* Re: [PATCH v7 20/23] scsi: ufs: mediatek: Back up idle timer in per-instance struct
From: Peter Wang (王信友) @ 2026-03-03 8:01 UTC (permalink / raw)
To: chu.stanley@gmail.com, robh@kernel.org,
Chunfeng Yun (云春峰), kishon@kernel.org,
James.Bottomley@HansenPartnership.com, bvanassche@acm.org,
AngeloGioacchino Del Regno,
Chaotian Jing (井朝天), conor+dt@kernel.org,
lgirdwood@gmail.com, nicolas.frattaroli@collabora.com,
vkoul@kernel.org, krzk+dt@kernel.org, p.zabel@pengutronix.de,
alim.akhtar@samsung.com, neil.armstrong@linaro.org,
matthias.bgg@gmail.com, avri.altman@wdc.com, broonie@kernel.org,
martin.petersen@oracle.com
Cc: linux-scsi@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-phy@lists.infradead.org, linux-mediatek@lists.infradead.org,
Louis-Alexis Eyraud, kernel@collabora.com
In-Reply-To: <48e8f40b-f5f3-42b5-a97b-7a25d1dc0fb8@collabora.com>
On Thu, 2026-02-26 at 11:36 +0100, AngeloGioacchino Del Regno wrote:
>
> Okay, does "saved_auto_hibern8_idle_tmr" sound good for you instead?
>
> Regards,
> Angelo
>
>
Hi AngeloGioacchino,
I’m fine with saved_auto_hibern8_idle_tmr, but it is more
verbose compared to saved_ahit.
Thanks
Peter
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v7 16/23] scsi: ufs: mediatek: Clean up logging prints
From: Peter Wang (王信友) @ 2026-03-03 8:06 UTC (permalink / raw)
To: chu.stanley@gmail.com, robh@kernel.org,
Chunfeng Yun (云春峰), kishon@kernel.org,
James.Bottomley@hansenpartnership.com, bvanassche@acm.org,
AngeloGioacchino Del Regno,
Chaotian Jing (井朝天), conor+dt@kernel.org,
lgirdwood@gmail.com, nicolas.frattaroli@collabora.com,
vkoul@kernel.org, krzk+dt@kernel.org, p.zabel@pengutronix.de,
alim.akhtar@samsung.com, neil.armstrong@linaro.org,
matthias.bgg@gmail.com, avri.altman@wdc.com, broonie@kernel.org,
martin.petersen@oracle.com
Cc: linux-scsi@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-phy@lists.infradead.org, linux-mediatek@lists.infradead.org,
Louis-Alexis Eyraud, kernel@collabora.com
In-Reply-To: <84f22f00-e3eb-4ea5-999e-260c81f29338@collabora.com>
On Thu, 2026-02-26 at 11:45 +0100, AngeloGioacchino Del Regno wrote:
> Sorry Peter, but I'd argue that the users don't care about how much
> and when
> their UFS device resets. Users just want to use a device, without
> caring
> about any implementation detail.
> The spirit is: "radio silence as long as everything works good".
>
> Power users might want to check the kernel log in a problematic
> scenario to
> seek for a message that says that "something went horribly wrong",
> but other
> than developers, nobody cares about when UFS resets.
>
> From a developer standpoint, I do agree with you in that we do *not*
> want to
> see device resets occurring repeatedly, but we're talking about a
> user here.
>
> See it like this... imagine if all of the device drivers in the Linux
> kernel
> would say "device reset done": how many devices are present in one
> SoC (of
> course, ignoring subdevices on a board)?
>
> Of all those many devices, if all of them would print a message
> saying that
> their reset is done (and operation is ok), the kernel log would get
> quite a
> bit clogged, you'd need to have a bigger RAM carveout just for ..
> well, the
> kernel log itself, and then you'd have to grep the log, hoping to
> find the
> one single line that helps you finding an issue that you're having.
>
> This is the reason why keeping any message that is not exactly a
> *single*
> indication of an error (so, an actual issue) as a dev_dbg() is a
> sensible
> thing to do (and of course, with dynamic debug in the kernel, you can
> always
> activate that on-the-fly without recompiling to verify functionality
> should
> you have any immediate doubt).
>
> So while I agree about your reasons, I very strongly disagree about
> having
> this message as a dev_info(), nor anything else that is not dev_dbg()
> really.
>
> Regards,
> Angelo
Hi AngeloGioacchino,
I am not sure if you know that when UFS encounters an error,
such as a UIC error or timeout, some errors can be so severe
that they cannot be recovered without a reset. In these cases,
we need to perform error handling or recovery by resetting
the device.
I agree that "radio silence is preferable as long as everything
works well." However, users may sometimes wonder why their
device (phone, tablet, laptop, etc.) shows good IO performance
in tests, but the actual user experience is poor (laggy).
This log can provide users with an explanation for IO lag
during usage.
I also agree that many devices are present in a single SoC, but
I don't think there is much reset information throughout the system.
Each device should ensure that the likelihood of a reset (error)
is minimized.
Thanks.
Peter
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v14 7/9] drm/rockchip: cdn-dp: Add multiple bridges to support PHY port selection
From: Luca Ceresoli @ 2026-03-03 8:52 UTC (permalink / raw)
To: Chaoyi Chen
Cc: Heikki Krogerus, Greg Kroah-Hartman, Dmitry Baryshkov, Peter Chen,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Vinod Koul,
Kishon Vijay Abraham I, Heiko Stuebner, Sandy Huang, Andy Yan,
Yubing Zhang, Frank Wang, Andrzej Hajda, Neil Armstrong,
Robert Foss, Laurent Pinchart, Jonas Karlman, Jernej Skrabec,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Amit Sunil Dhamne, Dragan Simic, Johan Jonker,
Diederik de Haas, Peter Robinson, linux-usb, devicetree,
linux-kernel, linux-phy, linux-arm-kernel, linux-rockchip,
dri-devel
In-Reply-To: <601a8b51-7411-429d-91a1-0633cabce9ee@rock-chips.com>
Hello Chaoyi,
On Tue Mar 3, 2026 at 1:44 AM CET, Chaoyi Chen wrote:
>>> +static int cdn_dp_parse_next_bridge_dt(struct cdn_dp_device *dp)
>>> +{
>>> + struct device_node *np = dp->dev->of_node;
>>> + struct device_node *port __free(device_node) = of_graph_get_port_by_id(np, 1);
>>> + struct drm_bridge *bridge;
>>> + int count = 0;
>>> + int ret = 0;
>>> + int i;
>>> +
>>> + /* If device use extcon, do not use hpd bridge */
>>> + for (i = 0; i < dp->ports; i++) {
>>> + if (dp->port[i]->extcon) {
>>> + dp->bridge_count = 1;
>>> + return 0;
>>> + }
>>> + }
>>> +
>>> + /* One endpoint may correspond to one next bridge. */
>>> + for_each_of_graph_port_endpoint(port, dp_ep) {
>>> + struct device_node *next_bridge_node __free(device_node) =
>>> + of_graph_get_remote_port_parent(dp_ep);
>>> +
>>> + bridge = of_drm_find_bridge(next_bridge_node);
>>> + if (!bridge) {
>>> + ret = -EPROBE_DEFER;
>>> + goto out;
>>> + }
>>> +
>>> + drm_bridge_get(bridge);
>>> + dp->next_bridge_valid = true;
>>> + dp->next_bridge_list[count] = bridge;
>>
>> Correct, but the drm_bridge_get() slightly far away from the assignement is
>> a bit misleading. I hadn't seen it initially so I suspected a missing get.
>>
>> I suggest to do it in a single statement, for clarity:
>>
>> dp->next_bridge_list[count] = bridgedrm_bridge_get(bridge);
>>
>
> I think the bridgedrm_bridge_get here seems to be a typo?
Oops, of course! :)
As you probably guessed, I was meaning:
dp->next_bridge_list[count] = drm_bridge_get(bridge);
> Anyway, thank you very much for your efforts on the bridge lifetime.
> I will fix this in the next version :)
Thanks!
Luca
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
--
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] dt-bindings: phy: qcom: Add CSI2 C-PHY/DPHY schema
From: Bryan O'Donoghue @ 2026-03-03 9:27 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: <c85fe457-c140-441c-93ed-342dce32e604@oss.qualcomm.com>
On 03/03/2026 01:51, Vijay Kumar Tumati wrote:
> Hi Bryan,
>
> On 2/26/2026 4:34 AM, 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 | 114 +++++++++++++++++++++
>> 1 file changed, 114 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..c937d26ccbda9
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/phy/qcom,x1e80100-csi2-phy.yaml
>> @@ -0,0 +1,114 @@
>> +# 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:
>> + maxItems: 1
>> +
>> + 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
>> + - 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>
>> +
>> + 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";
>> +
>> + operating-points-v2 = <&csiphy_opp_table>;
>> +
>> + interrupts = <GIC_SPI 477 IRQ_TYPE_EDGE_RISING>;
>> +
>> + power-domains = <&camcc CAM_CC_TITAN_TOP_GDSC>;
> As we are cleaning up the PHY device nodes, we should consider fixing
> the power domains as well. Although TOP GDSC is defined as a power
> domain, it is not the power source for the PHY devices. Rather, it is
> the MMCX, MXC and optionally MXA based on the architecture (Refer to
> 'Voltage rail' column for PHY clocks in IPCAT).
Feel free to send me a qcom laptop and I will :)
From memory though I _thought_ only the TOP was required for the PHY.
I'd be grateful if you could confirm yourself in ipcat.
- TITAN_TOP_GDSC
- MXC
- MMCX
- MXA - first time I've heard of this rail, from memory I don't remember
having seen this in ipcat when I could do so.
There is no
> parent-child relationship between the TOP GDSC and these in the clock
> driver and it was just working as the required power rails are getting
> enabled by/for other MM devices.
Well only the GDSC is supplied by the clock controller.
>> +
>> + vdda-0p8-supply = <&vreg_l2c_0p8>;
>> + vdda-1p2-supply = <&vreg_l1c_1p2>;
>> + };
>> +
>> + csiphy_opp_table: opp-table-csiphy {
>> + compatible = "operating-points-v2";
>> +
>> + opp-300000000 {
>> + opp-hz = /bits/ 64 <300000000>;
>> + required-opps = <&rpmhpd_opp_low_svs_d1>;
>> + };
>> +
>> + opp-400000000 {
>> + opp-hz = /bits/ 64 <400000000>;
>> + required-opps = <&rpmhpd_opp_low_svs>;
>> + };
>> +
>> + opp-480000000 {
>> + opp-hz = /bits/ 64 <480000000>;
>> + required-opps = <&rpmhpd_opp_low_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 v3 1/2] dt-bindings: phy: qcom: Add CSI2 C-PHY/DPHY schema
From: Bryan O'Donoghue @ 2026-03-03 9:30 UTC (permalink / raw)
To: Bryan O'Donoghue, 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: <c85fe457-c140-441c-93ed-342dce32e604@oss.qualcomm.com>
On 03/03/2026 09:27, Bryan O'Donoghue wrote:
> - MXA - first time I've heard of this rail, from memory I don't remember
> having seen this in ipcat when I could do so.
Yeah no MXA isn't a required vote.
https://lore.kernel.org/linux-arm-msm/9ff1645f-b2c9-4c1a-ae2d-96af416b08d9@oss.qualcomm.com/
---
bod
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v7 20/23] scsi: ufs: mediatek: Back up idle timer in per-instance struct
From: Nicolas Frattaroli @ 2026-03-03 10:15 UTC (permalink / raw)
To: chu.stanley@gmail.com, robh@kernel.org,
Chunfeng Yun (云春峰), kishon@kernel.org,
James.Bottomley@HansenPartnership.com, bvanassche@acm.org,
AngeloGioacchino Del Regno,
Chaotian Jing (井朝天), conor+dt@kernel.org,
lgirdwood@gmail.com, vkoul@kernel.org, krzk+dt@kernel.org,
p.zabel@pengutronix.de, alim.akhtar@samsung.com,
neil.armstrong@linaro.org, matthias.bgg@gmail.com,
avri.altman@wdc.com, broonie@kernel.org,
martin.petersen@oracle.com, Peter Wang (王信友)
Cc: linux-scsi@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-phy@lists.infradead.org, linux-mediatek@lists.infradead.org,
Louis-Alexis Eyraud, kernel@collabora.com
In-Reply-To: <0bef3e1592e64f74e6a6fd8ef59129ac71b307e4.camel@mediatek.com>
On Tuesday, 3 March 2026 09:01:14 Central European Standard Time Peter Wang (王信友) wrote:
> On Thu, 2026-02-26 at 11:36 +0100, AngeloGioacchino Del Regno wrote:
> >
> > Okay, does "saved_auto_hibern8_idle_tmr" sound good for you instead?
> >
> > Regards,
> > Angelo
> >
> >
>
> Hi AngeloGioacchino,
>
> I’m fine with saved_auto_hibern8_idle_tmr, but it is more
> verbose compared to saved_ahit.
>
> Thanks
> Peter
>
Yeah no I won't change this, this is pointless bikeshedding.
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: phy: qcom,sc8280xp-qmp-pcie-phy: Add vdda-refgen supply for Glymur
From: Konrad Dybcio @ 2026-03-03 11:14 UTC (permalink / raw)
To: Qiang Yu, Dmitry Baryshkov
Cc: Krzysztof Kozlowski, Vinod Koul, Neil Armstrong, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-msm, linux-phy,
devicetree, linux-kernel
In-Reply-To: <aaVkpKZcrNM7k4Xm@hu-qianyu-lv.qualcomm.com>
On 3/2/26 11:21 AM, Qiang Yu wrote:
> On Fri, Feb 13, 2026 at 07:47:36PM +0200, Dmitry Baryshkov wrote:
>> On Wed, Feb 11, 2026 at 07:32:23PM -0800, Qiang Yu wrote:
>>> On Mon, Feb 09, 2026 at 09:06:23AM +0100, Krzysztof Kozlowski wrote:
>>>> On Sun, Feb 08, 2026 at 08:49:39PM -0800, Qiang Yu wrote:
>>>>> The PCIe QMP PHYs on Glymur require stable reference voltage provided by
>>>>> refgen. The refgen itself requires two separate power supplies:
>>>>> vdda-refgen0p9 and vdda-refgen1p2.
>>>>>
>>>>> Since there is no dedicated driver for REFGEN, add vdda-refgen0p9-supply
>>>>
>>>> How does the driver matter for the bindings? If I add dedicated driver
>>>> for refgen, then I change the bindings?
>>>
>>> Yeah, I know that dt-bindings should describe hardware, not software. But
>>> what I meant to say is that the refgen is different from qref which is
>>> controlled via TCSR registers and its LDOs are requested to vote in
>>> tcsrcc driver. The refgen doesn't required register setting and it doesn't
>>> have dedicated driver, so we vote its LDOs in phy driver. I will avoid
>>> this statement in next version.
>>
>> I must admit, I could not find references to the refgen in any of Glymur
>> PCIe-related HPGs.
>>
>>>
>>>>
>>>> There is qcom,sc8280xp-refgen-regulator so why there cannot be
>>>> qcom,x1e-refgen-regulator?
>>>
>>> I think we can and it seems better because the refgen for pcie phy also
>>> supplies reference voltage to other modules like usb. But I checked the
>>> qcom-refgen-regulator.c, it contains some register settings and there is
>>> no LDOs voting. I'm not sure what does those register do, maybe Konrad
>>> can provide some backgroud.
>>
>> Those regs provide voting for refgen, because on those platforms DSI
>> block doesn't have a hardware vote for refgen.
>
> Hi Konrad, Dmitry
>
> I tried to model the reference voltage as a fixed regulator but the fixed
> regulator driver only supports a single vin-supply. However, the refgen
> block requires two separate power supplies (1.2V and 0.9V LDOs).
>
> Would it be appropriate to modify the qcom-refgen-regulator.c driver to
> handle LDO voting for both the 1.2V and 0.9V supplies? In the regulator's
> enable/disable callbacks, we could vote for and unvote these two LDOs
> instead of performing register operations.
Wait, so you want to associate the MMIO-controlled refgen's driver with
a dummy regulator that takes 2 supplies? I didn't catch that part earlier,
that's not great..
Or do we actually have access to the MMIO of *this* refgen and can control
it (except we don't do that today because X Y Z)?
Konrad
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2] phy: qcom: qmp-combo: Move pipe_clk on/off to common
From: Konrad Dybcio @ 2026-03-03 11:31 UTC (permalink / raw)
To: Val Packett, Vinod Koul, Kishon Vijay Abraham I, Bjorn Andersson,
Wesley Cheng, Neil Armstrong
Cc: Dmitry Baryshkov, linux-arm-msm, linux-phy, linux-kernel
In-Reply-To: <20260228220634.22778-2-val@packett.cool>
On 2/28/26 11:05 PM, Val Packett wrote:
> Keep the USB pipe clock working when the phy is in DP-only mode, because
> the dwc controller still needs it for USB 2.0 over the same Type-C port.
>
> Tested with the BenQ RD280UA monitor which has a downstream-facing port
> for data passthrough that's manually switchable between USB 2 and 3,
> corresponding to 4-lane and 2-lane DP respectively.
>
> Note: the suspend/resume callbacks were already gating the enable/disable
> of this clock only on init_count and not usb_init_count!
>
> Signed-off-by: Val Packett <val@packett.cool>
> ---
> See https://lore.kernel.org/all/389ca5d3-a698-4dac-911c-39ba057e3d17@oss.qualcomm.com/ for more info.
> BTW https://lore.kernel.org/all/20260205160240.748371-2-loic.poulain@oss.qualcomm.com/ helped with coldplug.
I think that's a fluke, you shouldn't see any real-world impact from
that patch
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 v9 1/2] dt-bindings: phy: eswin: Document the EIC7700 SoC SATA PHY
From: Bo Gan @ 2026-03-03 11:46 UTC (permalink / raw)
To: Yulin Lu, vkoul, neil.armstrong, robh, krzk+dt, conor+dt, p.zabel,
linux-phy, devicetree, linux-kernel
Cc: ningyu, linmin, fenglin
In-Reply-To: <20260205082129.1482-1-luyulin@eswincomputing.com>
Hi Yulin,
Can your team share the dt and driver for &hspcrg? I want to do some
testing with your latest v15 clock patchset on my P550 w/ SATA. W/o
&hspcrg, the SATA phy can't be enabled, hence SATA drive doesn't work.
Bo
On 2/5/26 00:21, Yulin Lu wrote:
> 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 | 92 +++++++++++++++++++
> 1 file changed, 92 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..fc7dbac77acf
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/eswin,eic7700-sata-phy.yaml
> @@ -0,0 +1,92 @@
> +# 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
> + - description: Gen2 parameter.
> + minimum: 0
> + maximum: 0x7f
> + - description: Gen3 parameter.
> + minimum: 0
> + maximum: 0x7f
> + default: [0, 0, 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
> + - description: Gen2 parameter.
> + minimum: 0
> + maximum: 0x3f
> + - description: Gen3 parameter.
> + minimum: 0
> + maximum: 0x3f
> + default: [0, 0, 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>;
> + };
--
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] dt-bindings: phy: qcom: Add CSI2 C-PHY/DPHY schema
From: Konrad Dybcio @ 2026-03-03 12:34 UTC (permalink / raw)
To: Bryan O'Donoghue, Bryan O'Donoghue, 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: <676e2a9f-d274-40fa-988f-e9388ba40f71@nxsw.ie>
On 3/3/26 10:30 AM, Bryan O'Donoghue wrote:
> On 03/03/2026 09:27, Bryan O'Donoghue wrote:
>> - MXA - first time I've heard of this rail, from memory I don't remember
>> having seen this in ipcat when I could do so.
>
> Yeah no MXA isn't a required vote.
That depends on the use case.
MXA is always-on (that's the 'A' in the name, as opposed to 'C'
for 'Collapsible'), but it's not always at the required performance
state (svs, nom, etc.). For some clock controllers specifically, there
is no need to put them into the picture, as the rail may be unconnected
altogether, or only used for some retention mechanisms (which only
require the rail to be enabled and nothing more)
Konrad
>
> https://lore.kernel.org/linux-arm-msm/9ff1645f-b2c9-4c1a-ae2d-96af416b08d9@oss.qualcomm.com/
>
> ---
> bod
>
>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v3 5/6] drm/mediatek: dsi: Add compatible for mt8167-dsi
From: AngeloGioacchino Del Regno @ 2026-03-03 14:24 UTC (permalink / raw)
To: CK Hu (胡俊光), l.scorcia@gmail.com,
krzk+dt@kernel.org
Cc: robh@kernel.org, Chunfeng Yun (云春峰),
simona@ffwll.ch, tzimmermann@suse.de, mripard@kernel.org,
linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org,
dri-devel@lists.freedesktop.org, chunkuang.hu@kernel.org,
vkoul@kernel.org, devicetree@vger.kernel.org,
linux-phy@lists.infradead.org, p.zabel@pengutronix.de,
conor+dt@kernel.org, airlied@gmail.com,
linux-arm-kernel@lists.infradead.org,
maarten.lankhorst@linux.intel.com, matthias.bgg@gmail.com,
neil.armstrong@linaro.org
In-Reply-To: <dcb797934bdb4467037559ee5e91bee0a568c03a.camel@mediatek.com>
Il 03/03/26 08:56, CK Hu (胡俊光) ha scritto:
> On Wed, 2026-02-25 at 09:15 +0100, Luca Leonardo Scorcia wrote:
>> External email : Please do not click links or open attachments until you have verified the sender or the content.
>>
>>
>>>> The mt8167 DSI controller is fully compatible with the one found in
>>>> mt2701. Device tree documentation is already present upstream.
>>>
>>> If mt8167 DSI is fully compatible with mt2701 DSI, I think the binding document and device tree should be modified.
>>> In device tree,
>>>
>>> compatible = "mediatek,mt8167-dsi", "mediatek,mt2701-dsi";
>>>
>>> And this patch is not necessary.
>>
>> Hi, if I understand your review correctly that's what v2 [1] of this
>> patch did, but the change was rejected during review.
>>
>> As far as I can see there is no win-win solution here. This tricky
>> situation derives from the fact that in last year's submissions the
>> change was only partially merged - the bindings went upstream while
>> the driver did not, and now we have to work around this. In v3 I tried
>> to address the issue by actually implementing what the binding
>> document says.
>> I'll be happy to resubmit v4 but I need to know what's the consensus here.
>
> You mean Krzysztof's comment?
> He has two comment.
> The first is 'remove'. You actually not remove "mediatek,mt8167-dsi". You change it.
> The second is about fallback. I'm also not sure why he says it's NAK. Also a bad wording?
> After Angelo's comment, Krzysztof does not response.
> I also do not know what Krzysztof think.
> I agree with Angelo. Single "mediatek,mt8167-dsi" does not reflect the hardware compatible but fallback does.
> Maybe describe more information (hardware) to Krzysztof, and ask what's the better way to do.
>
First of all: I would be happy with having
compatible = "mediatek,mt8167-dsi", "mediatek,mt2701-dsi";
in the devicetree, and to drop this patch - but that's not possible, check below.
The problem that Krzysztof was raising is that the bindings currently define
the "mediatek,mt8167-dsi" as single compatible with no fallback, and removing
it would break the ABI (as the bindings are not used only for Linux, but also
for bootloaders).
Even though I can try my best to convince him, this is a real problem: mistakes
were made in the past, and the only way to get the mt8167-dsi supported right
now is to, unfortunately, add the compatible in mtk_dsi.c.
I don't like that, and I see that you (CK) don't as well, but that's the result
of past mistakes... and apparently we can't do anything about this if not to
*uselessly clutter the driver* with that.
So, that said...
I'm sad to say that this patch is the only way to get this SoC probed by mtk_dsi
and that there's no other way around it, because the bindings maintainers are
forbidding us from removing the bad compatible (which was *never* used anyway)
from there and making it right with allowing it only under 2701 fallback.
I'm moving krzk to the To: field of this email in hope to get back a reply that
sounds like "you misunderstood me, you can do it", but I'm not positive about this.
Krzysztof, please confirm or deny what I said.
Regards,
Angelo
> Regards,
> CK
>
>>
>> Thanks!
>>
>> [1] https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-mediatek/patch/ff920a7cc94f2b0c03d4bb55142030fded30d07c.1771258407.git.l.scorcia@gmail.com/__;!!CTRNKA9wMg0ARbw!lIBnCRkybM1oxoARb70JlLMPlXHKqW9dwSmVqXGsvj3LE9hsWuINkPgtrlr8Jl8-atOvzYoMjtavHOr3$
>>
>>>>
>>>> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
>>>> ---
>>>> drivers/gpu/drm/mediatek/mtk_dsi.c | 1 +
>>>> 1 file changed, 1 insertion(+)
>>>>
>>>> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
>>>> index af4871de9e4c..ad10e86b161d 100644
>>>> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
>>>> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
>>>> @@ -1301,6 +1301,7 @@ static const struct mtk_dsi_driver_data mt8188_dsi_driver_data = {
>>>>
>>>> static const struct of_device_id mtk_dsi_of_match[] = {
>>>> { .compatible = "mediatek,mt2701-dsi", .data = &mt2701_dsi_driver_data },
>>>> + { .compatible = "mediatek,mt8167-dsi", .data = &mt2701_dsi_driver_data },
>>>> { .compatible = "mediatek,mt8173-dsi", .data = &mt8173_dsi_driver_data },
>>>> { .compatible = "mediatek,mt8183-dsi", .data = &mt8183_dsi_driver_data },
>>>> { .compatible = "mediatek,mt8186-dsi", .data = &mt8186_dsi_driver_data },
>>>> --
>>>> 2.43.0
>>>>
>>>>
>> --
>> Luca Leonardo Scorcia
>> l.scorcia@gmail.com
>
--
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] dt-bindings: phy: qcom: Add CSI2 C-PHY/DPHY schema
From: Bryan O'Donoghue @ 2026-03-03 14:56 UTC (permalink / raw)
To: Konrad Dybcio, Bryan O'Donoghue, Bryan O'Donoghue,
Vijay Kumar Tumati, 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: <04f22394-2dbb-4b7b-bce3-9b41ebfb7709@oss.qualcomm.com>
On 03/03/2026 12:34, Konrad Dybcio wrote:
> That depends on the use case.
>
> MXA is always-on (that's the 'A' in the name, as opposed to 'C'
> for 'Collapsible'), but it's not always at the required performance
> state (svs, nom, etc.). For some clock controllers specifically, there
> is no need to put them into the picture, as the rail may be unconnected
> altogether, or only used for some retention mechanisms (which only
> require the rail to be enabled and nothing more)
Does this rail have an OPP table you can share ?
---
bod
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH net-next v2 0/7] net: stmmac: qcom-ethqos: further serdes reorganisation
From: Russell King (Oracle) @ 2026-03-03 15:53 UTC (permalink / raw)
To: Andrew Lunn
Cc: Alexandre Torgue, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, linux-arm-kernel, linux-arm-msm, linux-phy,
linux-stm32, Mohd Ayaan Anwar, Neil Armstrong, netdev,
Paolo Abeni, Vinod Koul
This is part 2 of the qcom-ethqos series, part 1 and patch 2 of part 2
has now been merged.
This part of the series focuses on the generic PHY driver, but these
changes have dependencies on the ethernet driver, hence why
it will need to go via net-next. Furthermore, subsequent changes
depend on these patches.
The underlying ideas here are:
- get rid of the driver using phy_set_speed() with SPEED_1000 and
SPEED_2500 which makes no sense for an ethernet SerDes due to the
PCS 8B10B data encoding, which inflates the data rate at the SerDes
compared to the MAC. This is replaced with phy_set_mode_ext().
- allow phy_power_on() / phy_set_mode*() to be called in any order.
Mohd has tested this series, although not in the resulting merge order.
Changes since resend2:
- Drop patch 2 as that is now applied
- Add Vinod's Acks, which were eventually sent in response to the first
posting of this series.
.../ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c | 31 +++------
drivers/phy/qualcomm/phy-qcom-sgmii-eth.c | 73 ++++++++++------------
2 files changed, 41 insertions(+), 63 deletions(-)
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH net-next v2 1/7] net: stmmac: qcom-ethqos: move ethqos_set_serdes_speed()
From: Russell King (Oracle) @ 2026-03-03 15:53 UTC (permalink / raw)
To: Andrew Lunn
Cc: Alexandre Torgue, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, linux-arm-kernel, linux-arm-msm, linux-phy,
linux-stm32, Mohd Ayaan Anwar, Neil Armstrong, netdev,
Paolo Abeni, Vinod Koul
In-Reply-To: <aacD3osfaZkLsGxm@shell.armlinux.org.uk>
Combine ethqos_set_serdes_speed() with ethqos_mac_finish_serdes() to
simplify the code.
Reviewed-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
Tested-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
---
.../stmicro/stmmac/dwmac-qcom-ethqos.c | 22 +++++++++----------
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
index ad5b5d950fff..57cbe800f652 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
@@ -591,14 +591,6 @@ static void ethqos_configure_rgmii(struct qcom_ethqos *ethqos,
ethqos_rgmii_macro_init(ethqos, speed);
}
-static void ethqos_set_serdes_speed(struct qcom_ethqos *ethqos, int speed)
-{
- if (ethqos->serdes_speed != speed) {
- phy_set_speed(ethqos->serdes_phy, speed);
- ethqos->serdes_speed = speed;
- }
-}
-
static void ethqos_pcs_set_inband(struct stmmac_priv *priv, bool enable)
{
stmmac_pcs_ctrl_ane(priv, enable, 0);
@@ -683,15 +675,23 @@ static int ethqos_mac_finish_serdes(struct net_device *ndev, void *priv,
phy_interface_t interface)
{
struct qcom_ethqos *ethqos = priv;
+ int speed, ret = 0;
qcom_ethqos_set_sgmii_loopback(ethqos, false);
+ speed = SPEED_UNKNOWN;
if (interface == PHY_INTERFACE_MODE_SGMII)
- ethqos_set_serdes_speed(ethqos, SPEED_1000);
+ speed = SPEED_1000;
else if (interface == PHY_INTERFACE_MODE_2500BASEX)
- ethqos_set_serdes_speed(ethqos, SPEED_2500);
+ speed = SPEED_2500;
- return 0;
+ if (speed != SPEED_UNKNOWN && speed != ethqos->serdes_speed) {
+ ret = phy_set_speed(ethqos->serdes_phy, speed);
+ if (ret == 0)
+ ethqos->serdes_speed = speed;
+ }
+
+ return ret;
}
static int ethqos_clks_config(void *priv, bool enabled)
--
2.47.3
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH net-next v2 2/7] net: stmmac: qcom-ethqos: convert to use phy_set_mode_ext()
From: Russell King (Oracle) @ 2026-03-03 15:53 UTC (permalink / raw)
To: Andrew Lunn
Cc: Alexandre Torgue, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, linux-arm-kernel, linux-arm-msm, linux-phy,
linux-stm32, Mohd Ayaan Anwar, Neil Armstrong, netdev,
Paolo Abeni, Vinod Koul
In-Reply-To: <aacD3osfaZkLsGxm@shell.armlinux.org.uk>
qcom-sgmii-eth now accepts the phy_set_mode*() calls to configure the
SerDes, taking a PHY interface mode rather than a speed. This allows
the elimination of the interface mode to speed conversion in
ethqos_mac_finish_serdes().
Tested-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
---
.../stmicro/stmmac/dwmac-qcom-ethqos.c | 23 ++++++++-----------
1 file changed, 10 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
index 57cbe800f652..8913f6f02b9e 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
@@ -105,7 +105,7 @@ struct qcom_ethqos {
struct clk *link_clk;
struct phy *serdes_phy;
- int serdes_speed;
+ phy_interface_t serdes_mode;
phy_interface_t phy_mode;
const struct ethqos_emac_por *rgmii_por;
@@ -653,7 +653,8 @@ static int qcom_ethqos_serdes_powerup(struct net_device *ndev, void *priv)
return ret;
}
- ret = phy_set_speed(ethqos->serdes_phy, ethqos->serdes_speed);
+ ret = phy_set_mode_ext(ethqos->serdes_phy, PHY_MODE_ETHERNET,
+ ethqos->serdes_mode);
if (ret) {
phy_power_off(ethqos->serdes_phy);
phy_exit(ethqos->serdes_phy);
@@ -675,20 +676,16 @@ static int ethqos_mac_finish_serdes(struct net_device *ndev, void *priv,
phy_interface_t interface)
{
struct qcom_ethqos *ethqos = priv;
- int speed, ret = 0;
+ int ret = 0;
qcom_ethqos_set_sgmii_loopback(ethqos, false);
- speed = SPEED_UNKNOWN;
- if (interface == PHY_INTERFACE_MODE_SGMII)
- speed = SPEED_1000;
- else if (interface == PHY_INTERFACE_MODE_2500BASEX)
- speed = SPEED_2500;
-
- if (speed != SPEED_UNKNOWN && speed != ethqos->serdes_speed) {
- ret = phy_set_speed(ethqos->serdes_phy, speed);
+ if (interface == PHY_INTERFACE_MODE_SGMII ||
+ interface == PHY_INTERFACE_MODE_2500BASEX) {
+ ret = phy_set_mode_ext(ethqos->serdes_phy, PHY_MODE_ETHERNET,
+ interface);
if (ret == 0)
- ethqos->serdes_speed = speed;
+ ethqos->serdes_mode = interface;
}
return ret;
@@ -819,7 +816,6 @@ static int qcom_ethqos_probe(struct platform_device *pdev)
return dev_err_probe(dev, PTR_ERR(ethqos->serdes_phy),
"Failed to get serdes phy\n");
- ethqos->serdes_speed = SPEED_1000;
ethqos_set_clk_tx_rate(ethqos, NULL, plat_dat->phy_interface,
SPEED_1000);
@@ -843,6 +839,7 @@ static int qcom_ethqos_probe(struct platform_device *pdev)
plat_dat->host_dma_width = data->dma_addr_width;
if (ethqos->serdes_phy) {
+ ethqos->serdes_mode = PHY_INTERFACE_MODE_SGMII;
plat_dat->serdes_powerup = qcom_ethqos_serdes_powerup;
plat_dat->serdes_powerdown = qcom_ethqos_serdes_powerdown;
}
--
2.47.3
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH net-next v2 3/7] phy: qcom-sgmii-eth: remove .set_speed() implementation
From: Russell King (Oracle) @ 2026-03-03 15:53 UTC (permalink / raw)
To: Andrew Lunn
Cc: Alexandre Torgue, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, linux-arm-kernel, linux-arm-msm, linux-phy,
linux-stm32, Mohd Ayaan Anwar, Neil Armstrong, netdev,
Paolo Abeni, Vinod Koul
In-Reply-To: <aacD3osfaZkLsGxm@shell.armlinux.org.uk>
Now that the qcom-ethqos driver has migrated to use phy_set_mode_ext()
rather than phy_set_speed() to configure the SerDes, the support for
phy_set_speed() is now obsolete. Remove support for this method.
Using the MAC speed for the SerDes is never correct due to the PCS
encoding. For SGMII and 2500BASE-X, the PCS uses 8B10B encoding, and
so:
MAC rate * PCS output bits / PCS input bits = SerDes rate
1000M * 10 / 8 = 1250M
2500M * 10 / 8 = 3125M
Tested-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
Acked-by: Vinod Koul <vkoul@kernel.org>
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
---
drivers/phy/qualcomm/phy-qcom-sgmii-eth.c | 11 -----------
1 file changed, 11 deletions(-)
diff --git a/drivers/phy/qualcomm/phy-qcom-sgmii-eth.c b/drivers/phy/qualcomm/phy-qcom-sgmii-eth.c
index 4ea3dce7719f..dcfdb7d0e8ea 100644
--- a/drivers/phy/qualcomm/phy-qcom-sgmii-eth.c
+++ b/drivers/phy/qualcomm/phy-qcom-sgmii-eth.c
@@ -318,16 +318,6 @@ static int qcom_dwmac_sgmii_phy_set_mode(struct phy *phy, enum phy_mode mode,
return qcom_dwmac_sgmii_phy_calibrate(phy);
}
-static int qcom_dwmac_sgmii_phy_set_speed(struct phy *phy, int speed)
-{
- struct qcom_dwmac_sgmii_phy_data *data = phy_get_drvdata(phy);
-
- if (speed != data->speed)
- data->speed = speed;
-
- return qcom_dwmac_sgmii_phy_calibrate(phy);
-}
-
static int qcom_dwmac_sgmii_phy_validate(struct phy *phy, enum phy_mode mode,
int submode,
union phy_configure_opts *opts)
@@ -341,7 +331,6 @@ static const struct phy_ops qcom_dwmac_sgmii_phy_ops = {
.power_on = qcom_dwmac_sgmii_phy_power_on,
.power_off = qcom_dwmac_sgmii_phy_power_off,
.set_mode = qcom_dwmac_sgmii_phy_set_mode,
- .set_speed = qcom_dwmac_sgmii_phy_set_speed,
.validate = qcom_dwmac_sgmii_phy_validate,
.calibrate = qcom_dwmac_sgmii_phy_calibrate,
.owner = THIS_MODULE,
--
2.47.3
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH net-next v2 4/7] phy: qcom-sgmii-eth: use PHY interface mode for SerDes settings
From: Russell King (Oracle) @ 2026-03-03 15:53 UTC (permalink / raw)
To: Andrew Lunn
Cc: Alexandre Torgue, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, linux-arm-kernel, linux-arm-msm, linux-phy,
linux-stm32, Mohd Ayaan Anwar, Neil Armstrong, netdev,
Paolo Abeni, Vinod Koul
In-Reply-To: <aacD3osfaZkLsGxm@shell.armlinux.org.uk>
As established in the previous commit, using SPEED_1000 and SPEED_2500
does not make sense for a SerDes due to the PCS encoding that is used
over the SerDes link, which inflates the data rate at the SerDes. Thus,
the use of these constants in a SerDes driver is incorrect.
Since qcom-sgmii-eth no longer implements phy_set_speed(), but instead
uses the PHY interface mode passed via the .set_mode() method, convert
the driver to use the PHY interface mode internally to decide whether
to configure the SerDes for 1.25Gbps or 3.125Gbps mode.
Tested-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
Acked-by: Vinod Koul <vkoul@kernel.org>
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
---
drivers/phy/qualcomm/phy-qcom-sgmii-eth.c | 41 ++++++++++++-----------
1 file changed, 21 insertions(+), 20 deletions(-)
diff --git a/drivers/phy/qualcomm/phy-qcom-sgmii-eth.c b/drivers/phy/qualcomm/phy-qcom-sgmii-eth.c
index dcfdb7d0e8ea..58ff15601206 100644
--- a/drivers/phy/qualcomm/phy-qcom-sgmii-eth.c
+++ b/drivers/phy/qualcomm/phy-qcom-sgmii-eth.c
@@ -29,7 +29,7 @@
struct qcom_dwmac_sgmii_phy_data {
struct regmap *regmap;
struct clk *refclk;
- int speed;
+ phy_interface_t interface;
};
static void qcom_dwmac_sgmii_phy_init_1g(struct regmap *regmap)
@@ -223,15 +223,18 @@ static int qcom_dwmac_sgmii_phy_calibrate(struct phy *phy)
struct qcom_dwmac_sgmii_phy_data *data = phy_get_drvdata(phy);
struct device *dev = phy->dev.parent;
- switch (data->speed) {
- case SPEED_10:
- case SPEED_100:
- case SPEED_1000:
+ switch (data->interface) {
+ case PHY_INTERFACE_MODE_SGMII:
+ case PHY_INTERFACE_MODE_1000BASEX:
+ /* 1.25Gbps mode */
qcom_dwmac_sgmii_phy_init_1g(data->regmap);
break;
- case SPEED_2500:
+ case PHY_INTERFACE_MODE_2500BASEX:
+ /* 3.125Gbps mode */
qcom_dwmac_sgmii_phy_init_2p5g(data->regmap);
break;
+ default:
+ return -EINVAL;
}
if (qcom_dwmac_sgmii_phy_poll_status(data->regmap,
@@ -287,17 +290,15 @@ static int qcom_dwmac_sgmii_phy_power_off(struct phy *phy)
return 0;
}
-static int qcom_dwmac_sgmii_phy_speed(enum phy_mode mode, int submode)
+static int qcom_dwmac_sgmii_phy_interface(enum phy_mode mode, int submode)
{
if (mode != PHY_MODE_ETHERNET)
return -EINVAL;
if (submode == PHY_INTERFACE_MODE_SGMII ||
- submode == PHY_INTERFACE_MODE_1000BASEX)
- return SPEED_1000;
-
- if (submode == PHY_INTERFACE_MODE_2500BASEX)
- return SPEED_2500;
+ submode == PHY_INTERFACE_MODE_1000BASEX ||
+ submode == PHY_INTERFACE_MODE_2500BASEX)
+ return submode;
return -EINVAL;
}
@@ -306,14 +307,14 @@ static int qcom_dwmac_sgmii_phy_set_mode(struct phy *phy, enum phy_mode mode,
int submode)
{
struct qcom_dwmac_sgmii_phy_data *data = phy_get_drvdata(phy);
- int speed;
+ int interface;
- speed = qcom_dwmac_sgmii_phy_speed(mode, submode);
- if (speed < 0)
- return speed;
+ interface = qcom_dwmac_sgmii_phy_interface(mode, submode);
+ if (interface < 0)
+ return interface;
- if (speed != data->speed)
- data->speed = speed;
+ if (interface != data->interface)
+ data->interface = interface;
return qcom_dwmac_sgmii_phy_calibrate(phy);
}
@@ -322,7 +323,7 @@ static int qcom_dwmac_sgmii_phy_validate(struct phy *phy, enum phy_mode mode,
int submode,
union phy_configure_opts *opts)
{
- int ret = qcom_dwmac_sgmii_phy_speed(mode, submode);
+ int ret = qcom_dwmac_sgmii_phy_interface(mode, submode);
return ret < 0 ? ret : 0;
}
@@ -356,7 +357,7 @@ static int qcom_dwmac_sgmii_phy_probe(struct platform_device *pdev)
if (!data)
return -ENOMEM;
- data->speed = SPEED_10;
+ data->interface = PHY_INTERFACE_MODE_SGMII;
base = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(base))
--
2.47.3
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH net-next v2 6/7] phy: qcom-sgmii-eth: relax order of .power_on() vs .set_mode*()
From: Russell King (Oracle) @ 2026-03-03 15:54 UTC (permalink / raw)
To: Andrew Lunn
Cc: Alexandre Torgue, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, linux-arm-kernel, linux-arm-msm, linux-phy,
linux-stm32, Mohd Ayaan Anwar, Neil Armstrong, netdev,
Paolo Abeni, Vinod Koul
In-Reply-To: <aacD3osfaZkLsGxm@shell.armlinux.org.uk>
Allow any order of the .power_on() and .set_mode*() methods as per the
recent discussion. This means phy_power_on() with this SerDes will now
restore the previous setup without requiring a subsequent
phy_set_mode*() call.
Tested-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
Acked-by: Vinod Koul <vkoul@kernel.org>
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
---
drivers/phy/qualcomm/phy-qcom-sgmii-eth.c | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/phy/qualcomm/phy-qcom-sgmii-eth.c b/drivers/phy/qualcomm/phy-qcom-sgmii-eth.c
index 6332ff291fdf..f48faa2929a6 100644
--- a/drivers/phy/qualcomm/phy-qcom-sgmii-eth.c
+++ b/drivers/phy/qualcomm/phy-qcom-sgmii-eth.c
@@ -271,8 +271,17 @@ static int qcom_dwmac_sgmii_phy_calibrate(struct phy *phy)
static int qcom_dwmac_sgmii_phy_power_on(struct phy *phy)
{
struct qcom_dwmac_sgmii_phy_data *data = phy_get_drvdata(phy);
+ int ret;
+
+ ret = clk_prepare_enable(data->refclk);
+ if (ret < 0)
+ return ret;
- return clk_prepare_enable(data->refclk);
+ ret = qcom_dwmac_sgmii_phy_calibrate(phy);
+ if (ret < 0)
+ clk_disable_unprepare(data->refclk);
+
+ return ret;
}
static int qcom_dwmac_sgmii_phy_power_off(struct phy *phy)
@@ -318,6 +327,9 @@ static int qcom_dwmac_sgmii_phy_set_mode(struct phy *phy, enum phy_mode mode,
if (submode != data->interface)
data->interface = submode;
+ if (phy->power_count == 0)
+ return 0;
+
return qcom_dwmac_sgmii_phy_calibrate(phy);
}
--
2.47.3
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH net-next v2 5/7] phy: qcom-sgmii-eth: remove qcom_dwmac_sgmii_phy_interface()
From: Russell King (Oracle) @ 2026-03-03 15:53 UTC (permalink / raw)
To: Andrew Lunn
Cc: Alexandre Torgue, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, linux-arm-kernel, linux-arm-msm, linux-phy,
linux-stm32, Mohd Ayaan Anwar, Neil Armstrong, netdev,
Paolo Abeni, Vinod Koul
In-Reply-To: <aacD3osfaZkLsGxm@shell.armlinux.org.uk>
Now that qcom_dwmac_sgmii_phy_interface() only serves to validate the
passed interface mode, combine it with qcom_dwmac_sgmii_phy_validate(),
and use qcom_dwmac_sgmii_phy_validate() to validate the mode in
qcom_dwmac_sgmii_phy_set_mode().
Tested-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
Acked-by: Vinod Koul <vkoul@kernel.org>
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
---
drivers/phy/qualcomm/phy-qcom-sgmii-eth.c | 27 +++++++++--------------
1 file changed, 10 insertions(+), 17 deletions(-)
diff --git a/drivers/phy/qualcomm/phy-qcom-sgmii-eth.c b/drivers/phy/qualcomm/phy-qcom-sgmii-eth.c
index 58ff15601206..6332ff291fdf 100644
--- a/drivers/phy/qualcomm/phy-qcom-sgmii-eth.c
+++ b/drivers/phy/qualcomm/phy-qcom-sgmii-eth.c
@@ -290,7 +290,9 @@ static int qcom_dwmac_sgmii_phy_power_off(struct phy *phy)
return 0;
}
-static int qcom_dwmac_sgmii_phy_interface(enum phy_mode mode, int submode)
+static int qcom_dwmac_sgmii_phy_validate(struct phy *phy, enum phy_mode mode,
+ int submode,
+ union phy_configure_opts *opts)
{
if (mode != PHY_MODE_ETHERNET)
return -EINVAL;
@@ -298,7 +300,7 @@ static int qcom_dwmac_sgmii_phy_interface(enum phy_mode mode, int submode)
if (submode == PHY_INTERFACE_MODE_SGMII ||
submode == PHY_INTERFACE_MODE_1000BASEX ||
submode == PHY_INTERFACE_MODE_2500BASEX)
- return submode;
+ return 0;
return -EINVAL;
}
@@ -307,27 +309,18 @@ static int qcom_dwmac_sgmii_phy_set_mode(struct phy *phy, enum phy_mode mode,
int submode)
{
struct qcom_dwmac_sgmii_phy_data *data = phy_get_drvdata(phy);
- int interface;
+ int ret;
- interface = qcom_dwmac_sgmii_phy_interface(mode, submode);
- if (interface < 0)
- return interface;
+ ret = qcom_dwmac_sgmii_phy_validate(phy, mode, submode, NULL);
+ if (ret)
+ return ret;
- if (interface != data->interface)
- data->interface = interface;
+ if (submode != data->interface)
+ data->interface = submode;
return qcom_dwmac_sgmii_phy_calibrate(phy);
}
-static int qcom_dwmac_sgmii_phy_validate(struct phy *phy, enum phy_mode mode,
- int submode,
- union phy_configure_opts *opts)
-{
- int ret = qcom_dwmac_sgmii_phy_interface(mode, submode);
-
- return ret < 0 ? ret : 0;
-}
-
static const struct phy_ops qcom_dwmac_sgmii_phy_ops = {
.power_on = qcom_dwmac_sgmii_phy_power_on,
.power_off = qcom_dwmac_sgmii_phy_power_off,
--
2.47.3
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH net-next v2 7/7] net: stmmac: qcom-ethqos: remove phy_set_mode_ext() after phy_power_on()
From: Russell King (Oracle) @ 2026-03-03 15:54 UTC (permalink / raw)
To: Andrew Lunn
Cc: Alexandre Torgue, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, linux-arm-kernel, linux-arm-msm, linux-phy,
linux-stm32, Mohd Ayaan Anwar, Neil Armstrong, netdev,
Paolo Abeni, Vinod Koul
In-Reply-To: <aacD3osfaZkLsGxm@shell.armlinux.org.uk>
The call to phy_set_mode_ext() after phy_power_on() was a work-around
for the qcom-sgmii-eth SerDes driver that only re-enabled its clocks on
phy_power_on() but did not configure the PHY. Now that the SerDes driver
fully configures the SerDes at phy_power_on(), there is no need to call
phy_set_mode_ext() immediately afterwards.
This also means we no longer need to record the previous operating mode
of the driver - this is up to the SerDes driver. In any case, the only
thing that we care about is the SerDes provides the necessary clocks to
the stmmac core to allow it to reset at this point. The actual mode is
irrelevant at this point as the correct mode will be configured in
ethqos_mac_finish_serdes() just before the network device is brought
online.
Reviewed-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
Tested-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
---
.../stmicro/stmmac/dwmac-qcom-ethqos.c | 18 ++----------------
1 file changed, 2 insertions(+), 16 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
index 8913f6f02b9e..cb1c074c2053 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
@@ -105,7 +105,6 @@ struct qcom_ethqos {
struct clk *link_clk;
struct phy *serdes_phy;
- phy_interface_t serdes_mode;
phy_interface_t phy_mode;
const struct ethqos_emac_por *rgmii_por;
@@ -648,17 +647,8 @@ static int qcom_ethqos_serdes_powerup(struct net_device *ndev, void *priv)
return ret;
ret = phy_power_on(ethqos->serdes_phy);
- if (ret) {
- phy_exit(ethqos->serdes_phy);
- return ret;
- }
-
- ret = phy_set_mode_ext(ethqos->serdes_phy, PHY_MODE_ETHERNET,
- ethqos->serdes_mode);
- if (ret) {
- phy_power_off(ethqos->serdes_phy);
+ if (ret)
phy_exit(ethqos->serdes_phy);
- }
return ret;
}
@@ -681,12 +671,9 @@ static int ethqos_mac_finish_serdes(struct net_device *ndev, void *priv,
qcom_ethqos_set_sgmii_loopback(ethqos, false);
if (interface == PHY_INTERFACE_MODE_SGMII ||
- interface == PHY_INTERFACE_MODE_2500BASEX) {
+ interface == PHY_INTERFACE_MODE_2500BASEX)
ret = phy_set_mode_ext(ethqos->serdes_phy, PHY_MODE_ETHERNET,
interface);
- if (ret == 0)
- ethqos->serdes_mode = interface;
- }
return ret;
}
@@ -839,7 +826,6 @@ static int qcom_ethqos_probe(struct platform_device *pdev)
plat_dat->host_dma_width = data->dma_addr_width;
if (ethqos->serdes_phy) {
- ethqos->serdes_mode = PHY_INTERFACE_MODE_SGMII;
plat_dat->serdes_powerup = qcom_ethqos_serdes_powerup;
plat_dat->serdes_powerdown = qcom_ethqos_serdes_powerdown;
}
--
2.47.3
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* Re: [PATCH v3 1/2] dt-bindings: phy: qcom: Add CSI2 C-PHY/DPHY schema
From: Vijay Kumar Tumati @ 2026-03-03 18:03 UTC (permalink / raw)
To: Bryan O'Donoghue, 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: <676e2a9f-d274-40fa-988f-e9388ba40f71@nxsw.ie>
On 3/3/2026 1:30 AM, Bryan O'Donoghue wrote:
> On 03/03/2026 09:27, Bryan O'Donoghue wrote:
>> - MXA - first time I've heard of this rail, from memory I don't remember
>> having seen this in ipcat when I could do so.
>
> Yeah no MXA isn't a required vote.
>
> https://lore.kernel.org/linux-arm-msm/9ff1645f-b2c9-4c1a-ae2d-96af416b08d9@oss.qualcomm.com/
If I am not wrong, CAMCC only enables the power domains that source the
CAMCC block and it's register access. And for that, it only needs those
power domains to be just enabled without any performance vote. Based on
her comment, if MXA is always enabled (at min level), probably CAMCC
driver doesn't need to enable or scale it explicitly. However, the
camera devices that actually depend on this power domain for their core
functionality need to scale this per the core clock corner. I can double
check though.
>
> ---
> bod
>
Thanks,
Vijay.
--
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] dt-bindings: phy: qcom: Add CSI2 C-PHY/DPHY schema
From: Vijay Kumar Tumati @ 2026-03-03 18:08 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: <03b44922-72d5-465b-96e1-97a19655e97d@kernel.org>
On 3/3/2026 1:27 AM, Bryan O'Donoghue wrote:
> On 03/03/2026 01:51, Vijay Kumar Tumati wrote:
>> Hi Bryan,
>>
>> On 2/26/2026 4:34 AM, 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 | 114 +++++++++
>>> ++++++++++++
>>> 1 file changed, 114 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..c937d26ccbda9
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/phy/qcom,x1e80100-csi2-phy.yaml
>>> @@ -0,0 +1,114 @@
>>> +# 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:
>>> + maxItems: 1
>>> +
>>> + 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
>>> + - 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>
>>> +
>>> + 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";
>>> +
>>> + operating-points-v2 = <&csiphy_opp_table>;
>>> +
>>> + interrupts = <GIC_SPI 477 IRQ_TYPE_EDGE_RISING>;
>>> +
>>> + power-domains = <&camcc CAM_CC_TITAN_TOP_GDSC>;
>> As we are cleaning up the PHY device nodes, we should consider fixing
>> the power domains as well. Although TOP GDSC is defined as a power
>> domain, it is not the power source for the PHY devices. Rather, it is
>> the MMCX, MXC and optionally MXA based on the architecture (Refer to
>> 'Voltage rail' column for PHY clocks in IPCAT).
>
> Feel free to send me a qcom laptop and I will :)
:)
>
> From memory though I _thought_ only the TOP was required for the PHY.
> I'd be grateful if you could confirm yourself in ipcat.
>
> - TITAN_TOP_GDSC
> - MXC
> - MMCX
> - MXA - first time I've heard of this rail, from memory I don't remember
> having seen this in ipcat when I could do so.
MCX and MMCX are comminly required power domains across the PHYs but a
subset of PHYs have the dependency on MXA.
>
> There is no
>> parent-child relationship between the TOP GDSC and these in the clock
>> driver and it was just working as the required power rails are getting
>> enabled by/for other MM devices.
>
> Well only the GDSC is supplied by the clock controller.
Right, GDSC is controlled by the CAMCC to suspend the subsystems. But
the actual power supply and the voltage rails are under the control of
the RPMH. So the clients need to enable and vote for the required perf
corner as the core clocks scale up/down to be independent of the other
subsystems sharing those voltage rails.
>
>>> +
>>> + vdda-0p8-supply = <&vreg_l2c_0p8>;
>>> + vdda-1p2-supply = <&vreg_l1c_1p2>;
>>> + };
>>> +
>>> + csiphy_opp_table: opp-table-csiphy {
>>> + compatible = "operating-points-v2";
>>> +
>>> + opp-300000000 {
>>> + opp-hz = /bits/ 64 <300000000>;
>>> + required-opps = <&rpmhpd_opp_low_svs_d1>;
>>> + };
>>> +
>>> + opp-400000000 {
>>> + opp-hz = /bits/ 64 <400000000>;
>>> + required-opps = <&rpmhpd_opp_low_svs>;
>>> + };
>>> +
>>> + opp-480000000 {
>>> + opp-hz = /bits/ 64 <480000000>;
>>> + required-opps = <&rpmhpd_opp_low_svs>;
>>> + };
>>> + };
>>>
>> 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 v3 1/2] dt-bindings: phy: qcom: Add CSI2 C-PHY/DPHY schema
From: Vijay Kumar Tumati @ 2026-03-03 18:58 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: <4440a3a8-7281-4bea-bb84-7a9d19ef7ce9@oss.qualcomm.com>
On 3/3/2026 10:08 AM, Vijay Kumar Tumati wrote:
>
>
> On 3/3/2026 1:27 AM, Bryan O'Donoghue wrote:
>> On 03/03/2026 01:51, Vijay Kumar Tumati wrote:
>>> Hi Bryan,
>>>
>>> On 2/26/2026 4:34 AM, 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 | 114 ++++++++
>>>> + ++++++++++++
>>>> 1 file changed, 114 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..c937d26ccbda9
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/phy/qcom,x1e80100-csi2-phy.yaml
>>>> @@ -0,0 +1,114 @@
>>>> +# 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:
>>>> + maxItems: 1
>>>> +
>>>> + 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
>>>> + - 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>
>>>> +
>>>> + 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";
>>>> +
>>>> + operating-points-v2 = <&csiphy_opp_table>;
>>>> +
>>>> + interrupts = <GIC_SPI 477 IRQ_TYPE_EDGE_RISING>;
>>>> +
>>>> + power-domains = <&camcc CAM_CC_TITAN_TOP_GDSC>;
>>> As we are cleaning up the PHY device nodes, we should consider fixing
>>> the power domains as well. Although TOP GDSC is defined as a power
>>> domain, it is not the power source for the PHY devices. Rather, it is
>>> the MMCX, MXC and optionally MXA based on the architecture (Refer to
>>> 'Voltage rail' column for PHY clocks in IPCAT).
>>
>> Feel free to send me a qcom laptop and I will :)
> :)
>>
>> From memory though I _thought_ only the TOP was required for the PHY.
>> I'd be grateful if you could confirm yourself in ipcat.
>>
>> - TITAN_TOP_GDSC
>> - MXC
>> - MMCX
>> - MXA - first time I've heard of this rail, from memory I don't remember
>> having seen this in ipcat when I could do so.
> MCX and MMCX are comminly required power domains across the PHYs but a
> subset of PHYs have the dependency on MXA.
Actually, it's a bit more complicated on this target as
cam_cc_cphy_rx_clk_src also depends on MXA, which means all the CBCs
connected this RCG do as well.
>>
>> There is no
>>> parent-child relationship between the TOP GDSC and these in the clock
>>> driver and it was just working as the required power rails are getting
>>> enabled by/for other MM devices.
>>
>> Well only the GDSC is supplied by the clock controller.
> Right, GDSC is controlled by the CAMCC to suspend the subsystems. But
> the actual power supply and the voltage rails are under the control of
> the RPMH. So the clients need to enable and vote for the required perf
> corner as the core clocks scale up/down to be independent of the other
> subsystems sharing those voltage rails.
>>
>>>> +
>>>> + vdda-0p8-supply = <&vreg_l2c_0p8>;
>>>> + vdda-1p2-supply = <&vreg_l1c_1p2>;
>>>> + };
>>>> +
>>>> + csiphy_opp_table: opp-table-csiphy {
>>>> + compatible = "operating-points-v2";
>>>> +
>>>> + opp-300000000 {
>>>> + opp-hz = /bits/ 64 <300000000>;
>>>> + required-opps = <&rpmhpd_opp_low_svs_d1>;
>>>> + };
>>>> +
>>>> + opp-400000000 {
>>>> + opp-hz = /bits/ 64 <400000000>;
>>>> + required-opps = <&rpmhpd_opp_low_svs>;
>>>> + };
>>>> +
>>>> + opp-480000000 {
>>>> + opp-hz = /bits/ 64 <480000000>;
>>>> + required-opps = <&rpmhpd_opp_low_svs>;
>>>> + };
>>>> + };
>>>>
>>> Thanks,
>>> Vijay.
>>
> Thanks,
> Vijay.
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH 0/8] mips: econet: Add clk/reset and PCIe support
From: Caleb James DeLisle @ 2026-03-03 19:09 UTC (permalink / raw)
To: linux-mips
Cc: naseefkm, mturquette, sboyd, robh, krzk+dt, conor+dt, cjd,
tsbogend, ryder.lee, jianjun.wang, lpieralisi, kwilczynski, mani,
bhelgaas, vkoul, neil.armstrong, p.zabel, matthias.bgg,
angelogioacchino.delregno, nbd, ansuelsmth, linux-clk, devicetree,
linux-kernel, linux-pci, linux-mediatek, linux-phy,
linux-arm-kernel
Add clock/reset and PCIe support to EcoNet EN751221 and related SoCs.
This builds on the Airoha EN7523 clock driver and the Mediatek PCIe driver.
Patch 6 is upstreaming of Ahmed Naseef's work on EcoNet PCIe, which was
developed to support the EN7528, but which works equally on the EN751221.
There is also a workaround in patch 7 to gracefully handle PCI hardware
which does not advertize a bridge window and instead always reads zero.
Caleb James DeLisle (8):
dt-bindings: clock, reset: Add econet EN751221 bindings
clk: airoha: Add econet EN751221 clock/reset support to en7523-scu
dt-bindings: phy: Document PCIe PHY in EcoNet EN751221 and EN7528
phy: econet: Add PCIe PHY driver for EcoNet EN751221 and EN7528 SoCs.
dt-bindings: PCI: mediatek: Add support for EcoNet EN7528
PCI: mediatek: Add support for EcoNet EN7528 SoC
PCI: Skip bridge window reads when window is not supported
mips: dts: Add PCIe to EcoNet EN751221
.../bindings/clock/airoha,en7523-scu.yaml | 19 +-
.../mips/econet,en751221-chip-scu.yaml | 41 +++
.../bindings/pci/mediatek-pcie.yaml | 1 +
.../phy/econet,en751221-pcie-phy.yaml | 57 +++++
MAINTAINERS | 10 +
arch/mips/boot/dts/econet/en751221.dtsi | 114 +++++++++
.../econet/en751221_smartfiber_xp8421-b.dts | 21 ++
arch/mips/econet/Kconfig | 2 +
drivers/clk/Kconfig | 6 +-
drivers/clk/clk-en7523.c | 236 +++++++++++++++++-
drivers/pci/controller/Kconfig | 2 +-
drivers/pci/controller/pcie-mediatek.c | 107 ++++++++
drivers/pci/probe.c | 6 +
drivers/phy/Kconfig | 12 +
drivers/phy/Makefile | 1 +
drivers/phy/phy-econet-pcie.c | 180 +++++++++++++
.../dt-bindings/clock/econet,en751221-scu.h | 15 ++
.../dt-bindings/reset/econet,en751221-scu.h | 49 ++++
18 files changed, 869 insertions(+), 10 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mips/econet,en751221-chip-scu.yaml
create mode 100644 Documentation/devicetree/bindings/phy/econet,en751221-pcie-phy.yaml
create mode 100644 drivers/phy/phy-econet-pcie.c
create mode 100644 include/dt-bindings/clock/econet,en751221-scu.h
create mode 100644 include/dt-bindings/reset/econet,en751221-scu.h
base-commit: 3fa5e5702a82d259897bd7e209469bc06368bf31
--
2.39.5
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH 1/8] dt-bindings: clock, reset: Add econet EN751221 bindings
From: Caleb James DeLisle @ 2026-03-03 19:09 UTC (permalink / raw)
To: linux-mips
Cc: naseefkm, mturquette, sboyd, robh, krzk+dt, conor+dt, cjd,
tsbogend, ryder.lee, jianjun.wang, lpieralisi, kwilczynski, mani,
bhelgaas, vkoul, neil.armstrong, p.zabel, matthias.bgg,
angelogioacchino.delregno, nbd, ansuelsmth, linux-clk, devicetree,
linux-kernel, linux-pci, linux-mediatek, linux-phy,
linux-arm-kernel
In-Reply-To: <20260303190948.694783-1-cjd@cjdns.fr>
Add clock and reset bindings for EN751221 as well as
a "chip-scu" which is an additional regmap that is used
by the clock driver as well as others. This split of the
SCU across two register areas is the same as the Airoha
AN758x family.
Signed-off-by: Caleb James DeLisle <cjd@cjdns.fr>
---
.../bindings/clock/airoha,en7523-scu.yaml | 19 ++++++-
.../mips/econet,en751221-chip-scu.yaml | 41 ++++++++++++++++
MAINTAINERS | 3 ++
.../dt-bindings/clock/econet,en751221-scu.h | 15 ++++++
.../dt-bindings/reset/econet,en751221-scu.h | 49 +++++++++++++++++++
5 files changed, 126 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/mips/econet,en751221-chip-scu.yaml
create mode 100644 include/dt-bindings/clock/econet,en751221-scu.h
create mode 100644 include/dt-bindings/reset/econet,en751221-scu.h
diff --git a/Documentation/devicetree/bindings/clock/airoha,en7523-scu.yaml b/Documentation/devicetree/bindings/clock/airoha,en7523-scu.yaml
index a8471367175b..e60e54273393 100644
--- a/Documentation/devicetree/bindings/clock/airoha,en7523-scu.yaml
+++ b/Documentation/devicetree/bindings/clock/airoha,en7523-scu.yaml
@@ -32,6 +32,7 @@ properties:
- enum:
- airoha,en7523-scu
- airoha,en7581-scu
+ - econet,en751221-scu
reg:
items:
@@ -67,7 +68,10 @@ allOf:
- if:
properties:
compatible:
- const: airoha,en7581-scu
+ items:
+ - enum:
+ - airoha,en7581-scu
+ - econet,en751221-scu
then:
properties:
reg:
@@ -98,3 +102,16 @@ examples:
#reset-cells = <1>;
};
};
+
+ - |
+ soc {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ scuclk2: clock-controller@1fb00000 {
+ compatible = "econet,en751221-scu";
+ reg = <0x1fb00000 0x970>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/mips/econet,en751221-chip-scu.yaml b/Documentation/devicetree/bindings/mips/econet,en751221-chip-scu.yaml
new file mode 100644
index 000000000000..7c7c8cf8d2a5
--- /dev/null
+++ b/Documentation/devicetree/bindings/mips/econet,en751221-chip-scu.yaml
@@ -0,0 +1,41 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mips/econet,en751221-chip-scu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: EcoNet Chip SCU Controller for EN751221 SoC
+
+maintainers:
+ - Caleb James DeLisle <cjd@cjdns.fr>
+
+description:
+ The EcoNet chip-scu block provides a configuration interface for clock,
+ io-muxing and other functionalities used by multiple controllers (e.g. clock,
+ pinctrl, ecc) on EN751221 SoC.
+
+properties:
+ compatible:
+ items:
+ - const: econet,en751221-chip-scu
+ - const: syscon
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ soc {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ syscon@1fa20000 {
+ compatible = "econet,en751221-chip-scu", "syscon";
+ reg = <0x1fa20000 0x388>;
+ };
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index 14899f1de77e..56cf73ce91b8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9113,12 +9113,15 @@ M: Caleb James DeLisle <cjd@cjdns.fr>
L: linux-mips@vger.kernel.org
S: Maintained
F: Documentation/devicetree/bindings/interrupt-controller/econet,en751221-intc.yaml
+F: Documentation/devicetree/bindings/mips/econet,en751221-chip-scu.yaml
F: Documentation/devicetree/bindings/mips/econet.yaml
F: Documentation/devicetree/bindings/timer/econet,en751221-timer.yaml
F: arch/mips/boot/dts/econet/
F: arch/mips/econet/
F: drivers/clocksource/timer-econet-en751221.c
F: drivers/irqchip/irq-econet-en751221.c
+F: include/dt-bindings/clock/econet,en751221-scu.h
+F: include/dt-bindings/reset/econet,en751221-scu.h
ECRYPT FILE SYSTEM
M: Tyler Hicks <code@tyhicks.com>
diff --git a/include/dt-bindings/clock/econet,en751221-scu.h b/include/dt-bindings/clock/econet,en751221-scu.h
new file mode 100644
index 000000000000..34179b8fe2f9
--- /dev/null
+++ b/include/dt-bindings/clock/econet,en751221-scu.h
@@ -0,0 +1,15 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
+
+#ifndef _DT_BINDINGS_CLOCK_ECONET_EN751221_SCU_H_
+#define _DT_BINDINGS_CLOCK_ECONET_EN751221_SCU_H_
+
+#define EN751221_CLK_PCIE 0
+#define EN751221_CLK_SPI 1
+#define EN751221_CLK_BUS 2
+#define EN751221_CLK_CPU 3
+#define EN751221_CLK_HPT 4
+#define EN751221_CLK_GSW 5
+
+#define EN751221_MAX_CLKS 6
+
+#endif /* _DT_BINDINGS_CLOCK_ECONET_EN751221_SCU_H_ */
diff --git a/include/dt-bindings/reset/econet,en751221-scu.h b/include/dt-bindings/reset/econet,en751221-scu.h
new file mode 100644
index 000000000000..bad499d4d50a
--- /dev/null
+++ b/include/dt-bindings/reset/econet,en751221-scu.h
@@ -0,0 +1,49 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
+
+#ifndef __DT_BINDINGS_RESET_CONTROLLER_ECONET_EN751221_H_
+#define __DT_BINDINGS_RESET_CONTROLLER_ECONET_EN751221_H_
+
+#define EN751221_XPON_PHY_RST 0
+#define EN751221_PCM1_ZSI_ISI_RST 1
+#define EN751221_FE_QDMA1_RST 2
+#define EN751221_FE_QDMA2_RST 3
+#define EN751221_FE_UNZIP_RST 4
+#define EN751221_PCM2_RST 5
+#define EN751221_PTM_MAC_RST 6
+#define EN751221_CRYPTO_RST 7
+#define EN751221_SAR_RST 8
+#define EN751221_TIMER_RST 9
+#define EN751221_INTC_RST 10
+#define EN751221_BONDING_RST 11
+#define EN751221_PCM1_RST 12
+#define EN751221_UART_RST 13
+#define EN751221_GPIO_RST 14
+#define EN751221_GDMA_RST 15
+#define EN751221_I2C_MASTER_RST 16
+#define EN751221_PCM2_ZSI_ISI_RST 17
+#define EN751221_SFC_RST 18
+#define EN751221_UART2_RST 19
+#define EN751221_GDMP_RST 20
+#define EN751221_FE_RST 21
+#define EN751221_USB_HOST_P0_RST 22
+#define EN751221_GSW_RST 23
+#define EN751221_SFC2_PCM_RST 24
+#define EN751221_PCIE0_RST 25
+#define EN751221_PCIE1_RST 26
+#define EN751221_CPU_TIMER_RST 27
+#define EN751221_PCIE_HB_RST 28
+#define EN751221_SIMIF_RST 29
+#define EN751221_XPON_MAC_RST 30
+#define EN751221_GFAST_RST 31
+#define EN751221_CPU_TIMER2_RST 32
+#define EN751221_UART3_RST 33
+#define EN751221_UART4_RST 34
+#define EN751221_UART5_RST 35
+#define EN751221_I2C2_RST 36
+#define EN751221_XSI_MAC_RST 37
+#define EN751221_XSI_PHY_RST 38
+#define EN751221_DMT_RST 39
+#define EN751221_USB_PHY_P0_RST 40
+#define EN751221_USB_PHY_P1_RST 41
+
+#endif /* __DT_BINDINGS_RESET_CONTROLLER_ECONET_EN751221_H_ */
--
2.39.5
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox