* Re: [PATCH v3 4/4] phy: qualcomm: qmp-combo: Add support for Hawi SoC
From: Dmitry Baryshkov @ 2026-07-20 22:24 UTC (permalink / raw)
To: sashiko
Cc: Ronak Raheja, robh, krzk+dt, olteanv, devicetree, vkoul, conor+dt,
neil.armstrong, linux-phy, linux-arm-msm
In-Reply-To: <20260508232620.2FD04C2BCB0@smtp.kernel.org>
On Fri, May 08, 2026 at 11:26:19PM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [High] Missing DP PHY function pointers in `hawi_usb3dpphy_cfg` lead to NULL pointer dereferences when the DP PHY is initialized.
> - [High] Valid register offset `0x00` causes the AON toggle hardware reset override to be silently skipped.
Please add DP programming. There should be no NULL dereferences.
> > @@ -3699,9 +3915,9 @@ static int qmp_combo_com_init(struct qmp_combo *qmp, bool force)
> > SW_USB3PHY_RESET_MUX | SW_USB3PHY_RESET);
> >
> > /* override hardware control for reset of qmp phy */
> > - if (pcs_aon && cfg->regs[QPHY_AON_TOGGLE_ENABLE]) {
> > - qphy_clrbits(pcs_aon, cfg->regs[QPHY_AON_TOGGLE_ENABLE], 0x1);
> > - qphy_clrbits(pcs_aon, cfg->regs[QPHY_DP_AON_TOGGLE_ENABLE], 0x1);
> > + if (aon_toggle && cfg->regs[QPHY_AON_TOGGLE_ENABLE]) {
> > + qphy_clrbits(aon_toggle, cfg->regs[QPHY_AON_TOGGLE_ENABLE], 0x1);
> > + qphy_clrbits(aon_toggle, cfg->regs[QPHY_DP_AON_TOGGLE_ENABLE], 0x1);
> > }
>
> Is it possible for the hardware reset override to be silently skipped here?
>
> The V10 register layout maps QPHY_AON_TOGGLE_ENABLE to
> QPHY_V10_COM_AON_USB3_AON_TOGGLE_ENABLE, which is defined as 0x00 in
> phy-qcom-qmp-com-aon-v10.h.
>
> Because 0x00 is a valid register offset but evaluates to false in C, the
> check for cfg->regs[QPHY_AON_TOGGLE_ENABLE] will fail. This would skip the
> qphy_clrbits() calls entirely, bypassing the necessary hardware reset override
> sequence and leaving the PHY in a broken state.
>
> Could we use a different way to check if this register is supported by the
> layout without relying on the truthiness of the offset value?
This deserves a comment.
--
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] phy: HiSilicon: Fix error handling in hi3670_pcie_allclk_ctrl()
From: Akash Sukhavasi @ 2026-07-21 1:47 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Mauro Carvalho Chehab,
Manivannan Sadhasivam
Cc: linux-phy, linux-kernel
In-Reply-To: <20260708-b4-hi3670-v1-1-f9236f3e585c@gmail.com>
On Wed, Jul 08, 2026 at 04:31:00PM -0500, Akash Sukhavasi wrote:
> When hi3670_pcie_pll_ctrl() fails, hi3670_pcie_allclk_ctrl() returns
> -EINVAL directly, skipping the close_clocks cleanup path. This leaves
> the PLL with its power-down bit cleared.
Friendly ping on this one. Patch still applies cleanly on
phy/linux-phy.git next.
--
Thanks,
Akash
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v3 1/5] drm/bridge: Implement generic USB Type-C DP HPD bridge
From: Chaoyi Chen @ 2026-07-21 2:22 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Heikki Krogerus, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Luca Ceresoli,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Sandy Huang, Heiko Stübner, Andy Yan,
Vinod Koul, Nicolas Frattaroli, linux-kernel, dri-devel,
linux-arm-kernel, linux-rockchip, linux-phy
In-Reply-To: <al5fYojQ0kJw2okg@venus>
Hi Sebastian,
On 7/21/2026 1:59 AM, Sebastian Reichel wrote:
> Hi,
>
> On Fri, Jul 17, 2026 at 07:19:29PM +0200, Sebastian Reichel wrote:
>> On Fri, Jul 17, 2026 at 03:23:19PM +0800, Chaoyi Chen wrote:
>>> From: Chaoyi Chen <chaoyi.chen@rock-chips.com>
>>>
>>> The HPD function of Type-C DP is implemented through
>>> drm_connector_oob_hotplug_event(). For embedded DP, it is required
>>> that the DRM connector fwnode corresponds to the Type-C port fwnode.
>>>
>>> To describe the relationship between the DP controller and the Type-C
>>> port device, we usually using drm_bridge to build a bridge chain.
>>>
>>> Now several USB-C controller drivers have already implemented the DP
>>> HPD bridge function provided by aux-hpd-bridge.c, it will build a DP
>>> HPD bridge on USB-C connector port device.
>>>
>>> But this requires the USB-C controller driver to manually register the
>>> HPD bridge. If the driver does not implement this feature, the bridge
>>> will not be create.
>>>
>>> So this patch implements a generic DP HPD bridge based on
>>> aux-hpd-bridge.c. It will monitor Type-C bus events, and when a
>>> Type-C port device containing the DP svid is registered, it will
>>> create an HPD bridge for it without the need for the USB-C controller
>>> driver to implement it.
>>>
>>> Signed-off-by: Chaoyi Chen <chaoyi.chen@rock-chips.com>
>>> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
>>> Reviewed-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
>>> ---
>>
>> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
>> Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com> # ArmSom Sige5
>>
>> I gave this a test together with the RK3588/RK3576 USB-C DP AltMode
>> patches I'm working on. As the fusb302 does a manual registration
>> for the DRM bridge in its probe function, the bridge is registered
>> twice:
>>
>> root@sige5 # cat /sys/kernel/debug/dri/bridges
>> ...
>> bridge[1]: drm_aux_hpd_bridge_funcs
>> refcount: 4
>> type: [10] DP
>> OF: /soc/i2c@2ac50000/typec-portc@22/connector:usb-c-connector
>> ops: [0x4] hpd
>> bridge[2]: drm_aux_hpd_bridge_funcs
>> refcount: 2
>> type: [10] DP
>> OF: /soc/i2c@2ac50000/typec-portc@22/connector:usb-c-connector
>> ops: [0x4] hpd
>> ...
>>
>> Apparently the USB-C DP AltMode keeps working, so this just wastes
>> a few CPU cycles and some memory. So this can land and then we can
>> remove the manual code from the driver as a follow-up step. I also
>> gave that a try and things keep working. I won't send the fusb302
>> patch for now to ensure its not applied before this patch lands.
>
> The above test was done with a kernel having all config options
> built-in (i.e. no modules). Using arm64 defconfig one ends up with
>
> CONFIG_DRM_AUX_HPD_TYPEC_BRIDGE=m
>
> But the resulting 'aux-hpd-typec-dp-bridge' module is not loaded
> automatically resulting in missing bridge registration. Running
> 'modprobe aux-hpd-typec-dp-bridge' manually in the booted system
> does not work either as the TypeC controller has already been
> registered and no new BUS_NOTIFY_ADD_DEVICE is generated.
>
Oh, we indeed didn't consider that such a probe ordering issue exists.
The approach I came up with is to iterate through the &typec_bus after
registering the notifier, to ensure we don't miss any events that
occurred prior:
static int __init drm_aux_hpd_typec_dp_bridge_module_init(void)
{
bus_register_notifier(&typec_bus, &drm_typec_event_nb);
-
+ bus_for_each_dev(&typec_bus, NULL, NULL,
+ check_altmode_dev_and_register_hpd_bridge);
return 0;
}
But I'm not sure if there are potential race conditions involved.
Perhaps @Heikki and others have better ideas? Thanks.
> Greetings,
>
> -- Sebastian
--
Best,
Chaoyi
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH] phy: qualcomm: qmp-combo: update DP PHY PLL programming on Glymur
From: Nabige Aala @ 2026-07-21 5:18 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Wesley Cheng, Abel Vesa,
Dmitry Baryshkov
Cc: linux-arm-msm, linux-phy, linux-kernel, Ritesh Kumar, Mahadevan P,
Nabige Aala
From: Ritesh Kumar <ritesh.kumar@oss.qualcomm.com>
The existing DP PHY PLL and AUX configuration for the Glymur platform
does not fully follow the Hardware Programming Guide requirements for
DP over Type-C, which results in DP link bring-up failures.
Update the DP PHY programming sequence and PLL-related register
settings to align with the latest HPG recommendations. With this
change, DP link training completes successfully on Glymur-based
platforms.
Fixes: d10736db98d2 ("phy: qualcomm: qmp-combo: Add DP offsets and settings for Glymur platforms")
Signed-off-by: Ritesh Kumar <ritesh.kumar@oss.qualcomm.com>
Signed-off-by: Mahadevan P <mahadevan.p@oss.qualcomm.com>
Signed-off-by: Nabige Aala <nabige.aala@oss.qualcomm.com>
---
The existing DP PHY PLL and AUX configuration for the Glymur platform
does not fully follow the Hardware Programming Guide requirements for
DP over Type-C, which results in DP link bring-up failures.
Update the DP PHY programming sequence and PLL-related register
settings to align with the latest HPG recommendations. With this
change, DP link training completes successfully on Glymur-based
platforms.
Changes in v2:
- Use the DP-specific v8 COM status register definitions
(DP_QSERDES_V8_COM_C_READY_STATUS and DP_QSERDES_V8_COM_CMN_STATUS)
instead of adding new N3 USB/DP variants.(Konrad)
- Drop the qmp_v8_combo_configure_dp_mode() implementation and
reuse the common qmp_combo_configure_dp_mode() helper, restoring
orientation-specific DP_PHY_MODE programming (0x4c/0x5c) and addressing
review comments regarding DP_PHY_MODE handling.
- Include phy-qcom-qmp-dp-qserdes-com-v8.h for the DP COM register
definitions.
- Update patch author to Ritesh Kumar.(Konrad)
- Link to v1: https://lore.kernel.org/all/20260419-glymur_dp-v1-1-ad1067a8e8ae@oss.qualcomm.com/
---
drivers/phy/qualcomm/phy-qcom-qmp-combo.c | 190 ++++++++++++++++++++----------
1 file changed, 129 insertions(+), 61 deletions(-)
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-combo.c b/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
index cdcfad2e86b1..c98abae40a32 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
@@ -50,6 +50,7 @@
#include "phy-qcom-qmp-dp-phy-v6.h"
#include "phy-qcom-qmp-dp-phy-v8.h"
+#include "phy-qcom-qmp-dp-qserdes-com-v8.h"
#include "phy-qcom-qmp-usb43-pcs-v8.h"
/* QPHY_V3_DP_COM_RESET_OVRD_CTRL register bits */
@@ -283,8 +284,8 @@ static const unsigned int qmp_v8_n3_usb43dpphy_regs_layout[QPHY_LAYOUT_SIZE] = {
[QPHY_DP_AON_TOGGLE_ENABLE] = QPHY_V8_PCS_AON_DP_AON_TOGGLE_ENABLE,
[QPHY_COM_RESETSM_CNTRL] = QSERDES_V8_COM_RESETSM_CNTRL,
- [QPHY_COM_C_READY_STATUS] = QSERDES_V8_COM_C_READY_STATUS,
- [QPHY_COM_CMN_STATUS] = QSERDES_V8_COM_CMN_STATUS,
+ [QPHY_COM_C_READY_STATUS] = DP_QSERDES_V8_COM_C_READY_STATUS,
+ [QPHY_COM_CMN_STATUS] = DP_QSERDES_V8_COM_CMN_STATUS,
[QPHY_COM_BIAS_EN_CLKBUFLR_EN] = QSERDES_V8_COM_BIAS_EN_CLKBUFLR_EN,
[QPHY_DP_PHY_STATUS] = QSERDES_V8_DP_PHY_STATUS,
@@ -1386,10 +1387,10 @@ static const struct qmp_phy_init_tbl qmp_v6_n4_dp_serdes_tbl[] = {
};
static const struct qmp_phy_init_tbl qmp_v8_dp_serdes_tbl[] = {
- QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_SSC_STEP_SIZE2_MODE0, 0x00),
+ QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_SSC_STEP_SIZE2_MODE0, 0x02),
QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_CP_CTRL_MODE0, 0x06),
- QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_PLL_RCTRL_MODE1, 0x10),
- QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_PLL_CCTRL_MODE1, 0x01),
+ QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_PLL_RCTRL_MODE0, 0x16),
+ QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_PLL_CCTRL_MODE0, 0x36),
QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_CORECLK_DIV_MODE0, 0x0a),
QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_DIV_FRAC_START1_MODE0, 0x00),
QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_INTEGLOOP_GAIN0_MODE0, 0x3f),
@@ -1404,12 +1405,13 @@ static const struct qmp_phy_init_tbl qmp_v8_dp_serdes_tbl[] = {
QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_SYSCLK_BUF_ENABLE, 0x06),
QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_PLL_IVCO, 0x07),
QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_SYSCLK_EN_SEL, 0x3b),
+ QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_RESETSM_CNTRL, 0x20),
QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_LOCK_CMP_EN, 0x00),
QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_VCO_TUNE_CTRL, 0x00),
QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_VCO_TUNE_MAP, 0x00),
QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_CLK_SELECT, 0x30),
QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_CORE_CLK_EN, 0x00),
- QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_CMN_CONFIG_1, 0x56),
+ QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_CMN_CONFIG_1, 0x16),
QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_SVS_MODE_CLK_SEL, 0x15),
QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_CMN_MODE_CONTD1, 0x24),
QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_DCC_CAL_1, 0x40),
@@ -1445,26 +1447,26 @@ static const struct qmp_phy_init_tbl qmp_v6_n4_dp_tx_tbl[] = {
};
static const struct qmp_phy_init_tbl qmp_v8_n3p_dp_tx_tbl[] = {
- QMP_PHY_INIT_CFG(QSERDES_V8_LALB_TRANSMITTER_EN_CTRL, 0x3f),
+ QMP_PHY_INIT_CFG(QSERDES_V8_LALB_TRANSMITTER_EN_CTRL, 0x1a),
QMP_PHY_INIT_CFG(QSERDES_V8_LALB_VMODE_CTRL1, 0x40),
QMP_PHY_INIT_CFG(QSERDES_V8_LALB_ANA_INTERFACE_SELECT1, 0x07),
QMP_PHY_INIT_CFG(QSERDES_V8_LALB_ANA_INTERFACE_SELECT2, 0x18),
QMP_PHY_INIT_CFG(QSERDES_V8_LALB_PCS_INTERFACE_SELECT1, 0x50),
QMP_PHY_INIT_CFG(QSERDES_V8_LALB_LANE_MODE_1, 0x0d),
- QMP_PHY_INIT_CFG(QSERDES_V8_LALB_CLKBUF_ENABLE, 0x07),
- QMP_PHY_INIT_CFG(QSERDES_V8_LALB_RESET_TSYNC_EN_CTRL, 0x0a),
+ QMP_PHY_INIT_CFG(QSERDES_V8_LALB_CLKBUF_ENABLE, 0x87),
+ QMP_PHY_INIT_CFG(QSERDES_V8_LALB_RESET_TSYNC_EN_CTRL, 0x0f),
QMP_PHY_INIT_CFG(QSERDES_V8_LALB_TX_LVL_UPDATE_CTRL, 0x0f),
QMP_PHY_INIT_CFG(QSERDES_V8_LALB_TRAN_DRVR_EMP_EN, 0x5f),
- QMP_PHY_INIT_CFG(QSERDES_V8_LALB_TX0_EMP_POST1_LVL, 0x20),
- QMP_PHY_INIT_CFG(QSERDES_V8_LALB_TX1_EMP_POST1_LVL, 0x20),
+ QMP_PHY_INIT_CFG(QSERDES_V8_LALB_TX0_EMP_POST1_LVL, 0x2b),
+ QMP_PHY_INIT_CFG(QSERDES_V8_LALB_TX1_EMP_POST1_LVL, 0x2b),
QMP_PHY_INIT_CFG(QSERDES_V8_LALB_TX0_PRE1_EMPH, 0x20),
QMP_PHY_INIT_CFG(QSERDES_V8_LALB_TX1_PRE1_EMPH, 0x20),
QMP_PHY_INIT_CFG(QSERDES_V8_LALB_TX0_DRV_LVL, 0x00),
QMP_PHY_INIT_CFG(QSERDES_V8_LALB_TX1_DRV_LVL, 0x00),
- QMP_PHY_INIT_CFG(QSERDES_V8_LALB_HIGHZ_DRVR_EN, 0x30),
+ QMP_PHY_INIT_CFG(QSERDES_V8_LALB_HIGHZ_DRVR_EN, 0x3f),
QMP_PHY_INIT_CFG(QSERDES_V8_LALB_LANE_MODE_2, 0x50),
QMP_PHY_INIT_CFG(QSERDES_V8_LALB_LANE_MODE_3, 0x51),
- QMP_PHY_INIT_CFG(QSERDES_V8_LALB_TX_DCC_ANA_CTRL2, 0x00),
+ QMP_PHY_INIT_CFG(QSERDES_V8_LALB_TX_DCC_ANA_CTRL2, 0x0c),
QMP_PHY_INIT_CFG(QSERDES_V8_LALB_TX0_RESTRIM_CAL_CTRL, 0x20),
QMP_PHY_INIT_CFG(QSERDES_V8_LALB_TX1_RESTRIM_CAL_CTRL, 0x02),
QMP_PHY_INIT_CFG(QSERDES_V8_LALB_TX0_RESTRIM_POST_CAL_OFFSET, 0x10),
@@ -1589,11 +1591,12 @@ static const struct qmp_phy_init_tbl qmp_v6_n4_dp_serdes_tbl_hbr3[] = {
static const struct qmp_phy_init_tbl qmp_v8_dp_serdes_tbl_rbr[] = {
QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_HSCLK_SEL_1, 0x05),
- QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_BIN_VCOCAL_CMP_CODE1_MODE0, 0x7a),
- QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_BIN_VCOCAL_CMP_CODE2_MODE0, 0x02),
+ QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_BIN_VCOCAL_CMP_CODE1_MODE0, 0x8d),
+ QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_BIN_VCOCAL_CMP_CODE2_MODE0, 0x27),
QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_SSC_STEP_SIZE1_MODE0, 0x83),
- QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_LOCK_CMP1_MODE0, 0x37),
- QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_LOCK_CMP2_MODE0, 0x04),
+ QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_SSC_STEP_SIZE2_MODE0, 0x02),
+ QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_LOCK_CMP1_MODE0, 0x1c),
+ QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_LOCK_CMP2_MODE0, 0x02),
QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_DEC_START_MODE0, 0x54),
QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_DIV_FRAC_START2_MODE0, 0x00),
QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_DIV_FRAC_START3_MODE0, 0x06),
@@ -1601,16 +1604,17 @@ static const struct qmp_phy_init_tbl qmp_v8_dp_serdes_tbl_rbr[] = {
QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_VCO_TUNE2_MODE0, 0x00),
QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_BIN_VCOCAL_HSCLK_SEL_1, 0x05),
QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_CMN_MODE_CONTD3, 0x07),
- QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_CLK_FWD_CONFIG_1, 0x30),
- QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_IP_CTRL_AND_DP_SEL, 0xa4),
+ QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_CLK_FWD_CONFIG_1, 0x3f),
+ QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_IP_CTRL_AND_DP_SEL, 0xa7),
};
static const struct qmp_phy_init_tbl qmp_v8_dp_serdes_tbl_hbr[] = {
QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_HSCLK_SEL_1, 0x04),
- QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_BIN_VCOCAL_CMP_CODE1_MODE0, 0x21),
- QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_BIN_VCOCAL_CMP_CODE2_MODE0, 0x04),
+ QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_BIN_VCOCAL_CMP_CODE1_MODE0, 0xf6),
+ QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_BIN_VCOCAL_CMP_CODE2_MODE0, 0x20),
QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_SSC_STEP_SIZE1_MODE0, 0x18),
- QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_LOCK_CMP1_MODE0, 0x07),
+ QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_SSC_STEP_SIZE2_MODE0, 0x02),
+ QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_LOCK_CMP1_MODE0, 0x08),
QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_LOCK_CMP2_MODE0, 0x07),
QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_DEC_START_MODE0, 0x46),
QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_DIV_FRAC_START2_MODE0, 0x00),
@@ -1627,7 +1631,8 @@ static const struct qmp_phy_init_tbl qmp_v8_dp_serdes_tbl_hbr2[] = {
QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_HSCLK_SEL_1, 0x03),
QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_BIN_VCOCAL_CMP_CODE1_MODE0, 0xf6),
QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_BIN_VCOCAL_CMP_CODE2_MODE0, 0x20),
- QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_SSC_STEP_SIZE1_MODE0, 0x0),
+ QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_SSC_STEP_SIZE1_MODE0, 0x18),
+ QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_SSC_STEP_SIZE2_MODE0, 0x02),
QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_PLL_RCTRL_MODE0, 0x16),
QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_PLL_CCTRL_MODE0, 0x36),
QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_LOCK_CMP1_MODE0, 0x10),
@@ -1637,9 +1642,9 @@ static const struct qmp_phy_init_tbl qmp_v8_dp_serdes_tbl_hbr2[] = {
QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_DIV_FRAC_START3_MODE0, 0x05),
QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_VCO_TUNE1_MODE0, 0xae),
QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_VCO_TUNE2_MODE0, 0x02),
- QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_BIN_VCOCAL_HSCLK_SEL_1, 0x00),
- QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_IP_CTRL_AND_DP_SEL, 0xbf),
- QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_BIAS_EN_CLKBUFLR_EN, 0x1c),
+ QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_BIN_VCOCAL_HSCLK_SEL_1, 0x03),
+ QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_IP_CTRL_AND_DP_SEL, 0xab),
+ QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_BIAS_EN_CLKBUFLR_EN, 0x17),
QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_RESETSM_CNTRL, 0x20),
QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_CMN_MODE_CONTD3, 0x03),
QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_CLK_FWD_CONFIG_1, 0x3f),
@@ -1647,8 +1652,8 @@ static const struct qmp_phy_init_tbl qmp_v8_dp_serdes_tbl_hbr2[] = {
static const struct qmp_phy_init_tbl qmp_v8_dp_serdes_tbl_hbr3[] = {
QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_HSCLK_SEL_1, 0x02),
- QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_BIN_VCOCAL_CMP_CODE1_MODE0, 0x63),
- QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_BIN_VCOCAL_CMP_CODE2_MODE0, 0x0c),
+ QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_BIN_VCOCAL_CMP_CODE1_MODE0, 0x14),
+ QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_BIN_VCOCAL_CMP_CODE2_MODE0, 0x25),
QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_SSC_STEP_SIZE1_MODE0, 0x5b),
QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_SSC_STEP_SIZE2_MODE0, 0x02),
QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_CP_CTRL_MODE0, 0x06),
@@ -1656,7 +1661,7 @@ static const struct qmp_phy_init_tbl qmp_v8_dp_serdes_tbl_hbr3[] = {
QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_PLL_CCTRL_MODE0, 0x36),
QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_CORECLK_DIV_MODE0, 0x0a),
- QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_LOCK_CMP1_MODE0, 0x17),
+ QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_LOCK_CMP1_MODE0, 0x18),
QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_LOCK_CMP2_MODE0, 0x15),
QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_DEC_START_MODE0, 0x4f),
QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_DIV_FRAC_START1_MODE0, 0x00),
@@ -1675,19 +1680,19 @@ static const struct qmp_phy_init_tbl qmp_v8_dp_serdes_tbl_hbr3[] = {
QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_SYS_CLK_CTRL, 0x02),
QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_SYSCLK_BUF_ENABLE, 0x06),
QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_PLL_IVCO, 0x07),
- QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_SYSCLK_EN_SEL, 0x04),
+ QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_SYSCLK_EN_SEL, 0x3b),
QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_VCO_TUNE_CTRL, 0x00),
QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_VCO_TUNE_MAP, 0x00),
QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_CLK_SELECT, 0x30),
QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_CORE_CLK_EN, 0x00),
QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_CMN_CONFIG_1, 0x16),
QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_SVS_MODE_CLK_SEL, 0x15),
- QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_CLK_FWD_CONFIG_1, 0x30),
- QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_BIAS_EN_CLKBUFLR_EN, 0x10),
+ QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_CLK_FWD_CONFIG_1, 0x3f),
+ QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_BIAS_EN_CLKBUFLR_EN, 0x17),
QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_CMN_MODE_CONTD3, 0x05),
QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_CMN_MODE_CONTD1, 0x24),
QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_BIN_VCOCAL_HSCLK_SEL_1, 0x02),
- QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_IP_CTRL_AND_DP_SEL, 0x84),
+ QMP_PHY_INIT_CFG(QSERDES_V8_USB43_COM_IP_CTRL_AND_DP_SEL, 0x87),
};
static const struct qmp_phy_init_tbl sc8280xp_usb43dp_serdes_tbl[] = {
@@ -3324,16 +3329,70 @@ static void qmp_v4_dp_aux_init(struct qmp_combo *qmp)
qmp->dp_dp_phy + QSERDES_V4_DP_PHY_AUX_INTERRUPT_MASK);
}
+static int qmp_v8_helper_configure_dp_phy(struct qmp_combo *qmp)
+{
+ const struct qmp_phy_cfg *cfg = qmp->cfg;
+ u32 status;
+ int ret;
+
+ writel(0x0f, qmp->dp_dp_phy + QSERDES_DP_PHY_CFG_1);
+
+ qmp_combo_configure_dp_mode(qmp);
+
+ writel(0x13, qmp->dp_dp_phy + QSERDES_DP_PHY_AUX_CFG1);
+ writel(0xa4, qmp->dp_dp_phy + QSERDES_DP_PHY_AUX_CFG2);
+
+ writel(0x05, qmp->dp_dp_phy + QSERDES_V4_DP_PHY_TX0_TX1_LANE_CTL);
+ writel(0x05, qmp->dp_dp_phy + QSERDES_V4_DP_PHY_TX2_TX3_LANE_CTL);
+
+ ret = qmp->cfg->configure_dp_clocks(qmp);
+ if (ret)
+ return ret;
+
+ writel(0x01, qmp->dp_dp_phy + QSERDES_DP_PHY_CFG);
+ writel(0x05, qmp->dp_dp_phy + QSERDES_DP_PHY_CFG);
+ writel(0x01, qmp->dp_dp_phy + QSERDES_DP_PHY_CFG);
+ writel(0x09, qmp->dp_dp_phy + QSERDES_DP_PHY_CFG);
+
+ writel(0x20, qmp->dp_serdes + cfg->regs[QPHY_COM_RESETSM_CNTRL]);
+
+ if (readl_poll_timeout(qmp->dp_serdes + cfg->regs[QPHY_COM_C_READY_STATUS],
+ status,
+ ((status & BIT(0)) > 0),
+ 500,
+ 10000))
+ return -ETIMEDOUT;
+
+ if (readl_poll_timeout(qmp->dp_serdes + cfg->regs[QPHY_COM_CMN_STATUS],
+ status,
+ ((status & BIT(0)) > 0),
+ 500,
+ 10000))
+ return -ETIMEDOUT;
+
+ if (readl_poll_timeout(qmp->dp_serdes + cfg->regs[QPHY_COM_CMN_STATUS],
+ status,
+ ((status & BIT(1)) > 0),
+ 500,
+ 10000))
+ return -ETIMEDOUT;
+
+ return 0;
+}
+
static void qmp_v8_dp_aux_init(struct qmp_combo *qmp)
{
const struct qmp_phy_cfg *cfg = qmp->cfg;
- writel(DP_PHY_PD_CTL_PWRDN | DP_PHY_PD_CTL_PSR_PWRDN | DP_PHY_PD_CTL_AUX_PWRDN |
- DP_PHY_PD_CTL_PLL_PWRDN | DP_PHY_PD_CTL_DP_CLAMP_EN,
- qmp->dp_dp_phy + QSERDES_DP_PHY_PD_CTL);
+ writel(0x3f, qmp->dp_serdes + QSERDES_V8_USB43_COM_CLK_FWD_CONFIG_1);
+
+ writel(DP_PHY_PD_CTL_PWRDN | DP_PHY_PD_CTL_AUX_PWRDN |
+ DP_PHY_PD_CTL_LANE_0_1_PWRDN | DP_PHY_PD_CTL_LANE_2_3_PWRDN |
+ DP_PHY_PD_CTL_PLL_PWRDN | DP_PHY_PD_CTL_DP_CLAMP_EN,
+ qmp->dp_dp_phy + QSERDES_DP_PHY_PD_CTL);
/* Turn on BIAS current for PHY/PLL */
- writel(0x1c, qmp->dp_serdes + cfg->regs[QPHY_COM_BIAS_EN_CLKBUFLR_EN]);
+ writel(0x17, qmp->dp_serdes + cfg->regs[QPHY_COM_BIAS_EN_CLKBUFLR_EN]);
writel(0x00, qmp->dp_dp_phy + QSERDES_DP_PHY_AUX_CFG0);
writel(0x13, qmp->dp_dp_phy + QSERDES_DP_PHY_AUX_CFG1);
@@ -3361,8 +3420,8 @@ static void qmp_v4_configure_dp_tx(struct qmp_combo *qmp)
writel(0x27, qmp->dp_tx + cfg->regs[QPHY_TX_TX_DRV_LVL]);
writel(0x27, qmp->dp_tx2 + cfg->regs[QPHY_TX_TX_DRV_LVL]);
- writel(0x20, qmp->dp_tx + cfg->regs[QPHY_TX_TX_EMP_POST1_LVL]);
- writel(0x20, qmp->dp_tx2 + cfg->regs[QPHY_TX_TX_EMP_POST1_LVL]);
+ writel(0x2b, qmp->dp_tx + cfg->regs[QPHY_TX_TX_EMP_POST1_LVL]);
+ writel(0x2b, qmp->dp_tx2 + cfg->regs[QPHY_TX_TX_EMP_POST1_LVL]);
qmp_combo_configure_dp_swing(qmp);
}
@@ -3370,48 +3429,41 @@ static void qmp_v4_configure_dp_tx(struct qmp_combo *qmp)
static int qmp_v8_configure_dp_clocks(struct qmp_combo *qmp)
{
const struct phy_configure_opts_dp *dp_opts = &qmp->dp_opts;
- u32 phy_vco_div;
unsigned long pixel_freq;
- const struct qmp_phy_cfg *cfg = qmp->cfg;
switch (dp_opts->link_rate) {
case 1620:
- phy_vco_div = 0x4;
pixel_freq = 1620000000UL / 2;
break;
case 2700:
- phy_vco_div = 0x2;
pixel_freq = 2700000000UL / 2;
break;
case 5400:
- phy_vco_div = 0x4;
pixel_freq = 5400000000UL / 4;
break;
case 8100:
- phy_vco_div = 0x3;
pixel_freq = 8100000000UL / 6;
break;
default:
/* Other link rates aren't supported */
return -EINVAL;
}
- writel(phy_vco_div, qmp->dp_dp_phy + cfg->regs[QPHY_DP_PHY_VCO_DIV]);
/* disable core reset tsync */
writel(0x09, qmp->dp_dp_phy + QSERDES_DP_PHY_CFG);
- writel(0x04, qmp->dp_dp_phy + QSERDES_V8_DP_PHY_AUXLESS_SETUP_CYC);
- writel(0x08, qmp->dp_dp_phy + QSERDES_V8_DP_PHY_AUXLESS_SILENCE_CYC);
+ writel(0x09, qmp->dp_dp_phy + QSERDES_V8_DP_PHY_AUXLESS_SETUP_CYC);
+ writel(0x11, qmp->dp_dp_phy + QSERDES_V8_DP_PHY_AUXLESS_SILENCE_CYC);
writel(0x08, qmp->dp_dp_phy + QSERDES_V8_DP_PHY_LFPS_CYC);
- writel(0x11, qmp->dp_dp_phy + QSERDES_V8_DP_PHY_LFPS_PERIOD);
+ writel(0x33, qmp->dp_dp_phy + QSERDES_V8_DP_PHY_LFPS_PERIOD);
writel(0x3e, qmp->dp_dp_phy + QSERDES_V8_DP_PHY_TSYNC_OVRD);
writel(0x05, qmp->dp_dp_phy + QSERDES_V8_DP_PHY_TX2_TX3_LANE_CTL);
writel(0x05, qmp->dp_dp_phy + QSERDES_V8_DP_PHY_TX0_TX1_LANE_CTL);
writel(0x01, qmp->dp_dp_phy + QSERDES_V8_DP_PHY_AUXLESS_CFG1);
- writel(0x11, qmp->dp_dp_phy + QSERDES_V8_DP_PHY_LFPS_PERIOD);
+ writel(0x33, qmp->dp_dp_phy + QSERDES_V8_DP_PHY_LFPS_PERIOD);
writel(0x1f, qmp->dp_dp_phy + QSERDES_V8_DP_PHY_LN0_DRV_LVL);
- writel(0x1f, qmp->dp_dp_phy + QSERDES_V8_DP_PHY_LN1_DRV_LVL);
+ writel(0x02, qmp->dp_dp_phy + QSERDES_V8_DP_PHY_LN1_DRV_LVL);
clk_set_rate(qmp->dp_link_hw.clk, dp_opts->link_rate * 100000);
clk_set_rate(qmp->dp_pixel_hw.clk, pixel_freq);
@@ -3558,7 +3610,7 @@ static int qmp_v8_configure_dp_phy(struct qmp_combo *qmp)
u32 status;
int ret;
- ret = qmp_v456_configure_dp_phy(qmp);
+ ret = qmp_v8_helper_configure_dp_phy(qmp);
if (ret < 0)
return ret;
@@ -3570,13 +3622,13 @@ static int qmp_v8_configure_dp_phy(struct qmp_combo *qmp)
} else if (dp_opts->lanes == 2) {
bias0_en = reverse ? 0x3f : 0x15;
bias1_en = reverse ? 0x15 : 0x3f;
- drvr0_en = 0x10;
- drvr1_en = 0x10;
+ drvr0_en = 0x30;
+ drvr1_en = 0x30;
} else {
bias0_en = 0x3f;
bias1_en = 0x3f;
- drvr0_en = 0x34;
- drvr1_en = 0x34;
+ drvr0_en = 0x30;
+ drvr1_en = 0x30;
}
writel(drvr0_en, qmp->dp_tx + cfg->regs[QPHY_TX_HIGHZ_DRVR_EN]);
@@ -3584,6 +3636,14 @@ static int qmp_v8_configure_dp_phy(struct qmp_combo *qmp)
writel(drvr1_en, qmp->dp_tx2 + cfg->regs[QPHY_TX_HIGHZ_DRVR_EN]);
writel(bias1_en, qmp->dp_tx2 + cfg->regs[QPHY_TX_TRANSCEIVER_BIAS_EN]);
+ writel(0x03, qmp->dp_dp_phy + QSERDES_V8_DP_PHY_TSYNC_OVRD);
+ writel(0x23, qmp->dp_dp_phy + QSERDES_V8_DP_PHY_TSYNC_OVRD);
+ writel(0x22, qmp->dp_dp_phy + QSERDES_V8_DP_PHY_TSYNC_OVRD);
+
+ writel(0x0a, qmp->dp_tx + QSERDES_V8_LALB_RESET_TSYNC_EN_CTRL);
+ writel(0x0a, qmp->dp_tx2 + QSERDES_V8_LALB_RESET_TSYNC_EN_CTRL);
+
+ writel(0x3e, qmp->dp_dp_phy + QSERDES_V8_DP_PHY_TSYNC_OVRD);
writel(0x08, qmp->dp_dp_phy + QSERDES_DP_PHY_CFG);
udelay(100);
writel(0x09, qmp->dp_dp_phy + QSERDES_DP_PHY_CFG);
@@ -3591,16 +3651,24 @@ static int qmp_v8_configure_dp_phy(struct qmp_combo *qmp)
if (readl_poll_timeout(qmp->dp_dp_phy + cfg->regs[QPHY_DP_PHY_STATUS],
status,
- ((status & BIT(1)) > 0),
+ ((status & BIT(0)) > 0),
500,
10000))
return -ETIMEDOUT;
- writel(0x00, qmp->dp_tx + cfg->regs[QPHY_TX_TX_DRV_LVL]);
- writel(0x00, qmp->dp_tx2 + cfg->regs[QPHY_TX_TX_DRV_LVL]);
+ if (readl_poll_timeout(qmp->dp_serdes + cfg->regs[QPHY_COM_CMN_STATUS],
+ status,
+ ((status & BIT(0)) > 0),
+ 500,
+ 10000))
+ return -ETIMEDOUT;
- writel(0x2b, qmp->dp_tx + cfg->regs[QPHY_TX_TX_EMP_POST1_LVL]);
- writel(0x2b, qmp->dp_tx2 + cfg->regs[QPHY_TX_TX_EMP_POST1_LVL]);
+ if (readl_poll_timeout(qmp->dp_serdes + cfg->regs[QPHY_COM_CMN_STATUS],
+ status,
+ ((status & BIT(1)) > 0),
+ 500,
+ 10000))
+ return -ETIMEDOUT;
return 0;
}
---
base-commit: 6946bc5406f7fe2cb024419eca681bb0280f3461
change-id: 20260720-glymur-phy-conf-fc878ed134b1
Best regards,
--
Nabige Aala <nabige.aala@oss.qualcomm.com>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* Re: [PATCH] phy: qualcomm: qmp-combo: update DP PHY PLL programming on Glymur
From: sashiko-bot @ 2026-07-21 5:38 UTC (permalink / raw)
To: Nabige Aala; +Cc: olteanv, linux-phy, neil.armstrong, vkoul
In-Reply-To: <20260721-glymur-phy-conf-v1-1-7c8909552c5e@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Missing DP PHY ready check due to copy-paste error in status register polling.
- [High] Unconditional overwrite of QSERDES_DP_PHY_AUX_CFG2 clobbers the intended patch fix.
--
--- Patch [1]: [PATCH] phy: qualcomm: qmp-combo: update DP PHY PLL programming on Glymur ---
(Note: Due to system recitation restrictions, this review uses a free-form
summary format instead of inline quoting of the patch diff.)
commit f0c7819a29d1aef3384c1acb434959f322baf8bd
Author: Ritesh Kumar <ritesh.kumar@oss.qualcomm.com>
phy: qualcomm: qmp-combo: update DP PHY PLL programming on Glymur
The existing DP PHY PLL and AUX configuration for the Glymur platform
does not fully follow the Hardware Programming Guide requirements for
DP over Type-C, which results in DP link bring-up failures.
Update the DP PHY programming sequence and PLL-related register
settings to align with the latest recommendations.
Link: https://lore.kernel.org/all/20260419-glymur_dp-v1-1-ad1067a8e8ae@oss.qualcomm.com/
[Severity: High]
Looking at the updated status polling in qmp_v8_configure_dp_phy() in
drivers/phy/qualcomm/phy-qcom-qmp-combo.c, the code now polls
QPHY_DP_PHY_STATUS for BIT(0), and then polls QPHY_COM_CMN_STATUS twice
(first for BIT(0), then for BIT(1)).
Previously, this section waited for the DP PHY to become ready by polling
QPHY_DP_PHY_STATUS for BIT(1) after writing to QSERDES_DP_PHY_CFG. Since
QPHY_COM_CMN_STATUS was already polled earlier in the sequence, will these
new checks succeed immediately and bypass the required synchronization for
the DP PHY state machine? Could this result in race conditions and
DisplayPort link training failures?
[Severity: High]
In the newly introduced qmp_v8_helper_configure_dp_phy() function in the
same file, there is an unconditional write of 0xa4 to
QSERDES_DP_PHY_AUX_CFG2.
However, qmp_v8_dp_aux_init() is designed to write the newly recommended
0x06 value to QSERDES_DP_PHY_AUX_CFG2. Because the helper function
qmp_v8_helper_configure_dp_phy() is called later during link training via
configure_dp_phy(), will this hardcoded write of 0xa4 clobber the 0x06 value
programmed earlier? Does this inadvertently undo the intended AUX
configuration fix for the Glymur platform?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260721-glymur-phy-conf-v1-1-7c8909552c5e@oss.qualcomm.com?part=1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 1/2] phy: zynqmp: fix clock error handling in xpsgtr_phy_init()
From: Michal Simek @ 2026-07-21 5:39 UTC (permalink / raw)
To: Radhey Shyam Pandey, tomi.valkeinen, vkoul, neil.armstrong
Cc: linux-kernel, linux-phy, linux-arm-kernel, git
In-Reply-To: <20260720153832.1130006-2-radhey.shyam.pandey@amd.com>
On 7/20/26 17:38, Radhey Shyam Pandey wrote:
> Propagate clk_prepare_enable() failures to the caller instead of
> returning success, and disable the reference clock on initialization
> error paths to avoid leaking clock references when phy_exit() is not
> called.
>
> Fixes: 25d700833513 ("phy: xilinx: phy-zynqmp: dynamic clock support for power-save")
> Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
> ---
> drivers/phy/xilinx/phy-zynqmp.c | 13 +++++++++----
> 1 file changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/phy/xilinx/phy-zynqmp.c b/drivers/phy/xilinx/phy-zynqmp.c
> index fe6b4925d166..c8230f2bda62 100644
> --- a/drivers/phy/xilinx/phy-zynqmp.c
> +++ b/drivers/phy/xilinx/phy-zynqmp.c
> @@ -658,12 +658,13 @@ static int xpsgtr_phy_init(struct phy *phy)
> {
> struct xpsgtr_phy *gtr_phy = phy_get_drvdata(phy);
> struct xpsgtr_dev *gtr_dev = gtr_phy->dev;
> - int ret = 0;
> + int ret;
>
> mutex_lock(>r_dev->gtr_mutex);
>
> /* Configure and enable the clock when peripheral phy_init call */
> - if (clk_prepare_enable(gtr_dev->clk[gtr_phy->refclk]))
> + ret = clk_prepare_enable(gtr_dev->clk[gtr_phy->refclk]);
> + if (ret)
> goto out;
>
> /* Skip initialization if not required. */
> @@ -673,7 +674,7 @@ static int xpsgtr_phy_init(struct phy *phy)
> if (gtr_dev->tx_term_fix) {
> ret = xpsgtr_phy_tx_term_fix(gtr_phy);
> if (ret < 0)
> - goto out;
> + goto out_disable_clk;
>
> gtr_dev->tx_term_fix = false;
> }
> @@ -687,7 +688,7 @@ static int xpsgtr_phy_init(struct phy *phy)
> */
> ret = xpsgtr_configure_pll(gtr_phy);
> if (ret)
> - goto out;
> + goto out_disable_clk;
>
> xpsgtr_lane_set_protocol(gtr_phy);
>
> @@ -705,6 +706,10 @@ static int xpsgtr_phy_init(struct phy *phy)
> break;
> }
>
> + goto out;
> +
> +out_disable_clk:
> + clk_disable_unprepare(gtr_dev->clk[gtr_phy->refclk]);
> out:
> mutex_unlock(>r_dev->gtr_mutex);
> return ret;
Reviewed-by: Michal Simek <michal.simek@amd.com>
Thanks,
Michal
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 2/2] phy: zynqmp: fix runtime PM leak on probe allocation failure
From: Michal Simek @ 2026-07-21 5:39 UTC (permalink / raw)
To: Radhey Shyam Pandey, tomi.valkeinen, vkoul, neil.armstrong
Cc: linux-kernel, linux-phy, linux-arm-kernel, git
In-Reply-To: <20260720153832.1130006-3-radhey.shyam.pandey@amd.com>
On 7/20/26 17:38, Radhey Shyam Pandey wrote:
> Allocate saved_regs before pm_runtime_resume_and_get() so a
> devm_kmalloc() failure does not leave an unreleased runtime PM usage
> counter.
>
> Fixes: 5af9b304bc60 ("phy: xilinx: phy-zynqmp: Fix SGMII linkup failure on resume")
> Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
> ---
> drivers/phy/xilinx/phy-zynqmp.c | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/phy/xilinx/phy-zynqmp.c b/drivers/phy/xilinx/phy-zynqmp.c
> index c8230f2bda62..2138f5399821 100644
> --- a/drivers/phy/xilinx/phy-zynqmp.c
> +++ b/drivers/phy/xilinx/phy-zynqmp.c
> @@ -1044,6 +1044,12 @@ static int xpsgtr_probe(struct platform_device *pdev)
> return PTR_ERR(provider);
> }
>
> + gtr_dev->saved_regs = devm_kmalloc(gtr_dev->dev,
> + sizeof(save_reg_address),
> + GFP_KERNEL);
> + if (!gtr_dev->saved_regs)
> + return -ENOMEM;
> +
> pm_runtime_set_active(gtr_dev->dev);
> pm_runtime_enable(gtr_dev->dev);
>
> @@ -1053,12 +1059,6 @@ static int xpsgtr_probe(struct platform_device *pdev)
> return ret;
> }
>
> - gtr_dev->saved_regs = devm_kmalloc(gtr_dev->dev,
> - sizeof(save_reg_address),
> - GFP_KERNEL);
> - if (!gtr_dev->saved_regs)
> - return -ENOMEM;
> -
> return 0;
> }
>
Reviewed-by: Michal Simek <michal.simek@amd.com>
Thanks,
Michal
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v6 2/4] dt-bindings: phy: qcs615-qmp-usb3dp: Add support for Shikra SoC
From: Krzysztof Kozlowski @ 2026-07-21 6:42 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: <20260712-usb-shikra-phy-v6-v6-2-1b3e51bf1541@oss.qualcomm.com>
On Sun, Jul 12, 2026 at 08:58:35PM +0530, Krishna Kurapati wrote:
> 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 | 49 +++++++++++++++++++++-
> 1 file changed, 48 insertions(+), 1 deletion(-)
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
* [PATCH v2 0/4] phy: freescale: fsl-samsung-hdmi: Fix runtime PM issues
From: Can Peng @ 2026-07-21 6:47 UTC (permalink / raw)
To: vkoul, neil.armstrong, bmasney; +Cc: linux-phy, linux-kernel, Can Peng
Hi,
v1 fixed runtime PM cleanup when PHY clock registration fails. During
review, additional runtime PM and clock lifetime issues were pointed out
in the same driver:
- the APB clock can be disabled twice on remove if the device is runtime
suspended;
- the PHY clock .set_rate() path can access registers after the provider
device has been runtime suspended;
- runtime resume can leak the APB clock enable count if PHY
reconfiguration fails.
This v2 keeps the original cleanup fix and adds targeted fixes for the
other cases.
The PHY clock is registered after runtime PM is enabled, so the common
clock framework takes a runtime PM reference on the provider device
before invoking the rate callbacks. Patch 3 keeps the APB clock prepared
for the lifetime of the device and only gates it in runtime PM callbacks,
which makes the provider resume path safe while rate callbacks access
PHY registers.
Changes in v2:
- Expand the original single patch into a four-patch series.
- Add fixes for the remove-time APB clock underflow, CCF .set_rate()
runtime PM path and runtime-resume error unwind reported during
review.
- Link to v1:
https://lore.kernel.org/all/20260718071816.437047-1-pengcan@kylinos.cn/
Can Peng (4):
phy: freescale: fsl-samsung-hdmi: Fix runtime PM cleanup
phy: freescale: fsl-samsung-hdmi: Resume device on remove
phy: freescale: fsl-samsung-hdmi: Only gate APB clock in runtime PM
phy: freescale: fsl-samsung-hdmi: Disable APB clock on resume failure
drivers/phy/freescale/phy-fsl-samsung-hdmi.c | 32 +++++++++++++++-----
1 file changed, 25 insertions(+), 7 deletions(-)
--
2.53.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH v2 1/4] phy: freescale: fsl-samsung-hdmi: Fix runtime PM cleanup
From: Can Peng @ 2026-07-21 6:47 UTC (permalink / raw)
To: vkoul, neil.armstrong, bmasney; +Cc: linux-phy, linux-kernel, Can Peng, stable
In-Reply-To: <20260721064752.153338-1-pengcan@kylinos.cn>
fsl_samsung_hdmi_phy_probe() takes a runtime PM reference, marks the
device active and enables runtime PM before registering the PHY clock.
If phy_clk_register() fails, probe returns without dropping the runtime
PM reference or disabling runtime PM.
The remove callback only unregisters the clock provider, so runtime PM
is also left enabled after a successful probe followed by driver unbind.
Check pm_runtime_set_active(), use devm_pm_runtime_enable() so runtime
PM is disabled automatically, and drop the initial noresume reference
on PM setup and clock registration failures.
Fixes: 6ad082bee902 ("phy: freescale: add Samsung HDMI PHY")
Cc: stable@vger.kernel.org
Signed-off-by: Can Peng <pengcan@kylinos.cn>
---
drivers/phy/freescale/phy-fsl-samsung-hdmi.c | 14 ++++++++++----
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/phy/freescale/phy-fsl-samsung-hdmi.c b/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
index d010fec15671..e7af4f9c7b20 100644
--- a/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
+++ b/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
@@ -665,20 +665,26 @@ static int fsl_samsung_hdmi_phy_probe(struct platform_device *pdev)
"failed to get ref clk\n");
pm_runtime_get_noresume(phy->dev);
- pm_runtime_set_active(phy->dev);
- pm_runtime_enable(phy->dev);
+ ret = pm_runtime_set_active(phy->dev);
+ if (ret)
+ goto pm_put_noidle;
+
+ ret = devm_pm_runtime_enable(phy->dev);
+ if (ret)
+ goto pm_put_noidle;
ret = phy_clk_register(phy);
if (ret) {
dev_err(&pdev->dev, "register clk failed\n");
- goto register_clk_failed;
+ goto pm_put_noidle;
}
pm_runtime_put(phy->dev);
return 0;
-register_clk_failed:
+pm_put_noidle:
+ pm_runtime_put_noidle(phy->dev);
return ret;
}
--
2.53.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v2 2/4] phy: freescale: fsl-samsung-hdmi: Resume device on remove
From: Can Peng @ 2026-07-21 6:47 UTC (permalink / raw)
To: vkoul, neil.armstrong, bmasney; +Cc: linux-phy, linux-kernel, Can Peng, stable
In-Reply-To: <20260721064752.153338-1-pengcan@kylinos.cn>
The APB clock is acquired with devm_clk_get_enabled(), so devres will
disable and unprepare it when the driver is unbound.
Runtime suspend also disables the APB clock. If the device is runtime
suspended when the driver is removed, devres will disable the already
disabled clock and the clock enable count can underflow.
Resume the device in the remove callback before devres runs so the final
devres disable is balanced. Drop the runtime PM reference with noidle so
the device is not suspended again before devres cleanup.
Fixes: 6ad082bee902 ("phy: freescale: add Samsung HDMI PHY")
Cc: stable@vger.kernel.org
Signed-off-by: Can Peng <pengcan@kylinos.cn>
---
drivers/phy/freescale/phy-fsl-samsung-hdmi.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/phy/freescale/phy-fsl-samsung-hdmi.c b/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
index e7af4f9c7b20..5f41890bd134 100644
--- a/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
+++ b/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
@@ -690,7 +690,16 @@ static int fsl_samsung_hdmi_phy_probe(struct platform_device *pdev)
static void fsl_samsung_hdmi_phy_remove(struct platform_device *pdev)
{
+ int ret;
+
+ ret = pm_runtime_resume_and_get(&pdev->dev);
+ if (ret < 0)
+ dev_warn(&pdev->dev, "failed to resume on remove: %d\n", ret);
+
of_clk_del_provider(pdev->dev.of_node);
+
+ if (!ret)
+ pm_runtime_put_noidle(&pdev->dev);
}
static int __maybe_unused fsl_samsung_hdmi_phy_suspend(struct device *dev)
--
2.53.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v2 3/4] phy: freescale: fsl-samsung-hdmi: Only gate APB clock in runtime PM
From: Can Peng @ 2026-07-21 6:47 UTC (permalink / raw)
To: vkoul, neil.armstrong, bmasney; +Cc: linux-phy, linux-kernel, Can Peng, stable
In-Reply-To: <20260721064752.153338-1-pengcan@kylinos.cn>
The APB clock is acquired with devm_clk_get_enabled(), so it remains
prepared until devres cleanup and runtime PM only needs to gate or ungate
it.
Using clk_prepare_enable() from runtime resume is also problematic when
the common clock framework runtime-resumes the provider device before
calling the PHY clock rate callbacks, because clk_set_rate() is executed
while holding the clock prepare lock.
Use clk_enable() and clk_disable() in the runtime PM callbacks so the APB
clock remains prepared for the lifetime of the device and runtime resume
does not re-enter the prepare path.
Fixes: 6ad082bee902 ("phy: freescale: add Samsung HDMI PHY")
Cc: stable@vger.kernel.org
Signed-off-by: Can Peng <pengcan@kylinos.cn>
---
drivers/phy/freescale/phy-fsl-samsung-hdmi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/phy/freescale/phy-fsl-samsung-hdmi.c b/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
index 5f41890bd134..455d03220b72 100644
--- a/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
+++ b/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
@@ -706,7 +706,7 @@ static int __maybe_unused fsl_samsung_hdmi_phy_suspend(struct device *dev)
{
struct fsl_samsung_hdmi_phy *phy = dev_get_drvdata(dev);
- clk_disable_unprepare(phy->apbclk);
+ clk_disable(phy->apbclk);
return 0;
}
@@ -716,7 +716,7 @@ static int __maybe_unused fsl_samsung_hdmi_phy_resume(struct device *dev)
struct fsl_samsung_hdmi_phy *phy = dev_get_drvdata(dev);
int ret = 0;
- ret = clk_prepare_enable(phy->apbclk);
+ ret = clk_enable(phy->apbclk);
if (ret) {
dev_err(phy->dev, "failed to enable apbclk\n");
return ret;
--
2.53.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v2 4/4] phy: freescale: fsl-samsung-hdmi: Disable APB clock on resume failure
From: Can Peng @ 2026-07-21 6:47 UTC (permalink / raw)
To: vkoul, neil.armstrong, bmasney; +Cc: linux-phy, linux-kernel, Can Peng, stable
In-Reply-To: <20260721064752.153338-1-pengcan@kylinos.cn>
fsl_samsung_hdmi_phy_resume() enables apbclk and then reprograms the PHY
when a previous clock configuration is available. If the hardware
configuration fails, the function returns the error with apbclk still
enabled.
Disable apbclk on the failure path so the clock enable count remains
balanced.
Fixes: 6ad082bee902 ("phy: freescale: add Samsung HDMI PHY")
Cc: stable@vger.kernel.org
Signed-off-by: Can Peng <pengcan@kylinos.cn>
---
drivers/phy/freescale/phy-fsl-samsung-hdmi.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/phy/freescale/phy-fsl-samsung-hdmi.c b/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
index 455d03220b72..bb1aa1977065 100644
--- a/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
+++ b/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
@@ -722,8 +722,11 @@ static int __maybe_unused fsl_samsung_hdmi_phy_resume(struct device *dev)
return ret;
}
- if (phy->cur_cfg)
+ if (phy->cur_cfg) {
ret = fsl_samsung_hdmi_phy_configure(phy, phy->cur_cfg);
+ if (ret)
+ clk_disable(phy->apbclk);
+ }
return ret;
--
2.53.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* Re: [PATCH v2 4/4] phy: freescale: fsl-samsung-hdmi: Disable APB clock on resume failure
From: sashiko-bot @ 2026-07-21 7:01 UTC (permalink / raw)
To: Can Peng; +Cc: vkoul, olteanv, neil.armstrong, linux-phy
In-Reply-To: <20260721064752.153338-5-pengcan@kylinos.cn>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
Pre-existing issues:
- [Critical] The clock `set_rate` callback directly accesses hardware registers without ensuring the PHY device is runtime active, which could cause a synchronous external abort when called while the device is suspended.
- [High] The driver mutates a static global variable to store dynamically calculated, instance-specific PHY configurations, causing a race condition in multi-instance or concurrent scenarios.
- [Medium] If `pm_runtime_resume_and_get()` fails in `fsl_samsung_hdmi_phy_remove()`, devres cleanup will underflow the APB clock enable count.
--
--- Patch [4]: [PATCH v2 4/4] phy: freescale: fsl-samsung-hdmi: Disable APB clock on resume failure ---
commit f185b639eb37a8417c686059fd4e7a2399306055
Author: Can Peng <pengcan@kylinos.cn>
phy: freescale: fsl-samsung-hdmi: Disable APB clock on resume failure
This commit modifies the fsl_samsung_hdmi_phy_resume() function to disable
the apbclk on the failure path. This ensures the clock enable count remains
balanced if the hardware configuration fails after the clock was enabled.
Cc: stable@vger.kernel.org
> diff --git a/drivers/phy/freescale/phy-fsl-samsung-hdmi.c b/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
> index 455d03220b72c..bb1aa19770650 100644
> --- a/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
> +++ b/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
> @@ -722,8 +722,11 @@ static int __maybe_unused fsl_samsung_hdmi_phy_resume(struct device *dev)
> return ret;
> }
>
> - if (phy->cur_cfg)
> + if (phy->cur_cfg) {
> ret = fsl_samsung_hdmi_phy_configure(phy, phy->cur_cfg);
[Severity: High]
This is a pre-existing issue, but does reading phy->cur_cfg here race
with concurrent clock rate updates?
In fsl_samsung_hdmi_phy_find_settings(), the driver dynamically calculates
settings and writes them into a shared static global variable without
locking:
static struct phy_config calculated_phy_pll_cfg = { ... };
fsl_samsung_hdmi_phy_find_settings()
...
fsl_samsung_hdmi_calculate_phy(&calculated_phy_pll_cfg, ...);
If a concurrent call to clk_round_rate() updates calculated_phy_pll_cfg
while this resume callback is reading from it via phy->cur_cfg, could it
write partially updated or invalid PLL values to the hardware, resulting in
corrupted output or a display lockup?
> + if (ret)
> + clk_disable(phy->apbclk);
> + }
>
> return ret;
[Severity: Critical]
This is a pre-existing issue, but does the clock set_rate callback risk a
synchronous external abort if called while the device is suspended?
The clk_set_rate callback directly accesses hardware registers without
calling pm_runtime_resume_and_get():
fsl_samsung_hdmi_phy_clk_set_rate()
...
return fsl_samsung_hdmi_phy_configure(phy, target_settings);
fsl_samsung_hdmi_phy_configure()
...
writeb(REG33_FIX_DA, phy->regs + PHY_REG(33));
Because the clock framework does not automatically resume provider devices
during clk_set_rate(), if a consumer calls clk_set_rate() while the PHY is
runtime suspended, would writing to these unclocked APB registers cause a
system crash?
[Severity: Medium]
This is a pre-existing issue, but does failing to resume in remove()
cause a clock enable count underflow?
If pm_runtime_resume_and_get() fails (for example, due to a PLL lock
timeout), the device remains suspended with an enable count of 0:
fsl_samsung_hdmi_phy_remove()
...
ret = pm_runtime_resume_and_get(&pdev->dev);
if (ret < 0)
dev_warn(&pdev->dev, "failed to resume on remove: %d\n", ret);
When remove() returns, devres cleanup unconditionally calls
clk_disable_unprepare(). Since the driver mixes devm_clk_get_enabled()
with manual clk_enable() and clk_disable() PM runtime toggling, wouldn't
this invoke clk_disable() on a clock that is already at 0, triggering a
warning in the clock core?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260721064752.153338-1-pengcan@kylinos.cn?part=4
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH v5 0/2] Enable the QMP PCIe PHY present in Qualcomm ipq5210 SoC
From: Varadarajan Narayanan @ 2026-07-21 7:35 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel,
Varadarajan Narayanan, Krzysztof Kozlowski, Dmitry Baryshkov
Document the bindings and update the driver to support
the PCIe phy present in Qualcomm ipq5210 SoC.
Signed-off-by: Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com>
---
v5: Rebase to top of tree and resolve conflicts in phy-qcom-qmp-pcie.c
Pick 'R-b Krzysztof' for dt-bindings patch
v4: https://lore.kernel.org/r/20260616-pcie-phy-v4-0-504677c3d727@oss.qualcomm.com
Fix commit message for the bindings patch by removing redundant content
and adding explanation for using specific compatible.
v3: https://lore.kernel.org/linux-arm-msm/20260610-pcie-phy-v3-0-334011b378d6@oss.qualcomm.com/
Fix commit message for the bindings patch
Remove unused tables from the phy driver (ipq5210_gen3x1_pcie_ep_tx_tbl
and ipq5210_gen3x1_pcie_ep_pcs_tbl)
v2: https://lore.kernel.org/r/20260609-pcie-phy-v2-0-83bc80e79fa6@oss.qualcomm.com
Had incorrectly made both the phys as fallback. The single
lane phy is standalone and double lane uses ipq9574 as
fallback.
v1: https://lore.kernel.org/linux-arm-msm/20260514-pci-phy-v1-0-482429192746@oss.qualcomm.com/
---
Varadarajan Narayanan (2):
dt-bindings: phy: qcom,ipq8074-qmp-pcie: Document the ipq5210 QMP PCIe PHY
phy: qcom-qmp-pcie: Add support for ipq5210 PCIe phys
.../bindings/phy/qcom,ipq8074-qmp-pcie-phy.yaml | 2 +
drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 129 +++++++++++++++++++++
2 files changed, 131 insertions(+)
---
base-commit: 03cfefef0119410fc464d0d56e83626cb570b7a8
change-id: 20260609-pcie-phy-99fcf91a02fd
prerequisite-change-id: 20260514-icc-ipq5210-0ab03f3a3e83:v1
prerequisite-patch-id: 0b6145b6635b18fe79fbbff5815041b43778c5ed
prerequisite-patch-id: 924c6ff7baf4283ac7991ee94c803a00fc5cece4
prerequisite-patch-id: c2fe1800fe769dccd37f94c19860a07f979e3c4c
Best regards,
--
Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH v5 1/2] dt-bindings: phy: qcom,ipq8074-qmp-pcie: Document the ipq5210 QMP PCIe PHY
From: Varadarajan Narayanan @ 2026-07-21 7:35 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel,
Varadarajan Narayanan, Krzysztof Kozlowski
In-Reply-To: <20260721-pcie-phy-v5-0-8d403ef7e780@oss.qualcomm.com>
The ipq5210 has one dual lane and one single lane PCIe phy.
The dual lane phy is similar to the dual lane phy present in ipq9574. Hence
qcom,ipq5210-qmp-gen3x2-pcie-phy is documented with ipq9574's dual lane phy
as fallback compatible.
The single lane phy (qcom,ipq5210-qmp-gen3x1-pcie-phy) is documented as
specific compatible as it uses a combination of its own initialization
tables and some of the existing tables.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com>
---
Documentation/devicetree/bindings/phy/qcom,ipq8074-qmp-pcie-phy.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/phy/qcom,ipq8074-qmp-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,ipq8074-qmp-pcie-phy.yaml
index f60804687412..fc155ad5fa6d 100644
--- a/Documentation/devicetree/bindings/phy/qcom,ipq8074-qmp-pcie-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,ipq8074-qmp-pcie-phy.yaml
@@ -17,6 +17,7 @@ properties:
compatible:
oneOf:
- enum:
+ - qcom,ipq5210-qmp-gen3x1-pcie-phy
- qcom,ipq6018-qmp-pcie-phy
- qcom,ipq8074-qmp-gen3-pcie-phy
- qcom,ipq8074-qmp-pcie-phy
@@ -28,6 +29,7 @@ properties:
- const: qcom,ipq9574-qmp-gen3x1-pcie-phy
- items:
- enum:
+ - qcom,ipq5210-qmp-gen3x2-pcie-phy
- qcom,ipq5424-qmp-gen3x2-pcie-phy
- const: qcom,ipq9574-qmp-gen3x2-pcie-phy
--
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/2] phy: qcom-qmp-pcie: Add support for ipq5210 PCIe phys
From: Varadarajan Narayanan @ 2026-07-21 7:35 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel,
Varadarajan Narayanan, Dmitry Baryshkov
In-Reply-To: <20260721-pcie-phy-v5-0-8d403ef7e780@oss.qualcomm.com>
Add support for a PCIe phys found on Qualcomm ipq5210 platform.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com>
---
drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 129 +++++++++++++++++++++++++++++++
1 file changed, 129 insertions(+)
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
index f54f66429f37..f4b25a7b1604 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
@@ -636,6 +636,89 @@ static const struct qmp_phy_init_tbl ipq8074_pcie_gen3_pcs_misc_tbl[] = {
QMP_PHY_INIT_CFG(QPHY_V4_PCS_PCIE_ENDPOINT_REFCLK_DRIVE, 0xc1),
};
+static const struct qmp_phy_init_tbl ipq5210_gen3x1_pcie_ep_serdes_tbl[] = {
+ QMP_PHY_INIT_CFG(QSERDES_PLL_BG_TIMER, 0x02),
+ QMP_PHY_INIT_CFG(QSERDES_PLL_BIAS_EN_CLKBUFLR_EN, 0x18),
+ QMP_PHY_INIT_CFG(QSERDES_PLL_SYSCLK_BUF_ENABLE, 0x07),
+ QMP_PHY_INIT_CFG(QSERDES_PLL_PLL_IVCO, 0x0f),
+ QMP_PHY_INIT_CFG(QSERDES_PLL_LOCK_CMP1_MODE0, 0xff),
+ QMP_PHY_INIT_CFG(QSERDES_PLL_LOCK_CMP2_MODE0, 0x04),
+ QMP_PHY_INIT_CFG(QSERDES_PLL_LOCK_CMP1_MODE1, 0xff),
+ QMP_PHY_INIT_CFG(QSERDES_PLL_LOCK_CMP2_MODE1, 0x09),
+ QMP_PHY_INIT_CFG(QSERDES_PLL_BG_TRIM, 0x0f),
+ QMP_PHY_INIT_CFG(QSERDES_PLL_CP_CTRL_MODE0, 0x23),
+ QMP_PHY_INIT_CFG(QSERDES_PLL_CP_CTRL_MODE1, 0x23),
+ QMP_PHY_INIT_CFG(QSERDES_PLL_PLL_RCTRL_MODE0, 0x10),
+ QMP_PHY_INIT_CFG(QSERDES_PLL_PLL_RCTRL_MODE1, 0x10),
+ QMP_PHY_INIT_CFG(QSERDES_PLL_PLL_CCTRL_MODE0, 0x01),
+ QMP_PHY_INIT_CFG(QSERDES_PLL_PLL_CCTRL_MODE1, 0x01),
+ QMP_PHY_INIT_CFG(QSERDES_PLL_BIAS_EN_CTRL_BY_PSM, 0x01),
+ QMP_PHY_INIT_CFG(QSERDES_PLL_SYSCLK_EN_SEL, 0x00),
+ QMP_PHY_INIT_CFG(QSERDES_PLL_RESETSM_CNTRL, 0x20),
+ QMP_PHY_INIT_CFG(QSERDES_PLL_LOCK_CMP_EN, 0x42),
+ QMP_PHY_INIT_CFG(QSERDES_PLL_DEC_START_MODE0, 0x19),
+ QMP_PHY_INIT_CFG(QSERDES_PLL_DEC_START_MODE1, 0x14),
+ QMP_PHY_INIT_CFG(QSERDES_PLL_INTEGLOOP_GAIN0_MODE0, 0xfe),
+ QMP_PHY_INIT_CFG(QSERDES_PLL_INTEGLOOP_GAIN1_MODE0, 0x03),
+ QMP_PHY_INIT_CFG(QSERDES_PLL_INTEGLOOP_GAIN0_MODE1, 0xfe),
+ QMP_PHY_INIT_CFG(QSERDES_PLL_INTEGLOOP_GAIN1_MODE1, 0x03),
+ QMP_PHY_INIT_CFG(QSERDES_PLL_VCO_TUNE1_MODE0, 0x24),
+ QMP_PHY_INIT_CFG(QSERDES_PLL_VCO_TUNE2_MODE0, 0x02),
+ QMP_PHY_INIT_CFG(QSERDES_PLL_VCO_TUNE1_MODE1, 0xb4),
+ QMP_PHY_INIT_CFG(QSERDES_PLL_VCO_TUNE2_MODE1, 0x03),
+ QMP_PHY_INIT_CFG(QSERDES_PLL_HSCLK_SEL, 0x01),
+ QMP_PHY_INIT_CFG(QSERDES_PLL_CORE_CLK_EN, 0x00),
+ QMP_PHY_INIT_CFG(QSERDES_PLL_CMN_CONFIG, 0x06),
+ QMP_PHY_INIT_CFG(QSERDES_PLL_SVS_MODE_CLK_SEL, 0x05),
+ QMP_PHY_INIT_CFG(QSERDES_PLL_CORECLK_DIV_MODE1, 0x08),
+ QMP_PHY_INIT_CFG(QSERDES_PLL_SYS_CLK_CTRL, 0x07),
+ QMP_PHY_INIT_CFG(QSERDES_PLL_SYSCLK_EN_SEL, 0x10),
+};
+
+static const struct qmp_phy_init_tbl ipq5210_gen3x1_pcie_ep_rx_tbl[] = {
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_UCDR_FO_GAIN, 0x0c),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_UCDR_SO_GAIN, 0x02),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_UCDR_SO_SATURATION_AND_ENABLE, 0x7f),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_UCDR_PI_CONTROLS, 0x70),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_EQU_ADAPTOR_CNTRL2, 0x61),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_EQU_ADAPTOR_CNTRL3, 0x04),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_EQU_ADAPTOR_CNTRL4, 0x1e),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_IDAC_TSETTLE_LOW, 0xc0),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_IDAC_TSETTLE_HIGH, 0x00),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_EQ_OFFSET_ADAPTOR_CNTRL1, 0x73),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_OFFSET_ADAPTOR_CNTRL2, 0x80),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_SIGDET_ENABLES, 0x03),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_SIGDET_DEGLITCH_CNTRL, 0x14),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_MODE_00_LOW, 0xf0),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_MODE_00_HIGH, 0x01),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_MODE_00_HIGH2, 0x2f),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_MODE_00_HIGH3, 0xd3),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_MODE_00_HIGH4, 0x40),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_MODE_01_LOW, 0x01),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_MODE_01_HIGH, 0x02),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_MODE_01_HIGH2, 0xc8),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_MODE_01_HIGH3, 0x09),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_MODE_01_HIGH4, 0xb1),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_MODE_10_LOW, 0x00),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_MODE_10_HIGH, 0x02),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_MODE_10_HIGH2, 0xc8),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_MODE_10_HIGH3, 0x09),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_RX_MODE_10_HIGH4, 0xb1),
+ QMP_PHY_INIT_CFG(QSERDES_V4_RX_DFE_EN_TIMER, 0x04),
+};
+
+static const struct qmp_phy_init_tbl ipq5210_gen3x1_pcie_ep_pcs_misc_tbl[] = {
+ QMP_PHY_INIT_CFG(QPHY_V4_PCS_PCIE_POWER_STATE_CONFIG2, 0x04),
+ QMP_PHY_INIT_CFG(QPHY_V4_PCS_PCIE_POWER_STATE_CONFIG4, 0x07),
+ QMP_PHY_INIT_CFG(QPHY_V4_PCS_PCIE_L1P1_WAKEUP_DLY_TIME_AUXCLK_L, 0x01),
+ QMP_PHY_INIT_CFG(QPHY_V4_PCS_PCIE_L1P2_WAKEUP_DLY_TIME_AUXCLK_L, 0x01),
+ QMP_PHY_INIT_CFG(QPHY_V4_PCS_PCIE_EQ_CONFIG1, 0x11),
+ QMP_PHY_INIT_CFG(QPHY_V4_PCS_PCIE_PRESET_P10_PRE, 0x00),
+ QMP_PHY_INIT_CFG(QPHY_V4_PCS_PCIE_PRESET_P10_POST, 0x58),
+ QMP_PHY_INIT_CFG(QPHY_V4_PCS_PCIE_OSC_DTCT_CONFIG1, 0x02),
+ QMP_PHY_INIT_CFG(QPHY_V4_PCS_PCIE_OSC_DTCT_CONFIG4, 0xff),
+};
+
static const struct qmp_phy_init_tbl ipq9574_gen3x1_pcie_serdes_tbl[] = {
QMP_PHY_INIT_CFG(QSERDES_PLL_BIAS_EN_CLKBUFLR_EN, 0x18),
QMP_PHY_INIT_CFG(QSERDES_PLL_BIAS_EN_CTRL_BY_PSM, 0x01),
@@ -4061,6 +4144,49 @@ static const struct qmp_phy_cfg ipq6018_pciephy_cfg = {
.phy_status = PHYSTATUS,
};
+static const struct qmp_phy_cfg ipq5210_gen3x1_pciephy_cfg = {
+ .lanes = 1,
+
+ .offsets = &qmp_pcie_offsets_v4x1,
+
+ .tbls = {
+ .serdes = ipq9574_gen3x1_pcie_serdes_tbl,
+ .serdes_num = ARRAY_SIZE(ipq9574_gen3x1_pcie_serdes_tbl),
+ .tx = ipq8074_pcie_gen3_tx_tbl,
+ .tx_num = ARRAY_SIZE(ipq8074_pcie_gen3_tx_tbl),
+ .rx = ipq9574_pcie_rx_tbl,
+ .rx_num = ARRAY_SIZE(ipq9574_pcie_rx_tbl),
+ .pcs = ipq9574_gen3x1_pcie_pcs_tbl,
+ .pcs_num = ARRAY_SIZE(ipq9574_gen3x1_pcie_pcs_tbl),
+ .pcs_misc = ipq9574_gen3x1_pcie_pcs_misc_tbl,
+ .pcs_misc_num = ARRAY_SIZE(ipq9574_gen3x1_pcie_pcs_misc_tbl),
+ },
+
+ .tbls_ep = &(const struct qmp_phy_cfg_tbls) {
+ .serdes = ipq5210_gen3x1_pcie_ep_serdes_tbl,
+ .serdes_num = ARRAY_SIZE(ipq5210_gen3x1_pcie_ep_serdes_tbl),
+ .tx = ipq6018_pcie_tx_tbl,
+ .tx_num = ARRAY_SIZE(ipq6018_pcie_tx_tbl),
+ .rx = ipq5210_gen3x1_pcie_ep_rx_tbl,
+ .rx_num = ARRAY_SIZE(ipq5210_gen3x1_pcie_ep_rx_tbl),
+ .pcs = ipq6018_pcie_pcs_tbl,
+ .pcs_num = ARRAY_SIZE(ipq6018_pcie_pcs_tbl),
+ .pcs_misc = ipq5210_gen3x1_pcie_ep_pcs_misc_tbl,
+ .pcs_misc_num = ARRAY_SIZE(ipq5210_gen3x1_pcie_ep_pcs_misc_tbl),
+ },
+
+ .reset_list = ipq8074_pciephy_reset_l,
+ .num_resets = ARRAY_SIZE(ipq8074_pciephy_reset_l),
+ .vreg_list = NULL,
+ .num_vregs = 0,
+ .regs = pciephy_v4_regs_layout,
+
+ .pwrdn_ctrl = SW_PWRDN | REFCLK_DRV_DSBL,
+ .phy_status = PHYSTATUS,
+
+ .pipe_clock_rate = 250000000,
+};
+
static const struct qmp_phy_cfg ipq9574_gen3x1_pciephy_cfg = {
.lanes = 1,
@@ -5929,6 +6055,9 @@ static const struct of_device_id qmp_pcie_of_match_table[] = {
}, {
.compatible = "qcom,hawi-qmp-gen4x1-pcie-phy",
.data = &hawi_qmp_gen4x1_pciephy_cfg,
+ }, {
+ .compatible = "qcom,ipq5210-qmp-gen3x1-pcie-phy",
+ .data = &ipq5210_gen3x1_pciephy_cfg,
}, {
.compatible = "qcom,ipq6018-qmp-pcie-phy",
.data = &ipq6018_pciephy_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
* Re: [PATCH v12 1/2] dt-bindings: phy: qcom: Add CSI2 C-PHY/DPHY schema
From: Vladimir Zapolskiy @ 2026-07-21 8:11 UTC (permalink / raw)
To: Bryan O'Donoghue, Vinod Koul, Kishon Vijay Abraham I,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong
Cc: Bryan O'Donoghue, linux-arm-msm, linux-phy, linux-media,
devicetree, linux-kernel, Krzysztof Kozlowski
In-Reply-To: <20260719-x1e-csi2-phy-v12-1-cc7311326d1b@linaro.org>
On 7/19/26 16:47, Bryan O'Donoghue wrote:
> Add a base schema for the MIPI CSI2 PHYs on Qualcomm SoCs. This PHY
> supports both DPHY and CPHY operation. A special mode of DPHY operation -
> called variously split-mode or combo-mode also allows for two sensors to be
> connected to one PHY.
>
> The submitted binding here describes the DPHY modes of operation only. CPHY
> is left to future work.
>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
> ---
> .../bindings/phy/qcom,x1e80100-csi2-phy.yaml | 195 +++++++++++++++++++++
> 1 file changed, 195 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/phy/qcom,x1e80100-csi2-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,x1e80100-csi2-phy.yaml
> new file mode 100644
> index 0000000000000..880fe602945cb
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/qcom,x1e80100-csi2-phy.yaml
> @@ -0,0 +1,195 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/phy/qcom,x1e80100-csi2-phy.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Qualcomm X1E80100 SoC CSI2 PHY
> +
> +maintainers:
> + - Bryan O'Donoghue <bod@kernel.org>
> +
> +description:
> + Qualcomm MIPI CSI2 C-PHY/D-PHY combination PHY. Connects MIPI CSI2 sensors
> + to Qualcomm's Camera CSI Decoder. The PHY supports both C-PHY and D-PHY
> + modes.
> +
> +properties:
> + compatible:
> + const: qcom,x1e80100-csi2-phy
> +
> + reg:
> + maxItems: 1
> +
> + "#phy-cells":
> + const: 1
> + description:
> + The single cell specifies the PHY operating mode.
> +
This has been reported before, #phy-cells shall be 0, the operation
mode is selected by bus-type of endpoints as it is described in
video-interfaces.yaml
Two competing values are redundant, the technical discussion has
not been started yet.
> + clocks:
> + maxItems: 3
> +
> + clock-names:
> + items:
> + - const: core
> + - const: timer
> + - const: ahb
> +
> + interrupts:
> + maxItems: 1
> +
> + operating-points-v2: true
> +
> + opp-table:
> + type: object
> +
> + power-domains:
> + items:
> + - description: Titan Top GDSC - Titan ISP Block, Global Distributed Switch Controller.
> + - description: MMCX voltage rail
> + - description: MXC or MXA voltage rail
Please double check that there is such voltage rail as MXA.
> +
> + power-domain-names:
> + items:
> + - const: top
> + - const: mmcx
> + - const: mx
> +
> + vdda-0p9-supply:
> + description: Phandle to a 0.9V regulator supply to a PHY.
> +
> + vdda-1p2-supply:
> + description: Phandle to 1.2V regulator supply to a PHY.
> +
> + ports:
> + $ref: /schemas/graph.yaml#/properties/ports
> +
> + properties:
> + port@0:
> + $ref: /schemas/graph.yaml#/$defs/port-base
> + description:
> + Sensor input. Always present. A single sensor is described by a
> + single endpoint with one to four data lanes. DPHY split mode,
> + where two independent sensors share the same PHY, is described
> + by two endpoints; endpoint@0 with exactly two data-lanes and
> + endpoint@1 with exactly one data-lane.
> + unevaluatedProperties: false
> +
> + patternProperties:
> + "^endpoint(@[0-9a-f]+)?$":
endpoint regexp is not corrected, this issue has been reported
previously.
> + $ref: /schemas/media/video-interfaces.yaml#
> + unevaluatedProperties: false
> + properties:
> + data-lanes:
> + minItems: 1
> + maxItems: 4
> +
> + required:
> + - data-lanes
> + - remote-endpoint
> +
> + allOf:
> + - if:
> + required:
> + - endpoint@1
> + then:
> + properties:
> + endpoint@0:
> + properties:
> + data-lanes:
> + minItems: 2
> + maxItems: 2
> + endpoint@1:
> + properties:
> + data-lanes:
> + maxItems: 1
> + required:
> + - endpoint@0
> +
> + port@1:
> + $ref: /schemas/graph.yaml#/properties/port
> + description: Output to the CAMSS CSID controller.
> +
> + required:
> + - port@0
> + - port@1
> +
> +required:
> + - compatible
> + - reg
> + - "#phy-cells"
> + - clocks
> + - clock-names
> + - interrupts
> + - operating-points-v2
> + - power-domains
> + - power-domain-names
> + - vdda-0p9-supply
> + - vdda-1p2-supply
> + - ports
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> + #include <dt-bindings/clock/qcom,x1e80100-camcc.h>
> + #include <dt-bindings/clock/qcom,x1e80100-gcc.h>
> + #include <dt-bindings/power/qcom,rpmhpd.h>
> +
> + phy@ace4000 {
> + compatible = "qcom,x1e80100-csi2-phy";
> + reg = <0x0ace4000 0x2000>;
> + #phy-cells = <1>;
> +
> + clocks = <&camcc CAM_CC_CSIPHY0_CLK>,
> + <&camcc CAM_CC_CSI0PHYTIMER_CLK>,
> + <&camcc CAM_CC_CORE_AHB_CLK>;
> + clock-names = "core",
> + "timer",
> + "ahb";
> +
> + interrupts = <GIC_SPI 477 IRQ_TYPE_EDGE_RISING>;
> +
> + operating-points-v2 = <&csiphy_opp_table>;
> +
> + power-domains = <&camcc CAM_CC_TITAN_TOP_GDSC>,
> + <&rpmhpd RPMHPD_MMCX>,
> + <&rpmhpd RPMHPD_MX>;
> + power-domain-names = "top",
> + "mmcx",
> + "mx";
> +
> + vdda-0p9-supply = <&vreg_l2c_0p9>;
> + vdda-1p2-supply = <&vreg_l1c_1p2>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + csiphy0_in: endpoint {
> + data-lanes = <0 1 2 3>;
data-lanes values has not been corrected in accordance to linux-media
requirements.
> + remote-endpoint = <&sensor_out>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + csiphy0_out: endpoint {
> + remote-endpoint = <&csid_in>;
> + };
> + };
> + };
> +
> + csiphy_opp_table: opp-table {
> + compatible = "operating-points-v2";
> +
> + opp-300000000 {
> + opp-hz = /bits/ 64 <300000000>;
> + required-opps = <&rpmhpd_opp_low_svs_d1>,
> + <&rpmhpd_opp_low_svs_d1>;
> + };
> + };
> + };
>
--
Best wishes,
Vladimir
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v13 1/2] dt-bindings: phy: qcom: Add CSI2 C-PHY/DPHY schema
From: Neil Armstrong @ 2026-07-21 8:15 UTC (permalink / raw)
To: Bryan O'Donoghue, Vinod Koul, Kishon Vijay Abraham I,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Bryan O'Donoghue, Vladimir Zapolskiy, linux-arm-msm,
linux-phy, linux-media, devicetree, linux-kernel,
Krzysztof Kozlowski
In-Reply-To: <20260720-x1e-csi2-phy-v13-1-160c31958863@linaro.org>
Hi,
On 7/20/26 03:11, Bryan O'Donoghue wrote:
> Add a base schema for the MIPI CSI2 PHYs on Qualcomm SoCs. This PHY
> supports both DPHY and CPHY operation. A special mode of DPHY operation -
> called variously split-mode or combo-mode also allows for two sensors to be
> connected to one PHY.
>
> The submitted binding here describes the DPHY modes of operation only. CPHY
> is left to future work.
>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
> ---
> .../bindings/phy/qcom,x1e80100-csi2-phy.yaml | 195 +++++++++++++++++++++
> 1 file changed, 195 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/phy/qcom,x1e80100-csi2-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,x1e80100-csi2-phy.yaml
> new file mode 100644
> index 0000000000000..880fe602945cb
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/qcom,x1e80100-csi2-phy.yaml
> @@ -0,0 +1,195 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/phy/qcom,x1e80100-csi2-phy.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Qualcomm X1E80100 SoC CSI2 PHY
> +
> +maintainers:
> + - Bryan O'Donoghue <bod@kernel.org>
> +
> +description:
> + Qualcomm MIPI CSI2 C-PHY/D-PHY combination PHY. Connects MIPI CSI2 sensors
> + to Qualcomm's Camera CSI Decoder. The PHY supports both C-PHY and D-PHY
> + modes.
> +
> +properties:
> + compatible:
> + const: qcom,x1e80100-csi2-phy
> +
> + reg:
> + maxItems: 1
> +
> + "#phy-cells":
> + const: 1
> + description:
> + The single cell specifies the PHY operating mode.
> +
> + clocks:
> + maxItems: 3
> +
> + clock-names:
> + items:
> + - const: core
> + - const: timer
> + - const: ahb
> +
> + interrupts:
> + maxItems: 1
> +
> + operating-points-v2: true
> +
> + opp-table:
> + type: object
> +
> + power-domains:
> + items:
> + - description: Titan Top GDSC - Titan ISP Block, Global Distributed Switch Controller.
> + - description: MMCX voltage rail
> + - description: MXC or MXA voltage rail
> +
> + power-domain-names:
> + items:
> + - const: top
> + - const: mmcx
> + - const: mx
> +
> + vdda-0p9-supply:
> + description: Phandle to a 0.9V regulator supply to a PHY.
> +
> + vdda-1p2-supply:
> + description: Phandle to 1.2V regulator supply to a PHY.
> +
> + ports:
> + $ref: /schemas/graph.yaml#/properties/ports
> +
> + properties:
> + port@0:
> + $ref: /schemas/graph.yaml#/$defs/port-base
> + description:
> + Sensor input. Always present. A single sensor is described by a
> + single endpoint with one to four data lanes. DPHY split mode,
> + where two independent sensors share the same PHY, is described
> + by two endpoints; endpoint@0 with exactly two data-lanes and
> + endpoint@1 with exactly one data-lane.
> + unevaluatedProperties: false
> +
> + patternProperties:
> + "^endpoint(@[0-9a-f]+)?$":
> + $ref: /schemas/media/video-interfaces.yaml#
> + unevaluatedProperties: false
> + properties:
> + data-lanes:
> + minItems: 1
> + maxItems: 4
> +
> + required:
> + - data-lanes
> + - remote-endpoint
> +
> + allOf:
> + - if:
> + required:
> + - endpoint@1
> + then:
> + properties:
> + endpoint@0:
> + properties:
> + data-lanes:
> + minItems: 2
> + maxItems: 2
> + endpoint@1:
> + properties:
> + data-lanes:
> + maxItems: 1
> + required:
> + - endpoint@0
> +
> + port@1:
> + $ref: /schemas/graph.yaml#/properties/port
> + description: Output to the CAMSS CSID controller.
> +
> + required:
> + - port@0
> + - port@1
> +
> +required:
> + - compatible
> + - reg
> + - "#phy-cells"
> + - clocks
> + - clock-names
> + - interrupts
> + - operating-points-v2
> + - power-domains
> + - power-domain-names
> + - vdda-0p9-supply
> + - vdda-1p2-supply
> + - ports
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> + #include <dt-bindings/clock/qcom,x1e80100-camcc.h>
> + #include <dt-bindings/clock/qcom,x1e80100-gcc.h>
> + #include <dt-bindings/power/qcom,rpmhpd.h>
> +
> + phy@ace4000 {
> + compatible = "qcom,x1e80100-csi2-phy";
> + reg = <0x0ace4000 0x2000>;
> + #phy-cells = <1>;
> +
> + clocks = <&camcc CAM_CC_CSIPHY0_CLK>,
> + <&camcc CAM_CC_CSI0PHYTIMER_CLK>,
> + <&camcc CAM_CC_CORE_AHB_CLK>;
> + clock-names = "core",
> + "timer",
> + "ahb";
> +
> + interrupts = <GIC_SPI 477 IRQ_TYPE_EDGE_RISING>;
> +
> + operating-points-v2 = <&csiphy_opp_table>;
> +
> + power-domains = <&camcc CAM_CC_TITAN_TOP_GDSC>,
> + <&rpmhpd RPMHPD_MMCX>,
> + <&rpmhpd RPMHPD_MX>;
> + power-domain-names = "top",
> + "mmcx",
> + "mx";
> +
> + vdda-0p9-supply = <&vreg_l2c_0p9>;
> + vdda-1p2-supply = <&vreg_l1c_1p2>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + csiphy0_in: endpoint {
> + data-lanes = <0 1 2 3>;
> + remote-endpoint = <&sensor_out>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + csiphy0_out: endpoint {
> + remote-endpoint = <&csid_in>;
> + };
> + };
> + };
> +
> + csiphy_opp_table: opp-table {
> + compatible = "operating-points-v2";
> +
> + opp-300000000 {
> + opp-hz = /bits/ 64 <300000000>;
> + required-opps = <&rpmhpd_opp_low_svs_d1>,
> + <&rpmhpd_opp_low_svs_d1>;
> + };
> + };
> + };
>
While I see the utility of moving the CSI PHY into a separate node and
transferring the sensor endpoints there, I don't see why the PHYs would
be linked to CAMSS via the `phys =` property and via a port/endpoint to the CSIDs.
In my view, the `phys =` property should be used to reference static PHYs
associated with a controller, whereas port/endpoint graphs are better suited
for identifying the node and device for dynamic PHYs, like the ones we have here.
To that extent, I understand how moving this to the PHY framework could help
clean up the code. However, some PHY-related logic will still need to remain in
CAMSS to handle dynamic associations to different CSIDs at runtime.
I'm still not really convinced about moving this code to the PHY subsystem
as a standalone PHY driver.
Neil
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v13 1/2] dt-bindings: phy: qcom: Add CSI2 C-PHY/DPHY schema
From: Vladimir Zapolskiy @ 2026-07-21 8:17 UTC (permalink / raw)
To: Bryan O'Donoghue, Vinod Koul, Kishon Vijay Abraham I,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong
Cc: Bryan O'Donoghue, linux-arm-msm, linux-phy, linux-media,
devicetree, linux-kernel, Krzysztof Kozlowski
In-Reply-To: <20260720-x1e-csi2-phy-v13-1-160c31958863@linaro.org>
On 7/20/26 04:11, Bryan O'Donoghue wrote:
> Add a base schema for the MIPI CSI2 PHYs on Qualcomm SoCs. This PHY
> supports both DPHY and CPHY operation. A special mode of DPHY operation -
> called variously split-mode or combo-mode also allows for two sensors to be
> connected to one PHY.
>
> The submitted binding here describes the DPHY modes of operation only. CPHY
> is left to future work.
>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Since there is no changes in dt bindings from v12, all comments from here
are still applicable to this version of the changeset:
https://lore.kernel.org/linux-arm-msm/20260719-x1e-csi2-phy-v12-0-cc7311326d1b@linaro.org/
> ---
> .../bindings/phy/qcom,x1e80100-csi2-phy.yaml | 195 +++++++++++++++++++++
> 1 file changed, 195 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/phy/qcom,x1e80100-csi2-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,x1e80100-csi2-phy.yaml
> new file mode 100644
> index 0000000000000..880fe602945cb
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/qcom,x1e80100-csi2-phy.yaml
> @@ -0,0 +1,195 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/phy/qcom,x1e80100-csi2-phy.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Qualcomm X1E80100 SoC CSI2 PHY
> +
> +maintainers:
> + - Bryan O'Donoghue <bod@kernel.org>
> +
> +description:
> + Qualcomm MIPI CSI2 C-PHY/D-PHY combination PHY. Connects MIPI CSI2 sensors
> + to Qualcomm's Camera CSI Decoder. The PHY supports both C-PHY and D-PHY
> + modes.
> +
> +properties:
> + compatible:
> + const: qcom,x1e80100-csi2-phy
> +
> + reg:
> + maxItems: 1
> +
> + "#phy-cells":
> + const: 1
> + description:
> + The single cell specifies the PHY operating mode.
This has been reported before, #phy-cells shall be 0, the operation
mode is selected by bus-type of endpoints as it is described in
video-interfaces.yaml
Two competing values are redundant and it opens a door to a wrong
hardware description, the technical discussion has not been started yet.
> +
> + clocks:
> + maxItems: 3
> +
> + clock-names:
> + items:
> + - const: core
> + - const: timer
> + - const: ahb
> +
> + interrupts:
> + maxItems: 1
> +
> + operating-points-v2: true
> +
> + opp-table:
> + type: object
> +
> + power-domains:
> + items:
> + - description: Titan Top GDSC - Titan ISP Block, Global Distributed Switch Controller.
> + - description: MMCX voltage rail
> + - description: MXC or MXA voltage rail
> +
> + power-domain-names:
> + items:
> + - const: top
> + - const: mmcx
> + - const: mx
> +
> + vdda-0p9-supply:
> + description: Phandle to a 0.9V regulator supply to a PHY.
> +
> + vdda-1p2-supply:
> + description: Phandle to 1.2V regulator supply to a PHY.
> +
> + ports:
> + $ref: /schemas/graph.yaml#/properties/ports
> +
> + properties:
> + port@0:
> + $ref: /schemas/graph.yaml#/$defs/port-base
> + description:
> + Sensor input. Always present. A single sensor is described by a
> + single endpoint with one to four data lanes. DPHY split mode,
> + where two independent sensors share the same PHY, is described
> + by two endpoints; endpoint@0 with exactly two data-lanes and
> + endpoint@1 with exactly one data-lane.
> + unevaluatedProperties: false
> +
> + patternProperties:
> + "^endpoint(@[0-9a-f]+)?$":
endpoint suffix regexp is incorrected, this issue has been reported
previously, still it is not fixed.
> + $ref: /schemas/media/video-interfaces.yaml#
> + unevaluatedProperties: false
> + properties:
> + data-lanes:
> + minItems: 1
> + maxItems: 4
> +
> + required:
> + - data-lanes
> + - remote-endpoint
> +
> + allOf:
> + - if:
> + required:
> + - endpoint@1
> + then:
> + properties:
> + endpoint@0:
> + properties:
> + data-lanes:
> + minItems: 2
> + maxItems: 2
> + endpoint@1:
> + properties:
> + data-lanes:
> + maxItems: 1
> + required:
> + - endpoint@0
> +
> + port@1:
> + $ref: /schemas/graph.yaml#/properties/port
> + description: Output to the CAMSS CSID controller.
> +
> + required:
> + - port@0
> + - port@1
> +
> +required:
> + - compatible
> + - reg
> + - "#phy-cells"
> + - clocks
> + - clock-names
> + - interrupts
> + - operating-points-v2
> + - power-domains
> + - power-domain-names
> + - vdda-0p9-supply
> + - vdda-1p2-supply
> + - ports
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> + #include <dt-bindings/clock/qcom,x1e80100-camcc.h>
> + #include <dt-bindings/clock/qcom,x1e80100-gcc.h>
> + #include <dt-bindings/power/qcom,rpmhpd.h>
> +
> + phy@ace4000 {
> + compatible = "qcom,x1e80100-csi2-phy";
> + reg = <0x0ace4000 0x2000>;
> + #phy-cells = <1>;
> +
> + clocks = <&camcc CAM_CC_CSIPHY0_CLK>,
> + <&camcc CAM_CC_CSI0PHYTIMER_CLK>,
> + <&camcc CAM_CC_CORE_AHB_CLK>;
> + clock-names = "core",
> + "timer",
> + "ahb";
> +
> + interrupts = <GIC_SPI 477 IRQ_TYPE_EDGE_RISING>;
> +
> + operating-points-v2 = <&csiphy_opp_table>;
> +
> + power-domains = <&camcc CAM_CC_TITAN_TOP_GDSC>,
> + <&rpmhpd RPMHPD_MMCX>,
> + <&rpmhpd RPMHPD_MX>;
> + power-domain-names = "top",
> + "mmcx",
> + "mx";
> +
> + vdda-0p9-supply = <&vreg_l2c_0p9>;
> + vdda-1p2-supply = <&vreg_l1c_1p2>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + csiphy0_in: endpoint {
> + data-lanes = <0 1 2 3>;
data-lanes values has not been corrected in accordance to linux-media
requirements.
> + remote-endpoint = <&sensor_out>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + csiphy0_out: endpoint {
> + remote-endpoint = <&csid_in>;
> + };
> + };
> + };
> +
> + csiphy_opp_table: opp-table {
> + compatible = "operating-points-v2";
> +
> + opp-300000000 {
> + opp-hz = /bits/ 64 <300000000>;
> + required-opps = <&rpmhpd_opp_low_svs_d1>,
> + <&rpmhpd_opp_low_svs_d1>;
> + };
> + };
> + };
>
--
Best wishes,
Vladimir
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 1/3] dt-bindings: phy: qcom,sc8280xp-qmp-pcie-phy: Add SM8475 QMP PHY
From: Krzysztof Kozlowski @ 2026-07-21 8:19 UTC (permalink / raw)
To: Esteban Urrutia
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, linux-phy, devicetree, linux-kernel,
phone-devel
In-Reply-To: <20260715-sm8475-bup-pcie-v2-1-48bd91a19abf@proton.me>
On Wed, Jul 15, 2026 at 02:37:46AM -0400, Esteban Urrutia wrote:
> SM8450 init sequence for this PHY varies significantly and can't be reused
> in SM8475.
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 1/3] dt-bindings: phy: qcom,sc8280xp-qmp-usb43dp-phy: Add SM8475 QMP PHY
From: Krzysztof Kozlowski @ 2026-07-21 8:22 UTC (permalink / raw)
To: Esteban Urrutia
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, linux-phy, devicetree, linux-kernel,
phone-devel
In-Reply-To: <20260715-sm8475-bup-usbss-v2-1-2d8def39b190@proton.me>
On Wed, Jul 15, 2026 at 03:06:54AM -0400, Esteban Urrutia wrote:
> SM8450 init sequence for this PHY varies significantly and can't be used in
> SM8475.
> Add bindings for the PHY found in this SoC.
>
> Signed-off-by: Esteban Urrutia <esteuwu@proton.me>
> ---
> Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml | 1 +
> 1 file changed, 1 insertion(+)
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 v3 phy-next 2/8] soc: fsl: guts: add a global structure to hold state
From: Michael Walle @ 2026-07-21 8:44 UTC (permalink / raw)
To: Vladimir Oltean
Cc: devicetree, robh, conor+dt, vkoul, neil.armstrong, olteanv,
linux-phy
In-Reply-To: <20260720145724.acega7erguyufxd3@skbuf>
[-- Attachment #1.1: Type: text/plain, Size: 2871 bytes --]
Hi Vladimir,
On Mon Jul 20, 2026 at 4:57 PM CEST, Vladimir Oltean wrote:
> On Mon, Jul 20, 2026 at 05:01:39PM +0300, Vladimir Oltean wrote:
>> On Mon, Jul 20, 2026 at 01:50:49PM +0000, sashiko-bot@kernel.org wrote:
>> > [Severity: High]
>> > Will jumping to err_nomem cause a NULL pointer dereference?
>> >
>> > If the allocation of soc_dev_attr fails, the code now jumps to the error
>> > handling path which dereferences soc_dev_attr to free its members:
>> >
>> > > @@ -269,6 +271,8 @@ static int __init fsl_guts_init(void)
>> > > kfree(soc_dev_attr->revision);
>> > > kfree(soc_dev_attr->serial_number);
>> >
>> > Since soc_dev_attr is NULL when this allocation fails, won't evaluating
>> > soc_dev_attr->revision and other members result in a kernel panic?
>>
>> yeah.
>>
>> I tried to be nice and play with the existing "err_nomem" and "err"
>> error handling labels, but the truth is that a single error cleanup path
>> is just an antipattern that doesn't scale as code becomes more complex.
>>
>> Instead of having a single error handling procedure which needs to
>> carefully fend off from various invalid contexts from all the goto
>> sites, the standard convention is to have an incremental set of labels
>> which undo just the setup that was done up to the goto jump site.
>>
>> I'll refactor fsl_guts_init() to use that convention for v4.
>
> While I was doing this refactoring, I noticed that this code path:
>
> if (soc_data)
> soc_uid = fsl_guts_get_soc_uid(soc_data->sfp_compat,
> soc_data->uid_offset);
> if (soc_uid) {
> soc_dev_attr->serial_number = kasprintf(GFP_KERNEL, "%016llX",
> soc_uid);
> // no kasprintf() NULL return code check here, unlike
> // the rest of the code
It's a long time ago, but it seems to be designed be optional. In
that case a NULL pointer check was omitted, because nothing bad can
happen anyway. Either you'll free the string if != NULL or you don't
free anything.
> }
>
> soc_dev = soc_device_register(soc_dev_attr);
> if (IS_ERR(soc_dev)) {
> ret = PTR_ERR(soc_dev);
> goto err;
> }
>
> proceeds with soc_device_register() even if fsl_guts_get_soc_uid() was
> able to get a soc unique id from the security fuse processor, but we
> fail to print that string to the soc_dev_attr->serial_number variable.
>
> I don't see anywhere mentioned in commit 786dde1e59d7 ("soc: fsl: guts:
> add serial_number support") that this would be intentional, so it can
> just as well be an omission.
>
> Is it OK if I replace the silent failure with a loud failure of the
> entire fsl_guts_init()? The code executes only if soc_uid is non-zero
> anyway.
>
> kasprintf() fails only for memory related reasons.
I don't have a strong opinion. If you ever get that error, something
is seriously bad anyway.
-michael
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 297 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 1/2] dt-bindings: phy: qcom,m31-eusb2-phy: Document M31 eUSB2 PHY for Maili
From: Krzysztof Kozlowski @ 2026-07-21 9:10 UTC (permalink / raw)
To: Krishna Kurapati
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Wesley Cheng, linux-arm-msm, linux-phy, devicetree,
linux-kernel
In-Reply-To: <20260713-maili-usb-phy-v1-1-3285da11f148@oss.qualcomm.com>
On Mon, Jul 13, 2026 at 06:38:28PM +0530, Krishna Kurapati wrote:
> Document the M31 eUSB2 PHY for Maili which handles the USB2 path. Use
> fallback to indicate the compatibility of the M31 eUSB2 PHY on Maili
> with that on the SM8750.
>
> Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>
> ---
> Documentation/devicetree/bindings/phy/qcom,m31-eusb2-phy.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
Please kindly postpone posting anything for Hawi or Maili, because there
is no DTS user available and previous Kaanapali, Glymur, Maili and Hawi
postings without DTS came with somehow easy to spot issues if DTS was
available. Contributor did not spot them even though they had DTS
internally. OTOH, I cannot spot them, because DTS is not available to me
easily. I raised this internally hoping it can be somehow solved (if
Qualcomm wants to post bindings without any users).
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 v12 00/12] SPMI: Implement sub-devices and migrate drivers
From: AngeloGioacchino Del Regno @ 2026-07-21 9:26 UTC (permalink / raw)
To: Andy Shevchenko
Cc: jic23, sboyd, dlechner, nuno.sa, andy, arnd, gregkh, srini, vkoul,
neil.armstrong, sre, krzk, dmitry.baryshkov, quic_wcheng,
melody.olvera, quic_nsekar, ivo.ivanov.ivanov1, abelvesa,
luca.weiss, konrad.dybcio, mitltlatltl, krishna.kurapati,
linux-arm-msm, linux-iio, linux-kernel, linux-phy, linux-pm,
kernel
In-Reply-To: <akz8iRW2emM7B7n7@ashevche-desk.local>
On 7/7/26 15:18, Andy Shevchenko wrote:
> On Tue, Jul 07, 2026 at 01:18:17PM +0200, AngeloGioacchino Del Regno wrote:
>> Changes in v12:
>> - Removed call to of_node_put() for failure as it's being already
>> done in spmi_dev_release(), as pointed out by Sashiko
>> - Fixed usage of the new helper in all users (it's too hot today, sorry)
>
> You have send two versions in a row and effectively ignored my comment.
> What is going on? Perhaps you need to slow down, find a cool place and
> start over?
>
Andy, yeah, sorry about that.
It got pretty hot here in Italy, and I admit I was rushing way too much with those
patches.
I'm fixing your comment and sending a v13 right now.
Thanks,
Angelo
--
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