Re: [PATCH v3 1/5] hwmon: (pmbus/adm1266) add firmware_revision debugfs entry

[Guenter Roeck <linux@roeck-us.net>]

On Thu, May 14, 2026 at 08:35:23PM -0700, Abdurrahman Hussain wrote:
> On Thu May 14, 2026 at 6:42 PM PDT, Guenter Roeck wrote:
> > On Tue, May 12, 2026 at 11:56:24AM -0700, Abdurrahman Hussain wrote:
> >> The ADM1266 reports its firmware revision via the IC_DEVICE_REV
> >> manufacturer-specific block-read command (0xAE, datasheet Rev. D
> >> Table 80). The first three returned bytes are the firmware
> >> major.minor.patch fields. This is useful when correlating field
> >> behaviour against ADI release notes; expose it through debugfs
> >> alongside the existing sequencer_state entry.
> >> 
> >> The standard PMBus MFR_REVISION (0x9B) register is already exposed
> >> by pmbus_core's debugfs auto-create path and reports the
> >> manufacturer revision, which is a separate thing from the firmware
> >> running on the device.
> >> 
> >> Signed-off-by: Abdurrahman Hussain <abdurrahman@nexthop.ai>
> >
> > Applied to hwmon-next.
> >
> > Thanks,
> > Guenter
> 
> Thanks!
> 
> Status of the remaining three patches:
> 
>   - Patch 2 (clear_blackbox): v5 will extend the pmbus_lock guard
>     up to adm1266_nvmem_read() to cover the memset/refill/memcpy on
>     data->dev_mem as one critical section (per an automated review
>     of v3).
> 
>   - Patch 3 (powerup_counter): v5 will take pmbus_lock around the
>     block read, same reason.
> 
>   - Patch 4 (rtc_class): blocked on your reply to my "drop entirely
>     or loop in linux-rtc?" question [1].  rtc_class is out for v5
>     either way.
> 

My understanding is that there is no in-kernel API to inform drivers
about a rtc update. No other driver seems to need this.
I see a number of options:

1) Use ktime_get_real_seconds() in probe, just like every other Linux
   driver using the real time clock does without problems.
2) schedule a timer which updates the clock every hour ? day ?
3) Attach a sysfs attribute to the i2c device to trigger a time sync.

2) and 3) are a bit excessive, so you'll need to provide a specific
use case. "Because the datasheet says so" is not a use case.

> The same review on patch 2 also surfaced four pre-existing
> buffer-bound bugs in adm1266.c (stack overflow in
> adm1266_nvmem_read_blackbox(), undersized DMA read buffer in
> adm1266_pmbus_block_xfer(), an unbounded record_count loop, and an
> out-of-bounds memcpy() in pmbus_block_xfer() using a device-supplied
> length with no caller-side size knowledge).  None of them are
> introduced by this series.  My plan is to send them as a separate
> "hwmon: (pmbus/adm1266) fix ..." series with Fixes: tags first, then
> respin this feature series on top.  Let me know if you'd rather have
> them folded into v5.
> 
Separate series is ok.

Thanks,
Guenter