Skip to content

L
linux
Switch branch/tag
  1. 31 Jan, 2022 6 commits
    • Heiner Kallweit's avatar
      r8169: add rtl_disable_exit_l1() · d192181c
      Heiner Kallweit authored 
      Add rtl_disable_exit_l1() for ensuring that the chip doesn't
inadvertently exit ASPM L1 when being in a low-power mode.
The new function is called from rtl_prepare_power_down() which
has to be moved in the code to avoid a forward declaration.

According to Realtek OCP register 0xc0ac shadows ERI register 0xd4
on RTL8168 versions from RTL8168g. This allows to simplify the
code a little.

v2:
- call rtl_disable_exit_l1() also if DASH or WoL are enabled
Suggested-by: default avatarChun-Hao Lin <hau@realtek.com>
Signed-off-by: default avatarHeiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d192181c
    • Sergey Shtylyov's avatar
      phy: make phy_set_max_speed() *void* · 73c105ad
      Sergey Shtylyov authored 
      After following the call tree of phy_set_max_speed(), it became clear
that this function never returns anything but 0, so we can change its
result type to *void* and drop the result checks from the three drivers
that actually bothered to do it...

Found by Linux Verification Center (linuxtesting.org) with the SVACE static
analysis tool.
Signed-off-by: default avatarSergey Shtylyov <s.shtylyov@omp.ru>
Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      73c105ad
    • David S. Miller's avatar
      Merge branch 'dsa-mv88e6xxx-Improve-indirect-addressing-performance' · fe893027
      David S. Miller authored 
      Tobias Waldekranz says:

====================
net: dsa: mv88e6xxx: Improve indirect addressing performance

The individual patches have all the details. This work was triggered
by recent work on a platform that took 16s (sic) to load the mv88e6xxx
module.

The first patch gets rid of most of that time by replacing a very long
delay with a tighter poll loop to wait for the busy bit to clear.

The second patch shaves off some more time by avoiding redundant
busy-bit-checks, saving 1 out of 4 MDIO operations for every register
read/write in the optimal case.

v1 -> v2:
- Make sure that we always poll the busy bit at least twice, in the
  unlikely event that the first one is quick to query the hardware,
  but is then scheduled out for a long time before the timeout is
  checked.

v2 -> v3:
- Fallback to the longer sleeps after the initial two poll attempts.
====================
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fe893027
    • Tobias Waldekranz's avatar
      net: dsa: mv88e6xxx: Improve indirect addressing performance · 7bca16b2
      Tobias Waldekranz authored 
      Before this change, both the read and write callback would start out
by asserting that the chip's busy flag was cleared. However, both
callbacks also made sure to wait for the clearing of the busy bit
before returning - making the initial check superfluous. The only
time that would ever have an effect was if the busy bit was initially
set for some reason.

With that in mind, make sure to perform an initial check of the busy
bit, after which both read and write can rely the previous operation
to have waited for the bit to clear.

This cuts the number of operations on the underlying MDIO bus by 25%
Signed-off-by: default avatarTobias Waldekranz <tobias@waldekranz.com>
Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7bca16b2
    • Tobias Waldekranz's avatar
      net: dsa: mv88e6xxx: Improve performance of busy bit polling · 35da1dfd
      Tobias Waldekranz authored 
      Avoid a long delay when a busy bit is still set and has to be polled
again.

Measurements on a system with 2 Opals (6097F) and one Agate (6352)
show that even with this much tighter loop, we have about a 50% chance
of the bit being cleared on the first poll, all other accesses see the
bit being cleared on the second poll.

On a standard MDIO bus running MDC at 2.5MHz, a single access with 32
bits of preamble plus 32 bits of data takes 64*(1/2.5MHz) = 25.6us.

This means that mv88e6xxx_smi_direct_wait took 26us + CPU overhead in
the fast scenario, but 26us + 1500us + 26us + CPU overhead in the slow
case - bringing the average close to 1ms.

With this change in place, the slow case is closer to 2*26us + CPU
overhead, with the average well below 100us - a 10x improvement.

This translates to real-world winnings. On a 3-chip 20-port system,
the modprobe time drops by 88%:

Before:

root@coronet:~# time modprobe mv88e6xxx
real    0m 15.99s
user    0m 0.00s
sys     0m 1.52s

After:

root@coronet:~# time modprobe mv88e6xxx
real    0m 2.21s
user    0m 0.00s
sys     0m 1.54s
Signed-off-by: default avatarTobias Waldekranz <tobias@waldekranz.com>
Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      35da1dfd
    • Sun Shouxin's avatar
      net: bonding: Add support for IPV6 ns/na to balance-alb/balance-tlb mode · 0da8aa00
      Sun Shouxin authored 
      Since ipv6 neighbor solicitation and advertisement messages
isn't handled gracefully in bond6 driver, we can see packet
drop due to inconsistency between mac address in the option
message and source MAC .

Another examples is ipv6 neighbor solicitation and advertisement
messages from VM via tap attached to host bridge, the src mac
might be changed through balance-alb mode, but it is not synced
with Link-layer address in the option message.

The patch implements bond6's tx handle for ipv6 neighbor
solicitation and advertisement messages.
Suggested-by: default avatarHu Yadi <huyd12@chinatelecom.cn>
Acked-by: default avatarJay Vosburgh <jay.vosburgh@canonical.com>
Signed-off-by: default avatarSun Shouxin <sunshouxin@chinatelecom.cn>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0da8aa00
  3. 29 Jan, 2022 5 commits
  5. 28 Jan, 2022 29 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7