Age | Commit message (Collapse) | Author | Files | Lines |
|
Obviously this driver version doesn't make sense. Go with the default
and let ethtool display the kernel version.
Signed-off-by: Heiner Kallweit <[email protected]>
Reviewed-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
Make use of the new struct_size() helper instead of the offsetof() idiom.
Signed-off-by: Gustavo A. R. Silva <[email protected]>
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can
====================
linux-can-fixes-for-5.9-20201008
The first patch is by Lucas Stach and fixes m_can driver by removing an
erroneous call to m_can_class_suspend() in runtime suspend. Which causes the
pinctrl state to get stuck on the "sleep" state, which breaks all CAN
functionality on SoCs where this state is defined.
The last two patches target the j1939 protocol: Cong Wang fixes a syzbot
finding of an uninitialized variable in the j1939 transport protocol. I
contribute a patch, that fixes the initialization of a same uninitialized
variable in a different function.
====================
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next
Kalle Valo says:
====================
wireless-drivers-next patches for v5.10
Fourth and last set of patches for v5.10. Most of these are iwlwifi
patches, but few small fixes to other drivers as well.
Major changes:
iwlwifi
* PNVM support (platform-specific phy config data)
* bump the FW API support to 59
====================
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next
Marc Kleine-Budde says:
====================
linux-can-next-for-5.10-20201007
The first 3 patches are by me and fix several warnings found
when compiling the kernel with W=1.
Lukas Bulwahn's patch adjusts the MAINTAINERS file, to accommodate
the renaming of the mcp251xfd driver.
Vincent Mailhol contributes 3 patches for the CAN networking layer.
First error queue support is added the the CAN RAW protocol.
The second patch converts the get_can_dlc() and get_canfd_dlc()
in-Kernel-only macros from using __u8 to u8.
The third patch adds a helper function to calculate the length of
one bit in in multiple of time quanta.
Oliver Hartkopp's patch add support for the ISO 15765-2:2016
transport protocol to the CAN stack.
Three patches by Lad Prabhakar add documentation for various
new rcar controllers to the device tree bindings of the rcar_can
and rcan_canfd driver.
Michael Walle's patch adds various processors to the flexcan
driver binding documentation.
The next two patches are by me and target the flexcan driver aswell.
The remove the ack_grp and ack_bit from the fsl,stop-mode DT property
and the driver, as they are not used anymore. As these are the last
two arguments this change will not break existing device trees.
The last three patches are by Srinivas Neeli and target
the xilinx_can driver.
The first one increases the lower limit for the bit rate
prescaler to 2, the other two fix sparse and coverity findings.
====================
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
Fix comment typo.
s/abitrary/arbitrary/
Signed-off-by: Naoki Hayama <[email protected]>
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
When processing a system suspend request we suspend modem endpoints
if they are enabled, and call ipa_cmd_tag_process() (which issues
IPA commands) to ensure the IPA pipeline is cleared. It is an error
to attempt to issue an IPA command before setup is complete, so this
is clearly a bug. But we also shouldn't suspend or resume any
endpoints that have not been set up.
Have ipa_endpoint_suspend() and ipa_endpoint_resume() immediately
return if setup hasn't completed, to avoid any attempt to configure
endpoints or issue IPA commands in that case.
Fixes: 84f9bd12d46d ("soc: qcom: ipa: IPA endpoints")
Tested-by: Matthias Kaehlcke <[email protected]>
Signed-off-by: Alex Elder <[email protected]>
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
A subsequent addition of an IP4 or IP6 rule after other rules would
overwrite any existing TCAM entries of related L4 protocols(ex: tcp4 or
udp6). This was due to the mask including too many TCAM entries. Add new
packet type masks with bits properly excluded so rules are not overwritten.
Signed-off-by: Dan Nowlin <[email protected]>
Signed-off-by: Henry Tieman <[email protected]>
Tested-by: Brijesh Behera <[email protected]>
Signed-off-by: Tony Nguyen <[email protected]>
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
pointers should be casted to unsigned long to avoid
-Wpointer-to-int-cast warnings:
drivers/net/ethernet/intel/ice/ice_flow.h:197:33: warning:
cast from pointer to integer of different size
drivers/net/ethernet/intel/ice/ice_flow.h:198:32: warning:
cast to pointer from integer of different size
Signed-off-by: Bixuan Cui <[email protected]>
Tested-by: Aaron Brown <[email protected]>
Signed-off-by: Tony Nguyen <[email protected]>
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
While debugging a recent failure to update the flash of an ice device,
I found it helpful to add additional logging which helped determine the
root cause of the problem being a timeout issue.
Add some extra dev_dbg() logging messages which can be enabled using the
dynamic debug facility, including one for ice_aq_wait_for_event that
will use jiffies to capture a rough estimate of how long we waited for
the completion of a firmware command.
Signed-off-by: Jacob Keller <[email protected]>
Tested-by: Brijesh Behera <[email protected]>
Signed-off-by: Tony Nguyen <[email protected]>
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
Currently, the devlink_port structure is stored within the ice_pf. This
made sense because we create a single devlink_port for each PF. This
setup does not mesh with the abstractions in the driver very well, and
led to a flow where we accidentally call devlink_port_unregister twice
during error cleanup.
In particular, if devlink_port_register or devlink_port_unregister are
called twice, this leads to a kernel panic. This appears to occur during
some possible flows while cleaning up from a failure during driver
probe.
If register_netdev fails, then we will call devlink_port_unregister in
ice_cfg_netdev as it cleans up. Later, we again call
devlink_port_unregister since we assume that we must cleanup the port
that is associated with the PF structure.
This occurs because we cleanup the devlink_port for the main PF even
though it was not allocated. We allocated the port within a per-VSI
function for managing the main netdev, but did not release the port when
cleaning up that VSI, the allocation and destruction are not aligned.
Instead of attempting to manage the devlink_port as part of the PF
structure, manage it as part of the PF VSI. Doing this has advantages,
as we can match the de-allocation of the devlink_port with the
unregister_netdev associated with the main PF VSI.
Moving the port to the VSI is preferable as it paves the way for
handling devlink ports allocated for other purposes such as SR-IOV VFs.
Since we're changing up how we allocate the devlink_port, also change
the indexing. Originally, we indexed the port using the PF id number.
This came from an old goal of sharing a devlink for each physical
function. Managing devlink instances across multiple function drivers is
not workable. Instead, lets set the port number to the logical port
number returned by firmware and set the index using the VSI index
(sometimes referred to as VSI handle).
Signed-off-by: Jacob Keller <[email protected]>
Tested-by: Aaron Brown <[email protected]>
Signed-off-by: Tony Nguyen <[email protected]>
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
Add "fw.app.bundle_id" to display the DDP Track ID of the active DDP
package. This id is similar to "fw.bundle_id" and is a unique identifier
for the DDP package that is loaded in the device. Each new DDP has
a unique Track ID generated for it, and the ID can be used to identify
and track the DDP package.
Add documentation for the new devlink info version.
Signed-off-by: Jacob Keller <[email protected]>
Tested-by: Aaron Brown <[email protected]>
Signed-off-by: Tony Nguyen <[email protected]>
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
ice_info_get_dsn always returns 0, so just make it void.
Signed-off-by: Anirudh Venkataramanan <[email protected]>
Tested-by: Aaron Brown <[email protected]>
Signed-off-by: Tony Nguyen <[email protected]>
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
A new test in checkpatch detects repeated words; cleanup all pre-existing
occurrences of those now.
Signed-off-by: Bruce Allan <[email protected]>
Tested-by: Aaron Brown <[email protected]>
Co-developed-by: Tony Nguyen <[email protected]>
Signed-off-by: Tony Nguyen <[email protected]>
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
Use %*phD format to print small buffer as hex string.
Signed-off-by: Andy Shevchenko <[email protected]>
Reviewed-by: Jacob Keller <[email protected]>
Tested-by: Jacob Keller <[email protected]>
Signed-off-by: Tony Nguyen <[email protected]>
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
Add support for the KSZ9563 3-Port Gigabit Ethernet Switch to the
ksz9477 driver. The KSZ9563 supports both SPI (already in) and I2C. The
ksz9563 is already in the device tree binding documentation.
Signed-off-by: Christian Eggers <[email protected]>
Reviewed-by: Andrew Lunn <[email protected]>
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
Add support for devlink reload action fw_activate with reload limit
no_reset which does firmware live patching, updating the firmware image
without reset, no downtime and no configuration lose. The driver checks
if the firmware is capable of handling the pending firmware changes as a
live patch. If it is then it triggers firmware live patching flow.
Signed-off-by: Moshe Shemesh <[email protected]>
Reviewed-by: Saeed Mahameed <[email protected]>
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
Firmware live patch event notifies the driver that the firmware was just
updated using live patch. In such case the driver should not reload or
re-initiate entities, part to updating the firmware version and
re-initiate the firmware tracer which can be updated by live patch with
new strings database to help debugging an issue.
Signed-off-by: Moshe Shemesh <[email protected]>
Reviewed-by: Saeed Mahameed <[email protected]>
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
The enable_remote_dev_reset devlink param flags that the host admin
allows resets by other hosts. In case it is cleared mlx5 host PF driver
will send NACK on pci sync for firmware update reset request and the
command will fail.
By default enable_remote_dev_reset parameter is true, so pci sync for
firmware update reset is enabled.
Signed-off-by: Moshe Shemesh <[email protected]>
Reviewed-by: Saeed Mahameed <[email protected]>
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
Add support for devlink reload action fw_activate. To activate firmware
image the mlx5 driver resets the firmware and reloads it from flash. If
a new image was stored on flash it will be loaded. Once this reload
command is executed the driver initiates fw sync reset flow, where the
firmware synchronizes all PFs on coming reset and driver reload.
Signed-off-by: Moshe Shemesh <[email protected]>
Reviewed-by: Saeed Mahameed <[email protected]>
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
If firmware sends sync_reset_abort to driver the driver should clear the
reset requested mode as reset is not expected any more.
Signed-off-by: Moshe Shemesh <[email protected]>
Reviewed-by: Saeed Mahameed <[email protected]>
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
On sync_reset_now event the driver does reload and PCI link toggle to
activate firmware upgrade reset. When the firmware sends this event it
syncs the event on all PFs, so all PFs will do PCI link toggle at once.
To do PCI link toggle, the driver ensures that no other device ID under
the same bridge by checking that all the PF functions under the same PCI
bridge have same device ID. If no other device it uses PCI bridge link
control to turn link down and up.
Signed-off-by: Moshe Shemesh <[email protected]>
Reviewed-by: Saeed Mahameed <[email protected]>
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
Once the driver gets sync_reset_request from firmware it prepares for the
coming reset and sends acknowledge.
After getting this event the driver expects device reset, either it will
trigger PCI reset on sync_reset_now event or such PCI reset will be
triggered by another PF of the same device. So it moves to reset
requested mode and if it gets PCI reset triggered by the other PF it
detect the reset and reloads.
Signed-off-by: Moshe Shemesh <[email protected]>
Reviewed-by: Saeed Mahameed <[email protected]>
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
Set capability to notify the firmware that this host driver is capable
of handling pci sync for firmware update events.
Signed-off-by: Moshe Shemesh <[email protected]>
Reviewed-by: Saeed Mahameed <[email protected]>
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
Add functions to query and set the MFRL reset options supported by
firmware.
Signed-off-by: Moshe Shemesh <[email protected]>
Reviewed-by: Saeed Mahameed <[email protected]>
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
Add reload limit to demand restrictions on reload actions.
Reload limits supported:
no_reset: No reset allowed, no down time allowed, no link flap and no
configuration is lost.
By default reload limit is unspecified and so no constraints on reload
actions are required.
Some combinations of action and limit are invalid. For example, driver
can not reinitialize its entities without any downtime.
The no_reset reload limit will have usecase in this patchset to
implement restricted fw_activate on mlx5.
Have the uapi parameter of reload limit ready for future support of
multiselection.
Signed-off-by: Moshe Shemesh <[email protected]>
Reviewed-by: Jiri Pirko <[email protected]>
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
Add devlink reload action to allow the user to request a specific reload
action. The action parameter is optional, if not specified then devlink
driver re-init action is used (backward compatible).
Note that when required to do firmware activation some drivers may need
to reload the driver. On the other hand some drivers may need to reset
the firmware to reinitialize the driver entities. Therefore, the devlink
reload command returns the actions which were actually performed.
Reload actions supported are:
driver_reinit: driver entities re-initialization, applying devlink-param
and devlink-resource values.
fw_activate: firmware activate.
command examples:
$devlink dev reload pci/0000:82:00.0 action driver_reinit
reload_actions_performed:
driver_reinit
$devlink dev reload pci/0000:82:00.0 action fw_activate
reload_actions_performed:
driver_reinit fw_activate
Signed-off-by: Moshe Shemesh <[email protected]>
Reviewed-by: Jakub Kicinski <[email protected]>
Reviewed-by: Jacob Keller <[email protected]>
Reviewed-by: Jiri Pirko <[email protected]>
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
The phy_reset_after_clk_enable() does a PHY reset, which means the PHY
loses its register settings. The fec_enet_mii_probe() starts the PHY
and does the necessary calls to configure the PHY via PHY framework,
and loads the correct register settings into the PHY. Therefore,
fec_enet_mii_probe() should be called only after the PHY has been
reset, not before as it is now.
Fixes: 1b0a83ac04e3 ("net: fec: add phy_reset_after_clk_enable() support")
Reviewed-by: Andrew Lunn <[email protected]>
Tested-by: Richard Leitner <[email protected]>
Signed-off-by: Marek Vasut <[email protected]>
Cc: Christoph Niedermaier <[email protected]>
Cc: David S. Miller <[email protected]>
Cc: NXP Linux Team <[email protected]>
Cc: Shawn Guo <[email protected]>
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
This reverts commit 0a8159cbd11abf586693f1ec5264d0df587b71d8.
It turns out that this flag is used by iwldvm, so we can't get rid of
it. This broke iwldvm devices with BAD_COMMAND errors.
Fixes: 0a8159cbd11a ("iwlwifi: remove wide_cmd_header field")
Signed-off-by: Luca Coelho <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/iwlwifi.20201009122123.3e4ee0ad7a71.Id6d95ae601f048aeb4d2ed63a1712e469da84369@changeid
|
|
Without these definitions, the driver will crash in:
mscc_ocelot_probe
-> ocelot_init
-> ocelot_vcap_init
-> __ocelot_target_read_ix
I missed this because I did not have the VSC7514 hardware to test, only
the VSC9959 and VSC9953, and the probing part is different.
Fixes: e3aea296d86f ("net: mscc: ocelot: add definitions for VCAP ES0 keys, actions and target")
Fixes: a61e365d7c18 ("net: mscc: ocelot: add definitions for VCAP IS1 keys, actions and target")
Reported-by: Divya Koppera <[email protected]>
Signed-off-by: Vladimir Oltean <[email protected]>
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
In preparation for unconditionally passing the
struct tasklet_struct pointer to all tasklet
callbacks, switch to using the new tasklet_setup()
and from_tasklet() to pass the tasklet pointer explicitly.
Signed-off-by: Romain Perier <[email protected]>
Signed-off-by: Allen Pais <[email protected]>
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
Small conflict around locking in rxrpc_process_event() -
channel_lock moved to bundle in next, while state lock
needs _bh() from net.
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
Add usb ids of the Cellient MPL200 card.
Signed-off-by: Wilken Gottwalt <[email protected]>
Acked-by: Bjørn Mork <[email protected]>
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
De-referencing skb after call to gro_cells_receive() is not allowed.
We need to fetch skb->len earlier.
Fixes: 5491e7c6b1a9 ("macsec: enable GRO and RPS on macsec devices")
Signed-off-by: Eric Dumazet <[email protected]>
Cc: Paolo Abeni <[email protected]>
Acked-by: Paolo Abeni <[email protected]>
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
Some firmware files trigger a PHY soft reset and don't wait for it to
be finished. PHY register writes directly after applying the firmware
may fail or provide unexpected results therefore. Fix this by waiting
for bit BMCR_RESET to be cleared after applying firmware.
There's nothing wrong with the referenced change, it's just that the
fix will apply cleanly only after this change.
Fixes: 89fbd26cca7e ("r8169: fix firmware not resetting tp->ocp_base")
Signed-off-by: Heiner Kallweit <[email protected]>
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
Start supporting API version 59 for AX devices.
Signed-off-by: Luca Coelho <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/iwlwifi.20201008181047.0359498107fe.I559b5140be6abbee5eb759ec6e5ca046f7178f8f@changeid
|
|
The driver looks for a PNVM file that contains FW configuration data
for each different HW combination. The FW requests the data for a
certain SKU_ID and the driver tries to find it in the PNVM file.
Read the file, parse its contents and send it to the trans.
Signed-off-by: Luca Coelho <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/iwlwifi.20201008181047.826bc607e57a.I1d93dd6e6651586878db57fac3e7c3f09d742c42@changeid
|
|
Implement the set_pnvm op to store the PNVM settings to the context
info and the corresponding code to free the DRAM block when the
context is freed.
Signed-off-by: Luca Coelho <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/iwlwifi.20201008181047.85847cfb0972.I202d90e99779f722df14b2d4102d3e466343a6f6@changeid
|
|
Add an op to allow setting the PNVM data in the trans.
Signed-off-by: Luca Coelho <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/iwlwifi.20201008181047.77300b00d3ce.I89d7e45e71f19fd36d89f363a28b4759b59b8765@changeid
|
|
The PNVM code is generic and can be used by other opmodes. Move it to
a common file and include it in the relevant opmodes.
Signed-off-by: Luca Coelho <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/iwlwifi.20201008181047.232aa310693b.I03a18ffa4162753af38e759d88e27509007c7bca@changeid
|
|
The new API adds 4 bytes at end of the struct. We just need to make
sure that we don't break compatibility with old FWs.
Signed-off-by: Mordechay Goodstein <[email protected]>
Signed-off-by: Luca Coelho <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/iwlwifi.20201008181047.bb31ce80fc55.I8a272d1da1334b1805761c0731e5d0c76ca2ef29@changeid
|
|
When adding support for version 3 of the GEO_TX_POWER_LIMIT command,
the table argument of iwl_sar_geo_init was changed from a pointer a 1d
array of now-removed iwl_per_chain_offset_group_v1 to a pointer to a 2d
array of iwl_per_chain_offset (iwl_per_chain_offset_group_v1 was a
struct containing 2 copies of iwl_per_chain_offset).
So even for version 2 where the second dimension is of length 2, which
means that the underlying memory layout of the array didn't change, this
requires a small change in the way we loop over it, and this was missed.
Additionally, for the case of version 3 where the second dimension is now
3, in order to fill the first two elements of each row correctly (lb and
hb), iwl_sar_geo_init must get the true number of bands supported.
But because we don't yet store any values for the 3rd (uhb) band, skip
that band.
Signed-off-by: Naftali Goldstein <[email protected]>
Signed-off-by: Luca Coelho <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/iwlwifi.20201008181047.73605b6e0548.Id0ec98333277ff9e017e3938ae413b34acc68947@changeid
|
|
The new API uses TLV format for statistics to enable fast changes
and debug on the fly.
Signed-off-by: Mordechay Goodstein <[email protected]>
Signed-off-by: Luca Coelho <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/iwlwifi.20201008181047.a45fd1a34a39.I7709305a6dc7b88d0c5119b12c9251fa6c740262@changeid
|
|
mvm mutex isn't held by iwl_mvm_set_aes_rx_seq or it caller.
iee80211_local->key_mtx is held, but that is internal to mac80211.
The same applies to iwl_mvm_wowlan_program_keys.
Just hold rcu_read_lock, even though we are protected, the penalty
isn't that bad.
Warnings fixed are:
[ 4143.788196] WARNING: suspicious RCU usage
[ 4143.788211] -----------------------------
[ 4143.788220] suspicious rcu_dereference_protected() usage!
[ 4143.788227]
[ 4143.788234] rcu_scheduler_active = 2, debug_locks = 1
[ 4143.788242] 5 locks held by kworker/u8:9/5921:
[ 4143.788331] #4: ffff88804e69ad08 (&local->key_mtx){+.+.}, at ie80211_iter_keys+0x46/0x380 [mac80211]
[ 4143.788441]
[ 4143.788441] Call Trace:
[ 4143.788455] dump_stack+0xc1/0x11a
[ 4143.788471] lockdep_rcu_suspicious+0x14a/0x153
[ 4143.788515] iwl_mvm_set_aes_rx_seq+0x4a9/0x570 [iwlmvm]
[ 4143.788657] iwl_mvm_d3_update_keys+0x2ac/0x600 [iwlmvm]
[ 4143.788784] ieee80211_iter_keys+0x10e/0x380 [mac80211]
[ 4143.788838] iwl_mvm_setup_connection_keep+0x287/0x8d0 [iwlmvm]
[ 7243.206556] WARNING: suspicious RCU usage
[ 7243.206811] -----------------------------
[ 7243.206926] /suspicious rcu_dereference_protected() usage!
[ 7243.207086]
[ 7243.207204] rcu_scheduler_active = 2, debug_locks = 1
[ 7243.207321] 2 locks held by cat/15952:
[ 7243.207564] #1: ffff888008c8ad08 (&local->key_mtx){+.+.}, at:
ieee80211_iter_keys+0x46/0x380 [mac80211]
[ 7243.207751]
[ 7243.208094] Call Trace:
[ 7243.208211] dump_stack+0xc1/0x11a
[ 7243.208355] lockdep_rcu_suspicious+0x14a/0x153
[ 7243.208509] iwl_mvm_wowlan_program_keys+0x1db7/0x2340 [iwlmvm]
[ 7243.209852] ieee80211_iter_keys+0x10e/0x380 [mac80211]
Signed-off-by: Sara Sharon <[email protected]>
Signed-off-by: Luca Coelho <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/iwlwifi.20201008181047.65872d5f1670.I0b2fb2a65904ae686c3c7c05f881a1e3634dc900@changeid
|
|
iwl_mvm_wowlan_program_keys is now setting data directly in
the KEK_KCK command, and the memset is clearing this later,
causing the data to be incomplete.
Just remove the memory clearing, the structure is local and
cleared in the declaration.
Signed-off-by: Sara Sharon <[email protected]>
Signed-off-by: Luca Coelho <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/iwlwifi.20201008181047.0f355b4578c5.Ifbb76a2814925f215a2c889c1792d46d5bd66ab8@changeid
|
|
We introduced a new flow to remove an on-going CSA but we
assumed the firwmare understands the
CHANNEL_SWITCH_TIME_EVENT_CMD. This is not true for 7265 and down.
Don't send this command for those devices, but rather use the older
command.
Signed-off-by: Emmanuel Grumbach <[email protected]>
Signed-off-by: Luca Coelho <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/iwlwifi.20201008181047.2574e3e47927.Ic0c56411da1096e9a45ee5c3383edf777c5baca0@changeid
|
|
We were using 5 s for some qu devices, but their xtal stabilizes
much faster than that. Reduce the value to 500 ms.
Signed-off-by: Luca Coelho <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/iwlwifi.20201008181047.d0e2253c282f.Icd2ff00adff52f6c96fb261c34fbf129ce67a00d@changeid
|
|
We were using a very high latency for all 9560 devices so they all
would have time to stabilize. But this causes the system to be
slighly slower, so we can use the best values for each device.
This requires a new trans cfg struct for devices with longer latency
and some adjustments to the other structs.
Signed-off-by: Luca Coelho <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/iwlwifi.20201008181047.34392f98fdb1.I3d3db14f6d1a8ecc547ca6afce8488816bd26081@changeid
|
|
The 0x271B and 0x271C devices are part of the 9000 series (discrete),
and not 9560 (integrated). Fix it accordingly.
Signed-off-by: Luca Coelho <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/iwlwifi.20201008180656.5cc1809940d2.If0d1e0b91fa99486403d276cf7c0fe7680a7ca2a@changeid
|
|
When adding a PASN station, the station is added to the list only
if a TK is configured. Otherwise the station pointer should not be
used.
Signed-off-by: Avraham Stern <[email protected]>
Signed-off-by: Luca Coelho <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/iwlwifi.20201008180656.b8a493c168a7.Ie9a0f9dfd9e9c58c603dd06e45151119467a7804@changeid
|