linux-kernel - Re: [PATCH v4 01/20] driver core: Split devres APIs to device/devres.h

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]

Message-Id: <c1184a91-e216-423d-b956-d4b22116a171@app.fastmail.com>
Date: Tue, 11 Feb 2025 10:39:16 +0100
From: "Arnd Bergmann" <arnd@...db.de>
To: "Andy Shevchenko" <andriy.shevchenko@...ux.intel.com>
Cc: "kernel test robot" <lkp@...el.com>, "Raag Jadav" <raag.jadav@...el.com>,
 "Greg Kroah-Hartman" <gregkh@...uxfoundation.org>,
 "Rafael J . Wysocki" <rafael@...nel.org>,
 "Linus Walleij" <linus.walleij@...aro.org>,
 "Mika Westerberg" <mika.westerberg@...ux.intel.com>,
 "Dmitry Torokhov" <dmitry.torokhov@...il.com>, lgirdwood@...il.com,
 "Mark Brown" <broonie@...nel.org>, "Sebastian Reichel" <sre@...nel.org>,
 "Jonathan Cameron" <jic23@...nel.org>,
 "Przemek Kitszel" <przemyslaw.kitszel@...el.com>,
 oe-kbuild-all@...ts.linux.dev,
 "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
 linux-kernel@...r.kernel.org, linux-input@...r.kernel.org,
 linux-sound@...r.kernel.org, linux-pm@...r.kernel.org,
 linux-iio@...r.kernel.org
Subject: Re: [PATCH v4 01/20] driver core: Split devres APIs to device/devres.h

On Tue, Feb 11, 2025, at 10:27, Andy Shevchenko wrote:
> On Tue, Feb 11, 2025 at 08:36:47AM +0100, Arnd Bergmann wrote:
>> On Mon, Feb 10, 2025, at 16:23, Andy Shevchenko wrote:
>> >
>> > TBH I have no quick idea how to address this. It seems that io.h 
>> > includes device.h
>> > for no reason (but I haven't checked that carefully). OTOH, we need only
>> > IOMEM_IS_ERR() definition which can simply be moved from io.h to err.h 
>> > as the
>> > former includes the latter and the definition depends only on 
>> > compiler_types.h.
>> >
>> > Arnd?
>> 
>> Removing linux/device.h from asm/io.h is probably the right step,
>> it really has no business in there and no other architecture
>> includes it. I don't see an IOMEM_IS_ERR() definition, do you 
>> mean EEH_POSSIBLE_ERROR?
>
> The definition is in the generic header and patch here relies on
> that definition to fix the sparse warning. The simplest solution
> is to add another patch that simply moves the macro from
> linux/io.h to linux/err.h.

Ah, IOMEM_ERR_PTR(), not IOMEM_IS_ERR().

I don't mind moving that if it helps you, but don't see what
the problem is here. Is this missing because of a circular
#include list with linux/device.h including asm/io.h and vice
versa? If that is the root cause, then I assume there will be
additional problems either way until the loop can be broken.

>> Most of asm/eeh.h probably shouldn't be included by asm/io.h
>> either, my guess is that we can get away with the
>> eeh_{s,}{b,w,l,q}{_be} helpers, eeh_memcpy_fromio() and
>> eeh_check_failure(), which have no dependency on 'struct
>> device' in the header.
>> 
>> Removing a giant header inclusion from another one likely causes
>> build regressions in drivers that should have included the
>> header (linux/device.h or something included by that) themselves,
>> so ideally there should be some separate build testing of
>> powerpc kernels.
>
> I believe this might be far out of scope for this series due to potential
> fallouts here and there. But would be good to have it separately.

It certainly gets towards yak-shaving, but it does look like
the best solution. It really depends on how much breaks -- if there
are only a couple of missing #include statements, I can see those
get merged early as a bugfix or as part of another series. If there
are a lot of them, it is probably not worth it.

     Arnd