* [PATCH v8 1/2] dt-bindings: phy: eswin: Document the EIC7700 SoC SATA PHY
From: Yulin Lu @ 2026-01-23 2:49 UTC (permalink / raw)
To: vkoul, neil.armstrong, robh, krzk+dt, conor+dt, p.zabel,
linux-phy, devicetree, linux-kernel
Cc: ningyu, linmin, fenglin, Yulin Lu
In-Reply-To: <20260123024823.1612-1-luyulin@eswincomputing.com>
Document the SATA PHY on the EIC7700 SoC platform,
describing its usage.
Signed-off-by: Yulin Lu <luyulin@eswincomputing.com>
---
.../bindings/phy/eswin,eic7700-sata-phy.yaml | 96 +++++++++++++++++++
1 file changed, 96 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/eswin,eic7700-sata-phy.yaml
diff --git a/Documentation/devicetree/bindings/phy/eswin,eic7700-sata-phy.yaml b/Documentation/devicetree/bindings/phy/eswin,eic7700-sata-phy.yaml
new file mode 100644
index 000000000000..4bb2d7a53761
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/eswin,eic7700-sata-phy.yaml
@@ -0,0 +1,96 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/eswin,eic7700-sata-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Eswin EIC7700 SoC SATA PHY
+
+maintainers:
+ - Yulin Lu <luyulin@eswincomputing.com>
+ - Huan He <hehuan1@eswincomputing.com>
+
+properties:
+ compatible:
+ const: eswin,eic7700-sata-phy
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ const: phy
+
+ resets:
+ maxItems: 2
+
+ reset-names:
+ items:
+ - const: port
+ - const: phy
+
+ eswin,tx-amplitude-tuning:
+ description: This adjusts the transmitter amplitude signal, and its value
+ is derived from eye diagram tuning. The three values correspond to Gen1,
+ Gen2, and Gen3 parameters respectively.
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ items:
+ - description: Gen1 parameter.
+ minimum: 0
+ maximum: 0x7f
+ default: 0
+ - description: Gen2 parameter.
+ minimum: 0
+ maximum: 0x7f
+ default: 0
+ - description: Gen3 parameter.
+ minimum: 0
+ maximum: 0x7f
+ default: 0
+
+ eswin,tx-preemph-tuning:
+ description: This adjusts the transmitter de-emphasis signal, and its value
+ is derived from eye diagram tuning. The three values correspond to Gen1,
+ Gen2, and Gen3 parameters respectively.
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ items:
+ - description: Gen1 parameter.
+ minimum: 0
+ maximum: 0x3f
+ default: 0
+ - description: Gen2 parameter.
+ minimum: 0
+ maximum: 0x3f
+ default: 0
+ - description: Gen3 parameter.
+ minimum: 0
+ maximum: 0x3f
+ default: 0
+
+ "#phy-cells":
+ const: 0
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - resets
+ - reset-names
+ - "#phy-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ sata-phy@50440300 {
+ compatible = "eswin,eic7700-sata-phy";
+ reg = <0x50440300 0x40>;
+ clocks = <&hspcrg 17>;
+ clock-names = "phy";
+ resets = <&hspcrg 0>, <&hspcrg 1>;
+ reset-names = "port", "phy";
+ #phy-cells = <0>;
+ };
--
2.25.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v8 0/2] Add driver support for Eswin EIC7700 SoC SATA PHY
From: Yulin Lu @ 2026-01-23 2:48 UTC (permalink / raw)
To: vkoul, neil.armstrong, robh, krzk+dt, conor+dt, p.zabel,
linux-phy, devicetree, linux-kernel
Cc: ningyu, linmin, fenglin, Yulin Lu
Updates:
v8 -> v7:
- eswin,eic7700-sata-phy.yaml
- Add "eswin,tx-amplitude-tuning" and "eswin,tx-preemph-tuning"
properties, because these parameters may vary across different
circuit boards.
- Delete reviewed-by tag of Krzysztof Kozlowski, because the tuning
properties are introduced.
- phy-eic7700-sata.c
- Try to get SATA PHY transmitter amplitude and pre-emphasis signal
eye diagram tuning parameters from dts instead of hardcoded values
in the code. Because, these parameters may vary across different
circuit boards. Define default tuning parameters and use it when
these properties are not declared in dts.
- Add a comment to explain the reason for mapping I/O resources with
platform_get_resource and devm_ioremap instead of using the
devm_platform_ioremap_resource API.
- Link to v7: https://lore.kernel.org/lkml/20260106062944.1529-1-luyulin@eswincomputing.com/
v7 -> v6:
- phy-eic7700-sata.c
- Rename PHY_READY_TIMEOUT to PLL_LOCK_TIMEOUT_US with value 1000.
- Add macro PLL_LOCK_SLEEP_US set to 10.
- Add "goto disable_clk" in the eic7700_sata_phy_init function.
- Modify Copyright year from 2024 to 2026.
- Link to v6: https://lore.kernel.org/lkml/20251201060737.868-1-luyulin@eswincomputing.com/
v6 -> v5:
- eswin,eic7700-ahci.yaml
- Delete this file and it has already been applied in reply[1].
- eswin,eic7700-sata-phy.yaml
- Add clock and reset related properties.
- phy-eic7700-sata.c
- Map the io resource with platform_get_resource and devm_ioremap
instead of devm_platform_ioremap_resource API. Because the address
region of sata-phy falls into the region of hsp clock&reset which
has been got by hsp clock&reset driver.
- Use regmap_read_poll_timeout in wait_for_phy_ready to replace the
while loop check.
- Use devm_regmap_init_mmio and regmap_write to replace writel.
- Adapt to the clock and reset driver framework, replacing the
original readl and writel.
Because we are implementing the HSP layer clock and reset drivers,
the corresponding clock and reset registers can be registered into
the driver framework. And I have tested on the Sifive HiFive
Premier P550 board.
- Link to v5: https://lore.kernel.org/lkml/20250930083754.15-1-luyulin@eswincomputing.com/
v5 -> v4:
- eswin,eic7700-ahci.yaml
- Add "dt-bindings: ata:" prefix to the subject.
- Wrap at 80 characters in the YAML description field.
- Link to v4: https://lore.kernel.org/lkml/20250915125902.375-1-luyulin@eswincomputing.com/
v4 -> v3:
- eswin,eic7700-ahci.yaml
- Fix grammatical errors in patch subject and commit message
- Add an explanation in the commit message of patch 1 for retaining
the "ports-implemented" field, which Rob Herring suggested to
remove in the review comments on v2.
Link to Rob Herring's review:
https://lore.kernel.org/lkml/CAL_JsqKFotNLZZXwiy7S6K8qXLdGRAnsa-1zvZRDQBE39Gf5kg@mail.gmail.com/
Link to my question and Niklas Cassel's reply:
https://lore.kernel.org/lkml/aLBUC116MdJqDGIJ@flawful.org/
In this reply, Niklas Cassel mentioned his view:
If the ports-implemented register gets reset from
ahci_platform_assert_rsts(), then it seems acceptable to
retain the ports-implemented property in the device tree.
This aligns with our design.
Link to my reply:
https://lore.kernel.org/lkml/4ab70c6a.8be.198f47da494.Coremail.luyulin@eswincomputing.com/
Link to Niklas Cassel's question and my further explanation:
https://lore.kernel.org/lkml/aLlYkZWBaI5Yz6fo@ryzen/
https://lore.kernel.org/lkml/7206383a.d98.19918c22570.Coremail.luyulin@eswincomputing.com/
- eswin,eic7700-sata-phy.yaml
- Fix grammatical errors in patch subject and commit message
- Adjust the position of reg in the properties and required arrays
- Add reviewed-by tag of Krzysztof Kozlowski
- phy-eic7700-sata.c
- Correct the loop condition in wait_for_phy_ready() to use the
current jiffies instead of the fixed start time.
- Change the return value from -EFAULT to -ETIMEDOUT to correctly
indicate a timeout condition.
- Remove redundant clock disable handling in probe error path, as
SATA_SYS_CLK_EN is managed in phy_init() and phy_exit().
- Use dev_err_probe return in probe.
- Reorder local variables to follow reverse Xmas tree order.
- Wrap each line in the extended comments to 80 columns before
splitting lines.
- Adjust the position of `#include <linux/io.h>` for proper ordering.
- Link to v3: https://lore.kernel.org/lkml/20250904063427.1954-1-luyulin@eswincomputing.com/
v2 -> v3:
- Use full name in "From" and "Signed-off-by" fields information
- eswin,eic7700-ahci.yaml
- Remove the introduction to the reg, interrupts, phys, and
phy-names fields.
- Modify the usage of the clocks field in the examples.
- Correct the order of dt properties.
- phy-eic7700-sata.c
- Register operations use the GENMASK macro and FIELD_PREP instead
of the original bit offset method, and add
"#include <linux/bitfield.h>".
- Modify some macro definition names.
- Remove the redundant initialization assignments for "ret" and
"val".
- Delete ".suppress_bind_attrs = true".
- Modify the driver name.
- Add "#include <linux/io.h>" to fix the robot test issue.
- Link to v2: https://lore.kernel.org/lkml/20250819134722.220-1-luyulin@eswincomputing.com/
v2 -> v1:
- Delete the original controller driver and use ahci_dwc.c instead.
- Add eswin,eic7700-ahci.yaml
- Correct the descriptions of reset, interrupt and other hardware
resources for the sata controller on EIC7700 SoC.
- The clocks for both sata controller and sata PHY are controlled
via a register bit in the HSP bus and are not registered in the
clock tree. Clock are managed within the PHY driver, therefore it
is not described in this document.
- Add $ref: snps,dwc-ahci-common.yaml#.
- Add eswin,eic7700-sata-phy.yaml
- Add this file to include the description of the PHY on EIC7700 SoC.
- Add an eswin directory under the PHY driver path, and include the
SATA PHY driver code for EIC7700 SoC.
- Link to v1: https://lore.kernel.org/all/20250515085114.1692-1-hehuan1@eswincomputing.com/
Yulin Lu (2):
dt-bindings: phy: eswin: Document the EIC7700 SoC SATA PHY
phy: eswin: Create eswin directory and add EIC7700 SATA PHY driver
.../bindings/phy/eswin,eic7700-sata-phy.yaml | 96 ++++++
drivers/phy/Kconfig | 1 +
drivers/phy/Makefile | 1 +
drivers/phy/eswin/Kconfig | 14 +
drivers/phy/eswin/Makefile | 2 +
drivers/phy/eswin/phy-eic7700-sata.c | 273 ++++++++++++++++++
6 files changed, 387 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/eswin,eic7700-sata-phy.yaml
create mode 100644 drivers/phy/eswin/Kconfig
create mode 100644 drivers/phy/eswin/Makefile
create mode 100644 drivers/phy/eswin/phy-eic7700-sata.c
--
2.25.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v3 3/3] dt-bindings: phy: ti,control-phy-otghs: convert to DT schema
From: Rob Herring (Arm) @ 2026-01-22 23:34 UTC (permalink / raw)
To: Charan Pedumuru
Cc: Kishon Vijay Abraham I, linux-kernel, Kevin Hilman,
Andreas Kemnade, Aaro Koskinen, Roger Quadros, Tony Lindgren,
Krzysztof Kozlowski, linux-phy, devicetree, Conor Dooley,
linux-omap, Vinod Koul, Neil Armstrong, Roger Quadros
In-Reply-To: <20260122-ti-phy-v3-3-751619729433@gmail.com>
On Thu, 22 Jan 2026 17:52:59 +0000, Charan Pedumuru wrote:
> Convert TI OMAP Control PHY binding to DT schema.
>
> Signed-off-by: Charan Pedumuru <charan.pedumuru@gmail.com>
> ---
> .../bindings/phy/ti,control-phy-otghs.yaml | 99 ++++++++++++++++++++++
> Documentation/devicetree/bindings/phy/ti-phy.txt | 98 ---------------------
> 2 files changed, 99 insertions(+), 98 deletions(-)
>
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 v3 2/3] dt-bindings: phy: ti,phy-usb3: convert to DT schema
From: Rob Herring @ 2026-01-22 23:33 UTC (permalink / raw)
To: Charan Pedumuru
Cc: Vinod Koul, Neil Armstrong, Krzysztof Kozlowski, Conor Dooley,
Kishon Vijay Abraham I, Aaro Koskinen, Andreas Kemnade,
Kevin Hilman, Roger Quadros, Tony Lindgren, Roger Quadros,
linux-phy, devicetree, linux-kernel, linux-omap
In-Reply-To: <20260122-ti-phy-v3-2-751619729433@gmail.com>
On Thu, Jan 22, 2026 at 05:52:58PM +0000, Charan Pedumuru wrote:
> Convert TI PIPE3 PHY binding to DT schema.
> Changes during conversion:
> - Define a new pattern 'pcie-phy' to match nodes defined in DT.
> - Drop obsolete "id" property from the schema.
>
> Signed-off-by: Charan Pedumuru <charan.pedumuru@gmail.com>
> ---
> .../devicetree/bindings/phy/ti,phy-usb3.yaml | 135 +++++++++++++++++++++
> 1 file changed, 135 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/phy/ti,phy-usb3.yaml b/Documentation/devicetree/bindings/phy/ti,phy-usb3.yaml
> new file mode 100644
> index 000000000000..605f12f0f79a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/ti,phy-usb3.yaml
> @@ -0,0 +1,135 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/phy/ti,phy-usb3.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: TI PIPE3 PHY Module
> +
> +maintainers:
> + - Roger Quadros <rogerq@ti.com>
> +
> +description:
> + The TI PIPE3 PHY is a high-speed SerDes (Serializer/Deserializer)
> + transceiver integrated in OMAP5, DRA7xx/AM57xx, and similar SoCs.
> + It supports multiple protocols (USB3, SATA, PCIe) using the PIPE3
> + interface standard, which defines a common physical layer for
> + high-speed serial interfaces.
> +
> +properties:
> + $nodename:
> + pattern: "^(pcie-phy|usb3-phy|phy)@[0-9a-f]+$"
> +
> + compatible:
> + enum:
> + - ti,omap-usb3
> + - ti,phy-pipe3-pcie
> + - ti,phy-pipe3-sata
> + - ti,phy-usb3
> +
> + reg:
> + minItems: 2
> + maxItems: 3
> +
> + reg-names:
> + minItems: 2
> + items:
> + - const: phy_rx
> + - const: phy_tx
> + - const: pll_ctrl
> +
> + "#phy-cells":
> + const: 0
> +
> + clocks:
> + minItems: 2
> + maxItems: 7
> +
> + clock-names:
> + minItems: 2
> + maxItems: 7
> + items:
> + enum: [wkupclk, sysclk, refclk, dpll_ref,
> + dpll_ref_m2, phy-div, div-clk]
> +
> + syscon-phy-power:
> + $ref: /schemas/types.yaml#/definitions/phandle-array
> + items:
> + items:
> + - description: Phandle to the system control module
> + - description: Register offset controlling PHY power
This allows N entries of 2 cells each. You need either:
items:
- items:
- description: ...
- description: ...
(the hyphen is important!)
Or:
maxItems: 1
items:
items:
- description: ...
- description: ...
> +
> + syscon-pllreset:
> + $ref: /schemas/types.yaml#/definitions/phandle-array
> + items:
> + items:
> + - description: Phandle to the system control module
> + - description: Register offset of CTRL_CORE_SMA_SW_0
> +
> + syscon-pcs:
> + $ref: /schemas/types.yaml#/definitions/phandle-array
> + items:
> + items:
> + - description: Phandle to the system control module
> + - description: Register offset for PCS delay programming
> +
> + ctrl-module:
> + $ref: /schemas/types.yaml#/definitions/phandle
> + description:
> + Phandle of control module for PHY power on.
> + deprecated: true
> +
> +allOf:
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: ti,phy-pipe3-sata
> + then:
> + properties:
> + syscon-pllreset: true
> + else:
> + properties:
> + syscon-pllreset: false
> +
> +required:
> + - reg
> + - compatible
> + - reg-names
> + - "#phy-cells"
> + - clocks
> + - clock-names
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + /* TI PIPE3 USB3 PHY */
> + usb3-phy@4a084400 {
> + compatible = "ti,phy-usb3";
> + reg = <0x4a084400 0x80>,
> + <0x4a084800 0x64>,
> + <0x4a084c00 0x40>;
> + reg-names = "phy_rx", "phy_tx", "pll_ctrl";
> + #phy-cells = <0>;
> + clocks = <&usb_phy_cm_clk32k>,
> + <&sys_clkin>,
> + <&usb_otg_ss_refclk960m>;
> + clock-names = "wkupclk", "sysclk", "refclk";
> + ctrl-module = <&omap_control_usb>;
> + };
> +
> + - |
> + /* TI PIPE3 SATA PHY */
> + phy@4a096000 {
> + compatible = "ti,phy-pipe3-sata";
> + reg = <0x4A096000 0x80>, /* phy_rx */
> + <0x4A096400 0x64>, /* phy_tx */
> + <0x4A096800 0x40>; /* pll_ctrl */
Use lowercase hex.
> + reg-names = "phy_rx", "phy_tx", "pll_ctrl";
> + clocks = <&sys_clkin1>, <&sata_ref_clk>;
> + clock-names = "sysclk", "refclk";
> + syscon-pllreset = <&scm_conf 0x3fc>;
> + #phy-cells = <0>;
> + };
> +...
>
> --
> 2.52.0
>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH next] phy: google: fix build dependency for Google Tensor USB PHY
From: Roy Luo @ 2026-01-22 19:00 UTC (permalink / raw)
To: André Draszik
Cc: Vinod Koul, Neil Armstrong, Peter Griffin, Tudor Ambarus,
Joy Chakraborty, Naveen Kumar, linux-phy, linux-kernel,
linux-arm-kernel, linux-samsung-soc, kernel test robot
In-Reply-To: <7c78f9da40022e7bbf850ae8989c617bdc30cc95.camel@linaro.org>
On Thu, Jan 22, 2026 at 2:39 AM André Draszik <andre.draszik@linaro.org> wrote:
>
> Hi Roy,
>
> On Wed, 2026-01-21 at 22:21 +0000, Roy Luo wrote:
> > The Google Tensor USB PHY driver uses the Type-C switch framework to
> > handle orientation changes. However, the Kconfig did not specify a
> > dependency on the TYPEC framework, leading to undefined reference
> > errors when building for architectures or configurations where
> > CONFIG_TYPEC is disabled or configured as a module.
> >
> > Add 'depends on TYPEC' to the PHY_GOOGLE_USB entry to ensure all
> > required symbols are available during linking.
> >
> > Fixes: cbce66669c82 ("phy: Add Google Tensor SoC USB PHY driver")
> > Reported-by: kernel test robot <lkp@intel.com>
> > Closes: https://lore.kernel.org/oe-kbuild-all/202601210825.ELrpQeED-lkp@intel.com/
> > Signed-off-by: Roy Luo <royluo@google.com>
> > ---
> > drivers/phy/Kconfig | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> > index 142e7b0ef2efb9209781800ee47b820a91b115ae..5531ff31d8156cb164c32e3e52d4a57b26a62d8d 100644
> > --- a/drivers/phy/Kconfig
> > +++ b/drivers/phy/Kconfig
> > @@ -49,6 +49,7 @@ config GENERIC_PHY_MIPI_DPHY
> >
> > config PHY_GOOGLE_USB
> > tristate "Google Tensor SoC USB PHY driver"
> > + depends on TYPEC
>
> Can you make this
>
> depends on TYPEC || COMPILE_TEST
>
> to allow some better test coverage?
>
> Cheers,
> Andre
Hi Andre,
Whether to add COMPILE_TEST for build coverage was discussed in
another thread [1]. My takeaway from that discussion is that
COMPILE_TEST is intended to substitute for ARCH_XXX in build
testing and should not be used without it. Once ARCH_GOOGLE is
present, we can add "depends on (ARCH_GOOGLE || COMPILTE_TEST)".
[1] https://lore.kernel.org/all/CA+zupgwgfKwPYqj8G2tNf4pEXNEWA+vL2WYJPhJ16xExgko7Dw@mail.gmail.com/
Regards,
Roy
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH v3 3/3] dt-bindings: phy: ti,control-phy-otghs: convert to DT schema
From: Charan Pedumuru @ 2026-01-22 17:52 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Kishon Vijay Abraham I, Aaro Koskinen,
Andreas Kemnade, Kevin Hilman, Roger Quadros, Tony Lindgren,
Roger Quadros
Cc: linux-phy, devicetree, linux-kernel, linux-omap, Charan Pedumuru
In-Reply-To: <20260122-ti-phy-v3-0-751619729433@gmail.com>
Convert TI OMAP Control PHY binding to DT schema.
Signed-off-by: Charan Pedumuru <charan.pedumuru@gmail.com>
---
.../bindings/phy/ti,control-phy-otghs.yaml | 99 ++++++++++++++++++++++
Documentation/devicetree/bindings/phy/ti-phy.txt | 98 ---------------------
2 files changed, 99 insertions(+), 98 deletions(-)
diff --git a/Documentation/devicetree/bindings/phy/ti,control-phy-otghs.yaml b/Documentation/devicetree/bindings/phy/ti,control-phy-otghs.yaml
new file mode 100644
index 000000000000..4ecb1611ee65
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/ti,control-phy-otghs.yaml
@@ -0,0 +1,99 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/ti,control-phy-otghs.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI OMAP Control PHY Module
+
+maintainers:
+ - Roger Quadros <rogerq@ti.com>
+
+description:
+ The TI OMAP Control PHY module is a hardware block within the system
+ control module (SCM) of Texas Instruments OMAP SoCs. It provides
+ centralized control over power, configuration, and auxiliary features
+ for multiple on-chip PHYs. This module is essential for proper PHY
+ operation in power-constrained embedded systems.
+
+properties:
+ $nodename:
+ pattern: "^phy@[0-9a-f]+$"
+
+ compatible:
+ enum:
+ - ti,control-phy-otghs
+ - ti,control-phy-pcie
+ - ti,control-phy-pipe3
+ - ti,control-phy-usb2
+ - ti,control-phy-usb2-am437
+ - ti,control-phy-usb2-dra7
+
+ reg:
+ minItems: 1
+ maxItems: 3
+
+ reg-names:
+ minItems: 1
+ maxItems: 3
+ items:
+ enum: [otghs_control, power, pcie_pcs, control_sma]
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - ti,control-phy-otghs
+ then:
+ properties:
+ reg-names:
+ const: otghs_control
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - ti,control-phy-pcie
+ then:
+ properties:
+ reg:
+ minItems: 3
+
+ reg-names:
+ items:
+ - const: power
+ - const: pcie_pcs
+ - const: control_sma
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - ti,control-phy-usb2
+ - ti,control-phy-usb2-dra7
+ - ti,control-phy-usb2-am437
+ - ti,control-phy-pipe3
+ then:
+ properties:
+ reg-names:
+ const: power
+
+required:
+ - reg
+ - compatible
+ - reg-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ phy@4a00233c {
+ compatible = "ti,control-phy-otghs";
+ reg = <0x4a00233c 0x4>;
+ reg-names = "otghs_control";
+ };
+...
diff --git a/Documentation/devicetree/bindings/phy/ti-phy.txt b/Documentation/devicetree/bindings/phy/ti-phy.txt
deleted file mode 100644
index 7c7936b89f2c..000000000000
--- a/Documentation/devicetree/bindings/phy/ti-phy.txt
+++ /dev/null
@@ -1,98 +0,0 @@
-TI PHY: DT DOCUMENTATION FOR PHYs in TI PLATFORMs
-
-OMAP CONTROL PHY
-
-Required properties:
- - compatible: Should be one of
- "ti,control-phy-otghs" - if it has otghs_control mailbox register as on OMAP4.
- "ti,control-phy-usb2" - if it has Power down bit in control_dev_conf register
- e.g. USB2_PHY on OMAP5.
- "ti,control-phy-pipe3" - if it has DPLL and individual Rx & Tx power control
- e.g. USB3 PHY and SATA PHY on OMAP5.
- "ti,control-phy-pcie" - for pcie to support external clock for pcie and to
- set PCS delay value.
- e.g. PCIE PHY in DRA7x
- "ti,control-phy-usb2-dra7" - if it has power down register like USB2 PHY on
- DRA7 platform.
- "ti,control-phy-usb2-am437" - if it has power down register like USB2 PHY on
- AM437 platform.
- - reg : register ranges as listed in the reg-names property
- - reg-names: "otghs_control" for control-phy-otghs
- "power", "pcie_pcs" and "control_sma" for control-phy-pcie
- "power" for all other types
-
-omap_control_usb: omap-control-usb@4a002300 {
- compatible = "ti,control-phy-otghs";
- reg = <0x4a00233c 0x4>;
- reg-names = "otghs_control";
-};
-
-TI PIPE3 PHY
-
-Required properties:
- - compatible: Should be "ti,phy-usb3", "ti,phy-pipe3-sata" or
- "ti,phy-pipe3-pcie. "ti,omap-usb3" is deprecated.
- - reg : Address and length of the register set for the device.
- - reg-names: The names of the register addresses corresponding to the registers
- filled in "reg".
- - #phy-cells: determine the number of cells that should be given in the
- phandle while referencing this phy.
- - clocks: a list of phandles and clock-specifier pairs, one for each entry in
- clock-names.
- - clock-names: should include:
- * "wkupclk" - wakeup clock.
- * "sysclk" - system clock.
- * "refclk" - reference clock.
- * "dpll_ref" - external dpll ref clk
- * "dpll_ref_m2" - external dpll ref clk
- * "phy-div" - divider for apll
- * "div-clk" - apll clock
-
-Optional properties:
- - id: If there are multiple instance of the same type, in order to
- differentiate between each instance "id" can be used (e.g., multi-lane PCIe
- PHY). If "id" is not provided, it is set to default value of '1'.
- - syscon-pllreset: Handle to system control region that contains the
- CTRL_CORE_SMA_SW_0 register and register offset to the CTRL_CORE_SMA_SW_0
- register that contains the SATA_PLL_SOFT_RESET bit. Only valid for sata_phy.
- - syscon-pcs : phandle/offset pair. Phandle to the system control module and the
- register offset to write the PCS delay value.
-
-Deprecated properties:
- - ctrl-module : phandle of the control module used by PHY driver to power on
- the PHY.
-
-Recommended properties:
- - syscon-phy-power : phandle/offset pair. Phandle to the system control
- module and the register offset to power on/off the PHY.
-
-This is usually a subnode of ocp2scp to which it is connected.
-
-usb3phy@4a084400 {
- compatible = "ti,phy-usb3";
- reg = <0x4a084400 0x80>,
- <0x4a084800 0x64>,
- <0x4a084c00 0x40>;
- reg-names = "phy_rx", "phy_tx", "pll_ctrl";
- ctrl-module = <&omap_control_usb>;
- #phy-cells = <0>;
- clocks = <&usb_phy_cm_clk32k>,
- <&sys_clkin>,
- <&usb_otg_ss_refclk960m>;
- clock-names = "wkupclk",
- "sysclk",
- "refclk";
-};
-
-sata_phy: phy@4a096000 {
- compatible = "ti,phy-pipe3-sata";
- reg = <0x4A096000 0x80>, /* phy_rx */
- <0x4A096400 0x64>, /* phy_tx */
- <0x4A096800 0x40>; /* pll_ctrl */
- reg-names = "phy_rx", "phy_tx", "pll_ctrl";
- ctrl-module = <&omap_control_sata>;
- clocks = <&sys_clkin1>, <&sata_ref_clk>;
- clock-names = "sysclk", "refclk";
- syscon-pllreset = <&scm_conf 0x3fc>;
- #phy-cells = <0>;
-};
--
2.52.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/3] dt-bindings: phy: ti,phy-usb3: convert to DT schema
From: Charan Pedumuru @ 2026-01-22 17:52 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Kishon Vijay Abraham I, Aaro Koskinen,
Andreas Kemnade, Kevin Hilman, Roger Quadros, Tony Lindgren,
Roger Quadros
Cc: linux-phy, devicetree, linux-kernel, linux-omap, Charan Pedumuru
In-Reply-To: <20260122-ti-phy-v3-0-751619729433@gmail.com>
Convert TI PIPE3 PHY binding to DT schema.
Changes during conversion:
- Define a new pattern 'pcie-phy' to match nodes defined in DT.
- Drop obsolete "id" property from the schema.
Signed-off-by: Charan Pedumuru <charan.pedumuru@gmail.com>
---
.../devicetree/bindings/phy/ti,phy-usb3.yaml | 135 +++++++++++++++++++++
1 file changed, 135 insertions(+)
diff --git a/Documentation/devicetree/bindings/phy/ti,phy-usb3.yaml b/Documentation/devicetree/bindings/phy/ti,phy-usb3.yaml
new file mode 100644
index 000000000000..605f12f0f79a
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/ti,phy-usb3.yaml
@@ -0,0 +1,135 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/ti,phy-usb3.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI PIPE3 PHY Module
+
+maintainers:
+ - Roger Quadros <rogerq@ti.com>
+
+description:
+ The TI PIPE3 PHY is a high-speed SerDes (Serializer/Deserializer)
+ transceiver integrated in OMAP5, DRA7xx/AM57xx, and similar SoCs.
+ It supports multiple protocols (USB3, SATA, PCIe) using the PIPE3
+ interface standard, which defines a common physical layer for
+ high-speed serial interfaces.
+
+properties:
+ $nodename:
+ pattern: "^(pcie-phy|usb3-phy|phy)@[0-9a-f]+$"
+
+ compatible:
+ enum:
+ - ti,omap-usb3
+ - ti,phy-pipe3-pcie
+ - ti,phy-pipe3-sata
+ - ti,phy-usb3
+
+ reg:
+ minItems: 2
+ maxItems: 3
+
+ reg-names:
+ minItems: 2
+ items:
+ - const: phy_rx
+ - const: phy_tx
+ - const: pll_ctrl
+
+ "#phy-cells":
+ const: 0
+
+ clocks:
+ minItems: 2
+ maxItems: 7
+
+ clock-names:
+ minItems: 2
+ maxItems: 7
+ items:
+ enum: [wkupclk, sysclk, refclk, dpll_ref,
+ dpll_ref_m2, phy-div, div-clk]
+
+ syscon-phy-power:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ items:
+ items:
+ - description: Phandle to the system control module
+ - description: Register offset controlling PHY power
+
+ syscon-pllreset:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ items:
+ items:
+ - description: Phandle to the system control module
+ - description: Register offset of CTRL_CORE_SMA_SW_0
+
+ syscon-pcs:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ items:
+ items:
+ - description: Phandle to the system control module
+ - description: Register offset for PCS delay programming
+
+ ctrl-module:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ Phandle of control module for PHY power on.
+ deprecated: true
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: ti,phy-pipe3-sata
+ then:
+ properties:
+ syscon-pllreset: true
+ else:
+ properties:
+ syscon-pllreset: false
+
+required:
+ - reg
+ - compatible
+ - reg-names
+ - "#phy-cells"
+ - clocks
+ - clock-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ /* TI PIPE3 USB3 PHY */
+ usb3-phy@4a084400 {
+ compatible = "ti,phy-usb3";
+ reg = <0x4a084400 0x80>,
+ <0x4a084800 0x64>,
+ <0x4a084c00 0x40>;
+ reg-names = "phy_rx", "phy_tx", "pll_ctrl";
+ #phy-cells = <0>;
+ clocks = <&usb_phy_cm_clk32k>,
+ <&sys_clkin>,
+ <&usb_otg_ss_refclk960m>;
+ clock-names = "wkupclk", "sysclk", "refclk";
+ ctrl-module = <&omap_control_usb>;
+ };
+
+ - |
+ /* TI PIPE3 SATA PHY */
+ phy@4a096000 {
+ compatible = "ti,phy-pipe3-sata";
+ reg = <0x4A096000 0x80>, /* phy_rx */
+ <0x4A096400 0x64>, /* phy_tx */
+ <0x4A096800 0x40>; /* pll_ctrl */
+ reg-names = "phy_rx", "phy_tx", "pll_ctrl";
+ clocks = <&sys_clkin1>, <&sata_ref_clk>;
+ clock-names = "sysclk", "refclk";
+ syscon-pllreset = <&scm_conf 0x3fc>;
+ #phy-cells = <0>;
+ };
+...
--
2.52.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v3 1/3] arm: dts: ti: omap: align node patterns with established convention
From: Charan Pedumuru @ 2026-01-22 17:52 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Kishon Vijay Abraham I, Aaro Koskinen,
Andreas Kemnade, Kevin Hilman, Roger Quadros, Tony Lindgren,
Roger Quadros
Cc: linux-phy, devicetree, linux-kernel, linux-omap, Charan Pedumuru
In-Reply-To: <20260122-ti-phy-v3-0-751619729433@gmail.com>
Update OMAP DTS node patterns to match established conventions.
Signed-off-by: Charan Pedumuru <charan.pedumuru@gmail.com>
---
arch/arm/boot/dts/ti/omap/dra7-l4.dtsi | 4 ++--
arch/arm/boot/dts/ti/omap/omap4-l4.dtsi | 4 ++--
arch/arm/boot/dts/ti/omap/omap5-l4.dtsi | 2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/ti/omap/dra7-l4.dtsi b/arch/arm/boot/dts/ti/omap/dra7-l4.dtsi
index c9282f57ffa5..ed206eb84d02 100644
--- a/arch/arm/boot/dts/ti/omap/dra7-l4.dtsi
+++ b/arch/arm/boot/dts/ti/omap/dra7-l4.dtsi
@@ -328,7 +328,7 @@ ocp2scp@0 {
ranges = <0 0 0x8000>;
reg = <0x0 0x20>;
- pcie1_phy: pciephy@4000 {
+ pcie1_phy: pcie-phy@4000 {
compatible = "ti,phy-pipe3-pcie";
reg = <0x4000 0x80>, /* phy_rx */
<0x4400 0x64>; /* phy_tx */
@@ -348,7 +348,7 @@ pcie1_phy: pciephy@4000 {
#phy-cells = <0>;
};
- pcie2_phy: pciephy@5000 {
+ pcie2_phy: pcie-phy@5000 {
compatible = "ti,phy-pipe3-pcie";
reg = <0x5000 0x80>, /* phy_rx */
<0x5400 0x64>; /* phy_tx */
diff --git a/arch/arm/boot/dts/ti/omap/omap4-l4.dtsi b/arch/arm/boot/dts/ti/omap/omap4-l4.dtsi
index 4ee53dfb71b4..d8b16cbe6c35 100644
--- a/arch/arm/boot/dts/ti/omap/omap4-l4.dtsi
+++ b/arch/arm/boot/dts/ti/omap/omap4-l4.dtsi
@@ -72,13 +72,13 @@ scm_conf: scm_conf@0 {
#size-cells = <1>;
};
- omap_control_usb2phy: control-phy@300 {
+ omap_control_usb2phy: phy@300 {
compatible = "ti,control-phy-usb2";
reg = <0x300 0x4>;
reg-names = "power";
};
- omap_control_usbotg: control-phy@33c {
+ omap_control_usbotg: phy@33c {
compatible = "ti,control-phy-otghs";
reg = <0x33c 0x4>;
reg-names = "otghs_control";
diff --git a/arch/arm/boot/dts/ti/omap/omap5-l4.dtsi b/arch/arm/boot/dts/ti/omap/omap5-l4.dtsi
index 9f6100c7c34d..5c94db589dd1 100644
--- a/arch/arm/boot/dts/ti/omap/omap5-l4.dtsi
+++ b/arch/arm/boot/dts/ti/omap/omap5-l4.dtsi
@@ -472,7 +472,7 @@ usb2_phy: usb2phy@4000 {
#phy-cells = <0>;
};
- usb3_phy: usb3phy@4400 {
+ usb3_phy: usb3-phy@4400 {
compatible = "ti,omap-usb3";
reg = <0x4400 0x80>,
<0x4800 0x64>,
--
2.52.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v3 0/3] dt-bindings: phy: Convert TI OMAP control and PIPE3 PHY to DT schema
From: Charan Pedumuru @ 2026-01-22 17:52 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Kishon Vijay Abraham I, Aaro Koskinen,
Andreas Kemnade, Kevin Hilman, Roger Quadros, Tony Lindgren,
Roger Quadros
Cc: linux-phy, devicetree, linux-kernel, linux-omap, Charan Pedumuru
This series converts the old text-based DeviceTree bindings for TI OMAP
Control PHY and TI PIPE3 PHY to modern JSON-schema (YAML) format.
Signed-off-by: Charan Pedumuru <charan.pedumuru@gmail.com>
---
Changes in v3:
- Change maintainer to "Roger Quadros" for both YAML files.
- dts: Split node pattern updates into a separate patch and align node
naming with standard conventions.
- ti,phy-usb3: Update node pattern to follow standard conventions.
- ti,phy-usb3: Refine the reg-names property and add constraints for
optional phandle-array properties.
- ti,phy-usb3: Redefine "syscon-pllreset" dependency on the compatible
"ti,phy-pipe3-sata" in a correct format.
- ti,control-phy-otghs: Update node pattern and adjust maxItems for reg
and reg-names.
- ti,control-phy-otghs: Fix the conditional handling for the
ti,control-phy-pcie compatible.
- Link to v2: https://lore.kernel.org/r/20260107-ti-phy-v2-0-a1ec27401fff@gmail.com
Changes in v2:
- ti,control-phy-otghs: Update commit message to reflect the latest
binding changes.
- ti,phy-usb3: Drop the obsolete "id" property from the schema.
- Both bindings: Update maintainers list, modify node pattern and improve
node descriptions for clarity.
- ti,phy-usb3: Introduce new YAML schema with properly defined optional
properties for the PIPE3 PHY.
- Link to v1: https://lore.kernel.org/r/20260103-ti-phy-v1-1-8c3f5e2cbd63@gmail.com
---
Charan Pedumuru (3):
arm: dts: ti: omap: align node patterns with established convention
dt-bindings: phy: ti,phy-usb3: convert to DT schema
dt-bindings: phy: ti,control-phy-otghs: convert to DT schema
.../bindings/phy/ti,control-phy-otghs.yaml | 99 +++++++++++++++
.../devicetree/bindings/phy/ti,phy-usb3.yaml | 135 +++++++++++++++++++++
Documentation/devicetree/bindings/phy/ti-phy.txt | 98 ---------------
arch/arm/boot/dts/ti/omap/dra7-l4.dtsi | 4 +-
arch/arm/boot/dts/ti/omap/omap4-l4.dtsi | 4 +-
arch/arm/boot/dts/ti/omap/omap5-l4.dtsi | 2 +-
6 files changed, 239 insertions(+), 103 deletions(-)
---
base-commit: cc3aa43b44bdb43dfbac0fcb51c56594a11338a8
change-id: 20251231-ti-phy-58bb9e38cfc9
Best regards,
--
Charan Pedumuru <charan.pedumuru@gmail.com>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 2/6] phy: qcom: qmp-usbc: Fix possible NULL-deref on early runtime suspend
From: Konrad Dybcio @ 2026-01-22 15:00 UTC (permalink / raw)
To: Loic Poulain, vkoul, kishon
Cc: linux-arm-msm, linux-phy, dmitry.baryshkov, neil.armstrong
In-Reply-To: <20260121142827.2583-3-loic.poulain@oss.qualcomm.com>
On 1/21/26 3:28 PM, Loic Poulain wrote:
> There is a small window where the runtime suspend callback may run
> after pm_runtime_enable() and before pm_runtime_forbid(). In this
> case, a crash occurs because runtime suspend/resume dereferences
> qmp->phy pointer, which is not yet initialized:
> `if (!qmp->phy->init_count) {`
>
> This can also occur if user re-enables runtime-pm via the sysfs
> attribute before qmp phy is initialized.
>
> Use qmp->usb_init_count instead of qmp->phy->init_count to avoid
> depending on the possibly uninitialized phy pointer.
>
> Fixes: 19281571a4d5 ("phy: qcom: qmp-usb: split USB-C PHY driver")
> Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
> ---
> drivers/phy/qualcomm/phy-qcom-qmp-usbc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-usbc.c b/drivers/phy/qualcomm/phy-qcom-qmp-usbc.c
> index 5e7fcb26744a..edfaa14db967 100644
> --- a/drivers/phy/qualcomm/phy-qcom-qmp-usbc.c
> +++ b/drivers/phy/qualcomm/phy-qcom-qmp-usbc.c
> @@ -690,7 +690,7 @@ static int __maybe_unused qmp_usbc_runtime_suspend(struct device *dev)
>
> dev_vdbg(dev, "Suspending QMP phy, mode:%d\n", qmp->mode);
>
> - if (!qmp->phy->init_count) {
> + if (!qmp->usb_init_count) {
This function changed a month ago, please rebase against next
Although I believe this patch becomes unnecessary with 3 in the picture.
I suppose the case that you mention in the commit message, however
improbable, could be fixed by moving the pm call to after devm_phy_create
Although we'd then rely on devlink to make sure a consumer doesn't snatch
the reference halfway through .probe...
Konrad
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 6/6] phy: qcom: snps-femto-v2: Fix possible NULL-deref on early runtime suspend
From: Konrad Dybcio @ 2026-01-22 14:53 UTC (permalink / raw)
To: Loic Poulain, vkoul, kishon
Cc: linux-arm-msm, linux-phy, dmitry.baryshkov, neil.armstrong
In-Reply-To: <20260121142827.2583-7-loic.poulain@oss.qualcomm.com>
On 1/21/26 3:28 PM, Loic Poulain wrote:
> Enabling runtime PM before attaching the hsphy instance as driver data
> can lead to a NULL pointer dereference in runtime PM callbacks that
> expect valid driver data. There is a small window where the suspend
> callback may run after PM runtime enabling and before runtime forbid.
>
> Attach the hsphy instance as driver data before enabling runtime PM to
> prevent NULL pointer dereference in runtime PM callbacks.
>
> Reorder pm_runtime_enable() and pm_runtime_forbid() to prevent a
> short window where an unnecessary runtime suspend can occur.
>
> Use the devres-managed version to ensure PM runtime is symmetrically
> disabled during driver removal for proper cleanup.
>
> Fixes: 0d75f508a9d5 ("phy: qcom-snps: Add runtime suspend and resume handlers")
> Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 5/6] phy: qcom: qmp-usb-legacy: Prevent unnecessary PM runtime suspend at boot
From: Konrad Dybcio @ 2026-01-22 14:53 UTC (permalink / raw)
To: Loic Poulain, vkoul, kishon
Cc: linux-arm-msm, linux-phy, dmitry.baryshkov, neil.armstrong
In-Reply-To: <20260121142827.2583-6-loic.poulain@oss.qualcomm.com>
On 1/21/26 3:28 PM, Loic Poulain wrote:
> There is a small window where the device can suspend after
> pm_runtime_enable() and before pm_runtime_forbid(), causing an
> unnecessary suspend/resume cycle while the PHY is not yet registered.
>
> Move pm_runtime_forbid() before pm_runtime_enable() to eliminate
> this race.
>
> Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 3/6] phy: qcom: qmp-usbc: Prevent unnecessary PM runtime suspend at boot
From: Konrad Dybcio @ 2026-01-22 14:53 UTC (permalink / raw)
To: Loic Poulain, vkoul, kishon
Cc: linux-arm-msm, linux-phy, dmitry.baryshkov, neil.armstrong
In-Reply-To: <20260121142827.2583-4-loic.poulain@oss.qualcomm.com>
On 1/21/26 3:28 PM, Loic Poulain wrote:
> There is a small window where the device can suspend after
> pm_runtime_enable() and before pm_runtime_forbid(), causing an
> unnecessary suspend/resume cycle while the PHY is not yet registered.
>
> Move pm_runtime_forbid() before pm_runtime_enable() to eliminate
> this race.
>
> Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 1/6] phy: qcom: qmp-combo: Prevent unnecessary PM runtime suspend at boot
From: Konrad Dybcio @ 2026-01-22 14:52 UTC (permalink / raw)
To: Loic Poulain, vkoul, kishon
Cc: linux-arm-msm, linux-phy, dmitry.baryshkov, neil.armstrong
In-Reply-To: <20260121142827.2583-2-loic.poulain@oss.qualcomm.com>
On 1/21/26 3:28 PM, Loic Poulain wrote:
> There is a small window where the device can suspend after
> pm_runtime_enable() and before pm_runtime_forbid(), causing an
> unnecessary suspend/resume cycle while the PHY is not yet registered.
>
> Move pm_runtime_forbid() before pm_runtime_enable() to eliminate
> this race.
>
> Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 9/9] arm64: dts: renesas: ebisu: Describe PCIe/USB3.0 clock generator
From: Marek Vasut @ 2026-01-22 10:56 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Mark Brown, linux-arm-kernel, Conor Dooley, Krzysztof Kozlowski,
Magnus Damm, Neil Armstrong, Rob Herring, Vinod Koul,
Yoshihiro Shimoda, devicetree, linux-phy, linux-renesas-soc
In-Reply-To: <CAMuHMdX0iuyUhGRPFf4x==e_ZEMjaB_dP6mrM81F+yxqwam0FA@mail.gmail.com>
On 1/22/26 11:24 AM, Geert Uytterhoeven wrote:
Hello Geert,
>> This piece of code in drivers/usb/phy/phy-generic.c [1] shouldn't fail
>> the probe if "vbus-supply" property is not present in DT. If
>> "vbus-supply" property is not present in DT, then
>> PTR_ERR(nop->vbus_draw) == -ENODEV is true, nop->vbus_draw will be set
>> to NULL, but won't encode error, so the dev_err_probe() won't trigger.
>>
>> "
>> 259 nop->vbus_draw = devm_regulator_get_exclusive(dev, "vbus");
>> 260 if (PTR_ERR(nop->vbus_draw) == -ENODEV)
>> 261 nop->vbus_draw = NULL;
>> 262 if (IS_ERR(nop->vbus_draw))
>> 263 return dev_err_probe(dev, PTR_ERR(nop->vbus_draw),
>> 264 "could not get vbus regulator\n");
>> "
>>
>> [1]
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/usb/phy/phy-generic.c#n259
>
> Sorry, you are right. I missed the PHY driver ignores the error and
> probes successfully, and thus didn't bother doing "echo ee000000.usb >
> /sys/bus/platform/drivers/xhci-renesas-hcd/bind" after /lib/firmware
> became available.
Is any change needed to this series then ?
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [net-next,05/14] net: stmmac: add stmmac core serdes support
From: Vladimir Oltean @ 2026-01-22 11:29 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: Jakub Kicinski, linux-phy, davem, maxime.chevallier,
alexandre.torgue, mohd.anwar, neil.armstrong, hkallweit1,
mcoquelin.stm32, netdev, edumazet, linux-arm-msm,
linux-arm-kernel, vkoul, andrew, pabeni, andrew+netdev,
linux-stm32
In-Reply-To: <aXEN6B5_T9uFzVvu@shell.armlinux.org.uk>
On Wed, Jan 21, 2026 at 05:33:28PM +0000, Russell King (Oracle) wrote:
> On Wed, Jan 21, 2026 at 06:23:45PM +0200, Vladimir Oltean wrote:
> > On Wed, Jan 21, 2026 at 02:46:42PM +0000, Russell King (Oracle) wrote:
> > > On Tue, Jan 20, 2026 at 02:11:14PM +0200, Vladimir Oltean wrote:
> > > > On Tue, Jan 20, 2026 at 10:12:46AM +0000, Russell King (Oracle) wrote:
> > > > > First, I'll say I'm on a very short fuse today; no dinner last night,
> > > > > at the hospital up until 5:30am, and a fucking cold caller rang the door
> > > > > bell at 10am this morning. Just fucking our luck.
> > > >
> > > > Sorry to hear that.
> > > >
> > > > > On Tue, Jan 20, 2026 at 10:18:44AM +0200, Vladimir Oltean wrote:
> > > > > > Isn't it sufficient to set pl->pcs to NULL when pcs_enable() fails and
> > > > > > after calling pcs_disable(), though?
> > > > >
> > > > > No. We've already called mac_prepare(), pcs_pre_config(),
> > > > > pcs_post_config() by this time, we're past the point of being able to
> > > > > unwind.
> > > >
> > > > I'm set out to resolve a much smaller problem.
> > > >
> > > > Calling it a full "unwind" is perhaps a bit much, because pcs_pre_config()
> > > > and pcs_post_config() don't have unwinding equivalents, unlike how
> > > > pcs_enable() has pcs_disable(). I don't see what API convention would be
> > > > violated if phylink decided to drop a PCS whose enable() returned an error.
> > >
> > > While pcs_pre_config() and pcs_post_config() do not have unwinding
> > > equivalents (what would they be?) the issue here is that these could
> > > have changed any state that isn't simply undone by calling
> > > pcs_disable().
> > >
> > > For example, pcs_pre_config() could have reprogrammed signal routing,
> > > clocking, or power supplies to blocks.
> > >
> > > This already applies to Marvell DSA pcs-639x.c, where the pre/post
> > > config hooks change the power state of the PCS block (for errata
> > > handling), and the only way that gets undone is via a call to
> > > pcs_disable() which explicitly disables IRQs and power for the PCS. Its
> > > pcs_disable() isn't a strict reversal of pcs_enable(), it does more.
> > >
> > > We already declare the interface to be dead on pcs_post_config()
> > > failure, but we don't do that for pcs_enable() failure.
> > >
> > > Maybe I need to explicitly state that pcs_disable() does not directly
> > > balance pcs_enable(), but that _and_ the effects of pcs_pre_config()
> > > and pcs_post_config(). However, that itself will add to the problems.
> > > What if pcs_pre_config() and pcs_post_config() succeed but not
> > > pcs_enable()? pcs-639x needs pcs_disable() to be called, but if we
> > > require pcs_disable() to be balanced with a successful call to
> > > pcs_enable(), that messes up that driver, and pretty much makes it
> > > impossible to work around the errata.
> >
> > What if we reordered phylink_major_config() such that phylink_pcs_enable()
> > comes first, followed by phylink_pcs_pre_config() -> phylink_mac_config() ->
> > phylink_pcs_post_config()? Superficially looking at pcs-639x, I don't
> > think it would break.
>
> I'm sorry, but I don't have time to continue this discussion today. I
> woke late, we're trying to cram in the meals (in the middle of delayed
> lunch-time dinner right now), work wants a quick call to discuss a
> project that I missed the meeting for yesterday (which I haven't yet
> had time for...)
>
> Sorry, but while you may wish to get this sorted, for me this is a very
> low priority issue that can be addressed later. Don't think I will have
> time to review anything you send - and that's not a personal attack,
> it's because I'm barely managing to hold everything together at my
> end, and I don't have the time.
Thanks, this was a good talk, I understood a bit more about the
challenges that need to be overcome. I'll do some testing on the
Turris MOX with a 6390 switch. From my side this shouldn't block the
stmmac integrated PCS from being integrated with the SerDes, but I do
agree that leaving a comment explaining the current phylink_pcs calling
convention, as Jakub requested, would be very useful.
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH next] phy: google: fix build dependency for Google Tensor USB PHY
From: André Draszik @ 2026-01-22 10:39 UTC (permalink / raw)
To: Roy Luo, Vinod Koul, Neil Armstrong, Peter Griffin, Tudor Ambarus,
Joy Chakraborty, Naveen Kumar
Cc: linux-phy, linux-kernel, linux-arm-kernel, linux-samsung-soc,
kernel test robot
In-Reply-To: <20260121-next-v1-1-c18068b091b9@google.com>
Hi Roy,
On Wed, 2026-01-21 at 22:21 +0000, Roy Luo wrote:
> The Google Tensor USB PHY driver uses the Type-C switch framework to
> handle orientation changes. However, the Kconfig did not specify a
> dependency on the TYPEC framework, leading to undefined reference
> errors when building for architectures or configurations where
> CONFIG_TYPEC is disabled or configured as a module.
>
> Add 'depends on TYPEC' to the PHY_GOOGLE_USB entry to ensure all
> required symbols are available during linking.
>
> Fixes: cbce66669c82 ("phy: Add Google Tensor SoC USB PHY driver")
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202601210825.ELrpQeED-lkp@intel.com/
> Signed-off-by: Roy Luo <royluo@google.com>
> ---
> drivers/phy/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index 142e7b0ef2efb9209781800ee47b820a91b115ae..5531ff31d8156cb164c32e3e52d4a57b26a62d8d 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -49,6 +49,7 @@ config GENERIC_PHY_MIPI_DPHY
>
> config PHY_GOOGLE_USB
> tristate "Google Tensor SoC USB PHY driver"
> + depends on TYPEC
Can you make this
depends on TYPEC || COMPILE_TEST
to allow some better test coverage?
Cheers,
Andre
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 9/9] arm64: dts: renesas: ebisu: Describe PCIe/USB3.0 clock generator
From: Geert Uytterhoeven @ 2026-01-22 10:24 UTC (permalink / raw)
To: Marek Vasut
Cc: Mark Brown, linux-arm-kernel, Conor Dooley, Krzysztof Kozlowski,
Magnus Damm, Neil Armstrong, Rob Herring, Vinod Koul,
Yoshihiro Shimoda, devicetree, linux-phy, linux-renesas-soc
In-Reply-To: <6f817993-1b4a-4600-a771-d6c25efc668b@mailbox.org>
Hi Marek,
On Wed, 21 Jan 2026 at 23:44, Marek Vasut <marek.vasut@mailbox.org> wrote:
> On 1/21/26 2:48 PM, Geert Uytterhoeven wrote:
> >> @@ -871,7 +902,19 @@ &usb2_phy0 {
> >> status = "okay";
> >> };
> >>
> >> +&usb3_phy0 {
> >> + clocks = <&pcie_usb_clk 6>;
> >> + status = "okay";
> >> +};
> >
> > This does not work, probing fails with:
> >
> > usb_phy_generic usb-phy: dummy supplies not allowed for exclusive
> > requests (id=vbus)
> >
> > Adding a fixed regulator that serves as vbus-supply like in commit
> > fec2d8fcdedaeeb0 ("arm64: dts: freescale: imx93-phyboard-nash: Add USB
> > vbus regulators") fixes that issue (and my USB3.0 FLASH driver is
> > detected, yeah!), but a more accurate description would be better.
>
> This piece of code in drivers/usb/phy/phy-generic.c [1] shouldn't fail
> the probe if "vbus-supply" property is not present in DT. If
> "vbus-supply" property is not present in DT, then
> PTR_ERR(nop->vbus_draw) == -ENODEV is true, nop->vbus_draw will be set
> to NULL, but won't encode error, so the dev_err_probe() won't trigger.
>
> "
> 259 nop->vbus_draw = devm_regulator_get_exclusive(dev, "vbus");
> 260 if (PTR_ERR(nop->vbus_draw) == -ENODEV)
> 261 nop->vbus_draw = NULL;
> 262 if (IS_ERR(nop->vbus_draw))
> 263 return dev_err_probe(dev, PTR_ERR(nop->vbus_draw),
> 264 "could not get vbus regulator\n");
> "
>
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/usb/phy/phy-generic.c#n259
Sorry, you are right. I missed the PHY driver ignores the error and
probes successfully, and thus didn't bother doing "echo ee000000.usb >
/sys/bus/platform/drivers/xhci-renesas-hcd/bind" after /lib/firmware
became available.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v3 3/6] drm/sun4i: Enable LVDS output on sun20i D1s/T113
From: Parthiban @ 2026-01-22 10:22 UTC (permalink / raw)
To: Kuba Szczodrzyński, Maxime Ripard, Samuel Holland,
Chen-Yu Tsai, Jernej Skrabec, Maarten Lankhorst,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: parthiban, David Airlie, Simona Vetter, linux-arm-kernel,
linux-sunxi, linux-kernel, linux-riscv, linux-phy, devicetree,
dri-devel, paulk
In-Reply-To: <20251116134835.447357-1-kuba@szczodrzynski.pl>
Dear Kuba,
On 11/16/25 2:48 PM, Kuba Szczodrzyński wrote:
> +static void sun20i_tcon_setup_lvds_dphy(struct sun4i_tcon *tcon,
> + const struct drm_encoder *encoder)
> +{
> + union phy_configure_opts opts = { };
> +
> + if (!tcon->quirks->has_combo_dphy || !tcon->dphy)
> + return;
> +
> + if (phy_init(tcon->dphy))
> + return;
> +
> + if (phy_set_mode(tcon->dphy, PHY_MODE_LVDS))
From Documentation/driver-api/phy/phy.rst, set_mode shall be after power_on. But re-order
will fail to work for our case. Not sure if this is fine.
Thanks,
Parthiban
> + return;
> +
> + if (phy_configure(tcon->dphy, &opts))
> + return;
> +
> + if (phy_power_on(tcon->dphy))
> + return;
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v3 1/6] phy: allwinner: phy-sun6i-mipi-dphy: Support LVDS in combo D-PHY
From: Parthiban @ 2026-01-22 10:15 UTC (permalink / raw)
To: Kuba Szczodrzyński, Maxime Ripard, Samuel Holland,
Chen-Yu Tsai, Jernej Skrabec, Maarten Lankhorst,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: parthiban, David Airlie, Simona Vetter, linux-arm-kernel,
linux-sunxi, linux-kernel, linux-riscv, linux-phy, devicetree,
dri-devel, paulk
In-Reply-To: <20251116134724.447131-1-kuba@szczodrzynski.pl>
Dear Kuba,
On 11/16/25 2:47 PM, Kuba Szczodrzyński wrote:
> Some Allwinner chips (notably the D1s/T113 and the A100) have a "combo
> MIPI DSI D-PHY" which is required when using single-link LVDS0.
>
> In this mode, the DSI peripheral is not used and the PHY is not
> configured for DSI. Instead, the COMBO_PHY_REGx registers are set to
> enable LVDS operation.
>
> Enable the PHY driver to work in LVDS mode on chips with a combo D-PHY.
>
> Also change the SUN50I_COMBO_PHY_REG1 macro names to reflect the correct
> register name.
>
> Signed-off-by: Kuba Szczodrzyński <kuba@szczodrzynski.pl>
> ---
> drivers/phy/allwinner/phy-sun6i-mipi-dphy.c | 70 ++++++++++++++++++++-
> 1 file changed, 68 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/phy/allwinner/phy-sun6i-mipi-dphy.c b/drivers/phy/allwinner/phy-sun6i-mipi-dphy.c
> index 36eab9527..57035b3a4 100644
> --- a/drivers/phy/allwinner/phy-sun6i-mipi-dphy.c
> +++ b/drivers/phy/allwinner/phy-sun6i-mipi-dphy.c
> @@ -166,8 +166,8 @@
> #define SUN50I_COMBO_PHY_REG0_EN_CP BIT(0)
>
> #define SUN50I_COMBO_PHY_REG1 0x114
> -#define SUN50I_COMBO_PHY_REG2_REG_VREF1P6(n) (((n) & 0x7) << 4)
> -#define SUN50I_COMBO_PHY_REG2_REG_VREF0P8(n) ((n) & 0x7)
> +#define SUN50I_COMBO_PHY_REG1_REG_VREF1P6(n) (((n) & 0x7) << 4)
> +#define SUN50I_COMBO_PHY_REG1_REG_VREF0P8(n) ((n) & 0x7)
>
> #define SUN50I_COMBO_PHY_REG2 0x118
> #define SUN50I_COMBO_PHY_REG2_HS_STOP_DLY(n) ((n) & 0xff)
> @@ -181,7 +181,9 @@ struct sun6i_dphy;
>
> struct sun6i_dphy_variant {
> void (*tx_power_on)(struct sun6i_dphy *dphy);
> + void (*lvds_power_on)(struct sun6i_dphy *dphy);
> bool rx_supported;
> + bool is_combo_dphy;
> };
>
> struct sun6i_dphy {
> @@ -222,6 +224,18 @@ static int sun6i_dphy_configure(struct phy *phy, union phy_configure_opts *opts)
> return 0;
> }
>
> +static int sun6i_dphy_set_mode(struct phy *phy, enum phy_mode mode, int submode)
> +{
> + struct sun6i_dphy *dphy = phy_get_drvdata(phy);
> +
> + if (mode == PHY_MODE_LVDS && !dphy->variant->is_combo_dphy) {
At this stage mode will be PHY_MODE_INVALID by default. So the consumer fails with set_mode by
default.
IMO set_mode shall set
+ dphy->mode = mode;
+ dphy->submode = submode;
in the sun6i_dphy and retain for the next calls like power on.
> + /* Not a combo D-PHY: LVDS is not supported. */
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> static void sun6i_a31_mipi_dphy_tx_power_on(struct sun6i_dphy *dphy)
> {
> u8 lanes_mask = GENMASK(dphy->config.lanes - 1, 0);
> @@ -329,6 +343,43 @@ static void sun50i_a100_mipi_dphy_tx_power_on(struct sun6i_dphy *dphy)
> udelay(1);
> }
>
> +static void sun50i_a100_mipi_dphy_lvds_power_on(struct sun6i_dphy *dphy)
> +{
> + regmap_write(dphy->regs, SUN50I_COMBO_PHY_REG1,
> + SUN50I_COMBO_PHY_REG1_REG_VREF1P6(4) |
> + SUN50I_COMBO_PHY_REG1_REG_VREF0P8(3));
> +
> + regmap_write(dphy->regs, SUN50I_COMBO_PHY_REG0,
> + SUN50I_COMBO_PHY_REG0_EN_CP);
> + udelay(5);
> +
> + regmap_update_bits(dphy->regs, SUN50I_COMBO_PHY_REG0,
> + SUN50I_COMBO_PHY_REG0_EN_LVDS,
> + SUN50I_COMBO_PHY_REG0_EN_LVDS);
> + udelay(5);
> +
> + regmap_update_bits(dphy->regs, SUN50I_COMBO_PHY_REG0,
> + SUN50I_COMBO_PHY_REG0_EN_COMBOLDO,
> + SUN50I_COMBO_PHY_REG0_EN_COMBOLDO);
> + udelay(5);
> +
> + regmap_update_bits(dphy->regs, SUN50I_COMBO_PHY_REG0,
> + SUN50I_COMBO_PHY_REG0_EN_MIPI,
> + SUN50I_COMBO_PHY_REG0_EN_MIPI);
> +
> + regmap_write(dphy->regs, SUN6I_DPHY_ANA4_REG,
> + SUN6I_DPHY_ANA4_REG_EN_MIPI |
> + SUN6I_DPHY_ANA4_REG_IB(2));
> +
> + regmap_write(dphy->regs, SUN6I_DPHY_ANA3_REG,
> + SUN6I_DPHY_ANA3_EN_LDOR |
> + SUN6I_DPHY_ANA3_EN_LDOD);
> +
> + regmap_write(dphy->regs, SUN6I_DPHY_ANA2_REG, 0);
> +
> + regmap_write(dphy->regs, SUN6I_DPHY_ANA1_REG, 0);
> +}
> +
> static int sun6i_dphy_tx_power_on(struct sun6i_dphy *dphy)
> {
> u8 lanes_mask = GENMASK(dphy->config.lanes - 1, 0);
> @@ -492,6 +543,13 @@ static int sun6i_dphy_power_on(struct phy *phy)
> {
> struct sun6i_dphy *dphy = phy_get_drvdata(phy);
>
> + if (phy->attrs.mode == PHY_MODE_LVDS && dphy->variant->is_combo_dphy) {
+ if (dphy->mode == PHY_MODE_LVDS && dphy->variant->is_combo_dphy) {
compared like this.
Thanks,
Parthiban
> + if (!dphy->variant->lvds_power_on)
> + return -EINVAL;
> + dphy->variant->lvds_power_on(dphy);
> + return 0;
> + }
> +
> switch (dphy->direction) {
> case SUN6I_DPHY_DIRECTION_TX:
> return sun6i_dphy_tx_power_on(dphy);
> @@ -514,6 +572,11 @@ static int sun6i_dphy_power_off(struct phy *phy)
> regmap_write(dphy->regs, SUN6I_DPHY_ANA3_REG, 0);
> regmap_write(dphy->regs, SUN6I_DPHY_ANA4_REG, 0);
>
> + if (phy->attrs.mode == PHY_MODE_LVDS && dphy->variant->is_combo_dphy) {
> + regmap_write(dphy->regs, SUN50I_COMBO_PHY_REG1, 0);
> + regmap_write(dphy->regs, SUN50I_COMBO_PHY_REG0, 0);
> + }
> +
> return 0;
> }
>
> @@ -533,6 +596,7 @@ static const struct phy_ops sun6i_dphy_ops = {
> .configure = sun6i_dphy_configure,
> .power_on = sun6i_dphy_power_on,
> .power_off = sun6i_dphy_power_off,
> + .set_mode = sun6i_dphy_set_mode,
> .init = sun6i_dphy_init,
> .exit = sun6i_dphy_exit,
> };
> @@ -619,6 +683,8 @@ static const struct sun6i_dphy_variant sun6i_a31_mipi_dphy_variant = {
>
> static const struct sun6i_dphy_variant sun50i_a100_mipi_dphy_variant = {
> .tx_power_on = sun50i_a100_mipi_dphy_tx_power_on,
> + .lvds_power_on = sun50i_a100_mipi_dphy_lvds_power_on,
> + .is_combo_dphy = true,
> };
>
> static const struct of_device_id sun6i_dphy_of_table[] = {
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 5/5] PCI: qcom: enable Link retain logic for Hamoa
From: Krishna Chaitanya Chundru @ 2026-01-22 8:59 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Vinod Koul, Neil Armstrong, Philipp Zabel, Jingoo Han,
Manivannan Sadhasivam, Lorenzo Pieralisi,
Krzysztof Wilczyński, Rob Herring, Bjorn Helgaas,
linux-arm-msm, linux-phy, linux-kernel, linux-pci
In-Reply-To: <woztsrvxwkgi34z3yop7nja6ojbxdboyzz5xpz4xlym75dtyja@iopi7hvw42v7>
On 1/9/2026 6:39 PM, Dmitry Baryshkov wrote:
> On Fri, Jan 09, 2026 at 12:51:10PM +0530, Krishna Chaitanya Chundru wrote:
>> The Hamoa platform supports keeping the PCIe link active across
>> bootloader and kernel handoff. To take advantage of this, introduce a
>> specific configuration (cfg_x1e80100) with link_retain = true and
>> update the device match table to use it.
> Why are we enabling it only for this platform?
As mentioned in the cover letter we are not trusting every platform boot
loaders,
which have initialized the controller to max speed. That is we are
restricting them to
only for this platform.
- Krishna Chaitanya.
>> Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
>> ---
>> drivers/pci/controller/dwc/pcie-qcom.c | 8 +++++++-
>> 1 file changed, 7 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c
>> index bdd5bdb462c5f6814c8311be96411173456b6b14..975671a0dd4757074600d5a0966e94220bb18d8c 100644
>> --- a/drivers/pci/controller/dwc/pcie-qcom.c
>> +++ b/drivers/pci/controller/dwc/pcie-qcom.c
>> @@ -1531,6 +1531,12 @@ static const struct qcom_pcie_cfg cfg_sc8280xp = {
>> .no_l0s = true,
>> };
>>
>> +static const struct qcom_pcie_cfg cfg_x1e80100 = {
>> + .ops = &ops_1_21_0,
>> + .no_l0s = true,
>> + .link_retain = true,
>> +};
>> +
>> static const struct qcom_pcie_cfg cfg_fw_managed = {
>> .firmware_managed = true,
>> };
>> @@ -2168,7 +2174,7 @@ static const struct of_device_id qcom_pcie_match[] = {
>> { .compatible = "qcom,pcie-sm8450-pcie0", .data = &cfg_1_9_0 },
>> { .compatible = "qcom,pcie-sm8450-pcie1", .data = &cfg_1_9_0 },
>> { .compatible = "qcom,pcie-sm8550", .data = &cfg_1_9_0 },
>> - { .compatible = "qcom,pcie-x1e80100", .data = &cfg_sc8280xp },
>> + { .compatible = "qcom,pcie-x1e80100", .data = &cfg_x1e80100 },
>> { }
>> };
>>
>>
>> --
>> 2.34.1
>>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 2/5] PCI: dwc: Add support for retaining link during host init
From: Krishna Chaitanya Chundru @ 2026-01-22 8:55 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Vinod Koul, Neil Armstrong, Philipp Zabel, Jingoo Han,
Manivannan Sadhasivam, Lorenzo Pieralisi,
Krzysztof Wilczyński, Rob Herring, Bjorn Helgaas,
linux-arm-msm, linux-phy, linux-kernel, linux-pci
In-Reply-To: <20260109155350.GA546142@bhelgaas>
On 1/9/2026 9:23 PM, Bjorn Helgaas wrote:
> On Fri, Jan 09, 2026 at 12:51:07PM +0530, Krishna Chaitanya Chundru wrote:
>> Some platforms keep the PCIe link up across bootloader and kernel
>> handoff. In such cases, reinitializing the root complex is unnecessary
>> if the DWC glue drivers wants to retain the PCIe link.
>>
>> Introduce a link_retain flag in struct dw_pcie_rp to indicate that
>> the link should be preserved. When this flag is set by DWC glue drivers,
>> skip dw_pcie_setup_rc() and only initialize MSI, avoiding redundant
>> configuration steps.
> It sounds like this adds an assumption that the bootloader
> initialization is the same as what dw_pcie_setup_rc() would do. This
> assumption also applies to future changes in dw_pcie_setup_rc().
Yes the bootloader is expected to do everything what dw_pcie_setup_r()
does.
> It looks like you mention an issue like this in [PATCH 4/5]; DBI & ATU
> base being different than "HLOS" (whatever that is). This sounds like
> a maintenance issue keeping bootloader and kernel driver assumptions
> synchronized.
As the devicetree changes already pointing to different address from the
boatloader,
I was trying use this method. As changing device tree properties now
might not
be good, but no harm in doing so. I can skip this and make device tree
changes.
> Is there something in dw_pcie_setup_rc() that takes a lot of time or
> forces a link retrain?
I don't think it might not take much time as it is few register writes,
Just doesn't
want to do redundant register writes which are costly in general.
> You mentioned some clock and GENPD issues in
> the cover letter, but I don't see the connection between those and
> dw_pcie_setup_rc(). If there is a connection, please include it in
> this commit log and include a code comment about why
> dw_pcie_setup_rc() is being skipped.
The clock and GENPD issues have no direct relation ship with
dw_pcie_setup_r(). we are skipping them as they are redundant. I will
add a comment in next series on this. - Krishna Chaitanya.
>> Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
>> ---
>> drivers/pci/controller/dwc/pcie-designware-host.c | 11 ++++++++---
>> drivers/pci/controller/dwc/pcie-designware.h | 1 +
>> 2 files changed, 9 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c b/drivers/pci/controller/dwc/pcie-designware-host.c
>> index 372207c33a857b4c98572bb1e9b61fa0080bc871..d050df3f22e9507749a8f2fedd4c24fca43fb410 100644
>> --- a/drivers/pci/controller/dwc/pcie-designware-host.c
>> +++ b/drivers/pci/controller/dwc/pcie-designware-host.c
>> @@ -655,9 +655,14 @@ int dw_pcie_host_init(struct dw_pcie_rp *pp)
>> if (ret)
>> goto err_free_msi;
>>
>> - ret = dw_pcie_setup_rc(pp);
>> - if (ret)
>> - goto err_remove_edma;
>> + if (!pp->link_retain) {
> Use positive logic if possible (test "pp->link_retain" instead of
> "!pp->link_retain").
>
> I suspect this would be more maintainable if you identified specific
> things *inside* dw_pcie_setup_rc() that need to be skipped, and you
> added tests there.
>
>> + ret = dw_pcie_setup_rc(pp);
>> + if (ret)
>> + goto err_remove_edma;
>> + } else {
>> + dw_pcie_msi_init(pp);
>> + }
>> +
>>
>> if (!dw_pcie_link_up(pci)) {
>> ret = dw_pcie_start_link(pci);
>> diff --git a/drivers/pci/controller/dwc/pcie-designware.h b/drivers/pci/controller/dwc/pcie-designware.h
>> index 31685951a080456b8834aab2bf79a36c78f46639..8acab751b66a06e8322e027ab55dc0ecfdcf634c 100644
>> --- a/drivers/pci/controller/dwc/pcie-designware.h
>> +++ b/drivers/pci/controller/dwc/pcie-designware.h
>> @@ -439,6 +439,7 @@ struct dw_pcie_rp {
>> struct pci_config_window *cfg;
>> bool ecam_enabled;
>> bool native_ecam;
>> + bool link_retain;
>> };
>>
>> struct dw_pcie_ep_ops {
>>
>> --
>> 2.34.1
>>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v6 2/7] mux: Add helper functions for getting optional and selected mux-state
From: Dan Carpenter @ 2026-01-22 6:17 UTC (permalink / raw)
To: oe-kbuild, Josua Mayer, Marc Kleine-Budde, Vincent Mailhol,
Vinod Koul, Neil Armstrong, Peter Rosin, Aaro Koskinen,
Andreas Kemnade, 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
Cc: lkp, oe-kbuild-all, Yazan Shhady, Jon Nettleton, Mikhail Anikin,
linux-can, linux-phy, linux-kernel, linux-omap, linux-i2c,
linux-mmc, devicetree
In-Reply-To: <20260121-rz-sdio-mux-v6-2-38aa39527928@solid-run.com>
Hi Josua,
kernel test robot noticed the following build warnings:
url: https://github.com/intel-lab-lkp/linux/commits/Josua-Mayer/phy-can-transceiver-rename-temporary-helper-function-to-avoid-conflict/20260121-173607
base: 8f0b4cce4481fb22653697cced8d0d04027cb1e8
patch link: https://lore.kernel.org/r/20260121-rz-sdio-mux-v6-2-38aa39527928%40solid-run.com
patch subject: [PATCH v6 2/7] mux: Add helper functions for getting optional and selected mux-state
config: arm64-randconfig-r073-20260121 (https://download.01.org/0day-ci/archive/20260122/202601221036.J0kR78Uw-lkp@intel.com/config)
compiler: aarch64-linux-gcc (GCC) 8.5.0
smatch version: v0.5.0-8985-g2614ff1a
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
| Closes: https://lore.kernel.org/r/202601221036.J0kR78Uw-lkp@intel.com/
New smatch warnings:
drivers/mux/core.c:776 __devm_mux_state_get() warn: passing zero to 'PTR_ERR'
drivers/mux/core.c:796 __devm_mux_state_get() warn: passing zero to 'ERR_PTR'
Old smatch warnings:
drivers/mux/core.c:722 mux_state_get() warn: passing zero to 'ERR_CAST'
vim +/PTR_ERR +776 drivers/mux/core.c
0610cc3159b786 Josua Mayer 2026-01-21 761 static struct mux_state *__devm_mux_state_get(struct device *dev, const char *mux_name,
0610cc3159b786 Josua Mayer 2026-01-21 762 bool optional,
0610cc3159b786 Josua Mayer 2026-01-21 763 int (*init)(struct mux_state *mstate),
0610cc3159b786 Josua Mayer 2026-01-21 764 int (*exit)(struct mux_state *mstate))
0610cc3159b786 Josua Mayer 2026-01-21 765 {
0610cc3159b786 Josua Mayer 2026-01-21 766 struct devm_mux_state_state *devm_state;
0610cc3159b786 Josua Mayer 2026-01-21 767 struct mux_state *mstate;
0610cc3159b786 Josua Mayer 2026-01-21 768 int ret;
84564481bc4520 Aswath Govindraju 2022-01-07 769
0610cc3159b786 Josua Mayer 2026-01-21 770 devm_state = devres_alloc(devm_mux_state_release, sizeof(*devm_state), GFP_KERNEL);
0610cc3159b786 Josua Mayer 2026-01-21 771 if (!devm_state)
0610cc3159b786 Josua Mayer 2026-01-21 772 return ERR_PTR(-ENOMEM);
0610cc3159b786 Josua Mayer 2026-01-21 773
0610cc3159b786 Josua Mayer 2026-01-21 774 mstate = mux_state_get(dev, mux_name, optional);
0610cc3159b786 Josua Mayer 2026-01-21 775 if (IS_ERR_OR_NULL(mstate)) {
Please, change this to if (IS_ERR(mstate)) {. The mux_state_get() never
returns NULL. I have written a blog about functions which return both
error pointers and NULL.
https://staticthinking.wordpress.com/2022/08/01/mixing-error-pointers-and-null/
0610cc3159b786 Josua Mayer 2026-01-21 @776 ret = PTR_ERR(mstate);
0610cc3159b786 Josua Mayer 2026-01-21 777 goto err_mux_state_get;
0610cc3159b786 Josua Mayer 2026-01-21 778 }
0610cc3159b786 Josua Mayer 2026-01-21 779
0610cc3159b786 Josua Mayer 2026-01-21 780 if (init) {
0610cc3159b786 Josua Mayer 2026-01-21 781 ret = init(mstate);
0610cc3159b786 Josua Mayer 2026-01-21 782 if (ret)
0610cc3159b786 Josua Mayer 2026-01-21 783 goto err_mux_state_init;
0610cc3159b786 Josua Mayer 2026-01-21 784 }
0610cc3159b786 Josua Mayer 2026-01-21 785
0610cc3159b786 Josua Mayer 2026-01-21 786 devm_state->mstate = mstate;
0610cc3159b786 Josua Mayer 2026-01-21 787 devm_state->exit = exit;
0610cc3159b786 Josua Mayer 2026-01-21 788 devres_add(dev, devm_state);
0610cc3159b786 Josua Mayer 2026-01-21 789
0610cc3159b786 Josua Mayer 2026-01-21 790 return mstate;
0610cc3159b786 Josua Mayer 2026-01-21 791
0610cc3159b786 Josua Mayer 2026-01-21 792 err_mux_state_init:
84564481bc4520 Aswath Govindraju 2022-01-07 793 mux_state_put(mstate);
0610cc3159b786 Josua Mayer 2026-01-21 794 err_mux_state_get:
0610cc3159b786 Josua Mayer 2026-01-21 795 devres_free(devm_state);
0610cc3159b786 Josua Mayer 2026-01-21 @796 return ERR_PTR(ret);
84564481bc4520 Aswath Govindraju 2022-01-07 797 }
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH next] phy: google: fix build dependency for Google Tensor USB PHY
From: Peter Griffin @ 2026-01-21 23:06 UTC (permalink / raw)
To: Roy Luo
Cc: Vinod Koul, Neil Armstrong, André Draszik, Tudor Ambarus,
Joy Chakraborty, Naveen Kumar, linux-phy, linux-kernel,
linux-arm-kernel, linux-samsung-soc, kernel test robot
In-Reply-To: <20260121-next-v1-1-c18068b091b9@google.com>
On Wed, 21 Jan 2026 at 22:21, Roy Luo <royluo@google.com> wrote:
>
> The Google Tensor USB PHY driver uses the Type-C switch framework to
> handle orientation changes. However, the Kconfig did not specify a
> dependency on the TYPEC framework, leading to undefined reference
> errors when building for architectures or configurations where
> CONFIG_TYPEC is disabled or configured as a module.
>
> Add 'depends on TYPEC' to the PHY_GOOGLE_USB entry to ensure all
> required symbols are available during linking.
>
> Fixes: cbce66669c82 ("phy: Add Google Tensor SoC USB PHY driver")
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202601210825.ELrpQeED-lkp@intel.com/
> Signed-off-by: Roy Luo <royluo@google.com>
> ---
Reviewed-by: Peter Griffin <peter.griffin@linaro.org>
> drivers/phy/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index 142e7b0ef2efb9209781800ee47b820a91b115ae..5531ff31d8156cb164c32e3e52d4a57b26a62d8d 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -49,6 +49,7 @@ config GENERIC_PHY_MIPI_DPHY
>
> config PHY_GOOGLE_USB
> tristate "Google Tensor SoC USB PHY driver"
> + depends on TYPEC
> select GENERIC_PHY
> help
> Enable support for the USB PHY on Google Tensor SoCs, starting with
>
> ---
> base-commit: 8bb92fd7a04077925c8330f46a6ab44c80ca59f4
> change-id: 20260121-next-b949189cacf4
>
> Best regards,
> --
> Roy Luo <royluo@google.com>
>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 00/27] clk: remove deprecated API divider_round_rate() and friends
From: Brian Masney @ 2026-01-21 22:53 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd
Cc: linux-clk, linux-kernel, Chen Wang, Inochi Amaoto, sophgo,
Chen-Yu Tsai, Maxime Ripard, Jernej Skrabec, Samuel Holland,
linux-arm-kernel, linux-sunxi, Alexandre Belloni, linux-rtc,
Andreas Färber, Manivannan Sadhasivam, linux-actions,
Keguang Zhang, linux-mips, Taichi Sugaya, Takao Orito,
Jacky Huang, Shan-Chun Hung, Vladimir Zapolskiy,
Piotr Wojtaszczyk, Bjorn Andersson, linux-arm-msm, Orson Zhai,
Baolin Wang, Chunyan Zhang, Maxime Coquelin, Alexandre Torgue,
linux-stm32, Michal Simek, Rob Clark, Dmitry Baryshkov,
David Airlie, Simona Vetter, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, dri-devel, freedreno, Vinod Koul,
Neil Armstrong, linux-phy
In-Reply-To: <20260108-clk-divider-round-rate-v1-0-535a3ed73bf3@redhat.com>
Hi Stephen,
On Thu, Jan 08, 2026 at 04:16:18PM -0500, Brian Masney wrote:
> Here's a series that gets rid of the deprecated APIs
> divider_round_rate(), divider_round_rate_parent(), and
> divider_ro_round_rate_parent() since these functions are just wrappers
> for the determine_rate variant.
I sent you a GIT PULL for what can go to Linus for the upcoming merge
window from this series:
https://lore.kernel.org/linux-clk/aXFYU324yQ6uBmk0@redhat.com/T/#u
Thanks,
Brian
--
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