If we call ieee80211_hw_restart, it means that the
firmware is in bad condition and will be reset soon.
Since the firmware will be reset, there is no good
reason to keep sending host commands.
Signed-off-by: Alexander Bondar <alexander.bondar@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
A new firmware is coming out soon with new APIs.
To make sure that this new firmware won't be loaded on old
driver that don't support it, it's API version has been
updated to 8. In order to be able to load it, bump the API
version to 8.
API version 7 is still supported and will be for another
year or so.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Time event notification can have a failure status even if
the time event was scheduled:
* in START notification, this can happen if the time event
was scheduled later than the requested apply time.
* in STOP notification, this can happen if the time event
is truncated.
Even if both happened, the offchannel packets sent during
the remain on channel are very likely to have been sent.
Hence, don't WARN when this happens, but rather print a
discrete line in the kernel log.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
This patch is very similar to a previous fix: 22cba0c085
When we disassociate, mac80211 removes the station and
then, it sets the bss it unsets the assoc bool in bss_info.
Since the firwmware wants it the opposite (first set the
MAC context as unassoc, and only then, remove the STA of
the API), we have a small period of time in which the STA
in firmware doesn't have a valid ieee80211_sta pointer.
During that time, iwl_mvm_vif->ap_sta_id, is still set
to the STA in firmware that represent the AP.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
This feature isn't supported by the firmware (yet).
Note that settingt he values to BT_CFG_CMD is harmless if
the validity bit is clear - so keep the configuration
values in BT_CFG_CMD, but clear the validity bit until thes
feature is enabled in the firmware.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
We changed the timeout for the interrupt coealescing for
calibration, but that wasn't effective since we changed
that value back before loading the firmware. Since
calibrations are notification from firmware and not Rx
packets, this doesn't change anyway - the firmware will
fire an interrupt straight away regardless of the interrupt
coalescing value.
Also, a HW issue has been discovered in 7000 devices series.
The work around is to disable the new interrupt coalescing
timeout feature - do this by setting bit 31 in
CSR_INT_COALESCING.
This has been fixed in 7265 which means that we can't rely
on the device family and must have a hint in the iwl_cfg
structure.
Cc: stable@vger.kernel.org [3.10+]
Fixes: 99cd471423 ("iwlwifi: add 7000 series device configuration")
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
The station ID must be valid, if it's out of range then
the array access may crash. Validate the station ID to
the array length, and also validate the drain value even
if that doesn't matter all that much.
Cc: stable@vger.kernel.org
Fixes: 8ca151b568 ("iwlwifi: add the MVM driver")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
zsmalloc encodes a handle using the pfn and an object
index. On hardware platforms with physical memory starting
at 0x0 the pfn can be 0. This causes the encoded handle to be
0 and is incorrectly interpreted as an allocation failure.
This issue affects all current and future SoCs with physical
memory starting at 0x0. All MSM8974 SoCs which includes
Google Nexus 5 devices are affected.
To prevent this false error we ensure that the encoded handle
will not be 0 when allocation succeeds.
Signed-off-by: Olav Haugan <ohaugan@codeaurora.org>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jonathan writes:
First round of fixes for IIO in the 3.13 cycle.
The usual mixed bag of fixes.
* 3 cases where kconfig dependencies were missing. We need to keep a closer
eye on this in new drivers.
* hid_sensors was abusing the iio_dev->trigger pointer. We had a round
of clearing this out some time ago but this driver clearly slipped through.
* A misuse of the IIO_ST macro, in mcp3422, which we should really make a
concertive effort to finish removing.
* Avoid a double free introduced by recent buffer reference counting in the
one driver that (quite reasonably!) does things differently (am335x)
* A missing mutex_unlock in kxsd9 that means that driver has been non
functional for some time and no one noticed (including me who for once
actually has one of the supported devices).
* An incorrect assumption about the parameters of sign_extend32 in mcp3422.
So nothing controversial. The only substantial patch is the hid_sensors
one and that is actually just adding a new pointer to the devices private
state then moving the code over to it.
Pull regulator fixes from Mark Brown:
"A bunch of fixes, a few driver specific ones and a framework fix for
voltage enumeration on fixed voltage regulators which had previously
worked but had been misplaced during some refactoring causing problems
for users that needed to know the voltage"
* tag 'regulator-v3.13-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator:
regulator: arizona-micsupp: Correct wm5110 voltage selection
regulator: pfuze100: allow misprogrammed ID
regulator: fixed: fix regulator_list_voltage() for regression
regulator: gpio-regulator: Don't oops on missing regulator-type property
The number of bytes transmitted was not updated correctly, if several CAN
messages (with different length) were transmitted in one 'bunch'. Thus
programs like 'ifconfig' showed wrong transmit byte counts. Reason was, that
the message object whose DLC is to be read was not necessarily the active one
at the time when
priv->read_reg(priv, C_CAN_IFACE(MSGCTRL_REG, 0)) & IF_MCONT_DLC_MASK;
was executed.
Signed-off-by: Holger Bechtold <Holger.Bechtold@gmx.net>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
The c_can driver contians a callpath (c_can_poll -> c_can_state_change ->
c_can_get_berr_counter) which may call pm_runtime_get_sync() from the IRQ
handler, which is not allowed and results in "BUG: scheduling while atomic".
This problem is fixed by introducing __c_can_get_berr_counter, which will not
call pm_runtime_get_sync().
Reported-by: Andrew Glen <AGlen@bepmarine.com>
Tested-by: Andrew Glen <AGlen@bepmarine.com>
Signed-off-by: Andrew Glen <AGlen@bepmarine.com>
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
When building randconfigs with CONFIG_BCMA_DRIVER_GPIO=y, I get
drivers/built-in.o: In function `brcms_led_unregister':
(.text+0x351aca): undefined reference to `led_classdev_unregister'
drivers/built-in.o: In function `brcms_led_register':
(.text+0x351c65): undefined reference to `led_classdev_register'
during final linking stage because brcmsmac/led.c needs LEDS_CLASS for
registering/deregistering the led device. Select the required symbols.
Cc: Arend van Spriel <arend@broadcom.com>
Cc: "Rafał Miłecki" <zajec5@gmail.com>
Cc: <linux-wireless@vger.kernel.org>
Signed-off-by: Borislav Petkov <bp@suse.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
There are still many rts5208/5288 card readers being used, but no
drivers are supported them in kernel now. This driver can make a
great convenience for people who use them.
Many other rts-series card reader are supported by mfd driver, but due
to much difference with others, rts5208/5288 can not add into mfd driver
pretty now, so we provide a separated driver here to support the device.
Signed-off-by: Micky Ching <micky_ching@realsil.com.cn>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The return variable of request_code_segment() is used uninitialized if
the argument boot_case is false, this patch fixes it.
FYI, in ft1000_usb.h: STATUS_SUCCESS 0, and STATUS_FAILURE 0x1001.
Signed-off-by: Adam Lee <adam8157@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Merge structures typedef struct tagSTxShortBufHead and the members of
struct vnt_tx_datahead_ab to form single structure vnt_tx_short_buf_head.
Remove the duplicate members in struct vnt_beacon_buffer already in
typedef struct tagSTxShortBufHead.
This removes the need for any pointer arithmetic.
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Error handling code in gdm_usb_probe() deallocates all resources,
but calls usb_get_dev(usbdev) and returns error code after that.
The patch fixes it and, by the way, several other issues:
- no need to use GFP_ATOMIC in probe();
- return -ENODEV instead of -1;
- kmalloc+memset -> kzalloc
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch fixes the issue that the sja1000_interrupt() function may have
returned IRQ_NONE without processing the optional pre_irq() and post_irq()
function before. Further the irq processing counter 'n' is moved to the end of
the while statement to return correct IRQ_[NONE|HANDLED] values at error
conditions.
Reported-by: Wolfgang Grandegger <wg@grandegger.com>
Acked-by: Wolfgang Grandegger <wg@grandegger.com>
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
drivers/staging/btmtk_usb/btmtk_usb.c: In function ‘btmtk_usb_probe’:
drivers/staging/btmtk_usb/btmtk_usb.c:1610: warning: assignment from incompatible pointer type
Add the new hdev parameter, cfr. commit
7bd8f09f69 ("Bluetooth: Add hdev parameter to
hdev->send driver callback").
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Remove #ifdef DEBUG from a couple of places where it is not needed
Signed-off-by: Paul Zimmerman <paulz@synopsys.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Rename dwc2_check_core_status() to dwc2_is_controller_alive(), and
make it a boolean function. Also change the message when the
controller is dead to say "dead" instead of "disconnected".
Signed-off-by: Paul Zimmerman <paulz@synopsys.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
NO_FS_PHY_HW_CHECKS is never defined, so remove the conditional
code that checks for it being set
Signed-off-by: Paul Zimmerman <paulz@synopsys.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
We were not checking the return value from any of these functions,
so make them void functions
Signed-off-by: Paul Zimmerman <paulz@synopsys.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
DWC2_PARAM_TEST is not a very good name for this macro, so rename
it to DWC2_OUT_OF_BOUNDS
Signed-off-by: Paul Zimmerman <paulz@synopsys.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
dwc2_process_non_isoc_desc() can potentially free the qtd, so null
out the qtd pointer if the call fails so we don't try to access it
later
Signed-off-by: Paul Zimmerman <paulz@synopsys.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fix some functions called by dwc2_hcd_qtd_add() to return either
a proper error code or 0, instead of somewhat random values.
Then change the caller of dwc2_hcd_qtd_add() to just check the
return value for 0.
Signed-off-by: Paul Zimmerman <paulz@synopsys.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
If the GRSTCTL_CSFTRST self-clearing bit never comes
back to 0 for any reason, the controller is under reset
state and cannot be used. It's preferable to abort
initialization in such case.
Signed-off-by: Julien Delacou <julien.delacou@st.com>
Acked-by: Paul Zimmerman <paulz@synopsys.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Pending interrupts clearing is done in dwc2_enable_common_interrupts
so we don't need to do it twice.
Signed-off-by: Julien Delacou <julien.delacou@st.com>
Acked-by: Paul Zimmerman <paulz@synopsys.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
