* [PATCH v5 2/5] phy: fsl-imx8mq-usb: set usb phy to be wakeup capable
From: Xu Yang @ 2026-06-30 10:11 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Jun Li
Cc: linux-phy, imx, linux-arm-kernel, linux-kernel, Xu Yang
In-Reply-To: <20260630-imx8mp-usb-phy-improvement-v5-0-25d616403844@nxp.com>
From: Xu Yang <xu.yang_2@nxp.com>
Set PHY wakeup capable because this PHY supports remote wakeup function.
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
---
Changes in v5:
- no changes
Changes in v4:
- add Rb tag
Changes in v3:
- no changes
Changes in v2:
- no changes
---
drivers/phy/freescale/phy-fsl-imx8mq-usb.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
index 9a33c06d6fc3..3a5788c609e1 100644
--- a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
+++ b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
@@ -728,6 +728,7 @@ static int imx8mq_usb_phy_probe(struct platform_device *pdev)
"failed to get tca\n");
imx8m_get_phy_tuning_data(imx_phy);
+ device_set_wakeup_capable(dev, true);
phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v5 3/5] phy: fsl-imx8mq-usb: add runtime PM support
From: Xu Yang @ 2026-06-30 10:11 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Jun Li
Cc: linux-phy, imx, linux-arm-kernel, linux-kernel, Xu Yang
In-Reply-To: <20260630-imx8mp-usb-phy-improvement-v5-0-25d616403844@nxp.com>
From: Xu Yang <xu.yang_2@nxp.com>
Add runtime PM to ensure the PHY is properly powered and clocked during
register access, preventing potential system hangs.
It guards register access in the following scenarios:
- PHY operations: init() and power_on/off() callbacks are guarded by
phy core
- Type-C orientation switching when PHY/Controller are suspended which
needs explicitly care
- Future PHY control port register regmap debugfs access
Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
---
Changes in v5:
- use non-devm PM runtime callback to correctly enable/disable clocks
when unbind the device
Changes in v4:
- replace guard() with PM_RUNTIME_ACQUIRE()
Changes in v3:
- new patch
---
drivers/phy/freescale/phy-fsl-imx8mq-usb.c | 64 +++++++++++++++++++++---------
1 file changed, 45 insertions(+), 19 deletions(-)
diff --git a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
index 3a5788c609e1..9d1dd0e7352e 100644
--- a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
+++ b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
@@ -9,6 +9,7 @@
#include <linux/of.h>
#include <linux/phy/phy.h>
#include <linux/platform_device.h>
+#include <linux/pm_runtime.h>
#include <linux/regulator/consumer.h>
#include <linux/usb/typec_mux.h>
@@ -136,17 +137,15 @@ static int tca_blk_typec_switch_set(struct typec_switch_dev *sw,
{
struct imx8mq_usb_phy *imx_phy = typec_switch_get_drvdata(sw);
struct tca_blk *tca = imx_phy->tca;
- int ret;
if (tca->orientation == orientation)
return 0;
- ret = clk_prepare_enable(imx_phy->clk);
- if (ret)
- return ret;
+ PM_RUNTIME_ACQUIRE(&imx_phy->phy->dev, pm);
+ if (PM_RUNTIME_ACQUIRE_ERR(&pm))
+ return -ENXIO;
tca_blk_orientation_set(tca, orientation);
- clk_disable_unprepare(imx_phy->clk);
return 0;
}
@@ -620,16 +619,6 @@ static int imx8mq_phy_power_on(struct phy *phy)
if (ret)
return ret;
- ret = clk_prepare_enable(imx_phy->clk);
- if (ret)
- return ret;
-
- ret = clk_prepare_enable(imx_phy->alt_clk);
- if (ret) {
- clk_disable_unprepare(imx_phy->clk);
- return ret;
- }
-
/* Disable rx term override */
value = readl(imx_phy->base + PHY_CTRL6);
value &= ~PHY_CTRL6_RXTERM_OVERRIDE_SEL;
@@ -648,8 +637,6 @@ static int imx8mq_phy_power_off(struct phy *phy)
value |= PHY_CTRL6_RXTERM_OVERRIDE_SEL;
writel(value, imx_phy->base + PHY_CTRL6);
- clk_disable_unprepare(imx_phy->alt_clk);
- clk_disable_unprepare(imx_phy->clk);
regulator_disable(imx_phy->vbus);
return 0;
@@ -693,13 +680,13 @@ static int imx8mq_usb_phy_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, imx_phy);
- imx_phy->clk = devm_clk_get(dev, "phy");
+ imx_phy->clk = devm_clk_get_enabled(dev, "phy");
if (IS_ERR(imx_phy->clk)) {
dev_err(dev, "failed to get imx8mq usb phy clock\n");
return PTR_ERR(imx_phy->clk);
}
- imx_phy->alt_clk = devm_clk_get_optional(dev, "alt");
+ imx_phy->alt_clk = devm_clk_get_optional_enabled(dev, "alt");
if (IS_ERR(imx_phy->alt_clk))
return dev_err_probe(dev, PTR_ERR(imx_phy->alt_clk),
"Failed to get alt clk\n");
@@ -708,6 +695,9 @@ static int imx8mq_usb_phy_probe(struct platform_device *pdev)
if (IS_ERR(imx_phy->base))
return PTR_ERR(imx_phy->base);
+ pm_runtime_set_active(dev);
+ pm_runtime_enable(dev);
+
phy_ops = of_device_get_match_data(dev);
if (!phy_ops)
return -EINVAL;
@@ -737,15 +727,51 @@ static int imx8mq_usb_phy_probe(struct platform_device *pdev)
static void imx8mq_usb_phy_remove(struct platform_device *pdev)
{
+ struct device *dev = &pdev->dev;
+
+ pm_runtime_get_sync(dev);
+ pm_runtime_disable(dev);
+ pm_runtime_put_noidle(dev);
+}
+
+static int imx8mq_usb_phy_runtime_suspend(struct device *dev)
+{
+ struct imx8mq_usb_phy *imx_phy = dev_get_drvdata(dev);
+
+ clk_disable_unprepare(imx_phy->alt_clk);
+ clk_disable_unprepare(imx_phy->clk);
+
+ return 0;
+}
+
+static int imx8mq_usb_phy_runtime_resume(struct device *dev)
+{
+ struct imx8mq_usb_phy *imx_phy = dev_get_drvdata(dev);
+ int ret;
+
+ ret = clk_prepare_enable(imx_phy->clk);
+ if (ret)
+ return ret;
+ ret = clk_prepare_enable(imx_phy->alt_clk);
+ if (ret) {
+ clk_disable_unprepare(imx_phy->clk);
+ return ret;
+ }
+
+ return 0;
}
+static DEFINE_RUNTIME_DEV_PM_OPS(imx8mq_usb_phy_pm_ops, imx8mq_usb_phy_runtime_suspend,
+ imx8mq_usb_phy_runtime_resume, NULL);
+
static struct platform_driver imx8mq_usb_phy_driver = {
.probe = imx8mq_usb_phy_probe,
.remove = imx8mq_usb_phy_remove,
.driver = {
.name = "imx8mq-usb-phy",
.of_match_table = imx8mq_usb_phy_of_match,
+ .pm = pm_ptr(&imx8mq_usb_phy_pm_ops),
.suppress_bind_attrs = true,
}
};
--
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 4/5] phy: fsl-imx8mq-usb: add control register regmap
From: Xu Yang @ 2026-06-30 10:11 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Jun Li
Cc: linux-phy, imx, linux-arm-kernel, linux-kernel, Xu Yang
In-Reply-To: <20260630-imx8mp-usb-phy-improvement-v5-0-25d616403844@nxp.com>
From: Xu Yang <xu.yang_2@nxp.com>
The CR port is a simple 16-bit data/address parallel port that is
accessed through 32-bit MMIO registers for on-chip access to the
control registers inside the USB 3.0 femtoPHY. Add control register
regmap and export these registers by debugfs to help PHY's diagnostic.
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
---
Changes in v5:
- add Rb tag
Changes in v4:
- improve commit message as Haibo's suggestion
Changes in v3:
- drop Frank's tag because it includes other changes
- new patch
---
drivers/phy/freescale/phy-fsl-imx8mq-usb.c | 27 ++++++++++++++++++++++++++-
1 file changed, 26 insertions(+), 1 deletion(-)
diff --git a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
index 9d1dd0e7352e..4949ec78d304 100644
--- a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
+++ b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
@@ -1,5 +1,5 @@
// SPDX-License-Identifier: GPL-2.0+
-/* Copyright (c) 2017 NXP. */
+/* Copyright 2017-2026 NXP. */
#include <linux/bitfield.h>
#include <linux/clk.h>
@@ -11,6 +11,7 @@
#include <linux/platform_device.h>
#include <linux/pm_runtime.h>
#include <linux/regulator/consumer.h>
+#include <linux/regmap.h>
#include <linux/usb/typec_mux.h>
#define PHY_CTRL0 0x0
@@ -56,6 +57,8 @@
#define PHY_CTRL6_ALT_CLK_EN BIT(1)
#define PHY_CTRL6_ALT_CLK_SEL BIT(0)
+#define PHY_CRCTL 0x30
+
#define PHY_TUNE_DEFAULT 0xffffffff
#define TCA_CLK_RST 0x00
@@ -119,6 +122,7 @@ struct imx8mq_usb_phy {
void __iomem *base;
struct regulator *vbus;
struct tca_blk *tca;
+ struct regmap *cr_regmap;
u32 pcs_tx_swing_full;
u32 pcs_tx_deemph_3p5db;
u32 tx_vref_tune;
@@ -667,6 +671,14 @@ static const struct of_device_id imx8mq_usb_phy_of_match[] = {
};
MODULE_DEVICE_TABLE(of, imx8mq_usb_phy_of_match);
+static const struct regmap_config imx_cr_regmap_config = {
+ .name = "cr",
+ .reg_bits = 32,
+ .val_bits = 32,
+ .reg_stride = 4,
+ .max_register = 0x7,
+};
+
static int imx8mq_usb_phy_probe(struct platform_device *pdev)
{
struct phy_provider *phy_provider;
@@ -695,6 +707,13 @@ static int imx8mq_usb_phy_probe(struct platform_device *pdev)
if (IS_ERR(imx_phy->base))
return PTR_ERR(imx_phy->base);
+ imx_phy->cr_regmap = devm_regmap_init_mmio(dev, imx_phy->base + PHY_CRCTL,
+ &imx_cr_regmap_config);
+ if (IS_ERR(imx_phy->cr_regmap)) {
+ dev_warn(dev, "Fail to init debug register regmap\n");
+ imx_phy->cr_regmap = NULL;
+ }
+
pm_runtime_set_active(dev);
pm_runtime_enable(dev);
@@ -738,6 +757,9 @@ static int imx8mq_usb_phy_runtime_suspend(struct device *dev)
{
struct imx8mq_usb_phy *imx_phy = dev_get_drvdata(dev);
+ if (imx_phy->cr_regmap)
+ regcache_cache_only(imx_phy->cr_regmap, true);
+
clk_disable_unprepare(imx_phy->alt_clk);
clk_disable_unprepare(imx_phy->clk);
@@ -759,6 +781,9 @@ static int imx8mq_usb_phy_runtime_resume(struct device *dev)
return ret;
}
+ if (imx_phy->cr_regmap)
+ regcache_cache_only(imx_phy->cr_regmap, false);
+
return 0;
}
--
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 5/5] phy: fsl-imx8mq-usb: keep PHY power domain runtime always-on for i.MX8MP
From: Xu Yang @ 2026-06-30 10:11 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Jun Li
Cc: linux-phy, imx, linux-arm-kernel, linux-kernel, Xu Yang
In-Reply-To: <20260630-imx8mp-usb-phy-improvement-v5-0-25d616403844@nxp.com>
From: Xu Yang <xu.yang_2@nxp.com>
On i.MX8MP, the USB PHY has a dedicated power domain that was previously
never powered off at runtime. With the introduction of runtime PM support,
the power domain will be powered off if the device is runtime suspended,
which breaks USB wakeup functionality.
To preserve wakeup functionality, mark the PHY power domain as runtime
always-on for i.MX8MP platform. To limit the behavior to i.MX8MP, add a
new imx95_usb_phy_ops for i.MX95 and introduce usb_phy_is_imx8mp() helper
to identify i.MX8MP PHY instance.
Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
---
Changes in v5:
- no changes
Changes in v4:
- no changes
Changes in v3:
- new patch
---
drivers/phy/freescale/phy-fsl-imx8mq-usb.c | 18 +++++++++++++++++-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
index 4949ec78d304..c9741b532663 100644
--- a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
+++ b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
@@ -9,6 +9,7 @@
#include <linux/of.h>
#include <linux/phy/phy.h>
#include <linux/platform_device.h>
+#include <linux/pm_domain.h>
#include <linux/pm_runtime.h>
#include <linux/regulator/consumer.h>
#include <linux/regmap.h>
@@ -660,13 +661,20 @@ static const struct phy_ops imx8mp_usb_phy_ops = {
.owner = THIS_MODULE,
};
+static const struct phy_ops imx95_usb_phy_ops = {
+ .init = imx8mp_usb_phy_init,
+ .power_on = imx8mq_phy_power_on,
+ .power_off = imx8mq_phy_power_off,
+ .owner = THIS_MODULE,
+};
+
static const struct of_device_id imx8mq_usb_phy_of_match[] = {
{.compatible = "fsl,imx8mq-usb-phy",
.data = &imx8mq_usb_phy_ops,},
{.compatible = "fsl,imx8mp-usb-phy",
.data = &imx8mp_usb_phy_ops,},
{.compatible = "fsl,imx95-usb-phy",
- .data = &imx8mp_usb_phy_ops,},
+ .data = &imx95_usb_phy_ops,},
{ }
};
MODULE_DEVICE_TABLE(of, imx8mq_usb_phy_of_match);
@@ -679,6 +687,11 @@ static const struct regmap_config imx_cr_regmap_config = {
.max_register = 0x7,
};
+static bool usb_phy_is_imx8mp(const void *data)
+{
+ return data == &imx8mp_usb_phy_ops;
+}
+
static int imx8mq_usb_phy_probe(struct platform_device *pdev)
{
struct phy_provider *phy_provider;
@@ -721,6 +734,9 @@ static int imx8mq_usb_phy_probe(struct platform_device *pdev)
if (!phy_ops)
return -EINVAL;
+ if (usb_phy_is_imx8mp(phy_ops))
+ dev_pm_genpd_rpm_always_on(dev, true);
+
imx_phy->phy = devm_phy_create(dev, NULL, phy_ops);
if (IS_ERR(imx_phy->phy))
return PTR_ERR(imx_phy->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
* Re: [PATCH v5 1/5] phy: fsl-imx8mq-usb: fix typec switch leak on probe error path
From: sashiko-bot @ 2026-06-30 10:31 UTC (permalink / raw)
To: Xu Yang; +Cc: linux-phy, Frank.Li, vkoul, imx, neil.armstrong, olteanv
In-Reply-To: <20260630-imx8mp-usb-phy-improvement-v5-1-25d616403844@nxp.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues:
- [High] Race condition causing NULL pointer dereference during device probe.
- [High] Use-After-Free of devm-allocated driver data during device unbind.
--
commit d64f34cfc15d26f577e5ff3a17572cf971e65696
Author: Felix Gu <ustc.gu@gmail.com>
phy: fsl-imx8mq-usb: fix typec switch leak on probe error path
If probe fails after imx95_usb_phy_get_tca() succeeds, the typec
switch leaks because the only cleanup path was in .remove, which
never runs on probe failure. Use devm_add_action_or_reset() so the
switch is cleaned up on both probe failure and driver removal.
> diff --git a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
> --- a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
> +++ b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
[ ... ]
> @@ -266,17 +267,11 @@ static struct tca_blk *imx95_usb_phy_get_tca(struct platform_device *pdev,
> tca->orientation = TYPEC_ORIENTATION_NORMAL;
> tca->sw = tca_blk_get_typec_switch(pdev, imx_phy);
[Severity: High]
This is a pre-existing issue, but does this code introduce a race
condition during probe?
When tca_blk_get_typec_switch() registers the switch, it is immediately
visible to consumers. However, imx_phy->tca has not been assigned yet.
It is only assigned after returning from imx95_usb_phy_get_tca() in
imx8mq_usb_phy_probe().
If a consumer concurrently finds the switch and calls typec_switch_set(),
tca_blk_typec_switch_set() will access imx_phy->tca->orientation,
dereferencing a NULL pointer.
>
> - return tca;
> -}
> -
> -static void imx95_usb_phy_put_tca(struct imx8mq_usb_phy *imx_phy)
> -{
> - struct tca_blk *tca = imx_phy->tca;
> -
> - if (!tca)
> - return;
> + ret = devm_add_action_or_reset(&pdev->dev, tca_blk_put_typec_switch, tca->sw);
[Severity: High]
This is a pre-existing issue, but could this devm cleanup lead to a
use-after-free during driver unbind?
The imx_phy and tca structures are allocated via devm_kzalloc(). During
unbind, this devres action will execute tca_blk_put_typec_switch(), which
calls typec_switch_unregister().
While typec_switch_unregister() unlinks the device, if a consumer still
holds a reference to the switch, the object itself will outlive the driver
unbind. Since devres immediately frees imx_phy and tca after the action
returns, any subsequent call to tca_blk_typec_switch_set() by the active
consumer will access freed memory.
> + if (ret)
> + return ERR_PTR(ret);
>
> - tca_blk_put_typec_switch(tca->sw);
> + return tca;
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260630-imx8mp-usb-phy-improvement-v5-0-25d616403844@nxp.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 v5 3/5] phy: fsl-imx8mq-usb: add runtime PM support
From: sashiko-bot @ 2026-06-30 10:52 UTC (permalink / raw)
To: Xu Yang; +Cc: imx, vkoul, linux-phy, olteanv, Frank.Li, neil.armstrong
In-Reply-To: <20260630-imx8mp-usb-phy-improvement-v5-3-25d616403844@nxp.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Missing `pm_runtime_disable()` in `imx8mq_usb_phy_probe()` error paths causes a `disable_depth` imbalance and PM state corruption.
--
commit e9418c8d510e8492ef9a52ace4cb6d672041d448
Author: Xu Yang <xu.yang_2@nxp.com>
phy: fsl-imx8mq-usb: add runtime PM support
This commit adds runtime PM support to ensure the PHY is properly powered
and clocked during register access, preventing potential system hangs.
> diff --git a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
> --- a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
> +++ b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
[ ... ]
> @@ -708,6 +695,9 @@ static int imx8mq_usb_phy_probe(struct platform_device *pdev)
> if (IS_ERR(imx_phy->base))
> return PTR_ERR(imx_phy->base);
>
> + pm_runtime_set_active(dev);
> + pm_runtime_enable(dev);
> +
> phy_ops = of_device_get_match_data(dev);
> if (!phy_ops)
> return -EINVAL;
[Severity: High]
Does this code need a cleanup path to call pm_runtime_disable() on probe
failures?
If functions following pm_runtime_enable() fail (such as
of_device_get_match_data(), devm_phy_create(), or devm_regulator_get()),
the driver returns the error directly without cleaning up the PM state.
This can leave the disable_depth counter out of sync. If the device probe
defers (for example, if devm_regulator_get() returns -EPROBE_DEFER) and
runs again, the subsequent pm_runtime_enable() could drop the counter
below zero. This might trigger an unbalanced pm_runtime_enable warning
and leave the device permanently stuck in RPM_ACTIVE.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260630-imx8mp-usb-phy-improvement-v5-0-25d616403844@nxp.com?part=3
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v5 4/5] phy: fsl-imx8mq-usb: add control register regmap
From: sashiko-bot @ 2026-06-30 11:13 UTC (permalink / raw)
To: Xu Yang; +Cc: Frank.Li, vkoul, olteanv, linux-phy, imx, neil.armstrong
In-Reply-To: <20260630-imx8mp-usb-phy-improvement-v5-4-25d616403844@nxp.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Runtime PM enablement is leaked on probe error paths.
--
commit 487a0a8551844cc9b5c38e7f8d7cbf2ec3f1435d
Author: Xu Yang <xu.yang_2@nxp.com>
phy: fsl-imx8mq-usb: add control register regmap
This commit adds a control register regmap for the USB 3.0 femtoPHY.
It exposes these registers through debugfs to assist with diagnostic
efforts.
> diff --git a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
> index 9d1dd0e7352ed..4949ec78d3044 100644
> --- a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
> +++ b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
[ ... ]
> @@ -695,6 +707,13 @@ static int imx8mq_usb_phy_probe(struct platform_device *pdev)
> if (IS_ERR(imx_phy->base))
> return PTR_ERR(imx_phy->base);
>
> + imx_phy->cr_regmap = devm_regmap_init_mmio(dev, imx_phy->base + PHY_CRCTL,
> + &imx_cr_regmap_config);
> + if (IS_ERR(imx_phy->cr_regmap)) {
> + dev_warn(dev, "Fail to init debug register regmap\n");
> + imx_phy->cr_regmap = NULL;
> + }
> +
> pm_runtime_set_active(dev);
> pm_runtime_enable(dev);
[Severity: Medium]
Is there a leak of the runtime PM enablement state on probe error paths here?
In imx8mq_usb_phy_probe(), pm_runtime_enable() is called, but subsequent
initialization steps (like devm_phy_create() or devm_regulator_get()) can fail
and return directly without calling pm_runtime_disable().
Could this leave the disable_depth counter at 0 on a probe failure like
-EPROBE_DEFER, resulting in an 'Unbalanced pm_runtime_enable!' warning on the
next probe attempt? Would using devm_pm_runtime_enable() ensure this state is
properly cleaned up?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260630-imx8mp-usb-phy-improvement-v5-0-25d616403844@nxp.com?part=4
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH] phy: phy-can-transceiver: Add suspend operation for tcan1043
From: Thomas Richard (TI) @ 2026-06-30 12:28 UTC (permalink / raw)
To: Marc Kleine-Budde, Vincent Mailhol, Vinod Koul, Neil Armstrong
Cc: Thomas Petazzoni, Gregory CLEMENT, richard.genoud, Udit Kumar,
Abhash Kumar, linux-can, linux-phy, linux-kernel,
Thomas Richard (TI)
Add suspend operation for tcan1043. It switches the PHY in Sleep mode, the
lowest power mode of the device. If a bus wake-up pattern or a local
wake-up event occurs, the PHY transitions to Standby mode, set its internal
WAKERQ flag and set the INH output high. In Sleep mode INH is floating.
The WAKERQ flag prevents transition to Go-to-Sleep mode. The only way to
clear it is to switch to Normal mode. So to reach Sleep mode, we firstly
switch to Normal mode, then to Go-to-Sleep mode.
Suspend sequence (PHY is off):
Standby -> Normal -> Go-to-Sleep -> Sleep
Suspend sequence (PHY is on):
Normal -> Go-to-Sleep -> Sleep
Signed-off-by: Thomas Richard (TI) <thomas.richard@bootlin.com>
---
drivers/phy/phy-can-transceiver.c | 56 ++++++++++++++++++++++++++++++++++-----
1 file changed, 49 insertions(+), 7 deletions(-)
diff --git a/drivers/phy/phy-can-transceiver.c b/drivers/phy/phy-can-transceiver.c
index 75dc49e75ca0..2bca1a173fcc 100644
--- a/drivers/phy/phy-can-transceiver.c
+++ b/drivers/phy/phy-can-transceiver.c
@@ -5,6 +5,7 @@
* Copyright (C) 2021 Texas Instruments Incorporated - https://www.ti.com
*
*/
+#include <linux/delay.h>
#include <linux/gpio/consumer.h>
#include <linux/phy/phy.h>
#include <linux/platform_device.h>
@@ -12,25 +13,28 @@
#include <linux/module.h>
#include <linux/mux/consumer.h>
+struct can_transceiver_phy {
+ struct phy *generic_phy;
+ struct gpio_desc *silent_gpio;
+ struct gpio_desc *standby_gpio;
+ struct gpio_desc *enable_gpio;
+ struct can_transceiver_priv *priv;
+};
+
struct can_transceiver_data {
u32 flags;
#define CAN_TRANSCEIVER_STB_PRESENT BIT(0)
#define CAN_TRANSCEIVER_EN_PRESENT BIT(1)
#define CAN_TRANSCEIVER_DUAL_CH BIT(2)
#define CAN_TRANSCEIVER_SILENT_PRESENT BIT(3)
+ int (*suspend)(struct can_transceiver_phy *phy);
};
-struct can_transceiver_phy {
- struct phy *generic_phy;
- struct gpio_desc *silent_gpio;
- struct gpio_desc *standby_gpio;
- struct gpio_desc *enable_gpio;
- struct can_transceiver_priv *priv;
-};
struct can_transceiver_priv {
struct mux_state *mux_state;
int num_ch;
+ const struct can_transceiver_data *data;
struct can_transceiver_phy can_transceiver_phy[] __counted_by(num_ch);
};
@@ -76,12 +80,28 @@ static const struct phy_ops can_transceiver_phy_ops = {
.owner = THIS_MODULE,
};
+static int tcan1043_suspend(struct can_transceiver_phy *phy)
+{
+ /* Switch to Normal mode, it clears WAKERQ */
+ gpiod_set_value_cansleep(phy->standby_gpio, 0);
+ gpiod_set_value_cansleep(phy->enable_gpio, 1);
+
+ /* Switch to Go-to-Sleep mode */
+ gpiod_set_value_cansleep(phy->standby_gpio, 1);
+
+ /* Wait transition to Sleep mode */
+ fsleep(5);
+
+ return 0;
+}
+
static const struct can_transceiver_data tcan1042_drvdata = {
.flags = CAN_TRANSCEIVER_STB_PRESENT,
};
static const struct can_transceiver_data tcan1043_drvdata = {
.flags = CAN_TRANSCEIVER_STB_PRESENT | CAN_TRANSCEIVER_EN_PRESENT,
+ .suspend = tcan1043_suspend,
};
static const struct can_transceiver_data tja1048_drvdata = {
@@ -115,6 +135,26 @@ static struct phy *can_transceiver_phy_xlate(struct device *dev,
return priv->can_transceiver_phy[idx].generic_phy;
}
+static int can_transceiver_phy_suspend(struct device *dev)
+{
+ struct can_transceiver_priv *priv = dev_get_drvdata(dev);
+ const struct can_transceiver_data *data = priv->data;
+ int ret, i;
+
+ for (i = 0; i < priv->num_ch; i++) {
+ if (data->suspend) {
+ ret = data->suspend(&priv->can_transceiver_phy[i]);
+ if (ret)
+ return ret;
+ }
+ }
+
+ return 0;
+}
+
+static DEFINE_SIMPLE_DEV_PM_OPS(can_transceiver_phy_pm_ops,
+ can_transceiver_phy_suspend, NULL);
+
static int can_transceiver_phy_probe(struct platform_device *pdev)
{
struct phy_provider *phy_provider;
@@ -145,6 +185,7 @@ static int can_transceiver_phy_probe(struct platform_device *pdev)
return -ENOMEM;
priv->num_ch = num_ch;
+ priv->data = drvdata;
platform_set_drvdata(pdev, priv);
mux_state = devm_mux_state_get_optional(dev, NULL);
@@ -247,6 +288,7 @@ static struct platform_driver can_transceiver_phy_driver = {
.driver = {
.name = "can-transceiver-phy",
.of_match_table = can_transceiver_phy_ids,
+ .pm = pm_sleep_ptr(&can_transceiver_phy_pm_ops),
},
};
---
base-commit: a25d586f7f9e7f22e7e0350053c15924d28ed6ee
change-id: 20260618-phy-can-transceiver-suspend-resume-support-de9f32852fb8
Best regards,
--
Thomas Richard (TI) <thomas.richard@bootlin.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: phy-can-transceiver: Add suspend operation for tcan1043
From: sashiko-bot @ 2026-06-30 12:40 UTC (permalink / raw)
Cc: olteanv, vkoul, Vincent Mailhol, Oliver Hartkopp, Oleksij Rempel,
linux-can, Marc Kleine-Budde, linux-phy, neil.armstrong
In-Reply-To: <20260630-phy-can-transceiver-suspend-resume-support-v1-1-6842c2d697e4@bootlin.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Missing `.resume` callback in PM operations leaves the CAN PHY permanently in Sleep mode after system resume.
- [Medium] Missing delay when transitioning through Normal mode may result in the transition being ignored by the transceiver hardware.
--
commit 2d2e1a772ce8aac2faea27b0135abc2a7ed70072
Author: Thomas Richard (TI) <thomas.richard@bootlin.com>
phy: phy-can-transceiver: Add suspend operation for tcan1043
This commit adds a suspend operation for the tcan1043 PHY, switching it
to Sleep mode during system suspend. It transitions the PHY through Normal
mode to clear the WAKERQ flag before entering Go-to-Sleep and finally
Sleep mode.
> diff --git a/drivers/phy/phy-can-transceiver.c b/drivers/phy/phy-can-transceiver.c
> index 75dc49e75ca0e..2bca1a173fcc3 100644
> --- a/drivers/phy/phy-can-transceiver.c
> +++ b/drivers/phy/phy-can-transceiver.c
[ ... ]
> @@ -76,12 +80,28 @@ static const struct phy_ops can_transceiver_phy_ops = {
> .owner = THIS_MODULE,
> };
>
> +static int tcan1043_suspend(struct can_transceiver_phy *phy)
> +{
> + /* Switch to Normal mode, it clears WAKERQ */
> + gpiod_set_value_cansleep(phy->standby_gpio, 0);
> + gpiod_set_value_cansleep(phy->enable_gpio, 1);
> +
> + /* Switch to Go-to-Sleep mode */
> + gpiod_set_value_cansleep(phy->standby_gpio, 1);
[Severity: Medium]
Will this back-to-back GPIO toggle execute too quickly on platforms with fast
memory-mapped GPIOs?
Without an intermediate delay, the sub-microsecond state change might not
give the transceiver's internal state machine enough time to register the
Normal mode transition. Can this cause the transceiver to ignore the
transition, fail to clear the WAKERQ flag, and thus fail to enter Sleep
mode?
> +
> + /* Wait transition to Sleep mode */
> + fsleep(5);
> +
> + return 0;
> +}
[ ... ]
> @@ -115,6 +135,26 @@ static struct phy *can_transceiver_phy_xlate(struct device *dev,
> return priv->can_transceiver_phy[idx].generic_phy;
> }
>
> +static int can_transceiver_phy_suspend(struct device *dev)
> +{
> + struct can_transceiver_priv *priv = dev_get_drvdata(dev);
> + const struct can_transceiver_data *data = priv->data;
> + int ret, i;
> +
> + for (i = 0; i < priv->num_ch; i++) {
> + if (data->suspend) {
> + ret = data->suspend(&priv->can_transceiver_phy[i]);
> + if (ret)
> + return ret;
> + }
> + }
> +
> + return 0;
> +}
> +
> +static DEFINE_SIMPLE_DEV_PM_OPS(can_transceiver_phy_pm_ops,
> + can_transceiver_phy_suspend, NULL);
[Severity: High]
Does leaving the resume callback as NULL permanently leave the CAN PHY in
Sleep mode after a system resume?
Since the parent CAN MAC driver typically relies on the PHY framework for
power management and may not manually wake the PHY during its own resume
flow, could this prevent the CAN interface from becoming responsive again
until it is manually brought down and back up?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260630-phy-can-transceiver-suspend-resume-support-v1-1-6842c2d697e4@bootlin.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 3/4] arm64: dts: qcom: Add Shikra CQM SoM platform
From: Rakesh Kota @ 2026-06-30 12:42 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Kamal Wadhwa, linux-arm-msm, sashiko-reviews, Komal Bajaj, robh,
linux-phy, neil.armstrong, vkoul, olteanv, krzk+dt, conor+dt,
devicetree, Jishnu Prakash
In-Reply-To: <5idu4ljmcvcvzqsr5g73h2roxzs36l6xxc5ju6ovc5aitt3gx4@wmfqueyf2rj6>
On Sun, Jun 28, 2026 at 03:33:23PM +0300, Dmitry Baryshkov wrote:
> On Thu, Jun 25, 2026 at 09:11:19PM +0530, Kamal Wadhwa wrote:
> > On Wed, Jun 17, 2026 at 03:48:14PM +0300, Dmitry Baryshkov wrote:
> > > On Mon, 18 May 2026 at 14:49, Kamal Wadhwa
> > > <kamal.wadhwa@oss.qualcomm.com> wrote:
> > > >
> > > > On Sun, May 17, 2026 at 08:18:15PM +0300, Dmitry Baryshkov wrote:
> > > > > On Thu, May 14, 2026 at 04:09:18PM +0530, Kamal Wadhwa wrote:
> > > > > > On Wed, May 13, 2026 at 06:14:20PM +0300, Dmitry Baryshkov wrote:
> > > > > > > On 13/05/2026 17:29, Rakesh Kota wrote:
> > > > > > > > On Wed, May 13, 2026 at 03:01:47PM +0300, Dmitry Baryshkov wrote:
> > > > > > > > > On Wed, May 13, 2026 at 04:28:35AM +0000, sashiko-bot@kernel.org wrote:
> > > > > > > > > > Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> > > > > > > > > > - [High] The PMIC regulator definitions omit their required input supply dependencies (e.g., `vdd_s2-supply`, `vdd_l3-supply`), breaking the power hierarchy.
> > > > > > > > > > - [Medium] The device tree inaccurately hardcodes the `compatible` string to a different PMIC model (`qcom,rpm-pm2250-regulators`) instead of explicitly identifying the actual hardware (PM4125).
> > > > > > > > > > --
> > > > > > > > > > > +
> > > > > > > > > > > + pm4125_s2: s2 {
> > > > > > > > > > > + regulator-min-microvolt = <1000000>;
> > > > > > > > > > > + regulator-max-microvolt = <1200000>;
> > > > > > > > > > > + };
> > > > > > > > > >
> > > > > > > > > > Do these regulators need to explicitly define their input supply dependencies
> > > > > > > > > > such as vdd_s2-supply?
> > > > > > > > > >
> > > > > > > > > > Without these properties, the regulator framework might be unaware that the
> > > > > > > > > > PMIC regulators draw power from upstream supplies.
> > > > > > > > > >
> > > > > > > > > > If the kernel dynamically manages the upstream supply and its reference count
> > > > > > > > > > drops to zero, could it be disabled, causing an unexpected power loss for
> > > > > > > > > > downstream components?
> > > > > > > > >
> > > > > > > > > And this is a correct comment. Please provide missing supplies.
> > > > > > > > >
> > > > > > > > As per the Qualcomm system design, the parent-child supply relationship
> > > > > > > > is managed by the RPM firmware, not the Linux regulator framework. The
> > > > > > > > RPM ensures the parent supply is never disabled until all subsystem
> > > > > > > > votes are cleared.
> > > > > > >
> > > > > > > How is this different from other, previous platforms?
> > > > > >
> > > > > > This is not different. In the previous platforms too this is taken care from the
> > > > > > RPM/RPMH firmware side, the only case where we may need explicit vote to parent
> > > > > > is for non-rpmh/rpm regulator rails (like i2c based regulator pm8008), which
> > > > > > may have a RPM/RPMH regulator as a parent.
> > > > > >
> > > > > > Even on those previous targets the parent rail of all RPM/RPMH regulators are
> > > > > > internally voted by RPM/RPMH FW at proper voltage with required headroom
> > > > > > calculated based on the active child rails. This was done for all the
> > > > > > subsystems (including APPS) regulators.
> > > > > >
> > > > > > So no explicit handling from the APPS is required for parent supply.
> > > > >
> > > > > You are explaining the driver behaviour. But the question is about the
> > > > > hardware description. If there is no difference, please add necessary
> > > > > supplies back.
> > > >
> > > > I understand your concern about descibing the parent-child relation in the
> > > > devicetree, and given that we have been almost always followed this for all
> > > > the previous targets, it will expected of us to add them.
> > >
> > > Yes.
> > >
> > > >
> > > > However, we want to avoid the unnecessary access to the parent from APPS.
> > >
> > > Why? What is the reason? Do we want to do the same for all the
> > > platforms? Only for Shikra? Something else?
> > >
> > > > At the moment, I do not see a way to avoid that, if we add the parent
> > > > regulators.
> > >
> > > That depend on the answer to the previous question. In the end, we can
> > > make the driver ignore the parents by removing them from the regulator
> > > desc.
> >
> > Ok, this seems like a good suggestion, so you mean its ok if we define the
> > regulator desc's supply column with NULL? And only keep that in the DT?
> >
> > you mean like this?
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/regulator/qcom-rpmh-regulator.c?h=v7.1#n1453
> >
> > (please let me know if i got that right. thanks)
>
> Yes. Don't forget to explain in the commit message, why you are doing
> so.
Currently, Agatti uses the same PMIC, so we cannot set the driver
supply name reference to NULL. Since it's an older target,
we'll need to run a regression before making any driver-level changes.
Additionally, the child-to-parent regulator ganging differs between
Shikra and Agatti:
- On Agatti, l3 regulator is ganged with vdd_l13_l14_l15_l16
- On Shikra, l3 is ganged with vdd_l2_l3
Since vdd_l2_l3 is not present as a supply name in the driver, it will
be skipped by the driver and would only serve as a representational
reference in the DT.
We have two options to consider:
Option 1: Skip adding the child/parent relationship for Shikra for now,
since the DT bindings are not enforcing it. (Ref:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.yaml?h=v7.1)
Option 2: Go ahead and add the Shikra-specific ganging in DT now. Since
the supply name (vdd_l2_l3) does not match what the driver expects
(Agatti's mapping), it will be gracefully skipped by the driver — making
it safe to add for documentation/representation purposes without any
functional impact.
So,Please share your thoughts on above options ?
Thanks
Rakesh kota
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: clock: Drop incorrect usage of double '::'
From: Rob Herring (Arm) @ 2026-06-30 13:14 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Lee Jones, Sean Paul, Krzysztof Kozlowski, David Airlie,
Kyungmin Park, Lukasz Luba, Vinod Koul, Adam Skladowski,
Chanho Park, Wesley Cheng, Mark Brown, Linus Walleij, Alim Akhtar,
Abhinav Kumar, linux-gpio, linux-samsung-soc, Anusha Rao,
linux-mmc, Jonathan Marek, Greg Kroah-Hartman,
Javier Martinez Canillas, Taniya Das, linux-clk, Stephen Boyd,
linux-kernel, Zhang Rui, Srinivas Kandagatla, Barnabas Czeman,
Bjorn Andersson, Sunyeal Hong, freedreno, Stephan Gerhold,
Rob Clark, Simona Vetter, Andi Shyti, Niklas Söderlund,
linux-i2c, Brian Masney, Mauro Carvalho Chehab, Maarten Lankhorst,
Konrad Dybcio, Maxime Ripard, Daniel Lezcano, Rafael J. Wysocki,
Hans Verkuil, Dmitry Baryshkov, Sebastian Reichel, Chanwoo Choi,
Robert Marko, linux-sound, linux-usb, Pavel Machek, Peter Griffin,
linux-arm-msm, Marijn Suijten, Christian Marangi, Imran Shaik,
Neil Armstrong, dri-devel, Jiri Slaby, linux-phy, Shin Son,
Jessica Zhang, Liam Girdwood, Sam Protsenko, Tomasz Figa,
Magnus Damm, linux-renesas-soc, Jacek Anaszewski,
Sricharan Ramabadhran, Georgi Djakov, Conor Dooley,
Geert Uytterhoeven, devicetree, Luo Jie, linux-serial,
Jaehoon Chung, Andy Gross, Krishna Manikandan, Thomas Zimmermann,
linux-leds, Marek Szyprowski, Conor Dooley, linux-media,
Michael Turquette, Ulf Hansson, Bartlomiej Zolnierkiewicz,
Seung-Woo Kim, Inki Dae, linux-arm-kernel, Sireesh Kodali,
Sylwester Nawrocki, linux-pm, Alina Yu
In-Reply-To: <20260623054842.21831-3-krzysztof.kozlowski@oss.qualcomm.com>
On Tue, 23 Jun 2026 07:48:43 +0200, Krzysztof Kozlowski wrote:
> There is no use of double colon '::' in YAML. OTOH, the literal style
> block, e.g. using '|' treats all characters as content [1] therefore
> single use of ':' in descriptions is perfectly fine, whenever '|' is
> used.
>
> Cleanup existing code, so the confusing style won't be re-used in new
> contributions.
>
> Link: https://yaml.org/spec/1.2.2/#literal-style [1]
> Acked-by: Alim Akhtar <alim.akhtar@samsung.com>
> Acked-by: Conor Dooley <conor.dooley@microchip.com>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> ---
> I split the patches to avoid bounces from mailing list due to email size.
>
> This can go via clock tree (no dependencies)... or both could go via
> Rob's tree.
>
> Changes in v2:
> 1. Add tags (partial Reviews as Acks, as that's the meaning of Ack)
> ---
> .../devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml | 2 +-
> .../devicetree/bindings/clock/qcom,gcc-apq8064.yaml | 2 +-
> .../devicetree/bindings/clock/qcom,gcc-apq8084.yaml | 2 +-
> .../devicetree/bindings/clock/qcom,gcc-ipq6018.yaml | 2 +-
> .../devicetree/bindings/clock/qcom,gcc-ipq8064.yaml | 2 +-
> .../devicetree/bindings/clock/qcom,gcc-mdm9607.yaml | 2 +-
> .../devicetree/bindings/clock/qcom,gcc-mdm9615.yaml | 2 +-
> .../devicetree/bindings/clock/qcom,gcc-msm8660.yaml | 2 +-
> .../devicetree/bindings/clock/qcom,gcc-msm8909.yaml | 2 +-
> .../devicetree/bindings/clock/qcom,gcc-msm8916.yaml | 2 +-
> .../devicetree/bindings/clock/qcom,gcc-msm8953.yaml | 2 +-
> .../devicetree/bindings/clock/qcom,gcc-msm8974.yaml | 2 +-
> .../devicetree/bindings/clock/qcom,gcc-sdm660.yaml | 2 +-
> Documentation/devicetree/bindings/clock/qcom,gpucc.yaml | 2 +-
> .../devicetree/bindings/clock/qcom,ipq5018-gcc.yaml | 2 +-
> .../devicetree/bindings/clock/qcom,ipq9574-gcc.yaml | 2 +-
> .../devicetree/bindings/clock/qcom,qca8k-nsscc.yaml | 2 +-
> .../devicetree/bindings/clock/qcom,qcm2290-gpucc.yaml | 2 +-
> Documentation/devicetree/bindings/clock/qcom,rpmcc.yaml | 2 +-
> .../devicetree/bindings/clock/qcom,sc7280-lpasscorecc.yaml | 2 +-
> .../devicetree/bindings/clock/qcom,sc8280xp-lpasscc.yaml | 2 +-
> .../devicetree/bindings/clock/qcom,sm6115-lpasscc.yaml | 2 +-
> .../devicetree/bindings/clock/qcom,sm8350-videocc.yaml | 2 +-
> Documentation/devicetree/bindings/clock/qcom,videocc.yaml | 2 +-
> .../devicetree/bindings/clock/samsung,exynos5260-clock.yaml | 6 +++---
> .../devicetree/bindings/clock/samsung,exynos5410-clock.yaml | 2 +-
> .../devicetree/bindings/clock/samsung,exynos5433-clock.yaml | 2 +-
> .../devicetree/bindings/clock/samsung,exynos7-clock.yaml | 2 +-
> .../devicetree/bindings/clock/samsung,exynos850-clock.yaml | 2 +-
> .../bindings/clock/samsung,exynosautov9-clock.yaml | 2 +-
> .../bindings/clock/samsung,exynosautov920-clock.yaml | 2 +-
> .../devicetree/bindings/clock/samsung,s5pv210-clock.yaml | 2 +-
> 32 files changed, 34 insertions(+), 34 deletions(-)
>
Applied, thanks!
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 2/2] dt-bindings: Drop incorrect usage of double '::'
From: Rob Herring (Arm) @ 2026-06-30 13:14 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Sireesh Kodali, Stephen Boyd, Rob Clark, Wesley Cheng, Vinod Koul,
Seung-Woo Kim, Michael Turquette, freedreno, Linus Walleij,
Sam Protsenko, Rafael J. Wysocki, Alim Akhtar, linux-gpio,
linux-arm-msm, Taniya Das, Liam Girdwood, Imran Shaik, linux-phy,
Christian Marangi, Sebastian Reichel, Luo Jie,
Niklas Söderlund, Bjorn Andersson, Niklas Söderlund,
linux-kernel, linux-arm-kernel, dri-devel, Magnus Damm,
Conor Dooley, Brian Masney, linux-serial, linux-mmc, Sean Paul,
Kyungmin Park, Krishna Manikandan, linux-i2c, Konrad Dybcio,
Sylwester Nawrocki, Bartlomiej Zolnierkiewicz, Hans Verkuil,
Krzysztof Kozlowski, Chanwoo Choi, Sricharan Ramabadhran,
Andy Gross, Simona Vetter, Jaehoon Chung, Mauro Carvalho Chehab,
Zhang Rui, Maarten Lankhorst, Jessica Zhang, Tomasz Figa,
Shin Son, Marek Szyprowski, Robert Marko, linux-leds, Lee Jones,
Lukasz Luba, Srinivas Kandagatla, Georgi Djakov, Barnabas Czeman,
Greg Kroah-Hartman, Anusha Rao, linux-sound, Neil Armstrong,
linux-pm, Jiri Slaby, Marijn Suijten, Stephan Gerhold, linux-clk,
Mark Brown, Maxime Ripard, Pavel Machek, David Airlie,
Geert Uytterhoeven, Sunyeal Hong, Peter Griffin,
Sebastian Reichel, Andi Shyti, Dmitry Baryshkov, linux-usb,
Thomas Zimmermann, Jacek Anaszewski, Daniel Lezcano, Alina Yu,
Abhinav Kumar, Adam Skladowski, Conor Dooley,
Javier Martinez Canillas, Jonathan Marek, linux-renesas-soc,
linux-samsung-soc, Inki Dae, linux-media, Ulf Hansson,
Chanho Park, devicetree
In-Reply-To: <20260623054842.21831-4-krzysztof.kozlowski@oss.qualcomm.com>
On Tue, 23 Jun 2026 07:48:44 +0200, Krzysztof Kozlowski wrote:
> There is no use of double colon '::' in YAML. OTOH, the literal style
> block, e.g. using '|' treats all characters as content [1] therefore
> single use of ':' in descriptions is perfectly fine, whenever '|' is
> used.
>
> Cleanup existing code, so the confusing style won't be re-used in new
> contributions.
>
> Link: https://yaml.org/spec/1.2.2/#literal-style [1]
> Acked-by: Conor Dooley <conor.dooley@microchip.com>
> Acked-by: Alim Akhtar <alim.akhtar@samsung.com>
> Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com>
> Acked-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
> Acked-by: Mark Brown <broonie@kernel.org>
> Acked-by: Geert Uytterhoeven <geert+renesas@glider.be> # renesas
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>
> ---
>
> Intention for this patch is to go via Rob's tree.
>
> Changes in v2:
> 1. Add tags (partial Reviews as Acks, as that's the meaning of Ack)
> 2. Do not replace ::= in mux.
> ---
> .../devicetree/bindings/arm/qcom-soc.yaml | 4 ++--
> .../devicetree/bindings/arm/qcom.yaml | 4 ++--
> .../bindings/arm/samsung/samsung-soc.yaml | 4 ++--
> .../display/msm/dsi-controller-main.yaml | 20 +++++++++----------
> .../display/samsung/samsung,fimd.yaml | 4 ++--
> .../bindings/i2c/samsung,s3c2410-i2c.yaml | 2 +-
> .../interconnect/qcom,msm8998-bwmon.yaml | 2 +-
> .../interconnect/samsung,exynos-bus.yaml | 14 ++++++-------
> .../bindings/leds/qcom,pm8058-led.yaml | 4 ++--
> .../bindings/leds/skyworks,aat1290.yaml | 6 +++---
> .../bindings/media/cec/cec-gpio.yaml | 2 +-
> .../bindings/mmc/samsung,exynos-dw-mshc.yaml | 2 +-
> .../bindings/phy/samsung,mipi-video-phy.yaml | 4 ++--
> .../bindings/phy/samsung,usb2-phy.yaml | 2 +-
> .../bindings/phy/samsung,usb3-drd-phy.yaml | 2 +-
> .../bindings/pinctrl/samsung,pinctrl.yaml | 2 +-
> .../bindings/power/renesas,rcar-sysc.yaml | 2 +-
> .../bindings/power/reset/restart-handler.yaml | 8 ++++----
> .../bindings/regulator/maxim,max77802.yaml | 4 ++--
> .../bindings/regulator/richtek,rtq2208.yaml | 2 +-
> .../bindings/serial/qcom,msm-uartdm.yaml | 2 +-
> .../devicetree/bindings/slimbus/slimbus.yaml | 4 ++--
> .../bindings/soc/qcom/qcom,apr-services.yaml | 2 +-
> .../bindings/soc/qcom/qcom,rpmh-rsc.yaml | 8 ++++----
> .../bindings/soc/qcom/qcom,wcnss.yaml | 2 +-
> .../bindings/soc/renesas/renesas-soc.yaml | 4 ++--
> .../bindings/sound/qcom,q6asm-dais.yaml | 2 +-
> .../thermal/samsung,exynos-thermal.yaml | 4 ++--
> .../devicetree/bindings/usb/qcom,dwc3.yaml | 12 +++++------
> .../bindings/usb/qcom,snps-dwc3.yaml | 12 +++++------
> 30 files changed, 73 insertions(+), 73 deletions(-)
>
Applied, thanks!
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 05/13] mfd: replace linux/gpio.h inclusions
From: sashiko-bot @ 2026-06-30 13:28 UTC (permalink / raw)
To: Arnd Bergmann
Cc: olteanv, linux-phy, dmitry.torokhov, linux-input, vkoul,
neil.armstrong, linux-sunxi
In-Reply-To: <20260629132633.1300009-6-arnd@kernel.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The patch introduces a duplicate `#include <linux/gpio/consumer.h>` in `include/linux/mfd/ti-lmu.h`.
--
commit 19751af1f4af7549cf9f140e38427847c8babbd4
Author: Arnd Bergmann <arnd@arndb.de>
mfd: replace linux/gpio.h inclusions
This commit replaces the deprecated linux/gpio.h inclusion across various MFD
drivers and headers, converting them to use either linux/gpio/consumer.h or
linux/gpio/legacy.h as needed.
[ ... ]
> diff --git a/include/linux/mfd/ti-lmu.h b/include/linux/mfd/ti-lmu.h
> index 0bc0e81997987..5040c7d1e1b92 100644
> --- a/include/linux/mfd/ti-lmu.h
> +++ b/include/linux/mfd/ti-lmu.h
> @@ -10,7 +10,7 @@
> #ifndef __MFD_TI_LMU_H__
> #define __MFD_TI_LMU_H__
>
> -#include <linux/gpio.h>
> +#include <linux/gpio/consumer.h>
> #include <linux/notifier.h>
> #include <linux/regmap.h>
> #include <linux/gpio/consumer.h>
[Severity: Low]
This isn't a bug, but <linux/gpio/consumer.h> is now included twice. Would it
be better to just drop the replaced include here since the consumer header is
already present a few lines below?
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260629132633.1300009-1-arnd@kernel.org?part=5
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 07/13] ASoC: replace linux/gpio.h inclusions
From: sashiko-bot @ 2026-06-30 13:28 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-sunxi, linux-phy, linux-input, olteanv, vkoul,
neil.armstrong, dmitry.torokhov
In-Reply-To: <20260629132633.1300009-8-arnd@kernel.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The patch introduces duplicate `#include <linux/gpio/consumer.h>` directives in `cs42l84.c` and `dmic.c`.
--
commit 5e88ad9a5863dbafbe414c688b31a85827de20da
Author: Arnd Bergmann <arnd@arndb.de>
ASoC: replace linux/gpio.h inclusions
This commit updates multiple ASoC codecs to use linux/gpio/consumer.h instead
of the deprecated linux/gpio.h header.
> diff --git a/sound/soc/codecs/cs42l84.c b/sound/soc/codecs/cs42l84.c
> index f2a58163de0ed..36c3abc21fedc 100644
> --- a/sound/soc/codecs/cs42l84.c
> +++ b/sound/soc/codecs/cs42l84.c
> @@ -16,7 +16,7 @@
> #include <linux/init.h>
> #include <linux/delay.h>
> #include <linux/i2c.h>
> -#include <linux/gpio.h>
> +#include <linux/gpio/consumer.h>
[Severity: Low]
This isn't a bug, but does this create a duplicate include? It appears
linux/gpio/consumer.h is already included further down in this file. Could we
simply drop the linux/gpio.h include entirely?
> #include <linux/regmap.h>
> #include <linux/slab.h>
> #include <linux/acpi.h>
[ ... ]
> diff --git a/sound/soc/codecs/dmic.c b/sound/soc/codecs/dmic.c
> index 61e1bf1b3c9e6..8b05d6f9b429b 100644
> --- a/sound/soc/codecs/dmic.c
> +++ b/sound/soc/codecs/dmic.c
> @@ -6,7 +6,7 @@
> */
>
> #include <linux/delay.h>
> -#include <linux/gpio.h>
> +#include <linux/gpio/consumer.h>
> #include <linux/gpio/consumer.h>
[Severity: Low]
This isn't a bug, but should we just delete the old include line? Replacing
it leaves two identical includes back-to-back.
> #include <linux/platform_device.h>
> #include <linux/regulator/consumer.h>
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260629132633.1300009-1-arnd@kernel.org?part=7
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 08/13] pcmcia: replace linux/gpio.h inclusions
From: sashiko-bot @ 2026-06-30 13:28 UTC (permalink / raw)
To: Arnd Bergmann
Cc: olteanv, linux-phy, linux-sunxi, vkoul, dmitry.torokhov,
linux-input, neil.armstrong
In-Reply-To: <20260629132633.1300009-9-arnd@kernel.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Invalid resource cleanup on error path leading to potential double-free of a devres-managed GPIO descriptor.
--
commit a1a20647914d78d6a15655dea889e9d53c734136
Author: Arnd Bergmann <arnd@arndb.de>
pcmcia: replace linux/gpio.h inclusions
The pcmcia drivers all use the legacy interfaces, so convert to
include linux/gpio/legacy.h instead.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
[ ... ]
> diff --git a/drivers/pcmcia/sa1100_h3600.c b/drivers/pcmcia/sa1100_h3600.c
> index 10cb99c20a7f5..6c52d90795eb4 100644
> --- a/drivers/pcmcia/sa1100_h3600.c
> +++ b/drivers/pcmcia/sa1100_h3600.c
> @@ -11,7 +11,7 @@
> #include <linux/interrupt.h>
> #include <linux/init.h>
> #include <linux/delay.h>
> -#include <linux/gpio.h>
> +#include <linux/gpio/legacy.h>
[Severity: High]
This isn't a bug introduced by this patch, but I noticed a pre-existing
issue while reviewing the GPIO include changes.
Does the error path in h3600_pcmcia_hw_init() cause a double-free of a
devres-managed GPIO descriptor?
If gpio_request(H3XXX_EGPIO_OPT_NVRAM_ON) or subsequent legacy GPIO requests
fail, the code jumps to or falls through to the err01 label:
drivers/pcmcia/sa1100_h3600.c:h3600_pcmcia_hw_init() {
...
err06: gpio_free(H3XXX_EGPIO_CARD_RESET);
err05: gpio_free(H3XXX_EGPIO_OPT_RESET);
err04: gpio_free(H3XXX_EGPIO_OPT_ON);
err03: gpio_free(H3XXX_EGPIO_OPT_NVRAM_ON);
err01: gpio_free(H3XXX_GPIO_PCMCIA_IRQ0);
return err;
}
The err01 label incorrectly frees H3XXX_GPIO_PCMCIA_IRQ0. This GPIO is
managed by devres and was not explicitly requested using gpio_request() in
this function.
When devres cleans up the failed probe, it will attempt to free the GPIO
again. This could lead to a double-free, gpiolib state corruption, kernel
warnings, or accidentally freeing a GPIO acquired by a concurrent driver.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260629132633.1300009-1-arnd@kernel.org?part=8
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 11/13] Input: matrix_keyboard - replace linux/gpio.h inclusion
From: sashiko-bot @ 2026-06-30 13:28 UTC (permalink / raw)
To: Arnd Bergmann
Cc: olteanv, linux-phy, linux-sunxi, dmitry.torokhov, vkoul,
neil.armstrong, linux-input
In-Reply-To: <20260629132633.1300009-12-arnd@kernel.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Redundant header inclusion of <linux/gpio/consumer.h>
--
commit b60f4c5bf1d6c83cc34b3ab6030725489bd7c3e5
Author: Arnd Bergmann <arnd@arndb.de>
Input: matrix_keyboard - replace linux/gpio.h inclusion
This commit replaces the inclusion of the deprecated linux/gpio.h header
with linux/gpio/consumer.h in the matrix keypad driver. It prepares the
code for the removal of linux/gpio.h.
> diff --git a/drivers/input/keyboard/matrix_keypad.c b/drivers/input/keyboard/matrix_keypad.c
> index e50a6fea9a602..98d0269a978fe 100644
> --- a/drivers/input/keyboard/matrix_keypad.c
> +++ b/drivers/input/keyboard/matrix_keypad.c
> @@ -16,7 +16,7 @@
> #include <linux/interrupt.h>
> #include <linux/jiffies.h>
> #include <linux/module.h>
> -#include <linux/gpio.h>
> +#include <linux/gpio/consumer.h>
[Severity: Low]
Does this result in a redundant inclusion? Looking at matrix_keypad.c,
<linux/gpio/consumer.h> is already included earlier in the file:
#include <linux/types.h>
#include <linux/delay.h>
#include <linux/gpio/consumer.h>
#include <linux/platform_device.h>
Could the old <linux/gpio.h> inclusion just be removed entirely instead of
being replaced?
> #include <linux/input/matrix_keypad.h>
> #include <linux/slab.h>
> #include <linux/of.h>
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260629132633.1300009-1-arnd@kernel.org?part=11
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 12/13] gpib: gpio: replace linux/gpio.h inclusion
From: sashiko-bot @ 2026-06-30 13:28 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-phy, linux-sunxi, neil.armstrong, vkoul, linux-input,
dmitry.torokhov, olteanv
In-Reply-To: <20260629132633.1300009-13-arnd@kernel.org>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
New issues:
- [Low] The patch introduces redundant duplicate `#include <linux/gpio/consumer.h>` statements in multiple files.
Pre-existing issues:
- [High] Missing bounds check on `priv->count` in `bb_DAV_interrupt()` can lead to a buffer overflow.
--
commit 198cff3fadd8f7ab5db98a0ff2a666f4ac7f1bf0
Author: Arnd Bergmann <arnd@arndb.de>
gpib: gpio: replace linux/gpio.h inclusion
linux/gpio.h is going away, so use linux/gpio/consumer.h instead.
> diff --git a/drivers/gpib/gpio/gpib_bitbang.c b/drivers/gpib/gpio/gpib_bitbang.c
> index 0e227980b493a..2e8d895db06a5 100644
> --- a/drivers/gpib/gpio/gpib_bitbang.c
> +++ b/drivers/gpib/gpio/gpib_bitbang.c
> @@ -64,7 +64,7 @@
> #include <linux/gpio/consumer.h>
> #include <linux/gpio/driver.h>
> #include <linux/gpio/machine.h>
> -#include <linux/gpio.h>
> +#include <linux/gpio/consumer.h>
[Severity: Low]
This isn't a bug, but does this introduce a duplicate include of
linux/gpio/consumer.h? It appears to already be included a few lines above.
Similar duplicate includes might have been added to other files like
drivers/input/keyboard/matrix_keypad.c and drivers/net/phy/mdio_device.c
if they were also part of this series.
> #include <linux/irq.h>
>
> static int sn7516x_used = 1, sn7516x;
While reviewing this file, I noticed a separate issue in bb_DAV_interrupt().
[Severity: High]
This is a pre-existing issue, but does this lack of a bounds check on
priv->count lead to a buffer overflow?
drivers/gpib/gpio/gpib_bitbang.c:bb_DAV_interrupt() {
...
priv->rbuf[priv->count++] = get_data_lines();
priv->end = !gpiod_get_value(EOI);
...
}
If the hardware line DAV goes low multiple times while priv->r_busy is set
without waiting for the normal NRFD/NDAC handshake, could priv->count exceed
the allocated buffer size and corrupt memory?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260629132633.1300009-1-arnd@kernel.org?part=12
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 13/13] gpiolib: remove linux/gpio.h
From: sashiko-bot @ 2026-06-30 13:28 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-sunxi, dmitry.torokhov, neil.armstrong, olteanv, vkoul,
linux-phy, linux-input
In-Reply-To: <20260629132633.1300009-14-arnd@kernel.org>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Low] Removing `include/linux/gpio.h` breaks the build for multiple drivers across the kernel tree that still include it and rely on it for legacy GPIO declarations.
- [Low] Typographical error in `drivers/gpio/TODO` where `legacy.h` is misspelled as `lagacy.h`.
--
commit eb8b9c8709d4fc96f518f3578deb6f0d05993604
Author: Arnd Bergmann <arnd@arndb.de>
gpiolib: remove linux/gpio.h
This commit removes the include/linux/gpio.h header entirely, cleaning up
leftover bits under the assumption that all drivers have been converted to
consumer.h or legacy.h. It also updates internal gpiolib includes and a
TODO file accordingly.
> diff --git a/drivers/gpio/TODO b/drivers/gpio/TODO
> index 7ce80fde1f17e..894c7e1af252a 100644
> --- a/drivers/gpio/TODO
> +++ b/drivers/gpio/TODO
> @@ -52,9 +52,7 @@ Work items:
> base can be made dynamic (set to -1) if CONFIG_GPIO_SYSFS is disabled.
>
> - When this work is complete (will require some of the items in the
> - following ongoing work as well) we can delete the old global
> - numberspace accessors from <linux/gpio.h> and eventually delete
> - <linux/gpio.h> altogether.
> + following ongoing work as well) we can delete <linux/gpio/lagacy.h>.
^^^^^^^^
[Severity: Low]
This isn't a bug, but there is a typo here (lagacy.h instead of legacy.h).
[ ... ]
> diff --git a/include/linux/gpio.h b/include/linux/gpio.h
> deleted file mode 100644
> index b0d4942a65de2..0000000000000
> --- a/include/linux/gpio.h
> +++ /dev/null
> @@ -1,22 +0,0 @@
[ ... ]
> -#ifdef CONFIG_GPIOLIB_LEGACY
> -#include <linux/gpio/legacy.h>
> -#endif /* CONFIG_GPIOLIB_LEGACY */
> -
> -#endif /* __LINUX_GPIO_H */
[Severity: Low]
Does removing this header break the build for remaining unconverted legacy
GPIO consumers?
For example, drivers/input/keyboard/gpio_keys.c:gpio_keys_setup_key() still
appears to rely on this header for devm_gpio_request_one():
error = devm_gpio_request_one(dev, button->gpio, GPIOF_IN, desc);
Similarly, drivers/leds/leds-gpio.c:gpio_led_get_gpiod() also relies on it:
ret = devm_gpio_request_one(dev, template->gpio, GPIOF_OUT_INIT_LOW,
template->name);
And arch/x86/platform/olpc/olpc-xo1-sci.c:setup_ec_sci() still uses
gpio_request():
r = gpio_request(OLPC_GPIO_ECSCI, "OLPC-ECSCI");
Will these drivers fail to compile since functions like devm_gpio_request_one()
and gpio_request() will now be missing or implicitly declared?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260629132633.1300009-1-arnd@kernel.org?part=13
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 06/13] [net-next] net: replace linux/gpio.h inclusions
From: sashiko-bot @ 2026-06-30 13:28 UTC (permalink / raw)
To: Arnd Bergmann
Cc: vkoul, dmitry.torokhov, linux-input, linux-sunxi, neil.armstrong,
olteanv, linux-phy
In-Reply-To: <20260629132633.1300009-7-arnd@kernel.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Duplicate inclusion of `<linux/gpio/consumer.h>` caused by an unchecked find-and-replace.
--
commit cb55ce48e23e6753d04ac5f664585feb999f1fcd
Author: Arnd Bergmann <arnd@arndb.de>
net: replace linux/gpio.h inclusions
This commit replaces obsolete linux/gpio.h includes with linux/gpio/consumer.h
or linux/gpio/legacy.h across various network drivers where possible.
> diff --git a/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c b/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
> index 48b94ce774906..88c5c52e0e381 100644
> --- a/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
> +++ b/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
> @@ -16,7 +16,7 @@
> #include <linux/net_tstamp.h>
> #include <linux/ptp_classify.h>
> #include <linux/ptp_pch.h>
> -#include <linux/gpio.h>
> +#include <linux/gpio/consumer.h>
[Severity: Low]
Does this create a duplicate include in pch_gbe_main.c?
Since linux/gpio/consumer.h is already included earlier in the file alongside
linux/gpio/machine.h, changing this include results in it being included
twice. Can this replaced include simply be removed?
>
> #define PCH_GBE_MAR_ENTRIES 16
[ ... ]
> diff --git a/drivers/net/phy/mdio_device.c b/drivers/net/phy/mdio_device.c
> index 56080d3d2d25e..a18263d5bb029 100644
> --- a/drivers/net/phy/mdio_device.c
> +++ b/drivers/net/phy/mdio_device.c
> @@ -8,7 +8,7 @@
>
> #include <linux/delay.h>
> #include <linux/errno.h>
> -#include <linux/gpio.h>
> +#include <linux/gpio/consumer.h>
> #include <linux/gpio/consumer.h>
[Severity: Low]
Did the automated replacement result in consecutive duplicate includes here?
It looks like mdio_device.c already included linux/gpio/consumer.h right below
the old linux/gpio.h include. Should we just drop the old include entirely
instead of replacing it?
> #include <linux/init.h>
> #include <linux/interrupt.h>
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260629132633.1300009-1-arnd@kernel.org?part=6
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 09/13] phy: replace linux/gpio.h inclusions
From: sashiko-bot @ 2026-06-30 13:28 UTC (permalink / raw)
To: Arnd Bergmann
Cc: neil.armstrong, linux-input, dmitry.torokhov, linux-sunxi, vkoul,
linux-phy, olteanv
In-Reply-To: <20260629132633.1300009-10-arnd@kernel.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Replacing `#include <linux/gpio.h>` with `#include <linux/gpio/consumer.h>` results in duplicate include directives.
--
commit 172e670e08c06c1b704f9f5d80187a66ba9bb20c
Author: Arnd Bergmann <arnd@arndb.de>
phy: replace linux/gpio.h inclusions
linux/gpio.h should no longer be used, convert these instead to
either linux/gpio/consumer.h or linux/gpio/legacy.h as needed.
> diff --git a/drivers/phy/broadcom/phy-bcm-ns2-usbdrd.c b/drivers/phy/broadcom/phy-bcm-ns2-usbdrd.c
> index 8473fa5745296..d9c06129ed23e 100644
> --- a/drivers/phy/broadcom/phy-bcm-ns2-usbdrd.c
> +++ b/drivers/phy/broadcom/phy-bcm-ns2-usbdrd.c
> @@ -3,7 +3,7 @@
>
> #include <linux/delay.h>
> #include <linux/extcon-provider.h>
> -#include <linux/gpio.h>
> +#include <linux/gpio/consumer.h>
> #include <linux/gpio/consumer.h>
[Severity: Low]
This isn't a bug, but the replacement leaves us with consecutive duplicate
linux/gpio/consumer.h inclusions. Could the redundant include be removed?
[ ... ]
> diff --git a/drivers/phy/ti/phy-j721e-wiz.c b/drivers/phy/ti/phy-j721e-wiz.c
> index 7531a8a049123..2233babc00781 100644
> --- a/drivers/phy/ti/phy-j721e-wiz.c
> +++ b/drivers/phy/ti/phy-j721e-wiz.c
> @@ -11,7 +11,7 @@
> #include <linux/slab.h>
> #include <linux/clk.h>
> #include <linux/clk-provider.h>
> -#include <linux/gpio.h>
> +#include <linux/gpio/consumer.h>
> #include <linux/gpio/consumer.h>
[Severity: Low]
This isn't a bug, but similar to the broadcom phy driver, this creates
duplicate linux/gpio/consumer.h inclusions here as well. Should the second
one be dropped?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260629132633.1300009-1-arnd@kernel.org?part=9
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 13/13] gpiolib: remove linux/gpio.h
From: Arnd Bergmann @ 2026-06-30 13:31 UTC (permalink / raw)
To: sashiko-reviews
Cc: linux-sunxi, Dmitry Torokhov, Neil Armstrong, Vladimir Oltean,
Vinod Koul, linux-phy, linux-input
In-Reply-To: <20260630132838.113F91F00A3A@smtp.kernel.org>
On Tue, Jun 30, 2026, at 15:28, sashiko-bot@kernel.org wrote:
>> - When this work is complete (will require some of the items in the
>> - following ongoing work as well) we can delete the old global
>> - numberspace accessors from <linux/gpio.h> and eventually delete
>> - <linux/gpio.h> altogether.
>> + following ongoing work as well) we can delete <linux/gpio/lagacy.h>.
> ^^^^^^^^
> [Severity: Low]
> This isn't a bug, but there is a typo here (lagacy.h instead of legacy.h).
Fixed now for v2.
>> -#ifdef CONFIG_GPIOLIB_LEGACY
>> -#include <linux/gpio/legacy.h>
>> -#endif /* CONFIG_GPIOLIB_LEGACY */
>> -
>> -#endif /* __LINUX_GPIO_H */
>
> [Severity: Low]
> Does removing this header break the build for remaining unconverted legacy
> GPIO consumers?
There are a few more patches in flight that all have to be applied
before this one.
Arnd
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 08/13] pcmcia: replace linux/gpio.h inclusions
From: Arnd Bergmann @ 2026-06-30 13:36 UTC (permalink / raw)
To: sashiko-reviews
Cc: Vladimir Oltean, linux-phy, linux-sunxi, Vinod Koul,
Dmitry Torokhov, linux-input, Neil Armstrong
In-Reply-To: <20260630132833.450051F00A3A@smtp.kernel.org>
On Tue, Jun 30, 2026, at 15:28, sashiko-bot@kernel.org wrote:
> [Severity: High]
> This isn't a bug introduced by this patch, but I noticed a pre-existing
> issue while reviewing the GPIO include changes.
>
> Does the error path in h3600_pcmcia_hw_init() cause a double-free of a
> devres-managed GPIO descriptor?
Yes, there are many bugs in the old pcmcia drivers. I expect that
we will remove these soon, as I plan to drop all the sa1100 and pxa
board files early next year.
Arnd
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 09/13] phy: replace linux/gpio.h inclusions
From: Arnd Bergmann @ 2026-06-30 13:37 UTC (permalink / raw)
To: sashiko-reviews
Cc: Neil Armstrong, linux-input, Dmitry Torokhov, linux-sunxi,
Vinod Koul, linux-phy, Vladimir Oltean
In-Reply-To: <20260630132842.39AF01F000E9@smtp.kernel.org>
On Tue, Jun 30, 2026, at 15:28, sashiko-bot@kernel.org wrote:
>
> [Severity: Low]
> This isn't a bug, but the replacement leaves us with consecutive duplicate
> linux/gpio/consumer.h inclusions. Could the redundant include be removed?
This was already reported and fixed earlier, all of these will
be addressed in v2.
Arnd
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH v3 net-next 1/2] arm64: dts: ti: Add PLL1 refclk to J784S4 SoC SERDES node
From: Gokul Praveen @ 2026-06-30 13:43 UTC (permalink / raw)
To: conor+dt, devicetree, krzk+dt, linux-arm-kernel, linux-kernel,
linux-phy, neil.armstrong, nm, robh, sjakhade, kristo, vigneshr,
vkoul, yamonkar
In-Reply-To: <20260630134324.61085-1-g-praveen@ti.com>
Add PLL1 refclk to "clocks" and "clock-names" parameter of SERDES2 node
as "assigned clocks" parameter has PLL1 and serdes multilink configuration
fails without PLL1.
Signed-off-by: Gokul Praveen <g-praveen@ti.com>
---
arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi b/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
index 78fcd0c40abc..da8d582574d0 100644
--- a/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
@@ -122,8 +122,9 @@ serdes2: serdes@5020000 {
resets = <&serdes_wiz2 0>;
reset-names = "torrent_reset";
clocks = <&serdes_wiz2 TI_WIZ_PLL0_REFCLK>,
+ <&serdes_wiz2 TI_WIZ_PLL1_REFCLK>,
<&serdes_wiz2 TI_WIZ_PHY_EN_REFCLK>;
- clock-names = "refclk", "phy_en_refclk";
+ clock-names = "refclk","pll1_refclk", "phy_en_refclk";
assigned-clocks = <&serdes_wiz2 TI_WIZ_PLL0_REFCLK>,
<&serdes_wiz2 TI_WIZ_PLL1_REFCLK>,
<&serdes_wiz2 TI_WIZ_REFCLK_DIG>;
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v3 net-next 0/2] Add support for dual port USXGMII+SGMII
From: Gokul Praveen @ 2026-06-30 13:43 UTC (permalink / raw)
To: conor+dt, devicetree, krzk+dt, linux-arm-kernel, linux-kernel,
linux-phy, neil.armstrong, nm, robh, sjakhade, kristo, vigneshr,
vkoul, yamonkar
This patch series enables dual port USXGMII and SGMII Ethernet mode
support on the TI J784S4 EVM platform using the CPSW9G Ethernet switch.
The CPSW9G instance supports both SGMII and USXGMII modes simultaneously
on MAC Ports 1 and 2, which connect to ENET Expansion 1 and ENET
Expansion 2 slots through the SERDES2 instance. The series includes:
Multilink SERDES configuration support added to the SERDES2 node by adding
the PLL1 refclk.
v2 <==> v1
===========
* Added modifications to the device tree bindings documentation.
v3 <=> v2
==========
* Added net-next suffix in the patch subject.
* Added a separate bindings patch and added appropriate subject
format expected for Bindings patches.
* Updated the cover letter description
Gokul Praveen (2):
arm64: dts: ti: Add PLL1 refclk to J784S4 SoC SERDES node
dt-bindings: phy: cadence-torrent: Update property values to support 3
clocks
.../devicetree/bindings/phy/phy-cadence-torrent.yaml | 4 ++--
arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi | 3 ++-
2 files changed, 4 insertions(+), 3 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