* Re: [PATCH v8 1/2] dt-bindings: phy: qcom: Add CSI2 C-PHY/DPHY schema
From: Bryan O'Donoghue @ 2026-07-01 22:54 UTC (permalink / raw)
To: Vladimir Zapolskiy, Bryan O'Donoghue, Vinod Koul,
Kishon Vijay Abraham I, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Neil Armstrong
Cc: linux-arm-msm, linux-phy, linux-media, devicetree, linux-kernel
In-Reply-To: <dda32577-04e0-4507-acaf-a5694f4f31b3@linaro.org>
On 02/06/2026 22:59, Vladimir Zapolskiy wrote:
>> +
>> + "#phy-cells":
>> + const: 1
>> + description:
>> + The single cell specifies the PHY operating mode.
> #phy-cells should be 0, because the PHY operating mode is well defined
> by 'bus-type' property of an endpoint on the sensor side, the opposite
> side of CAMSS/CSID as a CSIPHY "consumer" should not dictate the PHY type.
So going through the list I don't believe this is correct.
Inserting bus-type into the PHY layer is borrowing from one domain
linux-media and pushing the concept into PHYs.
phy-cells = 1 with CPHY/DPHY specified in the consumer, as was Rob's
suggestion will specify the mode.
Then to understand if we are in regular or combo mode, we parse the
ports/endspoints in the PHY node as we've agreed already.
---
bod
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v4 0/8] phy: rockchip: samsung-hdptx: Clock fixes and API transition cleanups
From: Diederik de Haas @ 2026-07-01 18:50 UTC (permalink / raw)
To: Cristian Ciocaltea, Vinod Koul, Neil Armstrong, Heiko Stuebner,
Algea Cao, Dmitry Baryshkov
Cc: kernel, linux-phy, linux-arm-kernel, linux-rockchip, linux-kernel,
Thomas Niederprüm, Simon Wright, Sashiko
In-Reply-To: <20260612-hdptx-clk-fixes-v4-0-ce5e1d456cda@collabora.com>
Hi Cristian,
On Fri Jun 12, 2026 at 1:46 AM CEST, Cristian Ciocaltea wrote:
> This series provides a set of bug fixes and cleanups for the Rockchip
> Samsung HDPTX PHY driver.
>
> The first part of the series addresses clock rate calculation and
> synchronization issues. Specifically, it fixes edge cases where the PHY
> PLL is pre-programmed by an external component (like a bootloader) or
> when changing the color depth (bpc) while keeping the modeline constant.
> Because the Common Clock Framework .set_rate() callback might not be
> invoked if the pixel clock remains unchanged, this previously led to
> out-of-sync states between CCF and the actual HDMI PHY configuration.
>
> The second part focuses on code cleanups and modernizing the register
> access. Now that dw_hdmi_qp driver has fully switched to using
> phy_configure(), we can drop the deprecated TMDS rate setup workarounds
> and the restrict_rate_change flag logic. Finally, it refactors the
> driver to consistently use standard bitfield macros.
I built a 7.2-rc1 based kernel with this patch set and used that on my
NanoPC-T6 LTS connected to my 4K TV. The kernel also has the HDMI 2.0 patch
set, so I can get 4K@60 with it. When I then tried to switch to 10bpc with
``modetest -M rockchip -w 86:'max bpc':10`` nothing happened.
But that's expected as my TV only supports HDMI 2.0 and not HDMI 2.1.
When I add ``video=HDMI-A-1:1920x1080@60`` to the kernel command line, then it
starts up with 10bpc and I can change to 8bpc and back to 10bpc.
So feel free to add my
Tested-by: Diederik de Haas <diederik@cknow-tech.com> # NanoPC-T6 LTS
Cheers,
Diederik
>
> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
> ---
> Changes in v4:
> - Added new patches to address new findings from Sashiko:
> * Prevent divide-by-zero when computing clk rate
> * Fix rate recalculation for 3.2GHz FRL
> - Updated patch "Consistently use bitfield macros" to handle a few more
> bit operations
> - Link to v3: https://patch.msgid.link/20260611-hdptx-clk-fixes-v3-0-67b1b0c00e16@collabora.com
>
> Changes in v3:
> - Replaced div_u64() with DIV_ROUND_CLOSEST_ULL() in Patch 1 (Sashiko)
> - Fixed theoretical usage_count unbalanced issue in Patch 2 (Sashiko)
> - Rebased series onto latest phy/next
> - Link to v2: https://patch.msgid.link/20260511-hdptx-clk-fixes-v2-0-664e41379cab@collabora.com
>
> Changes in v2:
> - Collected Tested-by tags from Thomas and Simon
> - Fixed a typo in commit description of patch 1
> - Added a comment in patch 2 explaining why PLL config errors are
> ignored for rk_hdptx_phy_consumer_get()
> - Added a missed FIELD_GET conversion for lcpll_hw.pms_sdiv in patch 6
> - Rebased onto latest phy/fixes
> - Link to v1: https://lore.kernel.org/r/20260227-hdptx-clk-fixes-v1-0-f998f2762d0f@collabora.com
>
> ---
> Cristian Ciocaltea (8):
> phy: rockchip: samsung-hdptx: Fix rate recalculation for high bpc
> phy: rockchip: samsung-hdptx: Prevent divide-by-zero when computing clk rate
> phy: rockchip: samsung-hdptx: Fix rate recalculation for 3.2GHz FRL
> phy: rockchip: samsung-hdptx: Handle uncommitted PHY config changes
> phy: rockchip: samsung-hdptx: Drop TMDS rate setup workaround
> phy: rockchip: samsung-hdptx: Drop restrict_rate_change handling
> phy: rockchip: samsung-hdptx: Simplify GRF access with FIELD_PREP_WM16()
> phy: rockchip: samsung-hdptx: Consistently use bitfield macros
>
> drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c | 266 +++++++++++-----------
> 1 file changed, 130 insertions(+), 136 deletions(-)
> ---
> base-commit: 293e19f416fa3f233a2fb013258f7abcb39ad6ed
> change-id: 20260227-hdptx-clk-fixes-47426632f862
>
>
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v4 3/4] phy: qcom-qusb2: Add support for Shikra
From: sashiko-bot @ 2026-07-01 17:01 UTC (permalink / raw)
To: Krishna Kurapati
Cc: olteanv, conor+dt, devicetree, linux-phy, neil.armstrong, robh,
vkoul
In-Reply-To: <20260701165051.4122259-4-krishna.kurapati@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Mismatch between commit message and code regarding the Shikra initialization sequence, indicating a potentially missing SoC-specific init table.
--
commit 32d713dabf7fa1b123bcb3d8f9e6ad4438cd95c4
Author: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>
phy: qcom-qusb2: Add support for Shikra
This commit introduces the PHY configuration and match table entries
necessary to support the Shikra platform in the qcom-qusb2 driver.
> diff --git a/drivers/phy/qualcomm/phy-qcom-qusb2.c b/drivers/phy/qualcomm/phy-qcom-qusb2.c
> --- a/drivers/phy/qualcomm/phy-qcom-qusb2.c
> +++ b/drivers/phy/qualcomm/phy-qcom-qusb2.c
[ ... ]
> @@ -381,6 +381,19 @@ static const struct qusb2_phy_cfg sdm660_phy_cfg = {
> .autoresume_en = BIT(3),
> };
>
> +static const struct qusb2_phy_cfg shikra_phy_cfg = {
> + .tbl = qcs615_init_tbl,
[Severity: Medium]
The commit message states "Add init sequence and phy configuration for
Shikra", but this configuration reuses qcs615_init_tbl.
Since shikra_phy_cfg differs from qcs615 in key hardware parameters like
has_pll_test, se_clk_scheme_default, and autoresume_en, does the Shikra
PHY actually require its own specific tuning table that might have been
accidentally omitted?
If reusing the QCS615 table is intentional, could the commit message be
updated to clarify this reuse instead of stating an init sequence was added?
> + .tbl_num = ARRAY_SIZE(qcs615_init_tbl),
> + .regs = ipq6018_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,
> + .autoresume_en = BIT(3),
> + .update_tune1_with_efuse = false,
> +};
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260701165051.4122259-1-krishna.kurapati@oss.qualcomm.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] dt-bindings: phy: mediatek,tphy: Add support for MT8189 SoC
From: Conor Dooley @ 2026-07-01 16:59 UTC (permalink / raw)
To: Louis-Alexis Eyraud
Cc: Chunfeng Yun, Vinod Koul, Neil Armstrong, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, kernel, linux-arm-kernel,
linux-mediatek, linux-phy, devicetree, linux-kernel
In-Reply-To: <20260701-mt8189-dt-bindings-tphy-v1-1-5848a2be8303@collabora.com>
[-- Attachment #1.1: Type: text/plain, Size: 75 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 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 v4 2/4] dt-bindings: phy: qcs615-qmp-usb3dp: Add support for Shikra SoC
From: sashiko-bot @ 2026-07-01 16:57 UTC (permalink / raw)
To: Krishna Kurapati
Cc: olteanv, neil.armstrong, conor+dt, devicetree, linux-phy, vkoul,
robh
In-Reply-To: <20260701165051.4122259-3-krishna.kurapati@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The YAML schema fails to enforce the mandatory 3 resets for the Shikra SoC, allowing incomplete device tree nodes to pass validation.
--
commit dd87f88551c8d0851ff72a007e5d3d25aa1a3fc0
Author: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>
dt-bindings: phy: qcs615-qmp-usb3dp: Add support for Shikra SoC
Declare the USB-C QMP PHY present on the Qualcomm Shikra SoC. Shikra uses
3 resets to be programmed before initialising the phy. Also, add remote
endpoints and orientation switch support for getting Type-C orientation
information.
> 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 efb465c71c1b5..ae3f0dda3bca2 100644
> --- a/Documentation/devicetree/bindings/phy/qcom,qcs615-qmp-usb3dp-phy.yaml
> +++ b/Documentation/devicetree/bindings/phy/qcom,qcs615-qmp-usb3dp-phy.yaml
[ ... ]
> +allOf:
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - qcom,shikra-qmp-usb3-dp-phy
> + then:
> + properties:
> + resets:
> + maxItems: 3
> + reset-names:
> + items:
> + - const: phy_phy
> + - const: dp_phy
> + - const: phy
[Severity: Medium]
Does this schema accurately enforce the 3 mandatory resets for the Shikra SoC?
The base schema sets minItems to 2 for both resets and reset-names. Because
this conditional block only specifies maxItems: 3 and lists the items without
overriding minItems to 3, the schema will evaluate with minItems: 2 for
Shikra.
Could this allow incomplete device tree nodes missing the required third
reset to silently pass validation during a dt_binding_check run?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260701165051.4122259-1-krishna.kurapati@oss.qualcomm.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] dt-bindings: phy: mediatek,tphy: Add support for MT8189 SoC
From: AngeloGioacchino Del Regno @ 2026-07-01 16:55 UTC (permalink / raw)
To: Louis-Alexis Eyraud, Chunfeng Yun, Vinod Koul, Neil Armstrong,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger
Cc: kernel, linux-arm-kernel, linux-mediatek, linux-phy, devicetree,
linux-kernel
In-Reply-To: <20260701-mt8189-dt-bindings-tphy-v1-1-5848a2be8303@collabora.com>
On 7/1/26 17:36, Louis-Alexis Eyraud wrote:
> Add a compatible string for the MediaTek MT8189 SoC, that integrates a
> MediaTek generic T-PHY version 3.
>
> Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH v4 4/4] phy: qcom: qmp-usbc: Add qmp configuration for Shikra
From: Krishna Kurapati @ 2026-07-01 16:50 UTC (permalink / raw)
To: Neil Armstrong, Vinod Koul, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Xiangxu Yin,
Johan Hovold, Loic Poulain, Shawn Guo, Dmitry Baryshkov,
Abel Vesa, Wesley Cheng
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel,
Krishna Kurapati
In-Reply-To: <20260701165051.4122259-1-krishna.kurapati@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>
---
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 v4 3/4] phy: qcom-qusb2: Add support for Shikra
From: Krishna Kurapati @ 2026-07-01 16:50 UTC (permalink / raw)
To: Neil Armstrong, Vinod Koul, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Xiangxu Yin,
Johan Hovold, Loic Poulain, Shawn Guo, Dmitry Baryshkov,
Abel Vesa, Wesley Cheng
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel,
Krishna Kurapati
In-Reply-To: <20260701165051.4122259-1-krishna.kurapati@oss.qualcomm.com>
Add init sequence and phy configuration for Shikra.
Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>
---
drivers/phy/qualcomm/phy-qcom-qusb2.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/drivers/phy/qualcomm/phy-qcom-qusb2.c b/drivers/phy/qualcomm/phy-qcom-qusb2.c
index eb93015be841..ab7437e7b751 100644
--- a/drivers/phy/qualcomm/phy-qcom-qusb2.c
+++ b/drivers/phy/qualcomm/phy-qcom-qusb2.c
@@ -381,6 +381,19 @@ static const struct qusb2_phy_cfg sdm660_phy_cfg = {
.autoresume_en = BIT(3),
};
+static const struct qusb2_phy_cfg shikra_phy_cfg = {
+ .tbl = qcs615_init_tbl,
+ .tbl_num = ARRAY_SIZE(qcs615_init_tbl),
+ .regs = ipq6018_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,
+ .autoresume_en = BIT(3),
+ .update_tune1_with_efuse = false,
+};
+
static const struct qusb2_phy_cfg sm6115_phy_cfg = {
.tbl = sm6115_init_tbl,
.tbl_num = ARRAY_SIZE(sm6115_init_tbl),
@@ -958,6 +971,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 v4 2/4] dt-bindings: phy: qcs615-qmp-usb3dp: Add support for Shikra SoC
From: Krishna Kurapati @ 2026-07-01 16:50 UTC (permalink / raw)
To: Neil Armstrong, Vinod Koul, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Xiangxu Yin,
Johan Hovold, Loic Poulain, Shawn Guo, Dmitry Baryshkov,
Abel Vesa, Wesley Cheng
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel,
Krishna Kurapati
In-Reply-To: <20260701165051.4122259-1-krishna.kurapati@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>
---
.../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..ae3f0dda3bca 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:
+ maxItems: 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 v4 1/4] dt-bindings: phy: qcom,qusb2: Document QUSB2 Phy for Shikra
From: Krishna Kurapati @ 2026-07-01 16:50 UTC (permalink / raw)
To: Neil Armstrong, Vinod Koul, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Xiangxu Yin,
Johan Hovold, Loic Poulain, Shawn Guo, Dmitry Baryshkov,
Abel Vesa, Wesley Cheng
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel,
Krishna Kurapati, Krzysztof Kozlowski
In-Reply-To: <20260701165051.4122259-1-krishna.kurapati@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 v4 0/4] Add USB Phy driver and binding changes for Qualcomm Shikra SoC
From: Krishna Kurapati @ 2026-07-01 16:50 UTC (permalink / raw)
To: Neil Armstrong, Vinod Koul, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Xiangxu Yin,
Johan Hovold, Loic Poulain, Shawn Guo, Dmitry Baryshkov,
Abel Vesa, Wesley Cheng
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel,
Krishna Kurapati
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 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/
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
.../phy/qcom,qcs615-qmp-usb3dp-phy.yaml | 54 ++++++++++++++++++-
.../bindings/phy/qcom,qusb2-phy.yaml | 1 +
drivers/phy/qualcomm/phy-qcom-qmp-usbc.c | 53 ++++++++++++++++--
drivers/phy/qualcomm/phy-qcom-qusb2.c | 16 ++++++
4 files changed, 120 insertions(+), 4 deletions(-)
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v8 2/2] phy: qcom-mipi-csi2: Add a CSI2 MIPI DPHY driver
From: Bryan O'Donoghue @ 2026-07-01 16:05 UTC (permalink / raw)
To: Nihal Kumar Gupta, Dmitry Baryshkov, Vijay Kumar Tumati
Cc: Vladimir Zapolskiy, Vinod Koul, Kishon Vijay Abraham I,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Bryan O'Donoghue, linux-arm-msm, linux-phy, linux-media,
devicetree, linux-kernel
In-Reply-To: <59331aa7-8430-4754-861c-4ba6a4810ccd@oss.qualcomm.com>
On 05/06/2026 10:31, Nihal Kumar Gupta wrote:
> Could you please fix the driver to map logical lane indices, consistent with the gen2 camss convention.
>
> [1]https://lore.kernel.org/all/20260326-x1e-camss-csi2-phy-dtsi-
> v3-5-1d5a9306116a@linaro.org
I also agree with the principle here. camss since apq8016 has used
data-lanes = <0 1 2 3> so we should stick to this established paradigm.
---
bod
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v8 2/2] phy: qcom-mipi-csi2: Add a CSI2 MIPI DPHY driver
From: Bryan O'Donoghue @ 2026-07-01 15:53 UTC (permalink / raw)
To: Nihal Kumar Gupta, Dmitry Baryshkov, Vijay Kumar Tumati
Cc: Vladimir Zapolskiy, Vinod Koul, Kishon Vijay Abraham I,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Bryan O'Donoghue, linux-arm-msm, linux-phy, linux-media,
devicetree, linux-kernel
In-Reply-To: <59331aa7-8430-4754-861c-4ba6a4810ccd@oss.qualcomm.com>
On 05/06/2026 10:31, Nihal Kumar Gupta wrote:
>> Having clock-names property doesn't mean that all values are valid.
>>
> CSI_COMMON_CTRL5 is a physical lane power-up bitmap:
> - Bits [0,2,4,6] → D-PHY data lanes(LN0, LN2, LN4, LN6)
> - Bits [1,3,5] → C-PHY trio lanes(LN1, LN3, LN5)
> - Bit [7] → D-PHY clock lane(LNCK) dedicated clock enable
>
> In combo mode, only LN6 can be configurable as a clock lane.
This is a really excellent comment and I'm going to copy/paste the text
entirely into the driver as a comment.
ty
---
bod
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH] dt-bindings: phy: mediatek,tphy: Add support for MT8189 SoC
From: Louis-Alexis Eyraud @ 2026-07-01 15:36 UTC (permalink / raw)
To: Chunfeng Yun, Vinod Koul, Neil Armstrong, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: kernel, linux-arm-kernel, linux-mediatek, linux-phy, devicetree,
linux-kernel, Louis-Alexis Eyraud
Add a compatible string for the MediaTek MT8189 SoC, that integrates a
MediaTek generic T-PHY version 3.
Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
---
Documentation/devicetree/bindings/phy/mediatek,tphy.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml b/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml
index ff5c77ef1176..8b240cfd537d 100644
--- a/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml
+++ b/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml
@@ -90,6 +90,7 @@ properties:
- items:
- enum:
- mediatek,mt8188-tphy
+ - mediatek,mt8189-tphy
- mediatek,mt8195-tphy
- const: mediatek,generic-tphy-v3
- const: mediatek,mt2701-u3phy
---
base-commit: ba7c57499e5999aeae8dd4f954eb2600589d80aa
change-id: 20260701-mt8189-dt-bindings-tphy-4b661e3a9e50
Best regards,
--
Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* Re: [PATCH 01/12] dt-bindings: phy: Document MT8195 and MT8196 DisplayPort PHYs
From: Rob Herring (Arm) @ 2026-07-01 14:38 UTC (permalink / raw)
To: AngeloGioacchino Del Regno
Cc: dri-devel, conor+dt, p.zabel, linux-mediatek, vkoul, chunfeng.yun,
linux-phy, matthias.bgg, linux-arm-kernel, kernel, linux-kernel,
neil.armstrong, justin.yeh, krzk+dt, devicetree, chunkuang.hu
In-Reply-To: <20260701122008.19509-2-angelogioacchino.delregno@collabora.com>
On Wed, 01 Jul 2026 14:19:57 +0200, AngeloGioacchino Del Regno wrote:
> This adds bindings for the DisplayPort and Embedded DisplayPort
> 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 +++++++++++++++++++
> 1 file changed, 77 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/phy/mediatek,mt8195-dp-phy.yaml
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/phy/mediatek,mt8195-dp-phy.example.dtb: phy@1c500000 (mediatek,mt8195-dp-phy): reg: [[0, 475004928], [0, 8192]] is too long
from schema $id: http://devicetree.org/schemas/phy/mediatek,mt8195-dp-phy.yaml
doc reference errors (make refcheckdocs):
See https://patchwork.kernel.org/project/devicetree/patch/20260701122008.19509-2-angelogioacchino.delregno@collabora.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v4 net-next 2/2] arm64: dts: ti: Add PLL1 refclk to J784S4 SoC SERDES node
From: sashiko-bot @ 2026-07-01 14:34 UTC (permalink / raw)
To: Gokul Praveen
Cc: robh, devicetree, vkoul, conor+dt, neil.armstrong, linux-phy,
olteanv
In-Reply-To: <20260701142457.81874-3-g-praveen@ti.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] The Cadence Torrent PHY multilink configuration will fail on other K3 platforms (e.g., J721S2) due to a missing pll1_refclk property in identical serdes nodes.
--
commit cad292e544578dc0fc4b900abd68b229a97dc116
Author: Gokul Praveen <g-praveen@ti.com>
arm64: dts: ti: Add PLL1 refclk to J784S4 SoC SERDES node
This commit adds the PLL1 reference clock to the clocks and clock-names
parameters of the SERDES nodes for the J784S4 and J742S2 SoCs. This resolves
an issue where serdes multilink configurations fail without PLL1.
> diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-j742s2-main-common.dtsi b/arch/arm64/boot/dts/ti/k3-j784s4-j742s2-main-common.dtsi
> index c2636e624f18b..e5224bd7f5383 100644
> --- a/arch/arm64/boot/dts/ti/k3-j784s4-j742s2-main-common.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-j784s4-j742s2-main-common.dtsi
> @@ -1149,8 +1149,9 @@ serdes0: serdes@5060000 {
> resets = <&serdes_wiz0 0>;
> reset-names = "torrent_reset";
> clocks = <&serdes_wiz0 TI_WIZ_PLL0_REFCLK>,
> + <&serdes_wiz0 TI_WIZ_PLL1_REFCLK>,
> <&serdes_wiz0 TI_WIZ_PHY_EN_REFCLK>;
> - clock-names = "refclk", "phy_en_refclk";
> + clock-names = "refclk", "pll1_refclk", "phy_en_refclk";
[Severity: High]
This isn't a bug introduced by this patch, but does the same multilink
configuration failure occur on other K3 platforms like J721S2?
Looking at serdes0 in arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi, it lacks
the pll1_refclk property in the clocks array:
clocks = <&serdes_wiz0 TI_WIZ_PLL0_REFCLK>,
<&serdes_wiz0 TI_WIZ_PHY_EN_REFCLK>;
clock-names = "refclk", "phy_en_refclk";
When a multilink configuration is requested on these platforms (e.g., PCIe on
lane 0 and SGMII on lane 1), will the phy-cadence-torrent driver fail to
enable the PLL1 reference clock?
Could this cause essential peripheral initialization to fail when the
PHY is unable to lock PLL1?
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260701142457.81874-1-g-praveen@ti.com?part=2
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH v4 net-next 2/2] arm64: dts: ti: Add PLL1 refclk to J784S4 SoC SERDES node
From: Gokul Praveen @ 2026-07-01 14:24 UTC (permalink / raw)
To: conor+dt, devicetree, krzk+dt, linux-arm-kernel, linux-kernel,
linux-phy, neil.armstrong, nm, robh, sjakhade, kristo, vigneshr,
vkoul, yamonkar, g-praveen
In-Reply-To: <20260701142457.81874-1-g-praveen@ti.com>
Add PLL1 refclk to "clocks" and "clock-names" parameter of SERDES0,
SERDES1,SERDES2 and SERDES4 node as "assigned clocks" parameter has PLL1
and serdes multilink configuration fails without PLL1.
Signed-off-by: Gokul Praveen <g-praveen@ti.com>
---
arch/arm64/boot/dts/ti/k3-j784s4-j742s2-main-common.dtsi | 9 ++++++---
arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi | 3 ++-
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-j742s2-main-common.dtsi b/arch/arm64/boot/dts/ti/k3-j784s4-j742s2-main-common.dtsi
index c2636e624f18..e5224bd7f538 100644
--- a/arch/arm64/boot/dts/ti/k3-j784s4-j742s2-main-common.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j784s4-j742s2-main-common.dtsi
@@ -1149,8 +1149,9 @@ serdes0: serdes@5060000 {
resets = <&serdes_wiz0 0>;
reset-names = "torrent_reset";
clocks = <&serdes_wiz0 TI_WIZ_PLL0_REFCLK>,
+ <&serdes_wiz0 TI_WIZ_PLL1_REFCLK>,
<&serdes_wiz0 TI_WIZ_PHY_EN_REFCLK>;
- clock-names = "refclk", "phy_en_refclk";
+ clock-names = "refclk", "pll1_refclk", "phy_en_refclk";
assigned-clocks = <&serdes_wiz0 TI_WIZ_PLL0_REFCLK>,
<&serdes_wiz0 TI_WIZ_PLL1_REFCLK>,
<&serdes_wiz0 TI_WIZ_REFCLK_DIG>;
@@ -1186,8 +1187,9 @@ serdes1: serdes@5070000 {
resets = <&serdes_wiz1 0>;
reset-names = "torrent_reset";
clocks = <&serdes_wiz1 TI_WIZ_PLL0_REFCLK>,
+ <&serdes_wiz1 TI_WIZ_PLL1_REFCLK>,
<&serdes_wiz1 TI_WIZ_PHY_EN_REFCLK>;
- clock-names = "refclk", "phy_en_refclk";
+ clock-names = "refclk", "pll1_refclk", "phy_en_refclk";
assigned-clocks = <&serdes_wiz1 TI_WIZ_PLL0_REFCLK>,
<&serdes_wiz1 TI_WIZ_PLL1_REFCLK>,
<&serdes_wiz1 TI_WIZ_REFCLK_DIG>;
@@ -1229,8 +1231,9 @@ serdes4: serdes@5050000 {
resets = <&serdes_wiz4 0>;
reset-names = "torrent_reset";
clocks = <&serdes_wiz4 TI_WIZ_PLL0_REFCLK>,
+ <&serdes_wiz4 TI_WIZ_PLL1_REFCLK>,
<&serdes_wiz4 TI_WIZ_PHY_EN_REFCLK>;
- clock-names = "refclk", "phy_en_refclk";
+ clock-names = "refclk", "pll1_refclk", "phy_en_refclk";
assigned-clocks = <&serdes_wiz4 TI_WIZ_PLL0_REFCLK>,
<&serdes_wiz4 TI_WIZ_PLL1_REFCLK>,
<&serdes_wiz4 TI_WIZ_REFCLK_DIG>;
diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi b/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
index 78fcd0c40abc..53109e2fe527 100644
--- a/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
@@ -122,8 +122,9 @@ serdes2: serdes@5020000 {
resets = <&serdes_wiz2 0>;
reset-names = "torrent_reset";
clocks = <&serdes_wiz2 TI_WIZ_PLL0_REFCLK>,
+ <&serdes_wiz2 TI_WIZ_PLL1_REFCLK>,
<&serdes_wiz2 TI_WIZ_PHY_EN_REFCLK>;
- clock-names = "refclk", "phy_en_refclk";
+ clock-names = "refclk", "pll1_refclk", "phy_en_refclk";
assigned-clocks = <&serdes_wiz2 TI_WIZ_PLL0_REFCLK>,
<&serdes_wiz2 TI_WIZ_PLL1_REFCLK>,
<&serdes_wiz2 TI_WIZ_REFCLK_DIG>;
--
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 v4 net-next 1/2] dt-bindings: phy: cadence-torrent: Update property values to support 3 clocks
From: Gokul Praveen @ 2026-07-01 14:24 UTC (permalink / raw)
To: conor+dt, devicetree, krzk+dt, linux-arm-kernel, linux-kernel,
linux-phy, neil.armstrong, nm, robh, sjakhade, kristo, vigneshr,
vkoul, yamonkar, g-praveen
In-Reply-To: <20260701142457.81874-1-g-praveen@ti.com>
Update maxItems value of "clocks" property to 3 as description of
this parameter already indicates 3 clocks(refclk,pll1_refclk(optional)
and phy_en_refclk(optional)).
Update the maxItems and items value of "clock-names" property with multiple
combination of clock-names possible since pll1_refclk and phy_en_refclk are
optional clocks.
Signed-off-by: Gokul Praveen <g-praveen@ti.com>
---
.../bindings/phy/phy-cadence-torrent.yaml | 16 ++++++++++++----
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml b/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml
index 9af39b33646a..96c664d50629 100644
--- a/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml
+++ b/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml
@@ -34,7 +34,7 @@ properties:
clocks:
minItems: 1
- maxItems: 2
+ maxItems: 3
description:
PHY input reference clocks - refclk (for PLL0) & pll1_refclk (for PLL1).
pll1_refclk is optional and used for multi-protocol configurations requiring
@@ -45,9 +45,17 @@ properties:
clock-names:
minItems: 1
- items:
- - const: refclk
- - enum: [ pll1_refclk, phy_en_refclk ]
+ maxItems: 3
+ oneOf:
+ - items:
+ - const: refclk
+ - items:
+ - const: refclk
+ - enum: [ pll1_refclk, phy_en_refclk ]
+ - items:
+ - const: refclk
+ - const: pll1_refclk
+ - const: phy_en_refclk
reg:
minItems: 1
--
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 v4 net-next 0/2] Add multilink SERDES configuration support
From: Gokul Praveen @ 2026-07-01 14:24 UTC (permalink / raw)
To: conor+dt, devicetree, krzk+dt, linux-arm-kernel, linux-kernel,
linux-phy, neil.armstrong, nm, robh, sjakhade, kristo, vigneshr,
vkoul, yamonkar, g-praveen
Add multilink SERDES configuration support for SERDES0,SERDES1
SERDES2 and SERDES4 node on TI J784S4 EVM.
This patch series add multilink SERDES configurations support
for SERDES0,SERDES1 SERDES2 and SERDES4 node on TI J784S4 EVM
by adding the PLL1 refclk.
Gokul Praveen (2):
dt-bindings: phy: cadence-torrent: Update property values to support 3
clocks
arm64: dts: ti: Add PLL1 refclk to J784S4 SoC SERDES node
.../bindings/phy/phy-cadence-torrent.yaml | 16 ++++++++++++----
.../dts/ti/k3-j784s4-j742s2-main-common.dtsi | 9 ++++++---
arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi | 3 ++-
3 files changed, 20 insertions(+), 8 deletions(-)
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 01/12] dt-bindings: phy: Document MT8195 and MT8196 DisplayPort PHYs
From: AngeloGioacchino Del Regno @ 2026-07-01 13:07 UTC (permalink / raw)
To: sashiko-reviews
Cc: neil.armstrong, linux-phy, devicetree, robh, conor+dt, dri-devel,
vkoul, olteanv
In-Reply-To: <20260701122755.D031B1F000E9@smtp.kernel.org>
On 7/1/26 14:27, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Low] The device tree example will fail `make dt_binding_check` validation due to a 64-bit `reg` property at the root level without `#address-cells = <2>` and `#size-cells = <2>`.
That's not "Low", that should be "High" - failing dt_binding_check validation is
critical enough here.
Anyway, will allow some time for reviews before fixing that.
> --
>
> commit c7b476cde050e045aaa56bae9dd7ecc7b3d34ced
> Author: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> dt-bindings: phy: Document MT8195 and MT8196 DisplayPort PHYs
>
> This adds bindings for the DisplayPort and Embedded DisplayPort PHYs found in
> the MediaTek MT8195 and MT8196 SoCs. The PHY supports varying impedance
> calibrations for the signals to reach an optimal EYE signal pattern.
>
>> diff --git a/Documentation/devicetree/bindings/phy/mediatek,mt8195-dp-phy.yaml b/Documentation/devicetree/bindings/phy/mediatek,mt8195-dp-phy.yaml
>> new file mode 100644
>> index 0000000000000..5847963a7085e
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/phy/mediatek,mt8195-dp-phy.yaml
>
> [ ... ]
>
>> +examples:
>> + - |
>> + phy@1c500000 {
>> + compatible = "mediatek,mt8195-dp-phy";
>> + reg = <0 0x1c500000 0 0x2000>;
>
> [Severity: Low]
> Looking at the examples section in mediatek,mt8195-dp-phy.yaml, will this
> example pass make dt_binding_check validation? The reg property contains 4
> cells, but since the example node is at the root level without a parent node
> explicitly defining #address-cells = <2> and #size-cells = <2>, the dummy
> root node defaults to 1 for both. This causes the 4 cells to be parsed as 2
> separate items, which violates the schema's maxItems: 1 constraint.
>
>> + #phy-cells = <0>;
>> + nvmem-cells = <&edp_glb_bias_trim>, <&edp_clktx_impsel>,
>> + <&edp_imp_ln0_pmos>, <&edp_imp_ln0_nmos>,
>> + <&edp_imp_ln1_pmos>, <&edp_imp_ln1_nmos>,
>> + <&edp_imp_ln2_pmos>, <&edp_imp_ln2_nmos>,
>> + <&edp_imp_ln3_pmos>, <&edp_imp_ln3_nmos>;
>> + nvmem-cell-names = "rbias-trim", "impedance-txclk",
>> + "impedance-lane0p", "impedance-lane0n",
>> + "impedance-lane1p", "impedance-lane1n",
>> + "impedance-lane2p", "impedance-lane2n",
>> + "impedance-lane3p", "impedance-lane3n";
>> + };
>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 11/12] phy: phy-mtk-dp: Add PHYD Lane EN register mask to SoC data
From: sashiko-bot @ 2026-07-01 13:07 UTC (permalink / raw)
To: AngeloGioacchino Del Regno
Cc: devicetree, neil.armstrong, olteanv, robh, conor+dt, vkoul,
linux-phy, dri-devel
In-Reply-To: <20260701122008.19509-12-angelogioacchino.delregno@collabora.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] mtk_dp_phy_disable_all_lanes() executes undefined behavior if initially zero, and incorrectly clears lanes by shifting the lane index instead of a bitmask.
--
commit d17ede4ab4b1189e133fc8f8e84c59aaf2d2590e
Author: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
phy: phy-mtk-dp: Add PHYD Lane EN register mask to SoC data
This commit prepares for supporting newer SoCs by moving the PHYD_TX_LN_EN
register mask into the SoC-specific data structure.
> diff --git a/drivers/phy/mediatek/phy-mtk-dp.c b/drivers/phy/mediatek/phy-mtk-dp.c
> index 7c8c04787b78c..f067acef222f7 100644
> --- a/drivers/phy/mediatek/phy-mtk-dp.c
> +++ b/drivers/phy/mediatek/phy-mtk-dp.c
[ ... ]
> @@ -442,7 +446,7 @@ static int mtk_dp_phy_disable_all_lanes(struct mtk_dp_phy *dp_phy)
> return ret;
>
> /* Get mask of currently enabled lane */
> - val = FIELD_GET(PHYD_TX_LN_EN, val);
> + val = field_get(pdata->mask_dig_tx_ln, val);
>
> /* Disable all lanes (needs to be done one by one, from last to first) */
> do {
> @@ -451,7 +455,7 @@ static int mtk_dp_phy_disable_all_lanes(struct mtk_dp_phy *dp_phy)
>
> ret = regmap_clear_bits(dp_phy->regmap,
> pdata->off_dig_glb + regs[DP_PHYD_TX_CTL_0],
> - FIELD_PREP(PHYD_TX_LN_EN, lane_num));
> + field_prep(pdata->mask_dig_tx_ln, lane_num));
[Severity: High]
This is a pre-existing issue, but does this loop safely handle the case
where val is initially 0?
Since this is a do-while loop, if no lanes are currently enabled, fls(0)
will evaluate to 0, which leaves lane_num as -1. This would then result
in an out-of-bounds shift during the BIT(lane_num) calculation.
Additionally, should lane_num be passed into field_prep() as a bitmask
(e.g., BIT(lane_num)) rather than the raw integer index?
Passing the integer index directly (like 2 or 3) instead of a bitmask
appears to generate an incorrect value, which could cause regmap_clear_bits()
to clear the wrong bits in the register and leave lanes incorrectly powered on.
> if (ret)
> return ret;
> } while (val);
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260701122008.19509-1-angelogioacchino.delregno@collabora.com?part=11
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 02/12] phy: phy-mtk-dp: Rename regs to regmap in struct mtk_dp_phy
From: AngeloGioacchino Del Regno @ 2026-07-01 13:05 UTC (permalink / raw)
To: sashiko-reviews
Cc: linux-phy, neil.armstrong, dri-devel, conor+dt, robh, olteanv,
devicetree, vkoul
In-Reply-To: <20260701122658.307E21F000E9@smtp.kernel.org>
On 7/1/26 14:26, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
>
> Pre-existing issues:
> - [High] Missing NULL check for `dev->platform_data` before dereferencing.
> - [High] Missing `remove` callback to clean up PHY lookup leads to a memory leak and use-after-free.
> --
>
> commit a1a96e429cf3345472aae1b06f6ffe5b31edee81
> Author: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
>
> phy: phy-mtk-dp: Rename regs to regmap in struct mtk_dp_phy
>
> In preparation to perform further cleanups and to extend the driver to
> support more SoCs, rename the regs member to regmap to improve readability,
> as this is a common name across many kernel drivers for a struct regmap.
>
>> diff --git a/drivers/phy/mediatek/phy-mtk-dp.c b/drivers/phy/mediatek/phy-mtk-dp.c
>> index d7024a1443358..bf7b3a95e72d2 100644
>> --- a/drivers/phy/mediatek/phy-mtk-dp.c
>> +++ b/drivers/phy/mediatek/phy-mtk-dp.c
> [ ... ]
>> @@ -176,7 +176,7 @@ static int mtk_dp_phy_probe(struct platform_device *pdev)
>
> [Severity: High]
> This is a pre-existing issue, but is it possible for dev->platform_data to be
> NULL here?
>
> Earlier in mtk_dp_phy_probe(), dev->platform_data is dereferenced directly
> without a check:
>
> drivers/phy/mediatek/phy-mtk-dp.c:mtk_dp_phy_probe() {
> ...
> struct regmap *regs;
>
> regs = *(struct regmap **)dev->platform_data;
> if (!regs)
> ...
> }
>
> If the driver is manually bound via sysfs (or otherwise instantiated without
> platform data), dev->platform_data will be NULL.
>
> Should the code validate that dev->platform_data is not NULL before
> dereferencing it to avoid a kernel panic?
>
No, that's not crashing it, because there's a NULL check anyway just after that.
> [Severity: High]
> This isn't a bug introduced by this patch, but does this driver leak the
> phy_lookup struct and leave a dangling pointer if it gets unbound?
>
> In mtk_dp_phy_probe(), when !dev->of_node is true, a lookup entry is
> registered:
>
> drivers/phy/mediatek/phy-mtk-dp.c:mtk_dp_phy_probe() {
> ...
> if (!dev->of_node)
> phy_create_lookup(phy, "dp", dev_name(dev));
>
> return 0;
> }
>
> However, mtk_dp_phy_driver does not have a .remove callback to call
> phy_remove_lookup():
>
> drivers/phy/mediatek/phy-mtk-dp.c:
> static struct platform_driver mtk_dp_phy_driver = {
> .probe = mtk_dp_phy_probe,
> .driver = {
> .name = "mediatek-dp-phy",
> },
> };
>
> If the driver is unbound, the phy_lookup struct is leaked and remains linked
> in the global phys list. Since the phy struct gets freed by the
> device-managed subsystem, subsequent device probes iterating the PHY lookup
> list would trigger a use-after-free.
>
> Could a .remove callback be added to unregister the lookup and prevent this?
>
That's right, but I didn't create this issue. I can fix that in a later commit
just for that, even though this code path is dead when using new style devicetree.
>> if (!dp_phy)
>> return -ENOMEM;
>>
>> - dp_phy->regs = regs;
>> + dp_phy->regmap = regs;
>> phy = devm_phy_create(dev, NULL, &mtk_dp_phy_dev_ops);
>> if (IS_ERR(phy))
>> return dev_err_probe(dev, PTR_ERR(phy),
>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 10/12] phy: phy-mtk-dp: Add bitrate register val definitions to SoC data
From: sashiko-bot @ 2026-07-01 13:02 UTC (permalink / raw)
To: AngeloGioacchino Del Regno
Cc: devicetree, robh, vkoul, conor+dt, linux-phy, olteanv,
neil.armstrong, dri-devel
In-Reply-To: <20260701122008.19509-11-angelogioacchino.delregno@collabora.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] mtk_dp_phy_disable_all_lanes loop executes undefined behavior when val is 0, and incorrectly clears lane bits using the lane index instead of a bitmask.
--
commit 25cdd51bd1ac4d69a49e77d93a6b1374ba46dd3c
Author: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
phy: phy-mtk-dp: Support set_lanes in configure and properly cleanup
Add support for enabling a specifically requested number of lanes in the
configure callback, and disable all lanes in power off and reset
callbacks for proper hardware cleanup.
> diff --git a/drivers/phy/mediatek/phy-mtk-dp.c b/drivers/phy/mediatek/phy-mtk-dp.c
> index 586e727956332..a2cd22b9da066 100644
> --- a/drivers/phy/mediatek/phy-mtk-dp.c
> +++ b/drivers/phy/mediatek/phy-mtk-dp.c
[ ... ]
> @@ -261,6 +267,35 @@ static int mtk_dp_phy_power_on(struct phy *phy)
> return 0;
> }
>
> +static int mtk_dp_phy_disable_all_lanes(struct mtk_dp_phy *dp_phy)
> +{
> + const struct mtk_dp_phy_pdata *pdata = dp_phy->pdata;
> + const u8 *regs = pdata->regs_dig_glb;
> + int ret;
> + u32 val;
> +
> + ret = regmap_read(dp_phy->regmap, pdata->off_dig_glb + regs[DP_PHYD_TX_CTL_0], &val);
> + if (ret)
> + return ret;
> +
> + /* Get mask of currently enabled lane */
> + val = FIELD_GET(PHYD_TX_LN_EN, val);
> +
> + /* Disable all lanes (needs to be done one by one, from last to first) */
> + do {
> + u32 lane_num = fls(val) - 1;
[Severity: High]
If no lanes are currently enabled, val will be 0. Does this cause fls(0) - 1
to underflow, leading to undefined behavior when computing BIT(lane_num)?
> + val &= ~BIT(lane_num);
> +
> + ret = regmap_clear_bits(dp_phy->regmap,
> + pdata->off_dig_glb + regs[DP_PHYD_TX_CTL_0],
> + FIELD_PREP(PHYD_TX_LN_EN, lane_num));
[Severity: High]
Does this incorrectly clear bits using the lane index instead of a bitmask?
For example, if lane 3 is being disabled (lane_num == 3), this passes 3 to
FIELD_PREP instead of BIT(3). This would clear lanes 0 and 1 (3 << 4) while
leaving lane 3 enabled. Should this use BIT(lane_num) instead?
> + if (ret)
> + return ret;
> + } while (val);
> +
> + return 0;
> +}
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260701122008.19509-1-angelogioacchino.delregno@collabora.com?part=10
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 12/12] phy: phy-mtk-dp: Add support for MT8196 eDP PHY
From: sashiko-bot @ 2026-07-01 13:01 UTC (permalink / raw)
To: AngeloGioacchino Del Regno
Cc: vkoul, linux-phy, devicetree, robh, conor+dt, neil.armstrong,
olteanv, dri-devel
In-Reply-To: <20260701122008.19509-13-angelogioacchino.delregno@collabora.com>
Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
New issues:
- [High] The MT8196 layout places DP_PHYD_LAN_DRIVING_FORCE at an offset that is overwritten by a contiguous bulk write to the driving parameters.
Pre-existing issues:
- [High] Lane disabling logic incorrectly clears the wrong register bits, leaving upper lanes powered on and corrupting adjacent lanes.
- [High] Analog register offsets are mistakenly fetched from the digital register array, causing writes to the wrong address.
- [High] Missing shift for analog calibration parameters passed to regmap_update_bits() zeroes out hardware fields.
--
commit 25701726cdcf8525c87349866f69aa298517187f
Author: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Subject: phy: phy-mtk-dp: Add support for MT8196 eDP PHY
The MT8196 SoC features an updated PHY IP compared to the older ones, and
there is one that is specific to Embedded DisplayPort. This patch adds
support for the eDP PHY found in the MediaTek MT8196 SoC and all of its
variants.
> diff --git a/drivers/phy/mediatek/phy-mtk-dp.c b/drivers/phy/mediatek/phy-mtk-dp.c
> index f067acef222f7..998ac34466678 100644
> --- a/drivers/phy/mediatek/phy-mtk-dp.c
> +++ b/drivers/phy/mediatek/phy-mtk-dp.c
[ ... ]
> @@ -178,6 +190,11 @@ static const u8 mt8195_phy_dig_lane_regs[DP_PHYD_LAN_MAX] = {
> [DP_PHYD_LAN_DRIVING_PARAM_0] = 0x2c,
> };
>
> +static const u8 mt8196_phy_dig_lane_regs[DP_PHYD_LAN_MAX] = {
> + [DP_PHYD_LAN_DRIVING_FORCE] = 0x30,
> + [DP_PHYD_LAN_DRIVING_PARAM_0] = 0x2c,
> +};
[Severity: High]
Could this regression corrupt the driving force configuration?
In mtk_dp_phy_set_digital_drv_params(), there is a bulk write of 9 contiguous
32-bit registers starting at DP_PHYD_LAN_DRIVING_PARAM_0:
ret = regmap_bulk_write(dp_phy->regmap,
pdata->off_dig_lane[i] + reg,
pdata->driving_params,
ARRAY_SIZE(pdata->driving_params));
Since the bulk write starts at 0x2c, driving_params[1] will be written to 0x30,
which overlaps with DP_PHYD_LAN_DRIVING_FORCE.
> +
> static const u8 mt8195_phy_dig_glb_regs[DP_PHYD_GLOBAL_MAX] = {
[ ... ]
> @@ -751,8 +784,39 @@ static const struct mtk_dp_phy_pdata mt8195_dp_phy_data = {
> },
> };
>
> +static const struct mtk_dp_phy_pdata mt8196_edp_phy_data = {
> + .off_ana_glb = 0x400,
> + .off_ana_lane = (const u16[]) { 0x0, 0x100, 0x200, 0x300 },
> + .off_dig_glb = 0x1400,
> + .off_dig_lane = (const u16[]) { 0x1000, 0x1100, 0x1200, 0x1300 },
> + .regs_ana_glb = mt8195_phy_ana_glb_regs,
> + .regs_ana_lane = mt8195_phy_ana_lane_regs,
> + .regs_dig_glb = mt8196_phy_dig_glb_regs,
[Severity: High]
This is a pre-existing issue, but do mtk_dp_phy_power_on() and
mtk_dp_phy_power_off() fetch analog register offsets using this digital register
array?
Both functions use the analog enum DP_PHYA_GLB_FORCE_CTRL_1 to access the
digital array:
const u8 *regs = pdata->regs_dig_glb;
...
ret = regmap_set_bits(dp_phy->regmap,
pdata->off_ana_glb + regs[DP_PHYA_GLB_FORCE_CTRL_1],
CKM_CKTX0_EN_FORCE_MODE);
Accessing index 4 (DP_PHYA_GLB_FORCE_CTRL_1) of the digital array returns
DP_PHYD_AUX_RX_CTL (0x40) instead of the intended analog offset (0x34).
Does this overwrite incorrect memory mapped register offsets?
> + .regs_dig_lane = mt8196_phy_dig_lane_regs,
> + .mask_dig_tx_ln = PHYD_TX_LN_EN_V2,
[Severity: High]
This isn't a bug introduced by this patch, but does the lane disabling logic in
mtk_dp_phy_disable_all_lanes() use this mask incorrectly?
It computes lane_num as a raw index and passes it to field_prep():
ret = regmap_clear_bits(dp_phy->regmap,
pdata->off_dig_glb + regs[DP_PHYD_TX_CTL_0],
field_prep(pdata->mask_dig_tx_ln, lane_num));
Because field_prep() shifts the raw value, passing 3 instead of BIT(3) will
shift 0b11 into the mask, clearing bits 4 and 5 instead of bit 7 (or bits 0 and
1 instead of bit 3 for V2).
Should this be using BIT(lane_num) instead?
> + .val_dig_bitrate = mt8196_edp_phy_dig_bitrate_val,
> + .ana_bias_r = 15,
> + .ana_cktx_imp = 8,
[Severity: High]
This isn't a bug introduced by this patch, but are these calibration parameters
unconditionally cleared to zero in the hardware?
In mtk_dp_phy_set_analog_calibration_params(), these values are passed
directly to regmap_update_bits():
ret = regmap_update_bits(dp_phy->regmap,
pdata->off_ana_glb + regs_ana_glb[DP_PHYA_GLB_BIAS_GEN_0],
XTP_GLB_BIAS_INT_R_CTRL, pdata->ana_bias_r);
Because regmap_update_bits() expects a pre-shifted value and applies a mask
(e.g., GENMASK(20, 16)), an unshifted raw value like 15 masked against the upper
bits yields 0.
Should a macro like FIELD_PREP() be used to properly shift these values into
place?
> + .ana_lanes_imp = {
> + .pmos = 8,
> + .nmos = 8,
> + },
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260701122008.19509-1-angelogioacchino.delregno@collabora.com?part=12
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 09/12] phy: phy-mtk-dp: Rewrite and document default driving param macros
From: sashiko-bot @ 2026-07-01 12:50 UTC (permalink / raw)
To: AngeloGioacchino Del Regno
Cc: robh, dri-devel, vkoul, neil.armstrong, conor+dt, linux-phy,
devicetree, olteanv
In-Reply-To: <20260701122008.19509-10-angelogioacchino.delregno@collabora.com>
Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [High] The refactoring introduces incorrect integer values for two DisplayPort PHY driving parameters, silently altering the underlying hardware configuration.
- [High] Integer underflow and undefined behavior in mtk_dp_phy_disable_all_lanes when no lanes are enabled.
- [High] Flawed PM runtime initialization, race condition, and unhandled errors in probe.
- [Medium] Incorrect endianness conversion by pointer aliasing a u16 as a u8*.
--
commit 3ae397642076d659c70475bdbefbc3286e0e7c1f
Author: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Subject: phy: phy-mtk-dp: Rewrite and document default driving param macros
This patch uses FIELD_PREP_CONST and adds definitions and macros to build
the default driving parameters for the PHY. It also adds comments explaining
what they are supposed to set in the PHY.
> diff --git a/drivers/phy/mediatek/phy-mtk-dp.c b/drivers/phy/mediatek/phy-mtk-dp.c
> index d7024a1443358..1d73a622ef322 100644
> --- a/drivers/phy/mediatek/phy-mtk-dp.c
> +++ b/drivers/phy/mediatek/phy-mtk-dp.c
[ ... ]
> +/* MT8195: Logic State Change Point (LC TX C) */
> +#define MT8195_DRIVING_PARAM_3_DEFAULT BUILD_DRIVING_PARAM_0( 16, 20, 24, 32)
> +#define MT8195_DRIVING_PARAM_4_DEFAULT BUILD_DRIVING_PARAM_12(24, 30, 60, 32)
[Severity: High]
Does this unintentionally change the default for SW1_PRE2?
The conversion to macros incorrectly alters the sw1_pre2 value. The
original macro XTP_LN_TX_LCTXC0_SW1_PRE2_DEFAULT was (BIT(18) | BIT(21)),
which evaluates to 36 (0x24) when shifted. This macro now sets it to
60 (0x3c).
> +#define MT8195_DRIVING_PARAM_5_DEFAULT BUILD_DRIVING_PARAM_23(8, 48)
[Severity: High]
Is there a similar issue with the default for SW2_PRE1?
The original value was 40 (0x28), but this is now passing 8 (0x08), which
drops BIT(5). These altered driving parameters can degrade signal integrity
and cause connection instability.
[ ... ]
> +static int mtk_dp_phy_disable_all_lanes(struct mtk_dp_phy *dp_phy)
> +{
> + const struct mtk_dp_phy_pdata *pdata = dp_phy->pdata;
> + const u8 *regs = pdata->regs_dig_glb;
> + int ret;
> + u32 val;
> +
> + ret = regmap_read(dp_phy->regmap, pdata->off_dig_glb + regs[DP_PHYD_TX_CTL_0], &val);
> + if (ret)
> + return ret;
> +
> + /* Get mask of currently enabled lane */
> + val = FIELD_GET(PHYD_TX_LN_EN, val);
> +
> + /* Disable all lanes (needs to be done one by one, from last to first) */
> + do {
> + u32 lane_num = fls(val) - 1;
> + val &= ~BIT(lane_num);
> +
> + ret = regmap_clear_bits(dp_phy->regmap,
> + pdata->off_dig_glb + regs[DP_PHYD_TX_CTL_0],
> + FIELD_PREP(PHYD_TX_LN_EN, lane_num));
> + if (ret)
> + return ret;
> + } while (val);
[Severity: High]
Can this do-while loop execute with val initially at 0?
If the PHY is already fully disabled when this is called, val will be 0.
The loop blindly executes once, fls(0) returns 0, and lane_num underflows
to 0xffffffff.
Using ~BIT(0xffffffff) invokes undefined behavior, and passing 0xffffffff
to FIELD_PREP() extracts unpredictable bits, causing a spurious out-of-bounds
register write when clearing the PHY control registers.
> +
> + return 0;
> +}
[ ... ]
> +static int mtk_dp_phy_get_one_cal_para(struct device *dev, const char *name, u8 max_val)
> +{
> + u16 buf = 0;
> + int ret;
> +
> + /*
> + * All of the calibrations are always max 8 bits long, but some may
> + * be split between two different 8-bits cells: handle this corner
> + * case by retrying reading as u16.
> + */
> + ret = nvmem_cell_read_u8(dev, name, (u8 *)&buf);
[Severity: Medium]
Will this lead to an endianness violation on Big Endian platforms?
Casting a u16 buffer pointer to (u8 *) will cause the single byte to be
written into the most significant byte of buf instead of the least
significant byte on Big Endian architectures.
For instance, reading 0x0F would result in buf holding 0x0F00 (3840), which
would falsely trigger the subsequent if (buf > max_val) validation check.
> + if (ret)
> + ret = nvmem_cell_read_u16(dev, name, &buf);
[ ... ]
> +static int mtk_dp_phy_probe(struct platform_device *pdev)
> +{
[ ... ]
> + phy_set_drvdata(phy, dp_phy);
> +
> + provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
> + if (IS_ERR(provider))
> + return PTR_ERR(provider);
[Severity: High]
Could registering the provider before enabling PM runtime cause a race condition?
Exposing the PHY to consumers here means a consumer could claim the PHY and
attempt to power it on before pm_runtime_enable() is called below. This
would return -EACCES and break the consumer initialization.
> +
> + pm_runtime_enable(dev);
> + pm_runtime_get_sync(dev);
[Severity: High]
Should the return value of pm_runtime_get_sync(dev) be checked?
Ignoring the return value means the probe silently succeeds even if the
hardware cannot be powered.
Additionally, this driver lacks a .remove callback. Since
pm_runtime_get_sync() increases the usage counter without it ever being
released, and pm_runtime_disable() is never called, unloading the module
permanently leaks the PM reference and breaks PM runtime for this device.
> +
> + return 0;
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260701122008.19509-1-angelogioacchino.delregno@collabora.com?part=9
--
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