RE: [PATCH net-next 2/5] net: ethernet: oa_tc6: Allow custom mii_bus

[Selvamani Rajagopal]

> -----Original Message-----
> From: Andrew Lunn <andrew@xxxxxxx>
> Sent: Sunday, May 3, 2026 11:07 AM
> To: Selvamani Rajagopal <Selvamani.Rajagopal@xxxxxxxxxx>
> Cc: ciprian.regus@xxxxxxxxxx; Parthiban Veerasooran
> <parthiban.veerasooran@xxxxxxxxxxxxx>; Andrew Lunn <andrew+netdev@xxxxxxx>;
> David S. Miller <davem@xxxxxxxxxxxxx>; Eric Dumazet <edumazet@xxxxxxxxxx>;
> Jakub Kicinski <kuba@xxxxxxxxxx>; Paolo Abeni <pabeni@xxxxxxxxxx>; Simon Horman
> <horms@xxxxxxxxxx>; Jonathan Corbet <corbet@xxxxxxx>; Shuah Khan
> <skhan@xxxxxxxxxxxxxxxxxxx>; Heiner Kallweit <hkallweit1@xxxxxxxxx>; Russell King
> <linux@xxxxxxxxxxxxxxx>; Rob Herring <robh@xxxxxxxxxx>; Krzysztof Kozlowski
> <krzk+dt@xxxxxxxxxx>; Conor Dooley <conor+dt@xxxxxxxxxx>; netdev@xxxxxxxxxxxxxxx;
> linux-kernel@xxxxxxxxxxxxxxx; linux-doc@xxxxxxxxxxxxxxx; devicetree@xxxxxxxxxxxxxxx
> Subject: Re: [PATCH net-next 2/5] net: ethernet: oa_tc6: Allow custom mii_bus
> 
> 
> This Message Is From an External Sender
> This message came from outside your organization.
> 
> > > This all seems pretty invasive and ugly. Please could you think what
> > > happens if instead of passing in an mdiobus, you pass a phydev. Is the
> > > change to the core simpler and cleaner?
> > >
> > > Andrew
> >
> 
> > Kind of agree. Initially we were thinking about changing the
> > existing code (Microchip's vendor code) to alloc mii_bus so that
> > code would be same across multiple vendors. Either way, it would be
> > invasive changes. So, we decide to go with minimal change to other
> > vendor's code.
> 
> That would be wrong. The standard defines this, so it should be in the
> core. Anything which the standard defines should be in the core, so
> that drivers for hardware which actually follow the standard are
> minimal. Also, we try to keep workarounds for broken hardware out of
> the core, hide it in the driver. That is not always possible, but the
> aim should be to make the core clean. We don't want to penalise
> vendors which got the implementation correct because of vendors who
> got is wrong.
> 
> > Trying to understand your suggestion. Are you suggesting to move
> > entire mii_bus allocation/APIs implementation to vendor side and
> > keep only phy dev usage in oa_tc6.c?
> 
> No. I'm thinking maybe extend oa_tc6_init, similar to what you
> did. Add a quirks flag, and define TC6_QUIRK_BROKEN_PHY. And allow a
> phydev to be passed as well.
> 
> If the quirk is set, don't call oa_tc6_mdiobus_register() or
> phy_find_first(), nor oa_tc6_mdiobus_unregister().
> 
> You probably want to start with a patch which breaks oa_tc6_phy_init()
> into two, since you still need the phy_connect_direct() and
> phy_attached_info(). Then add the quirk, and lastly your driver making
> use of the quirk.
> 
> The quirks flag could also be used for devices which have MMD 30
> mapped into a vendor reserved MMS.
> 
> Andrew

Andrew,
I realized that I wrongly picked this thread to ask my question. This email thread wasn't ours. But I got your suggestion. Will try/test. Will discuss this in our thread.

Sincerely
Selva