* Re: [PATCH v8 23/46] KVM: TDX: Make source page optional for KVM_TDX_INIT_MEM_REGION
From: Yan Zhao @ 2026-06-30 2:09 UTC (permalink / raw)
To: Ackerley Tng
Cc: Sean Christopherson, aik, andrew.jones, binbin.wu, brauner,
chao.p.peng, david, jmattson, jthoughton, michael.roth, oupton,
pankaj.gupta, qperret, rick.p.edgecombe, rientjes, shivankg,
steven.price, tabba, willy, wyihan, forkloop, pratyush,
suzuki.poulose, aneesh.kumar, liam, Paolo Bonzini,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Steven Rostedt, Masami Hiramatsu,
Mathieu Desnoyers, Jonathan Corbet, Shuah Khan, Shuah Khan,
Vishal Annapurve, Andrew Morton, Chris Li, Kairui Song,
Kemeng Shi, Nhat Pham, Barry Song, Axel Rasmussen, Yuanchu Xie,
Wei Xu, Youngjun Park, Qi Zheng, Shakeel Butt, Kiryl Shutsemau,
Baoquan He, Jason Gunthorpe, Vlastimil Babka, kvm, linux-kernel,
linux-trace-kernel, linux-doc, linux-kselftest, linux-mm,
linux-coco
In-Reply-To: <CAEvNRgHO3T6pKDP7ye-RdqbGhAzVC7a=8uBUyaPxwbSuj9khqA@mail.gmail.com>
On Mon, Jun 29, 2026 at 05:00:02PM -0700, Ackerley Tng wrote:
> >> > The original uAPI did not explicitly define 0 as an invalid uaddr. Whether 0 was
> >> > rejected depended on whether the user mmap()'d address 0. If 0 was a valid
> >> > mapping, populate() could proceed.
> >> >
> >> > commit 2a62345b3052 ("KVM: guest_memfd: GUP source pages prior to populating
> >> > guest memory") changed the behavior though. It would return -EOPNOTSUPP for a 0
> >> > uaddr.
> >> >
> >>
> >> I see, I only looked at this after commit 2a62345b3052.
> >>
> >> > But if a user configures 0 uaddr as valid, writes to it, and then passes 0 as
> >> > source_addr(not from gmem), I'm not sure if it's good for the kernel to silently
> >> > treat 0 uaddr as an identifier for in-place copy from the private PFN in gmem.
> >> >
> >>
> >> I'd say the original uAPI perhaps just didn't document 0 as an
> >> unsupported uaddr. Given that commit 2a62345b3052 already merged, uAPI
> >> was perhaps accidentally changed and no customer complained, I think we
> >> can move forward with 0 as an invalid src_address? I wouldn't think
> >> anyone relies on 0 intentionally being a valid address.
> >>
> >> I could document that, if it helps?
> > What about just documenting that 0 is an unsupported uaddr which will be
> > re-purposed as an indicator to use the target pfn as the source, regardless of
> > whether gmem_in_place_conversion is true? i.e.,
> >
> > if (!src_page)
> > src_page = pfn_to_page(pfn);
> >
> > I don't get why the two scenarios should be treated differently:
> > 1. gmem_in_place_conversion==true, shared memory is not from gmem
> > 2. gmem_in_place_conversion==false, shared memory is not from gmem
> >
> > In both case, a 0 uaddr could be mapped to a valid page not from gmem.
>
> This is true, but this check isn't about whether the page is from gmem.
Hmm. TDX's in-place add does not rely on gmem in-place conversion, which means
when gmem_in_place_conversion==false, TDX's in-place add can still be successful.
Since checking gmem_in_place_conversion==true also can't guarantee the share
memory is from gmem, it makes me feel odd to reject scenario 2 while turning
scenario 1 to in-place add.
> > So why not update the uAPI to handle both cases consistently? :)
> >
>
> Wait, but before this series, if region.src_address = 0, src_page = NULL
> and that's not supported so it returns -EOPNOTSUPP.
As in our previous discussion, no customer complaining about the previous change
to -EOPNOTSUPP means no one uses 0 uaddr today.
> If that's dropped, then suddenly if region.src_address = 0 and
> !gmem_in_place_conversion, tdx_gmem_post_populate() will now load the
> memory (zeroed) after [1] into the guest? I don't think we want to
> change that behavior.
>
> I could document that 0 is an unsupported uaddr only for TDX, and only
> when gmem_in_place_conversion = false.
>
> Since it is unsupported only when gmem_in_place_conversion = false, the
> check two lines marked with <<==== can't go away?
>
> if (!src_page) {
> if (!gmem_in_place_conversion) <<====
> return -EOPNOTSUPP; <<====
This rejecting scenario 2.
> src_page = pfn_to_page(pfn);
This turning scenario 1 to in-place add.
> }
>
> Also, for SNP, src_address == 0 is permitted (and desired, I believe, to
> avoid a pointless kernel memcpy) if the type of population is
> KVM_SEV_SNP_PAGE_TYPE_ZERO.
>
> >> >> >> getting pfn" patch, ends up with the guest silently having a zero page?
> >> >> >> I think that would be found quite early in userspace VMM testing...
> >>
> >> [...snip...]
> >>
>
^ permalink raw reply
* Re: [PATCH v8 23/46] KVM: TDX: Make source page optional for KVM_TDX_INIT_MEM_REGION
From: Yan Zhao @ 2026-06-30 2:21 UTC (permalink / raw)
To: Sean Christopherson
Cc: Ackerley Tng, aik@amd.com, andrew.jones@linux.dev,
binbin.wu@linux.intel.com, brauner@kernel.org,
chao.p.peng@linux.intel.com, david@kernel.org,
jmattson@google.com, jthoughton@google.com, michael.roth@amd.com,
oupton@kernel.org, pankaj.gupta@amd.com, qperret@google.com,
Edgecombe, Rick P, rientjes@google.com, shivankg@amd.com,
steven.price@arm.com, tabba@google.com, willy@infradead.org,
wyihan@google.com, forkloop@google.com, pratyush@kernel.org,
suzuki.poulose@arm.com, aneesh.kumar@kernel.org,
liam@infradead.org, Paolo Bonzini, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86@kernel.org, H. Peter Anvin,
Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
Jonathan Corbet, Shuah Khan, Shuah Khan, Annapurve, Vishal,
Andrew Morton, Chris Li, Kairui Song, Kemeng Shi, Nhat Pham,
Barry Song, Axel Rasmussen, Yuanchu Xie, Wei Xu, Youngjun Park,
Qi Zheng, Shakeel Butt, Kiryl Shutsemau, Baoquan He,
Jason Gunthorpe, Vlastimil Babka, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org,
linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org,
linux-mm@kvack.org, linux-coco@lists.linux.dev
In-Reply-To: <akMPZePBdwQlD74H@google.com>
On Tue, Jun 30, 2026 at 08:35:49AM +0800, Sean Christopherson wrote:
> Gah, I thought I had sent this out this morning, long before Ackerley's response.
> But I got distracted by a meeting and forgot to get back to this... *sigh*
>
> Sending what I already wrote, even though there's a lot of overlap with Ackerley's
> mail.
>
> On Mon, Jun 29, 2026, Yan Zhao wrote:
> > On Fri, Jun 26, 2026 at 08:28:32AM -0700, Ackerley Tng wrote:
> > > Yan Zhao <yan.y.zhao@intel.com> writes:
> > > > But if a user configures 0 uaddr as valid, writes to it, and then passes 0 as
> > > > source_addr(not from gmem), I'm not sure if it's good for the kernel to silently
> > > > treat 0 uaddr as an identifier for in-place copy from the private PFN in gmem.
> > > >
> > >
> > > I'd say the original uAPI perhaps just didn't document 0 as an
> > > unsupported uaddr. Given that commit 2a62345b3052 already merged, uAPI
> > > was perhaps accidentally changed and no customer complained, I think we
> > > can move forward with 0 as an invalid src_address? I wouldn't think
> > > anyone relies on 0 intentionally being a valid address.
> > >
> > > I could document that, if it helps?
> > What about just documenting that 0 is an unsupported uaddr which will be
> > re-purposed as an indicator to use the target pfn as the source, regardless of
> > whether gmem_in_place_conversion is true? i.e.,
> >
> > if (!src_page)
> > src_page = pfn_to_page(pfn);
>
> Because KVM can't generally use the target page as the source without in-place
> conversion, it's not supported today, and out-of-place conversion is being
> deprecated.
By "out-of-place conversion", do you mean using per-VM memory attribute
conversion?
> > I don't get why the two scenarios should be treated differently:
> > 1. gmem_in_place_conversion==true, shared memory is not from gmem
> > 2. gmem_in_place_conversion==false, shared memory is not from gmem
> >
> > In both case, a 0 uaddr could be mapped to a valid page not from gmem.
>
> That's immaterial. KVM's ABI (that we're solidifying) is that an address of '0'
> for the source means NULL. The fact that userspace could have a valid mapping
> at virtual address '0' is irrelevant.
So, I'm wondering if we can document that 0 uaddr could always mean using target
PFN.
i.e., for both scenarios 1 and 2, al long as 0 uaddr is specified, we always
use target PFN as source for in-place add.
> Again, just because something is technically possible doesn't mean it needs to
> be supported by every piece of KVM's uAPI.
>
> > So why not update the uAPI to handle both cases consistently? :)
>
> Because retroactively adding support for out-of-place conversion is pointless
> (requires a userspace update for a feature that's being deprecated), KVM can't
> generally support using the source for out-of-place conversion (it's effectively
> an obscure zero-page optimization), and IMO rejecting the out-of-place conversion
> scenario is valuable for KVM developers, e.g. to help newcomers understand what
> exactly is and isn't possible.
Ok. You mean per-VM memory attribute is deprecating, and source page from !gmem
backend is also deprecating, so we don't want to change uAPI for scenarios under
gmem_in_place_conversion==false. Right?
> Side topic, isn't TDX broken if target page has already been added to the TD?
> IIUC, kvm_tdp_mmu_map_private_pfn() will be a glorified nop due to the page
> already having a valid S-EPT mapping, and so KVM will incorrectly allow a double
Not sure if my understand out-of-place conversion correctly.
Given target PFNs and GFNs are not duplicated, what would cause double add? :)
> add. Ahhh, no, because KVM will return RET_PF_SPURIOUS and
> kvm_tdp_mmu_map_private_pfn() will then return -EIO.
My asking was if we could document uaddr always means using target PFN, since
TDX's in-place add does not rely on gmem in-place conversion.
^ permalink raw reply
* [PATCH 0/6] Add support for MAX20830C and MAX20840C step-down DC-DC switching regulator
From: Alexis Czezar Torreno @ 2026-06-30 2:46 UTC (permalink / raw)
To: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jonathan Corbet, Shuah Khan
Cc: linux-hwmon, devicetree, linux-kernel, linux-doc,
Alexis Czezar Torreno
This series adds a few features before adding support to MAX20830C and
MAX20840C.
Patches 1 and 2 adds an enable gpio that should have been included before.
Patches 3 and 4 adds new resistor feedback properties that is needed to
properly scale VOUT
Patches 5 and 6 adds support for devices MAX20830C and MAX20840C.
MAX20830C and MAX20840 are step-down DC-DC switching regulator with PMBus
interface. MAX20830C is a different packaging for MAX20830, and MAX20840C
supports 40A regulation compared to MAX20830 that is only 30A.
Signed-off-by: Alexis Czezar Torreno <alexisczezar.torreno@analog.com>
---
Alexis Czezar Torreno (6):
dt-bindings: hwmon: (pmbus/max20830): add enable-gpios property
hwmon: (pmbus/max20830): add support for enable GPIO
dt-bindings: hwmon: (pmbus/max20830): add VOUT feedback resistor properties
hwmon: (pmbus/max20830): add VOUT feedback resistor scaling support
dt-bindings: hwmon: (pmbus/max20830): add max20830c and max20840c support
hwmon: (pmbus/max20830): add support for max20830c and max20840c
.../bindings/hwmon/pmbus/adi,max20830.yaml | 30 +++++-
Documentation/hwmon/max20830.rst | 27 ++++-
drivers/hwmon/pmbus/max20830.c | 117 +++++++++++++++++----
3 files changed, 148 insertions(+), 26 deletions(-)
---
base-commit: 1a42625604046790ea8ec61c2a749bbf76b28943
change-id: 20260630-dev-max20830c-9d38d8b0a765
Best regards,
--
Alexis Czezar Torreno <alexisczezar.torreno@analog.com>
^ permalink raw reply
* [PATCH 1/6] dt-bindings: hwmon: (pmbus/max20830): add enable-gpios property
From: Alexis Czezar Torreno @ 2026-06-30 2:46 UTC (permalink / raw)
To: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jonathan Corbet, Shuah Khan
Cc: linux-hwmon, devicetree, linux-kernel, linux-doc,
Alexis Czezar Torreno
In-Reply-To: <20260630-dev-max20830c-v1-0-a02786bde470@analog.com>
Adding a missing entry for the MAX20830 EN (enable) pin.
Signed-off-by: Alexis Czezar Torreno <alexisczezar.torreno@analog.com>
---
Documentation/devicetree/bindings/hwmon/pmbus/adi,max20830.yaml | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/hwmon/pmbus/adi,max20830.yaml b/Documentation/devicetree/bindings/hwmon/pmbus/adi,max20830.yaml
index 1625dd59417f1b3ca689a9c86ca266da913d1217..ab8f6324866f29de8c66c3c63300845b2e02207e 100644
--- a/Documentation/devicetree/bindings/hwmon/pmbus/adi,max20830.yaml
+++ b/Documentation/devicetree/bindings/hwmon/pmbus/adi,max20830.yaml
@@ -39,6 +39,11 @@ properties:
description:
Optional 2.5V to 5.5V LDO input supply.
+ enable-gpios:
+ description:
+ GPIO connected to the EN (enable) pin.
+ maxItems: 1
+
pwr-good-gpios:
description:
GPIO connected to the power-good status output pin.
--
2.34.1
^ permalink raw reply related
* [PATCH 2/6] hwmon: (pmbus/max20830): add support for enable GPIO
From: Alexis Czezar Torreno @ 2026-06-30 2:46 UTC (permalink / raw)
To: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jonathan Corbet, Shuah Khan
Cc: linux-hwmon, devicetree, linux-kernel, linux-doc,
Alexis Czezar Torreno
In-Reply-To: <20260630-dev-max20830c-v1-0-a02786bde470@analog.com>
Add support for the GPIO controlled EN pin. The EN pin is asserted high
for device to operate.
Signed-off-by: Alexis Czezar Torreno <alexisczezar.torreno@analog.com>
---
drivers/hwmon/pmbus/max20830.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/hwmon/pmbus/max20830.c b/drivers/hwmon/pmbus/max20830.c
index cb2c23672166d641852199ca07eb716924f4f286..cb3a39d747edee3aefb0fb4051ef957436b3c15b 100644
--- a/drivers/hwmon/pmbus/max20830.c
+++ b/drivers/hwmon/pmbus/max20830.c
@@ -6,6 +6,7 @@
*/
#include <linux/errno.h>
+#include <linux/gpio/consumer.h>
#include <linux/i2c.h>
#include <linux/mod_devicetable.h>
#include <linux/module.h>
@@ -29,8 +30,14 @@ static struct pmbus_driver_info max20830_info = {
static int max20830_probe(struct i2c_client *client)
{
u8 buf[I2C_SMBUS_BLOCK_MAX + 1] = {};
+ struct gpio_desc *enable_gpio;
int ret;
+ enable_gpio = devm_gpiod_get_optional(&client->dev, "enable", GPIOD_OUT_HIGH);
+ if (IS_ERR(enable_gpio))
+ return dev_err_probe(&client->dev, PTR_ERR(enable_gpio),
+ "Failed to get enable GPIO\n");
+
if (!i2c_check_functionality(client->adapter, I2C_FUNC_SMBUS_READ_BLOCK_DATA) &&
!i2c_check_functionality(client->adapter, I2C_FUNC_SMBUS_READ_I2C_BLOCK))
return -ENODEV;
--
2.34.1
^ permalink raw reply related
* [PATCH 3/6] dt-bindings: hwmon: (pmbus/max20830): add VOUT feedback resistor properties
From: Alexis Czezar Torreno @ 2026-06-30 2:46 UTC (permalink / raw)
To: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jonathan Corbet, Shuah Khan
Cc: linux-hwmon, devicetree, linux-kernel, linux-doc,
Alexis Czezar Torreno
In-Reply-To: <20260630-dev-max20830c-v1-0-a02786bde470@analog.com>
Add adi,vout-rfb1-ohms and adi,vout-rfb2-ohms properties to support
external voltage divider configuration for VOUT sensing. When the
desired output voltage is higher than VREF, a resistor divider (RFB1
and RFB2) is required to reach the intended value.
The properties use a dependency constraint to ensure both resistors
are specified together, or neither. This prevents misconfiguration
where only one resistor value is provided.
Signed-off-by: Alexis Czezar Torreno <alexisczezar.torreno@analog.com>
---
.../devicetree/bindings/hwmon/pmbus/adi,max20830.yaml | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/Documentation/devicetree/bindings/hwmon/pmbus/adi,max20830.yaml b/Documentation/devicetree/bindings/hwmon/pmbus/adi,max20830.yaml
index ab8f6324866f29de8c66c3c63300845b2e02207e..caedad40bc592c8489df235f02c6ff051070cb1e 100644
--- a/Documentation/devicetree/bindings/hwmon/pmbus/adi,max20830.yaml
+++ b/Documentation/devicetree/bindings/hwmon/pmbus/adi,max20830.yaml
@@ -49,11 +49,26 @@ properties:
GPIO connected to the power-good status output pin.
maxItems: 1
+ adi,vout-rfb1-ohms:
+ description:
+ Top feedback resistor (RFB1) value in ohms for VOUT sensing divider.
+ When the desired output voltage is higher than VREF, a resistor divider
+ is required. VOUT = VREF × (1 + RFB1/RFB2)
+
+ adi,vout-rfb2-ohms:
+ description:
+ Bottom feedback resistor (RFB2) value in ohms for VOUT sensing divider.
+ Datasheet recommends that RFB2 does not exceed 2.5kΩ.
+
required:
- compatible
- reg
- vddh-supply
+dependencies:
+ adi,vout-rfb1-ohms: ['adi,vout-rfb2-ohms']
+ adi,vout-rfb2-ohms: ['adi,vout-rfb1-ohms']
+
unevaluatedProperties: false
examples:
@@ -66,6 +81,8 @@ examples:
compatible = "adi,max20830";
reg = <0x30>;
vddh-supply = <&vddh>;
+ adi,vout-rfb1-ohms = <10000>;
+ adi,vout-rfb2-ohms = <2000>;
};
};
...
--
2.34.1
^ permalink raw reply related
* [PATCH 4/6] hwmon: (pmbus/max20830): add VOUT feedback resistor scaling support
From: Alexis Czezar Torreno @ 2026-06-30 2:46 UTC (permalink / raw)
To: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jonathan Corbet, Shuah Khan
Cc: linux-hwmon, devicetree, linux-kernel, linux-doc,
Alexis Czezar Torreno
In-Reply-To: <20260630-dev-max20830c-v1-0-a02786bde470@analog.com>
Implement support for external voltage divider scaling using the
adi,vout-rfb1-ohms and adi,vout-rfb2-ohms device tree properties.
When the desired output voltage exceeds VREF, a resistor divider
(RFB1 and RFB2) is used to scale down the feedback voltage. The
driver reads these resistor values from device tree and applies
the scaling formula: VOUT_actual = VOUT_measured × (1 + RFB1/RFB2)
The properties are optional. If not specified, the driver assumes
no voltage divider is present and reports the raw VOUT reading.
Signed-off-by: Alexis Czezar Torreno <alexisczezar.torreno@analog.com>
---
drivers/hwmon/pmbus/max20830.c | 42 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 42 insertions(+)
diff --git a/drivers/hwmon/pmbus/max20830.c b/drivers/hwmon/pmbus/max20830.c
index cb3a39d747edee3aefb0fb4051ef957436b3c15b..a3abd24437e8e7560264aad55fc4f456d30ae235 100644
--- a/drivers/hwmon/pmbus/max20830.c
+++ b/drivers/hwmon/pmbus/max20830.c
@@ -8,6 +8,7 @@
#include <linux/errno.h>
#include <linux/gpio/consumer.h>
#include <linux/i2c.h>
+#include <linux/math64.h>
#include <linux/mod_devicetable.h>
#include <linux/module.h>
#include <linux/string.h>
@@ -15,6 +16,35 @@
#define MAX20830_IC_DEVICE_ID_LENGTH 9
+struct max20830_data {
+ struct pmbus_driver_info info;
+ u32 vout_rfb1;
+ u32 vout_rfb2;
+};
+
+static int max20830_read_word_data(struct i2c_client *client, int page,
+ int phase, int reg)
+{
+ const struct pmbus_driver_info *info = pmbus_get_driver_info(client);
+ const struct max20830_data *data = container_of(info, struct max20830_data, info);
+ int ret;
+
+ switch (reg) {
+ case PMBUS_READ_VOUT:
+ ret = pmbus_read_word_data(client, page, phase, reg);
+ if (ret < 0)
+ return ret;
+
+ /* Apply voltage divider scaling if resistors are non-zero */
+ if (data->vout_rfb1 && data->vout_rfb2)
+ ret = DIV_ROUND_CLOSEST_ULL((u64)ret * (data->vout_rfb1 +
+ data->vout_rfb2), data->vout_rfb2);
+ return ret;
+ default:
+ return -ENODATA;
+ }
+}
+
static struct pmbus_driver_info max20830_info = {
.pages = 1,
.format[PSC_VOLTAGE_IN] = linear,
@@ -25,14 +55,26 @@ static struct pmbus_driver_info max20830_info = {
PMBUS_HAVE_TEMP |
PMBUS_HAVE_STATUS_VOUT | PMBUS_HAVE_STATUS_IOUT |
PMBUS_HAVE_STATUS_INPUT | PMBUS_HAVE_STATUS_TEMP,
+ .read_word_data = max20830_read_word_data,
};
static int max20830_probe(struct i2c_client *client)
{
u8 buf[I2C_SMBUS_BLOCK_MAX + 1] = {};
+ struct max20830_data *data;
struct gpio_desc *enable_gpio;
int ret;
+ data = devm_kzalloc(&client->dev, sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ data->info = max20830_info;
+
+ /* Read optional voltage divider resistor values */
+ device_property_read_u32(&client->dev, "adi,vout-rfb1-ohms", &data->vout_rfb1);
+ device_property_read_u32(&client->dev, "adi,vout-rfb2-ohms", &data->vout_rfb2);
+
enable_gpio = devm_gpiod_get_optional(&client->dev, "enable", GPIOD_OUT_HIGH);
if (IS_ERR(enable_gpio))
return dev_err_probe(&client->dev, PTR_ERR(enable_gpio),
--
2.34.1
^ permalink raw reply related
* [PATCH 5/6] dt-bindings: hwmon: (pmbus/max20830): add max20830c and max20840c support
From: Alexis Czezar Torreno @ 2026-06-30 2:46 UTC (permalink / raw)
To: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jonathan Corbet, Shuah Khan
Cc: linux-hwmon, devicetree, linux-kernel, linux-doc,
Alexis Czezar Torreno
In-Reply-To: <20260630-dev-max20830c-v1-0-a02786bde470@analog.com>
Add compatible strings for variants of MAX20830 which are MAX20830C
and MAX20840C. These devices have the same register functionality with
MAX20830 but with a longer IC_DEVICE_ID.
Signed-off-by: Alexis Czezar Torreno <alexisczezar.torreno@analog.com>
---
Documentation/devicetree/bindings/hwmon/pmbus/adi,max20830.yaml | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/hwmon/pmbus/adi,max20830.yaml b/Documentation/devicetree/bindings/hwmon/pmbus/adi,max20830.yaml
index caedad40bc592c8489df235f02c6ff051070cb1e..b8ca8ec0446fae2a16484e5ff8f1bb563cdb2405 100644
--- a/Documentation/devicetree/bindings/hwmon/pmbus/adi,max20830.yaml
+++ b/Documentation/devicetree/bindings/hwmon/pmbus/adi,max20830.yaml
@@ -22,7 +22,13 @@ allOf:
properties:
compatible:
- const: adi,max20830
+ oneOf:
+ - const: adi,max20830
+ - items:
+ - enum:
+ - adi,max20830c
+ - adi,max20840c
+ - const: adi,max20830 # Fallback compatible
reg:
maxItems: 1
--
2.34.1
^ permalink raw reply related
* [PATCH 6/6] hwmon: (pmbus/max20830): add support for max20830c and max20840c
From: Alexis Czezar Torreno @ 2026-06-30 2:46 UTC (permalink / raw)
To: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jonathan Corbet, Shuah Khan
Cc: linux-hwmon, devicetree, linux-kernel, linux-doc,
Alexis Czezar Torreno
In-Reply-To: <20260630-dev-max20830c-v1-0-a02786bde470@analog.com>
Add support for MAX20830C and MAX20840 step-down DC-DC switching
regulator with PMBus interface. MAX20830C is a different packaging
for MAX20830, and MAX20840C supports 40A regulation compared to
MAX20830 that is only 30A.
Signed-off-by: Alexis Czezar Torreno <alexisczezar.torreno@analog.com>
---
Documentation/hwmon/max20830.rst | 27 +++++++++++++---
drivers/hwmon/pmbus/max20830.c | 68 ++++++++++++++++++++++++++++------------
2 files changed, 70 insertions(+), 25 deletions(-)
diff --git a/Documentation/hwmon/max20830.rst b/Documentation/hwmon/max20830.rst
index 936e409dcc5c0898dde27d782308d4a7e1357e73..b850f3b6e40d1f1d0cec944be40af02265aced59 100644
--- a/Documentation/hwmon/max20830.rst
+++ b/Documentation/hwmon/max20830.rst
@@ -13,6 +13,22 @@ Supported chips:
Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/max20830.pdf
+ * Analog Devices MAX20830C
+
+ Prefix: 'max20830c'
+
+ Addresses scanned: -
+
+ Datasheet:
+
+ * Analog Devices MAX20840C
+
+ Prefix: 'max20840c'
+
+ Addresses scanned: -
+
+ Datasheet:
+
Author:
- Alexis Czezar Torreno <alexisczezar.torreno@analog.com>
@@ -21,12 +37,13 @@ Author:
Description
-----------
-This driver supports hardware monitoring for Analog Devices MAX20830
-Step-Down Switching Regulator with PMBus Interface.
+This driver supports hardware monitoring for Analog Devices MAX20830, MAX20830C
+and MAX20840C. These are Step-Down Switching Regulator with PMBus Interface.
-The MAX20830 is a 2.7V to 16V, 30A fully integrated step-down DC-DC switching
-regulator. Through the PMBus interface, the device can monitor input/output
-voltages, output current and temperature.
+MAX20830, and MAX20830C are 2.7V to 16V, 30A fully integrated step-down DC-DC
+switching regulators. MAX20840C is similar but can reach 40A. Through the PMBus
+interface, these devices can monitor input/output voltages, output current and
+temperature.
The driver is a client driver to the core PMBus driver. Please see
Documentation/hwmon/pmbus.rst for details on PMBus client drivers.
diff --git a/drivers/hwmon/pmbus/max20830.c b/drivers/hwmon/pmbus/max20830.c
index a3abd24437e8e7560264aad55fc4f456d30ae235..252c77beb243c5a2d90fcf96941605ff31439383 100644
--- a/drivers/hwmon/pmbus/max20830.c
+++ b/drivers/hwmon/pmbus/max20830.c
@@ -14,7 +14,30 @@
#include <linux/string.h>
#include "pmbus.h"
-#define MAX20830_IC_DEVICE_ID_LENGTH 9
+struct max20830_chip_info {
+ const char *id_str;
+ u8 id_length;
+};
+
+static const struct max20830_chip_info max20830_chip = {
+ /*
+ * MAX20830 IC_DEVICE_ID has a byte length of 9 despite being an 8
+ * character string, as it includes a null terminator. The other
+ * devices do not include null.
+ */
+ .id_str = "MAX20830\0",
+ .id_length = 9,
+};
+
+static const struct max20830_chip_info max20830c_chip = {
+ .id_str = "MAX20830C",
+ .id_length = 9,
+};
+
+static const struct max20830_chip_info max20840c_chip = {
+ .id_str = "MAX20840C",
+ .id_length = 9,
+};
struct max20830_data {
struct pmbus_driver_info info;
@@ -60,11 +83,14 @@ static struct pmbus_driver_info max20830_info = {
static int max20830_probe(struct i2c_client *client)
{
+ const struct max20830_chip_info *chip;
u8 buf[I2C_SMBUS_BLOCK_MAX + 1] = {};
struct max20830_data *data;
struct gpio_desc *enable_gpio;
int ret;
+ chip = i2c_get_match_data(client);
+
data = devm_kzalloc(&client->dev, sizeof(*data), GFP_KERNEL);
if (!data)
return -ENOMEM;
@@ -90,16 +116,14 @@ static int max20830_probe(struct i2c_client *client)
* which do not support SMBus block reads.
*/
if (i2c_check_functionality(client->adapter, I2C_FUNC_SMBUS_READ_BLOCK_DATA)) {
- /* Reads 9 Data bytes from MAX20830 */
ret = i2c_smbus_read_block_data(client, PMBUS_IC_DEVICE_ID, buf);
if (ret < 0)
return dev_err_probe(&client->dev, ret,
"Failed to read IC_DEVICE_ID\n");
} else {
- /* Reads 1 length byte + 9 Data bytes from MAX20830 */
+ /* Reads 1 length byte + data bytes */
ret = i2c_smbus_read_i2c_block_data(client, PMBUS_IC_DEVICE_ID,
- MAX20830_IC_DEVICE_ID_LENGTH + 1,
- buf);
+ chip->id_length + 1, buf);
if (ret < 0)
return dev_err_probe(&client->dev, ret,
"Failed to read IC_DEVICE_ID\n");
@@ -108,36 +132,40 @@ static int max20830_probe(struct i2c_client *client)
* match the format of i2c_smbus_read_block_data().
* Also adjust return value to reflect length byte removal.
*/
- memmove(buf, buf + 1, MAX20830_IC_DEVICE_ID_LENGTH);
+ memmove(buf, buf + 1, chip->id_length);
ret = ret - 1;
}
- /*
- * MAX20830 IC_DEVICE_ID sends string data "MAX20830\0".
- * Return value should at least be 9 bytes of data.
- */
- if (ret < MAX20830_IC_DEVICE_ID_LENGTH)
+ /* Verify we read the expected number of bytes */
+ if (ret < chip->id_length)
return dev_err_probe(&client->dev, -ENODEV,
- "IC_DEVICE_ID too short: expected at least 9 bytes, got %d\n",
- ret);
+ "IC_DEVICE_ID too short: expected %d bytes, got %d\n",
+ chip->id_length, ret);
+
+ /* Null-terminate the string */
+ buf[chip->id_length] = '\0';
- /* 9 bytes of data, buf[0]-buf[7] = "MAX20830", buf[8] = '\0' */
- buf[MAX20830_IC_DEVICE_ID_LENGTH - 1] = '\0';
- if (strncmp(buf, "MAX20830", MAX20830_IC_DEVICE_ID_LENGTH - 1))
+ /* Verify the device ID matches what we expect */
+ if (strncmp(buf, chip->id_str, chip->id_length))
return dev_err_probe(&client->dev, -ENODEV,
- "Unsupported device: '%s'\n", buf);
+ "Device mismatch: expected '%s', got '%s'\n",
+ chip->id_str, buf);
- return pmbus_do_probe(client, &max20830_info);
+ return pmbus_do_probe(client, &data->info);
}
static const struct i2c_device_id max20830_id[] = {
- {"max20830"},
+ { "max20830", (kernel_ulong_t)&max20830_chip },
+ { "max20830c", (kernel_ulong_t)&max20830c_chip },
+ { "max20840c", (kernel_ulong_t)&max20840c_chip },
{ }
};
MODULE_DEVICE_TABLE(i2c, max20830_id);
static const struct of_device_id max20830_of_match[] = {
- { .compatible = "adi,max20830" },
+ { .compatible = "adi,max20830", .data = &max20830_chip },
+ { .compatible = "adi,max20830c", .data = &max20830c_chip },
+ { .compatible = "adi,max20840c", .data = &max20840c_chip },
{ }
};
MODULE_DEVICE_TABLE(of, max20830_of_match);
--
2.34.1
^ permalink raw reply related
* Re: [PATCH 6/6] hwmon: (pmbus/max20830): add support for max20830c and max20840c
From: Guenter Roeck @ 2026-06-30 3:43 UTC (permalink / raw)
To: Alexis Czezar Torreno, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jonathan Corbet, Shuah Khan
Cc: linux-hwmon, devicetree, linux-kernel, linux-doc
In-Reply-To: <20260630-dev-max20830c-v1-6-a02786bde470@analog.com>
On 6/29/26 19:46, Alexis Czezar Torreno wrote:
> Add support for MAX20830C and MAX20840 step-down DC-DC switching
> regulator with PMBus interface. MAX20830C is a different packaging
> for MAX20830, and MAX20840C supports 40A regulation compared to
> MAX20830 that is only 30A.
>
> Signed-off-by: Alexis Czezar Torreno <alexisczezar.torreno@analog.com>
> ---
> Documentation/hwmon/max20830.rst | 27 +++++++++++++---
> drivers/hwmon/pmbus/max20830.c | 68 ++++++++++++++++++++++++++++------------
> 2 files changed, 70 insertions(+), 25 deletions(-)
>
> diff --git a/Documentation/hwmon/max20830.rst b/Documentation/hwmon/max20830.rst
> index 936e409dcc5c0898dde27d782308d4a7e1357e73..b850f3b6e40d1f1d0cec944be40af02265aced59 100644
> --- a/Documentation/hwmon/max20830.rst
> +++ b/Documentation/hwmon/max20830.rst
> @@ -13,6 +13,22 @@ Supported chips:
>
> Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/max20830.pdf
>
> + * Analog Devices MAX20830C
> +
> + Prefix: 'max20830c'
> +
> + Addresses scanned: -
> +
> + Datasheet:
> +
> + * Analog Devices MAX20840C
> +
> + Prefix: 'max20840c'
> +
> + Addresses scanned: -
> +
> + Datasheet:
> +
> Author:
>
> - Alexis Czezar Torreno <alexisczezar.torreno@analog.com>
> @@ -21,12 +37,13 @@ Author:
> Description
> -----------
>
> -This driver supports hardware monitoring for Analog Devices MAX20830
> -Step-Down Switching Regulator with PMBus Interface.
> +This driver supports hardware monitoring for Analog Devices MAX20830, MAX20830C
> +and MAX20840C. These are Step-Down Switching Regulator with PMBus Interface.
>
> -The MAX20830 is a 2.7V to 16V, 30A fully integrated step-down DC-DC switching
> -regulator. Through the PMBus interface, the device can monitor input/output
> -voltages, output current and temperature.
> +MAX20830, and MAX20830C are 2.7V to 16V, 30A fully integrated step-down DC-DC
> +switching regulators. MAX20840C is similar but can reach 40A. Through the PMBus
> +interface, these devices can monitor input/output voltages, output current and
> +temperature.
>
> The driver is a client driver to the core PMBus driver. Please see
> Documentation/hwmon/pmbus.rst for details on PMBus client drivers.
> diff --git a/drivers/hwmon/pmbus/max20830.c b/drivers/hwmon/pmbus/max20830.c
> index a3abd24437e8e7560264aad55fc4f456d30ae235..252c77beb243c5a2d90fcf96941605ff31439383 100644
> --- a/drivers/hwmon/pmbus/max20830.c
> +++ b/drivers/hwmon/pmbus/max20830.c
> @@ -14,7 +14,30 @@
> #include <linux/string.h>
> #include "pmbus.h"
>
> -#define MAX20830_IC_DEVICE_ID_LENGTH 9
> +struct max20830_chip_info {
> + const char *id_str;
> + u8 id_length;
> +};
> +
> +static const struct max20830_chip_info max20830_chip = {
> + /*
> + * MAX20830 IC_DEVICE_ID has a byte length of 9 despite being an 8
> + * character string, as it includes a null terminator. The other
> + * devices do not include null.
> + */
> + .id_str = "MAX20830\0",
> + .id_length = 9,
> +};
> +
> +static const struct max20830_chip_info max20830c_chip = {
> + .id_str = "MAX20830C",
> + .id_length = 9,
> +};
> +
> +static const struct max20830_chip_info max20840c_chip = {
> + .id_str = "MAX20840C",
> + .id_length = 9,
> +};
>
> struct max20830_data {
> struct pmbus_driver_info info;
> @@ -60,11 +83,14 @@ static struct pmbus_driver_info max20830_info = {
>
> static int max20830_probe(struct i2c_client *client)
> {
> + const struct max20830_chip_info *chip;
> u8 buf[I2C_SMBUS_BLOCK_MAX + 1] = {};
> struct max20830_data *data;
> struct gpio_desc *enable_gpio;
> int ret;
>
> + chip = i2c_get_match_data(client);
> +
> data = devm_kzalloc(&client->dev, sizeof(*data), GFP_KERNEL);
> if (!data)
> return -ENOMEM;
> @@ -90,16 +116,14 @@ static int max20830_probe(struct i2c_client *client)
> * which do not support SMBus block reads.
> */
> if (i2c_check_functionality(client->adapter, I2C_FUNC_SMBUS_READ_BLOCK_DATA)) {
> - /* Reads 9 Data bytes from MAX20830 */
> ret = i2c_smbus_read_block_data(client, PMBUS_IC_DEVICE_ID, buf);
> if (ret < 0)
> return dev_err_probe(&client->dev, ret,
> "Failed to read IC_DEVICE_ID\n");
> } else {
> - /* Reads 1 length byte + 9 Data bytes from MAX20830 */
> + /* Reads 1 length byte + data bytes */
> ret = i2c_smbus_read_i2c_block_data(client, PMBUS_IC_DEVICE_ID,
> - MAX20830_IC_DEVICE_ID_LENGTH + 1,
> - buf);
> + chip->id_length + 1, buf);
> if (ret < 0)
> return dev_err_probe(&client->dev, ret,
> "Failed to read IC_DEVICE_ID\n");
> @@ -108,36 +132,40 @@ static int max20830_probe(struct i2c_client *client)
> * match the format of i2c_smbus_read_block_data().
> * Also adjust return value to reflect length byte removal.
> */
> - memmove(buf, buf + 1, MAX20830_IC_DEVICE_ID_LENGTH);
> + memmove(buf, buf + 1, chip->id_length);
> ret = ret - 1;
> }
>
> - /*
> - * MAX20830 IC_DEVICE_ID sends string data "MAX20830\0".
> - * Return value should at least be 9 bytes of data.
> - */
> - if (ret < MAX20830_IC_DEVICE_ID_LENGTH)
> + /* Verify we read the expected number of bytes */
> + if (ret < chip->id_length)
> return dev_err_probe(&client->dev, -ENODEV,
> - "IC_DEVICE_ID too short: expected at least 9 bytes, got %d\n",
> - ret);
> + "IC_DEVICE_ID too short: expected %d bytes, got %d\n",
> + chip->id_length, ret);
> +
> + /* Null-terminate the string */
> + buf[chip->id_length] = '\0';
>
> - /* 9 bytes of data, buf[0]-buf[7] = "MAX20830", buf[8] = '\0' */
> - buf[MAX20830_IC_DEVICE_ID_LENGTH - 1] = '\0';
> - if (strncmp(buf, "MAX20830", MAX20830_IC_DEVICE_ID_LENGTH - 1))
> + /* Verify the device ID matches what we expect */
> + if (strncmp(buf, chip->id_str, chip->id_length))
> return dev_err_probe(&client->dev, -ENODEV,
> - "Unsupported device: '%s'\n", buf);
> + "Device mismatch: expected '%s', got '%s'\n",
> + chip->id_str, buf);
>
> - return pmbus_do_probe(client, &max20830_info);
> + return pmbus_do_probe(client, &data->info);
> }
>
> static const struct i2c_device_id max20830_id[] = {
> - {"max20830"},
> + { "max20830", (kernel_ulong_t)&max20830_chip },
> + { "max20830c", (kernel_ulong_t)&max20830c_chip },
> + { "max20840c", (kernel_ulong_t)&max20840c_chip },
> { }
> };
> MODULE_DEVICE_TABLE(i2c, max20830_id);
>
> static const struct of_device_id max20830_of_match[] = {
> - { .compatible = "adi,max20830" },
> + { .compatible = "adi,max20830", .data = &max20830_chip },
> + { .compatible = "adi,max20830c", .data = &max20830c_chip },
> + { .compatible = "adi,max20840c", .data = &max20840c_chip },
"adi,max20830" is a fallback for the other two chips, but that
is not how the code is implemented.
Guenter
> { }
> };
> MODULE_DEVICE_TABLE(of, max20830_of_match);
>
^ permalink raw reply
* Re: [PATCH 2/6] hwmon: (pmbus/max20830): add support for enable GPIO
From: Guenter Roeck @ 2026-06-30 3:50 UTC (permalink / raw)
To: Alexis Czezar Torreno, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jonathan Corbet, Shuah Khan
Cc: linux-hwmon, devicetree, linux-kernel, linux-doc
In-Reply-To: <20260630-dev-max20830c-v1-2-a02786bde470@analog.com>
On 6/29/26 19:46, Alexis Czezar Torreno wrote:
> Add support for the GPIO controlled EN pin. The EN pin is asserted high
> for device to operate.
>
> Signed-off-by: Alexis Czezar Torreno <alexisczezar.torreno@analog.com>
> ---
> drivers/hwmon/pmbus/max20830.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/hwmon/pmbus/max20830.c b/drivers/hwmon/pmbus/max20830.c
> index cb2c23672166d641852199ca07eb716924f4f286..cb3a39d747edee3aefb0fb4051ef957436b3c15b 100644
> --- a/drivers/hwmon/pmbus/max20830.c
> +++ b/drivers/hwmon/pmbus/max20830.c
> @@ -6,6 +6,7 @@
> */
>
> #include <linux/errno.h>
> +#include <linux/gpio/consumer.h>
> #include <linux/i2c.h>
> #include <linux/mod_devicetable.h>
> #include <linux/module.h>
> @@ -29,8 +30,14 @@ static struct pmbus_driver_info max20830_info = {
> static int max20830_probe(struct i2c_client *client)
> {
> u8 buf[I2C_SMBUS_BLOCK_MAX + 1] = {};
> + struct gpio_desc *enable_gpio;
> int ret;
>
> + enable_gpio = devm_gpiod_get_optional(&client->dev, "enable", GPIOD_OUT_HIGH);
> + if (IS_ERR(enable_gpio))
> + return dev_err_probe(&client->dev, PTR_ERR(enable_gpio),
> + "Failed to get enable GPIO\n");
> +
The above code gets the gpio reference, and then it doesn't do anything
with it. What exactly is the point of this exercise ? Where is the
chip actually enabled ?
Do you have an actual customer with such a set-up or is this
"just in case" ? Have you tested this code to ensure that the chip
is actually enabled in this setup ?
If there is indeed a use case where a customer indeed connects the
enable pin to a gpio output, wouldn't that same customer also want
to connect the "pgood" output to a gpio pin ? And what about
the LDOIN pin ? Shouldn't that be connected to a power supply ?
Guenter
^ permalink raw reply
* Re: [PATCH 2/6] hwmon: (pmbus/max20830): add support for enable GPIO
From: Guenter Roeck @ 2026-06-30 4:51 UTC (permalink / raw)
To: Alexis Czezar Torreno, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jonathan Corbet, Shuah Khan
Cc: linux-hwmon, devicetree, linux-kernel, linux-doc
In-Reply-To: <836b833e-e503-4cbb-92f7-3574f3fb430f@roeck-us.net>
On 6/29/26 20:50, Guenter Roeck wrote:
> On 6/29/26 19:46, Alexis Czezar Torreno wrote:
>> Add support for the GPIO controlled EN pin. The EN pin is asserted high
>> for device to operate.
>>
>> Signed-off-by: Alexis Czezar Torreno <alexisczezar.torreno@analog.com>
>> ---
>> drivers/hwmon/pmbus/max20830.c | 7 +++++++
>> 1 file changed, 7 insertions(+)
>>
>> diff --git a/drivers/hwmon/pmbus/max20830.c b/drivers/hwmon/pmbus/max20830.c
>> index cb2c23672166d641852199ca07eb716924f4f286..cb3a39d747edee3aefb0fb4051ef957436b3c15b 100644
>> --- a/drivers/hwmon/pmbus/max20830.c
>> +++ b/drivers/hwmon/pmbus/max20830.c
>> @@ -6,6 +6,7 @@
>> */
>> #include <linux/errno.h>
>> +#include <linux/gpio/consumer.h>
>> #include <linux/i2c.h>
>> #include <linux/mod_devicetable.h>
>> #include <linux/module.h>
>> @@ -29,8 +30,14 @@ static struct pmbus_driver_info max20830_info = {
>> static int max20830_probe(struct i2c_client *client)
>> {
>> u8 buf[I2C_SMBUS_BLOCK_MAX + 1] = {};
>> + struct gpio_desc *enable_gpio;
>> int ret;
>> + enable_gpio = devm_gpiod_get_optional(&client->dev, "enable", GPIOD_OUT_HIGH);
>> + if (IS_ERR(enable_gpio))
>> + return dev_err_probe(&client->dev, PTR_ERR(enable_gpio),
>> + "Failed to get enable GPIO\n");
>> +
>
> The above code gets the gpio reference, and then it doesn't do anything
> with it. What exactly is the point of this exercise ? Where is the
> chip actually enabled ?
>
> Do you have an actual customer with such a set-up or is this
> "just in case" ? Have you tested this code to ensure that the chip
> is actually enabled in this setup ?
>
Also, please explain the need in detail, especially in the context of
PMBus command 0x02 (ON_OFF_CONFIG) which can be used to configure
the pin functionality. Specifically, what would be the point of
trying to force-enable the chip if on-off-config happens to be set
to 0x1b (ignore EN pin and require OPERATION = 0x80) ?
And if ON_OFF_CONFIG happens to be set to 0x17 (Ignore OPERATION
command), why not just set it to 0x1b and override EN ?
In other words, I expect the use case to be explained in the context
of the ON_OFF_CONFIG and OPERATION commands. "The EN pin is asserted
high for device to operate" is misleading and only half-true since that
is only the case if the chip is configured to actually use it (which,
I notice, you are not doing here).
Thanks,
Guenter
> If there is indeed a use case where a customer indeed connects the
> enable pin to a gpio output, wouldn't that same customer also want
> to connect the "pgood" output to a gpio pin ? And what about
> the LDOIN pin ? Shouldn't that be connected to a power supply ?
>
> Guenter
>
>
^ permalink raw reply
* Re: [PATCH 4/6] hwmon: (pmbus/max20830): add VOUT feedback resistor scaling support
From: Guenter Roeck @ 2026-06-30 4:53 UTC (permalink / raw)
To: Alexis Czezar Torreno, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jonathan Corbet, Shuah Khan
Cc: linux-hwmon, devicetree, linux-kernel, linux-doc
In-Reply-To: <20260630-dev-max20830c-v1-4-a02786bde470@analog.com>
On 6/29/26 19:46, Alexis Czezar Torreno wrote:
> Implement support for external voltage divider scaling using the
> adi,vout-rfb1-ohms and adi,vout-rfb2-ohms device tree properties.
>
> When the desired output voltage exceeds VREF, a resistor divider
> (RFB1 and RFB2) is used to scale down the feedback voltage. The
> driver reads these resistor values from device tree and applies
> the scaling formula: VOUT_actual = VOUT_measured × (1 + RFB1/RFB2)
>
> The properties are optional. If not specified, the driver assumes
> no voltage divider is present and reports the raw VOUT reading.
>
This will require a detailed explanation why only PMBUS_READ_VOUT
would require scaling but not any of the other vout related commands.
Guenter
^ permalink raw reply
* htmldocs: Documentation/ABI/testing/sysfs-class-power-rt9471:1: WARNING: Inline emphasis start-string without end-string. [docutils]
From: kernel test robot @ 2026-06-30 5:00 UTC (permalink / raw)
To: Waqar Hameed; +Cc: oe-kbuild-all, 0day robot, linux-doc
tree: https://github.com/intel-lab-lkp/linux/commits/Waqar-Hameed/power-supply-Add-sysfs-entry-for-system-load-control/20260629-235714
head: 7f627c0c3f8b6254753610a05254e70cd6a2032d
commit: fad2c985b1a8f0d628768cd211f4afe3cb39e9d2 power: supply: rt9471: Use POWER_SUPPLY_PROP_LOAD_SWITCH
date: 13 hours ago
compiler: clang version 22.1.8 (https://github.com/llvm/llvm-project ca7933e47d3a3451d81e72ac174dcb5aa28b59d1)
docutils: docutils (Docutils 0.21.2, Python 3.13.5, on linux)
reproduce: (https://download.01.org/0day-ci/archive/20260630/202606300641.u5PDL60Y-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/202606300641.u5PDL60Y-lkp@intel.com/
All warnings (new ones prefixed by >>):
============ ===========================================
1 automatic adjustment of input current limit
0 no adjustment of input current limit. This
helps for more unusual power sources like
solar modules. [docutils]
>> Documentation/ABI/testing/sysfs-class-power-rt9471:1: WARNING: Inline emphasis start-string without end-string. [docutils]
WARNING: ./block/blk-map.c:366 Excess function parameter 'op' description in 'bio_copy_kern'
Documentation/devicetree/kernel-api:11: ./drivers/of/base.c:2161: WARNING: Inline emphasis start-string without end-string. [docutils]
Documentation/devicetree/kernel-api:11: ./drivers/of/base.c:2351: WARNING: Inline emphasis start-string without end-string. [docutils]
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]
vim +1 Documentation/ABI/testing/sysfs-class-power-rt9471
ab8174bbc39669 ChiYuan Huang 2023-01-13 @1 What: /sys/class/power_supply/rt9471-*/sysoff_enable
ab8174bbc39669 ChiYuan Huang 2023-01-13 2 Date: Feb 2023
ab8174bbc39669 ChiYuan Huang 2023-01-13 3 KernelVersion: 6.3
ab8174bbc39669 ChiYuan Huang 2023-01-13 4 Contact: ChiYuan Huang <cy_huang@richtek.com>
ab8174bbc39669 ChiYuan Huang 2023-01-13 5 Description:
ab8174bbc39669 ChiYuan Huang 2023-01-13 6 This entry allows enabling the sysoff mode of rt9471 charger devices.
ab8174bbc39669 ChiYuan Huang 2023-01-13 7 If enabled and the input is removed, the internal battery FET is turned
ab8174bbc39669 ChiYuan Huang 2023-01-13 8 off to reduce the leakage from the BAT pin. See device datasheet for details.
ab8174bbc39669 ChiYuan Huang 2023-01-13 9 It's commonly used when the product enter shipping stage. After entering
ab8174bbc39669 ChiYuan Huang 2023-01-13 10 shipping mode, only 'VBUS' or 'Power key" pressed can make it leave this
ab8174bbc39669 ChiYuan Huang 2023-01-13 11 mode. 'Disable' also can help to leave it, but it's more like to abort
ab8174bbc39669 ChiYuan Huang 2023-01-13 12 the action before the device really enter shipping mode.
ab8174bbc39669 ChiYuan Huang 2023-01-13 13
fad2c985b1a8f0 Waqar Hameed 2026-06-29 14 Note: use /sys/class/power_supply/rt9471-*/load_switch instead.
fad2c985b1a8f0 Waqar Hameed 2026-06-29 15
ab8174bbc39669 ChiYuan Huang 2023-01-13 16 Access: Read, Write
ab8174bbc39669 ChiYuan Huang 2023-01-13 17 Valid values:
ab8174bbc39669 ChiYuan Huang 2023-01-13 18 - 1: enabled
ab8174bbc39669 ChiYuan Huang 2023-01-13 19 - 0: disabled
ab8174bbc39669 ChiYuan Huang 2023-01-13 20
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v2] docs: kernel-hacking: fix typo
From: SJ Park @ 2026-06-30 5:01 UTC (permalink / raw)
To: Manuel Ebner
Cc: SJ Park, Jonathan Corbet, Shuah Khan, Vlastimil Babka,
open list:DOCUMENTATION, open list
In-Reply-To: <20260629152912.86500-2-manuelebner@mailbox.org>
On Mon, 29 Jun 2026 17:29:13 +0200 Manuel Ebner <manuelebner@mailbox.org> wrote:
> 'GP_KERNEL' -> 'GFP_KERNEL'
> Remove trailing '`' without clear purpose
Nice catch!
>
> Signed-off-by: Manuel Ebner <manuelebner@mailbox.org>
Reviewed-by: SJ Park <sj@kernel.org>
Thanks,
SJ
[...]
^ permalink raw reply
* Re: [PATCH RFC v6 1/5] dt-bindings: iio: add Open Sensor Fusion device
From: Kim Jinseob @ 2026-06-30 5:02 UTC (permalink / raw)
To: Conor Dooley
Cc: Jonathan Cameron, 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: <20260629-gilled-henna-96bde265d7ed@spud>
I will remove that sentence in the next revision.
I will also drop the RFC tag for the next version unless there are specific
open questions that need to be called out.
Thanks
Jinseob
2026년 6월 30일 (화) 오전 12:39, Conor Dooley <conor@kernel.org>님이 작성:
>
> On Mon, Jun 29, 2026 at 04:13:33AM +0900, Jinseob Kim wrote:
> > Add a binding for the generic Open Sensor Fusion host interface.
> >
> > Open Sensor Fusion devices report capabilities and samples over an OSF
> > protocol stream. Sensor channels are discovered at runtime from
> > capability reports instead of being described individually in Device
> > Tree.
> >
> > The protocol version is discovered at runtime from the OSF frame header.
> > OSF GREEN is a product identity, and OSF0 is a wire-format magic value,
> > so neither is used as the Linux compatible string.
> >
> > Signed-off-by: Jinseob Kim <kimjinseob88@gmail.com>
> > ---
> > .../bindings/iio/opensensorfusion,osf.yaml | 54 +++++++++++++++++++
> > .../devicetree/bindings/vendor-prefixes.yaml | 2 +
> > MAINTAINERS | 6 +++
> > 3 files changed, 62 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/iio/opensensorfusion,osf.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/iio/opensensorfusion,osf.yaml b/Documentation/devicetree/bindings/iio/opensensorfusion,osf.yaml
> > new file mode 100644
> > index 000000000..8016d582f
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/iio/opensensorfusion,osf.yaml
> > @@ -0,0 +1,54 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/iio/opensensorfusion,osf.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Open Sensor Fusion Sensor Aggregation Hub
> > +
> > +maintainers:
> > + - Jinseob Kim <kimjinseob88@gmail.com>
> > +
> > +description: |
> > + This binding documents the generic Open Sensor Fusion host interface. Open
> > + Sensor Fusion is a sensor aggregation hub. The hub exposes an OSF protocol
> > + data stream over its host interface and reports capabilities and samples for
> > + multiple sensor classes. The actual sensor channels are discovered at runtime
> > + from OSF capability reports instead of describing them in Device Tree. The
> > + protocol version is discovered at runtime.
> > +
> > + Public project documentation is available at:
> > +
> > + https://github.com/opensensorfusion
> > +
> > + The compatible describes the generic Open Sensor Fusion host interface.
>
> > It
> > + is not an OSF GREEN board identity, and it does not encode the OSF0 wire
> > + magic.
>
> I think this is evident from the previous text, and the first part is a
> bit confusing while the latter half is a bit confusing.
> Just remove this sentence I think.
>
> Binding looks fine to me, I'll provide a r-b when you submit a non-RFC
> version.
>
> pw-bot: not-applicable
>
> Thanks,
> Conor.
>
> > OSF0, protocol_major, and protocol_minor are wire-protocol details
> > + exchanged in OSF frames.
> > +
> > +allOf:
> > + - $ref: /schemas/serial/serial-peripheral-props.yaml#
> > +
> > +properties:
> > + compatible:
> > + const: opensensorfusion,osf
> > +
> > + vcc-supply:
> > + description:
> > + Regulator supplying power to the Open Sensor Fusion device.
> > +
> > +required:
> > + - compatible
> > + - vcc-supply
> > +
> > +unevaluatedProperties: false
> > +
> > +examples:
> > + - |
> > + serial {
> > + sensor {
> > + compatible = "opensensorfusion,osf";
> > + vcc-supply = <&vcc_sensor>;
> > + };
> > + };
> > +...
> > diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> > index 28784d66a..88172d4a4 100644
> > --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
> > +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> > @@ -1237,6 +1237,8 @@ patternProperties:
> > description: OpenPandora GmbH
> > "^openrisc,.*":
> > description: OpenRISC.io
> > + "^opensensorfusion,.*":
> > + description: Open Sensor Fusion
> > "^openwrt,.*":
> > description: OpenWrt
> > "^option,.*":
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index c2c6d7927..e4df9d8dc 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -20011,6 +20011,12 @@ F: Documentation/devicetree/
> > F: arch/*/boot/dts/
> > F: include/dt-bindings/
> >
> > +OPEN SENSOR FUSION
> > +M: Jinseob Kim <kimjinseob88@gmail.com>
> > +S: Maintained
> > +F: Documentation/devicetree/bindings/iio/opensensorfusion,osf.yaml
> > +K: opensensorfusion
> > +
> > OPENCOMPUTE PTP CLOCK DRIVER
> > M: Vadim Fedorenko <vadim.fedorenko@linux.dev>
> > L: netdev@vger.kernel.org
> > --
> > 2.43.0
> >
^ permalink raw reply
* Re: [PATCH v2 9/9] hwmon: adm1275: Support ROHM BD12790
From: Matti Vaittinen @ 2026-06-30 5:04 UTC (permalink / raw)
To: Guenter Roeck
Cc: Matti Vaittinen, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jonathan Corbet, Shuah Khan, Wensheng Wang, Ashish Yadav,
Vasileios Amoiridis, Kim Seer Paller, ChiShih Tsai, Chris Packham,
Robert Coulson, linux-hwmon, devicetree, linux-kernel, linux-doc
In-Reply-To: <2cf72420-8513-4856-a3cb-fe2629588d1b@roeck-us.net>
June 30, 2026 at 12:08 AM, "Guenter Roeck" <linux@roeck-us.net mailto:linux@roeck-us.net?to=%22Guenter%20Roeck%22%20%3Clinux%40roeck-us.net%3E > wrote:
>
> On Fri, Jun 26, 2026 at 10:26:02AM +0300, Matti Vaittinen wrote:
>
> >
> > From: Matti Vaittinen <mazziesaccount@gmail.com>
> >
> > Add support for ROHM BD12790 hot-swap controller which is largely
> > similar to Analog Devices adm1272.
> >
> > The BD12790 uses the same selectable 60V/100V voltage ranges and
> > 15mV/30mV current-sense ranges as the ADM1272, and the same VRANGE
> > (bit 5) and IRANGE (bit 0) layout in PMON_CONFIG. It therefore uses
> > a dedicated coefficient table that mirrors adm1272_coefficients, with
> > the following differences derived from BD12790 datasheet Table 1 (p.18):
> > - power 60V/30mV: m=17560 (vs. 17561)
> > - power 100V/30mV: m=10536 (vs. 10535)
> > - temperature: b=31880 (vs. 31871, reflecting T[11:0] = 4.2*T + 3188)
> >
> > Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
> > Assisted-by: GitHub Copilot:claude-sonnet-4.6
> >
> Applied, after fixing the comment about BD12790 coefficients as suggested.
Thanks for going the extra mile and fixing while applying. I am glad I didn't need to re-spin for this! :)
And it seems gmail is getting more and more useless :( This (and couple of other replies) never emerged in my gmail inbox. So, just as a heads-up - gmail may silently drop some messages when reveiving. :(
Yours,
-- Matti
^ permalink raw reply
* Re: [PATCH RFC v6 2/5] Documentation: iio: add Open Sensor Fusion driver overview
From: Kim Jinseob @ 2026-06-30 5:04 UTC (permalink / raw)
To: Jonathan Cameron
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: <20260630000254.1d1cf422@jic23-huawei>
I will remove "initial" there in the next revision.
Thanks
Jinseob
2026년 6월 30일 (화) 오전 8:03, Jonathan Cameron <jic23@kernel.org>님이 작성:
>
> On Mon, 29 Jun 2026 04:13:34 +0900
> Jinseob Kim <kimjinseob88@gmail.com> wrote:
>
> > Document the Linux IIO mapping for Open Sensor Fusion devices.
> >
> > The overview explains that sensor channels are discovered at runtime
> > from mandatory capability reports. It also documents that OSF0 is a
> > wire-format detail and that protocol_major and protocol_minor carry
> > protocol compatibility information.
> >
> > Signed-off-by: Jinseob Kim <kimjinseob88@gmail.com>
>
> One small thing inline. Otherwise looks good to me!
>
> Jonathan
>
> > diff --git a/Documentation/iio/open-sensor-fusion.rst b/Documentation/iio/open-sensor-fusion.rst
> > new file mode 100644
> > index 000000000..832901f5e
> > --- /dev/null
> > +++ b/Documentation/iio/open-sensor-fusion.rst
>
> > +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.
>
> Really small thing but I would avoid talking about 'initial' driver.
> It can cause confusion about when something is true and when it is not
> as we may have multiple non 'initial' drivers before you get to changing
> this handling. So just remove that word.
>
^ permalink raw reply
* Re: [PATCH RFC v6 3/5] iio: osf: add protocol decoding
From: Kim Jinseob @ 2026-06-30 5:07 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Jonathan Cameron, 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: <akJ7p17eay2mnW-Y@ashevche-desk.local>
I will fix these in the next revision.
- adjust the OSF_FRAME_MAGIC comment as suggested;
- remove or rewrite the overflow checks that are effectively dead for the
current u16 counts;
- build with W=1 using both GCC and clang before posting.
I will also include these items in the review tracking before posting another
revision.
Thanks,
Jinseob
2026년 6월 29일 (월) 오후 11:05, Andy Shevchenko <andriy.shevchenko@intel.com>님이 작성:
>
> On Mon, Jun 29, 2026 at 04:13:35AM +0900, Jinseob Kim wrote:
> > Add helpers for decoding Open Sensor Fusion frame headers and supported
> > message payloads.
> >
> > The decoder validates the OSF0 wire magic, protocol major version,
> > header length, payload bounds, reserved fields and CRC before exposing
> > decoded frame contents to the rest of the driver.
> >
> > Use explicit little-endian wire storage sizes and designated
> > initializers for decoded output structures.
>
> ...
>
> > +#include <linux/bits.h>
> > +#include <linux/crc32.h>
> > +#include <linux/errno.h>
> > +#include <linux/limits.h>
> > +#include <linux/types.h>
> > +#include <linux/unaligned.h>
>
> ...
>
> > +#define OSF_FRAME_MAGIC 0x3046534f /* "OSF0" little-endian */
>
> #define OSF_FRAME_MAGIC 0x3046534f /* "OSF0", little-endian */
>
> (mind a comma).
>
> ...
>
> > +int osf_protocol_decode_sensor_sample(const struct osf_frame *frame,
> > + struct osf_sensor_sample *sample)
> > +{
> > + u16 channel_count;
> > + u16 sample_format;
> > + u16 sensor_type;
> > + size_t expected_len;
> > + const u8 *payload;
> > +
> > + if (!frame || !sample || !frame->payload)
> > + return -EINVAL;
> > +
> > + if (frame->message_type != OSF_MSG_SENSOR_SAMPLE)
> > + return -EPROTO;
> > +
> > + if (frame->payload_len < OSF_SENSOR_SAMPLE_BASE_LEN)
> > + return -EMSGSIZE;
> > +
> > + payload = frame->payload;
> > + sensor_type = get_unaligned_le16(payload);
> > + channel_count = get_unaligned_le16(payload + 4);
> > + sample_format = get_unaligned_le16(payload + 6);
> > +
> > + if (!osf_sensor_type_valid(sensor_type))
> > + return -EPROTO;
> > +
> > + if (!channel_count)
> > + return -EPROTO;
> > +
> > + if (sample_format != OSF_SAMPLE_FORMAT_S32)
> > + return -EPROTO;
> > +
> > + if (get_unaligned_le32(payload + 12))
> > + return -EPROTO;
>
> > + if (channel_count > (SIZE_MAX - OSF_SENSOR_SAMPLE_BASE_LEN) /
> > + sizeof(__le32))
> > + return -EOVERFLOW;
>
> Dead code because it's always 'false'? Hasn't compiler given a warning?
> Always compile your code with `make W=1` using both compilers: clang and GCC.
>
> > + expected_len = OSF_SENSOR_SAMPLE_BASE_LEN + channel_count * sizeof(__le32);
> > + if (frame->payload_len != expected_len)
> > + return -EMSGSIZE;
> > +
> > + *sample = (struct osf_sensor_sample) {
> > + .sensor_type = sensor_type,
> > + .sensor_index = get_unaligned_le16(payload + 2),
> > + .channel_count = channel_count,
> > + .sample_format = sample_format,
> > + .scale_nano = get_unaligned_le32(payload + 8),
> > + .samples = payload + OSF_SENSOR_SAMPLE_BASE_LEN,
> > + };
> > +
> > + return 0;
> > +}
>
> ...
>
> > + if (capability_count > (SIZE_MAX - OSF_CAP_REPORT_BASE_LEN) /
> > + OSF_CAP_SENSOR_ENTRY_LEN)
> > + return -EOVERFLOW;
>
> Ditto.
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
^ permalink raw reply
* Re: [PATCH RFC v6 4/5] iio: osf: add authenticated stream parser
From: Kim Jinseob @ 2026-06-30 5:12 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Andy Shevchenko, 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: <20260630000623.0c030d5f@jic23-huawei>
Understood. I missed applying the earlier style feedback consistently
across this file, and I should have explicitly replied where a previous
comment was not addressed.
I will these:
- reuse the existing OSF magic definition instead of duplicating a byte array
in the stream parser;
- use loop-local variables where the variable is not used outside the loop;
- rework the stream error handling so authenticated and unauthenticated
failures are handled deliberately;
- either update partial_frames where appropriate or remove the unused
statistic.
I will also check lore for the previous versions and track the earlier review
comments before posting another revision, making sure each one is either
addressed in code or explicitly answered.
Thanks,
Jinseob
2026년 6월 30일 (화) 오전 8:06, Jonathan Cameron <jic23@kernel.org>님이 작성:
>
> On Mon, 29 Jun 2026 17:10:31 +0300
> Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
>
> > On Mon, Jun 29, 2026 at 04:13:36AM +0900, Jinseob Kim wrote:
> > > Add a UART byte-stream parser for Open Sensor Fusion frames.
> > >
> > > The parser searches for the OSF0 wire magic, keeps partial frames
> > > buffered, checks header length and payload bounds, and passes complete
> > > candidate frames to the core decoder.
> > >
> > > Rejected candidate frames drop only the current head byte before
> > > resynchronizing, so a corrupted unauthenticated payload length cannot
> > > make the parser skip later valid frames.
> >
> > ...
> >
> > > +#define OSF_STREAM_MAGIC_LEN 4
> > > +#define OSF_STREAM_MAX_PAYLOAD_LEN \
> > > + (OSF_STREAM_MAX_FRAME_LEN - OSF_FRAME_HEADER_LEN - OSF_FRAME_CRC_LEN)
> > > +
> > > +static const u8 osf_stream_magic[OSF_STREAM_MAGIC_LEN] = {
> > > + 'O', 'S', 'F', '0',
> > > +};
> >
> > You have already this in the header (as FourCC), use that.
> >
> > ...
> >
> > > +static size_t osf_stream_discard_to_magic(struct osf_stream *stream)
> > > +{
> > > + size_t old_len = stream->len;
> > > + size_t match_len;
> >
> > > + size_t i;
> > > +
> > > + for (i = 0; i < stream->len; i++) {
> >
> > for (size_t i = 0; i < stream->len; i++) {
> >
> > > + match_len = stream->len - i;
> > > + if (match_len > OSF_STREAM_MAGIC_LEN)
> > > + match_len = OSF_STREAM_MAGIC_LEN;
> > > +
> > > + if (osf_stream_magic_match(stream->buf + i, match_len)) {
> > > + if (i)
> > > + osf_stream_discard(stream, i);
> > > + return i;
> > > + }
> > > + }
> > > +
> > > + stream->len = 0;
> > > + return old_len;
> > > +}
> >
> > ...
> >
> > I stop here, because it's obvious that you neglected and ignored my previous
> > reviews. No explanation given, nothing. This is not how you should interact
> > with the community.
> >
> > Come again when each of the given comment will be either addressed or argued.
> >
> Likewise. Please make sure to address every comment either through
> changes or through reply to the earlier thread. Perhaps some emails
> have gone astray (it happens!). It can be a good idea to take a quick
> look at lore.kernel.org to make sure you aren't missing any feedback
> on a previous version.
>
> Thanks,
>
> Jonathan
>
>
^ permalink raw reply
* Re: [PATCH net-deletions] net: remove ax25 and amateur radio (hamradio) subsystem
From: Jiri Slaby @ 2026-06-30 5:42 UTC (permalink / raw)
To: Jakub Kicinski
Cc: davem, netdev, edumazet, pabeni, andrew+netdev, horms, corbet,
skhan, federico.vaga, carlos.bilbao, avadhut.naik, alexs,
si.yanteng, dzm91, 2023002089, tsbogend, dsahern, jani.nikula,
mchehab+huawei, gregkh, tytso, herbert, ebiggers, johannes.berg,
geert, pablo, tglx, mashiro.chen, mingo, dqfext, jreuter, sdf,
pkshih, enelsonmoore, mkl, toke, kees, crossd, jlayton,
wangliang74, aha310510, takamitz, kuniyu, linux-doc, linux-mips
In-Reply-To: <20260629152930.4c2131ed@kernel.org>
On 30. 06. 26, 0:29, Jakub Kicinski wrote:
> On Mon, 29 Jun 2026 07:24:51 +0200 Jiri Slaby wrote:
>> And net-tools are broken by the uapi/linux/rose.h removal:
>> rose.c:39:10: fatal error: linux/rose.h: No such file or directory
>> at:
>> https://github.com/ecki/net-tools/blob/2ab3c5efdb5c220bc9a649fded56c361136bff1a/lib/rose.c#L39
>
> Looks like the code for rose is already well separated from the rest.
> Should we just ask net-tools to delete it? Or do you feel strongly
> about restoring the now-defunct header?
No strong opinion from me. net-tools are easy to fix.
The builds of LLVMs (versions 15 to 21 at least) are broken nonetheless.
They are easy to fix as well -- by backporting the fix from main or 22.
(15--21 are likely unmaintained upstream already, but still
used/required widely).
$ osc whatdependson openSUSE:Factory llvm19 standard x86_64
llvm19 :
MozillaThunderbird
firefox-esr
ghc
gtkd
ldc
lfortran
python-PyMuPDF
redumper
tilix
zig0.14
$ osc whatdependson openSUSE:Factory llvm21 standard x86_64
llvm21 :
OpenImageDenoise
chromium
embree
ispc
leechcraft
python-PyMuPDF
python314
python314:base
python314:doc
python315
python315:base
python315:doc
rpcs3
rust-keylime
zig0.16
thanks,
--
js
suse labs
^ permalink raw reply
* Re: [PATCH v5 06/24] sched/core: allow only preferred CPUs in is_cpu_allowed
From: Shrikanth Hegde @ 2026-06-30 6:25 UTC (permalink / raw)
To: Yury Norov, kprateek.nayak
Cc: linux-kernel, mingo, peterz, juri.lelli, vincent.guittot, iii,
corbet, tglx, gregkh, pbonzini, seanjc, vschneid, huschle,
rostedt, dietmar.eggemann, maddy, srikar, hdanton, chleroy,
vineeth, frederic, arighi, pauld, christian.loehle, tj,
tommaso.cucinotta, maz, rafael, rdunlap, kernellwp, linux-doc
In-Reply-To: <e6570eac-e675-4b9b-8d1b-516965cd2207@linux.ibm.com>
Hi Yury, Prateek,
On 6/29/26 9:44 AM, Shrikanth Hegde wrote:
> Hi Yury.
>
>> Just as said on previous round. Please order your series such that the
>> core logic goes first, and all sorts of complications, like this
>> optimization, are appended at the end.
>
> Ok. I will split it up into two patches.
>
> One without any optimization but with comment explaining the rare case
> of N**2.
> Second one at the end of the series, with a patch do the optimization.
>
>>
>>> ---
>>>
>>> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
>>> index 9e16946c9d62..fafedd52611f 100644
>>> --- a/kernel/sched/core.c
>>> +++ b/kernel/sched/core.c
>>> @@ -2498,8 +2498,10 @@ static inline bool rq_has_pinned_tasks(struct
>>> rq *rq)
>>> * Per-CPU kthreads are allowed to run on !active && online CPUs, see
>>> * __set_cpus_allowed_ptr() and select_fallback_rq().
>>> */
>>> -static inline bool is_cpu_allowed(struct task_struct *p, int cpu)
>>> +static inline bool is_cpu_allowed(struct task_struct *p, int cpu,
>>> int cached)
>>> {
>>> + bool task_check_preferred_cpu;
>>> +
>>> /* When not in the task's cpumask, no point in looking
>>> further. */
>>> if (!task_allowed_on_cpu(p, cpu))
>>> return false;
>>> @@ -2508,9 +2510,24 @@ static inline bool is_cpu_allowed(struct
>>> task_struct *p, int cpu)
>>> if (is_migration_disabled(p))
>>> return cpu_online(cpu);
>>> + /*
>>> + * This is essential to maintain user affinities when preferred
>>> + * CPUs change. A task pinned on non-preferred CPU should
>>> continue
>>> + * to run there, since this is non-user triggered.
>>> + *
>>> + * If CPU is non-preferred and task can run on other CPUs
>>> which are
>>> + * currently preferred, then choose those other CPUs instead.
>>> + * Overhead is minimal when CPU is preferred.
>>> + */
>>> + task_check_preferred_cpu = !cpu_preferred(cpu) &&
>>> + task_has_preferred_cpus(p, cached);
>>> +
>>> /* Non kernel threads are not allowed during either online
>>> or offline. */
>>> - if (!(p->flags & PF_KTHREAD))
>>> + if (!(p->flags & PF_KTHREAD)) {
>>> + if (task_check_preferred_cpu)
>>> + return false;
>>> return cpu_active(cpu);
>>> + }
>>> /* KTHREAD_IS_PER_CPU is always allowed. */
>>> if (kthread_is_per_cpu(p))
>>> @@ -2520,6 +2537,10 @@ static inline bool is_cpu_allowed(struct
>>> task_struct *p, int cpu)
>>> if (cpu_dying(cpu))
>>> return false;
>>> + /* Try on preferred CPU first if possible*/
>>> + if (task_check_preferred_cpu)
>>> + return false;
>>> +
>>> /* But are allowed during online. */
>>> return cpu_online(cpu);
>>> }
>>> @@ -2595,7 +2616,7 @@ static struct rq *__migrate_task(struct rq *rq,
>>> struct rq_flags *rf,
>>> __must_hold(__rq_lockp(rq))
>>> {
>>> /* Affinity changed (again). */
>>> - if (!is_cpu_allowed(p, dest_cpu))
>>> + if (!is_cpu_allowed(p, dest_cpu, NO_CACHED_VAL))
>>> return rq;
>>
>> This thing I really dislike. The unrelated code should not be
>> affected. You can make it less visually invasive with:
>> #define is_cpu_allowed(p, cpu) __is_cpu_allowed(p, cpu,
>> NO_CACHED_VAL)
>>
>> Please reconsider your code to have the changes better localized.
>>
>> Thanks,
>> Yury
>>
>
> That was typed out too fast. I did refactor something like that later.
> But i will split this into twp patches as said above.
>
>
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 9e16946c9d62..a1b21c21aa9c 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -2498,8 +2498,11 @@ static inline bool rq_has_pinned_tasks(struct rq
> *rq)
> * Per-CPU kthreads are allowed to run on !active && online CPUs, see
> * __set_cpus_allowed_ptr() and select_fallback_rq().
> */
> -static inline bool is_cpu_allowed(struct task_struct *p, int cpu)
> +static inline bool __is_cpu_allowed(struct task_struct *p, int cpu,
> + int pref_state)
> {
> + bool task_check_preferred_cpu;
> +
> /* When not in the task's cpumask, no point in looking further. */
> if (!task_allowed_on_cpu(p, cpu))
> return false;
> @@ -2508,9 +2511,24 @@ static inline bool is_cpu_allowed(struct
> task_struct *p, int cpu)
> if (is_migration_disabled(p))
> return cpu_online(cpu);
>
> + /*
> + * This is essential to maintain user affinities when preferred
> + * CPUs change. A task pinned on non-preferred CPU should continue
> + * to run there, since this is non-user triggered.
> + *
> + * If CPU is non-preferred and task can run on other CPUs which are
> + * currently preferred, then choose those other CPUs instead.
> + * Overhead is minimal when CPU is preferred.
> + */
> + task_check_preferred_cpu = !cpu_preferred(cpu) &&
> + task_has_preferred_cpus(p, pref_state);
> +
> /* Non kernel threads are not allowed during either online or
> offline. */
> - if (!(p->flags & PF_KTHREAD))
> + if (!(p->flags & PF_KTHREAD)) {
> + if (task_check_preferred_cpu)
> + return false;
> return cpu_active(cpu);
> + }
>
> /* KTHREAD_IS_PER_CPU is always allowed. */
> if (kthread_is_per_cpu(p))
> @@ -2520,10 +2538,19 @@ static inline bool is_cpu_allowed(struct
> task_struct *p, int cpu)
> if (cpu_dying(cpu))
> return false;
>
> + /* Try on preferred CPU first if possible*/
> + if (task_check_preferred_cpu)
> + return false;
> +
> /* But are allowed during online. */
> return cpu_online(cpu);
> }
>
> +static inline bool is_cpu_allowed(struct task_struct *p, int cpu)
> +{
> + return __is_cpu_allowed(p, cpu, PREFERRED_CPU_UNKNOWN);
> +}
> +
> /*
> * This is how migration works:
> *
> @@ -3547,7 +3574,15 @@ static int select_fallback_rq(int cpu, struct
> task_struct *p)
> int nid = cpu_to_node(cpu);
> const struct cpumask *nodemask = NULL;
> enum { cpuset, possible, fail } state = cpuset;
> - int dest_cpu;
> + int dest_cpu, pref_state;
> +
> + /*
> + * Cache the value whether task's affinity spans preferred CPUs.
> + * This helps to avoid repeating the same for each CPU
> + * later in the loop.
> + */
> + pref_state = task_has_preferred_cpus(p, PREFERRED_CPU_UNKNOWN) ?
> + PREFERRED_CPU_EXISTS : PREFERRED_CPU_NONE;
>
> /*
> * If the node that the CPU is on has been offlined, cpu_to_node()
> @@ -3559,7 +3594,7 @@ static int select_fallback_rq(int cpu, struct
> task_struct *p)
>
> /* Look for allowed, online CPU in same node. */
> for_each_cpu(dest_cpu, nodemask) {
> - if (is_cpu_allowed(p, dest_cpu))
> + if (__is_cpu_allowed(p, dest_cpu, pref_state))
> return dest_cpu;
> }
> }
> @@ -3567,7 +3602,7 @@ static int select_fallback_rq(int cpu, struct
> task_struct *p)
> for (;;) {
> /* Any allowed, online CPU? */
> for_each_cpu(dest_cpu, p->cpus_ptr) {
> - if (!is_cpu_allowed(p, dest_cpu))
> + if (!__is_cpu_allowed(p, dest_cpu, pref_state))
> continue;
>
> goto out;
> diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
> index c7c2dea65edd..6a352d235503 100644
> --- a/kernel/sched/sched.h
> +++ b/kernel/sched/sched.h
> @@ -4213,4 +4213,33 @@ DEFINE_CLASS_IS_UNCONDITIONAL(sched_change)
>
> #include "ext.h"
>
> +/*
> + * PREFERRED_CPU_UNKNOWN: Unknown and need to evaluate.
> + * PREFERRED_CPU_NONE : Known and No preferred CPUs exists in task's
> affinity.
> + * PREFERRED_CPU_EXISTS: Known and preferred CPU exists in task's
> affinity.
> + */
> +
> +enum task_preferred_cached {
> + PREFERRED_CPU_UNKNOWN,
> + PREFERRED_CPU_NONE,
> + PREFERRED_CPU_EXISTS,
> +};
> +
> +/*
> + * Value is known when called via select_fallback_rq(). This helps to
> + * avoid calling cpumask_intersects repeatedly in the loop.
> + *
> + * Only affects FAIR task.
> + */
> +static inline bool task_has_preferred_cpus(struct task_struct *p, int
> pref_state)
> +{
> + /* Only FAIR tasks honor preferred CPU state */
> + if (unlikely(p->sched_class != &fair_sched_class))
> + return false;
> +
> + if (pref_state != PREFERRED_CPU_UNKNOWN)
> + return pref_state == PREFERRED_CPU_EXISTS;
> +
> + return cpumask_intersects(p->cpus_ptr, cpu_preferred_mask);
> +}
> #endif /* _KERNEL_SCHED_SCHED_H */
>
I was thinking caching the value can cause affinity to be reset,
because there is no protection of mask change within the loop of
select_fallback_rq. So i did some testing, and
I hit a case in practice with 10ms as interval with explicit
affinities on overlapping preferred and non-preferred CPUs and hotplugging
specific CPUs. caching exposes this race
Lets say task affined to 464-479 and preferred mask is 0-471 (472-479 is non preferred)
CPU468 CPU0
select_fallback_rq
- pref_state = PREFERRED_CPU_EXISTS
(Now preferred_mask becomes 0-463, but (Changes preferred to 0-463)
before any further call to is_cpu_allowed
is made)
- is_cpu_allowed tries to find a preferred
CPU since cached state says one exists.
- is_cpu_allowed is called twice (once on nodemask,
and once on p->cpus_ptr) but cached state remains the
same.
- no CPU found, fallback to reset to possible CPUs.
Without cached state, there is evaluation on each !preferred CPU
and such race isn;t possible between two calls. So chance of race
is extremely rare if non-existent.
I couldn't hit the same race in any permutations I tried.
Even if we take task was affined to only one CPU and mask changed between &&.
!cpu_preferred(cpu) && task_has_preferred_cpus(p);
Two cases.
Case 1: cpu was marked as preferred and after && it got removed from preferred_mask.
In that case task may end up on non-preferred CPU and it gets pushed out if possible.
No reset of its affinity.
Case 2: cpu was non-preferred and now it became preferred after && Now cpumask_intersects
will be true true and task_has_preferred_cpus is true as well, but this CPU will be skipped.
But second call in select_fallback_rq will ensure it returns the since cpu_preferred check
will succeed. Since select_fallback_rq is called on task_cpu(p) where it previously ran,
first check may fail due to race, but second one can't since evaluation between the two can't
be more than 1ms.
* So I will drop this optimization of caching the state for now *
^ permalink raw reply
* Re: [PATCH net-next v6 14/15] dt-bindings: net: add onsemi's S2500
From: Krzysztof Kozlowski @ 2026-06-30 6:29 UTC (permalink / raw)
To: Selvamani Rajagopal
Cc: Andrew Lunn, Piergiorgio Beruto, Heiner Kallweit, Russell King,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Andrew Lunn, Parthiban Veerasooran, Richard Cochran, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Simon Horman, Jonathan Corbet,
Shuah Khan, netdev, linux-kernel, devicetree, linux-doc,
Jerry Ray
In-Reply-To: <20260629-s2500-mac-phy-support-v6-14-18ce79500371@onsemi.com>
On Mon, Jun 29, 2026 at 10:23:44AM -0700, Selvamani Rajagopal wrote:
> Add YAML device tree binding for the onsemi S2500 IEEE 802.3cg
No improvements.
So not only you ignored review comment but you also ignored actual
review tag.
Don't worry, we can ignore your patches as well.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/6] dt-bindings: hwmon: (pmbus/max20830): add enable-gpios property
From: Krzysztof Kozlowski @ 2026-06-30 7:26 UTC (permalink / raw)
To: Alexis Czezar Torreno
Cc: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jonathan Corbet, Shuah Khan, linux-hwmon, devicetree,
linux-kernel, linux-doc
In-Reply-To: <20260630-dev-max20830c-v1-1-a02786bde470@analog.com>
On Tue, Jun 30, 2026 at 10:46:43AM +0800, Alexis Czezar Torreno wrote:
> Adding a missing entry for the MAX20830 EN (enable) pin.
... because? Device has it? Was missing?
>
> Signed-off-by: Alexis Czezar Torreno <alexisczezar.torreno@analog.com>
> ---
> Documentation/devicetree/bindings/hwmon/pmbus/adi,max20830.yaml | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/hwmon/pmbus/adi,max20830.yaml b/Documentation/devicetree/bindings/hwmon/pmbus/adi,max20830.yaml
> index 1625dd59417f1b3ca689a9c86ca266da913d1217..ab8f6324866f29de8c66c3c63300845b2e02207e 100644
> --- a/Documentation/devicetree/bindings/hwmon/pmbus/adi,max20830.yaml
> +++ b/Documentation/devicetree/bindings/hwmon/pmbus/adi,max20830.yaml
> @@ -39,6 +39,11 @@ properties:
> description:
> Optional 2.5V to 5.5V LDO input supply.
>
> + enable-gpios:
> + description:
> + GPIO connected to the EN (enable) pin.
> + maxItems: 1
Make also the example complete.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 3/6] dt-bindings: hwmon: (pmbus/max20830): add VOUT feedback resistor properties
From: Krzysztof Kozlowski @ 2026-06-30 7:39 UTC (permalink / raw)
To: Alexis Czezar Torreno
Cc: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jonathan Corbet, Shuah Khan, linux-hwmon, devicetree,
linux-kernel, linux-doc
In-Reply-To: <20260630-dev-max20830c-v1-3-a02786bde470@analog.com>
On Tue, Jun 30, 2026 at 10:46:45AM +0800, Alexis Czezar Torreno wrote:
> Add adi,vout-rfb1-ohms and adi,vout-rfb2-ohms properties to support
> external voltage divider configuration for VOUT sensing. When the
> desired output voltage is higher than VREF, a resistor divider (RFB1
> and RFB2) is required to reach the intended value.
>
> The properties use a dependency constraint to ensure both resistors
> are specified together, or neither. This prevents misconfiguration
> where only one resistor value is provided.
>
> Signed-off-by: Alexis Czezar Torreno <alexisczezar.torreno@analog.com>
> ---
> .../devicetree/bindings/hwmon/pmbus/adi,max20830.yaml | 17 +++++++++++++++++
> 1 file changed, 17 insertions(+)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ 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