[Feature]: Telemetry Refactor

[joelsmithTT]

Is your feature request related to a problem? Please describe.

The telemetry subsystem has several pain points:

1. Wormhole uses two telemetry styles: The legacy "SMBus-style" telemetry (fixed offsets) is still used for hwmon, while sysfs uses new-style tag-based telemetry.

2. No central entry point for telemetry reads: Telemetry access is scattered across architecture-specific code paths. This makes it difficult to add cross-cutting concerns like reset protection or runtime PM integration.

3. Telemetry addresses can become stale after firmware update (see Telemetry vs FW update #121): The driver probes telemetry tag addresses once at init. After a firmware flash, the tag table layout may change, but addresses aren't re-probed until driver reload or reboot.

Describe the Solution You'd Like

1. Unify Wormhole on new-style telemetry: Remove SMBus-style telemetry code from WH hwmon. All telemetry (sysfs and hwmon) should use tag-based access. The WH firmware already supports all needed tags.

2. Single entry point for telemetry reads: All telemetry access should flow through a common wrapper (e.g., tt_telemetry_read32()) that handles:

   • Reset protection (refuse reads while reset in progress or hardware uninitialized)
   • Runtime PM wake/sleep (future)
   • Architecture dispatch to the appropriate read primitive

3. Re-probe telemetry after firmware update: After a successful firmware flash + reset, re-scan the tag table to pick up any address changes. Cache the tag→address mappings to avoid per-read table scans.

Describe Alternatives You've Considered

• Scan the tag table on every read: Simplest approach and automatically handles address changes, but introduces unnecessary overhead on every telemetry access. Would prefer cached addresses with explicit re-probe.

• Keep SMBus-style for WH hwmon: Avoids refactor risk but prevents consolidation of hwmon code to a single, architecture-agnostic path.

Why is this Feature Important?

• Reduced maintenance burden: One telemetry code path instead of two per architecture.
• Correctness: Prevents stale/incorrect telemetry after firmware updates without requiring driver reload.
• Reset safety: Centralized protection against reading telemetry during hardware reset.
• Extensibility: Single integration point for runtime PM, future power management features.

Proposed Design/Technical Details (Optional)

• Add telemetry_read32(tt_dev, tag, *value) to device class (tag-based, not address-based)
• Each architecture implements tag→address resolution internally, caching results from probe
• Common wrapper in telemetry.c handles reset_rwsem, detached/needs_hw_init checks
• Add telemetry_reprobe() called after firmware update completes
• WH hwmon migrates from hardcoded offsets to tag-based reads (TAG_TDP, TAG_TDC, TAG_TDP_LIMIT_MAX, etc.)
• Unified hwmon implementation: Since WH and BH now share identical tag semantics and formats (16.16 fixed-point for temperature, same VDD_LIMITS packing), a single hwmon implementation in hwmon.c can serve both architectures. Architecture differences are hidden behind telemetry_read32().

Use Cases

• User flashes firmware: Telemetry continues working correctly without driver reload
• Runtime PM integration: Adding pm_runtime_get/put in one place covers all telemetry access
• Debugging: Consistent telemetry behavior across WH and BH simplifies support

Additional Context

• Related: Telemetry vs FW update #121 (telemetry not re-probed after firmware update)
• Related: Integrate PM runtime #152 (integrate PM runtime)
• Consider a provision for exposing attributes in sysfs that are not in the CMFW telemetry table but elsewhere, in e.g. scratch registers