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

Guenter Roeck linux at roeck-us.net
Sat Feb 21 22:03:08 AEDT 2015


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



More information about the Skiboot mailing list