* Re: [PATCH v5 11/24] scsi: ufs: mediatek: Rework probe function
From: Krzysztof Kozlowski @ 2026-01-09 7:24 UTC (permalink / raw)
To: Peter Wang (王信友), chu.stanley@gmail.com,
robh@kernel.org, Chunfeng Yun (云春峰),
kishon@kernel.org, James.Bottomley@HansenPartnership.com,
bvanassche@acm.org, AngeloGioacchino Del Regno,
neil.armstrong@linaro.org, conor+dt@kernel.org,
Chaotian Jing (井朝天), lgirdwood@gmail.com,
nicolas.frattaroli@collabora.com, vkoul@kernel.org,
krzk+dt@kernel.org, alim.akhtar@samsung.com,
p.zabel@pengutronix.de, matthias.bgg@gmail.com,
avri.altman@wdc.com, martin.petersen@oracle.com,
broonie@kernel.org
Cc: linux-scsi@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-phy@lists.infradead.org, linux-mediatek@lists.infradead.org,
Louis-Alexis Eyraud, kernel@collabora.com
In-Reply-To: <dd2eba99adaddf7517f06acf7805d32e261fafa4.camel@mediatek.com>
On 09/01/2026 07:22, Peter Wang (王信友) wrote:
> On Thu, 2026-01-08 at 13:25 +0100, Krzysztof Kozlowski wrote:
>>
>> Please provide here reason, e.g. undocumented ABI. Normally I would
>> ask
>> about ABI impact, but considering this is was just copied from some
>> downstream code I would just not care.
>>
>
> Is it sufficient for us to supplement the ABI document?
> This ABI might affect the ability to reset and recover after
> an UFS error in upstream world.
In normal case yes, but I cannot imagine arguments justifying your usage
of TI properties. Basically it would not pass review.
Best regards,
Krzysztof
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH 5/5] PCI: qcom: enable Link retain logic for Hamoa
From: Krishna Chaitanya Chundru @ 2026-01-09 7:21 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Philipp Zabel, Jingoo Han,
Manivannan Sadhasivam, Lorenzo Pieralisi,
Krzysztof Wilczyński, Rob Herring, Bjorn Helgaas
Cc: linux-arm-msm, linux-phy, linux-kernel, linux-pci,
Krishna Chaitanya Chundru
In-Reply-To: <20260109-link_retain-v1-0-7e6782230f4b@oss.qualcomm.com>
The Hamoa platform supports keeping the PCIe link active across
bootloader and kernel handoff. To take advantage of this, introduce a
specific configuration (cfg_x1e80100) with link_retain = true and
update the device match table to use it.
Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
---
drivers/pci/controller/dwc/pcie-qcom.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c
index bdd5bdb462c5f6814c8311be96411173456b6b14..975671a0dd4757074600d5a0966e94220bb18d8c 100644
--- a/drivers/pci/controller/dwc/pcie-qcom.c
+++ b/drivers/pci/controller/dwc/pcie-qcom.c
@@ -1531,6 +1531,12 @@ static const struct qcom_pcie_cfg cfg_sc8280xp = {
.no_l0s = true,
};
+static const struct qcom_pcie_cfg cfg_x1e80100 = {
+ .ops = &ops_1_21_0,
+ .no_l0s = true,
+ .link_retain = true,
+};
+
static const struct qcom_pcie_cfg cfg_fw_managed = {
.firmware_managed = true,
};
@@ -2168,7 +2174,7 @@ static const struct of_device_id qcom_pcie_match[] = {
{ .compatible = "qcom,pcie-sm8450-pcie0", .data = &cfg_1_9_0 },
{ .compatible = "qcom,pcie-sm8450-pcie1", .data = &cfg_1_9_0 },
{ .compatible = "qcom,pcie-sm8550", .data = &cfg_1_9_0 },
- { .compatible = "qcom,pcie-x1e80100", .data = &cfg_sc8280xp },
+ { .compatible = "qcom,pcie-x1e80100", .data = &cfg_x1e80100 },
{ }
};
--
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 4/5] PCI: qcom: Add link retention support
From: Krishna Chaitanya Chundru @ 2026-01-09 7:21 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Philipp Zabel, Jingoo Han,
Manivannan Sadhasivam, Lorenzo Pieralisi,
Krzysztof Wilczyński, Rob Herring, Bjorn Helgaas
Cc: linux-arm-msm, linux-phy, linux-kernel, linux-pci,
Krishna Chaitanya Chundru
In-Reply-To: <20260109-link_retain-v1-0-7e6782230f4b@oss.qualcomm.com>
Some platforms keep the PCIe link active across bootloader and kernel
handoff. Reinitializing the controller and toggling PERST# in such cases
is unnecessary if driver doesn't want to do link training again.
Introduce link_retain in both qcom_pcie_cfg and qcom_pcie to
indicate when link retention is supported. During initialization, check
the LTSSM state, if the link is already in L0 or L1 idle and LTSSM is
enabled, set pp.link_retain and skip controller reset, PERST# toggling,
and other post-init steps.
If there is a devicetree property to restrict PCIe data rate and lane
width go with the normal execution instead of link retantion logic.
Configure DBI and ATU base in this scenerio, since bootloader DBI & ATU
base may differ from HLOS one. So use the DBI & ATU provided from the
devicetree.
Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
---
drivers/pci/controller/dwc/pcie-qcom.c | 50 ++++++++++++++++++++++++++++++++--
1 file changed, 47 insertions(+), 3 deletions(-)
diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c
index 9342f9c75f1c3017b55614069a7aa821a6fb8da7..bdd5bdb462c5f6814c8311be96411173456b6b14 100644
--- a/drivers/pci/controller/dwc/pcie-qcom.c
+++ b/drivers/pci/controller/dwc/pcie-qcom.c
@@ -259,12 +259,14 @@ struct qcom_pcie_ops {
* @override_no_snoop: Override NO_SNOOP attribute in TLP to enable cache
* snooping
* @firmware_managed: Set if the Root Complex is firmware managed
+ * @link_retain: Set if controller supports link retain from bootloader
*/
struct qcom_pcie_cfg {
const struct qcom_pcie_ops *ops;
bool override_no_snoop;
bool firmware_managed;
bool no_l0s;
+ bool link_retain;
};
struct qcom_pcie_port {
@@ -965,6 +967,35 @@ static int qcom_pcie_get_resources_2_7_0(struct qcom_pcie *pcie)
return 0;
}
+static bool qcom_pcie_check_link_retain(struct qcom_pcie *pcie)
+{
+ u32 cap, speed, val, ltssm, width;
+ struct dw_pcie *pci = pcie->pci;
+ u8 offset;
+
+ val = readl(pcie->parf + PARF_LTSSM);
+ ltssm = val & 0x1f;
+ if ((val & LTSSM_EN) &&
+ (ltssm == DW_PCIE_LTSSM_L0 || ltssm == DW_PCIE_LTSSM_L1_IDLE)) {
+ qcom_pcie_configure_dbi_atu_base(pcie);
+
+ offset = dw_pcie_find_capability(pci, PCI_CAP_ID_EXP);
+ cap = dw_pcie_readl_dbi(pci, offset + PCI_EXP_LNKCAP);
+ speed = FIELD_GET(PCI_EXP_LNKCAP_SLS, cap);
+ width = dw_pcie_link_get_max_link_width(pci);
+
+ if (pci->max_link_speed > 0 && speed < pci->max_link_speed)
+ return false;
+
+ if (pci->num_lanes > 0 && width > pci->num_lanes)
+ return false;
+
+ return true;
+ }
+
+ return false;
+}
+
static int qcom_pcie_init_2_7_0(struct qcom_pcie *pcie)
{
struct qcom_pcie_resources_2_7_0 *res = &pcie->res.v2_7_0;
@@ -983,6 +1014,14 @@ static int qcom_pcie_init_2_7_0(struct qcom_pcie *pcie)
if (ret < 0)
goto err_disable_regulators;
+ if (pcie->cfg->link_retain) {
+ pci->pp.link_retain = qcom_pcie_check_link_retain(pcie);
+ if (pci->pp.link_retain) {
+ dev_info(dev, "Enabling link retain\n");
+ return 0;
+ }
+ }
+
ret = reset_control_assert(res->rst);
if (ret) {
dev_err(dev, "reset assert failed (%d)\n", ret);
@@ -1043,6 +1082,9 @@ static int qcom_pcie_post_init_2_7_0(struct qcom_pcie *pcie)
{
const struct qcom_pcie_cfg *pcie_cfg = pcie->cfg;
+ if (pcie->pci->pp.link_retain)
+ return 0;
+
if (pcie_cfg->override_no_snoop)
writel(WR_NO_SNOOP_OVERRIDE_EN | RD_NO_SNOOP_OVERRIDE_EN,
pcie->parf + PARF_NO_SNOOP_OVERRIDE);
@@ -1300,12 +1342,13 @@ static int qcom_pcie_host_init(struct dw_pcie_rp *pp)
struct qcom_pcie *pcie = to_qcom_pcie(pci);
int ret;
- qcom_ep_reset_assert(pcie);
-
ret = pcie->cfg->ops->init(pcie);
if (ret)
return ret;
+ if (!pp->link_retain)
+ qcom_ep_reset_assert(pcie);
+
ret = qcom_pcie_phy_power_on(pcie);
if (ret)
goto err_deinit;
@@ -1316,7 +1359,8 @@ static int qcom_pcie_host_init(struct dw_pcie_rp *pp)
goto err_disable_phy;
}
- qcom_ep_reset_deassert(pcie);
+ if (!pp->link_retain)
+ qcom_ep_reset_deassert(pcie);
if (pcie->cfg->ops->config_sid) {
ret = pcie->cfg->ops->config_sid(pcie);
--
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 3/5] PCI: qcom: Keep PERST# GPIO state as-is during probe
From: Krishna Chaitanya Chundru @ 2026-01-09 7:21 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Philipp Zabel, Jingoo Han,
Manivannan Sadhasivam, Lorenzo Pieralisi,
Krzysztof Wilczyński, Rob Herring, Bjorn Helgaas
Cc: linux-arm-msm, linux-phy, linux-kernel, linux-pci,
Krishna Chaitanya Chundru
In-Reply-To: <20260109-link_retain-v1-0-7e6782230f4b@oss.qualcomm.com>
The PERST# signal is used to reset PCIe devices. Currently, the driver
requests the GPIO with GPIOD_OUT_HIGH, which forces the line high
during probe. This can unintentionally assert reset early, breaking
link retention or causing unexpected device behavior.
Change the request to use GPIOD_ASIS so the driver preserves the
existing state configured by the bootloader or firmware. This allows
platforms that manage PERST# externally to maintain proper reset
sequencing.
Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
---
drivers/pci/controller/dwc/pcie-qcom.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c
index 7b92e7a1c0d9364a9cefe1450818f9cbfc7fd3ac..9342f9c75f1c3017b55614069a7aa821a6fb8da7 100644
--- a/drivers/pci/controller/dwc/pcie-qcom.c
+++ b/drivers/pci/controller/dwc/pcie-qcom.c
@@ -1711,7 +1711,7 @@ static int qcom_pcie_parse_port(struct qcom_pcie *pcie, struct device_node *node
int ret;
reset = devm_fwnode_gpiod_get(dev, of_fwnode_handle(node),
- "reset", GPIOD_OUT_HIGH, "PERST#");
+ "reset", GPIOD_ASIS, "PERST#");
if (IS_ERR(reset))
return PTR_ERR(reset);
@@ -1772,7 +1772,7 @@ static int qcom_pcie_parse_legacy_binding(struct qcom_pcie *pcie)
if (IS_ERR(phy))
return PTR_ERR(phy);
- reset = devm_gpiod_get_optional(dev, "perst", GPIOD_OUT_HIGH);
+ reset = devm_gpiod_get_optional(dev, "perst", GPIOD_ASIS);
if (IS_ERR(reset))
return PTR_ERR(reset);
--
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 2/5] PCI: dwc: Add support for retaining link during host init
From: Krishna Chaitanya Chundru @ 2026-01-09 7:21 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Philipp Zabel, Jingoo Han,
Manivannan Sadhasivam, Lorenzo Pieralisi,
Krzysztof Wilczyński, Rob Herring, Bjorn Helgaas
Cc: linux-arm-msm, linux-phy, linux-kernel, linux-pci,
Krishna Chaitanya Chundru
In-Reply-To: <20260109-link_retain-v1-0-7e6782230f4b@oss.qualcomm.com>
Some platforms keep the PCIe link up across bootloader and kernel
handoff. In such cases, reinitializing the root complex is unnecessary
if the DWC glue drivers wants to retain the PCIe link.
Introduce a link_retain flag in struct dw_pcie_rp to indicate that
the link should be preserved. When this flag is set by DWC glue drivers,
skip dw_pcie_setup_rc() and only initialize MSI, avoiding redundant
configuration steps.
Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
---
drivers/pci/controller/dwc/pcie-designware-host.c | 11 ++++++++---
drivers/pci/controller/dwc/pcie-designware.h | 1 +
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c b/drivers/pci/controller/dwc/pcie-designware-host.c
index 372207c33a857b4c98572bb1e9b61fa0080bc871..d050df3f22e9507749a8f2fedd4c24fca43fb410 100644
--- a/drivers/pci/controller/dwc/pcie-designware-host.c
+++ b/drivers/pci/controller/dwc/pcie-designware-host.c
@@ -655,9 +655,14 @@ int dw_pcie_host_init(struct dw_pcie_rp *pp)
if (ret)
goto err_free_msi;
- ret = dw_pcie_setup_rc(pp);
- if (ret)
- goto err_remove_edma;
+ if (!pp->link_retain) {
+ ret = dw_pcie_setup_rc(pp);
+ if (ret)
+ goto err_remove_edma;
+ } else {
+ dw_pcie_msi_init(pp);
+ }
+
if (!dw_pcie_link_up(pci)) {
ret = dw_pcie_start_link(pci);
diff --git a/drivers/pci/controller/dwc/pcie-designware.h b/drivers/pci/controller/dwc/pcie-designware.h
index 31685951a080456b8834aab2bf79a36c78f46639..8acab751b66a06e8322e027ab55dc0ecfdcf634c 100644
--- a/drivers/pci/controller/dwc/pcie-designware.h
+++ b/drivers/pci/controller/dwc/pcie-designware.h
@@ -439,6 +439,7 @@ struct dw_pcie_rp {
struct pci_config_window *cfg;
bool ecam_enabled;
bool native_ecam;
+ bool link_retain;
};
struct dw_pcie_ep_ops {
--
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 1/5] phy: qcom: qmp-pcie: Skip PHY reset if already up
From: Krishna Chaitanya Chundru @ 2026-01-09 7:21 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Philipp Zabel, Jingoo Han,
Manivannan Sadhasivam, Lorenzo Pieralisi,
Krzysztof Wilczyński, Rob Herring, Bjorn Helgaas
Cc: linux-arm-msm, linux-phy, linux-kernel, linux-pci,
Krishna Chaitanya Chundru
In-Reply-To: <20260109-link_retain-v1-0-7e6782230f4b@oss.qualcomm.com>
If the bootloader has already powered up the PCIe PHY, doing a full
reset and waiting for it to come up again slows down boot time.
Add a check for PHY status and skip the reset steps when the PHY is
already active. In this case, only enable the required resources during
power-on. This works alongside the existing logic that skips the init
sequence.
Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
---
drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 28 ++++++++++++++++++----------
1 file changed, 18 insertions(+), 10 deletions(-)
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
index 86b1b7e2da86a8675e3e48e90b782afb21cafd77..c93e613cf80b2612f0f225fa2125f78dbec1a33f 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
@@ -3153,6 +3153,7 @@ struct qmp_pcie {
const struct qmp_phy_cfg *cfg;
bool tcsr_4ln_config;
bool skip_init;
+ bool skip_reset;
void __iomem *serdes;
void __iomem *pcs;
@@ -4537,6 +4538,9 @@ static int qmp_pcie_init(struct phy *phy)
qphy_checkbits(pcs, cfg->regs[QPHY_START_CTRL], SERDES_START | PCS_START) &&
qphy_checkbits(pcs, cfg->regs[QPHY_PCS_POWER_DOWN_CONTROL], cfg->pwrdn_ctrl);
+ qmp->skip_reset = qmp->skip_init && !qphy_checkbits(pcs, cfg->regs[QPHY_PCS_STATUS],
+ cfg->phy_status);
+
if (!qmp->skip_init && !cfg->tbls.serdes_num) {
dev_err(qmp->dev, "Init sequence not available\n");
return -ENODATA;
@@ -4560,13 +4564,15 @@ static int qmp_pcie_init(struct phy *phy)
}
}
- ret = reset_control_assert(qmp->nocsr_reset);
- if (ret) {
- dev_err(qmp->dev, "no-csr reset assert failed\n");
- goto err_assert_reset;
- }
+ if (!qmp->skip_reset) {
+ ret = reset_control_assert(qmp->nocsr_reset);
+ if (ret) {
+ dev_err(qmp->dev, "no-csr reset assert failed\n");
+ goto err_assert_reset;
+ }
- usleep_range(200, 300);
+ usleep_range(200, 300);
+ }
if (!qmp->skip_init) {
ret = reset_control_bulk_deassert(cfg->num_resets, qmp->resets);
@@ -4641,10 +4647,12 @@ static int qmp_pcie_power_on(struct phy *phy)
if (ret)
return ret;
- ret = reset_control_deassert(qmp->nocsr_reset);
- if (ret) {
- dev_err(qmp->dev, "no-csr reset deassert failed\n");
- goto err_disable_pipe_clk;
+ if (!qmp->skip_reset) {
+ ret = reset_control_deassert(qmp->nocsr_reset);
+ if (ret) {
+ dev_err(qmp->dev, "no-csr reset deassert failed\n");
+ goto err_disable_pipe_clk;
+ }
}
if (qmp->skip_init)
--
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 0/5] PCI: qcom: Add link retention support
From: Krishna Chaitanya Chundru @ 2026-01-09 7:21 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Philipp Zabel, Jingoo Han,
Manivannan Sadhasivam, Lorenzo Pieralisi,
Krzysztof Wilczyński, Rob Herring, Bjorn Helgaas
Cc: linux-arm-msm, linux-phy, linux-kernel, linux-pci,
Krishna Chaitanya Chundru
This patch series introduces support for retaining the PCIe link across
bootloader and kernel handoff on Qualcomm platforms, specifically
X1E80100. The goal is to reduce boot time and avoid unnecessary link
reinitialization when the link is already up.
We are not enabling link retantion support for all the targets, as there
is no guarantee that the bootloader on all targets has initialized the
PCIe link in max supported speed. So we are enabling for hamoa & glymur
target only for now based on the config flag.
If the link is up and has link_retain is set to true in the
ithe driver config data then enable retain logic in the controller.
In phy as we already have skip init logic, the phy patch uses same
assumption that if there is phy no csr and bootloader has done the init
then driver can skip resetting the phy when phy status indicates it is
up.
Problem:-
1) As part of late init calls of clock & GENPD(for power domains) the
framework is disabling all the unvoted resources by that time and also
there is no sync state to keep them enabled till the probe is completed.
Due to dependencies with regulators and phy, qcom pcie probe is happening
after late init which is causing the resources(clocks & power domains) to
be off which causes the link to go down. To avoid this we need to use these
two kernel command line arguments (clk_ignore_unused & pd_ignore_unused)
to skip disabling clocks and gendp power domains as part of late init
for initial version. Once it is resolved we can avoid those kernel command
line arguments.
Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
---
Krishna Chaitanya Chundru (5):
phy: qcom: qmp-pcie: Skip PHY reset if already up
PCI: dwc: Add support for retaining link during host init
PCI: qcom: Keep PERST# GPIO state as-is during probe
PCI: qcom: Add link retention support
PCI: qcom: enable Link retain logic for Hamoa
drivers/pci/controller/dwc/pcie-designware-host.c | 11 ++--
drivers/pci/controller/dwc/pcie-designware.h | 1 +
drivers/pci/controller/dwc/pcie-qcom.c | 62 ++++++++++++++++++++---
drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 28 ++++++----
4 files changed, 83 insertions(+), 19 deletions(-)
---
base-commit: fc065cadc7ed048bedbb23cb6b7c4475198f431c
change-id: 20251001-link_retain-f181307947e4
Best regards,
--
Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v5 11/24] scsi: ufs: mediatek: Rework probe function
From: Peter Wang (王信友) @ 2026-01-09 6:22 UTC (permalink / raw)
To: chu.stanley@gmail.com, robh@kernel.org,
Chunfeng Yun (云春峰), kishon@kernel.org,
James.Bottomley@HansenPartnership.com, bvanassche@acm.org,
AngeloGioacchino Del Regno, neil.armstrong@linaro.org,
conor+dt@kernel.org, Chaotian Jing (井朝天),
lgirdwood@gmail.com, nicolas.frattaroli@collabora.com,
vkoul@kernel.org, krzk+dt@kernel.org, alim.akhtar@samsung.com,
p.zabel@pengutronix.de, krzk@kernel.org, matthias.bgg@gmail.com,
avri.altman@wdc.com, martin.petersen@oracle.com,
broonie@kernel.org
Cc: linux-scsi@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-phy@lists.infradead.org, linux-mediatek@lists.infradead.org,
Louis-Alexis Eyraud, kernel@collabora.com
In-Reply-To: <81ed17eb-2170-4e97-b56d-488b5335ff5c@kernel.org>
On Thu, 2026-01-08 at 13:25 +0100, Krzysztof Kozlowski wrote:
>
> Please provide here reason, e.g. undocumented ABI. Normally I would
> ask
> about ABI impact, but considering this is was just copied from some
> downstream code I would just not care.
>
Is it sufficient for us to supplement the ABI document?
This ABI might affect the ability to reset and recover after
an UFS error in upstream world.
> Mediatek should really stop and rethink their upstream process.
>
> Best regards,
> Krzysztof
Yes, you are right.
MediaTek does have some shortcomings in the upstream process.
We will make improvements.
Thanks.
Peter
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v5 12/24] scsi: ufs: mediatek: Remove vendor kernel quirks cruft
From: Peter Wang (王信友) @ 2026-01-09 6:21 UTC (permalink / raw)
To: chu.stanley@gmail.com, robh@kernel.org,
Chunfeng Yun (云春峰), kishon@kernel.org,
James.Bottomley@HansenPartnership.com, bvanassche@acm.org,
AngeloGioacchino Del Regno, neil.armstrong@linaro.org,
conor+dt@kernel.org, Chaotian Jing (井朝天),
lgirdwood@gmail.com, nicolas.frattaroli@collabora.com,
vkoul@kernel.org, krzk+dt@kernel.org, p.zabel@pengutronix.de,
alim.akhtar@samsung.com, matthias.bgg@gmail.com,
avri.altman@wdc.com, martin.petersen@oracle.com,
broonie@kernel.org
Cc: linux-scsi@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-phy@lists.infradead.org, linux-mediatek@lists.infradead.org,
Louis-Alexis Eyraud, kernel@collabora.com
In-Reply-To: <20260108-mt8196-ufs-v5-12-49215157ec41@collabora.com>
On Thu, 2026-01-08 at 11:49 +0100, Nicolas Frattaroli wrote:
> Both ufs_mtk_vreg_fix_vcc and ufs_mtk_vreg_fix_vccqx look like they
> are
> vendor kernel hacks to work around existing downstream device trees.
> Mainline does not need or want them, so remove them.
>
> Reviewed-by: AngeloGioacchino Del Regno
> <angelogioacchino.delregno@collabora.com>
> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
>
Reviewed-by: Peter Wang <peter.wang@mediatek.com>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v4 12/25] scsi: ufs: mediatek: Remove vendor kernel quirks cruft
From: Peter Wang (王信友) @ 2026-01-09 6:20 UTC (permalink / raw)
To: chu.stanley@gmail.com, robh@kernel.org,
Chunfeng Yun (云春峰), kishon@kernel.org,
James.Bottomley@hansenpartnership.com, bvanassche@acm.org,
AngeloGioacchino Del Regno,
Chaotian Jing (井朝天), conor+dt@kernel.org,
lgirdwood@gmail.com, nicolas.frattaroli@collabora.com,
vkoul@kernel.org, krzk+dt@kernel.org, p.zabel@pengutronix.de,
alim.akhtar@samsung.com, neil.armstrong@linaro.org,
matthias.bgg@gmail.com, avri.altman@wdc.com, broonie@kernel.org,
martin.petersen@oracle.com
Cc: linux-scsi@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-phy@lists.infradead.org, linux-mediatek@lists.infradead.org,
Louis-Alexis Eyraud, kernel@collabora.com
In-Reply-To: <13960383.uLZWGnKmhe@workhorse>
On Thu, 2026-01-08 at 10:28 +0100, Nicolas Frattaroli wrote:
> By "one software supporting multiple hardware configurations", do you
> mean one device tree? Because if so, I don't think that's a good
> idea.
Yes.
> Device tree is meant to describe non-enumerable hardware.
I agree.
>
> Even if you want to make it easier for your customers to ship one
> image
> for several SKUs, there's better ways to do this than having drivers
> fix up individual DT nodes. The platform firmware like u-boot can
> choose
> a DT based on differences it can probe. E.g. on Radxa ROCK 5B/5B+
> boards,
> we have u-boot choose between the 5B and 5B+ DT based on whether
> LPDDR5
> is present, as 5B does not have LPDDR5, so as long as u-boot is told
> it's
> either a ROCK 5B or ROCK 5B+, it can figure out which one
> specifically based
> on that. Similarly, for whichever boards this is for, there may be
> differences that can be probed to disambiguate between several SKUs
> of the
> board as long as it's known it must be at least one of those SKUs.
We will adopt this approach. Thank you for your suggestion.
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v4 11/25] scsi: ufs: mediatek: Rework probe function
From: Peter Wang (王信友) @ 2026-01-09 6:18 UTC (permalink / raw)
To: chu.stanley@gmail.com, robh@kernel.org,
Chunfeng Yun (云春峰), kishon@kernel.org,
James.Bottomley@hansenpartnership.com, bvanassche@acm.org,
AngeloGioacchino Del Regno,
Chaotian Jing (井朝天), conor+dt@kernel.org,
lgirdwood@gmail.com, nicolas.frattaroli@collabora.com,
vkoul@kernel.org, krzk+dt@kernel.org, p.zabel@pengutronix.de,
alim.akhtar@samsung.com, neil.armstrong@linaro.org,
matthias.bgg@gmail.com, avri.altman@wdc.com, broonie@kernel.org,
martin.petersen@oracle.com
Cc: linux-scsi@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-phy@lists.infradead.org, linux-mediatek@lists.infradead.org,
Louis-Alexis Eyraud, kernel@collabora.com
In-Reply-To: <5992593.DvuYhMxLoT@workhorse>
On Thu, 2026-01-08 at 10:14 +0100, Nicolas Frattaroli wrote:
> Because it's not described by the binding, and appears to be a
> downstream hack to work around not having the reset controller
> properly described and referred to with a `resets` property.
>
> Even if you were to use `ti,syscon-reset` to describe a reset
> controller, the UFS controller driver should not be searching
> for this compatible. It should access the reset through the
> reset API. The common reset code can then take care of probe
> ordering without every driver reinventing it.
>
>
Can we supplement description in binding and revise the reset
controller flow?
Because if we remove it directly, it may cause problems when an error
occurs?
Thanks.
Peter
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH] phy: qcom: edp: Fix NULL pointer dereference for phy v6 (x1e80100)
From: Val Packett @ 2026-01-09 4:50 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Abel Vesa, Dmitry Baryshkov
Cc: Val Packett, linux-arm-msm, linux-phy, linux-kernel
For Glymur SoC support, the com_clk_fwd_cfg callback was added, and a
stub implementation was added for the v4 of the hardware. However it
was omitted for the v6, causing a NULL pointer dereference oops on
Hamoa/Purwa (X1E/X1P) SoC devices. Fix by adding the appropriate stub.
Fixes: add66a6673bc ("phy: qcom: edp: Add Glymur platform support")
Signed-off-by: Val Packett <val@packett.cool>
---
drivers/phy/qualcomm/phy-qcom-edp.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/phy/qualcomm/phy-qcom-edp.c b/drivers/phy/qualcomm/phy-qcom-edp.c
index 13feab99feec..a17492db21d8 100644
--- a/drivers/phy/qualcomm/phy-qcom-edp.c
+++ b/drivers/phy/qualcomm/phy-qcom-edp.c
@@ -613,6 +613,11 @@ static int qcom_edp_phy_com_resetsm_cntrl_v6(const struct qcom_edp *edp)
val, val & BIT(0), 500, 10000);
}
+static int qcom_edp_com_clk_fwd_cfg_v6(const struct qcom_edp *edp)
+{
+ return 0;
+}
+
static int qcom_edp_com_bias_en_clkbuflr_v6(const struct qcom_edp *edp)
{
/* Turn on BIAS current for PHY/PLL */
@@ -758,6 +763,7 @@ static const struct phy_ver_ops qcom_edp_phy_ops_v6 = {
.com_power_on = qcom_edp_phy_power_on_v6,
.com_resetsm_cntrl = qcom_edp_phy_com_resetsm_cntrl_v6,
.com_bias_en_clkbuflr = qcom_edp_com_bias_en_clkbuflr_v6,
+ .com_clk_fwd_cfg = qcom_edp_com_clk_fwd_cfg_v6,
.com_configure_pll = qcom_edp_com_configure_pll_v6,
.com_configure_ssc = qcom_edp_com_configure_ssc_v6,
};
--
2.51.2
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* Re: [PATCH 8/9] drm/rockchip: Drop ROCKCHIP_IOMMU depend for DRM_ROCKCHIP
From: Chaoyi Chen @ 2026-01-09 1:26 UTC (permalink / raw)
To: Heiko Stuebner, Neil Armstrong, Jessica Zhang, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Sandy Huang, Andy Yan, Vinod Koul, Kishon Vijay Abraham I,
Chaoyi Chen
Cc: dri-devel, devicetree, linux-kernel, linux-arm-kernel,
linux-rockchip, linux-phy
In-Reply-To: <4072834.X9hSmTKtgW@phil>
Hi Heiko,
On 1/9/2026 3:03 AM, Heiko Stuebner wrote:
> Am Donnerstag, 6. November 2025, 03:06:31 Mitteleuropäische Normalzeit schrieb Chaoyi Chen:
>> From: Chaoyi Chen <chaoyi.chen@rock-chips.com>
>>
>> On the RK3506 platform, there is no iommu hardware. And even on
>> platform that have iommu hardware, it should be possible to use
>> VOP without enabling iommu. In this case, a contiguous memory
>> space like CMA should be used.
>>
>> So this patch removes the dependency on ROCKCHIP_IOMMU.
>>
>> Signed-off-by: Chaoyi Chen <chaoyi.chen@rock-chips.com>
>> ---
>> drivers/gpu/drm/rockchip/Kconfig | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
>> index b7b025814e72..a056d419190c 100644
>> --- a/drivers/gpu/drm/rockchip/Kconfig
>> +++ b/drivers/gpu/drm/rockchip/Kconfig
>> @@ -1,7 +1,8 @@
>> # SPDX-License-Identifier: GPL-2.0-only
>> config DRM_ROCKCHIP
>> tristate "DRM Support for Rockchip"
>> - depends on DRM && ROCKCHIP_IOMMU
>> + depends on DRM
>> + depends on ROCKCHIP_IOMMU || !ROCKCHIP_IOMMU
>
> I don't really understand this yes+no line :-)
>
> Can't you just
> - drop the dependency altogether
> or
> - do a depends on ROCKCHIP_IOMMU if ARM64
>
>
This trick is called optional-dependencies [0]. In addition to the
familiar depends on ROCKCHIP_IOMMU part, the newly added !ROCKCHIP_IOMMU
ensures that DRM_ROCKCHIP can still be built even when ROCKCHIP_IOMMU
is not build.
[0]: https://docs.kernel.org/kbuild/kconfig-language.html#optional-dependencies
If we just:
- drop the dependency altogether
When IOMMU is enabled, the dependency relationship cannot be handled
correctly. For example, the following configuration is possible:
ROCKCHIP_IOMMU=m, DRM_ROCKCHIP=y, which leads to a build failure.
- do a depends on ROCKCHIP_IOMMU if ARM64
This changes the semantics. On arm64 we should also be able to work
without IOMMU being enabled.
--
Best,
Chaoyi
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v3 9/9] phy: ti: phy-j721e-wiz: convert from round_rate() to determine_rate()
From: Brian Masney @ 2026-01-08 21:23 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Vinod Koul, Kishon Vijay Abraham I, Chun-Kuang Hu, Philipp Zabel,
Chunfeng Yun, Matthias Brugger, AngeloGioacchino Del Regno,
Heiko Stuebner, Neil Armstrong, Stephen Boyd, Maxime Ripard,
linux-clk, linux-phy, linux-kernel, dri-devel, linux-mediatek,
linux-arm-kernel, linux-rockchip
In-Reply-To: <aVurM1XRqiYlzi1B@redhat.com>
Hi Geert,
On Mon, Jan 05, 2026 at 07:14:43AM -0500, Brian Masney wrote:
> On Mon, Dec 29, 2025 at 11:18:52AM +0100, Geert Uytterhoeven wrote:
> > Hi Brian,
> >
> > On Fri, 12 Dec 2025 at 00:21, Brian Masney <bmasney@redhat.com> wrote:
> > > The round_rate() clk ops is deprecated, so migrate this driver from
> > > round_rate() to determine_rate() using the Coccinelle semantic patch
> > > on the cover letter of this series.
> > >
> > > Signed-off-by: Brian Masney <bmasney@redhat.com>
> >
> > Thanks for your patch, which is now commit 27287e3b52b5954b ("phy:
> > ti: phy-j721e-wiz: convert from round_rate() to determine_rate()")
> > in phy/next
> >
> > > --- a/drivers/phy/ti/phy-j721e-wiz.c
> > > +++ b/drivers/phy/ti/phy-j721e-wiz.c
> > > @@ -934,12 +934,15 @@ static unsigned long wiz_clk_div_recalc_rate(struct clk_hw *hw,
> > > return divider_recalc_rate(hw, parent_rate, val, div->table, 0x0, 2);
> > > }
> > >
> > > -static long wiz_clk_div_round_rate(struct clk_hw *hw, unsigned long rate,
> > > - unsigned long *prate)
> > > +static int wiz_clk_div_determine_rate(struct clk_hw *hw,
> > > + struct clk_rate_request *req)
> > > {
> > > struct wiz_clk_divider *div = to_wiz_clk_div(hw);
> > >
> > > - return divider_round_rate(hw, rate, prate, div->table, 2, 0x0);
> > > + req->rate = divider_round_rate(hw, req->rate, &req->best_parent_rate,
> > > + div->table, 2, 0x0);
> >
> > Is this correct? divider_round_rate() can return a negative error code
> > (from divider_ro_determine_rate()), which is not handled here?
> >
> > Looks like several other users of divider_round_rate() use this
> > same logic, and thus are affected, too.
>
> Thanks for the review! You are correct that this is a bug.
>
> I had planned once round_rate is removed from the clk core to post a
> series to remove divider_round_rate() and divider_ro_round_rate() (plus
> the _parent functions) since they call the corresponding determine_rate
> functions. I'll bump that up on my todo list this week.
I posted a series that fixes the issue you identified, plus removes
those deprecated APIs all in one go.
https://lore.kernel.org/linux-clk/20260108-clk-divider-round-rate-v1-0-535a3ed73bf3@redhat.com/T/#t
Brian
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH 25/27] phy: ti: phy-j721e-wiz: convert from divider_round_rate() to divider_determine_rate()
From: Brian Masney @ 2026-01-08 21:16 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd
Cc: linux-clk, linux-kernel, Brian Masney, Vinod Koul, Neil Armstrong,
linux-phy
In-Reply-To: <20260108-clk-divider-round-rate-v1-0-535a3ed73bf3@redhat.com>
The divider_round_rate() function is now deprecated, so let's migrate
to divider_determine_rate() instead so that this deprecated API can be
removed.
Note that when the main function itself was migrated to use
determine_rate, this was mistakenly converted to:
req->rate = divider_round_rate(...)
This is invalid in the case when an error occurs since it can set the
rate to a negative value.
Fixes: 27287e3b52b5 ("phy: ti: phy-j721e-wiz: convert from round_rate() to determine_rate()")
Signed-off-by: Brian Masney <bmasney@redhat.com>
---
To: Vinod Koul <vkoul@kernel.org>
Cc: Neil Armstrong <neil.armstrong@linaro.org>
Cc: linux-phy@lists.infradead.org
---
drivers/phy/ti/phy-j721e-wiz.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/phy/ti/phy-j721e-wiz.c b/drivers/phy/ti/phy-j721e-wiz.c
index 12a19bf2875c601c60ff5559e1554274ee215918..6e9ecb88dc8b7842745486ae8ad57f82563d6711 100644
--- a/drivers/phy/ti/phy-j721e-wiz.c
+++ b/drivers/phy/ti/phy-j721e-wiz.c
@@ -940,10 +940,7 @@ static int wiz_clk_div_determine_rate(struct clk_hw *hw,
{
struct wiz_clk_divider *div = to_wiz_clk_div(hw);
- req->rate = divider_round_rate(hw, req->rate, &req->best_parent_rate,
- div->table, 2, 0x0);
-
- return 0;
+ return divider_determine_rate(hw, req, div->table, 2, 0x0);
}
static int wiz_clk_div_set_rate(struct clk_hw *hw, unsigned long rate,
--
2.52.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH 00/27] clk: remove deprecated API divider_round_rate() and friends
From: Brian Masney @ 2026-01-08 21:16 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd
Cc: linux-clk, linux-kernel, Brian Masney, Chen Wang, Inochi Amaoto,
sophgo, Chen-Yu Tsai, Maxime Ripard, Jernej Skrabec,
Samuel Holland, linux-arm-kernel, linux-sunxi, Alexandre Belloni,
linux-rtc, Andreas Färber, Manivannan Sadhasivam,
linux-actions, Keguang Zhang, linux-mips, Taichi Sugaya,
Takao Orito, Jacky Huang, Shan-Chun Hung, Vladimir Zapolskiy,
Piotr Wojtaszczyk, Bjorn Andersson, linux-arm-msm, Orson Zhai,
Baolin Wang, Chunyan Zhang, Maxime Coquelin, Alexandre Torgue,
linux-stm32, Michal Simek, Rob Clark, Dmitry Baryshkov,
David Airlie, Simona Vetter, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, dri-devel, freedreno, Vinod Koul,
Neil Armstrong, linux-phy
Here's a series that gets rid of the deprecated APIs
divider_round_rate(), divider_round_rate_parent(), and
divider_ro_round_rate_parent() since these functions are just wrappers
for the determine_rate variant.
Note that when I converted some of these drivers from round_rate to
determine_rate, this was mistakenly converted to the following in some
cases:
req->rate = divider_round_rate(...)
This is invalid in the case when an error occurs since it can set the
rate to a negative value. So this series fixes those bugs and removes
the deprecated APIs all in one go.
Three of the patches ended up being a more complicated migration, and I
put them as the first three patches in this series (clk: sophgo:
cv18xx-ip), (clk: sunxi-ng), and (rtc: ac100). The remaining patches I
feel are all straight forward.
Merge strategy
==============
Only three of the patches are outside of drivers/clk (drm/msm, phy, and
rtc). For simplicity, I think it would be easiest if Stephen takes this
whole series through the clk tree. Subsystem maintainers please leave an
Acked-by for Stephen. Thanks!
Signed-off-by: Brian Masney <bmasney@redhat.com>
---
Brian Masney (27):
clk: sophgo: cv18xx-ip: convert from divider_round_rate() to divider_determine_rate()
clk: sunxi-ng: convert from divider_round_rate_parent() to divider_determine_rate()
rtc: ac100: convert from divider_round_rate() to divider_determine_rate()
clk: actions: owl-composite: convert from owl_divider_helper_round_rate() to divider_determine_rate()
clk: actions: owl-divider: convert from divider_round_rate() to divider_determine_rate()
clk: bm1880: convert from divider_ro_round_rate() to divider_ro_determine_rate()
clk: bm1880: convert from divider_round_rate() to divider_determine_rate()
clk: hisilicon: clkdivider-hi6220: convert from divider_round_rate() to divider_determine_rate()
clk: loongson1: convert from divider_round_rate() to divider_determine_rate()
clk: milbeaut: convert from divider_ro_round_rate() to divider_ro_determine_rate()
clk: milbeaut: convert from divider_round_rate() to divider_determine_rate()
clk: nuvoton: ma35d1-divider: convert from divider_round_rate() to divider_determine_rate()
clk: nxp: lpc32xx: convert from divider_round_rate() to divider_determine_rate()
clk: qcom: alpha-pll: convert from divider_round_rate() to divider_determine_rate()
clk: qcom: regmap-divider: convert from divider_ro_round_rate() to divider_ro_determine_rate()
clk: qcom: regmap-divider: convert from divider_round_rate() to divider_determine_rate()
clk: sophgo: sg2042-clkgen: convert from divider_round_rate() to divider_determine_rate()
clk: sprd: div: convert from divider_round_rate() to divider_determine_rate()
clk: stm32: stm32-core: convert from divider_ro_round_rate() to divider_ro_determine_rate()
clk: stm32: stm32-core: convert from divider_round_rate_parent() to divider_determine_rate()
clk: versaclock3: convert from divider_round_rate() to divider_determine_rate()
clk: x86: cgu: convert from divider_round_rate() to divider_determine_rate()
clk: zynqmp: divider: convert from divider_round_rate() to divider_determine_rate()
drm/msm/dsi_phy_14nm: convert from divider_round_rate() to divider_determine_rate()
phy: ti: phy-j721e-wiz: convert from divider_round_rate() to divider_determine_rate()
clk: divider: remove divider_ro_round_rate_parent()
clk: divider: remove divider_round_rate() and divider_round_rate_parent()
drivers/clk/actions/owl-composite.c | 11 +--
drivers/clk/actions/owl-divider.c | 17 +---
drivers/clk/actions/owl-divider.h | 5 -
drivers/clk/clk-bm1880.c | 13 +--
drivers/clk/clk-divider.c | 44 ---------
drivers/clk/clk-loongson1.c | 5 +-
drivers/clk/clk-milbeaut.c | 15 +--
drivers/clk/clk-versaclock3.c | 7 +-
drivers/clk/hisilicon/clkdivider-hi6220.c | 6 +-
drivers/clk/nuvoton/clk-ma35d1-divider.c | 7 +-
drivers/clk/nxp/clk-lpc32xx.c | 6 +-
drivers/clk/qcom/clk-alpha-pll.c | 21 ++--
drivers/clk/qcom/clk-regmap-divider.c | 16 +--
drivers/clk/sophgo/clk-cv18xx-ip.c | 154 ++++++++++++++++-------------
drivers/clk/sophgo/clk-sg2042-clkgen.c | 15 +--
drivers/clk/sprd/div.c | 6 +-
drivers/clk/stm32/clk-stm32-core.c | 42 +++-----
drivers/clk/sunxi-ng/ccu_div.c | 25 +++--
drivers/clk/sunxi-ng/ccu_mp.c | 26 ++---
drivers/clk/sunxi-ng/ccu_mult.c | 16 +--
drivers/clk/sunxi-ng/ccu_mux.c | 49 +++++----
drivers/clk/sunxi-ng/ccu_mux.h | 8 +-
drivers/clk/sunxi-ng/ccu_nkm.c | 25 ++---
drivers/clk/x86/clk-cgu.c | 6 +-
drivers/clk/zynqmp/divider.c | 5 +-
drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c | 7 +-
drivers/phy/ti/phy-j721e-wiz.c | 5 +-
drivers/rtc/rtc-ac100.c | 75 +++++++-------
include/linux/clk-provider.h | 28 ------
29 files changed, 257 insertions(+), 408 deletions(-)
---
base-commit: f8f97927abf7c12382dddc93a144fc9df7919b77
change-id: 20260107-clk-divider-round-rate-1cfd117b0670
Best regards,
--
Brian Masney <bmasney@redhat.com>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH next] phy: apple: atc: Reset USB2 PHY during probe as well
From: Sven Peter @ 2026-01-08 19:12 UTC (permalink / raw)
To: Janne Grunau, Neal Gompa, Vinod Koul, Neil Armstrong
Cc: asahi, linux-arm-kernel, linux-phy, linux-kernel,
James Calligeros, Sven Peter
Now that the upstream Type-C PHY code is getting broader test coverage we
got reports of USB devices plugged in during boot or those plugged in for
the first time after boot occasionally not working correctly.
This is partially caused by the USB2 parts of the PHY being left in an
unknown state by the previous boot stages. We reset all other parts during
probe but forgot about the USB2 PHY so let's fix that and actually reset
and power off the USB2 PHY as well.
Reported-by: James Calligeros <jcalligeros99@gmail.com>
Reported-by: Janne Grunau <j@jannau.net>
Fixes: 8e98ca1e74db ("phy: apple: Add Apple Type-C PHY")
Signed-off-by: Sven Peter <sven@kernel.org>
---
drivers/phy/apple/atc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/phy/apple/atc.c b/drivers/phy/apple/atc.c
index c8a58ee64b7aad3205df51cf16ae778471ad2c5d..ab0b40b72533f1b3878b646b59820c730239e85c 100644
--- a/drivers/phy/apple/atc.c
+++ b/drivers/phy/apple/atc.c
@@ -2227,6 +2227,7 @@ static int atcphy_probe_finalize(struct apple_atcphy *atcphy)
_atcphy_dwc3_reset_assert(atcphy);
/* Reset atcphy to clear any state potentially left by the bootloader */
+ atcphy_usb2_power_off(atcphy);
atcphy_power_off(atcphy);
atcphy_setup_pipehandler(atcphy);
---
base-commit: add66a6673bc4aacd0ef0f3c4a51271501770b17
change-id: 20260107-atcphy-coldboot-fix-08652d404347
Best regards,
--
Sven Peter <sven@kernel.org>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* Re: (subset) [PATCH 0/9] drm/rockchip: Introduce Rockchip RK3506 VOP
From: Heiko Stuebner @ 2026-01-08 19:04 UTC (permalink / raw)
To: Neil Armstrong, Jessica Zhang, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sandy Huang, Andy Yan,
Vinod Koul, Kishon Vijay Abraham I, Chaoyi Chen
Cc: Heiko Stuebner, dri-devel, devicetree, linux-kernel,
linux-arm-kernel, linux-rockchip, linux-phy, Chaoyi Chen
In-Reply-To: <20251106020632.92-1-kernel@airkyi.com>
On Thu, 06 Nov 2025 10:06:23 +0800, Chaoyi Chen wrote:
> The VOP on rk3506:
> - Support 2 lane MIPI DSI interface, 1.5Gbps/lane.
> - Support RGB interface.
> - Max output resolution is 1280x1280@60fps.
> - WIN1 layer support RGB888/ARGB8888/RGB565.
> - Support Gamma LUT.
>
> [...]
Applied, thanks!
[3/9] dt-bindings: display: rockchip,dw-mipi-dsi: Add compatible for rk3506
commit: 3af0f4d5d433921fa399bbe6396221c8a9985869
[4/9] dt-bindings: display: rockchip,vop: Add compatible for rk3506
commit: 7919273e495b9154cc7e5f7713f002290f4d9597
[7/9] drm/rockchip: dsi: Add support for rk3506
commit: cabeacc7eadc2d0033a2fc7304dfb900f9a32095
[9/9] drm/rockchip: vop: Add support for rk3506
commit: ec27500c8f2b65a3be6ce39a5844d6d246d1b2b0
Best regards,
--
Heiko Stuebner <heiko@sntech.de>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 8/9] drm/rockchip: Drop ROCKCHIP_IOMMU depend for DRM_ROCKCHIP
From: Heiko Stuebner @ 2026-01-08 19:03 UTC (permalink / raw)
To: Neil Armstrong, Jessica Zhang, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sandy Huang, Andy Yan,
Vinod Koul, Kishon Vijay Abraham I, Chaoyi Chen
Cc: dri-devel, devicetree, linux-kernel, linux-arm-kernel,
linux-rockchip, linux-phy, Chaoyi Chen
In-Reply-To: <20251106020632.92-9-kernel@airkyi.com>
Am Donnerstag, 6. November 2025, 03:06:31 Mitteleuropäische Normalzeit schrieb Chaoyi Chen:
> From: Chaoyi Chen <chaoyi.chen@rock-chips.com>
>
> On the RK3506 platform, there is no iommu hardware. And even on
> platform that have iommu hardware, it should be possible to use
> VOP without enabling iommu. In this case, a contiguous memory
> space like CMA should be used.
>
> So this patch removes the dependency on ROCKCHIP_IOMMU.
>
> Signed-off-by: Chaoyi Chen <chaoyi.chen@rock-chips.com>
> ---
> drivers/gpu/drm/rockchip/Kconfig | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
> index b7b025814e72..a056d419190c 100644
> --- a/drivers/gpu/drm/rockchip/Kconfig
> +++ b/drivers/gpu/drm/rockchip/Kconfig
> @@ -1,7 +1,8 @@
> # SPDX-License-Identifier: GPL-2.0-only
> config DRM_ROCKCHIP
> tristate "DRM Support for Rockchip"
> - depends on DRM && ROCKCHIP_IOMMU
> + depends on DRM
> + depends on ROCKCHIP_IOMMU || !ROCKCHIP_IOMMU
I don't really understand this yes+no line :-)
Can't you just
- drop the dependency altogether
or
- do a depends on ROCKCHIP_IOMMU if ARM64
Heiko
> depends on OF
> select DRM_CLIENT_SELECTION
> select DRM_GEM_DMA_HELPER
>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v3] phy: fsl-imx8mq-usb: add debugfs to access control register
From: Andrew Lunn @ 2026-01-08 18:24 UTC (permalink / raw)
To: Xu Yang
Cc: vkoul, neil.armstrong, shawnguo, kernel, festevam, jun.li,
Frank.Li, linux-phy, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260108083641.2119616-1-xu.yang_2@nxp.com>
On Thu, Jan 08, 2026 at 04:36:41PM +0800, Xu Yang wrote:
> The CR port is a simple 16-bit data/address parallel port that is
> provided for on-chip access to the control registers inside the
> USB 3.0 femtoPHY[1]. While access to these registers is not required
> for normal PHY operation, this interface enables you to access
> some of the PHY’s diagnostic features during normal operation or
> to override some basic PHY control signals.
>
> 3 debugfs files are created to read and write control registers,
> all use hexadecimal format:
> ctrl_reg_base: the register offset to write, or the start offset
> to read.
> ctrl_reg_count: how many continuous registers to be read.
> ctrl_reg_value: read to show the continuous registers value from
> the offset in ctrl_reg_base, to ctrl_reg_base
> + ctrl_reg_count - 1, one line for one register.
> when write, override the register at ctrl_reg_base,
> one time can only change one 16bits register.
>
> Link[1]: https://www.synopsys.com/dw/doc.php/phy/usb3.0/femto/phy/x652_usb3_ss14lpp_18_ns/4.07a/dwc_usb3.0_femtophy_ss14lpp_08V18V_x1_databook.pdf
Please don't ignore my comments to V2. Think about the code split
between the generic IP licensed from Synopsys and the vendor specific
code used for integration into the SoC. You want to avoid making a
mess you later need to cleanup because somebody else licensed the same
IP core from Synopsys, and need to put their own vendor specific
integration code around the generic code.
Andrew
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH 2/4] phy: qcom: qmp-usbc: Fix possible NULL-deref on early runtime suspend
From: Loic Poulain @ 2026-01-08 15:49 UTC (permalink / raw)
To: vkoul, kishon
Cc: linux-arm-msm, linux-phy, dmitry.baryshkov, neil.armstrong,
Loic Poulain
In-Reply-To: <20260108154944.211886-1-loic.poulain@oss.qualcomm.com>
There is a small window where the runtime suspend callback may run
after pm_runtime_enable() and before pm_runtime_forbid(). In this
case, a crash occurs because runtime suspend/resume dereferences
qmp->phy pointer, which is not yet initialized:
`if (!qmp->phy->init_count) {`
Use qmp->usb_init_count instead of qmp->phy->init_count to avoid
depending on the possibly uninitialized phy pointer.
Also reorder pm_runtime_enable() and pm_runtime_forbid() to prevent
the window where an unnecessary runtime suspend can occur.
Fixes: 19281571a4d5 ("phy: qcom: qmp-usb: split USB-C PHY driver")
Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
---
drivers/phy/qualcomm/phy-qcom-qmp-usbc.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-usbc.c b/drivers/phy/qualcomm/phy-qcom-qmp-usbc.c
index 5e7fcb26744a..05717ca85c5b 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp-usbc.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp-usbc.c
@@ -690,7 +690,7 @@ static int __maybe_unused qmp_usbc_runtime_suspend(struct device *dev)
dev_vdbg(dev, "Suspending QMP phy, mode:%d\n", qmp->mode);
- if (!qmp->phy->init_count) {
+ if (!qmp->usb_init_count) {
dev_vdbg(dev, "PHY not initialized, bailing out\n");
return 0;
}
@@ -710,7 +710,7 @@ static int __maybe_unused qmp_usbc_runtime_resume(struct device *dev)
dev_vdbg(dev, "Resuming QMP phy, mode:%d\n", qmp->mode);
- if (!qmp->phy->init_count) {
+ if (!qmp->usb_init_count) {
dev_vdbg(dev, "PHY not initialized, bailing out\n");
return 0;
}
@@ -1083,15 +1083,15 @@ static int qmp_usbc_probe(struct platform_device *pdev)
if (ret)
goto err_node_put;
+ /*
+ * Enable runtime PM support, but forbid it by default.
+ * Users can allow it again via the power/control attribute in sysfs.
+ */
pm_runtime_set_active(dev);
+ pm_runtime_forbid(dev);
ret = devm_pm_runtime_enable(dev);
if (ret)
goto err_node_put;
- /*
- * Prevent runtime pm from being ON by default. Users can enable
- * it using power/control in sysfs.
- */
- pm_runtime_forbid(dev);
ret = phy_pipe_clk_register(qmp, np);
if (ret)
--
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 4/4] phy: qcom: snps-femto-v2: Fix possible NULL-deref on early runtime suspend
From: Loic Poulain @ 2026-01-08 15:49 UTC (permalink / raw)
To: vkoul, kishon
Cc: linux-arm-msm, linux-phy, dmitry.baryshkov, neil.armstrong,
Loic Poulain
In-Reply-To: <20260108154944.211886-1-loic.poulain@oss.qualcomm.com>
Enabling runtime PM before attaching the hsphy instance as driver data
can lead to a NULL pointer dereference in runtime PM callbacks that
expect valid driver data. There is a small window where the suspend
callback may run after PM runtime enabling and before runtime forbid.
Attach the hsphy instance as driver data before enabling runtime PM to
prevent NULL pointer dereference in runtime PM callbacks.
Reorder pm_runtime_enable() and pm_runtime_forbid() to prevent a
short window where an unnecessary runtime suspend can occur.
Use the devres-managed version to ensure PM runtime is symmetrically
disabled during driver removal for proper cleanup.
Fixes: 0d75f508a9d5 ("phy: qcom-snps: Add runtime suspend and resume handlers")
Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
---
drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c | 15 ++++++++-------
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c b/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c
index eb0b0f61d98e..d1288a6c202e 100644
--- a/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c
+++ b/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c
@@ -599,13 +599,17 @@ static int qcom_snps_hsphy_probe(struct platform_device *pdev)
return dev_err_probe(dev, ret,
"failed to get regulator supplies\n");
- pm_runtime_set_active(dev);
- pm_runtime_enable(dev);
+ dev_set_drvdata(dev, hsphy);
+
/*
- * Prevent runtime pm from being ON by default. Users can enable
- * it using power/control in sysfs.
+ * Enable runtime PM support, but forbid it by default.
+ * Users can allow it again via the power/control attribute in sysfs.
*/
+ pm_runtime_set_active(dev);
pm_runtime_forbid(dev);
+ ret = devm_pm_runtime_enable(dev);
+ if (ret)
+ return ret;
generic_phy = devm_phy_create(dev, NULL, &qcom_snps_hsphy_gen_ops);
if (IS_ERR(generic_phy)) {
@@ -615,15 +619,12 @@ static int qcom_snps_hsphy_probe(struct platform_device *pdev)
}
hsphy->phy = generic_phy;
- dev_set_drvdata(dev, hsphy);
phy_set_drvdata(generic_phy, hsphy);
qcom_snps_hsphy_read_override_param_seq(dev);
phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
if (!IS_ERR(phy_provider))
dev_dbg(dev, "Registered Qcom-SNPS HS phy\n");
- else
- pm_runtime_disable(dev);
return PTR_ERR_OR_ZERO(phy_provider);
}
--
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 3/4] phy: qcom: qmp-usb-legacy: Fix possible NULL-deref on early runtime suspend
From: Loic Poulain @ 2026-01-08 15:49 UTC (permalink / raw)
To: vkoul, kishon
Cc: linux-arm-msm, linux-phy, dmitry.baryshkov, neil.armstrong,
Loic Poulain
In-Reply-To: <20260108154944.211886-1-loic.poulain@oss.qualcomm.com>
There is a small window where the runtime suspend callback may run
after pm_runtime_enable() and before pm_runtime_forbid(). In this
case, a crash occurs because runtime suspend/resume dereferences
qmp->phy pointer, which is not yet initialized:
`if (!qmp->phy->init_count) {`
Similarly to other qcom phy drivers, introduce a qmp->phy_initialized
variable that can be used to avoid relying on the possibly uninitialized
phy pointer.
Reorder pm_runtime_enable() and pm_runtime_forbid() to prevent the window
where an unnecessary runtime suspend can occur.
Fixes: e464a3180a43 ("phy: qcom-qmp-usb: split off the legacy USB+dp_com support")
Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
---
.../phy/qualcomm/phy-qcom-qmp-usb-legacy.c | 21 ++++++++++++-------
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-usb-legacy.c b/drivers/phy/qualcomm/phy-qcom-qmp-usb-legacy.c
index 8bf951b0490c..73439d223f1d 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp-usb-legacy.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp-usb-legacy.c
@@ -541,6 +541,7 @@ struct qmp_usb {
struct regulator_bulk_data *vregs;
enum phy_mode mode;
+ bool phy_initialized;
struct phy *phy;
@@ -895,6 +896,7 @@ static int qmp_usb_legacy_power_off(struct phy *phy)
static int qmp_usb_legacy_enable(struct phy *phy)
{
+ struct qmp_usb *qmp = phy_get_drvdata(phy);
int ret;
ret = qmp_usb_legacy_init(phy);
@@ -904,14 +906,19 @@ static int qmp_usb_legacy_enable(struct phy *phy)
ret = qmp_usb_legacy_power_on(phy);
if (ret)
qmp_usb_legacy_exit(phy);
+ else
+ qmp->phy_initialized = true;
return ret;
}
static int qmp_usb_legacy_disable(struct phy *phy)
{
+ struct qmp_usb *qmp = phy_get_drvdata(phy);
int ret;
+ qmp->phy_initialized = false;
+
ret = qmp_usb_legacy_power_off(phy);
if (ret)
return ret;
@@ -988,7 +995,7 @@ static int __maybe_unused qmp_usb_legacy_runtime_suspend(struct device *dev)
dev_vdbg(dev, "Suspending QMP phy, mode:%d\n", qmp->mode);
- if (!qmp->phy->init_count) {
+ if (!qmp->phy_initialized) {
dev_vdbg(dev, "PHY not initialized, bailing out\n");
return 0;
}
@@ -1009,7 +1016,7 @@ static int __maybe_unused qmp_usb_legacy_runtime_resume(struct device *dev)
dev_vdbg(dev, "Resuming QMP phy, mode:%d\n", qmp->mode);
- if (!qmp->phy->init_count) {
+ if (!qmp->phy_initialized) {
dev_vdbg(dev, "PHY not initialized, bailing out\n");
return 0;
}
@@ -1277,15 +1284,15 @@ static int qmp_usb_legacy_probe(struct platform_device *pdev)
if (ret)
goto err_node_put;
+ /*
+ * Enable runtime PM support, but forbid it by default.
+ * Users can allow it again via the power/control attribute in sysfs.
+ */
pm_runtime_set_active(dev);
+ pm_runtime_forbid(dev);
ret = devm_pm_runtime_enable(dev);
if (ret)
goto err_node_put;
- /*
- * Prevent runtime pm from being ON by default. Users can enable
- * it using power/control in sysfs.
- */
- pm_runtime_forbid(dev);
ret = phy_pipe_clk_register(qmp, np);
if (ret)
--
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 1/4] phy: qcom: qmp-combo: Prevent unnecessary PM runtime suspend at boot
From: Loic Poulain @ 2026-01-08 15:49 UTC (permalink / raw)
To: vkoul, kishon
Cc: linux-arm-msm, linux-phy, dmitry.baryshkov, neil.armstrong,
Loic Poulain
In-Reply-To: <20260108154944.211886-1-loic.poulain@oss.qualcomm.com>
There is a small window where the device can suspend after
pm_runtime_enable() and before pm_runtime_forbid(), causing an
unnecessary suspend/resume cycle while the PHY is not yet registered.
Move pm_runtime_forbid() before pm_runtime_enable() to eliminate
this race.
Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
---
drivers/phy/qualcomm/phy-qcom-qmp-combo.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-combo.c b/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
index 7b5af30f1d02..cea0e9f7413d 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
@@ -4175,15 +4175,15 @@ static int qmp_combo_probe(struct platform_device *pdev)
if (ret)
goto err_node_put;
+ /*
+ * Enable runtime PM support, but forbid it by default.
+ * Users can allow it again via the power/control attribute in sysfs.
+ */
pm_runtime_set_active(dev);
+ pm_runtime_forbid(dev);
ret = devm_pm_runtime_enable(dev);
if (ret)
goto err_node_put;
- /*
- * Prevent runtime pm from being ON by default. Users can enable
- * it using power/control in sysfs.
- */
- pm_runtime_forbid(dev);
ret = qmp_combo_register_clocks(qmp, usb_np, dp_np);
if (ret)
--
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 0/4] phy: qcom: Fix possible NULL-deref and runtime PM race conditions
From: Loic Poulain @ 2026-01-08 15:49 UTC (permalink / raw)
To: vkoul, kishon
Cc: linux-arm-msm, linux-phy, dmitry.baryshkov, neil.armstrong,
Loic Poulain
Address potential NULL pointer dereferences and race conditions related
to runtime PM in several Qualcomm PHY drivers. In all cases, enabling
runtime PM before the PHY instance is fully initialized can lead to
crashes during early runtime suspend callbacks.
- Attach driver data before enabling runtime PM.
- Introduce initialization flags where needed to avoid dereferencing
uninitialized pointers.
- Reorder pm_runtime_enable() and pm_runtime_forbid() calls to prevent
unnecessary suspend/resume cycles during driver probe.
- Use devres-managed PM runtime helpers for proper cleanup.
Loic Poulain (4):
phy: qcom: qmp-combo: Prevent unnecessary PM runtime suspend at boot
phy: qcom: qmp-usbc: Fix possible NULL-deref on early runtime suspend
phy: qcom: qmp-usb-legacy: Fix possible NULL-deref on early runtime
suspend
phy: qcom: snps-femto-v2: Fix possible NULL-deref on early runtime
suspend
drivers/phy/qualcomm/phy-qcom-qmp-combo.c | 10 ++++-----
.../phy/qualcomm/phy-qcom-qmp-usb-legacy.c | 21 ++++++++++++-------
drivers/phy/qualcomm/phy-qcom-qmp-usbc.c | 14 ++++++-------
drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c | 15 ++++++-------
4 files changed, 34 insertions(+), 26 deletions(-)
--
2.34.1
--
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