Merge tag 'v3.4-rc3' into staging/for_v3.5
* tag 'v3.4-rc3': (3755 commits) Linux 3.4-rc3 x86-32: fix up strncpy_from_user() sign error ARM: 7386/1: jump_label: fixup for rename to static_key ARM: 7384/1: ThumbEE: Disable userspace TEEHBR access for !CONFIG_ARM_THUMBEE ARM: 7382/1: mm: truncate memory banks to fit in 4GB space for classic MMU ARM: 7359/2: smp_twd: Only wait for reprogramming on active cpus PCI: Fix regression in pci_restore_state(), v3 SCSI: Fix error handling when no ULD is attached ARM: OMAP: clock: cleanup CPUfreq leftovers, fix build errors ARM: dts: remove blank interrupt-parent properties ARM: EXYNOS: Fix Kconfig dependencies for device tree enabled machine files do not export kernel's NULL #define to userspace ARM: EXYNOS: Remove broken config values for touchscren for NURI board ARM: EXYNOS: set fix xusbxti clock for NURI and Universal210 boards ARM: EXYNOS: fix regulator name for NURI board ARM: SAMSUNG: make SAMSUNG_PM_DEBUG select DEBUG_LL cpufreq: OMAP: fix build errors: depends on ARCH_OMAP2PLUS sparc64: Eliminate obsolete __handle_softirq() function sparc64: Fix bootup crash on sun4v. ARM: msm: Fix section mismatches in proc_comm.c ...
This commit is contained in:
Mauro Carvalho Chehab
Коммит
d5aeee8cb2
|
|
@ -1,5 +1,5 @@
|
|||
What: /sys/bus/usb/drivers/usbtmc/devices/*/interface_capabilities
|
||||
What: /sys/bus/usb/drivers/usbtmc/devices/*/device_capabilities
|
||||
What: /sys/bus/usb/drivers/usbtmc/*/interface_capabilities
|
||||
What: /sys/bus/usb/drivers/usbtmc/*/device_capabilities
|
||||
Date: August 2008
|
||||
Contact: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
||||
Description:
|
||||
|
|
@ -12,8 +12,8 @@ Description:
|
|||
The files are read only.
|
||||
|
||||
|
||||
What: /sys/bus/usb/drivers/usbtmc/devices/*/usb488_interface_capabilities
|
||||
What: /sys/bus/usb/drivers/usbtmc/devices/*/usb488_device_capabilities
|
||||
What: /sys/bus/usb/drivers/usbtmc/*/usb488_interface_capabilities
|
||||
What: /sys/bus/usb/drivers/usbtmc/*/usb488_device_capabilities
|
||||
Date: August 2008
|
||||
Contact: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
||||
Description:
|
||||
|
|
@ -27,7 +27,7 @@ Description:
|
|||
The files are read only.
|
||||
|
||||
|
||||
What: /sys/bus/usb/drivers/usbtmc/devices/*/TermChar
|
||||
What: /sys/bus/usb/drivers/usbtmc/*/TermChar
|
||||
Date: August 2008
|
||||
Contact: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
||||
Description:
|
||||
|
|
@ -40,7 +40,7 @@ Description:
|
|||
sent to the device or not.
|
||||
|
||||
|
||||
What: /sys/bus/usb/drivers/usbtmc/devices/*/TermCharEnabled
|
||||
What: /sys/bus/usb/drivers/usbtmc/*/TermCharEnabled
|
||||
Date: August 2008
|
||||
Contact: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
||||
Description:
|
||||
|
|
@ -51,11 +51,11 @@ Description:
|
|||
published by the USB-IF.
|
||||
|
||||
|
||||
What: /sys/bus/usb/drivers/usbtmc/devices/*/auto_abort
|
||||
What: /sys/bus/usb/drivers/usbtmc/*/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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
@ -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
|
||||
|
|
@ -0,0 +1,18 @@
|
|||
What: /sys/block/rssd*/registers
|
||||
Date: March 2012
|
||||
KernelVersion: 3.3
|
||||
Contact: Asai Thambi S P <asamymuthupa@micron.com>
|
||||
Description: This is a read-only file. Dumps below driver information and
|
||||
hardware registers.
|
||||
- S ACTive
|
||||
- Command Issue
|
||||
- Allocated
|
||||
- Completed
|
||||
- PORT IRQ STAT
|
||||
- HOST IRQ STAT
|
||||
|
||||
What: /sys/block/rssd*/status
|
||||
Date: April 2012
|
||||
KernelVersion: 3.4
|
||||
Contact: Asai Thambi S P <asamymuthupa@micron.com>
|
||||
Description: This is a read-only file. Indicates the status of the device.
|
||||
|
|
@ -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.
|
||||
|
|
@ -0,0 +1,75 @@
|
|||
What: /sys/bus/rpmsg/devices/.../name
|
||||
Date: June 2011
|
||||
KernelVersion: 3.3
|
||||
Contact: Ohad Ben-Cohen <ohad@wizery.com>
|
||||
Description:
|
||||
Every rpmsg device is a communication channel with a remote
|
||||
processor. Channels are identified with a (textual) name,
|
||||
which is maximum 32 bytes long (defined as RPMSG_NAME_SIZE in
|
||||
rpmsg.h).
|
||||
|
||||
This sysfs entry contains the name of this channel.
|
||||
|
||||
What: /sys/bus/rpmsg/devices/.../src
|
||||
Date: June 2011
|
||||
KernelVersion: 3.3
|
||||
Contact: Ohad Ben-Cohen <ohad@wizery.com>
|
||||
Description:
|
||||
Every rpmsg device is a communication channel with a remote
|
||||
processor. Channels have a local ("source") rpmsg address,
|
||||
and remote ("destination") rpmsg address. When an entity
|
||||
starts listening on one end of a channel, it assigns it with
|
||||
a unique rpmsg address (a 32 bits integer). This way when
|
||||
inbound messages arrive to this address, the rpmsg core
|
||||
dispatches them to the listening entity (a kernel driver).
|
||||
|
||||
This sysfs entry contains the src (local) rpmsg address
|
||||
of this channel. If it contains 0xffffffff, then an address
|
||||
wasn't assigned (can happen if no driver exists for this
|
||||
channel).
|
||||
|
||||
What: /sys/bus/rpmsg/devices/.../dst
|
||||
Date: June 2011
|
||||
KernelVersion: 3.3
|
||||
Contact: Ohad Ben-Cohen <ohad@wizery.com>
|
||||
Description:
|
||||
Every rpmsg device is a communication channel with a remote
|
||||
processor. Channels have a local ("source") rpmsg address,
|
||||
and remote ("destination") rpmsg address. When an entity
|
||||
starts listening on one end of a channel, it assigns it with
|
||||
a unique rpmsg address (a 32 bits integer). This way when
|
||||
inbound messages arrive to this address, the rpmsg core
|
||||
dispatches them to the listening entity.
|
||||
|
||||
This sysfs entry contains the dst (remote) rpmsg address
|
||||
of this channel. If it contains 0xffffffff, then an address
|
||||
wasn't assigned (can happen if the kernel driver that
|
||||
is attached to this channel is exposing a service to the
|
||||
remote processor. This make it a local rpmsg server,
|
||||
and it is listening for inbound messages that may be sent
|
||||
from any remote rpmsg client; it is not bound to a single
|
||||
remote entity).
|
||||
|
||||
What: /sys/bus/rpmsg/devices/.../announce
|
||||
Date: June 2011
|
||||
KernelVersion: 3.3
|
||||
Contact: Ohad Ben-Cohen <ohad@wizery.com>
|
||||
Description:
|
||||
Every rpmsg device is a communication channel with a remote
|
||||
processor. Channels are identified by a textual name (see
|
||||
/sys/bus/rpmsg/devices/.../name above) and have a local
|
||||
("source") rpmsg address, and remote ("destination") rpmsg
|
||||
address.
|
||||
|
||||
A channel is first created when an entity, whether local
|
||||
or remote, starts listening on it for messages (and is thus
|
||||
called an rpmsg server).
|
||||
|
||||
When that happens, a "name service" announcement is sent
|
||||
to the other processor, in order to let it know about the
|
||||
creation of the channel (this way remote clients know they
|
||||
can start sending messages).
|
||||
|
||||
This sysfs entry tells us whether the channel is a local
|
||||
server channel that is announced (values are either
|
||||
true or false).
|
||||
|
|
@ -0,0 +1,8 @@
|
|||
What: /sys/block/<device>/iosched/target_latency
|
||||
Date: March 2012
|
||||
contact: Tao Ma <boyu.mt@taobao.com>
|
||||
Description:
|
||||
The /sys/block/<device>/iosched/target_latency only exists
|
||||
when the user sets cfq to /sys/block/<device>/scheduler.
|
||||
It contains an estimated latency time for the cfq. cfq will
|
||||
use it to calculate the time slice used for every task.
|
||||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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>
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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>
|
||||
|
|
|
|||
|
|
@ -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/
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -34,8 +34,7 @@ Current Status: linux-2.6.34-mmotm(development version of 2010/April)
|
|||
|
||||
Features:
|
||||
- accounting anonymous pages, file caches, swap caches usage and limiting them.
|
||||
- private LRU and reclaim routine. (system's global LRU and private LRU
|
||||
work independently from each other)
|
||||
- pages are linked to per-memcg LRU exclusively, and there is no global LRU.
|
||||
- optionally, memory+swap usage can be accounted and limited.
|
||||
- hierarchical accounting
|
||||
- soft limit
|
||||
|
|
@ -154,7 +153,7 @@ updated. page_cgroup has its own LRU on cgroup.
|
|||
2.2.1 Accounting details
|
||||
|
||||
All mapped anon pages (RSS) and cache pages (Page Cache) are accounted.
|
||||
Some pages which are never reclaimable and will not be on the global LRU
|
||||
Some pages which are never reclaimable and will not be on the LRU
|
||||
are not accounted. We just account pages under usual VM management.
|
||||
|
||||
RSS pages are accounted at page_fault unless they've already been accounted
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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)
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
@ -0,0 +1,38 @@
|
|||
* Advanced Interrupt Controller (AIC)
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be "atmel,<chip>-aic"
|
||||
- interrupt-controller: Identifies the node as an interrupt controller.
|
||||
- interrupt-parent: For single AIC system, it is an empty property.
|
||||
- #interrupt-cells: The number of cells to define the interrupts. It sould be 2.
|
||||
The first cell is the IRQ number (aka "Peripheral IDentifier" on datasheet).
|
||||
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.
|
||||
Valid combinations are 1, 2, 3, 4, 8.
|
||||
Default flag for internal sources should be set to 4 (active high).
|
||||
- reg: Should contain AIC registers location and length
|
||||
|
||||
Examples:
|
||||
/*
|
||||
* AIC
|
||||
*/
|
||||
aic: interrupt-controller@fffff000 {
|
||||
compatible = "atmel,at91rm9200-aic";
|
||||
interrupt-controller;
|
||||
interrupt-parent;
|
||||
#interrupt-cells = <2>;
|
||||
reg = <0xfffff000 0x200>;
|
||||
};
|
||||
|
||||
/*
|
||||
* An interrupt generating device that is wired to an AIC.
|
||||
*/
|
||||
dma: dma-controller@ffffec00 {
|
||||
compatible = "atmel,at91sam9g45-dma";
|
||||
reg = <0xffffec00 0x200>;
|
||||
interrupts = <21 4>;
|
||||
};
|
||||
|
|
@ -0,0 +1,92 @@
|
|||
Atmel AT91 device tree bindings.
|
||||
================================
|
||||
|
||||
PIT Timer required properties:
|
||||
- compatible: Should be "atmel,at91sam9260-pit"
|
||||
- reg: Should contain registers location and length
|
||||
- interrupts: Should contain interrupt for the PIT which is the IRQ line
|
||||
shared across all System Controller members.
|
||||
|
||||
TC/TCLIB Timer required properties:
|
||||
- compatible: Should be "atmel,<chip>-pit".
|
||||
<chip> can be "at91rm9200" or "at91sam9x5"
|
||||
- reg: Should contain registers location and length
|
||||
- interrupts: Should contain all interrupts for the TC block
|
||||
Note that you can specify several interrupt cells if the TC
|
||||
block has one interrupt per channel.
|
||||
|
||||
Examples:
|
||||
|
||||
One interrupt per TC block:
|
||||
tcb0: timer@fff7c000 {
|
||||
compatible = "atmel,at91rm9200-tcb";
|
||||
reg = <0xfff7c000 0x100>;
|
||||
interrupts = <18 4>;
|
||||
};
|
||||
|
||||
One interrupt per TC channel in a TC block:
|
||||
tcb1: timer@fffdc000 {
|
||||
compatible = "atmel,at91rm9200-tcb";
|
||||
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>;
|
||||
};
|
||||
|
|
@ -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>;
|
||||
};
|
||||
|
|
@ -28,3 +28,25 @@ Required root node properties:
|
|||
i.MX6 Quad SABRE Lite Board
|
||||
Required root node properties:
|
||||
- compatible = "fsl,imx6q-sabrelite", "fsl,imx6q";
|
||||
|
||||
Generic i.MX boards
|
||||
-------------------
|
||||
|
||||
No iomux setup is done for these boards, so this must have been configured
|
||||
by the bootloader for boards to work with the generic bindings.
|
||||
|
||||
i.MX27 generic board
|
||||
Required root node properties:
|
||||
- compatible = "fsl,imx27";
|
||||
|
||||
i.MX51 generic board
|
||||
Required root node properties:
|
||||
- compatible = "fsl,imx51";
|
||||
|
||||
i.MX53 generic board
|
||||
Required root node properties:
|
||||
- compatible = "fsl,imx53";
|
||||
|
||||
i.MX6q generic board
|
||||
Required root node properties:
|
||||
- compatible = "fsl,imx6q";
|
||||
|
|
|
|||
|
|
@ -0,0 +1,6 @@
|
|||
Marvell Platforms Device Tree Bindings
|
||||
----------------------------------------------------
|
||||
|
||||
PXA168 Aspenite Board
|
||||
Required root node properties:
|
||||
- compatible = "mrvl,pxa168-aspenite", "mrvl,pxa168";
|
||||
|
|
@ -0,0 +1,27 @@
|
|||
* OMAP Interrupt Controller
|
||||
|
||||
OMAP2/3 are using a TI interrupt controller that can support several
|
||||
configurable number of interrupts.
|
||||
|
||||
Main node required properties:
|
||||
|
||||
- compatible : should be:
|
||||
"ti,omap2-intc"
|
||||
- interrupt-controller : Identifies the node as an interrupt controller
|
||||
- #interrupt-cells : Specifies the number of cells needed to encode an
|
||||
interrupt source. The type shall be a <u32> and the value shall be 1.
|
||||
|
||||
The cell contains the interrupt number in the range [0-128].
|
||||
- ti,intc-size: Number of interrupts handled by the interrupt controller.
|
||||
- reg: physical base address and size of the intc registers map.
|
||||
|
||||
Example:
|
||||
|
||||
intc: interrupt-controller@1 {
|
||||
compatible = "ti,omap2-intc";
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <1>;
|
||||
ti,intc-size = <96>;
|
||||
reg = <0x48200000 0x1000>;
|
||||
};
|
||||
|
||||
|
|
@ -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";
|
||||
|
|
@ -0,0 +1,100 @@
|
|||
Embedded Memory Controller
|
||||
|
||||
Properties:
|
||||
- name : Should be emc
|
||||
- #address-cells : Should be 1
|
||||
- #size-cells : Should be 0
|
||||
- compatible : Should contain "nvidia,tegra20-emc".
|
||||
- reg : Offset and length of the register set for the device
|
||||
- nvidia,use-ram-code : If present, the sub-nodes will be addressed
|
||||
and chosen using the ramcode board selector. If omitted, only one
|
||||
set of tables can be present and said tables will be used
|
||||
irrespective of ram-code configuration.
|
||||
|
||||
Child device nodes describe the memory settings for different configurations and clock rates.
|
||||
|
||||
Example:
|
||||
|
||||
emc@7000f400 {
|
||||
#address-cells = < 1 >;
|
||||
#size-cells = < 0 >;
|
||||
compatible = "nvidia,tegra20-emc";
|
||||
reg = <0x7000f4000 0x200>;
|
||||
}
|
||||
|
||||
|
||||
Embedded Memory Controller ram-code table
|
||||
|
||||
If the emc node has the nvidia,use-ram-code property present, then the
|
||||
next level of nodes below the emc table are used to specify which settings
|
||||
apply for which ram-code settings.
|
||||
|
||||
If the emc node lacks the nvidia,use-ram-code property, this level is omitted
|
||||
and the tables are stored directly under the emc node (see below).
|
||||
|
||||
Properties:
|
||||
|
||||
- name : Should be emc-tables
|
||||
- nvidia,ram-code : the binary representation of the ram-code board strappings
|
||||
for which this node (and children) are valid.
|
||||
|
||||
|
||||
|
||||
Embedded Memory Controller configuration table
|
||||
|
||||
This is a table containing the EMC register settings for the various
|
||||
operating speeds of the memory controller. They are always located as
|
||||
subnodes of the emc controller node.
|
||||
|
||||
There are two ways of specifying which tables to use:
|
||||
|
||||
* The simplest is if there is just one set of tables in the device tree,
|
||||
and they will always be used (based on which frequency is used).
|
||||
This is the preferred method, especially when firmware can fill in
|
||||
this information based on the specific system information and just
|
||||
pass it on to the kernel.
|
||||
|
||||
* The slightly more complex one is when more than one memory configuration
|
||||
might exist on the system. The Tegra20 platform handles this during
|
||||
early boot by selecting one out of possible 4 memory settings based
|
||||
on a 2-pin "ram code" bootstrap setting on the board. The values of
|
||||
these strappings can be read through a register in the SoC, and thus
|
||||
used to select which tables to use.
|
||||
|
||||
Properties:
|
||||
- name : Should be emc-table
|
||||
- compatible : Should contain "nvidia,tegra20-emc-table".
|
||||
- reg : either an opaque enumerator to tell different tables apart, or
|
||||
the valid frequency for which the table should be used (in kHz).
|
||||
- clock-frequency : the clock frequency for the EMC at which this
|
||||
table should be used (in kHz).
|
||||
- nvidia,emc-registers : a 46 word array of EMC registers to be programmed
|
||||
for operation at the 'clock-frequency' setting.
|
||||
The order and contents of the registers are:
|
||||
RC, RFC, RAS, RP, R2W, W2R, R2P, W2P, RD_RCD, WR_RCD, RRD, REXT,
|
||||
WDV, QUSE, QRST, QSAFE, RDV, REFRESH, BURST_REFRESH_NUM, PDEX2WR,
|
||||
PDEX2RD, PCHG2PDEN, ACT2PDEN, AR2PDEN, RW2PDEN, TXSR, TCKE, TFAW,
|
||||
TRPAB, TCLKSTABLE, TCLKSTOP, TREFBW, QUSE_EXTRA, FBIO_CFG6, ODT_WRITE,
|
||||
ODT_READ, FBIO_CFG5, CFG_DIG_DLL, DLL_XFORM_DQS, DLL_XFORM_QUSE,
|
||||
ZCAL_REF_CNT, ZCAL_WAIT_CNT, AUTO_CAL_INTERVAL, CFG_CLKTRIM_0,
|
||||
CFG_CLKTRIM_1, CFG_CLKTRIM_2
|
||||
|
||||
emc-table@166000 {
|
||||
reg = <166000>;
|
||||
compatible = "nvidia,tegra20-emc-table";
|
||||
clock-frequency = < 166000 >;
|
||||
nvidia,emc-registers = < 0 0 0 0 0 0 0 0 0 0 0 0 0 0
|
||||
0 0 0 0 0 0 0 0 0 0 0 0 0 0
|
||||
0 0 0 0 0 0 0 0 0 0 0 0 0 0
|
||||
0 0 0 0 >;
|
||||
};
|
||||
|
||||
emc-table@333000 {
|
||||
reg = <333000>;
|
||||
compatible = "nvidia,tegra20-emc-table";
|
||||
clock-frequency = < 333000 >;
|
||||
nvidia,emc-registers = < 0 0 0 0 0 0 0 0 0 0 0 0 0 0
|
||||
0 0 0 0 0 0 0 0 0 0 0 0 0 0
|
||||
0 0 0 0 0 0 0 0 0 0 0 0 0 0
|
||||
0 0 0 0 >;
|
||||
};
|
||||
|
|
@ -0,0 +1,19 @@
|
|||
NVIDIA Tegra Power Management Controller (PMC)
|
||||
|
||||
Properties:
|
||||
- name : Should be pmc
|
||||
- compatible : Should contain "nvidia,tegra<chip>-pmc".
|
||||
- reg : Offset and length of the register set for the device
|
||||
- nvidia,invert-interrupt : If present, inverts the PMU interrupt signal.
|
||||
The PMU is an external Power Management Unit, whose interrupt output
|
||||
signal is fed into the PMC. This signal is optionally inverted, and then
|
||||
fed into the ARM GIC. The PMC is not involved in the detection or
|
||||
handling of this interrupt signal, merely its inversion.
|
||||
|
||||
Example:
|
||||
|
||||
pmc@7000f400 {
|
||||
compatible = "nvidia,tegra20-pmc";
|
||||
reg = <0x7000e400 0x400>;
|
||||
nvidia,invert-interrupt;
|
||||
};
|
||||
|
|
@ -0,0 +1,48 @@
|
|||
* ARM Timer Watchdog
|
||||
|
||||
ARM 11MP, Cortex-A5 and Cortex-A9 are often associated with a per-core
|
||||
Timer-Watchdog (aka TWD), which provides both a per-cpu local timer
|
||||
and watchdog.
|
||||
|
||||
The TWD is usually attached to a GIC to deliver its two per-processor
|
||||
interrupts.
|
||||
|
||||
** Timer node required properties:
|
||||
|
||||
- compatible : Should be one of:
|
||||
"arm,cortex-a9-twd-timer"
|
||||
"arm,cortex-a5-twd-timer"
|
||||
"arm,arm11mp-twd-timer"
|
||||
|
||||
- interrupts : One interrupt to each core
|
||||
|
||||
- reg : Specify the base address and the size of the TWD timer
|
||||
register window.
|
||||
|
||||
Example:
|
||||
|
||||
twd-timer@2c000600 {
|
||||
compatible = "arm,arm11mp-twd-timer"";
|
||||
reg = <0x2c000600 0x20>;
|
||||
interrupts = <1 13 0xf01>;
|
||||
};
|
||||
|
||||
** Watchdog node properties:
|
||||
|
||||
- compatible : Should be one of:
|
||||
"arm,cortex-a9-twd-wdt"
|
||||
"arm,cortex-a5-twd-wdt"
|
||||
"arm,arm11mp-twd-wdt"
|
||||
|
||||
- interrupts : One interrupt to each core
|
||||
|
||||
- reg : Specify the base address and the size of the TWD watchdog
|
||||
register window.
|
||||
|
||||
Example:
|
||||
|
||||
twd-watchdog@2c000620 {
|
||||
compatible = "arm,arm11mp-twd-wdt";
|
||||
reg = <0x2c000620 0x20>;
|
||||
interrupts = <1 14 0xf01>;
|
||||
};
|
||||
|
|
@ -0,0 +1,146 @@
|
|||
ARM Versatile Express boards family
|
||||
-----------------------------------
|
||||
|
||||
ARM's Versatile Express platform consists of a motherboard and one
|
||||
or more daughterboards (tiles). The motherboard provides a set of
|
||||
peripherals. Processor and RAM "live" on the tiles.
|
||||
|
||||
The motherboard and each core tile should be described by a separate
|
||||
Device Tree source file, with the tile's description including
|
||||
the motherboard file using a /include/ directive. As the motherboard
|
||||
can be initialized in one of two different configurations ("memory
|
||||
maps"), care must be taken to include the correct one.
|
||||
|
||||
Required properties in the root node:
|
||||
- compatible value:
|
||||
compatible = "arm,vexpress,<model>", "arm,vexpress";
|
||||
where <model> is the full tile model name (as used in the tile's
|
||||
Technical Reference Manual), eg.:
|
||||
- for Coretile Express A5x2 (V2P-CA5s):
|
||||
compatible = "arm,vexpress,v2p-ca5s", "arm,vexpress";
|
||||
- for Coretile Express A9x4 (V2P-CA9):
|
||||
compatible = "arm,vexpress,v2p-ca9", "arm,vexpress";
|
||||
If a tile comes in several variants or can be used in more then one
|
||||
configuration, the compatible value should be:
|
||||
compatible = "arm,vexpress,<model>,<variant>", \
|
||||
"arm,vexpress,<model>", "arm,vexpress";
|
||||
eg:
|
||||
- Coretile Express A15x2 (V2P-CA15) with Tech Chip 1:
|
||||
compatible = "arm,vexpress,v2p-ca15,tc1", \
|
||||
"arm,vexpress,v2p-ca15", "arm,vexpress";
|
||||
- LogicTile Express 13MG (V2F-2XV6) running Cortex-A7 (3 cores) SMM:
|
||||
compatible = "arm,vexpress,v2f-2xv6,ca7x3", \
|
||||
"arm,vexpress,v2f-2xv6", "arm,vexpress";
|
||||
|
||||
Optional properties in the root node:
|
||||
- tile model name (use name from the tile's Technical Reference
|
||||
Manual, eg. "V2P-CA5s")
|
||||
model = "<model>";
|
||||
- tile's HBI number (unique ARM's board model ID, visible on the
|
||||
PCB's silkscreen) in hexadecimal transcription:
|
||||
arm,hbi = <0xhbi>
|
||||
eg:
|
||||
- for Coretile Express A5x2 (V2P-CA5s) HBI-0191:
|
||||
arm,hbi = <0x191>;
|
||||
- Coretile Express A9x4 (V2P-CA9) HBI-0225:
|
||||
arm,hbi = <0x225>;
|
||||
|
||||
Top-level standard "cpus" node is required. It must contain a node
|
||||
with device_type = "cpu" property for every available core, eg.:
|
||||
|
||||
cpus {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
cpu@0 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a5";
|
||||
reg = <0>;
|
||||
};
|
||||
};
|
||||
|
||||
The motherboard description file provides a single "motherboard" node
|
||||
using 2 address cells corresponding to the Static Memory Bus used
|
||||
between the motherboard and the tile. The first cell defines the Chip
|
||||
Select (CS) line number, the second cell address offset within the CS.
|
||||
All interrupt lines between the motherboard and the tile are active
|
||||
high and are described using single cell.
|
||||
|
||||
Optional properties of the "motherboard" node:
|
||||
- motherboard's memory map variant:
|
||||
arm,v2m-memory-map = "<name>";
|
||||
where name is one of:
|
||||
- "rs1" - for RS1 map (i.a. peripherals on CS3); this map is also
|
||||
referred to as "ARM Cortex-A Series memory map":
|
||||
arm,v2m-memory-map = "rs1";
|
||||
When this property is missing, the motherboard is using the original
|
||||
memory map (also known as the "Legacy memory map", primarily used
|
||||
with the original CoreTile Express A9x4) with peripherals on CS7.
|
||||
|
||||
Motherboard .dtsi files provide a set of labelled peripherals that
|
||||
can be used to obtain required phandle in the tile's "aliases" node:
|
||||
- UARTs, note that the numbers correspond to the physical connectors
|
||||
on the motherboard's back panel:
|
||||
v2m_serial0, v2m_serial1, v2m_serial2 and v2m_serial3
|
||||
- I2C controllers:
|
||||
v2m_i2c_dvi and v2m_i2c_pcie
|
||||
- SP804 timers:
|
||||
v2m_timer01 and v2m_timer23
|
||||
|
||||
Current Linux implementation requires a "arm,v2m_timer" alias
|
||||
pointing at one of the motherboard's SP804 timers, if it is to be
|
||||
used as the system timer. This alias should be defined in the
|
||||
motherboard files.
|
||||
|
||||
The tile description must define "ranges", "interrupt-map-mask" and
|
||||
"interrupt-map" properties to translate the motherboard's address
|
||||
and interrupt space into one used by the tile's processor.
|
||||
|
||||
Abbreviated example:
|
||||
|
||||
/dts-v1/;
|
||||
|
||||
/ {
|
||||
model = "V2P-CA5s";
|
||||
arm,hbi = <0x225>;
|
||||
compatible = "arm,vexpress-v2p-ca5s", "arm,vexpress";
|
||||
interrupt-parent = <&gic>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
|
||||
chosen { };
|
||||
|
||||
aliases {
|
||||
serial0 = &v2m_serial0;
|
||||
};
|
||||
|
||||
cpus {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
cpu@0 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a5";
|
||||
reg = <0>;
|
||||
};
|
||||
};
|
||||
|
||||
gic: interrupt-controller@2c001000 {
|
||||
compatible = "arm,cortex-a9-gic";
|
||||
#interrupt-cells = <3>;
|
||||
#address-cells = <0>;
|
||||
interrupt-controller;
|
||||
reg = <0x2c001000 0x1000>,
|
||||
<0x2c000100 0x100>;
|
||||
};
|
||||
|
||||
motherboard {
|
||||
/* CS0 is visible at 0x08000000 */
|
||||
ranges = <0 0 0x08000000 0x04000000>;
|
||||
interrupt-map-mask = <0 0 63>;
|
||||
/* Active high IRQ 0 is connected to GIC's SPI0 */
|
||||
interrupt-map = <0 0 0 &gic 0 0 4>;
|
||||
};
|
||||
};
|
||||
|
||||
/include/ "vexpress-v2m-rs1.dtsi"
|
||||
|
|
@ -0,0 +1,30 @@
|
|||
* NVIDIA Tegra APB DMA controller
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be "nvidia,<chip>-apbdma"
|
||||
- reg: Should contain DMA registers location and length. This shuld include
|
||||
all of the per-channel registers.
|
||||
- interrupts: Should contain all of the per-channel DMA interrupts.
|
||||
|
||||
Examples:
|
||||
|
||||
apbdma: dma@6000a000 {
|
||||
compatible = "nvidia,tegra20-apbdma";
|
||||
reg = <0x6000a000 0x1200>;
|
||||
interrupts = < 0 136 0x04
|
||||
0 137 0x04
|
||||
0 138 0x04
|
||||
0 139 0x04
|
||||
0 140 0x04
|
||||
0 141 0x04
|
||||
0 142 0x04
|
||||
0 143 0x04
|
||||
0 144 0x04
|
||||
0 145 0x04
|
||||
0 146 0x04
|
||||
0 147 0x04
|
||||
0 148 0x04
|
||||
0 149 0x04
|
||||
0 150 0x04
|
||||
0 151 0x04 >;
|
||||
};
|
||||
|
|
@ -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;
|
||||
};
|
||||
|
|
@ -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;
|
||||
};
|
||||
|
|
@ -0,0 +1,20 @@
|
|||
* Atmel GPIO controller (PIO)
|
||||
|
||||
Required properties:
|
||||
- compatible: "atmel,<chip>-gpio", where <chip> is at91rm9200 or at91sam9x5.
|
||||
- reg: Should contain GPIO controller registers location and length
|
||||
- interrupts: Should be the port interrupt shared by all the pins.
|
||||
- #gpio-cells: Should be two. The first cell is the pin number and
|
||||
the second cell is used to specify optional parameters (currently
|
||||
unused).
|
||||
- gpio-controller: Marks the device node as a GPIO controller.
|
||||
|
||||
Example:
|
||||
pioA: gpio@fffff200 {
|
||||
compatible = "atmel,at91rm9200-gpio";
|
||||
reg = <0xfffff200 0x100>;
|
||||
interrupts = <2 4>;
|
||||
#gpio-cells = <2>;
|
||||
gpio-controller;
|
||||
};
|
||||
|
||||
|
|
@ -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>;
|
||||
};
|
||||
};
|
||||
|
|
@ -1,8 +1,40 @@
|
|||
NVIDIA Tegra 2 GPIO controller
|
||||
NVIDIA Tegra GPIO controller
|
||||
|
||||
Required properties:
|
||||
- compatible : "nvidia,tegra20-gpio"
|
||||
- compatible : "nvidia,tegra<chip>-gpio"
|
||||
- reg : Physical base address and length of the controller's registers.
|
||||
- interrupts : The interrupt outputs from the controller. For Tegra20,
|
||||
there should be 7 interrupts specified, and for Tegra30, there should
|
||||
be 8 interrupts specified.
|
||||
- #gpio-cells : Should be two. The first cell is the pin number and the
|
||||
second cell is used to specify optional parameters:
|
||||
- bit 0 specifies polarity (0 for normal, 1 for inverted)
|
||||
- gpio-controller : Marks the device node as a GPIO controller.
|
||||
- #interrupt-cells : Should be 2.
|
||||
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.
|
||||
Valid combinations are 1, 2, 3, 4, 8.
|
||||
- interrupt-controller : Marks the device node as an interrupt controller.
|
||||
|
||||
Example:
|
||||
|
||||
gpio: gpio@6000d000 {
|
||||
compatible = "nvidia,tegra20-gpio";
|
||||
reg = < 0x6000d000 0x1000 >;
|
||||
interrupts = < 0 32 0x04
|
||||
0 33 0x04
|
||||
0 34 0x04
|
||||
0 35 0x04
|
||||
0 55 0x04
|
||||
0 87 0x04
|
||||
0 89 0x04 >;
|
||||
#gpio-cells = <2>;
|
||||
gpio-controller;
|
||||
#interrupt-cells = <2>;
|
||||
interrupt-controller;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -0,0 +1,23 @@
|
|||
* Marvell PXA GPIO controller
|
||||
|
||||
Required properties:
|
||||
- compatible : Should be "mrvl,pxa-gpio" or "mrvl,mmp-gpio"
|
||||
- reg : Address and length of the register set for the device
|
||||
- interrupts : Should be the port interrupt shared by all gpio pins, if
|
||||
- interrupt-name : Should be the name of irq resource.
|
||||
one number.
|
||||
- gpio-controller : Marks the device node as a gpio controller.
|
||||
- #gpio-cells : Should be one. It is the pin number.
|
||||
|
||||
Example:
|
||||
|
||||
gpio: gpio@d4019000 {
|
||||
compatible = "mrvl,mmp-gpio", "mrvl,pxa-gpio";
|
||||
reg = <0xd4019000 0x1000>;
|
||||
interrupts = <49>, <17>, <18>;
|
||||
interrupt-name = "gpio_mux", "gpio0", "gpio1";
|
||||
gpio-controller;
|
||||
#gpio-cells = <1>;
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <1>;
|
||||
};
|
||||
|
|
@ -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>;
|
||||
};
|
||||
|
|
@ -0,0 +1,37 @@
|
|||
* I2C
|
||||
|
||||
Required properties :
|
||||
|
||||
- reg : Offset and length of the register set for the device
|
||||
- compatible : should be "mrvl,mmp-twsi" where CHIP is the name of a
|
||||
compatible processor, e.g. pxa168, pxa910, mmp2, mmp3.
|
||||
For the pxa2xx/pxa3xx, an additional node "mrvl,pxa-i2c" is required
|
||||
as shown in the example below.
|
||||
|
||||
Recommended properties :
|
||||
|
||||
- interrupts : <a b> where a is the interrupt number and b is a
|
||||
field that represents an encoding of the sense and level
|
||||
information for the interrupt. This should be encoded based on
|
||||
the information in section 2) depending on the type of interrupt
|
||||
controller you have.
|
||||
- interrupt-parent : the phandle for the interrupt controller that
|
||||
services interrupts for this device.
|
||||
- mrvl,i2c-polling : Disable interrupt of i2c controller. Polling
|
||||
status register of i2c controller instead.
|
||||
- mrvl,i2c-fast-mode : Enable fast mode of i2c controller.
|
||||
|
||||
Examples:
|
||||
twsi1: i2c@d4011000 {
|
||||
compatible = "mrvl,mmp-twsi", "mrvl,pxa-i2c";
|
||||
reg = <0xd4011000 0x1000>;
|
||||
interrupts = <7>;
|
||||
mrvl,i2c-fast-mode;
|
||||
};
|
||||
|
||||
twsi2: i2c@d4025000 {
|
||||
compatible = "mrvl,mmp-twsi", "mrvl,pxa-i2c";
|
||||
reg = <0xd4025000 0x1000>;
|
||||
interrupts = <58>;
|
||||
};
|
||||
|
||||
|
|
@ -0,0 +1,19 @@
|
|||
I2C for SiRFprimaII platforms
|
||||
|
||||
Required properties :
|
||||
- compatible : Must be "sirf,prima2-i2c"
|
||||
- reg: physical base address of the controller and length of memory mapped
|
||||
region.
|
||||
- interrupts: interrupt number to the cpu.
|
||||
|
||||
Optional properties:
|
||||
- clock-frequency : Constains desired I2C/HS-I2C bus clock frequency in Hz.
|
||||
The absence of the propoerty indicates the default frequency 100 kHz.
|
||||
|
||||
Examples :
|
||||
|
||||
i2c0: i2c@b00e0000 {
|
||||
compatible = "sirf,prima2-i2c";
|
||||
reg = <0xb00e0000 0x10000>;
|
||||
interrupts = <24>;
|
||||
};
|
||||
|
|
@ -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,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,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 {
|
||||
|
|
|
|||
|
|
@ -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 {
|
||||
...
|
||||
};
|
||||
};
|
||||
|
|
@ -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 {
|
||||
|
|
|
|||
|
|
@ -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 {
|
||||
...
|
||||
};
|
||||
};
|
||||
|
|
@ -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,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:
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
@ -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>;
|
||||
};
|
||||
];
|
||||
|
|
@ -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;
|
||||
...
|
||||
};
|
||||
};
|
||||
|
|
@ -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>;
|
||||
};
|
||||
|
|
@ -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>;
|
||||
};
|
||||
|
|
@ -0,0 +1,17 @@
|
|||
* Marvell Real Time Clock controller
|
||||
|
||||
Required properties:
|
||||
- compatible: should be "mrvl,sa1100-rtc"
|
||||
- reg: physical base address of the controller and length of memory mapped
|
||||
region.
|
||||
- interrupts: Should be two. The first interrupt number is the rtc alarm
|
||||
interrupt and the second interrupt number is the rtc hz interrupt.
|
||||
- interrupt-names: Assign name of irq resource.
|
||||
|
||||
Example:
|
||||
rtc: rtc@d4010000 {
|
||||
compatible = "mrvl,mmp-rtc";
|
||||
reg = <0xd4010000 0x1000>;
|
||||
interrupts = <5>, <6>;
|
||||
interrupt-name = "rtc 1Hz", "rtc alarm";
|
||||
};
|
||||
|
|
@ -0,0 +1,4 @@
|
|||
PXA UART controller
|
||||
|
||||
Required properties:
|
||||
- compatible : should be "mrvl,mmp-uart" or "mrvl,pxa-uart".
|
||||
|
|
@ -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>;
|
||||
};
|
||||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
@ -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/
|
||||
|
|
|
|||
|
|
@ -158,7 +158,6 @@ logo_*.c
|
|||
logo_*_clut224.c
|
||||
logo_*_mono.c
|
||||
lxdialog
|
||||
mach
|
||||
mach-types
|
||||
mach-types.h
|
||||
machtypes.h
|
||||
|
|
|
|||
|
|
@ -334,8 +334,8 @@ Sdram memory scrubbing rate:
|
|||
|
||||
Reading the file will return the actual scrubbing rate employed.
|
||||
|
||||
If configuration fails or memory scrubbing is not implemented, the value
|
||||
of the attribute file will be -1.
|
||||
If configuration fails or memory scrubbing is not implemented, accessing
|
||||
that attribute will fail.
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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,
|
||||
|
|
@ -513,20 +505,6 @@ Who: Bjorn Helgaas <bhelgaas@google.com>
|
|||
|
||||
----------------------------
|
||||
|
||||
What: The CAP9 SoC family will be removed
|
||||
When: 3.4
|
||||
Files: arch/arm/mach-at91/at91cap9.c
|
||||
arch/arm/mach-at91/at91cap9_devices.c
|
||||
arch/arm/mach-at91/include/mach/at91cap9.h
|
||||
arch/arm/mach-at91/include/mach/at91cap9_matrix.h
|
||||
arch/arm/mach-at91/include/mach/at91cap9_ddrsdr.h
|
||||
arch/arm/mach-at91/board-cap9adk.c
|
||||
Why: The code is not actively maintained and platforms are now hard to find.
|
||||
Who: Nicolas Ferre <nicolas.ferre@atmel.com>
|
||||
Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: Low Performance USB Block driver ("CONFIG_BLK_DEV_UB")
|
||||
When: 3.6
|
||||
Why: This driver provides support for USB storage devices like "USB
|
||||
|
|
@ -543,3 +521,21 @@ 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>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: setitimer accepts user NULL pointer (value)
|
||||
When: 3.6
|
||||
Why: setitimer is not returning -EFAULT if user pointer is NULL. This
|
||||
violates the spec.
|
||||
Who: Sasikantha Babu <sasikanth.v19@gmail.com>
|
||||
|
|
|
|||
|
|
@ -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-
|
||||
|
|
|
|||
|
|
@ -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);
|
||||
.....
|
||||
|
||||
|
|
|
|||
|
|
@ -114,7 +114,7 @@ members are defined:
|
|||
struct file_system_type {
|
||||
const char *name;
|
||||
int fs_flags;
|
||||
struct dentry (*mount) (struct file_system_type *, int,
|
||||
struct dentry *(*mount) (struct file_system_type *, int,
|
||||
const char *, void *);
|
||||
void (*kill_sb) (struct super_block *);
|
||||
struct module *owner;
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -118,6 +118,10 @@ Supported chips:
|
|||
Addresses scanned: I2C 0x48 through 0x4F
|
||||
Datasheet: Publicly available at NXP website
|
||||
http://ics.nxp.com/products/interface/datasheet/sa56004x.pdf
|
||||
* GMT G781
|
||||
Prefix: 'g781'
|
||||
Addresses scanned: I2C 0x4c, 0x4d
|
||||
Datasheet: Not publicly available from GMT
|
||||
|
||||
Author: Jean Delvare <khali@linux-fr.org>
|
||||
|
||||
|
|
|
|||
|
|
@ -3,8 +3,11 @@ Kernel driver mc13783-adc
|
|||
|
||||
Supported chips:
|
||||
* Freescale Atlas MC13783
|
||||
Prefix: 'mc13783_adc'
|
||||
Prefix: 'mc13783'
|
||||
Datasheet: http://www.freescale.com/files/rf_if/doc/data_sheet/MC13783.pdf?fsrch=1
|
||||
* Freescale Atlas MC13892
|
||||
Prefix: 'mc13892'
|
||||
Datasheet: http://cache.freescale.com/files/analog/doc/data_sheet/MC13892.pdf?fsrch=1&sr=1
|
||||
|
||||
Authors:
|
||||
Sascha Hauer <s.hauer@pengutronix.de>
|
||||
|
|
@ -13,20 +16,21 @@ Authors:
|
|||
Description
|
||||
-----------
|
||||
|
||||
The Freescale MC13783 is a Power Management and Audio Circuit. Among
|
||||
other things it contains a 10-bit A/D converter. The converter has 16
|
||||
channels which can be used in different modes.
|
||||
The A/D converter has a resolution of 2.25mV. Channels 0-4 have
|
||||
a dedicated meaning with chip internal scaling applied. Channels 5-7
|
||||
can be used as general purpose inputs or alternatively in a dedicated
|
||||
mode. Channels 12-15 are occupied by the touchscreen if it's active.
|
||||
The Freescale MC13783 and MC13892 are Power Management and Audio Circuits.
|
||||
Among other things they contain a 10-bit A/D converter. The converter has 16
|
||||
(MC13783) resp. 12 (MC13892) channels which can be used in different modes. The
|
||||
A/D converter has a resolution of 2.25mV.
|
||||
|
||||
Currently the driver only supports channels 2 and 5-15 with no alternative
|
||||
modes for channels 5-7.
|
||||
Some channels can be used as General Purpose inputs or in a dedicated mode with
|
||||
a chip internal scaling applied .
|
||||
|
||||
See this table for the meaning of the different channels and their chip
|
||||
internal scaling:
|
||||
Currently the driver only supports the Application Supply channel (BP / BPSNS),
|
||||
the General Purpose inputs and touchscreen.
|
||||
|
||||
See the following tables for the meaning of the different channels and their
|
||||
chip internal scaling:
|
||||
|
||||
MC13783:
|
||||
Channel Signal Input Range Scaling
|
||||
-------------------------------------------------------------------------------
|
||||
0 Battery Voltage (BATT) 2.50 - 4.65V -2.40V
|
||||
|
|
@ -34,7 +38,7 @@ Channel Signal Input Range Scaling
|
|||
2 Application Supply (BP) 2.50 - 4.65V -2.40V
|
||||
3 Charger Voltage (CHRGRAW) 0 - 10V / /5
|
||||
0 - 20V /10
|
||||
4 Charger Current (CHRGISNSP-CHRGISNSN) -0.25V - 0.25V x4
|
||||
4 Charger Current (CHRGISNSP-CHRGISNSN) -0.25 - 0.25V x4
|
||||
5 General Purpose ADIN5 / Battery Pack Thermistor 0 - 2.30V No
|
||||
6 General Purpose ADIN6 / Backup Voltage (LICELL) 0 - 2.30V / No /
|
||||
1.50 - 3.50V -1.20V
|
||||
|
|
@ -48,3 +52,23 @@ Channel Signal Input Range Scaling
|
|||
13 General Purpose TSX2 / Touchscreen X-plate 2 0 - 2.30V No
|
||||
14 General Purpose TSY1 / Touchscreen Y-plate 1 0 - 2.30V No
|
||||
15 General Purpose TSY2 / Touchscreen Y-plate 2 0 - 2.30V No
|
||||
|
||||
MC13892:
|
||||
Channel Signal Input Range Scaling
|
||||
-------------------------------------------------------------------------------
|
||||
0 Battery Voltage (BATT) 0 - 4.8V /2
|
||||
1 Battery Current (BATT - BATTISNSCC) -60 - 60 mV x20
|
||||
2 Application Supply (BPSNS) 0 - 4.8V /2
|
||||
3 Charger Voltage (CHRGRAW) 0 - 12V / /5
|
||||
0 - 20V /10
|
||||
4 Charger Current (CHRGISNS-BPSNS) / -0.3 - 0.3V / x4 /
|
||||
Touchscreen X-plate 1 0 - 2.4V No
|
||||
5 General Purpose ADIN5 / Battery Pack Thermistor 0 - 2.4V No
|
||||
6 General Purpose ADIN6 / Backup Voltage (LICELL) 0 - 2.4V / No
|
||||
Backup Voltage (LICELL) 0 - 3.6V x2/3
|
||||
7 General Purpose ADIN7 / UID / Die Temperature 0 - 2.4V / No /
|
||||
0 - 4.8V /2
|
||||
12 General Purpose TSX1 / Touchscreen X-plate 1 0 - 2.4V No
|
||||
13 General Purpose TSX2 / Touchscreen X-plate 2 0 - 2.4V No
|
||||
14 General Purpose TSY1 / Touchscreen Y-plate 1 0 - 2.4V No
|
||||
15 General Purpose TSY2 / Touchscreen Y-plate 2 0 - 2.4V No
|
||||
|
|
|
|||
|
|
@ -0,0 +1,22 @@
|
|||
Kernel driver MCP3021
|
||||
======================
|
||||
|
||||
Supported chips:
|
||||
* Microchip Technology MCP3021
|
||||
Prefix: 'mcp3021'
|
||||
Datasheet: http://ww1.microchip.com/downloads/en/DeviceDoc/21805a.pdf
|
||||
|
||||
Author: Mingkai Hu
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
This driver implements support for the Microchip Technology MCP3021 chip.
|
||||
|
||||
The Microchip Technology Inc. MCP3021 is a successive approximation A/D
|
||||
converter (ADC) with 10-bit resolution.
|
||||
This device provides one single-ended input with very low power consumption.
|
||||
Communication to the MCP3021 is performed using a 2-wire I2C compatible
|
||||
interface. Standard (100 kHz) and Fast (400 kHz) I2C modes are available.
|
||||
The default I2C device address is 0x4d (contact the Microchip factory for
|
||||
additional address options).
|
||||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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).
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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'
|
||||
|
|
|
|||
|
|
@ -1086,8 +1086,6 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
|
|||
no_x2apic_optout
|
||||
BIOS x2APIC opt-out request will be ignored
|
||||
|
||||
inttest= [IA-64]
|
||||
|
||||
iomem= Disable strict checking of access to MMIO memory
|
||||
strict regions from userspace.
|
||||
relaxed
|
||||
|
|
@ -1701,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
|
||||
|
|
@ -1871,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.
|
||||
|
||||
|
|
@ -2147,8 +2153,14 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
|
|||
the default.
|
||||
off: Turn ECRC off
|
||||
on: Turn ECRC on.
|
||||
realloc reallocate PCI resources if allocations done by BIOS
|
||||
are erroneous.
|
||||
realloc= Enable/disable reallocating PCI bridge resources
|
||||
if allocations done by BIOS are too small to
|
||||
accommodate resources required by all child
|
||||
devices.
|
||||
off: Turn realloc off
|
||||
on: Turn realloc on
|
||||
realloc same as realloc=on
|
||||
noari do not use PCIe ARI.
|
||||
|
||||
pcie_aspm= [PCIE] Forcibly enable or disable PCIe Active State Power
|
||||
Management.
|
||||
|
|
@ -2156,6 +2168,10 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
|
|||
force Enable ASPM even on devices that claim not to support it.
|
||||
WARNING: Forcing ASPM on may cause system lockups.
|
||||
|
||||
pcie_hp= [PCIE] PCI Express Hotplug driver options:
|
||||
nomsi Do not use MSI for PCI Express Native Hotplug (this
|
||||
makes all PCIe ports use INTx for hotplug services).
|
||||
|
||||
pcie_ports= [PCIE] PCIe ports handling:
|
||||
auto Ask the BIOS whether or not to use native PCIe services
|
||||
associated with PCIe ports (PME, hot-plug, AER). Use
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
---------------------------------------------------------
|
||||
|
|
|
|||
|
|
@ -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>
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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,
|
||||
|
|
|
|||
Некоторые файлы не были показаны из-за слишком большого количества измененных файлов Показать больше
Загрузка…
Ссылка в новой задаче