* Re: [PATCH v2 4/4] arm64: dts: qcom: x1-dell-thena: bump linux,cma to 256 MiB
From: Bjorn Andersson @ 2026-07-11 18:24 UTC (permalink / raw)
To: Bryan O'Donoghue
Cc: Michael Scott, linux-arm-msm, vkoul, neil.armstrong,
dmitry.baryshkov, wesley.cheng, abelvesa, faisal.hassan,
linux-phy, konradybcio, robh, krzk+dt, conor+dt, devicetree, val,
laurentiu.tudor1, alex.vinarskis, linux-kernel
In-Reply-To: <a03fa27c-57ad-48e3-9223-b4d30978ded5@linaro.org>
On Fri, May 22, 2026 at 10:33:45PM +0100, Bryan O'Donoghue wrote:
> On 22/05/2026 18:16, Michael Scott wrote:
> > > └─[$] <git:(0.7.0-multipass-v0*)>
> >
> > Good point about the libcamera version. I debugged this on Ubuntu 26.04
> > (v0.7.0+patches). I tried testing v0.7.1, but it caused a crash due to
> > API changes with other parts of the subsystem. I checked the diff of
> > upstream between v0.7.0 and v0.7.1 for the dma allocator code and I
> > didn't see any changes, but I wasn't looking at the software ISP
> > changes.
> >
> > This highlights that "I'm doing this wrong". I'll move to a cleaner
> > rolling distro where staying current is a lot easier.
> >
> > The GPUISP support looks great!
> >
> > Dropping this patch as I'm not understanding the full allocator story.
> > Sorry for the noise.
>
> The whole make CMA bigger thing is an error I was pushing myself.
>
> CMA is required for some systems like say Hantro on i.MX where - the encoder
> doesn't know how to deal with non PHYS contig memory so when you are passing
> framebuffers around from once hw block to another, you need to make them
> physically contiguous.
>
> Not a problem for us on Qcom hw though. Like Rob said, I'm actually not sure
> why we need a CMA block on Qcom hardware at all.
>
&pcie_smmu { status = "reserved" }; means that typical Makena and Hamoa
machines need CMA. Which should be unrelated...
Regards,
Bjorn
> GPU or WiFi I think but not for Camera anymore anyway.
>
> ---
> bod
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 2/8] arm64: dts: qcom: sm8450: Remove unneeded reserved memory nodes
From: Dmitry Baryshkov @ 2026-07-11 18:04 UTC (permalink / raw)
To: Esteban Urrutia
Cc: Konrad Dybcio, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Brian Masney, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Rob Clark, Will Deacon, Robin Murphy,
Joerg Roedel (AMD), Vinod Koul, Neil Armstrong, linux-arm-msm,
linux-clk, linux-kernel, devicetree, iommu, linux-arm-kernel,
linux-phy
In-Reply-To: <c11f9ddd-8533-426c-8a88-0ed461f6a30e@proton.me>
On Tue, Jul 07, 2026 at 03:19:22AM +0000, Esteban Urrutia wrote:
> On 7/6/26 2:24 PM, Dmitry Baryshkov wrote:
> > Please verify that you can actually access those areas (boot with
> > memtest=1)
>
> Thanks for the suggestion!
>
> I actually did boot an SM8475 based device I'm mainlining (motorola-bronco)
> with this parameter.
> Deleted regions in DT are as follows:
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v5 3/4] phy: qcom-qusb2: Add support for Shikra
From: Dmitry Baryshkov @ 2026-07-11 17:51 UTC (permalink / raw)
To: Krishna Kurapati
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Wesley Cheng, Xiangxu Yin, linux-arm-msm, linux-phy,
devicetree, linux-kernel
In-Reply-To: <20260711-shikra-usbphy-v5-v5-3-229ba3602737@oss.qualcomm.com>
On Sat, Jul 11, 2026 at 10:39:52PM +0530, Krishna Kurapati wrote:
> Add init sequence and phy configuration for Shikra. Since the init
> sequence is same as that of QCS615, reuse the existing init table in
> Shikra.
>
> Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>
> ---
> drivers/phy/qualcomm/phy-qcom-qusb2.c | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v4 4/6] phy: cpcap-usb: add extcon support
From: sashiko-bot @ 2026-07-11 17:14 UTC (permalink / raw)
To: Ivaylo Dimitrov
Cc: olteanv, linux-phy, conor+dt, vkoul, robh, devicetree,
neil.armstrong
In-Reply-To: <20260711164754.185565-5-ivo.g.dimitrov.75@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
New issues:
- [Medium] The ordering of extcon state updates exposes invalid intermediate cable states to userspace.
Pre-existing issues:
- [High] Pre-existing UAF: Delayed work can be re-armed after cancel_delayed_work_sync() during driver removal due to an IRQ thread race.
--
--- Patch [4]: [PATCH v4 4/6] phy: cpcap-usb: add extcon support ---
commit 5fa6aab542d92a2c79fbe5195a861859976507b6
Author: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
phy: cpcap-usb: add extcon support
This commit registers an Extcon device and reports the detected USB cable
state. It exports this state through the Extcon framework so other drivers
can consume it using standard kernel interfaces.
> diff --git a/drivers/phy/motorola/phy-cpcap-usb.c b/drivers/phy/motorola/phy-cpcap-usb.c
> index d4eb8086b6000..8f9bea1d8a212 100644
> --- a/drivers/phy/motorola/phy-cpcap-usb.c
> +++ b/drivers/phy/motorola/phy-cpcap-usb.c
[ ... ]
> @@ -226,6 +239,46 @@ static void cpcap_usb_try_musb_mailbox(struct cpcap_phy_ddata *ddata,
> __func__, error);
> }
>
> +static void cpcap_usb_set_extcon(struct cpcap_phy_ddata *ddata)
> +{
> + int cable;
> +
> + switch (ddata->mode) {
[ ... ]
> + if (cable == ddata->cable)
> + return;
> +
> + if (ddata->cable == EXTCON_CHG_USB_SDP)
> + extcon_set_state_sync(ddata->edev, EXTCON_USB, false);
> + else if (cable == EXTCON_CHG_USB_SDP)
> + extcon_set_state_sync(ddata->edev, EXTCON_USB, true);
> +
> + if (ddata->cable != EXTCON_NONE)
> + extcon_set_state_sync(ddata->edev, ddata->cable, false);
[Severity: Medium]
Could this ordering expose invalid intermediate cable states to userspace?
When transitioning to a new cable state (specifically EXTCON_CHG_USB_SDP),
the new state's associated EXTCON_USB state is enabled before the old
ddata->cable state is cleared.
Because extcon_set_state_sync() immediately notifies consumers and emits a
uevent, consumers might briefly observe overlapping, mutually exclusive
states (such as both DCP and SDP active simultaneously).
Would it be safer to completely clear the old states before asserting any
new states?
> +
> + if (cable != EXTCON_NONE)
> + extcon_set_state_sync(ddata->edev, cable, true);
> +
> + ddata->cable = cable;
> +}
[ ... ]
[Severity: High]
This is a pre-existing issue, but I noticed a potential use-after-free race
involving the delayed work during driver unbind. Does this execution sequence
leave the work queued after removal?
If the IRQ thread checks ddata->active and gets preempted before calling
schedule_delayed_work():
cpcap_phy_irq_thread() {
...
if (atomic_read(&ddata->active))
... <preempted here> ...
cpcap_usb_phy_remove() can concurrently set active to 0 and call
cancel_delayed_work_sync(). Since the work isn't queued yet, the
cancellation completes immediately:
cpcap_usb_phy_remove() {
...
atomic_set(&ddata->active, 0);
cancel_delayed_work_sync(&ddata->detect_work);
...
During devres cleanup, free_irq() waits for the IRQ thread to finish.
The thread then resumes, unconditionally calls schedule_delayed_work(),
and exits:
schedule_delayed_work(&ddata->detect_work, msecs_to_jiffies(1));
}
After free_irq() completes, devres frees ddata. The delayed work will
subsequently execute and access the freed memory.
Could this be prevented by disabling IRQs prior to cancelling the work?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260711164754.185565-1-ivo.g.dimitrov.75@gmail.com?part=4
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: phy: qcom,sc8280xp-qmp-usb3-uni: Add SA8255P USB PHY
From: Krzysztof Kozlowski @ 2026-07-11 17:13 UTC (permalink / raw)
To: Mattijs Korpershoek
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Maxime Ripard, linux-arm-msm, linux-phy, devicetree,
linux-kernel
In-Reply-To: <20260709-phy-qcom-qmp-usb-8255-v2-1-3b6c26a45788@kernel.org>
On Thu, Jul 09, 2026 at 04:52:09PM +0200, Mattijs Korpershoek wrote:
> diff --git a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb3-uni-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb3-uni-phy.yaml
> index 01342823e57f..80b04b7f7584 100644
> --- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb3-uni-phy.yaml
> +++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb3-uni-phy.yaml
> @@ -26,6 +26,7 @@ properties:
> - qcom,msm8996-qmp-usb3-phy
> - qcom,qcs8300-qmp-usb3-uni-phy
> - qcom,qdu1000-qmp-usb3-uni-phy
> + - qcom,sa8255p-qmp-usb3-uni-phy
> - qcom,sa8775p-qmp-usb3-uni-phy
> - qcom,sc8180x-qmp-usb3-uni-phy
> - qcom,sc8280xp-qmp-usb3-uni-phy
> @@ -54,7 +55,13 @@ properties:
> maxItems: 5
>
> power-domains:
> - maxItems: 1
> + minItems: 1
> + maxItems: 2
> +
> + power-domain-names:
> + items:
> + - const: usb_transfer
> + - const: usb_core
usb_ feels redundant, since this is USB phy.
>
> resets:
> maxItems: 2
> @@ -82,14 +89,6 @@ properties:
> required:
> - compatible
> - reg
> - - clocks
> - - clock-names
> - - resets
> - - reset-names
> - - vdda-phy-supply
> - - vdda-pll-supply
> - - "#clock-cells"
> - - clock-output-names
> - "#phy-cells"
Just like in all other saXXXX cases, same review: move to a separate
binding file.
Best regards,
Krzysztof
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH v5 4/4] phy: qcom: qmp-usbc: Add qmp configuration for Shikra
From: Krishna Kurapati @ 2026-07-11 17:09 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Wesley Cheng, Xiangxu Yin
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel,
Krishna Kurapati, Dmitry Baryshkov
In-Reply-To: <20260711-shikra-usbphy-v5-v5-0-229ba3602737@oss.qualcomm.com>
Add init sequence and phy configuration for the Super Speed port on Shikra
SoC. Also since Shikra uses 3 resets, add support for the third reset and
configure Shikra platform data to use 3 resets.
Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
drivers/phy/qualcomm/phy-qcom-qmp-usbc.c | 53 ++++++++++++++++++++++++++++++--
1 file changed, 50 insertions(+), 3 deletions(-)
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-usbc.c b/drivers/phy/qualcomm/phy-qcom-qmp-usbc.c
index ab3055bb5b0c..fa8492b487d7 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp-usbc.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp-usbc.c
@@ -512,10 +512,14 @@ static const char * const usb3phy_reset_l[] = {
"phy_phy", "phy",
};
-static const char * const usb3dpphy_reset_l[] = {
+static const char * const qcs615_usb3dpphy_reset_l[] = {
"phy_phy", "dp_phy",
};
+static const char * const shikra_usb3dpphy_reset_l[] = {
+ "phy_phy", "dp_phy", "phy",
+};
+
static const struct regulator_bulk_data qmp_phy_msm8998_vreg_l[] = {
{ .supply = "vdda-phy", .init_load_uA = 68600 },
{ .supply = "vdda-pll", .init_load_uA = 14200 },
@@ -680,8 +684,48 @@ static const struct qmp_phy_cfg qcs615_usb3dp_phy_cfg = {
.configure_dp_phy = qcs615_qmp_configure_dp_phy,
.calibrate_dp_phy = qcs615_qmp_calibrate_dp_phy,
- .reset_list = usb3dpphy_reset_l,
- .num_resets = ARRAY_SIZE(usb3dpphy_reset_l),
+ .reset_list = qcs615_usb3dpphy_reset_l,
+ .num_resets = ARRAY_SIZE(qcs615_usb3dpphy_reset_l),
+ .vreg_list = qmp_phy_qcs615_vreg_l,
+ .num_vregs = ARRAY_SIZE(qmp_phy_qcs615_vreg_l),
+};
+
+static const struct qmp_phy_cfg shikra_usb3dp_phy_cfg = {
+ .offsets = &qmp_usbc_usb3dp_offsets_qcs615,
+
+ .serdes_tbl = qcm2290_usb3_serdes_tbl,
+ .serdes_tbl_num = ARRAY_SIZE(qcm2290_usb3_serdes_tbl),
+ .tx_tbl = qcm2290_usb3_tx_tbl,
+ .tx_tbl_num = ARRAY_SIZE(qcm2290_usb3_tx_tbl),
+ .rx_tbl = qcm2290_usb3_rx_tbl,
+ .rx_tbl_num = ARRAY_SIZE(qcm2290_usb3_rx_tbl),
+ .pcs_tbl = qcm2290_usb3_pcs_tbl,
+ .pcs_tbl_num = ARRAY_SIZE(qcm2290_usb3_pcs_tbl),
+
+ .regs = qmp_v3_usb3phy_regs_layout_qcm2290,
+
+ .dp_serdes_tbl = qcs615_dp_serdes_tbl,
+ .dp_serdes_tbl_num = ARRAY_SIZE(qcs615_dp_serdes_tbl),
+ .dp_tx_tbl = qcs615_dp_tx_tbl,
+ .dp_tx_tbl_num = ARRAY_SIZE(qcs615_dp_tx_tbl),
+
+ .serdes_tbl_rbr = qcs615_dp_serdes_tbl_rbr,
+ .serdes_tbl_rbr_num = ARRAY_SIZE(qcs615_dp_serdes_tbl_rbr),
+ .serdes_tbl_hbr = qcs615_dp_serdes_tbl_hbr,
+ .serdes_tbl_hbr_num = ARRAY_SIZE(qcs615_dp_serdes_tbl_hbr),
+ .serdes_tbl_hbr2 = qcs615_dp_serdes_tbl_hbr2,
+ .serdes_tbl_hbr2_num = ARRAY_SIZE(qcs615_dp_serdes_tbl_hbr2),
+
+ .swing_tbl = &qcs615_dp_voltage_swing_hbr2_rbr,
+ .pre_emphasis_tbl = &qcs615_dp_pre_emphasis_hbr2_rbr,
+
+ .dp_aux_init = qcs615_qmp_dp_aux_init,
+ .configure_dp_tx = qcs615_qmp_configure_dp_tx,
+ .configure_dp_phy = qcs615_qmp_configure_dp_phy,
+ .calibrate_dp_phy = qcs615_qmp_calibrate_dp_phy,
+
+ .reset_list = shikra_usb3dpphy_reset_l,
+ .num_resets = ARRAY_SIZE(shikra_usb3dpphy_reset_l),
.vreg_list = qmp_phy_qcs615_vreg_l,
.num_vregs = ARRAY_SIZE(qmp_phy_qcs615_vreg_l),
};
@@ -2019,6 +2063,9 @@ static const struct of_device_id qmp_usbc_of_match_table[] = {
}, {
.compatible = "qcom,sdm660-qmp-usb3-phy",
.data = &sdm660_usb3phy_cfg,
+ }, {
+ .compatible = "qcom,shikra-qmp-usb3-dp-phy",
+ .data = &shikra_usb3dp_phy_cfg,
}, {
.compatible = "qcom,sm6115-qmp-usb3-phy",
.data = &qcm2290_usb3phy_cfg,
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v5 3/4] phy: qcom-qusb2: Add support for Shikra
From: Krishna Kurapati @ 2026-07-11 17:09 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Wesley Cheng, Xiangxu Yin
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel,
Krishna Kurapati
In-Reply-To: <20260711-shikra-usbphy-v5-v5-0-229ba3602737@oss.qualcomm.com>
Add init sequence and phy configuration for Shikra. Since the init
sequence is same as that of QCS615, reuse the existing init table in
Shikra.
Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>
---
drivers/phy/qualcomm/phy-qcom-qusb2.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/drivers/phy/qualcomm/phy-qcom-qusb2.c b/drivers/phy/qualcomm/phy-qcom-qusb2.c
index b22b3c6adfd3..101c0820023d 100644
--- a/drivers/phy/qualcomm/phy-qcom-qusb2.c
+++ b/drivers/phy/qualcomm/phy-qcom-qusb2.c
@@ -377,6 +377,17 @@ static const struct qusb2_phy_cfg sdm660_phy_cfg = {
.mask_core_ready = PLL_LOCKED,
};
+static const struct qusb2_phy_cfg shikra_phy_cfg = {
+ .tbl = qcs615_init_tbl,
+ .tbl_num = ARRAY_SIZE(qcs615_init_tbl),
+ .regs = msm8996_regs_layout,
+
+ .has_pll_test = true,
+ .se_clk_scheme_default = true,
+ .disable_ctrl = CLAMP_N_EN | FREEZIO_N | POWER_DOWN,
+ .mask_core_ready = PLL_LOCKED,
+};
+
static const struct qusb2_phy_cfg sm6115_phy_cfg = {
.tbl = sm6115_init_tbl,
.tbl_num = ARRAY_SIZE(sm6115_init_tbl),
@@ -953,6 +964,9 @@ static const struct of_device_id qusb2_phy_of_match_table[] = {
}, {
.compatible = "qcom,sdm660-qusb2-phy",
.data = &sdm660_phy_cfg,
+ }, {
+ .compatible = "qcom,shikra-qusb2-phy",
+ .data = &shikra_phy_cfg,
}, {
.compatible = "qcom,sm4250-qusb2-phy",
.data = &sm6115_phy_cfg,
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v5 2/4] dt-bindings: phy: qcs615-qmp-usb3dp: Add support for Shikra SoC
From: Krishna Kurapati @ 2026-07-11 17:09 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Wesley Cheng, Xiangxu Yin
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel,
Krishna Kurapati
In-Reply-To: <20260711-shikra-usbphy-v5-v5-0-229ba3602737@oss.qualcomm.com>
Declare the USB-C QMP PHY present on the Qualcomm Shikra SoC. Shikra uses
3 resets to be programmed before initialising the phy. As per the hardware
documentation, the third reset is PHY_PRIM_SP0_BCR, hence naming it "phy".
Also, add remote endpoints and orientation switch support for getting
Type-C orientation information.
Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>
---
.../bindings/phy/qcom,qcs615-qmp-usb3dp-phy.yaml | 54 +++++++++++++++++++++-
1 file changed, 53 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/phy/qcom,qcs615-qmp-usb3dp-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,qcs615-qmp-usb3dp-phy.yaml
index efb465c71c1b..908c0f199c01 100644
--- a/Documentation/devicetree/bindings/phy/qcom,qcs615-qmp-usb3dp-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,qcs615-qmp-usb3dp-phy.yaml
@@ -18,6 +18,7 @@ properties:
compatible:
enum:
- qcom,qcs615-qmp-usb3-dp-phy
+ - qcom,shikra-qmp-usb3-dp-phy
reg:
maxItems: 1
@@ -33,12 +34,15 @@ properties:
- const: pipe
resets:
- maxItems: 2
+ minItems: 2
+ maxItems: 3
reset-names:
+ minItems: 2
items:
- const: phy_phy
- const: dp_phy
+ - const: phy
vdda-phy-supply: true
@@ -63,6 +67,22 @@ properties:
- description: offset of the PHY mode register
description: Clamp and PHY mode register present in the TCSR
+ orientation-switch:
+ description:
+ Flag the PHY as possible handler of USB Type-C orientation switching
+ type: boolean
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Output endpoint of the PHY
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Incoming endpoint from the USB controller
+
required:
- compatible
- reg
@@ -78,6 +98,38 @@ required:
additionalProperties: false
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,shikra-qmp-usb3-dp-phy
+ then:
+ properties:
+ resets:
+ minItems: 3
+ reset-names:
+ items:
+ - const: phy_phy
+ - const: dp_phy
+ - const: phy
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,qcs615-qmp-usb3-dp-phy
+ then:
+ properties:
+ resets:
+ maxItems: 2
+ reset-names:
+ items:
+ - const: phy_phy
+ - const: dp_phy
+
examples:
- |
#include <dt-bindings/clock/qcom,qcs615-gcc.h>
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v5 1/4] dt-bindings: phy: qcom,qusb2: Document QUSB2 Phy for Shikra
From: Krishna Kurapati @ 2026-07-11 17:09 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Wesley Cheng, Xiangxu Yin
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel,
Krishna Kurapati, Krzysztof Kozlowski
In-Reply-To: <20260711-shikra-usbphy-v5-v5-0-229ba3602737@oss.qualcomm.com>
Update dt-bindings to add Shikra to QUSB2 Phy list. Shikra SoC
has two High Speed QUSB2 Phys.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>
---
Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml
index 449c2a7e5fec..001fd0ccc985 100644
--- a/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml
@@ -28,6 +28,7 @@ properties:
- qcom,qcm2290-qusb2-phy
- qcom,qcs615-qusb2-phy
- qcom,sdm660-qusb2-phy
+ - qcom,shikra-qusb2-phy
- qcom,sm4250-qusb2-phy
- qcom,sm6115-qusb2-phy
- items:
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v5 0/4] Add USB Phy driver and binding changes for Qualcomm Shikra SoC
From: Krishna Kurapati @ 2026-07-11 17:09 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Wesley Cheng, Xiangxu Yin
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel,
Krishna Kurapati, Krzysztof Kozlowski, Dmitry Baryshkov
This series adds Driver and binding changes for USB Phys on Shikra.
There are two USB controllers - One of them is SS capable and other is
highspeed only capable.
Changes in v5:
- Fixed shikra specific minItems property for qmp bindings
- Rebased qusb2 driver changes on top of Dmitry's change [1]
Link to v4:
https://lore.kernel.org/all/20260701165051.4122259-1-krishna.kurapati@oss.qualcomm.com/
Changes in v4:
- Moved to using qcs615-usb3-dp-phy and added resets specific to shikra
- Updated bindings to reflect that there are 3 resets used in qmp phy
- Add remote endpoints and orientation-switch for Type-c handling
Link to v3:
https://lore.kernel.org/all/20260526184401.3959717-1-pratham.pratap@oss.qualcomm.com/
Changes in v3:
- Moved to using qcs615-usb3-dp-phy since the DP Phy is present although
not operational.
- Using Talos as a fallback for shikra in qmp driver
- Add required "phy" reset in qmp usbc driver since its needed on Shikra
Link to v2:
https://lore.kernel.org/all/20260504170659.282532-1-krishna.kurapati@oss.qualcomm.com/
Changes in v2:
- Separated the usb controller binding changes
- Updated commit texts.
Link to v1:
https://lore.kernel.org/all/20260430-shikra-usb-v1-0-c9c108536fdc@oss.qualcomm.com/
[1]: https://lore.kernel.org/all/20260706-fix-qusb2-v2-0-8d9cd73b1db7@oss.qualcomm.com/
Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>
---
Krishna Kurapati (4):
dt-bindings: phy: qcom,qusb2: Document QUSB2 Phy for Shikra
dt-bindings: phy: qcs615-qmp-usb3dp: Add support for Shikra SoC
phy: qcom-qusb2: Add support for Shikra
phy: qcom: qmp-usbc: Add qmp configuration for Shikra
.../bindings/phy/qcom,qcs615-qmp-usb3dp-phy.yaml | 54 +++++++++++++++++++++-
.../devicetree/bindings/phy/qcom,qusb2-phy.yaml | 1 +
drivers/phy/qualcomm/phy-qcom-qmp-usbc.c | 53 +++++++++++++++++++--
drivers/phy/qualcomm/phy-qcom-qusb2.c | 14 ++++++
4 files changed, 118 insertions(+), 4 deletions(-)
---
base-commit: b7296e82650f0130b8811ef79c5e17aadbf85bd1
change-id: 20260711-shikra-usbphy-v5-f120514ceffd
Best regards,
--
Krishna Kurapati <krishna.kurapati@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 v4 3/6] phy: cpcap-usb: add DCP detection and make UART idle mode optional
From: sashiko-bot @ 2026-07-11 17:06 UTC (permalink / raw)
To: Ivaylo Dimitrov
Cc: robh, conor+dt, devicetree, vkoul, olteanv, neil.armstrong,
linux-phy
In-Reply-To: <20260711164754.185565-4-ivo.g.dimitrov.75@gmail.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
New issues:
- [High] `cpcap_usb_set_idle_mode()` unconditionally sets `CPCAP_BIT_DMPD_SPI` and `CPCAP_BIT_DPPD_SPI`, overriding hardware pulldowns and breaking subsequent charger detection.
- [Medium] The `cpcap_usb_set_dcp_mode` function fails to fully configure the PHY registers, leaving them in a non-deterministic state.
Pre-existing issues:
- [High] A TOCTOU race condition exists between the IRQ handler thread and `cpcap_usb_phy_remove`, leading to a use-after-free of the `ddata` structure.
--
--- Patch [3]: [PATCH v4 3/6] phy: cpcap-usb: add DCP detection and make UART idle mode optional ---
commit ccdf9470fbb5fbd414c5546a329d78f69ecf50b7
Author: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
phy: cpcap-usb: add DCP detection and make UART idle mode optional
Handle DCP separately from USB host connections using CPCAP charger
detection status. Make the existing idle UART mode optional via the
enable_uart module parameter. Also initialize the PHY into the baseline
configuration required for reliable charger detection during probe.
> diff --git a/drivers/phy/motorola/phy-cpcap-usb.c b/drivers/phy/motorola/phy-cpcap-usb.c
> index 7cb020dd3423c..d4eb8086b6000 100644
> --- a/drivers/phy/motorola/phy-cpcap-usb.c
> +++ b/drivers/phy/motorola/phy-cpcap-usb.c
[ ... ]
> @@ -411,43 +446,84 @@ static int cpcap_usb_gpio_set_mode(struct cpcap_phy_ddata *ddata,
[ ... ]
> +static int cpcap_usb_set_idle_mode(struct cpcap_phy_ddata *ddata)
> +{
> + int error;
> + unsigned int val;
> + bool enable_uart = cpcap_enable_uart;
> +
> + error = cpcap_usb_set_safe_mode(ddata);
> + if (error)
> + return error;
> +
> error = regmap_update_bits(ddata->reg, CPCAP_REG_USBC1,
> + CPCAP_BIT_DP150KPU |
> + CPCAP_BIT_DP1K5PU |
> + CPCAP_BIT_DM1K5PU |
> + CPCAP_BIT_DPPD |
> + CPCAP_BIT_DMPD |
> CPCAP_BIT_VBUSPD,
> + CPCAP_BIT_DP150KPU |
> CPCAP_BIT_VBUSPD);
> if (error)
> goto out_err;
>
> - error = regmap_update_bits(ddata->reg, CPCAP_REG_USBC2,
> - 0xffff, CPCAP_BIT_UARTMUX0 |
> - CPCAP_BIT_EMUMODE0);
> + val = CPCAP_BIT_USBSUSPEND;
> +
> + if (enable_uart)
> + val |= (CPCAP_BIT_UARTMUX0 | CPCAP_BIT_EMUMODE0);
> +
> + error = regmap_update_bits(ddata->reg, CPCAP_REG_USBC2, 0xffff, val);
> if (error)
> goto out_err;
>
> - error = regmap_update_bits(ddata->reg, CPCAP_REG_USBC3, 0x7fff,
> - CPCAP_BIT_IDPU_SPI);
> + val = CPCAP_BIT_VBUSSTBY_EN |
> + CPCAP_BIT_VBUSPD_SPI |
> + CPCAP_BIT_DMPD_SPI |
> + CPCAP_BIT_DPPD_SPI |
> + CPCAP_BIT_PU_SPI |
> + CPCAP_BIT_IDPU_SPI |
> + CPCAP_BIT_ULPI_SPI_SEL;
> +
> + if (!enable_uart)
> + val |= CPCAP_BIT_SUSPEND_SPI;
> +
> + error = regmap_update_bits(ddata->reg, CPCAP_REG_USBC3, 0x7fff, val);
[Severity: High]
Does setting CPCAP_BIT_DMPD_SPI and CPCAP_BIT_DPPD_SPI here break charger
detection?
Writing this value to USBC3 unconditionally sets both DMPD_SPI and DPPD_SPI to
1. This overrides the hardware pulldowns and forces them off. The original
code correctly cleared these bits, and as noted in cpcap_usb_init_usb(),
disabling these pulldowns can break subsequent charger detection when the
cable is disconnected.
> if (error)
> goto out_err;
>
[ ... ]
> @@ -508,6 +583,31 @@ static int cpcap_usb_set_usb_mode(struct cpcap_phy_ddata *ddata)
> return error;
> }
>
> +static int cpcap_usb_set_dcp_mode(struct cpcap_phy_ddata *ddata)
> +{
> + int error;
> +
> + error = cpcap_usb_set_safe_mode(ddata);
> + if (error)
> + return error;
> +
> + error = regmap_update_bits(ddata->reg, CPCAP_REG_USBC3,
> + CPCAP_BIT_SUSPEND_SPI, 0);
> + if (error)
> + goto out_err;
[Severity: Medium]
Does cpcap_usb_set_dcp_mode() need to configure USBC1 and USBC2 as well?
Because this only updates USBC3, it seems to inherit whatever state was left
by the previous mode. For example, if transitioning from USB mode, USBXCVREN
in USBC2 might remain set. If transitioning from IDLE mode with
enable_uart=1, UARTMUX0 might remain set, leaving the UART connected to the
data lines during charging.
> +
> + error = cpcap_usb_gpio_set_mode(ddata, CPCAP_DM_DP);
> + if (error)
> + goto out_err;
> +
> + return 0;
> +
> +out_err:
> + dev_err(ddata->dev, "%s failed with %i\n", __func__, error);
> +
> + return error;
> +}
> +
[ ... ]
> @@ -688,17 +849,13 @@ static int cpcap_usb_phy_probe(struct platform_device *pdev)
> static void cpcap_usb_phy_remove(struct platform_device *pdev)
> {
> struct cpcap_phy_ddata *ddata = platform_get_drvdata(pdev);
> - int error;
>
> atomic_set(&ddata->active, 0);
> - error = cpcap_usb_set_uart_mode(ddata);
> - if (error)
> - dev_err(ddata->dev, "could not set UART mode\n");
> -
> + cancel_delayed_work_sync(&ddata->detect_work);
> + cpcap_usb_set_idle_mode(ddata);
> cpcap_usb_try_musb_mailbox(ddata, MUSB_VBUS_OFF);
>
> usb_remove_phy(&ddata->phy);
> - cancel_delayed_work_sync(&ddata->detect_work);
> regulator_disable(ddata->vusb);
> }
[Severity: High]
This is a pre-existing issue, but is there a TOCTOU race condition between
cpcap_phy_irq_thread() and cpcap_usb_phy_remove() that can result in a
use-after-free?
If the IRQ thread reads ddata->active as 1 in cpcap_phy_irq_thread() and gets
preempted:
cpcap_phy_irq_thread() {
if (!atomic_read(&ddata->active))
return IRQ_NONE;
/* preempted here */
And cpcap_usb_phy_remove() completes, setting ddata->active = 0, canceling the
work, and allowing devres to free ddata:
cpcap_usb_phy_remove() {
atomic_set(&ddata->active, 0);
cancel_delayed_work_sync(&ddata->detect_work);
...
}
/* devres frees ddata */
Could the IRQ thread then resume and call schedule_delayed_work() on the freed
ddata?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260711164754.185565-1-ivo.g.dimitrov.75@gmail.com?part=3
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v4 2/6] dt-bindings: phy: motorola,cpcap-usb-phy: add optional safe pinctrl state
From: sashiko-bot @ 2026-07-11 17:00 UTC (permalink / raw)
To: Ivaylo Dimitrov
Cc: conor+dt, linux-phy, vkoul, robh, devicetree, olteanv,
neil.armstrong
In-Reply-To: <20260711164754.185565-3-ivo.g.dimitrov.75@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The commit message claims to document the 'safe' pinctrl state used by the CPCAP USB PHY driver, but the driver itself never references or uses this state.
--
--- Patch [2]: [PATCH v4 2/6] dt-bindings: phy: motorola,cpcap-usb-phy: add optional safe pinctrl state ---
commit a9d2c62cbbf0fb6ec2341d2c0459bff90670c671
Author: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
dt-bindings: phy: motorola,cpcap-usb-phy: add optional safe pinctrl state
This commit adds a new safe pinctrl state to the CPCAP USB PHY device tree
bindings.
> Document the optional "safe" pinctrl state used by the CPCAP USB PHY
> driver.
[Severity: Medium]
Is this commit message accurate regarding the driver actually using this state?
Looking at the driver implementation in
drivers/phy/motorola/phy-cpcap-usb.c:cpcap_usb_init_optional_pins(), it
appears to only request the ulpi, utmi, and uart states:
ddata->pins_ulpi = pinctrl_lookup_state(ddata->pins, "ulpi");
if (IS_ERR(ddata->pins_ulpi))
...
ddata->pins_utmi = pinctrl_lookup_state(ddata->pins, "utmi");
...
ddata->pins_uart = pinctrl_lookup_state(ddata->pins, "uart");
The safe state does not appear to be requested or used anywhere in the driver
code.
Does the driver still need to be updated to support this new state, or could
the commit message be clarified to reflect that this is laying the groundwork
for future driver support?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260711164754.185565-1-ivo.g.dimitrov.75@gmail.com?part=2
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 0/8] SM8450 QoL changes
From: Bjorn Andersson @ 2026-07-11 16:58 UTC (permalink / raw)
To: esteuwu
Cc: Michael Turquette, Stephen Boyd, Brian Masney, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Rob Clark,
Will Deacon, Robin Murphy, Joerg Roedel (AMD), Vinod Koul,
Neil Armstrong, linux-arm-msm, linux-clk, linux-kernel,
devicetree, iommu, linux-arm-kernel, linux-phy
In-Reply-To: <20260622-sm8450-qol-v1-0-37e2ee8df9da@proton.me>
On Mon, Jun 22, 2026 at 08:54:21PM -0400, Esteban Urrutia via B4 Relay wrote:
> Hello. This is my first attempt at contributing to the Linux kernel.
Welcome! A very good first attempt, I hope you will keep doing this!
>
> I've been mainlining an SM8475 based device for quite some time now and
> I feel now's the proper time to start submitting patches.
> I'm starting with the smallest part which are mostly modifications
> regarding the current support for the SM8450 SoC.
>
> Regards,
> Esteban
>
> Signed-off-by: Esteban Urrutia <esteuwu@proton.me>
> ---
> Esteban Urrutia (8):
> clk: qcom: dispcc-sm8450: Fix mdss clocks
> arm64: dts: qcom: sm8450: Remove unneeded reserved memory nodes
> arm64: dts: qcom: sm8450: Modify GPU operating points
> arm64: dts: qcom: sm8450: Add missing PCM_OUT port
> iommu/arm-smmu-qcom: Add SM8450 MDSS compatible
> phy: qcom: qmp-combo: Drop qmp_v4_calibrate_dp_phy
> phy: qcom: qmp-combo: Correct pre-emphasis table for QMP v4 DP PHYs
> arm64: defconfig: Add SM8450 camcc
Sending the patches as a single series implies that there's some sort of
dependency/relationship between them, but as far as I can tell there
isn't.
The changes applies to 4 different maintainers/subsystems. If you group
patches based on their dependencies and who is going to merge them, each
group will be easier to review and merge.
Regards,
Bjorn
>
> arch/arm64/boot/dts/qcom/sm8450.dtsi | 50 ++++++------------------------
> arch/arm64/configs/defconfig | 1 +
> drivers/clk/qcom/dispcc-sm8450.c | 6 ++--
> drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 1 +
> drivers/phy/qualcomm/phy-qcom-qmp-combo.c | 33 +-------------------
> 5 files changed, 16 insertions(+), 75 deletions(-)
> ---
> base-commit: 948efecf22e49aa4bf55bb73ec79a0ddcfd38571
> change-id: 20260622-sm8450-qol-466b8c07eb5f
>
> Best regards,
> --
> Esteban Urrutia <esteuwu@proton.me>
>
>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 00/10] treewide: replace linux/gpio.h
From: Linus Walleij @ 2026-07-11 15:56 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-gpio, Bartosz Golaszewski, Arnd Bergmann, Andrew Lunn,
Sebastian Hesselbarth, Gregory Clement, Frank Li, Robert Jarzmik,
Krzysztof Kozlowski, Greg Ungerer, Thomas Bogendoerfer,
Hauke Mehrtens, Rafał Miłecki, Yoshinori Sato,
John Paul Adrian Glaubitz, Dmitry Torokhov, Dominik Brodowski,
linux-kernel, linux-arm-kernel, linux-samsung-soc, patches,
linux-m68k, linux-mips, linux-sh, linux-input, linux-sunxi,
linux-phy, linux-rockchip, linux-sound
In-Reply-To: <20260710211954.1373336-1-arnd@kernel.org>
On Fri, Jul 10, 2026 at 11:20 PM Arnd Bergmann <arnd@kernel.org> wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> The linux/gpio.h header used to be the global definition for the gpio
> interfaces, with 1100 users back in linux-3.17. In linux-7.2, only about
> 130 of those remain, so this series cleans out the rest.
The series:
Reviewed-by: Linus Walleij <linusw@kernel.org>
Yours,
Linus Walleij
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v3 01/12] dt-bindings: phy: Document MT8195 and MT8196 DisplayPort PHYs
From: Krzysztof Kozlowski @ 2026-07-11 15:41 UTC (permalink / raw)
To: AngeloGioacchino Del Regno
Cc: chunfeng.yun, vkoul, neil.armstrong, robh, krzk+dt, conor+dt,
matthias.bgg, chunkuang.hu, p.zabel, justin.yeh, linux-arm-kernel,
linux-mediatek, linux-phy, devicetree, linux-kernel, dri-devel,
kernel
In-Reply-To: <20260707154245.198361-2-angelogioacchino.delregno@collabora.com>
On Tue, Jul 07, 2026 at 05:42:34PM +0200, AngeloGioacchino Del Regno wrote:
> This adds bindings for the DisplayPort and Embedded DisplayPort
"Add binding"
> PHYs found in the MediaTek MT8195 SoC (and variants of) and for
> the Embedded DisplayPort found in the MT8196 SoC (and variants).
>
> This PHY supports varying impedance calibrations for the various
> signals to reach an optimal EYE signal pattern for any specific
> board(s), especially useful for very high bitrates such as HBR3
> and higher, depending on board design.
>
> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> ---
> .../bindings/phy/mediatek,mt8195-dp-phy.yaml | 77 +++++++++++++++++++
I guess this answers my question about deprecated nvmem which I sent
some minutes ago. I did not see any lore link in that cover letter,
which would be nice in that case.
Anyway,
Reviewed-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
* Re: [PATCH v2 06/10] ASoC: replace linux/gpio.h inclusions
From: Charles Keepax @ 2026-07-11 12:57 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-gpio, Linus Walleij, Bartosz Golaszewski, Arnd Bergmann,
Andrew Lunn, Sebastian Hesselbarth, Gregory Clement, Frank Li,
Robert Jarzmik, Krzysztof Kozlowski, Greg Ungerer,
Thomas Bogendoerfer, Hauke Mehrtens, Rafał Miłecki,
Yoshinori Sato, John Paul Adrian Glaubitz, Dmitry Torokhov,
Dominik Brodowski, linux-kernel, linux-arm-kernel,
linux-samsung-soc, patches, linux-m68k, linux-mips, linux-sh,
linux-input, linux-sunxi, linux-phy, linux-rockchip, linux-sound,
Bartosz Golaszewski
In-Reply-To: <20260710211954.1373336-7-arnd@kernel.org>
On Fri, Jul 10, 2026 at 11:19:51PM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> linux/gpio.h is going away,s o use linux/gpio/consumer.h instead.
>
> Acked-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> sound/soc/codecs/cs42l84.c | 1 -
Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Thanks,
Charles
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 05/10] mfd: replace linux/gpio.h inclusions
From: Charles Keepax @ 2026-07-11 12:56 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-gpio, Linus Walleij, Bartosz Golaszewski, Arnd Bergmann,
Andrew Lunn, Sebastian Hesselbarth, Gregory Clement, Frank Li,
Robert Jarzmik, Krzysztof Kozlowski, Greg Ungerer,
Thomas Bogendoerfer, Hauke Mehrtens, Rafał Miłecki,
Yoshinori Sato, John Paul Adrian Glaubitz, Dmitry Torokhov,
Dominik Brodowski, linux-kernel, linux-arm-kernel,
linux-samsung-soc, patches, linux-m68k, linux-mips, linux-sh,
linux-input, linux-sunxi, linux-phy, linux-rockchip, linux-sound,
Bartosz Golaszewski
In-Reply-To: <20260710211954.1373336-6-arnd@kernel.org>
On Fri, Jul 10, 2026 at 11:19:50PM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> linux/gpio.h should no longer be used, convert these instead to
> either linux/gpio/consumer.h or linux/gpio/legacy.h as needed.
>
> Acked-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> drivers/mfd/arizona-irq.c | 2 +-
> drivers/mfd/wm8994-irq.c | 2 +-
Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Thanks,
Charles
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH] phy: mediatek: xsphy: clear U2 DTM0 force bits during init
From: Nikolai Burov via B4 Relay @ 2026-07-11 10:34 UTC (permalink / raw)
To: Chunfeng Yun, Vinod Koul, Neil Armstrong, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: linux-arm-kernel, linux-mediatek, linux-phy, linux-kernel,
Nikolai Burov, Nikolai Burov
From: Nikolai Burov <nikolai.burov@jolla.com>
On mobile SoCs, the USB PHY is completely powered off during bootup.
As a result, various bits in the DTM0 register are set that prevent
the USB 2.0 PHY from functioning. Clear them as part of the
initialization sequence.
Signed-off-by: Nikolai Burov <nikolai.burov@jolla.com>
---
drivers/phy/mediatek/phy-mtk-xsphy.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/drivers/phy/mediatek/phy-mtk-xsphy.c b/drivers/phy/mediatek/phy-mtk-xsphy.c
index cc1d66954212..b29220bc5592 100644
--- a/drivers/phy/mediatek/phy-mtk-xsphy.c
+++ b/drivers/phy/mediatek/phy-mtk-xsphy.c
@@ -62,6 +62,14 @@
#define P2A6_RG_BC11_SW_EN BIT(23)
#define P2A6_RG_OTG_VBUSCMP_EN BIT(20)
+#define XSP_U2PHYDTM0 ((SSUSB_SIFSLV_U2PHY_COM) + 0x068)
+#define P2D_FORCE_DATAIN BIT(23)
+#define P2D_FORCE_DM_PULLDOWN BIT(21)
+#define P2D_FORCE_DP_PULLDOWN BIT(20)
+#define P2D_FORCE_XCVRSEL BIT(19)
+#define P2D_FORCE_SUSPENDM BIT(18)
+#define P2D_FORCE_TERMSEL BIT(17)
+
#define XSP_U2PHYDTM1 ((SSUSB_SIFSLV_U2PHY_COM) + 0x06C)
#define P2D_FORCE_IDDIG BIT(9)
#define P2D_RG_VBUSVALID BIT(5)
@@ -181,6 +189,11 @@ static void u2_phy_instance_init(struct mtk_xsphy *xsphy,
{
void __iomem *pbase = inst->port_base;
+ mtk_phy_clear_bits(pbase + XSP_U2PHYDTM0,
+ P2D_FORCE_DATAIN | P2D_FORCE_DM_PULLDOWN |
+ P2D_FORCE_DP_PULLDOWN | P2D_FORCE_XCVRSEL |
+ P2D_FORCE_SUSPENDM | P2D_FORCE_TERMSEL);
+
/* DP/DM BC1.1 path Disable */
mtk_phy_clear_bits(pbase + XSP_USBPHYACR6, P2A6_RG_BC11_SW_EN);
---
base-commit: bee763d5f341b99cf472afeb508d4988f62a6ca1
change-id: 20260710-mt6858-xsphy-poweron-ccafba09b4c2
Best regards,
--
Nikolai Burov <nikolai.burov@jolla.com>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* Re: [PATCH v2 06/10] ASoC: replace linux/gpio.h inclusions
From: Sergey Shtylyov @ 2026-07-11 7:34 UTC (permalink / raw)
To: Arnd Bergmann, linux-gpio, Linus Walleij, Bartosz Golaszewski
Cc: Arnd Bergmann, Andrew Lunn, Sebastian Hesselbarth,
Gregory Clement, Frank Li, Robert Jarzmik, Krzysztof Kozlowski,
Greg Ungerer, Thomas Bogendoerfer, Hauke Mehrtens,
Rafał Miłecki, Yoshinori Sato,
John Paul Adrian Glaubitz, Dmitry Torokhov, Dominik Brodowski,
linux-kernel, linux-arm-kernel, linux-samsung-soc, patches,
linux-m68k, linux-mips, linux-sh, linux-input, linux-sunxi,
linux-phy, linux-rockchip, linux-sound, Bartosz Golaszewski
In-Reply-To: <20260710211954.1373336-7-arnd@kernel.org>
On 7/11/26 12:19 AM, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> linux/gpio.h is going away,s o use linux/gpio/consumer.h instead.
s/s o/ so/?
>
> Acked-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>[...]
MBR, Sergey
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 09/10] Input: matrix_keyboard - replace linux/gpio.h inclusion
From: Dmitry Torokhov @ 2026-07-11 4:49 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-gpio, Linus Walleij, Bartosz Golaszewski, Arnd Bergmann,
Andrew Lunn, Sebastian Hesselbarth, Gregory Clement, Frank Li,
Robert Jarzmik, Krzysztof Kozlowski, Greg Ungerer,
Thomas Bogendoerfer, Hauke Mehrtens, Rafał Miłecki,
Yoshinori Sato, John Paul Adrian Glaubitz, Dominik Brodowski,
linux-kernel, linux-arm-kernel, linux-samsung-soc, patches,
linux-m68k, linux-mips, linux-sh, linux-input, linux-sunxi,
linux-phy, linux-rockchip, linux-sound, Bartosz Golaszewski
In-Reply-To: <20260710211954.1373336-10-arnd@kernel.org>
On Fri, Jul 10, 2026 at 11:19:54PM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> linux/gpio.h is going away, so remove that since the driver already
> includes linux/gpio/consumer.h.
>
> Acked-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Adjusted the subject (s/replace/remove) and applied, thank you.
Thanks.
--
Dmitry
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v6 0/4] phy: ti-pipe3: Fix clock resource handling issues
From: Hongling Zeng @ 2026-07-11 1:58 UTC (permalink / raw)
To: vkoul, neil.armstrong, johan, kishon, rogerq; +Cc: Hongling Zeng, linux-phy
In-Reply-To: <1782118512975255.3963.seg@mailgw.kylinos.cn>
Sorry for the noise，Gentle ping.
This series fixes clock/resource leak issues in TI PIPE3 PHY driver.
Could you please review?
Thanks,
Hongling
在 2026年06月19日 11:02, Hongling Zeng 写道:
> This patch series fixes multiple clock resource handling issues in the
> ti-pipe3 PHY driver.
>
> Patch 1 fixes a critical issue where ti_pipe3_init() was ignoring the
> return value of ti_pipe3_enable_clocks(), which could lead to unclocked
> hardware access and unbalanced clock disables.
>
> Patch 2 fixes a clock resource leak when probe fails after enabling
> the SATA refclk. The error path now properly disables the clock and
> cleans up runtime PM resources.
>
> Patch 3 fixes EPROBE_DEFER handling to prevent masking probe deferral
> errors. It uses devm_clk_get_optional() for SATA refclk to properly
> handle optional clocks while still propagating -EPROBE_DEFER and other
> error codes.
>
> Patch 4 fixes a clock leak in the init error path when regmap_update_bits()
> fails in PCIe mode, adding proper clock cleanup consistent with other
> error paths.
>
> These fixes ensure proper resource cleanup on probe and init failures,
> and prevent permanent driver initialization failures due to incorrect
> error handling.
>
> Change in v6:
> - Fix all clock leak paths comprehensively
>
> Changes in v5:
> - Add patch to fix ignored clock enable return value in ti_pipe3_init()
> - Improve error handling consistency across all paths
>
> Changes in v4:
> - Use devm_clk_get_optional() for SATA refclk
> - Drop manual -ENOENT handling
>
> Hongling Zeng (4):
> phy: ti-pipe3: Fix ignored clock enable return value in init
> phy: ti: pipe3: Fix clock resource leak on probe errors
> phy: ti-pipe3: Fix EPROBE_DEFER handling for clock resources
> phy: ti-pipe3: Fix clock leak in init error path
>
> drivers/phy/ti/phy-ti-pipe3.c | 58 ++++++++++++++++++++++++++++--------
> 1 file changed, 46 insertions(+), 12 deletions(-)
>
> --
> 2.25.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v12 32/36] phy: rockchip: usbdp: Drop -EPROBE_DEFER hack
From: sashiko-bot @ 2026-07-10 21:28 UTC (permalink / raw)
To: Sebastian Reichel
Cc: linux-phy, olteanv, devicetree, neil.armstrong, vkoul, robh,
conor+dt
In-Reply-To: <20260710-rockchip-usbdp-cleanup-v12-32-8b41a9a9bef0@collabora.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Removal of -EPROBE_DEFER fallback causes permanent initialization failures due to missing probe-time reset
--
--- Patch [32]: [PATCH v12 32/36] phy: rockchip: usbdp: Drop -EPROBE_DEFER hack ---
commit 98ed05cf436c46697d07d16fcc060eda63439bf7
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
phy: rockchip: usbdp: Drop -EPROBE_DEFER hack
This commit removes the -EPROBE_DEFER fallback for LCPLL lock timeouts in
rk_udphy_status_check(). It states that a reset during the probe routine
now avoids the problem.
> The hack to return -EPROBE_DEFER when the lcpll lock timeouts is no
> longer needed. The driver now does a reset during its probe routine
> marking everything as off and later on does a re-init, which avoids
> the problem.
[Severity: High]
Is this description accurate? Looking at rk_udphy_probe(), it appears the
probe-time reset was removed in a prior patch, meaning the driver does not
actually perform a reset during probe:
drivers/phy/rockchip/phy-rockchip-usbdp.c:rk_udphy_probe() {
...
udphy->dev = dev;
ret = rk_udphy_parse_dt(udphy);
if (ret)
return ret;
mutex_init(&udphy->mutex);
platform_set_drvdata(pdev, udphy);
...
}
> diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c
> index 0333e846ce343..cf173276bfc01 100644
> --- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
> +++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c
> @@ -750,17 +750,7 @@ static int rk_udphy_status_check(struct rk_udphy *udphy)
> (val & CMN_ANA_LCPLL_LOCK_DONE), 200, 100000);
> if (ret) {
> dev_err(udphy->dev, "cmn ana lcpll lock timeout\n");
> - /*
> - * If earlier software (U-Boot) enabled USB once already
> - * the PLL may have problems locking on the first try.
> - * It will be successful on the second try, so for the
> - * time being a -EPROBE_DEFER will solve the issue.
> - *
> - * This requires further investigation to understand the
> - * root cause, especially considering that the driver is
> - * asserting all reset lines at probe time.
> - */
> - return -EPROBE_DEFER;
> + return ret;
> }
[Severity: High]
Does returning the actual error code instead of -EPROBE_DEFER cause a permanent
initialization failure here?
Since the probe routine lacks the hardware reset assertion, if the bootloader
leaves the DWC3 controller running, it can corrupt the PHY state when the PHY
is later reset.
If another consumer like DisplayPort probes first, or DWC3 is not loaded,
phy_power_on() will assert the PHY reset.
Because DWC3 wouldn't have registered its pre-reset notifier to isolate the
PIPE interface, the PHY LCPLL will fail to lock. Without the -EPROBE_DEFER
fallback, this lock timeout becomes a fatal -ETIMEDOUT error and permanently
breaks the driver.
>
> if (!udphy->flip) {
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260710-rockchip-usbdp-cleanup-v12-0-8b41a9a9bef0@collabora.com?part=32
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v12 35/36] phy: rockchip: usbdp: Re-init PHY on mux change
From: sashiko-bot @ 2026-07-10 21:27 UTC (permalink / raw)
To: Sebastian Reichel
Cc: robh, devicetree, olteanv, linux-phy, vkoul, conor+dt,
neil.armstrong
In-Reply-To: <20260710-rockchip-usbdp-cleanup-v12-35-8b41a9a9bef0@collabora.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Uncoordinated PHY reset during Type-C mode change pulls the rug out from under the active DisplayPort controller, leading to lost DP configuration, race conditions with DRM, and potential hardware SErrors.
--
--- Patch [35]: [PATCH v12 35/36] phy: rockchip: usbdp: Re-init PHY on mux change ---
commit 94db902f39e3cb43921400824c3bb5833e6b7bf2
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
phy: rockchip: usbdp: Re-init PHY on mux change
Ensure that the right part of the PHY are powered up when the
mode changes. This ensures the PHY is re-initialized in the
following two scenarios, which are currently broken:
cable orientation changes without DP being involved and
switching from DP-only into a mode with USB support.
> diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c
> index c5ad300620a65..ecf0ed0139f69 100644
> --- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
> +++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c
> @@ -1383,7 +1383,7 @@ static int rk_udphy_typec_mux_set(struct typec_mux_dev *mux,
>
> rk_udphy_set_typec_state(udphy, state->mode);
>
> - return 0;
> + return rk_udphy_update_power_state(udphy);
[Severity: High]
Will this cause an uncoordinated PHY reset that breaks the active DisplayPort
controller?
When rk_udphy_update_power_state() detects a mode change, it calls
rk_udphy_init(), which forcefully resets the PHY and disables the DP lanes:
drivers/phy/rockchip/phy-rockchip-usbdp.c:rk_udphy_init() {
...
/* Step 3: configure lane mux */
regmap_update_bits(udphy->pma_regmap, CMN_LANE_MUX_AND_EN_OFFSET,
CMN_DP_LANE_MUX_ALL | CMN_DP_LANE_EN_ALL,
FIELD_PREP(CMN_DP_LANE_MUX_N(3), udphy->lane_mux_sel[3]) |
...
FIELD_PREP(CMN_DP_LANE_EN_ALL, 0));
...
}
If TCPM synchronously calls rk_udphy_typec_mux_set() during an altmode
renegotiation (such as switching from DP-only to DP+USB), the DP controller
might still be active because DRM handles the associated HPD disconnect
asynchronously on a different workqueue.
Could resetting the PHY while the DP controller is still active and its clock
is stopped trigger an SError or leave the display link permanently broken?
> }
>
> static void rk_udphy_typec_mux_unregister(void *data)
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260710-rockchip-usbdp-cleanup-v12-0-8b41a9a9bef0@collabora.com?part=35
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v12 31/36] phy: rockchip: usbdp: Add phy reset notification support
From: sashiko-bot @ 2026-07-10 21:26 UTC (permalink / raw)
To: Sebastian Reichel
Cc: neil.armstrong, conor+dt, linux-phy, vkoul, olteanv, robh,
devicetree
In-Reply-To: <20260710-rockchip-usbdp-cleanup-v12-31-8b41a9a9bef0@collabora.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Shared `phy_reset_count` across multiple USB3 ports in DWC3 notifier causes stuck `PHYSOFTRST` and unbalanced PM runtime refcounts.
--
--- Patch [31]: [PATCH v12 31/36] phy: rockchip: usbdp: Add phy reset notification support ---
commit a652d5b92503989cfd858925aecf81d1ed290bb7
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
phy: rockchip: usbdp: Add phy reset notification support
This commit adds support for reset notifications to gracefully handle
the PHY being disabled. It is intended to prevent corrupting the
controller's internal state and resolve "cmn ana lcpll lock timeout"
errors after device replugs.
> diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c
> index af915cc377275..0333e846ce343 100644
> --- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
> +++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c
> @@ -1005,24 +1005,39 @@ static int rk_udphy_power_on(struct rk_udphy *udphy, u8 mode)
> }
>
> if (udphy->status == UDPHY_MODE_NONE) {
> + phy_notify_reset(udphy->phy_u3, PHY_NOTIFY_PRE_RESET);
> +
[Severity: High]
Can this cause a port to become permanently stuck in reset due to how the
DWC3 core tracks reset notifications?
Looking at the DWC3 notifier callback in dwc3_usb3_phy_notify(), it uses a
single controller-wide atomic counter (phy_reset_count) rather than tracking
the state on a per-port basis:
drivers/usb/dwc3/core.c:dwc3_usb3_phy_notify() {
...
atomic_inc(&dwc->phy_reset_count);
...
}
If this PHY notification is triggered concurrently across multiple USB3 ports,
could the shared counter lead to unbalanced state? For example, if Port 0
executes PHY_NOTIFY_PRE_RESET while the controller is suspended
(pm_runtime_get_if_active <= 0), it skips the sequence and does not increment
the counter.
If the controller then wakes up and Port 1 concurrently executes
PHY_NOTIFY_PRE_RESET, it increments the shared counter to 1 and asserts
Port 1's reset.
When Port 0 later finishes its PHY setup and executes PHY_NOTIFY_POST_RESET,
it sees the shared counter is 1. Does it incorrectly process the post-reset,
decrementing the counter to 0 and dropping a PM refcount?
If so, when Port 1 finally executes PHY_NOTIFY_POST_RESET, it would see the
shared counter is 0 and abort early, potentially leaving Port 1 permanently
stuck with PHYSOFTRST asserted and unbalanced PM runtime refcounts.
Does the state need to be tracked on a per-port basis in the DWC3 core before
enabling these notifications for multi-port controllers?
> + rk_udphy_u3_port_disable(udphy, true);
> + udelay(10);
> +
> ret = rk_udphy_setup(udphy);
> - if (ret)
> + if (ret) {
> + phy_notify_reset(udphy->phy_u3, PHY_NOTIFY_POST_RESET);
> return ret;
> + }
>
> if (!udphy->hs && udphy->mode & UDPHY_MODE_USB)
> rk_udphy_u3_port_disable(udphy, false);
> udphy->phy_needs_reinit = false;
> +
> + phy_notify_reset(udphy->phy_u3, PHY_NOTIFY_POST_RESET);
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260710-rockchip-usbdp-cleanup-v12-0-8b41a9a9bef0@collabora.com?part=31
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v12 28/36] phy: rockchip: usbdp: Only enable USB3 when not in high-speed mode
From: sashiko-bot @ 2026-07-10 21:26 UTC (permalink / raw)
To: Sebastian Reichel
Cc: robh, conor+dt, linux-phy, vkoul, devicetree, neil.armstrong,
olteanv
In-Reply-To: <20260710-rockchip-usbdp-cleanup-v12-28-8b41a9a9bef0@collabora.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] rk_udphy_power_on returns 0 (success) for unsupported modes, tricking callers into accessing unclocked PHY registers
--
--- Patch [28]: [PATCH v12 28/36] phy: rockchip: usbdp: Only enable USB3 when not in high-speed mode ---
commit fac8dba407b679ba8fc75d417de958451d90f46f
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
phy: rockchip: usbdp: Only enable USB3 when not in high-speed mode
Ensure that USB3 mode is not accidently enabled during PHY re-init
for systems that are configured as high-speed only via DT.
Closes: https://sashiko.dev/#/message/20260626212424.C215E1F000E9%40smtp.kernel.org
> diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c
> index 2099ae2e51d1c..af915cc377275 100644
> --- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
> +++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c
> @@ -1009,7 +1009,7 @@ static int rk_udphy_power_on(struct rk_udphy *udphy, u8 mode)
> if (ret)
> return ret;
>
[Severity: High]
This is a pre-existing issue, but I noticed a potential problem in how
rk_udphy_power_on() handles unsupported modes.
At the beginning of rk_udphy_power_on(), if the hardware isn't configured
for the requested mode, the function logs an info message and returns 0:
if (!(udphy->mode & mode)) {
dev_info(udphy->dev, "mode 0x%02x is not support\n", mode);
return 0;
}
Because it returns success, callers might assume the PHY was successfully
powered up and clocked. For example, if we look at rk_udphy_dp_phy_power_on():
ret = rk_udphy_power_on(udphy, UDPHY_MODE_DP);
if (ret)
return ret;
rk_udphy_dp_lane_enable(udphy, udphy->dp_lanes);
If UDPHY_MODE_DP is requested but not supported (for instance, if the
device tree configures it as USB-only), rk_udphy_power_on() will skip
the setup sequence and return 0.
Would the caller then proceed to access unclocked memory-mapped registers
in rk_udphy_dp_lane_enable() and trigger a kernel panic (SError)?
Should rk_udphy_power_on() return an error code like -EOPNOTSUPP instead
of 0 when an unsupported mode is requested?
> - if (udphy->mode & UDPHY_MODE_USB)
> + if (!udphy->hs && udphy->mode & UDPHY_MODE_USB)
> rk_udphy_u3_port_disable(udphy, false);
> udphy->phy_needs_reinit = false;
> } else if (udphy->phy_needs_reinit) {
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260710-rockchip-usbdp-cleanup-v12-0-8b41a9a9bef0@collabora.com?part=28
--
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