[v4,0/3] arm64: add ethernet to orange pi 3

Message

Corentin Labbe Nov. 15, 2022, 7:36 a.m. UTC

Hello

2 sunxi board still does not have ethernet working, orangepi 1+ and
orangepi 3.
This is due to the fact thoses boards have a PHY which need 2 regulators.

A first attempt by Ondřej Jirman was made to support them was made by adding support in
stmmac driver:
https://lore.kernel.org/lkml/[e-mail]/
Proposal rejected, since regulators need to be handled by the PHY core.

My first tentative was to just add handling of phy and phy-io in
phy-core:
https://lore.kernel.org/netdev/[e-mail]/T/
But having hard-coded phy names was rejected.

Second tentative tryed the same path than clocks and clock-names for
regulators.
https://lore.kernel.org/netdev/[e-mail]/t/
But using this was rejected by DT maintainers.

So v3 use a new regulator_bulk_get_all() which grab all supplies
properties in a DT node.
But this way could have some problem, a netdev driver could handle
already its PHY (like dwmac-sun8i already do) and so both phy-core and
the netdev will use both.
It is why phy-supply was renamed in ephy-supply in patch #3.

This serie was tested on whole range of board and PHY architecture:
- internal PHY
  * sun8i-h3-orangepi-pc
- external PHY
  * sun50i-h6-pine-h64
  * sun8i-r40-bananapi-m2-ultra
  * sun8i-a83t-bananapi-m3
  * sun50i-a64-bananapi-m64
  * sun50i-h6-orangepi-3
  * sun50i-h5-nanopi-neo-plus2

The resume/suspend of PHY was tested.

Regards

changes since v1:
- Add regulator_bulk_get_all for ease handling of PHY regulators
- Removed all convertion patchs to keep DT compatibility.

Changes since v2:
- removed use of regulator-names and regulators list.

Changes since v3:
- fixes kbuild robot report

Corentin Labbe (2):
  regulator: Add of_regulator_bulk_get_all
  phy: handle optional regulator for PHY

Ondřej Jirman (1):
  arm64: dts: allwinner: orange-pi-3: Enable ethernet

 .../dts/allwinner/sun50i-h6-orangepi-3.dts    | 38 ++++++++
 drivers/net/mdio/fwnode_mdio.c                | 31 ++++++-
 drivers/net/phy/phy_device.c                  | 10 ++
 drivers/regulator/of_regulator.c              | 92 +++++++++++++++++++
 include/linux/phy.h                           |  3 +
 include/linux/regulator/consumer.h            |  8 ++
 6 files changed, 181 insertions(+), 1 deletion(-)

Comments

Andrew Lunn Nov. 16, 2022, 1:39 a.m. UTC | #1

> But this way could have some problem, a netdev driver could handle
> already its PHY (like dwmac-sun8i already do) and so both phy-core and
> the netdev will use both.
> It is why phy-supply was renamed in ephy-supply in patch #3.

A MAC driver will put its DT properties in the MAC node. A PHY will
put its DT properties in the PHY node of the MDIO bus. Since they are
in different locations, they can use the same name. So please keep
with phy-supply.

Please also update
Documentation/devicetree/bindings/net/ethernet-phy.yaml with these new
properties.

	Andrew

Mark Brown Nov. 18, 2022, 4:11 p.m. UTC | #2

On Tue, 15 Nov 2022 07:36:00 +0000, Corentin Labbe wrote:
> 2 sunxi board still does not have ethernet working, orangepi 1+ and
> orangepi 3.
> This is due to the fact thoses boards have a PHY which need 2 regulators.
> 
> A first attempt by Ondřej Jirman was made to support them was made by adding support in
> stmmac driver:
> https://lore.kernel.org/lkml/[e-mail]/
> Proposal rejected, since regulators need to be handled by the PHY core.
> 
> [...]

Applied to

   broonie/regulator.git for-next

Thanks!

[1/3] regulator: Add of_regulator_bulk_get_all
      commit: 27b9ecc7a9ba1d0014779bfe5a6dbf630899c6e7

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark