drivers/gpu/drm/drm_draw.c | 2 ++ include/linux/io.h | 3 --- 2 files changed, 2 insertions(+), 3 deletions(-)
This series attempts to cleanup io.h with "include what you use" approach. This depends on changes available on immutable tag[1]. Although this series is too trivial in the grand scheme of things, it is still a tiny step towards untangling core headers. I have success results from LKP for this series but there can still be corner cases. So perhaps we can queue this on a temporary branch which we can use to submit fixes in case of fallout. Future plan is to use the excellent analysis[2][3] by Arnd to cleanup other headers. [1] https://lore.kernel.org/r/Z7xGpz3Q4Zj6YHx7@black.fi.intel.com [2] https://lore.kernel.org/r/2342b516-2c6e-42e5-b4f4-579b280823ba@app.fastmail.com [3] https://lore.kernel.org/r/f6eb011b-40fb-409a-b2b2-a09d0e770bbd@app.fastmail.com v2: Fix sparc build errors v3: Fix nios2 build errors and re-order patches Raag Jadav (2): drm/draw: include missing headers io.h: drop unused headers drivers/gpu/drm/drm_draw.c | 2 ++ include/linux/io.h | 3 --- 2 files changed, 2 insertions(+), 3 deletions(-) base-commit: b8c38ccb2ca52b9a38cfeb9f89abab5d6e713221 -- 2.34.1
On Thu, Feb 27, 2025 at 12:37:45PM +0530, Raag Jadav wrote: > This series attempts to cleanup io.h with "include what you use" approach. > This depends on changes available on immutable tag[1]. > > Although this series is too trivial in the grand scheme of things, it is > still a tiny step towards untangling core headers. I have success results > from LKP for this series but there can still be corner cases. So perhaps > we can queue this on a temporary branch which we can use to submit fixes > in case of fallout. > > Future plan is to use the excellent analysis[2][3] by Arnd to cleanup other > headers. > > [1] https://lore.kernel.org/r/Z7xGpz3Q4Zj6YHx7@black.fi.intel.com > [2] https://lore.kernel.org/r/2342b516-2c6e-42e5-b4f4-579b280823ba@app.fastmail.com > [3] https://lore.kernel.org/r/f6eb011b-40fb-409a-b2b2-a09d0e770bbd@app.fastmail.com I believe Arnd can take it through his tree for headers as DRM part is Acked already. -- With Best Regards, Andy Shevchenko
On Thu, Feb 27, 2025, at 16:25, Andy Shevchenko wrote:
> On Thu, Feb 27, 2025 at 12:37:45PM +0530, Raag Jadav wrote:
>> This series attempts to cleanup io.h with "include what you use" approach.
>> This depends on changes available on immutable tag[1].
>>
>> Although this series is too trivial in the grand scheme of things, it is
>> still a tiny step towards untangling core headers. I have success results
>> from LKP for this series but there can still be corner cases. So perhaps
>> we can queue this on a temporary branch which we can use to submit fixes
>> in case of fallout.
>>
>> Future plan is to use the excellent analysis[2][3] by Arnd to cleanup other
>> headers.
>>
>> [1] https://lore.kernel.org/r/Z7xGpz3Q4Zj6YHx7@black.fi.intel.com
>> [2] https://lore.kernel.org/r/2342b516-2c6e-42e5-b4f4-579b280823ba@app.fastmail.com
>> [3] https://lore.kernel.org/r/f6eb011b-40fb-409a-b2b2-a09d0e770bbd@app.fastmail.com
>
> I believe Arnd can take it through his tree for headers as DRM part is
> Acked already.
I've applied it yesterday and not seen any regression reports so far.
Arnd
On Fri, Feb 28, 2025 at 06:11:16PM +0100, Arnd Bergmann wrote: > On Thu, Feb 27, 2025, at 16:25, Andy Shevchenko wrote: > > On Thu, Feb 27, 2025 at 12:37:45PM +0530, Raag Jadav wrote: > >> This series attempts to cleanup io.h with "include what you use" approach. > >> This depends on changes available on immutable tag[1]. > >> > >> Although this series is too trivial in the grand scheme of things, it is > >> still a tiny step towards untangling core headers. I have success results > >> from LKP for this series but there can still be corner cases. So perhaps > >> we can queue this on a temporary branch which we can use to submit fixes > >> in case of fallout. > >> > >> Future plan is to use the excellent analysis[2][3] by Arnd to cleanup other > >> headers. > >> > >> [1] https://lore.kernel.org/r/Z7xGpz3Q4Zj6YHx7@black.fi.intel.com > >> [2] https://lore.kernel.org/r/2342b516-2c6e-42e5-b4f4-579b280823ba@app.fastmail.com > >> [3] https://lore.kernel.org/r/f6eb011b-40fb-409a-b2b2-a09d0e770bbd@app.fastmail.com > > > > I believe Arnd can take it through his tree for headers as DRM part is > > Acked already. > > I've applied it yesterday and not seen any regression reports so far. Probably because the immutable tag is already in -next? Raag
On Fri, Feb 28, 2025 at 07:41:55PM +0200, Raag Jadav wrote: > On Fri, Feb 28, 2025 at 06:11:16PM +0100, Arnd Bergmann wrote: > > On Thu, Feb 27, 2025, at 16:25, Andy Shevchenko wrote: > > > On Thu, Feb 27, 2025 at 12:37:45PM +0530, Raag Jadav wrote: > > >> This series attempts to cleanup io.h with "include what you use" approach. > > >> This depends on changes available on immutable tag[1]. > > >> > > >> Although this series is too trivial in the grand scheme of things, it is > > >> still a tiny step towards untangling core headers. I have success results > > >> from LKP for this series but there can still be corner cases. So perhaps > > >> we can queue this on a temporary branch which we can use to submit fixes > > >> in case of fallout. > > >> > > >> Future plan is to use the excellent analysis[2][3] by Arnd to cleanup other > > >> headers. > > >> > > >> [1] https://lore.kernel.org/r/Z7xGpz3Q4Zj6YHx7@black.fi.intel.com > > >> [2] https://lore.kernel.org/r/2342b516-2c6e-42e5-b4f4-579b280823ba@app.fastmail.com > > >> [3] https://lore.kernel.org/r/f6eb011b-40fb-409a-b2b2-a09d0e770bbd@app.fastmail.com > > > > > > I believe Arnd can take it through his tree for headers as DRM part is > > > Acked already. > > > > I've applied it yesterday and not seen any regression reports so far. > > Probably because the immutable tag is already in -next? Is there any? -- With Best Regards, Andy Shevchenko
On Fri, Feb 28, 2025 at 08:41:33PM +0200, Andy Shevchenko wrote: > On Fri, Feb 28, 2025 at 07:41:55PM +0200, Raag Jadav wrote: > > On Fri, Feb 28, 2025 at 06:11:16PM +0100, Arnd Bergmann wrote: > > > On Thu, Feb 27, 2025, at 16:25, Andy Shevchenko wrote: > > > > On Thu, Feb 27, 2025 at 12:37:45PM +0530, Raag Jadav wrote: > > > >> This series attempts to cleanup io.h with "include what you use" approach. > > > >> This depends on changes available on immutable tag[1]. > > > >> > > > >> Although this series is too trivial in the grand scheme of things, it is > > > >> still a tiny step towards untangling core headers. I have success results > > > >> from LKP for this series but there can still be corner cases. So perhaps > > > >> we can queue this on a temporary branch which we can use to submit fixes > > > >> in case of fallout. > > > >> > > > >> Future plan is to use the excellent analysis[2][3] by Arnd to cleanup other > > > >> headers. > > > >> > > > >> [1] https://lore.kernel.org/r/Z7xGpz3Q4Zj6YHx7@black.fi.intel.com > > > >> [2] https://lore.kernel.org/r/2342b516-2c6e-42e5-b4f4-579b280823ba@app.fastmail.com > > > >> [3] https://lore.kernel.org/r/f6eb011b-40fb-409a-b2b2-a09d0e770bbd@app.fastmail.com > > > > > > > > I believe Arnd can take it through his tree for headers as DRM part is > > > > Acked already. > > > > > > I've applied it yesterday and not seen any regression reports so far. > > > > Probably because the immutable tag is already in -next? > > Is there any? Ah, you mean devres related? -- With Best Regards, Andy Shevchenko
On Fri, Feb 28, 2025 at 08:42:10PM +0200, Andy Shevchenko wrote: > On Fri, Feb 28, 2025 at 08:41:33PM +0200, Andy Shevchenko wrote: > > On Fri, Feb 28, 2025 at 07:41:55PM +0200, Raag Jadav wrote: > > > On Fri, Feb 28, 2025 at 06:11:16PM +0100, Arnd Bergmann wrote: > > > > On Thu, Feb 27, 2025, at 16:25, Andy Shevchenko wrote: > > > > > On Thu, Feb 27, 2025 at 12:37:45PM +0530, Raag Jadav wrote: > > > > >> This series attempts to cleanup io.h with "include what you use" approach. > > > > >> This depends on changes available on immutable tag[1]. > > > > >> > > > > >> Although this series is too trivial in the grand scheme of things, it is > > > > >> still a tiny step towards untangling core headers. I have success results > > > > >> from LKP for this series but there can still be corner cases. So perhaps > > > > >> we can queue this on a temporary branch which we can use to submit fixes > > > > >> in case of fallout. > > > > >> > > > > >> Future plan is to use the excellent analysis[2][3] by Arnd to cleanup other > > > > >> headers. > > > > >> > > > > >> [1] https://lore.kernel.org/r/Z7xGpz3Q4Zj6YHx7@black.fi.intel.com > > > > >> [2] https://lore.kernel.org/r/2342b516-2c6e-42e5-b4f4-579b280823ba@app.fastmail.com > > > > >> [3] https://lore.kernel.org/r/f6eb011b-40fb-409a-b2b2-a09d0e770bbd@app.fastmail.com > > > > > > > > > > I believe Arnd can take it through his tree for headers as DRM part is > > > > > Acked already. > > > > > > > > I've applied it yesterday and not seen any regression reports so far. > > > > > > Probably because the immutable tag is already in -next? > > > > Is there any? > > Ah, you mean devres related? Yeah, couldn't find it on Arnd's tree and I'm not sure if this series works without it. Raag
On Fri, Feb 28, 2025 at 08:45:26PM +0200, Raag Jadav wrote: > On Fri, Feb 28, 2025 at 08:42:10PM +0200, Andy Shevchenko wrote: > > On Fri, Feb 28, 2025 at 08:41:33PM +0200, Andy Shevchenko wrote: > > > On Fri, Feb 28, 2025 at 07:41:55PM +0200, Raag Jadav wrote: > > > > On Fri, Feb 28, 2025 at 06:11:16PM +0100, Arnd Bergmann wrote: > > > > > On Thu, Feb 27, 2025, at 16:25, Andy Shevchenko wrote: > > > > > > On Thu, Feb 27, 2025 at 12:37:45PM +0530, Raag Jadav wrote: > > > > > >> This series attempts to cleanup io.h with "include what you use" approach. > > > > > >> This depends on changes available on immutable tag[1]. > > > > > >> > > > > > >> Although this series is too trivial in the grand scheme of things, it is > > > > > >> still a tiny step towards untangling core headers. I have success results > > > > > >> from LKP for this series but there can still be corner cases. So perhaps > > > > > >> we can queue this on a temporary branch which we can use to submit fixes > > > > > >> in case of fallout. > > > > > >> > > > > > >> Future plan is to use the excellent analysis[2][3] by Arnd to cleanup other > > > > > >> headers. > > > > > >> > > > > > >> [1] https://lore.kernel.org/r/Z7xGpz3Q4Zj6YHx7@black.fi.intel.com > > > > > >> [2] https://lore.kernel.org/r/2342b516-2c6e-42e5-b4f4-579b280823ba@app.fastmail.com > > > > > >> [3] https://lore.kernel.org/r/f6eb011b-40fb-409a-b2b2-a09d0e770bbd@app.fastmail.com > > > > > > > > > > > > I believe Arnd can take it through his tree for headers as DRM part is > > > > > > Acked already. > > > > > > > > > > I've applied it yesterday and not seen any regression reports so far. > > > > > > > > Probably because the immutable tag is already in -next? > > > > > > Is there any? > > > > Ah, you mean devres related? > > Yeah, couldn't find it on Arnd's tree and I'm not sure if this series > works without it. But err.h is included in the io.h, no? Or did I misunderstand the point? -- With Best Regards, Andy Shevchenko
On Fri, Feb 28, 2025 at 08:52:51PM +0200, Andy Shevchenko wrote: > On Fri, Feb 28, 2025 at 08:45:26PM +0200, Raag Jadav wrote: > > On Fri, Feb 28, 2025 at 08:42:10PM +0200, Andy Shevchenko wrote: > > > On Fri, Feb 28, 2025 at 08:41:33PM +0200, Andy Shevchenko wrote: > > > > On Fri, Feb 28, 2025 at 07:41:55PM +0200, Raag Jadav wrote: > > > > > On Fri, Feb 28, 2025 at 06:11:16PM +0100, Arnd Bergmann wrote: > > > > > > On Thu, Feb 27, 2025, at 16:25, Andy Shevchenko wrote: > > > > > > > On Thu, Feb 27, 2025 at 12:37:45PM +0530, Raag Jadav wrote: > > > > > > >> This series attempts to cleanup io.h with "include what you use" approach. > > > > > > >> This depends on changes available on immutable tag[1]. > > > > > > >> > > > > > > >> Although this series is too trivial in the grand scheme of things, it is > > > > > > >> still a tiny step towards untangling core headers. I have success results > > > > > > >> from LKP for this series but there can still be corner cases. So perhaps > > > > > > >> we can queue this on a temporary branch which we can use to submit fixes > > > > > > >> in case of fallout. > > > > > > >> > > > > > > >> Future plan is to use the excellent analysis[2][3] by Arnd to cleanup other > > > > > > >> headers. > > > > > > >> > > > > > > >> [1] https://lore.kernel.org/r/Z7xGpz3Q4Zj6YHx7@black.fi.intel.com > > > > > > >> [2] https://lore.kernel.org/r/2342b516-2c6e-42e5-b4f4-579b280823ba@app.fastmail.com > > > > > > >> [3] https://lore.kernel.org/r/f6eb011b-40fb-409a-b2b2-a09d0e770bbd@app.fastmail.com > > > > > > > > > > > > > > I believe Arnd can take it through his tree for headers as DRM part is > > > > > > > Acked already. > > > > > > > > > > > > I've applied it yesterday and not seen any regression reports so far. > > > > > > > > > > Probably because the immutable tag is already in -next? > > > > > > > > Is there any? > > > > > > Ah, you mean devres related? > > > > Yeah, couldn't find it on Arnd's tree and I'm not sure if this series > > works without it. > > But err.h is included in the io.h, no? Or did I misunderstand the point? First patch on the immutable tag moves IOMEM_ERR_PTR() to err.h and here we're dropping err.h from io.h. So without the tag this series will probably break IOMEM_ERR_PTR(). Raag
On Fri, Feb 28, 2025 at 09:08:15PM +0200, Raag Jadav wrote: > On Fri, Feb 28, 2025 at 08:52:51PM +0200, Andy Shevchenko wrote: > > On Fri, Feb 28, 2025 at 08:45:26PM +0200, Raag Jadav wrote: > > > On Fri, Feb 28, 2025 at 08:42:10PM +0200, Andy Shevchenko wrote: > > > > On Fri, Feb 28, 2025 at 08:41:33PM +0200, Andy Shevchenko wrote: > > > > > On Fri, Feb 28, 2025 at 07:41:55PM +0200, Raag Jadav wrote: > > > > > > On Fri, Feb 28, 2025 at 06:11:16PM +0100, Arnd Bergmann wrote: > > > > > > > On Thu, Feb 27, 2025, at 16:25, Andy Shevchenko wrote: > > > > > > > > On Thu, Feb 27, 2025 at 12:37:45PM +0530, Raag Jadav wrote: > > > > > > > >> This series attempts to cleanup io.h with "include what you use" approach. > > > > > > > >> This depends on changes available on immutable tag[1]. > > > > > > > >> > > > > > > > >> Although this series is too trivial in the grand scheme of things, it is > > > > > > > >> still a tiny step towards untangling core headers. I have success results > > > > > > > >> from LKP for this series but there can still be corner cases. So perhaps > > > > > > > >> we can queue this on a temporary branch which we can use to submit fixes > > > > > > > >> in case of fallout. > > > > > > > >> > > > > > > > >> Future plan is to use the excellent analysis[2][3] by Arnd to cleanup other > > > > > > > >> headers. > > > > > > > >> > > > > > > > >> [1] https://lore.kernel.org/r/Z7xGpz3Q4Zj6YHx7@black.fi.intel.com > > > > > > > >> [2] https://lore.kernel.org/r/2342b516-2c6e-42e5-b4f4-579b280823ba@app.fastmail.com > > > > > > > >> [3] https://lore.kernel.org/r/f6eb011b-40fb-409a-b2b2-a09d0e770bbd@app.fastmail.com > > > > > > > > > > > > > > > > I believe Arnd can take it through his tree for headers as DRM part is > > > > > > > > Acked already. > > > > > > > > > > > > > > I've applied it yesterday and not seen any regression reports so far. > > > > > > > > > > > > Probably because the immutable tag is already in -next? > > > > > > > > > > Is there any? > > > > > > > > Ah, you mean devres related? > > > > > > Yeah, couldn't find it on Arnd's tree and I'm not sure if this series > > > works without it. > > > > But err.h is included in the io.h, no? Or did I misunderstand the point? > > First patch on the immutable tag moves IOMEM_ERR_PTR() to err.h and here > we're dropping err.h from io.h. So without the tag this series will probably > break IOMEM_ERR_PTR(). I see, I think it might be due to some other includes that make this happen. Whatever, I assume that Arnd heavily tested this anyway, so it's good to go independently on the immutable tag.. -- With Best Regards, Andy Shevchenko
On Mon, Mar 3, 2025, at 08:48, Andy Shevchenko wrote:
> On Fri, Feb 28, 2025 at 09:08:15PM +0200, Raag Jadav wrote:
>> > > > Ah, you mean devres related?
>> > >
>> > > Yeah, couldn't find it on Arnd's tree and I'm not sure if this series
>> > > works without it.
>> >
>> > But err.h is included in the io.h, no? Or did I misunderstand the point?
>>
>> First patch on the immutable tag moves IOMEM_ERR_PTR() to err.h and here
>> we're dropping err.h from io.h. So without the tag this series will probably
>> break IOMEM_ERR_PTR().
>
> I see, I think it might be due to some other includes that make this happen.
> Whatever, I assume that Arnd heavily tested this anyway, so it's good to go
> independently on the immutable tag..
I see that err.h gets included through at least linux/string.h,
linux/logic_pio.h and (depending on the architecture architectures)
asm/page.h, so there is no huge risk of something breaking here ;-)
Ideally all of the above should be removed here, but to do
it right, the linux/pgtable.h dependency needs to also be replaced
with a smaller pgprot_t specific one, which takes a bit of
cross-platform work as the definition is not in a consistent
place at the moment.
The change below still builds fine, and that likely indicates
that the same headers are still included from either asm/io.h
or asm/pgtable.h on the architectures I'm testing.
Arnd
----
diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
index 402020b23423..60a162591072 100644
--- a/include/asm-generic/io.h
+++ b/include/asm-generic/io.h
@@ -7,16 +7,16 @@
#ifndef __ASM_GENERIC_IO_H
#define __ASM_GENERIC_IO_H
-#include <asm/page.h> /* I/O is all done through memory accesses */
-#include <linux/string.h> /* for memset() and memcpy() */
#include <linux/sizes.h>
#include <linux/types.h>
#include <linux/instruction_pointer.h>
+#include <linux/compiler.h>
#ifdef CONFIG_GENERIC_IOMAP
#include <asm-generic/iomap.h>
#endif
+#include <asm/byteorder.h>
#include <asm/mmiowb.h>
#include <asm-generic/pci_iomap.h>
diff --git a/include/linux/logic_pio.h b/include/linux/logic_pio.h
index 8f1a9408302f..a83286bf13ab 100644
--- a/include/linux/logic_pio.h
+++ b/include/linux/logic_pio.h
@@ -8,7 +8,9 @@
#ifndef __LINUX_LOGIC_PIO_H
#define __LINUX_LOGIC_PIO_H
-#include <linux/fwnode.h>
+#include <linux/types.h>
+
+struct fwnode_handle;
enum {
LOGIC_PIO_INDIRECT, /* Indirect IO flag */
On Mon, Mar 03, 2025 at 09:31:06AM +0100, Arnd Bergmann wrote: > On Mon, Mar 3, 2025, at 08:48, Andy Shevchenko wrote: > > On Fri, Feb 28, 2025 at 09:08:15PM +0200, Raag Jadav wrote: > >> > > > Ah, you mean devres related? > >> > > > >> > > Yeah, couldn't find it on Arnd's tree and I'm not sure if this series > >> > > works without it. > >> > > >> > But err.h is included in the io.h, no? Or did I misunderstand the point? > >> > >> First patch on the immutable tag moves IOMEM_ERR_PTR() to err.h and here > >> we're dropping err.h from io.h. So without the tag this series will probably > >> break IOMEM_ERR_PTR(). > > > > I see, I think it might be due to some other includes that make this happen. > > Whatever, I assume that Arnd heavily tested this anyway, so it's good to go > > independently on the immutable tag.. > > I see that err.h gets included through at least linux/string.h, > linux/logic_pio.h and (depending on the architecture architectures) > asm/page.h, so there is no huge risk of something breaking here ;-) > > Ideally all of the above should be removed here, but to do > it right, the linux/pgtable.h dependency needs to also be replaced > with a smaller pgprot_t specific one, which takes a bit of > cross-platform work as the definition is not in a consistent > place at the moment. > > The change below still builds fine, and that likely indicates > that the same headers are still included from either asm/io.h > or asm/pgtable.h on the architectures I'm testing. Sounds even better. Can you submit a formal patch that other CIs will have a chance to go through this? -- With Best Regards, Andy Shevchenko
© 2016 - 2025 Red Hat, Inc.