* Re: [PATCH 0/7] phy: rockchip: usbdp: Fixes, DP 1-lane support and cleanups
From: Sebastian Reichel @ 2026-02-13 14:37 UTC (permalink / raw)
To: Andy Yan
Cc: Vinod Koul, Neil Armstrong, Heiko Stuebner, Andy Yan,
Yubing Zhang, linux-phy, linux-arm-kernel, linux-rockchip,
linux-kernel, kernel, Frank Wang, William Wu
In-Reply-To: <4a7a30c4.8848.19c288ea1f3.Coremail.andyshrk@163.com>
[-- Attachment #1.1: Type: text/plain, Size: 2208 bytes --]
Hi,
On Wed, Feb 04, 2026 at 08:09:22PM +0800, Andy Yan wrote:
> Hello Sebastian，
>
> At 2026-02-04 02:41:26, "Sebastian Reichel" <sebastian.reichel@collabora.com> wrote:
> >As there are some issues with the DisplayPort support, I went
> >though Rockchip's BSP kernel tree and looked for fixes. I found
> >two small changes for the initial register setup, which do not
> >help with the DP issue but seem sensible in general. Afterwards
> >I added one more fix, which corrects an issue that effectively
> >results in USB-C adapters with combined USB3+DP capabilities
> >not being able to use the DP part.
> >
> >Afterwards I added one more patch adding single-lane DP support
> >(found in Rockchip BSP kernel) and a couple of cleanups from my
> >side. These are logically independent from the fixes, but I put
> >all together in a single series because they need to be applied
> >in the right order to avoid conflicts.
> >
> >Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
> >---
> >Frank Wang (1):
> > phy: rockchip: usbdp: Amend SSC modulation deviation
> >
> >Sebastian Reichel (4):
> > phy: rockchip: usbdp: Add missing mode_change update
> > phy: rockchip: usbdp: Rename DP lane functions
> > phy: rockchip: usbdp: Use FIELD_PREP_WM16_CONST
> > phy: rockchip: usbdp: Cleanup DP lane selection function
> >
> >William Wu (1):
> > phy: rockchip: usbdp: Fix LFPS detect threshold control
> >
> >Zhang Yubing (1):
> > phy: rockchip: usbdp: Support single-lane DP
> >
> > drivers/phy/rockchip/phy-rockchip-usbdp.c | 114 +++++++++++++-----------------
> > 1 file changed, 48 insertions(+), 66 deletions(-)
>
> After applying this series of patches, the hub that previously
> couldn’t recognize Alt Mode can now detect it and work properly,
> but it also triggers a USB-related SERR — did I miss something？
I thought this was from a different patch that I needed to get DP
working. I've spent the last week debugging this and I'm just about
to send v2 with a workaround. FWIW the SError is not introduced by
this series, but before it was much harder to run into it.
Greetings,
-- Sebastian
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 112 bytes --]
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 2/6] scsi: ufs: qcom,sc7180-ufshc: dt-bindings: Document the Milos UFS Controller
From: Luca Weiss @ 2026-02-13 14:08 UTC (permalink / raw)
To: Luca Weiss, Martin K. Petersen, Herbert Xu, David S. Miller,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Alim Akhtar, Avri Altman, Bart Van Assche, Vinod Koul,
Neil Armstrong, Konrad Dybcio
Cc: ~postmarketos/upstreaming, phone-devel, linux-arm-msm,
linux-crypto, devicetree, linux-kernel, linux-scsi, linux-phy,
Krzysztof Kozlowski
In-Reply-To: <20260112-milos-ufs-v2-2-d3ce4f61f030@fairphone.com>
Hi Martin,
On Mon Jan 12, 2026 at 2:53 PM CET, Luca Weiss wrote:
> Document the UFS Controller on the Milos SoC.
>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
I've added you to this email now since you seem to pick up most patches
for these files. Could you take this one please to unblock Milos UFS
dts?
And maybe you could add yourself to MAINTAINERS so b4 picks up your
email for patches to these files?
Regards
Luca
> ---
> Documentation/devicetree/bindings/ufs/qcom,sc7180-ufshc.yaml | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/ufs/qcom,sc7180-ufshc.yaml b/Documentation/devicetree/bindings/ufs/qcom,sc7180-ufshc.yaml
> index d94ef4e6b85a..c85f126e52a0 100644
> --- a/Documentation/devicetree/bindings/ufs/qcom,sc7180-ufshc.yaml
> +++ b/Documentation/devicetree/bindings/ufs/qcom,sc7180-ufshc.yaml
> @@ -15,6 +15,7 @@ select:
> compatible:
> contains:
> enum:
> + - qcom,milos-ufshc
> - qcom,msm8998-ufshc
> - qcom,qcs8300-ufshc
> - qcom,sa8775p-ufshc
> @@ -33,6 +34,7 @@ properties:
> compatible:
> items:
> - enum:
> + - qcom,milos-ufshc
> - qcom,msm8998-ufshc
> - qcom,qcs8300-ufshc
> - qcom,sa8775p-ufshc
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2] phy: ti: j721e-wiz: Fix device node reference leak in wiz_get_lane_phy_types()
From: Vladimir Oltean @ 2026-02-13 10:46 UTC (permalink / raw)
To: Markus Elfring
Cc: Felix Gu, linux-phy, Jyri Sarha, Kishon Vijay Abraham I,
Neil Armstrong, Vinod Koul, LKML, kernel-janitors
In-Reply-To: <ffafec42-8d5f-429a-92b5-1b92c7643642@web.de>
On Fri, Feb 13, 2026 at 09:09:55AM +0100, Markus Elfring wrote:
> …
> > ---
> > Changes in v2:
> > - Use of_node_put() suggested by Vladimir Oltean.
> > - Link to v1: https://lore.kernel.org/r/20260211-wiz-v1-1-fdd018d02f33@gmail.com
> > ---
> > drivers/phy/ti/phy-j721e-wiz.c | 2 ++
> …
>
> * Would you like to complete the exception handling by using another goto chain?
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/coding-style.rst?h=v6.19#n526
While gotos have their place, here it seems simpler not to use them.
Felix would have needed to move the "int ret" variable from the
for_each_child_of_node_scoped() scope to the function scope, and
initialize it with 0. All that is unnecessary complexity here.
> * How do you think about to increase the application of scope-based resource management
> by additional update steps?
> https://elixir.bootlin.com/linux/v6.19-rc5/source/include/linux/cleanup.h#L157-L161
The cleanup.h API does not exist in all kernels where this bug fix can
be backported.
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2] phy: ti: j721e-wiz: Fix device node reference leak in wiz_get_lane_phy_types()
From: Vladimir Oltean @ 2026-02-13 10:47 UTC (permalink / raw)
To: Felix Gu
Cc: Vinod Koul, Neil Armstrong, Kishon Vijay Abraham I, Jyri Sarha,
linux-phy, linux-kernel, Markus Elfring
In-Reply-To: <20260212-wiz-v2-1-6e8bd4cc7a4a@gmail.com>
On Thu, Feb 12, 2026 at 06:39:19PM +0800, Felix Gu wrote:
> The serdes device_node is obtained using of_get_child_by_name(),
> which increments the reference count. However, it is never put,
> leading to a reference leak.
>
> Add the missing of_node_put() calls to ensure the reference count is
> properly balanced.
>
> Fixes: 7ae14cf581f2 ("phy: ti: j721e-wiz: Implement DisplayPort mode to the wiz driver")
> Suggested-by: Vladimir Oltean <olteanv@gmail.com>
> Signed-off-by: Felix Gu <ustc.gu@gmail.com>
> ---
> Changes in v2:
> - Use of_node_put() suggested by Vladimir Oltean.
> - Link to v1: https://lore.kernel.org/r/20260211-wiz-v1-1-fdd018d02f33@gmail.com
Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 2/3] phy: qcom: edp: Add per-version LDO configuration callback
From: Konrad Dybcio @ 2026-02-13 11:14 UTC (permalink / raw)
To: Yongxing Mou, Vinod Koul, Neil Armstrong, Dmitry Baryshkov
Cc: linux-arm-msm, linux-phy, linux-kernel
In-Reply-To: <8dbc18a0-6a64-491b-84b0-ba220c9050ac@oss.qualcomm.com>
On 2/12/26 10:04 AM, Yongxing Mou wrote:
>
>
> On 2/6/2026 6:52 PM, Konrad Dybcio wrote:
>> On 2/5/26 10:20 AM, Yongxing Mou wrote:
>>> Introduce the com_ldo_config callback to support per‑PHY LDO
>>> configuration.
>>>
>>> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com>
>>> ---
>>
>> [...]
>>
>>> +static int qcom_edp_ldo_config_v4(const struct qcom_edp *edp)
>>> +{
>>> + const struct phy_configure_opts_dp *dp_opts = &edp->dp_opts;
>>> + u32 ldo_config;
>>> +
>>> + if (!edp->is_edp)
>>> + ldo_config = 0x0;
>>> + else if (dp_opts->link_rate <= 2700)
>>> + ldo_config = 0xC1;
>>
>> lowercase hex, please
>>
>>> + else
>>> + ldo_config = 0x81;
>>> +
>>> + writel(ldo_config, edp->tx0 + TXn_LDO_CONFIG);
>>> + writel(ldo_config, edp->tx1 + TXn_LDO_CONFIG);
>>
>> tx1 should be dp_ops->lanes ? 2 : ldo_config : 0x00, in all cases,
>> I believe
>>
>> Konrad
> Hi, here i want to confirm again.. In the HPG main link brinup sequence, it not say write TX0/TX1 ldo_config based on the lane count. Only when we switch the lane mode, the LDO config will be updated according to the lane count. so here do we really need this condition?
I don't believe these two cases are differentiated in your patch, unless
you're trying to say that the hardware is smart enough to turn off the LDO
for TX23 on its own as we switch modes, which I wouldn't bet it is and can't
find confirmation for
Konrad
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 1/3] phy: qcom: edp: Correct and clean up eDP/DP combo PHY configuration values
From: Konrad Dybcio @ 2026-02-13 11:08 UTC (permalink / raw)
To: Yongxing Mou, Vinod Koul, Neil Armstrong
Cc: linux-arm-msm, linux-phy, linux-kernel
In-Reply-To: <92556aa2-607f-4743-a480-19458836fffa@oss.qualcomm.com>
On 2/9/26 10:00 AM, Yongxing Mou wrote:
>
>
> On 2/6/2026 6:47 PM, Konrad Dybcio wrote:
>> On 2/5/26 10:20 AM, Yongxing Mou wrote:
>>> According to the current HPG settings, most eDP/DP combo PHYs can reuse the
>>> same configuration values.
>>
>> Even across the various process nodes?
>>
> Emm,Currently, I have only checked the five platforms that already have eDP PHY driver support enabled. The results are the same as stated in the commit message: in DP mode and in eDP low‑vdiff mode, there are four platforms that can reuse the same settings. The HPG I used was the one I found on IPCAT. Regarding HRG, please move to next comment.
>>> DP mode：
>>> -sa8775p/sc7280/sc8280xp/x1e80100
>>> -glymur
>>> eDP mode(low vdiff):
>>> -glymur/sa8775p/sc8280xp/x1e80100
>>> -sc7280
>>> The current driver still keeps multiple versions of these tables and
>>> doesn't fully support every combo PHY mode. This patch removes the
>>> redundant configs and keeps only the sets we actually use, matching the
>>> platforms listed above.
>>
>> I see that e.g. eDP Low-Vdiff swing setting for RBR is:
>>
> Hi, do you mean emphasis settings, i don't see 0x11 0x12 in arr[0][1].
>> hamoa kodiak
>> arr[0][1] 0x11 0x12
>>
>> It may be that this changed later during tuning but it's not reflected
>> in the docs for kodiak
> Emm, if that, where can i get the correct value for tables.. In this patch, I’m indeed quite curious why the values before the modification differ from those in the HPG. I’m not sure about the reason. The HPG I used was taken directly from the current go/ipcat. Could you tell me where I can obtain the final table that should be used?
I.. wanted to ask you the same question..
I would assume that there's 3 possibilities:
a) the values have changed as they do during platform maturity
b) someone used the wrong values from the docs
c) someone downstream kernel as reference and that had wrong / older values
Konrad
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 3/3] phy: qcom: edp: Add eDP phy mode switch support
From: Konrad Dybcio @ 2026-02-13 11:06 UTC (permalink / raw)
To: Yongxing Mou, Vinod Koul, Neil Armstrong
Cc: linux-arm-msm, linux-phy, linux-kernel
In-Reply-To: <845165e6-4595-41de-8cff-d065e8f6b6be@oss.qualcomm.com>
On 2/10/26 11:29 AM, Yongxing Mou wrote:
>
>
> On 2/6/2026 7:02 PM, Konrad Dybcio wrote:
>> On 2/5/26 10:20 AM, Yongxing Mou wrote:
>>> Add DP/eDP switch support by splitting the PHY swing/pre-emphasis tables
>>> into separate DP and eDP configurations. This allows the driver to select
>>> the correct table based on the is_edp flag.
>>>
>>> Add a dedicated table for the SC7280/glymur platforms, as they are not
>>> compatible with the others.
>>>
>>> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com>
>>> ---
>>
>> [...]
>>
>>> +static const u8 edp_swing_hbr2_hbr3_v3[4][4] = {
>>> + { 0x0b, 0x11, 0x16, 0x1b },
>>> + { 0x0b, 0x19, 0x1f, 0xff },
>>> + { 0x18, 0x1f, 0xff, 0xff },
>>> + { 0x1f, 0xff, 0xff, 0xff }
>>> +};
>>> +
>>> +static const u8 edp_pre_emp_hbr2_hbr3_v3[4][4] = {
>>> + { 0x0c, 0x15, 0x19, 0x1e },
>>> + { 0x09, 0x14, 0x19, 0xff },
>>> + { 0x0f, 0x14, 0xff, 0xff },
>>> + { 0x0d, 0xff, 0xff, 0xff }
>>> +};
>>
>> This is not quite in line with docs for kodiak. Now, if you have
>> better/newer sequences than the HPG, I'm not objecting, but please
>> cross-check
>>
>> the rest of this patch I think looks fine
>>
>> Konrad
> Thanks for point that..
>>> +static const u8 edp_swing_hbr2_hbr3_v3[4][4] = {
>>> + { 0x0b, 0x11, 0x16, 0x1b },
> here should be { 0x06, 0x11, 0x16, 0x1b }, arr[0][1]: 0x0b->0x06
> does this looks fine? will check tables again..
For kodiak I see:
eDP HBR23 / low vdiff:
swing
0x0b, 0x11, 0x17, 0x1c
0x10, 0x19, 0x1f
0x19, 0x1f
0x1f
preemp
0x0c, 0x15, 0x19, 0x1e
0x08, 0x15, 0x19
0x0e, 0x14
0x0d
(notice how that mostly differs by the lowest bit being (not)set vs
your proposal)
eDP HBR23 / high vdiff:
swing
0x0a, 0x11, 0x17, 0x1f
0x0c, 0x14, 0x1d
0x15, 0x1f
0x17
preemp
0x08, 0x11, 0x17, 0x1b
0x00, 0x0c, 0x13
0x05, 0x10,
0x00
Konrad
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v3 5/5] phy: qcom: snps-femto-v2: Fix possible NULL-deref on early runtime suspend
From: Johan Hovold @ 2026-02-13 10:45 UTC (permalink / raw)
To: Loic Poulain
Cc: vkoul, kishon, linux-arm-msm, linux-phy, dmitry.baryshkov,
neil.armstrong, konrad.dybcio, Abel Vesa
In-Reply-To: <CAFEp6-3yk3sPXj+hGuWvAFsFJAXjH4kWLV8k_5_v9Hax0XxaOg@mail.gmail.com>
On Fri, Feb 13, 2026 at 10:45:32AM +0100, Loic Poulain wrote:
> On Fri, Feb 13, 2026 at 10:07 AM Johan Hovold <johan@kernel.org> wrote:
> >
> > On Thu, Feb 05, 2026 at 05:02:40PM +0100, Loic Poulain wrote:
> > > Enabling runtime PM before attaching the hsphy instance as driver data
> > > can lead to a NULL pointer dereference in runtime PM callbacks that
> > > expect valid driver data. There is a small window where the suspend
> > > callback may run after PM runtime enabling and before runtime forbid.
> >
> > So here too, the commit should reflect that this cannot really happen in
> > practice.
>
> This happened in practice in the qcom‑qusb2 PHY driver, with the same
> code flow.
> Bug: https://github.com/qualcomm-linux/qcom-deb-images/issues/208
> Patch: https://lore.kernel.org/linux-arm-msm/20251219085640.114473-1-loic.poulain@oss.qualcomm.com/
Thanks for the link.
> I know it may sound unlikely, but this crash has been reported
> several times during boot‑stress testing. I haven’t investigated
> deeply enough to determine whether it’s caused by an unfortunate
> preemption window or a racing CPU.
But I'm literally asking for *what* would trigger the suspend in that
initial window between enable() and forbid() cause I don't see it.
A racing user space daemon re-enabling runtime PM after forbid() is
the only thing I can think of that could trigger this.
Johan
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v3 5/5] phy: qcom: snps-femto-v2: Fix possible NULL-deref on early runtime suspend
From: Loic Poulain @ 2026-02-13 9:45 UTC (permalink / raw)
To: Johan Hovold
Cc: vkoul, kishon, linux-arm-msm, linux-phy, dmitry.baryshkov,
neil.armstrong, konrad.dybcio, Abel Vesa
In-Reply-To: <aY7pvakkOnaYsd5p@hovoldconsulting.com>
Hi Johan,
On Fri, Feb 13, 2026 at 10:07 AM Johan Hovold <johan@kernel.org> wrote:
>
> On Thu, Feb 05, 2026 at 05:02:40PM +0100, Loic Poulain wrote:
> > Enabling runtime PM before attaching the hsphy instance as driver data
> > can lead to a NULL pointer dereference in runtime PM callbacks that
> > expect valid driver data. There is a small window where the suspend
> > callback may run after PM runtime enabling and before runtime forbid.
>
> So here too, the commit should reflect that this cannot really happen in
> practice.
This happened in practice in the qcom‑qusb2 PHY driver, with the same
code flow.
Bug: https://github.com/qualcomm-linux/qcom-deb-images/issues/208
Patch: https://lore.kernel.org/linux-arm-msm/20251219085640.114473-1-loic.poulain@oss.qualcomm.com/
I know it may sound unlikely, but this crash has been reported
several times during boot‑stress testing. I haven’t investigated
deeply enough to determine whether it’s caused by an unfortunate
preemption window or a racing CPU.
I thought the series was already fairly conservative in its wording.
The titles use terms like “possible” and “unnecessary” to qualify the
crashes or unintended events. I can switch to “unlikely” if that
better characterizes the situation, but the issue isn’t purely
hypothetical.
Regards,
Loic
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v3 5/5] phy: qcom: snps-femto-v2: Fix possible NULL-deref on early runtime suspend
From: Johan Hovold @ 2026-02-13 9:07 UTC (permalink / raw)
To: Loic Poulain
Cc: vkoul, kishon, linux-arm-msm, linux-phy, dmitry.baryshkov,
neil.armstrong, konrad.dybcio, Abel Vesa
In-Reply-To: <20260205160240.748371-6-loic.poulain@oss.qualcomm.com>
On Thu, Feb 05, 2026 at 05:02:40PM +0100, Loic Poulain wrote:
> Enabling runtime PM before attaching the hsphy instance as driver data
> can lead to a NULL pointer dereference in runtime PM callbacks that
> expect valid driver data. There is a small window where the suspend
> callback may run after PM runtime enabling and before runtime forbid.
So here too, the commit should reflect that this cannot really happen in
practice.
> Attach the hsphy instance as driver data before enabling runtime PM to
> prevent NULL pointer dereference in runtime PM callbacks.
>
> Reorder pm_runtime_enable() and pm_runtime_forbid() to prevent a
> short window where an unnecessary runtime suspend can occur.
>
> Use the devres-managed version to ensure PM runtime is symmetrically
> disabled during driver removal for proper cleanup.
>
> Fixes: 0d75f508a9d5 ("phy: qcom-snps: Add runtime suspend and resume handlers")
> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
> Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
Johan
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v3 3/5] phy: qcom: qmp-usb-legacy: Fix possible NULL-deref on early runtime suspend
From: Johan Hovold @ 2026-02-13 9:02 UTC (permalink / raw)
To: Loic Poulain
Cc: vkoul, kishon, linux-arm-msm, linux-phy, dmitry.baryshkov,
neil.armstrong, konrad.dybcio, Abel Vesa
In-Reply-To: <20260205160240.748371-4-loic.poulain@oss.qualcomm.com>
On Thu, Feb 05, 2026 at 05:02:38PM +0100, Loic Poulain wrote:
> There is a small window where the runtime suspend callback may run
> after pm_runtime_enable() and before pm_runtime_forbid(). In this
> case, a crash occurs because runtime suspend/resume dereferences
> qmp->phy pointer, which is not yet initialized:
> `if (!qmp->phy->init_count) {`
So here too, what would trigger a suspend in this window? (Except
possibly user space disabling and reenabling runtime pm, which can't
happen in practice).
> This can also happen if user re-enables runtime-pm via the sysfs
> attribute before qmp phy is initialized.
This I guess can happen in theory, but you'd need to try pretty hard.
But I think the commit message should better reflect this is all mostly
theoretical (currently it sounds like something you've actually hit).
Johan
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v3 1/5] phy: qcom: qmp-combo: Prevent unnecessary PM runtime suspend at boot
From: Johan Hovold @ 2026-02-13 8:47 UTC (permalink / raw)
To: Loic Poulain
Cc: vkoul, kishon, linux-arm-msm, linux-phy, dmitry.baryshkov,
neil.armstrong, konrad.dybcio, Abel Vesa
In-Reply-To: <20260205160240.748371-2-loic.poulain@oss.qualcomm.com>
On Thu, Feb 05, 2026 at 05:02:36PM +0100, Loic Poulain wrote:
> There is a small window where the device can suspend after
> pm_runtime_enable() and before pm_runtime_forbid(), causing an
> unnecessary suspend/resume cycle while the PHY is not yet registered.
What do you think can trigger a suspend in that window?
(A racing user space request to both disable and re-enable runtime PM
could theoretically do so but not in practice.).
> Move pm_runtime_forbid() before pm_runtime_enable() to eliminate
> this race.
I think the commit message should reflect that this isn't really an
issue.
Johan
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2] phy: ti: j721e-wiz: Fix device node reference leak in wiz_get_lane_phy_types()
From: Markus Elfring @ 2026-02-13 8:09 UTC (permalink / raw)
To: Felix Gu, linux-phy, Jyri Sarha, Kishon Vijay Abraham I,
Neil Armstrong, Vinod Koul, Vladimir Oltean
Cc: LKML, kernel-janitors
In-Reply-To: <20260212-wiz-v2-1-6e8bd4cc7a4a@gmail.com>
…
> ---
> Changes in v2:
> - Use of_node_put() suggested by Vladimir Oltean.
> - Link to v1: https://lore.kernel.org/r/20260211-wiz-v1-1-fdd018d02f33@gmail.com
> ---
> drivers/phy/ti/phy-j721e-wiz.c | 2 ++
…
* Would you like to complete the exception handling by using another goto chain?
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/coding-style.rst?h=v6.19#n526
* How do you think about to increase the application of scope-based resource management
by additional update steps?
https://elixir.bootlin.com/linux/v6.19-rc5/source/include/linux/cleanup.h#L157-L161
Regards,
Markus
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH v2 2/2] phy: qcom: edp: Add per-version LDO configuration callback
From: Yongxing Mou @ 2026-02-13 7:31 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong
Cc: linux-arm-msm, linux-phy, linux-kernel, Yongxing Mou, stable
In-Reply-To: <20260213-edp_phy-v2-0-43c40976435e@oss.qualcomm.com>
For eDP low Vdiff, the LDO setting depends on the PHY version, instead of
being a simple 0x0 or 0x01. Introduce the com_ldo_config callback to
correct LDO setting accroding to the HPG.
Since SC7280 uses different LDO settings than SA8775P/SC8280XP, introduce
qcom_edp_phy_ops_v3 to keep the LDO setting correct.
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 | 86 ++++++++++++++++++++++++++++++++-----
1 file changed, 76 insertions(+), 10 deletions(-)
diff --git a/drivers/phy/qualcomm/phy-qcom-edp.c b/drivers/phy/qualcomm/phy-qcom-edp.c
index ff14de41cb1c..6464df8d2a62 100644
--- a/drivers/phy/qualcomm/phy-qcom-edp.c
+++ b/drivers/phy/qualcomm/phy-qcom-edp.c
@@ -81,6 +81,7 @@ struct phy_ver_ops {
int (*com_clk_fwd_cfg)(const struct qcom_edp *edp);
int (*com_configure_pll)(const struct qcom_edp *edp);
int (*com_configure_ssc)(const struct qcom_edp *edp);
+ int (*com_ldo_config)(const struct qcom_edp *edp);
};
struct qcom_edp_phy_cfg {
@@ -304,7 +305,7 @@ static int qcom_edp_set_voltages(struct qcom_edp *edp, const struct phy_configur
const struct qcom_edp_swing_pre_emph_cfg *cfg;
unsigned int v_level = 0;
unsigned int p_level = 0;
- u8 ldo_config;
+ int ret;
u8 swing;
u8 emph;
int i;
@@ -330,13 +331,13 @@ static int qcom_edp_set_voltages(struct qcom_edp *edp, const struct phy_configur
if (swing == 0xff || emph == 0xff)
return -EINVAL;
- ldo_config = edp->is_edp ? 0x0 : 0x1;
+ ret = edp->cfg->ver_ops->com_ldo_config(edp);
+ if (ret)
+ return ret;
- writel(ldo_config, edp->tx0 + TXn_LDO_CONFIG);
writel(swing, edp->tx0 + TXn_TX_DRV_LVL);
writel(emph, edp->tx0 + TXn_TX_EMP_POST1_LVL);
- writel(ldo_config, edp->tx1 + TXn_LDO_CONFIG);
writel(swing, edp->tx1 + TXn_TX_DRV_LVL);
writel(emph, edp->tx1 + TXn_TX_EMP_POST1_LVL);
@@ -560,6 +561,52 @@ static int qcom_edp_com_configure_pll_v4(const struct qcom_edp *edp)
return 0;
}
+static int qcom_edp_ldo_config_v3(const struct qcom_edp *edp)
+{
+ const struct phy_configure_opts_dp *dp_opts = &edp->dp_opts;
+ u32 ldo_config;
+
+ if (!edp->is_edp)
+ ldo_config = 0x0;
+ else if (dp_opts->link_rate <= 2700)
+ ldo_config = 0x81;
+ else
+ ldo_config = 0x41;
+
+ writel(ldo_config, edp->tx0 + TXn_LDO_CONFIG);
+ writel(ldo_config, edp->tx1 + TXn_LDO_CONFIG);
+
+ return 0;
+}
+
+static int qcom_edp_ldo_config_v4(const struct qcom_edp *edp)
+{
+ const struct phy_configure_opts_dp *dp_opts = &edp->dp_opts;
+ u32 ldo_config;
+
+ if (!edp->is_edp)
+ ldo_config = 0x0;
+ else if (dp_opts->link_rate <= 2700)
+ ldo_config = 0xc1;
+ else
+ ldo_config = 0x81;
+
+ writel(ldo_config, edp->tx0 + TXn_LDO_CONFIG);
+ writel(ldo_config, edp->tx1 + TXn_LDO_CONFIG);
+
+ return 0;
+}
+
+static const struct phy_ver_ops qcom_edp_phy_ops_v3 = {
+ .com_power_on = qcom_edp_phy_power_on_v4,
+ .com_resetsm_cntrl = qcom_edp_phy_com_resetsm_cntrl_v4,
+ .com_bias_en_clkbuflr = qcom_edp_com_bias_en_clkbuflr_v4,
+ .com_clk_fwd_cfg = qcom_edp_com_clk_fwd_cfg_v4,
+ .com_configure_pll = qcom_edp_com_configure_pll_v4,
+ .com_configure_ssc = qcom_edp_com_configure_ssc_v4,
+ .com_ldo_config = qcom_edp_ldo_config_v3,
+};
+
static const struct phy_ver_ops qcom_edp_phy_ops_v4 = {
.com_power_on = qcom_edp_phy_power_on_v4,
.com_resetsm_cntrl = qcom_edp_phy_com_resetsm_cntrl_v4,
@@ -567,6 +614,7 @@ static const struct phy_ver_ops qcom_edp_phy_ops_v4 = {
.com_clk_fwd_cfg = qcom_edp_com_clk_fwd_cfg_v4,
.com_configure_pll = qcom_edp_com_configure_pll_v4,
.com_configure_ssc = qcom_edp_com_configure_ssc_v4,
+ .com_ldo_config = qcom_edp_ldo_config_v4,
};
static const struct qcom_edp_phy_cfg sa8775p_dp_phy_cfg = {
@@ -583,7 +631,7 @@ static const struct qcom_edp_phy_cfg sc7280_dp_phy_cfg = {
.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,
+ .ver_ops = &qcom_edp_phy_ops_v3,
};
static const struct qcom_edp_phy_cfg sc8280xp_dp_phy_cfg = {
@@ -768,12 +816,31 @@ static int qcom_edp_com_configure_pll_v6(const struct qcom_edp *edp)
return 0;
}
+static int qcom_edp_ldo_config_v6(const struct qcom_edp *edp)
+{
+ const struct phy_configure_opts_dp *dp_opts = &edp->dp_opts;
+ u32 ldo_config;
+
+ if (!edp->is_edp)
+ ldo_config = 0x0;
+ else if (dp_opts->link_rate <= 2700)
+ ldo_config = 0x51;
+ else
+ ldo_config = 0x91;
+
+ writel(ldo_config, edp->tx0 + TXn_LDO_CONFIG);
+ writel(ldo_config, edp->tx1 + TXn_LDO_CONFIG);
+
+ return 0;
+}
+
static const struct phy_ver_ops qcom_edp_phy_ops_v6 = {
.com_power_on = qcom_edp_phy_power_on_v6,
.com_resetsm_cntrl = qcom_edp_phy_com_resetsm_cntrl_v6,
.com_bias_en_clkbuflr = qcom_edp_com_bias_en_clkbuflr_v6,
.com_configure_pll = qcom_edp_com_configure_pll_v6,
.com_configure_ssc = qcom_edp_com_configure_ssc_v6,
+ .com_ldo_config = qcom_edp_ldo_config_v6,
};
static struct qcom_edp_phy_cfg x1e80100_phy_cfg = {
@@ -954,6 +1021,7 @@ static const struct phy_ver_ops qcom_edp_phy_ops_v8 = {
.com_clk_fwd_cfg = qcom_edp_com_clk_fwd_cfg_v8,
.com_configure_pll = qcom_edp_com_configure_pll_v8,
.com_configure_ssc = qcom_edp_com_configure_ssc_v8,
+ .com_ldo_config = qcom_edp_ldo_config_v6,
};
static struct qcom_edp_phy_cfg glymur_phy_cfg = {
@@ -969,7 +1037,6 @@ static int qcom_edp_phy_power_on(struct phy *phy)
const struct qcom_edp *edp = phy_get_drvdata(phy);
u32 bias0_en, drvr0_en, bias1_en, drvr1_en;
unsigned long pixel_freq;
- u8 ldo_config = 0x0;
int ret;
u32 val;
u8 cfg1;
@@ -978,11 +1045,10 @@ static int qcom_edp_phy_power_on(struct phy *phy)
if (ret)
return ret;
- if (edp->cfg->swing_pre_emph_cfg && !edp->is_edp)
- ldo_config = 0x1;
+ ret = edp->cfg->ver_ops->com_ldo_config(edp);
+ if (ret)
+ return ret;
- writel(ldo_config, edp->tx0 + TXn_LDO_CONFIG);
- writel(ldo_config, edp->tx1 + TXn_LDO_CONFIG);
writel(0x00, edp->tx0 + TXn_LANE_MODE_1);
writel(0x00, edp->tx1 + TXn_LANE_MODE_1);
--
2.43.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v2 1/2] phy: qcom: edp: Add eDP/DP mode switch support
From: Yongxing Mou @ 2026-02-13 7:31 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong
Cc: linux-arm-msm, linux-phy, linux-kernel, Yongxing Mou, stable
In-Reply-To: <20260213-edp_phy-v2-0-43c40976435e@oss.qualcomm.com>
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 13feab99feec..ff14de41cb1c 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,
};
@@ -765,7 +779,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,
};
@@ -944,7 +959,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,
};
--
2.43.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v2 0/2] phy: qcom: edp: Add DP/eDP switch for phys
From: Yongxing Mou @ 2026-02-13 7:31 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong
Cc: linux-arm-msm, linux-phy, linux-kernel, Yongxing Mou, stable
Currently the PHY selects the DP/eDP configuration tables in a fixed way,
choosing the table when enable. This driver has known issues:
1. The selected table does not match the actual platform mode.
2. It cannot support both modes at the same time.
As discussed here[1], this series:
1. Cleans up duplicated and incorrect tables based on the HPG.
2. Fixes the LDO programming error in eDP mode.
3. Adds DP/eDP mode switching support.
Note: x1e80100/sa8775p/sc7280 have been tested, while glymur/sc8280xp
have not been tested.
[1] https://lore.kernel.org/all/20260119-klm_dpphy-v2-1-52252190940b@oss.qualcomm.com/
Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com>
---
Changes in v2:
- Combine the third patch with the first one.[Dmitry]
- Fix code formatting issues.[Konrad][Dmitry]
- Update the commit message description.[Dmitry][Konrad]
- Fix kodiak swing/pre_emp table values.[Konrad]
- Link to v1: https://lore.kernel.org/r/20260205-edp_phy-v1-0-231882bbf3f1@oss.qualcomm.com
---
Yongxing Mou (2):
phy: qcom: edp: Add eDP/DP mode switch support
phy: qcom: edp: Add per-version LDO configuration callback
drivers/phy/qualcomm/phy-qcom-edp.c | 176 ++++++++++++++++++++++++++----------
1 file changed, 129 insertions(+), 47 deletions(-)
---
base-commit: fc4e91c639c0af93d63c3d5bc0ee45515dd7504a
change-id: 20260205-edp_phy-1eca3ed074c0
Best regards,
--
Yongxing Mou <yongxing.mou@oss.qualcomm.com>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v9 0/2] Add driver support for Eswin EIC7700 SoC SATA PHY
From: Yulin Lu @ 2026-02-13 6:20 UTC (permalink / raw)
To: vkoul, neil.armstrong, robh, krzk+dt, conor+dt, p.zabel,
linux-phy, devicetree, linux-kernel
Cc: ningyu, linmin, fenglin
In-Reply-To: <20260205082009.1780-1-luyulin@eswincomputing.com>
> Updates:
> v9 -> v8:
> - eswin,eic7700-sata-phy.yaml
> - Modify the format of the "default" field in the
> "eswin,tx-amplitude-tuning" and "eswin,tx-preemph-tuning"
> properties.
> - phy-eic7700-sata.c
> - Correct the incorrectly formatted symbol "-" in the comments.
> - Link to v8: https://lore.kernel.org/lkml/20260123024823.1612-1-luyulin@eswincomputing.com/
>
> v8 -> v7:
> - eswin,eic7700-sata-phy.yaml
> - Add "eswin,tx-amplitude-tuning" and "eswin,tx-preemph-tuning"
> properties, because these parameters may vary across different
> circuit boards.
> - Delete reviewed-by tag of Krzysztof Kozlowski, because the tuning
> properties are introduced.
> - phy-eic7700-sata.c
> - Try to get SATA PHY transmitter amplitude and pre-emphasis signal
> eye diagram tuning parameters from dts instead of hardcoded values
> in the code. Because, these parameters may vary across different
> circuit boards. Define default tuning parameters and use it when
> these properties are not declared in dts.
> - Add a comment to explain the reason for mapping I/O resources with
> platform_get_resource and devm_ioremap instead of using the
> devm_platform_ioremap_resource API.
> - Link to v7: https://lore.kernel.org/lkml/20260106062944.1529-1-luyulin@eswincomputing.com/
Hi Vinod, all,
In v7, I got driver review comments from Vinod. After fixing and submitting v8,
I received yaml comments from Krzysztof. v9 now has Reviewed-by from Krzysztof.
So I want to confirm whether there are any further comments on the driver code
in v9 and if it meets the requirements for merging.
Best regards,
Yulin Lu
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [REGRESSION] HDMI monitor not working on Radxa Rock 5B after phy rockchip samsung hdptx HDMI 2.1 FRL patchset
From: Cristian Ciocaltea @ 2026-02-12 22:04 UTC (permalink / raw)
To: dubito, Vinod Koul, Neil Armstrong, Heiko Stuebner, linux-phy,
linux-arm-kernel, linux-rockchip, linux-kernel, regressions
In-Reply-To: <b32164001947ba922aefb6ca86a8dc59e9323d2b.camel@online.de>
Hi Thomas,
On 2/11/26 11:20 PM, Thomas Niederprüm wrote:
> Hi,
>
> I'm running a Radxa Rock 5B (rk3588) on a 10+ year old Samsung TV screen
> connected via HDMI. This worked flawlessly in 6.18.7 but does not work on linux-
> next. I bisected the problem and identified commit 3481fc04 to be the first bad
> commit. This points to the phy PLL clock rate calculation to be the problem in
> connection with my monitor. As it seems relevant, I attached the EDID of my
> monitor.
>
> I'm booting the kernel out of EDK2 after which efifb is correctly taking over
> the initialized display and I can see the initial kernel boot messages on the
> HDMI output. After the drm/kms in the kernel takes over the screen shortly turns
> black, changes resolution, and then correctly displays on 6.18.7. However, in
> linux-next the screen remains black after kms took over. I cannot see any
> obvious differences in the boot logs but I attached two boot logs, one for the
> working 6.18.7 kernel and one for the non-working linux-next kernel.
>
> When reverting 3481fc04..de5dba83 (i.e. the faulty commit and the ones that
> followed in the HDMI 2.1 FRL series) I can build a working kernel from linux-
> next.
>
> I don't know where to dig from here but I'm happy to run any test necessary to
> track down the problem.
It'd be helpful if you could resend the logs after booting both kernels with the
following params (requires CONFIG_DYNAMIC_DEBUG=y):
rockchipdrm.dyndbg=+p dw_hdmi_qp.dyndbg=+p phy_rockchip_samsung_hdptx.dyndbg=+p
As well as running the command below before connecting your display/TV:
$ echo 0x4 > /sys/module/drm/parameters/debug
I've noticed you're forcing "video=HDMI-A-1:1920x1080M@60", which should be
anyway the preferred mode (according to the EDID).
Did you try choosing a different one, e.g. 1920x1080@50 or 1920x1080@30 (they
are supported according to the listing in CTA-861 Extension Block). That's more
a test to confirm the issue affects a particular modeline, or is more general.
FWIW I've tested over 40 modes with different displays/TVs and didn't notice any
regression, hence I'm probably missing something here.
Thanks for the report!
Cristian
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 1/4 v2] dt-bindings: serdes: s32g: Add NXP serdes subsystem
From: Rob Herring @ 2026-02-12 21:10 UTC (permalink / raw)
To: Vincent Guittot
Cc: vkoul, neil.armstrong, krzk+dt, conor+dt, ciprianmarian.costea,
s32, p.zabel, linux, ghennadi.procopciuc, Ionut.Vicovan,
linux-phy, devicetree, linux-kernel, linux-arm-kernel, netdev,
horms, Frank.li
In-Reply-To: <CAKfTPtA299R7yn3r=tCqhhP_tK3E_UpGSMrDLyRP4Ccwt1m58g@mail.gmail.com>
On Thu, Feb 12, 2026 at 1:17 AM Vincent Guittot
<vincent.guittot@linaro.org> wrote:
>
> On Tue, 10 Feb 2026 at 01:40, Rob Herring <robh@kernel.org> wrote:
> >
> > On Tue, Feb 03, 2026 at 05:19:14PM +0100, Vincent Guittot wrote:
> > > Describe the serdes subsystem available on the S32G platforms.
> > >
> > > Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
> > > ---
> > > .../bindings/phy/nxp,s32g-serdes.yaml | 154 ++++++++++++++++++
> > > 1 file changed, 154 insertions(+)
> > > create mode 100644 Documentation/devicetree/bindings/phy/nxp,s32g-serdes.yaml
> > >
> > > diff --git a/Documentation/devicetree/bindings/phy/nxp,s32g-serdes.yaml b/Documentation/devicetree/bindings/phy/nxp,s32g-serdes.yaml
> > > new file mode 100644
> > > index 000000000000..fad34bee2a4f
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/phy/nxp,s32g-serdes.yaml
> > > @@ -0,0 +1,154 @@
> > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/phy/nxp,s32g-serdes.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: NXP S32G2xxx/S32G3xxx SerDes PHY subsystem
> > > +
> > > +maintainers:
> > > + - Ghennadi Procopciuc <ghennadi.procopciuc@nxp.com>
> > > +
> > > +description: |
> > > + The SerDes subsystem on S32G SoC Family includes two types of PHYs:
> > > + - One PCIe PHY: Supports various PCIe operation modes
> > > + - Two Ethernet Physical Coding Sublayer (XPCS) controllers
> > > +
> > > + SerDes operation mode selects the enabled PHYs and speeds. Clock frequency
> > > + must be adapted accordingly. Below table describes all possible operation
> > > + modes.
> > > +
> > > + Mode PCIe XPCS0 XPCS1 PHY clock Description
> > > + SGMII SGMII (MHz)
> > > + -------------------------------------------------------------------------
> > > + 0 Gen3 N/A N/A 100 Single PCIe
> > > + 1 Gen2 1.25Gbps N/A 100 PCIe/SGMII
> > > + 2 Gen2 N/A 1.25Gbps 100 PCIe/SGMII
> > > + 3 N/A 1.25Gbps 1.25Gbps 100,125 SGMII
> > > + 4 N/A 3.125/1.25Gbps 3.125/1.25Gbps 125 SGMII
> > > + 5 Gen2 N/A 3.125Gbps 100 PCIe/SGMII
> >
> > Mixed tabs and spaces. Drop the tabs.
>
> okay
>
> >
> > What's not clear to me is do you have 2 or 4 lanes?
>
> 2 lanes per serdes
> as an example mode 0 is one PCIe x2 lane
> and mode 1 is one PCIe x1 and one xpcs0/SGMII on lane 1
> or mode 3 is one xpcs0/SGMII on lane 0 and one xpcs1/SGMII on lane 1
Still confused. So 2 total lanes?
>
> >
> > > +
> > > +properties:
> > > + compatible:
> > > + oneOf:
> > > + - enum:
> > > + - nxp,s32g2-serdes
> > > + - items:
> > > + - const: nxp,s32g3-serdes
> > > + - const: nxp,s32g2-serdes
> > > +
> > > + reg:
> > > + maxItems: 4
> > > +
> > > + reg-names:
> > > + items:
> > > + - const: ss_pcie
> > > + - const: pcie_phy
> > > + - const: xpcs0
> > > + - const: xpcs1
> > > +
> > > + clocks:
> > > + minItems: 4
> > > + maxItems: 5
> > > +
> > > + clock-names:
> > > + items:
> > > + - const: axi
> > > + - const: aux
> > > + - const: apb
> > > + - const: ref
> > > + - const: ext
> > > + minItems: 4
> > > +
> > > + resets:
> > > + maxItems: 2
> > > +
> > > + reset-names:
> > > + items:
> > > + - const: serdes
> > > + - const: pcie
> > > +
> > > + nxp,sys-mode:
> > > + $ref: /schemas/types.yaml#/definitions/uint32
> >
> > maximum: 5
> >
> > Though isn't this redundant with the child nodes? You could use the
> > standard 'phy-mode' property in each child.
>
> not really because we can have mode 1 but only a node to describe
> lane0 for PCIe x1 if the lane 1 is not used
>
> >
> > > + description: |
> > > + SerDes operational mode. See above table for possible values.
> > > +
> > > + '#address-cells':
> > > + const: 1
> > > +
> > > + '#size-cells':
> > > + const: 0
> > > +
> > > +patternProperties:
> > > + '^serdes[0,1]_lane@[0,1]$':
> >
> > Do you need to support serdes0_lane@0 and serdes1_lane@0 (or similar
> > with "@1")? That's illegal as you have 2 nodes with the same address.
>
> okay, we can find other naming
>
> >
> > > + description:
> > > + Describe a serdes lane.
> > > + type: object
> > > +
> > > + properties:
> > > + compatible:
> > > + enum:
> > > + - nxp,s32g2-serdes-pcie-phy
> > > + - nxp,s32g2-serdes-xpcs
> >
> > Seems like phy-mode would be sufficient. Are these separate blocks from
> > the parent?
>
> Isn't phy-mode only for ethernet phy ?
Sorry, it is "phy-type" that I was thinking about. That takes the
types defined in dt-bindings/phy/phy.h. The type can be defined either
in "phy-type" or in the phy cells if the type is per identifier.
Really, Given each lane doesn't have any of its own resources, I'd
probably get rid of the child nodes and put the type into the phy
cells. Then you'd have something like this:
// PCIE on lanes 0 and 1 (mode 0)
pcie {
phys = <&phy 0 PHY_TYPE_PCIE>, <&phy 1 PHY_TYPE_PCIE>;
};
// PCIE on lane 0 (mode 1)
pcie {
phys = <&phy 0 PHY_TYPE_PCIE>;
};
// Ethernet on lane 1
ethernet {
phys = <&phy 1 PHY_TYPE_SGMII>;
};
I perhaps don't have the cells right if it is more than just lane 0
and lane 1, but you can put anything there you want. The cell
definition is provider specific.
If you need to get the overall system wide configuration, that can be
done. It's not terribly efficient, but you can iterate all 'phys'
nodes in the DT, find the ones for your provider (&phy) and examine
the cell values.
Rob
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 2/4] arm64: dts: rockchip: Add USB2.0 PHY for RK3368
From: Vladimir Oltean @ 2026-02-12 16:55 UTC (permalink / raw)
To: WeiHao Li
Cc: heiko, robh, krzk+dt, conor+dt, linux-phy, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel
In-Reply-To: <20250909132958.26423-3-cn.liweihao@gmail.com>
On Tue, Sep 09, 2025 at 09:29:56PM +0800, WeiHao Li wrote:
> RK3368 has one USB2.0 PHY with two ports, This adds device tree node for
> it.
>
> Signed-off-by: WeiHao Li <cn.liweihao@gmail.com>
> ---
> arch/arm64/boot/dts/rockchip/rk3368.dtsi | 29 ++++++++++++++++++++++++
> 1 file changed, 29 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3368.dtsi b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
> index 1b21787269..b09e431a64 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3368.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
> @@ -766,11 +766,40 @@ cru: clock-controller@ff760000 {
> grf: syscon@ff770000 {
> compatible = "rockchip,rk3368-grf", "syscon", "simple-mfd";
> reg = <0x0 0xff770000 0x0 0x1000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
This introduces a device tree warning. You cannot mix nodes with no unit
address (io-domains) with nodes with a unit address (usb2-phy@700) on
the same hierarchical level. You have to pick a format and stick to it.
>
> io_domains: io-domains {
> compatible = "rockchip,rk3368-io-voltage-domain";
> status = "disabled";
> };
> +
> + u2phy: usb2-phy@700 {
> + compatible = "rockchip,rk3368-usb2phy";
> + reg = <0x700 0x2c>;
> + clocks = <&cru SCLK_OTGPHY0>;
> + clock-names = "phyclk";
> + clock-output-names = "usb480m_phy";
> + #clock-cells = <0>;
> + status = "disabled";
> +
> + u2phy_otg: otg-port {
> + interrupts = <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 93 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 95 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "otg-bvalid", "otg-id",
> + "linestate";
> + #phy-cells = <0>;
> + status = "disabled";
> + };
> +
> + u2phy_host: host-port {
> + interrupts = <GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "linestate";
> + #phy-cells = <0>;
> + status = "disabled";
> + };
> + };
> };
>
> wdt: watchdog@ff800000 {
> --
> 2.47.2
>
>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v9 1/7] phy: can-transceiver: rename temporary helper function to avoid conflict
From: Geert Uytterhoeven @ 2026-02-12 16:53 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Josua Mayer, Marc Kleine-Budde, Vincent Mailhol, Vinod Koul,
Neil Armstrong, Peter Rosin, Aaro Koskinen, Andreas Kemnade,
Kevin Hilman, Roger Quadros, Tony Lindgren, Janusz Krzysztofik,
Vignesh R, Andi Shyti, Ulf Hansson, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, Wolfram Sang, Yazan Shhady, Jon Nettleton,
Mikhail Anikin, linux-can, linux-phy, linux-kernel, linux-omap,
linux-i2c, linux-mmc, devicetree, linux-renesas-soc
In-Reply-To: <20260212164823.mbeycqwzsy2dfq6e@skbuf>
Hi Vladimir,
On Thu, 12 Feb 2026 at 17:48, Vladimir Oltean <olteanv@gmail.com> wrote:
> On Sun, Feb 08, 2026 at 05:38:56PM +0200, Josua Mayer wrote:
> > Rename the temporary devm_mux_state_get_optional function to avoid
> > conflict with upcoming implementation in multiplexer subsystem.
> >
> > Acked-by: Vinod Koul <vkoul@kernel.org>
> > Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
> > Signed-off-by: Josua Mayer <josua@solid-run.com>
>
> In the future, when you have a series with cross-tree dependencies,
> please try to think of it as individual mini-series for each tree's
> 'next' branch, and specify clearly that you need stable tags (to be
> pulled into other trees). Telling maintainers what is your expected
> merge strategy helps avoid making mistakes.
>
> For example, if you did that in this set, you wouldn't have missed the
> fact that in linux-phy/next, phy-can-transceiver is _not_ the only
> occurrence of devm_mux_state_get_optional(). There's another one in
> drivers/phy/renesas/phy-rcar-gen3-usb2.c, and that should be also
> handled in order for trees to not enter inconsistent states.
To his defense, the one in drivers/phy/renesas/phy-rcar-gen3-usb2.c
is a recent addition.
So this is yet another case of "convert all current users" (i.e. those
present in the typical subsystem base, typically *-rc1), with new
users popping up in -next in parallel, which happens all the time...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v9 1/7] phy: can-transceiver: rename temporary helper function to avoid conflict
From: Vladimir Oltean @ 2026-02-12 16:48 UTC (permalink / raw)
To: Josua Mayer
Cc: Marc Kleine-Budde, Vincent Mailhol, Vinod Koul, Neil Armstrong,
Peter Rosin, Aaro Koskinen, Andreas Kemnade, Kevin Hilman,
Roger Quadros, Tony Lindgren, Janusz Krzysztofik, Vignesh R,
Andi Shyti, Ulf Hansson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Geert Uytterhoeven, Magnus Damm, Wolfram Sang,
Yazan Shhady, Jon Nettleton, Mikhail Anikin, linux-can, linux-phy,
linux-kernel, linux-omap, linux-i2c, linux-mmc, devicetree,
linux-renesas-soc
In-Reply-To: <20260208-rz-sdio-mux-v9-1-9a3be13c1280@solid-run.com>
Hi Josua,
On Sun, Feb 08, 2026 at 05:38:56PM +0200, Josua Mayer wrote:
> Rename the temporary devm_mux_state_get_optional function to avoid
> conflict with upcoming implementation in multiplexer subsystem.
>
> Acked-by: Vinod Koul <vkoul@kernel.org>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
> Signed-off-by: Josua Mayer <josua@solid-run.com>
> ---
In the future, when you have a series with cross-tree dependencies,
please try to think of it as individual mini-series for each tree's
'next' branch, and specify clearly that you need stable tags (to be
pulled into other trees). Telling maintainers what is your expected
merge strategy helps avoid making mistakes.
For example, if you did that in this set, you wouldn't have missed the
fact that in linux-phy/next, phy-can-transceiver is _not_ the only
occurrence of devm_mux_state_get_optional(). There's another one in
drivers/phy/renesas/phy-rcar-gen3-usb2.c, and that should be also
handled in order for trees to not enter inconsistent states.
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 2/3] phy: k1-usb: add disconnect function support
From: Yixun Lan @ 2026-02-12 14:43 UTC (permalink / raw)
To: Yao Zi
Cc: Yixun Lan, Vinod Koul, Neil Armstrong, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Ze Huang, Junzhong Pan,
linux-phy, devicetree, linux-riscv, spacemit, linux-kernel
In-Reply-To: <aY24UOvYsnh_7ZCO@pie>
Hi Yao,
On 11:24 Thu 12 Feb , Yao Zi wrote:
> On Thu, Feb 12, 2026 at 09:38:55AM +0800, Yixun Lan wrote:
> > A disconnect status BIT of USB2 PHY need to be cleared, otherwise
> > it will fail to work properly during next connection when devices
> > connect to roothub directly.
>
> This sounds like a bug. Does it affect K1 SoC as well? If so, I think
> it deserves a Fixes tag and backporting.
>
yes, but I haven't checked if it will affect real case since the problem
exist with devices connected to roothub directly only..
anyway, I think it deserves to add a Fixes tag, so will do in next version
--
Yixun Lan (dlan)
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 3/3] phy: k1-usb: k3: add USB2 PHY support
From: Yixun Lan @ 2026-02-12 14:35 UTC (permalink / raw)
To: Yao Zi
Cc: Yixun Lan, Vinod Koul, Neil Armstrong, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Ze Huang, Junzhong Pan,
linux-phy, devicetree, linux-riscv, spacemit, linux-kernel
In-Reply-To: <aY253_fOkoQKbi8g@pie>
Hi Yao,
On 11:30 Thu 12 Feb , Yao Zi wrote:
> On Thu, Feb 12, 2026 at 09:38:56AM +0800, Yixun Lan wrote:
> > Add USB2 PHY support for SpacemiT K3 SoC.
> >
> > Register layout of handling USB disconnect operation has been changed,
> > So introducing a platform data to distinguish the different SoCs.
>
> Would it be clearer and simpler if you define separate phy_ops for
> k1 and k3, and point of_device_id.data directly to the corresponding
> phy_ops? Then there's no need to introduce either spacemit_usb2phy_data
> structure, or spacemit_usb2phy_disconnect wrapper.
>
Yes, I agree, thanks for the suggestion
--
Yixun Lan (dlan)
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: phy: spacemit: k3: add USB2 PHY support
From: Krzysztof Kozlowski @ 2026-02-12 12:03 UTC (permalink / raw)
To: Yixun Lan
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Ze Huang, Junzhong Pan, linux-phy, devicetree,
linux-riscv, spacemit, linux-kernel
In-Reply-To: <20260212-11-k3-usb2-phy-v1-1-43578592405d@kernel.org>
On Thu, Feb 12, 2026 at 09:38:54AM +0800, Yixun Lan wrote:
> Introduce a compatible string for the USB2 PHY in SpacemiT K3 SoC. The IP
> of USB2 PHY mostly shares the same functionalities with K1 SoC, while has
> some register layout changes.
>
> Signed-off-by: Yixun Lan <dlan@kernel.org>
> ---
> Documentation/devicetree/bindings/phy/spacemit,usb2-phy.yaml | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
--
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