Netdev List
 help / color / mirror / Atom feed
From: Aleksei Sviridkin <f@lex.la>
To: andrew@lunn.ch, andrew+netdev@lunn.ch, hkallweit1@gmail.com,
	linux@armlinux.org.uk, davem@davemloft.net, edumazet@google.com,
	kuba@kernel.org, pabeni@redhat.com, horms@kernel.org,
	robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org
Cc: ericwouds@gmail.com, netdev@vger.kernel.org,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	Aleksei Sviridkin <f@lex.la>
Subject: [RFC PATCH net-next v3 0/6] net: mdio: an MDIO device driver for the Airoha EN8811H
Date: Sat, 12 Sep 2026 16:04:24 +0300	[thread overview]
Message-ID: <20260912130430.2246285-1-f@lex.la> (raw)

Last version, not for application, sorry for the noise. The other
option was to drop this quietly. I would rather have the reviewed state
on lore for whoever has a board that needs it; I don't.

The board it was written for does not need it. With the EN8811H
described the ordinary way, the phylink half [1] carries the port: the
PHY driver is a module that arrives after the switch has probed, and
the firmware sits on the squashfs, readable by the time the module
loads.

The second reason v2 [2] gave, a PHY node whose detach wipes the loaded
image, is wrong. I tried it: reset-gpios on the PHY node, the 10 ms
assert delay the Bananapi BPI-R3 Mini and OpenWrt One describe, a
switch unbind that reaches phy_detach(). The MD32 image stays. A marker
written into its RAM reads back unchanged, and the port comes back
after rebind. v2 states the opposite in two places.

What is left is the one-shot probe: -ENOENT at .probe() is not retried,
so a board whose firmware is not readable at that moment either loads
the driver after the filesystem or embeds 144 KB of blobs. That is the
case this driver is for, and I have no such board. Rather stop than
send code I cannot run.

For whoever searches for this later: in-tree the chip is on the
OpenWrt One (mt7981b-openwrt-one) and the Bananapi BPI-R3 Mini
(mt7986a-bananapi-bpi-r3-mini), both with the PHY on a MAC that
attaches at ifup, so neither is that board. Nothing
builds AIR_EN8811H_PHY in by default, so the case is a custom config
with the driver built in and the firmware on a filesystem mounted
later. Out of tree the chip also sits behind the MT7530 DSA bus on
EN7581, mdio-airoha on AN7583 and the SiFlower xgmac; a DSA port losing
a module that arrives late is what the phylink half is for. The
AN8811HB shares the download code touched here and I have none.

The series describes the chip as an MDIO device that owns the download
and the reset, and publishes the PHY on a child bus once the firmware
runs. Patch 4 leaves a running MD32 alone, so a board using the PHY
driver by itself keeps working as before.

Andrew, your points from v2 are answered in that thread. Two things
changed since. I said the next round would go without the RFC tag; it
keeps it, because this one is not for application. And the two
questions I left you there, whether to swap the Kconfig direction and
whether to add a MAINTAINERS record over both files, need no answer
now.

Tested on a Netcraze NC-1012, also sold as the Keenetic KN-1012
(MT7981B, EN8811H on a 2500base-x switch port), OpenWrt 6.18.44, the
series carried as target patches:

  - The MCU driver takes mdio-bus:0d, the PHY appears as mdio-bus:0d:0d
    from /soc/ethernet@15100000/mdio-bus/mcu@d/mdio/ethernet-phy@d,
    DSA attaches it to lan4 with irq=15, the interrupt fires, link up
    at 1Gbps. No bind or unbind in the driver's sysfs directory, rmmod
    of either module refused while the PHY is attached.
  - Download and late arrival, on an image with no firmware in the
    squashfs: the driver binds, publishes nothing, warns once at 61s of
    accumulated waiting naming both files and -ENOENT. Files copied in
    at 103s are taken on the next poll at 128s, the PHY is published,
    DSA attaches it with irq=15, link up at 160s.
  - A PHY node at an address the MCU does not answer: one error naming
    the node and both addresses, -EINVAL, no child bus.
  - Adoption of an already running MD32 has no hardware evidence. This
    board comes up needing firmware on every boot, warm or cold.

Changes since v2:
  - mdiodev_lock() helpers dropped, 7 patches became 6
  - wrong-address and empty-node checks moved into probe, so they fail
    once instead of on every retry
  - child bus lock taken once around the whole programming phase, the
    firmware read stays outside it
  - a failed bus registration keeps retrying on -EPROBE_DEFER
  - resume comment and commit text had the order backwards; the MCU
    resumes before the PHY
  - the detach-wipes-firmware reason is withdrawn

[1] https://lore.kernel.org/netdev/20260908155729.4164814-1-f@lex.la/
[2] https://lore.kernel.org/netdev/20260908155707.4164559-1-f@lex.la/

Aleksei Sviridkin (6):
  dt-bindings: net: add Airoha EN8811H PHY MCU
  net: phy: air: type the buckpbus core on the mdio device
  net: phy: air: move the EN8811H firmware download into the library
  net: phy: air: skip the download when the MD32 is already running
  net: mdio: add Airoha EN8811H MDIO device driver
  net: mdio: en8811h: add the nested bus

 .../bindings/net/airoha,en8811h-mcu.yaml      | 127 +++++
 MAINTAINERS                                   |   8 +
 drivers/net/mdio/Kconfig                      |  13 +
 drivers/net/mdio/Makefile                     |   1 +
 drivers/net/mdio/mdio-airoha-en8811h.c        | 378 +++++++++++++++
 drivers/net/phy/air_en8811h.c                 | 155 +-----
 drivers/net/phy/air_phy_lib.c                 | 440 ++++++++++++++++--
 drivers/net/phy/air_phy_lib.h                 |  27 ++
 include/linux/mdio/mdio-airoha-en8811h.h      |  29 ++
 9 files changed, 999 insertions(+), 179 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/net/airoha,en8811h-mcu.yaml
 create mode 100644 drivers/net/mdio/mdio-airoha-en8811h.c
 create mode 100644 include/linux/mdio/mdio-airoha-en8811h.h


base-commit: ab217fbb9b2169ce677b09a66558d5c3adcfbb76
-- 
2.53.0


             reply	other threads:[~2026-09-12 13:04 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-12 13:04 Aleksei Sviridkin [this message]
2026-09-12 13:04 ` [RFC PATCH net-next v3 1/6] dt-bindings: net: add Airoha EN8811H PHY MCU Aleksei Sviridkin
2026-09-12 13:04 ` [RFC PATCH net-next v3 2/6] net: phy: air: type the buckpbus core on the mdio device Aleksei Sviridkin
2026-09-12 13:04 ` [RFC PATCH net-next v3 3/6] net: phy: air: move the EN8811H firmware download into the library Aleksei Sviridkin
2026-09-12 13:04 ` [RFC PATCH net-next v3 4/6] net: phy: air: skip the download when the MD32 is already running Aleksei Sviridkin
2026-09-12 13:04 ` [RFC PATCH net-next v3 5/6] net: mdio: add Airoha EN8811H MDIO device driver Aleksei Sviridkin
2026-09-12 13:04 ` [RFC PATCH net-next v3 6/6] net: mdio: en8811h: add the nested bus Aleksei Sviridkin

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=20260912130430.2246285-1-f@lex.la \
    --to=f@lex.la \
    --cc=andrew+netdev@lunn.ch \
    --cc=andrew@lunn.ch \
    --cc=conor+dt@kernel.org \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=edumazet@google.com \
    --cc=ericwouds@gmail.com \
    --cc=hkallweit1@gmail.com \
    --cc=horms@kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox