Devicetree
 help / color / mirror / Atom feed
* [PATCH v6 0/9] media: add new API simple 1to1 subdev register and add imx parallel camera support
From: Frank.Li @ 2026-06-24 20:37 UTC (permalink / raw)
  To: Sakari Ailus, Mauro Carvalho Chehab, Michael Riesch,
	Laurent Pinchart, Frank Li, Martin Kepplinger-Novakovic,
	Rui Miguel Silva, Purism Kernel Team, Rob Herring,
	Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
	Pengutronix Kernel Team, Fabio Estevam
  Cc: linux-media, linux-kernel, imx, Guoniu Zhou, devicetree,
	linux-arm-kernel, Alice Yuan, Robert Chiras, Zhipeng Wang,
	Krzysztof Kozlowski

Base on patches "media: add and use fwnode_graph_for_each_endpoint_scoped()"
https://lore.kernel.org/imx/20260624200237.GJ851255@killaraus.ideasonboard.com/T/#m7969735b6c236c6b3abc16b9f3f55ec0488dbe89

This patches base on previous' thread "media: imx8qxp: add parallel camera
support".

Add new API media_async_register_subdev_1to1() to simple 1to1 subdev
register.

Many V4L2 subdev drivers implement the same registration and media pads.
Assumes a 1:1 mapping between firmware endpoints and media pads.
During registration it parses the firmware graph, creates media pads for
all endpoints, and registers common asynchronous notifiers for sink
endpoints. These notifiers automatically create media links when the
corresponding remote source devices become available.

The set_pad_by_ep() callback allows drivers to determine the media pad
associated with a firmware endpoint and identify whether the endpoint
represents a sink pad.

By centralizing firmware graph parsing, media pad creation, notifier
registration, and link creation, this helper reduces duplicated code and
simplifies error handling in V4L2 sub-device drivers.

Add media_async_register_subdev(), a helper to register a V4L2 sub-device
with the asynchronous sub-device framework.

This reduces code duplication and simplifies the implementation of
simple bridge and converter drivers.

    In subdev driver:

    your_device_probe()
    {
            v4l2_subdev_init(sd, &dw_mipi_csi2rx_ops);
            ...
            return media_async_register_subdev_1to1(sd);
    }

    ...
    your_device_remove()
    {
            media_async_subdev_cleanup(sd);
    }

This API help reduce over line duplcated code in synopsys/dw-mipi-csi2rx.c.
And use this API at imx8's parallel CPI driver, which over 90% code now
hardware related.

And also benefit on going pix format patch
https://lore.kernel.org/imx/20260525-csi_formatter-v8-0-6b646231224b@oss.nxp.com/

It will also reduce missed media_entity_cleanup() problem at some error path
https://lore.kernel.org/linux-media/20260614202835.11977-15-birenpandya@gmail.com/

Previous do partial simpilfy at
https://lore.kernel.org/imx/aaisdJSsFE5-PLx1@lizhi-Precision-Tower-5810/

To: Sakari Ailus <sakari.ailus@linux.intel.com>
To: Mauro Carvalho Chehab <mchehab@kernel.org>
To: Michael Riesch <michael.riesch@collabora.com>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Frank Li <Frank.Li@nxp.com>
To: Martin Kepplinger-Novakovic <martink@posteo.de>
To: Rui Miguel Silva <rmfrfs@gmail.com>
To: Purism Kernel Team <kernel@puri.sm>
To: Rob Herring <robh@kernel.org>
To: Krzysztof Kozlowski <krzk+dt@kernel.org>
To: Conor Dooley <conor+dt@kernel.org>
To: Sascha Hauer <s.hauer@pengutronix.de>
To: Pengutronix Kernel Team <kernel@pengutronix.de>
To: Fabio Estevam <festevam@gmail.com>
Cc: linux-media@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: imx@lists.linux.dev
Cc: Guoniu Zhou <guoniu.zhou@nxp.com>
Cc: devicetree@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org

Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
Changes in v6:
- Change API to fix more width user case, assume a media pad have one endpoint
on dts.
- other detail change see each patch's change log
- Link to v5: https://patch.msgid.link/20260617-imx8qxp_pcam-v5-0-7fa6c8e7fba7@nxp.com

Changes in v5:
- Add media_async_register_subdev_1to1() to simple code.
- Link to v4: https://lore.kernel.org/r/20250729-imx8qxp_pcam-v4-0-4dfca4ed2f87@nxp.com

Changes in v4:
- remove imx93 driver support since have not camera sensor module to do test now.
  Add it later
- Add new patch
  media: v4l2-common: Add helper function v4l_get_required_align_by_bpp()
- See each patche's change log for detail.
- Link to v3: https://lore.kernel.org/r/20250708-imx8qxp_pcam-v3-0-c8533e405df1@nxp.com

Changes in v3:
- replace CSI with CPI.
- detail change see each patch's change logs
- Link to v2: https://lore.kernel.org/r/20250703-imx8qxp_pcam-v2-0-188be85f06f1@nxp.com

Changes in v2:
- remove patch media: nxp: isi: add support for UYVY8_2X8 and YUYV8_2X8 bus codes
  because pcif controller convert 2x8 to 1x16 to match isi's input
- rename comaptible string to fsl,imx8qxp-pcif
- See each patches's change log for detail
- Link to v1: https://lore.kernel.org/r/20250630-imx8qxp_pcam-v1-0-eccd38d99201@nxp.com

---
Alice Yuan (2):
      dt-bindings: media: add i.MX parallel CPI support
      media: nxp: add V4L2 subdev driver for camera parallel interface (CPI)

Frank Li (7):
      media: mc-entity: Store parsed V4L2 fwnode endpoint in media_pad
      media: subdev: Add set_pad_by_ep() callback to internal ops
      media: subdev: Add media_async_register_subdev() helper
      media: synopsys: Use v4l2_subdev_get_frame_desc_passthrough()
      media: synopsys: Use media_async_register_subdev() to simplify code
      arm64: dts: imx8: add camera parallel interface (CPI) node
      arm64: dts: imx8qxp-mek: add parallel ov5640 camera support

 .../devicetree/bindings/media/fsl,imx93-pcif.yaml  | 126 +++++
 MAINTAINERS                                        |   2 +
 arch/arm64/boot/dts/freescale/Makefile             |   3 +
 arch/arm64/boot/dts/freescale/imx8-ss-img.dtsi     |  13 +
 .../boot/dts/freescale/imx8qxp-mek-ov5640-cpi.dtso |  83 +++
 arch/arm64/boot/dts/freescale/imx8qxp-ss-img.dtsi  |  27 +
 drivers/media/platform/nxp/Kconfig                 |  12 +
 drivers/media/platform/nxp/Makefile                |   1 +
 drivers/media/platform/nxp/imx-parallel-cpi.c      | 629 +++++++++++++++++++++
 drivers/media/platform/synopsys/dw-mipi-csi2rx.c   | 200 ++-----
 drivers/media/v4l2-core/v4l2-fwnode.c              | 155 +++++
 include/media/media-entity.h                       |   5 +-
 include/media/v4l2-async.h                         |  39 ++
 include/media/v4l2-subdev.h                        |   5 +
 14 files changed, 1140 insertions(+), 160 deletions(-)
---
base-commit: c425f8be0326d40823cd93cbca633872d099df2a
change-id: 20250626-imx8qxp_pcam-d851238343c3

Best regards,
--  
Frank Li <Frank.Li@nxp.com>


^ permalink raw reply

* Re: [PATCH v2] ASoC: dt-bindings: Convert cirrus,cs35l36 to DT schema
From: Rhodes, David @ 2026-06-24 20:05 UTC (permalink / raw)
  To: Rob Herring, David Heidelberg
  Cc: David Rhodes, Richard Fitzgerald, Liam Girdwood, Mark Brown,
	Krzysztof Kozlowski, Conor Dooley, patches, Bjorn Helgaas,
	linux-sound, devicetree, linux-kernel, phone-devel
In-Reply-To: <20260624194541.GA672824-robh@kernel.org>

On 6/24/26 2:45 PM, Rob Herring wrote:
> On Wed, Jun 24, 2026 at 08:39:28PM +0200, David Heidelberg wrote:
>> On 24/06/2026 20:17, Rob Herring wrote:
>>> On Wed, Jun 24, 2026 at 11:02 AM David Heidelberg via B4 Relay
>>> <devnull+david.ixit.cz@kernel.org> wrote:
>>>>
>>>> From: David Heidelberg <david@ixit.cz>
>>>>
>>>> Convert CS35L36 Speaker Amplifier to yaml.
>>>>
>>>> Changes:
>>>>    - maintainers email to the generic Cirrus email
>>>>    - Both the codec and downstream worked just fine without
>>>>      VP-supply provided. Align with datasheet for similar models.
>>>>    - add dai-common.yaml to cover for '#sound-dai-cells',
>>>>      'sound-name-prefix'
>>>>
>>>> Reviewed-by: David Rhodes <David.Rhodes@cirrus.com>
>>>
>>> If you are going to take stuff I haven't fixed:
>>>
>>> Assisted-by: OpenAI:gpt-4
>>>
>>> (I don't remember the exact flavor I used)
>>>
>>>> Co-developed-by: Rob Herring (Arm) <robh@kernel.org>
>>>> Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
>>>> Signed-off-by: David Heidelberg <david@ixit.cz>
>>>> ---
>>>> Relevant for Pixel 3 / 3XL / 4.
>>>> ---
>>>> Changes in v2:
>>>> - Rename the commit. (Mark)
>>>> - Link to v1: https://lore.kernel.org/r/20260618-dt-cirrus-cs35l36-v1-1-1a43515666ad@ixit.cz
>>>> ---
>>>>    .../devicetree/bindings/sound/cirrus,cs35l36.yaml  | 224 +++++++++++++++++++++
>>>>    .../devicetree/bindings/sound/cs35l36.txt          | 168 ----------------
>>>>    2 files changed, 224 insertions(+), 168 deletions(-)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/sound/cirrus,cs35l36.yaml b/Documentation/devicetree/bindings/sound/cirrus,cs35l36.yaml
>>>> new file mode 100644
>>>> index 0000000000000..af0acaaefb68e
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/sound/cirrus,cs35l36.yaml
>>>> @@ -0,0 +1,224 @@
>>>> +# SPDX-License-Identifier: GPL-2.0-only
>>>> +%YAML 1.2
>>>> +---
>>>> +$id: http://devicetree.org/schemas/cirrus,cs35l36.yaml#
>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>> +
>>>> +title: Cirrus Logic CS35L36 Speaker Amplifier
>>>> +
>>>> +maintainers:
>>>> +  - patches@opensource.cirrus.com
>>>> +  - Bjorn Helgaas <bhelgaas@google.com>
>>>
>>> Bjorn is not correct. Generally we want a person, not a company list.
>>
>> I'm adding back James, can I keep the patches at 2nd place?
> 
> Yes.

Please put me down and the patches list as well. James will not respond 
at that address any longer.

> 
>>>> +      cirrus,vpbr-thld:
>>>> +        description: Initial VPBR threshold voltage
>>>> +        $ref: /schemas/types.yaml#/definitions/uint32
minimum: 2
maximum: 31

>>>> +
>>>> +      cirrus,vpbr-atk-rate:
>>>> +        description: Attenuation attack step rate
>>>> +        $ref: /schemas/types.yaml#/definitions/uint32
>>>> +
minimum: 0
maximum: 7

>>>> +      cirrus,vpbr-atk-vol:
>>>> +        description: VP brownout prevention step size
>>>> +        $ref: /schemas/types.yaml#/definitions/uint32
>>>> +
minimum: 0
maximum: 7

>>>> +      cirrus,vpbr-max-attn:
>>>> +        description: Maximum attenuation during VP brownout prevention
>>>> +        $ref: /schemas/types.yaml#/definitions/uint32
>>>> +
minimum: 0
maximum: 15
this is just an integer dB value

>>>> +      cirrus,vpbr-wait:
>>>> +        description: Delay between brownout clearance and attenuation release
>>>> +        $ref: /schemas/types.yaml#/definitions/uint32
>>>> +enum:
- 0 # 10ms
- 1 # 100ms (Default)
- 2 # 250ms
- 3 # 500ms

>>>> +      cirrus,vpbr-rel-rate:
>>>> +        description: Attenuation release step rate
>>>> +        $ref: /schemas/types.yaml#/definitions/uint32
>>>> +
minimum: 0
maximum: 7

>>>> +      cirrus,vpbr-mute-en:
>>>> +        description: Mute audio if maximum attenuation reached
>>>> +        $ref: /schemas/types.yaml#/definitions/uint32
>>>
minimum: 0
maximum: 1

>>> Constraints on any of these?
>>
>> Code just applies whatever is thrown at it, maybe David knows more?
>>
>> #nodatasheet (but would be lovely to have one)
> 
> Unless the driver just takes these values and shoves them straight into
> a 32-bit register, the driver should give some clue about the size or
> possible values.
> 
> Rob
> 
Got some constraints for you.

Thanks,
David


^ permalink raw reply

* Re: [PATCH v2] ASoC: dt-bindings: Convert cirrus,cs35l36 to DT schema
From: David Heidelberg @ 2026-06-24 20:04 UTC (permalink / raw)
  To: Rob Herring
  Cc: David Rhodes, Richard Fitzgerald, Liam Girdwood, Mark Brown,
	Krzysztof Kozlowski, Conor Dooley, patches, Bjorn Helgaas,
	linux-sound, devicetree, linux-kernel, phone-devel
In-Reply-To: <20260624194541.GA672824-robh@kernel.org>

On 24/06/2026 21:45, Rob Herring wrote:
> On Wed, Jun 24, 2026 at 08:39:28PM +0200, David Heidelberg wrote:
>> On 24/06/2026 20:17, Rob Herring wrote:
>>> On Wed, Jun 24, 2026 at 11:02 AM David Heidelberg via B4 Relay
>>> <devnull+david.ixit.cz@kernel.org> wrote:
>>>>
>>>> From: David Heidelberg <david@ixit.cz>
>>>>
>>>> Convert CS35L36 Speaker Amplifier to yaml.
>>>>
>>>> Changes:
>>>>    - maintainers email to the generic Cirrus email
>>>>    - Both the codec and downstream worked just fine without
>>>>      VP-supply provided. Align with datasheet for similar models.
>>>>    - add dai-common.yaml to cover for '#sound-dai-cells',
>>>>      'sound-name-prefix'
>>>>
>>>> Reviewed-by: David Rhodes <David.Rhodes@cirrus.com>
>>>
>>> If you are going to take stuff I haven't fixed:
>>>
>>> Assisted-by: OpenAI:gpt-4
>>>
>>> (I don't remember the exact flavor I used)
>>>
>>>> Co-developed-by: Rob Herring (Arm) <robh@kernel.org>
>>>> Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
>>>> Signed-off-by: David Heidelberg <david@ixit.cz>
>>>> ---
>>>> Relevant for Pixel 3 / 3XL / 4.
>>>> ---
>>>> Changes in v2:
>>>> - Rename the commit. (Mark)
>>>> - Link to v1: https://lore.kernel.org/r/20260618-dt-cirrus-cs35l36-v1-1-1a43515666ad@ixit.cz
>>>> ---
>>>>    .../devicetree/bindings/sound/cirrus,cs35l36.yaml  | 224 +++++++++++++++++++++
>>>>    .../devicetree/bindings/sound/cs35l36.txt          | 168 ----------------
>>>>    2 files changed, 224 insertions(+), 168 deletions(-)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/sound/cirrus,cs35l36.yaml b/Documentation/devicetree/bindings/sound/cirrus,cs35l36.yaml
>>>> new file mode 100644
>>>> index 0000000000000..af0acaaefb68e
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/sound/cirrus,cs35l36.yaml
>>>> @@ -0,0 +1,224 @@
>>>> +# SPDX-License-Identifier: GPL-2.0-only
>>>> +%YAML 1.2
>>>> +---
>>>> +$id: http://devicetree.org/schemas/cirrus,cs35l36.yaml#
>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>> +
>>>> +title: Cirrus Logic CS35L36 Speaker Amplifier
>>>> +
>>>> +maintainers:
>>>> +  - patches@opensource.cirrus.com
>>>> +  - Bjorn Helgaas <bhelgaas@google.com>
>>>
>>> Bjorn is not correct. Generally we want a person, not a company list.
>>
>> I'm adding back James, can I keep the patches at 2nd place?
> 
> Yes.
> 
>>>> +      cirrus,vpbr-thld:
>>>> +        description: Initial VPBR threshold voltage
>>>> +        $ref: /schemas/types.yaml#/definitions/uint32
>>>> +
>>>> +      cirrus,vpbr-atk-rate:
>>>> +        description: Attenuation attack step rate
>>>> +        $ref: /schemas/types.yaml#/definitions/uint32
>>>> +
>>>> +      cirrus,vpbr-atk-vol:
>>>> +        description: VP brownout prevention step size
>>>> +        $ref: /schemas/types.yaml#/definitions/uint32
>>>> +
>>>> +      cirrus,vpbr-max-attn:
>>>> +        description: Maximum attenuation during VP brownout prevention
>>>> +        $ref: /schemas/types.yaml#/definitions/uint32
>>>> +
>>>> +      cirrus,vpbr-wait:
>>>> +        description: Delay between brownout clearance and attenuation release
>>>> +        $ref: /schemas/types.yaml#/definitions/uint32
>>>> +
>>>> +      cirrus,vpbr-rel-rate:
>>>> +        description: Attenuation release step rate
>>>> +        $ref: /schemas/types.yaml#/definitions/uint32
>>>> +
>>>> +      cirrus,vpbr-mute-en:
>>>> +        description: Mute audio if maximum attenuation reached
>>>> +        $ref: /schemas/types.yaml#/definitions/uint32
>>>
>>> Constraints on any of these?
>>
>> Code just applies whatever is thrown at it, maybe David knows more?
>>
>> #nodatasheet (but would be lovely to have one)
> 
> Unless the driver just takes these values and shoves them straight into
> a 32-bit register, the driver should give some clue about the size or
> possible values.

Okay, that's me being too lazy. Fair enough, I'll fill the constraints :)

Thanks
David

> 
> Rob

-- 
David Heidelberg


^ permalink raw reply

* Re: [PATCH RFC v4 10/12] reset: zte: Add a zx297520v3 reset driver
From: Stefan Dösinger @ 2026-06-24 20:00 UTC (permalink / raw)
  To: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley, Brian Masney, Philipp Zabel
  Cc: linux-clk, devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <90c4f50eb23dec06497d46f9c0f522a6b90a918b.camel@pengutronix.de>

[-- Attachment #1: Type: text/plain, Size: 1165 bytes --]

Hi Philipp,

Am Donnerstag, 18. Juni 2026, 12:24:26 Ostafrikanische Zeit schrieb Philipp 
Zabel:

> > +	[ZX297520V3_UART0_RESET]     = { .reg = 0x78,  .mask = BIT(6)  | 
BIT(7) 
> > },
> Is this a single reset line controlled by two bits (do you know what
> they are)? Or might these actually be two different reset controls that
> are just always set together?

I suppose I could expose both bits as separate reset controls in the binding. 
The lower bit is usually the one that actually resets the device, while the 
higher one works similarly to PCLK - it disconnects the device from the bus, 
if asserted. Depending on the device it may or may not leave any residual 
effect behind after deassert.

The stumbling block is the dwc2 USB driver. It only takes one reset, so I'd 
have to add another one (or abuse the dwc2-ecc reset) and presumably add a PHY 
driver for the 3rd reset or add a dwc2-phy reset.

The AMBA bus already takes an array of resets, so the pl011 UARTs are fine 
either way. For stmmac I need a glue driver for other reasons anyway. the 
dwc,mmc2 controller on this board seems to have only one reset, so no need to 
extend the driver here.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 870 bytes --]

^ permalink raw reply

* Re: [PATCH v2] ASoC: dt-bindings: Convert cirrus,cs35l36 to DT schema
From: Rob Herring @ 2026-06-24 19:45 UTC (permalink / raw)
  To: David Heidelberg
  Cc: David Rhodes, Richard Fitzgerald, Liam Girdwood, Mark Brown,
	Krzysztof Kozlowski, Conor Dooley, patches, Bjorn Helgaas,
	linux-sound, devicetree, linux-kernel, phone-devel
In-Reply-To: <3873b111-36d5-442e-996c-31d05d23c8e8@ixit.cz>

On Wed, Jun 24, 2026 at 08:39:28PM +0200, David Heidelberg wrote:
> On 24/06/2026 20:17, Rob Herring wrote:
> > On Wed, Jun 24, 2026 at 11:02 AM David Heidelberg via B4 Relay
> > <devnull+david.ixit.cz@kernel.org> wrote:
> > > 
> > > From: David Heidelberg <david@ixit.cz>
> > > 
> > > Convert CS35L36 Speaker Amplifier to yaml.
> > > 
> > > Changes:
> > >   - maintainers email to the generic Cirrus email
> > >   - Both the codec and downstream worked just fine without
> > >     VP-supply provided. Align with datasheet for similar models.
> > >   - add dai-common.yaml to cover for '#sound-dai-cells',
> > >     'sound-name-prefix'
> > > 
> > > Reviewed-by: David Rhodes <David.Rhodes@cirrus.com>
> > 
> > If you are going to take stuff I haven't fixed:
> > 
> > Assisted-by: OpenAI:gpt-4
> > 
> > (I don't remember the exact flavor I used)
> > 
> > > Co-developed-by: Rob Herring (Arm) <robh@kernel.org>
> > > Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
> > > Signed-off-by: David Heidelberg <david@ixit.cz>
> > > ---
> > > Relevant for Pixel 3 / 3XL / 4.
> > > ---
> > > Changes in v2:
> > > - Rename the commit. (Mark)
> > > - Link to v1: https://lore.kernel.org/r/20260618-dt-cirrus-cs35l36-v1-1-1a43515666ad@ixit.cz
> > > ---
> > >   .../devicetree/bindings/sound/cirrus,cs35l36.yaml  | 224 +++++++++++++++++++++
> > >   .../devicetree/bindings/sound/cs35l36.txt          | 168 ----------------
> > >   2 files changed, 224 insertions(+), 168 deletions(-)
> > > 
> > > diff --git a/Documentation/devicetree/bindings/sound/cirrus,cs35l36.yaml b/Documentation/devicetree/bindings/sound/cirrus,cs35l36.yaml
> > > new file mode 100644
> > > index 0000000000000..af0acaaefb68e
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/sound/cirrus,cs35l36.yaml
> > > @@ -0,0 +1,224 @@
> > > +# SPDX-License-Identifier: GPL-2.0-only
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/cirrus,cs35l36.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: Cirrus Logic CS35L36 Speaker Amplifier
> > > +
> > > +maintainers:
> > > +  - patches@opensource.cirrus.com
> > > +  - Bjorn Helgaas <bhelgaas@google.com>
> > 
> > Bjorn is not correct. Generally we want a person, not a company list.
> 
> I'm adding back James, can I keep the patches at 2nd place?

Yes.

> > > +      cirrus,vpbr-thld:
> > > +        description: Initial VPBR threshold voltage
> > > +        $ref: /schemas/types.yaml#/definitions/uint32
> > > +
> > > +      cirrus,vpbr-atk-rate:
> > > +        description: Attenuation attack step rate
> > > +        $ref: /schemas/types.yaml#/definitions/uint32
> > > +
> > > +      cirrus,vpbr-atk-vol:
> > > +        description: VP brownout prevention step size
> > > +        $ref: /schemas/types.yaml#/definitions/uint32
> > > +
> > > +      cirrus,vpbr-max-attn:
> > > +        description: Maximum attenuation during VP brownout prevention
> > > +        $ref: /schemas/types.yaml#/definitions/uint32
> > > +
> > > +      cirrus,vpbr-wait:
> > > +        description: Delay between brownout clearance and attenuation release
> > > +        $ref: /schemas/types.yaml#/definitions/uint32
> > > +
> > > +      cirrus,vpbr-rel-rate:
> > > +        description: Attenuation release step rate
> > > +        $ref: /schemas/types.yaml#/definitions/uint32
> > > +
> > > +      cirrus,vpbr-mute-en:
> > > +        description: Mute audio if maximum attenuation reached
> > > +        $ref: /schemas/types.yaml#/definitions/uint32
> > 
> > Constraints on any of these?
> 
> Code just applies whatever is thrown at it, maybe David knows more?
> 
> #nodatasheet (but would be lovely to have one)

Unless the driver just takes these values and shoves them straight into 
a 32-bit register, the driver should give some clue about the size or 
possible values.

Rob

^ permalink raw reply

* [PATCH v2 0/2] rockchip: Fix devices suspend freeze on RK3568/RK3566
From: Jonas Karlman @ 2026-06-24 19:27 UTC (permalink / raw)
  To: Heiko Stuebner, Rob Herring, Krzysztof Kozlowski, Conor Dooley
  Cc: Diederik de Haas, Greg Kroah-Hartman, devicetree, linux-rockchip,
	linux-usb, linux-arm-kernel, linux-kernel, Jonas Karlman

This series fixes a system freeze during suspend in ohci_suspend() due
to clk_usbphy1_480m not being enabled when EHCI/OHCI registers are
accessed on e.g. a Raxa ROCK 3C board.

Following pm_test modes work on my ROCK 3C with the missing usbphy clk
refs added:

  echo N > /sys/module/printk/parameters/console_suspend

  echo devices > /sys/power/pm_test
  echo platform > /sys/power/pm_test
  echo processors > /sys/power/pm_test
  echo core > /sys/power/pm_test

  echo mem > /sys/power/state

Changes in v2:
- Include rockchip,rk3588-ehci in the EHCI constraint
- Make clocks prop required for EHCI and OHCI
- Collect t-b tag

Jonas Karlman (2):
  dt-bindings: usb: Add Rockchip RK3568 compatible for EHCI and OHCI
  arm64: dts: rockchip: Fix devices suspend freeze on RK3568/RK3566

 .../devicetree/bindings/usb/generic-ehci.yaml    | 14 ++++++++++++++
 .../devicetree/bindings/usb/generic-ohci.yaml    |  7 ++++++-
 arch/arm64/boot/dts/rockchip/rk356x-base.dtsi    | 16 ++++++++--------
 3 files changed, 28 insertions(+), 9 deletions(-)

-- 
2.54.0


^ permalink raw reply

* [PATCH v2 1/2] dt-bindings: usb: Add Rockchip RK3568 compatible for EHCI and OHCI
From: Jonas Karlman @ 2026-06-24 19:27 UTC (permalink / raw)
  To: Heiko Stuebner, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
	Greg Kroah-Hartman
  Cc: Diederik de Haas, devicetree, linux-rockchip, linux-usb,
	linux-arm-kernel, linux-kernel, Jonas Karlman
In-Reply-To: <20260624192726.781864-1-jonas@kwiboo.se>

The Rockchip RK3568 EHCI/OHCI controller depends on clk_usbphy1_480m
being enabled, or the system may freeze when registers are accessed.

Add Rockchip RK3568 EHCI and OHCI compatibles with a similar four-clock
constraint as RK3588, also extend the EHCI constraint to include RK3588
to match similar requirements of RK3588.

Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
---
Existing DTs for RK3568 use the plain generic-ehci/ohci compatible,
next patch make use of these new compatibles and adds the missing
clk_usbphy1_480m clock references.

Existing DTs for RK3588 have contained the required four clocks since
the initial addition of the EHCI/OHCI nodes.

Changes in v2:
- Include rockchip,rk3588-ehci in the EHCI constraint
- Make clocks prop required for EHCI and OHCI
---
 .../devicetree/bindings/usb/generic-ehci.yaml      | 14 ++++++++++++++
 .../devicetree/bindings/usb/generic-ohci.yaml      |  7 ++++++-
 2 files changed, 20 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/usb/generic-ehci.yaml b/Documentation/devicetree/bindings/usb/generic-ehci.yaml
index 55a5aa7d7a54..a39f01e740b1 100644
--- a/Documentation/devicetree/bindings/usb/generic-ehci.yaml
+++ b/Documentation/devicetree/bindings/usb/generic-ehci.yaml
@@ -52,6 +52,7 @@ properties:
               - ibm,476gtr-ehci
               - nxp,lpc1850-ehci
               - qca,ar7100-ehci
+              - rockchip,rk3568-ehci
               - rockchip,rk3588-ehci
               - snps,hsdk-v1.0-ehci
               - socionext,uniphier-ehci
@@ -186,6 +187,19 @@ allOf:
       required:
         - clocks
         - clock-names
+  - if:
+      properties:
+        compatible:
+          contains:
+            enum:
+              - rockchip,rk3568-ehci
+              - rockchip,rk3588-ehci
+    then:
+      properties:
+        clocks:
+          minItems: 4
+      required:
+        - clocks
 
 unevaluatedProperties: false
 
diff --git a/Documentation/devicetree/bindings/usb/generic-ohci.yaml b/Documentation/devicetree/bindings/usb/generic-ohci.yaml
index d42f448fa204..19449a6b3033 100644
--- a/Documentation/devicetree/bindings/usb/generic-ohci.yaml
+++ b/Documentation/devicetree/bindings/usb/generic-ohci.yaml
@@ -47,6 +47,7 @@ properties:
               - hpe,gxp-ohci
               - ibm,476gtr-ohci
               - ingenic,jz4740-ohci
+              - rockchip,rk3568-ohci
               - rockchip,rk3588-ohci
               - snps,hsdk-v1.0-ohci
           - const: generic-ohci
@@ -198,11 +199,15 @@ allOf:
       properties:
         compatible:
           contains:
-            const: rockchip,rk3588-ohci
+            enum:
+              - rockchip,rk3568-ohci
+              - rockchip,rk3588-ohci
     then:
       properties:
         clocks:
           minItems: 4
+      required:
+        - clocks
     else:
       properties:
         clocks:
-- 
2.54.0


^ permalink raw reply related

* [PATCH v2 2/2] arm64: dts: rockchip: Fix devices suspend freeze on RK3568/RK3566
From: Jonas Karlman @ 2026-06-24 19:27 UTC (permalink / raw)
  To: Heiko Stuebner, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
	Peter Geis, Michael Riesch
  Cc: Diederik de Haas, Greg Kroah-Hartman, devicetree, linux-rockchip,
	linux-usb, linux-arm-kernel, linux-kernel, Jonas Karlman
In-Reply-To: <20260624192726.781864-1-jonas@kwiboo.se>

The EHCI/OHCI controller depends on clk_usbphy1_480m being enabled, or
the system may freeze when registers are accessed, i.e. during suspend
in ohci_suspend().

Add the missing clk_usbphy1_480m clocks reference to EHCI/OHCI
controllers to ensure the clock is enabled when ECHI/OHCI registers are
accessed to prevent a system freeze.

Fixes suspend pm_test issue with EHCI/OHCI devices due to the missing
clk_usbphy1_480m reference and makes following pm_test modes work:

  echo N > /sys/module/printk/parameters/console_suspend

  echo devices > /sys/power/pm_test
  echo platform > /sys/power/pm_test
  echo processors > /sys/power/pm_test
  echo core > /sys/power/pm_test

  echo mem > /sys/power/state

Fixes: 91c4c3e06a25 ("arm64: dts: rockchip: add usb2 nodes to rk3568 device tree")
Fixes: 78f7186095db ("arm64: dts: rockchip: rename and sort the rk356x usb2 phy handles")
Tested-by: Diederik de Haas <diederik@cknow-tech.com>
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
---
v2: Collect t-b tag
---
 arch/arm64/boot/dts/rockchip/rk356x-base.dtsi | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk356x-base.dtsi b/arch/arm64/boot/dts/rockchip/rk356x-base.dtsi
index a5832895bd39..c930a6fd6ea0 100644
--- a/arch/arm64/boot/dts/rockchip/rk356x-base.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk356x-base.dtsi
@@ -321,44 +321,44 @@ its: msi-controller@fd440000 {
 	};
 
 	usb_host0_ehci: usb@fd800000 {
-		compatible = "generic-ehci";
+		compatible = "rockchip,rk3568-ehci", "generic-ehci";
 		reg = <0x0 0xfd800000 0x0 0x40000>;
 		interrupts = <GIC_SPI 130 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&cru HCLK_USB2HOST0>, <&cru HCLK_USB2HOST0_ARB>,
-			 <&cru PCLK_USB>;
+			 <&cru PCLK_USB>, <&usb2phy1>;
 		phys = <&usb2phy1_otg>;
 		phy-names = "usb";
 		status = "disabled";
 	};
 
 	usb_host0_ohci: usb@fd840000 {
-		compatible = "generic-ohci";
+		compatible = "rockchip,rk3568-ohci", "generic-ohci";
 		reg = <0x0 0xfd840000 0x0 0x40000>;
 		interrupts = <GIC_SPI 131 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&cru HCLK_USB2HOST0>, <&cru HCLK_USB2HOST0_ARB>,
-			 <&cru PCLK_USB>;
+			 <&cru PCLK_USB>, <&usb2phy1>;
 		phys = <&usb2phy1_otg>;
 		phy-names = "usb";
 		status = "disabled";
 	};
 
 	usb_host1_ehci: usb@fd880000 {
-		compatible = "generic-ehci";
+		compatible = "rockchip,rk3568-ehci", "generic-ehci";
 		reg = <0x0 0xfd880000 0x0 0x40000>;
 		interrupts = <GIC_SPI 133 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&cru HCLK_USB2HOST1>, <&cru HCLK_USB2HOST1_ARB>,
-			 <&cru PCLK_USB>;
+			 <&cru PCLK_USB>, <&usb2phy1>;
 		phys = <&usb2phy1_host>;
 		phy-names = "usb";
 		status = "disabled";
 	};
 
 	usb_host1_ohci: usb@fd8c0000 {
-		compatible = "generic-ohci";
+		compatible = "rockchip,rk3568-ohci", "generic-ohci";
 		reg = <0x0 0xfd8c0000 0x0 0x40000>;
 		interrupts = <GIC_SPI 134 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&cru HCLK_USB2HOST1>, <&cru HCLK_USB2HOST1_ARB>,
-			 <&cru PCLK_USB>;
+			 <&cru PCLK_USB>, <&usb2phy1>;
 		phys = <&usb2phy1_host>;
 		phy-names = "usb";
 		status = "disabled";
-- 
2.54.0


^ permalink raw reply related

* Re: [PATCH v4 03/19] firmware: qcom: scm: Fix missing smp_load_acquire()
From: sashiko-bot @ 2026-06-24 19:24 UTC (permalink / raw)
  To: Mukesh Ojha; +Cc: devicetree, robh, conor+dt
In-Reply-To: <20260624190830.3131112-4-mukesh.ojha@oss.qualcomm.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] The waitqueue interrupt is requested and enabled before the global __scm pointer is published, leading to a potential NULL pointer dereference in the IRQ handler path.
--

commit 181d68fe28239c2e3b0bbf1762f175bcdf577648
Author: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>

firmware: qcom: scm: Fix missing smp_load_acquire()

This commit fixes a potential ordering violation in
qcom_scm_set_download_mode() by using smp_load_acquire() to safely read
the __scm pointer published by qcom_scm_probe().

> diff --git a/drivers/firmware/qcom/qcom_scm.c b/drivers/firmware/qcom/qcom_scm.c
> index 9b06a69d3a6d7..c8a84836887f0 100644
> --- a/drivers/firmware/qcom/qcom_scm.c
> +++ b/drivers/firmware/qcom/qcom_scm.c
[ ... ]
> @@ -2841,7 +2844,7 @@ static int qcom_scm_probe(struct platform_device *pdev)
>  	 * will cause the boot stages to enter download mode, unless
>  	 * disabled below by a clean shutdown/reboot.
>  	 */
> -	qcom_scm_set_download_mode(download_mode);
> +	qcom_scm_set_download_mode(scm, download_mode);

[Severity: High]
This is a pre-existing issue, but since we are looking at the initialization
ordering in qcom_scm_probe() in drivers/firmware/qcom/qcom_scm.c, could the
IRQ registration order cause a NULL pointer dereference?

Earlier in qcom_scm_probe(), the waitqueue interrupt is enabled before the
global __scm pointer is published:

	ret = devm_request_threaded_irq(scm->dev, irq, NULL, qcom_scm_irq_handler,
					IRQF_ONESHOT, "qcom-scm", scm);
	...
	smp_store_release(&__scm, scm);

If a pending hardware interrupt fires before __scm is published, the IRQ
handler will execute. The handler calls qcom_scm_waitq_wakeup(), which invokes
qcom_scm_get_completion().

Could qcom_scm_get_completion() crash here, since it ignores the valid scm
context passed via the IRQ data and unconditionally dereferences __scm?

drivers/firmware/qcom/qcom_scm.c:qcom_scm_get_completion() {
	if (WARN_ON_ONCE(wq_ctx >= __scm->wq_cnt))
		return ERR_PTR(-EINVAL);
	...
}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260624190830.3131112-1-mukesh.ojha@oss.qualcomm.com?part=3

^ permalink raw reply

* Re: [PATCH v4 04/19] firmware: qcom: scm: use dev_err_probe() for dload address failure
From: sashiko-bot @ 2026-06-24 19:22 UTC (permalink / raw)
  To: Mukesh Ojha; +Cc: conor+dt, robh, devicetree
In-Reply-To: <20260624190830.3131112-5-mukesh.ojha@oss.qualcomm.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [High] The global `qcom_tzmem_dev` pointer is set during `qcom_tzmem_enable()` but is never cleared on probe failure, causing subsequent probe retries to permanently fail with `-EBUSY`.
- [High] The probe function calls `of_reserved_mem_device_init()` but does not call `of_reserved_mem_device_release()` on subsequent error paths, leading to permanent probe failure or resource leaks upon probe retry.
--

commit 6dc15526252b78a9c217f06ed35ed4966a794450
Author: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>

firmware: qcom: scm: use dev_err_probe() for dload address failure

Replace the bare return ret after qcom_scm_find_dload_address() with
dev_err_probe() to produce a consistent, deferred-probe-aware error
message when the download-mode address cannot be resolved.

> diff --git a/drivers/firmware/qcom/qcom_scm.c b/drivers/firmware/qcom/qcom_scm.c
> index c8a84836887f0..6cd4d9468456f 100644
> --- a/drivers/firmware/qcom/qcom_scm.c
> +++ b/drivers/firmware/qcom/qcom_scm.c
> @@ -2750,7 +2750,8 @@ static int qcom_scm_probe(struct platform_device *pdev)
>  	scm->dev = &pdev->dev;
>  	ret = qcom_scm_find_dload_address(&pdev->dev, &scm->dload_mode_addr);
>  	if (ret < 0)
> -		return ret;
> +		return dev_err_probe(&pdev->dev, ret,
> +				     "Failed to get download mode address\n");
>  
>  	mutex_init(&scm->scm_bw_lock);

[Severity: High]
This is a pre-existing issue, but does qcom_scm_probe() properly release
resources on later probe failures?

Later in qcom_scm_probe(), of_reserved_mem_device_init() is called to setup
reserved memory:

drivers/firmware/qcom/qcom_scm.c:qcom_scm_probe() {
	...
	ret = of_reserved_mem_device_init(scm->dev);
	if (ret && ret != -ENODEV)
		return dev_err_probe(scm->dev, ret,
				     "Failed to setup the reserved memory region for TZ mem\n");
	...
}

However, subsequent error paths, such as platform_get_irq_optional() returning
-EPROBE_DEFER, exit directly without calling of_reserved_mem_device_release().

If the probe is deferred, will this cause the next probe attempt to fail with
-EBUSY, or leak memory by duplicating the rmem_assigned_device list entry on
every retry?

[Severity: High]
This is a pre-existing issue, but does qcom_tzmem_enable() cause a permanent
probe failure if qcom_scm_probe() defers later in the function?

qcom_tzmem_enable() sets a static qcom_tzmem_dev pointer in qcom_tzmem.c:

drivers/firmware/qcom/qcom_tzmem.c:qcom_tzmem_enable() {
	if (qcom_tzmem_dev)
		return -EBUSY;

	qcom_tzmem_dev = dev;

	return qcom_tzmem_init();
}

Since qcom_scm_probe() does not clear this pointer if it defers after this
call, will subsequent probe retries permanently fail with -EBUSY when
qcom_tzmem_enable() checks the still-set pointer?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260624190830.3131112-1-mukesh.ojha@oss.qualcomm.com?part=4

^ permalink raw reply

* Re: [PATCH v4 01/19] dt-bindings: firmware: qcom,scm: Add minidump SRAM property
From: sashiko-bot @ 2026-06-24 19:19 UTC (permalink / raw)
  To: Mukesh Ojha; +Cc: conor+dt, devicetree, robh
In-Reply-To: <20260624190830.3131112-2-mukesh.ojha@oss.qualcomm.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Missing property type reference (`$ref`) for the `sram` property in the dt-binding schema.
--

commit 6acd1cecaeb951d30398f9208dd4e87b7cfd156e
Author: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>

dt-bindings: firmware: qcom,scm: Add minidump SRAM property

This commit adds a new 'sram' property to the Qualcomm SCM dt-binding. The
property is intended to contain a phandle to a region in always-on SRAM used
for minidump download destination configuration. This allows the OS to share
information with the boot firmware across warm resets.

> diff --git a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
> index 7918d31f58b4a..82c661db0b616 100644
> --- a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
> +++ b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
> @@ -127,6 +127,13 @@ properties:
>            - description: offset of the download mode control register
>      description: TCSR hardware block
>  
> +  sram:
> +    description:
> +      Phandle to a region in always-on SRAM used to store the download
> +      mode value for boot firmware to read before DDR is initialised on
> +      the next warm reset.
> +    maxItems: 1

[Severity: Low]
Does this property need an explicit type reference, such as
$ref: /schemas/types.yaml#/definitions/phandle?

Without a type definition, the dt-schema validator might infer the property
as an untyped array based on the presence of maxItems: 1. Could this allow
malformed device trees to pass validation silently since it won't enforce
that the provided value is actually a valid phandle?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260624190830.3131112-1-mukesh.ojha@oss.qualcomm.com?part=1

^ permalink raw reply

* [PATCH v4 19/19] arm64: dts: qcom: sdm845: Add minidump SRAM config to SCM node
From: Mukesh Ojha @ 2026-06-24 19:08 UTC (permalink / raw)
  To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley, Robert Marko, Guru Das Srinagesh
  Cc: cros-qcom-dts-watchers, linux-arm-msm, devicetree, linux-kernel,
	Mukesh Ojha
In-Reply-To: <20260624190830.3131112-1-mukesh.ojha@oss.qualcomm.com>

Point the SCM node at the minidump config slot in the always-on SRAM.
Boot firmware reads this word before DDR is initialised on a warm reset
to decide where to deliver the minidump.

Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/sdm845.dtsi | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 4ae8627d6dbc..2179988dbaaf 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -363,6 +363,7 @@ cluster_sleep_0: cluster-sleep-0 {
 	firmware {
 		scm {
 			compatible = "qcom,scm-sdm845", "qcom,scm";
+			sram = <&minidump_config>;
 		};
 	};
 
@@ -5192,6 +5193,10 @@ sram@14680000 {
 
 			ranges = <0 0 0x14680000 0x40000>;
 
+			minidump_config: minidump-sram@1c {
+				reg = <0x1c 0x4>;
+			};
+
 			ipa_modem_tables: modem-tables@3d000 {
 				reg = <0x3d000 0x2000>;
 			};
-- 
2.53.0


^ permalink raw reply related

* [PATCH v4 18/19] arm64: dts: qcom: qcs615: Add minidump SRAM config to SCM node
From: Mukesh Ojha @ 2026-06-24 19:08 UTC (permalink / raw)
  To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley, Robert Marko, Guru Das Srinagesh
  Cc: cros-qcom-dts-watchers, linux-arm-msm, devicetree, linux-kernel,
	Mukesh Ojha, Konrad Dybcio
In-Reply-To: <20260624190830.3131112-1-mukesh.ojha@oss.qualcomm.com>

Point the SCM node at the minidump config slot in the always-on SRAM.
Boot firmware reads this word before DDR is initialised on a warm reset
to decide where to deliver the minidump.

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/talos.dtsi | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/talos.dtsi b/arch/arm64/boot/dts/qcom/talos.dtsi
index fb1bbc51bb8a..a358d5441fa9 100644
--- a/arch/arm64/boot/dts/qcom/talos.dtsi
+++ b/arch/arm64/boot/dts/qcom/talos.dtsi
@@ -473,6 +473,7 @@ firmware {
 		scm {
 			compatible = "qcom,scm-qcs615", "qcom,scm";
 			qcom,dload-mode = <&tcsr 0x13000>;
+			sram = <&minidump_config>;
 		};
 	};
 
@@ -4654,6 +4655,10 @@ sram@14680000 {
 			#address-cells = <1>;
 			#size-cells = <1>;
 
+			minidump_config: minidump-sram@1c {
+				reg = <0x1c 0x4>;
+			};
+
 			pil-reloc@2a94c {
 				compatible = "qcom,pil-reloc-info";
 				reg = <0x2a94c 0xc8>;
-- 
2.53.0


^ permalink raw reply related

* [PATCH v4 17/19] arm64: dts: qcom: sm6375: Add minidump SRAM config to SCM node
From: Mukesh Ojha @ 2026-06-24 19:08 UTC (permalink / raw)
  To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley, Robert Marko, Guru Das Srinagesh
  Cc: cros-qcom-dts-watchers, linux-arm-msm, devicetree, linux-kernel,
	Mukesh Ojha, Konrad Dybcio
In-Reply-To: <20260624190830.3131112-1-mukesh.ojha@oss.qualcomm.com>

Point the SCM node at the minidump config slot in the always-on SRAM.
Boot firmware reads this word before DDR is initialised on a warm reset
to decide where to deliver the minidump.

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/sm6375.dtsi | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sm6375.dtsi b/arch/arm64/boot/dts/qcom/sm6375.dtsi
index ccf572bb1549..71a228597093 100644
--- a/arch/arm64/boot/dts/qcom/sm6375.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm6375.dtsi
@@ -307,6 +307,7 @@ scm {
 			compatible = "qcom,scm-sm6375", "qcom,scm";
 			clocks = <&rpmcc RPM_SMD_CE1_CLK>;
 			clock-names = "core";
+			sram = <&minidump_config>;
 			#reset-cells = <1>;
 		};
 	};
@@ -1645,6 +1646,10 @@ sram@c125000 {
 			#address-cells = <1>;
 			#size-cells = <1>;
 
+			minidump_config: minidump-sram@1c {
+				reg = <0x1c 0x4>;
+			};
+
 			pil-reloc@94c {
 				compatible = "qcom,pil-reloc-info";
 				reg = <0x94c 0xc8>;
-- 
2.53.0


^ permalink raw reply related

* [PATCH v4 16/19] arm64: dts: qcom: sm6350: Add minidump SRAM config to SCM node
From: Mukesh Ojha @ 2026-06-24 19:08 UTC (permalink / raw)
  To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley, Robert Marko, Guru Das Srinagesh
  Cc: cros-qcom-dts-watchers, linux-arm-msm, devicetree, linux-kernel,
	Mukesh Ojha, Konrad Dybcio
In-Reply-To: <20260624190830.3131112-1-mukesh.ojha@oss.qualcomm.com>

Point the SCM node at the minidump config slot in the always-on SRAM.
Boot firmware reads this word before DDR is initialised on a warm reset
to decide where to deliver the minidump.

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/sm6350.dtsi | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sm6350.dtsi b/arch/arm64/boot/dts/qcom/sm6350.dtsi
index d6adf68563cb..06892ba22875 100644
--- a/arch/arm64/boot/dts/qcom/sm6350.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm6350.dtsi
@@ -363,6 +363,7 @@ big_cpu_sleep_1: cpu-sleep-1-1 {
 	firmware {
 		scm: scm {
 			compatible = "qcom,scm-sm6350", "qcom,scm";
+			sram = <&minidump_config>;
 			#reset-cells = <1>;
 		};
 	};
@@ -2808,6 +2809,10 @@ sram@14680000 {
 
 			ranges = <0 0 0x14680000 0x2e000>;
 
+			minidump_config: minidump-sram@1c {
+				reg = <0x1c 0x4>;
+			};
+
 			ipa_modem_tables: modem-tables@28000 {
 				reg = <0x28000 0x2000>;
 			};
-- 
2.53.0


^ permalink raw reply related

* [PATCH v4 15/19] arm64: dts: qcom: sc7180: Add minidump SRAM config to SCM node
From: Mukesh Ojha @ 2026-06-24 19:08 UTC (permalink / raw)
  To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley, Robert Marko, Guru Das Srinagesh
  Cc: cros-qcom-dts-watchers, linux-arm-msm, devicetree, linux-kernel,
	Mukesh Ojha, Konrad Dybcio
In-Reply-To: <20260624190830.3131112-1-mukesh.ojha@oss.qualcomm.com>

Point the SCM node at the minidump config slot in the always-on SRAM.
Boot firmware reads this word before DDR is initialised on a warm reset
to decide where to deliver the minidump.

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/sc7180.dtsi | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi b/arch/arm64/boot/dts/qcom/sc7180.dtsi
index fa65c485172f..1f51fd431ce5 100644
--- a/arch/arm64/boot/dts/qcom/sc7180.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
@@ -385,6 +385,7 @@ cluster_aoss_sleep: cluster-sleep-2 {
 	firmware {
 		scm: scm {
 			compatible = "qcom,scm-sc7180", "qcom,scm";
+			sram = <&minidump_config>;
 		};
 	};
 
@@ -3596,6 +3597,10 @@ sram@14680000 {
 
 			ranges = <0 0 0x14680000 0x2e000>;
 
+			minidump_config: minidump-sram@1c {
+				reg = <0x1c 0x4>;
+			};
+
 			ipa_modem_tables: modem-tables@28000 {
 				reg = <0x28000 0x2000>;
 			};
-- 
2.53.0


^ permalink raw reply related

* [PATCH v4 14/19] arm64: dts: qcom: sm8350: Add minidump SRAM config to SCM node
From: Mukesh Ojha @ 2026-06-24 19:08 UTC (permalink / raw)
  To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley, Robert Marko, Guru Das Srinagesh
  Cc: cros-qcom-dts-watchers, linux-arm-msm, devicetree, linux-kernel,
	Mukesh Ojha, Konrad Dybcio
In-Reply-To: <20260624190830.3131112-1-mukesh.ojha@oss.qualcomm.com>

Point the SCM node at the minidump config slot in the always-on SRAM.
Boot firmware reads this word before DDR is initialised on a warm reset
to decide where to deliver the minidump.

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/sm8350.dtsi | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sm8350.dtsi b/arch/arm64/boot/dts/qcom/sm8350.dtsi
index c830953156ec..dea97330da49 100644
--- a/arch/arm64/boot/dts/qcom/sm8350.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8350.dtsi
@@ -293,6 +293,7 @@ firmware {
 		scm: scm {
 			compatible = "qcom,scm-sm8350", "qcom,scm";
 			qcom,dload-mode = <&tcsr 0x13000>;
+			sram = <&minidump_config>;
 			#reset-cells = <1>;
 		};
 	};
@@ -3451,6 +3452,10 @@ sram@14680000 {
 
 			ranges = <0 0 0x14680000 0x40000>;
 
+			minidump_config: minidump-sram@1c {
+				reg = <0x1c 0x4>;
+			};
+
 			ipa_modem_tables: modem-tables@3d000 {
 				reg = <0x3d000 0x2000>;
 			};
-- 
2.53.0


^ permalink raw reply related

* [PATCH v4 13/19] arm64: dts: qcom: sc7280: Add minidump SRAM config to SCM node
From: Mukesh Ojha @ 2026-06-24 19:08 UTC (permalink / raw)
  To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley, Robert Marko, Guru Das Srinagesh
  Cc: cros-qcom-dts-watchers, linux-arm-msm, devicetree, linux-kernel,
	Mukesh Ojha, Konrad Dybcio
In-Reply-To: <20260624190830.3131112-1-mukesh.ojha@oss.qualcomm.com>

Point the SCM node at the minidump config slot in the always-on SRAM.
Boot firmware reads this word before DDR is initialised on a warm reset
to decide where to deliver the minidump.

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/kodiak.dtsi | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/kodiak.dtsi b/arch/arm64/boot/dts/qcom/kodiak.dtsi
index fa540d8c2615..6d805cbe5b4f 100644
--- a/arch/arm64/boot/dts/qcom/kodiak.dtsi
+++ b/arch/arm64/boot/dts/qcom/kodiak.dtsi
@@ -720,6 +720,7 @@ firmware {
 		scm: scm {
 			compatible = "qcom,scm-sc7280", "qcom,scm";
 			qcom,dload-mode = <&tcsr_2 0x13000>;
+			sram = <&minidump_config>;
 		};
 	};
 
@@ -6698,6 +6699,10 @@ sram@146a5000 {
 
 			ranges = <0 0 0x146a5000 0x6000>;
 
+			minidump_config: minidump-sram@1c {
+				reg = <0x1c 0x4>;
+			};
+
 			ipa_modem_tables: modem-tables@3000 {
 				reg = <0x3000 0x2000>;
 			};
-- 
2.53.0


^ permalink raw reply related

* [PATCH v4 12/19] arm64: dts: qcom: sm8650: Add minidump SRAM config to SCM node
From: Mukesh Ojha @ 2026-06-24 19:08 UTC (permalink / raw)
  To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley, Robert Marko, Guru Das Srinagesh
  Cc: cros-qcom-dts-watchers, linux-arm-msm, devicetree, linux-kernel,
	Mukesh Ojha, Konrad Dybcio
In-Reply-To: <20260624190830.3131112-1-mukesh.ojha@oss.qualcomm.com>

Point the SCM node at the minidump config slot in the always-on SRAM.
Boot firmware reads this word before DDR is initialised on a warm reset
to decide where to deliver the minidump.

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/sm8650.dtsi | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sm8650.dtsi b/arch/arm64/boot/dts/qcom/sm8650.dtsi
index 160ead25ecf7..88751d3b72cd 100644
--- a/arch/arm64/boot/dts/qcom/sm8650.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8650.dtsi
@@ -645,6 +645,7 @@ scm: scm {
 			qcom,dload-mode = <&tcsr 0x19000>;
 			interconnects = <&aggre2_noc MASTER_CRYPTO QCOM_ICC_TAG_ALWAYS
 					 &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>;
+			sram = <&minidump_config>;
 		};
 	};
 
@@ -7091,6 +7092,10 @@ sram@14680000 {
 
 			ranges = <0 0 0x14680000 0x2c000>;
 
+			minidump_config: minidump-sram@1c {
+				reg = <0x1c 0x4>;
+			};
+
 			ipa_modem_tables: modem-tables@8000 {
 				reg = <0x8000 0x2000>;
 			};
-- 
2.53.0


^ permalink raw reply related

* [PATCH v4 11/19] arm64: dts: qcom: sm8550: Add minidump SRAM config to SCM node
From: Mukesh Ojha @ 2026-06-24 19:08 UTC (permalink / raw)
  To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley, Robert Marko, Guru Das Srinagesh
  Cc: cros-qcom-dts-watchers, linux-arm-msm, devicetree, linux-kernel,
	Mukesh Ojha, Konrad Dybcio
In-Reply-To: <20260624190830.3131112-1-mukesh.ojha@oss.qualcomm.com>

Point the SCM node at the minidump config slot in the always-on SRAM.
Boot firmware reads this word before DDR is initialised on a warm reset
to decide where to deliver the minidump.

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/sm8550.dtsi | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sm8550.dtsi b/arch/arm64/boot/dts/qcom/sm8550.dtsi
index 396201905ef2..8830da63261f 100644
--- a/arch/arm64/boot/dts/qcom/sm8550.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8550.dtsi
@@ -391,6 +391,7 @@ scm: scm {
 			qcom,dload-mode = <&tcsr 0x19000>;
 			interconnects = <&aggre2_noc MASTER_CRYPTO QCOM_ICC_TAG_ALWAYS
 					 &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>;
+			sram = <&minidump_config>;
 		};
 	};
 
@@ -5537,6 +5538,10 @@ sram@14680000 {
 
 			ranges = <0 0 0x14680000 0x2c000>;
 
+			minidump_config: minidump-sram@1c {
+				reg = <0x1c 0x4>;
+			};
+
 			ipa_modem_tables: modem-tables@8000 {
 				reg = <0x8000 0x2000>;
 			};
-- 
2.53.0


^ permalink raw reply related

* [PATCH v4 10/19] arm64: dts: qcom: qdu1000: Add minidump SRAM config to SCM node
From: Mukesh Ojha @ 2026-06-24 19:08 UTC (permalink / raw)
  To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley, Robert Marko, Guru Das Srinagesh
  Cc: cros-qcom-dts-watchers, linux-arm-msm, devicetree, linux-kernel,
	Mukesh Ojha, Konrad Dybcio
In-Reply-To: <20260624190830.3131112-1-mukesh.ojha@oss.qualcomm.com>

Point the SCM node at the minidump config slot in the always-on SRAM.
Boot firmware reads this word before DDR is initialised on a warm reset
to decide where to deliver the minidump.

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/qdu1000.dtsi | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/qdu1000.dtsi b/arch/arm64/boot/dts/qcom/qdu1000.dtsi
index 952d4270d118..0c6ae3ff06fb 100644
--- a/arch/arm64/boot/dts/qcom/qdu1000.dtsi
+++ b/arch/arm64/boot/dts/qcom/qdu1000.dtsi
@@ -171,6 +171,7 @@ cluster_sleep_1: cluster-sleep-1 {
 	firmware {
 		scm {
 			compatible = "qcom,scm-qdu1000", "qcom,scm";
+			sram = <&minidump_config>;
 		};
 	};
 
@@ -1369,6 +1370,10 @@ sram@14680000 {
 			#address-cells = <1>;
 			#size-cells = <1>;
 
+			minidump_config: minidump-sram@1c {
+				reg = <0x1c 0x4>;
+			};
+
 			pil-reloc@94c {
 				compatible = "qcom,pil-reloc-info";
 				reg = <0x94c 0xc8>;
-- 
2.53.0


^ permalink raw reply related

* [PATCH v4 09/19] arm64: dts: qcom: qcs8300: Add minidump SRAM config to SCM node
From: Mukesh Ojha @ 2026-06-24 19:08 UTC (permalink / raw)
  To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley, Robert Marko, Guru Das Srinagesh
  Cc: cros-qcom-dts-watchers, linux-arm-msm, devicetree, linux-kernel,
	Mukesh Ojha, Konrad Dybcio
In-Reply-To: <20260624190830.3131112-1-mukesh.ojha@oss.qualcomm.com>

Point the SCM node at the minidump config slot in the always-on SRAM.
Boot firmware reads this word before DDR is initialised on a warm reset
to decide where to deliver the minidump.

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/monaco.dtsi | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/monaco.dtsi b/arch/arm64/boot/dts/qcom/monaco.dtsi
index e4c8466f941b..a05b8d28bdb8 100644
--- a/arch/arm64/boot/dts/qcom/monaco.dtsi
+++ b/arch/arm64/boot/dts/qcom/monaco.dtsi
@@ -634,6 +634,7 @@ firmware {
 		scm: scm {
 			compatible = "qcom,scm-qcs8300", "qcom,scm";
 			qcom,dload-mode = <&tcsr 0x13000>;
+			sram = <&minidump_config>;
 		};
 	};
 
@@ -7154,6 +7155,10 @@ sram: sram@146d8000 {
 			#address-cells = <1>;
 			#size-cells = <1>;
 
+			minidump_config: minidump-sram@1c {
+				reg = <0x1c 0x4>;
+			};
+
 			pil-reloc@94c {
 				compatible = "qcom,pil-reloc-info";
 				reg = <0x94c 0xc8>;
-- 
2.53.0


^ permalink raw reply related

* [PATCH v4 08/19] arm64: dts: qcom: sa8775p: Add minidump SRAM config to SCM node
From: Mukesh Ojha @ 2026-06-24 19:08 UTC (permalink / raw)
  To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley, Robert Marko, Guru Das Srinagesh
  Cc: cros-qcom-dts-watchers, linux-arm-msm, devicetree, linux-kernel,
	Mukesh Ojha, Konrad Dybcio
In-Reply-To: <20260624190830.3131112-1-mukesh.ojha@oss.qualcomm.com>

Point the SCM node at the minidump config slot in the always-on SRAM.
Boot firmware reads this word before DDR is initialised on a warm reset
to decide where to deliver the minidump.

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/lemans.dtsi | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/lemans.dtsi b/arch/arm64/boot/dts/qcom/lemans.dtsi
index 353a6e6fd3ac..a1708bd15076 100644
--- a/arch/arm64/boot/dts/qcom/lemans.dtsi
+++ b/arch/arm64/boot/dts/qcom/lemans.dtsi
@@ -524,6 +524,7 @@ firmware {
 		scm {
 			compatible = "qcom,scm-sa8775p", "qcom,scm";
 			qcom,dload-mode = <&tcsr 0x13000>;
+			sram = <&minidump_config>;
 		};
 	};
 
@@ -6825,6 +6826,10 @@ sram: sram@146d8000 {
 			#address-cells = <1>;
 			#size-cells = <1>;
 
+			minidump_config: minidump-sram@1c {
+				reg = <0x1c 0x4>;
+			};
+
 			pil-reloc@94c {
 				compatible = "qcom,pil-reloc-info";
 				reg = <0x94c 0xc8>;
-- 
2.53.0


^ permalink raw reply related

* [PATCH v4 07/19] arm64: dts: qcom: sm8450: Add minidump SRAM config to SCM node
From: Mukesh Ojha @ 2026-06-24 19:08 UTC (permalink / raw)
  To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley, Robert Marko, Guru Das Srinagesh
  Cc: cros-qcom-dts-watchers, linux-arm-msm, devicetree, linux-kernel,
	Mukesh Ojha, Konrad Dybcio
In-Reply-To: <20260624190830.3131112-1-mukesh.ojha@oss.qualcomm.com>

Point the SCM node at the minidump config slot in the always-on SRAM.
Boot firmware reads this word before DDR is initialised on a warm reset
to decide where to deliver the minidump.

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/sm8450.dtsi | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sm8450.dtsi b/arch/arm64/boot/dts/qcom/sm8450.dtsi
index 56cb6e959e4e..f819b4f7fdbc 100644
--- a/arch/arm64/boot/dts/qcom/sm8450.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8450.dtsi
@@ -479,6 +479,7 @@ scm: scm {
 			compatible = "qcom,scm-sm8450", "qcom,scm";
 			qcom,dload-mode = <&tcsr 0x13000>;
 			interconnects = <&aggre2_noc MASTER_CRYPTO 0 &mc_virt SLAVE_EBI1 0>;
+			sram = <&minidump_config>;
 			#reset-cells = <1>;
 		};
 	};
@@ -4978,6 +4979,10 @@ sram@146aa000 {
 			#address-cells = <1>;
 			#size-cells = <1>;
 
+			minidump_config: minidump-sram@1c {
+				reg = <0x1c 0x4>;
+			};
+
 			pil-reloc@94c {
 				compatible = "qcom,pil-reloc-info";
 				reg = <0x94c 0xc8>;
-- 
2.53.0


^ permalink raw reply related

* [PATCH v4 06/19] arm64: dts: qcom: kaanapali: Add minidump SRAM config to SCM node
From: Mukesh Ojha @ 2026-06-24 19:08 UTC (permalink / raw)
  To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley, Robert Marko, Guru Das Srinagesh
  Cc: cros-qcom-dts-watchers, linux-arm-msm, devicetree, linux-kernel,
	Mukesh Ojha, Konrad Dybcio
In-Reply-To: <20260624190830.3131112-1-mukesh.ojha@oss.qualcomm.com>

Point the SCM node at the minidump config slot in the always-on SRAM.
Boot firmware reads this word before DDR is initialised on a warm reset
to decide where to deliver the minidump.

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/kaanapali.dtsi | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/kaanapali.dtsi b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
index 7aa9653bd456..0342fd28f9b9 100644
--- a/arch/arm64/boot/dts/qcom/kaanapali.dtsi
+++ b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
@@ -224,6 +224,7 @@ scm: scm {
 			qcom,dload-mode = <&tcsr 0x19000>;
 			interconnects = <&aggre_noc MASTER_CRYPTO QCOM_ICC_TAG_ALWAYS
 					 &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>;
+			sram = <&minidump_config>;
 		};
 
 		scmi: scmi {
@@ -5452,6 +5453,10 @@ sram@14680000 {
 			#address-cells = <1>;
 			#size-cells = <1>;
 
+			minidump_config: minidump-sram@1c {
+				reg = <0x1c 0x4>;
+			};
+
 			pil-sram@94c {
 				compatible = "qcom,pil-reloc-info";
 				reg = <0x94c 0xc8>;
-- 
2.53.0


^ permalink raw reply related


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox