[PATCH] hwmon, k10temp: Add support for AMD F15h M60h processor

[PATCH] hwmon, k10temp: Add support for AMD F15h M60h processor

[Aravind Gopalakrishnan]

This patch adds temperature monitoring support for F15h M60h processor.
 - Add new pci device id for the relevant processor
 - The functionality of REG_REPORTED_TEMPERATURE is moved to
   D0F0xBC_xD820_0CA4 [Reported Temperature Control]
   - So, use this to get CUR_TEMP value
 - Add Kconfig, Doc entries to indicate support for this processor.

Signed-off-by: Aravind Gopalakrishnan <Aravind.Gopalakrishnan@amd.com>
---
 Documentation/hwmon/k10temp |  2 +-
 drivers/hwmon/Kconfig       |  4 ++--
 drivers/hwmon/k10temp.c     | 22 ++++++++++++++++++++--
 include/linux/pci_ids.h     |  1 +
 4 files changed, 24 insertions(+), 5 deletions(-)

diff --git a/Documentation/hwmon/k10temp b/Documentation/hwmon/k10temp
index ee6d30e..254d2f5 100644
--- a/Documentation/hwmon/k10temp
+++ b/Documentation/hwmon/k10temp
@@ -11,7 +11,7 @@ Supported chips:
   Socket S1G2: Athlon (X2), Sempron (X2), Turion X2 (Ultra)
 * AMD Family 12h processors: "Llano" (E2/A4/A6/A8-Series)
 * AMD Family 14h processors: "Brazos" (C/E/G/Z-Series)
-* AMD Family 15h processors: "Bulldozer" (FX-Series), "Trinity", "Kaveri"
+* AMD Family 15h processors: "Bulldozer" (FX-Series), "Trinity", "Kaveri", "Carrizo"
 * AMD Family 16h processors: "Kabini", "Mullins"
 
   Prefix: 'k10temp'
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 02d3d85..57ba400 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -280,8 +280,8 @@ config SENSORS_K10TEMP
 	  If you say yes here you get support for the temperature
 	  sensor(s) inside your CPU. Supported are later revisions of
 	  the AMD Family 10h and all revisions of the AMD Family 11h,
-	  12h (Llano), 14h (Brazos), 15h (Bulldozer/Trinity/Kaveri) and
-	  16h (Kabini/Mullins) microarchitectures.
+	  12h (Llano), 14h (Brazos), 15h (Bulldozer/Trinity/Kaveri/Carrizo)
+	  and 16h (Kabini/Mullins) microarchitectures.
 
 	  This driver can also be built as a module.  If so, the module
 	  will be called k10temp.
diff --git a/drivers/hwmon/k10temp.c b/drivers/hwmon/k10temp.c
index f7b46f6..5da872f 100644
--- a/drivers/hwmon/k10temp.c
+++ b/drivers/hwmon/k10temp.c
@@ -51,13 +51,30 @@ MODULE_PARM_DESC(force, "force loading on processors with erratum 319");
 #define REG_NORTHBRIDGE_CAPABILITIES	0xe8
 #define  NB_CAP_HTC			0x00000400
 
+/*
+ * For F15h M60h, functionality of REG_REPORTED_TEMPERATURE
+ * has been moved to D0F0xBC_xD820_0CA4 [Reported Temperature
+ * Control]
+ */
+#define NB_SMU_IND_ADDR			0xb8
+#define NB_SMU_IND_DATA			0xbc
+#define IND_ADDR_OFFSET			0xd8200ca4
+
 static ssize_t show_temp(struct device *dev,
 			 struct device_attribute *attr, char *buf)
 {
 	u32 regval;
+	struct pci_dev *pdev = to_pci_dev(dev);
+
+	if (boot_cpu_data.x86 == 0x15 && boot_cpu_data.x86_model == 0x60) {
+		pci_bus_write_config_dword(pdev->bus, PCI_DEVFN(0, 0),
+					   NB_SMU_IND_ADDR, IND_ADDR_OFFSET);
+		pci_bus_read_config_dword(pdev->bus, PCI_DEVFN(0, 0),
+					  NB_SMU_IND_DATA, &regval);
+
+	} else
+		pci_read_config_dword(pdev, REG_REPORTED_TEMPERATURE, &regval);
 
-	pci_read_config_dword(to_pci_dev(dev),
-			      REG_REPORTED_TEMPERATURE, &regval);
 	return sprintf(buf, "%u\n", (regval >> 21) * 125);
 }
 
@@ -211,6 +228,7 @@ static const struct pci_device_id k10temp_id_table[] = {
 	{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_15H_NB_F3) },
 	{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_15H_M10H_F3) },
 	{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_15H_M30H_NB_F3) },
+	{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_15H_M60H_NB_F3) },
 	{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_16H_NB_F3) },
 	{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_16H_M30H_NB_F3) },
 	{}
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index 7fa3173..3c8e328 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -520,6 +520,7 @@
 #define PCI_DEVICE_ID_AMD_15H_M10H_F3	0x1403
 #define PCI_DEVICE_ID_AMD_15H_M30H_NB_F3 0x141d
 #define PCI_DEVICE_ID_AMD_15H_M30H_NB_F4 0x141e
+#define PCI_DEVICE_ID_AMD_15H_M60H_NB_F3 0x1573
 #define PCI_DEVICE_ID_AMD_15H_NB_F0	0x1600
 #define PCI_DEVICE_ID_AMD_15H_NB_F1	0x1601
 #define PCI_DEVICE_ID_AMD_15H_NB_F2	0x1602
-- 
1.8.1.2

Re: [PATCH] hwmon, k10temp: Add support for AMD F15h M60h processor

[Borislav Petkov]

On Mon, Jul 14, 2014 at 03:23:08PM -0500, Aravind Gopalakrishnan wrote:
> This patch adds temperature monitoring support for F15h M60h processor.
>  - Add new pci device id for the relevant processor
>  - The functionality of REG_REPORTED_TEMPERATURE is moved to
>    D0F0xBC_xD820_0CA4 [Reported Temperature Control]
>    - So, use this to get CUR_TEMP value
>  - Add Kconfig, Doc entries to indicate support for this processor.
> 
> Signed-off-by: Aravind Gopalakrishnan <Aravind.Gopalakrishnan@amd.com>
> ---
>  Documentation/hwmon/k10temp |  2 +-
>  drivers/hwmon/Kconfig       |  4 ++--
>  drivers/hwmon/k10temp.c     | 22 ++++++++++++++++++++--
>  include/linux/pci_ids.h     |  1 +
>  4 files changed, 24 insertions(+), 5 deletions(-)
> 
> diff --git a/Documentation/hwmon/k10temp b/Documentation/hwmon/k10temp
> index ee6d30e..254d2f5 100644
> --- a/Documentation/hwmon/k10temp
> +++ b/Documentation/hwmon/k10temp
> @@ -11,7 +11,7 @@ Supported chips:
>    Socket S1G2: Athlon (X2), Sempron (X2), Turion X2 (Ultra)
>  * AMD Family 12h processors: "Llano" (E2/A4/A6/A8-Series)
>  * AMD Family 14h processors: "Brazos" (C/E/G/Z-Series)
> -* AMD Family 15h processors: "Bulldozer" (FX-Series), "Trinity", "Kaveri"
> +* AMD Family 15h processors: "Bulldozer" (FX-Series), "Trinity", "Kaveri", "Carrizo"
>  * AMD Family 16h processors: "Kabini", "Mullins"
>  
>    Prefix: 'k10temp'
> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
> index 02d3d85..57ba400 100644
> --- a/drivers/hwmon/Kconfig
> +++ b/drivers/hwmon/Kconfig
> @@ -280,8 +280,8 @@ config SENSORS_K10TEMP
>  	  If you say yes here you get support for the temperature
>  	  sensor(s) inside your CPU. Supported are later revisions of
>  	  the AMD Family 10h and all revisions of the AMD Family 11h,
> -	  12h (Llano), 14h (Brazos), 15h (Bulldozer/Trinity/Kaveri) and
> -	  16h (Kabini/Mullins) microarchitectures.
> +	  12h (Llano), 14h (Brazos), 15h (Bulldozer/Trinity/Kaveri/Carrizo)
> +	  and 16h (Kabini/Mullins) microarchitectures.
>  
>  	  This driver can also be built as a module.  If so, the module
>  	  will be called k10temp.
> diff --git a/drivers/hwmon/k10temp.c b/drivers/hwmon/k10temp.c
> index f7b46f6..5da872f 100644
> --- a/drivers/hwmon/k10temp.c
> +++ b/drivers/hwmon/k10temp.c
> @@ -51,13 +51,30 @@ MODULE_PARM_DESC(force, "force loading on processors with erratum 319");
>  #define REG_NORTHBRIDGE_CAPABILITIES	0xe8
>  #define  NB_CAP_HTC			0x00000400
>  
> +/*
> + * For F15h M60h, functionality of REG_REPORTED_TEMPERATURE
> + * has been moved to D0F0xBC_xD820_0CA4 [Reported Temperature
> + * Control]
> + */
> +#define NB_SMU_IND_ADDR			0xb8
> +#define NB_SMU_IND_DATA			0xbc
> +#define IND_ADDR_OFFSET			0xd8200ca4
> +
>  static ssize_t show_temp(struct device *dev,
>  			 struct device_attribute *attr, char *buf)
>  {
>  	u32 regval;
> +	struct pci_dev *pdev = to_pci_dev(dev);
> +
> +	if (boot_cpu_data.x86 == 0x15 && boot_cpu_data.x86_model == 0x60) {
> +		pci_bus_write_config_dword(pdev->bus, PCI_DEVFN(0, 0),
> +					   NB_SMU_IND_ADDR, IND_ADDR_OFFSET);
> +		pci_bus_read_config_dword(pdev->bus, PCI_DEVFN(0, 0),
> +					  NB_SMU_IND_DATA, &regval);
> +
> +	} else
> +		pci_read_config_dword(pdev, REG_REPORTED_TEMPERATURE, &regval);
>  
> -	pci_read_config_dword(to_pci_dev(dev),
> -			      REG_REPORTED_TEMPERATURE, &regval);
>  	return sprintf(buf, "%u\n", (regval >> 21) * 125);
>  }
>  
> @@ -211,6 +228,7 @@ static const struct pci_device_id k10temp_id_table[] = {
>  	{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_15H_NB_F3) },
>  	{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_15H_M10H_F3) },
>  	{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_15H_M30H_NB_F3) },
> +	{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_15H_M60H_NB_F3) },
>  	{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_16H_NB_F3) },
>  	{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_16H_M30H_NB_F3) },
>  	{}
> diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
> index 7fa3173..3c8e328 100644
> --- a/include/linux/pci_ids.h
> +++ b/include/linux/pci_ids.h
> @@ -520,6 +520,7 @@
>  #define PCI_DEVICE_ID_AMD_15H_M10H_F3	0x1403
>  #define PCI_DEVICE_ID_AMD_15H_M30H_NB_F3 0x141d
>  #define PCI_DEVICE_ID_AMD_15H_M30H_NB_F4 0x141e
> +#define PCI_DEVICE_ID_AMD_15H_M60H_NB_F3 0x1573

I'm assuming this is used somewhere else besides k10temp.c?

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

Re: [PATCH] hwmon, k10temp: Add support for AMD F15h M60h processor

[Aravind Gopalakrishnan]

On 7/14/2014 2:51 PM, Borislav Petkov wrote:
> On Mon, Jul 14, 2014 at 03:23:08PM -0500, Aravind Gopalakrishnan wrote:
>>   
>> @@ -211,6 +228,7 @@ static const struct pci_device_id k10temp_id_table[] = {
>>   	{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_15H_NB_F3) },
>>   	{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_15H_M10H_F3) },
>>   	{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_15H_M30H_NB_F3) },
>> +	{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_15H_M60H_NB_F3) },
>>   	{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_16H_NB_F3) },
>>   	{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_16H_M30H_NB_F3) },
>>   	{}
>> diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
>> index 7fa3173..3c8e328 100644
>> --- a/include/linux/pci_ids.h
>> +++ b/include/linux/pci_ids.h
>> @@ -520,6 +520,7 @@
>>   #define PCI_DEVICE_ID_AMD_15H_M10H_F3	0x1403
>>   #define PCI_DEVICE_ID_AMD_15H_M30H_NB_F3 0x141d
>>   #define PCI_DEVICE_ID_AMD_15H_M30H_NB_F4 0x141e
>> +#define PCI_DEVICE_ID_AMD_15H_M60H_NB_F3 0x1573
> I'm assuming this is used somewhere else besides k10temp.c?
>

Yeah, will most likely need to add EDAC bits. But that is something I 
can't test now.

So will have to do it only in due time.. :)

-Aravind.

Re: [PATCH] hwmon, k10temp: Add support for AMD F15h M60h processor

[Guenter Roeck]

On Mon, Jul 14, 2014 at 02:59:10PM -0500, Aravind Gopalakrishnan wrote:
> On 7/14/2014 2:51 PM, Borislav Petkov wrote:
> >On Mon, Jul 14, 2014 at 03:23:08PM -0500, Aravind Gopalakrishnan wrote:
> >>@@ -211,6 +228,7 @@ static const struct pci_device_id k10temp_id_table[] = {
> >>  	{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_15H_NB_F3) },
> >>  	{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_15H_M10H_F3) },
> >>  	{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_15H_M30H_NB_F3) },
> >>+	{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_15H_M60H_NB_F3) },
> >>  	{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_16H_NB_F3) },
> >>  	{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_16H_M30H_NB_F3) },
> >>  	{}
> >>diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
> >>index 7fa3173..3c8e328 100644
> >>--- a/include/linux/pci_ids.h
> >>+++ b/include/linux/pci_ids.h
> >>@@ -520,6 +520,7 @@
> >>  #define PCI_DEVICE_ID_AMD_15H_M10H_F3	0x1403
> >>  #define PCI_DEVICE_ID_AMD_15H_M30H_NB_F3 0x141d
> >>  #define PCI_DEVICE_ID_AMD_15H_M30H_NB_F4 0x141e
> >>+#define PCI_DEVICE_ID_AMD_15H_M60H_NB_F3 0x1573
> >I'm assuming this is used somewhere else besides k10temp.c?
> >
> 
> Yeah, will most likely need to add EDAC bits. But that is something
> I can't test now.
> 
Sorry, I can not add this to a common file unless it is used elsewhere.
I would suggest to add it locally for now. It can be moved to the
common file once it is used elsewhere.

Guenter

Re: [PATCH] hwmon, k10temp: Add support for AMD F15h M60h processor

[Clemens Ladisch]

Borislav Petkov wrote:
> On Mon, Jul 14, 2014 at 03:23:08PM -0500, Aravind Gopalakrishnan wrote:
>> +	if (boot_cpu_data.x86 == 0x15 && boot_cpu_data.x86_model == 0x60) {
>> +		pci_bus_write_config_dword(pdev->bus, PCI_DEVFN(0, 0),
>> +					   NB_SMU_IND_ADDR, IND_ADDR_OFFSET);
>> +		pci_bus_read_config_dword(pdev->bus, PCI_DEVFN(0, 0),
>> +					  NB_SMU_IND_DATA, &regval);

How do you prevent races with any other code that accesses some indirect
register?

>> +
>> +	} else
>> +		pci_read_config_dword(pdev, REG_REPORTED_TEMPERATURE, &regval);

Why the empty line?  Also, use braces in both branches.


Regards,
Clemens

Re: [PATCH] hwmon, k10temp: Add support for AMD F15h M60h processor

[Guenter Roeck]

On Mon, Jul 14, 2014 at 10:21:51PM +0200, Clemens Ladisch wrote:
> Borislav Petkov wrote:
> > On Mon, Jul 14, 2014 at 03:23:08PM -0500, Aravind Gopalakrishnan wrote:
> >> +	if (boot_cpu_data.x86 == 0x15 && boot_cpu_data.x86_model == 0x60) {
> >> +		pci_bus_write_config_dword(pdev->bus, PCI_DEVFN(0, 0),
> >> +					   NB_SMU_IND_ADDR, IND_ADDR_OFFSET);
> >> +		pci_bus_read_config_dword(pdev->bus, PCI_DEVFN(0, 0),
> >> +					  NB_SMU_IND_DATA, &regval);
> 
> How do you prevent races with any other code that accesses some indirect
> register?
> 
I just wanted to ask exactly the same question. I think this will need
locking.

> >> +
> >> +	} else
> >> +		pci_read_config_dword(pdev, REG_REPORTED_TEMPERATURE, &regval);
> 
> Why the empty line?  Also, use braces in both branches.
> 
Agreed. Too bad the respective checkpatch warning was moved to --strict.

Guenter

Re: [PATCH] hwmon, k10temp: Add support for AMD F15h M60h processor

[Clemens Ladisch]

Guenter Roeck wrote:
> On Mon, Jul 14, 2014 at 10:21:51PM +0200, Clemens Ladisch wrote:
>> Borislav Petkov wrote:
>>> On Mon, Jul 14, 2014 at 03:23:08PM -0500, Aravind Gopalakrishnan wrote:
>>>> +	if (boot_cpu_data.x86 == 0x15 && boot_cpu_data.x86_model == 0x60) {
>>>> +		pci_bus_write_config_dword(pdev->bus, PCI_DEVFN(0, 0),
>>>> +					   NB_SMU_IND_ADDR, IND_ADDR_OFFSET);
>>>> +		pci_bus_read_config_dword(pdev->bus, PCI_DEVFN(0, 0),
>>>> +					  NB_SMU_IND_DATA, &regval);
>>
>> How do you prevent races with any other code that accesses some indirect
>> register?
>>
> I just wanted to ask exactly the same question. I think this will need
> locking.

If there actually is any other code; these indirect SMU registers appear
to be mostly undocumented and to be intended to be used by the BIOS.
(Which makes me wonder why the temperature sensor was moved there.)

Anyway, if a lock is needed, it looks as if it could go into a helper
function such as "amd_nb_smu_ind_read()" in arch/x86/kernel/amd_nb.c.


Regards,
Clemens

Re: [PATCH] hwmon, k10temp: Add support for AMD F15h M60h processor

[Guenter Roeck]

On 07/15/2014 12:41 AM, Clemens Ladisch wrote:
> Guenter Roeck wrote:
>> On Mon, Jul 14, 2014 at 10:21:51PM +0200, Clemens Ladisch wrote:
>>> Borislav Petkov wrote:
>>>> On Mon, Jul 14, 2014 at 03:23:08PM -0500, Aravind Gopalakrishnan wrote:
>>>>> +	if (boot_cpu_data.x86 == 0x15 && boot_cpu_data.x86_model == 0x60) {
>>>>> +		pci_bus_write_config_dword(pdev->bus, PCI_DEVFN(0, 0),
>>>>> +					   NB_SMU_IND_ADDR, IND_ADDR_OFFSET);
>>>>> +		pci_bus_read_config_dword(pdev->bus, PCI_DEVFN(0, 0),
>>>>> +					  NB_SMU_IND_DATA, &regval);
>>>
>>> How do you prevent races with any other code that accesses some indirect
>>> register?
>>>
>> I just wanted to ask exactly the same question. I think this will need
>> locking.
>
> If there actually is any other code; these indirect SMU registers appear
> to be mostly undocumented and to be intended to be used by the BIOS.
> (Which makes me wonder why the temperature sensor was moved there.)
>
Scary. Does that mean there is a chance they may get used through ACPI ?

> Anyway, if a lock is needed, it looks as if it could go into a helper
> function such as "amd_nb_smu_ind_read()" in arch/x86/kernel/amd_nb.c.
>
Yes, something like that.

Guenter

Re: [PATCH] hwmon, k10temp: Add support for AMD F15h M60h processor

[Aravind Gopalakrishnan]

On 7/15/2014 4:03 AM, Guenter Roeck wrote:
> On 07/15/2014 12:41 AM, Clemens Ladisch wrote:
>> Guenter Roeck wrote:
>>> On Mon, Jul 14, 2014 at 10:21:51PM +0200, Clemens Ladisch wrote:
>>>> Borislav Petkov wrote:
>>>>> On Mon, Jul 14, 2014 at 03:23:08PM -0500, Aravind Gopalakrishnan 
>>>>> wrote:
>>>>>> +    if (boot_cpu_data.x86 == 0x15 && boot_cpu_data.x86_model == 
>>>>>> 0x60) {
>>>>>> +        pci_bus_write_config_dword(pdev->bus, PCI_DEVFN(0, 0),
>>>>>> +                       NB_SMU_IND_ADDR, IND_ADDR_OFFSET);
>>>>>> +        pci_bus_read_config_dword(pdev->bus, PCI_DEVFN(0, 0),
>>>>>> +                      NB_SMU_IND_DATA, &regval);
>>>>
>>>> How do you prevent races with any other code that accesses some 
>>>> indirect
>>>> register?
>>>>
>>> I just wanted to ask exactly the same question. I think this will need
>>> locking.
>>
>> If there actually is any other code; these indirect SMU registers appear
>> to be mostly undocumented and to be intended to be used by the BIOS.
>> (Which makes me wonder why the temperature sensor was moved there.)
>>
> Scary. Does that mean there is a chance they may get used through ACPI ?

I have been asking internally about this, and looks like it's just a 
register address change.
So we probably don't have to worry about this being used elsewhere..

>
>> Anyway, if a lock is needed, it looks as if it could go into a helper
>> function such as "amd_nb_smu_ind_read()" in arch/x86/kernel/amd_nb.c.
>>
> Yes, something like that.
>
>
Okay, I shall add the locking mechanism and re-send.

Thanks,
-Aravind.

Re: [PATCH] hwmon, k10temp: Add support for AMD F15h M60h processor

[Clemens Ladisch]

Aravind Gopalakrishnan wrote:
> On 7/15/2014 4:03 AM, Guenter Roeck wrote:
>> On 07/15/2014 12:41 AM, Clemens Ladisch wrote:
>>> Guenter Roeck wrote:
>>>> On Mon, Jul 14, 2014 at 10:21:51PM +0200, Clemens Ladisch wrote:
>>>>> Borislav Petkov wrote:
>>>>>> On Mon, Jul 14, 2014 at 03:23:08PM -0500, Aravind Gopalakrishnan wrote:
>>>>>>> +    if (boot_cpu_data.x86 == 0x15 && boot_cpu_data.x86_model == 0x60) {
>>>>>>> +        pci_bus_write_config_dword(pdev->bus, PCI_DEVFN(0, 0),
>>>>>>> +                       NB_SMU_IND_ADDR, IND_ADDR_OFFSET);
>>>>>>> +        pci_bus_read_config_dword(pdev->bus, PCI_DEVFN(0, 0),
>>>>>>> +                      NB_SMU_IND_DATA, &regval);
>>>>>
>>>>> How do you prevent races with any other code that accesses some indirect
>>>>> register?
>>>
>>> If there actually is any other code; these indirect SMU registers appear
>>> to be mostly undocumented and to be intended to be used by the BIOS.
>>> (Which makes me wonder why the temperature sensor was moved there.)
>>
>> Scary. Does that mean there is a chance they may get used through ACPI ?
>
> I have been asking internally about this, and looks like it's just a register address change.
> So we probably don't have to worry about this being used elsewhere..

The conflict is about the SMU index register; the question is whether
_any_ of these SMU registers is used elsewhere (in a way that could
happen concurrently).


Regards,
Clemens