* [PATCH] phy: move spacemit pcie driver to its subfolder
From: Vinod Koul @ 2026-02-23 6:42 UTC (permalink / raw)
To: linux-phy
Cc: Neil Armstrong, Vladimir Oltean, Vinod Koul, Alex Elder, Ze Huang,
spacemit
Commit fe4bc1a08638 ("phy: spacemit: support K1 USB2.0 PHY controller")
created spacemit subfolder with usb driver while commit 57e920b92724
("phy: spacemit: Introduce PCIe/combo PHY") added pcie driver in phy
folder. Move latter into spacemit subfolder and rename file to
phy-k1-pcie.c
Signed-off-by: Vinod Koul <vkoul@kernel.org>
---
drivers/phy/Kconfig | 12 ------------
drivers/phy/Makefile | 1 -
drivers/phy/spacemit/Kconfig | 12 ++++++++++++
drivers/phy/spacemit/Makefile | 1 +
.../phy-k1-pcie.c} | 0
5 files changed, 13 insertions(+), 13 deletions(-)
rename drivers/phy/{phy-spacemit-k1-pcie.c => spacemit/phy-k1-pcie.c} (100%)
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 02467dfd4fb0..c0574e44f0a3 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -134,18 +134,6 @@ config PHY_NXP_PTN3222
schemes. It supports all three USB 2.0 data rates: Low Speed, Full
Speed and High Speed.
-config PHY_SPACEMIT_K1_PCIE
- tristate "PCIe and combo PHY driver for the SpacemiT K1 SoC"
- depends on ARCH_SPACEMIT || COMPILE_TEST
- depends on COMMON_CLK
- depends on HAS_IOMEM
- depends on OF
- select GENERIC_PHY
- default ARCH_SPACEMIT
- help
- Enable support for the PCIe and USB 3 combo PHY and two
- PCIe-only PHYs used in the SpacemiT K1 SoC.
-
source "drivers/phy/allwinner/Kconfig"
source "drivers/phy/amlogic/Kconfig"
source "drivers/phy/apple/Kconfig"
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index a648c2e02a83..2773d596e543 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -16,7 +16,6 @@ obj-$(CONFIG_PHY_SNPS_EUSB2) += phy-snps-eusb2.o
obj-$(CONFIG_USB_LGM_PHY) += phy-lgm-usb.o
obj-$(CONFIG_PHY_AIROHA_PCIE) += phy-airoha-pcie.o
obj-$(CONFIG_PHY_NXP_PTN3222) += phy-nxp-ptn3222.o
-obj-$(CONFIG_PHY_SPACEMIT_K1_PCIE) += phy-spacemit-k1-pcie.o
obj-$(CONFIG_GENERIC_PHY) += allwinner/ \
amlogic/ \
apple/ \
diff --git a/drivers/phy/spacemit/Kconfig b/drivers/phy/spacemit/Kconfig
index 0136aee2e8a2..50b0005acf66 100644
--- a/drivers/phy/spacemit/Kconfig
+++ b/drivers/phy/spacemit/Kconfig
@@ -2,6 +2,18 @@
#
# Phy drivers for SpacemiT platforms
#
+config PHY_SPACEMIT_K1_PCIE
+ tristate "PCIe and combo PHY driver for the SpacemiT K1 SoC"
+ depends on ARCH_SPACEMIT || COMPILE_TEST
+ depends on COMMON_CLK
+ depends on HAS_IOMEM
+ depends on OF
+ select GENERIC_PHY
+ default ARCH_SPACEMIT
+ help
+ Enable support for the PCIe and USB 3 combo PHY and two
+ PCIe-only PHYs used in the SpacemiT K1 SoC.
+
config PHY_SPACEMIT_K1_USB2
tristate "SpacemiT K1 USB 2.0 PHY support"
depends on (ARCH_SPACEMIT || COMPILE_TEST) && OF
diff --git a/drivers/phy/spacemit/Makefile b/drivers/phy/spacemit/Makefile
index fec0b425a948..a821a21d6142 100644
--- a/drivers/phy/spacemit/Makefile
+++ b/drivers/phy/spacemit/Makefile
@@ -1,2 +1,3 @@
# SPDX-License-Identifier: GPL-2.0-only
+obj-$(CONFIG_PHY_SPACEMIT_K1_PCIE) += phy-k1-pcie.o
obj-$(CONFIG_PHY_SPACEMIT_K1_USB2) += phy-k1-usb2.o
diff --git a/drivers/phy/phy-spacemit-k1-pcie.c b/drivers/phy/spacemit/phy-k1-pcie.c
similarity index 100%
rename from drivers/phy/phy-spacemit-k1-pcie.c
rename to drivers/phy/spacemit/phy-k1-pcie.c
--
2.43.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH] phy: Sort the subsystem Makefile
From: Vinod Koul @ 2026-02-23 6:57 UTC (permalink / raw)
To: linux-phy; +Cc: Neil Armstrong, Vladimir Oltean, Vinod Koul
Makefile is supposed to be sorted alphabetically, sadly it has bitrotted
so fix that
Signed-off-by: Vinod Koul <vkoul@kernel.org>
---
drivers/phy/Makefile | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 2773d596e543..90cad2b72cfa 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -7,15 +7,16 @@ obj-$(CONFIG_PHY_COMMON_PROPS) += phy-common-props.o
obj-$(CONFIG_PHY_COMMON_PROPS_TEST) += phy-common-props-test.o
obj-$(CONFIG_GENERIC_PHY) += phy-core.o
obj-$(CONFIG_GENERIC_PHY_MIPI_DPHY) += phy-core-mipi-dphy.o
+obj-$(CONFIG_PHY_AIROHA_PCIE) += phy-airoha-pcie.o
obj-$(CONFIG_PHY_CAN_TRANSCEIVER) += phy-can-transceiver.o
obj-$(CONFIG_PHY_GOOGLE_USB) += phy-google-usb.o
+obj-$(CONFIG_USB_LGM_PHY) += phy-lgm-usb.o
obj-$(CONFIG_PHY_LPC18XX_USB_OTG) += phy-lpc18xx-usb-otg.o
-obj-$(CONFIG_PHY_XGENE) += phy-xgene.o
+obj-$(CONFIG_PHY_NXP_PTN3222) += phy-nxp-ptn3222.o
obj-$(CONFIG_PHY_PISTACHIO_USB) += phy-pistachio-usb.o
obj-$(CONFIG_PHY_SNPS_EUSB2) += phy-snps-eusb2.o
-obj-$(CONFIG_USB_LGM_PHY) += phy-lgm-usb.o
-obj-$(CONFIG_PHY_AIROHA_PCIE) += phy-airoha-pcie.o
-obj-$(CONFIG_PHY_NXP_PTN3222) += phy-nxp-ptn3222.o
+obj-$(CONFIG_PHY_XGENE) += phy-xgene.o
+
obj-$(CONFIG_GENERIC_PHY) += allwinner/ \
amlogic/ \
apple/ \
--
2.43.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH] phy: Sort the subsystem Kconfig
From: Vinod Koul @ 2026-02-23 6:58 UTC (permalink / raw)
To: linux-phy; +Cc: Neil Armstrong, Vladimir Oltean, Vinod Koul
Kconfig is supposed to be sorted alphabetically, sadly it has bitrotted
so fix that
Signed-off-by: Vinod Koul <vkoul@kernel.org>
---
drivers/phy/Kconfig | 88 ++++++++++++++++++++++-----------------------
1 file changed, 44 insertions(+), 44 deletions(-)
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index c0574e44f0a3..a00266c8256b 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -47,6 +47,26 @@ config GENERIC_PHY_MIPI_DPHY
Provides a number of helpers a core functions for MIPI D-PHY
drivers to us.
+config PHY_AIROHA_PCIE
+ tristate "Airoha PCIe-PHY Driver"
+ depends on ARCH_AIROHA || COMPILE_TEST
+ depends on OF
+ select GENERIC_PHY
+ help
+ Say Y here to add support for Airoha PCIe PHY driver.
+ This driver create the basic PHY instance and provides initialize
+ callback for PCIe GEN3 port.
+
+config PHY_CAN_TRANSCEIVER
+ tristate "CAN transceiver PHY"
+ select GENERIC_PHY
+ select MULTIPLEXER
+ help
+ This option enables support for CAN transceivers as a PHY. This
+ driver provides function for putting the transceivers in various
+ functional modes using gpios and sets the attribute max link
+ rate, for CAN drivers.
+
config PHY_GOOGLE_USB
tristate "Google Tensor SoC USB PHY driver"
select GENERIC_PHY
@@ -58,6 +78,18 @@ config PHY_GOOGLE_USB
both of which are integrated with the DWC3 USB DRD controller.
This driver currently supports USB high-speed.
+config USB_LGM_PHY
+ tristate "INTEL Lightning Mountain USB PHY Driver"
+ depends on USB_SUPPORT
+ depends on X86 || COMPILE_TEST
+ select USB_PHY
+ select REGULATOR
+ select REGULATOR_FIXED_VOLTAGE
+ help
+ Enable this to support Intel DWC3 PHY USB phy. This driver provides
+ interface to interact with USB GEN-II and USB 3.x PHY that is part
+ of the Intel network SOC.
+
config PHY_LPC18XX_USB_OTG
tristate "NXP LPC18xx/43xx SoC USB OTG PHY driver"
depends on OF && (ARCH_LPC18XX || COMPILE_TEST)
@@ -69,6 +101,17 @@ config PHY_LPC18XX_USB_OTG
This driver is need for USB0 support on LPC18xx/43xx and takes
care of enabling and clock setup.
+config PHY_NXP_PTN3222
+ tristate "NXP PTN3222 1-port eUSB2 to USB2 redriver"
+ depends on I2C
+ depends on OF
+ select GENERIC_PHY
+ help
+ Enable this to support NXP PTN3222 1-port eUSB2 to USB2 Redriver.
+ This redriver performs translation between eUSB2 and USB2 signalling
+ schemes. It supports all three USB 2.0 data rates: Low Speed, Full
+ Speed and High Speed.
+
config PHY_PISTACHIO_USB
tristate "IMG Pistachio USB2.0 PHY driver"
depends on MIPS || COMPILE_TEST
@@ -91,49 +134,6 @@ config PHY_XGENE
help
This option enables support for APM X-Gene SoC multi-purpose PHY.
-config USB_LGM_PHY
- tristate "INTEL Lightning Mountain USB PHY Driver"
- depends on USB_SUPPORT
- depends on X86 || COMPILE_TEST
- select USB_PHY
- select REGULATOR
- select REGULATOR_FIXED_VOLTAGE
- help
- Enable this to support Intel DWC3 PHY USB phy. This driver provides
- interface to interact with USB GEN-II and USB 3.x PHY that is part
- of the Intel network SOC.
-
-config PHY_CAN_TRANSCEIVER
- tristate "CAN transceiver PHY"
- select GENERIC_PHY
- select MULTIPLEXER
- help
- This option enables support for CAN transceivers as a PHY. This
- driver provides function for putting the transceivers in various
- functional modes using gpios and sets the attribute max link
- rate, for CAN drivers.
-
-config PHY_AIROHA_PCIE
- tristate "Airoha PCIe-PHY Driver"
- depends on ARCH_AIROHA || COMPILE_TEST
- depends on OF
- select GENERIC_PHY
- help
- Say Y here to add support for Airoha PCIe PHY driver.
- This driver create the basic PHY instance and provides initialize
- callback for PCIe GEN3 port.
-
-config PHY_NXP_PTN3222
- tristate "NXP PTN3222 1-port eUSB2 to USB2 redriver"
- depends on I2C
- depends on OF
- select GENERIC_PHY
- help
- Enable this to support NXP PTN3222 1-port eUSB2 to USB2 Redriver.
- This redriver performs translation between eUSB2 and USB2 signalling
- schemes. It supports all three USB 2.0 data rates: Low Speed, Full
- Speed and High Speed.
-
source "drivers/phy/allwinner/Kconfig"
source "drivers/phy/amlogic/Kconfig"
source "drivers/phy/apple/Kconfig"
@@ -142,6 +142,7 @@ source "drivers/phy/cadence/Kconfig"
source "drivers/phy/freescale/Kconfig"
source "drivers/phy/hisilicon/Kconfig"
source "drivers/phy/ingenic/Kconfig"
+source "drivers/phy/intel/Kconfig"
source "drivers/phy/lantiq/Kconfig"
source "drivers/phy/marvell/Kconfig"
source "drivers/phy/mediatek/Kconfig"
@@ -163,7 +164,6 @@ source "drivers/phy/starfive/Kconfig"
source "drivers/phy/sunplus/Kconfig"
source "drivers/phy/tegra/Kconfig"
source "drivers/phy/ti/Kconfig"
-source "drivers/phy/intel/Kconfig"
source "drivers/phy/xilinx/Kconfig"
endmenu
--
2.43.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH] phy: phy-mtk-tphy: Update names and format of kernel-doc comments
From: Vinod Koul @ 2026-02-23 7:10 UTC (permalink / raw)
To: linux-phy; +Cc: Neil Armstrong, Vladimir Oltean, Vinod Koul, chunfeng.yun
mtk_phy_pdata documentation does not use correct tag for struct, while at
it fix one of member wrongly documented.
Warning: drivers/phy/mediatek/phy-mtk-tphy.c:289 cannot understand function prototype: 'struct mtk_phy_pdata'
Warning: drivers/phy/mediatek/phy-mtk-tphy.c:296 struct member 'slew_ref_clock_mhz' not described in 'mtk_phy_pdata'
Signed-off-by: Vinod Koul <vkoul@kernel.org>
---
drivers/phy/mediatek/phy-mtk-tphy.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/phy/mediatek/phy-mtk-tphy.c b/drivers/phy/mediatek/phy-mtk-tphy.c
index f6504e0ecd1a..acf506529507 100644
--- a/drivers/phy/mediatek/phy-mtk-tphy.c
+++ b/drivers/phy/mediatek/phy-mtk-tphy.c
@@ -276,14 +276,14 @@ enum mtk_phy_version {
};
/**
- * mtk_phy_pdata - SoC specific platform data
+ * struct mtk_phy_pdata - SoC specific platform data
* @avoid_rx_sen_degradation: Avoid TX Sensitivity level degradation (MT6795/8173 only)
* @sw_pll_48m_to_26m: Workaround for V3 IP (MT8195) - switch the 48MHz PLL from
* fractional mode to integer to output 26MHz for U2PHY
* @sw_efuse_supported: Switches off eFuse auto-load from PHY and applies values
* read from different nvmem (usually different eFuse array)
* that is pointed at in the device tree node for this PHY
- * @slew_ref_clk_mhz: Default reference clock (in MHz) for slew rate calibration
+ * @slew_ref_clock_mhz: Default reference clock (in MHz) for slew rate calibration
* @slew_rate_coefficient: Coefficient for slew rate calibration
* @version: PHY IP Version
*/
--
2.43.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v3] dt-bindings: phy: qcom,sc8280xp-qmp-ufs-phy: document the Eliza QMP UFS PHY
From: Abel Vesa @ 2026-02-23 8:19 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Nitin Rawat, Konrad Dybcio, linux-arm-msm, linux-phy, devicetree,
linux-kernel, Krzysztof Kozlowski, Abel Vesa
Document the QMP UFS PHY compatible for the Eliza Platform. It is fully
compatible with the PHY implemented in SM8650, so use the SM8650
compatible as fallback.
While at it, move the QCS8300 one so that it is sorted correctly by
fallback compatible.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
---
Changes in v3:
- Fix commit message by dropping extra "the" word from last sentence.
- Picked up Krzysztof's R-b tag.
- Link to v2: https://patch.msgid.link/20260220-eliza-bindings-phy-ufs-v2-1-4910bdcc585a@oss.qualcomm.com
Changes in v2:
- Fixed the order by moving it below X1E80100 so that the fallback
compatibles would be sorted, like Krzysztof suggested.
- While at it, moved the QCS8300 in first, so the sorting of all fallback
compatibles will be complete all the way.
- Picked up Konrad's R-b tag.
- Link to v1: https://patch.msgid.link/20260219-eliza-bindings-phy-ufs-v1-1-1635e7b53049@oss.qualcomm.com
---
.../devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml
index a1731b08c9d1..9616c736b6d4 100644
--- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml
@@ -16,6 +16,10 @@ description:
properties:
compatible:
oneOf:
+ - items:
+ - enum:
+ - qcom,qcs8300-qmp-ufs-phy
+ - const: qcom,sa8775p-qmp-ufs-phy
- items:
- enum:
- qcom,qcs615-qmp-ufs-phy
@@ -26,8 +30,8 @@ properties:
- const: qcom,sm8550-qmp-ufs-phy
- items:
- enum:
- - qcom,qcs8300-qmp-ufs-phy
- - const: qcom,sa8775p-qmp-ufs-phy
+ - qcom,eliza-qmp-ufs-phy
+ - const: qcom,sm8650-qmp-ufs-phy
- items:
- enum:
- qcom,kaanapali-qmp-ufs-phy
---
base-commit: 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f
change-id: 20260219-eliza-bindings-phy-ufs-3d95c2377aeb
Best regards,
--
Abel Vesa <abel.vesa@oss.qualcomm.com>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* Re: [PATCH RFC net-next+ 4/9] net: stmmac: qcom-ethqos: convert to use phy_set_mode_ext()
From: Mohd Ayaan Anwar @ 2026-02-23 9:44 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: Andrew Lunn, Alexandre Torgue, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, linux-arm-kernel, linux-arm-msm,
linux-phy, linux-stm32, Neil Armstrong, netdev, Paolo Abeni,
Vinod Koul
In-Reply-To: <E1vt3US-0000000A5eE-1RHM@rmk-PC.armlinux.org.uk>
Hi Russell,
On Thu, Feb 19, 2026 at 12:50:44PM +0000, Russell King (Oracle) wrote:
> @@ -675,20 +676,16 @@ static int ethqos_mac_finish_serdes(struct net_device *ndev, void *priv,
> phy_interface_t interface)
> {
> struct qcom_ethqos *ethqos = priv;
> - int speed, ret = 0;
> + int ret = 0;
>
> qcom_ethqos_set_sgmii_loopback(ethqos, false);
>
> - speed = SPEED_UNKNOWN;
> - if (interface == PHY_INTERFACE_MODE_SGMII)
> - speed = SPEED_1000;
> - else if (interface == PHY_INTERFACE_MODE_2500BASEX)
> - speed = SPEED_2500;
> -
> - if (speed != SPEED_UNKNOWN && speed != ethqos->serdes_speed) {
> - ret = phy_set_speed(ethqos->serdes_phy, speed);
> + if (interface == PHY_INTERFACE_MODE_SGMII ||
> + interface == PHY_INTERFACE_MODE_2500BASEX) {
> + ret = phy_set_mode(ethqos->serdes_phy, PHY_MODE_ETHERNET,
> + interface);
Shouldn't this be phy_set_mode_ext()?
Ayaan
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH RFC net-next+previous 0/9] net: stmmac: qcom-ethqos: further updates
From: Mohd Ayaan Anwar @ 2026-02-23 9:49 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: Andrew Lunn, Alexandre Torgue, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, linux-arm-kernel, linux-arm-msm,
linux-phy, linux-stm32, Neil Armstrong, netdev, Paolo Abeni,
Vinod Koul
In-Reply-To: <aZcGxDBwfMXHbo_O@shell.armlinux.org.uk>
On Thu, Feb 19, 2026 at 12:49:08PM +0000, Russell King (Oracle) wrote:
> This is part 2 of the qcom-ethqos series, building on the previous
> series which can be found at
> https://lore.kernel.org/r/aY0aJppQWUC52OUq@shell.armlinux.org.uk
>
> This part of the series focuses on the generic PHY driver, but these
> changes have dependencies on the ethernet driver, hence why
> it will need to go via net-next. Furthermore, subsequent changes
> depend on these patches.
>
> The underlying ideas here are:
>
> - get rid of the driver using phy_set_speed() with SPEED_1000 and
> SPEED_2500 which makes no sense for an ethernet SerDes due to the
> PCS 8B10B data encoding, which inflates the data rate at the SerDes
> compared to the MAC.
> - allow phy_power_on() / phy_set_mode*() to be called in any order.
>
> I've included the set_clk_tx_rate() patch as that was tested, which
> would make applying this series awkward to apply without it.
>
> Mohd, please could you test this series - I'm hoping it will pass with
> flying colours as there should be no change to the order in which we
> program the hardware. Thanks.
>
> .../ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c | 52 +++++++-----------
> drivers/phy/qualcomm/phy-qcom-sgmii-eth.c | 62 +++++++++++++++++-----
> 2 files changed, 68 insertions(+), 46 deletions(-)
>
After changing phy_set_mode() to phy_set_mode_ext() in
dwmac-qcom-ethqos.c, no issues found on:
- QCS9100 Ride R3 (AQR115C PHY, 2500BASE-X) - 2.5G/1G/100M
- IQ9 EVK (QCA8081 PHY, 2500BASE-X) - 2.5G
Tested-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
Ayaan
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH RFC net-next+ 2/9] net: stmmac: qcom-ethqos: move ethqos_set_serdes_speed()
From: Mohd Ayaan Anwar @ 2026-02-23 9:52 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: Andrew Lunn, Alexandre Torgue, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, linux-arm-kernel, linux-arm-msm,
linux-phy, linux-stm32, Neil Armstrong, netdev, Paolo Abeni,
Vinod Koul
In-Reply-To: <E1vt3UI-0000000A5e2-0Im5@rmk-PC.armlinux.org.uk>
On Thu, Feb 19, 2026 at 12:50:34PM +0000, Russell King (Oracle) wrote:
> Combine ethqos_set_serdes_speed() with ethqos_mac_finish_serdes() to
> simplify the code.
>
> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
> ---
> .../stmicro/stmmac/dwmac-qcom-ethqos.c | 22 +++++++++----------
> 1 file changed, 11 insertions(+), 11 deletions(-)
>
Reviewed-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
Ayaan
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH RFC net-next+ 9/9] net: stmmac: qcom-ethqos: remove phy_set_mode_ext() after phy_power_on()
From: Mohd Ayaan Anwar @ 2026-02-23 9:54 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: Andrew Lunn, Alexandre Torgue, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, linux-arm-kernel, linux-arm-msm,
linux-phy, linux-stm32, Neil Armstrong, netdev, Paolo Abeni,
Vinod Koul
In-Reply-To: <E1vt3Us-0000000A5ei-04Bg@rmk-PC.armlinux.org.uk>
On Thu, Feb 19, 2026 at 12:51:10PM +0000, Russell King (Oracle) wrote:
> The call to phy_set_mode_ext() after phy_power_on() was a work-around
> for the qcom-sgmii-eth SerDes driver that only re-enabled its clocks on
> phy_power_on() but did not configure the PHY. Now that the SerDes driver
> fully configures the SerDes at phy_power_on(), there is no need to call
> phy_set_mode_ext() immediately afterwards.
>
> This also means we no longer need to record the previous operating mode
> of the driver - this is up to the SerDes driver. In any case, the only
> thing that we care about is the SerDes provides the necessary clocks to
> the stmmac core to allow it to reset at this point. The actual mode is
> irrelevant at this point as the correct mode will be configured in
> ethqos_mac_finish_serdes() just before the network device is brought
> online.
>
> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
> ---
> .../stmicro/stmmac/dwmac-qcom-ethqos.c | 18 ++----------------
> 1 file changed, 2 insertions(+), 16 deletions(-)
>
Reviewed-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
Ayaan
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v9 1/7] phy: can-transceiver: rename temporary helper function to avoid conflict
From: Josua Mayer @ 2026-02-23 12:43 UTC (permalink / raw)
To: Andreas Kemnade, Vladimir Oltean
Cc: Geert Uytterhoeven, Marc Kleine-Budde, Vincent Mailhol,
Vinod Koul, Neil Armstrong, Peter Rosin, Aaro Koskinen,
Kevin Hilman, Roger Quadros, Tony Lindgren, Janusz Krzysztofik,
Vignesh R, Andi Shyti, Ulf Hansson, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, Wolfram Sang, Yazan Shhady, Jon Nettleton,
Mikhail Anikin, linux-can@vger.kernel.org,
linux-phy@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-omap@vger.kernel.org, linux-i2c@vger.kernel.org,
linux-mmc@vger.kernel.org, devicetree@vger.kernel.org,
linux-renesas-soc@vger.kernel.org
In-Reply-To: <20260216162406.0121dd91@kemnade.info>
Am 16.02.26 um 16:24 schrieb Andreas Kemnade:
> On Mon, 16 Feb 2026 11:29:14 +0200
> Vladimir Oltean <olteanv@gmail.com> wrote:
>
>> Hi Josua,
>>
>> On Mon, Feb 16, 2026 at 08:19:27AM +0000, Josua Mayer wrote:
>>>>> In the future, when you have a series with cross-tree dependencies,
>>>>> please try to think of it as individual mini-series for each tree's
>>>>> 'next' branch, and specify clearly that you need stable tags (to be
>>>>> pulled into other trees).
>>> I don't really understand how I could split my series up to avoid this
>>> issue.
>>>
>>> Due to the fact that one (and now two) drivers implemented local
>>> mux helpers, to undo that an atomic change must be made tree-wide.
>>>
>>> Meanwhile it must be avoided that while the mux core helpers are being
>>> tested / reviewed, that any tree adds another driver-local mux helper
>>> like appears to have happened here.
>>>
>>> Note that my patch-set did go to linux-phy@lists.infradead.org list, too.
>>>
>>> The second challenge for this series was that mux framework is being
>>> enabled only by drivers Kconfig "select" - and not possible by menuconfig.
>>> This is e.g. responsible for being unable to test =m build with arm64
>>> defconfig - and lead to it only being detected through kernel robot
>>> x86_64 allmodconfig.
>> To avoid this, a combination of developer due diligence + maintainer due
>> diligence is probably required.
>>
>> From linux-phy perspective, there will be some automated build testing
>> (which did not exist at the time of your submission). This would have
>> caught the 'hidden' devm_mux_state_get_optional() call present only in
>> linux-phy/next, when testing patch 2/7.
Excellent!
>>
>> But, to work, the build automation needs to be able to apply the entire
>> patch set on linux-phy/next. So expect some pushback if it doesn't
>> (hence the recommendation to send a mini-series to linux-phy first, and
>> request a stable tag).
It would help immensely if there was a way to get the patches renaming
driver-local conflicting helper-functions very early, before anything else.
Would this sort of patch be acceptable in linux-next now, so it can make
it into v7.0-rc1?
If not then that mini-patchset would be the first one I shall submit after
v7.0-rc1 is released.
Then I can treat the actual implementation of the devm_mux_* helpers
as a second standalone patch-set.
And finally patching all drivers with local helpers to use the new global ones
can be patch-set number 3.
Any opinions on this?
> I do not think that is at all the duty of the patch submitter. I think as
> long as every dependencies and side effects are documented, it is IMHO up to the
> maintainers to decide how it can be merged best. They know best whether there
> is any danger of conflicts in their working tree because that is an area
> where people are working on. Especially this patchset is around for months.
>
> In MFD where it is
> more common practice to have cross-subsystem patchsets, once acks from
> everyone are there, MFD Maintainer creates an immutable branch with a tag.
> The maintainers of the affected subsystems pull it in.
This seems like an option, if I can get the patch-set (or a partial one) ready early in the cycle.
>
> Regards,
> Andreas
>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH] phy: move spacemit pcie driver to its subfolder
From: Alex Elder @ 2026-02-23 13:00 UTC (permalink / raw)
To: Vinod Koul, linux-phy; +Cc: Neil Armstrong, Vladimir Oltean, Ze Huang, spacemit
In-Reply-To: <20260223064240.386617-1-vkoul@kernel.org>
On 2/23/26 12:42 AM, Vinod Koul wrote:
> Commit fe4bc1a08638 ("phy: spacemit: support K1 USB2.0 PHY controller")
> created spacemit subfolder with usb driver while commit 57e920b92724
> ("phy: spacemit: Introduce PCIe/combo PHY") added pcie driver in phy
> folder. Move latter into spacemit subfolder and rename file to
> phy-k1-pcie.c
>
> Signed-off-by: Vinod Koul <vkoul@kernel.org>
Looks good. Thanks!
Reviewed-by: Alex Elder <elder@riscstar.com>
> ---
> drivers/phy/Kconfig | 12 ------------
> drivers/phy/Makefile | 1 -
> drivers/phy/spacemit/Kconfig | 12 ++++++++++++
> drivers/phy/spacemit/Makefile | 1 +
> .../phy-k1-pcie.c} | 0
> 5 files changed, 13 insertions(+), 13 deletions(-)
> rename drivers/phy/{phy-spacemit-k1-pcie.c => spacemit/phy-k1-pcie.c} (100%)
>
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index 02467dfd4fb0..c0574e44f0a3 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -134,18 +134,6 @@ config PHY_NXP_PTN3222
> schemes. It supports all three USB 2.0 data rates: Low Speed, Full
> Speed and High Speed.
>
> -config PHY_SPACEMIT_K1_PCIE
> - tristate "PCIe and combo PHY driver for the SpacemiT K1 SoC"
> - depends on ARCH_SPACEMIT || COMPILE_TEST
> - depends on COMMON_CLK
> - depends on HAS_IOMEM
> - depends on OF
> - select GENERIC_PHY
> - default ARCH_SPACEMIT
> - help
> - Enable support for the PCIe and USB 3 combo PHY and two
> - PCIe-only PHYs used in the SpacemiT K1 SoC.
> -
> source "drivers/phy/allwinner/Kconfig"
> source "drivers/phy/amlogic/Kconfig"
> source "drivers/phy/apple/Kconfig"
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index a648c2e02a83..2773d596e543 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -16,7 +16,6 @@ obj-$(CONFIG_PHY_SNPS_EUSB2) += phy-snps-eusb2.o
> obj-$(CONFIG_USB_LGM_PHY) += phy-lgm-usb.o
> obj-$(CONFIG_PHY_AIROHA_PCIE) += phy-airoha-pcie.o
> obj-$(CONFIG_PHY_NXP_PTN3222) += phy-nxp-ptn3222.o
> -obj-$(CONFIG_PHY_SPACEMIT_K1_PCIE) += phy-spacemit-k1-pcie.o
> obj-$(CONFIG_GENERIC_PHY) += allwinner/ \
> amlogic/ \
> apple/ \
> diff --git a/drivers/phy/spacemit/Kconfig b/drivers/phy/spacemit/Kconfig
> index 0136aee2e8a2..50b0005acf66 100644
> --- a/drivers/phy/spacemit/Kconfig
> +++ b/drivers/phy/spacemit/Kconfig
> @@ -2,6 +2,18 @@
> #
> # Phy drivers for SpacemiT platforms
> #
> +config PHY_SPACEMIT_K1_PCIE
> + tristate "PCIe and combo PHY driver for the SpacemiT K1 SoC"
> + depends on ARCH_SPACEMIT || COMPILE_TEST
> + depends on COMMON_CLK
> + depends on HAS_IOMEM
> + depends on OF
> + select GENERIC_PHY
> + default ARCH_SPACEMIT
> + help
> + Enable support for the PCIe and USB 3 combo PHY and two
> + PCIe-only PHYs used in the SpacemiT K1 SoC.
> +
> config PHY_SPACEMIT_K1_USB2
> tristate "SpacemiT K1 USB 2.0 PHY support"
> depends on (ARCH_SPACEMIT || COMPILE_TEST) && OF
> diff --git a/drivers/phy/spacemit/Makefile b/drivers/phy/spacemit/Makefile
> index fec0b425a948..a821a21d6142 100644
> --- a/drivers/phy/spacemit/Makefile
> +++ b/drivers/phy/spacemit/Makefile
> @@ -1,2 +1,3 @@
> # SPDX-License-Identifier: GPL-2.0-only
> +obj-$(CONFIG_PHY_SPACEMIT_K1_PCIE) += phy-k1-pcie.o
> obj-$(CONFIG_PHY_SPACEMIT_K1_USB2) += phy-k1-usb2.o
> diff --git a/drivers/phy/phy-spacemit-k1-pcie.c b/drivers/phy/spacemit/phy-k1-pcie.c
> similarity index 100%
> rename from drivers/phy/phy-spacemit-k1-pcie.c
> rename to drivers/phy/spacemit/phy-k1-pcie.c
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v9 1/7] phy: can-transceiver: rename temporary helper function to avoid conflict
From: Vladimir Oltean @ 2026-02-23 13:12 UTC (permalink / raw)
To: Josua Mayer
Cc: Andreas Kemnade, Geert Uytterhoeven, Marc Kleine-Budde,
Vincent Mailhol, Vinod Koul, Neil Armstrong, Peter Rosin,
Aaro Koskinen, Kevin Hilman, Roger Quadros, Tony Lindgren,
Janusz Krzysztofik, Vignesh R, Andi Shyti, Ulf Hansson,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm, Wolfram Sang, Yazan Shhady,
Jon Nettleton, Mikhail Anikin, linux-can@vger.kernel.org,
linux-phy@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-omap@vger.kernel.org, linux-i2c@vger.kernel.org,
linux-mmc@vger.kernel.org, devicetree@vger.kernel.org,
linux-renesas-soc@vger.kernel.org
In-Reply-To: <203a36fb-6ac9-41f6-80ce-b137b9db4ad1@solid-run.com>
On Mon, Feb 23, 2026 at 12:43:48PM +0000, Josua Mayer wrote:
> It would help immensely if there was a way to get the patches renaming
> driver-local conflicting helper-functions very early, before anything else.
>
> Would this sort of patch be acceptable in linux-next now, so it can make
> it into v7.0-rc1?
>
> If not then that mini-patchset would be the first one I shall submit after
> v7.0-rc1 is released.
v7.0-rc1 was already tagged as commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f.
Additionally, patches are not accepted directly *in* linux-next. They
are accepted in subsystem trees (linux-phy, mmc, etc) which are then
integrated all together in linux-next.
>
> Then I can treat the actual implementation of the devm_mux_* helpers
> as a second standalone patch-set.
>
> And finally patching all drivers with local helpers to use the new global ones
> can be patch-set number 3.
>
> Any opinions on this?
From linux-phy perspective, I think in this particular case the following
would help:
- submit the patches at the beginning of the development cycle (i.e.
now) while the subsystem trees didn't diverge too much
- submit the patch series *in full* (to get build testing of the later
devm_mux_state_get_optional() introduction too, even if that is not
for linux-phy)
- keep all patches pertaining to linux-phy (the mini-patchset) together
and close to the beginning of the series, so they can be picked
without other dependencies
- be clear in the cover letter if you require a stable tag for the
linux-phy patches to be picked in other trees. You seem to be in the
best position to be aware of all dependencies.
I don't know what is the exact status with the MULTIPLEXER SUBSYSTEM
which is marked as Odd Fixes and doesn't have appear to have a subsystem
tree. I have no recommendation there.
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v9 1/7] phy: can-transceiver: rename temporary helper function to avoid conflict
From: Ulf Hansson @ 2026-02-23 13:44 UTC (permalink / raw)
To: Josua Mayer
Cc: Andreas Kemnade, Vladimir Oltean, Geert Uytterhoeven,
Marc Kleine-Budde, Vincent Mailhol, Vinod Koul, Neil Armstrong,
Peter Rosin, Aaro Koskinen, Kevin Hilman, Roger Quadros,
Tony Lindgren, Janusz Krzysztofik, Vignesh R, Andi Shyti,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm, Wolfram Sang, Yazan Shhady,
Jon Nettleton, Mikhail Anikin, linux-can@vger.kernel.org,
linux-phy@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-omap@vger.kernel.org, linux-i2c@vger.kernel.org,
linux-mmc@vger.kernel.org, devicetree@vger.kernel.org,
linux-renesas-soc@vger.kernel.org
In-Reply-To: <203a36fb-6ac9-41f6-80ce-b137b9db4ad1@solid-run.com>
On Mon, 23 Feb 2026 at 13:44, Josua Mayer <josua@solid-run.com> wrote:
>
> Am 16.02.26 um 16:24 schrieb Andreas Kemnade:
> > On Mon, 16 Feb 2026 11:29:14 +0200
> > Vladimir Oltean <olteanv@gmail.com> wrote:
> >
> >> Hi Josua,
> >>
> >> On Mon, Feb 16, 2026 at 08:19:27AM +0000, Josua Mayer wrote:
> >>>>> In the future, when you have a series with cross-tree dependencies,
> >>>>> please try to think of it as individual mini-series for each tree's
> >>>>> 'next' branch, and specify clearly that you need stable tags (to be
> >>>>> pulled into other trees).
> >>> I don't really understand how I could split my series up to avoid this
> >>> issue.
> >>>
> >>> Due to the fact that one (and now two) drivers implemented local
> >>> mux helpers, to undo that an atomic change must be made tree-wide.
> >>>
> >>> Meanwhile it must be avoided that while the mux core helpers are being
> >>> tested / reviewed, that any tree adds another driver-local mux helper
> >>> like appears to have happened here.
> >>>
> >>> Note that my patch-set did go to linux-phy@lists.infradead.org list, too.
> >>>
> >>> The second challenge for this series was that mux framework is being
> >>> enabled only by drivers Kconfig "select" - and not possible by menuconfig.
> >>> This is e.g. responsible for being unable to test =m build with arm64
> >>> defconfig - and lead to it only being detected through kernel robot
> >>> x86_64 allmodconfig.
> >> To avoid this, a combination of developer due diligence + maintainer due
> >> diligence is probably required.
> >>
> >> From linux-phy perspective, there will be some automated build testing
> >> (which did not exist at the time of your submission). This would have
> >> caught the 'hidden' devm_mux_state_get_optional() call present only in
> >> linux-phy/next, when testing patch 2/7.
> Excellent!
> >>
> >> But, to work, the build automation needs to be able to apply the entire
> >> patch set on linux-phy/next. So expect some pushback if it doesn't
> >> (hence the recommendation to send a mini-series to linux-phy first, and
> >> request a stable tag).
> It would help immensely if there was a way to get the patches renaming
> driver-local conflicting helper-functions very early, before anything else.
>
> Would this sort of patch be acceptable in linux-next now, so it can make
> it into v7.0-rc1?
>
> If not then that mini-patchset would be the first one I shall submit after
> v7.0-rc1 is released.
>
> Then I can treat the actual implementation of the devm_mux_* helpers
> as a second standalone patch-set.
>
> And finally patching all drivers with local helpers to use the new global ones
> can be patch-set number 3.
>
> Any opinions on this?
>
> > I do not think that is at all the duty of the patch submitter. I think as
> > long as every dependencies and side effects are documented, it is IMHO up to the
> > maintainers to decide how it can be merged best. They know best whether there
> > is any danger of conflicts in their working tree because that is an area
> > where people are working on. Especially this patchset is around for months.
> >
> > In MFD where it is
> > more common practice to have cross-subsystem patchsets, once acks from
> > everyone are there, MFD Maintainer creates an immutable branch with a tag.
> > The maintainers of the affected subsystems pull it in.
> This seems like an option, if I can get the patch-set (or a partial one) ready early in the cycle.
I agree with this approach as it should provide less churns for all of
us. Especially since the changes to the consumer drivers here are few
and trivial.
I am willing to help with hosting the immutable branch (unless someone
else wants of course). Once all acks have been received for the
series, I can set it up. Then other subsystem maintainers can pull it
in if there is a need to avoid conflicts/build-errors.
Kind regards
Uffe
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH] phy: mediatek: allow building T-PHY driver for MT7621 MIPS SoC
From: AngeloGioacchino Del Regno @ 2026-02-23 13:47 UTC (permalink / raw)
To: Shiji Yang, linux-phy
Cc: Chunfeng Yun, Vinod Koul, Neil Armstrong, Matthias Brugger,
linux-arm-kernel, linux-mediatek, linux-kernel
In-Reply-To: <OS7PR01MB136023DAF6E893E8110CEF777BC6BA@OS7PR01MB13602.jpnprd01.prod.outlook.com>
Il 19/02/26 13:53, Shiji Yang ha scritto:
> MT7621 also has compatible T-PHY which attached to the XHCI interface.
>
> Signed-off-by: Shiji Yang <yangshiji66@outlook.com>
MT7621 seems to be a bit special among the mips/ralink platforms, so I agree.
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v3 0/2] Add Axiado AX3000 eMMC Host Controller Support
From: Ulf Hansson @ 2026-02-23 14:12 UTC (permalink / raw)
To: Tzu-Hao Wei
Cc: SriNavmani A, Prasad Bolisetty, Vinod Koul, Neil Armstrong,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Adrian Hunter,
Michal Simek, linux-phy, devicetree, linux-arm-kernel,
linux-kernel, linux-mmc, openbmc
In-Reply-To: <20260206-axiado-ax3000-add-emmc-host-driver-support-v3-0-ef83b09325be@axiado.com>
On Fri, 6 Feb 2026 at 09:23, Tzu-Hao Wei <twei@axiado.com> wrote:
>
> Axiado AX3000 SoC eMMC controller is based on Arasan eMMC controller.
>
> This series includes:
> 1. Add bindings for AX3000 SoC eMMC controller
> 2. Add arasan sdhci support for eMMC in Axiado AX3000
>
> For platform device tree change, we will send a different series of
> patches.
>
> It has been verified on AX3000 platform.
>
> ---
> Changes in v3:
> - Enable SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN quirk
> - Remove dependencies in b4
> - Link to v2: https://lore.kernel.org/r/20260109-axiado-ax3000-add-emmc-host-driver-support-v2-0-934f1a61f7c0@axiado.com
>
> Changes in v2:
> - Keep host controller changes in this patchset
> - Use pdata instead of mix compatible string
> - Fix coding style
> - Link to v1: https://lore.kernel.org/r/20251222-axiado-ax3000-add-emmc-host-driver-support-v1-0-5457d0ebcdb4@axiado.com
>
> Signed-off-by: Tzu-Hao Wei <twei@axiado.com>
>
> ---
> SriNavmani A (2):
> dt-bindings: mmc: arasan,sdhci: Add Axiado AX3000 SoC
> mmc: sdhci-of-arasan: add support on Axiado AX3000 SoC
>
> Documentation/devicetree/bindings/mmc/arasan,sdhci.yaml | 3 +++
> drivers/mmc/host/sdhci-of-arasan.c | 15 +++++++++++++++
> 2 files changed, 18 insertions(+)
> ---
> base-commit: 63804fed149a6750ffd28610c5c1c98cce6bd377
> change-id: 20251222-axiado-ax3000-add-emmc-host-driver-support-2cc84a8f889a
>
> Best regards,
> --
> Tzu-Hao Wei <twei@axiado.com>
>
Applied for next, thanks!
Kind regards
Uffe
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH] phy: move spacemit pcie driver to its subfolder
From: Yixun Lan @ 2026-02-23 14:38 UTC (permalink / raw)
To: Vinod Koul
Cc: linux-phy, Neil Armstrong, Vladimir Oltean, Alex Elder, Ze Huang,
spacemit
In-Reply-To: <20260223064240.386617-1-vkoul@kernel.org>
Hi Vinod,
On 12:12 Mon 23 Feb , Vinod Koul wrote:
> Commit fe4bc1a08638 ("phy: spacemit: support K1 USB2.0 PHY controller")
> created spacemit subfolder with usb driver while commit 57e920b92724
> ("phy: spacemit: Introduce PCIe/combo PHY") added pcie driver in phy
> folder. Move latter into spacemit subfolder and rename file to
> phy-k1-pcie.c
>
Make sense, this looks better, thanks
Reviewed-by: Yixun Lan <dlan@kernel.org>
> Signed-off-by: Vinod Koul <vkoul@kernel.org>
> ---
> drivers/phy/Kconfig | 12 ------------
> drivers/phy/Makefile | 1 -
> drivers/phy/spacemit/Kconfig | 12 ++++++++++++
> drivers/phy/spacemit/Makefile | 1 +
> .../phy-k1-pcie.c} | 0
> 5 files changed, 13 insertions(+), 13 deletions(-)
> rename drivers/phy/{phy-spacemit-k1-pcie.c => spacemit/phy-k1-pcie.c} (100%)
>
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index 02467dfd4fb0..c0574e44f0a3 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -134,18 +134,6 @@ config PHY_NXP_PTN3222
> schemes. It supports all three USB 2.0 data rates: Low Speed, Full
> Speed and High Speed.
>
> -config PHY_SPACEMIT_K1_PCIE
> - tristate "PCIe and combo PHY driver for the SpacemiT K1 SoC"
> - depends on ARCH_SPACEMIT || COMPILE_TEST
> - depends on COMMON_CLK
> - depends on HAS_IOMEM
> - depends on OF
> - select GENERIC_PHY
> - default ARCH_SPACEMIT
> - help
> - Enable support for the PCIe and USB 3 combo PHY and two
> - PCIe-only PHYs used in the SpacemiT K1 SoC.
> -
> source "drivers/phy/allwinner/Kconfig"
> source "drivers/phy/amlogic/Kconfig"
> source "drivers/phy/apple/Kconfig"
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index a648c2e02a83..2773d596e543 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -16,7 +16,6 @@ obj-$(CONFIG_PHY_SNPS_EUSB2) += phy-snps-eusb2.o
> obj-$(CONFIG_USB_LGM_PHY) += phy-lgm-usb.o
> obj-$(CONFIG_PHY_AIROHA_PCIE) += phy-airoha-pcie.o
> obj-$(CONFIG_PHY_NXP_PTN3222) += phy-nxp-ptn3222.o
> -obj-$(CONFIG_PHY_SPACEMIT_K1_PCIE) += phy-spacemit-k1-pcie.o
> obj-$(CONFIG_GENERIC_PHY) += allwinner/ \
> amlogic/ \
> apple/ \
> diff --git a/drivers/phy/spacemit/Kconfig b/drivers/phy/spacemit/Kconfig
> index 0136aee2e8a2..50b0005acf66 100644
> --- a/drivers/phy/spacemit/Kconfig
> +++ b/drivers/phy/spacemit/Kconfig
> @@ -2,6 +2,18 @@
> #
> # Phy drivers for SpacemiT platforms
> #
> +config PHY_SPACEMIT_K1_PCIE
> + tristate "PCIe and combo PHY driver for the SpacemiT K1 SoC"
> + depends on ARCH_SPACEMIT || COMPILE_TEST
> + depends on COMMON_CLK
> + depends on HAS_IOMEM
> + depends on OF
> + select GENERIC_PHY
> + default ARCH_SPACEMIT
> + help
> + Enable support for the PCIe and USB 3 combo PHY and two
> + PCIe-only PHYs used in the SpacemiT K1 SoC.
> +
> config PHY_SPACEMIT_K1_USB2
> tristate "SpacemiT K1 USB 2.0 PHY support"
> depends on (ARCH_SPACEMIT || COMPILE_TEST) && OF
> diff --git a/drivers/phy/spacemit/Makefile b/drivers/phy/spacemit/Makefile
> index fec0b425a948..a821a21d6142 100644
> --- a/drivers/phy/spacemit/Makefile
> +++ b/drivers/phy/spacemit/Makefile
> @@ -1,2 +1,3 @@
> # SPDX-License-Identifier: GPL-2.0-only
> +obj-$(CONFIG_PHY_SPACEMIT_K1_PCIE) += phy-k1-pcie.o
> obj-$(CONFIG_PHY_SPACEMIT_K1_USB2) += phy-k1-usb2.o
> diff --git a/drivers/phy/phy-spacemit-k1-pcie.c b/drivers/phy/spacemit/phy-k1-pcie.c
> similarity index 100%
> rename from drivers/phy/phy-spacemit-k1-pcie.c
> rename to drivers/phy/spacemit/phy-k1-pcie.c
> --
> 2.43.0
>
>
--
Yixun Lan (dlan)
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH v3 0/6] Add support for mt8167 display blocks
From: Luca Leonardo Scorcia @ 2026-02-23 16:22 UTC (permalink / raw)
To: linux-mediatek
Cc: Luca Leonardo Scorcia, Chun-Kuang Hu, Philipp Zabel,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Chunfeng Yun, Vinod Koul, Neil Armstrong, Matthias Brugger,
AngeloGioacchino Del Regno, dri-devel, devicetree, linux-kernel,
linux-arm-kernel, linux-phy
This series adds support for the display blocks on MediaTek mt8167.
Tested on Xiaomi Mi Smart Clock x04g.
The first patch just does some reordering of dts nodes with no other
changes as this makes later patches cleaner and easier to follow.
v3:
- Added mt8167-dsi compatible to driver instead of changing the binding;
- Resolved patch formatting issues.
v2:
- Separate patch for mediatek,dsi-phy binding;
- Separate patch for mt8167-dsi binding;
- Simplified OF graph endpoints in mt8167.dtsi.
Luca Leonardo Scorcia (5):
arm64: dts: mt8167: Reorder nodes according to mmio address
dt-bindings: display: mediatek: Add compatibles for MediaTek mt8167
dt-bindings: phy: mediatek,dsi-phy: Add support for mt8167
arm64: dts: mediatek: mt8167: Add DRM nodes
drm/mediatek: dsi: Add compatible for mt8167-dsi
Val Packett (1):
gpu: drm: mediatek: ovl: add specific entry for mt8167
.../display/mediatek/mediatek,aal.yaml | 1 +
.../display/mediatek/mediatek,ccorr.yaml | 4 +-
.../display/mediatek/mediatek,dither.yaml | 1 +
.../display/mediatek/mediatek,gamma.yaml | 1 +
.../display/mediatek/mediatek,ovl.yaml | 1 +
.../display/mediatek/mediatek,rdma.yaml | 1 +
.../display/mediatek/mediatek,wdma.yaml | 4 +-
.../bindings/phy/mediatek,dsi-phy.yaml | 1 +
arch/arm64/boot/dts/mediatek/mt8167.dtsi | 381 ++++++++++++++++--
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 12 +
drivers/gpu/drm/mediatek/mtk_dsi.c | 1 +
11 files changed, 374 insertions(+), 34 deletions(-)
--
2.43.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH v3 1/6] arm64: dts: mt8167: Reorder nodes according to mmio address
From: Luca Leonardo Scorcia @ 2026-02-23 16:22 UTC (permalink / raw)
To: linux-mediatek
Cc: Luca Leonardo Scorcia, AngeloGioacchino Del Regno, Chun-Kuang Hu,
Philipp Zabel, David Airlie, Simona Vetter, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Chunfeng Yun, Vinod Koul,
Neil Armstrong, Matthias Brugger, dri-devel, devicetree,
linux-kernel, linux-arm-kernel, linux-phy
In-Reply-To: <cover.1771863641.git.l.scorcia@gmail.com>
In preparation for adding display nodes. No other changes.
Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
arch/arm64/boot/dts/mediatek/mt8167.dtsi | 68 ++++++++++++------------
1 file changed, 34 insertions(+), 34 deletions(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt8167.dtsi b/arch/arm64/boot/dts/mediatek/mt8167.dtsi
index 2374c0953057..27cf32d7ae35 100644
--- a/arch/arm64/boot/dts/mediatek/mt8167.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8167.dtsi
@@ -29,12 +29,6 @@ infracfg: infracfg@10001000 {
#clock-cells = <1>;
};
- apmixedsys: apmixedsys@10018000 {
- compatible = "mediatek,mt8167-apmixedsys", "syscon";
- reg = <0 0x10018000 0 0x710>;
- #clock-cells = <1>;
- };
-
scpsys: syscon@10006000 {
compatible = "mediatek,mt8167-scpsys", "syscon", "simple-mfd";
reg = <0 0x10006000 0 0x1000>;
@@ -101,18 +95,6 @@ power-domain@MT8167_POWER_DOMAIN_CONN {
};
};
- imgsys: syscon@15000000 {
- compatible = "mediatek,mt8167-imgsys", "syscon";
- reg = <0 0x15000000 0 0x1000>;
- #clock-cells = <1>;
- };
-
- vdecsys: syscon@16000000 {
- compatible = "mediatek,mt8167-vdecsys", "syscon";
- reg = <0 0x16000000 0 0x1000>;
- #clock-cells = <1>;
- };
-
pio: pinctrl@1000b000 {
compatible = "mediatek,mt8167-pinctrl";
reg = <0 0x1000b000 0 0x1000>;
@@ -124,12 +106,36 @@ pio: pinctrl@1000b000 {
interrupts = <GIC_SPI 134 IRQ_TYPE_LEVEL_HIGH>;
};
+ apmixedsys: apmixedsys@10018000 {
+ compatible = "mediatek,mt8167-apmixedsys", "syscon";
+ reg = <0 0x10018000 0 0x710>;
+ #clock-cells = <1>;
+ };
+
+ iommu: m4u@10203000 {
+ compatible = "mediatek,mt8167-m4u";
+ reg = <0 0x10203000 0 0x1000>;
+ mediatek,larbs = <&larb0>, <&larb1>, <&larb2>;
+ interrupts = <GIC_SPI 121 IRQ_TYPE_LEVEL_LOW>;
+ #iommu-cells = <1>;
+ };
+
mmsys: syscon@14000000 {
compatible = "mediatek,mt8167-mmsys", "syscon";
reg = <0 0x14000000 0 0x1000>;
#clock-cells = <1>;
};
+ larb0: larb@14016000 {
+ compatible = "mediatek,mt8167-smi-larb";
+ reg = <0 0x14016000 0 0x1000>;
+ mediatek,smi = <&smi_common>;
+ clocks = <&mmsys CLK_MM_SMI_LARB0>,
+ <&mmsys CLK_MM_SMI_LARB0>;
+ clock-names = "apb", "smi";
+ power-domains = <&spm MT8167_POWER_DOMAIN_MM>;
+ };
+
smi_common: smi@14017000 {
compatible = "mediatek,mt8167-smi-common";
reg = <0 0x14017000 0 0x1000>;
@@ -139,14 +145,10 @@ smi_common: smi@14017000 {
power-domains = <&spm MT8167_POWER_DOMAIN_MM>;
};
- larb0: larb@14016000 {
- compatible = "mediatek,mt8167-smi-larb";
- reg = <0 0x14016000 0 0x1000>;
- mediatek,smi = <&smi_common>;
- clocks = <&mmsys CLK_MM_SMI_LARB0>,
- <&mmsys CLK_MM_SMI_LARB0>;
- clock-names = "apb", "smi";
- power-domains = <&spm MT8167_POWER_DOMAIN_MM>;
+ imgsys: syscon@15000000 {
+ compatible = "mediatek,mt8167-imgsys", "syscon";
+ reg = <0 0x15000000 0 0x1000>;
+ #clock-cells = <1>;
};
larb1: larb@15001000 {
@@ -159,6 +161,12 @@ larb1: larb@15001000 {
power-domains = <&spm MT8167_POWER_DOMAIN_ISP>;
};
+ vdecsys: syscon@16000000 {
+ compatible = "mediatek,mt8167-vdecsys", "syscon";
+ reg = <0 0x16000000 0 0x1000>;
+ #clock-cells = <1>;
+ };
+
larb2: larb@16010000 {
compatible = "mediatek,mt8167-smi-larb";
reg = <0 0x16010000 0 0x1000>;
@@ -168,13 +176,5 @@ larb2: larb@16010000 {
clock-names = "apb", "smi";
power-domains = <&spm MT8167_POWER_DOMAIN_VDEC>;
};
-
- iommu: m4u@10203000 {
- compatible = "mediatek,mt8167-m4u";
- reg = <0 0x10203000 0 0x1000>;
- mediatek,larbs = <&larb0>, <&larb1>, <&larb2>;
- interrupts = <GIC_SPI 121 IRQ_TYPE_LEVEL_LOW>;
- #iommu-cells = <1>;
- };
};
};
--
2.43.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v3 2/6] dt-bindings: display: mediatek: Add compatibles for MediaTek mt8167
From: Luca Leonardo Scorcia @ 2026-02-23 16:22 UTC (permalink / raw)
To: linux-mediatek
Cc: Luca Leonardo Scorcia, Krzysztof Kozlowski,
AngeloGioacchino Del Regno, Chun-Kuang Hu, Philipp Zabel,
David Airlie, Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Chunfeng Yun, Vinod Koul, Neil Armstrong, Matthias Brugger,
dri-devel, devicetree, linux-kernel, linux-arm-kernel, linux-phy
In-Reply-To: <cover.1771863641.git.l.scorcia@gmail.com>
Add compatibles for various display-related blocks of MediaTek mt8167.
Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
.../devicetree/bindings/display/mediatek/mediatek,aal.yaml | 1 +
.../devicetree/bindings/display/mediatek/mediatek,ccorr.yaml | 4 +++-
.../devicetree/bindings/display/mediatek/mediatek,dither.yaml | 1 +
.../devicetree/bindings/display/mediatek/mediatek,gamma.yaml | 1 +
.../devicetree/bindings/display/mediatek/mediatek,ovl.yaml | 1 +
.../devicetree/bindings/display/mediatek/mediatek,rdma.yaml | 1 +
.../devicetree/bindings/display/mediatek/mediatek,wdma.yaml | 4 +++-
7 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
index daf90ebb39bf..4bbea72b292a 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
@@ -33,6 +33,7 @@ properties:
- enum:
- mediatek,mt2712-disp-aal
- mediatek,mt6795-disp-aal
+ - mediatek,mt8167-disp-aal
- const: mediatek,mt8173-disp-aal
- items:
- enum:
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml
index fca8e7bb0cbc..5c5068128d0c 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml
@@ -25,7 +25,9 @@ properties:
- mediatek,mt8183-disp-ccorr
- mediatek,mt8192-disp-ccorr
- items:
- - const: mediatek,mt8365-disp-ccorr
+ - enum:
+ - mediatek,mt8167-disp-ccorr
+ - mediatek,mt8365-disp-ccorr
- const: mediatek,mt8183-disp-ccorr
- items:
- enum:
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml
index abaf27916d13..891c95be15b9 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml
@@ -26,6 +26,7 @@ properties:
- mediatek,mt8183-disp-dither
- items:
- enum:
+ - mediatek,mt8167-disp-dither
- mediatek,mt8186-disp-dither
- mediatek,mt8188-disp-dither
- mediatek,mt8192-disp-dither
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml
index 48542dc7e784..ec1054bb06d4 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml
@@ -28,6 +28,7 @@ properties:
- items:
- enum:
- mediatek,mt6795-disp-gamma
+ - mediatek,mt8167-disp-gamma
- const: mediatek,mt8173-disp-gamma
- items:
- enum:
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml
index 4f110635afb6..679f731f0f15 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml
@@ -23,6 +23,7 @@ properties:
oneOf:
- enum:
- mediatek,mt2701-disp-ovl
+ - mediatek,mt8167-disp-ovl
- mediatek,mt8173-disp-ovl
- mediatek,mt8183-disp-ovl
- mediatek,mt8192-disp-ovl
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml
index 878f676b581f..cb187a95c11e 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml
@@ -36,6 +36,7 @@ properties:
- enum:
- mediatek,mt7623-disp-rdma
- mediatek,mt2712-disp-rdma
+ - mediatek,mt8167-disp-rdma
- const: mediatek,mt2701-disp-rdma
- items:
- enum:
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,wdma.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,wdma.yaml
index a3a2b71a4523..816841a96133 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,wdma.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,wdma.yaml
@@ -24,7 +24,9 @@ properties:
- enum:
- mediatek,mt8173-disp-wdma
- items:
- - const: mediatek,mt6795-disp-wdma
+ - enum:
+ - mediatek,mt6795-disp-wdma
+ - mediatek,mt8167-disp-wdma
- const: mediatek,mt8173-disp-wdma
reg:
--
2.43.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v3 3/6] dt-bindings: phy: mediatek,dsi-phy: Add support for mt8167
From: Luca Leonardo Scorcia @ 2026-02-23 16:22 UTC (permalink / raw)
To: linux-mediatek
Cc: Luca Leonardo Scorcia, AngeloGioacchino Del Regno,
Krzysztof Kozlowski, Chun-Kuang Hu, Philipp Zabel, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Chunfeng Yun, Vinod Koul, Neil Armstrong, Matthias Brugger,
dri-devel, devicetree, linux-kernel, linux-arm-kernel, linux-phy
In-Reply-To: <cover.1771863641.git.l.scorcia@gmail.com>
Add support for the MediaTek mt8167 SoC: the DSI PHY found
in this chip is fully compatible with the one found in the mt2701 SoC.
Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml b/Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml
index acdbce937b0a..c6d0bbdbe0e2 100644
--- a/Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml
@@ -23,6 +23,7 @@ properties:
- items:
- enum:
- mediatek,mt7623-mipi-tx
+ - mediatek,mt8167-mipi-tx
- const: mediatek,mt2701-mipi-tx
- items:
- enum:
--
2.43.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v3 4/6] arm64: dts: mediatek: mt8167: Add DRM nodes
From: Luca Leonardo Scorcia @ 2026-02-23 16:22 UTC (permalink / raw)
To: linux-mediatek
Cc: Luca Leonardo Scorcia, AngeloGioacchino Del Regno, Chun-Kuang Hu,
Philipp Zabel, David Airlie, Simona Vetter, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Chunfeng Yun, Vinod Koul,
Neil Armstrong, Matthias Brugger, dri-devel, devicetree,
linux-kernel, linux-arm-kernel, linux-phy
In-Reply-To: <cover.1771863641.git.l.scorcia@gmail.com>
Add all the DRM nodes required to get DSI to work on MT8167 SoC.
Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
arch/arm64/boot/dts/mediatek/mt8167.dtsi | 317 +++++++++++++++++++++++
1 file changed, 317 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8167.dtsi b/arch/arm64/boot/dts/mediatek/mt8167.dtsi
index 27cf32d7ae35..32d3895baaa6 100644
--- a/arch/arm64/boot/dts/mediatek/mt8167.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8167.dtsi
@@ -16,6 +16,20 @@
/ {
compatible = "mediatek,mt8167";
+ aliases {
+ aal0 = &aal;
+ ccorr0 = &ccorr;
+ color0 = &color;
+ dither0 = &dither;
+ dsi0 = &dsi;
+ gamma0 = γ
+ ovl0 = &ovl0;
+ pwm0 = &disp_pwm;
+ rdma0 = &rdma0;
+ rdma1 = &rdma1;
+ wdma0 = &wdma;
+ };
+
soc {
topckgen: topckgen@10000000 {
compatible = "mediatek,mt8167-topckgen", "syscon";
@@ -120,10 +134,303 @@ iommu: m4u@10203000 {
#iommu-cells = <1>;
};
+ disp_pwm: pwm@1100f000 {
+ compatible = "mediatek,mt8167-disp-pwm", "mediatek,mt8173-disp-pwm";
+ reg = <0 0x1100f000 0 0x1000>;
+ clocks = <&mmsys CLK_MM_DISP_PWM_26M>, <&mmsys CLK_MM_DISP_PWM_MM>;
+ clock-names = "main", "mm";
+ power-domains = <&spm MT8167_POWER_DOMAIN_MM>;
+ #pwm-cells = <2>;
+ status = "disabled";
+ };
+
mmsys: syscon@14000000 {
compatible = "mediatek,mt8167-mmsys", "syscon";
reg = <0 0x14000000 0 0x1000>;
+ power-domains = <&spm MT8167_POWER_DOMAIN_MM>;
#clock-cells = <1>;
+
+ port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mmsys_main: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&ovl0_in>;
+ };
+
+ mmsys_ext: endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <&rdma1_in>;
+ };
+ };
+ };
+
+ ovl0: ovl0@14007000 {
+ compatible = "mediatek,mt8167-disp-ovl";
+ reg = <0 0x14007000 0 0x1000>;
+ clocks = <&mmsys CLK_MM_DISP_OVL0>;
+ interrupts = <GIC_SPI 160 IRQ_TYPE_LEVEL_LOW>;
+ iommus = <&iommu M4U_PORT_DISP_OVL0>;
+ power-domains = <&spm MT8167_POWER_DOMAIN_MM>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ ovl0_in: endpoint {
+ remote-endpoint = <&mmsys_main>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ ovl0_out: endpoint {
+ remote-endpoint = <&color_in>;
+ };
+ };
+ };
+ };
+
+ rdma0: rdma0@14009000 {
+ compatible = "mediatek,mt8167-disp-rdma", "mediatek,mt2701-disp-rdma";
+ reg = <0 0x14009000 0 0x1000>;
+ clocks = <&mmsys CLK_MM_DISP_RDMA0>;
+ interrupts = <GIC_SPI 162 IRQ_TYPE_LEVEL_LOW>;
+ iommus = <&iommu M4U_PORT_DISP_RDMA0>;
+ power-domains = <&spm MT8167_POWER_DOMAIN_MM>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ rdma0_in: endpoint {
+ remote-endpoint = <&dither_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ rdma0_out: endpoint {
+ remote-endpoint = <&dsi_in>;
+ };
+ };
+ };
+ };
+
+ rdma1: rdma1@1400a000 {
+ compatible = "mediatek,mt8167-disp-rdma", "mediatek,mt2701-disp-rdma";
+ reg = <0 0x1400a000 0 0x1000>;
+ clocks = <&mmsys CLK_MM_DISP_RDMA1>;
+ interrupts = <GIC_SPI 163 IRQ_TYPE_LEVEL_LOW>;
+ iommus = <&iommu M4U_PORT_DISP_RDMA1>;
+ power-domains = <&spm MT8167_POWER_DOMAIN_MM>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ rdma1_in: endpoint {
+ remote-endpoint = <&mmsys_ext>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ rdma1_out: endpoint { };
+ };
+ };
+ };
+
+ wdma: wdma0@1400b000 {
+ compatible = "mediatek,mt8167-disp-wdma", "mediatek,mt8173-disp-wdma";
+ reg = <0 0x1400b000 0 0x1000>;
+ clocks = <&mmsys CLK_MM_DISP_WDMA>;
+ interrupts = <GIC_SPI 164 IRQ_TYPE_LEVEL_LOW>;
+ iommus = <&iommu M4U_PORT_DISP_WDMA0>;
+ power-domains = <&spm MT8167_POWER_DOMAIN_MM>;
+ };
+
+ color: color@1400c000 {
+ compatible = "mediatek,mt8167-disp-color";
+ reg = <0 0x1400c000 0 0x1000>;
+ clocks = <&mmsys CLK_MM_DISP_COLOR>;
+ interrupts = <GIC_SPI 165 IRQ_TYPE_LEVEL_LOW>;
+ power-domains = <&spm MT8167_POWER_DOMAIN_MM>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ color_in: endpoint {
+ remote-endpoint = <&ovl0_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ color_out: endpoint {
+ remote-endpoint = <&ccorr_in>;
+ };
+ };
+ };
+ };
+
+ ccorr: ccorr@1400d000 {
+ compatible = "mediatek,mt8167-disp-ccorr", "mediatek,mt8183-disp-ccorr";
+ reg = <0 0x1400d000 0 0x1000>;
+ clocks = <&mmsys CLK_MM_DISP_CCORR>;
+ interrupts = <GIC_SPI 166 IRQ_TYPE_LEVEL_LOW>;
+ power-domains = <&spm MT8167_POWER_DOMAIN_MM>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ ccorr_in: endpoint {
+ remote-endpoint = <&color_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ ccorr_out: endpoint {
+ remote-endpoint = <&aal_in>;
+ };
+ };
+ };
+ };
+
+ aal: aal@1400e000 {
+ compatible = "mediatek,mt8167-disp-aal", "mediatek,mt8173-disp-aal";
+ reg = <0 0x1400e000 0 0x1000>;
+ clocks = <&mmsys CLK_MM_DISP_AAL>;
+ interrupts = <GIC_SPI 167 IRQ_TYPE_LEVEL_LOW>;
+ power-domains = <&spm MT8167_POWER_DOMAIN_MM>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ aal_in: endpoint {
+ remote-endpoint = <&ccorr_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ aal_out: endpoint {
+ remote-endpoint = <&gamma_in>;
+ };
+ };
+ };
+ };
+
+ gamma: gamma@1400f000 {
+ compatible = "mediatek,mt8167-disp-gamma", "mediatek,mt8173-disp-gamma";
+ reg = <0 0x1400f000 0 0x1000>;
+ clocks = <&mmsys CLK_MM_DISP_GAMMA>;
+ interrupts = <GIC_SPI 168 IRQ_TYPE_LEVEL_LOW>;
+ power-domains = <&spm MT8167_POWER_DOMAIN_MM>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ gamma_in: endpoint {
+ remote-endpoint = <&aal_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ gamma_out: endpoint {
+ remote-endpoint = <&dither_in>;
+ };
+ };
+ };
+ };
+
+ dither: dither@14010000 {
+ compatible = "mediatek,mt8167-disp-dither", "mediatek,mt8183-disp-dither";
+ reg = <0 0x14010000 0 0x1000>;
+ clocks = <&mmsys CLK_MM_DISP_DITHER>;
+ interrupts = <GIC_SPI 169 IRQ_TYPE_LEVEL_LOW>;
+ power-domains = <&spm MT8167_POWER_DOMAIN_MM>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dither_in: endpoint {
+ remote-endpoint = <&gamma_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dither_out: endpoint {
+ remote-endpoint = <&rdma0_in>;
+ };
+ };
+ };
+ };
+
+ dsi: dsi@14012000 {
+ compatible = "mediatek,mt8167-dsi";
+ reg = <0 0x14012000 0 0x1000>;
+ clocks = <&mmsys CLK_MM_DSI_ENGINE>, <&mmsys CLK_MM_DSI_DIGITAL>,
+ <&mipi_tx>;
+ clock-names = "engine", "digital", "hs";
+ interrupts = <GIC_SPI 171 IRQ_TYPE_LEVEL_LOW>;
+ phys = <&mipi_tx>;
+ phy-names = "dphy";
+ power-domains = <&spm MT8167_POWER_DOMAIN_MM>;
+ status = "disabled";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dsi_in: endpoint {
+ remote-endpoint = <&rdma0_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dsi_out: endpoint { };
+ };
+ };
+ };
+
+ mutex: mutex@14015000 {
+ compatible = "mediatek,mt8167-disp-mutex";
+ reg = <0 0x14015000 0 0x1000>;
+ interrupts = <GIC_SPI 153 IRQ_TYPE_LEVEL_LOW>;
+ power-domains = <&spm MT8167_POWER_DOMAIN_MM>;
};
larb0: larb@14016000 {
@@ -145,6 +452,16 @@ smi_common: smi@14017000 {
power-domains = <&spm MT8167_POWER_DOMAIN_MM>;
};
+ mipi_tx: dsi-phy@14018000 {
+ compatible = "mediatek,mt8167-mipi-tx", "mediatek,mt2701-mipi-tx";
+ reg = <0 0x14018000 0 0x90>;
+ clocks = <&topckgen CLK_TOP_MIPI_26M_DBG>;
+ clock-output-names = "mipi_tx0_pll";
+ #clock-cells = <0>;
+ #phy-cells = <0>;
+ status = "disabled";
+ };
+
imgsys: syscon@15000000 {
compatible = "mediatek,mt8167-imgsys", "syscon";
reg = <0 0x15000000 0 0x1000>;
--
2.43.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v3 5/6] drm/mediatek: dsi: Add compatible for mt8167-dsi
From: Luca Leonardo Scorcia @ 2026-02-23 16:22 UTC (permalink / raw)
To: linux-mediatek
Cc: Luca Leonardo Scorcia, Chun-Kuang Hu, Philipp Zabel,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Chunfeng Yun, Vinod Koul, Neil Armstrong, Matthias Brugger,
AngeloGioacchino Del Regno, dri-devel, devicetree, linux-kernel,
linux-arm-kernel, linux-phy
In-Reply-To: <cover.1771863641.git.l.scorcia@gmail.com>
The mt8167 DSI controller is fully compatible with the one found in
mt2701. Device tree documentation is already present upstream.
Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
index af4871de9e4c..ad10e86b161d 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -1301,6 +1301,7 @@ static const struct mtk_dsi_driver_data mt8188_dsi_driver_data = {
static const struct of_device_id mtk_dsi_of_match[] = {
{ .compatible = "mediatek,mt2701-dsi", .data = &mt2701_dsi_driver_data },
+ { .compatible = "mediatek,mt8167-dsi", .data = &mt2701_dsi_driver_data },
{ .compatible = "mediatek,mt8173-dsi", .data = &mt8173_dsi_driver_data },
{ .compatible = "mediatek,mt8183-dsi", .data = &mt8183_dsi_driver_data },
{ .compatible = "mediatek,mt8186-dsi", .data = &mt8186_dsi_driver_data },
--
2.43.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v3 6/6] gpu: drm: mediatek: ovl: add specific entry for mt8167
From: Luca Leonardo Scorcia @ 2026-02-23 16:22 UTC (permalink / raw)
To: linux-mediatek
Cc: Val Packett, Luca Leonardo Scorcia, AngeloGioacchino Del Regno,
Chun-Kuang Hu, Philipp Zabel, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Chunfeng Yun, Vinod Koul,
Neil Armstrong, Matthias Brugger, dri-devel, devicetree,
linux-kernel, linux-arm-kernel, linux-phy
In-Reply-To: <cover.1771863641.git.l.scorcia@gmail.com>
From: Val Packett <val@packett.cool>
While this configuration is otherwise identical to mt8173, according
to Android kernel sources, this SoC does need smi_id_en.
Signed-off-by: Val Packett <val@packett.cool>
Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index e0236353d499..97a899e4bd99 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -671,6 +671,16 @@ static const struct mtk_disp_ovl_data mt2701_ovl_driver_data = {
.num_formats = ARRAY_SIZE(mt8173_formats),
};
+static const struct mtk_disp_ovl_data mt8167_ovl_driver_data = {
+ .addr = DISP_REG_OVL_ADDR_MT8173,
+ .gmc_bits = 8,
+ .layer_nr = 4,
+ .fmt_rgb565_is_0 = true,
+ .smi_id_en = true,
+ .formats = mt8173_formats,
+ .num_formats = ARRAY_SIZE(mt8173_formats),
+};
+
static const struct mtk_disp_ovl_data mt8173_ovl_driver_data = {
.addr = DISP_REG_OVL_ADDR_MT8173,
.gmc_bits = 8,
@@ -742,6 +752,8 @@ static const struct mtk_disp_ovl_data mt8195_ovl_driver_data = {
static const struct of_device_id mtk_disp_ovl_driver_dt_match[] = {
{ .compatible = "mediatek,mt2701-disp-ovl",
.data = &mt2701_ovl_driver_data},
+ { .compatible = "mediatek,mt8167-disp-ovl",
+ .data = &mt8167_ovl_driver_data},
{ .compatible = "mediatek,mt8173-disp-ovl",
.data = &mt8173_ovl_driver_data},
{ .compatible = "mediatek,mt8183-disp-ovl",
--
2.43.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* Re: [PATCH v3 5/6] drm/mediatek: dsi: Add compatible for mt8167-dsi
From: AngeloGioacchino Del Regno @ 2026-02-23 16:39 UTC (permalink / raw)
To: Luca Leonardo Scorcia, linux-mediatek
Cc: Chun-Kuang Hu, Philipp Zabel, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Chunfeng Yun, Vinod Koul,
Neil Armstrong, Matthias Brugger, dri-devel, devicetree,
linux-kernel, linux-arm-kernel, linux-phy
In-Reply-To: <2fbf179c03c61f527e2583f9df4f97f6aaf3297a.1771863641.git.l.scorcia@gmail.com>
Il 23/02/26 17:22, Luca Leonardo Scorcia ha scritto:
> The mt8167 DSI controller is fully compatible with the one found in
> mt2701. Device tree documentation is already present upstream.
>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH] phy: core: fix potential UAF in of_phy_simple_xlate()
From: Vladimir Oltean @ 2026-02-23 23:15 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Vinod Koul, Kishon Vijay Abraham I, Neil Armstrong,
Rafael J. Wysocki, Geert Uytterhoeven, Johan Hovold,
Claudiu Beznea, Dr. David Alan Gilbert, Peter Griffin,
Dmitry Baryshkov, Krzysztof Kozlowski, Zijun Hu, linux-phy,
linux-kernel
In-Reply-To: <aZkCyQ1oizPXplyU@google.com>
Hi Dmitry,
On Fri, Feb 20, 2026 at 05:01:50PM -0800, Dmitry Torokhov wrote:
> On Thu, Feb 19, 2026 at 04:11:37PM -0800, Dmitry Torokhov wrote:
> > On Thu, Feb 19, 2026 at 03:57:11PM -0800, Dmitry Torokhov wrote:
> > > The implementation put_device()s located device and then uses
> > > container_of() on the pointer. The device may disappear by that time,
> > > resulting in UAF.
> > >
> > > Fix the problem by keeping the reference to the framer device,
> > > avoiding getting an extra reference to it in framer_get(), and making
> > > sure to drop the reference in error path when we fail to get the module.
> >
> > Hmm, I was too rash. There are bunch of other xlate functions that need
> > to be updated to take the reference.
>
> So I am convinced that xlate functions need to bump up the reference to
> phy devices they return. The question is how to deal with the ones that
> do not. I can either convert them in the same patch (the changes are
> quite mechanical) or we can do the whole song and dance, introduce a
> flag, set it up in converted xlate functions, have the core respect it,
> and then remove it from xlates and from the core when it is all done.
>
> Please let me know.
You have hit on a weak spot of the Generic PHY framework and I would
like to encourage you to follow through with patches for this finding
(although it won't be exactly trivial, I think it's doable with some
determination).
On your direct question:
It will impact downstream in subtle and unpleasant ways if you change
the of_xlate() semantics w.r.t. reference counting, but the code will
still compile just as before, i.e. when looking just at your downstream
driver (what 99% of developers do) there will be no obvious way of
knowing that something in the API has changed. I would avoid doing that.
But first the problem. Too little has been said about the problem, and
too much about the solution. We can't find a good solution if we don't
call out the problem properly first.
The phy_get() function follows a "lookup-then-get" approach for PHY
providers, rather than "atomic-lookup-and-get".
Namely, the phy_provider->of_xlate() caller, which is _of_phy_get(),
returns a struct phy * with its underlying device reference count
nominally at 1. All callers of _of_phy_get() do later call get_device()
to bump this refcount for each PHY consumer, but it is "too late" in the
sense that a window has been opened where the PHY provider driver can
unbind, and the reference count of &phy->dev can drop to 0 and it can be
freed.
Immediately after being created by phy_create(), the &phy->dev has a
refcount of 1, and only the action of its provider driver (calling
phy_destroy() directly or through devres, on driver unbind) can drop
that refcount to 0. As long as the driver doesn't do that, the &phy->dev
refcount is not in danger.
Then the PHY is exposed to the outside world using of_phy_provider_register(),
where the fact that the provider driver can concurrently unregister
starts being a problem.
Therefore, I would say that the problem is that consumers, aka phy_get()
callers, can get a phy with a &phy->dev refcount that is not already bumped
by the time they are handed over that PHY.
Mechanically, PHY lookup happens under &phy_provider_mutex, and I
believe it would be sufficient to call get_device() under this lock, in
order for consumers to get PHYs with their reference bumped.
Why?
Let's consider what a PHY provider does when unbinding. It runs the PHY
registration and creation processes in reverse, i.e.
- it calls of_phy_provider_unregister() directly or through devres
- it calls phy_destroy() directly or through devres
Since of_phy_provider_unregister() also acquires &phy_provider_mutex,
this acts like a synchronization barrier. There are 2 cases:
Consumer Provider
phy_get()
-> mutex_lock(&phy_provider_mutex)
-> get_device(&phy->dev) -> 2
-> mutex_unlock(&phy_provider_mutex)
of_phy_provider_unregister()
-> mutex_lock(&phy_provider_mutex)
-> removes phy from list
-> mutex_unlock(&phy_provider_mutex)
phy_destroy()
-> device_unregister(&phy->dev)
-> device_del(dev);
-> put_device(dev); // -> 1
and the consumer remains with a "zombie" PHY device (more later)
Or
Consumer Provider
phy_get()
of_phy_provider_unregister()
-> mutex_lock(&phy_provider_mutex)
-> removes phy from list
-> mutex_unlock(&phy_provider_mutex)
-> mutex_lock(&phy_provider_mutex)
-> doesn't find the PHY device!
It was unpublished even if not freed
-> mutex_unlock(&phy_provider_mutex)
phy_destroy()
-> device_unregister(&phy->dev)
-> device_del(dev);
-> put_device(dev); // -> 1
and the consumer won't be allowed to even find the PHY device in this case.
So this is why get_device() under phy_provider_mutex actually helps.
Now, it is much less important whether you push the get_device() to the
actual of_xlate() PHY vendor implementation or not. For simplicity sake,
I suggest you don't do that, but instead keep it in the core, to
preserve driver API semantics (patch not even compile-tested):
-- >8 --
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index 21aaf2f76e53..c50e38f057a8 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -122,17 +122,19 @@ EXPORT_SYMBOL_GPL(phy_remove_lookup);
static struct phy *phy_find(struct device *dev, const char *con_id)
{
const char *dev_id = dev_name(dev);
- struct phy_lookup *p, *pl = NULL;
+ struct phy *phy = NULL;
+ struct phy_lookup *p;
mutex_lock(&phy_provider_mutex);
list_for_each_entry(p, &phys, node)
if (!strcmp(p->dev_id, dev_id) && !strcmp(p->con_id, con_id)) {
- pl = p;
+ phy = p->phy;
+ get_device(&phy->dev);
break;
}
mutex_unlock(&phy_provider_mutex);
- return pl ? pl->phy : ERR_PTR(-ENODEV);
+ return phy ? phy : ERR_PTR(-ENODEV);
}
static struct phy_provider *of_phy_provider_lookup(struct device_node *node)
@@ -649,6 +651,7 @@ static struct phy *_of_phy_get(struct device_node *np, int index)
}
phy = phy_provider->of_xlate(phy_provider->dev, &args);
+ get_device(&phy->dev);
out_put_module:
module_put(phy_provider->owner);
@@ -682,10 +685,10 @@ struct phy *of_phy_get(struct device_node *np, const char *con_id)
if (IS_ERR(phy))
return phy;
- if (!try_module_get(phy->ops->owner))
+ if (!try_module_get(phy->ops->owner)) {
+ put_device(&phy->dev);
return ERR_PTR(-EPROBE_DEFER);
-
- get_device(&phy->dev);
+ }
return phy;
}
@@ -803,10 +806,10 @@ struct phy *phy_get(struct device *dev, const char *string)
if (IS_ERR(phy))
return phy;
- if (!try_module_get(phy->ops->owner))
+ if (!try_module_get(phy->ops->owner)) {
+ put_device(&phy->dev);
return ERR_PTR(-EPROBE_DEFER);
-
- get_device(&phy->dev);
+ }
link = device_link_add(dev, &phy->dev, DL_FLAG_STATELESS);
if (!link)
@@ -969,11 +972,10 @@ struct phy *devm_of_phy_get_by_index(struct device *dev, struct device_node *np,
if (!try_module_get(phy->ops->owner)) {
devres_free(ptr);
+ put_device(&phy->dev);
return ERR_PTR(-EPROBE_DEFER);
}
- get_device(&phy->dev);
-
*ptr = phy;
devres_add(dev, ptr);
-- >8 --
The patch above leaves a few loose ends.
The most obvious is of_phy_simple_xlate(), which has that put_device()
to balance out class_find_device_by_of_node() - which bumps the device
refcount to 2. It "looks" wrong but it is consistent with vendor
implementations of of_xlate(), which also provide a phy->dev refcount of 1.
And as explained, the refcount never _actually_ drops to 0 with the
above patch.
I would actually address _only_ of_phy_simple_xlate(), for cosmetics sake.
Instead of devm_of_phy_provider_register(..., of_phy_simple_xlate), I
would offer a new helper, devm_of_phy_simple_provider_register(), which
would internally use a callback that doesn't drop the refcount (say
__of_phy_simple_xlate() for lack of imagination). I would convert vendor
PHY drivers one by one to use this (it would be valid at any time to use
either the old or the new method).
You'd notice that most of the of_phy_simple_xlate() occurrences go away,
except for freescale/phy-fsl-lynx-28g.c which calls this function
directly from its own lynx_28g_xlate(). It will still have to keep
calling it, and for refcount equalization purposes that weird
put_device() will have to continue to exist. Just leave a comment as to
why that is.
But there are more important loose ends still.
I mentioned that "zombie" device. We've solved the memory safety issue,
but it's possible for consumers to hold onto a phy whose provider has
disappeared. The refcount of &phy->dev hasn't dropped to 0, so
technically it's a valid object, but from PHY API perspective, it's
still possible to call phy_init(), phy_power_on() and friends on this
PHY, and the Generic PHY core will be happy to further call into the
phy->ops->init(), phy->ops->power_on() etc. But the driver has unbound,
so it should really be left alone.
If we fix the UAF but leave the zombie PHY problem, we've effectively
done nothing but silence static analysis checkers, while the code path
where the PHY provider unbinds effectively remains treated as poorly as
before, just moving the crashes to a different place.
I suspect what needs to be done here is to introduce a "bool dead" or
similar, which is to be set from phy_destroy() and checked from every
API call. The idea is that API functions on zombie PHYs should fail
without calling into their driver. I **suppose** that
try_module_get(phy->ops->owner) "tried" to avoid this situation, but
it just protects against module removal, not against "echo device >
/sys/bus/.../unbind". So it's absolutely incomplete and easily bypassable.
Finally, I have identified one more loose end still.
/**
* of_phy_put() - release the PHY
* @phy: the phy returned by of_phy_get()
*
* Releases a refcount the caller received from of_phy_get().
*/
void of_phy_put(struct phy *phy)
{
if (!phy || IS_ERR(phy))
return;
mutex_lock(&phy->mutex);
if (phy->ops->release)
phy->ops->release(phy);
mutex_unlock(&phy->mutex);
module_put(phy->ops->owner);
put_device(&phy->dev);
}
EXPORT_SYMBOL_GPL(of_phy_put);
This function is called by PHY consumers. A PHY provider can have
multiple consumers (example in the case of Ethernet: a QSGMII SerDes
lane has 4 MAC ports multiplexed onto it).
If a single consumer calls of_phy_put() to release its reference to the
SerDes lane, the phy->ops->release() method makes absolutely no sense.
There are 3 remaining consumers with handles to the lane! But we aren't
even telling the PHY which consumer has disappeared! It has nothing
useful to do with this information.
Looking at actual phy_ops implementations, what they want to know is
when _all_ consumers went away, not when individual consumers did.
So the phy->ops->release() call needs to be put somewhere which is
executed when all consumers disappear. If I were to guess, that would be
the phy_release() class callback, but this is completely untested.
Sorry that this email is a bit long, it got a bit late writing it and I
don't have a lot of energy left to trim it down.
In summary I found 4 highly related problems:
- use after free
- misleading of_phy_simple_xlate() API pattern (not a functional issue)
- zombie PHYs
- premature release call
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
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