[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <905d3a14-1e78-469f-99f1-4c1d2299d97c@vaisala.com>
Date: Mon, 8 Dec 2025 18:21:25 +0200
From: Tomas Melin <tomas.melin@...sala.com>
To: Andy Shevchenko <andriy.shevchenko@...el.com>
Cc: Lars-Peter Clausen <lars@...afoo.de>,
Michael Hennerich <Michael.Hennerich@...log.com>,
Nuno Sa <nuno.sa@...log.com>, Jonathan Cameron <jic23@...nel.org>,
David Lechner <dlechner@...libre.com>, Andy Shevchenko <andy@...nel.org>,
Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>, linux-iio@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 3/3] iio: adc: ad9467: drop kernel.h in favor of
array_size.h
Hi,
On 08/12/2025 17:58, Andy Shevchenko wrote:
> On Mon, Dec 08, 2025 at 05:41:20PM +0200, Tomas Melin wrote:
>> On 08/12/2025 15:20, Andy Shevchenko wrote:
>>> On Mon, Dec 08, 2025 at 12:30:59PM +0000, Tomas Melin wrote:
>>>> No need to include the entire kernel.h when the only thing needed
>>>> is the ARRAY_SIZE macro.
>>> While this change is almost (*) okay per se, I think we can address more
>>> while at it.
>>> - Make the header inclusions ordered (also fix the location of clk.h)
>>> - drop other proxy (device.h) or unneeded headers (bitops.h as it's implied by bitmap.h)
>>> - add missing ones (dev_printk.h, device/devres.h, ...)
>>
>> As this change (kernel.h) does not seem at all as straightforward as I
>> envisoned based on your initial request, I will likely change this patch
>> to instead just sort the headers. Reworking the includes is separate
>> topic from the intent of this patch series.
>
> If you don't feel going that deep, than it's a (small) problem.
>
> As the author of a driver feature one should understand slightly more about
> this (yeah, currently mess) header stuff. So, your first patch should add
> missed headers, if any, that's required to your changes, this one can be
> omitted after all.
Well, I think reworking the headers is a sane idea, but it is not the
topic of this series.
>
> But on some day you will still need to understand a bit more about headers...
>
> TL;DR: make sure you have all needed headers for your changes in the previous
> patch and drop this one.
Hope we mean the same thing, I was thinking more like
1. sort current headers
2. add feature which adds the new header in correct location
Thanks,
Tomas
>
>>> (*) no, kernel.h provides more for this driver, for example, your patch
>>> misses types.h.
>
Powered by blists - more mailing lists