| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
There are two modes now, and we have two places checking
that must be in sync. Refactor the logic into a new small
helper function.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Gregory Greenman <[email protected]>
Link: https://lore.kernel.org/r/20230413102635.ef6246f4b73b.I44820ec095634dd0bba3007465cf25e4ce1c77c6@changeid
Signed-off-by: Johannes Berg <[email protected]>
|
|
Since Gl A-step devices use the old checksum hardware,
we shouldn't use the Bz code to check for A-MSDU
combining ability; fix that.
Fixes: ec18e7d4d20d ("wifi: iwlwifi: mvm: use old checksum for Bz A-step")
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Gregory Greenman <[email protected]>
Link: https://lore.kernel.org/r/20230413102635.8c445b943fee.Ibf772102ca712f59e2ee0cdd4c344011fcf445aa@changeid
Signed-off-by: Johannes Berg <[email protected]>
|
|
B step doesn't support full checksum yet, move to c step.
Signed-off-by: Golan Ben Ami <[email protected]>
Signed-off-by: Gregory Greenman <[email protected]>
Link: https://lore.kernel.org/r/20230413102635.697a9d74e84d.I6724874112692a04e29287cac9dad7140532557f@changeid
Signed-off-by: Johannes Berg <[email protected]>
|
|
IEEE80211_TX_CTL_NO_CCK_RATE indicates that CCK rates should not be
used, but is ignored by the driver. Fix it.
Signed-off-by: Avraham Stern <[email protected]>
Signed-off-by: Gregory Greenman <[email protected]>
Link: https://lore.kernel.org/r/20230413102635.a322d18b5eb1.Icc46027a03f90feffb6fab49a5d82e54829d3dd9@changeid
Signed-off-by: Johannes Berg <[email protected]>
|
|
On queue remove, we should convert the TID value to the
firmware value (8 -> 15) just like we do on queue add.
Otherwise, the firmware will not be able to find the
correct queue to remove.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Gregory Greenman <[email protected]>
Link: https://lore.kernel.org/r/20230413102635.6651077eaec3.Ia6868c8fc1a92063609bb057b6a618726712d0bb@changeid
Signed-off-by: Johannes Berg <[email protected]>
|
|
update the device configuration for HR1 device for SO and SOF device.
QuZ device configuration is corrected to support specific CRF.
Signed-off-by: Mukesh Sisodiya <[email protected]>
Signed-off-by: Gregory Greenman <[email protected]>
Link: https://lore.kernel.org/r/20230413102635.86f08520323f.Ieccb50de47f877b85732000a0d67b645eeeb0c2a@changeid
Signed-off-by: Johannes Berg <[email protected]>
|
|
This function receives the queue id to reclaim packets from. Currently
we're passing to it the queue id we received from the FW in the flush
response. We don't do any check of this value and it might be invalid.
In such case we will refer to a pointer to a queue which might be NULL.
Fix this by adding a validity check of the queue id before using it.
Signed-off-by: Miri Korenblit <[email protected]>
Signed-off-by: Gregory Greenman <[email protected]>
Link: https://lore.kernel.org/r/20230413102635.a9c3fd32bce7.I5fbdcf3b1b80eb96a907116c166f19dc0aae7cb8@changeid
Signed-off-by: Johannes Berg <[email protected]>
|
|
Initially, 160/320 MHz in AP mode were not supported.
After testing, enable the wider bandwidths in AP mode
as well.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Gregory Greenman <[email protected]>
Link: https://lore.kernel.org/r/20230413102635.ed04de3a2833.Ie3991179dfaf24880b96a0904a625dbf6b8fd579@changeid
Signed-off-by: Johannes Berg <[email protected]>
|
|
In __iwl_err(), if we rate-limit the message away, then
vaf.va is still NULL-initialized by the time we get to
the tracing code, which then crashes. When it doesn't
get rate-limited out, it's still wrong to reuse the old
args2 that was already printed, which is why we bother
making a copy in the first place.
Assign vaf.va properly to fix this.
Fixes: e5f1cc98cc1b ("iwlwifi: allow rate-limited error messages")
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Gregory Greenman <[email protected]>
Link: https://lore.kernel.org/r/20230413102635.e27134c6bcd4.Ib3894cd2ba7a5ad5e75912a7634f146ceaa569e2@changeid
Signed-off-by: Johannes Berg <[email protected]>
|
|
Eric points out that we should make sure that ring index updates
are wrapped in the appropriate READ_ONCE/WRITE_ONCE macros.
Suggested-by: Eric Dumazet <[email protected]>
Reviewed-by: Eric Dumazet <[email protected]>
Reviewed-by: Jesse Brandeburg <[email protected]>
Signed-off-by: Jakub Kicinski <[email protected]>
Reviewed-by: Tariq Toukan <[email protected]>
Signed-off-by: Paolo Abeni <[email protected]>
|
|
Eric points out that we should make sure that ring index updates
are wrapped in the appropriate READ_ONCE/WRITE_ONCE macros.
Suggested-by: Eric Dumazet <[email protected]>
Reviewed-by: Eric Dumazet <[email protected]>
Reviewed-by: Jesse Brandeburg <[email protected]>
Signed-off-by: Jakub Kicinski <[email protected]>
Reviewed-by: Michael Chan <[email protected]>
Signed-off-by: Paolo Abeni <[email protected]>
|
|
Add the new programming sequence needed for EMAC3 based platforms such
as the sc8280xp family.
Signed-off-by: Andrew Halaney <[email protected]>
Reviewed-by: Jesse Brandeburg <[email protected]>
Tested-by: Brian Masney <[email protected]>
Signed-off-by: Paolo Abeni <[email protected]>
|
|
It seems that this variable should be used for all speeds, not just
1000/100.
While at it refactor it slightly to be more readable, including fixing
the typo in the variable name.
Signed-off-by: Andrew Halaney <[email protected]>
Reviewed-by: Jesse Brandeburg <[email protected]>
Tested-by: Brian Masney <[email protected]>
Signed-off-by: Paolo Abeni <[email protected]>
|
|
The driver currently sets a MAC TX delay of 2 ns no matter what the
phy-mode is. If the phy-mode indicates the phy is in charge of the
TX delay (rgmii-txid, rgmii-id), don't do it in the MAC.
Signed-off-by: Andrew Halaney <[email protected]>
Reviewed-by: Jesse Brandeburg <[email protected]>
Tested-by: Brian Masney <[email protected]>
Signed-off-by: Paolo Abeni <[email protected]>
|
|
Some platforms have dwmac4 implementations that have a different
address space layout than the default, resulting in the need to define
their own DMA/MTL offsets.
Extend the functions to allow a platform driver to indicate what its
addresses are, overriding the defaults.
Signed-off-by: Andrew Halaney <[email protected]>
Reviewed-by: Jesse Brandeburg <[email protected]>
Tested-by: Brian Masney <[email protected]>
Signed-off-by: Paolo Abeni <[email protected]>
|
|
Passing stmmac_priv to some of the callbacks allows hwif implementations
to grab some data that platforms can customize. Adjust the callbacks
accordingly in preparation of such a platform customization.
Signed-off-by: Andrew Halaney <[email protected]>
Reviewed-by: Jesse Brandeburg <[email protected]>
Tested-by: Brian Masney <[email protected]>
Signed-off-by: Paolo Abeni <[email protected]>
|
|
There's a few spots in the hardware interface where a void pointer is
used, but what's passed in and later cast out is always the same type.
Just use the proper type directly.
Reviewed-by: Simon Horman <[email protected]>
Signed-off-by: Andrew Halaney <[email protected]>
Reviewed-by: Jesse Brandeburg <[email protected]>
Tested-by: Brian Masney <[email protected]>
Signed-off-by: Paolo Abeni <[email protected]>
|
|
DAM is supposed to be DMA. Fix it to improve readability.
Signed-off-by: Andrew Halaney <[email protected]>
Reviewed-by: Jesse Brandeburg <[email protected]>
Tested-by: Brian Masney <[email protected]>
Signed-off-by: Paolo Abeni <[email protected]>
|
|
The brackets are unnecessary, remove them to match the coding style
used in the kernel.
Signed-off-by: Andrew Halaney <[email protected]>
Reviewed-by: Jesse Brandeburg <[email protected]>
Tested-by: Brian Masney <[email protected]>
Signed-off-by: Paolo Abeni <[email protected]>
|
|
I have observed an issue where the RX direction of the LS1028A ENETC pMAC
seems unresponsive. The minimal procedure to reproduce the issue is:
1. Connect ENETC port 0 with a loopback RJ45 cable to one of the Felix
switch ports (0).
2. Bring the ports up (MAC Merge layer is not enabled on either end).
3. Send a large quantity of unidirectional (express) traffic from Felix
to ENETC. I tried altering frame size and frame count, and it doesn't
appear to be specific to either of them, but rather, to the quantity
of octets received. Lowering the frame count, the minimum quantity of
packets to reproduce relatively consistently seems to be around 37000
frames at 1514 octets (w/o FCS) each.
4. Using ethtool --set-mm, enable the pMAC in the Felix and in the ENETC
ports, in both RX and TX directions, and with verification on both
ends.
5. Wait for verification to complete on both sides.
6. Configure a traffic class as preemptible on both ends.
7. Send some packets again.
The issue is at step 5, where the verification process of ENETC ends
(meaning that Felix responds with an SMD-R and ENETC sees the response),
but the verification process of Felix never ends (it remains VERIFYING).
If step 3 is skipped or if ENETC receives less traffic than
approximately that threshold, the test runs all the way through
(verification succeeds on both ends, preemptible traffic passes fine).
If, between step 4 and 5, the step below is also introduced:
4.1. Disable and re-enable PM0_COMMAND_CONFIG bit RX_EN
then again, the sequence of steps runs all the way through, and
verification succeeds, even if there was the previous RX traffic
injected into ENETC.
Traffic sent *by* the ENETC port prior to enabling the MAC Merge layer
does not seem to influence the verification result, only received
traffic does.
The LS1028A manual does not mention any relationship between
PM0_COMMAND_CONFIG and MMCSR, and the hardware people don't seem to
know for now either.
The bit that is toggled to work around the issue is also toggled
by enetc_mac_enable(), called from phylink's mac_link_down() and
mac_link_up() methods - which is how the workaround was found:
verification would work after a link down/up.
Fixes: c7b9e8086902 ("net: enetc: add support for MAC Merge layer")
Signed-off-by: Vladimir Oltean <[email protected]>
Reviewed-by: Jacob Keller <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Paolo Abeni <[email protected]>
|
|
Remove an inability of bnxt_en driver to set eswitch to switchdev
mode without existing VFs by:
1. Allow to set switchdev mode in bnxt_dl_eswitch_mode_set() so
representors are created only when num_vfs > 0 otherwise just
set bp->eswitch_mode
2. Do not automatically change bp->eswitch_mode during
bnxt_vf_reps_create() and bnxt_vf_reps_destroy() calls so
the eswitch mode is managed only by an user by devlink.
Just set temporarily bp->eswitch_mode to legacy to avoid
re-opening of representors during destroy.
3. Create representors in bnxt_sriov_enable() if current eswitch
mode is switchdev one
Tested by this sequence:
1. Set PF interface up
2. Set PF's eswitch mode to switchdev
3. Created N VFs
4. Checked that N representors were created
5. Set eswitch mode to legacy
6. Checked that representors were deleted
7. Set eswitch mode back to switchdev
8. Checked that representors exist again for VFs
9. Deleted all VFs
10. Checked that all representors were deleted as well
11. Checked that current eswitch mode is still switchdev
Signed-off-by: Ivan Vecera <[email protected]>
Acked-by: Venkat Duvvuru <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Paolo Abeni <[email protected]>
|
|
Fix two typos in comments:
blongs -> belongs
UPD -> UDP
No functional changes.
Signed-off-by: Mika Westerberg <[email protected]>
Reviewed-by: Simon Horman <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
Fixes the following warning when the driver is built with sparse checks
enabled:
main.c:993:23: warning: incorrect type in initializer (different base types)
main.c:993:23: expected restricted __wsum [usertype] wsum
main.c:993:23: got restricted __be32 [usertype]
No functional changes intended.
Signed-off-by: Mika Westerberg <[email protected]>
Reviewed-by: Simon Horman <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
Fixes the following warnings when the driver is built with sparse
checks enabled:
main.c:767:47: warning: restricted __le32 degrades to integer
main.c:775:47: warning: restricted __le16 degrades to integer
main.c:776:44: warning: restricted __le16 degrades to integer
main.c:876:40: warning: incorrect type in assignment (different base types)
main.c:876:40: expected restricted __le32 [usertype] frame_size
main.c:876:40: got unsigned int [assigned] [usertype] frame_size
main.c:877:41: warning: incorrect type in assignment (different base types)
main.c:877:41: expected restricted __le32 [usertype] frame_count
main.c:877:41: got unsigned int [usertype]
main.c:878:41: warning: incorrect type in assignment (different base types)
main.c:878:41: expected restricted __le16 [usertype] frame_index
main.c:878:41: got unsigned short [usertype]
main.c:879:38: warning: incorrect type in assignment (different base types)
main.c:879:38: expected restricted __le16 [usertype] frame_id
main.c:879:38: got unsigned short [usertype]
main.c:880:62: warning: restricted __le32 degrades to integer
main.c:880:35: warning: restricted __le16 degrades to integer
No functional changes intended.
Signed-off-by: Mika Westerberg <[email protected]>
Reviewed-by: Simon Horman <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
A number of MDIO drivers make use of devm_mdiobus_alloc_size(). This
is only available when CONFIG_MDIO_DEVRES is enabled. Add missing
depends or selects, depending on if there are circular dependencies or
not. This avoids linker errors, especially for randconfig builds.
Signed-off-by: Andrew Lunn <[email protected]>
Reviewed-by: Jacob Keller <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
Wire up RTL8821CS chipset support using the new rtw88 SDIO HCI code as
well as the existing RTL8821C chipset code.
Reviewed-by: Ping-Ke Shih <[email protected]>
Tested-by: Chris Morgan <[email protected]>
Signed-off-by: Martin Blumenstingl <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
Wire up RTL8822CS chipset support using the new rtw88 SDIO HCI code as
well as the existing RTL8822C chipset code.
Reviewed-by: Ping-Ke Shih <[email protected]>
Signed-off-by: Martin Blumenstingl <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
Wire up RTL8822BS chipset support using the new rtw88 SDIO HCI code as
well as the existing RTL8822B chipset code.
Signed-off-by: Jernej Skrabec <[email protected]>
Reviewed-by: Ping-Ke Shih <[email protected]>
Signed-off-by: Martin Blumenstingl <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
For SDIO host controllers with DMA support the TX buffer physical memory
address need to be aligned at an 8-byte boundary. Reserve 8 bytes of
extra TX headroom so we can align the data without re-allocating the
transmit buffer.
While here, also remove the TODO comment regarding extra headroom for
USB and SDIO. For SDIO the extra headroom is now handled and for USB it
was not needed so far.
Reviewed-by: Ping-Ke Shih <[email protected]>
Signed-off-by: Martin Blumenstingl <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
Initialize the rpwm_addr and cpwm_addr for power-saving support on SDIO
based chipsets.
Reviewed-by: Ping-Ke Shih <[email protected]>
Signed-off-by: Martin Blumenstingl <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
Add the code specific to SDIO HCI in the MAC power on sequence. This is
based on the RTL8822BS and RTL8822CS vendor drivers.
Co-developed-by: Jernej Skrabec <[email protected]>
Signed-off-by: Jernej Skrabec <[email protected]>
Reviewed-by: Ping-Ke Shih <[email protected]>
Signed-off-by: Martin Blumenstingl <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
Add a sub-driver for SDIO based chipsets which implements the following
functionality:
- register accessors for 8, 16 and 32 bits for all states of the card
(including usage of 4x 8 bit access for one 32 bit buffer if the card
is not fully powered on yet - or if it's fully powered on then 1x 32
bit access is used)
- checking whether there's space in the TX FIFO queue to transmit data
- transfers from the host to the device for actual network traffic,
reserved pages (for firmware download) and H2C (host-to-card)
transfers
- receiving data from the device
- deep power saving state
The transmit path is optimized so DMA-capable SDIO host controllers can
directly use the buffers provided because the buffer's physical
addresses are 8 byte aligned.
The receive path is prepared to support RX aggregation where the
chipset combines multiple MAC frames into one bigger buffer to reduce
SDIO transfer overhead.
Co-developed-by: Jernej Skrabec <[email protected]>
Signed-off-by: Jernej Skrabec <[email protected]>
Reviewed-by: Ulf Hansson <[email protected]>
Signed-off-by: Martin Blumenstingl <[email protected]>
Reviewed-by: Ping-Ke Shih <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
The SDIO HCI implementation needs to know when the MAC is powered on.
This is needed because 32-bit register access has to be split into 4x
8-bit register access when the MAC is not fully powered on or while
powering off. When the MAC is powered on 32-bit register access can be
used to reduce the number of transfers but splitting into 4x 8-bit
register access still works in that case.
During the power on sequence is how RTW_FLAG_POWERON is only set when
the power on sequence has completed successfully. During power off
however RTW_FLAG_POWERON is set. This means that the upcoming SDIO HCI
implementation does not know that it has to use 4x 8-bit register
accessors. Clear the RTW_FLAG_POWERON flag early when powering off the
MAC so the whole power off sequence is processed with RTW_FLAG_POWERON
unset. This will make it possible to use the RTW_FLAG_POWERON flag in
the upcoming SDIO HCI implementation.
Note that a failure in rtw_pwr_seq_parser() while applying
chip->pwr_off_seq can theoretically result in the RTW_FLAG_POWERON
flag being cleared while the chip is still powered on. However,
depending on when the failure occurs in the power off sequence the
chip may be on or off. Even the original approach of clearing
RTW_FLAG_POWERON only when the power off sequence has been applied
successfully could end up in some corner case where the chip is
powered off but RTW_FLAG_POWERON was not cleared.
Reviewed-by: Ping-Ke Shih <[email protected]>
Signed-off-by: Martin Blumenstingl <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
Remove pci_clear_master to simplify the code,
the bus-mastering is also cleared in do_pci_disable_device,
like this:
./drivers/pci/pci.c:2197
static void do_pci_disable_device(struct pci_dev *dev)
{
u16 pci_command;
pci_read_config_word(dev, PCI_COMMAND, &pci_command);
if (pci_command & PCI_COMMAND_MASTER) {
pci_command &= ~PCI_COMMAND_MASTER;
pci_write_config_word(dev, PCI_COMMAND, pci_command);
}
pcibios_disable_device(dev);
}.
And dev->is_busmaster is set to 0 in pci_disable_device.
Signed-off-by: Cai Huoqing <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
Remove pci_clear_master to simplify the code,
the bus-mastering is also cleared in do_pci_disable_device,
like this:
./drivers/pci/pci.c:2197
static void do_pci_disable_device(struct pci_dev *dev)
{
u16 pci_command;
pci_read_config_word(dev, PCI_COMMAND, &pci_command);
if (pci_command & PCI_COMMAND_MASTER) {
pci_command &= ~PCI_COMMAND_MASTER;
pci_write_config_word(dev, PCI_COMMAND, pci_command);
}
pcibios_disable_device(dev);
}.
And dev->is_busmaster is set to 0 in pci_disable_device.
Signed-off-by: Cai Huoqing <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
Remove pci_clear_master to simplify the code,
the bus-mastering is also cleared in do_pci_disable_device,
like this:
./drivers/pci/pci.c:2197
static void do_pci_disable_device(struct pci_dev *dev)
{
u16 pci_command;
pci_read_config_word(dev, PCI_COMMAND, &pci_command);
if (pci_command & PCI_COMMAND_MASTER) {
pci_command &= ~PCI_COMMAND_MASTER;
pci_write_config_word(dev, PCI_COMMAND, pci_command);
}
pcibios_disable_device(dev);
}.
And dev->is_busmaster is set to 0 in pci_disable_device.
Signed-off-by: Cai Huoqing <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
Firmwares advertising the support of triggering 11d algorithm on the
scan results of a regular scan expects driver to send
WMI_11D_SCAN_START_CMDID before sending WMI_START_SCAN_CMDID.
Triggering 11d algorithm on the scan results of a normal scan helps
in completely avoiding a separate 11d scan for determining regdomain.
This indirectly helps in speeding up connections on station
interfaces on the chipsets supporting 11D scan.
To enable this feature, send WMI_11D_SCAN_START_CMDID just before
sending WMI_START_SCAN_CMDID if the firmware advertises
WMI_TLV_SERVICE_SUPPORT_11D_FOR_HOST_SCAN service flag.
WCN6750 & WCN6855 supports this feature.
Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.1.0.1-01160-QCAMSLSWPLZ-1
Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.23
Signed-off-by: Manikanta Pubbisetty <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
While initializing spectral, the magic value is getting written to the
invalid memory address leading to random boot-up crash. This occurs
due to the incorrect index increment in ath11k_dbring_fill_magic_value
function. Fix it by replacing the existing logic with memset32 to ensure
there is no invalid memory access.
Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.4.0.1-01838-QCAHKSWPL_SILICONZ-1
Fixes: d3d358efc553 ("ath11k: add spectral/CFR buffer validation support")
Signed-off-by: P Praneesh <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
The WMI management rx event has multiple arrays of TLVs, however the common
WMI TLV parser won't handle multiple TLV tags of same type.
So the multiple array tags of WMI management rx TLV is parsed incorrectly
and the length calculated becomes wrong when the target sends multiple
array tags.
Add separate TLV parser to handle multiple arrays for WMI management rx
TLV. This fixes invalid length issue when the target sends multiple array
tags.
Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1
Signed-off-by: Bhagavathi Perumal S <[email protected]>
Co-developed-by: Nagarajan Maran <[email protected]>
Signed-off-by: Nagarajan Maran <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
In QCN9074, station dump signal values display default value which
is -95 dbm, since there is firmware header change for HAL_RX_MPDU_START
between QCN9074 and IPQ8074 which cause wrong peer_id fetch from msdu.
Fix this by updating hal_rx_mpdu_info with corresponding QCN9074 tlv
format.
Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1
Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.4.0.1-01695-QCAHKSWPL_SILICONZ-1
Signed-off-by: P Praneesh <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
Fine Time Measurement(FTM) is offloaded feature to firmware.
Hence, the configuration of FTM responder role is done using
firmware capability flag instead of hw param.
Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1
Signed-off-by: Ganesh Babu Jothiram <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
Currently, time taken to scan all supported channels on WCN6750
is ~8 seconds and connection time is almost 10 seconds. WCN6750
supports three Wi-Fi bands (i.e., 2.4/5/6 GHz) and the numbers of
channels for scan come around ~100 channels (default case).
Since the chip doesn't have support for DBS (Dual Band Simultaneous),
scans cannot be parallelized resulting in longer scan times.
Among the 100 odd channels, ~60 channels are in 6 GHz band. Therefore,
optimizing the scan for 6 GHz channels will bring down the overall
scan time.
WCN6750 firmware has support to scan a 6 GHz channel based on co-located
AP information i.e., RNR IE which is found in the legacy 2.4/5 GHz scan
results. When a scan request with all supported channel list is enqueued
to the firmware, then based on WMI_SCAN_CHAN_FLAG_SCAN_ONLY_IF_RNR_FOUND
scan channel flag, firmware will scan only those 6 GHz channels for which
RNR IEs are found in the legacy scan results.
In the proposed design, based on NL80211_SCAN_FLAG_COLOCATED_6GHZ scan
flag, driver will set the WMI_SCAN_CHAN_FLAG_SCAN_ONLY_IF_RNR_FOUND flag
for non-PSC channels. Since there is high probability to find 6 GHz APs
on PSC channels, these channels are always scanned. Only non-PSC channels
are selectively scanned based on cached RNR information from the legacy
scan results.
If NL80211_SCAN_FLAG_COLOCATED_6GHZ is not set in the scan flags,
then scan will happen on all supported channels (default behavior).
With these optimizations, scan time is improved by 1.5-1.8 seconds on
WCN6750. Similar savings have been observed on WCN6855.
Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.1.0.1-00887-QCAMSLSWPLZ-1
Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.16
Signed-off-by: Manikanta Pubbisetty <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
TI CPSW uses of_platform_* functions which are declared in of_platform.h.
of_platform.h gets implicitly included by of_device.h, but that is going
to be removed soon. Nothing else depends on of_device.h so it can be
dropped. of_platform.h also implicitly includes platform_device.h, so
add an explicit include for it, too.
Signed-off-by: Rob Herring <[email protected]>
Reviewed-by: Jesse Brandeburg <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Smatch reports:
drivers/net/wwan/iosm/iosm_ipc_pcie.c:298 ipc_pcie_probe()
warn: missing unwind goto?
When dma_set_mask fails it directly returns without disabling pci
device and freeing ipc_pcie. Fix this my calling a correct goto label
As dma_set_mask returns either 0 or -EIO, we can use a goto label, as
it finally returns -EIO.
Add a set_mask_fail goto label which stands consistent with other goto
labels in this function..
Fixes: 035e3befc191 ("net: wwan: iosm: fix driver not working with INTEL_IOMMU disabled")
Reviewed-by: Simon Horman <[email protected]>
Signed-off-by: Harshit Mogalapalli <[email protected]>
Reviewed-by: Simon Horman <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Remove unused functions.
These functions may have some value in documenting the
hardware. But that information may be accessed via SCM history.
Flagged by clang-16 with W=1.
No functional change intended.
Compile tested only.
Signed-off-by: Simon Horman <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
The driver was incorrectly overwriting the cyclecounter bitmask,
which was truncating it and not aligning to the hardware mask value.
This isn't causing any issues, but it's wrong. Fix this by not
constraining the cyclecounter/hardware mask.
Luckily, this seems to cause no issues, which is why this change
doesn't have a fixes tag and isn't being sent to net. However, if
any transformations from time->cycles are needed in the future,
this change will be needed.
Suggested-by: Allen Hubbe <[email protected]>
Signed-off-by: Brett Creeley <[email protected]>
Signed-off-by: Shannon Nelson <[email protected]>
Reviewed-by: Simon Horman <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
The usual devm_regulator_get() call already handles "optional"
regulators by returning a valid dummy and printing a warning
that the dummy regulator should be described properly. This
code open coded the same behaviour, but masked any errors that
are not -EPROBE_DEFER and is quite noisy.
This change effectively unmasks and propagates regulators errors
not involving -ENODEV, downgrades the error print to warning level
if no regulator is specified and captures the probe defer message
for /sys/kernel/debug/devices_deferred.
Fixes: 2e12f536635f ("net: stmmac: dwmac-rk: Use standard devicetree property for phy regulator")
Signed-off-by: Sebastian Reichel <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
The clock requesting code is quite repetitive. Fix this by requesting
the clocks via devm_clk_bulk_get_optional. The optional variant has been
used, since this is effectively what the old code did. The exact clocks
required depend on the platform and configuration. As a side effect
this change adds correct -EPROBE_DEFER handling.
Suggested-by: Jakub Kicinski <[email protected]>
Suggested-by: Andrew Lunn <[email protected]>
Fixes: 7ad269ea1a2b ("GMAC: add driver for Rockchip RK3288 SoCs integrated GMAC")
Signed-off-by: Sebastian Reichel <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Static code analyzer complains to unchecked return value.
The result of pci_reset_function() is unchecked.
Despite, the issue is on the FLR supported code path and in that
case reset can be done with pcie_flr(), the patch uses less invasive
approach by adding the result check of pci_reset_function().
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Fixes: 7e2cf4feba05 ("qlcnic: change driver hardware interface mechanism")
Signed-off-by: Denis Plotnikov <[email protected]>
Reviewed-by: Simon Horman <[email protected]>
Reviewed-by: Bjorn Helgaas <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue
Tony Nguyen says:
====================
iavf: fix racing in VLANs
Ahmed Zaki says:
This patchset mainly fixes a racing issue in the iavf where the number of
VLANs in the vlan_filter_list might be more than the PF limit. To fix that,
we get rid of the cvlans and svlans bitmaps and keep all the required info
in the list.
The second patch adds two new states that are needed so that we keep the
VLAN info while the interface goes DOWN:
-- DISABLE (notify PF, but keep the filter in the list)
-- INACTIVE (dev is DOWN, filter is removed from PF)
Finally, the current code keeps each state in a separate bit field, which
is error prone. The first patch refactors that by replacing all bits with
a single enum. The changes are minimal where each bit change is replaced
with the new state value.
* '40GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue:
iavf: remove active_cvlans and active_svlans bitmaps
iavf: refactor VLAN filter states
====================
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
|