<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/drivers/hwmon/pmbus, branch master</title>
<subtitle>Linux kernel source tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/'/>
<entry>
<title>Merge tag 'device-id-rework' of git://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux</title>
<updated>2026-07-03T06:54:26+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2026-07-03T06:54:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=d2c9a99135da931377240942d44f3dea104cedb8'/>
<id>d2c9a99135da931377240942d44f3dea104cedb8</id>
<content type='text'>
Pull mod_devicetable.h header split from Uwe Kleine-König:
 "Split &lt;linux/mod_devicetable.h&gt; in per subsystem headers

  &lt;linux/mod_devicetable.h&gt; is included transitively in nearly every
  driver in an x86_64 allmodconfig build of v7.1:

      $ find drivers -name \*.o -not -name \*.mod.o | wc -l
      21330
      $ find drivers -name \*.o.cmd -not -name \*.mod.o.cmd | xargs grep -l mod_devicetable.h | wc -l
      17038

  The result of this mixture of different and unrelated subsystem
  details is that even when touching an obscure device id struct most of
  the kernel needs to be recompiled. Given that each driver typically
  only needs one or two of these structures, splitting into per
  subsystem headers and only including what is really needed reduces the
  amount of needed recompilation.

  This split is implemented in the first commit and then after some
  preparatory work in the following commits, the last two replace
  includes of &lt;linux/mod_devicetable.h&gt; by the actually needed more
  specific headers.

  There are still a few instances left, but the ones with high impact
  (that is in headers that are used a lot) and the easy ones (.c files)
  are handled. These remaining includes will be addressed during the
  next merge window"

* tag 'device-id-rework' of git://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux:
  Replace &lt;linux/mod_devicetable.h&gt; by more specific &lt;linux/device-id/*.h&gt; (c files)
  Replace &lt;linux/mod_devicetable.h&gt; by more specific &lt;linux/device-id/*.h&gt; (headers)
  parisc: #include &lt;linux/compiler.h&gt; for unlikely() in &lt;asm/ptrace.h&gt;
  media: em28xx: Add include for struct usb_device_id
  LoongArch: KVM: Add include defining struct cpu_feature
  ALSA: hda/core: Add include defining struct hda_device_id
  usb: dwc2: Add include defining struct pci_device_id
  platform/x86: int3472: Add include defining struct dmi_system_id
  platform/x86: x86-android-tablets: Add include defining struct dmi_system_id
  i2c: Let i2c-core.h include &lt;linux/i2c.h&gt;
  of: Explicitly include &lt;linux/types.h&gt; and &lt;linux/err.h&gt;
  platform/x86: msi-ec: Ensure dmi_system_id is defined
  usb: serial: Include &lt;linux/usb.h&gt; in &lt;linux/usb/serial.h&gt;
  driver core: platform: Include header for struct platform_device_id
  driver: core: Include headers for acpi_device_id and of_device_id for struct device_driver
  media: ti: vpe: #include &lt;linux/platform_device.h&gt; explicitly
  mod_devicetable.h: Split into per subsystem headers
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull mod_devicetable.h header split from Uwe Kleine-König:
 "Split &lt;linux/mod_devicetable.h&gt; in per subsystem headers

  &lt;linux/mod_devicetable.h&gt; is included transitively in nearly every
  driver in an x86_64 allmodconfig build of v7.1:

      $ find drivers -name \*.o -not -name \*.mod.o | wc -l
      21330
      $ find drivers -name \*.o.cmd -not -name \*.mod.o.cmd | xargs grep -l mod_devicetable.h | wc -l
      17038

  The result of this mixture of different and unrelated subsystem
  details is that even when touching an obscure device id struct most of
  the kernel needs to be recompiled. Given that each driver typically
  only needs one or two of these structures, splitting into per
  subsystem headers and only including what is really needed reduces the
  amount of needed recompilation.

  This split is implemented in the first commit and then after some
  preparatory work in the following commits, the last two replace
  includes of &lt;linux/mod_devicetable.h&gt; by the actually needed more
  specific headers.

  There are still a few instances left, but the ones with high impact
  (that is in headers that are used a lot) and the easy ones (.c files)
  are handled. These remaining includes will be addressed during the
  next merge window"

* tag 'device-id-rework' of git://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux:
  Replace &lt;linux/mod_devicetable.h&gt; by more specific &lt;linux/device-id/*.h&gt; (c files)
  Replace &lt;linux/mod_devicetable.h&gt; by more specific &lt;linux/device-id/*.h&gt; (headers)
  parisc: #include &lt;linux/compiler.h&gt; for unlikely() in &lt;asm/ptrace.h&gt;
  media: em28xx: Add include for struct usb_device_id
  LoongArch: KVM: Add include defining struct cpu_feature
  ALSA: hda/core: Add include defining struct hda_device_id
  usb: dwc2: Add include defining struct pci_device_id
  platform/x86: int3472: Add include defining struct dmi_system_id
  platform/x86: x86-android-tablets: Add include defining struct dmi_system_id
  i2c: Let i2c-core.h include &lt;linux/i2c.h&gt;
  of: Explicitly include &lt;linux/types.h&gt; and &lt;linux/err.h&gt;
  platform/x86: msi-ec: Ensure dmi_system_id is defined
  usb: serial: Include &lt;linux/usb.h&gt; in &lt;linux/usb/serial.h&gt;
  driver core: platform: Include header for struct platform_device_id
  driver: core: Include headers for acpi_device_id and of_device_id for struct device_driver
  media: ti: vpe: #include &lt;linux/platform_device.h&gt; explicitly
  mod_devicetable.h: Split into per subsystem headers
</pre>
</div>
</content>
</entry>
<entry>
<title>Replace &lt;linux/mod_devicetable.h&gt; by more specific &lt;linux/device-id/*.h&gt; (c files)</title>
<updated>2026-07-03T05:38:17+00:00</updated>
<author>
<name>Uwe Kleine-König (The Capable Hub)</name>
<email>u.kleine-koenig@baylibre.com</email>
</author>
<published>2026-06-30T09:24:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=995832b2cebe6969d1b42635db698803ee31294d'/>
<id>995832b2cebe6969d1b42635db698803ee31294d</id>
<content type='text'>
Replace the #include of &lt;linux/mod_devicetable.h&gt; by the more specific
&lt;linux/device-id/*.h&gt; where applicable. For most cases the include
can be dropped completely, only a few drivers need one or two headers
added.

Acked-by: Danilo Krummrich &lt;dakr@kernel.org&gt;
Acked-by: Takashi Sakamoto &lt;o-takashi@sakamocchi.jp&gt;
Acked-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Link: https://patch.msgid.link/1a3f2007c5c5dcf555c09a4035ce3ae8ef1b6c49.1782808461.git.u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König (The Capable Hub) &lt;u.kleine-koenig@baylibre.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Replace the #include of &lt;linux/mod_devicetable.h&gt; by the more specific
&lt;linux/device-id/*.h&gt; where applicable. For most cases the include
can be dropped completely, only a few drivers need one or two headers
added.

Acked-by: Danilo Krummrich &lt;dakr@kernel.org&gt;
Acked-by: Takashi Sakamoto &lt;o-takashi@sakamocchi.jp&gt;
Acked-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Link: https://patch.msgid.link/1a3f2007c5c5dcf555c09a4035ce3ae8ef1b6c49.1782808461.git.u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König (The Capable Hub) &lt;u.kleine-koenig@baylibre.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>hwmon: (pmbus) Fix passing events to regulator core</title>
<updated>2026-06-29T23:25:27+00:00</updated>
<author>
<name>Guenter Roeck</name>
<email>linux@roeck-us.net</email>
</author>
<published>2026-06-29T23:08:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=9ef7dacd44216bf5ea05c8aef49eba4d145f4047'/>
<id>9ef7dacd44216bf5ea05c8aef49eba4d145f4047</id>
<content type='text'>
Sashiko reports:

Commit 754bd2b4a084 ("hwmon: (pmbus/core) Protect regulator operations with
mutex") introduced a worker to batch regulator events over time using
atomic_or(). The delayed worker then passes the combined bitmask unmodified
to regulator_notifier_call_chain().

The core regulator subsystem's regulator_handle_critical() function
evaluates the event parameter using a strict switch statement. If
multiple distinct faults occur before the worker runs (e.g.,
REGULATOR_EVENT_UNDER_VOLTAGE | REGULATOR_EVENT_OVER_CURRENT), the combined
bitmask fails to match any case. This leaves the reason as NULL and
completely bypasses the critical hw_protection_trigger().

Fix the problem by passing events bit by bit to the regulator event
handler.

Reported-by: Sashiko &lt;sashiko-bot@kernel.org&gt;
Fixes: 754bd2b4a084 ("hwmon: (pmbus/core) Protect regulator operations with mutex")
Signed-off-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Sashiko reports:

Commit 754bd2b4a084 ("hwmon: (pmbus/core) Protect regulator operations with
mutex") introduced a worker to batch regulator events over time using
atomic_or(). The delayed worker then passes the combined bitmask unmodified
to regulator_notifier_call_chain().

The core regulator subsystem's regulator_handle_critical() function
evaluates the event parameter using a strict switch statement. If
multiple distinct faults occur before the worker runs (e.g.,
REGULATOR_EVENT_UNDER_VOLTAGE | REGULATOR_EVENT_OVER_CURRENT), the combined
bitmask fails to match any case. This leaves the reason as NULL and
completely bypasses the critical hw_protection_trigger().

Fix the problem by passing events bit by bit to the regulator event
handler.

Reported-by: Sashiko &lt;sashiko-bot@kernel.org&gt;
Fixes: 754bd2b4a084 ("hwmon: (pmbus/core) Protect regulator operations with mutex")
Signed-off-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>hwmon: adm1275: Detect coefficient overflow</title>
<updated>2026-06-29T20:46:10+00:00</updated>
<author>
<name>Matti Vaittinen</name>
<email>mazziesaccount@gmail.com</email>
</author>
<published>2026-06-26T07:23:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=72a69101032d2932ba5bde38494a325cc6b5d614'/>
<id>72a69101032d2932ba5bde38494a325cc6b5d614</id>
<content type='text'>
Sashiko detected potential coefficient overflow if large shunt resistor
is used. When going unnoticed it can cause "drastically incorrect
telemetry scaling factors" as Sashiko put it.

I am not convinced such "drastically incorrect telemetry scaling
factors" could have gone unnoticed, so I suspect such large shunt
resistors aren't really used. Well, it shouldn't hurt to detect the
error and abort the probe before Really Wrong current / power -values
are reported to user by the hwmon.

Signed-off-by: Matti Vaittinen &lt;mazziesaccount@gmail.com&gt;
Link: https://lore.kernel.org/r/d9e3320dbd62e094ff89598cb3aac5b5e716f9e7.1782458224.git.mazziesaccount@gmail.com
Signed-off-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Sashiko detected potential coefficient overflow if large shunt resistor
is used. When going unnoticed it can cause "drastically incorrect
telemetry scaling factors" as Sashiko put it.

I am not convinced such "drastically incorrect telemetry scaling
factors" could have gone unnoticed, so I suspect such large shunt
resistors aren't really used. Well, it shouldn't hurt to detect the
error and abort the probe before Really Wrong current / power -values
are reported to user by the hwmon.

Signed-off-by: Matti Vaittinen &lt;mazziesaccount@gmail.com&gt;
Link: https://lore.kernel.org/r/d9e3320dbd62e094ff89598cb3aac5b5e716f9e7.1782458224.git.mazziesaccount@gmail.com
Signed-off-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>hwmon: adm1275: Prevent reading uninitialized stack</title>
<updated>2026-06-29T20:45:04+00:00</updated>
<author>
<name>Matti Vaittinen</name>
<email>mazziesaccount@gmail.com</email>
</author>
<published>2026-06-26T07:22:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=553f9517813912a5ab661af5504485d96824a61c'/>
<id>553f9517813912a5ab661af5504485d96824a61c</id>
<content type='text'>
While adding support for the ROHM BD127X0 hot-swap controllers, sashiko
reported an error in device-name comparison, which can lead to reading
uninitialized stack memory.

Quoting Sashiko:

This is a pre-existing issue, but I noticed that just before this block in
adm1275_probe(), there might be an out-of-bounds stack read:

    ret = i2c_smbus_read_block_data(client, PMBUS_MFR_MODEL, block_buffer);
    if (ret &lt; 0) { ... }
    for (mid = adm1275_id; mid-&gt;name[0]; mid++) {
            if (!strncasecmp(mid-&gt;name, block_buffer, strlen(mid-&gt;name)))
                    break;
    }

Since i2c_smbus_read_block_data() reads up to 32 bytes into the
uninitialized stack array block_buffer without appending a null
terminator, strncasecmp() could read past the valid bytes returned in ret.

For example, if the device returns a shorter string like "adm12", checking
it against "adm1275" up to the length of "adm1275" will continue reading
into uninitialized stack bounds.

Prevent reading uninitialized memory by zeroing the stack array.

Signed-off-by: Matti Vaittinen &lt;mazziesaccount@gmail.com&gt;
Fixes: 87102808d039 ("hwmon: (pmbus/adm1275) Validate device ID")
Link: https://lore.kernel.org/r/c8ad38e0cdb347261c6245de2b7965e747f28d22.1782458224.git.mazziesaccount@gmail.com
Signed-off-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
While adding support for the ROHM BD127X0 hot-swap controllers, sashiko
reported an error in device-name comparison, which can lead to reading
uninitialized stack memory.

Quoting Sashiko:

This is a pre-existing issue, but I noticed that just before this block in
adm1275_probe(), there might be an out-of-bounds stack read:

    ret = i2c_smbus_read_block_data(client, PMBUS_MFR_MODEL, block_buffer);
    if (ret &lt; 0) { ... }
    for (mid = adm1275_id; mid-&gt;name[0]; mid++) {
            if (!strncasecmp(mid-&gt;name, block_buffer, strlen(mid-&gt;name)))
                    break;
    }

Since i2c_smbus_read_block_data() reads up to 32 bytes into the
uninitialized stack array block_buffer without appending a null
terminator, strncasecmp() could read past the valid bytes returned in ret.

For example, if the device returns a shorter string like "adm12", checking
it against "adm1275" up to the length of "adm1275" will continue reading
into uninitialized stack bounds.

Prevent reading uninitialized memory by zeroing the stack array.

Signed-off-by: Matti Vaittinen &lt;mazziesaccount@gmail.com&gt;
Fixes: 87102808d039 ("hwmon: (pmbus/adm1275) Validate device ID")
Link: https://lore.kernel.org/r/c8ad38e0cdb347261c6245de2b7965e747f28d22.1782458224.git.mazziesaccount@gmail.com
Signed-off-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>hwmon: (pmbus/core) honor vrm_version in pmbus_data2reg_vid()</title>
<updated>2026-06-29T15:44:41+00:00</updated>
<author>
<name>Abdurrahman Hussain</name>
<email>abdurrahman@nexthop.ai</email>
</author>
<published>2026-06-20T07:50:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=828cd614e2af053ca5e1d6da767bbd8a1b5cabfb'/>
<id>828cd614e2af053ca5e1d6da767bbd8a1b5cabfb</id>
<content type='text'>
pmbus_data2reg_vid() hardcoded the VR11 encoding regardless of the
vrm_version configured by the driver, while pmbus_reg2data_vid()
already switched on it. Any driver that selects a non-VR11 VID mode
and exposes a regulator (or hwmon vout setter) sent dangerously
wrong codes to PMBUS_VOUT_COMMAND -- e.g. an nvidia195mv part asked
for 200 mV got the VR11 clamp to 500 mV encoded as 0xB2, which the
chip interprets as 1080 mV.

Mirror pmbus_reg2data_vid() so writes round-trip with reads.

Signed-off-by: Abdurrahman Hussain &lt;abdurrahman@nexthop.ai&gt;
Assisted-by: Claude:claude-opus-4-7 [Claude Code]
Link: https://lore.kernel.org/r/20260620-pmbus-data2reg-vid-v1-1-5518030432c4@nexthop.ai
Fixes: 068c227056b92 ("hwmon: (pmbus) Add support for VR12")
Fixes: d4977c083aeb2 ("hwmon: (pmbus) Add support for Intel VID protocol VR13")
Fixes: 9d72340b6ade9 ("hwmon: (pmbus/core) Add support for Intel IMVP9 and AMD 6.25mV modes")
Fixes: 969a4ec86ca5f ("hwmon: (pmbus/core) Add support for NVIDIA nvidia195mv mode")
Signed-off-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
pmbus_data2reg_vid() hardcoded the VR11 encoding regardless of the
vrm_version configured by the driver, while pmbus_reg2data_vid()
already switched on it. Any driver that selects a non-VR11 VID mode
and exposes a regulator (or hwmon vout setter) sent dangerously
wrong codes to PMBUS_VOUT_COMMAND -- e.g. an nvidia195mv part asked
for 200 mV got the VR11 clamp to 500 mV encoded as 0xB2, which the
chip interprets as 1080 mV.

Mirror pmbus_reg2data_vid() so writes round-trip with reads.

Signed-off-by: Abdurrahman Hussain &lt;abdurrahman@nexthop.ai&gt;
Assisted-by: Claude:claude-opus-4-7 [Claude Code]
Link: https://lore.kernel.org/r/20260620-pmbus-data2reg-vid-v1-1-5518030432c4@nexthop.ai
Fixes: 068c227056b92 ("hwmon: (pmbus) Add support for VR12")
Fixes: d4977c083aeb2 ("hwmon: (pmbus) Add support for Intel VID protocol VR13")
Fixes: 9d72340b6ade9 ("hwmon: (pmbus/core) Add support for Intel IMVP9 and AMD 6.25mV modes")
Fixes: 969a4ec86ca5f ("hwmon: (pmbus/core) Add support for NVIDIA nvidia195mv mode")
Signed-off-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>hwmon: (pmbus/lm25066) Fix PMBus coefficients for LM5064/5066/5066i</title>
<updated>2026-06-11T11:30:34+00:00</updated>
<author>
<name>Potin Lai</name>
<email>potin.lai.pt@gmail.com</email>
</author>
<published>2026-06-11T05:46:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=83dda7ed185501ba1f8165aeca83ff4a8ef7c263'/>
<id>83dda7ed185501ba1f8165aeca83ff4a8ef7c263</id>
<content type='text'>
Swap the high setting and low setting coefficients in the lm25066_coeff
table for LM5064, LM5066, and LM5066i. The coefficients were previously
mapped incorrectly, resulting in inverted current and power scaling.

Additionally, dynamically assign the exponent (R) registers inside the
probe's LM25066_DEV_SETUP_CL check. This ensures that the proper
exponent is applied (e.g., for LM25056, high setting power exponent
is -4, but low setting power exponent is -3).

Signed-off-by: Potin Lai &lt;potin.lai.pt@gmail.com&gt;
Link: https://lore.kernel.org/r/20260611-lm25066-driver-fix-v3-1-9d7d4b4e253d@gmail.com
Signed-off-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Swap the high setting and low setting coefficients in the lm25066_coeff
table for LM5064, LM5066, and LM5066i. The coefficients were previously
mapped incorrectly, resulting in inverted current and power scaling.

Additionally, dynamically assign the exponent (R) registers inside the
probe's LM25066_DEV_SETUP_CL check. This ensures that the proper
exponent is applied (e.g., for LM25056, high setting power exponent
is -4, but low setting power exponent is -3).

Signed-off-by: Potin Lai &lt;potin.lai.pt@gmail.com&gt;
Link: https://lore.kernel.org/r/20260611-lm25066-driver-fix-v3-1-9d7d4b4e253d@gmail.com
Signed-off-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>hwmon: (pmbus/max34440): add support adpm12250</title>
<updated>2026-06-10T13:12:18+00:00</updated>
<author>
<name>Alexis Czezar Torreno</name>
<email>alexisczezar.torreno@analog.com</email>
</author>
<published>2026-06-10T01:12:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=479bfeba2eb62666cd4b981c8e721c61dcf36e7d'/>
<id>479bfeba2eb62666cd4b981c8e721c61dcf36e7d</id>
<content type='text'>
ADPM12250 is a quarter brick DC/DC Power Module. It is a high power
non-isolated converter capable of delivering regulated 12V with
continuous power level of 2500W. Uses PMBus.

Signed-off-by: Alexis Czezar Torreno &lt;alexisczezar.torreno@analog.com&gt;
Reviewed-by: Nuno Sá &lt;nuno.sa@analog.com&gt;
Link: https://lore.kernel.org/r/20260610-dev-adpm12250-v1-1-422760bb80da@analog.com
Signed-off-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
ADPM12250 is a quarter brick DC/DC Power Module. It is a high power
non-isolated converter capable of delivering regulated 12V with
continuous power level of 2500W. Uses PMBus.

Signed-off-by: Alexis Czezar Torreno &lt;alexisczezar.torreno@analog.com&gt;
Reviewed-by: Nuno Sá &lt;nuno.sa@analog.com&gt;
Link: https://lore.kernel.org/r/20260610-dev-adpm12250-v1-1-422760bb80da@analog.com
Signed-off-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>hwmon: (pmbus/xdp720) Fix driver issues xdp720/730</title>
<updated>2026-06-09T15:23:21+00:00</updated>
<author>
<name>Ashish Yadav</name>
<email>ashish.yadav@infineon.com</email>
</author>
<published>2026-06-09T07:22:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=d647ebf5a5d50bf794e609b397d471e5b92a02ca'/>
<id>d647ebf5a5d50bf794e609b397d471e5b92a02ca</id>
<content type='text'>
Fix driver issues:
- Add the missing regulator and property files in include
- Declare XDP720_DEFAULT_RIMON as unsigned constant
- Declare struct pmbus_driver_info xdp720_info as constant

Signed-off-by: Ashish Yadav &lt;ashish.yadav@infineon.com&gt;
Link: https://lore.kernel.org/r/20260609072231.15486-4-Ashish.Yadav@infineon.com
Signed-off-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Fix driver issues:
- Add the missing regulator and property files in include
- Declare XDP720_DEFAULT_RIMON as unsigned constant
- Declare struct pmbus_driver_info xdp720_info as constant

Signed-off-by: Ashish Yadav &lt;ashish.yadav@infineon.com&gt;
Link: https://lore.kernel.org/r/20260609072231.15486-4-Ashish.Yadav@infineon.com
Signed-off-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>hwmon: (pmbus/xdp720) Add support for efuse xdp730</title>
<updated>2026-06-09T15:23:18+00:00</updated>
<author>
<name>Ashish Yadav</name>
<email>ashish.yadav@infineon.com</email>
</author>
<published>2026-06-09T07:22:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=7c264a7d077586a64656ea10559ce6ab69377534'/>
<id>7c264a7d077586a64656ea10559ce6ab69377534</id>
<content type='text'>
Adds support for the Infineon XDP730 Digital eFuse Controller by
updating the existing XDP720 driver.

Signed-off-by: Ashish Yadav &lt;ashish.yadav@infineon.com&gt;
Link: https://lore.kernel.org/r/20260609072231.15486-3-Ashish.Yadav@infineon.com
[groeck: Fixed conflicts in xdp720_id declaration]
Signed-off-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Adds support for the Infineon XDP730 Digital eFuse Controller by
updating the existing XDP720 driver.

Signed-off-by: Ashish Yadav &lt;ashish.yadav@infineon.com&gt;
Link: https://lore.kernel.org/r/20260609072231.15486-3-Ashish.Yadav@infineon.com
[groeck: Fixed conflicts in xdp720_id declaration]
Signed-off-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
</pre>
</div>
</content>
</entry>
</feed>
