RE: [PATCH 2/3] hwmon: (pmbus/ltc2978) Add support for LT7175 and LT7176P

From: De guzman, Christopher

Date: Fri Nov 06 2026 - 06:15:38 EST


> -----Original Message-----
> From: Guenter Roeck <groeck7@xxxxxxxxx> On Behalf Of Guenter Roeck
> Sent: Tuesday, October 20, 2026 11:14 PM
> To: De guzman, Christopher <christopher.deguzman@xxxxxxxxxx>; Rob
> Herring <robh@xxxxxxxxxx>; Krzysztof Kozlowski <krzk+dt@xxxxxxxxxx>; Conor
> Dooley <conor+dt@xxxxxxxxxx>; Frank Li <Frank.Li@xxxxxxx>; Jonathan
> Corbet <corbet@xxxxxxx>; Shuah Khan <skhan@xxxxxxxxxxxxxxxxxxx>; Randy
> Dunlap <rdunlap@xxxxxxxxxxxxx>
> Cc: linux-hwmon@xxxxxxxxxxxxxxx; devicetree@xxxxxxxxxxxxxxx; linux-
> kernel@xxxxxxxxxxxxxxx; linux-doc@xxxxxxxxxxxxxxx
> Subject: Re: [PATCH 2/3] hwmon: (pmbus/ltc2978) Add support for LT7175
> and LT7176P
>
> [External]
>
> On 10/20/26 04:45, Christopher de Guzman wrote:
> > Add support for LT7175/LT7175-1 and LT7176P/LT7176P-1 PMBus buck
> > regulators. These parts share the LT7170 family MFR_SPECIAL_ID (0x1C1D
> > masked to 0x1C10) and use the same PMBus register layout, so they
> > reuse the existing lt7170/lt7171 probe path. Variants are
> > distinguished by reading the PMBUS_IC_DEVICE_ID ASCII string.
> >
> > Signed-off-by: Christopher de Guzman
> <christopher.deguzman@xxxxxxxxxx>
> > ---
> > drivers/hwmon/pmbus/Kconfig | 6 +++---
> > drivers/hwmon/pmbus/ltc2978.c | 28 +++++++++++++++++++++++++++-
> > 2 files changed, 30 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/hwmon/pmbus/Kconfig b/drivers/hwmon/pmbus/Kconfig
> > index fd6641316454..63fb4d5dd87d 100644
> > --- a/drivers/hwmon/pmbus/Kconfig
> > +++ b/drivers/hwmon/pmbus/Kconfig
> > @@ -306,9 +306,9 @@ config SENSORS_LTC2978_REGULATOR
> > depends on SENSORS_LTC2978 && REGULATOR
> > help
> > If you say yes here you get regulator support for Linear Technology
> > - LT7170, LT7171, LTC3880, LTC3883, LTC3884, LTC3886, LTC3887,
> LTC3889,
> > - LTC7841, LTC7880, LTM4644, LTM4673, LTM4675, LTM4676, LTM4677,
> > - LTM4678, LTM4680, LTM4686, and LTM4700.
> > + LT7170, LT7171, LT7175, LT7176P, LTC3880, LTC3883, LTC3884,
> LTC3886,
> > + LTC3887, LTC3889, LTC7841, LTC7880, LTM4644, LTM4673, LTM4675,
> LTM4676,
> > + LTM4677, LTM4678, LTM4680, LTM4686, and LTM4700.
> >
> > config SENSORS_LTC3815
> > tristate "Linear Technologies LTC3815"
> > diff --git a/drivers/hwmon/pmbus/ltc2978.c
> > b/drivers/hwmon/pmbus/ltc2978.c index aea7b6c93e74..a42cdc1fe124
> > 100644
> > --- a/drivers/hwmon/pmbus/ltc2978.c
> > +++ b/drivers/hwmon/pmbus/ltc2978.c
> > @@ -23,7 +23,7 @@ enum chips {
> > /* Managers */
> > ltc2972, ltc2974, ltc2975, ltc2977, ltc2978, ltc2979, ltc2980,
> > /* Controllers */
> > - lt7170, lt7171, ltc3880, ltc3882, ltc3883, ltc3884, ltc3886, ltc3887,
> > + lt7170, lt7171, lt7175, lt7176p, ltc3880, ltc3882, ltc3883, ltc3884,
> > +ltc3886, ltc3887,
> > ltc3889, ltc7132, ltc7841, ltc7880,
> > /* Modules */
> > ltm2987, ltm4664, ltm4673, ltm4675, ltm4676, ltm4677, ltm4678,
> > ltm4680, @@ -540,6 +540,10 @@ static int ltc2978_write_word_data(struct
> i2c_client *client, int page,
> > static const struct i2c_device_id ltc2978_id[] = {
> > { .name = "lt7170", .driver_data = lt7170 },
> > { .name = "lt7171", .driver_data = lt7171 },
> > + { .name = "lt7175", .driver_data = lt7175 },
> > + { .name = "lt7175-1", .driver_data = lt7175 },
> > + { .name = "lt7176p", .driver_data = lt7176p },
> > + { .name = "lt7176p-1", .driver_data = lt7176p },
>
> We don't usually add -x variants unless really needed.
> Let's not start this here.
>
> > { .name = "ltc2972", .driver_data = ltc2972 },
> > { .name = "ltc2974", .driver_data = ltc2974 },
> > { .name = "ltc2975", .driver_data = ltc2975 }, @@ -645,6 +649,10 @@
> > static int ltc2978_get_id(struct i2c_client *client)
> > return lt7170;
> > if (!strncmp(buf, "LT7171", 6))
> > return lt7171;
> > + if (!strncmp(buf, "LT7175", 6))
> > + return lt7175;
> > + if (!strncmp(buf, "LT7176P", 7))
> > + return lt7176p;
>
> Sashiko has a point. It may be better to start using the same approach used
> for chips with no chip ID, which would be something like
>
> for (id = &ltc2978_id[0]; strlen(id->name); id++) {
> if (ret >= strlen(id->name) &&
> !strncasecmp(id->name, buf, strlen(id->name)))
> return (int)id->driver_data;
> }
>
> >
> > return -ENODEV;
> > }
> > @@ -774,6 +782,20 @@ static int ltc2978_probe(struct i2c_client *client)
> > | PMBUS_HAVE_IOUT | PMBUS_HAVE_STATUS_IOUT
> > | PMBUS_HAVE_TEMP | PMBUS_HAVE_STATUS_TEMP;
> > break;
> > + case lt7175:
> > + case lt7176p:
> > + data->features |= FEAT_CLEAR_PEAKS |
> FEAT_NEEDS_POLLING;
> > + info->read_word_data = ltc3883_read_word_data;
> > + info->pages = LTC3883_NUM_PAGES;
> > + info->format[PSC_VOLTAGE_IN] = ieee754;
> > + info->format[PSC_VOLTAGE_OUT] = ieee754;
> > + info->format[PSC_CURRENT_OUT] = ieee754;
> > + info->format[PSC_TEMPERATURE] = ieee754;
> > + info->func[0] = PMBUS_HAVE_VIN |
> PMBUS_HAVE_STATUS_INPUT
> > + | PMBUS_HAVE_VOUT | PMBUS_HAVE_STATUS_VOUT
> > + | PMBUS_HAVE_IOUT | PMBUS_HAVE_STATUS_IOUT
> > + | PMBUS_HAVE_TEMP | PMBUS_HAVE_STATUS_TEMP;
>
> Unless I am missing something, this is identical to lt7170 / lt71751.
> No need to duplicate the code, just add the case statements.
>
> > + break;
> > case ltc2972:
> > info->read_word_data = ltc2975_read_word_data;
> > info->pages = LTC2972_NUM_PAGES;
> > @@ -962,6 +984,10 @@ static int ltc2978_probe(struct i2c_client *client)
> > static const struct of_device_id ltc2978_of_match[] = {
> > { .compatible = "lltc,lt7170" },
> > { .compatible = "lltc,lt7171" },
> > + { .compatible = "lltc,lt7175" },
> > + { .compatible = "lltc,lt7175-1" },
> > + { .compatible = "lltc,lt7176p" },
> > + { .compatible = "lltc,lt7176p-1" },
>
> Same as above. Please do not add -1 variants.
>
> Thanks,
> Guenter
>
> > { .compatible = "lltc,ltc2972" },
> > { .compatible = "lltc,ltc2974" },
> > { .compatible = "lltc,ltc2975" },
> >

Hi Guenter,

Thanks for the review. I'll address all comments in v2:
- drop the -1 variants from the bindings and the i2c/of tables
- add lt7175/lt7176p as case labels on the existing lt7170/lt7171 block
- switch the LT7170-family detection to iterate ltc2978_id[] with the
length check, as you suggested

I expect to send v2 next week.

Thanks,
Christopher