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

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

[Corentin Labbe]

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/20190820145343.29108-6-megous@megous.com/
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/20220509074857.195302-7-clabbe@baylibre.com/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/0518eef1-75a6-fbfe-96d8-bb1fc4e5178a@linaro.org/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(-)

-- 
2.37.4


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v4 1/3] regulator: Add of_regulator_bulk_get_all

[Corentin Labbe]

It work exactly like regulator_bulk_get() but instead of working on a
provided list of names, it seek all consumers properties matching
xxx-supply.

Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
---
 drivers/regulator/of_regulator.c   | 92 ++++++++++++++++++++++++++++++
 include/linux/regulator/consumer.h |  8 +++
 2 files changed, 100 insertions(+)

diff --git a/drivers/regulator/of_regulator.c b/drivers/regulator/of_regulator.c
index 0aff1c2886b5..584c92f1a317 100644
--- a/drivers/regulator/of_regulator.c
+++ b/drivers/regulator/of_regulator.c
@@ -701,3 +701,95 @@ struct regulator_dev *of_parse_coupled_regulator(struct regulator_dev *rdev,
 
 	return c_rdev;
 }
+
+/*
+ * Check if name is a supply name according to the '*-supply' pattern
+ * return 0 if false
+ * return length of supply name without the -supply
+ */
+static int is_supply_name(const char *name)
+{
+	int strs, i;
+
+	strs = strlen(name);
+	/* string need to be at minimum len(x-supply) */
+	if (strs < 8)
+		return 0;
+	for (i = strs - 6; i > 0; i--) {
+		/* find first '-' and check if right part is supply */
+		if (name[i] != '-')
+			continue;
+		if (strcmp(name + i + 1, "supply") != 0)
+			return 0;
+		return i;
+	}
+	return 0;
+}
+
+/*
+ * of_regulator_bulk_get_all - get multiple regulator consumers
+ *
+ * @dev:	Device to supply
+ * @np:		device node to search for consumers
+ * @consumers:  Configuration of consumers; clients are stored here.
+ *
+ * @return number of regulators on success, an errno on failure.
+ *
+ * This helper function allows drivers to get several regulator
+ * consumers in one operation.  If any of the regulators cannot be
+ * acquired then any regulators that were allocated will be freed
+ * before returning to the caller.
+ */
+int of_regulator_bulk_get_all(struct device *dev, struct device_node *np,
+			      struct regulator_bulk_data **consumers)
+{
+	int num_consumers = 0;
+	struct regulator *tmp;
+	struct property *prop;
+	int i, n = 0, ret;
+	char name[64];
+
+	*consumers = NULL;
+
+	/*
+	 * first pass: get numbers of xxx-supply
+	 * second pass: fill consumers
+	 */
+restart:
+	for_each_property_of_node(np, prop) {
+		i = is_supply_name(prop->name);
+		if (i == 0)
+			continue;
+		if (!*consumers) {
+			num_consumers++;
+			continue;
+		} else {
+			memcpy(name, prop->name, i);
+			name[i] = '\0';
+			tmp = regulator_get(dev, name);
+			if (!tmp) {
+				ret = -EINVAL;
+				goto error;
+			}
+			(*consumers)[n].consumer = tmp;
+			n++;
+			continue;
+		}
+	}
+	if (*consumers)
+		return num_consumers;
+	if (num_consumers == 0)
+		return 0;
+	*consumers = kmalloc_array(num_consumers,
+				   sizeof(struct regulator_bulk_data),
+				   GFP_KERNEL);
+	if (!*consumers)
+		return -ENOMEM;
+	goto restart;
+
+error:
+	while (--n >= 0)
+		regulator_put(consumers[n]->consumer);
+	return ret;
+}
+EXPORT_SYMBOL_GPL(of_regulator_bulk_get_all);
diff --git a/include/linux/regulator/consumer.h b/include/linux/regulator/consumer.h
index 628a52b8e63f..39b666b40ea6 100644
--- a/include/linux/regulator/consumer.h
+++ b/include/linux/regulator/consumer.h
@@ -244,6 +244,8 @@ int regulator_disable_deferred(struct regulator *regulator, int ms);
 
 int __must_check regulator_bulk_get(struct device *dev, int num_consumers,
 				    struct regulator_bulk_data *consumers);
+int __must_check of_regulator_bulk_get_all(struct device *dev, struct device_node *np,
+					   struct regulator_bulk_data **consumers);
 int __must_check devm_regulator_bulk_get(struct device *dev, int num_consumers,
 					 struct regulator_bulk_data *consumers);
 void devm_regulator_bulk_put(struct regulator_bulk_data *consumers);
@@ -481,6 +483,12 @@ static inline int devm_regulator_bulk_get(struct device *dev, int num_consumers,
 	return 0;
 }
 
+static inline int of_regulator_bulk_get_all(struct device *dev, struct device_node *np,
+					    struct regulator_bulk_data **consumers)
+{
+	return 0;
+}
+
 static inline int regulator_bulk_enable(int num_consumers,
 					struct regulator_bulk_data *consumers)
 {
-- 
2.37.4


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v4 1/3] regulator: Add of_regulator_bulk_get_all

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 366 bytes --]

On Tue, Nov 15, 2022 at 07:36:01AM +0000, Corentin Labbe wrote:

> It work exactly like regulator_bulk_get() but instead of working on a
> provided list of names, it seek all consumers properties matching
> xxx-supply.

What's the use case - why would a device not know which supplies
it requires?  This just looks like an invitation to badly written
consumers TBH.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v4 1/3] regulator: Add of_regulator_bulk_get_all

[Corentin LABBE]

Le Tue, Nov 15, 2022 at 10:03:14AM +0000, Mark Brown a écrit :
> On Tue, Nov 15, 2022 at 07:36:01AM +0000, Corentin Labbe wrote:
> 
> > It work exactly like regulator_bulk_get() but instead of working on a
> > provided list of names, it seek all consumers properties matching
> > xxx-supply.
> 
> What's the use case - why would a device not know which supplies
> it requires?  This just looks like an invitation to badly written
> consumers TBH.

Hello

The device know which supply it have, but I found only this way to made all maintainers happy.
See https://lore.kernel.org/netdev/0518eef1-75a6-fbfe-96d8-bb1fc4e5178a@linaro.org/t/#m7a2e012f4c7c7058478811929774ab2af9bfcbf6

Regards

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v4 1/3] regulator: Add of_regulator_bulk_get_all

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 684 bytes --]

On Tue, Nov 15, 2022 at 11:18:50AM +0100, Corentin LABBE wrote:
> Le Tue, Nov 15, 2022 at 10:03:14AM +0000, Mark Brown a écrit :

> > What's the use case - why would a device not know which supplies
> > it requires?  This just looks like an invitation to badly written
> > consumers TBH.

> The device know which supply it have, but I found only this way to made all maintainers happy.
> See https://lore.kernel.org/netdev/0518eef1-75a6-fbfe-96d8-bb1fc4e5178a@linaro.org/t/#m7a2e012f4c7c7058478811929774ab2af9bfcbf6

Well, it's not making this maintainer happy :/  If we know what
PHY is there why not just look up the set of supplies based on
the compatible of the PHY?

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v4 1/3] regulator: Add of_regulator_bulk_get_all

[Russell King (Oracle)]

On Tue, Nov 15, 2022 at 10:34:41AM +0000, Mark Brown wrote:
> On Tue, Nov 15, 2022 at 11:18:50AM +0100, Corentin LABBE wrote:
> > Le Tue, Nov 15, 2022 at 10:03:14AM +0000, Mark Brown a écrit :
> 
> > > What's the use case - why would a device not know which supplies
> > > it requires?  This just looks like an invitation to badly written
> > > consumers TBH.
> 
> > The device know which supply it have, but I found only this way to made all maintainers happy.
> > See https://lore.kernel.org/netdev/0518eef1-75a6-fbfe-96d8-bb1fc4e5178a@linaro.org/t/#m7a2e012f4c7c7058478811929774ab2af9bfcbf6
> 
> Well, it's not making this maintainer happy :/  If we know what
> PHY is there why not just look up the set of supplies based on
> the compatible of the PHY?

It looks to me like this series fetches the regulators before the PHY
is bound to the driver, so what you're proposing would mean that the
core PHY code would need a table of all compatibles (which is pretty
hard to do, they encode the vendor/device ID, not some descriptive
name) and then a list of the regulator names. IMHO that doesn't scale.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v4 1/3] regulator: Add of_regulator_bulk_get_all

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 845 bytes --]

On Tue, Nov 15, 2022 at 10:42:50AM +0000, Russell King (Oracle) wrote:
> On Tue, Nov 15, 2022 at 10:34:41AM +0000, Mark Brown wrote:

> > Well, it's not making this maintainer happy :/  If we know what
> > PHY is there why not just look up the set of supplies based on
> > the compatible of the PHY?

> It looks to me like this series fetches the regulators before the PHY
> is bound to the driver, so what you're proposing would mean that the
> core PHY code would need a table of all compatibles (which is pretty
> hard to do, they encode the vendor/device ID, not some descriptive
> name) and then a list of the regulator names. IMHO that doesn't scale.

Oh, PHYs have interesting enough drivers to dynamically load
here? The last time I was looking at MDIO stuff it was all
running from generic class devices but that was quite a while
ago.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v4 1/3] regulator: Add of_regulator_bulk_get_all

[Russell King (Oracle)]

On Tue, Nov 15, 2022 at 11:16:53AM +0000, Mark Brown wrote:
> On Tue, Nov 15, 2022 at 10:42:50AM +0000, Russell King (Oracle) wrote:
> > On Tue, Nov 15, 2022 at 10:34:41AM +0000, Mark Brown wrote:
> 
> > > Well, it's not making this maintainer happy :/  If we know what
> > > PHY is there why not just look up the set of supplies based on
> > > the compatible of the PHY?
> 
> > It looks to me like this series fetches the regulators before the PHY
> > is bound to the driver, so what you're proposing would mean that the
> > core PHY code would need a table of all compatibles (which is pretty
> > hard to do, they encode the vendor/device ID, not some descriptive
> > name) and then a list of the regulator names. IMHO that doesn't scale.
> 
> Oh, PHYs have interesting enough drivers to dynamically load
> here? The last time I was looking at MDIO stuff it was all
> running from generic class devices but that was quite a while
> ago.

There's a couple of generic drivers which are used if there isn't a
specific driver available for the vendor/device ID that has either
been probed from the hardware, or discovered encoded in the firmware's
compatible property.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v4 1/3] regulator: Add of_regulator_bulk_get_all

[Andrew Lunn]

On Tue, Nov 15, 2022 at 11:16:53AM +0000, Mark Brown wrote:
> On Tue, Nov 15, 2022 at 10:42:50AM +0000, Russell King (Oracle) wrote:
> > On Tue, Nov 15, 2022 at 10:34:41AM +0000, Mark Brown wrote:
> 
> > > Well, it's not making this maintainer happy :/  If we know what
> > > PHY is there why not just look up the set of supplies based on
> > > the compatible of the PHY?
> 
> > It looks to me like this series fetches the regulators before the PHY
> > is bound to the driver, so what you're proposing would mean that the
> > core PHY code would need a table of all compatibles (which is pretty
> > hard to do, they encode the vendor/device ID, not some descriptive
> > name) and then a list of the regulator names. IMHO that doesn't scale.
> 
> Oh, PHYs have interesting enough drivers to dynamically load
> here?

Yes. And you sometimes have the chicken/egg problem that you don't
know what PHY it is until you have turned its regulators on and you
can talk to it. So the PHY code will poke around in the DT
description, and turn on the regulator before enumerating the bus.

	Andrew	     

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v4 1/3] regulator: Add of_regulator_bulk_get_all

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 1279 bytes --]

On Tue, Nov 15, 2022 at 07:36:01AM +0000, Corentin Labbe wrote:
> It work exactly like regulator_bulk_get() but instead of working on a
> provided list of names, it seek all consumers properties matching
> xxx-supply.

The following changes since commit 9abf2313adc1ca1b6180c508c25f22f9395cc780:

  Linux 6.1-rc1 (2022-10-16 15:36:24 -0700)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git tags/of_regulator_bulk_get_all

for you to fetch changes up to 27b9ecc7a9ba1d0014779bfe5a6dbf630899c6e7:

  regulator: Add of_regulator_bulk_get_all (2022-11-18 15:13:34 +0000)

----------------------------------------------------------------
regulator: Add of_regulator_bulk_get_all()

This adds a new of_regulator_bulk_get_all() which grab all supplies
properties in a DT node, for use in implementing generic handling
for things like MDIO PHYs where the physical standardisation of
the bus does not extend to power supplies.

----------------------------------------------------------------
Corentin Labbe (1):
      regulator: Add of_regulator_bulk_get_all

 drivers/regulator/of_regulator.c   | 92 ++++++++++++++++++++++++++++++++++++++
 include/linux/regulator/consumer.h |  8 ++++
 2 files changed, 100 insertions(+)

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v4 2/3] phy: handle optional regulator for PHY

[Corentin Labbe]

Add handling of optional regulators for PHY.
Regulators need to be enabled before PHY scanning, so MDIO bus
initiate this task.

Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
---
 drivers/net/mdio/fwnode_mdio.c | 31 ++++++++++++++++++++++++++++++-
 drivers/net/phy/phy_device.c   | 10 ++++++++++
 include/linux/phy.h            |  3 +++
 3 files changed, 43 insertions(+), 1 deletion(-)

diff --git a/drivers/net/mdio/fwnode_mdio.c b/drivers/net/mdio/fwnode_mdio.c
index 689e728345ce..19a16072d4ca 100644
--- a/drivers/net/mdio/fwnode_mdio.c
+++ b/drivers/net/mdio/fwnode_mdio.c
@@ -10,6 +10,7 @@
 #include <linux/fwnode_mdio.h>
 #include <linux/of.h>
 #include <linux/phy.h>
+#include <linux/regulator/consumer.h>
 #include <linux/pse-pd/pse.h>
 
 MODULE_AUTHOR("Calvin Johnson <calvin.johnson@oss.nxp.com>");
@@ -116,7 +117,9 @@ int fwnode_mdiobus_register_phy(struct mii_bus *bus,
 	struct phy_device *phy;
 	bool is_c45 = false;
 	u32 phy_id;
-	int rc;
+	int rc, reg_cnt = 0;
+	struct regulator_bulk_data *consumers = NULL;
+	struct device_node __maybe_unused *nchild = NULL;
 
 	psec = fwnode_find_pse_control(child);
 	if (IS_ERR(psec))
@@ -133,6 +136,26 @@ int fwnode_mdiobus_register_phy(struct mii_bus *bus,
 	if (rc >= 0)
 		is_c45 = true;
 
+#ifdef CONFIG_OF
+	for_each_child_of_node(bus->dev.of_node, nchild) {
+		u32 reg;
+
+		of_property_read_u32(nchild, "reg", &reg);
+		if (reg != addr)
+			continue;
+		reg_cnt = of_regulator_bulk_get_all(&bus->dev, nchild, &consumers);
+		if (reg_cnt > 0) {
+			rc = regulator_bulk_enable(reg_cnt, consumers);
+			if (rc)
+				return rc;
+		}
+		if (reg_cnt < 0) {
+			dev_err(&bus->dev, "Fail to regulator_bulk_get_all err=%d\n", reg_cnt);
+			return reg_cnt;
+		}
+	}
+#endif
+
 	if (is_c45 || fwnode_get_phy_id(child, &phy_id))
 		phy = get_phy_device(bus, addr, is_c45);
 	else
@@ -142,6 +165,9 @@ int fwnode_mdiobus_register_phy(struct mii_bus *bus,
 		goto clean_mii_ts;
 	}
 
+	phy->regulator_cnt = reg_cnt;
+	phy->consumers = consumers;
+
 	if (is_acpi_node(child)) {
 		phy->irq = bus->irq[addr];
 
@@ -180,6 +206,9 @@ int fwnode_mdiobus_register_phy(struct mii_bus *bus,
 clean_pse:
 	pse_control_put(psec);
 
+	if (reg_cnt > 0)
+		regulator_bulk_disable(reg_cnt, consumers);
+
 	return rc;
 }
 EXPORT_SYMBOL(fwnode_mdiobus_register_phy);
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 57849ac0384e..957e27c75eb2 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -28,6 +28,7 @@
 #include <linux/phy_led_triggers.h>
 #include <linux/pse-pd/pse.h>
 #include <linux/property.h>
+#include <linux/regulator/consumer.h>
 #include <linux/sfp.h>
 #include <linux/skbuff.h>
 #include <linux/slab.h>
@@ -1818,6 +1819,9 @@ int phy_suspend(struct phy_device *phydev)
 	if (!ret)
 		phydev->suspended = true;
 
+	if (phydev->regulator_cnt > 0)
+		regulator_bulk_disable(phydev->regulator_cnt, phydev->consumers);
+
 	return ret;
 }
 EXPORT_SYMBOL(phy_suspend);
@@ -1844,6 +1848,12 @@ int phy_resume(struct phy_device *phydev)
 {
 	int ret;
 
+	if (phydev->regulator_cnt > 0) {
+		ret = regulator_bulk_enable(phydev->regulator_cnt, phydev->consumers);
+		if (ret)
+			return ret;
+	}
+
 	mutex_lock(&phydev->lock);
 	ret = __phy_resume(phydev);
 	mutex_unlock(&phydev->lock);
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 9a3752c0c444..5d1311b35cc3 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -729,6 +729,9 @@ struct phy_device {
 	void (*phy_link_change)(struct phy_device *phydev, bool up);
 	void (*adjust_link)(struct net_device *dev);
 
+	int regulator_cnt;
+	struct regulator_bulk_data *consumers;
+
 #if IS_ENABLED(CONFIG_MACSEC)
 	/* MACsec management functions */
 	const struct macsec_ops *macsec_ops;
-- 
2.37.4


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v4 2/3] phy: handle optional regulator for PHY

[Andrew Lunn]

On Tue, Nov 15, 2022 at 07:36:02AM +0000, Corentin Labbe wrote:
> Add handling of optional regulators for PHY.
> Regulators need to be enabled before PHY scanning, so MDIO bus
> initiate this task.
> 
> Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
> ---
>  drivers/net/mdio/fwnode_mdio.c | 31 ++++++++++++++++++++++++++++++-
>  drivers/net/phy/phy_device.c   | 10 ++++++++++
>  include/linux/phy.h            |  3 +++
>  3 files changed, 43 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/mdio/fwnode_mdio.c b/drivers/net/mdio/fwnode_mdio.c
> index 689e728345ce..19a16072d4ca 100644
> --- a/drivers/net/mdio/fwnode_mdio.c
> +++ b/drivers/net/mdio/fwnode_mdio.c
> @@ -10,6 +10,7 @@
>  #include <linux/fwnode_mdio.h>
>  #include <linux/of.h>
>  #include <linux/phy.h>
> +#include <linux/regulator/consumer.h>
>  #include <linux/pse-pd/pse.h>

These headers are sorted, so please add regulator after pse.

>  
>  MODULE_AUTHOR("Calvin Johnson <calvin.johnson@oss.nxp.com>");
> @@ -116,7 +117,9 @@ int fwnode_mdiobus_register_phy(struct mii_bus *bus,
>  	struct phy_device *phy;
>  	bool is_c45 = false;
>  	u32 phy_id;
> -	int rc;
> +	int rc, reg_cnt = 0;
> +	struct regulator_bulk_data *consumers = NULL;
> +	struct device_node __maybe_unused *nchild = NULL;

Reverse Christmas tree.

>  
>  	psec = fwnode_find_pse_control(child);
>  	if (IS_ERR(psec))
> @@ -133,6 +136,26 @@ int fwnode_mdiobus_register_phy(struct mii_bus *bus,
>  	if (rc >= 0)
>  		is_c45 = true;
>  
> +#ifdef CONFIG_OF

Do you need this #ifdef ? Generally, all of_* functions should have
stubs if CONFIG_OF is not enabled. It would be nice to remove this, so
we get compile testing. And the __maybe_unused above is then probably
not needed.

> +	for_each_child_of_node(bus->dev.of_node, nchild) {
> +		u32 reg;
> +
> +		of_property_read_u32(nchild, "reg", &reg);
> +		if (reg != addr)
> +			continue;
> +		reg_cnt = of_regulator_bulk_get_all(&bus->dev, nchild, &consumers);
> +		if (reg_cnt > 0) {
> +			rc = regulator_bulk_enable(reg_cnt, consumers);
> +			if (rc)
> +				return rc;
> +		}
> +		if (reg_cnt < 0) {
> +			dev_err(&bus->dev, "Fail to regulator_bulk_get_all err=%d\n", reg_cnt);
> +			return reg_cnt;
> +		}
> +	}
> +#endif
> +

	Andrew

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v4 2/3] phy: handle optional regulator for PHY

[Andrew Lunn]

> +		reg_cnt = of_regulator_bulk_get_all(&bus->dev, nchild, &consumers);

This allocates memory for consumers?

I don't see it being freed. I think you need to add to
phy_remove. Plus the error patch should also free it.

	    Andrew

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v4 3/3] arm64: dts: allwinner: orange-pi-3: Enable ethernet

[Corentin Labbe]

From: Ondřej Jirman <megi@xff.cz>

Orange Pi 3 has two regulators that power the Realtek RTL8211E
PHY. According to the datasheet, both regulators need to be enabled
at the same time, or that "phy-io" should be enabled slightly earlier
than "phy" regulator.

RTL8211E/RTL8211EG datasheet says:

  Note 4: 2.5V (or 1.8/1.5V) RGMII power should be risen simultaneously
  or slightly earlier than 3.3V power. Rising 2.5V (or 1.8/1.5V) power
  later than 3.3V power may lead to errors.

The timing is set in DT via startup-delay-us.

Signed-off-by: Ondrej Jirman <megi@xff.cz>
Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
---
 .../dts/allwinner/sun50i-h6-orangepi-3.dts    | 38 +++++++++++++++++++
 1 file changed, 38 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
index 6fc65e8db220..081b004f26ea 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
@@ -13,6 +13,7 @@ / {
 	compatible = "xunlong,orangepi-3", "allwinner,sun50i-h6";
 
 	aliases {
+		ethernet0 = &emac;
 		serial0 = &uart0;
 		serial1 = &uart1;
 	};
@@ -55,6 +56,15 @@ led-1 {
 		};
 	};
 
+	reg_gmac_2v5: gmac-2v5 {
+		compatible = "regulator-fixed";
+		regulator-name = "gmac-2v5";
+		regulator-min-microvolt = <2500000>;
+		regulator-max-microvolt = <2500000>;
+		enable-active-high;
+		gpio = <&pio 3 6 GPIO_ACTIVE_HIGH>; /* PD6 */
+	};
+
 	reg_vcc5v: vcc5v {
 		/* board wide 5V supply directly from the DC jack */
 		compatible = "regulator-fixed";
@@ -113,6 +123,33 @@ &ehci3 {
 	status = "okay";
 };
 
+&emac {
+	pinctrl-names = "default";
+	pinctrl-0 = <&ext_rgmii_pins>;
+	phy-mode = "rgmii-id";
+	phy-handle = <&ext_rgmii_phy>;
+	status = "okay";
+};
+
+&mdio {
+	ext_rgmii_phy: ethernet-phy@1 {
+		compatible = "ethernet-phy-ieee802.3-c22";
+		reg = <1>;
+		/*
+		 * The board uses 2.5V RGMII signalling. Power sequence to enable
+		 * the phy is to enable GMAC-2V5 and GMAC-3V (aldo2) power rails
+		 * at the same time and to wait 100ms. The driver enables phy-io
+		 * first. Delay is achieved with enable-ramp-delay on reg_aldo2.
+		 */
+		phy-io-supply = <&reg_gmac_2v5>;
+		ephy-supply = <&reg_aldo2>;
+
+		reset-gpios = <&pio 3 14 GPIO_ACTIVE_LOW>; /* PD14 */
+		reset-assert-us = <15000>;
+		reset-deassert-us = <40000>;
+	};
+};
+
 &gpu {
 	mali-supply = <&reg_dcdcc>;
 	status = "okay";
@@ -211,6 +248,7 @@ reg_aldo2: aldo2 {
 				regulator-min-microvolt = <3300000>;
 				regulator-max-microvolt = <3300000>;
 				regulator-name = "vcc33-audio-tv-ephy-mac";
+				regulator-enable-ramp-delay = <100000>;
 			};
 
 			/* ALDO3 is shorted to CLDO1 */
-- 
2.37.4


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Andrew Lunn]

> 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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: (subset) [PATCH v4 0/3] arm64: add ethernet to orange pi 3

[Mark Brown]

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/20190820145343.29108-6-megous@megous.com/
> 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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel