[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200418164902.GK804711@lunn.ch>
Date: Sat, 18 Apr 2020 18:49:02 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Florian Fainelli <f.fainelli@...il.com>
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
> > 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.
Hi Florian
I've been following what I2C does, since MDIO and I2C is very similar.
I2C has none of what you are asking for. If I2C does not need any of
this, does MDIO? I2C assumes what whoever writes the DT knows what
they are doing and will set a valid clock frequency which works for
all devices on the bus. This seems to work for I2C, so why should it
not work for MDIO?
My preference is KISS.
Andrew
Powered by blists - more mailing lists