All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jisheng Zhang <jszhang@kernel.org>
To: Andrew Lunn <andrew@lunn.ch>, Russell King <linux@armlinux.org.uk>
Cc: Russell King <linux@armlinux.org.uk>,
	Florian Fainelli <florian.fainelli@broadcom.com>,
	Jakub Kicinski <kuba@kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	netdev@vger.kernel.org
Subject: Re: [RFC] mdio demux multiplexer driver
Date: Wed, 20 Aug 2025 23:44:51 +0800	[thread overview]
Message-ID: <aKXtcw1G3-TQTf2r@xhacker> (raw)
In-Reply-To: <c40dd405-9549-40c9-8cfd-88dd0b1342da@lunn.ch>

On Mon, Aug 18, 2025 at 06:27:33PM +0200, Andrew Lunn wrote:
> > > Both Ethernet and MDIO hardware exists, even if it is not used. I
> > > would separate the drivers. Have a MAC driver and an MDIO driver. List
> > > them as separate entities in DT. Always probe the MDIO0 driver. It can
> > > set the MUX registers. Don't probe MDIO1 driver. Even if it does
> > > probe, you know MDIO0 is one to be used, so MDIO1 can still set the
> > > MUX to point to MDIO0.
> > > 
> > > How messy is the address space? Are the MDIO registers in the middle
> > > of the MAC registers? Is this a standard, off the shelf MAC/MDIO IP?
> > > stmmac? Or something currently without a driver? If you are dealing
> > 
> > stmmac :(  And the MMIO reg doesn't sit together with MAC IP's.
> > As can be seen, the stmmac mdio registers sit in the middle of the
> > MAC regs. And current stmmac still tries to register a mdio driver for
> > the MDIO bus master. And to be honest, it's not the stmmac make things
> > messy, but the two MDIO masters sharing the single clk and data lines
> > makes the mess. Modeling the mmio as a demux seems a just so so but
> > not perfect solution.
> 
> So you only really have problems when MAC0 is not used. Are there any
> boards actually designed that way? If there are no such boards at the
> moment, you can delay handling that until later.
> 
> When later arrives, i would probably look at refactoring the stmmac
> MDIO code into a library. The stmmac driver can use the library, and
> you can add a new MDIO only driver around the library for when MAC0 is
> not used, but you need the MDIO bus.
> 
> For the moment, you can add setting the MUX register in the stmmac
> glue driver.

Hi Andrew, Russell

Thanks a lot for your useful inputs. I will check again and try the
demux and compare it with different solutions.

Thanks a lot!

      reply	other threads:[~2025-08-20 16:02 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-13  0:58 [RFC] mdio demux multiplexer driver Jisheng Zhang
2025-08-15  3:51 ` Andrew Lunn
2025-08-16  5:26   ` Jisheng Zhang
2025-08-16 14:52     ` Andrew Lunn
2025-08-18 15:39       ` Jisheng Zhang
2025-08-18 16:21         ` Russell King (Oracle)
2025-08-18 16:27         ` Andrew Lunn
2025-08-20 15:44           ` Jisheng Zhang [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aKXtcw1G3-TQTf2r@xhacker \
    --to=jszhang@kernel.org \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=florian.fainelli@broadcom.com \
    --cc=kuba@kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.