Skip to content

Commit

Permalink
Merge branch 'rmobile/sdio' into rmobile-latest
Browse files Browse the repository at this point in the history
  • Loading branch information
pmundt committed Jul 25, 2011
2 parents b8e513a + c5ad48f commit b79b3e0
Show file tree
Hide file tree
Showing 3,634 changed files with 223,783 additions and 112,907 deletions.
The diff you're trying to view is too large. We only load the first 3000 changed files.
103 changes: 103 additions & 0 deletions Documentation/ABI/stable/firewire-cdev
@@ -0,0 +1,103 @@
What: /dev/fw[0-9]+
Date: May 2007
KernelVersion: 2.6.22
Contact: linux1394-devel@lists.sourceforge.net
Description:
The character device files /dev/fw* are the interface between
firewire-core and IEEE 1394 device drivers implemented in
userspace. The ioctl(2)- and read(2)-based ABI is defined and
documented in <linux/firewire-cdev.h>.

This ABI offers most of the features which firewire-core also
exposes to kernelspace IEEE 1394 drivers.

Each /dev/fw* is associated with one IEEE 1394 node, which can
be remote or local nodes. Operations on a /dev/fw* file have
different scope:
- The 1394 node which is associated with the file:
- Asynchronous request transmission
- Get the Configuration ROM
- Query node ID
- Query maximum speed of the path between this node
and local node
- The 1394 bus (i.e. "card") to which the node is attached to:
- Isochronous stream transmission and reception
- Asynchronous stream transmission and reception
- Asynchronous broadcast request transmission
- PHY packet transmission and reception
- Allocate, reallocate, deallocate isochronous
resources (channels, bandwidth) at the bus's IRM
- Query node IDs of local node, root node, IRM, bus
manager
- Query cycle time
- Bus reset initiation, bus reset event reception
- All 1394 buses:
- Allocation of IEEE 1212 address ranges on the local
link layers, reception of inbound requests to such
an address range, asynchronous response transmission
to inbound requests
- Addition of descriptors or directories to the local
nodes' Configuration ROM

Due to the different scope of operations and in order to let
userland implement different access permission models, some
operations are restricted to /dev/fw* files that are associated
with a local node:
- Addition of descriptors or directories to the local
nodes' Configuration ROM
- PHY packet transmission and reception

A /dev/fw* file remains associated with one particular node
during its entire life time. Bus topology changes, and hence
node ID changes, are tracked by firewire-core. ABI users do not
need to be aware of topology.

The following file operations are supported:

open(2)
Currently the only useful flags are O_RDWR.

ioctl(2)
Initiate various actions. Some take immediate effect, others
are performed asynchronously while or after the ioctl returns.
See the inline documentation in <linux/firewire-cdev.h> for
descriptions of all ioctls.

poll(2), select(2), epoll_wait(2) etc.
Watch for events to become available to be read.

read(2)
Receive various events. There are solicited events like
outbound asynchronous transaction completion or isochronous
buffer completion, and unsolicited events such as bus resets,
request reception, or PHY packet reception. Always use a read
buffer which is large enough to receive the largest event that
could ever arrive. See <linux/firewire-cdev.h> for descriptions
of all event types and for which ioctls affect reception of
events.

mmap(2)
Allocate a DMA buffer for isochronous reception or transmission
and map it into the process address space. The arguments should
be used as follows: addr = NULL, length = the desired buffer
size, i.e. number of packets times size of largest packet,
prot = at least PROT_READ for reception and at least PROT_WRITE
for transmission, flags = MAP_SHARED, fd = the handle to the
/dev/fw*, offset = 0.

Isochronous reception works in packet-per-buffer fashion except
for multichannel reception which works in buffer-fill mode.

munmap(2)
Unmap the isochronous I/O buffer from the process address space.

close(2)
Besides stopping and freeing I/O contexts that were associated
with the file descriptor, back out any changes to the local
nodes' Configuration ROM. Deallocate isochronous channels and
bandwidth at the IRM that were marked for kernel-assisted
re- and deallocation.

Users: libraw1394
libdc1394
tools like jujuutils, fwhack, ...
122 changes: 122 additions & 0 deletions Documentation/ABI/stable/sysfs-bus-firewire
@@ -0,0 +1,122 @@
What: /sys/bus/firewire/devices/fw[0-9]+/
Date: May 2007
KernelVersion: 2.6.22
Contact: linux1394-devel@lists.sourceforge.net
Description:
IEEE 1394 node device attributes.
Read-only. Mutable during the node device's lifetime.
See IEEE 1212 for semantic definitions.

config_rom
Contents of the Configuration ROM register.
Binary attribute; an array of host-endian u32.

guid
The node's EUI-64 in the bus information block of
Configuration ROM.
Hexadecimal string representation of an u64.


What: /sys/bus/firewire/devices/fw[0-9]+/units
Date: June 2009
KernelVersion: 2.6.31
Contact: linux1394-devel@lists.sourceforge.net
Description:
IEEE 1394 node device attribute.
Read-only. Mutable during the node device's lifetime.
See IEEE 1212 for semantic definitions.

units
Summary of all units present in an IEEE 1394 node.
Contains space-separated tuples of specifier_id and
version of each unit present in the node. Specifier_id
and version are hexadecimal string representations of
u24 of the respective unit directory entries.
Specifier_id and version within each tuple are separated
by a colon.

Users: udev rules to set ownership and access permissions or ACLs of
/dev/fw[0-9]+ character device files


What: /sys/bus/firewire/devices/fw[0-9]+[.][0-9]+/
Date: May 2007
KernelVersion: 2.6.22
Contact: linux1394-devel@lists.sourceforge.net
Description:
IEEE 1394 unit device attributes.
Read-only. Immutable during the unit device's lifetime.
See IEEE 1212 for semantic definitions.

modalias
Same as MODALIAS in the uevent at device creation.

rom_index
Offset of the unit directory within the parent device's
(node device's) Configuration ROM, in quadlets.
Decimal string representation.


What: /sys/bus/firewire/devices/*/
Date: May 2007
KernelVersion: 2.6.22
Contact: linux1394-devel@lists.sourceforge.net
Description:
Attributes common to IEEE 1394 node devices and unit devices.
Read-only. Mutable during the node device's lifetime.
Immutable during the unit device's lifetime.
See IEEE 1212 for semantic definitions.

These attributes are only created if the root directory of an
IEEE 1394 node or the unit directory of an IEEE 1394 unit
actually contains according entries.

hardware_version
Hexadecimal string representation of an u24.

hardware_version_name
Contents of a respective textual descriptor leaf.

model
Hexadecimal string representation of an u24.

model_name
Contents of a respective textual descriptor leaf.

specifier_id
Hexadecimal string representation of an u24.
Mandatory in unit directories according to IEEE 1212.

vendor
Hexadecimal string representation of an u24.
Mandatory in the root directory according to IEEE 1212.

vendor_name
Contents of a respective textual descriptor leaf.

version
Hexadecimal string representation of an u24.
Mandatory in unit directories according to IEEE 1212.


What: /sys/bus/firewire/drivers/sbp2/fw*/host*/target*/*:*:*:*/ieee1394_id
formerly
/sys/bus/ieee1394/drivers/sbp2/fw*/host*/target*/*:*:*:*/ieee1394_id
Date: Feb 2004
KernelVersion: 2.6.4
Contact: linux1394-devel@lists.sourceforge.net
Description:
SCSI target port identifier and logical unit identifier of a
logical unit of an SBP-2 target. The identifiers are specified
in SAM-2...SAM-4 annex A. They are persistent and world-wide
unique properties the SBP-2 attached target.

Read-only attribute, immutable during the target's lifetime.
Format, as exposed by firewire-sbp2 since 2.6.22, May 2007:
Colon-separated hexadecimal string representations of
u64 EUI-64 : u24 directory_ID : u16 LUN
without 0x prefixes, without whitespace. The former sbp2 driver
(removed in 2.6.37 after being superseded by firewire-sbp2) used
a somewhat shorter format which was not as close to SAM.

Users: udev rules to create /dev/disk/by-id/ symlinks
27 changes: 27 additions & 0 deletions Documentation/ABI/stable/vdso
@@ -0,0 +1,27 @@
On some architectures, when the kernel loads any userspace program it
maps an ELF DSO into that program's address space. This DSO is called
the vDSO and it often contains useful and highly-optimized alternatives
to real syscalls.

These functions are called just like ordinary C function according to
your platform's ABI. Call them from a sensible context. (For example,
if you set CS on x86 to something strange, the vDSO functions are
within their rights to crash.) In addition, if you pass a bad
pointer to a vDSO function, you might get SIGSEGV instead of -EFAULT.

To find the DSO, parse the auxiliary vector passed to the program's
entry point. The AT_SYSINFO_EHDR entry will point to the vDSO.

The vDSO uses symbol versioning; whenever you request a symbol from the
vDSO, specify the version you are expecting.

Programs that dynamically link to glibc will use the vDSO automatically.
Otherwise, you can use the reference parser in Documentation/vDSO/parse_vdso.c.

Unless otherwise noted, the set of symbols with any given version and the
ABI of those symbols is considered stable. It may vary across architectures,
though.

(As of this writing, this ABI documentation as been confirmed for x86_64.
The maintainers of the other vDSO-using architectures should confirm
that it is correct for their architecture.)
8 changes: 8 additions & 0 deletions Documentation/ABI/testing/sysfs-driver-hid-roccat-koneplus
Expand Up @@ -92,6 +92,14 @@ Description: The mouse has a tracking- and a distance-control-unit. These
This file is writeonly.
Users: http://roccat.sourceforge.net

What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/talk
Date: May 2011
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: Used to active some easy* functions of the mouse from outside.
The data has to be 16 bytes long.
This file is writeonly.
Users: http://roccat.sourceforge.net

What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/tcu
Date: October 2010
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Expand Down
10 changes: 10 additions & 0 deletions Documentation/ABI/testing/sysfs-driver-hid-wiimote
@@ -0,0 +1,10 @@
What: /sys/bus/hid/drivers/wiimote/<dev>/led1
What: /sys/bus/hid/drivers/wiimote/<dev>/led2
What: /sys/bus/hid/drivers/wiimote/<dev>/led3
What: /sys/bus/hid/drivers/wiimote/<dev>/led4
Date: July 2011
KernelVersion: 3.1
Contact: David Herrmann <dh.herrmann@googlemail.com>
Description: Make it possible to set/get current led state. Reading from it
returns 0 if led is off and 1 if it is on. Writing 0 to it
disables the led, writing 1 enables it.
43 changes: 18 additions & 25 deletions Documentation/Changes
Expand Up @@ -2,13 +2,7 @@ Intro
=====

This document is designed to provide a list of the minimum levels of
software necessary to run the 2.6 kernels, as well as provide brief
instructions regarding any other "Gotchas" users may encounter when
trying life on the Bleeding Edge. If upgrading from a pre-2.4.x
kernel, please consult the Changes file included with 2.4.x kernels for
additional information; most of that information will not be repeated
here. Basically, this document assumes that your system is already
functional and running at least 2.4.x kernels.
software necessary to run the 3.0 kernels.

This document is originally based on my "Changes" file for 2.0.x kernels
and therefore owes credit to the same people as that file (Jared Mauch,
Expand All @@ -22,11 +16,10 @@ Upgrade to at *least* these software revisions before thinking you've
encountered a bug! If you're unsure what version you're currently
running, the suggested command should tell you.

Again, keep in mind that this list assumes you are already
functionally running a Linux 2.4 kernel. Also, not all tools are
necessary on all systems; obviously, if you don't have any ISDN
hardware, for example, you probably needn't concern yourself with
isdn4k-utils.
Again, keep in mind that this list assumes you are already functionally
running a Linux kernel. Also, not all tools are necessary on all
systems; obviously, if you don't have any ISDN hardware, for example,
you probably needn't concern yourself with isdn4k-utils.

o Gnu C 3.2 # gcc --version
o Gnu make 3.80 # make --version
Expand Down Expand Up @@ -114,12 +107,12 @@ Ksymoops

If the unthinkable happens and your kernel oopses, you may need the
ksymoops tool to decode it, but in most cases you don't.
In the 2.6 kernel it is generally preferred to build the kernel with
CONFIG_KALLSYMS so that it produces readable dumps that can be used as-is
(this also produces better output than ksymoops).
If for some reason your kernel is not build with CONFIG_KALLSYMS and
you have no way to rebuild and reproduce the Oops with that option, then
you can still decode that Oops with ksymoops.
It is generally preferred to build the kernel with CONFIG_KALLSYMS so
that it produces readable dumps that can be used as-is (this also
produces better output than ksymoops). If for some reason your kernel
is not build with CONFIG_KALLSYMS and you have no way to rebuild and
reproduce the Oops with that option, then you can still decode that Oops
with ksymoops.

Module-Init-Tools
-----------------
Expand Down Expand Up @@ -261,8 +254,8 @@ needs to be recompiled or (preferably) upgraded.
NFS-utils
---------

In 2.4 and earlier kernels, the nfs server needed to know about any
client that expected to be able to access files via NFS. This
In ancient (2.4 and earlier) kernels, the nfs server needed to know
about any client that expected to be able to access files via NFS. This
information would be given to the kernel by "mountd" when the client
mounted the filesystem, or by "exportfs" at system startup. exportfs
would take information about active clients from /var/lib/nfs/rmtab.
Expand All @@ -272,11 +265,11 @@ which is not always easy, particularly when trying to implement
fail-over. Even when the system is working well, rmtab suffers from
getting lots of old entries that never get removed.

With 2.6 we have the option of having the kernel tell mountd when it
gets a request from an unknown host, and mountd can give appropriate
export information to the kernel. This removes the dependency on
rmtab and means that the kernel only needs to know about currently
active clients.
With modern kernels we have the option of having the kernel tell mountd
when it gets a request from an unknown host, and mountd can give
appropriate export information to the kernel. This removes the
dependency on rmtab and means that the kernel only needs to know about
currently active clients.

To enable this new functionality, you need to:

Expand Down
5 changes: 3 additions & 2 deletions Documentation/DocBook/80211.tmpl
Expand Up @@ -402,8 +402,9 @@
!Finclude/net/mac80211.h set_key_cmd
!Finclude/net/mac80211.h ieee80211_key_conf
!Finclude/net/mac80211.h ieee80211_key_flags
!Finclude/net/mac80211.h ieee80211_tkip_key_type
!Finclude/net/mac80211.h ieee80211_get_tkip_key
!Finclude/net/mac80211.h ieee80211_get_tkip_p1k
!Finclude/net/mac80211.h ieee80211_get_tkip_p1k_iv
!Finclude/net/mac80211.h ieee80211_get_tkip_p2k
!Finclude/net/mac80211.h ieee80211_key_removed
</chapter>

Expand Down
2 changes: 1 addition & 1 deletion Documentation/DocBook/kernel-hacking.tmpl
Expand Up @@ -409,7 +409,7 @@ cond_resched(); /* Will sleep */

<para>
You should always compile your kernel
<symbol>CONFIG_DEBUG_SPINLOCK_SLEEP</symbol> on, and it will warn
<symbol>CONFIG_DEBUG_ATOMIC_SLEEP</symbol> on, and it will warn
you if you break these rules. If you <emphasis>do</emphasis> break
the rules, you will eventually lock up your box.
</para>
Expand Down

0 comments on commit b79b3e0

Please sign in to comment.