netdev - Re: [PATCH net-next v2 2/3] net: phy: bcm5481x: Implement MII-Lite mode

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <56cc7658-0b57-4925-89c7-595d76f77064@axis.com>
Date: Tue, 24 Jun 2025 09:59:54 +0200
From: Kamil Horák (2N) <kamilh@...s.com>
To: Maxime Chevallier <maxime.chevallier@...tlin.com>
Cc: netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next v2 2/3] net: phy: bcm5481x: Implement MII-Lite
 mode



On 6/23/25 17:51, Maxime Chevallier wrote:
> Hi Kamil,
> 
> On Mon, 23 Jun 2025 17:10:46 +0200
> Kamil Horák - 2N <kamilh@...s.com> wrote:
> 
>> From: Kamil Horák (2N) <kamilh@...s.com>
>>
>> The Broadcom bcm54810 and bcm54811 PHYs are capable to operate in
>> simplified MII mode, without TXER, RXER, CRS and COL signals as defined
>> for the MII. While the PHY can be strapped for MII mode, the selection
>> between MII and MII-Lite must be done by software.
>> The MII-Lite mode can be used with some Ethernet controllers, usually
>> those used in automotive applications. The absence of COL signal
>> makes half-duplex link modes impossible but does not interfere with
>> BroadR-Reach link modes on Broadcom PHYs, because they are full-duplex
>> only. The MII-Lite mode can be also used on an Ethernet controller with
>> full MII interface by just leaving the input signals (RXER, CRS, COL)
>> inactive.
> 
> I'm following-up to Andrew's suggestion of making it a dedicated
> phy-mode. You say that this requires only phy-side configuration,
> however you also say that with MII-lite, you can't do half-duplex.
> 
OK let's go this way. I was not fully aware about the fact that MII-Lite 
were actually Broadcom's specialty, only found in its two-wire Ethernet 
PHYs.

> Looking at the way we configure the MAC to PHY link, how can the MAC
> driver know that HD isn't available if this is a phy-only property ?
It is a very special case, because the Broadcom two-wire PHY would never 
go half-duplex in BroadR-Reach mode. However, it is capable of "normal" 
(IEEE) modes as well and in such case, half-duplex modes must be avoided 
with MII-Lite. I doubt anyone would create a hardware capable of both 
IEEE and BRR modes - it would be difficult to do, perhaps only using 
kind of hardware plugin interface modules.

The MAC driver should handle the situation properly (and the imx6ul SoC 
in our case does so), considering the unconnected MII signals are 
inactive. These signals even do not need to be put on external pads and 
pulled up or down.

> 
> Relying on the fact that the PHYs that use MII-Lite will only ever
> setup a full-duplex link with the partner seems a bit fragile, when we
> could indicate that this new MII-Lite mode only supports 10FD/100FD,
> through this mapping code here :
> 
> https://elixir.bootlin.com/linux/v6.16-rc2/source/drivers/net/phy/phy_caps.c#L282
> 
> Besides that, given that this is a physically different MAC to PHY
> interface (missing signals compared to MII), one could also argue that
> this warrants a dedicated phy-mode.
So I'll change it so that there will be separate MII-Lite PHY mode, only 
usable with Broadcom PHYs. It would be possible to wire other PHYs the 
same way, at least there seems to be some support in Marvell, Microchip 
and Texas Instruments ones.

> 
> Maxime


Kamil