RE: [PATCH net-next 4/5] net: ethernet: adi: Add a driver for the ADIN1140 MACPHY

[Regus, Ciprian]

> -----Original Message-----
> From: Andrew Lunn <andrew@xxxxxxx>
> Sent: Sunday, May 3, 2026 6:16 PM
> To: Regus, Ciprian <Ciprian.Regus@xxxxxxxxxx>
> Cc: 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 4/5] net: ethernet: adi: Add a driver for the
> ADIN1140 MACPHY
> 
> [External]
> 
> On Sun, May 03, 2026 at 05:36:13AM +0200, Andrew Lunn wrote:
> > On Sun, May 03, 2026 at 02:24:53AM +0300, Ciprian Regus via B4 Relay
> wrote:
> > > From: Ciprian Regus <ciprian.regus@xxxxxxxxxx>
> > >
> > > Add a driver for ADIN1140. The device is a 10BASE-T1S MAC-PHY
> > > (integrated in the same package) that connects to a CPU over an SPI bus,
> > > and implements the Open Alliance TC6 protocol for control and frame
> > > transfers. As such, this driver relies on oa_tc6 for the communication
> > > with the device. The device has an alternative name (AD3306), so the
> > > driver can be probed using one of the two compatible strings.
> > >
> > > For control transactions, ADIN1140 only implements the protected mode.
> > > The driver has a custom implementation for the mii_bus access methods
> as a
> > > workaround for hardware issues:
> > >
> > > 1. The OA TC6 standard defines the direct and indirect access modes for
> > >    MDIO transactions. The ADIN1140 incorrectly advertises indirect mode
> > >    only (supported capabilities register - 0x2, bit 9), while actually
> > >    implementing just the direct mode. We cannot rely on the CAP register
> > >    to choose an access method (which oa_tc6 does by default, even
> though
> > >    it only implements the direct mode), so the driver has to use its
> > >    own.
> > > 2. The ADIN1140 cannot access the C22 register space of the internal
> > >    PHY, while the PHY is busy receiving frames. If that happens, the
> > >    CONFIG0 and CONFIG2 registers of the MAC will get corrupted and the
> > >    data transfer will stop. Those two registers configure settings for
> > >    the transfer protocol between the MAC and host, so the value for some
> > >    of their subfields shouldn't be changed while the netdev is up.
> 
> This device is pretty broken. Has it been shipped to customers? Is
> there going to be a new stepping of the silicon which is less broken?
> A new device to replace this one?

Hello Andrew,

The device has been out for some time, but it's only now being made public.
There are customers using it at the moment. I'm not aware of future revisions
of the silicon,  but I can ask further about that.

> 
> 	Andrew