Re: [PATCH v3 0/6] x86/hygon: Add Family 0x18 DF node enumeration and SMN access

[Lin Wang]

Hi Boris,

Thanks. I reviewed the Sashiko findings again against the complete
series and audited the Hygon-reachable AMD NB and SMN paths.

The current upstream tree contains isolated Hygon handling in EDAC/MCE
and k10temp, while EDAC and ATL depend on the AMD NB cache. These paths
do not provide a complete Hygon backend for the DF topology handled by
this series. On the tested Family 18h Model 04h platform, for example,
the DF F3 devices are enumerated at platform-assigned slots that cannot
be represented by the AMD fixed-slot 0x18 + node mapping.

Sashiko is right that the current series leaves an inconsistent
transition. Patch 2 prevents the existing EDAC and ATL paths from
obtaining an AMD NB cache on Hygon. Patch 3 disables the AMD SMN setup
while Hygon-reachable callers such as k10temp and EDAC still use
amd_smn_read(). Patch 5 provides the Hygon SMN backend, but the
remaining AMD NB/SMN-based consumer entry points leave the separation
incomplete.

The PCI device lifetime finding in the Hygon SMN setup is also valid.
I will take explicit references for cached roots, retain them for the
lifetime of the Hygon SMN access layer, and release them on every setup
failure path after releasing the reserved config regions.

The report also identifies two pre-existing issues in the AMD SMN path:
amd_roots[] retains iterator-returned devices without owning references,
and amd_smn_init() does not validate the node and root counts before
using the derived values as divisors. Since these affect AMD behavior
independently of Hygon support, I will leave them to a separate
AMD-side discussion and follow Yazen's guidance.

I plan to revise v4 by completing the AMD/Hygon separation. Hygon DF
enumeration, node identity, SMN access, root binding and debugfs would
remain entirely in Hygon-specific code. AMD NB/SMN-based consumer entry
points without a Hygon backend would be made AMD-only in the same
series.

The AMD64 EDAC and ATL backends would therefore not initialize on
Hygon, and k10temp would not use its AMD node/SMN path on Hygon.
Independent Hygon functionality that does not depend on AMD NB or SMN,
including applicable MCE decoding, would remain unchanged.

These consumer changes would only establish the vendor boundary; v4
would not include a Hygon EDAC or ATL implementation. This would
temporarily disable the existing Hygon entry points into these AMD
backends. For Family 18h Models 04h through 08h, those paths do not
provide a topology-correct, end-to-end Hygon implementation because
they rely on the AMD node and SMN model.

This separation would be vendor-wide rather than model-specific. The
Hygon node and SMN implementation in v4 would support Family 18h Models
04h through 08h. Other Hygon models would no longer use the AMD
fallback and would remain without these functions until Hygon-specific
support is added.

There is already an EDAC/ATL RFC v2 describing the follow-up Hygon
consumer support [1]. The original author of that RFC is unable to
continue this work. I will take over development of the EDAC/ATL v3
series and adapt it to the Hygon node interfaces, while retaining the
appropriate authorship and attribution for work carried forward. It
will remain a separate follow-up series rather than being folded into
the Hygon node v4 series.

I believe this vendor-wide separation gives v4 a complete and
reviewable boundary: the Hygon node and SMN implementation is
self-contained, while the Hygon EDAC and ATL implementations remain a
separate follow-up series with a defined owner and development path.

Would this staged vendor-wide separation, including temporarily making
the AMD-backed Hygon consumer paths unavailable, be acceptable? If you
would instead require the existing AMD-backed paths to remain available
until their Hygon replacements are ready, I would appreciate guidance
on how you would prefer the node, SMN and consumer transition to be
staged.

[1] 
https://lore.kernel.org/all/20260528035246.526012-1-shiaichun@xxxxxxxxxxxxxx/

Thx & Br,

Lin

On 7/23/2026 3:59 AM, Borislav Petkov wrote:
> On Thu, Jul 09, 2026 at 03:55:43PM +0800, Lin Wang wrote:
> > Hygon Family 0x18 systems expose Data Fabric (DF) devices in a layout
> > that cannot be handled by the AMD fixed-slot node model.
>
> A bunch of issues Sashiko caught which need addressing:
>
> https://sashiko.dev/#/patchset/20260709075549.626095-1-wanglin%40open-hieco.net
>
> @Yazen, there are some preexisting ones in the SMN code that would need
> addressing/commenting too.
>
> Thx.