!1638 [openEuler-1.0-LTS] Add support for Hygon model 4h~6h processors

The header file linux/hwmon-sysfs.h provides a number of useful macros to

declare and use hardware monitoring sysfs attributes.

In many cases, you can use the exsting define DEVICE_ATTR to declare such

attributes. This is feasible if an attribute has no additional context. However,

in many cases there will be additional information such as a sensor index which

will need to be passed to the sysfs attribute handling function.

In many cases, you can use the exsting define DEVICE_ATTR or its variants

DEVICE_ATTR_{RW,RO,WO} to declare such attributes. This is feasible if an

attribute has no additional context. However, in many cases there will be

additional information such as a sensor index which will need to be passed

to the sysfs attribute handling function.

SENSOR_DEVICE_ATTR and SENSOR_DEVICE_ATTR_2 can be used to define attributes

which need such additional context information. SENSOR_DEVICE_ATTR requires

one additional argument, SENSOR_DEVICE_ATTR_2 requires two.

SENSOR_DEVICE_ATTR defines a struct sensor_device_attribute variable.

This structure has the following fields.

Simplified variants of SENSOR_DEVICE_ATTR and SENSOR_DEVICE_ATTR_2 are available

and should be used if standard attribute permissions and function names are

feasible. Standard permissions are 0644 for SENSOR_DEVICE_ATTR[_2]_RW,

0444 for SENSOR_DEVICE_ATTR[_2]_RO, and 0200 for SENSOR_DEVICE_ATTR[_2]_WO.

Standard functions, similar to DEVICE_ATTR_{RW,RO,WO}, have _show and _store

appended to the provided function name.

SENSOR_DEVICE_ATTR and its variants define a struct sensor_device_attribute

variable. This structure has the following fields.

struct sensor_device_attribute {

	struct device_attribute dev_attr;

attribute read or write function. Its parameter is the device to which the

attribute is attached.

SENSOR_DEVICE_ATTR_2 defines a struct sensor_device_attribute_2 variable,

which is defined as follows.

SENSOR_DEVICE_ATTR_2 and its variants define a struct sensor_device_attribute_2

variable, which is defined as follows.

struct sensor_device_attribute_2 {

	struct device_attribute dev_attr;

on Intel: kernel/x86/microcode/GenuineIntel.bin

on AMD  : kernel/x86/microcode/AuthenticAMD.bin

on Hygon: kernel/x86/microcode/HygonGenuine.bin

During BSP (BootStrapping Processor) boot (pre-SMP), the kernel

scans the microcode file in the initrd. If microcode matching the

  cd $TMPDIR

  mkdir -p $DSTDIR

  if [ -d /lib/firmware/hygon-ucode ]; then

          cat /lib/firmware/hygon-ucode/microcode_hygon*.bin > $DSTDIR/HygonGenuine.bin

  fi

  if [ -d /lib/firmware/amd-ucode ]; then

          cat /lib/firmware/amd-ucode/microcode_amd*.bin > $DSTDIR/AuthenticAMD.bin

  fi

Here's an example:

CONFIG_EXTRA_FIRMWARE="intel-ucode/06-3a-09 amd-ucode/microcode_amd_fam15h.bin"

CONFIG_EXTRA_FIRMWARE="intel-ucode/06-3a-09 \

  amd-ucode/microcode_amd_fam15h.bin hygon-ucode/microcode_hygon_fam18h.bin"

CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware"

This basically means, you have the following tree structure locally:

...

|   |-- microcode_amd_fam15h.bin

...

|-- hygon-ucode

...

|   |-- microcode_hygon_fam18h.bin

...

|-- intel-ucode

...

|   |-- 06-3a-09

  Packages contain a number of cores plus shared resources, e.g. DRAM

  controller, shared caches etc.

  Modern systems may also use the term 'Die' for package.

  AMD nomenclature for package is 'Node'.

  Package-related topology information in the kernel:

    The number of dies in a package. This information is retrieved via CPUID.

  - cpuinfo_x86.cpu_die_id:

    The physical ID of the die. This information is retrieved via CPUID.

  - cpuinfo_x86.phys_proc_id:

    The physical ID of the package. This information is retrieved via CPUID

    and deduced from the APIC IDs of the cores in the package.

    Modern systems use this value for the socket. There may be multiple

    packages within a socket. This value may differ from cpu_die_id.

  - cpuinfo_x86.logical_id:

    The logical ID of the package. As we do not trust BIOSes to enumerate the

config MICROCODE

	bool "CPU microcode loading support"

	default y

	depends on CPU_SUP_AMD || CPU_SUP_INTEL

	depends on CPU_SUP_AMD || CPU_SUP_INTEL || CPU_SUP_HYGON

	select FW_LOADER

	---help---

	  If you say Y here, you will be able to update the microcode on

	  Intel and AMD processors. The Intel support is for the IA32 family,

	  If you say Y here, you will be able to update the microcode on Intel,

	  AMD and Hygon processors. The Intel support is for the IA32 family,

	  e.g. Pentium Pro, Pentium II, Pentium III, Pentium 4, Xeon etc. The

	  AMD support is for families 0x10 and later. You will obviously need

	  the actual microcode binary data itself which is not shipped with

	  the Linux kernel.

	  AMD support is for families 0x10 and later. The Hygon support is for

	  families 0x18 and later. You will obviously need the actual microcode

	  binary data itself which is not shipped with the Linux kernel.

	  The preferred method to load microcode from a detached initrd is described

	  in Documentation/x86/microcode.txt. For that you need to enable

	  If you select this option, microcode patch loading support for AMD

	  processors will be enabled.

config MICROCODE_HYGON

	bool "Hygon microcode loading support"

	depends on CPU_SUP_HYGON && MICROCODE

	default MICROCODE

	select MICROCODE_AMD

	help

	  If you select this option, microcode patch loading support for Hygon

	  processors will be enabled.

config MICROCODE_OLD_INTERFACE

	def_bool y

	depends on MICROCODE

bool amd_nb_has_feature(unsigned int feature);

struct amd_northbridge *node_to_amd_nb(int node);

bool hygon_f18h_m4h(void);

u16 hygon_nb_num(void);

int get_df_id(struct pci_dev *misc, u8 *id);

static inline u16 amd_pci_dev_to_node_id(struct pci_dev *pdev)

{

	struct pci_dev *misc;

#define node_to_amd_nb(x)	NULL

#define amd_gart_present(x)	false

#define hygon_f18h_m4h		false

#define hygon_nb_num(x)	0

#define get_df_id(x, y)	NULL

#endif