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 <gregkh@suse.de>
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 <gregkh@suse.de>
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 <gregkh@suse.de>
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 <gregkh@suse.de>
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 <gregkh@suse.de>
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 <gregkh@suse.de>
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 <gregkh@suse.de>
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 <gregkh@suse.de>
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: Kristian Hoegsberg <krh@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
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: Greg Kroah-Hartman <gregkh@suse.de>
This adds support to the AOE core to report the proper device name to
userspace for the AOE devices.
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>
This adds support to the drm core to report the proper device name to
userspace for the drm devices.
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>
This adds support to the raw driver to report the proper device name to
userspace for the raw devices.
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>
This adds support to the input core to report the proper device name to
userspace for their devices.
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>
This adds support to the dvb core to report the proper device name to
userspace for their devices.
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>
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 <kay.sievers@vrfy.org>
Signed-off-by: Jan Blunck <jblunck@suse.de>
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>
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 <kay.sievers@vrfy.org>
Signed-off-by: Jan Blunck <jblunck@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
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: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Jan Blunck <jblunck@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
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 <gregkh@suse.de>
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 <sameo@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
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 <sameo@linux.intel.com>
Cc: Dominik Brodowski <linux@dominikbrodowski.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
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: Samuel Ortiz <sameo@linux.intel.com>
Reviewed-by: Michael Krufky <mkrufky@kernellabs.com>
Cc: Mauro Carvalho Chehab <mchehab@infradead.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
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 <sameo@linux.intel.com>
Cc: Mauro Carvalho Chehab <mchehab@infradead.org>
Cc: Michel Ludwig <michel.ludwig@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
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 <sameo@linux.intel.com>
Cc: Damien Bergamini <damien.bergamini@free.fr>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
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: Samuel Ortiz <sameo@linux.intel.com>
Cc: Marcel Holtmann <holtmann@linux.intel.com>
Cc: Zhu Yi <yi.zhu@intel.com>,
Cc: John Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
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: Greg Kroah-Hartman <gregkh@suse.de>
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: Greg Kroah-Hartman <gregkh@suse.de>
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: Greg Kroah-Hartman <gregkh@suse.de>
This converts resource and IRQ getbyname functions for the platform
bus to use const char *, I ran into compiler moanings when I tried
using a const char * for looking up a certain resource.
Signed-off-by: Linus Walleij <linus.walleij@stericsson.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch adds a new bus notifier event which is emitted _after_ a
device is removed from its driver. This event will be used by the
dma-api debug code to check if a driver has released all dma allocations
for that device.
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
If we are in PS mode, we have to process the received frame if
the SC_OP_WAIT_FOR_CAB bit is set.
Changes-licensed-under: ISC
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We have to remain awake if the SC_OP_WAIT_FOR_CAB flag is set.
Changes-licensed-under: ISC
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The ath9k_ps_{wakeup,restore} calls must be in balance.
Changes-licensed-under: ISC
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
A polarity error snuck into the rfkill rewrite's dell-laptop
conversion, fix it.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Tested-by: Oliver Hartkopp <oliver@hartkopp.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This ports the ath9k rfkill code to the new API offered by
cfg80211 and thus removes a lot of useless stuff.
("With this series a kernel panic, which is a regression, during module
unload disappears." -- Vasanthakumar Thiagarajan <vasanth@atheros.com>
Other patches in the series:
ath9k: Add helper to get ath9k specific current channel
ath9k: Make sure we have current channel in ah_curchan before rf
disable/enable
-- JWL)
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Cc: Luis Rodriguez <mcgrof@gmail.com>
Tested-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch is from Nick Kossifidis but he forgot to send it. It ensures
that the beacon queue gets started in mesh mode as well, otherwise ath5k
will not beacon in mesh point mode.
At this time, we still need to issue a scan before mesh beaconing will
work but that appears to be a separate problem.
Signed-off-by: Andrey Yurovsky <andrey@cozybit.com>
Signed-off-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Patch fixes the following bugs at
http://www.intellinuxwireless.org/bugzilla/show_bug.cgi?id=2005http://www.intellinuxwireless.org/bugzilla/show_bug.cgi?id=2007
If we suspend with an association and then resumed,
we need to synchronize the active rxon with staging rxon,
else we will get an error when iwl_alive_start try to commit
rxon and staging is set to channel 0. Before going to suspend
staging and active rxon are in sync. After resuming from the
suspend, iwl_mac_start is called and it clears the staging
rxon. Patch fixes the bug by not clearing the staging rxon
in iwl_mac_start.
Patch also adds similar fix to 3945.
Signed-off-by: Abhijeet Kolekar <abhijeet.kolekar@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
for both mixed and pure 40MHz, need to check for valid channel location.
if the specified channel not allow the channel location requested
(ABOVE, BELOW), then reject the Fat channel access
This fixes http://www.intellinuxwireless.org/bugzilla/show_bug.cgi?id=1988
("iwlwifi: checking for 40MHz mode" and "iwlwifi: check control channel
for pure 40MHz" combine with this to address the above bug. -- JWL)
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
for pure 40MHz mode, set the control channel location if provided, but not
like Mixed mode; if information is not provided, still allow 40MHz
operation.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
when checking for 40MHz, compare ht_protection to
IEEE80211_HT_OP_MODE_PROTECTION_20MHZ. ht_protection is not a bit-mask
field
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
My earlier patch,
"mac80211: unify config_interface and bss_info_changed"
introduced a bug in iwlwifi where it will do some things
incorrectly now when reassociating.
Revamp iwl_bss_info_changed to fix that issue and make it
easier to read. Also, while at it, add comments about things
that it should do but currently doesn't.
Finally, also improve the locking in the function.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The card firmware does not set the Command Download Ready interrupt bit
when IEEE PS mode is enabled, preventing the driver from sending
commands (such as the command to exit IEEE PS mode) since there is no
indication that the card is ready to accept commands.
This patch works around the problem by using the the TX Download Ready
bit in place of the Command Download Ready Bit while in IEEE PS mode.
TX Download Ready is set in IEEE PS mode.
Signed-off-by: Andrey Yurovsky <andrey@cozybit.com>
Signed-off-by: Javier Cardona <javier@cozybit.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When the hard state changes, we shouldn't set the soft
state to blocked as well -- we have no such indication
from the device in that case so leave it untouched.
Fixes http://bugzilla.kernel.org/show_bug.cgi?id=13458.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Reported-by: Reinette Chatre <reinette.chatre@intel.com>
Tested-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
