[PATCH V9] thermal: bcm2835: add thermal driver for bcm2835 soc

kernel at martin.sperl.org kernel at martin.sperl.org
Wed Feb 8 00:19:48 PST 2017


> On 08.02.2017, at 05:31, Eduardo Valentin <edubezval at gmail.com> wrote:
> 
> On Sat, Feb 04, 2017 at 09:35:47AM +0100, kernel at martin.sperl.org wrote:
>> 
> 
>> So how does this change/impact the driver code itself?
>> 
>> Defining a thermal zone in the dts is just an additional feature
>> that only impacts the device tree.
>> The DT as is works fine and at least allows to read the current temperature.
> 
> Well, your driver is still half finished. It is a DT only driver, which
> does not follow the DT spec on thermal. The impact on your code is that
> it wont need to carry your hardware data in the source code.
> 
> Also, having the data described in DT allows you porting your driver
> without patching it, in  case you need, or any other system engineer,
> to have different thermal data, trips values, number or trips, offset
> and slope per sensor, on different boards, or even on different chip
> version.
> 
> Not to say that having the data described in DT also allows system
> engineers to deploy different thermal zones, based on your
> driver/sensor, to extrapolate different hotspots.
> 

That is all true and as far as I understand you can do all of that
using the current driver - see the patch-sets by Stefan Wahren that
incorporates this into the dts.

My point is still: there are dtb’s that come with 4.10-rcX
that do not have all of those defined 

But as the mantra for DT is: "it is an API”, we have to be backwards
compatible from the driver perspective.
So we need those values in the driver to ensure the older version
of dtb’s are working correctly. That is why it is still included.

Also the settings of the trip are for the HW trip point for the case
that a future version of the firmware does not set up the thermal
HW block.

Do you really want to break this Mantra of backwards compatibility
by having those compatiblity “defines” stripped out with all the
possible negative side-effects if things are not set up correctly?

Thanks,
	Martin

P.s: I find it strange that V3 of the driver was sent out in May 2016
(way before the DTS changes got merged) and you only started to 
give feedback in November only in V8 (that primarily incorporated
minor changes and a rebase to 4.9) by which time the changes to the
dts have already been merged.






More information about the linux-arm-kernel mailing list