linux-kernel - 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: <b6dd9b94e3a43d98bacdcd22f536a10c@artur-rojek.eu>
Date: Sun, 17 Aug 2025 14:04:11 +0200
From: Artur Rojek <contact@...ur-rojek.eu>
To: Andrew Lunn <andrew@...n.ch>
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 2025-08-16 17:04, Andrew Lunn wrote:
> 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?

It's pretty limited - there is no MMU or DMA, for example. There does
appear to be a GPIO controller, however I'm not sure if it is of pinmux
variety (whether pins used by an IP core can be multiplexed to PIO), or
if it has its own pool of general purpose pins, that don't overlap with
PHY. In any case, there is no Linux driver for it (I have interest to
eventually write one), and I don't know if the design for it is even
included in the bitstream on my board.

> 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.

This is a clever idea! It does however sound like Jeff & co. will
eventually add a proper MDIO interface to this MAC. I will halt upstream
of this driver for now and see what happens first (that, or me
experimenting with GPIO). Thanks for the review of this series thus far!

Cheers,
Artur

> 
> 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