Re: [PATCH v4 01/20] driver core: Split devres APIs to device/devres.h

Andy Shevchenko
2025-02-11T12:11:00Z

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