* [PATCH v2 2/4] phy: phy-can-transceiver: Move OF ID table closer to their user
From: Andy Shevchenko @ 2026-03-17 20:27 UTC (permalink / raw)
To: linux-can, linux-phy, linux-kernel
Cc: Marc Kleine-Budde, Vincent Mailhol, Vinod Koul, Neil Armstrong,
Josua Mayer, Ulf Hansson, Andy Shevchenko
In-Reply-To: <20260317203001.2108568-1-andriy.shevchenko@linux.intel.com>
There is no code that uses ID table directly, except the
struct device_driver at the end of the file. Hence, move
table closer to its user. It's always possible to access
them via a pointer.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/phy/phy-can-transceiver.c | 59 +++++++++++++++----------------
1 file changed, 29 insertions(+), 30 deletions(-)
diff --git a/drivers/phy/phy-can-transceiver.c b/drivers/phy/phy-can-transceiver.c
index 80eece74f77d..aaed8d08fcf0 100644
--- a/drivers/phy/phy-can-transceiver.c
+++ b/drivers/phy/phy-can-transceiver.c
@@ -97,35 +97,6 @@ static const struct can_transceiver_data tja1057_drvdata = {
.flags = CAN_TRANSCEIVER_SILENT_PRESENT,
};
-static const struct of_device_id can_transceiver_phy_ids[] = {
- {
- .compatible = "ti,tcan1042",
- .data = &tcan1042_drvdata
- },
- {
- .compatible = "ti,tcan1043",
- .data = &tcan1043_drvdata
- },
- {
- .compatible = "nxp,tja1048",
- .data = &tja1048_drvdata
- },
- {
- .compatible = "nxp,tja1051",
- .data = &tja1051_drvdata
- },
- {
- .compatible = "nxp,tja1057",
- .data = &tja1057_drvdata
- },
- {
- .compatible = "nxp,tjr1443",
- .data = &tcan1043_drvdata
- },
- { }
-};
-MODULE_DEVICE_TABLE(of, can_transceiver_phy_ids);
-
static struct phy *can_transceiver_phy_xlate(struct device *dev,
const struct of_phandle_args *args)
{
@@ -229,6 +200,35 @@ static int can_transceiver_phy_probe(struct platform_device *pdev)
return PTR_ERR_OR_ZERO(phy_provider);
}
+static const struct of_device_id can_transceiver_phy_ids[] = {
+ {
+ .compatible = "ti,tcan1042",
+ .data = &tcan1042_drvdata
+ },
+ {
+ .compatible = "ti,tcan1043",
+ .data = &tcan1043_drvdata
+ },
+ {
+ .compatible = "nxp,tja1048",
+ .data = &tja1048_drvdata
+ },
+ {
+ .compatible = "nxp,tja1051",
+ .data = &tja1051_drvdata
+ },
+ {
+ .compatible = "nxp,tja1057",
+ .data = &tja1057_drvdata
+ },
+ {
+ .compatible = "nxp,tjr1443",
+ .data = &tcan1043_drvdata
+ },
+ { }
+};
+MODULE_DEVICE_TABLE(of, can_transceiver_phy_ids);
+
static struct platform_driver can_transceiver_phy_driver = {
.probe = can_transceiver_phy_probe,
.driver = {
@@ -236,7 +236,6 @@ static struct platform_driver can_transceiver_phy_driver = {
.of_match_table = can_transceiver_phy_ids,
},
};
-
module_platform_driver(can_transceiver_phy_driver);
MODULE_AUTHOR("Faiz Abbas <faiz_abbas@ti.com>");
--
2.50.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v2 3/4] phy: phy-can-transceiver: Don't check for specific errors when parsing properties
From: Andy Shevchenko @ 2026-03-17 20:27 UTC (permalink / raw)
To: linux-can, linux-phy, linux-kernel
Cc: Marc Kleine-Budde, Vincent Mailhol, Vinod Koul, Neil Armstrong,
Josua Mayer, Ulf Hansson, Andy Shevchenko
In-Reply-To: <20260317203001.2108568-1-andriy.shevchenko@linux.intel.com>
Instead of checking for the specific error codes (that can be considered
a layering violation to some extent) check for the property existence first
and then either parse it, or apply a default value.
With that, return an error when parsing of the existing property fails.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/phy/phy-can-transceiver.c | 14 +++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/phy/phy-can-transceiver.c b/drivers/phy/phy-can-transceiver.c
index aaed8d08fcf0..21b0406d1a09 100644
--- a/drivers/phy/phy-can-transceiver.c
+++ b/drivers/phy/phy-can-transceiver.c
@@ -128,8 +128,9 @@ static int can_transceiver_phy_probe(struct platform_device *pdev)
struct gpio_desc *standby_gpio;
struct gpio_desc *enable_gpio;
struct mux_state *mux_state;
- u32 max_bitrate = 0;
int err, i, num_ch = 1;
+ const char *propname;
+ u32 max_bitrate;
drvdata = device_get_match_data(dev);
if (drvdata->flags & CAN_TRANSCEIVER_DUAL_CH)
@@ -148,8 +149,15 @@ static int can_transceiver_phy_probe(struct platform_device *pdev)
priv->mux_state = mux_state;
- err = device_property_read_u32(dev, "max-bitrate", &max_bitrate);
- if ((err != -EINVAL) && !max_bitrate)
+ propname = "max-bitrate";
+ if (device_property_present(dev, propname)) {
+ err = device_property_read_u32(dev, propname, &max_bitrate);
+ if (err)
+ return dev_err_probe(dev, err, "failed to parse %s\n", propname);
+ } else {
+ max_bitrate = 0;
+ }
+ if (max_bitrate == 0)
dev_warn(dev, "Invalid value for transceiver max bitrate. Ignoring bitrate limit\n");
for (i = 0; i < num_ch; i++) {
--
2.50.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v2 4/4] phy: phy-can-transceiver: Drop unused include
From: Andy Shevchenko @ 2026-03-17 20:27 UTC (permalink / raw)
To: linux-can, linux-phy, linux-kernel
Cc: Marc Kleine-Budde, Vincent Mailhol, Vinod Koul, Neil Armstrong,
Josua Mayer, Ulf Hansson, Andy Shevchenko
In-Reply-To: <20260317203001.2108568-1-andriy.shevchenko@linux.intel.com>
This file does not use the symbols from the legacy
<linux/gpio.h> header, so let's drop it.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/phy/phy-can-transceiver.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/phy/phy-can-transceiver.c b/drivers/phy/phy-can-transceiver.c
index 21b0406d1a09..8e250039c183 100644
--- a/drivers/phy/phy-can-transceiver.c
+++ b/drivers/phy/phy-can-transceiver.c
@@ -5,12 +5,11 @@
* Copyright (C) 2021 Texas Instruments Incorporated - https://www.ti.com
*
*/
+#include <linux/gpio/consumer.h>
#include <linux/phy/phy.h>
#include <linux/platform_device.h>
#include <linux/property.h>
#include <linux/module.h>
-#include <linux/gpio.h>
-#include <linux/gpio/consumer.h>
#include <linux/mux/consumer.h>
struct can_transceiver_data {
--
2.50.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v2 0/4] phy: phy-can-transceiver: Ad-hoc cleanups and refactoring
From: Andy Shevchenko @ 2026-03-17 20:27 UTC (permalink / raw)
To: linux-can, linux-phy, linux-kernel
Cc: Marc Kleine-Budde, Vincent Mailhol, Vinod Koul, Neil Armstrong,
Josua Mayer, Ulf Hansson, Andy Shevchenko
The driver does two things that need to be addressed:
- includes subject to remove gpio.h
- checks for error code from device property APIs when it can be done in
a robust way
This series addresses the above and adds a couple of additional refactoring.
Changelog v2:
- rebased on top of the latest changes in the driver
- Cc'ed to Ulf and Josua due to above
- elaborated dropping of_node parameter (Vladimir)
v1: 20260219202910.2304440-1-andriy.shevchenko@linux.intel.com
Andy Shevchenko (4):
phy: phy-can-transceiver: Convert to use device property API
phy: phy-can-transceiver: Move OF ID table closer to their user
phy: phy-can-transceiver: Don't check for specific errors when parsing
properties
phy: phy-can-transceiver: Drop unused include
drivers/phy/phy-can-transceiver.c | 84 ++++++++++++++++---------------
1 file changed, 44 insertions(+), 40 deletions(-)
--
2.50.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v4 1/2] dt-bindings: phy: qcom: Add CSI2 C-PHY/DPHY schema
From: Vijay Kumar Tumati @ 2026-03-17 20:25 UTC (permalink / raw)
To: Bryan O'Donoghue, Bryan O'Donoghue, Vinod Koul,
Kishon Vijay Abraham I, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Neil Armstrong
Cc: Vladimir Zapolskiy, linux-arm-msm, linux-phy, linux-media,
devicetree, linux-kernel
In-Reply-To: <edf766b8-2664-4dac-b626-551807b3e5ef@kernel.org>
On 3/16/2026 10:26 PM, Bryan O'Donoghue wrote:
> On 16/03/2026 21:31, Vijay Kumar Tumati wrote:
>> Hi Bryan,
>>
>> On 3/15/2026 4:52 PM, Bryan O'Donoghue wrote:
>>> Add a base schema initially compatible with x1e80100 to describe MIPI
>>> CSI2
>>> PHY devices.
>>>
>>> The hardware can support both C-PHY and D-PHY modes. The CSIPHY devices
>>> have their own pinouts on the SoC as well as their own individual
>>> voltage
>>> rails.
>>>
>>> The need to model voltage rails on a per-PHY basis leads us to define
>>> CSIPHY devices as individual nodes.
>>>
>>> Two nice outcomes in terms of schema and DT arise from this change.
>>>
>>> 1. The ability to define on a per-PHY basis voltage rails.
>>> 2. The ability to require those voltage.
>>>
>>> We have had a complete bodge upstream for this where a single set of
>>> voltage rail for all CSIPHYs has been buried inside of CAMSS.
>>>
>>> Much like the I2C bus which is dedicated to Camera sensors - the CCI
>>> bus in
>>> CAMSS parlance, the CSIPHY devices should be individually modelled.
>>>
>>> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
>>> ---
>>> .../bindings/phy/qcom,x1e80100-csi2-phy.yaml | 133 +++++++++
>>> ++++++++++++
>>> 1 file changed, 133 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/phy/qcom,x1e80100-
>>> csi2-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,x1e80100-
>>> csi2-phy.yaml
>>> new file mode 100644
>>> index 0000000000000..b83c2d65ebc6e
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/phy/qcom,x1e80100-csi2-phy.yaml
>>> @@ -0,0 +1,133 @@
>>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>>> +%YAML 1.2
>>> +---
>>> +$id: http://devicetree.org/schemas/phy/qcom,x1e80100-csi2-phy.yaml#
>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>> +
>>> +title: Qualcomm CSI2 PHY
>>> +
>>> +maintainers:
>>> + - Bryan O'Donoghue <bod@kernel.org>
>>> +
>>> +description:
>>> + Qualcomm MIPI CSI2 C-PHY/D-PHY combination PHY. Connects MIPI CSI2
>>> sensors
>>> + to Qualcomm's Camera CSI Decoder. The PHY supports both C-PHY and
>>> D-PHY
>>> + modes.
>>> +
>>> +properties:
>>> + compatible:
>>> + const: qcom,x1e80100-csi2-phy
>>> +
>>> + reg:
>>> + maxItems: 1
>>> +
>>> + "#phy-cells":
>>> + const: 1
>>> +
>>> + clocks:
>>> + maxItems: 4
>>> +
>>> + clock-names:
>>> + items:
>>> + - const: csiphy
>>> + - const: csiphy_timer
>>> + - const: camnoc_axi
>>> + - const: cpas_ahb
>>> +
>>> + interrupts:
>>> + maxItems: 1
>>> +
>>> + operating-points-v2:
>>> + maxItems: 1
>>> +
>>> + power-domains:
>>> + items:
>>> + - description: TITAN TOP GDSC
>>> + - description: MXC or MXA voltage rail
>> Would it be better to provision MXA or MXC as an additional optional
>> power domain? I see 'cam_cc_cphy_rx_clk_src', the parent of all CSIPHYx
>> clocks, need all three power domains on this chipset.
>
> I don't think this should be optional. Have the dts point to an "mx"
> power-domain and then select which one is right for a PHY MX/MXA or MXC.
>
> Your worst case here is some future PHY which has more or fewer PDs
> which is then either a special case in this file or a whole new file for
> that compat.
>
I think it is the case on x1e* as well, Bryan.
>>> + - description: MMCX voltage rail
>>> +
>>> + power-domain-names:
>>> + items:
>>> + - const: top
>>> + - const: mx
>>> + - const: mmcx
>>> +
>>> + vdda-0p8-supply:
>>> + description: Phandle to a 0.8V regulator supply to a PHY.
>>> +
>>> + vdda-1p2-supply:
>>> + description: Phandle to 1.2V regulator supply to a PHY.
>>> +
>>> +required:
>>> + - compatible
>>> + - reg
>>> + - "#phy-cells"
>>> + - clocks
>>> + - clock-names
>>> + - interrupts
>>> + - operating-points-v2
>>> + - power-domains
>>> + - power-domain-names
>>> + - vdda-0p8-supply
>>> + - vdda-1p2-supply
>>> +
>>> +additionalProperties: false
>>> +
>>> +examples:
>>> + - |
>>> + #include <dt-bindings/interrupt-controller/arm-gic.h>
>>> + #include <dt-bindings/clock/qcom,x1e80100-camcc.h>
>>> + #include <dt-bindings/clock/qcom,x1e80100-gcc.h>
>>> + #include <dt-bindings/phy/phy.h>
>>> + #include <dt-bindings/power/qcom,rpmhpd.h>
>>> +
>>> + csiphy@ace4000 {
>>> + compatible = "qcom,x1e80100-csi2-phy";
>>> + reg = <0x0ace4000 0x2000>;
>>> + #phy-cells = <1>;
>>> +
>>> + clocks = <&camcc CAM_CC_CSIPHY0_CLK>,
>>> + <&camcc CAM_CC_CSI0PHYTIMER_CLK>,
>>> + <&camcc CAM_CC_CAMNOC_AXI_RT_CLK>,
>>> + <&camcc CAM_CC_CPAS_AHB_CLK>;
>>> + clock-names = "csiphy",
>>> + "csiphy_timer",
>>> + "camnoc_axi",
>>> + "cpas_ahb";
>> Although it's not a concern from my side, just want to be explicitly
>> sure that everyone is happy with the clock names, just to avoid any
>> changes later on when other modules are separated out.
>
> These are the names we already use in CAMSS so ... they're good enough
> to start from.
>
Sure, FYI: Dmitry, Konrad.
>>> +
>>> + operating-points-v2 = <&csiphy_opp_table>;
>>> +
>>> + interrupts = <GIC_SPI 477 IRQ_TYPE_EDGE_RISING>;
>>> +
>>> + power-domains = <&camcc CAM_CC_TITAN_TOP_GDSC>,
>>> + <&rpmhpd RPMHPD_MX>,
>>> + <&rpmhpd RPMHPD_MMCX>;
>>> + power-domain-names = "top",
>>> + "mx",
>>> + "mmcx";
>>> +
>>> + vdda-0p8-supply = <&vreg_l2c_0p8>;
>>> + vdda-1p2-supply = <&vreg_l1c_1p2>;
>>> + };
>>> +
>>> + csiphy_opp_table: opp-table {
>>> + compatible = "operating-points-v2";
>>> +
>>> + opp-300000000 {
>>> + opp-hz = /bits/ 64 <300000000>;
>>> + required-opps = <&rpmhpd_opp_low_svs_d1>,
>>> + <&rpmhpd_opp_low_svs_d1>;
>>> + };
>>> +
>>> + opp-400000000 {
>>> + opp-hz = /bits/ 64 <400000000>;
>>> + required-opps = <&rpmhpd_opp_low_svs>,
>>> + <&rpmhpd_opp_low_svs>;
>>> + };
>>> +
>>> + opp-480000000 {
>>> + opp-hz = /bits/ 64 <480000000>;
>>> + required-opps = <&rpmhpd_opp_low_svs>,
>>> + <&rpmhpd_opp_low_svs>;
>> 480mhz should be svs?
>
> Yes you're right thanks for spotting.
>
>>> + };
>>> + };
>>>
>> Thanks,
>> Vijay.
>
Thanks,
Vijay.
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v1 1/4] phy: phy-can-transceiver: Convert to use device property API
From: Andy Shevchenko @ 2026-03-17 20:13 UTC (permalink / raw)
To: Vladimir Oltean
Cc: linux-can, linux-phy, linux-kernel, Marc Kleine-Budde,
Vincent Mailhol, Vinod Koul, Neil Armstrong, Josua Mayer
In-Reply-To: <abkvyrkkqKRffVUr@ashevche-desk.local>
On Tue, Mar 17, 2026 at 12:41:19PM +0200, Andy Shevchenko wrote:
> On Sat, Feb 28, 2026 at 01:10:02PM +0200, Andy Shevchenko wrote:
> > On Tue, Feb 24, 2026 at 08:30:00PM +0200, Vladimir Oltean wrote:
> > > On Tue, Feb 24, 2026 at 06:54:48PM +0200, Andy Shevchenko wrote:
> > > > On Tue, Feb 24, 2026 at 06:26:06PM +0200, Vladimir Oltean wrote:
> > > > > On Thu, Feb 19, 2026 at 09:26:19PM +0100, Andy Shevchenko wrote:
...
> > > > > > - if (!of_property_present(dev->of_node, "mux-states"))
> > > > > > + if (!device_property_present(dev, "mux-states"))
> > > > >
> > > > > There's an entire saga with this function - devm_mux_state_get_optional().
> > > > > Josua Mayer is preparing to move it to the MUX core, which will be a cross-tree series.
> > > > > Would you mind not touching this, to avoid complicating what is already
> > > > > a complicated operation? It is going away anyway, and from what I can
> > > > > see in Josua's last series, its implementation from drivers/mux/core.c
> > > > > is already using device property APIs:
> > > > > https://lore.kernel.org/linux-phy/20260208-rz-sdio-mux-v9-2-9a3be13c1280@solid-run.com/
> > > >
> > > > Basically you ask me to postpone the series until that will be in. Since this
> > > > file is a mess in terms of OF/fwnode API use in exchange I would like whoever
> > > > is doing the other part to speed up a bit if possible.
> > > >
> > > > I prefer to see cleaner solution to be applied sooner and last in a long distance,
> > > > that's why I see either mine first but soon, or that first but also soon should
> > > > be in. Can we try to achieve that?
> > >
> > > The idea is that Ulf already expressed the availability to take the phy-can-transceiver
> > > patch through the mmc tree and provide back a tag to be pulled into linux-phy:
> > > https://lore.kernel.org/linux-phy/CAPDyKFrtTaJ5fqqbGrE_K6SAdTZYUfp-BycGjtWs4SabwBysKA@mail.gmail.com/
> > >
> > > If linux-phy takes your patch first, there will be a conflict when pulling the
> > > stable branch, and it won't be so fun, plus we can't even build-test Josua's
> > > submission on linux-phy, so that's obviously not great.
> > >
> > > So yeah, I'm not requesting you to postpone the entire series, just not
> > > touch devm_mux_state_get_optional() and don't let it appear in your
> > > patch context.
> >
> > Thanks for explanation. I prefer that Ulf's staff settles down first as it seems
> > more important.
>
> Any news on that front?
Okay, I found the new patches in Linux Next.
I will respin my set based on that.
> > > Somebody will have to remove "#include <linux/of.h>" at the end of the
> > > whole process, but that's minor.
...
> > > > > > - phy = devm_phy_create(dev, dev->of_node, &can_transceiver_phy_ops);
> > > > > > + phy = devm_phy_create(dev, NULL, &can_transceiver_phy_ops);
> > > > >
> > > > > It is not obvious why you replaced dev->of_node with NULL here.
> > > > > It doesn't appear correct. You seem to be breaking OF-based PHY lookups.
> > > >
> > > > It's the default. Yeah, I probably have to explain this in the commit message.
> > >
> > > Ah, ok. Found the "phy->dev.of_node = node ?: dev->of_node;" assignment.
> > > Sorry and noted, but please add it to the commit message too.
> >
> > Sure.
> >
> > > > Basically all devm_phy_create(dev, dev->of_node, ...) for clarity should be
> > > > converted to that approach. Or even better, a new (agnostic) API should take
> > > > default fwnode from the same device.
> > > >
> > > > phy = devm_phy_create_simple(dev, &..._phy_ops);
> > > >
> > > > // name was quickly chosen and may be not the best we can come up with
> > >
> > > I agree in principle. PHY drivers shouldn't be given a function where
> > > they routinely have to set one of the arguments to NULL, but a simpler
> > > function without that argument.
> > >
> > > But the phy-core.c doesn't support fwnode at all yet, it uses OF
> > > throughout. I think it would be preferable to leave this change to
> > > somebody who has business in that area.
> > >
> > > (are you interested in PHYs with a fwnode for any particular reason, or
> > > just because the API is more "generic" just in case?)
> >
> > Because of inconsistency. This makes my mind blown and the code is not good
> > for others to read and understand when it's inconsistent like this. That's it.
--
With Best Regards,
Andy Shevchenko
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH v3 2/4] phy: axiado: add Axiado eMMC PHY driver
From: Tzu-Hao Wei @ 2026-03-17 19:52 UTC (permalink / raw)
To: SriNavmani A, Prasad Bolisetty, Vinod Koul, Neil Armstrong,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-phy, devicetree, linux-arm-kernel, linux-kernel, openbmc,
Tzu-Hao Wei
In-Reply-To: <20260317-axiado-ax3000-add-emmc-phy-driver-support-v3-0-fbf790f3f711@axiado.com>
From: SriNavmani A <srinavmani@axiado.com>
It provides the required configurations for Axiado eMMC PHY driver for
HS200 mode.
Signed-off-by: SriNavmani A <srinavmani@axiado.com>
Co-developed-by: Prasad Bolisetty <pbolisetty@axiado.com>
Signed-off-by: Prasad Bolisetty <pbolisetty@axiado.com>
Signed-off-by: Tzu-Hao Wei <twei@axiado.com>
---
drivers/phy/Kconfig | 1 +
drivers/phy/Makefile | 1 +
drivers/phy/axiado/Kconfig | 11 ++
drivers/phy/axiado/Makefile | 1 +
drivers/phy/axiado/phy-axiado-emmc.c | 217 +++++++++++++++++++++++++++++++++++
5 files changed, 231 insertions(+)
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 678dd0452f0aa0597773433f04d2a9ba77474d2a..b802274ea45a84bd36d7c0b7fb90e368a5c018b4 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -103,6 +103,7 @@ config PHY_NXP_PTN3222
source "drivers/phy/allwinner/Kconfig"
source "drivers/phy/amlogic/Kconfig"
+source "drivers/phy/axiado/Kconfig"
source "drivers/phy/broadcom/Kconfig"
source "drivers/phy/cadence/Kconfig"
source "drivers/phy/freescale/Kconfig"
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index bfb27fb5a494283d7fd05dd670ebd1b12df8b1a1..f1b9e4a8673bcde3fdc0fdc06a3deddb5785ced1 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_PHY_AIROHA_PCIE) += phy-airoha-pcie.o
obj-$(CONFIG_PHY_NXP_PTN3222) += phy-nxp-ptn3222.o
obj-y += allwinner/ \
amlogic/ \
+ axiado/ \
broadcom/ \
cadence/ \
freescale/ \
diff --git a/drivers/phy/axiado/Kconfig b/drivers/phy/axiado/Kconfig
new file mode 100644
index 0000000000000000000000000000000000000000..d159e0345345987c7f48dcd12d3237997735d2b5
--- /dev/null
+++ b/drivers/phy/axiado/Kconfig
@@ -0,0 +1,11 @@
+#
+# PHY drivers for Axiado platforms
+#
+
+config PHY_AX3000_EMMC
+ tristate "Axiado eMMC PHY driver"
+ depends on OF && (ARCH_AXIADO || COMPILE_TEST)
+ select GENERIC_PHY
+ help
+ Enables this to support for the AX3000 EMMC PHY driver.
+ If unsure, say N.
diff --git a/drivers/phy/axiado/Makefile b/drivers/phy/axiado/Makefile
new file mode 100644
index 0000000000000000000000000000000000000000..1e2b1ba016092eaffdbd7acbd9cdc8577d79b35c
--- /dev/null
+++ b/drivers/phy/axiado/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_PHY_AX3000_EMMC) += phy-axiado-emmc.o
diff --git a/drivers/phy/axiado/phy-axiado-emmc.c b/drivers/phy/axiado/phy-axiado-emmc.c
new file mode 100644
index 0000000000000000000000000000000000000000..e0e2174776ad027df0a10a8c4741b1b4ef9ef40e
--- /dev/null
+++ b/drivers/phy/axiado/phy-axiado-emmc.c
@@ -0,0 +1,217 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Axiado eMMC PHY driver
+ *
+ * Copyright (C) 2017 Arasan Chip Systems Inc.
+ * Copyright (C) 2022-2026 Axiado Corporation (or its affiliates).
+ *
+ * Based on Arasan Driver (sdhci-pci-arasan.c)
+ * sdhci-pci-arasan.c - Driver for Arasan PCI Controller with integrated phy.
+ */
+#include <linux/bitfield.h>
+#include <linux/delay.h>
+#include <linux/io.h>
+#include <linux/iopoll.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/phy/phy.h>
+#include <linux/platform_device.h>
+
+/* Arasan eMMC 5.1 - PHY configuration registers */
+#define CAP_REG_IN_S1_MSB 0x04
+#define PHY_CTRL_1 0x38
+#define PHY_CTRL_2 0x3c
+#define PHY_CTRL_3 0x40
+#define STATUS 0x50
+
+#define DLL_ENBL BIT(26)
+#define RTRIM_EN BIT(21)
+#define PDB_ENBL BIT(23)
+#define RETB_ENBL BIT(1)
+
+#define REN_STRB BIT(27)
+#define REN_CMD_EN GENMASK(20, 12)
+
+/* Pull-UP Enable on CMD Line */
+#define PU_CMD_EN GENMASK(11, 3)
+
+/* Selection value for the optimum delay from 1-32 output tap lines */
+#define OTAP_DLY 0x02
+/* DLL charge pump current trim default [1000] */
+#define DLL_TRM_ICP 0x08
+/* Select the frequency range of DLL Operation */
+#define FRQ_SEL 0x01
+
+#define OTAP_SEL_MASK GENMASK(10, 7)
+#define DLL_TRM_MASK GENMASK(25, 22)
+#define DLL_FRQSEL_MASK GENMASK(27, 25)
+
+#define OTAP_SEL(x) (FIELD_PREP(OTAP_SEL_MASK, x) | OTAPDLY_EN)
+#define DLL_TRM(x) (FIELD_PREP(DLL_TRM_MASK, x) | DLL_ENBL)
+#define DLL_FRQSEL(x) FIELD_PREP(DLL_FRQSEL_MASK, x)
+
+#define OTAPDLY_EN BIT(11)
+
+#define SEL_DLY_RXCLK BIT(18)
+#define SEL_DLY_TXCLK BIT(19)
+
+#define CALDONE_MASK 0x40
+#define DLL_RDY_MASK 0x1
+#define MAX_CLK_BUF0 BIT(20)
+#define MAX_CLK_BUF1 BIT(21)
+#define MAX_CLK_BUF2 BIT(22)
+
+#define CLK_MULTIPLIER 0xc008e
+#define POLL_TIMEOUT_MS 3000
+#define POLL_DELAY_US 100
+
+struct axiado_emmc_phy {
+ void __iomem *reg_base;
+ struct device *dev;
+};
+
+static int axiado_emmc_phy_init(struct phy *phy)
+{
+ struct axiado_emmc_phy *ax_phy = phy_get_drvdata(phy);
+ struct device *dev = ax_phy->dev;
+ u32 val;
+ int ret;
+
+ val = readl(ax_phy->reg_base + PHY_CTRL_1);
+ writel(val | RETB_ENBL | RTRIM_EN, ax_phy->reg_base + PHY_CTRL_1);
+
+ val = readl(ax_phy->reg_base + PHY_CTRL_3);
+ writel(val | PDB_ENBL, ax_phy->reg_base + PHY_CTRL_3);
+
+ ret = readl_poll_timeout(ax_phy->reg_base + STATUS, val,
+ val & CALDONE_MASK, POLL_DELAY_US,
+ POLL_TIMEOUT_MS * 1000);
+ if (ret) {
+ dev_err(dev, "PHY calibration timeout\n");
+ return ret;
+ }
+
+ val = readl(ax_phy->reg_base + PHY_CTRL_1);
+ writel(val | REN_CMD_EN | PU_CMD_EN, ax_phy->reg_base + PHY_CTRL_1);
+
+ val = readl(ax_phy->reg_base + PHY_CTRL_2);
+ writel(val | REN_STRB, ax_phy->reg_base + PHY_CTRL_2);
+
+ val = readl(ax_phy->reg_base + PHY_CTRL_3);
+ writel(val | MAX_CLK_BUF0 | MAX_CLK_BUF1 | MAX_CLK_BUF2,
+ ax_phy->reg_base + PHY_CTRL_3);
+
+ writel(CLK_MULTIPLIER, ax_phy->reg_base + CAP_REG_IN_S1_MSB);
+
+ val = readl(ax_phy->reg_base + PHY_CTRL_3);
+ writel(val | SEL_DLY_RXCLK | SEL_DLY_TXCLK,
+ ax_phy->reg_base + PHY_CTRL_3);
+
+ return 0;
+}
+
+static int axiado_emmc_phy_power_on(struct phy *phy)
+{
+ struct axiado_emmc_phy *ax_phy = phy_get_drvdata(phy);
+ struct device *dev = ax_phy->dev;
+ u32 val;
+ int ret;
+
+ val = readl(ax_phy->reg_base + PHY_CTRL_1);
+ writel(val | RETB_ENBL, ax_phy->reg_base + PHY_CTRL_1);
+
+ val = readl(ax_phy->reg_base + PHY_CTRL_3);
+ writel(val | PDB_ENBL, ax_phy->reg_base + PHY_CTRL_3);
+
+ val = readl(ax_phy->reg_base + PHY_CTRL_2);
+ writel(val | OTAP_SEL(OTAP_DLY), ax_phy->reg_base + PHY_CTRL_2);
+
+ val = readl(ax_phy->reg_base + PHY_CTRL_1);
+ writel(val | DLL_TRM(DLL_TRM_ICP), ax_phy->reg_base + PHY_CTRL_1);
+
+ val = readl(ax_phy->reg_base + PHY_CTRL_3);
+ writel(val | DLL_FRQSEL(FRQ_SEL), ax_phy->reg_base + PHY_CTRL_3);
+
+ ret = read_poll_timeout(readl, val, val & DLL_RDY_MASK, POLL_DELAY_US,
+ POLL_TIMEOUT_MS * 1000, false,
+ ax_phy->reg_base + STATUS);
+ if (ret) {
+ dev_err(dev, "DLL ready timeout\n");
+ return ret;
+ }
+
+ return 0;
+}
+
+static int axiado_emmc_phy_power_off(struct phy *phy)
+{
+ struct axiado_emmc_phy *ax_phy = phy_get_drvdata(phy);
+ u32 val;
+
+ val = readl(ax_phy->reg_base + PHY_CTRL_1);
+ val &= ~(DLL_TRM_MASK | DLL_ENBL);
+ writel(val, ax_phy->reg_base + PHY_CTRL_1);
+
+ val = readl(ax_phy->reg_base + PHY_CTRL_3);
+ val &= ~(DLL_FRQSEL_MASK | PDB_ENBL);
+ writel(val, ax_phy->reg_base + PHY_CTRL_3);
+
+ return 0;
+}
+
+static const struct phy_ops axiado_emmc_phy_ops = {
+ .init = axiado_emmc_phy_init,
+ .power_on = axiado_emmc_phy_power_on,
+ .power_off = axiado_emmc_phy_power_off,
+ .owner = THIS_MODULE,
+};
+
+static const struct of_device_id axiado_emmc_phy_of_match[] = {
+ { .compatible = "axiado,ax3000-emmc-phy" },
+ { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, axiado_emmc_phy_of_match);
+
+static int axiado_emmc_phy_probe(struct platform_device *pdev)
+{
+ struct axiado_emmc_phy *ax_phy;
+ struct phy_provider *phy_provider;
+ struct device *dev = &pdev->dev;
+ struct phy *generic_phy;
+
+ if (!dev->of_node)
+ return -ENODEV;
+
+ ax_phy = devm_kzalloc(dev, sizeof(*ax_phy), GFP_KERNEL);
+ if (!ax_phy)
+ return -ENOMEM;
+
+ ax_phy->reg_base = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(ax_phy->reg_base))
+ return PTR_ERR(ax_phy->reg_base);
+
+ ax_phy->dev = dev;
+
+ generic_phy = devm_phy_create(dev, dev->of_node, &axiado_emmc_phy_ops);
+ if (IS_ERR(generic_phy))
+ return dev_err_probe(dev, PTR_ERR(generic_phy),
+ "failed to create PHY\n");
+
+ phy_set_drvdata(generic_phy, ax_phy);
+ phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
+
+ return PTR_ERR_OR_ZERO(phy_provider);
+}
+
+static struct platform_driver axiado_emmc_phy_driver = {
+ .probe = axiado_emmc_phy_probe,
+ .driver = {
+ .name = "axiado-emmc-phy",
+ .of_match_table = axiado_emmc_phy_of_match,
+ },
+};
+module_platform_driver(axiado_emmc_phy_driver);
+
+MODULE_DESCRIPTION("AX3000 eMMC PHY Driver");
+MODULE_AUTHOR("Axiado Corporation");
+MODULE_LICENSE("GPL");
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v3 0/4] Add eMMC PHY support for Axiado AX3000 SoC
From: Tzu-Hao Wei @ 2026-03-17 19:52 UTC (permalink / raw)
To: SriNavmani A, Prasad Bolisetty, Vinod Koul, Neil Armstrong,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-phy, devicetree, linux-arm-kernel, linux-kernel, openbmc,
Tzu-Hao Wei
Axiado AX3000 SoC contains Arasan PHY which provides the interface to the
HS200 eMMC controller.
This series includes:
1. Add bindings for Axiado AX3000 eMMC PHY
2. Add Axiado AX3000 eMMC phy driver
3. Update MAINTAINERS for the new driver
4. Update Axiado AX3000 device tree
Changes in v3:
- Update year to 2026
- Use lowercase for addresses
- Remove redundant macros and use GENMASK
- Implement power_off function
- Link to v2: https://lore.kernel.org/r/20260206-axiado-ax3000-add-emmc-phy-driver-support-v2-0-a2f59e97a92d@axiado.com
Changes in v2:
- Fix dt-binding format
- Fix compilation error in m68k
- Use readl_poll_timeout instead of read_poll_timeout
- Link to v1: https://lore.kernel.org/r/20260109-axiado-ax3000-add-emmc-phy-driver-support-v1-0-dd43459dbfea@axiado.com
Changes: (The previous version was mixed with Host driver, so I separate
the PHY driver as a new thread)
- Fix property order in required section to match properties section
- Fixed example to use lowercase hex and proper node naming
- Removed wrapper functions, use readl/writel directly
- Replaced manual polling loops with read_poll_timeout macro
- Used devm_platform_ioremap_resource instead of separate calls
- Removed unnecessary of_match_node check
- Used dev_err_probe for error reporting
- Added proper Kconfig dependencies (ARCH_AXIADO || COMPILE_TEST)
- Fixed various coding style issues
- Link to previous patches: https://lore.kernel.org/all/20251222-axiado-ax3000-add-emmc-host-driver-support-v1-0-5457d0ebcdb4@axiado.com/
Signed-off-by: Tzu-Hao Wei <twei@axiado.com>
---
SriNavmani A (3):
dt-bindings: phy: axiado,ax3000-emmc-phy: add Axiado eMMC PHY
phy: axiado: add Axiado eMMC PHY driver
arm64: dts: axiado: Add eMMC PHY node
Tzu-Hao Wei (1):
MAINTAINERS: Add Axiado AX3000 eMMC PHY driver
.../bindings/phy/axiado,ax3000-emmc-phy.yaml | 37 ++++
MAINTAINERS | 10 +
arch/arm64/boot/dts/axiado/ax3000.dtsi | 7 +
drivers/phy/Kconfig | 1 +
drivers/phy/Makefile | 1 +
drivers/phy/axiado/Kconfig | 11 ++
drivers/phy/axiado/Makefile | 1 +
drivers/phy/axiado/phy-axiado-emmc.c | 217 +++++++++++++++++++++
8 files changed, 285 insertions(+)
---
base-commit: 63804fed149a6750ffd28610c5c1c98cce6bd377
change-id: 20260108-axiado-ax3000-add-emmc-phy-driver-support-d61aead8f622
Best regards,
--
Tzu-Hao Wei <twei@axiado.com>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH v3 1/4] dt-bindings: phy: axiado,ax3000-emmc-phy: add Axiado eMMC PHY
From: Tzu-Hao Wei @ 2026-03-17 19:52 UTC (permalink / raw)
To: SriNavmani A, Prasad Bolisetty, Vinod Koul, Neil Armstrong,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-phy, devicetree, linux-arm-kernel, linux-kernel, openbmc,
Tzu-Hao Wei
In-Reply-To: <20260317-axiado-ax3000-add-emmc-phy-driver-support-v3-0-fbf790f3f711@axiado.com>
From: SriNavmani A <srinavmani@axiado.com>
Axiado AX3000 SoC contains Arasan PHY which provides the interface to the
HS200 eMMC host controller.
Signed-off-by: SriNavmani A <srinavmani@axiado.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Tzu-Hao Wei <twei@axiado.com>
---
.../bindings/phy/axiado,ax3000-emmc-phy.yaml | 37 ++++++++++++++++++++++
1 file changed, 37 insertions(+)
diff --git a/Documentation/devicetree/bindings/phy/axiado,ax3000-emmc-phy.yaml b/Documentation/devicetree/bindings/phy/axiado,ax3000-emmc-phy.yaml
new file mode 100644
index 0000000000000000000000000000000000000000..61700b80e93f7185e16ca9eab0922fe6bb29fe86
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/axiado,ax3000-emmc-phy.yaml
@@ -0,0 +1,37 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/axiado,ax3000-emmc-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Axiado AX3000 Arasan eMMC PHY
+
+maintainers:
+ - SriNavmani A <srinavmani@axiado.com>
+ - Tzu-Hao Wei <twei@axiado.com>
+ - Prasad Bolisetty <pbolisetty@axiado.com>
+
+properties:
+ compatible:
+ const: axiado,ax3000-emmc-phy
+
+ reg:
+ maxItems: 1
+
+ "#phy-cells":
+ const: 0
+
+required:
+ - compatible
+ - reg
+ - "#phy-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ phy@80801c00 {
+ compatible = "axiado,ax3000-emmc-phy";
+ reg = <0x80801c00 0x1000>;
+ #phy-cells = <0>;
+ };
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v3 4/4] arm64: dts: axiado: Add eMMC PHY node
From: Tzu-Hao Wei @ 2026-03-17 19:52 UTC (permalink / raw)
To: SriNavmani A, Prasad Bolisetty, Vinod Koul, Neil Armstrong,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-phy, devicetree, linux-arm-kernel, linux-kernel, openbmc,
Tzu-Hao Wei
In-Reply-To: <20260317-axiado-ax3000-add-emmc-phy-driver-support-v3-0-fbf790f3f711@axiado.com>
From: SriNavmani A <srinavmani@axiado.com>
Add the eMMC PHY device tree node to the AX3000 SoC DTSI.
AX3000 has one eMMC PHY interface.
Signed-off-by: SriNavmani A <srinavmani@axiado.com>
Signed-off-by: Tzu-Hao Wei <twei@axiado.com>
---
arch/arm64/boot/dts/axiado/ax3000.dtsi | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/axiado/ax3000.dtsi b/arch/arm64/boot/dts/axiado/ax3000.dtsi
index 792f52e0c7dd42cbc54b0eb47e25b0fbf1a706b8..ccc8088bd8258cfb666268b14a3b0716a9ca69f4 100644
--- a/arch/arm64/boot/dts/axiado/ax3000.dtsi
+++ b/arch/arm64/boot/dts/axiado/ax3000.dtsi
@@ -507,6 +507,13 @@ uart3: serial@80520800 {
clocks = <&refclk &refclk>;
status = "disabled";
};
+
+ emmc_phy: phy@80801c00 {
+ compatible = "axiado,ax3000-emmc-phy";
+ reg = <0x0 0x80801c00 0x0 0x1000>;
+ #phy-cells = <0>;
+ status = "disabled";
+ };
};
timer {
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v3 3/4] MAINTAINERS: Add Axiado AX3000 eMMC PHY driver
From: Tzu-Hao Wei @ 2026-03-17 19:52 UTC (permalink / raw)
To: SriNavmani A, Prasad Bolisetty, Vinod Koul, Neil Armstrong,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-phy, devicetree, linux-arm-kernel, linux-kernel, openbmc,
Tzu-Hao Wei
In-Reply-To: <20260317-axiado-ax3000-add-emmc-phy-driver-support-v3-0-fbf790f3f711@axiado.com>
Add SriNavmani, Prasad and me as maintainers for Axiado AX3000 eMMC PHY
driver
Acked-by: Prasad Bolisetty <pbolisetty@axiado.com>
Signed-off-by: Tzu-Hao Wei <twei@axiado.com>
---
MAINTAINERS | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 67db88b04537b431c927b73624993233eef43e3f..c33b0aa94de81c89b674e44d4813c4e3b95b7b2d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4254,6 +4254,16 @@ W: https://ez.analog.com/linux-software-drivers
F: Documentation/devicetree/bindings/hwmon/adi,axi-fan-control.yaml
F: drivers/hwmon/axi-fan-control.c
+AXIADO EMMC PHY DRIVER
+M: SriNavmani A <srinavmani@axiado.com>
+M: Tzu-Hao Wei <twei@axiado.com>
+M: Prasad Bolisetty <pbolisetty@axiado.com>
+L: linux-phy@lists.infradead.org (moderated for non-subscribers)
+S: Maintained
+F: Documentation/devicetree/bindings/phy/axiado,ax3000-emmc-phy.yaml
+F: drivers/phy/axiado/Kconfig
+F: drivers/phy/axiado/phy-axiado-emmc.c
+
AXI SPI ENGINE
M: Michael Hennerich <michael.hennerich@analog.com>
M: Nuno Sá <nuno.sa@analog.com>
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* Re: [PATCH v1 1/1] arm64: dts: qcom: hamoa: Move PCIe PERST and Wake GPIOs to port nodes
From: Bjorn Helgaas @ 2026-03-17 17:13 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: Ziyue Zhang, andersson, konradybcio, robh, krzk+dt, conor+dt,
jingoohan1, lpieralisi, kwilczynski, bhelgaas, johan+linaro,
vkoul, kishon, neil.armstrong, abel.vesa, kw, linux-arm-msm,
devicetree, linux-kernel, linux-pci, linux-phy, qiang.yu,
quic_krichai, quic_vbadigan
In-Reply-To: <en5a7jrgpbn4bsmw5qwprugb2qmjkqw2x5eey6jxxu63634duz@b43rhcsqkj3o>
On Sat, Mar 14, 2026 at 07:50:50PM +0530, Manivannan Sadhasivam wrote:
> On Fri, Mar 13, 2026 at 11:45:42AM -0500, Bjorn Helgaas wrote:
> > On Fri, Mar 13, 2026 at 05:46:18PM +0800, Ziyue Zhang wrote:
> > > Commit 960609b22be5 ("arm64: dts: qcom: hamoa: Move PHY, PERST, and Wake
> > > GPIOs to PCIe port nodes and add port Nodes for all PCIe ports") did not
> > > convert all Hamoa‑based platforms to the new method of defining PERST and
> > > Wake GPIOs in the PCIe root port nodes.
> > >
> > > Without the change PCIe probe will fail. The probe failure happens because
> > > the PHY stays in the controller node while the PERST/Wake GPIOs were moved
> > > to the port nodes.
> > >
> > > This fixes probe failures seen on the following platforms:
> > > - x1-hp-omnibook-x14
> > > - x1-microsoft-denali
> > > - x1e80100-lenovo-yoga-slim7x
> > > - x1e80100-medion-sprchrgd-14-s1
> > > - x1p42100-lenovo-thinkbook-16
> > > - x1-asus-zenbook-a14
> > > - x1-crd
> > > - x1-dell-thena
> > >
> > > Fixes: 960609b22be5 ("arm64: dts: qcom: hamoa: Move PHY, PERST, and Wake GPIOs to PCIe port nodes and add port Nodes for all PCIe ports")
> >
> > Are you saying that DTs in the field broke because of some kernel
> > change? That's not supposed to happen. Even though PHY, PERST, and
> > Wake GPIOs should be described in Root Port nodes instead of the Root
> > Complex node in *future* DTs, the kernel is still supposed to accept
> > the old style with them described in the Root Complex node.
>
> This is not related to the driver change. The driver correctly
> parses all Root Port properties either in the Root Complex node (old
> binding) or Root Port node (new binding). But commit 960609b22be5,
> left converting mentioned board DTS to the new binding, leaving
> those affected platforms in a half baked state i.e., some properties
> in RC node and some in Root Port node. Driver cannot parse such
> combinations, so it fails correctly so.
The commit log mentions probe failures on some machines. I'd like it
to be more clear about who is affected and what they need to do to fix
their machines. If it only affects developers who generated DTs based
on 960609b22be5 for internal testing, we should say that so it's clear
that no end users will see any regressions or boot failures.
Is there some way to verify that after this patch, none of the
generated DTBs are in this half-baked situation? Some kind of
automated DTB checker?
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v1 1/4] phy: phy-can-transceiver: Convert to use device property API
From: Andy Shevchenko @ 2026-03-17 10:41 UTC (permalink / raw)
To: Vladimir Oltean
Cc: linux-can, linux-phy, linux-kernel, Marc Kleine-Budde,
Vincent Mailhol, Vinod Koul, Neil Armstrong, Josua Mayer
In-Reply-To: <aaLNBTZsUQ2vMfOW@ashevche-desk.local>
On Sat, Feb 28, 2026 at 01:10:02PM +0200, Andy Shevchenko wrote:
> On Tue, Feb 24, 2026 at 08:30:00PM +0200, Vladimir Oltean wrote:
> > On Tue, Feb 24, 2026 at 06:54:48PM +0200, Andy Shevchenko wrote:
> > > On Tue, Feb 24, 2026 at 06:26:06PM +0200, Vladimir Oltean wrote:
> > > > On Thu, Feb 19, 2026 at 09:26:19PM +0100, Andy Shevchenko wrote:
...
> > > > > - if (!of_property_present(dev->of_node, "mux-states"))
> > > > > + if (!device_property_present(dev, "mux-states"))
> > > >
> > > > There's an entire saga with this function - devm_mux_state_get_optional().
> > > > Josua Mayer is preparing to move it to the MUX core, which will be a cross-tree series.
> > > > Would you mind not touching this, to avoid complicating what is already
> > > > a complicated operation? It is going away anyway, and from what I can
> > > > see in Josua's last series, its implementation from drivers/mux/core.c
> > > > is already using device property APIs:
> > > > https://lore.kernel.org/linux-phy/20260208-rz-sdio-mux-v9-2-9a3be13c1280@solid-run.com/
> > >
> > > Basically you ask me to postpone the series until that will be in. Since this
> > > file is a mess in terms of OF/fwnode API use in exchange I would like whoever
> > > is doing the other part to speed up a bit if possible.
> > >
> > > I prefer to see cleaner solution to be applied sooner and last in a long distance,
> > > that's why I see either mine first but soon, or that first but also soon should
> > > be in. Can we try to achieve that?
> >
> > The idea is that Ulf already expressed the availability to take the phy-can-transceiver
> > patch through the mmc tree and provide back a tag to be pulled into linux-phy:
> > https://lore.kernel.org/linux-phy/CAPDyKFrtTaJ5fqqbGrE_K6SAdTZYUfp-BycGjtWs4SabwBysKA@mail.gmail.com/
> >
> > If linux-phy takes your patch first, there will be a conflict when pulling the
> > stable branch, and it won't be so fun, plus we can't even build-test Josua's
> > submission on linux-phy, so that's obviously not great.
> >
> > So yeah, I'm not requesting you to postpone the entire series, just not
> > touch devm_mux_state_get_optional() and don't let it appear in your
> > patch context.
>
> Thanks for explanation. I prefer that Ulf's staff settles down first as it seems
> more important.
Any news on that front?
> > Somebody will have to remove "#include <linux/of.h>" at the end of the
> > whole process, but that's minor.
>
> > > ...
> > >
> > > > > - phy = devm_phy_create(dev, dev->of_node, &can_transceiver_phy_ops);
> > > > > + phy = devm_phy_create(dev, NULL, &can_transceiver_phy_ops);
> > > >
> > > > It is not obvious why you replaced dev->of_node with NULL here.
> > > > It doesn't appear correct. You seem to be breaking OF-based PHY lookups.
> > >
> > > It's the default. Yeah, I probably have to explain this in the commit message.
> >
> > Ah, ok. Found the "phy->dev.of_node = node ?: dev->of_node;" assignment.
> > Sorry and noted, but please add it to the commit message too.
>
> Sure.
>
> > > Basically all devm_phy_create(dev, dev->of_node, ...) for clarity should be
> > > converted to that approach. Or even better, a new (agnostic) API should take
> > > default fwnode from the same device.
> > >
> > > phy = devm_phy_create_simple(dev, &..._phy_ops);
> > >
> > > // name was quickly chosen and may be not the best we can come up with
> >
> > I agree in principle. PHY drivers shouldn't be given a function where
> > they routinely have to set one of the arguments to NULL, but a simpler
> > function without that argument.
> >
> > But the phy-core.c doesn't support fwnode at all yet, it uses OF
> > throughout. I think it would be preferable to leave this change to
> > somebody who has business in that area.
> >
> > (are you interested in PHYs with a fwnode for any particular reason, or
> > just because the API is more "generic" just in case?)
>
> Because of inconsistency. This makes my mind blown and the code is not good
> for others to read and understand when it's inconsistent like this. That's it.
--
With Best Regards,
Andy Shevchenko
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v3 1/2] phy: qcom: edp: Add eDP/DP mode switch support
From: Yongxing Mou @ 2026-03-17 6:10 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Stephen Boyd, Bjorn Andersson
Cc: linux-arm-msm, linux-phy, linux-kernel, stable
In-Reply-To: <20260302-edp_phy-v3-1-ca8888d793b0@oss.qualcomm.com>
On 3/2/2026 4:28 PM, Yongxing Mou wrote:
> The eDP PHY supports both eDP&DP modes, each requires a different table.
> The current driver doesn't fully support every combo PHY mode and use
> either the eDP or DP table when enable the platform. In addition, some
> platforms mismatch between the mode and the table where DP mode uses
> the eDP table or eDP mode use the DP table.
>
> Clean up and correct the tables for currently supported platforms based on
> the HPG specification.
>
> Here lists the tables can be reused across current platforms.
> DP mode：
> -sa8775p/sc7280/sc8280xp/x1e80100
> -glymur
> eDP mode(low vdiff):
> -glymur/sa8775p/sc8280xp/x1e80100
> -sc7280
>
> Cc: stable@vger.kernel.org
> Fixes: f199223cb490 ("phy: qcom: Introduce new eDP PHY driver")
> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com>
> ---
> drivers/phy/qualcomm/phy-qcom-edp.c | 90 ++++++++++++++++++++++---------------
> 1 file changed, 53 insertions(+), 37 deletions(-)
>
> diff --git a/drivers/phy/qualcomm/phy-qcom-edp.c b/drivers/phy/qualcomm/phy-qcom-edp.c
> index 7372de05a0b8..36998326bae6 100644
> --- a/drivers/phy/qualcomm/phy-qcom-edp.c
> +++ b/drivers/phy/qualcomm/phy-qcom-edp.c
> @@ -87,7 +87,8 @@ struct qcom_edp_phy_cfg {
> bool is_edp;
> const u8 *aux_cfg;
> const u8 *vco_div_cfg;
> - const struct qcom_edp_swing_pre_emph_cfg *swing_pre_emph_cfg;
> + const struct qcom_edp_swing_pre_emph_cfg *dp_swing_pre_emph_cfg;
> + const struct qcom_edp_swing_pre_emph_cfg *edp_swing_pre_emph_cfg;
> const struct phy_ver_ops *ver_ops;
> };
>
> @@ -116,17 +117,17 @@ struct qcom_edp {
> };
>
> static const u8 dp_swing_hbr_rbr[4][4] = {
> - { 0x08, 0x0f, 0x16, 0x1f },
> + { 0x07, 0x0f, 0x16, 0x1f },
> { 0x11, 0x1e, 0x1f, 0xff },
> { 0x16, 0x1f, 0xff, 0xff },
> { 0x1f, 0xff, 0xff, 0xff }
> };
>
> static const u8 dp_pre_emp_hbr_rbr[4][4] = {
> - { 0x00, 0x0d, 0x14, 0x1a },
> + { 0x00, 0x0e, 0x15, 0x1a },
> { 0x00, 0x0e, 0x15, 0xff },
> { 0x00, 0x0e, 0xff, 0xff },
> - { 0x03, 0xff, 0xff, 0xff }
> + { 0x04, 0xff, 0xff, 0xff }
> };
>
> static const u8 dp_swing_hbr2_hbr3[4][4] = {
> @@ -150,6 +151,20 @@ static const struct qcom_edp_swing_pre_emph_cfg dp_phy_swing_pre_emph_cfg = {
> .pre_emphasis_hbr3_hbr2 = &dp_pre_emp_hbr2_hbr3,
> };
>
> +static const u8 dp_pre_emp_hbr_rbr_v8[4][4] = {
> + { 0x00, 0x0e, 0x15, 0x1a },
> + { 0x00, 0x0e, 0x15, 0xff },
> + { 0x00, 0x0e, 0xff, 0xff },
> + { 0x00, 0xff, 0xff, 0xff }
> +};
> +
> +static const struct qcom_edp_swing_pre_emph_cfg dp_phy_swing_pre_emph_cfg_v8 = {
> + .swing_hbr_rbr = &dp_swing_hbr_rbr,
> + .swing_hbr3_hbr2 = &dp_swing_hbr2_hbr3,
> + .pre_emphasis_hbr_rbr = &dp_pre_emp_hbr_rbr_v8,
> + .pre_emphasis_hbr3_hbr2 = &dp_pre_emp_hbr2_hbr3,
> +};
> +
> static const u8 edp_swing_hbr_rbr[4][4] = {
> { 0x07, 0x0f, 0x16, 0x1f },
> { 0x0d, 0x16, 0x1e, 0xff },
> @@ -158,7 +173,7 @@ static const u8 edp_swing_hbr_rbr[4][4] = {
> };
>
> static const u8 edp_pre_emp_hbr_rbr[4][4] = {
> - { 0x05, 0x12, 0x17, 0x1d },
> + { 0x05, 0x11, 0x17, 0x1d },
> { 0x05, 0x11, 0x18, 0xff },
> { 0x06, 0x11, 0xff, 0xff },
> { 0x00, 0xff, 0xff, 0xff }
> @@ -172,10 +187,10 @@ static const u8 edp_swing_hbr2_hbr3[4][4] = {
> };
>
> static const u8 edp_pre_emp_hbr2_hbr3[4][4] = {
> - { 0x08, 0x11, 0x17, 0x1b },
> - { 0x00, 0x0c, 0x13, 0xff },
> - { 0x05, 0x10, 0xff, 0xff },
> - { 0x00, 0xff, 0xff, 0xff }
> + { 0x0c, 0x15, 0x19, 0x1e },
> + { 0x0b, 0x15, 0x19, 0xff },
> + { 0x0e, 0x14, 0xff, 0xff },
> + { 0x0d, 0xff, 0xff, 0xff }
> };
>
> static const struct qcom_edp_swing_pre_emph_cfg edp_phy_swing_pre_emph_cfg = {
> @@ -193,25 +208,25 @@ static const u8 edp_phy_vco_div_cfg_v4[4] = {
> 0x01, 0x01, 0x02, 0x00,
> };
>
> -static const u8 edp_pre_emp_hbr_rbr_v5[4][4] = {
> - { 0x05, 0x11, 0x17, 0x1d },
> - { 0x05, 0x11, 0x18, 0xff },
> - { 0x06, 0x11, 0xff, 0xff },
> - { 0x00, 0xff, 0xff, 0xff }
> +static const u8 edp_swing_hbr2_hbr3_v3[4][4] = {
> + { 0x06, 0x11, 0x16, 0x1b },
> + { 0x0b, 0x19, 0x1f, 0xff },
> + { 0x18, 0x1f, 0xff, 0xff },
> + { 0x1f, 0xff, 0xff, 0xff }
> };
>
> -static const u8 edp_pre_emp_hbr2_hbr3_v5[4][4] = {
> +static const u8 edp_pre_emp_hbr2_hbr3_v3[4][4] = {
> { 0x0c, 0x15, 0x19, 0x1e },
> - { 0x0b, 0x15, 0x19, 0xff },
> - { 0x0e, 0x14, 0xff, 0xff },
> + { 0x09, 0x14, 0x19, 0xff },
> + { 0x0f, 0x14, 0xff, 0xff },
> { 0x0d, 0xff, 0xff, 0xff }
> };
>
> -static const struct qcom_edp_swing_pre_emph_cfg edp_phy_swing_pre_emph_cfg_v5 = {
> +static const struct qcom_edp_swing_pre_emph_cfg edp_phy_swing_pre_emph_cfg_v3 = {
> .swing_hbr_rbr = &edp_swing_hbr_rbr,
> - .swing_hbr3_hbr2 = &edp_swing_hbr2_hbr3,
> - .pre_emphasis_hbr_rbr = &edp_pre_emp_hbr_rbr_v5,
> - .pre_emphasis_hbr3_hbr2 = &edp_pre_emp_hbr2_hbr3_v5,
> + .swing_hbr3_hbr2 = &edp_swing_hbr2_hbr3_v3,
> + .pre_emphasis_hbr_rbr = &edp_pre_emp_hbr_rbr,
> + .pre_emphasis_hbr3_hbr2 = &edp_pre_emp_hbr2_hbr3_v3,
> };
>
> static const u8 edp_phy_aux_cfg_v5[DP_AUX_CFG_SIZE] = {
> @@ -262,12 +277,7 @@ static int qcom_edp_phy_init(struct phy *phy)
> DP_PHY_PD_CTL_PLL_PWRDN | DP_PHY_PD_CTL_DP_CLAMP_EN,
> edp->edp + DP_PHY_PD_CTL);
>
> - /*
> - * TODO: Re-work the conditions around setting the cfg8 value
> - * when more information becomes available about why this is
> - * even needed.
> - */
> - if (edp->cfg->swing_pre_emph_cfg && !edp->is_edp)
> + if (!edp->is_edp)
> aux_cfg[8] = 0xb7;
>
> writel(0xfc, edp->edp + DP_PHY_MODE);
> @@ -291,7 +301,7 @@ static int qcom_edp_phy_init(struct phy *phy)
>
> static int qcom_edp_set_voltages(struct qcom_edp *edp, const struct phy_configure_opts_dp *dp_opts)
> {
> - const struct qcom_edp_swing_pre_emph_cfg *cfg = edp->cfg->swing_pre_emph_cfg;
> + const struct qcom_edp_swing_pre_emph_cfg *cfg;
> unsigned int v_level = 0;
> unsigned int p_level = 0;
> u8 ldo_config;
> @@ -299,11 +309,10 @@ static int qcom_edp_set_voltages(struct qcom_edp *edp, const struct phy_configur
> u8 emph;
> int i;
>
> - if (!cfg)
> - return 0;
> -
> if (edp->is_edp)
> - cfg = &edp_phy_swing_pre_emph_cfg;
> + cfg = edp->cfg->edp_swing_pre_emph_cfg;
> + else
> + cfg = edp->cfg->dp_swing_pre_emph_cfg;
>
> for (i = 0; i < dp_opts->lanes; i++) {
> v_level = max(v_level, dp_opts->voltage[i]);
> @@ -564,20 +573,24 @@ static const struct qcom_edp_phy_cfg sa8775p_dp_phy_cfg = {
> .is_edp = false,
> .aux_cfg = edp_phy_aux_cfg_v5,
> .vco_div_cfg = edp_phy_vco_div_cfg_v4,
> - .swing_pre_emph_cfg = &edp_phy_swing_pre_emph_cfg_v5,
> + .dp_swing_pre_emph_cfg = &dp_phy_swing_pre_emph_cfg,
> + .edp_swing_pre_emph_cfg = &edp_phy_swing_pre_emph_cfg,
> .ver_ops = &qcom_edp_phy_ops_v4,
> };
>
> static const struct qcom_edp_phy_cfg sc7280_dp_phy_cfg = {
> .aux_cfg = edp_phy_aux_cfg_v4,
> .vco_div_cfg = edp_phy_vco_div_cfg_v4,
> + .dp_swing_pre_emph_cfg = &dp_phy_swing_pre_emph_cfg,
> + .edp_swing_pre_emph_cfg = &edp_phy_swing_pre_emph_cfg_v3,
> .ver_ops = &qcom_edp_phy_ops_v4,
> };
>
> static const struct qcom_edp_phy_cfg sc8280xp_dp_phy_cfg = {
> .aux_cfg = edp_phy_aux_cfg_v4,
> .vco_div_cfg = edp_phy_vco_div_cfg_v4,
> - .swing_pre_emph_cfg = &dp_phy_swing_pre_emph_cfg,
> + .dp_swing_pre_emph_cfg = &dp_phy_swing_pre_emph_cfg,
> + .edp_swing_pre_emph_cfg = &edp_phy_swing_pre_emph_cfg,
> .ver_ops = &qcom_edp_phy_ops_v4,
> };
>
> @@ -585,7 +598,8 @@ static const struct qcom_edp_phy_cfg sc8280xp_edp_phy_cfg = {
> .is_edp = true,
> .aux_cfg = edp_phy_aux_cfg_v4,
> .vco_div_cfg = edp_phy_vco_div_cfg_v4,
> - .swing_pre_emph_cfg = &edp_phy_swing_pre_emph_cfg,
> + .dp_swing_pre_emph_cfg = &dp_phy_swing_pre_emph_cfg,
> + .edp_swing_pre_emph_cfg = &edp_phy_swing_pre_emph_cfg,
> .ver_ops = &qcom_edp_phy_ops_v4,
> };
>
> @@ -766,7 +780,8 @@ static const struct phy_ver_ops qcom_edp_phy_ops_v6 = {
> static struct qcom_edp_phy_cfg x1e80100_phy_cfg = {
> .aux_cfg = edp_phy_aux_cfg_v4,
> .vco_div_cfg = edp_phy_vco_div_cfg_v4,
> - .swing_pre_emph_cfg = &dp_phy_swing_pre_emph_cfg,
> + .dp_swing_pre_emph_cfg = &dp_phy_swing_pre_emph_cfg,
> + .edp_swing_pre_emph_cfg = &edp_phy_swing_pre_emph_cfg,
> .ver_ops = &qcom_edp_phy_ops_v6,
> };
>
> @@ -945,7 +960,8 @@ static const struct phy_ver_ops qcom_edp_phy_ops_v8 = {
> static struct qcom_edp_phy_cfg glymur_phy_cfg = {
> .aux_cfg = edp_phy_aux_cfg_v8,
> .vco_div_cfg = edp_phy_vco_div_cfg_v8,
> - .swing_pre_emph_cfg = &edp_phy_swing_pre_emph_cfg_v5,
> + .dp_swing_pre_emph_cfg = &dp_phy_swing_pre_emph_cfg_v8,
> + .edp_swing_pre_emph_cfg = &edp_phy_swing_pre_emph_cfg,
> .ver_ops = &qcom_edp_phy_ops_v8,
> };
>
>
Hi, maintanier, just a gentle ping on this patch in case it slipped
through. Thanks!
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v4 1/2] dt-bindings: phy: qcom: Add CSI2 C-PHY/DPHY schema
From: Bryan O'Donoghue @ 2026-03-17 5:26 UTC (permalink / raw)
To: Vijay Kumar Tumati, Bryan O'Donoghue, Vinod Koul,
Kishon Vijay Abraham I, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Neil Armstrong
Cc: Vladimir Zapolskiy, linux-arm-msm, linux-phy, linux-media,
devicetree, linux-kernel
In-Reply-To: <5705b48a-fc24-4c5f-aa6d-40952f0070d9@oss.qualcomm.com>
On 16/03/2026 21:31, Vijay Kumar Tumati wrote:
> Hi Bryan,
>
> On 3/15/2026 4:52 PM, Bryan O'Donoghue wrote:
>> Add a base schema initially compatible with x1e80100 to describe MIPI CSI2
>> PHY devices.
>>
>> The hardware can support both C-PHY and D-PHY modes. The CSIPHY devices
>> have their own pinouts on the SoC as well as their own individual voltage
>> rails.
>>
>> The need to model voltage rails on a per-PHY basis leads us to define
>> CSIPHY devices as individual nodes.
>>
>> Two nice outcomes in terms of schema and DT arise from this change.
>>
>> 1. The ability to define on a per-PHY basis voltage rails.
>> 2. The ability to require those voltage.
>>
>> We have had a complete bodge upstream for this where a single set of
>> voltage rail for all CSIPHYs has been buried inside of CAMSS.
>>
>> Much like the I2C bus which is dedicated to Camera sensors - the CCI bus in
>> CAMSS parlance, the CSIPHY devices should be individually modelled.
>>
>> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
>> ---
>> .../bindings/phy/qcom,x1e80100-csi2-phy.yaml | 133 +++++++++++++++++++++
>> 1 file changed, 133 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/phy/qcom,x1e80100-csi2-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,x1e80100-csi2-phy.yaml
>> new file mode 100644
>> index 0000000000000..b83c2d65ebc6e
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/phy/qcom,x1e80100-csi2-phy.yaml
>> @@ -0,0 +1,133 @@
>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/phy/qcom,x1e80100-csi2-phy.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Qualcomm CSI2 PHY
>> +
>> +maintainers:
>> + - Bryan O'Donoghue <bod@kernel.org>
>> +
>> +description:
>> + Qualcomm MIPI CSI2 C-PHY/D-PHY combination PHY. Connects MIPI CSI2 sensors
>> + to Qualcomm's Camera CSI Decoder. The PHY supports both C-PHY and D-PHY
>> + modes.
>> +
>> +properties:
>> + compatible:
>> + const: qcom,x1e80100-csi2-phy
>> +
>> + reg:
>> + maxItems: 1
>> +
>> + "#phy-cells":
>> + const: 1
>> +
>> + clocks:
>> + maxItems: 4
>> +
>> + clock-names:
>> + items:
>> + - const: csiphy
>> + - const: csiphy_timer
>> + - const: camnoc_axi
>> + - const: cpas_ahb
>> +
>> + interrupts:
>> + maxItems: 1
>> +
>> + operating-points-v2:
>> + maxItems: 1
>> +
>> + power-domains:
>> + items:
>> + - description: TITAN TOP GDSC
>> + - description: MXC or MXA voltage rail
> Would it be better to provision MXA or MXC as an additional optional
> power domain? I see 'cam_cc_cphy_rx_clk_src', the parent of all CSIPHYx
> clocks, need all three power domains on this chipset.
I don't think this should be optional. Have the dts point to an "mx"
power-domain and then select which one is right for a PHY MX/MXA or MXC.
Your worst case here is some future PHY which has more or fewer PDs
which is then either a special case in this file or a whole new file for
that compat.
>> + - description: MMCX voltage rail
>> +
>> + power-domain-names:
>> + items:
>> + - const: top
>> + - const: mx
>> + - const: mmcx
>> +
>> + vdda-0p8-supply:
>> + description: Phandle to a 0.8V regulator supply to a PHY.
>> +
>> + vdda-1p2-supply:
>> + description: Phandle to 1.2V regulator supply to a PHY.
>> +
>> +required:
>> + - compatible
>> + - reg
>> + - "#phy-cells"
>> + - clocks
>> + - clock-names
>> + - interrupts
>> + - operating-points-v2
>> + - power-domains
>> + - power-domain-names
>> + - vdda-0p8-supply
>> + - vdda-1p2-supply
>> +
>> +additionalProperties: false
>> +
>> +examples:
>> + - |
>> + #include <dt-bindings/interrupt-controller/arm-gic.h>
>> + #include <dt-bindings/clock/qcom,x1e80100-camcc.h>
>> + #include <dt-bindings/clock/qcom,x1e80100-gcc.h>
>> + #include <dt-bindings/phy/phy.h>
>> + #include <dt-bindings/power/qcom,rpmhpd.h>
>> +
>> + csiphy@ace4000 {
>> + compatible = "qcom,x1e80100-csi2-phy";
>> + reg = <0x0ace4000 0x2000>;
>> + #phy-cells = <1>;
>> +
>> + clocks = <&camcc CAM_CC_CSIPHY0_CLK>,
>> + <&camcc CAM_CC_CSI0PHYTIMER_CLK>,
>> + <&camcc CAM_CC_CAMNOC_AXI_RT_CLK>,
>> + <&camcc CAM_CC_CPAS_AHB_CLK>;
>> + clock-names = "csiphy",
>> + "csiphy_timer",
>> + "camnoc_axi",
>> + "cpas_ahb";
> Although it's not a concern from my side, just want to be explicitly
> sure that everyone is happy with the clock names, just to avoid any
> changes later on when other modules are separated out.
These are the names we already use in CAMSS so ... they're good enough
to start from.
>> +
>> + operating-points-v2 = <&csiphy_opp_table>;
>> +
>> + interrupts = <GIC_SPI 477 IRQ_TYPE_EDGE_RISING>;
>> +
>> + power-domains = <&camcc CAM_CC_TITAN_TOP_GDSC>,
>> + <&rpmhpd RPMHPD_MX>,
>> + <&rpmhpd RPMHPD_MMCX>;
>> + power-domain-names = "top",
>> + "mx",
>> + "mmcx";
>> +
>> + vdda-0p8-supply = <&vreg_l2c_0p8>;
>> + vdda-1p2-supply = <&vreg_l1c_1p2>;
>> + };
>> +
>> + csiphy_opp_table: opp-table {
>> + compatible = "operating-points-v2";
>> +
>> + opp-300000000 {
>> + opp-hz = /bits/ 64 <300000000>;
>> + required-opps = <&rpmhpd_opp_low_svs_d1>,
>> + <&rpmhpd_opp_low_svs_d1>;
>> + };
>> +
>> + opp-400000000 {
>> + opp-hz = /bits/ 64 <400000000>;
>> + required-opps = <&rpmhpd_opp_low_svs>,
>> + <&rpmhpd_opp_low_svs>;
>> + };
>> +
>> + opp-480000000 {
>> + opp-hz = /bits/ 64 <480000000>;
>> + required-opps = <&rpmhpd_opp_low_svs>,
>> + <&rpmhpd_opp_low_svs>;
> 480mhz should be svs?
Yes you're right thanks for spotting.
>> + };
>> + };
>>
> Thanks,
> Vijay.
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 46/61] vfio: Prefer IS_ERR_OR_NULL over manual NULL check
From: Alex Williamson @ 2026-03-16 22:10 UTC (permalink / raw)
To: Philipp Hahn
Cc: amd-gfx, apparmor, bpf, ceph-devel, cocci, dm-devel, dri-devel,
gfs2, intel-gfx, intel-wired-lan, iommu, kvm, linux-arm-kernel,
linux-block, linux-bluetooth, linux-btrfs, linux-cifs, linux-clk,
linux-erofs, linux-ext4, linux-fsdevel, linux-gpio, linux-hyperv,
linux-input, linux-kernel, linux-leds, linux-media, linux-mips,
linux-mm, linux-modules, linux-mtd, linux-nfs, linux-omap,
linux-phy, linux-pm, linux-rockchip, linux-s390, linux-scsi,
linux-sctp, linux-security-module, linux-sh, linux-sound,
linux-stm32, linux-trace-kernel, linux-usb, linux-wireless,
netdev, ntfs3, samba-technical, sched-ext, target-devel,
tipc-discussion, v9fs, alex
In-Reply-To: <20260310-b4-is_err_or_null-v1-46-bd63b656022d@avm.de>
On Tue, 10 Mar 2026 12:49:12 +0100
Philipp Hahn <phahn-oss@avm.de> wrote:
> Prefer using IS_ERR_OR_NULL() over using IS_ERR() and a manual NULL
> check.
>
> Change generated with coccinelle.
>
> To: Alex Williamson <alex@shazbot.org>
> Cc: kvm@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Philipp Hahn <phahn-oss@avm.de>
> ---
> drivers/vfio/vfio_main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
> index 742477546b15d4dbaf9ebcfb2e67627db71521e0..d71922dfde5885967398deddec3e9e04b05adfec 100644
> --- a/drivers/vfio/vfio_main.c
> +++ b/drivers/vfio/vfio_main.c
> @@ -923,7 +923,7 @@ vfio_ioctl_device_feature_mig_device_state(struct vfio_device *device,
>
> /* Handle the VFIO_DEVICE_FEATURE_SET */
> filp = device->mig_ops->migration_set_state(device, mig.device_state);
> - if (IS_ERR(filp) || !filp)
> + if (IS_ERR_OR_NULL(filp))
> goto out_copy;
>
> return vfio_ioct_mig_return_fd(filp, arg, &mig);
>
As others have expressed in general, this doesn't seem to be cleaner
and tends to mask that we consider IS_ERR() and NULL as separate cases
in the goto. This code looks like it could use some refactoring, and
likely that refactoring should handle the IS_ERR() and NULL cases
separately, but conflating them here is not an improvement. Thanks,
Alex
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v4 1/2] dt-bindings: phy: qcom: Add CSI2 C-PHY/DPHY schema
From: Vijay Kumar Tumati @ 2026-03-16 21:31 UTC (permalink / raw)
To: Bryan O'Donoghue, Vinod Koul, Kishon Vijay Abraham I,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong
Cc: Bryan O'Donoghue, Vladimir Zapolskiy, linux-arm-msm,
linux-phy, linux-media, devicetree, linux-kernel
In-Reply-To: <20260315-x1e-csi2-phy-v4-1-90c09203888d@linaro.org>
Hi Bryan,
On 3/15/2026 4:52 PM, Bryan O'Donoghue wrote:
> Add a base schema initially compatible with x1e80100 to describe MIPI CSI2
> PHY devices.
>
> The hardware can support both C-PHY and D-PHY modes. The CSIPHY devices
> have their own pinouts on the SoC as well as their own individual voltage
> rails.
>
> The need to model voltage rails on a per-PHY basis leads us to define
> CSIPHY devices as individual nodes.
>
> Two nice outcomes in terms of schema and DT arise from this change.
>
> 1. The ability to define on a per-PHY basis voltage rails.
> 2. The ability to require those voltage.
>
> We have had a complete bodge upstream for this where a single set of
> voltage rail for all CSIPHYs has been buried inside of CAMSS.
>
> Much like the I2C bus which is dedicated to Camera sensors - the CCI bus in
> CAMSS parlance, the CSIPHY devices should be individually modelled.
>
> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
> ---
> .../bindings/phy/qcom,x1e80100-csi2-phy.yaml | 133 +++++++++++++++++++++
> 1 file changed, 133 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/phy/qcom,x1e80100-csi2-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,x1e80100-csi2-phy.yaml
> new file mode 100644
> index 0000000000000..b83c2d65ebc6e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/qcom,x1e80100-csi2-phy.yaml
> @@ -0,0 +1,133 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/phy/qcom,x1e80100-csi2-phy.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Qualcomm CSI2 PHY
> +
> +maintainers:
> + - Bryan O'Donoghue <bod@kernel.org>
> +
> +description:
> + Qualcomm MIPI CSI2 C-PHY/D-PHY combination PHY. Connects MIPI CSI2 sensors
> + to Qualcomm's Camera CSI Decoder. The PHY supports both C-PHY and D-PHY
> + modes.
> +
> +properties:
> + compatible:
> + const: qcom,x1e80100-csi2-phy
> +
> + reg:
> + maxItems: 1
> +
> + "#phy-cells":
> + const: 1
> +
> + clocks:
> + maxItems: 4
> +
> + clock-names:
> + items:
> + - const: csiphy
> + - const: csiphy_timer
> + - const: camnoc_axi
> + - const: cpas_ahb
> +
> + interrupts:
> + maxItems: 1
> +
> + operating-points-v2:
> + maxItems: 1
> +
> + power-domains:
> + items:
> + - description: TITAN TOP GDSC
> + - description: MXC or MXA voltage rail
Would it be better to provision MXA or MXC as an additional optional
power domain? I see 'cam_cc_cphy_rx_clk_src', the parent of all CSIPHYx
clocks, need all three power domains on this chipset.
> + - description: MMCX voltage rail
> +
> + power-domain-names:
> + items:
> + - const: top
> + - const: mx
> + - const: mmcx
> +
> + vdda-0p8-supply:
> + description: Phandle to a 0.8V regulator supply to a PHY.
> +
> + vdda-1p2-supply:
> + description: Phandle to 1.2V regulator supply to a PHY.
> +
> +required:
> + - compatible
> + - reg
> + - "#phy-cells"
> + - clocks
> + - clock-names
> + - interrupts
> + - operating-points-v2
> + - power-domains
> + - power-domain-names
> + - vdda-0p8-supply
> + - vdda-1p2-supply
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> + #include <dt-bindings/clock/qcom,x1e80100-camcc.h>
> + #include <dt-bindings/clock/qcom,x1e80100-gcc.h>
> + #include <dt-bindings/phy/phy.h>
> + #include <dt-bindings/power/qcom,rpmhpd.h>
> +
> + csiphy@ace4000 {
> + compatible = "qcom,x1e80100-csi2-phy";
> + reg = <0x0ace4000 0x2000>;
> + #phy-cells = <1>;
> +
> + clocks = <&camcc CAM_CC_CSIPHY0_CLK>,
> + <&camcc CAM_CC_CSI0PHYTIMER_CLK>,
> + <&camcc CAM_CC_CAMNOC_AXI_RT_CLK>,
> + <&camcc CAM_CC_CPAS_AHB_CLK>;
> + clock-names = "csiphy",
> + "csiphy_timer",
> + "camnoc_axi",
> + "cpas_ahb";
Although it's not a concern from my side, just want to be explicitly
sure that everyone is happy with the clock names, just to avoid any
changes later on when other modules are separated out.
> +
> + operating-points-v2 = <&csiphy_opp_table>;
> +
> + interrupts = <GIC_SPI 477 IRQ_TYPE_EDGE_RISING>;
> +
> + power-domains = <&camcc CAM_CC_TITAN_TOP_GDSC>,
> + <&rpmhpd RPMHPD_MX>,
> + <&rpmhpd RPMHPD_MMCX>;
> + power-domain-names = "top",
> + "mx",
> + "mmcx";
> +
> + vdda-0p8-supply = <&vreg_l2c_0p8>;
> + vdda-1p2-supply = <&vreg_l1c_1p2>;
> + };
> +
> + csiphy_opp_table: opp-table {
> + compatible = "operating-points-v2";
> +
> + opp-300000000 {
> + opp-hz = /bits/ 64 <300000000>;
> + required-opps = <&rpmhpd_opp_low_svs_d1>,
> + <&rpmhpd_opp_low_svs_d1>;
> + };
> +
> + opp-400000000 {
> + opp-hz = /bits/ 64 <400000000>;
> + required-opps = <&rpmhpd_opp_low_svs>,
> + <&rpmhpd_opp_low_svs>;
> + };
> +
> + opp-480000000 {
> + opp-hz = /bits/ 64 <480000000>;
> + required-opps = <&rpmhpd_opp_low_svs>,
> + <&rpmhpd_opp_low_svs>;
480mhz should be svs?
> + };
> + };
>
Thanks,
Vijay.
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 50/61] iommu: Prefer IS_ERR_OR_NULL over manual NULL check
From: Robin Murphy @ 2026-03-16 13:30 UTC (permalink / raw)
To: Philipp Hahn, amd-gfx, apparmor, bpf, ceph-devel, cocci, dm-devel,
dri-devel, gfs2, intel-gfx, intel-wired-lan, iommu, kvm,
linux-arm-kernel, linux-block, linux-bluetooth, linux-btrfs,
linux-cifs, linux-clk, linux-erofs, linux-ext4, linux-fsdevel,
linux-gpio, linux-hyperv, linux-input, linux-kernel, linux-leds,
linux-media, linux-mips, linux-mm, linux-modules, linux-mtd,
linux-nfs, linux-omap, linux-phy, linux-pm, linux-rockchip,
linux-s390, linux-scsi, linux-sctp, linux-security-module,
linux-sh, linux-sound, linux-stm32, linux-trace-kernel, linux-usb,
linux-wireless, netdev, ntfs3, samba-technical, sched-ext,
target-devel, tipc-discussion, v9fs
Cc: Joerg Roedel, Will Deacon
In-Reply-To: <20260310-b4-is_err_or_null-v1-50-bd63b656022d@avm.de>
On 2026-03-10 11:49 am, Philipp Hahn wrote:
> Prefer using IS_ERR_OR_NULL() over using IS_ERR() and a manual NULL
> check.
AFAICS it doesn't look possible for the argument to be anything other
than valid at both callsites, so *both* conditions here seem in fact to
be entirely redundant.
> Change generated with coccinelle.
Please use coccinelle responsibly. Mechanical changes are great for
scripted API updates, but for cleanup, whilst it's ideal for *finding*
areas of code that are worth looking at, the code then wants actually
looking at, in its whole context, because meaningful cleanup often goes
deeper than trivial replacement.
In particular, anywhere IS_ERR_OR_NULL() is genuinely relevant is
usually a sign of bad interface design, so if you're looking at this
then you really should be looking first and foremost to remove any
checks that are already unnecessary, and for the remainder, to see if
the thing being checked can be improved to not mix the two different
styles. That would be constructive and (usually) welcome cleanup. Simply
churning a bunch of code with this ugly macro that's arguably less
readable than what it replaces, not so much.
Thanks,
Robin.
> To: Joerg Roedel <joro@8bytes.org>
> To: Will Deacon <will@kernel.org>
> To: Robin Murphy <robin.murphy@arm.com>
> Cc: iommu@lists.linux.dev
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Philipp Hahn <phahn-oss@avm.de>
> ---
> drivers/iommu/omap-iommu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
> index 8231d7d6bb6a9202025643639a6b28e6faa84659..500a42b57a997696ff37c76f028a717ab71d01f9 100644
> --- a/drivers/iommu/omap-iommu.c
> +++ b/drivers/iommu/omap-iommu.c
> @@ -881,7 +881,7 @@ static int omap_iommu_attach(struct omap_iommu *obj, u32 *iopgd)
> **/
> static void omap_iommu_detach(struct omap_iommu *obj)
> {
> - if (!obj || IS_ERR(obj))
> + if (IS_ERR_OR_NULL(obj))
> return;
>
> spin_lock(&obj->iommu_lock);
>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH] phy: google-usb: Fix runtime PM cleanup on probe failure
From: Felix Gu @ 2026-03-16 13:11 UTC (permalink / raw)
To: Peter Griffin, André Draszik, Tudor Ambarus, Vinod Koul,
Neil Armstrong, Naveen Kumar, Joy Chakraborty, Roy Luo
Cc: linux-arm-kernel, linux-samsung-soc, linux-phy, linux-kernel,
Felix Gu
In google_usb_phy_probe(), if typec_switch_register() fails,
pm_runtime_disable() is not called, leading to an unbalanced
runtime PM state on probe failure.
Switch to devm_pm_runtime_enable() to ensure that runtime PM is
automatically disabled both on probe failure and during driver
removal.
Fixes: cbce66669c82 ("phy: Add Google Tensor SoC USB PHY driver")
Signed-off-by: Felix Gu <ustc.gu@gmail.com>
---
drivers/phy/phy-google-usb.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/phy/phy-google-usb.c b/drivers/phy/phy-google-usb.c
index ab20bc20f19e..79480f8b110e 100644
--- a/drivers/phy/phy-google-usb.c
+++ b/drivers/phy/phy-google-usb.c
@@ -251,7 +251,9 @@ static int google_usb_phy_probe(struct platform_device *pdev)
return dev_err_probe(dev, PTR_ERR(phy_provider),
"failed to register phy provider\n");
- pm_runtime_enable(dev);
+ ret = devm_pm_runtime_enable(dev);
+ if (ret)
+ return dev_err_probe(dev, ret, "Failed to enable runtime PM\n");
sw_desc.fwnode = dev_fwnode(dev);
sw_desc.drvdata = gphy;
@@ -271,7 +273,6 @@ static void google_usb_phy_remove(struct platform_device *pdev)
struct google_usb_phy *gphy = dev_get_drvdata(&pdev->dev);
typec_switch_unregister(gphy->sw);
- pm_runtime_disable(&pdev->dev);
}
static const struct of_device_id google_usb_phy_of_match[] = {
---
base-commit: b84a0ebe421ca56995ff78b66307667b62b3a900
change-id: 20260316-google-3acfa2f3de9d
Best regards,
--
Felix Gu <ustc.gu@gmail.com>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* Re: [PATCH v4 1/2] dt-bindings: phy: qcom: Add CSI2 C-PHY/DPHY schema
From: Bryan O'Donoghue @ 2026-03-16 12:09 UTC (permalink / raw)
To: Konrad Dybcio, Dmitry Baryshkov, Vladimir Zapolskiy
Cc: Vinod Koul, Kishon Vijay Abraham I, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Bryan O'Donoghue, linux-arm-msm, linux-phy, linux-media,
devicetree, linux-kernel
In-Reply-To: <a685b880-0239-4804-adeb-c63204a91142@oss.qualcomm.com>
On 16/03/2026 10:49, Konrad Dybcio wrote:
>>> On Hamoa the CSIPHY supply voltage is 0.88-0.92, so it is 0p9 rather than 0p8.
>> What is its name in the schematics or in the datasheet?
> VDD_A_CSI_n_0P9
>
> so vdda-0p9 seems fitting
>
> Konrad
(0.88+0.92) / 2 == 0.9
I'm happy with the average.
---
bod
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v4 2/2] phy: qcom-mipi-csi2: Add a CSI2 MIPI DPHY driver
From: Bryan O'Donoghue @ 2026-03-16 12:04 UTC (permalink / raw)
To: Krzysztof Kozlowski, Vinod Koul, Kishon Vijay Abraham I,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong
Cc: Bryan O'Donoghue, Vladimir Zapolskiy, linux-arm-msm,
linux-phy, linux-media, devicetree, linux-kernel
In-Reply-To: <55db5547-96b0-4d3a-90bf-3d2b289abaa3@kernel.org>
On 16/03/2026 10:12, Krzysztof Kozlowski wrote:
>> + if (IS_ERR(csi2phy->pds[i])) {
> API is terrible, but it does return NULL.
Ah b******s... thanks missed that completely.
---
bod
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v1 1/1] arm64: dts: qcom: hamoa: Move PCIe PERST and Wake GPIOs to port nodes
From: Konrad Dybcio @ 2026-03-16 11:16 UTC (permalink / raw)
To: Ziyue Zhang, andersson, konradybcio, robh, krzk+dt, conor+dt,
jingoohan1, mani, lpieralisi, kwilczynski, bhelgaas, johan+linaro,
vkoul, kishon, neil.armstrong, abel.vesa, kw
Cc: linux-arm-msm, devicetree, linux-kernel, linux-pci, linux-phy,
qiang.yu, quic_krichai, quic_vbadigan
In-Reply-To: <20260313094618.1361418-1-ziyue.zhang@oss.qualcomm.com>
On 3/13/26 10:46 AM, Ziyue Zhang wrote:
> Commit 960609b22be5 ("arm64: dts: qcom: hamoa: Move PHY, PERST, and Wake
> GPIOs to PCIe port nodes and add port Nodes for all PCIe ports") did not
> convert all Hamoa‑based platforms to the new method of defining PERST and
> Wake GPIOs in the PCIe root port nodes.
>
> Without the change PCIe probe will fail. The probe failure happens because
> the PHY stays in the controller node while the PERST/Wake GPIOs were moved
> to the port nodes.
>
> This fixes probe failures seen on the following platforms:
> - x1-hp-omnibook-x14
> - x1-microsoft-denali
> - x1e80100-lenovo-yoga-slim7x
> - x1e80100-medion-sprchrgd-14-s1
> - x1p42100-lenovo-thinkbook-16
> - x1-asus-zenbook-a14
> - x1-crd
> - x1-dell-thena
>
> Fixes: 960609b22be5 ("arm64: dts: qcom: hamoa: Move PHY, PERST, and Wake GPIOs to PCIe port nodes and add port Nodes for all PCIe ports")
> Signed-off-by: Ziyue Zhang <ziyue.zhang@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 v4 1/2] dt-bindings: phy: qcom: Add CSI2 C-PHY/DPHY schema
From: Konrad Dybcio @ 2026-03-16 10:49 UTC (permalink / raw)
To: Dmitry Baryshkov, Vladimir Zapolskiy
Cc: Bryan O'Donoghue, Vinod Koul, Kishon Vijay Abraham I,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Bryan O'Donoghue, linux-arm-msm, linux-phy, linux-media,
devicetree, linux-kernel
In-Reply-To: <wjsnwdyoptrfbmdkqlcepzekfbccv6vsfop5wm37m56rtlevfk@jkbievryoo2j>
On 3/16/26 3:45 AM, Dmitry Baryshkov wrote:
> On Mon, Mar 16, 2026 at 03:58:14AM +0200, Vladimir Zapolskiy wrote:
>> On 3/16/26 01:52, Bryan O'Donoghue wrote:
>>> Add a base schema initially compatible with x1e80100 to describe MIPI CSI2
>>> PHY devices.
>>>
>>> The hardware can support both C-PHY and D-PHY modes. The CSIPHY devices
>>> have their own pinouts on the SoC as well as their own individual voltage
>>> rails.
>>>
>>> The need to model voltage rails on a per-PHY basis leads us to define
>>> CSIPHY devices as individual nodes.
>>>
>>> Two nice outcomes in terms of schema and DT arise from this change.
>>>
>>> 1. The ability to define on a per-PHY basis voltage rails.
>>> 2. The ability to require those voltage.
>>>
>>> We have had a complete bodge upstream for this where a single set of
>>> voltage rail for all CSIPHYs has been buried inside of CAMSS.
>>>
>>> Much like the I2C bus which is dedicated to Camera sensors - the CCI bus in
>>> CAMSS parlance, the CSIPHY devices should be individually modelled.
>>>
>>> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
>>> ---
>>> .../bindings/phy/qcom,x1e80100-csi2-phy.yaml | 133 +++++++++++++++++++++
>>> 1 file changed, 133 insertions(+)
>>>
>>> +
>>> + vdda-0p8-supply:
>>> + description: Phandle to a 0.8V regulator supply to a PHY.
>>
>> On Hamoa the CSIPHY supply voltage is 0.88-0.92, so it is 0p9 rather than 0p8.
>
> What is its name in the schematics or in the datasheet?
VDD_A_CSI_n_0P9
so vdda-0p9 seems fitting
Konrad
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v4 2/2] phy: qcom-mipi-csi2: Add a CSI2 MIPI DPHY driver
From: Krzysztof Kozlowski @ 2026-03-16 10:12 UTC (permalink / raw)
To: Bryan O'Donoghue, Vinod Koul, Kishon Vijay Abraham I,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong
Cc: Bryan O'Donoghue, Vladimir Zapolskiy, linux-arm-msm,
linux-phy, linux-media, devicetree, linux-kernel
In-Reply-To: <20260315-x1e-csi2-phy-v4-2-90c09203888d@linaro.org>
On 16/03/2026 00:52, Bryan O'Donoghue wrote:
> +
> + csi2phy = devm_kzalloc(dev, sizeof(*csi2phy), GFP_KERNEL);
> + if (!csi2phy)
> + return -ENOMEM;
> +
> + csi2phy->dev = dev;
> + csi2phy->soc_cfg = device_get_match_data(&pdev->dev);
> +
> + if (!csi2phy->soc_cfg)
> + return -EINVAL;
> +
> + num_clk = csi2phy->soc_cfg->num_clk;
> + csi2phy->clks = devm_kzalloc(dev, sizeof(*csi2phy->clks) * num_clk, GFP_KERNEL);
> + if (!csi2phy->clks)
> + return -ENOMEM;
> +
> + num_pds = csi2phy->soc_cfg->num_genpd_names;
> + if (!num_pds)
> + return -EINVAL;
> +
> + csi2phy->pds = devm_kzalloc(dev, sizeof(*csi2phy->pds) * num_pds, GFP_KERNEL);
> + if (!csi2phy->pds)
> + return -ENOMEM;
> +
> + for (i = 0; i < num_pds; i++) {
> + csi2phy->pds[i] = dev_pm_domain_attach_by_name(dev,
> + csi2phy->soc_cfg->genpd_names[i]);
> + if (IS_ERR(csi2phy->pds[i])) {
API is terrible, but it does return NULL. Look at other uses of it. Or
read review of sashiko of your patchset.
> + return dev_err_probe(dev, PTR_ERR(csi2phy->pds[i]),
> + "Failed to attach %s\n",
> + csi2phy->soc_cfg->genpd_names[i]);
> + }
Best regards,
Krzysztof
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v9 03/23] dt-bindings: ufs: mediatek,ufs: Add mt8196 variant
From: AngeloGioacchino Del Regno @ 2026-03-16 9:34 UTC (permalink / raw)
To: Rob Herring, Nicolas Frattaroli
Cc: Martin K. Petersen, Alim Akhtar, Avri Altman, Bart Van Assche,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger, Chunfeng Yun,
Vinod Koul, Kishon Vijay Abraham I, Peter Wang, Stanley Jhu,
James E.J. Bottomley, Philipp Zabel, Liam Girdwood, Mark Brown,
Chaotian Jing, Neil Armstrong, Louis-Alexis Eyraud, kernel,
linux-scsi, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, linux-phy, Conor Dooley
In-Reply-To: <CAL_JsqKGxrNuaTb9+n3ZYjAdY=UHC6z-neXK-aieTXeROCN5og@mail.gmail.com>
Il 10/03/26 19:21, Rob Herring ha scritto:
> On Mon, Mar 9, 2026 at 5:04 AM Nicolas Frattaroli
> <nicolas.frattaroli@collabora.com> wrote:
>>
>> On Saturday, 7 March 2026 19:01:17 Central European Standard Time Martin K. Petersen wrote:
>>>
>>> Nicolas,
>>>
>>>>> "ufs" is redundant as all the clocks are for UFS. Same comment on prior
>>>>> patch.
>>>>
>>>> Is this naming a big enough concern to block this series with two
>>>> explicit acks on this patch that fixes a wholly broken and useless
>>>> binding?
>>>
>>> It is if it comes from one of the DT maintainers.
>>>
>>>> I am trying to put out this dumpster fire of a downstream turd that
>>>> made its way into mainline as the review process has been completely
>>>> subverted, and is only getting worse with each passing month
>>>
>>> This has to stop. Please read Documentation/process/code-of-conduct.rst.
>
> I have little doubt that that is an accurate description of
> downstream. And if properties are getting added without bindings, then
> that is certainly a problem that should be complained about.
>
>>>
>>>
>>
>> I apologise for my tone, it's my frustration getting the better of me.
>>
>> I'll be handing off this series to someone else, so you won't have to
>> deal with me anymore.
>>
>> I do ask however that you don't apply patches from MediaTek blindly;
>> if there's code to read an OF property, and that OF property is not
>> in the binding, then the patch should be rejected, even if there's an
>> Ack from the MediaTek maintainer.
>
> There's functionality to find undocumented compatibles in kernel code
> (make dt_compatible_check), but not properties. Sounds like I need to
> add that.
Rob: yes please, that would help a lot in general, not just with this UFS driver.
Cheers,
Angelo
>
> Rob
--
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