FEX-Emu/linux
1
0
Fork 0
mirror of https://github.com/FEX-Emu/linux.git synced 2024-12-14 04:41:26 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless

Browse Source
This commit is contained in:
John W. Linville 2012-04-12 13:49:28 -04:00
commit 8065248069
4103 changed files with 104989 additions and 50464 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
Documentation/ABI/stable/sysfs-driver-usb-usbtmc
View File

@ -55,7 +55,7 @@ What: /sys/bus/usb/drivers/usbtmc/devices/*/auto_abort
Date: August 2008
Contact: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Description:
This file determines if the the transaction of the USB TMC
This file determines if the transaction of the USB TMC
device is to be automatically aborted if there is any error.
For more details about this, please see the document,
"Universal Serial Bus Test and Measurement Class Specification

16
Documentation/ABI/testing/debugfs-olpc Normal file
View File

@ -0,0 +1,16 @@
What: /sys/kernel/debug/olpc-ec/cmd
Date: Dec 2011
KernelVersion: 3.4
Contact: devel@lists.laptop.org
Description:
A generic interface for executing OLPC Embedded Controller commands and
reading their responses.
To execute a command, write data with the format: CC:N A A A A
CC is the (hex) command, N is the count of expected reply bytes, and A A A A
are optional (hex) arguments.
To read the response (if any), read from the generic node after executing
a command. Hex reply bytes will be returned, *whether or not* they came from
the immediately previous command.

25
Documentation/ABI/testing/sysfs-block-dm Normal file
View File

@ -0,0 +1,25 @@
What: /sys/block/dm-<num>/dm/name
Date: January 2009
KernelVersion: 2.6.29
Contact: dm-devel@redhat.com
Description: Device-mapper device name.
Read-only string containing mapped device name.
Users: util-linux, device-mapper udev rules
What: /sys/block/dm-<num>/dm/uuid
Date: January 2009
KernelVersion: 2.6.29
Contact: dm-devel@redhat.com
Description: Device-mapper device UUID.
Read-only string containing DM-UUID or empty string
if DM-UUID is not set.
Users: util-linux, device-mapper udev rules
What: /sys/block/dm-<num>/dm/suspended
Date: June 2009
KernelVersion: 2.6.31
Contact: dm-devel@redhat.com
Description: Device-mapper device suspend state.
Contains the value 1 while the device is suspended.
Otherwise it contains 0. Read-only attribute.
Users: util-linux, device-mapper udev rules

14
Documentation/ABI/testing/sysfs-bus-event_source-devices-format Normal file
View File

@ -0,0 +1,14 @@
Where: /sys/bus/event_source/devices/<dev>/format
Date: January 2012
Kernel Version: 3.3
Contact: Jiri Olsa <jolsa@redhat.com>
Description:
Attribute group to describe the magic bits that go into
perf_event_attr::config[012] for a particular pmu.
Each attribute of this group defines the 'hardware' bitmask
we want to export, so that userspace can deal with sane
name/value pairs.
Example: 'config1:1,6-10,44'
Defines contents of attribute that occupies bits 1,6-10,44 of
perf_event_attr::config1.

18
Documentation/ABI/testing/sysfs-driver-samsung-laptop
View File

@ -17,3 +17,21 @@ Description: Some Samsung laptops have different "performance levels"
Specifically, not all support the "overclock" option,
and it's still unknown if this value even changes
anything, other than making the user feel a bit better.
What: /sys/devices/platform/samsung/battery_life_extender
Date: December 1, 2011
KernelVersion: 3.3
Contact: Corentin Chary <corentin.chary@gmail.com>
Description: Max battery charge level can be modified, battery cycle
life can be extended by reducing the max battery charge
level.
0 means normal battery mode (100% charge)
1 means battery life extender mode (80% charge)
What: /sys/devices/platform/samsung/usb_charge
Date: December 1, 2011
KernelVersion: 3.3
Contact: Corentin Chary <corentin.chary@gmail.com>
Description: Use your USB ports to charge devices, even
when your laptop is powered off.
1 means enabled, 0 means disabled.

20
Documentation/ABI/testing/sysfs-firmware-acpi
View File

@ -1,3 +1,23 @@
What: /sys/firmware/acpi/bgrt/
Date: January 2012
Contact: Matthew Garrett <mjg@redhat.com>
Description:
The BGRT is an ACPI 5.0 feature that allows the OS
to obtain a copy of the firmware boot splash and
some associated metadata. This is intended to be used
by boot splash applications in order to interact with
the firmware boot splash in order to avoid jarring
transitions.
image: The image bitmap. Currently a 32-bit BMP.
status: 1 if the image is valid, 0 if firmware invalidated it.
type: 0 indicates image is in BMP format.
version: The version of the BGRT. Currently 1.
xoffset: The number of pixels between the left of the screen
and the left edge of the image.
yoffset: The number of pixels between the top of the screen
and the top edge of the image.
What: /sys/firmware/acpi/interrupts/
Date: February 2008
Contact: Len Brown <lenb@kernel.org>

29
Documentation/CodingStyle
View File

@ -793,6 +793,35 @@ own custom mode, or may have some other magic method for making indentation
work correctly.
Chapter 19: Inline assembly
In architecture-specific code, you may need to use inline assembly to interface
with CPU or platform functionality. Don't hesitate to do so when necessary.
However, don't use inline assembly gratuitously when C can do the job. You can
and should poke hardware from C when possible.
Consider writing simple helper functions that wrap common bits of inline
assembly, rather than repeatedly writing them with slight variations. Remember
that inline assembly can use C parameters.
Large, non-trivial assembly functions should go in .S files, with corresponding
C prototypes defined in C header files. The C prototypes for assembly
functions should use "asmlinkage".
You may need to mark your asm statement as volatile, to prevent GCC from
removing it if GCC doesn't notice any side effects. You don't always need to
do so, though, and doing so unnecessarily can limit optimization.
When writing a single inline assembly statement containing multiple
instructions, put each instruction on a separate line in a separate quoted
string, and end each string except the last with \n\t to properly indent the
next instruction in the assembly output:
asm ("magic %reg1, #42\n\t"
"more_magic %reg2, %reg3"
: /* outputs */ : /* inputs */ : /* clobbers */);
Appendix I: References

18
Documentation/DMA-attributes.txt
View File

@ -31,3 +31,21 @@ may be weakly ordered, that is that reads and writes may pass each other.
Since it is optional for platforms to implement DMA_ATTR_WEAK_ORDERING,
those that do not will simply ignore the attribute and exhibit default
behavior.
DMA_ATTR_WRITE_COMBINE
----------------------
DMA_ATTR_WRITE_COMBINE specifies that writes to the mapping may be
buffered to improve performance.
Since it is optional for platforms to implement DMA_ATTR_WRITE_COMBINE,
those that do not will simply ignore the attribute and exhibit default
behavior.
DMA_ATTR_NON_CONSISTENT
-----------------------
DMA_ATTR_NON_CONSISTENT lets the platform to choose to return either
consistent or non-consistent memory as it sees fit. By using this API,
you are guaranteeing to the platform that you have all the correct and
necessary sync points for this memory in the driver.

17
Documentation/DocBook/device-drivers.tmpl
View File

@ -446,4 +446,21 @@ X!Idrivers/video/console/fonts.c
!Edrivers/i2c/i2c-core.c
</chapter>
<chapter id="hsi">
<title>High Speed Synchronous Serial Interface (HSI)</title>
<para>
High Speed Synchronous Serial Interface (HSI) is a
serial interface mainly used for connecting application
engines (APE) with cellular modem engines (CMT) in cellular
handsets.
HSI provides multiplexing for up to 16 logical channels,
low-latency and full duplex communication.
</para>
!Iinclude/linux/hsi/hsi.h
!Edrivers/hsi/hsi.c
</chapter>
</book>

2
Documentation/Makefile
View File

@ -1,3 +1,3 @@
obj-m := DocBook/ accounting/ auxdisplay/ connector/ \
filesystems/ filesystems/configfs/ ia64/ laptops/ networking/ \
pcmcia/ spi/ timers/ vm/ watchdog/src/
pcmcia/ spi/ timers/ watchdog/src/

8
Documentation/acpi/apei/einj.txt
View File

@ -53,6 +53,14 @@ directory apei/einj. The following files are provided.
This file is used to set the second error parameter value. Effect of
parameter depends on error_type specified.
- notrigger
The EINJ mechanism is a two step process. First inject the error, then
perform some actions to trigger it. Setting "notrigger" to 1 skips the
trigger phase, which *may* allow the user to cause the error in some other
context by a simple access to the cpu, memory location, or device that is
the target of the error injection. Whether this actually works depends
on what operations the BIOS actually includes in the trigger phase.
BIOS versions based in the ACPI 4.0 specification have limited options
to control where the errors are injected. Your BIOS may support an
extension (enabled with the param_extension=1 module parameter, or

2
Documentation/aoe/aoe.txt
View File

@ -35,7 +35,7 @@ CREATING DEVICE NODES
sh Documentation/aoe/mkshelf.sh /dev/etherd 0
There is also an autoload script that shows how to edit
/etc/modprobe.conf to ensure that the aoe module is loaded when
/etc/modprobe.d/aoe.conf to ensure that the aoe module is loaded when
necessary.
USING DEVICE NODES

4
Documentation/aoe/autoload.sh
View File

@ -1,8 +1,8 @@
#!/bin/sh
# set aoe to autoload by installing the
# aliases in /etc/modprobe.conf
# aliases in /etc/modprobe.d/
f=/etc/modprobe.conf
f=/etc/modprobe.d/aoe.conf
if test ! -r $f || test ! -w $f; then
echo "cannot configure $f for module autoloading" 1>&2

2
Documentation/blockdev/floppy.txt
View File

@ -49,7 +49,7 @@ you can put:
options floppy omnibook messages
in /etc/modprobe.conf.
in a configuration file in /etc/modprobe.d/.
The floppy driver related options are:

2
Documentation/cgroups/cpusets.txt
View File

@ -217,7 +217,7 @@ and name space for cpusets, with a minimum of additional kernel code.
The cpus and mems files in the root (top_cpuset) cpuset are
read-only. The cpus file automatically tracks the value of
cpu_online_map using a CPU hotplug notifier, and the mems file
cpu_online_mask using a CPU hotplug notifier, and the mems file
automatically tracks the value of node_states[N_HIGH_MEMORY]--i.e.,
nodes with memory--using the cpuset_track_online_nodes() hook.

233
Documentation/clk.txt Normal file
View File

@ -0,0 +1,233 @@
The Common Clk Framework
Mike Turquette <mturquette@ti.com>
This document endeavours to explain the common clk framework details,
and how to port a platform over to this framework. It is not yet a
detailed explanation of the clock api in include/linux/clk.h, but
perhaps someday it will include that information.
Part 1 - introduction and interface split
The common clk framework is an interface to control the clock nodes
available on various devices today. This may come in the form of clock
gating, rate adjustment, muxing or other operations. This framework is
enabled with the CONFIG_COMMON_CLK option.
The interface itself is divided into two halves, each shielded from the
details of its counterpart. First is the common definition of struct
clk which unifies the framework-level accounting and infrastructure that
has traditionally been duplicated across a variety of platforms. Second
is a common implementation of the clk.h api, defined in
drivers/clk/clk.c. Finally there is struct clk_ops, whose operations
are invoked by the clk api implementation.
The second half of the interface is comprised of the hardware-specific
callbacks registered with struct clk_ops and the corresponding
hardware-specific structures needed to model a particular clock. For
the remainder of this document any reference to a callback in struct
clk_ops, such as .enable or .set_rate, implies the hardware-specific
implementation of that code. Likewise, references to struct clk_foo
serve as a convenient shorthand for the implementation of the
hardware-specific bits for the hypothetical "foo" hardware.
Tying the two halves of this interface together is struct clk_hw, which
is defined in struct clk_foo and pointed to within struct clk. This
allows easy for navigation between the two discrete halves of the common
clock interface.
Part 2 - common data structures and api
Below is the common struct clk definition from
include/linux/clk-private.h, modified for brevity:
struct clk {
const char *name;
const struct clk_ops *ops;
struct clk_hw *hw;
char **parent_names;
struct clk **parents;
struct clk *parent;
struct hlist_head children;
struct hlist_node child_node;
...
};
The members above make up the core of the clk tree topology. The clk
api itself defines several driver-facing functions which operate on
struct clk. That api is documented in include/linux/clk.h.
Platforms and devices utilizing the common struct clk use the struct
clk_ops pointer in struct clk to perform the hardware-specific parts of
the operations defined in clk.h:
struct clk_ops {
int (*prepare)(struct clk_hw *hw);
void (*unprepare)(struct clk_hw *hw);
int (*enable)(struct clk_hw *hw);
void (*disable)(struct clk_hw *hw);
int (*is_enabled)(struct clk_hw *hw);
unsigned long (*recalc_rate)(struct clk_hw *hw,
unsigned long parent_rate);
long (*round_rate)(struct clk_hw *hw, unsigned long,
unsigned long *);
int (*set_parent)(struct clk_hw *hw, u8 index);
u8 (*get_parent)(struct clk_hw *hw);
int (*set_rate)(struct clk_hw *hw, unsigned long);
void (*init)(struct clk_hw *hw);
};
Part 3 - hardware clk implementations
The strength of the common struct clk comes from its .ops and .hw pointers
which abstract the details of struct clk from the hardware-specific bits, and
vice versa. To illustrate consider the simple gateable clk implementation in
drivers/clk/clk-gate.c:
struct clk_gate {
struct clk_hw hw;
void __iomem *reg;
u8 bit_idx;
...
};
struct clk_gate contains struct clk_hw hw as well as hardware-specific
knowledge about which register and bit controls this clk's gating.
Nothing about clock topology or accounting, such as enable_count or
notifier_count, is needed here. That is all handled by the common
framework code and struct clk.
Let's walk through enabling this clk from driver code:
struct clk *clk;
clk = clk_get(NULL, "my_gateable_clk");
clk_prepare(clk);
clk_enable(clk);
The call graph for clk_enable is very simple:
clk_enable(clk);
clk->ops->enable(clk->hw);
[resolves to...]
clk_gate_enable(hw);
[resolves struct clk gate with to_clk_gate(hw)]
clk_gate_set_bit(gate);
And the definition of clk_gate_set_bit:
static void clk_gate_set_bit(struct clk_gate *gate)
{
u32 reg;
reg = __raw_readl(gate->reg);
reg |= BIT(gate->bit_idx);
writel(reg, gate->reg);
}
Note that to_clk_gate is defined as:
#define to_clk_gate(_hw) container_of(_hw, struct clk_gate, clk)
This pattern of abstraction is used for every clock hardware
representation.
Part 4 - supporting your own clk hardware
When implementing support for a new type of clock it only necessary to
include the following header:
#include <linux/clk-provider.h>
include/linux/clk.h is included within that header and clk-private.h
must never be included from the code which implements the operations for
a clock. More on that below in Part 5.
To construct a clk hardware structure for your platform you must define
the following:
struct clk_foo {
struct clk_hw hw;
... hardware specific data goes here ...
};
To take advantage of your data you'll need to support valid operations
for your clk:
struct clk_ops clk_foo_ops {
.enable = &clk_foo_enable;
.disable = &clk_foo_disable;
};
Implement the above functions using container_of:
#define to_clk_foo(_hw) container_of(_hw, struct clk_foo, hw)
int clk_foo_enable(struct clk_hw *hw)
{
struct clk_foo *foo;
foo = to_clk_foo(hw);
... perform magic on foo ...
return 0;
};
Below is a matrix detailing which clk_ops are mandatory based upon the
hardware capbilities of that clock. A cell marked as "y" means
mandatory, a cell marked as "n" implies that either including that
callback is invalid or otherwise uneccesary. Empty cells are either
optional or must be evaluated on a case-by-case basis.
clock hardware characteristics
-----------------------------------------------------------
| gate | change rate | single parent | multiplexer | root |
|------|-------------|---------------|-------------|------|
.prepare | | | | | |
.unprepare | | | | | |
| | | | | |
.enable | y | | | | |
.disable | y | | | | |
.is_enabled | y | | | | |
| | | | | |
.recalc_rate | | y | | | |
.round_rate | | y | | | |
.set_rate | | y | | | |
| | | | | |
.set_parent | | | n | y | n |
.get_parent | | | n | y | n |
| | | | | |
.init | | | | | |
-----------------------------------------------------------
Finally, register your clock at run-time with a hardware-specific
registration function. This function simply populates struct clk_foo's
data and then passes the common struct clk parameters to the framework
with a call to:
clk_register(...)
See the basic clock types in drivers/clk/clk-*.c for examples.
Part 5 - static initialization of clock data
For platforms with many clocks (often numbering into the hundreds) it
may be desirable to statically initialize some clock data. This
presents a problem since the definition of struct clk should be hidden
from everyone except for the clock core in drivers/clk/clk.c.
To get around this problem struct clk's definition is exposed in
include/linux/clk-private.h along with some macros for more easily
initializing instances of the basic clock types. These clocks must
still be initialized with the common clock framework via a call to
__clk_init.
clk-private.h must NEVER be included by code which implements struct
clk_ops callbacks, nor must it be included by any logic which pokes
around inside of struct clk at run-time. To do so is a layering
violation.
To better enforce this policy, always follow this simple rule: any
statically initialized clock data MUST be defined in a separate file
from the logic that implements its ops. Basically separate the logic
from the data and all is well.

22
Documentation/cpu-hotplug.txt
View File

@ -47,7 +47,7 @@ maxcpus=n Restrict boot time cpus to n. Say if you have 4 cpus, using
other cpus later online, read FAQ's for more info.
additional_cpus=n (*) Use this to limit hotpluggable cpus. This option sets
cpu_possible_map = cpu_present_map + additional_cpus
cpu_possible_mask = cpu_present_mask + additional_cpus
cede_offline={"off","on"} Use this option to disable/enable putting offlined
processors to an extended H_CEDE state on
@ -64,11 +64,11 @@ should only rely on this to count the # of cpus, but *MUST* not rely
on the apicid values in those tables for disabled apics. In the event
BIOS doesn't mark such hot-pluggable cpus as disabled entries, one could
use this parameter "additional_cpus=x" to represent those cpus in the
cpu_possible_map.
cpu_possible_mask.
possible_cpus=n [s390,x86_64] use this to set hotpluggable cpus.
This option sets possible_cpus bits in
cpu_possible_map. Thus keeping the numbers of bits set
cpu_possible_mask. Thus keeping the numbers of bits set
constant even if the machine gets rebooted.
CPU maps and such
@ -76,7 +76,7 @@ CPU maps and such
[More on cpumaps and primitive to manipulate, please check
include/linux/cpumask.h that has more descriptive text.]
cpu_possible_map: Bitmap of possible CPUs that can ever be available in the
cpu_possible_mask: Bitmap of possible CPUs that can ever be available in the
system. This is used to allocate some boot time memory for per_cpu variables
that aren't designed to grow/shrink as CPUs are made available or removed.
Once set during boot time discovery phase, the map is static, i.e no bits
@ -84,13 +84,13 @@ are added or removed anytime. Trimming it accurately for your system needs
upfront can save some boot time memory. See below for how we use heuristics
in x86_64 case to keep this under check.
cpu_online_map: Bitmap of all CPUs currently online. Its set in __cpu_up()
cpu_online_mask: Bitmap of all CPUs currently online. Its set in __cpu_up()
after a cpu is available for kernel scheduling and ready to receive
interrupts from devices. Its cleared when a cpu is brought down using
__cpu_disable(), before which all OS services including interrupts are
migrated to another target CPU.
cpu_present_map: Bitmap of CPUs currently present in the system. Not all
cpu_present_mask: Bitmap of CPUs currently present in the system. Not all
of them may be online. When physical hotplug is processed by the relevant
subsystem (e.g ACPI) can change and new bit either be added or removed
from the map depending on the event is hot-add/hot-remove. There are currently
@ -99,22 +99,22 @@ at which time hotplug is disabled.
You really dont need to manipulate any of the system cpu maps. They should
be read-only for most use. When setting up per-cpu resources almost always use
cpu_possible_map/for_each_possible_cpu() to iterate.
cpu_possible_mask/for_each_possible_cpu() to iterate.
Never use anything other than cpumask_t to represent bitmap of CPUs.
#include <linux/cpumask.h>
for_each_possible_cpu - Iterate over cpu_possible_map
for_each_online_cpu - Iterate over cpu_online_map
for_each_present_cpu - Iterate over cpu_present_map
for_each_possible_cpu - Iterate over cpu_possible_mask
for_each_online_cpu - Iterate over cpu_online_mask
for_each_present_cpu - Iterate over cpu_present_mask
for_each_cpu_mask(x,mask) - Iterate over some random collection of cpu mask.
#include <linux/cpu.h>
get_online_cpus() and put_online_cpus():
The above calls are used to inhibit cpu hotplug operations. While the
cpu_hotplug.refcount is non zero, the cpu_online_map will not change.
cpu_hotplug.refcount is non zero, the cpu_online_mask will not change.
If you merely need to avoid cpus going away, you could also use
preempt_disable() and preempt_enable() for those sections.
Just remember the critical section cannot call any

5
Documentation/cpuidle/sysfs.txt
View File

@ -36,6 +36,7 @@ drwxr-xr-x 2 root root 0 Feb 8 10:42 state3
/sys/devices/system/cpu/cpu0/cpuidle/state0:
total 0
-r--r--r-- 1 root root 4096 Feb 8 10:42 desc
-rw-r--r-- 1 root root 4096 Feb 8 10:42 disable
-r--r--r-- 1 root root 4096 Feb 8 10:42 latency
-r--r--r-- 1 root root 4096 Feb 8 10:42 name
-r--r--r-- 1 root root 4096 Feb 8 10:42 power
@ -45,6 +46,7 @@ total 0
/sys/devices/system/cpu/cpu0/cpuidle/state1:
total 0
-r--r--r-- 1 root root 4096 Feb 8 10:42 desc
-rw-r--r-- 1 root root 4096 Feb 8 10:42 disable
-r--r--r-- 1 root root 4096 Feb 8 10:42 latency
-r--r--r-- 1 root root 4096 Feb 8 10:42 name
-r--r--r-- 1 root root 4096 Feb 8 10:42 power
@ -54,6 +56,7 @@ total 0
/sys/devices/system/cpu/cpu0/cpuidle/state2:
total 0
-r--r--r-- 1 root root 4096 Feb 8 10:42 desc
-rw-r--r-- 1 root root 4096 Feb 8 10:42 disable
-r--r--r-- 1 root root 4096 Feb 8 10:42 latency
-r--r--r-- 1 root root 4096 Feb 8 10:42 name
-r--r--r-- 1 root root 4096 Feb 8 10:42 power
@ -63,6 +66,7 @@ total 0
/sys/devices/system/cpu/cpu0/cpuidle/state3:
total 0
-r--r--r-- 1 root root 4096 Feb 8 10:42 desc
-rw-r--r-- 1 root root 4096 Feb 8 10:42 disable
-r--r--r-- 1 root root 4096 Feb 8 10:42 latency
-r--r--r-- 1 root root 4096 Feb 8 10:42 name
-r--r--r-- 1 root root 4096 Feb 8 10:42 power
@ -72,6 +76,7 @@ total 0
* desc : Small description about the idle state (string)
* disable : Option to disable this idle state (bool)
* latency : Latency to exit out of this idle state (in microseconds)
* name : Name of the idle state (string)
* power : Power consumed while in this idle state (in milliwatts)

65
Documentation/device-mapper/thin-provisioning.txt
View File

@ -75,10 +75,12 @@ less sharing than average you'll need a larger-than-average metadata device.
As a guide, we suggest you calculate the number of bytes to use in the
metadata device as 48 * $data_dev_size / $data_block_size but round it up
to 2MB if the answer is smaller. The largest size supported is 16GB.
to 2MB if the answer is smaller. If you're creating large numbers of
snapshots which are recording large amounts of change, you may find you
need to increase this.
If you're creating large numbers of snapshots which are recording large
amounts of change, you may need find you need to increase this.
The largest size supported is 16GB: If the device is larger,
a warning will be issued and the excess space will not be used.
Reloading a pool table
----------------------
@ -167,6 +169,38 @@ ii) Using an internal snapshot.
dmsetup create snap --table "0 2097152 thin /dev/mapper/pool 1"
External snapshots
------------------
You can use an external _read only_ device as an origin for a
thinly-provisioned volume. Any read to an unprovisioned area of the
thin device will be passed through to the origin. Writes trigger
the allocation of new blocks as usual.
One use case for this is VM hosts that want to run guests on
thinly-provisioned volumes but have the base image on another device
(possibly shared between many VMs).
You must not write to the origin device if you use this technique!
Of course, you may write to the thin device and take internal snapshots
of the thin volume.
i) Creating a snapshot of an external device
This is the same as creating a thin device.
You don't mention the origin at this stage.
dmsetup message /dev/mapper/pool 0 "create_thin 0"
ii) Using a snapshot of an external device.
Append an extra parameter to the thin target specifying the origin:
dmsetup create snap --table "0 2097152 thin /dev/mapper/pool 0 /dev/image"
N.B. All descendants (internal snapshots) of this snapshot require the
same extra origin parameter.
Deactivation
------------
@ -189,7 +223,13 @@ i) Constructor
<low water mark (blocks)> [<number of feature args> [<arg>]*]
Optional feature arguments:
- 'skip_block_zeroing': skips the zeroing of newly-provisioned blocks.
skip_block_zeroing: Skip the zeroing of newly-provisioned blocks.
ignore_discard: Disable discard support.
no_discard_passdown: Don't pass discards down to the underlying
data device, but just remove the mapping.
Data block size must be between 64KB (128 sectors) and 1GB
(2097152 sectors) inclusive.
@ -237,16 +277,6 @@ iii) Messages
Deletes a thin device. Irreversible.
trim <dev id> <new size in sectors>
Delete mappings from the end of a thin device. Irreversible.
You might want to use this if you're reducing the size of
your thinly-provisioned device. In many cases, due to the
sharing of blocks between devices, it is not possible to
determine in advance how much space 'trim' will release. (In
future a userspace tool might be able to perform this
calculation.)
set_transaction_id <current id> <new id>
Userland volume managers, such as LVM, need a way to
@ -262,7 +292,7 @@ iii) Messages
i) Constructor
thin <pool dev> <dev id>
thin <pool dev> <dev id> [<external origin dev>]
pool dev:
the thin-pool device, e.g. /dev/mapper/my_pool or 253:0
@ -271,6 +301,11 @@ i) Constructor
the internal device identifier of the device to be
activated.
external origin dev:
an optional block device outside the pool to be treated as a
read-only snapshot origin: reads to unprovisioned areas of the
thin target will be mapped to this device.
The pool doesn't store any size against the thin devices. If you
load a thin target that is smaller than you've been using previously,
then you'll have no access to blocks mapped beyond the end. If you

194
Documentation/device-mapper/verity.txt Normal file
View File

@ -0,0 +1,194 @@
dm-verity
==========
Device-Mapper's "verity" target provides transparent integrity checking of
block devices using a cryptographic digest provided by the kernel crypto API.
This target is read-only.
Construction Parameters
=======================
<version> <dev> <hash_dev> <hash_start>
<data_block_size> <hash_block_size>
<num_data_blocks> <hash_start_block>
<algorithm> <digest> <salt>
<version>
This is the version number of the on-disk format.
0 is the original format used in the Chromium OS.
The salt is appended when hashing, digests are stored continuously and
the rest of the block is padded with zeros.
1 is the current format that should be used for new devices.
The salt is prepended when hashing and each digest is
padded with zeros to the power of two.
<dev>
This is the device containing the data the integrity of which needs to be
checked. It may be specified as a path, like /dev/sdaX, or a device number,
<major>:<minor>.
<hash_dev>
This is the device that that supplies the hash tree data. It may be
specified similarly to the device path and may be the same device. If the
same device is used, the hash_start should be outside of the dm-verity
configured device size.
<data_block_size>
The block size on a data device. Each block corresponds to one digest on
the hash device.
<hash_block_size>
The size of a hash block.
<num_data_blocks>
The number of data blocks on the data device. Additional blocks are
inaccessible. You can place hashes to the same partition as data, in this
case hashes are placed after <num_data_blocks>.
<hash_start_block>
This is the offset, in <hash_block_size>-blocks, from the start of hash_dev
to the root block of the hash tree.
<algorithm>
The cryptographic hash algorithm used for this device. This should
be the name of the algorithm, like "sha1".
<digest>
The hexadecimal encoding of the cryptographic hash of the root hash block
and the salt. This hash should be trusted as there is no other authenticity
beyond this point.
<salt>
The hexadecimal encoding of the salt value.
Theory of operation
===================
dm-verity is meant to be setup as part of a verified boot path. This
may be anything ranging from a boot using tboot or trustedgrub to just
booting from a known-good device (like a USB drive or CD).
When a dm-verity device is configured, it is expected that the caller
has been authenticated in some way (cryptographic signatures, etc).
After instantiation, all hashes will be verified on-demand during
disk access. If they cannot be verified up to the root node of the
tree, the root hash, then the I/O will fail. This should identify
tampering with any data on the device and the hash data.
Cryptographic hashes are used to assert the integrity of the device on a
per-block basis. This allows for a lightweight hash computation on first read
into the page cache. Block hashes are stored linearly-aligned to the nearest
block the size of a page.
Hash Tree
---------
Each node in the tree is a cryptographic hash. If it is a leaf node, the hash
is of some block data on disk. If it is an intermediary node, then the hash is
of a number of child nodes.
Each entry in the tree is a collection of neighboring nodes that fit in one
block. The number is determined based on block_size and the size of the
selected cryptographic digest algorithm. The hashes are linearly-ordered in
this entry and any unaligned trailing space is ignored but included when
calculating the parent node.
The tree looks something like:
alg = sha256, num_blocks = 32768, block_size = 4096
[ root ]
/ . . . \
[entry_0] [entry_1]
/ . . . \ . . . \
[entry_0_0] . . . [entry_0_127] . . . . [entry_1_127]
/ ... \ / . . . \ / \
blk_0 ... blk_127 blk_16256 blk_16383 blk_32640 . . . blk_32767
On-disk format
==============
Below is the recommended on-disk format. The verity kernel code does not
read the on-disk header. It only reads the hash blocks which directly
follow the header. It is expected that a user-space tool will verify the
integrity of the verity_header and then call dmsetup with the correct
parameters. Alternatively, the header can be omitted and the dmsetup
parameters can be passed via the kernel command-line in a rooted chain
of trust where the command-line is verified.
The on-disk format is especially useful in cases where the hash blocks
are on a separate partition. The magic number allows easy identification
of the partition contents. Alternatively, the hash blocks can be stored
in the same partition as the data to be verified. In such a configuration
the filesystem on the partition would be sized a little smaller than
the full-partition, leaving room for the hash blocks.
struct superblock {
uint8_t signature[8]
"verity\0\0";
uint8_t version;
1 - current format
uint8_t data_block_bits;
log2(data block size)
uint8_t hash_block_bits;
log2(hash block size)
uint8_t pad1[1];
zero padding
uint16_t salt_size;
big-endian salt size
uint8_t pad2[2];
zero padding
uint32_t data_blocks_hi;
big-endian high 32 bits of the 64-bit number of data blocks
uint32_t data_blocks_lo;
big-endian low 32 bits of the 64-bit number of data blocks
uint8_t algorithm[16];
cryptographic algorithm
uint8_t salt[384];
salt (the salt size is specified above)
uint8_t pad3[88];
zero padding to 512-byte boundary
}
Directly following the header (and with sector number padded to the next hash
block boundary) are the hash blocks which are stored a depth at a time
(starting from the root), sorted in order of increasing index.
Status
======
V (for Valid) is returned if every check performed so far was valid.
If any check failed, C (for Corruption) is returned.
Example
=======
Setup a device:
dmsetup create vroot --table \
"0 2097152 "\
"verity 1 /dev/sda1 /dev/sda2 4096 4096 2097152 1 "\
"4392712ba01368efdf14b05c76f9e4df0d53664630b5d48632ed17a137f39076 "\
"1234000000000000000000000000000000000000000000000000000000000000"
A command line tool veritysetup is available to compute or verify
the hash tree or activate the kernel driver. This is available from
the LVM2 upstream repository and may be supplied as a package called
device-mapper-verity-tools:
git://sources.redhat.com/git/lvm2
http://sourceware.org/git/?p=lvm2.git
http://sourceware.org/cgi-bin/cvsweb.cgi/LVM2/verity?cvsroot=lvm2
veritysetup -a vroot /dev/sda1 /dev/sda2 \
4392712ba01368efdf14b05c76f9e4df0d53664630b5d48632ed17a137f39076

60
Documentation/devicetree/bindings/arm/atmel-at91.txt
View File

@ -30,3 +30,63 @@ One interrupt per TC channel in a TC block:
reg = <0xfffdc000 0x100>;
interrupts = <26 4 27 4 28 4>;
};
RSTC Reset Controller required properties:
- compatible: Should be "atmel,<chip>-rstc".
<chip> can be "at91sam9260" or "at91sam9g45"
- reg: Should contain registers location and length
Example:
rstc@fffffd00 {
compatible = "atmel,at91sam9260-rstc";
reg = <0xfffffd00 0x10>;
};
RAMC SDRAM/DDR Controller required properties:
- compatible: Should be "atmel,at91sam9260-sdramc",
"atmel,at91sam9g45-ddramc",
- reg: Should contain registers location and length
For at91sam9263 and at91sam9g45 you must specify 2 entries.
Examples:
ramc0: ramc@ffffe800 {
compatible = "atmel,at91sam9g45-ddramc";
reg = <0xffffe800 0x200>;
};
ramc0: ramc@ffffe400 {
compatible = "atmel,at91sam9g45-ddramc";
reg = <0xffffe400 0x200
0xffffe600 0x200>;
};
SHDWC Shutdown Controller
required properties:
- compatible: Should be "atmel,<chip>-shdwc".
<chip> can be "at91sam9260", "at91sam9rl" or "at91sam9x5".
- reg: Should contain registers location and length
optional properties:
- atmel,wakeup-mode: String, operation mode of the wakeup mode.
Supported values are: "none", "high", "low", "any".
- atmel,wakeup-counter: Counter on Wake-up 0 (between 0x0 and 0xf).
optional at91sam9260 properties:
- atmel,wakeup-rtt-timer: boolean to enable Real-time Timer Wake-up.
optional at91sam9rl properties:
- atmel,wakeup-rtc-timer: boolean to enable Real-time Clock Wake-up.
- atmel,wakeup-rtt-timer: boolean to enable Real-time Timer Wake-up.
optional at91sam9x5 properties:
- atmel,wakeup-rtc-timer: boolean to enable Real-time Clock Wake-up.
Example:
rstc@fffffd00 {
compatible = "atmel,at91sam9260-rstc";
reg = <0xfffffd00 0x10>;
};

11
Documentation/devicetree/bindings/arm/atmel-pmc.txt Normal file
View File

@ -0,0 +1,11 @@
* Power Management Controller (PMC)
Required properties:
- compatible: Should be "atmel,at91rm9200-pmc"
- reg: Should contain PMC registers location and length
Examples:
pmc: pmc@fffffc00 {
compatible = "atmel,at91rm9200-pmc";
reg = <0xfffffc00 0x100>;
};

8
Documentation/devicetree/bindings/arm/spear.txt Normal file
View File

@ -0,0 +1,8 @@
ST SPEAr Platforms Device Tree Bindings
---------------------------------------
Boards with the ST SPEAr600 SoC shall have the following properties:
Required root node property:
compatible = "st,spear600";

36
Documentation/devicetree/bindings/gpio/gpio-omap.txt Normal file
View File

@ -0,0 +1,36 @@
OMAP GPIO controller bindings
Required properties:
- compatible:
- "ti,omap2-gpio" for OMAP2 controllers
- "ti,omap3-gpio" for OMAP3 controllers
- "ti,omap4-gpio" for OMAP4 controllers
- #gpio-cells : Should be two.
- first cell is the pin number
- second cell is used to specify optional parameters (unused)
- gpio-controller : Marks the device node as a GPIO controller.
- #interrupt-cells : Should be 2.
- interrupt-controller: Mark the device node as an interrupt controller
The first cell is the GPIO number.
The second cell is used to specify flags:
bits[3:0] trigger type and level flags:
1 = low-to-high edge triggered.
2 = high-to-low edge triggered.
4 = active high level-sensitive.
8 = active low level-sensitive.
OMAP specific properties:
- ti,hwmods: Name of the hwmod associated to the GPIO:
"gpio<X>", <X> being the 1-based instance number from the HW spec
Example:
gpio4: gpio4 {
compatible = "ti,omap4-gpio";
ti,hwmods = "gpio4";
#gpio-cells = <2>;
gpio-controller;
#interrupt-cells = <2>;
interrupt-controller;
};

23
Documentation/devicetree/bindings/gpio/gpio-twl4030.txt Normal file
View File

@ -0,0 +1,23 @@
twl4030 GPIO controller bindings
Required properties:
- compatible:
- "ti,twl4030-gpio" for twl4030 GPIO controller
- #gpio-cells : Should be two.
- first cell is the pin number
- second cell is used to specify optional parameters (unused)
- gpio-controller : Marks the device node as a GPIO controller.
- #interrupt-cells : Should be 2.
- interrupt-controller: Mark the device node as an interrupt controller
The first cell is the GPIO number.
The second cell is not used.
Example:
twl_gpio: gpio {
compatible = "ti,twl4030-gpio";
#gpio-cells = <2>;
gpio-controller;
#interrupt-cells = <2>;
interrupt-controller;
};

32
Documentation/devicetree/bindings/gpio/gpio_i2c.txt Normal file
View File

@ -0,0 +1,32 @@
Device-Tree bindings for i2c gpio driver
Required properties:
- compatible = "i2c-gpio";
- gpios: sda and scl gpio
Optional properties:
- i2c-gpio,sda-open-drain: sda as open drain
- i2c-gpio,scl-open-drain: scl as open drain
- i2c-gpio,scl-output-only: scl as output only
- i2c-gpio,delay-us: delay between GPIO operations (may depend on each platform)
- i2c-gpio,timeout-ms: timeout to get data
Example nodes:
i2c@0 {
compatible = "i2c-gpio";
gpios = <&pioA 23 0 /* sda */
&pioA 24 0 /* scl */
>;
i2c-gpio,sda-open-drain;
i2c-gpio,scl-open-drain;
i2c-gpio,delay-us = <2>; /* ~100 kHz */
#address-cells = <1>;
#size-cells = <0>;
rv3029c2@56 {
compatible = "rv3029c2";
reg = <0x56>;
};
};

48
Documentation/devicetree/bindings/gpio/sodaville.txt Normal file
View File

@ -0,0 +1,48 @@
GPIO controller on CE4100 / Sodaville SoCs
==========================================
The bindings for CE4100's GPIO controller match the generic description
which is covered by the gpio.txt file in this folder.
The only additional property is the intel,muxctl property which holds the
value which is written into the MUXCNTL register.
There is no compatible property for now because the driver is probed via
PCI id (vendor 0x8086 device 0x2e67).
The interrupt specifier consists of two cells encoded as follows:
- <1st cell>: The interrupt-number that identifies the interrupt source.
- <2nd cell>: The level-sense information, encoded as follows:
4 - active high level-sensitive
8 - active low level-sensitive
Example of the GPIO device and one user:
pcigpio: gpio@b,1 {
/* two cells for GPIO and interrupt */
#gpio-cells = <2>;
#interrupt-cells = <2>;
compatible = "pci8086,2e67.2",
"pci8086,2e67",
"pciclassff0000",
"pciclassff00";
reg = <0x15900 0x0 0x0 0x0 0x0>;
/* Interrupt line of the gpio device */
interrupts = <15 1>;
/* It is an interrupt and GPIO controller itself */
interrupt-controller;
gpio-controller;
intel,muxctl = <0>;
};
testuser@20 {
compatible = "example,testuser";
/* User the 11th GPIO line as an active high triggered
* level interrupt
*/
interrupts = <11 8>;
interrupt-parent = <&pcigpio>;
/* Use this GPIO also with the gpio functions */
gpios = <&pcigpio 11 0>;
};

33
Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt Normal file
View File

@ -0,0 +1,33 @@
* TI Highspeed MMC host controller for OMAP
The Highspeed MMC Host Controller on TI OMAP family
provides an interface for MMC, SD, and SDIO types of memory cards.
Required properties:
- compatible:
Should be "ti,omap2-hsmmc", for OMAP2 controllers
Should be "ti,omap3-hsmmc", for OMAP3 controllers
Should be "ti,omap4-hsmmc", for OMAP4 controllers
- ti,hwmods: Must be "mmc<n>", n is controller instance starting 1
- reg : should contain hsmmc registers location and length
Optional properties:
ti,dual-volt: boolean, supports dual voltage cards
<supply-name>-supply: phandle to the regulator device tree node
"supply-name" examples are "vmmc", "vmmc_aux" etc
ti,bus-width: Number of data lines, default assumed is 1 if the property is missing.
cd-gpios: GPIOs for card detection
wp-gpios: GPIOs for write protection
ti,non-removable: non-removable slot (like eMMC)
ti,needs-special-reset: Requires a special softreset sequence
Example:
mmc1: mmc@0x4809c000 {
compatible = "ti,omap4-hsmmc";
reg = <0x4809c000 0x400>;
ti,hwmods = "mmc1";
ti,dual-volt;
ti,bus-width = <4>;
vmmc-supply = <&vmmc>; /* phandle to regulator node */
ti,non-removable;
};

4
Documentation/devicetree/bindings/mtd/arm-versatile.txt
View File

@ -4,5 +4,5 @@ Required properties:
- compatible : must be "arm,versatile-flash";
- bank-width : width in bytes of flash interface.
Optional properties:
- Subnode partition map from mtd flash binding
The device tree may optionally contain sub-nodes describing partitions of the
address space. See partition.txt for more detail.

3
Documentation/devicetree/bindings/mtd/atmel-dataflash.txt
View File

@ -3,6 +3,9 @@
Required properties:
- compatible : "atmel,<model>", "atmel,<series>", "atmel,dataflash".
The device tree may optionally contain sub-nodes describing partitions of the
address space. See partition.txt for more detail.
Example:
flash@1 {

41
Documentation/devicetree/bindings/mtd/atmel-nand.txt Normal file
View File

@ -0,0 +1,41 @@
Atmel NAND flash
Required properties:
- compatible : "atmel,at91rm9200-nand".
- reg : should specify localbus address and size used for the chip,
and if availlable the ECC.
- atmel,nand-addr-offset : offset for the address latch.
- atmel,nand-cmd-offset : offset for the command latch.
- #address-cells, #size-cells : Must be present if the device has sub-nodes
representing partitions.
- gpios : specifies the gpio pins to control the NAND device. detect is an
optional gpio and may be set to 0 if not present.
Optional properties:
- nand-ecc-mode : String, operation mode of the NAND ecc mode, soft by default.
Supported values are: "none", "soft", "hw", "hw_syndrome", "hw_oob_first",
"soft_bch".
- nand-bus-width : 8 or 16 bus width if not present 8
- nand-on-flash-bbt: boolean to enable on flash bbt option if not present false
Examples:
nand0: nand@40000000,0 {
compatible = "atmel,at91rm9200-nand";
#address-cells = <1>;
#size-cells = <1>;
reg = <0x40000000 0x10000000
0xffffe800 0x200
>;
atmel,nand-addr-offset = <21>; /* ale */
atmel,nand-cmd-offset = <22>; /* cle */
nand-on-flash-bbt;
nand-ecc-mode = "soft";
gpios = <&pioC 13 0 /* rdy */
&pioC 14 0 /* nce */
0 /* cd */
>;
partition@0 {
...
};
};

4
Documentation/devicetree/bindings/mtd/fsl-upm-nand.txt
View File

@ -19,6 +19,10 @@ Optional properties:
read registers (tR). Required if property "gpios" is not used
(R/B# pins not connected).
Each flash chip described may optionally contain additional sub-nodes
describing partitions of the address space. See partition.txt for more
detail.
Examples:
upm@1,0 {

33
Documentation/devicetree/bindings/mtd/fsmc-nand.txt Normal file
View File

@ -0,0 +1,33 @@
* FSMC NAND
Required properties:
- compatible : "st,spear600-fsmc-nand"
- reg : Address range of the mtd chip
- reg-names: Should contain the reg names "fsmc_regs" and "nand_data"
- st,ale-off : Chip specific offset to ALE
- st,cle-off : Chip specific offset to CLE
Optional properties:
- bank-width : Width (in bytes) of the device. If not present, the width
defaults to 1 byte
- nand-skip-bbtscan: Indicates the the BBT scanning should be skipped
Example:
fsmc: flash@d1800000 {
compatible = "st,spear600-fsmc-nand";
#address-cells = <1>;
#size-cells = <1>;
reg = <0xd1800000 0x1000 /* FSMC Register */
0xd2000000 0x4000>; /* NAND Base */
reg-names = "fsmc_regs", "nand_data";
st,ale-off = <0x20000>;
st,cle-off = <0x10000>;
bank-width = <1>;
nand-skip-bbtscan;
partition@0 {
...
};
};

3
Documentation/devicetree/bindings/mtd/gpio-control-nand.txt
View File

@ -25,6 +25,9 @@ Optional properties:
GPIO state and before and after command byte writes, this register will be
read to ensure that the GPIO accesses have completed.
The device tree may optionally contain sub-nodes describing partitions of the
address space. See partition.txt for more detail.
Examples:
gpio-nand@1,0 {

23
Documentation/devicetree/bindings/mtd/mtd-physmap.txt
View File

@ -23,27 +23,8 @@ are defined:
- vendor-id : Contains the flash chip's vendor id (1 byte).
- device-id : Contains the flash chip's device id (1 byte).
In addition to the information on the mtd bank itself, the
device tree may optionally contain additional information
describing partitions of the address space. This can be
used on platforms which have strong conventions about which
portions of a flash are used for what purposes, but which don't
use an on-flash partition table such as RedBoot.
Each partition is represented as a sub-node of the mtd device.
Each node's name represents the name of the corresponding
partition of the mtd device.
Flash partitions
- reg : The partition's offset and size within the mtd bank.
- label : (optional) The label / name for this partition.
If omitted, the label is taken from the node name (excluding
the unit address).
- read-only : (optional) This parameter, if present, is a hint to
Linux that this partition should only be mounted
read-only. This is usually used for flash partitions
containing early-boot firmware images or data which should not
be clobbered.
The device tree may optionally contain sub-nodes describing partitions of the
address space. See partition.txt for more detail.
Example:

7
Documentation/devicetree/bindings/mtd/nand.txt Normal file
View File

@ -0,0 +1,7 @@
* MTD generic binding
- nand-ecc-mode : String, operation mode of the NAND ecc mode.
Supported values are: "none", "soft", "hw", "hw_syndrome", "hw_oob_first",
"soft_bch".
- nand-bus-width : 8 or 16 bus width if not present 8
- nand-on-flash-bbt: boolean to enable on flash bbt option if not present false

38
Documentation/devicetree/bindings/mtd/partition.txt Normal file
View File

@ -0,0 +1,38 @@
Representing flash partitions in devicetree
Partitions can be represented by sub-nodes of an mtd device. This can be used
on platforms which have strong conventions about which portions of a flash are
used for what purposes, but which don't use an on-flash partition table such
as RedBoot.
#address-cells & #size-cells must both be present in the mtd device and be
equal to 1.
Required properties:
- reg : The partition's offset and size within the mtd bank.
Optional properties:
- label : The label / name for this partition. If omitted, the label is taken
from the node name (excluding the unit address).
- read-only : This parameter, if present, is a hint to Linux that this
partition should only be mounted read-only. This is usually used for flash
partitions containing early-boot firmware images or data which should not be
clobbered.
Examples:
flash@0 {
#address-cells = <1>;
#size-cells = <1>;
partition@0 {
label = "u-boot";
reg = <0x0000000 0x100000>;
read-only;
};
uimage@100000 {
reg = <0x0100000 0x200000>;
};
];

31
Documentation/devicetree/bindings/mtd/spear_smi.txt Normal file
View File

@ -0,0 +1,31 @@
* SPEAr SMI
Required properties:
- compatible : "st,spear600-smi"
- reg : Address range of the mtd chip
- #address-cells, #size-cells : Must be present if the device has sub-nodes
representing partitions.
- interrupt-parent: Should be the phandle for the interrupt controller
that services interrupts for this device
- interrupts: Should contain the STMMAC interrupts
- clock-rate : Functional clock rate of SMI in Hz
Optional properties:
- st,smi-fast-mode : Flash supports read in fast mode
Example:
smi: flash@fc000000 {
compatible = "st,spear600-smi";
#address-cells = <1>;
#size-cells = <1>;
reg = <0xfc000000 0x1000>;
interrupt-parent = <&vic1>;
interrupts = <12>;
clock-rate = <50000000>; /* 50MHz */
flash@f8000000 {
st,smi-fast-mode;
...
};
};

18
Documentation/devicetree/bindings/power_supply/max17042_battery.txt Normal file
View File

@ -0,0 +1,18 @@
max17042_battery
~~~~~~~~~~~~~~~~
Required properties :
- compatible : "maxim,max17042"
Optional properties :
- maxim,rsns-microohm : Resistance of rsns resistor in micro Ohms
(datasheet-recommended value is 10000).
Defining this property enables current-sense functionality.
Example:
battery-charger@36 {
compatible = "maxim,max17042";
reg = <0x36>;
maxim,rsns-microohm = <10000>;
};

29
Documentation/devicetree/bindings/regulator/anatop-regulator.txt Normal file
View File

@ -0,0 +1,29 @@
Anatop Voltage regulators
Required properties:
- compatible: Must be "fsl,anatop-regulator"
- anatop-reg-offset: Anatop MFD register offset
- anatop-vol-bit-shift: Bit shift for the register
- anatop-vol-bit-width: Number of bits used in the register
- anatop-min-bit-val: Minimum value of this register
- anatop-min-voltage: Minimum voltage of this regulator
- anatop-max-voltage: Maximum voltage of this regulator
Any property defined as part of the core regulator
binding, defined in regulator.txt, can also be used.
Example:
regulator-vddpu {
compatible = "fsl,anatop-regulator";
regulator-name = "vddpu";
regulator-min-microvolt = <725000>;
regulator-max-microvolt = <1300000>;
regulator-always-on;
anatop-reg-offset = <0x140>;
anatop-vol-bit-shift = <9>;
anatop-vol-bit-width = <5>;
anatop-min-bit-val = <1>;
anatop-min-voltage = <725000>;
anatop-max-voltage = <1300000>;
};

49
Documentation/devicetree/bindings/usb/atmel-usb.txt Normal file
View File

@ -0,0 +1,49 @@
Atmel SOC USB controllers
OHCI
Required properties:
- compatible: Should be "atmel,at91rm9200-ohci" for USB controllers
used in host mode.
- num-ports: Number of ports.
- atmel,vbus-gpio: If present, specifies a gpio that needs to be
activated for the bus to be powered.
- atmel,oc-gpio: If present, specifies a gpio that needs to be
activated for the overcurrent detection.
usb0: ohci@00500000 {
compatible = "atmel,at91rm9200-ohci", "usb-ohci";
reg = <0x00500000 0x100000>;
interrupts = <20 4>;
num-ports = <2>;
};
EHCI
Required properties:
- compatible: Should be "atmel,at91sam9g45-ehci" for USB controllers
used in host mode.
usb1: ehci@00800000 {
compatible = "atmel,at91sam9g45-ehci", "usb-ehci";
reg = <0x00800000 0x100000>;
interrupts = <22 4>;
};
AT91 USB device controller
Required properties:
- compatible: Should be "atmel,at91rm9200-udc"
- reg: Address and length of the register set for the device
- interrupts: Should contain macb interrupt
Optional properties:
- atmel,vbus-gpio: If present, specifies a gpio that needs to be
activated for the bus to be powered.
usb1: gadget@fffa4000 {
compatible = "atmel,at91rm9200-udc";
reg = <0xfffa4000 0x4000>;
interrupts = <10 4>;
atmel,vbus-gpio = <&pioC 5 0>;
};

13
Documentation/devicetree/bindings/usb/tegra-usb.txt
View File

@ -11,3 +11,16 @@ Required properties :
- phy_type : Should be one of "ulpi" or "utmi".
- nvidia,vbus-gpio : If present, specifies a gpio that needs to be
activated for the bus to be powered.
Optional properties:
- dr_mode : dual role mode. Indicates the working mode for
nvidia,tegra20-ehci compatible controllers. Can be "host", "peripheral",
or "otg". Default to "host" if not defined for backward compatibility.
host means this is a host controller
peripheral means it is device controller
otg means it can operate as either ("on the go")
- nvidia,has-legacy-mode : boolean indicates whether this controller can
operate in legacy mode (as APX 2500 / 2600). In legacy mode some
registers are accessed through the APB_MISC base address instead of
the USB controller. Since this is a legacy issue it probably does not
warrant a compatible string of its own.

412
Documentation/devicetree/usage-model.txt Normal file
View File

@ -0,0 +1,412 @@
Linux and the Device Tree
-------------------------
The Linux usage model for device tree data
Author: Grant Likely <grant.likely@secretlab.ca>
This article describes how Linux uses the device tree. An overview of
the device tree data format can be found on the device tree usage page
at devicetree.org[1].
[1] http://devicetree.org/Device_Tree_Usage
The "Open Firmware Device Tree", or simply Device Tree (DT), is a data
structure and language for describing hardware. More specifically, it
is a description of hardware that is readable by an operating system
so that the operating system doesn't need to hard code details of the
machine.
Structurally, the DT is a tree, or acyclic graph with named nodes, and
nodes may have an arbitrary number of named properties encapsulating
arbitrary data. A mechanism also exists to create arbitrary
links from one node to another outside of the natural tree structure.
Conceptually, a common set of usage conventions, called 'bindings',
is defined for how data should appear in the tree to describe typical
hardware characteristics including data busses, interrupt lines, GPIO
connections, and peripheral devices.
As much as possible, hardware is described using existing bindings to
maximize use of existing support code, but since property and node
names are simply text strings, it is easy to extend existing bindings
or create new ones by defining new nodes and properties. Be wary,
however, of creating a new binding without first doing some homework
about what already exists. There are currently two different,
incompatible, bindings for i2c busses that came about because the new
binding was created without first investigating how i2c devices were
already being enumerated in existing systems.
1. History
----------
The DT was originally created by Open Firmware as part of the
communication method for passing data from Open Firmware to a client
program (like to an operating system). An operating system used the
Device Tree to discover the topology of the hardware at runtime, and
thereby support a majority of available hardware without hard coded
information (assuming drivers were available for all devices).
Since Open Firmware is commonly used on PowerPC and SPARC platforms,
the Linux support for those architectures has for a long time used the
Device Tree.
In 2005, when PowerPC Linux began a major cleanup and to merge 32-bit
and 64-bit support, the decision was made to require DT support on all
powerpc platforms, regardless of whether or not they used Open
Firmware. To do this, a DT representation called the Flattened Device
Tree (FDT) was created which could be passed to the kernel as a binary
blob without requiring a real Open Firmware implementation. U-Boot,
kexec, and other bootloaders were modified to support both passing a
Device Tree Binary (dtb) and to modify a dtb at boot time. DT was
also added to the PowerPC boot wrapper (arch/powerpc/boot/*) so that
a dtb could be wrapped up with the kernel image to support booting
existing non-DT aware firmware.
Some time later, FDT infrastructure was generalized to be usable by
all architectures. At the time of this writing, 6 mainlined
architectures (arm, microblaze, mips, powerpc, sparc, and x86) and 1
out of mainline (nios) have some level of DT support.
2. Data Model
-------------
If you haven't already read the Device Tree Usage[1] page,
then go read it now. It's okay, I'll wait....
2.1 High Level View
-------------------
The most important thing to understand is that the DT is simply a data
structure that describes the hardware. There is nothing magical about
it, and it doesn't magically make all hardware configuration problems
go away. What it does do is provide a language for decoupling the
hardware configuration from the board and device driver support in the
Linux kernel (or any other operating system for that matter). Using
it allows board and device support to become data driven; to make
setup decisions based on data passed into the kernel instead of on
per-machine hard coded selections.
Ideally, data driven platform setup should result in less code
duplication and make it easier to support a wide range of hardware
with a single kernel image.
Linux uses DT data for three major purposes:
1) platform identification,
2) runtime configuration, and
3) device population.
2.2 Platform Identification
---------------------------
First and foremost, the kernel will use data in the DT to identify the
specific machine. In a perfect world, the specific platform shouldn't
matter to the kernel because all platform details would be described
perfectly by the device tree in a consistent and reliable manner.
Hardware is not perfect though, and so the kernel must identify the
machine during early boot so that it has the opportunity to run
machine-specific fixups.
In the majority of cases, the machine identity is irrelevant, and the
kernel will instead select setup code based on the machine's core
CPU or SoC. On ARM for example, setup_arch() in
arch/arm/kernel/setup.c will call setup_machine_fdt() in
arch/arm/kernel/devicetree.c which searches through the machine_desc
table and selects the machine_desc which best matches the device tree
data. It determines the best match by looking at the 'compatible'
property in the root device tree node, and comparing it with the
dt_compat list in struct machine_desc.
The 'compatible' property contains a sorted list of strings starting
with the exact name of the machine, followed by an optional list of
boards it is compatible with sorted from most compatible to least. For
example, the root compatible properties for the TI BeagleBoard and its
successor, the BeagleBoard xM board might look like:
compatible = "ti,omap3-beagleboard", "ti,omap3450", "ti,omap3";
compatible = "ti,omap3-beagleboard-xm", "ti,omap3450", "ti,omap3";
Where "ti,omap3-beagleboard-xm" specifies the exact model, it also
claims that it compatible with the OMAP 3450 SoC, and the omap3 family
of SoCs in general. You'll notice that the list is sorted from most
specific (exact board) to least specific (SoC family).
Astute readers might point out that the Beagle xM could also claim
compatibility with the original Beagle board. However, one should be
cautioned about doing so at the board level since there is typically a
high level of change from one board to another, even within the same
product line, and it is hard to nail down exactly what is meant when one
board claims to be compatible with another. For the top level, it is
better to err on the side of caution and not claim one board is
compatible with another. The notable exception would be when one
board is a carrier for another, such as a CPU module attached to a
carrier board.
One more note on compatible values. Any string used in a compatible
property must be documented as to what it indicates. Add
documentation for compatible strings in Documentation/devicetree/bindings.
Again on ARM, for each machine_desc, the kernel looks to see if
any of the dt_compat list entries appear in the compatible property.
If one does, then that machine_desc is a candidate for driving the
machine. After searching the entire table of machine_descs,
setup_machine_fdt() returns the 'most compatible' machine_desc based
on which entry in the compatible property each machine_desc matches
against. If no matching machine_desc is found, then it returns NULL.
The reasoning behind this scheme is the observation that in the majority
of cases, a single machine_desc can support a large number of boards
if they all use the same SoC, or same family of SoCs. However,
invariably there will be some exceptions where a specific board will
require special setup code that is not useful in the generic case.
Special cases could be handled by explicitly checking for the
troublesome board(s) in generic setup code, but doing so very quickly
becomes ugly and/or unmaintainable if it is more than just a couple of
cases.
Instead, the compatible list allows a generic machine_desc to provide
support for a wide common set of boards by specifying "less
compatible" value in the dt_compat list. In the example above,
generic board support can claim compatibility with "ti,omap3" or
"ti,omap3450". If a bug was discovered on the original beagleboard
that required special workaround code during early boot, then a new
machine_desc could be added which implements the workarounds and only
matches on "ti,omap3-beagleboard".
PowerPC uses a slightly different scheme where it calls the .probe()
hook from each machine_desc, and the first one returning TRUE is used.
However, this approach does not take into account the priority of the
compatible list, and probably should be avoided for new architecture
support.
2.3 Runtime configuration
-------------------------
In most cases, a DT will be the sole method of communicating data from
firmware to the kernel, so also gets used to pass in runtime and
configuration data like the kernel parameters string and the location
of an initrd image.
Most of this data is contained in the /chosen node, and when booting
Linux it will look something like this:
chosen {
bootargs = "console=ttyS0,115200 loglevel=8";
initrd-start = <0xc8000000>;
initrd-end = <0xc8200000>;
};
The bootargs property contains the kernel arguments, and the initrd-*
properties define the address and size of an initrd blob. The
chosen node may also optionally contain an arbitrary number of
additional properties for platform-specific configuration data.
During early boot, the architecture setup code calls of_scan_flat_dt()
several times with different helper callbacks to parse device tree
data before paging is setup. The of_scan_flat_dt() code scans through
the device tree and uses the helpers to extract information required
during early boot. Typically the early_init_dt_scan_chosen() helper
is used to parse the chosen node including kernel parameters,
early_init_dt_scan_root() to initialize the DT address space model,
and early_init_dt_scan_memory() to determine the size and
location of usable RAM.
On ARM, the function setup_machine_fdt() is responsible for early
scanning of the device tree after selecting the correct machine_desc
that supports the board.
2.4 Device population
---------------------
After the board has been identified, and after the early configuration data
has been parsed, then kernel initialization can proceed in the normal
way. At some point in this process, unflatten_device_tree() is called
to convert the data into a more efficient runtime representation.
This is also when machine-specific setup hooks will get called, like
the machine_desc .init_early(), .init_irq() and .init_machine() hooks
on ARM. The remainder of this section uses examples from the ARM
implementation, but all architectures will do pretty much the same
thing when using a DT.
As can be guessed by the names, .init_early() is used for any machine-
specific setup that needs to be executed early in the boot process,
and .init_irq() is used to set up interrupt handling. Using a DT
doesn't materially change the behaviour of either of these functions.
If a DT is provided, then both .init_early() and .init_irq() are able
to call any of the DT query functions (of_* in include/linux/of*.h) to
get additional data about the platform.
The most interesting hook in the DT context is .init_machine() which
is primarily responsible for populating the Linux device model with
data about the platform. Historically this has been implemented on
embedded platforms by defining a set of static clock structures,
platform_devices, and other data in the board support .c file, and
registering it en-masse in .init_machine(). When DT is used, then
instead of hard coding static devices for each platform, the list of
devices can be obtained by parsing the DT, and allocating device
structures dynamically.
The simplest case is when .init_machine() is only responsible for
registering a block of platform_devices. A platform_device is a concept
used by Linux for memory or I/O mapped devices which cannot be detected
by hardware, and for 'composite' or 'virtual' devices (more on those
later). While there is no 'platform device' terminology for the DT,
platform devices roughly correspond to device nodes at the root of the
tree and children of simple memory mapped bus nodes.
About now is a good time to lay out an example. Here is part of the
device tree for the NVIDIA Tegra board.
/{
compatible = "nvidia,harmony", "nvidia,tegra20";
#address-cells = <1>;
#size-cells = <1>;
interrupt-parent = <&intc>;
chosen { };
aliases { };
memory {
device_type = "memory";
reg = <0x00000000 0x40000000>;
};
soc {
compatible = "nvidia,tegra20-soc", "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges;
intc: interrupt-controller@50041000 {
compatible = "nvidia,tegra20-gic";
interrupt-controller;
#interrupt-cells = <1>;
reg = <0x50041000 0x1000>, < 0x50040100 0x0100 >;
};
serial@70006300 {
compatible = "nvidia,tegra20-uart";
reg = <0x70006300 0x100>;
interrupts = <122>;
};
i2s1: i2s@70002800 {
compatible = "nvidia,tegra20-i2s";
reg = <0x70002800 0x100>;
interrupts = <77>;
codec = <&wm8903>;
};
i2c@7000c000 {
compatible = "nvidia,tegra20-i2c";
#address-cells = <1>;
#size-cells = <0>;
reg = <0x7000c000 0x100>;
interrupts = <70>;
wm8903: codec@1a {
compatible = "wlf,wm8903";
reg = <0x1a>;
interrupts = <347>;
};
};
};
sound {
compatible = "nvidia,harmony-sound";
i2s-controller = <&i2s1>;
i2s-codec = <&wm8903>;
};
};
At .machine_init() time, Tegra board support code will need to look at
this DT and decide which nodes to create platform_devices for.
However, looking at the tree, it is not immediately obvious what kind
of device each node represents, or even if a node represents a device
at all. The /chosen, /aliases, and /memory nodes are informational
nodes that don't describe devices (although arguably memory could be
considered a device). The children of the /soc node are memory mapped
devices, but the codec@1a is an i2c device, and the sound node
represents not a device, but rather how other devices are connected
together to create the audio subsystem. I know what each device is
because I'm familiar with the board design, but how does the kernel
know what to do with each node?
The trick is that the kernel starts at the root of the tree and looks
for nodes that have a 'compatible' property. First, it is generally
assumed that any node with a 'compatible' property represents a device
of some kind, and second, it can be assumed that any node at the root
of the tree is either directly attached to the processor bus, or is a
miscellaneous system device that cannot be described any other way.
For each of these nodes, Linux allocates and registers a
platform_device, which in turn may get bound to a platform_driver.
Why is using a platform_device for these nodes a safe assumption?
Well, for the way that Linux models devices, just about all bus_types
assume that its devices are children of a bus controller. For
example, each i2c_client is a child of an i2c_master. Each spi_device
is a child of an SPI bus. Similarly for USB, PCI, MDIO, etc. The
same hierarchy is also found in the DT, where I2C device nodes only
ever appear as children of an I2C bus node. Ditto for SPI, MDIO, USB,
etc. The only devices which do not require a specific type of parent
device are platform_devices (and amba_devices, but more on that
later), which will happily live at the base of the Linux /sys/devices
tree. Therefore, if a DT node is at the root of the tree, then it
really probably is best registered as a platform_device.
Linux board support code calls of_platform_populate(NULL, NULL, NULL)
to kick off discovery of devices at the root of the tree. The
parameters are all NULL because when starting from the root of the
tree, there is no need to provide a starting node (the first NULL), a
parent struct device (the last NULL), and we're not using a match
table (yet). For a board that only needs to register devices,
.init_machine() can be completely empty except for the
of_platform_populate() call.
In the Tegra example, this accounts for the /soc and /sound nodes, but
what about the children of the SoC node? Shouldn't they be registered
as platform devices too? For Linux DT support, the generic behaviour
is for child devices to be registered by the parent's device driver at
driver .probe() time. So, an i2c bus device driver will register a
i2c_client for each child node, an SPI bus driver will register
its spi_device children, and similarly for other bus_types.
According to that model, a driver could be written that binds to the
SoC node and simply registers platform_devices for each of its
children. The board support code would allocate and register an SoC
device, a (theoretical) SoC device driver could bind to the SoC device,
and register platform_devices for /soc/interrupt-controller, /soc/serial,
/soc/i2s, and /soc/i2c in its .probe() hook. Easy, right?
Actually, it turns out that registering children of some
platform_devices as more platform_devices is a common pattern, and the
device tree support code reflects that and makes the above example
simpler. The second argument to of_platform_populate() is an
of_device_id table, and any node that matches an entry in that table
will also get its child nodes registered. In the tegra case, the code
can look something like this:
static void __init harmony_init_machine(void)
{
/* ... */
of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
}
"simple-bus" is defined in the ePAPR 1.0 specification as a property
meaning a simple memory mapped bus, so the of_platform_populate() code
could be written to just assume simple-bus compatible nodes will
always be traversed. However, we pass it in as an argument so that
board support code can always override the default behaviour.
[Need to add discussion of adding i2c/spi/etc child devices]
Appendix A: AMBA devices
------------------------
ARM Primecells are a certain kind of device attached to the ARM AMBA
bus which include some support for hardware detection and power
management. In Linux, struct amba_device and the amba_bus_type is
used to represent Primecell devices. However, the fiddly bit is that
not all devices on an AMBA bus are Primecells, and for Linux it is
typical for both amba_device and platform_device instances to be
siblings of the same bus segment.
When using the DT, this creates problems for of_platform_populate()
because it must decide whether to register each node as either a
platform_device or an amba_device. This unfortunately complicates the
device creation model a little bit, but the solution turns out not to
be too invasive. If a node is compatible with "arm,amba-primecell", then
of_platform_populate() will register it as an amba_device instead of a
platform_device.

120
Documentation/dma-buf-sharing.txt
View File

@ -32,8 +32,12 @@ The buffer-user
*IMPORTANT*: [see https://lkml.org/lkml/2011/12/20/211 for more details]
For this first version, A buffer shared using the dma_buf sharing API:
- *may* be exported to user space using "mmap" *ONLY* by exporter, outside of
this framework.
- may be used *ONLY* by importers that do not need CPU access to the buffer.
this framework.
- with this new iteration of the dma-buf api cpu access from the kernel has been
enable, see below for the details.
dma-buf operations for device dma only
--------------------------------------
The dma_buf buffer sharing API usage contains the following steps:
@ -219,10 +223,120 @@ NOTES:
If the exporter chooses not to allow an attach() operation once a
map_dma_buf() API has been called, it simply returns an error.
Miscellaneous notes:
Kernel cpu access to a dma-buf buffer object
--------------------------------------------
The motivation to allow cpu access from the kernel to a dma-buf object from the
importers side are:
- fallback operations, e.g. if the devices is connected to a usb bus and the
kernel needs to shuffle the data around first before sending it away.
- full transparency for existing users on the importer side, i.e. userspace
should not notice the difference between a normal object from that subsystem
and an imported one backed by a dma-buf. This is really important for drm
opengl drivers that expect to still use all the existing upload/download
paths.
Access to a dma_buf from the kernel context involves three steps:
1. Prepare access, which invalidate any necessary caches and make the object
available for cpu access.
2. Access the object page-by-page with the dma_buf map apis
3. Finish access, which will flush any necessary cpu caches and free reserved
resources.
1. Prepare access
Before an importer can access a dma_buf object with the cpu from the kernel
context, it needs to notify the exporter of the access that is about to
happen.
Interface:
int dma_buf_begin_cpu_access(struct dma_buf *dmabuf,
size_t start, size_t len,
enum dma_data_direction direction)
This allows the exporter to ensure that the memory is actually available for
cpu access - the exporter might need to allocate or swap-in and pin the
backing storage. The exporter also needs to ensure that cpu access is
coherent for the given range and access direction. The range and access
direction can be used by the exporter to optimize the cache flushing, i.e.
access outside of the range or with a different direction (read instead of
write) might return stale or even bogus data (e.g. when the exporter needs to
copy the data to temporary storage).
This step might fail, e.g. in oom conditions.
2. Accessing the buffer
To support dma_buf objects residing in highmem cpu access is page-based using
an api similar to kmap. Accessing a dma_buf is done in aligned chunks of
PAGE_SIZE size. Before accessing a chunk it needs to be mapped, which returns
a pointer in kernel virtual address space. Afterwards the chunk needs to be
unmapped again. There is no limit on how often a given chunk can be mapped
and unmapped, i.e. the importer does not need to call begin_cpu_access again
before mapping the same chunk again.
Interfaces:
void *dma_buf_kmap(struct dma_buf *, unsigned long);
void dma_buf_kunmap(struct dma_buf *, unsigned long, void *);
There are also atomic variants of these interfaces. Like for kmap they
facilitate non-blocking fast-paths. Neither the importer nor the exporter (in
the callback) is allowed to block when using these.
Interfaces:
void *dma_buf_kmap_atomic(struct dma_buf *, unsigned long);
void dma_buf_kunmap_atomic(struct dma_buf *, unsigned long, void *);
For importers all the restrictions of using kmap apply, like the limited
supply of kmap_atomic slots. Hence an importer shall only hold onto at most 2
atomic dma_buf kmaps at the same time (in any given process context).
dma_buf kmap calls outside of the range specified in begin_cpu_access are
undefined. If the range is not PAGE_SIZE aligned, kmap needs to succeed on
the partial chunks at the beginning and end but may return stale or bogus
data outside of the range (in these partial chunks).
Note that these calls need to always succeed. The exporter needs to complete
any preparations that might fail in begin_cpu_access.
3. Finish access
When the importer is done accessing the range specified in begin_cpu_access,
it needs to announce this to the exporter (to facilitate cache flushing and
unpinning of any pinned resources). The result of of any dma_buf kmap calls
after end_cpu_access is undefined.
Interface:
void dma_buf_end_cpu_access(struct dma_buf *dma_buf,
size_t start, size_t len,
enum dma_data_direction dir);
Miscellaneous notes
-------------------
- Any exporters or users of the dma-buf buffer sharing framework must have
a 'select DMA_SHARED_BUFFER' in their respective Kconfigs.
- In order to avoid fd leaks on exec, the FD_CLOEXEC flag must be set
on the file descriptor. This is not just a resource leak, but a
potential security hole. It could give the newly exec'd application
access to buffers, via the leaked fd, to which it should otherwise
not be permitted access.
The problem with doing this via a separate fcntl() call, versus doing it
atomically when the fd is created, is that this is inherently racy in a
multi-threaded app[3]. The issue is made worse when it is library code
opening/creating the file descriptor, as the application may not even be
aware of the fd's.
To avoid this problem, userspace must have a way to request O_CLOEXEC
flag be set when the dma-buf fd is created. So any API provided by
the exporting driver to create a dmabuf fd must provide a way to let
userspace control setting of O_CLOEXEC flag passed in to dma_buf_fd().
References:
[1] struct dma_buf_ops in include/linux/dma-buf.h
[2] All interfaces mentioned above defined in include/linux/dma-buf.h
[3] https://lwn.net/Articles/236486/

1
Documentation/dontdiff
View File

@ -158,7 +158,6 @@ logo_*.c
logo_*_clut224.c
logo_*_mono.c
lxdialog
mach
mach-types
mach-types.h
machtypes.h

2
Documentation/fb/intel810.txt
View File

@ -211,7 +211,7 @@ Using the same setup as described above, load the module like this:
modprobe i810fb vram=2 xres=1024 bpp=8 hsync1=30 hsync2=55 vsync1=50 \
vsync2=85 accel=1 mtrr=1
Or just add the following to /etc/modprobe.conf
Or just add the following to a configuration file in /etc/modprobe.d/
options i810fb vram=2 xres=1024 bpp=16 hsync1=30 hsync2=55 vsync1=50 \
vsync2=85 accel=1 mtrr=1

2
Documentation/fb/intelfb.txt
View File

@ -120,7 +120,7 @@ Using the same setup as described above, load the module like this:
modprobe intelfb mode=800x600-32@75 vram=8 accel=1 hwcursor=1
Or just add the following to /etc/modprobe.conf
Or just add the following to a configuration file in /etc/modprobe.d/
options intelfb mode=800x600-32@75 vram=8 accel=1 hwcursor=1

18
Documentation/feature-removal-schedule.txt
View File

@ -6,14 +6,6 @@ be removed from this file.
---------------------------
What: x86 floppy disable_hlt
When: 2012
Why: ancient workaround of dubious utility clutters the
code used by everybody else.
Who: Len Brown <len.brown@intel.com>
---------------------------
What: CONFIG_APM_CPU_IDLE, and its ability to call APM BIOS in idle
When: 2012
Why: This optional sub-feature of APM is of dubious reliability,
@ -529,3 +521,13 @@ When: 3.5
Why: The old kmap_atomic() with two arguments is deprecated, we only
keep it for backward compatibility for few cycles and then drop it.
Who: Cong Wang <amwang@redhat.com>
----------------------------
What: get_robust_list syscall
When: 2013
Why: There appear to be no production users of the get_robust_list syscall,
and it runs the risk of leaking address locations, allowing the bypass
of ASLR. It was only ever intended for debugging, so it should be
removed.
Who: Kees Cook <keescook@chromium.org>

8
Documentation/filesystems/ext4.txt
View File

@ -144,9 +144,6 @@ journal_async_commit Commit block can be written to disk without waiting
mount the device. This will enable 'journal_checksum'
internally.
journal=update Update the ext4 file system's journal to the current
format.
journal_dev=devnum When the external journal device's major/minor numbers
have changed, this option allows the user to specify
the new journal location. The journal device is
@ -356,11 +353,6 @@ nouid32 Disables 32-bit UIDs and GIDs. This is for
interoperability with older kernels which only
store and expect 16-bit values.
resize Allows to resize filesystem to the end of the last
existing block group, further resize has to be done
with resize2fs either online, or offline. It can be
used only with conjunction with remount.
block_validity This options allows to enables/disables the in-kernel
noblock_validity facility for tracking filesystem metadata blocks
within internal data structures. This allows multi-

4
Documentation/filesystems/files.txt
View File

@ -113,8 +113,8 @@ the fdtable structure -
if (fd >= 0) {
/* locate_fd() may have expanded fdtable, load the ptr */
fdt = files_fdtable(files);
FD_SET(fd, fdt->open_fds);
FD_CLR(fd, fdt->close_on_exec);
__set_open_fd(fd, fdt);
__clear_close_on_exec(fd, fdt);
spin_unlock(&files->file_lock);
.....

40
Documentation/gpio.txt
View File

@ -271,9 +271,26 @@ Some platforms may also use knowledge about what GPIOs are active for
power management, such as by powering down unused chip sectors and, more
easily, gating off unused clocks.
Note that requesting a GPIO does NOT cause it to be configured in any
way; it just marks that GPIO as in use. Separate code must handle any
pin setup (e.g. controlling which pin the GPIO uses, pullup/pulldown).
For GPIOs that use pins known to the pinctrl subsystem, that subsystem should
be informed of their use; a gpiolib driver's .request() operation may call
pinctrl_request_gpio(), and a gpiolib driver's .free() operation may call
pinctrl_free_gpio(). The pinctrl subsystem allows a pinctrl_request_gpio()
to succeed concurrently with a pin or pingroup being "owned" by a device for
pin multiplexing.
Any programming of pin multiplexing hardware that is needed to route the
GPIO signal to the appropriate pin should occur within a GPIO driver's
.direction_input() or .direction_output() operations, and occur after any
setup of an output GPIO's value. This allows a glitch-free migration from a
pin's special function to GPIO. This is sometimes required when using a GPIO
to implement a workaround on signals typically driven by a non-GPIO HW block.
Some platforms allow some or all GPIO signals to be routed to different pins.
Similarly, other aspects of the GPIO or pin may need to be configured, such as
pullup/pulldown. Platform software should arrange that any such details are
configured prior to gpio_request() being called for those GPIOs, e.g. using
the pinctrl subsystem's mapping table, so that GPIO users need not be aware
of these details.
Also note that it's your responsibility to have stopped using a GPIO
before you free it.
@ -302,6 +319,8 @@ where 'flags' is currently defined to specify the following properties:
* GPIOF_INIT_LOW - as output, set initial level to LOW
* GPIOF_INIT_HIGH - as output, set initial level to HIGH
* GPIOF_OPEN_DRAIN - gpio pin is open drain type.
* GPIOF_OPEN_SOURCE - gpio pin is open source type.
since GPIOF_INIT_* are only valid when configured as output, so group valid
combinations as:
@ -310,8 +329,19 @@ combinations as:
* GPIOF_OUT_INIT_LOW - configured as output, initial level LOW
* GPIOF_OUT_INIT_HIGH - configured as output, initial level HIGH
In the future, these flags can be extended to support more properties such
as open-drain status.
When setting the flag as GPIOF_OPEN_DRAIN then it will assume that pins is
open drain type. Such pins will not be driven to 1 in output mode. It is
require to connect pull-up on such pins. By enabling this flag, gpio lib will
make the direction to input when it is asked to set value of 1 in output mode
to make the pin HIGH. The pin is make to LOW by driving value 0 in output mode.
When setting the flag as GPIOF_OPEN_SOURCE then it will assume that pins is
open source type. Such pins will not be driven to 0 in output mode. It is
require to connect pull-down on such pin. By enabling this flag, gpio lib will
make the direction to input when it is asked to set value of 0 in output mode
to make the pin LOW. The pin is make to HIGH by driving value 1 in output mode.
In the future, these flags can be extended to support more properties.
Further more, to ease the claim/release of multiple GPIOs, 'struct gpio' is
introduced to encapsulate all three fields as:

2
Documentation/hwmon/k10temp
View File

@ -11,7 +11,7 @@ Supported chips:
Socket S1G2: Athlon (X2), Sempron (X2), Turion X2 (Ultra)
* AMD Family 12h processors: "Llano" (E2/A4/A6/A8-Series)
* AMD Family 14h processors: "Brazos" (C/E/G/Z-Series)
* AMD Family 15h processors: "Bulldozer"
* AMD Family 15h processors: "Bulldozer" (FX-Series), "Trinity"
Prefix: 'k10temp'
Addresses scanned: PCI space

1
Documentation/i2c/busses/i2c-i801
View File

@ -20,6 +20,7 @@ Supported adapters:
* Intel Patsburg (PCH)
* Intel DH89xxCC (PCH)
* Intel Panther Point (PCH)
* Intel Lynx Point (PCH)
Datasheets: Publicly available at the Intel website
On Intel Patsburg and later chipsets, both the normal host SMBus controller

2
Documentation/i2c/busses/scx200_acb
View File

@ -28,5 +28,5 @@ If the scx200_acb driver is built into the kernel, add the following
parameter to your boot command line:
scx200_acb.base=0x810,0x820
If the scx200_acb driver is built as a module, add the following line to
the file /etc/modprobe.conf instead:
a configuration file in /etc/modprobe.d/ instead:
options scx200_acb base=0x810,0x820

2
Documentation/ide/ide.txt
View File

@ -169,7 +169,7 @@ When using ide.c as a module in combination with kmod, add:
alias block-major-3 ide-probe
to /etc/modprobe.conf.
to a configuration file in /etc/modprobe.d/.
When ide.c is used as a module, you can pass command line parameters to the
driver using the "options=" keyword to insmod, while replacing any ',' with

4
Documentation/input/input.txt
View File

@ -250,8 +250,8 @@ And so on up to event31.
a USB keyboard works and is correctly connected to the kernel keyboard
driver.
Doing a cat /dev/input/mouse0 (c, 13, 32) will verify that a mouse
is also emulated, characters should appear if you move it.
Doing a "cat /dev/input/mouse0" (c, 13, 32) will verify that a mouse
is also emulated; characters should appear if you move it.
You can test the joystick emulation with the 'jstest' utility,
available in the joystick package (see Documentation/input/joystick.txt).

1
Documentation/ioctl/ioctl-number.txt
View File

@ -225,6 +225,7 @@ Code Seq#(hex) Include File Comments
'j' 00-3F linux/joystick.h
'k' 00-0F linux/spi/spidev.h conflict!
'k' 00-05 video/kyro.h conflict!
'k' 10-17 linux/hsi/hsi_char.h HSI character device
'l' 00-3F linux/tcfs_fs.h transparent cryptographic file system
<http://web.archive.org/web/*/http://mikonos.dia.unisa.it/tcfs>
'l' 40-7F linux/udf_fs_i.h in development:

16
Documentation/isdn/README.gigaset
View File

@ -97,8 +97,7 @@ GigaSet 307x Device Driver
2.5.): 1=on (default), 0=off
Depending on your distribution you may want to create a separate module
configuration file /etc/modprobe.d/gigaset for these, or add them to a
custom file like /etc/modprobe.conf.local.
configuration file like /etc/modprobe.d/gigaset.conf for these.
2.2. Device nodes for user space programs
------------------------------------
@ -212,8 +211,8 @@ GigaSet 307x Device Driver
options ppp_async flag_time=0
to an appropriate module configuration file, like /etc/modprobe.d/gigaset
or /etc/modprobe.conf.local.
to an appropriate module configuration file, like
/etc/modprobe.d/gigaset.conf.
Unimodem mode is needed for making some devices [e.g. SX100] work which
do not support the regular Gigaset command set. If debug output (see
@ -237,8 +236,8 @@ GigaSet 307x Device Driver
modprobe usb_gigaset startmode=0
or by adding a line like
options usb_gigaset startmode=0
to an appropriate module configuration file, like /etc/modprobe.d/gigaset
or /etc/modprobe.conf.local.
to an appropriate module configuration file, like
/etc/modprobe.d/gigaset.conf
2.6. Call-ID (CID) mode
------------------
@ -310,7 +309,7 @@ GigaSet 307x Device Driver
options isdn dialtimeout=15
to /etc/modprobe.d/gigaset, /etc/modprobe.conf.local or a similar file.
to /etc/modprobe.d/gigaset.conf or a similar file.
Problem:
The isdnlog program emits error messages or just doesn't work.
@ -350,8 +349,7 @@ GigaSet 307x Device Driver
The initial value can be set using the debug parameter when loading the
module "gigaset", e.g. by adding a line
options gigaset debug=0
to your module configuration file, eg. /etc/modprobe.d/gigaset or
/etc/modprobe.conf.local.
to your module configuration file, eg. /etc/modprobe.d/gigaset.conf
Generated debugging information can be found
- as output of the command

8
Documentation/kbuild/kconfig.txt
View File

@ -28,12 +28,10 @@ new (default) values, so you can use:
grep "(NEW)" conf.new
to see the new config symbols or you can 'diff' the previous and
new .config files to see the differences:
to see the new config symbols or you can use diffconfig to see the
differences between the previous and new .config files:
diff .config.old .config | less
(Yes, we need something better here.)
scripts/diffconfig .config.old .config | less
______________________________________________________________________
Environment variables for '*config'

8
Documentation/kernel-parameters.txt
View File

@ -1699,6 +1699,12 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
The default is to send the implementation identification
information.
nfsd.nfs4_disable_idmapping=
[NFSv4] When set to the default of '1', the NFSv4
server will return only numeric uids and gids to
clients using auth_sys, and will accept numeric uids
and gids from such clients. This is intended to ease
migration from NFSv2/v3.
objlayoutdriver.osd_login_prog=
[NFS] [OBJLAYOUT] sets the pathname to the program which
@ -1869,6 +1875,8 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
shutdown the other cpus. Instead use the REBOOT_VECTOR
irq.
nomodule Disable module load
nopat [X86] Disable PAT (page attribute table extension of
pagetables) support.

2
Documentation/laptops/asus-laptop.txt
View File

@ -45,7 +45,7 @@ Status
Usage
-----
Try "modprobe asus_acpi". Check your dmesg (simply type dmesg). You should
Try "modprobe asus-laptop". Check your dmesg (simply type dmesg). You should
see some lines like this :
Asus Laptop Extras version 0.42

5
Documentation/laptops/sony-laptop.txt
View File

@ -17,6 +17,11 @@ subsystem. See the logs of acpid or /proc/acpi/event and
devices are created by the driver. Additionally, loading the driver with the
debug option will report all events in the kernel log.
The "scancodes" passed to the input system (that can be remapped with udev)
are indexes to the table "sony_laptop_input_keycode_map" in the sony-laptop.c
module. For example the "FN/E" key combination (EJECTCD on some models)
generates the scancode 20 (0x14).
Backlight control:
------------------
If your laptop model supports it, you will find sysfs files in the

2
Documentation/laptops/sonypi.txt
View File

@ -110,7 +110,7 @@ Module use:
-----------
In order to automatically load the sonypi module on use, you can put those
lines in your /etc/modprobe.conf file:
lines a configuration file in /etc/modprobe.d/:
alias char-major-10-250 sonypi
options sonypi minor=250

8
Documentation/mono.txt
View File

@ -38,11 +38,11 @@ if [ ! -e /proc/sys/fs/binfmt_misc/register ]; then
/sbin/modprobe binfmt_misc
# Some distributions, like Fedora Core, perform
# the following command automatically when the
# binfmt_misc module is loaded into the kernel.
# binfmt_misc module is loaded into the kernel
# or during normal boot up (systemd-based systems).
# Thus, it is possible that the following line
# is not needed at all. Look at /etc/modprobe.conf
# to check whether this is applicable or not.
mount -t binfmt_misc none /proc/sys/fs/binfmt_misc
# is not needed at all.
mount -t binfmt_misc none /proc/sys/fs/binfmt_misc
fi
# Register support for .NET CLR binaries

2
Documentation/networking/baycom.txt
View File

@ -93,7 +93,7 @@ Every time a driver is inserted into the kernel, it has to know which
modems it should access at which ports. This can be done with the setbaycom
utility. If you are only using one modem, you can also configure the
driver from the insmod command line (or by means of an option line in
/etc/modprobe.conf).
/etc/modprobe.d/*.conf).
Examples:
modprobe baycom_ser_fdx mode="ser12*" iobase=0x3f8 irq=4

46
Documentation/networking/bonding.txt
View File

@ -173,9 +173,8 @@ bonding module at load time, or are specified via sysfs.
Module options may be given as command line arguments to the
insmod or modprobe command, but are usually specified in either the
/etc/modules.conf or /etc/modprobe.conf configuration file, or in a
distro-specific configuration file (some of which are detailed in the next
section).
/etc/modrobe.d/*.conf configuration files, or in a distro-specific
configuration file (some of which are detailed in the next section).
Details on bonding support for sysfs is provided in the
"Configuring Bonding Manually via Sysfs" section, below.
@ -1021,7 +1020,7 @@ ifcfg-bondX files.
Because the sysconfig scripts supply the bonding module
options in the ifcfg-bondX file, it is not necessary to add them to
the system /etc/modules.conf or /etc/modprobe.conf configuration file.
the system /etc/modules.d/*.conf configuration files.
3.2 Configuration with Initscripts Support
------------------------------------------
@ -1098,15 +1097,13 @@ queried targets, e.g.,
arp_ip_target=+192.168.1.1 arp_ip_target=+192.168.1.2
is the proper syntax to specify multiple targets. When specifying
options via BONDING_OPTS, it is not necessary to edit /etc/modules.conf or
/etc/modprobe.conf.
options via BONDING_OPTS, it is not necessary to edit /etc/modprobe.d/*.conf.
For even older versions of initscripts that do not support
BONDING_OPTS, it is necessary to edit /etc/modules.conf (or
/etc/modprobe.conf, depending upon your distro) to load the bonding module
with your desired options when the bond0 interface is brought up. The
following lines in /etc/modules.conf (or modprobe.conf) will load the
bonding module, and select its options:
BONDING_OPTS, it is necessary to edit /etc/modprobe.d/*.conf, depending upon
your distro) to load the bonding module with your desired options when the
bond0 interface is brought up. The following lines in /etc/modprobe.d/*.conf
will load the bonding module, and select its options:
alias bond0 bonding
options bond0 mode=balance-alb miimon=100
@ -1152,7 +1149,7 @@ knowledge of bonding. One such distro is SuSE Linux Enterprise Server
version 8.
The general method for these systems is to place the bonding
module parameters into /etc/modules.conf or /etc/modprobe.conf (as
module parameters into a config file in /etc/modprobe.d/ (as
appropriate for the installed distro), then add modprobe and/or
ifenslave commands to the system's global init script. The name of
the global init script differs; for sysconfig, it is
@ -1228,7 +1225,7 @@ network initialization scripts.
specify a different name for each instance (the module loading system
requires that every loaded module, even multiple instances of the same
module, have a unique name). This is accomplished by supplying multiple
sets of bonding options in /etc/modprobe.conf, for example:
sets of bonding options in /etc/modprobe.d/*.conf, for example:
alias bond0 bonding
options bond0 -o bond0 mode=balance-rr miimon=100
@ -1793,8 +1790,8 @@ route additions may cause trouble.
On systems with network configuration scripts that do not
associate physical devices directly with network interface names (so
that the same physical device always has the same "ethX" name), it may
be necessary to add some special logic to either /etc/modules.conf or
/etc/modprobe.conf (depending upon which is installed on the system).
be necessary to add some special logic to config files in
/etc/modprobe.d/.
For example, given a modules.conf containing the following:
@ -1821,20 +1818,15 @@ add above bonding e1000 tg3
bonding is loaded. This command is fully documented in the
modules.conf manual page.
On systems utilizing modprobe.conf (or modprobe.conf.local),
an equivalent problem can occur. In this case, the following can be
added to modprobe.conf (or modprobe.conf.local, as appropriate), as
follows (all on one line; it has been split here for clarity):
On systems utilizing modprobe an equivalent problem can occur.
In this case, the following can be added to config files in
/etc/modprobe.d/ as:
install bonding /sbin/modprobe tg3; /sbin/modprobe e1000;
/sbin/modprobe --ignore-install bonding
softdep bonding pre: tg3 e1000
This will, when loading the bonding module, rather than
performing the normal action, instead execute the provided command.
This command loads the device drivers in the order needed, then calls
modprobe with --ignore-install to cause the normal action to then take
place. Full documentation on this can be found in the modprobe.conf
and modprobe manual pages.
This will load tg3 and e1000 modules before loading the bonding one.
Full documentation on this can be found in the modprobe.d and modprobe
manual pages.
8.3. Painfully Slow Or No Failed Link Detection By Miimon
---------------------------------------------------------

11
Documentation/networking/dl2k.txt
View File

@ -45,12 +45,13 @@ Now eth0 should active, you can test it by "ping" or get more information by
"ifconfig". If tested ok, continue the next step.
4. cp dl2k.ko /lib/modules/`uname -r`/kernel/drivers/net
5. Add the following line to /etc/modprobe.conf:
5. Add the following line to /etc/modprobe.d/dl2k.conf:
alias eth0 dl2k
6. Run "netconfig" or "netconf" to create configuration script ifcfg-eth0
6. Run depmod to updated module indexes.
7. Run "netconfig" or "netconf" to create configuration script ifcfg-eth0
located at /etc/sysconfig/network-scripts or create it manually.
[see - Configuration Script Sample]
7. Driver will automatically load and configure at next boot time.
8. Driver will automatically load and configure at next boot time.
Compiling the Driver
====================
@ -154,8 +155,8 @@ Installing the Driver
-----------------
1. Copy dl2k.o to the network modules directory, typically
/lib/modules/2.x.x-xx/net or /lib/modules/2.x.x/kernel/drivers/net.
2. Locate the boot module configuration file, most commonly modprobe.conf
or modules.conf (for 2.4) in the /etc directory. Add the following lines:
2. Locate the boot module configuration file, most commonly in the
/etc/modprobe.d/ directory. Add the following lines:
alias ethx dl2k
options dl2k <optional parameters>

31
Documentation/networking/driver.txt
View File

@ -2,16 +2,16 @@ Document about softnet driver issues
Transmit path guidelines:
1) The hard_start_xmit method must never return '1' under any
normal circumstances. It is considered a hard error unless
1) The ndo_start_xmit method must not return NETDEV_TX_BUSY under
any normal circumstances. It is considered a hard error unless
there is no way your device can tell ahead of time when it's
transmit function will become busy.
Instead it must maintain the queue properly. For example,
for a driver implementing scatter-gather this means:
static int drv_hard_start_xmit(struct sk_buff *skb,
struct net_device *dev)
static netdev_tx_t drv_hard_start_xmit(struct sk_buff *skb,
struct net_device *dev)
{
struct drv *dp = netdev_priv(dev);
@ -23,7 +23,7 @@ Transmit path guidelines:
unlock_tx(dp);
printk(KERN_ERR PFX "%s: BUG! Tx Ring full when queue awake!\n",
dev->name);
return 1;
return NETDEV_TX_BUSY;
}
... queue packet to card ...
@ -35,6 +35,7 @@ Transmit path guidelines:
...
unlock_tx(dp);
...
return NETDEV_TX_OK;
}
And then at the end of your TX reclamation event handling:
@ -58,15 +59,12 @@ Transmit path guidelines:
TX_BUFFS_AVAIL(dp) > 0)
netif_wake_queue(dp->dev);
2) Do not forget to update netdev->trans_start to jiffies after
each new tx packet is given to the hardware.
3) A hard_start_xmit method must not modify the shared parts of a
2) An ndo_start_xmit method must not modify the shared parts of a
cloned SKB.
4) Do not forget that once you return 0 from your hard_start_xmit
method, it is your driver's responsibility to free up the SKB
and in some finite amount of time.
3) Do not forget that once you return NETDEV_TX_OK from your
ndo_start_xmit method, it is your driver's responsibility to free
up the SKB and in some finite amount of time.
For example, this means that it is not allowed for your TX
mitigation scheme to let TX packets "hang out" in the TX
@ -74,8 +72,9 @@ Transmit path guidelines:
This error can deadlock sockets waiting for send buffer room
to be freed up.
If you return 1 from the hard_start_xmit method, you must not keep
any reference to that SKB and you must not attempt to free it up.
If you return NETDEV_TX_BUSY from the ndo_start_xmit method, you
must not keep any reference to that SKB and you must not attempt
to free it up.
Probing guidelines:
@ -85,10 +84,10 @@ Probing guidelines:
Close/stop guidelines:
1) After the dev->stop routine has been called, the hardware must
1) After the ndo_stop routine has been called, the hardware must
not receive or transmit any data. All in flight packets must
be aborted. If necessary, poll or wait for completion of
any reset commands.
2) The dev->stop routine will be called by unregister_netdevice
2) The ndo_stop routine will be called by unregister_netdevice
if device is still UP.

6
Documentation/networking/e100.txt
View File

@ -94,8 +94,8 @@ Additional Configurations
Configuring a network driver to load properly when the system is started is
distribution dependent. Typically, the configuration process involves adding
an alias line to /etc/modules.conf or /etc/modprobe.conf as well as editing
other system startup scripts and/or configuration files. Many popular Linux
an alias line to /etc/modprobe.d/*.conf as well as editing other system
startup scripts and/or configuration files. Many popular Linux
distributions ship with tools to make these changes for you. To learn the
proper way to configure a network device for your system, refer to your
distribution documentation. If during this process you are asked for the
@ -103,7 +103,7 @@ Additional Configurations
PRO/100 Family of Adapters is e100.
As an example, if you install the e100 driver for two PRO/100 adapters
(eth0 and eth1), add the following to modules.conf or modprobe.conf:
(eth0 and eth1), add the following to a configuraton file in /etc/modprobe.d/
alias eth0 e100
alias eth1 e100

11
Documentation/networking/ip-sysctl.txt
View File

@ -604,15 +604,8 @@ IP Variables:
ip_local_port_range - 2 INTEGERS
Defines the local port range that is used by TCP and UDP to
choose the local port. The first number is the first, the
second the last local port number. Default value depends on
amount of memory available on the system:
> 128Mb 32768-61000
< 128Mb 1024-4999 or even less.
This number defines number of active connections, which this
system can issue simultaneously to systems not supporting
TCP extensions (timestamps). With tcp_tw_recycle enabled
(i.e. by default) range 1024-4999 is enough to issue up to
2000 connections per second to systems supporting timestamps.
second the last local port number. The default values are
32768 and 61000 respectively.
ip_local_reserved_ports - list of comma separated ranges
Specify the ports which are reserved for known third-party

6
Documentation/networking/ipv6.txt
View File

@ -2,9 +2,9 @@
Options for the ipv6 module are supplied as parameters at load time.
Module options may be given as command line arguments to the insmod
or modprobe command, but are usually specified in either the
/etc/modules.conf or /etc/modprobe.conf configuration file, or in a
distro-specific configuration file.
or modprobe command, but are usually specified in either
/etc/modules.d/*.conf configuration files, or in a distro-specific
configuration file.
The available ipv6 module parameters are listed below. If a parameter
is not specified the default value is used.

6
Documentation/networking/ixgb.txt
View File

@ -274,9 +274,9 @@ Additional Configurations
-------------------------------------------------
Configuring a network driver to load properly when the system is started is
distribution dependent. Typically, the configuration process involves adding
an alias line to /etc/modprobe.conf as well as editing other system startup
scripts and/or configuration files. Many popular Linux distributions ship
with tools to make these changes for you. To learn the proper way to
an alias line to files in /etc/modprobe.d/ as well as editing other system
startup scripts and/or configuration files. Many popular Linux distributions
ship with tools to make these changes for you. To learn the proper way to
configure a network device for your system, refer to your distribution
documentation. If during this process you are asked for the driver or module
name, the name for the Linux Base Driver for the Intel 10GbE Family of

2
Documentation/networking/ltpc.txt
View File

@ -25,7 +25,7 @@ the driver will try to determine them itself.
If you load the driver as a module, you can pass the parameters "io=",
"irq=", and "dma=" on the command line with insmod or modprobe, or add
them as options in /etc/modprobe.conf:
them as options in a configuration file in /etc/modprobe.d/ directory:
alias lt0 ltpc # autoload the module when the interface is configured
options ltpc io=0x240 irq=9 dma=1

25
Documentation/networking/netdevices.txt
View File

@ -47,26 +47,25 @@ packets is preferred.
struct net_device synchronization rules
=======================================
dev->open:
ndo_open:
Synchronization: rtnl_lock() semaphore.
Context: process
dev->stop:
ndo_stop:
Synchronization: rtnl_lock() semaphore.
Context: process
Note1: netif_running() is guaranteed false
Note2: dev->poll() is guaranteed to be stopped
Note: netif_running() is guaranteed false
dev->do_ioctl:
ndo_do_ioctl:
Synchronization: rtnl_lock() semaphore.
Context: process
dev->get_stats:
ndo_get_stats:
Synchronization: dev_base_lock rwlock.
Context: nominally process, but don't sleep inside an rwlock
dev->hard_start_xmit:
Synchronization: netif_tx_lock spinlock.
ndo_start_xmit:
Synchronization: __netif_tx_lock spinlock.
When the driver sets NETIF_F_LLTX in dev->features this will be
called without holding netif_tx_lock. In this case the driver
@ -87,20 +86,20 @@ dev->hard_start_xmit:
o NETDEV_TX_LOCKED Locking failed, please retry quickly.
Only valid when NETIF_F_LLTX is set.
dev->tx_timeout:
Synchronization: netif_tx_lock spinlock.
ndo_tx_timeout:
Synchronization: netif_tx_lock spinlock; all TX queues frozen.
Context: BHs disabled
Notes: netif_queue_stopped() is guaranteed true
dev->set_rx_mode:
Synchronization: netif_tx_lock spinlock.
ndo_set_rx_mode:
Synchronization: netif_addr_lock spinlock.
Context: BHs disabled
struct napi_struct synchronization rules
========================================
napi->poll:
Synchronization: NAPI_STATE_SCHED bit in napi->state. Device
driver's dev->close method will invoke napi_disable() on
driver's ndo_stop method will invoke napi_disable() on
all NAPI instances which will do a sleeping poll on the
NAPI_STATE_SCHED napi->state bit, waiting for all pending
NAPI activity to cease.

6
Documentation/networking/vortex.txt
View File

@ -67,8 +67,8 @@ Module parameters
=================
There are several parameters which may be provided to the driver when
its module is loaded. These are usually placed in /etc/modprobe.conf
(/etc/modules.conf in 2.4). Example:
its module is loaded. These are usually placed in /etc/modprobe.d/*.conf
configuretion files. Example:
options 3c59x debug=3 rx_copybreak=300
@ -425,7 +425,7 @@ steps you should take:
1) Increase the debug level. Usually this is done via:
a) modprobe driver debug=7
b) In /etc/modprobe.conf (or /etc/modules.conf for 2.4):
b) In /etc/modprobe.d/driver.conf:
options driver debug=7
2) Recreate the problem with the higher debug level,

13
Documentation/parport.txt
View File

@ -36,18 +36,17 @@ addresses should not be specified for supported PCI cards since they
are automatically detected.
KMod
----
modprobe
--------
If you use kmod, you will find it useful to edit /etc/modprobe.conf.
Here is an example of the lines that need to be added:
If you use modprobe , you will find it useful to add lines as below to a
configuration file in /etc/modprobe.d/ directory:.
alias parport_lowlevel parport_pc
options parport_pc io=0x378,0x278 irq=7,auto
KMod will then automatically load parport_pc (with the options
"io=0x378,0x278 irq=7,auto") whenever a parallel port device driver
(such as lp) is loaded.
modprobe will load parport_pc (with the options "io=0x378,0x278 irq=7,auto")
whenever a parallel port device driver (such as lp) is loaded.
Note that these are example lines only! You shouldn't in general need
to specify any options to parport_pc in order to be able to use a

21
Documentation/s390/3270.txt
View File

@ -47,9 +47,9 @@ including the console 3270, changes subchannel identifier relative to
one another. ReIPL as soon as possible after running the configuration
script and the resulting /tmp/mkdev3270.
If you have chosen to make tub3270 a module, you add a line to
/etc/modprobe.conf. If you are working on a VM virtual machine, you
can use DEF GRAF to define virtual 3270 devices.
If you have chosen to make tub3270 a module, you add a line to a
configuration file under /etc/modprobe.d/. If you are working on a VM
virtual machine, you can use DEF GRAF to define virtual 3270 devices.
You may generate both 3270 and 3215 console support, or one or the
other, or neither. If you generate both, the console type under VM is
@ -60,7 +60,7 @@ at boot time to a 3270 if it is a 3215.
In brief, these are the steps:
1. Install the tub3270 patch
2. (If a module) add a line to /etc/modprobe.conf
2. (If a module) add a line to a file in /etc/modprobe.d/*.conf
3. (If VM) define devices with DEF GRAF
4. Reboot
5. Configure
@ -84,13 +84,12 @@ Here are the installation steps in detail:
make modules_install
2. (Perform this step only if you have configured tub3270 as a
module.) Add a line to /etc/modprobe.conf to automatically
load the driver when it's needed. With this line added,
you will see login prompts appear on your 3270s as soon as
boot is complete (or with emulated 3270s, as soon as you dial
into your vm guest using the command "DIAL <vmguestname>").
Since the line-mode major number is 227, the line to add to
/etc/modprobe.conf should be:
module.) Add a line to a file /etc/modprobe.d/*.conf to automatically
load the driver when it's needed. With this line added, you will see
login prompts appear on your 3270s as soon as boot is complete (or
with emulated 3270s, as soon as you dial into your vm guest using the
command "DIAL <vmguestname>"). Since the line-mode major number is
227, the line to add should be:
alias char-major-227 tub3270
3. Define graphic devices to your vm guest machine, if you

2
Documentation/scsi/00-INDEX
View File

@ -94,3 +94,5 @@ sym53c8xx_2.txt
- info on second generation driver for sym53c8xx based adapters
tmscsim.txt
- info on driver for AM53c974 based adapters
ufs.txt
- info on Universal Flash Storage(UFS) and UFS host controller driver.

2
Documentation/scsi/aic79xx.txt
View File

@ -215,7 +215,7 @@ The following information is available in this file:
INCORRECTLY CAN RENDER YOUR SYSTEM INOPERABLE.
USE THEM WITH CAUTION.
Edit the file "modprobe.conf" in the directory /etc and add/edit a
Put a .conf file in the /etc/modprobe.d/ directory and add/edit a
line containing 'options aic79xx aic79xx=[command[,command...]]' where
'command' is one or more of the following:
-----------------------------------------------------------------

2
Documentation/scsi/aic7xxx.txt
View File

@ -190,7 +190,7 @@ The following information is available in this file:
INCORRECTLY CAN RENDER YOUR SYSTEM INOPERABLE.
USE THEM WITH CAUTION.
Edit the file "modprobe.conf" in the directory /etc and add/edit a
Put a .conf file in the /etc/modprobe.d directory and add/edit a
line containing 'options aic7xxx aic7xxx=[command[,command...]]' where
'command' is one or more of the following:
-----------------------------------------------------------------

2
Documentation/scsi/osst.txt
View File

@ -66,7 +66,7 @@ recognized.
If you want to have the module autoloaded on access to /dev/osst, you may
add something like
alias char-major-206 osst
to your /etc/modprobe.conf (before 2.6: modules.conf).
to a file under /etc/modprobe.d/ directory.
You may find it convenient to create a symbolic link
ln -s nosst0 /dev/tape

4
Documentation/scsi/st.txt
View File

@ -390,6 +390,10 @@ MTSETDRVBUFFER
MT_ST_SYSV sets the SYSV semantics (mode)
MT_ST_NOWAIT enables immediate mode (i.e., don't wait for
the command to finish) for some commands (e.g., rewind)
MT_ST_NOWAIT_EOF enables immediate filemark mode (i.e. when
writing a filemark, don't wait for it to complete). Please
see the BASICS note about MTWEOFI with respect to the
possible dangers of writing immediate filemarks.
MT_ST_SILI enables setting the SILI bit in SCSI commands when
reading in variable block mode to enhance performance when
reading blocks shorter than the byte count; set this only

133
Documentation/scsi/ufs.txt Normal file
View File

@ -0,0 +1,133 @@
Universal Flash Storage
=======================
Contents
--------
1. Overview
2. UFS Architecture Overview
2.1 Application Layer
2.2 UFS Transport Protocol(UTP) layer
2.3 UFS Interconnect(UIC) Layer
3. UFSHCD Overview
3.1 UFS controller initialization
3.2 UTP Transfer requests
3.3 UFS error handling
3.4 SCSI Error handling
1. Overview
-----------
Universal Flash Storage(UFS) is a storage specification for flash devices.
It is aimed to provide a universal storage interface for both
embedded and removable flash memory based storage in mobile
devices such as smart phones and tablet computers. The specification
is defined by JEDEC Solid State Technology Association. UFS is based
on MIPI M-PHY physical layer standard. UFS uses MIPI M-PHY as the
physical layer and MIPI Unipro as the link layer.
The main goals of UFS is to provide,
* Optimized performance:
For UFS version 1.0 and 1.1 the target performance is as follows,
Support for Gear1 is mandatory (rate A: 1248Mbps, rate B: 1457.6Mbps)
Support for Gear2 is optional (rate A: 2496Mbps, rate B: 2915.2Mbps)
Future version of the standard,
Gear3 (rate A: 4992Mbps, rate B: 5830.4Mbps)
* Low power consumption
* High random IOPs and low latency
2. UFS Architecture Overview
----------------------------
UFS has a layered communication architecture which is based on SCSI
SAM-5 architectural model.
UFS communication architecture consists of following layers,
2.1 Application Layer
The Application layer is composed of UFS command set layer(UCS),
Task Manager and Device manager. The UFS interface is designed to be
protocol agnostic, however SCSI has been selected as a baseline
protocol for versions 1.0 and 1.1 of UFS protocol layer.
UFS supports subset of SCSI commands defined by SPC-4 and SBC-3.
* UCS: It handles SCSI commands supported by UFS specification.
* Task manager: It handles task management functions defined by the
UFS which are meant for command queue control.
* Device manager: It handles device level operations and device
configuration operations. Device level operations mainly involve
device power management operations and commands to Interconnect
layers. Device level configurations involve handling of query
requests which are used to modify and retrieve configuration
information of the device.
2.2 UFS Transport Protocol(UTP) layer
UTP layer provides services for
the higher layers through Service Access Points. UTP defines 3
service access points for higher layers.
* UDM_SAP: Device manager service access point is exposed to device
manager for device level operations. These device level operations
are done through query requests.
* UTP_CMD_SAP: Command service access point is exposed to UFS command
set layer(UCS) to transport commands.
* UTP_TM_SAP: Task management service access point is exposed to task
manager to transport task management functions.
UTP transports messages through UFS protocol information unit(UPIU).
2.3 UFS Interconnect(UIC) Layer
UIC is the lowest layer of UFS layered architecture. It handles
connection between UFS host and UFS device. UIC consists of
MIPI UniPro and MIPI M-PHY. UIC provides 2 service access points
to upper layer,
* UIC_SAP: To transport UPIU between UFS host and UFS device.
* UIO_SAP: To issue commands to Unipro layers.
3. UFSHCD Overview
------------------
The UFS host controller driver is based on Linux SCSI Framework.
UFSHCD is a low level device driver which acts as an interface between
SCSI Midlayer and PCIe based UFS host controllers.
The current UFSHCD implementation supports following functionality,
3.1 UFS controller initialization
The initialization module brings UFS host controller to active state
and prepares the controller to transfer commands/response between
UFSHCD and UFS device.
3.2 UTP Transfer requests
Transfer request handling module of UFSHCD receives SCSI commands
from SCSI Midlayer, forms UPIUs and issues the UPIUs to UFS Host
controller. Also, the module decodes, responses received from UFS
host controller in the form of UPIUs and intimates the SCSI Midlayer
of the status of the command.
3.3 UFS error handling
Error handling module handles Host controller fatal errors,
Device fatal errors and UIC interconnect layer related errors.
3.4 SCSI Error handling
This is done through UFSHCD SCSI error handling routines registered
with SCSI Midlayer. Examples of some of the error handling commands
issues by SCSI Midlayer are Abort task, Lun reset and host reset.
UFSHCD Routines to perform these tasks are registered with
SCSI Midlayer through .eh_abort_handler, .eh_device_reset_handler and
.eh_host_reset_handler.
In this version of UFSHCD Query requests and power management
functionality are not implemented.
UFS Specifications can be found at,
UFS - http://www.jedec.org/sites/default/files/docs/JESD220.pdf
UFSHCI - http://www.jedec.org/sites/default/files/docs/JESD223.pdf

8
Documentation/serial/computone.txt
View File

@ -49,7 +49,7 @@ Hardware - If you have an ISA card, find a free interrupt and io port.
Note the hardware address from the Computone ISA cards installed into
the system. These are required for editing ip2.c or editing
/etc/modprobe.conf, or for specification on the modprobe
/etc/modprobe.d/*.conf, or for specification on the modprobe
command line.
Note that the /etc/modules.conf should be used for older (pre-2.6)
@ -66,7 +66,7 @@ b) Run "make config" or "make menuconfig" or "make xconfig"
c) Set address on ISA cards then:
edit /usr/src/linux/drivers/char/ip2.c if needed
or
edit /etc/modprobe.conf if needed (module).
edit config file in /etc/modprobe.d/ if needed (module).
or both to match this setting.
d) Run "make modules"
e) Run "make modules_install"
@ -153,11 +153,11 @@ the irqs are not specified the driver uses the default in ip2.c (which
selects polled mode). If no base addresses are specified the defaults in
ip2.c are used. If you are autoloading the driver module with kerneld or
kmod the base addresses and interrupt number must also be set in ip2.c
and recompile or just insert and options line in /etc/modprobe.conf or both.
and recompile or just insert and options line in /etc/modprobe.d/*.conf or both.
The options line is equivalent to the command line and takes precedence over
what is in ip2.c.
/etc/modprobe.conf sample:
config sample to put /etc/modprobe.d/*.conf:
options ip2 io=1,0x328 irq=1,10
alias char-major-71 ip2
alias char-major-72 ip2

2
Documentation/serial/rocket.txt
View File

@ -62,7 +62,7 @@ in the system log at /var/log/messages.
If installed as a module, the module must be loaded. This can be done
manually by entering "modprobe rocket". To have the module loaded automatically
upon system boot, edit the /etc/modprobe.conf file and add the line
upon system boot, edit a /etc/modprobe.d/*.conf file and add the line
"alias char-major-46 rocket".
In order to use the ports, their device names (nodes) must be created with mknod.

4
Documentation/serial/stallion.txt
View File

@ -139,8 +139,8 @@ secondary address 0x280 and IRQ 10.
You will probably want to enter this module load and configuration information
into your system startup scripts so that the drivers are loaded and configured
on each system boot. Typically the start up script would be something like
/etc/modprobe.conf.
on each system boot. Typically configuration files are put in the
/etc/modprobe.d/ directory.
2.2 STATIC DRIVER CONFIGURATION:

10
Documentation/sound/alsa/ALSA-Configuration.txt
View File

@ -2044,7 +2044,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
Install the necessary firmware files in alsa-firmware package.
When no hotplug fw loader is available, you need to load the
firmware via vxloader utility in alsa-tools package. To invoke
vxloader automatically, add the following to /etc/modprobe.conf
vxloader automatically, add the following to /etc/modprobe.d/alsa.conf
install snd-vx222 /sbin/modprobe --first-time -i snd-vx222 && /usr/bin/vxloader
@ -2168,10 +2168,10 @@ corresponds to the card index of ALSA. Usually, define this
as the same card module.
An example configuration for a single emu10k1 card is like below:
----- /etc/modprobe.conf
----- /etc/modprobe.d/alsa.conf
alias snd-card-0 snd-emu10k1
alias sound-slot-0 snd-emu10k1
----- /etc/modprobe.conf
----- /etc/modprobe.d/alsa.conf
The available number of auto-loaded sound cards depends on the module
option "cards_limit" of snd module. As default it's set to 1.
@ -2184,7 +2184,7 @@ cards is kept consistent.
An example configuration for two sound cards is like below:
----- /etc/modprobe.conf
----- /etc/modprobe.d/alsa.conf
# ALSA portion
options snd cards_limit=2
alias snd-card-0 snd-interwave
@ -2194,7 +2194,7 @@ options snd-ens1371 index=1
# OSS/Free portion
alias sound-slot-0 snd-interwave
alias sound-slot-1 snd-ens1371
----- /etc/modprobe.conf
----- /etc/modprobe.d/alsa.conf
In this example, the interwave card is always loaded as the first card
(index 0) and ens1371 as the second (index 1).

4
Documentation/sound/alsa/Audiophile-Usb.txt
View File

@ -232,7 +232,7 @@ The parameter can be given:
# modprobe snd-usb-audio index=1 device_setup=0x09
* Or while configuring the modules options in your modules configuration file
- For Fedora distributions, edit the /etc/modprobe.conf file:
(tipically a .conf file in /etc/modprobe.d/ directory:
alias snd-card-1 snd-usb-audio
options snd-usb-audio index=1 device_setup=0x09
@ -253,7 +253,7 @@ CAUTION when initializing the device
- first turn off the device
- de-register the snd-usb-audio module (modprobe -r)
- change the device_setup parameter by changing the device_setup
option in /etc/modprobe.conf
option in /etc/modprobe.d/*.conf
- turn on the device
* A workaround for this last issue has been applied to kernel 2.6.23, but it may not
be enough to ensure the 'stability' of the device initialization.

6
Documentation/sound/alsa/MIXART.txt
View File

@ -76,9 +76,9 @@ FIRMWARE
when CONFIG_FW_LOADER is set. The mixartloader is necessary only
for older versions or when you build the driver into kernel.]
For loading the firmware automatically after the module is loaded, use
the post-install command. For example, add the following entry to
/etc/modprobe.conf for miXart driver:
For loading the firmware automatically after the module is loaded, use a
install command. For example, add the following entry to
/etc/modprobe.d/mixart.conf for miXart driver:
install snd-mixart /sbin/modprobe --first-time -i snd-mixart && \
/usr/bin/mixartloader

2
Documentation/sound/alsa/OSS-Emulation.txt
View File

@ -19,7 +19,7 @@ the card number and the minor unit number. Usually you don't have to
define these aliases by yourself.
Only necessary step for auto-loading of OSS modules is to define the
card alias in /etc/modprobe.conf, such as
card alias in /etc/modprobe.d/alsa.conf, such as
alias sound-slot-0 snd-emu10k1

10
Documentation/sound/oss/AudioExcelDSP16
View File

@ -41,7 +41,7 @@ mpu_base I/O base address for activate MPU-401 mode
(0x300, 0x310, 0x320 or 0x330)
mpu_irq MPU-401 irq line (5, 7, 9, 10 or 0)
The /etc/modprobe.conf will have lines like this:
A configuration file in /etc/modprobe.d/ directory will have lines like this:
options opl3 io=0x388
options ad1848 io=0x530 irq=11 dma=3
@ -51,11 +51,11 @@ Where the aedsp16 options are the options for this driver while opl3 and
ad1848 are the corresponding options for the MSS and OPL3 modules.
Loading MSS and OPL3 needs to pre load the aedsp16 module to set up correctly
the sound card. Installation dependencies must be written in the modprobe.conf
file:
the sound card. Installation dependencies must be written in configuration
files under /etc/modprobe.d/ directory:
install ad1848 /sbin/modprobe aedsp16 && /sbin/modprobe -i ad1848
install opl3 /sbin/modprobe aedsp16 && /sbin/modprobe -i opl3
softdep ad1848 pre: aedsp16
softdep opl3 pre: aedsp16
Then you must load the sound modules stack in this order:
sound -> aedsp16 -> [ ad1848, opl3 ]

5
Documentation/sound/oss/CMI8330
View File

@ -143,11 +143,10 @@ CONFIG_SOUND_MSS=m
Alma Chao <elysian@ethereal.torsion.org> suggests the following /etc/modprobe.conf:
Alma Chao <elysian@ethereal.torsion.org> suggests the following in
a /etc/modprobe.d/*conf file:
alias sound ad1848
alias synth0 opl3
options ad1848 io=0x530 irq=7 dma=0 soundpro=1
options opl3 io=0x388

10
Documentation/sound/oss/Introduction
View File

@ -167,8 +167,8 @@ in a file such as /root/soundon.sh.
MODPROBE:
=========
If loading via modprobe, these common files are automatically loaded
when requested by modprobe. For example, my /etc/modprobe.conf contains:
If loading via modprobe, these common files are automatically loaded when
requested by modprobe. For example, my /etc/modprobe.d/oss.conf contains:
alias sound sb
options sb io=0x240 irq=9 dma=3 dma16=5 mpu_io=0x300
@ -228,7 +228,7 @@ http://www.opensound.com. Before loading the commercial sound
driver, you should do the following:
1. remove sound modules (detailed above)
2. remove the sound modules from /etc/modprobe.conf
2. remove the sound modules from /etc/modprobe.d/*.conf
3. move the sound modules from /lib/modules/<kernel>/misc
(for example, I make a /lib/modules/<kernel>/misc/tmp
directory and copy the sound module files to that
@ -265,7 +265,7 @@ twice, you need to do the following:
sb.o could be copied (or symlinked) to sb1.o for the
second SoundBlaster.
2. Make a second entry in /etc/modprobe.conf, for example,
2. Make a second entry in /etc/modprobe.d/*conf, for example,
sound1 or sb1. This second entry should refer to the
new module names for example sb1, and should include
the I/O, etc. for the second sound card.
@ -369,7 +369,7 @@ There are several ways of configuring your sound:
2) On the command line when using insmod or in a bash script
using command line calls to load sound.
3) In /etc/modprobe.conf when using modprobe.
3) In /etc/modprobe.d/*conf when using modprobe.
4) Via Red Hat's GPL'd /usr/sbin/sndconfig program (text based).

8
Documentation/sound/oss/Opti
View File

@ -18,7 +18,7 @@ force the card into a mode in which it can be programmed.
If you have another OS installed on your computer it is recommended
that Linux and the other OS use the same resources.
Also, it is recommended that resources specified in /etc/modprobe.conf
Also, it is recommended that resources specified in /etc/modprobe.d/*.conf
and resources specified in /etc/isapnp.conf agree.
Compiling the sound driver
@ -67,11 +67,7 @@ address is hard-coded into the driver.
Using kmod and autoloading the sound driver
-------------------------------------------
Comment: as of linux-2.1.90 kmod is replacing kerneld.
The config file '/etc/modprobe.conf' is used as before.
This is the sound part of my /etc/modprobe.conf file.
Following that I will explain each line.
Config files in '/etc/modprobe.d/' are used as below:
alias mixer0 mad16
alias audio0 mad16

4
Documentation/sound/oss/PAS16
View File

@ -128,7 +128,7 @@ CONFIG_SOUND_YM3812
You can then get OPL3 functionality by issuing the command:
insmod opl3
In addition, you must either add the following line to
/etc/modprobe.conf:
/etc/modprobe.d/*.conf:
options opl3 io=0x388
or else add the following line to /etc/lilo.conf:
opl3=0x388
@ -158,5 +158,5 @@ following line would be appropriate:
append="pas2=0x388,10,3,-1,0,-1,-1,-1 opl3=0x388"
If sound is built totally modular, the above options may be
specified in /etc/modprobe.conf for pas2, sb and opl3
specified in /etc/modprobe.d/*.conf for pas2, sb and opl3
respectively.

10
Documentation/sound/oss/README.modules
View File

@ -26,7 +26,7 @@ Note that it is no longer necessary or possible to configure sound in the
drivers/sound dir. Now one simply configures and makes one's kernel and
modules in the usual way.
Then, add to your /etc/modprobe.conf something like:
Then, add to your /etc/modprobe.d/oss.conf something like:
alias char-major-14-* sb
install sb /sbin/modprobe -i sb && /sbin/modprobe adlib_card
@ -36,7 +36,7 @@ options adlib_card io=0x388 # FM synthesizer
Alternatively, if you have compiled in kernel level ISAPnP support:
alias char-major-14 sb
post-install sb /sbin/modprobe "-k" "adlib_card"
softdep sb post: adlib_card
options adlib_card io=0x388
The effect of this is that the sound driver and all necessary bits and
@ -66,12 +66,12 @@ args are expected.
Note that at present there is no way to configure the io, irq and other
parameters for the modular drivers as one does for the wired drivers.. One
needs to pass the modules the necessary parameters as arguments, either
with /etc/modprobe.conf or with command-line args to modprobe, e.g.
with /etc/modprobe.d/*.conf or with command-line args to modprobe, e.g.
modprobe sb io=0x220 irq=7 dma=1 dma16=5 mpu_io=0x330
modprobe adlib_card io=0x388
recommend using /etc/modprobe.conf.
recommend using /etc/modprobe.d/*.conf.
Persistent DMA Buffers:
@ -89,7 +89,7 @@ wasteful of RAM, but it guarantees that sound always works.
To make the sound driver use persistent DMA buffers we need to pass the
sound.o module a "dmabuf=1" command-line argument. This is normally done
in /etc/modprobe.conf like so:
in /etc/modprobe.d/*.conf files like so:
options sound dmabuf=1

5
Documentation/sysrq.txt
View File

@ -241,9 +241,8 @@ command you are interested in.
* I have more questions, who can I ask?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
And I'll answer any questions about the registration system you got, also
responding as soon as possible.
-Crutcher
Just ask them on the linux-kernel mailing list:
linux-kernel@vger.kernel.org
* Credits
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

3
Documentation/usb/power-management.txt
View File

@ -179,7 +179,8 @@ do:
modprobe usbcore autosuspend=5
Equivalently, you could add to /etc/modprobe.conf a line saying:
Equivalently, you could add to a configuration file in /etc/modprobe.d
a line saying:
options usbcore autosuspend=5

14
Documentation/video4linux/CQcam.txt
View File

@ -61,29 +61,19 @@ But that is my personal preference.
2.2 Configuration
The configuration requires module configuration and device
configuration. I like kmod or kerneld process with the
/etc/modprobe.conf file so the modules can automatically load/unload as
they are used. The video devices could already exist, be generated
using MAKEDEV, or need to be created. The following sections detail
these procedures.
configuration. The following sections detail these procedures.
2.1 Module Configuration
Using modules requires a bit of work to install and pass the
parameters. Understand that entries in /etc/modprobe.conf of:
parameters. Understand that entries in /etc/modprobe.d/*.conf of:
alias parport_lowlevel parport_pc
options parport_pc io=0x378 irq=none
alias char-major-81 videodev
alias char-major-81-0 c-qcam
will cause the kmod/modprobe to do certain things. If you are
using kmod, then a request for a 'char-major-81-0' will cause
the 'c-qcam' module to load. If you have other video sources with
modules, you might want to assign the different minor numbers to
different modules.
2.2 Device Configuration
At this point, we need to ensure that the device files exist.

2
Documentation/video4linux/Zoran
View File

@ -255,7 +255,7 @@ Load zr36067.o. If it can't autodetect your card, use the card=X insmod
option with X being the card number as given in the previous section.
To have more than one card, use card=X1[,X2[,X3,[X4[..]]]]
To automate this, add the following to your /etc/modprobe.conf:
To automate this, add the following to your /etc/modprobe.d/zoran.conf:
options zr36067 card=X1[,X2[,X3[,X4[..]]]]
alias char-major-81-0 zr36067

Some files were not shown because too many files have changed in this diff Show More