- 27 Apr, 2007 40 commits
-
-
Cornelia Huck authored
We often have the situation that we register a subchannel and start device recognition, only to find out that the device is not usable after all, which triggers an unregister of the subchannel. This often happens on hundreds of subchannels on a LPAR, leading to a storm of events which aren't of any use. Therefore, use uevent_suppress to delay the KOBJ_ADD uevent for a subchannel until we know that its ccw_device is to be registered. Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com> Cc: Kay Sievers <kay.sievers@vrfy.org> Cc: Eric Rannaud <eric.rannaud@gmail.com> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Andrew Morton authored
fs/sysfs/bin.c: In function 'read': fs/sysfs/bin.c:77: warning: format '%zd' expects type 'signed size_t', but argument 4 has type 'int' Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Matthias Kaehlcke authored
the DMA pool handler uses a semaphore as mutex. use the mutex API instead of the (binary) semaphore Signed-off-by: Matthias Kaehlcke <matthias.kaehlcke@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Greg Kroah-Hartman authored
As pointed out by Dave Jones. Cc: Dave Jones <davej@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Michael Ellerman authored
I went to use this the other day, only to find it didn't exist. It's a straight copy of the debugfs u32 code, then s/u32/u64/. A quick test shows it seems to be working. Signed-off-by: Michael Ellerman <michael@ellerman.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Adrian Bunk authored
This patch contains the overdue removal of the mount/umount uevents. Signed-off-by: Adrian Bunk <bunk@stusta.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Eric W. Biederman authored
This dots some i's and crosses some t's after left over from when kobject_kset_add_dir was built from kobject_add_dir. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> Cc: Kay Sievers <kay.sievers@vrfy.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Kay Sievers authored
In the future we will allow the uevent type to be written to the uevent file to trigger the different types of uevents. But for now, as we only support the ADD event, warn if userspace tries to write anything else to this file. Signed-off-by: Kay Sievers <kay.sievers@vrfy.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Kay Sievers authored
This allows sysfs to show the environment variables that are available if the uevent happens. This lets userspace not have to cache all of this information as the kernel already knows it. Signed-off-by: Kay Sievers <kay.sievers@vrfy.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Greg Kroah-Hartman authored
It isn't used at all by the driver core anymore, and the few usages of it within the kernel have now all been fixed as most of them were using it incorrectly. So remove it. Now the whole struct subsys can be removed from the system, but that's for a later patch... Cc: Kay Sievers <kay.sievers@vrfy.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Cornelia Huck authored
the current driver tree contains the removal of subsys.rwsem. Unfortunately, this breaks qeth. However, it should be no problem to fix the walking of the devices for /proc/qeth: No need to take subsys.rwsem during walking the devices, driver_find_devices() should already suffice. Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Greg Kroah-Hartman authored
The subsystem rwsem is not used by the driver core at all, so the use of it in the phy code doesn't make any sense. They might possibly want to use a local lock, but I am unsure about that. Cc: netdev <netdev@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Greg Kroah-Hartman authored
The subsystem rwsem is not used by the driver core at all, so the use of it in the ieee1394 code doesn't make any sense. They might possibly want to use a local lock, but as most of these operations are already protected by a local lock, it really doesn't look like it would be needed. Cc: Ben Collins <bcollins@debian.org> Cc: Stefan Richter <stefanr@s5r6.in-berlin.de> Cc: linux1394-devel <linux1394-devel@lists.sourceforge.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Greg Kroah-Hartman authored
The subsystem rwsem is not used by the driver core at all, so the use of it in the ide-proc code of it doesn't make any sense. Perhaps a local lock might be needed, but I do not really think so. Cc: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> Cc: linux ide <linux-ide@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Dmitry Torokhov authored
The subsystem rwsem is not used by the driver core at all, so there is no point in trying to access it. Signed-off-by: Dmitry Torokhov <dtor@mail.ru> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Dmitry Torokhov authored
The subsystem rwsem is not used by the driver core at all, so there is no point in trying to access it. Signed-off-by: Dmitry Torokhov <dtor@mail.ru> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Greg Kroah-Hartman authored
The rwsem is not used to protect anything, so the use of it by the PNP subsystem isn't really useful, and it's doubtful if it really did anything or not. So I've removed it. Cc: Adam Belay <ambx1@neo.rr.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Greg Kroah-Hartman authored
The driver core stopped using the rwsem a long time ago, yet the USB core still grabbed the lock, thinking it protected something. This patch removes that useless use. Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Oliver Neukum <oneukum@suse.de> Cc: David Brownell <david-b@pacbell.net> Cc: linux-usb-devel <linux-usb-devel@lists.sourceforge.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Greg Kroah-Hartman authored
SCSI was using the incorrect lock to protect walking the list of all devices in the class. This patch fixes this. Cc: James Bottomley <James.Bottomley@SteelEye.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Greg Kroah-Hartman authored
This lock is never used by the rest of the driver core, so the fact that we are grabbing it here means it isn't correct... Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Cornelia Huck authored
We leak a reference if we attempt to add a kobject with no name. Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
John Anthony Kazos Jr authored
Collapses a do..while() loop within an if() to a simple while() loop for simplicity and readability. Signed-off-by: John Anthony Kazos Jr. <jakj@j-a-k-j.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Dmitry Torokhov authored
Driver core: add suspend() and resume() to struct device_type In cases when there are devices of different types in the same class we can't use class's implementation of suspend and resume methods and we need to add them to struct device_type instead. Also fix error handling in resume code (we should not try to call class's resume method iof bus's resume method for the device failed. Signed-off-by: Dmitry Torokhov <dtor@mail.ru> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Eric Rannaud authored
Make use of add_uevent_var() instead of (often incorrectly) open coding it. Signed-off-by: Michael Ellerman <michael@ellerman.id.au> Signed-off-by: Eric Rannaud <eric.rannaud@gmail.com> Cc: Kay Sievers <kay.sievers@vrfy.org> Cc: Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Cornelia Huck authored
Use uevent_suppress instead of returning an error code in firmware_uevent(). Get rid of the now unneeded FW_STATUS_READY and FW_STATUS_READY_NOHOTPLUG. Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Cornelia Huck authored
Suppress uevents for devices if uevent_suppress is set via dev_uevent_filter(). This makes the driver core suppress all device uevents, not just the add event in device_add(). Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com> Cc: Kay Sievers <kay.sievers@vrfy.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Jean Tourrilhes authored
Provide rename event for when we rename network devices. Signed-off-by: Jean Tourrilhes <jt@hpl.hp.com> Cc: Kay Sievers <kay.sievers@vrfy.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Oliver Neukum authored
some atomic operations are only atomic, not ordered. Thus a CPU is allowed to reorder memory references to an object to before the reference is obtained. This fixes it. Signed-off-by: Oliver Neukum <oneukum@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Greg Kroah-Hartman authored
The completion in the driver release path is due to ancient history in the _very_ early 2.5 days when we were not tracking the module reference count of attributes. It is not needed at all and can be removed. Note, we now have an empty release function for the driver structure. This is due to the fact that drivers are statically allocated in the system at this point in time, something which I want to change in the future. But remember, drivers are really code, which is reference counted by the module, unlike devices, which are data and _must_ be reference counted properly in order to work correctly. Cc: Kay Sievers <kay.sievers@vrfy.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Cornelia Huck authored
Don't fail bus_attach_device() if the device cannot be bound. If dev->driver has been specified, reset it to NULL if device_bind_driver() failed and add the device as an unbound device. As a result, bus_attach_device() now cannot fail, and we can remove some checking from device_add(). Also remove an unneeded check in bus_rescan_devices_helper(). Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Andrew Morton authored
arch/powerpc/kernel/of_platform.c:479: error: unknown field `multithread_probe' specified in initializer Cc: Paul Mackerras <paulus@samba.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Cornelia Huck authored
Make multithreaded probing work per subsystem instead of per driver. It doesn't make much sense to probe the same device for multiple drivers in parallel (after all, only one driver can bind to the device). Instead, create a probing thread for each device that probes the drivers one after another. Also make the decision to use multi-threaded probe per bus instead of per device and adapt the pci code. Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Dmitriy Monakhov authored
- correct function name in comments - parrent assignment does metter only inside "if" block, so move it inside this block. Signed-off-by: Monakhov Dmitriy <dmonakhov@openvz.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Kay Sievers authored
If "name" of a device_type is specified, the uevent will contain the device_type name in the DEVTYPE variable. This helps userspace to distingiush between different types of devices, belonging to the same subsystem. Signed-off-by: Kay Sievers <kay.sievers@vrfy.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Dmitry Torokhov authored
Driver core: use attribute groups in struct device_type Attribute groups are more flexible than attribute lists (an attribute list can be represented by anonymous group) so switch struct device_type to use them. Also rework attribute creation for devices so that they all cleaned up properly in case of errors. Signed-off-by: Dmitry Torokhov <dtor@mail.ru> Cc: Kay Sievers <kay.sievers@novell.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Kay Sievers authored
We get two per-bus sysfs files: ls-l /sys/subsystem/usb drwxr-xr-x 2 root root 0 2007-02-16 16:42 devices drwxr-xr-x 7 root root 0 2007-02-16 14:55 drivers -rw-r--r-- 1 root root 4096 2007-02-16 16:42 drivers_autoprobe --w------- 1 root root 4096 2007-02-16 16:42 drivers_probe The flag "drivers_autoprobe" controls the behavior of the bus to bind devices by default, or just initialize the device and leave it alone. The command "drivers_probe" accepts a bus_id and the bus tries to bind a driver to this device. Systems who want to control the driver binding with udev, switch off the bus initiated probing: echo 0 > /sys/subsystem/usb/drivers_autoprobe echo 0 > /sys/subsystem/pcmcia/drivers_autoprobe ... and initiate the probing with udev rules like: ACTION=="add", SUBSYSTEM=="usb", ATTR{subsystem/drivers_probe}="$kernel" ACTION=="add", SUBSYSTEM=="pcmcia", ATTR{subsystem/drivers_probe}="$kernel" ... Custom driver binding can happen in earlier rules by something like: ACTION=="add", SUBSYSTEM=="usb", \ ATTRS{idVendor}=="1234", ATTRS{idProduct}=="5678" \ ATTR{subsystem/drivers/<custom-driver>/bind}="$kernel" This is intended to solve the modprobe.conf mess with "install-rules", custom bind/unbind-scripts and all the weird things people invented over the years. It should also provide the functionality "libusual" was supposed to do. With udev, one can just write a udev rule to drive all USB-disks at the third port of USB-hub by the "ub" driver, and everything else by usb-storage. One can also instruct udev to bind different wireless drivers to identical cards - just selected by the pcmcia slot-number, and whatever ... To use the mentioned rules, it needs udev version 106, to be able to write ATTR{}="$kernel" to sysfs files. Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Jean Delvare authored
As the new-style class devices (as opposed to old-style struct class_device) are becoming more widely used, I noticed that the dev_printk-based functions are not working properly with these. New-style class devices have no driver nor bus, almost by definition, and as a result dev_driver_string(), which is used as the first parameter of dev_printk, resolves to an empty string. This causes entries like the following to show in my logs: i2c-2: adapter [SMBus stub driver] registered Notice the unaesthetical leading whitespace. In order to fix this problem, I suggest that we extend dev_driver_string to deal with new-style class devices: Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Kay Sievers authored
- uses a kset in "struct class" to keep track of all directories belonging to this class - merges with the /sys/devices/virtual logic. - removes the namespace-dir if the last member of that class leaves the directory. There may be locking or refcounting fixes left, I stopped when it seemed to work with network and sound modules. :) From: Kay Sievers <kay.sievers@vrfy.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Dmitriy Monakhov authored
- At the moment we jump here device was't added to dev->class->devices list yet. Signed-off-by: Monakhov Dmitriy <dmonakhov@openvz.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-
Linus Torvalds authored
* 'e1000-fixes' of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6: e1000: FIX: Stop raw interrupts disabled nag from RT e1000: FIX: firmware handover bits e1000: FIX: be ready for incoming irq at pci_request_irq
-