[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <c1ea7287-a1a8-4d77-97fd-f341d2412005@baylibre.com>
Date: Fri, 27 Jun 2025 18:36:21 -0500
From: David Lechner <dlechner@...libre.com>
To: Andy Shevchenko <andriy.shevchenko@...el.com>
Cc: Michael Hennerich <Michael.Hennerich@...log.com>,
Jonathan Cameron <jic23@...nel.org>, Nuno Sá
<nuno.sa@...log.com>, Andy Shevchenko <andy@...nel.org>,
Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>, Mark Brown <broonie@...nel.org>,
linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org,
devicetree@...r.kernel.org, linux-spi@...r.kernel.org
Subject: Re: [PATCH 3/9] iio: adc: ad_sigma_delta: use BITS_TO_BYTES() macro
On 6/23/25 1:54 AM, Andy Shevchenko wrote:
> On Fri, Jun 20, 2025 at 05:20:09PM -0500, David Lechner wrote:
>> Use the BITS_TO_BYTES() macro instead of dividing by 8 to convert bits
>> to bytes.
>>
>> This makes it more obvious what unit conversion is taking place.
>>
>> In once instance, we also avoid the temporary assignment to a variable
>> as it was confusing that reg_size was being used with two different
>> units (bits and bytes).
>
> ...
>
>> - size = DIV_ROUND_UP(reset_length, 8);
>> + size = BITS_TO_BYTES(reset_length);
>> buf = kcalloc(size, sizeof(*buf), GFP_KERNEL);
>> if (!buf)
>> return -ENOMEM;
>
> Hmm... On the rough glance this sounds like some kind of bitmap
> and hence bitmap_zalloc() (and other bitmap APIs), but I am not
> sure.
>
I looked at it, but I don't think it is worth changing. It is
really counting clock cycles, not bits.
Powered by blists - more mailing lists