[Sorry for sending my previous message twice, it was rejected by the
list server the first time because it contained both plaintext and
HTML alternatives].
On Wed, Dec 02, 2020 at 10:10:37AM -0800, Florian Fainelli wrote:
> On 12/2/2020 9:50 AM, Grant Edwards wrote:
>
> > I know this thread is a couple years old, but I finally got around
> > to working with a newer kernel (5.4) that has the "fixed phy"
> > support. Unfortunately, the existing "fixed phy" support is
> > unusable for us. It doesn't just present a fake, fixed, PHY. It
> > replaces the entire mii (mdio/mdc) bus with a fake bus. That means
> > our code loses the ability to talk to the devices that /are/
> > attached to the macb's mdio management bus.
>
> You did not indicate this was a requirement.
Indeed, I should have done so. It didn't occur to me since I was
discussing adding a fake PHY, not a fake bus.
>> So, I ended up porting my hack from the 2.6.33 macb.c driver to the
>> 5.4 macb.c driver. [...]
>
> That should be unnecessary see below.
> ð0 {
> fixed-link {
> speed = <1000>;
> full-duplex;
> };
> mdio {
> phy0: phy@0 {
> reg = <0>;
> };
> };
> };
Thanks! I may try that if we can resolve the performance issues with
the newer kernels.
When using the SIOC[SG]MIIREG ioctl() call, how does one control
whether the fake fixed-link bus is accessed or the real macb-mdio bus
is accessed? Do different phy_ids automatically get mapped to the two
busses? That requires that a particular id can only exist on one bus
(which isn't a problem).
> The key thing here is to support a "mdio" bus container node which is
> optional and is used as a hint that you need to register the MACB MDIO
> bus controller regardless of MII probing having found devices or not.
How does the macb driver decide which bus/id combination to use as
"the phy" that controls the link duplex/speed settting the the MAC?
[Feel free to point me at appropriat documentation for this.]
--
Grant
