From: Bartosz Golaszewski <brgl@kernel.org>

In order to drop the dependency on CONFIG_OF, convert all device property
getters from OF-specific to generic device properties and stop pulling
in any linux/of.h symbols.

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
 drivers/net/ethernet/stmicro/stmmac/Kconfig             | 2 +-
 drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c | 9 ++++-----
 2 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig b/drivers/net/ethernet/stmicro/stmmac/Kconfig
index 907fe2e927f015542b6a7228eae9a6c6945be3ac..1310312e3e099841da89d2f19b138b4459ecb504 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
+++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig
@@ -135,7 +135,7 @@ config DWMAC_MESON
 config DWMAC_QCOM_ETHQOS
 	tristate "Qualcomm ETHQOS support"
 	default ARCH_QCOM
-	depends on OF && (ARCH_QCOM || COMPILE_TEST)
+	depends on ARCH_QCOM || COMPILE_TEST
 	help
 	  Support for the Qualcomm ETHQOS core.
 
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
index 0826a7bd32ff55bef62f8fda4e3eaef64facdb5d..457748e5781231680b64382fa73e195cf7473924 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
@@ -1,8 +1,8 @@
 // SPDX-License-Identifier: GPL-2.0
 // Copyright (c) 2018-19, Linaro Limited
 
+#include <linux/mod_devicetable.h>
 #include <linux/module.h>
-#include <linux/of.h>
 #include <linux/of_net.h>
 #include <linux/platform_device.h>
 #include <linux/phy.h>
@@ -723,7 +723,6 @@ static void ethqos_ptp_clk_freq_config(struct stmmac_priv *priv)
 
 static int qcom_ethqos_probe(struct platform_device *pdev)
 {
-	struct device_node *np = pdev->dev.of_node;
 	const struct ethqos_emac_driver_data *data;
 	struct plat_stmmacenet_data *plat_dat;
 	struct stmmac_resources stmmac_res;
@@ -774,7 +773,7 @@ static int qcom_ethqos_probe(struct platform_device *pdev)
 
 	ethqos->mac_base = stmmac_res.addr;
 
-	data = of_device_get_match_data(dev);
+	data = device_get_match_data(dev);
 	ethqos->por = data->por;
 	ethqos->num_por = data->num_por;
 	ethqos->rgmii_config_loopback_en = data->rgmii_config_loopback_en;
@@ -811,9 +810,9 @@ static int qcom_ethqos_probe(struct platform_device *pdev)
 	if (ethqos->has_emac_ge_3)
 		plat_dat->dwmac4_addrs = &data->dwmac4_addrs;
 	plat_dat->pmt = 1;
-	if (of_property_read_bool(np, "snps,tso"))
+	if (device_property_present(dev, "snps,tso"))
 		plat_dat->flags |= STMMAC_FLAG_TSO_EN;
-	if (of_device_is_compatible(np, "qcom,qcs404-ethqos"))
+	if (device_is_compatible(dev, "qcom,qcs404-ethqos"))
 		plat_dat->flags |= STMMAC_FLAG_RX_CLK_RUNS_IN_LPI;
 	if (data->dma_addr_width)
 		plat_dat->host_dma_width = data->dma_addr_width;

-- 
2.47.3

On Mon, Jan 12, 2026 at 11:15:41AM +0100, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <brgl@kernel.org>
> 
> In order to drop the dependency on CONFIG_OF, convert all device property
> getters from OF-specific to generic device properties and stop pulling
> in any linux/of.h symbols.

Is the intention to read these properties from ACPI tables?

If so, it would be nice to document these properties in
Documentation/firmware-guide/acpi/dsd.

> -	if (of_property_read_bool(np, "snps,tso"))
> +	if (device_property_present(dev, "snps,tso"))
>  		plat_dat->flags |= STMMAC_FLAG_TSO_EN;

Do you actually need this in the ACPI binding? Is there a reason not
to just hard code it enabled? You don't need to worry about backwards
compatibility here, because this is the first ACPI device.

> -	if (of_device_is_compatible(np, "qcom,qcs404-ethqos"))
> +	if (device_is_compatible(dev, "qcom,qcs404-ethqos"))
>  		plat_dat->flags |= STMMAC_FLAG_RX_CLK_RUNS_IN_LPI;

What is your target hardware? Will qcom,qcs404-ethqos every use ACPI?

Maybe this should actually stay as of_device_is_compatible, to make it
clear this is an device tree only device? There is no need to mess up
the ACPI binding with things which will never actually use ACPI.

   Andrew

On Mon, Jan 12, 2026 at 2:45 PM Andrew Lunn <andrew@lunn.ch> wrote:
>
> On Mon, Jan 12, 2026 at 11:15:41AM +0100, Bartosz Golaszewski wrote:
> > From: Bartosz Golaszewski <brgl@kernel.org>
> >
> > In order to drop the dependency on CONFIG_OF, convert all device property
> > getters from OF-specific to generic device properties and stop pulling
> > in any linux/of.h symbols.
>
> Is the intention to read these properties from ACPI tables?
>

No. Other than a couple property getters which can use the fwnode
abstraction, there's nothing here that requires the OF dependence.

Bartosz

On Tue, Jan 13, 2026 at 01:36:53PM +0100, Bartosz Golaszewski wrote:
> On Mon, Jan 12, 2026 at 2:45 PM Andrew Lunn <andrew@lunn.ch> wrote:
> >
> > On Mon, Jan 12, 2026 at 11:15:41AM +0100, Bartosz Golaszewski wrote:
> > > From: Bartosz Golaszewski <brgl@kernel.org>
> > >
> > > In order to drop the dependency on CONFIG_OF, convert all device property
> > > getters from OF-specific to generic device properties and stop pulling
> > > in any linux/of.h symbols.
> >
> > Is the intention to read these properties from ACPI tables?
> >
> 
> No. Other than a couple property getters which can use the fwnode
> abstraction, there's nothing here that requires the OF dependence.

So what is the need for not using OF? Why do you want this patch?

    Andrew

On Tue, Jan 13, 2026 at 11:06 PM Andrew Lunn <andrew@lunn.ch> wrote:
>
> On Tue, Jan 13, 2026 at 01:36:53PM +0100, Bartosz Golaszewski wrote:
> > On Mon, Jan 12, 2026 at 2:45 PM Andrew Lunn <andrew@lunn.ch> wrote:
> > >
> > > On Mon, Jan 12, 2026 at 11:15:41AM +0100, Bartosz Golaszewski wrote:
> > > > From: Bartosz Golaszewski <brgl@kernel.org>
> > > >
> > > > In order to drop the dependency on CONFIG_OF, convert all device property
> > > > getters from OF-specific to generic device properties and stop pulling
> > > > in any linux/of.h symbols.
> > >
> > > Is the intention to read these properties from ACPI tables?
> > >
> >
> > No. Other than a couple property getters which can use the fwnode
> > abstraction, there's nothing here that requires the OF dependence.
>
> So what is the need for not using OF? Why do you want this patch?
>

We've had a higher-level abstraction for OF nodes for years now. Since
I'm already touching the driver, it makes sense to switch to using it,
as OF-centric APIs are not recommended in new code even if it's an
OF-only driver.

Bartosz