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]
Date:   Tue, 1 Nov 2016 12:03:57 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Timur Tabi <timur@...eaurora.org>,
        David Miller <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [PATCH] [RFC] net: phy: phy drivers should not set
 SUPPORTED_Pause or SUPPORTED_Asym_Pause

On 11/01/2016 11:45 AM, Timur Tabi wrote:
> Florian Fainelli wrote:
>> So in premise, this is good, and is exactly what I have in mind for the
>> series that I am cooking, but if we apply this alone, without a change
>> in drivers/net/phy/phy.c which adds SUPPORTED_Pause |
>> SUPPORTED_AsymPause to phydev->features, we are basically breaking the
>> Ethernet MAC drivers that don't explicitly override phydev->features and
>> yet rely on that to get flow control to work.
> 
> That's what I figured, but I wasn't sure how to handle that.  However,
> isn't the ability to pass pause frames a feature that some PHYs do not
> have?  That is, does every PHY support bits 10 and 11 in register 4?
> 

The standard (IEEE Std 802.3-2008) describes this as the
Auto-negotiation advertisement register and these bits are part of the
Technology ability field register. These two bits A5 (PAUSE operation
for full duplex links) and A6 (Asymetric PAUSE operation for full duplex
links) have no cabling requirement, and earlier the paragraph mentions
this is to be resolved by the "management" entity, so I don't think the
PHY has any business in that other than reflecting what the MAC is
capable of doing towards the link partner, but I could be reading the
specification incorrectly.
--
Florian

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ