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: <Z6s-S67MdpVrXRji@smile.fi.intel.com>
Date: Tue, 11 Feb 2025 14:10:51 +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 12:56:11PM +0100, Arnd Bergmann wrote:
> On Tue, Feb 11, 2025, at 12:37, Andy Shevchenko wrote:
> >
> > The problem this series solves at the beginning is that not all the consumers
> > of device.h needs it, in many cases the device/devres.h (or subset of
> > device/*.h) is enough to include. While solving this, it appears that
> > the current code uses ERR_PTR() instead of IOMEM_ERR_PTR() in devm_*io*() APIs
> > and kernel test robot found this and complained about. While solving
> > this new issue, LKP found another issue that is circular dependency.
> > But the original code only wants to have an access to IOMEM_ERR_PTR() which
> > is in io.h and can be moved to err.h AFAICS. Does this sound reasonable?
> 
> Yes, that sounds fine to me. I agree that not including linux/io.h
> from device/devres.h is a good idea, same as no longer including
> linux/device.h from asm/io.h. Moving IOMEM_ERR_PTR() as you
> describe is the right idea.

Thank you for confirming the idea. Raag, please follow as suggested:

Move IOMEM_ERR_PTR() to err.h (perhaps in a separate patch),
and drop io.h from devres.h as it will be not needed.

> Side note: I looked at large-scale header file cleanups in the past,
> and in general the result of that was that the best way to reduce the
> indirect inclusions is by splitting data structure definitions from
> inline functions that use those data structures. The definition of
> "struct device" clearly has too many dependencies, and to make
> this one better. There has actually been some good preparatory work
> done by Kent Overstreet a while ago that moves structures out
> (e.g. work_struct and mutex), but not yet struct device and
> struct kobject, which are needed in many other headers. The tricky
> part that needs to happen to actually make it useful later on is
> to replace all the unnecessary indirect includes with the minimal
> ones, and that is a huge amount of work.

Good to hear that somebody is working on the dependency hell untangling.

-- 
With Best Regards,
Andy Shevchenko