linux-kernel - Re: [PATCH] pwm: Use div64_ul instead of do

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] [day] [month] [year] [list]

Message-ID: <a9a62f9d-7227-0421-e36f-44222b79bbe7@microchip.com>
Date:   Thu, 18 Nov 2021 14:19:37 +0100
From:   Nicolas Ferre <nicolas.ferre@...rochip.com>
To:     "Russell King (Oracle)" <linux@...linux.org.uk>,
        Uwe Kleine-König <u.kleine-koenig@...gutronix.de>
CC:     <cgel.zte@...il.com>, <linux-pwm@...r.kernel.org>,
        <alexandre.belloni@...tlin.com>, Zeal Robot <zealci@....com.cn>,
        <linux-kernel@...r.kernel.org>, <ludovic.desroches@...rochip.com>,
        <thierry.reding@...il.com>,
        Changcheng Deng <deng.changcheng@....com.cn>,
        <lee.jones@...aro.org>, <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH] pwm: Use div64_ul instead of do_div

On 18/11/2021 at 11:09, Russell King (Oracle) wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> On Wed, Nov 17, 2021 at 12:24:00PM +0100, Uwe Kleine-König wrote:
>> Hello,
>>
>> On Wed, Nov 17, 2021 at 02:04:26AM +0000, cgel.zte@...il.com wrote:
>>> From: Changcheng Deng <deng.changcheng@....com.cn>
>>>
>>> do_div() does a 64-by-32 division. If the divisor is unsigned long, using
>>> div64_ul can avoid truncation to 32-bit.
>>
>> After some research I understood your commit log. I'd write:
>>
>>        do_div() does a 64-by-32 division. Here the divsor is an
>>        unsigned long which on some platforms is 64 bit wide. So use
>>        div64_ul instead of do_div to avoid a possible truncation.
>>
>> The priority of this patch seems to be low, as the device seems to exist
>> only on (32bit) arm.
> 
> ... where unsigned long is 32-bit.
> 
> In any case, for this to overflow, we would need to have a clock in
> excess of 2^32-1 Hz, or around 4GHz - and if we had such a situation
> on 32-bit devices, we need to change the type for holding the frequency
> in the clk API, and probably a lot of code in the CCF as well.
> 
> Unless there is a real reason for this change, I would suggest leaving
> the code as is - there is absolutely no point in making these divisions
> more expensive unless there is a real reason.

Thanks for the technical demonstration Russell. With this in mind:
NACK to the patch, sorry Changcheng Deng.

Best regards,
   Nicolas


-- 
Nicolas Ferre