Re: [PATCH v7 1/7] x86/hygon: Add Family 0x18 DF node enumeration

[Yazen Ghannam]

On Fri, Oct 09, 2026 at 05:01:05PM +0800, Lin Wang wrote:
> The AMD node code locates function 3 for node N at PCI slot 0x18 + N.
> Hygon has no equivalent node-index-to-slot mapping: DF F3 devices are
> discovered by PCI ID and the PCI BDF is only an access point.
> 
> Add a Hygon node cache that enumerates DF devices by PCI ID and obtains
> the socket ID and DFID for each node from DF configuration registers.
> Validate the enumerated socket set against the hardware-reported socket
> mask before making the cache available.
> 
> Place Core and DDR Dies (CDDs) before I/O Dies (IODs) and order each
> group by socket and DFID to provide dense node indices. Export
> interfaces for node counts and identity, F3/F4 lookup, and PCI
> device-to-node lookup.
> 
> Signed-off-by: Lin Wang <wanglin@xxxxxxxxxxxxxx>
> ---
>  MAINTAINERS                       |   3 +
>  arch/x86/Kconfig                  |   4 +
>  arch/x86/include/asm/hygon/node.h | 128 +++++++
>  arch/x86/kernel/Makefile          |   1 +
>  arch/x86/kernel/hygon_node.c      | 601 ++++++++++++++++++++++++++++++
>  5 files changed, 737 insertions(+)
>  create mode 100644 arch/x86/include/asm/hygon/node.h
>  create mode 100644 arch/x86/kernel/hygon_node.c
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index f53047aa8d3c..1c5be275a28a 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -12137,9 +12137,12 @@ F:	drivers/input/touchscreen/hycon-hy46xx.c
>  
>  HYGON PROCESSOR SUPPORT
>  M:	Pu Wen <puwen@xxxxxxxx>
> +M:	Lin Wang <wanglin@xxxxxxxxxxxxxx>

Any feedback from Pu Wen?

>  L:	linux-kernel@xxxxxxxxxxxxxxx
>  S:	Maintained
> +F:	arch/x86/include/asm/hygon/
>  F:	arch/x86/kernel/cpu/hygon.c
> +F:	arch/x86/kernel/hygon_node.c
>  

[...]

> +
> +u16 hygon_node_num(void)
> +{
> +	return df_cache.num_nodes;
> +}
> +EXPORT_SYMBOL_GPL(hygon_node_num);
> +
> +u16 hygon_cdd_num(void)
> +{
> +	return df_cache.num_cdd;
> +}
> +EXPORT_SYMBOL_GPL(hygon_cdd_num);
> +
> +int hygon_node_get_info(u16 node, struct hygon_node_info *info)
> +{
> +	const struct df_node *n;
> +
> +	if (!info)
> +		return -EINVAL;
> +
> +	if (!df_cache.nodes)
> +		return -ENODEV;
> +
> +	if (node >= df_cache.num_nodes)
> +		return -EINVAL;
> +
> +	n = &df_cache.nodes[node];
> +	info->socket_id = n->socket_id;
> +	info->dfid = n->dfid;
> +	info->type = n->is_cdd ? HYGON_NODE_CDD : HYGON_NODE_IOD;
> +	return 0;
> +}
> +EXPORT_SYMBOL_GPL(hygon_node_get_info);
> +
> +struct pci_dev *hygon_node_get_func(u16 node, u8 func)
> +{
> +	if (!df_cache.nodes)
> +		return NULL;
> +
> +	if (node >= df_cache.num_nodes)
> +		return NULL;
> +
> +	switch (func) {
> +	case HYGON_DF_F3:
> +		return pci_dev_get(df_cache.nodes[node].misc);
> +	case HYGON_DF_F4:
> +		return pci_dev_get(df_cache.nodes[node].link);
> +	default:
> +		return NULL;
> +	}
> +}
> +EXPORT_SYMBOL_GPL(hygon_node_get_func);
> +
> +int hygon_pci_dev_to_df_node(struct pci_dev *pdev)
> +{
> +	u16 i;
> +
> +	if (!pdev)
> +		return -EINVAL;
> +
> +	if (!df_cache.nodes)
> +		return -ENODEV;
> +
> +	for (i = 0; i < df_cache.num_nodes; i++) {
> +		struct pci_dev *misc = df_cache.nodes[i].misc;
> +
> +		if (pci_domain_nr(misc->bus) == pci_domain_nr(pdev->bus) &&
> +		    misc->bus->number == pdev->bus->number &&
> +		    PCI_SLOT(misc->devfn) == PCI_SLOT(pdev->devfn))
> +			return i;
> +	}
> +
> +	return -ENODEV;
> +}
> +EXPORT_SYMBOL_GPL(hygon_pci_dev_to_df_node);
> +

These exported functions don't have any callers in this set.

This issue was mentioned in the last revision for a different function.
But the guidance should be followed in general.

> +static int __init df_node_init(void)
> +{
> +	int ret;
> +
> +	if (!get_df_cfg())
> +		return 0;
> +
> +	ret = build_cache();
> +	if (ret) {
> +		pr_warn("DF node cache build failed: %d\n", ret);
> +		return ret;
> +	}
> +

Have you considered cases where the cache build fails but that are
expected?

We've had similar issues recently like this related to virtualization.

In summary: this failure is a true issue on bare metal, so the user
should be warned. But the failure is expected within a guest VM.

Thanks,
Yazen