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

[Andy Shevchenko <andriy.shevchenko@linux.intel.com>]

On Tue, Feb 11, 2025 at 11:23:07AM +0100, Arnd Bergmann wrote:
> On Tue, Feb 11, 2025, at 11:11, Andy Shevchenko wrote:
> > On Tue, Feb 11, 2025 at 10:39:16AM +0100, Arnd Bergmann wrote:
> >> On Tue, Feb 11, 2025, at 10:27, Andy Shevchenko wrote:
> >
> >> I don't mind moving that if it helps you, but don't see what
> >> the problem is here. Is this missing because of a circular
> >> #include list with linux/device.h including asm/io.h and vice
> >> versa? If that is the root cause, then I assume there will be
> >> additional problems either way until the loop can be broken.
> >
> > I don't see how. io.h already includes err.h, so whoever includes io.h should
> > have that as previously.
> 
> I mean I never understood what problem you are trying to solve
> exactly. From the log, it appears that the problem is an include
> loop between linux/device.h, linux/device/devres.h and asm/io.h,
> and anything that breaks the loop should work. Your suggestion of
> stopping asm/io.h from including linux/device.h sounds like
> the most promising here, but this should be possible regardless
> of whether IOMEM_ERR_PTR() gets moved.

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?

-- 
With Best Regards,
Andy Shevchenko