From: Ashish Yadav <ashish.yadav@infineon.com>

Hi,

These patches add support for Infineon Digital eFuse XDP730.
XDP730 provides accurate system telemetry (V, I, P, T) and
reports analog current at the IMON pin for post-processing.

The Current and Power measurement depends on the RIMON and GIMON values.
Please look into data sheet sections 4.4.2 and 4.4.4 for more details:
https://www.infineon.com/assets/row/public/documents/24/49/infineon-xdp730-001-datasheet-en.pdf

With Best Regards,
 Ashish Yadav

Ashish Yadav (2):
  dt-bindings: hwmon/pmbus: Add Infineon XDP730
  hwmon:(pmbus/xdp730) Add support for efuse xdp730

 .../bindings/hwmon/pmbus/infineon,xdp730.yaml |  59 ++++++++
 drivers/hwmon/pmbus/Kconfig                   |   9 ++
 drivers/hwmon/pmbus/Makefile                  |   1 +
 drivers/hwmon/pmbus/xdp730.c                  | 128 ++++++++++++++++++
 4 files changed, 197 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hwmon/pmbus/infineon,xdp730.yaml
 create mode 100644 drivers/hwmon/pmbus/xdp730.c

-- 
2.39.5

On 5/19/26 00:55, ASHISH YADAV wrote:
> From: Ashish Yadav <ashish.yadav@infineon.com>
> 
> Hi,
> 
> These patches add support for Infineon Digital eFuse XDP730.
> XDP730 provides accurate system telemetry (V, I, P, T) and
> reports analog current at the IMON pin for post-processing.
> 
> The Current and Power measurement depends on the RIMON and GIMON values.
> Please look into data sheet sections 4.4.2 and 4.4.4 for more details:
> https://www.infineon.com/assets/row/public/documents/24/49/infineon-xdp730-001-datasheet-en.pdf
> 

This driver is 99% identical to the xdp720 driver, except for the gimon
constants. Please add support for this chip to that driver.

Thanks,
Guenter

Hi Guenter,

Thanks for your time and response.
You are entirely correct that the XDP720 and XDP730 drivers are 99% identical.
The only functional difference between the two variants lies within
their GIMON values.

To programmatically identify whether the current target device is an
XDP720 or an XDP730, the system must query the MFR_MODEL register.
Because this register is 8 bytes long, it requires an I2C Block Read
operation to retrieve the model identifier string.
However, some embedded I2C controllers do not natively support I2C Block Reads.
It is precisely due to this hardware controller limitation that we
proposed developing two separate drivers, ensuring reliable
compatibility across different system architectures.

As a better alternative, an elegant solution to consolidate this into
a single driver is to utilize the i2c_transfer() API to read the
MFR_MODEL register.
Please let me know if you have any questions regarding this approach.

With Best Regards,
   Ashish Yadav


On Tue, May 19, 2026 at 8:59 PM Guenter Roeck <linux@roeck-us.net> wrote:
>
> On 5/19/26 00:55, ASHISH YADAV wrote:
> > From: Ashish Yadav <ashish.yadav@infineon.com>
> >
> > Hi,
> >
> > These patches add support for Infineon Digital eFuse XDP730.
> > XDP730 provides accurate system telemetry (V, I, P, T) and
> > reports analog current at the IMON pin for post-processing.
> >
> > The Current and Power measurement depends on the RIMON and GIMON values.
> > Please look into data sheet sections 4.4.2 and 4.4.4 for more details:
> > https://www.infineon.com/assets/row/public/documents/24/49/infineon-xdp730-001-datasheet-en.pdf
> >
>
> This driver is 99% identical to the xdp720 driver, except for the gimon
> constants. Please add support for this chip to that driver.
>
> Thanks,
> Guenter
>

On 5/19/26 23:40, ashish yadav wrote:
> Hi Guenter,
> 
> Thanks for your time and response.
> You are entirely correct that the XDP720 and XDP730 drivers are 99% identical.
> The only functional difference between the two variants lies within
> their GIMON values.
> 
> To programmatically identify whether the current target device is an
> XDP720 or an XDP730, the system must query the MFR_MODEL register.
> Because this register is 8 bytes long, it requires an I2C Block Read
> operation to retrieve the model identifier string.
> However, some embedded I2C controllers do not natively support I2C Block Reads.
> It is precisely due to this hardware controller limitation that we
> proposed developing two separate drivers, ensuring reliable
> compatibility across different system architectures.
> 

All you need to do is to add the second compatible to the first driver,
and use driver_data (i2c_device_id) and data (of_device_id) to
distinguish the chips. Many other drivers do just that.

Guenter