From: Aravind Gopalakrishnan <aravind.gopalakrishnan@amd.com>
To: Guenter Roeck <linux@roeck-us.net>
Cc: <herrmann.der.user@googlemail.com>, <jdelvare@suse.de>,
<lm-sensors@lm-sensors.org>, <linux-kernel@vger.kernel.org>,
Boris Ostrovsky <boris.ostrovsky@amd.com>
Subject: Re: [PATCH] hwmon, fam15h_power: Add support for two more processors
Date: Wed, 10 Sep 2014 16:23:35 -0500 [thread overview]
Message-ID: <5410C157.4050103@amd.com> (raw)
In-Reply-To: <20140910203719.GA31216@roeck-us.net>
On 9/10/2014 3:37 PM, Guenter Roeck wrote:
> On Wed, Sep 10, 2014 at 03:01:36PM -0500, Aravind Gopalakrishnan wrote:
>> On 9/10/2014 12:53 PM, Guenter Roeck wrote:
>>> On Wed, Sep 10, 2014 at 12:02:08PM -0500, Aravind Gopalakrishnan wrote:
>>>> Fam16h,M30h(Mullins) and Fam15hM30h(Kaveri) processors can
>>>> report 'power_crit' value. So, adding their respective device ids.
>>>>
>>>> Also, according to BKDGs, the 'TdpRunAvgAccCap' that show_power()
>>>> uses is valid only on Fam15h, Models 0x0-0xF. On all other processors
>>>> the field is 'Reserved'. So, return error if we are on any other family/model.
>>>>
>>>> Impact on lm-sensors is minimal. On such families, instead of reporting
>>>> Current power value as '0', we now have:
>>>> power1: N/A
>>>>
>>> It will result in people complaining to us about it.
>>>
>>> It would be more appropriate to not create the attribute the first place
>>> if it is not supported. Sure, that is a bit more code, but it isn't that bad.
>>> You can simply return -ENODEV for unsupported CPUs from the probe function.
>>>
>>>
>>>> Signed-off-by: Aravind Gopalakrishnan <aravind.gopalakrishnan@amd.com>
>>>> ---
>>>> drivers/hwmon/fam15h_power.c | 6 ++++++
>>>> 1 file changed, 6 insertions(+)
>>>>
>>>> diff --git a/drivers/hwmon/fam15h_power.c b/drivers/hwmon/fam15h_power.c
>>>> index 4a7cbfa..b69bf7d 100644
>>>> --- a/drivers/hwmon/fam15h_power.c
>>>> +++ b/drivers/hwmon/fam15h_power.c
>>>> @@ -57,6 +57,10 @@ static ssize_t show_power(struct device *dev,
>>>> struct fam15h_power_data *data = dev_get_drvdata(dev);
>>>> struct pci_dev *f4 = data->pdev;
>>>> + /* The value TdpRunAvgAccCap is valid only on F15h, Models 0x0-0xF */
>>>> + if (boot_cpu_data.x86 != 0x15 || boot_cpu_data.x86_model > 0x0)
>>> The comment does not match the code. The comment talks about accepting models
>>> F15h, models 0x0-0xF, but the code rejects anything but F15h model 0x0.
>> Ah. Yes, The condition should have been (..boot_cpu_data.x86_model > 0xf)
>>
>>> Now it may well be that the above describes identifies all F15h and F16h CPUs,
>>> but this is not clear from the comment. It rather looks as if anything but F15h,
>>> model 0x0 is rejected, including all F16h CPUs. But then why accept F16h CPUs
>>> in the first place ?
>> Yes, we want to reject anything but F15h, Models 00h-0fh.
>> The reason I included the newer processor IDs, (and let
>> PCI_DEVICE_ID_AMD_16H_NB_F4) remain
>> is because we can still obtain 'critical power value'. It is only
>> the 'current power' that is not exposed.
>>
> That is a behavioral change, though; previously the current power was
> reported for F16h chips with PCI ID PCI_DEVICE_ID_AMD_16H_NB_F4.
> Is this a bug, ie should the power value not have been reported
> for the F16h chips ?
That's right.
>> If we return -ENODEV in the probe function (or we can just remove
>> the listed PCI_DEVICE_ID), then we'd not get the critical power
>> values too.
>>
> If you want to make the actual power reporting conditional, you should
> introduce an is_visible function to the attribute group to ensure that
> power1_input is only reported if/when supported. If the actual power
> value is not really supported for F16h chips, you should actually provide
> two separate patches: One to make power1_input optional, to be reported for
> supported chips only, and another to add more chips. One is a bug fix,
> the other a functionality extension.
>
Ok, I'll do that and resend.
Thanks,
-Aravind.
>
>>>> + return -ENOSYS;
>>>> +
>>>> pci_bus_read_config_dword(f4->bus, PCI_DEVFN(PCI_SLOT(f4->devfn), 5),
>>>> REG_TDP_RUNNING_AVERAGE, &val);
>>>> running_avg_capture = (val >> 4) & 0x3fffff;
>>>> @@ -216,7 +220,9 @@ static int fam15h_power_probe(struct pci_dev *pdev,
>>>> static const struct pci_device_id fam15h_power_id_table[] = {
>>>> { PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_15H_NB_F4) },
>>>> + { PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_15H_M30H_NB_F4) },
>>>> { PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_16H_NB_F4) },
>>>> + { PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_16H_M30H_NB_F3) },
>>>> {}
>>>> };
>>>> MODULE_DEVICE_TABLE(pci, fam15h_power_id_table);
>>>> --
>>>> 2.0.3
>>>>
prev parent reply other threads:[~2014-09-10 21:23 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-10 17:02 [PATCH] hwmon, fam15h_power: Add support for two more processors Aravind Gopalakrishnan
2014-09-10 17:53 ` Guenter Roeck
2014-09-10 20:01 ` Aravind Gopalakrishnan
2014-09-10 20:37 ` Guenter Roeck
2014-09-10 21:23 ` Aravind Gopalakrishnan [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5410C157.4050103@amd.com \
--to=aravind.gopalakrishnan@amd.com \
--cc=boris.ostrovsky@amd.com \
--cc=herrmann.der.user@googlemail.com \
--cc=jdelvare@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=lm-sensors@lm-sensors.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox