* [PATCH v12 0/3] hwmon: Add support for the LTC4283 Hot Swap Controller
From: Nuno Sá via B4 Relay @ 2026-04-30 8:52 UTC (permalink / raw)
To: linux-gpio, linux-hwmon, devicetree, linux-doc
Cc: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jonathan Corbet, Linus Walleij, Bartosz Golaszewski,
Bartosz Golaszewski
This is v8 for the LTC4283 how swap controller.
Similar to the LTC4282 device, we're clearing some fault logs in the
reset_history attributes.
Guenter, for my last email worrying about rsense low values, this is
what I got internally:
"10uOhm at the smallest sense voltage of 15mV would be 1500A and 72kW, which
seems a tad excessive. The highest currents I’ve seen are around 200A, and
the -48V market 4283 serves is generally a lot lower than that. Normal values
are around 200uOhm. I’d say the resolution should be around 1uohm and if a
minimum is needed, 50uOhm is probably safe."
For the resolution, I'm pretty sure I got the tenths of micro
resolution for ltc4282 so I just kept it in here. So, if you don't mind
I would prefer to keep it this way to be safer and changing that now would
require me to change some formulas and I would prefer not to do that at
this stage.
---
Changes in v12:
- Patch 2:
* Add missing in0_reset_history in docs;
* Make sure to pass st->gpio_mask in __devm_auxiliary_device_create().
- Link to v11: https://patch.msgid.link/20260429-ltc4283-support-v11-0-27ccde619dad@analog.com
---
Nuno Sá (3):
dt-bindings: hwmon: Document the LTC4283 Swap Controller
hwmon: ltc4283: Add support for the LTC4283 Swap Controller
gpio: gpio-ltc4283: Add support for the LTC4283 Swap Controller
.../devicetree/bindings/hwmon/adi,ltc4283.yaml | 272 +++
Documentation/hwmon/index.rst | 1 +
Documentation/hwmon/ltc4283.rst | 267 +++
MAINTAINERS | 9 +
drivers/gpio/Kconfig | 15 +
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-ltc4283.c | 218 +++
drivers/hwmon/Kconfig | 12 +
drivers/hwmon/Makefile | 1 +
drivers/hwmon/ltc4283.c | 1795 ++++++++++++++++++++
10 files changed, 2591 insertions(+)
---
base-commit: 992920ad25f27f41521c1bb905d0e1062ecb9e93
change-id: 20260303-ltc4283-support-063f78acc5a4
--
Thanks!
- Nuno Sá
^ permalink raw reply
* [PATCH v12 1/3] dt-bindings: hwmon: Document the LTC4283 Swap Controller
From: Nuno Sá via B4 Relay @ 2026-04-30 8:52 UTC (permalink / raw)
To: linux-gpio, linux-hwmon, devicetree, linux-doc
Cc: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jonathan Corbet, Linus Walleij, Bartosz Golaszewski
In-Reply-To: <20260430-ltc4283-support-v12-0-5dc9901f2567@analog.com>
From: Nuno Sá <nuno.sa@analog.com>
The LTC4283 is a negative voltage hot swap controller that drives an
external N-channel MOSFET to allow a board to be safely inserted and
removed from a live backplane.
Special note for the "adi,vpower-drns-enable" property. It allows to choose
between the attenuated MOSFET drain voltage or the attenuated input
voltage at the RTNS pin (effectively choosing between input or output
power). This is a system level decision not really intended to change at
runtime and hence is being added as a Firmware property.
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Nuno Sá <nuno.sa@analog.com>
---
.../devicetree/bindings/hwmon/adi,ltc4283.yaml | 272 +++++++++++++++++++++
MAINTAINERS | 6 +
2 files changed, 278 insertions(+)
diff --git a/Documentation/devicetree/bindings/hwmon/adi,ltc4283.yaml b/Documentation/devicetree/bindings/hwmon/adi,ltc4283.yaml
new file mode 100644
index 000000000000..05e2132ad4d8
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/adi,ltc4283.yaml
@@ -0,0 +1,272 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/adi,ltc4283.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: LTC4283 Negative Voltage Hot Swap Controller
+
+maintainers:
+ - Nuno Sá <nuno.sa@analog.com>
+
+description: |
+ The LTC4283 negative voltage hot swap controller drives an external N-channel
+ MOSFET to allow a board to be safely inserted and removed from a live
+ backplane.
+
+ https://www.analog.com/media/en/technical-documentation/data-sheets/ltc4283.pdf
+
+properties:
+ compatible:
+ enum:
+ - adi,ltc4283
+
+ reg:
+ maxItems: 1
+
+ adi,rsense-nano-ohms:
+ description: Value of the sense resistor.
+
+ adi,current-limit-sense-microvolt:
+ description:
+ The current limit sense voltage of the chip is adjustable between
+ 15mV and 30mV in 1mV steps. This effectively limits the current
+ on the load.
+ minimum: 15000
+ maximum: 30000
+ default: 15000
+
+ adi,current-limit-foldback-factor:
+ description:
+ Specifies the foldback factor for the current limit. The current limit
+ can be reduced (folded back) to one of four preset levels. The value
+ represents the percentage of the current limit sense voltage to use
+ during foldback. A value of 100 means no foldback.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [10, 20, 50, 100]
+ default: 100
+
+ adi,cooling-delay-ms:
+ description:
+ Cooling time to apply after an overcurrent fault, FET bad or
+ external fault.
+ enum: [512, 1002, 2005, 4100, 8190, 16400, 32800, 65600]
+ default: 512
+
+ adi,fet-bad-timer-delay-ms:
+ description:
+ FET bad timer delay. After a FET bad status condition is detected,
+ this timer is started. If the condition persists for the
+ specified time, the FET is turned off and a fault is logged.
+ enum: [256, 512, 1002, 2005]
+ default: 256
+
+ adi,power-good-reset-on-fet:
+ description:
+ If set, resets the power good status when the MOSFET is turned off.
+ Otherwise, it resets when a low output voltage is detected.
+ type: boolean
+
+ adi,fet-turn-off-disable:
+ description:
+ If set, the MOSFET is not turned off when a FET fault is detected.
+ type: boolean
+
+ adi,tmr-pull-down-disable:
+ description: Disables 2uA pull-down current on the TMR pin.
+ type: boolean
+
+ adi,dvdt-inrush-control-disable:
+ description:
+ Disables dV/dt inrush control during startup. In dV/dt mode, the inrush
+ current is limited by controlling a constant output voltage ramp rate.
+ When disabled, the inrush control mechanism is active current limiting.
+ type: boolean
+
+ adi,fault-log-enable:
+ description:
+ If set, enables logging fault registers and ADC data into EEPROM upon a
+ fault.
+ type: boolean
+
+ adi,vpower-drns-enable:
+ description:
+ If set, enables the attenuated MOSFET drain voltage to be monitored. This
+ effectively means that the MOSFET power is monitored. If not set, the
+ attenuated input voltage (and hence input power) is monitored.
+ type: boolean
+
+ adi,external-fault-fet-off-enable:
+ description: Turns MOSFET off following an external fault.
+ type: boolean
+
+ adi,undervoltage-retry-disable:
+ description: Do not retry to turn on the MOSFET after an undervoltage fault.
+ type: boolean
+
+ adi,overvoltage-retry-disable:
+ description: Do not retry to turn on the MOSFET after an overvoltage fault.
+ type: boolean
+
+ adi,external-fault-retry-enable:
+ description: Retry to turn on the MOSFET after an external fault.
+ type: boolean
+
+ adi,overcurrent-retries:
+ description: Configures auto-retry following an Overcurrent fault.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [latch-off, "1", "7", unlimited]
+ default: latch-off
+
+ adi,fet-bad-retries:
+ description:
+ Configures auto-retry following a FET bad fault and a consequent MOSFET
+ turn off.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [latch-off, "1", "7", unlimited]
+ default: latch-off
+
+ adi,pgio1-func:
+ description: Configures the function of the PGIO1 pin.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [inverted_power_good, power_good, gpio]
+ default: inverted_power_good
+
+ adi,pgio2-func:
+ description: Configures the function of the PGIO2 pin.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [inverted_power_good, power_good, gpio, active_current_limiting]
+ default: inverted_power_good
+
+ adi,pgio3-func:
+ description: Configures the function of the PGIO3 pin.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [inverted_power_good_input, power_good_input, gpio]
+ default: inverted_power_good_input
+
+ adi,pgio4-func:
+ description: Configures the function of the PGIO4 pin.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum: [inverted_external_fault, external_fault, gpio]
+ default: inverted_external_fault
+
+ adi,gpio-on-adio1:
+ description: If set, the ADIO1 pin is used as a GPIO.
+ type: boolean
+
+ adi,gpio-on-adio2:
+ description: If set, the ADIO2 pin is used as a GPIO.
+ type: boolean
+
+ adi,gpio-on-adio3:
+ description: If set, the ADIO3 pin is used as a GPIO.
+ type: boolean
+
+ adi,gpio-on-adio4:
+ description: If set, the ADIO4 pin is used as a GPIO.
+ type: boolean
+
+ gpio-controller: true
+
+ '#gpio-cells':
+ const: 2
+
+dependencies:
+ adi,gpio-on-adio1:
+ - gpio-controller
+ - '#gpio-cells'
+ adi,gpio-on-adio2:
+ - gpio-controller
+ - '#gpio-cells'
+ adi,gpio-on-adio3:
+ - gpio-controller
+ - '#gpio-cells'
+ adi,gpio-on-adio4:
+ - gpio-controller
+ - '#gpio-cells'
+ adi,external-fault-retry-enable:
+ - adi,pgio4-func
+ adi,external-fault-fet-off-enable:
+ - adi,pgio4-func
+
+required:
+ - compatible
+ - reg
+ - adi,rsense-nano-ohms
+
+allOf:
+ - if:
+ properties:
+ adi,pgio1-func:
+ const: gpio
+ required:
+ - adi,pgio1-func
+ then:
+ required:
+ - gpio-controller
+ - '#gpio-cells'
+
+ - if:
+ properties:
+ adi,pgio2-func:
+ const: gpio
+ required:
+ - adi,pgio2-func
+ then:
+ required:
+ - gpio-controller
+ - '#gpio-cells'
+
+ - if:
+ properties:
+ adi,pgio3-func:
+ const: gpio
+ required:
+ - adi,pgio3-func
+ then:
+ required:
+ - gpio-controller
+ - '#gpio-cells'
+
+ - if:
+ properties:
+ adi,pgio4-func:
+ const: gpio
+ required:
+ - adi,pgio4-func
+ then:
+ properties:
+ adi,external-fault-retry-enable: false
+ adi,external-fault-fet-off-enable: false
+ required:
+ - gpio-controller
+ - '#gpio-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ swap-controller@15 {
+ compatible = "adi,ltc4283";
+ reg = <0x15>;
+
+ adi,rsense-nano-ohms = <500>;
+ adi,current-limit-sense-microvolt = <25000>;
+ adi,current-limit-foldback-factor = <10>;
+ adi,cooling-delay-ms = <8190>;
+ adi,fet-bad-timer-delay-ms = <512>;
+
+ adi,external-fault-fet-off-enable;
+ adi,pgio4-func = "external_fault";
+
+ adi,gpio-on-adio1;
+ adi,pgio1-func = "gpio";
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+ };
+...
diff --git a/MAINTAINERS b/MAINTAINERS
index c77860210bd5..76dd9edca7d5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -15238,6 +15238,12 @@ F: Documentation/devicetree/bindings/hwmon/adi,ltc4282.yaml
F: Documentation/hwmon/ltc4282.rst
F: drivers/hwmon/ltc4282.c
+LTC4283 HARDWARE MONITOR AND GPIO DRIVER
+M: Nuno Sá <nuno.sa@analog.com>
+L: linux-hwmon@vger.kernel.org
+S: Supported
+F: Documentation/devicetree/bindings/hwmon/adi,ltc4283.yaml
+
LTC4286 HARDWARE MONITOR DRIVER
M: Delphine CC Chiu <Delphine_CC_Chiu@Wiwynn.com>
L: linux-hwmon@vger.kernel.org
--
2.54.0
^ permalink raw reply related
* htmldocs: Documentation/networking/device_drivers/ethernet/index.rst:10: WARNING: toctree contains reference to nonexisting document 'networking/device_drivers/ethernet/smsc/smc9' [toc.not_readable]
From: kernel test robot @ 2026-04-30 7:41 UTC (permalink / raw)
To: Andrew Lunn; +Cc: oe-kbuild-all, 0day robot, linux-doc
tree: https://github.com/intel-lab-lkp/linux/commits/Andrew-Lunn/drivers-net-3com-3c509-Remove-this-driver/20260424-104110
head: 9223eb1499a6a614ff3744386dc2b772907adc68
commit: f80ee3d33b3345eebf1de83dd20d95a37b32f15d drivers: net: smsc: smc91c92: Remove this driver
date: 6 days ago
compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
docutils: docutils (Docutils 0.21.2, Python 3.13.5, on linux)
reproduce: (https://download.01.org/0day-ci/archive/20260430/202604300931.XuSzPxr8-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202604300931.XuSzPxr8-lkp@intel.com/
All warnings (new ones prefixed by >>):
Non-Preserved Properties
======================== [docutils]
Documentation/networking/device_drivers/ethernet/index.rst:10: WARNING: toctree contains reference to nonexisting document 'networking/device_drivers/ethernet/3com/3c509' [toc.not_readable]
>> Documentation/networking/device_drivers/ethernet/index.rst:10: WARNING: toctree contains reference to nonexisting document 'networking/device_drivers/ethernet/smsc/smc9' [toc.not_readable]
Documentation/networking/skbuff:36: ./include/linux/skbuff.h:48: ERROR: Unexpected section title.
vim +10 Documentation/networking/device_drivers/ethernet/index.rst
132db93572821e Jakub Kicinski 2020-06-26 7
132db93572821e Jakub Kicinski 2020-06-26 8 Contents:
132db93572821e Jakub Kicinski 2020-06-26 9
132db93572821e Jakub Kicinski 2020-06-26 @10 .. toctree::
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg GPIO driver
From: Arnaud POULIQUEN @ 2026-04-30 7:35 UTC (permalink / raw)
To: Mathieu Poirier, Padhi, Beleswar
Cc: Shenwei Wang, Andrew Lunn, Linus Walleij, Bartosz Golaszewski,
Jonathan Corbet, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Frank Li, Sascha Hauer, Shuah Khan,
linux-gpio@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, Pengutronix Kernel Team,
Fabio Estevam, Peng Fan, devicetree@vger.kernel.org,
linux-remoteproc@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org, dl-linux-imx,
Bartosz Golaszewski
In-Reply-To: <CANLsYkzt9xUczxSU28u-TfZAAjr0ufZKXAj8Eqfq=45gufXW3w@mail.gmail.com>
Hello,
On 4/29/26 21:20, Mathieu Poirier wrote:
> On Wed, 29 Apr 2026 at 12:07, Padhi, Beleswar <b-padhi@ti.com> wrote:
>>
>> Hi Mathieu,
>>
>> On 4/29/2026 11:03 PM, Mathieu Poirier wrote:
>>> On Wed, 29 Apr 2026 at 10:53, Shenwei Wang <shenwei.wang@nxp.com> wrote:
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Mathieu Poirier <mathieu.poirier@linaro.org>
>>>>> Sent: Wednesday, April 29, 2026 10:42 AM
>>>>> To: Shenwei Wang <shenwei.wang@nxp.com>
>>>>> Cc: Andrew Lunn <andrew@lunn.ch>; Padhi, Beleswar <b-padhi@ti.com>; Linus
>>>>> Walleij <linusw@kernel.org>; Bartosz Golaszewski <brgl@kernel.org>; Jonathan
>>>>> Corbet <corbet@lwn.net>; Rob Herring <robh@kernel.org>; Krzysztof Kozlowski
>>>>> <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>; Bjorn Andersson
>>>>> <andersson@kernel.org>; Frank Li <frank.li@nxp.com>; Sascha Hauer
>>>>> <s.hauer@pengutronix.de>; Shuah Khan <skhan@linuxfoundation.org>; linux-
>>>>> gpio@vger.kernel.org; linux-doc@vger.kernel.org; linux-kernel@vger.kernel.org;
>>>>> Pengutronix Kernel Team <kernel@pengutronix.de>; Fabio Estevam
>>>>> <festevam@gmail.com>; Peng Fan <peng.fan@nxp.com>;
>>>>> devicetree@vger.kernel.org; linux-remoteproc@vger.kernel.org;
>>>>> imx@lists.linux.dev; linux-arm-kernel@lists.infradead.org; dl-linux-imx <linux-
>>>>> imx@nxp.com>; Bartosz Golaszewski <brgl@bgdev.pl>
>>>>> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg GPIO driver
>>>>> On Tue, Apr 28, 2026 at 03:24:59PM +0000, Shenwei Wang wrote:
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Andrew Lunn <andrew@lunn.ch>
>>>>>>> Sent: Monday, April 27, 2026 3:49 PM
>>>>>>> To: Shenwei Wang <shenwei.wang@nxp.com>
>>>>>>> Cc: Padhi, Beleswar <b-padhi@ti.com>; Linus Walleij
>>>>>>> <linusw@kernel.org>; Bartosz Golaszewski <brgl@kernel.org>; Jonathan
>>>>>>> Corbet <corbet@lwn.net>; Rob Herring <robh@kernel.org>; Krzysztof
>>>>>>> Kozlowski <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>;
>>>>>>> Bjorn Andersson <andersson@kernel.org>; Mathieu Poirier
>>>>>>> <mathieu.poirier@linaro.org>; Frank Li <frank.li@nxp.com>; Sascha
>>>>>>> Hauer <s.hauer@pengutronix.de>; Shuah Khan
>>>>>>> <skhan@linuxfoundation.org>; linux-gpio@vger.kernel.org; linux-
>>>>>>> doc@vger.kernel.org; linux-kernel@vger.kernel.org; Pengutronix
>>>>>>> Kernel Team <kernel@pengutronix.de>; Fabio Estevam
>>>>>>> <festevam@gmail.com>; Peng Fan <peng.fan@nxp.com>;
>>>>>>> devicetree@vger.kernel.org; linux- remoteproc@vger.kernel.org;
>>>>>>> imx@lists.linux.dev; linux-arm- kernel@lists.infradead.org;
>>>>>>> dl-linux-imx <linux-imx@nxp.com>; Bartosz Golaszewski
>>>>>>> <brgl@bgdev.pl>
>>>>>>> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg
>>>>>>> GPIO driver
>>>>>>>>> struct virtio_gpio_response {
>>>>>>>>> __u8 status;
>>>>>>>>> __u8 value;
>>>>>>>>> };
>>>>>>>> It is the same message format. Please see the message definition
>>>>>>> (GET_DIRECTION) below:
>>>>>>>
>>>>>>>> + +-----+-----+-----+-----+-----+----+
>>>>>>>> + |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
>>>>>>>> + | 1 | 2 |port |line | err | dir|
>>>>>>>> + +-----+-----+-----+-----+-----+----+
>>>>>>> Sorry, but i don't see how two u8 vs six u8 are the same message format.
>>>>>>>
>>>>>> Some changes to the message format are necessary.
>>>>>>
>>>>>> Virtio uses two communication channels (virtqueues): one for requests and
>>>>> replies, and a second one for events.
>>>>>> In contrast, rpmsg provides only a single communication channel, so a
>>>>>> type field is required to distinguish between different kinds of messages.
>>>>>>
>>>>>> Since rpmsg replies and events share the same message format, an additional
>>>>> line is introduced to handle both cases.
>>>>>> Finally, rpmsg supports multiple GPIO controllers, so a port field is added to
>>>>> uniquely identify the target controller.
>>>>>
>>>>> I have commented on this before - RPMSG is already providing multiplexing
>>>>> capability by way of endpoints. There is no need for a port field. One endpoint,
>>>>> one GPIO controller.
>>>>>
>>>> You still need a way to let the remote side know which port the endpoint maps to, either
>>>> by embedding the port information in the message (the current way), or by sending it
>>>> separately.
>>>>
>>> An endpoint is created with every namespace request. There should be
>>> one namespace request for every GPIO controller, which yields a unique
>>> endpoint for each controller and eliminates the need for an extra
>>> field to identify them.
>>
>>
>> Right, but this can still be done by just having one namespace request.
>> We can create new endpoints bound to an existing namespace/channel by
>> invoking rpmsg_create_ept(). This is what I suggested here too:
>> https://lore.kernel.org/all/29485742-6e49-482e-b73d-228295daaeec@ti.com/
>>
>
> I will look at your suggestion (i.e link above) later this week or next week.
>
>> My mental model looks like this for the complete picture:
>>
>> 1. namespace/channel#1 = rpmsg-io
>> a. ept1 -> gpio-controller@1
>> b. ept2 -> gpio-controller@2
>>
>
> I've asked for one endpoint per GPIO controller since the very
> beginning. I don't yet have a strong opinion on whether to use one
> namespace request per GPIO controller or a single request that spins
> off multiple endpoints. I'll have to look at your link and reflect on
> that. Regardless of how we proceed on that front, multiplexing needs
> to happen at the endpoint level rather than the packet level. This is
> the only way this work can move forward.
>
I would be more in favor of Mathieu’s proposal: “An endpoint is created
with every namespace request.”
If the endpoint is created only on the Linux side, how do we match the
Linux endpoint address with the local port field on the remote side?
With a multi-namespace approach, the namespace could be rpmsg-io-[addr],
where [addr] corresponds to the GPIO controller address in the DT. This
would:
- match the RPMsg probe with the DT,
- provide a simple mapping between the port and the endpoint on both sides,
- allow multiple endpoints on the remote side,
- provide a simple discovery mechanism for remote capabilities.
Regards,
Arnaud
>> 2. namespace/channel#2 = rpmsg-i2c
>> a. ept1 -> i2c@1
>> b. ept2 -> i2c@2
>> c. ept3 -> i2c@3
>>
>> etc...
>>
>> This way device groups are isolated with each channel/namespace, and
>> instances within each device groups are also respected with specific
>> endpoints.
>>
>> Thanks,
>> Beleswar
>>
>
^ permalink raw reply
* Re: [PATCH net-next 2/2] ne2k: fold drivers/net/Space.c into ne.c
From: Geert Uytterhoeven @ 2026-04-30 7:22 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Jonathan Corbet, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Arnd Bergmann, Shuah Khan,
Simon Horman, Andrew Morton, Borislav Petkov (AMD), linux-doc,
linux-kernel, netdev
In-Reply-To: <20260429145624.2948432-2-arnd@kernel.org>
On Wed, 29 Apr 2026 at 16:58, Arnd Bergmann <arnd@kernel.org> wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> drivers/net/Space.c is the last remnant of the linux-2.4.x driver model
> that required each subsystem and device driver init function to be called
> from init/main.c explicitly, before the introduction of initcall levels.
>
> In linux-7.0, this was only used for a handful of ISA network drivers,
> with the ne2000 driver being the last one.
>
> Fold the code into ne.c directly, with minimal changes to preserve
> the existing command line parsing.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Documentation/arch/m68k/kernel-options.rst | 24 +-
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> # m68k
> --- a/Documentation/arch/m68k/kernel-options.rst
> +++ b/Documentation/arch/m68k/kernel-options.rst
> @@ -244,23 +244,7 @@ drive (with "root=").
> 3) General Device Options (Amiga and Atari)
> ===========================================
>
> -3.1) ether=
> ------------
> -
> -:Syntax: ether=[<irq>[,<base_addr>[,<mem_start>[,<mem_end>]]]],<dev-name>
> -
> -<dev-name> is the name of a net driver, as specified in
> -drivers/net/Space.c in the Linux source. Most prominent are eth0, ...
> -eth3, sl0, ... sl3, ppp0, ..., ppp3, dummy, and lo.
> -
> -The non-ethernet drivers (sl, ppp, dummy, lo) obviously ignore the
> -settings by this options. Also, the existing ethernet drivers for
> -Linux/m68k (ariadne, a2065, hydra) don't use them because Zorro boards
> -are really Plug-'n-Play, so the "ether=" option is useless altogether
> -for Linux/m68k.
> -
> -
> -3.2) hd=
> +3.1) hd=
[...]
> -3.3) max_scsi_luns=
> +3.2) max_scsi_luns=
[...]
> -3.4) st=
> +3.3) st=
[...]
> -3.5) dmasound=
> +3.4) dmasound=
So that's why you should leave numbering to the tooling ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v2] docs: kernel-parameters: document scope of irqaffinity= parameter
From: Bagas Sanjaya @ 2026-04-30 7:08 UTC (permalink / raw)
To: Aaron Tomlin, corbet, skhan
Cc: tglx, akpm, bp, rdunlap, dave.hansen, feng.tang,
pawan.kumar.gupta, dapeng1.mi, kees, elver, paulmck, lirongqing,
bhelgaas, bigeasy, linux-doc, linux-kernel
In-Reply-To: <20260421150911.42404-1-atomlin@atomlin.com>
[-- Attachment #1: Type: text/plain, Size: 747 bytes --]
On Tue, Apr 21, 2026 at 11:09:11AM -0400, Aaron Tomlin wrote:
> - This can be verified via the debugfs interface
> - (/sys/kernel/debug/irq/irqs/48). The dstate field will include
> + If the Linux kernel was built with Kconfig CONFIG_GENERIC_IRQ_DEBUGFS
> + enabled, this can be verified via the debugfs interface (e.g.,
> + /sys/kernel/debug/irq/irqs/48). The dstate field will include
> IRQD_IRQ_DISABLED, IRQD_IRQ_MASKED and IRQD_MANAGED_SHUTDOWN.
> + A managed IRQ will also include IRQD_AFFINITY_MANAGED. For example:
Use double-colon syntax (i.e. ``For example::``) for literal code block
below.
> +
> + # cat /sys/kernel/debug/irq/irqs/87
Thanks.
--
An old man doll... just what I always wanted! - Clara
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Warning: drivers/hwmon/yogafan.c:2 This comment starts with '/**', but isn't a kernel-doc comment. Refer to Documentation/doc-guide/kernel-doc.rst
From: kernel test robot @ 2026-04-30 6:46 UTC (permalink / raw)
To: Sergio Melas; +Cc: llvm, oe-kbuild-all, linux-kernel, Guenter Roeck, linux-doc
Hi Sergio,
First bad commit (maybe != root cause):
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
head: 57b8e2d666a31fa201432d58f5fe3469a0dd83ba
commit: c67c248ca406a86cf8b20bf1b3af5e7f3e36581f hwmon: (yogafan) Add support for Lenovo Yoga/Legion fan monitoring
date: 4 weeks ago
config: x86_64-allyesconfig (https://download.01.org/0day-ci/archive/20260430/202604301429.UUK5MS9i-lkp@intel.com/config)
compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260430/202604301429.UUK5MS9i-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Fixes: c67c248ca406 ("hwmon: (yogafan) Add support for Lenovo Yoga/Legion fan monitoring")
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202604301429.UUK5MS9i-lkp@intel.com/
All warnings (new ones prefixed by >>):
>> Warning: drivers/hwmon/yogafan.c:2 This comment starts with '/**', but isn't a kernel-doc comment. Refer to Documentation/doc-guide/kernel-doc.rst
* yoga_fan.c - Lenovo Yoga/Legion Fan Hardware Monitoring Driver
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [rafael-pm:bleeding-edge 14/30] htmldocs: Documentation/driver-api/acpi/index.rst:5: WARNING: toctree contains reference to nonexisting document 'driver-api/acpi/acpi-drivers' [toc.not_readable]
From: kernel test robot @ 2026-04-30 6:40 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: oe-kbuild-all, linux-acpi, linux-pm, linux-doc
tree: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git bleeding-edge
head: c776b06fa37fc4193b29821f1ac2871c02ae97b4
commit: 54ce12887d4a1d605f6a9b4736d07564ed07b529 [14/30] ACPI: Documentation: Remove driver-api/acpi/acpi-drivers.rst
compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
docutils: docutils (Docutils 0.21.2, Python 3.13.5, on linux)
reproduce: (https://download.01.org/0day-ci/archive/20260430/202604300815.6rqygFFB-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202604300815.6rqygFFB-lkp@intel.com/
All warnings (new ones prefixed by >>):
int kref_put_mutex (struct kref *kref, void (*release)(struct kref *kref), struct mutex *mutex) __cond_acquires(true# mutex)
------------------------------------------------------------------------------------------------^
Documentation/core-api/kref:328: ./include/linux/kref.h:94: WARNING: Invalid C declaration: Expected end of definition. [error at 92]
int kref_put_lock (struct kref *kref, void (*release)(struct kref *kref), spinlock_t *lock) __cond_acquires(true# lock)
--------------------------------------------------------------------------------------------^
>> Documentation/driver-api/acpi/index.rst:5: WARNING: toctree contains reference to nonexisting document 'driver-api/acpi/acpi-drivers' [toc.not_readable]
Documentation/driver-api/basics:42: ./kernel/time/time.c:370: WARNING: Duplicate C declaration, also defined at driver-api/basics:436.
Declaration is '.. c:function:: unsigned int jiffies_to_msecs (const unsigned long j)'. [duplicate_declaration.c]
Documentation/driver-api/basics:42: ./kernel/time/time.c:393: WARNING: Duplicate C declaration, also defined at driver-api/basics:453.
Declaration is '.. c:function:: unsigned int jiffies_to_usecs (const unsigned long j)'. [duplicate_declaration.c]
Documentation/driver-api/target:25: ./drivers/target/target_core_user.c:35: ERROR: Unexpected section title.
vim +5 Documentation/driver-api/acpi/index.rst
680e6ffa15103a Changbin Du 2019-04-25 4
680e6ffa15103a Changbin Du 2019-04-25 @5 .. toctree::
:::::: The code at line 5 was first introduced by commit
:::::: 680e6ffa15103ab610c0fc1241d2f98c801b13e2 Documentation: add Linux ACPI to Sphinx TOC tree
:::::: TO: Changbin Du <changbin.du@gmail.com>
:::::: CC: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH v3 3/3] hwmon: (pmbus) add support for Delta E50SN12051
From: Colin Huang via B4 Relay @ 2026-04-30 6:16 UTC (permalink / raw)
To: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Kevin Chang, Jonathan Corbet, Shuah Khan
Cc: linux-hwmon, devicetree, linux-kernel, linux-doc, Colin Huang,
Colin Huang
In-Reply-To: <20260430-add-e50sn12051-v3-0-f6d4e043ec7c@gmail.com>
From: Colin Huang <u8813345@gmail.com>
Add the pmbus driver for Delta E50SN12051 600W Non-isolated
1/8th Brick DCDC Power Modules.
Signed-off-by: Colin Huang <u8813345@gmail.com>
---
drivers/hwmon/pmbus/Kconfig | 9 +++++++
drivers/hwmon/pmbus/Makefile | 1 +
drivers/hwmon/pmbus/e50sn12051.c | 52 ++++++++++++++++++++++++++++++++++++++++
3 files changed, 62 insertions(+)
diff --git a/drivers/hwmon/pmbus/Kconfig b/drivers/hwmon/pmbus/Kconfig
index 8f4bff375ecb..4fbfcbc4a9c5 100644
--- a/drivers/hwmon/pmbus/Kconfig
+++ b/drivers/hwmon/pmbus/Kconfig
@@ -161,6 +161,15 @@ config SENSORS_DPS920AB
This driver can also be built as a module. If so, the module will
be called dps920ab.
+config SENSORS_E50SN12051
+ tristate "Delta E50SN12051 Power Modules"
+ help
+ If you say yes here you get hardware monitoring support for Delta
+ E50SN12051 Power Modules.
+
+ This driver can also be built as a module. If so, the module will
+ be called e50sn12051.
+
config SENSORS_INA233
tristate "Texas Instruments INA233 and compatibles"
help
diff --git a/drivers/hwmon/pmbus/Makefile b/drivers/hwmon/pmbus/Makefile
index 7129b62bc00f..fc910bf34fe3 100644
--- a/drivers/hwmon/pmbus/Makefile
+++ b/drivers/hwmon/pmbus/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_SENSORS_FSP_3Y) += fsp-3y.o
obj-$(CONFIG_SENSORS_HAC300S) += hac300s.o
obj-$(CONFIG_SENSORS_IBM_CFFPS) += ibm-cffps.o
obj-$(CONFIG_SENSORS_DPS920AB) += dps920ab.o
+obj-$(CONFIG_SENSORS_E50SN12051) += e50sn12051.o
obj-$(CONFIG_SENSORS_INA233) += ina233.o
obj-$(CONFIG_SENSORS_INSPUR_IPSPS) += inspur-ipsps.o
obj-$(CONFIG_SENSORS_IR35221) += ir35221.o
diff --git a/drivers/hwmon/pmbus/e50sn12051.c b/drivers/hwmon/pmbus/e50sn12051.c
new file mode 100644
index 000000000000..efb4d62b2603
--- /dev/null
+++ b/drivers/hwmon/pmbus/e50sn12051.c
@@ -0,0 +1,52 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Hardware monitoring driver for E50SN12051
+ */
+
+#include <linux/i2c.h>
+#include <linux/module.h>
+#include <linux/mod_devicetable.h>
+#include "pmbus.h"
+
+static struct pmbus_driver_info e50sn12051_info = {
+ .pages = 1,
+ .format[PSC_VOLTAGE_IN] = linear,
+ .format[PSC_VOLTAGE_OUT] = linear,
+ .format[PSC_CURRENT_OUT] = linear,
+ .format[PSC_TEMPERATURE] = linear,
+ .func[0] = PMBUS_HAVE_VIN | PMBUS_HAVE_STATUS_INPUT |
+ PMBUS_HAVE_VOUT | PMBUS_HAVE_STATUS_VOUT |
+ PMBUS_HAVE_IOUT | PMBUS_HAVE_STATUS_IOUT |
+ PMBUS_HAVE_TEMP | PMBUS_HAVE_STATUS_TEMP,
+};
+
+static const struct i2c_device_id e50sn12051_id[] = { { "e50sn12051", 0 }, {} };
+MODULE_DEVICE_TABLE(i2c, e50sn12051_id);
+
+static const struct of_device_id e50sn12051_of_match[] = {
+ { .compatible = "delta,e50sn12051" },
+ {},
+};
+MODULE_DEVICE_TABLE(of, e50sn12051_of_match);
+
+static int e50sn12051_probe(struct i2c_client *client)
+{
+ return pmbus_do_probe(client, &e50sn12051_info);
+}
+
+static struct i2c_driver e50sn12051_driver = {
+ .driver = {
+ .name = "e50sn12051",
+ .of_match_table = e50sn12051_of_match,
+ },
+ .probe = e50sn12051_probe,
+
+ .id_table = e50sn12051_id,
+};
+
+module_i2c_driver(e50sn12051_driver);
+
+MODULE_AUTHOR("Kevin Chang <kevin.chang2@amd.com>");
+MODULE_DESCRIPTION("PMBus driver for E50SN12051");
+MODULE_LICENSE("GPL");
+MODULE_IMPORT_NS("PMBUS");
--
2.34.1
^ permalink raw reply related
* [PATCH v3 2/3] Documentation/hwmon: add Delta E50SN12051 documentation
From: Colin Huang via B4 Relay @ 2026-04-30 6:16 UTC (permalink / raw)
To: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Kevin Chang, Jonathan Corbet, Shuah Khan
Cc: linux-hwmon, devicetree, linux-kernel, linux-doc, Colin Huang,
Colin Huang
In-Reply-To: <20260430-add-e50sn12051-v3-0-f6d4e043ec7c@gmail.com>
From: Colin Huang <u8813345@gmail.com>
Document the hardware monitoring support for the Delta E50SN12051
device.
The documentation describes the supported sensors exposed via the
hwmon subsystem, including voltage, current, and temperature measurements.
Signed-off-by: Colin Huang <u8813345@gmail.com>
---
Documentation/hwmon/e50sn12051.rst | 81 ++++++++++++++++++++++++++++++++++++++
Documentation/hwmon/index.rst | 1 +
2 files changed, 82 insertions(+)
diff --git a/Documentation/hwmon/e50sn12051.rst b/Documentation/hwmon/e50sn12051.rst
new file mode 100644
index 000000000000..cbbfa7895d82
--- /dev/null
+++ b/Documentation/hwmon/e50sn12051.rst
@@ -0,0 +1,81 @@
+.. SPDX-License-Identifier: GPL-2.0-or-later
+
+Kernel driver e50sn12051
+========================
+
+Supported chips:
+
+ * Delta E50SN12051
+
+ Prefix: 'e50sn12051'
+
+ Addresses scanned: -
+
+ Datasheet:
+
+ Provided by Delta upon request and NDA
+
+Description
+-----------
+
+E50SN12051 is a 600W non-isolated 1/8th brick DC-DC power module.
+
+This driver supports the E50SN12051 PMBus compliant monitor device.
+
+The device provides measurements for:
+
+* Input voltage
+* Output current
+* Output voltage
+* Temperature
+
+The driver is based on the PMBus core and exposes standard hwmon
+sysfs attributes.
+
+Sysfs attributes
+----------------
+
+======================= =======================================================
+curr1_label "iout1"
+curr1_crit Critical maximum current.
+ From IOUT_OC_FAULT_LIMIT register.
+curr1_crit_alarm Current critical high alarm.
+ From IOUT_OC_FAULT status.
+curr1_input Measured current.
+ From READ_IOUT register.
+curr1_max Maximum current.
+ From IOUT_OC_WARN_LIMIT register.
+curr1_max_alarm Current high alarm.
+ From IOUT_OC_WARN_LIMIT status.
+
+in1_label "vin"
+in1_alarm Input voltage alarm.
+in1_input Measured voltage.
+ From READ_VIN register.
+
+in2_label "vout1"
+in2_crit Critical maximum voltage.
+ From VOUT_OV_FAULT_LIMIT register.
+in2_crit_alarm Voltage critical high alarm.
+ From VOLTAGE_OV_FAULT status.
+in2_input Measured voltage.
+ From READ_VOUT register.
+in2_max Maximum voltage.
+ From VOUT_OV_WARN_LIMIT register.
+in2_max_alarm Voltage high alarm.
+ From VOLTAGE_OV_WARNING status.
+
+temp1_crit Critical high temperature.
+ From OT_FAULT_LIMIT register.
+temp1_crit_alarm Module temperature critical high alarm.
+ Set by comparing READ_TEMPERATURE_1 with OT_FAULT_LIMIT
+ if TEMP_OT_FAULT status is set.
+temp1_input Measured module's hot spot temperature.
+ From READ_TEMPERATURE_1 register.
+temp1_max Maximum temperature.
+ From OT_WARN_LIMIT register.
+temp1_max_alarm Module temperature high alarm.
+ Set by comparing READ_TEMPERATURE_1 with OT_WARN_LIMIT if
+ TEMP_OT_WARNING status is set.
+======================= =======================================================
+
diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst
index 8b655e5d6b68..ba08655fc496 100644
--- a/Documentation/hwmon/index.rst
+++ b/Documentation/hwmon/index.rst
@@ -68,6 +68,7 @@ Hardware Monitoring Kernel Drivers
drivetemp
ds1621
ds620
+ e50sn12051
emc1403
emc2103
emc2305
--
2.34.1
^ permalink raw reply related
* [PATCH v3 1/3] dt-bindings: hwmon: pmbus: add Delta E50SN12051 binding
From: Colin Huang via B4 Relay @ 2026-04-30 6:16 UTC (permalink / raw)
To: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Kevin Chang, Jonathan Corbet, Shuah Khan
Cc: linux-hwmon, devicetree, linux-kernel, linux-doc, Colin Huang,
Colin Huang
In-Reply-To: <20260430-add-e50sn12051-v3-0-f6d4e043ec7c@gmail.com>
From: Colin Huang <u8813345@gmail.com>
Add devicetree binding documentation for the Delta E50SN12051
PMBus-compliant device.
Signed-off-by: Colin Huang <u8813345@gmail.com>
---
.../bindings/hwmon/pmbus/delta,e50sn12051.yaml | 41 ++++++++++++++++++++++
1 file changed, 41 insertions(+)
diff --git a/Documentation/devicetree/bindings/hwmon/pmbus/delta,e50sn12051.yaml b/Documentation/devicetree/bindings/hwmon/pmbus/delta,e50sn12051.yaml
new file mode 100644
index 000000000000..ea7b6d001d66
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/pmbus/delta,e50sn12051.yaml
@@ -0,0 +1,41 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/pmbus/delta,e50sn12051.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Delta E50SN12051 PMBus Sensor
+
+maintainers:
+ - Kevin Chang <kevin.chang2@amd.com>
+
+description: |
+ This binding describes the Delta E50SN12051 PMBus sensor.
+ The driver supports reading voltage, current, and temperature
+ using the PMBus interface.
+
+properties:
+ compatible:
+ const: delta,e50sn12051
+
+ reg:
+ maxItems: 1
+ description: I2C bus address of the PMBus device
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ hwmon@40 {
+ compatible = "delta,e50sn12051";
+ reg = <0x40>;
+ };
+ };
--
2.34.1
^ permalink raw reply related
* [PATCH v3 0/3] add support for Delta E50SN12051
From: Colin Huang via B4 Relay @ 2026-04-30 6:16 UTC (permalink / raw)
To: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Kevin Chang, Jonathan Corbet, Shuah Khan
Cc: linux-hwmon, devicetree, linux-kernel, linux-doc, Colin Huang,
Colin Huang
Delta E50SN12051 is a 600W non-isolated 1/8th brick DC-DC power module.
With this series applied, voltage, current and temperature sensors can
be exposed through the standard hwmon interface.
Changes in this series:
- Introduce device-tree binding documentation for the new device
- Add hwmon documentation describing the supported sensors
- Add PMBus driver support for Delta E50SN12051
Signed-off-by: Colin Huang <u8813345@gmail.com>
---
Changes in v3:
- Simplify to pass &e50sn12051_info directly to pmbus_do_probe()
to avoid the extra memory allocation
- Link to v2: https://lore.kernel.org/r/20260430-add-e50sn12051-v2-0-d76fe42482ab@gmail.com
Changes in v2:
- Add %YAML 1.2 declaration in binding document.
- Use a generic node name in examples in binding document.
- Add MODULE_IMPORT_NS("PMBUS")
- Remove unused / incorrect headers
- Link to v1: https://lore.kernel.org/r/20260429-add-e50sn12051-v1-0-c101e6c80bbb@gmail.com
---
Colin Huang (3):
dt-bindings: hwmon: pmbus: add Delta E50SN12051 binding
Documentation/hwmon: add Delta E50SN12051 documentation
hwmon: (pmbus) add support for Delta E50SN12051
.../bindings/hwmon/pmbus/delta,e50sn12051.yaml | 41 +++++++++++
Documentation/hwmon/e50sn12051.rst | 81 ++++++++++++++++++++++
Documentation/hwmon/index.rst | 1 +
drivers/hwmon/pmbus/Kconfig | 9 +++
drivers/hwmon/pmbus/Makefile | 1 +
drivers/hwmon/pmbus/e50sn12051.c | 52 ++++++++++++++
6 files changed, 185 insertions(+)
---
base-commit: b584e7d50af502462349910bf4ed30057620b69f
change-id: 20260316-add-e50sn12051-ad828ad6777a
Best regards,
--
Colin Huang <u8813345@gmail.com>
^ permalink raw reply
* [PATCH 6/6] KVM: PPC: Document KVM_PPC_GET_COMPAT_CAPS ioctl
From: Amit Machhiwal @ 2026-04-30 5:49 UTC (permalink / raw)
To: linuxppc-dev, Madhavan Srinivasan
Cc: Amit Machhiwal, Vaibhav Jain, Paolo Bonzini, Jonathan Corbet,
Shuah Khan, kvm, linux-kernel, linux-doc
In-Reply-To: <20260430054906.94431-1-amachhiw@linux.ibm.com>
Add documentation for the KVM_PPC_GET_COMPAT_CAPS ioctl to the KVM API
documentation.
The ioctl exposes host processor compatibility modes supported for
nested KVM guests on PowerPC systems.
Signed-off-by: Amit Machhiwal <amachhiw@linux.ibm.com>
---
Documentation/virt/kvm/api.rst | 35 ++++++++++++++++++++++++++++++++++
1 file changed, 35 insertions(+)
diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
index 52bbbb553ce1..7a10c3c6cbf1 100644
--- a/Documentation/virt/kvm/api.rst
+++ b/Documentation/virt/kvm/api.rst
@@ -6555,6 +6555,41 @@ KVM_S390_KEYOP_SSKE
.. _kvm_run:
+4.145 KVM_PPC_GET_COMPAT_CAPS
+-----------------------------
+:Capability: KVM_CAP_PPC_COMPAT_CAPS
+:Architectures: powerpc
+:Type: vm ioctl
+:Parameters: struct kvm_ppc_compat_caps (out)
+:Returns:
+ 0 on successful completion,
+ -EFAULT if ``struct kvm_ppc_compat_caps`` cannot be written
+
+IBM POWER system server-based processors provide a compatibility mode feature
+where an Nth generation processor can operate in modes consistent with earlier
+generations such as (N-1) and (N-2).
+
+This ioctl provides userspace with information about the CPU compatibility modes
+supported by the current host processor for booting the nested KVM guests on
+PowerNV (KVM nested APIv1) and PowerVM (KVM nested APIv2) platforms.
+
+::
+
+ struct kvm_ppc_compat_caps {
+ __u32 flags;
+ __u64 compat_capabilities; /* Capabilities supported by the host */
+ };
+
+The ``compat_capabilities`` bit field describes the processor compatibility
+modes supported by the host. For example, the following bits indicate support
+for specific processor modes.
+
+::
+
+ bit 1: KVM guests can run in Power9 processor mode
+ bit 2: KVM guests can run in Power10 processor mode
+ bit 3: KVM guests can run in Power11 processor mode
+
5. The kvm_run structure
========================
--
2.50.1
^ permalink raw reply related
* [PATCH 0/6] KVM: PPC: Handle CPU compatibility mode for nested guests
From: Amit Machhiwal @ 2026-04-30 5:48 UTC (permalink / raw)
To: linuxppc-dev, Madhavan Srinivasan
Cc: Amit Machhiwal, Vaibhav Jain, Paolo Bonzini, Nicholas Piggin,
Michael Ellerman, Christophe Leroy (CS GROUP), Jonathan Corbet,
Shuah Khan, kvm, linux-kernel, linux-doc
On POWER systems, newer processor generations can operate in compatibility
modes corresponding to earlier generations (e.g., a Power11 system running
in Power10 compatibility mode). In such cases, the effective CPU level
exposed to guests differs from the physical processor generation.
This creates a problem for nested virtualization. When booting a nested KVM
guest (L2) inside a host KVM guest (L1) running in a compatibility mode,
userspace (e.g., QEMU) may derive the CPU model from the raw hardware PVR
and attempt to configure the nested guest accordingly. However, the L1
partition is constrained by the compatibility level negotiated with the
hypervisor (L0), and requests exceeding that level are rejected, leading to
guest boot failures such as:
KVM-NESTEDv2: couldn't set guest wide elements
This series addresses the issue in two steps:
1. Detect and reject invalid compatibility requests early in KVM to avoid
late failures.
2. Provide a mechanism for userspace to query the effective CPU
compatibility modes supported by the host, so it can select an
appropriate CPU model for nested guests.
To achieve this, the series introduces a new KVM capability and ioctl
(KVM_CAP_PPC_COMPAT_CAPS / KVM_PPC_GET_COMPAT_CAPS) that expose the
compatibility modes supported by the host.
The implementation supports both:
- PowerVM (nested API v2), where compatibility information is obtained
via the H_GUEST_GET_CAPABILITIES hypercall.
- PowerNV (nested API v1), where compatibility is derived from the device
tree ("cpu-version") representing the effective processor compatibility
level.
This allows userspace (e.g., QEMU) to select a CPU model consistent with
the host compatibility mode, avoiding mismatches and enabling successful
nested guest boot.
Patch summary:
[1/6] Validate arch_compat against host compatibility mode
[2/6] Introduce KVM_CAP_PPC_COMPAT_CAPS and ioctl
[3/6] Wire up ioctl handling
[4/6] Implement capability retrieval for PowerVM (API v2)
[5/6] Add PowerNV support (API v1)
[6/6] Document the new ioctl
Tested on:
- Power11 pSeries LPAR in Power10 compatibility mode (nested API v2)
- Power10 PowerNV system (and QEMU TCG PowerNV 11) with nested
virtualization (API v1) with various combinations of KVM L1/L2 guests
in various supported compatibility modes.
With this series, nested guests boot successfully in configurations where
they previously failed due to compatibility mismatches.
Amit Machhiwal (6):
KVM: PPC: Book3S HV: Validate arch_compat against host compatibility
mode
KVM: PPC: Introduce KVM_CAP_PPC_COMPAT_CAPS and
KVM_PPC_GET_COMPAT_CAPS
KVM: PPC: Wire up KVM_PPC_GET_COMPAT_CAPS ioctl
KVM: PPC: Book3S HV: Implement compat CPU capability retrieval for KVM
on PowerVM
KVM: PPC: Book3S HV: Add support for compat CPU capabilities for KVM
on PowerNV
KVM: PPC: Document KVM_PPC_GET_COMPAT_CAPS ioctl
Documentation/virt/kvm/api.rst | 35 +++++++++++++++++
arch/powerpc/include/asm/kvm_ppc.h | 1 +
arch/powerpc/include/uapi/asm/kvm.h | 6 +++
arch/powerpc/kvm/book3s_hv.c | 58 +++++++++++++++++++++++++++++
arch/powerpc/kvm/powerpc.c | 19 ++++++++++
include/uapi/linux/kvm.h | 4 ++
6 files changed, 123 insertions(+)
base-commit: dca922e019dd758b4c1b4bec8f1d509efddeaab4
--
2.50.1
^ permalink raw reply
* Re: [PATCH 01/14] mm: decouple protnone helpers from CONFIG_NUMA_BALANCING
From: SeongJae Park @ 2026-04-30 4:47 UTC (permalink / raw)
To: Kiryl Shutsemau (Meta)
Cc: SeongJae Park, akpm, rppt, peterx, david, ljs, surenb, vbabka,
Liam.Howlett, ziy, corbet, skhan, seanjc, pbonzini, jthoughton,
aarcange, usama.arif, linux-mm, linux-kernel, linux-doc,
linux-kselftest, kvm, kernel-team
In-Reply-To: <20260427114607.4068647-2-kas@kernel.org>
On Mon, 27 Apr 2026 12:45:49 +0100 "Kiryl Shutsemau (Meta)" <kas@kernel.org> wrote:
> pte_protnone() and pmd_protnone() detect present-but-inaccessible page
> table entries. This capability is useful beyond NUMA balancing — for
> example, userfaultfd working set tracking uses protnone PTEs to track
> page access without unmapping pages.
I agree. It can be useful for general access monitoring. I'm also slowly but
continuously working [1] to use that for DAMON.
>
> Introduce CONFIG_ARCH_HAS_PTE_PROTNONE to decouple the protnone PTE
> infrastructure from CONFIG_NUMA_BALANCING. The six architectures that
> support protnone PTEs (x86_64, arm64, powerpc, s390, riscv, loongarch)
> now select this option, and CONFIG_NUMA_BALANCING depends on it.
>
> No functional change — the same set of architectures continues to have
> working protnone support, but the infrastructure is now available
> independently of NUMA balancing.
I think this is a good change for making the infrastructure available for uffd.
I believe this can also be useful for making it further available for general
access monitoring purposes. I hope this to be landed on the mainline sooner
than later. Thank you for doing this, Kiryl!
>
> Signed-off-by: Kiryl Shutsemau (Meta) <kas@kernel.org>
> Assisted-by: Claude:claude-opus-4-6
Acked-by: SeongJae Park <sj@kernel.org>
[1] https://lore.kernel.org/linux-mm/20260218054320.4570-1-sj@kernel.org/
Thanks,
SJ
[...]
^ permalink raw reply
* Re: [PATCHv7 09/18] mm/hugetlb: Defer vmemmap population for bootmem hugepages
From: patchwork-bot+linux-riscv @ 2026-04-30 3:26 UTC (permalink / raw)
To: Kiryl Shutsemau
Cc: linux-riscv, akpm, muchun.song, david, willy, usamaarif642, fvdl,
osalvador, rppt, vbabka, lorenzo.stoakes, ziy, bhe, mhocko,
hannes, corbet, chenhuacai, kernel, palmer, paul.walmsley, aou,
alex, kernel-team, linux-mm, linux-kernel, linux-doc, loongarch
In-Reply-To: <20260227193030.272078-9-kas@kernel.org>
Hello:
This patch was applied to riscv/linux.git (fixes)
by Andrew Morton <akpm@linux-foundation.org>:
On Fri, 27 Feb 2026 19:30:10 +0000 you wrote:
> Currently, the vmemmap for bootmem-allocated gigantic pages is populated
> early in hugetlb_vmemmap_init_early(). However, the zone information is
> only available after zones are initialized. If it is later discovered
> that a page spans multiple zones, the HVO mapping must be undone and
> replaced with a normal mapping using vmemmap_undo_hvo().
>
> Defer the actual vmemmap population to hugetlb_vmemmap_init_late(). At
> this stage, zones are already initialized, so it can be checked if the
> page is valid for HVO before deciding how to populate the vmemmap.
>
> [...]
Here is the summary with links:
- [PATCHv7,09/18] mm/hugetlb: Defer vmemmap population for bootmem hugepages
https://git.kernel.org/riscv/c/209e6d9eb13a
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCHv7 14/18] hugetlb: Remove VMEMMAP_SYNCHRONIZE_RCU
From: patchwork-bot+linux-riscv @ 2026-04-30 3:26 UTC (permalink / raw)
To: Kiryl Shutsemau
Cc: linux-riscv, akpm, muchun.song, david, willy, usamaarif642, fvdl,
osalvador, rppt, vbabka, lorenzo.stoakes, ziy, bhe, mhocko,
hannes, corbet, chenhuacai, kernel, palmer, paul.walmsley, aou,
alex, kernel-team, linux-mm, linux-kernel, linux-doc, loongarch,
david
In-Reply-To: <20260227193030.272078-14-kas@kernel.org>
Hello:
This patch was applied to riscv/linux.git (fixes)
by Andrew Morton <akpm@linux-foundation.org>:
On Fri, 27 Feb 2026 19:30:15 +0000 you wrote:
> From: Kiryl Shutsemau <kas@kernel.org>
>
> The VMEMMAP_SYNCHRONIZE_RCU flag triggered synchronize_rcu() calls to
> prevent a race between HVO remapping and page_ref_add_unless(). The
> race could occur when a speculative PFN walker tried to modify the
> refcount on a struct page that was in the process of being remapped
> to a fake head.
>
> [...]
Here is the summary with links:
- [PATCHv7,14/18] hugetlb: Remove VMEMMAP_SYNCHRONIZE_RCU
https://git.kernel.org/riscv/c/01b1d0ffb6f7
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCHv7 02/18] mm: Change the interface of prep_compound_tail()
From: patchwork-bot+linux-riscv @ 2026-04-30 3:26 UTC (permalink / raw)
To: Kiryl Shutsemau
Cc: linux-riscv, akpm, muchun.song, david, willy, usamaarif642, fvdl,
osalvador, rppt, vbabka, lorenzo.stoakes, ziy, bhe, mhocko,
hannes, corbet, chenhuacai, kernel, palmer, paul.walmsley, aou,
alex, kernel-team, linux-mm, linux-kernel, linux-doc, loongarch,
david
In-Reply-To: <20260227193030.272078-2-kas@kernel.org>
Hello:
This patch was applied to riscv/linux.git (fixes)
by Andrew Morton <akpm@linux-foundation.org>:
On Fri, 27 Feb 2026 19:30:03 +0000 you wrote:
> From: Kiryl Shutsemau <kas@kernel.org>
>
> Instead of passing down the head page and tail page index, pass the tail
> and head pages directly, as well as the order of the compound page.
>
> This is a preparation for changing how the head position is encoded in
> the tail page.
>
> [...]
Here is the summary with links:
- [PATCHv7,02/18] mm: Change the interface of prep_compound_tail()
https://git.kernel.org/riscv/c/f0369fb13619
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCHv7 08/18] mm/sparse: Check memmap alignment for compound_info_has_mask()
From: patchwork-bot+linux-riscv @ 2026-04-30 3:25 UTC (permalink / raw)
To: Kiryl Shutsemau
Cc: linux-riscv, akpm, muchun.song, david, willy, usamaarif642, fvdl,
osalvador, rppt, vbabka, lorenzo.stoakes, ziy, bhe, mhocko,
hannes, corbet, chenhuacai, kernel, palmer, paul.walmsley, aou,
alex, kernel-team, linux-mm, linux-kernel, linux-doc, loongarch
In-Reply-To: <20260227193030.272078-8-kas@kernel.org>
Hello:
This patch was applied to riscv/linux.git (fixes)
by Andrew Morton <akpm@linux-foundation.org>:
On Fri, 27 Feb 2026 19:30:09 +0000 you wrote:
> From: Kiryl Shutsemau <kas@kernel.org>
>
> If page->compound_info encodes a mask, it is expected that vmemmap to be
> naturally aligned to the maximum folio size.
>
> Add a VM_WARN_ON_ONCE() to check the alignment.
>
> [...]
Here is the summary with links:
- [PATCHv7,08/18] mm/sparse: Check memmap alignment for compound_info_has_mask()
https://git.kernel.org/riscv/c/9f94db4c7eaa
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCHv7 13/18] mm: Drop fake head checks
From: patchwork-bot+linux-riscv @ 2026-04-30 3:25 UTC (permalink / raw)
To: Kiryl Shutsemau
Cc: linux-riscv, akpm, muchun.song, david, willy, usamaarif642, fvdl,
osalvador, rppt, vbabka, lorenzo.stoakes, ziy, bhe, mhocko,
hannes, corbet, chenhuacai, kernel, palmer, paul.walmsley, aou,
alex, kernel-team, linux-mm, linux-kernel, linux-doc, loongarch,
david
In-Reply-To: <20260227193030.272078-13-kas@kernel.org>
Hello:
This patch was applied to riscv/linux.git (fixes)
by Andrew Morton <akpm@linux-foundation.org>:
On Fri, 27 Feb 2026 19:30:14 +0000 you wrote:
> From: Kiryl Shutsemau <kas@kernel.org>
>
> With fake head pages eliminated in the previous commit, remove the
> supporting infrastructure:
>
> - page_fixed_fake_head(): no longer needed to detect fake heads;
> - page_is_fake_head(): no longer needed;
> - page_count_writable(): no longer needed for RCU protection;
> - RCU read_lock in page_ref_add_unless(): no longer needed;
>
> [...]
Here is the summary with links:
- [PATCHv7,13/18] mm: Drop fake head checks
https://git.kernel.org/riscv/c/32c440d67e6c
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCHv7 12/18] mm/hugetlb: Remove fake head pages
From: patchwork-bot+linux-riscv @ 2026-04-30 3:25 UTC (permalink / raw)
To: Kiryl Shutsemau
Cc: linux-riscv, akpm, muchun.song, david, willy, usamaarif642, fvdl,
osalvador, rppt, vbabka, lorenzo.stoakes, ziy, bhe, mhocko,
hannes, corbet, chenhuacai, kernel, palmer, paul.walmsley, aou,
alex, kernel-team, linux-mm, linux-kernel, linux-doc, loongarch
In-Reply-To: <20260227193030.272078-12-kas@kernel.org>
Hello:
This patch was applied to riscv/linux.git (fixes)
by Andrew Morton <akpm@linux-foundation.org>:
On Fri, 27 Feb 2026 19:30:13 +0000 you wrote:
> From: Kiryl Shutsemau <kas@kernel.org>
>
> HugeTLB Vmemmap Optimization (HVO) reduces memory usage by freeing most
> vmemmap pages for huge pages and remapping the freed range to a single
> page containing the struct page metadata.
>
> With the new mask-based compound_info encoding (for power-of-2 struct
> page sizes), all tail pages of the same order are now identical
> regardless of which compound page they belong to. This means the tail
> pages can be truly shared without fake heads.
>
> [...]
Here is the summary with links:
- [PATCHv7,12/18] mm/hugetlb: Remove fake head pages
https://git.kernel.org/riscv/c/622026e87c40
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCHv7 01/18] mm: Move MAX_FOLIO_ORDER definition to mmzone.h
From: patchwork-bot+linux-riscv @ 2026-04-30 3:25 UTC (permalink / raw)
To: Kiryl Shutsemau
Cc: linux-riscv, akpm, muchun.song, david, willy, usamaarif642, fvdl,
osalvador, rppt, vbabka, lorenzo.stoakes, ziy, bhe, mhocko,
hannes, corbet, chenhuacai, kernel, palmer, paul.walmsley, aou,
alex, kernel-team, linux-mm, linux-kernel, linux-doc, loongarch,
david
In-Reply-To: <20260227193030.272078-1-kas@kernel.org>
Hello:
This patch was applied to riscv/linux.git (fixes)
by Andrew Morton <akpm@linux-foundation.org>:
On Fri, 27 Feb 2026 19:30:02 +0000 you wrote:
> From: Kiryl Shutsemau <kas@kernel.org>
>
> Move MAX_FOLIO_ORDER definition from mm.h to mmzone.h.
>
> This is preparation for adding the vmemmap_tails array to struct
> zone, which requires MAX_FOLIO_ORDER to be available in mmzone.h.
>
> [...]
Here is the summary with links:
- [PATCHv7,01/18] mm: Move MAX_FOLIO_ORDER definition to mmzone.h
https://git.kernel.org/riscv/c/a2c77ec320a9
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCHv7.1 17/18] hugetlb: Update vmemmap_dedup.rst
From: patchwork-bot+linux-riscv @ 2026-04-30 3:25 UTC (permalink / raw)
To: Kiryl Shutsemau
Cc: linux-riscv, akpm, alex, aou, bhe, chenhuacai, corbet, david,
fvdl, hannes, kernel-team, kernel, linux-doc, linux-kernel,
linux-mm, loongarch, lorenzo.stoakes, mhocko, muchun.song,
osalvador, palmer, paul.walmsley, rppt, usamaarif642, vbabka,
willy, ziy
In-Reply-To: <20260302105630.303492-1-kas@kernel.org>
Hello:
This patch was applied to riscv/linux.git (fixes)
by Andrew Morton <akpm@linux-foundation.org>:
On Mon, 2 Mar 2026 10:56:28 +0000 you wrote:
> From: Kiryl Shutsemau <kas@kernel.org>
>
> Update the documentation regarding vmemmap optimization for hugetlb to
> reflect the changes in how the kernel maps the tail pages.
>
> Fake heads no longer exist. Remove their description.
>
> [...]
Here is the summary with links:
- [PATCHv7.1,17/18] hugetlb: Update vmemmap_dedup.rst
https://git.kernel.org/riscv/c/fed8676ca2b0
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCHv7 05/18] riscv/mm: Align vmemmap to maximal folio size
From: patchwork-bot+linux-riscv @ 2026-04-30 3:25 UTC (permalink / raw)
To: Kiryl Shutsemau
Cc: linux-riscv, akpm, muchun.song, david, willy, usamaarif642, fvdl,
osalvador, rppt, vbabka, lorenzo.stoakes, ziy, bhe, mhocko,
hannes, corbet, chenhuacai, kernel, palmer, paul.walmsley, aou,
alex, kernel-team, linux-mm, linux-kernel, linux-doc, loongarch
In-Reply-To: <20260227193030.272078-5-kas@kernel.org>
Hello:
This patch was applied to riscv/linux.git (fixes)
by Andrew Morton <akpm@linux-foundation.org>:
On Fri, 27 Feb 2026 19:30:06 +0000 you wrote:
> From: Kiryl Shutsemau <kas@kernel.org>
>
> The upcoming change to the HugeTLB vmemmap optimization (HVO) requires
> struct pages of the head page to be naturally aligned with regard to the
> folio size.
>
> Align vmemmap to the newly introduced MAX_FOLIO_VMEMMAP_ALIGN.
>
> [...]
Here is the summary with links:
- [PATCHv7,05/18] riscv/mm: Align vmemmap to maximal folio size
https://git.kernel.org/riscv/c/476849b0fba4
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCHv7 06/18] LoongArch/mm: Align vmemmap to maximal folio size
From: patchwork-bot+linux-riscv @ 2026-04-30 3:25 UTC (permalink / raw)
To: Kiryl Shutsemau
Cc: linux-riscv, akpm, muchun.song, david, willy, usamaarif642, fvdl,
osalvador, rppt, vbabka, lorenzo.stoakes, ziy, bhe, mhocko,
hannes, corbet, chenhuacai, kernel, palmer, paul.walmsley, aou,
alex, kernel-team, linux-mm, linux-kernel, linux-doc, loongarch
In-Reply-To: <20260227193030.272078-6-kas@kernel.org>
Hello:
This patch was applied to riscv/linux.git (fixes)
by Andrew Morton <akpm@linux-foundation.org>:
On Fri, 27 Feb 2026 19:30:07 +0000 you wrote:
> From: Kiryl Shutsemau <kas@kernel.org>
>
> The upcoming change to the HugeTLB vmemmap optimization (HVO) requires
> struct pages of the head page to be naturally aligned with regard to the
> folio size.
>
> Align vmemmap to MAX_FOLIO_VMEMMAP_ALIGN.
>
> [...]
Here is the summary with links:
- [PATCHv7,06/18] LoongArch/mm: Align vmemmap to maximal folio size
https://git.kernel.org/riscv/c/2969b42c8f99
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ 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