Merge branch 'doc/4.2' into docs-next
Jonathan Corbet
commit
f8785d94fc
|
|
@ -670,7 +670,7 @@ functions:
|
|||
typeof(x) ret; \
|
||||
ret = calc_ret(x); \
|
||||
(ret); \
|
||||
)}
|
||||
})
|
||||
|
||||
ret is a common name for a local variable - __foo_ret is less likely
|
||||
to collide with an existing variable.
|
||||
|
|
|
|||
|
|
@ -240,7 +240,7 @@ the case would look like this:
|
|||
|
||||
if (!dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64))) {
|
||||
using_dac = 1;
|
||||
consistent_using_dac = 1;
|
||||
consistent_using_dac = 1;
|
||||
} else if (!dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32))) {
|
||||
using_dac = 0;
|
||||
consistent_using_dac = 0;
|
||||
|
|
@ -353,7 +353,7 @@ There are two types of DMA mappings:
|
|||
transfer, unmapped right after it (unless you use dma_sync_* below)
|
||||
and for which hardware can optimize for sequential accesses.
|
||||
|
||||
This of "streaming" as "asynchronous" or "outside the coherency
|
||||
Think of "streaming" as "asynchronous" or "outside the coherency
|
||||
domain".
|
||||
|
||||
Good examples of what to use streaming mappings for are:
|
||||
|
|
|
|||
|
|
@ -954,6 +954,8 @@ printk(KERN_INFO "my ip: %pI4\n", &ipaddress);
|
|||
<function>MODULE_LICENSE()</function> that specifies a GPL
|
||||
compatible license. It implies that the function is considered
|
||||
an internal implementation issue, and not really an interface.
|
||||
Some maintainers and developers may however
|
||||
require EXPORT_SYMBOL_GPL() when adding any new APIs or functionality.
|
||||
</para>
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
|
|
|||
|
|
@ -299,7 +299,9 @@ toward the stable maintainers by putting a line like this:
|
|||
|
||||
Cc: stable@vger.kernel.org
|
||||
|
||||
into your patch.
|
||||
into the sign-off area of your patch (note, NOT an email recipient). You
|
||||
should also read Documentation/stable_kernel_rules.txt in addition to this
|
||||
file.
|
||||
|
||||
Note, however, that some subsystem maintainers want to come to their own
|
||||
conclusions on which patches should go to the stable trees. The networking
|
||||
|
|
|
|||
|
|
@ -0,0 +1,53 @@
|
|||
Interface between kernel and boot loaders on Exynos boards
|
||||
==========================================================
|
||||
|
||||
Author: Krzysztof Kozlowski
|
||||
Date : 6 June 2015
|
||||
|
||||
The document tries to describe currently used interface between Linux kernel
|
||||
and boot loaders on Samsung Exynos based boards. This is not a definition
|
||||
of interface but rather a description of existing state, a reference
|
||||
for information purpose only.
|
||||
|
||||
In the document "boot loader" means any of following: U-boot, proprietary
|
||||
SBOOT or any other firmware for ARMv7 and ARMv8 initializing the board before
|
||||
executing kernel.
|
||||
|
||||
|
||||
1. Non-Secure mode
|
||||
Address: sysram_ns_base_addr
|
||||
Offset Value Purpose
|
||||
=============================================================================
|
||||
0x08 exynos_cpu_resume_ns System suspend
|
||||
0x0c 0x00000bad (Magic cookie) System suspend
|
||||
0x1c exynos4_secondary_startup Secondary CPU boot
|
||||
0x1c + 4*cpu exynos4_secondary_startup (Exynos4412) Secondary CPU boot
|
||||
0x20 0xfcba0d10 (Magic cookie) AFTR
|
||||
0x24 exynos_cpu_resume_ns AFTR
|
||||
0x28 + 4*cpu 0x8 (Magic cookie, Exynos3250) AFTR
|
||||
|
||||
|
||||
2. Secure mode
|
||||
Address: sysram_base_addr
|
||||
Offset Value Purpose
|
||||
=============================================================================
|
||||
0x00 exynos4_secondary_startup Secondary CPU boot
|
||||
0x04 exynos4_secondary_startup (Exynos542x) Secondary CPU boot
|
||||
4*cpu exynos4_secondary_startup (Exynos4412) Secondary CPU boot
|
||||
0x20 exynos_cpu_resume (Exynos4210 r1.0) AFTR
|
||||
0x24 0xfcba0d10 (Magic cookie, Exynos4210 r1.0) AFTR
|
||||
|
||||
Address: pmu_base_addr
|
||||
Offset Value Purpose
|
||||
=============================================================================
|
||||
0x0800 exynos_cpu_resume AFTR
|
||||
0x0814 exynos4_secondary_startup (Exynos4210 r1.1) Secondary CPU boot
|
||||
0x0818 0xfcba0d10 (Magic cookie, Exynos4210 r1.1) AFTR
|
||||
0x081C exynos_cpu_resume (Exynos4210 r1.1) AFTR
|
||||
|
||||
|
||||
3. Other (regardless of secure/non-secure mode)
|
||||
Address: pmu_base_addr
|
||||
Offset Value Purpose
|
||||
=============================================================================
|
||||
0x0908 Non-zero (only Exynos3250) Secondary CPU boot up indicator
|
||||
|
|
@ -17,6 +17,12 @@
|
|||
|
||||
#define DRIVER_NAME "gptimer_example"
|
||||
|
||||
#ifdef IRQ_TIMER5
|
||||
#define SAMPLE_IRQ_TIMER IRQ_TIMER5
|
||||
#else
|
||||
#define SAMPLE_IRQ_TIMER IRQ_TIMER2
|
||||
#endif
|
||||
|
||||
struct gptimer_data {
|
||||
uint32_t period, width;
|
||||
};
|
||||
|
|
@ -57,7 +63,8 @@ static int __init gptimer_example_init(void)
|
|||
}
|
||||
|
||||
/* grab the IRQ for the timer */
|
||||
ret = request_irq(IRQ_TIMER5, gptimer_example_irq, IRQF_SHARED, DRIVER_NAME, &data);
|
||||
ret = request_irq(SAMPLE_IRQ_TIMER, gptimer_example_irq,
|
||||
IRQF_SHARED, DRIVER_NAME, &data);
|
||||
if (ret) {
|
||||
printk(KERN_NOTICE DRIVER_NAME ": IRQ request failed\n");
|
||||
peripheral_free(P_TMR5);
|
||||
|
|
@ -65,7 +72,8 @@ static int __init gptimer_example_init(void)
|
|||
}
|
||||
|
||||
/* setup the timer and enable it */
|
||||
set_gptimer_config(TIMER5_id, WDTH_CAP | PULSE_HI | PERIOD_CNT | IRQ_ENA);
|
||||
set_gptimer_config(TIMER5_id,
|
||||
WDTH_CAP | PULSE_HI | PERIOD_CNT | IRQ_ENA);
|
||||
enable_gptimers(TIMER5bit);
|
||||
|
||||
return 0;
|
||||
|
|
@ -75,7 +83,7 @@ module_init(gptimer_example_init);
|
|||
static void __exit gptimer_example_exit(void)
|
||||
{
|
||||
disable_gptimers(TIMER5bit);
|
||||
free_irq(IRQ_TIMER5, &data);
|
||||
free_irq(SAMPLE_IRQ_TIMER, &data);
|
||||
peripheral_free(P_TMR5);
|
||||
}
|
||||
module_exit(gptimer_example_exit);
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@ Contents:
|
|||
1. What Is A CPUFreq Governor?
|
||||
==============================
|
||||
|
||||
Most cpufreq drivers (in fact, all except one, longrun) or even most
|
||||
Most cpufreq drivers (except the intel_pstate and longrun) or even most
|
||||
cpu frequency scaling algorithms only offer the CPU to be set to one
|
||||
frequency. In order to offer dynamic frequency scaling, the cpufreq
|
||||
core must be able to tell these drivers of a "target frequency". So
|
||||
|
|
|
|||
|
|
@ -3,24 +3,25 @@ Intel P-state driver
|
|||
|
||||
This driver provides an interface to control the P state selection for
|
||||
SandyBridge+ Intel processors. The driver can operate two different
|
||||
modes based on the processor model legacy and Hardware P state (HWP)
|
||||
modes based on the processor model, legacy mode and Hardware P state (HWP)
|
||||
mode.
|
||||
|
||||
In legacy mode the driver implements a scaling driver with an internal
|
||||
governor for Intel Core processors. The driver follows the same model
|
||||
as the Transmeta scaling driver (longrun.c) and implements the
|
||||
setpolicy() instead of target(). Scaling drivers that implement
|
||||
setpolicy() are assumed to implement internal governors by the cpufreq
|
||||
core. All the logic for selecting the current P state is contained
|
||||
within the driver; no external governor is used by the cpufreq core.
|
||||
In legacy mode, the Intel P-state implements two internal governors,
|
||||
performance and powersave, that differ from the general cpufreq governors of
|
||||
the same name (the general cpufreq governors implement target(), whereas the
|
||||
internal Intel P-state governors implement setpolicy()). The internal
|
||||
performance governor sets the max_perf_pct and min_perf_pct to 100; that is,
|
||||
the governor selects the highest available P state to maximize the performance
|
||||
of the core. The internal powersave governor selects the appropriate P state
|
||||
based on the current load on the CPU.
|
||||
|
||||
In HWP mode P state selection is implemented in the processor
|
||||
itself. The driver provides the interfaces between the cpufreq core and
|
||||
the processor to control P state selection based on user preferences
|
||||
and reporting frequency to the cpufreq core. In this mode the
|
||||
internal governor code is disabled.
|
||||
internal Intel P-state governor code is disabled.
|
||||
|
||||
In addtion to the interfaces provided by the cpufreq core for
|
||||
In addition to the interfaces provided by the cpufreq core for
|
||||
controlling frequency the driver provides sysfs files for
|
||||
controlling P state selection. These files have been added to
|
||||
/sys/devices/system/cpu/intel_pstate/
|
||||
|
|
|
|||
|
|
@ -379,10 +379,10 @@ may now be called in rcu-walk mode (nd->flags & LOOKUP_RCU). -ECHILD should be
|
|||
returned if the filesystem cannot handle rcu-walk. See
|
||||
Documentation/filesystems/vfs.txt for more details.
|
||||
|
||||
permission and check_acl are inode permission checks that are called
|
||||
on many or all directory inodes on the way down a path walk (to check for
|
||||
exec permission). These must now be rcu-walk aware (flags & IPERM_FLAG_RCU).
|
||||
See Documentation/filesystems/vfs.txt for more details.
|
||||
permission is an inode permission check that is called on many or all
|
||||
directory inodes on the way down a path walk (to check for exec permission). It
|
||||
must now be rcu-walk aware (mask & MAY_NOT_BLOCK). See
|
||||
Documentation/filesystems/vfs.txt for more details.
|
||||
|
||||
--
|
||||
[mandatory]
|
||||
|
|
|
|||
|
|
@ -205,7 +205,7 @@ asynchronous manner and the value may not be very precise. To see a precise
|
|||
snapshot of a moment, you can see /proc/<pid>/smaps file and scan page table.
|
||||
It's slow but very precise.
|
||||
|
||||
Table 1-2: Contents of the status files (as of 3.20.0)
|
||||
Table 1-2: Contents of the status files (as of 4.1)
|
||||
..............................................................................
|
||||
Field Content
|
||||
Name filename of the executable
|
||||
|
|
@ -235,6 +235,7 @@ Table 1-2: Contents of the status files (as of 3.20.0)
|
|||
VmExe size of text segment
|
||||
VmLib size of shared library code
|
||||
VmPTE size of page table entries
|
||||
VmPMD size of second level page tables
|
||||
VmSwap size of swap usage (the number of referred swapents)
|
||||
Threads number of threads
|
||||
SigQ number of signals queued/max. number for queue
|
||||
|
|
|
|||
|
|
@ -797,7 +797,7 @@ struct file_operations
|
|||
----------------------
|
||||
|
||||
This describes how the VFS can manipulate an open file. As of kernel
|
||||
3.12, the following members are defined:
|
||||
4.1, the following members are defined:
|
||||
|
||||
struct file_operations {
|
||||
struct module *owner;
|
||||
|
|
@ -811,8 +811,9 @@ struct file_operations {
|
|||
long (*unlocked_ioctl) (struct file *, unsigned int, unsigned long);
|
||||
long (*compat_ioctl) (struct file *, unsigned int, unsigned long);
|
||||
int (*mmap) (struct file *, struct vm_area_struct *);
|
||||
int (*mremap)(struct file *, struct vm_area_struct *);
|
||||
int (*open) (struct inode *, struct file *);
|
||||
int (*flush) (struct file *);
|
||||
int (*flush) (struct file *, fl_owner_t id);
|
||||
int (*release) (struct inode *, struct file *);
|
||||
int (*fsync) (struct file *, loff_t, loff_t, int datasync);
|
||||
int (*aio_fsync) (struct kiocb *, int datasync);
|
||||
|
|
@ -822,11 +823,15 @@ struct file_operations {
|
|||
unsigned long (*get_unmapped_area)(struct file *, unsigned long, unsigned long, unsigned long, unsigned long);
|
||||
int (*check_flags)(int);
|
||||
int (*flock) (struct file *, int, struct file_lock *);
|
||||
ssize_t (*splice_write)(struct pipe_inode_info *, struct file *, size_t, unsigned int);
|
||||
ssize_t (*splice_read)(struct file *, struct pipe_inode_info *, size_t, unsigned int);
|
||||
int (*setlease)(struct file *, long arg, struct file_lock **, void **);
|
||||
long (*fallocate)(struct file *, int mode, loff_t offset, loff_t len);
|
||||
ssize_t (*splice_write)(struct pipe_inode_info *, struct file *, loff_t *, size_t, unsigned int);
|
||||
ssize_t (*splice_read)(struct file *, loff_t *, struct pipe_inode_info *, size_t, unsigned int);
|
||||
int (*setlease)(struct file *, long, struct file_lock **, void **);
|
||||
long (*fallocate)(struct file *file, int mode, loff_t offset,
|
||||
loff_t len);
|
||||
void (*show_fdinfo)(struct seq_file *m, struct file *f);
|
||||
#ifndef CONFIG_MMU
|
||||
unsigned (*mmap_capabilities)(struct file *);
|
||||
#endif
|
||||
};
|
||||
|
||||
Again, all methods are called without any locks being held, unless
|
||||
|
|
|
|||
|
|
@ -290,7 +290,7 @@ corresponding to a given GPIO using the following call:
|
|||
|
||||
int gpiod_to_irq(const struct gpio_desc *desc)
|
||||
|
||||
It will return an IRQ number, or an negative errno code if the mapping can't be
|
||||
It will return an IRQ number, or a negative errno code if the mapping can't be
|
||||
done (most likely because that particular GPIO cannot be used as IRQ). It is an
|
||||
unchecked error to use a GPIO that wasn't set up as an input using
|
||||
gpiod_direction_input(), or to use an IRQ number that didn't originally come
|
||||
|
|
|
|||
|
|
@ -445,7 +445,7 @@ MAINTAINERS ファイルにリストがありますので参照してくださ
|
|||
メールの先頭でなく、各引用行の間にあなたの言いたいことを追加するべきで
|
||||
す。
|
||||
|
||||
もしパッチをメールに付ける場合は、Documentaion/SubmittingPatches に提
|
||||
もしパッチをメールに付ける場合は、Documentation/SubmittingPatches に提
|
||||
示されているように、それは プレーンな可読テキストにすることを忘れない
|
||||
ようにしましょう。カーネル開発者は 添付や圧縮したパッチを扱いたがりま
|
||||
せん-
|
||||
|
|
|
|||
|
|
@ -150,7 +150,7 @@ AddressSanitizer dedicates 1/8 of kernel memory to its shadow memory
|
|||
(e.g. 16TB to cover 128TB on x86_64) and uses direct mapping with a scale and
|
||||
offset to translate a memory address to its corresponding shadow address.
|
||||
|
||||
Here is the function witch translate an address to its corresponding shadow
|
||||
Here is the function which translates an address to its corresponding shadow
|
||||
address:
|
||||
|
||||
static inline void *kasan_mem_to_shadow(const void *addr)
|
||||
|
|
|
|||
|
|
@ -755,8 +755,8 @@ Additional files can be specified in kbuild makefiles by use of $(clean-files).
|
|||
#lib/Makefile
|
||||
clean-files := crc32table.h
|
||||
|
||||
When executing "make clean", the two files "devlist.h classlist.h" will be
|
||||
deleted. Kbuild will assume files to be in the same relative directory as the
|
||||
When executing "make clean", the file "crc32table.h" will be deleted.
|
||||
Kbuild will assume files to be in the same relative directory as the
|
||||
Makefile, except if prefixed with $(objtree).
|
||||
|
||||
To delete a directory hierarchy use:
|
||||
|
|
|
|||
|
|
@ -2437,7 +2437,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
|
|||
|
||||
nomca [IA-64] Disable machine check abort handling
|
||||
|
||||
nomce [X86-32] Machine Check Exception
|
||||
nomce [X86-32] Disable Machine Check Exception
|
||||
|
||||
nomfgpt [X86-32] Disable Multi-Function General Purpose
|
||||
Timer usage (for AMD Geode machines).
|
||||
|
|
|
|||
|
|
@ -1,2 +1 @@
|
|||
dslm
|
||||
freefall
|
||||
|
|
|
|||
|
|
@ -8,8 +8,6 @@ disk-shock-protection.txt
|
|||
- information on hard disk shock protection.
|
||||
dslm.c
|
||||
- Simple Disk Sleep Monitor program
|
||||
freefall.c
|
||||
- (HP/DELL) laptop accelerometer program for disk protection.
|
||||
laptop-mode.txt
|
||||
- how to conserve battery power using laptop-mode.
|
||||
sony-laptop.txt
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
# List of programs to build
|
||||
hostprogs-y := dslm freefall
|
||||
hostprogs-y := dslm
|
||||
|
||||
# Tell kbuild to always build the programs
|
||||
always := $(hostprogs-y)
|
||||
|
|
|
|||
|
|
@ -116,7 +116,6 @@ COW_MAGIC 0x4f4f4f4d cow_header_v1 arch/um/drivers/ubd_user.c
|
|||
I810_CARD_MAGIC 0x5072696E i810_card sound/oss/i810_audio.c
|
||||
TRIDENT_CARD_MAGIC 0x5072696E trident_card sound/oss/trident.c
|
||||
ROUTER_MAGIC 0x524d4157 wan_device [in wanrouter.h pre 3.9]
|
||||
SCC_MAGIC 0x52696368 gs_port drivers/char/scc.h
|
||||
SAVEKMSG_MAGIC1 0x53415645 savekmsg arch/*/amiga/config.c
|
||||
GDA_MAGIC 0x58464552 gda arch/mips/include/asm/sn/gda.h
|
||||
RED_MAGIC1 0x5a2cf071 (any) mm/slab.c
|
||||
|
|
@ -138,7 +137,6 @@ KMALLOC_MAGIC 0x87654321 snd_alloc_track sound/core/memory.c
|
|||
PWC_MAGIC 0x89DC10AB pwc_device drivers/usb/media/pwc.h
|
||||
NBD_REPLY_MAGIC 0x96744668 nbd_reply include/linux/nbd.h
|
||||
ENI155_MAGIC 0xa54b872d midway_eprom drivers/atm/eni.h
|
||||
SCI_MAGIC 0xbabeface gs_port drivers/char/sh-sci.h
|
||||
CODA_MAGIC 0xC0DAC0DA coda_file_info fs/coda/coda_fs_i.h
|
||||
DPMEM_MAGIC 0xc0ffee11 gdt_pci_sram drivers/scsi/gdth.h
|
||||
YAM_MAGIC 0xF10A7654 yam_port drivers/net/hamradio/yam.c
|
||||
|
|
|
|||
|
|
@ -36,6 +36,7 @@
|
|||
#include <asm/types.h>
|
||||
#include <error.h>
|
||||
#include <errno.h>
|
||||
#include <inttypes.h>
|
||||
#include <linux/errqueue.h>
|
||||
#include <linux/if_ether.h>
|
||||
#include <linux/net_tstamp.h>
|
||||
|
|
@ -49,7 +50,6 @@
|
|||
#include <poll.h>
|
||||
#include <stdarg.h>
|
||||
#include <stdbool.h>
|
||||
#include <stdint.h>
|
||||
#include <stdio.h>
|
||||
#include <stdlib.h>
|
||||
#include <string.h>
|
||||
|
|
@ -96,7 +96,7 @@ static void __print_timestamp(const char *name, struct timespec *cur,
|
|||
prev_ms = (long) ts_prev.tv_sec * 1000 * 1000;
|
||||
prev_ms += ts_prev.tv_nsec / 1000;
|
||||
|
||||
fprintf(stderr, " (%+ld us)", cur_ms - prev_ms);
|
||||
fprintf(stderr, " (%+" PRId64 " us)", cur_ms - prev_ms);
|
||||
}
|
||||
|
||||
ts_prev = *cur;
|
||||
|
|
|
|||
|
|
@ -122,7 +122,7 @@ This must be done from a context that can sleep.
|
|||
PHY Management
|
||||
--------------
|
||||
|
||||
The physical link (i2c, ...) management is defined by the following struture:
|
||||
The physical link (i2c, ...) management is defined by the following structure:
|
||||
|
||||
struct nfc_phy_ops {
|
||||
int (*write)(void *dev_id, struct sk_buff *skb);
|
||||
|
|
|
|||
|
|
@ -59,11 +59,20 @@ For all other submissions, choose one of the following procedures:
|
|||
changelog of your submission, as well as the kernel version you wish
|
||||
it to be applied to.
|
||||
|
||||
Option 1 is probably the easiest and most common. Options 2 and 3 are more
|
||||
useful if the patch isn't deemed worthy at the time it is applied to a public
|
||||
git tree (for instance, because it deserves more regression testing first).
|
||||
Option 3 is especially useful if the patch needs some special handling to apply
|
||||
to an older kernel (e.g., if API's have changed in the meantime).
|
||||
Option 1 is *strongly* preferred, is the easiest and most common. Options 2 and
|
||||
3 are more useful if the patch isn't deemed worthy at the time it is applied to
|
||||
a public git tree (for instance, because it deserves more regression testing
|
||||
first). Option 3 is especially useful if the patch needs some special handling
|
||||
to apply to an older kernel (e.g., if API's have changed in the meantime).
|
||||
|
||||
Note that for Option 3, if the patch deviates from the original upstream patch
|
||||
(for example because it had to be backported) this must be very clearly
|
||||
documented and justified in the patch description.
|
||||
|
||||
The upstream commit ID must be specified with a separate line above the commit
|
||||
text, like this:
|
||||
|
||||
commit <sha1> upstream.
|
||||
|
||||
Additionally, some patches submitted via Option 1 may have additional patch
|
||||
prerequisites which can be cherry-picked. This can be specified in the following
|
||||
|
|
|
|||
|
|
@ -108,8 +108,8 @@ of ftrace. Here is a list of some of the key files:
|
|||
data is read from this file, it is consumed, and
|
||||
will not be read again with a sequential read. The
|
||||
"trace" file is static, and if the tracer is not
|
||||
adding more data,they will display the same
|
||||
information every time they are read.
|
||||
adding more data, it will display the same
|
||||
information every time it is read.
|
||||
|
||||
trace_options:
|
||||
|
||||
|
|
|
|||
|
|
@ -465,12 +465,14 @@ Generic Serial driver
|
|||
device, and does not support any kind of device flow control. All that
|
||||
is required of your device is that it has at least one bulk in endpoint,
|
||||
or one bulk out endpoint.
|
||||
|
||||
To enable the generic driver to recognize your device, build the driver
|
||||
as a module and load it by the following invocation:
|
||||
|
||||
To enable the generic driver to recognize your device, provide
|
||||
echo <vid> <pid> >/sys/bus/usb-serial/drivers/generic/new_id
|
||||
where the <vid> and <pid> is replaced with the hex representation of your
|
||||
device's vendor id and product id.
|
||||
If the driver is compiled as a module you can also provide one id when
|
||||
loading the module
|
||||
insmod usbserial vendor=0x#### product=0x####
|
||||
where the #### is replaced with the hex representation of your device's
|
||||
vendor id and product id.
|
||||
|
||||
This driver has been successfully used to connect to the NetChip USB
|
||||
development board, providing a way to develop USB firmware without
|
||||
|
|
|
|||
|
|
@ -116,7 +116,6 @@ COW_MAGIC 0x4f4f4f4d cow_header_v1 arch/um/drivers/ubd_user.c
|
|||
I810_CARD_MAGIC 0x5072696E i810_card sound/oss/i810_audio.c
|
||||
TRIDENT_CARD_MAGIC 0x5072696E trident_card sound/oss/trident.c
|
||||
ROUTER_MAGIC 0x524d4157 wan_device [in wanrouter.h pre 3.9]
|
||||
SCC_MAGIC 0x52696368 gs_port drivers/char/scc.h
|
||||
SAVEKMSG_MAGIC1 0x53415645 savekmsg arch/*/amiga/config.c
|
||||
GDA_MAGIC 0x58464552 gda arch/mips/include/asm/sn/gda.h
|
||||
RED_MAGIC1 0x5a2cf071 (any) mm/slab.c
|
||||
|
|
@ -138,7 +137,6 @@ KMALLOC_MAGIC 0x87654321 snd_alloc_track sound/core/memory.c
|
|||
PWC_MAGIC 0x89DC10AB pwc_device drivers/usb/media/pwc.h
|
||||
NBD_REPLY_MAGIC 0x96744668 nbd_reply include/linux/nbd.h
|
||||
ENI155_MAGIC 0xa54b872d midway_eprom drivers/atm/eni.h
|
||||
SCI_MAGIC 0xbabeface gs_port drivers/char/sh-sci.h
|
||||
CODA_MAGIC 0xC0DAC0DA coda_file_info include/linux/coda_fs_i.h
|
||||
DPMEM_MAGIC 0xc0ffee11 gdt_pci_sram drivers/scsi/gdth.h
|
||||
YAM_MAGIC 0xF10A7654 yam_port drivers/net/hamradio/yam.c
|
||||
|
|
|
|||
|
|
@ -21,15 +21,25 @@ been permitted to redistribute under separate cover.
|
|||
|
||||
To submit firmware to that repository, please send either a git binary
|
||||
diff or preferably a git pull request to:
|
||||
David Woodhouse <dwmw2@infradead.org>
|
||||
Ben Hutchings <ben@decadent.org.uk>
|
||||
linux-firmware@kernel.org
|
||||
and also cc: to related mailing lists.
|
||||
|
||||
Your commit should include an update to the WHENCE file clearly
|
||||
identifying the licence under which the firmware is available, and
|
||||
that it is redistributable. If the licence is long and involved, it's
|
||||
permitted to include it in a separate file and refer to it from the
|
||||
WHENCE file.
|
||||
And if it were possible, a changelog of the firmware itself.
|
||||
|
||||
Ideally, your commit should contain a Signed-Off-By: from someone
|
||||
authoritative on the licensing of the firmware in question (i.e. from
|
||||
within the company that owns the code).
|
||||
|
||||
|
||||
WARNING:
|
||||
=======
|
||||
|
||||
Don't send any "CONFIDENTIALITY STATEMENT" in your e-mail, patch or
|
||||
request. Otherwise your firmware _will never be accepted_.
|
||||
|
||||
Maintainers are really busy, so don't expect a prompt reply.
|
||||
|
|
|
|||
|
|
@ -18,6 +18,7 @@ help:
|
|||
@echo ' vm - misc vm tools'
|
||||
@echo ' x86_energy_perf_policy - Intel energy policy tool'
|
||||
@echo ' tmon - thermal monitoring and tuning tool'
|
||||
@echo ' freefall - laptop accelerometer program for disk protection'
|
||||
@echo ''
|
||||
@echo 'You can do:'
|
||||
@echo ' $$ make -C tools/ <tool>_install'
|
||||
|
|
@ -62,6 +63,9 @@ turbostat x86_energy_perf_policy: FORCE
|
|||
tmon: FORCE
|
||||
$(call descend,thermal/$@)
|
||||
|
||||
freefall: FORCE
|
||||
$(call descend,laptop/$@)
|
||||
|
||||
acpi_install:
|
||||
$(call descend,power/$(@:_install=),install)
|
||||
|
||||
|
|
@ -80,10 +84,13 @@ turbostat_install x86_energy_perf_policy_install:
|
|||
tmon_install:
|
||||
$(call descend,thermal/$(@:_install=),install)
|
||||
|
||||
freefall_install:
|
||||
$(call descend,laptop/$(@:_install=),install)
|
||||
|
||||
install: acpi_install cgroup_install cpupower_install hv_install firewire_install lguest_install \
|
||||
perf_install selftests_install turbostat_install usb_install \
|
||||
virtio_install vm_install net_install x86_energy_perf_policy_install \
|
||||
tmon
|
||||
tmon freefall_install
|
||||
|
||||
acpi_clean:
|
||||
$(call descend,power/acpi,clean)
|
||||
|
|
@ -112,8 +119,11 @@ turbostat_clean x86_energy_perf_policy_clean:
|
|||
tmon_clean:
|
||||
$(call descend,thermal/tmon,clean)
|
||||
|
||||
freefall_clean:
|
||||
$(call descend,laptop/freefall,clean)
|
||||
|
||||
clean: acpi_clean cgroup_clean cpupower_clean hv_clean firewire_clean lguest_clean \
|
||||
perf_clean selftests_clean turbostat_clean usb_clean virtio_clean \
|
||||
vm_clean net_clean x86_energy_perf_policy_clean tmon_clean
|
||||
vm_clean net_clean x86_energy_perf_policy_clean tmon_clean freefall_clean
|
||||
|
||||
.PHONY: FORCE
|
||||
|
|
|
|||
|
|
@ -0,0 +1,17 @@
|
|||
PREFIX ?= /usr
|
||||
SBINDIR ?= sbin
|
||||
INSTALL ?= install
|
||||
CC = $(CROSS_COMPILE)gcc
|
||||
|
||||
TARGET = freefall
|
||||
|
||||
all: $(TARGET)
|
||||
|
||||
%: %.c
|
||||
$(CC) $(CFLAGS) $(LDFLAGS) -o $@ $<
|
||||
|
||||
clean:
|
||||
$(RM) $(TARGET)
|
||||
|
||||
install: freefall
|
||||
$(INSTALL) -D -m 755 $(TARGET) $(DESTDIR)$(PREFIX)/$(SBINDIR)/$(TARGET)
|
||||
Loading…
Reference in New Issue