netdev - Re: [PATCH net-next v2 2/3] net: ethernet: fec: Allow configuration of MDIO bus speed

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: <b6b6c42b-aa2d-8036-958e-4f9929752536@gmail.com>
Date:   Sat, 18 Apr 2020 09:01:46 -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 2/3] net: ethernet: fec: Allow configuration
 of MDIO bus speed



On 4/18/2020 7:23 AM, Andrew Lunn wrote:
> On Fri, Apr 17, 2020 at 05:34:56PM -0700, Florian Fainelli wrote:
>> Hi Andrew,
>>
>> On 4/17/2020 5:03 PM, Andrew Lunn wrote:
>>> MDIO busses typically operate at 2.5MHz. However many devices can
>>> operate at faster speeds. This then allows more MDIO transactions per
>>> second, useful for Ethernet switch statistics, or Ethernet PHY TDR
>>> data. Allow the bus speed to be configured, using the standard
>>> "clock-frequency" property, which i2c busses use to indicate the bus
>>> speed.
>>>
>>> Suggested-by: Chris Healy <Chris.Healy@....aero>
>>> Signed-off-by: Andrew Lunn <andrew@...n.ch>
>>
>> This does look good to me, however if we go down that road, it looks like we
>> should also support a 'mdio-max-frequency' per MDIO child node in order to
>> scale up and down the frequency accordingly.
> 
> Hi Florian
> 
> I don't see how that would work. Each device on the bus needs to be
> able to receiver the transaction in order to decode the device
> address, and then either discard it, or act on it. So the same as I2C
> where the device address is part of the transaction. You need the bus
> to run as fast as the slowest device on the bus. So a bus property is
> the simplest. You could have per device properties, and during the bus
> scan, figure out what the slowest device is, but that seems to add
> complexity for no real gain. I2C does not have this either.
> 
> If MDIO was more like SPI, with per device chip select lines, then a
> per device frequency would make sense.

OK, that is a good point, but then again, just like patch #3 you need to 
ensure that you are setting a MDIO bus controller frequency that is the 
lowest common denominator of all MDIO slaves on the bus, which means 
that you need to know about what devices do support.

Your current patch makes it possible for someone to set a 
'clock-frequency' which is not going to guarantee that all MDIO devices 
will work, and the same is arguably true for every other MDIO controller 
that supports having its bus frequency defined/controlled. So maybe we 
can make this in a progressive manner: start with your patches, but add 
support for specifying the MDIO devices' maximum supported frequency and 
later add code in mdio_bus.c which is responsible for selecting the 
lowest frequency and telling the use that a frequency lower than that 
specified in 'clock-frequency' has been selected.
-- 
Florian