* [PATCH v7 3/4] phy: qcom-uniphy: add more registers from display PHYs
From: Dmitry Baryshkov @ 2026-03-23 22:56 UTC (permalink / raw)
To: Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, David Airlie, Simona Vetter,
Vinod Koul, Neil Armstrong
Cc: linux-kernel, linux-arm-msm, dri-devel, freedreno, linux-phy,
Dmitry Baryshkov
In-Reply-To: <20260324-fd-hdmi-phy-v7-0-b41dde8d83b8@oss.qualcomm.com>
From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Import register definitions from 28nm DSI and HDMI PHYs, adding more UNI
PHY registers.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
drivers/phy/qualcomm/phy-qcom-uniphy.h | 42 ++++++++++++++++++++++++++++++++++
1 file changed, 42 insertions(+)
diff --git a/drivers/phy/qualcomm/phy-qcom-uniphy.h b/drivers/phy/qualcomm/phy-qcom-uniphy.h
index e5b79a4dc270..ba9d14aae682 100644
--- a/drivers/phy/qualcomm/phy-qcom-uniphy.h
+++ b/drivers/phy/qualcomm/phy-qcom-uniphy.h
@@ -8,10 +8,30 @@
/* PHY registers */
#define UNIPHY_PLL_REFCLK_CFG 0x000
+#define UNIPHY_PLL_REFCLK_DBLR BIT(0)
+#define UNIPHY_PLL_REFCLK_DIV GENMASK(3, 2)
+
+#define UNIPHY_PLL_POSTDIV1_CFG 0x004
+#define UNIPHY_PLL_CHGPUMP_CFG 0x008
+#define UNIPHY_PLL_VCOLPF_CFG 0x00c
+#define UNIPHY_PLL_VREG_CFG 0x010
#define UNIPHY_PLL_PWRGEN_CFG 0x014
+#define UNIPHY_PLL_DMUX_CFG 0x018
+#define UNIPHY_PLL_AMUX_CFG 0x01c
#define UNIPHY_PLL_GLB_CFG 0x020
+#define UNIPHY_PLL_POSTDIV2_CFG 0x024
+#define UNIPHY_PLL_POSTDIV3_CFG 0x028
+#define UNIPHY_PLL_LPFR_CFG 0x02c
+#define UNIPHY_PLL_LPFC1_CFG 0x030
+#define UNIPHY_PLL_LPFC2_CFG 0x034
#define UNIPHY_PLL_SDM_CFG0 0x038
+#define UNIPHY_PLL_SDM_BYP BIT(6)
+#define UNIPHY_PLL_SDM_BYP_DIV GENMASK(5, 0)
+
#define UNIPHY_PLL_SDM_CFG1 0x03c
+#define UNIPHY_PLL_SDM_DITHER_EN BIT(6)
+#define UNIPHY_PLL_SDM_DC_OFFSET GENMASK(5, 0)
+
#define UNIPHY_PLL_SDM_CFG2 0x040
#define UNIPHY_PLL_SDM_CFG3 0x044
#define UNIPHY_PLL_SDM_CFG4 0x048
@@ -22,11 +42,33 @@
#define UNIPHY_PLL_LKDET_CFG0 0x05c
#define UNIPHY_PLL_LKDET_CFG1 0x060
#define UNIPHY_PLL_LKDET_CFG2 0x064
+#define UNIPHY_PLL_TEST_CFG 0x068
#define UNIPHY_PLL_CAL_CFG0 0x06c
+#define UNIPHY_PLL_CAL_CFG1 0x070
+#define UNIPHY_PLL_CAL_CFG2 0x074
+#define UNIPHY_PLL_CAL_CFG3 0x078
+#define UNIPHY_PLL_CAL_CFG4 0x07c
+#define UNIPHY_PLL_CAL_CFG5 0x080
+#define UNIPHY_PLL_CAL_CFG6 0x084
+#define UNIPHY_PLL_CAL_CFG7 0x088
#define UNIPHY_PLL_CAL_CFG8 0x08c
#define UNIPHY_PLL_CAL_CFG9 0x090
#define UNIPHY_PLL_CAL_CFG10 0x094
#define UNIPHY_PLL_CAL_CFG11 0x098
+#define UNIPHY_PLL_EFUSE_CFG 0x09c
+#define UNIPHY_PLL_DEBUG_BUS_SEL 0x0a0
+#define UNIPHY_PLL_CTRL_42 0x0a4
+#define UNIPHY_PLL_CTRL_43 0x0a8
+#define UNIPHY_PLL_CTRL_44 0x0ac
+#define UNIPHY_PLL_CTRL_45 0x0b0
+#define UNIPHY_PLL_CTRL_46 0x0b4
+#define UNIPHY_PLL_CTRL_47 0x0b8
+#define UNIPHY_PLL_CTRL_48 0x0bc
#define UNIPHY_PLL_STATUS 0x0c0
+#define UNIPHY_PLL_DEBUG_BUS0 0x0c4
+#define UNIPHY_PLL_DEBUG_BUS1 0x0c8
+#define UNIPHY_PLL_DEBUG_BUS2 0x0cc
+#define UNIPHY_PLL_DEBUG_BUS3 0x0d0
+#define UNIPHY_PLL_CTRL_54 0x0d4
#endif
--
2.47.3
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v7 2/4] phy: qcom: apq8064-sata: extract UNI PLL register defines
From: Dmitry Baryshkov @ 2026-03-23 22:56 UTC (permalink / raw)
To: Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, David Airlie, Simona Vetter,
Vinod Koul, Neil Armstrong
Cc: linux-kernel, linux-arm-msm, dri-devel, freedreno, linux-phy,
Dmitry Baryshkov
In-Reply-To: <20260324-fd-hdmi-phy-v7-0-b41dde8d83b8@oss.qualcomm.com>
From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
The "uni" PLL is shared between several PHYS: APQ8064's SATA,
MSM8974/APQ8084 HDMI, MSM8916 DSI, MSM8974/APQ8084 DSI. Extract the
common register names to a separate header with the hope of later having
the common code to handle PLL in those PHYs.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
drivers/phy/qualcomm/phy-qcom-apq8064-sata.c | 23 +-------------------
drivers/phy/qualcomm/phy-qcom-uniphy.h | 32 ++++++++++++++++++++++++++++
2 files changed, 33 insertions(+), 22 deletions(-)
diff --git a/drivers/phy/qualcomm/phy-qcom-apq8064-sata.c b/drivers/phy/qualcomm/phy-qcom-apq8064-sata.c
index cae290a6e19f..dd9929429f9a 100644
--- a/drivers/phy/qualcomm/phy-qcom-apq8064-sata.c
+++ b/drivers/phy/qualcomm/phy-qcom-apq8064-sata.c
@@ -15,28 +15,7 @@
#include <linux/platform_device.h>
#include <linux/phy/phy.h>
-/* PHY registers */
-#define UNIPHY_PLL_REFCLK_CFG 0x000
-#define UNIPHY_PLL_PWRGEN_CFG 0x014
-#define UNIPHY_PLL_GLB_CFG 0x020
-#define UNIPHY_PLL_SDM_CFG0 0x038
-#define UNIPHY_PLL_SDM_CFG1 0x03C
-#define UNIPHY_PLL_SDM_CFG2 0x040
-#define UNIPHY_PLL_SDM_CFG3 0x044
-#define UNIPHY_PLL_SDM_CFG4 0x048
-#define UNIPHY_PLL_SSC_CFG0 0x04C
-#define UNIPHY_PLL_SSC_CFG1 0x050
-#define UNIPHY_PLL_SSC_CFG2 0x054
-#define UNIPHY_PLL_SSC_CFG3 0x058
-#define UNIPHY_PLL_LKDET_CFG0 0x05C
-#define UNIPHY_PLL_LKDET_CFG1 0x060
-#define UNIPHY_PLL_LKDET_CFG2 0x064
-#define UNIPHY_PLL_CAL_CFG0 0x06C
-#define UNIPHY_PLL_CAL_CFG8 0x08C
-#define UNIPHY_PLL_CAL_CFG9 0x090
-#define UNIPHY_PLL_CAL_CFG10 0x094
-#define UNIPHY_PLL_CAL_CFG11 0x098
-#define UNIPHY_PLL_STATUS 0x0C0
+#include "phy-qcom-uniphy.h"
#define SATA_PHY_SER_CTRL 0x100
#define SATA_PHY_TX_DRIV_CTRL0 0x104
diff --git a/drivers/phy/qualcomm/phy-qcom-uniphy.h b/drivers/phy/qualcomm/phy-qcom-uniphy.h
new file mode 100644
index 000000000000..e5b79a4dc270
--- /dev/null
+++ b/drivers/phy/qualcomm/phy-qcom-uniphy.h
@@ -0,0 +1,32 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (c) 2014, The Linux Foundation. All rights reserved.
+ */
+
+#ifndef PHY_QCOM_UNIPHY_H
+#define PHY_QCOM_UNIPHY_H
+
+/* PHY registers */
+#define UNIPHY_PLL_REFCLK_CFG 0x000
+#define UNIPHY_PLL_PWRGEN_CFG 0x014
+#define UNIPHY_PLL_GLB_CFG 0x020
+#define UNIPHY_PLL_SDM_CFG0 0x038
+#define UNIPHY_PLL_SDM_CFG1 0x03c
+#define UNIPHY_PLL_SDM_CFG2 0x040
+#define UNIPHY_PLL_SDM_CFG3 0x044
+#define UNIPHY_PLL_SDM_CFG4 0x048
+#define UNIPHY_PLL_SSC_CFG0 0x04c
+#define UNIPHY_PLL_SSC_CFG1 0x050
+#define UNIPHY_PLL_SSC_CFG2 0x054
+#define UNIPHY_PLL_SSC_CFG3 0x058
+#define UNIPHY_PLL_LKDET_CFG0 0x05c
+#define UNIPHY_PLL_LKDET_CFG1 0x060
+#define UNIPHY_PLL_LKDET_CFG2 0x064
+#define UNIPHY_PLL_CAL_CFG0 0x06c
+#define UNIPHY_PLL_CAL_CFG8 0x08c
+#define UNIPHY_PLL_CAL_CFG9 0x090
+#define UNIPHY_PLL_CAL_CFG10 0x094
+#define UNIPHY_PLL_CAL_CFG11 0x098
+#define UNIPHY_PLL_STATUS 0x0c0
+
+#endif
--
2.47.3
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v7 0/4] drm/msm/hdmi & phy: use generic PHY framework
From: Dmitry Baryshkov @ 2026-03-23 22:56 UTC (permalink / raw)
To: Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, David Airlie, Simona Vetter,
Vinod Koul, Neil Armstrong
Cc: linux-kernel, linux-arm-msm, dri-devel, freedreno, linux-phy,
Dmitry Baryshkov, Konrad Dybcio, Konrad Dybcio
The MSM HDMI PHYs have been using the ad-hoc approach / API instead of
using the generic API framework. Move MSM HDMI PHY drivers to
drivers/phy/qualcomm and rework them to use generic PHY framework. This
way all the QMP-related code is kept at the same place.
Also MSM8974 HDMI PHY, 28nm DSI PHY and apq8964 SATA PHY now can use
common helpers for the UNI PLL.
This also causes some design changes. Currently on MSM8996 the HDMI PLL
implements clock's set_rate(), while other HDMI PHY drivers used the
ad-hoc PHY API for setting the PLL rate (this includes in-tree MSM8960
driver and posted, but not merged, MSM8974 driver). This might result in
the PLL being set to one rate, while the rest of the PHY being tuned to
work at another rate. Adopt the latter idea and always use
phy_configure() to tune the PHY and set the PLL rate.
Merge strategy: Merge the first patch (either through drm/msm or through
the PHY tree), merge the rest of the patches in the next cycle.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
Changes in v7:
- Fixed the build issue between msm8974 patches.
- Dropped even more writel / readl wrappers (now from QMP PHYs)
- Link to v6: https://lore.kernel.org/r/20260319-fd-hdmi-phy-v6-0-cefc08a55470@oss.qualcomm.com
Changes in v6:
- Changed MSM8974 HDMI PHY driver to use FIELD_PREP / FIELD_GET (Konrad)
- Fixed rate recalculation for MSM8974 HDMI PHY (Konrad)
- Dropped register read/write wrappers
- Link to v5: https://lore.kernel.org/r/20260314-fd-hdmi-phy-v5-0-58122ae96d3b@oss.qualcomm.com
Changes in v5:
- Kept only a single place which handles extp clk (after PHY power on,
before PHY power off) (Neil)
- Inlined pm_runtime calls in the HDMI TX driver, replaced
pm_runtime_resume_and_get() with pm_runtime_get_sync(), since
atomic_pre_enable() can not fail.
- Renamed registers defines to drop the REG_ prefix.
- Link to v4: https://lore.kernel.org/r/20250520-fd-hdmi-phy-v4-0-fcbaa652ad75@oss.qualcomm.com
Changes in v3-v4:
- Rebased on top of linux-next, solving conflicts
- Squashed add-and-remove patches into a single git mv patch
- Dropped HDMI PHY header patch (merged upstream)
Changes in v2:
- Changed msm8960 / apq8064 to calculate register data instead of using
fixed tables. This extends the list of supported modes.
(Implementation is based on mdss-hdmi-pll-28lpm.c from msm-4.14).
- Fixed the reprogramming of PLL rate on apq8064.
- Merged all non-QMP HDMI PHY drivers into a common PHY_QCOM_HDMI
driver (suggested by Rob Clark)
---
Dmitry Baryshkov (4):
drm/msm/hdmi: switch to generic PHY subsystem
phy: qcom: apq8064-sata: extract UNI PLL register defines
phy: qcom-uniphy: add more registers from display PHYs
phy: qualcomm: add MSM8974 HDMI PHY support
drivers/gpu/drm/msm/Makefile | 7 -
drivers/gpu/drm/msm/hdmi/hdmi.c | 58 +-
drivers/gpu/drm/msm/hdmi/hdmi.h | 80 +--
drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 80 ++-
drivers/gpu/drm/msm/hdmi/hdmi_phy.c | 225 -------
drivers/gpu/drm/msm/hdmi/hdmi_phy_8960.c | 51 --
drivers/gpu/drm/msm/hdmi/hdmi_phy_8996.c | 761 ----------------------
drivers/gpu/drm/msm/hdmi/hdmi_phy_8998.c | 765 -----------------------
drivers/gpu/drm/msm/hdmi/hdmi_phy_8x60.c | 141 -----
drivers/gpu/drm/msm/hdmi/hdmi_phy_8x74.c | 44 --
drivers/gpu/drm/msm/hdmi/hdmi_pll_8960.c | 460 --------------
drivers/gpu/drm/msm/registers/display/hdmi.xml | 537 ----------------
drivers/phy/qualcomm/Kconfig | 24 +
drivers/phy/qualcomm/Makefile | 14 +
drivers/phy/qualcomm/phy-qcom-apq8064-sata.c | 23 +-
drivers/phy/qualcomm/phy-qcom-hdmi-28hpm.c | 352 +++++++++++
drivers/phy/qualcomm/phy-qcom-hdmi-28lpm.c | 462 ++++++++++++++
drivers/phy/qualcomm/phy-qcom-hdmi-45nm.c | 186 ++++++
drivers/phy/qualcomm/phy-qcom-hdmi-preqmp.c | 212 +++++++
drivers/phy/qualcomm/phy-qcom-hdmi-preqmp.h | 59 ++
drivers/phy/qualcomm/phy-qcom-qmp-hdmi-base.c | 185 ++++++
drivers/phy/qualcomm/phy-qcom-qmp-hdmi-msm8996.c | 440 +++++++++++++
drivers/phy/qualcomm/phy-qcom-qmp-hdmi-msm8998.c | 489 +++++++++++++++
drivers/phy/qualcomm/phy-qcom-qmp-hdmi.h | 49 ++
drivers/phy/qualcomm/phy-qcom-uniphy.h | 74 +++
25 files changed, 2590 insertions(+), 3188 deletions(-)
---
base-commit: 95bcfacccdad8a76e02a8eaa92baaf09c879877e
change-id: 20240109-fd-hdmi-phy-44b8319fbcc7
Best regards,
--
With best wishes
Dmitry
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 04/10] regulator: of: switch to using class_find_device_by_fwnode()
From: Dmitry Torokhov @ 2026-03-23 22:48 UTC (permalink / raw)
To: Andrew Lunn
Cc: Mark Brown, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Vinod Koul, Neil Armstrong,
Liam Girdwood, Lee Jones, Pavel Machek, Peter Rosin,
Heiner Kallweit, Russell King, Moritz Fischer, Xu Yilun, Tom Rix,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich, netdev,
linux-kernel, linux-phy, linux-spi, linux-leds, linux-fpga,
driver-core
In-Reply-To: <27f4ed63-08a2-4621-8943-c50261de31cd@lunn.ch>
On Mon, Mar 23, 2026 at 11:39:03PM +0100, Andrew Lunn wrote:
> > If there is a deprecated property you can do:
> >
> > error = device_property_read_u32(dev, "prop", &val);
> > if (error == -ENOENT)
> > error = device_property_read_u32(dev, "deprecated-prop", &val);
>
> It is not as simple as that. There are a lot of optional
> properties. Say "prop" is optional? And not present. So -ENOENT. We
> then look for this deprecated property. That should not happen.
Why? That is exactly what you want: you favor new one if it is present
and fall back to deprecated one if it is absent. And then you decide
whether to continue or abort.
Or you are saying that new property is optional but old one was
mandatory? Not sure...
>
> Using of_property_read_u32(np, "deprecated-prop", &val) actually makes
> it stand out, it is special somehow, which is good, because it is
> special.
If you only have of_property_read_u32() then it will not stand out. If
you advocate of using device_property_read_u32() normally but
of_property_read_u32() for deprecated only - that is a possibility, but
I do not know if anyone does this.
Thanks.
--
Dmitry
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v5 phy-next 09/27] scsi: ufs: exynos: stop poking into struct phy guts
From: Vladimir Oltean @ 2026-03-23 22:41 UTC (permalink / raw)
To: Alim Akhtar
Cc: 'Martin K. Petersen', linux-phy, 'Vinod Koul',
'Neil Armstrong', dri-devel, freedreno, linux-arm-kernel,
linux-arm-msm, linux-can, linux-gpio, linux-ide, linux-kernel,
linux-media, linux-pci, linux-renesas-soc, linux-riscv,
linux-rockchip, linux-samsung-soc, linux-scsi, linux-sunxi,
linux-tegra, linux-usb, netdev, spacemit, UNGLinuxDriver,
'Bart Van Assche', 'Peter Griffin',
'James E.J. Bottomley', 'Krzysztof Kozlowski',
'Chanho Park'
In-Reply-To: <1891546521.01774280282025.JavaMail.epsvc@epcpadp2new>
On Mon, Mar 23, 2026 at 06:05:36PM +0530, Alim Akhtar wrote:
> Will review and possibly test on one of the board later tonight
Ok, in that case I'll wait. Thanks.
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 04/10] regulator: of: switch to using class_find_device_by_fwnode()
From: Andrew Lunn @ 2026-03-23 22:39 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Mark Brown, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Vinod Koul, Neil Armstrong,
Liam Girdwood, Lee Jones, Pavel Machek, Peter Rosin,
Heiner Kallweit, Russell King, Moritz Fischer, Xu Yilun, Tom Rix,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich, netdev,
linux-kernel, linux-phy, linux-spi, linux-leds, linux-fpga,
driver-core
In-Reply-To: <acG9BPkFr_De-ulu@google.com>
> If there is a deprecated property you can do:
>
> error = device_property_read_u32(dev, "prop", &val);
> if (error == -ENOENT)
> error = device_property_read_u32(dev, "deprecated-prop", &val);
It is not as simple as that. There are a lot of optional
properties. Say "prop" is optional? And not present. So -ENOENT. We
then look for this deprecated property. That should not happen.
Using of_property_read_u32(np, "deprecated-prop", &val) actually makes
it stand out, it is special somehow, which is good, because it is
special.
Andrew
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 04/10] regulator: of: switch to using class_find_device_by_fwnode()
From: Dmitry Torokhov @ 2026-03-23 22:27 UTC (permalink / raw)
To: Andrew Lunn
Cc: Mark Brown, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Vinod Koul, Neil Armstrong,
Liam Girdwood, Lee Jones, Pavel Machek, Peter Rosin,
Heiner Kallweit, Russell King, Moritz Fischer, Xu Yilun, Tom Rix,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich, netdev,
linux-kernel, linux-phy, linux-spi, linux-leds, linux-fpga,
driver-core
In-Reply-To: <09072374-65e7-4792-af7e-97d7df93f9bd@lunn.ch>
On Mon, Mar 23, 2026 at 11:11:58PM +0100, Andrew Lunn wrote:
> On Mon, Mar 23, 2026 at 02:41:03PM -0700, Dmitry Torokhov wrote:
> > On Mon, Mar 23, 2026 at 09:36:07PM +0000, Mark Brown wrote:
> > > On Mon, Mar 23, 2026 at 09:01:47PM +0100, Andrew Lunn wrote:
> > >
> > > > How do you handle deprecated OF properties? This is a problem i've run
> > > > into before. A developer needs an ACPI binding, so they blindly
> > > > convert from of_ to device_ without engaging brain. As a result, they
> > > > bring all the deprecated OF properties we want to die into the brand
> > > > new ACPI bindings.
> > >
> > > Honestly that one hasn't really come up much for me - not too many
> > > deprecated properties.
> >
> > Given that we position properties as an ABI even if they are deprecated
> > we supposed to handle them forever. Newer properties usually offer
> > benefits over old ones and that is how users get moved over.
>
> ~/linux/Documentation/devicetree/bindings/net$ grep -r deprecated * | wc
> 75 361 4195
>
> So networking has ~ 75 of them.
>
> Within the OF world, they are ABI and we need to keep them. But we
> don't want them in ACPI or any other firmware. Any code looking for
> properties needs to know what is underneath so it can decide if it
> should look for the deprecated, OF only property, or not.
If there is a deprecated property you can do:
error = device_property_read_u32(dev, "prop", &val);
if (error == -ENOENT)
error = device_property_read_u32(dev, "deprecated-prop", &val);
You do not need much more than that... Checking node type only
complicates the code, especially when a device can be used on both ACPI
and DT systems.
Thanks.
--
Dmitry
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH net-next 07/10] net: phy: switch to using class_find_device_by_fwnode()
From: Dmitry Torokhov @ 2026-03-23 22:20 UTC (permalink / raw)
To: Andrew Lunn
Cc: Russell King (Oracle), Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Vinod Koul, Neil Armstrong,
Mark Brown, Liam Girdwood, Lee Jones, Pavel Machek, Peter Rosin,
Heiner Kallweit, Moritz Fischer, Xu Yilun, Tom Rix,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich, netdev,
linux-kernel, linux-phy, linux-spi, linux-leds, linux-fpga,
driver-core
In-Reply-To: <f3c51f5d-e001-4a6d-a219-f2e0698f35f9@lunn.ch>
On Mon, Mar 23, 2026 at 11:00:05PM +0100, Andrew Lunn wrote:
> > BTW, why would not we want to push for the unified binding? They are the
> > same pieces of hardware...
>
> I don't think the ACPI committee would be too happy if i ask them to
> throw away their standard and just use DT.
I meant if we are introducing a new to ACPI schema... Not throwing away
existing one.
>
> ACPI and DT are different and we just have to accept it.
>
> Nobody really cares about describing networking hardware in ACPI, so
> there is no need to support it. KISS and keep everything DT.
OK, but even for DT I think we should be using device_property_*() and
fwnode_handle.
If there is an ACPI support for mdio it is perfectly valid to use fwnode
handle on an ACPI system to locate an instance of mdio bus. And
hopefully the caller of this function does not really need to parse
properties itself but will use mdio APIs (mii_bus).
Thanks.
--
Dmitry
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 04/10] regulator: of: switch to using class_find_device_by_fwnode()
From: Andrew Lunn @ 2026-03-23 22:11 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Mark Brown, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Vinod Koul, Neil Armstrong,
Liam Girdwood, Lee Jones, Pavel Machek, Peter Rosin,
Heiner Kallweit, Russell King, Moritz Fischer, Xu Yilun, Tom Rix,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich, netdev,
linux-kernel, linux-phy, linux-spi, linux-leds, linux-fpga,
driver-core
In-Reply-To: <acGzJV3vKhuty3nd@google.com>
On Mon, Mar 23, 2026 at 02:41:03PM -0700, Dmitry Torokhov wrote:
> On Mon, Mar 23, 2026 at 09:36:07PM +0000, Mark Brown wrote:
> > On Mon, Mar 23, 2026 at 09:01:47PM +0100, Andrew Lunn wrote:
> >
> > > How do you handle deprecated OF properties? This is a problem i've run
> > > into before. A developer needs an ACPI binding, so they blindly
> > > convert from of_ to device_ without engaging brain. As a result, they
> > > bring all the deprecated OF properties we want to die into the brand
> > > new ACPI bindings.
> >
> > Honestly that one hasn't really come up much for me - not too many
> > deprecated properties.
>
> Given that we position properties as an ABI even if they are deprecated
> we supposed to handle them forever. Newer properties usually offer
> benefits over old ones and that is how users get moved over.
~/linux/Documentation/devicetree/bindings/net$ grep -r deprecated * | wc
75 361 4195
So networking has ~ 75 of them.
Within the OF world, they are ABI and we need to keep them. But we
don't want them in ACPI or any other firmware. Any code looking for
properties needs to know what is underneath so it can decide if it
should look for the deprecated, OF only property, or not.
Andrew
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH net-next 07/10] net: phy: switch to using class_find_device_by_fwnode()
From: Andrew Lunn @ 2026-03-23 22:00 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Russell King (Oracle), Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Vinod Koul, Neil Armstrong,
Mark Brown, Liam Girdwood, Lee Jones, Pavel Machek, Peter Rosin,
Heiner Kallweit, Moritz Fischer, Xu Yilun, Tom Rix,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich, netdev,
linux-kernel, linux-phy, linux-spi, linux-leds, linux-fpga,
driver-core
In-Reply-To: <acG1JNGVBJ2Mf7jC@google.com>
> BTW, why would not we want to push for the unified binding? They are the
> same pieces of hardware...
I don't think the ACPI committee would be too happy if i ask them to
throw away their standard and just use DT.
ACPI and DT are different and we just have to accept it.
Nobody really cares about describing networking hardware in ACPI, so
there is no need to support it. KISS and keep everything DT.
Andrew
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH net-next 07/10] net: phy: switch to using class_find_device_by_fwnode()
From: Dmitry Torokhov @ 2026-03-23 21:49 UTC (permalink / raw)
To: Andrew Lunn
Cc: Russell King (Oracle), Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Vinod Koul, Neil Armstrong,
Mark Brown, Liam Girdwood, Lee Jones, Pavel Machek, Peter Rosin,
Heiner Kallweit, Moritz Fischer, Xu Yilun, Tom Rix,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich, netdev,
linux-kernel, linux-phy, linux-spi, linux-leds, linux-fpga,
driver-core
In-Reply-To: <f37684ff-57af-425a-bb18-bd5e8de3bba3@lunn.ch>
On Mon, Mar 23, 2026 at 09:15:11PM +0100, Andrew Lunn wrote:
> > This is not "foreign territory" - ACPI in general doesn't want to
> > describe e.g. the individual components of a network card, unlike
> > DT.
>
> It has also been suggested that the MDIO bus should be added to the
> ACPI specification as a first class bus, similar to I2C, SPI,
> etc. This would make it different to the DT. So we don't want to
> encourage developers to use the networking DT concepts in ACPI, it
> will just cause problems if the ACPI spec every actually covers the
> use cases of networking.
BTW, why would not we want to push for the unified binding? They are the
same pieces of hardware...
--
Dmitry
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 04/10] regulator: of: switch to using class_find_device_by_fwnode()
From: Dmitry Torokhov @ 2026-03-23 21:41 UTC (permalink / raw)
To: Mark Brown
Cc: Andrew Lunn, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Vinod Koul, Neil Armstrong,
Liam Girdwood, Lee Jones, Pavel Machek, Peter Rosin,
Heiner Kallweit, Russell King, Moritz Fischer, Xu Yilun, Tom Rix,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich, netdev,
linux-kernel, linux-phy, linux-spi, linux-leds, linux-fpga,
driver-core
In-Reply-To: <193e194a-498f-464f-b22c-c283c16db6c1@sirena.org.uk>
On Mon, Mar 23, 2026 at 09:36:07PM +0000, Mark Brown wrote:
> On Mon, Mar 23, 2026 at 09:01:47PM +0100, Andrew Lunn wrote:
>
> > How do you handle deprecated OF properties? This is a problem i've run
> > into before. A developer needs an ACPI binding, so they blindly
> > convert from of_ to device_ without engaging brain. As a result, they
> > bring all the deprecated OF properties we want to die into the brand
> > new ACPI bindings.
>
> Honestly that one hasn't really come up much for me - not too many
> deprecated properties.
Given that we position properties as an ABI even if they are deprecated
we supposed to handle them forever. Newer properties usually offer
benefits over old ones and that is how users get moved over.
Thanks.
--
Dmitry
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 04/10] regulator: of: switch to using class_find_device_by_fwnode()
From: Dmitry Torokhov @ 2026-03-23 21:39 UTC (permalink / raw)
To: Mark Brown
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Vinod Koul, Neil Armstrong, Liam Girdwood, Lee Jones,
Pavel Machek, Peter Rosin, Andrew Lunn, Heiner Kallweit,
Russell King, Moritz Fischer, Xu Yilun, Tom Rix,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich, netdev,
linux-kernel, linux-phy, linux-spi, linux-leds, linux-fpga,
driver-core
In-Reply-To: <55abcc68-747a-468a-abdf-b6340d658c4f@sirena.org.uk>
On Mon, Mar 23, 2026 at 07:58:14PM +0000, Mark Brown wrote:
> On Mon, Mar 23, 2026 at 12:41:59PM -0700, Dmitry Torokhov wrote:
> > On Mon, Mar 23, 2026 at 07:05:13PM +0000, Mark Brown wrote:
>
> > > I think this is a worrying idea for core code like this, we have
> > > specific firmware bindings for specific firmware interfaces with the
> > > different interfaces having very different ideas of how things should be
> > > modelled. The chances that firmware agnostic code is going to do the
> > > right thing seem low, and encouraging the use of generic APIs that might
> > > happen to run OK raises the risk that we'll get firmware vendors relying
> > > on them and leaving us with a conceptual mishmash to sort through.
>
> > Firmware vendors can introduce incompatible DT bindings and have them in
> > their devices too and we have to deal with that...
>
> The case that's worrying me is mixing the ACPI and DT design models in
> one system, and especially having that happen to actually work without
> modification purely by luck rather than by design.
>
> > I think if this pushes closer ACPI and OF schemas for at least some
> > subsystems closer to each other it would not be a bad thing.
>
> I think we shouldn't be encouraging people to just throw random stuff at
> the wall and see if it happens to run OK with whatever OS they tried
> booting. The differences between ACPI and DT in areas like the
> regulator bindings are fundamental conceptual ones. There's some areas
> where things are closer and it winds up being fine actually, especially
> for leaf devices, but there's others where that's less likely.
Maybe we should just have explicit checks with nice comments at the
beginning of the schema parsing stating that this schema is
intentionally restricted to OF (or ACPI) in cases where we ave distinct
schemas? This way it is explicit that it is a thought out decision and
not simply a legacy artefact.
I think we want to hanel software nodes because they do not
form their own schemas, they follow the existing ones (DT usually).
--
Dmitry
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 04/10] regulator: of: switch to using class_find_device_by_fwnode()
From: Mark Brown @ 2026-03-23 21:36 UTC (permalink / raw)
To: Andrew Lunn
Cc: Dmitry Torokhov, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Vinod Koul, Neil Armstrong,
Liam Girdwood, Lee Jones, Pavel Machek, Peter Rosin,
Heiner Kallweit, Russell King, Moritz Fischer, Xu Yilun, Tom Rix,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich, netdev,
linux-kernel, linux-phy, linux-spi, linux-leds, linux-fpga,
driver-core
In-Reply-To: <cf92122d-6b15-458a-bf89-189a0a6874f7@lunn.ch>
[-- Attachment #1.1: Type: text/plain, Size: 456 bytes --]
On Mon, Mar 23, 2026 at 09:01:47PM +0100, Andrew Lunn wrote:
> How do you handle deprecated OF properties? This is a problem i've run
> into before. A developer needs an ACPI binding, so they blindly
> convert from of_ to device_ without engaging brain. As a result, they
> bring all the deprecated OF properties we want to die into the brand
> new ACPI bindings.
Honestly that one hasn't really come up much for me - not too many
deprecated properties.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 112 bytes --]
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH net-next 07/10] net: phy: switch to using class_find_device_by_fwnode()
From: Andrew Lunn @ 2026-03-23 20:15 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: Dmitry Torokhov, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Vinod Koul, Neil Armstrong,
Mark Brown, Liam Girdwood, Lee Jones, Pavel Machek, Peter Rosin,
Heiner Kallweit, Moritz Fischer, Xu Yilun, Tom Rix,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich, netdev,
linux-kernel, linux-phy, linux-spi, linux-leds, linux-fpga,
driver-core
In-Reply-To: <acGI4PI3MHML9Pce@shell.armlinux.org.uk>
> This is not "foreign territory" - ACPI in general doesn't want to
> describe e.g. the individual components of a network card, unlike
> DT.
It has also been suggested that the MDIO bus should be added to the
ACPI specification as a first class bus, similar to I2C, SPI,
etc. This would make it different to the DT. So we don't want to
encourage developers to use the networking DT concepts in ACPI, it
will just cause problems if the ACPI spec every actually covers the
use cases of networking.
Andrew
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 04/10] regulator: of: switch to using class_find_device_by_fwnode()
From: Andrew Lunn @ 2026-03-23 20:01 UTC (permalink / raw)
To: Mark Brown
Cc: Dmitry Torokhov, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Vinod Koul, Neil Armstrong,
Liam Girdwood, Lee Jones, Pavel Machek, Peter Rosin,
Heiner Kallweit, Russell King, Moritz Fischer, Xu Yilun, Tom Rix,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich, netdev,
linux-kernel, linux-phy, linux-spi, linux-leds, linux-fpga,
driver-core
In-Reply-To: <7d46803e-b285-4e9c-8856-10100fa0ea85@sirena.org.uk>
On Mon, Mar 23, 2026 at 07:05:13PM +0000, Mark Brown wrote:
> On Mon, Mar 23, 2026 at 11:28:27AM -0700, Dmitry Torokhov wrote:
> > On Mon, Mar 23, 2026 at 02:00:43PM +0000, Mark Brown wrote:
>
> > > The regulator API is very deliberately specifically using the OF APIs,
> > > not the ACPI APIs, since ACPI really doesn't want to model regulators.
>
> > For now? We also have software nodes and maybe we come up with something
> > else in the future...
>
> > I think we should use firmware-agnostic APIs as much as possible, and
> > only use OF- or ACPI-specific ones when there is no generic equivalent.
> > This makes the code most flexible.
>
> I think this is a worrying idea for core code like this, we have
> specific firmware bindings for specific firmware interfaces with the
> different interfaces having very different ideas of how things should be
> modelled. The chances that firmware agnostic code is going to do the
> right thing seem low, and encouraging the use of generic APIs that might
> happen to run OK raises the risk that we'll get firmware vendors relying
> on them and leaving us with a conceptual mishmash to sort through.
How do you handle deprecated OF properties? This is a problem i've run
into before. A developer needs an ACPI binding, so they blindly
convert from of_ to device_ without engaging brain. As a result, they
bring all the deprecated OF properties we want to die into the brand
new ACPI bindings.
A agree with Mark here. OF != ACPI, and anything which makes it appear
they are the same is just going to lead developers down the wrong path
and increase Maintainers work pointing out all the problems.
Andrew
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v3 01/12] dt-bindings: phy: rockchip-usbdp: add improved ports scheme
From: Rob Herring (Arm) @ 2026-03-23 20:00 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Yubing Zhang, Heiko Stuebner, linux-arm-kernel, Neil Armstrong,
Conor Dooley, Alexey Charkov, linux-phy, linux-rockchip,
linux-kernel, Andy Yan, kernel, Krzysztof Kozlowski, devicetree,
Frank Wang, Dmitry Baryshkov, Vinod Koul
In-Reply-To: <20260313-rockchip-usbdp-cleanup-v3-1-3e8fe89a35b5@collabora.com>
On Fri, 13 Mar 2026 18:57:10 +0100, Sebastian Reichel wrote:
> Currently the Rockchip USBDP PHY is missing a documented port scheme.
> Meanwhile upstream RK3588 DTS files are a bit messy and use different
> port schemes. The upstream USBDP PHY Linux kernel driver does not yet
> parse the ports at all and thus does not create any implicit ABI either.
>
> But with the current mess it is not possible to properly support USB-C
> DP AltMode. Thus this introduces a proper port scheme following roughly
> the ports design of the Qualcomm QMP USB4-USB3-DP PHY controller binding
> with a slight difference that there is an additional port for the
> USB-C SBU port as the Rockchip USB-DP PHY also contains the SBU mux.
>
> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
> ---
> .../bindings/phy/phy-rockchip-usbdp.yaml | 23 ++++++++++++++++++++++
> 1 file changed, 23 insertions(+)
>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 04/10] regulator: of: switch to using class_find_device_by_fwnode()
From: Mark Brown @ 2026-03-23 19:58 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Vinod Koul, Neil Armstrong, Liam Girdwood, Lee Jones,
Pavel Machek, Peter Rosin, Andrew Lunn, Heiner Kallweit,
Russell King, Moritz Fischer, Xu Yilun, Tom Rix,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich, netdev,
linux-kernel, linux-phy, linux-spi, linux-leds, linux-fpga,
driver-core
In-Reply-To: <acGWJf1AGXT1xduM@google.com>
[-- Attachment #1.1: Type: text/plain, Size: 1545 bytes --]
On Mon, Mar 23, 2026 at 12:41:59PM -0700, Dmitry Torokhov wrote:
> On Mon, Mar 23, 2026 at 07:05:13PM +0000, Mark Brown wrote:
> > I think this is a worrying idea for core code like this, we have
> > specific firmware bindings for specific firmware interfaces with the
> > different interfaces having very different ideas of how things should be
> > modelled. The chances that firmware agnostic code is going to do the
> > right thing seem low, and encouraging the use of generic APIs that might
> > happen to run OK raises the risk that we'll get firmware vendors relying
> > on them and leaving us with a conceptual mishmash to sort through.
> Firmware vendors can introduce incompatible DT bindings and have them in
> their devices too and we have to deal with that...
The case that's worrying me is mixing the ACPI and DT design models in
one system, and especially having that happen to actually work without
modification purely by luck rather than by design.
> I think if this pushes closer ACPI and OF schemas for at least some
> subsystems closer to each other it would not be a bad thing.
I think we shouldn't be encouraging people to just throw random stuff at
the wall and see if it happens to run OK with whatever OS they tried
booting. The differences between ACPI and DT in areas like the
regulator bindings are fundamental conceptual ones. There's some areas
where things are closer and it winds up being fine actually, especially
for leaf devices, but there's others where that's less likely.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 112 bytes --]
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 04/10] regulator: of: switch to using class_find_device_by_fwnode()
From: Dmitry Torokhov @ 2026-03-23 19:41 UTC (permalink / raw)
To: Mark Brown
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Vinod Koul, Neil Armstrong, Liam Girdwood, Lee Jones,
Pavel Machek, Peter Rosin, Andrew Lunn, Heiner Kallweit,
Russell King, Moritz Fischer, Xu Yilun, Tom Rix,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich, netdev,
linux-kernel, linux-phy, linux-spi, linux-leds, linux-fpga,
driver-core
In-Reply-To: <7d46803e-b285-4e9c-8856-10100fa0ea85@sirena.org.uk>
On Mon, Mar 23, 2026 at 07:05:13PM +0000, Mark Brown wrote:
> On Mon, Mar 23, 2026 at 11:28:27AM -0700, Dmitry Torokhov wrote:
> > On Mon, Mar 23, 2026 at 02:00:43PM +0000, Mark Brown wrote:
>
> > > The regulator API is very deliberately specifically using the OF APIs,
> > > not the ACPI APIs, since ACPI really doesn't want to model regulators.
>
> > For now? We also have software nodes and maybe we come up with something
> > else in the future...
>
> > I think we should use firmware-agnostic APIs as much as possible, and
> > only use OF- or ACPI-specific ones when there is no generic equivalent.
> > This makes the code most flexible.
>
> I think this is a worrying idea for core code like this, we have
> specific firmware bindings for specific firmware interfaces with the
> different interfaces having very different ideas of how things should be
> modelled. The chances that firmware agnostic code is going to do the
> right thing seem low, and encouraging the use of generic APIs that might
> happen to run OK raises the risk that we'll get firmware vendors relying
> on them and leaving us with a conceptual mishmash to sort through.
>
> Software nodes are already a bit of a concern here TBH.
Firmware vendors can introduce incompatible DT bindings and have them in
their devices too and we have to deal with that...
I think if this pushes closer ACPI and OF schemas for at least some
subsystems closer to each other it would not be a bad thing.
Thanks.
--
Dmitry
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH net-next 07/10] net: phy: switch to using class_find_device_by_fwnode()
From: Dmitry Torokhov @ 2026-03-23 19:35 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: Andrew Lunn, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Vinod Koul, Neil Armstrong,
Mark Brown, Liam Girdwood, Lee Jones, Pavel Machek, Peter Rosin,
Heiner Kallweit, Moritz Fischer, Xu Yilun, Tom Rix,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich, netdev,
linux-kernel, linux-phy, linux-spi, linux-leds, linux-fpga,
driver-core
In-Reply-To: <acGI4PI3MHML9Pce@shell.armlinux.org.uk>
On Mon, Mar 23, 2026 at 06:39:28PM +0000, Russell King (Oracle) wrote:
> On Mon, Mar 23, 2026 at 11:33:36AM -0700, Dmitry Torokhov wrote:
> > On Mon, Mar 23, 2026 at 08:59:52AM +0000, Russell King (Oracle) wrote:
> > > On Sun, Mar 22, 2026 at 10:17:15PM -0700, Dmitry Torokhov wrote:
> > > > On Mon, Mar 23, 2026 at 03:54:09AM +0100, Andrew Lunn wrote:
> > > > > > - d = class_find_device_by_of_node(&mdio_bus_class, mdio_bus_np);
> > > > > > + d = class_find_device_by_fwnode(&mdio_bus_class,
> > > > > > + of_fwnode_handle(mdio_bus_np));
> > > > >
> > > > > When you look at this, why is it better?
> > > >
> > > > I think we should move as much as possible towards firmware-agnostic
> > > > APIs and use fwnode_handle instead of device_node or software_node or
> > > > ACPI companion. To discourage this I think we better remove
> > > > firmware-specific APIs where we have firmware-agnostic ones and
> > > > eventually clean up drivers that use OF- or ACPI-specific APIs.
> > >
> > > Basically, no. This is wrong.
> > >
> > > It may sound like a good goal, but there's an underlying issue. This
> > > goal assumes that the firmware description in OF and ACPI are
> > > indentical.
> >
> > If they are different then drivers will make allowance for this, like
> > I2C core or SPI core does. But most of the modern drivers use
> > firmware-agnostic APIs (device_property_*()).
>
> What is appropriate is up to the standards bodies responsible for
> the firmware. ACPI has a separate body, and we can't just dump
> the structure we use for networking into ACPI. So no, you can't
> just switch to firmware-agnostic APIs for networking.
So I believe there is a difference between deciding:
1. What schema is being used on a particular system - it may be
OF-compatible, or ACPI compatible one, and ACPI may support
OF-compatible schemes for certain subsystems or individual devices, and
2. What is the API to access the properties.
There is no harm to use device_property_read_*() universally as well as
not having OF-specific APIs at the driver core level. What matters is
schema matches the system type.
>
> For infrastructure where we lookup stuff by some kind of firmware
> node, I have no problem with converting that to fwnode APIs,
> because that doesn't transfer the DT description into other
> firmwares without prior agreement of the appropriate firmware
> standards bodies.
>
> This is not "foreign territory" - ACPI in general doesn't want to
> describe e.g. the individual components of a network card, unlike
> DT.
I think we actually broadly agree? What you are arguing against is
saying that OF schema is guaranteed to work on ACPI systems and vice
versa, but I am not saying that (although for some things it may). But
still most OF schema can be handled by generic APIs (either
device_property_read_*() or fwnode ones).
Thanks.
--
Dmitry
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 04/10] regulator: of: switch to using class_find_device_by_fwnode()
From: Mark Brown @ 2026-03-23 19:05 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Vinod Koul, Neil Armstrong, Liam Girdwood, Lee Jones,
Pavel Machek, Peter Rosin, Andrew Lunn, Heiner Kallweit,
Russell King, Moritz Fischer, Xu Yilun, Tom Rix,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich, netdev,
linux-kernel, linux-phy, linux-spi, linux-leds, linux-fpga,
driver-core
In-Reply-To: <acGFksyx3SA0kJ5b@google.com>
[-- Attachment #1.1: Type: text/plain, Size: 1110 bytes --]
On Mon, Mar 23, 2026 at 11:28:27AM -0700, Dmitry Torokhov wrote:
> On Mon, Mar 23, 2026 at 02:00:43PM +0000, Mark Brown wrote:
> > The regulator API is very deliberately specifically using the OF APIs,
> > not the ACPI APIs, since ACPI really doesn't want to model regulators.
> For now? We also have software nodes and maybe we come up with something
> else in the future...
> I think we should use firmware-agnostic APIs as much as possible, and
> only use OF- or ACPI-specific ones when there is no generic equivalent.
> This makes the code most flexible.
I think this is a worrying idea for core code like this, we have
specific firmware bindings for specific firmware interfaces with the
different interfaces having very different ideas of how things should be
modelled. The chances that firmware agnostic code is going to do the
right thing seem low, and encouraging the use of generic APIs that might
happen to run OK raises the risk that we'll get firmware vendors relying
on them and leaving us with a conceptual mishmash to sort through.
Software nodes are already a bit of a concern here TBH.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 112 bytes --]
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH net-next 07/10] net: phy: switch to using class_find_device_by_fwnode()
From: Russell King (Oracle) @ 2026-03-23 18:39 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Andrew Lunn, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Vinod Koul, Neil Armstrong,
Mark Brown, Liam Girdwood, Lee Jones, Pavel Machek, Peter Rosin,
Heiner Kallweit, Moritz Fischer, Xu Yilun, Tom Rix,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich, netdev,
linux-kernel, linux-phy, linux-spi, linux-leds, linux-fpga,
driver-core
In-Reply-To: <acGGWTmSMuc5h3Od@google.com>
On Mon, Mar 23, 2026 at 11:33:36AM -0700, Dmitry Torokhov wrote:
> On Mon, Mar 23, 2026 at 08:59:52AM +0000, Russell King (Oracle) wrote:
> > On Sun, Mar 22, 2026 at 10:17:15PM -0700, Dmitry Torokhov wrote:
> > > On Mon, Mar 23, 2026 at 03:54:09AM +0100, Andrew Lunn wrote:
> > > > > - d = class_find_device_by_of_node(&mdio_bus_class, mdio_bus_np);
> > > > > + d = class_find_device_by_fwnode(&mdio_bus_class,
> > > > > + of_fwnode_handle(mdio_bus_np));
> > > >
> > > > When you look at this, why is it better?
> > >
> > > I think we should move as much as possible towards firmware-agnostic
> > > APIs and use fwnode_handle instead of device_node or software_node or
> > > ACPI companion. To discourage this I think we better remove
> > > firmware-specific APIs where we have firmware-agnostic ones and
> > > eventually clean up drivers that use OF- or ACPI-specific APIs.
> >
> > Basically, no. This is wrong.
> >
> > It may sound like a good goal, but there's an underlying issue. This
> > goal assumes that the firmware description in OF and ACPI are
> > indentical.
>
> If they are different then drivers will make allowance for this, like
> I2C core or SPI core does. But most of the modern drivers use
> firmware-agnostic APIs (device_property_*()).
What is appropriate is up to the standards bodies responsible for
the firmware. ACPI has a separate body, and we can't just dump
the structure we use for networking into ACPI. So no, you can't
just switch to firmware-agnostic APIs for networking.
For infrastructure where we lookup stuff by some kind of firmware
node, I have no problem with converting that to fwnode APIs,
because that doesn't transfer the DT description into other
firmwares without prior agreement of the appropriate firmware
standards bodies.
This is not "foreign territory" - ACPI in general doesn't want to
describe e.g. the individual components of a network card, unlike
DT.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH net-next 07/10] net: phy: switch to using class_find_device_by_fwnode()
From: Dmitry Torokhov @ 2026-03-23 18:33 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: Andrew Lunn, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Vinod Koul, Neil Armstrong,
Mark Brown, Liam Girdwood, Lee Jones, Pavel Machek, Peter Rosin,
Heiner Kallweit, Moritz Fischer, Xu Yilun, Tom Rix,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich, netdev,
linux-kernel, linux-phy, linux-spi, linux-leds, linux-fpga,
driver-core
In-Reply-To: <acEBCBgMV3RrGKiU@shell.armlinux.org.uk>
On Mon, Mar 23, 2026 at 08:59:52AM +0000, Russell King (Oracle) wrote:
> On Sun, Mar 22, 2026 at 10:17:15PM -0700, Dmitry Torokhov wrote:
> > On Mon, Mar 23, 2026 at 03:54:09AM +0100, Andrew Lunn wrote:
> > > > - d = class_find_device_by_of_node(&mdio_bus_class, mdio_bus_np);
> > > > + d = class_find_device_by_fwnode(&mdio_bus_class,
> > > > + of_fwnode_handle(mdio_bus_np));
> > >
> > > When you look at this, why is it better?
> >
> > I think we should move as much as possible towards firmware-agnostic
> > APIs and use fwnode_handle instead of device_node or software_node or
> > ACPI companion. To discourage this I think we better remove
> > firmware-specific APIs where we have firmware-agnostic ones and
> > eventually clean up drivers that use OF- or ACPI-specific APIs.
>
> Basically, no. This is wrong.
>
> It may sound like a good goal, but there's an underlying issue. This
> goal assumes that the firmware description in OF and ACPI are
> indentical.
If they are different then drivers will make allowance for this, like
I2C core or SPI core does. But most of the modern drivers use
firmware-agnostic APIs (device_property_*()).
ACPI has allowance for device tree properties (via PRP0001 HID
entries), and drivers should work with them.
>
> Sure, looking up devices by fwnode handle makes sense, but looking up
> anything that is described in firmware is not suitable for this kind
> of conversion, because in doing so, you effectively "port" the DT
> bindings to ACPI, and it may not be suitable for ACPI.
>
> So, please don't make wholesale changes that transfer the DT bindings
> into ACPI.
>
I am not "transferring" anything, but I want to make sure the code works
even if we augment OF with software nodes or if DT properties are used
in ACPI.
Thanks.
--
Dmitry
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 04/10] regulator: of: switch to using class_find_device_by_fwnode()
From: Dmitry Torokhov @ 2026-03-23 18:28 UTC (permalink / raw)
To: Mark Brown
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Vinod Koul, Neil Armstrong, Liam Girdwood, Lee Jones,
Pavel Machek, Peter Rosin, Andrew Lunn, Heiner Kallweit,
Russell King, Moritz Fischer, Xu Yilun, Tom Rix,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich, netdev,
linux-kernel, linux-phy, linux-spi, linux-leds, linux-fpga,
driver-core
In-Reply-To: <360a8b4a-6507-417a-9fc1-c53b14868657@sirena.org.uk>
On Mon, Mar 23, 2026 at 02:00:43PM +0000, Mark Brown wrote:
> On Sun, Mar 22, 2026 at 06:54:22PM -0700, Dmitry Torokhov wrote:
> > In preparation to class_find_device_by_of_node() going away switch to
> > using class_find_device_by_fwnode().
>
> > struct device *dev;
> >
> > - dev = class_find_device_by_of_node(®ulator_class, np);
> > + dev = class_find_device_by_fwnode(®ulator_class, of_fwnode_handle(np));
>
> The regulator API is very deliberately specifically using the OF APIs,
> not the ACPI APIs, since ACPI really doesn't want to model regulators.
For now? We also have software nodes and maybe we come up with something
else in the future...
I think we should use firmware-agnostic APIs as much as possible, and
only use OF- or ACPI-specific ones when there is no generic equivalent.
This makes the code most flexible.
Anyway, I am not proposing to change all of the regulator code, just
clean up driver core APIs.
Thanks.
--
Dmitry
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 03/10] spi: switch to using class_find_device_by_fwnode()
From: Dmitry Torokhov @ 2026-03-23 18:25 UTC (permalink / raw)
To: Mark Brown
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Vinod Koul, Neil Armstrong, Liam Girdwood, Lee Jones,
Pavel Machek, Peter Rosin, Andrew Lunn, Heiner Kallweit,
Russell King, Moritz Fischer, Xu Yilun, Tom Rix,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich, netdev,
linux-kernel, linux-phy, linux-spi, linux-leds, linux-fpga,
driver-core
In-Reply-To: <098e1856-feee-4f4b-8059-85a53967f6b3@sirena.org.uk>
On Mon, Mar 23, 2026 at 05:16:04PM +0000, Mark Brown wrote:
> On Sun, Mar 22, 2026 at 06:54:21PM -0700, Dmitry Torokhov wrote:
> > In preparation to class_find_device_by_of_node() going away switch to
> > using class_find_device_by_fwnode().
>
> > struct spi_controller *of_find_spi_controller_by_node(struct device_node *node)
> > {
> > + struct fwnode_handle *fwnode = of_fwnode_handle(node);
> > struct device *dev;
> >
> > - dev = class_find_device_by_of_node(&spi_controller_class, node);
> > + dev = class_find_device_by_fwnode(&spi_controller_class, fwnode);
> > if (!dev && IS_ENABLED(CONFIG_SPI_SLAVE))
> > - dev = class_find_device_by_of_node(&spi_target_class, node);
> > + dev = class_find_device_by_fwnode(&spi_target_class, fwnode);
> > if (!dev)
> > return NULL;
>
> Actually, no - this just looks weird. We're in the middle of an OF
> specific function but we're having to jump up to fwnode for no apparent
> reason. If we actually decide to get rid of the OF specific function
> then I guess but I'm really not convinced this is an improvement in
> isolation.
Yes, I want to remove OF-specific APIs from the driver core. I also have
drafts for bus_find_device_by_fwnode and others.
I can make a followup series introducing spi_find_controller_by_fwnode()
and removing this OF-specific variant.
Thanks.
--
Dmitry
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox