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: <Z6sYAxRIeCzw12nY@smile.fi.intel.com>
Date: Tue, 11 Feb 2025 11:27:31 +0200
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To: Arnd Bergmann <arnd@...db.de>
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 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.

> 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.

Raag, I think if you have time and motivation you can create that patch,
but send it separately. And this series can be fixed with the move of the
macro.

-- 
With Best Regards,
Andy Shevchenko