summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2023-10-23wifi: iwlwifi: mvm: fix removing pasn station for responderAvraham Stern
In case of MLD operation the station should be removed using the mld api. Fixes: fd940de72d49 ("wifi: iwlwifi: mvm: FTM responder MLO support") Signed-off-by: Avraham Stern <avraham.stern@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230926110319.7eb353abb95c.I2b30be09b99f5a2379956e010bafaa465ff053ba@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-10-23wifi: iwlwifi: pcie: clean up WFPM control bitsJohannes Berg
We define the same bit twice, remove the less precise definition and use the better one instead. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230926110319.82d2744690b3.I90c08a27dca26a181dacb069184f39ece77849b5@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-10-23wifi: iwlwifi: fix opmode start/stop raceJohannes Berg
There's a race when the device is unbound (maybe because the module is unloaded) while the opmode start hasn't finished yet. The complete(request_firmware_complete) after the opmode start was meant (and commented accordingly) to prevent this problem, but it's not sufficient when the opmode module is loaded after the firmware load already completed, which happens regularly now because firmware load doesn't require userspace, unlike module load. Fix this by using the existing opmode registration mutex to protected the start/stop flows against each other properly. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230926110319.85951554fed8.I62f20f40d79d0f136fa05e46d7fc16dc437fa3db@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-10-23wifi: iwlwifi: skip opmode start retries on dead transportJohannes Berg
These retries aren't going to succeed if the device was deemed dead and needs to be unbound/rebound/... to be recovered; skip the retries in that case. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230926110319.9f472069d75d.Ib6684c5b2ea8ed98f082c9b0e9bb2b03c3ea4fe3@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-10-23wifi: iwlwifi: pcie: propagate iwl_pcie_gen2_apm_init() errorJohannes Berg
If iwl_pcie_gen2_apm_init() fails, we should propagate the error code up, rather than ignoring it. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230926110319.883768afe77b.Ic47cb8ce0a0abba3b4745cc2a721217c33360d6c@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-10-23wifi: iwlwifi: mvm: update station's MFP flag after associationAvraham Stern
The management frames protection flag is always set when the station is not yet authorized. However, it was not cleared after association even if the association did not use MFP. As a result, all public action frames are not parsed by fw (which will cause FTM to fail, for example). Update the station MFP flag after the station is authorized. Fixes: 4c8d5c8d079e ("wifi: iwlwifi: mvm: tell firmware about per-STA MFP enablement") Signed-off-by: Avraham Stern <avraham.stern@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230926110319.2488cbd01bde.Ic0f08b7d3efcbdce27ec897f84d740fec8d169ef@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-10-23net: lan966x: remove useless code in lan966x_xtr_irq_handlerSu Hui
'err' is useless after break, remove this to save space and be more clear. Signed-off-by: Su Hui <suhui@nfschina.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-10-23isdn: mISDN: hfcsusb: Spelling fix in commentKunwu Chan
protocoll -> protocol Signed-off-by: Kunwu Chan <chentao@kylinos.cn> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-10-23Merge branch 'tcp-ts-usec-resolution'David S. Miller
Eric Dumazet says: ==================== tcp: add optional usec resolution to TCP TS As discussed in various public places in 2016, Google adopted usec resolution in RFC 7323 TS values, at Van Jacobson suggestion. Goals were : 1) better observability of delays in networking stacks/fabrics. 2) better disambiguation of events based on TSval/ecr values. 3) building block for congestion control modules needing usec resolution. Back then we implemented a schem based on private SYN options to safely negotiate the feature. For upstream submission, we chose to use a much simpler route attribute because this feature is probably going to be used in private networks. ip route add 10/8 ... features tcp_usec_ts References: https://www.ietf.org/proceedings/97/slides/slides-97-tcpm-tcp-options-for-low-latency-00.pdf https://datatracker.ietf.org/doc/draft-wang-tcpm-low-latency-opt/ First two patches are fixing old minor bugs and might be taken by stable teams (thanks to appropriate Fixes: tags) ==================== Acked-by: Neal Cardwell <ncardwell@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-10-23tcp: add TCPI_OPT_USEC_TSEric Dumazet
Add the ability to report in tcp_info.tcpi_options if a flow is using usec resolution in TCP TS val. Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-10-23tcp: add support for usec resolution in TCP TS valuesEric Dumazet
Back in 2015, Van Jacobson suggested to use usec resolution in TCP TS values. This has been implemented in our private kernels. Goals were : 1) better observability of delays in networking stacks. 2) better disambiguation of events based on TSval/ecr values. 3) building block for congestion control modules needing usec resolution. Back then we implemented a schem based on private SYN options to negotiate the feature. For upstream submission, we chose to use a route attribute, because this feature is probably going to be used in private networks [1] [2]. ip route add 10/8 ... features tcp_usec_ts Note that RFC 7323 recommends a "timestamp clock frequency in the range 1 ms to 1 sec per tick.", but also mentions "the maximum acceptable clock frequency is one tick every 59 ns." [1] Unfortunately RFC 7323 5.5 (Outdated Timestamps) suggests to invalidate TS.Recent values after a flow was idle for more than 24 days. This is the part making usec_ts a problem for peers following this recommendation for long living idle flows. [2] Attempts to standardize usec ts went nowhere: https://www.ietf.org/proceedings/97/slides/slides-97-tcpm-tcp-options-for-low-latency-00.pdf https://datatracker.ietf.org/doc/draft-wang-tcpm-low-latency-opt/ Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-10-23tcp: introduce TCP_PAWS_WRAPEric Dumazet
tcp_paws_check() uses TCP_PAWS_24DAYS constant to detect if TCP TS values might have wrapped after a long idle period. This mechanism is described in RFC 7323 5.5 (Outdated Timestamps) TCP_PAWS_24DAYS value was based on the assumption of a clock of 1 Khz. As we want to adopt a 1 Mhz clock in the future, we reduce this constant. Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-10-23tcp: add RTAX_FEATURE_TCP_USEC_TSEric Dumazet
This new dst feature flag will be used to allow TCP to use usec based timestamps instead of msec ones. ip route .... feature tcp_usec_ts Also document that RTAX_FEATURE_SACK and RTAX_FEATURE_TIMESTAMP are unused. RTAX_FEATURE_ALLFRAG is also going away soon. Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-10-23tcp: add tcp_rtt_tsopt_us()Eric Dumazet
Before adding usec TS support, add tcp_rtt_tsopt_us() helper to factorize code. Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-10-23tcp: rename tcp_time_stamp() to tcp_time_stamp_ts()Eric Dumazet
This helper returns a TSval from a TCP socket. It currently calls tcp_time_stamp_ms() but will soon be able to return a usec based TSval, depending on an upcoming tp->tcp_usec_ts field. Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-10-23tcp: move tcp_ns_to_ts() to net/ipv4/syncookies.cEric Dumazet
tcp_ns_to_ts() is only used once from cookie_init_timestamp(). Also add the 'bool usec_ts' parameter to enable usec TS later. Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-10-23tcp: rename tcp_skb_timestamp()Eric Dumazet
This helper returns a 32bit TCP TSval from skb->tstamp. As we are going to support usec or ms units soon, rename it to tcp_skb_timestamp_ts() and add a boolean to select the unit. Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-10-23tcp: replace tcp_time_stamp_raw()Eric Dumazet
In preparation of usec TCP TS support, remove tcp_time_stamp_raw() in favor of tcp_clock_ts() helper. This helper will return a suitable 32bit result to feed TS values, depending on a socket field. Also add tcp_tw_tsval() and tcp_rsk_tsval() helpers to factorize the details. We do not yet support usec timestamps. Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-10-23tcp: introduce tcp_clock_ms()Eric Dumazet
It delivers current TCP time stamp in ms unit, and is used in place of confusing tcp_time_stamp_raw() It is the same family than tcp_clock_ns() and tcp_clock_ms(). tcp_time_stamp_raw() will be replaced later for TSval contexts with a more descriptive name. Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-10-23tcp: add tcp_time_stamp_ms() helperEric Dumazet
In preparation of adding usec TCP TS values, add tcp_time_stamp_ms() for contexts needing ms based values. Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-10-23tcp: fix cookie_init_timestamp() overflowsEric Dumazet
cookie_init_timestamp() is supposed to return a 64bit timestamp suitable for both TSval determination and setting of skb->tstamp. Unfortunately it uses 32bit fields and overflows after 2^32 * 10^6 nsec (~49 days) of uptime. Generated TSval are still correct, but skb->tstamp might be set far away in the past, potentially confusing other layers. tcp_ns_to_ts() is changed to return a full 64bit value, ts and ts_now variables are changed to u64 type, and TSMASK is removed in favor of shifts operations. While we are at it, change this sequence: ts >>= TSBITS; ts--; ts <<= TSBITS; ts |= options; to: ts -= (1UL << TSBITS); Fixes: 9a568de4818d ("tcp: switch TCP TS option (RFC 7323) to 1ms clock") Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-10-23chtls: fix tp->rcv_tstamp initializationEric Dumazet
tp->rcv_tstamp should be set to tcp_jiffies, not tcp_time_stamp(). Fixes: cc35c88ae4db ("crypto : chtls - CPL handler definition") Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Ayush Sawal <ayush.sawal@chelsio.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-10-23Merge branch 'consolidate-udp-ipv6-route-lookups'David S. Miller
Beniamino Galvani says: ==================== net: consolidate IPv6 route lookup for UDP tunnels At the moment different UDP tunnels rely on different functions for IPv6 route lookup, and those functions all implement the same logic. Extend the generic lookup function so that it is suitable for all UDP tunnel implementations, and then adapt bareudp, geneve and vxlan to use it. This is similar to what already done for IPv4. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2023-10-23vxlan: use generic function for tunnel IPv6 route lookupBeniamino Galvani
The route lookup can be done now via generic function udp_tunnel6_dst_lookup() to replace the custom implementation in vxlan6_get_route(). This is similar to what already done for IPv4 in commit 6f19b2c136d9 ("vxlan: use generic function for tunnel IPv4 route lookup"). Suggested-by: Guillaume Nault <gnault@redhat.com> Signed-off-by: Beniamino Galvani <b.galvani@gmail.com> Reviewed-by: David Ahern <dsahern@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-10-23geneve: use generic function for tunnel IPv6 route lookupBeniamino Galvani
The route lookup can be done now via generic function udp_tunnel6_dst_lookup() to replace the custom implementation in geneve_get_v6_dst(). This is similar to what already done for IPv4 in commit daa2ba7ed1d1 ("geneve: use generic function for tunnel IPv4 route lookup"). Suggested-by: Guillaume Nault <gnault@redhat.com> Signed-off-by: Beniamino Galvani <b.galvani@gmail.com> Reviewed-by: David Ahern <dsahern@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-10-23ipv6: add new arguments to udp_tunnel6_dst_lookup()Beniamino Galvani
We want to make the function more generic so that it can be used by other UDP tunnel implementations such as geneve and vxlan. To do that, add the following arguments: - source and destination UDP port; - ifindex of the output interface, needed by vxlan; - the tos, because in some cases it is not taken from struct ip_tunnel_info (for example, when it's inherited from the inner packet); - the dst cache, because not all tunnel types (e.g. vxlan) want to use the one from struct ip_tunnel_info. With these parameters, the function no longer needs the full struct ip_tunnel_info as argument and we can pass only the relevant part of it (struct ip_tunnel_key). This is similar to what already done for IPv4 in commit 72fc68c6356b ("ipv4: add new arguments to udp_tunnel_dst_lookup()"). Suggested-by: Guillaume Nault <gnault@redhat.com> Signed-off-by: Beniamino Galvani <b.galvani@gmail.com> Reviewed-by: David Ahern <dsahern@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-10-23ipv6: remove "proto" argument from udp_tunnel6_dst_lookup()Beniamino Galvani
The function is now UDP-specific, the protocol is always IPPROTO_UDP. This is similar to what already done for IPv4 in commit 78f3655adcb5 ("ipv4: remove "proto" argument from udp_tunnel_dst_lookup()"). Suggested-by: Guillaume Nault <gnault@redhat.com> Signed-off-by: Beniamino Galvani <b.galvani@gmail.com> Reviewed-by: David Ahern <dsahern@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-10-23ipv6: rename and move ip6_dst_lookup_tunnel()Beniamino Galvani
At the moment ip6_dst_lookup_tunnel() is used only by bareudp. Ideally, other UDP tunnel implementations should use it, but to do so the function needs to accept new parameters that are specific for UDP tunnels, such as the ports. Prepare for these changes by renaming the function to udp_tunnel6_dst_lookup() and move it to file net/ipv6/ip6_udp_tunnel.c. This is similar to what already done for IPv4 in commit bf3fcbf7e7a0 ("ipv4: rename and move ip_route_output_tunnel()"). Suggested-by: Guillaume Nault <gnault@redhat.com> Signed-off-by: Beniamino Galvani <b.galvani@gmail.com> Reviewed-by: David Ahern <dsahern@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-10-23net: atm: Remove redundant check.Gavrilov Ilia
Checking the 'adev' variable is unnecessary, because 'cdev' has already been checked earlier. Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 656d98b09d57 ("[ATM]: basic sysfs support for ATM devices") Signed-off-by: Gavrilov Ilia <Ilia.Gavrilov@infotecs.ru> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-10-22Linux 6.6-rc7v6.6-rc7Linus Torvalds
2023-10-22Merge tag 'phy-fixes-6.6' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy Pull phy fixes from Vinod Koul: - mapphone-mdm6600 runtime pm & pinctrl handling fixes - Qualcomm qmp usb pcs register fixes, qmp pcie register size warning fix, m31 fixes for wrong pointer in PTR_ERR and dropping wrong vreg check, qmp combo fix for 8550 power config register - realtek usb fix for debugfs_create_dir() and kconfig dependency * tag 'phy-fixes-6.6' of git://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy: phy: realtek: Realtek PHYs should depend on ARCH_REALTEK phy: qualcomm: Fix typos in comments phy: qcom-qmp-combo: initialize PCS_USB registers phy: qcom-qmp-combo: Square out 8550 POWER_STATE_CONFIG1 phy: qcom: m31: Remove unwanted qphy->vreg is NULL check phy: realtek: usb: Drop unnecessary error check for debugfs_create_dir() phy: qcom: phy-qcom-m31: change m31_ipq5332_regs to static phy: qcom: phy-qcom-m31: fix wrong pointer pass to PTR_ERR() dt-bindings: phy: qcom,ipq8074-qmp-pcie: fix warning regarding reg size phy: qcom-qmp-usb: split PCS_USB init table for sc8280xp and sa8775p phy: qcom-qmp-usb: initialize PCS_USB registers phy: mapphone-mdm6600: Fix pinctrl_pm handling for sleep pins phy: mapphone-mdm6600: Fix runtime PM for remove phy: mapphone-mdm6600: Fix runtime disable on probe
2023-10-22Merge tag 'efi-fixes-for-v6.6-3' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi Pull EFI fixes from Ard Biesheuvel: "The boot_params pointer fix uses a somewhat ugly extern struct declaration but this will be cleaned up the next cycle. - don't try to print warnings to the console when it is no longer available - fix theoretical memory leak in SSDT override handling - make sure that the boot_params global variable is set before the KASLR code attempts to hash it for 'randomness' - avoid soft lockups in the memory acceptance code" * tag 'efi-fixes-for-v6.6-3' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi: efi/unaccepted: Fix soft lockups caused by parallel memory acceptance x86/boot: efistub: Assign global boot_params variable efi: fix memory leak in krealloc failure handling x86/efistub: Don't try to print after ExitBootService()
2023-10-22tcp: fix wrong RTO timeout when received SACK renegingFred Chen
This commit fix wrong RTO timeout when received SACK reneging. When an ACK arrived pointing to a SACK reneging, tcp_check_sack_reneging() will rearm the RTO timer for min(1/2*srtt, 10ms) into to the future. But since the commit 62d9f1a6945b ("tcp: fix TLP timer not set when CA_STATE changes from DISORDER to OPEN") merged, the tcp_set_xmit_timer() is moved after tcp_fastretrans_alert()(which do the SACK reneging check), so the RTO timeout will be overwrited by tcp_set_xmit_timer() with icsk_rto instead of 1/2*srtt. Here is a packetdrill script to check this bug: 0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3 +0 bind(3, ..., ...) = 0 +0 listen(3, 1) = 0 // simulate srtt to 100ms +0 < S 0:0(0) win 32792 <mss 1000, sackOK,nop,nop,nop,wscale 7> +0 > S. 0:0(0) ack 1 <mss 1460,nop,nop,sackOK,nop,wscale 7> +.1 < . 1:1(0) ack 1 win 1024 +0 accept(3, ..., ...) = 4 +0 write(4, ..., 10000) = 10000 +0 > P. 1:10001(10000) ack 1 // inject sack +.1 < . 1:1(0) ack 1 win 257 <sack 1001:10001,nop,nop> +0 > . 1:1001(1000) ack 1 // inject sack reneging +.1 < . 1:1(0) ack 1001 win 257 <sack 9001:10001,nop,nop> // we expect rto fired in 1/2*srtt (50ms) +.05 > . 1001:2001(1000) ack 1 This fix remove the FLAG_SET_XMIT_TIMER from ack_flag when tcp_check_sack_reneging() set RTO timer with 1/2*srtt to avoid being overwrited later. Fixes: 62d9f1a6945b ("tcp: fix TLP timer not set when CA_STATE changes from DISORDER to OPEN") Signed-off-by: Fred Chen <fred.chenchen03@gmail.com> Reviewed-by: Neal Cardwell <ncardwell@google.com> Tested-by: Neal Cardwell <ncardwell@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-10-22ACPI: NFIT: Install Notify() handler before getting NFIT tableXiang Chen
If there is no NFIT at startup, it will return 0 immediately in function acpi_nfit_add() and will not install Notify() handler. If hotplugging a nvdimm device later, it will not be identified as there is no Notify() handler. Install the handler before getting NFI table in function acpi_nfit_add() to avoid above issue. Fixes: dcca12ab62a2 ("ACPI: NFIT: Install Notify() handler directly") Signed-off-by: Xiang Chen <chenxiang66@hisilicon.com> [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-10-22Merge branch 'r8152-reg-garbage'David S. Miller
Douglas Anderson says: ==================== r8152: Avoid writing garbage to the adapter's registers This series is the result of a cooperative debug effort between Realtek and the ChromeOS team. On ChromeOS, we've noticed that Realtek Ethernet adapters can sometimes get so wedged that even a reboot of the host can't get them to enumerate again, assuming that the adapter was on a powered hub and din't lose power when the host rebooted. This is sometimes seen in the ChromeOS automated testing lab. The only way to recover adapters in this state is to manually power cycle them. I managed to reproduce one instance of this wedging (unknown if this is truly related to what the test lab sees) by doing this: 1. Start a flood ping from a host to the device. 2. Drop the device into kdb. 3. Wait 90 seconds. 4. Resume from kdb (the "g" command). 5. Wait another 45 seconds. Upon analysis, Realtek realized this was happening: 1. The Linux driver was getting a "Tx timeout" after resuming from kdb and then trying to reset itself. 2. As part of the reset, the Linux driver was attempting to do a read-modify-write of the adapter's registers. 3. The read would fail (due to a timeout) and the driver pretended that the register contained all 0xFFs. See commit f53a7ad18959 ("r8152: Set memory to all 0xFFs on failed reg reads") 4. The driver would take this value of all 0xFFs, modify it, and attempt to write it back to the adapter. 5. By this time the USB channel seemed to recover and thus we'd successfully write a value that was mostly 0xFFs to the adpater. 6. The adapter didn't like this and would wedge itself. Another Engineer also managed to reproduce wedging of the Realtek Ethernet adpater during a reboot test on an AMD Chromebook. In that case he was sometimes seeing -EPIPE returned from the control transfers. This patch series fixes both issues. Changes in v5: - ("Run the unload routine if we have errors during probe") new for v5. - ("Cancel hw_phy_work if we have an error in probe") new for v5. - ("Release firmware if we have an error in probe") new for v5. - Removed extra mutex_unlock() left over in v4. - Fixed minor typos. - Don't do queue an unbind/bind reset if probe fails; just retry probe. Changes in v4: - Took out some unnecessary locks/unlocks of the control mutex. - Added comment about reading version causing probe fail if 3 fails. - Added text to commit msg about the potential unbind/bind loop. Changes in v3: - Fixed v2 changelog ending up in the commit message. - farmework -> framework in comments. Changes in v2: - ("Check for unplug in rtl_phy_patch_request()") new for v2. - ("Check for unplug in r8153b_ups_en() / r8153c_ups_en()") new for v2. - ("Rename RTL8152_UNPLUG to RTL8152_INACCESSIBLE") new for v2. - Reset patch no longer based on retry patch, since that was dropped. - Reset patch should be robust even if failures happen in probe. - Switched booleans to bits in the "flags" variable. - Check for -ENODEV instead of "udev->state == USB_STATE_NOTATTACHED" ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2023-10-22r8152: Block future register access if register access failsDouglas Anderson
Even though the functions to read/write registers can fail, most of the places in the r8152 driver that read/write register values don't check error codes. The lack of error code checking is problematic in at least two ways. The first problem is that the r8152 driver often uses code patterns similar to this: x = read_register() x = x | SOME_BIT; write_register(x); ...with the above pattern, if the read_register() fails and returns garbage then we'll end up trying to write modified garbage back to the Realtek adapter. If the write_register() succeeds that's bad. Note that as of commit f53a7ad18959 ("r8152: Set memory to all 0xFFs on failed reg reads") the "garbage" returned by read_register() will at least be consistent garbage, but it is still garbage. It turns out that this problem is very serious. Writing garbage to some of the hardware registers on the Ethernet adapter can put the adapter in such a bad state that it needs to be power cycled (fully unplugged and plugged in again) before it can enumerate again. The second problem is that the r8152 driver generally has functions that are long sequences of register writes. Assuming everything will be OK if a random register write fails in the middle isn't a great assumption. One might wonder if the above two problems are real. You could ask if we would really have a successful write after a failed read. It turns out that the answer appears to be "yes, this can happen". In fact, we've seen at least two distinct failure modes where this happens. On a sc7180-trogdor Chromebook if you drop into kdb for a while and then resume, you can see: 1. We get a "Tx timeout" 2. The "Tx timeout" queues up a USB reset. 3. In rtl8152_pre_reset() we try to reinit the hardware. 4. The first several (2-9) register accesses fail with a timeout, then things recover. The above test case was actually fixed by the patch ("r8152: Increase USB control msg timeout to 5000ms as per spec") but at least shows that we really can see successful calls after failed ones. On a different (AMD) based Chromebook with a particular adapter, we found that during reboot tests we'd also sometimes get a transitory failure. In this case we saw -EPIPE being returned sometimes. Retrying worked, but retrying is not always safe for all register accesses since reading/writing some registers might have side effects (like registers that clear on read). Let's fully lock out all register access if a register access fails. When we do this, we'll try to queue up a USB reset and try to unlock register access after the reset. This is slightly tricker than it sounds since the r8152 driver has an optimized reset sequence that only works reliably after probe happens. In order to handle this, we avoid the optimized reset if probe didn't finish. Instead, we simply retry the probe routine in this case. When locking out access, we'll use the existing infrastructure that the driver was using when it detected we were unplugged. This keeps us from getting stuck in delay loops in some parts of the driver. Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Grant Grundler <grundler@chromium.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-10-22r8152: Rename RTL8152_UNPLUG to RTL8152_INACCESSIBLEDouglas Anderson
Whenever the RTL8152_UNPLUG is set that just tells the driver that all accesses will fail and we should just immediately bail. A future patch will use this same concept at a time when the driver hasn't actually been unplugged but is about to be reset. Rename the flag in preparation for the future patch. This is a no-op change and just a search and replace. Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Grant Grundler <grundler@chromium.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-10-22r8152: Check for unplug in r8153b_ups_en() / r8153c_ups_en()Douglas Anderson
If the adapter is unplugged while we're looping in r8153b_ups_en() / r8153c_ups_en() we could end up looping for 10 seconds (20 ms * 500 loops). Add code similar to what's done in other places in the driver to check for unplug and bail. Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Grant Grundler <grundler@chromium.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-10-22r8152: Check for unplug in rtl_phy_patch_request()Douglas Anderson
If the adapter is unplugged while we're looping in rtl_phy_patch_request() we could end up looping for 10 seconds (2 ms * 5000 loops). Add code similar to what's done in other places in the driver to check for unplug and bail. Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Grant Grundler <grundler@chromium.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-10-22r8152: Release firmware if we have an error in probeDouglas Anderson
The error handling in rtl8152_probe() is missing a call to release firmware. Add it in to match what's in the cleanup code in rtl8152_disconnect(). Fixes: 9370f2d05a2a ("r8152: support request_firmware for RTL8153") Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Grant Grundler <grundler@chromium.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-10-22r8152: Cancel hw_phy_work if we have an error in probeDouglas Anderson
The error handling in rtl8152_probe() is missing a call to cancel the hw_phy_work. Add it in to match what's in the cleanup code in rtl8152_disconnect(). Fixes: a028a9e003f2 ("r8152: move the settings of PHY to a work queue") Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Grant Grundler <grundler@chromium.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-10-22r8152: Run the unload routine if we have errors during probeDouglas Anderson
The rtl8152_probe() function lacks a call to the chip-specific unload() routine when it sees an error in probe. Add it in to match the cleanup code in rtl8152_disconnect(). Fixes: ac718b69301c ("net/usb: new driver for RTL8152") Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Grant Grundler <grundler@chromium.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-10-22r8152: Increase USB control msg timeout to 5000ms as per specDouglas Anderson
According to the comment next to USB_CTRL_GET_TIMEOUT and USB_CTRL_SET_TIMEOUT, although sending/receiving control messages is usually quite fast, the spec allows them to take up to 5 seconds. Let's increase the timeout in the Realtek driver from 500ms to 5000ms (using the #defines) to account for this. This is not just a theoretical change. The need for the longer timeout was seen in testing. Specifically, if you drop a sc7180-trogdor based Chromebook into the kdb debugger and then "go" again after sitting in the debugger for a while, the next USB control message takes a long time. Out of ~40 tests the slowest USB control message was 4.5 seconds. While dropping into kdb is not exactly an end-user scenario, the above is similar to what could happen due to an temporary interrupt storm, what could happen if there was a host controller (HW or SW) issue, or what could happen if the Realtek device got into a confused state and needed time to recover. This change is fairly critical since the r8152 driver in Linux doesn't expect register reads/writes (which are backed by USB control messages) to fail. Fixes: ac718b69301c ("net/usb: new driver for RTL8152") Suggested-by: Hayes Wang <hayeswang@realtek.com> Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Grant Grundler <grundler@chromium.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-10-22Merge branch 'bnxt_en-next'David S. Miller
Michael Chan says: ==================== bnxt_en: Update for net-next The first 2 patches are fixes for the recently added hwmon changes. The next 6 patches are enhancements to support ethtool lanes and all the proper supported and advertised link modes. Before these patches, the driver was only supporting the link modes for copper media. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2023-10-22bnxt_en: extend media types to supported and autoneg modesEdwin Peer
The current driver code does not accurately report the supported and advertised link modes. It basically always assumes the media type is copper for any particular speed. Utilize the recently added link mode mappings to accurately report fully qualified ethtool link modes for advertised and supported speeds. If the media type is known, we will report the supported link modes for that media only. If the media is not known, we will report all possible supported link modes. The user can now specify any supported link modes (including NRZ and PAM4) to advertise for autoneg. It used to only accept copper NRZ modes. Signed-off-by: Edwin Peer <edwin.peer@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-10-22bnxt_en: convert to linkmode_set_bit() APIEdwin Peer
Barring the BNXT_FW_TO_ETHTOOL speed macros, which will be removed in the next patch, update code to use the newer API. No functional change. Signed-off-by: Edwin Peer <edwin.peer@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-10-22bnxt_en: Refactor NRZ/PAM4 link speed related logicMichael Chan
Refactor some NRZ/PAM4 link speed related logic into helper functions. The NRZ and PAM4 link parameters are stored in separate structure fields. The driver logic has to check whether it is in NRZ or PAM4 mode and then use the appropriate field. Refactor this logic into helper functions for better readability. Reviewed-by: Damodharam Ammepalli <damodharam.ammepalli@broadcom.com> Reviewed-by: Ajit Khaparde <ajit.khaparde@broadcom.com> Reviewed-by: Andy Gospodarek <andrew.gospodarek@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-10-22bnxt_en: refactor speed independent ethtool modesEdwin Peer
A future patch in this series will change the algorithm used to determine ethtool speed and media modes. Extract the handling of the unrelated pause, autoneg modes into an independent function. Also separate FEC handling out of bnxt_fw_to_ethtool_*_spds(). No functional change. Signed-off-by: Edwin Peer <edwin.peer@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-10-22bnxt_en: support lane configuration via ethtoolEdwin Peer
Recent kernels support changing the number of link lanes via ethtool. This is useful for determining the appropriate signal mode to use when a given link speed can be achieved using different lane configurations. Accept the ethtool lanes parameter when configuring forced speed. If there is no lanes parameter, select a default. Signed-off-by: Edwin Peer <edwin.peer@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-10-22bnxt_en: add infrastructure to lookup ethtool link modeEdwin Peer
Add infrastructure to look up the enum ethtool_link_mode_bit_indices from link information provided by the firmware. The link speed, signal mode, and media type returned by firmware will be used to look up the ethtool link mode. The immediate benefit is that once the link mode is determined, we can now use ethtool_params_from_link_mode() to fill the basic ethtool parameters including the number of lanes. Lanes will be fully supported in the next patch. Signed-off-by: Edwin Peer <edwin.peer@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
generated by cgit (git 2.34.1) at 2025-09-13 13:12:38 +0000