- 16 Jun, 2009 40 commits
-
-
Greg Kroah-Hartman authored
In the near future, the driver core is going to not allow direct access to the driver_data pointer in struct device. Instead, the functions dev_get_drvdata() and dev_set_drvdata() should be used. These functions have been around since the beginning, so are backwards compatible with all older kernel versions. Cc: linux-scsi@vger.kernel.org Cc: James Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by:Greg Kroah-Hartman <gregkh@suse.de>
-
Greg Kroah-Hartman authored
In the near future, the driver core is going to not allow direct access to the driver_data pointer in struct device. Instead, the functions dev_get_drvdata() and dev_set_drvdata() should be used. These functions have been around since the beginning, so are backwards compatible with all older kernel versions. Cc: linux-pcmcia@lists.infradead.org Cc: Dominik Brodowski <linux@dominikbrodowski.net> Signed-off-by: -
Greg Kroah-Hartman authored
In the near future, the driver core is going to not allow direct access to the driver_data pointer in struct device. Instead, the functions dev_get_drvdata() and dev_set_drvdata() should be used. These functions have been around since the beginning, so are backwards compatible with all older kernel versions. Cc: linux-pci@vger.kernel.org Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: -
Greg Kroah-Hartman authored
In the near future, the driver core is going to not allow direct access to the driver_data pointer in struct device. Instead, the functions dev_get_drvdata() and dev_set_drvdata() should be used. These functions have been around since the beginning, so are backwards compatible with all older kernel versions. Cc: Samuel Ortiz <sameo@linux.intel.com> Acked-by:
Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by:
-
Greg Kroah-Hartman authored
In the near future, the driver core is going to not allow direct access to the driver_data pointer in struct device. Instead, the functions dev_get_drvdata() and dev_set_drvdata() should be used. These functions have been around since the beginning, so are backwards compatible with all older kernel versions. Cc: Mauro Carvalho Chehab <mchehab@infradead.org> Acked-by:
Mike Isely <isely@pobox.com> Cc: linux-media@vger.kernel.org Signed-off-by:
-
Greg Kroah-Hartman authored
In the near future, the driver core is going to not allow direct access to the driver_data pointer in struct device. Instead, the functions dev_get_drvdata() and dev_set_drvdata() should be used. These functions have been around since the beginning, so are backwards compatible with all older kernel versions. Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com> Cc: linux-input@vger.kernel.org Signed-off-by: -
Greg Kroah-Hartman authored
In the near future, the driver core is going to not allow direct access to the driver_data pointer in struct device. Instead, the functions dev_get_drvdata() and dev_set_drvdata() should be used. These functions have been around since the beginning, so are backwards compatible with all older kernel versions. Cc: general@lists.openfabrics.org Cc: Roland Dreier <rolandd@cisco.com> Cc: Hal Rosenstock <hal.rosenstock@gmail.com> Cc: Sean Hefty <sean.hefty@intel.com> Signed-off-by: -
Greg Kroah-Hartman authored
In the near future, the driver core is going to not allow direct access to the driver_data pointer in struct device. Instead, the functions dev_get_drvdata() and dev_set_drvdata() should be used. These functions have been around since the beginning, so are backwards compatible with all older kernel versions. Cc: linux1394-devel@lists.sourceforge.net Acked-by:
Stefan Richter <stefanr@s5r6.in-berlin.de> Cc: Ben Collins <ben.collins@ubuntu.com> Signed-off-by:
-
Greg Kroah-Hartman authored
In the near future, the driver core is going to not allow direct access to the driver_data pointer in struct device. Instead, the functions dev_get_drvdata() and dev_set_drvdata() should be used. These functions have been around since the beginning, so are backwards compatible with all older kernel versions. Cc: linux-ide@vger.kernel.org Acked-by:
Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> Signed-off-by:
-
Greg Kroah-Hartman authored
In the near future, the driver core is going to not allow direct access to the driver_data pointer in struct device. Instead, the functions dev_get_drvdata() and dev_set_drvdata() should be used. These functions have been around since the beginning, so are backwards compatible with all older kernel versions. Cc: linux1394-devel@lists.sourceforge.net Acked-by:
-
Greg Kroah-Hartman authored
In the near future, the driver core is going to not allow direct access to the driver_data pointer in struct device. Instead, the functions dev_get_drvdata() and dev_set_drvdata() should be used. These functions have been around since the beginning, so are backwards compatible with all older kernel versions. Signed-off-by: -
Kay Sievers authored
This adds support to the BSG driver to report the proper device name to userspace for the bsg devices. Signed-off-by:
Kay Sievers <kay.sievers@vrfy.org> Signed-off-by:
Jan Blunck <jblunck@suse.de> Signed-off-by:
-
Kay Sievers authored
This adds support to the AOE core to report the proper device name to userspace for the AOE devices. Signed-off-by:
-
Kay Sievers authored
This adds support to the drm core to report the proper device name to userspace for the drm devices. Signed-off-by:
-
Kay Sievers authored
This adds support to the raw driver to report the proper device name to userspace for the raw devices. Signed-off-by:
-
Kay Sievers authored
This adds support to the sound core to report the proper device name to userspace for their devices. Signed-off-by:
-
Kay Sievers authored
This adds support to the input core to report the proper device name to userspace for their devices. Signed-off-by:
-
Kay Sievers authored
This adds support to the dvb core to report the proper device name to userspace for their devices. Signed-off-by:
-
Kay Sievers authored
This adds support to the x86 cpuid and msr drivers to report the proper device name to userspace for their devices. Signed-off-by:
-
Kay Sievers authored
This adds support for block drivers to report their requested nodename to userspace. It also updates a number of block drivers to provide the needed subdirectory and device name to be used for them. Signed-off-by:
-
Kay Sievers authored
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 authored
This adds support for misc devices to report their requested nodename to userspace. It also updates a number of misc drivers to provide the needed subdirectory and device name to be used for them. Signed-off-by:
-
Kay Sievers authored
This adds the nodename callback for struct class, struct device_type and struct device, to allow drivers to send userspace hints on the device name and subdirectory that should be used for it. Signed-off-by:
-
Greg Kroah-Hartman authored
This removes the warning: format not a string literal and no format arguments warnings in the driver core that gcc 4.3.3 complains about. Signed-off-by: -
Greg Kroah-Hartman authored
The firmware example files are beyond broken, and will not work, and should not be used as an example at all. So lets remove them and hope someone writes new files sometime in the future. Signed-off-by: -
Samuel Ortiz authored
As we're allocating the firmware name dynamically, we no longer need this definition. This patch must be applied only after the 5 previous patches from this pacth set have been applied. Signed-off-by:
Samuel Ortiz <sameo@linux.intel.com> Signed-off-by:
-
John W. Linville authored
We're going to remove the FIRMWARE_NAME_MAX definition in order to avoid any firmware name length restriction. This patch eplaces the shared FIRMWARE_NAME_MAX definition with a libertas local one. Signed-off-by:
John W. Linville <linville@tuxdriver.com> Acked-by:
Dan Williams <dcbw@redhat.com> Acked-by:
-
Samuel Ortiz authored
We're going to remove the FIRMWARE_NAME_MAX definition in order to avoid any firmware name length restriction. With the FIRMWARE_NAME_MAX removal, the ds.c reference becomes useless as we dont need to check for the firmware name length anymore. Signed-off-by:
-
Samuel Ortiz authored
We're going to remove the FIRMWARE_NAME_MAX definition in order to avoid any firmware name length restriction. This patch changes the dvb_usb_device_properties firmware field accordingly. Signed-off-by:
Michael Krufky <mkrufky@kernellabs.com> Cc: Mauro Carvalho Chehab <mchehab@infradead.org> Signed-off-by:
-
Samuel Ortiz authored
We're going to remove the FIRMWARE_NAME_MAX definition in order to avoid any firmware name length restriction. This patch gets rid of the xc2028 FIRMWARE_NAME_MAX reference. Signed-off-by:
-
Samuel Ortiz authored
We're going to remove the FIRMWARE_NAME_MAX definition in order to avoid any firmware name length restriction. This patch replaces the shared FIRMWARE_NAME_MAX definition with a ueagle local one. Signed-off-by:
-
Samuel Ortiz authored
The firmware loader has a statically allocated 30 bytes long string for the firmware id (a.k.a. the firmware file name). There is no reason why we couldnt allocate it dynamically, and avoid having restrictions on the firmware names lengths. Signed-off-by:
-
Ming Lei authored
request_firmware_nowait declares it can be called in non-sleep contexts, but kthead_run called by request_firmware_nowait may sleep. So fix its documentation and comment to make callers clear about it. Signed-off-by:
Ming Lei <tom.leiming@gmail.com> Signed-off-by:
-
Michal Marek authored
With SAMPLE_KOBJECT=y, it isn't even linked into the kernel image. Signed-off-by:
Michal Marek <mmarek@suse.cz> Signed-off-by:
-
Shaohua Li authored
A patch series to make .shutdown execute asynchronously. Some drivers's shutdown can take a lot of time. The patches can help save some shutdown time. The patches use Arjan's async API. This patch: synchronize all tasks submitted by .shutdown Signed-off-by:
Shaohua Li <shaohua.li@intel.com> Cc: Arjan van de Ven <arjan@infradead.org> Cc: Dmitry Torokhov <dtor@mail.ru> Cc: James Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Jonathan Corbet authored
Fix an error in debugfs_create_blob's docbook description It cannot actually be used to write a binary blob. Signed-off-by:Jonathan Corbet <corbet@lwn.net>
-
Dave Young authored
sysdev_class_register should check the kobject_set_name return value. Add the return value checking code. Signed-off-by:
Dave Young <hidave.darkstar@gmail.com> Signed-off-by:
-
Dave Young authored
kset_create should check the kobject_set_name return value. Add the return value checking code. Signed-off-by:
-
Dmitry Torokhov authored
We are looking for matching drivers, not devices. Signed-off-by:
Dmitry Torokhov <dtor@mail.ru> Signed-off-by:
-
Steven Rostedt authored
debugfs: dont stop on first failed recursive delete While running a while loop of removing a module that removes a debugfs directory with debugfs_remove_recursive, and at the same time doing a while loop of cat of a file in that directory, I would hit a point where somehow the cat of the file caused the remove to fail. The result is that other files did not get removed when the module was removed. I simple read of one of those file can oops the kernel because the operations to the file no longer exist (removed by module). The funny thing is that the file being cat'ed was removed. It was the siblings that were not. I see in the code to debugfs_remove_recursive there's a test that checks if the child fails to bail out of the loop to prevent an infinite loop. What this patch does is to still try any siblings in that directory. If all the siblings fail, or there are no more siblings, then we exit the loop. This fixes the above symptom, but... This is no full proof. It makes the debugfs_remove_recursive a bit more robust, but it does not explain why the one file failed. There may be some kind of delay deletion that makes the debugfs think it did not succeed. So this patch is more of a fix for the symptom but not the disease. This patch still makes the debugfs_remove_recursive more robust and until I can find out why the bug exists, this patch will keep the kernel from oopsing in most cases. Even after the cause is found I think this change can stand on its own and should be kept. [ Impact: prevent kernel oops on module unload and reading debugfs files ] Signed-off-by:
Steven Rostedt <rostedt@goodmis.org> Signed-off-by:
-
