- 08 Nov, 2019 3 commits
-
-
David Ahern authored
Hendrik reported routes in the main table using source address are not removed when the address is removed. The problem is that fib_sync_down_addr does not account for devices in the default VRF which are associated with the main table. Fix by updating the table id reference. Fixes: 5a56a0b3 ("net: Don't delete routes in different VRFs") Reported-by:
Hendrik Donner <hd@os-cillation.de> Signed-off-by:
David Ahern <dsahern@kernel.org> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Eric Dumazet authored
While looking at a syzbot KCSAN report [1], I found multiple issues in this code : 1) fib6_nh->last_probe has an initial value of 0. While probably okay on 64bit kernels, this causes an issue on 32bit kernels since the time_after(jiffies, 0 + interval) might be false ~24 days after boot (for HZ=1000) 2) The data-race found by KCSAN I could use READ_ONCE() and WRITE_ONCE(), but we also can take the opportunity of not piling-up too many rt6_probe_deferred() works by using instead cmpxchg() so that only one cpu wins the race. [1] BUG: KCSAN: data-race in find_match / find_match write to 0xffff8880bb7aabe8 of 8 bytes by interrupt on cpu 1: rt6_probe net/ipv6/route.c:663 [inline] find_match net/ipv6/route.c:757 [inline] find_match+0x5bd/0x790 net/ipv6/route.c:733 __find_rr_leaf+0xe3/0x780 net/ipv6/route.c:831 find_rr_leaf net/ipv6/route.c:852 [inline] rt6_select net/ipv6/route.c:896 [inline] fib6_table_lookup+0x383/0x650 net/ipv6/route.c:2164 ip6_pol_route+0xee/0x5c0 net/ipv6/route.c:2200 ip6_pol_route_output+0x48/0x60 net/ipv6/route.c:2452 fib6_rule_lookup+0x3d6/0x470 net/ipv6/fib6_rules.c:117 ip6_route_output_flags_noref+0x16b/0x230 net/ipv6/route.c:2484 ip6_route_output_flags+0x50/0x1a0 net/ipv6/route.c:2497 ip6_dst_lookup_tail+0x25d/0xc30 net/ipv6/ip6_output.c:1049 ip6_dst_lookup_flow+0x68/0x120 net/ipv6/ip6_output.c:1150 inet6_csk_route_socket+0x2f7/0x420 net/ipv6/inet6_connection_sock.c:106 inet6_csk_xmit+0x91/0x1f0 net/ipv6/inet6_connection_sock.c:121 __tcp_transmit_skb+0xe81/0x1d60 net/ipv4/tcp_output.c:1169 tcp_transmit_skb net/ipv4/tcp_output.c:1185 [inline] tcp_xmit_probe_skb+0x19b/0x1d0 net/ipv4/tcp_output.c:3735 read to 0xffff8880bb7aabe8 of 8 bytes by interrupt on cpu 0: rt6_probe net/ipv6/route.c:657 [inline] find_match net/ipv6/route.c:757 [inline] find_match+0x521/0x790 net/ipv6/route.c:733 __find_rr_leaf+0xe3/0x780 net/ipv6/route.c:831 find_rr_leaf net/ipv6/route.c:852 [inline] rt6_select net/ipv6/route.c:896 [inline] fib6_table_lookup+0x383/0x650 net/ipv6/route.c:2164 ip6_pol_route+0xee/0x5c0 net/ipv6/route.c:2200 ip6_pol_route_output+0x48/0x60 net/ipv6/route.c:2452 fib6_rule_lookup+0x3d6/0x470 net/ipv6/fib6_rules.c:117 ip6_route_output_flags_noref+0x16b/0x230 net/ipv6/route.c:2484 ip6_route_output_flags+0x50/0x1a0 net/ipv6/route.c:2497 ip6_dst_lookup_tail+0x25d/0xc30 net/ipv6/ip6_output.c:1049 ip6_dst_lookup_flow+0x68/0x120 net/ipv6/ip6_output.c:1150 inet6_csk_route_socket+0x2f7/0x420 net/ipv6/inet6_connection_sock.c:106 inet6_csk_xmit+0x91/0x1f0 net/ipv6/inet6_connection_sock.c:121 __tcp_transmit_skb+0xe81/0x1d60 net/ipv4/tcp_output.c:1169 Reported by Kernel Concurrency Sanitizer on: CPU: 0 PID: 18894 Comm: udevd Not tainted 5.4.0-rc3+ #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Fixes: cc3a86c8 ("ipv6: Change rt6_probe to take a fib6_nh") Fixes: f547fac6 ("ipv6: rate-limit probes for neighbourless routes") Signed-off-by:
Eric Dumazet <edumazet@google.com> Reported-by:
syzbot <syzkaller@googlegroups.com> Reviewed-by:
David Ahern <dsahern@gmail.com> Signed-off-by:
-
Salil Mehta authored
This patch fixes the problem of the spin locks, originally meant for the netpoll path of hns driver, causing deadlock in the normal NAPI poll path. The issue happened due to the presence of the stray leftover spin lock code related to the netpoll, whose support was earlier removed from the HNS[1], got activated due to enabling of NET_POLL_CONTROLLER switch. Earlier background: The netpoll handling code originally had this bug(as identified by Marc Zyngier[2]) of wrong spin lock API being used which did not disable the interrupts and hence could cause locking issues. i.e. if the lock were first acquired in context to thread like 'ip' util and this lock if ever got later acquired again in context to the interrupt context like TX/RX (Interrupts could always pre-empt the lock holding task and acquire the lock again) and hence could cause deadlock. Proposed Solution: 1. If the netpoll was enabled in the HNS driver, which is not right now, we could have simply used spin_[un]lock_irqsave() 2. But as netpoll is disabled, therefore, it is best to get rid of the existing locks and stray code for now. This should solve the problem reported by Marc. [1] https://git.kernel.org/torvalds/c/4bd2c03be7 [2] https://patchwork.ozlabs.org/patch/1189139/ Fixes: 4bd2c03b ("net: hns: remove ndo_poll_controller") Cc: lipeng <lipeng321@huawei.com> Cc: Yisen Zhuang <yisen.zhuang@huawei.com> Cc: Eric Dumazet <edumazet@google.com> Cc: David S. Miller <davem@davemloft.net> Reported-by:
Marc Zyngier <maz@kernel.org> Acked-by:
Salil Mehta <salil.mehta@huawei.com> Signed-off-by:
-
- 07 Nov, 2019 25 commits
-
-
Aleksander Morgado authored
Exactly same layout as the default DW5821e module, just a different vid/pid. The QMI interface is exposed in USB configuration #1: P: Vendor=413c ProdID=81e0 Rev=03.18 S: Manufacturer=Dell Inc. S: Product=DW5821e-eSIM Snapdragon X20 LTE S: SerialNumber=0123456789ABCDEF C: #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=500mA I: If#=0x0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan I: If#=0x1 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=00 Prot=00 Driver=usbhid I: If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I: If#=0x3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I: If#=0x4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I: If#=0x5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option Signed-off-by:
Aleksander Morgado <aleksander@aleksander.es> Signed-off-by:
-
Oliver Neukum authored
A malicious device may give half an answer when asked for its MTU. The driver will proceed after this with a garbage MTU. Anything but a complete answer must be treated as an error. V2: used sizeof as request by Alexander Reported-and-tested-by: syzbot+0631d878823ce2411636@syzkaller.appspotmail.com Signed-off-by:
Oliver Neukum <oneukum@suse.com> Signed-off-by:
-
Pan Bian authored
The function nfc_put_device(dev) is called twice to drop the reference to dev when there is no associated local llcp. Remove one of them to fix the bug. Fixes: 52feb444 ("NFC: Extend netlink interface for LTO, RW, and MIUX parameters support") Fixes: d9b8d8e1 ("NFC: llcp: Service Name Lookup netlink interface") Signed-off-by:
Pan Bian <bianpan2016@163.com> Reviewed-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
-
Pan Bian authored
The variable nfcid_skb is not changed in the callee nfc_hci_get_param() if error occurs. Consequently, the freed variable nfcid_skb will be freed again, resulting in a double free bug. Set nfcid_skb to NULL after releasing it to fix the bug. Signed-off-by:
-
Huazhong Tan authored
Since old firmware does not support HCLGE_OPC_PF_RST_DONE, it will return -EOPNOTSUPP to the driver when received this command. So for this case, it should just print a warning and return success to the caller. Fixes: 72e2fb07 ("net: hns3: clear reset interrupt status in hclge_irq_handle()") Signed-off-by:
Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linuxDavid S. Miller authored
Saeed Mahamees says: ==================== Mellanox, mlx5 fixes 2019-11-06 This series introduces some fixes to mlx5 driver. Please pull and let me know if there is any problem. No -stable this time. ==================== Signed-off-by: -
Heiner Kallweit authored
Functions like phy_modify_paged() read the current page, on Realtek PHY's this means reading the value of register 0x1f. Add special handling for reading this register, similar to what we do already in r8168g_mdio_write(). Currently we read a random value that by chance seems to be 0 always. Fixes: a2928d28 ("r8169: use paged versions of phylib MDIO access functions") Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by:
-
David S. Miller authored
Jose Abreu says: ==================== net: stmmac: Fixes for -net Misc fixes for stmmac. Patch 1/11 and 2/11, use the correct variable type for bitrev32() calls. Patch 3/11, fixes the random failures the we were seing when running selftests. Patch 4/11, prevents a crash that can occur when receiving AVB packets and with SPH feature enabled on XGMAC. Patch 5/11, fixes the correct settings for CBS on XGMAC. Patch 6/11, corrects the interpretation of AVB feature on XGMAC. Patch 7/11, disables Flow Control for AVB enabled queues on XGMAC. Patch 8/11, disables MMC interrupts on XGMAC, preventing a storm of interrupts. Patch 9/11, fixes the number of packets that were being taken into account in the RX path cleaning function. Patch 10/11, fixes an incorrect descriptor setting that could cause IP misbehavior. Patch 11/11, fixes the IOC generation mechanism when multiple descriptors are used. ==================== Signed-off-by: -
Jose Abreu authored
IOC bit must be only set in the last descriptor. Move the logic up a little bit to make sure it's set in the correct descriptor. Signed-off-by:
Jose Abreu <Jose.Abreu@synopsys.com> Signed-off-by:
-
Jose Abreu authored
When using addressing > 32 bits the TSO first descriptor only has the header so we can't set the payload field for this descriptor. Let's reset the variable so that buffer 2 value is zero. Fixes: a993db88 ("net: stmmac: Enable support for > 32 Bits addressing in XGMAC") Signed-off-by:
-
Jose Abreu authored
Currently, stmmac_rx() is counting the number of descriptors but it should count the number of packets as specified by the NAPI limit. Fix this. Fixes: ec222003 ("net: stmmac: Prepare to add Split Header support") Signed-off-by:
-
Jose Abreu authored
MMC interrupts were being enabled, which is not what we want because it will lead to a storm of interrupts that are not handled at all. Fix it by disabling all MMC interrupts for XGMAC. Fixes: b6cdf09f ("net: stmmac: xgmac: Implement MMC counters") Signed-off-by:
-
Jose Abreu authored
When in AVB mode we need to disable flow control to prevent MAC from pausing in TX side. Fixes: ec6ea8e3 ("net: stmmac: Add CBS support in XGMAC2") Signed-off-by:
-
Jose Abreu authored
Fix incorrect precedence of operators. For reference: AV implies AV Feature but RAV implies only RX side AV Feature. As we want full AV features we need to check RAV. Fixes: c2b69474 ("net: stmmac: xgmac: Correct RAVSEL field interpretation") Signed-off-by:
-
Jose Abreu authored
When we change between Transmission Scheduling Algorithms, we need to clear previous values so that the new chosen algorithm is correctly selected. Fixes: ec6ea8e3 ("net: stmmac: Add CBS support in XGMAC2") Signed-off-by:
-
Jose Abreu authored
Split Header length is only available when L34T == 0. Fix this by correctly checking if L34T is zero before trying to get Header length. Fixes: 67afd6d1 ("net: stmmac: Add Split Header support and enable it in XGMAC cores") Signed-off-by:
-
Jose Abreu authored
In L2 tests that filter packets by destination MAC address we need to prevent false positives that can occur if we add an address that collides with the existing ones. To fix this, lets manually check if the new address to be added is already present in the NIC and use a different one if so. For Hash filtering this also envolves converting the address to the hash. Fixes: 091810db ("net: stmmac: Introduce selftests support") Signed-off-by:
-
Jose Abreu authored
The bitrev32 function returns an u32 var, not an int. Fix it. Fixes: 0efedbf1 ("net: stmmac: xgmac: Fix XGMAC selftests") Signed-off-by:
-
Jose Abreu authored
The bitrev32 function returns an u32 var, not an int. Fix it. Fixes: 477286b5 ("stmmac: add GMAC4 core support") Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nfDavid S. Miller authored
Pablo Neira Ayuso says: ==================== Netfilter fixes for net The following patchset contains Netfilter fixes for net: 1) Missing register size validation in bitwise and cmp offloads. 2) Fix error code in ip_set_sockfn_get() when copy_to_user() fails, from Dan Carpenter. 3) Oneliner to copy MAC address in IPv6 hash:ip,mac sets, from Stefano Brivio. 4) Missing policy validation in ipset with NL_VALIDATE_STRICT, from Jozsef Kadlecsik. 5) Fix unaligned access to private data area of nf_tables instructions, from Lukas Wunner. 6) Relax check for object updates, reported as a regression by Eric Garver, patch from Fernando Fernandez Mancera. 7) Crash on ebtables dnat extension when used from the output path. From Florian Westphal. 8) Fix bogus EOPNOTSUPP when updating basechain flags. 9) Fix bogus EBUSY when updating a basechain that is already offloaded. ==================== Signed-off-by: -
Ursula Braun authored
If a pnet table entry is to be added mentioning a valid ethernet interface, but an invalid infiniband or ISM device, the dev_put() operation for the ethernet interface is called twice, resulting in a negative refcount for the ethernet interface, which disables removal of such a network interface. This patch removes one of the dev_put() calls. Fixes: 890a2cb4 ("net/smc: rework pnet table") Signed-off-by:
Ursula Braun <ubraun@linux.ibm.com> Signed-off-by:
Karsten Graul <kgraul@linux.ibm.com> Signed-off-by:
-
David S. Miller authored
Jakub Kicinski says: ==================== net/tls: add a TX lock Some time ago Pooja and Mallesham started reporting crashes with an async accelerator. After trying to poke the existing logic into shape I came to the conclusion that it can't be trusted, and to preserve our sanity we should just add a lock around the TX side. First patch removes the sk_write_pending checks from the write space callbacks. Those don't seem to have a logical justification. Patch 2 adds the TX lock and patch 3 associated test (which should hang with current net). Mallesham reports that even with these fixes applied the async accelerator workload still occasionally hangs waiting for socket memory. I suspect that's strictly related to the way async crypto is integrated in TLS, so I think we should get these into net or net-next and move from there. ==================== Signed-off-by: -
Jakub Kicinski authored
Add a test which spawns 16 threads and performs concurrent send and recv calls on the same socket. Signed-off-by:
Jakub Kicinski <jakub.kicinski@netronome.com> Reviewed-by:
Simon Horman <simon.horman@netronome.com> Signed-off-by:
-
Jakub Kicinski authored
TLS TX needs to release and re-acquire the socket lock if send buffer fills up. TLS SW TX path currently depends on only allowing one thread to enter the function by the abuse of sk_write_pending. If another writer is already waiting for memory no new ones are allowed in. This has two problems: - writers don't wake other threads up when they leave the kernel; meaning that this scheme works for single extra thread (second application thread or delayed work) because memory becoming available will send a wake up request, but as Mallesham and Pooja report with larger number of threads it leads to threads being put to sleep indefinitely; - the delayed work does not get _scheduled_ but it may _run_ when other writers are present leading to crashes as writers don't expect state to change under their feet (same records get pushed and freed multiple times); it's hard to reliably bail from the work, however, because the mere presence of a writer does not guarantee that the writer will push pending records before exiting. Ensuring wakeups always happen will make the code basically open code a mutex. Just use a mutex. The TLS HW TX path does not have any locking (not even the sk_write_pending hack), yet it uses a per-socket sg_tx_data array to push records. Fixes: a42055e8 ("net/tls: Add support for async encryption of records for performance") Reported-by:
Mallesham Jatharakonda <mallesh537@gmail.com> Reported-by:
Pooja Trivedi <poojatrivedi@gmail.com> Signed-off-by:
-
Jakub Kicinski authored
sk_write_pending being not zero does not guarantee that partial record will be pushed. If the thread waiting for memory times out the pending record may get stuck. In case of tls_device there is no path where parial record is set and writer present in the first place. Partial record is set only in tls_push_sg() and tls_push_sg() will return an error immediately. All tls_device callers of tls_push_sg() will return (and not wait for memory) if it failed. Fixes: a42055e8 ("net/tls: Add support for async encryption of records for performance") Signed-off-by:
-
- 06 Nov, 2019 12 commits
-
-
Vladimir Oltean authored
The "read-modify-write register index" function is declared with a confusing prototype: the "mask" and "reg" arguments are swapped. Fortunately, this does not affect callers so far. Both arguments are u32, and the wrapper macros (ocelot_rmw_ix etc) have the arguments in the correct order (the one from ocelot_io.c). Signed-off-by:
Vladimir Oltean <olteanv@gmail.com> Signed-off-by:
-
David S. Miller authored
Vladimir Oltean says: ==================== Bonding fixes for Ocelot switch This series fixes 2 issues with bonding in a system that integrates the ocelot driver, but the ports that are bonded do not actually belong to ocelot. ==================== Signed-off-by: -
Claudiu Manoil authored
lag_upper_info may be NULL on slave removal. Fixes: dc96ee37 ("net: mscc: ocelot: add bonding support") Signed-off-by:
Claudiu Manoil <claudiu.manoil@nxp.com> Signed-off-by:
-
Claudiu Manoil authored
The check that the event is actually for this device should be moved from the "port" handler to the net device handler. Otherwise the port handler will deny bonding configuration for other net devices in the same system (like enetc in the LS1028A) that don't have the lag_upper_info->tx_type restriction that ocelot has. Fixes: dc96ee37 ("net: mscc: ocelot: add bonding support") Signed-off-by:
-
Dmytro Linkin authored
For vlan push action, if eswitch flow source capability is enabled, flow source value compared with MLX5_VPORT_UPLINK enum, to determine uplink port. This lead to syndrome in dmesg if try to add vlan push action. For example: $ tc filter add dev vxlan0 ingress protocol ip prio 1 flower \ enc_dst_port 4789 \ action tunnel_key unset pipe \ action vlan push id 20 pipe \ action mirred egress redirect dev ens1f0_0 $ dmesg ... [ 2456.883693] mlx5_core 0000:82:00.0: mlx5_cmd_check:756:(pid 5273): SET_FLOW_TABLE_ENTRY(0x936) op_mod(0x0) failed, status bad parameter(0x3), syndrome (0xa9c090) Use the correct enum value MLX5_FLOW_CONTEXT_FLOW_SOURCE_UPLINK. Fixes: bb204dcf39fe ("net/mlx5e: Determine source port properly for vlan push action") Signed-off-by:Dmytro Linkin <dmitrolin@mellanox.com> Reviewed-by:
Vlad Buslov <vladbu@mellanox.com> Reviewed-by:
Roi Dayan <roid@mellanox.com> Signed-off-by:
Saeed Mahameed <saeedm@mellanox.com>
-
Alex Vesker authored
During rule creation hw_ste_arr was not freed. Fixes: 41d07074 ("net/mlx5: DR, Expose steering rule functionality") Signed-off-by:
Alex Vesker <valex@mellanox.com> Signed-off-by:
-
Alex Vesker authored
The rewrite data was no freed. Fixes: 9db810ed ("net/mlx5: DR, Expose steering action functionality") Signed-off-by:
-
Roi Dayan authored
The value is already the calculation so remove the log prefix. Fixes: e52c2802 ("net/mlx5: E-Switch, Add chains and priorities") Signed-off-by:
Eli Britstein <elibr@mellanox.com> Signed-off-by:
-
David S. Miller authored
Doug Berger says: ==================== net: bcmgenet: restore internal EPHY support (part 2) This is a follow up to my previous submission (see [1]). The first commit provides what is intended to be a complete solution for the issues that can result from insufficient clocking of the MAC during reset of its state machines. It should be backported to the stable releases. It is intended to replace the partial solution of commit 1f515486 ("net: bcmgenet: soft reset 40nm EPHYs before MAC init") which is reverted by the second commit of this series and should not be back- ported as noted in [2]. The third commit corrects a timing hazard with a polled PHY that can occur when the MAC resumes and also when a v3 internal EPHY is reset by the change in commit 25382b99 ("net: bcmgenet: reset 40nm EPHY on energy detect"). It is expected that commit 25382b99 be back- ported to stable first before backporting this commit. [1] https://lkml.org/lkml/2019/10/16/1706 [2] https://lkml.org/lkml/2019/10/31/749 ==================== Signed-off-by:
-
Doug Berger authored
The phy_init_hw() function may reset the PHY to a configuration that does not match manual network settings stored in the phydev structure. If the phy state machine is polled rather than event driven this can create a timing hazard where the phy state machine might alter the settings stored in the phydev structure from the value read from the BMCR. This commit follows invocations of phy_init_hw() by the bcmgenet driver with invocations of the genphy_config_aneg() function to ensure that the BMCR is written to match the settings held in the phydev structure. This prevents the risk of manual settings being accidentally altered. Fixes: 1c1008c7 ("net: bcmgenet: add main driver file") Signed-off-by:
Doug Berger <opendmb@gmail.com> Acked-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Doug Berger authored
This reverts commit 1f515486. This commit improved the chances of the umac resetting cleanly by ensuring that the PHY was restored to its normal operation prior to resetting the umac. However, there were still cases when the PHY might not be driving a Tx clock to the umac during this window (e.g. when the PHY detects no link). The previous commit now ensures that the unimac receives clocks from the MAC during its reset window so this commit is no longer needed. This commit also has an unintended negative impact on the MDIO performance of the UniMAC MDIO interface because it is used before the MDIO interrupts are reenabled, so it should be removed. Signed-off-by:
-
Doug Berger authored
As noted in commit 28c2d1a7 ("net: bcmgenet: enable loopback during UniMAC sw_reset") the UniMAC must be clocked while sw_reset is asserted for its state machines to reset cleanly. The transmit and receive clocks used by the UniMAC are derived from the signals used on its PHY interface. The bcmgenet MAC can be configured to work with different PHY interfaces including MII, GMII, RGMII, and Reverse MII on internal and external interfaces. Unfortunately for the UniMAC, when configured for MII the Tx clock is always driven from the PHY which places it outside of the direct control of the MAC. The earlier commit enabled a local loopback mode within the UniMAC so that the receive clock would be derived from the transmit clock which addressed the observed issue with an external GPHY disabling it's Rx clock. However, when a Tx clock is not available this loopback is insufficient. This commit implements a workaround that leverages the fact that the MAC can reliably generate all of its necessary clocking by enterring the external GPHY RGMII interface mode with the UniMAC in local loopback during the sw_reset interval. Unfortunately, this has the undesirable side efect of the RGMII GTXCLK signal being driven during the same window. In most configurations this is a benign side effect as the signal is either not routed to a pin or is already expected to drive the pin. The one exception is when an external MII PHY is expected to drive the same pin with its TX_CLK output creating output driver contention. This commit exploits the IEEE 802.3 clause 22 standard defined isolate mode to force an external MII PHY to present a high impedance on its TX_CLK output during the window to prevent any contention at the pin. The MII interface is used internally with the 40nm internal EPHY which agressively disables its clocks for power savings leading to incomplete resets of the UniMAC and many instabilities observed over the years. The workaround of this commit is expected to put an end to those problems. Fixes: 1c1008c7 ("net: bcmgenet: add main driver file") Signed-off-by:
-
