From: Calvin Johnson <hidden> Date: 2021-01-22 18:24:27
This patch set provides ACPI support to DPAA2 network drivers.
It also introduces new fwnode based APIs to support phylink and phy
layers
Following functions are defined:
phylink_fwnode_phy_connect()
fwnode_mdiobus_register_phy()
fwnode_mdiobus_register()
fwnode_get_phy_id()
fwnode_phy_find_device()
device_phy_find_device()
fwnode_get_phy_node()
fwnode_mdio_find_device()
fwnode_get_id()
First one helps in connecting phy to phylink instance.
Next three helps in getting phy_id and registering phy to mdiobus
Next two help in finding a phy on a mdiobus.
Next one helps in getting phy_node from a fwnode.
Last one is used to get fwnode ID.
Corresponding OF functions are refactored.
Tested-on: LS2088ARDB and LX2160ARDB
Changes in v4:
- More cleanup
- Improve code structure to handle all cases
- Remove redundant else from fwnode_mdiobus_register()
- Cleanup xgmac_mdio_probe()
- call phy_device_free() before returning
Changes in v3:
- Add more info on legacy DT properties "phy" and "phy-device"
- Redefine fwnode_phy_find_device() to follow of_phy_find_device()
- Use traditional comparison pattern
- Use GENMASK
- Modified to retrieve reg property value for ACPI as well
- Resolved compilation issue with CONFIG_ACPI = n
- Added more info into documentation
- Use acpi_mdiobus_register()
- Avoid unnecessary line removal
- Remove unused inclusion of acpi.h
Changes in v2:
- Updated with more description in document
- use reverse christmas tree ordering for local variables
- Refactor OF functions to use fwnode functions
Calvin Johnson (15):
Documentation: ACPI: DSD: Document MDIO PHY
net: phy: Introduce fwnode_mdio_find_device()
net: phy: Introduce phy related fwnode functions
of: mdio: Refactor of_phy_find_device()
net: phy: Introduce fwnode_get_phy_id()
of: mdio: Refactor of_get_phy_id()
net: mdiobus: Introduce fwnode_mdiobus_register_phy()
of: mdio: Refactor of_mdiobus_register_phy()
device property: Introduce fwnode_get_id()
net: mdio: Add ACPI support code for mdio
net: mdiobus: Introduce fwnode_mdiobus_register()
net/fsl: Use fwnode_mdiobus_register()
phylink: introduce phylink_fwnode_phy_connect()
net: phylink: Refactor phylink_of_phy_connect()
net: dpaa2-mac: Add ACPI support for DPAA2 MAC driver
Documentation/firmware-guide/acpi/dsd/phy.rst | 129 ++++++++++++++++++
MAINTAINERS | 1 +
drivers/base/property.c | 34 +++++
.../net/ethernet/freescale/dpaa2/dpaa2-mac.c | 87 +++++++-----
drivers/net/ethernet/freescale/xgmac_mdio.c | 11 +-
drivers/net/mdio/Kconfig | 7 +
drivers/net/mdio/Makefile | 1 +
drivers/net/mdio/acpi_mdio.c | 49 +++++++
drivers/net/mdio/of_mdio.c | 79 +----------
drivers/net/phy/mdio_bus.c | 88 ++++++++++++
drivers/net/phy/phy_device.c | 106 ++++++++++++++
drivers/net/phy/phylink.c | 53 ++++---
include/linux/acpi_mdio.h | 27 ++++
include/linux/mdio.h | 2 +
include/linux/of_mdio.h | 6 +-
include/linux/phy.h | 32 +++++
include/linux/phylink.h | 3 +
include/linux/property.h | 1 +
18 files changed, 584 insertions(+), 132 deletions(-)
create mode 100644 Documentation/firmware-guide/acpi/dsd/phy.rst
create mode 100644 drivers/net/mdio/acpi_mdio.c
create mode 100644 include/linux/acpi_mdio.h
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Calvin Johnson <hidden> Date: 2021-01-22 15:47:31
Define fwnode_mdio_find_device() to get a pointer to the
mdio_device from fwnode passed to the function.
Signed-off-by: Calvin Johnson <redacted>
---
Changes in v4: None
Changes in v3: None
Changes in v2: None
drivers/net/mdio/of_mdio.c | 11 +----------
drivers/net/phy/phy_device.c | 23 +++++++++++++++++++++++
include/linux/phy.h | 6 ++++++
3 files changed, 30 insertions(+), 10 deletions(-)
From: Calvin Johnson <hidden> Date: 2021-01-22 15:49:12
With the introduction of fwnode_get_phy_id(), refactor of_get_phy_id()
to use fwnode equivalent.
Signed-off-by: Calvin Johnson <redacted>
---
Changes in v4: None
Changes in v3: None
Changes in v2: None
drivers/net/mdio/of_mdio.c | 12 +-----------
1 file changed, 1 insertion(+), 11 deletions(-)
From: Calvin Johnson <hidden> Date: 2021-01-22 15:49:12
Introduce ACPI mechanism to get PHYs registered on a MDIO bus and
provide them to be connected to MAC.
Describe properties "phy-handle" and "phy-mode".
Signed-off-by: Calvin Johnson <redacted>
---
Changes in v4:
- More cleanup
Changes in v3: None
Changes in v2:
- Updated with more description in document
Documentation/firmware-guide/acpi/dsd/phy.rst | 129 ++++++++++++++++++
1 file changed, 129 insertions(+)
create mode 100644 Documentation/firmware-guide/acpi/dsd/phy.rst
@@ -0,0 +1,129 @@+.. SPDX-License-Identifier: GPL-2.0++=========================+MDIO bus and PHYs in ACPI+=========================++The PHYs on an MDIO bus [1] are probed and registered using+fwnode_mdiobus_register_phy().+Later, for connecting these PHYs to MAC, the PHYs registered on the+MDIO bus have to be referenced.++The UUID given below should be used as mentioned in the "Device Properties+UUID For _DSD" [2] document.+- UUID: daffd814-6eba-4d8c-8a91-bc9bbf4aa301++This document introduces two _DSD properties that are to be used+for PHYs on the MDIO bus.[3]++phy-handle+----------+For each MAC node, a device property "phy-handle" is used to reference+the PHY that is registered on an MDIO bus. This is mandatory for+network interfaces that have PHYs connected to MAC via MDIO bus.++During the MDIO bus driver initialization, PHYs on this bus are probed+using the _ADR object as shown below and are registered on the MDIO bus.++::+ Scope(\_SB.MDI0)+ {+ Device(PHY1) {+ Name (_ADR, 0x1)+ } // end of PHY1++ Device(PHY2) {+ Name (_ADR, 0x2)+ } // end of PHY2+ }++Later, during the MAC driver initialization, the registered PHY devices+have to be retrieved from the MDIO bus. For this, MAC driver needs+reference to the previously registered PHYs which are provided+using reference to the device as {\_SB.MDI0.PHY1}.++phy-mode+--------+The "phy-mode" _DSD property is used to describe the connection to+the PHY. The valid values for "phy-mode" are defined in [4].+++An ASL example of this is shown below.++DSDT entry for MDIO node+------------------------+The MDIO bus has an SoC component(MDIO controller) and a platform+component (PHYs on the MDIO bus).++a) Silicon Component+This node describes the MDIO controller, MDI0+---------------------------------------------+::+ Scope(_SB)+ {+ Device(MDI0) {+ Name(_HID, "NXP0006")+ Name(_CCA, 1)+ Name(_UID, 0)+ Name(_CRS, ResourceTemplate() {+ Memory32Fixed(ReadWrite, MDI0_BASE, MDI_LEN)+ Interrupt(ResourceConsumer, Level, ActiveHigh, Shared)+ {+ MDI0_IT+ }+ }) // end of _CRS for MDI0+ } // end of MDI0+ }++b) Platform Component+This node defines the PHYs that are connected to the MDIO bus, MDI0+-------------------------------------------------------------------+::+ Scope(\_SB.MDI0)+ {+ Device(PHY1) {+ Name (_ADR, 0x1)+ } // end of PHY1++ Device(PHY2) {+ Name (_ADR, 0x2)+ } // end of PHY2+ }+++Below are the MAC nodes where PHY nodes are referenced.+phy-mode and phy-handle are used as explained earlier.+------------------------------------------------------+::+ Scope(\_SB.MCE0.PR17)+ {+ Name (_DSD, Package () {+ ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),+ Package () {+ Package (2) {"phy-mode", "rgmii-id"},+ Package (2) {"phy-handle", \_SB.MDI0.PHY1}+ }+ })+ }++ Scope(\_SB.MCE0.PR18)+ {+ Name (_DSD, Package () {+ ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),+ Package () {+ Package (2) {"phy-mode", "rgmii-id"},+ Package (2) {"phy-handle", \_SB.MDI0.PHY2}}+ }+ })+ }++References+==========++[1] Documentation/networking/phy.rst++[2] https://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf++[3] Documentation/firmware-guide/acpi/DSD-properties-rules.rst++[4] Documentation/devicetree/bindings/net/ethernet-controller.yaml
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
@@ -2,6 +2,7 @@# Makefile for Linux MDIO bus driversobj-$(CONFIG_OF_MDIO)+=of_mdio.o+obj-$(CONFIG_ACPI_MDIO)+=acpi_mdio.oobj-$(CONFIG_MDIO_ASPEED)+=mdio-aspeed.oobj-$(CONFIG_MDIO_BCM_IPROC)+=mdio-bcm-iproc.o
@@ -0,0 +1,49 @@+// SPDX-License-Identifier: GPL-2.0-only+/*+*ACPIhelpersfortheMDIO(EthernetPHY)API+*+*ThisfileprovideshelperfunctionsforextractingPHYdeviceinformation+*outoftheACPIASLandusingittopopulateanmii_bus.+*/++#include<linux/acpi.h>+#include<linux/acpi_mdio.h>++/**+*acpi_mdiobus_register-Registermii_busandcreatePHYsfromtheACPIASL.+*+*@mdio:pointertomii_busstructure+*@fwnode:pointertofwnodeofMDIObus.+*+*Thisfunctionregistersthemii_busstructureandregistersaphy_device+*foreachchildnodeof@fwnode.+*/+intacpi_mdiobus_register(structmii_bus*mdio,structfwnode_handle*fwnode)+{+structfwnode_handle*child;+u32addr;+intret;++/* Mask out all PHYs from auto probing. */+mdio->phy_mask=~0;+ret=mdiobus_register(mdio);+if(ret)+returnret;++mdio->dev.fwnode=fwnode;+/* Loop over the child nodes and register a phy_device for each PHY */+fwnode_for_each_child_node(fwnode,child){+ret=fwnode_get_id(child,&addr);++if(addr>=PHY_MAX_ADDR)+continue;++ret=fwnode_mdiobus_register_phy(mdio,child,addr);+if(ret==-ENODEV)+dev_err(&mdio->dev,+"MDIO device at address %d is missing.\n",+addr);+}+return0;+}+EXPORT_SYMBOL(acpi_mdiobus_register);
From: Calvin Johnson <hidden> Date: 2021-01-22 15:50:49
Using fwnode_get_id(), get the reg property value for DT node
or get the _ADR object value for ACPI node.
Signed-off-by: Calvin Johnson <redacted>
---
Changes in v4:
- Improve code structure to handle all cases
Changes in v3:
- Modified to retrieve reg property value for ACPI as well
- Resolved compilation issue with CONFIG_ACPI = n
- Added more info into documentation
Changes in v2: None
drivers/base/property.c | 34 ++++++++++++++++++++++++++++++++++
include/linux/property.h | 1 +
2 files changed, 35 insertions(+)
@@ -1080,44 +1080,7 @@ EXPORT_SYMBOL_GPL(phylink_connect_phy);intphylink_of_phy_connect(structphylink*pl,structdevice_node*dn,u32flags){-structdevice_node*phy_node;-structphy_device*phy_dev;-intret;--/* Fixed links and 802.3z are handled without needing a PHY */-if(pl->cfg_link_an_mode==MLO_AN_FIXED||-(pl->cfg_link_an_mode==MLO_AN_INBAND&&-phy_interface_mode_is_8023z(pl->link_interface)))-return0;--phy_node=of_parse_phandle(dn,"phy-handle",0);-if(!phy_node)-phy_node=of_parse_phandle(dn,"phy",0);-if(!phy_node)-phy_node=of_parse_phandle(dn,"phy-device",0);--if(!phy_node){-if(pl->cfg_link_an_mode==MLO_AN_PHY)-return-ENODEV;-return0;-}--phy_dev=of_phy_find_device(phy_node);-/* We're done with the phy_node handle */-of_node_put(phy_node);-if(!phy_dev)-return-ENODEV;--ret=phy_attach_direct(pl->netdev,phy_dev,flags,-pl->link_interface);-if(ret)-returnret;--ret=phylink_bringup_phy(pl,phy_dev,pl->link_config.interface);-if(ret)-phy_detach(phy_dev);--returnret;+returnphylink_fwnode_phy_connect(pl,of_fwnode_handle(dn),flags);}EXPORT_SYMBOL_GPL(phylink_of_phy_connect);
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Calvin Johnson <hidden> Date: 2021-01-22 15:56:04
Define phylink_fwnode_phy_connect() to connect phy specified by
a fwnode to a phylink instance.
Signed-off-by: Calvin Johnson <redacted>
---
Changes in v4:
- call phy_device_free() before returning
Changes in v3: None
Changes in v2: None
drivers/net/phy/phylink.c | 56 +++++++++++++++++++++++++++++++++++++++
include/linux/phylink.h | 3 +++
2 files changed, 59 insertions(+)
@@ -1120,6 +1121,61 @@ int phylink_of_phy_connect(struct phylink *pl, struct device_node *dn,}EXPORT_SYMBOL_GPL(phylink_of_phy_connect);+/**+*phylink_fwnode_phy_connect()-connectthePHYspecifiedinthefwnode.+*@pl:apointertoa&structphylinkreturnedfromphylink_create()+*@fwnode:apointertoa&structfwnode_handle.+*@flags:PHY-specificflagstocommunicatetothePHYdevicedriver+*+*Connectthephyspecified@fwnodetothephylinkinstancespecified+*by@pl.+*+*Returns0onsuccessoranegativeerrno.+*/+intphylink_fwnode_phy_connect(structphylink*pl,+structfwnode_handle*fwnode,+u32flags)+{+structfwnode_handle*phy_fwnode;+structphy_device*phy_dev;+intret;++if(is_of_node(fwnode)){+/* Fixed links and 802.3z are handled without needing a PHY */+if(pl->cfg_link_an_mode==MLO_AN_FIXED||+(pl->cfg_link_an_mode==MLO_AN_INBAND&&+phy_interface_mode_is_8023z(pl->link_interface)))+return0;+}++phy_fwnode=fwnode_get_phy_node(fwnode);+if(IS_ERR(phy_fwnode)){+if(pl->cfg_link_an_mode==MLO_AN_PHY)+return-ENODEV;+return0;+}++phy_dev=fwnode_phy_find_device(phy_fwnode);+/* We're done with the phy_node handle */+fwnode_handle_put(phy_fwnode);+if(!phy_dev)+return-ENODEV;++ret=phy_attach_direct(pl->netdev,phy_dev,flags,+pl->link_interface);+if(ret){+phy_device_free(phy_dev);+returnret;+}++ret=phylink_bringup_phy(pl,phy_dev,pl->link_config.interface);+if(ret)+phy_detach(phy_dev);++returnret;+}+EXPORT_SYMBOL_GPL(phylink_fwnode_phy_connect);+/***phylink_disconnect_phy()-disconnectanyPHYattachedtothephylink*instance.
From: Andy Shevchenko <hidden> Date: 2021-01-22 16:27:52
On Fri, Jan 22, 2021 at 09:12:54PM +0530, Calvin Johnson wrote:
Using fwnode_get_id(), get the reg property value for DT node
or get the _ADR object value for ACPI node.
...
+/**
+ * fwnode_get_id - Get the id of a fwnode.
+ * @fwnode: firmware node
+ * @id: id of the fwnode
+ *
+ * This function provides the id of a fwnode which can be either
+ * DT or ACPI node. For ACPI, "reg" property value, if present will
+ * be provided or else _ADR value will be provided.
+ * Returns 0 on success or a negative errno.
+ */
+int fwnode_get_id(struct fwnode_handle *fwnode, u32 *id)
+{
+#ifdef CONFIG_ACPI
+ unsigned long long adr;
+ acpi_status status;
+#endif
Instead you may do...
+ int ret;
+
+ ret = fwnode_property_read_u32(fwnode, "reg", id);
+ if (ret) {
+#ifdef CONFIG_ACPI
...it here like
unsigned long long adr;
acpi_status status;
From: "Rafael J. Wysocki" <rafael@kernel.org> Date: 2021-01-22 17:04:28
On Fri, Jan 22, 2021 at 4:46 PM Calvin Johnson
[off-list ref] wrote:
Using fwnode_get_id(), get the reg property value for DT node
or get the _ADR object value for ACPI node.
So I'm not really sure if this is going to be generically useful.
First of all, the meaning of the _ADR return value is specific to a
given bus type (e.g. the PCI encoding of it is different from the I2C
encoding of it) and it just happens to be matching the definition of
the "reg" property for this particular binding.
IOW, not everyone may expect the "reg" property and the _ADR return
value to have the same encoding and belong to the same set of values,
so maybe put this function somewhere closer to the code that's going
to use it, because it seems to be kind of specific to this particular
use case?
quoted hunk
Signed-off-by: Calvin Johnson <redacted>
---
Changes in v4:
- Improve code structure to handle all cases
Changes in v3:
- Modified to retrieve reg property value for ACPI as well
- Resolved compilation issue with CONFIG_ACPI = n
- Added more info into documentation
Changes in v2: None
drivers/base/property.c | 34 ++++++++++++++++++++++++++++++++++
include/linux/property.h | 1 +
2 files changed, 35 insertions(+)
From: Calvin Johnson <hidden> Date: 2021-01-22 17:33:02
fwnode_mdiobus_register() internally takes care of both DT
and ACPI cases to register mdiobus. Replace existing
of_mdiobus_register() with fwnode_mdiobus_register().
Note: For both ACPI and DT cases, endianness of MDIO controller
need to be specified using "little-endian" property.
Signed-off-by: Calvin Johnson <redacted>
---
Changes in v4:
- Cleanup xgmac_mdio_probe()
Changes in v3:
- Avoid unnecessary line removal
- Remove unused inclusion of acpi.h
Changes in v2: None
drivers/net/ethernet/freescale/xgmac_mdio.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
@@ -243,10 +244,9 @@ static int xgmac_mdio_read(struct mii_bus *bus, int phy_id, int regnum)staticintxgmac_mdio_probe(structplatform_device*pdev){-structdevice_node*np=pdev->dev.of_node;-structmii_bus*bus;-structresource*res;structmdio_fsl_priv*priv;+structresource*res;+structmii_bus*bus;intret;/* In DPAA-1, MDIO is one of the many FMan sub-devices. The FMan
@@ -279,13 +279,16 @@ static int xgmac_mdio_probe(struct platform_device *pdev)gotoerr_ioremap;}+/* For both ACPI and DT cases, endianness of MDIO controller+*needstobespecifiedusing"little-endian"property.+*/priv->is_little_endian=device_property_read_bool(&pdev->dev,"little-endian");priv->has_a011043=device_property_read_bool(&pdev->dev,"fsl,erratum-a011043");-ret=of_mdiobus_register(bus,np);+ret=fwnode_mdiobus_register(bus,pdev->dev.fwnode);if(ret){dev_err(&pdev->dev,"cannot register MDIO bus\n");gotoerr_registration;
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
@@ -98,45 +98,7 @@ EXPORT_SYMBOL(of_mdiobus_phy_device_register);staticintof_mdiobus_register_phy(structmii_bus*mdio,structdevice_node*child,u32addr){-structmii_timestamper*mii_ts;-structphy_device*phy;-boolis_c45;-intrc;-u32phy_id;--mii_ts=of_find_mii_timestamper(child);-if(IS_ERR(mii_ts))-returnPTR_ERR(mii_ts);--is_c45=of_device_is_compatible(child,-"ethernet-phy-ieee802.3-c45");--if(!is_c45&&!of_get_phy_id(child,&phy_id))-phy=phy_device_create(mdio,addr,phy_id,0,NULL);-else-phy=get_phy_device(mdio,addr,is_c45);-if(IS_ERR(phy)){-if(mii_ts)-unregister_mii_timestamper(mii_ts);-returnPTR_ERR(phy);-}--rc=of_mdiobus_phy_device_register(mdio,phy,child,addr);-if(rc){-if(mii_ts)-unregister_mii_timestamper(mii_ts);-phy_device_free(phy);-returnrc;-}--/* phy->mii_ts may already be defined by the PHY driver. A-*mii_timestamperprobedviathedevicetreewillstillhave-*precedence.-*/-if(mii_ts)-phy->mii_ts=mii_ts;--return0;+returnfwnode_mdiobus_register_phy(mdio,of_fwnode_handle(child),addr);}staticintof_mdiobus_register_device(structmii_bus*mdio,
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Calvin Johnson <hidden> Date: 2021-01-22 17:36:36
Introduce fwnode_mdiobus_register() to register PHYs on the mdiobus.
If the fwnode is DT node, then call of_mdiobus_register().
If it is an ACPI node, then call acpi_mdiobus_register().
Signed-off-by: Calvin Johnson <redacted>
---
Changes in v4:
- Remove redundant else from fwnode_mdiobus_register()
Changes in v3:
- Use acpi_mdiobus_register()
Changes in v2: None
drivers/net/phy/mdio_bus.c | 21 +++++++++++++++++++++
include/linux/phy.h | 1 +
2 files changed, 22 insertions(+)
From: Andy Shevchenko <hidden> Date: 2021-01-22 17:56:56
On Fri, Jan 22, 2021 at 05:40:41PM +0100, Rafael J. Wysocki wrote:
On Fri, Jan 22, 2021 at 4:46 PM Calvin Johnson
[off-list ref] wrote:
quoted
Using fwnode_get_id(), get the reg property value for DT node
or get the _ADR object value for ACPI node.
So I'm not really sure if this is going to be generically useful.
First of all, the meaning of the _ADR return value is specific to a
given bus type (e.g. the PCI encoding of it is different from the I2C
encoding of it) and it just happens to be matching the definition of
the "reg" property for this particular binding.
IOW, not everyone may expect the "reg" property and the _ADR return
value to have the same encoding and belong to the same set of values,
I have counted three or even four attempts to open code exact this scenario
in the past couple of years. And I have no idea where to put a common base for
them so they will not duplicate this in each case.
so maybe put this function somewhere closer to the code that's going
to use it, because it seems to be kind of specific to this particular
use case?
From: Calvin Johnson <hidden> Date: 2021-01-22 18:19:23
Introduce fwnode_mdiobus_register_phy() to register PHYs on the
mdiobus. From the compatible string, identify whether the PHY is
c45 and based on this create a PHY device instance which is
registered on the mdiobus.
Signed-off-by: Calvin Johnson <redacted>
---
Changes in v4: None
Changes in v3: None
Changes in v2: None
drivers/net/mdio/of_mdio.c | 3 +-
drivers/net/phy/mdio_bus.c | 67 ++++++++++++++++++++++++++++++++++++++
include/linux/mdio.h | 2 ++
include/linux/of_mdio.h | 6 +++-
4 files changed, 76 insertions(+), 2 deletions(-)
@@ -106,6 +107,72 @@ int mdiobus_unregister_device(struct mdio_device *mdiodev)}EXPORT_SYMBOL(mdiobus_unregister_device);+intfwnode_mdiobus_register_phy(structmii_bus*bus,+structfwnode_handle*child,u32addr)+{+structmii_timestamper*mii_ts;+structphy_device*phy;+boolis_c45=false;+u32phy_id;+intrc;++if(is_of_node(child)){+mii_ts=of_find_mii_timestamper(to_of_node(child));+if(IS_ERR(mii_ts))+returnPTR_ERR(mii_ts);+}++rc=fwnode_property_match_string(child,"compatible","ethernet-phy-ieee802.3-c45");+if(rc>=0)+is_c45=true;++if(is_c45||fwnode_get_phy_id(child,&phy_id))+phy=get_phy_device(bus,addr,is_c45);+else+phy=phy_device_create(bus,addr,phy_id,0,NULL);+if(IS_ERR(phy)){+if(mii_ts&&is_of_node(child))+unregister_mii_timestamper(mii_ts);+returnPTR_ERR(phy);+}++if(is_acpi_node(child)){+phy->irq=bus->irq[addr];++/* Associate the fwnode with the device structure so it+*canbelookeduplater.+*/+phy->mdio.dev.fwnode=child;++/* All data is now stored in the phy struct, so register it */+rc=phy_device_register(phy);+if(rc){+phy_device_free(phy);+fwnode_handle_put(phy->mdio.dev.fwnode);+returnrc;+}++dev_dbg(&bus->dev,"registered phy at address %i\n",addr);+}elseif(is_of_node(child)){+rc=of_mdiobus_phy_device_register(bus,phy,to_of_node(child),addr);+if(rc){+if(mii_ts)+unregister_mii_timestamper(mii_ts);+phy_device_free(phy);+returnrc;+}++/* phy->mii_ts may already be defined by the PHY driver. A+*mii_timestamperprobedviathedevicetreewillstillhave+*precedence.+*/+if(mii_ts)+phy->mii_ts=mii_ts;+}+return0;+}+EXPORT_SYMBOL(fwnode_mdiobus_register_phy);+structphy_device*mdiobus_get_phy(structmii_bus*bus,intaddr){structmdio_device*mdiodev=bus->mdio_map[addr];
From: Calvin Johnson <hidden> Date: 2021-01-22 18:20:21
Extract phy_id from compatible string. This will be used by
fwnode_mdiobus_register_phy() to create phy device using the
phy_id.
Signed-off-by: Calvin Johnson <redacted>
---
Changes in v4: None
Changes in v3:
- Use traditional comparison pattern
- Use GENMASK
Changes in v2: None
drivers/net/phy/phy_device.c | 21 +++++++++++++++++++++
include/linux/phy.h | 5 +++++
2 files changed, 26 insertions(+)
@@ -846,6 +846,27 @@ static int get_phy_c22_id(struct mii_bus *bus, int addr, u32 *phy_id)return0;}+/* Extract the phy ID from the compatible string of the form+*ethernet-phy-idAAAA.BBBB.+*/+intfwnode_get_phy_id(structfwnode_handle*fwnode,u32*phy_id)+{+unsignedintupper,lower;+constchar*cp;+intret;++ret=fwnode_property_read_string(fwnode,"compatible",&cp);+if(ret)+returnret;++if(sscanf(cp,"ethernet-phy-id%4x.%4x",&upper,&lower)!=2)+return-EINVAL;++*phy_id=((upper&GENMASK(15,0))<<16)|(lower&GENMASK(15,0));+return0;+}+EXPORT_SYMBOL(fwnode_get_phy_id);+/***get_phy_device-readsthespecifiedPHYdeviceandreturnsits@phy_device*struct
From: Calvin Johnson <hidden> Date: 2021-01-22 18:21:15
Modify dpaa2_mac_connect() to support ACPI along with DT.
Modify dpaa2_mac_get_node() to get the dpmac fwnode from either
DT or ACPI.
Replace of_get_phy_mode with fwnode_get_phy_mode to get
phy-mode for a dpmac_node.
Use helper function phylink_fwnode_phy_connect() to find phy_dev and
connect to mac->phylink.
Signed-off-by: Calvin Johnson <redacted>
---
Changes in v4: None
Changes in v3: None
Changes in v2:
- Refactor OF functions to use fwnode functions
.../net/ethernet/freescale/dpaa2/dpaa2-mac.c | 87 +++++++++++--------
1 file changed, 50 insertions(+), 37 deletions(-)
@@ -34,39 +37,47 @@ static int phy_mode(enum dpmac_eth_if eth_if, phy_interface_t *if_mode)return0;}-/* Caller must call of_node_put on the returned value */-staticstructdevice_node*dpaa2_mac_get_node(u16dpmac_id)+staticstructfwnode_handle*dpaa2_mac_get_node(structdevice*dev,+u16dpmac_id){-structdevice_node*dpmacs,*dpmac=NULL;-u32id;+structdevice_node*dpmacs=NULL;+structfwnode_handle*parent,*child=NULL;interr;+u32id;-dpmacs=of_find_node_by_name(NULL,"dpmacs");-if(!dpmacs)-returnNULL;+if(is_of_node(dev->parent->fwnode)){+dpmacs=of_find_node_by_name(NULL,"dpmacs");+if(!dpmacs)+returnNULL;+parent=of_fwnode_handle(dpmacs);+}elseif(is_acpi_node(dev->parent->fwnode)){+parent=dev->parent->fwnode;+}-while((dpmac=of_get_next_child(dpmacs,dpmac))!=NULL){-err=of_property_read_u32(dpmac,"reg",&id);-if(err)+fwnode_for_each_child_node(parent,child){+err=fwnode_get_id(child,&id);+if(err){continue;-if(id==dpmac_id)-break;+}elseif(id==dpmac_id){+if(is_of_node(dev->parent->fwnode))+of_node_put(dpmacs);+returnchild;+}}--of_node_put(dpmacs);--returndpmac;+if(is_of_node(dev->parent->fwnode))+of_node_put(dpmacs);+returnNULL;}-staticintdpaa2_mac_get_if_mode(structdevice_node*node,+staticintdpaa2_mac_get_if_mode(structfwnode_handle*dpmac_node,structdpmac_attrattr){phy_interface_tif_mode;interr;-err=of_get_phy_mode(node,&if_mode);-if(!err)-returnif_mode;+err=fwnode_get_phy_mode(dpmac_node);+if(err>0)+returnerr;err=phy_mode(attr.eth_if,&if_mode);if(!err)
@@ -221,26 +232,27 @@ static const struct phylink_mac_ops dpaa2_mac_phylink_ops = {};staticintdpaa2_pcs_create(structdpaa2_mac*mac,-structdevice_node*dpmac_node,intid)+structfwnode_handle*dpmac_node,+intid){structmdio_device*mdiodev;-structdevice_node*node;+structfwnode_handle*node;-node=of_parse_phandle(dpmac_node,"pcs-handle",0);-if(!node){+node=fwnode_find_reference(dpmac_node,"pcs-handle",0);+if(IS_ERR(node)){/* do not error out on old DTS files */netdev_warn(mac->net_dev,"pcs-handle node not found\n");return0;}-if(!of_device_is_available(node)){+if(!of_device_is_available(to_of_node(node))){netdev_err(mac->net_dev,"pcs-handle node not available\n");-of_node_put(node);+of_node_put(to_of_node(node));return-ENODEV;}-mdiodev=of_mdio_find_device(node);-of_node_put(node);+mdiodev=fwnode_mdio_find_device(node);+fwnode_handle_put(node);if(!mdiodev)return-EPROBE_DEFER;
From: Calvin Johnson <hidden> Date: 2021-01-22 18:22:55
Define fwnode_phy_find_device() to iterate an mdiobus and find the
phy device of the provided phy fwnode. Additionally define
device_phy_find_device() to find phy device of provided device.
Define fwnode_get_phy_node() to get phy_node using named reference.
Signed-off-by: Calvin Johnson <redacted>
---
Changes in v4: None
Changes in v3:
- Add more info on legacy DT properties "phy" and "phy-device"
- Redefine fwnode_phy_find_device() to follow of_phy_find_device()
Changes in v2:
- use reverse christmas tree ordering for local variables
drivers/net/phy/phy_device.c | 62 ++++++++++++++++++++++++++++++++++++
include/linux/phy.h | 20 ++++++++++++
2 files changed, 82 insertions(+)
@@ -2852,6 +2853,67 @@ struct mdio_device *fwnode_mdio_find_device(struct fwnode_handle *fwnode)}EXPORT_SYMBOL(fwnode_mdio_find_device);+/**+*fwnode_phy_find_device-Forprovidedphy_fwnode,findphy_device.+*+*@phy_fwnode:Pointertothephy'sfwnode.+*+*Ifsuccessful,returnsapointertothephy_devicewiththeembedded+*structdevicerefcountincrementedbyone,orNULLonfailure.+*/+structphy_device*fwnode_phy_find_device(structfwnode_handle*phy_fwnode)+{+structmdio_device*mdiodev;++mdiodev=fwnode_mdio_find_device(phy_fwnode);+if(!mdiodev)+returnNULL;++if(mdiodev->flags&MDIO_DEVICE_FLAG_PHY)+returnto_phy_device(&mdiodev->dev);++put_device(&mdiodev->dev);++returnNULL;+}+EXPORT_SYMBOL(fwnode_phy_find_device);++/**+*device_phy_find_device-Forthegivendevice,getthephy_device+*@dev:Pointertothegivendevice+*+*Referreturnconditionsoffwnode_phy_find_device().+*/+structphy_device*device_phy_find_device(structdevice*dev)+{+returnfwnode_phy_find_device(dev_fwnode(dev));+}+EXPORT_SYMBOL_GPL(device_phy_find_device);++/**+*fwnode_get_phy_node-Getthephy_nodeusingthenamedreference.+*@fwnode:Pointertofwnodefromwhichphy_nodehastobeobtained.+*+*Referreturnconditionsoffwnode_find_reference().+*ForACPI,only"phy-handle"issupported.LegacyDTproperties"phy"+*and"phy-device"arenotsupportedinACPI.DTsupportsallthethree+*namedreferencestothephynode.+*/+structfwnode_handle*fwnode_get_phy_node(structfwnode_handle*fwnode)+{+structfwnode_handle*phy_node;++/* Only phy-handle is used for ACPI */+phy_node=fwnode_find_reference(fwnode,"phy-handle",0);+if(is_acpi_node(fwnode)||!IS_ERR(phy_node))+returnphy_node;+phy_node=fwnode_find_reference(fwnode,"phy",0);+if(IS_ERR(phy_node))+phy_node=fwnode_find_reference(fwnode,"phy-device",0);+returnphy_node;+}+EXPORT_SYMBOL_GPL(fwnode_get_phy_node);+/***phy_probe-probeandinitaPHYdevice*@dev:devicetoprobeandinit
From: "Rafael J. Wysocki" <rafael@kernel.org> Date: 2021-01-22 18:44:15
On Fri, Jan 22, 2021 at 7:11 PM Rafael J. Wysocki [off-list ref] wrote:
On Fri, Jan 22, 2021 at 6:12 PM Andy Shevchenko
[off-list ref] wrote:
quoted
On Fri, Jan 22, 2021 at 05:40:41PM +0100, Rafael J. Wysocki wrote:
quoted
On Fri, Jan 22, 2021 at 4:46 PM Calvin Johnson
[off-list ref] wrote:
quoted
Using fwnode_get_id(), get the reg property value for DT node
or get the _ADR object value for ACPI node.
So I'm not really sure if this is going to be generically useful.
First of all, the meaning of the _ADR return value is specific to a
given bus type (e.g. the PCI encoding of it is different from the I2C
encoding of it) and it just happens to be matching the definition of
the "reg" property for this particular binding.
quoted
IOW, not everyone may expect the "reg" property and the _ADR return
value to have the same encoding and belong to the same set of values,
I have counted three or even four attempts to open code exact this scenario
in the past couple of years. And I have no idea where to put a common base for
them so they will not duplicate this in each case.
In that case it makes sense to have it in the core, but calling the
_ADR return value an "id" generically is a stretch to put it lightly.
It may be better to call the function something like
fwnode_get_local_bus_id()
From: "Rafael J. Wysocki" <rafael@kernel.org> Date: 2021-01-22 18:47:11
On Fri, Jan 22, 2021 at 4:46 PM Calvin Johnson
[off-list ref] wrote:
quoted hunk
Using fwnode_get_id(), get the reg property value for DT node
or get the _ADR object value for ACPI node.
Signed-off-by: Calvin Johnson <redacted>
---
Changes in v4:
- Improve code structure to handle all cases
Changes in v3:
- Modified to retrieve reg property value for ACPI as well
- Resolved compilation issue with CONFIG_ACPI = n
- Added more info into documentation
Changes in v2: None
drivers/base/property.c | 34 ++++++++++++++++++++++++++++++++++
include/linux/property.h | 1 +
2 files changed, 35 insertions(+)
Please don't return -EINVAL from here, because this means "invalid
argument" to the caller, but there may be nothing wrong with the
fwnode and id pointers.
I would return -ENODATA instead.
From: "Rafael J. Wysocki" <rafael@kernel.org> Date: 2021-01-22 18:47:56
On Fri, Jan 22, 2021 at 6:12 PM Andy Shevchenko
[off-list ref] wrote:
On Fri, Jan 22, 2021 at 05:40:41PM +0100, Rafael J. Wysocki wrote:
quoted
On Fri, Jan 22, 2021 at 4:46 PM Calvin Johnson
[off-list ref] wrote:
quoted
Using fwnode_get_id(), get the reg property value for DT node
or get the _ADR object value for ACPI node.
So I'm not really sure if this is going to be generically useful.
First of all, the meaning of the _ADR return value is specific to a
given bus type (e.g. the PCI encoding of it is different from the I2C
encoding of it) and it just happens to be matching the definition of
the "reg" property for this particular binding.
quoted
IOW, not everyone may expect the "reg" property and the _ADR return
value to have the same encoding and belong to the same set of values,
I have counted three or even four attempts to open code exact this scenario
in the past couple of years. And I have no idea where to put a common base for
them so they will not duplicate this in each case.
In that case it makes sense to have it in the core, but calling the
_ADR return value an "id" generically is a stretch to put it lightly.
It may be better to call the function something like
fwnode_get_local_bus_id() end explain in the kerneldoc comment that
the return value provides a way to distinguish the given device from
the other devices on the same bus segment.
Otherwise it may cause people to expect that the "reg" property and
_ADR are generally equivalent, which is not the case AFAICS.
At least the kerneldoc should say something like "use only if it is
known for a fact that the _ADR return value can be treated as a
fallback replacement for the "reg" property that is missing in the
given use case".
quoted
so maybe put this function somewhere closer to the code that's going
to use it, because it seems to be kind of specific to this particular
use case?
From: "Rafael J. Wysocki" <rafael@kernel.org> Date: 2021-01-22 18:56:24
On Fri, Jan 22, 2021 at 7:13 PM Rafael J. Wysocki [off-list ref] wrote:
On Fri, Jan 22, 2021 at 4:46 PM Calvin Johnson
[off-list ref] wrote:
quoted
Using fwnode_get_id(), get the reg property value for DT node
or get the _ADR object value for ACPI node.
This is not accurate AFAICS, because if the "reg" property is present
in the ACPI case, it will be returned then too.
quoted
Signed-off-by: Calvin Johnson <redacted>
---
Changes in v4:
- Improve code structure to handle all cases
Changes in v3:
- Modified to retrieve reg property value for ACPI as well
- Resolved compilation issue with CONFIG_ACPI = n
- Added more info into documentation
Changes in v2: None
drivers/base/property.c | 34 ++++++++++++++++++++++++++++++++++
include/linux/property.h | 1 +
2 files changed, 35 insertions(+)
What about using the following description instead of the above:
"Retrieve the value of the "reg" property for @fwnode which can be
either DT or ACPI node. In the ACPI case, if the "reg" property is
missing, evaluate the _ADR object located under the given node, if
present, and provide its return value to the caller.
Return 0 on success or a negative error code.
This function can be used only if it is known valid to treat the _ADR
return value as a fallback replacement for the value of the "reg"
property that is missing in the given use case."
quoted
+ */
+int fwnode_get_id(struct fwnode_handle *fwnode, u32 *id)
+{
+#ifdef CONFIG_ACPI
+ unsigned long long adr;
+ acpi_status status;
+#endif
+ int ret;
+
+ ret = fwnode_property_read_u32(fwnode, "reg", id);
+ if (ret) {
+#ifdef CONFIG_ACPI
+ status = acpi_evaluate_integer(ACPI_HANDLE_FWNODE(fwnode),
+ METHOD_NAME__ADR, NULL, &adr);
+ if (ACPI_FAILURE(status))
+ return -EINVAL;
Please don't return -EINVAL from here, because this means "invalid
argument" to the caller, but there may be nothing wrong with the
fwnode and id pointers.
I would return -ENODATA instead.
From: "Rafael J. Wysocki" <rafael@kernel.org> Date: 2021-01-22 19:38:18
On Fri, Jan 22, 2021 at 4:43 PM Calvin Johnson
[off-list ref] wrote:
Introduce ACPI mechanism to get PHYs registered on a MDIO bus and
provide them to be connected to MAC.
Describe properties "phy-handle" and "phy-mode".
Signed-off-by: Calvin Johnson <redacted>
---
Changes in v4:
- More cleanup
This looks much better that the previous versions IMV, some nits below.
quoted hunk
Changes in v3: None
Changes in v2:
- Updated with more description in document
Documentation/firmware-guide/acpi/dsd/phy.rst | 129 ++++++++++++++++++
1 file changed, 129 insertions(+)
create mode 100644 Documentation/firmware-guide/acpi/dsd/phy.rst
@@ -0,0 +1,129 @@+.. SPDX-License-Identifier: GPL-2.0++=========================+MDIO bus and PHYs in ACPI+=========================++The PHYs on an MDIO bus [1] are probed and registered using+fwnode_mdiobus_register_phy().
Empty line here, please.
+Later, for connecting these PHYs to MAC, the PHYs registered on the
+MDIO bus have to be referenced.
+
+The UUID given below should be used as mentioned in the "Device Properties
+UUID For _DSD" [2] document.
+ - UUID: daffd814-6eba-4d8c-8a91-bc9bbf4aa301
I would drop the above paragraph.
+
+This document introduces two _DSD properties that are to be used
+for PHYs on the MDIO bus.[3]
I'd say "for connecting PHYs on the MDIO bus [3] to the MAC layer."
above and add the following here:
"These properties are defined in accordance with the "Device
Properties UUID For _DSD" [2] document and the
daffd814-6eba-4d8c-8a91-bc9bbf4aa301 UUID must be used in the Device
Data Descriptors containing them."
+
+phy-handle
+----------
+For each MAC node, a device property "phy-handle" is used to reference
+the PHY that is registered on an MDIO bus. This is mandatory for
+network interfaces that have PHYs connected to MAC via MDIO bus.
+
+During the MDIO bus driver initialization, PHYs on this bus are probed
+using the _ADR object as shown below and are registered on the MDIO bus.
Do you want to mention the "reg" property here? I think it would be
useful to do that.
+
+::
+ Scope(\_SB.MDI0)
+ {
+ Device(PHY1) {
+ Name (_ADR, 0x1)
+ } // end of PHY1
+
+ Device(PHY2) {
+ Name (_ADR, 0x2)
+ } // end of PHY2
+ }
+
+Later, during the MAC driver initialization, the registered PHY devices
+have to be retrieved from the MDIO bus. For this, MAC driver needs
"the MAC driver" I suppose?
+reference to the previously registered PHYs which are provided
s/reference/references/ (plural)
+using reference to the device as {\_SB.MDI0.PHY1}.
+
+phy-mode
+--------
+The "phy-mode" _DSD property is used to describe the connection to
+the PHY. The valid values for "phy-mode" are defined in [4].
+
One empty line should be sufficient.
+
+An ASL example of this is shown below.
"The following ASL example illustrates the usage of these properties."
+
+DSDT entry for MDIO node
+------------------------
Empty line here, please.
+The MDIO bus has an SoC component(MDIO controller) and a platform
Missing space after "component".
+component (PHYs on the MDIO bus).
+
+a) Silicon Component
+This node describes the MDIO controller, MDI0
+---------------------------------------------
+::
+ Scope(_SB)
+ {
+ Device(MDI0) {
+ Name(_HID, "NXP0006")
+ Name(_CCA, 1)
+ Name(_UID, 0)
+ Name(_CRS, ResourceTemplate() {
+ Memory32Fixed(ReadWrite, MDI0_BASE, MDI_LEN)
+ Interrupt(ResourceConsumer, Level, ActiveHigh, Shared)
+ {
+ MDI0_IT
+ }
+ }) // end of _CRS for MDI0
+ } // end of MDI0
+ }
+
+b) Platform Component
+This node defines the PHYs that are connected to the MDIO bus, MDI0
"The PHY1 and PHY2 nodes represent the PHYs connected to MDIO bus MDI0."
+-------------------------------------------------------------------
+::
+ Scope(\_SB.MDI0)
+ {
+ Device(PHY1) {
+ Name (_ADR, 0x1)
+ } // end of PHY1
+
+ Device(PHY2) {
+ Name (_ADR, 0x2)
+ } // end of PHY2
+ }
+
+
"DSDT entries representing MAC nodes
-----------------------------------"
Plus an empty line.
+Below are the MAC nodes where PHY nodes are referenced.
+phy-mode and phy-handle are used as explained earlier.
+------------------------------------------------------
+::
+ Scope(\_SB.MCE0.PR17)
+ {
+ Name (_DSD, Package () {
+ ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
+ Package () {
+ Package (2) {"phy-mode", "rgmii-id"},
+ Package (2) {"phy-handle", \_SB.MDI0.PHY1}
+ }
+ })
+ }
+
+ Scope(\_SB.MCE0.PR18)
+ {
+ Name (_DSD, Package () {
+ ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
+ Package () {
+ Package (2) {"phy-mode", "rgmii-id"},
+ Package (2) {"phy-handle", \_SB.MDI0.PHY2}}
+ }
+ })
+ }
+
+References
+==========
+
+[1] Documentation/networking/phy.rst
+
+[2] https://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf
+
+[3] Documentation/firmware-guide/acpi/DSD-properties-rules.rst
+
+[4] Documentation/devicetree/bindings/net/ethernet-controller.yaml
--
2.17.1
From: Calvin Johnson <hidden> Date: 2021-01-28 11:29:06
Hi Rafael,
Thanks for the review. I'll work on all the comments.
On Fri, Jan 22, 2021 at 08:22:21PM +0100, Rafael J. Wysocki wrote:
On Fri, Jan 22, 2021 at 4:43 PM Calvin Johnson
[off-list ref] wrote:
quoted
Introduce ACPI mechanism to get PHYs registered on a MDIO bus and
provide them to be connected to MAC.
Describe properties "phy-handle" and "phy-mode".
Signed-off-by: Calvin Johnson <redacted>
---
Changes in v4:
- More cleanup
This looks much better that the previous versions IMV, some nits below.
quoted
Changes in v3: None
Changes in v2:
- Updated with more description in document
Documentation/firmware-guide/acpi/dsd/phy.rst | 129 ++++++++++++++++++
1 file changed, 129 insertions(+)
create mode 100644 Documentation/firmware-guide/acpi/dsd/phy.rst
@@ -0,0 +1,129 @@+.. SPDX-License-Identifier: GPL-2.0++=========================+MDIO bus and PHYs in ACPI+=========================++The PHYs on an MDIO bus [1] are probed and registered using+fwnode_mdiobus_register_phy().
Empty line here, please.
quoted
+Later, for connecting these PHYs to MAC, the PHYs registered on the
+MDIO bus have to be referenced.
+
+The UUID given below should be used as mentioned in the "Device Properties
+UUID For _DSD" [2] document.
+ - UUID: daffd814-6eba-4d8c-8a91-bc9bbf4aa301
I would drop the above paragraph.
quoted
+
+This document introduces two _DSD properties that are to be used
+for PHYs on the MDIO bus.[3]
I'd say "for connecting PHYs on the MDIO bus [3] to the MAC layer."
above and add the following here:
"These properties are defined in accordance with the "Device
Properties UUID For _DSD" [2] document and the
daffd814-6eba-4d8c-8a91-bc9bbf4aa301 UUID must be used in the Device
Data Descriptors containing them."
quoted
+
+phy-handle
+----------
+For each MAC node, a device property "phy-handle" is used to reference
+the PHY that is registered on an MDIO bus. This is mandatory for
+network interfaces that have PHYs connected to MAC via MDIO bus.
+
+During the MDIO bus driver initialization, PHYs on this bus are probed
+using the _ADR object as shown below and are registered on the MDIO bus.
Do you want to mention the "reg" property here? I think it would be
useful to do that.
No. I think we should adhere to _ADR in MDIO case. The "reg" property for ACPI
may be useful for other use cases that Andy is aware of.
Regards
Calvin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: "Rafael J. Wysocki" <rafael@kernel.org> Date: 2021-01-28 12:02:39
On Thu, Jan 28, 2021 at 12:27 PM Calvin Johnson
[off-list ref] wrote:
Hi Rafael,
Thanks for the review. I'll work on all the comments.
On Fri, Jan 22, 2021 at 08:22:21PM +0100, Rafael J. Wysocki wrote:
quoted
On Fri, Jan 22, 2021 at 4:43 PM Calvin Johnson
[off-list ref] wrote:
quoted
Introduce ACPI mechanism to get PHYs registered on a MDIO bus and
provide them to be connected to MAC.
Describe properties "phy-handle" and "phy-mode".
Signed-off-by: Calvin Johnson <redacted>
---
Changes in v4:
- More cleanup
This looks much better that the previous versions IMV, some nits below.
quoted
Changes in v3: None
Changes in v2:
- Updated with more description in document
Documentation/firmware-guide/acpi/dsd/phy.rst | 129 ++++++++++++++++++
1 file changed, 129 insertions(+)
create mode 100644 Documentation/firmware-guide/acpi/dsd/phy.rst
@@ -0,0 +1,129 @@+.. SPDX-License-Identifier: GPL-2.0++=========================+MDIO bus and PHYs in ACPI+=========================++The PHYs on an MDIO bus [1] are probed and registered using+fwnode_mdiobus_register_phy().
Empty line here, please.
quoted
+Later, for connecting these PHYs to MAC, the PHYs registered on the
+MDIO bus have to be referenced.
+
+The UUID given below should be used as mentioned in the "Device Properties
+UUID For _DSD" [2] document.
+ - UUID: daffd814-6eba-4d8c-8a91-bc9bbf4aa301
I would drop the above paragraph.
quoted
+
+This document introduces two _DSD properties that are to be used
+for PHYs on the MDIO bus.[3]
I'd say "for connecting PHYs on the MDIO bus [3] to the MAC layer."
above and add the following here:
"These properties are defined in accordance with the "Device
Properties UUID For _DSD" [2] document and the
daffd814-6eba-4d8c-8a91-bc9bbf4aa301 UUID must be used in the Device
Data Descriptors containing them."
quoted
+
+phy-handle
+----------
+For each MAC node, a device property "phy-handle" is used to reference
+the PHY that is registered on an MDIO bus. This is mandatory for
+network interfaces that have PHYs connected to MAC via MDIO bus.
+
+During the MDIO bus driver initialization, PHYs on this bus are probed
+using the _ADR object as shown below and are registered on the MDIO bus.
Do you want to mention the "reg" property here? I think it would be
useful to do that.
No. I think we should adhere to _ADR in MDIO case. The "reg" property for ACPI
may be useful for other use cases that Andy is aware of.
The code should reflect this, then. I mean it sounds like you want to
check the "reg" property only if this is a non-ACPI node.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Calvin Johnson <hidden> Date: 2021-01-28 13:14:02
On Thu, Jan 28, 2021 at 01:00:40PM +0100, Rafael J. Wysocki wrote:
On Thu, Jan 28, 2021 at 12:27 PM Calvin Johnson
[off-list ref] wrote:
quoted
Hi Rafael,
Thanks for the review. I'll work on all the comments.
On Fri, Jan 22, 2021 at 08:22:21PM +0100, Rafael J. Wysocki wrote:
quoted
On Fri, Jan 22, 2021 at 4:43 PM Calvin Johnson
[off-list ref] wrote:
quoted
Introduce ACPI mechanism to get PHYs registered on a MDIO bus and
provide them to be connected to MAC.
Describe properties "phy-handle" and "phy-mode".
Signed-off-by: Calvin Johnson <redacted>
---
Changes in v4:
- More cleanup
This looks much better that the previous versions IMV, some nits below.
quoted
Changes in v3: None
Changes in v2:
- Updated with more description in document
Documentation/firmware-guide/acpi/dsd/phy.rst | 129 ++++++++++++++++++
1 file changed, 129 insertions(+)
create mode 100644 Documentation/firmware-guide/acpi/dsd/phy.rst
@@ -0,0 +1,129 @@+.. SPDX-License-Identifier: GPL-2.0++=========================+MDIO bus and PHYs in ACPI+=========================++The PHYs on an MDIO bus [1] are probed and registered using+fwnode_mdiobus_register_phy().
Empty line here, please.
quoted
+Later, for connecting these PHYs to MAC, the PHYs registered on the
+MDIO bus have to be referenced.
+
+The UUID given below should be used as mentioned in the "Device Properties
+UUID For _DSD" [2] document.
+ - UUID: daffd814-6eba-4d8c-8a91-bc9bbf4aa301
I would drop the above paragraph.
quoted
+
+This document introduces two _DSD properties that are to be used
+for PHYs on the MDIO bus.[3]
I'd say "for connecting PHYs on the MDIO bus [3] to the MAC layer."
above and add the following here:
"These properties are defined in accordance with the "Device
Properties UUID For _DSD" [2] document and the
daffd814-6eba-4d8c-8a91-bc9bbf4aa301 UUID must be used in the Device
Data Descriptors containing them."
quoted
+
+phy-handle
+----------
+For each MAC node, a device property "phy-handle" is used to reference
+the PHY that is registered on an MDIO bus. This is mandatory for
+network interfaces that have PHYs connected to MAC via MDIO bus.
+
+During the MDIO bus driver initialization, PHYs on this bus are probed
+using the _ADR object as shown below and are registered on the MDIO bus.
Do you want to mention the "reg" property here? I think it would be
useful to do that.
No. I think we should adhere to _ADR in MDIO case. The "reg" property for ACPI
may be useful for other use cases that Andy is aware of.
The code should reflect this, then. I mean it sounds like you want to
check the "reg" property only if this is a non-ACPI node.
From: "Rafael J. Wysocki" <rafael@kernel.org> Date: 2021-01-28 13:28:16
On Thu, Jan 28, 2021 at 2:12 PM Calvin Johnson
[off-list ref] wrote:
On Thu, Jan 28, 2021 at 01:00:40PM +0100, Rafael J. Wysocki wrote:
quoted
On Thu, Jan 28, 2021 at 12:27 PM Calvin Johnson
[off-list ref] wrote:
quoted
Hi Rafael,
Thanks for the review. I'll work on all the comments.
On Fri, Jan 22, 2021 at 08:22:21PM +0100, Rafael J. Wysocki wrote:
quoted
On Fri, Jan 22, 2021 at 4:43 PM Calvin Johnson
[off-list ref] wrote:
quoted
Introduce ACPI mechanism to get PHYs registered on a MDIO bus and
provide them to be connected to MAC.
Describe properties "phy-handle" and "phy-mode".
Signed-off-by: Calvin Johnson <redacted>
---
Changes in v4:
- More cleanup
This looks much better that the previous versions IMV, some nits below.
quoted
Changes in v3: None
Changes in v2:
- Updated with more description in document
Documentation/firmware-guide/acpi/dsd/phy.rst | 129 ++++++++++++++++++
1 file changed, 129 insertions(+)
create mode 100644 Documentation/firmware-guide/acpi/dsd/phy.rst
@@ -0,0 +1,129 @@+.. SPDX-License-Identifier: GPL-2.0++=========================+MDIO bus and PHYs in ACPI+=========================++The PHYs on an MDIO bus [1] are probed and registered using+fwnode_mdiobus_register_phy().
Empty line here, please.
quoted
+Later, for connecting these PHYs to MAC, the PHYs registered on the
+MDIO bus have to be referenced.
+
+The UUID given below should be used as mentioned in the "Device Properties
+UUID For _DSD" [2] document.
+ - UUID: daffd814-6eba-4d8c-8a91-bc9bbf4aa301
I would drop the above paragraph.
quoted
+
+This document introduces two _DSD properties that are to be used
+for PHYs on the MDIO bus.[3]
I'd say "for connecting PHYs on the MDIO bus [3] to the MAC layer."
above and add the following here:
"These properties are defined in accordance with the "Device
Properties UUID For _DSD" [2] document and the
daffd814-6eba-4d8c-8a91-bc9bbf4aa301 UUID must be used in the Device
Data Descriptors containing them."
quoted
+
+phy-handle
+----------
+For each MAC node, a device property "phy-handle" is used to reference
+the PHY that is registered on an MDIO bus. This is mandatory for
+network interfaces that have PHYs connected to MAC via MDIO bus.
+
+During the MDIO bus driver initialization, PHYs on this bus are probed
+using the _ADR object as shown below and are registered on the MDIO bus.
Do you want to mention the "reg" property here? I think it would be
useful to do that.
No. I think we should adhere to _ADR in MDIO case. The "reg" property for ACPI
may be useful for other use cases that Andy is aware of.
The code should reflect this, then. I mean it sounds like you want to
check the "reg" property only if this is a non-ACPI node.
Right. For MDIO case, that is what is required.
"reg" for DT and "_ADR" for ACPI.
However, Andy pointed out [1] that ACPI nodes can also hold reg property and
therefore, fwnode_get_id() need to be capable to handling that situation as
well.
No, please don't confuse those two things.
Yes, ACPI nodes can also hold a "reg" property, but the meaning of it
depends on the binding which is exactly my point: _ADR is not a
fallback replacement for "reg" in general and it is not so for MDIO
too. The new function as proposed doesn't match the MDIO requirements
and so it should not be used for MDIO.
For MDIO, the exact flow mentioned above needs to be implemented (and
if someone wants to use it for their use case too, fine).
Otherwise the code wouldn't match the documentation.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Calvin Johnson <hidden> Date: 2021-01-29 06:49:34
On Thu, Jan 28, 2021 at 02:27:00PM +0100, Rafael J. Wysocki wrote:
On Thu, Jan 28, 2021 at 2:12 PM Calvin Johnson
[off-list ref] wrote:
quoted
On Thu, Jan 28, 2021 at 01:00:40PM +0100, Rafael J. Wysocki wrote:
quoted
On Thu, Jan 28, 2021 at 12:27 PM Calvin Johnson
[off-list ref] wrote:
quoted
Hi Rafael,
Thanks for the review. I'll work on all the comments.
On Fri, Jan 22, 2021 at 08:22:21PM +0100, Rafael J. Wysocki wrote:
quoted
On Fri, Jan 22, 2021 at 4:43 PM Calvin Johnson
[off-list ref] wrote:
quoted
Introduce ACPI mechanism to get PHYs registered on a MDIO bus and
provide them to be connected to MAC.
Describe properties "phy-handle" and "phy-mode".
Signed-off-by: Calvin Johnson <redacted>
---
Changes in v4:
- More cleanup
This looks much better that the previous versions IMV, some nits below.
quoted
Changes in v3: None
Changes in v2:
- Updated with more description in document
Documentation/firmware-guide/acpi/dsd/phy.rst | 129 ++++++++++++++++++
1 file changed, 129 insertions(+)
create mode 100644 Documentation/firmware-guide/acpi/dsd/phy.rst
@@ -0,0 +1,129 @@+.. SPDX-License-Identifier: GPL-2.0++=========================+MDIO bus and PHYs in ACPI+=========================++The PHYs on an MDIO bus [1] are probed and registered using+fwnode_mdiobus_register_phy().
Empty line here, please.
quoted
+Later, for connecting these PHYs to MAC, the PHYs registered on the
+MDIO bus have to be referenced.
+
+The UUID given below should be used as mentioned in the "Device Properties
+UUID For _DSD" [2] document.
+ - UUID: daffd814-6eba-4d8c-8a91-bc9bbf4aa301
I would drop the above paragraph.
quoted
+
+This document introduces two _DSD properties that are to be used
+for PHYs on the MDIO bus.[3]
I'd say "for connecting PHYs on the MDIO bus [3] to the MAC layer."
above and add the following here:
"These properties are defined in accordance with the "Device
Properties UUID For _DSD" [2] document and the
daffd814-6eba-4d8c-8a91-bc9bbf4aa301 UUID must be used in the Device
Data Descriptors containing them."
quoted
+
+phy-handle
+----------
+For each MAC node, a device property "phy-handle" is used to reference
+the PHY that is registered on an MDIO bus. This is mandatory for
+network interfaces that have PHYs connected to MAC via MDIO bus.
+
+During the MDIO bus driver initialization, PHYs on this bus are probed
+using the _ADR object as shown below and are registered on the MDIO bus.
Do you want to mention the "reg" property here? I think it would be
useful to do that.
No. I think we should adhere to _ADR in MDIO case. The "reg" property for ACPI
may be useful for other use cases that Andy is aware of.
The code should reflect this, then. I mean it sounds like you want to
check the "reg" property only if this is a non-ACPI node.
Right. For MDIO case, that is what is required.
"reg" for DT and "_ADR" for ACPI.
However, Andy pointed out [1] that ACPI nodes can also hold reg property and
therefore, fwnode_get_id() need to be capable to handling that situation as
well.
No, please don't confuse those two things.
Yes, ACPI nodes can also hold a "reg" property, but the meaning of it
depends on the binding which is exactly my point: _ADR is not a
fallback replacement for "reg" in general and it is not so for MDIO
too. The new function as proposed doesn't match the MDIO requirements
and so it should not be used for MDIO.
For MDIO, the exact flow mentioned above needs to be implemented (and
if someone wants to use it for their use case too, fine).
Otherwise the code wouldn't match the documentation.
In that case, is this good?
/**
* fwnode_get_local_addr - Get the local address of fwnode.
* @fwnode: firmware node
* @addr: addr value contained in the fwnode
*
* For DT, retrieve the value of the "reg" property for @fwnode.
*
* In the ACPI case, evaluate the _ADR object located under the
* given node, if present, and provide its return value to the
* caller.
*
* Return 0 on success or a negative error code.
*/
int fwnode_get_local_addr(struct fwnode_handle *fwnode, u32 *addr)
{
int ret;
if (is_of_node(fwnode))
return of_property_read_u32(to_of_node(fwnode), "reg", addr);
#ifdef CONFIG_ACPI
if (is_acpi_node(fwnode)) {
unsigned long long adr;
acpi_status status;
status = acpi_evaluate_integer(ACPI_HANDLE_FWNODE(fwnode),
METHOD_NAME__ADR, NULL, &adr);
if (ACPI_FAILURE(status))
return -ENODATA;
*addr = (u32)adr;
return 0;
}
#endif
return -EINVAL;
}
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: "Rafael J. Wysocki" <rafael@kernel.org> Date: 2021-01-29 16:39:28
On Fri, Jan 29, 2021 at 7:48 AM Calvin Johnson
[off-list ref] wrote:
On Thu, Jan 28, 2021 at 02:27:00PM +0100, Rafael J. Wysocki wrote:
quoted
On Thu, Jan 28, 2021 at 2:12 PM Calvin Johnson
[off-list ref] wrote:
quoted
On Thu, Jan 28, 2021 at 01:00:40PM +0100, Rafael J. Wysocki wrote:
quoted
On Thu, Jan 28, 2021 at 12:27 PM Calvin Johnson
[off-list ref] wrote:
quoted
Hi Rafael,
Thanks for the review. I'll work on all the comments.
On Fri, Jan 22, 2021 at 08:22:21PM +0100, Rafael J. Wysocki wrote:
quoted
On Fri, Jan 22, 2021 at 4:43 PM Calvin Johnson
[off-list ref] wrote:
quoted
Introduce ACPI mechanism to get PHYs registered on a MDIO bus and
provide them to be connected to MAC.
Describe properties "phy-handle" and "phy-mode".
Signed-off-by: Calvin Johnson <redacted>
---
Changes in v4:
- More cleanup
This looks much better that the previous versions IMV, some nits below.
quoted
Changes in v3: None
Changes in v2:
- Updated with more description in document
Documentation/firmware-guide/acpi/dsd/phy.rst | 129 ++++++++++++++++++
1 file changed, 129 insertions(+)
create mode 100644 Documentation/firmware-guide/acpi/dsd/phy.rst
@@ -0,0 +1,129 @@+.. SPDX-License-Identifier: GPL-2.0++=========================+MDIO bus and PHYs in ACPI+=========================++The PHYs on an MDIO bus [1] are probed and registered using+fwnode_mdiobus_register_phy().
Empty line here, please.
quoted
+Later, for connecting these PHYs to MAC, the PHYs registered on the
+MDIO bus have to be referenced.
+
+The UUID given below should be used as mentioned in the "Device Properties
+UUID For _DSD" [2] document.
+ - UUID: daffd814-6eba-4d8c-8a91-bc9bbf4aa301
I would drop the above paragraph.
quoted
+
+This document introduces two _DSD properties that are to be used
+for PHYs on the MDIO bus.[3]
I'd say "for connecting PHYs on the MDIO bus [3] to the MAC layer."
above and add the following here:
"These properties are defined in accordance with the "Device
Properties UUID For _DSD" [2] document and the
daffd814-6eba-4d8c-8a91-bc9bbf4aa301 UUID must be used in the Device
Data Descriptors containing them."
quoted
+
+phy-handle
+----------
+For each MAC node, a device property "phy-handle" is used to reference
+the PHY that is registered on an MDIO bus. This is mandatory for
+network interfaces that have PHYs connected to MAC via MDIO bus.
+
+During the MDIO bus driver initialization, PHYs on this bus are probed
+using the _ADR object as shown below and are registered on the MDIO bus.
Do you want to mention the "reg" property here? I think it would be
useful to do that.
No. I think we should adhere to _ADR in MDIO case. The "reg" property for ACPI
may be useful for other use cases that Andy is aware of.
The code should reflect this, then. I mean it sounds like you want to
check the "reg" property only if this is a non-ACPI node.
Right. For MDIO case, that is what is required.
"reg" for DT and "_ADR" for ACPI.
However, Andy pointed out [1] that ACPI nodes can also hold reg property and
therefore, fwnode_get_id() need to be capable to handling that situation as
well.
No, please don't confuse those two things.
Yes, ACPI nodes can also hold a "reg" property, but the meaning of it
depends on the binding which is exactly my point: _ADR is not a
fallback replacement for "reg" in general and it is not so for MDIO
too. The new function as proposed doesn't match the MDIO requirements
and so it should not be used for MDIO.
For MDIO, the exact flow mentioned above needs to be implemented (and
if someone wants to use it for their use case too, fine).
Otherwise the code wouldn't match the documentation.
In that case, is this good?
It would work, but I would introduce a wrapper around the _ADR
evaluation, something like:
int acpi_get_local_address(acpi_handle handle, u32 *addr)
{
unsigned long long adr;
acpi_status status;
status = acpi_evaluate_integer(handle, METHOD_NAME__ADR, NULL, &adr);
if (ACPI_FAILURE(status))
return -ENODATA;
*addr = (u32)adr;
return 0;
}
in drivers/acpi/utils.c and add a static inline stub always returning
-ENODEV for it for !CONFIG_ACPI.
/**
* fwnode_get_local_addr - Get the local address of fwnode.
* @fwnode: firmware node
* @addr: addr value contained in the fwnode
*
* For DT, retrieve the value of the "reg" property for @fwnode.
*
* In the ACPI case, evaluate the _ADR object located under the
* given node, if present, and provide its return value to the
* caller.
*
* Return 0 on success or a negative error code.
*/
int fwnode_get_local_addr(struct fwnode_handle *fwnode, u32 *addr)
{
int ret;
if (is_of_node(fwnode))
return of_property_read_u32(to_of_node(fwnode), "reg", addr);
So you can write the below as
if (is_acpi_device_node(fwnode))
return acpi_get_local_address(ACPI_HANDLE_FWNODE(fwnode), addr);
return -EINVAL;
and this should compile just fine if CONFIG_ACPI is unset, so you can
avoid the whole #ifdeffery in this function.
#ifdef CONFIG_ACPI
if (is_acpi_node(fwnode)) {
unsigned long long adr;
acpi_status status;
status = acpi_evaluate_integer(ACPI_HANDLE_FWNODE(fwnode),
METHOD_NAME__ADR, NULL, &adr);
if (ACPI_FAILURE(status))
return -ENODATA;
*addr = (u32)adr;
return 0;
}
#endif
return -EINVAL;
}
From: "Rafael J. Wysocki" <rafael@kernel.org> Date: 2021-01-29 16:45:24
On Fri, Jan 29, 2021 at 5:37 PM Rafael J. Wysocki [off-list ref] wrote:
On Fri, Jan 29, 2021 at 7:48 AM Calvin Johnson
[off-list ref] wrote:
quoted
On Thu, Jan 28, 2021 at 02:27:00PM +0100, Rafael J. Wysocki wrote:
quoted
On Thu, Jan 28, 2021 at 2:12 PM Calvin Johnson
[off-list ref] wrote:
quoted
On Thu, Jan 28, 2021 at 01:00:40PM +0100, Rafael J. Wysocki wrote:
quoted
On Thu, Jan 28, 2021 at 12:27 PM Calvin Johnson
[off-list ref] wrote:
quoted
Hi Rafael,
Thanks for the review. I'll work on all the comments.
On Fri, Jan 22, 2021 at 08:22:21PM +0100, Rafael J. Wysocki wrote:
quoted
On Fri, Jan 22, 2021 at 4:43 PM Calvin Johnson
[off-list ref] wrote:
quoted
Introduce ACPI mechanism to get PHYs registered on a MDIO bus and
provide them to be connected to MAC.
Describe properties "phy-handle" and "phy-mode".
Signed-off-by: Calvin Johnson <redacted>
---
Changes in v4:
- More cleanup
This looks much better that the previous versions IMV, some nits below.
quoted
Changes in v3: None
Changes in v2:
- Updated with more description in document
Documentation/firmware-guide/acpi/dsd/phy.rst | 129 ++++++++++++++++++
1 file changed, 129 insertions(+)
create mode 100644 Documentation/firmware-guide/acpi/dsd/phy.rst
@@ -0,0 +1,129 @@+.. SPDX-License-Identifier: GPL-2.0++=========================+MDIO bus and PHYs in ACPI+=========================++The PHYs on an MDIO bus [1] are probed and registered using+fwnode_mdiobus_register_phy().
Empty line here, please.
quoted
+Later, for connecting these PHYs to MAC, the PHYs registered on the
+MDIO bus have to be referenced.
+
+The UUID given below should be used as mentioned in the "Device Properties
+UUID For _DSD" [2] document.
+ - UUID: daffd814-6eba-4d8c-8a91-bc9bbf4aa301
I would drop the above paragraph.
quoted
+
+This document introduces two _DSD properties that are to be used
+for PHYs on the MDIO bus.[3]
I'd say "for connecting PHYs on the MDIO bus [3] to the MAC layer."
above and add the following here:
"These properties are defined in accordance with the "Device
Properties UUID For _DSD" [2] document and the
daffd814-6eba-4d8c-8a91-bc9bbf4aa301 UUID must be used in the Device
Data Descriptors containing them."
quoted
+
+phy-handle
+----------
+For each MAC node, a device property "phy-handle" is used to reference
+the PHY that is registered on an MDIO bus. This is mandatory for
+network interfaces that have PHYs connected to MAC via MDIO bus.
+
+During the MDIO bus driver initialization, PHYs on this bus are probed
+using the _ADR object as shown below and are registered on the MDIO bus.
Do you want to mention the "reg" property here? I think it would be
useful to do that.
No. I think we should adhere to _ADR in MDIO case. The "reg" property for ACPI
may be useful for other use cases that Andy is aware of.
The code should reflect this, then. I mean it sounds like you want to
check the "reg" property only if this is a non-ACPI node.
Right. For MDIO case, that is what is required.
"reg" for DT and "_ADR" for ACPI.
However, Andy pointed out [1] that ACPI nodes can also hold reg property and
therefore, fwnode_get_id() need to be capable to handling that situation as
well.
No, please don't confuse those two things.
Yes, ACPI nodes can also hold a "reg" property, but the meaning of it
depends on the binding which is exactly my point: _ADR is not a
fallback replacement for "reg" in general and it is not so for MDIO
too. The new function as proposed doesn't match the MDIO requirements
and so it should not be used for MDIO.
For MDIO, the exact flow mentioned above needs to be implemented (and
if someone wants to use it for their use case too, fine).
Otherwise the code wouldn't match the documentation.
In that case, is this good?
It would work, but I would introduce a wrapper around the _ADR
evaluation, something like:
int acpi_get_local_address(acpi_handle handle, u32 *addr)
{
unsigned long long adr;
acpi_status status;
status = acpi_evaluate_integer(handle, METHOD_NAME__ADR, NULL, &adr);
if (ACPI_FAILURE(status))
return -ENODATA;
*addr = (u32)adr;
return 0;
}
in drivers/acpi/utils.c and add a static inline stub always returning
-ENODEV for it for !CONFIG_ACPI.
quoted
/**
* fwnode_get_local_addr - Get the local address of fwnode.
* @fwnode: firmware node
* @addr: addr value contained in the fwnode
*
* For DT, retrieve the value of the "reg" property for @fwnode.
*
* In the ACPI case, evaluate the _ADR object located under the
* given node, if present, and provide its return value to the
* caller.
*
* Return 0 on success or a negative error code.
*/
int fwnode_get_local_addr(struct fwnode_handle *fwnode, u32 *addr)
{
int ret;
if (is_of_node(fwnode))
return of_property_read_u32(to_of_node(fwnode), "reg", addr);
So you can write the below as
if (is_acpi_device_node(fwnode))
return acpi_get_local_address(ACPI_HANDLE_FWNODE(fwnode), addr);
return -EINVAL;
and this should compile just fine if CONFIG_ACPI is unset, so you can
avoid the whole #ifdeffery in this function.
BTW, you may not need the fwnode_get_local_addr() at all then, just
evaluate either the "reg" property for OF or acpi_get_local_address()
for ACPI in the "caller" code directly. A common helper doing this can
be added later.
quoted
#ifdef CONFIG_ACPI
if (is_acpi_node(fwnode)) {
unsigned long long adr;
acpi_status status;
status = acpi_evaluate_integer(ACPI_HANDLE_FWNODE(fwnode),
METHOD_NAME__ADR, NULL, &adr);
if (ACPI_FAILURE(status))
return -ENODATA;
*addr = (u32)adr;
return 0;
}
#endif
return -EINVAL;
}
From: Andy Shevchenko <hidden> Date: 2021-01-29 17:22:24
On Fri, Jan 29, 2021 at 6:44 PM Rafael J. Wysocki [off-list ref] wrote:
On Fri, Jan 29, 2021 at 5:37 PM Rafael J. Wysocki [off-list ref] wrote:
quoted
On Fri, Jan 29, 2021 at 7:48 AM Calvin Johnson
[off-list ref] wrote:
...
quoted
It would work, but I would introduce a wrapper around the _ADR
evaluation, something like:
int acpi_get_local_address(acpi_handle handle, u32 *addr)
{
unsigned long long adr;
acpi_status status;
status = acpi_evaluate_integer(handle, METHOD_NAME__ADR, NULL, &adr);
if (ACPI_FAILURE(status))
return -ENODATA;
*addr = (u32)adr;
return 0;
}
in drivers/acpi/utils.c and add a static inline stub always returning
-ENODEV for it for !CONFIG_ACPI.
...
BTW, you may not need the fwnode_get_local_addr() at all then, just
evaluate either the "reg" property for OF or acpi_get_local_address()
for ACPI in the "caller" code directly. A common helper doing this can
be added later.
Sounds good to me and it will address your concern about different
semantics of reg/_ADR on per driver/subsystem basis.
--
With Best Regards,
Andy Shevchenko
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Calvin Johnson <hidden> Date: 2021-02-05 17:30:33
On Fri, Jan 22, 2021 at 09:12:52PM +0530, Calvin Johnson wrote:
quoted hunk
Introduce fwnode_mdiobus_register_phy() to register PHYs on the
mdiobus. From the compatible string, identify whether the PHY is
c45 and based on this create a PHY device instance which is
registered on the mdiobus.
Signed-off-by: Calvin Johnson <redacted>
---
Changes in v4: None
Changes in v3: None
Changes in v2: None
drivers/net/mdio/of_mdio.c | 3 +-
drivers/net/phy/mdio_bus.c | 67 ++++++++++++++++++++++++++++++++++++++
include/linux/mdio.h | 2 ++
include/linux/of_mdio.h | 6 +++-
4 files changed, 76 insertions(+), 2 deletions(-)
@@ -106,6 +107,72 @@ int mdiobus_unregister_device(struct mdio_device *mdiodev)}EXPORT_SYMBOL(mdiobus_unregister_device);+intfwnode_mdiobus_register_phy(structmii_bus*bus,+structfwnode_handle*child,u32addr)+{+structmii_timestamper*mii_ts;+structphy_device*phy;+boolis_c45=false;+u32phy_id;+intrc;++if(is_of_node(child)){+mii_ts=of_find_mii_timestamper(to_of_node(child));+if(IS_ERR(mii_ts))+returnPTR_ERR(mii_ts);+}++rc=fwnode_property_match_string(child,"compatible","ethernet-phy-ieee802.3-c45");
With ACPI, I'm facing some problem with fwnode_property_match_string(). It is
unable to detect the compatible string and returns -EPROTO.
ACPI node for PHY4 is as below:
Device(PHY4) {
Name (_ADR, 0x4)
Name(_CRS, ResourceTemplate() {
Interrupt(ResourceConsumer, Level, ActiveHigh, Shared)
{
AQR_PHY4_IT
}
}) // end of _CRS for PHY4
Name (_DSD, Package () {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () {"compatible", "ethernet-phy-ieee802.3-c45"}
}
})
} // end of PHY4
What is see is that in acpi_data_get_property(),
propvalue->type = 0x2(ACPI_TYPE_STRING) and type = 0x4(ACPI_TYPE_PACKAGE).
Any help please?
fwnode_property_match_string() works fine for DT.
Thanks
Calvin
quoted hunk
+ if (rc >= 0)
+ is_c45 = true;
+
+ if (is_c45 || fwnode_get_phy_id(child, &phy_id))
+ phy = get_phy_device(bus, addr, is_c45);
+ else
+ phy = phy_device_create(bus, addr, phy_id, 0, NULL);
+ if (IS_ERR(phy)) {
+ if (mii_ts && is_of_node(child))
+ unregister_mii_timestamper(mii_ts);
+ return PTR_ERR(phy);
+ }
+
+ if (is_acpi_node(child)) {
+ phy->irq = bus->irq[addr];
+
+ /* Associate the fwnode with the device structure so it
+ * can be looked up later.
+ */
+ phy->mdio.dev.fwnode = child;
+
+ /* All data is now stored in the phy struct, so register it */
+ rc = phy_device_register(phy);
+ if (rc) {
+ phy_device_free(phy);
+ fwnode_handle_put(phy->mdio.dev.fwnode);
+ return rc;
+ }
+
+ dev_dbg(&bus->dev, "registered phy at address %i\n", addr);
+ } else if (is_of_node(child)) {
+ rc = of_mdiobus_phy_device_register(bus, phy, to_of_node(child), addr);
+ if (rc) {
+ if (mii_ts)
+ unregister_mii_timestamper(mii_ts);
+ phy_device_free(phy);
+ return rc;
+ }
+
+ /* phy->mii_ts may already be defined by the PHY driver. A
+ * mii_timestamper probed via the device tree will still have
+ * precedence.
+ */
+ if (mii_ts)
+ phy->mii_ts = mii_ts;
+ }
+ return 0;
+}
+EXPORT_SYMBOL(fwnode_mdiobus_register_phy);
+
struct phy_device *mdiobus_get_phy(struct mii_bus *bus, int addr)
{
struct mdio_device *mdiodev = bus->mdio_map[addr];
With ACPI, I'm facing some problem with fwnode_property_match_string(). It is
unable to detect the compatible string and returns -EPROTO.
ACPI node for PHY4 is as below:
Device(PHY4) {
Name (_ADR, 0x4)
Name(_CRS, ResourceTemplate() {
Interrupt(ResourceConsumer, Level, ActiveHigh, Shared)
{
AQR_PHY4_IT
}
}) // end of _CRS for PHY4
Name (_DSD, Package () {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () {"compatible", "ethernet-phy-ieee802.3-c45"}
}
})
} // end of PHY4
What is see is that in acpi_data_get_property(),
propvalue->type = 0x2(ACPI_TYPE_STRING) and type = 0x4(ACPI_TYPE_PACKAGE).
Any help please?
fwnode_property_match_string() works fine for DT.
Can you show the DT node which works and also input for the
)match_string() (i.o.w what exactly you are trying to match with)?
--
With Best Regards,
Andy Shevchenko
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
With ACPI, I'm facing some problem with fwnode_property_match_string(). It is
unable to detect the compatible string and returns -EPROTO.
ACPI node for PHY4 is as below:
Device(PHY4) {
Name (_ADR, 0x4)
Name(_CRS, ResourceTemplate() {
Interrupt(ResourceConsumer, Level, ActiveHigh, Shared)
{
AQR_PHY4_IT
}
}) // end of _CRS for PHY4
Name (_DSD, Package () {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
I guess converting this to
Package () {"compatible", Package() {"ethernet-phy-ieee802.3-c45"}}
will solve it.
quoted
}
quoted
})
} // end of PHY4
What is see is that in acpi_data_get_property(),
propvalue->type = 0x2(ACPI_TYPE_STRING) and type = 0x4(ACPI_TYPE_PACKAGE).
Any help please?
fwnode_property_match_string() works fine for DT.
Can you show the DT node which works and also input for the
)match_string() (i.o.w what exactly you are trying to match with)?
--
With Best Regards,
Andy Shevchenko
With ACPI, I'm facing some problem with fwnode_property_match_string(). It is
unable to detect the compatible string and returns -EPROTO.
ACPI node for PHY4 is as below:
Device(PHY4) {
Name (_ADR, 0x4)
Name(_CRS, ResourceTemplate() {
Interrupt(ResourceConsumer, Level, ActiveHigh, Shared)
{
AQR_PHY4_IT
}
}) // end of _CRS for PHY4
Name (_DSD, Package () {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
I guess converting this to
Package () {"compatible", Package() {"ethernet-phy-ieee802.3-c45"}}
will solve it.
For the record, it doesn't mean there is no bug in the code. DT treats
a single string as an array, but ACPI doesn't.
And this is specific to _match_string() because it has two passes. And
the first one fails.
While reading a single string as an array of 1 element will work I believe.
quoted
quoted
}
quoted
quoted
})
} // end of PHY4
What is see is that in acpi_data_get_property(),
propvalue->type = 0x2(ACPI_TYPE_STRING) and type = 0x4(ACPI_TYPE_PACKAGE).
Any help please?
fwnode_property_match_string() works fine for DT.
Can you show the DT node which works and also input for the
)match_string() (i.o.w what exactly you are trying to match with)?
With ACPI, I'm facing some problem with fwnode_property_match_string(). It is
unable to detect the compatible string and returns -EPROTO.
ACPI node for PHY4 is as below:
Device(PHY4) {
Name (_ADR, 0x4)
Name(_CRS, ResourceTemplate() {
Interrupt(ResourceConsumer, Level, ActiveHigh, Shared)
{
AQR_PHY4_IT
}
}) // end of _CRS for PHY4
Name (_DSD, Package () {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
I guess converting this to
Package () {"compatible", Package() {"ethernet-phy-ieee802.3-c45"}}
will solve it.
Thanks a lot Andy! This helped. But is this the correct way to define compatible
string value, i.e as a sub package.
For the record, it doesn't mean there is no bug in the code. DT treats
a single string as an array, but ACPI doesn't.
And this is specific to _match_string() because it has two passes. And
the first one fails.
While reading a single string as an array of 1 element will work I believe.
quoted
quoted
quoted
}
quoted
quoted
})
} // end of PHY4
What is see is that in acpi_data_get_property(),
propvalue->type = 0x2(ACPI_TYPE_STRING) and type = 0x4(ACPI_TYPE_PACKAGE).
Any help please?
fwnode_property_match_string() works fine for DT.
Can you show the DT node which works and also input for the
)match_string() (i.o.w what exactly you are trying to match with)?