This series enables the HSMP driver on the Family 1Ah client platforms,
Models 80h-8Fh and E0h-E3h.

The client parts drive a different mailbox from the server HSMP
interface, but the latest BIOS describes it through ACPI _CRS/_DSD the
same way a server socket's mailbox is described, and the parts speak
the Ryzen Master SMC message set instead of the server message IDs.
Patch 1 teaches the driver the message set and lets the client reach
its mailbox through the existing _CRS/_DSD-driven MMIO path, leaving
server behaviour unchanged. Patch 2 wires the client's own metric-table
messages into the existing metric-table read path. Patch 3 hides the
pre-existing hwmon and ACPI sysfs attributes on client platforms, since
those predate the client message set and are wired to hardcoded server
message IDs that mostly resolve to unrelated, sometimes destructive,
client commands. Patch 4 adds the telemetry table those parts return.
Only the ACPI driver probes them.

Changes in v7:

  - The client message set no longer has a per-message descriptor
    table (hsmp_client_msg_desc_table is gone).
    Validate num_args and response_sz with HSMP_CLIENT_MAX_MSG_LEN.
  - /dev/hsmp is now registered at 0600 on client platforms instead of
    0644, since hsmp_ioctl_msg() has no per-message GET/SET gate there
    and any opener could otherwise issue a destructive client SET
    message; server platforms are unaffected.
  - New patch 3: the pre-existing hwmon registration, ACPI sysfs
    device attributes and metrics_bin visibility predate the client
    message set and are wired to hardcoded server message IDs, which
    mostly collide with unrelated client commands on a client
    platform. Guard all three with is_client_platform(), keeping
    smu_fw_version and protocol_version visible since they report the
    same data on both message sets.

Changes in v6:

  - Patch 1: dropped "inline" from get_msg_desc() too, for the same
    reason as hsmp_desc(): it does a range check and a reserved-type
    check, not a trivial accessor, so let the compiler decide.
  - Squashed what was patch 3 ("Add ACPI client support for Family
    1Ah") into patch 2. Patches 1+2 alone, without the old patch 3,
    would have left hsmp_metric_tbl_read_locked()'s new client message
    routing unreachable: hsmp_get_tbl_dram_base() never runs on a
    client platform until the ACPI DRAM-base gate lands, so the two
    belong together as one atomic change.
  - Patch 2 (now including the former patch 3): also guard the
    pre-existing server proto_ver clause with !is_client_platform(),
    not just the new client clause, per review. hsmp_pdev->proto_ver
    is a small Ryzen Master interface version number today, but
    nothing stops a future client interface version from reaching
    HSMP_PROTO_VER6 (6) and making that clause spuriously true on a
    client platform.
  - Series is now 3 patches instead of 4, following the squash above
    and addressed the review comments.

Changes in v5:

  - Patch 3: hsmp_pdev->proto_ver holds the Ryzen Master SMC interface
    version on client platforms, a separate numbering space from the
    server protocol versions in enum hsmp_proto_versions.

Changes in v4:

  - SMU now answers the interface version query on client platforms,
    so hsmp_desc_client.proto_ver_msg goes back to
    HSMP_CLIENT_GET_INTERFACE_VER instead of
    HSMP_CLIENT_GET_METRICS_TABLE_VER. Patch 3 is back down to just
    the ACPI metric-table-DRAM-base change, since that was the only
    other thing it did.

Changes in v3:

  - is_client_platform() now tells client and server apart through the
    ACPI-reported PM profile (FADT preferred_profile) instead of a
    hardcoded Family 1Ah model range, the same signal amd-pstate
    already keys off of. Future client generations are recognised as
    long as firmware reports the right PM profile, with no driver
    update needed.
  - hsmp_desc() now resolves the running platform's descriptor once and
    caches the pointer behind READ_ONCE()/WRITE_ONCE() instead of
    recomputing it on every call. Concurrent first callers are benign,
    since every one of them computes and stores that same pointer, so
    the pair only needs to keep the load/store from being torn or
    reordered by the compiler, not order it against anything else.
  - The client message enum in amd_hsmp.h is now documented with
    kernel-doc, one @member entry per message describing its inputs
    and outputs, rather than a block comment plus a same-line comment
    per enumerator. Noted there that not every platform supports every
    message and that an unsupported one returns -ENOMSG.
  - Patch 4: the Telemetry Table RM layout moved out of the .rst and
    into amd_hsmp.h as real kernel-doc'd struct/enum declarations,
    giving userspace one authoritative definition of the byte layout.
    The .rst now just points at struct hsmp_telemetry_table_rm. The
    structs are now also packed to a 4-byte boundary to match
    firmware's actual layout, and the trailing NPU/PMF counters and
    spare padding firmware carries after the overclocking fields are
    no longer missing. Verified field-by-field against AMD's internal
    metrics table header and end-to-end against a live snapshot off
    Family 1Ah client hardware.

Each patch builds individually and is clean under checkpatch.pl --strict.

Muralidhara M K (4):
  platform/x86/amd/hsmp: Add HSMP client support for Family 1Ah
  platform/x86/amd/hsmp: Route metric table through the client messages
  platform/x86/amd/hsmp: Hide server-only attributes on client platforms
  platform/x86/amd/hsmp: Document and expose client telemetry table in
    UAPI

 Documentation/arch/x86/amd_hsmp.rst  |  24 +-
 arch/x86/include/uapi/asm/amd_hsmp.h | 420 +++++++++++++++++++++++++++
 drivers/platform/x86/amd/hsmp/acpi.c |  32 +-
 drivers/platform/x86/amd/hsmp/hsmp.c | 249 ++++++++++++----
 drivers/platform/x86/amd/hsmp/hsmp.h |  23 ++
 5 files changed, 681 insertions(+), 67 deletions(-)

base-commit: 08dbfad3f5040f5bdb6c529da20d6d4e81fefd72
-- 
2.34.1