[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <49396042-31f0-4d8e-aa54-d89093ab5709@app.fastmail.com>
Date: Tue, 11 Feb 2025 12:56:11 +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 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.
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.
Arnd
Powered by blists - more mailing lists