mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Daniel Golle <daniel@makrotopia.org>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Chris Packham <Chris.Packham@alliedtelesis.co.nz>,
	"hkallweit1@gmail.com" <hkallweit1@gmail.com>,
	"linux@armlinux.org.uk" <linux@armlinux.org.uk>,
	"davem@davemloft.net" <davem@davemloft.net>,
	"edumazet@google.com" <edumazet@google.com>,
	"kuba@kernel.org" <kuba@kernel.org>,
	"pabeni@redhat.com" <pabeni@redhat.com>,
	"markus.stockhausen@gmx.de" <markus.stockhausen@gmx.de>,
	"sander@svanheule.net" <sander@svanheule.net>,
	netdev <netdev@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v10] net: mdio: Add RTL9300 MDIO driver
Date: Thu, 13 Mar 2025 23:01:45 +0000	[thread overview]
Message-ID: <Z9Nj2ZRnh8ZABklp@makrotopia.org> (raw)
In-Reply-To: <f6165df5-eedb-4a11-add0-2ae4d4052d6a@lunn.ch>

On Thu, Mar 13, 2025 at 11:07:55PM +0100, Andrew Lunn wrote:
> > I'm pretty sure it would upset the hardware polling mechanism which 
> > unfortunately we can't disable (earlier I thought we could but there are 
> > various switch features that rely on it).
> 
> So we need to get a better understanding of that polling. How are you
> telling it about the aquantia PHY features? How does it know it needs
> to get the current link rate from MDIO_MMD_AN, MDIO_AN_TX_VEND_STATUS1
> which is a vendor register, not a standard C45 register? How do you
> teach it to decode bits in that register?

There are several registers of the MDIO controller to control which
non-standard registers are polled as well as information about the
register layout [1].

There are lots of constraints which is why not all PHYs can even be
used at all with those switch SoCs -- PHYs which are more or less
standard C45 are easy to support, all one got to do is define MMD
device and registers as well as register layouts for things which
aren't covered by the C45 standard (1G Master/Slave status and control,
as well as a way to access the equivalent of C22 register 0).

But C22 PHYs which aren't RealTek's won't ever work.
Anything which doesn't use register 0x1f for paging is disqualified and
can't be used. I've also just never seen any of those SoCs being used with
anything else than RealTek's 1000Base-T or 2500Base-T PHYs.

Only for 10GBase-T you will find variation, Marvell, Aquantia and some
with Broadcom.

Obviously that's all largely incompatible with Linux' approach to PHY
drivers. Luckily *most* (but not all) switches based on those RealTek
SoC's initialize the PHY polling registers in U-Boot, so usually Linux
doesn't have to touch that (that's why usually we have to make sure
that 'rtk network on' is called in RealTek's U-Boot before launching
Linux).


[1]: There is a very useful reverse-engineered register documentation for
those RealTek SoCs which also covers those registers of the RTL9300:

https://svanheule.net/realtek/longan/feature/mac_control

See SMI_REG_CHK_* and everything with 'POLL' in the register name to get
an idea...

For illustation see the default value of SMI_10GPHY_POLLING_SEL_0 which
is 0x001f_a434. So that's what is called 'RTL_VND2_PHYSR' in the Linux
driver for RealTek PHYs...

      parent reply	other threads:[~2025-03-13 23:02 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20250313010726.2181302-1-chris.packham@alliedtelesis.co.nz>
     [not found] ` <f7c7f28b-f2b0-464a-a621-d4b2f815d206@lunn.ch>
2025-03-13 19:54   ` Chris Packham
2025-03-13 20:35     ` Andrew Lunn
2025-03-13 20:37       ` Chris Packham
2025-03-13 20:40         ` Andrew Lunn
2025-03-13 20:44           ` Chris Packham
2025-03-13 22:07             ` Andrew Lunn
2025-03-13 22:53               ` Chris Packham
2025-03-13 23:01               ` Daniel Golle [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=Z9Nj2ZRnh8ZABklp@makrotopia.org \
    --to=daniel@makrotopia.org \
    --cc=Chris.Packham@alliedtelesis.co.nz \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=hkallweit1@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=markus.stockhausen@gmx.de \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=sander@svanheule.net \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®