openkylin
/
linux
mirror of https://gitee.com/openkylin/linux.git
9
0
Fork 0
Code Issues Projects Releases Wiki Activity

Merge commit 'v2.6.28-rc8' into x86/mm

This commit is contained in:
Ingo Molnar 2008-12-12 11:53:43 +01:00
parent 3555105333 8b1fae4e42
commit e18d7af852
3915 changed files with 143814 additions and 49095 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
.mailmap
View File

@ -80,6 +80,8 @@ Nguyen Anh Quynh <aquynh@gmail.com>
Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Patrick Mochel <mochel@digitalimplant.org>
Peter A Jonsson <pj@ludd.ltu.se>
Peter Oruba <peter@oruba.de>
Peter Oruba <peter.oruba@amd.com>
Praveen BP <praveenbp@ti.com>
Rajesh Shah <rajesh.shah@intel.com>
Ralf Baechle <ralf@linux-mips.org>

11
CREDITS
View File

@ -598,6 +598,11 @@ S: Tamsui town, Taipei county,
S: Taiwan 251
S: Republic of China
N: Reinette Chatre
E: reinette.chatre@intel.com
D: WiMedia Link Protocol implementation
D: UWB stack bits and pieces
N: Michael Elizabeth Chastain
E: mec@shout.net
D: Configure, Menuconfig, xconfig
@ -2695,6 +2700,12 @@ S: Demonstratsii 8-382
S: Tula 300000
S: Russia
N: Inaky Perez-Gonzalez
E: inaky.perez-gonzalez@intel.com
D: UWB stack, HWA-RC driver and HWA-HC drivers
D: Wireless USB additions to the USB stack
D: WiMedia Link Protocol bits and pieces
N: Gordon Peters
E: GordPeters@smarttech.com
D: Isochronous receive for IEEE 1394 driver (OHCI module).

48
Documentation/00-INDEX
View File

@ -42,14 +42,8 @@ IRQ.txt
- description of what an IRQ is.
ManagementStyle
- how to (attempt to) manage kernel hackers.
MSI-HOWTO.txt
- the Message Signaled Interrupts (MSI) Driver Guide HOWTO and FAQ.
RCU/
- directory with info on RCU (read-copy update).
README.DAC960
- info on Mylex DAC960/DAC1100 PCI RAID Controller Driver for Linux.
README.cycladesZ
- info on Cyclades-Z firmware loading.
SAK.txt
- info on Secure Attention Keys.
SM501.txt
@ -86,20 +80,16 @@ blackfin/
- directory with documentation for the Blackfin arch.
block/
- info on the Block I/O (BIO) layer.
blockdev/
- info on block devices & drivers
cachetlb.txt
- describes the cache/TLB flushing interfaces Linux uses.
cciss.txt
- info, major/minor #'s for Compaq's SMART Array Controllers.
cdrom/
- directory with information on the CD-ROM drivers that Linux has.
computone.txt
- info on Computone Intelliport II/Plus Multiport Serial Driver.
connector/
- docs on the netlink based userspace<->kernel space communication mod.
console/
- documentation on Linux console drivers.
cpqarray.txt
- info on using Compaq's SMART2 Intelligent Disk Array Controllers.
cpu-freq/
- info on CPU frequency and voltage scaling.
cpu-hotplug.txt
@ -126,8 +116,6 @@ device-mapper/
- directory with info on Device Mapper.
devices.txt
- plain ASCII listing of all the nodes in /dev/ with major minor #'s.
digiepca.txt
- info on Digi Intl. {PC,PCI,EISA}Xx and Xem series cards.
dontdiff
- file containing a list of files that should never be diff'ed.
driver-model/
@ -152,14 +140,10 @@ filesystems/
- info on the vfs and the various filesystems that Linux supports.
firmware_class/
- request_firmware() hotplug interface info.
floppy.txt
- notes and driver options for the floppy disk driver.
frv/
- Fujitsu FR-V Linux documentation.
gpio.txt
- overview of GPIO (General Purpose Input/Output) access conventions.
hayes-esp.txt
- info on using the Hayes ESP serial driver.
highuid.txt
- notes on the change from 16 bit to 32 bit user/group IDs.
timers/
@ -172,7 +156,7 @@ i2c/
- directory with info about the I2C bus/protocol (2 wire, kHz speed).
i2o/
- directory with info about the Linux I2O subsystem.
i386/
x86/i386/
- directory with info about Linux on Intel 32 bit architecture.
ia64/
- directory with info about Linux on Intel 64 bit architecture.
@ -186,8 +170,6 @@ io_ordering.txt
- info on ordering I/O writes to memory-mapped addresses.
ioctl/
- directory with documents describing various IOCTL calls.
ioctl-number.txt
- how to implement and register device/driver ioctl calls.
iostats.txt
- info on I/O statistics Linux kernel provides.
irqflags-tracing.txt
@ -250,14 +232,10 @@ mips/
- directory with info about Linux on MIPS architecture.
mono.txt
- how to execute Mono-based .NET binaries with the help of BINFMT_MISC.
moxa-smartio
- file with info on installing/using Moxa multiport serial driver.
mutex-design.txt
- info on the generic mutex subsystem.
namespaces/
- directory with various information about namespaces
nbd.txt
- info on a TCP implementation of a network block device.
netlabel/
- directory with information on the NetLabel subsystem.
networking/
@ -270,8 +248,6 @@ numastat.txt
- info on how to read Numa policy hit/miss statistics in sysfs.
oops-tracing.txt
- how to decode those nasty internal kernel error dump messages.
paride.txt
- information about the parallel port IDE subsystem.
parisc/
- directory with info on using Linux on PA-RISC architecture.
parport.txt
@ -290,20 +266,16 @@ powerpc/
- directory with info on using Linux with the PowerPC.
preempt-locking.txt
- info on locking under a preemptive kernel.
printk-formats.txt
- how to get printk format specifiers right
prio_tree.txt
- info on radix-priority-search-tree use for indexing vmas.
ramdisk.txt
- short guide on how to set up and use the RAM disk.
rbtree.txt
- info on what red-black trees are and what they are for.
riscom8.txt
- notes on using the RISCom/8 multi-port serial driver.
robust-futex-ABI.txt
- documentation of the robust futex ABI.
robust-futexes.txt
- a description of what robust futexes are.
rocket.txt
- info on the Comtrol RocketPort multiport serial driver.
rt-mutex-design.txt
- description of the RealTime mutex implementation design.
rt-mutex.txt
@ -332,8 +304,6 @@ sparc/
- directory with info on using Linux on Sparc architecture.
sparse.txt
- info on how to obtain and use the sparse tool for typechecking.
specialix.txt
- info on hardware/driver for specialix IO8+ multiport serial card.
spi/
- overview of Linux kernel Serial Peripheral Interface (SPI) support.
spinlocks.txt
@ -342,14 +312,10 @@ stable_api_nonsense.txt
- info on why the kernel does not have a stable in-kernel api or abi.
stable_kernel_rules.txt
- rules and procedures for the -stable kernel releases.
stallion.txt
- info on using the Stallion multiport serial driver.
svga.txt
- short guide on selecting video modes at boot via VGA BIOS.
sysfs-rules.txt
- How not to use sysfs.
sx.txt
- info on the Specialix SX/SI multiport serial driver.
sysctl/
- directory with info on the /proc/sys/* files.
sysrq.txt
@ -358,8 +324,6 @@ telephony/
- directory with info on telephony (e.g. voice over IP) support.
time_interpolators.txt
- info on time interpolators.
tty.txt
- guide to the locking policies of the tty layer.
uml/
- directory with information about User Mode Linux.
unicode.txt
@ -382,7 +346,7 @@ w1/
- directory with documents regarding the 1-wire (w1) subsystem.
watchdog/
- how to auto-reboot Linux if it has "fallen and can't get up". ;-)
x86_64/
x86/x86_64/
- directory with info on Linux support for AMD x86-64 (Hammer) machines.
zorro.txt
- info on writing drivers for Zorro bus devices found on Amigas.

28
Documentation/ABI/testing/sysfs-bus-umc Normal file
View File

@ -0,0 +1,28 @@
What: /sys/bus/umc/
Date: July 2008
KernelVersion: 2.6.27
Contact: David Vrabel <david.vrabel@csr.com>
Description:
The Wireless Host Controller Interface (WHCI)
specification describes a PCI-based device with
multiple capabilities; the UWB Multi-interface
Controller (UMC).
The umc bus presents each of the individual
capabilties as a device.
What: /sys/bus/umc/devices/.../capability_id
Date: July 2008
KernelVersion: 2.6.27
Contact: David Vrabel <david.vrabel@csr.com>
Description:
The ID of this capability, with 0 being the radio
controller capability.
What: /sys/bus/umc/devices/.../version
Date: July 2008
KernelVersion: 2.6.27
Contact: David Vrabel <david.vrabel@csr.com>
Description:
The specification version this capability's hardware
interface complies with.

43
Documentation/ABI/testing/sysfs-bus-usb
View File

@ -101,3 +101,46 @@ Description:
Users:
USB PM tool
git://git.moblin.org/users/sarah/usb-pm-tool/
What: /sys/bus/usb/device/.../authorized
Date: July 2008
KernelVersion: 2.6.26
Contact: David Vrabel <david.vrabel@csr.com>
Description:
Authorized devices are available for use by device
drivers, non-authorized one are not. By default, wired
USB devices are authorized.
Certified Wireless USB devices are not authorized
initially and should be (by writing 1) after the
device has been authenticated.
What: /sys/bus/usb/device/.../wusb_cdid
Date: July 2008
KernelVersion: 2.6.27
Contact: David Vrabel <david.vrabel@csr.com>
Description:
For Certified Wireless USB devices only.
A devices's CDID, as 16 space-separated hex octets.
What: /sys/bus/usb/device/.../wusb_ck
Date: July 2008
KernelVersion: 2.6.27
Contact: David Vrabel <david.vrabel@csr.com>
Description:
For Certified Wireless USB devices only.
Write the device's connection key (CK) to start the
authentication of the device. The CK is 16
space-separated hex octets.
What: /sys/bus/usb/device/.../wusb_disconnect
Date: July 2008
KernelVersion: 2.6.27
Contact: David Vrabel <david.vrabel@csr.com>
Description:
For Certified Wireless USB devices only.
Write a 1 to force the device to disconnect
(equivalent to unplugging a wired USB device).

88
Documentation/ABI/testing/sysfs-c2port Normal file
View File

@ -0,0 +1,88 @@
What: /sys/class/c2port/
Date: October 2008
Contact: Rodolfo Giometti <giometti@linux.it>
Description:
The /sys/class/c2port/ directory will contain files and
directories that will provide a unified interface to
the C2 port interface.
What: /sys/class/c2port/c2portX
Date: October 2008
Contact: Rodolfo Giometti <giometti@linux.it>
Description:
The /sys/class/c2port/c2portX/ directory is related to X-th
C2 port into the system. Each directory will contain files to
manage and control its C2 port.
What: /sys/class/c2port/c2portX/access
Date: October 2008
Contact: Rodolfo Giometti <giometti@linux.it>
Description:
The /sys/class/c2port/c2portX/access file enable the access
to the C2 port from the system. No commands can be sent
till this entry is set to 0.
What: /sys/class/c2port/c2portX/dev_id
Date: October 2008
Contact: Rodolfo Giometti <giometti@linux.it>
Description:
The /sys/class/c2port/c2portX/dev_id file show the device ID
of the connected micro.
What: /sys/class/c2port/c2portX/flash_access
Date: October 2008
Contact: Rodolfo Giometti <giometti@linux.it>
Description:
The /sys/class/c2port/c2portX/flash_access file enable the
access to the on-board flash of the connected micro.
No commands can be sent till this entry is set to 0.
What: /sys/class/c2port/c2portX/flash_block_size
Date: October 2008
Contact: Rodolfo Giometti <giometti@linux.it>
Description:
The /sys/class/c2port/c2portX/flash_block_size file show
the on-board flash block size of the connected micro.
What: /sys/class/c2port/c2portX/flash_blocks_num
Date: October 2008
Contact: Rodolfo Giometti <giometti@linux.it>
Description:
The /sys/class/c2port/c2portX/flash_blocks_num file show
the on-board flash blocks number of the connected micro.
What: /sys/class/c2port/c2portX/flash_data
Date: October 2008
Contact: Rodolfo Giometti <giometti@linux.it>
Description:
The /sys/class/c2port/c2portX/flash_data file export
the content of the on-board flash of the connected micro.
What: /sys/class/c2port/c2portX/flash_erase
Date: October 2008
Contact: Rodolfo Giometti <giometti@linux.it>
Description:
The /sys/class/c2port/c2portX/flash_erase file execute
the "erase" command on the on-board flash of the connected
micro.
What: /sys/class/c2port/c2portX/flash_erase
Date: October 2008
Contact: Rodolfo Giometti <giometti@linux.it>
Description:
The /sys/class/c2port/c2portX/flash_erase file show the
on-board flash size of the connected micro.
What: /sys/class/c2port/c2portX/reset
Date: October 2008
Contact: Rodolfo Giometti <giometti@linux.it>
Description:
The /sys/class/c2port/c2portX/reset file execute a "reset"
command on the connected micro.
What: /sys/class/c2port/c2portX/rev_id
Date: October 2008
Contact: Rodolfo Giometti <giometti@linux.it>
Description:
The /sys/class/c2port/c2portX/rev_id file show the revision ID
of the connected micro.

25
Documentation/ABI/testing/sysfs-class-usb_host Normal file
View File

@ -0,0 +1,25 @@
What: /sys/class/usb_host/usb_hostN/wusb_chid
Date: July 2008
KernelVersion: 2.6.27
Contact: David Vrabel <david.vrabel@csr.com>
Description:
Write the CHID (16 space-separated hex octets) for this host controller.
This starts the host controller, allowing it to accept connection from
WUSB devices.
Set an all zero CHID to stop the host controller.
What: /sys/class/usb_host/usb_hostN/wusb_trust_timeout
Date: July 2008
KernelVersion: 2.6.27
Contact: David Vrabel <david.vrabel@csr.com>
Description:
Devices that haven't sent a WUSB packet to the host
within 'wusb_trust_timeout' ms are considered to have
disconnected and are removed. The default value of
4000 ms is the value required by the WUSB
specification.
Since this relates to security (specifically, the
lifetime of PTKs and GTKs) it should not be changed
from the default.

144
Documentation/ABI/testing/sysfs-class-uwb_rc Normal file
View File

@ -0,0 +1,144 @@
What: /sys/class/uwb_rc
Date: July 2008
KernelVersion: 2.6.27
Contact: linux-usb@vger.kernel.org
Description:
Interfaces for WiMedia Ultra Wideband Common Radio
Platform (UWB) radio controllers.
Familiarity with the ECMA-368 'High Rate Ultra
Wideband MAC and PHY Specification' is assumed.
What: /sys/class/uwb_rc/beacon_timeout_ms
Date: July 2008
KernelVersion: 2.6.27
Description:
If no beacons are received from a device for at least
this time, the device will be considered to have gone
and it will be removed. The default is 3 superframes
(~197 ms) as required by the specification.
What: /sys/class/uwb_rc/uwbN/
Date: July 2008
KernelVersion: 2.6.27
Contact: linux-usb@vger.kernel.org
Description:
An individual UWB radio controller.
What: /sys/class/uwb_rc/uwbN/beacon
Date: July 2008
KernelVersion: 2.6.27
Contact: linux-usb@vger.kernel.org
Description:
Write:
<channel> [<bpst offset>]
to start beaconing on a specific channel, or stop
beaconing if <channel> is -1. Valid channels depends
on the radio controller's supported band groups.
<bpst offset> may be used to try and join a specific
beacon group if more than one was found during a scan.
What: /sys/class/uwb_rc/uwbN/scan
Date: July 2008
KernelVersion: 2.6.27
Contact: linux-usb@vger.kernel.org
Description:
Write:
<channel> <type> [<bpst offset>]
to start (or stop) scanning on a channel. <type> is one of:
0 - scan
1 - scan outside BP
2 - scan while inactive
3 - scanning disabled
4 - scan (with start time of <bpst offset>)
What: /sys/class/uwb_rc/uwbN/mac_address
Date: July 2008
KernelVersion: 2.6.27
Contact: linux-usb@vger.kernel.org
Description:
The EUI-48, in colon-separated hex octets, for this
radio controller. A write will change the radio
controller's EUI-48 but only do so while the device is
not beaconing or scanning.
What: /sys/class/uwb_rc/uwbN/wusbhc
Date: July 2008
KernelVersion: 2.6.27
Contact: linux-usb@vger.kernel.org
Description:
A symlink to the device (if any) of the WUSB Host
Controller PAL using this radio controller.
What: /sys/class/uwb_rc/uwbN/<EUI-48>/
Date: July 2008
KernelVersion: 2.6.27
Contact: linux-usb@vger.kernel.org
Description:
A neighbour UWB device that has either been detected
as part of a scan or is a member of the radio
controllers beacon group.
What: /sys/class/uwb_rc/uwbN/<EUI-48>/BPST
Date: July 2008
KernelVersion: 2.6.27
Contact: linux-usb@vger.kernel.org
Description:
The time (using the radio controllers internal 1 ms
interval superframe timer) of the last beacon from
this device was received.
What: /sys/class/uwb_rc/uwbN/<EUI-48>/DevAddr
Date: July 2008
KernelVersion: 2.6.27
Contact: linux-usb@vger.kernel.org
Description:
The current DevAddr of this device in colon separated
hex octets.
What: /sys/class/uwb_rc/uwbN/<EUI-48>/EUI_48
Date: July 2008
KernelVersion: 2.6.27
Contact: linux-usb@vger.kernel.org
Description:
The EUI-48 of this device in colon separated hex
octets.
What: /sys/class/uwb_rc/uwbN/<EUI-48>/BPST
Date: July 2008
KernelVersion: 2.6.27
Contact: linux-usb@vger.kernel.org
Description:
What: /sys/class/uwb_rc/uwbN/<EUI-48>/IEs
Date: July 2008
KernelVersion: 2.6.27
Contact: linux-usb@vger.kernel.org
Description:
The latest IEs included in this device's beacon, in
space separated hex octets with one IE per line.
What: /sys/class/uwb_rc/uwbN/<EUI-48>/LQE
Date: July 2008
KernelVersion: 2.6.27
Contact: linux-usb@vger.kernel.org
Description:
Link Quality Estimate - the Signal to Noise Ratio
(SNR) of all packets received from this device in dB.
This gives an estimate on a suitable PHY rate. Refer
to [ECMA-368] section 13.3 for more details.
What: /sys/class/uwb_rc/uwbN/<EUI-48>/RSSI
Date: July 2008
KernelVersion: 2.6.27
Contact: linux-usb@vger.kernel.org
Description:
Received Signal Strength Indication - the strength of
the received signal in dB. LQE is a more useful
measure of the radio link quality.

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

@ -89,7 +89,7 @@ Description:
error - an interrupt that can't be accounted for above.
invalid: it's either a wakeup GPE or a GPE/Fixed Event that
invalid: it's either a GPE or a Fixed Event that
doesn't have an event handler.
disable: the GPE/Fixed Event is valid but disabled.
@ -117,30 +117,30 @@ Description:
and other user space applications so that the machine won't shutdown
when pressing the power button.
# cat ff_pwr_btn
0
0 enabled
# press the power button for 3 times;
# cat ff_pwr_btn
3
3 enabled
# echo disable > ff_pwr_btn
# cat ff_pwr_btn
disable
3 disabled
# press the power button for 3 times;
# cat ff_pwr_btn
disable
3 disabled
# echo enable > ff_pwr_btn
# cat ff_pwr_btn
4
4 enabled
/*
* this is because the status bit is set even if the enable bit is cleared,
* and it triggers an ACPI fixed event when the enable bit is set again
*/
# press the power button for 3 times;
# cat ff_pwr_btn
7
7 enabled
# echo disable > ff_pwr_btn
# press the power button for 3 times;
# echo clear > ff_pwr_btn /* clear the status bit */
# echo disable > ff_pwr_btn
# cat ff_pwr_btn
7
7 enabled

100
Documentation/ABI/testing/sysfs-wusb_cbaf Normal file
View File

@ -0,0 +1,100 @@
What: /sys/bus/usb/drivers/wusb_cbaf/.../wusb_*
Date: August 2008
KernelVersion: 2.6.27
Contact: David Vrabel <david.vrabel@csr.com>
Description:
Various files for managing Cable Based Association of
(wireless) USB devices.
The sequence of operations should be:
1. Device is plugged in.
2. The connection manager (CM) sees a device with CBA capability.
(the wusb_chid etc. files in /sys/devices/blah/OURDEVICE).
3. The CM writes the host name, supported band groups,
and the CHID (host ID) into the wusb_host_name,
wusb_host_band_groups and wusb_chid files. These
get sent to the device and the CDID (if any) for
this host is requested.
4. The CM can verify that the device's supported band
groups (wusb_device_band_groups) are compatible
with the host.
5. The CM reads the wusb_cdid file.
6. The CM looks it up its database.
- If it has a matching CHID,CDID entry, the device
has been authorized before and nothing further
needs to be done.
- If the CDID is zero (or the CM doesn't find a
matching CDID in its database), the device is
assumed to be not known. The CM may associate
the host with device by: writing a randomly
generated CDID to wusb_cdid and then a random CK
to wusb_ck (this uploads the new CC to the
device).
CMD may choose to prompt the user before
associating with a new device.
7. Device is unplugged.
References:
[WUSB-AM] Association Models Supplement to the
Certified Wireless Universal Serial Bus
Specification, version 1.0.
What: /sys/bus/usb/drivers/wusb_cbaf/.../wusb_chid
Date: August 2008
KernelVersion: 2.6.27
Contact: David Vrabel <david.vrabel@csr.com>
Description:
The CHID of the host formatted as 16 space-separated
hex octets.
Writes fetches device's supported band groups and the
the CDID for any existing association with this host.
What: /sys/bus/usb/drivers/wusb_cbaf/.../wusb_host_name
Date: August 2008
KernelVersion: 2.6.27
Contact: David Vrabel <david.vrabel@csr.com>
Description:
A friendly name for the host as a UTF-8 encoded string.
What: /sys/bus/usb/drivers/wusb_cbaf/.../wusb_host_band_groups
Date: August 2008
KernelVersion: 2.6.27
Contact: David Vrabel <david.vrabel@csr.com>
Description:
The band groups supported by the host, in the format
defined in [WUSB-AM].
What: /sys/bus/usb/drivers/wusb_cbaf/.../wusb_device_band_groups
Date: August 2008
KernelVersion: 2.6.27
Contact: David Vrabel <david.vrabel@csr.com>
Description:
The band groups supported by the device, in the format
defined in [WUSB-AM].
What: /sys/bus/usb/drivers/wusb_cbaf/.../wusb_cdid
Date: August 2008
KernelVersion: 2.6.27
Contact: David Vrabel <david.vrabel@csr.com>
Description:
The device's CDID formatted as 16 space-separated hex
octets.
What: /sys/bus/usb/drivers/wusb_cbaf/.../wusb_ck
Date: August 2008
KernelVersion: 2.6.27
Contact: David Vrabel <david.vrabel@csr.com>
Description:
Write 16 space-separated random, hex octets to
associate with the device.

8
Documentation/DMA-API.txt
View File

@ -316,12 +316,10 @@ reduce current DMA mapping usage or delay and try again later).
pci_map_sg(struct pci_dev *hwdev, struct scatterlist *sg,
int nents, int direction)
Maps a scatter gather list from the block layer.
Returns: the number of physical segments mapped (this may be shorter
than <nents> passed in if the block layer determines that some
elements of the scatter/gather list are physically adjacent and thus
may be mapped with a single entry).
than <nents> passed in if some elements of the scatter/gather list are
physically or virtually adjacent and an IOMMU maps them with a single
entry).
Please note that the sg cannot be mapped again if it has been mapped once.
The mapping process is allowed to destroy information in the sg.

4
Documentation/DocBook/Makefile
View File

@ -136,7 +136,7 @@ quiet_cmd_db2ps = PS $@
%.ps : %.xml
$(call cmd,db2ps)
quiet_cmd_db2pdf = PDF $@
quiet_cmd_db2pdf = PDF $@
cmd_db2pdf = $(subst TYPE,pdf, $($(PDF_METHOD)template))
%.pdf : %.xml
$(call cmd,db2pdf)
@ -148,7 +148,7 @@ build_main_index = rm -rf $(main_idx) && \
echo '<h2>Kernel Version: $(KERNELVERSION)</h2>' >> $(main_idx) && \
cat $(HTML) >> $(main_idx)
quiet_cmd_db2html = HTML $@
quiet_cmd_db2html = HTML $@
cmd_db2html = xmlto xhtml $(XMLTOFLAGS) -o $(patsubst %.html,%,$@) $< && \
echo '<a HREF="$(patsubst %.html,%,$(notdir $@))/index.html"> \
$(patsubst %.html,%,$(notdir $@))</a><p>' > $@

4
Documentation/DocBook/deviceiobook.tmpl
View File

@ -24,7 +24,7 @@
<surname>Cox</surname>
<affiliation>
<address>
<email>alan@redhat.com</email>
<email>alan@lxorguk.ukuu.org.uk</email>
</address>
</affiliation>
</author>
@ -316,7 +316,7 @@ CPU B: spin_unlock_irqrestore(&amp;dev_lock, flags)
<chapter id="pubfunctions">
<title>Public Functions Provided</title>
!Iinclude/asm-x86/io_32.h
!Iarch/x86/include/asm/io_32.h
!Elib/iomap.c
</chapter>

10
Documentation/DocBook/kernel-api.tmpl
View File

@ -45,8 +45,8 @@
</sect1>
<sect1><title>Atomic and pointer manipulation</title>
!Iinclude/asm-x86/atomic_32.h
!Iinclude/asm-x86/unaligned.h
!Iarch/x86/include/asm/atomic_32.h
!Iarch/x86/include/asm/unaligned.h
</sect1>
<sect1><title>Delaying, scheduling, and timer routines</title>
@ -119,7 +119,7 @@ X!Ilib/string.c
!Elib/string.c
</sect1>
<sect1><title>Bit Operations</title>
!Iinclude/asm-x86/bitops.h
!Iarch/x86/include/asm/bitops.h
</sect1>
</chapter>
@ -155,7 +155,7 @@ X!Ilib/string.c
!Emm/slab.c
</sect1>
<sect1><title>User Space Memory Access</title>
!Iinclude/asm-x86/uaccess_32.h
!Iarch/x86/include/asm/uaccess_32.h
!Earch/x86/lib/usercopy_32.c
</sect1>
<sect1><title>More Memory Management Functions</title>
@ -265,7 +265,7 @@ X!Earch/x86/kernel/mca_32.c
-->
</sect2>
<sect2><title>MCA Bus DMA</title>
!Iinclude/asm-x86/mca_dma.h
!Iarch/x86/include/asm/mca_dma.h
</sect2>
</sect1>
</chapter>

4
Documentation/DocBook/kernel-hacking.tmpl
View File

@ -1239,7 +1239,7 @@ static struct block_device_operations opt_fops = {
</para>
<para>
<filename>include/asm-x86/delay_32.h:</filename>
<filename>arch/x86/include/asm/delay.h:</filename>
</para>
<programlisting>
#define ndelay(n) (__builtin_constant_p(n) ? \
@ -1265,7 +1265,7 @@ static struct block_device_operations opt_fops = {
</programlisting>
<para>
<filename>include/asm-x86/uaccess_32.h:</filename>
<filename>arch/x86/include/asm/uaccess_32.h:</filename>
</para>
<programlisting>

4
Documentation/DocBook/mcabook.tmpl
View File

@ -12,7 +12,7 @@
<surname>Cox</surname>
<affiliation>
<address>
<email>alan@redhat.com</email>
<email>alan@lxorguk.ukuu.org.uk</email>
</address>
</affiliation>
</author>
@ -101,7 +101,7 @@
<chapter id="dmafunctions">
<title>DMA Functions Provided</title>
!Iinclude/asm-x86/mca_dma.h
!Iarch/x86/include/asm/mca_dma.h
</chapter>
</book>

2
Documentation/DocBook/wanbook.tmpl
View File

@ -12,7 +12,7 @@
<surname>Cox</surname>
<affiliation>
<address>
<email>alan@redhat.com</email>
<email>alan@lxorguk.ukuu.org.uk</email>
</address>
</affiliation>
</author>

2
Documentation/DocBook/z8530book.tmpl
View File

@ -12,7 +12,7 @@
<surname>Cox</surname>
<affiliation>
<address>
<email>alan@redhat.com</email>
<email>alan@lxorguk.ukuu.org.uk</email>
</address>
</affiliation>
</author>

2
Documentation/ManagementStyle
View File

@ -17,7 +17,7 @@ companies. If you sign purchase orders or you have any clue about the
budget of your group, you're almost certainly not a kernel manager.
These suggestions may or may not apply to you.
First off, I'd suggest buying "Seven Habits of Highly Successful
First off, I'd suggest buying "Seven Habits of Highly Effective
People", and NOT read it. Burn it, it's a great symbolic gesture.
(*) This document does so not so much by answering the question, but by

2
Documentation/PCI/00-INDEX
View File

@ -1,5 +1,7 @@
00-INDEX
- this file
MSI-HOWTO.txt
- the Message Signaled Interrupts (MSI) Driver Guide HOWTO and FAQ.
PCI-DMA-mapping.txt
- info for PCI drivers using DMA portably across all platforms
PCIEBUS-HOWTO.txt

0
Documentation/MSI-HOWTO.txt → Documentation/PCI/MSI-HOWTO.txt
View File

1
Documentation/accounting/.gitignore vendored Normal file
View File

@ -0,0 +1 @@
getdelays

148
Documentation/acpi/debug.txt Normal file
View File

@ -0,0 +1,148 @@
ACPI Debug Output
The ACPI CA, the Linux ACPI core, and some ACPI drivers can generate debug
output. This document describes how to use this facility.
Compile-time configuration
--------------------------
ACPI debug output is globally enabled by CONFIG_ACPI_DEBUG. If this config
option is turned off, the debug messages are not even built into the
kernel.
Boot- and run-time configuration
--------------------------------
When CONFIG_ACPI_DEBUG=y, you can select the component and level of messages
you're interested in. At boot-time, use the acpi.debug_layer and
acpi.debug_level kernel command line options. After boot, you can use the
debug_layer and debug_level files in /sys/module/acpi/parameters/ to control
the debug messages.
debug_layer (component)
-----------------------
The "debug_layer" is a mask that selects components of interest, e.g., a
specific driver or part of the ACPI interpreter. To build the debug_layer
bitmask, look for the "#define _COMPONENT" in an ACPI source file.
You can set the debug_layer mask at boot-time using the acpi.debug_layer
command line argument, and you can change it after boot by writing values
to /sys/module/acpi/parameters/debug_layer.
The possible components are defined in include/acpi/acoutput.h and
include/acpi/acpi_drivers.h. Reading /sys/module/acpi/parameters/debug_layer
shows the supported mask values, currently these:
ACPI_UTILITIES 0x00000001
ACPI_HARDWARE 0x00000002
ACPI_EVENTS 0x00000004
ACPI_TABLES 0x00000008
ACPI_NAMESPACE 0x00000010
ACPI_PARSER 0x00000020
ACPI_DISPATCHER 0x00000040
ACPI_EXECUTER 0x00000080
ACPI_RESOURCES 0x00000100
ACPI_CA_DEBUGGER 0x00000200
ACPI_OS_SERVICES 0x00000400
ACPI_CA_DISASSEMBLER 0x00000800
ACPI_COMPILER 0x00001000
ACPI_TOOLS 0x00002000
ACPI_BUS_COMPONENT 0x00010000
ACPI_AC_COMPONENT 0x00020000
ACPI_BATTERY_COMPONENT 0x00040000
ACPI_BUTTON_COMPONENT 0x00080000
ACPI_SBS_COMPONENT 0x00100000
ACPI_FAN_COMPONENT 0x00200000
ACPI_PCI_COMPONENT 0x00400000
ACPI_POWER_COMPONENT 0x00800000
ACPI_CONTAINER_COMPONENT 0x01000000
ACPI_SYSTEM_COMPONENT 0x02000000
ACPI_THERMAL_COMPONENT 0x04000000
ACPI_MEMORY_DEVICE_COMPONENT 0x08000000
ACPI_VIDEO_COMPONENT 0x10000000
ACPI_PROCESSOR_COMPONENT 0x20000000
debug_level
-----------
The "debug_level" is a mask that selects different types of messages, e.g.,
those related to initialization, method execution, informational messages, etc.
To build debug_level, look at the level specified in an ACPI_DEBUG_PRINT()
statement.
The ACPI interpreter uses several different levels, but the Linux
ACPI core and ACPI drivers generally only use ACPI_LV_INFO.
You can set the debug_level mask at boot-time using the acpi.debug_level
command line argument, and you can change it after boot by writing values
to /sys/module/acpi/parameters/debug_level.
The possible levels are defined in include/acpi/acoutput.h. Reading
/sys/module/acpi/parameters/debug_level shows the supported mask values,
currently these:
ACPI_LV_INIT 0x00000001
ACPI_LV_DEBUG_OBJECT 0x00000002
ACPI_LV_INFO 0x00000004
ACPI_LV_INIT_NAMES 0x00000020
ACPI_LV_PARSE 0x00000040
ACPI_LV_LOAD 0x00000080
ACPI_LV_DISPATCH 0x00000100
ACPI_LV_EXEC 0x00000200
ACPI_LV_NAMES 0x00000400
ACPI_LV_OPREGION 0x00000800
ACPI_LV_BFIELD 0x00001000
ACPI_LV_TABLES 0x00002000
ACPI_LV_VALUES 0x00004000
ACPI_LV_OBJECTS 0x00008000
ACPI_LV_RESOURCES 0x00010000
ACPI_LV_USER_REQUESTS 0x00020000
ACPI_LV_PACKAGE 0x00040000
ACPI_LV_ALLOCATIONS 0x00100000
ACPI_LV_FUNCTIONS 0x00200000
ACPI_LV_OPTIMIZATIONS 0x00400000
ACPI_LV_MUTEX 0x01000000
ACPI_LV_THREADS 0x02000000
ACPI_LV_IO 0x04000000
ACPI_LV_INTERRUPTS 0x08000000
ACPI_LV_AML_DISASSEMBLE 0x10000000
ACPI_LV_VERBOSE_INFO 0x20000000
ACPI_LV_FULL_TABLES 0x40000000
ACPI_LV_EVENTS 0x80000000
Examples
--------
For example, drivers/acpi/bus.c contains this:
#define _COMPONENT ACPI_BUS_COMPONENT
...
ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Device insertion detected\n"));
To turn on this message, set the ACPI_BUS_COMPONENT bit in acpi.debug_layer
and the ACPI_LV_INFO bit in acpi.debug_level. (The ACPI_DEBUG_PRINT
statement uses ACPI_DB_INFO, which is macro based on the ACPI_LV_INFO
definition.)
Enable all AML "Debug" output (stores to the Debug object while interpreting
AML) during boot:
acpi.debug_layer=0xffffffff acpi.debug_level=0x2
Enable PCI and PCI interrupt routing debug messages:
acpi.debug_layer=0x400000 acpi.debug_level=0x4
Enable all ACPI hardware-related messages:
acpi.debug_layer=0x2 acpi.debug_level=0xffffffff
Enable all ACPI_DB_INFO messages after boot:
# echo 0x4 > /sys/module/acpi/parameters/debug_level
Show all valid component values:
# cat /sys/module/acpi/parameters/debug_layer

13
Documentation/arm/empeg/README
View File

@ -1,13 +0,0 @@
Empeg, Ltd's Empeg MP3 Car Audio Player
The initial design is to go in your car, but you can use it at home, on a
boat... almost anywhere. The principle is to store CD-quality music using
MPEG technology onto a hard disk in the unit, and use the power of the
embedded computer to serve up the music you want.
For more details, see:
http://www.empeg.com

49
Documentation/arm/empeg/ir.txt
View File

@ -1,49 +0,0 @@
Infra-red driver documentation.
Mike Crowe <mac@empeg.com>
(C) Empeg Ltd 1999
Not a lot here yet :-)
The Kenwood KCA-R6A remote control generates a sequence like the following:
Go low for approx 16T (Around 9000us)
Go high for approx 8T (Around 4000us)
Go low for less than 2T (Around 750us)
For each of the 32 bits
Go high for more than 2T (Around 1500us) == 1
Go high for less than T (Around 400us) == 0
Go low for less than 2T (Around 750us)
Rather than repeat a signal when the button is held down certain buttons
generate the following code to indicate repetition.
Go low for approx 16T
Go high for approx 4T
Go low for less than 2T
(By removing the <2T from the start of the sequence and placing at the end
it can be considered a stop bit but I found it easier to deal with it at
the start).
The 32 bits are encoded as XxYy where x and y are the actual data values
while X and Y are the logical inverses of the associated data values. Using
LSB first yields sensible codes for the numbers.
All codes are of the form b9xx
The numeric keys generate the code 0x where x is the number pressed.
Tuner 1c
Tape 1d
CD 1e
CD-MD-CH 1f
Track- 0a
Track+ 0b
Rewind 0c
FF 0d
DNPP 5e
Play/Pause 0e
Vol+ 14
Vol- 15

11
Documentation/arm/empeg/mkdevs
View File

@ -1,11 +0,0 @@
#!/bin/sh
mknod /dev/display c 244 0
mknod /dev/ir c 242 0
mknod /dev/usb0 c 243 0
mknod /dev/audio c 245 4
mknod /dev/dsp c 245 3
mknod /dev/mixer c 245 0
mknod /dev/empeg_state c 246 0
mknod /dev/radio0 c 81 64
ln -sf radio0 radio
ln -sf usb0 usb

1
Documentation/auxdisplay/.gitignore vendored Normal file
View File

@ -0,0 +1 @@
cfag12864b-example

16
Documentation/blockdev/00-INDEX Normal file
View File

@ -0,0 +1,16 @@
00-INDEX
- this file
README.DAC960
- info on Mylex DAC960/DAC1100 PCI RAID Controller Driver for Linux.
cciss.txt
- info, major/minor #'s for Compaq's SMART Array Controllers.
cpqarray.txt
- info on using Compaq's SMART2 Intelligent Disk Array Controllers.
floppy.txt
- notes and driver options for the floppy disk driver.
nbd.txt
- info on a TCP implementation of a network block device.
paride.txt
- information about the parallel port IDE subsystem.
ramdisk.txt
- short guide on how to set up and use the RAM disk.

0
Documentation/README.DAC960 → Documentation/blockdev/README.DAC960
View File

3
Documentation/cciss.txt → Documentation/blockdev/cciss.txt
View File

@ -21,11 +21,14 @@ This driver is known to work with the following cards:
* SA E200
* SA E200i
* SA E500
* SA P700m
* SA P212
* SA P410
* SA P410i
* SA P411
* SA P812
* SA P712m
* SA P711m
Detecting drive failures:
-------------------------

0
Documentation/cpqarray.txt → Documentation/blockdev/cpqarray.txt
View File

0
Documentation/floppy.txt → Documentation/blockdev/floppy.txt
View File

0
Documentation/nbd.txt → Documentation/blockdev/nbd.txt
View File

0
Documentation/paride.txt → Documentation/blockdev/paride.txt
View File

0
Documentation/ramdisk.txt → Documentation/blockdev/ramdisk.txt
View File

90
Documentation/c2port.txt Normal file
View File

@ -0,0 +1,90 @@
C2 port support
---------------
(C) Copyright 2007 Rodolfo Giometti <giometti@enneenne.com>
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
Overview
--------
This driver implements the support for Linux of Silicon Labs (Silabs)
C2 Interface used for in-system programming of micro controllers.
By using this driver you can reprogram the in-system flash without EC2
or EC3 debug adapter. This solution is also useful in those systems
where the micro controller is connected via special GPIOs pins.
References
----------
The C2 Interface main references are at (http://www.silabs.com)
Silicon Laboratories site], see:
- AN127: FLASH Programming via the C2 Interface at
http://www.silabs.com/public/documents/tpub_doc/anote/Microcontrollers/Small_Form_Factor/en/an127.pdf, and
- C2 Specification at
http://www.silabs.com/public/documents/tpub_doc/spec/Microcontrollers/en/C2spec.pdf,
however it implements a two wire serial communication protocol (bit
banging) designed to enable in-system programming, debugging, and
boundary-scan testing on low pin-count Silicon Labs devices. Currently
this code supports only flash programming but extensions are easy to
add.
Using the driver
----------------
Once the driver is loaded you can use sysfs support to get C2port's
info or read/write in-system flash.
# ls /sys/class/c2port/c2port0/
access flash_block_size flash_erase rev_id
dev_id flash_blocks_num flash_size subsystem/
flash_access flash_data reset uevent
Initially the C2port access is disabled since you hardware may have
such lines multiplexed with other devices so, to get access to the
C2port, you need the command:
# echo 1 > /sys/class/c2port/c2port0/access
after that you should read the device ID and revision ID of the
connected micro controller:
# cat /sys/class/c2port/c2port0/dev_id
8
# cat /sys/class/c2port/c2port0/rev_id
1
However, for security reasons, the in-system flash access in not
enabled yet, to do so you need the command:
# echo 1 > /sys/class/c2port/c2port0/flash_access
After that you can read the whole flash:
# cat /sys/class/c2port/c2port0/flash_data > image
erase it:
# echo 1 > /sys/class/c2port/c2port0/flash_erase
and write it:
# cat image > /sys/class/c2port/c2port0/flash_data
after writing you have to reset the device to execute the new code:
# echo 1 > /sys/class/c2port/c2port0/reset

21
Documentation/cgroups/freezer-subsystem.txt
View File

@ -1,4 +1,4 @@
The cgroup freezer is useful to batch job management system which start
The cgroup freezer is useful to batch job management system which start
and stop sets of tasks in order to schedule the resources of a machine
according to the desires of a system administrator. This sort of program
is often used on HPC clusters to schedule access to the cluster as a
@ -6,7 +6,7 @@ whole. The cgroup freezer uses cgroups to describe the set of tasks to
be started/stopped by the batch job management system. It also provides
a means to start and stop the tasks composing the job.
The cgroup freezer will also be useful for checkpointing running groups
The cgroup freezer will also be useful for checkpointing running groups
of tasks. The freezer allows the checkpoint code to obtain a consistent
image of the tasks by attempting to force the tasks in a cgroup into a
quiescent state. Once the tasks are quiescent another task can
@ -16,7 +16,7 @@ recoverable error occur. This also allows the checkpointed tasks to be
migrated between nodes in a cluster by copying the gathered information
to another node and restarting the tasks there.
Sequences of SIGSTOP and SIGCONT are not always sufficient for stopping
Sequences of SIGSTOP and SIGCONT are not always sufficient for stopping
and resuming tasks in userspace. Both of these signals are observable
from within the tasks we wish to freeze. While SIGSTOP cannot be caught,
blocked, or ignored it can be seen by waiting or ptracing parent tasks.
@ -37,26 +37,29 @@ demonstrate this problem using nested bash shells:
<at this point 16990 exits and causes 16644 to exit too>
This happens because bash can observe both signals and choose how it
This happens because bash can observe both signals and choose how it
responds to them.
Another example of a program which catches and responds to these
Another example of a program which catches and responds to these
signals is gdb. In fact any program designed to use ptrace is likely to
have a problem with this method of stopping and resuming tasks.
In contrast, the cgroup freezer uses the kernel freezer code to
In contrast, the cgroup freezer uses the kernel freezer code to
prevent the freeze/unfreeze cycle from becoming visible to the tasks
being frozen. This allows the bash example above and gdb to run as
expected.
The freezer subsystem in the container filesystem defines a file named
The freezer subsystem in the container filesystem defines a file named
freezer.state. Writing "FROZEN" to the state file will freeze all tasks in the
cgroup. Subsequently writing "THAWED" will unfreeze the tasks in the cgroup.
Reading will return the current state.
Note freezer.state doesn't exist in root cgroup, which means root cgroup
is non-freezable.
* Examples of usage :
# mkdir /containers/freezer
# mkdir /containers
# mount -t cgroup -ofreezer freezer /containers
# mkdir /containers/0
# echo $some_pid > /containers/0/tasks
@ -94,6 +97,6 @@ things happens:
the freezer.state file
2) Userspace retries the freezing operation by writing "FROZEN" to
the freezer.state file (writing "FREEZING" is not legal
and returns EIO)
and returns EINVAL)
3) The tasks that blocked the cgroup from entering the "FROZEN"
state disappear from the cgroup's set of tasks.

1
Documentation/connector/.gitignore vendored Normal file
View File

@ -0,0 +1 @@
ucon

12
Documentation/cpu-freq/user-guide.txt
View File

@ -23,6 +23,7 @@ Contents:
1.3 sparc64
1.4 ppc
1.5 SuperH
1.6 Blackfin
2. "Policy" / "Governor"?
2.1 Policy
@ -97,6 +98,17 @@ The following SuperH processors are supported by cpufreq:
SH-3
SH-4
1.6 Blackfin
------------
The following Blackfin processors are supported by cpufreq:
BF522, BF523, BF524, BF525, BF526, BF527, Rev 0.1 or higher
BF531, BF532, BF533, Rev 0.3 or higher
BF534, BF536, BF537, Rev 0.2 or higher
BF561, Rev 0.3 or higher
BF542, BF544, BF547, BF548, BF549, Rev 0.1 or higher
2. "Policy" / "Governor" ?
==========================

25
Documentation/email-clients.txt
View File

@ -213,4 +213,29 @@ TkRat (GUI)
Works. Use "Insert file..." or external editor.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Gmail (Web GUI)
If you just have to use Gmail to send patches, it CAN be made to work. It
requires a bit of external help, though.
The first problem is that Gmail converts tabs to spaces. This will
totally break your patches. To prevent this, you have to use a different
editor. There is a firefox extension called "ViewSourceWith"
(https://addons.mozilla.org/en-US/firefox/addon/394) which allows you to
edit any text box in the editor of your choice. Configure it to launch
your favorite editor. When you want to send a patch, use this technique.
Once you have crafted your messsage + patch, save and exit the editor,
which should reload the Gmail edit box. GMAIL WILL PRESERVE THE TABS.
Hoorah. Apparently you can cut-n-paste literal tabs, but Gmail will
convert those to spaces upon sending!
The second problem is that Gmail converts tabs to spaces on replies. If
you reply to a patch, don't expect to be able to apply it as a patch.
The last problem is that Gmail will base64-encode any message that has a
non-ASCII character. That includes things like European names. Be aware.
Gmail is not convenient for lkml patches, but CAN be made to work.
###

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

@ -56,30 +56,6 @@ Who: Mauro Carvalho Chehab <mchehab@infradead.org>
---------------------------
What: old tuner-3036 i2c driver
When: 2.6.28
Why: This driver is for VERY old i2c-over-parallel port teletext receiver
boxes. Rather then spending effort on converting this driver to V4L2,
and since it is extremely unlikely that anyone still uses one of these
devices, it was decided to drop it.
Who: Hans Verkuil <hverkuil@xs4all.nl>
Mauro Carvalho Chehab <mchehab@infradead.org>
---------------------------
What: V4L2 dpc7146 driver
When: 2.6.28
Why: Old driver for the dpc7146 demonstration board that is no longer
relevant. The last time this was tested on actual hardware was
probably around 2002. Since this is a driver for a demonstration
board the decision was made to remove it rather than spending a
lot of effort continually updating this driver to stay in sync
with the latest internal V4L2 or I2C API.
Who: Hans Verkuil <hverkuil@xs4all.nl>
Mauro Carvalho Chehab <mchehab@infradead.org>
---------------------------
What: PCMCIA control ioctl (needed for pcmcia-cs [cardmgr, cardctl])
When: November 2005
Files: drivers/pcmcia/: pcmcia_ioctl.c
@ -359,3 +335,11 @@ Why: The 2.6 kernel supports direct writing to ide CD drives, which
eliminates the need for ide-scsi. The new method is more
efficient in every way.
Who: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
---------------------------
What: i2c_attach_client(), i2c_detach_client(), i2c_driver->detach_client()
When: 2.6.29 (ideally) or 2.6.30 (more likely)
Why: Deprecated by the new (standard) device driver binding model. Use
i2c_driver->probe() and ->remove() instead.
Who: Jean Delvare <khali@linux-fr.org>

12
Documentation/filesystems/Locking
View File

@ -161,8 +161,12 @@ prototypes:
int (*set_page_dirty)(struct page *page);
int (*readpages)(struct file *filp, struct address_space *mapping,
struct list_head *pages, unsigned nr_pages);
int (*prepare_write)(struct file *, struct page *, unsigned, unsigned);
int (*commit_write)(struct file *, struct page *, unsigned, unsigned);
int (*write_begin)(struct file *, struct address_space *mapping,
loff_t pos, unsigned len, unsigned flags,
struct page **pagep, void **fsdata);
int (*write_end)(struct file *, struct address_space *mapping,
loff_t pos, unsigned len, unsigned copied,
struct page *page, void *fsdata);
sector_t (*bmap)(struct address_space *, sector_t);
int (*invalidatepage) (struct page *, unsigned long);
int (*releasepage) (struct page *, int);
@ -180,8 +184,6 @@ sync_page: no maybe
writepages: no
set_page_dirty no no
readpages: no
prepare_write: no yes yes
commit_write: no yes yes
write_begin: no locks the page yes
write_end: no yes, unlocks yes
perform_write: no n/a yes
@ -191,7 +193,7 @@ releasepage: no yes
direct_IO: no
launder_page: no yes
->prepare_write(), ->commit_write(), ->sync_page() and ->readpage()
->write_begin(), ->write_end(), ->sync_page() and ->readpage()
may be called from the request handler (/dev/loop).
->readpage() unlocks the page, either synchronously or via I/O

3
Documentation/filesystems/ocfs2.txt
View File

@ -28,10 +28,7 @@ Manish Singh <manish.singh@oracle.com>
Caveats
=======
Features which OCFS2 does not support yet:
- extended attributes
- quotas
- cluster aware flock
- cluster aware lockf
- Directory change notification (F_NOTIFY)
- Distributed Caching (F_SETLEASE/F_GETLEASE/break_lease)
- POSIX ACLs

27
Documentation/filesystems/proc.txt
View File

@ -44,6 +44,7 @@ Table of Contents
2.14 /proc/<pid>/io - Display the IO accounting fields
2.15 /proc/<pid>/coredump_filter - Core dump filtering settings
2.16 /proc/<pid>/mountinfo - Information about mounts
2.17 /proc/sys/fs/epoll - Configuration options for the epoll interface
------------------------------------------------------------------------------
Preface
@ -2483,4 +2484,30 @@ For more information on mount propagation see:
Documentation/filesystems/sharedsubtree.txt
2.17 /proc/sys/fs/epoll - Configuration options for the epoll interface
--------------------------------------------------------
This directory contains configuration options for the epoll(7) interface.
max_user_instances
------------------
This is the maximum number of epoll file descriptors that a single user can
have open at a given time. The default value is 128, and should be enough
for normal users.
max_user_watches
----------------
Every epoll file descriptor can store a number of files to be monitored
for event readiness. Each one of these monitored files constitutes a "watch".
This configuration option sets the maximum number of "watches" that are
allowed for each user.
Each "watch" costs roughly 90 bytes on a 32bit kernel, and roughly 160 bytes
on a 64bit one.
The current default value for max_user_watches is the 1/32 of the available
low memory, divided for the "watch" cost in bytes.
------------------------------------------------------------------------------

12
Documentation/filesystems/ramfs-rootfs-initramfs.txt
View File

@ -130,12 +130,12 @@ The 2.6 kernel build process always creates a gzipped cpio format initramfs
archive and links it into the resulting kernel binary. By default, this
archive is empty (consuming 134 bytes on x86).
The config option CONFIG_INITRAMFS_SOURCE (for some reason buried under
devices->block devices in menuconfig, and living in usr/Kconfig) can be used
to specify a source for the initramfs archive, which will automatically be
incorporated into the resulting binary. This option can point to an existing
gzipped cpio archive, a directory containing files to be archived, or a text
file specification such as the following example:
The config option CONFIG_INITRAMFS_SOURCE (in General Setup in menuconfig,
and living in usr/Kconfig) can be used to specify a source for the
initramfs archive, which will automatically be incorporated into the
resulting binary. This option can point to an existing gzipped cpio
archive, a directory containing files to be archived, or a text file
specification such as the following example:
dir /dev 755 0 0
nod /dev/console 644 0 0 c 5 1

32
Documentation/filesystems/vfat.txt
View File

@ -8,6 +8,12 @@ if you want to format from within Linux.
VFAT MOUNT OPTIONS
----------------------------------------------------------------------
uid=### -- Set the owner of all files on this filesystem.
The default is the uid of current process.
gid=### -- Set the group of all files on this filesystem.
The default is the gid of current process.
umask=### -- The permission mask (for files and directories, see umask(1)).
The default is the umask of current process.
@ -36,7 +42,7 @@ codepage=### -- Sets the codepage number for converting to shortname
characters on FAT filesystem.
By default, FAT_DEFAULT_CODEPAGE setting is used.
iocharset=name -- Character set to use for converting between the
iocharset=<name> -- Character set to use for converting between the
encoding is used for user visible filename and 16 bit
Unicode characters. Long filenames are stored on disk
in Unicode format, but Unix for the most part doesn't
@ -86,6 +92,8 @@ check=s|r|n -- Case sensitivity checking setting.
r: relaxed, case insensitive
n: normal, default setting, currently case insensitive
nocase -- This was deprecated for vfat. Use shortname=win95 instead.
shortname=lower|win95|winnt|mixed
-- Shortname display/create setting.
lower: convert to lowercase for display,
@ -99,11 +107,31 @@ shortname=lower|win95|winnt|mixed
tz=UTC -- Interpret timestamps as UTC rather than local time.
This option disables the conversion of timestamps
between local time (as used by Windows on FAT) and UTC
(which Linux uses internally). This is particuluarly
(which Linux uses internally). This is particularly
useful when mounting devices (like digital cameras)
that are set to UTC in order to avoid the pitfalls of
local time.
showexec -- If set, the execute permission bits of the file will be
allowed only if the extension part of the name is .EXE,
.COM, or .BAT. Not set by default.
debug -- Can be set, but unused by the current implementation.
sys_immutable -- If set, ATTR_SYS attribute on FAT is handled as
IMMUTABLE flag on Linux. Not set by default.
flush -- If set, the filesystem will try to flush to disk more
early than normal. Not set by default.
rodir -- FAT has the ATTR_RO (read-only) attribute. But on Windows,
the ATTR_RO of the directory will be just ignored actually,
and is used by only applications as flag. E.g. it's setted
for the customized folder.
If you want to use ATTR_RO as read-only flag even for
the directory, set this option.
<bool>: 0,1,yes,no,true,false
TODO

39
Documentation/filesystems/vfs.txt
View File

@ -492,7 +492,7 @@ written-back to storage typically in whole pages, however the
address_space has finer control of write sizes.
The read process essentially only requires 'readpage'. The write
process is more complicated and uses prepare_write/commit_write or
process is more complicated and uses write_begin/write_end or
set_page_dirty to write data into the address_space, and writepage,
sync_page, and writepages to writeback data to storage.
@ -521,8 +521,6 @@ struct address_space_operations {
int (*set_page_dirty)(struct page *page);
int (*readpages)(struct file *filp, struct address_space *mapping,
struct list_head *pages, unsigned nr_pages);
int (*prepare_write)(struct file *, struct page *, unsigned, unsigned);
int (*commit_write)(struct file *, struct page *, unsigned, unsigned);
int (*write_begin)(struct file *, struct address_space *mapping,
loff_t pos, unsigned len, unsigned flags,
struct page **pagep, void **fsdata);
@ -598,37 +596,7 @@ struct address_space_operations {
readpages is only used for read-ahead, so read errors are
ignored. If anything goes wrong, feel free to give up.
prepare_write: called by the generic write path in VM to set up a write
request for a page. This indicates to the address space that
the given range of bytes is about to be written. The
address_space should check that the write will be able to
complete, by allocating space if necessary and doing any other
internal housekeeping. If the write will update parts of
any basic-blocks on storage, then those blocks should be
pre-read (if they haven't been read already) so that the
updated blocks can be written out properly.
The page will be locked.
Note: the page _must not_ be marked uptodate in this function
(or anywhere else) unless it actually is uptodate right now. As
soon as a page is marked uptodate, it is possible for a concurrent
read(2) to copy it to userspace.
commit_write: If prepare_write succeeds, new data will be copied
into the page and then commit_write will be called. It will
typically update the size of the file (if appropriate) and
mark the inode as dirty, and do any other related housekeeping
operations. It should avoid returning an error if possible -
errors should have been handled by prepare_write.
write_begin: This is intended as a replacement for prepare_write. The
key differences being that:
- it returns a locked page (in *pagep) rather than being
given a pre locked page;
- it must be able to cope with short writes (where the
length passed to write_begin is greater than the number
of bytes copied into the page).
write_begin:
Called by the generic buffered write code to ask the filesystem to
prepare to write len bytes at the given offset in the file. The
address_space should check that the write will be able to complete,
@ -640,6 +608,9 @@ struct address_space_operations {
The filesystem must return the locked pagecache page for the specified
offset, in *pagep, for the caller to write into.
It must be able to cope with short writes (where the length passed to
write_begin is greater than the number of bytes copied into the page).
flags is a field for AOP_FLAG_xxx flags, described in
include/linux/fs.h.

9
Documentation/filesystems/xip.txt
View File

@ -39,10 +39,11 @@ The block device operation is optional, these block devices support it as of
today:
- dcssblk: s390 dcss block device driver
An address space operation named get_xip_page is used to retrieve reference
to a struct page. To address the target page, a reference to an address_space,
and a sector number is provided. A 3rd argument indicates whether the
function should allocate blocks if needed.
An address space operation named get_xip_mem is used to retrieve references
to a page frame number and a kernel address. To obtain these values a reference
to an address_space is provided. This function assigns values to the kmem and
pfn parameters. The third argument indicates whether the function should allocate
blocks if needed.
This address space operation is mutually exclusive with readpage&writepage that
do page cache read/write operations.

172
Documentation/ftrace.txt
View File

@ -8,7 +8,7 @@ Copyright 2008 Red Hat Inc.
Reviewers: Elias Oltmanns, Randy Dunlap, Andrew Morton,
John Kacur, and David Teigland.
Written for: 2.6.27-rc1
Written for: 2.6.28-rc2
Introduction
------------
@ -50,26 +50,26 @@ of ftrace. Here is a list of some of the key files:
Note: all time values are in microseconds.
current_tracer : This is used to set or display the current tracer
current_tracer: This is used to set or display the current tracer
that is configured.
available_tracers : This holds the different types of tracers that
available_tracers: This holds the different types of tracers that
have been compiled into the kernel. The tracers
listed here can be configured by echoing their name
into current_tracer.
tracing_enabled : This sets or displays whether the current_tracer
tracing_enabled: This sets or displays whether the current_tracer
is activated and tracing or not. Echo 0 into this
file to disable the tracer or 1 to enable it.
trace : This file holds the output of the trace in a human readable
trace: This file holds the output of the trace in a human readable
format (described below).
latency_trace : This file shows the same trace but the information
latency_trace: This file shows the same trace but the information
is organized more to display possible latencies
in the system (described below).
trace_pipe : The output is the same as the "trace" file but this
trace_pipe: The output is the same as the "trace" file but this
file is meant to be streamed with live tracing.
Reads from this file will block until new data
is retrieved. Unlike the "trace" and "latency_trace"
@ -82,11 +82,11 @@ of ftrace. Here is a list of some of the key files:
tracer is not adding more data, they will display
the same information every time they are read.
iter_ctrl : This file lets the user control the amount of data
iter_ctrl: This file lets the user control the amount of data
that is displayed in one of the above output
files.
trace_max_latency : Some of the tracers record the max latency.
trace_max_latency: Some of the tracers record the max latency.
For example, the time interrupts are disabled.
This time is saved in this file. The max trace
will also be stored, and displayed by either
@ -94,29 +94,26 @@ of ftrace. Here is a list of some of the key files:
only be recorded if the latency is greater than
the value in this file. (in microseconds)
trace_entries : This sets or displays the number of trace
entries each CPU buffer can hold. The tracer buffers
are the same size for each CPU. The displayed number
is the size of the CPU buffer and not total size. The
trace_entries: This sets or displays the number of bytes each CPU
buffer can hold. The tracer buffers are the same size
for each CPU. The displayed number is the size of the
CPU buffer and not total size of all buffers. The
trace buffers are allocated in pages (blocks of memory
that the kernel uses for allocation, usually 4 KB in size).
Since each entry is smaller than a page, if the last
allocated page has room for more entries than were
requested, the rest of the page is used to allocate
entries.
If the last page allocated has room for more bytes
than requested, the rest of the page will be used,
making the actual allocation bigger than requested.
(Note, the size may not be a multiple of the page size due
to buffer managment overhead.)
This can only be updated when the current_tracer
is set to "none".
is set to "nop".
NOTE: It is planned on changing the allocated buffers
from being the number of possible CPUS to
the number of online CPUS.
tracing_cpumask : This is a mask that lets the user only trace
tracing_cpumask: This is a mask that lets the user only trace
on specified CPUS. The format is a hex string
representing the CPUS.
set_ftrace_filter : When dynamic ftrace is configured in (see the
set_ftrace_filter: When dynamic ftrace is configured in (see the
section below "dynamic ftrace"), the code is dynamically
modified (code text rewrite) to disable calling of the
function profiler (mcount). This lets tracing be configured
@ -130,14 +127,11 @@ of ftrace. Here is a list of some of the key files:
be traced. If a function exists in both set_ftrace_filter
and set_ftrace_notrace, the function will _not_ be traced.
available_filter_functions : When a function is encountered the first
time by the dynamic tracer, it is recorded and
later the call is converted into a nop. This file
lists the functions that have been recorded
by the dynamic tracer and these functions can
be used to set the ftrace filter by the above
"set_ftrace_filter" file. (See the section "dynamic ftrace"
below for more details).
available_filter_functions: This lists the functions that ftrace
has processed and can trace. These are the function
names that you can pass to "set_ftrace_filter" or
"set_ftrace_notrace". (See the section "dynamic ftrace"
below for more details.)
The Tracers
@ -145,7 +139,7 @@ The Tracers
Here is the list of current tracers that may be configured.
ftrace - function tracer that uses mcount to trace all functions.
function - function tracer that uses mcount to trace all functions.
sched_switch - traces the context switches between tasks.
@ -166,8 +160,8 @@ Here is the list of current tracers that may be configured.
the highest priority task to get scheduled after
it has been woken up.
none - This is not a tracer. To remove all tracers from tracing
simply echo "none" into current_tracer.
nop - This is not a tracer. To remove all tracers from tracing
simply echo "nop" into current_tracer.
Examples of using the tracer
@ -182,7 +176,7 @@ Output format:
Here is an example of the output format of the file "trace"
--------
# tracer: ftrace
# tracer: function
#
# TASK-PID CPU# TIMESTAMP FUNCTION
# | | | | |
@ -192,7 +186,7 @@ Here is an example of the output format of the file "trace"
--------
A header is printed with the tracer name that is represented by the trace.
In this case the tracer is "ftrace". Then a header showing the format. Task
In this case the tracer is "function". Then a header showing the format. Task
name "bash", the task PID "4251", the CPU that it was running on
"01", the timestamp in <secs>.<usecs> format, the function name that was
traced "path_put" and the parent function that called this function
@ -291,6 +285,9 @@ explains which is which.
CPU#: The CPU which the process was running on.
irqs-off: 'd' interrupts are disabled. '.' otherwise.
Note: If the architecture does not support a way to
read the irq flags variable, an 'X' will always
be printed here.
need-resched: 'N' task need_resched is set, '.' otherwise.
@ -1000,22 +997,20 @@ is the stack for the hard interrupt. This hides the fact that NEED_RESCHED
has been set. We do not see the 'N' until we switch back to the task's
assigned stack.
ftrace
------
function
--------
ftrace is not only the name of the tracing infrastructure, but it
is also a name of one of the tracers. The tracer is the function
tracer. Enabling the function tracer can be done from the
debug file system. Make sure the ftrace_enabled is set otherwise
this tracer is a nop.
This tracer is the function tracer. Enabling the function tracer
can be done from the debug file system. Make sure the ftrace_enabled is
set; otherwise this tracer is a nop.
# sysctl kernel.ftrace_enabled=1
# echo ftrace > /debug/tracing/current_tracer
# echo function > /debug/tracing/current_tracer
# echo 1 > /debug/tracing/tracing_enabled
# usleep 1
# echo 0 > /debug/tracing/tracing_enabled
# cat /debug/tracing/trace
# tracer: ftrace
# tracer: function
#
# TASK-PID CPU# TIMESTAMP FUNCTION
# | | | | |
@ -1037,10 +1032,10 @@ this tracer is a nop.
[...]
Note: ftrace uses ring buffers to store the above entries. The newest data
may overwrite the oldest data. Sometimes using echo to stop the trace
is not sufficient because the tracing could have overwritten the data
that you wanted to record. For this reason, it is sometimes better to
Note: function tracer uses ring buffers to store the above entries.
The newest data may overwrite the oldest data. Sometimes using echo to
stop the trace is not sufficient because the tracing could have overwritten
the data that you wanted to record. For this reason, it is sometimes better to
disable tracing directly from a program. This allows you to stop the
tracing at the point that you hit the part that you are interested in.
To disable the tracing directly from a C program, something like following
@ -1074,18 +1069,31 @@ every kernel function, produced by the -pg switch in gcc), starts
of pointing to a simple return. (Enabling FTRACE will include the
-pg switch in the compiling of the kernel.)
When dynamic ftrace is initialized, it calls kstop_machine to make
the machine act like a uniprocessor so that it can freely modify code
without worrying about other processors executing that same code. At
initialization, the mcount calls are changed to call a "record_ip"
function. After this, the first time a kernel function is called,
it has the calling address saved in a hash table.
At compile time every C file object is run through the
recordmcount.pl script (located in the scripts directory). This
script will process the C object using objdump to find all the
locations in the .text section that call mcount. (Note, only
the .text section is processed, since processing other sections
like .init.text may cause races due to those sections being freed).
Later on the ftraced kernel thread is awoken and will again call
kstop_machine if new functions have been recorded. The ftraced thread
will change all calls to mcount to "nop". Just calling mcount
and having mcount return has shown a 10% overhead. By converting
it to a nop, there is no measurable overhead to the system.
A new section called "__mcount_loc" is created that holds references
to all the mcount call sites in the .text section. This section is
compiled back into the original object. The final linker will add
all these references into a single table.
On boot up, before SMP is initialized, the dynamic ftrace code
scans this table and updates all the locations into nops. It also
records the locations, which are added to the available_filter_functions
list. Modules are processed as they are loaded and before they are
executed. When a module is unloaded, it also removes its functions from
the ftrace function list. This is automatic in the module unload
code, and the module author does not need to worry about it.
When tracing is enabled, kstop_machine is called to prevent races
with the CPUS executing code being modified (which can cause the
CPU to do undesireable things), and the nops are patched back
to calls. But this time, they do not call mcount (which is just
a function stub). They now call into the ftrace infrastructure.
One special side-effect to the recording of the functions being
traced is that we can now selectively choose which functions we
@ -1248,36 +1256,6 @@ Produces:
We can see that there's no more lock or preempt tracing.
ftraced
-------
As mentioned above, when dynamic ftrace is configured in, a kernel
thread wakes up once a second and checks to see if there are mcount
calls that need to be converted into nops. If there are not any, then
it simply goes back to sleep. But if there are some, it will call
kstop_machine to convert the calls to nops.
There may be a case in which you do not want this added latency.
Perhaps you are doing some audio recording and this activity might
cause skips in the playback. There is an interface to disable
and enable the "ftraced" kernel thread.
# echo 0 > /debug/tracing/ftraced_enabled
This will disable the calling of kstop_machine to update the
mcount calls to nops. Remember that there is a large overhead
to calling mcount. Without this kernel thread, that overhead will
exist.
If there are recorded calls to mcount, any write to the ftraced_enabled
file will cause the kstop_machine to run. This means that a
user can manually perform the updates when they want to by simply
echoing a '0' into the ftraced_enabled file.
The updates are also done at the beginning of enabling a tracer
that uses ftrace function recording.
trace_pipe
----------
@ -1286,14 +1264,14 @@ on the tracing is different. Every read from trace_pipe is consumed.
This means that subsequent reads will be different. The trace
is live.
# echo ftrace > /debug/tracing/current_tracer
# echo function > /debug/tracing/current_tracer
# cat /debug/tracing/trace_pipe > /tmp/trace.out &
[1] 4153
# echo 1 > /debug/tracing/tracing_enabled
# usleep 1
# echo 0 > /debug/tracing/tracing_enabled
# cat /debug/tracing/trace
# tracer: ftrace
# tracer: function
#
# TASK-PID CPU# TIMESTAMP FUNCTION
# | | | | |
@ -1314,7 +1292,7 @@ is live.
Note, reading the trace_pipe file will block until more input is added.
By changing the tracer, trace_pipe will issue an EOF. We needed
to set the ftrace tracer _before_ cating the trace_pipe file.
to set the function tracer _before_ we "cat" the trace_pipe file.
trace entries
@ -1331,10 +1309,10 @@ number of entries.
65620
Note, to modify this, you must have tracing completely disabled. To do that,
echo "none" into the current_tracer. If the current_tracer is not set
to "none", an EINVAL error will be returned.
echo "nop" into the current_tracer. If the current_tracer is not set
to "nop", an EINVAL error will be returned.
# echo none > /debug/tracing/current_tracer
# echo nop > /debug/tracing/current_tracer
# echo 100000 > /debug/tracing/trace_entries
# cat /debug/tracing/trace_entries
100045

67
Documentation/hwmon/adt7462 Normal file
View File

@ -0,0 +1,67 @@
Kernel driver adt7462
======================
Supported chips:
* Analog Devices ADT7462
Prefix: 'adt7462'
Addresses scanned: I2C 0x58, 0x5C
Datasheet: Publicly available at the Analog Devices website
Author: Darrick J. Wong
Description
-----------
This driver implements support for the Analog Devices ADT7462 chip family.
This chip is a bit of a beast. It has 8 counters for measuring fan speed. It
can also measure 13 voltages or 4 temperatures, or various combinations of the
two. See the chip documentation for more details about the exact set of
configurations. This driver does not allow one to configure the chip; that is
left to the system designer.
A sophisticated control system for the PWM outputs is designed into the ADT7462
that allows fan speed to be adjusted automatically based on any of the three
temperature sensors. Each PWM output is individually adjustable and
programmable. Once configured, the ADT7462 will adjust the PWM outputs in
response to the measured temperatures without further host intervention. This
feature can also be disabled for manual control of the PWM's.
Each of the measured inputs (voltage, temperature, fan speed) has
corresponding high/low limit values. The ADT7462 will signal an ALARM if
any measured value exceeds either limit.
The ADT7462 samples all inputs continuously. The driver will not read
the registers more often than once every other second. Further,
configuration data is only read once per minute.
Special Features
----------------
The ADT7462 have a 10-bit ADC and can therefore measure temperatures
with 0.25 degC resolution.
The Analog Devices datasheet is very detailed and describes a procedure for
determining an optimal configuration for the automatic PWM control.
The driver will report sensor labels when it is able to determine that
information from the configuration registers.
Configuration Notes
-------------------
Besides standard interfaces driver adds the following:
* PWM Control
* pwm#_auto_point1_pwm and temp#_auto_point1_temp and
* pwm#_auto_point2_pwm and temp#_auto_point2_temp -
point1: Set the pwm speed at a lower temperature bound.
point2: Set the pwm speed at a higher temperature bound.
The ADT7462 will scale the pwm between the lower and higher pwm speed when
the temperature is between the two temperature boundaries. PWM values range
from 0 (off) to 255 (full speed). Fan speed will be set to maximum when the
temperature sensor associated with the PWM control exceeds temp#_max.

49
Documentation/hwmon/lis3lv02d Normal file
View File

@ -0,0 +1,49 @@
Kernel driver lis3lv02d
==================
Supported chips:
* STMicroelectronics LIS3LV02DL and LIS3LV02DQ
Author:
Yan Burman <burman.yan@gmail.com>
Eric Piel <eric.piel@tremplin-utc.net>
Description
-----------
This driver provides support for the accelerometer found in various HP laptops
sporting the feature officially called "HP Mobile Data Protection System 3D" or
"HP 3D DriveGuard". It detect automatically laptops with this sensor. Known models
(for now the HP 2133, nc6420, nc2510, nc8510, nc84x0, nw9440 and nx9420) will
have their axis automatically oriented on standard way (eg: you can directly
play neverball). The accelerometer data is readable via
/sys/devices/platform/lis3lv02d.
Sysfs attributes under /sys/devices/platform/lis3lv02d/:
position - 3D position that the accelerometer reports. Format: "(x,y,z)"
calibrate - read: values (x, y, z) that are used as the base for input class device operation.
write: forces the base to be recalibrated with the current position.
rate - reports the sampling rate of the accelerometer device in HZ
This driver also provides an absolute input class device, allowing
the laptop to act as a pinball machine-esque joystick.
Axes orientation
----------------
For better compatibility between the various laptops. The values reported by
the accelerometer are converted into a "standard" organisation of the axes
(aka "can play neverball out of the box"):
* When the laptop is horizontal the position reported is about 0 for X and Y
and a positive value for Z
* If the left side is elevated, X increases (becomes positive)
* If the front side (where the touchpad is) is elevated, Y decreases (becomes negative)
* If the laptop is put upside-down, Z becomes negative
If your laptop model is not recognized (cf "dmesg"), you can send an email to the
authors to add it to the database. When reporting a new laptop, please include
the output of "dmidecode" plus the value of /sys/devices/platform/lis3lv02d/position
in these four cases.

2
Documentation/hwmon/lm90
View File

@ -8,7 +8,7 @@ Supported chips:
Datasheet: Publicly available at the National Semiconductor website
http://www.national.com/pf/LM/LM90.html
* National Semiconductor LM89
Prefix: 'lm99'
Prefix: 'lm89' (no auto-detection)
Addresses scanned: I2C 0x4c and 0x4d
Datasheet: Publicly available at the National Semiconductor website
http://www.national.com/mpf/LM/LM89.html

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

@ -13,8 +13,9 @@ Supported adapters:
* Intel 631xESB/632xESB (ESB2)
* Intel 82801H (ICH8)
* Intel 82801I (ICH9)
* Intel Tolapai
* Intel ICH10
* Intel EP80579 (Tolapai)
* Intel 82801JI (ICH10)
* Intel PCH
Datasheets: Publicly available at the Intel website
Authors:
@ -32,7 +33,7 @@ Description
-----------
The ICH (properly known as the 82801AA), ICH0 (82801AB), ICH2 (82801BA),
ICH3 (82801CA/CAM) and later devices are Intel chips that are a part of
ICH3 (82801CA/CAM) and later devices (PCH) are Intel chips that are a part of
Intel's '810' chipset for Celeron-based PCs, '810E' chipset for
Pentium-based PCs, '815E' chipset, and others.

2
Documentation/i2c/busses/i2c-sis96x
View File

@ -42,7 +42,7 @@ I suspect that this driver could be made to work for the following SiS
chipsets as well: 635, and 635T. If anyone owns a board with those chips
AND is willing to risk crashing & burning an otherwise well-behaved kernel
in the name of progress... please contact me at <mhoffman@lightlink.com> or
via the project's mailing list: <i2c@lm-sensors.org>. Please send bug
via the linux-i2c mailing list: <linux-i2c@vger.kernel.org>. Please send bug
reports and/or success stories as well.

160
Documentation/i2c/porting-clients
View File

@ -1,160 +0,0 @@
Revision 7, 2007-04-19
Jean Delvare <khali@linux-fr.org>
Greg KH <greg@kroah.com>
This is a guide on how to convert I2C chip drivers from Linux 2.4 to
Linux 2.6. I have been using existing drivers (lm75, lm78) as examples.
Then I converted a driver myself (lm83) and updated this document.
Note that this guide is strongly oriented towards hardware monitoring
drivers. Many points are still valid for other type of drivers, but
others may be irrelevant.
There are two sets of points below. The first set concerns technical
changes. The second set concerns coding policy. Both are mandatory.
Although reading this guide will help you porting drivers, I suggest
you keep an eye on an already ported driver while porting your own
driver. This will help you a lot understanding what this guide
exactly means. Choose the chip driver that is the more similar to
yours for best results.
Technical changes:
* [Driver type] Any driver that was relying on i2c-isa has to be
converted to a proper isa, platform or pci driver. This is not
covered by this guide.
* [Includes] Get rid of "version.h" and <linux/i2c-proc.h>.
Includes typically look like that:
#include <linux/module.h>
#include <linux/init.h>
#include <linux/slab.h>
#include <linux/jiffies.h>
#include <linux/i2c.h>
#include <linux/hwmon.h> /* for hardware monitoring drivers */
#include <linux/hwmon-sysfs.h>
#include <linux/hwmon-vid.h> /* if you need VRM support */
#include <linux/err.h> /* for class registration */
Please respect this inclusion order. Some extra headers may be
required for a given driver (e.g. "lm75.h").
* [Addresses] SENSORS_I2C_END becomes I2C_CLIENT_END, ISA addresses
are no more handled by the i2c core. Address ranges are no more
supported either, define each individual address separately.
SENSORS_INSMOD_<n> becomes I2C_CLIENT_INSMOD_<n>.
* [Client data] Get rid of sysctl_id. Try using standard names for
register values (for example, temp_os becomes temp_max). You're
still relatively free here, but you *have* to follow the standard
names for sysfs files (see the Sysctl section below).
* [Function prototypes] The detect functions loses its flags
parameter. Sysctl (e.g. lm75_temp) and miscellaneous functions
are off the list of prototypes. This usually leaves five
prototypes:
static int lm75_attach_adapter(struct i2c_adapter *adapter);
static int lm75_detect(struct i2c_adapter *adapter, int address,
int kind);
static void lm75_init_client(struct i2c_client *client);
static int lm75_detach_client(struct i2c_client *client);
static struct lm75_data lm75_update_device(struct device *dev);
* [Sysctl] All sysctl stuff is of course gone (defines, ctl_table
and functions). Instead, you have to define show and set functions for
each sysfs file. Only define set for writable values. Take a look at an
existing 2.6 driver for details (it87 for example). Don't forget
to define the attributes for each file (this is that step that
links callback functions). Use the file names specified in
Documentation/hwmon/sysfs-interface for the individual files. Also
convert the units these files read and write to the specified ones.
If you need to add a new type of file, please discuss it on the
sensors mailing list <lm-sensors@lm-sensors.org> by providing a
patch to the Documentation/hwmon/sysfs-interface file.
* [Attach] The attach function should make sure that the adapter's
class has I2C_CLASS_HWMON (or whatever class is suitable for your
driver), using the following construct:
if (!(adapter->class & I2C_CLASS_HWMON))
return 0;
Call i2c_probe() instead of i2c_detect().
* [Detect] As mentioned earlier, the flags parameter is gone.
The type_name and client_name strings are replaced by a single
name string, which will be filled with a lowercase, short string.
The labels used for error paths are reduced to the number needed.
It is advised that the labels are given descriptive names such as
exit and exit_free. Don't forget to properly set err before
jumping to error labels. By the way, labels should be left-aligned.
Use kzalloc instead of kmalloc.
Use i2c_set_clientdata to set the client data (as opposed to
a direct access to client->data).
Use strlcpy instead of strcpy or snprintf to copy the client name.
Replace the sysctl directory registration by calls to
device_create_file. Move the driver initialization before any
sysfs file creation.
Register the client with the hwmon class (using hwmon_device_register)
if applicable.
Drop client->id.
Drop any 24RF08 corruption prevention you find, as this is now done
at the i2c-core level, and doing it twice voids it.
Don't add I2C_CLIENT_ALLOW_USE to client->flags, it's the default now.
* [Init] Limits must not be set by the driver (can be done later in
user-space). Chip should not be reset default (although a module
parameter may be used to force it), and initialization should be
limited to the strictly necessary steps.
* [Detach] Remove the call to i2c_deregister_entry. Do not log an
error message if i2c_detach_client fails, as i2c-core will now do
it for you.
Unregister from the hwmon class if applicable.
* [Update] The function prototype changed, it is now
passed a device structure, which you have to convert to a client
using to_i2c_client(dev). The update function should return a
pointer to the client data.
Don't access client->data directly, use i2c_get_clientdata(client)
instead.
Use time_after() instead of direct jiffies comparison.
* [Interface] Make sure there is a MODULE_LICENSE() line, at the bottom
of the file (after MODULE_AUTHOR() and MODULE_DESCRIPTION(), in this
order).
* [Driver] The flags field of the i2c_driver structure is gone.
I2C_DF_NOTIFY is now the default behavior.
The i2c_driver structure has a driver member, which is itself a
structure, those name member should be initialized to a driver name
string. i2c_driver itself has no name member anymore.
* [Driver model] Instead of shutdown or reboot notifiers, provide a
shutdown() method in your driver.
* [Power management] Use the driver model suspend() and resume()
callbacks instead of the obsolete pm_register() calls.
Coding policy:
* [Copyright] Use (C), not (c), for copyright.
* [Debug/log] Get rid of #ifdef DEBUG/#endif constructs whenever you
can. Calls to printk for debugging purposes are replaced by calls to
dev_dbg where possible, else to pr_debug. Here is an example of how
to call it (taken from lm75_detect):
dev_dbg(&client->dev, "Starting lm75 update\n");
Replace other printk calls with the dev_info, dev_err or dev_warn
function, as appropriate.
* [Constants] Constants defines (registers, conversions) should be
aligned. This greatly improves readability.
Alignments are achieved by the means of tabs, not spaces. Remember
that tabs are set to 8 in the Linux kernel code.
* [Layout] Avoid extra empty lines between comments and what they
comment. Respect the coding style (see Documentation/CodingStyle),
in particular when it comes to placing curly braces.
* [Comments] Make sure that no comment refers to a file that isn't
part of the Linux source tree (typically doc/chips/<chip name>),
and that remaining comments still match the code. Merging comment
lines when possible is encouraged.

475
Documentation/i2c/writing-clients
View File

@ -10,23 +10,21 @@ General remarks
===============
Try to keep the kernel namespace as clean as possible. The best way to
do this is to use a unique prefix for all global symbols. This is
do this is to use a unique prefix for all global symbols. This is
especially important for exported symbols, but it is a good idea to do
it for non-exported symbols too. We will use the prefix `foo_' in this
tutorial, and `FOO_' for preprocessor variables.
tutorial.
The driver structure
====================
Usually, you will implement a single driver structure, and instantiate
all clients from it. Remember, a driver structure contains general access
all clients from it. Remember, a driver structure contains general access
routines, and should be zero-initialized except for fields with data you
provide. A client structure holds device-specific information like the
driver model device node, and its I2C address.
/* iff driver uses driver model ("new style") binding model: */
static struct i2c_device_id foo_idtable[] = {
{ "foo", my_id_for_foo },
{ "bar", my_id_for_bar },
@ -40,7 +38,6 @@ static struct i2c_driver foo_driver = {
.name = "foo",
},
/* iff driver uses driver model ("new style") binding model: */
.id_table = foo_ids,
.probe = foo_probe,
.remove = foo_remove,
@ -49,24 +46,19 @@ static struct i2c_driver foo_driver = {
.detect = foo_detect,
.address_data = &addr_data,
/* else, driver uses "legacy" binding model: */
.attach_adapter = foo_attach_adapter,
.detach_client = foo_detach_client,
/* these may be used regardless of the driver binding model */
.shutdown = foo_shutdown, /* optional */
.suspend = foo_suspend, /* optional */
.resume = foo_resume, /* optional */
.command = foo_command, /* optional */
.command = foo_command, /* optional, deprecated */
}
The name field is the driver name, and must not contain spaces. It
should match the module name (if the driver can be compiled as a module),
although you can use MODULE_ALIAS (passing "foo" in this example) to add
another name for the module. If the driver name doesn't match the module
name, the module won't be automatically loaded (hotplug/coldplug).
All other fields are for call-back functions which will be explained
All other fields are for call-back functions which will be explained
below.
@ -74,34 +66,13 @@ Extra client data
=================
Each client structure has a special `data' field that can point to any
structure at all. You should use this to keep device-specific data,
especially in drivers that handle multiple I2C or SMBUS devices. You
do not always need this, but especially for `sensors' drivers, it can
be very useful.
structure at all. You should use this to keep device-specific data.
/* store the value */
void i2c_set_clientdata(struct i2c_client *client, void *data);
/* retrieve the value */
void *i2c_get_clientdata(struct i2c_client *client);
An example structure is below.
struct foo_data {
struct i2c_client client;
enum chips type; /* To keep the chips type for `sensors' drivers. */
/* Because the i2c bus is slow, it is often useful to cache the read
information of a chip for some time (for example, 1 or 2 seconds).
It depends of course on the device whether this is really worthwhile
or even sensible. */
struct mutex update_lock; /* When we are reading lots of information,
another process should not update the
below information */
char valid; /* != 0 if the following fields are valid. */
unsigned long last_updated; /* In jiffies */
/* Add the read information here too */
};
void *i2c_get_clientdata(const struct i2c_client *client);
Accessing the client
@ -109,11 +80,9 @@ Accessing the client
Let's say we have a valid client structure. At some time, we will need
to gather information from the client, or write new information to the
client. How we will export this information to user-space is less
important at this moment (perhaps we do not need to do this at all for
some obscure clients). But we need generic reading and writing routines.
client.
I have found it useful to define foo_read and foo_write function for this.
I have found it useful to define foo_read and foo_write functions for this.
For some cases, it will be easier to call the i2c functions directly,
but many chips have some kind of register-value idea that can easily
be encapsulated.
@ -121,33 +90,33 @@ be encapsulated.
The below functions are simple examples, and should not be copied
literally.
int foo_read_value(struct i2c_client *client, u8 reg)
{
if (reg < 0x10) /* byte-sized register */
return i2c_smbus_read_byte_data(client,reg);
else /* word-sized register */
return i2c_smbus_read_word_data(client,reg);
}
int foo_read_value(struct i2c_client *client, u8 reg)
{
if (reg < 0x10) /* byte-sized register */
return i2c_smbus_read_byte_data(client, reg);
else /* word-sized register */
return i2c_smbus_read_word_data(client, reg);
}
int foo_write_value(struct i2c_client *client, u8 reg, u16 value)
{
if (reg == 0x10) /* Impossible to write - driver error! */ {
return -1;
else if (reg < 0x10) /* byte-sized register */
return i2c_smbus_write_byte_data(client,reg,value);
else /* word-sized register */
return i2c_smbus_write_word_data(client,reg,value);
}
int foo_write_value(struct i2c_client *client, u8 reg, u16 value)
{
if (reg == 0x10) /* Impossible to write - driver error! */
return -EINVAL;
else if (reg < 0x10) /* byte-sized register */
return i2c_smbus_write_byte_data(client, reg, value);
else /* word-sized register */
return i2c_smbus_write_word_data(client, reg, value);
}
Probing and attaching
=====================
The Linux I2C stack was originally written to support access to hardware
monitoring chips on PC motherboards, and thus it embeds some assumptions
that are more appropriate to SMBus (and PCs) than to I2C. One of these
assumptions is that most adapters and devices drivers support the SMBUS_QUICK
protocol to probe device presence. Another is that devices and their drivers
monitoring chips on PC motherboards, and thus used to embed some assumptions
that were more appropriate to SMBus (and PCs) than to I2C. One of these
assumptions was that most adapters and devices drivers support the SMBUS_QUICK
protocol to probe device presence. Another was that devices and their drivers
can be sufficiently configured using only such probe primitives.
As Linux and its I2C stack became more widely used in embedded systems
@ -164,6 +133,9 @@ since the "legacy" model requires drivers to create "i2c_client" device
objects after SMBus style probing, while the Linux driver model expects
drivers to be given such device objects in their probe() routines.
The legacy model is deprecated now and will soon be removed, so we no
longer document it here.
Standard Driver Model Binding ("New Style")
-------------------------------------------
@ -193,8 +165,8 @@ matches the device's name. It is passed the entry that was matched so
the driver knows which one in the table matched.
Device Creation (Standard driver model)
---------------------------------------
Device Creation
---------------
If you know for a fact that an I2C device is connected to a given I2C bus,
you can instantiate that device by simply filling an i2c_board_info
@ -221,8 +193,8 @@ in the I2C bus driver. You may want to save the returned i2c_client
reference for later use.
Device Detection (Standard driver model)
----------------------------------------
Device Detection
----------------
Sometimes you do not know in advance which I2C devices are connected to
a given I2C bus. This is for example the case of hardware monitoring
@ -246,8 +218,8 @@ otherwise misdetections are likely to occur and things can get wrong
quickly.
Device Deletion (Standard driver model)
---------------------------------------
Device Deletion
---------------
Each I2C device which has been created using i2c_new_device() or
i2c_new_probed_device() can be unregistered by calling
@ -256,264 +228,37 @@ called automatically before the underlying I2C bus itself is removed, as a
device can't survive its parent in the device driver model.
Legacy Driver Binding Model
---------------------------
Initializing the driver
=======================
Most i2c devices can be present on several i2c addresses; for some this
is determined in hardware (by soldering some chip pins to Vcc or Ground),
for others this can be changed in software (by writing to specific client
registers). Some devices are usually on a specific address, but not always;
and some are even more tricky. So you will probably need to scan several
i2c addresses for your clients, and do some sort of detection to see
whether it is actually a device supported by your driver.
When the kernel is booted, or when your foo driver module is inserted,
you have to do some initializing. Fortunately, just registering the
driver module is usually enough.
To give the user a maximum of possibilities, some default module parameters
are defined to help determine what addresses are scanned. Several macros
are defined in i2c.h to help you support them, as well as a generic
detection algorithm.
static int __init foo_init(void)
{
return i2c_add_driver(&foo_driver);
}
You do not have to use this parameter interface; but don't try to use
function i2c_probe() if you don't.
static void __exit foo_cleanup(void)
{
i2c_del_driver(&foo_driver);
}
/* Substitute your own name and email address */
MODULE_AUTHOR("Frodo Looijaard <frodol@dds.nl>"
MODULE_DESCRIPTION("Driver for Barf Inc. Foo I2C devices");
Probing classes (Legacy model)
------------------------------
/* a few non-GPL license types are also allowed */
MODULE_LICENSE("GPL");
All parameters are given as lists of unsigned 16-bit integers. Lists are
terminated by I2C_CLIENT_END.
The following lists are used internally:
module_init(foo_init);
module_exit(foo_cleanup);
normal_i2c: filled in by the module writer.
A list of I2C addresses which should normally be examined.
probe: insmod parameter.
A list of pairs. The first value is a bus number (-1 for any I2C bus),
the second is the address. These addresses are also probed, as if they
were in the 'normal' list.
ignore: insmod parameter.
A list of pairs. The first value is a bus number (-1 for any I2C bus),
the second is the I2C address. These addresses are never probed.
This parameter overrules the 'normal_i2c' list only.
force: insmod parameter.
A list of pairs. The first value is a bus number (-1 for any I2C bus),
the second is the I2C address. A device is blindly assumed to be on
the given address, no probing is done.
Additionally, kind-specific force lists may optionally be defined if
the driver supports several chip kinds. They are grouped in a
NULL-terminated list of pointers named forces, those first element if the
generic force list mentioned above. Each additional list correspond to an
insmod parameter of the form force_<kind>.
Fortunately, as a module writer, you just have to define the `normal_i2c'
parameter. The complete declaration could look like this:
/* Scan 0x4c to 0x4f */
static const unsigned short normal_i2c[] = { 0x4c, 0x4d, 0x4e, 0x4f,
I2C_CLIENT_END };
/* Magic definition of all other variables and things */
I2C_CLIENT_INSMOD;
/* Or, if your driver supports, say, 2 kind of devices: */
I2C_CLIENT_INSMOD_2(foo, bar);
If you use the multi-kind form, an enum will be defined for you:
enum chips { any_chip, foo, bar, ... }
You can then (and certainly should) use it in the driver code.
Note that you *have* to call the defined variable `normal_i2c',
without any prefix!
Attaching to an adapter (Legacy model)
--------------------------------------
Whenever a new adapter is inserted, or for all adapters if the driver is
being registered, the callback attach_adapter() is called. Now is the
time to determine what devices are present on the adapter, and to register
a client for each of them.
The attach_adapter callback is really easy: we just call the generic
detection function. This function will scan the bus for us, using the
information as defined in the lists explained above. If a device is
detected at a specific address, another callback is called.
int foo_attach_adapter(struct i2c_adapter *adapter)
{
return i2c_probe(adapter,&addr_data,&foo_detect_client);
}
Remember, structure `addr_data' is defined by the macros explained above,
so you do not have to define it yourself.
The i2c_probe function will call the foo_detect_client
function only for those i2c addresses that actually have a device on
them (unless a `force' parameter was used). In addition, addresses that
are already in use (by some other registered client) are skipped.
The detect client function (Legacy model)
-----------------------------------------
The detect client function is called by i2c_probe. The `kind' parameter
contains -1 for a probed detection, 0 for a forced detection, or a positive
number for a forced detection with a chip type forced.
Returning an error different from -ENODEV in a detect function will cause
the detection to stop: other addresses and adapters won't be scanned.
This should only be done on fatal or internal errors, such as a memory
shortage or i2c_attach_client failing.
For now, you can ignore the `flags' parameter. It is there for future use.
int foo_detect_client(struct i2c_adapter *adapter, int address,
int kind)
{
int err = 0;
int i;
struct i2c_client *client;
struct foo_data *data;
const char *name = "";
/* Let's see whether this adapter can support what we need.
Please substitute the things you need here! */
if (!i2c_check_functionality(adapter,I2C_FUNC_SMBUS_WORD_DATA |
I2C_FUNC_SMBUS_WRITE_BYTE))
goto ERROR0;
/* OK. For now, we presume we have a valid client. We now create the
client structure, even though we cannot fill it completely yet.
But it allows us to access several i2c functions safely */
if (!(data = kzalloc(sizeof(struct foo_data), GFP_KERNEL))) {
err = -ENOMEM;
goto ERROR0;
}
client = &data->client;
i2c_set_clientdata(client, data);
client->addr = address;
client->adapter = adapter;
client->driver = &foo_driver;
/* Now, we do the remaining detection. If no `force' parameter is used. */
/* First, the generic detection (if any), that is skipped if any force
parameter was used. */
if (kind < 0) {
/* The below is of course bogus */
if (foo_read(client, FOO_REG_GENERIC) != FOO_GENERIC_VALUE)
goto ERROR1;
}
/* Next, specific detection. This is especially important for `sensors'
devices. */
/* Determine the chip type. Not needed if a `force_CHIPTYPE' parameter
was used. */
if (kind <= 0) {
i = foo_read(client, FOO_REG_CHIPTYPE);
if (i == FOO_TYPE_1)
kind = chip1; /* As defined in the enum */
else if (i == FOO_TYPE_2)
kind = chip2;
else {
printk("foo: Ignoring 'force' parameter for unknown chip at "
"adapter %d, address 0x%02x\n",i2c_adapter_id(adapter),address);
goto ERROR1;
}
}
/* Now set the type and chip names */
if (kind == chip1) {
name = "chip1";
} else if (kind == chip2) {
name = "chip2";
}
/* Fill in the remaining client fields. */
strlcpy(client->name, name, I2C_NAME_SIZE);
data->type = kind;
mutex_init(&data->update_lock); /* Only if you use this field */
/* Any other initializations in data must be done here too. */
/* This function can write default values to the client registers, if
needed. */
foo_init_client(client);
/* Tell the i2c layer a new client has arrived */
if ((err = i2c_attach_client(client)))
goto ERROR1;
return 0;
/* OK, this is not exactly good programming practice, usually. But it is
very code-efficient in this case. */
ERROR1:
kfree(data);
ERROR0:
return err;
}
Removing the client (Legacy model)
==================================
The detach_client call back function is called when a client should be
removed. It may actually fail, but only when panicking. This code is
much simpler than the attachment code, fortunately!
int foo_detach_client(struct i2c_client *client)
{
int err;
/* Try to detach the client from i2c space */
if ((err = i2c_detach_client(client)))
return err;
kfree(i2c_get_clientdata(client));
return 0;
}
Initializing the module or kernel
=================================
When the kernel is booted, or when your foo driver module is inserted,
you have to do some initializing. Fortunately, just attaching (registering)
the driver module is usually enough.
static int __init foo_init(void)
{
int res;
if ((res = i2c_add_driver(&foo_driver))) {
printk("foo: Driver registration failed, module not inserted.\n");
return res;
}
return 0;
}
static void __exit foo_cleanup(void)
{
i2c_del_driver(&foo_driver);
}
/* Substitute your own name and email address */
MODULE_AUTHOR("Frodo Looijaard <frodol@dds.nl>"
MODULE_DESCRIPTION("Driver for Barf Inc. Foo I2C devices");
/* a few non-GPL license types are also allowed */
MODULE_LICENSE("GPL");
module_init(foo_init);
module_exit(foo_cleanup);
Note that some functions are marked by `__init', and some data structures
by `__initdata'. These functions and structures can be removed after
kernel booting (or module loading) is completed.
Note that some functions are marked by `__init'. These functions can
be removed after kernel booting (or module loading) is completed.
Likewise, functions marked by `__exit' are dropped by the compiler when
the code is built into the kernel, as they would never be called.
Power Management
@ -548,33 +293,35 @@ Command function
A generic ioctl-like function call back is supported. You will seldom
need this, and its use is deprecated anyway, so newer design should not
use it. Set it to NULL.
use it.
Sending and receiving
=====================
If you want to communicate with your device, there are several functions
to do this. You can find all of them in i2c.h.
to do this. You can find all of them in <linux/i2c.h>.
If you can choose between plain i2c communication and SMBus level
communication, please use the last. All adapters understand SMBus level
commands, but only some of them understand plain i2c!
If you can choose between plain I2C communication and SMBus level
communication, please use the latter. All adapters understand SMBus level
commands, but only some of them understand plain I2C!
Plain i2c communication
Plain I2C communication
-----------------------
extern int i2c_master_send(struct i2c_client *,const char* ,int);
extern int i2c_master_recv(struct i2c_client *,char* ,int);
int i2c_master_send(struct i2c_client *client, const char *buf,
int count);
int i2c_master_recv(struct i2c_client *client, char *buf, int count);
These routines read and write some bytes from/to a client. The client
contains the i2c address, so you do not have to include it. The second
parameter contains the bytes the read/write, the third the length of the
buffer. Returned is the actual number of bytes read/written.
extern int i2c_transfer(struct i2c_adapter *adap, struct i2c_msg *msg,
int num);
parameter contains the bytes to read/write, the third the number of bytes
to read/write (must be less than the length of the buffer.) Returned is
the actual number of bytes read/written.
int i2c_transfer(struct i2c_adapter *adap, struct i2c_msg *msg,
int num);
This sends a series of messages. Each message can be a read or write,
and they can be mixed in any way. The transactions are combined: no
@ -583,49 +330,45 @@ for each message the client address, the number of bytes of the message
and the message data itself.
You can read the file `i2c-protocol' for more information about the
actual i2c protocol.
actual I2C protocol.
SMBus communication
-------------------
extern s32 i2c_smbus_xfer (struct i2c_adapter * adapter, u16 addr,
unsigned short flags,
char read_write, u8 command, int size,
union i2c_smbus_data * data);
s32 i2c_smbus_xfer(struct i2c_adapter *adapter, u16 addr,
unsigned short flags, char read_write, u8 command,
int size, union i2c_smbus_data *data);
This is the generic SMBus function. All functions below are implemented
in terms of it. Never use this function directly!
This is the generic SMBus function. All functions below are implemented
in terms of it. Never use this function directly!
extern s32 i2c_smbus_read_byte(struct i2c_client * client);
extern s32 i2c_smbus_write_byte(struct i2c_client * client, u8 value);
extern s32 i2c_smbus_read_byte_data(struct i2c_client * client, u8 command);
extern s32 i2c_smbus_write_byte_data(struct i2c_client * client,
u8 command, u8 value);
extern s32 i2c_smbus_read_word_data(struct i2c_client * client, u8 command);
extern s32 i2c_smbus_write_word_data(struct i2c_client * client,
u8 command, u16 value);
extern s32 i2c_smbus_process_call(struct i2c_client *client,
u8 command, u16 value);
extern s32 i2c_smbus_read_block_data(struct i2c_client * client,
u8 command, u8 *values);
extern s32 i2c_smbus_write_block_data(struct i2c_client * client,
u8 command, u8 length,
u8 *values);
extern s32 i2c_smbus_read_i2c_block_data(struct i2c_client * client,
u8 command, u8 length, u8 *values);
extern s32 i2c_smbus_write_i2c_block_data(struct i2c_client * client,
u8 command, u8 length,
u8 *values);
s32 i2c_smbus_read_byte(struct i2c_client *client);
s32 i2c_smbus_write_byte(struct i2c_client *client, u8 value);
s32 i2c_smbus_read_byte_data(struct i2c_client *client, u8 command);
s32 i2c_smbus_write_byte_data(struct i2c_client *client,
u8 command, u8 value);
s32 i2c_smbus_read_word_data(struct i2c_client *client, u8 command);
s32 i2c_smbus_write_word_data(struct i2c_client *client,
u8 command, u16 value);
s32 i2c_smbus_process_call(struct i2c_client *client,
u8 command, u16 value);
s32 i2c_smbus_read_block_data(struct i2c_client *client,
u8 command, u8 *values);
s32 i2c_smbus_write_block_data(struct i2c_client *client,
u8 command, u8 length, const u8 *values);
s32 i2c_smbus_read_i2c_block_data(struct i2c_client *client,
u8 command, u8 length, u8 *values);
s32 i2c_smbus_write_i2c_block_data(struct i2c_client *client,
u8 command, u8 length,
const u8 *values);
These ones were removed from i2c-core because they had no users, but could
be added back later if needed:
extern s32 i2c_smbus_write_quick(struct i2c_client * client, u8 value);
extern s32 i2c_smbus_block_process_call(struct i2c_client *client,
u8 command, u8 length,
u8 *values)
s32 i2c_smbus_write_quick(struct i2c_client *client, u8 value);
s32 i2c_smbus_block_process_call(struct i2c_client *client,
u8 command, u8 length, u8 *values);
All these transactions return a negative errno value on failure. The 'write'
transactions return 0 on success; the 'read' transactions return the read
@ -642,7 +385,5 @@ General purpose routines
Below all general purpose routines are listed, that were not mentioned
before.
/* This call returns a unique low identifier for each registered adapter.
*/
extern int i2c_adapter_id(struct i2c_adapter *adap);
/* Return the adapter number for a specific adapter */
int i2c_adapter_id(struct i2c_adapter *adap);

1
Documentation/ia64/.gitignore vendored Normal file
View File

@ -0,0 +1 @@
aliasing-test

183
Documentation/ia64/xen.txt Normal file
View File

@ -0,0 +1,183 @@
Recipe for getting/building/running Xen/ia64 with pv_ops
--------------------------------------------------------
This recipe describes how to get xen-ia64 source and build it,
and run domU with pv_ops.
============
Requirements
============
- python
- mercurial
it (aka "hg") is an open-source source code
management software. See the below.
http://www.selenic.com/mercurial/wiki/
- git
- bridge-utils
=================================
Getting and Building Xen and Dom0
=================================
My environment is;
Machine : Tiger4
Domain0 OS : RHEL5
DomainU OS : RHEL5
1. Download source
# hg clone http://xenbits.xensource.com/ext/ia64/xen-unstable.hg
# cd xen-unstable.hg
# hg clone http://xenbits.xensource.com/ext/ia64/linux-2.6.18-xen.hg
2. # make world
3. # make install-tools
4. copy kernels and xen
# cp xen/xen.gz /boot/efi/efi/redhat/
# cp build-linux-2.6.18-xen_ia64/vmlinux.gz \
/boot/efi/efi/redhat/vmlinuz-2.6.18.8-xen
5. make initrd for Dom0/DomU
# make -C linux-2.6.18-xen.hg ARCH=ia64 modules_install \
O=$(/bin/pwd)/build-linux-2.6.18-xen_ia64
# mkinitrd -f /boot/efi/efi/redhat/initrd-2.6.18.8-xen.img \
2.6.18.8-xen --builtin mptspi --builtin mptbase \
--builtin mptscsih --builtin uhci-hcd --builtin ohci-hcd \
--builtin ehci-hcd
================================
Making a disk image for guest OS
================================
1. make file
# dd if=/dev/zero of=/root/rhel5.img bs=1M seek=4096 count=0
# mke2fs -F -j /root/rhel5.img
# mount -o loop /root/rhel5.img /mnt
# cp -ax /{dev,var,etc,usr,bin,sbin,lib} /mnt
# mkdir /mnt/{root,proc,sys,home,tmp}
Note: You may miss some device files. If so, please create them
with mknod. Or you can use tar instead of cp.
2. modify DomU's fstab
# vi /mnt/etc/fstab
/dev/xvda1 / ext3 defaults 1 1
none /dev/pts devpts gid=5,mode=620 0 0
none /dev/shm tmpfs defaults 0 0
none /proc proc defaults 0 0
none /sys sysfs defaults 0 0
3. modify inittab
set runlevel to 3 to avoid X trying to start
# vi /mnt/etc/inittab
id:3:initdefault:
Start a getty on the hvc0 console
X0:2345:respawn:/sbin/mingetty hvc0
tty1-6 mingetty can be commented out
4. add hvc0 into /etc/securetty
# vi /mnt/etc/securetty (add hvc0)
5. umount
# umount /mnt
FYI, virt-manager can also make a disk image for guest OS.
It's GUI tools and easy to make it.
==================
Boot Xen & Domain0
==================
1. replace elilo
elilo of RHEL5 can boot Xen and Dom0.
If you use old elilo (e.g RHEL4), please download from the below
http://elilo.sourceforge.net/cgi-bin/blosxom
and copy into /boot/efi/efi/redhat/
# cp elilo-3.6-ia64.efi /boot/efi/efi/redhat/elilo.efi
2. modify elilo.conf (like the below)
# vi /boot/efi/efi/redhat/elilo.conf
prompt
timeout=20
default=xen
relocatable
image=vmlinuz-2.6.18.8-xen
label=xen
vmm=xen.gz
initrd=initrd-2.6.18.8-xen.img
read-only
append=" -- rhgb root=/dev/sda2"
The append options before "--" are for xen hypervisor,
the options after "--" are for dom0.
FYI, your machine may need console options like
"com1=19200,8n1 console=vga,com1". For example,
append="com1=19200,8n1 console=vga,com1 -- rhgb console=tty0 \
console=ttyS0 root=/dev/sda2"
=====================================
Getting and Building domU with pv_ops
=====================================
1. get pv_ops tree
# git clone http://people.valinux.co.jp/~yamahata/xen-ia64/linux-2.6-xen-ia64.git/
2. git branch (if necessary)
# cd linux-2.6-xen-ia64/
# git checkout -b your_branch origin/xen-ia64-domu-minimal-2008may19
(Note: The current branch is xen-ia64-domu-minimal-2008may19.
But you would find the new branch. You can see with
"git branch -r" to get the branch lists.
http://people.valinux.co.jp/~yamahata/xen-ia64/for_eagl/linux-2.6-ia64-pv-ops.git/
is also available. The tree is based on
git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6 test)
3. copy .config for pv_ops of domU
# cp arch/ia64/configs/xen_domu_wip_defconfig .config
4. make kernel with pv_ops
# make oldconfig
# make
5. install the kernel and initrd
# cp vmlinux.gz /boot/efi/efi/redhat/vmlinuz-2.6-pv_ops-xenU
# make modules_install
# mkinitrd -f /boot/efi/efi/redhat/initrd-2.6-pv_ops-xenU.img \
2.6.26-rc3xen-ia64-08941-g1b12161 --builtin mptspi \
--builtin mptbase --builtin mptscsih --builtin uhci-hcd \
--builtin ohci-hcd --builtin ehci-hcd
========================
Boot DomainU with pv_ops
========================
1. make config of DomU
# vi /etc/xen/rhel5
kernel = "/boot/efi/efi/redhat/vmlinuz-2.6-pv_ops-xenU"
ramdisk = "/boot/efi/efi/redhat/initrd-2.6-pv_ops-xenU.img"
vcpus = 1
memory = 512
name = "rhel5"
disk = [ 'file:/root/rhel5.img,xvda1,w' ]
root = "/dev/xvda1 ro"
extra= "rhgb console=hvc0"
2. After boot xen and dom0, start xend
# /etc/init.d/xend start
( In the debugging case, # XEND_DEBUG=1 xend trace_start )
3. start domU
# xm create -c rhel5
=========
Reference
=========
- Wiki of Xen/IA64 upstream merge
http://wiki.xensource.com/xenwiki/XenIA64/UpstreamMerge
Written by Akio Takebe <takebe_akio@jp.fujitsu.com> on 28 May 2008

31
Documentation/ics932s401 Normal file
View File

@ -0,0 +1,31 @@
Kernel driver ics932s401
======================
Supported chips:
* IDT ICS932S401
Prefix: 'ics932s401'
Addresses scanned: I2C 0x69
Datasheet: Publically available at the IDT website
Author: Darrick J. Wong
Description
-----------
This driver implements support for the IDT ICS932S401 chip family.
This chip has 4 clock outputs--a base clock for the CPU (which is likely
multiplied to get the real CPU clock), a system clock, a PCI clock, a USB
clock, and a reference clock. The driver reports selected and actual
frequency. If spread spectrum mode is enabled, the driver also reports by what
percent the clock signal is being spread, which should be between 0 and -0.5%.
All frequencies are reported in KHz.
The ICS932S401 monitors all inputs continuously. The driver will not read
the registers more often than once every other second.
Special Features
----------------
The clocks could be reprogrammed to increase system speed. I will not help you
do this, as you risk damaging your system!

405
Documentation/input/elantech.txt Normal file
View File

@ -0,0 +1,405 @@
Elantech Touchpad Driver
========================
Copyright (C) 2007-2008 Arjan Opmeer <arjan@opmeer.net>
Extra information for hardware version 1 found and
provided by Steve Havelka
Version 2 (EeePC) hardware support based on patches
received from Woody at Xandros and forwarded to me
by user StewieGriffin at the eeeuser.com forum
Contents
~~~~~~~~
1. Introduction
2. Extra knobs
3. Hardware version 1
3.1 Registers
3.2 Native relative mode 4 byte packet format
3.3 Native absolute mode 4 byte packet format
4. Hardware version 2
4.1 Registers
4.2 Native absolute mode 6 byte packet format
4.2.1 One finger touch
4.2.2 Two finger touch
1. Introduction
~~~~~~~~~~~~
Currently the Linux Elantech touchpad driver is aware of two different
hardware versions unimaginatively called version 1 and version 2. Version 1
is found in "older" laptops and uses 4 bytes per packet. Version 2 seems to
be introduced with the EeePC and uses 6 bytes per packet.
The driver tries to support both hardware versions and should be compatible
with the Xorg Synaptics touchpad driver and its graphical configuration
utilities.
Additionally the operation of the touchpad can be altered by adjusting the
contents of some of its internal registers. These registers are represented
by the driver as sysfs entries under /sys/bus/serio/drivers/psmouse/serio?
that can be read from and written to.
Currently only the registers for hardware version 1 are somewhat understood.
Hardware version 2 seems to use some of the same registers but it is not
known whether the bits in the registers represent the same thing or might
have changed their meaning.
On top of that, some register settings have effect only when the touchpad is
in relative mode and not in absolute mode. As the Linux Elantech touchpad
driver always puts the hardware into absolute mode not all information
mentioned below can be used immediately. But because there is no freely
available Elantech documentation the information is provided here anyway for
completeness sake.
/////////////////////////////////////////////////////////////////////////////
2. Extra knobs
~~~~~~~~~~~
Currently the Linux Elantech touchpad driver provides two extra knobs under
/sys/bus/serio/drivers/psmouse/serio? for the user.
* debug
Turn different levels of debugging ON or OFF.
By echoing "0" to this file all debugging will be turned OFF.
Currently a value of "1" will turn on some basic debugging and a value of
"2" will turn on packet debugging. For hardware version 1 the default is
OFF. For version 2 the default is "1".
Turning packet debugging on will make the driver dump every packet
received to the syslog before processing it. Be warned that this can
generate quite a lot of data!
* paritycheck
Turns parity checking ON or OFF.
By echoing "0" to this file parity checking will be turned OFF. Any
non-zero value will turn it ON. For hardware version 1 the default is ON.
For version 2 the default it is OFF.
Hardware version 1 provides basic data integrity verification by
calculating a parity bit for the last 3 bytes of each packet. The driver
can check these bits and reject any packet that appears corrupted. Using
this knob you can bypass that check.
It is not known yet whether hardware version 2 provides the same parity
bits. Hence checking is disabled by default. Currently even turning it on
will do nothing.
/////////////////////////////////////////////////////////////////////////////
3. Hardware version 1
==================
3.1 Registers
~~~~~~~~~
By echoing a hexadecimal value to a register it contents can be altered.
For example:
echo -n 0x16 > reg_10
* reg_10
bit 7 6 5 4 3 2 1 0
B C T D L A S E
E: 1 = enable smart edges unconditionally
S: 1 = enable smart edges only when dragging
A: 1 = absolute mode (needs 4 byte packets, see reg_11)
L: 1 = enable drag lock (see reg_22)
D: 1 = disable dynamic resolution
T: 1 = disable tapping
C: 1 = enable corner tap
B: 1 = swap left and right button
* reg_11
bit 7 6 5 4 3 2 1 0
1 0 0 H V 1 F P
P: 1 = enable parity checking for relative mode
F: 1 = enable native 4 byte packet mode
V: 1 = enable vertical scroll area
H: 1 = enable horizontal scroll area
* reg_20
single finger width?
* reg_21
scroll area width (small: 0x40 ... wide: 0xff)
* reg_22
drag lock time out (short: 0x14 ... long: 0xfe;
0xff = tap again to release)
* reg_23
tap make timeout?
* reg_24
tap release timeout?
* reg_25
smart edge cursor speed (0x02 = slow, 0x03 = medium, 0x04 = fast)
* reg_26
smart edge activation area width?
3.2 Native relative mode 4 byte packet format
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
byte 0:
bit 7 6 5 4 3 2 1 0
c c p2 p1 1 M R L
L, R, M = 1 when Left, Right, Middle mouse button pressed
some models have M as byte 3 odd parity bit
when parity checking is enabled (reg_11, P = 1):
p1..p2 = byte 1 and 2 odd parity bit
c = 1 when corner tap detected
byte 1:
bit 7 6 5 4 3 2 1 0
dx7 dx6 dx5 dx4 dx3 dx2 dx1 dx0
dx7..dx0 = x movement; positive = right, negative = left
byte 1 = 0xf0 when corner tap detected
byte 2:
bit 7 6 5 4 3 2 1 0
dy7 dy6 dy5 dy4 dy3 dy2 dy1 dy0
dy7..dy0 = y movement; positive = up, negative = down
byte 3:
parity checking enabled (reg_11, P = 1):
bit 7 6 5 4 3 2 1 0
w h n1 n0 ds3 ds2 ds1 ds0
normally:
ds3..ds0 = scroll wheel amount and direction
positive = down or left
negative = up or right
when corner tap detected:
ds0 = 1 when top right corner tapped
ds1 = 1 when bottom right corner tapped
ds2 = 1 when bottom left corner tapped
ds3 = 1 when top left corner tapped
n1..n0 = number of fingers on touchpad
only models with firmware 2.x report this, models with
firmware 1.x seem to map one, two and three finger taps
directly to L, M and R mouse buttons
h = 1 when horizontal scroll action
w = 1 when wide finger touch?
otherwise (reg_11, P = 0):
bit 7 6 5 4 3 2 1 0
ds7 ds6 ds5 ds4 ds3 ds2 ds1 ds0
ds7..ds0 = vertical scroll amount and direction
negative = up
positive = down
3.3 Native absolute mode 4 byte packet format
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
byte 0:
firmware version 1.x:
bit 7 6 5 4 3 2 1 0
D U p1 p2 1 p3 R L
L, R = 1 when Left, Right mouse button pressed
p1..p3 = byte 1..3 odd parity bit
D, U = 1 when rocker switch pressed Up, Down
firmware version 2.x:
bit 7 6 5 4 3 2 1 0
n1 n0 p2 p1 1 p3 R L
L, R = 1 when Left, Right mouse button pressed
p1..p3 = byte 1..3 odd parity bit
n1..n0 = number of fingers on touchpad
byte 1:
firmware version 1.x:
bit 7 6 5 4 3 2 1 0
f 0 th tw x9 x8 y9 y8
tw = 1 when two finger touch
th = 1 when three finger touch
f = 1 when finger touch
firmware version 2.x:
bit 7 6 5 4 3 2 1 0
. . . . x9 x8 y9 y8
byte 2:
bit 7 6 5 4 3 2 1 0
x7 x6 x5 x4 x3 x2 x1 x0
x9..x0 = absolute x value (horizontal)
byte 3:
bit 7 6 5 4 3 2 1 0
y7 y6 y5 y4 y3 y2 y1 y0
y9..y0 = absolute y value (vertical)
/////////////////////////////////////////////////////////////////////////////
4. Hardware version 2
==================
4.1 Registers
~~~~~~~~~
By echoing a hexadecimal value to a register it contents can be altered.
For example:
echo -n 0x56 > reg_10
* reg_10
bit 7 6 5 4 3 2 1 0
0 1 0 1 0 1 D 0
D: 1 = enable drag and drop
* reg_11
bit 7 6 5 4 3 2 1 0
1 0 0 0 S 0 1 0
S: 1 = enable vertical scroll
* reg_21
unknown (0x00)
* reg_22
drag and drop release time out (short: 0x70 ... long 0x7e;
0x7f = never i.e. tap again to release)
4.2 Native absolute mode 6 byte packet format
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4.2.1 One finger touch
~~~~~~~~~~~~~~~~
byte 0:
bit 7 6 5 4 3 2 1 0
n1 n0 . . . . R L
L, R = 1 when Left, Right mouse button pressed
n1..n0 = numbers of fingers on touchpad
byte 1:
bit 7 6 5 4 3 2 1 0
x15 x14 x13 x12 x11 x10 x9 x8
byte 2:
bit 7 6 5 4 3 2 1 0
x7 x6 x5 x4 x4 x2 x1 x0
x15..x0 = absolute x value (horizontal)
byte 3:
bit 7 6 5 4 3 2 1 0
. . . . . . . .
byte 4:
bit 7 6 5 4 3 2 1 0
y15 y14 y13 y12 y11 y10 y8 y8
byte 5:
bit 7 6 5 4 3 2 1 0
y7 y6 y5 y4 y3 y2 y1 y0
y15..y0 = absolute y value (vertical)
4.2.2 Two finger touch
~~~~~~~~~~~~~~~~
byte 0:
bit 7 6 5 4 3 2 1 0
n1 n0 ay8 ax8 . . R L
L, R = 1 when Left, Right mouse button pressed
n1..n0 = numbers of fingers on touchpad
byte 1:
bit 7 6 5 4 3 2 1 0
ax7 ax6 ax5 ax4 ax3 ax2 ax1 ax0
ax8..ax0 = first finger absolute x value
byte 2:
bit 7 6 5 4 3 2 1 0
ay7 ay6 ay5 ay4 ay3 ay2 ay1 ay0
ay8..ay0 = first finger absolute y value
byte 3:
bit 7 6 5 4 3 2 1 0
. . by8 bx8 . . . .
byte 4:
bit 7 6 5 4 3 2 1 0
bx7 bx6 bx5 bx4 bx3 bx2 bx1 bx0
bx8..bx0 = second finger absolute x value
byte 5:
bit 7 6 5 4 3 2 1 0
by7 by8 by5 by4 by3 by2 by1 by0
by8..by0 = second finger absolute y value

3
Documentation/input/input-programming.txt
View File

@ -20,10 +20,11 @@ pressed or released a BUTTON_IRQ happens. The driver could look like:
static struct input_dev *button_dev;
static void button_interrupt(int irq, void *dummy, struct pt_regs *fp)
static irqreturn_t button_interrupt(int irq, void *dummy)
{
input_report_key(button_dev, BTN_0, inb(BUTTON_PORT) & 1);
input_sync(button_dev);
return IRQ_HANDLED;
}
static int __init button_init(void)

82
Documentation/io-mapping.txt Normal file
View File

@ -0,0 +1,82 @@
The io_mapping functions in linux/io-mapping.h provide an abstraction for
efficiently mapping small regions of an I/O device to the CPU. The initial
usage is to support the large graphics aperture on 32-bit processors where
ioremap_wc cannot be used to statically map the entire aperture to the CPU
as it would consume too much of the kernel address space.
A mapping object is created during driver initialization using
struct io_mapping *io_mapping_create_wc(unsigned long base,
unsigned long size)
'base' is the bus address of the region to be made
mappable, while 'size' indicates how large a mapping region to
enable. Both are in bytes.
This _wc variant provides a mapping which may only be used
with the io_mapping_map_atomic_wc or io_mapping_map_wc.
With this mapping object, individual pages can be mapped either atomically
or not, depending on the necessary scheduling environment. Of course, atomic
maps are more efficient:
void *io_mapping_map_atomic_wc(struct io_mapping *mapping,
unsigned long offset)
'offset' is the offset within the defined mapping region.
Accessing addresses beyond the region specified in the
creation function yields undefined results. Using an offset
which is not page aligned yields an undefined result. The
return value points to a single page in CPU address space.
This _wc variant returns a write-combining map to the
page and may only be used with mappings created by
io_mapping_create_wc
Note that the task may not sleep while holding this page
mapped.
void io_mapping_unmap_atomic(void *vaddr)
'vaddr' must be the the value returned by the last
io_mapping_map_atomic_wc call. This unmaps the specified
page and allows the task to sleep once again.
If you need to sleep while holding the lock, you can use the non-atomic
variant, although they may be significantly slower.
void *io_mapping_map_wc(struct io_mapping *mapping,
unsigned long offset)
This works like io_mapping_map_atomic_wc except it allows
the task to sleep while holding the page mapped.
void io_mapping_unmap(void *vaddr)
This works like io_mapping_unmap_atomic, except it is used
for pages mapped with io_mapping_map_wc.
At driver close time, the io_mapping object must be freed:
void io_mapping_free(struct io_mapping *mapping)
Current Implementation:
The initial implementation of these functions uses existing mapping
mechanisms and so provides only an abstraction layer and no new
functionality.
On 64-bit processors, io_mapping_create_wc calls ioremap_wc for the whole
range, creating a permanent kernel-visible mapping to the resource. The
map_atomic and map functions add the requested offset to the base of the
virtual address returned by ioremap_wc.
On 32-bit processors with HIGHMEM defined, io_mapping_map_atomic_wc uses
kmap_atomic_pfn to map the specified page in an atomic fashion;
kmap_atomic_pfn isn't really supposed to be used with device pages, but it
provides an efficient mapping for this usage.
On 32-bit processors without HIGHMEM defined, io_mapping_map_atomic_wc and
io_mapping_map_wc both use ioremap_wc, a terribly inefficient function which
performs an IPI to inform all processors about the new mapping. This results
in a significant performance penalty.

10
Documentation/ioctl/00-INDEX Normal file
View File

@ -0,0 +1,10 @@
00-INDEX
- this file
cdrom.txt
- summary of CDROM ioctl calls
hdio.txt
- summary of HDIO_ ioctl calls
ioctl-decoding.txt
- how to decode the bits of an IOCTL code
ioctl-number.txt
- how to implement and register device/driver ioctl calls

0
Documentation/ioctl-number.txt → Documentation/ioctl/ioctl-number.txt
View File

2
Documentation/isdn/CREDITS
View File

@ -5,7 +5,7 @@ I want to thank all who contributed to this project and especially to:
Thomas Bogendörfer (tsbogend@bigbug.franken.de)
Tester, lots of bugfixes and hints.
Alan Cox (alan@redhat.com)
Alan Cox (alan@lxorguk.ukuu.org.uk)
For help getting into standard-kernel.
Henner Eisen (eis@baty.hanse.de)

14
Documentation/ja_JP/HOWTO
View File

@ -11,14 +11,14 @@ for non English (read: Japanese) speakers and is not intended as a
fork. So if you have any comments or updates for this file, please try
to update the original English file first.
Last Updated: 2008/08/21
Last Updated: 2008/10/24
==================================
これは、
linux-2.6.27/Documentation/HOWTO
linux-2.6.28/Documentation/HOWTO
の和訳です。
翻訳団体： JF プロジェクト < http://www.linux.or.jp/JF/ >
翻訳日： 2008/8/5
翻訳日： 2008/10/24
翻訳者： Tsugikazu Shibata <tshibata at ab dot jp dot nec dot com>
校正者： 松倉さん <nbh--mats at nifty dot com>
小林 雅典さん (Masanori Kobayasi) <zap03216 at nifty dot ne dot jp>
@ -110,8 +110,8 @@ Linux カーネルソースツリーは幅広い範囲のドキュメントを
新しいドキュメントファイルも追加することを勧めます。
カーネルの変更が、カーネルがユーザ空間に公開しているインターフェイスの
変更を引き起こす場合、その変更を説明するマニュアルページのパッチや情報
をマニュアルページのメンテナ mtk.manpages@gmail.com に送ることを勧めま
す。
をマニュアルページのメンテナ mtk.manpages@gmail.com に送り、CC を
linux-api@ver.kernel.org に送ることを勧めます。
以下はカーネルソースツリーに含まれている読んでおくべきファイルの一覧で
す-
@ -149,7 +149,7 @@ Linux カーネルソースツリーは幅広い範囲のドキュメントを
この他にパッチを作る方法についてのよくできた記述は-
"The Perfect Patch"
http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt
http://userweb.kernel.org/~akpm/stuff/tpp.txt
"Linux kernel patch submission format"
http://linux.yyz.us/patch-format.html
@ -664,7 +664,7 @@ Linux カーネルコミュニティは、一度に大量のコードの塊を
これについて全てがどのようにあるべきかについての詳細は、以下のドキュメ
ントの ChangeLog セクションを見てください-
"The Perfect Patch"
http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt
http://userweb.kernel.org/~akpm/stuff/tpp.txt
これらのどれもが、時にはとても困難です。これらの慣例を完璧に実施するに
は数年かかるかもしれません。これは継続的な改善のプロセスであり、そのた

14
Documentation/kdump/kdump.txt
View File

@ -109,7 +109,8 @@ There are two possible methods of using Kdump.
2) Or use the system kernel binary itself as dump-capture kernel and there is
no need to build a separate dump-capture kernel. This is possible
only with the architecutres which support a relocatable kernel. As
of today, i386, x86_64 and ia64 architectures support relocatable kernel.
of today, i386, x86_64, ppc64 and ia64 architectures support relocatable
kernel.
Building a relocatable kernel is advantageous from the point of view that
one does not have to build a second kernel for capturing the dump. But
@ -207,8 +208,15 @@ Dump-capture kernel config options (Arch Dependent, i386 and x86_64)
Dump-capture kernel config options (Arch Dependent, ppc64)
----------------------------------------------------------
* Make and install the kernel and its modules. DO NOT add this kernel
to the boot loader configuration files.
1) Enable "Build a kdump crash kernel" support under "Kernel" options:
CONFIG_CRASH_DUMP=y
2) Enable "Build a relocatable kernel" support
CONFIG_RELOCATABLE=y
Make and install the kernel and its modules.
Dump-capture kernel config options (Arch Dependent, ia64)
----------------------------------------------------------

137
Documentation/kernel-parameters.txt
View File

@ -100,7 +100,7 @@ parameter is applicable:
X86-32 X86-32, aka i386 architecture is enabled.
X86-64 X86-64 architecture is enabled.
More X86-64 boot options can be found in
Documentation/x86_64/boot-options.txt .
Documentation/x86/x86_64/boot-options.txt .
X86 Either 32bit or 64bit x86 (same as X86-32+X86-64)
In addition, the following text indicates that the option:
@ -112,10 +112,10 @@ In addition, the following text indicates that the option:
Parameters denoted with BOOT are actually interpreted by the boot
loader, and have no meaning to the kernel directly.
Do not modify the syntax of boot loader parameters without extreme
need or coordination with <Documentation/i386/boot.txt>.
need or coordination with <Documentation/x86/i386/boot.txt>.
There are also arch-specific kernel-parameters not documented here.
See for example <Documentation/x86_64/boot-options.txt>.
See for example <Documentation/x86/x86_64/boot-options.txt>.
Note that ALL kernel parameters listed below are CASE SENSITIVE, and that
a trailing = on the name of any parameter states that that parameter will
@ -198,40 +198,50 @@ and is between 256 and 4096 characters. It is defined in the file
that require a timer override, but don't have
HPET
acpi.debug_layer= [HW,ACPI]
Format: <int>
Each bit of the <int> indicates an ACPI debug layer,
1: enable, 0: disable. It is useful for boot time
debugging. After system has booted up, it can be set
via /sys/module/acpi/parameters/debug_layer.
CONFIG_ACPI_DEBUG must be enabled for this to produce any output.
Available bits (add the numbers together) to enable debug output
for specific parts of the ACPI subsystem:
0x01 utilities 0x02 hardware 0x04 events 0x08 tables
0x10 namespace 0x20 parser 0x40 dispatcher
0x80 executer 0x100 resources 0x200 acpica debugger
0x400 os services 0x800 acpica disassembler.
The number can be in decimal or prefixed with 0x in hex.
Warning: Many of these options can produce a lot of
output and make your system unusable. Be very careful.
acpi_backlight= [HW,ACPI]
acpi_backlight=vendor
acpi_backlight=video
If set to vendor, prefer vendor specific driver
(e.g. thinkpad_acpi, sony_acpi, etc.) instead
of the ACPI video.ko driver.
acpi.debug_level= [HW,ACPI]
acpi_display_output= [HW,ACPI]
acpi_display_output=vendor
acpi_display_output=video
See above.
acpi.debug_layer= [HW,ACPI,ACPI_DEBUG]
acpi.debug_level= [HW,ACPI,ACPI_DEBUG]
Format: <int>
Each bit of the <int> indicates an ACPI debug level,
1: enable, 0: disable. It is useful for boot time
debugging. After system has booted up, it can be set
via /sys/module/acpi/parameters/debug_level.
CONFIG_ACPI_DEBUG must be enabled for this to produce any output.
Available bits (add the numbers together) to enable different
debug output levels of the ACPI subsystem:
0x01 error 0x02 warn 0x04 init 0x08 debug object
0x10 info 0x20 init names 0x40 parse 0x80 load
0x100 dispatch 0x200 execute 0x400 names 0x800 operation region
0x1000 bfield 0x2000 tables 0x4000 values 0x8000 objects
0x10000 resources 0x20000 user requests 0x40000 package.
The number can be in decimal or prefixed with 0x in hex.
Warning: Many of these options can produce a lot of
output and make your system unusable. Be very careful.
CONFIG_ACPI_DEBUG must be enabled to produce any ACPI
debug output. Bits in debug_layer correspond to a
_COMPONENT in an ACPI source file, e.g.,
#define _COMPONENT ACPI_PCI_COMPONENT
Bits in debug_level correspond to a level in
ACPI_DEBUG_PRINT statements, e.g.,
ACPI_DEBUG_PRINT((ACPI_DB_INFO, ...
See Documentation/acpi/debug.txt for more information
about debug layers and levels.
Enable AML "Debug" output, i.e., stores to the Debug
object while interpreting AML:
acpi.debug_layer=0xffffffff acpi.debug_level=0x2
Enable PCI/PCI interrupt routing info messages:
acpi.debug_layer=0x400000 acpi.debug_level=0x4
Enable all messages related to ACPI hardware:
acpi.debug_layer=0x2 acpi.debug_level=0xffffffff
Some values produce so much output that the system is
unusable. The "log_buf_len" parameter may be useful
if you need to capture more output.
acpi.power_nocheck= [HW,ACPI]
Format: 1/0 enable/disable the check of power state.
On some bogus BIOS the _PSC object/_STA object of
power resource can't return the correct device power
state. In such case it is unneccessary to check its
power state again in power transition.
1 : disable the power state check
acpi_pm_good [X86-32,X86-64]
Override the pmtimer bug detection: force the kernel
@ -284,7 +294,9 @@ and is between 256 and 4096 characters. It is defined in the file
Possible values are:
isolate - enable device isolation (each device, as far
as possible, will get its own protection
domain)
domain) [default]
share - put every device behind one IOMMU into the
same protection domain
fullflush - enable flushing of IO/TLB entries when
they are unmapped. Otherwise they are
flushed before they will be reused, which
@ -619,7 +631,7 @@ and is between 256 and 4096 characters. It is defined in the file
digiepca= [HW,SERIAL]
See drivers/char/README.epca and
Documentation/digiepca.txt.
Documentation/serial/digiepca.txt.
disable_mtrr_cleanup [X86]
enable_mtrr_cleanup [X86]
@ -730,7 +742,7 @@ and is between 256 and 4096 characters. It is defined in the file
See header of drivers/scsi/fdomain.c.
floppy= [HW]
See Documentation/floppy.txt.
See Documentation/blockdev/floppy.txt.
force_pal_cache_flush
[IA-64] Avoid check_sal_cache_flush which may hang on
@ -968,13 +980,15 @@ and is between 256 and 4096 characters. It is defined in the file
Format:
<cpu number>,...,<cpu number>
or
<cpu number>-<cpu number> (must be a positive range in ascending order)
<cpu number>-<cpu number>
(must be a positive range in ascending order)
or a mixture
<cpu number>,...,<cpu number>-<cpu number>
This option can be used to specify one or more CPUs
to isolate from the general SMP balancing and scheduling
algorithms. The only way to move a process onto or off
an "isolated" CPU is via the CPU affinity syscalls.
algorithms. You can move a process onto or off an
"isolated" CPU via the CPU affinity syscalls or cpuset.
<cpu number> begins at 0 and the maximum value is
"number of CPUs in system - 1".
@ -1089,7 +1103,7 @@ and is between 256 and 4096 characters. It is defined in the file
the same attribute, the last one is used.
load_ramdisk= [RAM] List of ramdisks to load from floppy
See Documentation/ramdisk.txt.
See Documentation/blockdev/ramdisk.txt.
lockd.nlm_grace_period=P [NFS] Assign grace period.
Format: <integer>
@ -1181,8 +1195,8 @@ and is between 256 and 4096 characters. It is defined in the file
it is equivalent to "nosmp", which also disables
the IO APIC.
max_addr=[KMG] [KNL,BOOT,ia64] All physical memory greater than or
equal to this physical address is ignored.
max_addr=nn[KMG] [KNL,BOOT,ia64] All physical memory greater than
or equal to this physical address is ignored.
max_luns= [SCSI] Maximum number of LUNs to probe.
Should be between 1 and 2^32-1.
@ -1195,7 +1209,7 @@ and is between 256 and 4096 characters. It is defined in the file
mce [X86-32] Machine Check Exception
mce=option [X86-64] See Documentation/x86_64/boot-options.txt
mce=option [X86-64] See Documentation/x86/x86_64/boot-options.txt
md= [HW] RAID subsystems devices and level
See Documentation/md.txt.
@ -1282,6 +1296,9 @@ and is between 256 and 4096 characters. It is defined in the file
mga= [HW,DRM]
min_addr=nn[KMG] [KNL,BOOT,ia64] All physical memory below this
physical address is ignored.
mminit_loglevel=
[KNL] When CONFIG_DEBUG_MEMORY_INIT is set, this
parameter allows control of the logging verbosity for
@ -1443,8 +1460,6 @@ and is between 256 and 4096 characters. It is defined in the file
Valid arguments: on, off
Default: on
noirqbalance [X86-32,SMP,KNL] Disable kernel irq balancing
noirqdebug [X86-32] Disables the code which attempts to detect and
disable unhandled interrupt sources.
@ -1586,7 +1601,7 @@ and is between 256 and 4096 characters. It is defined in the file
pcd. [PARIDE]
See header of drivers/block/paride/pcd.c.
See also Documentation/paride.txt.
See also Documentation/blockdev/paride.txt.
pci=option[,option...] [PCI] various PCI subsystem options:
off [X86] don't probe for the PCI bus
@ -1687,7 +1702,7 @@ and is between 256 and 4096 characters. It is defined in the file
pcmv= [HW,PCMCIA] BadgePAD 4
pd. [PARIDE]
See Documentation/paride.txt.
See Documentation/blockdev/paride.txt.
pdcchassis= [PARISC,HW] Disable/Enable PDC Chassis Status codes at
boot time.
@ -1695,13 +1710,13 @@ and is between 256 and 4096 characters. It is defined in the file
See arch/parisc/kernel/pdc_chassis.c
pf. [PARIDE]
See Documentation/paride.txt.
See Documentation/blockdev/paride.txt.
pg. [PARIDE]
See Documentation/paride.txt.
See Documentation/blockdev/paride.txt.
pirq= [SMP,APIC] Manual mp-table setup
See Documentation/i386/IO-APIC.txt.
See Documentation/x86/i386/IO-APIC.txt.
plip= [PPT,NET] Parallel port network link
Format: { parport<nr> | timid | 0 }
@ -1711,6 +1726,10 @@ and is between 256 and 4096 characters. It is defined in the file
Override pmtimer IOPort with a hex value.
e.g. pmtmr=0x508
pnp.debug [PNP]
Enable PNP debug messages. This depends on the
CONFIG_PNP_DEBUG_MESSAGES option.
pnpacpi= [ACPI]
{ off }
@ -1764,7 +1783,7 @@ and is between 256 and 4096 characters. It is defined in the file
prompt_ramdisk= [RAM] List of RAM disks to prompt for floppy disk
before loading.
See Documentation/ramdisk.txt.
See Documentation/blockdev/ramdisk.txt.
psmouse.proto= [HW,MOUSE] Highest PS2 mouse protocol extension to
probe for; one of (bare|imps|exps|lifebook|any).
@ -1784,7 +1803,7 @@ and is between 256 and 4096 characters. It is defined in the file
<io>,<mss_io>,<mss_irq>,<mss_dma>,<mpu_io>,<mpu_irq>
pt. [PARIDE]
See Documentation/paride.txt.
See Documentation/blockdev/paride.txt.
pty.legacy_count=
[KNL] Number of legacy pty's. Overwrites compiled-in
@ -1798,10 +1817,10 @@ and is between 256 and 4096 characters. It is defined in the file
See Documentation/md.txt.
ramdisk_blocksize= [RAM]
See Documentation/ramdisk.txt.
See Documentation/blockdev/ramdisk.txt.
ramdisk_size= [RAM] Sizes of RAM disks in kilobytes
See Documentation/ramdisk.txt.
See Documentation/blockdev/ramdisk.txt.
rcupdate.blimit= [KNL,BOOT]
Set maximum number of finished RCU callbacks to process
@ -2133,7 +2152,7 @@ and is between 256 and 4096 characters. It is defined in the file
See Documentation/sonypi.txt
specialix= [HW,SERIAL] Specialix multi-serial port adapter
See Documentation/specialix.txt.
See Documentation/serial/specialix.txt.
spia_io_base= [HW,MTD]
spia_fio_base=
@ -2208,7 +2227,7 @@ and is between 256 and 4096 characters. It is defined in the file
thermal.crt= [HW,ACPI]
-1: disable all critical trip points in all thermal zones
<degrees C>: lower all critical trip points
<degrees C>: override all critical trip points
thermal.nocrt= [HW,ACPI]
Set to disable actions on ACPI thermal zone
@ -2312,7 +2331,7 @@ and is between 256 and 4096 characters. It is defined in the file
See Documentation/fb/modedb.txt.
vga= [BOOT,X86-32] Select a particular video mode
See Documentation/i386/boot.txt and
See Documentation/x86/i386/boot.txt and
Documentation/svga.txt.
Use vga=ask for menu.
This is actually a boot loader parameter; the value is

28
Documentation/laptops/acer-wmi.txt
View File

@ -1,7 +1,7 @@
Acer Laptop WMI Extras Driver
http://code.google.com/p/aceracpi
Version 0.1
9th February 2008
Version 0.2
18th August 2008
Copyright 2007-2008 Carlos Corbacho <carlos@strangeworlds.co.uk>
@ -87,17 +87,7 @@ acer-wmi come with built-in wireless. However, should you feel so inclined to
ever wish to remove the card, or swap it out at some point, please get in touch
with me, as we may well be able to gain some data on wireless card detection.
To read the status of the wireless radio (0=off, 1=on):
cat /sys/devices/platform/acer-wmi/wireless
To enable the wireless radio:
echo 1 > /sys/devices/platform/acer-wmi/wireless
To disable the wireless radio:
echo 0 > /sys/devices/platform/acer-wmi/wireless
To set the state of the wireless radio when loading acer-wmi, pass:
wireless=X (where X is 0 or 1)
The wireless radio is exposed through rfkill.
Bluetooth
*********
@ -117,17 +107,7 @@ For the adventurously minded - if you want to buy an internal bluetooth
module off the internet that is compatible with your laptop and fit it, then
it will work just fine with acer-wmi.
To read the status of the bluetooth module (0=off, 1=on):
cat /sys/devices/platform/acer-wmi/wireless
To enable the bluetooth module:
echo 1 > /sys/devices/platform/acer-wmi/bluetooth
To disable the bluetooth module:
echo 0 > /sys/devices/platform/acer-wmi/bluetooth
To set the state of the bluetooth module when loading acer-wmi, pass:
bluetooth=X (where X is 0 or 1)
Bluetooth is exposed through rfkill.
3G
**

2
Documentation/lguest/Makefile
View File

@ -1,5 +1,5 @@
# This creates the demonstration utility "lguest" which runs a Linux guest.
CFLAGS:=-Wall -Wmissing-declarations -Wmissing-prototypes -O3 -I../../include
CFLAGS:=-Wall -Wmissing-declarations -Wmissing-prototypes -O3 -I../../include -I../../arch/x86/include
LDLIBS:=-lz
all: lguest

4
Documentation/lguest/lguest.c
View File

@ -44,7 +44,7 @@
#include "linux/virtio_console.h"
#include "linux/virtio_rng.h"
#include "linux/virtio_ring.h"
#include "asm-x86/bootparam.h"
#include "asm/bootparam.h"
/*L:110 We can ignore the 39 include files we need for this program, but I do
* want to draw attention to the use of kernel-style types.
*
@ -402,7 +402,7 @@ static unsigned long load_bzimage(int fd)
void *p = from_guest_phys(0x100000);
/* Go back to the start of the file and read the header. It should be
* a Linux boot header (see Documentation/i386/boot.txt) */
* a Linux boot header (see Documentation/x86/i386/boot.txt) */
lseek(fd, 0, SEEK_SET);
read(fd, &boot, sizeof(boot));

2
Documentation/local_ops.txt
View File

@ -149,7 +149,7 @@ static void do_test_timer(unsigned long data)
int cpu;
/* Increment the counters */
on_each_cpu(test_each, NULL, 0, 1);
on_each_cpu(test_each, NULL, 1);
/* Read all the counters */
printk("Counters read from CPU %d\n", smp_processor_id());
for_each_online_cpu(cpu) {

1
Documentation/networking/.gitignore vendored Normal file
View File

@ -0,0 +1 @@
ifenslave

2
Documentation/networking/dmfe.txt
View File

@ -60,6 +60,6 @@ Tobias Ringstrom <tori@unhappy.mine.nu> : Current Maintainer
Contributors:
Marcelo Tosatti <marcelo@conectiva.com.br>
Alan Cox <alan@redhat.com>
Alan Cox <alan@lxorguk.ukuu.org.uk>
Jeff Garzik <jgarzik@pobox.com>
Vojtech Pavlik <vojtech@suse.cz>

2
Documentation/networking/phy.txt
View File

@ -96,7 +96,7 @@ Letting the PHY Abstraction Layer do Everything
static void adjust_link(struct net_device *dev);
Next, you need to know the device name of the PHY connected to this device.
The name will look something like, "phy0:0", where the first number is the
The name will look something like, "0:00", where the first number is the
bus id, and the second is the PHY's address on that bus. Typically,
the bus is responsible for making its ID unique.

1
Documentation/pcmcia/.gitignore vendored Normal file
View File

@ -0,0 +1 @@
crc32hash

67
Documentation/powerpc/booting-without-of.txt
View File

@ -41,25 +41,14 @@ Table of Contents
VI - System-on-a-chip devices and nodes
1) Defining child nodes of an SOC
2) Representing devices without a current OF specification
a) MDIO IO device
b) Gianfar-compatible ethernet nodes
c) PHY nodes
d) Interrupt controllers
e) I2C
f) Freescale SOC USB controllers
g) Freescale SOC SEC Security Engines
h) Board Control and Status (BCSR)
i) Freescale QUICC Engine module (QE)
j) CFI or JEDEC memory-mapped NOR flash
k) Global Utilities Block
l) Freescale Communications Processor Module
m) Chipselect/Local Bus
n) 4xx/Axon EMAC ethernet nodes
o) Xilinx IP cores
p) Freescale Synchronous Serial Interface
q) USB EHCI controllers
r) MDIO on GPIOs
s) SPI busses
a) PHY nodes
b) Interrupt controllers
c) CFI or JEDEC memory-mapped NOR flash
d) 4xx/Axon EMAC ethernet nodes
e) Xilinx IP cores
f) USB EHCI controllers
g) MDIO on GPIOs
h) SPI busses
VII - Marvell Discovery mv64[345]6x System Controller chips
1) The /system-controller node
@ -1830,41 +1819,7 @@ platforms are moved over to use the flattened-device-tree model.
big-endian;
};
r) Freescale Display Interface Unit
The Freescale DIU is a LCD controller, with proper hardware, it can also
drive DVI monitors.
Required properties:
- compatible : should be "fsl-diu".
- reg : should contain at least address and length of the DIU register
set.
- Interrupts : one DIU interrupt should be describe here.
Example (MPC8610HPCD)
display@2c000 {
compatible = "fsl,diu";
reg = <0x2c000 100>;
interrupts = <72 2>;
interrupt-parent = <&mpic>;
};
s) Freescale on board FPGA
This is the memory-mapped registers for on board FPGA.
Required properities:
- compatible : should be "fsl,fpga-pixis".
- reg : should contain the address and the lenght of the FPPGA register
set.
Example (MPC8610HPCD)
board-control@e8000000 {
compatible = "fsl,fpga-pixis";
reg = <0xe8000000 32>;
};
r) MDIO on GPIOs
g) MDIO on GPIOs
Currently defined compatibles:
- virtual,gpio-mdio
@ -1884,7 +1839,7 @@ platforms are moved over to use the flattened-device-tree model.
&qe_pio_c 6>;
};
s) SPI (Serial Peripheral Interface) busses
h) SPI (Serial Peripheral Interface) busses
SPI busses can be described with a node for the SPI master device
and a set of child nodes for each SPI slave on the bus. For this
@ -1917,6 +1872,8 @@ platforms are moved over to use the flattened-device-tree model.
inverse clock polarity (CPOL) mode
- spi-cpha - (optional) Empty property indicating device requires
shifted clock phase (CPHA) mode
- spi-cs-high - (optional) Empty property indicating device requires
chip select active high
SPI example for an MPC5200 SPI bus:
spi@f00 {

4
Documentation/powerpc/dts-bindings/fsl/board.txt
View File

@ -2,13 +2,13 @@
Required properties:
- device_type : Should be "board-control"
- compatible : Should be "fsl,<board>-bcsr"
- reg : Offset and length of the register set for the device
Example:
bcsr@f8000000 {
device_type = "board-control";
compatible = "fsl,mpc8360mds-bcsr";
reg = <f8000000 8000>;
};

35
Documentation/printk-formats.txt Normal file
View File

@ -0,0 +1,35 @@
If variable is of Type, use printk format specifier:
---------------------------------------------------------
int %d or %x
unsigned int %u or %x
long %ld or %lx
unsigned long %lu or %lx
long long %lld or %llx
unsigned long long %llu or %llx
size_t %zu or %zx
ssize_t %zd or %zx
Raw pointer value SHOULD be printed with %p.
u64 SHOULD be printed with %llu/%llx, (unsigned long long):
printk("%llu", (unsigned long long)u64_var);
s64 SHOULD be printed with %lld/%llx, (long long):
printk("%lld", (long long)s64_var);
If <type> is dependent on a config option for its size (e.g., sector_t,
blkcnt_t, phys_addr_t, resource_size_t) or is architecture-dependent
for its size (e.g., tcflag_t), use a format specifier of its largest
possible type and explicitly cast to it. Example:
printk("test: sector number/total blocks: %llu/%llu\n",
(unsigned long long)sector, (unsigned long long)blockcount);
Reminder: sizeof() result is of type size_t.
Thank you for your cooperation and attention.
By Randy Dunlap <rdunlap@xenotime.net>

2
Documentation/scheduler/00-INDEX
View File

@ -4,8 +4,6 @@ sched-arch.txt
- CPU Scheduler implementation hints for architecture specific code.
sched-coding.txt
- reference for various scheduler-related methods in the O(1) scheduler.
sched-design.txt
- goals, design and implementation of the Linux O(1) scheduler.
sched-design-CFS.txt
- goals, design and implementation of the Complete Fair Scheduler.
sched-domains.txt

2
Documentation/scheduler/sched-design-CFS.txt
View File

@ -92,7 +92,7 @@ other HZ detail. Thus the CFS scheduler has no notion of "timeslices" in the
way the previous scheduler had, and has no heuristics whatsoever. There is
only one central tunable (you have to switch on CONFIG_SCHED_DEBUG):
/proc/sys/kernel/sched_granularity_ns
/proc/sys/kernel/sched_min_granularity_ns
which can be used to tune the scheduler from "desktop" (i.e., low latencies) to
"server" (i.e., good batching) workloads. It defaults to a setting suitable

2
Documentation/scsi/aacraid.txt
View File

@ -128,7 +128,7 @@ Supported Cards/Chipsets
People
-------------------------
Alan Cox <alan@redhat.com>
Alan Cox <alan@lxorguk.ukuu.org.uk>
Christoph Hellwig <hch@infradead.org> (updates for new-style PCI probing and SCSI host registration,
small cleanups/fixes)
Matt Domsch <matt_domsch@dell.com> (revision ioctl, adapter messages)

24
Documentation/serial/00-INDEX Normal file
View File

@ -0,0 +1,24 @@
00-INDEX
- this file.
README.cycladesZ
- info on Cyclades-Z firmware loading.
computone.txt
- info on Computone Intelliport II/Plus Multiport Serial Driver.
digiepca.txt
- info on Digi Intl. {PC,PCI,EISA}Xx and Xem series cards.
hayes-esp.txt
- info on using the Hayes ESP serial driver.
moxa-smartio
- file with info on installing/using Moxa multiport serial driver.
riscom8.txt
- notes on using the RISCom/8 multi-port serial driver.
rocket.txt
- info on the Comtrol RocketPort multiport serial driver.
specialix.txt
- info on hardware/driver for specialix IO8+ multiport serial card.
stallion.txt
- info on using the Stallion multiport serial driver.
sx.txt
- info on the Specialix SX/SI multiport serial driver.
tty.txt
- guide to the locking policies of the tty layer.

0
Documentation/README.cycladesZ → Documentation/serial/README.cycladesZ
View File

2
Documentation/computone.txt → Documentation/serial/computone.txt
View File

@ -247,7 +247,7 @@ shar archive to make it easier to extract the script from the documentation.
To create the ip2mkdev shell script change to a convenient directory (/tmp
works just fine) and run the following command:
unshar Documentation/computone.txt
unshar Documentation/serial/computone.txt
(This file)
You should now have a file ip2mkdev in your current working directory with

0
Documentation/digiepca.txt → Documentation/serial/digiepca.txt
View File

0
Documentation/hayes-esp.txt → Documentation/serial/hayes-esp.txt
View File

0
Documentation/moxa-smartio → Documentation/serial/moxa-smartio
View File

0
Documentation/riscom8.txt → Documentation/serial/riscom8.txt
View File

0
Documentation/rocket.txt → Documentation/serial/rocket.txt
View File

0
Documentation/specialix.txt → Documentation/serial/specialix.txt
View File

0
Documentation/stallion.txt → Documentation/serial/stallion.txt
View File

0
Documentation/sx.txt → Documentation/serial/sx.txt
View File

0
Documentation/tty.txt → Documentation/serial/tty.txt
View File

4
Documentation/sh/new-machine.txt
View File

@ -47,9 +47,7 @@ Next, for companion chips:
`-- sh
`-- cchips
`-- hd6446x
|-- hd64461
| `-- cchip-specific files
`-- hd64465
`-- hd64461
`-- cchip-specific files
... and so on. Headers for the companion chips are treated the same way as

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

@ -1072,10 +1072,13 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
ref Reference board
dell-m4-1 Dell desktops
dell-m4-2 Dell desktops
dell-m4-3 Dell desktops
STAC92HD73*
ref Reference board
dell-m6 Dell desktops
dell-m6-amic Dell desktops/laptops with analog mics
dell-m6-dmic Dell desktops/laptops with digital mics
dell-m6 Dell desktops/laptops with both type of mics
STAC9872
vaio Setup for VAIO FE550G/SZ110

2
Documentation/spi/.gitignore vendored Normal file
View File

@ -0,0 +1,2 @@
spidev_fdx
spidev_test

2
Documentation/spi/spi-summary
View File

@ -215,7 +215,7 @@ So for example arch/.../mach-*/board-*.c files might have code like:
/* if your mach-* infrastructure doesn't support kernels that can
* run on multiple boards, pdata wouldn't benefit from "__init".
*/
static struct mysoc_spi_data __init pdata = { ... };
static struct mysoc_spi_data __initdata pdata = { ... };
static __init board_init(void)
{

1
Documentation/stable_kernel_rules.txt
View File

@ -12,6 +12,7 @@ Rules on what kind of patches are accepted, and which ones are not, into the
marked CONFIG_BROKEN), an oops, a hang, data corruption, a real
security issue, or some "oh, that's not good" issue. In short, something
critical.
- New device IDs and quirks are also accepted.
- No "theoretical race condition" issues, unless an explanation of how the
race can be exploited is also provided.
- It cannot contain any "trivial" fixes in it (spelling changes,

24
Documentation/sysctl/kernel.txt
View File

@ -363,11 +363,21 @@ tainted:
Non-zero if the kernel has been tainted. Numeric values, which
can be ORed together:
1 - A module with a non-GPL license has been loaded, this
includes modules with no license.
Set by modutils >= 2.4.9 and module-init-tools.
2 - A module was force loaded by insmod -f.
Set by modutils >= 2.4.9 and module-init-tools.
4 - Unsafe SMP processors: SMP with CPUs not designed for SMP.
64 - A module from drivers/staging was loaded.
1 - A module with a non-GPL license has been loaded, this
includes modules with no license.
Set by modutils >= 2.4.9 and module-init-tools.
2 - A module was force loaded by insmod -f.
Set by modutils >= 2.4.9 and module-init-tools.
4 - Unsafe SMP processors: SMP with CPUs not designed for SMP.
8 - A module was forcibly unloaded from the system by rmmod -f.
16 - A hardware machine check error occurred on the system.
32 - A bad page was discovered on the system.
64 - The user has asked that the system be marked "tainted". This
could be because they are running software that directly modifies
the hardware, or for other reasons.
128 - The system has died.
256 - The ACPI DSDT has been overridden with one supplied by the user
instead of using the one provided by the hardware.
512 - A kernel warning has occurred.
1024 - A module from drivers/staging was loaded.

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