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 08:36:47AM +0100, Arnd Bergmann wrote:
> On Mon, Feb 10, 2025, at 16:23, Andy Shevchenko wrote:
> >
> > TBH I have no quick idea how to address this. It seems that io.h 
> > includes device.h
> > for no reason (but I haven't checked that carefully). OTOH, we need only
> > IOMEM_IS_ERR() definition which can simply be moved from io.h to err.h 
> > as the
> > former includes the latter and the definition depends only on 
> > compiler_types.h.
> >
> > Arnd?
> 
> Removing linux/device.h from asm/io.h is probably the right step,
> it really has no business in there and no other architecture
> includes it. I don't see an IOMEM_IS_ERR() definition, do you 
> mean EEH_POSSIBLE_ERROR?

The definition is in the generic header and patch here relies on
that definition to fix the sparse warning. The simplest solution
is to add another patch that simply moves the macro from
linux/io.h to linux/err.h.

> Most of asm/eeh.h probably shouldn't be included by asm/io.h
> either, my guess is that we can get away with the
> eeh_{s,}{b,w,l,q}{_be} helpers, eeh_memcpy_fromio() and
> eeh_check_failure(), which have no dependency on 'struct
> device' in the header.
> 
> Removing a giant header inclusion from another one likely causes
> build regressions in drivers that should have included the
> header (linux/device.h or something included by that) themselves,
> so ideally there should be some separate build testing of
> powerpc kernels.

I believe this might be far out of scope for this series due to potential
fallouts here and there. But would be good to have it separately.

Raag, I think if you have time and motivation you can create that patch,
but send it separately. And this series can be fixed with the move of the
macro.

-- 
With Best Regards,
Andy Shevchenko