08 Dec, 2006
1 commit
-
For node-aware skb allocations we need information about the node in struct
net_device or struct device. Davem suggested to put it into struct device
which this patch does.In particular:
- struct device gets a new int numa_node member if CONFIG_NUMA is set
- there are two new helpers, dev_to_node and set_dev_node to
transparently deal with the non-numa case
- for pci devices the node-info is set to the value we get from
pcibus_to_node.Note that for some architectures pcibus_to_node doesn't work yet at the time
we call it currently. This is harmless and will just mean skb allocations
aren't node-local on this architectures until the implementation of
pcibus_to_node on these architectures have been updated (There are patches for
x86 and x86_64 floating around)[akpm@osdl.org: cleanup]
Signed-off-by: Christoph Hellwig
Cc: Christoph Lameter
Cc: Greg KH
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
02 Dec, 2006
6 commits
-
Provide a function device_move() to move a device to a new parent device. Add
auxilliary functions kobject_move() and sysfs_move_dir().
kobject_move() generates a new uevent of type KOBJ_MOVE, containing the
previous path (DEVPATH_OLD) in addition to the usual values. For this, a new
interface kobject_uevent_env() is created that allows to add further
environmental data to the uevent at the kobject layer.Signed-off-by: Cornelia Huck
Acked-by: Kay Sievers
Signed-off-by: Greg Kroah-Hartman -
Introduce device_find_child() to match device_for_each_child().
Signed-off-by: Cornelia Huck
Signed-off-by: Greg Kroah-Hartman -
Change ACPI to use dev_archdata instead of firmware_data
This patch changes ACPI to use the new dev_archdata on i386, x86_64
and ia64 (is there any other arch using ACPI ?) to store it's
acpi_handle.It also removes the firmware_data field from struct device as this
was the only user.Only build-tested on x86
Signed-off-by: Benjamin Herrenschmidt
Cc: Len Brown
Signed-off-by: Greg Kroah-Hartman -
Add arch specific dev_archdata to struct device
Adds an arch specific struct dev_arch to struct device. This enables
architecture to add specific fields to every device in the system, like
DMA operation pointers, NUMA node ID, firmware specific data, etc...Signed-off-by: Benjamin Herrenschmidt
Acked-by: Andi Kleen
Acked-By: David Howells
Signed-off-by: Greg Kroah-Hartman -
It doesn't need to be global or in device.h
Cc: Kay Sievers
Signed-off-by: Greg Kroah-Hartman -
I finally did as you suggested and added the notifier to the struct
bus_type itself. There are still problems to be expected is something
attaches to a bus type where the code can hook in different struct
device sub-classes (which is imho a big bogosity but I won't even try to
argue that case now) but it will solve nicely a number of issues I've
had so far.That also means that clients interested in registering for such
notifications have to do it before devices are added and after bus types
are registered. Fortunately, most bus types that matter for the various
usage scenarios I have in mind are registerd at postcore_initcall time,
which means I have a really nice spot at arch_initcall time to add my
notifiers.There are 4 notifications provided. Device being added (before hooked to
the bus) and removed (failure of previous case or after being unhooked
from the bus), along with driver being bound to a device and about to be
unbound.The usage I have for these are:
- The 2 first ones are used to maintain a struct device_ext that is
hooked to struct device.firmware_data. This structure contains for now a
pointer to the Open Firmware node related to the device (if any), the
NUMA node ID (for quick access to it) and the DMA operations pointers &
iommu table instance for DMA to/from this device. For bus types I own
(like IBM VIO or EBUS), I just maintain that structure directly from the
bus code when creating the devices. But for bus types managed by generic
code like PCI or platform (actually, of_platform which is a variation of
platform linked to Open Firmware device-tree), I need this notifier.- The other two ones have a completely different usage scenario. I have
cases where multiple devices and their drivers depend on each other. For
example, the IBM EMAC network driver needs to attach to a MAL DMA engine
which is a separate device, and a PHY interface which is also a separate
device. They are all of_platform_device's (well, about to be with my
upcoming patches) but there is no say in what precise order the core
will "probe" them and instanciate the various modules. The solution I
found for that is to have the drivers for emac to use multithread_probe,
and wait for a driver to be bound to the target MAL and PHY control
devices (the device-tree contains reference to the MAL and PHY interface
nodes, which I can then match to of_platform_devices). Right now, I've
been polling, but with that notifier, I can more cleanly wait (with a
timeout of course).Signed-off-by: Benjamin Herrenschmidt
Signed-off-by: Greg Kroah-Hartman
24 Oct, 2006
1 commit
-
Eliminate more __must_check madness.
The return code from device_for_each_child() depends on the values
which the helper function returns. If the helper function always
returns zero, it's utterly pointless to check the return code from
device_for_each_child().The only code which knows if the return value should be checked is
the caller itself, so forcing the return code to always be checked
is silly. Hence, remove the __must_check annotation.Signed-off-by: Russell King
Signed-off-by: Linus Torvalds
26 Sep, 2006
15 commits
-
There is a potential deadlock in the driver core. It boils down to
the fact that bus_remove_device() calls klist_remove() instead of
klist_del(), thereby waiting until the reference count of the
klist_node in the bus's klist of devices drops to 0. The refcount
can't reach 0 so long as a modprobe process is trying to bind a new
driver to the device being removed, by calling __driver_attach(). The
problem is that __driver_attach() tries to acquire the device's
parent's semaphore, but the caller of bus_remove_device() is quite
likely to own that semaphore already.It isn't sufficient just to replace klist_remove() with klist_del().
Doing so runs the risk that the device would remain on the bus's klist
of devices for some time, and so could be bound to another driver even
after it was unregistered. What's needed is a new way to distinguish
whether or not a device is registered, based on a criterion other than
whether its klist_node is linked into the bus's klist of devices. That
way driver binding can fail when the device is unregistered, even if
it is still linked into the klist.This patch (as782) implements the solution, by adding a new bitflag to
indiate when a struct device is registered, by testing the flag before
allowing a driver to bind a device, and by changing the definition of
the device_is_registered() inline.Signed-off-by: Alan Stern
Signed-off-by: Greg Kroah-Hartman -
This adds the infrastructure for drivers to do a threaded probe, and
waits at init time for all currently outstanding probes to complete.A new kernel thread will be created when the probe() function for the
driver is called, if the multithread_probe bit is set in the driver
saying it can support this kind of operation.I have tested this with USB and PCI, and it works, and shaves off a lot
of time in the boot process, but there are issues with finding root boot
disks, and some USB drivers assume that this can never happen, so it is
currently not enabled for any bus type. Individual drivers can enable
this right now if they wish, and bus authors can selectivly turn it on
as well, once they determine that their subsystem will work properly
with it.Signed-off-by: Greg Kroah-Hartman
-
Add lots of return-value checking.
: fix bus_rescan_devices()]
Cc: "Randy.Dunlap"
Signed-off-by: Cornelia Huck
Signed-off-by: Andrew Morton
Signed-off-by: Greg Kroah-Hartman -
We're getting a lot of crashes in the sysfs/kobject/device/bus/class code and
they're very hard to diagnose.I'm suspecting that in some cases this is because drivers aren't checking
return values and aren't handling errors correctly. So the code blithely
blunders on and crashes later in very obscure ways.There's just no reason to ignore errors which can and do occur. So the patch
sprinkles __must_check all over these APIs.Causes 1,513 new warnings. Heh.
Signed-off-by: Andrew Morton
Signed-off-by: Greg Kroah-Hartman -
Makes it easier for devices to create and remove binary attribute files
so they don't have to call directly into sysfs. This is needed to help
with the conversion from struct class_device to struct device.Signed-off-by: Greg Kroah-Hartman
-
When moving class_device usage over to device, we need to handle
class_interfaces properly with devices. This patch adds that support.Signed-off-by: Greg Kroah-Hartman
-
This change creates a devices/virtual/CLASS_NAME tree for struct devices
that belong to a class, yet do not have a "real" struct device for a
parent. It automatically creates the directories on the fly as needed.Cc: Kay Sievers
Signed-off-by: Greg Kroah-Hartman -
The network layer needs this to convert to using struct device instead
of a struct class_device.Signed-off-by: Greg Kroah-Hartman
-
This adds two new callbacks to the class structure:
int (*dev_uevent)(struct device *dev, char **envp, int num_envp,
char *buffer, int buffer_size);
void (*dev_release)(struct device *dev);And one pointer:
struct device_attribute * dev_attrs;which all corrispond with the same thing as the "normal" class devices
do, yet this is for when a struct device is bound to a class.Someday soon, struct class_device will go away, and then the other
fields in this structure can be removed too. But this is necessary in
order to get the transition to work properly.Tested out on a network core patch that converted it to use struct
device instead of struct class_device.Signed-off-by: Greg Kroah-Hartman
-
This is needed for the network class devices in order to be able to
convert over to use struct device.Signed-off-by: Greg Kroah-Hartman
-
Remove the new suspend_prepare() phase. It doesn't seem very usable,
has never been tested, doesn't address fault cleanup, and would need
a sibling resume_complete(); plus there are no real use cases. It
could be restored later if those issues get resolved.Signed-off-by: David Brownell
Cc: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
Allow devices to participate in the suspend process more intimately,
in particular, allow the final phase (with interrupts disabled) to
also be open to normal devices, not just system devices.Also, allow classes to participate in device suspend.
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
Adds const to class_create second parameter, because:
struct class {
const char * name;/*...*/
}Signed-off-by: Miguel Ojeda Sandonis
Signed-off-by: Greg Kroah-Hartman -
Signed-off-by: Greg Kroah-Hartman
-
Signed-off-by: Dmitry Torokhov
Signed-off-by: Greg Kroah-Hartman
22 Jun, 2006
3 commits
-
This patch (as721) makes dev_info and related macros print the device's
bus name if the device doesn't have a driver, instead of printing just a
blank. If the device isn't on a bus either... well, then it does leave
a blank space. But it will be easier for someone else to change if they
want.Cc: Matthew Wilcox
Signed-off-by: Alan Stern
Signed-off-by: Greg Kroah-Hartman -
This is the first step in moving class_device to being replaced by
struct device. It allows struct device to export a dev_t and makes it
easy to dynamically create and destroy struct device as long as they are
associated with a specific class.Cc: Kay Sievers
Signed-off-by: Greg Kroah-Hartman -
Cc: Arjan van de Ven
Signed-off-by: Greg Kroah-Hartman
24 May, 2006
1 commit
-
Conflicts:
include/asm-powerpc/unistd.h
include/asm-sparc/unistd.h
include/asm-sparc64/unistd.hSigned-off-by: David Woodhouse
07 May, 2006
1 commit
-
Extend the support of attribute groups in class_device's to allow
groups to be created as part of the registration process. This allows
network device's to avoid race between registration and creating
groups.Note that unlike attributes that are a property of the class object,
the groups are a property of the class_device object. This is done
because there are different types of network devices (wireless for
example).Signed-off-by: Stephen Hemminger
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: David S. Miller
26 Apr, 2006
1 commit
-
Signed-off-by: David Woodhouse
23 Mar, 2006
1 commit
-
* git://git.kernel.org/pub/scm/linux/kernel/git/bunk/trivial:
fixed path to moved file in include/linux/device.h
Fix spelling in E1000_DISABLE_PACKET_SPLIT Kconfig description
Documentation/dvb/get_dvb_firmware: fix firmware URL
Documentation: Update to BUG-HUNTING
Remove superfluous NOTIFY_COOKIE_LEN define
add "tags" to .gitignore
Fix "frist", "fisrt", typos
fix rwlock usage example
It's UTF-8
22 Mar, 2006
2 commits
-
Signed-off-by: Adrian Bunk
21 Mar, 2006
1 commit
-
Both usb.h and device.h have collections of convenience macros for
printk() with the KERN_ERR, KERN_WARNING, and KERN_NOTICE severity
levels. This patch adds macros for the KERN_NOTICE level which was
so far uncatered for.These macros already exist privately in drivers/isdn/gigaset/gigaset.h
(currently in the process of being submitted for the kernel tree)
but they really belong with their brothers and sisters in
include/linux/{device,usb}.h.Signed-off-by: Tilman Schmidt
Signed-off-by: Greg Kroah-Hartman
15 Mar, 2006
1 commit
-
Adding support for exposing hidden raid components for sg
interface. The sdev->no_uld_attach flag will set set accordingly.The sas module supports adding/removing raid volumes using online
storage management application interface.This patch was provided to me by Christoph Hellwig.
Signed-off-by: Eric Moore
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: James Bottomley
14 Jan, 2006
1 commit
-
Add bus_type probe, remove and shutdown methods to replace the
corresponding methods in struct device_driver. This matches
the way we handle the suspend/resume methods.Since the bus methods override the device_driver methods, warn
if a device driver is registered whose methods will not be
called.The long-term idea is to remove the device_driver methods entirely.
Signed-off-by: Russell King
Signed-off-by: Greg Kroah-Hartman
05 Jan, 2006
1 commit
-
Leave the overloaded "hotplug" word to susbsystems which are handling
real devices. The driver core does not "plug" anything, it just exports
the state to userspace and generates events.Signed-off-by: Kay Sievers
Signed-off-by: Greg Kroah-Hartman
30 Oct, 2005
1 commit
-
Convert everyone who uses platform_bus_type to include
linux/platform_device.h.Signed-off-by: Russell King
Acked-by: Greg Kroah-Hartman
29 Oct, 2005
3 commits
-
In PM v1, all devices were called at SUSPEND_DISABLE level. Then
all devices were called at SUSPEND_SAVE_STATE level, and finally
SUSPEND_POWER_DOWN level. However, with PM v2, to maintain
compatibility for platform devices, I arranged for the PM v2
suspend/resume callbacks to call the old PM v1 suspend/resume
callbacks three times with each level in order so that existing
drivers continued to work.Since this is obsolete infrastructure which is no longer necessary,
we can remove it. Here's an (untested) patch to do exactly that.Signed-off-by: Russell King
Signed-off-by: Greg Kroah-Hartman -
Signed-off-by: Greg Kroah-Hartman
-
This patch allows struct class_device to be nested, so that another
struct class_device can be the parent of a new one, instead of only
having the struct class be the parent. This will allow us to
(hopefully) fix up the input and video class subsystem mess.But please people, don't go crazy and start making huge trees of class
devices, you should only need 2 levels deep to get everything to work
(remember to use a class_interface to get notification of a new class
device being added to the system.)Oh, this also allows us to have the possibility of potentially, someday,
moving /sys/block into /sys/class. The main hindrance is that pesky
/dev numberspace issue...Signed-off-by: Greg Kroah-Hartman