For more clearance what the functions actually do,
usb_buffer_alloc() is renamed to usb_alloc_coherent()
usb_buffer_free() is renamed to usb_free_coherent()
They should only be used in code which really needs DMA coherency.
[added compatibility macros so we can convert things easier - gregkh]
Signed-off-by: Daniel Mack <daniel@caiaq.de>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Pedro Ribeiro <pedrib@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
USB: Move hcd free_dev call into usb_disconnect
I found a way to oops the kernel:
1. Open a USB device through devio.
2. Remove the hcd module in the host kernel.
3. Close the devio file descriptor.
The problem is that closing the file descriptor does usb_release_dev
as it is the last reference. usb_release_dev then tries to invoke
the hcd free_dev function (or rather dereferencing the hcd driver
struct). This causes an oops as the hcd driver has already been
unloaded so the struct is gone.
This patch tries to fix this by bringing the free_dev call earlier
and into usb_disconnect. I have verified that repeating the
above steps no longer crashes with this patch applied.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as1329) converts the USB stack over to the PM core's
runtime PM framework. This involves numerous changes throughout
usbcore, especially to hub.c and driver.c. Perhaps the most notable
change is that CONFIG_USB_SUSPEND now depends on CONFIG_PM_RUNTIME
instead of CONFIG_PM.
Several fields in the usb_device and usb_interface structures are no
longer needed. Some code which used to depend on CONFIG_USB_PM now
depends on CONFIG_USB_SUSPEND (requiring some rearrangement of header
files).
The only visible change in behavior should be that following a system
sleep (resume from RAM or resume from hibernation), autosuspended USB
devices will be resumed just like everything else. They won't remain
suspended. But if they aren't in use then they will naturally
autosuspend again in a few seconds.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Fix new kernel-doc warnings in usb core:
Warning(drivers/usb/core/usb.c:79): No description found for parameter 'config'
Warning(drivers/usb/core/usb.c:79): No description found for parameter 'iface_num'
Warning(drivers/usb/core/usb.c:79): No description found for parameter 'alt_num'
Warning(drivers/usb/core/hcd.c:1622): No description found for parameter 'udev'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
USB drivers that create character devices call usb_register_dev in their
probe function. This associates the usb_interface device with that minor
number and creates the character device and announces it to the world.
However, the driver's probe function is called before the new
usb_interface is added to the driver's klist_devices.
This is a problem because userspace will respond to the character device
creation announcement by opening the character device. The driver's open
function will the call usb_find_interface to find the usb_interface
associated with that minor number. usb_find_interface will walk the
driver's list of devices and find the usb_interface with the matching
minor number.
Because the announcement happens before the usb_interface is added to the
driver's klist_devices, a race condition exists. A straightforward fix
is to walk the list of devices on usb_bus_type instead since the device
is added to that list before the announcement occurs.
bus_find_device calls get_device to bump the reference count on the found
device. It is arguable that the reference count should be dropped by the
caller of usb_find_interface instead of usb_find_interface, however,
the current users of usb_find_interface do not expect this.
The original version of this patch only matched against minor number
instead of driver and minor number. This version matches against both.
Signed-off-by: Russ Dill <Russ.Dill@gmail.com>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This reverts commit a2582bd478.
It turned out to be buggy and broke USB printers from working.
Cc: Russ Dill <Russ.Dill@gmail.com>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Fix the following sparse warning:
drivers/usb/core/usb.c:1033:15: warning: symbol 'usb_debug_devices' was not declared. Should it be static?
Signed-off-by: Felipe Balbi <felipe.balbi@nokia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Refactor out the code to find alternate interface settings into
usb_find_alt_setting(). Print a debugging message and return null if the
alt setting is not found.
While we're at it, correct a bug in the refactored code. The interfaces
in the configuration's interface cache are not necessarily in numerical
order, so we can't just use the interface number as an array index. Loop
through the interface caches, looking for the correct interface.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
USB drivers that create character devices call usb_register_dev in their
probe function. This associates the usb_interface device with that minor
number and creates the character device and announces it to the world.
However, the driver's probe function is called before the new
usb_interface is added to the driver's klist_devices.
This is a problem because userspace will respond to the character device
creation announcement by opening the character device. The driver's open
function will the call usb_find_interface to find the usb_interface
associated with that minor number. usb_find_interface will walk the
driver's list of devices and find the usb_interface with the matching
minor number.
Because the announcement happens before the usb_interface is added to the
driver's klist_devices, a race condition exists. A straightforward fix
is to walk the list of devices on usb_bus_type instead since the device
is added to that list before the announcement occurs.
bus_find_device calls get_device to bump the reference count on the found
device. It is arguable that the reference count should be dropped by the
caller of usb_find_interface instead of usb_find_interface, however,
the current users of usb_find_interface do not expect this.
Signed-off-by: Russ Dill <Russ.Dill@gmail.com>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The xHCI driver needs to set the route string in the slot context of all
devices, not just SuperSpeed devices. The route string concept was added
in the USB 3.0 specification, section 10.1.3.2. Each hub in the topology
is expected to have no more than 15 ports in order for the route string of
a device to be unique. SuperSpeed hubs are restricted to only having 15
ports, but FS/LS/HS hubs are not. The xHCI specification says that if the
port number the device is under is greater than 15, that portion of the
route string shall be set to 15.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
usb_buffer_map_sg should return negative on error according to
its documentation. But dma_map_sg returns 0 on error. Take this
into account and return -ENOMEM in such situation.
While at it, return -EINVAL instead of -1 when wrong input is
passed in.
If this wasn't done, usb_sg_* operations used after usb_sg_init
which returned 0 may cause oopses/deadlocks since we don't init
structures/entries, esp. completion and status entry.
Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This allows subsytems to provide devtmpfs with non-default permissions
for the device node. Instead of the default mode of 0600, null, zero,
random, urandom, full, tty, ptmx now have a mode of 0666, which allows
non-privileged processes to access standard device nodes in case no
other userspace process applies the expected permissions.
This also fixes a wrong assignment in pktcdvd and a checkpatch.pl complain.
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Add host controller driver API and a slot_id variable to struct
usb_device. This allows the xHCI host controller driver to ask the
hardware to allocate a slot for the device when a struct usb_device is
allocated. The slot needs to be allocated at that point because the
hardware can run out of internal resources, and we want to know that very
early in the device connection process. Don't call this new API for root
hubs, since they aren't real devices.
Add HCD API to let the host controller choose the device address. This is
especially important for xHCI hardware running in a virtualized
environment. The guests running under the VM don't need to know which
addresses on the bus are taken, because the hardware picks the address for
them. Announce SuperSpeed USB devices after the address has been assigned
by the hardware.
Don't use the new get descriptor/set address scheme with xHCI. Unless
special handling is done in the host controller driver, the xHC can't
issue control transfers before you set the device address. Support for
the older addressing scheme will be added when the xHCI driver supports
the Block Set Address Request (BSR) flag in the Address Device command.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch adds a hex route string to each USB device. The route string is used
by the USB 3.0 host controller to send packets through the device tree. USB 3.0
hubs use this string to route packets to the correct port. This is fundamental
bus change from USB 2.0, where all packets were broadcast across the bus.
Devices (including hubs) under a root port receive the route string 0x0. Every
four bits in the route string represent a port on a hub. This length works
because USB 3.0 hubs are limited to 15 ports, and USB 2.0 hubs (with potentially
more ports) will never see packets with a route string. A port number of 0
means the packet is destined for that hub.
For example, a peripheral device might have a route string of 0x00097.
This means the device is connected to port 9 of the hub at depth 1.
The hub at depth 1 is connected to port 7 of a hub at depth 0.
The hub at depth 0 is connected to a root port.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This replaces dma_sync_single() and dma_sync_sg() with
dma_sync_single_for_cpu() and dma_sync_sg_for_cpu() respectively
because they is an obsolete API; include/linux/dma-mapping.h says:
/* Backwards compat, remove in 2.7.x */
#define dma_sync_single dma_sync_single_for_cpu
#define dma_sync_sg dma_sync_sg_for_cpu
Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The endpoint devices look like simple attribute groups now, and no longer
like devices with a specific subsystem. They will also no longer emit uevents.
It also removes the device node requests for endpoint devices, which are not
implemented for now.
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The usb_host class isn't used for anything anymore (it was used for
debug files, but they have moved to debugfs a few kernel releases ago),
so let's delete it before someone accidentally puts a file in it.
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
People are very used to the devices file in usbfs. Now that we have
moved usbfs to be an "embedded" option only, the developers miss the
file, they had grown quite attached to it over all of these years. This
patch brings it back and puts it in the usb debugfs directory, so that
the developers don't feel sad anymore.
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This adds support for USB drivers to report their requested nodename to
userspace. It also updates a number of USB drivers to provide the
needed subdirectory and device name to be used for them.
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Jan Blunck <jblunck@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Wireless USB endpoint state has a sequence number and a current
window and not just a single toggle bit. So allow HCDs to provide a
endpoint_reset method and call this or clear the software toggles as
required (after a clear halt, set configuration etc.).
usb_settoggle() and friends are then HCD internal and are moved into
core/hcd.h and all device drivers call usb_reset_endpoint() instead.
If the device endpoint state has been reset (with a clear halt) but
the host endpoint state has not then subsequent data transfers will
not complete. The device will only work again after it is reset or
disconnected.
Signed-off-by: David Vrabel <david.vrabel@csr.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as1197) fixes an error introduced recently. Since a
significant number of devices can't handle Set-Interface requests, we
no longer call usb_set_interface() when a driver unbinds from an
interface, provided the interface is already in altsetting 0. However
the interface still does get disabled, and the call to
usb_set_interface() was the only thing re-enabling it. Since the
interface doesn't get re-enabled, further attempts to use it fail.
So the patch adds a call to usb_enable_interface() when a driver
unbinds and the interface is in altsetting 0. For this to work
right, the interface's endpoints have to be re-enabled but their
toggles have to be left alone. Therefore an additional argument is
added to usb_enable_endpoint() and usb_enable_interface(), a flag
indicating whether or not the endpoint toggles should be reset.
This is a forward-ported version of a patch which fixes Bugzilla
#12301.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: David Roka <roka@dawid.hu>
Reported-by: Erik Ekman <erik@kryo.se>
Tested-by: Erik Ekman <erik@kryo.se>
Tested-by: Alon Bar-Lev <alon.barlev@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as1185) makes usbcore take advantage of the bus
notifications sent out by the driver core. Now we can create all our
device and interface attribute files before the device or interface
uevent is broadcast.
A side effect is that we no longer create the endpoint "pseudo"
devices at the same time as a device or interface is registered -- it
seems like a bad idea to try registering an endpoint before the
registration of its parent is complete. So the routines for creating
and removing endpoint devices have been split out and renamed, and
they are called explicitly when needed. A new bitflag is used for
keeping track of whether or not the interface's endpoint devices have
been created, since (just as with the interface attributes) they vary
with the altsetting and hence can be changed at random times.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Cc: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as1177) modifies the USB core suspend and resume
routines. The resume functions now will take a pm_message_t argument,
so they will know what sort of resume is occurring. The new argument
is also passed to the port suspend/resume and bus suspend/resume
routines (although they don't use it for anything but debugging).
In addition, special pm_message_t values are used for user-initiated,
device-initiated (i.e., remote wakeup), and automatic suspend/resume.
By testing these values, drivers can tell whether or not a particular
suspend was an autosuspend. Unfortunately, they can't do the same for
resumes -- not until the pm_message_t argument is also passed to the
drivers' resume methods. That will require a bigger change.
IMO, the whole Power Management framework should have been set up this
way in the first place.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Impact: cleanup
Found this when I changed args to __module_param_call. We now have
core_param for exactly this, but Greg assures me "nousb" is used as a
module parameter, so we need the #ifdef MODULE.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Cc: Pete Zaitcev <zaitcev@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as1160b) adds support routines for asynchronous autosuspend
and autoresume, with accompanying documentation updates. There
already are several potential users of this interface, and others are
likely to arise as autosuspend support becomes more widespread.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as1161) changes the interface to
usb_lock_device_for_reset(). The existing interface is apparently not
very clear, judging from the fact that several of its callers don't
use it correctly. The new interface always returns 0 for success and
it always requires the caller to unlock the device afterward.
The new routine will not return immediately if it is called while the
driver's probe method is running. Instead it will wait until the
probe is over and the device has been unlocked. This shouldn't cause
any problems; I don't know of any cases where drivers call
usb_lock_device_for_reset() during probe.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Cc: Pete Zaitcev <zaitcev@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
PM: Simplify the new suspend/hibernation framework for devices
Following the discussion at the Kernel Summit, simplify the new
device PM framework by merging 'struct pm_ops' and
'struct pm_ext_ops' and removing pointers to 'struct pm_ext_ops'
from 'struct platform_driver' and 'struct pci_driver'.
After this change, the suspend/hibernation callbacks will only
reside in 'struct device_driver' as well as at the bus type/
device class/device type level. Accordingly, PCI and platform
device drivers are now expected to put their suspend/hibernation
callbacks into the 'struct device_driver' embedded in
'struct pci_driver' or 'struct platform_driver', respectively.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@suse.cz>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as1129) adds support for the new PM callbacks to usbcore.
The new callbacks merely invoke the same old USB power management
routines as the old ones did.
A minor improvement is that the callbacks are present only in the
"USB-device" device_type structure, rather than in the bus_type
structure. This way they will be invoked only for USB devices, not
for USB interfaces. The core USB PM routines automatically handle
suspending and resuming interfaces along with their devices.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The bus_id field is going away, use the dev_set_name() function
to set it properly.
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The bus_id field is going away, use the dev_name() function instead.
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as1087d) fixes a long-standing problem in usbcore: Device,
interface, and endpoint attributes aren't added until _after_ the
creation uevent has already been broadcast.
Unfortunately there are a few attributes which cannot be created that
early. The "descriptors" attribute is binary and so must be created
separately. The power-management attributes can't be created until
the dev/power/ group exists. And the interface string can vary from
one altsetting to another, so it has to be created dynamically.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Cc: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Fix docbook problems in USB source files.
These cause the generated docbook to be incorrect.
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Over two years ago, the Linux USB developers stated that they believed
there was no way to create a USB kernel driver that was not under the
GPL. This patch moves the USB apis to enforce that decision.
There are no known closed source USB drivers in the wild, so this patch
should cause no problems.
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch exports two statistics to userspace:
/sys/bus/usb/device/.../power/connected_duration
/sys/bus/usb/device/.../power/active_duration
connected_duration is the total time (in msec) that the device has
been connected. active_duration is the total time the device has not
been suspended. With these two statistics, tools like PowerTOP can
calculate the percentage time that a device is active, i.e. not
suspended or auto-suspended.
Users can also use the active_duration to check if a device is actually
autosuspended. Currently, they can set power/level to auto and
power/autosuspend to a positive timeout, but there's no way to know from
userspace if a device was actually autosuspended without looking at the
dmesg output. These statistics will be useful in creating an automated
userspace script to test autosuspend for USB devices.
Signed-off-by: Sarah Sharp <sarah.a.sharp@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as1012b) makes the ksuspend_usbd kernel thread
non-freezable. Since the PM core has been changed to lock all devices
during a system sleep, the thread no longer needs to be frozen. It
won't interfere with a system sleep because before trying to resume a
root hub device, it acquires the device's lock.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as1010) was written by both Kay Sievers and me. It solves
the problem of duplicated keys in USB uevent structures by refactoring
the uevent subroutines, taking advantage of the way the hotplug core
calls uevent handlers for the device's bus and for the device's type.
Keys needed for both USB-device and USB-interface events are added in
usb_uevent(), which is the bus handler. Keys appropriate only for
USB-device or USB-interface events are added in usb_dev_uevent() or
usb_if_uevent() respectively, the type handlers.
In addition, unnecessary tests for NULL pointers are removed as are
duplicated debugging log statements.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Cc: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Not architecture specific code should not #include <asm/scatterlist.h>.
This patch therefore either replaces them with
#include <linux/scatterlist.h> or simply removes them if they were
unused.
Signed-off-by: Adrian Bunk <bunk@kernel.org>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
This patch contains the following cleanups that are now possible:
- remove the unused security_operations->inode_xattr_getsuffix
- remove the no longer used security_operations->unregister_security
- remove some no longer required exit code
- remove a bunch of no longer used exports
Signed-off-by: Adrian Bunk <bunk@kernel.org>
Acked-by: James Morris <jmorris@namei.org>
Cc: Chris Wright <chrisw@sous-sol.org>
Cc: Stephen Smalley <sds@tycho.nsa.gov>
Cc: Serge Hallyn <serue@us.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
powertop currently tracks interrupts generated by uhci, ehci, and ohci,
but it has no way of telling which USB device to blame USB bus activity on.
This patch exports the number of URBs that are submitted for a given device.
Cat the file 'urbnum' in /sys/bus/usb/devices/.../
Signed-off-by: Sarah Sharp <sarah.a.sharp@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as989) makes usbcore flush all outstanding URBs for each
device as the device is suspended. This will be true even when
CONFIG_USB_SUSPEND is not enabled.
In addition, an extra can_submit flag is added to the usb_device
structure. That flag will be turned off whenever a suspend request
has been received for the device, even if the device isn't actually
suspended because CONFIG_USB_SUSPEND isn't set.
It's no longer necessary to check for the device state being equal to
USB_STATE_SUSPENDED during URB submission; that check can be replaced
by a check of the can_submit flag. This also permits us to remove
some questionable references to the deprecated power.power_state field.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as946) eliminates many of the uses of urb->pipe in
usbcore. Unfortunately there will have to be a significant API
change, affecting all USB drivers, before we can remove it entirely.
This patch contents itself with changing only the interface to
usb_buffer_map_sg() and friends: The pipe argument is replaced with a
direction flag. That can be done easily because those routines get
used in only one place.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as944) adds an explicit "enabled" field to the
usb_host_endpoint structure and uses it in place of the current
mechanism. This is merely a time-space tradeoff; it makes checking
whether URBs may be submitted to an endpoint simpler. The existing
mechanism is efficient when converting urb->pipe to an endpoint
pointer, but it's not so efficient when urb->ep is used instead.
As a side effect, the procedure for enabling an endpoint is now a
little more complicated. The ad-hoc inline code in usb.c and hub.c
for enabling ep0 is now replaced with calls to usb_enable_endpoint,
which is no longer static.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch updates some of the documentation about DMA buffer management
for USB, and ways to avoid extra copying. Our understanding of the issues
has improved over time.
- Most drivers should *avoid* the dma-coherent allocators. There are
a few exceptions (like the HID driver).
- Some methods are currently commented out; it seems folk writing
USB drivers aren't doing performance tuning at that level yet.
- Just avoid highmem; there's no good way to pass an "I can do highmem
DMA" capability through a driver stack. This is easy, everything
already avoids highmem. But it'd be nice if x86_32 systems with much
physical memory could use it directly with network adapters and mass
storage devices. (Patch, anyone?)
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
