linux-kernel - Re: [PATCH] clk: at91: clk-generated: Limit the requested rate to our range

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:   Fri, 16 Jul 2021 21:17:06 +0200
From:   Nicolas Ferre <nicolas.ferre@...rochip.com>
To:     Codrin Ciubotariu - M19940 <Codrin.Ciubotariu@...rochip.com>,
        "linux-clk@...r.kernel.org" <linux-clk@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
CC:     "mturquette@...libre.com" <mturquette@...libre.com>,
        "sboyd@...nel.org" <sboyd@...nel.org>,
        "alexandre.belloni@...tlin.com" <alexandre.belloni@...tlin.com>,
        Ludovic Desroches - M43218 <Ludovic.Desroches@...rochip.com>,
        Claudiu Beznea - M18063 <Claudiu.Beznea@...rochip.com>
Subject: Re: [PATCH] clk: at91: clk-generated: Limit the requested rate to our
 range

On 09/07/2021 at 11:59, Codrin Ciubotariu - M19940 wrote:
> On 09.07.2021 12:21, Nicolas Ferre wrote:
>> On 07/07/2021 at 15:12, Codrin Ciubotariu wrote:
>>> On clk_generated_determine_rate(), the requested rate could be outside
>>> of clk's range. Limit the rate to the clock's range to not return an
>>> error.
>>
>> Isn't it saner for the user to return an error code instead of
>> automatically restrain the dynamics requested without notice?
>>
>> Can you elaborate the use case where returning an error is not convenient?
> 
> The way I see it, if the user requests a rate that is out of clock's
> range, the driver's determine_rate() should return min/max, not an
> error. That is actually the closest rate supported by the clock, which
> is what determine_rate() should accomplish. The user has no clk API to
> get clock's range, so there is no way to call clk_round_rate() only for
> values within our range.
> 
> The use cause is with sam9x60's I2S driver, which has to try different
> rates to get the closest one to what it needs. There is no 'perfect'
> rate, because there is no AUDIO PLL and we have to try different values
> for our internal dividers to find the closest one.
> 
> https://elixir.bootlin.com/linux/latest/source/sound/soc/atmel/mchp-i2s-mcc.c#L416

Sure, makes sense:

Acked-by: Nicolas Ferre <nicolas.ferre@...rochip.com>

Regards,
   Nicolas

-- 
Nicolas Ferre