* Re: [PATCH v4 1/3] dt-bindings: add DTS style checker
From: sashiko-bot @ 2026-05-22 18:17 UTC (permalink / raw)
To: Daniel Golle; +Cc: devicetree, conor+dt, robh
In-Reply-To: <457f328d4c5d639482fddf40e79be61b97db5814.1779472837.git.daniel@makrotopia.org>
Thank you for your contribution! Sashiko AI review found 6 potential issue(s) to consider:
- [Medium] Code following a block comment on the same line is completely ignored, breaking parsing state and nesting depth.
- [Medium] Multi-line C preprocessor directives (macros) using `\` continuations are mishandled, corrupting the parsing state and triggering false-positive style warnings.
- [Medium] The unused-labels checker regex matches inside string literals and misses labels on nodes starting with digits.
- [Medium] Syntactic checks operating on `dl.raw` incorrectly process the contents of unclosed block comments on `PROPERTY` lines, causing false positives.
- [Medium] The regex for node headers rejects nodes with malformed unit addresses, allowing them to bypass the unit-address format check.
- [Low] Multiple closing braces on the same line break depth tracking and cause cascading false positive warnings.
--
commit 6b49caf90b5c4741b273da5e02e9f53fa30ea1bc
Author: Daniel Golle <daniel@makrotopia.org>
dt-bindings: add DTS style checker
Add a Python tool that checks DTS coding style on examples in YAML binding
files and on .dts/.dtsi/.dtso source files. Rules are kept in a declarative
registry, tagged as 'relaxed' or 'strict'.
> diff --git a/scripts/dtc/dt-check-style b/scripts/dtc/dt-check-style
> new file mode 100755
> index 0000000000000..93cb1d7d2985c
> --- /dev/null
> +++ b/scripts/dtc/dt-check-style
[ ... ]
> +re_node_header = re.compile(
> + r'^(?:([a-zA-Z_][a-zA-Z0-9_]*):\s*)?'
> + r'([a-zA-Z0-9][a-zA-Z0-9,._+-]*|/)'
> + r'(?:@([0-9a-fA-F,]+))?'
> + r'\s*\{$')
[Severity: Medium]
Will this regex reject nodes with malformed unit addresses, allowing them to
bypass the unit-address format check?
If the unit address contains characters outside this set, such as the x in
memory@0x1000, the entire regex match fails and dl.node_addr remains None.
Because check_unit_address_format() skips validation if dl.node_addr is None,
does this allow malformed unit addresses containing 0x to bypass the very
check designed to flag them?
[ ... ]
> + if in_block_comment:
> + ltype = (LineType.COMMENT_END if '*/' in stripped
> + else LineType.COMMENT_BODY)
> + if ltype == LineType.COMMENT_END:
> + in_block_comment = False
> + dl = DtsLine(i, raw, ltype, indent_str, stripped)
> + dl.depth = depth
> + out.append(dl)
> + continue
> +
> + if stripped.startswith('/*'):
> + if '*/' in stripped:
> + ltype = LineType.COMMENT
> + else:
> + in_block_comment = True
> + ltype = LineType.COMMENT_START
> + dl = DtsLine(i, raw, ltype, indent_str, stripped)
> + dl.depth = depth
> + out.append(dl)
> + continue
[Severity: Medium]
Does this code skip parsing for any valid DTS code following a block comment
on the exact same line?
If a line starts with /* and contains */, or if an open block comment ends on
the line, the script sets the line type and immediately executes continue.
Could this lead to desynchronized nesting depth tracking by ignoring
constructs like /* ... */ }; or /* ... */ foo = <1>;, incorrectly classifying
subsequent lines and triggering cascading false positive violations?
> +
> + if stripped.startswith('//'):
> + dl = DtsLine(i, raw, LineType.COMMENT, indent_str, stripped)
> + dl.depth = depth
> + out.append(dl)
> + continue
> +
> + if stripped.startswith('#') and is_preprocessor(stripped):
> + dl = DtsLine(i, raw, LineType.PREPROCESSOR,
> + indent_str, stripped)
> + dl.depth = depth
> + out.append(dl)
> + prev_complete = True
> + continue
[Severity: Medium]
Does this logic mishandle multi-line C preprocessor directives using
backslash continuations?
If the directive has trailing backslashes to continue macros to subsequent
lines, the continuation lines do not start with #.
Are these improperly parsed as standard DTS properties or continuations,
inappropriately applying DTS constraints to internal C code and triggering
false positives?
[ ... ]
> + if code == '};' or code == '}':
> + depth = max(depth - 1, 0)
> + dl = DtsLine(i, raw, LineType.NODE_CLOSE, indent_str, code)
> + dl.depth = depth
> + out.append(dl)
> + prev_complete = True
> + continue
[Severity: Low]
Will this fail to decrement nesting depth if a single line contains multiple
closures?
If code contains }; };, this exact-match condition fails.
Does the line then improperly fall through and get classified as
LineType.PROPERTY, corrupting depth tracking for subsequent lines and
incorrectly flagging them for indentation violations?
[ ... ]
> +def collect_labels_and_refs(text):
> + """Return (defined_labels, referenced_labels) found anywhere outside
> + /* */ comments. Labels named fake_intc* (injected by
> + dt-extract-example) are skipped."""
> + # Strip block comments first so labels inside them don't count
> + stripped = re.sub(r'/\*.*?\*/', '', text, flags=re.DOTALL)
> + # Strip line comments
> + stripped = re.sub(r'//[^\n]*', '', stripped)
> + defined = set()
> + referenced = set()
> + for m in re.finditer(r'(?:^|[\s{])([a-zA-Z_][a-zA-Z0-9_]*):\s*[a-zA-Z/&]',
> + stripped):
[Severity: Medium]
Does this regex match inside string literals and miss labels on nodes
starting with digits?
Since string literals are not stripped before searching for labels, words
followed by colons inside strings like prop = "Error: failed"; could be added
to the defined set and flagged as unused.
Additionally, because the regex requires the character following the colon to
be a letter, /, or &, does it fail to capture labels attached to nodes
starting with a digit like label: 1wire@10 {?
[ ... ]
> +def _strip_strings_and_comments(text):
> + """Remove string literals and /* */ + // comments from a single
> + line, replacing them with empty strings. Used so syntactic checks
> + (whitespace, hex case, etc.) don't false-positive on contents of
> + quoted strings or comments."""
> + text = re.sub(r'"(?:[^"\\]|\\.)*"', '""', text)
> + text = re.sub(r'/\*.*?\*/', '', text)
> + text = re.sub(r'//.*$', '', text)
> + return text
[Severity: Medium]
Will syntactic checks incorrectly process the contents of unclosed block
comments on PROPERTY lines?
Because the regex only removes block comments that both open and close on the
same line, if a line contains an unclosed block comment like
prop = <1>; /* ... 0xABC, the regex fails to match.
Does the comment text remain intact, causing checks like check_hex_case() to
yield false positive errors for uppercase hex values inside the comment?
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1779472837.git.daniel@makrotopia.org?part=1
^ permalink raw reply
* Re: [PATCH v6 04/10] nvmem: Add the Raspberry Pi OTP driver
From: sashiko-bot @ 2026-05-22 18:18 UTC (permalink / raw)
To: Gregor Herburger; +Cc: devicetree, conor+dt, robh
In-Reply-To: <20260522-rpi-otp-driver-v6-4-b0eac97d1428@linutronix.de>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] Potential FORTIFY_SOURCE out-of-bounds panic in `rpi_otp_read()` due to missing short-read validation.
- [High] `devm`-allocated private data is used-after-free if an external consumer holds a reference to the nvmem device after driver unbind.
- [Medium] Unconditional write support can lead to silent write failures on read-only OTP regions.
--
commit dcc1b143736646b08c117f369ca02e22f47c7ba5
Author: Gregor Herburger <gregor.herburger@linutronix.de>
nvmem: Add the Raspberry Pi OTP driver
Raspberry Pis have OTP registers which can be accessed through the
videocore firmware. Add a nvmem driver to support these OTP registers.
> diff --git a/drivers/nvmem/raspberrypi-otp.c b/drivers/nvmem/raspberrypi-otp.c
> new file mode 100644
> index 0000000000000..2e2537ee6793b
> --- /dev/null
> +++ b/drivers/nvmem/raspberrypi-otp.c
> @@ -0,0 +1,131 @@
[ ... ]
> +static int rpi_otp_read(void *context, unsigned int offset, void *buf, size_t bytes)
> +{
> + struct rpi_otp_priv *priv = context;
> + struct rpi_otp_header *fwbuf;
> + u32 count;
> + int ret;
> +
> + count = bytes / 4;
> +
> + fwbuf = kzalloc(struct_size(fwbuf, data, count), GFP_KERNEL);
> + if (!fwbuf)
> + return -ENOMEM;
> +
> + fwbuf->start = cpu_to_le32(offset / 4);
> + fwbuf->count = cpu_to_le32(count);
> +
> + ret = rpi_firmware_property(priv->fw, priv->read_tag, fwbuf,
> + sizeof(struct rpi_otp_header) + bytes);
> + if (ret)
> + goto out;
> +
> + memcpy(buf, fwbuf->data, bytes);
[Severity: High]
Can this trigger a FORTIFY_SOURCE out-of-bounds panic?
The struct rpi_otp_header uses the __counted_by_le(count) attribute for the
flexible data array. If the firmware returns a short read or encounters an
error, it updates the count field to the actual number of words returned.
If count is reduced by the firmware, does this memcpy attempt to copy the
original requested size (bytes), exceeding the dynamically evaluated bounds
of fwbuf->data?
> +
> +out:
> + kfree(fwbuf);
> + return ret;
> +}
[ ... ]
> +static int rpi_otp_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct nvmem_device *nvmem;
> + struct rpi_otp_priv *priv;
> + const struct rpi_otp_driver_data *data;
> + struct nvmem_config config = {
> + .read_only = false,
[Severity: Medium]
Will this allow silent write failures on read-only OTP regions?
If a region (like the device-specific private key OTP) is read-only and
lacks a valid write_tag in the platform data, write_tag will be 0. When
rpi_otp_write() sends tag 0 (which corresponds to RPI_FIRMWARE_PROPERTY_END)
to the firmware, it interprets this as an empty property list and returns
success without writing any data.
Should the read_only flag be set dynamically based on whether a valid
write_tag is provided?
> + .word_size = 4,
> + .stride = 4,
> + .reg_read = rpi_otp_read,
> + .reg_write = rpi_otp_write,
> + .id = NVMEM_DEVID_NONE,
> + };
> +
> + data = dev_get_platdata(dev);
> + if (!data)
> + return -ENODEV;
> +
> + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + priv->fw = dev_get_drvdata(dev->parent);
> + priv->read_tag = data->read_tag;
> + priv->write_tag = data->write_tag;
> + config.dev = dev;
> + config.priv = priv;
> + config.name = data->name;
> + config.size = data->size;
> + config.root_only = data->root_only;
> +
> + nvmem = devm_nvmem_register(dev, &config);
[Severity: High]
Could this lead to a use-after-free if an external consumer holds a
reference to the nvmem device after the driver unbinds?
The driver allocates the priv context using devm_kzalloc() and registers the
nvmem provider via devm_nvmem_register(). During driver unbind, devres cleans
up in reverse order: nvmem_unregister() is called, which drops the internal
kref, and then the priv memory is freed.
If an in-kernel consumer has acquired the nvmem device (e.g., via
nvmem_device_get()), the refcount remains greater than zero and the nvmem
device stays alive after priv is freed. If the consumer subsequently calls a
read or write operation, will rpi_otp_read() or rpi_otp_write() dereference
the freed priv pointer?
> + if (IS_ERR(nvmem))
> + return dev_err_probe(dev, PTR_ERR(nvmem), "error registering nvmem config\n");
> +
> + return 0;
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260522-rpi-otp-driver-v6-0-b0eac97d1428@linutronix.de?part=4
^ permalink raw reply
* Re: [PATCH v5 12/13] Documentation: ABI: testing: add docs for ad9910 sysfs entries
From: Jonathan Cameron @ 2026-05-22 18:20 UTC (permalink / raw)
To: Rodrigo Alencar
Cc: rodrigo.alencar, linux-iio, devicetree, linux-kernel, linux-doc,
linux-hardening, Lars-Peter Clausen, Michael Hennerich,
David Lechner, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Jonathan Corbet, Shuah Khan,
Kees Cook, Gustavo A. R. Silva
In-Reply-To: <vqqvn2cgs3fbp5mq6xfac7iyosaqfrvgngqur4x355a3at7slo@ylrtd6fhi33a>
On Wed, 20 May 2026 19:47:25 +0100
Rodrigo Alencar <455.rodrigo.alencar@gmail.com> wrote:
> On 26/05/17 07:37PM, Rodrigo Alencar via B4 Relay wrote:
> > From: Rodrigo Alencar <rodrigo.alencar@analog.com>
> >
> > Add custom ABI documentation file for the DDS AD9910 with sysfs entries to
> > control Parallel Port, Digital Ramp Generator and OSK parameters.
>
> ...
>
> > +What: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_frequency_offset
> > +KernelVersion:
> > +Contact: linux-iio@vger.kernel.org
> > +Description:
> > + For a channel that allows frequency control through buffers, this
> > + represents the base frequency value in Hz. The actual output frequency
> > + is derived from this offset combined with the processed buffer sample
> > + value.
> > +
> > +What: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_frequency_scale
> > +KernelVersion:
> > +Contact: linux-iio@vger.kernel.org
> > +Description:
> > + For a channel that allows frequency control through buffers, this
> > + represents the frequency modulation gain. This value multiplies the
> > + buffer input sample value before it is added to a frequency offset.
> > +
> > +What: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_phase_offset
> > +KernelVersion:
> > +Contact: linux-iio@vger.kernel.org
> > +Description:
> > + For a channel that allows phase control through buffers, this
> > + represents the base phase value in radians. The actual output phase is
> > + derived from this offset combined with the processed buffer sample
> > + value.
> > +
> > +What: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_scale_offset
> > +KernelVersion:
> > +Contact: linux-iio@vger.kernel.org
> > +Description:
> > + For a channel that allows amplitude control through buffers, this
> > + represents the value for a base amplitude scale. The actual output
> > + amplitude scale is derived from this offset combined with the processed
> > + buffer sample value.
> > +
>
> This will become just offset with altcurrent channels. I noticed we have a IIO_PHASE
> iio_chan_type, could we have a IIO_FREQUENCY too? Parallel port needs actual raw
> frequency values in that case to be written to the dma buffer.
>
Sure to IIO_FREQUENCY. I thought we already did but seems not!
The Phase one is a bit special given it's use in resolvers and distance sensors
but perhaps it is the right solution here.
> Then we may have buffer capable channels for the parallel port:
>
> out_altcurrent120
> offset
So that's the amplitude envelope control.
> out_phase120
> offset
So this is the phase adjustment being controlled.
> out_frequency120
And this is the frequency being controlled.
> scale
> offset
>
> Problem is that the math for the actual frequency output is:
>
> f_OUT = f_FTW + (f_RAW * FM)
>
> where f_FTW is a base frequency (already scaled), FM is a
> modulation gain and f_RAW is the contribution from the parallel
> port, which is the already scaled:
>
> f_RAW = RAW * f_SYSCLK / 2^32
> f_FTW = FTW * f_SYSCLK / 2^32
>
> so the above becomes:
>
> f_OUT = (FTW * f_SYSCLK / 2^32) + (RAW * f_SYSCLK / 2^32) * FM
> f_OUT = (FTW/FM + RAW) * f_SYSCLK * FM / 2^32
>
> if I make:
>
> SCALE = f_SYSCLK * FM / 2^32
> OFFSET = FTW/FM
> f_OUT = (OFFSET + RAW) * SCALE
>
> That would work for a IIO_FREQUENCY channel type, problem is that both
> scale and offset would depend on the modulation gain (FM)... I suppose
> scale should be setting that and offset assumes it is constant to act
> only on FTW.
I'm not that concerned about the coupling - it's a bit of a useability
issue I guess as not obvious which should be the fixed one. Can we do
cache written values and try and compensate to get a pair that is nearest
to whatever we try to drive (in either order of setting them?)
>
> I suppose we can keep altcurrent for other modes as phase and frequency
> can be attributes (knobs) for them. However, in parallel mode we are effectively
> pushing frequency, phase or amplitude values into the buffer.
Given that's the thing we are controlling. My Friday evening tired brain agrees
that it makes sense to use channel types rather than adjustments on something else.
I'll think some more on this. We've never had continuous (well digital
so near continous) control of either phase or frequency before - it's just
be symbol stuff with a couple of points to set.
>
> The polar destination is a corner case, but can be solved when both
> phase and altcurrent channels are enabled. When that happens we can
> change the scan_type with has_ext_scan_type = 1, so the 16-bit data
> bus is split between the two.
>
For now I'll just nod at that!
> With the above, all of those *_offset and *_scale custom ABI can be dropped.
That is definitely attractive :)
Jonathan
>
^ permalink raw reply
* Re: [PATCH 3/3] arm64: dts: rockchip: Add Axelera AI metis-sbc
From: sashiko-bot @ 2026-05-22 18:21 UTC (permalink / raw)
To: Patrick Barsanti; +Cc: conor+dt, robh, devicetree
In-Reply-To: <20260522174918.61523-4-patrick.barsanti@amarulasolutions.com>
Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:
- [High] The `&hdmi0` node mixes HDMI M0 and M1 pinmux groups for its pins, which will cause the HDMI controller to miss Hot-Plug Detection (HPD) signals.
- [Medium] The `&sdhci` (eMMC) node specifies `full-pwr-cycle-in-suspend` but lacks the required `vmmc-supply` and `vqmmc-supply` regulator assignments, and the underlying PMIC supplies are not configured to turn off in suspend.
- [Medium] The `pmic@0` (RK806) node lacks a `pinctrl` assignment for its interrupt pin.
- [Medium] The `vcc3v3_hubreset` regulator is used as a hack to release a USB hub reset GPIO, and is incorrectly passed as the `phy-supply` to `&usbdp_phy1` while being marked as `regulator-always-on` and `regulator-boot-on`.
- [Low] The `vbus5v0_typec` and `vcc_3v3_sd_s0` regulators are defined but never referenced by any consumer node in the device tree, and lack the `regulator-always-on` property.
--
commit 4aee50a229d0828f7f68b373236eeefdfcd2b1b8
Author: Patrick Barsanti <patrick.barsanti@amarulasolutions.com>
arm64: dts: rockchip: Add Axelera AI metis-sbc
Add minimal device tree for the Axelera AI Metis Compute Board
(rk3588-metis-sbc).
Link: https://axelera.ai/evaluation-systems/metis-compute-board
> diff --git a/arch/arm64/boot/dts/rockchip/rk3588-metis-sbc.dts b/arch/arm64/boot/dts/rockchip/rk3588-metis-sbc.dts
> new file mode 100644
> index 0000000000000..56d734f9f25bc
> --- /dev/null
> +++ b/arch/arm64/boot/dts/rockchip/rk3588-metis-sbc.dts
> @@ -0,0 +1,840 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +
> +/dts-v1/;
> +
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/input/input.h>
> +#include <dt-bindings/pinctrl/rockchip.h>
> +#include <dt-bindings/soc/rockchip,vop2.h>
> +#include "rk3588.dtsi"
> +
> +/ {
> + model = "Axelera AI Metis Compute Board";
> + compatible = "axelera,metis-sbc", "rockchip,rk3588";
[ ... ]
> + vbus5v0_typec: vbus5v0-typec {
> + compatible = "regulator-fixed";
> + enable-active-high;
> + gpio = <&gpio4 RK_PB4 GPIO_ACTIVE_HIGH>; /* TYPEC5V_PWREN */
> + pinctrl-0 = <&typec5v_pwren>;
> + pinctrl-names = "default";
> + regulator-name = "usbc_ss_vbus";
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + vin-supply = <&vcc5v0_sus>;
> + };
[Severity: Low]
Are this regulator and vcc_3v3_sd_s0 actually used anywhere?
They lack the regulator-always-on property and are never referenced by any
consumer node in the device tree, which means the regulator framework will
never enable them.
[ ... ]
> + vcc_3v3_sd_s0: vcc-3v3-sd-s0 {
> + compatible = "regulator-fixed";
> + enable-active-high;
> + gpio = <&gpio0 RK_PC5 GPIO_ACTIVE_HIGH>; /* SDMMC_PWREN */
> + pinctrl-0 = <&sdmmc_pwren>;
> + pinctrl-names = "default";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-name = "vsd_3v3";
> + startup-delay-us = <1000000>;
> + vin-supply = <&vcc_3v3_s3>;
> + };
[Severity: Low]
Similar to vbus5v0_typec, is this regulator actually utilized?
It appears to be unreferenced dead code since it is not marked as always
on and is not linked to any consumer node.
[ ... ]
> + vcc3v3_hubreset: vcc3v3-hubreset {
> + compatible = "regulator-fixed";
> + enable-active-high;
> + gpio = <&gpio3 RK_PB2 GPIO_ACTIVE_HIGH>; /* USB_HUB_RST_N */
> + pinctrl-0 = <&usb_hub_rst_n>;
> + pinctrl-names = "default";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-name = "vcc3v3_hubreset";
> + vin-supply = <&vcc_3v3_s3>;
> + };
[Severity: Medium]
Does marking this regulator with regulator-always-on and regulator-boot-on
defeat the intended reset sequencing mechanism?
It looks like this regulator is used to control a reset line for the
downstream hub and is later referenced as phy-supply in &usbdp_phy1 to allow
the PHY driver to sequence the reset. However, keeping it always on forces
the reset line to be de-asserted immediately at boot before the PHY driver
is ready, which can cause the hub to fail enumeration.
[ ... ]
> +&hdmi0 {
> + pinctrl-0 = <&hdmim0_tx0_cec &hdmim0_tx0_hpd_sbc &hdmim0_tx0_scl &hdmim0_tx0_sda>;
> + pinctrl-names = "default";
> + status = "okay";
> +};
[ ... ]
> + hdmi {
> + hdmim0_tx0_hpd_sbc: hdmim0-tx0-hpd-sbc {
> + rockchip,pins = <3 RK_PD4 3 &pcfg_pull_none>;
> + };
> + };
[Severity: High]
Does mixing HDMI M0 and M1 pinmux groups break display hot-plug detection?
The hdmi0 node uses the M0 hardware pinmux group for CEC, SCL, and SDA, but
hdmim0_tx0_hpd_sbc is mapped to 3 RK_PD4 3, which corresponds to the M1 group.
Since Rockchip SoCs configure IOMUX routing globally for a peripheral via GRF,
and the controller is routed to the M0 group for CEC/I2C, won't the M1 HPD pin
be electrically ignored?
[ ... ]
> +&sdhci {
> + bus-width = <8>;
> + max-frequency = <200000000>;
> + mmc-hs400-1_8v;
> + mmc-hs400-enhanced-strobe;
> + no-sd;
> + no-sdio;
> + non-removable;
> + full-pwr-cycle-in-suspend;
> + status = "okay";
> +};
[Severity: Medium]
Without explicit vmmc-supply and vqmmc-supply regulator assignments, can this
full-pwr-cycle-in-suspend property cause eMMC resume failures?
Because the underlying vcc_3v3_s3 regulator is configured with
regulator-on-in-suspend, power will not actually be removed during suspend.
Upon resume, the MMC core will attempt a full re-initialization expecting the
card to be idle, but since the card never lost power, the re-initialization
might fail.
[ ... ]
> +&spi2 {
> + assigned-clock-rates = <200000000>;
> + assigned-clocks = <&cru CLK_SPI2>;
> + num-cs = <1>;
> + pinctrl-0 = <&spi2m2_cs0 &spi2m2_pins>;
> + pinctrl-names = "default";
> + status = "okay";
> +
> + pmic@0 {
> + compatible = "rockchip,rk806";
> + reg = <0x0>;
> + interrupt-parent = <&gpio0>;
> + interrupts = <RK_PA7 IRQ_TYPE_LEVEL_LOW>; /* PMIC_INT_L */
> + spi-max-frequency = <1000000>;
> + system-power-controller;
[Severity: Medium]
Should there be a pinctrl assignment for the PMIC interrupt pin?
Relying entirely on the bootloader's default pin configuration could result
in the pin being left floating or misconfigured as an output, which can lead
to missed or spurious PMIC interrupts and power management failures.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260522174918.61523-1-patrick.barsanti@amarulasolutions.com?part=3
^ permalink raw reply
* Re: [PATCH net-next v8 10/10] net: airoha: Support multiple LAN/WAN interfaces for hw MAC address configuration
From: Jakub Kicinski @ 2026-05-22 18:25 UTC (permalink / raw)
To: Lorenzo Bianconi; +Cc: sashiko-reviews, robh, devicetree, conor+dt, netdev
In-Reply-To: <ag2t4eVe4DcfU2yZ@lore-desk>
On Wed, 20 May 2026 14:49:37 +0200 Lorenzo Bianconi wrote:
> > Does this strict OUI validation cause the driver probe to fail when MAC addresses
> > are randomly generated?
> >
> > If a MAC address is not provided in the device tree, the driver generates a random
> > one via eth_hw_addr_random(). For multi-port configurations, each port receives an
> > independently generated random MAC address.
> >
> > Since the upper 3 bytes of these random addresses will almost certainly differ,
> > when register_netdev() is called for the second port, its ndo_init callback
> > (airoha_dev_init) will invoke airoha_set_macaddr() and hit this check. Returning
> > -EINVAL will fail register_netdev() and abort the entire driver probe, leaving
> > the system without networking.
> >
> > Does this also prevent users from changing the MAC address OUI?
> >
> > When an administrator attempts to change the MAC address via standard userspace
> > tools, only one interface can be modified at a time. The driver will compare the
> > new MAC against the existing MAC of the other port.
> >
> > If the MSBs differ, the change is rejected. This makes it impossible to atomically
> > change the OUI of both interfaces simultaneously, locking the MAC address OUI
> > to its initial probe-time value.
>
> As pointed out before, this is a hw design requirement when multiple
> net_devices are configured as LAN.
What about Clashiko report about the MAC address?
^ permalink raw reply
* Re: [PATCH v4 2/3] dt-bindings: wire style checker into dt_binding_check
From: sashiko-bot @ 2026-05-22 18:36 UTC (permalink / raw)
To: Daniel Golle; +Cc: devicetree, robh, conor+dt
In-Reply-To: <93923232b32423d33dc3b6632165ccc9571dea8f.1779472837.git.daniel@makrotopia.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The style checker's exit code is silently swallowed by the `jobserver-exec` wrapper, causing the Make target to falsely cache failed runs as successful.
--
commit d2626a1d6568000139a4bc557d46c27f248fcea9
Author: Daniel Golle <daniel@makrotopia.org>
dt-bindings: wire style checker into dt_binding_check
This commit adds the dt-check-style tool to the dt_binding_check_one target
to enforce relaxed style checks on the device tree bindings. It uses
scripts/jobserver-exec to constrain the worker count based on the GNU make
jobserver.
> diff --git a/Documentation/devicetree/bindings/Makefile b/Documentation/devicetree/bindings/Makefile
> index 7b668f7fd4007..00149e8242611 100644
> --- a/Documentation/devicetree/bindings/Makefile
> +++ b/Documentation/devicetree/bindings/Makefile
[ ... ]
> @@ -46,6 +46,18 @@ quiet_cmd_chk_bindings = CHKDT $(src)
> xargs -n200 -P$$(nproc) $(DT_DOC_CHECKER) -u $(src)) \
> && touch $@ || true
>
> +DT_CHK_STYLE = $(srctree)/scripts/dtc/dt-check-style
> +
> +# Feed the file list to the checker via @argfile in a single Python
> +# process so the ruamel.yaml import is paid once. scripts/jobserver-exec
> +# claims slots from the GNU make jobserver and exposes the count via
> +# $PARALLELISM, which dt-check-style picks up to size its worker pool.
> +quiet_cmd_chk_style = STYLE $(src)
> + cmd_chk_style = f=$$(mktemp) && $(find_cmd) > $$f && \
> + $(PYTHON3) $(srctree)/scripts/jobserver-exec \
> + $(PYTHON3) $(DT_CHK_STYLE) @$$f \
> + && touch $@ || true; rm -f $$f
[Severity: Low]
Does this wrapper silently swallow the style checker's exit code?
The main() function in scripts/jobserver-exec does not appear to pass the
subprocess exit code returned by jobserver.run() to sys.exit(). Because the
script always implicitly exits with status 0, the && touch $@ command
will execute unconditionally even if the style checker detects violations and
exits with a non-zero code.
This will erroneously create the .dt-style.checked stamp file, caching the
failed check as successful and hiding warnings on subsequent runs until the
files are modified again.
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1779472837.git.daniel@makrotopia.org?part=2
^ permalink raw reply
* Re: [PATCH v4 05/12] rvtrace: Add trace encoder driver
From: Sergey Matyukevich @ 2026-05-22 18:46 UTC (permalink / raw)
To: Anup Patel
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Palmer Dabbelt,
Paul Walmsley, Greg KH, Alexander Shishkin, Ian Rogers,
Alexandre Ghiti, Peter Zijlstra, Ingo Molnar, Namhyung Kim,
Mark Rutland, Jiri Olsa, Adrian Hunter, Mayuresh Chitale,
Anup Patel, Atish Patra, Andrew Jones, Sunil V L, linux-riscv,
devicetree, linux-kernel, Mayuresh Chitale
In-Reply-To: <20260429125135.1983498-6-anup.patel@oss.qualcomm.com>
Hi,
> From: Mayuresh Chitale <mayuresh.chitale@oss.qualcomm.com>
>
> Add initial implementation of RISC-V trace encoder driver. The encoder
> is defined in the RISC-V Trace Control Interface specification.
>
> Co-developed-by: Anup Patel <anup.patel@oss.qualcomm.com>
> Signed-off-by: Anup Patel <anup.patel@oss.qualcomm.com>
> Signed-off-by: Mayuresh Chitale <mayuresh.chitale@oss.qualcomm.com>
> ---
> drivers/hwtracing/rvtrace/Kconfig | 7 ++
> drivers/hwtracing/rvtrace/Makefile | 1 +
> drivers/hwtracing/rvtrace/rvtrace-encoder.c | 130 ++++++++++++++++++++
> 3 files changed, 138 insertions(+)
> create mode 100644 drivers/hwtracing/rvtrace/rvtrace-encoder.c
...
> +static int rvtrace_encoder_start(struct rvtrace_component *comp)
> +{
> + int ret;
> + u32 val;
> +
> + val = rvtrace_read32(comp->pdata, RVTRACE_COMPONENT_CTRL_OFFSET);
> + val |= BIT(RVTRACE_COMPONENT_CTRL_ENABLE_SHIFT);
> + rvtrace_write32(comp->pdata, val, RVTRACE_COMPONENT_CTRL_OFFSET);
> + ret = rvtrace_poll_bit(comp->pdata, RVTRACE_COMPONENT_CTRL_OFFSET,
> + RVTRACE_COMPONENT_CTRL_ENABLE_SHIFT, 1,
> + comp->pdata->control_poll_timeout_usecs);
IIUC the code fragment above duplicates 'rvtrace_enable_component' from
rvtrace-core.c.
> + if (ret) {
> + dev_err(&comp->dev, "failed to enable encoder.\n");
> + return ret;
> + }
> +
> + /* set mode */
> + val = rvtrace_read32(comp->pdata, RVTRACE_COMPONENT_CTRL_OFFSET);
> + val |= (RVTRACE_COMPONENT_CTRL_INSTMODE_OPIT << RVTRACE_COMPONENT_CTRL_INSTMODE_SHIFT);
> + rvtrace_write32(comp->pdata, val, RVTRACE_COMPONENT_CTRL_OFFSET);
> +
> + val = rvtrace_read32(comp->pdata, RVTRACE_COMPONENT_CTRL_OFFSET);
> + val |= BIT(RVTRACE_COMPONENT_CTRL_ITRACE_SHIFT);
> + rvtrace_write32(comp->pdata, val, RVTRACE_COMPONENT_CTRL_OFFSET);
> + ret = rvtrace_poll_bit(comp->pdata, RVTRACE_COMPONENT_CTRL_OFFSET,
> + RVTRACE_COMPONENT_CTRL_ITRACE_SHIFT, 1,
> + comp->pdata->control_poll_timeout_usecs);
> + if (ret)
> + dev_err(&comp->dev, "failed to enable tracing.\n");
> +
> + return ret;
> +}
> +
> +static int rvtrace_encoder_stop(struct rvtrace_component *comp)
> +{
> + int ret;
> + u32 val;
> +
> + val = rvtrace_read32(comp->pdata, RVTRACE_COMPONENT_CTRL_OFFSET);
> + val &= ~BIT(RVTRACE_COMPONENT_CTRL_ITRACE_SHIFT);
> + rvtrace_write32(comp->pdata, val, RVTRACE_COMPONENT_CTRL_OFFSET);
> + ret = rvtrace_poll_bit(comp->pdata, RVTRACE_COMPONENT_CTRL_OFFSET,
> + RVTRACE_COMPONENT_CTRL_ITRACE_SHIFT, 0,
> + comp->pdata->control_poll_timeout_usecs);
> + if (ret) {
> + dev_err(&comp->dev, "failed to stop tracing.\n");
> + return ret;
> + }
> +
> + val = rvtrace_read32(comp->pdata, RVTRACE_COMPONENT_CTRL_OFFSET);
> + val &= ~BIT(RVTRACE_COMPONENT_CTRL_ENABLE_SHIFT);
> + rvtrace_write32(comp->pdata, val, RVTRACE_COMPONENT_CTRL_OFFSET);
> + ret = rvtrace_poll_bit(comp->pdata, RVTRACE_COMPONENT_CTRL_OFFSET,
> + RVTRACE_COMPONENT_CTRL_ENABLE_SHIFT, 0,
> + comp->pdata->control_poll_timeout_usecs);
IIUC the code fragment above duplicates 'rvtrace_disable_component' from
rvtrace-core.c.
> + if (ret) {
> + dev_err(&comp->dev, "failed to disable encoder.\n");
> + return ret;
> + }
> +
> + return rvtrace_comp_poll_empty(comp);
> +}
Regards,
Sergey
^ permalink raw reply
* Re: [PATCH v4 07/12] rvtrace: Add trace ramsink driver
From: Sergey Matyukevich @ 2026-05-22 18:48 UTC (permalink / raw)
To: Anup Patel
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Palmer Dabbelt,
Paul Walmsley, Greg KH, Alexander Shishkin, Ian Rogers,
Alexandre Ghiti, Peter Zijlstra, Ingo Molnar, Namhyung Kim,
Mark Rutland, Jiri Olsa, Adrian Hunter, Mayuresh Chitale,
Anup Patel, Atish Patra, Andrew Jones, Sunil V L, linux-riscv,
devicetree, linux-kernel, Mayuresh Chitale
In-Reply-To: <20260429125135.1983498-8-anup.patel@oss.qualcomm.com>
> From: Mayuresh Chitale <mayuresh.chitale@oss.qualcomm.com>
>
> Add initial implementation of RISC-V trace ramsink driver. The ramsink
> is defined in the RISC-V Trace Control Interface specification.
>
> Co-developed-by: Anup Patel <anup.patel@oss.qualcomm.com>
> Signed-off-by: Anup Patel <anup.patel@oss.qualcomm.com>
> Signed-off-by: Mayuresh Chitale <mayuresh.chitale@oss.qualcomm.com>
> ---
> drivers/hwtracing/rvtrace/Kconfig | 9 +
> drivers/hwtracing/rvtrace/Makefile | 1 +
> drivers/hwtracing/rvtrace/rvtrace-ramsink.c | 338 ++++++++++++++++++++
> 3 files changed, 348 insertions(+)
> create mode 100644 drivers/hwtracing/rvtrace/rvtrace-ramsink.c
...
> +static int rvtrace_ramsink_start(struct rvtrace_component *comp)
> +{
> + int ret;
> + u32 val;
> +
> + val = rvtrace_read32(comp->pdata, RVTRACE_COMPONENT_CTRL_OFFSET);
> + val |= BIT(RVTRACE_COMPONENT_CTRL_ENABLE_SHIFT);
> + rvtrace_write32(comp->pdata, val, RVTRACE_COMPONENT_CTRL_OFFSET);
> + ret = rvtrace_poll_bit(comp->pdata, RVTRACE_COMPONENT_CTRL_OFFSET,
> + RVTRACE_COMPONENT_CTRL_ENABLE_SHIFT, 1,
> + comp->pdata->control_poll_timeout_usecs);
IIUC the code fragment above duplicates 'rvtrace_enable_component' from
rvtrace-core.c.
> + if (ret)
> + dev_err(&comp->dev, "failed to start ramsink.\n");
> +
> + return ret;
> +}
> +
> +static int rvtrace_ramsink_stop(struct rvtrace_component *comp)
> +{
> + int ret;
> + u32 val;
> +
> + val = rvtrace_read32(comp->pdata, RVTRACE_COMPONENT_CTRL_OFFSET);
> + val &= ~BIT(RVTRACE_COMPONENT_CTRL_ENABLE_SHIFT);
> + rvtrace_write32(comp->pdata, val, RVTRACE_COMPONENT_CTRL_OFFSET);
> + ret = rvtrace_poll_bit(comp->pdata, RVTRACE_COMPONENT_CTRL_OFFSET,
> + RVTRACE_COMPONENT_CTRL_ENABLE_SHIFT, 0,
> + comp->pdata->control_poll_timeout_usecs);
IIUC the code fragment above duplicates 'rvtrace_disable_component' from
rvtrace-core.c.
> + if (ret) {
> + dev_err(&comp->dev, "failed to stop ramsink.\n");
> + return ret;
> + }
> +
> + return rvtrace_comp_poll_empty(comp);
> +}
Regards,
Sergey
^ permalink raw reply
* Re: [PATCH v3 3/5] arm64: dts: qcom: Add Shikra CQ2390M SoM platform
From: sashiko-bot @ 2026-05-22 19:10 UTC (permalink / raw)
To: Komal Bajaj
Cc: devicetree, linux-phy, neil.armstrong, conor+dt, olteanv, vkoul,
robh
In-Reply-To: <20260522-shikra-dt-v3-3-80ffde8a3dc4@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The commit message claims to add PM8005 PMIC regulator definitions, but the patch explicitly disables the PM8005 regulators and provides no configuration.
--
commit b8207cdfd80924e291ee52448a105708aa7b6a09
Author: Komal Bajaj <komal.bajaj@oss.qualcomm.com>
arm64: dts: qcom: Add Shikra CQ2390M SoM platform
This commit adds the device tree include for the CQ2390M variant of the
Shikra System-on-Module. It integrates the Shikra SoC and includes PMIC
regulator configurations for the retail SoM.
> The DTSI includes the common shikra.dtsi, adds PM4125 and PM8005 PMIC
> regulator definitions specific to this variant.
[ ... ]
> diff --git a/arch/arm64/boot/dts/qcom/shikra-cqm-som.dtsi b/arch/arm64/boot/dts/qcom/shikra-cqm-som.dtsi
> new file mode 100644
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/shikra-cqm-som.dtsi
[ ... ]
> +&pm8005_regulators {
> + status = "disabled";
> +};
[Severity: Medium]
Is the commit message inaccurate, or are the definitions for the PM8005
regulators missing from this patch?
The commit message states that PM8005 PMIC regulator definitions are
added, but the code explicitly disables them without providing any
configuration. If the SoM variant requires the PM8005 regulators to power
hardware components, will leaving them disabled result in runtime failures?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260522-shikra-dt-v3-0-80ffde8a3dc4@oss.qualcomm.com?part=3
^ permalink raw reply
* Re: [PATCH net-next v8 10/10] net: airoha: Support multiple LAN/WAN interfaces for hw MAC address configuration
From: Lorenzo Bianconi @ 2026-05-22 19:25 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: sashiko-reviews, robh, devicetree, conor+dt, netdev
In-Reply-To: <20260522112514.1ad6e947@kicinski-fedora-PF5CM1Y0>
[-- Attachment #1: Type: text/plain, Size: 3538 bytes --]
On May 22, Jakub Kicinski wrote:
> On Wed, 20 May 2026 14:49:37 +0200 Lorenzo Bianconi wrote:
> > > Does this strict OUI validation cause the driver probe to fail when MAC addresses
> > > are randomly generated?
> > >
> > > If a MAC address is not provided in the device tree, the driver generates a random
> > > one via eth_hw_addr_random(). For multi-port configurations, each port receives an
> > > independently generated random MAC address.
> > >
> > > Since the upper 3 bytes of these random addresses will almost certainly differ,
> > > when register_netdev() is called for the second port, its ndo_init callback
> > > (airoha_dev_init) will invoke airoha_set_macaddr() and hit this check. Returning
> > > -EINVAL will fail register_netdev() and abort the entire driver probe, leaving
> > > the system without networking.
> > >
> > > Does this also prevent users from changing the MAC address OUI?
> > >
> > > When an administrator attempts to change the MAC address via standard userspace
> > > tools, only one interface can be modified at a time. The driver will compare the
> > > new MAC against the existing MAC of the other port.
> > >
> > > If the MSBs differ, the change is rejected. This makes it impossible to atomically
> > > change the OUI of both interfaces simultaneously, locking the MAC address OUI
> > > to its initial probe-time value.
> >
> > As pointed out before, this is a hw design requirement when multiple
> > net_devices are configured as LAN.
>
> What about Clashiko report about the MAC address?
Do you the following one?
https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260519-airoha-eth-multi-serdes-v8-0-6bd70e329df6%40kernel.org
- What happens when device tree does not provide MAC addresses for two or
more same-side GDM interfaces?
- This is the same comment reported in [0].
Since the hw exposes just a single register (REG_FE_LAN_MAC_H or
REG_FE_WAN_MAC_H) for the LAN/WAN mac address MSBs, we need to
require all the interfaces configured as LAN or WAN to share the
mac address MSBs and the user needs to select the new mac address
observing this limitation.
Please note this limitation is only valid if multiple net_devices
are configured as LAN (or WAN). Since in the current codebase we
do not support multiple interfaces configured as LAN or WAN, we are
not introducing any regression.
I do not think selecting a "base" for the mac address is helpful
if the user does not provide the mac address via the DTS or NVME
(as suggested by sashiko) since it will not help us if the mac
addresses configured via DTS are "wrong" (if they do not respect
the limitation described above). What do you think?
- If airoha_set_macaddr() succeeds (and has just widened the shared
[lmin, lmax] range to include this dev) and airoha_set_gdm2_loopback()
then fails, airoha_dev_init() returns the error but there is no
airoha_dev_uninit / ndo_uninit to roll the LMIN/LMAX update back.
The shared range is then wider than the set of currently-registered peers.
- I guess it is not harmful to keep the already configured mac address
range if airoha_set_gdm2_loopback() fails and I decided to not unwind
the changes to keep the code simple. Moreover, in the current codebase,
if ndo_init() fails, the airoha_probe() will fail.
Regards,
Lorenzo
[0] https://sashiko.dev/#/patchset/20260519-airoha-eth-multi-serdes-v8-0-6bd70e329df6%40kernel.org
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v8 01/10] dt-bindings: net: airoha: Add GDM port ethernet child node
From: Lorenzo Bianconi @ 2026-05-22 19:27 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Christian Marangi, Benjamin Larsson, linux-arm-kernel,
linux-mediatek, netdev, devicetree
In-Reply-To: <20260519-airoha-eth-multi-serdes-v8-1-6bd70e329df6@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 3315 bytes --]
> EN7581 and AN7583 SoCs support connecting multiple external SerDes to GDM3
> or GDM4 ports via a hw arbiter that manages the traffic in a TDM manner.
> As a result multiple net_devices can connect to the same GDM{3,4} port
> and there is a theoretical "1:n" relation between GDM ports and
> net_devices.
> Introduce the ethernet node child of a specific GDM port in order to model
> a given net_device that is connected via the external arbiter to the
> GDM{3,4} port. This new ethernet node is defined by the "airoha,eth-port"
> compatible string. Please note GDM1 and GDM2 does not support the
> connection with the external arbiter and they are represented by an
> ethernet node defined by the "airoha,eth-mac" compatible string.
Hi Rob, Krzysztof and Conor,
do you have any comment about this patch? Thanks in advance.
Regards,
Lorenzo
>
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> ---
> .../devicetree/bindings/net/airoha,en7581-eth.yaml | 56 +++++++++++++++++++++-
> 1 file changed, 55 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/net/airoha,en7581-eth.yaml b/Documentation/devicetree/bindings/net/airoha,en7581-eth.yaml
> index fbe2ddcdd909..17fe2edf4886 100644
> --- a/Documentation/devicetree/bindings/net/airoha,en7581-eth.yaml
> +++ b/Documentation/devicetree/bindings/net/airoha,en7581-eth.yaml
> @@ -130,6 +130,42 @@ patternProperties:
> maximum: 4
> description: GMAC port identifier
>
> + allOf:
> + - if:
> + properties:
> + reg:
> + contains:
> + items:
> + - enum:
> + - 3
> + - 4
> + then:
> + properties:
> + '#address-cells':
> + const: 1
> +
> + '#size-cells':
> + const: 0
> +
> + patternProperties:
> + "^ethernet@[0-5]$":
> + type: object
> + unevaluatedProperties: false
> + $ref: ethernet-controller.yaml#
> + description: External ethernet port ID available on the GDM port
> +
> + properties:
> + compatible:
> + const: airoha,eth-port
> +
> + reg:
> + maximum: 5
> + description: External ethernet port identifier
> +
> + required:
> + - reg
> + - compatible
> +
> required:
> - reg
> - compatible
> @@ -191,9 +227,27 @@ examples:
> #address-cells = <1>;
> #size-cells = <0>;
>
> - mac: ethernet@1 {
> + ethernet@1 {
> compatible = "airoha,eth-mac";
> reg = <1>;
> };
> +
> + ethernet@4 {
> + compatible = "airoha,eth-mac";
> + reg = <4>;
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ethernet@0 {
> + compatible = "airoha,eth-port";
> + reg = <0>;
> + };
> +
> + ethernet@1 {
> + compatible = "airoha,eth-port";
> + reg = <1>;
> + };
> + };
> };
> };
>
> --
> 2.54.0
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v3 5/5] arm64: dts: qcom: Add Shikra EVK boards
From: sashiko-bot @ 2026-05-22 19:39 UTC (permalink / raw)
To: Komal Bajaj
Cc: vkoul, devicetree, linux-phy, conor+dt, neil.armstrong, olteanv,
robh
In-Reply-To: <20260522-shikra-dt-v3-5-80ffde8a3dc4@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The device tree file shikra-cqs-evk.dts incorrectly includes the CQM SoM device tree (shikra-cqm-som.dtsi) instead of the expected CQS SoM device tree (shikra-cqs-som.dtsi).
--
commit cb9ff9c76f4ee019113138237f57794fa621d71f
Author: Komal Bajaj <komal.bajaj@oss.qualcomm.com>
arm64: dts: qcom: Add Shikra EVK boards
This commit adds device trees for the Shikra EVK platform, combining
Shikra SoM variants with a common carrier board. It introduces three EVK
boards: CQM (retail with modem), CQS (retail without modem), and IQS
(industrial without modem).
[ ... ]
> diff --git a/arch/arm64/boot/dts/qcom/shikra-cqs-evk.dts b/arch/arm64/boot/dts/qcom/shikra-cqs-evk.dts
> new file mode 100644
> index 0000000000000..b3f19a64d7aed
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/shikra-cqs-evk.dts
> @@ -0,0 +1,40 @@
> +// SPDX-License-Identifier: BSD-3-Clause
> +/*
> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> + */
> +
> +/dts-v1/;
> +
> +#include "shikra-cqm-som.dtsi"
[Severity: High]
The commit message states that shikra-cqs-evk.dts pairs with the CQ2390S
SoM (retail, without modem). Does this file include the incorrect SoM dtsi?
Including shikra-cqm-som.dtsi here seems like it would pull in the hardware
description of the modem-enabled CQM SoM instead of the expected CQS variant.
Could this cause boot issues or lead to loading drivers for hardware that
isn't actually present on the CQS board?
> +#include "shikra-evk.dtsi"
> +
> +/ {
> + model = "Qualcomm Technologies, Inc. Shikra CQS EVK";
> + compatible = "qcom,shikra-cqs-evk", "qcom,shikra-cqs-som", "qcom,shikra";
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260522-shikra-dt-v3-0-80ffde8a3dc4@oss.qualcomm.com?part=5
^ permalink raw reply
* [PATCH v3 00/18] firmware: qcom: scm: Add minidump SRAM destination support
From: Mukesh Ojha @ 2026-05-22 19:49 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
On most Qualcomm SoCs where minidump is supported, a word in always-on
SRAM is shared between the kernel and boot firmware. Before DDR is
initialised on the warm reset following a crash, firmware reads this
word to decide if minidump is enabled and collect a minidump and where
to deliver it (USB upload to a host, or save to local storage).
This series wires that mechanism into the SCM driver:
[1]- The SRAM word location is described via a 'sram' phandle on the
SCM DT node.
[2]- Add minidump-sram pattern property for older soc which supports
minidump destination support.
[3]- Trivial change for consistency.
[4]- A 'minidump_dest' module parameter (default: usb) selects the
destination. Custom kernel_param_ops expose it as the human-
readable strings "usb" or "storage".
[5-18]- Add the support for Kaanapali and other various SoCs.
Changes in v3: https://lore.kernel.org/lkml/20260519171442.1582987-1-mukesh.ojha@oss.qualcomm.com/
- Addressed some code improvement comments.
- Removed example from scm binding.
- Added minidump-sram binding which follows qcom,imem binding.
- Added some more SoCs which supports this .
Changes in v2: https://lore.kernel.org/lkml/20260507080727.3227367-1-mukesh.ojha@oss.qualcomm.com/
- Remove the restriction on the binding change done in v1.
- Remove sram-name from binding.
- sram definition is introduced and merged, so removed the refs from
v1.
- Minor change in the log as per comment s/find/get/
- remove reference of sram-names
- use minidump-sram instead of minidump-config.
Mukesh Ojha (18):
dt-bindings: firmware: qcom,scm: Add minidump SRAM property
dt-bindings: sram: qcom,imem: Add minidump-sram pattern property
firmware: qcom: scm: use dev_err_probe() for dload address failure
firmware: qcom: scm: Add minidump SRAM support
arm64: dts: qcom: kaanapali: Add minidump SRAM config to SCM node
arm64: dts: qcom: sm8450: Add minidump SRAM config to SCM node
arm64: dts: qcom: sa8775p: Add minidump SRAM config to SCM node
arm64: dts: qcom: qcs8300: Add minidump SRAM config to SCM node
arm64: dts: qcom: qdu1000: Add minidump SRAM config to SCM node
arm64: dts: qcom: sm8550: Add minidump SRAM config to SCM node
arm64: dts: qcom: sm8650: Add minidump SRAM config to SCM node
arm64: dts: qcom: sc7280: Add minidump SRAM config to SCM node
arm64: dts: qcom: sm8350: Add minidump SRAM config to SCM node
arm64: dts: qcom: sc7180: Add minidump SRAM config to SCM node
arm64: dts: qcom: sm6350: Add minidump SRAM config to SCM node
arm64: dts: qcom: sm6375: Add minidump SRAM config to SCM node
arm64: dts: qcom: qcs615: Add minidump SRAM config to SCM node
arm64: dts: qcom: sdm845: Add minidump SRAM config to SCM node
.../bindings/firmware/qcom,scm.yaml | 7 ++
.../devicetree/bindings/sram/qcom,imem.yaml | 16 ++++
arch/arm64/boot/dts/qcom/kaanapali.dtsi | 5 +
arch/arm64/boot/dts/qcom/kodiak.dtsi | 5 +
arch/arm64/boot/dts/qcom/lemans.dtsi | 5 +
arch/arm64/boot/dts/qcom/monaco.dtsi | 5 +
arch/arm64/boot/dts/qcom/qdu1000.dtsi | 5 +
arch/arm64/boot/dts/qcom/sc7180.dtsi | 5 +
arch/arm64/boot/dts/qcom/sdm845.dtsi | 5 +
arch/arm64/boot/dts/qcom/sm6350.dtsi | 5 +
arch/arm64/boot/dts/qcom/sm6375.dtsi | 5 +
arch/arm64/boot/dts/qcom/sm8350.dtsi | 5 +
arch/arm64/boot/dts/qcom/sm8450.dtsi | 5 +
arch/arm64/boot/dts/qcom/sm8550.dtsi | 5 +
arch/arm64/boot/dts/qcom/sm8650.dtsi | 5 +
arch/arm64/boot/dts/qcom/talos.dtsi | 5 +
drivers/firmware/qcom/qcom_scm.c | 95 ++++++++++++++++++-
17 files changed, 187 insertions(+), 1 deletion(-)
--
2.53.0
^ permalink raw reply
* [PATCH v3 01/18] dt-bindings: firmware: qcom,scm: Add minidump SRAM property
From: Mukesh Ojha @ 2026-05-22 19:49 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: <20260522195009.2961022-1-mukesh.ojha@oss.qualcomm.com>
On most Qualcomm SoCs where minidump is supported, a word in always-on
SRAM is shared between the kernel and boot firmware. Before DDR is
initialised on the warm reset following a crash, firmware reads this
word to decide if minidump is enabled and collect a minidump and where
to deliver it (USB upload to a host, or save to local storage).
Add a 'sram' property to the SCM binding to describe a region in
always-on SRAM where the minidump download destination value could be
written. Boot firmware reads it before DDR is initialised on a warm
reset to decide where to store the minidump either to host PC or to
on device storage.
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
---
Documentation/devicetree/bindings/firmware/qcom,scm.yaml | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
index 25f62bacbc91..2d68b4065341 100644
--- a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
+++ b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
@@ -129,6 +129,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
+
allOf:
# Clocks
- if:
--
2.53.0
^ permalink raw reply related
* [PATCH v3 02/18] dt-bindings: sram: qcom,imem: Add minidump-sram pattern property
From: Mukesh Ojha @ 2026-05-22 19:49 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: <20260522195009.2961022-1-mukesh.ojha@oss.qualcomm.com>
Add a patternProperty for the minidump-sram child node to the qcom,imem
binding that describes a single word in always-on SRAM shared between
the kernel and boot firmware. Before DDR is initialized on the warm
reset following a crash, firmware reads this word to decide where to
deliver the minidump (USB or on-device storage).
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
---
.../devicetree/bindings/sram/qcom,imem.yaml | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/Documentation/devicetree/bindings/sram/qcom,imem.yaml b/Documentation/devicetree/bindings/sram/qcom,imem.yaml
index c63026904061..17adced6d3a4 100644
--- a/Documentation/devicetree/bindings/sram/qcom,imem.yaml
+++ b/Documentation/devicetree/bindings/sram/qcom,imem.yaml
@@ -67,6 +67,22 @@ properties:
$ref: /schemas/power/reset/syscon-reboot-mode.yaml#
patternProperties:
+ "^minidump-sram@[0-9a-f]+$":
+ type: object
+ description:
+ A word in always-on SRAM shared between the kernel and boot firmware.
+ Before DDR is initialised on the warm reset following a crash, firmware
+ reads this word to decide where to deliver the minidump (USB or storage).
+
+ properties:
+ reg:
+ maxItems: 1
+
+ required:
+ - reg
+
+ additionalProperties: false
+
"^modem-tables@[0-9a-f]+$":
type: object
description:
--
2.53.0
^ permalink raw reply related
* [PATCH v3 03/18] firmware: qcom: scm: use dev_err_probe() for dload address failure
From: Mukesh Ojha @ 2026-05-22 19:49 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, Dmitry Baryshkov
In-Reply-To: <20260522195009.2961022-1-mukesh.ojha@oss.qualcomm.com>
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.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
---
drivers/firmware/qcom/qcom_scm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/firmware/qcom/qcom_scm.c b/drivers/firmware/qcom/qcom_scm.c
index 9b06a69d3a6d..52432469badc 100644
--- a/drivers/firmware/qcom/qcom_scm.c
+++ b/drivers/firmware/qcom/qcom_scm.c
@@ -2747,7 +2747,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);
--
2.53.0
^ permalink raw reply related
* [PATCH v3 04/18] firmware: qcom: scm: Add minidump SRAM support
From: Mukesh Ojha @ 2026-05-22 19:49 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: <20260522195009.2961022-1-mukesh.ojha@oss.qualcomm.com>
On most Qualcomm SoCs where minidump is supported, a word in always-on
SRAM is shared between the kernel and boot firmware. Before DDR is
initialised on the warm reset following a crash, firmware reads this
word to decide if minidump is enabled and collect a minidump and where
to deliver it (USB upload to a host, or save to local storage).
The SRAM region is described by a 'sram' phandle on the SCM DT node.
If the property is absent the feature is silently disabled, keeping
existing SoCs unaffected.
Expose a 'minidump_dest' module parameter (default: usb) so the user can
select the destination. Only the string names "usb" or "storage" are
acceptable values.
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
---
drivers/firmware/qcom/qcom_scm.c | 92 ++++++++++++++++++++++++++++++++
1 file changed, 92 insertions(+)
diff --git a/drivers/firmware/qcom/qcom_scm.c b/drivers/firmware/qcom/qcom_scm.c
index 52432469badc..5276a77834a0 100644
--- a/drivers/firmware/qcom/qcom_scm.c
+++ b/drivers/firmware/qcom/qcom_scm.c
@@ -57,6 +57,7 @@ struct qcom_scm {
int scm_vote_count;
u64 dload_mode_addr;
+ void __iomem *minidump_sram;
struct qcom_tzmem_pool *mempool;
unsigned int wq_cnt;
@@ -141,6 +142,20 @@ static const u8 qcom_scm_cpu_warm_bits[QCOM_SCM_BOOT_MAX_CPUS] = {
#define QCOM_DLOAD_MINIDUMP 2
#define QCOM_DLOAD_BOTHDUMP 3
+/* Minidump destination values written to always-on SRAM for boot firmware */
+#define QCOM_MINIDUMP_DEST_USB 0x0
+#define QCOM_MINIDUMP_DEST_STORAGE 0x2
+
+static u32 minidump_dest = QCOM_MINIDUMP_DEST_USB;
+
+static const struct {
+ const char *name;
+ u32 val;
+} minidump_dest_map[] = {
+ { "usb", QCOM_MINIDUMP_DEST_USB },
+ { "storage", QCOM_MINIDUMP_DEST_STORAGE },
+};
+
#define QCOM_SCM_DEFAULT_WAITQ_COUNT 1
static const char * const qcom_scm_convention_names[] = {
@@ -568,6 +583,14 @@ static void qcom_scm_set_download_mode(u32 dload_mode)
if (ret)
dev_err(__scm->dev, "failed to set download mode: %d\n", ret);
+
+ /*
+ * Write the destination into the always-on SRAM so boot firmware
+ * can read it before DDR is initialised on the next warm reset.
+ * Only written when minidump is active;
+ */
+ if (__scm->minidump_sram && (dload_mode & QCOM_DLOAD_MINIDUMP))
+ writel_relaxed(minidump_dest, __scm->minidump_sram);
}
/**
@@ -2040,6 +2063,29 @@ int qcom_scm_gpu_init_regs(u32 gpu_req)
}
EXPORT_SYMBOL_GPL(qcom_scm_gpu_init_regs);
+static int qcom_scm_map_minidump_sram(struct device *dev, void __iomem **out)
+{
+ struct device_node *np = dev->of_node;
+ struct device_node *sram_np;
+ struct resource res;
+ int ret;
+
+ sram_np = of_parse_phandle(np, "sram", 0);
+ if (!sram_np)
+ return 0;
+
+ ret = of_address_to_resource(sram_np, 0, &res);
+ of_node_put(sram_np);
+ if (ret)
+ return ret;
+
+ *out = devm_ioremap(dev, res.start, resource_size(&res));
+ if (!*out)
+ return -ENOMEM;
+
+ return 0;
+}
+
static int qcom_scm_find_dload_address(struct device *dev, u64 *addr)
{
struct device_node *tcsr;
@@ -2733,6 +2779,47 @@ static const struct kernel_param_ops download_mode_param_ops = {
module_param_cb(download_mode, &download_mode_param_ops, NULL, 0644);
MODULE_PARM_DESC(download_mode, "download mode: off/0/N for no dump mode, full/on/1/Y for full dump mode, mini for minidump mode and full,mini for both full and minidump mode together are acceptable values");
+static int get_minidump_dest(char *buffer, const struct kernel_param *kp)
+{
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(minidump_dest_map); i++)
+ if (minidump_dest == minidump_dest_map[i].val)
+ return sysfs_emit(buffer, "%s\n", minidump_dest_map[i].name);
+
+ return sysfs_emit(buffer, "unknown\n");
+}
+
+static int set_minidump_dest(const char *val, const struct kernel_param *kp)
+{
+ struct qcom_scm *scm;
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(minidump_dest_map); i++)
+ if (sysfs_streq(val, minidump_dest_map[i].name))
+ break;
+
+ if (i >= ARRAY_SIZE(minidump_dest_map))
+ return -EINVAL;
+
+ minidump_dest = minidump_dest_map[i].val;
+
+ /* Pairs with smp_store_release() in qcom_scm_probe(). */
+ scm = smp_load_acquire(&__scm);
+ if (scm && scm->minidump_sram && (download_mode & QCOM_DLOAD_MINIDUMP))
+ writel_relaxed(minidump_dest, scm->minidump_sram);
+
+ return 0;
+}
+
+static const struct kernel_param_ops minidump_dest_param_ops = {
+ .get = get_minidump_dest,
+ .set = set_minidump_dest,
+};
+
+module_param_cb(minidump_dest, &minidump_dest_param_ops, NULL, 0644);
+MODULE_PARM_DESC(minidump_dest, "Minidump SRAM destination: usb (default) or storage");
+
static int qcom_scm_probe(struct platform_device *pdev)
{
struct qcom_tzmem_pool_config pool_config;
@@ -2750,6 +2837,11 @@ static int qcom_scm_probe(struct platform_device *pdev)
return dev_err_probe(&pdev->dev, ret,
"Failed to get download mode address\n");
+ ret = qcom_scm_map_minidump_sram(&pdev->dev, &scm->minidump_sram);
+ if (ret < 0)
+ return dev_err_probe(&pdev->dev, ret,
+ "Failed to map minidump SRAM\n");
+
mutex_init(&scm->scm_bw_lock);
scm->path = devm_of_icc_get(&pdev->dev, NULL);
--
2.53.0
^ permalink raw reply related
* [PATCH v3 05/18] arm64: dts: qcom: kaanapali: Add minidump SRAM config to SCM node
From: Mukesh Ojha @ 2026-05-22 19:49 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: <20260522195009.2961022-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 bcd1cee31356..425b532c53be 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 {
@@ -5448,6 +5449,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
* [PATCH v3 06/18] arm64: dts: qcom: sm8450: Add minidump SRAM config to SCM node
From: Mukesh Ojha @ 2026-05-22 19:49 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: <20260522195009.2961022-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/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 e0c37ce3042a..d1fc5ef63a78 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 v3 07/18] arm64: dts: qcom: sa8775p: Add minidump SRAM config to SCM node
From: Mukesh Ojha @ 2026-05-22 19:49 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: <20260522195009.2961022-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/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 bc7b4f65ad5e..634000fb22d4 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>;
};
};
@@ -6817,6 +6818,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 v3 08/18] arm64: dts: qcom: qcs8300: Add minidump SRAM config to SCM node
From: Mukesh Ojha @ 2026-05-22 19:49 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: <20260522195009.2961022-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/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 7b1d57460f1e..b408ad9c0844 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>;
};
};
@@ -7150,6 +7151,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 v3 09/18] arm64: dts: qcom: qdu1000: Add minidump SRAM config to SCM node
From: Mukesh Ojha @ 2026-05-22 19:50 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: <20260522195009.2961022-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/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 v3 10/18] arm64: dts: qcom: sm8550: Add minidump SRAM config to SCM node
From: Mukesh Ojha @ 2026-05-22 19:50 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: <20260522195009.2961022-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/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 b7a7c49db077..27ef1de3edc6 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>;
};
};
@@ -5533,6 +5534,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 v3 11/18] arm64: dts: qcom: sm8650: Add minidump SRAM config to SCM node
From: Mukesh Ojha @ 2026-05-22 19:50 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: <20260522195009.2961022-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/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 1604bc8cff37..cee4def3c51d 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>;
};
};
@@ -7087,6 +7088,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 v3 12/18] arm64: dts: qcom: sc7280: Add minidump SRAM config to SCM node
From: Mukesh Ojha @ 2026-05-22 19:50 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: <20260522195009.2961022-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/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 c51beada8c7d..6a6560a3758a 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>;
};
};
@@ -6694,6 +6695,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
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