hwmon: (pmbus/adm1266) add rtc debugfs entry

hwmon: (pmbus/adm1266) add rtc debugfs entry

The driver seeds the chip's SET_RTC register once at probe with
ktime_get_real_seconds().  Over a long uptime the chip's internal
seconds counter drifts away from the host's wall-clock time, so the
timestamp embedded in each blackbox record stops being meaningful
in wall-clock terms.  The datasheet recommends that the host
periodically resynchronise the counter to address this; today the
driver has no userspace-facing knob for that.

Expose SET_RTC via an rtc debugfs file alongside the other adm1266
debugfs entries:

  read  -- returns the chip's current SET_RTC seconds counter, so
           userspace can observe how far the chip has drifted from
           host wall-clock without writing anything.
  write -- the kernel re-reads ktime_get_real_seconds() itself and
           pushes it to the chip.  The write payload is ignored;
           userspace does not get to supply its own timestamp
           value, so there is no way for it to push a wrong time
           into the chip.

A small userspace agent (chrony hook, systemd-timesyncd dispatch
script, or a periodic cron job) can write to this file to keep the
chip's counter aligned with wall-clock across long uptimes.

Both the read and write paths take pmbus_lock to serialise against
the pmbus_core's own PAGE+register sequences and against the other
adm1266 debugfs accessors that already run under the same lock.

While at it, drop the now-redundant adm1266_set_rtc() probe-time
helper.  The new adm1266_rtc_set() callback does exactly the same
byte-packing and write; probe just calls adm1266_rtc_set(client, 0)
(the ignored @val argument) after pmbus_do_probe() so the
pmbus_lock acquired by the new helper has a live mutex to take.

Signed-off-by: Abdurrahman Hussain <abdurrahman@nexthop.ai>
Assisted-by: Claude-Code:claude-opus-4-7
Assisted-by: sashiko:gemini-3.1-pro-preview
Link: https://lore.kernel.org/r/20260520-adm1266-v5-3-c72ef1fac1ea@nexthop.ai
Signed-off-by: Guenter Roeck <linux@roeck-us.net>