* 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
* [PATCH v3 net-next 2/2] dt-bindings: phy: cadence-torrent: Update property values to support 3 clocks
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>
Update maxItems value of "clocks" property to 3 as description of
this parameter already indicates 3 clocks(refclk,pll1_refclk(optional)
and phy_en_refclk(optional))
Update the "clock-names" property as well with the 3 clocks.
Signed-off-by: Gokul Praveen <g-praveen@ti.com>
---
.../devicetree/bindings/phy/phy-cadence-torrent.yaml | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml b/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml
index 9af39b33646a..54fe78da297a 100644
--- a/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml
+++ b/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml
@@ -34,7 +34,7 @@ properties:
clocks:
minItems: 1
- maxItems: 2
+ maxItems: 3
description:
PHY input reference clocks - refclk (for PLL0) & pll1_refclk (for PLL1).
pll1_refclk is optional and used for multi-protocol configurations requiring
@@ -47,7 +47,7 @@ properties:
minItems: 1
items:
- const: refclk
- - enum: [ pll1_refclk, phy_en_refclk ]
+ - enum: [refclk, pll1_refclk, phy_en_refclk ]
reg:
minItems: 1
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* Re: [PATCH v3 net-next 2/2] dt-bindings: phy: cadence-torrent: Update property values to support 3 clocks
From: sashiko-bot @ 2026-06-30 13:48 UTC (permalink / raw)
To: Gokul Praveen
Cc: neil.armstrong, olteanv, devicetree, linux-phy, conor+dt, robh,
vkoul
In-Reply-To: <20260630134324.61085-3-g-praveen@ti.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The `clock-names` schema definition incorrectly restricts the array to a maximum of 2 items and allows duplicate clock names. While the commit correctly updates `clocks` to allow `maxItems: 3`, it only modifies the second element of the `items` array for `clock-names`. In `dt-schema` (based on JSON Schema), defining `items` as an array of schemas implicitly limits the maximum number of items to the length of that array (because `additionalItems` is implicitly false). As a result, a device tree specifying 3 clocks will fail `dt_binding_check` validation. Additionally, adding `refclk` to the second element's `enum` creates a logic error, permitting redundant sequences such as `clock-names = "refclk", "refclk";`.
--
commit d737f6b2f91949e839e21f62c39ca9db8f322775
Author: Gokul Praveen <g-praveen@ti.com>
dt-bindings: phy: cadence-torrent: Update property values to support 3 clocks
This commit updates the Cadence Torrent PHY device tree binding to support up
to 3 clocks. It increases the maxItems of the clocks property and updates the
clock-names property.
> diff --git a/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml b/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml
> index 9af39b33646ac..54fe78da297a2 100644
> --- a/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml
> +++ b/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml
> @@ -34,7 +34,7 @@ properties:
>
> clocks:
> minItems: 1
> - maxItems: 2
> + maxItems: 3
> description:
> PHY input reference clocks - refclk (for PLL0) & pll1_refclk (for PLL1).
[ ... ]
> @@ -47,7 +47,7 @@ properties:
> minItems: 1
> items:
> - const: refclk
> - - enum: [ pll1_refclk, phy_en_refclk ]
> + - enum: [refclk, pll1_refclk, phy_en_refclk ]
[Severity: Medium]
Will this fail schema validation when a device tree specifies 3 clocks?
Because the items sequence for clock-names only defines two elements, it
implicitly restricts the array to a maximum of 2 items. Even though the clocks
property was updated to maxItems: 3 above, the clock-names array is now
mismatched and will reject 3 items during dt_binding_check.
Also, does this unintentionally allow duplicate clock names? Adding refclk to
the second element's enum makes it possible to define a redundant sequence
like clock-names = "refclk", "refclk".
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260630134324.61085-1-g-praveen@ti.com?part=2
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 3/4] arm64: dts: qcom: Add Shikra CQM SoM platform
From: Konrad Dybcio @ 2026-06-30 13:50 UTC (permalink / raw)
To: Rakesh Kota, 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: <20260630124220.4lja4zshpf66kwj3@hu-kotarake-hyd.qualcomm.com>
On 6/30/26 2:42 PM, Rakesh Kota wrote:
> 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
Is it configurable on the PMIC level? I was under the impression the
supply maps are fixed in hardware. Is there a chance the agatti
description is just wrong?
Konrad
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v3 net-next 1/2] arm64: dts: ti: Add PLL1 refclk to J784S4 SoC SERDES node
From: sashiko-bot @ 2026-06-30 13:53 UTC (permalink / raw)
To: Gokul Praveen
Cc: linux-phy, devicetree, olteanv, vkoul, neil.armstrong, conor+dt,
robh
In-Reply-To: <20260630134324.61085-2-g-praveen@ti.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
New issues:
- [Low] Adding a third clock to the 'serdes2' node violates the 'phy-cadence-torrent.yaml' DT binding. The subsequent binding update in the series is logically incomplete and fails to resolve the validation error.
- [Low] Missing whitespace after the comma in the 'clock-names' list.
Pre-existing issues:
- [High] This problem wasn't introduced by this patch, but the commit fails to comprehensively fix the issue. It adds 'pll1_refclk' to fix multilink configuration for 'serdes2', but ignores identical SERDES nodes ('serdes0', 'serdes1', 'serdes4') that share the exact same bug.
--
commit c37d528887d49433e9d33970e77ad622c557ad5e
Author: Gokul Praveen <g-praveen@ti.com>
arm64: dts: ti: Add PLL1 refclk to J784S4 SoC SERDES node
This commit adds the PLL1 refclk to the clocks and clock-names parameters
for the SERDES2 node. It addresses a multilink configuration failure that
occurs without PLL1 being present in the clocks list.
> diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi b/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
> index 78fcd0c40abcf..da8d582574d03 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>;
[Severity: High]
This is a pre-existing issue, but does the same fix need to be applied to
the other identical serdes nodes?
Other nodes like serdes0, serdes1, and serdes4 in
arch/arm64/boot/dts/ti/k3-j784s4-j742s2-main-common.dtsi share the exact same
configuration issue where TI_WIZ_PLL1_REFCLK is in assigned-clocks but absent
from clocks:
clocks = <&serdes_wiz0 TI_WIZ_PLL0_REFCLK>,
<&serdes_wiz0 TI_WIZ_PHY_EN_REFCLK>;
clock-names = "refclk", "phy_en_refclk";
assigned-clocks = <&serdes_wiz0 TI_WIZ_PLL0_REFCLK>,
<&serdes_wiz0 TI_WIZ_PLL1_REFCLK>,
<&serdes_wiz0 TI_WIZ_REFCLK_DIG>;
Since serdes0 is also configured for multilink (PCIe + USB), will its
configuration fail without a similar update?
> - clock-names = "refclk", "phy_en_refclk";
> + clock-names = "refclk","pll1_refclk", "phy_en_refclk";
[Severity: Low]
Will this addition cause make dtbs_check to fail?
Adding a third item to clock-names exceeds the currently defined items in the
phy-cadence-torrent.yaml binding.
Even if a subsequent patch in the series updates the schema by modifying
maxItems and the enum for the second item, dt-schema enforces
additionalItems: false for arrays.
Unless a third item definition is explicitly added to the items array in the
schema, won't validation fail for this node?
[Severity: Low]
this isn't a bug, but there is a missing space after the first comma.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260630134324.61085-1-g-praveen@ti.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 v4 3/5] arm64: dts: qcom: Add Shikra CQ2390M SoM platform
From: Konrad Dybcio @ 2026-06-30 13:56 UTC (permalink / raw)
To: Komal Bajaj, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Vinod Koul, Neil Armstrong,
Wesley Cheng, Ulf Hansson
Cc: linux-arm-msm, devicetree, linux-kernel, linux-phy, linux-mmc,
monish.chunara, Rakesh Kota
In-Reply-To: <20260527-shikra-dt-v4-3-b5ca1fa0b392@oss.qualcomm.com>
On 5/27/26 5:53 PM, Komal Bajaj wrote:
> Add device tree include for the CQ2390M variant of the Shikra
> System-on-Module, a compact compute module integrating the Shikra SoC
> and PMIC for IoT applications, designed to mount on carrier boards.
>
> - shikra-cqm-som.dtsi: Retail SoM with modem (PM4125 and PM8005 PMIC)
>
> The DTSI includes the common shikra.dtsi, adds PM4125 and PM8005 PMIC
> peripheral definitions specific to this variant. Since PM8005 regulators
> are controlled by rpmpd, so disabling the pm8005 regulators.
>
> Co-developed-by: Rakesh Kota <rakesh.kota@oss.qualcomm.com>
> Signed-off-by: Rakesh Kota <rakesh.kota@oss.qualcomm.com>
> Signed-off-by: Komal Bajaj <komal.bajaj@oss.qualcomm.com>
> ---
I'll pretend I don't see an issue with a volume button living on the
SoM
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v4 4/5] arm64: dts: qcom: Add Shikra IQ2390S SoM platform
From: Konrad Dybcio @ 2026-06-30 13:56 UTC (permalink / raw)
To: Komal Bajaj, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Vinod Koul, Neil Armstrong,
Wesley Cheng, Ulf Hansson
Cc: linux-arm-msm, devicetree, linux-kernel, linux-phy, linux-mmc,
monish.chunara
In-Reply-To: <20260527-shikra-dt-v4-4-b5ca1fa0b392@oss.qualcomm.com>
On 5/27/26 5:53 PM, Komal Bajaj wrote:
> Add device tree include for the IQ2390S variant of the Shikra
> System-on-Module, an industrial compute module integrating the Shikra
> SoC and PMIC for industrial IoT applications, designed to mount on
> carrier boards.
>
> - shikra-iqs-som.dtsi: Industrial SoM without modem (PM8150 PMIC)
>
> The DTSI includes the common shikra.dtsi and adds PM8150 PMIC regulator
> definitions specific to this variant.
>
> Signed-off-by: Komal Bajaj <komal.bajaj@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v6 3/5] arm64: dts: qcom: Add Shikra CQ2390M SoM platform
From: Konrad Dybcio @ 2026-06-30 13:57 UTC (permalink / raw)
To: Komal Bajaj, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Vinod Koul, Neil Armstrong,
Wesley Cheng, Ulf Hansson
Cc: linux-arm-msm, devicetree, linux-kernel, linux-phy, linux-mmc,
monish.chunara, Rakesh Kota, Dmitry Baryshkov
In-Reply-To: <20260612-shikra-dt-v6-3-6b6cb58db477@oss.qualcomm.com>
On 6/12/26 7:27 PM, Komal Bajaj wrote:
> Add device tree include for the CQ2390M variant of the Shikra
> System-on-Module, a compact compute module integrating the Shikra SoC
> and PMIC for IoT applications, designed to mount on carrier boards.
>
> - shikra-cqm-som.dtsi: Retail SoM with modem (PM4125 and PM8005 PMIC)
>
> The DTSI includes the common shikra.dtsi, adds PM4125 and PM8005 PMIC
> peripheral definitions specific to this variant. Since PM8005 regulators
> are controlled by rpmpd, so disabling the pm8005 regulators.
>
> Co-developed-by: Rakesh Kota <rakesh.kota@oss.qualcomm.com>
> Signed-off-by: Rakesh Kota <rakesh.kota@oss.qualcomm.com>
> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> Signed-off-by: Komal Bajaj <komal.bajaj@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v6 4/5] arm64: dts: qcom: Add Shikra IQ2390S SoM platform
From: Konrad Dybcio @ 2026-06-30 13:57 UTC (permalink / raw)
To: Komal Bajaj, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Vinod Koul, Neil Armstrong,
Wesley Cheng, Ulf Hansson
Cc: linux-arm-msm, devicetree, linux-kernel, linux-phy, linux-mmc,
monish.chunara, Dmitry Baryshkov
In-Reply-To: <20260612-shikra-dt-v6-4-6b6cb58db477@oss.qualcomm.com>
On 6/12/26 7:27 PM, Komal Bajaj wrote:
> Add device tree include for the IQ2390S variant of the Shikra
> System-on-Module, an industrial compute module integrating the Shikra
> SoC and PMIC for industrial IoT applications, designed to mount on
> carrier boards.
>
> - shikra-iqs-som.dtsi: Industrial SoM without modem (PM8150 PMIC)
>
> The DTSI includes the common shikra.dtsi and adds PM8150 PMIC regulator
> definitions specific to this variant.
>
> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> Signed-off-by: Komal Bajaj <komal.bajaj@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v3 0/4] phy: qcom: qmp-pcie: Add PCIe PHY support for Hawi
From: Matthew Leung @ 2026-06-30 16:25 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel,
Krzysztof Kozlowski
In-Reply-To: <20260618-hawi-phy-pcie-v3-0-3fa42ca45ea4@oss.qualcomm.com>
Hello,
Gentle ping for this patch series.
Best regards,
Matthew Leung
On Thu, Jun 18, 2026 at 09:54:35PM +0000, Matthew Leung wrote:
> This series adds QMP PCIe PHY support for the Qualcomm Hawi SoC. The Hawi
> platform features two PCIe PHY configurations: Gen3 x2 and Gen4 x1.
>
> The Gen3 x2 PHY uses v10 register definitions, while the Gen4 x1 PHY uses
> v10.60 register definitions.
>
> The series adds:
> - device tree bindings
> - v10 register offset headers
> - v10.60 register offset headers
> - driver support with PHY initialization tables for both configurations
>
> Overlap:
> The series has overlap with "phy: qcom: Introduce USB support for Hawi"
> by Ronak Raheja (see link [1]). Both patch series introduce a subset of
> v10 registers (this series for PCIe and Ronak's for USB). I have
> coordinated with Ronak regarding the overlap, and we can update the
> series to resolve any overlap based on the order of merging.
>
> Link: https://lore.kernel.org/all/20260508213234.4643-1-ronak.raheja@oss.qualcomm.com/ [1]
>
> Signed-off-by: Matthew Leung <matthew.leung@oss.qualcomm.com>
> ---
> Changes in v3:
> - Squashed v10 register offsets into a single change
> - Squashed v10.60 register offsets into a single change
> - Removed USB mentions from header comments; offsets are PCIe-specific
> - Reused the tx offset for the v10.60 combined txrx module instead of
> introducing a separate txrx offset
> - Link to v2: https://patch.msgid.link/20260604-hawi-phy-pcie-v2-0-be908d3560db@oss.qualcomm.com
>
> Changes in v2:
> - Rebased onto v7.1-rc6
> - Patch 1: no change (Reviewed-by carried forward)
> - Patch 9: rename QPHY_PCIE_V10_60_PCS_PCS_TX_RX_CONFIG to
> QPHY_PCIE_V10_60_PCS_TX_RX_CONFIG to be consistent with the
> naming convention used in previous pcs-pcie headers
> - Patch 10: update usage of renamed macro
> - Link to v1: https://patch.msgid.link/20260508-hawi-phy-pcie-v1-0-237b894353fc@oss.qualcomm.com
>
> To: Vinod Koul <vkoul@kernel.org>
> To: Neil Armstrong <neil.armstrong@linaro.org>
> To: Rob Herring <robh@kernel.org>
> To: Krzysztof Kozlowski <krzk+dt@kernel.org>
> To: Conor Dooley <conor+dt@kernel.org>
> Cc: linux-arm-msm@vger.kernel.org
> Cc: linux-phy@lists.infradead.org
> Cc: devicetree@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
>
> ---
> Matthew Leung (4):
> dt-bindings: phy: qcom,sc8280xp-qmp-pcie-phy: Add Hawi compatibles
> phy: qcom-qmp: Add v10 register offsets
> phy: qcom-qmp: Add v10.60 register offsets
> phy: qcom: qmp-pcie: Add QMP PCIe PHY support for Hawi
>
> .../bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml | 6 +
> drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 375 +++++++++++++++++++++
> drivers/phy/qualcomm/phy-qcom-qmp-pcs-pcie-v10.h | 18 +
> .../phy/qualcomm/phy-qcom-qmp-pcs-pcie-v10_60.h | 26 ++
> drivers/phy/qualcomm/phy-qcom-qmp-pcs-v10.h | 22 ++
> drivers/phy/qualcomm/phy-qcom-qmp-pcs-v10_60.h | 23 ++
> .../phy/qualcomm/phy-qcom-qmp-qserdes-com-v10.h | 49 +++
> .../phy/qualcomm/phy-qcom-qmp-qserdes-com-v10_60.h | 55 +++
> .../phy/qualcomm/phy-qcom-qmp-qserdes-txrx-v10.h | 47 +++
> .../qualcomm/phy-qcom-qmp-qserdes-txrx-v10_60.h | 109 ++++++
> drivers/phy/qualcomm/phy-qcom-qmp.h | 10 +
> 11 files changed, 740 insertions(+)
> ---
> base-commit: 8cd9520d35a6c38db6567e97dd93b1f11f185dc6
> change-id: 20260506-hawi-phy-pcie-283933b4113e
>
> Best regards,
> --
> Matthew Leung <matthew.leung@oss.qualcomm.com>
>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH V2 0/2] arm64: dts: qcom: Shikra SD Card support
From: Monish Chunara @ 2026-06-30 16:56 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Vinod Koul, Neil Armstrong, Wesley Cheng,
Ulf Hansson, Kernel Team
Cc: linux-arm-msm, devicetree, linux-kernel, linux-phy, linux-mmc,
Nitin Rawat, Pradeep Pragallapati, Komal Bajaj, Monish Chunara,
Konrad Dybcio
This is v2 of the Shikra SD Card support series.
This series adds SD card support for the Shikra platform.
The first patch adds the SDHC2 controller node and the necessary pinctrl
configurations to the base Shikra SoC dtsi. The second patch enables
this support on the Shikra EVK (CQS, CQM, and IQS variants) by defining
the regulator supplies and the card detection GPIO.
Signed-off-by: Monish Chunara <monish.chunara@oss.qualcomm.com>
Changes in v2:
- Rectify the alignment for clocks and interconnect properties for SD
card
- Link to v1: https://lore.kernel.org/all/20260604122045.494712-1-monish.chunara@oss.qualcomm.com
Testing:
- Validated on Shikra EVK variants.
This series depends on:
- https://lore.kernel.org/all/20260612-shikra-dt-v6-2-6b6cb58db477@oss.qualcomm.com
Monish Chunara (2):
arm64: dts: qcom: Add SD Card support for Shikra SoC
arm64: dts: qcom: Enable SD card for Shikra EVK
arch/arm64/boot/dts/qcom/shikra-cqm-evk.dts | 18 ++++
arch/arm64/boot/dts/qcom/shikra-cqs-evk.dts | 18 ++++
arch/arm64/boot/dts/qcom/shikra-iqs-evk.dts | 18 ++++
arch/arm64/boot/dts/qcom/shikra.dtsi | 97 +++++++++++++++++++++
4 files changed, 151 insertions(+)
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH V2 1/2] arm64: dts: qcom: Add SD Card support for Shikra SoC
From: Monish Chunara @ 2026-06-30 16:56 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Vinod Koul, Neil Armstrong, Wesley Cheng,
Ulf Hansson, Kernel Team
Cc: linux-arm-msm, devicetree, linux-kernel, linux-phy, linux-mmc,
Nitin Rawat, Pradeep Pragallapati, Komal Bajaj, Monish Chunara,
Konrad Dybcio
In-Reply-To: <20260630165700.1886608-1-monish.chunara@oss.qualcomm.com>
Add support for SD card on Shikra SoC and enable the required pinctrl
configurations.
Signed-off-by: Monish Chunara <monish.chunara@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/shikra.dtsi | 97 ++++++++++++++++++++++++++++
1 file changed, 97 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/shikra.dtsi b/arch/arm64/boot/dts/qcom/shikra.dtsi
index e67fe047a683..cfdee8a2526e 100644
--- a/arch/arm64/boot/dts/qcom/shikra.dtsi
+++ b/arch/arm64/boot/dts/qcom/shikra.dtsi
@@ -829,6 +829,53 @@ rclk-pins {
bias-bus-hold;
};
};
+
+ sdc2_default: sdc2-default-state {
+ clk-pins {
+ pins = "sdc2_clk";
+ drive-strength = <14>;
+ bias-disable;
+ };
+
+ cmd-pins {
+ pins = "sdc2_cmd";
+ drive-strength = <14>;
+ bias-pull-up;
+ };
+
+ data-pins {
+ pins = "sdc2_data";
+ drive-strength = <14>;
+ bias-pull-up;
+ };
+ };
+
+ sdc2_sleep: sdc2-sleep-state {
+ clk-pins {
+ pins = "sdc2_clk";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ cmd-pins {
+ pins = "sdc2_cmd";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+
+ data-pins {
+ pins = "sdc2_data";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+ };
+
+ sdc2_card_det_n: sd-card-det-n-state {
+ pins = "gpio89";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
};
pmu@c91000 {
@@ -1081,6 +1128,56 @@ opp-384000000 {
};
};
+ sdhc_2: mmc@4784000 {
+ compatible = "qcom,shikra-sdhci", "qcom,sdhci-msm-v5";
+ reg = <0x0 0x4784000 0x0 0x1000>;
+
+ interrupts = <GIC_SPI 350 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 353 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "hc_irq",
+ "pwr_irq";
+
+ bus-width = <4>;
+
+ clocks = <&gcc GCC_SDCC2_AHB_CLK>,
+ <&gcc GCC_SDCC2_APPS_CLK>,
+ <&rpmcc RPM_SMD_XO_CLK_SRC>;
+ clock-names = "iface",
+ "core",
+ "xo";
+
+ qcom,dll-config = <0x0007442c>;
+ qcom,ddr-config = <0x80040868>;
+
+ iommus = <&apps_smmu 0x0a0 0x0>;
+
+ interconnects = <&system_noc MASTER_SDCC_2 RPM_ALWAYS_TAG
+ &mc_virt SLAVE_EBI_CH0 RPM_ALWAYS_TAG>,
+ <&mem_noc MASTER_AMPSS_M0 RPM_ACTIVE_TAG
+ &config_noc SLAVE_SDCC_2 RPM_ACTIVE_TAG>;
+ interconnect-names = "sdhc-ddr",
+ "cpu-sdhc";
+
+ power-domains = <&rpmpd RPMPD_VDDCX>;
+ operating-points-v2 = <&sdhc2_opp_table>;
+
+ status = "disabled";
+
+ sdhc2_opp_table: opp-table-2 {
+ compatible = "operating-points-v2";
+
+ opp-100000000 {
+ opp-hz = /bits/ 64 <100000000>;
+ required-opps = <&rpmpd_opp_low_svs>;
+ };
+
+ opp-202000000 {
+ opp-hz = /bits/ 64 <202000000>;
+ required-opps = <&rpmpd_opp_svs_plus>;
+ };
+ };
+ };
+
gpi_dma0: dma-controller@4a00000 {
compatible = "qcom,shikra-gpi-dma", "qcom,sm6350-gpi-dma";
reg = <0x0 0x04a00000 0x0 0x60000>;
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
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