Re: [RFC PATCH net-next v4 01/28] net: mdio: ipq8064: clean whitespaces in define

[Ansuel Smith]

On Sun, May 16, 2021 at 01:52:05AM +0200, Andrew Lunn wrote:
> > > They're on 2 separate sets of GPIOs if that makes a difference - switch0
> > > is in gpio0/1 and switch1 is on gpio10/11. Is the internal MDIO logic
> > > shared between these? Also even if that's the case it seems odd that
> > > enabling the MDIO for just switch0 doesn't work?
> > > 
> > 
> > The dedicated internal mdio on ipq8064 is unique and present on the
> > gmac0 address so yes it's shared between them. And this seems to be the
> > problem... As you notice the fact that different gpio are used for the
> > different switch fix the problem. So think that to use the dedicated
> > mdio bus with both switch we need to introduce some type of
> > syncronization or something like that.
> 
> Please could you describe the hardware in a bit more details. Or point
> me at a datasheet. It sounds like you have an MDIO mux? Linux has this
> concept, so you might need to implement a mux driver.
> 
> 	 Andrew

Datasheet of ipq8064 are hard to find and pricey.
Will try hoping I don't write something very wrong.
Anyway on the SoC there are 4 gmac (most of the time 2 are used
and represent the 2 cpu port) and one mdio bus present on the gmac0
address. 
Normally on these SoC they add a qca8337 switch and it's common to use
2 gmac port as cpu port. The switch can be interfaced using UART or MDIO.
Normally the uart interface is used, but it's slower than using the mdio
dedicated interface. Only mdio or uart can be used as the switch use the
same pins.
So I think the problem here is that only one switch can use the mdio bus
exposed by gmac0 and any other must use a gpio slow path.
Anyway about the use of the MASTER path and all this mess, the 
qca8k: extend slave-bus implementations series contains lots of info
about this[1].

[1] http://patchwork.ozlabs.org/project/netdev/patch/20190319195419.12746-3-chunkeey@xxxxxxxxx/