* Re: [PATCH v3 1/2] dt-bindings: iio: dac: Add AD5529R
From: Jonathan Cameron @ 2026-06-22 16:24 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: <ajkILRPq_g24g4dH@nsa>
On Mon, 22 Jun 2026 11:17:56 +0100
Nuno Sá <noname.nuno@gmail.com> wrote:
> 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?
Nope. It is what you suggest - the implementation in the gpio layer
is to detect the reuse of the same GPIO and insert a proxy layer that
allows multiple consumers. I think that will provide different gpio
numbers (well descs really) to each of them but I haven't checked the details
that closely.
>
> 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.
Yup. As much as we have an ack on SPI. So with a write only message you'd never
know if anyone got it.
Jonathan
>
> - Nuno Sá
>
> > Jonathan
> >
> > >
> > > - Nuno Sá
> > >
> >
>
^ permalink raw reply
* Re: [PATCH v3 06/12] fs/resctrl: Initialize the global kernel-mode policy at subsystem init
From: Reinette Chatre @ 2026-06-22 16:21 UTC (permalink / raw)
To: Babu Moger, corbet, tony.luck, Dave.Martin, james.morse, tglx, bp,
dave.hansen
Cc: skhan, x86, mingo, hpa, akpm, rdunlap, pawan.kumar.gupta,
feng.tang, dapeng1.mi, kees, elver, lirongqing, paulmck, bhelgaas,
seanjc, alexandre.chartre, yazen.ghannam, peterz, chang.seok.bae,
kim.phillips, xin, naveen, thomas.lendacky, linux-doc,
linux-kernel, eranian, peternewman
In-Reply-To: <416d685f-9e76-415a-bbb0-fc89f87827d9@amd.com>
Hi Babu,
On 6/18/26 10:14 AM, Babu Moger wrote:
> On 6/16/26 18:36, Reinette Chatre wrote:
>> On 4/30/26 4:24 PM, Babu Moger wrote:
>>
>>> - calls resctrl_arch_get_kmode_support() so each architecture ORs
>>> BIT(<mode>) into kmode for the policies its hardware supports
>>> (on x86, AMD PLZA contributes the two global-assign modes).
>>>
>>> resctrl_kmode_init() runs from resctrl_init() once the default group
>>
>> resctrl_kmode_init() can be dropped after changes described in response
>> to previous patch. Apart from no longer being necessary I also find that
>> having the kernel mode fully initialized *before* the hotplug handlers run
>> to be simpler.
>
> That means resctrl_set_kmode_support() will be called from the architecture layer, likely from core.c within get_rdt_alloc_resources().
>
> The resctrl_set_kmode_support() handler would need to initialize both the default mode and all supported modes.
I see this differently. Since resctrl_set_kmode_support() is optional for an architecture
resctrl fs can just statically initialize the defaults. resctrl_set_kmode_support() would
expand the defaults to also accommodate what the architecture supports.
Reinette
^ permalink raw reply
* Re: [PATCH RFC v5 2/6] Documentation: iio: add Open Sensor Fusion driver overview
From: Jonathan Cameron @ 2026-06-22 16:21 UTC (permalink / raw)
To: Jinseob Kim
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, David Lechner,
Nuno Sá, Andy Shevchenko, Jonathan Corbet, Shuah Khan,
linux-iio, devicetree, linux-doc, linux-kernel
In-Reply-To: <20260616072242.3942-3-kimjinseob88@gmail.com>
On Tue, 16 Jun 2026 16:22:38 +0900
Jinseob Kim <kimjinseob88@gmail.com> wrote:
> Document the Linux IIO mapping for Open Sensor Fusion devices, including
> capability-driven IIO device registration and the initially supported
> receive path.
>
> Call out that OSF0 is a wire magic value, while protocol_major and
> protocol_minor carry protocol compatibility inside frames. The Linux
> compatible remains the generic Open Sensor Fusion host interface.
>
> Signed-off-by: Jinseob Kim <kimjinseob88@gmail.com>
Just one small thing inline.
Otherwise this look good to me.
Thanks,
Jonathan
> ---
> Documentation/iio/index.rst | 1 +
> Documentation/iio/open-sensor-fusion.rst | 71 ++++++++++++++++++++++++
> 2 files changed, 72 insertions(+)
> create mode 100644 Documentation/iio/open-sensor-fusion.rst
>
> diff --git a/Documentation/iio/index.rst b/Documentation/iio/index.rst
> index ba3e609c6..2713ec5e0 100644
> --- a/Documentation/iio/index.rst
> +++ b/Documentation/iio/index.rst
> @@ -38,4 +38,5 @@ Industrial I/O Kernel Drivers
> adxl345
> bno055
> ep93xx_adc
> + open-sensor-fusion
> opt4060
> diff --git a/Documentation/iio/open-sensor-fusion.rst b/Documentation/iio/open-sensor-fusion.rst
> new file mode 100644
> index 000000000..cf3bbd761
> --- /dev/null
> +++ b/Documentation/iio/open-sensor-fusion.rst
> @@ -0,0 +1,71 @@
> +.. SPDX-License-Identifier: GPL-2.0-only
> +
> +Open Sensor Fusion
> +==================
> +
> +Open Sensor Fusion is a sensor aggregation hub interface. The Linux IIO driver
> +receives OSF protocol frames from an attached device, discovers supported sensor
> +streams through capability reports, and registers matching IIO devices for the
> +sensor classes supported by the driver.
> +
> +This document is a driver-facing overview for the Linux IIO mapping. The full
> +wire protocol, firmware behavior, and hardware model details belong in the Open
> +Sensor Fusion project documentation.
> +
> +Device Model
> +------------
> +
> +An OSF device sends binary frames from the device to the host. The host driver
> +uses ``CAPABILITY_REPORT`` messages to discover which sensor streams are
> +available. Device Tree describes the attached OSF sensor aggregation hub; it does
> +not enumerate the individual sensors discovered at runtime.
> +
> +The currently supported Linux subset exposes:
> +
> +* accelerometer samples as ``IIO_ACCEL`` X/Y/Z channels,
> +* gyroscope samples as ``IIO_ANGL_VEL`` X/Y/Z channels,
> +* magnetometer samples as ``IIO_MAGN`` X/Y/Z channels, and
> +* temperature samples as ``IIO_TEMP``.
> +
> +Protocol Scope
> +---------------
> +
> +The driver supports OSF protocol major version 0 for the initial IIO receive
> +path. The current wire magic is ``OSF0``; that string is a wire-format detail and
> +is not the Linux driver identity. Device Tree keeps the generic
> +``opensensorfusion,osf`` compatible rather than naming a product such as OSF
> +GREEN or a wire magic value.
I'd remove anything that is documented elsewhere (i.e. the dt-binding)
and instead use a cross reference to it. That will reduce the chance of this getting
out of sync.
> +
> +Protocol versioning is carried by the ``protocol_major`` and ``protocol_minor``
> +fields at fixed offsets in the OSF frame header. The driver currently
> +supports ``protocol_major`` 0. ``protocol_minor`` changes within major version
> +0 are intended to remain backward-compatible within the fixed header layout.
> +Incompatible wire-format changes require a new ``protocol_major``. A future
> +device that cannot expose compatible version discovery through that fixed
> +header layout would need a different Device Tree compatible.
> +
> +The initial Linux driver handles device-to-host frames for:
> +
> +* ``SENSOR_SAMPLE`` buffered and direct-mode sample data,
> +* ``CAPABILITY_REPORT`` based IIO device registration, and
> +* ``DEVICE_STATUS`` cache updates.
> +
> +Vendor-private message types are ignored. Command transport, calibration
> +control ABI, fusion output ABI, and runtime capability removal are outside the
> +initial Linux IIO receive path.
> +
> +Timestamps
> +----------
> +
> +OSF frames include a device-side ``timestamp_us`` field. Buffered IIO samples use
> +an IIO timestamp captured on the host when samples are pushed to IIO buffers.
> +The initial driver does not correlate the device timestamp with the host IIO
> +clock.
> +
> +Compatibility Notes
> +-------------------
> +
> +The project protocol documentation should define the compatibility rules for
> +reserved fields, optional flags, and trailing extension data. Until those rules
> +are finalized, the Linux decoder keeps conservative bounds checks around the
> +currently supported message layouts.
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: iio: dac: Add AD5529R
From: David Lechner @ 2026-06-22 15:36 UTC (permalink / raw)
To: Nuno Sá, Rodrigo Alencar
Cc: Jonathan Cameron, Conor Dooley, Janani Sunil, Janani Sunil,
Lars-Peter Clausen, Michael Hennerich, 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: <ajklksIDLsj0BZul@nsa>
On 6/22/26 7:20 AM, Nuno Sá wrote:
> On Mon, Jun 22, 2026 at 12:51:20PM +0100, Rodrigo Alencar wrote:
>> 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).
>
> True!
>
>>
>>> 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.
>
> Which makes me feel that different pins per device might be possible
> from an HW point of view but does not make much sense. For example, for
> the buffer example I would expect LDAC to be shared between all the
> devices.
>
> - Nuno Sá
I think I mentioned this on a previous revision, but I still think the
simplest way to go about it would be to assume that all chips treated
as an aggregate device have everything wired in parallel and just add
support for per-chip wiring on an as-needed basis. This is how we have
handled daisy-chained devices so far.
^ permalink raw reply
* Re: [PATCH] Docs/admin-guide/cgroup-v2: fix memory.stat doc details
From: Doehyun Baek @ 2026-06-22 15:26 UTC (permalink / raw)
To: Michal Koutný
Cc: Tejun Heo, Jonathan Corbet, Johannes Weiner, Andrew Morton,
Shakeel Butt, Roman Gushchin, Yosry Ahmed, Nhat Pham, cgroups,
linux-doc, linux-kernel
In-Reply-To: <ajlLhFnMZGoVxLE6@localhost.localdomain>
> ...but what do you mean by this?
> As I'm looking at the code in obj_cgroup_charge_zswap() and
> memcg_page_state_output_unit(), I'd say those are pages and the docs is
> thus alright.
>
> Thanks,
> Michal
Thanks for taking a look.
I agree that the counters are pages internally. I was talking about what
gets printed in memory.stat.
The internal updates are page-count based:
mod_memcg_state(memcg, MEMCG_ZSWAPPED, 1);
if (size == PAGE_SIZE)
mod_memcg_state(memcg, MEMCG_ZSWAP_INCOMP, 1);
However, both zswapped and zswap_incomp are memory_stats[] entries, so
memory.stat prints them through memcg_page_state_output(). Since
MEMCG_ZSWAP_INCOMP is not special-cased as a raw count, the stored page
count is multiplied by the default PAGE_SIZE unit and exported as bytes.
unsigned long memcg_page_state_output(struct mem_cgroup *memcg, int item)
{
return memcg_page_state(memcg, item) *
memcg_page_state_output_unit(item);
}
Separately, this matches the existing documentation style for zswapped,
whose exported value is described as a memory amount:
zswapped
Amount of application memory swapped out to zswap.
Since zswap_incomp follows the same memory.stat output path, I think its
documentation should describe the exported value as a memory amount too.
I also boot-tested this in QEMU with the current tree and zswap enabled.
With incompressible pages pushed into zswap, memory.stat showed:
zswap 87822336
zswapped 87822336
zswap_incomp 87822336
The zswap_incomp value there is byte-valued; it is not a plain page
count. It also matches zswapped in this all-incompressible case, which
is consistent with both being exported as memory amounts.
Best,
Doehyun Baek
^ permalink raw reply
* Re: [PATCH] Docs/admin-guide/cgroup-v2: fix memory.stat doc details
From: Michal Koutný @ 2026-06-22 14:59 UTC (permalink / raw)
To: Doehyun Baek
Cc: Tejun Heo, Jonathan Corbet, Johannes Weiner, Andrew Morton,
Shakeel Butt, Roman Gushchin, Yosry Ahmed, Nhat Pham, cgroups,
linux-doc, linux-kernel
In-Reply-To: <20260620122751.388770-1-doehyunbaek@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1816 bytes --]
On Sat, Jun 20, 2026 at 12:27:51PM +0000, Doehyun Baek <doehyunbaek@gmail.com> wrote:
> Fix minor cgroup v2 memory.stat documentation issues. Correct the
> vmalloc per-node marker now that vmalloc uses the native NR_VMALLOC node
> stat, and document zswap_incomp as a byte-valued memory amount instead
> of as a page counter.
>
> Fixes: c466412c73c3 ("mm: memcontrol: switch to native NR_VMALLOC vmstat counter")
> Fixes: 5ad41a38c364 ("mm: zswap: add per-memcg stat for incompressible pages")
> Signed-off-by: Doehyun Baek <doehyunbaek@gmail.com>
> ---
> Documentation/admin-guide/cgroup-v2.rst | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst
> index 993446ab66d0..ce6741f78f4f 100644
> --- a/Documentation/admin-guide/cgroup-v2.rst
> +++ b/Documentation/admin-guide/cgroup-v2.rst
> @@ -1570,7 +1570,7 @@ The following nested keys are defined.
> sock (npn)
> Amount of memory used in network transmission buffers
>
> - vmalloc (npn)
> + vmalloc
> Amount of memory used for vmap backed memory.
The vmalloc change looks OK...
>
> shmem
> @@ -1735,7 +1735,7 @@ The following nested keys are defined.
> Number of pages written from zswap to swap.
>
> zswap_incomp
> - Number of incompressible pages currently stored in zswap
> + Amount of memory used by incompressible pages currently stored in zswap
> without compression. These pages could not be compressed to
> a size smaller than PAGE_SIZE, so they are stored as-is.
...but what do you mean by this?
As I'm looking at the code in obj_cgroup_charge_zswap() and
memcg_page_state_output_unit(), I'd say those are pages and the docs is
thus alright.
Thanks,
Michal
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 265 bytes --]
^ permalink raw reply
* Re: [PATCH 0/4] nfs: remove the fileid field from struct nfs_inode
From: Anna Schumaker @ 2026-06-22 14:45 UTC (permalink / raw)
To: Jeff Layton, Trond Myklebust, Jonathan Corbet, Shuah Khan
Cc: linux-nfs, linux-kernel, linux-doc
In-Reply-To: <d0daedc8491e046c036bfe4e6915dc677e79428e.camel@kernel.org>
Hi Jeff,
On Sat, Jun 20, 2026, at 9:06 PM, Jeff Layton wrote:
> On Tue, 2026-05-12 at 12:12 -0400, 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>
>> ---
>> Jeff Layton (4):
>> nfs: store the full NFS fileid in inode->i_ino
>> nfs: remove nfs_compat_user_ino64() and deprecate enable_ino64
>> nfs: replace NFS_FILEID() and nfsi->fileid with inode->i_ino
>> nfs: remove fileid field from struct nfs_inode
>>
>> Documentation/admin-guide/kernel-parameters.txt | 7 --
>> fs/nfs/dir.c | 4 +-
>> fs/nfs/export.c | 6 +-
>> fs/nfs/filelayout/filelayout.c | 4 +-
>> fs/nfs/flexfilelayout/flexfilelayout.c | 6 +-
>> fs/nfs/inode.c | 87 +++++++++----------------
>> fs/nfs/nfs4proc.c | 4 +-
>> fs/nfs/nfs4trace.h | 79 ++++++++++------------
>> fs/nfs/nfstrace.h | 84 ++++++++++++------------
>> fs/nfs/pagelist.c | 2 +-
>> fs/nfs/pnfs.c | 2 +-
>> fs/nfs/unlink.c | 2 +-
>> fs/nfs/write.c | 2 +-
>> include/linux/nfs_fs.h | 25 -------
>> 14 files changed, 123 insertions(+), 191 deletions(-)
>> ---
>> base-commit: 5d6919055dec134de3c40167a490f33c74c12581
>> change-id: 20260512-nfsino-1f9a8ca2f3ed
>>
>> Best regards,
>
> Ping?
>
> i just noticed that this never made v7.2. Maybe consider for v7.3?
These are actually the first four patches in my linux-next branch for
the pull request I'm planning on sending (hopefully) later today.
Anna
> --
> Jeff Layton <jlayton@kernel.org>
^ permalink raw reply
* [PATCH] Documentation: tracing: fix typo in events documentation
From: Yudistira Putra @ 2026-06-22 14:37 UTC (permalink / raw)
To: Steven Rostedt, Masami Hiramatsu
Cc: Mathieu Desnoyers, Jonathan Corbet, Shuah Khan,
linux-trace-kernel, linux-doc, linux-kernel, Yudistira Putra
Fix a typo in the tracing events documentation: "can by built up"
should be "can be built up".
Signed-off-by: Yudistira Putra <pyudistira519@gmail.com>
---
Documentation/trace/events.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/trace/events.rst b/Documentation/trace/events.rst
index 18d112963dec..581f2260614b 100644
--- a/Documentation/trace/events.rst
+++ b/Documentation/trace/events.rst
@@ -1064,7 +1064,7 @@ correct command type, and a pointer to an event-specific run_command()
callback that will be called to actually execute the event-specific
command function.
-Once that's done, the command string can by built up by successive
+Once that's done, the command string can be built up by successive
calls to argument-adding functions.
To add a single argument, define and initialize a struct dynevent_arg
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v2 2/4] irqchip/gic-v3: Refactor GIC600 limited to 32bit PA erratum handling
From: Marek Vasut @ 2026-06-22 14:22 UTC (permalink / raw)
To: Geert Uytterhoeven, 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: <CAMuHMdUxT87M1oQvPP_h4YX4vXFaVbbG+LCG8EdmuLTuHNtybQ@mail.gmail.com>
On 6/22/26 11:52 AM, Geert Uytterhoeven wrote:
Hello Geert,
>> +++ 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...
I will fix that in V3. Thank you !
^ permalink raw reply
* Re: [Question] 5.posting.rst use To: or Cc:
From: Krzysztof Kozlowski @ 2026-06-22 14:15 UTC (permalink / raw)
To: Jonathan Corbet, Manuel Ebner, Shuah Khan,
open list:DOCUMENTATION PROCESS, open list:DOCUMENTATION,
open list
In-Reply-To: <87ik7o9bj0.fsf@trenco.lwn.net>
On 12/06/2026 14:41, Jonathan Corbet wrote:
> Manuel Ebner <manuelebner@mailbox.org> writes:
>
>> so every time I send a mail to lists or maintainers I have to choose: To:
>> or Cc:. I did look for an answer in the Documentation but couldn't find
>> one.
>> I think if there is an answer then it could be added to 5.posting.rst .
>
> Normally you would To: the maintainers, CC: the rest, but the end result
> is the same either way - it really doesn't matter.
>
Yes and 'b4' follows that logic. I think I saw only one case when
maintainer relied on actual To/Cc difference, but it was pointed out
that it is fragile and there is no unified rule.
Regardless, just use b4 to contribute patches because it solves all such
process issues. And whenever process is different, we tend to
fix/improve b4 to implement it correctly or we should change the
process, because in general we should not have rules which cannot be
implemented in toolset.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 4/5] hwmon: add Stratix 10 SoC FPGA hardware monitor driver
From: Krzysztof Kozlowski @ 2026-06-22 14:08 UTC (permalink / raw)
To: tze.yee.ng
Cc: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-hwmon, devicetree, linux-kernel, Dinh Nguyen, Mahesh Rao,
Jonathan Corbet, Shuah Khan, linux-doc
In-Reply-To: <081650bc4d92e9497b7a5a926e79a067cca3519f.1781861409.git.tze.yee.ng@altera.com>
On Fri, Jun 19, 2026 at 02:38:55AM -0700, tze.yee.ng@altera.com wrote:
> + dev_warn(dev, "unsupported sensor type %s\n", type);
> + return 0;
> +}
> +
> +static int stratix10_hwmon_probe_child_from_dt(struct device *dev,
> + struct device_node *child,
np
> + struct stratix10_hwmon_priv *priv)
> +{
> + struct device_node *grandchild;
child
> + const char *label;
> + u32 val;
> + int ret;
> +
> + for_each_child_of_node(child, grandchild) {
child
> + ret = of_property_read_u32(grandchild, "reg", &val);
> + if (ret) {
> + dev_err(dev, "missing reg property of %pOFn\n",
> + grandchild);
> + of_node_put(grandchild);
> + return ret;
> + }
> +
> + ret = of_property_read_string(grandchild, "label", &label);
> + if (ret)
> + label = grandchild->name;
> +
> + stratix10_hwmon_add_channel(dev, child->name, val, label, priv);
> + }
> +
> + return 0;
> +}
> +
> +static int stratix10_hwmon_probe_from_dt(struct device *dev,
> + struct stratix10_hwmon_priv *priv)
> +{
> + struct device_node *child;
> + int ret;
> +
> + if (!dev->of_node)
> + return 0;
> +
> + for_each_child_of_node(dev->of_node, child) {
Just use scoped. And why not available child node? Why do you probe
disabled channels?
> + ret = stratix10_hwmon_probe_child_from_dt(dev, child, priv);
> + if (ret) {
> + of_node_put(child);
> + return ret;
> + }
> + }
> +
> + return 0;
> +}
> +
> +static int stratix10_hwmon_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct stratix10_hwmon_priv *priv;
> + struct device *hwmon_dev;
> + int ret;
> +
> + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + priv->client.dev = dev;
> + priv->client.priv = priv;
> + init_completion(&priv->completion);
> + mutex_init(&priv->lock);
> +
> + ret = stratix10_hwmon_probe_from_dt(dev, priv);
> + if (ret) {
> + dev_err(dev, "Unable to probe from device tree\n");
> + return ret;
> + }
> +
> + if (!priv->temperature_channels && !priv->voltage_channels) {
> + dev_err(dev, "no temperature or voltage channels in device tree\n");
> + return -ENODEV;
> + }
> +
> + priv->chan = stratix10_svc_request_channel_byname(&priv->client,
> + SVC_CLIENT_HWMON);
> + if (IS_ERR(priv->chan)) {
> + ret = PTR_ERR(priv->chan);
> + if (ret == -EPROBE_DEFER)
> + dev_dbg(dev, "service channel %s not ready, deferring probe\n",
> + SVC_CLIENT_HWMON);
> + else
> + dev_err(dev, "couldn't get service channel %s: %d\n",
> + SVC_CLIENT_HWMON, ret);
> + return ret;
> + }
> +
> + ret = stratix10_svc_add_async_client(priv->chan, false);
> + switch (ret) {
> + case 0:
> + priv->async = true;
> + break;
> + case -EINVAL:
> + dev_dbg(dev, "async operations not supported, using sync mode\n");
> + priv->async = false;
> + break;
> + default:
> + dev_err(dev, "failed to add async client: %d\n", ret);
> + stratix10_svc_free_channel(priv->chan);
> + return ret;
> + }
> +
> + dev_info(dev, "Initialized %d temperature and %d voltage channels\n",
> + priv->temperature_channels, priv->voltage_channels);
Drop, driver should be silent on success. dev_dbg might be fine, but
honestly that's static information from DT so zero usefulness.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/5] dt-bindings: firmware: svc: add hwmon property
From: Krzysztof Kozlowski @ 2026-06-22 14:05 UTC (permalink / raw)
To: tze.yee.ng
Cc: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-hwmon, devicetree, linux-kernel, Dinh Nguyen, Mahesh Rao,
Jonathan Corbet, Shuah Khan, linux-doc
In-Reply-To: <be798fdfb7ec76e1f7d04c1fd00126c88c8a2e31.1781861409.git.tze.yee.ng@altera.com>
On Fri, Jun 19, 2026 at 02:38:53AM -0700, tze.yee.ng@altera.com wrote:
> From: Tze Yee Ng <tze.yee.ng@altera.com>
>
> Altera Stratix 10 SoCFPGA supports hardware monitor access through the
> service layer mailbox. Add an optional hwmon child node to the service
> layer binding so device trees can describe the hardware monitor.
>
> Signed-off-by: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
> Signed-off-by: Tze Yee Ng <tze.yee.ng@altera.com>
> ---
> .../devicetree/bindings/firmware/intel,stratix10-svc.yaml | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/firmware/intel,stratix10-svc.yaml b/Documentation/devicetree/bindings/firmware/intel,stratix10-svc.yaml
> index b42cfa78b28b..86ffdb10132f 100644
> --- a/Documentation/devicetree/bindings/firmware/intel,stratix10-svc.yaml
> +++ b/Documentation/devicetree/bindings/firmware/intel,stratix10-svc.yaml
> @@ -62,6 +62,10 @@ properties:
> $ref: /schemas/fpga/intel,stratix10-soc-fpga-mgr.yaml
> description: Optional child node for fpga manager to perform fabric configuration.
>
> + hwmon:
> + $ref: /schemas/hwmon/altr,stratix10-hwmon.yaml
So hwmon is completely fake wrapper over two other wrappers... If in
doubts, please read slides from DTS101 presentations from OSS, including
the chapter about Linux driver design.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/5] dt-bindings: hwmon: add Altera Stratix 10 hardware monitor binding
From: Krzysztof Kozlowski @ 2026-06-22 14:04 UTC (permalink / raw)
To: tze.yee.ng
Cc: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-hwmon, devicetree, linux-kernel, Dinh Nguyen, Mahesh Rao,
Jonathan Corbet, Shuah Khan, linux-doc
In-Reply-To: <ac5a118394e96f707823463fedd32b6a484c1ceb.1781861409.git.tze.yee.ng@altera.com>
On Fri, Jun 19, 2026 at 02:38:52AM -0700, tze.yee.ng@altera.com wrote:
> From: Tze Yee Ng <tze.yee.ng@altera.com>
>
> Document the device tree binding for the Altera Stratix 10 SoC FPGA
> hardware monitor, including temperature and voltage sensor nodes.
Also:
A nit, subject: drop second/last, redundant "binding". The
"dt-bindings" prefix is already stating that these are bindings.
See also:
https://elixir.bootlin.com/linux/v7.1-rc7/source/Documentation/devicetree/bindings/submitting-patches.rst#L23
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/5] dt-bindings: hwmon: add Altera Stratix 10 hardware monitor binding
From: Krzysztof Kozlowski @ 2026-06-22 14:04 UTC (permalink / raw)
To: tze.yee.ng
Cc: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-hwmon, devicetree, linux-kernel, Dinh Nguyen, Mahesh Rao,
Jonathan Corbet, Shuah Khan, linux-doc
In-Reply-To: <ac5a118394e96f707823463fedd32b6a484c1ceb.1781861409.git.tze.yee.ng@altera.com>
On Fri, Jun 19, 2026 at 02:38:52AM -0700, tze.yee.ng@altera.com wrote:
> From: Tze Yee Ng <tze.yee.ng@altera.com>
>
> Document the device tree binding for the Altera Stratix 10 SoC FPGA
> hardware monitor, including temperature and voltage sensor nodes.
>
> Signed-off-by: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
> Signed-off-by: Tze Yee Ng <tze.yee.ng@altera.com>
> ---
> .../bindings/hwmon/altr,stratix10-hwmon.yaml | 164 ++++++++++++++++++
> MAINTAINERS | 7 +
> 2 files changed, 171 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/hwmon/altr,stratix10-hwmon.yaml
>
> diff --git a/Documentation/devicetree/bindings/hwmon/altr,stratix10-hwmon.yaml b/Documentation/devicetree/bindings/hwmon/altr,stratix10-hwmon.yaml
> new file mode 100644
> index 000000000000..5bd98660ee7b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hwmon/altr,stratix10-hwmon.yaml
> @@ -0,0 +1,164 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/hwmon/altr,stratix10-hwmon.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Altera Hardware Monitor for Stratix 10 SoC FPGA
> +
> +maintainers:
> + - Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
> + - Tze Yee Ng <tze.yee.ng@altera.com>
> +
> +description: |
> + The Altera Stratix 10 SoC FPGA hardware monitor unit provides on-chip
> + voltage and temperature sensors. These sensors can be used to monitor
> + external voltages and on-chip operating conditions such as internal
> + power rails and on-chip junction temperatures.
> +
> + The specific sensor configuration varies by device. Check the device
> + documentation to verify which sensors are available.
> +
> + Stratix 10 voltage sensors:
> +
> + page 0, channel 2 = 0.8V VCC
> + page 0, channel 3 = 1.8V VCCIO_SDM
> + page 0, channel 6 = 0.9V VCCERAM
> +
> + Stratix 10 temperature sensors:
> +
> + page 0, channel 0 = main die
> + page 0, channel 1 = tile bottom left
> + page 0, channel 2 = tile middle left
> + page 0, channel 3 = tile top left
> + page 0, channel 4 = tile bottom right
> + page 0, channel 5 = tile middle right
> + page 0, channel 6 = tile top right
> + page 0, channel 7 = hbm2 bottom
> + page 0, channel 8 = hbm2 top
> +
> +properties:
> + compatible:
> + const: altr,stratix10-hwmon
> +
Where are top-level properties? clocks? interrupts? power-domain,
resets? address space? Anything? Did you read writing bindings doc?
> + temperature:
> + description:
> + The temperature node specifies mappings of temperature sensor diodes on
> + the Stratix 10 SoC FPGA main die and tile die.
> + type: object
Blank line
> + properties:
> + '#address-cells':
> + const: 1
> + '#size-cells':
> + const: 0
Blank line
> + patternProperties:
> + "^input(@[0-9a-f]+)?$":
Unit address should not be optional.
Also, use consistent style of quotes.
> + description:
> + The input node specifies each individual temperature sensor.
> + type: object
> + properties:
> + reg:
> + description:
> + Sensor channel index in the lower 16-bits (0-15). For temperature
> + sensors, the page number is encoded in the upper 16-bits.
> + The driver encodes the SMC request argument as a channel
> + bitmask (1 << channel) in bits 0..15, with the page number
> + placed in bits 16..31. Channel values >= 16 are rejected to
> + avoid overlap with the page field. For example, reg = <2>
> + selects channel 2 and the driver passes 0x4 to the service layer.
> + label:
> + description:
> + A descriptive name for this channel (e.g. "Main Die" or
> + "Tile Bottom Left").
> + required:
> + - reg
> + additionalProperties: false
All this is difficult to read. Please open other bindings to understand
the style used in Linux kernel.
> + required:
> + - '#address-cells'
> + - '#size-cells'
> + additionalProperties: false
> +
> + voltage:
> + description:
> + The voltage node specifies mappings of voltage sensors on the Stratix 10
> + SoC FPGA analog to digital converter of the Secure Device Manager (SDM).
> + type: object
> + properties:
> + '#address-cells':
> + const: 1
> + '#size-cells':
> + const: 0
> + patternProperties:
> + "^input(@[0-9a-f]+)?$":
Isn't this usually called channel?
> + description:
> + The input node specifies each individual voltage sensor.
> + type: object
> + properties:
> + reg:
> + description:
> + Sensor channel index in the lower 16-bits (0-15). The driver
> + encodes the SMC request argument as a channel bitmask
> + (1 << channel). For example, reg = <2> selects channel 2 and
> + the driver passes 0x4 to the service layer.
> + label:
> + description:
> + A descriptive name for this channel (e.g. "0.8V VCC" or
> + "1.8V VCCIO_SDM").
> + required:
> + - reg
> + additionalProperties: false
> + required:
> + - '#address-cells'
> + - '#size-cells'
> + additionalProperties: false
> +
> +required:
> + - compatible
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + hwmon {
> + compatible = "altr,stratix10-hwmon";
> +
> + voltage {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + input@2 {
> + label = "0.8V VCC";
> + reg = <2>;
> + };
> +
> + input@3 {
> + label = "1.8V VCCIO_SDM";
> + reg = <3>;
> + };
> +
> + input@6 {
> + label = "0.9V VCCERAM";
> + reg = <6>;
> + };
> + };
> +
> + temperature {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + input@0 {
> + label = "Main Die";
> + reg = <0>;
> + };
> +
> + input@1 {
> + label = "Tile Bottom Left";
> + reg = <1>;
> + };
> +
> + input@2 {
> + label = "Tile Middle Left";
> + reg = <2>;
> + };
> + };
> + };
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 6aa3fe2ee1bb..678f6c429627 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -937,6 +937,13 @@ ALPS PS/2 TOUCHPAD DRIVER
> R: Pali Rohár <pali@kernel.org>
> F: drivers/input/mouse/alps.*
>
> +ALTERA STRATIX 10 SoC FPGA HWMON DRIVER
> +M: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
> +M: Tze Yee Ng <tze.yee.ng@altera.com>
> +L: linux-hwmon@vger.kernel.org
> +S: Maintained
> +F: Documentation/devicetree/bindings/hwmon/altr,stratix10-hwmon.yaml
> +
> ALTERA MAILBOX DRIVER
Does not look sorted. Please read this file before changing it.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v3 8/8] docs: misc: amd-sbi: Document SBTSI userspace interface
From: Akshay Gupta @ 2026-06-22 13:58 UTC (permalink / raw)
To: linux-doc, linux-kernel, linux-hwmon
Cc: corbet, skhan, linux, arnd, gregkh, NaveenKrishna.Chatradhi,
Anand.Umarji, Akshay.Gupta, Prathima.Lk
In-Reply-To: <20260622135821.2190260-1-Akshay.Gupta@amd.com>
From: Prathima <Prathima.Lk@amd.com>
- Document AMD sideband IOCTL description defined
for SBTSI and its usage.
User space C-APIs are made available by esmi_oob_library [1],
which is provided by the E-SMS project [2].
Link: https://github.com/amd/esmi_oob_library [1]
Link: https://www.amd.com/en/developer/e-sms.html [2]
Include a user-space open example for /dev/sbtsi-* and list auxiliary
bus sysfs paths.
Reviewed-by: Akshay Gupta <Akshay.Gupta@amd.com>
Signed-off-by: Prathima <Prathima.Lk@amd.com>
---
Changes since v2:
- Update misc node names info as per socket
Changes since v1:
- Elaborate the document
Documentation/misc-devices/amd-sbi.rst | 68 ++++++++++++++++++++++++++
1 file changed, 68 insertions(+)
diff --git a/Documentation/misc-devices/amd-sbi.rst b/Documentation/misc-devices/amd-sbi.rst
index f91ddadefe48..fbbbc504119f 100644
--- a/Documentation/misc-devices/amd-sbi.rst
+++ b/Documentation/misc-devices/amd-sbi.rst
@@ -48,6 +48,60 @@ Access restrictions:
* APML Mailbox messages and Register xfer access are read-write,
* CPUID and MCA_MSR access is read-only.
+SBTSI device
+============
+
+sbtsi driver under the drivers/misc/amd-sbi creates miscdevice
+/dev/sbtsi-* to let user space programs run APML TSI register xfer
+commands.
+
+The driver supports both I2C and I3C transports for SB-TSI targets.
+The transport is selected by the bus where the device is enumerated.
+
+Misc device:
+ * In 1P socket 0: /dev/sbtsi-4c
+ * In 2P socket 0: /dev/sbtsi-4c, socket 1: /dev/sbtsi-48
+
+.. code-block:: bash
+
+ $ ls -al /dev/sbtsi-4c
+ crw------- 1 root root 10, 116 Apr 2 05:22 /dev/sbtsi-4c
+
+
+Access restrictions:
+ * Only root user is allowed to open the file.
+ * APML TSI Register xfer access is read-write.
+
+SBTSI hwmon interface
+=====================
+
+The sbtsi_temp auxiliary driver binds to the auxiliary device published
+by the core sbtsi driver on the auxiliary bus. The auxiliary device is
+named amd-sbtsi.temp-sensor.<addr> where <addr> is the device's dynamic
+address.
+
+It registers a hwmon device, providing a standard Linux hwmon interface
+for reading CPU temperature and managing temperature limits.
+
+The hwmon device appears under ``/sys/class/hwmon/`` when both ``sbtsi.ko``
+and ``sbtsi_temp.ko`` are loaded.
+
+Verify auxiliary bus device::
+
+ ls /sys/bus/auxiliary/devices/
+ # e.g. amd-sbtsi.temp-sensor.X
+
+Example usage::
+
+ # Read current temperature
+ cat /sys/class/hwmon/hwmon<N>/temp1_input
+
+ # Set high temperature limit to 70 °C
+ echo 70000 > /sys/class/hwmon/hwmon<N>/temp1_max
+
+ # Verify
+ cat /sys/class/hwmon/hwmon<N>/temp1_max
+
Driver IOCTLs
=============
@@ -63,6 +117,9 @@ Driver IOCTLs
.. c:macro:: SBRMI_IOCTL_REG_XFER_CMD
.. kernel-doc:: include/uapi/misc/amd-apml.h
:doc: SBRMI_IOCTL_REG_XFER_CMD
+.. c:macro:: SBTSI_IOCTL_REG_XFER_CMD
+.. kernel-doc:: include/uapi/misc/amd-apml.h
+ :doc: SBTSI_IOCTL_REG_XFER_CMD
User-space usage
================
@@ -85,6 +142,16 @@ Next thing, open the device file, as follows::
exit(1);
}
+To open SB-TSI device::
+
+ int file;
+
+ file = open("/dev/sbtsi-4c", O_RDWR);
+ if (file < 0) {
+ /* ERROR HANDLING */
+ exit(1);
+ }
+
The following IOCTLs are defined:
``#define SB_BASE_IOCTL_NR 0xF9``
@@ -92,6 +159,7 @@ The following IOCTLs are defined:
``#define SBRMI_IOCTL_CPUID_CMD _IOWR(SB_BASE_IOCTL_NR, 1, struct apml_cpuid_msg)``
``#define SBRMI_IOCTL_MCAMSR_CMD _IOWR(SB_BASE_IOCTL_NR, 2, struct apml_mcamsr_msg)``
``#define SBRMI_IOCTL_REG_XFER_CMD _IOWR(SB_BASE_IOCTL_NR, 3, struct apml_reg_xfer_msg)``
+``#define SBTSI_IOCTL_REG_XFER_CMD _IOWR(SB_BASE_IOCTL_NR, 4, struct apml_tsi_xfer_msg)``
User space C-APIs are made available by esmi_oob_library, hosted at
--
2.34.1
^ permalink raw reply related
* [PATCH v3 5/8] misc: amd-sbi: Add support for SB-TSI over I3C
From: Akshay Gupta @ 2026-06-22 13:58 UTC (permalink / raw)
To: linux-doc, linux-kernel, linux-hwmon
Cc: corbet, skhan, linux, arnd, gregkh, NaveenKrishna.Chatradhi,
Anand.Umarji, Akshay.Gupta, Prathima.Lk
In-Reply-To: <20260622135821.2190260-1-Akshay.Gupta@amd.com>
From: Prathima <Prathima.Lk@amd.com>
AMD SB-TSI temperature sensors can be accessed over both
I2C and I3C buses depending on the platform configuration.
Extend the SB-TSI driver to support both I2C and I3C bus interfaces
by selecting the appropriate transport based on the probed bus type.
The driver maintains backward compatibility with existing I2C
deployments while enabling support for systems using the I3C bus.
Register both I2C and I3C drivers using module_i3c_i2c_driver() and
update the Kconfig dependency from I2C to I3C_OR_I2C.
Reviewed-by: Akshay Gupta <Akshay.Gupta@amd.com>
Signed-off-by: Prathima <Prathima.Lk@amd.com>
---
Changes since v2:
- Fix DMA mapping issue to prevent memory corruption or kernel panics
when CONFIG_VMAP_STACK is enabled
- Use i3c_device_get_info() to populate i3c_device_info structure fields
- Remove unused header file inclusion from "include/linux/misc/tsi.h"
Changes since v1:
- Changes in accordance with usage of auxiliary device
drivers/misc/amd-sbi/Kconfig | 4 +--
drivers/misc/amd-sbi/tsi-core.c | 58 ++++++++++++++++++++++++++++++++-
drivers/misc/amd-sbi/tsi-core.h | 23 +++++++++++++
drivers/misc/amd-sbi/tsi.c | 58 ++++++++++++++++++++++++++++++---
include/linux/misc/tsi.h | 11 +++++--
5 files changed, 145 insertions(+), 9 deletions(-)
create mode 100644 drivers/misc/amd-sbi/tsi-core.h
diff --git a/drivers/misc/amd-sbi/Kconfig b/drivers/misc/amd-sbi/Kconfig
index 512251690e0e..1a96b71f8506 100644
--- a/drivers/misc/amd-sbi/Kconfig
+++ b/drivers/misc/amd-sbi/Kconfig
@@ -23,13 +23,13 @@ config AMD_SBRMI_HWMON
config AMD_SBTSI
tristate "AMD side band TSI support"
- depends on I2C
+ depends on I3C_OR_I2C
depends on ARM || ARM64 || COMPILE_TEST
select AUXILIARY_BUS
help
Enables support for the AMD SB-TSI (Side Band Temperature Sensor
Interface) driver, which provides access to emulated CPU temperature
- sensors on AMD SoCs via an I2C connected BMC device.
+ sensors on AMD SoCs via an I2C/I3C connected BMC device.
This driver can also be built as a module. If so, the module will
be called sbtsi.
diff --git a/drivers/misc/amd-sbi/tsi-core.c b/drivers/misc/amd-sbi/tsi-core.c
index 6ef1831515bb..9278d06d8e5f 100644
--- a/drivers/misc/amd-sbi/tsi-core.c
+++ b/drivers/misc/amd-sbi/tsi-core.c
@@ -7,7 +7,17 @@
*/
#include <linux/module.h>
-#include <linux/misc/tsi.h>
+#include "tsi-core.h"
+
+static inline struct sbtsi_i3c_priv *to_sbtsi_i3c_priv(struct sbtsi_data *data)
+{
+ return container_of(data, struct sbtsi_i3c_priv, data);
+}
+
+static u8 *sbtsi_i3c_buf(struct sbtsi_data *data)
+{
+ return to_sbtsi_i3c_priv(data)->buf;
+}
/* I2C transfer function */
static int sbtsi_i2c_xfer(struct sbtsi_data *data, u8 reg, u8 *val, bool is_read)
@@ -23,8 +33,54 @@ static int sbtsi_i2c_xfer(struct sbtsi_data *data, u8 reg, u8 *val, bool is_read
return i2c_smbus_write_byte_data(data->client, reg, *val);
}
+/* I3C read transfer function */
+static int sbtsi_i3c_read(struct sbtsi_data *data, u8 reg, u8 *val)
+{
+ struct i3c_xfer xfers[2] = { };
+ u8 *buf = sbtsi_i3c_buf(data);
+ int ret;
+
+ buf[0] = reg;
+ /* Add Register data to read/write */
+ xfers[0].rnw = false;
+ xfers[0].len = 1;
+ xfers[0].data.out = &buf[0];
+
+ xfers[1].rnw = true;
+ xfers[1].len = 1;
+ xfers[1].data.in = &buf[1];
+
+ ret = i3c_device_do_xfers(data->i3cdev, xfers, 2, I3C_SDR);
+ if (ret)
+ return ret;
+
+ *val = buf[1];
+ return ret;
+}
+
+/* I3C write transfer function */
+static int sbtsi_i3c_write(struct sbtsi_data *data, u8 reg, u8 val)
+{
+ u8 *buf = sbtsi_i3c_buf(data);
+ struct i3c_xfer xfers = {
+ .rnw = false,
+ .len = 2,
+ .data.out = buf,
+ };
+
+ buf[0] = reg;
+ buf[1] = val;
+
+ return i3c_device_do_xfers(data->i3cdev, &xfers, 1, I3C_SDR);
+}
+
+/* Unified transfer function for I2C and I3C access */
int sbtsi_xfer(struct sbtsi_data *data, u8 reg, u8 *val, bool is_read)
{
+ if (data->is_i3c)
+ return is_read ? sbtsi_i3c_read(data, reg, val)
+ : sbtsi_i3c_write(data, reg, *val);
+
return sbtsi_i2c_xfer(data, reg, val, is_read);
}
EXPORT_SYMBOL_GPL(sbtsi_xfer);
diff --git a/drivers/misc/amd-sbi/tsi-core.h b/drivers/misc/amd-sbi/tsi-core.h
new file mode 100644
index 000000000000..7dde040caf30
--- /dev/null
+++ b/drivers/misc/amd-sbi/tsi-core.h
@@ -0,0 +1,23 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * AMD SBTSI core driver private definitions.
+ *
+ * Copyright (C) 2026 Advanced Micro Devices, Inc.
+ */
+
+#ifndef _LINUX_TSI_CORE_H_
+#define _LINUX_TSI_CORE_H_
+
+#include <linux/misc/tsi.h>
+
+/**
+ * struct sbtsi_i3c_priv - per-device state for I3C SBTSI (includes DMA-safe buffers)
+ * @data: public device state exposed via dev_set_drvdata()
+ * @buf: I3C transfer buffer; [0] register address, [1] data byte
+ */
+struct sbtsi_i3c_priv {
+ struct sbtsi_data data;
+ u8 buf[2];
+};
+
+#endif /* _LINUX_TSI_CORE_H_ */
diff --git a/drivers/misc/amd-sbi/tsi.c b/drivers/misc/amd-sbi/tsi.c
index a4c7e1be5624..8fb17ccab73d 100644
--- a/drivers/misc/amd-sbi/tsi.c
+++ b/drivers/misc/amd-sbi/tsi.c
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0-or-later
/*
- * tsi.c - AMD SBTSI I2C core driver. Probes the SBTSI device over I2C
+ * tsi.c - AMD SBTSI I2C/I3C core driver. Probes the SBTSI device over I2C/I3C
* and publishes an auxiliary device on the auxiliary bus.
*
* Copyright (C) 2026 Advanced Micro Devices, Inc.
@@ -10,8 +10,8 @@
#include <linux/bitfield.h>
#include <linux/module.h>
#include <linux/of.h>
-#include <linux/misc/tsi.h>
#include <linux/slab.h>
+#include "tsi-core.h"
#define SBTSI_REG_CONFIG 0x03 /* RO */
@@ -109,6 +109,7 @@ static int sbtsi_i2c_probe(struct i2c_client *client)
if (!data)
return -ENOMEM;
+ data->is_i3c = false;
data->client = client;
data->dev_addr = client->addr;
@@ -138,7 +139,56 @@ static struct i2c_driver sbtsi_driver = {
.id_table = sbtsi_id,
};
-module_i2c_driver(sbtsi_driver);
+static int sbtsi_i3c_probe(struct i3c_device *i3cdev)
+{
+ struct device *dev = i3cdev_to_dev(i3cdev);
+ struct i3c_device_info devinfo;
+ struct sbtsi_i3c_priv *i3c_priv;
+ struct sbtsi_data *data;
+
+ /*
+ * AMD OOB devices differ on basis of Instance ID,
+ * for SBTSI, instance ID is 0.
+ * As the device Id match is not on basis of Instance ID,
+ * add the below check to probe the SBTSI device only and
+ * not other OOB devices.
+ */
+ i3c_device_get_info(i3cdev, &devinfo);
+ if (I3C_PID_INSTANCE_ID(devinfo.pid) != 0)
+ return -ENXIO;
+
+ i3c_priv = devm_kzalloc(dev, sizeof(*i3c_priv), GFP_KERNEL);
+ if (!i3c_priv)
+ return -ENOMEM;
+
+ data = &i3c_priv->data;
+ data->i3cdev = i3cdev;
+ data->is_i3c = true;
+ data->dev_addr = devinfo.dyn_addr;
+
+ return sbtsi_probe_common(dev, data);
+}
+
+static const struct i3c_device_id sbtsi_i3c_id[] = {
+ /* PID for AMD SBTSI device */
+ I3C_DEVICE_EXTRA_INFO(0x112, 0x0, 0x1, NULL), /* Socket:0, Turin and Genoa */
+ I3C_DEVICE_EXTRA_INFO(0x0, 0x0, 0x118, NULL), /* Socket:0, Venice */
+ I3C_DEVICE_EXTRA_INFO(0x0, 0x100, 0x118, NULL), /* Socket:1, Venice */
+ I3C_DEVICE_EXTRA_INFO(0x112, 0x0, 0x119, NULL), /* Socket:0, Venice */
+ I3C_DEVICE_EXTRA_INFO(0x112, 0x100, 0x119, NULL), /* Socket:1, Venice */
+ {}
+};
+MODULE_DEVICE_TABLE(i3c, sbtsi_i3c_id);
+
+static struct i3c_driver sbtsi_i3c_driver = {
+ .driver = {
+ .name = "sbtsi-i3c",
+ },
+ .probe = sbtsi_i3c_probe,
+ .id_table = sbtsi_i3c_id,
+};
+
+module_i3c_i2c_driver(sbtsi_i3c_driver, &sbtsi_driver);
-MODULE_DESCRIPTION("AMD SB-TSI I2C core driver");
+MODULE_DESCRIPTION("AMD SB-TSI I2C/I3C core driver");
MODULE_LICENSE("GPL");
diff --git a/include/linux/misc/tsi.h b/include/linux/misc/tsi.h
index 55ee7e42a65d..02c90ec285ec 100644
--- a/include/linux/misc/tsi.h
+++ b/include/linux/misc/tsi.h
@@ -9,20 +9,27 @@
#define _LINUX_MISC_TSI_H_
#include <linux/i2c.h>
+#include <linux/i3c/device.h>
#include <linux/types.h>
/**
* struct sbtsi_data - driver private data for an AMD SB-TSI device
* @client: underlying I2C client
- * @dev_addr: I2C device address, used to name the misc device node
+ * @i3cdev: underlying I3C device (when using I3C bus)
+ * @dev_addr: I2C/I3C device address, used to name the misc device node
* @ext_range_mode: sensor uses extended temperature range
* @read_order: if set, decimal part must be read before integer part
+ * @is_i3c: true when the device is accessed over I3C
*/
struct sbtsi_data {
- struct i2c_client *client;
+ union {
+ struct i2c_client *client;
+ struct i3c_device *i3cdev;
+ };
u8 dev_addr;
bool ext_range_mode;
bool read_order;
+ bool is_i3c;
};
/*
--
2.34.1
^ permalink raw reply related
* [PATCH v3 7/8] hwmon: Add mutex protecting for sbtsi read/write through hwmon
From: Akshay Gupta @ 2026-06-22 13:58 UTC (permalink / raw)
To: linux-doc, linux-kernel, linux-hwmon
Cc: corbet, skhan, linux, arnd, gregkh, NaveenKrishna.Chatradhi,
Anand.Umarji, Akshay.Gupta, Prathima.Lk
In-Reply-To: <20260622135821.2190260-1-Akshay.Gupta@amd.com>
From: Prathima <Prathima.Lk@amd.com>
Add a mutex and take it around SBTSI read/write paths so that only
one transaction runs at a time. The lock is held only for the
duration of the bus transfer and associated driver bookkeeping, not
across blocking work unrelated to SBTSI.
This is a concurrency hardening fix.
Reviewed-by: Akshay Gupta <Akshay.Gupta@amd.com>
Signed-off-by: Prathima <Prathima.Lk@amd.com>
---
Changes since v2:
- New patch
drivers/hwmon/sbtsi_temp.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/hwmon/sbtsi_temp.c b/drivers/hwmon/sbtsi_temp.c
index d7ae986d824c..11c8108d69b2 100644
--- a/drivers/hwmon/sbtsi_temp.c
+++ b/drivers/hwmon/sbtsi_temp.c
@@ -70,6 +70,7 @@ static int sbtsi_temp_read(struct sbtsi_data *data, u8 reg1, u8 reg2,
{
int ret;
+ guard(sbtsi)(data);
ret = sbtsi_xfer(data, reg1, val1, true);
if (!ret)
ret = sbtsi_xfer(data, reg2, val2, true);
@@ -84,6 +85,7 @@ static int sbtsi_temp_write(struct sbtsi_data *data, u8 reg_int, u8 reg_dec,
{
int ret;
+ guard(sbtsi)(data);
ret = sbtsi_xfer(data, reg_int, &val_int, false);
if (!ret)
ret = sbtsi_xfer(data, reg_dec, &val_dec, false);
--
2.34.1
^ permalink raw reply related
* [PATCH v3 6/8] misc: amd-sbi: Add SBTSI ioctl register transfer interface
From: Akshay Gupta @ 2026-06-22 13:58 UTC (permalink / raw)
To: linux-doc, linux-kernel, linux-hwmon
Cc: corbet, skhan, linux, arnd, gregkh, NaveenKrishna.Chatradhi,
Anand.Umarji, Akshay.Gupta, Prathima.Lk
In-Reply-To: <20260622135821.2190260-1-Akshay.Gupta@amd.com>
From: Prathima <Prathima.Lk@amd.com>
Implement IOCTL interface for SB-TSI driver to enable userspace access
to TSI register read/write operations through the AMD Advanced Platform
Management Link (APML) protocol.
Add an ioctl command (SBTSI_IOCTL_REG_XFER_CMD) that accepts a register
address, data byte, and direction flag. Serialize access with a mutex
shared between the hwmon and ioctl paths to prevent concurrent bus
transactions from corrupting register state.
Reviewed-by: Akshay Gupta <Akshay.Gupta@amd.com>
Signed-off-by: Prathima <Prathima.Lk@amd.com>
---
Changes since v2:
- Address feedback to hide mutex with common guard function
- Separate out mutex patch in hwmon file to next patch, 7/8
- Use file operation, open/release and kref to prevent use-after-free
if the device is unbound in IOCTL
- Add check for msg.pad
Changes since v1:
- Use of devm_mutex_init in place of mutex_init
- Use of guard_mutex in place of mutex_lock()/mutex_unlock()
- Use of devm_add_action_or_reset() for clean removal
drivers/misc/amd-sbi/tsi-core.c | 118 +++++++++++++++++++++++++++++++-
drivers/misc/amd-sbi/tsi-core.h | 3 +
drivers/misc/amd-sbi/tsi.c | 36 +++++++++-
include/linux/misc/tsi.h | 15 ++++
include/uapi/misc/amd-apml.h | 23 +++++++
5 files changed, 191 insertions(+), 4 deletions(-)
diff --git a/drivers/misc/amd-sbi/tsi-core.c b/drivers/misc/amd-sbi/tsi-core.c
index 9278d06d8e5f..688b9221868f 100644
--- a/drivers/misc/amd-sbi/tsi-core.c
+++ b/drivers/misc/amd-sbi/tsi-core.c
@@ -6,7 +6,11 @@
* Copyright (C) 2026 Advanced Micro Devices, Inc.
*/
+#include <linux/fs.h>
+#include <linux/ioctl.h>
#include <linux/module.h>
+#include <linux/uaccess.h>
+#include <uapi/misc/amd-apml.h>
#include "tsi-core.h"
static inline struct sbtsi_i3c_priv *to_sbtsi_i3c_priv(struct sbtsi_data *data)
@@ -19,6 +23,17 @@ static u8 *sbtsi_i3c_buf(struct sbtsi_data *data)
return to_sbtsi_i3c_priv(data)->buf;
}
+void sbtsi_data_release(struct kref *kref)
+{
+ struct sbtsi_data *data = container_of(kref, struct sbtsi_data, kref);
+
+ mutex_destroy(&data->lock);
+ if (data->is_i3c)
+ kfree(to_sbtsi_i3c_priv(data));
+ else
+ kfree(data);
+}
+
/* I2C transfer function */
static int sbtsi_i2c_xfer(struct sbtsi_data *data, u8 reg, u8 *val, bool is_read)
{
@@ -80,7 +95,108 @@ int sbtsi_xfer(struct sbtsi_data *data, u8 reg, u8 *val, bool is_read)
if (data->is_i3c)
return is_read ? sbtsi_i3c_read(data, reg, val)
: sbtsi_i3c_write(data, reg, *val);
-
return sbtsi_i2c_xfer(data, reg, val, is_read);
}
EXPORT_SYMBOL_GPL(sbtsi_xfer);
+
+/*
+ * The mutex protects against concurrent access to the shared I2C/I3C bus by
+ * the hwmon sysfs and a userspace ioctl.
+ */
+static int sbtsi_xfer_ioctl(struct sbtsi_data *data, u8 reg, u8 *val, bool is_read)
+{
+ guard(sbtsi)(data);
+ return sbtsi_xfer(data, reg, val, is_read);
+}
+
+static int apml_tsi_reg_xfer(struct sbtsi_data *data,
+ struct apml_tsi_xfer_msg __user *arg)
+{
+ struct apml_tsi_xfer_msg msg = { 0 };
+ int ret;
+
+ if (data->detached)
+ return -ENODEV;
+
+ if (copy_from_user(&msg, arg, sizeof(struct apml_tsi_xfer_msg)))
+ return -EFAULT;
+
+ if (msg.pad)
+ return -EINVAL;
+
+ ret = sbtsi_xfer_ioctl(data, msg.reg_addr, &msg.data_in_out, msg.rflag);
+
+ if (msg.rflag && !ret) {
+ if (copy_to_user(arg, &msg, sizeof(struct apml_tsi_xfer_msg)))
+ return -EFAULT;
+ }
+ return ret;
+}
+
+static int sbtsi_open(struct inode *inode, struct file *fp)
+{
+ struct sbtsi_data *data;
+
+ data = container_of(fp->private_data, struct sbtsi_data, sbtsi_misc_dev);
+ if (data->detached)
+ return -ENODEV;
+
+ kref_get(&data->kref);
+
+ return 0;
+}
+
+static int sbtsi_release(struct inode *inode, struct file *fp)
+{
+ struct sbtsi_data *data;
+
+ data = container_of(fp->private_data, struct sbtsi_data, sbtsi_misc_dev);
+ kref_put(&data->kref, sbtsi_data_release);
+ return 0;
+}
+
+static long sbtsi_ioctl(struct file *fp, unsigned int cmd, unsigned long arg)
+{
+ void __user *argp = (void __user *)arg;
+ struct sbtsi_data *data;
+
+ data = container_of(fp->private_data, struct sbtsi_data, sbtsi_misc_dev);
+ switch (cmd) {
+ case SBTSI_IOCTL_REG_XFER_CMD:
+ return apml_tsi_reg_xfer(data, argp);
+ default:
+ return -ENOTTY;
+ }
+}
+
+static const struct file_operations sbtsi_fops = {
+ .owner = THIS_MODULE,
+ .open = sbtsi_open,
+ .release = sbtsi_release,
+ .unlocked_ioctl = sbtsi_ioctl,
+ .compat_ioctl = compat_ptr_ioctl,
+};
+
+int create_misc_tsi_device(struct sbtsi_data *data, struct device *dev)
+{
+ int ret;
+
+ data->sbtsi_misc_dev.name = devm_kasprintf(dev, GFP_KERNEL,
+ "sbtsi-%x", data->dev_addr);
+ if (!data->sbtsi_misc_dev.name)
+ return -ENOMEM;
+ data->sbtsi_misc_dev.minor = MISC_DYNAMIC_MINOR;
+ data->sbtsi_misc_dev.fops = &sbtsi_fops;
+ data->sbtsi_misc_dev.parent = dev;
+ data->sbtsi_misc_dev.nodename = devm_kasprintf(dev, GFP_KERNEL,
+ "sbtsi-%x", data->dev_addr);
+ if (!data->sbtsi_misc_dev.nodename)
+ return -ENOMEM;
+ data->sbtsi_misc_dev.mode = 0600;
+
+ ret = misc_register(&data->sbtsi_misc_dev);
+ if (ret)
+ return ret;
+
+ return 0;
+}
diff --git a/drivers/misc/amd-sbi/tsi-core.h b/drivers/misc/amd-sbi/tsi-core.h
index 7dde040caf30..c0849c704c7b 100644
--- a/drivers/misc/amd-sbi/tsi-core.h
+++ b/drivers/misc/amd-sbi/tsi-core.h
@@ -20,4 +20,7 @@ struct sbtsi_i3c_priv {
u8 buf[2];
};
+int create_misc_tsi_device(struct sbtsi_data *data, struct device *dev);
+
+void sbtsi_data_release(struct kref *kref);
#endif /* _LINUX_TSI_CORE_H_ */
diff --git a/drivers/misc/amd-sbi/tsi.c b/drivers/misc/amd-sbi/tsi.c
index 8fb17ccab73d..6649cd8cdf85 100644
--- a/drivers/misc/amd-sbi/tsi.c
+++ b/drivers/misc/amd-sbi/tsi.c
@@ -42,6 +42,21 @@ static void sbtsi_unregister_hwmon_adev(void *_adev)
auxiliary_device_uninit(adev);
}
+static void sbtsi_misc_unregister(void *arg)
+{
+ struct sbtsi_data *data = arg;
+
+ misc_deregister(&data->sbtsi_misc_dev);
+ data->detached = true;
+}
+
+static void sbtsi_driver_unref(void *arg)
+{
+ struct sbtsi_data *data = arg;
+
+ kref_put(&data->kref, sbtsi_data_release);
+}
+
/*
* Create and publish an auxiliary device. The hwmon driver in
* drivers/hwmon/sbtsi_temp.c binds to this device.
@@ -89,6 +104,13 @@ static int sbtsi_probe_common(struct device *dev, struct sbtsi_data *data)
u8 val;
int err;
+ mutex_init(&data->lock);
+ kref_init(&data->kref);
+
+ err = devm_add_action_or_reset(dev, sbtsi_driver_unref, data);
+ if (err)
+ return err;
+
err = sbtsi_xfer(data, SBTSI_REG_CONFIG, &val, true);
if (err)
return err;
@@ -97,7 +119,15 @@ static int sbtsi_probe_common(struct device *dev, struct sbtsi_data *data)
data->read_order = FIELD_GET(BIT(SBTSI_CONFIG_READ_ORDER_SHIFT), val);
dev_set_drvdata(dev, data);
- return sbtsi_create_hwmon_adev(dev, data->dev_addr);
+ err = sbtsi_create_hwmon_adev(dev, data->dev_addr);
+ if (err < 0)
+ return err;
+
+ err = create_misc_tsi_device(data, dev);
+ if (err)
+ return err;
+
+ return devm_add_action(dev, sbtsi_misc_unregister, data);
}
static int sbtsi_i2c_probe(struct i2c_client *client)
@@ -105,7 +135,7 @@ static int sbtsi_i2c_probe(struct i2c_client *client)
struct device *dev = &client->dev;
struct sbtsi_data *data;
- data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
+ data = kzalloc_obj(*data);
if (!data)
return -ENOMEM;
@@ -157,7 +187,7 @@ static int sbtsi_i3c_probe(struct i3c_device *i3cdev)
if (I3C_PID_INSTANCE_ID(devinfo.pid) != 0)
return -ENXIO;
- i3c_priv = devm_kzalloc(dev, sizeof(*i3c_priv), GFP_KERNEL);
+ i3c_priv = kzalloc_obj(*i3c_priv);
if (!i3c_priv)
return -ENOMEM;
diff --git a/include/linux/misc/tsi.h b/include/linux/misc/tsi.h
index 02c90ec285ec..3ce3770d1ad5 100644
--- a/include/linux/misc/tsi.h
+++ b/include/linux/misc/tsi.h
@@ -8,30 +8,45 @@
#ifndef _LINUX_MISC_TSI_H_
#define _LINUX_MISC_TSI_H_
+#include <linux/cleanup.h>
#include <linux/i2c.h>
#include <linux/i3c/device.h>
+#include <linux/kref.h>
+#include <linux/miscdevice.h>
+#include <linux/mutex.h>
#include <linux/types.h>
/**
* struct sbtsi_data - driver private data for an AMD SB-TSI device
* @client: underlying I2C client
* @i3cdev: underlying I3C device (when using I3C bus)
+ * @sbtsi_misc_dev: miscdevice exposing ioctl interface at /dev/sbtsi-<addr>
+ * @lock: mutex protecting concurrent access to the device
+ * @kref: reference count; keeps @sbtsi_data alive while misc fds are open
* @dev_addr: I2C/I3C device address, used to name the misc device node
* @ext_range_mode: sensor uses extended temperature range
* @read_order: if set, decimal part must be read before integer part
* @is_i3c: true when the device is accessed over I3C
+ * @detached: set on driver unbind; open/ioctl return -ENODEV afterward
*/
struct sbtsi_data {
union {
struct i2c_client *client;
struct i3c_device *i3cdev;
};
+ struct miscdevice sbtsi_misc_dev;
+ struct mutex lock; /* protects concurrent access to the device */
+ struct kref kref;
u8 dev_addr;
bool ext_range_mode;
bool read_order;
bool is_i3c;
+ bool detached;
};
+DEFINE_GUARD(sbtsi, struct sbtsi_data *, mutex_lock(&_T->lock),
+ mutex_unlock(&_T->lock))
+
/*
* Name of the auxiliary device published on the auxiliary bus by the core
* driver. The full device name is "amd-sbtsi.temp-sensor.<id>". where
diff --git a/include/uapi/misc/amd-apml.h b/include/uapi/misc/amd-apml.h
index 745b3338fc06..8a85f79b0938 100644
--- a/include/uapi/misc/amd-apml.h
+++ b/include/uapi/misc/amd-apml.h
@@ -73,6 +73,13 @@ struct apml_reg_xfer_msg {
__u8 rflag;
};
+struct apml_tsi_xfer_msg {
+ __u8 reg_addr; /* TSI register address offset */
+ __u8 data_in_out; /* Register data for read/write */
+ __u8 rflag; /* Register read or write */
+ __u8 pad; /* Explicit padding */
+};
+
/*
* AMD sideband interface base IOCTL
*/
@@ -149,4 +156,20 @@ struct apml_reg_xfer_msg {
*/
#define SBRMI_IOCTL_REG_XFER_CMD _IOWR(SB_BASE_IOCTL_NR, 3, struct apml_reg_xfer_msg)
+/**
+ * DOC: SBTSI_IOCTL_REG_XFER_CMD
+ *
+ * @Parameters
+ *
+ * @struct apml_tsi_xfer_msg
+ * Pointer to the &struct apml_tsi_xfer_msg that will contain the protocol
+ * information
+ *
+ * @Description
+ * IOCTL command for APML TSI messages using generic _IOWR
+ * The IOCTL provides userspace access to AMD sideband TSI register xfer protocol
+ * - TSI protocol to read/write temperature sensor registers
+ */
+#define SBTSI_IOCTL_REG_XFER_CMD _IOWR(SB_BASE_IOCTL_NR, 4, struct apml_tsi_xfer_msg)
+
#endif /*_AMD_APML_H_*/
--
2.34.1
^ permalink raw reply related
* [PATCH v3 4/8] misc: amd-sbi: Consolidate Common SBTSI Probe Path for I2C and I3C
From: Akshay Gupta @ 2026-06-22 13:58 UTC (permalink / raw)
To: linux-doc, linux-kernel, linux-hwmon
Cc: corbet, skhan, linux, arnd, gregkh, NaveenKrishna.Chatradhi,
Anand.Umarji, Akshay.Gupta, Prathima.Lk
In-Reply-To: <20260622135821.2190260-1-Akshay.Gupta@amd.com>
From: Prathima <Prathima.Lk@amd.com>
Refactor shared probe procedures into sbtsi_probe_common() to ensure
that I2C and I3C probes focus solely on bus-specific allocation and
device configuration.
The utility function reads the configuration register via sbtsi_xfer(),
initializes ext_range_mode and read_order, assigns the driver data,
and registers the hwmon auxiliary device.
Utilizing sbtsi_xfer() for both buses eliminates the need to duplicate
the I2C SMBus and I3C transfer paths within tsi.c.
Reviewed-by: Akshay Gupta <Akshay.Gupta@amd.com>
Signed-off-by: Prathima <Prathima.Lk@amd.com>
---
Changes since v2:
- New patch to refactor SBTSI common probe
drivers/misc/amd-sbi/tsi.c | 26 ++++++++++++++++++--------
include/linux/misc/tsi.h | 2 ++
2 files changed, 20 insertions(+), 8 deletions(-)
diff --git a/drivers/misc/amd-sbi/tsi.c b/drivers/misc/amd-sbi/tsi.c
index dfdd730b906a..a4c7e1be5624 100644
--- a/drivers/misc/amd-sbi/tsi.c
+++ b/drivers/misc/amd-sbi/tsi.c
@@ -84,25 +84,35 @@ static int sbtsi_create_hwmon_adev(struct device *dev, u8 dev_addr)
return devm_add_action_or_reset(dev, sbtsi_unregister_hwmon_adev, adev);
}
+static int sbtsi_probe_common(struct device *dev, struct sbtsi_data *data)
+{
+ u8 val;
+ int err;
+
+ err = sbtsi_xfer(data, SBTSI_REG_CONFIG, &val, true);
+ if (err)
+ return err;
+
+ data->ext_range_mode = FIELD_GET(BIT(SBTSI_CONFIG_EXT_RANGE_SHIFT), val);
+ data->read_order = FIELD_GET(BIT(SBTSI_CONFIG_READ_ORDER_SHIFT), val);
+
+ dev_set_drvdata(dev, data);
+ return sbtsi_create_hwmon_adev(dev, data->dev_addr);
+}
+
static int sbtsi_i2c_probe(struct i2c_client *client)
{
struct device *dev = &client->dev;
struct sbtsi_data *data;
- int err;
data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
if (!data)
return -ENOMEM;
data->client = client;
- err = i2c_smbus_read_byte_data(data->client, SBTSI_REG_CONFIG);
- if (err < 0)
- return err;
- data->ext_range_mode = FIELD_GET(BIT(SBTSI_CONFIG_EXT_RANGE_SHIFT), err);
- data->read_order = FIELD_GET(BIT(SBTSI_CONFIG_READ_ORDER_SHIFT), err);
+ data->dev_addr = client->addr;
- dev_set_drvdata(dev, data);
- return sbtsi_create_hwmon_adev(dev, client->addr);
+ return sbtsi_probe_common(dev, data);
}
static const struct i2c_device_id sbtsi_id[] = {
diff --git a/include/linux/misc/tsi.h b/include/linux/misc/tsi.h
index 2d2709f1ff32..55ee7e42a65d 100644
--- a/include/linux/misc/tsi.h
+++ b/include/linux/misc/tsi.h
@@ -14,11 +14,13 @@
/**
* struct sbtsi_data - driver private data for an AMD SB-TSI device
* @client: underlying I2C client
+ * @dev_addr: I2C device address, used to name the misc device node
* @ext_range_mode: sensor uses extended temperature range
* @read_order: if set, decimal part must be read before integer part
*/
struct sbtsi_data {
struct i2c_client *client;
+ u8 dev_addr;
bool ext_range_mode;
bool read_order;
};
--
2.34.1
^ permalink raw reply related
* [PATCH v3 3/8] hwmon/misc: amd-sbi: Move sbtsi register transfer to core abstraction
From: Akshay Gupta @ 2026-06-22 13:58 UTC (permalink / raw)
To: linux-doc, linux-kernel, linux-hwmon
Cc: corbet, skhan, linux, arnd, gregkh, NaveenKrishna.Chatradhi,
Anand.Umarji, Akshay.Gupta, Prathima.Lk
In-Reply-To: <20260622135821.2190260-1-Akshay.Gupta@amd.com>
From: Prathima <Prathima.Lk@amd.com>
Move the I2C read/write byte operations from the sbtsi hwmon driver into
a common sbtsi_xfer() function in tsi-core.c.
This decouples the hwmon sensor driver from the underlying bus transport,
preparing for I3C support in a subsequent patch.
This patch does not introduce any functional changes. The updates are
limited to code organization/cleanup and should not affect the runtime
behavior of the driver
Reviewed-by: Akshay Gupta <Akshay.Gupta@amd.com>
Signed-off-by: Prathima <Prathima.Lk@amd.com>
---
Changes since v2:
- Name change for header inclusion guard to misc specific
Changes since v1:
- New patch
drivers/hwmon/sbtsi_temp.c | 17 ++++++-----------
drivers/misc/amd-sbi/Makefile | 2 +-
drivers/misc/amd-sbi/tsi-core.c | 30 ++++++++++++++++++++++++++++++
include/linux/misc/tsi.h | 13 +++++++++++++
4 files changed, 50 insertions(+), 12 deletions(-)
create mode 100644 drivers/misc/amd-sbi/tsi-core.c
diff --git a/drivers/hwmon/sbtsi_temp.c b/drivers/hwmon/sbtsi_temp.c
index 078f4ab25bde..d7ae986d824c 100644
--- a/drivers/hwmon/sbtsi_temp.c
+++ b/drivers/hwmon/sbtsi_temp.c
@@ -70,15 +70,10 @@ static int sbtsi_temp_read(struct sbtsi_data *data, u8 reg1, u8 reg2,
{
int ret;
- ret = i2c_smbus_read_byte_data(data->client, reg1);
- if (ret < 0)
- return ret;
- *val1 = ret;
- ret = i2c_smbus_read_byte_data(data->client, reg2);
- if (ret < 0)
- return ret;
- *val2 = ret;
- return 0;
+ ret = sbtsi_xfer(data, reg1, val1, true);
+ if (!ret)
+ ret = sbtsi_xfer(data, reg2, val2, true);
+ return ret;
}
/*
@@ -89,9 +84,9 @@ static int sbtsi_temp_write(struct sbtsi_data *data, u8 reg_int, u8 reg_dec,
{
int ret;
- ret = i2c_smbus_write_byte_data(data->client, reg_int, val_int);
+ ret = sbtsi_xfer(data, reg_int, &val_int, false);
if (!ret)
- ret = i2c_smbus_write_byte_data(data->client, reg_dec, val_dec);
+ ret = sbtsi_xfer(data, reg_dec, &val_dec, false);
return ret;
}
diff --git a/drivers/misc/amd-sbi/Makefile b/drivers/misc/amd-sbi/Makefile
index 28f95b9e204f..ce9321f5c601 100644
--- a/drivers/misc/amd-sbi/Makefile
+++ b/drivers/misc/amd-sbi/Makefile
@@ -3,5 +3,5 @@ sbrmi-i2c-objs += rmi-i2c.o rmi-core.o
sbrmi-i2c-$(CONFIG_AMD_SBRMI_HWMON) += rmi-hwmon.o
obj-$(CONFIG_AMD_SBRMI_I2C) += sbrmi-i2c.o
# SBTSI Configuration
-sbtsi-objs += tsi.o
+sbtsi-objs += tsi.o tsi-core.o
obj-$(CONFIG_AMD_SBTSI) += sbtsi.o
diff --git a/drivers/misc/amd-sbi/tsi-core.c b/drivers/misc/amd-sbi/tsi-core.c
new file mode 100644
index 000000000000..6ef1831515bb
--- /dev/null
+++ b/drivers/misc/amd-sbi/tsi-core.c
@@ -0,0 +1,30 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * tsi-core.c - file defining SB-TSI protocols compliant
+ * AMD SoC device.
+ *
+ * Copyright (C) 2026 Advanced Micro Devices, Inc.
+ */
+
+#include <linux/module.h>
+#include <linux/misc/tsi.h>
+
+/* I2C transfer function */
+static int sbtsi_i2c_xfer(struct sbtsi_data *data, u8 reg, u8 *val, bool is_read)
+{
+ if (is_read) {
+ int ret = i2c_smbus_read_byte_data(data->client, reg);
+
+ if (ret < 0)
+ return ret;
+ *val = ret;
+ return 0;
+ }
+ return i2c_smbus_write_byte_data(data->client, reg, *val);
+}
+
+int sbtsi_xfer(struct sbtsi_data *data, u8 reg, u8 *val, bool is_read)
+{
+ return sbtsi_i2c_xfer(data, reg, val, is_read);
+}
+EXPORT_SYMBOL_GPL(sbtsi_xfer);
diff --git a/include/linux/misc/tsi.h b/include/linux/misc/tsi.h
index befdc2d14160..2d2709f1ff32 100644
--- a/include/linux/misc/tsi.h
+++ b/include/linux/misc/tsi.h
@@ -31,4 +31,17 @@ struct sbtsi_data {
#define AMD_SBTSI_ADEV "amd-sbtsi"
#define AMD_SBTSI_AUX_HWMON "temp-sensor"
+/**
+ * sbtsi_xfer - Perform a register read or write transfer on an AMD SB-TSI device.
+ *
+ * @data: Pointer to the sbtsi_data structure containing the device context
+ * @reg: Register address to access.
+ * @val: Pointer to the value to read into or write from.
+ * @is_read: If true, performs a read transfer and stores the result in @val.
+ * If false, performs a write transfer using the value in @val.
+ *
+ * Returns 0 on success, or a negative error code on failure.
+ */
+int sbtsi_xfer(struct sbtsi_data *data, u8 reg, u8 *val, bool is_read);
+
#endif /* _LINUX_MISC_TSI_H_ */
--
2.34.1
^ permalink raw reply related
* [PATCH v3 2/8] hwmon: sbtsi_temp: Refactor temperature register access into helpers
From: Akshay Gupta @ 2026-06-22 13:58 UTC (permalink / raw)
To: linux-doc, linux-kernel, linux-hwmon
Cc: corbet, skhan, linux, arnd, gregkh, NaveenKrishna.Chatradhi,
Anand.Umarji, Akshay.Gupta, Prathima.Lk
In-Reply-To: <20260622135821.2190260-1-Akshay.Gupta@amd.com>
From: Prathima <Prathima.Lk@amd.com>
Extract the paired integer/decimal register reads and writes from the
hwmon read/write callbacks into sbtsi_temp_read() and sbtsi_temp_write()
helpers. This consolidates error handling and respects the ReadOrder bit
for atomic temperature latching.
This keeps register access independent while preserving existing hwmon
functionality.
Reviewed-by: Akshay Gupta <Akshay.Gupta@amd.com>
Signed-off-by: Prathima <Prathima.Lk@amd.com>
---
Changes since v1:
- New patch
drivers/hwmon/sbtsi_temp.c | 84 +++++++++++++++++++++++++++-----------
1 file changed, 61 insertions(+), 23 deletions(-)
diff --git a/drivers/hwmon/sbtsi_temp.c b/drivers/hwmon/sbtsi_temp.c
index 28258bf49922..078f4ab25bde 100644
--- a/drivers/hwmon/sbtsi_temp.c
+++ b/drivers/hwmon/sbtsi_temp.c
@@ -61,40 +61,82 @@ static inline void sbtsi_mc_to_reg(s32 temp, u8 *integer, u8 *decimal)
*decimal = (temp & 0x7) << 5;
}
+/*
+ * Read integer and decimal parts of an SB-TSI temperature register pair
+ * The read order is determined by the ReadOrder bit to ensure atomic latching.
+ */
+static int sbtsi_temp_read(struct sbtsi_data *data, u8 reg1, u8 reg2,
+ u8 *val1, u8 *val2)
+{
+ int ret;
+
+ ret = i2c_smbus_read_byte_data(data->client, reg1);
+ if (ret < 0)
+ return ret;
+ *val1 = ret;
+ ret = i2c_smbus_read_byte_data(data->client, reg2);
+ if (ret < 0)
+ return ret;
+ *val2 = ret;
+ return 0;
+}
+
+/*
+ * Write integer and decimal parts of an SB-TSI temperature register pair.
+ */
+static int sbtsi_temp_write(struct sbtsi_data *data, u8 reg_int, u8 reg_dec,
+ u8 val_int, u8 val_dec)
+{
+ int ret;
+
+ ret = i2c_smbus_write_byte_data(data->client, reg_int, val_int);
+ if (!ret)
+ ret = i2c_smbus_write_byte_data(data->client, reg_dec, val_dec);
+ return ret;
+}
+
static int sbtsi_read(struct device *dev, enum hwmon_sensor_types type,
u32 attr, int channel, long *val)
{
struct sbtsi_data *data = dev_get_drvdata(dev);
s32 temp_int, temp_dec;
+ int err;
+ u8 val_int, val_dec;
switch (attr) {
case hwmon_temp_input:
- if (data->read_order) {
- temp_dec = i2c_smbus_read_byte_data(data->client, SBTSI_REG_TEMP_DEC);
- temp_int = i2c_smbus_read_byte_data(data->client, SBTSI_REG_TEMP_INT);
- } else {
- temp_int = i2c_smbus_read_byte_data(data->client, SBTSI_REG_TEMP_INT);
- temp_dec = i2c_smbus_read_byte_data(data->client, SBTSI_REG_TEMP_DEC);
- }
+ if (data->read_order)
+ err = sbtsi_temp_read(data,
+ SBTSI_REG_TEMP_DEC, SBTSI_REG_TEMP_INT,
+ &val_dec, &val_int);
+ else
+ err = sbtsi_temp_read(data,
+ SBTSI_REG_TEMP_INT, SBTSI_REG_TEMP_DEC,
+ &val_int, &val_dec);
+ if (err < 0)
+ return err;
break;
case hwmon_temp_max:
- temp_int = i2c_smbus_read_byte_data(data->client, SBTSI_REG_TEMP_HIGH_INT);
- temp_dec = i2c_smbus_read_byte_data(data->client, SBTSI_REG_TEMP_HIGH_DEC);
+ err = sbtsi_temp_read(data,
+ SBTSI_REG_TEMP_HIGH_INT, SBTSI_REG_TEMP_HIGH_DEC,
+ &val_int, &val_dec);
+ if (err < 0)
+ return err;
break;
case hwmon_temp_min:
- temp_int = i2c_smbus_read_byte_data(data->client, SBTSI_REG_TEMP_LOW_INT);
- temp_dec = i2c_smbus_read_byte_data(data->client, SBTSI_REG_TEMP_LOW_DEC);
+ err = sbtsi_temp_read(data,
+ SBTSI_REG_TEMP_LOW_INT, SBTSI_REG_TEMP_LOW_DEC,
+ &val_int, &val_dec);
+
+ if (err < 0)
+ return err;
break;
default:
return -EINVAL;
}
-
- if (temp_int < 0)
- return temp_int;
- if (temp_dec < 0)
- return temp_dec;
-
+ temp_int = val_int;
+ temp_dec = val_dec;
*val = sbtsi_reg_to_mc(temp_int, temp_dec);
if (data->ext_range_mode)
*val -= SBTSI_TEMP_EXT_RANGE_ADJ;
@@ -106,7 +148,7 @@ static int sbtsi_write(struct device *dev, enum hwmon_sensor_types type,
u32 attr, int channel, long val)
{
struct sbtsi_data *data = dev_get_drvdata(dev);
- int reg_int, reg_dec, err;
+ int reg_int, reg_dec;
u8 temp_int, temp_dec;
switch (attr) {
@@ -127,11 +169,7 @@ static int sbtsi_write(struct device *dev, enum hwmon_sensor_types type,
val = clamp_val(val, SBTSI_TEMP_MIN, SBTSI_TEMP_MAX);
sbtsi_mc_to_reg(val, &temp_int, &temp_dec);
- err = i2c_smbus_write_byte_data(data->client, reg_int, temp_int);
- if (err)
- return err;
-
- return i2c_smbus_write_byte_data(data->client, reg_dec, temp_dec);
+ return sbtsi_temp_write(data, reg_int, reg_dec, temp_int, temp_dec);
}
static umode_t sbtsi_is_visible(const void *data,
--
2.34.1
^ permalink raw reply related
* [PATCH v3 1/8] hwmon/misc: amd-sbi: Move core sbtsi support from hwmon to misc
From: Akshay Gupta @ 2026-06-22 13:58 UTC (permalink / raw)
To: linux-doc, linux-kernel, linux-hwmon
Cc: corbet, skhan, linux, arnd, gregkh, NaveenKrishna.Chatradhi,
Anand.Umarji, Akshay.Gupta, Prathima.Lk
In-Reply-To: <20260622135821.2190260-1-Akshay.Gupta@amd.com>
From: Prathima <Prathima.Lk@amd.com>
Move SBTSI(Side-Band Temperature Sensor Interface) core functionality out
of the hwmon-only path and into drivers/misc/amd-sbi so it can be reused
by non-hwmon consumers.
I2C probe parsing is moved from drivers/hwmon/sbtsi_temp.c
into drivers/misc/amd-sbi/tsi.c under CONFIG_AMD_SBTSI. The core driver
stores struct sbtsi_data on the bus device and registers an auxiliary
device amd-sbtsi.temp-sensor.<addr> per target.
This split prepares the driver for additional interfaces while keeping
hwmon support in hwmon subsystem on top of common SBTSI core logic.
Reviewed-by: Akshay Gupta <Akshay.Gupta@amd.com>
Signed-off-by: Prathima <Prathima.Lk@amd.com>
---
Changes since v2:
- Change hwmon config symbol dependency, "depends on" to "select"
as "depends on" could silently disable the hwmon driver
Changes since v1:
- Use auxiliary device to probe hwmon sensor instead of moving
the hwmon functionality to misc subsystem. This change is as
per feedback.
drivers/hwmon/Kconfig | 2 +-
drivers/hwmon/sbtsi_temp.c | 71 ++++--------------
drivers/misc/amd-sbi/Kconfig | 13 ++++
drivers/misc/amd-sbi/Makefile | 3 +
drivers/misc/amd-sbi/tsi.c | 134 ++++++++++++++++++++++++++++++++++
include/linux/misc/tsi.h | 34 +++++++++
6 files changed, 198 insertions(+), 59 deletions(-)
create mode 100644 drivers/misc/amd-sbi/tsi.c
create mode 100644 include/linux/misc/tsi.h
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index e4c4f2b09732..8f204cf49b6e 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1963,7 +1963,7 @@ config SENSORS_SL28CPLD
config SENSORS_SBTSI
tristate "Emulated SB-TSI temperature sensor"
- depends on I2C
+ select AMD_SBTSI
help
If you say yes here you get support for emulated temperature
sensors on AMD SoCs with SB-TSI interface connected to a BMC device.
diff --git a/drivers/hwmon/sbtsi_temp.c b/drivers/hwmon/sbtsi_temp.c
index c28f8625cd3a..28258bf49922 100644
--- a/drivers/hwmon/sbtsi_temp.c
+++ b/drivers/hwmon/sbtsi_temp.c
@@ -7,13 +7,12 @@
* Copyright (c) 2020, Kun Yi <kunyi@google.com>
*/
+#include <linux/auxiliary_bus.h>
#include <linux/err.h>
-#include <linux/i2c.h>
-#include <linux/init.h>
#include <linux/hwmon.h>
+#include <linux/init.h>
#include <linux/module.h>
-#include <linux/of.h>
-#include <linux/bitfield.h>
+#include <linux/misc/tsi.h>
/*
* SB-TSI registers only support SMBus byte data access. "_INT" registers are
@@ -22,39 +21,17 @@
*/
#define SBTSI_REG_TEMP_INT 0x01 /* RO */
#define SBTSI_REG_STATUS 0x02 /* RO */
-#define SBTSI_REG_CONFIG 0x03 /* RO */
#define SBTSI_REG_TEMP_HIGH_INT 0x07 /* RW */
#define SBTSI_REG_TEMP_LOW_INT 0x08 /* RW */
#define SBTSI_REG_TEMP_DEC 0x10 /* RW */
#define SBTSI_REG_TEMP_HIGH_DEC 0x13 /* RW */
#define SBTSI_REG_TEMP_LOW_DEC 0x14 /* RW */
-/*
- * Bit for reporting value with temperature measurement range.
- * bit == 0: Use default temperature range (0C to 255.875C).
- * bit == 1: Use extended temperature range (-49C to +206.875C).
- */
-#define SBTSI_CONFIG_EXT_RANGE_SHIFT 2
-/*
- * ReadOrder bit specifies the reading order of integer and decimal part of
- * CPU temperature for atomic reads. If bit == 0, reading integer part triggers
- * latching of the decimal part, so integer part should be read first.
- * If bit == 1, read order should be reversed.
- */
-#define SBTSI_CONFIG_READ_ORDER_SHIFT 5
-
#define SBTSI_TEMP_EXT_RANGE_ADJ 49000
#define SBTSI_TEMP_MIN 0
#define SBTSI_TEMP_MAX 255875
-/* Each client has this additional data */
-struct sbtsi_data {
- struct i2c_client *client;
- bool ext_range_mode;
- bool read_order;
-};
-
/*
* From SB-TSI spec: CPU temperature readings and limit registers encode the
* temperature in increments of 0.125 from 0 to 255.875. The "high byte"
@@ -195,55 +172,33 @@ static const struct hwmon_chip_info sbtsi_chip_info = {
.info = sbtsi_info,
};
-static int sbtsi_probe(struct i2c_client *client)
+static int sbtsi_probe(struct auxiliary_device *adev,
+ const struct auxiliary_device_id *id)
{
- struct device *dev = &client->dev;
+ struct sbtsi_data *data = dev_get_drvdata(adev->dev.parent);
+ struct device *dev = &adev->dev;
struct device *hwmon_dev;
- struct sbtsi_data *data;
- int err;
- data = devm_kzalloc(dev, sizeof(struct sbtsi_data), GFP_KERNEL);
- if (!data)
- return -ENOMEM;
-
- data->client = client;
-
- err = i2c_smbus_read_byte_data(data->client, SBTSI_REG_CONFIG);
- if (err < 0)
- return err;
- data->ext_range_mode = FIELD_GET(BIT(SBTSI_CONFIG_EXT_RANGE_SHIFT), err);
- data->read_order = FIELD_GET(BIT(SBTSI_CONFIG_READ_ORDER_SHIFT), err);
-
- hwmon_dev = devm_hwmon_device_register_with_info(dev, client->name, data,
+ hwmon_dev = devm_hwmon_device_register_with_info(dev, "sbtsi", data,
&sbtsi_chip_info, NULL);
return PTR_ERR_OR_ZERO(hwmon_dev);
}
-static const struct i2c_device_id sbtsi_id[] = {
- { .name = "sbtsi" },
+static const struct auxiliary_device_id sbtsi_id[] = {
+ { .name = AMD_SBTSI_ADEV "." AMD_SBTSI_AUX_HWMON },
{ }
};
-MODULE_DEVICE_TABLE(i2c, sbtsi_id);
+MODULE_DEVICE_TABLE(auxiliary, sbtsi_id);
-static const struct of_device_id __maybe_unused sbtsi_of_match[] = {
- {
- .compatible = "amd,sbtsi",
- },
- { },
-};
-MODULE_DEVICE_TABLE(of, sbtsi_of_match);
-
-static struct i2c_driver sbtsi_driver = {
+static struct auxiliary_driver sbtsi_driver = {
.driver = {
.name = "sbtsi",
- .of_match_table = of_match_ptr(sbtsi_of_match),
},
.probe = sbtsi_probe,
.id_table = sbtsi_id,
};
-
-module_i2c_driver(sbtsi_driver);
+module_auxiliary_driver(sbtsi_driver);
MODULE_AUTHOR("Kun Yi <kunyi@google.com>");
MODULE_DESCRIPTION("Hwmon driver for AMD SB-TSI emulated sensor");
diff --git a/drivers/misc/amd-sbi/Kconfig b/drivers/misc/amd-sbi/Kconfig
index 30e7fad7356c..512251690e0e 100644
--- a/drivers/misc/amd-sbi/Kconfig
+++ b/drivers/misc/amd-sbi/Kconfig
@@ -20,3 +20,16 @@ config AMD_SBRMI_HWMON
This provides support for RMI device hardware monitoring. If enabled,
a hardware monitoring device will be created for each socket in
the system.
+
+config AMD_SBTSI
+ tristate "AMD side band TSI support"
+ depends on I2C
+ depends on ARM || ARM64 || COMPILE_TEST
+ select AUXILIARY_BUS
+ help
+ Enables support for the AMD SB-TSI (Side Band Temperature Sensor
+ Interface) driver, which provides access to emulated CPU temperature
+ sensors on AMD SoCs via an I2C connected BMC device.
+
+ This driver can also be built as a module. If so, the module will
+ be called sbtsi.
diff --git a/drivers/misc/amd-sbi/Makefile b/drivers/misc/amd-sbi/Makefile
index 38eaaa651fd9..28f95b9e204f 100644
--- a/drivers/misc/amd-sbi/Makefile
+++ b/drivers/misc/amd-sbi/Makefile
@@ -2,3 +2,6 @@
sbrmi-i2c-objs += rmi-i2c.o rmi-core.o
sbrmi-i2c-$(CONFIG_AMD_SBRMI_HWMON) += rmi-hwmon.o
obj-$(CONFIG_AMD_SBRMI_I2C) += sbrmi-i2c.o
+# SBTSI Configuration
+sbtsi-objs += tsi.o
+obj-$(CONFIG_AMD_SBTSI) += sbtsi.o
diff --git a/drivers/misc/amd-sbi/tsi.c b/drivers/misc/amd-sbi/tsi.c
new file mode 100644
index 000000000000..dfdd730b906a
--- /dev/null
+++ b/drivers/misc/amd-sbi/tsi.c
@@ -0,0 +1,134 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * tsi.c - AMD SBTSI I2C core driver. Probes the SBTSI device over I2C
+ * and publishes an auxiliary device on the auxiliary bus.
+ *
+ * Copyright (C) 2026 Advanced Micro Devices, Inc.
+ */
+
+#include <linux/auxiliary_bus.h>
+#include <linux/bitfield.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/misc/tsi.h>
+#include <linux/slab.h>
+
+#define SBTSI_REG_CONFIG 0x03 /* RO */
+
+/*
+ * Bit for reporting value with temperature measurement range.
+ * bit == 0: Use default temperature range (0C to 255.875C).
+ * bit == 1: Use extended temperature range (-49C to +206.875C).
+ */
+#define SBTSI_CONFIG_EXT_RANGE_SHIFT 2
+
+/*
+ * ReadOrder bit specifies the reading order of integer and decimal part of
+ * CPU temperature for atomic reads. If bit == 0, reading integer part triggers
+ * latching of the decimal part, so integer part should be read first.
+ */
+#define SBTSI_CONFIG_READ_ORDER_SHIFT 5
+
+static void sbtsi_adev_release(struct device *dev)
+{
+ kfree(to_auxiliary_dev(dev));
+}
+
+static void sbtsi_unregister_hwmon_adev(void *_adev)
+{
+ struct auxiliary_device *adev = _adev;
+
+ auxiliary_device_delete(adev);
+ auxiliary_device_uninit(adev);
+}
+
+/*
+ * Create and publish an auxiliary device. The hwmon driver in
+ * drivers/hwmon/sbtsi_temp.c binds to this device.
+ *
+ * @dev: I2C device (parent of the auxiliary device)
+ * @dev_addr: I2C address — used as the auxiliary device instance ID so that
+ * each socket gets a unique name.
+ */
+static int sbtsi_create_hwmon_adev(struct device *dev, u8 dev_addr)
+{
+ struct auxiliary_device *adev;
+ int ret;
+
+ adev = kzalloc_obj(*adev);
+ if (!adev)
+ return -ENOMEM;
+
+ adev->name = AMD_SBTSI_AUX_HWMON;
+ /*
+ * In a multi-socket system, otherwise identical devices do not
+ * share the same static address; each instance has its own address,
+ * which must be supplied via the device tree (DTS).
+ */
+ adev->id = dev_addr;
+ adev->dev.parent = dev;
+ adev->dev.release = sbtsi_adev_release;
+
+ ret = auxiliary_device_init(adev);
+ if (ret) {
+ kfree(adev);
+ return ret;
+ }
+
+ ret = __auxiliary_device_add(adev, AMD_SBTSI_ADEV);
+ if (ret) {
+ auxiliary_device_uninit(adev);
+ return ret;
+ }
+
+ return devm_add_action_or_reset(dev, sbtsi_unregister_hwmon_adev, adev);
+}
+
+static int sbtsi_i2c_probe(struct i2c_client *client)
+{
+ struct device *dev = &client->dev;
+ struct sbtsi_data *data;
+ int err;
+
+ data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ data->client = client;
+ err = i2c_smbus_read_byte_data(data->client, SBTSI_REG_CONFIG);
+ if (err < 0)
+ return err;
+ data->ext_range_mode = FIELD_GET(BIT(SBTSI_CONFIG_EXT_RANGE_SHIFT), err);
+ data->read_order = FIELD_GET(BIT(SBTSI_CONFIG_READ_ORDER_SHIFT), err);
+
+ dev_set_drvdata(dev, data);
+ return sbtsi_create_hwmon_adev(dev, client->addr);
+}
+
+static const struct i2c_device_id sbtsi_id[] = {
+ { .name = "sbtsi" },
+ { }
+};
+MODULE_DEVICE_TABLE(i2c, sbtsi_id);
+
+static const struct of_device_id __maybe_unused sbtsi_of_match[] = {
+ {
+ .compatible = "amd,sbtsi",
+ },
+ { },
+};
+MODULE_DEVICE_TABLE(of, sbtsi_of_match);
+
+static struct i2c_driver sbtsi_driver = {
+ .driver = {
+ .name = "sbtsi-i2c",
+ .of_match_table = of_match_ptr(sbtsi_of_match),
+ },
+ .probe = sbtsi_i2c_probe,
+ .id_table = sbtsi_id,
+};
+
+module_i2c_driver(sbtsi_driver);
+
+MODULE_DESCRIPTION("AMD SB-TSI I2C core driver");
+MODULE_LICENSE("GPL");
diff --git a/include/linux/misc/tsi.h b/include/linux/misc/tsi.h
new file mode 100644
index 000000000000..befdc2d14160
--- /dev/null
+++ b/include/linux/misc/tsi.h
@@ -0,0 +1,34 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * AMD SBTSI shared data structure and auxiliary bus definitions.
+ *
+ * Copyright (C) 2026 Advanced Micro Devices, Inc.
+ */
+
+#ifndef _LINUX_MISC_TSI_H_
+#define _LINUX_MISC_TSI_H_
+
+#include <linux/i2c.h>
+#include <linux/types.h>
+
+/**
+ * struct sbtsi_data - driver private data for an AMD SB-TSI device
+ * @client: underlying I2C client
+ * @ext_range_mode: sensor uses extended temperature range
+ * @read_order: if set, decimal part must be read before integer part
+ */
+struct sbtsi_data {
+ struct i2c_client *client;
+ bool ext_range_mode;
+ bool read_order;
+};
+
+/*
+ * Name of the auxiliary device published on the auxiliary bus by the core
+ * driver. The full device name is "amd-sbtsi.temp-sensor.<id>". where
+ * <id> is the auxiliary device instance id.
+ */
+#define AMD_SBTSI_ADEV "amd-sbtsi"
+#define AMD_SBTSI_AUX_HWMON "temp-sensor"
+
+#endif /* _LINUX_MISC_TSI_H_ */
--
2.34.1
^ permalink raw reply related
* [PATCH v3 0/8] misc: amd-sbi: Refactor SBTSI driver with I3C support and ioctl interface
From: Akshay Gupta @ 2026-06-22 13:58 UTC (permalink / raw)
To: linux-doc, linux-kernel, linux-hwmon
Cc: corbet, skhan, linux, arnd, gregkh, NaveenKrishna.Chatradhi,
Anand.Umarji, Akshay.Gupta, Prathima.Lk
This series refactors the AMD SB-TSI (Side-Band Temperature Sensor
Interface) driver by moving the core from the hwmon subsystem into the
drivers/misc/amd-sbi framework, alongside the existing SB-RMI driver.
Registers an auxiliary device keeping hwmon sensors functionality intact.
Background:
The SB-TSI driver currently lives under drivers/hwmon/sbtsi_temp.c and
is limited to exposing temperature readings via the hwmon interface.
As AMD platforms evolve, SB-TSI access is required from multiple
consumers (hwmon, userspace via ioctl, I3C-attached devices), making
the hwmon-only placement insufficient.
This series restructures the driver into a layered design:
- tsi-core.c : core register access and ioctl/miscdevice support
- tsi.c : I2C/I3C probe and glue
- sbtsi_temp.c : hwmon sensor layer built on top of the core using aux device
Changes in this series:
1. Move core SBTSI driver probe from drivers/hwmon into drivers/misc/amd-sbi,
and registering an auxiliary device in core for hwmon subsystem probing
2. Register order follows the device ReadOrder bit so both parts latch atomically;
limit registers (temp / temp1_max / temp1_min) use the same helpers instead of
separate SMBus calls.
3. Move sbtsi register transfer to core abstraction to decouple the hwmon sensor
driver from the underlying bus transport. Preparing for I3C support in a
subsequent patch
4. Refactor I2C probe common functionality to new common helper function to prepare
for I3C support
5. Extend the driver to support SB-TSI over I3C in addition to I2C.
Both buses share the same core read/write path via sbtsi_xfer();
the is_i3c flag selects the underlying transport at probe time.
Backward compatibility with existing I2C deployments is maintained.
6. Add a miscdevice (/dev/sbtsi-<addr>) and an ioctl interface
(SBTSI_IOCTL_REG_XFER_CMD) that allows root userspace to perform
SB-TSI register read/write operations through the APML protocol,
consistent with the existing SBRMI ioctl interface.
7. Add mutex for SBTSI read/write in hwmon to prevent race condition with IOCTL.
8. Document the new SBTSI miscdevice and its ioctl in
Documentation/misc-devices/amd-sbi.rst.
Testing:
Tested on AMD Genoa/Turin/Venice BMC platforms with both I2C and I3C-attached
SB-TSI targets. hwmon sysfs attributes (tempX_input, tempX_max, etc.)
and ioctl register transfers verified against hardware.
Prathima (8):
hwmon/misc: amd-sbi: Move core sbtsi support from hwmon to misc
hwmon: sbtsi_temp: Refactor temperature register access into helpers
hwmon/misc: amd-sbi: Move sbtsi register transfer to core abstraction
misc: amd-sbi: Consolidate Common SBTSI Probe Path for I2C and I3C
misc: amd-sbi: Add support for SB-TSI over I3C
misc: amd-sbi: Add SBTSI ioctl register transfer interface
hwmon: Add mutex protecting for sbtsi read/write through hwmon
docs: misc: amd-sbi: Document SBTSI userspace interface
Documentation/misc-devices/amd-sbi.rst | 68 ++++++++
drivers/hwmon/Kconfig | 2 +-
drivers/hwmon/sbtsi_temp.c | 152 ++++++++---------
drivers/misc/amd-sbi/Kconfig | 13 ++
drivers/misc/amd-sbi/Makefile | 3 +
drivers/misc/amd-sbi/tsi-core.c | 202 ++++++++++++++++++++++
drivers/misc/amd-sbi/tsi-core.h | 26 +++
drivers/misc/amd-sbi/tsi.c | 224 +++++++++++++++++++++++++
include/linux/misc/tsi.h | 71 ++++++++
include/uapi/misc/amd-apml.h | 23 +++
10 files changed, 702 insertions(+), 82 deletions(-)
create mode 100644 drivers/misc/amd-sbi/tsi-core.c
create mode 100644 drivers/misc/amd-sbi/tsi-core.h
create mode 100644 drivers/misc/amd-sbi/tsi.c
create mode 100644 include/linux/misc/tsi.h
--
2.34.1
^ permalink raw reply
* Re: [PATCH 0/2] tracing: Move trace_printk.h out of kernel.h
From: Yury Norov @ 2026-06-22 13:11 UTC (permalink / raw)
To: Steven Rostedt
Cc: Christophe Leroy (CS GROUP), linux-kernel, linux-trace-kernel,
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: <20260622090826.20efadb3@fedora>
On Mon, Jun 22, 2026 at 09:08:26AM -0400, Steven Rostedt wrote:
> On Mon, 22 Jun 2026 10:05:13 +0200
> "Christophe Leroy (CS GROUP)" <chleroy@kernel.org> 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.
> >
> > Do we have a measurement of the increased compilation time ?
>
> I believe Yury does.
I re-run compilation is a more strict environment, and the difference
is negligible.
^ permalink raw reply
* Re: [PATCH] Documentation: admin-guide: fix bracelets and translation issue
From: Björn Persson @ 2026-06-22 13:10 UTC (permalink / raw)
To: Manuel Ebner
Cc: Jonathan Corbet, Shuah Khan, Mauro Carvalho Chehab, linux-media,
linux-doc, linux-kernel
In-Reply-To: <20260611075513.124994-2-manuelebner@mailbox.org>
[-- Attachment #1: Type: text/plain, Size: 268 bytes --]
Manuel Ebner wrote:
> -- Galaxis plug.in S [neuer Name: Galaxis DVB Card S CI
> +- Galaxis plug.in S [new Name: Galaxis DVB Card S CI]
If it's not German anymore, should it still have the capital N? It
doesn't look like "Name" is a name here.
Björn Persson
[-- Attachment #2: OpenPGP digital signatur --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ 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