linux-kernel - RE: Re: [PATCH 1/3] PM / devfreq: Actually support providing freq

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 24 Apr 2018 15:09:14 +0900
From:   MyungJoo Ham <myungjoo.ham@...sung.com>
To:     Bjorn Andersson <bjorn.andersson@...aro.org>,
        Chanwoo Choi <cw00.choi@...sung.com>
CC:     Kyungmin Park <kyungmin.park@...sung.com>,
        Vinayak Holikatti <vinholikatti@...il.com>,
        "James E.J. Bottomley" <jejb@...ux.vnet.ibm.com>,
        "Martin K. Petersen" <martin.petersen@...cle.com>,
        "linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
        "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-arm-msm@...r.kernel.org" <linux-arm-msm@...r.kernel.org>,
        Vivek Gautam <vivek.gautam@...eaurora.org>
Subject: RE: Re: [PATCH 1/3] PM / devfreq: Actually support providing
 freq_table

>On Mon 23 Apr 19:48 PDT 2018, Chanwoo Choi wrote:
>
>> Hi,
>> 
>> On 2018??? 04??? 24??? 09:20, Bjorn Andersson wrote:
>> > The code in devfreq_add_device() handles the case where a freq_table is
>> > passed by the client, but then requests min and max frequences from
>> > the, in this case absent, opp tables.
>> > 
>> > Read the min and max frequencies from the frequency table, which has
>> > been built from the opp table if one exists, instead of querying the
>> > opp table.
>> > 
>> > Signed-off-by: Bjorn Andersson <bjorn.andersson@...aro.org>
>> > ---
>> > 
>> > An alternative approach is to clarify in the devfreq code that it's not
>> > possible to pass a freq_table and then in patch 3 create an opp table for the
>> > device in runtime; although the error handling of this becomes non-trivial.
>> > 
>> > Transitioning the UFSHCD to use opp tables directly is hindered by the fact
>> > that the Qualcomm UFS hardware has two different clocks that needs to be
>> > running at different rates, so we would need a way to describe the two rates in
>> > the opp table. (And would force us to change the DT binding)
>> > 
>> >  drivers/devfreq/devfreq.c | 22 ++++------------------
>> >  1 file changed, 4 insertions(+), 18 deletions(-)
>> > 
>> > diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
>> > index fe2af6aa88fc..086ced50a13d 100644
>> > --- a/drivers/devfreq/devfreq.c
>> > +++ b/drivers/devfreq/devfreq.c
>> > @@ -74,30 +74,16 @@ static struct devfreq *find_device_devfreq(struct device *dev)
>> >  
>> >  static unsigned long find_available_min_freq(struct devfreq *devfreq)
>> >  {
>> > -	struct dev_pm_opp *opp;
>> > -	unsigned long min_freq = 0;
>> > -
>> > -	opp = dev_pm_opp_find_freq_ceil(devfreq->dev.parent, &min_freq);
>> > -	if (IS_ERR(opp))
>> > -		min_freq = 0;
>> > -	else
>> > -		dev_pm_opp_put(opp);
>> > +	struct devfreq_dev_profile *profile = devfreq->profile;
>> >  
>> > -	return min_freq;
>> > +	return profile->freq_table[0];
>> 
>> It is wrong. The thermal framework support the devfreq-cooling device
>> which uses the dev_pm_opp_enable/disable().
>> 
>
>Okay, that makes sense. So rather than registering a custom freq_table I
>should register the min and max frequency using dev_pm_opp_add().
>
>> In order to find the correct available min frequency,
>> the devfreq have to use the OPP function instead of using the first entry
>> of the freq_table array.
>> 
>
>Based on this there seems to be room for cleaning out the freq_table
>from devfreq, to reduce the confusion. I will review this further.

Could you please check if the bug suffering you gets resolved by
replacing 0 with ULONG_MAX in the function find_available_max_freq?

-                max_freq = 0;
+                max_freq = ULONG_MAX;

Even if you are not using OPP, these functions should provide somewhat
"compatible" values.

Cheers,
MyungJoo


>
>Thanks,
>Bjorn
>