After commit b2b49ccbdd (PM: Kconfig: Set PM_RUNTIME if PM_SLEEP is
selected) PM_RUNTIME is always set if PM is set, so #ifdef blocks
depending on CONFIG_PM_RUNTIME within #ifdef blocks depending on
CONFIG_PM may be dropped now.
Do that in the e1000e and igb network drivers.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
After commit b2b49ccbdd (PM: Kconfig: Set PM_RUNTIME if PM_SLEEP is
selected) PM_RUNTIME is always set if PM is set, so #ifdef blocks
depending on CONFIG_PM_RUNTIME may now be changed to depend on
CONFIG_PM.
Replace CONFIG_PM_RUNTIME with CONFIG_PM everywhere under
drivers/mmc/.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
After commit b2b49ccbdd (PM: Kconfig: Set PM_RUNTIME if PM_SLEEP is
selected) PM_RUNTIME is always set if PM is set, so #ifdef blocks
depending on CONFIG_PM_RUNTIME may now be changed to depend on
CONFIG_PM.
Replace CONFIG_PM_RUNTIME with CONFIG_PM everywhere under
drivers/mfd/.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Lee Jones <lee.jones@linaro.org>
After commit b2b49ccbdd (PM: Kconfig: Set PM_RUNTIME if PM_SLEEP is
selected) PM_RUNTIME is always set if PM is set, so #ifdef blocks
depending on CONFIG_PM_RUNTIME may now be changed to depend on
CONFIG_PM.
Replace CONFIG_PM_RUNTIME with CONFIG_PM everywhere under
drivers/misc/.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
After commit b2b49ccbdd (PM: Kconfig: Set PM_RUNTIME if PM_SLEEP is
selected) PM_RUNTIME is always set if PM is set, so #ifdef blocks
depending on CONFIG_PM_RUNTIME may now be changed to depend on
CONFIG_PM.
The alternative of CONFIG_PM_SLEEP and CONFIG_PM_RUNTIME may be
replaced with CONFIG_PM too.
Make these changes everywhere under drivers/media/.
Acked-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
Acked-by: Kamil Debski <k.debski@samsung.com>
Acked-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
After commit b2b49ccbdd (PM: Kconfig: Set PM_RUNTIME if PM_SLEEP is
selected) PM_RUNTIME is always set if PM is set, so #ifdef blocks
depending on CONFIG_PM_RUNTIME may now be changed to depend on
CONFIG_PM.
The alternative of CONFIG_PM_SLEEP and CONFIG_PM_RUNTIME may be
replaced with CONFIG_PM too.
Make these changes in 2 files under drivers/input/.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Jingoo Han <jg1.han@samsung.com>
Reviewed-by: Ferruh Yigit <fery@cypress.com>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Pull ACPI backlight fix from Rafael Wysocki:
"This is a simple fix for an ACPI backlight regression introduced by a
recent commit that overlooked a corner case which should have been
taken into account"
* tag 'pm+acpi-3.18-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
ACPI / video: update condition to check if device is in _DOD list
Silence some pch fifo underrun reports and panel locking backtraces,
both cc: stable.
* tag 'drm-intel-fixes-2014-12-04' of git://anongit.freedesktop.org/drm-intel:
drm/i915: Unlock panel even when LVDS is disabled
drm/i915: More cautious with pch fifo underruns
Fixes for 3.20. I did stick the gen3/4 reset work from Ville in because we
have an awful lot of gen4 mesa hangs, and with this reset should also work
on vintage i965g/gm (we already have reset for g4x/gen4.5). So should help
to appease users suffering from these hangs. Otherwise all over.
This is the last 3.20 pull from me, from here on Jani will take over. By Ville Syrjälä (8) and others
* tag 'drm-intel-next-fixes-2014-12-04' of git://anongit.freedesktop.org/drm-intel:
drm/i915: Reject modeset when the same digital port is used more than once
drm/i915: mask RPS IRQs properly when disabling RPS
drm/i915: Tune down spurious CRC interrupt warning
drm/i915: Fix context object leak for legacy contexts
drm/i915/skl: Update in Gen9 multi-engine forcewake range
drm/i915/eDP: When enabling panel VDD cancel pending disable worker
drm/i915: Handle runtime pm in the CRC setup code
drm/i915: Disable crtcs gracefully before GPU reset on gen3/4
drm/i915: Grab modeset locks for GPU rest on pre-ctg
drm/i915: Implement GPU reset for g33
drm/i915: Implement GPU reset for 915/945
drm/i915: Restore the display config after a GPU reset on gen4
drm/i915: Fix gen4 GPU reset
drm/i915: Stop gathering error states for CS error interrupts
drm/i915: Disallow pin ioctl completely for kms drivers
drm/i915: Only warn the first time we attempt to mmio whilst suspended
drm/i915/chv: Enable AVI, SPD and HDMI infoframes for CHV.
drm/i915: Don't clobber crtc->new_config when nothing changes
Just three more fixes for 3.19.
This is the last request until -rc1. I will have our QA team run a full
HSA stack test on 3.19-rc1 and if we find problems, I will send a fixes pull
request.
* 'amdkfd-next-3.19' of git://people.freedesktop.org/~gabbayo/linux:
amdkfd: Set *buffer_ptr to NULL in case of error
amdkfd: use atomic allocations within srcu callbacks
amdkfd: use sizeof(long) granularity for the pasid bitmask
Pull media fixes from Mauro Carvalho Chehab:
"A core fix and some driver fixes:
- regression fix in Remote Controller core affecting RC6 protocol
handling
- fix video buffer handling in cx23885
- race fix in solo6x10
- fix image selection in smiapp
- fix reported payload size on s2255drv
- two updates for MAINTAINERS file"
* tag 'media/v3.18-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media:
[media] rc-core: fix toggle handling in the rc6 decoder
MAINTAINERS: Update mchehab's addresses
[media] cx23885: use sg = sg_next(sg) instead of sg++
[media] s2255drv: fix payload size for JPG, MJPEG
[media] Update MAINTAINERS for solo6x10
[media] solo6x10: fix a race in IRQ handler
[media] smiapp: Only some selection targets are settable
After freeing pin from regulator_ena_gpio_free, loop can access
the pin. So this patch fixes not to access pin after freeing.
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Since commit c592becbe7 ("spi: fsl-(e)spi: migrate to generic master
queueing") the function fsl_spi_do_one_msg() is not void anymore, so return
an error code to avoid the following buid warning:
drivers/spi/spi-fsl-spi.c: In function 'fsl_spi_do_one_msg':
>> drivers/spi/spi-fsl-spi.c:374:4: warning: 'return' with no value, in function returning non-void [-Wreturn-type]
return;
^
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
kthread_run() could return ERR_PTR(-EINTR) from kthread_create_on_node().
Return the actual error code in spi_init_queue() instead of mangling it to
-ENOMEM.
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Poweroff the fans when shutting down the system. Else,
echo '1' > /sys/class/hwmon/hwmon0/fan1_target; poweroff leaves the
fan running if the System power off does not drive the gpio expander
which might control the fan power supply.
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Certain I2C based GPIO expanders could be used in sleepable context,
this results in:
[ 115.890569] ------------[ cut here ]------------
[ 115.895422] WARNING: CPU: 0 PID: 1115 at drivers/gpio/gpiolib.c:1370 gpiod_set_raw_value+0x40/0x4c()
[ 115.905024] Modules linked in:
[ 115.908229] CPU: 0 PID: 1115 Comm: sh Tainted: G W 3.18.0-rc7-next-20141203-dirty #1
[ 115.917461] Hardware name: Generic DRA74X (Flattened Device Tree)
[ 115.923876] [<c0015368>] (unwind_backtrace) from [<c00119f4>] (show_stack+0x10/0x14)
[ 115.932013] [<c00119f4>] (show_stack) from [<c05b78e8>] (dump_stack+0x78/0x94)
[ 115.939594] [<c05b78e8>] (dump_stack) from [<c003de28>] (warn_slowpath_common+0x7c/0xb4)
[ 115.948094] [<c003de28>] (warn_slowpath_common) from [<c003de7c>] (warn_slowpath_null+0x1c/0x24)
[ 115.957315] [<c003de7c>] (warn_slowpath_null) from [<c03461e8>] (gpiod_set_raw_value+0x40/0x4c)
[ 115.966457] [<c03461e8>] (gpiod_set_raw_value) from [<c04866f4>] (set_fan_speed+0x4c/0x64)
[ 115.975145] [<c04866f4>] (set_fan_speed) from [<c04868a8>] (set_rpm+0x98/0xac)
[ 115.982742] [<c04868a8>] (set_rpm) from [<c039fb4c>] (dev_attr_store+0x18/0x24)
[ 115.990426] [<c039fb4c>] (dev_attr_store) from [<c01b0a28>] (sysfs_kf_write+0x4c/0x50)
[ 115.998742] [<c01b0a28>] (sysfs_kf_write) from [<c01afe1c>] (kernfs_fop_write+0xbc/0x19c)
[ 116.007333] [<c01afe1c>] (kernfs_fop_write) from [<c0148cc4>] (vfs_write+0xb0/0x1a0)
[ 116.015461] [<c0148cc4>] (vfs_write) from [<c0148fbc>] (SyS_write+0x44/0x84)
[ 116.022881] [<c0148fbc>] (SyS_write) from [<c000e5c0>] (ret_fast_syscall+0x0/0x48)
[ 116.030833] ---[ end trace 3a0b636123acab82 ]---
So, switch over to sleepable GPIO operations as there is no mandatory
need for non-sleepable gpio operations in the fan driver.
This allows the fan driver to be used with i2c based gpio expanders such
as palmas_gpio.
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The return value of i2c_smbus_read_byte_data() is checked in
tmp401_init_client(), but only a warning is printed and the device is
registered anyway. This leads to devices being registered even if they
cannot be physically detected.
Bail out from probe in case of write errors and notify the user.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Cadence I2C controller has bug wherein it generates invalid read transactions
after timeout in master receiver mode. This driver does not use the HW
timeout and this interrupt is disabled but the feature itself cannot be
disabled. Hence, this patch writes the maximum value (0xFF) to this register.
This is one of the workarounds to this bug and it will not avoid the issue
completely but reduces the chances of error.
Signed-off-by: Vishnu Motghare <vishnum@xilinx.com>
Signed-off-by: Harini Katakam <harinik@xilinx.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Cc: stable@kernel.org
According to I2C specification the NACK should be handled as follows:
"When SDA remains HIGH during this ninth clock pulse, this is defined as the Not
Acknowledge signal. The master can then generate either a STOP condition to
abort the transfer, or a repeated START condition to start a new transfer."
[I2C spec Rev. 6, 3.1.6: http://www.nxp.com/documents/user_manual/UM10204.pdf]
Currently the Davinci i2c driver interrupts the transfer on receipt of a
NACK but fails to send a STOP in some situations and so makes the bus
stuck until next I2C IP reset (idle/enable).
For example, the issue will happen during SMBus read transfer which
consists from two i2c messages write command/address and read data:
S Slave Address Wr A Command Code A Sr Slave Address Rd A D1..Dn A P
<--- write -----------------------> <--- read --------------------->
The I2C client device will send NACK if it can't recognize "Command Code"
and it's expected from I2C master to generate STP in this case.
But now, Davinci i2C driver will just exit with -EREMOTEIO and STP will
not be generated.
Hence, fix it by generating Stop condition (STP) always when NACK is received.
This patch fixes Davinci I2C in the same way it was done for OMAP I2C
commit cda2109a26 ("i2c: omap: query STP always when NACK is received").
Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reported-by: Hein Tibosch <hein_tibosch@yahoo.es>
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Cc: stable@kernel.org
Switch Davinci I2C driver to use platform_get_irq(), because
it is not recommened to use platform_get_resource(pdev, IORESOURCE_IRQ, ..)
for requesting IRQ resources any more, as they can be not ready yet
in case of DT-boot.
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Pull "Fifth batch of cleanup/SoC for 3.19" from Nicolas Ferre:
- removal of now dead code and AT91-specific driver
- removal of !DT initialization in some core AT91 drivers
- simplification of Kconfig DT board file selection: now automatic
* tag 'at91-cleanup5' of git://git.kernel.org/pub/scm/linux/kernel/git/nferre/linux-at91:
ARM: at91: remove unused board.h file
ARM: at91: remove unneeded header files
ARM: at91/clocksource: remove !DT PIT initializations
ARM: at91: at91rm9200 ST initialization is now DT only
ARM: at91: remove old AT91-specific drivers
ARM: at91: cleanup initilisation code by removing dead code
ARM: at91/Kconfig: select board files automatically
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
The release_firmware() function was called by the mn88473_init() function even
if a previous function call "request_firmware" failed.
This implementation detail could be improved by the introduction of another
jump label.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
The release_firmware() function tests whether its argument is NULL and then
returns immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Remove the FIXME comment in atapi_request_sense() asking whether
memset of sense buffer is necessary. The buffer may be partially or
fully filled by the device. We want it to be cleared.
tj: Updated description.
Signed-off-by: Nicholas Krause <xerofoify@gmail.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
We can simply pass the pointer to the private structure to the irq
routine instead of passing the platform device and looking up its
driver_data.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
The vfree() function performs also input parameter validation. Thus the test
around the call is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
The ImgTec Infrared decoder block which img-ir drives is only used in
IMGWorks SoCs so far, such as the TZ1090 (Meta based) and the upcoming
Pistachio (MIPS based). Therefore make the driver depend on METAG (for
TZ1090) or MIPS (for Pistachio) or COMPILE_TEST (so that it is included
in x86 allmodconfig builds), to avoid cluttering the Kconfig menu with
drivers for hardware that isn't yet available on other platforms.
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
The img_ir_register_decoder() and img_ir_unregister_decoder() functions
were dropped prior to the img-ir driver being applied to simplify the
protocol decoder setup. However the declarations of these functions in
img-ir-hw.h were still included. Delete them since they're completely
unused.
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
The end timer is used for switching back from repeat code timings when
no repeat codes have been received for a certain amount of time. When
the protocol is changed, the end timer is deleted synchronously with
del_timer_sync(), however this takes place while holding the main spin
lock, and the timer handler also needs to acquire the spin lock.
This opens the possibility of a deadlock on an SMP system if the
protocol is changed just as the repeat timer is expiring. One CPU could
end up in img_ir_set_decoder() holding the lock and waiting for the end
timer to complete, while the other CPU is stuck in the timer handler
spinning on the lock held by the first CPU.
Lockdep also spots a possible lock inversion in the same code, since
img_ir_set_decoder() acquires the img-ir lock before the timer lock, but
the timer handler will try and acquire them the other way around:
=========================================================
[ INFO: possible irq lock inversion dependency detected ]
3.18.0-rc5+ #957 Not tainted
---------------------------------------------------------
swapper/0/0 just changed the state of lock:
(((&hw->end_timer))){+.-...}, at: [<4006ae5c>] _call_timer_fn+0x0/0xfc
but this lock was taken by another, HARDIRQ-safe lock in the past:
(&(&priv->lock)->rlock#2){-.....}
and interrupts could create inverse lock ordering between them.
other info that might help us debug this:
Possible interrupt unsafe locking scenario:
CPU0 CPU1
---- ----
lock(((&hw->end_timer)));
local_irq_disable();
lock(&(&priv->lock)->rlock#2);
lock(((&hw->end_timer)));
<Interrupt>
lock(&(&priv->lock)->rlock#2);
*** DEADLOCK ***
This is fixed by releasing the main spin lock while performing the
del_timer_sync() call. The timer is prevented from restarting before the
lock is reacquired by a new "stopping" flag which img_ir_handle_data()
checks before updating the timer.
---------------------------------------------------------
swapper/0/0 just changed the state of lock:
(((&hw->end_timer))){+.-...}, at: [<4006ae5c>] _call_timer_fn+0x0/0xfc
but this lock was taken by another, HARDIRQ-safe lock in the past:
(&(&priv->lock)->rlock#2){-.....}
and interrupts could create inverse lock ordering between them.
other info that might help us debug this:
Possible interrupt unsafe locking scenario:
CPU0 CPU1
---- ----
lock(((&hw->end_timer)));
local_irq_disable();
lock(&(&priv->lock)->rlock#2);
lock(((&hw->end_timer)));
<Interrupt>
lock(&(&priv->lock)->rlock#2);
*** DEADLOCK ***
This is fixed by releasing the main spin lock while performing the
del_timer_sync() call. The timer is prevented from restarting before the
lock is reacquired by a new "stopping" flag which img_ir_handle_data()
checks before updating the timer.
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: Sifan Naeem <sifan.naeem@imgtec.com>
Cc: <stable@vger.kernel.org> # v3.15+
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
A problem was found on Polaris where if the unit it booted via the power
button on the infrared remote then the next button press on the remote
would return the key code used to power on the unit.
The sequence is:
- The polaris powered off but with the powerdown controller (PDC) block
still powered.
- Press power key on remote, IR block receives the key.
- Kernel starts, IR code is in IMG_IR_DATA_x but neither IMG_IR_RXDVAL
or IMG_IR_RXDVALD2 are set.
- Wait any amount of time.
- Press any key.
- IMG_IR_RXDVAL or IMG_IR_RXDVALD2 is set but IMG_IR_DATA_x is
unchanged since the powerup key data was never read.
This is worked around by always reading the IMG_IR_DATA_x in
img_ir_set_decoder(), rather than only when the IMG_IR_RXDVAL or
IMG_IR_RXDVALD2 bit is set.
Signed-off-by: Dylan Rajaratnam <dylan.rajaratnam@imgtec.com>
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: <stable@vger.kernel.org> # v3.15+
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
The dvb_unregister_device() function tests whether its argument is NULL
and then returns immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
The release_firmware() function was called in some cases by the si2157_init()
function during error handling even if the passed variable contained still
a null pointer. This implementation detail could be improved
by the introduction of another jump label.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
The release_firmware() function tests whether its argument is NULL
and then returns immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
As pointed by smatch:
drivers/media/dvb-frontends/stv090x.c:2787 stv090x_optimize_carloop() error: buffer overflow 'car_loop_apsk_low' 11 <= 13
drivers/media/dvb-frontends/stv090x.c:2789 stv090x_optimize_carloop() error: buffer overflow 'car_loop_apsk_low' 11 <= 13
drivers/media/dvb-frontends/stv090x.c:2791 stv090x_optimize_carloop() error: buffer overflow 'car_loop_apsk_low' 11 <= 13
drivers/media/dvb-frontends/stv090x.c:2793 stv090x_optimize_carloop() error: buffer overflow 'car_loop_apsk_low' 11 <= 13
drivers/media/dvb-frontends/stv090x.c:2795 stv090x_optimize_carloop() error: buffer overflow 'car_loop_apsk_low' 11 <= 13
The situation of a buffer overflow won't happen, in practice,
with the current values of car_loop table. Yet, the entire logic
that checks for those registration values is too complex. So,
better to add an explicit check, just in case someone changes
the car_loop tables causing a buffer overflow by mistake.
This also helps to remove several smatch warnings, with is good.
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
if STV090x_RANGEOK is not returned, then STV090x_OUTOFRANGE
is returned. However, that part of the code is never reached,
as pointed by smatch:
drivers/media/dvb-frontends/stv090x.c:2673 stv090x_get_sig_params() info: ignoring unreachable code.
So, remove the two uneeded elses, with makes the code a little bit
cleaner.
No functional changes, and one less smatch warning.
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
This patch adds support for multiple BSS interfaces (AP). In
total three AP configurations can be created. In order to use
multiple BSS firmware needs to support it.
Reviewed-by: Arend Van Spriel <arend@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: Hante Meuleman <meuleman@broadcom.com>
Signed-off-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Some 43602 devices are band specific and identify themselves
with different PCIE device ID. This patch adds support for the
43602 2.4G and 5.0G devices used in for example R8000 router.
Reviewed-by: Arend Van Spriel <arend@broadcom.com>
Reviewed-by: Franky (Zhenhui) Lin <frankyl@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
Reviewed-by: Daniel (Deognyoun) Kim <dekim@broadcom.com>
Signed-off-by: Hante Meuleman <meuleman@broadcom.com>
Signed-off-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Wake On Lan was not working on laptop DELL Vostro 1500.
If WOL was turned on, BCM4401 was powered up in suspend mode. LEDs blinked.
But the laptop could not be woken up with the Magic Packet. The reason for
that was that PCIE was not enabled as a system wakeup source and
therefore the host PCI bridge was not powered up in suspend mode.
PCIE was not enabled in suspend by PM because no child devices were
registered as wakeup source during suspend process.
On laptop BCM4401 is connected through the SSB bus, that is connected to the
PCI-Express bus. SSB and B44 did not use standard PM wakeup functions
and did not forward wakeup settings to their parents.
To fix that B44 driver enables PM wakeup and registers new wakeup source
using device_set_wakeup_enable(). Wakeup is automatically reported to the parent SSB
bus via power.wakeup_path. SSB bus enables wakeup for the parent PCI bridge, if there is any
child devices with enabled wakeup functionality. All other steps are
done by PM core code.
Signed-off-by: Andrey Skvortsov <Andrej.Skvortzov@gmail.com>
Signed-off-by: Michael Buesch <m@bues.ch>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Johannes Berg <johannes@sipsolutions.net> says:
"This time I have Felix's no-status rate control work, which will allow
drivers to work better with rate control even if they don't have perfect
status reporting. In addition to this, a small hwsim fix from Patrik,
one of the regulatory patches from Arik, and a number of cleanups and
fixes I did myself.
Of note is a patch where I disable CFG80211_WEXT so that compatibility
is no longer selectable - this is intended as a wake-up call for anyone
who's still using it, and is still easily worked around (it's a one-line
patch) before we fully remove the code as well in the future."
Signed-off-by: John W. Linville <linville@tuxdriver.com>
