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: <7c42e438-22f9-40d9-bb8e-24feb7d58e64@app.fastmail.com>
Date: Tue, 11 Feb 2025 08:36:47 +0100
From: "Arnd Bergmann" <arnd@...db.de>
To: "Andy Shevchenko" <andriy.shevchenko@...ux.intel.com>,
 "kernel test robot" <lkp@...el.com>
Cc: "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 Mon, Feb 10, 2025, at 16:23, Andy Shevchenko wrote:
> +Cc: Arnd
>
>
> 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?

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.

      Arnd