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: <279d9f32-a1c9-41aa-b15a-e1485877b2d5@app.fastmail.com>
Date: Tue, 11 Feb 2025 11:23:07 +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 11:11, Andy Shevchenko wrote:
> On Tue, Feb 11, 2025 at 10:39:16AM +0100, Arnd Bergmann wrote:
>> On Tue, Feb 11, 2025, at 10:27, Andy Shevchenko wrote:
>
>> 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.
>
> I don't see how. io.h already includes err.h, so whoever includes io.h should
> have that as previously.

I mean I never understood what problem you are trying to solve
exactly. From the log, it appears that the problem is an include
loop between linux/device.h, linux/device/devres.h and asm/io.h,
and anything that breaks the loop should work. Your suggestion of
stopping asm/io.h from including linux/device.h sounds like
the most promising here, but this should be possible regardless
of whether IOMEM_ERR_PTR() gets moved.

    Arnd