[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <53C4EE5C.5020407@roeck-us.net>
Date: Tue, 15 Jul 2014 02:03:24 -0700
From: Guenter Roeck <linux@...ck-us.net>
To: Clemens Ladisch <clemens@...isch.de>
CC: Aravind Gopalakrishnan <Aravind.Gopalakrishnan@....com>,
Borislav Petkov <bp@...en8.de>, jdelvare@...e.de,
rdunlap@...radead.org, bhelgaas@...gle.com,
lm-sensors@...sensors.org, linux-doc@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-pci@...r.kernel.org
Subject: Re: [PATCH] hwmon, k10temp: Add support for AMD F15h M60h processor
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, ®val);
>>>
>>> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists