Age | Commit message (Collapse) | Author | Files | Lines |
|
Strictly speaking, the unit of the offset should be TU instead of ms.
So, correct it and the macro for calculation. Then, to make the macro
generic, the factor n is moved outside.
Signed-off-by: Zong-Zhe Yang <[email protected]>
Signed-off-by: Ping-Ke Shih <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
Should update the driver with the supported firmware version of the
below item.
Bluetooth firmware BT_Coex_Ver: 0x07
Wi-Fi firmware version: RTL8852C->v0.27.56.10, RTL8852A->v0.24.36
Signed-off-by: Ching-Te Ku <[email protected]>
Signed-off-by: Ping-Ke Shih <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
The origin code will enable TDMA WL:BT = 50:50 to prevent Wi-Fi
throughput suddenly drop to 0 in the moment while A2DP pause.
And this protection just a short moment, and will turn to Bluetooth
idle case when A2DP turn into sniff mode. But the raspberryPI simulated
A2DP device will not turn into sniff mode. So the protection will bring
the throughput drop.
Signed-off-by: Ching-Te Ku <[email protected]>
Signed-off-by: Ping-Ke Shih <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
When Wi-Fi enter and leave LPS, coexistence driver need to know
is there A2DP exist or not. And when Wi-Fi sleep in deep power save
state will not able to receive mailbox sent from Bluetooth. So update
the A2DP exist information from reading register.
Signed-off-by: Ching-Te Ku <[email protected]>
Signed-off-by: Ping-Ke Shih <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
When Wi-Fi is RX, set Bluetooth background scan to low-priority and
not to break Wi-Fi packet. Bluetooth can RX depend on hardware ability
even RX request has been rejected. This way can improve Wi-Fi RX
throughput performance.
Signed-off-by: Ching-Te Ku <[email protected]>
Signed-off-by: Ping-Ke Shih <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
Adjust the log format and correct variable reference to make the log
more readable.
Signed-off-by: Ching-Te Ku <[email protected]>
Signed-off-by: Ping-Ke Shih <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
Force firmware to update TDMA parameter when enter/exit power saving.
The TDMA instant feature will make firmware force update TDMA parameter
immediately when the TDMA parameter H2C to firmware. Without this feature,
it will have a low fail rate trigger Bluetooth audio sound glitch when
Wi-Fi is under power saving. Or Wi-Fi fail to turn in to power save state.
Signed-off-by: Ching-Te Ku <[email protected]>
Signed-off-by: Ping-Ke Shih <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
Reset the counter no matter Wi-Fi is notified turning into power save or
not. With rest the counter coexistence will recognize Bluetooth is hanged
easily.
Signed-off-by: Ching-Te Ku <[email protected]>
Signed-off-by: Ping-Ke Shih <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
This patch update the external control (Wi-Fi firmware control) type of
TDMA related parameters, almost all of these case were related to Wi-Fi
multi-role situations & AP mode.
Signed-off-by: Ching-Te Ku <[email protected]>
Signed-off-by: Ping-Ke Shih <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
The function cfg80211_set_channel() is an static function in brcmfmac
but the name is misleading. Hence rename it with 'brcmf' prefix. Also
changing the parameters to avoid additional conversions.
Signed-off-by: Arend van Spriel <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
This code re-uses "i" to be the iterator for both the inside and outside
loops. It means the outside loop will exit earlier than intended.
Fixes: d219b7eb3792 ("mwifiex: handle BT coex event to adjust Rx BA window size")
Signed-off-by: Dan Carpenter <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/Y+ERnaDaZD7RtLvX@kili
|
|
One-element arrays are deprecated, and we are replacing them with flexible
array members instead. So, replace one-element array with flexible-array
member in struct mwifiex_ie_types_rates_param_set.
These are the only binary differences I see after the change:
mwifiex.o
_@@ -50154,7 +50154,7 @@
23514: R_X86_64_32S kmalloc_caches+0x50
23518: call 2351d <mwifiex_scan_networks+0x11d>
23519: R_X86_64_PLT32 __tsan_read8-0x4
- 2351d: mov $0x225,%edx
+ 2351d: mov $0x224,%edx
23522: mov $0xdc0,%esi
23527: mov 0x0(%rip),%rdi # 2352e <mwifiex_scan_networks+0x12e>
2352a: R_X86_64_PC32 kmalloc_caches+0x4c
scan.o
_@@ -5582,7 +5582,7 @@
4394: R_X86_64_32S kmalloc_caches+0x50
4398: call 439d <mwifiex_scan_networks+0x11d>
4399: R_X86_64_PLT32 __tsan_read8-0x4
- 439d: mov $0x225,%edx
+ 439d: mov $0x224,%edx
43a2: mov $0xdc0,%esi
43a7: mov 0x0(%rip),%rdi # 43ae <mwifiex_scan_networks+0x12e>
43aa: R_X86_64_PC32 kmalloc_caches+0x4c
and the reason for that is the following line:
drivers/net/wireless/marvell/mwifiex/scan.c:
1517 scan_cfg_out = kzalloc(sizeof(union mwifiex_scan_cmd_config_tlv),
1518 GFP_KERNEL);
sizeof(union mwifiex_scan_cmd_config_tlv) is now one-byte smaller due to the
flex-array transformation:
46 union mwifiex_scan_cmd_config_tlv {
47 /* Scan configuration (variable length) */
48 struct mwifiex_scan_cmd_config config;
49 /* Max allocated block */
50 u8 config_alloc_buf[MAX_SCAN_CFG_ALLOC];
51 };
Notice that MAX_SCAN_CFG_ALLOC is defined in terms of
sizeof(struct mwifiex_ie_types_rates_param_set), see:
26 /* Memory needed to store supported rate */
27 #define RATE_TLV_MAX_SIZE (sizeof(struct mwifiex_ie_types_rates_param_set) \
28 + HOSTCMD_SUPPORTED_RATES)
37 /* Maximum memory needed for a mwifiex_scan_cmd_config with all TLVs at max */
38 #define MAX_SCAN_CFG_ALLOC (sizeof(struct mwifiex_scan_cmd_config) \
39 + sizeof(struct mwifiex_ie_types_num_probes) \
40 + sizeof(struct mwifiex_ie_types_htcap) \
41 + CHAN_TLV_MAX_SIZE \
42 + RATE_TLV_MAX_SIZE \
43 + WILDCARD_SSID_TLV_MAX_SIZE)
This helps with the ongoing efforts to tighten the FORTIFY_SOURCE
routines on memcpy() and help us make progress towards globally
enabling -fstrict-flex-arrays=3 [1].
Link: https://github.com/KSPP/linux/issues/79
Link: https://github.com/KSPP/linux/issues/252
Link: https://gcc.gnu.org/pipermail/gcc-patches/2022-October/602902.html [1]
Signed-off-by: Gustavo A. R. Silva <[email protected]>
Reviewed-by: Kees Cook <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/Y9xkjXeElSEQ0FPY@work
|
|
One-element arrays are deprecated, and we are replacing them with flexible
array members instead. So, replace one-element arrays with flexible-array
members in multiple structures.
This helps with the ongoing efforts to tighten the FORTIFY_SOURCE
routines on memcpy() and help us make progress towards globally
enabling -fstrict-flex-arrays=3 [1].
This results in no differences in binary output.
Link: https://github.com/KSPP/linux/issues/79
Link: https://github.com/KSPP/linux/issues/256
Link: https://gcc.gnu.org/pipermail/gcc-patches/2022-October/602902.html [1]
Signed-off-by: Gustavo A. R. Silva <[email protected]>
Reviewed-by: Kees Cook <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/Y9xkECG3uTZ6T1dN@work
|
|
One-element arrays are deprecated, and we are replacing them with flexible
array members instead. So, replace one-element array with flexible-array
member in struct brcmf_tlv.
This helps with the ongoing efforts to tighten the FORTIFY_SOURCE
routines on memcpy() and help us make progress towards globally
enabling -fstrict-flex-arrays=3 [1].
This results in no differences in binary output.
Link: https://github.com/KSPP/linux/issues/79
Link: https://github.com/KSPP/linux/issues/253
Link: https://gcc.gnu.org/pipermail/gcc-patches/2022-October/602902.html [1]
Signed-off-by: Gustavo A. R. Silva <[email protected]>
Reviewed-by: Kees Cook <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/Y9xjizhMujNEtpB4@work
|
|
Support the firmware hotfix version in GET_HW_SPEC responses to avoid an
irritating "Unknown api_id: 5" message on probe.
Based on this commit in NXP's GPLv2-licensed out-of-tree driver:
https://github.com/nxp-imx/mwifiex/commit/27fd8ecca504
Signed-off-by: Lukas Wunner <[email protected]>
Cc: Sherry Sun <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/111c7ee895f12d951e95a2edcd06d87ca26a7d0f.1674827105.git.lukas@wunner.de
|
|
The Marvell SD8978 (aka NXP IW416) uses identical registers as SD8987,
so reuse the existing mwifiex_reg_sd8987 definition.
Note that mwifiex_reg_sd8977 and mwifiex_reg_sd8997 are likewise
identical, save for the fw_dump_ctrl register: They define it as 0xf0
whereas mwifiex_reg_sd8987 defines it as 0xf9. I've verified that
0xf9 is the correct value on SD8978. NXP's out-of-tree driver uses
0xf9 for all of them, so there's a chance that 0xf0 is not correct
in the mwifiex_reg_sd8977 and mwifiex_reg_sd8997 definitions. I cannot
test that for lack of hardware, hence am leaving it as is.
NXP has only released a firmware which runs Bluetooth over UART.
Perhaps Bluetooth over SDIO is unsupported by this chipset.
Consequently, only an "sdiouart" firmware image is referenced, not an
alternative "sdsd" image.
Signed-off-by: Lukas Wunner <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/536b4f17a72ca460ad1b07045757043fb0778988.1674827105.git.lukas@wunner.de
|
|
Commit e3fffc1f0b47 ("devicetree: document new marvell-8xxx and
pwrseq-sd8787 options") documented a compatible string for SD8787 in
the devicetree bindings, but neglected to add it to the mwifiex driver.
Fixes: e3fffc1f0b47 ("devicetree: document new marvell-8xxx and pwrseq-sd8787 options")
Signed-off-by: Lukas Wunner <[email protected]>
Cc: [email protected] # v4.11+
Cc: Matt Ranostay <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/320de5005ff3b8fd76be2d2b859fd021689c3681.1674827105.git.lukas@wunner.de
|
|
This chip exists in two revisions (B2=r3 and B3=r4) on different
platforms, and was added without regard to doing proper firmware
selection or differentiating between them. Fix this to have proper
per-revision firmwares and support Apple NVRAM selection.
Revision B2 is present on at least these Apple T2 Macs:
kauai: MacBook Pro 15" (Touch/2018-2019)
maui: MacBook Pro 13" (Touch/2018-2019)
lanai: Mac mini (Late 2018)
ekans: iMac Pro 27" (5K, Late 2017)
And these non-T2 Macs:
nihau: iMac 27" (5K, 2019)
Revision B3 is present on at least these Apple T2 Macs:
bali: MacBook Pro 16" (2019)
trinidad: MacBook Pro 13" (2020, 4 TB3)
borneo: MacBook Pro 16" (2019, 5600M)
kahana: Mac Pro (2019)
kahana: Mac Pro (2019, Rack)
hanauma: iMac 27" (5K, 2020)
kure: iMac 27" (5K, 2020, 5700/XT)
Also fix the firmware interface for 4364, from BCA to WCC.
Fixes: 24f0bd136264 ("brcmfmac: add the BRCM 4364 found in MacBook Pro 15,2")
Reviewed-by: Linus Walleij <[email protected]>
Reviewed-by: Arend van Spriel <[email protected]>
Signed-off-by: Hector Martin <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
This chip is present on at least these Apple T2 Macs:
* tahiti: MacBook Pro 13" (2020, 2 TB3)
* formosa: MacBook Pro 13" (Touch/2019)
* fiji: MacBook Air 13" (Scissor, 2020)
Reviewed-by: Linus Walleij <[email protected]>
Reviewed-by: Arend van Spriel <[email protected]>
Signed-off-by: Hector Martin <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
This chip is present on at least these Apple T2 Macs:
* hawaii: MacBook Air 13" (Late 2018)
* hawaii: MacBook Air 13" (True Tone, 2019)
Users report seeing PCI revision ID 12 for this chip, which Arend
reports should be revision C2, but Apple has the firmware tagged as
revision C1. Assume the right cutoff point for firmware versions is
revision ID 11 then, and leave older revisions using the non-versioned
firmware filename (Apple only uses C1 firmware builds).
Reviewed-by: Arend van Spriel <[email protected]>
Signed-off-by: Hector Martin <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
The commit that introduced support for this chip incorrectly claimed it
is a Cypress-specific part, while in actuality it is just a variant of
BCM4355 silicon (as evidenced by the chip ID).
The relationship between Cypress products and Broadcom products isn't
entirely clear but given what little information is available and prior
art in the driver, it seems the convention should be that originally
Broadcom parts should retain the Broadcom name.
Thus, rename the relevant constants and firmware file. Also rename the
specific 89459 PCIe ID to BCM43596, which seems to be the original
subvariant name for this PCI ID (as defined in the out-of-tree bcmdhd
driver).
Since Cypress added this part and will presumably be providing its
supported firmware, we keep the CYW designation for this device.
We also drop the RAW device ID in this commit. We don't do this for the
other chips since apparently some devices with them exist in the wild,
but there is already a 4355 entry with the Broadcom subvendor and WCC
firmware vendor, so adding a generic fallback to Cypress seems
redundant (no reason why a device would have the raw device ID *and* an
explicitly programmed subvendor).
Fixes: dce45ded7619 ("brcmfmac: Support 89459 pcie")
Reviewed-by: Arend van Spriel <[email protected]>
Signed-off-by: Hector Martin <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
Minor cleanups:
- Drop redundant blank lines,
- Correct indentaion in examples,
- Correct node names in examples to drop underscore and use generic
name.
No functional impact except adjusting to preferred coding style.
Signed-off-by: Krzysztof Kozlowski <[email protected]>
Acked-by: Rob Herring <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86
Pull x86 platform drivers fix from Hans de Goede:
"Intel vsec driver Meteor Lake PCI ids addition"
* tag 'platform-drivers-x86-v6.2-5' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86:
platform/x86/intel/vsec: Add support for Meteor Lake
|
|
CONFIG_DRM_USE_DYNAMIC_DEBUG breaks debug prints for (at least modular)
drm drivers. The debug prints can be reinstated by manually frobbing
/sys/module/drm/parameters/debug after the fact, but at that point the
damage is done and all debugs from driver probe are lost. This makes
drivers totally undebuggable.
There's a more complete fix in progress [1], with further details, but
we need this fixed in stable kernels. Mark the feature as broken and
disable it by default, with hopes distros follow suit and disable it as
well.
[1] https://lore.kernel.org/r/[email protected]
Fixes: 84ec67288c10 ("drm_print: wrap drm_*_dbg in dyndbg descriptor factory macro")
Cc: Jim Cromie <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: Maarten Lankhorst <[email protected]>
Cc: Maxime Ripard <[email protected]>
Cc: Thomas Zimmermann <[email protected]>
Cc: David Airlie <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: [email protected]
Cc: <[email protected]> # v6.1+
Signed-off-by: Ville Syrjälä <[email protected]>
Acked-by: Greg Kroah-Hartman <[email protected]>
Acked-by: Jim Cromie <[email protected]>
Acked-by: Maxime Ripard <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Add the check for the return value of the create_singlethread_workqueue()
in order to avoid NULL pointer dereference.
Fixes: b481de9ca074 ("[IWLWIFI]: add iwlwifi wireless drivers")
Signed-off-by: Jiasheng Jiang <[email protected]>
Acked-by: Stanislaw Gruszka <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
Add the check for the return value of the create_singlethread_workqueue
in order to avoid NULL pointer dereference.
Fixes: b481de9ca074 ("[IWLWIFI]: add iwlwifi wireless drivers")
Signed-off-by: Jiasheng Jiang <[email protected]>
Acked-by: Stanislaw Gruszka <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
Replace the magic numbers for the intf_mask with their existing
RTW_PWR_INTF_PCI_MSK and RTW_PWR_INTF_USB_MSK macros to make the code
easier to understand.
Acked-by: Ping-Ke Shih <[email protected]>
Signed-off-by: Martin Blumenstingl <[email protected]>
Reviewed-by: Simon Horman <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
This code is not specific to the PCIe bus type but can be re-used by USB
and SDIO bus types. Move it to tx.{c,h} to avoid code-duplication in the
future. While here, add checking of the ac argument in
rtw_tx_ac_to_hwq() so we're not accessing entries beyond the end of the
array.
Signed-off-by: Martin Blumenstingl <[email protected]>
Reviewed-by: Simon Horman <[email protected]>
Reviewed-by: Ping-Ke Shih <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
This makes it easier to understand which values are allowed for the
"queue" variable when using the enum instead of an u8.
Acked-by: Ping-Ke Shih <[email protected]>
Signed-off-by: Martin Blumenstingl <[email protected]>
Reviewed-by: Simon Horman <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
rtw_hw_queue_mapping() and ac_to_hwq[] hold values of type enum
rtw_tx_queue_type. Change their types to reflect this to make it easier
to understand this part of the code.
While here, also change the array to be static const as it is not
supposed to be modified at runtime.
Signed-off-by: Martin Blumenstingl <[email protected]>
Reviewed-by: Simon Horman <[email protected]>
Reviewed-by: Ping-Ke Shih <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
It should be "broadcast".
Signed-off-by: Jonathan Neuschäfer <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
Add compatibility with WPS by passing on WPS enrollee information in
probe requests. Ignore other IEs supplied in the scan request. This also
has the added benefit of restoring compatibility with newer
wpa_supplicant versions that always add scan IEs. Previously, with
max_scan_ie_len set to 0, scans would always fail.
Suggested-by: Dan Williams <[email protected]>
Signed-off-by: Doug Brown <[email protected]>
Reviewed-by: Dan Williams <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
Add a define for the TLV type that will be used to add WPS enrollee
information to probe requests.
Suggested-by: Dan Williams <[email protected]>
Signed-off-by: Doug Brown <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
The existing code only converts the first IE to a TLV, but it returns a
value that takes the length of all IEs into account. When there is more
than one IE (which happens with modern wpa_supplicant versions for
example), the returned length is too long and extra junk TLVs get sent
to the firmware, resulting in an association failure.
Fix this by finding the first RSN or WPA IE and only adding that. This
has the extra benefit of working properly if the RSN/WPA IE isn't the
first one in the IE buffer.
While we're at it, clean up the code to use the available structs like
the other lbs_add_* functions instead of directly manipulating the TLV
buffer.
Signed-off-by: Doug Brown <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
Several of the structs are using the deprecated convention of items[1]
for a dynamically sized trailing element. Convert these structs to the
modern C99 style of items[]. Also fix a couple of camel case struct
element names.
Signed-off-by: Doug Brown <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
mt76 patches for 6.3
- fixes
- mt7996 cleanups
- switch to page pool allocator
- mt7996 eht support
- WED reset support
|
|
Oleksij Rempel says:
====================
net: add EEE support for KSZ9477 switch family
changes v8:
- fix comment for linkmode_to_mii_eee_cap1_t() function
- add Acked-by: Arun Ramadoss <[email protected]>
- add Reviewed-by: Alexander Duyck <[email protected]>
changes v7:
- update documentation for genphy_c45_eee_is_active()
- address review comments on "net: dsa: microchip: enable EEE support"
patch
changes v6:
- split patch set and send only first 9 patches
- Add Reviewed-by: Andrew Lunn <[email protected]>
- use 0xffff instead of GENMASK
- Document @supported_eee
- use "()" with function name in comments
changes v5:
- spell fixes
- move part of genphy_c45_read_eee_abilities() to
genphy_c45_read_eee_cap1()
- validate MDIO_PCS_EEE_ABLE register against 0xffff val.
- rename *eee_100_10000* to *eee_cap1*
- use linkmode_intersects(phydev->supported, PHY_EEE_CAP1_FEATURES)
instead of !linkmode_empty()
- add documentation to linkmode/register helpers
changes v4:
- remove following helpers:
mmd_eee_cap_to_ethtool_sup_t
mmd_eee_adv_to_ethtool_adv_t
ethtool_adv_to_mmd_eee_adv_t
and port drivers from this helpers to linkmode helpers.
- rebase against latest net-next
- port phy_init_eee() to genphy_c45_eee_is_active()
changes v3:
- rework some parts of EEE infrastructure and move it to c45 code.
- add supported_eee storage and start using it in EEE code and by the
micrel driver.
- add EEE support for ar8035 PHY
- add SmartEEE support to FEC i.MX series.
changes v2:
- use phydev->supported instead of reading MII_BMSR regiaster
- fix @get_eee > @set_eee
With this patch series we provide EEE control for KSZ9477 family of
switches and
AR8035 with i.MX6 configuration.
According to my tests, on a system with KSZ8563 switch and 100Mbit idle
link,
we consume 0,192W less power per port if EEE is enabled.
====================
Signed-off-by: David S. Miller <[email protected]>
|
|
All preparations are done. Now we can start using new functions and remove
the old code.
Signed-off-by: Oleksij Rempel <[email protected]>
Reviewed-by: Andrew Lunn <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Reduce code duplicated by migrating phy_init_eee() to
genphy_c45_eee_is_active().
Signed-off-by: Oleksij Rempel <[email protected]>
Reviewed-by: Andrew Lunn <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Migrate from genphy_config_eee_advert() to genphy_c45_write_eee_adv().
It should work as before except write operation to the EEE adv registers
will be done only if some EEE abilities was detected.
If some driver will have a regression, related driver should provide own
.get_features callback. See micrel.c:ksz9477_get_features() as example.
Signed-off-by: Oleksij Rempel <[email protected]>
Reviewed-by: Andrew Lunn <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Migrate from genphy_config_eee_advert() to genphy_c45_write_eee_adv().
It should work as before except write operation to the EEE adv registers
will be done only if some EEE abilities was detected.
If some driver will have a regression, related driver should provide own
.get_features callback. See micrel.c:ksz9477_get_features() as example.
Signed-off-by: Oleksij Rempel <[email protected]>
Reviewed-by: Andrew Lunn <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Add replacement for phy_ethtool_get/set_eee() functions.
Current phy_ethtool_get/set_eee() implementation is great and it is
possible to make it even better:
- this functionality is for devices implementing parts of IEEE 802.3
specification beyond Clause 22. The better place for this code is
phy-c45.c
- currently it is able to do read/write operations on PHYs with
different abilities to not existing registers. It is better to
use stored supported_eee abilities to avoid false read/write
operations.
- the eee_active detection will provide wrong results on not supported
link modes. It is better to validate speed/duplex properties against
supported EEE link modes.
- it is able to support only limited amount of link modes. We have more
EEE link modes...
By refactoring this code I address most of this point except of the last
one. Adding additional EEE link modes will need more work.
Signed-off-by: Oleksij Rempel <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
This function will be needed for genphy_c45_ethtool_get_eee() provided
by next patch.
Signed-off-by: Oleksij Rempel <[email protected]>
Reviewed-by: Alexander Duyck <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
KSZ8563R, which has same PHYID as KSZ9477 family, will change "EEE control
and capability 1" (Register 3.20) content depending on configuration of
"EEE advertisement 1" (Register 7.60). Changes on the 7.60 will affect
3.20 register.
So, instead of depending on register 3.20, driver should set supported_eee.
Proper supported_eee configuration is needed to make use of generic
PHY c45 set/get_eee functions provided by next patches.
Signed-off-by: Oleksij Rempel <[email protected]>
Reviewed-by: Andrew Lunn <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Add generic function for EEE abilities defined by IEEE 802.3
specification. For now following registers are supported:
- IEEE 802.3-2018 45.2.3.10 EEE control and capability 1 (Register 3.20)
- IEEE 802.3cg-2019 45.2.1.186b 10BASE-T1L PMA status register
(Register 1.2295)
Since I was not able to find any flag signaling support of these
registers, we should detect link mode abilities first and then based on
these abilities doing EEE link modes detection.
Results of EEE ability detection will be stored into new variable
phydev->supported_eee.
Signed-off-by: Oleksij Rempel <[email protected]>
Reviewed-by: Andrew Lunn <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Some of KSZ9477 family switches provides EEE support. To enable it, we
just need to register set_mac_eee/set_mac_eee handlers and validate
supported chip version and port.
Currently supported chip variants are: KSZ8563, KSZ9477, KSZ9563,
KSZ9567, KSZ9893, KSZ9896, KSZ9897. KSZ8563 supports EEE only with
100BaseTX/Full. Other chips support 100BaseTX/Full and 1000BaseTX/Full.
Low Power Idle configuration is not supported and currently not
documented in the datasheets.
EEE PHY specific tunings are not documented in the switch datasheets, but can
overlap with KSZ9131 specification.
Signed-off-by: Oleksij Rempel <[email protected]>
Reviewed-by: Andrew Lunn <[email protected]>
Acked-by: Arun Ramadoss <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Shannon Nelson says:
====================
ionic: on-chip descriptors
We start with a couple of house-keeping patches that were originally
presented for 'net', then we add support for on-chip descriptor rings
for tx-push, as well as adding support for rx-push.
I have a patch for the ethtool userland utility that I can send out
once this has been accepted.
v4: added rx-push attributes to ethtool netlink
converted CMB feature from using a priv-flag to using ethtool tx/rx-push
v3: edited commit message to describe interface-down limitation
added warn msg if cmb_inuse alloc fails
removed unnecessary clearing of phy_cmb_pages and cmb_npages
changed cmb_rings_toggle to use cmb_inuse
removed unrelated pci_set_drvdata()
removed unnecessary (u32) cast
added static inline func for writing CMB descriptors
v2: dropped the rx buffers patch
====================
Signed-off-by: David S. Miller <[email protected]>
|
|
The ionic device has on-board memory (CMB) that can be used
for descriptors as a way to speed descriptor access for faster
packet processing. It is rumored to improve latency and/or
packets-per-second for some profiles of small packet traffic,
although your mileage may vary.
Signed-off-by: Shannon Nelson <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Similar to what was done for TX_PUSH, add an RX_PUSH concept
to the ethtool interfaces.
Signed-off-by: Shannon Nelson <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Minor Code cleanup details.
Signed-off-by: Shannon Nelson <[email protected]>
Reviewed-by: Leon Romanovsky <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|