* [PATCH v3 0/3] arm64: dts: imx93-11x11-evk: Add DY1212W-4856 LVDS panel
From: Liu Ying @ 2026-06-10 9:26 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Peng Fan
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, Marco Felsch,
Liu Ying
Hi,
This patch series aims to add DY1212W-4856 [1] LVDS panel to i.MX93 11x11
EVK board.
Patch 1 allows LVDS Display Bridge (LDB) child node in i.MX93 mediamix
blk-ctrl DT binding.
Patch 2 adds LDB child node to mediamix blk-ctrl node in imx93.dtsi.
Patch 3 adds a DT overlay to support the DY1212W-4856 LVDS panel on
i.MX93 11x11 EVK board.
[1] https://www.nxp.com/design/design-center/development-boards-and-designs/dy1212w-4856-tft-lcd-panel-with-lvds-interface:DY1212W-4856
Signed-off-by: Liu Ying <victor.liu@nxp.com>
---
Changes in v3:
- Explain in patch 1's commit message that mixing addressable and
non-addressable DT child nodes is allowed. (Krzysztof)
- Link to v2: https://patch.msgid.link/20260608-imx93-ldb-v2-0-1b1fe621bfda@nxp.com
Changes in v2:
- Rebase on next-20260605.
- Disallow bridge@20 for i.MX91 in patch 1. (Sashiko bot)
- Cc Marco.
- Link to v1: https://patch.msgid.link/20260513-imx93-ldb-v1-0-d11c5c3cc197@nxp.com
---
Liu Ying (3):
dt-bindings: soc: imx: fsl,imx93-media-blk-ctrl: Allow LVDS Display Bridge child node
arm64: dts: imx93: Add LVDS Display Bridge support
arm64: dts: imx93-11x11-evk: Add DY1212W-4856 LVDS panel
.../bindings/soc/imx/fsl,imx93-media-blk-ctrl.yaml | 39 +++++++++++
arch/arm64/boot/dts/freescale/Makefile | 4 ++
.../freescale/imx93-11x11-evk-dy1212w-4856.dtso | 81 ++++++++++++++++++++++
arch/arm64/boot/dts/freescale/imx93.dtsi | 37 ++++++++++
4 files changed, 161 insertions(+)
---
base-commit: 6e845bcb78c95af935094040bd4edc3c2b6dd784
change-id: 20260513-imx93-ldb-c5a4194e41ce
Best regards,
--
Regards,
Liu Ying
^ permalink raw reply
* Re: [PATCH 0/2] Cleanup and fix for NanoPC-T6 Plus
From: Diederik de Haas @ 2026-06-10 9:18 UTC (permalink / raw)
To: Diederik de Haas, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Heiko Stuebner
Cc: devicetree, linux-arm-kernel, linux-rockchip, linux-kernel,
Jonas Karlman, Marcin Juszkiewicz
In-Reply-To: <20260610081400.758687-1-diederik@cknow-tech.com>
On Wed Jun 10, 2026 at 10:14 AM CEST, Diederik de Haas wrote:
> Several nodes were enabled/configured when support for the NanoPC-T6 Plus was
s/Plus/LTS/ in Subject and here ...
Still working on a submission for the NanoPC-T6 Plus ;-)
Cheers,
Diederik
> added, but later those same nodes got enabled/configured in the dtsi file,
> making those in the dts file superfluous, so remove them.
>
> The MTT USB 2.0 Hub is connected to USB20 HOST1, so the phy-supply belongs to
> u2phy3_host, not u2phy2_host as that is for USB20 HOST0.
>
> Diederik de Haas (2):
> arm64: dts: rockchip: Drop duplicate USB nodes on NanoPC-T6 LTS
> arm64: dts: rockchip: Fix USB hub phy-supply config for NanoPC-T6 LTS
>
> .../dts/rockchip/rk3588-nanopc-t6-lts.dts | 19 +------------------
> 1 file changed, 1 insertion(+), 18 deletions(-)
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: media: qcom,qcm2290-venus: document shikra Iris compatible
From: Krzysztof Kozlowski @ 2026-06-10 9:17 UTC (permalink / raw)
To: Vikash Garodia
Cc: Bryan O'Donoghue, Dikshita Agarwal, Mauro Carvalho Chehab,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jorge Ramirez-Ortiz, Bjorn Andersson, Konrad Dybcio,
linux-arm-msm, linux-media, devicetree, linux-kernel
In-Reply-To: <20260609-shikra_vpu-v1-1-3a32bb38b080@oss.qualcomm.com>
On Tue, Jun 09, 2026 at 09:45:40PM +0530, Vikash Garodia wrote:
> Document the iris video accelerator used on shikra platforms by adding
> the qcom,shikra-iris compatible.
>
> Although QCM2290 and shikra share the same video hardware and overall
> integration, their SMMU programming differs. QCM2290 exposes separate
> stream IDs for the video hardware and the Xtensa path, requiring two
> explicit IOMMU entries, whereas shikra uses a masked SMR to collapse
> equivalent stream IDs into a single mapping. Due to QCM2290’s SID layout
> and Xtensa isolation requirements, such SMR masking is not applicable on
> QCM2290 platforms.
> Since shikra uses the same video hardware as QCM2290 and shares the same
> programming model and capabilities, it is added as a fallback compatible
> to qcom,qcm2290-venus, with conditional handling to allow either one or
> two IOMMU entries.
>
> Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
> ---
> .../bindings/media/qcom,qcm2290-venus.yaml | 20 ++++++++++++++++----
> 1 file changed, 16 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/media/qcom,qcm2290-venus.yaml b/Documentation/devicetree/bindings/media/qcom,qcm2290-venus.yaml
> index 5977e7d0a71b4fb5681f1c2094439c251366f01f..895533b9756690d075fd7729e3f805c8e72ff0df 100644
> --- a/Documentation/devicetree/bindings/media/qcom,qcm2290-venus.yaml
> +++ b/Documentation/devicetree/bindings/media/qcom,qcm2290-venus.yaml
> @@ -15,12 +15,27 @@ description:
>
> allOf:
> - $ref: qcom,venus-common.yaml#
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: qcom,shikra-iris
> + then:
> + properties:
> + iommus:
> + maxItems: 1
> + else:
> + properties:
> + iommus:
> + maxItems: 2
allOf goes to the end, after required: block. See example-schema.
>
> properties:
> compatible:
> oneOf:
> - items:
> - - const: qcom,sm6115-venus
> + - enum:
> + - qcom,sm6115-venus
> + - qcom,shikra-iris
Messed order.
> - const: qcom,qcm2290-venus
> - const: qcom,qcm2290-venus
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/3] arm64: dts: qcom: shikra: Add Iris video codec node
From: Konrad Dybcio @ 2026-06-10 9:15 UTC (permalink / raw)
To: Vikash Garodia, Bryan O'Donoghue, Dikshita Agarwal,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jorge Ramirez-Ortiz, Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel
In-Reply-To: <20260609-shikra_vpu-v1-2-3a32bb38b080@oss.qualcomm.com>
On 6/9/26 6:15 PM, Vikash Garodia wrote:
> Add the Iris video codec device tree node for the Shikra platform.
>
> Shikra reuses the QCM2290-class video hardware and programming model.
> The video node is added to describe the Iris based video decoder
> encoder block, allowing the media driver to probe and initialize
> the hardware.
>
> Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [net-next 1/3] dt-bindings: ptp: renesas,rcar-gen4-gptp: Add binding for R-Car Gen4
From: Niklas Söderlund @ 2026-06-10 9:14 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm, Richard Cochran, Andrew Lunn,
DavidS. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
linux-renesas-soc, devicetree, linux-kernel, netdev
In-Reply-To: <ded0ae1a-535f-4524-9c3c-e9970bdf387a@kernel.org>
On 2026-06-10 11:01:27 +0200, Krzysztof Kozlowski wrote:
> On 10/06/2026 10:53, Niklas Söderlund wrote:
> > Hi Krzysztof,
> >
> > Thanks for your comments.
> >
> > On 2026-06-10 08:54:06 +0200, Krzysztof Kozlowski wrote:
> >> On 09/06/2026 23:57, Niklas Söderlund wrote:
> >>> Add bindings for the R-Car Gen4 gPTP timer. The timer enables accurate
> >>> synchronization of the clock in the control system. The timer is
> >>> system-wide and used by different Ethernet devices on each Gen4 platform.
> >>
> >> A nit, subject: drop second/last, redundant "binding for". The
> >> "dt-bindings" prefix is already stating that these are bindings.
> >
> > Thanks, will fix.
> >
> >> See also:
> >> https://elixir.bootlin.com/linux/v6.17-rc3/source/Documentation/devicetree/bindings/submitting-patches.rst#L18
> >
> > Not sure I follow this one, L18 reads,
> >
> > "Few subsystems, like ASoC, media, regulators and SPI, expect reverse
> > order of the prefixes::"
> >
> > But 'git log Documentation/devicetree/bindings/ptp/' shows all commits
> > in that directory use the 'dt-bindings: ptp:' prefix.
>
> 5 lines below.
> https://elixir.bootlin.com/linux/v6.17-rc3/source/Documentation/devicetree/bindings/submitting-patches.rst#L23
Ahh, thanks.
>
>
> Best regards,
> Krzysztof
--
Kind Regards,
Niklas Söderlund
^ permalink raw reply
* Re: [PATCH v2 1/4] dt-bindings: remoteproc: imx_rproc: document optional "memory-region-names"
From: Krzysztof Kozlowski @ 2026-06-10 9:14 UTC (permalink / raw)
To: Laurentiu Mihalcea
Cc: Bjorn Andersson, Mathieu Poirier, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sascha Hauer, Peng Fan,
Fabio Estevam, Daniel Baluta, Francesco Dolcini, linux-remoteproc,
devicetree, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <2fc48536-5af9-419e-b4df-746b678cb6ab@gmail.com>
On 10/06/2026 11:10, Laurentiu Mihalcea wrote:
>
>
> On 6/10/2026 12:37 AM, Krzysztof Kozlowski wrote:
>> On Fri, Jun 05, 2026 at 04:36:18AM -0700, Laurentiu Mihalcea wrote:
>>> From: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
>>>
>>> The names of the carveout regions are derived using the names of the
>>> reserved memory devicetree nodes, which are referenced using the
>>> "memory-region" property. This adds a restriction on the names of said
>>> devicetree nodes, often bearing specific names such as: "vdevbuffer",
>>> "vdev0vring0", "rsc-table", etc... This goes against the devicetree
>>> specification's recommendation, which states that the devicetree node
>>> names should be generic.
>>
>> No, it does not. Names like rsc-table feels exactly like DT spec is
>> asking - for a name matching purpose. Are you sure you read the spec?
>
> Quoting from the spec:
>
> "The name of a node should be somewhat generic, reflecting the function of the
> device and not its precise programming model"
And read the rest of the spec, please.
>
> and looking at the examples provided in "2.2.2 Generic Names Recommendation",
> wouldn't "memory" be a more appropriate choice for the DT node name instead of
> "rsc-table" since it's more generic, while still matching the purpose
> of the device? Or perhaps I'm interpreting this the wrong way?
You just took one piece skipping the rest. Also binding in the dtschema
repeats that.
>
>>
>>>
>>> Fix this by documenting an additional, optional property:
>>> "memory-region-names". This way, the carveout names can use the values
>>> passed via "memory-region-names", while keeping the devicetree node
>>> names of the reserved memory regions generic.
>>
>> I don't see how anything here is fixed. memory-region-names has nothing
>> to do with node names.
>
> The idea here is that the names of the carveout regions can now be passed
> via the "memory-region-names" property. Previously, we were using the DT
> node names for that.
memory-region phandles give you that, not names. You need to state why
this is not sufficient.
>
> Thus, we can now use the more generic "memory" name for the DT nodes since we
> no longer use them for the carveout names.
That's wrong reason for doing this change. Also random names here change
nothing.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v1 2/3] arm64: dts: freescale: Add support for Variscite DART-MX8M-MINI
From: sashiko-bot @ 2026-06-10 9:13 UTC (permalink / raw)
To: Stefano Radaelli; +Cc: Frank.Li, devicetree, robh, conor+dt, imx
In-Reply-To: <3b7987d3021b1f0e4c0730b5fdb5ea6b2a192c4b.1781024557.git.stefano.r@variscite.com>
Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [High] Contradictory GPIO polarity in fixed regulator `reg_eth_phy` between `enable-active-high` and `GPIO_ACTIVE_LOW`.
- [High] Simultaneous deassertion of power enable and reset in `wifi_pwrseq` violates hardware sequencing requirements.
- [Medium] The audio card hardcodes carrier-board-specific jacks in the SOM .dtsi, violating the module separation described in the commit message.
- [Low] The `bluetooth` node is missing the necessary GPIO property assignments (`device-wakeup-gpios`, etc.) required to control the Bluetooth chip, despite the pins being configured in `pinctrl_bt`.
--
commit 9e70fb8b6cc043ee758ca5e7801e30846eec594b
Author: Stefano Radaelli <stefano.r@variscite.com>
arm64: dts: freescale: Add support for Variscite DART-MX8M-MINI
Add device tree support for the Variscite DART-MX8MM system on module.
This SOM is designed to be used with various carrier boards.
Link: https://variscite.com/system-on-module-som/i-mx-8/i-mx-8m-mini/dart-mx8m-mini/
> diff --git a/arch/arm64/boot/dts/freescale/imx8mm-var-dart.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-var-dart.dtsi
> new file mode 100644
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/imx8mm-var-dart.dtsi
> @@ -0,0 +1,559 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Common dtsi for Variscite DART-MX8M-MINI
[ ... ]
> + reg_eth_phy: regulator-eth-phy {
> + compatible = "regulator-fixed";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_reg_eth_phy>;
> + regulator-name = "eth_phy_pwr";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-enable-ramp-delay = <20000>;
> + gpio = <&gpio1 7 GPIO_ACTIVE_LOW>;
> + enable-active-high;
> + };
[Severity: High]
Does the PHY power switch require an active-low or active-high signal?
The reg_eth_phy node uses GPIO_ACTIVE_LOW but also specifies
enable-active-high. Under the regulator framework, enable-active-high forces
the GPIO to be treated as active-high, overriding the GPIO_ACTIVE_LOW flag.
If the power switch requires an active-low signal, it might fail to enable
the PHY. If it requires an active-high signal, the GPIO_ACTIVE_LOW flag
seems misleading.
[ ... ]
> + sound-wm8904 {
> + compatible = "simple-audio-card";
> + simple-audio-card,bitclock-master = <&codec_dai>;
> + simple-audio-card,format = "i2s";
> + simple-audio-card,frame-master = <&codec_dai>;
> + simple-audio-card,mclk-fs = <256>;
> + simple-audio-card,name = "wm8904-audio";
> + simple-audio-card,routing =
> + "Headphone Jack", "HPOUTL",
> + "Headphone Jack", "HPOUTR",
> + "IN2L", "Line In Jack",
> + "IN2R", "Line In Jack",
> + "IN1L", "Microphone Jack",
> + "IN1R", "Microphone Jack";
> + simple-audio-card,widgets =
> + "Microphone", "Microphone Jack",
> + "Headphone", "Headphone Jack",
> + "Line", "Line In Jack";
[Severity: Medium]
Should this routing and widget configuration be moved to the carrier board
device tree instead?
The commit message states that carrier board specific interfaces are left
disabled to be enabled in respective carrier board device trees. However,
this sound-wm8904 node hardcodes routing for physical jacks (Headphone, Line
In, Microphone) which normally reside on the carrier board.
Including this directly in the module's .dtsi forces all carrier boards to
inherit this exact jack topology.
[ ... ]
> + wifi_pwrseq: wifi-pwrseq {
> + compatible = "mmc-pwrseq-simple";
> + post-power-on-delay-ms = <100>;
> + power-off-delay-us = <10000>;
> + reset-gpios = <&gpio2 10 GPIO_ACTIVE_LOW>, /* WIFI_RESET */
> + <&gpio2 20 GPIO_ACTIVE_LOW>; /* WIFI_PWR_EN */
> + };
[Severity: High]
Does toggling these GPIOs simultaneously violate the hardware sequencing
requirements for the Wi-Fi chip?
Grouping both WIFI_RESET and WIFI_PWR_EN in the reset-gpios property of
mmc-pwrseq-simple causes the driver to toggle both lines at the exact same
moment.
Would it be safer to model the power enable signal as a vmmc-supply with a
startup-delay-us? This would allow the power rail to fully stabilize before
the reset line is released.
[ ... ]
> +/* BT module */
> +&uart4 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_uart4>, <&pinctrl_bt>;
> + assigned-clocks = <&clk IMX8MM_CLK_UART4>;
> + assigned-clock-parents = <&clk IMX8MM_SYS_PLL1_80M>;
> + uart-has-rtscts;
> + status = "okay";
> +
> + bluetooth_iw61x: bluetooth {
> + compatible = "nxp,88w8987-bt";
> + };
> +};
[ ... ]
> +&iomuxc {
> + pinctrl_bt: btgrp {
> + fsl,pins = <
> + MX8MM_IOMUXC_SD1_DATA4_GPIO2_IO6 0xc1
> + MX8MM_IOMUXC_SPDIF_EXT_CLK_GPIO5_IO5 0xc1
> + >;
> + };
[Severity: Low]
Are we missing driver property assignments for these Bluetooth pins?
The pinctrl_bt group configures GPIO2_IO6 and GPIO5_IO5 with pull-ups
disabled (0xc1), and assigns them to the uart4 node. However, the
bluetooth_iw61x node does not assign these pins to any driver properties
(like device-wakeup-gpios).
Because the driver cannot manage them, does this leave the pins physically
floating, which could cause spurious wakeups or increased power consumption?
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1781024557.git.stefano.r@variscite.com?part=2
^ permalink raw reply
* Re: [PATCH 7/7] ASoC: dt-bindings: ES8389: Add members about HPF and clock
From: zhangyi @ 2026-06-10 9:12 UTC (permalink / raw)
To: krzk; +Cc: alsa-devel, broonie, conor+dt, devicetree, krzk+dt, robh, tiwai
> You already sent v1 and received feedback.
>
> You just completely ignored it
When I submitted the v0 patch, I received feedback and suggestions from
Sashiko.
I wasn't sure how to handle Sashiko's feedback, and I mistakenly assumed
that if my patch didn't pass Sashiko's tests, you wouldn't receive it.
So, after modifying the code based on Sashiko's reasonable suggestions, I
submitted a patch with the same version ID.
As a result, you received two consecutive patches from me. I didn't mean to
ignore your valuable feedback, and I apologize for this.
So, when I receive feedback from Sashiko, do I need to wait for the
maintainers to provide their feedback before incorporating the changes into
the next version's patch?
^ permalink raw reply
* Re: [PATCH v1 3/3] arm64: dts: imx8mm-var-dart: Add support for Variscite Sonata board
From: sashiko-bot @ 2026-06-10 9:11 UTC (permalink / raw)
To: Stefano Radaelli; +Cc: conor+dt, devicetree, Frank.Li, robh, imx
In-Reply-To: <2fd914cc7af53e217cfdb21713fee8eb7007f42f.1781024557.git.stefano.r@variscite.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] Commit message claims 'HDMI support', but the device tree does not contain any display or HDMI nodes.
- [Low] Unused pinmux configuration for GPIO4_IO22 in SPI pin group.
--
commit 4503e51abf44d2c1fc12465dd4301df16f97a703
Author: Stefano Radaelli <stefano.r@variscite.com>
arm64: dts: imx8mm-var-dart: Add support for Variscite Sonata board
Add device tree support for the Variscite Sonata carrier board with the
DART-MX8M-MINI system on module.
Link: https://variscite.com/carrier-boards/sonata-board/
> The Sonata board includes
> - uSD Card support
> - USB ports and OTG
> - Uart, SPI and I2C interfaces
> - HDMI support
[Severity: Medium]
The commit message claims "HDMI support", but looking at the provided device
tree, there don't appear to be any display-related nodes such as LCDIF,
MIPI DSI, a DSI-to-HDMI bridge, or an hdmi-connector. Does this patch actually
include the HDMI support mentioned in the description?
> diff --git a/arch/arm64/boot/dts/freescale/imx8mm-var-dart-sonata.dts b/arch/arm64/boot/dts/freescale/imx8mm-var-dart-sonata.dts
> new file mode 100644
> index 0000000000000..93b0076987b82
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/imx8mm-var-dart-sonata.dts
[ ... ]
> + pinctrl_ecspi1: ecspi1grp {
> + fsl,pins = <
> + MX8MM_IOMUXC_ECSPI1_SCLK_ECSPI1_SCLK 0x13
> + MX8MM_IOMUXC_ECSPI1_MOSI_ECSPI1_MOSI 0x13
> + MX8MM_IOMUXC_ECSPI1_MISO_ECSPI1_MISO 0x13
> + MX8MM_IOMUXC_ECSPI1_SS0_GPIO5_IO9 0x13
> + MX8MM_IOMUXC_GPIO1_IO12_GPIO1_IO12 0x13
> + MX8MM_IOMUXC_SAI2_RXC_GPIO4_IO22 0x13
> + >;
> + };
[Severity: Low]
Does the ECSPI1 controller or any of its connected devices actually use this
MX8MM_IOMUXC_SAI2_RXC_GPIO4_IO22 pin?
The ecspi1 node explicitly defines its chip selects as <&gpio5 9> and
<&gpio1 12>, and it doesn't appear to reference this GPIO.
Could this be an unused pinmux configuration left over from a copy-paste that
might conflict with other functions needing this pin?
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1781024557.git.stefano.r@variscite.com?part=3
^ permalink raw reply
* Re: [PATCH 2/2] MAINTAINERS: Add myself as maintainer for SPS30
From: Krzysztof Kozlowski @ 2026-06-10 9:10 UTC (permalink / raw)
To: Maxwell Doose
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
open list:IIO SUBSYSTEM AND DRIVERS,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list, Tomasz Duszynski
In-Reply-To: <20260609161701.52513-4-m32285159@gmail.com>
On Tue, Jun 09, 2026 at 11:17:01AM -0500, Maxwell Doose wrote:
> Tomasz's entry is no longer valid, as he is not active anymore. Add
> myself as maintainer of the SPS30 to replace his entry.
Same comments.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 1/4] dt-bindings: remoteproc: imx_rproc: document optional "memory-region-names"
From: Laurentiu Mihalcea @ 2026-06-10 9:10 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Bjorn Andersson, Mathieu Poirier, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sascha Hauer, Peng Fan,
Fabio Estevam, Daniel Baluta, Francesco Dolcini, linux-remoteproc,
devicetree, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260610-adventurous-granite-marmoset-e0eaa8@quoll>
On 6/10/2026 12:37 AM, Krzysztof Kozlowski wrote:
> On Fri, Jun 05, 2026 at 04:36:18AM -0700, Laurentiu Mihalcea wrote:
>> From: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
>>
>> The names of the carveout regions are derived using the names of the
>> reserved memory devicetree nodes, which are referenced using the
>> "memory-region" property. This adds a restriction on the names of said
>> devicetree nodes, often bearing specific names such as: "vdevbuffer",
>> "vdev0vring0", "rsc-table", etc... This goes against the devicetree
>> specification's recommendation, which states that the devicetree node
>> names should be generic.
>
> No, it does not. Names like rsc-table feels exactly like DT spec is
> asking - for a name matching purpose. Are you sure you read the spec?
Quoting from the spec:
"The name of a node should be somewhat generic, reflecting the function of the
device and not its precise programming model"
and looking at the examples provided in "2.2.2 Generic Names Recommendation",
wouldn't "memory" be a more appropriate choice for the DT node name instead of
"rsc-table" since it's more generic, while still matching the purpose
of the device? Or perhaps I'm interpreting this the wrong way?
>
>>
>> Fix this by documenting an additional, optional property:
>> "memory-region-names". This way, the carveout names can use the values
>> passed via "memory-region-names", while keeping the devicetree node
>> names of the reserved memory regions generic.
>
> I don't see how anything here is fixed. memory-region-names has nothing
> to do with node names.
The idea here is that the names of the carveout regions can now be passed
via the "memory-region-names" property. Previously, we were using the DT
node names for that.
Thus, we can now use the more generic "memory" name for the DT nodes since we
no longer use them for the carveout names.
>
> Best regards,
> Krzysztof
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: iio: sensirion,sps30: Add myself as maintainer
From: Krzysztof Kozlowski @ 2026-06-10 9:10 UTC (permalink / raw)
To: Maxwell Doose
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
open list:IIO SUBSYSTEM AND DRIVERS,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list, Tomasz Duzsynski
In-Reply-To: <20260609161701.52513-3-m32285159@gmail.com>
On Tue, Jun 09, 2026 at 11:17:00AM -0500, Maxwell Doose wrote:
> Tomasz's entry is no longer valid, as he is not active anymore. Add
> myself as maintainer for the SPS30 to replace his entry.
>
> Link: https://lore.kernel.org/linux-iio/20260609140712.2e5d1640@jic23-huawei/
> Cc: Tomasz Duzsynski <tduszyns@gmail.com>
> Signed-off-by: Maxwell Doose <m32285159@gmail.com>
> ---
> .../devicetree/bindings/iio/chemical/sensirion,sps30.yaml | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
How many separate patches are you going to send?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/2] MAINTAINERS: Add myself as maintainer for PMS7003
From: Krzysztof Kozlowski @ 2026-06-10 9:09 UTC (permalink / raw)
To: Maxwell Doose
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
open list:IIO SUBSYSTEM AND DRIVERS,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list, Tomasz Duszynski
In-Reply-To: <20260609160326.45123-3-m32285159@gmail.com>
On Tue, Jun 09, 2026 at 11:03:26AM -0500, Maxwell Doose wrote:
> Tomasz's entry is no longer valid, as he is not active anymore. Add
Why is not longer valid? I see activity in Feb...
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: iio: plantower,pms7003: Add myself as maintainer
From: Krzysztof Kozlowski @ 2026-06-10 9:08 UTC (permalink / raw)
To: Maxwell Doose
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
open list:IIO SUBSYSTEM AND DRIVERS,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list, Tomasz Duzsynski
In-Reply-To: <20260609160326.45123-2-m32285159@gmail.com>
On Tue, Jun 09, 2026 at 11:03:25AM -0500, Maxwell Doose wrote:
> Tomasz's entry is no longer valid, as he is not active anymore. Add
> myself as maintainer to replace his entry.
Last replies are from Feb 2026, so not that far away. I fail to see the
context behind that change.
Anyway, it's like fourth patch from you doing the same. It's even more
confusing seeing this done file by file.
Maybe you just want to add yourself as co-maintainer?
>
> Link: https://lore.kernel.org/linux-iio/20260609140712.2e5d1640@jic23-huawei/
> Cc: Tomasz Duzsynski <tduszyns@gmail.com>
> Signed-off-by: Maxwell Doose <m32285159@gmail.com>
> ---
> .../devicetree/bindings/iio/chemical/plantower,pms7003.yaml | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH RFC v7 7/9] PM / devfreq: Introduce the QCOM SCMI Memlat devfreq driver
From: sashiko-bot @ 2026-06-10 9:06 UTC (permalink / raw)
To: Pragnesh Papaniya; +Cc: conor+dt, devicetree, robh
In-Reply-To: <20260610-rfc_v7_scmi_memlat-v7-7-f3f68c608f25@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Circular `devm` dependency creates a permanent resource leak of dummy platform devices and devfreq instances, leading to a Use-After-Free of the `memory` struct on module unload.
- [Medium] Dummy platform devices are created with generic names and PLATFORM_DEVID_NONE, causing global platform bus naming collisions.
--
commit 911bb9ff9b30677cf9eaa4d7a6794775e3393fc4
Author: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
PM / devfreq: Introduce the QCOM SCMI Memlat devfreq driver
This commit introduces a devfreq SCMI client driver that uses the MEMLAT
algorithm to detect memory-latency-bound workloads. It controls the frequency
and level of memory buses like DDR and LLCC on Qualcomm platforms.
> diff --git a/drivers/devfreq/scmi-qcom-memlat-devfreq.c b/drivers/devfreq/scmi-qcom-memlat-devfreq.c
> new file mode 100644
> index 0000000000000..99ae229acfdc3
> --- /dev/null
> +++ b/drivers/devfreq/scmi-qcom-memlat-devfreq.c
[ ... ]
> +static void scmi_qcom_memlat_unwind(struct scmi_qcom_memlat_info *info, int count)
> +{
> + for (int i = 0; i < count; i++) {
> + struct scmi_qcom_memory_info *memory = info->memory[i];
> +
> + if (IS_ERR_OR_NULL(memory) || IS_ERR_OR_NULL(memory->pdev))
> + continue;
> +
> + dev_pm_opp_remove_all_dynamic(&memory->pdev->dev);
> + platform_device_unregister(memory->pdev);
> + }
> +}
[ ... ]
> + for (i = 0; i < info->memory_cnt; i++) {
> + struct scmi_qcom_memory_info *memory = info->memory[i];
> + struct platform_device *pdev = memory->pdev;
> + struct devfreq_dev_profile *profile = &memory->profile;
> +
> + /* sampling time should be double the devfreq observing time */
> + profile->polling_ms = max(1U, info->cpucp_sample_ms / 2);
> + profile->get_cur_freq = scmi_qcom_devfreq_get_cur_freq;
> + profile->initial_freq = memory->min_freq > 1 ?
> + (memory->min_freq * 1000UL) : memory->min_freq;
> +
> + platform_set_drvdata(pdev, memory);
> +
> + memory->devfreq = devm_devfreq_add_device(&pdev->dev, profile,
> + DEVFREQ_GOV_REMOTE, NULL);
[Severity: High]
Does this create a circular dependency that results in a permanent resource
leak and use-after-free on module unload?
The driver registers dummy platform devices without binding a driver to them,
and attaches devfreq instances to them using devm_devfreq_add_device() here.
The devfreq core internally calls get_device(dev->parent), taking a reference
on pdev->dev.
During module unload or probe failure, scmi_qcom_memlat_unwind() calls
platform_device_unregister(pdev), dropping the initial reference. However, for
a driverless device, devres cleanup actions are only executed when the device
is finally released (device_release()). Because the child devfreq device still
holds a reference to pdev->dev, its refcount never drops to zero, preventing
the devres cleanup from executing.
This creates a circular dependency where the devfreq device is permanently
leaked. When the SCMI driver finishes its removal, its own devres actions free
the memory structure (allocated via devm_kzalloc(&sdev->dev)). The leaked
devfreq device's delayed work queue continues to poll, dereferencing the freed
memory pointer via profile->get_cur_freq() in scmi_qcom_devfreq_get_cur_freq(),
which could result in a panic.
> + if (IS_ERR(memory->devfreq)) {
> + dev_err(&sdev->dev, "failed to add devfreq device\n");
> + /* Stop sampling and voting timer */
[ ... ]
> + for (i = 0; i < cfg_data->memory_cnt; i++) {
> + const struct scmi_qcom_memory_cfg *memory_cfg = &cfg_data->memory_cfg[i];
> + struct platform_device_info pdevinfo = { 0 };
> +
> + pdevinfo.parent = &sdev->dev;
> + pdevinfo.name = memory_cfg->name;
> + pdevinfo.id = PLATFORM_DEVID_NONE;
[Severity: Medium]
Will this cause global platform bus naming collisions?
The driver registers dummy platform devices with generic names (e.g., "ddr",
"llcc", "ddr-qos") and uses PLATFORM_DEVID_NONE instead of PLATFORM_DEVID_AUTO.
As a result, devices are added to the global platform bus with exactly these
generic names.
If any other driver in the kernel registers a platform device with the same
name, or if there are multiple SCMI memlat instances active in the system,
platform_device_register_full() will fail with -EEXIST and abort the probe.
Could this use a driver-specific prefix or auto-assigned instance IDs to
prevent namespace collisions?
> +
> + memory = devm_kzalloc(&sdev->dev, sizeof(*memory), GFP_KERNEL);
> + if (!memory)
> + return -ENOMEM;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260610-rfc_v7_scmi_memlat-v7-0-f3f68c608f25@oss.qualcomm.com?part=7
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: media: qcom,qcm2290-venus: document shikra Iris compatible
From: Vikash Garodia @ 2026-06-10 9:05 UTC (permalink / raw)
To: Bryan O'Donoghue, Dikshita Agarwal, Mauro Carvalho Chehab,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jorge Ramirez-Ortiz, Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel
In-Reply-To: <3d53b646-d5f2-4ca9-9d69-dc0899165c3d@kernel.org>
On 6/10/2026 2:24 PM, Bryan O'Donoghue wrote:
> On 10/06/2026 08:50, Vikash Garodia wrote:
>>
>> On 6/10/2026 2:07 AM, Bryan O'Donoghue wrote:
>>> On 09/06/2026 17:15, Vikash Garodia wrote:
>>>> Document the iris video accelerator used on shikra platforms by adding
>>>> the qcom,shikra-iris compatible.
>>>>
>>>> Although QCM2290 and shikra share the same video hardware and overall
>>>> integration, their SMMU programming differs. QCM2290 exposes separate
>>>> stream IDs for the video hardware and the Xtensa path, requiring two
>>>> explicit IOMMU entries, whereas shikra uses a masked SMR to collapse
>>>> equivalent stream IDs into a single mapping. Due to QCM2290’s SID
>>>> layout
>>>> and Xtensa isolation requirements, such SMR masking is not
>>>> applicable on
>>>> QCM2290 platforms.
>>>> Since shikra uses the same video hardware as QCM2290 and shares the
>>>> same
>>>> programming model and capabilities, it is added as a fallback
>>>> compatible
>>>> to qcom,qcm2290-venus, with conditional handling to allow either one or
>>>> two IOMMU entries.
>>>>
>>>> Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
>>>> ---
>>>> .../bindings/media/qcom,qcm2290-venus.yaml | 20 ++++++++++
>>>> ++++++----
>>>> 1 file changed, 16 insertions(+), 4 deletions(-)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/media/qcom,qcm2290-
>>>> venus.yaml b/Documentation/devicetree/bindings/media/qcom,qcm2290-
>>>> venus.yaml
>>>> index
>>>> 5977e7d0a71b4fb5681f1c2094439c251366f01f..895533b9756690d075fd7729e3f805c8e72ff0df 100644
>>>> --- a/Documentation/devicetree/bindings/media/qcom,qcm2290-venus.yaml
>>>> +++ b/Documentation/devicetree/bindings/media/qcom,qcm2290-venus.yaml
>>>> @@ -15,12 +15,27 @@ description:
>>>>
>>>> allOf:
>>>> - $ref: qcom,venus-common.yaml#
>>>> + - if:
>>>> + properties:
>>>> + compatible:
>>>> + contains:
>>>> + const: qcom,shikra-iris
>>>
>>> Should this be "iris" in a venus yaml ?
>>
>> given the vpu core was first enabled on venus and now it same core on a
>> different SOC being enabled on iris. There are 2 ways to do this
>> 1. Add the compat to existing schema which defines the binding for that
>> core i.e existing patch
>> 2. Write a new schema (or say duplicate it) with ...shikra-iris.yaml,
>> but again, the shikra compat would fallback to "qcom,qcm2290-venus"
>> compat. hence even iris yaml would then need to carry the venus *string*.
>>
>> I followed the first option.
>>
>
> I'm confused here. Your fallback is qcm2290-venus.
>
> grep qcm2290-venus drivers/* -r
>
> drivers/media/platform/qcom/venus/core.c: { .compatible =
> "qcom,qcm2290-venus", .data = &qcm2290_res, },
As part of migrating soc support from venus to iris [1], the compat
would be added to iris and shikra would fallback to it.
[1]
https://lore.kernel.org/linux-media/20260515-iris-ar50lt-v3-12-df3846e74347@oss.qualcomm.com/
>
> So shouldn't it be shikra-venus ?
>
> ---
> bod
^ permalink raw reply
* Re: [PATCH v4 4/4] arm64: dts: qcom: Add IMDT QCS8550 SBC
From: sashiko-bot @ 2026-06-10 9:05 UTC (permalink / raw)
To: William Bright; +Cc: robh, conor+dt, devicetree
In-Reply-To: <20260610-imdt-qcs8550-sbc-rfc-v4-4-358e71d606bc@imd-tec.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] Encoding downstream device resets and straps into the PCIe host controller's pinctrl to control boot sequencing.
- [Low] Dangling `enable-active-high` property in `regulator-gpio` without `enable-gpios`.
--
commit 69cdd29642da9fee5fcb6d62c3df7354abac11dc
Author: William Bright <william.bright@imd-tec.com>
arm64: dts: qcom: Add IMDT QCS8550 SBC
This commit adds device tree support for the IMDT QCS8550 SBC. It enables
various peripherals including regulators, UART, UFS, PCIe, USB, and Ethernet.
> diff --git a/arch/arm64/boot/dts/qcom/qcs8550-imdt-sbc.dts b/arch/arm64/boot/dts/qcom/qcs8550-imdt-sbc.dts
> new file mode 100644
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/qcs8550-imdt-sbc.dts
[ ... ]
> + sdhci_2_vqmmc: regulator-sdhci-2-vqmmc {
> + compatible = "regulator-gpio";
> +
> + regulator-name = "sdhci_2_vqmmc";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-type = "voltage";
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <&sd_vset_default>;
> +
> + gpios = <&tlmm 4 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
[Severity: Low]
Is this enable-active-high property needed here?
This regulator uses regulator-gpio and defines the gpios array for voltage
state selection, but it does not specify an enable-gpios property. Since the
property is dangling, will this trigger a dtbs_check validation warning?
> +
> + gpios-states = <0>;
> + states = <3300000 0>,
> + <1800000 1>;
[ ... ]
> +&pcie0 {
> + wake-gpios = <&tlmm 96 GPIO_ACTIVE_HIGH>;
> + perst-gpios = <&tlmm 94 GPIO_ACTIVE_LOW>;
> +
> + /*
> + * pcie0 hosts the M.2 Key-E slot. Apply the SDIO
> + * reset de-assert here so any module's chip enable is settled
> + * before pcie0 trains its link.
> + */
> + pinctrl-0 = <&pcie0_default_state>, <&m2e_sdio_resetn_default>;
[Severity: Medium]
Is it correct to encode downstream device resets into the PCIe host
controller's pinctrl?
Tying board-level reset pins like the SDIO reset to the PCIe host
controller's pinctrl tightly couples peripheral initialization to the host
driver's state machine.
Should these downstream devices be modeled using PCI child nodes with their
own reset properties or standard power sequencing mechanisms instead, to
avoid unintended GPIO toggling during PCIe suspend and resume?
> + pinctrl-names = "default";
> +
> + status = "okay";
> +};
[ ... ]
> +&pcie1 {
> + wake-gpios = <&tlmm 99 GPIO_ACTIVE_HIGH>;
> + perst-gpios = <&tlmm 97 GPIO_ACTIVE_LOW>;
> +
> + /*
> + * pcie_switch_sel_default and gbe_reset_default are board-init
> + * lines that must be stable before pcie1 trains its link: the
> + * PCIe switch needs its mode-select strap settled, and the
> + * downstream LAN743x must be out of reset to enumerate.
> + * Applying them via pcie1's pinctrl-0 fires them during
> + * qcom-pcie probe, before bus enumeration.
> + */
> + pinctrl-0 = <&pcie1_default_state>,
> + <&pcie_switch_sel_default>,
> + <&gbe_reset_default>;
[Severity: Medium]
Does assigning the PCIe switch strap and downstream GbE PHY reset to the pcie1
pinctrl violate device tree abstractions?
Similar to pcie0, this couples downstream device initialization directly to
the host controller. Modeling this hardware topology through proper PCI child
nodes might be safer than relying on host driver sequencing.
> + pinctrl-names = "default";
> +
> + status = "okay";
> +};
> +
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260610-imdt-qcs8550-sbc-rfc-v4-0-358e71d606bc@imd-tec.com?part=4
^ permalink raw reply
* Re: [PATCH RFC v7 5/9] PM / devfreq: Add new track_remote flag for governors
From: sashiko-bot @ 2026-06-10 9:05 UTC (permalink / raw)
To: Pragnesh Papaniya; +Cc: devicetree, conor+dt, robh
In-Reply-To: <20260610-rfc_v7_scmi_memlat-v7-5-f3f68c608f25@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
New issues:
- [High] Bypassing `profile->target()` for `TRACK_REMOTE` governors leaves `new_freq` unaligned to exact OPP frequencies, permanently breaking transition statistics and causing a warning flood.
Pre-existing issues:
- [High] Unprotected read of `devfreq->governor` can lead to a NULL pointer dereference or use-after-free due to concurrent modification.
- [High] The resume_freq state variable is incorrectly overwritten with suspend_freq during suspend transitions, preventing the device from properly restoring its pre-suspend frequency on resume.
--
commit fa5d93fe675fe1183dc1fbfcc716761f517b7cf0
Author: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
PM / devfreq: Add new track_remote flag for governors
Some devfreq governors need to track frequency changes performed on remote
devices rather than driving the frequency updates themselves. In such cases,
the device's frequency is already updated by an external entity and devfreq
only needs to keep its transition statistics and notifier subscribers in sync.
> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
> index 2f27a239e34a6..71c6ced9e4e1d 100644
> --- a/drivers/devfreq/devfreq.c
> +++ b/drivers/devfreq/devfreq.c
> @@ -348,6 +348,26 @@ static int devfreq_set_target(struct devfreq *devfreq, unsigned long new_freq,
> unsigned long cur_freq;
> int err = 0;
>
> + /*
> + * When a remote agent (e.g. firmware) owns the frequency, skip the
> + * local profile->target() call. Still emit the PRECHANGE/POSTCHANGE
> + * pair and the trace event so that transition-notifier subscribers
> + * (passive governor, devfreq cooling, etc.) and tracing observe the
> + * frequency change exactly as they would on the normal path.
> + */
> + if (devfreq->governor &&
> + IS_SUPPORTED_FLAG(devfreq->governor->flags, TRACK_REMOTE)) {
[Severity: High]
This is a pre-existing issue, but does this evaluation of devfreq->governor
risk a NULL pointer dereference in drivers/devfreq/devfreq.c?
If governor_store() concurrently sets devfreq->governor to NULL,
devfreq->governor could be evaluated as true for the check, but then become
NULL when dereferencing devfreq->governor->flags in devfreq_set_target().
> + freqs.old = devfreq->previous_freq;
> + freqs.new = new_freq;
> + devfreq_notify_transition(devfreq, &freqs, DEVFREQ_PRECHANGE);
> +
> + if (trace_devfreq_frequency_enabled() && new_freq != freqs.old)
> + trace_devfreq_frequency(devfreq, new_freq, freqs.old);
> +
> + devfreq_notify_transition(devfreq, &freqs, DEVFREQ_POSTCHANGE);
> + goto update_status;
[Severity: High]
Will bypassing profile->target() cause transition statistics to permanently
break due to unaligned frequencies?
In drivers/devfreq/devfreq.c:devfreq_update_target(), the frequency is
clamped against PM QoS bounds before calling devfreq_set_target():
if (freq < min_freq) {
freq = min_freq;
flags &= ~DEVFREQ_FLAG_LEAST_UPPER_BOUND; /* Use GLB */
}
if (freq > max_freq) {
freq = max_freq;
flags |= DEVFREQ_FLAG_LEAST_UPPER_BOUND; /* Use LUB */
}
Since we skip profile->target() here, unaligned PM QoS values are passed
directly to devfreq_update_status(). Inside devfreq_update_status(),
devfreq_get_freq_level() attempts to find an exact match in the OPP table:
lev = devfreq_get_freq_level(devfreq, freq);
if (lev < 0) {
ret = lev;
goto out;
}
This mismatch causes devfreq_update_status() to return an error, triggering a
warning flood. Further, previous_freq will be updated to this invalid
frequency, causing all future status updates to fail the prev_lev check.
> + }
> +
> if (devfreq->profile->get_cur_freq)
[ ... ]
> @@ -375,6 +395,7 @@ static int devfreq_set_target(struct devfreq *devfreq, unsigned long new_freq,
> freqs.new = new_freq;
> devfreq_notify_transition(devfreq, &freqs, DEVFREQ_POSTCHANGE);
>
> +update_status:
> if (devfreq_update_status(devfreq, new_freq))
> dev_warn(&devfreq->dev,
> "Couldn't update frequency transition information.\n");
[Severity: High]
This isn't a bug introduced by this patch, but does the following code at the
end of devfreq_set_target() incorrectly overwrite the resume frequency during
suspend?
if (devfreq->suspend_freq)
devfreq->resume_freq = new_freq;
When devfreq_suspend_device() in drivers/devfreq/devfreq.c is called, it
explicitly initiates a transition to suspend_freq:
if (devfreq->suspend_freq) {
mutex_lock(&devfreq->lock);
ret = devfreq_set_target(devfreq, devfreq->suspend_freq, 0);
This overwrites devfreq->resume_freq with the suspend_freq, which prevents the
device from restoring its actual active pre-suspend frequency on resume.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260610-rfc_v7_scmi_memlat-v7-0-f3f68c608f25@oss.qualcomm.com?part=5
^ permalink raw reply
* Re: [PATCH 1/2] bindings: power: supply: qcom,pmic-glink: Document thermal-mitigation
From: Krzysztof Kozlowski @ 2026-06-10 9:04 UTC (permalink / raw)
To: DhruvinRajpura
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Sebastian Reichel, linux-arm-msm, devicetree,
linux-kernel, linux-pm, kamal.wadhwa, jishnu.prakash,
Dhruvin Rajpura
In-Reply-To: <20260609-cooling_device_reg-v1-1-e15bddcb0086@qti.qualcomm.com>
On Tue, Jun 09, 2026 at 02:46:42PM +0530, DhruvinRajpura wrote:
> From: Dhruvin Rajpura <drajpura@qti.qualcomm.com>
>
> The qcom,thermal-mitigation property allows platforms to define
> discrete fast charge current limits used by the thermal framework
> to throttle battery charging in response to thermal events.
>
> Document the qcom,thermal-mitigation property to describe the array
> of fast charge current limits in microamps that map to thermal
> cooling states.
>
> Signed-off-by: Dhruvin Rajpura <drajpura@qti.qualcomm.com>
> ---
> .../devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml
> index ff01d2f3ee5b..fcb69ebaa7cb 100644
> --- a/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml
> +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml
> @@ -58,6 +58,16 @@ properties:
> The array should contain a gpio entry for each PMIC Glink connector, in reg order.
> It is defined that GPIO active level means "CC2" or Reversed/Flipped orientation.
>
> + qcom,thermal-mitigation:
Use proper suffixes, see writing bindings.
Also, name looks too much as policy. Describe the hardware.
> + $ref: /schemas/types.yaml#/definitions/uint32-array
> + description:
> + Array of fast charge current limit values for different system thermal
> + mitigation levels. This should be a flat array that denotes the maximum
> + charging current (in uA) for each thermal level. Elements should be listed
> + in monotonically decreasing (non-increasing) order.
What is a thermal level? How do you define it? How does it map to
thermal bindings?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH RFC v7 3/9] firmware: arm_scmi: vendors: Add QCOM SCMI Generic Extensions
From: sashiko-bot @ 2026-06-10 9:04 UTC (permalink / raw)
To: Pragnesh Papaniya; +Cc: robh, devicetree, conor+dt
In-Reply-To: <20260610-rfc_v7_scmi_memlat-v7-3-f3f68c608f25@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Critical] Missing bounds check on firmware response length causes potential stack buffer overflow or uninitialized memory read.
- [Medium] Undefined behavior in `memcpy` when passed a NULL buffer for a zero-length payload.
--
commit 66dbf88ec6a6058435ff2cd14122285e5de5a740
Author: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
firmware: arm_scmi: vendors: Add QCOM SCMI Generic Extensions
This commit introduces the QCOM SCMI Generic Extensions Protocol, providing
a generic way to expose Qualcomm SoC specific features via the SCMI controller.
> diff --git a/drivers/firmware/arm_scmi/vendors/qcom/qcom-generic-ext.c b/drivers/firmware/arm_scmi/vendors/qcom/qcom-generic-ext.c
> new file mode 100644
> index 0000000000000..77c07272c09d6
> --- /dev/null
> +++ b/drivers/firmware/arm_scmi/vendors/qcom/qcom-generic-ext.c
[ ... ]
> +static int qcom_scmi_common_xfer(const struct scmi_protocol_handle *ph,
> + enum qcom_generic_ext_protocol_cmd cmd_id, void *buf,
> + size_t buf_len, u64 algo_str, u32 param_id, size_t rx_size)
> +{
> + struct scmi_xfer *t;
> + struct qcom_scmi_msg *msg;
> + int ret;
> +
> + /* Reject calls where rx_size exceeds buf_len. */
> + if (rx_size > buf_len)
> + return -EINVAL;
> +
> + ret = ph->xops->xfer_get_init(ph, cmd_id, buf_len + sizeof(*msg), rx_size, &t);
> + if (ret)
> + return ret;
> +
> + msg = t->tx.buf;
> + msg->ext_id = 0;
> + msg->algo_low = cpu_to_le32(lower_32_bits(algo_str));
> + msg->algo_high = cpu_to_le32(upper_32_bits(algo_str));
> + msg->param_id = cpu_to_le32(param_id);
> + memcpy(msg->buf, buf, buf_len);
[Severity: Medium]
Is it possible for this memcpy() to receive a NULL buffer?
If a caller invokes a start or stop activity command with a zero-length payload
(passing NULL for buf and 0 for buf_len), this will result in memcpy() being
called with a NULL source pointer.
Calling memcpy() with a NULL pointer is undefined behavior in standard C,
even if the length is zero, and can trigger warnings when Fortify Source
or UBSAN are enabled.
Should this copy be guarded by a check for buf_len > 0?
> +
> + ret = ph->xops->do_xfer(ph, t);
> + if (!ret && rx_size)
> + /*
> + * Response is returned into the caller's @buf, replacing the
> + * tx payload. Callers using the same on-stack struct for both
> + * directions must not rely on tx contents after this point.
> + */
> + memcpy(buf, t->rx.buf, t->rx.len);
[Severity: Critical]
Does this memcpy() need bounds checking on the received length?
The length t->rx.len is controlled by firmware. If the firmware returns a
payload larger than the caller's allocated buffer (buf_len), this copy could
overflow the caller's stack or buffer.
Conversely, if the firmware returns a truncated response (t->rx.len < rx_size),
fewer bytes will be copied. Since the function returns 0 on success without
reporting the actual received length, the caller might unknowingly read leftover
TX payload as valid RX data.
Would it be safer to validate t->rx.len against buf_len or rx_size, and return
an error if the length does not match expectations?
> + ph->xops->xfer_put(ph, t);
> +
> + return ret;
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260610-rfc_v7_scmi_memlat-v7-0-f3f68c608f25@oss.qualcomm.com?part=3
^ permalink raw reply
* Re: [PATCH RFC v7 4/9] PM / devfreq: Add new target_freq attribute flag for governors
From: sashiko-bot @ 2026-06-10 9:04 UTC (permalink / raw)
To: Pragnesh Papaniya; +Cc: conor+dt, robh, devicetree
In-Reply-To: <20260610-rfc_v7_scmi_memlat-v7-4-f3f68c608f25@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues:
- [High] Pre-existing ABBA deadlock between sysfs read/store operations on governor attributes and governor_store().
- [High] Pre-existing Use-After-Free vulnerabilities due to lockless accesses to df->governor in governor_show() and devfreq_remove_device().
--
commit 362eb55beaf9c6e36069d42a3c923196961acbd8
Author: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
PM / devfreq: Add new target_freq attribute flag for governors
The target_freq sysfs attribute exposes a governor's predicted next target
frequency. This commit introduces DEVFREQ_GOV_ATTR_TARGET_FREQ to allow
governors to opt in to exposing their target_freq via sysfs, and updates
target_freq_show to gate the read on this flag.
> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
> index f08fc6966eaee..2f27a239e34a6 100644
> --- a/drivers/devfreq/devfreq.c
> +++ b/drivers/devfreq/devfreq.c
> @@ -1530,6 +1530,12 @@ static ssize_t target_freq_show(struct device *dev,
[Severity: High]
This is a pre-existing issue, but there appears to be an ABBA deadlock
between sysfs read/store operations on governor attributes and governor_store().
When userspace reads or writes attributes in gov_attr_group (like
polling_interval or timer), the sysfs core acquires an active reference
(kn->active) on the kernfs node before calling the sysfs handler
(e.g., polling_interval_show()). The handler then acquires devfreq_list_lock:
guard(mutex)(&devfreq_list_lock);
Concurrently, if another thread writes to the governor attribute,
governor_store() acquires devfreq_list_lock and calls
sysfs_update_group(&df->dev.kobj, &gov_attr_group):
mutex_lock(&devfreq_list_lock);
...
ret = sysfs_update_group(&df->dev.kobj, &gov_attr_group);
This function synchronously removes the existing files in the group via
kernfs_remove_by_name(), which waits indefinitely for all active
references on those files to drain.
Because the reader thread holds the active reference and waits for the
lock, and the writer thread holds the lock and waits for the active
reference, a permanent ABBA deadlock occurs.
(Note that target_freq_show modified in this patch is not affected since it
resides in devfreq_group, not gov_attr_group).
Is there a way to safely restructure the locking here to avoid this deadlock?
[Severity: High]
This isn't a bug introduced by this patch, but there are Use-After-Free
vulnerabilities due to lockless accesses to df->governor in
governor_show() and devfreq_remove_device().
In governor_show() and devfreq_remove_device(), df->governor is
accessed without holding devfreq_list_lock:
drivers/devfreq/devfreq.c:governor_show() {
...
if (!df->governor)
return -ENOENT;
return sprintf(buf, "%s\n", df->governor->name);
}
drivers/devfreq/devfreq.c:devfreq_remove_device() {
...
if (devfreq->governor)
devfreq->governor->event_handler(devfreq, DEVFREQ_GOV_STOP, NULL);
...
}
If the active governor is removed concurrently (e.g., via module
unload), devfreq_remove_governor() takes devfreq_list_lock, stops the
governor, sets df->governor = NULL, and drops the lock before the
module is unloaded.
Since the unprotected functions do not acquire devfreq_list_lock to
serialize with governor removal, they can read a valid pointer to the
governor, get preempted while the module is unloaded, and dereference
freed module memory or execute unloaded function pointers when they
resume.
Could devfreq_list_lock be used in these functions to prevent this race?
> {
> struct devfreq *df = to_devfreq(dev);
>
> + guard(mutex)(&devfreq_list_lock);
> +
> + if (!df->profile || !df->governor ||
> + !IS_SUPPORTED_ATTR(df->governor->attrs, TARGET_FREQ))
> + return -EINVAL;
> +
> return sprintf(buf, "%lu\n", df->previous_freq);
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260610-rfc_v7_scmi_memlat-v7-0-f3f68c608f25@oss.qualcomm.com?part=4
^ permalink raw reply
* Re: [PATCH v2 07/16] usb: hub: Power on connected M.2 E-key connectors
From: sashiko-bot @ 2026-06-10 9:03 UTC (permalink / raw)
To: Chen-Yu Tsai; +Cc: devicetree, robh, conor+dt
In-Reply-To: <20260610084053.2059858-8-wenst@chromium.org>
Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [Critical] Unconditional calls to power sequencing APIs will fail all USB port initializations when `CONFIG_POWER_SEQUENCING` is disabled.
- [High] Concurrent modification of the `pwrseq_on` bitfield on a shared `usb_port` device causes data races and corruption of other bitfields.
- [High] Premature physical power-off of the shared M.2 E-key power sequencer when one peer logical port suspends, unexpectedly disconnecting the active peer.
- [Medium] Leaked fwnode reference during USB port creation via `fwnode_graph_get_port_by_id()`.
--
commit 984160fb49fab6dc951a766897ded9fb49d0992b
Author: Chen-Yu Tsai <wenst@chromium.org>
usb: hub: Power on connected M.2 E-key connectors
This patch adds support for powering on directly connected M.2 E-key
connectors via the power sequencing API. It ties the power sequencing
descriptor to the usb port device to allow providers to distinguish
ports on a hub. The power state is toggled using the power sequencing
API during port power changes.
> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> index 0c75965fefb7c..585b6beec71bb 100644
> --- a/drivers/usb/core/hub.c
> +++ b/drivers/usb/core/hub.c
> @@ -886,20 +887,41 @@ static void hub_tt_work(struct work_struct *work)
> int usb_hub_set_port_power(struct usb_device *hdev, struct usb_hub *hub,
> int port1, bool set)
> {
> - int ret;
> + struct usb_port *pwrseq_port = hub->ports[port1 - 1];
> + int ret = 0;
> +
> + /* non-SuperSpeed USB port holds pwrseq descriptor reference. */
> + if (hub->ports[port1 - 1]->is_superspeed && hub->ports[port1 - 1]->peer)
> + pwrseq_port = hub->ports[port1 - 1]->peer;
> +
> + if (set && !pwrseq_port->pwrseq_on)
> + ret = pwrseq_power_on(pwrseq_port->pwrseq);
> + else if (!set && pwrseq_port->pwrseq_on)
> + ret = pwrseq_power_off(pwrseq_port->pwrseq);
[Severity: High]
Will this prematurely cut physical power to the M.2 slot if the HiSpeed
logical port suspends?
A physical M.2 connector has both a SuperSpeed and HiSpeed logical port.
This patch binds the power sequencing descriptor only to the HiSpeed port
and shares a single pwrseq_on boolean for both logical ports.
If a SuperSpeed device is connected, the SuperSpeed port remains active,
but the HiSpeed port suspends via usb_port_runtime_suspend() since it detects
no active HiSpeed device. Suspending the HiSpeed port invokes
usb_hub_set_port_power(..., false) which immediately calls
pwrseq_power_off() here since pwrseq_on is true.
This would abruptly cut physical power to the M.2 slot and drop the active
SuperSpeed device, because the boolean flag bypasses the power sequencing
framework's internal reference counting and ignores the active state of the
SuperSpeed port.
> + if (ret)
> + return ret;
>
> if (set)
> ret = set_port_feature(hdev, port1, USB_PORT_FEAT_POWER);
> else
> ret = usb_clear_port_feature(hdev, port1, USB_PORT_FEAT_POWER);
>
> - if (ret)
> + if (ret) {
> + if (set && !pwrseq_port->pwrseq_on)
> + pwrseq_power_off(pwrseq_port->pwrseq);
> + else if (!set && pwrseq_port->pwrseq_on)
> + pwrseq_power_on(pwrseq_port->pwrseq);
> return ret;
> + }
>
> - if (set)
> + if (set) {
> set_bit(port1, hub->power_bits);
> - else
> + pwrseq_port->pwrseq_on = 1;
> + } else {
> clear_bit(port1, hub->power_bits);
> + pwrseq_port->pwrseq_on = 0;
> + }
[Severity: High]
Could modifying this bitfield without holding usb_lock_port() cause a data race?
Since pwrseq_on is packed alongside other 1-bit fields in struct usb_port
(like ignore_event, early_stop, and usb3_lpm_u1_permit), modifying it here
in usb_hub_set_port_power() without synchronization can cause a
read-modify-write data race.
If sysfs (like usb3_lpm_u1_permit_store) or hub event workqueues modify
adjacent bits under their respective locks concurrently, one thread's update
could silently overwrite the other's, corrupting the port state.
[ ... ]
> diff --git a/drivers/usb/core/port.c b/drivers/usb/core/port.c
> index d9d3e2bb8f251..a5e7fbf4aa6e2 100644
> --- a/drivers/usb/core/port.c
> +++ b/drivers/usb/core/port.c
> @@ -803,10 +846,25 @@ int usb_hub_create_port_device(struct usb_hub *hub, int port1)
> goto err_put_kn;
> }
>
[Severity: Medium]
Does port creation leak an fwnode reference here?
Earlier in usb_hub_create_port_device(), the call to
fwnode_graph_get_port_by_id() returns a firmware node with an incremented
reference count. This node is passed to device_set_node(), which assigns it
but does not take ownership of the reference.
Neither the error paths in usb_hub_create_port_device(), nor
usb_hub_remove_port_device() call fwnode_handle_put() to release it, causing
a reference leak every time a usb port is enumerated.
> + port_dev->pwrseq = usb_hub_port_pwrseq_get(port_dev);
> + if (IS_ERR(port_dev->pwrseq)) {
> + retval = PTR_ERR(port_dev->pwrseq);
> + dev_err_probe(&port_dev->dev, retval,
> + "failed to get power sequencing descriptor\n");
> + goto err_put_kn;
> + }
> +
> + retval = pwrseq_power_on(port_dev->pwrseq);
> + if (retval) {
> + dev_err_probe(&port_dev->dev, retval, "failed to enable power\n");
> + goto err_put_pwrseq;
> + }
[Severity: Critical]
Will this fail port creation for all usb ports when power sequencing
is disabled?
If the kernel is built without power sequencing enabled,
usb_hub_port_pwrseq_get() deliberately returns NULL.
However, pwrseq_power_on(NULL) unconditionally returns -ENOSYS when the
feature is disabled. Treating -ENOSYS as a hard failure here will abort port
creation, causing the entire usb subsystem to fail enumerating any ports on
systems where power sequencing is disabled.
> + port_dev->pwrseq_on = 1;
> +
> retval = component_add(&port_dev->dev, &connector_ops);
> if (retval) {
> dev_warn(&port_dev->dev, "failed to add component\n");
> - goto err_put_kn;
> + goto err_pwrseq_off;
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260610084053.2059858-1-wenst@chromium.org?part=7
^ permalink raw reply
* Re: [PATCH v2 14/16] arm64: dts: mediatek: mt8195-cherry: Add M.2 E-key slot
From: sashiko-bot @ 2026-06-10 9:03 UTC (permalink / raw)
To: Chen-Yu Tsai; +Cc: devicetree, conor+dt, robh
In-Reply-To: <20260610084053.2059858-15-wenst@chromium.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Deletion of the `wifi@0` child node removes the `wakeup-source` property, breaking default Wake-on-WLAN (WOWLAN) capability.
--
commit f79abe85df05e70cd87af21f7a5b924157250109
Author: Chen-Yu Tsai <wenst@chromium.org>
arm64: dts: mediatek: mt8195-cherry: Add M.2 E-key slot
The commit adds an M.2 E-key slot representation for the Mt8195 Cherry
design. It wires up PCIe, USB, and auxiliary signals, replacing the older
PCIe wifi node and power supply properties.
> diff --git a/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi b/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi
> index ef7afc436aefc..c95a54de35672 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi
[ ... ]
> @@ -791,14 +832,14 @@ pcie@0 {
> reg = <0 0 0 0 0>;
> device_type = "pci";
> num-lanes = <1>;
> - vpcie3v3-supply = <&pp3300_wlan>;
> #address-cells = <3>;
> #size-cells = <2>;
> ranges;
>
> - wifi@0 {
> - reg = <0 0 0 0 0>;
> - wakeup-source;
[Severity: Medium]
Does this removal break default Wake-on-WLAN (WOWLAN) capability?
The mt7921 Wi-Fi driver specifically checks for the wakeup-source property
on its Device Tree node during probe to call device_init_wakeup() and
enable Wake-on-WLAN by default.
By replacing the wifi@0 node with an OF graph port endpoint, the PCI core
will no longer match the PCI device to an OF node, making dev->of_node NULL.
This means the driver will not detect the property and could silently leave
default WOWLAN disabled.
> + port {
> + pcie1_ep: endpoint {
> + remote-endpoint = <&wifi_ep>;
> + };
> };
> };
> };
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260610084053.2059858-1-wenst@chromium.org?part=14
^ permalink raw reply
* Re: [PATCH v2 16/16] arm64: dts: mediatek: mt8188-geralt: Add WiFi/BT as M.2 E-key slot
From: sashiko-bot @ 2026-06-10 9:02 UTC (permalink / raw)
To: Chen-Yu Tsai; +Cc: robh, conor+dt, devicetree
In-Reply-To: <20260610084053.2059858-17-wenst@chromium.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The pinctrl configuration for the W_DISABLE kill pins drives them physically HIGH before the VIO/VCC regulators are enabled, causing chip back-powering and an initial signal glitch.
--
commit c9c4e7dd87a963320b0c2bf646e1e008f5ee5638
Author: Chen-Yu Tsai <wenst@chromium.org>
arm64: dts: mediatek: mt8188-geralt: Add WiFi/BT as M.2 E-key slot
This commit models the chip-on-board WiFi/BT solution on MT8188 Geralt as
an M.2 E-key slot. It adds the PMU_EN pin controls and drops the always-on
property from the pp3300_wlan regulator to properly reflect power sequencing.
> diff --git a/arch/arm64/boot/dts/mediatek/mt8188-geralt.dtsi b/arch/arm64/boot/dts/mediatek/mt8188-geralt.dtsi
> index 4cb23595d17b4..d7b5eb95ba0fe 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8188-geralt.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8188-geralt.dtsi
[ ... ]
> @@ -193,6 +202,39 @@ adsp_dma_mem: memory@61000000 {
> no-map;
> };
> };
> +
> + wifi-bt-connector {
> + compatible = "pcie-m2-e-connector";
> + pinctrl-names = "default";
> + pinctrl-0 = <&m2_e_key_kill_pins>;
> + vpcie1v8-supply = <&mt6359_vcn18_ldo_reg>;
> + vpcie3v3-supply = <&wlan_pmu>;
> + w-disable1-gpios = <&pio 13 GPIO_ACTIVE_LOW>;
> + w-disable2-gpios = <&pio 14 GPIO_ACTIVE_LOW>;
[ ... ]
> @@ -999,6 +1057,14 @@ pins-bus {
> };
> };
>
> + m2_e_key_kill_pins: m2-e-key-kill-pins {
> + pins-kill {
> + pinmux = <PINMUX_GPIO13__FUNC_B_GPIO13>,
> + <PINMUX_GPIO14__FUNC_B_GPIO14>;
> + output-high;
[Severity: High]
Since pp3300_wlan is no longer always-on, does this output-high configuration
cause the unpowered Wi-Fi/BT chip to be back-powered?
The device core automatically applies the default pinctrl state during
instantiation, before the power sequence driver probes and turns on the
regulators. Driving a physical HIGH voltage into the w-disable pins of an
unpowered IC can forward-bias internal ESD diodes and leak current.
Additionally, when the driver eventually probes, it will request the
w-disable pins. Since the wifi-bt-connector node defines them as
GPIO_ACTIVE_LOW, requesting a logical HIGH translates to a physical LOW.
Will this result in an unintended HIGH-to-LOW physical glitch on the
unpowered chip's w-disable lines before the regulators are finally enabled?
> + };
> + };
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260610084053.2059858-1-wenst@chromium.org?part=16
^ permalink raw reply
* Re: [PATCH RFC v7 2/9] dt-bindings: firmware: arm,scmi: Add Qualcomm Generic Extension Protocol
From: sashiko-bot @ 2026-06-10 9:01 UTC (permalink / raw)
To: Pragnesh Papaniya; +Cc: devicetree, conor+dt, robh
In-Reply-To: <20260610-rfc_v7_scmi_memlat-v7-2-f3f68c608f25@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Adding `qcom,generic-scmi.yaml` to the unconditional `anyOf` block silently bypasses strict schema validation for all other vendor schemas (e.g., `nxp,imx95-scmi.yaml`).
--
commit 4cdbbb0bcf03bec0f34cb611707f09de406a9cfa
Author: Pragnesh Papaniya <pragnesh.papaniya@oss.qualcomm.com>
dt-bindings: firmware: arm,scmi: Add Qualcomm Generic Extension Protocol
This commit adds the binding schema for the Qualcomm SCMI Generic Extension
Protocol to support Bus DVFS on several SoCs.
> diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> index d06cca9273c48..aedc57dd3b389 100644
> --- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> +++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> @@ -24,6 +24,7 @@ description: |
>
> anyOf:
> - $ref: /schemas/firmware/nxp,imx95-scmi.yaml
> + - $ref: /schemas/firmware/qcom,generic-scmi.yaml
[Severity: Medium]
Does adding qcom,generic-scmi.yaml to the unconditional anyOf block silently
bypass strict schema validation for all other vendor schemas?
Due to JSON Schema evaluation rules, an additionalProperties: true keyword in
the newly added QCOM schema evaluates to boolean true and annotates all
properties it matches as evaluated.
If an NXP device tree has an invalid property (for example, wrong types inside
protocol@81 or protocol@84), it correctly fails the nxp,imx95-scmi.yaml
schema. However, because it is evaluated against the unconditional anyOf block
here, it then falls back to qcom,generic-scmi.yaml.
Since the QCOM schema does not define NXP's specific properties, it accepts
them via its additionalProperties: true directive and annotates them as
evaluated. The anyOf condition is thus satisfied, and the top-level
unevaluatedProperties: false check in arm,scmi.yaml passes, silently
suppressing the NXP schema validation failure.
Should vendor schemas be conditionally applied based on compatible strings
(for example, using if: properties: compatible: contains: ...) instead of
being placed into an unconditional anyOf list?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260610-rfc_v7_scmi_memlat-v7-0-f3f68c608f25@oss.qualcomm.com?part=2
^ 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