* Re: [PATCH v3 4/4] phy: qualcomm: qmp-combo: Add support for Hawi SoC
From: Dmitry Baryshkov @ 2026-07-20 22:24 UTC (permalink / raw)
To: sashiko
Cc: Ronak Raheja, robh, krzk+dt, olteanv, devicetree, vkoul, conor+dt,
neil.armstrong, linux-phy, linux-arm-msm
In-Reply-To: <20260508232620.2FD04C2BCB0@smtp.kernel.org>
On Fri, May 08, 2026 at 11:26:19PM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [High] Missing DP PHY function pointers in `hawi_usb3dpphy_cfg` lead to NULL pointer dereferences when the DP PHY is initialized.
> - [High] Valid register offset `0x00` causes the AON toggle hardware reset override to be silently skipped.
Please add DP programming. There should be no NULL dereferences.
> > @@ -3699,9 +3915,9 @@ static int qmp_combo_com_init(struct qmp_combo *qmp, bool force)
> > SW_USB3PHY_RESET_MUX | SW_USB3PHY_RESET);
> >
> > /* override hardware control for reset of qmp phy */
> > - if (pcs_aon && cfg->regs[QPHY_AON_TOGGLE_ENABLE]) {
> > - qphy_clrbits(pcs_aon, cfg->regs[QPHY_AON_TOGGLE_ENABLE], 0x1);
> > - qphy_clrbits(pcs_aon, cfg->regs[QPHY_DP_AON_TOGGLE_ENABLE], 0x1);
> > + if (aon_toggle && cfg->regs[QPHY_AON_TOGGLE_ENABLE]) {
> > + qphy_clrbits(aon_toggle, cfg->regs[QPHY_AON_TOGGLE_ENABLE], 0x1);
> > + qphy_clrbits(aon_toggle, cfg->regs[QPHY_DP_AON_TOGGLE_ENABLE], 0x1);
> > }
>
> Is it possible for the hardware reset override to be silently skipped here?
>
> The V10 register layout maps QPHY_AON_TOGGLE_ENABLE to
> QPHY_V10_COM_AON_USB3_AON_TOGGLE_ENABLE, which is defined as 0x00 in
> phy-qcom-qmp-com-aon-v10.h.
>
> Because 0x00 is a valid register offset but evaluates to false in C, the
> check for cfg->regs[QPHY_AON_TOGGLE_ENABLE] will fail. This would skip the
> qphy_clrbits() calls entirely, bypassing the necessary hardware reset override
> sequence and leaving the PHY in a broken state.
>
> Could we use a different way to check if this register is supported by the
> layout without relying on the truthiness of the offset value?
This deserves a comment.
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v7 10/10] arm64: dts: qcom: shikra: Add gpio-reserved-ranges to tlmm
From: Dmitry Baryshkov @ 2026-07-20 22:19 UTC (permalink / raw)
To: Komal Bajaj
Cc: Vinod Koul, Frank Li, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Krzysztof Kozlowski, Georgi Djakov, Bjorn Andersson,
Konrad Dybcio, linux-arm-msm, dmaengine, devicetree, linux-kernel,
linux-pm, Anurag Pateriya
In-Reply-To: <20260720-shikra-dt-m1-v7-10-7dc99100c6dd@oss.qualcomm.com>
On Mon, Jul 20, 2026 at 04:19:26PM +0530, Komal Bajaj wrote:
> Add gpio-reserved-ranges property to the TLMM node for both Shikra
> SoM variants (CQM and IQS). These reserved GPIOs are inaccessible
> from the non-secure world and dedicated to fixed functions.
>
> Signed-off-by: Anurag Pateriya <apateriy@qti.qualcomm.com>
> Signed-off-by: Komal Bajaj <komal.bajaj@oss.qualcomm.com>
Who is the author of the patch? Why does it have two SoBs? Should there
be a Co-developed-by?
Other than that:
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/shikra-cqm-som.dtsi | 6 ++++++
> arch/arm64/boot/dts/qcom/shikra-iqs-som.dtsi | 6 ++++++
> 2 files changed, 12 insertions(+)
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH] dt-bindings: clock: ti,da850-pll: Convert to DT schema
From: David Lechner @ 2026-07-20 22:11 UTC (permalink / raw)
To: Bhargav Joshi, Michael Turquette, Stephen Boyd, Brian Masney,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-clk, devicetree, linux-kernel, goledhruva, m-chawdhry,
daniel.baluta, simona.toaca
In-Reply-To: <20260717-ti-pll-v1-1-f6f9ba8c9b5e@gmail.com>
On 7/17/26 1:21 PM, Bhargav Joshi wrote:
> Convert TI da850-pll binding from legacy text to dt schema.
> No functional change is introduced during conversion.
>
> Signed-off-by: Bhargav Joshi <j.bhargav.u@gmail.com>
> ---
...
> diff --git a/Documentation/devicetree/bindings/clock/ti/davinci/ti,da850-pll.yaml b/Documentation/devicetree/bindings/clock/ti/davinci/ti,da850-pll.yaml
> new file mode 100644
> index 000000000000..5e4109567b75
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/ti/davinci/ti,da850-pll.yaml
> @@ -0,0 +1,177 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/clock/ti/davinci/ti,da850-pll.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: TI DaVinci PLL Controllers
TI DA850/OMAP-L138/AM18xx PLL Controllers
(The original binding used to have more, but they have since been removed
because of obsolescence. We don't expect to ever add more.)
> +
> +maintainers:
> + - David Lechner <david@lechnology.com>
> + - Bhargav Joshi <j.bhargav.u@gmail.com>
Do you actually have knowledge/interest/hardware needed to
support this?
> +
> +description:
> + The PLL provides clocks to most of the components on the SoC. In addition to
> + the PLL itself, this controller also contains bypasses, gates, dividers, an
> + multiplexers for various clock signals.
> +
> +properties:
> + compatible:
> + enum:
> + - ti,da850-pll0
> + - ti,da850-pll1
> +
> + reg:
> + maxItems: 1
> +
> + clocks:
> + minItems: 1
> + maxItems: 2
> +
> + clock-names:
> + minItems: 1
> + maxItems: 2
The items: needs to be moved up here. The if: should only limit pll1.
^ permalink raw reply
* Re: [PATCH 2/2] media: i2c: Add driver for Sony IMX662 sensor
From: Sakari Ailus @ 2026-07-20 22:03 UTC (permalink / raw)
To: Dave Stevenson
Cc: Jai Luthra, Alexander Shiyan, linux-media, devicetree,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Hans Verkuil, Hans de Goede, Tetsuya Nomura,
Manivannan Sadhasivam
In-Reply-To: <CAPY8ntCvB9ij=rMwwBmBDfe_gWQboX9Xbt0ZB6WPVyFvc2CLZw@mail.gmail.com>
Hi Dave, Jai,
On Mon, Jul 20, 2026 at 06:39:34PM +0100, Dave Stevenson wrote:
> > and implement
> > it using the common raw sensor model directly?
> >
> > I did it for IMX678 [1] on Sakari's suggestion [2]. The two sensors are
> > quite similar, so I'm happy to help in whatever way I can on getting this
> > working with the new model too :-)
>
> Is this effectively saying that linux-media is closed to sensor
> drivers not adopting the common raw sensor model, even though AIUI
> that isn't ready yet? I can accept that for a period, but how long is
> it reasonable for that to be the case? A year?
> With all due respect to those involved, the series has been around so
> long in various guises that it's a case of I'll believe it when I see
> it merged.
I know... :-( Hopefully not as long as that.
I intend to send update at least to the pre-metadata series next week and
ideally the pre-metadata series could go to 7.3. I've got some bugs to fix
in the main series so that may take a little longer, after which there's
libcamera part to be implemented.
--
Regards,
Sakari Ailus
^ permalink raw reply
* Re: [PATCH 5/5] soc: qcom: ubwc: Add Kalambo UBWC config
From: Dmitry Baryshkov @ 2026-07-20 21:59 UTC (permalink / raw)
To: Gopikrishna Garmidi
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Sibi Sankar, Pankaj Patil, Rajendra Nayak,
linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260718-b4-kalambo-crd-v1-5-a1069b5a2757@oss.qualcomm.com>
On Sat, Jul 18, 2026 at 05:06:25AM -0700, Gopikrishna Garmidi wrote:
> Qualcomm Kalambo is a derivative of the Mahua SoC and shares the same
> Universal Bandwidth Compression (UBWC) configuration. Add the Kalambo
> compatible to the UBWC configuration table to enable support.
>
> Signed-off-by: Gopikrishna Garmidi <gopikrishna.garmidi@oss.qualcomm.com>
> ---
> drivers/soc/qcom/ubwc_config.c | 1 +
> 1 file changed, 1 insertion(+)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 4/5] firmware: qcom: scm: Allow QSEECOM on Kalambo CRD
From: Dmitry Baryshkov @ 2026-07-20 21:58 UTC (permalink / raw)
To: Gopikrishna Garmidi
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Sibi Sankar, Pankaj Patil, Rajendra Nayak,
linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260718-b4-kalambo-crd-v1-4-a1069b5a2757@oss.qualcomm.com>
On Sat, Jul 18, 2026 at 05:06:24AM -0700, Gopikrishna Garmidi wrote:
> Add Kalambo CRD board to the QSEECOM allowlist for enabling access to
> efivars.
>
> Signed-off-by: Gopikrishna Garmidi <gopikrishna.garmidi@oss.qualcomm.com>
> ---
> drivers/firmware/qcom/qcom_scm.c | 1 +
> 1 file changed, 1 insertion(+)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 2/5] arm64: dts: qcom: Add Kalambo SoC
From: Dmitry Baryshkov @ 2026-07-20 21:57 UTC (permalink / raw)
To: Gopikrishna Garmidi
Cc: Konrad Dybcio, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sibi Sankar, Pankaj Patil,
Rajendra Nayak, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <782d626c-2545-4719-9833-efbc9ba82871@oss.qualcomm.com>
On Mon, Jul 20, 2026 at 08:34:36PM +0530, Gopikrishna Garmidi wrote:
>
> Hi Konrad,
>
> Thanks a lot for the review and for catching these
> > On 7/18/26 2:06 PM, Gopikrishna Garmidi wrote:
> > > Introduce support for the Qualcomm Kalambo SoC. It is derived from Mahua
> > > with CPU cluster 0 removed, leaving it with just cluster 1. As a result,
> > > the PDP mailbox and SCP low-priority register windows are updated to
> > > match the reduced CPU complex. Everything else should work as-is.
> > >
> > > Add a label to the Glymur cluster0 cpu-map node to allow its removal on
> > > derived SoCs.
> > >
> > > Signed-off-by: Gopikrishna Garmidi <gopikrishna.garmidi@oss.qualcomm.com>
> > > ---
> > > arch/arm64/boot/dts/qcom/glymur.dtsi | 2 +-
> > > arch/arm64/boot/dts/qcom/kalambo.dtsi | 29 +++++++++++++++++++++++++++++
> > > 2 files changed, 30 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/arch/arm64/boot/dts/qcom/glymur.dtsi b/arch/arm64/boot/dts/qcom/glymur.dtsi
> > > index 55d91c696a3a..f2feef362be5 100644
> > > --- a/arch/arm64/boot/dts/qcom/glymur.dtsi
> > > +++ b/arch/arm64/boot/dts/qcom/glymur.dtsi
> > > @@ -275,7 +275,7 @@ cpu17: cpu@20500 {
> > > };
> > > cpu-map {
> > > - cluster0 {
> > > + cpu_map_cluster0: cluster0 {
> >
> > I doubt the code that parses this will be happy about not
> > being able to start from 'cluster0'
> >
>
> Good catch, you're right. parse_cluster() in drivers/base/arch_topology.c
> walks "cluster%d" starting at 0 and bails out on the first missing index, so
> deleting cluster0 and leaving only cluster1 means the topology never gets
> parsed at all.
How was this patchset tested then?
--
With best wishes
Dmitry
^ permalink raw reply
* [PATCH V1] dt-bindings: mmc: sdhci-msm: Document the Maili compatible
From: Nitin Rawat @ 2026-07-20 21:56 UTC (permalink / raw)
To: krzk+dt, robh, ulfh, conor+dt, andersson
Cc: linux-arm-msm, linux-kernel, devicetree, linux-mmc, Nitin Rawat
Document the compatible for SDHCI on Qualcomm Maili SoC.
Signed-off-by: Nitin Rawat <nitin.rawat@oss.qualcomm.com>
---
Documentation/devicetree/bindings/mmc/qcom,sdhci-msm.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/mmc/qcom,sdhci-msm.yaml b/Documentation/devicetree/bindings/mmc/qcom,sdhci-msm.yaml
index bd558a11b792..8dfcd1351551 100644
--- a/Documentation/devicetree/bindings/mmc/qcom,sdhci-msm.yaml
+++ b/Documentation/devicetree/bindings/mmc/qcom,sdhci-msm.yaml
@@ -47,6 +47,7 @@ properties:
- qcom,ipq9574-sdhci
- qcom,ipq9650-sdhci
- qcom,kaanapali-sdhci
+ - qcom,maili-sdhci
- qcom,milos-sdhci
- qcom,qcm2290-sdhci
- qcom,qcs404-sdhci
--
2.34.1
^ permalink raw reply related
* [PATCH] ARM: dts: allwinner: a10: Fix PMU interrupt
From: Andre Przywara @ 2026-07-20 21:51 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland
Cc: devicetree, linux-arm-kernel, linux-sunxi, linux-kernel
The Performance Monitoring Unit of the Cortex-A8 cores in the Allwinner
A10 SoC is connected to interrupt line 66, not 3. This is shown in the
manual (where interrupt 3 is assigned to UART2, also in our .dtsi), but
has also been confirmed by triggering an PMU overflow interrupt and
inspecting the IRQ controller status registers (from U-Boot).
Please note that "perf stat" does not use interrupts, this might explain
why this evaded the initial testing.
Fixes: 7e345d25c796 ("ARM: dts: sun4i-a10: Add PMU node")
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
arch/arm/boot/dts/allwinner/sun4i-a10.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/allwinner/sun4i-a10.dtsi b/arch/arm/boot/dts/allwinner/sun4i-a10.dtsi
index 51a6464aab9a3..cabf619c2e217 100644
--- a/arch/arm/boot/dts/allwinner/sun4i-a10.dtsi
+++ b/arch/arm/boot/dts/allwinner/sun4i-a10.dtsi
@@ -185,7 +185,7 @@ de: display-engine {
pmu {
compatible = "arm,cortex-a8-pmu";
- interrupts = <3>;
+ interrupts = <66>;
};
reserved-memory {
--
2.46.4
^ permalink raw reply related
* Re: [PATCH] arm64: dts: allwinner: a523: x96qpro+: overvolting eMMC
From: sashiko-bot @ 2026-07-20 21:50 UTC (permalink / raw)
To: Andre Przywara; +Cc: conor+dt, devicetree, robh, linux-sunxi
In-Reply-To: <20260720213832.3763-1-andre.przywara@arm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Bumping the eMMC IO regulator (`reg_cldo1`) to 1.9V inadvertently misconfigures the SoC's IO bank (Port C) into 3.3V power mode instead of 1.8V mode, creating a logic threshold mismatch.
--
--- Patch [1]: [PATCH] arm64: dts: allwinner: a523: x96qpro+: overvolting eMMC ---
commit e4c261c388d6e406babdf0d56ac61d104d537230
Author: Andre Przywara <andre.przywara@arm.com>
Date: Mon Jul 20 21:38:32 2026 +0000
arm64: dts: allwinner: a523: x96qpro+: overvolting eMMC
This commit changes the eMMC IO regulator voltage on PortC from 1.8V to 1.9V
for the X96QPro+ device. The goal is to improve eMMC stability and performance
without drastically limiting the clock frequency.
> diff --git a/arch/arm64/boot/dts/allwinner/sun55i-h728-x96qpro+.dts b/arch/arm64/boot/dts/allwinner/sun55i-h728-x96qpro+.dts
> --- a/arch/arm64/boot/dts/allwinner/sun55i-h728-x96qpro+.dts
> +++ b/arch/arm64/boot/dts/allwinner/sun55i-h728-x96qpro+.dts
[ ... ]
> @@ -194,8 +194,8 @@ reg_bldo4: bldo4 {
>
> reg_cldo1: cldo1 {
> regulator-always-on;
> - regulator-min-microvolt = <1800000>;
> - regulator-max-microvolt = <1800000>;
> + regulator-min-microvolt = <1900000>;
> + regulator-max-microvolt = <1900000>;
[Severity: High]
Does bumping this regulator to 1.9V inadvertently force the SoC's IO bank
(Port C) into 3.3V power mode?
Looking at sunxi_pinctrl_set_io_bias_cfg() in
drivers/pinctrl/sunxi/pinctrl-sunxi.c, the driver uses a strict check when
evaluating the voltage:
case BIAS_VOLTAGE_PIO_POW_MODE_SEL:
val = uV <= 1800000 ? 1 : 0;
Since 1900000 is greater than 1800000, this evaluates to 0 and clears the
PIO_POW_MOD_SEL register bit, incorrectly configuring the IO bank for 3.3V
mode while being powered at 1.9V.
Could this mismatch alter input receiver thresholds and drive strengths,
potentially causing signal integrity issues or long-term hardware
degradation?
> regulator-name = "vcc-codec-sd";
> };
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260720213832.3763-1-andre.przywara@arm.com?part=1
^ permalink raw reply
* [PATCH] arm64: dts: allwinner: a523: x96qpro+: overvolting eMMC
From: Andre Przywara @ 2026-07-20 21:38 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland
Cc: devicetree, linux-arm-kernel, linux-sunxi, linux-kernel
On the X96QPro+ TV box, the eMMC wasn't working properly: the chip would
be detected, but most requests failed, leaving it unusable. Some
"solutions" were circulating downstream, one "popular" one is severely
limiting the clock frequency, with a drastic performance impact.
Instead slightly bumping the I/O voltage on PortC from the canonical
1.8V to 1.9V seemed to do the trick: the eMMC now works and reaches the
expected 120MB/s performance.
Adjust the respective regulator voltage in the .dts to enable eMMC
operation on that device.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
Hi,
I am not super happy with this patch, but it seems to be a pragmatic and
the least hacky solution I have seen.
Cheers,
Andre
arch/arm64/boot/dts/allwinner/sun55i-h728-x96qpro+.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/allwinner/sun55i-h728-x96qpro+.dts b/arch/arm64/boot/dts/allwinner/sun55i-h728-x96qpro+.dts
index a96927fbdadd5..5636e95312218 100644
--- a/arch/arm64/boot/dts/allwinner/sun55i-h728-x96qpro+.dts
+++ b/arch/arm64/boot/dts/allwinner/sun55i-h728-x96qpro+.dts
@@ -194,8 +194,8 @@ reg_bldo4: bldo4 {
reg_cldo1: cldo1 {
regulator-always-on;
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
+ regulator-min-microvolt = <1900000>;
+ regulator-max-microvolt = <1900000>;
regulator-name = "vcc-codec-sd";
};
--
2.46.4
^ permalink raw reply related
* Re: [PATCH 0/4] media: rc: sunxi-cir: support the A523/H728/T527 IR receiver
From: Justin Suess @ 2026-07-20 21:33 UTC (permalink / raw)
To: Andre Przywara
Cc: Sean Young, Mauro Carvalho Chehab, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Maxime Ripard, linux-media, devicetree, linux-arm-kernel,
linux-sunxi, Sashiko
In-Reply-To: <20260720225310.039aca2e@ryzen.lan>
On Mon, Jul 20, 2026 at 10:53:10PM +0200, Andre Przywara wrote:
> On Thu, 2 Jul 2026 17:47:46 -0400
> Justin Suess <utilityemal77@gmail.com> wrote:
>
> Hey Justin,
>
> > This series adds support for the CIR receiver found in the Allwinner
> > A523/T527/H728 family (sun55i). The only board in this family that I
>
> will you be able to send a v2 with the fixes we discussed in this
> thread? No driver changes, just the binding for the new specific
> compatible string, and the DT changes.
> I tested this on the X96QPro+, and also managed to enable IR operation
> on the Avaota board, where it uses the other IP instance (and another
> pin).
>
> Please let us know if you can send a new version this week still, to
> possibly allow a v7.3 merge. Happy to review that quickly then.
> If not, please drop me a note, I can then take care of that.
>
Gotcha should be no problem! Sorry I was working on some other patches
for a bit and was out of town and didn't have access to the hardware.
I'll get the board out of my closet and do some testing before I send...
Justin
> Cheers,
> Andre
>
^ permalink raw reply
* Re: [PATCH 2/2] arm64: dts: imx8qm-ss-conn: Add HSIC usb@5b0e0000 node
From: sashiko-bot @ 2026-07-20 21:24 UTC (permalink / raw)
To: Frank.Li; +Cc: devicetree, robh, conor+dt, Frank.Li, imx
In-Reply-To: <20260720-qm_smmu-v1-2-3689fbd8b516@nxp.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] The `usbphynop2` node requests the wrong power domain (`IMX_SC_R_USB_0_PHY` instead of `IMX_SC_R_USB_1_PHY`).
- [Medium] The `usbh1` node is enabled by default (missing `status = "disabled";`), violating SoC `.dtsi` practices and causing unconditional probing.
- [Low] Missing required `#phy-cells` property in the `usbphynop2` node.
--
--- Patch [2]: [PATCH 2/2] arm64: dts: imx8qm-ss-conn: Add HSIC usb@5b0e0000 node ---
commit 9497d73ee79f69a11e0a9347cd596ca4c9842914
Author: Frank Li <Frank.Li@nxp.com>
arm64: dts: imx8qm-ss-conn: Add HSIC usb@5b0e0000 node
Add usb@5b0e0000 and related node for i.MX8QM.
> diff --git a/arch/arm64/boot/dts/freescale/imx8qm-ss-conn.dtsi b/arch/arm64/boot/dts/freescale/imx8qm-ss-conn.dtsi
> index 1370a571153a5..c7063aaac4a34 100644
> --- a/arch/arm64/boot/dts/freescale/imx8qm-ss-conn.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8qm-ss-conn.dtsi
> @@ -4,6 +4,40 @@
> * Dong Aisheng <aisheng.dong@nxp.com>
> */
>
> +&{/} {
> + usbphynop2: usbphynop2 {
> + compatible = "usb-nop-xceiv";
[Severity: Low]
Does this node need a #phy-cells = <0>; property? The usb-nop-xceiv.yaml
binding schema typically requires this property to be present, and omitting
it might cause dtbs_check validation failures during the build.
> + clocks = <&usb2_lpcg IMX_LPCG_CLK_7>;
> + clock-names = "main_clk";
> + power-domains = <&pd IMX_SC_R_USB_0_PHY>;
[Severity: High]
Is IMX_SC_R_USB_0_PHY the correct power domain for usbphynop2? Since this is
for the USB_1 controller (usbh1), should this be IMX_SC_R_USB_1_PHY instead?
If it requests the USB_0 PHY domain, the USB_1 PHY hardware might remain
unpowered, causing the HSIC port to fail.
> + status = "disabled";
> + };
> +};
> +
> +&conn_subsys {
> + usbh1: usb@5b0e0000 {
> + compatible = "fsl,imx7ulp-usb", "fsl,imx6ul-usb", "fsl,imx27-usb";
> + reg = <0x5b0e0000 0x200>;
[Severity: Medium]
Should this node include a status = "disabled"; property? Without it, the
usbh1 node is enabled by default and will probe unconditionally on all i.MX8QM
boards, even if the hardware interface isn't wired up.
Since the required usbphynop2 PHY is disabled, the controller might fail to
initialize, leading to boot delays and unnecessary resource allocation.
> + interrupt-parent = <&gic>;
> + interrupts = <GIC_SPI 268 IRQ_TYPE_LEVEL_HIGH>;
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260720-qm_smmu-v1-0-3689fbd8b516@nxp.com?part=2
^ permalink raw reply
* Re: [PATCH] Documentation/devicetree/bindings: update Sudeep Holla's email address
From: Rob Herring (Arm) @ 2026-07-20 21:20 UTC (permalink / raw)
To: Laszlo Ersek
Cc: Lorenzo Pieralisi, Sudeep Holla, Krzysztof Kozlowski, arm-scmi,
Conor Dooley, linux-arm-kernel, devicetree, Jassi Brar,
Linus Walleij, Cristian Marussi, Liviu Dudau, linux-kernel
In-Reply-To: <20260720160235.36592-1-laszlo.ersek@arm.com>
On Mon, 20 Jul 2026 18:02:30 +0200, Laszlo Ersek wrote:
> MAINTAINERS disagrees with Documentation/devicetree/bindings on Sudeep's
> email address; fix the latter.
>
> Cc: Conor Dooley <conor+dt@kernel.org>
> Cc: Cristian Marussi <cristian.marussi@arm.com>
> Cc: Jassi Brar <jassisinghbrar@gmail.com>
> Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
> Cc: Linus Walleij <linusw@kernel.org>
> Cc: Liviu Dudau <liviu.dudau@arm.com>
> Cc: Lorenzo Pieralisi <lpieralisi@kernel.org>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Sudeep Holla <sudeep.holla@kernel.org>
> Cc: arm-scmi@vger.kernel.org
> Cc: devicetree@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Fixes: 59e82a4237cf ("MAINTAINERS: Change Sudeep Holla's email address")
> Signed-off-by: Laszlo Ersek <laszlo.ersek@arm.com>
> ---
> Documentation/devicetree/bindings/arm/arm,juno-fpga-apb-regs.yaml | 2 +-
> Documentation/devicetree/bindings/arm/arm,vexpress-juno.yaml | 2 +-
> Documentation/devicetree/bindings/arm/arm,vexpress-scc.yaml | 2 +-
> Documentation/devicetree/bindings/dvfs/performance-domain.yaml | 2 +-
> Documentation/devicetree/bindings/firmware/arm,scmi.yaml | 2 +-
> Documentation/devicetree/bindings/firmware/arm,scpi.yaml | 2 +-
> Documentation/devicetree/bindings/mailbox/arm,mhuv3.yaml | 2 +-
> 7 files changed, 7 insertions(+), 7 deletions(-)
>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH V18 0/9] Add Invensense ICM42607
From: Chris Morgan @ 2026-07-20 21:17 UTC (permalink / raw)
To: Chris Morgan
Cc: linux-iio, andy, nuno.sa, dlechner, jic23, jean-baptiste.maneyrol,
linux-rockchip, devicetree, heiko, conor+dt, krzk+dt, robh,
andriy.shevchenko
In-Reply-To: <20260720202343.70138-1-macroalpha82@gmail.com>
On Mon, Jul 20, 2026 at 03:23:32PM -0500, Chris Morgan wrote:
> From: Chris Morgan <macromorgan@hotmail.com>
>
> Add support for the ICM42607 IMU. This sensor shares the same
> functionality but a different register layout with the existing
> ICM42600.
>
> This driver should work with the ICM42607 and ICM42607P over both I2C
> and SPI, however only the ICM42607P over I2C could be tested.
>
> Changes Since V1:
> - Instead of creating a new driver, merged with the existing inv_icm42600
> driver. This necessitated adding some code to the existing driver to
> permit using a different register layout for the same functionality.
> - Split changes up a bit more to decrease the size of the individual
> patches. Note that patch 0004 is still pretty hefty; if I need to split
> further I may need to create some temporary stub functions.
> - Used guard() and PM_RUNTIME_ACQUIRE_AUTOSUSPEND() on the new functions
> per Jonathan's recommendations.
>
> Changes Since V2:
> - Went back to using a new driver on advice from Invensense engineer.
> - Further split changes up into smaller chunks of functionality. Note
> still that the largest patch is approximately 900 lines, and that while
> the driver compiles cleanly at each commit it is not able to drive the
> hardware until the commit that adds the Interrupt (as it also adds the
> Makefile).
> - Change the error to a warning when the devicetree binding does not match
> the hardware ID.
> - Dropped the ack on the devicetree bindings, as I am creating a new file
> (for a new driver) instead of modifying the existing one.
>
> Changes Since V3:
> - Numerous small fixes (too many to list here). Thank you to everyone who
> provided feedback.
> - Split power management additions into an additional commit to break
> things up further.
> - Consolidated devicetree documentation in existing
> invensense,icm42600.yaml file.
> - Removed most of the FIELD_PREP from header file to c files to make code
> easier to read.
> - Changed scale values to 2D arrays for Gyro and Accelerometer.
> - Removed IIO_CHAN_INFO_CALIBBIAS attribute.
>
> Changes Since V4:
> - Additional numerous small fixes, thank you again for all the feedback.
> - Dropped power control API and instead run device in low noise mode.
> - Split devicetree bindings into two distinct changes.
> - Reordered adding of enums and structs to main header file so that they
> are only brought in when needed.
> - Stopped using enum for driver data and instead am using pointer to
> device specific driver data.
>
> Changes Since V5:
> - Corrected use of "dev_warn_probe" to just "dev_warn".
> - Fixed some return scenarios which would unconditionally return 0
> when an error was present.
> - Corrected use of max() to min() for bounds checking. max() was
> incorrect.
> - Fixed using "st->conf.accel.odr" in the gyroscope function. It
> should have been "st->conf.gyro.odr" which it now is.
> - Additional small fixes suggested by "sashiko.dev".
> - Added a regmap cache. I used the datasheet to try and determine
> which registers might change without explicit writes.
>
> Changes Since V6:
> - Corrected additional errors identified by sashiko.dev, mostly
> fixing potential deadlocks, missing calls for pm runtime, and
> potential overflow issues.
>
> Changes Since V7:
> - Dropped Wake on Movement patches, since some of the functionality
> was only available for a device on which I cannot test.
> - Dropped support for SPI 3-Wire mode, since it complicated the
> bus setup (and I lack the hardware to test such features anyway).
> - Fixed a few additional bugs identified by sashiko.dev bot.
>
> Changes Since V8:
> - Added back IRQ dropped accidentally when dropping wake on movement
> patches.
> - Dropped "Reviewed-By" tag on patch 2 because of substantial changes
> made to devicetree binding documentation.
> - Additional small fixes as suggested.
>
> Changes Since V9:
> - Removed interrupts (and buffers) from the driver. I previously was
> unable to detect deadlocks because it turns out my IRQ was not even
> wired correctly in my device.
> - Updated devicetree binding commits to make interrupts optional for
> users of the icm42607 driver.
>
> Changes Since V10:
> - Explicitly specified enum values in header file.
> - Removed additional dead code for buffer handling.
> - Cleaned up headers.
> - Added additional locks as requested by sashiko.dev bot.
>
> Changes Since V11:
> - Since driver has shrunk in size considerably, moved i2c bits into
> first code commit. This ensures that the very first commit with code
> can now be compiled. The commit after that adds SPI support as it
> was in the previous versions.
> - Used pahole to optimize inv_icm42607_state. Reordering elements
> reduced size in memory from 384 bytes to 256 bytes.
> - Added a map of all readable registers and all writeable registers
> according to the datasheet.
> - Added back some missing headers pointed out by the maintainers.
> - Added FIELD_PREP in a few more places to make the code more
> obvious on what it's doing.
> - Added a comment to the power management code to note that
> temperature sensor being enabled doesn't matter as the clocks
> are off by default when the gyro and accel channels are off.
> - Removed iio_device_claim_direct() calls since it was no longer
> needed.
> - Fixed shared_by_all attributes for temperature sensor.
> - Additional miscellanous fixes as requested.
>
> Changes Since V12:
> - Removed aligned buffer from inv_icm42607_state struct as we do not
> currently have the need for it.
> - Corrected the order of the odr values in the accel and gyro files
> as the values were out of order (the place in the array corresponds
> to the register value).
> - Stopped setting the clock value depending upon the temp config. The
> datasheet advised to keep using the default value.
> - Corrected logic when changing between states. We only need to pause
> when a sensor changes from off to an on state or when the gyro
> changes from an on state to off.
> - Added missing includes for several files.
>
> Changes Since V13:
> - Refactored inv_icm42607_set_accel_conf() and
> inv_icm42607_set_gyro_conf() into a single function.
> - Refactored inv_icm42607_accel_read_sensor() and
> inv_icm42607_gyro_read_sensor() into a single function.
> - Merged inv_icm42607_set_temp_conf() into initial init function
> since it only really needs to be called once.
> - Saved adding temp sensor for last and updated
> inv_icm42607_temp_read() to either confirm other sensors are already
> enabled or enable the accelerometer so it can get a reading.
> - Updated inv_icm42607_set_pwr_mgmt0() so that it does not update the
> sensor mode and forcibly keep the sensor enabled.
> - Added inv_icm42607_temp_filter_bw enums since it appears to use
> different values than the accel or gyro sensor.
> - Set the temp startup time from 77ms to 77us, as I previously misread
> the datasheet.
> - Additional minor fixes.
>
> Changes Since V14:
> - Added IIO_BE for temp sensor.
> - Switched from ktime_get_real() to ktime_get().
>
> Changes Since V15:
> - Removed interrupts from required property per note from Jonathan.
> As a result of this change I've also removed one of Krzysztof's
> Reviewed-By tags as this change probably requires further review
> from them.
> - Corrected a comment about reserved values from 0-5 to 0-4.
> - Reordered some operations so that only runtime power management
> turns off the sensors now. This removes the "ping-pong" effect
> when switching between the accel and gyro sensor, at the expense
> of leaving either the accel or gyro sensor enabled until runtime
> power management turns it off.
> - Fixed the shared frequency value not being available for the temp
> sensor.
>
> Changes Since V16:
> - Reverted devicetree changes back to removing interrupts only for
> icm42607. Added back "Reviewed-By" tag, hope that's okay since it's
> what was initally agreed upon.
> - Removed PM runtime resume code, as there is currently no need to
> resume; instead the raw read/write calls will enable sensors as
> needed. This also allows us to remove storing the sensor state
> prior to runtime suspend and instead we just use runtime suspend
> to disable sensors while not being used.
> - Additional formatting and minor fixes.
>
> Changes Since V17:
> - Added remove routine to ensure device is properly powered down when
> driver removed.
> - Corrected issue with reading scale and offset values for temp
> sensor.
> - Set regcache as dirty and re-sync when resuming from suspend.
> - Added back driver data to of_device_id table for I2C driver. While
> Uwe told me to remove this in a prior commit Jonathan requested it
> back and it is consistent with other drivers to be there.
> - Removed linux/mod_devicetable.h header for SPI driver.
>
> Chris Morgan (9):
> dt-bindings: iio: imu: icm42600: Add mount-matrix
> dt-bindings: iio: imu: icm42600: Add icm42607
> iio: imu: inv_icm42607: Add inv_icm42607 Core Driver
> iio: imu: inv_icm42607: Add SPI For icm42607
> iio: imu: inv_icm42607: Add PM support for icm42607
> iio: imu: inv_icm42607: Add Accelerometer for icm42607
> iio: imu: inv_icm42607: Add Gyroscope to icm42607
> iio: imu: inv_icm42607: Add Temp Support in icm42607
> arm64: dts: rockchip: Add icm42607p IMU for RG-DS
>
> .../bindings/iio/imu/invensense,icm42600.yaml | 20 +-
> .../dts/rockchip/rk3568-anbernic-rg-ds.dts | 8 +-
> drivers/iio/imu/Kconfig | 1 +
> drivers/iio/imu/Makefile | 1 +
> drivers/iio/imu/inv_icm42607/Kconfig | 30 +
> drivers/iio/imu/inv_icm42607/Makefile | 13 +
> drivers/iio/imu/inv_icm42607/inv_icm42607.h | 421 ++++++++++++
> .../iio/imu/inv_icm42607/inv_icm42607_accel.c | 312 +++++++++
> .../iio/imu/inv_icm42607/inv_icm42607_core.c | 641 ++++++++++++++++++
> .../iio/imu/inv_icm42607/inv_icm42607_gyro.c | 309 +++++++++
> .../iio/imu/inv_icm42607/inv_icm42607_i2c.c | 104 +++
> .../iio/imu/inv_icm42607/inv_icm42607_spi.c | 114 ++++
> .../iio/imu/inv_icm42607/inv_icm42607_temp.c | 98 +++
> .../iio/imu/inv_icm42607/inv_icm42607_temp.h | 38 ++
> 14 files changed, 2108 insertions(+), 2 deletions(-)
> create mode 100644 drivers/iio/imu/inv_icm42607/Kconfig
> create mode 100644 drivers/iio/imu/inv_icm42607/Makefile
> create mode 100644 drivers/iio/imu/inv_icm42607/inv_icm42607.h
> create mode 100644 drivers/iio/imu/inv_icm42607/inv_icm42607_accel.c
> create mode 100644 drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
> create mode 100644 drivers/iio/imu/inv_icm42607/inv_icm42607_gyro.c
> create mode 100644 drivers/iio/imu/inv_icm42607/inv_icm42607_i2c.c
> create mode 100644 drivers/iio/imu/inv_icm42607/inv_icm42607_spi.c
> create mode 100644 drivers/iio/imu/inv_icm42607/inv_icm42607_temp.c
> create mode 100644 drivers/iio/imu/inv_icm42607/inv_icm42607_temp.h
>
> --
> 2.43.0
>
Still getting a Sashiko error on the PM stuff. I honestly don't know
at this point how to fix it. Is there a way to find out if the device
is already PM suspended so I can skip that part? Can I just export
the inv_icm42607_set_pwr_mgmt0() function and then use it to shut stuff
off instead of calling pm_runtime_force_suspend()?
I don't think the IIO_CHAN_INFO_SAMP_FREQ is a serious showstopper at
this point, worst case I think telling the read_raw() functions to
return to inv_icm42607_temp_read_raw() if the type is IIO_TEMP
and the mask is not IIO_CHAN_INFO_SAMP_FREQ is sufficient.
Let me know what you think on the PM stuff. Slowly losing my sanity :-p
Chris
^ permalink raw reply
* Re: [PATCH v2 1/1] regulator: dt-bindings: Convert ltc3589.txt to yaml format
From: Rob Herring (Arm) @ 2026-07-20 21:13 UTC (permalink / raw)
To: Frank.Li
Cc: Krzysztof Kozlowski, devicetree, Conor Dooley, imx, Mark Brown,
Frank Li, Frank Li, Liam Girdwood, linux-kernel
In-Reply-To: <20260714160147.1641379-1-Frank.Li@oss.nxp.com>
On Tue, 14 Jul 2026 12:01:45 -0400, Frank.Li@oss.nxp.com wrote:
> From: Frank Li <Frank.Li@nxp.com>
>
> Convert ltc3589.txt to yaml format.
>
> Additional changes:
> - Add interrupts to match driver code
> - Require lltc,fb-voltage-divider property ^(sw1|sw2|sw3|bb-out|ldo1|ldo2)$
>
> Signed-off-by: Frank Li <Frank.Li@nxp.com>
> ---
> change in v2
> - Add interrupts to match driver code (report by sashiko)
> - Require lltc,fb-voltage-divider property ^(sw1|sw2|sw3|bb-out|ldo1|ldo2)$
> (report by sashiko)
> ---
> .../bindings/regulator/lltc,ltc3589.yaml | 149 ++++++++++++++++++
> .../devicetree/bindings/regulator/ltc3589.txt | 99 ------------
> 2 files changed, 149 insertions(+), 99 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/regulator/lltc,ltc3589.yaml
> delete mode 100644 Documentation/devicetree/bindings/regulator/ltc3589.txt
>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v3] dt-bindings: dma: ti,dma-crossbar: Convert to DT schema
From: Rob Herring (Arm) @ 2026-07-20 21:12 UTC (permalink / raw)
To: Bhargav Joshi
Cc: Conor Dooley, daniel.baluta, Peter Ujfalusi, simona.toaca,
Frank Li, goledhruva, Vignesh Raghavendra, Vinod Koul,
Krzysztof Kozlowski, devicetree, m-chawdhry, linux-kernel,
dmaengine
In-Reply-To: <20260713-ti-dma-crossbar-v3-1-734509b316c1@gmail.com>
On Mon, 13 Jul 2026 18:07:30 +0530, Bhargav Joshi wrote:
> Convert Texas Instruments DMA Crossbar from text to DT schema.
> Modify MAINTAINERS file to correctly point to new yaml file.
>
> Signed-off-by: Bhargav Joshi <j.bhargav.u@gmail.com>
> ---
> Changes in v3:
> - Add else block to validate dma-cells property better
> - Link to v2: https://lore.kernel.org/r/20260708-ti-dma-crossbar-v2-1-2ac0d6efde36@gmail.com
>
> Changes in v2:
> - Removed the unmatched `ti,omap4430-sdma` compatible string from the
> example block and trim down example
> - Restored dropped documentation regarding client dma-cells
> configuration into the top-level description block.
> - Updated the MAINTAINERS file to replace the old .txt reference with
> the new .yaml file path.
> - Added constraints on its inner tuple dimensions of
> ti,reserved-dma-request-ranges
> - Link to v1: https://lore.kernel.org/r/20260708-ti-dma-crossbar-v1-1-f62796428f13@gmail.com
> ---
> .../bindings/dma/ti,dra7-dma-crossbar.yaml | 94 ++++++++++++++++++++++
> .../devicetree/bindings/dma/ti-dma-crossbar.txt | 68 ----------------
> MAINTAINERS | 2 +-
> 3 files changed, 95 insertions(+), 69 deletions(-)
>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* [PATCH 2/2] arm64: dts: imx8qm-ss-conn: Add HSIC usb@5b0e0000 node
From: Frank.Li @ 2026-07-20 21:10 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, Xu Yang,
Frank Li
In-Reply-To: <20260720-qm_smmu-v1-0-3689fbd8b516@nxp.com>
From: Frank Li <Frank.Li@nxp.com>
Add usb@5b0e0000 and related node for i.MX8QM.
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
arch/arm64/boot/dts/freescale/imx8qm-ss-conn.dtsi | 34 +++++++++++++++++++++++
1 file changed, 34 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8qm-ss-conn.dtsi b/arch/arm64/boot/dts/freescale/imx8qm-ss-conn.dtsi
index 1370a571153a5..c7063aaac4a34 100644
--- a/arch/arm64/boot/dts/freescale/imx8qm-ss-conn.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8qm-ss-conn.dtsi
@@ -4,6 +4,40 @@
* Dong Aisheng <aisheng.dong@nxp.com>
*/
+&{/} {
+ usbphynop2: usbphynop2 {
+ compatible = "usb-nop-xceiv";
+ clocks = <&usb2_lpcg IMX_LPCG_CLK_7>;
+ clock-names = "main_clk";
+ power-domains = <&pd IMX_SC_R_USB_0_PHY>;
+ status = "disabled";
+ };
+};
+
+&conn_subsys {
+ usbh1: usb@5b0e0000 {
+ compatible = "fsl,imx7ulp-usb", "fsl,imx6ul-usb", "fsl,imx27-usb";
+ reg = <0x5b0e0000 0x200>;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 268 IRQ_TYPE_LEVEL_HIGH>;
+ phy_type = "hsic";
+ dr_mode = "host";
+ clocks = <&usb2_lpcg IMX_LPCG_CLK_6>;
+ ahb-burst-config = <0x0>;
+ tx-burst-size-dword = <0x10>;
+ rx-burst-size-dword = <0x10>;
+ power-domains = <&pd IMX_SC_R_USB_1>;
+ fsl,usbphy = <&usbphynop2>;
+ fsl,usbmisc = <&usbmisc2 0>;
+ };
+
+ usbmisc2: usbmisc@5b0e0200 {
+ compatible = "fsl,imx7ulp-usbmisc", "fsl,imx7d-usbmisc", "fsl,imx6q-usbmisc";
+ #index-cells = <1>;
+ reg = <0x5b0e0200 0x200>;
+ };
+};
+
&usbphy1 {
compatible = "fsl,imx8qm-usbphy", "fsl,imx7ulp-usbphy";
};
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] dt-bindings: pinctrl: ti,dra7-iodelay: Convert to DT schema
From: Rob Herring @ 2026-07-20 21:10 UTC (permalink / raw)
To: sashiko-reviews; +Cc: Bhargav Joshi, devicetree, conor+dt
In-Reply-To: <20260713125721.2E22D1F00A3A@smtp.kernel.org>
On Mon, Jul 13, 2026 at 12:57:20PM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [Medium] The child node regex `^mmc.*_conf$` arbitrarily restricts I/O delay configuration nodes to those starting with 'mmc', even though the controller is generic.
> - [Medium] The `pinctrl-pin-array` property is not marked as required within the child node schema.
Looks to me like these should be addressed.
> --
>
> --- Patch [1]: [PATCH] dt-bindings: pinctrl: ti,dra7-iodelay: Convert to DT schema ---
> commit 59d5959fa2ce86d89ce637daf5f846ce2bedcb0d
> Author: Bhargav Joshi <j.bhargav.u@gmail.com>
>
> dt-bindings: pinctrl: ti,dra7-iodelay: Convert to DT schema
>
> This commit converts the TI IODELAY controller bindings from plain text
> to DT schema. It also adds documentation for child properties missing
> from the original text bindings.
>
> > diff --git a/Documentation/devicetree/bindings/pinctrl/ti,dra7-iodelay.yaml b/Documentation/devicetree/bindings/pinctrl/ti,dra7-iodelay.yaml
> > new file mode 100644
> > index 0000000000000..a399946ae8172
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/pinctrl/ti,dra7-iodelay.yaml
>
> [ ... ]
>
> > +patternProperties:
> > + ^mmc.*_conf$:
>
> [Severity: Medium]
> Looking at the patternProperties definition, does this regression arbitrarily
> restrict delay configuration nodes to only those starting with mmc?
>
> The commit message mentions that mmc pins are just an example of pins
> needing dynamic configuration. If a device tree dynamically configures delay
> for other pins, will this reject them as invalid?
>
> Would it be better to use a more generic pattern?
>
> > + type: object
> > + additionalProperties: false
> > + properties:
> > + pinctrl-pin-array:
> > + $ref: /schemas/types.yaml#/definitions/uint32-array
> > + description: |
> > + An array of 32-bit integers defining the pin delay configuration.
>
> [Severity: Medium]
> Could this regression allow incomplete configuration nodes to pass schema
> validation?
>
> Since pinctrl-pin-array is not marked as required, an empty child node would
> pass dt_binding_check, but the driver expects this property to be present
> to initialize the mapping. Should it be added to a required list within the
> patternProperties block?
>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20260713-ti-iodelay-v1-1-5f06d36c4aac@gmail.com?part=1
>
^ permalink raw reply
* [PATCH 1/2] arm64: dts: imx8qm-ss-conn: add usbotg3 iommu information
From: Frank.Li @ 2026-07-20 21:10 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, Xu Yang,
Frank Li
In-Reply-To: <20260720-qm_smmu-v1-0-3689fbd8b516@nxp.com>
From: Frank Li <Frank.Li@nxp.com>
Add usbotg3 iommu information.
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
arch/arm64/boot/dts/freescale/imx8qm-ss-conn.dtsi | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8qm-ss-conn.dtsi b/arch/arm64/boot/dts/freescale/imx8qm-ss-conn.dtsi
index ccf9f510e0f88..1370a571153a5 100644
--- a/arch/arm64/boot/dts/freescale/imx8qm-ss-conn.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8qm-ss-conn.dtsi
@@ -32,3 +32,7 @@ &usdhc3 {
compatible = "fsl,imx8qm-usdhc", "fsl,imx8qxp-usdhc", "fsl,imx7d-usdhc";
iommus = <&smmu 0x11 0x7f80>;
};
+
+&usbotg3_cdns3 {
+ iommus = <&smmu 0x4 0x7f80>;
+};
--
2.43.0
^ permalink raw reply related
* [PATCH 0/2] arm64: dts: imx8qm: add smmu information for usb and add hsic usb port
From: Frank.Li @ 2026-07-20 21:10 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, Xu Yang,
Frank Li
Add smmu information for usb and add hsic usb port.
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
Frank Li (2):
arm64: dts: imx8qm-ss-conn: add usbotg3 iommu information
arm64: dts: imx8qm-ss-conn: Add HSIC usb@5b0e0000 node
arch/arm64/boot/dts/freescale/imx8qm-ss-conn.dtsi | 38 +++++++++++++++++++++++
1 file changed, 38 insertions(+)
---
base-commit: 3fe08b9796f36ef437ab9328e7dd1e5ff2d66603
change-id: 20260720-qm_smmu-417e915cb713
Best regards,
--
Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* Re: [PATCH] ASoC: dt-bindings: ti,omap4-dmic: Convert to DT schema
From: Rob Herring (Arm) @ 2026-07-20 21:07 UTC (permalink / raw)
To: Bhargav Joshi
Cc: Conor Dooley, m-chawdhry, Peter Ujfalusi, Liam Girdwood,
linux-sound, goledhruva, daniel.baluta, simona.toaca, Mark Brown,
linux-kernel, devicetree, Krzysztof Kozlowski
In-Reply-To: <20260713-ti-omap4-dmic-v1-1-3cc6e13decec@gmail.com>
On Mon, 13 Jul 2026 18:17:11 +0530, Bhargav Joshi wrote:
> Convert the TI OMAP4+ dmic bindings from txt to DT schema.
>
> Following changes are introduced during converson:
> - Drop ti,hwmods property as it is not needed since the sysc
> conversion no existing DTS uses it.
> - Add dma, dma-names, reg-names properties to match the DTS.
> - Update example node to match existing DTS.
>
> Signed-off-by: Bhargav Joshi <j.bhargav.u@gmail.com>
> ---
> .../devicetree/bindings/sound/omap-dmic.txt | 20 --------
> .../devicetree/bindings/sound/ti,omap4-dmic.yaml | 58 ++++++++++++++++++++++
> 2 files changed, 58 insertions(+), 20 deletions(-)
>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: soc: qcom,wcnss: Drop redundant $ref of firmware-name property
From: Rob Herring (Arm) @ 2026-07-20 21:05 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Andy Gross, Conor Dooley, Konrad Dybcio, devicetree,
Bjorn Andersson, linux-arm-msm, linux-kernel, Krzysztof Kozlowski
In-Reply-To: <20260712162212.184592-2-krzysztof.kozlowski@oss.qualcomm.com>
On Sun, 12 Jul 2026 18:22:13 +0200, Krzysztof Kozlowski wrote:
> The DT schema core defines the type ($ref) of 'firmware-name' property
> as string-array, so individual schemas do not need to. They also should
> not redefine it to a single string, but instead just set number of
> expected firmware names.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>
> ---
>
> Changes in v2:
> 1. Switch default to an array
> ---
> Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.yaml | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v3 2/3] clk: qcom: gcc-glymur: Enable runtime PM
From: Dmitry Baryshkov @ 2026-07-20 21:01 UTC (permalink / raw)
To: Abel Vesa
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Taniya Das, Konrad Dybcio,
Maulik Shah, Jyothi Kumar Seerapu, Konrad Dybcio, Brian Masney,
Krzysztof Kozlowski, Sibi Sankar, Pankaj Patil, Akhil P Oommen,
linux-arm-msm, linux-clk, devicetree, linux-kernel,
Jishnu Prakash, Raviteja Laggyshetty, Kamal Wadhwa, Qiang Yu,
Manaf Meethalavalappu Pallikunhi, Abel Vesa
In-Reply-To: <20260715-glymur-fix-gcc-cx-scaling-v3-2-72eb5adad156@oss.qualcomm.com>
On Wed, Jul 15, 2026 at 04:29:15PM +0300, Abel Vesa wrote:
> Enable runtime PM for the controller so the common GCC probe path resumes
> the attached domain while registering clocks, resets and GDSCs.
>
> This lets GDSC consumers propagate their votes through the GCC provider to
> the CX parent domain.
>
> Fixes: efe504300a17 ("clk: qcom: gcc: Add support for Global Clock Controller")
> Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
> ---
> drivers/clk/qcom/gcc-glymur.c | 1 +
> 1 file changed, 1 insertion(+)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v3 2/3] pmdomain: mediatek: Add support for secure modem power domain control
From: sashiko-bot @ 2026-07-20 20:58 UTC (permalink / raw)
To: Nikolai Burov; +Cc: conor+dt, robh, devicetree
In-Reply-To: <20260720-mt6858-pmdomain-v3-2-8966d8de93c8@jolla.com>
Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
New issues:
- [High] Hardware sequence inversion for secure modem teardown
- [Medium] Unwarranted 1-second busy sleep loop on SMC hard errors
Pre-existing issues:
- [High] Missing power-off rollback in hardware bring-up error paths
- [High] Bus protection resource leak on early power-off failure
--
--- Patch [2]: [PATCH v3 2/3] pmdomain: mediatek: Add support for secure modem power domain control ---
commit a98929d49f9662dbe82719e18f3bfc5621c41558
Author: Nikolai Burov <nikolai.burov@jolla.com>
pmdomain: mediatek: Add support for secure modem power domain control
On recent MediaTek SoCs such as MT6858, the kernel is required to use
a secure monitor call (SMC) to enable or disable the modem power domain.
This patch adds a flag to enable this new power sequence.
> diff --git a/drivers/pmdomain/mediatek/mtk-pm-domains.c b/drivers/pmdomain/mediatek/mtk-pm-domains.c
> index 8309a4b46afb0..5b4d860318a46 100644
> --- a/drivers/pmdomain/mediatek/mtk-pm-domains.c
> +++ b/drivers/pmdomain/mediatek/mtk-pm-domains.c
[ ... ]
> @@ -668,6 +672,34 @@ static int scpsys_modem_pwrseq_off(struct scpsys_domain *pd)
> return 0;
> }
>
> +static bool scpsys_modem_sec_poll(unsigned long cmd)
> +{
> + struct arm_smccc_res res;
> +
> + arm_smccc_smc(MTK_SIP_KERNEL_CCCI_CONTROL, cmd, 1, 0, 0, 0, 0, 0, &res);
> +
> + return res.a0 == 0;
> +}
> +
> +static int scpsys_modem_sec_power_on(bool on)
> +{
> + struct arm_smccc_res res;
> + unsigned long cmd = on ? MTK_MD_MTCMOS_ENABLE : MTK_MD_MTCMOS_DISABLE;
> + bool tmp;
> + int ret;
> +
> + arm_smccc_smc(MTK_SIP_KERNEL_CCCI_CONTROL, cmd, 0, 0, 0, 0, 0, 0, &res);
> + if (res.a0 == 0)
> + return 0;
> +
> + ret = readx_poll_timeout(scpsys_modem_sec_poll, cmd, tmp, tmp,
> + MTK_POLL_DELAY_US, MTK_POLL_TIMEOUT);
[Severity: Medium]
Does this code assume any non-zero res.a0 indicates an 'in-progress'
operation? If the SMC call returns a negative error code (like
SMCCC_RET_NOT_SUPPORTED), will it dive into a 1-second busy sleep loop instead
of failing immediately?
> + if (ret < 0)
> + return ret;
> +
> + return 0;
> +}
[ ... ]
> @@ -739,7 +774,8 @@ static int scpsys_power_on(struct generic_pm_domain *genpd)
> err_enable_bus_protect:
> scpsys_bus_protect_enable(pd, 0);
> err_disable_sram:
> - if (!MTK_SCPD_CAPS(pd, MTK_SCPD_SIMPLE_PWRSEQ))
> + if (!MTK_SCPD_CAPS(pd, MTK_SCPD_SIMPLE_PWRSEQ) &&
> + !MTK_SCPD_CAPS(pd, MTK_SCPD_MODEM_SECURE_PWRSEQ))
> scpsys_sram_disable(pd);
> err_disable_subsys_clks:
[Severity: High]
This isn't a bug introduced by this patch, but does this error path block skip
reverting the MTCMOS/SMC power-on state before disabling the regulator?
If a step fails after powering on the MTCMOS domain (for example,
clk_bulk_prepare_enable()), the error paths drop the subsystem clocks and
regulator but fail to explicitly invoke the power-off rollback. Could this
leave the SMC firmware tracking a powered-on domain while physical power is
cut, potentially deadlocking firmware?
> if (!MTK_SCPD_CAPS(pd, MTK_SCPD_STRICT_BUS_PROTECTION))
> @@ -761,7 +797,11 @@ static int scpsys_power_off_internal(struct scpsys_domain *pd)
> if (ret < 0)
> return ret;
>
> - if (!MTK_SCPD_CAPS(pd, MTK_SCPD_SIMPLE_PWRSEQ)) {
> + if (MTK_SCPD_CAPS(pd, MTK_SCPD_MODEM_SECURE_PWRSEQ)) {
> + ret = scpsys_modem_sec_power_on(false);
[Severity: High]
In scpsys_power_on(), the sequence un-isolates the buck, powers on the domain
via SMC, and then enables subsystem clocks. To maintain LIFO symmetry,
shouldn't the teardown sequence disable the clocks and isolate the buck before
cutting MTCMOS power?
Since the SMC power-off call is placed at the very beginning of the function
here, could this cut power while clocks are still actively toggling, causing
hardware bus hangs?
> + if (ret)
> + return ret;
[Severity: High]
This is a pre-existing issue, but does returning an error here leave the bus
protection enabled indefinitely?
If the SMC power-off fails and returns early, the genpd framework treats a
failed power-off as the domain remaining active, but the bus is now
permanently blocked. Does this error path need to revert bus protection to
avoid a system hang when accessing devices within the domain?
> + } else if (!MTK_SCPD_CAPS(pd, MTK_SCPD_SIMPLE_PWRSEQ)) {
> ret = scpsys_sram_disable(pd);
> if (ret < 0)
> return ret;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260720-mt6858-pmdomain-v3-0-8966d8de93c8@jolla.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