netdev - Re: [PATCH net] amd-xgbe: read STAT1 register twice to get correct value

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <61d32959-83e1-f255-9aa7-65630027deb7@amd.com>
Date: Thu, 5 Oct 2023 09:05:09 +0530
From: Raju Rangoju <Raju.Rangoju@....com>
To: kuba@...nel.org, Andrew Lunn <andrew@...n.ch>
Cc: Tom Lendacky <thomas.lendacky@....com>, netdev@...r.kernel.org,
 davem@...emloft.net, edumazet@...gle.com, pabeni@...hat.com,
 Shyam-sundar.S-k@....com
Subject: Re: [PATCH net] amd-xgbe: read STAT1 register twice to get correct
 value

Hi Andrew,

Thanks for the explanation. The current approach is holding good for 
amd-xgbe.


Hi Jakub,

Can you please apply this patch.

Thanks,
Raju

On 9/17/2023 7:41 PM, Andrew Lunn wrote:
>> Thanks, Tom.
>>
>> The following thread (found online) has the detailed info on the IEEE 802.3
>> Standard that define the Link Status bit:
>>
>> https://microchip.my.site.com/s/article/How-to-correctly-read-the-Ethernet-PHY-Link-Status-bit
> 
> The relevant section for me is:
> 
>      Having a latched-low bit helps to ensure a link drop (no matter
>      how short the duration before re-establishing link-up again) gets
>      recorded and can be read from PHY register by the upper network
>      layer (e.g., MAC processor).
> 
> By reading it twice, you are loosing the information the link went
> down. This could mean you don't restart dhcp to get a new IP address
> for a new subnet, kick of IPv6 getting the new network prefix so it
> can create its IPv6 address etc.
> 
> When Linux is driving the PHYs using phylib, drivers are written such
> that they report the latched link down. This gets report to the stack,
> and so up to user space etc. phylib will then ask the driver a second
> time to get the link status, and it might then return that the link is
> now up. That then gets reported to the stack and user space.
> 
> As i said, you are not using phylib, this is not a linux PHY driver,
> so i don't actually care what you do here. I just want to point out
> why what you are doing could be wrong.
> 
>      Andrew