All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: Markus Stockhausen <markus.stockhausen@gmx.de>
Cc: hkallweit1@gmail.com, linux@armlinux.org.uk, davem@davemloft.net,
	edumazet@google.com, kuba@kernel.org, pabeni@redhat.com,
	netdev@vger.kernel.org, chris.packham@alliedtelesis.co.nz,
	daniel@makrotopia.org, robh@kernel.org, krzk+dt@kernel.org,
	conor+dt@kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH net-next v15 08/13] net: mdio: realtek-rtl9300: Add page tracking
Date: Wed, 2 Sep 2026 02:16:02 +0200	[thread overview]
Message-ID: <756f8e8f-324d-4dfd-b944-1c71cac73403@lunn.ch> (raw)
In-Reply-To: <20260831143439.2404484-9-markus.stockhausen@gmx.de>

On Mon, Aug 31, 2026 at 04:34:34PM +0200, Markus Stockhausen wrote:
61;8001;1c> The hardware polling unit of the Realtek switches has a very special
> handling for c22 PHY register 31 (aka Realtek page register) in place.
> 
> - On the RTL838x it is permanently reset to zero.
> - On other devices there is some magic saving/restoring (aka parking)
>   in the background in place.
> 
> This makes access to PHYs a gamble.
> 
> It is vital to keep the polling alive so the MAC layer can rely on
> consistent data. Intercept access to c22 register 31 and handle it
> internally. Store the desired value for each port in the driver. When
> issuing hardware access to other registers add the page to the command
> towards the controller. Given this, the hardware will run two c22
> commands that are not interrupted by polling.
> 
>   ... hardware poll ...
>   phy_write(phy, 31, page)
>   phy_write(phy, reg, value)
>   ... hardware poll ...
> 
> Looking at this implementation one might argue that disabling/enabling
> polling might be a cleaner solution. But one must remember that
> 
> - This driver differentiates clearly between C22 and C45 buses. During
>   probing it enables only one of the protocols for a bus.
> - All known devices run RTL8218 (B/D/E) or RTL8214FC on 1G
> - RTL839x gives link flapping when deactivating polling for a port
> 
> So a solution for a Realtek-only ecosystem is required. This commit
> copies the downstream-proven driver-only page handling patch without
> any new MDIO callbacks and is the lowest common denominator. If a
> non-Realtek PHY is identified on a c22 bus the attachment aborts. It
> should be noted that bus scan runs with the page handling already in
> place before the check in notify_phy_attach(). This is accepted for
> now.
> 
> Remark: To keep this simple, writes to register 31 are only accepted
> if they are lower than the device specific raw page - 0..4094/8190.
> Otherwise -EINVAL is returned. Under the above assumption (Only 1G
> Realtek PHYs on a c22 bus) this is no limitation.
> 
> Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>

Reviewed-by: Andrew Lunn <andrew@lunn.ch>

    Andrew

  reply	other threads:[~2026-09-02  0:16 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-31 14:34 [PATCH net-next v15 00/13] net: mdio: realtek-rtl9300: Add RTL83xx support Markus Stockhausen
2026-08-31 14:34 ` [PATCH net-next v15 01/13] dt-bindings: net: realtek,rtl9301-mdio: Add RTL83xx series Markus Stockhausen
2026-08-31 14:34 ` [PATCH net-next v15 02/13] net: mdio: realtek-rtl9300: Add polling documentation Markus Stockhausen
2026-08-31 14:34 ` [PATCH net-next v15 03/13] net: mdio: realtek-rtl9300: deny C45 over C22 access Markus Stockhausen
2026-09-02  0:08   ` Andrew Lunn
2026-09-02  5:36   ` [net-next,v15,03/13] " netdev-bot+sashiko
2026-08-31 14:34 ` [PATCH net-next v15 04/13] net: phy: add phy_detach_internal() helper Markus Stockhausen
2026-09-01 14:35   ` sashiko-bot
2026-09-02  0:09   ` Andrew Lunn
2026-08-31 14:34 ` [PATCH net-next v15 05/13] net: phy: add (*notify_phy_attach/detach)() hooks to struct mii_bus Markus Stockhausen
2026-09-02  0:10   ` Andrew Lunn
2026-09-02  5:36   ` [net-next,v15,05/13] " netdev-bot+sashiko
2026-08-31 14:34 ` [PATCH net-next v15 06/13] net: mdio: realtek-rtl9300: suppress sysfs bind/unbind attributes Markus Stockhausen
2026-09-01 14:35   ` sashiko-bot
2026-09-02  0:12   ` Andrew Lunn
2026-09-02  5:36   ` [net-next,v15,06/13] " netdev-bot+sashiko
2026-08-31 14:34 ` [PATCH net-next v15 07/13] net: mdio: realtek-rtl9300: Configure hardware polling during probing Markus Stockhausen
2026-09-01 14:35   ` sashiko-bot
2026-09-02  0:14   ` Andrew Lunn
2026-09-02  5:36   ` [net-next,v15,07/13] " netdev-bot+sashiko
2026-08-31 14:34 ` [PATCH net-next v15 08/13] net: mdio: realtek-rtl9300: Add page tracking Markus Stockhausen
2026-09-02  0:16   ` Andrew Lunn [this message]
2026-09-02  5:36   ` [net-next,v15,08/13] " netdev-bot+sashiko
2026-08-31 14:34 ` [PATCH net-next v15 09/13] net: mdio: realtek-rtl9300: Increase MDIO timeout Markus Stockhausen
2026-08-31 14:34 ` [PATCH net-next v15 10/13] net: mdio: realtek-rtl9300: Open up C22 and C45 space in parallel Markus Stockhausen
2026-09-01 14:35   ` sashiko-bot
2026-09-02  0:16   ` Andrew Lunn
2026-09-02  5:36   ` [net-next,v15,10/13] " netdev-bot+sashiko
2026-08-31 14:34 ` [PATCH net-next v15 11/13] net: mdio: realtek-rtl9300: Add support for RTL838x Markus Stockhausen
2026-09-02  0:17   ` Andrew Lunn
2026-09-02  5:36   ` [net-next,v15,11/13] " netdev-bot+sashiko
2026-08-31 14:34 ` [PATCH net-next v15 12/13] net: mdio: realtek-rtl9300: Add support for RTL839x Markus Stockhausen
2026-09-02  0:18   ` Andrew Lunn
2026-09-02  5:32     ` AW: " Markus Stockhausen
2026-09-02  5:36   ` [net-next,v15,12/13] " netdev-bot+sashiko
2026-08-31 14:34 ` [PATCH net-next v15 13/13] net: mdio: realtek-rtl9300: reword Kconfig and module description Markus Stockhausen
2026-09-03  2:10 ` [PATCH net-next v15 00/13] net: mdio: realtek-rtl9300: Add RTL83xx support patchwork-bot+netdevbpf

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=756f8e8f-324d-4dfd-b944-1c71cac73403@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=chris.packham@alliedtelesis.co.nz \
    --cc=conor+dt@kernel.org \
    --cc=daniel@makrotopia.org \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=edumazet@google.com \
    --cc=hkallweit1@gmail.com \
    --cc=krzk+dt@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=markus.stockhausen@gmx.de \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=robh@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.