[lm-sensors] [RFC PATCH 0/3] hwmon: (ibmpowernv) add DTS support

[lm-sensors] [RFC PATCH 0/3] hwmon: (ibmpowernv) add DTS support

[Cédric Le Goater]

SGVsbG8gIQoKVGhlc2UgcGF0Y2hlcyByZXdvcmsgdGhlIGlibXBvd2VybnYgZHJpdmVyIHRvIHN1
cHBvcnQgdGhlIG5ldyBkZXZpY2UgCnRyZWUgYXMgcHJvcG9zZWQgYnkgdGhpcyBwYXRjaHNldCBv
biB0aGUgc2tpYm9vdCBtYWlsaW5nIGxpc3QgOgoKICBodHRwczovL2xpc3RzLm96bGFicy5vcmcv
cGlwZXJtYWlsL3NraWJvb3QvMjAxNS1GZWJydWFyeS8wMDA0NTcuaHRtbAoKVGhleSBhcmUgYmFz
ZWQgb24gTGludXggMy4xOSBhbmQgd2VyZSB0ZXN0ZWQgb24gSUJNIFBvd2VyIGFuZCBPcGVuIFBv
d2VyIApzeXN0ZW1zIHJ1bm5pbmcgdHJ1c3R5LgoKVGhlIG1haW4gaXNzdWUgaXMgdGhhdCB0aGUg
bmV3IGRldmljZSB0cmVlIGlzIGluY29tcGF0aWJsZSB3aXRoIHRoZSAKcHJldmlvdXMgaWJtcG93
ZXJudiBkcml2ZXJzLiBUaGUgY29uc2VxdWVuY2UgaXMgbm8gcG93ZXJudiBzZW5zb3JzIApvbiBz
eXN0ZW1zIHdpdGggc3VjaCBhIG9wYWwvbGludXggY29uZmlndXJhdGlvbi4KCkNoZWVycywKCkMu
CgoKQ8OpZHJpYyBMZSBHb2F0ZXIgKDMpOgogIHBvd2VycGMvcG93ZXJudjogQ2hlY2sgT1BBTCBz
ZW5zb3IgY2FsbHMgZXhpc3QKICBwb3dlcnBjL3Bvd2VybnY6IGhhbmRsZSBPUEFMX1NVQ0NFU1Mg
cmV0dXJuIGluIG9wYWxfc2Vuc29yX3JlYWQKICBod21vbjogKGlibXBvd2VybnYpIGFkZCBEVFMg
c3VwcG9ydAoKIGFyY2gvcG93ZXJwYy9wbGF0Zm9ybXMvcG93ZXJudi9vcGFsLXNlbnNvci5jIHwg
ICAzMiArKy0KIGRyaXZlcnMvaHdtb24vaWJtcG93ZXJudi5jICAgICAgICAgICAgICAgICAgIHwg
IDMzNiArKysrKysrKysrKysrKy0tLS0tLS0tLS0tLQogMiBmaWxlcyBjaGFuZ2VkLCAyMDIgaW5z
ZXJ0aW9ucygrKSwgMTY2IGRlbGV0aW9ucygtKQoKLS0gCjEuNy4xMC40CgoKX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbG0tc2Vuc29ycyBtYWlsaW5nIGxp
c3QKbG0tc2Vuc29yc0BsbS1zZW5zb3JzLm9yZwpodHRwOi8vbGlzdHMubG0tc2Vuc29ycy5vcmcv
bWFpbG1hbi9saXN0aW5mby9sbS1zZW5zb3Jz

[RFC PATCH 0/3] hwmon: (ibmpowernv) add DTS support

[Cédric Le Goater]

Hello !

These patches rework the ibmpowernv driver to support the new device 
tree as proposed by this patchset on the skiboot mailing list :

  https://lists.ozlabs.org/pipermail/skiboot/2015-February/000457.html

They are based on Linux 3.19 and were tested on IBM Power and Open Power 
systems running trusty.

The main issue is that the new device tree is incompatible with the 
previous ibmpowernv drivers. The consequence is no powernv sensors 
on systems with such a opal/linux configuration.

Cheers,

C.


Cédric Le Goater (3):
  powerpc/powernv: Check OPAL sensor calls exist
  powerpc/powernv: handle OPAL_SUCCESS return in opal_sensor_read
  hwmon: (ibmpowernv) add DTS support

 arch/powerpc/platforms/powernv/opal-sensor.c |   32 ++-
 drivers/hwmon/ibmpowernv.c                   |  336 ++++++++++++++------------
 2 files changed, 202 insertions(+), 166 deletions(-)

-- 
1.7.10.4

Re: [lm-sensors] [RFC PATCH 0/3] hwmon: (ibmpowernv) add DTS support

[Guenter Roeck]

On Fri, Feb 20, 2015 at 04:07:34PM +0100, Cédric Le Goater wrote:
> Hello !
> 
> These patches rework the ibmpowernv driver to support the new device 
> tree as proposed by this patchset on the skiboot mailing list :
> 
>   https://lists.ozlabs.org/pipermail/skiboot/2015-February/000457.html
> 
> They are based on Linux 3.19 and were tested on IBM Power and Open Power 
> systems running trusty.
> 
> The main issue is that the new device tree is incompatible with the 
> previous ibmpowernv drivers. The consequence is no powernv sensors 
> on systems with such a opal/linux configuration.
> 
I don't think that would be acceptable. There must be lots of such
systems out there. Why does it have to be incompatible ?
Can't it support both the old and new versions ?

Guenter

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [RFC PATCH 0/3] hwmon: (ibmpowernv) add DTS support

[Guenter Roeck]

On Fri, Feb 20, 2015 at 04:07:34PM +0100, Cédric Le Goater wrote:
> Hello !
> 
> These patches rework the ibmpowernv driver to support the new device 
> tree as proposed by this patchset on the skiboot mailing list :
> 
>   https://lists.ozlabs.org/pipermail/skiboot/2015-February/000457.html
> 
> They are based on Linux 3.19 and were tested on IBM Power and Open Power 
> systems running trusty.
> 
> The main issue is that the new device tree is incompatible with the 
> previous ibmpowernv drivers. The consequence is no powernv sensors 
> on systems with such a opal/linux configuration.
> 
I don't think that would be acceptable. There must be lots of such
systems out there. Why does it have to be incompatible ?
Can't it support both the old and new versions ?

Guenter

Re: [lm-sensors] [RFC PATCH 0/3] hwmon: (ibmpowernv) add DTS support

[Cedric Le Goater]

On 02/20/2015 05:52 PM, Guenter Roeck wrote:
> On Fri, Feb 20, 2015 at 04:07:34PM +0100, Cédric Le Goater wrote:
>> Hello !
>>
>> These patches rework the ibmpowernv driver to support the new device 
>> tree as proposed by this patchset on the skiboot mailing list :
>>
>>   https://lists.ozlabs.org/pipermail/skiboot/2015-February/000457.html
>>
>> They are based on Linux 3.19 and were tested on IBM Power and Open Power 
>> systems running trusty.
>>
>> The main issue is that the new device tree is incompatible with the 
>> previous ibmpowernv drivers. The consequence is no powernv sensors 
>> on systems with such a opal/linux configuration.
>>
> I don't think that would be acceptable. There must be lots of such
> systems out there. Why does it have to be incompatible ?
> Can't it support both the old and new versions ?

I should have provided more explanation in the Linux patchset. Sorry 
for that. Here is the rationale behind this brutal code change.

The initial ibmpowernv driver was designed in the early days of the
powernv platform and the device tree it is using to expose the sensors 
has some limitations that makes it difficult to add new ones. The current 
layout of the device tree is also tightly coupled to IBM Power systems 
and their service processor (FSP). Open Power systems are different and 
need a different solution.

It is to get more sensors out the P8 (and there are quite a few) that 
the OPAL patchset [1] proposes a new device tree. On the Linux side, it 
feels simpler to make a jump forward and break the compatibility than 
to maintain multiple branches of code just to keep alive an early v1 
of the ibmpowernv driver.    

Open Power systems won't be impacted as ibmpowernv does not support them.


Cheers,

C.


[1] https://lists.ozlabs.org/pipermail/skiboot/2015-February/000457.html


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [RFC PATCH 0/3] hwmon: (ibmpowernv) add DTS support

[Cedric Le Goater]

On 02/20/2015 05:52 PM, Guenter Roeck wrote:
> On Fri, Feb 20, 2015 at 04:07:34PM +0100, Cédric Le Goater wrote:
>> Hello !
>>
>> These patches rework the ibmpowernv driver to support the new device 
>> tree as proposed by this patchset on the skiboot mailing list :
>>
>>   https://lists.ozlabs.org/pipermail/skiboot/2015-February/000457.html
>>
>> They are based on Linux 3.19 and were tested on IBM Power and Open Power 
>> systems running trusty.
>>
>> The main issue is that the new device tree is incompatible with the 
>> previous ibmpowernv drivers. The consequence is no powernv sensors 
>> on systems with such a opal/linux configuration.
>>
> I don't think that would be acceptable. There must be lots of such
> systems out there. Why does it have to be incompatible ?
> Can't it support both the old and new versions ?

I should have provided more explanation in the Linux patchset. Sorry 
for that. Here is the rationale behind this brutal code change.

The initial ibmpowernv driver was designed in the early days of the
powernv platform and the device tree it is using to expose the sensors 
has some limitations that makes it difficult to add new ones. The current 
layout of the device tree is also tightly coupled to IBM Power systems 
and their service processor (FSP). Open Power systems are different and 
need a different solution.

It is to get more sensors out the P8 (and there are quite a few) that 
the OPAL patchset [1] proposes a new device tree. On the Linux side, it 
feels simpler to make a jump forward and break the compatibility than 
to maintain multiple branches of code just to keep alive an early v1 
of the ibmpowernv driver.    

Open Power systems won't be impacted as ibmpowernv does not support them.


Cheers,

C.


[1] https://lists.ozlabs.org/pipermail/skiboot/2015-February/000457.html

Re: [lm-sensors] [RFC PATCH 0/3] hwmon: (ibmpowernv) add DTS support

[Guenter Roeck]

On 02/20/2015 12:15 PM, Cedric Le Goater wrote:
> On 02/20/2015 05:52 PM, Guenter Roeck wrote:
>> On Fri, Feb 20, 2015 at 04:07:34PM +0100, Cédric Le Goater wrote:
>>> Hello !
>>>
>>> These patches rework the ibmpowernv driver to support the new device
>>> tree as proposed by this patchset on the skiboot mailing list :
>>>
>>>    https://lists.ozlabs.org/pipermail/skiboot/2015-February/000457.html
>>>
>>> They are based on Linux 3.19 and were tested on IBM Power and Open Power
>>> systems running trusty.
>>>
>>> The main issue is that the new device tree is incompatible with the
>>> previous ibmpowernv drivers. The consequence is no powernv sensors
>>> on systems with such a opal/linux configuration.
>>>
>> I don't think that would be acceptable. There must be lots of such
>> systems out there. Why does it have to be incompatible ?
>> Can't it support both the old and new versions ?
>
> I should have provided more explanation in the Linux patchset. Sorry
> for that. Here is the rationale behind this brutal code change.
>
> The initial ibmpowernv driver was designed in the early days of the
> powernv platform and the device tree it is using to expose the sensors
> has some limitations that makes it difficult to add new ones. The current
> layout of the device tree is also tightly coupled to IBM Power systems
> and their service processor (FSP). Open Power systems are different and
> need a different solution.
>
> It is to get more sensors out the P8 (and there are quite a few) that
> the OPAL patchset [1] proposes a new device tree. On the Linux side, it
> feels simpler to make a jump forward and break the compatibility than
> to maintain multiple branches of code just to keep alive an early v1
> of the ibmpowernv driver.
>

Would it possibly be appropriate to write a different driver for the new
device tree ?

Guenter


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [RFC PATCH 0/3] hwmon: (ibmpowernv) add DTS support

[Guenter Roeck]

On 02/20/2015 12:15 PM, Cedric Le Goater wrote:
> On 02/20/2015 05:52 PM, Guenter Roeck wrote:
>> On Fri, Feb 20, 2015 at 04:07:34PM +0100, Cédric Le Goater wrote:
>>> Hello !
>>>
>>> These patches rework the ibmpowernv driver to support the new device
>>> tree as proposed by this patchset on the skiboot mailing list :
>>>
>>>    https://lists.ozlabs.org/pipermail/skiboot/2015-February/000457.html
>>>
>>> They are based on Linux 3.19 and were tested on IBM Power and Open Power
>>> systems running trusty.
>>>
>>> The main issue is that the new device tree is incompatible with the
>>> previous ibmpowernv drivers. The consequence is no powernv sensors
>>> on systems with such a opal/linux configuration.
>>>
>> I don't think that would be acceptable. There must be lots of such
>> systems out there. Why does it have to be incompatible ?
>> Can't it support both the old and new versions ?
>
> I should have provided more explanation in the Linux patchset. Sorry
> for that. Here is the rationale behind this brutal code change.
>
> The initial ibmpowernv driver was designed in the early days of the
> powernv platform and the device tree it is using to expose the sensors
> has some limitations that makes it difficult to add new ones. The current
> layout of the device tree is also tightly coupled to IBM Power systems
> and their service processor (FSP). Open Power systems are different and
> need a different solution.
>
> It is to get more sensors out the P8 (and there are quite a few) that
> the OPAL patchset [1] proposes a new device tree. On the Linux side, it
> feels simpler to make a jump forward and break the compatibility than
> to maintain multiple branches of code just to keep alive an early v1
> of the ibmpowernv driver.
>

Would it possibly be appropriate to write a different driver for the new
device tree ?

Guenter

Re: [lm-sensors] [RFC PATCH 0/3] hwmon: (ibmpowernv) add DTS support

[Cedric Le Goater]

On 02/21/2015 12:52 AM, Guenter Roeck wrote:
> On 02/20/2015 12:15 PM, Cedric Le Goater wrote:
>> On 02/20/2015 05:52 PM, Guenter Roeck wrote:
>>> On Fri, Feb 20, 2015 at 04:07:34PM +0100, Cédric Le Goater wrote:
>>>> Hello !
>>>>
>>>> These patches rework the ibmpowernv driver to support the new device
>>>> tree as proposed by this patchset on the skiboot mailing list :
>>>>
>>>>    https://lists.ozlabs.org/pipermail/skiboot/2015-February/000457.html
>>>>
>>>> They are based on Linux 3.19 and were tested on IBM Power and Open Power
>>>> systems running trusty.
>>>>
>>>> The main issue is that the new device tree is incompatible with the
>>>> previous ibmpowernv drivers. The consequence is no powernv sensors
>>>> on systems with such a opal/linux configuration.
>>>>
>>> I don't think that would be acceptable. There must be lots of such
>>> systems out there. Why does it have to be incompatible ?
>>> Can't it support both the old and new versions ?
>>
>> I should have provided more explanation in the Linux patchset. Sorry
>> for that. Here is the rationale behind this brutal code change.
>>
>> The initial ibmpowernv driver was designed in the early days of the
>> powernv platform and the device tree it is using to expose the sensors
>> has some limitations that makes it difficult to add new ones. The current
>> layout of the device tree is also tightly coupled to IBM Power systems
>> and their service processor (FSP). Open Power systems are different and
>> need a different solution.
>>
>> It is to get more sensors out the P8 (and there are quite a few) that
>> the OPAL patchset [1] proposes a new device tree. On the Linux side, it
>> feels simpler to make a jump forward and break the compatibility than
>> to maintain multiple branches of code just to keep alive an early v1
>> of the ibmpowernv driver.
>>
> 
> Would it possibly be appropriate to write a different driver for the new
> device tree ?

Sure. That is an option. 

There are no conflicts between the trees so we can live with two drivers 
using the same sensors/ root node. With time we will deprecate the initial
one.

Is that the preferred option ? How would we name the new driver ? 

	1. powernv
	2. powernv-hwmon
	3. openpowernv
	4. ibmpowernv2 

Thanks,

C.



_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [RFC PATCH 0/3] hwmon: (ibmpowernv) add DTS support

[Cedric Le Goater]

On 02/21/2015 12:52 AM, Guenter Roeck wrote:
> On 02/20/2015 12:15 PM, Cedric Le Goater wrote:
>> On 02/20/2015 05:52 PM, Guenter Roeck wrote:
>>> On Fri, Feb 20, 2015 at 04:07:34PM +0100, Cédric Le Goater wrote:
>>>> Hello !
>>>>
>>>> These patches rework the ibmpowernv driver to support the new device
>>>> tree as proposed by this patchset on the skiboot mailing list :
>>>>
>>>>    https://lists.ozlabs.org/pipermail/skiboot/2015-February/000457.html
>>>>
>>>> They are based on Linux 3.19 and were tested on IBM Power and Open Power
>>>> systems running trusty.
>>>>
>>>> The main issue is that the new device tree is incompatible with the
>>>> previous ibmpowernv drivers. The consequence is no powernv sensors
>>>> on systems with such a opal/linux configuration.
>>>>
>>> I don't think that would be acceptable. There must be lots of such
>>> systems out there. Why does it have to be incompatible ?
>>> Can't it support both the old and new versions ?
>>
>> I should have provided more explanation in the Linux patchset. Sorry
>> for that. Here is the rationale behind this brutal code change.
>>
>> The initial ibmpowernv driver was designed in the early days of the
>> powernv platform and the device tree it is using to expose the sensors
>> has some limitations that makes it difficult to add new ones. The current
>> layout of the device tree is also tightly coupled to IBM Power systems
>> and their service processor (FSP). Open Power systems are different and
>> need a different solution.
>>
>> It is to get more sensors out the P8 (and there are quite a few) that
>> the OPAL patchset [1] proposes a new device tree. On the Linux side, it
>> feels simpler to make a jump forward and break the compatibility than
>> to maintain multiple branches of code just to keep alive an early v1
>> of the ibmpowernv driver.
>>
> 
> Would it possibly be appropriate to write a different driver for the new
> device tree ?

Sure. That is an option. 

There are no conflicts between the trees so we can live with two drivers 
using the same sensors/ root node. With time we will deprecate the initial
one.

Is that the preferred option ? How would we name the new driver ? 

	1. powernv
	2. powernv-hwmon
	3. openpowernv
	4. ibmpowernv2 

Thanks,

C.

Re: [lm-sensors] [RFC PATCH 0/3] hwmon: (ibmpowernv) add DTS support

[Guenter Roeck]

On 02/20/2015 11:14 PM, Cedric Le Goater wrote:
> On 02/21/2015 12:52 AM, Guenter Roeck wrote:
>> On 02/20/2015 12:15 PM, Cedric Le Goater wrote:
>>> On 02/20/2015 05:52 PM, Guenter Roeck wrote:
>>>> On Fri, Feb 20, 2015 at 04:07:34PM +0100, Cédric Le Goater wrote:
>>>>> Hello !
>>>>>
>>>>> These patches rework the ibmpowernv driver to support the new device
>>>>> tree as proposed by this patchset on the skiboot mailing list :
>>>>>
>>>>>     https://lists.ozlabs.org/pipermail/skiboot/2015-February/000457.html
>>>>>
>>>>> They are based on Linux 3.19 and were tested on IBM Power and Open Power
>>>>> systems running trusty.
>>>>>
>>>>> The main issue is that the new device tree is incompatible with the
>>>>> previous ibmpowernv drivers. The consequence is no powernv sensors
>>>>> on systems with such a opal/linux configuration.
>>>>>
>>>> I don't think that would be acceptable. There must be lots of such
>>>> systems out there. Why does it have to be incompatible ?
>>>> Can't it support both the old and new versions ?
>>>
>>> I should have provided more explanation in the Linux patchset. Sorry
>>> for that. Here is the rationale behind this brutal code change.
>>>
>>> The initial ibmpowernv driver was designed in the early days of the
>>> powernv platform and the device tree it is using to expose the sensors
>>> has some limitations that makes it difficult to add new ones. The current
>>> layout of the device tree is also tightly coupled to IBM Power systems
>>> and their service processor (FSP). Open Power systems are different and
>>> need a different solution.
>>>
>>> It is to get more sensors out the P8 (and there are quite a few) that
>>> the OPAL patchset [1] proposes a new device tree. On the Linux side, it
>>> feels simpler to make a jump forward and break the compatibility than
>>> to maintain multiple branches of code just to keep alive an early v1
>>> of the ibmpowernv driver.
>>>
>>
>> Would it possibly be appropriate to write a different driver for the new
>> device tree ?
>
> Sure. That is an option.
>
> There are no conflicts between the trees so we can live with two drivers
> using the same sensors/ root node. With time we will deprecate the initial
> one.
>
You lost me a bit. Are you saying you are going to replace the devicetree
properties with something that is incompatible but retain the same
compatible properties ? If so, how do you expect this to work ?
How do you expect to be able to determine which version of devicetree
is loaded, and thus which driver is needed ?

I'll have to understand this way better. The link above doesn't explain
what the differences are, nor how the driver is supposed to know what
to do.

Guenter


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [RFC PATCH 0/3] hwmon: (ibmpowernv) add DTS support

[Guenter Roeck]

On 02/20/2015 11:14 PM, Cedric Le Goater wrote:
> On 02/21/2015 12:52 AM, Guenter Roeck wrote:
>> On 02/20/2015 12:15 PM, Cedric Le Goater wrote:
>>> On 02/20/2015 05:52 PM, Guenter Roeck wrote:
>>>> On Fri, Feb 20, 2015 at 04:07:34PM +0100, Cédric Le Goater wrote:
>>>>> Hello !
>>>>>
>>>>> These patches rework the ibmpowernv driver to support the new device
>>>>> tree as proposed by this patchset on the skiboot mailing list :
>>>>>
>>>>>     https://lists.ozlabs.org/pipermail/skiboot/2015-February/000457.html
>>>>>
>>>>> They are based on Linux 3.19 and were tested on IBM Power and Open Power
>>>>> systems running trusty.
>>>>>
>>>>> The main issue is that the new device tree is incompatible with the
>>>>> previous ibmpowernv drivers. The consequence is no powernv sensors
>>>>> on systems with such a opal/linux configuration.
>>>>>
>>>> I don't think that would be acceptable. There must be lots of such
>>>> systems out there. Why does it have to be incompatible ?
>>>> Can't it support both the old and new versions ?
>>>
>>> I should have provided more explanation in the Linux patchset. Sorry
>>> for that. Here is the rationale behind this brutal code change.
>>>
>>> The initial ibmpowernv driver was designed in the early days of the
>>> powernv platform and the device tree it is using to expose the sensors
>>> has some limitations that makes it difficult to add new ones. The current
>>> layout of the device tree is also tightly coupled to IBM Power systems
>>> and their service processor (FSP). Open Power systems are different and
>>> need a different solution.
>>>
>>> It is to get more sensors out the P8 (and there are quite a few) that
>>> the OPAL patchset [1] proposes a new device tree. On the Linux side, it
>>> feels simpler to make a jump forward and break the compatibility than
>>> to maintain multiple branches of code just to keep alive an early v1
>>> of the ibmpowernv driver.
>>>
>>
>> Would it possibly be appropriate to write a different driver for the new
>> device tree ?
>
> Sure. That is an option.
>
> There are no conflicts between the trees so we can live with two drivers
> using the same sensors/ root node. With time we will deprecate the initial
> one.
>
You lost me a bit. Are you saying you are going to replace the devicetree
properties with something that is incompatible but retain the same
compatible properties ? If so, how do you expect this to work ?
How do you expect to be able to determine which version of devicetree
is loaded, and thus which driver is needed ?

I'll have to understand this way better. The link above doesn't explain
what the differences are, nor how the driver is supposed to know what
to do.

Guenter

Re: [lm-sensors] [RFC PATCH 0/3] hwmon: (ibmpowernv) add DTS support

[Cedric Le Goater]

On 02/21/2015 12:03 PM, Guenter Roeck wrote:
> On 02/20/2015 11:14 PM, Cedric Le Goater wrote:
>> On 02/21/2015 12:52 AM, Guenter Roeck wrote:
>>> On 02/20/2015 12:15 PM, Cedric Le Goater wrote:
>>>> On 02/20/2015 05:52 PM, Guenter Roeck wrote:
>>>>> On Fri, Feb 20, 2015 at 04:07:34PM +0100, Cédric Le Goater wrote:
>>>>>> Hello !
>>>>>>
>>>>>> These patches rework the ibmpowernv driver to support the new device
>>>>>> tree as proposed by this patchset on the skiboot mailing list :
>>>>>>
>>>>>>     https://lists.ozlabs.org/pipermail/skiboot/2015-February/000457.html
>>>>>>
>>>>>> They are based on Linux 3.19 and were tested on IBM Power and Open Power
>>>>>> systems running trusty.
>>>>>>
>>>>>> The main issue is that the new device tree is incompatible with the
>>>>>> previous ibmpowernv drivers. The consequence is no powernv sensors
>>>>>> on systems with such a opal/linux configuration.
>>>>>>
>>>>> I don't think that would be acceptable. There must be lots of such
>>>>> systems out there. Why does it have to be incompatible ?
>>>>> Can't it support both the old and new versions ?
>>>>
>>>> I should have provided more explanation in the Linux patchset. Sorry
>>>> for that. Here is the rationale behind this brutal code change.
>>>>
>>>> The initial ibmpowernv driver was designed in the early days of the
>>>> powernv platform and the device tree it is using to expose the sensors
>>>> has some limitations that makes it difficult to add new ones. The current
>>>> layout of the device tree is also tightly coupled to IBM Power systems
>>>> and their service processor (FSP). Open Power systems are different and
>>>> need a different solution.
>>>>
>>>> It is to get more sensors out the P8 (and there are quite a few) that
>>>> the OPAL patchset [1] proposes a new device tree. On the Linux side, it
>>>> feels simpler to make a jump forward and break the compatibility than
>>>> to maintain multiple branches of code just to keep alive an early v1
>>>> of the ibmpowernv driver.
>>>>
>>>
>>> Would it possibly be appropriate to write a different driver for the new
>>> device tree ?
>>
>> Sure. That is an option.
>>
>> There are no conflicts between the trees so we can live with two drivers
>> using the same sensors/ root node. With time we will deprecate the initial
>> one.
>>
> You lost me a bit. Are you saying you are going to replace the devicetree
> properties with something that is incompatible but retain the same
> compatible properties ? If so, how do you expect this to work ?
> How do you expect to be able to determine which version of devicetree
> is loaded, and thus which driver is needed ?
>
> I'll have to understand this way better. The link above doesn't explain
> what the differences are, nor how the driver is supposed to know what
> to do.
 
Sure. My bad. I did not provide enough information in this RFC. Thanks for
your patience ! 


The current hwmon driver ibmpowernv relies on a device tree provided by 
the OPAL firmware. Today, this tree has the following layout :

	ibm,opal/sensors/
	|-- amb-temp#1-data
	|   |-- compatible
	|   |-- linux,phandle
	|   |-- name
	|   |-- phandle
	|   `-- sensor-id
	|-- amb-temp#1-thrs
	|   |-- compatible
	|   |-- linux,phandle
	|   |-- name
	|   |-- phandle
	|   `-- sensor-id
	|-- cooling-fan#10-data
	|   |-- compatible
	|   |-- linux,phandle
	|   |-- name
	|   |-- phandle
	|   `-- sensor-id
	|-- cooling-fan#10-faulted
	|   |-- compatible
	|   |-- linux,phandle
	|   |-- name
	|   |-- phandle
	|   `-- sensor-id
	|-- cooling-fan#10-thrs
	|   |-- compatible
	|   |-- linux,phandle
	|   |-- name
	|   |-- phandle
	|   `-- sensor-id
	...

It has some limitations and we want to change it to something more flexible, 
giving us the ability to add new sensors. The new device tree layout is 
described here :

	https://lists.ozlabs.org/pipermail/skiboot/2015-February/000457.html


Both layouts use the same root node "ibm,opal/sensors" but the underlying
nodes have nothing in common, which means that the current driver ibmpowernv
will not 'see' any sensors on a system with an OPAL firmware exposing the new 
device tree. One will need new code for it. 

We have a few options to add support for this new tree :

 1. modify the current driver to parse the two trees. It seems overly complex 
    and the resulting code will be a pain to maintain. 

 2. add a new driver. As the two drivers can cohabitate, it is a viable solution.
    We will let the old driver rot in its corner and deprecate it one day. Kind
    of ugly to keep this code around.

 3. replace the current driver with a new one. The simplest and most brutal but 
    it also means we loose sensor support for IBM P8 systems running the old OPAL 
    firmware. I don't think it is a problem as these systems are bound to update 
    their firmware due to the amount of development currently being done on the 
    OPAL side.

    Open Power systems are not impacted.


Is that clearer ? and I would go for option 3.

Thanks,

C.
   






C. 


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [RFC PATCH 0/3] hwmon: (ibmpowernv) add DTS support

[Cedric Le Goater]

On 02/21/2015 12:03 PM, Guenter Roeck wrote:
> On 02/20/2015 11:14 PM, Cedric Le Goater wrote:
>> On 02/21/2015 12:52 AM, Guenter Roeck wrote:
>>> On 02/20/2015 12:15 PM, Cedric Le Goater wrote:
>>>> On 02/20/2015 05:52 PM, Guenter Roeck wrote:
>>>>> On Fri, Feb 20, 2015 at 04:07:34PM +0100, Cédric Le Goater wrote:
>>>>>> Hello !
>>>>>>
>>>>>> These patches rework the ibmpowernv driver to support the new device
>>>>>> tree as proposed by this patchset on the skiboot mailing list :
>>>>>>
>>>>>>     https://lists.ozlabs.org/pipermail/skiboot/2015-February/000457.html
>>>>>>
>>>>>> They are based on Linux 3.19 and were tested on IBM Power and Open Power
>>>>>> systems running trusty.
>>>>>>
>>>>>> The main issue is that the new device tree is incompatible with the
>>>>>> previous ibmpowernv drivers. The consequence is no powernv sensors
>>>>>> on systems with such a opal/linux configuration.
>>>>>>
>>>>> I don't think that would be acceptable. There must be lots of such
>>>>> systems out there. Why does it have to be incompatible ?
>>>>> Can't it support both the old and new versions ?
>>>>
>>>> I should have provided more explanation in the Linux patchset. Sorry
>>>> for that. Here is the rationale behind this brutal code change.
>>>>
>>>> The initial ibmpowernv driver was designed in the early days of the
>>>> powernv platform and the device tree it is using to expose the sensors
>>>> has some limitations that makes it difficult to add new ones. The current
>>>> layout of the device tree is also tightly coupled to IBM Power systems
>>>> and their service processor (FSP). Open Power systems are different and
>>>> need a different solution.
>>>>
>>>> It is to get more sensors out the P8 (and there are quite a few) that
>>>> the OPAL patchset [1] proposes a new device tree. On the Linux side, it
>>>> feels simpler to make a jump forward and break the compatibility than
>>>> to maintain multiple branches of code just to keep alive an early v1
>>>> of the ibmpowernv driver.
>>>>
>>>
>>> Would it possibly be appropriate to write a different driver for the new
>>> device tree ?
>>
>> Sure. That is an option.
>>
>> There are no conflicts between the trees so we can live with two drivers
>> using the same sensors/ root node. With time we will deprecate the initial
>> one.
>>
> You lost me a bit. Are you saying you are going to replace the devicetree
> properties with something that is incompatible but retain the same
> compatible properties ? If so, how do you expect this to work ?
> How do you expect to be able to determine which version of devicetree
> is loaded, and thus which driver is needed ?
>
> I'll have to understand this way better. The link above doesn't explain
> what the differences are, nor how the driver is supposed to know what
> to do.
 
Sure. My bad. I did not provide enough information in this RFC. Thanks for
your patience ! 


The current hwmon driver ibmpowernv relies on a device tree provided by 
the OPAL firmware. Today, this tree has the following layout :

	ibm,opal/sensors/
	|-- amb-temp#1-data
	|   |-- compatible
	|   |-- linux,phandle
	|   |-- name
	|   |-- phandle
	|   `-- sensor-id
	|-- amb-temp#1-thrs
	|   |-- compatible
	|   |-- linux,phandle
	|   |-- name
	|   |-- phandle
	|   `-- sensor-id
	|-- cooling-fan#10-data
	|   |-- compatible
	|   |-- linux,phandle
	|   |-- name
	|   |-- phandle
	|   `-- sensor-id
	|-- cooling-fan#10-faulted
	|   |-- compatible
	|   |-- linux,phandle
	|   |-- name
	|   |-- phandle
	|   `-- sensor-id
	|-- cooling-fan#10-thrs
	|   |-- compatible
	|   |-- linux,phandle
	|   |-- name
	|   |-- phandle
	|   `-- sensor-id
	...

It has some limitations and we want to change it to something more flexible, 
giving us the ability to add new sensors. The new device tree layout is 
described here :

	https://lists.ozlabs.org/pipermail/skiboot/2015-February/000457.html


Both layouts use the same root node "ibm,opal/sensors" but the underlying
nodes have nothing in common, which means that the current driver ibmpowernv
will not 'see' any sensors on a system with an OPAL firmware exposing the new 
device tree. One will need new code for it. 

We have a few options to add support for this new tree :

 1. modify the current driver to parse the two trees. It seems overly complex 
    and the resulting code will be a pain to maintain. 

 2. add a new driver. As the two drivers can cohabitate, it is a viable solution.
    We will let the old driver rot in its corner and deprecate it one day. Kind
    of ugly to keep this code around.

 3. replace the current driver with a new one. The simplest and most brutal but 
    it also means we loose sensor support for IBM P8 systems running the old OPAL 
    firmware. I don't think it is a problem as these systems are bound to update 
    their firmware due to the amount of development currently being done on the 
    OPAL side.

    Open Power systems are not impacted.


Is that clearer ? and I would go for option 3.

Thanks,

C.
   






C. 

[lm-sensors] [RFC PATCH 1/3] powerpc/powernv: Check OPAL sensor calls exist

U2lnbmVkLW9mZi1ieTogQ8OpZHJpYyBMZSBHb2F0ZXIgPGNsZ0Bmci5pYm0uY29tPgotLS0KIGFy
Y2gvcG93ZXJwYy9wbGF0Zm9ybXMvcG93ZXJudi9vcGFsLXNlbnNvci5jIHwgICAgMyArKysKIDEg
ZmlsZSBjaGFuZ2VkLCAzIGluc2VydGlvbnMoKykKCmRpZmYgLS1naXQgYS9hcmNoL3Bvd2VycGMv
cGxhdGZvcm1zL3Bvd2VybnYvb3BhbC1zZW5zb3IuYyBiL2FyY2gvcG93ZXJwYy9wbGF0Zm9ybXMv
cG93ZXJudi9vcGFsLXNlbnNvci5jCmluZGV4IDRhYjY3ZWY3YWJjOS4uNTQ0MjkyZjIwMjBmIDEw
MDY0NAotLS0gYS9hcmNoL3Bvd2VycGMvcGxhdGZvcm1zL3Bvd2VybnYvb3BhbC1zZW5zb3IuYwor
KysgYi9hcmNoL3Bvd2VycGMvcGxhdGZvcm1zL3Bvd2VybnYvb3BhbC1zZW5zb3IuYwpAQCAtNzIs
NiArNzIsOSBAQCBzdGF0aWMgX19pbml0IGludCBvcGFsX3NlbnNvcl9pbml0KHZvaWQpCiAJc3Ry
dWN0IHBsYXRmb3JtX2RldmljZSAqcGRldjsKIAlzdHJ1Y3QgZGV2aWNlX25vZGUgKnNlbnNvcjsK
IAorCWlmICghb3BhbF9jaGVja190b2tlbihPUEFMX1NFTlNPUl9SRUFEKSkKKwkJcmV0dXJuIC1F
Tk9ERVY7CisKIAlzZW5zb3IgPSBvZl9maW5kX25vZGVfYnlfcGF0aCgiL2libSxvcGFsL3NlbnNv
cnMiKTsKIAlpZiAoIXNlbnNvcikgewogCQlwcl9lcnIoIk9wYWwgbm9kZSAnc2Vuc29ycycgbm90
IGZvdW5kXG4iKTsKLS0gCjEuNy4xMC40CgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18KbG0tc2Vuc29ycyBtYWlsaW5nIGxpc3QKbG0tc2Vuc29yc0BsbS1z
ZW5zb3JzLm9yZwpodHRwOi8vbGlzdHMubG0tc2Vuc29ycy5vcmcvbWFpbG1hbi9saXN0aW5mby9s
bS1zZW5zb3Jz

[RFC PATCH 1/3] powerpc/powernv: Check OPAL sensor calls exist

[Cédric Le Goater]

Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>
---
 arch/powerpc/platforms/powernv/opal-sensor.c |    3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/powerpc/platforms/powernv/opal-sensor.c b/arch/powerpc/platforms/powernv/opal-sensor.c
index 4ab67ef7abc9..544292f2020f 100644
--- a/arch/powerpc/platforms/powernv/opal-sensor.c
+++ b/arch/powerpc/platforms/powernv/opal-sensor.c
@@ -72,6 +72,9 @@ static __init int opal_sensor_init(void)
 	struct platform_device *pdev;
 	struct device_node *sensor;
 
+	if (!opal_check_token(OPAL_SENSOR_READ))
+		return -ENODEV;
+
 	sensor = of_find_node_by_path("/ibm,opal/sensors");
 	if (!sensor) {
 		pr_err("Opal node 'sensors' not found\n");
-- 
1.7.10.4

Re: [lm-sensors] [RFC PATCH 1/3] powerpc/powernv: Check OPAL sensor calls exist

[Guenter Roeck]

On Fri, Feb 20, 2015 at 04:07:35PM +0100, Cédric Le Goater wrote:

You should explain here why this patch is needed.

> Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>
> ---
>  arch/powerpc/platforms/powernv/opal-sensor.c |    3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/arch/powerpc/platforms/powernv/opal-sensor.c b/arch/powerpc/platforms/powernv/opal-sensor.c
> index 4ab67ef7abc9..544292f2020f 100644
> --- a/arch/powerpc/platforms/powernv/opal-sensor.c
> +++ b/arch/powerpc/platforms/powernv/opal-sensor.c
> @@ -72,6 +72,9 @@ static __init int opal_sensor_init(void)
>  	struct platform_device *pdev;
>  	struct device_node *sensor;
>  
> +	if (!opal_check_token(OPAL_SENSOR_READ))
> +		return -ENODEV;
> +
>  	sensor = of_find_node_by_path("/ibm,opal/sensors");
>  	if (!sensor) {
>  		pr_err("Opal node 'sensors' not found\n");
> -- 
> 1.7.10.4
> 

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [RFC PATCH 1/3] powerpc/powernv: Check OPAL sensor calls exist

[Guenter Roeck]

On Fri, Feb 20, 2015 at 04:07:35PM +0100, Cédric Le Goater wrote:

You should explain here why this patch is needed.

> Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>
> ---
>  arch/powerpc/platforms/powernv/opal-sensor.c |    3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/arch/powerpc/platforms/powernv/opal-sensor.c b/arch/powerpc/platforms/powernv/opal-sensor.c
> index 4ab67ef7abc9..544292f2020f 100644
> --- a/arch/powerpc/platforms/powernv/opal-sensor.c
> +++ b/arch/powerpc/platforms/powernv/opal-sensor.c
> @@ -72,6 +72,9 @@ static __init int opal_sensor_init(void)
>  	struct platform_device *pdev;
>  	struct device_node *sensor;
>  
> +	if (!opal_check_token(OPAL_SENSOR_READ))
> +		return -ENODEV;
> +
>  	sensor = of_find_node_by_path("/ibm,opal/sensors");
>  	if (!sensor) {
>  		pr_err("Opal node 'sensors' not found\n");
> -- 
> 1.7.10.4
> 

Re: [lm-sensors] [RFC PATCH 1/3] powerpc/powernv: Check OPAL sensor calls exist

[Cedric Le Goater]

On 02/20/2015 05:53 PM, Guenter Roeck wrote:
> On Fri, Feb 20, 2015 at 04:07:35PM +0100, Cédric Le Goater wrote:
> 
> You should explain here why this patch is needed.

Yes. What it does is to check that the firmware exposes the service
this driver is using (OPAL_SENSOR_READ). I will fix it.

Thanks,

C. 


> 
>> Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>
>> ---
>>  arch/powerpc/platforms/powernv/opal-sensor.c |    3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/arch/powerpc/platforms/powernv/opal-sensor.c b/arch/powerpc/platforms/powernv/opal-sensor.c
>> index 4ab67ef7abc9..544292f2020f 100644
>> --- a/arch/powerpc/platforms/powernv/opal-sensor.c
>> +++ b/arch/powerpc/platforms/powernv/opal-sensor.c
>> @@ -72,6 +72,9 @@ static __init int opal_sensor_init(void)
>>  	struct platform_device *pdev;
>>  	struct device_node *sensor;
>>  
>> +	if (!opal_check_token(OPAL_SENSOR_READ))
>> +		return -ENODEV;
>> +
>>  	sensor = of_find_node_by_path("/ibm,opal/sensors");
>>  	if (!sensor) {
>>  		pr_err("Opal node 'sensors' not found\n");
>> -- 
>> 1.7.10.4
>>
> 


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [RFC PATCH 1/3] powerpc/powernv: Check OPAL sensor calls exist

[Cedric Le Goater]

On 02/20/2015 05:53 PM, Guenter Roeck wrote:
> On Fri, Feb 20, 2015 at 04:07:35PM +0100, Cédric Le Goater wrote:
> 
> You should explain here why this patch is needed.

Yes. What it does is to check that the firmware exposes the service
this driver is using (OPAL_SENSOR_READ). I will fix it.

Thanks,

C. 


> 
>> Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>
>> ---
>>  arch/powerpc/platforms/powernv/opal-sensor.c |    3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/arch/powerpc/platforms/powernv/opal-sensor.c b/arch/powerpc/platforms/powernv/opal-sensor.c
>> index 4ab67ef7abc9..544292f2020f 100644
>> --- a/arch/powerpc/platforms/powernv/opal-sensor.c
>> +++ b/arch/powerpc/platforms/powernv/opal-sensor.c
>> @@ -72,6 +72,9 @@ static __init int opal_sensor_init(void)
>>  	struct platform_device *pdev;
>>  	struct device_node *sensor;
>>  
>> +	if (!opal_check_token(OPAL_SENSOR_READ))
>> +		return -ENODEV;
>> +
>>  	sensor = of_find_node_by_path("/ibm,opal/sensors");
>>  	if (!sensor) {
>>  		pr_err("Opal node 'sensors' not found\n");
>> -- 
>> 1.7.10.4
>>
> 

Re: [lm-sensors] [RFC PATCH 1/3] powerpc/powernv: Check OPAL sensor calls exist

[Michael Ellerman]

T24gRnJpLCAyMDE1LTAyLTIwIGF0IDE2OjA3ICswMTAwLCBDw6lkcmljIExlIEdvYXRlciB3cm90
ZToKPiBTaWduZWQtb2ZmLWJ5OiBDw6lkcmljIExlIEdvYXRlciA8Y2xnQGZyLmlibS5jb20+Cj4g
LS0tCj4gIGFyY2gvcG93ZXJwYy9wbGF0Zm9ybXMvcG93ZXJudi9vcGFsLXNlbnNvci5jIHwgICAg
MyArKysKPiAgMSBmaWxlIGNoYW5nZWQsIDMgaW5zZXJ0aW9ucygrKQo+IAo+IGRpZmYgLS1naXQg
YS9hcmNoL3Bvd2VycGMvcGxhdGZvcm1zL3Bvd2VybnYvb3BhbC1zZW5zb3IuYyBiL2FyY2gvcG93
ZXJwYy9wbGF0Zm9ybXMvcG93ZXJudi9vcGFsLXNlbnNvci5jCj4gaW5kZXggNGFiNjdlZjdhYmM5
Li41NDQyOTJmMjAyMGYgMTAwNjQ0Cj4gLS0tIGEvYXJjaC9wb3dlcnBjL3BsYXRmb3Jtcy9wb3dl
cm52L29wYWwtc2Vuc29yLmMKPiArKysgYi9hcmNoL3Bvd2VycGMvcGxhdGZvcm1zL3Bvd2VybnYv
b3BhbC1zZW5zb3IuYwo+IEBAIC03Miw2ICs3Miw5IEBAIHN0YXRpYyBfX2luaXQgaW50IG9wYWxf
c2Vuc29yX2luaXQodm9pZCkKPiAgCXN0cnVjdCBwbGF0Zm9ybV9kZXZpY2UgKnBkZXY7Cj4gIAlz
dHJ1Y3QgZGV2aWNlX25vZGUgKnNlbnNvcjsKPiAgCj4gKwlpZiAoIW9wYWxfY2hlY2tfdG9rZW4o
T1BBTF9TRU5TT1JfUkVBRCkpCj4gKwkJcmV0dXJuIC1FTk9ERVY7Cj4gKwo+ICAJc2Vuc29yID0g
b2ZfZmluZF9ub2RlX2J5X3BhdGgoIi9pYm0sb3BhbC9zZW5zb3JzIik7Cj4gIAlpZiAoIXNlbnNv
cikgewo+ICAJCXByX2VycigiT3BhbCBub2RlICdzZW5zb3JzJyBub3QgZm91bmRcbiIpOwoKQXJl
IHlvdSBhY3R1YWxseSBzZWVpbmcgdGhpcyBpbiBwcmFjdGljZT8KCkl0J3MgYSBiaXQgYW5ub3lp
bmcgdGhhdCB3ZSBoYXZlIHRvIGNoZWNrIGZvciB0aGUgdG9rZW4sIGFuZCB0aGVuIGFsc28gY2hl
Y2sKdGhlIGRldmljZSB0cmVlLiBJdCB3b3VsZCBiZSBuaWNlIGlmIG9uZSBpbXBsaWVkIHRoZSBw
cmVzZW5jZSBvZiB0aGUgb3RoZXIuCgpjaGVlcnMKCgoKX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18KbG0tc2Vuc29ycyBtYWlsaW5nIGxpc3QKbG0tc2Vuc29y
c0BsbS1zZW5zb3JzLm9yZwpodHRwOi8vbGlzdHMubG0tc2Vuc29ycy5vcmcvbWFpbG1hbi9saXN0
aW5mby9sbS1zZW5zb3Jz

Re: [RFC PATCH 1/3] powerpc/powernv: Check OPAL sensor calls exist

[Michael Ellerman]

On Fri, 2015-02-20 at 16:07 +0100, Cédric Le Goater wrote:
> Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>
> ---
>  arch/powerpc/platforms/powernv/opal-sensor.c |    3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/arch/powerpc/platforms/powernv/opal-sensor.c b/arch/powerpc/platforms/powernv/opal-sensor.c
> index 4ab67ef7abc9..544292f2020f 100644
> --- a/arch/powerpc/platforms/powernv/opal-sensor.c
> +++ b/arch/powerpc/platforms/powernv/opal-sensor.c
> @@ -72,6 +72,9 @@ static __init int opal_sensor_init(void)
>  	struct platform_device *pdev;
>  	struct device_node *sensor;
>  
> +	if (!opal_check_token(OPAL_SENSOR_READ))
> +		return -ENODEV;
> +
>  	sensor = of_find_node_by_path("/ibm,opal/sensors");
>  	if (!sensor) {
>  		pr_err("Opal node 'sensors' not found\n");

Are you actually seeing this in practice?

It's a bit annoying that we have to check for the token, and then also check
the device tree. It would be nice if one implied the presence of the other.

cheers

Re: [lm-sensors] [RFC PATCH 1/3] powerpc/powernv: Check OPAL sensor calls exist

[Cedric Le Goater]

T24gMDIvMjQvMjAxNSAwNTo1NCBBTSwgTWljaGFlbCBFbGxlcm1hbiB3cm90ZToKPiBPbiBGcmks
IDIwMTUtMDItMjAgYXQgMTY6MDcgKzAxMDAsIEPDqWRyaWMgTGUgR29hdGVyIHdyb3RlOgo+PiBT
aWduZWQtb2ZmLWJ5OiBDw6lkcmljIExlIEdvYXRlciA8Y2xnQGZyLmlibS5jb20+Cj4+IC0tLQo+
PiAgYXJjaC9wb3dlcnBjL3BsYXRmb3Jtcy9wb3dlcm52L29wYWwtc2Vuc29yLmMgfCAgICAzICsr
Kwo+PiAgMSBmaWxlIGNoYW5nZWQsIDMgaW5zZXJ0aW9ucygrKQo+Pgo+PiBkaWZmIC0tZ2l0IGEv
YXJjaC9wb3dlcnBjL3BsYXRmb3Jtcy9wb3dlcm52L29wYWwtc2Vuc29yLmMgYi9hcmNoL3Bvd2Vy
cGMvcGxhdGZvcm1zL3Bvd2VybnYvb3BhbC1zZW5zb3IuYwo+PiBpbmRleCA0YWI2N2VmN2FiYzku
LjU0NDI5MmYyMDIwZiAxMDA2NDQKPj4gLS0tIGEvYXJjaC9wb3dlcnBjL3BsYXRmb3Jtcy9wb3dl
cm52L29wYWwtc2Vuc29yLmMKPj4gKysrIGIvYXJjaC9wb3dlcnBjL3BsYXRmb3Jtcy9wb3dlcm52
L29wYWwtc2Vuc29yLmMKPj4gQEAgLTcyLDYgKzcyLDkgQEAgc3RhdGljIF9faW5pdCBpbnQgb3Bh
bF9zZW5zb3JfaW5pdCh2b2lkKQo+PiAgCXN0cnVjdCBwbGF0Zm9ybV9kZXZpY2UgKnBkZXY7Cj4+
ICAJc3RydWN0IGRldmljZV9ub2RlICpzZW5zb3I7Cj4+ICAKPj4gKwlpZiAoIW9wYWxfY2hlY2tf
dG9rZW4oT1BBTF9TRU5TT1JfUkVBRCkpCj4+ICsJCXJldHVybiAtRU5PREVWOwo+PiArCj4+ICAJ
c2Vuc29yID0gb2ZfZmluZF9ub2RlX2J5X3BhdGgoIi9pYm0sb3BhbC9zZW5zb3JzIik7Cj4+ICAJ
aWYgKCFzZW5zb3IpIHsKPj4gIAkJcHJfZXJyKCJPcGFsIG5vZGUgJ3NlbnNvcnMnIG5vdCBmb3Vu
ZFxuIik7Cj4gCj4gQXJlIHlvdSBhY3R1YWxseSBzZWVpbmcgdGhpcyBpbiBwcmFjdGljZT8KCk5v
LiBOb3QgdGhpcyBvbmUuIEkgaGF2ZSBzZWVuIG90aGVycyB0aG91Z2guIEkgd2lsbCBzZW5kIHlv
dSBwYXRjaGVzLgoKPiBJdCdzIGEgYml0IGFubm95aW5nIHRoYXQgd2UgaGF2ZSB0byBjaGVjayBm
b3IgdGhlIHRva2VuLCBhbmQgdGhlbiBhbHNvIGNoZWNrCj4gdGhlIGRldmljZSB0cmVlLiBJdCB3
b3VsZCBiZSBuaWNlIGlmIG9uZSBpbXBsaWVkIHRoZSBwcmVzZW5jZSBvZiB0aGUgb3RoZXIuCgpT
aG91bGQgd2UgZXhwb3NlIHRoZSBPUEFMIGNhbGwgdG9rZW4gaW4gdGhlIGRldmljZSB0cmVlID8g
CgpDaGVlcnMsCgpDLiAKIAoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fCmxtLXNlbnNvcnMgbWFpbGluZyBsaXN0CmxtLXNlbnNvcnNAbG0tc2Vuc29ycy5v
cmcKaHR0cDovL2xpc3RzLmxtLXNlbnNvcnMub3JnL21haWxtYW4vbGlzdGluZm8vbG0tc2Vuc29y
cw=

Re: [RFC PATCH 1/3] powerpc/powernv: Check OPAL sensor calls exist

[Cedric Le Goater]

On 02/24/2015 05:54 AM, Michael Ellerman wrote:
> On Fri, 2015-02-20 at 16:07 +0100, Cédric Le Goater wrote:
>> Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>
>> ---
>>  arch/powerpc/platforms/powernv/opal-sensor.c |    3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/arch/powerpc/platforms/powernv/opal-sensor.c b/arch/powerpc/platforms/powernv/opal-sensor.c
>> index 4ab67ef7abc9..544292f2020f 100644
>> --- a/arch/powerpc/platforms/powernv/opal-sensor.c
>> +++ b/arch/powerpc/platforms/powernv/opal-sensor.c
>> @@ -72,6 +72,9 @@ static __init int opal_sensor_init(void)
>>  	struct platform_device *pdev;
>>  	struct device_node *sensor;
>>  
>> +	if (!opal_check_token(OPAL_SENSOR_READ))
>> +		return -ENODEV;
>> +
>>  	sensor = of_find_node_by_path("/ibm,opal/sensors");
>>  	if (!sensor) {
>>  		pr_err("Opal node 'sensors' not found\n");
> 
> Are you actually seeing this in practice?

No. Not this one. I have seen others though. I will send you patches.

> It's a bit annoying that we have to check for the token, and then also check
> the device tree. It would be nice if one implied the presence of the other.

Should we expose the OPAL call token in the device tree ? 

Cheers,

C. 
 

[lm-sensors] [RFC PATCH 2/3] powerpc/powernv: handle OPAL_SUCCESS return in opal_sensor_read

[Cédric Le Goater]

Q3VycmVudGx5LCB3aGVuIGEgc2Vuc29yIHZhbHVlIGlzIHJlYWQsIHRoZSBrZXJuZWwgY2FsbHMg
T1BBTCwgd2hpY2ggaW4KdHVybiBidWlsZHMgYSBtZXNzYWdlIGZvciB0aGUgRlNQLCBhbmQgd2Fp
dHMgZm9yIGEgbWVzc2FnZSBiYWNrLiBIb3dldmVyLApzb21lIHNlbnNvcnMgY2FuIGJlIHJlYWQg
c3luY2hyb25vdXNseSAoY29yZSB0ZW1wZXJhdHVyZXMgZm9yIGluc3RhbmNlKQphbmQgZG9uJ3Qg
bmVlZCB0byB3YWl0IGZvciBhIHJlc3BvbnNlLgoKVGhpcyBwYXRjaCBtb2RpZmllcyB0aGUgb3Bh
bCBjYWxsIHRvIGFjY2VwdCBhbiBPUEFMX1NVQ0NFU1MgcmV0dXJuIHZhbHVlCmFuZCBub3Qgd2Fp
dCBmb3IgYSByZXNwb25zZSBpZiB0aGlzIGlzIHRoZSBjYXNlLgoKQnV0LCB3ZSBzdGlsbCB1c2Vs
ZXNzbHkgcmVzZXJ2ZSBhIHRva2VuIChmb3IgdGhlIHJlc3BvbnNlKSBhbmQgdGFrZSBhCmxvY2ss
IHdoaWNoIG1pZ2h0IHJhaXNlIHRoZSBuZWVkIG9mIGEgbmV3ICdvcGFsX3NlbnNvcl9yZWFkX3N5
bmMnIGNhbGwuCgpTaWduZWQtb2ZmLWJ5OiBDw6lkcmljIExlIEdvYXRlciA8Y2xnQGZyLmlibS5j
b20+Ci0tLQogYXJjaC9wb3dlcnBjL3BsYXRmb3Jtcy9wb3dlcm52L29wYWwtc2Vuc29yLmMgfCAg
IDI5ICsrKysrKysrKysrKysrKysrLS0tLS0tLS0tCiAxIGZpbGUgY2hhbmdlZCwgMTkgaW5zZXJ0
aW9ucygrKSwgMTAgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvYXJjaC9wb3dlcnBjL3BsYXRm
b3Jtcy9wb3dlcm52L29wYWwtc2Vuc29yLmMgYi9hcmNoL3Bvd2VycGMvcGxhdGZvcm1zL3Bvd2Vy
bnYvb3BhbC1zZW5zb3IuYwppbmRleCA1NDQyOTJmMjAyMGYuLmE0ZWQ4M2E3ZGZiNCAxMDA2NDQK
LS0tIGEvYXJjaC9wb3dlcnBjL3BsYXRmb3Jtcy9wb3dlcm52L29wYWwtc2Vuc29yLmMKKysrIGIv
YXJjaC9wb3dlcnBjL3BsYXRmb3Jtcy9wb3dlcm52L29wYWwtc2Vuc29yLmMKQEAgLTQ2LDE4ICs0
NiwyNyBAQCBpbnQgb3BhbF9nZXRfc2Vuc29yX2RhdGEodTMyIHNlbnNvcl9obmRsLCB1MzIgKnNl
bnNvcl9kYXRhKQogCiAJbXV0ZXhfbG9jaygmb3BhbF9zZW5zb3JfbXV0ZXgpOwogCXJldCA9IG9w
YWxfc2Vuc29yX3JlYWQoc2Vuc29yX2huZGwsIHRva2VuLCAmZGF0YSk7Ci0JaWYgKHJldCAhPSBP
UEFMX0FTWU5DX0NPTVBMRVRJT04pCi0JCWdvdG8gb3V0X3Rva2VuOworCXN3aXRjaCAocmV0KSB7
CisJY2FzZSBPUEFMX0FTWU5DX0NPTVBMRVRJT046CisJCXJldCA9IG9wYWxfYXN5bmNfd2FpdF9y
ZXNwb25zZSh0b2tlbiwgJm1zZyk7CisJCWlmIChyZXQpIHsKKwkJCXByX2VycigiJXM6IEZhaWxl
ZCB0byB3YWl0IGZvciB0aGUgYXN5bmMgcmVzcG9uc2UsICVkXG4iLAorCQkJICAgICAgIF9fZnVu
Y19fLCByZXQpOworCQkJZ290byBvdXRfdG9rZW47CisJCX0KIAotCXJldCA9IG9wYWxfYXN5bmNf
d2FpdF9yZXNwb25zZSh0b2tlbiwgJm1zZyk7Ci0JaWYgKHJldCkgewotCQlwcl9lcnIoIiVzOiBG
YWlsZWQgdG8gd2FpdCBmb3IgdGhlIGFzeW5jIHJlc3BvbnNlLCAlZFxuIiwKLQkJCQlfX2Z1bmNf
XywgcmV0KTsKLQkJZ290byBvdXRfdG9rZW47Ci0JfQorCQlyZXQgPSBiZTY0X3RvX2NwdShtc2cu
cGFyYW1zWzFdKTsKKworCQkqc2Vuc29yX2RhdGEgPSBiZTMyX3RvX2NwdShkYXRhKTsKKwkJYnJl
YWs7CiAKLQkqc2Vuc29yX2RhdGEgPSBiZTMyX3RvX2NwdShkYXRhKTsKLQlyZXQgPSBiZTY0X3Rv
X2NwdShtc2cucGFyYW1zWzFdKTsKKwljYXNlIE9QQUxfU1VDQ0VTUzoKKwkJKnNlbnNvcl9kYXRh
ID0gYmUzMl90b19jcHUoZGF0YSk7CisJCWJyZWFrOworCisJZGVmYXVsdDoKKwkJYnJlYWs7CisJ
fQogCiBvdXRfdG9rZW46CiAJbXV0ZXhfdW5sb2NrKCZvcGFsX3NlbnNvcl9tdXRleCk7Ci0tIAox
LjcuMTAuNAoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
CmxtLXNlbnNvcnMgbWFpbGluZyBsaXN0CmxtLXNlbnNvcnNAbG0tc2Vuc29ycy5vcmcKaHR0cDov
L2xpc3RzLmxtLXNlbnNvcnMub3JnL21haWxtYW4vbGlzdGluZm8vbG0tc2Vuc29ycw=

[RFC PATCH 2/3] powerpc/powernv: handle OPAL_SUCCESS return in opal_sensor_read

[Cédric Le Goater]

Currently, when a sensor value is read, the kernel calls OPAL, which in
turn builds a message for the FSP, and waits for a message back. However,
some sensors can be read synchronously (core temperatures for instance)
and don't need to wait for a response.

This patch modifies the opal call to accept an OPAL_SUCCESS return value
and not wait for a response if this is the case.

But, we still uselessly reserve a token (for the response) and take a
lock, which might raise the need of a new 'opal_sensor_read_sync' call.

Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>
---
 arch/powerpc/platforms/powernv/opal-sensor.c |   29 +++++++++++++++++---------
 1 file changed, 19 insertions(+), 10 deletions(-)

diff --git a/arch/powerpc/platforms/powernv/opal-sensor.c b/arch/powerpc/platforms/powernv/opal-sensor.c
index 544292f2020f..a4ed83a7dfb4 100644
--- a/arch/powerpc/platforms/powernv/opal-sensor.c
+++ b/arch/powerpc/platforms/powernv/opal-sensor.c
@@ -46,18 +46,27 @@ int opal_get_sensor_data(u32 sensor_hndl, u32 *sensor_data)
 
 	mutex_lock(&opal_sensor_mutex);
 	ret = opal_sensor_read(sensor_hndl, token, &data);
-	if (ret != OPAL_ASYNC_COMPLETION)
-		goto out_token;
+	switch (ret) {
+	case OPAL_ASYNC_COMPLETION:
+		ret = opal_async_wait_response(token, &msg);
+		if (ret) {
+			pr_err("%s: Failed to wait for the async response, %d\n",
+			       __func__, ret);
+			goto out_token;
+		}
 
-	ret = opal_async_wait_response(token, &msg);
-	if (ret) {
-		pr_err("%s: Failed to wait for the async response, %d\n",
-				__func__, ret);
-		goto out_token;
-	}
+		ret = be64_to_cpu(msg.params[1]);
+
+		*sensor_data = be32_to_cpu(data);
+		break;
 
-	*sensor_data = be32_to_cpu(data);
-	ret = be64_to_cpu(msg.params[1]);
+	case OPAL_SUCCESS:
+		*sensor_data = be32_to_cpu(data);
+		break;
+
+	default:
+		break;
+	}
 
 out_token:
 	mutex_unlock(&opal_sensor_mutex);
-- 
1.7.10.4

[lm-sensors] [RFC PATCH 3/3] hwmon: (ibmpowernv) add DTS support

[Cédric Le Goater]

VGhpcyBwYXRjaCByZXdvcmtzIHRoZSBpYm1wb3dlcm52IGRyaXZlciB0byBzdXBwb3J0IHRoZSBu
ZXcgZGV2aWNlIHRyZWUKZm9yIHNlbnNvcnMgZXhwb3NlZCBieSBPUEFMLiBJdCBhbHNvIGFkZHMg
bmV3IHNlbnNvcnMgOiB0aGUgY29yZSBhbmQKbWVtb3J5IGJ1ZmZlcnMgRFRTLgoKSG9wZWZ1bGx5
LCB0aGUgcHJvcG9zZWQgZnJhbWV3b3JrIGlzIGdvb2QgZW5vdWdoIHRvIGVhc2lseSBhZGQgc2Vu
c29ycwpmb3Igb3RoZXIgcmVzb3VyY2VzIHN1Y2ggYXMgdm9sdHMsIHBsYW5hciB0ZW1wZXJhdHVy
ZXMsIGV0Yy4KClNpZ25lZC1vZmYtYnk6IEPDqWRyaWMgTGUgR29hdGVyIDxjbGdAZnIuaWJtLmNv
bT4KLS0tCiBkcml2ZXJzL2h3bW9uL2libXBvd2VybnYuYyB8ICAzMzYgKysrKysrKysrKysrKysr
KysrKysrKysrLS0tLS0tLS0tLS0tLS0tLS0tLS0KIDEgZmlsZSBjaGFuZ2VkLCAxODAgaW5zZXJ0
aW9ucygrKSwgMTU2IGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL2RyaXZlcnMvaHdtb24vaWJt
cG93ZXJudi5jIGIvZHJpdmVycy9od21vbi9pYm1wb3dlcm52LmMKaW5kZXggZmViZTgxNzVkMzZj
Li45YTZlZTMzZjgyMTkgMTAwNjQ0Ci0tLSBhL2RyaXZlcnMvaHdtb24vaWJtcG93ZXJudi5jCisr
KyBiL2RyaXZlcnMvaHdtb24vaWJtcG93ZXJudi5jCkBAIC0zMiwyNDcgKzMyLDI3NiBAQAogI2lu
Y2x1ZGUgPGxpbnV4L2Vyci5oPgogCiAjZGVmaW5lIE1BWF9BVFRSX0xFTgkzMgotCi0vKiBTZW5z
b3Igc3VmZml4IG5hbWUgZnJvbSBEVCAqLwotI2RlZmluZSBEVF9GQVVMVF9BVFRSX1NVRkZJWAkJ
ImZhdWx0ZWQiCi0jZGVmaW5lIERUX0RBVEFfQVRUUl9TVUZGSVgJCSJkYXRhIgotI2RlZmluZSBE
VF9USFJFU0hPTERfQVRUUl9TVUZGSVgJInRocnMiCisjZGVmaW5lIE1BWF9MQUJFTF9MRU4JNjQK
KyNkZWZpbmUgTUFYX0FUVFJTCTMJLyogc2Vuc29yLWRhdGEsIHNlbnNvci1zdGF0dXMsIGxhYmVs
ICovCiAKIC8qCiAgKiBFbnVtZXJhdGVzIGFsbCB0aGUgdHlwZXMgb2Ygc2Vuc29ycyBpbiB0aGUg
UE9XRVJOViBwbGF0Zm9ybSBhbmQgZG9lcyBpbmRleAotICogaW50byAnc3RydWN0IHNlbnNvcl9n
cm91cCcKKyAqIGludG8gJ3N0cnVjdCBzZW5zb3JfdHlwZScKICAqLwogZW51bSBzZW5zb3JzIHsK
IAlGQU4sCi0JQU1CSUVOVF9URU1QLAorCVRFTVAsCiAJUE9XRVJfU1VQUExZLAogCVBPV0VSX0lO
UFVULAogCU1BWF9TRU5TT1JfVFlQRSwKIH07CiAKLXN0YXRpYyBzdHJ1Y3Qgc2Vuc29yX2dyb3Vw
IHsKK3N0YXRpYyBzdHJ1Y3Qgc2Vuc29yX3R5cGUgeworCWVudW0gc2Vuc29ycyB0eXBlOwogCWNv
bnN0IGNoYXIgKm5hbWU7Ci0JY29uc3QgY2hhciAqY29tcGF0aWJsZTsKLQlzdHJ1Y3QgYXR0cmli
dXRlX2dyb3VwIGdyb3VwOwotCXUzMiBhdHRyX2NvdW50OwotfSBzZW5zb3JfZ3JvdXBzW10gPSB7
Ci0JeyJmYW4iLCAiaWJtLG9wYWwtc2Vuc29yLWNvb2xpbmctZmFuIn0sCi0JeyJ0ZW1wIiwgImli
bSxvcGFsLXNlbnNvci1hbWItdGVtcCJ9LAotCXsiaW4iLCAiaWJtLG9wYWwtc2Vuc29yLXBvd2Vy
LXN1cHBseSJ9LAotCXsicG93ZXIiLCAiaWJtLG9wYWwtc2Vuc29yLXBvd2VyIn0KKwl1MzIgY291
bnQ7Cit9IHNlbnNvcl90eXBlc1tdID0geworCXsgRkFOLAkJCSJmYW4iCX0sCisJeyBURU1QLAkJ
CSJ0ZW1wIgl9LAorCXsgUE9XRVJfU1VQUExZLAkJInBvd2VyIgl9LAorCXsgUE9XRVJfSU5QVVQs
CQkiaW4iCX0sCisJeyBNQVhfU0VOU09SX1RZUEUsCU5VTEwJfQogfTsKIAogc3RydWN0IHNlbnNv
cl9kYXRhIHsKLQl1MzIgaWQ7IC8qIEFuIG9wYXF1ZSBpZCBvZiB0aGUgZmlybXdhcmUgZm9yIGVh
Y2ggc2Vuc29yICovCisJdTMyIGRhdGE7CisJdTMyIHN0YXR1czsKKwljaGFyIGxhYmVsW01BWF9M
QUJFTF9MRU5dOwogCWVudW0gc2Vuc29ycyB0eXBlOwotCWNoYXIgbmFtZVtNQVhfQVRUUl9MRU5d
OwotCXN0cnVjdCBkZXZpY2VfYXR0cmlidXRlIGRldl9hdHRyOworCWNoYXIgYXR0cl9uYW1lW01B
WF9BVFRSU11bTUFYX0FUVFJfTEVOXTsKKwlzdHJ1Y3Qgc2Vuc29yX2RldmljZV9hdHRyaWJ1dGUg
c2RfYXR0cnNbTUFYX0FUVFJTXTsKIH07CiAKIHN0cnVjdCBwbGF0Zm9ybV9kYXRhIHsKLQljb25z
dCBzdHJ1Y3QgYXR0cmlidXRlX2dyb3VwICphdHRyX2dyb3Vwc1tNQVhfU0VOU09SX1RZUEUgKyAx
XTsKKwlzdHJ1Y3QgYXR0cmlidXRlX2dyb3VwIGF0dHJfZ3JvdXA7CisJY29uc3Qgc3RydWN0IGF0
dHJpYnV0ZV9ncm91cCAqZ3JvdXBzWzJdOwogCXUzMiBzZW5zb3JzX2NvdW50OyAvKiBUb3RhbCBj
b3VudCBvZiBzZW5zb3JzIGZyb20gZWFjaCBncm91cCAqLworCXN0cnVjdCBhdHRyaWJ1dGUgKiph
dHRyczsKKwlzdHJ1Y3Qgc2Vuc29yX2RhdGEgKipzZW5zb3JzOwogfTsKIAogc3RhdGljIHNzaXpl
X3Qgc2hvd19zZW5zb3Ioc3RydWN0IGRldmljZSAqZGV2LCBzdHJ1Y3QgZGV2aWNlX2F0dHJpYnV0
ZSAqZGV2YXR0ciwKIAkJCSAgIGNoYXIgKmJ1ZikKIHsKLQlzdHJ1Y3Qgc2Vuc29yX2RhdGEgKnNk
YXRhID0gY29udGFpbmVyX29mKGRldmF0dHIsIHN0cnVjdCBzZW5zb3JfZGF0YSwKLQkJCQkJCSBk
ZXZfYXR0cik7CisJc3RydWN0IHNlbnNvcl9kZXZpY2VfYXR0cmlidXRlICphdHRyID0gdG9fc2Vu
c29yX2Rldl9hdHRyKGRldmF0dHIpOworCXN0cnVjdCBwbGF0Zm9ybV9kYXRhICpwZGF0YSA9IGRl
dl9nZXRfZHJ2ZGF0YShkZXYpOworCXN0cnVjdCBzZW5zb3JfZGF0YSAqc2RhdGEgPSBwZGF0YS0+
c2Vuc29yc1thdHRyLT5pbmRleF07CiAJc3NpemVfdCByZXQ7CiAJdTMyIHg7CiAKLQlyZXQgPSBv
cGFsX2dldF9zZW5zb3JfZGF0YShzZGF0YS0+aWQsICZ4KTsKKwlyZXQgPSBvcGFsX2dldF9zZW5z
b3JfZGF0YShzZGF0YS0+ZGF0YSwgJngpOwogCWlmIChyZXQpCiAJCXJldHVybiByZXQ7CiAKIAkv
KiBDb252ZXJ0IHRlbXBlcmF0dXJlIHRvIG1pbGxpLWRlZ3JlZXMgKi8KLQlpZiAoc2RhdGEtPnR5
cGUgPT0gQU1CSUVOVF9URU1QKQorCWlmIChzZGF0YS0+dHlwZSA9PSBURU1QKQogCQl4ICo9IDEw
MDA7CiAJLyogQ29udmVydCBwb3dlciB0byBtaWNyby13YXR0cyAqLwotCWVsc2UgaWYgKHNkYXRh
LT50eXBlID09IFBPV0VSX0lOUFVUKQorCWVsc2UgaWYgKHNkYXRhLT50eXBlID09IFBPV0VSX1NV
UFBMWSkKIAkJeCAqPSAxMDAwMDAwOwogCiAJcmV0dXJuIHNwcmludGYoYnVmLCAiJXVcbiIsIHgp
OwogfQogCi1zdGF0aWMgaW50IGdldF9zZW5zb3JfaW5kZXhfYXR0cihjb25zdCBjaGFyICpuYW1l
LCB1MzIgKmluZGV4LAotCQkJCQljaGFyICphdHRyKQorc3RhdGljIHNzaXplX3Qgc2hvd19hbGFy
bShzdHJ1Y3QgZGV2aWNlICpkZXYsIHN0cnVjdCBkZXZpY2VfYXR0cmlidXRlICpkZXZhdHRyLAor
CQkJICAgY2hhciAqYnVmKQogewotCWNoYXIgKmhhc2hfcG9zID0gc3RyY2hyKG5hbWUsICcjJyk7
Ci0JY2hhciBidWZbOF0gPSB7IDAgfTsKLQljaGFyICpkYXNoX3BvczsKLQl1MzIgY29weV9sZW47
Ci0JaW50IGVycjsKLQotCWlmICghaGFzaF9wb3MpCi0JCXJldHVybiAtRUlOVkFMOwotCi0JZGFz
aF9wb3MgPSBzdHJjaHIoaGFzaF9wb3MsICctJyk7Ci0JaWYgKCFkYXNoX3BvcykKLQkJcmV0dXJu
IC1FSU5WQUw7Ci0KLQljb3B5X2xlbiA9IGRhc2hfcG9zIC0gaGFzaF9wb3MgLSAxOwotCWlmIChj
b3B5X2xlbiA+PSBzaXplb2YoYnVmKSkKLQkJcmV0dXJuIC1FSU5WQUw7CisJc3RydWN0IHNlbnNv
cl9kZXZpY2VfYXR0cmlidXRlICphdHRyID0gdG9fc2Vuc29yX2Rldl9hdHRyKGRldmF0dHIpOwor
CXN0cnVjdCBwbGF0Zm9ybV9kYXRhICpwZGF0YSA9IGRldl9nZXRfZHJ2ZGF0YShkZXYpOworCXN0
cnVjdCBzZW5zb3JfZGF0YSAqc2RhdGEgPSBwZGF0YS0+c2Vuc29yc1thdHRyLT5pbmRleF07CisJ
c3NpemVfdCByZXQ7CisJdTMyIHg7CiAKLQlzdHJuY3B5KGJ1ZiwgaGFzaF9wb3MgKyAxLCBjb3B5
X2xlbik7CisJcmV0ID0gb3BhbF9nZXRfc2Vuc29yX2RhdGEoc2RhdGEtPnN0YXR1cywgJngpOwor
CWlmIChyZXQpCisJCXJldHVybiByZXQ7CiAKLQllcnIgPSBrc3RydG91MzIoYnVmLCAxMCwgaW5k
ZXgpOwotCWlmIChlcnIpCi0JCXJldHVybiBlcnI7CisJLyoKKwkgKiBEZXBlbmRpbmcgb24gdGhl
IHNlbnNvciB0eXBlLCB0aGUgc3RhdHVzIGJpdHMgY2FuIGhhdmUKKwkgKiBkaWZmZXJlbnQgbWVh
bmluZ3MuIExldCdzIG5vdCBiZSB0b28gc3VidGlsIGZvciB0aGUgbW9tZW50LAorCSAqIHRlc3Rp
bmcgYWdhaW5zdCAweDYgc2hvdWxkIHJhaXNlIGFuIGFsYXJtLgorCSAqLworCXJldHVybiBzcHJp
bnRmKGJ1ZiwgIiV1XG4iLCB4ICYgMHg2KTsKK30KIAotCXN0cm5jcHkoYXR0ciwgZGFzaF9wb3Mg
KyAxLCBNQVhfQVRUUl9MRU4pOworc3RhdGljIHNzaXplX3Qgc2hvd19sYWJlbChzdHJ1Y3QgZGV2
aWNlICpkZXYsIHN0cnVjdCBkZXZpY2VfYXR0cmlidXRlICpkZXZhdHRyLAorCQkJICAgY2hhciAq
YnVmKQoreworCXN0cnVjdCBzZW5zb3JfZGV2aWNlX2F0dHJpYnV0ZSAqYXR0ciA9IHRvX3NlbnNv
cl9kZXZfYXR0cihkZXZhdHRyKTsKKwlzdHJ1Y3QgcGxhdGZvcm1fZGF0YSAqcGRhdGEgPSBkZXZf
Z2V0X2RydmRhdGEoZGV2KTsKKwlzdHJ1Y3Qgc2Vuc29yX2RhdGEgKnNkYXRhID0gcGRhdGEtPnNl
bnNvcnNbYXR0ci0+aW5kZXhdOwogCi0JcmV0dXJuIDA7CisJcmV0dXJuIHNwcmludGYoYnVmLCAi
JXNcbiIsIHNkYXRhLT5sYWJlbCk7CiB9CiAKLS8qCi0gKiBUaGlzIGZ1bmN0aW9uIHRyYW5zbGF0
ZXMgdGhlIERUIG5vZGUgbmFtZSBpbnRvIHRoZSAnaHdtb24nIGF0dHJpYnV0ZSBuYW1lLgotICog
SUJNUE9XRVJOViBkZXZpY2Ugbm9kZSBhcHBlYXIgbGlrZSBjb29saW5nLWZhbiMyLWRhdGEsIGFt
Yi10ZW1wIzEtdGhycyBldGMuCi0gKiB3aGljaCBuZWVkIHRvIGJlIG1hcHBlZCBhcyBmYW4yX2lu
cHV0LCB0ZW1wMV9tYXggcmVzcGVjdGl2ZWx5IGJlZm9yZQotICogcG9wdWxhdGluZyB0aGVtIGlu
c2lkZSBod21vbiBkZXZpY2UgY2xhc3MuCi0gKi8KLXN0YXRpYyBpbnQgY3JlYXRlX2h3bW9uX2F0
dHJfbmFtZShzdHJ1Y3QgZGV2aWNlICpkZXYsIGVudW0gc2Vuc29ycyB0eXBlLAotCQkJCQkgY29u
c3QgY2hhciAqbm9kZV9uYW1lLAotCQkJCQkgY2hhciAqaHdtb25fYXR0cl9uYW1lKQorc3RhdGlj
IHN0cnVjdCBzZW5zb3JfdHlwZSAqX19pbml0IGdldF9zZW5zb3JfdHlwZShzdHJ1Y3QgcGxhdGZv
cm1fZGV2aWNlICpwZGV2LAorCXN0cnVjdCBkZXZpY2Vfbm9kZSAqbnApCiB7Ci0JY2hhciBhdHRy
X3N1ZmZpeFtNQVhfQVRUUl9MRU5dOwotCWNoYXIgKmF0dHJfbmFtZTsKLQl1MzIgaW5kZXg7Ci0J
aW50IGVycjsKKwljb25zdCBjaGFyICp0eXBlOworCWludCBpOwogCi0JZXJyID0gZ2V0X3NlbnNv
cl9pbmRleF9hdHRyKG5vZGVfbmFtZSwgJmluZGV4LCBhdHRyX3N1ZmZpeCk7Ci0JaWYgKGVycikg
ewotCQlkZXZfZXJyKGRldiwgIlNlbnNvciBkZXZpY2Ugbm9kZSBuYW1lICclcycgaXMgaW52YWxp
ZFxuIiwKLQkJCW5vZGVfbmFtZSk7Ci0JCXJldHVybiBlcnI7Ci0JfQorCWlmIChucC0+bmFtZSA9
PSBOVUxMKQorCQlyZXR1cm4gTlVMTDsKKworCWlmICghb2ZfZGV2aWNlX2lzX2NvbXBhdGlibGUo
bnAsICJpYm0sb3BhbC1zZW5zb3IiKSkKKwkJcmV0dXJuIE5VTEw7CiAKLQlpZiAoIXN0cmNtcChh
dHRyX3N1ZmZpeCwgRFRfRkFVTFRfQVRUUl9TVUZGSVgpKSB7Ci0JCWF0dHJfbmFtZSA9ICJmYXVs
dCI7Ci0JfSBlbHNlIGlmICghc3RyY21wKGF0dHJfc3VmZml4LCBEVF9EQVRBX0FUVFJfU1VGRklY
KSkgewotCQlhdHRyX25hbWUgPSAiaW5wdXQiOwotCX0gZWxzZSBpZiAoIXN0cmNtcChhdHRyX3N1
ZmZpeCwgRFRfVEhSRVNIT0xEX0FUVFJfU1VGRklYKSkgewotCQlpZiAodHlwZSA9PSBBTUJJRU5U
X1RFTVApCi0JCQlhdHRyX25hbWUgPSAibWF4IjsKLQkJZWxzZSBpZiAodHlwZSA9PSBGQU4pCi0J
CQlhdHRyX25hbWUgPSAibWluIjsKLQkJZWxzZQotCQkJcmV0dXJuIC1FTk9FTlQ7Ci0JfSBlbHNl
IHsKLQkJcmV0dXJuIC1FTk9FTlQ7CisJaWYgKG9mX3Byb3BlcnR5X3JlYWRfc3RyaW5nKG5wLCAi
c2Vuc29yLXR5cGUiLCAmdHlwZSkpIHsKKwkJZGV2X2luZm8oJnBkZXYtPmRldiwKKwkJCSAiJ3Nl
bnNvci10eXBlJyBtaXNzaW5nIGluIHRoZSBub2RlICclcydcbiIsCisJCQkgbnAtPm5hbWUpOwor
CQlyZXR1cm4gTlVMTDsKIAl9CiAKLQlzbnByaW50Zihod21vbl9hdHRyX25hbWUsIE1BWF9BVFRS
X0xFTiwgIiVzJWRfJXMiLAotCQkgc2Vuc29yX2dyb3Vwc1t0eXBlXS5uYW1lLCBpbmRleCwgYXR0
cl9uYW1lKTsKLQlyZXR1cm4gMDsKKwlmb3IgKGkgPSAwIDsgaSA8IE1BWF9TRU5TT1JfVFlQRTsg
aSsrKQorCQlpZiAoIXN0cmNtcCh0eXBlLCBzZW5zb3JfdHlwZXNbaV0ubmFtZSkpCisJCQlyZXR1
cm4gJnNlbnNvcl90eXBlc1tpXTsKKworCXJldHVybiBOVUxMOwogfQogCi1zdGF0aWMgaW50IHBv
cHVsYXRlX2F0dHJfZ3JvdXBzKHN0cnVjdCBwbGF0Zm9ybV9kZXZpY2UgKnBkZXYpCitzdGF0aWMg
dm9pZCBfX2luaXQgbWFrZV9zZW5zb3JfbGFiZWwoc3RydWN0IGRldmljZV9ub2RlICpucCwKKwkJ
ICAgIHN0cnVjdCBzZW5zb3JfZGF0YSAqc2RhdGEsIGNvbnN0IGNoYXIgKmxhYmVsKQogewotCXN0
cnVjdCBwbGF0Zm9ybV9kYXRhICpwZGF0YSA9IHBsYXRmb3JtX2dldF9kcnZkYXRhKHBkZXYpOwot
CWNvbnN0IHN0cnVjdCBhdHRyaWJ1dGVfZ3JvdXAgKipwZ3JvdXBzID0gcGRhdGEtPmF0dHJfZ3Jv
dXBzOwotCXN0cnVjdCBkZXZpY2Vfbm9kZSAqb3BhbCwgKm5wOwotCWVudW0gc2Vuc29ycyB0eXBl
OworCXUzMiBpZDsKKwlzaXplX3QgbjsKIAotCW9wYWwgPSBvZl9maW5kX25vZGVfYnlfcGF0aCgi
L2libSxvcGFsL3NlbnNvcnMiKTsKLQlmb3JfZWFjaF9jaGlsZF9vZl9ub2RlKG9wYWwsIG5wKSB7
Ci0JCWlmIChucC0+bmFtZSA9PSBOVUxMKQotCQkJY29udGludWU7CisJbiA9IHNucHJpbnRmKHNk
YXRhLT5sYWJlbCwgc2l6ZW9mKHNkYXRhLT5sYWJlbCksICIlcyIsIGxhYmVsKTsKIAotCQlmb3Ig
KHR5cGUgPSAwOyB0eXBlIDwgTUFYX1NFTlNPUl9UWVBFOyB0eXBlKyspCi0JCQlpZiAob2ZfZGV2
aWNlX2lzX2NvbXBhdGlibGUobnAsCi0JCQkJCXNlbnNvcl9ncm91cHNbdHlwZV0uY29tcGF0aWJs
ZSkpIHsKLQkJCQlzZW5zb3JfZ3JvdXBzW3R5cGVdLmF0dHJfY291bnQrKzsKLQkJCQlicmVhazsK
LQkJCX0KLQl9CisJLyoKKwkgKiBDb3JlIHRlbXAgcHJldHR5IHByZXR0eQorCSAqLworCWlmICgh
b2ZfcHJvcGVydHlfcmVhZF91MzIobnAsICJpYm0scGlyIiwgJmlkKSkgeworCQlpbnQgaTsKIAot
CW9mX25vZGVfcHV0KG9wYWwpOworCQlmb3JfZWFjaF9wb3NzaWJsZV9jcHUoaSkKKwkJCWlmIChw
YWNhW2ldLmh3X2NwdV9pZCA9PSBpZCkKKwkJCQlicmVhazsKIAotCWZvciAodHlwZSA9IDA7IHR5
cGUgPCBNQVhfU0VOU09SX1RZUEU7IHR5cGUrKykgewotCQlzZW5zb3JfZ3JvdXBzW3R5cGVdLmdy
b3VwLmF0dHJzID0gZGV2bV9remFsbG9jKCZwZGV2LT5kZXYsCi0JCQkJCXNpemVvZihzdHJ1Y3Qg
YXR0cmlidXRlICopICoKLQkJCQkJKHNlbnNvcl9ncm91cHNbdHlwZV0uYXR0cl9jb3VudCArIDEp
LAotCQkJCQlHRlBfS0VSTkVMKTsKLQkJaWYgKCFzZW5zb3JfZ3JvdXBzW3R5cGVdLmdyb3VwLmF0
dHJzKQotCQkJcmV0dXJuIC1FTk9NRU07Ci0KLQkJcGdyb3Vwc1t0eXBlXSA9ICZzZW5zb3JfZ3Jv
dXBzW3R5cGVdLmdyb3VwOwotCQlwZGF0YS0+c2Vuc29yc19jb3VudCArPSBzZW5zb3JfZ3JvdXBz
W3R5cGVdLmF0dHJfY291bnQ7Ci0JCXNlbnNvcl9ncm91cHNbdHlwZV0uYXR0cl9jb3VudCA9IDA7
CisJCW4gKz0gc25wcmludGYoc2RhdGEtPmxhYmVsICsgbiwgc2l6ZW9mKHNkYXRhLT5sYWJlbCkg
LSBuLAorCQkJICAgICAgIiAlZC0lZCIsIGksIGkrNyk7CiAJfQogCi0JcmV0dXJuIDA7CisJLyoK
KwkgKiBNZW1idWZmZXIgcHJldHR5IHByaW50CisJICovCisJaWYgKCFvZl9wcm9wZXJ0eV9yZWFk
X3UzMihucCwgImlibSxjaGlwLWlkIiwgJmlkKSkKKwkJbiArPSBzbnByaW50ZihzZGF0YS0+bGFi
ZWwgKyBuLCBzaXplb2Yoc2RhdGEtPmxhYmVsKSAtIG4sCisJCQkgICAgICAiICVkIiwgaWQgJiAw
eGZmZmYpOwogfQogCi0vKgotICogSXRlcmF0ZSB0aHJvdWdoIHRoZSBkZXZpY2UgdHJlZSBmb3Ig
ZWFjaCBjaGlsZCBvZiAnc2Vuc29ycycgbm9kZSwgY3JlYXRlCi0gKiBhIHN5c2ZzIGF0dHJpYnV0
ZSBmaWxlLCB0aGUgZmlsZSBpcyBuYW1lZCBieSB0cmFuc2xhdGluZyB0aGUgRFQgbm9kZSBuYW1l
Ci0gKiB0byB0aGUgbmFtZSByZXF1aXJlZCBieSB0aGUgaGlnaGVyICdod21vbicgZHJpdmVyIGxp
a2UgZmFuMV9pbnB1dCwgdGVtcDFfbWF4Ci0gKiBldGMuLgotICovCi1zdGF0aWMgaW50IGNyZWF0
ZV9kZXZpY2VfYXR0cnMoc3RydWN0IHBsYXRmb3JtX2RldmljZSAqcGRldikKK3N0YXRpYyBpbnQg
X19pbml0IHBvcHVsYXRlX2F0dHJfZ3JvdXBzKHN0cnVjdCBwbGF0Zm9ybV9kZXZpY2UgKnBkZXYp
CiB7CiAJc3RydWN0IHBsYXRmb3JtX2RhdGEgKnBkYXRhID0gcGxhdGZvcm1fZ2V0X2RydmRhdGEo
cGRldik7Ci0JY29uc3Qgc3RydWN0IGF0dHJpYnV0ZV9ncm91cCAqKnBncm91cHMgPSBwZGF0YS0+
YXR0cl9ncm91cHM7CiAJc3RydWN0IGRldmljZV9ub2RlICpvcGFsLCAqbnA7Ci0Jc3RydWN0IHNl
bnNvcl9kYXRhICpzZGF0YTsKLQl1MzIgc2Vuc29yX2lkOwotCWVudW0gc2Vuc29ycyB0eXBlOwot
CXUzMiBjb3VudCA9IDA7CiAJaW50IGVyciA9IDA7CisJaW50IGkgPSAwOwogCiAJb3BhbCA9IG9m
X2ZpbmRfbm9kZV9ieV9wYXRoKCIvaWJtLG9wYWwvc2Vuc29ycyIpOwotCXNkYXRhID0gZGV2bV9r
emFsbG9jKCZwZGV2LT5kZXYsIHBkYXRhLT5zZW5zb3JzX2NvdW50ICogc2l6ZW9mKCpzZGF0YSks
Ci0JCQkgICAgIEdGUF9LRVJORUwpOwotCWlmICghc2RhdGEpIHsKKwlpZiAoIW9wYWwpIHsKKwkJ
ZGV2X2RiZygmcGRldi0+ZGV2LCAiT3BhbCBub2RlICdzZW5zb3JzJyBub3QgZm91bmRcbiIpOwor
CQlyZXR1cm4gLUVOT0RFVjsKKwl9CisKKwlmb3JfZWFjaF9jaGlsZF9vZl9ub2RlKG9wYWwsIG5w
KSB7CisJCWlmIChvZl9kZXZpY2VfaXNfY29tcGF0aWJsZShucCwgImlibSxvcGFsLXNlbnNvciIp
KQorCQkJcGRhdGEtPnNlbnNvcnNfY291bnQrKzsKKwl9CisKKwlwZGF0YS0+YXR0cnMgPSBkZXZt
X2t6YWxsb2MoJnBkZXYtPmRldiwKKwkgICAgc2l6ZW9mKCpwZGF0YS0+YXR0cnMpICogcGRhdGEt
PnNlbnNvcnNfY291bnQgKiBNQVhfQVRUUlMgKyAxLAorCSAgICBHRlBfS0VSTkVMKTsKKwlpZiAo
IXBkYXRhLT5hdHRycykgeworCQllcnIgPSAtRU5PTUVNOworCQlnb3RvIGV4aXRfcHV0X25vZGU7
CisJfQorCXBkYXRhLT5zZW5zb3JzID0gZGV2bV9remFsbG9jKCZwZGV2LT5kZXYsCisJICAgIHNp
emVvZigqcGRhdGEtPnNlbnNvcnMpICogcGRhdGEtPnNlbnNvcnNfY291bnQgKiBNQVhfQVRUUlMg
KyAxLAorCSAgICBHRlBfS0VSTkVMKTsKKwlpZiAoIXBkYXRhLT5zZW5zb3JzKSB7CiAJCWVyciA9
IC1FTk9NRU07CiAJCWdvdG8gZXhpdF9wdXRfbm9kZTsKIAl9CiAKLQlmb3JfZWFjaF9jaGlsZF9v
Zl9ub2RlKG9wYWwsIG5wKSB7Ci0JCWlmIChucC0+bmFtZSA9PSBOVUxMKQotCQkJY29udGludWU7
CiAKLQkJZm9yICh0eXBlID0gMDsgdHlwZSA8IE1BWF9TRU5TT1JfVFlQRTsgdHlwZSsrKQotCQkJ
aWYgKG9mX2RldmljZV9pc19jb21wYXRpYmxlKG5wLAotCQkJCQlzZW5zb3JfZ3JvdXBzW3R5cGVd
LmNvbXBhdGlibGUpKQotCQkJCWJyZWFrOworCWZvcl9lYWNoX2NoaWxkX29mX25vZGUob3BhbCwg
bnApIHsKKwkJc3RydWN0IHNlbnNvcl9kYXRhICpzZGF0YTsKKwkJc3RydWN0IHNlbnNvcl90eXBl
ICpzdHlwZTsKKwkJdTMyIHNlbnNvcl9kYXRhOworCQljb25zdCBjaGFyICpsYWJlbDsKIAotCQlp
ZiAodHlwZSA9PSBNQVhfU0VOU09SX1RZUEUpCisJCXN0eXBlID0gZ2V0X3NlbnNvcl90eXBlKHBk
ZXYsIG5wKTsKKwkJaWYgKCFzdHlwZSkKIAkJCWNvbnRpbnVlOwogCi0JCWlmIChvZl9wcm9wZXJ0
eV9yZWFkX3UzMihucCwgInNlbnNvci1pZCIsICZzZW5zb3JfaWQpKSB7CisJCWlmIChvZl9wcm9w
ZXJ0eV9yZWFkX3UzMihucCwgInNlbnNvci1kYXRhIiwgJnNlbnNvcl9kYXRhKSkgewogCQkJZGV2
X2luZm8oJnBkZXYtPmRldiwKLQkJCQkgIidzZW5zb3ItaWQnIG1pc3NpbmcgaW4gdGhlIG5vZGUg
JyVzJ1xuIiwKKwkJCQkgIidzZW5zb3ItZGF0YScgbWlzc2luZyBpbiB0aGUgbm9kZSAnJXMnXG4i
LAogCQkJCSBucC0+bmFtZSk7CiAJCQljb250aW51ZTsKIAkJfQogCi0JCXNkYXRhW2NvdW50XS5p
ZCA9IHNlbnNvcl9pZDsKLQkJc2RhdGFbY291bnRdLnR5cGUgPSB0eXBlOwotCQllcnIgPSBjcmVh
dGVfaHdtb25fYXR0cl9uYW1lKCZwZGV2LT5kZXYsIHR5cGUsIG5wLT5uYW1lLAotCQkJCQkgICAg
IHNkYXRhW2NvdW50XS5uYW1lKTsKLQkJaWYgKGVycikKKwkJc2RhdGEgPSBkZXZtX2t6YWxsb2Mo
JnBkZXYtPmRldiwgc2l6ZW9mKCpzZGF0YSksIEdGUF9LRVJORUwpOworCQlpZiAoc2RhdGEgPT0g
TlVMTCkgeworCQkJZXJyID0gLUVOT01FTTsKIAkJCWdvdG8gZXhpdF9wdXRfbm9kZTsKKwkJfQor
CisJCXN0eXBlLT5jb3VudCsrOworCQlzZGF0YS0+ZGF0YSA9IHNlbnNvcl9kYXRhOworCQlzZGF0
YS0+dHlwZSA9IHN0eXBlLT50eXBlOworCisJCXNucHJpbnRmKHNkYXRhLT5hdHRyX25hbWVbMF0s
IE1BWF9BVFRSX0xFTiwgIiVzJWRfaW5wdXQiLAorCQkJIHN0eXBlLT5uYW1lLCBzdHlwZS0+Y291
bnQpOworCisJCXN5c2ZzX2F0dHJfaW5pdCgmc2RhdGEtPnNkX2F0dHJzWzBdLmRldl9hdHRyLmF0
dHIpOworCQlzZGF0YS0+c2RfYXR0cnNbMF0uZGV2X2F0dHIuYXR0ci5uYW1lID0gc2RhdGEtPmF0
dHJfbmFtZVswXTsKKwkJc2RhdGEtPnNkX2F0dHJzWzBdLmRldl9hdHRyLmF0dHIubW9kZSA9IFNf
SVJVR087CisJCXNkYXRhLT5zZF9hdHRyc1swXS5kZXZfYXR0ci5zaG93ID0gc2hvd19zZW5zb3I7
CisJCXNkYXRhLT5zZF9hdHRyc1swXS5pbmRleCA9IGk7CisKKwkJcGRhdGEtPmF0dHJzW2ldID0g
JnNkYXRhLT5zZF9hdHRyc1swXS5kZXZfYXR0ci5hdHRyOworCQlwZGF0YS0+c2Vuc29yc1tpKytd
ID0gc2RhdGE7CisKKwkJaWYgKCFvZl9wcm9wZXJ0eV9yZWFkX3UzMihucCwgInNlbnNvci1zdGF0
dXMiLAorCQkJCQkgICZzZGF0YS0+c3RhdHVzKSkgeworCQkJc25wcmludGYoc2RhdGEtPmF0dHJf
bmFtZVsxXSwgTUFYX0FUVFJfTEVOLAorCQkJCSAiJXMlZF9hbGFybSIsIHN0eXBlLT5uYW1lLCBz
dHlwZS0+Y291bnQpOworCisJCQlzeXNmc19hdHRyX2luaXQoJnNkYXRhLT5zZF9hdHRyc1sxXS5k
ZXZfYXR0ci5hdHRyKTsKKwkJCXNkYXRhLT5zZF9hdHRyc1sxXS5kZXZfYXR0ci5hdHRyLm5hbWUg
PQorCQkJCXNkYXRhLT5hdHRyX25hbWVbMV07CisJCQlzZGF0YS0+c2RfYXR0cnNbMV0uZGV2X2F0
dHIuYXR0ci5tb2RlID0gU19JUlVHTzsKKwkJCXNkYXRhLT5zZF9hdHRyc1sxXS5kZXZfYXR0ci5z
aG93ID0gc2hvd19hbGFybTsKKwkJCXNkYXRhLT5zZF9hdHRyc1sxXS5pbmRleCA9IGk7CisKKwkJ
CXBkYXRhLT5hdHRyc1tpXSA9ICZzZGF0YS0+c2RfYXR0cnNbMV0uZGV2X2F0dHIuYXR0cjsKKwkJ
CXBkYXRhLT5zZW5zb3JzW2krK10gPSBzZGF0YTsKKwkJfQorCisJCWlmICghb2ZfcHJvcGVydHlf
cmVhZF9zdHJpbmcobnAsICJsYWJlbCIsICZsYWJlbCkpIHsKKwkJCXNucHJpbnRmKHNkYXRhLT5h
dHRyX25hbWVbMl0sIE1BWF9BVFRSX0xFTiwKKwkJCQkgIiVzJWRfbGFiZWwiLCBzdHlwZS0+bmFt
ZSwgc3R5cGUtPmNvdW50KTsKIAotCQlzeXNmc19hdHRyX2luaXQoJnNkYXRhW2NvdW50XS5kZXZf
YXR0ci5hdHRyKTsKLQkJc2RhdGFbY291bnRdLmRldl9hdHRyLmF0dHIubmFtZSA9IHNkYXRhW2Nv
dW50XS5uYW1lOwotCQlzZGF0YVtjb3VudF0uZGV2X2F0dHIuYXR0ci5tb2RlID0gU19JUlVHTzsK
LQkJc2RhdGFbY291bnRdLmRldl9hdHRyLnNob3cgPSBzaG93X3NlbnNvcjsKKwkJCW1ha2Vfc2Vu
c29yX2xhYmVsKG5wLCBzZGF0YSwgbGFiZWwpOwogCi0JCXBncm91cHNbdHlwZV0tPmF0dHJzW3Nl
bnNvcl9ncm91cHNbdHlwZV0uYXR0cl9jb3VudCsrXSA9Ci0JCQkJJnNkYXRhW2NvdW50KytdLmRl
dl9hdHRyLmF0dHI7CisJCQlzeXNmc19hdHRyX2luaXQoJnNkYXRhLT5zZF9hdHRyc1syXS5kZXZf
YXR0ci5hdHRyKTsKKwkJCXNkYXRhLT5zZF9hdHRyc1syXS5kZXZfYXR0ci5hdHRyLm5hbWUgPQor
CQkJCXNkYXRhLT5hdHRyX25hbWVbMl07CisJCQlzZGF0YS0+c2RfYXR0cnNbMl0uZGV2X2F0dHIu
YXR0ci5tb2RlID0gU19JUlVHTzsKKwkJCXNkYXRhLT5zZF9hdHRyc1syXS5kZXZfYXR0ci5zaG93
ID0gc2hvd19sYWJlbDsKKwkJCXNkYXRhLT5zZF9hdHRyc1syXS5pbmRleCA9IGk7CisKKwkJCXBk
YXRhLT5hdHRyc1tpXSA9ICZzZGF0YS0+c2RfYXR0cnNbMl0uZGV2X2F0dHIuYXR0cjsKKwkJCXBk
YXRhLT5zZW5zb3JzW2krK10gPSBzZGF0YTsKKwkJfQogCX0KIAorCXBkYXRhLT5hdHRyX2dyb3Vw
LmF0dHJzID0gcGRhdGEtPmF0dHJzOworCXBkYXRhLT5ncm91cHNbMF0gPSAmcGRhdGEtPmF0dHJf
Z3JvdXA7CisKIGV4aXRfcHV0X25vZGU6CiAJb2Zfbm9kZV9wdXQob3BhbCk7CiAJcmV0dXJuIGVy
cjsKIH0KIAotc3RhdGljIGludCBpYm1wb3dlcm52X3Byb2JlKHN0cnVjdCBwbGF0Zm9ybV9kZXZp
Y2UgKnBkZXYpCitzdGF0aWMgaW50IF9faW5pdCBpYm1wb3dlcm52X3Byb2JlKHN0cnVjdCBwbGF0
Zm9ybV9kZXZpY2UgKnBkZXYpCiB7CiAJc3RydWN0IHBsYXRmb3JtX2RhdGEgKnBkYXRhOwogCXN0
cnVjdCBkZXZpY2UgKmh3bW9uX2RldjsKQEAgLTI4OCwxNSArMzE3LDEwIEBAIHN0YXRpYyBpbnQg
aWJtcG93ZXJudl9wcm9iZShzdHJ1Y3QgcGxhdGZvcm1fZGV2aWNlICpwZGV2KQogCWlmIChlcnIp
CiAJCXJldHVybiBlcnI7CiAKLQkvKiBDcmVhdGUgc3lzZnMgYXR0cmlidXRlIGRhdGEgZm9yIGVh
Y2ggc2Vuc29yIGZvdW5kIGluIHRoZSBEVCAqLwotCWVyciA9IGNyZWF0ZV9kZXZpY2VfYXR0cnMo
cGRldik7Ci0JaWYgKGVycikKLQkJcmV0dXJuIGVycjsKLQogCS8qIEZpbmFsbHksIHJlZ2lzdGVy
IHdpdGggaHdtb24gKi8KIAlod21vbl9kZXYgPSBkZXZtX2h3bW9uX2RldmljZV9yZWdpc3Rlcl93
aXRoX2dyb3VwcygmcGRldi0+ZGV2LCBEUlZOQU1FLAogCQkJCQkJCSAgIHBkYXRhLAotCQkJCQkJ
CSAgIHBkYXRhLT5hdHRyX2dyb3Vwcyk7CisJCQkJCQkJICAgcGRhdGEtPmdyb3Vwcyk7CiAKIAly
ZXR1cm4gUFRSX0VSUl9PUl9aRVJPKGh3bW9uX2Rldik7CiB9Ci0tIAoxLjcuMTAuNAoKCl9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmxtLXNlbnNvcnMgbWFp
bGluZyBsaXN0CmxtLXNlbnNvcnNAbG0tc2Vuc29ycy5vcmcKaHR0cDovL2xpc3RzLmxtLXNlbnNv
cnMub3JnL21haWxtYW4vbGlzdGluZm8vbG0tc2Vuc29ycw=

[RFC PATCH 3/3] hwmon: (ibmpowernv) add DTS support

[Cédric Le Goater]

This patch reworks the ibmpowernv driver to support the new device tree
for sensors exposed by OPAL. It also adds new sensors : the core and
memory buffers DTS.

Hopefully, the proposed framework is good enough to easily add sensors
for other resources such as volts, planar temperatures, etc.

Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>
---
 drivers/hwmon/ibmpowernv.c |  336 ++++++++++++++++++++++++--------------------
 1 file changed, 180 insertions(+), 156 deletions(-)

diff --git a/drivers/hwmon/ibmpowernv.c b/drivers/hwmon/ibmpowernv.c
index febe8175d36c..9a6ee33f8219 100644
--- a/drivers/hwmon/ibmpowernv.c
+++ b/drivers/hwmon/ibmpowernv.c
@@ -32,247 +32,276 @@
 #include <linux/err.h>
 
 #define MAX_ATTR_LEN	32
-
-/* Sensor suffix name from DT */
-#define DT_FAULT_ATTR_SUFFIX		"faulted"
-#define DT_DATA_ATTR_SUFFIX		"data"
-#define DT_THRESHOLD_ATTR_SUFFIX	"thrs"
+#define MAX_LABEL_LEN	64
+#define MAX_ATTRS	3	/* sensor-data, sensor-status, label */
 
 /*
  * Enumerates all the types of sensors in the POWERNV platform and does index
- * into 'struct sensor_group'
+ * into 'struct sensor_type'
  */
 enum sensors {
 	FAN,
-	AMBIENT_TEMP,
+	TEMP,
 	POWER_SUPPLY,
 	POWER_INPUT,
 	MAX_SENSOR_TYPE,
 };
 
-static struct sensor_group {
+static struct sensor_type {
+	enum sensors type;
 	const char *name;
-	const char *compatible;
-	struct attribute_group group;
-	u32 attr_count;
-} sensor_groups[] = {
-	{"fan", "ibm,opal-sensor-cooling-fan"},
-	{"temp", "ibm,opal-sensor-amb-temp"},
-	{"in", "ibm,opal-sensor-power-supply"},
-	{"power", "ibm,opal-sensor-power"}
+	u32 count;
+} sensor_types[] = {
+	{ FAN,			"fan"	},
+	{ TEMP,			"temp"	},
+	{ POWER_SUPPLY,		"power"	},
+	{ POWER_INPUT,		"in"	},
+	{ MAX_SENSOR_TYPE,	NULL	}
 };
 
 struct sensor_data {
-	u32 id; /* An opaque id of the firmware for each sensor */
+	u32 data;
+	u32 status;
+	char label[MAX_LABEL_LEN];
 	enum sensors type;
-	char name[MAX_ATTR_LEN];
-	struct device_attribute dev_attr;
+	char attr_name[MAX_ATTRS][MAX_ATTR_LEN];
+	struct sensor_device_attribute sd_attrs[MAX_ATTRS];
 };
 
 struct platform_data {
-	const struct attribute_group *attr_groups[MAX_SENSOR_TYPE + 1];
+	struct attribute_group attr_group;
+	const struct attribute_group *groups[2];
 	u32 sensors_count; /* Total count of sensors from each group */
+	struct attribute **attrs;
+	struct sensor_data **sensors;
 };
 
 static ssize_t show_sensor(struct device *dev, struct device_attribute *devattr,
 			   char *buf)
 {
-	struct sensor_data *sdata = container_of(devattr, struct sensor_data,
-						 dev_attr);
+	struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr);
+	struct platform_data *pdata = dev_get_drvdata(dev);
+	struct sensor_data *sdata = pdata->sensors[attr->index];
 	ssize_t ret;
 	u32 x;
 
-	ret = opal_get_sensor_data(sdata->id, &x);
+	ret = opal_get_sensor_data(sdata->data, &x);
 	if (ret)
 		return ret;
 
 	/* Convert temperature to milli-degrees */
-	if (sdata->type == AMBIENT_TEMP)
+	if (sdata->type == TEMP)
 		x *= 1000;
 	/* Convert power to micro-watts */
-	else if (sdata->type == POWER_INPUT)
+	else if (sdata->type == POWER_SUPPLY)
 		x *= 1000000;
 
 	return sprintf(buf, "%u\n", x);
 }
 
-static int get_sensor_index_attr(const char *name, u32 *index,
-					char *attr)
+static ssize_t show_alarm(struct device *dev, struct device_attribute *devattr,
+			   char *buf)
 {
-	char *hash_pos = strchr(name, '#');
-	char buf[8] = { 0 };
-	char *dash_pos;
-	u32 copy_len;
-	int err;
-
-	if (!hash_pos)
-		return -EINVAL;
-
-	dash_pos = strchr(hash_pos, '-');
-	if (!dash_pos)
-		return -EINVAL;
-
-	copy_len = dash_pos - hash_pos - 1;
-	if (copy_len >= sizeof(buf))
-		return -EINVAL;
+	struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr);
+	struct platform_data *pdata = dev_get_drvdata(dev);
+	struct sensor_data *sdata = pdata->sensors[attr->index];
+	ssize_t ret;
+	u32 x;
 
-	strncpy(buf, hash_pos + 1, copy_len);
+	ret = opal_get_sensor_data(sdata->status, &x);
+	if (ret)
+		return ret;
 
-	err = kstrtou32(buf, 10, index);
-	if (err)
-		return err;
+	/*
+	 * Depending on the sensor type, the status bits can have
+	 * different meanings. Let's not be too subtil for the moment,
+	 * testing against 0x6 should raise an alarm.
+	 */
+	return sprintf(buf, "%u\n", x & 0x6);
+}
 
-	strncpy(attr, dash_pos + 1, MAX_ATTR_LEN);
+static ssize_t show_label(struct device *dev, struct device_attribute *devattr,
+			   char *buf)
+{
+	struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr);
+	struct platform_data *pdata = dev_get_drvdata(dev);
+	struct sensor_data *sdata = pdata->sensors[attr->index];
 
-	return 0;
+	return sprintf(buf, "%s\n", sdata->label);
 }
 
-/*
- * This function translates the DT node name into the 'hwmon' attribute name.
- * IBMPOWERNV device node appear like cooling-fan#2-data, amb-temp#1-thrs etc.
- * which need to be mapped as fan2_input, temp1_max respectively before
- * populating them inside hwmon device class.
- */
-static int create_hwmon_attr_name(struct device *dev, enum sensors type,
-					 const char *node_name,
-					 char *hwmon_attr_name)
+static struct sensor_type *__init get_sensor_type(struct platform_device *pdev,
+	struct device_node *np)
 {
-	char attr_suffix[MAX_ATTR_LEN];
-	char *attr_name;
-	u32 index;
-	int err;
+	const char *type;
+	int i;
 
-	err = get_sensor_index_attr(node_name, &index, attr_suffix);
-	if (err) {
-		dev_err(dev, "Sensor device node name '%s' is invalid\n",
-			node_name);
-		return err;
-	}
+	if (np->name == NULL)
+		return NULL;
+
+	if (!of_device_is_compatible(np, "ibm,opal-sensor"))
+		return NULL;
 
-	if (!strcmp(attr_suffix, DT_FAULT_ATTR_SUFFIX)) {
-		attr_name = "fault";
-	} else if (!strcmp(attr_suffix, DT_DATA_ATTR_SUFFIX)) {
-		attr_name = "input";
-	} else if (!strcmp(attr_suffix, DT_THRESHOLD_ATTR_SUFFIX)) {
-		if (type == AMBIENT_TEMP)
-			attr_name = "max";
-		else if (type == FAN)
-			attr_name = "min";
-		else
-			return -ENOENT;
-	} else {
-		return -ENOENT;
+	if (of_property_read_string(np, "sensor-type", &type)) {
+		dev_info(&pdev->dev,
+			 "'sensor-type' missing in the node '%s'\n",
+			 np->name);
+		return NULL;
 	}
 
-	snprintf(hwmon_attr_name, MAX_ATTR_LEN, "%s%d_%s",
-		 sensor_groups[type].name, index, attr_name);
-	return 0;
+	for (i = 0 ; i < MAX_SENSOR_TYPE; i++)
+		if (!strcmp(type, sensor_types[i].name))
+			return &sensor_types[i];
+
+	return NULL;
 }
 
-static int populate_attr_groups(struct platform_device *pdev)
+static void __init make_sensor_label(struct device_node *np,
+		    struct sensor_data *sdata, const char *label)
 {
-	struct platform_data *pdata = platform_get_drvdata(pdev);
-	const struct attribute_group **pgroups = pdata->attr_groups;
-	struct device_node *opal, *np;
-	enum sensors type;
+	u32 id;
+	size_t n;
 
-	opal = of_find_node_by_path("/ibm,opal/sensors");
-	for_each_child_of_node(opal, np) {
-		if (np->name == NULL)
-			continue;
+	n = snprintf(sdata->label, sizeof(sdata->label), "%s", label);
 
-		for (type = 0; type < MAX_SENSOR_TYPE; type++)
-			if (of_device_is_compatible(np,
-					sensor_groups[type].compatible)) {
-				sensor_groups[type].attr_count++;
-				break;
-			}
-	}
+	/*
+	 * Core temp pretty pretty
+	 */
+	if (!of_property_read_u32(np, "ibm,pir", &id)) {
+		int i;
 
-	of_node_put(opal);
+		for_each_possible_cpu(i)
+			if (paca[i].hw_cpu_id == id)
+				break;
 
-	for (type = 0; type < MAX_SENSOR_TYPE; type++) {
-		sensor_groups[type].group.attrs = devm_kzalloc(&pdev->dev,
-					sizeof(struct attribute *) *
-					(sensor_groups[type].attr_count + 1),
-					GFP_KERNEL);
-		if (!sensor_groups[type].group.attrs)
-			return -ENOMEM;
-
-		pgroups[type] = &sensor_groups[type].group;
-		pdata->sensors_count += sensor_groups[type].attr_count;
-		sensor_groups[type].attr_count = 0;
+		n += snprintf(sdata->label + n, sizeof(sdata->label) - n,
+			      " %d-%d", i, i+7);
 	}
 
-	return 0;
+	/*
+	 * Membuffer pretty print
+	 */
+	if (!of_property_read_u32(np, "ibm,chip-id", &id))
+		n += snprintf(sdata->label + n, sizeof(sdata->label) - n,
+			      " %d", id & 0xffff);
 }
 
-/*
- * Iterate through the device tree for each child of 'sensors' node, create
- * a sysfs attribute file, the file is named by translating the DT node name
- * to the name required by the higher 'hwmon' driver like fan1_input, temp1_max
- * etc..
- */
-static int create_device_attrs(struct platform_device *pdev)
+static int __init populate_attr_groups(struct platform_device *pdev)
 {
 	struct platform_data *pdata = platform_get_drvdata(pdev);
-	const struct attribute_group **pgroups = pdata->attr_groups;
 	struct device_node *opal, *np;
-	struct sensor_data *sdata;
-	u32 sensor_id;
-	enum sensors type;
-	u32 count = 0;
 	int err = 0;
+	int i = 0;
 
 	opal = of_find_node_by_path("/ibm,opal/sensors");
-	sdata = devm_kzalloc(&pdev->dev, pdata->sensors_count * sizeof(*sdata),
-			     GFP_KERNEL);
-	if (!sdata) {
+	if (!opal) {
+		dev_dbg(&pdev->dev, "Opal node 'sensors' not found\n");
+		return -ENODEV;
+	}
+
+	for_each_child_of_node(opal, np) {
+		if (of_device_is_compatible(np, "ibm,opal-sensor"))
+			pdata->sensors_count++;
+	}
+
+	pdata->attrs = devm_kzalloc(&pdev->dev,
+	    sizeof(*pdata->attrs) * pdata->sensors_count * MAX_ATTRS + 1,
+	    GFP_KERNEL);
+	if (!pdata->attrs) {
+		err = -ENOMEM;
+		goto exit_put_node;
+	}
+	pdata->sensors = devm_kzalloc(&pdev->dev,
+	    sizeof(*pdata->sensors) * pdata->sensors_count * MAX_ATTRS + 1,
+	    GFP_KERNEL);
+	if (!pdata->sensors) {
 		err = -ENOMEM;
 		goto exit_put_node;
 	}
 
-	for_each_child_of_node(opal, np) {
-		if (np->name == NULL)
-			continue;
 
-		for (type = 0; type < MAX_SENSOR_TYPE; type++)
-			if (of_device_is_compatible(np,
-					sensor_groups[type].compatible))
-				break;
+	for_each_child_of_node(opal, np) {
+		struct sensor_data *sdata;
+		struct sensor_type *stype;
+		u32 sensor_data;
+		const char *label;
 
-		if (type == MAX_SENSOR_TYPE)
+		stype = get_sensor_type(pdev, np);
+		if (!stype)
 			continue;
 
-		if (of_property_read_u32(np, "sensor-id", &sensor_id)) {
+		if (of_property_read_u32(np, "sensor-data", &sensor_data)) {
 			dev_info(&pdev->dev,
-				 "'sensor-id' missing in the node '%s'\n",
+				 "'sensor-data' missing in the node '%s'\n",
 				 np->name);
 			continue;
 		}
 
-		sdata[count].id = sensor_id;
-		sdata[count].type = type;
-		err = create_hwmon_attr_name(&pdev->dev, type, np->name,
-					     sdata[count].name);
-		if (err)
+		sdata = devm_kzalloc(&pdev->dev, sizeof(*sdata), GFP_KERNEL);
+		if (sdata == NULL) {
+			err = -ENOMEM;
 			goto exit_put_node;
+		}
+
+		stype->count++;
+		sdata->data = sensor_data;
+		sdata->type = stype->type;
+
+		snprintf(sdata->attr_name[0], MAX_ATTR_LEN, "%s%d_input",
+			 stype->name, stype->count);
+
+		sysfs_attr_init(&sdata->sd_attrs[0].dev_attr.attr);
+		sdata->sd_attrs[0].dev_attr.attr.name = sdata->attr_name[0];
+		sdata->sd_attrs[0].dev_attr.attr.mode = S_IRUGO;
+		sdata->sd_attrs[0].dev_attr.show = show_sensor;
+		sdata->sd_attrs[0].index = i;
+
+		pdata->attrs[i] = &sdata->sd_attrs[0].dev_attr.attr;
+		pdata->sensors[i++] = sdata;
+
+		if (!of_property_read_u32(np, "sensor-status",
+					  &sdata->status)) {
+			snprintf(sdata->attr_name[1], MAX_ATTR_LEN,
+				 "%s%d_alarm", stype->name, stype->count);
+
+			sysfs_attr_init(&sdata->sd_attrs[1].dev_attr.attr);
+			sdata->sd_attrs[1].dev_attr.attr.name =
+				sdata->attr_name[1];
+			sdata->sd_attrs[1].dev_attr.attr.mode = S_IRUGO;
+			sdata->sd_attrs[1].dev_attr.show = show_alarm;
+			sdata->sd_attrs[1].index = i;
+
+			pdata->attrs[i] = &sdata->sd_attrs[1].dev_attr.attr;
+			pdata->sensors[i++] = sdata;
+		}
+
+		if (!of_property_read_string(np, "label", &label)) {
+			snprintf(sdata->attr_name[2], MAX_ATTR_LEN,
+				 "%s%d_label", stype->name, stype->count);
 
-		sysfs_attr_init(&sdata[count].dev_attr.attr);
-		sdata[count].dev_attr.attr.name = sdata[count].name;
-		sdata[count].dev_attr.attr.mode = S_IRUGO;
-		sdata[count].dev_attr.show = show_sensor;
+			make_sensor_label(np, sdata, label);
 
-		pgroups[type]->attrs[sensor_groups[type].attr_count++] =
-				&sdata[count++].dev_attr.attr;
+			sysfs_attr_init(&sdata->sd_attrs[2].dev_attr.attr);
+			sdata->sd_attrs[2].dev_attr.attr.name =
+				sdata->attr_name[2];
+			sdata->sd_attrs[2].dev_attr.attr.mode = S_IRUGO;
+			sdata->sd_attrs[2].dev_attr.show = show_label;
+			sdata->sd_attrs[2].index = i;
+
+			pdata->attrs[i] = &sdata->sd_attrs[2].dev_attr.attr;
+			pdata->sensors[i++] = sdata;
+		}
 	}
 
+	pdata->attr_group.attrs = pdata->attrs;
+	pdata->groups[0] = &pdata->attr_group;
+
 exit_put_node:
 	of_node_put(opal);
 	return err;
 }
 
-static int ibmpowernv_probe(struct platform_device *pdev)
+static int __init ibmpowernv_probe(struct platform_device *pdev)
 {
 	struct platform_data *pdata;
 	struct device *hwmon_dev;
@@ -288,15 +317,10 @@ static int ibmpowernv_probe(struct platform_device *pdev)
 	if (err)
 		return err;
 
-	/* Create sysfs attribute data for each sensor found in the DT */
-	err = create_device_attrs(pdev);
-	if (err)
-		return err;
-
 	/* Finally, register with hwmon */
 	hwmon_dev = devm_hwmon_device_register_with_groups(&pdev->dev, DRVNAME,
 							   pdata,
-							   pdata->attr_groups);
+							   pdata->groups);
 
 	return PTR_ERR_OR_ZERO(hwmon_dev);
 }
-- 
1.7.10.4

[lm-sensors] [PATCH 0/5] hwmon: (ibmpowernv) remove dependency on OPAL index

[Cédric Le Goater]

SGVsbG8gIQoKVGhlIGN1cnJlbnQgaW1wbGVtZW50YXRpb24gb2YgdGhlIGRyaXZlciB1c2VzIGFu
IGluZGV4IGZvciB0aGUgaHdtb24gCmF0dHJpYnV0ZSB3aGljaCBpcyBleHRyYWN0ZWQgZnJvbSB0
aGUgZGV2aWNlIG5vZGUgbmFtZS4gVGhpcyBpbmRleAppcyBjYWxjdWxhdGVkIGJ5IHRoZSBPUEFM
IGZpcm13YXJlIGFuZCBpdHMgdXNhZ2UgY3JlYXRlcyBhIGRlcGVuZGVuY3kgCndpdGggdGhlIGRy
aXZlciB3aGljaCBtYWtlcyBjaGFuZ2VzIGEgbGl0dGxlIG1vcmUgY29tcGxleCBpbiBPUEFMLgoK
VGhpcyBwYXRjaHNldCBjaGFuZ2VzIHRoZSBpYm1wb3dlcm52IGNvZGUgdG8gdXNlIGl0cyBvd24g
aW5kZXguIEl0IApzdGFydHMgd2l0aCBhIGZldyBjbGVhbnVwcywgbW9zdGx5IGNvZGUgc2h1ZmZs
aW5nIGFyb3VuZCB0aGUgY3JlYXRpb24gCm9mIHRoZSBod21vbiBzeXNmcyBhdHRyaWJ1dGVzIGFu
ZCBjb21wbGV0ZXMgYnkgcmVtb3ZpbmcgdGhlIGRlcGVuZGVuY3kuCgpJdCBhbHNvIHByZXBhcmVz
IGdyb3VuZCBmb3IgZnV0dXJlIE9QQUwgY2hhbmdlcyA6ICAKCiAgIGh0dHBzOi8vbGlzdHMub3ps
YWJzLm9yZy9waXBlcm1haWwvc2tpYm9vdC8yMDE1LU1hcmNoLzAwMDYzOS5odG1sCgp3aGljaCB3
aWxsIGJlIGFkZHJlc3NlZCBpbiBhIG90aGVyIHNtYWxsIHBhdGNoc2V0LgoKClRoZSBwYXRjaGVz
IGFyZSBiYXNlZCBvbiBMaW51eCA0LjAuMC1yYzQgYW5kIHdlcmUgdGVzdGVkIG9uIElCTSBQb3dl
ciAKYW5kIE9wZW4gUG93ZXIgc3lzdGVtcyBydW5uaW5nIFRydXN0eS4gCgpDaGVlcnMsCgpDLgoK
CkPDqWRyaWMgTGUgR29hdGVyICg1KToKICBod21vbjogKGlibXBvd2VybnYpIHJlcGxhY2UgQU1C
SUVOVF9URU1QIGJ5IFRFTVAKICBod21vbjogKGlibXBvd2VybnYpIGFkZCBhIGdldF9zZW5zb3Jf
dHlwZSgpIHJvdXRpbmUKICBod21vbjogKGlibXBvd2VybnYpIGFkZCBhIGNvbnZlcnRfb3BhbF9h
dHRyX25hbWUoKSByb3V0aW5lCiAgaHdtb246IChpYm1wb3dlcm52KSBjaGFuZ2UgY3JlYXRlX2h3
bW9uX2F0dHJfbmFtZSgpIHByb3RvdHlwZQogIGh3bW9uOiAoaWJtcG93ZXJudikgZG8gbm90IHVz
ZSB0aGUgT1BBTCBpbmRleCBmb3IgaHdtb24gYXR0cmlidXRlCiAgICBuYW1lcwoKIGRyaXZlcnMv
aHdtb24vaWJtcG93ZXJudi5jIHwgIDEyMiArKysrKysrKysrKysrKysrKysrKysrKysrKysrKy0t
LS0tLS0tLS0tLS0tLQogMSBmaWxlIGNoYW5nZWQsIDgxIGluc2VydGlvbnMoKyksIDQxIGRlbGV0
aW9ucygtKQoKLS0gCjEuNy4xMC40CgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18KbG0tc2Vuc29ycyBtYWlsaW5nIGxpc3QKbG0tc2Vuc29yc0BsbS1zZW5z
b3JzLm9yZwpodHRwOi8vbGlzdHMubG0tc2Vuc29ycy5vcmcvbWFpbG1hbi9saXN0aW5mby9sbS1z
ZW5zb3Jz

[PATCH 0/5] hwmon: (ibmpowernv) remove dependency on OPAL index

[Cédric Le Goater]

Hello !

The current implementation of the driver uses an index for the hwmon 
attribute which is extracted from the device node name. This index
is calculated by the OPAL firmware and its usage creates a dependency 
with the driver which makes changes a little more complex in OPAL.

This patchset changes the ibmpowernv code to use its own index. It 
starts with a few cleanups, mostly code shuffling around the creation 
of the hwmon sysfs attributes and completes by removing the dependency.

It also prepares ground for future OPAL changes :  

   https://lists.ozlabs.org/pipermail/skiboot/2015-March/000639.html

which will be addressed in a other small patchset.


The patches are based on Linux 4.0.0-rc4 and were tested on IBM Power 
and Open Power systems running Trusty. 

Cheers,

C.


Cédric Le Goater (5):
  hwmon: (ibmpowernv) replace AMBIENT_TEMP by TEMP
  hwmon: (ibmpowernv) add a get_sensor_type() routine
  hwmon: (ibmpowernv) add a convert_opal_attr_name() routine
  hwmon: (ibmpowernv) change create_hwmon_attr_name() prototype
  hwmon: (ibmpowernv) do not use the OPAL index for hwmon attribute
    names

 drivers/hwmon/ibmpowernv.c |  122 +++++++++++++++++++++++++++++---------------
 1 file changed, 81 insertions(+), 41 deletions(-)

-- 
1.7.10.4

Re: [lm-sensors] [PATCH 0/5] hwmon: (ibmpowernv) remove dependency on OPAL index

[Guenter Roeck]

T24gMDMvMTgvMjAxNSAwODo0NyBBTSwgQ8OpZHJpYyBMZSBHb2F0ZXIgd3JvdGU6Cj4gSGVsbG8g
IQo+Cj4gVGhlIGN1cnJlbnQgaW1wbGVtZW50YXRpb24gb2YgdGhlIGRyaXZlciB1c2VzIGFuIGlu
ZGV4IGZvciB0aGUgaHdtb24KPiBhdHRyaWJ1dGUgd2hpY2ggaXMgZXh0cmFjdGVkIGZyb20gdGhl
IGRldmljZSBub2RlIG5hbWUuIFRoaXMgaW5kZXgKPiBpcyBjYWxjdWxhdGVkIGJ5IHRoZSBPUEFM
IGZpcm13YXJlIGFuZCBpdHMgdXNhZ2UgY3JlYXRlcyBhIGRlcGVuZGVuY3kKPiB3aXRoIHRoZSBk
cml2ZXIgd2hpY2ggbWFrZXMgY2hhbmdlcyBhIGxpdHRsZSBtb3JlIGNvbXBsZXggaW4gT1BBTC4K
Pgo+IFRoaXMgcGF0Y2hzZXQgY2hhbmdlcyB0aGUgaWJtcG93ZXJudiBjb2RlIHRvIHVzZSBpdHMg
b3duIGluZGV4LiBJdAo+IHN0YXJ0cyB3aXRoIGEgZmV3IGNsZWFudXBzLCBtb3N0bHkgY29kZSBz
aHVmZmxpbmcgYXJvdW5kIHRoZSBjcmVhdGlvbgo+IG9mIHRoZSBod21vbiBzeXNmcyBhdHRyaWJ1
dGVzIGFuZCBjb21wbGV0ZXMgYnkgcmVtb3ZpbmcgdGhlIGRlcGVuZGVuY3kuCj4KPiBJdCBhbHNv
IHByZXBhcmVzIGdyb3VuZCBmb3IgZnV0dXJlIE9QQUwgY2hhbmdlcyA6Cj4KPiAgICAgaHR0cHM6
Ly9saXN0cy5vemxhYnMub3JnL3BpcGVybWFpbC9za2lib290LzIwMTUtTWFyY2gvMDAwNjM5Lmh0
bWwKPgo+IHdoaWNoIHdpbGwgYmUgYWRkcmVzc2VkIGluIGEgb3RoZXIgc21hbGwgcGF0Y2hzZXQu
Cj4KPgo+IFRoZSBwYXRjaGVzIGFyZSBiYXNlZCBvbiBMaW51eCA0LjAuMC1yYzQgYW5kIHdlcmUg
dGVzdGVkIG9uIElCTSBQb3dlcgo+IGFuZCBPcGVuIFBvd2VyIHN5c3RlbXMgcnVubmluZyBUcnVz
dHkuCj4KCkkgY29tbWVudGVkIG9uIHR3byBvZiB0aGUgcGF0Y2hlczsgdGhlIG90aGVycyBhcmUg
b2suCgpQbGVhc2UgcmUtc2VuZCB0aGUgZW50aXJlIHNlcmllcyBhZnRlciBhZGRyZXNzaW5nIG15
IGNvbW1lbnRzLgoKVGhhbmtzLApHdWVudGVyCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fCmxtLXNlbnNvcnMgbWFpbGluZyBsaXN0CmxtLXNlbnNvcnNA
bG0tc2Vuc29ycy5vcmcKaHR0cDovL2xpc3RzLmxtLXNlbnNvcnMub3JnL21haWxtYW4vbGlzdGlu
Zm8vbG0tc2Vuc29ycw=

Re: [PATCH 0/5] hwmon: (ibmpowernv) remove dependency on OPAL index

[Guenter Roeck]

On 03/18/2015 08:47 AM, Cédric Le Goater wrote:
> Hello !
>
> The current implementation of the driver uses an index for the hwmon
> attribute which is extracted from the device node name. This index
> is calculated by the OPAL firmware and its usage creates a dependency
> with the driver which makes changes a little more complex in OPAL.
>
> This patchset changes the ibmpowernv code to use its own index. It
> starts with a few cleanups, mostly code shuffling around the creation
> of the hwmon sysfs attributes and completes by removing the dependency.
>
> It also prepares ground for future OPAL changes :
>
>     https://lists.ozlabs.org/pipermail/skiboot/2015-March/000639.html
>
> which will be addressed in a other small patchset.
>
>
> The patches are based on Linux 4.0.0-rc4 and were tested on IBM Power
> and Open Power systems running Trusty.
>

I commented on two of the patches; the others are ok.

Please re-send the entire series after addressing my comments.

Thanks,
Guenter

[lm-sensors] [PATCH 1/5] hwmon: (ibmpowernv) replace AMBIENT_TEMP by TEMP

[Cédric Le Goater]

QW1iaWVudCBpcyB0b28gcmVzdHJpY3RpdmUgYXMgdGhlcmUgY2FuIGJlIG90aGVyIHRlbXBlcmF0
dXJlIGNoYW5uZWxzIDoKY29yZSwgbWVtb3J5LCBldGMuCgpTaWduZWQtb2ZmLWJ5OiBDw6lkcmlj
IExlIEdvYXRlciA8Y2xnQGZyLmlibS5jb20+Ci0tLQogZHJpdmVycy9od21vbi9pYm1wb3dlcm52
LmMgfCAgICA2ICsrKy0tLQogMSBmaWxlIGNoYW5nZWQsIDMgaW5zZXJ0aW9ucygrKSwgMyBkZWxl
dGlvbnMoLSkKCmRpZmYgLS1naXQgYS9kcml2ZXJzL2h3bW9uL2libXBvd2VybnYuYyBiL2RyaXZl
cnMvaHdtb24vaWJtcG93ZXJudi5jCmluZGV4IGZlYmU4MTc1ZDM2Yy4uZjY5MWUxOGRmMTZiIDEw
MDY0NAotLS0gYS9kcml2ZXJzL2h3bW9uL2libXBvd2VybnYuYworKysgYi9kcml2ZXJzL2h3bW9u
L2libXBvd2VybnYuYwpAQCAtNDQsNyArNDQsNyBAQAogICovCiBlbnVtIHNlbnNvcnMgewogCUZB
TiwKLQlBTUJJRU5UX1RFTVAsCisJVEVNUCwKIAlQT1dFUl9TVVBQTFksCiAJUE9XRVJfSU5QVVQs
CiAJTUFYX1NFTlNPUl9UWVBFLApAQCAtODcsNyArODcsNyBAQCBzdGF0aWMgc3NpemVfdCBzaG93
X3NlbnNvcihzdHJ1Y3QgZGV2aWNlICpkZXYsIHN0cnVjdCBkZXZpY2VfYXR0cmlidXRlICpkZXZh
dHRyLAogCQlyZXR1cm4gcmV0OwogCiAJLyogQ29udmVydCB0ZW1wZXJhdHVyZSB0byBtaWxsaS1k
ZWdyZWVzICovCi0JaWYgKHNkYXRhLT50eXBlID09IEFNQklFTlRfVEVNUCkKKwlpZiAoc2RhdGEt
PnR5cGUgPT0gVEVNUCkKIAkJeCAqPSAxMDAwOwogCS8qIENvbnZlcnQgcG93ZXIgdG8gbWljcm8t
d2F0dHMgKi8KIAllbHNlIGlmIChzZGF0YS0+dHlwZSA9PSBQT1dFUl9JTlBVVCkKQEAgLTE1NCw3
ICsxNTQsNyBAQCBzdGF0aWMgaW50IGNyZWF0ZV9od21vbl9hdHRyX25hbWUoc3RydWN0IGRldmlj
ZSAqZGV2LCBlbnVtIHNlbnNvcnMgdHlwZSwKIAl9IGVsc2UgaWYgKCFzdHJjbXAoYXR0cl9zdWZm
aXgsIERUX0RBVEFfQVRUUl9TVUZGSVgpKSB7CiAJCWF0dHJfbmFtZSA9ICJpbnB1dCI7CiAJfSBl
bHNlIGlmICghc3RyY21wKGF0dHJfc3VmZml4LCBEVF9USFJFU0hPTERfQVRUUl9TVUZGSVgpKSB7
Ci0JCWlmICh0eXBlID09IEFNQklFTlRfVEVNUCkKKwkJaWYgKHR5cGUgPT0gVEVNUCkKIAkJCWF0
dHJfbmFtZSA9ICJtYXgiOwogCQllbHNlIGlmICh0eXBlID09IEZBTikKIAkJCWF0dHJfbmFtZSA9
ICJtaW4iOwotLSAKMS43LjEwLjQKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXwpsbS1zZW5zb3JzIG1haWxpbmcgbGlzdApsbS1zZW5zb3JzQGxtLXNlbnNv
cnMub3JnCmh0dHA6Ly9saXN0cy5sbS1zZW5zb3JzLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xtLXNl
bnNvcnM

[PATCH 1/5] hwmon: (ibmpowernv) replace AMBIENT_TEMP by TEMP

[Cédric Le Goater]

Ambient is too restrictive as there can be other temperature channels :
core, memory, etc.

Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>
---
 drivers/hwmon/ibmpowernv.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/hwmon/ibmpowernv.c b/drivers/hwmon/ibmpowernv.c
index febe8175d36c..f691e18df16b 100644
--- a/drivers/hwmon/ibmpowernv.c
+++ b/drivers/hwmon/ibmpowernv.c
@@ -44,7 +44,7 @@
  */
 enum sensors {
 	FAN,
-	AMBIENT_TEMP,
+	TEMP,
 	POWER_SUPPLY,
 	POWER_INPUT,
 	MAX_SENSOR_TYPE,
@@ -87,7 +87,7 @@ static ssize_t show_sensor(struct device *dev, struct device_attribute *devattr,
 		return ret;
 
 	/* Convert temperature to milli-degrees */
-	if (sdata->type == AMBIENT_TEMP)
+	if (sdata->type == TEMP)
 		x *= 1000;
 	/* Convert power to micro-watts */
 	else if (sdata->type == POWER_INPUT)
@@ -154,7 +154,7 @@ static int create_hwmon_attr_name(struct device *dev, enum sensors type,
 	} else if (!strcmp(attr_suffix, DT_DATA_ATTR_SUFFIX)) {
 		attr_name = "input";
 	} else if (!strcmp(attr_suffix, DT_THRESHOLD_ATTR_SUFFIX)) {
-		if (type == AMBIENT_TEMP)
+		if (type == TEMP)
 			attr_name = "max";
 		else if (type == FAN)
 			attr_name = "min";
-- 
1.7.10.4

[lm-sensors] [PATCH 2/5] hwmon: (ibmpowernv) add a get_sensor_type() routine

[Cédric Le Goater]

SXQgd2lsbCBoZWxwIGluIGFkZGluZyBkaWZmZXJlbnQgY29tcGF0aWJsZSBwcm9wZXJ0aWVzLCBj
b21pbmcgZnJvbSBhCm5ldyBkZXZpY2UgdHJlZSBsYXlvdXQgZm9yIGV4YW1wbGUuCgpTaWduZWQt
b2ZmLWJ5OiBDw6lkcmljIExlIEdvYXRlciA8Y2xnQGZyLmlibS5jb20+Ci0tLQogZHJpdmVycy9o
d21vbi9pYm1wb3dlcm52LmMgfCAgIDI2ICsrKysrKysrKysrKysrKy0tLS0tLS0tLS0tCiAxIGZp
bGUgY2hhbmdlZCwgMTUgaW5zZXJ0aW9ucygrKSwgMTEgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0
IGEvZHJpdmVycy9od21vbi9pYm1wb3dlcm52LmMgYi9kcml2ZXJzL2h3bW9uL2libXBvd2VybnYu
YwppbmRleCBmNjkxZTE4ZGYxNmIuLjA3YTgyMTliN2Y0ZSAxMDA2NDQKLS0tIGEvZHJpdmVycy9o
d21vbi9pYm1wb3dlcm52LmMKKysrIGIvZHJpdmVycy9od21vbi9pYm1wb3dlcm52LmMKQEAgLTE2
OSw2ICsxNjksMTcgQEAgc3RhdGljIGludCBjcmVhdGVfaHdtb25fYXR0cl9uYW1lKHN0cnVjdCBk
ZXZpY2UgKmRldiwgZW51bSBzZW5zb3JzIHR5cGUsCiAJcmV0dXJuIDA7CiB9CiAKK3N0YXRpYyBp
bnQgZ2V0X3NlbnNvcl90eXBlKHN0cnVjdCBkZXZpY2Vfbm9kZSAqbnApCit7CisJZW51bSBzZW5z
b3JzIHR5cGU7CisKKwlmb3IgKHR5cGUgPSAwOyB0eXBlIDwgTUFYX1NFTlNPUl9UWVBFOyB0eXBl
KyspIHsKKwkJaWYgKG9mX2RldmljZV9pc19jb21wYXRpYmxlKG5wLCBzZW5zb3JfZ3JvdXBzW3R5
cGVdLmNvbXBhdGlibGUpKQorCQkJcmV0dXJuIHR5cGU7CisJfQorCXJldHVybiBNQVhfU0VOU09S
X1RZUEU7Cit9CisKIHN0YXRpYyBpbnQgcG9wdWxhdGVfYXR0cl9ncm91cHMoc3RydWN0IHBsYXRm
b3JtX2RldmljZSAqcGRldikKIHsKIAlzdHJ1Y3QgcGxhdGZvcm1fZGF0YSAqcGRhdGEgPSBwbGF0
Zm9ybV9nZXRfZHJ2ZGF0YShwZGV2KTsKQEAgLTE4MSwxMiArMTkyLDkgQEAgc3RhdGljIGludCBw
b3B1bGF0ZV9hdHRyX2dyb3VwcyhzdHJ1Y3QgcGxhdGZvcm1fZGV2aWNlICpwZGV2KQogCQlpZiAo
bnAtPm5hbWUgPT0gTlVMTCkKIAkJCWNvbnRpbnVlOwogCi0JCWZvciAodHlwZSA9IDA7IHR5cGUg
PCBNQVhfU0VOU09SX1RZUEU7IHR5cGUrKykKLQkJCWlmIChvZl9kZXZpY2VfaXNfY29tcGF0aWJs
ZShucCwKLQkJCQkJc2Vuc29yX2dyb3Vwc1t0eXBlXS5jb21wYXRpYmxlKSkgewotCQkJCXNlbnNv
cl9ncm91cHNbdHlwZV0uYXR0cl9jb3VudCsrOwotCQkJCWJyZWFrOwotCQkJfQorCQl0eXBlID0g
Z2V0X3NlbnNvcl90eXBlKG5wKTsKKwkJaWYgKHR5cGUgIT0gTUFYX1NFTlNPUl9UWVBFKQorCQkJ
c2Vuc29yX2dyb3Vwc1t0eXBlXS5hdHRyX2NvdW50Kys7CiAJfQogCiAJb2Zfbm9kZV9wdXQob3Bh
bCk7CkBAIC0yMzYsMTEgKzI0NCw3IEBAIHN0YXRpYyBpbnQgY3JlYXRlX2RldmljZV9hdHRycyhz
dHJ1Y3QgcGxhdGZvcm1fZGV2aWNlICpwZGV2KQogCQlpZiAobnAtPm5hbWUgPT0gTlVMTCkKIAkJ
CWNvbnRpbnVlOwogCi0JCWZvciAodHlwZSA9IDA7IHR5cGUgPCBNQVhfU0VOU09SX1RZUEU7IHR5
cGUrKykKLQkJCWlmIChvZl9kZXZpY2VfaXNfY29tcGF0aWJsZShucCwKLQkJCQkJc2Vuc29yX2dy
b3Vwc1t0eXBlXS5jb21wYXRpYmxlKSkKLQkJCQlicmVhazsKLQorCQl0eXBlID0gZ2V0X3NlbnNv
cl90eXBlKG5wKTsKIAkJaWYgKHR5cGUgPT0gTUFYX1NFTlNPUl9UWVBFKQogCQkJY29udGludWU7
CiAKLS0gCjEuNy4xMC40CgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18KbG0tc2Vuc29ycyBtYWlsaW5nIGxpc3QKbG0tc2Vuc29yc0BsbS1zZW5zb3JzLm9y
ZwpodHRwOi8vbGlzdHMubG0tc2Vuc29ycy5vcmcvbWFpbG1hbi9saXN0aW5mby9sbS1zZW5zb3Jz

[PATCH 2/5] hwmon: (ibmpowernv) add a get_sensor_type() routine

[Cédric Le Goater]

It will help in adding different compatible properties, coming from a
new device tree layout for example.

Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>
---
 drivers/hwmon/ibmpowernv.c |   26 +++++++++++++++-----------
 1 file changed, 15 insertions(+), 11 deletions(-)

diff --git a/drivers/hwmon/ibmpowernv.c b/drivers/hwmon/ibmpowernv.c
index f691e18df16b..07a8219b7f4e 100644
--- a/drivers/hwmon/ibmpowernv.c
+++ b/drivers/hwmon/ibmpowernv.c
@@ -169,6 +169,17 @@ static int create_hwmon_attr_name(struct device *dev, enum sensors type,
 	return 0;
 }
 
+static int get_sensor_type(struct device_node *np)
+{
+	enum sensors type;
+
+	for (type = 0; type < MAX_SENSOR_TYPE; type++) {
+		if (of_device_is_compatible(np, sensor_groups[type].compatible))
+			return type;
+	}
+	return MAX_SENSOR_TYPE;
+}
+
 static int populate_attr_groups(struct platform_device *pdev)
 {
 	struct platform_data *pdata = platform_get_drvdata(pdev);
@@ -181,12 +192,9 @@ static int populate_attr_groups(struct platform_device *pdev)
 		if (np->name == NULL)
 			continue;
 
-		for (type = 0; type < MAX_SENSOR_TYPE; type++)
-			if (of_device_is_compatible(np,
-					sensor_groups[type].compatible)) {
-				sensor_groups[type].attr_count++;
-				break;
-			}
+		type = get_sensor_type(np);
+		if (type != MAX_SENSOR_TYPE)
+			sensor_groups[type].attr_count++;
 	}
 
 	of_node_put(opal);
@@ -236,11 +244,7 @@ static int create_device_attrs(struct platform_device *pdev)
 		if (np->name == NULL)
 			continue;
 
-		for (type = 0; type < MAX_SENSOR_TYPE; type++)
-			if (of_device_is_compatible(np,
-					sensor_groups[type].compatible))
-				break;
-
+		type = get_sensor_type(np);
 		if (type == MAX_SENSOR_TYPE)
 			continue;
 
-- 
1.7.10.4

[lm-sensors] [PATCH 3/5] hwmon: (ibmpowernv) add a convert_opal_attr_name() routine

[Cédric Le Goater]

SXQgc2ltcGxpZmllcyB0aGUgY3JlYXRlX2h3bW9uX2F0dHJfbmFtZSgpIHJvdXRpbmUgYW5kIGl0
IGNsZWFybHkgaXNvbGF0ZXMKdGhlIGNvbnZlcnNpb24gZG9uZSBiZXR3ZWVuIHRoZSBPUEFMIG5v
ZGUgbmFtZXMgYW5kIGh3bW9uIGF0dHJpYnV0ZXMgbmFtZXMuCgpTaWduZWQtb2ZmLWJ5OiBDw6lk
cmljIExlIEdvYXRlciA8Y2xnQGZyLmlibS5jb20+Ci0tLQogZHJpdmVycy9od21vbi9pYm1wb3dl
cm52LmMgfCAgIDM5ICsrKysrKysrKysrKysrKysrKysrKysrKystLS0tLS0tLS0tLS0tLQogMSBm
aWxlIGNoYW5nZWQsIDI1IGluc2VydGlvbnMoKyksIDE0IGRlbGV0aW9ucygtKQoKZGlmZiAtLWdp
dCBhL2RyaXZlcnMvaHdtb24vaWJtcG93ZXJudi5jIGIvZHJpdmVycy9od21vbi9pYm1wb3dlcm52
LmMKaW5kZXggMDdhODIxOWI3ZjRlLi5lZGNjNGZmYTVhZDAgMTAwNjQ0Ci0tLSBhL2RyaXZlcnMv
aHdtb24vaWJtcG93ZXJudi5jCisrKyBiL2RyaXZlcnMvaHdtb24vaWJtcG93ZXJudi5jCkBAIC0x
MjcsNiArMTI3LDI4IEBAIHN0YXRpYyBpbnQgZ2V0X3NlbnNvcl9pbmRleF9hdHRyKGNvbnN0IGNo
YXIgKm5hbWUsIHUzMiAqaW5kZXgsCiAJcmV0dXJuIDA7CiB9CiAKK3N0YXRpYyBjb25zdCBjaGFy
ICpjb252ZXJ0X29wYWxfYXR0cl9uYW1lKGVudW0gc2Vuc29ycyB0eXBlLAorCQkJCQljb25zdCBj
aGFyICpvcGFsX2F0dHIpCit7CisJY29uc3QgY2hhciAqYXR0cl9uYW1lID0gTlVMTDsKKworCWlm
ICghc3RyY21wKG9wYWxfYXR0ciwgRFRfRkFVTFRfQVRUUl9TVUZGSVgpKSB7CisJCWF0dHJfbmFt
ZSA9ICJmYXVsdCI7CisJfSBlbHNlIGlmICghc3RyY21wKG9wYWxfYXR0ciwgRFRfREFUQV9BVFRS
X1NVRkZJWCkpIHsKKwkJYXR0cl9uYW1lID0gImlucHV0IjsKKwl9IGVsc2UgaWYgKCFzdHJjbXAo
b3BhbF9hdHRyLCBEVF9USFJFU0hPTERfQVRUUl9TVUZGSVgpKSB7CisJCWlmICh0eXBlID09IFRF
TVApCisJCQlhdHRyX25hbWUgPSAibWF4IjsKKwkJZWxzZSBpZiAodHlwZSA9PSBGQU4pCisJCQlh
dHRyX25hbWUgPSAibWluIjsKKwkJZWxzZQorCQkJcmV0dXJuIE5VTEw7CisJfSBlbHNlIHsKKwkJ
cmV0dXJuIE5VTEw7CisJfQorCXJldHVybiBhdHRyX25hbWU7Cit9CisKIC8qCiAgKiBUaGlzIGZ1
bmN0aW9uIHRyYW5zbGF0ZXMgdGhlIERUIG5vZGUgbmFtZSBpbnRvIHRoZSAnaHdtb24nIGF0dHJp
YnV0ZSBuYW1lLgogICogSUJNUE9XRVJOViBkZXZpY2Ugbm9kZSBhcHBlYXIgbGlrZSBjb29saW5n
LWZhbiMyLWRhdGEsIGFtYi10ZW1wIzEtdGhycyBldGMuCkBAIC0xMzgsNyArMTYwLDcgQEAgc3Rh
dGljIGludCBjcmVhdGVfaHdtb25fYXR0cl9uYW1lKHN0cnVjdCBkZXZpY2UgKmRldiwgZW51bSBz
ZW5zb3JzIHR5cGUsCiAJCQkJCSBjaGFyICpod21vbl9hdHRyX25hbWUpCiB7CiAJY2hhciBhdHRy
X3N1ZmZpeFtNQVhfQVRUUl9MRU5dOwotCWNoYXIgKmF0dHJfbmFtZTsKKwljb25zdCBjaGFyICph
dHRyX25hbWU7CiAJdTMyIGluZGV4OwogCWludCBlcnI7CiAKQEAgLTE0OSwyMCArMTcxLDkgQEAg
c3RhdGljIGludCBjcmVhdGVfaHdtb25fYXR0cl9uYW1lKHN0cnVjdCBkZXZpY2UgKmRldiwgZW51
bSBzZW5zb3JzIHR5cGUsCiAJCXJldHVybiBlcnI7CiAJfQogCi0JaWYgKCFzdHJjbXAoYXR0cl9z
dWZmaXgsIERUX0ZBVUxUX0FUVFJfU1VGRklYKSkgewotCQlhdHRyX25hbWUgPSAiZmF1bHQiOwot
CX0gZWxzZSBpZiAoIXN0cmNtcChhdHRyX3N1ZmZpeCwgRFRfREFUQV9BVFRSX1NVRkZJWCkpIHsK
LQkJYXR0cl9uYW1lID0gImlucHV0IjsKLQl9IGVsc2UgaWYgKCFzdHJjbXAoYXR0cl9zdWZmaXgs
IERUX1RIUkVTSE9MRF9BVFRSX1NVRkZJWCkpIHsKLQkJaWYgKHR5cGUgPT0gVEVNUCkKLQkJCWF0
dHJfbmFtZSA9ICJtYXgiOwotCQllbHNlIGlmICh0eXBlID09IEZBTikKLQkJCWF0dHJfbmFtZSA9
ICJtaW4iOwotCQllbHNlCi0JCQlyZXR1cm4gLUVOT0VOVDsKLQl9IGVsc2UgeworCWF0dHJfbmFt
ZSA9IGNvbnZlcnRfb3BhbF9hdHRyX25hbWUodHlwZSwgYXR0cl9zdWZmaXgpOworCWlmICghYXR0
cl9uYW1lKQogCQlyZXR1cm4gLUVOT0VOVDsKLQl9CiAKIAlzbnByaW50Zihod21vbl9hdHRyX25h
bWUsIE1BWF9BVFRSX0xFTiwgIiVzJWRfJXMiLAogCQkgc2Vuc29yX2dyb3Vwc1t0eXBlXS5uYW1l
LCBpbmRleCwgYXR0cl9uYW1lKTsKLS0gCjEuNy4xMC40CgoKX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18KbG0tc2Vuc29ycyBtYWlsaW5nIGxpc3QKbG0tc2Vu
c29yc0BsbS1zZW5zb3JzLm9yZwpodHRwOi8vbGlzdHMubG0tc2Vuc29ycy5vcmcvbWFpbG1hbi9s
aXN0aW5mby9sbS1zZW5zb3Jz

[PATCH 3/5] hwmon: (ibmpowernv) add a convert_opal_attr_name() routine

[Cédric Le Goater]

It simplifies the create_hwmon_attr_name() routine and it clearly isolates
the conversion done between the OPAL node names and hwmon attributes names.

Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>
---
 drivers/hwmon/ibmpowernv.c |   39 +++++++++++++++++++++++++--------------
 1 file changed, 25 insertions(+), 14 deletions(-)

diff --git a/drivers/hwmon/ibmpowernv.c b/drivers/hwmon/ibmpowernv.c
index 07a8219b7f4e..edcc4ffa5ad0 100644
--- a/drivers/hwmon/ibmpowernv.c
+++ b/drivers/hwmon/ibmpowernv.c
@@ -127,6 +127,28 @@ static int get_sensor_index_attr(const char *name, u32 *index,
 	return 0;
 }
 
+static const char *convert_opal_attr_name(enum sensors type,
+					const char *opal_attr)
+{
+	const char *attr_name = NULL;
+
+	if (!strcmp(opal_attr, DT_FAULT_ATTR_SUFFIX)) {
+		attr_name = "fault";
+	} else if (!strcmp(opal_attr, DT_DATA_ATTR_SUFFIX)) {
+		attr_name = "input";
+	} else if (!strcmp(opal_attr, DT_THRESHOLD_ATTR_SUFFIX)) {
+		if (type == TEMP)
+			attr_name = "max";
+		else if (type == FAN)
+			attr_name = "min";
+		else
+			return NULL;
+	} else {
+		return NULL;
+	}
+	return attr_name;
+}
+
 /*
  * This function translates the DT node name into the 'hwmon' attribute name.
  * IBMPOWERNV device node appear like cooling-fan#2-data, amb-temp#1-thrs etc.
@@ -138,7 +160,7 @@ static int create_hwmon_attr_name(struct device *dev, enum sensors type,
 					 char *hwmon_attr_name)
 {
 	char attr_suffix[MAX_ATTR_LEN];
-	char *attr_name;
+	const char *attr_name;
 	u32 index;
 	int err;
 
@@ -149,20 +171,9 @@ static int create_hwmon_attr_name(struct device *dev, enum sensors type,
 		return err;
 	}
 
-	if (!strcmp(attr_suffix, DT_FAULT_ATTR_SUFFIX)) {
-		attr_name = "fault";
-	} else if (!strcmp(attr_suffix, DT_DATA_ATTR_SUFFIX)) {
-		attr_name = "input";
-	} else if (!strcmp(attr_suffix, DT_THRESHOLD_ATTR_SUFFIX)) {
-		if (type == TEMP)
-			attr_name = "max";
-		else if (type == FAN)
-			attr_name = "min";
-		else
-			return -ENOENT;
-	} else {
+	attr_name = convert_opal_attr_name(type, attr_suffix);
+	if (!attr_name)
 		return -ENOENT;
-	}
 
 	snprintf(hwmon_attr_name, MAX_ATTR_LEN, "%s%d_%s",
 		 sensor_groups[type].name, index, attr_name);
-- 
1.7.10.4

Re: [lm-sensors] [PATCH 3/5] hwmon: (ibmpowernv) add a convert_opal_attr_name() routine

[Guenter Roeck]

T24gMDMvMTgvMjAxNSAwODo0NyBBTSwgQ8OpZHJpYyBMZSBHb2F0ZXIgd3JvdGU6Cj4gSXQgc2lt
cGxpZmllcyB0aGUgY3JlYXRlX2h3bW9uX2F0dHJfbmFtZSgpIHJvdXRpbmUgYW5kIGl0IGNsZWFy
bHkgaXNvbGF0ZXMKPiB0aGUgY29udmVyc2lvbiBkb25lIGJldHdlZW4gdGhlIE9QQUwgbm9kZSBu
YW1lcyBhbmQgaHdtb24gYXR0cmlidXRlcyBuYW1lcy4KPgo+IFNpZ25lZC1vZmYtYnk6IEPDqWRy
aWMgTGUgR29hdGVyIDxjbGdAZnIuaWJtLmNvbT4KPiAtLS0KPiAgIGRyaXZlcnMvaHdtb24vaWJt
cG93ZXJudi5jIHwgICAzOSArKysrKysrKysrKysrKysrKysrKysrKysrLS0tLS0tLS0tLS0tLS0K
PiAgIDEgZmlsZSBjaGFuZ2VkLCAyNSBpbnNlcnRpb25zKCspLCAxNCBkZWxldGlvbnMoLSkKPgo+
IGRpZmYgLS1naXQgYS9kcml2ZXJzL2h3bW9uL2libXBvd2VybnYuYyBiL2RyaXZlcnMvaHdtb24v
aWJtcG93ZXJudi5jCj4gaW5kZXggMDdhODIxOWI3ZjRlLi5lZGNjNGZmYTVhZDAgMTAwNjQ0Cj4g
LS0tIGEvZHJpdmVycy9od21vbi9pYm1wb3dlcm52LmMKPiArKysgYi9kcml2ZXJzL2h3bW9uL2li
bXBvd2VybnYuYwo+IEBAIC0xMjcsNiArMTI3LDI4IEBAIHN0YXRpYyBpbnQgZ2V0X3NlbnNvcl9p
bmRleF9hdHRyKGNvbnN0IGNoYXIgKm5hbWUsIHUzMiAqaW5kZXgsCj4gICAJcmV0dXJuIDA7Cj4g
ICB9Cj4KPiArc3RhdGljIGNvbnN0IGNoYXIgKmNvbnZlcnRfb3BhbF9hdHRyX25hbWUoZW51bSBz
ZW5zb3JzIHR5cGUsCj4gKwkJCQkJY29uc3QgY2hhciAqb3BhbF9hdHRyKQoKV291bGQgYmUgZ3Jl
YXQgaWYgeW91IGNvdWxkIGFsaWduIGFsbCB0aGUgY29udGludWF0aW9uIGxpbmVzIHdpdGggJygn
LgoKPiArewo+ICsJY29uc3QgY2hhciAqYXR0cl9uYW1lID0gTlVMTDsKPiArCj4gKwlpZiAoIXN0
cmNtcChvcGFsX2F0dHIsIERUX0ZBVUxUX0FUVFJfU1VGRklYKSkgewo+ICsJCWF0dHJfbmFtZSA9
ICJmYXVsdCI7Cj4gKwl9IGVsc2UgaWYgKCFzdHJjbXAob3BhbF9hdHRyLCBEVF9EQVRBX0FUVFJf
U1VGRklYKSkgewo+ICsJCWF0dHJfbmFtZSA9ICJpbnB1dCI7Cj4gKwl9IGVsc2UgaWYgKCFzdHJj
bXAob3BhbF9hdHRyLCBEVF9USFJFU0hPTERfQVRUUl9TVUZGSVgpKSB7Cj4gKwkJaWYgKHR5cGUg
PT0gVEVNUCkKPiArCQkJYXR0cl9uYW1lID0gIm1heCI7Cj4gKwkJZWxzZSBpZiAodHlwZSA9PSBG
QU4pCj4gKwkJCWF0dHJfbmFtZSA9ICJtaW4iOwo+ICsJCWVsc2UKPiArCQkJcmV0dXJuIE5VTEw7
Cj4gKwl9IGVsc2Ugewo+ICsJCXJldHVybiBOVUxMOwo+ICsJfQoKVGhvc2UgZWxzZSBjYXNlcyBy
ZXR1cm5pbmcgTlVMTCBhcmUgdW5uZWNlc3Nhcnk7IGF0dHJfbmFtZQppcyBhbHJlYWR5IGluaXRp
YWxpemVkIHdpdGggTlVMTCwgc28geW91IGNhbiBqdXN0IHJldHVybiBpdC4KCgo+ICsJcmV0dXJu
IGF0dHJfbmFtZTsKPiArfQo+ICsKPiAgIC8qCj4gICAgKiBUaGlzIGZ1bmN0aW9uIHRyYW5zbGF0
ZXMgdGhlIERUIG5vZGUgbmFtZSBpbnRvIHRoZSAnaHdtb24nIGF0dHJpYnV0ZSBuYW1lLgo+ICAg
ICogSUJNUE9XRVJOViBkZXZpY2Ugbm9kZSBhcHBlYXIgbGlrZSBjb29saW5nLWZhbiMyLWRhdGEs
IGFtYi10ZW1wIzEtdGhycyBldGMuCj4gQEAgLTEzOCw3ICsxNjAsNyBAQCBzdGF0aWMgaW50IGNy
ZWF0ZV9od21vbl9hdHRyX25hbWUoc3RydWN0IGRldmljZSAqZGV2LCBlbnVtIHNlbnNvcnMgdHlw
ZSwKPiAgIAkJCQkJIGNoYXIgKmh3bW9uX2F0dHJfbmFtZSkKPiAgIHsKPiAgIAljaGFyIGF0dHJf
c3VmZml4W01BWF9BVFRSX0xFTl07Cj4gLQljaGFyICphdHRyX25hbWU7Cj4gKwljb25zdCBjaGFy
ICphdHRyX25hbWU7Cj4gICAJdTMyIGluZGV4Owo+ICAgCWludCBlcnI7Cj4KPiBAQCAtMTQ5LDIw
ICsxNzEsOSBAQCBzdGF0aWMgaW50IGNyZWF0ZV9od21vbl9hdHRyX25hbWUoc3RydWN0IGRldmlj
ZSAqZGV2LCBlbnVtIHNlbnNvcnMgdHlwZSwKPiAgIAkJcmV0dXJuIGVycjsKPiAgIAl9Cj4KPiAt
CWlmICghc3RyY21wKGF0dHJfc3VmZml4LCBEVF9GQVVMVF9BVFRSX1NVRkZJWCkpIHsKPiAtCQlh
dHRyX25hbWUgPSAiZmF1bHQiOwo+IC0JfSBlbHNlIGlmICghc3RyY21wKGF0dHJfc3VmZml4LCBE
VF9EQVRBX0FUVFJfU1VGRklYKSkgewo+IC0JCWF0dHJfbmFtZSA9ICJpbnB1dCI7Cj4gLQl9IGVs
c2UgaWYgKCFzdHJjbXAoYXR0cl9zdWZmaXgsIERUX1RIUkVTSE9MRF9BVFRSX1NVRkZJWCkpIHsK
PiAtCQlpZiAodHlwZSA9PSBURU1QKQo+IC0JCQlhdHRyX25hbWUgPSAibWF4IjsKPiAtCQllbHNl
IGlmICh0eXBlID09IEZBTikKPiAtCQkJYXR0cl9uYW1lID0gIm1pbiI7Cj4gLQkJZWxzZQo+IC0J
CQlyZXR1cm4gLUVOT0VOVDsKPiAtCX0gZWxzZSB7Cj4gKwlhdHRyX25hbWUgPSBjb252ZXJ0X29w
YWxfYXR0cl9uYW1lKHR5cGUsIGF0dHJfc3VmZml4KTsKPiArCWlmICghYXR0cl9uYW1lKQo+ICAg
CQlyZXR1cm4gLUVOT0VOVDsKPiAtCX0KPgo+ICAgCXNucHJpbnRmKGh3bW9uX2F0dHJfbmFtZSwg
TUFYX0FUVFJfTEVOLCAiJXMlZF8lcyIsCj4gICAJCSBzZW5zb3JfZ3JvdXBzW3R5cGVdLm5hbWUs
IGluZGV4LCBhdHRyX25hbWUpOwo+CgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18KbG0tc2Vuc29ycyBtYWlsaW5nIGxpc3QKbG0tc2Vuc29yc0BsbS1zZW5z
b3JzLm9yZwpodHRwOi8vbGlzdHMubG0tc2Vuc29ycy5vcmcvbWFpbG1hbi9saXN0aW5mby9sbS1z
ZW5zb3Jz

Re: [PATCH 3/5] hwmon: (ibmpowernv) add a convert_opal_attr_name() routine

[Guenter Roeck]

On 03/18/2015 08:47 AM, Cédric Le Goater wrote:
> It simplifies the create_hwmon_attr_name() routine and it clearly isolates
> the conversion done between the OPAL node names and hwmon attributes names.
>
> Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>
> ---
>   drivers/hwmon/ibmpowernv.c |   39 +++++++++++++++++++++++++--------------
>   1 file changed, 25 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/hwmon/ibmpowernv.c b/drivers/hwmon/ibmpowernv.c
> index 07a8219b7f4e..edcc4ffa5ad0 100644
> --- a/drivers/hwmon/ibmpowernv.c
> +++ b/drivers/hwmon/ibmpowernv.c
> @@ -127,6 +127,28 @@ static int get_sensor_index_attr(const char *name, u32 *index,
>   	return 0;
>   }
>
> +static const char *convert_opal_attr_name(enum sensors type,
> +					const char *opal_attr)

Would be great if you could align all the continuation lines with '('.

> +{
> +	const char *attr_name = NULL;
> +
> +	if (!strcmp(opal_attr, DT_FAULT_ATTR_SUFFIX)) {
> +		attr_name = "fault";
> +	} else if (!strcmp(opal_attr, DT_DATA_ATTR_SUFFIX)) {
> +		attr_name = "input";
> +	} else if (!strcmp(opal_attr, DT_THRESHOLD_ATTR_SUFFIX)) {
> +		if (type == TEMP)
> +			attr_name = "max";
> +		else if (type == FAN)
> +			attr_name = "min";
> +		else
> +			return NULL;
> +	} else {
> +		return NULL;
> +	}

Those else cases returning NULL are unnecessary; attr_name
is already initialized with NULL, so you can just return it.


> +	return attr_name;
> +}
> +
>   /*
>    * This function translates the DT node name into the 'hwmon' attribute name.
>    * IBMPOWERNV device node appear like cooling-fan#2-data, amb-temp#1-thrs etc.
> @@ -138,7 +160,7 @@ static int create_hwmon_attr_name(struct device *dev, enum sensors type,
>   					 char *hwmon_attr_name)
>   {
>   	char attr_suffix[MAX_ATTR_LEN];
> -	char *attr_name;
> +	const char *attr_name;
>   	u32 index;
>   	int err;
>
> @@ -149,20 +171,9 @@ static int create_hwmon_attr_name(struct device *dev, enum sensors type,
>   		return err;
>   	}
>
> -	if (!strcmp(attr_suffix, DT_FAULT_ATTR_SUFFIX)) {
> -		attr_name = "fault";
> -	} else if (!strcmp(attr_suffix, DT_DATA_ATTR_SUFFIX)) {
> -		attr_name = "input";
> -	} else if (!strcmp(attr_suffix, DT_THRESHOLD_ATTR_SUFFIX)) {
> -		if (type == TEMP)
> -			attr_name = "max";
> -		else if (type == FAN)
> -			attr_name = "min";
> -		else
> -			return -ENOENT;
> -	} else {
> +	attr_name = convert_opal_attr_name(type, attr_suffix);
> +	if (!attr_name)
>   		return -ENOENT;
> -	}
>
>   	snprintf(hwmon_attr_name, MAX_ATTR_LEN, "%s%d_%s",
>   		 sensor_groups[type].name, index, attr_name);
>

[lm-sensors] [PATCH 4/5] hwmon: (ibmpowernv) change create_hwmon_attr_name() prototype

[Cédric Le Goater]

SXQgc2ltcGxpZmllcyB0aGUgY3JlYXRpb24gb2YgdGhlIGh3bW9uIGF0dHJpYnV0ZXMgYW5kIHdp
bGwgaGVscCB3aGVuCnN1cHBvcnQgZm9yIGEgbmV3IGRldmljZSB0cmVlIGxheW91dCBpcyBhZGRl
ZC4gVGhlIHBhdGNoIGFsc28gY2hhbmdlcwp0aGUgbmFtZSBvZiB0aGUgcm91dGluZSB0byBwYXJz
ZV9vcGFsX25vZGVfbmFtZSgpLgoKU2lnbmVkLW9mZi1ieTogQ8OpZHJpYyBMZSBHb2F0ZXIgPGNs
Z0Bmci5pYm0uY29tPgotLS0KIGRyaXZlcnMvaHdtb24vaWJtcG93ZXJudi5jIHwgICAzMiArKysr
KysrKysrKysrKysrKystLS0tLS0tLS0tLS0tLQogMSBmaWxlIGNoYW5nZWQsIDE4IGluc2VydGlv
bnMoKyksIDE0IGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL2RyaXZlcnMvaHdtb24vaWJtcG93
ZXJudi5jIGIvZHJpdmVycy9od21vbi9pYm1wb3dlcm52LmMKaW5kZXggZWRjYzRmZmE1YWQwLi41
NzBkMjM2MGI2OTggMTAwNjQ0Ci0tLSBhL2RyaXZlcnMvaHdtb24vaWJtcG93ZXJudi5jCisrKyBi
L2RyaXZlcnMvaHdtb24vaWJtcG93ZXJudi5jCkBAIC0xNTUsMjggKzE1NSwyMiBAQCBzdGF0aWMg
Y29uc3QgY2hhciAqY29udmVydF9vcGFsX2F0dHJfbmFtZShlbnVtIHNlbnNvcnMgdHlwZSwKICAq
IHdoaWNoIG5lZWQgdG8gYmUgbWFwcGVkIGFzIGZhbjJfaW5wdXQsIHRlbXAxX21heCByZXNwZWN0
aXZlbHkgYmVmb3JlCiAgKiBwb3B1bGF0aW5nIHRoZW0gaW5zaWRlIGh3bW9uIGRldmljZSBjbGFz
cy4KICAqLwotc3RhdGljIGludCBjcmVhdGVfaHdtb25fYXR0cl9uYW1lKHN0cnVjdCBkZXZpY2Ug
KmRldiwgZW51bSBzZW5zb3JzIHR5cGUsCi0JCQkJCSBjb25zdCBjaGFyICpub2RlX25hbWUsCi0J
CQkJCSBjaGFyICpod21vbl9hdHRyX25hbWUpCitzdGF0aWMgaW50IHBhcnNlX29wYWxfbm9kZV9u
YW1lKGNvbnN0IGNoYXIgKm5vZGVfbmFtZSwgZW51bSBzZW5zb3JzIHR5cGUsCisJdTMyICppbmRl
eCwgY29uc3QgY2hhciAqKmh3bW9uX2F0dHJfbmFtZSkKIHsKIAljaGFyIGF0dHJfc3VmZml4W01B
WF9BVFRSX0xFTl07CiAJY29uc3QgY2hhciAqYXR0cl9uYW1lOwotCXUzMiBpbmRleDsKIAlpbnQg
ZXJyOwogCi0JZXJyID0gZ2V0X3NlbnNvcl9pbmRleF9hdHRyKG5vZGVfbmFtZSwgJmluZGV4LCBh
dHRyX3N1ZmZpeCk7Ci0JaWYgKGVycikgewotCQlkZXZfZXJyKGRldiwgIlNlbnNvciBkZXZpY2Ug
bm9kZSBuYW1lICclcycgaXMgaW52YWxpZFxuIiwKLQkJCW5vZGVfbmFtZSk7CisJZXJyID0gZ2V0
X3NlbnNvcl9pbmRleF9hdHRyKG5vZGVfbmFtZSwgaW5kZXgsIGF0dHJfc3VmZml4KTsKKwlpZiAo
ZXJyKQogCQlyZXR1cm4gZXJyOwotCX0KIAogCWF0dHJfbmFtZSA9IGNvbnZlcnRfb3BhbF9hdHRy
X25hbWUodHlwZSwgYXR0cl9zdWZmaXgpOwogCWlmICghYXR0cl9uYW1lKQogCQlyZXR1cm4gLUVO
T0VOVDsKIAotCXNucHJpbnRmKGh3bW9uX2F0dHJfbmFtZSwgTUFYX0FUVFJfTEVOLCAiJXMlZF8l
cyIsCi0JCSBzZW5zb3JfZ3JvdXBzW3R5cGVdLm5hbWUsIGluZGV4LCBhdHRyX25hbWUpOworCSpo
d21vbl9hdHRyX25hbWUgPSBhdHRyX25hbWU7CiAJcmV0dXJuIDA7CiB9CiAKQEAgLTI1Miw2ICsy
NDYsOSBAQCBzdGF0aWMgaW50IGNyZWF0ZV9kZXZpY2VfYXR0cnMoc3RydWN0IHBsYXRmb3JtX2Rl
dmljZSAqcGRldikKIAl9CiAKIAlmb3JfZWFjaF9jaGlsZF9vZl9ub2RlKG9wYWwsIG5wKSB7CisJ
CWNvbnN0IGNoYXIgKmF0dHJfbmFtZTsKKwkJdTMyIG9wYWxfaW5kZXg7CisKIAkJaWYgKG5wLT5u
YW1lID09IE5VTEwpCiAJCQljb250aW51ZTsKIApAQCAtMjY4LDEwICsyNjUsMTcgQEAgc3RhdGlj
IGludCBjcmVhdGVfZGV2aWNlX2F0dHJzKHN0cnVjdCBwbGF0Zm9ybV9kZXZpY2UgKnBkZXYpCiAK
IAkJc2RhdGFbY291bnRdLmlkID0gc2Vuc29yX2lkOwogCQlzZGF0YVtjb3VudF0udHlwZSA9IHR5
cGU7Ci0JCWVyciA9IGNyZWF0ZV9od21vbl9hdHRyX25hbWUoJnBkZXYtPmRldiwgdHlwZSwgbnAt
Pm5hbWUsCi0JCQkJCSAgICAgc2RhdGFbY291bnRdLm5hbWUpOwotCQlpZiAoZXJyKQorCisJCWVy
ciA9IHBhcnNlX29wYWxfbm9kZV9uYW1lKG5wLT5uYW1lLCB0eXBlLCAmb3BhbF9pbmRleCwKKwkJ
CQkJICAgJmF0dHJfbmFtZSk7CisJCWlmIChlcnIpIHsKKwkJCWRldl9lcnIoJnBkZXYtPmRldiwg
IlNlbnNvciBkZXZpY2Ugbm9kZSBuYW1lICclcycgaXMgaW52YWxpZFxuIiwKKwkJCQlucC0+bmFt
ZSk7CiAJCQlnb3RvIGV4aXRfcHV0X25vZGU7CisJCX0KKworCQlzbnByaW50ZihzZGF0YVtjb3Vu
dF0ubmFtZSwgTUFYX0FUVFJfTEVOLCAiJXMlZF8lcyIsCisJCQkgc2Vuc29yX2dyb3Vwc1t0eXBl
XS5uYW1lLCBvcGFsX2luZGV4LCBhdHRyX25hbWUpOwogCiAJCXN5c2ZzX2F0dHJfaW5pdCgmc2Rh
dGFbY291bnRdLmRldl9hdHRyLmF0dHIpOwogCQlzZGF0YVtjb3VudF0uZGV2X2F0dHIuYXR0ci5u
YW1lID0gc2RhdGFbY291bnRdLm5hbWU7Ci0tIAoxLjcuMTAuNAoKCl9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmxtLXNlbnNvcnMgbWFpbGluZyBsaXN0Cmxt
LXNlbnNvcnNAbG0tc2Vuc29ycy5vcmcKaHR0cDovL2xpc3RzLmxtLXNlbnNvcnMub3JnL21haWxt
YW4vbGlzdGluZm8vbG0tc2Vuc29ycw=

[PATCH 4/5] hwmon: (ibmpowernv) change create_hwmon_attr_name() prototype

[Cédric Le Goater]

It simplifies the creation of the hwmon attributes and will help when
support for a new device tree layout is added. The patch also changes
the name of the routine to parse_opal_node_name().

Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>
---
 drivers/hwmon/ibmpowernv.c |   32 ++++++++++++++++++--------------
 1 file changed, 18 insertions(+), 14 deletions(-)

diff --git a/drivers/hwmon/ibmpowernv.c b/drivers/hwmon/ibmpowernv.c
index edcc4ffa5ad0..570d2360b698 100644
--- a/drivers/hwmon/ibmpowernv.c
+++ b/drivers/hwmon/ibmpowernv.c
@@ -155,28 +155,22 @@ static const char *convert_opal_attr_name(enum sensors type,
  * which need to be mapped as fan2_input, temp1_max respectively before
  * populating them inside hwmon device class.
  */
-static int create_hwmon_attr_name(struct device *dev, enum sensors type,
-					 const char *node_name,
-					 char *hwmon_attr_name)
+static int parse_opal_node_name(const char *node_name, enum sensors type,
+	u32 *index, const char **hwmon_attr_name)
 {
 	char attr_suffix[MAX_ATTR_LEN];
 	const char *attr_name;
-	u32 index;
 	int err;
 
-	err = get_sensor_index_attr(node_name, &index, attr_suffix);
-	if (err) {
-		dev_err(dev, "Sensor device node name '%s' is invalid\n",
-			node_name);
+	err = get_sensor_index_attr(node_name, index, attr_suffix);
+	if (err)
 		return err;
-	}
 
 	attr_name = convert_opal_attr_name(type, attr_suffix);
 	if (!attr_name)
 		return -ENOENT;
 
-	snprintf(hwmon_attr_name, MAX_ATTR_LEN, "%s%d_%s",
-		 sensor_groups[type].name, index, attr_name);
+	*hwmon_attr_name = attr_name;
 	return 0;
 }
 
@@ -252,6 +246,9 @@ static int create_device_attrs(struct platform_device *pdev)
 	}
 
 	for_each_child_of_node(opal, np) {
+		const char *attr_name;
+		u32 opal_index;
+
 		if (np->name == NULL)
 			continue;
 
@@ -268,10 +265,17 @@ static int create_device_attrs(struct platform_device *pdev)
 
 		sdata[count].id = sensor_id;
 		sdata[count].type = type;
-		err = create_hwmon_attr_name(&pdev->dev, type, np->name,
-					     sdata[count].name);
-		if (err)
+
+		err = parse_opal_node_name(np->name, type, &opal_index,
+					   &attr_name);
+		if (err) {
+			dev_err(&pdev->dev, "Sensor device node name '%s' is invalid\n",
+				np->name);
 			goto exit_put_node;
+		}
+
+		snprintf(sdata[count].name, MAX_ATTR_LEN, "%s%d_%s",
+			 sensor_groups[type].name, opal_index, attr_name);
 
 		sysfs_attr_init(&sdata[count].dev_attr.attr);
 		sdata[count].dev_attr.attr.name = sdata[count].name;
-- 
1.7.10.4

Re: [lm-sensors] [PATCH 4/5] hwmon: (ibmpowernv) change create_hwmon_attr_name() prototype

[Guenter Roeck]

T24gMDMvMTgvMjAxNSAwODo0NyBBTSwgQ8OpZHJpYyBMZSBHb2F0ZXIgd3JvdGU6Cj4gSXQgc2lt
cGxpZmllcyB0aGUgY3JlYXRpb24gb2YgdGhlIGh3bW9uIGF0dHJpYnV0ZXMgYW5kIHdpbGwgaGVs
cCB3aGVuCj4gc3VwcG9ydCBmb3IgYSBuZXcgZGV2aWNlIHRyZWUgbGF5b3V0IGlzIGFkZGVkLiBU
aGUgcGF0Y2ggYWxzbyBjaGFuZ2VzCj4gdGhlIG5hbWUgb2YgdGhlIHJvdXRpbmUgdG8gcGFyc2Vf
b3BhbF9ub2RlX25hbWUoKS4KPgo+IFNpZ25lZC1vZmYtYnk6IEPDqWRyaWMgTGUgR29hdGVyIDxj
bGdAZnIuaWJtLmNvbT4KPiAtLS0KPiAgIGRyaXZlcnMvaHdtb24vaWJtcG93ZXJudi5jIHwgICAz
MiArKysrKysrKysrKysrKysrKystLS0tLS0tLS0tLS0tLQo+ICAgMSBmaWxlIGNoYW5nZWQsIDE4
IGluc2VydGlvbnMoKyksIDE0IGRlbGV0aW9ucygtKQo+Cj4gZGlmZiAtLWdpdCBhL2RyaXZlcnMv
aHdtb24vaWJtcG93ZXJudi5jIGIvZHJpdmVycy9od21vbi9pYm1wb3dlcm52LmMKPiBpbmRleCBl
ZGNjNGZmYTVhZDAuLjU3MGQyMzYwYjY5OCAxMDA2NDQKPiAtLS0gYS9kcml2ZXJzL2h3bW9uL2li
bXBvd2VybnYuYwo+ICsrKyBiL2RyaXZlcnMvaHdtb24vaWJtcG93ZXJudi5jCj4gQEAgLTE1NSwy
OCArMTU1LDIyIEBAIHN0YXRpYyBjb25zdCBjaGFyICpjb252ZXJ0X29wYWxfYXR0cl9uYW1lKGVu
dW0gc2Vuc29ycyB0eXBlLAo+ICAgICogd2hpY2ggbmVlZCB0byBiZSBtYXBwZWQgYXMgZmFuMl9p
bnB1dCwgdGVtcDFfbWF4IHJlc3BlY3RpdmVseSBiZWZvcmUKPiAgICAqIHBvcHVsYXRpbmcgdGhl
bSBpbnNpZGUgaHdtb24gZGV2aWNlIGNsYXNzLgo+ICAgICovCj4gLXN0YXRpYyBpbnQgY3JlYXRl
X2h3bW9uX2F0dHJfbmFtZShzdHJ1Y3QgZGV2aWNlICpkZXYsIGVudW0gc2Vuc29ycyB0eXBlLAo+
IC0JCQkJCSBjb25zdCBjaGFyICpub2RlX25hbWUsCj4gLQkJCQkJIGNoYXIgKmh3bW9uX2F0dHJf
bmFtZSkKPiArc3RhdGljIGludCBwYXJzZV9vcGFsX25vZGVfbmFtZShjb25zdCBjaGFyICpub2Rl
X25hbWUsIGVudW0gc2Vuc29ycyB0eXBlLAo+ICsJdTMyICppbmRleCwgY29uc3QgY2hhciAqKmh3
bW9uX2F0dHJfbmFtZSkKPiAgIHsKClBsZWFzZSBoYXZlIHRoZSBmdW5jdGlvbiByZXR1cm4gY29u
c3QgY2hhciAqIGFuZCBtZXJnZSB0aGUgZXJyb3IgY29kZSB3aXRoIEVSUl9QVFIuCgo+ICAgCWNo
YXIgYXR0cl9zdWZmaXhbTUFYX0FUVFJfTEVOXTsKPiAgIAljb25zdCBjaGFyICphdHRyX25hbWU7
Cj4gLQl1MzIgaW5kZXg7Cj4gICAJaW50IGVycjsKPgo+IC0JZXJyID0gZ2V0X3NlbnNvcl9pbmRl
eF9hdHRyKG5vZGVfbmFtZSwgJmluZGV4LCBhdHRyX3N1ZmZpeCk7Cj4gLQlpZiAoZXJyKSB7Cj4g
LQkJZGV2X2VycihkZXYsICJTZW5zb3IgZGV2aWNlIG5vZGUgbmFtZSAnJXMnIGlzIGludmFsaWRc
biIsCj4gLQkJCW5vZGVfbmFtZSk7Cj4gKwllcnIgPSBnZXRfc2Vuc29yX2luZGV4X2F0dHIobm9k
ZV9uYW1lLCBpbmRleCwgYXR0cl9zdWZmaXgpOwo+ICsJaWYgKGVycikKPiAgIAkJcmV0dXJuIGVy
cjsKPiAtCX0KPgo+ICAgCWF0dHJfbmFtZSA9IGNvbnZlcnRfb3BhbF9hdHRyX25hbWUodHlwZSwg
YXR0cl9zdWZmaXgpOwo+ICAgCWlmICghYXR0cl9uYW1lKQo+ICAgCQlyZXR1cm4gLUVOT0VOVDsK
Pgo+IC0Jc25wcmludGYoaHdtb25fYXR0cl9uYW1lLCBNQVhfQVRUUl9MRU4sICIlcyVkXyVzIiwK
PiAtCQkgc2Vuc29yX2dyb3Vwc1t0eXBlXS5uYW1lLCBpbmRleCwgYXR0cl9uYW1lKTsKPiArCSpo
d21vbl9hdHRyX25hbWUgPSBhdHRyX25hbWU7Cj4gICAJcmV0dXJuIDA7Cj4gICB9Cj4KPiBAQCAt
MjUyLDYgKzI0Niw5IEBAIHN0YXRpYyBpbnQgY3JlYXRlX2RldmljZV9hdHRycyhzdHJ1Y3QgcGxh
dGZvcm1fZGV2aWNlICpwZGV2KQo+ICAgCX0KPgo+ICAgCWZvcl9lYWNoX2NoaWxkX29mX25vZGUo
b3BhbCwgbnApIHsKPiArCQljb25zdCBjaGFyICphdHRyX25hbWU7Cj4gKwkJdTMyIG9wYWxfaW5k
ZXg7Cj4gKwo+ICAgCQlpZiAobnAtPm5hbWUgPT0gTlVMTCkKPiAgIAkJCWNvbnRpbnVlOwo+Cj4g
QEAgLTI2OCwxMCArMjY1LDE3IEBAIHN0YXRpYyBpbnQgY3JlYXRlX2RldmljZV9hdHRycyhzdHJ1
Y3QgcGxhdGZvcm1fZGV2aWNlICpwZGV2KQo+Cj4gICAJCXNkYXRhW2NvdW50XS5pZCA9IHNlbnNv
cl9pZDsKPiAgIAkJc2RhdGFbY291bnRdLnR5cGUgPSB0eXBlOwo+IC0JCWVyciA9IGNyZWF0ZV9o
d21vbl9hdHRyX25hbWUoJnBkZXYtPmRldiwgdHlwZSwgbnAtPm5hbWUsCj4gLQkJCQkJICAgICBz
ZGF0YVtjb3VudF0ubmFtZSk7Cj4gLQkJaWYgKGVycikKPiArCj4gKwkJZXJyID0gcGFyc2Vfb3Bh
bF9ub2RlX25hbWUobnAtPm5hbWUsIHR5cGUsICZvcGFsX2luZGV4LAo+ICsJCQkJCSAgICZhdHRy
X25hbWUpOwo+ICsJCWlmIChlcnIpIHsKPiArCQkJZGV2X2VycigmcGRldi0+ZGV2LCAiU2Vuc29y
IGRldmljZSBub2RlIG5hbWUgJyVzJyBpcyBpbnZhbGlkXG4iLAo+ICsJCQkJbnAtPm5hbWUpOwo+
ICAgCQkJZ290byBleGl0X3B1dF9ub2RlOwo+ICsJCX0KPiArCj4gKwkJc25wcmludGYoc2RhdGFb
Y291bnRdLm5hbWUsIE1BWF9BVFRSX0xFTiwgIiVzJWRfJXMiLAo+ICsJCQkgc2Vuc29yX2dyb3Vw
c1t0eXBlXS5uYW1lLCBvcGFsX2luZGV4LCBhdHRyX25hbWUpOwo+Cj4gICAJCXN5c2ZzX2F0dHJf
aW5pdCgmc2RhdGFbY291bnRdLmRldl9hdHRyLmF0dHIpOwo+ICAgCQlzZGF0YVtjb3VudF0uZGV2
X2F0dHIuYXR0ci5uYW1lID0gc2RhdGFbY291bnRdLm5hbWU7Cj4KCgpfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpsbS1zZW5zb3JzIG1haWxpbmcgbGlzdAps
bS1zZW5zb3JzQGxtLXNlbnNvcnMub3JnCmh0dHA6Ly9saXN0cy5sbS1zZW5zb3JzLm9yZy9tYWls
bWFuL2xpc3RpbmZvL2xtLXNlbnNvcnM

Re: [PATCH 4/5] hwmon: (ibmpowernv) change create_hwmon_attr_name() prototype

[Guenter Roeck]

On 03/18/2015 08:47 AM, Cédric Le Goater wrote:
> It simplifies the creation of the hwmon attributes and will help when
> support for a new device tree layout is added. The patch also changes
> the name of the routine to parse_opal_node_name().
>
> Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>
> ---
>   drivers/hwmon/ibmpowernv.c |   32 ++++++++++++++++++--------------
>   1 file changed, 18 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/hwmon/ibmpowernv.c b/drivers/hwmon/ibmpowernv.c
> index edcc4ffa5ad0..570d2360b698 100644
> --- a/drivers/hwmon/ibmpowernv.c
> +++ b/drivers/hwmon/ibmpowernv.c
> @@ -155,28 +155,22 @@ static const char *convert_opal_attr_name(enum sensors type,
>    * which need to be mapped as fan2_input, temp1_max respectively before
>    * populating them inside hwmon device class.
>    */
> -static int create_hwmon_attr_name(struct device *dev, enum sensors type,
> -					 const char *node_name,
> -					 char *hwmon_attr_name)
> +static int parse_opal_node_name(const char *node_name, enum sensors type,
> +	u32 *index, const char **hwmon_attr_name)
>   {

Please have the function return const char * and merge the error code with ERR_PTR.

>   	char attr_suffix[MAX_ATTR_LEN];
>   	const char *attr_name;
> -	u32 index;
>   	int err;
>
> -	err = get_sensor_index_attr(node_name, &index, attr_suffix);
> -	if (err) {
> -		dev_err(dev, "Sensor device node name '%s' is invalid\n",
> -			node_name);
> +	err = get_sensor_index_attr(node_name, index, attr_suffix);
> +	if (err)
>   		return err;
> -	}
>
>   	attr_name = convert_opal_attr_name(type, attr_suffix);
>   	if (!attr_name)
>   		return -ENOENT;
>
> -	snprintf(hwmon_attr_name, MAX_ATTR_LEN, "%s%d_%s",
> -		 sensor_groups[type].name, index, attr_name);
> +	*hwmon_attr_name = attr_name;
>   	return 0;
>   }
>
> @@ -252,6 +246,9 @@ static int create_device_attrs(struct platform_device *pdev)
>   	}
>
>   	for_each_child_of_node(opal, np) {
> +		const char *attr_name;
> +		u32 opal_index;
> +
>   		if (np->name == NULL)
>   			continue;
>
> @@ -268,10 +265,17 @@ static int create_device_attrs(struct platform_device *pdev)
>
>   		sdata[count].id = sensor_id;
>   		sdata[count].type = type;
> -		err = create_hwmon_attr_name(&pdev->dev, type, np->name,
> -					     sdata[count].name);
> -		if (err)
> +
> +		err = parse_opal_node_name(np->name, type, &opal_index,
> +					   &attr_name);
> +		if (err) {
> +			dev_err(&pdev->dev, "Sensor device node name '%s' is invalid\n",
> +				np->name);
>   			goto exit_put_node;
> +		}
> +
> +		snprintf(sdata[count].name, MAX_ATTR_LEN, "%s%d_%s",
> +			 sensor_groups[type].name, opal_index, attr_name);
>
>   		sysfs_attr_init(&sdata[count].dev_attr.attr);
>   		sdata[count].dev_attr.attr.name = sdata[count].name;
>

[lm-sensors] [PATCH 5/5] hwmon: (ibmpowernv) do not use the OPAL index for hwmon attribute names

[Cédric Le Goater]

VGhlIGN1cnJlbnQgT1BBTCBmaXJtd2FyZSBleHBvc2VzIHRoZSBkaWZmZXJlbnQgc2Vuc29ycyBv
ZiBhbiBJQk0gUG93ZXIKc3lzdGVtIHVzaW5nIHRoZSBub2RlIG5hbWVzIHN1Y2ggYXMgOgoKCXNl
bnNvcnMvYW1iLXRlbXAjMS1kYXRhCglzZW5zb3JzL2FtYi10ZW1wIzEtdGhycwoJY29vbGluZy1m
YW4jMS1kYXRhCgljb29saW5nLWZhbiMxLWZhdWx0ZWQKCWNvb2xpbmctZmFuIzEtdGhycwoJY29v
bGluZy1mYW4jMi1kYXRhCgkuLi4KClRoZSBpYm1wb3dlcm52IGRyaXZlciwgd2hlbiBsb2FkZWQs
IHBhcnNlcyB0aGVzZSBuYW1lcyB0byBleHRyYWN0IHRoZQpzZW5zb3IgaW5kZXggYW5kIHRoZSBz
ZW5zb3IgYXR0cmlidXRlIG5hbWUuIFVuZm9ydHVuYXRlbHksIHRoaXMgc2NoZW1lCm1ha2VzIGl0
IGRpZmZpY3VsdCB0byBhZGQgc2Vuc29ycyB3aXRoIGEgZGlmZmVyZW50IGxheW91dCAoc3BlY2lh
bGx5IG9mCnRoZSBzYW1lIHR5cGUsIGxpa2UgdGVtcGVyYXR1cmUpIGFzIHRoZSBzZW5zb3IgaW5k
ZXggY2FsY3VsYXRlZCBpbiBPUEFMCmlzIGRpcmVjdGx5IHVzZWQgaW4gdGhlIGh3bW9uIHN5c2Zz
IGludGVyZmFjZS4KCldoYXQgdGhpcyBwYXRjaCBkb2VzIGlzIGFkZCBhIGluZGVwZW5kZW50IGh3
bW9uIGluZGV4IGZvciBlYWNoIHNlbnNvci4KVGhlIGluY3JlbWVudCBvZiB0aGUgaHdtb24gaW5k
ZXggKHRlbXAsIGZhbiwgcG93ZXIsIGV0Yy4pIGlzIGtlcHQgcGVyCnNlbnNvciB0eXBlIGluIHRo
ZSBzZW5zb3JfZ3JvdXAgdGFibGUuIFRoZSBzZW5zb3JfZGF0YSB0YWJsZSBpcyB1c2VkCnRvIHN0
b3JlIHRoZSBhc3NvY2lhdGlvbiBvZiB0aGUgaHdtb24gYW5kIE9QQUwgaW5kZXhlcywgYXMgd2Ug
bmVlZCB0bwpoYXZlIHRoZSBzYW1lIGh3bW9uIGluZGV4IGZvciBkaWZmZXJlbnQgYXR0cmlidXRl
cyBvZiBhIHNhbWUgc2Vuc29yLgoKU2lnbmVkLW9mZi1ieTogQ8OpZHJpYyBMZSBHb2F0ZXIgPGNs
Z0Bmci5pYm0uY29tPgotLS0KIGRyaXZlcnMvaHdtb24vaWJtcG93ZXJudi5jIHwgICAyMyArKysr
KysrKysrKysrKysrKysrKysrLQogMSBmaWxlIGNoYW5nZWQsIDIyIGluc2VydGlvbnMoKyksIDEg
ZGVsZXRpb24oLSkKCmRpZmYgLS1naXQgYS9kcml2ZXJzL2h3bW9uL2libXBvd2VybnYuYyBiL2Ry
aXZlcnMvaHdtb24vaWJtcG93ZXJudi5jCmluZGV4IDU3MGQyMzYwYjY5OC4uZmZjZWJjOWQ4YmY1
IDEwMDY0NAotLS0gYS9kcml2ZXJzL2h3bW9uL2libXBvd2VybnYuYworKysgYi9kcml2ZXJzL2h3
bW9uL2libXBvd2VybnYuYwpAQCAtNTUsNiArNTUsNyBAQCBzdGF0aWMgc3RydWN0IHNlbnNvcl9n
cm91cCB7CiAJY29uc3QgY2hhciAqY29tcGF0aWJsZTsKIAlzdHJ1Y3QgYXR0cmlidXRlX2dyb3Vw
IGdyb3VwOwogCXUzMiBhdHRyX2NvdW50OworCXUzMiBod21vbl9pbmRleDsKIH0gc2Vuc29yX2dy
b3Vwc1tdID0gewogCXsiZmFuIiwgImlibSxvcGFsLXNlbnNvci1jb29saW5nLWZhbiJ9LAogCXsi
dGVtcCIsICJpYm0sb3BhbC1zZW5zb3ItYW1iLXRlbXAifSwKQEAgLTY0LDYgKzY1LDggQEAgc3Rh
dGljIHN0cnVjdCBzZW5zb3JfZ3JvdXAgewogCiBzdHJ1Y3Qgc2Vuc29yX2RhdGEgewogCXUzMiBp
ZDsgLyogQW4gb3BhcXVlIGlkIG9mIHRoZSBmaXJtd2FyZSBmb3IgZWFjaCBzZW5zb3IgKi8KKwl1
MzIgaHdtb25faW5kZXg7CisJdTMyIG9wYWxfaW5kZXg7CiAJZW51bSBzZW5zb3JzIHR5cGU7CiAJ
Y2hhciBuYW1lW01BWF9BVFRSX0xFTl07CiAJc3RydWN0IGRldmljZV9hdHRyaWJ1dGUgZGV2X2F0
dHI7CkBAIC0xODUsNiArMTg4LDE5IEBAIHN0YXRpYyBpbnQgZ2V0X3NlbnNvcl90eXBlKHN0cnVj
dCBkZXZpY2Vfbm9kZSAqbnApCiAJcmV0dXJuIE1BWF9TRU5TT1JfVFlQRTsKIH0KIAorc3RhdGlj
IHUzMiBnZXRfc2Vuc29yX2h3bW9uX2luZGV4KHN0cnVjdCBzZW5zb3JfZGF0YSAqc2RhdGEsCisJ
c3RydWN0IHNlbnNvcl9kYXRhICpzZGF0YV90YWJsZSwgaW50IGNvdW50KQoreworCWludCBpOwor
CisJZm9yIChpID0gMDsgaSA8IGNvdW50OyBpKyspCisJCWlmIChzZGF0YV90YWJsZVtpXS5vcGFs
X2luZGV4ID09IHNkYXRhLT5vcGFsX2luZGV4ICYmCisJCSAgICBzZGF0YV90YWJsZVtpXS50eXBl
ID09IHNkYXRhLT50eXBlKQorCQkJcmV0dXJuIHNkYXRhX3RhYmxlW2ldLmh3bW9uX2luZGV4Owor
CisJcmV0dXJuICsrc2Vuc29yX2dyb3Vwc1tzZGF0YS0+dHlwZV0uaHdtb25faW5kZXg7Cit9CisK
IHN0YXRpYyBpbnQgcG9wdWxhdGVfYXR0cl9ncm91cHMoc3RydWN0IHBsYXRmb3JtX2RldmljZSAq
cGRldikKIHsKIAlzdHJ1Y3QgcGxhdGZvcm1fZGF0YSAqcGRhdGEgPSBwbGF0Zm9ybV9nZXRfZHJ2
ZGF0YShwZGV2KTsKQEAgLTI3NCw4ICsyOTAsMTMgQEAgc3RhdGljIGludCBjcmVhdGVfZGV2aWNl
X2F0dHJzKHN0cnVjdCBwbGF0Zm9ybV9kZXZpY2UgKnBkZXYpCiAJCQlnb3RvIGV4aXRfcHV0X25v
ZGU7CiAJCX0KIAorCQlzZGF0YVtjb3VudF0ub3BhbF9pbmRleCA9IG9wYWxfaW5kZXg7CisJCXNk
YXRhW2NvdW50XS5od21vbl9pbmRleCA9CisJCQlnZXRfc2Vuc29yX2h3bW9uX2luZGV4KCZzZGF0
YVtjb3VudF0sIHNkYXRhLCBjb3VudCk7CisKIAkJc25wcmludGYoc2RhdGFbY291bnRdLm5hbWUs
IE1BWF9BVFRSX0xFTiwgIiVzJWRfJXMiLAotCQkJIHNlbnNvcl9ncm91cHNbdHlwZV0ubmFtZSwg
b3BhbF9pbmRleCwgYXR0cl9uYW1lKTsKKwkJCSBzZW5zb3JfZ3JvdXBzW3R5cGVdLm5hbWUsIHNk
YXRhW2NvdW50XS5od21vbl9pbmRleCwKKwkJCSBhdHRyX25hbWUpOwogCiAJCXN5c2ZzX2F0dHJf
aW5pdCgmc2RhdGFbY291bnRdLmRldl9hdHRyLmF0dHIpOwogCQlzZGF0YVtjb3VudF0uZGV2X2F0
dHIuYXR0ci5uYW1lID0gc2RhdGFbY291bnRdLm5hbWU7Ci0tIAoxLjcuMTAuNAoKCl9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmxtLXNlbnNvcnMgbWFpbGlu
ZyBsaXN0CmxtLXNlbnNvcnNAbG0tc2Vuc29ycy5vcmcKaHR0cDovL2xpc3RzLmxtLXNlbnNvcnMu
b3JnL21haWxtYW4vbGlzdGluZm8vbG0tc2Vuc29ycw=

[PATCH 5/5] hwmon: (ibmpowernv) do not use the OPAL index for hwmon attribute names

[Cédric Le Goater]

The current OPAL firmware exposes the different sensors of an IBM Power
system using the node names such as :

	sensors/amb-temp#1-data
	sensors/amb-temp#1-thrs
	cooling-fan#1-data
	cooling-fan#1-faulted
	cooling-fan#1-thrs
	cooling-fan#2-data
	...

The ibmpowernv driver, when loaded, parses these names to extract the
sensor index and the sensor attribute name. Unfortunately, this scheme
makes it difficult to add sensors with a different layout (specially of
the same type, like temperature) as the sensor index calculated in OPAL
is directly used in the hwmon sysfs interface.

What this patch does is add a independent hwmon index for each sensor.
The increment of the hwmon index (temp, fan, power, etc.) is kept per
sensor type in the sensor_group table. The sensor_data table is used
to store the association of the hwmon and OPAL indexes, as we need to
have the same hwmon index for different attributes of a same sensor.

Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>
---
 drivers/hwmon/ibmpowernv.c |   23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/drivers/hwmon/ibmpowernv.c b/drivers/hwmon/ibmpowernv.c
index 570d2360b698..ffcebc9d8bf5 100644
--- a/drivers/hwmon/ibmpowernv.c
+++ b/drivers/hwmon/ibmpowernv.c
@@ -55,6 +55,7 @@ static struct sensor_group {
 	const char *compatible;
 	struct attribute_group group;
 	u32 attr_count;
+	u32 hwmon_index;
 } sensor_groups[] = {
 	{"fan", "ibm,opal-sensor-cooling-fan"},
 	{"temp", "ibm,opal-sensor-amb-temp"},
@@ -64,6 +65,8 @@ static struct sensor_group {
 
 struct sensor_data {
 	u32 id; /* An opaque id of the firmware for each sensor */
+	u32 hwmon_index;
+	u32 opal_index;
 	enum sensors type;
 	char name[MAX_ATTR_LEN];
 	struct device_attribute dev_attr;
@@ -185,6 +188,19 @@ static int get_sensor_type(struct device_node *np)
 	return MAX_SENSOR_TYPE;
 }
 
+static u32 get_sensor_hwmon_index(struct sensor_data *sdata,
+	struct sensor_data *sdata_table, int count)
+{
+	int i;
+
+	for (i = 0; i < count; i++)
+		if (sdata_table[i].opal_index == sdata->opal_index &&
+		    sdata_table[i].type == sdata->type)
+			return sdata_table[i].hwmon_index;
+
+	return ++sensor_groups[sdata->type].hwmon_index;
+}
+
 static int populate_attr_groups(struct platform_device *pdev)
 {
 	struct platform_data *pdata = platform_get_drvdata(pdev);
@@ -274,8 +290,13 @@ static int create_device_attrs(struct platform_device *pdev)
 			goto exit_put_node;
 		}
 
+		sdata[count].opal_index = opal_index;
+		sdata[count].hwmon_index =
+			get_sensor_hwmon_index(&sdata[count], sdata, count);
+
 		snprintf(sdata[count].name, MAX_ATTR_LEN, "%s%d_%s",
-			 sensor_groups[type].name, opal_index, attr_name);
+			 sensor_groups[type].name, sdata[count].hwmon_index,
+			 attr_name);
 
 		sysfs_attr_init(&sdata[count].dev_attr.attr);
 		sdata[count].dev_attr.attr.name = sdata[count].name;
-- 
1.7.10.4

[lm-sensors] [PATCH v2 0/5] hwmon: (ibmpowernv) remove dependency on OPAL index

[Cédric Le Goater]

SGVsbG8gIQoKVGhlIGN1cnJlbnQgaW1wbGVtZW50YXRpb24gb2YgdGhlIGRyaXZlciB1c2VzIGFu
IGluZGV4IGZvciB0aGUgaHdtb24gCmF0dHJpYnV0ZSB3aGljaCBpcyBleHRyYWN0ZWQgZnJvbSB0
aGUgZGV2aWNlIG5vZGUgbmFtZS4gVGhpcyBpbmRleAppcyBjYWxjdWxhdGVkIGJ5IHRoZSBPUEFM
IGZpcm13YXJlIGFuZCBpdHMgdXNhZ2UgY3JlYXRlcyBhIGRlcGVuZGVuY3kgCndpdGggdGhlIGRy
aXZlciB3aGljaCBtYWtlcyBjaGFuZ2VzIGEgbGl0dGxlIG1vcmUgY29tcGxleCBpbiBPUEFMLgoK
VGhpcyBwYXRjaHNldCBjaGFuZ2VzIHRoZSBpYm1wb3dlcm52IGNvZGUgdG8gdXNlIGl0cyBvd24g
aW5kZXguIEl0IApzdGFydHMgd2l0aCBhIGZldyBjbGVhbnVwcywgbW9zdGx5IGNvZGUgc2h1ZmZs
aW5nIGFyb3VuZCB0aGUgY3JlYXRpb24gCm9mIHRoZSBod21vbiBzeXNmcyBhdHRyaWJ1dGVzIGFu
ZCBjb21wbGV0ZXMgYnkgcmVtb3ZpbmcgdGhlIGRlcGVuZGVuY3kuCgpJdCBhbHNvIHByZXBhcmVz
IGdyb3VuZCBmb3IgZnV0dXJlIE9QQUwgY2hhbmdlcyA6ICAKCiAgIGh0dHBzOi8vbGlzdHMub3ps
YWJzLm9yZy9waXBlcm1haWwvc2tpYm9vdC8yMDE1LU1hcmNoLzAwMDYzOS5odG1sCgp3aGljaCB3
aWxsIGJlIGFkZHJlc3NlZCBpbiBhIG90aGVyIHNtYWxsIHBhdGNoc2V0LgoKClRoZSBwYXRjaGVz
IGFyZSBiYXNlZCBvbiBMaW51eCA0LjAuMC1yYzQgYW5kIHdlcmUgdGVzdGVkIG9uIElCTSBQb3dl
ciAKYW5kIE9wZW4gUG93ZXIgc3lzdGVtcyBydW5uaW5nIFRydXN0eS4gCgpDaGVlcnMsCgpDLgoK
CkNoYW5nZXMgc2luY2UgdjE6CgogLSBmaXhlZCBhbGlnbm1lbnQKIC0ga2lsbGVkIGEgY291cGxl
IG9mIHVzZWxlc3MgInJldHVybiBOVUxMIgogLSBjaGFuZ2VkIHJldHVybmVkIHZhbHVlIG9mIHBh
cnNlX29wYWxfbm9kZV9uYW1lKCkKIC0gdXNlZCAqX1BUUiBtYWNyb3MgdG8gY2hlY2sgZm9yIGVy
cm9ycwoKQ8OpZHJpYyBMZSBHb2F0ZXIgKDUpOgogIGh3bW9uOiAoaWJtcG93ZXJudikgcmVwbGFj
ZSBBTUJJRU5UX1RFTVAgYnkgVEVNUAogIGh3bW9uOiAoaWJtcG93ZXJudikgYWRkIGEgZ2V0X3Nl
bnNvcl90eXBlKCkgcm91dGluZQogIGh3bW9uOiAoaWJtcG93ZXJudikgYWRkIGEgY29udmVydF9v
cGFsX2F0dHJfbmFtZSgpIHJvdXRpbmUKICBod21vbjogKGlibXBvd2VybnYpIGNoYW5nZSBjcmVh
dGVfaHdtb25fYXR0cl9uYW1lKCkgcHJvdG90eXBlCiAgaHdtb246IChpYm1wb3dlcm52KSBkbyBu
b3QgdXNlIHRoZSBPUEFMIGluZGV4IGZvciBod21vbiBhdHRyaWJ1dGUKICAgIG5hbWVzCgogZHJp
dmVycy9od21vbi9pYm1wb3dlcm52LmMgfCAgMTIyICsrKysrKysrKysrKysrKysrKysrKysrKysr
KysrLS0tLS0tLS0tLS0tLS0tCiAxIGZpbGUgY2hhbmdlZCwgODEgaW5zZXJ0aW9ucygrKSwgNDEg
ZGVsZXRpb25zKC0pCgotLSAKMS43LjEwLjQKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXwpsbS1zZW5zb3JzIG1haWxpbmcgbGlzdApsbS1zZW5zb3JzQGxt
LXNlbnNvcnMub3JnCmh0dHA6Ly9saXN0cy5sbS1zZW5zb3JzLm9yZy9tYWlsbWFuL2xpc3RpbmZv
L2xtLXNlbnNvcnM

[PATCH v2 0/5] hwmon: (ibmpowernv) remove dependency on OPAL index

[Cédric Le Goater]

Hello !

The current implementation of the driver uses an index for the hwmon 
attribute which is extracted from the device node name. This index
is calculated by the OPAL firmware and its usage creates a dependency 
with the driver which makes changes a little more complex in OPAL.

This patchset changes the ibmpowernv code to use its own index. It 
starts with a few cleanups, mostly code shuffling around the creation 
of the hwmon sysfs attributes and completes by removing the dependency.

It also prepares ground for future OPAL changes :  

   https://lists.ozlabs.org/pipermail/skiboot/2015-March/000639.html

which will be addressed in a other small patchset.


The patches are based on Linux 4.0.0-rc4 and were tested on IBM Power 
and Open Power systems running Trusty. 

Cheers,

C.


Changes since v1:

 - fixed alignment
 - killed a couple of useless "return NULL"
 - changed returned value of parse_opal_node_name()
 - used *_PTR macros to check for errors

Cédric Le Goater (5):
  hwmon: (ibmpowernv) replace AMBIENT_TEMP by TEMP
  hwmon: (ibmpowernv) add a get_sensor_type() routine
  hwmon: (ibmpowernv) add a convert_opal_attr_name() routine
  hwmon: (ibmpowernv) change create_hwmon_attr_name() prototype
  hwmon: (ibmpowernv) do not use the OPAL index for hwmon attribute
    names

 drivers/hwmon/ibmpowernv.c |  122 +++++++++++++++++++++++++++++---------------
 1 file changed, 81 insertions(+), 41 deletions(-)

-- 
1.7.10.4

Re: [lm-sensors] [PATCH v2 0/5] hwmon: (ibmpowernv) remove dependency on OPAL index

[Guenter Roeck]

On Thu, Mar 19, 2015 at 06:44:40PM +0100, Cédric Le Goater wrote:
> Hello !
> 
> The current implementation of the driver uses an index for the hwmon 
> attribute which is extracted from the device node name. This index
> is calculated by the OPAL firmware and its usage creates a dependency 
> with the driver which makes changes a little more complex in OPAL.
> 
> This patchset changes the ibmpowernv code to use its own index. It 
> starts with a few cleanups, mostly code shuffling around the creation 
> of the hwmon sysfs attributes and completes by removing the dependency.
> 
Series applied to hwmon-next (with patch #4 fixed up).

Thanks,
Guenter

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [PATCH v2 0/5] hwmon: (ibmpowernv) remove dependency on OPAL index

[Guenter Roeck]

On Thu, Mar 19, 2015 at 06:44:40PM +0100, Cédric Le Goater wrote:
> Hello !
> 
> The current implementation of the driver uses an index for the hwmon 
> attribute which is extracted from the device node name. This index
> is calculated by the OPAL firmware and its usage creates a dependency 
> with the driver which makes changes a little more complex in OPAL.
> 
> This patchset changes the ibmpowernv code to use its own index. It 
> starts with a few cleanups, mostly code shuffling around the creation 
> of the hwmon sysfs attributes and completes by removing the dependency.
> 
Series applied to hwmon-next (with patch #4 fixed up).

Thanks,
Guenter

Re: [lm-sensors] [PATCH v2 0/5] hwmon: (ibmpowernv) remove dependency on OPAL index

[Cedric Le Goater]

On 03/20/2015 04:26 PM, Guenter Roeck wrote:
> On Thu, Mar 19, 2015 at 06:44:40PM +0100, Cédric Le Goater wrote:
>> Hello !
>>
>> The current implementation of the driver uses an index for the hwmon 
>> attribute which is extracted from the device node name. This index
>> is calculated by the OPAL firmware and its usage creates a dependency 
>> with the driver which makes changes a little more complex in OPAL.
>>
>> This patchset changes the ibmpowernv code to use its own index. It 
>> starts with a few cleanups, mostly code shuffling around the creation 
>> of the hwmon sysfs attributes and completes by removing the dependency.
>>
> Series applied to hwmon-next (with patch #4 fixed up).

Thanks !

C.


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [PATCH v2 0/5] hwmon: (ibmpowernv) remove dependency on OPAL index

[Cedric Le Goater]

On 03/20/2015 04:26 PM, Guenter Roeck wrote:
> On Thu, Mar 19, 2015 at 06:44:40PM +0100, Cédric Le Goater wrote:
>> Hello !
>>
>> The current implementation of the driver uses an index for the hwmon 
>> attribute which is extracted from the device node name. This index
>> is calculated by the OPAL firmware and its usage creates a dependency 
>> with the driver which makes changes a little more complex in OPAL.
>>
>> This patchset changes the ibmpowernv code to use its own index. It 
>> starts with a few cleanups, mostly code shuffling around the creation 
>> of the hwmon sysfs attributes and completes by removing the dependency.
>>
> Series applied to hwmon-next (with patch #4 fixed up).

Thanks !

C.

[lm-sensors] [PATCH 0/4] hwmon: (ibmpowernv) add DTS support

[Cédric Le Goater]

SGVsbG8gIQoKVGhlc2UgcGF0Y2hlcyBleHRlbmQgdGhlIGlibXBvd2VybnYgZHJpdmVyIHRvIHN1
cHBvcnQgdGhlIG5ldyBPUEFMIGZpcm13YXJlIAp3aGljaCBub3cgZXhwb3NlcyBpbiBpdHMgZGV2
aWNlIHRyZWUgdGhlIERpZ2l0YWwgVGVtcGVyYXR1cmUgU2Vuc29ycyBvZiAKYSBQOCBzeXN0ZW0u
CgpUaGV5IGFyZSBiYXNlZCBvbiBMaW51eCA0LjAuMC1yYzYgKyB0aGUgaW5pdGlhbCBjbGVhbnVw
IHNlcmllIDoKCiAgICAgaHR0cDovL2xpc3RzLmxtLXNlbnNvcnMub3JnL3BpcGVybWFpbC9sbS1z
ZW5zb3JzLzIwMTUtTWFyY2gvMDQzNjcwLmh0bWwKCmFuZCB3ZXJlIHRlc3RlZCBvbiBJQk0gUG93
ZXIgYW5kIE9wZW4gUG93ZXIgc3lzdGVtcyBydW5uaW5nIFRydXN0eS4KCkNoZWVycywKCkMuCgpD
w6lkcmljIExlIEdvYXRlciAoNCk6CiAgaHdtb246IChpYm1wb3dlcm52KSBhZGQgYSBoZWxwZXIg
cm91dGluZSBjcmVhdGVfaHdtb25fYXR0cgogIGh3bW9uOiAoaWJtcG93ZXJudikgYWRkIHN1cHBv
cnQgZm9yIHRoZSBuZXcgZGV2aWNlIHRyZWUKICBod21vbjogKGlibXBvd2VybnYpIGFkZCBhIGxh
YmVsIGF0dHJpYnV0ZQogIGh3bW9uOiAoaWJtcG93ZXJudikgcHJldHR5IHByaW50IGxhYmVscwoK
IGRyaXZlcnMvaHdtb24vaWJtcG93ZXJudi5jIHwgIDE0MyArKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysrKysrKy0tLS0tLQogMSBmaWxlIGNoYW5nZWQsIDEyNSBpbnNlcnRpb25zKCsp
LCAxOCBkZWxldGlvbnMoLSkKCi0tIAoxLjcuMTAuNAoKCl9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fCmxtLXNlbnNvcnMgbWFpbGluZyBsaXN0CmxtLXNlbnNv
cnNAbG0tc2Vuc29ycy5vcmcKaHR0cDovL2xpc3RzLmxtLXNlbnNvcnMub3JnL21haWxtYW4vbGlz
dGluZm8vbG0tc2Vuc29ycw=

[PATCH 0/4] hwmon: (ibmpowernv) add DTS support

[Cédric Le Goater]

Hello !

These patches extend the ibmpowernv driver to support the new OPAL firmware 
which now exposes in its device tree the Digital Temperature Sensors of 
a P8 system.

They are based on Linux 4.0.0-rc6 + the initial cleanup serie :

     http://lists.lm-sensors.org/pipermail/lm-sensors/2015-March/043670.html

and were tested on IBM Power and Open Power systems running Trusty.

Cheers,

C.

Cédric Le Goater (4):
  hwmon: (ibmpowernv) add a helper routine create_hwmon_attr
  hwmon: (ibmpowernv) add support for the new device tree
  hwmon: (ibmpowernv) add a label attribute
  hwmon: (ibmpowernv) pretty print labels

 drivers/hwmon/ibmpowernv.c |  143 ++++++++++++++++++++++++++++++++++++++------
 1 file changed, 125 insertions(+), 18 deletions(-)

-- 
1.7.10.4

[lm-sensors] [PATCH 1/4] hwmon: (ibmpowernv) add a helper routine create_hwmon_attr

[Cédric Le Goater]

VGhpcyBzaG91bGQgc2hvcnRlbiBhIGJpdCB0aGUgY29kZSBuZWNlc3NhcnkgdG8gY3JlYXRlIGEg
aG13b24gYXR0cmlidXRlLgoKU2lnbmVkLW9mZi1ieTogQ8OpZHJpYyBMZSBHb2F0ZXIgPGNsZ0Bm
ci5pYm0uY29tPgotLS0KIGRyaXZlcnMvaHdtb24vaWJtcG93ZXJudi5jIHwgICAyMyArKysrKysr
KysrKysrKystLS0tLS0tLQogMSBmaWxlIGNoYW5nZWQsIDE1IGluc2VydGlvbnMoKyksIDggZGVs
ZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvZHJpdmVycy9od21vbi9pYm1wb3dlcm52LmMgYi9kcml2
ZXJzL2h3bW9uL2libXBvd2VybnYuYwppbmRleCBhNmU3MjQ1ZjE3MmQuLmM5YWE0ZDgzN2M2ZiAx
MDA2NDQKLS0tIGEvZHJpdmVycy9od21vbi9pYm1wb3dlcm52LmMKKysrIGIvZHJpdmVycy9od21v
bi9pYm1wb3dlcm52LmMKQEAgLTIzMiw2ICsyMzIsMjAgQEAgc3RhdGljIGludCBwb3B1bGF0ZV9h
dHRyX2dyb3VwcyhzdHJ1Y3QgcGxhdGZvcm1fZGV2aWNlICpwZGV2KQogCXJldHVybiAwOwogfQog
CitzdGF0aWMgdm9pZCBjcmVhdGVfaHdtb25fYXR0cihzdHJ1Y3Qgc2Vuc29yX2RhdGEgKnNkYXRh
LCBjb25zdCBjaGFyICphdHRyX25hbWUsCisJc3NpemVfdCAoKnNob3cpKHN0cnVjdCBkZXZpY2Ug
KmRldiwgc3RydWN0IGRldmljZV9hdHRyaWJ1dGUgKmF0dHIsCisJCQljaGFyICpidWYpKQorewor
CXNucHJpbnRmKHNkYXRhLT5uYW1lLCBNQVhfQVRUUl9MRU4sICIlcyVkXyVzIiwKKwkJIHNlbnNv
cl9ncm91cHNbc2RhdGEtPnR5cGVdLm5hbWUsIHNkYXRhLT5od21vbl9pbmRleCwKKwkJIGF0dHJf
bmFtZSk7CisKKwlzeXNmc19hdHRyX2luaXQoJnNkYXRhLT5kZXZfYXR0ci5hdHRyKTsKKwlzZGF0
YS0+ZGV2X2F0dHIuYXR0ci5uYW1lID0gc2RhdGEtPm5hbWU7CisJc2RhdGEtPmRldl9hdHRyLmF0
dHIubW9kZSA9IFNfSVJVR087CisJc2RhdGEtPmRldl9hdHRyLnNob3cgPSBzaG93OworfQorCiAv
KgogICogSXRlcmF0ZSB0aHJvdWdoIHRoZSBkZXZpY2UgdHJlZSBmb3IgZWFjaCBjaGlsZCBvZiAn
c2Vuc29ycycgbm9kZSwgY3JlYXRlCiAgKiBhIHN5c2ZzIGF0dHJpYnV0ZSBmaWxlLCB0aGUgZmls
ZSBpcyBuYW1lZCBieSB0cmFuc2xhdGluZyB0aGUgRFQgbm9kZSBuYW1lCkBAIC0yOTAsMTQgKzMw
NCw3IEBAIHN0YXRpYyBpbnQgY3JlYXRlX2RldmljZV9hdHRycyhzdHJ1Y3QgcGxhdGZvcm1fZGV2
aWNlICpwZGV2KQogCQlzZGF0YVtjb3VudF0uaHdtb25faW5kZXggPQogCQkJZ2V0X3NlbnNvcl9o
d21vbl9pbmRleCgmc2RhdGFbY291bnRdLCBzZGF0YSwgY291bnQpOwogCi0JCXNucHJpbnRmKHNk
YXRhW2NvdW50XS5uYW1lLCBNQVhfQVRUUl9MRU4sICIlcyVkXyVzIiwKLQkJCSBzZW5zb3JfZ3Jv
dXBzW3R5cGVdLm5hbWUsIHNkYXRhW2NvdW50XS5od21vbl9pbmRleCwKLQkJCSBhdHRyX25hbWUp
OwotCi0JCXN5c2ZzX2F0dHJfaW5pdCgmc2RhdGFbY291bnRdLmRldl9hdHRyLmF0dHIpOwotCQlz
ZGF0YVtjb3VudF0uZGV2X2F0dHIuYXR0ci5uYW1lID0gc2RhdGFbY291bnRdLm5hbWU7Ci0JCXNk
YXRhW2NvdW50XS5kZXZfYXR0ci5hdHRyLm1vZGUgPSBTX0lSVUdPOwotCQlzZGF0YVtjb3VudF0u
ZGV2X2F0dHIuc2hvdyA9IHNob3dfc2Vuc29yOworCQljcmVhdGVfaHdtb25fYXR0cigmc2RhdGFb
Y291bnRdLCBhdHRyX25hbWUsIHNob3dfc2Vuc29yKTsKIAogCQlwZ3JvdXBzW3R5cGVdLT5hdHRy
c1tzZW5zb3JfZ3JvdXBzW3R5cGVdLmF0dHJfY291bnQrK10gPQogCQkJCSZzZGF0YVtjb3VudCsr
XS5kZXZfYXR0ci5hdHRyOwotLSAKMS43LjEwLjQKCgpfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXwpsbS1zZW5zb3JzIG1haWxpbmcgbGlzdApsbS1zZW5zb3Jz
QGxtLXNlbnNvcnMub3JnCmh0dHA6Ly9saXN0cy5sbS1zZW5zb3JzLm9yZy9tYWlsbWFuL2xpc3Rp
bmZvL2xtLXNlbnNvcnM

[PATCH 1/4] hwmon: (ibmpowernv) add a helper routine create_hwmon_attr

[Cédric Le Goater]

This should shorten a bit the code necessary to create a hmwon attribute.

Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>
---
 drivers/hwmon/ibmpowernv.c |   23 +++++++++++++++--------
 1 file changed, 15 insertions(+), 8 deletions(-)

diff --git a/drivers/hwmon/ibmpowernv.c b/drivers/hwmon/ibmpowernv.c
index a6e7245f172d..c9aa4d837c6f 100644
--- a/drivers/hwmon/ibmpowernv.c
+++ b/drivers/hwmon/ibmpowernv.c
@@ -232,6 +232,20 @@ static int populate_attr_groups(struct platform_device *pdev)
 	return 0;
 }
 
+static void create_hwmon_attr(struct sensor_data *sdata, const char *attr_name,
+	ssize_t (*show)(struct device *dev, struct device_attribute *attr,
+			char *buf))
+{
+	snprintf(sdata->name, MAX_ATTR_LEN, "%s%d_%s",
+		 sensor_groups[sdata->type].name, sdata->hwmon_index,
+		 attr_name);
+
+	sysfs_attr_init(&sdata->dev_attr.attr);
+	sdata->dev_attr.attr.name = sdata->name;
+	sdata->dev_attr.attr.mode = S_IRUGO;
+	sdata->dev_attr.show = show;
+}
+
 /*
  * Iterate through the device tree for each child of 'sensors' node, create
  * a sysfs attribute file, the file is named by translating the DT node name
@@ -290,14 +304,7 @@ static int create_device_attrs(struct platform_device *pdev)
 		sdata[count].hwmon_index =
 			get_sensor_hwmon_index(&sdata[count], sdata, count);
 
-		snprintf(sdata[count].name, MAX_ATTR_LEN, "%s%d_%s",
-			 sensor_groups[type].name, sdata[count].hwmon_index,
-			 attr_name);
-
-		sysfs_attr_init(&sdata[count].dev_attr.attr);
-		sdata[count].dev_attr.attr.name = sdata[count].name;
-		sdata[count].dev_attr.attr.mode = S_IRUGO;
-		sdata[count].dev_attr.show = show_sensor;
+		create_hwmon_attr(&sdata[count], attr_name, show_sensor);
 
 		pgroups[type]->attrs[sensor_groups[type].attr_count++] =
 				&sdata[count++].dev_attr.attr;
-- 
1.7.10.4

[lm-sensors] [PATCH 2/4] hwmon: (ibmpowernv) add support for the new device tree

[Cédric Le Goater]

VGhlIG5ldyBPUEFMIGRldmljZSB0cmVlIGZvciBzZW5zb3JzIGhhcyBhIGRpZmZlcmVudCBsYXlv
dXQgYW5kIHVzZXMgbmV3CnByb3BlcnR5IG5hbWVzLCBmb3IgdGhlIHR5cGUgYW5kIGZvciB0aGUg
aGFuZGxlciB1c2VkIHRvIGNhcHR1cmUgdGhlCnNlbnNvciBkYXRhLgoKVGhpcyBwYXRjaCBtb2Rp
ZmllcyB0aGUgaWJtcG93ZXJudiBkcml2ZXIgdG8gc3VwcG9ydCBzdWNoIGEgdHJlZSBpbiBhCndh
eSBwcmVzZXJ2aW5nIGNvbXBhdGliaWxpdHkgd2l0aCBvbGRlciBPUEFMIGZpcm13YXJlcy4KClRo
aXMgaXMgYWNoaWV2ZWQgYnkgY2hhbmdpbmcgdGhlIGVycm9yIHBhdGggb2YgdGhlIHJvdXRpbmUg
cGFyc2luZwphbiBPUEFMIG5vZGUgbmFtZS4gVGhlIG5vZGUgaXMgc2ltcGx5IGNvbnNpZGVyZWQg
YmVpbmcgZnJvbSB0aGUgbmV3CmRldmljZSB0cmVlIGxheW91dCBhbmQgZmFsbGJhY2sgdmFsdWVz
IGFyZSB1c2VkLgoKU2lnbmVkLW9mZi1ieTogQ8OpZHJpYyBMZSBHb2F0ZXIgPGNsZ0Bmci5pYm0u
Y29tPgotLS0KIGRyaXZlcnMvaHdtb24vaWJtcG93ZXJudi5jIHwgICA0NyArKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKy0tLS0tLS0tLQogMSBmaWxlIGNoYW5nZWQsIDM4IGluc2Vy
dGlvbnMoKyksIDkgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvZHJpdmVycy9od21vbi9pYm1w
b3dlcm52LmMgYi9kcml2ZXJzL2h3bW9uL2libXBvd2VybnYuYwppbmRleCBjOWFhNGQ4MzdjNmYu
LmYzOGFhMjczNDNmMiAxMDA2NDQKLS0tIGEvZHJpdmVycy9od21vbi9pYm1wb3dlcm52LmMKKysr
IGIvZHJpdmVycy9od21vbi9pYm1wb3dlcm52LmMKQEAgLTE3NiwxMSArMTc2LDI2IEBAIHN0YXRp
YyBjb25zdCBjaGFyICpwYXJzZV9vcGFsX25vZGVfbmFtZShjb25zdCBjaGFyICpub2RlX25hbWUs
CiBzdGF0aWMgaW50IGdldF9zZW5zb3JfdHlwZShzdHJ1Y3QgZGV2aWNlX25vZGUgKm5wKQogewog
CWVudW0gc2Vuc29ycyB0eXBlOworCWNvbnN0IGNoYXIgKnN0cjsKIAogCWZvciAodHlwZSA9IDA7
IHR5cGUgPCBNQVhfU0VOU09SX1RZUEU7IHR5cGUrKykgewogCQlpZiAob2ZfZGV2aWNlX2lzX2Nv
bXBhdGlibGUobnAsIHNlbnNvcl9ncm91cHNbdHlwZV0uY29tcGF0aWJsZSkpCiAJCQlyZXR1cm4g
dHlwZTsKIAl9CisKKwkvKgorCSAqIExldCdzIGNoZWNrIGlmIHdlIGhhdmUgYSBuZXdlciBkZXZp
Y2UgdHJlZQorCSAqLworCWlmICghb2ZfZGV2aWNlX2lzX2NvbXBhdGlibGUobnAsICJpYm0sb3Bh
bC1zZW5zb3IiKSkKKwkJcmV0dXJuIE1BWF9TRU5TT1JfVFlQRTsKKworCWlmIChvZl9wcm9wZXJ0
eV9yZWFkX3N0cmluZyhucCwgInNlbnNvci10eXBlIiwgJnN0cikpCisJCXJldHVybiBNQVhfU0VO
U09SX1RZUEU7CisKKwlmb3IgKHR5cGUgPSAwOyB0eXBlIDwgTUFYX1NFTlNPUl9UWVBFOyB0eXBl
KyspCisJCWlmICghc3RyY21wKHN0ciwgc2Vuc29yX2dyb3Vwc1t0eXBlXS5uYW1lKSkKKwkJCXJl
dHVybiB0eXBlOworCiAJcmV0dXJuIE1BWF9TRU5TT1JfVFlQRTsKIH0KIApAQCAtMTg5LDExICsy
MDQsMTYgQEAgc3RhdGljIHUzMiBnZXRfc2Vuc29yX2h3bW9uX2luZGV4KHN0cnVjdCBzZW5zb3Jf
ZGF0YSAqc2RhdGEsCiB7CiAJaW50IGk7CiAKLQlmb3IgKGkgPSAwOyBpIDwgY291bnQ7IGkrKykK
LQkJaWYgKHNkYXRhX3RhYmxlW2ldLm9wYWxfaW5kZXggPT0gc2RhdGEtPm9wYWxfaW5kZXggJiYK
LQkJICAgIHNkYXRhX3RhYmxlW2ldLnR5cGUgPT0gc2RhdGEtPnR5cGUpCi0JCQlyZXR1cm4gc2Rh
dGFfdGFibGVbaV0uaHdtb25faW5kZXg7CisJLyoKKwkgKiBXZSBkb24ndCB1c2UgdGhlIE9QQUwg
aW5kZXggb24gbmV3ZXIgZGV2aWNlIHRyZWVzCisJICovCisJaWYgKHNkYXRhLT5vcGFsX2luZGV4
ICE9IC0xKSB7CisJCWZvciAoaSA9IDA7IGkgPCBjb3VudDsgaSsrKQorCQkJaWYgKHNkYXRhX3Rh
YmxlW2ldLm9wYWxfaW5kZXggPT0gc2RhdGEtPm9wYWxfaW5kZXggJiYKKwkJCSAgICBzZGF0YV90
YWJsZVtpXS50eXBlID09IHNkYXRhLT50eXBlKQorCQkJCXJldHVybiBzZGF0YV90YWJsZVtpXS5o
d21vbl9pbmRleDsKIAorCX0KIAlyZXR1cm4gKytzZW5zb3JfZ3JvdXBzW3NkYXRhLT50eXBlXS5o
d21vbl9pbmRleDsKIH0KIApAQCAtMjgyLDcgKzMwMiwxMiBAQCBzdGF0aWMgaW50IGNyZWF0ZV9k
ZXZpY2VfYXR0cnMoc3RydWN0IHBsYXRmb3JtX2RldmljZSAqcGRldikKIAkJaWYgKHR5cGUgPT0g
TUFYX1NFTlNPUl9UWVBFKQogCQkJY29udGludWU7CiAKLQkJaWYgKG9mX3Byb3BlcnR5X3JlYWRf
dTMyKG5wLCAic2Vuc29yLWlkIiwgJnNlbnNvcl9pZCkpIHsKKwkJLyoKKwkJICogTmV3ZXIgZGV2
aWNlIHRyZWVzIHVzZSBhICJzZW5zb3ItZGF0YSIgcHJvcGVydHkKKwkJICogbmFtZSBmb3IgaW5w
dXQuCisJCSAqLworCQlpZiAob2ZfcHJvcGVydHlfcmVhZF91MzIobnAsICJzZW5zb3ItaWQiLCAm
c2Vuc29yX2lkKSAmJgorCQkgICAgb2ZfcHJvcGVydHlfcmVhZF91MzIobnAsICJzZW5zb3ItZGF0
YSIsICZzZW5zb3JfaWQpKSB7CiAJCQlkZXZfaW5mbygmcGRldi0+ZGV2LAogCQkJCSAiJ3NlbnNv
ci1pZCcgbWlzc2luZyBpbiB0aGUgbm9kZSAnJXMnXG4iLAogCQkJCSBucC0+bmFtZSk7CkBAIC0y
OTIsMTIgKzMxNywxNiBAQCBzdGF0aWMgaW50IGNyZWF0ZV9kZXZpY2VfYXR0cnMoc3RydWN0IHBs
YXRmb3JtX2RldmljZSAqcGRldikKIAkJc2RhdGFbY291bnRdLmlkID0gc2Vuc29yX2lkOwogCQlz
ZGF0YVtjb3VudF0udHlwZSA9IHR5cGU7CiAKKwkJLyoKKwkJICogSWYgd2UgY2FuIG5vdCBwYXJz
ZSB0aGUgbm9kZSBuYW1lLCBpdCBtZWFucyB3ZSBhcmUKKwkJICogcnVubmluZyBvbiBhIG5ld2Vy
IGRldmljZSB0cmVlLiBXZSBjYW4ganVzdCBmb3JnZXQKKwkJICogYWJvdXQgdGhlIE9QQUwgaW5k
ZXggYW5kIHVzZSBhIGRlZmF1dCB2YWx1ZSBmb3IgdGhlCisJCSAqIGh3bW9uIGF0dHJpYnV0ZSBu
YW1lCisJCSAqLwogCQlhdHRyX25hbWUgPSBwYXJzZV9vcGFsX25vZGVfbmFtZShucC0+bmFtZSwg
dHlwZSwgJm9wYWxfaW5kZXgpOwogCQlpZiAoSVNfRVJSKGF0dHJfbmFtZSkpIHsKLQkJCWRldl9l
cnIoJnBkZXYtPmRldiwgIlNlbnNvciBkZXZpY2Ugbm9kZSBuYW1lICclcycgaXMgaW52YWxpZFxu
IiwKLQkJCQlucC0+bmFtZSk7Ci0JCQllcnIgPSBQVFJfRVJSKGF0dHJfbmFtZSk7Ci0JCQlnb3Rv
IGV4aXRfcHV0X25vZGU7CisJCQlhdHRyX25hbWUgPSAiaW5wdXQiOworCQkJb3BhbF9pbmRleCA9
IC0xOwogCQl9CiAKIAkJc2RhdGFbY291bnRdLm9wYWxfaW5kZXggPSBvcGFsX2luZGV4OwotLSAK
MS43LjEwLjQKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
XwpsbS1zZW5zb3JzIG1haWxpbmcgbGlzdApsbS1zZW5zb3JzQGxtLXNlbnNvcnMub3JnCmh0dHA6
Ly9saXN0cy5sbS1zZW5zb3JzLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xtLXNlbnNvcnM

[PATCH 2/4] hwmon: (ibmpowernv) add support for the new device tree

[Cédric Le Goater]

The new OPAL device tree for sensors has a different layout and uses new
property names, for the type and for the handler used to capture the
sensor data.

This patch modifies the ibmpowernv driver to support such a tree in a
way preserving compatibility with older OPAL firmwares.

This is achieved by changing the error path of the routine parsing
an OPAL node name. The node is simply considered being from the new
device tree layout and fallback values are used.

Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>
---
 drivers/hwmon/ibmpowernv.c |   47 +++++++++++++++++++++++++++++++++++---------
 1 file changed, 38 insertions(+), 9 deletions(-)

diff --git a/drivers/hwmon/ibmpowernv.c b/drivers/hwmon/ibmpowernv.c
index c9aa4d837c6f..f38aa27343f2 100644
--- a/drivers/hwmon/ibmpowernv.c
+++ b/drivers/hwmon/ibmpowernv.c
@@ -176,11 +176,26 @@ static const char *parse_opal_node_name(const char *node_name,
 static int get_sensor_type(struct device_node *np)
 {
 	enum sensors type;
+	const char *str;
 
 	for (type = 0; type < MAX_SENSOR_TYPE; type++) {
 		if (of_device_is_compatible(np, sensor_groups[type].compatible))
 			return type;
 	}
+
+	/*
+	 * Let's check if we have a newer device tree
+	 */
+	if (!of_device_is_compatible(np, "ibm,opal-sensor"))
+		return MAX_SENSOR_TYPE;
+
+	if (of_property_read_string(np, "sensor-type", &str))
+		return MAX_SENSOR_TYPE;
+
+	for (type = 0; type < MAX_SENSOR_TYPE; type++)
+		if (!strcmp(str, sensor_groups[type].name))
+			return type;
+
 	return MAX_SENSOR_TYPE;
 }
 
@@ -189,11 +204,16 @@ static u32 get_sensor_hwmon_index(struct sensor_data *sdata,
 {
 	int i;
 
-	for (i = 0; i < count; i++)
-		if (sdata_table[i].opal_index == sdata->opal_index &&
-		    sdata_table[i].type == sdata->type)
-			return sdata_table[i].hwmon_index;
+	/*
+	 * We don't use the OPAL index on newer device trees
+	 */
+	if (sdata->opal_index != -1) {
+		for (i = 0; i < count; i++)
+			if (sdata_table[i].opal_index == sdata->opal_index &&
+			    sdata_table[i].type == sdata->type)
+				return sdata_table[i].hwmon_index;
 
+	}
 	return ++sensor_groups[sdata->type].hwmon_index;
 }
 
@@ -282,7 +302,12 @@ static int create_device_attrs(struct platform_device *pdev)
 		if (type == MAX_SENSOR_TYPE)
 			continue;
 
-		if (of_property_read_u32(np, "sensor-id", &sensor_id)) {
+		/*
+		 * Newer device trees use a "sensor-data" property
+		 * name for input.
+		 */
+		if (of_property_read_u32(np, "sensor-id", &sensor_id) &&
+		    of_property_read_u32(np, "sensor-data", &sensor_id)) {
 			dev_info(&pdev->dev,
 				 "'sensor-id' missing in the node '%s'\n",
 				 np->name);
@@ -292,12 +317,16 @@ static int create_device_attrs(struct platform_device *pdev)
 		sdata[count].id = sensor_id;
 		sdata[count].type = type;
 
+		/*
+		 * If we can not parse the node name, it means we are
+		 * running on a newer device tree. We can just forget
+		 * about the OPAL index and use a defaut value for the
+		 * hwmon attribute name
+		 */
 		attr_name = parse_opal_node_name(np->name, type, &opal_index);
 		if (IS_ERR(attr_name)) {
-			dev_err(&pdev->dev, "Sensor device node name '%s' is invalid\n",
-				np->name);
-			err = PTR_ERR(attr_name);
-			goto exit_put_node;
+			attr_name = "input";
+			opal_index = -1;
 		}
 
 		sdata[count].opal_index = opal_index;
-- 
1.7.10.4

Re: [lm-sensors] [PATCH 2/4] hwmon: (ibmpowernv) add support for the new device tree

[Guenter Roeck]

On Wed, Apr 01, 2015 at 12:15:04PM +0200, Cédric Le Goater wrote:
> The new OPAL device tree for sensors has a different layout and uses new
> property names, for the type and for the handler used to capture the
> sensor data.
> 
> This patch modifies the ibmpowernv driver to support such a tree in a
> way preserving compatibility with older OPAL firmwares.
> 
> This is achieved by changing the error path of the routine parsing
> an OPAL node name. The node is simply considered being from the new
> device tree layout and fallback values are used.
> 
> Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>

Hi Cedric,

I was about to apply the series, but then I found the following problem.

> ---
>  drivers/hwmon/ibmpowernv.c |   47 +++++++++++++++++++++++++++++++++++---------
>  1 file changed, 38 insertions(+), 9 deletions(-)
> 
[ ... ]
>  
> @@ -189,11 +204,16 @@ static u32 get_sensor_hwmon_index(struct sensor_data *sdata,
>  {
>  	int i;
>  
> -	for (i = 0; i < count; i++)
> -		if (sdata_table[i].opal_index == sdata->opal_index &&
> -		    sdata_table[i].type == sdata->type)
> -			return sdata_table[i].hwmon_index;
> +	/*
> +	 * We don't use the OPAL index on newer device trees
> +	 */
> +	if (sdata->opal_index != -1) {

opal_index is u32, so this won't work (or at least the result is
unpredictable).

Also, in patch 4/4 (v4), get_logical_cpu() takes unsigned int as parameter,
but get_hard_smp_processor_id() returns an int, causing gcc to complain
if the code is built with W=1.

Please fix and resubmit the entire series.

When you do that, please also ensure that continuation lines
are aligned (in patch 3/4).

Thanks,
Guenter

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [PATCH 2/4] hwmon: (ibmpowernv) add support for the new device tree

[Guenter Roeck]

On Wed, Apr 01, 2015 at 12:15:04PM +0200, Cédric Le Goater wrote:
> The new OPAL device tree for sensors has a different layout and uses new
> property names, for the type and for the handler used to capture the
> sensor data.
> 
> This patch modifies the ibmpowernv driver to support such a tree in a
> way preserving compatibility with older OPAL firmwares.
> 
> This is achieved by changing the error path of the routine parsing
> an OPAL node name. The node is simply considered being from the new
> device tree layout and fallback values are used.
> 
> Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>

Hi Cedric,

I was about to apply the series, but then I found the following problem.

> ---
>  drivers/hwmon/ibmpowernv.c |   47 +++++++++++++++++++++++++++++++++++---------
>  1 file changed, 38 insertions(+), 9 deletions(-)
> 
[ ... ]
>  
> @@ -189,11 +204,16 @@ static u32 get_sensor_hwmon_index(struct sensor_data *sdata,
>  {
>  	int i;
>  
> -	for (i = 0; i < count; i++)
> -		if (sdata_table[i].opal_index == sdata->opal_index &&
> -		    sdata_table[i].type == sdata->type)
> -			return sdata_table[i].hwmon_index;
> +	/*
> +	 * We don't use the OPAL index on newer device trees
> +	 */
> +	if (sdata->opal_index != -1) {

opal_index is u32, so this won't work (or at least the result is
unpredictable).

Also, in patch 4/4 (v4), get_logical_cpu() takes unsigned int as parameter,
but get_hard_smp_processor_id() returns an int, causing gcc to complain
if the code is built with W=1.

Please fix and resubmit the entire series.

When you do that, please also ensure that continuation lines
are aligned (in patch 3/4).

Thanks,
Guenter

Re: [lm-sensors] [PATCH 2/4] hwmon: (ibmpowernv) add support for the new device tree

[Cedric Le Goater]

On 04/08/2015 05:20 PM, Guenter Roeck wrote:
> On Wed, Apr 01, 2015 at 12:15:04PM +0200, Cédric Le Goater wrote:
>> The new OPAL device tree for sensors has a different layout and uses new
>> property names, for the type and for the handler used to capture the
>> sensor data.
>>
>> This patch modifies the ibmpowernv driver to support such a tree in a
>> way preserving compatibility with older OPAL firmwares.
>>
>> This is achieved by changing the error path of the routine parsing
>> an OPAL node name. The node is simply considered being from the new
>> device tree layout and fallback values are used.
>>
>> Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>
> 
> Hi Cedric,
> 
> I was about to apply the series, but then I found the following problem.
> 
>> ---
>>  drivers/hwmon/ibmpowernv.c |   47 +++++++++++++++++++++++++++++++++++---------
>>  1 file changed, 38 insertions(+), 9 deletions(-)
>>
> [ ... ]
>>  
>> @@ -189,11 +204,16 @@ static u32 get_sensor_hwmon_index(struct sensor_data *sdata,
>>  {
>>  	int i;
>>  
>> -	for (i = 0; i < count; i++)
>> -		if (sdata_table[i].opal_index == sdata->opal_index &&
>> -		    sdata_table[i].type == sdata->type)
>> -			return sdata_table[i].hwmon_index;
>> +	/*
>> +	 * We don't use the OPAL index on newer device trees
>> +	 */
>> +	if (sdata->opal_index != -1) {
> 
> opal_index is u32, so this won't work (or at least the result is
> unpredictable).
> 
> Also, in patch 4/4 (v4), get_logical_cpu() takes unsigned int as parameter,
> but get_hard_smp_processor_id() returns an int, causing gcc to complain
> if the code is built with W=1.
> 
> Please fix and resubmit the entire series.
> 
> When you do that, please also ensure that continuation lines
> are aligned (in patch 3/4).

Sure. Working on it right now.

Thanks,

C. 


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [PATCH 2/4] hwmon: (ibmpowernv) add support for the new device tree

[Cedric Le Goater]

On 04/08/2015 05:20 PM, Guenter Roeck wrote:
> On Wed, Apr 01, 2015 at 12:15:04PM +0200, Cédric Le Goater wrote:
>> The new OPAL device tree for sensors has a different layout and uses new
>> property names, for the type and for the handler used to capture the
>> sensor data.
>>
>> This patch modifies the ibmpowernv driver to support such a tree in a
>> way preserving compatibility with older OPAL firmwares.
>>
>> This is achieved by changing the error path of the routine parsing
>> an OPAL node name. The node is simply considered being from the new
>> device tree layout and fallback values are used.
>>
>> Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>
> 
> Hi Cedric,
> 
> I was about to apply the series, but then I found the following problem.
> 
>> ---
>>  drivers/hwmon/ibmpowernv.c |   47 +++++++++++++++++++++++++++++++++++---------
>>  1 file changed, 38 insertions(+), 9 deletions(-)
>>
> [ ... ]
>>  
>> @@ -189,11 +204,16 @@ static u32 get_sensor_hwmon_index(struct sensor_data *sdata,
>>  {
>>  	int i;
>>  
>> -	for (i = 0; i < count; i++)
>> -		if (sdata_table[i].opal_index == sdata->opal_index &&
>> -		    sdata_table[i].type == sdata->type)
>> -			return sdata_table[i].hwmon_index;
>> +	/*
>> +	 * We don't use the OPAL index on newer device trees
>> +	 */
>> +	if (sdata->opal_index != -1) {
> 
> opal_index is u32, so this won't work (or at least the result is
> unpredictable).
> 
> Also, in patch 4/4 (v4), get_logical_cpu() takes unsigned int as parameter,
> but get_hard_smp_processor_id() returns an int, causing gcc to complain
> if the code is built with W=1.
> 
> Please fix and resubmit the entire series.
> 
> When you do that, please also ensure that continuation lines
> are aligned (in patch 3/4).

Sure. Working on it right now.

Thanks,

C. 

[lm-sensors] [PATCH 3/4] hwmon: (ibmpowernv) add a label attribute

[Cédric Le Goater]

Q3VycmVudGx5LCBzZW5zb3JzIGFyZSBvbmx5IGlkZW50aWZpZWQgYnkgdGhlaXIgdHlwZSBhbmQg
aW5kZXguCgpUaGUgbmV3IE9QQUwgZGV2aWNlIHRyZWUgY2FuIGV4cG9zZSBleHRyYSBwcm9wZXJ0
aWVzIHRvIGlkZW50aWZ5CnNvbWUgc2Vuc29ycyBieSB0aGVpciBuYW1lIG9yIGxvY2F0aW9uLiBU
aGlzIHBhdGNoIGFkZHMgdGhlIGNyZWF0aW9uCm9mIGEgbmV3IGh3bW9uICpfbGFiZWwgYXR0cmli
dXRlIHdoZW4gc3VjaCBwcm9wZXJ0aWVzIGFyZSBkZXRlY3RlZC4KClNpZ25lZC1vZmYtYnk6IEPD
qWRyaWMgTGUgR29hdGVyIDxjbGdAZnIuaWJtLmNvbT4KLS0tCiBkcml2ZXJzL2h3bW9uL2libXBv
d2VybnYuYyB8ICAgNTEgKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
Ky0KIDEgZmlsZSBjaGFuZ2VkLCA1MCBpbnNlcnRpb25zKCspLCAxIGRlbGV0aW9uKC0pCgpkaWZm
IC0tZ2l0IGEvZHJpdmVycy9od21vbi9pYm1wb3dlcm52LmMgYi9kcml2ZXJzL2h3bW9uL2libXBv
d2VybnYuYwppbmRleCBmMzhhYTI3MzQzZjIuLmJlNmZlNTU5YjUyYSAxMDA2NDQKLS0tIGEvZHJp
dmVycy9od21vbi9pYm1wb3dlcm52LmMKKysrIGIvZHJpdmVycy9od21vbi9pYm1wb3dlcm52LmMK
QEAgLTMyLDYgKzMyLDcgQEAKICNpbmNsdWRlIDxsaW51eC9lcnIuaD4KIAogI2RlZmluZSBNQVhf
QVRUUl9MRU4JMzIKKyNkZWZpbmUgTUFYX0xBQkVMX0xFTgk2NAogCiAvKiBTZW5zb3Igc3VmZml4
IG5hbWUgZnJvbSBEVCAqLwogI2RlZmluZSBEVF9GQVVMVF9BVFRSX1NVRkZJWAkJImZhdWx0ZWQi
CkBAIC02OCw2ICs2OSw3IEBAIHN0cnVjdCBzZW5zb3JfZGF0YSB7CiAJdTMyIGh3bW9uX2luZGV4
OwogCXUzMiBvcGFsX2luZGV4OwogCWVudW0gc2Vuc29ycyB0eXBlOworCWNoYXIgbGFiZWxbTUFY
X0xBQkVMX0xFTl07CiAJY2hhciBuYW1lW01BWF9BVFRSX0xFTl07CiAJc3RydWN0IGRldmljZV9h
dHRyaWJ1dGUgZGV2X2F0dHI7CiB9OwpAQCAtOTksNiArMTAxLDIzIEBAIHN0YXRpYyBzc2l6ZV90
IHNob3dfc2Vuc29yKHN0cnVjdCBkZXZpY2UgKmRldiwgc3RydWN0IGRldmljZV9hdHRyaWJ1dGUg
KmRldmF0dHIsCiAJcmV0dXJuIHNwcmludGYoYnVmLCAiJXVcbiIsIHgpOwogfQogCitzdGF0aWMg
c3NpemVfdCBzaG93X2xhYmVsKHN0cnVjdCBkZXZpY2UgKmRldiwgc3RydWN0IGRldmljZV9hdHRy
aWJ1dGUgKmRldmF0dHIsCisJCQkgICBjaGFyICpidWYpCit7CisJc3RydWN0IHNlbnNvcl9kYXRh
ICpzZGF0YSA9IGNvbnRhaW5lcl9vZihkZXZhdHRyLCBzdHJ1Y3Qgc2Vuc29yX2RhdGEsCisJCQkJ
CQkgZGV2X2F0dHIpOworCisJcmV0dXJuIHNwcmludGYoYnVmLCAiJXNcbiIsIHNkYXRhLT5sYWJl
bCk7Cit9CisKK3N0YXRpYyB2b2lkIF9faW5pdCBtYWtlX3NlbnNvcl9sYWJlbChzdHJ1Y3QgZGV2
aWNlX25vZGUgKm5wLAorCQkgICAgc3RydWN0IHNlbnNvcl9kYXRhICpzZGF0YSwgY29uc3QgY2hh
ciAqbGFiZWwpCit7CisJc2l6ZV90IG47CisKKwluID0gc25wcmludGYoc2RhdGEtPmxhYmVsLCBz
aXplb2Yoc2RhdGEtPmxhYmVsKSwgIiVzIiwgbGFiZWwpOworfQorCiBzdGF0aWMgaW50IGdldF9z
ZW5zb3JfaW5kZXhfYXR0cihjb25zdCBjaGFyICpuYW1lLCB1MzIgKmluZGV4LAogCQkJCQljaGFy
ICphdHRyKQogewpAQCAtMjI2LDExICsyNDUsMjEgQEAgc3RhdGljIGludCBwb3B1bGF0ZV9hdHRy
X2dyb3VwcyhzdHJ1Y3QgcGxhdGZvcm1fZGV2aWNlICpwZGV2KQogCiAJb3BhbCA9IG9mX2ZpbmRf
bm9kZV9ieV9wYXRoKCIvaWJtLG9wYWwvc2Vuc29ycyIpOwogCWZvcl9lYWNoX2NoaWxkX29mX25v
ZGUob3BhbCwgbnApIHsKKwkJY29uc3QgY2hhciAqbGFiZWw7CisKIAkJaWYgKG5wLT5uYW1lID09
IE5VTEwpCiAJCQljb250aW51ZTsKIAogCQl0eXBlID0gZ2V0X3NlbnNvcl90eXBlKG5wKTsKLQkJ
aWYgKHR5cGUgIT0gTUFYX1NFTlNPUl9UWVBFKQorCQlpZiAodHlwZSA9PSBNQVhfU0VOU09SX1RZ
UEUpCisJCQljb250aW51ZTsKKworCQlzZW5zb3JfZ3JvdXBzW3R5cGVdLmF0dHJfY291bnQrKzsK
KworCQkvKgorCQkgKiBhZGQgYSBuZXcgYXR0cmlidXRlIGZvciBsYWJlbHMKKwkJICovCisJCWlm
ICghb2ZfcHJvcGVydHlfcmVhZF9zdHJpbmcobnAsICJsYWJlbCIsICZsYWJlbCkpCiAJCQlzZW5z
b3JfZ3JvdXBzW3R5cGVdLmF0dHJfY291bnQrKzsKIAl9CiAKQEAgLTI5NCw2ICszMjMsNyBAQCBz
dGF0aWMgaW50IGNyZWF0ZV9kZXZpY2VfYXR0cnMoc3RydWN0IHBsYXRmb3JtX2RldmljZSAqcGRl
dikKIAlmb3JfZWFjaF9jaGlsZF9vZl9ub2RlKG9wYWwsIG5wKSB7CiAJCWNvbnN0IGNoYXIgKmF0
dHJfbmFtZTsKIAkJdTMyIG9wYWxfaW5kZXg7CisJCWNvbnN0IGNoYXIgKmxhYmVsOwogCiAJCWlm
IChucC0+bmFtZSA9PSBOVUxMKQogCQkJY29udGludWU7CkBAIC0zMzcsNiArMzY3LDI1IEBAIHN0
YXRpYyBpbnQgY3JlYXRlX2RldmljZV9hdHRycyhzdHJ1Y3QgcGxhdGZvcm1fZGV2aWNlICpwZGV2
KQogCiAJCXBncm91cHNbdHlwZV0tPmF0dHJzW3NlbnNvcl9ncm91cHNbdHlwZV0uYXR0cl9jb3Vu
dCsrXSA9CiAJCQkJJnNkYXRhW2NvdW50KytdLmRldl9hdHRyLmF0dHI7CisKKwkJaWYgKCFvZl9w
cm9wZXJ0eV9yZWFkX3N0cmluZyhucCwgImxhYmVsIiwgJmxhYmVsKSkgeworCQkJLyoKKwkJCSAq
IEZvciB0aGUgbGFiZWwgYXR0cmlidXRlLCB3ZSBjYW4gcmV1c2UgdGhlCisJCQkgKiAicHJvcGVy
dGllcyIgb2YgdGhlIHByZXZpb3VzICJpbnB1dCIKKwkJCSAqIGF0dHJpYnV0ZS4gVGhleSBhcmUg
cmVsYXRlZCB0byB0aGUgc2FtZQorCQkJICogc2Vuc29yLgorCQkJICovCisJCQlzZGF0YVtjb3Vu
dF0udHlwZSA9IHR5cGU7CisJCQlzZGF0YVtjb3VudF0ub3BhbF9pbmRleCA9IHNkYXRhW2NvdW50
IC0gMV0ub3BhbF9pbmRleDsKKwkJCXNkYXRhW2NvdW50XS5od21vbl9pbmRleCA9IHNkYXRhW2Nv
dW50IC0gMV0uaHdtb25faW5kZXg7CisKKwkJCW1ha2Vfc2Vuc29yX2xhYmVsKG5wLCAmc2RhdGFb
Y291bnRdLCBsYWJlbCk7CisKKwkJCWNyZWF0ZV9od21vbl9hdHRyKCZzZGF0YVtjb3VudF0sICJs
YWJlbCIsIHNob3dfbGFiZWwpOworCisJCQlwZ3JvdXBzW3R5cGVdLT5hdHRyc1tzZW5zb3JfZ3Jv
dXBzW3R5cGVdLmF0dHJfY291bnQrK10gPQorCQkJCSZzZGF0YVtjb3VudCsrXS5kZXZfYXR0ci5h
dHRyOworCQl9CiAJfQogCiBleGl0X3B1dF9ub2RlOgotLSAKMS43LjEwLjQKCgpfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpsbS1zZW5zb3JzIG1haWxpbmcg
bGlzdApsbS1zZW5zb3JzQGxtLXNlbnNvcnMub3JnCmh0dHA6Ly9saXN0cy5sbS1zZW5zb3JzLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL2xtLXNlbnNvcnM

[PATCH 3/4] hwmon: (ibmpowernv) add a label attribute

[Cédric Le Goater]

Currently, sensors are only identified by their type and index.

The new OPAL device tree can expose extra properties to identify
some sensors by their name or location. This patch adds the creation
of a new hwmon *_label attribute when such properties are detected.

Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>
---
 drivers/hwmon/ibmpowernv.c |   51 +++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 50 insertions(+), 1 deletion(-)

diff --git a/drivers/hwmon/ibmpowernv.c b/drivers/hwmon/ibmpowernv.c
index f38aa27343f2..be6fe559b52a 100644
--- a/drivers/hwmon/ibmpowernv.c
+++ b/drivers/hwmon/ibmpowernv.c
@@ -32,6 +32,7 @@
 #include <linux/err.h>
 
 #define MAX_ATTR_LEN	32
+#define MAX_LABEL_LEN	64
 
 /* Sensor suffix name from DT */
 #define DT_FAULT_ATTR_SUFFIX		"faulted"
@@ -68,6 +69,7 @@ struct sensor_data {
 	u32 hwmon_index;
 	u32 opal_index;
 	enum sensors type;
+	char label[MAX_LABEL_LEN];
 	char name[MAX_ATTR_LEN];
 	struct device_attribute dev_attr;
 };
@@ -99,6 +101,23 @@ static ssize_t show_sensor(struct device *dev, struct device_attribute *devattr,
 	return sprintf(buf, "%u\n", x);
 }
 
+static ssize_t show_label(struct device *dev, struct device_attribute *devattr,
+			   char *buf)
+{
+	struct sensor_data *sdata = container_of(devattr, struct sensor_data,
+						 dev_attr);
+
+	return sprintf(buf, "%s\n", sdata->label);
+}
+
+static void __init make_sensor_label(struct device_node *np,
+		    struct sensor_data *sdata, const char *label)
+{
+	size_t n;
+
+	n = snprintf(sdata->label, sizeof(sdata->label), "%s", label);
+}
+
 static int get_sensor_index_attr(const char *name, u32 *index,
 					char *attr)
 {
@@ -226,11 +245,21 @@ static int populate_attr_groups(struct platform_device *pdev)
 
 	opal = of_find_node_by_path("/ibm,opal/sensors");
 	for_each_child_of_node(opal, np) {
+		const char *label;
+
 		if (np->name == NULL)
 			continue;
 
 		type = get_sensor_type(np);
-		if (type != MAX_SENSOR_TYPE)
+		if (type == MAX_SENSOR_TYPE)
+			continue;
+
+		sensor_groups[type].attr_count++;
+
+		/*
+		 * add a new attribute for labels
+		 */
+		if (!of_property_read_string(np, "label", &label))
 			sensor_groups[type].attr_count++;
 	}
 
@@ -294,6 +323,7 @@ static int create_device_attrs(struct platform_device *pdev)
 	for_each_child_of_node(opal, np) {
 		const char *attr_name;
 		u32 opal_index;
+		const char *label;
 
 		if (np->name == NULL)
 			continue;
@@ -337,6 +367,25 @@ static int create_device_attrs(struct platform_device *pdev)
 
 		pgroups[type]->attrs[sensor_groups[type].attr_count++] =
 				&sdata[count++].dev_attr.attr;
+
+		if (!of_property_read_string(np, "label", &label)) {
+			/*
+			 * For the label attribute, we can reuse the
+			 * "properties" of the previous "input"
+			 * attribute. They are related to the same
+			 * sensor.
+			 */
+			sdata[count].type = type;
+			sdata[count].opal_index = sdata[count - 1].opal_index;
+			sdata[count].hwmon_index = sdata[count - 1].hwmon_index;
+
+			make_sensor_label(np, &sdata[count], label);
+
+			create_hwmon_attr(&sdata[count], "label", show_label);
+
+			pgroups[type]->attrs[sensor_groups[type].attr_count++] =
+				&sdata[count++].dev_attr.attr;
+		}
 	}
 
 exit_put_node:
-- 
1.7.10.4

[lm-sensors] [PATCH 4/4] hwmon: (ibmpowernv) pretty print labels

[Cédric Le Goater]

VGhlIG5ldyBPUEFMIGRldmljZSB0cmVlIGFkZHMgYSBmZXcgcHJvcGVydGllcyB3aGljaCBjYW4g
YmUgdXNlZCB0byBhZGQKZXh0cmEgaW5mb3JtYXRpb24gb24gdGhlIHNlbnNvciBsYWJlbC4KClNp
Z25lZC1vZmYtYnk6IEPDqWRyaWMgTGUgR29hdGVyIDxjbGdAZnIuaWJtLmNvbT4KLS0tCiBkcml2
ZXJzL2h3bW9uL2libXBvd2VybnYuYyB8ICAgMjIgKysrKysrKysrKysrKysrKysrKysrKwogMSBm
aWxlIGNoYW5nZWQsIDIyIGluc2VydGlvbnMoKykKCmRpZmYgLS1naXQgYS9kcml2ZXJzL2h3bW9u
L2libXBvd2VybnYuYyBiL2RyaXZlcnMvaHdtb24vaWJtcG93ZXJudi5jCmluZGV4IGJlNmZlNTU5
YjUyYS4uM2U3NTNjMjE1YjQwIDEwMDY0NAotLS0gYS9kcml2ZXJzL2h3bW9uL2libXBvd2VybnYu
YworKysgYi9kcml2ZXJzL2h3bW9uL2libXBvd2VybnYuYwpAQCAtMTEzLDkgKzExMywzMSBAQCBz
dGF0aWMgc3NpemVfdCBzaG93X2xhYmVsKHN0cnVjdCBkZXZpY2UgKmRldiwgc3RydWN0IGRldmlj
ZV9hdHRyaWJ1dGUgKmRldmF0dHIsCiBzdGF0aWMgdm9pZCBfX2luaXQgbWFrZV9zZW5zb3JfbGFi
ZWwoc3RydWN0IGRldmljZV9ub2RlICpucCwKIAkJICAgIHN0cnVjdCBzZW5zb3JfZGF0YSAqc2Rh
dGEsIGNvbnN0IGNoYXIgKmxhYmVsKQogeworCXUzMiBpZDsKIAlzaXplX3QgbjsKIAogCW4gPSBz
bnByaW50ZihzZGF0YS0+bGFiZWwsIHNpemVvZihzZGF0YS0+bGFiZWwpLCAiJXMiLCBsYWJlbCk7
CisKKwkvKgorCSAqIENvcmUgdGVtcCBwcmV0dHkgcHJpbnQKKwkgKi8KKwlpZiAoIW9mX3Byb3Bl
cnR5X3JlYWRfdTMyKG5wLCAiaWJtLHBpciIsICZpZCkpIHsKKwkJaW50IGk7CisKKwkJZm9yX2Vh
Y2hfcG9zc2libGVfY3B1KGkpCisJCQlpZiAocGFjYVtpXS5od19jcHVfaWQgPT0gaWQpCisJCQkJ
YnJlYWs7CisKKwkJbiArPSBzbnByaW50ZihzZGF0YS0+bGFiZWwgKyBuLCBzaXplb2Yoc2RhdGEt
PmxhYmVsKSAtIG4sCisJCQkgICAgICAiICVkLSVkIiwgaSwgaSs3KTsKKwl9CisKKwkvKgorCSAq
IE1lbWJ1ZmZlciBwcmV0dHkgcHJpbnQKKwkgKi8KKwlpZiAoIW9mX3Byb3BlcnR5X3JlYWRfdTMy
KG5wLCAiaWJtLGNoaXAtaWQiLCAmaWQpKQorCQluICs9IHNucHJpbnRmKHNkYXRhLT5sYWJlbCAr
IG4sIHNpemVvZihzZGF0YS0+bGFiZWwpIC0gbiwKKwkJCSAgICAgICIgJWQiLCBpZCAmIDB4ZmZm
Zik7CiB9CiAKIHN0YXRpYyBpbnQgZ2V0X3NlbnNvcl9pbmRleF9hdHRyKGNvbnN0IGNoYXIgKm5h
bWUsIHUzMiAqaW5kZXgsCi0tIAoxLjcuMTAuNAoKCl9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fCmxtLXNlbnNvcnMgbWFpbGluZyBsaXN0CmxtLXNlbnNvcnNA
bG0tc2Vuc29ycy5vcmcKaHR0cDovL2xpc3RzLmxtLXNlbnNvcnMub3JnL21haWxtYW4vbGlzdGlu
Zm8vbG0tc2Vuc29ycw=

[PATCH 4/4] hwmon: (ibmpowernv) pretty print labels

[Cédric Le Goater]

The new OPAL device tree adds a few properties which can be used to add
extra information on the sensor label.

Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>
---
 drivers/hwmon/ibmpowernv.c |   22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/drivers/hwmon/ibmpowernv.c b/drivers/hwmon/ibmpowernv.c
index be6fe559b52a..3e753c215b40 100644
--- a/drivers/hwmon/ibmpowernv.c
+++ b/drivers/hwmon/ibmpowernv.c
@@ -113,9 +113,31 @@ static ssize_t show_label(struct device *dev, struct device_attribute *devattr,
 static void __init make_sensor_label(struct device_node *np,
 		    struct sensor_data *sdata, const char *label)
 {
+	u32 id;
 	size_t n;
 
 	n = snprintf(sdata->label, sizeof(sdata->label), "%s", label);
+
+	/*
+	 * Core temp pretty print
+	 */
+	if (!of_property_read_u32(np, "ibm,pir", &id)) {
+		int i;
+
+		for_each_possible_cpu(i)
+			if (paca[i].hw_cpu_id == id)
+				break;
+
+		n += snprintf(sdata->label + n, sizeof(sdata->label) - n,
+			      " %d-%d", i, i+7);
+	}
+
+	/*
+	 * Membuffer pretty print
+	 */
+	if (!of_property_read_u32(np, "ibm,chip-id", &id))
+		n += snprintf(sdata->label + n, sizeof(sdata->label) - n,
+			      " %d", id & 0xffff);
 }
 
 static int get_sensor_index_attr(const char *name, u32 *index,
-- 
1.7.10.4

Re: [lm-sensors] [PATCH 4/4] hwmon: (ibmpowernv) pretty print labels

[Guenter Roeck]

T24gMDQvMDEvMjAxNSAwMzoxNSBBTSwgQ8OpZHJpYyBMZSBHb2F0ZXIgd3JvdGU6Cj4gVGhlIG5l
dyBPUEFMIGRldmljZSB0cmVlIGFkZHMgYSBmZXcgcHJvcGVydGllcyB3aGljaCBjYW4gYmUgdXNl
ZCB0byBhZGQKPiBleHRyYSBpbmZvcm1hdGlvbiBvbiB0aGUgc2Vuc29yIGxhYmVsLgo+Cj4gU2ln
bmVkLW9mZi1ieTogQ8OpZHJpYyBMZSBHb2F0ZXIgPGNsZ0Bmci5pYm0uY29tPgo+IC0tLQo+ICAg
ZHJpdmVycy9od21vbi9pYm1wb3dlcm52LmMgfCAgIDIyICsrKysrKysrKysrKysrKysrKysrKysK
PiAgIDEgZmlsZSBjaGFuZ2VkLCAyMiBpbnNlcnRpb25zKCspCj4KPiBkaWZmIC0tZ2l0IGEvZHJp
dmVycy9od21vbi9pYm1wb3dlcm52LmMgYi9kcml2ZXJzL2h3bW9uL2libXBvd2VybnYuYwo+IGlu
ZGV4IGJlNmZlNTU5YjUyYS4uM2U3NTNjMjE1YjQwIDEwMDY0NAo+IC0tLSBhL2RyaXZlcnMvaHdt
b24vaWJtcG93ZXJudi5jCj4gKysrIGIvZHJpdmVycy9od21vbi9pYm1wb3dlcm52LmMKPiBAQCAt
MTEzLDkgKzExMywzMSBAQCBzdGF0aWMgc3NpemVfdCBzaG93X2xhYmVsKHN0cnVjdCBkZXZpY2Ug
KmRldiwgc3RydWN0IGRldmljZV9hdHRyaWJ1dGUgKmRldmF0dHIsCj4gICBzdGF0aWMgdm9pZCBf
X2luaXQgbWFrZV9zZW5zb3JfbGFiZWwoc3RydWN0IGRldmljZV9ub2RlICpucCwKPiAgIAkJICAg
IHN0cnVjdCBzZW5zb3JfZGF0YSAqc2RhdGEsIGNvbnN0IGNoYXIgKmxhYmVsKQo+ICAgewo+ICsJ
dTMyIGlkOwo+ICAgCXNpemVfdCBuOwo+Cj4gICAJbiA9IHNucHJpbnRmKHNkYXRhLT5sYWJlbCwg
c2l6ZW9mKHNkYXRhLT5sYWJlbCksICIlcyIsIGxhYmVsKTsKPiArCj4gKwkvKgo+ICsJICogQ29y
ZSB0ZW1wIHByZXR0eSBwcmludAo+ICsJICovCj4gKwlpZiAoIW9mX3Byb3BlcnR5X3JlYWRfdTMy
KG5wLCAiaWJtLHBpciIsICZpZCkpIHsKPiArCQlpbnQgaTsKPiArCj4gKwkJZm9yX2VhY2hfcG9z
c2libGVfY3B1KGkpCj4gKwkJCWlmIChwYWNhW2ldLmh3X2NwdV9pZCA9PSBpZCkKPiArCQkJCWJy
ZWFrOwo+ICsKPiArCQluICs9IHNucHJpbnRmKHNkYXRhLT5sYWJlbCArIG4sIHNpemVvZihzZGF0
YS0+bGFiZWwpIC0gbiwKPiArCQkJICAgICAgIiAlZC0lZCIsIGksIGkrNyk7CgpJZiBpYm0scGly
IHBvaW50cyB0byBhIGJhZC9pbnZhbGlkIENQVSBpZCB5b3UganVzdCBwcmludCBhbiBpbnZhbGlk
IHZhbHVlLgpJcyB0aGF0IHdoYXQgeW91IHdhbnQgPyBBbHNvLCB3aGF0IHJlbGV2YW5jZSBkb2Vz
ICdpJyBoYXZlIGZvciB0aGUgdXNlciA/Ckl0IGlzIHRoZSBpbmRleCBpbnRvIHRoZSBwYWNhIGFy
cmF5LCBzdXJlLCBidXQgd2hhdCBpcyBpdHMgcmVsZXZhbmNlCm91dHNpZGUgdGhpcyBjb2RlLCBl
c3BlY2lhbGx5IGluIHRoZSBjb250ZXh0IG9mIHlvdSBwcmludGluZyBib3RoIGkgYW5kIGkrNyA/
CgpHdWVudGVyCgo+ICsJfQo+ICsKPiArCS8qCj4gKwkgKiBNZW1idWZmZXIgcHJldHR5IHByaW50
Cj4gKwkgKi8KPiArCWlmICghb2ZfcHJvcGVydHlfcmVhZF91MzIobnAsICJpYm0sY2hpcC1pZCIs
ICZpZCkpCj4gKwkJbiArPSBzbnByaW50ZihzZGF0YS0+bGFiZWwgKyBuLCBzaXplb2Yoc2RhdGEt
PmxhYmVsKSAtIG4sCj4gKwkJCSAgICAgICIgJWQiLCBpZCAmIDB4ZmZmZik7Cj4gICB9Cj4KPiAg
IHN0YXRpYyBpbnQgZ2V0X3NlbnNvcl9pbmRleF9hdHRyKGNvbnN0IGNoYXIgKm5hbWUsIHUzMiAq
aW5kZXgsCj4KCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
XwpsbS1zZW5zb3JzIG1haWxpbmcgbGlzdApsbS1zZW5zb3JzQGxtLXNlbnNvcnMub3JnCmh0dHA6
Ly9saXN0cy5sbS1zZW5zb3JzLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xtLXNlbnNvcnM

Re: [PATCH 4/4] hwmon: (ibmpowernv) pretty print labels

[Guenter Roeck]

On 04/01/2015 03:15 AM, Cédric Le Goater wrote:
> The new OPAL device tree adds a few properties which can be used to add
> extra information on the sensor label.
>
> Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>
> ---
>   drivers/hwmon/ibmpowernv.c |   22 ++++++++++++++++++++++
>   1 file changed, 22 insertions(+)
>
> diff --git a/drivers/hwmon/ibmpowernv.c b/drivers/hwmon/ibmpowernv.c
> index be6fe559b52a..3e753c215b40 100644
> --- a/drivers/hwmon/ibmpowernv.c
> +++ b/drivers/hwmon/ibmpowernv.c
> @@ -113,9 +113,31 @@ static ssize_t show_label(struct device *dev, struct device_attribute *devattr,
>   static void __init make_sensor_label(struct device_node *np,
>   		    struct sensor_data *sdata, const char *label)
>   {
> +	u32 id;
>   	size_t n;
>
>   	n = snprintf(sdata->label, sizeof(sdata->label), "%s", label);
> +
> +	/*
> +	 * Core temp pretty print
> +	 */
> +	if (!of_property_read_u32(np, "ibm,pir", &id)) {
> +		int i;
> +
> +		for_each_possible_cpu(i)
> +			if (paca[i].hw_cpu_id == id)
> +				break;
> +
> +		n += snprintf(sdata->label + n, sizeof(sdata->label) - n,
> +			      " %d-%d", i, i+7);

If ibm,pir points to a bad/invalid CPU id you just print an invalid value.
Is that what you want ? Also, what relevance does 'i' have for the user ?
It is the index into the paca array, sure, but what is its relevance
outside this code, especially in the context of you printing both i and i+7 ?

Guenter

> +	}
> +
> +	/*
> +	 * Membuffer pretty print
> +	 */
> +	if (!of_property_read_u32(np, "ibm,chip-id", &id))
> +		n += snprintf(sdata->label + n, sizeof(sdata->label) - n,
> +			      " %d", id & 0xffff);
>   }
>
>   static int get_sensor_index_attr(const char *name, u32 *index,
>

Re: [lm-sensors] [PATCH 4/4] hwmon: (ibmpowernv) pretty print labels

[Cedric Le Goater]

T24gMDQvMDMvMjAxNSAwNTo0OSBQTSwgR3VlbnRlciBSb2VjayB3cm90ZToKPiBPbiAwNC8wMS8y
MDE1IDAzOjE1IEFNLCBDw6lkcmljIExlIEdvYXRlciB3cm90ZToKPj4gVGhlIG5ldyBPUEFMIGRl
dmljZSB0cmVlIGFkZHMgYSBmZXcgcHJvcGVydGllcyB3aGljaCBjYW4gYmUgdXNlZCB0byBhZGQK
Pj4gZXh0cmEgaW5mb3JtYXRpb24gb24gdGhlIHNlbnNvciBsYWJlbC4KPj4KPj4gU2lnbmVkLW9m
Zi1ieTogQ8OpZHJpYyBMZSBHb2F0ZXIgPGNsZ0Bmci5pYm0uY29tPgo+PiAtLS0KPj4gICBkcml2
ZXJzL2h3bW9uL2libXBvd2VybnYuYyB8ICAgMjIgKysrKysrKysrKysrKysrKysrKysrKwo+PiAg
IDEgZmlsZSBjaGFuZ2VkLCAyMiBpbnNlcnRpb25zKCspCj4+Cj4+IGRpZmYgLS1naXQgYS9kcml2
ZXJzL2h3bW9uL2libXBvd2VybnYuYyBiL2RyaXZlcnMvaHdtb24vaWJtcG93ZXJudi5jCj4+IGlu
ZGV4IGJlNmZlNTU5YjUyYS4uM2U3NTNjMjE1YjQwIDEwMDY0NAo+PiAtLS0gYS9kcml2ZXJzL2h3
bW9uL2libXBvd2VybnYuYwo+PiArKysgYi9kcml2ZXJzL2h3bW9uL2libXBvd2VybnYuYwo+PiBA
QCAtMTEzLDkgKzExMywzMSBAQCBzdGF0aWMgc3NpemVfdCBzaG93X2xhYmVsKHN0cnVjdCBkZXZp
Y2UgKmRldiwgc3RydWN0IGRldmljZV9hdHRyaWJ1dGUgKmRldmF0dHIsCj4+ICAgc3RhdGljIHZv
aWQgX19pbml0IG1ha2Vfc2Vuc29yX2xhYmVsKHN0cnVjdCBkZXZpY2Vfbm9kZSAqbnAsCj4+ICAg
ICAgICAgICAgICAgc3RydWN0IHNlbnNvcl9kYXRhICpzZGF0YSwgY29uc3QgY2hhciAqbGFiZWwp
Cj4+ICAgewo+PiArICAgIHUzMiBpZDsKPj4gICAgICAgc2l6ZV90IG47Cj4+Cj4+ICAgICAgIG4g
PSBzbnByaW50ZihzZGF0YS0+bGFiZWwsIHNpemVvZihzZGF0YS0+bGFiZWwpLCAiJXMiLCBsYWJl
bCk7Cj4+ICsKPj4gKyAgICAvKgo+PiArICAgICAqIENvcmUgdGVtcCBwcmV0dHkgcHJpbnQKPj4g
KyAgICAgKi8KPj4gKyAgICBpZiAoIW9mX3Byb3BlcnR5X3JlYWRfdTMyKG5wLCAiaWJtLHBpciIs
ICZpZCkpIHsKPj4gKyAgICAgICAgaW50IGk7Cj4+ICsKPj4gKyAgICAgICAgZm9yX2VhY2hfcG9z
c2libGVfY3B1KGkpCj4+ICsgICAgICAgICAgICBpZiAocGFjYVtpXS5od19jcHVfaWQgPT0gaWQp
Cj4+ICsgICAgICAgICAgICAgICAgYnJlYWs7Cj4+ICsKPj4gKyAgICAgICAgbiArPSBzbnByaW50
ZihzZGF0YS0+bGFiZWwgKyBuLCBzaXplb2Yoc2RhdGEtPmxhYmVsKSAtIG4sCj4+ICsgICAgICAg
ICAgICAgICAgICAiICVkLSVkIiwgaSwgaSs3KTsKPiAKPiBJZiBpYm0scGlyIHBvaW50cyB0byBh
IGJhZC9pbnZhbGlkIENQVSBpZCB5b3UganVzdCBwcmludCBhbiBpbnZhbGlkIHZhbHVlLgo+IElz
IHRoYXQgd2hhdCB5b3Ugd2FudCA/IAoKQ2VydGFpbmx5IG5vdCA6KSBJIGFtIGJlaW5nIG92ZXIg
b3B0aW1pc3RpYyBvbiB0aGUgdW5kZXJseWluZyBsYXllci4gCgo+IEFsc28sIHdoYXQgcmVsZXZh
bmNlIGRvZXMgJ2knIGhhdmUgZm9yIHRoZSB1c2VyID8KPiBJdCBpcyB0aGUgaW5kZXggaW50byB0
aGUgcGFjYSBhcnJheSwgc3VyZSwgYnV0IHdoYXQgaXMgaXRzIHJlbGV2YW5jZQo+IG91dHNpZGUg
dGhpcyBjb2RlLCBlc3BlY2lhbGx5IGluIHRoZSBjb250ZXh0IG9mIHlvdSBwcmludGluZyBib3Ro
IGkgYW5kIGkrNyA/CgpJdCBnaXZlcyBhIGhpbnQgb24gdGhlIGxvY2FsaXphdGlvbiBvZiB0aGUg
Y29yZSBpbiB0aGUgc3lzdGVtLCB3aGljaApjYW4gYmUgdXNlZnVsIHdoZW4gZGV2ZWxvcGluZyBj
dXN0b20gaGVhdCBzaW5rcy4gVGhlIHRyYW5zbGF0aW9uIApmcm9tIHBoeXNpY2FsIHRvIGxpbnV4
IGNwdSBpZCBpcyBoZXJlIHRvIGJlIGNvbnNpc3RlbnQgd2l0aCB0aGUgdXNlcgpsYXllci4gVGhl
IHBoeXNpY2FsIGlkIGlzIHJhcmVseSB1c2VkIGF0IHRoYXQgbGV2ZWwuICAKCkkgd2lsbCBzZW5k
IGEgdjIgZm9yIHRoaXMgcGF0Y2guCgpUaGFua3MsCgpDLgogCgo+IAo+IEd1ZW50ZXIKPiAKPj4g
KyAgICB9Cj4+ICsKPj4gKyAgICAvKgo+PiArICAgICAqIE1lbWJ1ZmZlciBwcmV0dHkgcHJpbnQK
Pj4gKyAgICAgKi8KPj4gKyAgICBpZiAoIW9mX3Byb3BlcnR5X3JlYWRfdTMyKG5wLCAiaWJtLGNo
aXAtaWQiLCAmaWQpKQo+PiArICAgICAgICBuICs9IHNucHJpbnRmKHNkYXRhLT5sYWJlbCArIG4s
IHNpemVvZihzZGF0YS0+bGFiZWwpIC0gbiwKPj4gKyAgICAgICAgICAgICAgICAgICIgJWQiLCBp
ZCAmIDB4ZmZmZik7Cj4+ICAgfQo+Pgo+PiAgIHN0YXRpYyBpbnQgZ2V0X3NlbnNvcl9pbmRleF9h
dHRyKGNvbnN0IGNoYXIgKm5hbWUsIHUzMiAqaW5kZXgsCj4+Cj4gCgoKX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbG0tc2Vuc29ycyBtYWlsaW5nIGxpc3QK
bG0tc2Vuc29yc0BsbS1zZW5zb3JzLm9yZwpodHRwOi8vbGlzdHMubG0tc2Vuc29ycy5vcmcvbWFp
bG1hbi9saXN0aW5mby9sbS1zZW5zb3Jz

Re: [PATCH 4/4] hwmon: (ibmpowernv) pretty print labels

[Cedric Le Goater]

On 04/03/2015 05:49 PM, Guenter Roeck wrote:
> On 04/01/2015 03:15 AM, Cédric Le Goater wrote:
>> The new OPAL device tree adds a few properties which can be used to add
>> extra information on the sensor label.
>>
>> Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>
>> ---
>>   drivers/hwmon/ibmpowernv.c |   22 ++++++++++++++++++++++
>>   1 file changed, 22 insertions(+)
>>
>> diff --git a/drivers/hwmon/ibmpowernv.c b/drivers/hwmon/ibmpowernv.c
>> index be6fe559b52a..3e753c215b40 100644
>> --- a/drivers/hwmon/ibmpowernv.c
>> +++ b/drivers/hwmon/ibmpowernv.c
>> @@ -113,9 +113,31 @@ static ssize_t show_label(struct device *dev, struct device_attribute *devattr,
>>   static void __init make_sensor_label(struct device_node *np,
>>               struct sensor_data *sdata, const char *label)
>>   {
>> +    u32 id;
>>       size_t n;
>>
>>       n = snprintf(sdata->label, sizeof(sdata->label), "%s", label);
>> +
>> +    /*
>> +     * Core temp pretty print
>> +     */
>> +    if (!of_property_read_u32(np, "ibm,pir", &id)) {
>> +        int i;
>> +
>> +        for_each_possible_cpu(i)
>> +            if (paca[i].hw_cpu_id == id)
>> +                break;
>> +
>> +        n += snprintf(sdata->label + n, sizeof(sdata->label) - n,
>> +                  " %d-%d", i, i+7);
> 
> If ibm,pir points to a bad/invalid CPU id you just print an invalid value.
> Is that what you want ? 

Certainly not :) I am being over optimistic on the underlying layer. 

> Also, what relevance does 'i' have for the user ?
> It is the index into the paca array, sure, but what is its relevance
> outside this code, especially in the context of you printing both i and i+7 ?

It gives a hint on the localization of the core in the system, which
can be useful when developing custom heat sinks. The translation 
from physical to linux cpu id is here to be consistent with the user
layer. The physical id is rarely used at that level.  

I will send a v2 for this patch.

Thanks,

C.
 

> 
> Guenter
> 
>> +    }
>> +
>> +    /*
>> +     * Membuffer pretty print
>> +     */
>> +    if (!of_property_read_u32(np, "ibm,chip-id", &id))
>> +        n += snprintf(sdata->label + n, sizeof(sdata->label) - n,
>> +                  " %d", id & 0xffff);
>>   }
>>
>>   static int get_sensor_index_attr(const char *name, u32 *index,
>>
> 

[lm-sensors] [PATCH 4/4] hwmon: (ibmpowernv) pretty print labels

[Cédric Le Goater]

VGhlIG5ldyBPUEFMIGRldmljZSB0cmVlIGFkZHMgYSBmZXcgcHJvcGVydGllcyB3aGljaCBjYW4g
YmUgdXNlZCB0byBhZGQKZXh0cmEgaW5mb3JtYXRpb24gb24gdGhlIHNlbnNvciBsYWJlbC4KCklu
IHRoZSBjYXNlIG9mIGEgY3B1IGNvcmUgc2Vuc29yLCB0aGUgZmlybXdhcmUgZXhwb3NlcyB0aGUg
cGh5c2ljYWwgCmlkZW50aWZpZXIgb2YgdGhlIGNvcmUgaW4gdGhlICJpYm0scGlyIiBwcm9wZXJ0
eS4gVGhlIGRyaXZlciAKdHJhbnNsYXRlcyB0aGlzIGlkZW50aWZpZXIgaW4gYSBsaW51eCBjcHUg
bnVtYmVyIGFuZCBwcmludHMgb3V0IGEgCnJhbmdlIGNvcnJlc3BvbmRpbmcgdG8gdGhlIGhhcmR3
YXJlIHRocmVhZHMgb2YgdGhlIGNvcmUgKGFzIHRoZXkKc2hhcmUgdGhlIHNhbWUgc2Vuc29yKS4K
ClRoZSBudW1iZXJpbmcgZ2l2ZXMgYSBoaW50IG9uIHRoZSBsb2NhbGl6YXRpb24gb2YgdGhlIGNv
cmUgaW4gdGhlIApzeXN0ZW0gKHdoaWNoIHNvY2tldCwgd2hpY2ggY2hpcCkuIAoKU2lnbmVkLW9m
Zi1ieTogQ8OpZHJpYyBMZSBHb2F0ZXIgPGNsZ0Bmci5pYm0uY29tPgotLS0KCiBDaGFuZ2VzIHNp
bmNlIHYxOgoKIC0gY2hlY2sgY3B1IHZhbGlkaXR5IGJlZm9yZSBwcmludGluZyBvdXQgdGhlIGF0
dHJpYnV0ZSBsYWJlbC4gCiAgIGlmIGludmFsaWQsIHVzZSBhICJwaHkiIHByZWZpeCB0byBkaXN0
aW5ndWlzaCBhIGxpbnV4IGNwdSAKICAgbnVtYmVyIGZyb20gYSBwaHlzaWNhbCBjcHUgbnVtYmVy
LiAKCiBkcml2ZXJzL2h3bW9uL2libXBvd2VybnYuYyB8ICAgMzQgKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysrKysrKwogMSBmaWxlIGNoYW5nZWQsIDM0IGluc2VydGlvbnMoKykKCkluZGV4
OiBsaW51eC5naXQvZHJpdmVycy9od21vbi9pYm1wb3dlcm52LmMKPT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gbGlu
dXguZ2l0Lm9yaWcvZHJpdmVycy9od21vbi9pYm1wb3dlcm52LmMKKysrIGxpbnV4LmdpdC9kcml2
ZXJzL2h3bW9uL2libXBvd2VybnYuYwpAQCAtMTEzLDkgKzExMyw0MyBAQCBzdGF0aWMgc3NpemVf
dCBzaG93X2xhYmVsKHN0cnVjdCBkZXZpY2UKIHN0YXRpYyB2b2lkIF9faW5pdCBtYWtlX3NlbnNv
cl9sYWJlbChzdHJ1Y3QgZGV2aWNlX25vZGUgKm5wLAogCQkgICAgc3RydWN0IHNlbnNvcl9kYXRh
ICpzZGF0YSwgY29uc3QgY2hhciAqbGFiZWwpCiB7CisJdTMyIGlkOwogCXNpemVfdCBuOwogCiAJ
biA9IHNucHJpbnRmKHNkYXRhLT5sYWJlbCwgc2l6ZW9mKHNkYXRhLT5sYWJlbCksICIlcyIsIGxh
YmVsKTsKKworCS8qCisJICogQ29yZSB0ZW1wIHByZXR0eSBwcmludAorCSAqLworCWlmICghb2Zf
cHJvcGVydHlfcmVhZF91MzIobnAsICJpYm0scGlyIiwgJmlkKSkgeworCQlpbnQgaSA9IC0xOwor
CisJCWZvcl9lYWNoX3Bvc3NpYmxlX2NwdShpKQorCQkJaWYgKHBhY2FbaV0uaHdfY3B1X2lkID09
IGlkKQorCQkJCWJyZWFrOworCisJCWlmIChpICE9IC0xKQorCQkJLyoKKwkJCSAqIFRoZSBkaWdp
dGFsIHRoZXJtYWwgc2Vuc29ycyBhcmUgYXNzb2NpYXRlZAorCQkJICogd2l0aCBhIGNvcmUuIExl
dCdzIHByaW50IG91dCB0aGUgcmFuZ2Ugb2YKKwkJCSAqIGNwdSBpZHMgY29ycmVzcG9uZGluZyB0
byB0aGUgaGFyZHdhcmUKKwkJCSAqIHRocmVhZHMgb2YgdGhlIGNvcmUuCisJCQkgKi8KKwkJCW4g
Kz0gc25wcmludGYoc2RhdGEtPmxhYmVsICsgbiwKKwkJCQkgICAgICBzaXplb2Yoc2RhdGEtPmxh
YmVsKSAtIG4sCisJCQkJICAgICAgIiAlZC0lZCIsIGksIGkrNyk7CisJCWVsc2UKKwkJCW4gKz0g
c25wcmludGYoc2RhdGEtPmxhYmVsICsgbiwKKwkJCQkgICAgICBzaXplb2Yoc2RhdGEtPmxhYmVs
KSAtIG4sCisJCQkJICAgICAgIiBwaHklZCIsIGlkKTsKKwl9CisKKwkvKgorCSAqIE1lbWJ1ZmZl
ciBwcmV0dHkgcHJpbnQKKwkgKi8KKwlpZiAoIW9mX3Byb3BlcnR5X3JlYWRfdTMyKG5wLCAiaWJt
LGNoaXAtaWQiLCAmaWQpKQorCQluICs9IHNucHJpbnRmKHNkYXRhLT5sYWJlbCArIG4sIHNpemVv
ZihzZGF0YS0+bGFiZWwpIC0gbiwKKwkJCSAgICAgICIgJWQiLCBpZCAmIDB4ZmZmZik7CiB9CiAK
IHN0YXRpYyBpbnQgZ2V0X3NlbnNvcl9pbmRleF9hdHRyKGNvbnN0IGNoYXIgKm5hbWUsIHUzMiAq
aW5kZXgsCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K
bG0tc2Vuc29ycyBtYWlsaW5nIGxpc3QKbG0tc2Vuc29yc0BsbS1zZW5zb3JzLm9yZwpodHRwOi8v
bGlzdHMubG0tc2Vuc29ycy5vcmcvbWFpbG1hbi9saXN0aW5mby9sbS1zZW5zb3Jz

[PATCH 4/4] hwmon: (ibmpowernv) pretty print labels

[Cédric Le Goater]

The new OPAL device tree adds a few properties which can be used to add
extra information on the sensor label.

In the case of a cpu core sensor, the firmware exposes the physical 
identifier of the core in the "ibm,pir" property. The driver 
translates this identifier in a linux cpu number and prints out a 
range corresponding to the hardware threads of the core (as they
share the same sensor).

The numbering gives a hint on the localization of the core in the 
system (which socket, which chip). 

Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>
---

 Changes since v1:

 - check cpu validity before printing out the attribute label. 
   if invalid, use a "phy" prefix to distinguish a linux cpu 
   number from a physical cpu number. 

 drivers/hwmon/ibmpowernv.c |   34 ++++++++++++++++++++++++++++++++++
 1 file changed, 34 insertions(+)

Index: linux.git/drivers/hwmon/ibmpowernv.c
===================================================================
--- linux.git.orig/drivers/hwmon/ibmpowernv.c
+++ linux.git/drivers/hwmon/ibmpowernv.c
@@ -113,9 +113,43 @@ static ssize_t show_label(struct device
 static void __init make_sensor_label(struct device_node *np,
 		    struct sensor_data *sdata, const char *label)
 {
+	u32 id;
 	size_t n;
 
 	n = snprintf(sdata->label, sizeof(sdata->label), "%s", label);
+
+	/*
+	 * Core temp pretty print
+	 */
+	if (!of_property_read_u32(np, "ibm,pir", &id)) {
+		int i = -1;
+
+		for_each_possible_cpu(i)
+			if (paca[i].hw_cpu_id == id)
+				break;
+
+		if (i != -1)
+			/*
+			 * The digital thermal sensors are associated
+			 * with a core. Let's print out the range of
+			 * cpu ids corresponding to the hardware
+			 * threads of the core.
+			 */
+			n += snprintf(sdata->label + n,
+				      sizeof(sdata->label) - n,
+				      " %d-%d", i, i+7);
+		else
+			n += snprintf(sdata->label + n,
+				      sizeof(sdata->label) - n,
+				      " phy%d", id);
+	}
+
+	/*
+	 * Membuffer pretty print
+	 */
+	if (!of_property_read_u32(np, "ibm,chip-id", &id))
+		n += snprintf(sdata->label + n, sizeof(sdata->label) - n,
+			      " %d", id & 0xffff);
 }
 
 static int get_sensor_index_attr(const char *name, u32 *index,

Re: [lm-sensors] [PATCH 4/4] hwmon: (ibmpowernv) pretty print labels

[Guenter Roeck]

On Tue, Apr 07, 2015 at 04:45:56PM +0200, Cédric Le Goater wrote:
> The new OPAL device tree adds a few properties which can be used to add
> extra information on the sensor label.
> 
> In the case of a cpu core sensor, the firmware exposes the physical 
> identifier of the core in the "ibm,pir" property. The driver 
> translates this identifier in a linux cpu number and prints out a 
> range corresponding to the hardware threads of the core (as they
> share the same sensor).
> 
> The numbering gives a hint on the localization of the core in the 
> system (which socket, which chip). 
> 
> Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>

Hi Cedric,

Please do not send follow-up patches as reply, but as separate e-mail.

Further comments below.

> ---
> 
>  Changes since v1:
> 
>  - check cpu validity before printing out the attribute label. 
>    if invalid, use a "phy" prefix to distinguish a linux cpu 
>    number from a physical cpu number. 
> 
>  drivers/hwmon/ibmpowernv.c |   34 ++++++++++++++++++++++++++++++++++
>  1 file changed, 34 insertions(+)
> 
> Index: linux.git/drivers/hwmon/ibmpowernv.c
> ===================================================================
> --- linux.git.orig/drivers/hwmon/ibmpowernv.c
> +++ linux.git/drivers/hwmon/ibmpowernv.c
> @@ -113,9 +113,43 @@ static ssize_t show_label(struct device
>  static void __init make_sensor_label(struct device_node *np,
>  		    struct sensor_data *sdata, const char *label)
>  {
> +	u32 id;
>  	size_t n;
>  
>  	n = snprintf(sdata->label, sizeof(sdata->label), "%s", label);
> +
> +	/*
> +	 * Core temp pretty print
> +	 */
> +	if (!of_property_read_u32(np, "ibm,pir", &id)) {
> +		int i = -1;
> +
> +		for_each_possible_cpu(i)
> +			if (paca[i].hw_cpu_id == id)

I think you should consider using get_hard_smp_processor_id() and avoid
direct access to the paca array.

> +				break;
> +
> +		if (i != -1)

I don't think that works. i is initialized by for_each_possible_cpu(),
either to -1 or 0 depending on the state of CONFIG_SMP. So pre-initializing
it won't make a difference. Its last value is NR_CPUS (SMP) or 1 (non-SMP).

You would need a second variable (which you could pre-initialize)
to determine if the code found a matching ID or not.

> +			/*
> +			 * The digital thermal sensors are associated
> +			 * with a core. Let's print out the range of
> +			 * cpu ids corresponding to the hardware
> +			 * threads of the core.
> +			 */
> +			n += snprintf(sdata->label + n,
> +				      sizeof(sdata->label) - n,
> +				      " %d-%d", i, i+7);

I would really like to see how this looks like in practice.

The id in the devicetree entry is the physical CPU. The resulting index
is the logical CPU number. So let's assume that the logical CPU number
for the first physical CPU is 0. Output would be "0-7". If the second
physical CPU matches logical CPU 1, output would be "1-8". 
How does that make any sense ?

Also, how do you know that the range of CPU IDs is always 8 ?

Can you provide some resulting outputs ?

Thanks,
Guenter

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [PATCH 4/4] hwmon: (ibmpowernv) pretty print labels

[Guenter Roeck]

On Tue, Apr 07, 2015 at 04:45:56PM +0200, Cédric Le Goater wrote:
> The new OPAL device tree adds a few properties which can be used to add
> extra information on the sensor label.
> 
> In the case of a cpu core sensor, the firmware exposes the physical 
> identifier of the core in the "ibm,pir" property. The driver 
> translates this identifier in a linux cpu number and prints out a 
> range corresponding to the hardware threads of the core (as they
> share the same sensor).
> 
> The numbering gives a hint on the localization of the core in the 
> system (which socket, which chip). 
> 
> Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>

Hi Cedric,

Please do not send follow-up patches as reply, but as separate e-mail.

Further comments below.

> ---
> 
>  Changes since v1:
> 
>  - check cpu validity before printing out the attribute label. 
>    if invalid, use a "phy" prefix to distinguish a linux cpu 
>    number from a physical cpu number. 
> 
>  drivers/hwmon/ibmpowernv.c |   34 ++++++++++++++++++++++++++++++++++
>  1 file changed, 34 insertions(+)
> 
> Index: linux.git/drivers/hwmon/ibmpowernv.c
> ===================================================================
> --- linux.git.orig/drivers/hwmon/ibmpowernv.c
> +++ linux.git/drivers/hwmon/ibmpowernv.c
> @@ -113,9 +113,43 @@ static ssize_t show_label(struct device
>  static void __init make_sensor_label(struct device_node *np,
>  		    struct sensor_data *sdata, const char *label)
>  {
> +	u32 id;
>  	size_t n;
>  
>  	n = snprintf(sdata->label, sizeof(sdata->label), "%s", label);
> +
> +	/*
> +	 * Core temp pretty print
> +	 */
> +	if (!of_property_read_u32(np, "ibm,pir", &id)) {
> +		int i = -1;
> +
> +		for_each_possible_cpu(i)
> +			if (paca[i].hw_cpu_id == id)

I think you should consider using get_hard_smp_processor_id() and avoid
direct access to the paca array.

> +				break;
> +
> +		if (i != -1)

I don't think that works. i is initialized by for_each_possible_cpu(),
either to -1 or 0 depending on the state of CONFIG_SMP. So pre-initializing
it won't make a difference. Its last value is NR_CPUS (SMP) or 1 (non-SMP).

You would need a second variable (which you could pre-initialize)
to determine if the code found a matching ID or not.

> +			/*
> +			 * The digital thermal sensors are associated
> +			 * with a core. Let's print out the range of
> +			 * cpu ids corresponding to the hardware
> +			 * threads of the core.
> +			 */
> +			n += snprintf(sdata->label + n,
> +				      sizeof(sdata->label) - n,
> +				      " %d-%d", i, i+7);

I would really like to see how this looks like in practice.

The id in the devicetree entry is the physical CPU. The resulting index
is the logical CPU number. So let's assume that the logical CPU number
for the first physical CPU is 0. Output would be "0-7". If the second
physical CPU matches logical CPU 1, output would be "1-8". 
How does that make any sense ?

Also, how do you know that the range of CPU IDs is always 8 ?

Can you provide some resulting outputs ?

Thanks,
Guenter

Re: [lm-sensors] [PATCH 4/4] hwmon: (ibmpowernv) pretty print labels

[Cedric Le Goater]

Hello Guenter,

On 04/07/2015 06:44 PM, Guenter Roeck wrote:
> On Tue, Apr 07, 2015 at 04:45:56PM +0200, Cédric Le Goater wrote:
>> The new OPAL device tree adds a few properties which can be used to add
>> extra information on the sensor label.
>>
>> In the case of a cpu core sensor, the firmware exposes the physical 
>> identifier of the core in the "ibm,pir" property. The driver 
>> translates this identifier in a linux cpu number and prints out a 
>> range corresponding to the hardware threads of the core (as they
>> share the same sensor).
>>
>> The numbering gives a hint on the localization of the core in the 
>> system (which socket, which chip). 
>>
>> Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>
> 
> Hi Cedric,
> 
> Please do not send follow-up patches as reply, but as separate e-mail.

Ok. I will start a new thread when I resend this patch.

> Further comments below.
> 
>> ---
>>
>>  Changes since v1:
>>
>>  - check cpu validity before printing out the attribute label. 
>>    if invalid, use a "phy" prefix to distinguish a linux cpu 
>>    number from a physical cpu number. 
>>
>>  drivers/hwmon/ibmpowernv.c |   34 ++++++++++++++++++++++++++++++++++
>>  1 file changed, 34 insertions(+)
>>
>> Index: linux.git/drivers/hwmon/ibmpowernv.c
>> ===================================================================
>> --- linux.git.orig/drivers/hwmon/ibmpowernv.c
>> +++ linux.git/drivers/hwmon/ibmpowernv.c
>> @@ -113,9 +113,43 @@ static ssize_t show_label(struct device
>>  static void __init make_sensor_label(struct device_node *np,
>>  		    struct sensor_data *sdata, const char *label)
>>  {
>> +	u32 id;
>>  	size_t n;
>>  
>>  	n = snprintf(sdata->label, sizeof(sdata->label), "%s", label);
>> +
>> +	/*
>> +	 * Core temp pretty print
>> +	 */
>> +	if (!of_property_read_u32(np, "ibm,pir", &id)) {
>> +		int i = -1;
>> +
>> +		for_each_possible_cpu(i)
>> +			if (paca[i].hw_cpu_id == id)
> 
> I think you should consider using get_hard_smp_processor_id() and avoid
> direct access to the paca array.

Yes. It will look better. Thanks.

>> +				break;
>> +
>> +		if (i != -1)
> 
> I don't think that works. i is initialized by for_each_possible_cpu(),
> either to -1 or 0 depending on the state of CONFIG_SMP. So pre-initializing
> it won't make a difference. Its last value is NR_CPUS (SMP) or 1 (non-SMP).
> 
> You would need a second variable (which you could pre-initialize)
> to determine if the code found a matching ID or not.

gloups. I did that patch waaaay too quickly, it is completely bogus ... 
I will cook a new version. sorry for the noise. 

>> +			/*
>> +			 * The digital thermal sensors are associated
>> +			 * with a core. Let's print out the range of
>> +			 * cpu ids corresponding to the hardware
>> +			 * threads of the core.
>> +			 */
>> +			n += snprintf(sdata->label + n,
>> +				      sizeof(sdata->label) - n,
>> +				      " %d-%d", i, i+7);
> 
> I would really like to see how this looks like in practice.
> 
> The id in the devicetree entry is the physical CPU. The resulting index
> is the logical CPU number. So let's assume that the logical CPU number
> for the first physical CPU is 0. Output would be "0-7". If the second
> physical CPU matches logical CPU 1, output would be "1-8". 
> How does that make any sense ?

The logical CPU numbers on PowerPC are initialized looping on the cores
found in the device tree and then on the threads of the core. Something 
like :

	logical_cpu = core_index * max_threads_per_core + thread_index 

which gives on a P8  :

	# ppc64_cpu --info
	Core   0:    0*    1*    2*    3*    4*    5*    6*    7* 
	Core   1:    8*    9*   10*   11*   12*   13*   14*   15* 
	Core   2:   16*   17*   18*   19*   20*   21*   22*   23* 
	Core   3:   24*   25*   26*   27*   28*   29*   30*   31* 
	Core   4:   32*   33*   34*   35*   36*   37*   38*   39* 
	Core   5:   40*   41*   42*   43*   44*   45*   46*   47* 
	Core   6:   48*   49*   50*   51*   52*   53*   54*   55* 
	Core   7:   56*   57*   58*   59*   60*   61*   62*   63* 
	Core   8:   64*   65*   66*   67*   68*   69*   70*   71* 
	Core   9:   72*   73*   74*   75*   76*   77*   78*   79* 
	Core  10:   80*   81*   82*   83*   84*   85*   86*   87* 
	Core  11:   88*   89*   90*   91*   92*   93*   94*   95* 
	Core  12:   96*   97*   98*   99*  100*  101*  102*  103* 
	Core  13:  104*  105*  106*  107*  108*  109*  110*  111* 
	Core  14:  112*  113*  114*  115*  116*  117*  118*  119* 
	Core  15:  120*  121*  122*  123*  124*  125*  126*  127* 
	Core  16:  128*  129*  130*  131*  132*  133*  134*  135* 
	Core  17:  136*  137*  138*  139*  140*  141*  142*  143* 
	Core  18:  144*  145*  146*  147*  148*  149*  150*  151* 
	Core  19:  152*  153*  154*  155*  156*  157*  158*  159* 

on a P7  :

	# ppc64_cpu --info
	Core   0:    0*    1*    2*    3* 
	Core   1:    4*    5*    6*    7* 
	Core   2:    8*    9*   10*   11* 
	Core   3:   12*   13*   14*   15* 
	Core   4:   16*   17*   18*   19* 
	Core   5:   20*   21*   22*   23* 


> Also, how do you know that the range of CPU IDs is always 8 ?

This is a shortcut. The code is for the ibmpowernv platform and assumes 
that we are running on a P8 (8 hardware threads). It would be better to 
use a "maximum threads per core" variable but I am not sure this is 
available, as it is a tunable. I will look into it.

> Can you provide some resulting outputs ?

sure. 

On an Open Power system : 

	# sensors
	ibmpowernv-isa-0000
	Adapter: ISA adapter
	Core 8-15:    +29.0°C  
	Core 16-23:   +29.0°C  
	Core 24-31:   +30.0°C  
	Core 32-39:   +30.0°C  
	Core 40-47:   +32.0°C  
	Core 48-55:   +29.0°C  
	Core 56-63:   +29.0°C  
	Centaur 0:    +28.0°C  
	Centaur 1:    +32.0°C  
	Centaur 4:    +28.0°C  
	Centaur 5:    +27.0°C  
	Core 0-7:     +29.0°C  

The Centaur numbering does not look as good as for the core.

On an IBM Power system :

	# sensors
	ibmpowernv-isa-0000
	Adapter: ISA adapter
	fan1:         5960 RPM  (min =    0 RPM)
	fan2:         5252 RPM  (min =    0 RPM)
	fan3:         5960 RPM  (min =    0 RPM)
	fan4:         5242 RPM  (min =    0 RPM)
	fan5:         5008 RPM  (min =    0 RPM)
	fan6:         5000 RPM  (min =    0 RPM)
	fan7:         5232 RPM  (min =    0 RPM)
	fan8:         5986 RPM  (min =    0 RPM)
	fan9:         5232 RPM  (min =    0 RPM)
	fan10:        6094 RPM  (min =    0 RPM)
	fan11:        5242 RPM  (min =    0 RPM)
	fan12:        5882 RPM  (min =    0 RPM)
	fan13:        5212 RPM  (min =    0 RPM)
	fan14:        5973 RPM  (min =    0 RPM)
	Ambient:       +18.0°C  (high =  +0.0°C)
	Core 0-7:      +40.0°C  
	Core 8-15:     +39.0°C  
	Core 16-23:    +39.0°C  
	Core 24-31:    +38.0°C  
	Core 32-39:    +38.0°C  
	Core 40-47:    +37.0°C  
	Core 48-55:    +37.0°C  
	Core 56-63:    +38.0°C  
	Core 64-71:    +38.0°C  
	Core 72-79:    +39.0°C  
	Core 80-87:    +35.0°C  
	Core 88-95:    +34.0°C  
	Core 96-103:   +33.0°C  
	Core 104-111:  +34.0°C  
	Core 112-119:  +33.0°C  
	Core 120-127:  +31.0°C  
	Core 128-135:  +31.0°C  
	Core 136-143:  +39.0°C  
	Core 144-151:  +39.0°C  
	Core 152-159:  +40.0°C  
	power1:       425.00 W  

The Centaur are not exposed yet.

Thanks,

C.



_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [PATCH 4/4] hwmon: (ibmpowernv) pretty print labels

[Cedric Le Goater]

Hello Guenter,

On 04/07/2015 06:44 PM, Guenter Roeck wrote:
> On Tue, Apr 07, 2015 at 04:45:56PM +0200, Cédric Le Goater wrote:
>> The new OPAL device tree adds a few properties which can be used to add
>> extra information on the sensor label.
>>
>> In the case of a cpu core sensor, the firmware exposes the physical 
>> identifier of the core in the "ibm,pir" property. The driver 
>> translates this identifier in a linux cpu number and prints out a 
>> range corresponding to the hardware threads of the core (as they
>> share the same sensor).
>>
>> The numbering gives a hint on the localization of the core in the 
>> system (which socket, which chip). 
>>
>> Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>
> 
> Hi Cedric,
> 
> Please do not send follow-up patches as reply, but as separate e-mail.

Ok. I will start a new thread when I resend this patch.

> Further comments below.
> 
>> ---
>>
>>  Changes since v1:
>>
>>  - check cpu validity before printing out the attribute label. 
>>    if invalid, use a "phy" prefix to distinguish a linux cpu 
>>    number from a physical cpu number. 
>>
>>  drivers/hwmon/ibmpowernv.c |   34 ++++++++++++++++++++++++++++++++++
>>  1 file changed, 34 insertions(+)
>>
>> Index: linux.git/drivers/hwmon/ibmpowernv.c
>> ===================================================================
>> --- linux.git.orig/drivers/hwmon/ibmpowernv.c
>> +++ linux.git/drivers/hwmon/ibmpowernv.c
>> @@ -113,9 +113,43 @@ static ssize_t show_label(struct device
>>  static void __init make_sensor_label(struct device_node *np,
>>  		    struct sensor_data *sdata, const char *label)
>>  {
>> +	u32 id;
>>  	size_t n;
>>  
>>  	n = snprintf(sdata->label, sizeof(sdata->label), "%s", label);
>> +
>> +	/*
>> +	 * Core temp pretty print
>> +	 */
>> +	if (!of_property_read_u32(np, "ibm,pir", &id)) {
>> +		int i = -1;
>> +
>> +		for_each_possible_cpu(i)
>> +			if (paca[i].hw_cpu_id == id)
> 
> I think you should consider using get_hard_smp_processor_id() and avoid
> direct access to the paca array.

Yes. It will look better. Thanks.

>> +				break;
>> +
>> +		if (i != -1)
> 
> I don't think that works. i is initialized by for_each_possible_cpu(),
> either to -1 or 0 depending on the state of CONFIG_SMP. So pre-initializing
> it won't make a difference. Its last value is NR_CPUS (SMP) or 1 (non-SMP).
> 
> You would need a second variable (which you could pre-initialize)
> to determine if the code found a matching ID or not.

gloups. I did that patch waaaay too quickly, it is completely bogus ... 
I will cook a new version. sorry for the noise. 

>> +			/*
>> +			 * The digital thermal sensors are associated
>> +			 * with a core. Let's print out the range of
>> +			 * cpu ids corresponding to the hardware
>> +			 * threads of the core.
>> +			 */
>> +			n += snprintf(sdata->label + n,
>> +				      sizeof(sdata->label) - n,
>> +				      " %d-%d", i, i+7);
> 
> I would really like to see how this looks like in practice.
> 
> The id in the devicetree entry is the physical CPU. The resulting index
> is the logical CPU number. So let's assume that the logical CPU number
> for the first physical CPU is 0. Output would be "0-7". If the second
> physical CPU matches logical CPU 1, output would be "1-8". 
> How does that make any sense ?

The logical CPU numbers on PowerPC are initialized looping on the cores
found in the device tree and then on the threads of the core. Something 
like :

	logical_cpu = core_index * max_threads_per_core + thread_index 

which gives on a P8  :

	# ppc64_cpu --info
	Core   0:    0*    1*    2*    3*    4*    5*    6*    7* 
	Core   1:    8*    9*   10*   11*   12*   13*   14*   15* 
	Core   2:   16*   17*   18*   19*   20*   21*   22*   23* 
	Core   3:   24*   25*   26*   27*   28*   29*   30*   31* 
	Core   4:   32*   33*   34*   35*   36*   37*   38*   39* 
	Core   5:   40*   41*   42*   43*   44*   45*   46*   47* 
	Core   6:   48*   49*   50*   51*   52*   53*   54*   55* 
	Core   7:   56*   57*   58*   59*   60*   61*   62*   63* 
	Core   8:   64*   65*   66*   67*   68*   69*   70*   71* 
	Core   9:   72*   73*   74*   75*   76*   77*   78*   79* 
	Core  10:   80*   81*   82*   83*   84*   85*   86*   87* 
	Core  11:   88*   89*   90*   91*   92*   93*   94*   95* 
	Core  12:   96*   97*   98*   99*  100*  101*  102*  103* 
	Core  13:  104*  105*  106*  107*  108*  109*  110*  111* 
	Core  14:  112*  113*  114*  115*  116*  117*  118*  119* 
	Core  15:  120*  121*  122*  123*  124*  125*  126*  127* 
	Core  16:  128*  129*  130*  131*  132*  133*  134*  135* 
	Core  17:  136*  137*  138*  139*  140*  141*  142*  143* 
	Core  18:  144*  145*  146*  147*  148*  149*  150*  151* 
	Core  19:  152*  153*  154*  155*  156*  157*  158*  159* 

on a P7  :

	# ppc64_cpu --info
	Core   0:    0*    1*    2*    3* 
	Core   1:    4*    5*    6*    7* 
	Core   2:    8*    9*   10*   11* 
	Core   3:   12*   13*   14*   15* 
	Core   4:   16*   17*   18*   19* 
	Core   5:   20*   21*   22*   23* 


> Also, how do you know that the range of CPU IDs is always 8 ?

This is a shortcut. The code is for the ibmpowernv platform and assumes 
that we are running on a P8 (8 hardware threads). It would be better to 
use a "maximum threads per core" variable but I am not sure this is 
available, as it is a tunable. I will look into it.

> Can you provide some resulting outputs ?

sure. 

On an Open Power system : 

	# sensors
	ibmpowernv-isa-0000
	Adapter: ISA adapter
	Core 8-15:    +29.0°C  
	Core 16-23:   +29.0°C  
	Core 24-31:   +30.0°C  
	Core 32-39:   +30.0°C  
	Core 40-47:   +32.0°C  
	Core 48-55:   +29.0°C  
	Core 56-63:   +29.0°C  
	Centaur 0:    +28.0°C  
	Centaur 1:    +32.0°C  
	Centaur 4:    +28.0°C  
	Centaur 5:    +27.0°C  
	Core 0-7:     +29.0°C  

The Centaur numbering does not look as good as for the core.

On an IBM Power system :

	# sensors
	ibmpowernv-isa-0000
	Adapter: ISA adapter
	fan1:         5960 RPM  (min =    0 RPM)
	fan2:         5252 RPM  (min =    0 RPM)
	fan3:         5960 RPM  (min =    0 RPM)
	fan4:         5242 RPM  (min =    0 RPM)
	fan5:         5008 RPM  (min =    0 RPM)
	fan6:         5000 RPM  (min =    0 RPM)
	fan7:         5232 RPM  (min =    0 RPM)
	fan8:         5986 RPM  (min =    0 RPM)
	fan9:         5232 RPM  (min =    0 RPM)
	fan10:        6094 RPM  (min =    0 RPM)
	fan11:        5242 RPM  (min =    0 RPM)
	fan12:        5882 RPM  (min =    0 RPM)
	fan13:        5212 RPM  (min =    0 RPM)
	fan14:        5973 RPM  (min =    0 RPM)
	Ambient:       +18.0°C  (high =  +0.0°C)
	Core 0-7:      +40.0°C  
	Core 8-15:     +39.0°C  
	Core 16-23:    +39.0°C  
	Core 24-31:    +38.0°C  
	Core 32-39:    +38.0°C  
	Core 40-47:    +37.0°C  
	Core 48-55:    +37.0°C  
	Core 56-63:    +38.0°C  
	Core 64-71:    +38.0°C  
	Core 72-79:    +39.0°C  
	Core 80-87:    +35.0°C  
	Core 88-95:    +34.0°C  
	Core 96-103:   +33.0°C  
	Core 104-111:  +34.0°C  
	Core 112-119:  +33.0°C  
	Core 120-127:  +31.0°C  
	Core 128-135:  +31.0°C  
	Core 136-143:  +39.0°C  
	Core 144-151:  +39.0°C  
	Core 152-159:  +40.0°C  
	power1:       425.00 W  

The Centaur are not exposed yet.

Thanks,

C.

Re: [lm-sensors] [PATCH 4/4] hwmon: (ibmpowernv) pretty print labels

[Guenter Roeck]

Hi Cedric,

On Tue, Apr 07, 2015 at 08:03:46PM +0200, Cedric Le Goater wrote:
> 
> on a P7  :
> 
> 	# ppc64_cpu --info
> 	Core   0:    0*    1*    2*    3* 
> 	Core   1:    4*    5*    6*    7* 
> 	Core   2:    8*    9*   10*   11* 
> 	Core   3:   12*   13*   14*   15* 
> 	Core   4:   16*   17*   18*   19* 
> 	Core   5:   20*   21*   22*   23* 
> 
How would the 'sensors' output look like on that system ?
Wouldn't it be something like the following ?

 	Core 0-7:    +29.0°C  
 	Core 4-11:   +29.0°C  

> 
> > Also, how do you know that the range of CPU IDs is always 8 ?
> 
> This is a shortcut. The code is for the ibmpowernv platform and assumes 
> that we are running on a P8 (8 hardware threads). It would be better to 
> use a "maximum threads per core" variable but I am not sure this is 
> available, as it is a tunable. I will look into it.
> 
Tunable how ? The core code must have some means to detect this number
when it initialized CPU entries, or am I missing something ?

Thanks,
Guenter

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [PATCH 4/4] hwmon: (ibmpowernv) pretty print labels

[Guenter Roeck]

Hi Cedric,

On Tue, Apr 07, 2015 at 08:03:46PM +0200, Cedric Le Goater wrote:
> 
> on a P7  :
> 
> 	# ppc64_cpu --info
> 	Core   0:    0*    1*    2*    3* 
> 	Core   1:    4*    5*    6*    7* 
> 	Core   2:    8*    9*   10*   11* 
> 	Core   3:   12*   13*   14*   15* 
> 	Core   4:   16*   17*   18*   19* 
> 	Core   5:   20*   21*   22*   23* 
> 
How would the 'sensors' output look like on that system ?
Wouldn't it be something like the following ?

 	Core 0-7:    +29.0°C  
 	Core 4-11:   +29.0°C  

> 
> > Also, how do you know that the range of CPU IDs is always 8 ?
> 
> This is a shortcut. The code is for the ibmpowernv platform and assumes 
> that we are running on a P8 (8 hardware threads). It would be better to 
> use a "maximum threads per core" variable but I am not sure this is 
> available, as it is a tunable. I will look into it.
> 
Tunable how ? The core code must have some means to detect this number
when it initialized CPU entries, or am I missing something ?

Thanks,
Guenter

Re: [lm-sensors] [PATCH 4/4] hwmon: (ibmpowernv) pretty print labels

[Cedric Le Goater]

Hello Guenter,

On 04/07/2015 09:22 PM, Guenter Roeck wrote:
> Hi Cedric,
> 
> On Tue, Apr 07, 2015 at 08:03:46PM +0200, Cedric Le Goater wrote:
>>
>> on a P7  :
>>
>> 	# ppc64_cpu --info
>> 	Core   0:    0*    1*    2*    3* 
>> 	Core   1:    4*    5*    6*    7* 
>> 	Core   2:    8*    9*   10*   11* 
>> 	Core   3:   12*   13*   14*   15* 
>> 	Core   4:   16*   17*   18*   19* 
>> 	Core   5:   20*   21*   22*   23* 
>>
> How would the 'sensors' output look like on that system ?
> Wouldn't it be something like the following ?
> 
>  	Core 0-7:    +29.0°C  
>  	Core 4-11:   +29.0°C  

yep. 

>>> Also, how do you know that the range of CPU IDs is always 8 ?
>>
>> This is a shortcut. The code is for the ibmpowernv platform and assumes 
>> that we are running on a P8 (8 hardware threads). It would be better to 
>> use a "maximum threads per core" variable but I am not sure this is 
>> available, as it is a tunable. I will look into it.
>>
> Tunable how ? 

You can switch on and off threads.

> The core code must have some means to detect this number when it initialized 
> CPU entries, or am I missing something ?

threads_per_core is what the code needs. v3 is on its way.

Thanks !

C.





_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [PATCH 4/4] hwmon: (ibmpowernv) pretty print labels

[Cedric Le Goater]

Hello Guenter,

On 04/07/2015 09:22 PM, Guenter Roeck wrote:
> Hi Cedric,
> 
> On Tue, Apr 07, 2015 at 08:03:46PM +0200, Cedric Le Goater wrote:
>>
>> on a P7  :
>>
>> 	# ppc64_cpu --info
>> 	Core   0:    0*    1*    2*    3* 
>> 	Core   1:    4*    5*    6*    7* 
>> 	Core   2:    8*    9*   10*   11* 
>> 	Core   3:   12*   13*   14*   15* 
>> 	Core   4:   16*   17*   18*   19* 
>> 	Core   5:   20*   21*   22*   23* 
>>
> How would the 'sensors' output look like on that system ?
> Wouldn't it be something like the following ?
> 
>  	Core 0-7:    +29.0°C  
>  	Core 4-11:   +29.0°C  

yep. 

>>> Also, how do you know that the range of CPU IDs is always 8 ?
>>
>> This is a shortcut. The code is for the ibmpowernv platform and assumes 
>> that we are running on a P8 (8 hardware threads). It would be better to 
>> use a "maximum threads per core" variable but I am not sure this is 
>> available, as it is a tunable. I will look into it.
>>
> Tunable how ? 

You can switch on and off threads.

> The core code must have some means to detect this number when it initialized 
> CPU entries, or am I missing something ?

threads_per_core is what the code needs. v3 is on its way.

Thanks !

C.

Re: [lm-sensors] [Skiboot] [PATCH 4/4] hwmon: (ibmpowernv) pretty print labels

[Benjamin Herrenschmidt]

On Tue, 2015-04-07 at 20:03 +0200, Cedric Le Goater wrote:
> 
> This is a shortcut. The code is for the ibmpowernv platform and assumes 
> that we are running on a P8 (8 hardware threads). It would be better to 
> use a "maximum threads per core" variable but I am not sure this is 
> available, as it is a tunable. I will look into it.

Yes, please don't hard code this...

Cheers,
Ben.




_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [Skiboot] [PATCH 4/4] hwmon: (ibmpowernv) pretty print labels

[Benjamin Herrenschmidt]

On Tue, 2015-04-07 at 20:03 +0200, Cedric Le Goater wrote:
> 
> This is a shortcut. The code is for the ibmpowernv platform and assumes 
> that we are running on a P8 (8 hardware threads). It would be better to 
> use a "maximum threads per core" variable but I am not sure this is 
> available, as it is a tunable. I will look into it.

Yes, please don't hard code this...

Cheers,
Ben.

[lm-sensors] [PATCH v2 1/5] hwmon: (ibmpowernv) replace AMBIENT_TEMP by TEMP

[Cédric Le Goater]

QW1iaWVudCBpcyB0b28gcmVzdHJpY3RpdmUgYXMgdGhlcmUgY2FuIGJlIG90aGVyIHRlbXBlcmF0
dXJlIGNoYW5uZWxzIDoKY29yZSwgbWVtb3J5LCBldGMuCgpTaWduZWQtb2ZmLWJ5OiBDw6lkcmlj
IExlIEdvYXRlciA8Y2xnQGZyLmlibS5jb20+Ci0tLQogZHJpdmVycy9od21vbi9pYm1wb3dlcm52
LmMgfCAgICA2ICsrKy0tLQogMSBmaWxlIGNoYW5nZWQsIDMgaW5zZXJ0aW9ucygrKSwgMyBkZWxl
dGlvbnMoLSkKCkluZGV4OiBsaW51eC5naXQvZHJpdmVycy9od21vbi9pYm1wb3dlcm52LmMKPT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PQotLS0gbGludXguZ2l0Lm9yaWcvZHJpdmVycy9od21vbi9pYm1wb3dlcm52LmMKKysr
IGxpbnV4LmdpdC9kcml2ZXJzL2h3bW9uL2libXBvd2VybnYuYwpAQCAtNDQsNyArNDQsNyBAQAog
ICovCiBlbnVtIHNlbnNvcnMgewogCUZBTiwKLQlBTUJJRU5UX1RFTVAsCisJVEVNUCwKIAlQT1dF
Ul9TVVBQTFksCiAJUE9XRVJfSU5QVVQsCiAJTUFYX1NFTlNPUl9UWVBFLApAQCAtODcsNyArODcs
NyBAQCBzdGF0aWMgc3NpemVfdCBzaG93X3NlbnNvcihzdHJ1Y3QgZGV2aWNlCiAJCXJldHVybiBy
ZXQ7CiAKIAkvKiBDb252ZXJ0IHRlbXBlcmF0dXJlIHRvIG1pbGxpLWRlZ3JlZXMgKi8KLQlpZiAo
c2RhdGEtPnR5cGUgPT0gQU1CSUVOVF9URU1QKQorCWlmIChzZGF0YS0+dHlwZSA9PSBURU1QKQog
CQl4ICo9IDEwMDA7CiAJLyogQ29udmVydCBwb3dlciB0byBtaWNyby13YXR0cyAqLwogCWVsc2Ug
aWYgKHNkYXRhLT50eXBlID09IFBPV0VSX0lOUFVUKQpAQCAtMTU0LDcgKzE1NCw3IEBAIHN0YXRp
YyBpbnQgY3JlYXRlX2h3bW9uX2F0dHJfbmFtZShzdHJ1Y3QKIAl9IGVsc2UgaWYgKCFzdHJjbXAo
YXR0cl9zdWZmaXgsIERUX0RBVEFfQVRUUl9TVUZGSVgpKSB7CiAJCWF0dHJfbmFtZSA9ICJpbnB1
dCI7CiAJfSBlbHNlIGlmICghc3RyY21wKGF0dHJfc3VmZml4LCBEVF9USFJFU0hPTERfQVRUUl9T
VUZGSVgpKSB7Ci0JCWlmICh0eXBlID09IEFNQklFTlRfVEVNUCkKKwkJaWYgKHR5cGUgPT0gVEVN
UCkKIAkJCWF0dHJfbmFtZSA9ICJtYXgiOwogCQllbHNlIGlmICh0eXBlID09IEZBTikKIAkJCWF0
dHJfbmFtZSA9ICJtaW4iOwoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fCmxtLXNlbnNvcnMgbWFpbGluZyBsaXN0CmxtLXNlbnNvcnNAbG0tc2Vuc29ycy5v
cmcKaHR0cDovL2xpc3RzLmxtLXNlbnNvcnMub3JnL21haWxtYW4vbGlzdGluZm8vbG0tc2Vuc29y
cw=

[PATCH v2 1/5] hwmon: (ibmpowernv) replace AMBIENT_TEMP by TEMP

[Cédric Le Goater]

Ambient is too restrictive as there can be other temperature channels :
core, memory, etc.

Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>
---
 drivers/hwmon/ibmpowernv.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

Index: linux.git/drivers/hwmon/ibmpowernv.c
===================================================================
--- linux.git.orig/drivers/hwmon/ibmpowernv.c
+++ linux.git/drivers/hwmon/ibmpowernv.c
@@ -44,7 +44,7 @@
  */
 enum sensors {
 	FAN,
-	AMBIENT_TEMP,
+	TEMP,
 	POWER_SUPPLY,
 	POWER_INPUT,
 	MAX_SENSOR_TYPE,
@@ -87,7 +87,7 @@ static ssize_t show_sensor(struct device
 		return ret;
 
 	/* Convert temperature to milli-degrees */
-	if (sdata->type == AMBIENT_TEMP)
+	if (sdata->type == TEMP)
 		x *= 1000;
 	/* Convert power to micro-watts */
 	else if (sdata->type == POWER_INPUT)
@@ -154,7 +154,7 @@ static int create_hwmon_attr_name(struct
 	} else if (!strcmp(attr_suffix, DT_DATA_ATTR_SUFFIX)) {
 		attr_name = "input";
 	} else if (!strcmp(attr_suffix, DT_THRESHOLD_ATTR_SUFFIX)) {
-		if (type == AMBIENT_TEMP)
+		if (type == TEMP)
 			attr_name = "max";
 		else if (type == FAN)
 			attr_name = "min";

[lm-sensors] [PATCH v2 2/5] hwmon: (ibmpowernv) add a get_sensor_type() routine

[Cédric Le Goater]

SXQgd2lsbCBoZWxwIGluIGFkZGluZyBkaWZmZXJlbnQgY29tcGF0aWJsZSBwcm9wZXJ0aWVzLCBj
b21pbmcgZnJvbSBhCm5ldyBkZXZpY2UgdHJlZSBsYXlvdXQgZm9yIGV4YW1wbGUuCgpTaWduZWQt
b2ZmLWJ5OiBDw6lkcmljIExlIEdvYXRlciA8Y2xnQGZyLmlibS5jb20+Ci0tLQogZHJpdmVycy9o
d21vbi9pYm1wb3dlcm52LmMgfCAgIDI2ICsrKysrKysrKysrKysrKy0tLS0tLS0tLS0tCiAxIGZp
bGUgY2hhbmdlZCwgMTUgaW5zZXJ0aW9ucygrKSwgMTEgZGVsZXRpb25zKC0pCgpJbmRleDogbGlu
dXguZ2l0L2RyaXZlcnMvaHdtb24vaWJtcG93ZXJudi5jCj09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIGxpbnV4Lmdp
dC5vcmlnL2RyaXZlcnMvaHdtb24vaWJtcG93ZXJudi5jCisrKyBsaW51eC5naXQvZHJpdmVycy9o
d21vbi9pYm1wb3dlcm52LmMKQEAgLTE2OSw2ICsxNjksMTcgQEAgc3RhdGljIGludCBjcmVhdGVf
aHdtb25fYXR0cl9uYW1lKHN0cnVjdAogCXJldHVybiAwOwogfQogCitzdGF0aWMgaW50IGdldF9z
ZW5zb3JfdHlwZShzdHJ1Y3QgZGV2aWNlX25vZGUgKm5wKQoreworCWVudW0gc2Vuc29ycyB0eXBl
OworCisJZm9yICh0eXBlID0gMDsgdHlwZSA8IE1BWF9TRU5TT1JfVFlQRTsgdHlwZSsrKSB7CisJ
CWlmIChvZl9kZXZpY2VfaXNfY29tcGF0aWJsZShucCwgc2Vuc29yX2dyb3Vwc1t0eXBlXS5jb21w
YXRpYmxlKSkKKwkJCXJldHVybiB0eXBlOworCX0KKwlyZXR1cm4gTUFYX1NFTlNPUl9UWVBFOwor
fQorCiBzdGF0aWMgaW50IHBvcHVsYXRlX2F0dHJfZ3JvdXBzKHN0cnVjdCBwbGF0Zm9ybV9kZXZp
Y2UgKnBkZXYpCiB7CiAJc3RydWN0IHBsYXRmb3JtX2RhdGEgKnBkYXRhID0gcGxhdGZvcm1fZ2V0
X2RydmRhdGEocGRldik7CkBAIC0xODEsMTIgKzE5Miw5IEBAIHN0YXRpYyBpbnQgcG9wdWxhdGVf
YXR0cl9ncm91cHMoc3RydWN0IHAKIAkJaWYgKG5wLT5uYW1lID09IE5VTEwpCiAJCQljb250aW51
ZTsKIAotCQlmb3IgKHR5cGUgPSAwOyB0eXBlIDwgTUFYX1NFTlNPUl9UWVBFOyB0eXBlKyspCi0J
CQlpZiAob2ZfZGV2aWNlX2lzX2NvbXBhdGlibGUobnAsCi0JCQkJCXNlbnNvcl9ncm91cHNbdHlw
ZV0uY29tcGF0aWJsZSkpIHsKLQkJCQlzZW5zb3JfZ3JvdXBzW3R5cGVdLmF0dHJfY291bnQrKzsK
LQkJCQlicmVhazsKLQkJCX0KKwkJdHlwZSA9IGdldF9zZW5zb3JfdHlwZShucCk7CisJCWlmICh0
eXBlICE9IE1BWF9TRU5TT1JfVFlQRSkKKwkJCXNlbnNvcl9ncm91cHNbdHlwZV0uYXR0cl9jb3Vu
dCsrOwogCX0KIAogCW9mX25vZGVfcHV0KG9wYWwpOwpAQCAtMjM2LDExICsyNDQsNyBAQCBzdGF0
aWMgaW50IGNyZWF0ZV9kZXZpY2VfYXR0cnMoc3RydWN0IHBsCiAJCWlmIChucC0+bmFtZSA9PSBO
VUxMKQogCQkJY29udGludWU7CiAKLQkJZm9yICh0eXBlID0gMDsgdHlwZSA8IE1BWF9TRU5TT1Jf
VFlQRTsgdHlwZSsrKQotCQkJaWYgKG9mX2RldmljZV9pc19jb21wYXRpYmxlKG5wLAotCQkJCQlz
ZW5zb3JfZ3JvdXBzW3R5cGVdLmNvbXBhdGlibGUpKQotCQkJCWJyZWFrOwotCisJCXR5cGUgPSBn
ZXRfc2Vuc29yX3R5cGUobnApOwogCQlpZiAodHlwZSA9PSBNQVhfU0VOU09SX1RZUEUpCiAJCQlj
b250aW51ZTsKIAoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fCmxtLXNlbnNvcnMgbWFpbGluZyBsaXN0CmxtLXNlbnNvcnNAbG0tc2Vuc29ycy5vcmcKaHR0
cDovL2xpc3RzLmxtLXNlbnNvcnMub3JnL21haWxtYW4vbGlzdGluZm8vbG0tc2Vuc29ycw=

[PATCH v2 2/5] hwmon: (ibmpowernv) add a get_sensor_type() routine

[Cédric Le Goater]

It will help in adding different compatible properties, coming from a
new device tree layout for example.

Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>
---
 drivers/hwmon/ibmpowernv.c |   26 +++++++++++++++-----------
 1 file changed, 15 insertions(+), 11 deletions(-)

Index: linux.git/drivers/hwmon/ibmpowernv.c
===================================================================
--- linux.git.orig/drivers/hwmon/ibmpowernv.c
+++ linux.git/drivers/hwmon/ibmpowernv.c
@@ -169,6 +169,17 @@ static int create_hwmon_attr_name(struct
 	return 0;
 }
 
+static int get_sensor_type(struct device_node *np)
+{
+	enum sensors type;
+
+	for (type = 0; type < MAX_SENSOR_TYPE; type++) {
+		if (of_device_is_compatible(np, sensor_groups[type].compatible))
+			return type;
+	}
+	return MAX_SENSOR_TYPE;
+}
+
 static int populate_attr_groups(struct platform_device *pdev)
 {
 	struct platform_data *pdata = platform_get_drvdata(pdev);
@@ -181,12 +192,9 @@ static int populate_attr_groups(struct p
 		if (np->name == NULL)
 			continue;
 
-		for (type = 0; type < MAX_SENSOR_TYPE; type++)
-			if (of_device_is_compatible(np,
-					sensor_groups[type].compatible)) {
-				sensor_groups[type].attr_count++;
-				break;
-			}
+		type = get_sensor_type(np);
+		if (type != MAX_SENSOR_TYPE)
+			sensor_groups[type].attr_count++;
 	}
 
 	of_node_put(opal);
@@ -236,11 +244,7 @@ static int create_device_attrs(struct pl
 		if (np->name == NULL)
 			continue;
 
-		for (type = 0; type < MAX_SENSOR_TYPE; type++)
-			if (of_device_is_compatible(np,
-					sensor_groups[type].compatible))
-				break;
-
+		type = get_sensor_type(np);
 		if (type == MAX_SENSOR_TYPE)
 			continue;
 

[lm-sensors] [PATCH v2 3/5] hwmon: (ibmpowernv) add a convert_opal_attr_name() routine

[Cédric Le Goater]

SXQgc2ltcGxpZmllcyB0aGUgY3JlYXRlX2h3bW9uX2F0dHJfbmFtZSgpIHJvdXRpbmUgYW5kIGl0
IGNsZWFybHkgaXNvbGF0ZXMKdGhlIGNvbnZlcnNpb24gZG9uZSBiZXR3ZWVuIHRoZSBPUEFMIG5v
ZGUgbmFtZXMgYW5kIGh3bW9uIGF0dHJpYnV0ZXMgbmFtZXMuCgpTaWduZWQtb2ZmLWJ5OiBDw6lk
cmljIExlIEdvYXRlciA8Y2xnQGZyLmlibS5jb20+Ci0tLQoKQ2hhbmdlcyBzaW5jZSB2MToKCiAt
IGZpeGVkIGFsaWdubWVudAogLSBraWxsZWQgYSBjb3VwbGUgb2YgdXNlbGVzcyAicmV0dXJuIE5V
TEwiCgogZHJpdmVycy9od21vbi9pYm1wb3dlcm52LmMgfCAgIDM2ICsrKysrKysrKysrKysrKysr
KysrKystLS0tLS0tLS0tLS0tLQogMSBmaWxlIGNoYW5nZWQsIDIyIGluc2VydGlvbnMoKyksIDE0
IGRlbGV0aW9ucygtKQoKSW5kZXg6IGxpbnV4LmdpdC9kcml2ZXJzL2h3bW9uL2libXBvd2VybnYu
Ywo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09Ci0tLSBsaW51eC5naXQub3JpZy9kcml2ZXJzL2h3bW9uL2libXBvd2VybnYu
YworKysgbGludXguZ2l0L2RyaXZlcnMvaHdtb24vaWJtcG93ZXJudi5jCkBAIC0xMjcsNiArMTI3
LDI1IEBAIHN0YXRpYyBpbnQgZ2V0X3NlbnNvcl9pbmRleF9hdHRyKGNvbnN0IGMKIAlyZXR1cm4g
MDsKIH0KIAorc3RhdGljIGNvbnN0IGNoYXIgKmNvbnZlcnRfb3BhbF9hdHRyX25hbWUoZW51bSBz
ZW5zb3JzIHR5cGUsCisJCQkJCSAgY29uc3QgY2hhciAqb3BhbF9hdHRyKQoreworCWNvbnN0IGNo
YXIgKmF0dHJfbmFtZSA9IE5VTEw7CisKKwlpZiAoIXN0cmNtcChvcGFsX2F0dHIsIERUX0ZBVUxU
X0FUVFJfU1VGRklYKSkgeworCQlhdHRyX25hbWUgPSAiZmF1bHQiOworCX0gZWxzZSBpZiAoIXN0
cmNtcChvcGFsX2F0dHIsIERUX0RBVEFfQVRUUl9TVUZGSVgpKSB7CisJCWF0dHJfbmFtZSA9ICJp
bnB1dCI7CisJfSBlbHNlIGlmICghc3RyY21wKG9wYWxfYXR0ciwgRFRfVEhSRVNIT0xEX0FUVFJf
U1VGRklYKSkgeworCQlpZiAodHlwZSA9PSBURU1QKQorCQkJYXR0cl9uYW1lID0gIm1heCI7CisJ
CWVsc2UgaWYgKHR5cGUgPT0gRkFOKQorCQkJYXR0cl9uYW1lID0gIm1pbiI7CisJfQorCisJcmV0
dXJuIGF0dHJfbmFtZTsKK30KKwogLyoKICAqIFRoaXMgZnVuY3Rpb24gdHJhbnNsYXRlcyB0aGUg
RFQgbm9kZSBuYW1lIGludG8gdGhlICdod21vbicgYXR0cmlidXRlIG5hbWUuCiAgKiBJQk1QT1dF
Uk5WIGRldmljZSBub2RlIGFwcGVhciBsaWtlIGNvb2xpbmctZmFuIzItZGF0YSwgYW1iLXRlbXAj
MS10aHJzIGV0Yy4KQEAgLTEzOCw3ICsxNTcsNyBAQCBzdGF0aWMgaW50IGNyZWF0ZV9od21vbl9h
dHRyX25hbWUoc3RydWN0CiAJCQkJCSBjaGFyICpod21vbl9hdHRyX25hbWUpCiB7CiAJY2hhciBh
dHRyX3N1ZmZpeFtNQVhfQVRUUl9MRU5dOwotCWNoYXIgKmF0dHJfbmFtZTsKKwljb25zdCBjaGFy
ICphdHRyX25hbWU7CiAJdTMyIGluZGV4OwogCWludCBlcnI7CiAKQEAgLTE0OSwyMCArMTY4LDkg
QEAgc3RhdGljIGludCBjcmVhdGVfaHdtb25fYXR0cl9uYW1lKHN0cnVjdAogCQlyZXR1cm4gZXJy
OwogCX0KIAotCWlmICghc3RyY21wKGF0dHJfc3VmZml4LCBEVF9GQVVMVF9BVFRSX1NVRkZJWCkp
IHsKLQkJYXR0cl9uYW1lID0gImZhdWx0IjsKLQl9IGVsc2UgaWYgKCFzdHJjbXAoYXR0cl9zdWZm
aXgsIERUX0RBVEFfQVRUUl9TVUZGSVgpKSB7Ci0JCWF0dHJfbmFtZSA9ICJpbnB1dCI7Ci0JfSBl
bHNlIGlmICghc3RyY21wKGF0dHJfc3VmZml4LCBEVF9USFJFU0hPTERfQVRUUl9TVUZGSVgpKSB7
Ci0JCWlmICh0eXBlID09IFRFTVApCi0JCQlhdHRyX25hbWUgPSAibWF4IjsKLQkJZWxzZSBpZiAo
dHlwZSA9PSBGQU4pCi0JCQlhdHRyX25hbWUgPSAibWluIjsKLQkJZWxzZQotCQkJcmV0dXJuIC1F
Tk9FTlQ7Ci0JfSBlbHNlIHsKKwlhdHRyX25hbWUgPSBjb252ZXJ0X29wYWxfYXR0cl9uYW1lKHR5
cGUsIGF0dHJfc3VmZml4KTsKKwlpZiAoIWF0dHJfbmFtZSkKIAkJcmV0dXJuIC1FTk9FTlQ7Ci0J
fQogCiAJc25wcmludGYoaHdtb25fYXR0cl9uYW1lLCBNQVhfQVRUUl9MRU4sICIlcyVkXyVzIiwK
IAkJIHNlbnNvcl9ncm91cHNbdHlwZV0ubmFtZSwgaW5kZXgsIGF0dHJfbmFtZSk7CgoKX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbG0tc2Vuc29ycyBtYWls
aW5nIGxpc3QKbG0tc2Vuc29yc0BsbS1zZW5zb3JzLm9yZwpodHRwOi8vbGlzdHMubG0tc2Vuc29y
cy5vcmcvbWFpbG1hbi9saXN0aW5mby9sbS1zZW5zb3Jz

[PATCH v2 3/5] hwmon: (ibmpowernv) add a convert_opal_attr_name() routine

[Cédric Le Goater]

It simplifies the create_hwmon_attr_name() routine and it clearly isolates
the conversion done between the OPAL node names and hwmon attributes names.

Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>
---

Changes since v1:

 - fixed alignment
 - killed a couple of useless "return NULL"

 drivers/hwmon/ibmpowernv.c |   36 ++++++++++++++++++++++--------------
 1 file changed, 22 insertions(+), 14 deletions(-)

Index: linux.git/drivers/hwmon/ibmpowernv.c
===================================================================
--- linux.git.orig/drivers/hwmon/ibmpowernv.c
+++ linux.git/drivers/hwmon/ibmpowernv.c
@@ -127,6 +127,25 @@ static int get_sensor_index_attr(const c
 	return 0;
 }
 
+static const char *convert_opal_attr_name(enum sensors type,
+					  const char *opal_attr)
+{
+	const char *attr_name = NULL;
+
+	if (!strcmp(opal_attr, DT_FAULT_ATTR_SUFFIX)) {
+		attr_name = "fault";
+	} else if (!strcmp(opal_attr, DT_DATA_ATTR_SUFFIX)) {
+		attr_name = "input";
+	} else if (!strcmp(opal_attr, DT_THRESHOLD_ATTR_SUFFIX)) {
+		if (type == TEMP)
+			attr_name = "max";
+		else if (type == FAN)
+			attr_name = "min";
+	}
+
+	return attr_name;
+}
+
 /*
  * This function translates the DT node name into the 'hwmon' attribute name.
  * IBMPOWERNV device node appear like cooling-fan#2-data, amb-temp#1-thrs etc.
@@ -138,7 +157,7 @@ static int create_hwmon_attr_name(struct
 					 char *hwmon_attr_name)
 {
 	char attr_suffix[MAX_ATTR_LEN];
-	char *attr_name;
+	const char *attr_name;
 	u32 index;
 	int err;
 
@@ -149,20 +168,9 @@ static int create_hwmon_attr_name(struct
 		return err;
 	}
 
-	if (!strcmp(attr_suffix, DT_FAULT_ATTR_SUFFIX)) {
-		attr_name = "fault";
-	} else if (!strcmp(attr_suffix, DT_DATA_ATTR_SUFFIX)) {
-		attr_name = "input";
-	} else if (!strcmp(attr_suffix, DT_THRESHOLD_ATTR_SUFFIX)) {
-		if (type == TEMP)
-			attr_name = "max";
-		else if (type == FAN)
-			attr_name = "min";
-		else
-			return -ENOENT;
-	} else {
+	attr_name = convert_opal_attr_name(type, attr_suffix);
+	if (!attr_name)
 		return -ENOENT;
-	}
 
 	snprintf(hwmon_attr_name, MAX_ATTR_LEN, "%s%d_%s",
 		 sensor_groups[type].name, index, attr_name);

[lm-sensors] [PATCH v2 4/5] hwmon: (ibmpowernv) change create_hwmon_attr_name() prototype

[Cédric Le Goater]

SXQgc2ltcGxpZmllcyB0aGUgY3JlYXRpb24gb2YgdGhlIGh3bW9uIGF0dHJpYnV0ZXMgYW5kIHdp
bGwgaGVscCB3aGVuCnN1cHBvcnQgZm9yIGEgbmV3IGRldmljZSB0cmVlIGxheW91dCBpcyBhZGRl
ZC4gVGhlIHBhdGNoIGFsc28gY2hhbmdlcwp0aGUgbmFtZSBvZiB0aGUgcm91dGluZSB0byBwYXJz
ZV9vcGFsX25vZGVfbmFtZSgpLgoKU2lnbmVkLW9mZi1ieTogQ8OpZHJpYyBMZSBHb2F0ZXIgPGNs
Z0Bmci5pYm0uY29tPgotLS0KCkNoYW5nZXMgc2luY2UgdjE6CgogLSBjaGFuZ2VkIHJldHVybmVk
IHZhbHVlIG9mIHBhcnNlX29wYWxfbm9kZV9uYW1lKCkKIC0gdXNlZCAqX1BUUiBtYWNyb3MgdG8g
Y2hlY2sgZm9yIGVycm9ycwoKIGRyaXZlcnMvaHdtb24vaWJtcG93ZXJudi5jIHwgICAzNyArKysr
KysrKysrKysrKysrKysrKy0tLS0tLS0tLS0tLS0tLS0tCiAxIGZpbGUgY2hhbmdlZCwgMjAgaW5z
ZXJ0aW9ucygrKSwgMTcgZGVsZXRpb25zKC0pCgpJbmRleDogbGludXguZ2l0L2RyaXZlcnMvaHdt
b24vaWJtcG93ZXJudi5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIGxpbnV4LmdpdC5vcmlnL2RyaXZlcnMvaHdt
b24vaWJtcG93ZXJudi5jCisrKyBsaW51eC5naXQvZHJpdmVycy9od21vbi9pYm1wb3dlcm52LmMK
QEAgLTE1MiwyOSArMTUyLDIyIEBAIHN0YXRpYyBjb25zdCBjaGFyICpjb252ZXJ0X29wYWxfYXR0
cl9uYW0KICAqIHdoaWNoIG5lZWQgdG8gYmUgbWFwcGVkIGFzIGZhbjJfaW5wdXQsIHRlbXAxX21h
eCByZXNwZWN0aXZlbHkgYmVmb3JlCiAgKiBwb3B1bGF0aW5nIHRoZW0gaW5zaWRlIGh3bW9uIGRl
dmljZSBjbGFzcy4KICAqLwotc3RhdGljIGludCBjcmVhdGVfaHdtb25fYXR0cl9uYW1lKHN0cnVj
dCBkZXZpY2UgKmRldiwgZW51bSBzZW5zb3JzIHR5cGUsCi0JCQkJCSBjb25zdCBjaGFyICpub2Rl
X25hbWUsCi0JCQkJCSBjaGFyICpod21vbl9hdHRyX25hbWUpCitzdGF0aWMgY29uc3QgY2hhciAq
cGFyc2Vfb3BhbF9ub2RlX25hbWUoY29uc3QgY2hhciAqbm9kZV9uYW1lLAorCQkJCQllbnVtIHNl
bnNvcnMgdHlwZSwgdTMyICppbmRleCkKIHsKIAljaGFyIGF0dHJfc3VmZml4W01BWF9BVFRSX0xF
Tl07CiAJY29uc3QgY2hhciAqYXR0cl9uYW1lOwotCXUzMiBpbmRleDsKIAlpbnQgZXJyOwogCi0J
ZXJyID0gZ2V0X3NlbnNvcl9pbmRleF9hdHRyKG5vZGVfbmFtZSwgJmluZGV4LCBhdHRyX3N1ZmZp
eCk7Ci0JaWYgKGVycikgewotCQlkZXZfZXJyKGRldiwgIlNlbnNvciBkZXZpY2Ugbm9kZSBuYW1l
ICclcycgaXMgaW52YWxpZFxuIiwKLQkJCW5vZGVfbmFtZSk7Ci0JCXJldHVybiBlcnI7Ci0JfQor
CWVyciA9IGdldF9zZW5zb3JfaW5kZXhfYXR0cihub2RlX25hbWUsIGluZGV4LCBhdHRyX3N1ZmZp
eCk7CisJaWYgKGVycikKKwkJcmV0dXJuIEVSUl9QVFIoZXJyKTsKIAogCWF0dHJfbmFtZSA9IGNv
bnZlcnRfb3BhbF9hdHRyX25hbWUodHlwZSwgYXR0cl9zdWZmaXgpOwogCWlmICghYXR0cl9uYW1l
KQotCQlyZXR1cm4gLUVOT0VOVDsKKwkJcmV0dXJuIEVSUl9QVFIoLUVOT0VOVCk7CiAKLQlzbnBy
aW50Zihod21vbl9hdHRyX25hbWUsIE1BWF9BVFRSX0xFTiwgIiVzJWRfJXMiLAotCQkgc2Vuc29y
X2dyb3Vwc1t0eXBlXS5uYW1lLCBpbmRleCwgYXR0cl9uYW1lKTsKLQlyZXR1cm4gMDsKKwlyZXR1
cm4gYXR0cl9uYW1lOwogfQogCiBzdGF0aWMgaW50IGdldF9zZW5zb3JfdHlwZShzdHJ1Y3QgZGV2
aWNlX25vZGUgKm5wKQpAQCAtMjQ5LDYgKzI0Miw5IEBAIHN0YXRpYyBpbnQgY3JlYXRlX2Rldmlj
ZV9hdHRycyhzdHJ1Y3QgcGwKIAl9CiAKIAlmb3JfZWFjaF9jaGlsZF9vZl9ub2RlKG9wYWwsIG5w
KSB7CisJCWNvbnN0IGNoYXIgKmF0dHJfbmFtZTsKKwkJdTMyIG9wYWxfaW5kZXg7CisKIAkJaWYg
KG5wLT5uYW1lID09IE5VTEwpCiAJCQljb250aW51ZTsKIApAQCAtMjY1LDEwICsyNjEsMTcgQEAg
c3RhdGljIGludCBjcmVhdGVfZGV2aWNlX2F0dHJzKHN0cnVjdCBwbAogCiAJCXNkYXRhW2NvdW50
XS5pZCA9IHNlbnNvcl9pZDsKIAkJc2RhdGFbY291bnRdLnR5cGUgPSB0eXBlOwotCQllcnIgPSBj
cmVhdGVfaHdtb25fYXR0cl9uYW1lKCZwZGV2LT5kZXYsIHR5cGUsIG5wLT5uYW1lLAotCQkJCQkg
ICAgIHNkYXRhW2NvdW50XS5uYW1lKTsKLQkJaWYgKGVycikKKworCQlhdHRyX25hbWUgPSBwYXJz
ZV9vcGFsX25vZGVfbmFtZShucC0+bmFtZSwgdHlwZSwgJm9wYWxfaW5kZXgpOworCQlpZiAoSVNf
RVJSKGF0dHJfbmFtZSkpIHsKKwkJCWRldl9lcnIoJnBkZXYtPmRldiwgIlNlbnNvciBkZXZpY2Ug
bm9kZSBuYW1lICclcycgaXMgaW52YWxpZFxuIiwKKwkJCQlucC0+bmFtZSk7CisJCQllcnIgPSBJ
U19FUlIoYXR0cl9uYW1lKTsKIAkJCWdvdG8gZXhpdF9wdXRfbm9kZTsKKwkJfQorCisJCXNucHJp
bnRmKHNkYXRhW2NvdW50XS5uYW1lLCBNQVhfQVRUUl9MRU4sICIlcyVkXyVzIiwKKwkJCSBzZW5z
b3JfZ3JvdXBzW3R5cGVdLm5hbWUsIG9wYWxfaW5kZXgsIGF0dHJfbmFtZSk7CiAKIAkJc3lzZnNf
YXR0cl9pbml0KCZzZGF0YVtjb3VudF0uZGV2X2F0dHIuYXR0cik7CiAJCXNkYXRhW2NvdW50XS5k
ZXZfYXR0ci5hdHRyLm5hbWUgPSBzZGF0YVtjb3VudF0ubmFtZTsKCgpfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpsbS1zZW5zb3JzIG1haWxpbmcgbGlzdAps
bS1zZW5zb3JzQGxtLXNlbnNvcnMub3JnCmh0dHA6Ly9saXN0cy5sbS1zZW5zb3JzLm9yZy9tYWls
bWFuL2xpc3RpbmZvL2xtLXNlbnNvcnM

[PATCH v2 4/5] hwmon: (ibmpowernv) change create_hwmon_attr_name() prototype

[Cédric Le Goater]

It simplifies the creation of the hwmon attributes and will help when
support for a new device tree layout is added. The patch also changes
the name of the routine to parse_opal_node_name().

Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>
---

Changes since v1:

 - changed returned value of parse_opal_node_name()
 - used *_PTR macros to check for errors

 drivers/hwmon/ibmpowernv.c |   37 ++++++++++++++++++++-----------------
 1 file changed, 20 insertions(+), 17 deletions(-)

Index: linux.git/drivers/hwmon/ibmpowernv.c
===================================================================
--- linux.git.orig/drivers/hwmon/ibmpowernv.c
+++ linux.git/drivers/hwmon/ibmpowernv.c
@@ -152,29 +152,22 @@ static const char *convert_opal_attr_nam
  * which need to be mapped as fan2_input, temp1_max respectively before
  * populating them inside hwmon device class.
  */
-static int create_hwmon_attr_name(struct device *dev, enum sensors type,
-					 const char *node_name,
-					 char *hwmon_attr_name)
+static const char *parse_opal_node_name(const char *node_name,
+					enum sensors type, u32 *index)
 {
 	char attr_suffix[MAX_ATTR_LEN];
 	const char *attr_name;
-	u32 index;
 	int err;
 
-	err = get_sensor_index_attr(node_name, &index, attr_suffix);
-	if (err) {
-		dev_err(dev, "Sensor device node name '%s' is invalid\n",
-			node_name);
-		return err;
-	}
+	err = get_sensor_index_attr(node_name, index, attr_suffix);
+	if (err)
+		return ERR_PTR(err);
 
 	attr_name = convert_opal_attr_name(type, attr_suffix);
 	if (!attr_name)
-		return -ENOENT;
+		return ERR_PTR(-ENOENT);
 
-	snprintf(hwmon_attr_name, MAX_ATTR_LEN, "%s%d_%s",
-		 sensor_groups[type].name, index, attr_name);
-	return 0;
+	return attr_name;
 }
 
 static int get_sensor_type(struct device_node *np)
@@ -249,6 +242,9 @@ static int create_device_attrs(struct pl
 	}
 
 	for_each_child_of_node(opal, np) {
+		const char *attr_name;
+		u32 opal_index;
+
 		if (np->name == NULL)
 			continue;
 
@@ -265,10 +261,17 @@ static int create_device_attrs(struct pl
 
 		sdata[count].id = sensor_id;
 		sdata[count].type = type;
-		err = create_hwmon_attr_name(&pdev->dev, type, np->name,
-					     sdata[count].name);
-		if (err)
+
+		attr_name = parse_opal_node_name(np->name, type, &opal_index);
+		if (IS_ERR(attr_name)) {
+			dev_err(&pdev->dev, "Sensor device node name '%s' is invalid\n",
+				np->name);
+			err = IS_ERR(attr_name);
 			goto exit_put_node;
+		}
+
+		snprintf(sdata[count].name, MAX_ATTR_LEN, "%s%d_%s",
+			 sensor_groups[type].name, opal_index, attr_name);
 
 		sysfs_attr_init(&sdata[count].dev_attr.attr);
 		sdata[count].dev_attr.attr.name = sdata[count].name;

Re: [lm-sensors] [PATCH v2 4/5] hwmon: (ibmpowernv) change create_hwmon_attr_name() prototype

[Cedric Le Goater]

[ ... ] 


> @@ -265,10 +261,17 @@ static int create_device_attrs(struct pl
> 
>  		sdata[count].id = sensor_id;
>  		sdata[count].type = type;
> -		err = create_hwmon_attr_name(&pdev->dev, type, np->name,
> -					     sdata[count].name);
> -		if (err)
> +
> +		attr_name = parse_opal_node_name(np->name, type, &opal_index);
> +		if (IS_ERR(attr_name)) {
> +			dev_err(&pdev->dev, "Sensor device node name '%s' is invalid\n",
> +				np->name);
> +			err = IS_ERR(attr_name);
                              ^^^^^^

Arg. Bad copy/paste. This should be PTR_ERR() ... 

Do you want a full patchset resend or just a resend of this patch ? or a fix maybe.

Sorry for the noise ...

C.  


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [PATCH v2 4/5] hwmon: (ibmpowernv) change create_hwmon_attr_name() prototype

[Cedric Le Goater]

[ ... ] 


> @@ -265,10 +261,17 @@ static int create_device_attrs(struct pl
> 
>  		sdata[count].id = sensor_id;
>  		sdata[count].type = type;
> -		err = create_hwmon_attr_name(&pdev->dev, type, np->name,
> -					     sdata[count].name);
> -		if (err)
> +
> +		attr_name = parse_opal_node_name(np->name, type, &opal_index);
> +		if (IS_ERR(attr_name)) {
> +			dev_err(&pdev->dev, "Sensor device node name '%s' is invalid\n",
> +				np->name);
> +			err = IS_ERR(attr_name);
                              ^^^^^^

Arg. Bad copy/paste. This should be PTR_ERR() ... 

Do you want a full patchset resend or just a resend of this patch ? or a fix maybe.

Sorry for the noise ...

C.  

Re: [lm-sensors] [PATCH v2 4/5] hwmon: (ibmpowernv) change create_hwmon_attr_name() prototype

[Guenter Roeck]

On Fri, Mar 20, 2015 at 09:06:38AM +0100, Cedric Le Goater wrote:
> [ ... ] 
> 
> 
> > @@ -265,10 +261,17 @@ static int create_device_attrs(struct pl
> > 
> >  		sdata[count].id = sensor_id;
> >  		sdata[count].type = type;
> > -		err = create_hwmon_attr_name(&pdev->dev, type, np->name,
> > -					     sdata[count].name);
> > -		if (err)
> > +
> > +		attr_name = parse_opal_node_name(np->name, type, &opal_index);
> > +		if (IS_ERR(attr_name)) {
> > +			dev_err(&pdev->dev, "Sensor device node name '%s' is invalid\n",
> > +				np->name);
> > +			err = IS_ERR(attr_name);
>                               ^^^^^^
> 
> Arg. Bad copy/paste. This should be PTR_ERR() ... 
> 
> Do you want a full patchset resend or just a resend of this patch ? or a fix maybe.
> 
No need to resend; I fixed it up.

Thanks,
Guenter

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [PATCH v2 4/5] hwmon: (ibmpowernv) change create_hwmon_attr_name() prototype

[Guenter Roeck]

On Fri, Mar 20, 2015 at 09:06:38AM +0100, Cedric Le Goater wrote:
> [ ... ] 
> 
> 
> > @@ -265,10 +261,17 @@ static int create_device_attrs(struct pl
> > 
> >  		sdata[count].id = sensor_id;
> >  		sdata[count].type = type;
> > -		err = create_hwmon_attr_name(&pdev->dev, type, np->name,
> > -					     sdata[count].name);
> > -		if (err)
> > +
> > +		attr_name = parse_opal_node_name(np->name, type, &opal_index);
> > +		if (IS_ERR(attr_name)) {
> > +			dev_err(&pdev->dev, "Sensor device node name '%s' is invalid\n",
> > +				np->name);
> > +			err = IS_ERR(attr_name);
>                               ^^^^^^
> 
> Arg. Bad copy/paste. This should be PTR_ERR() ... 
> 
> Do you want a full patchset resend or just a resend of this patch ? or a fix maybe.
> 
No need to resend; I fixed it up.

Thanks,
Guenter

[lm-sensors] [PATCH v2 5/5] hwmon: (ibmpowernv) do not use the OPAL index for hwmon attribute names

[Cédric Le Goater]

VGhlIGN1cnJlbnQgT1BBTCBmaXJtd2FyZSBleHBvc2VzIHRoZSBkaWZmZXJlbnQgc2Vuc29ycyBv
ZiBhbiBJQk0gUG93ZXIKc3lzdGVtIHVzaW5nIG5vZGUgbmFtZXMgc3VjaCBhcyA6CgoJc2Vuc29y
cy9hbWItdGVtcCMxLWRhdGEKCXNlbnNvcnMvYW1iLXRlbXAjMS10aHJzCgljb29saW5nLWZhbiMx
LWRhdGEKCWNvb2xpbmctZmFuIzEtZmF1bHRlZAoJY29vbGluZy1mYW4jMS10aHJzCgljb29saW5n
LWZhbiMyLWRhdGEKCS4uLgoKVGhlIGlibXBvd2VybnYgZHJpdmVyLCB3aGVuIGxvYWRlZCwgcGFy
c2VzIHRoZXNlIG5hbWVzIHRvIGV4dHJhY3QgdGhlCnNlbnNvciBpbmRleCBhbmQgdGhlIHNlbnNv
ciBhdHRyaWJ1dGUgbmFtZS4gVW5mb3J0dW5hdGVseSwgdGhpcyBzY2hlbWUKbWFrZXMgaXQgZGlm
ZmljdWx0IHRvIGFkZCBzZW5zb3JzIHdpdGggYSBkaWZmZXJlbnQgbGF5b3V0IChzcGVjaWFsbHkg
b2YKdGhlIHNhbWUgdHlwZSwgbGlrZSB0ZW1wZXJhdHVyZSkgYXMgdGhlIHNlbnNvciBpbmRleCBj
YWxjdWxhdGVkIGluIE9QQUwKaXMgZGlyZWN0bHkgdXNlZCBpbiB0aGUgaHdtb24gc3lzZnMgaW50
ZXJmYWNlLgoKV2hhdCB0aGlzIHBhdGNoIGRvZXMgaXMgYWRkIGEgaW5kZXBlbmRlbnQgaHdtb24g
aW5kZXggZm9yIGVhY2ggc2Vuc29yLgpUaGUgaW5jcmVtZW50IG9mIHRoZSBod21vbiBpbmRleCAo
dGVtcCwgZmFuLCBwb3dlciwgZXRjLikgaXMga2VwdCBwZXIKc2Vuc29yIHR5cGUgaW4gdGhlIHNl
bnNvcl9ncm91cCB0YWJsZS4gVGhlIHNlbnNvcl9kYXRhIHRhYmxlIGlzIHVzZWQKdG8gc3RvcmUg
dGhlIGFzc29jaWF0aW9uIG9mIHRoZSBod21vbiBhbmQgT1BBTCBpbmRleGVzLCBhcyB3ZSBuZWVk
IHRvCmhhdmUgdGhlIHNhbWUgaHdtb24gaW5kZXggZm9yIGRpZmZlcmVudCBhdHRyaWJ1dGVzIG9m
IGEgc2FtZSBzZW5zb3IuCgpTaWduZWQtb2ZmLWJ5OiBDw6lkcmljIExlIEdvYXRlciA8Y2xnQGZy
LmlibS5jb20+Ci0tLQogZHJpdmVycy9od21vbi9pYm1wb3dlcm52LmMgfCAgIDIzICsrKysrKysr
KysrKysrKysrKysrKystCiAxIGZpbGUgY2hhbmdlZCwgMjIgaW5zZXJ0aW9ucygrKSwgMSBkZWxl
dGlvbigtKQoKSW5kZXg6IGxpbnV4LmdpdC9kcml2ZXJzL2h3bW9uL2libXBvd2VybnYuYwo9PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09Ci0tLSBsaW51eC5naXQub3JpZy9kcml2ZXJzL2h3bW9uL2libXBvd2VybnYuYworKysg
bGludXguZ2l0L2RyaXZlcnMvaHdtb24vaWJtcG93ZXJudi5jCkBAIC01NSw2ICs1NSw3IEBAIHN0
YXRpYyBzdHJ1Y3Qgc2Vuc29yX2dyb3VwIHsKIAljb25zdCBjaGFyICpjb21wYXRpYmxlOwogCXN0
cnVjdCBhdHRyaWJ1dGVfZ3JvdXAgZ3JvdXA7CiAJdTMyIGF0dHJfY291bnQ7CisJdTMyIGh3bW9u
X2luZGV4OwogfSBzZW5zb3JfZ3JvdXBzW10gPSB7CiAJeyJmYW4iLCAiaWJtLG9wYWwtc2Vuc29y
LWNvb2xpbmctZmFuIn0sCiAJeyJ0ZW1wIiwgImlibSxvcGFsLXNlbnNvci1hbWItdGVtcCJ9LApA
QCAtNjQsNiArNjUsOCBAQCBzdGF0aWMgc3RydWN0IHNlbnNvcl9ncm91cCB7CiAKIHN0cnVjdCBz
ZW5zb3JfZGF0YSB7CiAJdTMyIGlkOyAvKiBBbiBvcGFxdWUgaWQgb2YgdGhlIGZpcm13YXJlIGZv
ciBlYWNoIHNlbnNvciAqLworCXUzMiBod21vbl9pbmRleDsKKwl1MzIgb3BhbF9pbmRleDsKIAll
bnVtIHNlbnNvcnMgdHlwZTsKIAljaGFyIG5hbWVbTUFYX0FUVFJfTEVOXTsKIAlzdHJ1Y3QgZGV2
aWNlX2F0dHJpYnV0ZSBkZXZfYXR0cjsKQEAgLTE4MSw2ICsxODQsMTkgQEAgc3RhdGljIGludCBn
ZXRfc2Vuc29yX3R5cGUoc3RydWN0IGRldmljZQogCXJldHVybiBNQVhfU0VOU09SX1RZUEU7CiB9
CiAKK3N0YXRpYyB1MzIgZ2V0X3NlbnNvcl9od21vbl9pbmRleChzdHJ1Y3Qgc2Vuc29yX2RhdGEg
KnNkYXRhLAorCXN0cnVjdCBzZW5zb3JfZGF0YSAqc2RhdGFfdGFibGUsIGludCBjb3VudCkKK3sK
KwlpbnQgaTsKKworCWZvciAoaSA9IDA7IGkgPCBjb3VudDsgaSsrKQorCQlpZiAoc2RhdGFfdGFi
bGVbaV0ub3BhbF9pbmRleCA9PSBzZGF0YS0+b3BhbF9pbmRleCAmJgorCQkgICAgc2RhdGFfdGFi
bGVbaV0udHlwZSA9PSBzZGF0YS0+dHlwZSkKKwkJCXJldHVybiBzZGF0YV90YWJsZVtpXS5od21v
bl9pbmRleDsKKworCXJldHVybiArK3NlbnNvcl9ncm91cHNbc2RhdGEtPnR5cGVdLmh3bW9uX2lu
ZGV4OworfQorCiBzdGF0aWMgaW50IHBvcHVsYXRlX2F0dHJfZ3JvdXBzKHN0cnVjdCBwbGF0Zm9y
bV9kZXZpY2UgKnBkZXYpCiB7CiAJc3RydWN0IHBsYXRmb3JtX2RhdGEgKnBkYXRhID0gcGxhdGZv
cm1fZ2V0X2RydmRhdGEocGRldik7CkBAIC0yNzAsOCArMjg2LDEzIEBAIHN0YXRpYyBpbnQgY3Jl
YXRlX2RldmljZV9hdHRycyhzdHJ1Y3QgcGwKIAkJCWdvdG8gZXhpdF9wdXRfbm9kZTsKIAkJfQog
CisJCXNkYXRhW2NvdW50XS5vcGFsX2luZGV4ID0gb3BhbF9pbmRleDsKKwkJc2RhdGFbY291bnRd
Lmh3bW9uX2luZGV4ID0KKwkJCWdldF9zZW5zb3JfaHdtb25faW5kZXgoJnNkYXRhW2NvdW50XSwg
c2RhdGEsIGNvdW50KTsKKwogCQlzbnByaW50ZihzZGF0YVtjb3VudF0ubmFtZSwgTUFYX0FUVFJf
TEVOLCAiJXMlZF8lcyIsCi0JCQkgc2Vuc29yX2dyb3Vwc1t0eXBlXS5uYW1lLCBvcGFsX2luZGV4
LCBhdHRyX25hbWUpOworCQkJIHNlbnNvcl9ncm91cHNbdHlwZV0ubmFtZSwgc2RhdGFbY291bnRd
Lmh3bW9uX2luZGV4LAorCQkJIGF0dHJfbmFtZSk7CiAKIAkJc3lzZnNfYXR0cl9pbml0KCZzZGF0
YVtjb3VudF0uZGV2X2F0dHIuYXR0cik7CiAJCXNkYXRhW2NvdW50XS5kZXZfYXR0ci5hdHRyLm5h
bWUgPSBzZGF0YVtjb3VudF0ubmFtZTsKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXwpsbS1zZW5zb3JzIG1haWxpbmcgbGlzdApsbS1zZW5zb3JzQGxtLXNl
bnNvcnMub3JnCmh0dHA6Ly9saXN0cy5sbS1zZW5zb3JzLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xt
LXNlbnNvcnM

[PATCH v2 5/5] hwmon: (ibmpowernv) do not use the OPAL index for hwmon attribute names

[Cédric Le Goater]

The current OPAL firmware exposes the different sensors of an IBM Power
system using node names such as :

	sensors/amb-temp#1-data
	sensors/amb-temp#1-thrs
	cooling-fan#1-data
	cooling-fan#1-faulted
	cooling-fan#1-thrs
	cooling-fan#2-data
	...

The ibmpowernv driver, when loaded, parses these names to extract the
sensor index and the sensor attribute name. Unfortunately, this scheme
makes it difficult to add sensors with a different layout (specially of
the same type, like temperature) as the sensor index calculated in OPAL
is directly used in the hwmon sysfs interface.

What this patch does is add a independent hwmon index for each sensor.
The increment of the hwmon index (temp, fan, power, etc.) is kept per
sensor type in the sensor_group table. The sensor_data table is used
to store the association of the hwmon and OPAL indexes, as we need to
have the same hwmon index for different attributes of a same sensor.

Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>
---
 drivers/hwmon/ibmpowernv.c |   23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

Index: linux.git/drivers/hwmon/ibmpowernv.c
===================================================================
--- linux.git.orig/drivers/hwmon/ibmpowernv.c
+++ linux.git/drivers/hwmon/ibmpowernv.c
@@ -55,6 +55,7 @@ static struct sensor_group {
 	const char *compatible;
 	struct attribute_group group;
 	u32 attr_count;
+	u32 hwmon_index;
 } sensor_groups[] = {
 	{"fan", "ibm,opal-sensor-cooling-fan"},
 	{"temp", "ibm,opal-sensor-amb-temp"},
@@ -64,6 +65,8 @@ static struct sensor_group {
 
 struct sensor_data {
 	u32 id; /* An opaque id of the firmware for each sensor */
+	u32 hwmon_index;
+	u32 opal_index;
 	enum sensors type;
 	char name[MAX_ATTR_LEN];
 	struct device_attribute dev_attr;
@@ -181,6 +184,19 @@ static int get_sensor_type(struct device
 	return MAX_SENSOR_TYPE;
 }
 
+static u32 get_sensor_hwmon_index(struct sensor_data *sdata,
+	struct sensor_data *sdata_table, int count)
+{
+	int i;
+
+	for (i = 0; i < count; i++)
+		if (sdata_table[i].opal_index == sdata->opal_index &&
+		    sdata_table[i].type == sdata->type)
+			return sdata_table[i].hwmon_index;
+
+	return ++sensor_groups[sdata->type].hwmon_index;
+}
+
 static int populate_attr_groups(struct platform_device *pdev)
 {
 	struct platform_data *pdata = platform_get_drvdata(pdev);
@@ -270,8 +286,13 @@ static int create_device_attrs(struct pl
 			goto exit_put_node;
 		}
 
+		sdata[count].opal_index = opal_index;
+		sdata[count].hwmon_index =
+			get_sensor_hwmon_index(&sdata[count], sdata, count);
+
 		snprintf(sdata[count].name, MAX_ATTR_LEN, "%s%d_%s",
-			 sensor_groups[type].name, opal_index, attr_name);
+			 sensor_groups[type].name, sdata[count].hwmon_index,
+			 attr_name);
 
 		sysfs_attr_init(&sdata[count].dev_attr.attr);
 		sdata[count].dev_attr.attr.name = sdata[count].name;