netdev - Re: [PATCH 3/3] net: j2: Introduce J-Core EMAC

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: <DC855B2C-37F3-4565-8B6F-B122F7E16E25@coresemi.io>
Date: Sun, 17 Aug 2025 13:29:42 +0900
From: "D. Jeff Dionne" <jeff@...esemi.io>
To: Artur Rojek <contact@...ur-rojek.eu>
Cc: Andrew Lunn <andrew@...n.ch>,
 Rob Landley <rob@...dley.net>,
 John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>,
 Geert Uytterhoeven <geert+renesas@...der.be>,
 Andrew Lunn <andrew+netdev@...n.ch>,
 "David S . Miller" <davem@...emloft.net>,
 Eric Dumazet <edumazet@...gle.com>,
 Jakub Kicinski <kuba@...nel.org>,
 Paolo Abeni <pabeni@...hat.com>,
 Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>,
 Conor Dooley <conor+dt@...nel.org>,
 netdev@...r.kernel.org,
 devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org,
 "D. Jeff Dionne" <jeff@...esemi.io>
Subject: Re: [PATCH 3/3] net: j2: Introduce J-Core EMAC

On Aug 16, 2025, at 22:40, Artur Rojek <contact@...ur-rojek.eu> wrote:

The MDIO isn’t implemented yet.  There is a pin driver for it, but it relies on
pin strapping the Phy.  Probably because all the designs that SoC base is in
(IIRC 10 or so customer and prototype designs, plus Turtle and a few 
derivatives), the SoC was designed in conjunction with board.  A bit lazy.

But they all have the MDIO connected, so we should add it (it’s very simple).

Cheers,
J.

> On 2025-08-16 02:18, Andrew Lunn wrote:
>>> Yes, it's an IC+ IP101ALF 10/100 Ethernet PHY [1]. It does have both MDC
>>> and MDIO pins connected, however I suspect that nothing really
>>> configures it, and it simply runs on default register values (which
>>> allow for valid operation in 100Mb/s mode, it seems). I doubt there is
>>> another IP core to handle MDIO, as this SoC design is optimized for
>>> minimal utilization of FPGA blocks. Does it make sense to you that a MAC
>>> could run without any access to an MDIO bus?
>> It can work like that. You will likely have problems if the link ever
>> negotiates 10Mbps or 100Mbps half duplex. You generally need to change
>> something in the MAC to support different speeds and duplex. Without
>> being able to talk to the PHY over MDIO you have no idea what it has
>> negotiated with the link peer.
> 
> Thanks for the explanation. I just confirmed that there is no activity
> on the MDIO bus from board power on, up to the jcore_emac driver start
> (and past it), so most likely this SoC design does not provide any
> management interface between MAC and PHY. I guess once/if MDIO is
> implemented, we can distinguish between IP core revision compatibles,
> and properly switch between netif_carrier_*()/phylink logic.
> 
> Cheers,
> Artur
> 
>> Andrew