Re: [PATCH] thermal: imx: fix for dependency on cpu-freq

[Lucas Stach]

Am Dienstag, den 20.11.2018, 10:29 +0100 schrieb Daniel Lezcano:
> On 20/11/2018 09:58, Anson Huang wrote:
> > Hi, Daniel
> > 
> > Best Regards!
> > Anson Huang
> > 
> > > -----Original Message-----
> > > From: Daniel Lezcano [mailto:daniel.lezcano@xxxxxxxxxx]
> > > Sent: 2018å11æ20æ 16:54
> > > To: Anson Huang <anson.huang@xxxxxxx>; rui.zhang@xxxxxxxxx;
> > > edubezval@xxxxxxxxx; linux-pm@xxxxxxxxxxxxxxx;
> > > linux-kernel@xxxxxxxxxxxxxxx
> > > Cc: dl-linux-imx <linux-imx@xxxxxxx>
> > > Subject: Re: [PATCH] thermal: imx: fix for dependency on cpu-freq
> > > 
> > > On 20/11/2018 09:47, Anson Huang wrote:
> > > > Hi, Daniel
> > > > 
> > > > Best Regards!
> > > > Anson Huang
> > > > 
> > > > > -----Original Message-----
> > > > > From: Daniel Lezcano [mailto:daniel.lezcano@xxxxxxxxxx]
> > > > > Sent: 2018å11æ20æ 16:45
> > > > > To: Anson Huang <anson.huang@xxxxxxx>; rui.zhang@xxxxxxxxx;
> > > > > edubezval@xxxxxxxxx; linux-pm@xxxxxxxxxxxxxxx;
> > > > > linux-kernel@xxxxxxxxxxxxxxx
> > > > > Cc: dl-linux-imx <linux-imx@xxxxxxx>
> > > > > Subject: Re: [PATCH] thermal: imx: fix for dependency on cpu-
> > > > > freq
> > > > > 
> > > > > On 24/10/2018 08:39, Anson Huang wrote:
> > > > > > The thermal driver is a standalone driver for monitoring
> > > > > > SoC
> > > > > > temperature by enabling thermal sensor, so it can be
> > > > > > enabled even
> > > > > > when CONFIG_CPU_FREQ is NOT set. So remove the dependency
> > > > > > with
> > > > > 
> > > > > CPU_THERMAL.
> > > > > > 
> > > > > > Add CONFIG_CPU_FREQ check for cpu-freq related operation in
> > > > > > thermal
> > > > > > driver to make thermal driver probe successfully when
> > > > > > CONFIG_CPU_FREQ is NOT set.
> > > > > > 
> > > > > > Signed-off-by: Anson Huang <Anson.Huang@xxxxxxx>
> > > > > > ---
> > > > > 
> > > > > Why not simply kill this legacy code ?
> > > > 
> > > > Because killing legacy code will have old dtb compatible issue,
> > > > old
> > > > dtb will NOT have cpufreq cooling function.
> > > 
> > > Yeah, I imagine that is the reason why you want to keep the
> > > legacy code but do
> > > you really care about old DTB based boards? Are they still
> > > updated with newer
> > > *upstream vanilla* kernels?
> > 
> > I am NOT sure if there is someone care about it, but I did receive
> > many comments
> > about old dtb compatible when I sent out other patches, so is it a
> > solid requirement
> > of old dtb compatible when doing upstream, or each sub-system or
> > maintainer has
> > different requirement about it? Actually I am happy to just remove
> > the legacy
> > code, because it makes the code more clean and easy reading. Who
> > can make the
> > decision?
> 
> Yes, making sure to not break the compatibility makes the patch
> submission easier. However, sometime it makes sense to put in
> question
> if keeping old (and hackish) code really matters.
> 
> Old boards are rarely updated with newer kernels and when that
> happens,
> usually the DT is updated also.
> 
> IMO, this decision is in the hands of the platform maintainers. I
> suggest to send a patch removing the legacy code Cc'ing all of them.

On i.MX we usually try to keep DT compatibility as much as possible.
There are cases where keeping the compatibility is just too much of a
burden on maintenance, but IMHO this is not the case for the piece of
code in question here.

Regards,
Lucas