Merge branch 'doc/4.2' into docs-next

This commit is contained in:
Jonathan Corbet 2015-06-08 17:04:11 -06:00
commit f8785d94fc
30 changed files with 175 additions and 62 deletions

View File

@ -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.

View File

@ -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:

View File

@ -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>

View File

@ -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

View File

@ -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

View File

@ -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);

View File

@ -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

View File

@ -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/

View File

@ -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]

View File

@ -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

View File

@ -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

View File

@ -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

View File

@ -445,7 +445,7 @@ MAINTAINERS ファイルにリストがありますので参照してくださ
メールの先頭でなく、各引用行の間にあなたの言いたいことを追加するべきで
す。
もしパッチをメールに付ける場合は、Documentaion/SubmittingPatches に提
もしパッチをメールに付ける場合は、Documentation/SubmittingPatches に提
示されているように、それは プレーンな可読テキストにすることを忘れない
ようにしましょう。カーネル開発者は 添付や圧縮したパッチを扱いたがりま
せん-

View File

@ -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)

View File

@ -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:

View File

@ -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).

View File

@ -1,2 +1 @@
dslm
freefall

View File

@ -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

View File

@ -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)

View File

@ -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

View File

@ -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;

View File

@ -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);

View File

@ -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

View File

@ -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:

View File

@ -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

View File

@ -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

View File

@ -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.

View File

@ -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

View File

@ -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)