From: "Arnd Bergmann" <arnd@arndb.de>
To: "Andy Shevchenko" <andriy.shevchenko@linux.intel.com>
Cc: "kernel test robot" <lkp@intel.com>,
"Raag Jadav" <raag.jadav@intel.com>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Rafael J . Wysocki" <rafael@kernel.org>,
"Linus Walleij" <linus.walleij@linaro.org>,
"Mika Westerberg" <mika.westerberg@linux.intel.com>,
"Dmitry Torokhov" <dmitry.torokhov@gmail.com>,
lgirdwood@gmail.com, "Mark Brown" <broonie@kernel.org>,
"Sebastian Reichel" <sre@kernel.org>,
"Jonathan Cameron" <jic23@kernel.org>,
"Przemek Kitszel" <przemyslaw.kitszel@intel.com>,
oe-kbuild-all@lists.linux.dev,
"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
linux-kernel@vger.kernel.org, linux-input@vger.kernel.org,
linux-sound@vger.kernel.org, linux-pm@vger.kernel.org,
linux-iio@vger.kernel.org
Subject: Re: [PATCH v4 01/20] driver core: Split devres APIs to device/devres.h
Date: Tue, 11 Feb 2025 12:56:11 +0100 [thread overview]
Message-ID: <49396042-31f0-4d8e-aa54-d89093ab5709@app.fastmail.com> (raw)
In-Reply-To: <Z6s2cGMM9R6SZ9Le@smile.fi.intel.com>
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
next prev parent reply other threads:[~2025-02-11 11:56 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-10 6:48 [PATCH v4 00/20] Split devres APIs to device/devres.h and introduce devm_kmemdup_array() Raag Jadav
2025-02-10 6:48 ` [PATCH v4 01/20] driver core: Split devres APIs to device/devres.h Raag Jadav
2025-02-10 14:08 ` kernel test robot
2025-02-10 14:30 ` kernel test robot
2025-02-10 15:23 ` Andy Shevchenko
2025-02-10 21:35 ` Raag Jadav
2025-02-11 7:36 ` Arnd Bergmann
2025-02-11 9:27 ` Andy Shevchenko
2025-02-11 9:39 ` Arnd Bergmann
2025-02-11 10:11 ` Andy Shevchenko
2025-02-11 10:23 ` Arnd Bergmann
2025-02-11 11:37 ` Andy Shevchenko
2025-02-11 11:56 ` Arnd Bergmann [this message]
2025-02-11 12:10 ` Andy Shevchenko
2025-02-11 12:57 ` Raag Jadav
2025-02-10 18:43 ` kernel test robot
2025-02-10 6:48 ` [PATCH v4 02/20] iio: imu: st_lsm9ds0: Replace device.h with what is needed Raag Jadav
2025-02-10 6:48 ` [PATCH v4 03/20] devres: Introduce devm_kmemdup_array() Raag Jadav
2025-02-10 6:48 ` [PATCH v4 04/20] pinctrl: intel: copy communities using devm_kmemdup_array() Raag Jadav
2025-02-10 6:48 ` [PATCH v4 05/20] pinctrl: baytrail: " Raag Jadav
2025-02-10 6:48 ` [PATCH v4 06/20] pinctrl: cherryview: use devm_kmemdup_array() Raag Jadav
2025-02-10 6:48 ` [PATCH v4 07/20] pinctrl: tangier: " Raag Jadav
2025-02-10 6:48 ` [PATCH v4 08/20] pinctrl: pxa2xx: " Raag Jadav
2025-02-10 6:48 ` [PATCH v4 09/20] input: sparse-keymap: " Raag Jadav
2025-02-10 6:48 ` [PATCH v4 10/20] input: ipaq-micro-keys: " Raag Jadav
2025-02-10 6:48 ` [PATCH v4 11/20] regulator: devres: " Raag Jadav
2025-02-10 6:48 ` [PATCH v4 12/20] regulator: cros-ec: " Raag Jadav
2025-02-10 6:48 ` [PATCH v4 13/20] power: supply: sc27xx: " Raag Jadav
2025-02-10 6:49 ` [PATCH v4 14/20] iio: adc: xilinx-xadc-core: " Raag Jadav
2025-02-10 6:49 ` [PATCH v4 15/20] ASoC: Intel: avs: " Raag Jadav
2025-02-10 6:49 ` [PATCH v4 16/20] ASoC: hdac_hdmi: " Raag Jadav
2025-02-10 6:49 ` [PATCH v4 17/20] ASoC: tlv320dac33: " Raag Jadav
2025-02-10 6:49 ` [PATCH v4 18/20] ASoC: uda1380: " Raag Jadav
2025-02-10 6:49 ` [PATCH v4 19/20] ASoC: meson: axg-tdm-interface: " Raag Jadav
2025-02-10 6:49 ` [PATCH v4 20/20] ASoC: uniphier: " Raag Jadav
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=49396042-31f0-4d8e-aa54-d89093ab5709@app.fastmail.com \
--to=arnd@arndb.de \
--cc=andriy.shevchenko@linux.intel.com \
--cc=broonie@kernel.org \
--cc=dmitry.torokhov@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=jic23@kernel.org \
--cc=lgirdwood@gmail.com \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-sound@vger.kernel.org \
--cc=lkp@intel.com \
--cc=mika.westerberg@linux.intel.com \
--cc=oe-kbuild-all@lists.linux.dev \
--cc=przemyslaw.kitszel@intel.com \
--cc=raag.jadav@intel.com \
--cc=rafael@kernel.org \
--cc=sre@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox