netdev - genphy_read_status() vs. 1000bT Pause capability

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 28 Mar 2017 11:49:50 +1100
From:   Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:     netdev@...r.kernel.org
Subject: genphy_read_status() vs. 1000bT Pause capability

Hi !

I noticed that flow control isn't being enabled on a system I'm
working on by default. I've tracked it down to two things:

 - The realtec.c PHY driver doesn't have Pause or Asym_Pause in
its exposed capabilities. This is in part because PHY_GBIT_FEATURES
does not include SUPPORTED_Pause and SUPPORTED_Asym_Pause. Is there
a specific reason for that ?

 - After I've hacked the above, I get in genphy_read_status():

lpa=c1e1 lpagb=3800 adv=de1 common_adv=1e1 common_adv_gb=800

So we have negociated 1000bT full duplex. LPA_PAUSE's aren't set
but I was under the impression that in Gigabit mode, LPA bit 0x80
which *is* set, meant ADVERTISE_1000XPAUSE which is the pause
capability isn't it ? Or am I confusing with something else ?
This seems to be how mii_adv_to_ethtool_adv_x() decodes them
but that function is not called by genphy_read_status()...

Now it's been a while since I hacked network drivers and back then
everybody did their own salad with gigabit PHYs so it's very possible
that I missed something here.

Should we update genphy_read_status() to grab the pause details
from mii_adv_to_ethtool_adv_x() when in 1000bT mode ?

Thanks !

Cheers,
Ben.