[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1475026240.4284.17.camel@intel.com>
Date: Wed, 28 Sep 2016 09:30:40 +0800
From: Zhang Rui <rui.zhang@...el.com>
To: Eduardo Valentin <edubezval@...il.com>,
Lukasz Luba <lukasz.luba@....com>
Cc: Inhyuk Kang <hugh.kang@....com>, linux-pm@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] of: thermal: Fixed governor at each thermal zone
Hi, Javi, Lukasz and Eduardo,
thanks for your input.
thanks,
rui
On 二, 2016-09-27 at 06:22 -0700, Eduardo Valentin wrote:
> Hello, Lukasz, Inhyuk, Javi,
>
> On Tue, Sep 27, 2016 at 12:52:04PM +0100, Lukasz Luba wrote:
> >
> >
> > On 27/09/16 02:46, Zhang Rui wrote:
> > >
> > > On 一, 2016-09-19 at 10:18 +0900, Inhyuk Kang wrote:
> > > >
> > > > It is necessary to be added governor at each thermal_zone.
> > > > Because some governors should be operated in the during the
> > > > kernel
> > > > booting
> > > > in order to avoid heating problem.
> > > >
> > > > Default governor cannot be covered all thermal zones policy
> > > > because
> > > > some thermal zones want to apply different one.
> > > > For example, the power allocator governor operates differently
> > > > with
> > > > step wise governor.
> > > > Hence, it is better to parse governor parameter from the device
> > > > tree.
> > > >
> > > > Signed-off-by: Inhyuk Kang <hugh.kang@....com>
> > > >
> > > The patch looks okay to me.
> > > Eduardo, what do you think of this patch?
> > Hi Rui,
> >
> > Beside the fact which Javi pointed out in his email, there is an
> > issue in
> > the patch itself.
> > The idea behind the patch is good, but the patch should have some
> > improvements, i.e:
> > - strncpy instead of strcpy,
> > - if the governor name is not found in the registered governor's
> > list by
> > __find_governor (and then null is set) we should probably switch to
> > default
> > governor,
> > - add DT documentation,
> Also, the idea of the patch is good, almost tempting to do it, but
> unfortunately, not acceptable from DT perspective. The patch
> infringes
> two of the DT conceptual and design decision of:
> (a) DT should describe hardware, not policy;
> (b) DT should describe hardware, not OS specific implementations.
>
> As already pointed by Javi, this patch has already been proposed
> (more
> than one time by different people), but, it still continues to be
> unacceptable.
>
> Cheers,
>
>
> >
> >
> > Regards,
> > Lukasz
> >
Powered by blists - more mailing lists