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:   Sat, 18 Apr 2020 09:02:18 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     David Miller <davem@...emloft.net>,
        netdev <netdev@...r.kernel.org>,
        Heiner Kallweit <hkallweit1@...il.com>, fugang.duan@....com,
        Chris Healy <Chris.Healy@....aero>
Subject: Re: [PATCH net-next v2 3/3] net: ethernet: fec: Allow the MDIO
 preamble to be disabled



On 4/18/2020 7:27 AM, Andrew Lunn wrote:
>> This is a property of the MDIO device node and the MDIO bus controller as
>> well, so I would assume that it has to be treated a little it like the
>> 'broken-turn-around' property and it would have to be a bitmask per MDIO
>> device address that is set/clear depending on what the device support. If it
>> is set for the device and your controller supports it, then you an suppress
>> preamble.
> 
> Again, i don't see how this can work. You need all the devices on the
> bus to support preamble suppression, otherwise you cannot use it. As
> with a maximum clock frequency, we could add the complexity to check
> as bus scan time that all devices have the necessary property, but i
> don't think it brings anything.

With your current patch I can define 'suppress-preamble' for the FEC 
MDIO node, and if there is at least one device on the bus that does not 
support preamble suppression, they are not going to work, so if nothing 
else you need to intersect between the device capability and the MDIO 
bus controller capability. Same comments as patch #2 about we could 
approach this.
-- 
Florian

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ