* Re: [PATCH V7 1/6] dt-bindings: power: supply: sgm41542: document sgm41542
From: Chris Morgan @ 2026-06-11 16:47 UTC (permalink / raw)
To: Rob Herring
Cc: Chris Morgan, linux-rockchip, devicetree, xsf, sre, simona,
airlied, tzimmermann, mripard, maarten.lankhorst, jesszhan0024,
neil.armstrong, heiko, conor+dt, krzk+dt
In-Reply-To: <20260611163613.GA2922314-robh@kernel.org>
On Thu, Jun 11, 2026 at 11:36:13AM -0500, Rob Herring wrote:
> On Wed, Jun 10, 2026 at 09:44:02AM -0500, Chris Morgan wrote:
> > From: Chris Morgan <macromorgan@hotmail.com>
> >
> > Document the SG Micro sgm41542 battery charger/boost converter.
> > The parameters of input-current-limit-microamp and
> > input-voltage-limit-microvolt are defined as such since they are in
> > common use among multiple bindings currently.
> >
> > Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
>
> Missing Conor's reviewed-by.
> > ---
> > .../power/supply/sgmicro,sgm41542.yaml | 96 +++++++++++++++++++
> > 1 file changed, 96 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/power/supply/sgmicro,sgm41542.yaml
I'm sorry, somehow I accidentally dropped it. If I need a V8 I'll be
sure to include it, unless you want me to submit a V8 to add it?
Thank you,
Chris
^ permalink raw reply
* Re: [PATCH v2 2/2] iio: pressure: ms5637: Add variant specific temperature compensation
From: Jonathan Cameron @ 2026-06-11 16:50 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Louis Adamian, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
David Lechner, Nuno Sá, Andy Shevchenko, linux-iio,
devicetree, linux-kernel
In-Reply-To: <aimvBvJp8CsNKlPU@ashevche-desk.local>
On Wed, 10 Jun 2026 21:37:58 +0300
Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> On Tue, Jun 09, 2026 at 10:04:58PM -0400, Louis Adamian wrote:
> > Add correct temperature compensation for ms5637-30BA, MS5803-01BA,02BA,
> > 05BA, 14BA, 30BA, MS5837-30BA. The temperature compensation formula is
> > shared across these sensors but with different constants. Add
> > ms_tp_comp_consts to capture these per-device differences. Add pressure
> > variant specific pressure scale variable.
>
> Is there SPI driver? If so, why only i2c is affected?
Excellent question. I went digging.
The library is used by the tsys01 driver which has both SPI and I2C interfaces.
Seems the SPI side never got added. The particular driver being modified here
is I2C only and the modified library function is only used in that driver.
Feels like maybe we should revisit the division of library and driver, but
probably not as part of this series!
I also too a quick look through and with the stuff Andy raised acted on this
looks fine to me.
Jonathan
^ permalink raw reply
* Re: [PATCH 2/2] MAINTAINERS: Add myself as maintainer for PMS7003
From: Jonathan Cameron @ 2026-06-11 16:57 UTC (permalink / raw)
To: Tomasz Duszyński
Cc: Maxwell Doose, Andy Shevchenko, Krzysztof Kozlowski,
David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley,
open list:IIO SUBSYSTEM AND DRIVERS,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list
In-Reply-To: <CAObtm8zDk4s3+pmGSxRoVHq7ef1y=_cHdC8YRH6ycRNbjzaNkg@mail.gmail.com>
On Thu, 11 Jun 2026 15:41:44 +0200
Tomasz Duszyński <tduszyns@gmail.com> wrote:
> Hi,
>
> I've been trying to catch up on the recent discussion. A few things I
> want to address:
>
Hi Tomasz,
> 1. My email is active and I do read patches (when CCd), but by the
> time I have a proper slot to sit down and review something, it's
> usually already gone through several rounds.
> Chiming in at that point just for the sake of it doesn't add much value imo.
On this, if you want to take a look at a patch but are busy at the time
(happens to all of us!) then feel free to just reply to say that
is the case. Most stuff isn't urgent enough and I do take things a bit
quickly sometimes (driven by desire to keep the queue manageable!)
>
> 2. I get the impression you're thinking that since I'm not actively
> maintaining these drivers, you can step in and take ownership. I'm
> broadly fine with that, but I'd want to see more work and patches
> coming from you first. If that happens, we can revisit the ownership
> question. That said, do you actually have these sensors on hand to
> test more invasive changes? If you've already answered that just skip
> it as I'll probably stumble upon it whilst going through overdue
> mails.
>
This was driven by some confusion and I think a bounce on a different
email address (octakon). For the scd30, would you mind if we put you
back (can be along side Maxwell who stepped up because the original
suggestion was to mark it orphaned) with this email address?
> 3. I've managed to carve out some extra time lately, so I'm happy to
> be more involved with reviews going forward if that's useful.
Excellent!
>
> In the meantime I'll go through the remaining emails to get better context.
>
> On Thu, Jun 11, 2026 at 2:23 PM Maxwell Doose <m32285159@gmail.com> wrote:
> >
> > On Thu, Jun 11, 2026 at 2:12 AM Andy Shevchenko
> > <andriy.shevchenko@intel.com> wrote:
> > >
> > > On Thu, Jun 11, 2026 at 10:09:57AM +0300, Andy Shevchenko wrote:
> > > > On Thu, Jun 11, 2026 at 08:58:47AM +0200, Krzysztof Kozlowski wrote:
> > > > > On 11/06/2026 08:50, Andy Shevchenko wrote:
> > > > > > On Thu, Jun 11, 2026 at 08:37:33AM +0200, Krzysztof Kozlowski wrote:
> > > > > >> On 11/06/2026 00:24, Maxwell Doose wrote:
> > > > > >>> On Wed, Jun 10, 2026 at 4:09 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> > > > > >>>> On Tue, Jun 09, 2026 at 11:03:26AM -0500, Maxwell Doose wrote:
> > > > > >>>>> Tomasz's entry is no longer valid, as he is not active anymore. Add
> > > > > >>>>
> > > > > >>>> Why is not longer valid? I see activity in Feb...
> > > > > >>>
> > > > > >>> Strange. According to git log --author="Tomasz Duszynski" last commit
> > > > > >>> I have from him is 2023. We also did have an RFC open for a month on
> > > > > >>> linux-iio with Tomasz Cced with no response.
> > > > > >>
> > > > > >> So you did not check enough... and no one needs to read RFC :/
> > > > > >
> > > > > > Hmm... lore.kernel.org shows last activity November last year (07-11-2025).
> > > > > > What other sources do you suggest to check?
> > > > >
> > > > > No, only lore.
> > > >
> > > > I used this request:
> > > > https://lore.kernel.org/all/?q=f%3A%22Tomasz+Duszynski%22
> > > >
> > > > > As I said, February this year.
> > > > >
> > > > > https://lore.kernel.org/all/CAObtm8zKUAWNS23nRMhc9ZR-zn7xeVOFPiV4ai_x7Bkd5puiyA@mail.gmail.com/
> > > >
> > > > Okay, you used UTF-8 name, Where did you get it from? MAINTAINERS has no
> > > > diacritics.
> > >
> > > OTOH, you may have used simply email approach. With
> > > https://lore.kernel.org/all/?q=f%3Atduszyns%40gmail.com
> > > I got it as well.
> >
> > Ok, now I see it. I will say though that we've emailed Tomasz at least
> > 10 times at this point for various things and hasn't responded to even
> > one :/ if we need to we can allow Jonathan to chime in.
>
>
>
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: shikra: Add BAM-DMUX support
From: Stephan Gerhold @ 2026-06-11 16:57 UTC (permalink / raw)
To: Vishnu Santhosh
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel,
bjorn.andersson, chris.lew
In-Reply-To: <17bfa853-d0a6-4f83-a164-a17fb02f67a6@oss.qualcomm.com>
On Thu, Jun 11, 2026 at 09:31:06PM +0530, Vishnu Santhosh wrote:
> On 11-06-2026 02:25 pm, Stephan Gerhold wrote:
> > On Thu, Jun 11, 2026 at 02:11:59PM +0530, Vishnu Santhosh wrote:
> > > + bam_dmux: bam-dmux {
> > > + compatible = "qcom,bam-dmux";
> > > +
> > > + interrupts-extended = <&modem_smsm 1 IRQ_TYPE_EDGE_BOTH>,
> > > + <&modem_smsm 11 IRQ_TYPE_EDGE_BOTH>;
> > > + interrupt-names = "pc",
> > > + "pc-ack";
> > > +
> > > + qcom,smem-states = <&apps_smsm 1>,
> > > + <&apps_smsm 11>;
> > > + qcom,smem-state-names = "pc",
> > > + "pc-ack";
> > > +
> > > + dmas = <&bam_dmux_dma 4>, <&bam_dmux_dma 5>;
> > > + dma-names = "tx", "rx";
> > > + };
> > This should be a child node of the modem remoteproc. See msm8916.dtsi
> > for example.
>
> Thanks for the context! We actually referenced msm8916.dtsi during bring-up
> and initially placed bam-dmux as a
> remoteproc child. We then hit the issue that the driver was not probing at
> all. After some digging, we realized
> that qcom_q6v5_mss.c (used by msm8916) explicitly calls
> of_platform_device_create() for its qcom,bam-dmux child,
> but qcom_q6v5_pas.c which Shikra uses has no such logic, so the platform
> device was never created.
>
> There was a prior attempt to fix this generically by adding
> of_platform_populate() to qcom_q6v5.c
> (https://lore.kernel.org/all/20251223123227.1317244-3-gaurav.kohli@oss.qualcomm.com/),
> but it was blocked
> because GLINK/SMD edge child nodes would also get spurious platform devices
> registered for them.
> That series remains unresolved at v1.
>
> Since your driver already manages modem lifecycle independently via SMSM
> state bits without remoteproc dependency,
> we moved it to the root level where of_platform_populate() picks it up at
> boot, and everything worked.
>
> Would love to get your suggestion on whether this approach is welcomed,
> since it needs zero driver changes.
>
Adding the bam-dmux node top-level makes it impossible for userspace to
associate it with a remoteproc (for this purpose: the "modem"). If you
add it below the remoteproc the udev/sysfs path will include the
remoteproc and you can tell that the network interfaces exposed by
bam_dmux belong to that remoteproc.
As you noticed, having a generic of_platform_populate() for remoteproc
nodes is problematic, because usually subnodes are remoteproc subdevs.
Also, the cooling device use case in the thread you linked doesn't have
any resources attached, so the root complaint there was that you don't
need a separate subnode at all.
I would just replicate the special qcom,bam-dmux logic inside
qcom_q6v5_pas.c. I think the motivation for BAM-DMUX explained in commit
59983c74fc42 ("remoteproc: qcom_q6v5_mss: Create platform device for
BAM-DMUX") is still valid. Conceptually, BAM-DMUX is a subdevice of the
modem remoteproc, since the remoteproc is responsible for powering the
BAM-DMUX hardware on and off. The fact that BAM-DMUX is not a remoteproc
subdev in Linux is more an implementation detail of the current Linux
driver. This is independent from the model in the device tree.
Thanks,
Stephan
^ permalink raw reply
* Re: [PATCH] dt-bindings: iio: accel: Convert lis302 binding to YAML schema
From: Conor Dooley @ 2026-06-11 17:09 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Md Shofiqul Islam, linux-iio, devicetree, dlechner, nuno.sa, andy,
robh, krzk+dt, conor+dt, krzk, linux-kernel
In-Reply-To: <20260611140640.4b144bc2@jic23-huawei>
[-- Attachment #1: Type: text/plain, Size: 3637 bytes --]
On Thu, Jun 11, 2026 at 02:06:40PM +0100, Jonathan Cameron wrote:
> On Wed, 10 Jun 2026 17:40:04 +0100
> Conor Dooley <conor@kernel.org> wrote:
>
> > On Wed, Jun 10, 2026 at 04:56:40PM +0100, Jonathan Cameron wrote:
> > > On Wed, 10 Jun 2026 14:00:51 +0300
> > > Md Shofiqul Islam <shofiqtest@gmail.com> wrote:
> > >
> > > > Convert the STMicroelectronics LIS302DL/LIS3LV02D accelerometer device
> > > > tree binding from plain text format to YAML schema format.
> > > >
> > > > The binding covers two variants matched via their respective bus drivers:
> > > > - SPI: st,lis302dl-spi (drivers/misc/lis3lv02d/lis3lv02d_spi.c)
> > > > - I2C: st,lis3lv02d (drivers/misc/lis3lv02d/lis3lv02d_i2c.c)
> > > >
> > > > Document all vendor-specific properties read by the driver via
> > > > of_property_read_*(), including click detection, IRQ routing, free-fall/
> > > > wake-up engines, high-pass filtering, axis remapping, output data rate,
> > > > and self-test limits.
> > > >
> > > > Also correct the click threshold property names: the driver reads
> > > > "st,click-threshold-{x,y,z}" but the old .txt documented them as
> > > > "st,click-thresh-{x,y,z}".
> > > >
> > > > Validated with: make dt_binding_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/iio/accel/st,lis302dl.yaml
> > > >
> > > > Signed-off-by: Md Shofiqul Islam <shofiqtest@gmail.com>
> > >
> > > Hi.
> > >
> > > So the conundrum here is whether we want to keep carrying this binding
> > > as it dates to a previous era.
> > >
> > > The driver never made it to IIO and is still in drivers/misc.
> > > The majority of what is the text document should never have been
> > > in DT in the first place. I'll guess this dates all the way back
> > > to the wild west days before we had regular binding review.
> >
> > I'd say this should be treated like a staging binding but for the fact
> > that this has a user in arm. Problem of course is that it's probably
> > impossible to get that board and so doing any rework is probably not
> > realistic for this submitter?
> > Is there a general policy for iio devices in misc? Do they get reworked
> > to be moved?
>
> It is tricky if we have upstream users because the ABI will change on them.
>
> I'm not sure how easy this would be to add to the existing st sensors driver
> as these are very early parts. If we could maybe we'd do so and just deal
> with the mess of having to disable one or other driver.
>
> My gut feeling here is ancient part, let it get dropped in a year or
> two and not worry about adding support to a standard IIO driver unless
> anyone actually has hardware and wants to do it.
>
> >
> > The user funnily enough has the binding's click-thresh properties:
> > st,click-single-x;
> > st,click-single-y;
> > st,click-single-z;
> > st,click-thresh-x = <10>;
> > st,click-thresh-y = <10>;
> > st,click-thresh-z = <10>;
> > st,irq1-click;
> > st,irq2-click;
> > st,wakeup-x-lo;
> > st,wakeup-x-hi;
> > st,wakeup-y-lo;
> > st,wakeup-y-hi;
> > st,wakeup-z-lo;
> > st,wakeup-z-hi;
> > Dunno what that ultimately means in terms of which should be used
> > though.
> Set those as defaults in the driver if all upstream users have those
> values and then drop reading them from dt?
Actually, there's more than one user in arm, but there's a mix of
compatibles and properties used. Probably not really viable unless these
are all unique compatible + property combinations. FWIW, there's more
compatibles used than those documented, that fall back to the documented
ones.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2 3/3] dt-bindings: iio: accel: convert lis302 binding to YAML schema (v2)
From: Conor Dooley @ 2026-06-11 17:10 UTC (permalink / raw)
To: Md Shofiqul Islam
Cc: linux-iio, devicetree, jic23, robh, krzk+dt, conor+dt, linusw,
linux-kernel
In-Reply-To: <20260611154105.3727-4-shofiqtest@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 17001 bytes --]
On Thu, Jun 11, 2026 at 06:41:05PM +0300, Md Shofiqul Islam wrote:
> Replace the plain text lis302.txt with a YAML schema for the
> LIS302DL/LIS3LV02D accelerometer family.
>
> Key changes from v1:
> - Add a prominent WARNING in the description that this is a legacy
> binding and must not be copied for new devices
> - Add st,lis302dl compatible (used by Nokia N900 / omap3-n900.dts)
> in addition to st,lis302dl-spi and st,lis3lv02d
> - Document both supply naming conventions: Vdd-supply/Vdd_IO-supply
> (legacy uppercase, used by most boards) and vdd-supply/vddio-supply
> (modern lowercase, used by Nokia N900)
> - Add mount-matrix support (used by Nokia N900)
> - Add self-test limit properties st,min-limit-x/y/z and
> st,max-limit-x/y/z (these legitimately belong in DT as they
> encode per-board hardware tolerances)
> - Mark all click/irq/wakeup/filter properties as deprecated=true.
> They configure run-time driver behaviour, not hardware, and should
> not appear in DT for new boards
> - Add st,click-thresh-x/y/z as deprecated with an explicit note that
> this is a misspelling present in several upstream boards; the driver
> reads st,click-threshold-x/y/z and never reads the short form
> - Remove driver path reference from description
> - Use schema constraints (minimum/maximum) for axis remapping range
> - Remove Jonathan Cameron as maintainer; use Linus Walleij who
> already maintains the related st,st-sensors binding
> - Use example based on actual upstream board (Nokia N900)
This whole section should be under the --- line.
Please do not send additional versions while discussion is still ongoing
on your most recent.
Thanks,
Conor.
>
> Boards using this as primary binding:
> st,lis302dl: omap3-n900.dts
> st,lis3lv02d: omap3-n950-n9.dtsi, am335x-pepper.dts
> st,lis302dl-spi: pxa300-raumfeld-controller.dts
>
> Signed-off-by: Md Shofiqul Islam <shofiqtest@gmail.com>
> ---
> .../devicetree/bindings/iio/accel/lis302.txt | 119 -------
> .../bindings/iio/accel/st,lis302dl.yaml | 320 ++++++++++++++++++
> 2 files changed, 320 insertions(+), 119 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/iio/accel/lis302.txt
> create mode 100644 Documentation/devicetree/bindings/iio/accel/st,lis302dl.yaml
>
> diff --git a/Documentation/devicetree/bindings/iio/accel/lis302.txt b/Documentation/devicetree/bindings/iio/accel/lis302.txt
> deleted file mode 100644
> index 457539647f36..000000000000
> --- a/Documentation/devicetree/bindings/iio/accel/lis302.txt
> +++ /dev/null
> @@ -1,119 +0,0 @@
> -LIS302 accelerometer devicetree bindings
> -
> -This device is matched via its bus drivers, and has a number of properties
> -that apply in on the generic device (independent from the bus).
> -
> -
> -Required properties for the SPI bindings:
> - - compatible: should be set to "st,lis3lv02d-spi"
> - - reg: the chipselect index
> - - spi-max-frequency: maximal bus speed, should be set to 1000000 unless
> - constrained by external circuitry
> - - interrupts: the interrupt generated by the device
> -
> -Required properties for the I2C bindings:
> - - compatible: should be set to "st,lis3lv02d"
> - - reg: i2c slave address
> - - Vdd-supply: The input supply for Vdd
> - - Vdd_IO-supply: The input supply for Vdd_IO
> -
> -
> -Optional properties for all bus drivers:
> -
> - - st,click-single-{x,y,z}: if present, tells the device to issue an
> - interrupt on single click events on the
> - x/y/z axis.
> - - st,click-double-{x,y,z}: if present, tells the device to issue an
> - interrupt on double click events on the
> - x/y/z axis.
> - - st,click-thresh-{x,y,z}: set the x/y/z axis threshold
> - - st,click-click-time-limit: click time limit, from 0 to 127.5msec
> - with step of 0.5 msec
> - - st,click-latency: click latency, from 0 to 255 msec with
> - step of 1 msec.
> - - st,click-window: click window, from 0 to 255 msec with
> - step of 1 msec.
> - - st,irq{1,2}-disable: disable IRQ 1/2
> - - st,irq{1,2}-ff-wu-1: raise IRQ 1/2 on FF_WU_1 condition
> - - st,irq{1,2}-ff-wu-2: raise IRQ 1/2 on FF_WU_2 condition
> - - st,irq{1,2}-data-ready: raise IRQ 1/2 on data ready condition
> - - st,irq{1,2}-click: raise IRQ 1/2 on click condition
> - - st,irq-open-drain: consider IRQ lines open-drain
> - - st,irq-active-low: make IRQ lines active low
> - - st,wu-duration-1: duration register for Free-Fall/Wake-Up
> - interrupt 1
> - - st,wu-duration-2: duration register for Free-Fall/Wake-Up
> - interrupt 2
> - - st,wakeup-{x,y,z}-{lo,hi}: set wakeup condition on x/y/z axis for
> - upper/lower limit
> - - st,wakeup-threshold: set wakeup threshold
> - - st,wakeup2-{x,y,z}-{lo,hi}: set wakeup condition on x/y/z axis for
> - upper/lower limit for second wakeup
> - engine.
> - - st,wakeup2-threshold: set wakeup threshold for second wakeup
> - engine.
> - - st,highpass-cutoff-hz=: 1, 2, 4 or 8 for 1Hz, 2Hz, 4Hz or 8Hz of
> - highpass cut-off frequency
> - - st,hipass{1,2}-disable: disable highpass 1/2.
> - - st,default-rate=: set the default rate
> - - st,axis-{x,y,z}=: set the axis to map to the three coordinates.
> - Negative values can be used for inverted axis.
> - - st,{min,max}-limit-{x,y,z} set the min/max limits for x/y/z axis
> - (used by self-test)
> -
> -
> -Example for a SPI device node:
> -
> - accelerometer@0 {
> - compatible = "st,lis302dl-spi";
> - reg = <0>;
> - spi-max-frequency = <1000000>;
> - interrupt-parent = <&gpio>;
> - interrupts = <104 0>;
> -
> - st,click-single-x;
> - st,click-single-y;
> - st,click-single-z;
> - st,click-thresh-x = <10>;
> - st,click-thresh-y = <10>;
> - st,click-thresh-z = <10>;
> - st,irq1-click;
> - st,irq2-click;
> - st,wakeup-x-lo;
> - st,wakeup-x-hi;
> - st,wakeup-y-lo;
> - st,wakeup-y-hi;
> - st,wakeup-z-lo;
> - st,wakeup-z-hi;
> - };
> -
> -Example for a I2C device node:
> -
> - lis331dlh: accelerometer@18 {
> - compatible = "st,lis331dlh", "st,lis3lv02d";
> - reg = <0x18>;
> - Vdd-supply = <&lis3_reg>;
> - Vdd_IO-supply = <&lis3_reg>;
> -
> - st,click-single-x;
> - st,click-single-y;
> - st,click-single-z;
> - st,click-thresh-x = <10>;
> - st,click-thresh-y = <10>;
> - st,click-thresh-z = <10>;
> - st,irq1-click;
> - st,irq2-click;
> - st,wakeup-x-lo;
> - st,wakeup-x-hi;
> - st,wakeup-y-lo;
> - st,wakeup-y-hi;
> - st,wakeup-z-lo;
> - st,wakeup-z-hi;
> - st,min-limit-x = <120>;
> - st,min-limit-y = <120>;
> - st,min-limit-z = <140>;
> - st,max-limit-x = <550>;
> - st,max-limit-y = <550>;
> - st,max-limit-z = <750>;
> - };
> -
> diff --git a/Documentation/devicetree/bindings/iio/accel/st,lis302dl.yaml b/Documentation/devicetree/bindings/iio/accel/st,lis302dl.yaml
> new file mode 100644
> index 000000000000..8a19aa108521
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/accel/st,lis302dl.yaml
> @@ -0,0 +1,320 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/iio/accel/st,lis302dl.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: STMicroelectronics LIS302DL/LIS3LV02D 3-Axis Accelerometer (Legacy Binding)
> +
> +description: |
> + WARNING: This is a legacy binding for hardware that predates modern DT
> + practices. It is documented as-found in upstream board files. Do NOT use
> + this as a template for new drivers or bindings.
> +
> + The driver lives in drivers/misc/lis3lv02d, not in IIO. Many properties
> + listed here represent run-time driver configuration that would normally not
> + appear in device tree. They are documented here only because existing
> + upstream board DTS files use them.
> +
> + Compatibles st,lis302dl-spi and st,lis3lv02d were previously listed as
> + deprecated in st,st-sensors.yaml. They are moved here with their actual
> + hardware configuration so validation works correctly.
> +
> +maintainers:
> + - Linus Walleij <linus.walleij@linaro.org>
> +
> +properties:
> + compatible:
> + oneOf:
> + - description: I2C variant (original part)
> + const: st,lis302dl
> + - description: I2C variant (larger range)
> + const: st,lis3lv02d
> + - description: SPI variant; including the bus type in the compatible
> + string is a legacy naming error, do not copy for new bindings
> + const: st,lis302dl-spi
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + minItems: 1
> + maxItems: 2
> +
> + Vdd-supply:
> + description: Main power supply (legacy uppercase name used by most boards).
> +
> + Vdd_IO-supply:
> + description: I/O power supply (legacy uppercase name used by most boards).
> +
> + vdd-supply:
> + description: Main power supply (modern lowercase name, used by omap3-n900).
> +
> + vddio-supply:
> + description: I/O power supply (modern lowercase name, used by omap3-n900).
> +
> + mount-matrix:
> + description: 3x3 mounting rotation matrix.
> +
> + st,min-limit-x:
> + $ref: /schemas/types.yaml#/definitions/int32
> + description: Minimum acceptable self-test delta for X axis.
> +
> + st,min-limit-y:
> + $ref: /schemas/types.yaml#/definitions/int32
> + description: Minimum acceptable self-test delta for Y axis.
> +
> + st,min-limit-z:
> + $ref: /schemas/types.yaml#/definitions/int32
> + description: Minimum acceptable self-test delta for Z axis.
> +
> + st,max-limit-x:
> + $ref: /schemas/types.yaml#/definitions/int32
> + description: Maximum acceptable self-test delta for X axis.
> +
> + st,max-limit-y:
> + $ref: /schemas/types.yaml#/definitions/int32
> + description: Maximum acceptable self-test delta for Y axis.
> +
> + st,max-limit-z:
> + $ref: /schemas/types.yaml#/definitions/int32
> + description: Maximum acceptable self-test delta for Z axis.
> +
> + # The following properties configure run-time driver behaviour and do not
> + # describe hardware. They are deprecated. Documented here only so that
> + # existing upstream board DTS files pass dt_binding_check.
> +
> + st,click-single-x:
> + type: boolean
> + deprecated: true
> + description: Enable single-click detection on X axis.
> +
> + st,click-single-y:
> + type: boolean
> + deprecated: true
> + description: Enable single-click detection on Y axis.
> +
> + st,click-single-z:
> + type: boolean
> + deprecated: true
> + description: Enable single-click detection on Z axis.
> +
> + st,click-threshold-x:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + deprecated: true
> + description: Click threshold X axis. Driver default is used if absent.
> +
> + st,click-threshold-y:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + deprecated: true
> + description: Click threshold Y axis. Driver default is used if absent.
> +
> + st,click-threshold-z:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + deprecated: true
> + description: Click threshold Z axis. Driver default is used if absent.
> +
> + st,click-thresh-x:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + deprecated: true
> + description: |
> + Misspelling of st,click-threshold-x present in several upstream board
> + files. The driver does not read this property; it is silently ignored.
> + Documented here only to avoid dt_binding_check failures on those boards.
> +
> + st,click-thresh-y:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + deprecated: true
> + description: See st,click-thresh-x.
> +
> + st,click-thresh-z:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + deprecated: true
> + description: See st,click-thresh-x.
> +
> + st,click-time-limit:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + deprecated: true
> + description: Click time limit in 0.5ms steps (0-127).
> +
> + st,click-latency:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + deprecated: true
> + description: Click latency in 1ms steps (0-255).
> +
> + st,click-window:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + deprecated: true
> +
> + st,irq1-click:
> + type: boolean
> + deprecated: true
> + st,irq2-click:
> + type: boolean
> + deprecated: true
> + st,irq1-ff-wu-1:
> + type: boolean
> + deprecated: true
> + st,irq1-ff-wu-2:
> + type: boolean
> + deprecated: true
> + st,irq2-ff-wu-1:
> + type: boolean
> + deprecated: true
> + st,irq2-ff-wu-2:
> + type: boolean
> + deprecated: true
> + st,irq1-data-ready:
> + type: boolean
> + deprecated: true
> + st,irq2-data-ready:
> + type: boolean
> + deprecated: true
> + st,irq1-disable:
> + type: boolean
> + deprecated: true
> + st,irq2-disable:
> + type: boolean
> + deprecated: true
> + st,irq-open-drain:
> + type: boolean
> + deprecated: true
> + st,irq-active-low:
> + type: boolean
> + deprecated: true
> +
> + st,wakeup-x-lo:
> + type: boolean
> + deprecated: true
> + st,wakeup-x-hi:
> + type: boolean
> + deprecated: true
> + st,wakeup-y-lo:
> + type: boolean
> + deprecated: true
> + st,wakeup-y-hi:
> + type: boolean
> + deprecated: true
> + st,wakeup-z-lo:
> + type: boolean
> + deprecated: true
> + st,wakeup-z-hi:
> + type: boolean
> + deprecated: true
> + st,wakeup-threshold:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + deprecated: true
> +
> + st,wakeup2-x-lo:
> + type: boolean
> + deprecated: true
> + st,wakeup2-x-hi:
> + type: boolean
> + deprecated: true
> + st,wakeup2-y-lo:
> + type: boolean
> + deprecated: true
> + st,wakeup2-y-hi:
> + type: boolean
> + deprecated: true
> + st,wakeup2-z-lo:
> + type: boolean
> + deprecated: true
> + st,wakeup2-z-hi:
> + type: boolean
> + deprecated: true
> + st,wakeup2-threshold:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + deprecated: true
> +
> + st,wu-duration-1:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + deprecated: true
> + st,wu-duration-2:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + deprecated: true
> +
> + st,highpass-cutoff-hz:
> + enum: [1, 2, 4, 8]
> + deprecated: true
> + st,hipass1-disable:
> + type: boolean
> + deprecated: true
> + st,hipass2-disable:
> + type: boolean
> + deprecated: true
> +
> + st,default-rate:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + deprecated: true
> +
> + st,axis-x:
> + $ref: /schemas/types.yaml#/definitions/int32
> + minimum: -3
> + maximum: 3
> + deprecated: true
> + description: Axis remapping. Replaced by mount-matrix.
> +
> + st,axis-y:
> + $ref: /schemas/types.yaml#/definitions/int32
> + minimum: -3
> + maximum: 3
> + deprecated: true
> + description: Axis remapping. Replaced by mount-matrix.
> +
> + st,axis-z:
> + $ref: /schemas/types.yaml#/definitions/int32
> + minimum: -3
> + maximum: 3
> + deprecated: true
> + description: Axis remapping. Replaced by mount-matrix.
> +
> +required:
> + - compatible
> + - reg
> +
> +allOf:
> + - $ref: /schemas/spi/spi-peripheral-props.yaml#
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/irq.h>
> + i2c {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + accelerometer@1d {
> + compatible = "st,lis302dl";
> + reg = <0x1d>;
> + vdd-supply = <&vaux1>;
> + vddio-supply = <&vio>;
> + interrupt-parent = <&gpio6>;
> + interrupts = <21 IRQ_TYPE_EDGE_RISING>,
> + <20 IRQ_TYPE_EDGE_RISING>;
> + mount-matrix = "-1", "0", "0",
> + "0", "1", "0",
> + "0", "0", "-1";
> + };
> + };
> + - |
> + #include <dt-bindings/interrupt-controller/irq.h>
> + spi {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + accelerometer@1 {
> + compatible = "st,lis302dl-spi";
> + reg = <1>;
> + spi-max-frequency = <1000000>;
> + interrupt-parent = <&gpio>;
> + interrupts = <104 IRQ_TYPE_EDGE_FALLING>;
> + st,click-single-x;
> + st,click-single-y;
> + st,click-single-z;
> + st,irq1-click;
> + st,irq2-click;
> + };
> + };
> +...
> --
> 2.51.1
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH] dt-bindings: i2c: i2c-mux-pinctrl: change maintainer
From: Conor Dooley @ 2026-06-11 17:18 UTC (permalink / raw)
To: Wolfram Sang
Cc: linux-i2c, Thierry Reding, Peter Rosin, Andi Shyti, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, devicetree
In-Reply-To: <20260611122704.7559-2-wsa+renesas@sang-engineering.com>
[-- Attachment #1: Type: text/plain, Size: 75 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH] dt-bindings: i2c: mux-gpio: name correct maintainer
From: Conor Dooley @ 2026-06-11 17:19 UTC (permalink / raw)
To: Wolfram Sang
Cc: linux-i2c, Peter Korsgaard, Peter Rosin, Andi Shyti, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, devicetree
In-Reply-To: <20260611122053.7306-2-wsa+renesas@sang-engineering.com>
[-- Attachment #1: Type: text/plain, Size: 75 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: mfd: mediatek: mt6397: add mt6323 PMIC EFUSE
From: Conor Dooley @ 2026-06-11 17:22 UTC (permalink / raw)
To: rva333
Cc: Sen Chu, Sean Wang, Macpaul Lin, Lee Jones, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Srinivas Kandagatla, Andy Shevchenko,
Jonathan Cameron, linux-pm, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek, Ben Grisdale
In-Reply-To: <20260611-mt6323-nvmem-v1-1-b5e1b9ce51f2@protonmail.com>
[-- Attachment #1: Type: text/plain, Size: 75 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v3 04/18] firmware: qcom: scm: Add minidump SRAM support
From: Mukesh Ojha @ 2026-06-11 17:22 UTC (permalink / raw)
To: sashiko-reviews; +Cc: conor+dt, devicetree, robh
In-Reply-To: <20260522202145.9AC631F000E9@smtp.kernel.org>
On Fri, May 22, 2026 at 08:21:45PM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
>
> Pre-existing issues:
> - [High] Missing smp_load_acquire() when reading the global __scm pointer in set_download_mode() risks a race condition and stale reads.
> --
>
> commit de197846d8ecb70e3382c65171f1e37949d3d114
> Author: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
>
> firmware: qcom: scm: Add minidump SRAM support
>
> On most Qualcomm SoCs where minidump is supported, a word in always-on
> SRAM is shared between the kernel and boot firmware. This commit adds
> minidump SRAM support and exposes a minidump_dest module parameter so
> the user can select the destination.
>
> > diff --git a/drivers/firmware/qcom/qcom_scm.c b/drivers/firmware/qcom/qcom_scm.c
> > --- a/drivers/firmware/qcom/qcom_scm.c
> > +++ b/drivers/firmware/qcom/qcom_scm.c
> [ ... ]
> > @@ -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);
> > }
>
> [Severity: High]
> This is a pre-existing issue, but is it safe to read the global __scm
> pointer here without using smp_load_acquire()?
>
> The driver publishes the global __scm pointer at the end of qcom_scm_probe()
> using smp_store_release(&__scm, scm). Module parameters are exposed via
> sysfs before probe completes, allowing userspace to concurrently trigger the
> set_download_mode() callback.
>
> This callback reads __scm using a plain, lockless memory access. Without a
> matching smp_load_acquire(), the CPU can observe a non-NULL __scm pointer
> while still seeing stale or uninitialized values for its members, including
> the newly added __scm->minidump_sram.
>
> Could this lead to an unaligned access or page fault if writel_relaxed()
> is passed an uninitialized pointer?
>
> Note that the newly added set_minidump_dest() correctly uses
> smp_load_acquire() to prevent this exact issue, but
> qcom_scm_set_download_mode() remains unprotected.
Will raise a separate change for this fixing
qcom_scm_set_download_mode().
>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20260522195009.2961022-1-mukesh.ojha@oss.qualcomm.com?part=4
--
-Mukesh Ojha
^ permalink raw reply
* [PATCH] arm64: dts: qcom: glymur: fix QUP serial engine IRQs
From: Bjorn Andersson @ 2026-06-11 17:22 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Pankaj Patil, Taniya Das,
Manaf Meethalavalappu Pallikunhi, Jyothi Kumar Seerapu,
Jishnu Prakash
Cc: Maulik Shah, Sibi Sankar, Kamal Wadhwa, linux-arm-msm, devicetree,
linux-kernel, Bjorn Andersson
The Geni serial-engine interrupts from QUP wrapper 0 all fall in ESPI
INTIDs space. While some of the i2c instances has gotten their
interrupt specifiers corrected, even the other functions on the same
serial-engines are wrong.
Ensure that all the serial engine interrupts for QUP wrapper 0 matches
the datasheet.
Assisted-by: Codex:GPT-5.5
Fixes: 41b6e8db400c ("arm64: dts: qcom: Introduce Glymur base dtsi")
Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/glymur.dtsi | 26 +++++++++++++-------------
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/glymur.dtsi b/arch/arm64/boot/dts/qcom/glymur.dtsi
index 20b49af7298e..2271ac080ccb 100644
--- a/arch/arm64/boot/dts/qcom/glymur.dtsi
+++ b/arch/arm64/boot/dts/qcom/glymur.dtsi
@@ -1876,7 +1876,7 @@ &config_noc SLAVE_QUP_0 QCOM_ICC_TAG_ALWAYS>,
spi0: spi@b80000 {
compatible = "qcom,geni-spi";
reg = <0x0 0x00b80000 0x0 0x4000>;
- interrupts = <GIC_SPI 1052 IRQ_TYPE_LEVEL_HIGH>;
+ interrupts = <GIC_ESPI 92 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&gcc GCC_QUPV3_WRAP0_S0_CLK>;
clock-names = "se";
interconnects = <&clk_virt MASTER_QUP_CORE_0 QCOM_ICC_TAG_ALWAYS
@@ -1903,7 +1903,7 @@ &config_noc SLAVE_QUP_0 QCOM_ICC_TAG_ALWAYS>,
i2c1: i2c@b84000 {
compatible = "qcom,geni-i2c";
reg = <0x0 0x00b84000 0x0 0x4000>;
- interrupts = <GIC_SPI 1053 IRQ_TYPE_LEVEL_HIGH>;
+ interrupts = <GIC_ESPI 93 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&gcc GCC_QUPV3_WRAP0_S1_CLK>;
clock-names = "se";
interconnects = <&clk_virt MASTER_QUP_CORE_0 QCOM_ICC_TAG_ALWAYS
@@ -1930,7 +1930,7 @@ &config_noc SLAVE_QUP_0 QCOM_ICC_TAG_ALWAYS>,
spi1: spi@b84000 {
compatible = "qcom,geni-spi";
reg = <0x0 0x00b84000 0x0 0x4000>;
- interrupts = <GIC_SPI 1053 IRQ_TYPE_LEVEL_HIGH>;
+ interrupts = <GIC_ESPI 93 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&gcc GCC_QUPV3_WRAP0_S1_CLK>;
clock-names = "se";
interconnects = <&clk_virt MASTER_QUP_CORE_0 QCOM_ICC_TAG_ALWAYS
@@ -1957,7 +1957,7 @@ &config_noc SLAVE_QUP_0 QCOM_ICC_TAG_ALWAYS>,
i2c2: i2c@b88000 {
compatible = "qcom,geni-i2c";
reg = <0x0 0x00b88000 0x0 0x4000>;
- interrupts = <GIC_SPI 1054 IRQ_TYPE_LEVEL_HIGH>;
+ interrupts = <GIC_ESPI 94 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&gcc GCC_QUPV3_WRAP0_S2_CLK>;
clock-names = "se";
interconnects = <&clk_virt MASTER_QUP_CORE_0 QCOM_ICC_TAG_ALWAYS
@@ -1984,7 +1984,7 @@ &config_noc SLAVE_QUP_0 QCOM_ICC_TAG_ALWAYS>,
spi2: spi@b88000 {
compatible = "qcom,geni-spi";
reg = <0x0 0x00b88000 0x0 0x4000>;
- interrupts = <GIC_SPI 1054 IRQ_TYPE_LEVEL_HIGH>;
+ interrupts = <GIC_ESPI 94 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&gcc GCC_QUPV3_WRAP0_S2_CLK>;
clock-names = "se";
interconnects = <&clk_virt MASTER_QUP_CORE_0 QCOM_ICC_TAG_ALWAYS
@@ -2011,7 +2011,7 @@ &config_noc SLAVE_QUP_0 QCOM_ICC_TAG_ALWAYS>,
uart2: serial@b88000 {
compatible = "qcom,geni-uart";
reg = <0x0 0x00b88000 0x0 0x4000>;
- interrupts = <GIC_SPI 1054 IRQ_TYPE_LEVEL_HIGH>;
+ interrupts = <GIC_ESPI 94 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&gcc GCC_QUPV3_WRAP0_S2_CLK>;
clock-names = "se";
interconnects = <&clk_virt MASTER_QUP_CORE_0 QCOM_ICC_TAG_ALWAYS
@@ -2056,7 +2056,7 @@ &config_noc SLAVE_QUP_0 QCOM_ICC_TAG_ALWAYS>,
spi3: spi@b8c000 {
compatible = "qcom,geni-spi";
reg = <0x0 0x00b8c000 0x0 0x4000>;
- interrupts = <GIC_SPI 1055 IRQ_TYPE_LEVEL_HIGH>;
+ interrupts = <GIC_ESPI 95 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&gcc GCC_QUPV3_WRAP0_S3_CLK>;
clock-names = "se";
interconnects = <&clk_virt MASTER_QUP_CORE_0 QCOM_ICC_TAG_ALWAYS
@@ -2110,7 +2110,7 @@ &config_noc SLAVE_QUP_0 QCOM_ICC_TAG_ALWAYS>,
spi4: spi@b90000 {
compatible = "qcom,geni-spi";
reg = <0x0 0x00b90000 0x0 0x4000>;
- interrupts = <GIC_SPI 1056 IRQ_TYPE_LEVEL_HIGH>;
+ interrupts = <GIC_ESPI 96 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&gcc GCC_QUPV3_WRAP0_S4_CLK>;
clock-names = "se";
interconnects = <&clk_virt MASTER_QUP_CORE_0 QCOM_ICC_TAG_ALWAYS
@@ -2164,7 +2164,7 @@ &config_noc SLAVE_QUP_0 QCOM_ICC_TAG_ALWAYS>,
spi5: spi@b94000 {
compatible = "qcom,geni-spi";
reg = <0x0 0x00b94000 0x0 0x4000>;
- interrupts = <GIC_SPI 1057 IRQ_TYPE_LEVEL_HIGH>;
+ interrupts = <GIC_ESPI 97 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&gcc GCC_QUPV3_WRAP0_S5_CLK>;
clock-names = "se";
interconnects = <&clk_virt MASTER_QUP_CORE_0 QCOM_ICC_TAG_ALWAYS
@@ -2191,7 +2191,7 @@ &config_noc SLAVE_QUP_0 QCOM_ICC_TAG_ALWAYS>,
i2c6: i2c@b98000 {
compatible = "qcom,geni-i2c";
reg = <0x0 0x00b98000 0x0 0x4000>;
- interrupts = <GIC_SPI 1058 IRQ_TYPE_LEVEL_HIGH>;
+ interrupts = <GIC_ESPI 98 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&gcc GCC_QUPV3_WRAP0_S6_CLK>;
clock-names = "se";
interconnects = <&clk_virt MASTER_QUP_CORE_0 QCOM_ICC_TAG_ALWAYS
@@ -2218,7 +2218,7 @@ &config_noc SLAVE_QUP_0 QCOM_ICC_TAG_ALWAYS>,
spi6: spi@b98000 {
compatible = "qcom,geni-spi";
reg = <0x0 0x00b98000 0x0 0x4000>;
- interrupts = <GIC_SPI 1058 IRQ_TYPE_LEVEL_HIGH>;
+ interrupts = <GIC_ESPI 98 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&gcc GCC_QUPV3_WRAP0_S6_CLK>;
clock-names = "se";
interconnects = <&clk_virt MASTER_QUP_CORE_0 QCOM_ICC_TAG_ALWAYS
@@ -2245,7 +2245,7 @@ &config_noc SLAVE_QUP_0 QCOM_ICC_TAG_ALWAYS>,
i2c7: i2c@b9c000 {
compatible = "qcom,geni-i2c";
reg = <0x0 0x00b9c000 0x0 0x4000>;
- interrupts = <GIC_SPI 1059 IRQ_TYPE_LEVEL_HIGH>;
+ interrupts = <GIC_ESPI 99 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&gcc GCC_QUPV3_WRAP0_S7_CLK>;
clock-names = "se";
interconnects = <&clk_virt MASTER_QUP_CORE_0 QCOM_ICC_TAG_ALWAYS
@@ -2272,7 +2272,7 @@ &config_noc SLAVE_QUP_0 QCOM_ICC_TAG_ALWAYS>,
spi7: spi@b9c000 {
compatible = "qcom,geni-spi";
reg = <0x0 0x00b9c000 0x0 0x4000>;
- interrupts = <GIC_SPI 1059 IRQ_TYPE_LEVEL_HIGH>;
+ interrupts = <GIC_ESPI 99 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&gcc GCC_QUPV3_WRAP0_S7_CLK>;
clock-names = "se";
interconnects = <&clk_virt MASTER_QUP_CORE_0 QCOM_ICC_TAG_ALWAYS
---
base-commit: ec039126b7fac4e3af35ebccaa7c6f9b6875ba81
change-id: 20260611-glymur-geni-irqs-1f796376a62d
Best regards,
--
Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
^ permalink raw reply related
* Re: [PATCH v3 04/18] firmware: qcom: scm: Add minidump SRAM support
From: Mukesh Ojha @ 2026-06-11 17:24 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Robert Marko, Guru Das Srinagesh,
cros-qcom-dts-watchers, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <004d6bd1-2800-42d5-a6be-1fa69a06194c@oss.qualcomm.com>
On Thu, Jun 11, 2026 at 01:45:53PM +0200, Konrad Dybcio wrote:
> On 5/22/26 9:49 PM, Mukesh Ojha wrote:
> > 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>
> > ---
>
> [...]
>
>
> > + for (i = 0; i < ARRAY_SIZE(minidump_dest_map); i++)
> > + if (sysfs_streq(val, minidump_dest_map[i].name))
>
> I'm not sure about sysfs_streq() specifically, but otherwise this lgtm
It is used in quite a few places for the same purpose. Am I missing something?
--
-Mukesh Ojha
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: hwmon: pmbus: ti,lm25066: add current limit properties
From: Conor Dooley @ 2026-06-11 17:27 UTC (permalink / raw)
To: Potin Lai
Cc: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Zev Weiss, linux-hwmon, devicetree, linux-kernel, Cosmo Chou,
Mike Hsieh, Potin Lai
In-Reply-To: <20260611-lm25066-cl-config-v1-1-02e567bf3d91@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1664 bytes --]
On Thu, Jun 11, 2026 at 05:58:44PM +0800, Potin Lai wrote:
> Add mutually exclusive 'ti,cl-smbus-high' and 'ti,cl-smbus-low' boolean
> properties to configure the device's Current Limit (CL) behavior using
> SMBus settings instead of physical pins.
>
> Signed-off-by: Potin Lai <potin.lai.pt@gmail.com>
> ---
> .../devicetree/bindings/hwmon/pmbus/ti,lm25066.yaml | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/hwmon/pmbus/ti,lm25066.yaml b/Documentation/devicetree/bindings/hwmon/pmbus/ti,lm25066.yaml
> index a20f140dc79a..95ea7c26dec2 100644
> --- a/Documentation/devicetree/bindings/hwmon/pmbus/ti,lm25066.yaml
> +++ b/Documentation/devicetree/bindings/hwmon/pmbus/ti,lm25066.yaml
> @@ -46,6 +46,26 @@ properties:
>
> additionalProperties: false
>
> + ti,cl-smbus-high:
> + description: |
> + Configure the Current Limit (CL) to use the SMBus high setting.
> + type: boolean
> +
> + ti,cl-smbus-low:
> + description: |
> + Configure the Current Limit (CL) to use the SMBus low setting.
> + type: boolean
What's smbus specific about this? If the pin was connected to a GPIO,
you'd then need to have different properties or use these ones with an
inaccurate name.
Please also spell out "current-limit".
pw-bot: changes-requested
Thanks,
Conor.
> +
> +dependencies:
> + ti,cl-smbus-high:
> + not:
> + required:
> + - ti,cl-smbus-low
> + ti,cl-smbus-low:
> + not:
> + required:
> + - ti,cl-smbus-high
> +
> required:
> - compatible
> - reg
>
> --
> 2.52.0
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: clock: ultrarisc: Add DP1000 Clock Controller
From: Conor Dooley @ 2026-06-11 17:29 UTC (permalink / raw)
To: wangjia
Cc: Michael Turquette, Stephen Boyd, Brian Masney, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-clk, devicetree,
linux-kernel
In-Reply-To: <20260611-ultrarisc-clock-v1-1-2d93ebb4cc13@ultrarisc.com>
[-- Attachment #1: Type: text/plain, Size: 4984 bytes --]
On Thu, Jun 11, 2026 at 05:40:53PM +0800, Jia Wang via B4 Relay wrote:
> From: Jia Wang <wangjia@ultrarisc.com>
>
> Add doc for the clock controller on the UltraRISC DP1000 RISC-V SoC.
>
> Signed-off-by: Jia Wang <wangjia@ultrarisc.com>
> ---
> .../bindings/clock/ultrarisc,dp1000-clk.yaml | 72 ++++++++++++++++++++++
> MAINTAINERS | 7 +++
> include/dt-bindings/clock/ultrarisc,dp1000-clk.h | 29 +++++++++
> 3 files changed, 108 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/clock/ultrarisc,dp1000-clk.yaml b/Documentation/devicetree/bindings/clock/ultrarisc,dp1000-clk.yaml
> new file mode 100644
> index 000000000000..d4d3d851a079
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/ultrarisc,dp1000-clk.yaml
> @@ -0,0 +1,72 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/clock/ultrarisc,dp1000-clk.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: UltraRISC DP1000 Clock Controller
> +
> +maintainers:
> + - Jia Wang <wangjia@ultrarisc.com>
> +
> +description: |
> + The UltraRISC DP1000 clock controller is driven from a single external
> + oscillator input. It provides a system PLL with fractional multiplier
> + and post-divider stages, several fixed-ratio derived clocks for
> + the on-chip subsystem, Clock Configuration Register (CCR) divider
> + outputs for GMAC and the UART, I2C, and SPI root clocks, and
> + per-instance gate clocks for UART0-3, I2C0-3, and SPI0-1.
> +
> + All available clocks are defined as preprocessor macros in
> + include/dt-bindings/clock/ultrarisc,dp1000-clk.h
> +
> +properties:
> + compatible:
> + const: ultrarisc,dp1000-clk
> +
> + reg:
> + maxItems: 1
> +
> + clocks:
> + maxItems: 1
> + description:
> + External oscillator input clock used as the parent of the PLLs.
> +
> + clock-names:
> + items:
> + - const: osc
Clock names don't really have any value when you have one input clock.
> +
> + "#clock-cells":
> + const: 1
> +
> +required:
> + - compatible
> + - reg
> + - clocks
> + - clock-names
> + - "#clock-cells"
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/clock/ultrarisc,dp1000-clk.h>
> +
> + osc: oscillator {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <24000000>;
> + };
Drop this whole node please.
> +
> + soc {
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + clock-controller@11080000 {
> + compatible = "ultrarisc,dp1000-clk";
> + reg = <0x0 0x11080000 0x0 0x1000>;
> + clocks = <&osc>;
> + clock-names = "osc";
> + #clock-cells = <1>;
> + };
> + };
> diff --git a/MAINTAINERS b/MAINTAINERS
> index e035a3be797c..3331f1edf002 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -27357,6 +27357,13 @@ S: Maintained
> F: drivers/usb/common/ulpi.c
> F: include/linux/ulpi/
>
> +ULTRARISC DP1000 CLOCK DRIVER
> +M: Jia Wang <wangjia@ultrarisc.com>
> +L: linux-clk@vger.kernel.org
> +S: Maintained
> +F: Documentation/devicetree/bindings/clock/ultrarisc,dp1000-clk.yaml
> +F: include/dt-bindings/clock/ultrarisc,dp1000-clk.h
> +
> ULTRATRONIK BOARD SUPPORT
> M: Goran Rađenović <goran.radni@gmail.com>
> M: Börge Strümpfel <boerge.struempfel@gmail.com>
> diff --git a/include/dt-bindings/clock/ultrarisc,dp1000-clk.h b/include/dt-bindings/clock/ultrarisc,dp1000-clk.h
> new file mode 100644
> index 000000000000..5e484f652b08
> --- /dev/null
> +++ b/include/dt-bindings/clock/ultrarisc,dp1000-clk.h
> @@ -0,0 +1,29 @@
> +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
> +#ifndef _DT_BINDINGS_CLOCK_ULTRARISC_DP1000_CLK_H
> +#define _DT_BINDINGS_CLOCK_ULTRARISC_DP1000_CLK_H
> +
> +#define DP1000_CLK_SYSPLL 0
> +#define DP1000_CLK_SYSPLL_DIV2 1
> +#define DP1000_CLK_SUBSYS 2
> +#define DP1000_CLK_GMAC 3
> +#define DP1000_CLK_UART_ROOT 4
> +#define DP1000_CLK_I2C_ROOT 5
> +#define DP1000_CLK_SPI_ROOT 6
> +#define DP1000_CLK_PCIE_DBI 7
> +#define DP1000_CLK_PCIEX4_CORE 8
> +#define DP1000_CLK_PCIEX16_CORE 9
> +#define DP1000_CLK_PCIE_AUX 10
> +#define DP1000_CLK_UART0 11
> +#define DP1000_CLK_UART1 12
> +#define DP1000_CLK_UART2 13
> +#define DP1000_CLK_UART3 14
> +#define DP1000_CLK_I2C0 15
> +#define DP1000_CLK_I2C1 16
> +#define DP1000_CLK_I2C2 17
> +#define DP1000_CLK_I2C3 18
> +#define DP1000_CLK_SPI0 19
> +#define DP1000_CLK_SPI1 20
> +
> +#define DP1000_CLK_NUM 21
This is not suitable to have in a binding, move it to the driver if it
is required.
pw-bot: changes-requested
Cheers,
Conor.
> +
> +#endif /* _DT_BINDINGS_CLOCK_ULTRARISC_DP1000_CLK_H */
>
> --
> 2.34.1
>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: spi: nuvoton,ma35d1-qspi: Add Nuvoton MA35D1 QSPI
From: Conor Dooley @ 2026-06-11 17:34 UTC (permalink / raw)
To: Chi-Wen Weng
Cc: broonie, robh, krzk+dt, conor+dt, linux-arm-kernel, linux-spi,
devicetree, linux-kernel, cwweng
In-Reply-To: <20260611091246.2070485-2-cwweng.linux@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2626 bytes --]
On Thu, Jun 11, 2026 at 05:12:45PM +0800, Chi-Wen Weng wrote:
> From: Chi-Wen Weng <cwweng@nuvoton.com>
>
> Add a devicetree binding for the Quad SPI controller found in
> Nuvoton MA35D1 SoCs.
>
> The controller supports SPI memory devices such as SPI NOR and SPI NAND
> flashes. It has one register range, one clock input and one reset line,
> and supports up to two chip selects.
>
> Signed-off-by: Chi-Wen Weng <cwweng@nuvoton.com>
> ---
> .../bindings/spi/nuvoton,ma35d1-qspi.yaml | 62 +++++++++++++++++++
> 1 file changed, 62 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/spi/nuvoton,ma35d1-qspi.yaml
>
> diff --git a/Documentation/devicetree/bindings/spi/nuvoton,ma35d1-qspi.yaml b/Documentation/devicetree/bindings/spi/nuvoton,ma35d1-qspi.yaml
> new file mode 100644
> index 000000000000..d3b36e612eb0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/spi/nuvoton,ma35d1-qspi.yaml
> @@ -0,0 +1,62 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/spi/nuvoton,ma35d1-qspi.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Nuvoton MA35D1 Quad SPI Controller
> +
> +maintainers:
> + - Chi-Wen Weng <cwweng@nuvoton.com>
> +
> +allOf:
> + - $ref: /schemas/spi/spi-controller.yaml#
> +
> +properties:
> + compatible:
> + const: nuvoton,ma35d1-qspi
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 1
> +
> + clocks:
> + maxItems: 1
> +
> + resets:
> + maxItems: 1
> +
> + num-cs:
> + maximum: 2
Missing a default of 2, unless you make the property required.
FWIW, your driver doesn't appear to read this value.
pw-bot: changes-requested
Cheers,
Conor.
> +
> +required:
> + - compatible
> + - reg
> + - clocks
> + - resets
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> + #include <dt-bindings/clock/nuvoton,ma35d1-clk.h>
> + #include <dt-bindings/reset/nuvoton,ma35d1-reset.h>
> +
> + soc {
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + spi@40680000 {
> + compatible = "nuvoton,ma35d1-qspi";
> + reg = <0 0x40680000 0 0x100>;
> + interrupts = <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clk QSPI0_GATE>;
> + resets = <&sys MA35D1_RESET_QSPI0>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + };
> +
> --
> 2.25.1
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH RFC 1/2] dt-bindings: pinctl: amlogic,pinctrl-a4: Add gpio irq property
From: Conor Dooley @ 2026-06-11 17:39 UTC (permalink / raw)
To: xianwei.zhao
Cc: Linus Walleij, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
linux-amlogic, linux-gpio, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <20260611-gpio-to-irq-v1-1-12201716f23f@amlogic.com>
[-- Attachment #1: Type: text/plain, Size: 1305 bytes --]
On Thu, Jun 11, 2026 at 07:54:33AM +0000, Xianwei Zhao via B4 Relay wrote:
> From: Xianwei Zhao <xianwei.zhao@amlogic.com>
>
> Add the hw-irq property for each GPIO bank and enable interrupt-parent
> for pinctrl so that gpiod_to_irq() can translate GPIO lines to IRQs.
Uhhhhh, what? Why can't you just use the normal interrupts property?
>
> Signed-off-by: Xianwei Zhao <xianwei.zhao@amlogic.com>
> ---
> Documentation/devicetree/bindings/pinctrl/amlogic,pinctrl-a4.yaml | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/pinctrl/amlogic,pinctrl-a4.yaml b/Documentation/devicetree/bindings/pinctrl/amlogic,pinctrl-a4.yaml
> index b69db1b95345..65ec9121300e 100644
> --- a/Documentation/devicetree/bindings/pinctrl/amlogic,pinctrl-a4.yaml
> +++ b/Documentation/devicetree/bindings/pinctrl/amlogic,pinctrl-a4.yaml
> @@ -37,6 +37,8 @@ properties:
>
> ranges: true
>
> + interrupt-parent: true
> +
> patternProperties:
> "^gpio@[0-9a-f]+$":
> type: object
> @@ -65,6 +67,9 @@ patternProperties:
> gpio-ranges:
> maxItems: 1
>
> + hw-irq:
> + $ref: /schemas/types.yaml#/definitions/uint32
> +
> required:
> - reg
> - reg-names
>
> --
> 2.52.0
>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH] dt-bindings: vendor-prefixes: add Gira
From: Conor Dooley @ 2026-06-11 17:40 UTC (permalink / raw)
To: Lucas Stach
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, devicetree,
kernel
In-Reply-To: <20260610213047.500701-1-l.stach@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 986 bytes --]
On Wed, Jun 10, 2026 at 11:30:47PM +0200, Lucas Stach wrote:
> Add vendor prefix for Gira Giersiepen GmbH & Co. KG
> Link: https://www.gira.de/
>
> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Where is the user?
> ---
> Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> index 28784d66ae7b..2b7bf7d7b9c2 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> @@ -656,6 +656,8 @@ patternProperties:
> description: Giantec Semiconductor, Inc.
> "^giantplus,.*":
> description: Giantplus Technology Co., Ltd.
> + "^gira,.*":
> + description: Gira Giersiepen GmbH & Co. KG
> "^glinet,.*":
> description: GL Intelligence, Inc.
> "^globalscale,.*":
> --
> 2.47.3
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: iio: adc: Add TI ADS1220
From: Conor Dooley @ 2026-06-11 17:47 UTC (permalink / raw)
To: Nguyen Minh Tien
Cc: Jonathan Cameron, linux-iio, devicetree, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, David Lechner, Nuno Sá,
Andy Shevchenko, linux-kernel
In-Reply-To: <20260610151342.44274-2-zizuzacker@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 676 bytes --]
On Wed, Jun 10, 2026 at 10:13:41PM +0700, Nguyen Minh Tien wrote:
> + diff-channels:
> + description:
> + Differential input pair routable by the ADS1220 multiplexer.
> + oneOf:
> + - items: [const: 0, const: 1]
> + - items: [const: 0, const: 2]
> + - items: [const: 0, const: 3]
> + - items: [const: 1, const: 2]
> + - items: [const: 1, const: 3]
> + - items: [const: 2, const: 3]
> + - items: [const: 1, const: 0]
> + - items: [const: 3, const: 2]
Maybe this is a silly question, but what is the difference between 3,2
and 2,3? Which pin is considered the positive value?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH] dt-bindings: iio: accel: Convert lis302 binding to YAML schema
From: Rob Herring @ 2026-06-11 17:48 UTC (permalink / raw)
To: Conor Dooley
Cc: Jonathan Cameron, Md Shofiqul Islam, linux-iio, devicetree,
dlechner, nuno.sa, andy, krzk+dt, conor+dt, krzk, linux-kernel
In-Reply-To: <20260611-spoken-prewar-b5a4b94787cd@spud>
On Thu, Jun 11, 2026 at 12:09 PM Conor Dooley <conor@kernel.org> wrote:
>
> On Thu, Jun 11, 2026 at 02:06:40PM +0100, Jonathan Cameron wrote:
> > On Wed, 10 Jun 2026 17:40:04 +0100
> > Conor Dooley <conor@kernel.org> wrote:
> >
> > > On Wed, Jun 10, 2026 at 04:56:40PM +0100, Jonathan Cameron wrote:
> > > > On Wed, 10 Jun 2026 14:00:51 +0300
> > > > Md Shofiqul Islam <shofiqtest@gmail.com> wrote:
> > > >
> > > > > Convert the STMicroelectronics LIS302DL/LIS3LV02D accelerometer device
> > > > > tree binding from plain text format to YAML schema format.
> > > > >
> > > > > The binding covers two variants matched via their respective bus drivers:
> > > > > - SPI: st,lis302dl-spi (drivers/misc/lis3lv02d/lis3lv02d_spi.c)
> > > > > - I2C: st,lis3lv02d (drivers/misc/lis3lv02d/lis3lv02d_i2c.c)
> > > > >
> > > > > Document all vendor-specific properties read by the driver via
> > > > > of_property_read_*(), including click detection, IRQ routing, free-fall/
> > > > > wake-up engines, high-pass filtering, axis remapping, output data rate,
> > > > > and self-test limits.
> > > > >
> > > > > Also correct the click threshold property names: the driver reads
> > > > > "st,click-threshold-{x,y,z}" but the old .txt documented them as
> > > > > "st,click-thresh-{x,y,z}".
> > > > >
> > > > > Validated with: make dt_binding_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/iio/accel/st,lis302dl.yaml
> > > > >
> > > > > Signed-off-by: Md Shofiqul Islam <shofiqtest@gmail.com>
> > > >
> > > > Hi.
> > > >
> > > > So the conundrum here is whether we want to keep carrying this binding
> > > > as it dates to a previous era.
> > > >
> > > > The driver never made it to IIO and is still in drivers/misc.
> > > > The majority of what is the text document should never have been
> > > > in DT in the first place. I'll guess this dates all the way back
> > > > to the wild west days before we had regular binding review.
> > >
> > > I'd say this should be treated like a staging binding but for the fact
> > > that this has a user in arm. Problem of course is that it's probably
> > > impossible to get that board and so doing any rework is probably not
> > > realistic for this submitter?
> > > Is there a general policy for iio devices in misc? Do they get reworked
> > > to be moved?
> >
> > It is tricky if we have upstream users because the ABI will change on them.
> >
> > I'm not sure how easy this would be to add to the existing st sensors driver
> > as these are very early parts. If we could maybe we'd do so and just deal
> > with the mess of having to disable one or other driver.
> >
> > My gut feeling here is ancient part, let it get dropped in a year or
> > two and not worry about adding support to a standard IIO driver unless
> > anyone actually has hardware and wants to do it.
> >
> > >
> > > The user funnily enough has the binding's click-thresh properties:
> > > st,click-single-x;
> > > st,click-single-y;
> > > st,click-single-z;
> > > st,click-thresh-x = <10>;
> > > st,click-thresh-y = <10>;
> > > st,click-thresh-z = <10>;
> > > st,irq1-click;
> > > st,irq2-click;
> > > st,wakeup-x-lo;
> > > st,wakeup-x-hi;
> > > st,wakeup-y-lo;
> > > st,wakeup-y-hi;
> > > st,wakeup-z-lo;
> > > st,wakeup-z-hi;
> > > Dunno what that ultimately means in terms of which should be used
> > > though.
> > Set those as defaults in the driver if all upstream users have those
> > values and then drop reading them from dt?
>
> Actually, there's more than one user in arm, but there's a mix of
> compatibles and properties used. Probably not really viable unless these
> are all unique compatible + property combinations. FWIW, there's more
> compatibles used than those documented, that fall back to the documented
> ones.
There's only 1 for SPI. For I2C, I guess it is a question of which
driver is used:
drivers/iio/accel/st_accel_i2c.c: .compatible = "st,lis3lv02d",
drivers/misc/lis3lv02d/lis3lv02d_i2c.c: { .compatible = "st,lis3lv02d" },
Rob
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: iio: adc: Add TI ADS1220
From: Conor Dooley @ 2026-06-11 18:00 UTC (permalink / raw)
To: sashiko-reviews; +Cc: Nguyen Minh Tien, robh, conor+dt, devicetree
In-Reply-To: <20260610152903.54FE61F00893@smtp.kernel.org>
[-- Attachment #1: Type: text/plain, Size: 3350 bytes --]
On Wed, Jun 10, 2026 at 03:29:02PM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [High] The `diff-channels` property constraint uses invalid YAML flow sequence syntax (`items: [const: 0, const: 1]`) that will cause a fatal parser error or evaluate to a single-element list with a collapsed duplicate dictionary key.
> - [Medium] The child node regex and `reg` maximum artificially limit the device tree to defining at most 7 channels, despite the hardware supporting 12 unique multiplexer configurations.
> --
>
> commit 2b3665a0096105a4bb2db6266e47dec0a0802cff
> Author: Nguyen Minh Tien <zizuzacker@gmail.com>
>
> dt-bindings: iio: adc: Add TI ADS1220
>
> This commit adds a device tree binding for the TI ADS1220 24-bit ADC.
> It describes the SPI device, its per-input channel child nodes,
> external reference selection, and the DRDY interrupt.
>
> > diff --git a/Documentation/devicetree/bindings/iio/adc/ti,ads1220.yaml b/Documentation/devicetree/bindings/iio/adc/ti,ads1220.yaml
> > new file mode 100644
> > index 0000000000000..1fedffc2a1475
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/iio/adc/ti,ads1220.yaml
> [ ... ]
> > +patternProperties:
> > + "^channel@[0-6]$":
> > + $ref: adc.yaml
> > + type: object
> > + description: Represents one ADC input configuration (channel).
> > +
> > + properties:
> > + reg:
> > + minimum: 0
> > + maximum: 6
>
> [Severity: Medium]
> The ADS1220 hardware supports 12 unique multiplexer combinations
> (8 differential pairs and 4 single-ended inputs). Does this regex and
> reg maximum artificially limit the device tree to defining at most 7
> channels?
>
> System integrators might not be able to represent all available
> hardware configurations if this limit is enforced.
>
> [ ... ]
> > + diff-channels:
> > + description:
> > + Differential input pair routable by the ADS1220 multiplexer.
> > + oneOf:
> > + - items: [const: 0, const: 1]
> > + - items: [const: 0, const: 2]
> > + - items: [const: 0, const: 3]
> > + - items: [const: 1, const: 2]
> > + - items: [const: 1, const: 3]
> > + - items: [const: 2, const: 3]
> > + - items: [const: 1, const: 0]
> > + - items: [const: 3, const: 2]
>
> [Severity: High]
> Will this syntax pass the dt_binding_check validation?
>
> In YAML, a flow sequence like [const: 0, const: 1] evaluates to a list
> containing a single implicit mapping with duplicate keys. The dt-schema
> toolchain utilizes a strict parser that typically fails on duplicate
> dictionary keys.
>
> If it did parse, it would likely collapse the duplicate keys into a
> single element, forcing the diff-channels array to have exactly one
> element instead of the expected two.
>
> Would it be better to use a valid flow mapping sequence, such as
> - items: [{const: 0}, {const: 1}]?
dt_binding_check passes actually. Although this syntax has no other
users in the tree. The only other diff-channel user I saw that applied
as tight restrictions as this one spelt it out as
items:
- const: 0
- const: 1
etc but I have no objection to this if it works.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH 0/3] ARM: dts: stm32: lxa: change stdout-path baud rate from 9600 to 115200
From: Ahmad Fatoum @ 2026-06-11 18:12 UTC (permalink / raw)
To: Alexandre Torgue, Maxime Coquelin, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Leonard Göhrs,
Marc Kleine-Budde
Cc: Alexandre Torgue, devicetree, linux-stm32, linux-arm-kernel,
linux-kernel, kernel, Ahmad Fatoum
The LXA boards are the only STM32 boards that set stdout-path = &uart*
instead of explicitly specifying a baud rate.
This would mean the default of 9600 is used, but it goes unnoticed when
booting normally as barebox fixes up a console= line that includes a
baud rate.
When EFI booting GRUB however, GRUB will not pass along the console=
line and thus the board ends up with a 9600 baud Linux console,
confusing users.
This series fixes this. As the device trees were added at different
times, they are fixed each in a separate commit with its own Fixes: tag.
---
Ahmad Fatoum (3):
ARM: dts: stm32: lxa-mc1: change stdout-path baud rate from 9600 to 115200
ARM: dts: stm32: lxa-tac: change stdout-path baud rate from 9600 to 115200
ARM: dts: stm32: fairytux2: change stdout-path baud rate from 9600 to 115200
arch/arm/boot/dts/st/stm32mp153c-lxa-fairytux2.dtsi | 2 +-
arch/arm/boot/dts/st/stm32mp157c-lxa-mc1.dts | 2 +-
arch/arm/boot/dts/st/stm32mp15xc-lxa-tac.dtsi | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
---
base-commit: 4549871118cf616eecdd2d939f78e3b9e1dddc48
change-id: 20260611-lxa-stdout-path-baudrate-7cf454cdae07
Best regards,
--
Ahmad Fatoum <a.fatoum@pengutronix.de>
^ permalink raw reply
* [PATCH 1/3] ARM: dts: stm32: lxa-mc1: change stdout-path baud rate from 9600 to 115200
From: Ahmad Fatoum @ 2026-06-11 18:12 UTC (permalink / raw)
To: Alexandre Torgue, Maxime Coquelin, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Leonard Göhrs,
Marc Kleine-Budde
Cc: Alexandre Torgue, devicetree, linux-stm32, linux-arm-kernel,
linux-kernel, kernel, Ahmad Fatoum
In-Reply-To: <20260611-lxa-stdout-path-baudrate-v1-0-59b60a5069ff@pengutronix.de>
The default baud rate when none is specified is up to the DT consumer.
In the case of the Linux STM32 serial driver, it defaults to 9600 baud,
which differs from the 115200 baud that this board's barebox bootloader
configured.
This went unnoticed, because barebox automatically fixes up a console=
command-line option that looks like this on the LXA boards:
console=ttySTM0,115200n8
This had precedence over the 9600 fallback baud rate.
But when EFI booting a kernel via GRUB, we run into this issue, because
the barebox-provided command-line is disregarded by GRUB.
Fix this by explicitly setting the baud rate to the correct 115200.
Fixes: 666b5ca85cd3 ("ARM: dts: stm32: add STM32MP1-based Linux Automation MC-1 board")
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
---
arch/arm/boot/dts/st/stm32mp157c-lxa-mc1.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/st/stm32mp157c-lxa-mc1.dts b/arch/arm/boot/dts/st/stm32mp157c-lxa-mc1.dts
index eada9cf257be..b3d8eb57aa24 100644
--- a/arch/arm/boot/dts/st/stm32mp157c-lxa-mc1.dts
+++ b/arch/arm/boot/dts/st/stm32mp157c-lxa-mc1.dts
@@ -33,7 +33,7 @@ backlight: backlight {
};
chosen {
- stdout-path = &uart4;
+ stdout-path = "serial0:115200n8";
};
led-controller-0 {
--
2.47.3
^ permalink raw reply related
* [PATCH 2/3] ARM: dts: stm32: lxa-tac: change stdout-path baud rate from 9600 to 115200
From: Ahmad Fatoum @ 2026-06-11 18:12 UTC (permalink / raw)
To: Alexandre Torgue, Maxime Coquelin, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Leonard Göhrs,
Marc Kleine-Budde
Cc: Alexandre Torgue, devicetree, linux-stm32, linux-arm-kernel,
linux-kernel, kernel, Ahmad Fatoum
In-Reply-To: <20260611-lxa-stdout-path-baudrate-v1-0-59b60a5069ff@pengutronix.de>
The default baud rate when none is specified is up to the DT consumer.
In the case of the Linux STM32 serial driver, it defaults to 9600 baud,
which differs from the 115200 baud that this board's barebox bootloader
configured.
This went unnoticed, because barebox automatically fixes up a console=
command-line option that looks like this on the LXA boards:
console=ttySTM0,115200n8
This had precedence over the 9600 fallback baud rate.
But when EFI booting a kernel via GRUB, we run into this issue, because
the barebox-provided command-line is disregarded by GRUB.
Fix this by explicitly setting the baud rate to the correct 115200.
Fixes: 518272af37b2 ("ARM: dts: stm32: lxa-tac: add Linux Automation GmbH TAC")
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
---
arch/arm/boot/dts/st/stm32mp15xc-lxa-tac.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/st/stm32mp15xc-lxa-tac.dtsi b/arch/arm/boot/dts/st/stm32mp15xc-lxa-tac.dtsi
index ab13f0c39892..ddb1657cd785 100644
--- a/arch/arm/boot/dts/st/stm32mp15xc-lxa-tac.dtsi
+++ b/arch/arm/boot/dts/st/stm32mp15xc-lxa-tac.dtsi
@@ -33,7 +33,7 @@ aliases {
};
chosen {
- stdout-path = &uart4;
+ stdout-path = "serial0:115200n8";
};
led-controller-0 {
--
2.47.3
^ permalink raw reply related
* [PATCH 3/3] ARM: dts: stm32: fairytux2: change stdout-path baud rate from 9600 to 115200
From: Ahmad Fatoum @ 2026-06-11 18:12 UTC (permalink / raw)
To: Alexandre Torgue, Maxime Coquelin, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Leonard Göhrs,
Marc Kleine-Budde
Cc: Alexandre Torgue, devicetree, linux-stm32, linux-arm-kernel,
linux-kernel, kernel, Ahmad Fatoum
In-Reply-To: <20260611-lxa-stdout-path-baudrate-v1-0-59b60a5069ff@pengutronix.de>
The default baud rate when none is specified is up to the DT consumer.
In the case of the Linux STM32 serial driver, it defaults to 9600 baud,
which differs from the 115200 baud that this board's barebox bootloader
configured.
This went unnoticed, because barebox automatically fixes up a console=
command-line option that looks like this on the LXA boards:
console=ttySTM0,115200n8
This had precedence over the 9600 fallback baud rate.
But when EFI booting a kernel via GRUB, we run into this issue, because
the barebox-provided command-line is disregarded by GRUB.
Fix this by explicitly setting the baud rate to the correct 115200.
Fixes: 8c6d469f5249 ("ARM: dts: stm32: lxa-fairytux2: add Linux Automation GmbH FairyTux 2")
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
---
arch/arm/boot/dts/st/stm32mp153c-lxa-fairytux2.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/st/stm32mp153c-lxa-fairytux2.dtsi b/arch/arm/boot/dts/st/stm32mp153c-lxa-fairytux2.dtsi
index 7d3a6a3b5d09..d30b626a18c2 100644
--- a/arch/arm/boot/dts/st/stm32mp153c-lxa-fairytux2.dtsi
+++ b/arch/arm/boot/dts/st/stm32mp153c-lxa-fairytux2.dtsi
@@ -28,7 +28,7 @@ aliases {
};
chosen {
- stdout-path = &uart4;
+ stdout-path = "serial0:115200n8";
};
backlight: backlight {
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v5 1/5] dt-bindings: arm: qcom: Document Shikra and its EVK boards
From: Rob Herring @ 2026-06-11 18:18 UTC (permalink / raw)
To: Komal Bajaj
Cc: Bjorn Andersson, Konrad Dybcio, Krzysztof Kozlowski, Conor Dooley,
Vinod Koul, Neil Armstrong, Wesley Cheng, Ulf Hansson,
linux-arm-msm, devicetree, linux-kernel, linux-phy, linux-mmc,
monish.chunara
In-Reply-To: <20260611-shikra-dt-v5-1-103ed26a8529@oss.qualcomm.com>
On Thu, Jun 11, 2026 at 03:40:08PM +0530, Komal Bajaj wrote:
> Shikra is a Qualcomm IoT SoC available in a System-on-Module (SoM)
> form factor. The SoM integrates the Shikra SoC, PMICs, and essential
> passives, and is designed to be mounted on carrier boards.
>
> Three eSoM variant are introduced:
> - CQM: retail variant with integrated modem (PM4125 and PM8005 PMIC)
> - CQS: retail variant without modem (PM4125 and PM8005 PMIC)
> - IQS: industrial-grade variant without modem (PM8150 PMIC)
>
> Each SoM variant pairs with a common EVK carrier board provides debug
> UART, USB, and other peripheral interfaces.
>
> Add compatible strings for the CQ2390M, CQ2390S, IQ2390S SoM variant and
> its corresponding EVK boards.
>
> Signed-off-by: Komal Bajaj <komal.bajaj@oss.qualcomm.com>
Missing Krzysztof's reviewed-by.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox