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@xxxxxxxxxxxxxx http://lists.lm-sensors.org/mailman/listinfo/lm-sensors