[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <52aef275-0907-4510-b95c-b2b01738ce0b@lunn.ch>
Date: Sat, 16 Aug 2025 17:04:12 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Artur Rojek <contact@...ur-rojek.eu>
Cc: Rob Landley <rob@...dley.net>, Jeff Dionne <jeff@...esemi.io>,
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
Subject: Re: [PATCH 3/3] net: j2: Introduce J-Core EMAC
On Sat, Aug 16, 2025 at 03:40:57PM +0200, Artur Rojek wrote:
> 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.
How cut down of a SoC design is it? Is there pinmux and each pin can
also be used for GPIO? Linux has software bit-banging MDIO, if you can
make the two pins be standard Linux GPIOs, and can configure them
correctly, i _think_ open drain on MDIO. It will be slow, but it
works, and it is pretty much for free.
MDIO itself is simple, just a big shift register:
https://opencores.org/websvn/filedetails?repname=ethmac10g&path=%2Fethmac10g%2Ftrunk%2Frtl%2Fverilog%2Fmgmt%2Fmdio.v
Andrew
Powered by blists - more mailing lists