linux-kernel - Re: [PATCH 1/3] PM / devfreq: set min/max freq limit from freq table

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Tue, 5 Feb 2013 15:51:51 +0900
From:	MyungJoo Ham <myungjoo.ham@...il.com>
To:	Rajagopal Venkat <rajagopal.venkat@...aro.org>
Cc:	kyungmin.park@...sung.com, mturquette@...aro.org, rjw@...k.pl,
	patches@...aro.org, linaro-dev@...ts.linaro.org,
	linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/3] PM / devfreq: set min/max freq limit from freq table

On Tue, Jan 15, 2013 at 8:21 PM, Rajagopal Venkat
<rajagopal.venkat@...aro.org> wrote:
> On 14 January 2013 20:06, MyungJoo Ham <myungjoo.ham@...sung.com> wrote:
>> On Tue, Jan 8, 2013 at 2:50 PM, Rajagopal Venkat
>> <rajagopal.venkat@...aro.org> wrote:
>>> Set devfreq device min and max frequency limits when device
>>> is added to devfreq, provided frequency table is supplied.
>>> This helps governors to suggest target frequency with in
>>> limits.
>>>
>>> Signed-off-by: Rajagopal Venkat <rajagopal.venkat@...aro.org>
>>
>> Could you please elaborate the benefit of the patch?
>>
>
> When freq table is supplied, it's unreasonable to suggest the target frequency
> which is - target_freq < min_freq and target_freq > max_freq. It avoids
> unnecessary checks at devfreq drivers.

Is it a safety barrier against userspace processes or devfreq governors?
Users are allowed to enter min_freq and max_freq via sysfs interfaces anyway.
Also, as mentioned earlier, users are allowed to enter 0 in order to
"disengage" the min/max_freq.
If we need "hardware-specific" min/max value, we'd need another sysfs
interfaces and values (i.e., scaling_min/max_freq vs
cpuinfo_min/max_freq).

Besides, if you are able to provide "freq_table", it means that you
are able to provide OPP for the device.
Then, you can use OPP APIs to avoid unnecessary checks at devfreq
driver (even you can use the devfreq helper functions)

>
>> The devfreq device drivers are required to choose proper frequencies
>> anyway regardless which values the governors may give (hopefully by
>> choosing the closest value that can support the required performance).
>>
>
> Yes. but then each driver needs to have conditional checks for choosing
> closet value even though freq table is provided.

Even with this min/max-freq, when governors suggests some values
between min/max, each driver needs to have checks unless it uses OPP.

>
>> Besides, the min/max values are to be set by userspace. Users may
>> enter 0 in order to express that they do not want to limit the
>> behaviors of governors.

Because of this, this patch will create discrepency from/to userspace
interfaces.




Cheers,
MyungJoo.

>>
>>
>> Cheers,
>> MyungJoo.
>>
>>> ---
>>>  drivers/devfreq/devfreq.c |   24 ++++++++++++++++++++++++
>>>  1 file changed, 24 insertions(+)
>>>
>>> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
>>> index a8f0173..5782c9b 100644
>>> --- a/drivers/devfreq/devfreq.c
>>> +++ b/drivers/devfreq/devfreq.c
>>> @@ -69,6 +69,29 @@ static struct devfreq *find_device_devfreq(struct device *dev)
>>>  }
>>>
>>>  /**
>>> + * devfreq_set_freq_limits() - Set min and max frequency from freq_table
>>> + * @devfreq:   the devfreq instance
>>> + */
>>> +static void devfreq_set_freq_limits(struct devfreq *devfreq)
>>> +{
>>> +       int idx;
>>> +       unsigned long min = ~0, max = 0;
>>> +
>>> +       if (!devfreq->profile->freq_table)
>>> +               return;
>>> +
>>> +       for (idx = 0; idx < devfreq->profile->max_state; idx++) {
>>> +               if (min > devfreq->profile->freq_table[idx])
>>> +                       min = devfreq->profile->freq_table[idx];
>>> +               if (max < devfreq->profile->freq_table[idx])
>>> +                       max = devfreq->profile->freq_table[idx];
>>> +       }
>>> +
>>> +       devfreq->min_freq = min;
>>> +       devfreq->max_freq = max;
>>> +}
>>> +
>>> +/**
>>>   * devfreq_get_freq_level() - Lookup freq_table for the frequency
>>>   * @devfreq:   the devfreq instance
>>>   * @freq:      the target frequency
>>> @@ -476,6 +499,7 @@ struct devfreq *devfreq_add_device(struct device *dev,
>>>                                                 devfreq->profile->max_state,
>>>                                                 GFP_KERNEL);
>>>         devfreq->last_stat_updated = jiffies;
>>> +       devfreq_set_freq_limits(devfreq);
>>>
>>>         dev_set_name(&devfreq->dev, dev_name(dev));
>>>         err = device_register(&devfreq->dev);
>>> --
>>> 1.7.10.4
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-pm" in
>>> the body of a message to majordomo@...r.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>>
>>
>> --
>> MyungJoo Ham, Ph.D.
>> Mobile Software Platform Lab, DMC Business, Samsung Electronics
>
>
>
> --
> Regards,
> Rajagopal



-- 
MyungJoo Ham, Ph.D.
System S/W Lab, S/W Center, Samsung Electronics
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/