Re: Clarification regarding handling of PMBUS_STATUS_WORD in generic PMBus driver

Re: Clarification regarding handling of PMBUS_STATUS_WORD in generic PMBus driver

[Guenter Roeck]

On 8/5/25 09:23, Soloninov, Alexander wrote:
> Dear PMBus maintainers,
> 
> I’m a Linux kernel driver developer at Siemens, currently working on PMBus integration for one of our power supply units (PSU), which communicates via I²C using the generic pmbus.c driver.
> 
> Our PSU correctly supports and reports PMBUS_STATUS_WORD (0x79), and I’m able to read it successfully via the generic PMBus driver using pmbus_read_word_data(). However, I noticed that while PMBUS_STATUS_WORD is defined in pmbus.h, I couldn’t find any logic in pmbus.c that actively processes or exports it — either to hwmon or through other standard interfaces.
> 
> It seems that only substatus registers like STATUS_VOUT, STATUS_IOUT, STATUS_INPUT, etc., are conditionally evaluated in functions like pmbus_find_sensor_groups(), but not the combined STATUS_WORD.
> 
> My questions:
> 
> 1.           Is the omission of PMBUS_STATUS_WORD handling in the generic driver intentional?
> 
> 2.           Would it be acceptable to add fallback or supplementary logic to process and expose bits from STATUS_WORD, especially for devices that do not implement individual STATUS_* registers?
> 
> 3.           Or is it expected that STATUS_WORD should only be used internally or in device-specific drivers, and not exposed directly via hwmon?
> 
> If helpful, I’d be happy to propose a patch or help test one.
> 
> If I misunderstood the intended role or expected handling of PMBUS_STATUS_WORD in the generic driver, please feel free to correct me.
> 
> My assumption was that it could serve as a consolidated status interface, but I now wonder if its use is intentionally avoided in favor of the individual substatus registers.
> 
> Thank you for your time and your work maintaining PMBus support in Linux!
> 


Sorry, I have no idea what you are talking about. PMBUS_STATUS_WORD is used
and evaluated all over the place.

$ git grep PMBUS_STATUS_WORD
drivers/hwmon/pmbus/delta-ahe50dc-fan.c:        case PMBUS_STATUS_WORD:
drivers/hwmon/pmbus/dps920ab.c: case PMBUS_STATUS_WORD:
drivers/hwmon/pmbus/fsp-3y.c:   case PMBUS_STATUS_WORD:
drivers/hwmon/pmbus/ibm-cffps.c:        case PMBUS_STATUS_WORD:
drivers/hwmon/pmbus/ltc3815.c:          ret = pmbus_read_word_data(client, 0, 0xff, PMBUS_STATUS_WORD);
drivers/hwmon/pmbus/ltc3815.c:                  pmbus_write_word_data(client, 0, PMBUS_STATUS_WORD,
drivers/hwmon/pmbus/max16601.c:         case PMBUS_STATUS_WORD:
drivers/hwmon/pmbus/mp2975.c:   case PMBUS_STATUS_WORD:
drivers/hwmon/pmbus/pli1209bc.c:                                            PMBUS_STATUS_WORD);
drivers/hwmon/pmbus/pmbus.h:    PMBUS_STATUS_WORD               = 0x79,
drivers/hwmon/pmbus/pmbus_core.c:       case PMBUS_STATUS_WORD:
drivers/hwmon/pmbus/pmbus_core.c:                                               page, PMBUS_STATUS_WORD,
drivers/hwmon/pmbus/pmbus_core.c:       return _pmbus_read_word_data(client, page, 0xff, PMBUS_STATUS_WORD);
drivers/hwmon/pmbus/pmbus_core.c:        * Some PMBus chips don't support PMBUS_STATUS_WORD, so try
drivers/hwmon/pmbus/pmbus_core.c:       ret = i2c_smbus_read_word_data(client, PMBUS_STATUS_WORD);
drivers/hwmon/pmbus/pmbus_core.c:       status = pmbus_get_status(client, page, PMBUS_STATUS_WORD);
drivers/hwmon/pmbus/pmbus_core.c:       status = pmbus_get_status(client, page, PMBUS_STATUS_WORD);

Guenter

RE: Clarification regarding handling of PMBUS_STATUS_WORD in generic PMBus driver

[Soloninov, Alexander]

Hi Guenter,

Thank you for the clarification and the grep output - you're absolutely right! 

I apologize for the confusion in my initial message. 
I had incorrectly stated that PMBUS_STATUS_WORD wasn't being processed at all by the generic driver. 
After reviewing the code more carefully following your response, I can clearly see that PMBUS_STATUS_WORD is indeed used extensively throughout the PMBus subsystem - for initialization, internal status monitoring, error handling, and regulator integration.

My actual question should have been about direct hwmon sysfs attribute exposure of the complete STATUS_WORD register (like /sys/class/hwmon/hwmonX/status_word), which the PMBus core correctly doesn't provide since it processes STATUS_WORD internally and breaks it down into individual status sensors as intended.

Thank you for maintaining the PMBus subsystem and for taking the time to correct my misunderstanding!

Best regards,
Alexander

-----Original Message-----
From: Guenter Roeck <groeck7@gmail.com> On Behalf Of Guenter Roeck
Sent: Tuesday, August 5, 2025 6:48 PM
To: Soloninov, Alexander (DI FA CTR IPC PRC2) <alexander.soloninov@siemens.com>; peterz@infradead.org; titusr@google.com
Cc: Busch, Martin (DI FA CTR IPC PRC2) <martin.busch@siemens.com>; Niedermayr, Benedikt (FT RPD CED OES-DE) <benedikt.niedermayr@siemens.com>; linux-hwmon@vger.kernel.org; jdelvare@suse.com; Dabek, Florian (DI FA CTR IPC PO2) <florian.dabek@siemens.com>
Subject: Re: Clarification regarding handling of PMBUS_STATUS_WORD in generic PMBus driver

On 8/5/25 09:23, Soloninov, Alexander wrote:
> Dear PMBus maintainers,
> 
> I’m a Linux kernel driver developer at Siemens, currently working on PMBus integration for one of our power supply units (PSU), which communicates via I²C using the generic pmbus.c driver.
> 
> Our PSU correctly supports and reports PMBUS_STATUS_WORD (0x79), and I’m able to read it successfully via the generic PMBus driver using pmbus_read_word_data(). However, I noticed that while PMBUS_STATUS_WORD is defined in pmbus.h, I couldn’t find any logic in pmbus.c that actively processes or exports it — either to hwmon or through other standard interfaces.
> 
> It seems that only substatus registers like STATUS_VOUT, STATUS_IOUT, STATUS_INPUT, etc., are conditionally evaluated in functions like pmbus_find_sensor_groups(), but not the combined STATUS_WORD.
> 
> My questions:
> 
> 1.           Is the omission of PMBUS_STATUS_WORD handling in the generic driver intentional?
> 
> 2.           Would it be acceptable to add fallback or supplementary logic to process and expose bits from STATUS_WORD, especially for devices that do not implement individual STATUS_* registers?
> 
> 3.           Or is it expected that STATUS_WORD should only be used internally or in device-specific drivers, and not exposed directly via hwmon?
> 
> If helpful, I’d be happy to propose a patch or help test one.
> 
> If I misunderstood the intended role or expected handling of PMBUS_STATUS_WORD in the generic driver, please feel free to correct me.
> 
> My assumption was that it could serve as a consolidated status interface, but I now wonder if its use is intentionally avoided in favor of the individual substatus registers.
> 
> Thank you for your time and your work maintaining PMBus support in Linux!
> 


Sorry, I have no idea what you are talking about. PMBUS_STATUS_WORD is used and evaluated all over the place.

$ git grep PMBUS_STATUS_WORD
drivers/hwmon/pmbus/delta-ahe50dc-fan.c:        case PMBUS_STATUS_WORD:
drivers/hwmon/pmbus/dps920ab.c: case PMBUS_STATUS_WORD:
drivers/hwmon/pmbus/fsp-3y.c:   case PMBUS_STATUS_WORD:
drivers/hwmon/pmbus/ibm-cffps.c:        case PMBUS_STATUS_WORD:
drivers/hwmon/pmbus/ltc3815.c:          ret = pmbus_read_word_data(client, 0, 0xff, PMBUS_STATUS_WORD);
drivers/hwmon/pmbus/ltc3815.c:                  pmbus_write_word_data(client, 0, PMBUS_STATUS_WORD,
drivers/hwmon/pmbus/max16601.c:         case PMBUS_STATUS_WORD:
drivers/hwmon/pmbus/mp2975.c:   case PMBUS_STATUS_WORD:
drivers/hwmon/pmbus/pli1209bc.c:                                            PMBUS_STATUS_WORD);
drivers/hwmon/pmbus/pmbus.h:    PMBUS_STATUS_WORD               = 0x79,
drivers/hwmon/pmbus/pmbus_core.c:       case PMBUS_STATUS_WORD:
drivers/hwmon/pmbus/pmbus_core.c:                                               page, PMBUS_STATUS_WORD,
drivers/hwmon/pmbus/pmbus_core.c:       return _pmbus_read_word_data(client, page, 0xff, PMBUS_STATUS_WORD);
drivers/hwmon/pmbus/pmbus_core.c:        * Some PMBus chips don't support PMBUS_STATUS_WORD, so try
drivers/hwmon/pmbus/pmbus_core.c:       ret = i2c_smbus_read_word_data(client, PMBUS_STATUS_WORD);
drivers/hwmon/pmbus/pmbus_core.c:       status = pmbus_get_status(client, page, PMBUS_STATUS_WORD);
drivers/hwmon/pmbus/pmbus_core.c:       status = pmbus_get_status(client, page, PMBUS_STATUS_WORD);

Guenter

Re: Clarification regarding handling of PMBUS_STATUS_WORD in generic PMBus driver

[Guenter Roeck]

On 8/5/25 14:34, Soloninov, Alexander wrote:
> Hi Guenter,
> 
> Thank you for the clarification and the grep output - you're absolutely right!
> 
> I apologize for the confusion in my initial message.
> I had incorrectly stated that PMBUS_STATUS_WORD wasn't being processed at all by the generic driver.
> After reviewing the code more carefully following your response, I can clearly see that PMBUS_STATUS_WORD is indeed used extensively throughout the PMBus subsystem - for initialization, internal status monitoring, error handling, and regulator integration.
> 
> My actual question should have been about direct hwmon sysfs attribute exposure of the complete STATUS_WORD register (like /sys/class/hwmon/hwmonX/status_word), which the PMBus core correctly doesn't provide since it processes STATUS_WORD internally and breaks it down into individual status sensors as intended.
> 

The attributes in /sys/class/hwmon/hwmonX/ reflect a standardized chip-independent ABI.
Chip specific values do not belong there. The raw status register value is reported -
together with various other raw register values - as debugfs file.

Guenter