From: Guenter Roeck <linux@roeck-us.net>
To: Neelesh Gupta <neelegup@linux.vnet.ibm.com>,
Michael Ellerman <mpe@ellerman.id.au>
Cc: jdelvare@suse.de, lm-sensors@lm-sensors.org,
linux-kernel@vger.kernel.org
Subject: Re: [lm-sensors] [PATCH 1/2] hwmon: (ibmpowernv) Quieten when probing finds no device
Date: Sat, 01 Nov 2014 21:15:25 +0000 [thread overview]
Message-ID: <54554D6D.5090509@roeck-us.net> (raw)
In-Reply-To: <54551CDB.2090407@linux.vnet.ibm.com>
On 11/01/2014 10:48 AM, Neelesh Gupta wrote:
>
> On 10/31/2014 11:42 PM, Guenter Roeck wrote:
>> On Fri, Oct 31, 2014 at 05:45:22PM +1100, Michael Ellerman wrote:
>>> Because we build kernels with drivers built in for many platforms, it's
>>> normal for the ibmpowernv driver to be loaded on systems that don't have
>>> the appropriate hardware.
>>>
>>> Currently the driver spams the log with:
>>>
>>> ibmpowernv ibmpowernv.0: Opal node 'sensors' not found
>>> ibmpowernv: Platfrom driver probe failed
>>>
>>> But there is no error, this machine is not a powernv and doesn't have
>>> the hardware. So change the sensors message to dev_dbg(), and only print
>>> an error about the probe failing if it's not ENODEV.
>>>
>>> Also fix the spelling of "Platfrom" and print the actual error value.
>>>
>>> Signed-off-by: Michael Ellerman<mpe@ellerman.id.au>
>> Neelesh,
>>
>> is there a compatible property in the powernv devicetree which can be
>> used to identify the system ?
>
> I think the driver should not be loaded at first place on *non* powernv platforms.
> Still, we can improve by introducing 'platform_driver.id_table' and moving the
> platform device creation code in platform init 'opal-sensor.c' using
> of_platform_device_create() and just do driver register in module init.
>
Ok with me.
Can you write a patch doing that ?
Thanks,
Guenter
> - Neelesh
>
>>
>> I am ok with applying this patch for the time being, but it would be better
>> if we can change the driver to only instantiate when actually needed.
>>
>> Thanks,
>> Guenter
>>
>>> ---
>>> drivers/hwmon/ibmpowernv.c | 6 ++++--
>>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/hwmon/ibmpowernv.c b/drivers/hwmon/ibmpowernv.c
>>> index d2bf2c97ae70..6a30eeea94be 100644
>>> --- a/drivers/hwmon/ibmpowernv.c
>>> +++ b/drivers/hwmon/ibmpowernv.c
>>> @@ -181,7 +181,7 @@ static int __init populate_attr_groups(struct platform_device *pdev)
>>>
>>> opal = of_find_node_by_path("/ibm,opal/sensors");
>>> if (!opal) {
>>> - dev_err(&pdev->dev, "Opal node 'sensors' not found\n");
>>> + dev_dbg(&pdev->dev, "Opal node 'sensors' not found\n");
>>> return -ENODEV;
>>> }
>>>
>>> @@ -335,7 +335,9 @@ static int __init ibmpowernv_init(void)
>>>
>>> err = platform_driver_probe(&ibmpowernv_driver, ibmpowernv_probe);
>>> if (err) {
>>> - pr_err("Platfrom driver probe failed\n");
>>> + if (err != -ENODEV)
>>> + pr_err("Platform driver probe failed (%d)\n", err);
>>> +
>>> goto exit_device_del;
>>> }
>>>
>>> --
>>> 1.9.1
>>>
>
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
WARNING: multiple messages have this Message-ID (diff)
From: Guenter Roeck <linux@roeck-us.net>
To: Neelesh Gupta <neelegup@linux.vnet.ibm.com>,
Michael Ellerman <mpe@ellerman.id.au>
Cc: jdelvare@suse.de, lm-sensors@lm-sensors.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] hwmon: (ibmpowernv) Quieten when probing finds no device
Date: Sat, 01 Nov 2014 14:15:25 -0700 [thread overview]
Message-ID: <54554D6D.5090509@roeck-us.net> (raw)
In-Reply-To: <54551CDB.2090407@linux.vnet.ibm.com>
On 11/01/2014 10:48 AM, Neelesh Gupta wrote:
>
> On 10/31/2014 11:42 PM, Guenter Roeck wrote:
>> On Fri, Oct 31, 2014 at 05:45:22PM +1100, Michael Ellerman wrote:
>>> Because we build kernels with drivers built in for many platforms, it's
>>> normal for the ibmpowernv driver to be loaded on systems that don't have
>>> the appropriate hardware.
>>>
>>> Currently the driver spams the log with:
>>>
>>> ibmpowernv ibmpowernv.0: Opal node 'sensors' not found
>>> ibmpowernv: Platfrom driver probe failed
>>>
>>> But there is no error, this machine is not a powernv and doesn't have
>>> the hardware. So change the sensors message to dev_dbg(), and only print
>>> an error about the probe failing if it's not ENODEV.
>>>
>>> Also fix the spelling of "Platfrom" and print the actual error value.
>>>
>>> Signed-off-by: Michael Ellerman<mpe@ellerman.id.au>
>> Neelesh,
>>
>> is there a compatible property in the powernv devicetree which can be
>> used to identify the system ?
>
> I think the driver should not be loaded at first place on *non* powernv platforms.
> Still, we can improve by introducing 'platform_driver.id_table' and moving the
> platform device creation code in platform init 'opal-sensor.c' using
> of_platform_device_create() and just do driver register in module init.
>
Ok with me.
Can you write a patch doing that ?
Thanks,
Guenter
> - Neelesh
>
>>
>> I am ok with applying this patch for the time being, but it would be better
>> if we can change the driver to only instantiate when actually needed.
>>
>> Thanks,
>> Guenter
>>
>>> ---
>>> drivers/hwmon/ibmpowernv.c | 6 ++++--
>>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/hwmon/ibmpowernv.c b/drivers/hwmon/ibmpowernv.c
>>> index d2bf2c97ae70..6a30eeea94be 100644
>>> --- a/drivers/hwmon/ibmpowernv.c
>>> +++ b/drivers/hwmon/ibmpowernv.c
>>> @@ -181,7 +181,7 @@ static int __init populate_attr_groups(struct platform_device *pdev)
>>>
>>> opal = of_find_node_by_path("/ibm,opal/sensors");
>>> if (!opal) {
>>> - dev_err(&pdev->dev, "Opal node 'sensors' not found\n");
>>> + dev_dbg(&pdev->dev, "Opal node 'sensors' not found\n");
>>> return -ENODEV;
>>> }
>>>
>>> @@ -335,7 +335,9 @@ static int __init ibmpowernv_init(void)
>>>
>>> err = platform_driver_probe(&ibmpowernv_driver, ibmpowernv_probe);
>>> if (err) {
>>> - pr_err("Platfrom driver probe failed\n");
>>> + if (err != -ENODEV)
>>> + pr_err("Platform driver probe failed (%d)\n", err);
>>> +
>>> goto exit_device_del;
>>> }
>>>
>>> --
>>> 1.9.1
>>>
>
next prev parent reply other threads:[~2014-11-01 21:15 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-31 6:45 [lm-sensors] [PATCH 1/2] hwmon: (ibmpowernv) Quieten when probing finds no device Michael Ellerman
2014-10-31 6:45 ` Michael Ellerman
2014-10-31 6:45 ` [lm-sensors] [PATCH 2/2] hwmon: (ibmpowernv) Make the driver name more recognisable Michael Ellerman
2014-10-31 6:45 ` Michael Ellerman
2014-10-31 8:35 ` [lm-sensors] " Jean Delvare
2014-10-31 8:35 ` Jean Delvare
2014-10-31 13:10 ` [lm-sensors] " Guenter Roeck
2014-10-31 13:10 ` Guenter Roeck
2014-10-31 9:41 ` [lm-sensors] [PATCH 1/2] hwmon: (ibmpowernv) Quieten when probing finds no device Jean Delvare
2014-10-31 9:41 ` Jean Delvare
2014-10-31 13:21 ` [lm-sensors] " Guenter Roeck
2014-10-31 13:21 ` Guenter Roeck
2014-11-01 17:53 ` Neelesh Gupta
2014-11-01 17:58 ` [lm-sensors] " Neelesh Gupta
2014-11-03 16:20 ` Guenter Roeck
2014-11-03 16:20 ` Guenter Roeck
2014-10-31 13:12 ` [lm-sensors] " Guenter Roeck
2014-10-31 13:12 ` Guenter Roeck
2014-10-31 18:12 ` [lm-sensors] " Guenter Roeck
2014-10-31 18:12 ` Guenter Roeck
2014-11-01 17:52 ` [lm-sensors] " Neelesh Gupta
2014-11-01 21:15 ` Guenter Roeck [this message]
2014-11-01 21:15 ` Guenter Roeck
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=54554D6D.5090509@roeck-us.net \
--to=linux@roeck-us.net \
--cc=jdelvare@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=lm-sensors@lm-sensors.org \
--cc=mpe@ellerman.id.au \
--cc=neelegup@linux.vnet.ibm.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.