* Re: [PATCH v3 1/2] dt-bindings: iio: dac: Add AD5529R
From: Rodrigo Alencar @ 2026-06-22 11:51 UTC (permalink / raw)
To: Nuno Sá, Rodrigo Alencar
Cc: Jonathan Cameron, Conor Dooley, Janani Sunil, Janani Sunil,
Lars-Peter Clausen, Michael Hennerich, David Lechner,
Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Jonathan Corbet, Shuah Khan,
linux-iio, devicetree, linux-kernel, linux-doc, Mark Brown
In-Reply-To: <ajkMBh-R_7pYaoAn@nsa>
On 22/06/26 11:29, Nuno Sá wrote:
> On Mon, Jun 22, 2026 at 10:24:05AM +0100, Rodrigo Alencar wrote:
> > On 21/06/26 15:33, Jonathan Cameron wrote:
> > > On Fri, 19 Jun 2026 16:54:11 +0100
> > > Nuno Sá <noname.nuno@gmail.com> wrote:
> > >
> > > > On Fri, Jun 19, 2026 at 03:12:07PM +0100, Conor Dooley wrote:
> > > > > On Fri, Jun 19, 2026 at 02:01:08PM +0100, Nuno Sá wrote:
> > > > > > On Fri, Jun 19, 2026 at 12:40:54PM +0100, Conor Dooley wrote:
> > > > > > > On Fri, Jun 19, 2026 at 12:36:55PM +0100, Conor Dooley wrote:
> > > > > > > > On Fri, Jun 19, 2026 at 12:33:11PM +0200, Janani Sunil wrote:
> > > > > > > > >
> > > > > > > > > On 6/14/26 21:44, Jonathan Cameron wrote:
> > > > > > > > > > On Tue, 9 Jun 2026 16:47:23 +0200
> > > > > > > > > > Janani Sunil <jan.sun97@gmail.com> wrote:
> > > > > > > > > >
> > > > > > > > > > > On 5/26/26 15:11, Rodrigo Alencar wrote:
> > > > > > > > > > > > On 26/05/19 05:42PM, Janani Sunil wrote:
> > > > > > > > > > > > > Devicetree bindings for AD5529R 16 channel 12/16 bit high voltage,
> > > > > > > > > > > > > buffered voltage output digital-to-analog converter (DAC) with an
> > > > > > > > > > > > > integrated precision reference.
> > > > > > > > > > > > ...
> > > > > > > > > > > > Probably others may comment on that, but...
> > > > > > > > > > > >
> > > > > > > > > > > > This parent node may support device addressing for multi-device support through
> > > > > > > > > > > > those ID pins. I suppose that each device may have its own power supplies or
> > > > > > > > > > > > other resources like the toggle pins or reset and enable.
> > > > > > > > > > > >
> > > > > > > > > > > > That way I suppose that an example would look like...
> > > > > > > > > > > > > +
> > > > > > > > > > > > > +patternProperties:
> > > > > > > > > > > > > + "^channel@([0-9]|1[0-5])$":
> > > > > > > > > > > > > + type: object
> > > > > > > > > > > > > + description: Child nodes for individual channel configuration
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + properties:
> > > > > > > > > > > > > + reg:
> > > > > > > > > > > > > + description: Channel number.
> > > > > > > > > > > > > + minimum: 0
> > > > > > > > > > > > > + maximum: 15
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + adi,output-range-microvolt:
> > > > > > > > > > > > > + description: |
> > > > > > > > > > > > > + Output voltage range for this channel as [min, max] in microvolts.
> > > > > > > > > > > > > + If not specified, defaults to 0V to 5V range.
> > > > > > > > > > > > > + oneOf:
> > > > > > > > > > > > > + - items:
> > > > > > > > > > > > > + - const: 0
> > > > > > > > > > > > > + - enum: [5000000, 10000000, 20000000, 40000000]
> > > > > > > > > > > > > + - items:
> > > > > > > > > > > > > + - const: -5000000
> > > > > > > > > > > > > + - const: 5000000
> > > > > > > > > > > > > + - items:
> > > > > > > > > > > > > + - const: -10000000
> > > > > > > > > > > > > + - const: 10000000
> > > > > > > > > > > > > + - items:
> > > > > > > > > > > > > + - const: -15000000
> > > > > > > > > > > > > + - const: 15000000
> > > > > > > > > > > > > + - items:
> > > > > > > > > > > > > + - const: -20000000
> > > > > > > > > > > > > + - const: 20000000
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + required:
> > > > > > > > > > > > > + - reg
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + additionalProperties: false
> > > > > > > > > > > > > +
> > > > > > > > > > > > > +required:
> > > > > > > > > > > > > + - compatible
> > > > > > > > > > > > > + - reg
> > > > > > > > > > > > > + - vdd-supply
> > > > > > > > > > > > > + - avdd-supply
> > > > > > > > > > > > > + - hvdd-supply
> > > > > > > > > > > > > +
> > > > > > > > > > > > > +dependencies:
> > > > > > > > > > > > > + spi-cpha: [ spi-cpol ]
> > > > > > > > > > > > > + spi-cpol: [ spi-cpha ]
> > > > > > > > > > > > > +
> > > > > > > > > > > > > +allOf:
> > > > > > > > > > > > > + - $ref: /schemas/spi/spi-peripheral-props.yaml#
> > > > > > > > > > > > > +
> > > > > > > > > > > > > +unevaluatedProperties: false
> > > > > > > > > > > > > +
> > > > > > > > > > > > > +examples:
> > > > > > > > > > > > > + - |
> > > > > > > > > > > > > + #include <dt-bindings/gpio/gpio.h>
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + spi {
> > > > > > > > > > > > > + #address-cells = <1>;
> > > > > > > > > > > > > + #size-cells = <0>;
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + dac@0 {
> > > > > > > > > > > > > + compatible = "adi,ad5529r-16";
> > > > > > > > > > > > > + reg = <0>;
> > > > > > > > > > > > > + spi-max-frequency = <25000000>;
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + vdd-supply = <&vdd_regulator>;
> > > > > > > > > > > > > + avdd-supply = <&avdd_regulator>;
> > > > > > > > > > > > > + hvdd-supply = <&hvdd_regulator>;
> > > > > > > > > > > > > + hvss-supply = <&hvss_regulator>;
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + reset-gpios = <&gpio0 87 GPIO_ACTIVE_LOW>;
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + #address-cells = <1>;
> > > > > > > > > > > > > + #size-cells = <0>;
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + channel@0 {
> > > > > > > > > > > > > + reg = <0>;
> > > > > > > > > > > > > + adi,output-range-microvolt = <0 5000000>;
> > > > > > > > > > > > > + };
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + channel@1 {
> > > > > > > > > > > > > + reg = <1>;
> > > > > > > > > > > > > + adi,output-range-microvolt = <(-10000000) 10000000>;
> > > > > > > > > > > > > + };
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + channel@2 {
> > > > > > > > > > > > > + reg = <2>;
> > > > > > > > > > > > > + adi,output-range-microvolt = <0 40000000>;
> > > > > > > > > > > > > + };
> > > > > > > > > > > > > + };
> > > > > > > > > > > > > + };
> > > > > > > > > > > > ...
> > > > > > > > > > > >
> > > > > > > > > > > > spi {
> > > > > > > > > > > > #address-cells = <1>;
> > > > > > > > > > > > #size-cells = <0>;
> > > > > > > > > > > >
> > > > > > > > > > > > multi-dac@0 {
> > > > > > > > > > > > compatible = "adi,ad5529r-16";
> > > > > > > > > > > > reg = <0>;
> > > > > > > > > > > > spi-max-frequency = <25000000>;
> > > > > > > > > > > >
> > > > > > > > > > > > #address-cells = <1>;
> > > > > > > > > > > > #size-cells = <0>;
> > > > > > > > > > > >
> > > > > > > > > > > > dac@0 {
> > > > > > > > > > > > reg = <0>;
> > > > > > > > > > > > vdd-supply = <&vdd_regulator>;
> > > > > > > > > > > > avdd-supply = <&avdd_regulator>;
> > > > > > > > > > > > hvdd-supply = <&hvdd_regulator>;
> > > > > > > > > > > > hvss-supply = <&hvss_regulator>;
> > > > > > > > > > > >
> > > > > > > > > > > > reset-gpios = <&gpio0 87 GPIO_ACTIVE_LOW>;
> > > > > > > > > > > >
> > > > > > > > > > > > #address-cells = <1>;
> > > > > > > > > > > > #size-cells = <0>;
> > > > > > > > > > > >
> > > > > > > > > > > > channel@0 {
> > > > > > > > > > > > reg = <0>;
> > > > > > > > > > > > adi,output-range-microvolt = <0 5000000>;
> > > > > > > > > > > > };
> > > > > > > > > > > >
> > > > > > > > > > > > channel@1 {
> > > > > > > > > > > > reg = <1>;
> > > > > > > > > > > > adi,output-range-microvolt = <(-10000000) 10000000>;
> > > > > > > > > > > > };
> > > > > > > > > > > >
> > > > > > > > > > > > channel@2 {
> > > > > > > > > > > > reg = <2>;
> > > > > > > > > > > > adi,output-range-microvolt = <0 40000000>;
> > > > > > > > > > > > };
> > > > > > > > > > > > }
> > > > > > > > > > > >
> > > > > > > > > > > > dac@1 {
> > > > > > > > > > > > reg = <1>;
> > > > > > > > > > > > vdd-supply = <&vdd_regulator>;
> > > > > > > > > > > > avdd-supply = <&avdd_regulator>;
> > > > > > > > > > > > hvdd-supply = <&hvdd_regulator>;
> > > > > > > > > > > > hvss-supply = <&hvss_regulator>;
> > > > > > > > > > > >
> > > > > > > > > > > > reset-gpios = <&gpio0 88 GPIO_ACTIVE_LOW>;
> > > > > > > > > > > >
> > > > > > > > > > > > #address-cells = <1>;
> > > > > > > > > > > > #size-cells = <0>;
> > > > > > > > > > > >
> > > > > > > > > > > > channel@0 {
> > > > > > > > > > > > reg = <0>;
> > > > > > > > > > > > adi,output-range-microvolt = <0 5000000>;
> > > > > > > > > > > > };
> > > > > > > > > > > >
> > > > > > > > > > > > channel@1 {
> > > > > > > > > > > > reg = <1>;
> > > > > > > > > > > > adi,output-range-microvolt = <(-10000000) 10000000>;
> > > > > > > > > > > > };
> > > > > > > > > > > > }
> > > > > > > > > > > > };
> > > > > > > > > > > > };
> > > > > > > > > > > >
> > > > > > > > > > > > then you might need something like:
> > > > > > > > > > > >
> > > > > > > > > > > > patternProperties:
> > > > > > > > > > > > "^dac@[0-3]$":
> > > > > > > > > > > >
> > > > > > > > > > > > and put most of the things under this node pattern.
> > > > > > > > > > > >
> > > > > > > > > > > > So the main driver that you're putting together might need to handle up to four instances.
> > > > > > > > > > > > Even if your current driver cannot handle this, the dt-bindings might need cover that.
> > > > > > > > > > > >
> > > > > > > > > > > > Need to double check if each dac node needs a separate compatible, so you would maybe populate
> > > > > > > > > > > > a platform data to be shared with the child nodes, which would be a separate driver.
> > > > > > > > > > > > (not sure if it would make sense to mix and match ad5529r-16 and ad5529r-12).
> > > > > > > > > > > Hi Rodrigo,
> > > > > > > > > > >
> > > > > > > > > > > Thank you for looking at this.
> > > > > > > > > > >
> > > > > > > > > > > For now, I would prefer to keep the binding scoped to a single AD5529R device instance. The current
> > > > > > > > > > > hardware/use case we have only needs one device node and the driver is written around that model as well.
> > > > > > > > > > > While the device addressing pins could allow multi-device topology, we do not have an actual platform using
> > > > > > > > > > > that configuration at the moment, so I would prefer not to introduce an extra parent/child binding structure
> > > > > > > > > > > speculatively without a validating use case.
> > > > > > > > > > Interesting feature - kind of similar to address control on a typical i2c bus device, or
> > > > > > > > > > looking at it another way a kind of distributed SPI mux.
> > > > > > > > > >
> > > > > > > > > > Challenge of a binding is we need to anticipate the future. So I think we do need something
> > > > > > > > > > like Rodrigo is suggesting even if we only (for now) support a single instance in the driver.
> > > > > > > > > > That would leave the path open to supporting the addressing at a later date.
> > > > > > > > > > An alternative might be to look at it like a chained device setup. In those we pretend there
> > > > > > > > > > is just one device with a lot of channels etc. The snag is that here things are more loosely
> > > > > > > > > > coupled whereas for those devices it tends to be you have to read / write the same register
> > > > > > > > > > in all devices in the chain as one big SPI message.
> > > > > > > > > >
> > > > > > > > > > +CC Mark Brown as he may know of some precedence for this feature. For his reference..
> > > > > > > > > > - Each of these device has 2 ID pins. The SPI transfers have to contain the 2 bit
> > > > > > > > > > value that matches that or they are ignored. Thus a single bus + 1 chip select can
> > > > > > > > > > be used to talk to 4 devices. Question is what that looks like in device tree + I guess
> > > > > > > > > > longer term how to support it cleanly in SPI.
> > > > > > > >
> > > > > > > > I'd swear I have seen this before, from some Microchip devices. Let me
> > > > > > > > see if I can find what I am thinking of...
> > > > > > >
> > > > > > >
> > > > > > > microchip,mcp3911 and microchip,mcp3564 both seem to do this with
> > > > > > > slightly different properties.
> > > > > > >
> > > > > > > microchip,device-addr:
> > > > > > > description: Device address when multiple MCP3911 chips are present on the same SPI bus.
> > > > > > > $ref: /schemas/types.yaml#/definitions/uint32
> > > > > > > enum: [0, 1, 2, 3]
> > > > > > > default: 0
> > > > > > >
> > > > > > > and
> > > > > > >
> > > > > > >
> > > > > > > microchip,hw-device-address:
> > > > > > > $ref: /schemas/types.yaml#/definitions/uint32
> > > > > > > minimum: 0
> > > > > > > maximum: 3
> > > > > > > description:
> > > > > > > The address is set on a per-device basis by fuses in the factory,
> > > > > > > configured on request. If not requested, the fuses are set for 0x1.
> > > > > > > The device address is part of the device markings to avoid
> > > > > > > potential confusion. This address is coded on two bits, so four possible
> > > > > > > addresses are available when multiple devices are present on the same
> > > > > > > SPI bus with only one Chip Select line for all devices.
> > > > > > > Each device communication starts by a CS falling edge, followed by the
> > > > > > > clocking of the device address (BITS[7:6] - top two bits of COMMAND BYTE
> > > > > > > which is first one on the wire).
> > > > > > >
> > > > > > > This sounds exactly like the sort of feature that you're dealing with
> > > > > > > here?
> > > > > > >
> > > > > >
> > > > > > The core idea yes but for this chip, things are a bit more annoying (but
> > > > > > Janani can correct me if I'm wrong). Here, each device can, in theory,
> > > > > > have it's own supplies, pins and at the very least, channels with maybe
> > > > > > different scales. That is why Janani is proposing dac nodes. Given I
> > > > > > honestly don't like much of that "adi,ad5529r-bus" compatible I wondered
> > > > > > about solving this at the spi level.
> > > > > >
> > > > > > Ah and to make it more annoying, we can also mix 12 and 16 bits variants
> > > > > > together in the same bus.
> > > > >
> > > > > I'm definitely missing something, because that property for the
> > > > > microchip devices is not impacted what else is on the bus. AFAICT, you
> > > > > could have an mcp3911 and an mcp3564 on the same bus even though both
> > > > > are completely different devices with different drivers. They have
> > > > > individual device nodes and their own supplies etc etc. These aren't
> > > > > per-channel properties on an adc or dac, they're per child device on a
> > > > > spi bus.
> > > >
> > > > Maybe I'm the one missing something :). IIRC, spi would not allow two
> > > > devices on the same CS right? Because for this chip we would need
> > > > something like:
> > > >
> > > > spi {
> > > > dac@0 {
> > > > reg = <0>;
> > > > adi,pin-id = <0>;
> > > > };
> > > >
> > > > dac@1 {
> > > > reg = <0>; // which seems already problematic?
> > > > adi,pin-id <1>;
> > > > };
> > > >
> > > > ...
> > > >
> > > > //up to 4
> > > > };
> > > Yeah. It's not clear to me how that works for the microchip devices
> > > (I suspect it doesn't!)
> > >
> > > Just thinking as I type, but could we do something a bit nasty with
> > > a gpio mux that doesn't actually switch but represents the GPIO being
> > > shared? Given this is all tied to the spi bus that should all happen
> > > under serializing locks.
> > >
> > > Agreed though that this would be nicer as an SPI thing that let
> > > us specify that a single CS is share by multiple devices and their
> > > is some other signal acting to select which one we are talking to.
> > >
> >
> > If the device-addressing on the same chip-select is to be handled
> > by the spi framework, wouldn't we lose device-specific features?
> >
> > I understand that this multi-device feature is there mostly to extend the
> > channel count from 16 to 32, 48 or 64. I suppose the command:
> >
> > "MULTI DEVICE SW LDAC MODE"
> >
> > exists so that software can update channel values accross multiple devices.
>
> Right! You do have a point! I agree the main driver for a feature like
> this is likely to extend the channel count and effectively "aggregate"
> devices.
>
> But I would say that even with the spi solution the MULTI DEVICE stuff
> should be doable (as we still need a sort of adi,pin-id property).
I don't think we can have something like an IIO buffer shared by multiple
devices. Synchronizing separate devices would be doable with proper hardware
support for this (probably involving an FGPA).
> But yes, I do feel that the whole feature is for aggregation so seeing
> one device with 32 channels is the expectation here? Rather than seeing
> two devices with 16 channels.
Yes, I think aggregation is the whole point there... so that the IIO driver
is multi-device-aware.
--
Kind regards,
Rodrigo Alencar
^ permalink raw reply
* Re: [PATCH 0/4] nfs: remove the fileid field from struct nfs_inode
From: Benjamin Coddington @ 2026-06-22 11:23 UTC (permalink / raw)
To: Jeff Layton
Cc: Trond Myklebust, Anna Schumaker, Jonathan Corbet, Shuah Khan,
linux-nfs, linux-kernel, linux-doc
In-Reply-To: <20260512-nfsino-v1-0-284720522f4c@kernel.org>
On 12 May 2026, at 12:12, Jeff Layton wrote:
> v7.1-rc1 contains patches to make inode->i_ino to be a u64. With this
> change, there is no need to keep a separate "fileid" field in struct
> nfs_inode.
>
> This patchset eliminiates that field, and the inode number hashing
> machinery that is no longer needed. This shaves 8 bytes off of each
> nfs_inode.
>
> Trond/Anna: please consider this for v7.2.
>
> Assisted-by: Claude:claude-opus-4-6
> Signed-off-by: Jeff Layton <jlayton@kernel.org>
Looks good,
Reviewed-by: Benjamin Coddington <bcodding@hammerspace.com>
Ben
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: iio: dac: Add AD5529R
From: Nuno Sá @ 2026-06-22 10:29 UTC (permalink / raw)
To: Rodrigo Alencar
Cc: Jonathan Cameron, Conor Dooley, Janani Sunil, Janani Sunil,
Lars-Peter Clausen, Michael Hennerich, David Lechner,
Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Jonathan Corbet, Shuah Khan,
linux-iio, devicetree, linux-kernel, linux-doc, Mark Brown
In-Reply-To: <5u4dnsgxwcwie45f24cacyzf3dko4srhyyyhcpom6tsvhqtmpc@y7d7gmex6n7k>
On Mon, Jun 22, 2026 at 10:24:05AM +0100, Rodrigo Alencar wrote:
> On 21/06/26 15:33, Jonathan Cameron wrote:
> > On Fri, 19 Jun 2026 16:54:11 +0100
> > Nuno Sá <noname.nuno@gmail.com> wrote:
> >
> > > On Fri, Jun 19, 2026 at 03:12:07PM +0100, Conor Dooley wrote:
> > > > On Fri, Jun 19, 2026 at 02:01:08PM +0100, Nuno Sá wrote:
> > > > > On Fri, Jun 19, 2026 at 12:40:54PM +0100, Conor Dooley wrote:
> > > > > > On Fri, Jun 19, 2026 at 12:36:55PM +0100, Conor Dooley wrote:
> > > > > > > On Fri, Jun 19, 2026 at 12:33:11PM +0200, Janani Sunil wrote:
> > > > > > > >
> > > > > > > > On 6/14/26 21:44, Jonathan Cameron wrote:
> > > > > > > > > On Tue, 9 Jun 2026 16:47:23 +0200
> > > > > > > > > Janani Sunil <jan.sun97@gmail.com> wrote:
> > > > > > > > >
> > > > > > > > > > On 5/26/26 15:11, Rodrigo Alencar wrote:
> > > > > > > > > > > On 26/05/19 05:42PM, Janani Sunil wrote:
> > > > > > > > > > > > Devicetree bindings for AD5529R 16 channel 12/16 bit high voltage,
> > > > > > > > > > > > buffered voltage output digital-to-analog converter (DAC) with an
> > > > > > > > > > > > integrated precision reference.
> > > > > > > > > > > ...
> > > > > > > > > > > Probably others may comment on that, but...
> > > > > > > > > > >
> > > > > > > > > > > This parent node may support device addressing for multi-device support through
> > > > > > > > > > > those ID pins. I suppose that each device may have its own power supplies or
> > > > > > > > > > > other resources like the toggle pins or reset and enable.
> > > > > > > > > > >
> > > > > > > > > > > That way I suppose that an example would look like...
> > > > > > > > > > > > +
> > > > > > > > > > > > +patternProperties:
> > > > > > > > > > > > + "^channel@([0-9]|1[0-5])$":
> > > > > > > > > > > > + type: object
> > > > > > > > > > > > + description: Child nodes for individual channel configuration
> > > > > > > > > > > > +
> > > > > > > > > > > > + properties:
> > > > > > > > > > > > + reg:
> > > > > > > > > > > > + description: Channel number.
> > > > > > > > > > > > + minimum: 0
> > > > > > > > > > > > + maximum: 15
> > > > > > > > > > > > +
> > > > > > > > > > > > + adi,output-range-microvolt:
> > > > > > > > > > > > + description: |
> > > > > > > > > > > > + Output voltage range for this channel as [min, max] in microvolts.
> > > > > > > > > > > > + If not specified, defaults to 0V to 5V range.
> > > > > > > > > > > > + oneOf:
> > > > > > > > > > > > + - items:
> > > > > > > > > > > > + - const: 0
> > > > > > > > > > > > + - enum: [5000000, 10000000, 20000000, 40000000]
> > > > > > > > > > > > + - items:
> > > > > > > > > > > > + - const: -5000000
> > > > > > > > > > > > + - const: 5000000
> > > > > > > > > > > > + - items:
> > > > > > > > > > > > + - const: -10000000
> > > > > > > > > > > > + - const: 10000000
> > > > > > > > > > > > + - items:
> > > > > > > > > > > > + - const: -15000000
> > > > > > > > > > > > + - const: 15000000
> > > > > > > > > > > > + - items:
> > > > > > > > > > > > + - const: -20000000
> > > > > > > > > > > > + - const: 20000000
> > > > > > > > > > > > +
> > > > > > > > > > > > + required:
> > > > > > > > > > > > + - reg
> > > > > > > > > > > > +
> > > > > > > > > > > > + additionalProperties: false
> > > > > > > > > > > > +
> > > > > > > > > > > > +required:
> > > > > > > > > > > > + - compatible
> > > > > > > > > > > > + - reg
> > > > > > > > > > > > + - vdd-supply
> > > > > > > > > > > > + - avdd-supply
> > > > > > > > > > > > + - hvdd-supply
> > > > > > > > > > > > +
> > > > > > > > > > > > +dependencies:
> > > > > > > > > > > > + spi-cpha: [ spi-cpol ]
> > > > > > > > > > > > + spi-cpol: [ spi-cpha ]
> > > > > > > > > > > > +
> > > > > > > > > > > > +allOf:
> > > > > > > > > > > > + - $ref: /schemas/spi/spi-peripheral-props.yaml#
> > > > > > > > > > > > +
> > > > > > > > > > > > +unevaluatedProperties: false
> > > > > > > > > > > > +
> > > > > > > > > > > > +examples:
> > > > > > > > > > > > + - |
> > > > > > > > > > > > + #include <dt-bindings/gpio/gpio.h>
> > > > > > > > > > > > +
> > > > > > > > > > > > + spi {
> > > > > > > > > > > > + #address-cells = <1>;
> > > > > > > > > > > > + #size-cells = <0>;
> > > > > > > > > > > > +
> > > > > > > > > > > > + dac@0 {
> > > > > > > > > > > > + compatible = "adi,ad5529r-16";
> > > > > > > > > > > > + reg = <0>;
> > > > > > > > > > > > + spi-max-frequency = <25000000>;
> > > > > > > > > > > > +
> > > > > > > > > > > > + vdd-supply = <&vdd_regulator>;
> > > > > > > > > > > > + avdd-supply = <&avdd_regulator>;
> > > > > > > > > > > > + hvdd-supply = <&hvdd_regulator>;
> > > > > > > > > > > > + hvss-supply = <&hvss_regulator>;
> > > > > > > > > > > > +
> > > > > > > > > > > > + reset-gpios = <&gpio0 87 GPIO_ACTIVE_LOW>;
> > > > > > > > > > > > +
> > > > > > > > > > > > + #address-cells = <1>;
> > > > > > > > > > > > + #size-cells = <0>;
> > > > > > > > > > > > +
> > > > > > > > > > > > + channel@0 {
> > > > > > > > > > > > + reg = <0>;
> > > > > > > > > > > > + adi,output-range-microvolt = <0 5000000>;
> > > > > > > > > > > > + };
> > > > > > > > > > > > +
> > > > > > > > > > > > + channel@1 {
> > > > > > > > > > > > + reg = <1>;
> > > > > > > > > > > > + adi,output-range-microvolt = <(-10000000) 10000000>;
> > > > > > > > > > > > + };
> > > > > > > > > > > > +
> > > > > > > > > > > > + channel@2 {
> > > > > > > > > > > > + reg = <2>;
> > > > > > > > > > > > + adi,output-range-microvolt = <0 40000000>;
> > > > > > > > > > > > + };
> > > > > > > > > > > > + };
> > > > > > > > > > > > + };
> > > > > > > > > > > ...
> > > > > > > > > > >
> > > > > > > > > > > spi {
> > > > > > > > > > > #address-cells = <1>;
> > > > > > > > > > > #size-cells = <0>;
> > > > > > > > > > >
> > > > > > > > > > > multi-dac@0 {
> > > > > > > > > > > compatible = "adi,ad5529r-16";
> > > > > > > > > > > reg = <0>;
> > > > > > > > > > > spi-max-frequency = <25000000>;
> > > > > > > > > > >
> > > > > > > > > > > #address-cells = <1>;
> > > > > > > > > > > #size-cells = <0>;
> > > > > > > > > > >
> > > > > > > > > > > dac@0 {
> > > > > > > > > > > reg = <0>;
> > > > > > > > > > > vdd-supply = <&vdd_regulator>;
> > > > > > > > > > > avdd-supply = <&avdd_regulator>;
> > > > > > > > > > > hvdd-supply = <&hvdd_regulator>;
> > > > > > > > > > > hvss-supply = <&hvss_regulator>;
> > > > > > > > > > >
> > > > > > > > > > > reset-gpios = <&gpio0 87 GPIO_ACTIVE_LOW>;
> > > > > > > > > > >
> > > > > > > > > > > #address-cells = <1>;
> > > > > > > > > > > #size-cells = <0>;
> > > > > > > > > > >
> > > > > > > > > > > channel@0 {
> > > > > > > > > > > reg = <0>;
> > > > > > > > > > > adi,output-range-microvolt = <0 5000000>;
> > > > > > > > > > > };
> > > > > > > > > > >
> > > > > > > > > > > channel@1 {
> > > > > > > > > > > reg = <1>;
> > > > > > > > > > > adi,output-range-microvolt = <(-10000000) 10000000>;
> > > > > > > > > > > };
> > > > > > > > > > >
> > > > > > > > > > > channel@2 {
> > > > > > > > > > > reg = <2>;
> > > > > > > > > > > adi,output-range-microvolt = <0 40000000>;
> > > > > > > > > > > };
> > > > > > > > > > > }
> > > > > > > > > > >
> > > > > > > > > > > dac@1 {
> > > > > > > > > > > reg = <1>;
> > > > > > > > > > > vdd-supply = <&vdd_regulator>;
> > > > > > > > > > > avdd-supply = <&avdd_regulator>;
> > > > > > > > > > > hvdd-supply = <&hvdd_regulator>;
> > > > > > > > > > > hvss-supply = <&hvss_regulator>;
> > > > > > > > > > >
> > > > > > > > > > > reset-gpios = <&gpio0 88 GPIO_ACTIVE_LOW>;
> > > > > > > > > > >
> > > > > > > > > > > #address-cells = <1>;
> > > > > > > > > > > #size-cells = <0>;
> > > > > > > > > > >
> > > > > > > > > > > channel@0 {
> > > > > > > > > > > reg = <0>;
> > > > > > > > > > > adi,output-range-microvolt = <0 5000000>;
> > > > > > > > > > > };
> > > > > > > > > > >
> > > > > > > > > > > channel@1 {
> > > > > > > > > > > reg = <1>;
> > > > > > > > > > > adi,output-range-microvolt = <(-10000000) 10000000>;
> > > > > > > > > > > };
> > > > > > > > > > > }
> > > > > > > > > > > };
> > > > > > > > > > > };
> > > > > > > > > > >
> > > > > > > > > > > then you might need something like:
> > > > > > > > > > >
> > > > > > > > > > > patternProperties:
> > > > > > > > > > > "^dac@[0-3]$":
> > > > > > > > > > >
> > > > > > > > > > > and put most of the things under this node pattern.
> > > > > > > > > > >
> > > > > > > > > > > So the main driver that you're putting together might need to handle up to four instances.
> > > > > > > > > > > Even if your current driver cannot handle this, the dt-bindings might need cover that.
> > > > > > > > > > >
> > > > > > > > > > > Need to double check if each dac node needs a separate compatible, so you would maybe populate
> > > > > > > > > > > a platform data to be shared with the child nodes, which would be a separate driver.
> > > > > > > > > > > (not sure if it would make sense to mix and match ad5529r-16 and ad5529r-12).
> > > > > > > > > > Hi Rodrigo,
> > > > > > > > > >
> > > > > > > > > > Thank you for looking at this.
> > > > > > > > > >
> > > > > > > > > > For now, I would prefer to keep the binding scoped to a single AD5529R device instance. The current
> > > > > > > > > > hardware/use case we have only needs one device node and the driver is written around that model as well.
> > > > > > > > > > While the device addressing pins could allow multi-device topology, we do not have an actual platform using
> > > > > > > > > > that configuration at the moment, so I would prefer not to introduce an extra parent/child binding structure
> > > > > > > > > > speculatively without a validating use case.
> > > > > > > > > Interesting feature - kind of similar to address control on a typical i2c bus device, or
> > > > > > > > > looking at it another way a kind of distributed SPI mux.
> > > > > > > > >
> > > > > > > > > Challenge of a binding is we need to anticipate the future. So I think we do need something
> > > > > > > > > like Rodrigo is suggesting even if we only (for now) support a single instance in the driver.
> > > > > > > > > That would leave the path open to supporting the addressing at a later date.
> > > > > > > > > An alternative might be to look at it like a chained device setup. In those we pretend there
> > > > > > > > > is just one device with a lot of channels etc. The snag is that here things are more loosely
> > > > > > > > > coupled whereas for those devices it tends to be you have to read / write the same register
> > > > > > > > > in all devices in the chain as one big SPI message.
> > > > > > > > >
> > > > > > > > > +CC Mark Brown as he may know of some precedence for this feature. For his reference..
> > > > > > > > > - Each of these device has 2 ID pins. The SPI transfers have to contain the 2 bit
> > > > > > > > > value that matches that or they are ignored. Thus a single bus + 1 chip select can
> > > > > > > > > be used to talk to 4 devices. Question is what that looks like in device tree + I guess
> > > > > > > > > longer term how to support it cleanly in SPI.
> > > > > > >
> > > > > > > I'd swear I have seen this before, from some Microchip devices. Let me
> > > > > > > see if I can find what I am thinking of...
> > > > > >
> > > > > >
> > > > > > microchip,mcp3911 and microchip,mcp3564 both seem to do this with
> > > > > > slightly different properties.
> > > > > >
> > > > > > microchip,device-addr:
> > > > > > description: Device address when multiple MCP3911 chips are present on the same SPI bus.
> > > > > > $ref: /schemas/types.yaml#/definitions/uint32
> > > > > > enum: [0, 1, 2, 3]
> > > > > > default: 0
> > > > > >
> > > > > > and
> > > > > >
> > > > > >
> > > > > > microchip,hw-device-address:
> > > > > > $ref: /schemas/types.yaml#/definitions/uint32
> > > > > > minimum: 0
> > > > > > maximum: 3
> > > > > > description:
> > > > > > The address is set on a per-device basis by fuses in the factory,
> > > > > > configured on request. If not requested, the fuses are set for 0x1.
> > > > > > The device address is part of the device markings to avoid
> > > > > > potential confusion. This address is coded on two bits, so four possible
> > > > > > addresses are available when multiple devices are present on the same
> > > > > > SPI bus with only one Chip Select line for all devices.
> > > > > > Each device communication starts by a CS falling edge, followed by the
> > > > > > clocking of the device address (BITS[7:6] - top two bits of COMMAND BYTE
> > > > > > which is first one on the wire).
> > > > > >
> > > > > > This sounds exactly like the sort of feature that you're dealing with
> > > > > > here?
> > > > > >
> > > > >
> > > > > The core idea yes but for this chip, things are a bit more annoying (but
> > > > > Janani can correct me if I'm wrong). Here, each device can, in theory,
> > > > > have it's own supplies, pins and at the very least, channels with maybe
> > > > > different scales. That is why Janani is proposing dac nodes. Given I
> > > > > honestly don't like much of that "adi,ad5529r-bus" compatible I wondered
> > > > > about solving this at the spi level.
> > > > >
> > > > > Ah and to make it more annoying, we can also mix 12 and 16 bits variants
> > > > > together in the same bus.
> > > >
> > > > I'm definitely missing something, because that property for the
> > > > microchip devices is not impacted what else is on the bus. AFAICT, you
> > > > could have an mcp3911 and an mcp3564 on the same bus even though both
> > > > are completely different devices with different drivers. They have
> > > > individual device nodes and their own supplies etc etc. These aren't
> > > > per-channel properties on an adc or dac, they're per child device on a
> > > > spi bus.
> > >
> > > Maybe I'm the one missing something :). IIRC, spi would not allow two
> > > devices on the same CS right? Because for this chip we would need
> > > something like:
> > >
> > > spi {
> > > dac@0 {
> > > reg = <0>;
> > > adi,pin-id = <0>;
> > > };
> > >
> > > dac@1 {
> > > reg = <0>; // which seems already problematic?
> > > adi,pin-id <1>;
> > > };
> > >
> > > ...
> > >
> > > //up to 4
> > > };
> > Yeah. It's not clear to me how that works for the microchip devices
> > (I suspect it doesn't!)
> >
> > Just thinking as I type, but could we do something a bit nasty with
> > a gpio mux that doesn't actually switch but represents the GPIO being
> > shared? Given this is all tied to the spi bus that should all happen
> > under serializing locks.
> >
> > Agreed though that this would be nicer as an SPI thing that let
> > us specify that a single CS is share by multiple devices and their
> > is some other signal acting to select which one we are talking to.
> >
>
> If the device-addressing on the same chip-select is to be handled
> by the spi framework, wouldn't we lose device-specific features?
>
> I understand that this multi-device feature is there mostly to extend the
> channel count from 16 to 32, 48 or 64. I suppose the command:
>
> "MULTI DEVICE SW LDAC MODE"
>
> exists so that software can update channel values accross multiple devices.
Right! You do have a point! I agree the main driver for a feature like
this is likely to extend the channel count and effectively "aggregate"
devices.
But I would say that even with the spi solution the MULTI DEVICE stuff
should be doable (as we still need a sort of adi,pin-id property).
But yes, I do feel that the whole feature is for aggregation so seeing
one device with 32 channels is the expectation here? Rather than seeing
two devices with 16 channels.
- Nuno Sá
>
> --
> Kind regards,
>
> Rodrigo Alencar
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: iio: dac: Add AD5529R
From: Nuno Sá @ 2026-06-22 10:17 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Conor Dooley, Janani Sunil, Rodrigo Alencar, Janani Sunil,
Lars-Peter Clausen, Michael Hennerich, David Lechner,
Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Jonathan Corbet, Shuah Khan,
linux-iio, devicetree, linux-kernel, linux-doc, Mark Brown
In-Reply-To: <20260622102722.5900592f@jic23-huawei>
On Mon, Jun 22, 2026 at 10:27:22AM +0100, Jonathan Cameron wrote:
> On Mon, 22 Jun 2026 10:07:01 +0100
> Nuno Sá <noname.nuno@gmail.com> wrote:
>
> > On Sun, Jun 21, 2026 at 07:35:42PM +0100, Conor Dooley wrote:
> > > On Sun, Jun 21, 2026 at 03:33:40PM +0100, Jonathan Cameron wrote:
> > > > On Fri, 19 Jun 2026 16:54:11 +0100
> > > > Nuno Sá <noname.nuno@gmail.com> wrote:
> > > >
> > > > > On Fri, Jun 19, 2026 at 03:12:07PM +0100, Conor Dooley wrote:
> > > > > > On Fri, Jun 19, 2026 at 02:01:08PM +0100, Nuno Sá wrote:
> > > > > > > On Fri, Jun 19, 2026 at 12:40:54PM +0100, Conor Dooley wrote:
> > > > > > > > On Fri, Jun 19, 2026 at 12:36:55PM +0100, Conor Dooley wrote:
> > > > > > > > > On Fri, Jun 19, 2026 at 12:33:11PM +0200, Janani Sunil wrote:
> > > > > > > > > >
> > > > > > > > > > On 6/14/26 21:44, Jonathan Cameron wrote:
> > > > > > > > > > > On Tue, 9 Jun 2026 16:47:23 +0200
> > > > > > > > > > > Janani Sunil <jan.sun97@gmail.com> wrote:
> > > > > > > > > > >
> > > > > > > > > > > > On 5/26/26 15:11, Rodrigo Alencar wrote:
> > > > > > > > > > > > > On 26/05/19 05:42PM, Janani Sunil wrote:
> > > > > > > > > > > > > > Devicetree bindings for AD5529R 16 channel 12/16 bit high voltage,
> > > > > > > > > > > > > > buffered voltage output digital-to-analog converter (DAC) with an
> > > > > > > > > > > > > > integrated precision reference.
> > > > > > > > > > > > > ...
> > > > > > > > > > > > > Probably others may comment on that, but...
> > > > > > > > > > > > >
> > > > > > > > > > > > > This parent node may support device addressing for multi-device support through
> > > > > > > > > > > > > those ID pins. I suppose that each device may have its own power supplies or
> > > > > > > > > > > > > other resources like the toggle pins or reset and enable.
> > > > > > > > > > > > >
> > > > > > > > > > > > > That way I suppose that an example would look like...
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > +patternProperties:
> > > > > > > > > > > > > > + "^channel@([0-9]|1[0-5])$":
> > > > > > > > > > > > > > + type: object
> > > > > > > > > > > > > > + description: Child nodes for individual channel configuration
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + properties:
> > > > > > > > > > > > > > + reg:
> > > > > > > > > > > > > > + description: Channel number.
> > > > > > > > > > > > > > + minimum: 0
> > > > > > > > > > > > > > + maximum: 15
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + adi,output-range-microvolt:
> > > > > > > > > > > > > > + description: |
> > > > > > > > > > > > > > + Output voltage range for this channel as [min, max] in microvolts.
> > > > > > > > > > > > > > + If not specified, defaults to 0V to 5V range.
> > > > > > > > > > > > > > + oneOf:
> > > > > > > > > > > > > > + - items:
> > > > > > > > > > > > > > + - const: 0
> > > > > > > > > > > > > > + - enum: [5000000, 10000000, 20000000, 40000000]
> > > > > > > > > > > > > > + - items:
> > > > > > > > > > > > > > + - const: -5000000
> > > > > > > > > > > > > > + - const: 5000000
> > > > > > > > > > > > > > + - items:
> > > > > > > > > > > > > > + - const: -10000000
> > > > > > > > > > > > > > + - const: 10000000
> > > > > > > > > > > > > > + - items:
> > > > > > > > > > > > > > + - const: -15000000
> > > > > > > > > > > > > > + - const: 15000000
> > > > > > > > > > > > > > + - items:
> > > > > > > > > > > > > > + - const: -20000000
> > > > > > > > > > > > > > + - const: 20000000
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + required:
> > > > > > > > > > > > > > + - reg
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + additionalProperties: false
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > +required:
> > > > > > > > > > > > > > + - compatible
> > > > > > > > > > > > > > + - reg
> > > > > > > > > > > > > > + - vdd-supply
> > > > > > > > > > > > > > + - avdd-supply
> > > > > > > > > > > > > > + - hvdd-supply
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > +dependencies:
> > > > > > > > > > > > > > + spi-cpha: [ spi-cpol ]
> > > > > > > > > > > > > > + spi-cpol: [ spi-cpha ]
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > +allOf:
> > > > > > > > > > > > > > + - $ref: /schemas/spi/spi-peripheral-props.yaml#
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > +unevaluatedProperties: false
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > +examples:
> > > > > > > > > > > > > > + - |
> > > > > > > > > > > > > > + #include <dt-bindings/gpio/gpio.h>
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + spi {
> > > > > > > > > > > > > > + #address-cells = <1>;
> > > > > > > > > > > > > > + #size-cells = <0>;
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + dac@0 {
> > > > > > > > > > > > > > + compatible = "adi,ad5529r-16";
> > > > > > > > > > > > > > + reg = <0>;
> > > > > > > > > > > > > > + spi-max-frequency = <25000000>;
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + vdd-supply = <&vdd_regulator>;
> > > > > > > > > > > > > > + avdd-supply = <&avdd_regulator>;
> > > > > > > > > > > > > > + hvdd-supply = <&hvdd_regulator>;
> > > > > > > > > > > > > > + hvss-supply = <&hvss_regulator>;
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + reset-gpios = <&gpio0 87 GPIO_ACTIVE_LOW>;
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + #address-cells = <1>;
> > > > > > > > > > > > > > + #size-cells = <0>;
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + channel@0 {
> > > > > > > > > > > > > > + reg = <0>;
> > > > > > > > > > > > > > + adi,output-range-microvolt = <0 5000000>;
> > > > > > > > > > > > > > + };
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + channel@1 {
> > > > > > > > > > > > > > + reg = <1>;
> > > > > > > > > > > > > > + adi,output-range-microvolt = <(-10000000) 10000000>;
> > > > > > > > > > > > > > + };
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + channel@2 {
> > > > > > > > > > > > > > + reg = <2>;
> > > > > > > > > > > > > > + adi,output-range-microvolt = <0 40000000>;
> > > > > > > > > > > > > > + };
> > > > > > > > > > > > > > + };
> > > > > > > > > > > > > > + };
> > > > > > > > > > > > > ...
> > > > > > > > > > > > >
> > > > > > > > > > > > > spi {
> > > > > > > > > > > > > #address-cells = <1>;
> > > > > > > > > > > > > #size-cells = <0>;
> > > > > > > > > > > > >
> > > > > > > > > > > > > multi-dac@0 {
> > > > > > > > > > > > > compatible = "adi,ad5529r-16";
> > > > > > > > > > > > > reg = <0>;
> > > > > > > > > > > > > spi-max-frequency = <25000000>;
> > > > > > > > > > > > >
> > > > > > > > > > > > > #address-cells = <1>;
> > > > > > > > > > > > > #size-cells = <0>;
> > > > > > > > > > > > >
> > > > > > > > > > > > > dac@0 {
> > > > > > > > > > > > > reg = <0>;
> > > > > > > > > > > > > vdd-supply = <&vdd_regulator>;
> > > > > > > > > > > > > avdd-supply = <&avdd_regulator>;
> > > > > > > > > > > > > hvdd-supply = <&hvdd_regulator>;
> > > > > > > > > > > > > hvss-supply = <&hvss_regulator>;
> > > > > > > > > > > > >
> > > > > > > > > > > > > reset-gpios = <&gpio0 87 GPIO_ACTIVE_LOW>;
> > > > > > > > > > > > >
> > > > > > > > > > > > > #address-cells = <1>;
> > > > > > > > > > > > > #size-cells = <0>;
> > > > > > > > > > > > >
> > > > > > > > > > > > > channel@0 {
> > > > > > > > > > > > > reg = <0>;
> > > > > > > > > > > > > adi,output-range-microvolt = <0 5000000>;
> > > > > > > > > > > > > };
> > > > > > > > > > > > >
> > > > > > > > > > > > > channel@1 {
> > > > > > > > > > > > > reg = <1>;
> > > > > > > > > > > > > adi,output-range-microvolt = <(-10000000) 10000000>;
> > > > > > > > > > > > > };
> > > > > > > > > > > > >
> > > > > > > > > > > > > channel@2 {
> > > > > > > > > > > > > reg = <2>;
> > > > > > > > > > > > > adi,output-range-microvolt = <0 40000000>;
> > > > > > > > > > > > > };
> > > > > > > > > > > > > }
> > > > > > > > > > > > >
> > > > > > > > > > > > > dac@1 {
> > > > > > > > > > > > > reg = <1>;
> > > > > > > > > > > > > vdd-supply = <&vdd_regulator>;
> > > > > > > > > > > > > avdd-supply = <&avdd_regulator>;
> > > > > > > > > > > > > hvdd-supply = <&hvdd_regulator>;
> > > > > > > > > > > > > hvss-supply = <&hvss_regulator>;
> > > > > > > > > > > > >
> > > > > > > > > > > > > reset-gpios = <&gpio0 88 GPIO_ACTIVE_LOW>;
> > > > > > > > > > > > >
> > > > > > > > > > > > > #address-cells = <1>;
> > > > > > > > > > > > > #size-cells = <0>;
> > > > > > > > > > > > >
> > > > > > > > > > > > > channel@0 {
> > > > > > > > > > > > > reg = <0>;
> > > > > > > > > > > > > adi,output-range-microvolt = <0 5000000>;
> > > > > > > > > > > > > };
> > > > > > > > > > > > >
> > > > > > > > > > > > > channel@1 {
> > > > > > > > > > > > > reg = <1>;
> > > > > > > > > > > > > adi,output-range-microvolt = <(-10000000) 10000000>;
> > > > > > > > > > > > > };
> > > > > > > > > > > > > }
> > > > > > > > > > > > > };
> > > > > > > > > > > > > };
> > > > > > > > > > > > >
> > > > > > > > > > > > > then you might need something like:
> > > > > > > > > > > > >
> > > > > > > > > > > > > patternProperties:
> > > > > > > > > > > > > "^dac@[0-3]$":
> > > > > > > > > > > > >
> > > > > > > > > > > > > and put most of the things under this node pattern.
> > > > > > > > > > > > >
> > > > > > > > > > > > > So the main driver that you're putting together might need to handle up to four instances.
> > > > > > > > > > > > > Even if your current driver cannot handle this, the dt-bindings might need cover that.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Need to double check if each dac node needs a separate compatible, so you would maybe populate
> > > > > > > > > > > > > a platform data to be shared with the child nodes, which would be a separate driver.
> > > > > > > > > > > > > (not sure if it would make sense to mix and match ad5529r-16 and ad5529r-12).
> > > > > > > > > > > > Hi Rodrigo,
> > > > > > > > > > > >
> > > > > > > > > > > > Thank you for looking at this.
> > > > > > > > > > > >
> > > > > > > > > > > > For now, I would prefer to keep the binding scoped to a single AD5529R device instance. The current
> > > > > > > > > > > > hardware/use case we have only needs one device node and the driver is written around that model as well.
> > > > > > > > > > > > While the device addressing pins could allow multi-device topology, we do not have an actual platform using
> > > > > > > > > > > > that configuration at the moment, so I would prefer not to introduce an extra parent/child binding structure
> > > > > > > > > > > > speculatively without a validating use case.
> > > > > > > > > > > Interesting feature - kind of similar to address control on a typical i2c bus device, or
> > > > > > > > > > > looking at it another way a kind of distributed SPI mux.
> > > > > > > > > > >
> > > > > > > > > > > Challenge of a binding is we need to anticipate the future. So I think we do need something
> > > > > > > > > > > like Rodrigo is suggesting even if we only (for now) support a single instance in the driver.
> > > > > > > > > > > That would leave the path open to supporting the addressing at a later date.
> > > > > > > > > > > An alternative might be to look at it like a chained device setup. In those we pretend there
> > > > > > > > > > > is just one device with a lot of channels etc. The snag is that here things are more loosely
> > > > > > > > > > > coupled whereas for those devices it tends to be you have to read / write the same register
> > > > > > > > > > > in all devices in the chain as one big SPI message.
> > > > > > > > > > >
> > > > > > > > > > > +CC Mark Brown as he may know of some precedence for this feature. For his reference..
> > > > > > > > > > > - Each of these device has 2 ID pins. The SPI transfers have to contain the 2 bit
> > > > > > > > > > > value that matches that or they are ignored. Thus a single bus + 1 chip select can
> > > > > > > > > > > be used to talk to 4 devices. Question is what that looks like in device tree + I guess
> > > > > > > > > > > longer term how to support it cleanly in SPI.
> > > > > > > > >
> > > > > > > > > I'd swear I have seen this before, from some Microchip devices. Let me
> > > > > > > > > see if I can find what I am thinking of...
> > > > > > > >
> > > > > > > >
> > > > > > > > microchip,mcp3911 and microchip,mcp3564 both seem to do this with
> > > > > > > > slightly different properties.
> > > > > > > >
> > > > > > > > microchip,device-addr:
> > > > > > > > description: Device address when multiple MCP3911 chips are present on the same SPI bus.
> > > > > > > > $ref: /schemas/types.yaml#/definitions/uint32
> > > > > > > > enum: [0, 1, 2, 3]
> > > > > > > > default: 0
> > > > > > > >
> > > > > > > > and
> > > > > > > >
> > > > > > > >
> > > > > > > > microchip,hw-device-address:
> > > > > > > > $ref: /schemas/types.yaml#/definitions/uint32
> > > > > > > > minimum: 0
> > > > > > > > maximum: 3
> > > > > > > > description:
> > > > > > > > The address is set on a per-device basis by fuses in the factory,
> > > > > > > > configured on request. If not requested, the fuses are set for 0x1.
> > > > > > > > The device address is part of the device markings to avoid
> > > > > > > > potential confusion. This address is coded on two bits, so four possible
> > > > > > > > addresses are available when multiple devices are present on the same
> > > > > > > > SPI bus with only one Chip Select line for all devices.
> > > > > > > > Each device communication starts by a CS falling edge, followed by the
> > > > > > > > clocking of the device address (BITS[7:6] - top two bits of COMMAND BYTE
> > > > > > > > which is first one on the wire).
> > > > > > > >
> > > > > > > > This sounds exactly like the sort of feature that you're dealing with
> > > > > > > > here?
> > > > > > > >
> > > > > > >
> > > > > > > The core idea yes but for this chip, things are a bit more annoying (but
> > > > > > > Janani can correct me if I'm wrong). Here, each device can, in theory,
> > > > > > > have it's own supplies, pins and at the very least, channels with maybe
> > > > > > > different scales. That is why Janani is proposing dac nodes. Given I
> > > > > > > honestly don't like much of that "adi,ad5529r-bus" compatible I wondered
> > > > > > > about solving this at the spi level.
> > > > > > >
> > > > > > > Ah and to make it more annoying, we can also mix 12 and 16 bits variants
> > > > > > > together in the same bus.
> > > > > >
> > > > > > I'm definitely missing something, because that property for the
> > > > > > microchip devices is not impacted what else is on the bus. AFAICT, you
> > > > > > could have an mcp3911 and an mcp3564 on the same bus even though both
> > > > > > are completely different devices with different drivers. They have
> > > > > > individual device nodes and their own supplies etc etc. These aren't
> > > > > > per-channel properties on an adc or dac, they're per child device on a
> > > > > > spi bus.
> > > > >
> > > > > Maybe I'm the one missing something :). IIRC, spi would not allow two
> > > > > devices on the same CS right? Because for this chip we would need
> > > > > something like:
> > > > >
> > > > > spi {
> > > > > dac@0 {
> > > > > reg = <0>;
> > > > > adi,pin-id = <0>;
> > > > > };
> > > > >
> > > > > dac@1 {
> > > > > reg = <0>; // which seems already problematic?
> > > > > adi,pin-id <1>;
> > > > > };
> > > > >
> > > > > ...
> > > > >
> > > > > //up to 4
> > > > > };
> > > > Yeah. It's not clear to me how that works for the microchip devices
> > > > (I suspect it doesn't!)
> > > >
> > > > Just thinking as I type, but could we do something a bit nasty with
> > > > a gpio mux that doesn't actually switch but represents the GPIO being
> > > > shared? Given this is all tied to the spi bus that should all happen
> > > > under serializing locks.
> > > >
> > > > Agreed though that this would be nicer as an SPI thing that let
> > > > us specify that a single CS is share by multiple devices and their
> > > > is some other signal acting to select which one we are talking to.
> > >
> > > Whether it works or not, I think it is the more correct approach. Messing
> > > with gpio muxes seems completely wrong, given the chip select may not be
> > > a gpio at all.
> > >
> > > Why do you think the microchip devices won't work? Does the spi core
> > > reject multiple devices with the same chip select being registered or
> > > something like that?
> >
> > Not sure how things work atm. But I'm fairly sure it used to be like
> > that. SPI would reject devices on the same controller and CS. Now that
> > we support more than one CS per controller, not sure how things work.
> We always supported more than one per CS per controller. I guess you mean
> per device.
Obviously :)
>
> >
> > Janani, maybe you can give it a try?
>
> I think we'd need to get it to work with shared gpio proxy which maybe
> will just get set up under the hood. This used to be opt in, but seems
> that changed fairly recently so maybe some of us are working with out
> of date knowledge! I haven't played with it yet, so might not be
> that simple.
>
What I meant for Janani was basically testing two devices on the same CS
as in my pseudo DT. For the GPIO, you mean having a way to select
between devices on the same CS?
For these devices the pin id numbers get's setted up as part of the spi message
so my assumption is that all of them will receive the message but only one acks it.
- Nuno Sá
> Jonathan
>
> >
> > - Nuno Sá
> >
>
^ permalink raw reply
* Re: [PATCH v4 0/5] mm/zswap: Implement per-cgroup proactive writeback
From: Youngjun Park @ 2026-06-22 10:04 UTC (permalink / raw)
To: Hao Jia
Cc: Muchun Song, yosry, akpm, tj, hannes, shakeel.butt, mhocko,
mkoutny, nphamcs, chengming.zhou, roman.gushchin, linux-mm,
linux-kernel, linux-doc, Hao Jia
In-Reply-To: <26a034b3-9cfa-e4f5-eea1-e69fbfff02b4@gmail.com>
On Mon, Jun 22, 2026 at 02:08:49PM +0800, Hao Jia wrote:
>
>
> On 2026/6/21 12:20, Muchun Song wrote:
> >
> >
> > > On Jun 18, 2026, at 12:48, Hao Jia <jiahao.kernel@gmail.com> wrote:
> > >
> > > From: Hao Jia <jiahao1@lixiang.com>
> > >
> > > Zswap currently writes back pages to backing swap reactively, triggered
> > > either by the shrinker or by the pool reaching its size limit. Although
> > > proactive memory reclaim can automatically write back a portion of zswap
> > > pages via the shrinker, it cannot explicitly control the amount of
> > > writeback for a specific memory cgroup. Moreover, proactive memory reclaim
> > > may not always be triggered during a steady state.
> > >
> > > In certain scenarios, it is desirable to trigger writeback in advance to
> > > free up memory. For example, users may want to prepare for an upcoming
> > > memory-intensive workload by flushing cold memory to the backing storage
> > > when the system is relatively idle.
> > >
> > > This patch series introduces a "zswap_writeback_only" key to memory.reclaim
> > > cgroup interface, allowing users to proactively write back cold compressed
> > > data from zswap to the backing swap device. When specified, this key
> > > bypasses standard memory reclaim and exclusively performs proactive zswap
> > > writeback up to the requested budget. If omitted, the default reclaim
> > > behavior remains unchanged.
> > >
> > > Example usage:
> > > # Write back 10MB of compressed data from zswap to the backing swap
> > > echo "10M zswap_writeback_only" > memory.reclaim
> >
> > I’m not entirely sure if other candidate names were already brought up
> > in previous discussions, so my apologies if I'm repeating something here!
> > I do think expanding memory.reclaim is a great approach. That said, I
> > was wondering if we could make the interface a bit more concise while
> > keeping it flexible for future extensions.
> >
> > Essentially, what we want is to control the specific targets of the reclaim
> > process—such as file, anon, or zswap. What do you think about using
> > something like "source=zswap"? For instance, if we want to reclaim 10M from
> > zswap, the command would look like this:
> >
> > echo "10M source=zswap" > memory.reclaim
> >
>
> Thanks for the suggestion. TBH, I personally think your approach makes more
> sense than "zswap_writeback_only".
> Hi YoungJun and Yosry,
>
> I am not sure if this suggestion from Muchun could decouple zswap proactive
> writeback from the swap tiers, or make it easier to migrate to swap tiers in
> the future:
>
> echo "10M source=zswap" > memory.reclaim
> For now, we only specify the source. Later on, the swap tiers feature could
> extend this to control whether to demote to SSD swap, HDD swap, or other
> tiers.
>
> Thanks,
> Hao
Hi Hao!
I also preferred sharing the `memory.reclaim` interface in the future swap demotion,
since it already takes `zswap_writeback_only`.
https://lore.kernel.org/all/aieUQUBHI+E3uNPW@yjaykim-PowerEdge-T330/
Alternatively, we could use a separate interface as Yosry suggested
(e.g. 'swap.tiers.demote'?).
But as Nhat pointed out, allowing user-triggered demotion from the swap tier
perspective could lead to issues like LRU inversion. We probably need to
discuss whether this kind of user-triggered tier demotion will actually be
supported at all.
https://lore.kernel.org/linux-mm/CAKEwX=NfSy0XiD_UMsDOHGCwpE7sYmBmhV4Y9vk_cbnnr6J6PQ@mail.gmail.com/
So, IMHO..
1. If swap tier demotion is NOT exposed.
We can simply choose between "source=" and `zswap_writeback_only` based
on preference. (since there is no need to consider "swap_tier" demotion.)
However, "source=" seems to offer better extensibility if it is expanded
to file and anon use cases in the future.
2. If swap tier demotion IS exposed.
We need to consider integration vs decoupling.
(In my view, This is a design consideration. avoiding potentially
redundant interfaces vs adding a new one if it is architecturally correct.)
2.1 Integration
- Integrating into 'memory.reclaim':
- "source=": Seems easier to integrate by explicitly specifying the target. (Your suggestion)
- 'zswap_writeback_only': Harder to integrate than "source=".
- Integrating into 'memory.swap.tiers.demote'
- 'memory.swap.tiers.demote' could absorb the memory.reclaim functionality.
(But since we only want to allow tiering for vswap+zswap cases like
the zswap writeback feature as we discussed, the reclaim interface behavior might
still need to stay for zswap only.)
2.2 Decoupling
- 'memory.swap.tiers.demote' handles other swap devices (excluding zswap),
while "source=" or 'zswap_writeback_only' handles only zswap.
I think future discussions might lean toward "integrating into
'memory.swap.tiers.demote'". Therefore, from this perspective, either
direction seems fine. However, I slightly prefer "source=" due to its
potential for other extensions.
I don't have a strong preference, though!
Thanks
Youngjun
> If we only want to reclaim 10M from file pages, we could easily extend the
> syntax:
>
> echo "10M source=file" > memory.reclaim
>
> And of course, we could even combine them down the road:
>
> echo "10M source=anon,file" > memory.reclaim
>
> to only reclaim anon and file but bypass zswap.
>
> Just some thoughts of mine.
^ permalink raw reply
* Re: [PATCH v6 15/19] drm/connector: Add new atomic_create_state callback
From: Maxime Ripard @ 2026-06-22 9:53 UTC (permalink / raw)
To: Luca Ceresoli
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Dmitry Baryshkov, Jyri Sarha,
Tomi Valkeinen, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Simon Ser,
Harry Wentland, Melissa Wen, Sebastian Wick, Alex Hung,
Jani Nikula, Rodrigo Vivi, Joonas Lahtinen, Tvrtko Ursulin,
Chen-Yu Tsai, Samuel Holland, Dave Stevenson, Maíra Canal,
Raspberry Pi Kernel Maintenance, dri-devel, linux-doc,
linux-kernel, Daniel Stone, intel-gfx, intel-xe, linux-arm-kernel,
linux-sunxi, Laurent Pinchart
In-Reply-To: <DJD5YZ2K1047.3UJ5QMMLQO6UY@bootlin.com>
[-- Attachment #1: Type: text/plain, Size: 5721 bytes --]
On Fri, Jun 19, 2026 at 06:24:46PM +0200, Luca Ceresoli wrote:
> Hello Maxime, Dmitry, all,
>
> On Tue May 26, 2026 at 6:46 PM CEST, Maxime Ripard wrote:
> > Commit 47b5ac7daa46 ("drm/atomic: Add new atomic_create_state callback
> > to drm_private_obj") introduced a new pattern for allocating drm object
> > states.
> >
> > Instead of relying on the reset() callback, it created a new
> > atomic_create_state hook. This is helpful because reset is a bit
> > overloaded: it's used to create the initial software state, reset it,
> > but also reset the hardware.
> >
> > It can also be used either at probe time, to create the initial state
> > and possibly reset the hardware to an expected default, but also during
> > suspend/resume.
> >
> > Both these cases come with different expectations too: during the
> > initialization, we want to initialize all states, but during
> > suspend/resume, drm_private_states for example are expected to be kept
> > around.
> >
> > reset() also isn't fallible, which makes it harder to handle
> > initialization errors properly. This is only really relevant for some
> > drivers though, since all the helpers for reset only create a new
> > state, and don't touch the hardware at all.
> >
> > It was thus decided to create a new hook that would allocate and
> > initialize a pristine state without any side effect:
> > atomic_create_state to untangle a bit some of it, and to separate the
> > initialization with the actual reset one might need during a
> > suspend/resume.
> >
> > Continue the transition to the new pattern with connectors.
> >
> > Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> > Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> > Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
> > Signed-off-by: Maxime Ripard <mripard@kernel.org>
>
> As I'm rebasing another series on current drm-misc-next, which now includes
> this patch, I ran into troubles and I'm not sure what is the right thing to
> do. I hope you can help me clarify this. See below for my question.
>
> FTR the series I'm rebasing is "drm bridge hotplug", but the question is
> not specific to that series.
>
> > --- a/drivers/gpu/drm/drm_connector.c
> > +++ b/drivers/gpu/drm/drm_connector.c
> > @@ -616,11 +616,19 @@ int drmm_connector_hdmi_init(struct drm_device *dev,
> >
> > /*
> > * drm_connector_attach_max_bpc_property() requires the
> > * connector to have a state.
> > */
> > - if (connector->funcs->reset)
> > + if (connector->funcs->atomic_create_state) {
> > + struct drm_connector_state *state;
> > +
> > + state = connector->funcs->atomic_create_state(connector);
> > + if (IS_ERR(state))
> > + return PTR_ERR(state);
> > +
> > + connector->state = state;
> > + } else if (connector->funcs->reset)
> > connector->funcs->reset(connector);
>
> Here a state is added to connector->state, and that's fine.
>
> However non-HDMI connectors don't get a state created by default.
That's true, but I don't see how this particular patch affects it? The
call sites of reset are now falling back to atomic_create_state, but it
doesn't change anything wrt when reset is (or was?) called, which seems
to be what you're talking about.
> I was hit by this with the drm_bridge_connector which it can add either an
> HDMI or a non-HDMI connector [0]. In the former case it calls
> drmm_connector_hdmi_init(), which creates the state (in the hunk quoted
> above). In the latter case, as I experienced at runtime and confirmed by
> code inspection, it does not create a state: no one calls
> connector->funcs->atomic_create_state.
>
> I suspect this is related to patch 19/19 which converted the
> drm_bridge_connector from drm_atomic_helper_connector_reset() to
> drm_atomic_helper_connector_create_state(), and only the former sets
> 'connector->state = conn_state'.
But it's pretty much the same story here? it changes the implementation,
but it should be called at the same time it used to.
> Generally speaking, looks like a state is created only for HDMI
> connectors.
>
> The hardware I have uses the drm_bridge_connector in the non-HDMI case, so
> the state is not created and this results in a NULL pointer deref later on,
> in my case it's in in drm_atomic_connector_get_property().
>
> Am I missing anything obvious?
>
> For now I've come up with a quick workaround, adding (roughly after
> connector init at [1]):
>
> if (!connector->state)
> connector->state = drm_bridge_connector_create_state(connector);
>
> I'm not sure which would be the best solution. Maybe taking the whole
> atomic_create_state/reset state creation calls [2] from
> drmm_connector_hdmi_init() and hoist them up into
> drmm_connector_init(), so all connectors benefit?
Generally speaking, either drm_mode_config_reset() or
drm_mode_config_create_initial_state will fill $object->state on most
drivers. For dynamic connectors, you'll need to create the initial state
when creating the new connector.
That's what intel (in intel_connector_alloc()) is doing
https://elixir.bootlin.com/linux/v7.0.11/source/drivers/gpu/drm/i915/display/intel_dp_mst.c#L1684
amdgpu through the call to amdgpu_dm_connector_funcs_reset():
https://elixir.bootlin.com/linux/v7.0.11/source/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c#L632
nouveau through the call to mstc->connector.funcs->reset()
https://elixir.bootlin.com/linux/v7.0.11/source/drivers/gpu/drm/nouveau/dispnv50/disp.c#L1262
Would it be possible that it's not a regression but rather that you just noticed it?
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]
^ permalink raw reply
* Re: [PATCH v2 2/4] irqchip/gic-v3: Refactor GIC600 limited to 32bit PA erratum handling
From: Geert Uytterhoeven @ 2026-06-22 9:52 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-pci, Marc Zyngier, Krzysztof Wilczyński, Bjorn Helgaas,
Catalin Marinas, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Lorenzo Pieralisi, Manivannan Sadhasivam,
Rob Herring, Yoshihiro Shimoda, devicetree, linux-arm-kernel,
linux-doc, linux-kernel, linux-renesas-soc
In-Reply-To: <20260618220427.14325-3-marek.vasut+renesas@mailbox.org>
Hi Marek,
On Fri, 19 Jun 2026 at 00:04, Marek Vasut
<marek.vasut+renesas@mailbox.org> wrote:
> The GIC600 implementation is now known to be used on multiple 64-bit
> SoCs, where it has address width for AXI or APB interface configured
> to 32 bit, and it can access only the first 4GiB of physical address
> space.
>
> Rework the handling of the quirk to work around this limitation such
> that new entries can be added purely as new compatible strings, with
> no need to add additional functions or new its_quirk array entries.
>
> Suggested-by: Marc Zyngier <maz@kernel.org>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Thanks for your patch!
> --- a/drivers/irqchip/irq-gic-v3-its.c
> +++ b/drivers/irqchip/irq-gic-v3-its.c
> @@ -4890,10 +4890,17 @@ static bool __maybe_unused its_enable_quirk_hip09_162100801(void *data)
> return true;
> }
>
> -static bool __maybe_unused its_enable_rk3568002(void *data)
> +static const char * const dma_32bit_impaired_platforms[] = {
> +#ifdef CONFIG_ROCKCHIP_ERRATUM_3568002
> + "rockchip,rk3566",
> + "rockchip,rk3568",
> +#endif
> + NULL,
> +};
> +
> +static bool __maybe_unused its_enable_dma32(void *data)
__maybe_unused can be dropped...
> {
> - if (!of_machine_is_compatible("rockchip,rk3566") &&
> - !of_machine_is_compatible("rockchip,rk3568"))
> + if (!of_machine_compatible_match(dma_32bit_impaired_platforms))
> return false;
>
> gfp_flags_quirk |= GFP_DMA32;
> @@ -4968,14 +4975,12 @@ static const struct gic_quirk its_quirks[] = {
> .property = "dma-noncoherent",
> .init = its_set_non_coherent,
> },
> -#ifdef CONFIG_ROCKCHIP_ERRATUM_3568002
... as the #ifdef is removed.
> {
> - .desc = "ITS: Rockchip erratum RK3568002",
> + .desc = "ITS: Broken GIC600 integration limited to 32bit PA",
> .iidr = 0x0201743b,
> .mask = 0xffffffff,
> - .init = its_enable_rk3568002,
> + .init = its_enable_dma32,
> },
> -#endif
> {
> }
> };
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v3 2/2] iio: dac: Add AD5529R DAC driver support
From: Jonathan Cameron @ 2026-06-22 9:31 UTC (permalink / raw)
To: Philipp Zabel
Cc: Janani Sunil, Lars-Peter Clausen, Michael Hennerich,
David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Shuah Khan,
linux-iio, devicetree, linux-kernel, linux-doc, Janani Sunil
In-Reply-To: <9c5104eb504e390c2267e0a17762fdb6d73d75a4.camel@pengutronix.de>
On Mon, 22 Jun 2026 11:12:19 +0200
Philipp Zabel <p.zabel@pengutronix.de> wrote:
> On Di, 2026-05-19 at 17:42 +0200, Janani Sunil wrote:
> > Add support for AD5529R 16-channel, 12/16 bit Digital to Analog Converter
> >
> > Signed-off-by: Janani Sunil <janani.sunil@analog.com>
> > ---
> > MAINTAINERS | 1 +
> > drivers/iio/dac/Kconfig | 17 ++
> > drivers/iio/dac/Makefile | 1 +
> > drivers/iio/dac/ad5529r.c | 527 ++++++++++++++++++++++++++++++++++++++++++++++
> > 4 files changed, 546 insertions(+)
> >
> [...]
> > diff --git a/drivers/iio/dac/ad5529r.c b/drivers/iio/dac/ad5529r.c
> > new file mode 100644
> > index 000000000000..9bb63030db95
> > --- /dev/null
> > +++ b/drivers/iio/dac/ad5529r.c
> > @@ -0,0 +1,527 @@
> [...]
> > +static int ad5529r_reset(struct ad5529r_state *st)
> > +{
> > + struct reset_control *rst;
> > + int ret;
> > +
> > + rst = devm_reset_control_get_optional_exclusive(&st->spi->dev, NULL);
>
> Consider using devm_reset_control_get_optional_exclusive_deasserted()
> to save a few lines, and to make sure the reset line is asserted again
> when the driver is unbound.
Given we can't assume it's a gpio reset at this level (it is but meh,
we shouldn't use the API that way), we can't guarantee it was ever asserted
so we probably have to do a dance of assert then deassert.
This is one of Sashiko's favourite things to complain about so
we ended up doing some digging into that path a few weeks back.
I'd really like that not to be the case so maybe that analysis is wrong.
Jonathan
>
> > + if (IS_ERR(rst))
> > + return PTR_ERR(rst);
> > +
> > + if (rst) {
> > + ret = reset_control_deassert(rst);
> > + if (ret)
> > + return ret;
>
> This branch could then be removed.
>
> > + } else {
> > + ret = regmap_write(st->regmap_8bit, AD5529R_REG_INTERFACE_CONFIG_A,
> > + AD5529R_INTERFACE_CONFIG_A_SW_RESET);
> > + if (ret)
> > + return ret;
> > + }
>
> regards
> Philipp
^ permalink raw reply
* Re: [PATCH v4 0/2] cpufreq: CPPC: add autonomous mode boot parameter support
From: Sumit Gupta @ 2026-06-22 9:28 UTC (permalink / raw)
To: Pierre Gondois, Viresh Kumar
Cc: rafael, ionela.voinescu, zhenglifeng1, zhanjie9, corbet, skhan,
rdunlap, mario.limonciello, linux-pm, linux-doc, linux-kernel,
linux-tegra, treding, jonathanh, vsethi, ksitaraman, sanjayc,
mochs, bbasu, sumitg
In-Reply-To: <35458c15-73b3-45f1-91fe-aa81d85a3efd@arm.com>
On 19/06/26 14:59, Pierre Gondois wrote:
> External email: Use caution opening links or attachments
>
>
> On 6/18/26 07:28, Viresh Kumar wrote:
>> On 16-06-26, 18:22, Sumit Gupta wrote:
>>> The dependency it was waiting on, the "cpufreq: Set policy->min and
>>> max as real QoS constraints" series, is now in linux-pm (linux-next).
>>> I rebased on top and verified autonomous mode works as expected, and
>>> it applies cleanly on the current linux-next.
>>>
>>> The [1] reference in patch 2/2 points to v2 of that series; the merged
>>> version is v3 [2].
>>>
>>> If there are no further comments, please consider acking and queuing
>>> this for the next cycle.
>> I was waiting for CPPC reviewers to provide some feedback.i
>>
>> Jie / Lifeng / Pierre ?
>>
> I think the patchset has the same issue described at:
>
> https://lore.kernel.org/all/86780f97-29ee-4a72-b311-38c89434b707@arm.com/
>
> I don't know if this is important to other persons,
> but IMO it would be preferable to have a solution to this issue
> before adding more functionalities relying on registers that are left
> in an unknown state.
>
> If there are any other opinion ?
>
The concern is valid, but this isn't a new gap. The registers the boot
parameter programs are already writable via existing sysfs:
- auto_sel via auto_select
- EPP via energy_performance_preference_val
So userspace can already leave these in a non-default state across
unload / CPU hotplug in mainline. The boot parameter just sets the
same registers at boot via the same paths.
I am already working on the save/restore change we discussed on
the ospm_nominal_perf thread, as a dedicated follow-up grouping
all OSPM-set registers (ospm_nominal_perf, auto_sel, EPP) together.
I think doing it once uniformly is cleaner.
Both features are already under review, so my preference is to take
them first and add the save/restore on top, rather than merging it
first and respinning both features under it. Either order works for me
if you and the maintainers prefer infra-first.
Thanks,
Sumit
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: iio: dac: Add AD5529R
From: Jonathan Cameron @ 2026-06-22 9:27 UTC (permalink / raw)
To: Nuno Sá
Cc: Conor Dooley, Janani Sunil, Rodrigo Alencar, Janani Sunil,
Lars-Peter Clausen, Michael Hennerich, David Lechner,
Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Jonathan Corbet, Shuah Khan,
linux-iio, devicetree, linux-kernel, linux-doc, Mark Brown
In-Reply-To: <ajj6nEb4tATM3C7b@nsa>
On Mon, 22 Jun 2026 10:07:01 +0100
Nuno Sá <noname.nuno@gmail.com> wrote:
> On Sun, Jun 21, 2026 at 07:35:42PM +0100, Conor Dooley wrote:
> > On Sun, Jun 21, 2026 at 03:33:40PM +0100, Jonathan Cameron wrote:
> > > On Fri, 19 Jun 2026 16:54:11 +0100
> > > Nuno Sá <noname.nuno@gmail.com> wrote:
> > >
> > > > On Fri, Jun 19, 2026 at 03:12:07PM +0100, Conor Dooley wrote:
> > > > > On Fri, Jun 19, 2026 at 02:01:08PM +0100, Nuno Sá wrote:
> > > > > > On Fri, Jun 19, 2026 at 12:40:54PM +0100, Conor Dooley wrote:
> > > > > > > On Fri, Jun 19, 2026 at 12:36:55PM +0100, Conor Dooley wrote:
> > > > > > > > On Fri, Jun 19, 2026 at 12:33:11PM +0200, Janani Sunil wrote:
> > > > > > > > >
> > > > > > > > > On 6/14/26 21:44, Jonathan Cameron wrote:
> > > > > > > > > > On Tue, 9 Jun 2026 16:47:23 +0200
> > > > > > > > > > Janani Sunil <jan.sun97@gmail.com> wrote:
> > > > > > > > > >
> > > > > > > > > > > On 5/26/26 15:11, Rodrigo Alencar wrote:
> > > > > > > > > > > > On 26/05/19 05:42PM, Janani Sunil wrote:
> > > > > > > > > > > > > Devicetree bindings for AD5529R 16 channel 12/16 bit high voltage,
> > > > > > > > > > > > > buffered voltage output digital-to-analog converter (DAC) with an
> > > > > > > > > > > > > integrated precision reference.
> > > > > > > > > > > > ...
> > > > > > > > > > > > Probably others may comment on that, but...
> > > > > > > > > > > >
> > > > > > > > > > > > This parent node may support device addressing for multi-device support through
> > > > > > > > > > > > those ID pins. I suppose that each device may have its own power supplies or
> > > > > > > > > > > > other resources like the toggle pins or reset and enable.
> > > > > > > > > > > >
> > > > > > > > > > > > That way I suppose that an example would look like...
> > > > > > > > > > > > > +
> > > > > > > > > > > > > +patternProperties:
> > > > > > > > > > > > > + "^channel@([0-9]|1[0-5])$":
> > > > > > > > > > > > > + type: object
> > > > > > > > > > > > > + description: Child nodes for individual channel configuration
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + properties:
> > > > > > > > > > > > > + reg:
> > > > > > > > > > > > > + description: Channel number.
> > > > > > > > > > > > > + minimum: 0
> > > > > > > > > > > > > + maximum: 15
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + adi,output-range-microvolt:
> > > > > > > > > > > > > + description: |
> > > > > > > > > > > > > + Output voltage range for this channel as [min, max] in microvolts.
> > > > > > > > > > > > > + If not specified, defaults to 0V to 5V range.
> > > > > > > > > > > > > + oneOf:
> > > > > > > > > > > > > + - items:
> > > > > > > > > > > > > + - const: 0
> > > > > > > > > > > > > + - enum: [5000000, 10000000, 20000000, 40000000]
> > > > > > > > > > > > > + - items:
> > > > > > > > > > > > > + - const: -5000000
> > > > > > > > > > > > > + - const: 5000000
> > > > > > > > > > > > > + - items:
> > > > > > > > > > > > > + - const: -10000000
> > > > > > > > > > > > > + - const: 10000000
> > > > > > > > > > > > > + - items:
> > > > > > > > > > > > > + - const: -15000000
> > > > > > > > > > > > > + - const: 15000000
> > > > > > > > > > > > > + - items:
> > > > > > > > > > > > > + - const: -20000000
> > > > > > > > > > > > > + - const: 20000000
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + required:
> > > > > > > > > > > > > + - reg
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + additionalProperties: false
> > > > > > > > > > > > > +
> > > > > > > > > > > > > +required:
> > > > > > > > > > > > > + - compatible
> > > > > > > > > > > > > + - reg
> > > > > > > > > > > > > + - vdd-supply
> > > > > > > > > > > > > + - avdd-supply
> > > > > > > > > > > > > + - hvdd-supply
> > > > > > > > > > > > > +
> > > > > > > > > > > > > +dependencies:
> > > > > > > > > > > > > + spi-cpha: [ spi-cpol ]
> > > > > > > > > > > > > + spi-cpol: [ spi-cpha ]
> > > > > > > > > > > > > +
> > > > > > > > > > > > > +allOf:
> > > > > > > > > > > > > + - $ref: /schemas/spi/spi-peripheral-props.yaml#
> > > > > > > > > > > > > +
> > > > > > > > > > > > > +unevaluatedProperties: false
> > > > > > > > > > > > > +
> > > > > > > > > > > > > +examples:
> > > > > > > > > > > > > + - |
> > > > > > > > > > > > > + #include <dt-bindings/gpio/gpio.h>
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + spi {
> > > > > > > > > > > > > + #address-cells = <1>;
> > > > > > > > > > > > > + #size-cells = <0>;
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + dac@0 {
> > > > > > > > > > > > > + compatible = "adi,ad5529r-16";
> > > > > > > > > > > > > + reg = <0>;
> > > > > > > > > > > > > + spi-max-frequency = <25000000>;
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + vdd-supply = <&vdd_regulator>;
> > > > > > > > > > > > > + avdd-supply = <&avdd_regulator>;
> > > > > > > > > > > > > + hvdd-supply = <&hvdd_regulator>;
> > > > > > > > > > > > > + hvss-supply = <&hvss_regulator>;
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + reset-gpios = <&gpio0 87 GPIO_ACTIVE_LOW>;
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + #address-cells = <1>;
> > > > > > > > > > > > > + #size-cells = <0>;
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + channel@0 {
> > > > > > > > > > > > > + reg = <0>;
> > > > > > > > > > > > > + adi,output-range-microvolt = <0 5000000>;
> > > > > > > > > > > > > + };
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + channel@1 {
> > > > > > > > > > > > > + reg = <1>;
> > > > > > > > > > > > > + adi,output-range-microvolt = <(-10000000) 10000000>;
> > > > > > > > > > > > > + };
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + channel@2 {
> > > > > > > > > > > > > + reg = <2>;
> > > > > > > > > > > > > + adi,output-range-microvolt = <0 40000000>;
> > > > > > > > > > > > > + };
> > > > > > > > > > > > > + };
> > > > > > > > > > > > > + };
> > > > > > > > > > > > ...
> > > > > > > > > > > >
> > > > > > > > > > > > spi {
> > > > > > > > > > > > #address-cells = <1>;
> > > > > > > > > > > > #size-cells = <0>;
> > > > > > > > > > > >
> > > > > > > > > > > > multi-dac@0 {
> > > > > > > > > > > > compatible = "adi,ad5529r-16";
> > > > > > > > > > > > reg = <0>;
> > > > > > > > > > > > spi-max-frequency = <25000000>;
> > > > > > > > > > > >
> > > > > > > > > > > > #address-cells = <1>;
> > > > > > > > > > > > #size-cells = <0>;
> > > > > > > > > > > >
> > > > > > > > > > > > dac@0 {
> > > > > > > > > > > > reg = <0>;
> > > > > > > > > > > > vdd-supply = <&vdd_regulator>;
> > > > > > > > > > > > avdd-supply = <&avdd_regulator>;
> > > > > > > > > > > > hvdd-supply = <&hvdd_regulator>;
> > > > > > > > > > > > hvss-supply = <&hvss_regulator>;
> > > > > > > > > > > >
> > > > > > > > > > > > reset-gpios = <&gpio0 87 GPIO_ACTIVE_LOW>;
> > > > > > > > > > > >
> > > > > > > > > > > > #address-cells = <1>;
> > > > > > > > > > > > #size-cells = <0>;
> > > > > > > > > > > >
> > > > > > > > > > > > channel@0 {
> > > > > > > > > > > > reg = <0>;
> > > > > > > > > > > > adi,output-range-microvolt = <0 5000000>;
> > > > > > > > > > > > };
> > > > > > > > > > > >
> > > > > > > > > > > > channel@1 {
> > > > > > > > > > > > reg = <1>;
> > > > > > > > > > > > adi,output-range-microvolt = <(-10000000) 10000000>;
> > > > > > > > > > > > };
> > > > > > > > > > > >
> > > > > > > > > > > > channel@2 {
> > > > > > > > > > > > reg = <2>;
> > > > > > > > > > > > adi,output-range-microvolt = <0 40000000>;
> > > > > > > > > > > > };
> > > > > > > > > > > > }
> > > > > > > > > > > >
> > > > > > > > > > > > dac@1 {
> > > > > > > > > > > > reg = <1>;
> > > > > > > > > > > > vdd-supply = <&vdd_regulator>;
> > > > > > > > > > > > avdd-supply = <&avdd_regulator>;
> > > > > > > > > > > > hvdd-supply = <&hvdd_regulator>;
> > > > > > > > > > > > hvss-supply = <&hvss_regulator>;
> > > > > > > > > > > >
> > > > > > > > > > > > reset-gpios = <&gpio0 88 GPIO_ACTIVE_LOW>;
> > > > > > > > > > > >
> > > > > > > > > > > > #address-cells = <1>;
> > > > > > > > > > > > #size-cells = <0>;
> > > > > > > > > > > >
> > > > > > > > > > > > channel@0 {
> > > > > > > > > > > > reg = <0>;
> > > > > > > > > > > > adi,output-range-microvolt = <0 5000000>;
> > > > > > > > > > > > };
> > > > > > > > > > > >
> > > > > > > > > > > > channel@1 {
> > > > > > > > > > > > reg = <1>;
> > > > > > > > > > > > adi,output-range-microvolt = <(-10000000) 10000000>;
> > > > > > > > > > > > };
> > > > > > > > > > > > }
> > > > > > > > > > > > };
> > > > > > > > > > > > };
> > > > > > > > > > > >
> > > > > > > > > > > > then you might need something like:
> > > > > > > > > > > >
> > > > > > > > > > > > patternProperties:
> > > > > > > > > > > > "^dac@[0-3]$":
> > > > > > > > > > > >
> > > > > > > > > > > > and put most of the things under this node pattern.
> > > > > > > > > > > >
> > > > > > > > > > > > So the main driver that you're putting together might need to handle up to four instances.
> > > > > > > > > > > > Even if your current driver cannot handle this, the dt-bindings might need cover that.
> > > > > > > > > > > >
> > > > > > > > > > > > Need to double check if each dac node needs a separate compatible, so you would maybe populate
> > > > > > > > > > > > a platform data to be shared with the child nodes, which would be a separate driver.
> > > > > > > > > > > > (not sure if it would make sense to mix and match ad5529r-16 and ad5529r-12).
> > > > > > > > > > > Hi Rodrigo,
> > > > > > > > > > >
> > > > > > > > > > > Thank you for looking at this.
> > > > > > > > > > >
> > > > > > > > > > > For now, I would prefer to keep the binding scoped to a single AD5529R device instance. The current
> > > > > > > > > > > hardware/use case we have only needs one device node and the driver is written around that model as well.
> > > > > > > > > > > While the device addressing pins could allow multi-device topology, we do not have an actual platform using
> > > > > > > > > > > that configuration at the moment, so I would prefer not to introduce an extra parent/child binding structure
> > > > > > > > > > > speculatively without a validating use case.
> > > > > > > > > > Interesting feature - kind of similar to address control on a typical i2c bus device, or
> > > > > > > > > > looking at it another way a kind of distributed SPI mux.
> > > > > > > > > >
> > > > > > > > > > Challenge of a binding is we need to anticipate the future. So I think we do need something
> > > > > > > > > > like Rodrigo is suggesting even if we only (for now) support a single instance in the driver.
> > > > > > > > > > That would leave the path open to supporting the addressing at a later date.
> > > > > > > > > > An alternative might be to look at it like a chained device setup. In those we pretend there
> > > > > > > > > > is just one device with a lot of channels etc. The snag is that here things are more loosely
> > > > > > > > > > coupled whereas for those devices it tends to be you have to read / write the same register
> > > > > > > > > > in all devices in the chain as one big SPI message.
> > > > > > > > > >
> > > > > > > > > > +CC Mark Brown as he may know of some precedence for this feature. For his reference..
> > > > > > > > > > - Each of these device has 2 ID pins. The SPI transfers have to contain the 2 bit
> > > > > > > > > > value that matches that or they are ignored. Thus a single bus + 1 chip select can
> > > > > > > > > > be used to talk to 4 devices. Question is what that looks like in device tree + I guess
> > > > > > > > > > longer term how to support it cleanly in SPI.
> > > > > > > >
> > > > > > > > I'd swear I have seen this before, from some Microchip devices. Let me
> > > > > > > > see if I can find what I am thinking of...
> > > > > > >
> > > > > > >
> > > > > > > microchip,mcp3911 and microchip,mcp3564 both seem to do this with
> > > > > > > slightly different properties.
> > > > > > >
> > > > > > > microchip,device-addr:
> > > > > > > description: Device address when multiple MCP3911 chips are present on the same SPI bus.
> > > > > > > $ref: /schemas/types.yaml#/definitions/uint32
> > > > > > > enum: [0, 1, 2, 3]
> > > > > > > default: 0
> > > > > > >
> > > > > > > and
> > > > > > >
> > > > > > >
> > > > > > > microchip,hw-device-address:
> > > > > > > $ref: /schemas/types.yaml#/definitions/uint32
> > > > > > > minimum: 0
> > > > > > > maximum: 3
> > > > > > > description:
> > > > > > > The address is set on a per-device basis by fuses in the factory,
> > > > > > > configured on request. If not requested, the fuses are set for 0x1.
> > > > > > > The device address is part of the device markings to avoid
> > > > > > > potential confusion. This address is coded on two bits, so four possible
> > > > > > > addresses are available when multiple devices are present on the same
> > > > > > > SPI bus with only one Chip Select line for all devices.
> > > > > > > Each device communication starts by a CS falling edge, followed by the
> > > > > > > clocking of the device address (BITS[7:6] - top two bits of COMMAND BYTE
> > > > > > > which is first one on the wire).
> > > > > > >
> > > > > > > This sounds exactly like the sort of feature that you're dealing with
> > > > > > > here?
> > > > > > >
> > > > > >
> > > > > > The core idea yes but for this chip, things are a bit more annoying (but
> > > > > > Janani can correct me if I'm wrong). Here, each device can, in theory,
> > > > > > have it's own supplies, pins and at the very least, channels with maybe
> > > > > > different scales. That is why Janani is proposing dac nodes. Given I
> > > > > > honestly don't like much of that "adi,ad5529r-bus" compatible I wondered
> > > > > > about solving this at the spi level.
> > > > > >
> > > > > > Ah and to make it more annoying, we can also mix 12 and 16 bits variants
> > > > > > together in the same bus.
> > > > >
> > > > > I'm definitely missing something, because that property for the
> > > > > microchip devices is not impacted what else is on the bus. AFAICT, you
> > > > > could have an mcp3911 and an mcp3564 on the same bus even though both
> > > > > are completely different devices with different drivers. They have
> > > > > individual device nodes and their own supplies etc etc. These aren't
> > > > > per-channel properties on an adc or dac, they're per child device on a
> > > > > spi bus.
> > > >
> > > > Maybe I'm the one missing something :). IIRC, spi would not allow two
> > > > devices on the same CS right? Because for this chip we would need
> > > > something like:
> > > >
> > > > spi {
> > > > dac@0 {
> > > > reg = <0>;
> > > > adi,pin-id = <0>;
> > > > };
> > > >
> > > > dac@1 {
> > > > reg = <0>; // which seems already problematic?
> > > > adi,pin-id <1>;
> > > > };
> > > >
> > > > ...
> > > >
> > > > //up to 4
> > > > };
> > > Yeah. It's not clear to me how that works for the microchip devices
> > > (I suspect it doesn't!)
> > >
> > > Just thinking as I type, but could we do something a bit nasty with
> > > a gpio mux that doesn't actually switch but represents the GPIO being
> > > shared? Given this is all tied to the spi bus that should all happen
> > > under serializing locks.
> > >
> > > Agreed though that this would be nicer as an SPI thing that let
> > > us specify that a single CS is share by multiple devices and their
> > > is some other signal acting to select which one we are talking to.
> >
> > Whether it works or not, I think it is the more correct approach. Messing
> > with gpio muxes seems completely wrong, given the chip select may not be
> > a gpio at all.
> >
> > Why do you think the microchip devices won't work? Does the spi core
> > reject multiple devices with the same chip select being registered or
> > something like that?
>
> Not sure how things work atm. But I'm fairly sure it used to be like
> that. SPI would reject devices on the same controller and CS. Now that
> we support more than one CS per controller, not sure how things work.
We always supported more than one per CS per controller. I guess you mean
per device.
>
> Janani, maybe you can give it a try?
I think we'd need to get it to work with shared gpio proxy which maybe
will just get set up under the hood. This used to be opt in, but seems
that changed fairly recently so maybe some of us are working with out
of date knowledge! I haven't played with it yet, so might not be
that simple.
Jonathan
>
> - Nuno Sá
>
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: iio: dac: Add AD5529R
From: Rodrigo Alencar @ 2026-06-22 9:24 UTC (permalink / raw)
To: Jonathan Cameron, Nuno Sá
Cc: Conor Dooley, Janani Sunil, Rodrigo Alencar, Janani Sunil,
Lars-Peter Clausen, Michael Hennerich, David Lechner,
Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Jonathan Corbet, Shuah Khan,
linux-iio, devicetree, linux-kernel, linux-doc, Mark Brown
In-Reply-To: <20260621153330.79b6600c@jic23-huawei>
On 21/06/26 15:33, Jonathan Cameron wrote:
> On Fri, 19 Jun 2026 16:54:11 +0100
> Nuno Sá <noname.nuno@gmail.com> wrote:
>
> > On Fri, Jun 19, 2026 at 03:12:07PM +0100, Conor Dooley wrote:
> > > On Fri, Jun 19, 2026 at 02:01:08PM +0100, Nuno Sá wrote:
> > > > On Fri, Jun 19, 2026 at 12:40:54PM +0100, Conor Dooley wrote:
> > > > > On Fri, Jun 19, 2026 at 12:36:55PM +0100, Conor Dooley wrote:
> > > > > > On Fri, Jun 19, 2026 at 12:33:11PM +0200, Janani Sunil wrote:
> > > > > > >
> > > > > > > On 6/14/26 21:44, Jonathan Cameron wrote:
> > > > > > > > On Tue, 9 Jun 2026 16:47:23 +0200
> > > > > > > > Janani Sunil <jan.sun97@gmail.com> wrote:
> > > > > > > >
> > > > > > > > > On 5/26/26 15:11, Rodrigo Alencar wrote:
> > > > > > > > > > On 26/05/19 05:42PM, Janani Sunil wrote:
> > > > > > > > > > > Devicetree bindings for AD5529R 16 channel 12/16 bit high voltage,
> > > > > > > > > > > buffered voltage output digital-to-analog converter (DAC) with an
> > > > > > > > > > > integrated precision reference.
> > > > > > > > > > ...
> > > > > > > > > > Probably others may comment on that, but...
> > > > > > > > > >
> > > > > > > > > > This parent node may support device addressing for multi-device support through
> > > > > > > > > > those ID pins. I suppose that each device may have its own power supplies or
> > > > > > > > > > other resources like the toggle pins or reset and enable.
> > > > > > > > > >
> > > > > > > > > > That way I suppose that an example would look like...
> > > > > > > > > > > +
> > > > > > > > > > > +patternProperties:
> > > > > > > > > > > + "^channel@([0-9]|1[0-5])$":
> > > > > > > > > > > + type: object
> > > > > > > > > > > + description: Child nodes for individual channel configuration
> > > > > > > > > > > +
> > > > > > > > > > > + properties:
> > > > > > > > > > > + reg:
> > > > > > > > > > > + description: Channel number.
> > > > > > > > > > > + minimum: 0
> > > > > > > > > > > + maximum: 15
> > > > > > > > > > > +
> > > > > > > > > > > + adi,output-range-microvolt:
> > > > > > > > > > > + description: |
> > > > > > > > > > > + Output voltage range for this channel as [min, max] in microvolts.
> > > > > > > > > > > + If not specified, defaults to 0V to 5V range.
> > > > > > > > > > > + oneOf:
> > > > > > > > > > > + - items:
> > > > > > > > > > > + - const: 0
> > > > > > > > > > > + - enum: [5000000, 10000000, 20000000, 40000000]
> > > > > > > > > > > + - items:
> > > > > > > > > > > + - const: -5000000
> > > > > > > > > > > + - const: 5000000
> > > > > > > > > > > + - items:
> > > > > > > > > > > + - const: -10000000
> > > > > > > > > > > + - const: 10000000
> > > > > > > > > > > + - items:
> > > > > > > > > > > + - const: -15000000
> > > > > > > > > > > + - const: 15000000
> > > > > > > > > > > + - items:
> > > > > > > > > > > + - const: -20000000
> > > > > > > > > > > + - const: 20000000
> > > > > > > > > > > +
> > > > > > > > > > > + required:
> > > > > > > > > > > + - reg
> > > > > > > > > > > +
> > > > > > > > > > > + additionalProperties: false
> > > > > > > > > > > +
> > > > > > > > > > > +required:
> > > > > > > > > > > + - compatible
> > > > > > > > > > > + - reg
> > > > > > > > > > > + - vdd-supply
> > > > > > > > > > > + - avdd-supply
> > > > > > > > > > > + - hvdd-supply
> > > > > > > > > > > +
> > > > > > > > > > > +dependencies:
> > > > > > > > > > > + spi-cpha: [ spi-cpol ]
> > > > > > > > > > > + spi-cpol: [ spi-cpha ]
> > > > > > > > > > > +
> > > > > > > > > > > +allOf:
> > > > > > > > > > > + - $ref: /schemas/spi/spi-peripheral-props.yaml#
> > > > > > > > > > > +
> > > > > > > > > > > +unevaluatedProperties: false
> > > > > > > > > > > +
> > > > > > > > > > > +examples:
> > > > > > > > > > > + - |
> > > > > > > > > > > + #include <dt-bindings/gpio/gpio.h>
> > > > > > > > > > > +
> > > > > > > > > > > + spi {
> > > > > > > > > > > + #address-cells = <1>;
> > > > > > > > > > > + #size-cells = <0>;
> > > > > > > > > > > +
> > > > > > > > > > > + dac@0 {
> > > > > > > > > > > + compatible = "adi,ad5529r-16";
> > > > > > > > > > > + reg = <0>;
> > > > > > > > > > > + spi-max-frequency = <25000000>;
> > > > > > > > > > > +
> > > > > > > > > > > + vdd-supply = <&vdd_regulator>;
> > > > > > > > > > > + avdd-supply = <&avdd_regulator>;
> > > > > > > > > > > + hvdd-supply = <&hvdd_regulator>;
> > > > > > > > > > > + hvss-supply = <&hvss_regulator>;
> > > > > > > > > > > +
> > > > > > > > > > > + reset-gpios = <&gpio0 87 GPIO_ACTIVE_LOW>;
> > > > > > > > > > > +
> > > > > > > > > > > + #address-cells = <1>;
> > > > > > > > > > > + #size-cells = <0>;
> > > > > > > > > > > +
> > > > > > > > > > > + channel@0 {
> > > > > > > > > > > + reg = <0>;
> > > > > > > > > > > + adi,output-range-microvolt = <0 5000000>;
> > > > > > > > > > > + };
> > > > > > > > > > > +
> > > > > > > > > > > + channel@1 {
> > > > > > > > > > > + reg = <1>;
> > > > > > > > > > > + adi,output-range-microvolt = <(-10000000) 10000000>;
> > > > > > > > > > > + };
> > > > > > > > > > > +
> > > > > > > > > > > + channel@2 {
> > > > > > > > > > > + reg = <2>;
> > > > > > > > > > > + adi,output-range-microvolt = <0 40000000>;
> > > > > > > > > > > + };
> > > > > > > > > > > + };
> > > > > > > > > > > + };
> > > > > > > > > > ...
> > > > > > > > > >
> > > > > > > > > > spi {
> > > > > > > > > > #address-cells = <1>;
> > > > > > > > > > #size-cells = <0>;
> > > > > > > > > >
> > > > > > > > > > multi-dac@0 {
> > > > > > > > > > compatible = "adi,ad5529r-16";
> > > > > > > > > > reg = <0>;
> > > > > > > > > > spi-max-frequency = <25000000>;
> > > > > > > > > >
> > > > > > > > > > #address-cells = <1>;
> > > > > > > > > > #size-cells = <0>;
> > > > > > > > > >
> > > > > > > > > > dac@0 {
> > > > > > > > > > reg = <0>;
> > > > > > > > > > vdd-supply = <&vdd_regulator>;
> > > > > > > > > > avdd-supply = <&avdd_regulator>;
> > > > > > > > > > hvdd-supply = <&hvdd_regulator>;
> > > > > > > > > > hvss-supply = <&hvss_regulator>;
> > > > > > > > > >
> > > > > > > > > > reset-gpios = <&gpio0 87 GPIO_ACTIVE_LOW>;
> > > > > > > > > >
> > > > > > > > > > #address-cells = <1>;
> > > > > > > > > > #size-cells = <0>;
> > > > > > > > > >
> > > > > > > > > > channel@0 {
> > > > > > > > > > reg = <0>;
> > > > > > > > > > adi,output-range-microvolt = <0 5000000>;
> > > > > > > > > > };
> > > > > > > > > >
> > > > > > > > > > channel@1 {
> > > > > > > > > > reg = <1>;
> > > > > > > > > > adi,output-range-microvolt = <(-10000000) 10000000>;
> > > > > > > > > > };
> > > > > > > > > >
> > > > > > > > > > channel@2 {
> > > > > > > > > > reg = <2>;
> > > > > > > > > > adi,output-range-microvolt = <0 40000000>;
> > > > > > > > > > };
> > > > > > > > > > }
> > > > > > > > > >
> > > > > > > > > > dac@1 {
> > > > > > > > > > reg = <1>;
> > > > > > > > > > vdd-supply = <&vdd_regulator>;
> > > > > > > > > > avdd-supply = <&avdd_regulator>;
> > > > > > > > > > hvdd-supply = <&hvdd_regulator>;
> > > > > > > > > > hvss-supply = <&hvss_regulator>;
> > > > > > > > > >
> > > > > > > > > > reset-gpios = <&gpio0 88 GPIO_ACTIVE_LOW>;
> > > > > > > > > >
> > > > > > > > > > #address-cells = <1>;
> > > > > > > > > > #size-cells = <0>;
> > > > > > > > > >
> > > > > > > > > > channel@0 {
> > > > > > > > > > reg = <0>;
> > > > > > > > > > adi,output-range-microvolt = <0 5000000>;
> > > > > > > > > > };
> > > > > > > > > >
> > > > > > > > > > channel@1 {
> > > > > > > > > > reg = <1>;
> > > > > > > > > > adi,output-range-microvolt = <(-10000000) 10000000>;
> > > > > > > > > > };
> > > > > > > > > > }
> > > > > > > > > > };
> > > > > > > > > > };
> > > > > > > > > >
> > > > > > > > > > then you might need something like:
> > > > > > > > > >
> > > > > > > > > > patternProperties:
> > > > > > > > > > "^dac@[0-3]$":
> > > > > > > > > >
> > > > > > > > > > and put most of the things under this node pattern.
> > > > > > > > > >
> > > > > > > > > > So the main driver that you're putting together might need to handle up to four instances.
> > > > > > > > > > Even if your current driver cannot handle this, the dt-bindings might need cover that.
> > > > > > > > > >
> > > > > > > > > > Need to double check if each dac node needs a separate compatible, so you would maybe populate
> > > > > > > > > > a platform data to be shared with the child nodes, which would be a separate driver.
> > > > > > > > > > (not sure if it would make sense to mix and match ad5529r-16 and ad5529r-12).
> > > > > > > > > Hi Rodrigo,
> > > > > > > > >
> > > > > > > > > Thank you for looking at this.
> > > > > > > > >
> > > > > > > > > For now, I would prefer to keep the binding scoped to a single AD5529R device instance. The current
> > > > > > > > > hardware/use case we have only needs one device node and the driver is written around that model as well.
> > > > > > > > > While the device addressing pins could allow multi-device topology, we do not have an actual platform using
> > > > > > > > > that configuration at the moment, so I would prefer not to introduce an extra parent/child binding structure
> > > > > > > > > speculatively without a validating use case.
> > > > > > > > Interesting feature - kind of similar to address control on a typical i2c bus device, or
> > > > > > > > looking at it another way a kind of distributed SPI mux.
> > > > > > > >
> > > > > > > > Challenge of a binding is we need to anticipate the future. So I think we do need something
> > > > > > > > like Rodrigo is suggesting even if we only (for now) support a single instance in the driver.
> > > > > > > > That would leave the path open to supporting the addressing at a later date.
> > > > > > > > An alternative might be to look at it like a chained device setup. In those we pretend there
> > > > > > > > is just one device with a lot of channels etc. The snag is that here things are more loosely
> > > > > > > > coupled whereas for those devices it tends to be you have to read / write the same register
> > > > > > > > in all devices in the chain as one big SPI message.
> > > > > > > >
> > > > > > > > +CC Mark Brown as he may know of some precedence for this feature. For his reference..
> > > > > > > > - Each of these device has 2 ID pins. The SPI transfers have to contain the 2 bit
> > > > > > > > value that matches that or they are ignored. Thus a single bus + 1 chip select can
> > > > > > > > be used to talk to 4 devices. Question is what that looks like in device tree + I guess
> > > > > > > > longer term how to support it cleanly in SPI.
> > > > > >
> > > > > > I'd swear I have seen this before, from some Microchip devices. Let me
> > > > > > see if I can find what I am thinking of...
> > > > >
> > > > >
> > > > > microchip,mcp3911 and microchip,mcp3564 both seem to do this with
> > > > > slightly different properties.
> > > > >
> > > > > microchip,device-addr:
> > > > > description: Device address when multiple MCP3911 chips are present on the same SPI bus.
> > > > > $ref: /schemas/types.yaml#/definitions/uint32
> > > > > enum: [0, 1, 2, 3]
> > > > > default: 0
> > > > >
> > > > > and
> > > > >
> > > > >
> > > > > microchip,hw-device-address:
> > > > > $ref: /schemas/types.yaml#/definitions/uint32
> > > > > minimum: 0
> > > > > maximum: 3
> > > > > description:
> > > > > The address is set on a per-device basis by fuses in the factory,
> > > > > configured on request. If not requested, the fuses are set for 0x1.
> > > > > The device address is part of the device markings to avoid
> > > > > potential confusion. This address is coded on two bits, so four possible
> > > > > addresses are available when multiple devices are present on the same
> > > > > SPI bus with only one Chip Select line for all devices.
> > > > > Each device communication starts by a CS falling edge, followed by the
> > > > > clocking of the device address (BITS[7:6] - top two bits of COMMAND BYTE
> > > > > which is first one on the wire).
> > > > >
> > > > > This sounds exactly like the sort of feature that you're dealing with
> > > > > here?
> > > > >
> > > >
> > > > The core idea yes but for this chip, things are a bit more annoying (but
> > > > Janani can correct me if I'm wrong). Here, each device can, in theory,
> > > > have it's own supplies, pins and at the very least, channels with maybe
> > > > different scales. That is why Janani is proposing dac nodes. Given I
> > > > honestly don't like much of that "adi,ad5529r-bus" compatible I wondered
> > > > about solving this at the spi level.
> > > >
> > > > Ah and to make it more annoying, we can also mix 12 and 16 bits variants
> > > > together in the same bus.
> > >
> > > I'm definitely missing something, because that property for the
> > > microchip devices is not impacted what else is on the bus. AFAICT, you
> > > could have an mcp3911 and an mcp3564 on the same bus even though both
> > > are completely different devices with different drivers. They have
> > > individual device nodes and their own supplies etc etc. These aren't
> > > per-channel properties on an adc or dac, they're per child device on a
> > > spi bus.
> >
> > Maybe I'm the one missing something :). IIRC, spi would not allow two
> > devices on the same CS right? Because for this chip we would need
> > something like:
> >
> > spi {
> > dac@0 {
> > reg = <0>;
> > adi,pin-id = <0>;
> > };
> >
> > dac@1 {
> > reg = <0>; // which seems already problematic?
> > adi,pin-id <1>;
> > };
> >
> > ...
> >
> > //up to 4
> > };
> Yeah. It's not clear to me how that works for the microchip devices
> (I suspect it doesn't!)
>
> Just thinking as I type, but could we do something a bit nasty with
> a gpio mux that doesn't actually switch but represents the GPIO being
> shared? Given this is all tied to the spi bus that should all happen
> under serializing locks.
>
> Agreed though that this would be nicer as an SPI thing that let
> us specify that a single CS is share by multiple devices and their
> is some other signal acting to select which one we are talking to.
>
If the device-addressing on the same chip-select is to be handled
by the spi framework, wouldn't we lose device-specific features?
I understand that this multi-device feature is there mostly to extend the
channel count from 16 to 32, 48 or 64. I suppose the command:
"MULTI DEVICE SW LDAC MODE"
exists so that software can update channel values accross multiple devices.
--
Kind regards,
Rodrigo Alencar
^ permalink raw reply
* Re: [PATCH v3 2/2] iio: dac: Add AD5529R DAC driver support
From: Philipp Zabel @ 2026-06-22 9:12 UTC (permalink / raw)
To: Janani Sunil, Lars-Peter Clausen, Michael Hennerich,
Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet,
Shuah Khan
Cc: linux-iio, devicetree, linux-kernel, linux-doc, Janani Sunil
In-Reply-To: <20260519-ad5529r-driver-v3-2-267c0731aa68@analog.com>
On Di, 2026-05-19 at 17:42 +0200, Janani Sunil wrote:
> Add support for AD5529R 16-channel, 12/16 bit Digital to Analog Converter
>
> Signed-off-by: Janani Sunil <janani.sunil@analog.com>
> ---
> MAINTAINERS | 1 +
> drivers/iio/dac/Kconfig | 17 ++
> drivers/iio/dac/Makefile | 1 +
> drivers/iio/dac/ad5529r.c | 527 ++++++++++++++++++++++++++++++++++++++++++++++
> 4 files changed, 546 insertions(+)
>
[...]
> diff --git a/drivers/iio/dac/ad5529r.c b/drivers/iio/dac/ad5529r.c
> new file mode 100644
> index 000000000000..9bb63030db95
> --- /dev/null
> +++ b/drivers/iio/dac/ad5529r.c
> @@ -0,0 +1,527 @@
[...]
> +static int ad5529r_reset(struct ad5529r_state *st)
> +{
> + struct reset_control *rst;
> + int ret;
> +
> + rst = devm_reset_control_get_optional_exclusive(&st->spi->dev, NULL);
Consider using devm_reset_control_get_optional_exclusive_deasserted()
to save a few lines, and to make sure the reset line is asserted again
when the driver is unbound.
> + if (IS_ERR(rst))
> + return PTR_ERR(rst);
> +
> + if (rst) {
> + ret = reset_control_deassert(rst);
> + if (ret)
> + return ret;
This branch could then be removed.
> + } else {
> + ret = regmap_write(st->regmap_8bit, AD5529R_REG_INTERFACE_CONFIG_A,
> + AD5529R_INTERFACE_CONFIG_A_SW_RESET);
> + if (ret)
> + return ret;
> + }
regards
Philipp
^ permalink raw reply
* Re: [PATCH v8 01/46] KVM: guest_memfd: Introduce per-gmem attributes, use to guard user mappings
From: Binbin Wu @ 2026-06-22 9:08 UTC (permalink / raw)
To: ackerleytng
Cc: aik, andrew.jones, brauner, chao.p.peng, david, jmattson,
jthoughton, michael.roth, oupton, pankaj.gupta, qperret,
rick.p.edgecombe, rientjes, shivankg, steven.price, tabba, willy,
wyihan, yan.y.zhao, forkloop, pratyush, suzuki.poulose,
aneesh.kumar, liam, Paolo Bonzini, Sean Christopherson,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Steven Rostedt, Masami Hiramatsu,
Mathieu Desnoyers, Jonathan Corbet, Shuah Khan, Shuah Khan,
Vishal Annapurve, Andrew Morton, Chris Li, Kairui Song,
Kemeng Shi, Nhat Pham, Barry Song, Axel Rasmussen, Yuanchu Xie,
Wei Xu, Youngjun Park, Qi Zheng, Shakeel Butt, Kiryl Shutsemau,
Baoquan He, Jason Gunthorpe, Vlastimil Babka, kvm, linux-kernel,
linux-trace-kernel, linux-doc, linux-kselftest, linux-mm,
linux-coco
In-Reply-To: <20260618-gmem-inplace-conversion-v8-1-9d2959357853@google.com>
On 6/19/2026 8:31 AM, Ackerley Tng via B4 Relay wrote:
[...]
>
> +static u64 kvm_gmem_get_attributes(struct inode *inode, pgoff_t index)
> +{
> + struct maple_tree *mt = &GMEM_I(inode)->attributes;
> + void *entry = mtree_load(mt, index);
> +
> + return WARN_ON_ONCE(!entry) ? 0 : xa_to_value(entry);
If the entry is unexpectedly missing, returning 0 means the attribute would be treated as shared.
And then in kvm_gmem_fault_user_mapping(), it would allow the userspace to fault in the folio.
Should gmem deny such edge case?
> +}
> +
> +static bool kvm_gmem_is_private_mem(struct inode *inode, pgoff_t index)
> +{
> + return kvm_gmem_get_attributes(inode, index) & KVM_MEMORY_ATTRIBUTE_PRIVATE;
> +}
> +
> +static bool kvm_gmem_is_shared_mem(struct inode *inode, pgoff_t index)
> +{
> + return !kvm_gmem_is_private_mem(inode, index);
> +}
> +
> static int __kvm_gmem_prepare_folio(struct kvm *kvm, struct kvm_memory_slot *slot,
> pgoff_t index, struct folio *folio)
> {
> @@ -397,10 +423,13 @@ static vm_fault_t kvm_gmem_fault_user_mapping(struct vm_fault *vmf)
> if (((loff_t)vmf->pgoff << PAGE_SHIFT) >= i_size_read(inode))
> return VM_FAULT_SIGBUS;
>
> - if (!(GMEM_I(inode)->flags & GUEST_MEMFD_FLAG_INIT_SHARED))
> - return VM_FAULT_SIGBUS;
> + filemap_invalidate_lock_shared(inode->i_mapping);
> + if (kvm_gmem_is_shared_mem(inode, vmf->pgoff))
> + folio = kvm_gmem_get_folio(inode, vmf->pgoff);
> + else
> + folio = ERR_PTR(-EACCES);
> + filemap_invalidate_unlock_shared(inode->i_mapping);
>
> - folio = kvm_gmem_get_folio(inode, vmf->pgoff);
> if (IS_ERR(folio)) {
> if (PTR_ERR(folio) == -EAGAIN)
> return VM_FAULT_RETRY;
> @@ -557,6 +586,51 @@ bool __weak kvm_arch_supports_gmem_init_shared(struct kvm *kvm)
> return true;
> }
>
^ permalink raw reply
* Re: [PATCH] hwmon: ltc4283: fix malformed table docs build error
From: Nuno Sá @ 2026-06-22 9:08 UTC (permalink / raw)
To: Randy Dunlap; +Cc: linux-doc, Nuno Sá, Guenter Roeck, linux-hwmon
In-Reply-To: <20260620011833.3568693-1-rdunlap@infradead.org>
On Fri, Jun 19, 2026 at 06:18:30PM -0700, Randy Dunlap wrote:
> Expand the table borders (upper & lower) to prevent a documentation
> build error:
>
> Documentation/hwmon/ltc4283.rst:261: ERROR: Malformed table.
> Text in column margin in table line 3.
> ======================= ==========================================
> power1_failed_fault_log Set to 1 by a power1 fault occurring.
> power1_good_input_fault_log Set to 1 by a power1 good input fault occurring at PGIO3.
>
> Fixes: dd63353a0b5e ("hwmon: ltc4283: Add support for the LTC4283 Swap Controller")
> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
> ---
Thanks!
Reviewed-by: Nuno Sá <nuno.sa@analog.com>
> Cc: Nuno Sá <nuno.sa@analog.com>
> Cc: Guenter Roeck <linux@roeck-us.net>
> Cc: linux-hwmon@vger.kernel.org
>
> Documentation/hwmon/ltc4283.rst | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> --- linux-next-20260619.orig/Documentation/hwmon/ltc4283.rst
> +++ linux-next-20260619/Documentation/hwmon/ltc4283.rst
> @@ -256,7 +256,7 @@ these logs can be cleared by writing in
> ``/sys/kernel/debug/i2c/i2c-[X]/[X]-addr/``
> contains the following attributes:
>
> -======================= ==========================================
> +============================== ==========================================================
> power1_failed_fault_log Set to 1 by a power1 fault occurring.
> power1_good_input_fault_log Set to 1 by a power1 good input fault occurring at PGIO3.
> in11_fet_short_fault_log Set to 1 when a FET-short fault occurs.
> @@ -264,4 +264,4 @@ in11_fet_bad_fault_log Set to 1 when a
> in0_lcrit_fault_log Set to 1 by a VIN undervoltage fault occurring.
> in0_crit_fault_log Set to 1 by a VIN overvoltage fault occurring.
> curr1_crit_fault_log Set to 1 by an overcurrent fault occurring.
> -======================= ==========================================
> +============================== ==========================================================
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: iio: dac: Add AD5529R
From: Nuno Sá @ 2026-06-22 9:07 UTC (permalink / raw)
To: Conor Dooley
Cc: Jonathan Cameron, Janani Sunil, Rodrigo Alencar, Janani Sunil,
Lars-Peter Clausen, Michael Hennerich, David Lechner,
Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Jonathan Corbet, Shuah Khan,
linux-iio, devicetree, linux-kernel, linux-doc, Mark Brown
In-Reply-To: <20260621-nutmeg-coauthor-715189372230@spud>
On Sun, Jun 21, 2026 at 07:35:42PM +0100, Conor Dooley wrote:
> On Sun, Jun 21, 2026 at 03:33:40PM +0100, Jonathan Cameron wrote:
> > On Fri, 19 Jun 2026 16:54:11 +0100
> > Nuno Sá <noname.nuno@gmail.com> wrote:
> >
> > > On Fri, Jun 19, 2026 at 03:12:07PM +0100, Conor Dooley wrote:
> > > > On Fri, Jun 19, 2026 at 02:01:08PM +0100, Nuno Sá wrote:
> > > > > On Fri, Jun 19, 2026 at 12:40:54PM +0100, Conor Dooley wrote:
> > > > > > On Fri, Jun 19, 2026 at 12:36:55PM +0100, Conor Dooley wrote:
> > > > > > > On Fri, Jun 19, 2026 at 12:33:11PM +0200, Janani Sunil wrote:
> > > > > > > >
> > > > > > > > On 6/14/26 21:44, Jonathan Cameron wrote:
> > > > > > > > > On Tue, 9 Jun 2026 16:47:23 +0200
> > > > > > > > > Janani Sunil <jan.sun97@gmail.com> wrote:
> > > > > > > > >
> > > > > > > > > > On 5/26/26 15:11, Rodrigo Alencar wrote:
> > > > > > > > > > > On 26/05/19 05:42PM, Janani Sunil wrote:
> > > > > > > > > > > > Devicetree bindings for AD5529R 16 channel 12/16 bit high voltage,
> > > > > > > > > > > > buffered voltage output digital-to-analog converter (DAC) with an
> > > > > > > > > > > > integrated precision reference.
> > > > > > > > > > > ...
> > > > > > > > > > > Probably others may comment on that, but...
> > > > > > > > > > >
> > > > > > > > > > > This parent node may support device addressing for multi-device support through
> > > > > > > > > > > those ID pins. I suppose that each device may have its own power supplies or
> > > > > > > > > > > other resources like the toggle pins or reset and enable.
> > > > > > > > > > >
> > > > > > > > > > > That way I suppose that an example would look like...
> > > > > > > > > > > > +
> > > > > > > > > > > > +patternProperties:
> > > > > > > > > > > > + "^channel@([0-9]|1[0-5])$":
> > > > > > > > > > > > + type: object
> > > > > > > > > > > > + description: Child nodes for individual channel configuration
> > > > > > > > > > > > +
> > > > > > > > > > > > + properties:
> > > > > > > > > > > > + reg:
> > > > > > > > > > > > + description: Channel number.
> > > > > > > > > > > > + minimum: 0
> > > > > > > > > > > > + maximum: 15
> > > > > > > > > > > > +
> > > > > > > > > > > > + adi,output-range-microvolt:
> > > > > > > > > > > > + description: |
> > > > > > > > > > > > + Output voltage range for this channel as [min, max] in microvolts.
> > > > > > > > > > > > + If not specified, defaults to 0V to 5V range.
> > > > > > > > > > > > + oneOf:
> > > > > > > > > > > > + - items:
> > > > > > > > > > > > + - const: 0
> > > > > > > > > > > > + - enum: [5000000, 10000000, 20000000, 40000000]
> > > > > > > > > > > > + - items:
> > > > > > > > > > > > + - const: -5000000
> > > > > > > > > > > > + - const: 5000000
> > > > > > > > > > > > + - items:
> > > > > > > > > > > > + - const: -10000000
> > > > > > > > > > > > + - const: 10000000
> > > > > > > > > > > > + - items:
> > > > > > > > > > > > + - const: -15000000
> > > > > > > > > > > > + - const: 15000000
> > > > > > > > > > > > + - items:
> > > > > > > > > > > > + - const: -20000000
> > > > > > > > > > > > + - const: 20000000
> > > > > > > > > > > > +
> > > > > > > > > > > > + required:
> > > > > > > > > > > > + - reg
> > > > > > > > > > > > +
> > > > > > > > > > > > + additionalProperties: false
> > > > > > > > > > > > +
> > > > > > > > > > > > +required:
> > > > > > > > > > > > + - compatible
> > > > > > > > > > > > + - reg
> > > > > > > > > > > > + - vdd-supply
> > > > > > > > > > > > + - avdd-supply
> > > > > > > > > > > > + - hvdd-supply
> > > > > > > > > > > > +
> > > > > > > > > > > > +dependencies:
> > > > > > > > > > > > + spi-cpha: [ spi-cpol ]
> > > > > > > > > > > > + spi-cpol: [ spi-cpha ]
> > > > > > > > > > > > +
> > > > > > > > > > > > +allOf:
> > > > > > > > > > > > + - $ref: /schemas/spi/spi-peripheral-props.yaml#
> > > > > > > > > > > > +
> > > > > > > > > > > > +unevaluatedProperties: false
> > > > > > > > > > > > +
> > > > > > > > > > > > +examples:
> > > > > > > > > > > > + - |
> > > > > > > > > > > > + #include <dt-bindings/gpio/gpio.h>
> > > > > > > > > > > > +
> > > > > > > > > > > > + spi {
> > > > > > > > > > > > + #address-cells = <1>;
> > > > > > > > > > > > + #size-cells = <0>;
> > > > > > > > > > > > +
> > > > > > > > > > > > + dac@0 {
> > > > > > > > > > > > + compatible = "adi,ad5529r-16";
> > > > > > > > > > > > + reg = <0>;
> > > > > > > > > > > > + spi-max-frequency = <25000000>;
> > > > > > > > > > > > +
> > > > > > > > > > > > + vdd-supply = <&vdd_regulator>;
> > > > > > > > > > > > + avdd-supply = <&avdd_regulator>;
> > > > > > > > > > > > + hvdd-supply = <&hvdd_regulator>;
> > > > > > > > > > > > + hvss-supply = <&hvss_regulator>;
> > > > > > > > > > > > +
> > > > > > > > > > > > + reset-gpios = <&gpio0 87 GPIO_ACTIVE_LOW>;
> > > > > > > > > > > > +
> > > > > > > > > > > > + #address-cells = <1>;
> > > > > > > > > > > > + #size-cells = <0>;
> > > > > > > > > > > > +
> > > > > > > > > > > > + channel@0 {
> > > > > > > > > > > > + reg = <0>;
> > > > > > > > > > > > + adi,output-range-microvolt = <0 5000000>;
> > > > > > > > > > > > + };
> > > > > > > > > > > > +
> > > > > > > > > > > > + channel@1 {
> > > > > > > > > > > > + reg = <1>;
> > > > > > > > > > > > + adi,output-range-microvolt = <(-10000000) 10000000>;
> > > > > > > > > > > > + };
> > > > > > > > > > > > +
> > > > > > > > > > > > + channel@2 {
> > > > > > > > > > > > + reg = <2>;
> > > > > > > > > > > > + adi,output-range-microvolt = <0 40000000>;
> > > > > > > > > > > > + };
> > > > > > > > > > > > + };
> > > > > > > > > > > > + };
> > > > > > > > > > > ...
> > > > > > > > > > >
> > > > > > > > > > > spi {
> > > > > > > > > > > #address-cells = <1>;
> > > > > > > > > > > #size-cells = <0>;
> > > > > > > > > > >
> > > > > > > > > > > multi-dac@0 {
> > > > > > > > > > > compatible = "adi,ad5529r-16";
> > > > > > > > > > > reg = <0>;
> > > > > > > > > > > spi-max-frequency = <25000000>;
> > > > > > > > > > >
> > > > > > > > > > > #address-cells = <1>;
> > > > > > > > > > > #size-cells = <0>;
> > > > > > > > > > >
> > > > > > > > > > > dac@0 {
> > > > > > > > > > > reg = <0>;
> > > > > > > > > > > vdd-supply = <&vdd_regulator>;
> > > > > > > > > > > avdd-supply = <&avdd_regulator>;
> > > > > > > > > > > hvdd-supply = <&hvdd_regulator>;
> > > > > > > > > > > hvss-supply = <&hvss_regulator>;
> > > > > > > > > > >
> > > > > > > > > > > reset-gpios = <&gpio0 87 GPIO_ACTIVE_LOW>;
> > > > > > > > > > >
> > > > > > > > > > > #address-cells = <1>;
> > > > > > > > > > > #size-cells = <0>;
> > > > > > > > > > >
> > > > > > > > > > > channel@0 {
> > > > > > > > > > > reg = <0>;
> > > > > > > > > > > adi,output-range-microvolt = <0 5000000>;
> > > > > > > > > > > };
> > > > > > > > > > >
> > > > > > > > > > > channel@1 {
> > > > > > > > > > > reg = <1>;
> > > > > > > > > > > adi,output-range-microvolt = <(-10000000) 10000000>;
> > > > > > > > > > > };
> > > > > > > > > > >
> > > > > > > > > > > channel@2 {
> > > > > > > > > > > reg = <2>;
> > > > > > > > > > > adi,output-range-microvolt = <0 40000000>;
> > > > > > > > > > > };
> > > > > > > > > > > }
> > > > > > > > > > >
> > > > > > > > > > > dac@1 {
> > > > > > > > > > > reg = <1>;
> > > > > > > > > > > vdd-supply = <&vdd_regulator>;
> > > > > > > > > > > avdd-supply = <&avdd_regulator>;
> > > > > > > > > > > hvdd-supply = <&hvdd_regulator>;
> > > > > > > > > > > hvss-supply = <&hvss_regulator>;
> > > > > > > > > > >
> > > > > > > > > > > reset-gpios = <&gpio0 88 GPIO_ACTIVE_LOW>;
> > > > > > > > > > >
> > > > > > > > > > > #address-cells = <1>;
> > > > > > > > > > > #size-cells = <0>;
> > > > > > > > > > >
> > > > > > > > > > > channel@0 {
> > > > > > > > > > > reg = <0>;
> > > > > > > > > > > adi,output-range-microvolt = <0 5000000>;
> > > > > > > > > > > };
> > > > > > > > > > >
> > > > > > > > > > > channel@1 {
> > > > > > > > > > > reg = <1>;
> > > > > > > > > > > adi,output-range-microvolt = <(-10000000) 10000000>;
> > > > > > > > > > > };
> > > > > > > > > > > }
> > > > > > > > > > > };
> > > > > > > > > > > };
> > > > > > > > > > >
> > > > > > > > > > > then you might need something like:
> > > > > > > > > > >
> > > > > > > > > > > patternProperties:
> > > > > > > > > > > "^dac@[0-3]$":
> > > > > > > > > > >
> > > > > > > > > > > and put most of the things under this node pattern.
> > > > > > > > > > >
> > > > > > > > > > > So the main driver that you're putting together might need to handle up to four instances.
> > > > > > > > > > > Even if your current driver cannot handle this, the dt-bindings might need cover that.
> > > > > > > > > > >
> > > > > > > > > > > Need to double check if each dac node needs a separate compatible, so you would maybe populate
> > > > > > > > > > > a platform data to be shared with the child nodes, which would be a separate driver.
> > > > > > > > > > > (not sure if it would make sense to mix and match ad5529r-16 and ad5529r-12).
> > > > > > > > > > Hi Rodrigo,
> > > > > > > > > >
> > > > > > > > > > Thank you for looking at this.
> > > > > > > > > >
> > > > > > > > > > For now, I would prefer to keep the binding scoped to a single AD5529R device instance. The current
> > > > > > > > > > hardware/use case we have only needs one device node and the driver is written around that model as well.
> > > > > > > > > > While the device addressing pins could allow multi-device topology, we do not have an actual platform using
> > > > > > > > > > that configuration at the moment, so I would prefer not to introduce an extra parent/child binding structure
> > > > > > > > > > speculatively without a validating use case.
> > > > > > > > > Interesting feature - kind of similar to address control on a typical i2c bus device, or
> > > > > > > > > looking at it another way a kind of distributed SPI mux.
> > > > > > > > >
> > > > > > > > > Challenge of a binding is we need to anticipate the future. So I think we do need something
> > > > > > > > > like Rodrigo is suggesting even if we only (for now) support a single instance in the driver.
> > > > > > > > > That would leave the path open to supporting the addressing at a later date.
> > > > > > > > > An alternative might be to look at it like a chained device setup. In those we pretend there
> > > > > > > > > is just one device with a lot of channels etc. The snag is that here things are more loosely
> > > > > > > > > coupled whereas for those devices it tends to be you have to read / write the same register
> > > > > > > > > in all devices in the chain as one big SPI message.
> > > > > > > > >
> > > > > > > > > +CC Mark Brown as he may know of some precedence for this feature. For his reference..
> > > > > > > > > - Each of these device has 2 ID pins. The SPI transfers have to contain the 2 bit
> > > > > > > > > value that matches that or they are ignored. Thus a single bus + 1 chip select can
> > > > > > > > > be used to talk to 4 devices. Question is what that looks like in device tree + I guess
> > > > > > > > > longer term how to support it cleanly in SPI.
> > > > > > >
> > > > > > > I'd swear I have seen this before, from some Microchip devices. Let me
> > > > > > > see if I can find what I am thinking of...
> > > > > >
> > > > > >
> > > > > > microchip,mcp3911 and microchip,mcp3564 both seem to do this with
> > > > > > slightly different properties.
> > > > > >
> > > > > > microchip,device-addr:
> > > > > > description: Device address when multiple MCP3911 chips are present on the same SPI bus.
> > > > > > $ref: /schemas/types.yaml#/definitions/uint32
> > > > > > enum: [0, 1, 2, 3]
> > > > > > default: 0
> > > > > >
> > > > > > and
> > > > > >
> > > > > >
> > > > > > microchip,hw-device-address:
> > > > > > $ref: /schemas/types.yaml#/definitions/uint32
> > > > > > minimum: 0
> > > > > > maximum: 3
> > > > > > description:
> > > > > > The address is set on a per-device basis by fuses in the factory,
> > > > > > configured on request. If not requested, the fuses are set for 0x1.
> > > > > > The device address is part of the device markings to avoid
> > > > > > potential confusion. This address is coded on two bits, so four possible
> > > > > > addresses are available when multiple devices are present on the same
> > > > > > SPI bus with only one Chip Select line for all devices.
> > > > > > Each device communication starts by a CS falling edge, followed by the
> > > > > > clocking of the device address (BITS[7:6] - top two bits of COMMAND BYTE
> > > > > > which is first one on the wire).
> > > > > >
> > > > > > This sounds exactly like the sort of feature that you're dealing with
> > > > > > here?
> > > > > >
> > > > >
> > > > > The core idea yes but for this chip, things are a bit more annoying (but
> > > > > Janani can correct me if I'm wrong). Here, each device can, in theory,
> > > > > have it's own supplies, pins and at the very least, channels with maybe
> > > > > different scales. That is why Janani is proposing dac nodes. Given I
> > > > > honestly don't like much of that "adi,ad5529r-bus" compatible I wondered
> > > > > about solving this at the spi level.
> > > > >
> > > > > Ah and to make it more annoying, we can also mix 12 and 16 bits variants
> > > > > together in the same bus.
> > > >
> > > > I'm definitely missing something, because that property for the
> > > > microchip devices is not impacted what else is on the bus. AFAICT, you
> > > > could have an mcp3911 and an mcp3564 on the same bus even though both
> > > > are completely different devices with different drivers. They have
> > > > individual device nodes and their own supplies etc etc. These aren't
> > > > per-channel properties on an adc or dac, they're per child device on a
> > > > spi bus.
> > >
> > > Maybe I'm the one missing something :). IIRC, spi would not allow two
> > > devices on the same CS right? Because for this chip we would need
> > > something like:
> > >
> > > spi {
> > > dac@0 {
> > > reg = <0>;
> > > adi,pin-id = <0>;
> > > };
> > >
> > > dac@1 {
> > > reg = <0>; // which seems already problematic?
> > > adi,pin-id <1>;
> > > };
> > >
> > > ...
> > >
> > > //up to 4
> > > };
> > Yeah. It's not clear to me how that works for the microchip devices
> > (I suspect it doesn't!)
> >
> > Just thinking as I type, but could we do something a bit nasty with
> > a gpio mux that doesn't actually switch but represents the GPIO being
> > shared? Given this is all tied to the spi bus that should all happen
> > under serializing locks.
> >
> > Agreed though that this would be nicer as an SPI thing that let
> > us specify that a single CS is share by multiple devices and their
> > is some other signal acting to select which one we are talking to.
>
> Whether it works or not, I think it is the more correct approach. Messing
> with gpio muxes seems completely wrong, given the chip select may not be
> a gpio at all.
>
> Why do you think the microchip devices won't work? Does the spi core
> reject multiple devices with the same chip select being registered or
> something like that?
Not sure how things work atm. But I'm fairly sure it used to be like
that. SPI would reject devices on the same controller and CS. Now that
we support more than one CS per controller, not sure how things work.
Janani, maybe you can give it a try?
- Nuno Sá
^ permalink raw reply
* Re: [PATCH 0/2] tracing: Move trace_printk.h out of kernel.h
From: Peter Zijlstra @ 2026-06-22 8:34 UTC (permalink / raw)
To: Steven Rostedt
Cc: linux-kernel, linux-trace-kernel, Masami Hiramatsu, Mark Rutland,
Mathieu Desnoyers, Andrew Morton, Linus Torvalds,
Sebastian Andrzej Siewior, John Ogness, Thomas Gleixner,
Julia Lawall, Yury Norov, linux-doc, linux-kbuild, linuxppc-dev,
dri-devel, linux-stm32, linux-arm-kernel, linux-rdma, linux-usb,
linux-ext4, linux-nfs, kvm, intel-gfx
In-Reply-To: <20260621093430.264983361@kernel.org>
On Sun, Jun 21, 2026 at 05:34:30AM -0400, Steven Rostedt wrote:
> There's been complaints about trace_printk() being defined in kernel.h as it
> can increase the compilation time. As it is only used by some developers for
> debugging purposes, it should not be in kernel.h causing lots of wasted CPU
> cycles for those that do not ever care about it.
>
> Instead, add a CONFIG_TRACE_PRINTK_DEBUGGING option that developers that do
> use it can set and not have to always remember to add #include <linux/trace_printk.h>
> to the files they add trace_printk() while debugging. It also means that
> those that do not have that config set will not have to worry about wasted
> CPU cycles as it is only include in the CFLAGS when the option is set, and
> its completely ignored otherwise.
Did you forget your C 101 class? If you use a function, you gotta
include the relevant header.
You don't see userspace saying: 'Hey, you know what, perhaps we should
add stdio.h to every other header, just in case someone wants to
printf()' either.
I really don't understand your argument. Yes, maybe someone will forget
and then either their editor (if they have a halfway modern setup with
LSP enabled) or their build will complain, but so what? This is all
trivial stuff, surely we have more pressing matters to concern outselves
with?
^ permalink raw reply
* Re: [PATCH 0/2] tracing: Move trace_printk.h out of kernel.h
From: Steven Rostedt @ 2026-06-22 8:53 UTC (permalink / raw)
To: Peter Zijlstra
Cc: linux-kernel, linux-trace-kernel, Masami Hiramatsu, Mark Rutland,
Mathieu Desnoyers, Andrew Morton, Linus Torvalds,
Sebastian Andrzej Siewior, John Ogness, Thomas Gleixner,
Julia Lawall, Yury Norov, linux-doc, linux-kbuild, linuxppc-dev,
dri-devel, linux-stm32, linux-arm-kernel, linux-rdma, linux-usb,
linux-ext4, linux-nfs, kvm, intel-gfx
In-Reply-To: <20260622083440.GX49951@noisy.programming.kicks-ass.net>
On Mon, 22 Jun 2026 10:34:40 +0200
Peter Zijlstra <peterz@infradead.org> wrote:
> Did you forget your C 101 class? If you use a function, you gotta
> include the relevant header.
If this was the way it was back in 2009, yeah sure. But the header
wasn't need for 17 years. Now it suddenly will be.
-- Steve
^ permalink raw reply
* [PATCH v2 3/3] watchdog: npcm: add bootstatus support
From: Tomer Maimon @ 2026-06-22 8:30 UTC (permalink / raw)
To: andrew, wim, linux, robh, krzk+dt, conor+dt
Cc: openbmc, linux-watchdog, linux-doc, devicetree, linux-kernel,
avifishman70, tmaimon77, tali.perry1, venture, yuenn,
benjaminfair, corbet, skhan, joel
In-Reply-To: <20260622083046.3189603-1-tmaimon77@gmail.com>
The NPCM750 uses RESSR and the NPCM845 uses INTCR2 to latch reset
indications. Read those bits during probe and map them into watchdog
bootstatus flags.
For NPCM845, cache the sampled INTCR2 state in SCRPAD10 after the reset
status bits are cleared so later probes can report the same boot-time
state. Also report WDIOF_CARDRESET for the watchdog instance whose reset
bit is latched, while leaving WPCM450 behavior unchanged.
Signed-off-by: Tomer Maimon <tmaimon77@gmail.com>
---
drivers/watchdog/npcm_wdt.c | 197 +++++++++++++++++++++++++++++++++++-
1 file changed, 195 insertions(+), 2 deletions(-)
diff --git a/drivers/watchdog/npcm_wdt.c b/drivers/watchdog/npcm_wdt.c
index e62ea054bc61..98660419ec3f 100644
--- a/drivers/watchdog/npcm_wdt.c
+++ b/drivers/watchdog/npcm_wdt.c
@@ -7,14 +7,51 @@
#include <linux/delay.h>
#include <linux/interrupt.h>
#include <linux/kernel.h>
+#include <linux/mfd/syscon.h>
#include <linux/module.h>
#include <linux/of_irq.h>
#include <linux/platform_device.h>
+#include <linux/regmap.h>
#include <linux/slab.h>
#include <linux/watchdog.h>
#define NPCM_WTCR 0x1C
+/* NPCM GCR module */
+#define NPCM_RESSR_OFFSET 0x6C
+#define NPCM_INTCR2_OFFSET 0x60
+#define NPCM8XX_SCRPAD10_OFFSET 0xE28
+
+#define NPCM_PORST BIT(31)
+#define NPCM_CORST BIT(30)
+#define NPCM_WD0RST BIT(29)
+#define NPCM_SWR1RST BIT(28)
+#define NPCM_SWR2RST BIT(27)
+#define NPCM_SWR3RST BIT(26)
+#define NPCM_SWR4RST BIT(25)
+#define NPCM_WD1RST BIT(24)
+#define NPCM_WD2RST BIT(23)
+#define NPCM8XX_RST (GENMASK(31, 23) | GENMASK(15, 12))
+#define NPCM8XX_TIP_RESET BIT(25) /* Replaces SWRST4 on NPCM8xx */
+
+/* Per-instance mapping of MMIO base address to its RESSR/INTCR2 reset bit. */
+struct npcm_wdt_rst_map {
+ phys_addr_t base;
+ u32 rst_bit;
+};
+
+struct npcm_wdt_status_map {
+ u32 rst_bit;
+ u32 wdiof_flag;
+};
+
+struct npcm_wdt_data {
+ const struct npcm_wdt_rst_map *rst_map;
+ unsigned int rst_map_size;
+ const struct npcm_wdt_status_map *status_map;
+ unsigned int status_map_size;
+};
+
#define NPCM_WTCLK (BIT(10) | BIT(11)) /* Clock divider */
#define NPCM_WTE BIT(7) /* Enable */
#define NPCM_WTIE BIT(6) /* Enable irq */
@@ -47,6 +84,50 @@ struct npcm_wdt {
struct clk *clk;
};
+static const struct npcm_wdt_rst_map npcm750_rst_map[] = {
+ { 0xf000801c, NPCM_WD0RST },
+ { 0xf000901c, NPCM_WD1RST },
+ { 0xf000a01c, NPCM_WD2RST },
+};
+
+static const struct npcm_wdt_status_map npcm750_status_map[] = {
+ { NPCM_PORST, WDIOF_OVERHEAT },
+ { NPCM_CORST, WDIOF_FANFAULT },
+ { NPCM_SWR1RST, WDIOF_EXTERN1 },
+ { NPCM_SWR2RST, WDIOF_EXTERN2 },
+ { NPCM_SWR3RST, WDIOF_POWERUNDER },
+ { NPCM_SWR4RST, WDIOF_POWEROVER },
+};
+
+static const struct npcm_wdt_data npcm750_data = {
+ .rst_map = npcm750_rst_map,
+ .rst_map_size = ARRAY_SIZE(npcm750_rst_map),
+ .status_map = npcm750_status_map,
+ .status_map_size = ARRAY_SIZE(npcm750_status_map),
+};
+
+static const struct npcm_wdt_rst_map npcm845_rst_map[] = {
+ { 0xf000801c, NPCM_WD0RST },
+ { 0xf000901c, NPCM_WD1RST },
+ { 0xf000a01c, NPCM_WD2RST },
+};
+
+static const struct npcm_wdt_status_map npcm845_status_map[] = {
+ { NPCM_PORST, WDIOF_OVERHEAT },
+ { NPCM_CORST, WDIOF_FANFAULT },
+ { NPCM_SWR1RST, WDIOF_EXTERN1 },
+ { NPCM_SWR2RST, WDIOF_EXTERN2 },
+ { NPCM_SWR3RST, WDIOF_POWERUNDER },
+ { NPCM8XX_TIP_RESET, WDIOF_POWEROVER },
+};
+
+static const struct npcm_wdt_data npcm845_data = {
+ .rst_map = npcm845_rst_map,
+ .rst_map_size = ARRAY_SIZE(npcm845_rst_map),
+ .status_map = npcm845_status_map,
+ .status_map_size = ARRAY_SIZE(npcm845_status_map),
+};
+
static inline struct npcm_wdt *to_npcm_wdt(struct watchdog_device *wdd)
{
return container_of(wdd, struct npcm_wdt, wdd);
@@ -169,6 +250,92 @@ static bool npcm_is_running(struct watchdog_device *wdd)
return readl(wdt->reg) & NPCM_WTE;
}
+static void npcm_get_reset_status(struct npcm_wdt *wdt, struct device *dev,
+ const struct npcm_wdt_data *data,
+ resource_size_t start)
+{
+ struct regmap *gcr_regmap;
+ u32 rstval = 0;
+ unsigned int i;
+ int ret;
+
+ if (!data)
+ return;
+
+ gcr_regmap = syscon_regmap_lookup_by_phandle(dev->of_node,
+ "nuvoton,sysgcr");
+ if (IS_ERR(gcr_regmap)) {
+ dev_warn(dev,
+ "Failed to find nuvoton,sysgcr, WD reset status not supported\n");
+ return;
+ }
+
+ if (of_device_is_compatible(dev->of_node, "nuvoton,npcm845-wdt")) {
+ ret = regmap_read(gcr_regmap, NPCM_INTCR2_OFFSET, &rstval);
+ if (ret) {
+ dev_warn(dev, "Failed to read INTCR2 reset status: %d\n",
+ ret);
+ return;
+ }
+
+ if (rstval & NPCM8XX_RST) {
+ ret = regmap_write(gcr_regmap, NPCM_INTCR2_OFFSET,
+ rstval & ~NPCM8XX_RST);
+ if (ret) {
+ dev_warn(dev,
+ "Failed to clear INTCR2 reset status: %d\n",
+ ret);
+ return;
+ }
+
+ ret = regmap_write(gcr_regmap, NPCM8XX_SCRPAD10_OFFSET,
+ rstval);
+ if (ret) {
+ dev_warn(dev,
+ "Failed to cache reset status in SCRPAD10: %d\n",
+ ret);
+ return;
+ }
+ } else {
+ ret = regmap_read(gcr_regmap, NPCM8XX_SCRPAD10_OFFSET,
+ &rstval);
+ if (ret) {
+ dev_warn(dev,
+ "Failed to read cached reset status from SCRPAD10: %d\n",
+ ret);
+ return;
+ }
+ }
+ } else if (of_device_is_compatible(dev->of_node, "nuvoton,npcm750-wdt")) {
+ ret = regmap_read(gcr_regmap, NPCM_RESSR_OFFSET, &rstval);
+ if (ret) {
+ dev_warn(dev, "Failed to read RESSR reset status: %d\n",
+ ret);
+ return;
+ }
+
+ ret = regmap_write(gcr_regmap, NPCM_RESSR_OFFSET, rstval);
+ if (ret) {
+ dev_warn(dev, "Failed to clear RESSR reset status: %d\n",
+ ret);
+ return;
+ }
+ }
+
+ for (i = 0; i < data->status_map_size; i++) {
+ if (rstval & data->status_map[i].rst_bit)
+ wdt->wdd.bootstatus |= data->status_map[i].wdiof_flag;
+ }
+
+ for (i = 0; i < data->rst_map_size; i++) {
+ if (data->rst_map[i].base == start &&
+ rstval & data->rst_map[i].rst_bit) {
+ wdt->wdd.bootstatus |= WDIOF_CARDRESET;
+ break;
+ }
+ }
+}
+
static const struct watchdog_info npcm_wdt_info = {
.identity = KBUILD_MODNAME,
.options = WDIOF_SETTIMEOUT
@@ -176,6 +343,20 @@ static const struct watchdog_info npcm_wdt_info = {
| WDIOF_MAGICCLOSE,
};
+static const struct watchdog_info npcm_wdt_rst_info = {
+ .identity = KBUILD_MODNAME,
+ .options = WDIOF_SETTIMEOUT
+ | WDIOF_KEEPALIVEPING
+ | WDIOF_MAGICCLOSE
+ | WDIOF_CARDRESET
+ | WDIOF_OVERHEAT
+ | WDIOF_FANFAULT
+ | WDIOF_EXTERN1
+ | WDIOF_EXTERN2
+ | WDIOF_POWERUNDER
+ | WDIOF_POWEROVER,
+};
+
static const struct watchdog_ops npcm_wdt_ops = {
.owner = THIS_MODULE,
.start = npcm_wdt_start,
@@ -188,7 +369,10 @@ static const struct watchdog_ops npcm_wdt_ops = {
static int npcm_wdt_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
+ const struct npcm_wdt_data *data = device_get_match_data(dev);
+ struct resource *res;
struct npcm_wdt *wdt;
+ resource_size_t start;
int irq;
int ret;
@@ -196,10 +380,16 @@ static int npcm_wdt_probe(struct platform_device *pdev)
if (!wdt)
return -ENOMEM;
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res)
+ return -EINVAL;
+
wdt->reg = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(wdt->reg))
return PTR_ERR(wdt->reg);
+ start = res->start;
+
wdt->clk = devm_clk_get_optional(&pdev->dev, NULL);
if (IS_ERR(wdt->clk))
return PTR_ERR(wdt->clk);
@@ -208,7 +398,7 @@ static int npcm_wdt_probe(struct platform_device *pdev)
if (irq < 0)
return irq;
- wdt->wdd.info = &npcm_wdt_info;
+ wdt->wdd.info = data ? &npcm_wdt_rst_info : &npcm_wdt_info;
wdt->wdd.ops = &npcm_wdt_ops;
wdt->wdd.min_timeout = 1;
wdt->wdd.max_timeout = 2750;
@@ -220,6 +410,8 @@ static int npcm_wdt_probe(struct platform_device *pdev)
/* Ensure timeout is able to be represented by the hardware */
npcm_wdt_set_timeout(&wdt->wdd, wdt->wdd.timeout);
+ npcm_get_reset_status(wdt, dev, data, start);
+
if (npcm_is_running(&wdt->wdd)) {
/* Restart with the default or device-tree specified timeout */
npcm_wdt_start(&wdt->wdd);
@@ -243,7 +435,8 @@ static int npcm_wdt_probe(struct platform_device *pdev)
#ifdef CONFIG_OF
static const struct of_device_id npcm_wdt_match[] = {
{.compatible = "nuvoton,wpcm450-wdt"},
- {.compatible = "nuvoton,npcm750-wdt"},
+ {.compatible = "nuvoton,npcm750-wdt", .data = &npcm750_data},
+ {.compatible = "nuvoton,npcm845-wdt", .data = &npcm845_data},
{},
};
MODULE_DEVICE_TABLE(of, npcm_wdt_match);
--
2.34.1
^ permalink raw reply related
* [PATCH v2 2/3] docs: watchdog: npcm: Add reset status description
From: Tomer Maimon @ 2026-06-22 8:30 UTC (permalink / raw)
To: andrew, wim, linux, robh, krzk+dt, conor+dt
Cc: openbmc, linux-watchdog, linux-doc, devicetree, linux-kernel,
avifishman70, tmaimon77, tali.perry1, venture, yuenn,
benjaminfair, corbet, skhan, joel
In-Reply-To: <20260622083046.3189603-1-tmaimon77@gmail.com>
Add documentation describing how the NPCM watchdog driver reports reset
causes through bootstatus on NPCM750 and NPCM845 systems.
Document the reset flag mapping, the watchdog instance mapping for
WDIOF_CARDRESET, and the NPCM750/NPCM845 latch handling. Also mention
sysfs bootstatus reporting when watchdog sysfs support is enabled.
Signed-off-by: Tomer Maimon <tmaimon77@gmail.com>
---
Documentation/watchdog/index.rst | 1 +
Documentation/watchdog/npcm_wdt.rst | 70 +++++++++++++++++++++++++++++
2 files changed, 71 insertions(+)
create mode 100644 Documentation/watchdog/npcm_wdt.rst
diff --git a/Documentation/watchdog/index.rst b/Documentation/watchdog/index.rst
index 1cea24681e6b..ef29e861e837 100644
--- a/Documentation/watchdog/index.rst
+++ b/Documentation/watchdog/index.rst
@@ -9,6 +9,7 @@ Watchdog Support
hpwdt
mlx-wdt
+ npcm_wdt
pcwd-watchdog
watchdog-api
watchdog-kernel-api
diff --git a/Documentation/watchdog/npcm_wdt.rst b/Documentation/watchdog/npcm_wdt.rst
new file mode 100644
index 000000000000..48f0c7920c11
--- /dev/null
+++ b/Documentation/watchdog/npcm_wdt.rst
@@ -0,0 +1,70 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=============
+NPCM Watchdog
+=============
+
+The NPCM watchdog driver can report reset-cause information on
+``nuvoton,npcm750-wdt`` and ``nuvoton,npcm845-wdt`` systems.
+
+Userspace can read the latched reset cause through
+``WDIOC_GETBOOTSTATUS``. When ``CONFIG_WATCHDOG_SYSFS`` is enabled, the
+same value is also visible through ``/sys/class/watchdog/watchdogN/bootstatus``.
+
+The mapping is fixed in the driver. It exposes the SoC reset indications
+through the generic watchdog bootstatus flags and is not configurable from
+Device Tree.
+
+.. list-table:: Reset-cause mapping
+ :header-rows: 1
+
+ * - Platform
+ - Reset indication
+ - Bootstatus flag
+ - Reported meaning
+ * - NPCM750 and NPCM845
+ - ``PORST``
+ - ``WDIOF_OVERHEAT``
+ - power-on reset
+ * - NPCM750 and NPCM845
+ - ``CORST``
+ - ``WDIOF_FANFAULT``
+ - core reset
+ * - NPCM750 and NPCM845
+ - ``SWR1RST``
+ - ``WDIOF_EXTERN1``
+ - software reset source 1
+ * - NPCM750 and NPCM845
+ - ``SWR2RST``
+ - ``WDIOF_EXTERN2``
+ - software reset source 2
+ * - NPCM750 and NPCM845
+ - ``SWR3RST``
+ - ``WDIOF_POWERUNDER``
+ - software reset source 3
+ * - NPCM750
+ - ``SWR4RST``
+ - ``WDIOF_POWEROVER``
+ - software reset source 4
+ * - NPCM845
+ - ``TIP reset`` (``INTCR2[25]``)
+ - ``WDIOF_POWEROVER``
+ - TIP reset
+
+``WDIOF_CARDRESET`` is reported only for the watchdog instance whose own
+reset-status bit is latched. On systems with three watchdog instances, this
+maps ``WD0RST``, ``WD1RST``, and ``WD2RST`` to ``watchdog0``, ``watchdog1``,
+and ``watchdog2`` respectively.
+
+The driver may report ``WDIOF_CARDRESET`` together with one or more of the
+reset-cause flags listed above.
+
+On NPCM750, the driver samples ``RESSR`` and clears the latched reset bits
+after reading them.
+
+On NPCM845, the driver samples ``INTCR2``. When reset bits are still latched,
+it clears them and stores the sampled value in ``SCRPAD10`` so later watchdog
+probes can report the same boot-time state.
+
+The WPCM450 watchdog continues to operate without this reset-indication
+mapping.
--
2.34.1
^ permalink raw reply related
* [PATCH v2 1/3] dt-bindings: watchdog: npcm: add GCR syscon property
From: Tomer Maimon @ 2026-06-22 8:30 UTC (permalink / raw)
To: andrew, wim, linux, robh, krzk+dt, conor+dt
Cc: openbmc, linux-watchdog, linux-doc, devicetree, linux-kernel,
avifishman70, tmaimon77, tali.perry1, venture, yuenn,
benjaminfair, corbet, skhan, joel
In-Reply-To: <20260622083046.3189603-1-tmaimon77@gmail.com>
Describe syscon property that handles general control registers (GCR) in
Nuvoton BMC NPCM watchdog driver.
Signed-off-by: Tomer Maimon <tmaimon77@gmail.com>
---
.../devicetree/bindings/watchdog/nuvoton,npcm750-wdt.yaml | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/watchdog/nuvoton,npcm750-wdt.yaml b/Documentation/devicetree/bindings/watchdog/nuvoton,npcm750-wdt.yaml
index 7aa30f5b5c49..4f00f099b2d2 100644
--- a/Documentation/devicetree/bindings/watchdog/nuvoton,npcm750-wdt.yaml
+++ b/Documentation/devicetree/bindings/watchdog/nuvoton,npcm750-wdt.yaml
@@ -40,6 +40,12 @@ properties:
clock-frequency:
description: Frequency in Hz of the clock that drives the NPCM timer.
+ nuvoton,sysgcr:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ a phandle to access GCR registers on NPCM750 and NPCM845 watchdog
+ instances.
+
required:
- compatible
- reg
--
2.34.1
^ permalink raw reply related
* [PATCH v2 0/3] watchdog: npcm: Add reset status detection support
From: Tomer Maimon @ 2026-06-22 8:30 UTC (permalink / raw)
To: andrew, wim, linux, robh, krzk+dt, conor+dt
Cc: openbmc, linux-watchdog, linux-doc, devicetree, linux-kernel,
avifishman70, tmaimon77, tali.perry1, venture, yuenn,
benjaminfair, corbet, skhan, joel
This series documents and implements reset indication reporting for the
NPCM watchdog driver on NPCM7xx and NPCM8xx systems, and documents the
optional GCR syscon property used by that support.
Patch 1 updates the watchdog binding to allow the optional
``nuvoton,sysgcr`` property used for reset-cause reporting.
Patch 2 adds watchdog documentation that describes the bootstatus
mapping.
Patch 3 reads the SoC reset indication bits and maps them into the
existing watchdog bootstatus flags for NPCM750 and NPCM845, while
leaving WPCM450 unchanged.
Addressed comments from:
- Krzysztof Kozlowski: https://patchwork.ozlabs.org/project/openbmc/patch/20260210133843.1078463-2-tmaimon77@gmail.com/
- Guenter Roeck: https://patchwork.ozlabs.org/project/openbmc/patch/20260210133843.1078463-3-tmaimon77@gmail.com/
Changes since version 1:
- Modify reset detection handle in the watchodg.
- reword patch 1 to use the GCR syscon-property wording from the
applied NPCM reset binding update and drop the optional property from
the binding example.
- reword the patch subjects and commit message bodies to match current
kernel dt-bindings, docs, and watchdog style.
Tomer Maimon (3):
dt-bindings: watchdog: npcm: add GCR syscon property
docs: watchdog: npcm: Add reset status description
watchdog: npcm: add bootstatus support
.../watchdog/nuvoton,npcm750-wdt.yaml | 6 +
Documentation/watchdog/index.rst | 1 +
Documentation/watchdog/npcm_wdt.rst | 70 +++++++
drivers/watchdog/npcm_wdt.c | 197 +++++++++++++++++-
4 files changed, 272 insertions(+), 2 deletions(-)
create mode 100644 Documentation/watchdog/npcm_wdt.rst
--
2.34.1
^ permalink raw reply
* Re: [PATCH 0/2] tracing: Move trace_printk.h out of kernel.h
From: Christophe Leroy (CS GROUP) @ 2026-06-22 8:05 UTC (permalink / raw)
To: Steven Rostedt, linux-kernel, linux-trace-kernel
Cc: Masami Hiramatsu, Mark Rutland, Mathieu Desnoyers, Andrew Morton,
Linus Torvalds, Sebastian Andrzej Siewior, John Ogness,
Thomas Gleixner, Peter Zijlstra, Julia Lawall, Yury Norov,
linux-doc, linux-kbuild, linuxppc-dev, dri-devel, linux-stm32,
linux-arm-kernel, linux-rdma, linux-usb, linux-ext4, linux-nfs,
kvm, intel-gfx
In-Reply-To: <20260621093430.264983361@kernel.org>
Le 21/06/2026 à 11:34, Steven Rostedt a écrit :
> There's been complaints about trace_printk() being defined in kernel.h as it
> can increase the compilation time. As it is only used by some developers for
> debugging purposes, it should not be in kernel.h causing lots of wasted CPU
> cycles for those that do not ever care about it.
Do we have a measurement of the increased compilation time ?
Christophe
>
> Instead, add a CONFIG_TRACE_PRINTK_DEBUGGING option that developers that do
> use it can set and not have to always remember to add #include <linux/trace_printk.h>
> to the files they add trace_printk() while debugging. It also means that
> those that do not have that config set will not have to worry about wasted
> CPU cycles as it is only include in the CFLAGS when the option is set, and
> its completely ignored otherwise.
>
> Steven Rostedt (2):
> tracing: Move non-trace_printk prototypes back to kernel.h
> tracing: Add CONFIG_TRACE_PRINTK_DEBUGGING to clean up kernel.h
>
> ----
> .../driver_development_debugging_guide.rst | 2 +-
> Makefile | 5 +++++
> arch/powerpc/kvm/book3s_xics.c | 1 +
> drivers/gpu/drm/i915/gt/intel_gtt.h | 1 +
> drivers/gpu/drm/i915/i915_gem.h | 1 +
> drivers/hwtracing/stm/dummy_stm.c | 4 ++++
> drivers/infiniband/hw/hfi1/trace_dbg.h | 1 +
> drivers/usb/early/xhci-dbc.c | 1 +
> fs/ext4/inline.c | 1 +
> include/linux/kernel.h | 19 ++++++++++++++++++-
> include/linux/sunrpc/debug.h | 1 +
> include/linux/trace_printk.h | 22 +++-------------------
> kernel/trace/Kconfig | 10 ++++++++++
> kernel/trace/ring_buffer_benchmark.c | 1 +
> kernel/trace/trace.h | 1 +
> samples/fprobe/fprobe_example.c | 1 +
> samples/ftrace/ftrace-direct-modify.c | 1 +
> samples/ftrace/ftrace-direct-multi-modify.c | 1 +
> samples/ftrace/ftrace-direct-multi.c | 2 +-
> samples/ftrace/ftrace-direct-too.c | 2 +-
> samples/ftrace/ftrace-direct.c | 2 +-
> 21 files changed, 56 insertions(+), 24 deletions(-)
>
^ permalink raw reply
* Re: [PATCH v8 23/46] KVM: TDX: Make source page optional for KVM_TDX_INIT_MEM_REGION
From: Yan Zhao @ 2026-06-22 7:18 UTC (permalink / raw)
To: Fuad Tabba
Cc: ackerleytng, aik, andrew.jones, binbin.wu, brauner, chao.p.peng,
david, jmattson, jthoughton, michael.roth, oupton, pankaj.gupta,
qperret, rick.p.edgecombe, rientjes, shivankg, steven.price,
willy, wyihan, forkloop, pratyush, suzuki.poulose, aneesh.kumar,
liam, Paolo Bonzini, Sean Christopherson, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, x86, H. Peter Anvin,
Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
Jonathan Corbet, Shuah Khan, Shuah Khan, Vishal Annapurve,
Andrew Morton, Chris Li, Kairui Song, Kemeng Shi, Nhat Pham,
Barry Song, Axel Rasmussen, Yuanchu Xie, Wei Xu, Youngjun Park,
Qi Zheng, Shakeel Butt, Kiryl Shutsemau, Baoquan He,
Jason Gunthorpe, Vlastimil Babka, kvm, linux-kernel,
linux-trace-kernel, linux-doc, linux-kselftest, linux-mm,
linux-coco
In-Reply-To: <CA+EHjTyj-JdW8H0ii2j3dayqnT2s3VV+brSG++p335=FGd2GXg@mail.gmail.com>
On Fri, Jun 19, 2026 at 12:09:54PM +0100, Fuad Tabba wrote:
> Sashiko flagged that when src_page = pfn_to_page(pfn),
> tdh_mem_page_add gets identical physical addresses for r8
> (destination) and r9 (source), reading with host KeyID and writing
> with TD KeyID on the same address.
This is allowed :)
See below description in the spec [1].
In-Place Add:
It is allowed to set the TD page HPA in R8 to the same address as the source
page HPA in R9. In this case the source page is converted to be a TD private
page.
[1] https://www.intel.com/content/www/us/en/content-details/853294/intel-trust-domain-extensions-intel-tdx-module-base-architecture-specification.html
^ permalink raw reply
* Re: [PATCH v8 23/46] KVM: TDX: Make source page optional for KVM_TDX_INIT_MEM_REGION
From: Yan Zhao @ 2026-06-22 6:57 UTC (permalink / raw)
To: ackerleytng
Cc: aik, andrew.jones, binbin.wu, brauner, chao.p.peng, david,
jmattson, jthoughton, michael.roth, oupton, pankaj.gupta, qperret,
rick.p.edgecombe, rientjes, shivankg, steven.price, tabba, willy,
wyihan, forkloop, pratyush, suzuki.poulose, aneesh.kumar, liam,
Paolo Bonzini, Sean Christopherson, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin, Steven Rostedt,
Masami Hiramatsu, Mathieu Desnoyers, Jonathan Corbet, Shuah Khan,
Shuah Khan, Vishal Annapurve, Andrew Morton, Chris Li,
Kairui Song, Kemeng Shi, Nhat Pham, Barry Song, Axel Rasmussen,
Yuanchu Xie, Wei Xu, Youngjun Park, Qi Zheng, Shakeel Butt,
Kiryl Shutsemau, Baoquan He, Jason Gunthorpe, Vlastimil Babka,
kvm, linux-kernel, linux-trace-kernel, linux-doc, linux-kselftest,
linux-mm, linux-coco
In-Reply-To: <20260618-gmem-inplace-conversion-v8-23-9d2959357853@google.com>
On Thu, Jun 18, 2026 at 05:32:00PM -0700, Ackerley Tng via B4 Relay wrote:
> From: Ackerley Tng <ackerleytng@google.com>
>
> Update tdx_gmem_post_populate() to handle cases where a source page is
> not explicitly provided. Instead of returning -EOPNOTSUPP when src_page
> is NULL, default to using the page associated with the destination PFN.
>
> This change allows for in-place memory conversion where the data is
> already present in the target PFN, ensuring the TDX module has a valid
> source page reference for the TDH.MEM.PAGE.ADD operation.
>
> Signed-off-by: Ackerley Tng <ackerleytng@google.com>
> Signed-off-by: Sean Christopherson <seanjc@google.com>
> ---
> Documentation/virt/kvm/x86/intel-tdx.rst | 4 ++++
> arch/x86/kvm/vmx/tdx.c | 11 ++++++++---
> 2 files changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/virt/kvm/x86/intel-tdx.rst b/Documentation/virt/kvm/x86/intel-tdx.rst
> index 6a222e9d09541..74357fe87f9ec 100644
> --- a/Documentation/virt/kvm/x86/intel-tdx.rst
> +++ b/Documentation/virt/kvm/x86/intel-tdx.rst
> @@ -158,6 +158,10 @@ KVM_TDX_INIT_MEM_REGION
> Initialize @nr_pages TDX guest private memory starting from @gpa with userspace
> provided data from @source_addr. @source_addr must be PAGE_SIZE-aligned.
>
> +If guest_memfd in-place conversion is enabled, pass NULL for @source_addr to
> +initialize the memory region using memory contents already populated in
> +guest_memfd memory.
> +
> Note, before calling this sub command, memory attribute of the range
> [gpa, gpa + nr_pages] needs to be private. Userspace can use
> KVM_SET_MEMORY_ATTRIBUTES to set the attribute.
> diff --git a/arch/x86/kvm/vmx/tdx.c b/arch/x86/kvm/vmx/tdx.c
> index ffe9d0db58c59..56d10333c61a7 100644
> --- a/arch/x86/kvm/vmx/tdx.c
> +++ b/arch/x86/kvm/vmx/tdx.c
> @@ -3198,8 +3198,12 @@ static int tdx_gmem_post_populate(struct kvm *kvm, gfn_t gfn, kvm_pfn_t pfn,
> if (KVM_BUG_ON(kvm_tdx->page_add_src, kvm))
> return -EIO;
>
> - if (!src_page)
> - return -EOPNOTSUPP;
> + if (!src_page) {
> + if (!gmem_in_place_conversion)
When userspace turns on gmem_in_place_conversion while creating guest_memfd
without the MMAP flag, the absence of src_page should still be treated as an
error.
Additionally, to properly enable in-place copying for the TDX initial memory
region, userspace must not only specify source_addr to NULL, but also follow
a specific sequence (where steps 1/2/3/7 are required only for in-place copy):
1. create guest_memfd with MMAP flag
2. mmap the guest_memfd.
3. convert the initial memory range to shared.
4. copy initial content to the source page.
5. convert the initial memory range to private
6. invoke ioctl KVM_TDX_INIT_MEM_REGION.
7. do not unmap the source backend.
So, would it be reasonable to introduce a dedicated flag that allows userspace
to explicitly opt into the in-place copy functionality? e.g.,
diff --git a/arch/x86/include/uapi/asm/kvm.h b/arch/x86/include/uapi/asm/kvm.h
index 1585ec804066..d047a6efc728 100644
--- a/arch/x86/include/uapi/asm/kvm.h
+++ b/arch/x86/include/uapi/asm/kvm.h
@@ -1043,6 +1043,9 @@ struct kvm_tdx_init_vm {
};
#define KVM_TDX_MEASURE_MEMORY_REGION _BITULL(0)
+#define KVM_TDX_IN_PLACE_COPY_INITIAL_MEMORY_REGION _BITULL(1)
+#define KVM_TDX_INIT_MEM_VALID_FLAGS (KVM_TDX_MEASURE_MEMORY_REGION | \
+ KVM_TDX_IN_PLACE_COPY_INITIAL_MEMORY_REGION)
struct kvm_tdx_init_mem_region {
__u64 source_addr;
diff --git a/arch/x86/kvm/vmx/tdx.c b/arch/x86/kvm/vmx/tdx.c
index 56d10333c61a..6072b38ceb37 100644
--- a/arch/x86/kvm/vmx/tdx.c
+++ b/arch/x86/kvm/vmx/tdx.c
@@ -3190,6 +3190,7 @@ static int tdx_gmem_post_populate(struct kvm *kvm, gfn_t gfn, kvm_pfn_t pfn,
struct page *src_page, void *_arg)
{
struct tdx_gmem_post_populate_arg *arg = _arg;
+ bool in_place_copy = arg->flags & KVM_TDX_IN_PLACE_COPY_INITIAL_MEMORY_REGION;
struct kvm_tdx *kvm_tdx = to_kvm_tdx(kvm);
u64 err, entry, level_state;
gpa_t gpa = gfn_to_gpa(gfn);
@@ -3199,7 +3200,7 @@ static int tdx_gmem_post_populate(struct kvm *kvm, gfn_t gfn, kvm_pfn_t pfn,
return -EIO;
if (!src_page) {
- if (!gmem_in_place_conversion)
+ if (!in_place_copy)
return -EOPNOTSUPP;
src_page = pfn_to_page(pfn);
@@ -3245,7 +3246,7 @@ static int tdx_vcpu_init_mem_region(struct kvm_vcpu *vcpu, struct kvm_tdx_cmd *c
if (kvm_tdx->state == TD_STATE_RUNNABLE)
return -EINVAL;
- if (cmd->flags & ~KVM_TDX_MEASURE_MEMORY_REGION)
+ if (cmd->flags & ~KVM_TDX_INIT_MEM_VALID_FLAGS)
return -EINVAL;
> + return -EOPNOTSUPP;
> +
> + src_page = pfn_to_page(pfn);
> + }
>
> kvm_tdx->page_add_src = src_page;
> ret = kvm_tdp_mmu_map_private_pfn(arg->vcpu, gfn, pfn);
> @@ -3278,7 +3282,8 @@ static int tdx_vcpu_init_mem_region(struct kvm_vcpu *vcpu, struct kvm_tdx_cmd *c
> break;
> }
>
> - region.source_addr += PAGE_SIZE;
> + if (region.source_addr)
> + region.source_addr += PAGE_SIZE;
> region.gpa += PAGE_SIZE;
> region.nr_pages--;
>
>
> --
> 2.55.0.rc0.738.g0c8ab3ebcc-goog
>
>
^ permalink raw reply related
* Re: [PATCH v2 3/4] irqchip/gic-v3: Add Renesas R-Car Gen4 erratum workaround
From: Marc Zyngier @ 2026-06-22 6:55 UTC (permalink / raw)
To: Marek Vasut
Cc: Thomas Gleixner, linux-pci, Yoshihiro Shimoda,
Krzysztof Wilczyński, Bjorn Helgaas, Catalin Marinas,
Conor Dooley, Geert Uytterhoeven, Krzysztof Kozlowski,
Lorenzo Pieralisi, Manivannan Sadhasivam, Rob Herring, devicetree,
linux-arm-kernel, linux-doc, linux-kernel, linux-renesas-soc
In-Reply-To: <d6fce333-4353-4e49-873f-eb3187a631e4@mailbox.org>
On Sun, 21 Jun 2026 23:46:25 +0100,
Marek Vasut <marek.vasut@mailbox.org> wrote:
>
> On 6/21/26 12:59 PM, Thomas Gleixner wrote:
> > On Fri, Jun 19 2026 at 00:02, Marek Vasut wrote:
> >> Renesas R-Car S4/V4H/V4M GIC600 integration has address width for AXI
> >> or APB interface configured to 32 bit, it can therefore access only
> >> the first 4 GiB of physical address space. This information comes from
> >> R-Car V4H Interface Specification sheet, there is currently no technical
> >> update number assigned to this limitation. Further input from hardware
> >> engineer indicates that this limitation also applies to R-Car S4 and V4M.
> >> Name the limitation GEN4GICITS1, and add a driver quirk to mitigate this
> >> limitation.
> >>
> >> The quirk is keyed on the combination of the GIC implementation
> >> and the platform identification in the device tree.
> >>
> >> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> >> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
> >
> > This SOB chain is broken.
>
> Broken ? I don't understand , could you please elaborate ?
Either Shimoda-san is the sole author of the change and you are
posting their work, then the first line of the patch should say:
From: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
with your own SoB immediately following their SoB (see [1]).
Or this has been co-developed, and both of you should be credited as
authors. then Shimoda-san's SoB should be preceded by their
Co-developed-by: tag (see [2]).
Co-developed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
This shows exactly who did what, who forwarded whose patch, and forms
the base of the DCO which is documented at [3].
Thanks,
M.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst#n449
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst#n503
[3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst#n396
--
Without deviation from the norm, progress is not possible.
^ 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