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

[Guenter Roeck <linux@roeck-us.net>]

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