[linux-sunxi] Re: [PATCH v4 2/3] phy: handle optional regulator for PHY
On Tue, Nov 15, 2022 at 07:36:02AM +, 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
> ---
> 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
> #include
> #include
> +#include
> #include
These headers are sorted, so please add regulator after pse.
>
> MODULE_AUTHOR("Calvin Johnson ");
> @@ -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", );
> + if (reg != addr)
> + continue;
> + reg_cnt = of_regulator_bulk_get_all(>dev, nchild,
> );
> + if (reg_cnt > 0) {
> + rc = regulator_bulk_enable(reg_cnt, consumers);
> + if (rc)
> + return rc;
> + }
> + if (reg_cnt < 0) {
> + dev_err(>dev, "Fail to regulator_bulk_get_all
> err=%d\n", reg_cnt);
> + return reg_cnt;
> + }
> + }
> +#endif
> +
Andrew
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/Y3RCG/Xt4y3OfisD%40lunn.ch.
[linux-sunxi] Re: [PATCH v4 0/3] arm64: add ethernet to orange pi 3
> 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 -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/Y3Q/NL4ikhxt1YJI%40lunn.ch.
[linux-sunxi] Re: [PATCH v4 2/3] phy: handle optional regulator for PHY
> + reg_cnt = of_regulator_bulk_get_all(>dev, nchild, > ); 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 -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/Y3RDumClNkEW6L4F%40lunn.ch.
[linux-sunxi] Re: [PATCH v4 1/3] regulator: Add of_regulator_bulk_get_all
On Tue, Nov 15, 2022 at 11:18:50AM +0100, Corentin LABBE wrote: > Le Tue, Nov 15, 2022 at 10:03:14AM +, 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-bb1fc4e51...@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? -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/Y3NrQffcdGIjS64a%40sirena.org.uk. signature.asc Description: PGP signature
[linux-sunxi] Re: [PATCH v4 1/3] regulator: Add of_regulator_bulk_get_all
On Tue, Nov 15, 2022 at 07:36:01AM +, 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. -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/Y3Nj4pA2%2BWRFvSNd%40sirena.org.uk. signature.asc Description: PGP signature
[linux-sunxi] Re: [PATCH v4 1/3] regulator: Add of_regulator_bulk_get_all
On Tue, Nov 15, 2022 at 10:42:50AM +, Russell King (Oracle) wrote: > On Tue, Nov 15, 2022 at 10:34:41AM +, 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. -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/Y3N1JYVx9tB9pisR%40sirena.org.uk. signature.asc Description: PGP signature
[linux-sunxi] Re: [PATCH v4 1/3] regulator: Add of_regulator_bulk_get_all
On Tue, Nov 15, 2022 at 11:16:53AM +, Mark Brown wrote: > On Tue, Nov 15, 2022 at 10:42:50AM +, Russell King (Oracle) wrote: > > On Tue, Nov 15, 2022 at 10:34:41AM +, 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 -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/Y3OYyX2o6BsJKxFh%40lunn.ch.
