Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net

</para>

</para>

<itemizedlist>

<itemizedlist>

<listitem><para>

<varname>const char *name</varname>: Optional. Set this to help identify

the memory region, it will show up in the corresponding sysfs node.

</para></listitem>

<listitem><para>

<listitem><para>

<varname>int memtype</varname>: Required if the mapping is used. Set this to

<varname>int memtype</varname>: Required if the mapping is used. Set this to

<varname>UIO_MEM_PHYS</varname> if you you have physical memory on your

<varname>UIO_MEM_PHYS</varname> if you you have physical memory on your

</itemizedlist>

</itemizedlist>

<para>

<para>

Please do not touch the <varname>kobj</varname> element of

Please do not touch the <varname>map</varname> element of

<varname>struct uio_mem</varname>! It is used by the UIO framework

<varname>struct uio_mem</varname>! It is used by the UIO framework

to set up sysfs files for this mapping. Simply leave it alone.

to set up sysfs files for this mapping. Simply leave it alone.

</para>

</para>

ramtron	Ramtron International

ramtron	Ramtron International

samsung	Samsung Semiconductor

samsung	Samsung Semiconductor

schindler	Schindler

schindler	Schindler

sil	Silicon Image

simtek

simtek

sirf	SiRF Technology, Inc.

sirf	SiRF Technology, Inc.

stericsson	ST-Ericsson

stericsson	ST-Ericsson

Userspace tools for creating and manipulating Btrfs file systems are

Userspace tools for creating and manipulating Btrfs file systems are

available from the git repository at the following location:

available from the git repository at the following location:

 http://git.kernel.org/?p=linux/kernel/git/mason/btrfs-progs-unstable.git

 http://git.kernel.org/?p=linux/kernel/git/mason/btrfs-progs.git

 git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs-unstable.git

 git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git

These include the following tools:

These include the following tools:

The I2C protocol knows about two kinds of device addresses: normal 7 bit

The I2C protocol knows about two kinds of device addresses: normal 7 bit

addresses, and an extended set of 10 bit addresses. The sets of addresses

addresses, and an extended set of 10 bit addresses. The sets of addresses

do not intersect: the 7 bit address 0x10 is not the same as the 10 bit

do not intersect: the 7 bit address 0x10 is not the same as the 10 bit

address 0x10 (though a single device could respond to both of them). You

address 0x10 (though a single device could respond to both of them).

select a 10 bit address by adding an extra byte after the address

byte:

  S Addr7 Rd/Wr ....

becomes

  S 11110 Addr10 Rd/Wr

S is the start bit, Rd/Wr the read/write bit, and if you count the number

of bits, you will see the there are 8 after the S bit for 7 bit addresses,

and 16 after the S bit for 10 bit addresses.

WARNING! The current 10 bit address support is EXPERIMENTAL. There are

I2C messages to and from 10-bit address devices have a different format.

several places in the code that will cause SEVERE PROBLEMS with 10 bit

See the I2C specification for the details.

addresses, even though there is some basic handling and hooks. Also,

almost no supported adapter handles the 10 bit addresses correctly.

As soon as a real 10 bit address device is spotted 'in the wild', we

The current 10 bit address support is minimal. It should work, however

can and will add proper support. Right now, 10 bit address devices

you can expect some problems along the way:

are defined by the I2C protocol, but we have never seen a single device

* Not all bus drivers support 10-bit addresses. Some don't because the

which supports them.

  hardware doesn't support them (SMBus doesn't require 10-bit address

  support for example), some don't because nobody bothered adding the

  code (or it's there but not working properly.) Software implementation

  (i2c-algo-bit) is known to work.

* Some optional features do not support 10-bit addresses. This is the

  case of automatic detection and instantiation of devices by their,

  drivers, for example.

* Many user-space packages (for example i2c-tools) lack support for

  10-bit addresses.

Note that 10-bit address devices are still pretty rare, so the limitations

listed above could stay for a long time, maybe even forever if nobody

needs them to be fixed.

Subsystem-Level Methods

Subsystem-Level Methods

-----------------------

-----------------------

The core methods to suspend and resume devices reside in struct dev_pm_ops

The core methods to suspend and resume devices reside in struct dev_pm_ops

pointed to by the pm member of struct bus_type, struct device_type and

pointed to by the ops member of struct dev_pm_domain, or by the pm member of

struct class.  They are mostly of interest to the people writing infrastructure

struct bus_type, struct device_type and struct class.  They are mostly of

for buses, like PCI or USB, or device type and device class drivers.

interest to the people writing infrastructure for platforms and buses, like PCI

or USB, or device type and device class drivers.

Bus drivers implement these methods as appropriate for the hardware and the

Bus drivers implement these methods as appropriate for the hardware and the

drivers using it; PCI works differently from USB, and so on.  Not many people

drivers using it; PCI works differently from USB, and so on.  Not many people

/sys/devices/.../power/wakeup files

/sys/devices/.../power/wakeup files

-----------------------------------

-----------------------------------

All devices in the driver model have two flags to control handling of wakeup

All device objects in the driver model contain fields that control the handling

events (hardware signals that can force the device and/or system out of a low

of system wakeup events (hardware signals that can force the system out of a

power state).  These flags are initialized by bus or device driver code using

sleep state).  These fields are initialized by bus or device driver code using

device_set_wakeup_capable() and device_set_wakeup_enable(), defined in

device_set_wakeup_capable() and device_set_wakeup_enable(), defined in

include/linux/pm_wakeup.h.

include/linux/pm_wakeup.h.

The "can_wakeup" flag just records whether the device (and its driver) can

The "power.can_wakeup" flag just records whether the device (and its driver) can

physically support wakeup events.  The device_set_wakeup_capable() routine

physically support wakeup events.  The device_set_wakeup_capable() routine

affects this flag.  The "should_wakeup" flag controls whether the device should

affects this flag.  The "power.wakeup" field is a pointer to an object of type

try to use its wakeup mechanism.  device_set_wakeup_enable() affects this flag;

struct wakeup_source used for controlling whether or not the device should use

for the most part drivers should not change its value.  The initial value of

its system wakeup mechanism and for notifying the PM core of system wakeup

should_wakeup is supposed to be false for the majority of devices; the major

events signaled by the device.  This object is only present for wakeup-capable

exceptions are power buttons, keyboards, and Ethernet adapters whose WoL

devices (i.e. devices whose "can_wakeup" flags are set) and is created (or

(wake-on-LAN) feature has been set up with ethtool.  It should also default

removed) by device_set_wakeup_capable().

to true for devices that don't generate wakeup requests on their own but merely

forward wakeup requests from one bus to another (like PCI bridges).

Whether or not a device is capable of issuing wakeup events is a hardware

Whether or not a device is capable of issuing wakeup events is a hardware

matter, and the kernel is responsible for keeping track of it.  By contrast,

matter, and the kernel is responsible for keeping track of it.  By contrast,

whether or not a wakeup-capable device should issue wakeup events is a policy

whether or not a wakeup-capable device should issue wakeup events is a policy

decision, and it is managed by user space through a sysfs attribute: the

decision, and it is managed by user space through a sysfs attribute: the

power/wakeup file.  User space can write the strings "enabled" or "disabled" to

"power/wakeup" file.  User space can write the strings "enabled" or "disabled"

set or clear the "should_wakeup" flag, respectively.  This file is only present

to it to indicate whether or not, respectively, the device is supposed to signal

for wakeup-capable devices (i.e. devices whose "can_wakeup" flags are set)

system wakeup.  This file is only present if the "power.wakeup" object exists

and is created (or removed) by device_set_wakeup_capable().  Reads from the

for the given device and is created (or removed) along with that object, by

file will return the corresponding string.

device_set_wakeup_capable().  Reads from the file will return the corresponding

string.

The device_may_wakeup() routine returns true only if both flags are set.

The "power/wakeup" file is supposed to contain the "disabled" string initially

for the majority of devices; the major exceptions are power buttons, keyboards,

and Ethernet adapters whose WoL (wake-on-LAN) feature has been set up with

ethtool.  It should also default to "enabled" for devices that don't generate

wakeup requests on their own but merely forward wakeup requests from one bus to

another (like PCI Express ports).

The device_may_wakeup() routine returns true only if the "power.wakeup" object

exists and the corresponding "power/wakeup" file contains the string "enabled".

This information is used by subsystems, like the PCI bus type code, to see

This information is used by subsystems, like the PCI bus type code, to see

whether or not to enable the devices' wakeup mechanisms.  If device wakeup

whether or not to enable the devices' wakeup mechanisms.  If device wakeup

mechanisms are enabled or disabled directly by drivers, they also should use

mechanisms are enabled or disabled directly by drivers, they also should use

device_may_wakeup() to decide what to do during a system sleep transition.

device_may_wakeup() to decide what to do during a system sleep transition.

However for runtime power management, wakeup events should be enabled whenever

Device drivers, however, are not supposed to call device_set_wakeup_enable()

the device and driver both support them, regardless of the should_wakeup flag.

directly in any case.

It ought to be noted that system wakeup is conceptually different from "remote

wakeup" used by runtime power management, although it may be supported by the

same physical mechanism.  Remote wakeup is a feature allowing devices in

low-power states to trigger specific interrupts to signal conditions in which

they should be put into the full-power state.  Those interrupts may or may not

be used to signal system wakeup events, depending on the hardware design.  On

some systems it is impossible to trigger them from system sleep states.  In any

case, remote wakeup should always be enabled for runtime power management for

all devices and drivers that support it.

/sys/devices/.../power/control files

/sys/devices/.../power/control files

------------------------------------

------------------------------------

support all these callbacks and not all drivers use all the callbacks.  The

support all these callbacks and not all drivers use all the callbacks.  The

various phases always run after tasks have been frozen and before they are

various phases always run after tasks have been frozen and before they are

unfrozen.  Furthermore, the *_noirq phases run at a time when IRQ handlers have

unfrozen.  Furthermore, the *_noirq phases run at a time when IRQ handlers have

been disabled (except for those marked with the IRQ_WAKEUP flag).

been disabled (except for those marked with the IRQF_NO_SUSPEND flag).

All phases use bus, type, or class callbacks (that is, methods defined in

All phases use PM domain, bus, type, or class callbacks (that is, methods

dev->bus->pm, dev->type->pm, or dev->class->pm).  These callbacks are mutually

defined in dev->pm_domain->ops, dev->bus->pm, dev->type->pm, or dev->class->pm).

exclusive, so if the device type provides a struct dev_pm_ops object pointed to

These callbacks are regarded by the PM core as mutually exclusive.  Moreover,

by its pm field (i.e. both dev->type and dev->type->pm are defined), the

PM domain callbacks always take precedence over bus, type and class callbacks,

callbacks included in that object (i.e. dev->type->pm) will be used.  Otherwise,

while type callbacks take precedence over bus and class callbacks, and class

if the class provides a struct dev_pm_ops object pointed to by its pm field

callbacks take precedence over bus callbacks.  To be precise, the following

(i.e. both dev->class and dev->class->pm are defined), the PM core will use the

rules are used to determine which callback to execute in the given phase:

callbacks from that object (i.e. dev->class->pm).  Finally, if the pm fields of

both the device type and class objects are NULL (or those objects do not exist),

    1.	If dev->pm_domain is present, the PM core will attempt to execute the

the callbacks provided by the bus (that is, the callbacks from dev->bus->pm)

	callback included in dev->pm_domain->ops.  If that callback is not

will be used (this allows device types to override callbacks provided by bus

	present, no action will be carried out for the given device.

types or classes if necessary).

    2.	Otherwise, if both dev->type and dev->type->pm are present, the callback

	included in dev->type->pm will be executed.

    3.	Otherwise, if both dev->class and dev->class->pm are present, the

	callback included in dev->class->pm will be executed.

    4.	Otherwise, if both dev->bus and dev->bus->pm are present, the callback

	included in dev->bus->pm will be executed.

This allows PM domains and device types to override callbacks provided by bus

types or device classes if necessary.

These callbacks may in turn invoke device- or driver-specific methods stored in

These callbacks may in turn invoke device- or driver-specific methods stored in

dev->driver->pm, but they don't have to.

dev->driver->pm, but they don't have to.

	After the prepare callback method returns, no new children may be

	After the prepare callback method returns, no new children may be

	registered below the device.  The method may also prepare the device or

	registered below the device.  The method may also prepare the device or

	driver in some way for the upcoming system power transition (for

	driver in some way for the upcoming system power transition, but it

	example, by allocating additional memory required for this purpose), but

	should not put the device into a low-power state.

	it should not put the device into a low-power state.

    2.	The suspend methods should quiesce the device to stop it from performing

    2.	The suspend methods should quiesce the device to stop it from performing

	I/O.  They also may save the device registers and put it into the

	I/O.  They also may save the device registers and put it into the