[v1,1/2] LoongArch: Add missing headers

  The header uses definitions from sizes.h, include it.
For __iomem we need the compiler_types.h, include it.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 arch/loongarch/include/asm/addrspace.h | 2 ++
 1 file changed, 2 insertions(+)
  

Hi,  Andy,

Thank you for your patch, can this patch solve the problem below?
https://lore.kernel.org/oe-kbuild-all/202309072237.9zxMv4MZ-lkp@intel.com/T/#u

If yes, please add a reference in the commit message. I have
investigated this problem for a long time but failed to solve it.

Huacai

On Thu, Sep 14, 2023 at 6:34 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> The header uses definitions from sizes.h, include it.
> For __iomem we need the compiler_types.h, include it.
>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> ---
>  arch/loongarch/include/asm/addrspace.h | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/arch/loongarch/include/asm/addrspace.h b/arch/loongarch/include/asm/addrspace.h
> index 5c9c03bdf915..eaf8ac098622 100644
> --- a/arch/loongarch/include/asm/addrspace.h
> +++ b/arch/loongarch/include/asm/addrspace.h
> @@ -10,7 +10,9 @@
>  #ifndef _ASM_ADDRSPACE_H
>  #define _ASM_ADDRSPACE_H
>
> +#include <linux/compiler_types.h>
>  #include <linux/const.h>
> +#include <linux/sizes.h>
>
>  #include <asm/loongarch.h>
>
> --
> 2.40.0.1.gaa8946217a0b
>
>
  

On Thu, Sep 14, 2023 at 11:25:22PM +0800, Huacai Chen wrote:
> Hi,  Andy,
> 
> Thank you for your patch, can this patch solve the problem below?
> https://lore.kernel.org/oe-kbuild-all/202309072237.9zxMv4MZ-lkp@intel.com/T/#u

Nope, this just adds missing includes.
No functional change, so warnings will still be there.

> If yes, please add a reference in the commit message. I have
> investigated this problem for a long time but failed to solve it.
  

Hi, Andy,

On Fri, Sep 15, 2023 at 2:53 AM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Thu, Sep 14, 2023 at 11:25:22PM +0800, Huacai Chen wrote:
> > Hi,  Andy,
> >
> > Thank you for your patch, can this patch solve the problem below?
> > https://lore.kernel.org/oe-kbuild-all/202309072237.9zxMv4MZ-lkp@intel.com/T/#u
>
> Nope, this just adds missing includes.
> No functional change, so warnings will still be there.
But I think a patch should solve a problem. If we don't get a build
error or warning without this patch, does that mean the 'missing'
headers are actually included indirectly?

Huacai

>
> > If yes, please add a reference in the commit message. I have
> > investigated this problem for a long time but failed to solve it.
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
  

On Fri, Sep 15, 2023 at 08:36:24AM +0800, Huacai Chen wrote:
> On Fri, Sep 15, 2023 at 2:53 AM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> > On Thu, Sep 14, 2023 at 11:25:22PM +0800, Huacai Chen wrote:

> > > Thank you for your patch, can this patch solve the problem below?
> > > https://lore.kernel.org/oe-kbuild-all/202309072237.9zxMv4MZ-lkp@intel.com/T/#u
> >
> > Nope, this just adds missing includes.
> > No functional change, so warnings will still be there.
> But I think a patch should solve a problem.

No, that problem is static analyser concern, not the compiler nor linker.

> If we don't get a build
> error or warning without this patch, does that mean the 'missing'
> headers are actually included indirectly?

I might be missing something, but I do not see any build error in the above message.
  

On Sat, Sep 16, 2023 at 6:27 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Fri, Sep 15, 2023 at 08:36:24AM +0800, Huacai Chen wrote:
> > On Fri, Sep 15, 2023 at 2:53 AM Andy Shevchenko
> > <andriy.shevchenko@linux.intel.com> wrote:
> > > On Thu, Sep 14, 2023 at 11:25:22PM +0800, Huacai Chen wrote:
>
> > > > Thank you for your patch, can this patch solve the problem below?
> > > > https://lore.kernel.org/oe-kbuild-all/202309072237.9zxMv4MZ-lkp@intel.com/T/#u
> > >
> > > Nope, this just adds missing includes.
> > > No functional change, so warnings will still be there.
> > But I think a patch should solve a problem.
>
> No, that problem is static analyser concern, not the compiler nor linker.
>
> > If we don't get a build
> > error or warning without this patch, does that mean the 'missing'
> > headers are actually included indirectly?
>
> I might be missing something, but I do not see any build error in the above message.
Hmm, then I think I will take the second patch only.

Huacai
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
>
  

On Sat, Sep 16, 2023 at 08:05:52PM +0800, Huacai Chen wrote:
> On Sat, Sep 16, 2023 at 6:27 PM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> > On Fri, Sep 15, 2023 at 08:36:24AM +0800, Huacai Chen wrote:
> > > On Fri, Sep 15, 2023 at 2:53 AM Andy Shevchenko
> > > <andriy.shevchenko@linux.intel.com> wrote:
> > > > On Thu, Sep 14, 2023 at 11:25:22PM +0800, Huacai Chen wrote:
> >
> > > > > Thank you for your patch, can this patch solve the problem below?
> > > > > https://lore.kernel.org/oe-kbuild-all/202309072237.9zxMv4MZ-lkp@intel.com/T/#u
> > > >
> > > > Nope, this just adds missing includes.
> > > > No functional change, so warnings will still be there.
> > > But I think a patch should solve a problem.
> >
> > No, that problem is static analyser concern, not the compiler nor linker.
> >
> > > If we don't get a build
> > > error or warning without this patch, does that mean the 'missing'
> > > headers are actually included indirectly?
> >
> > I might be missing something, but I do not see any build error in the above message.
> Hmm, then I think I will take the second patch only.

Thanks, but can you shed a light why?

The rule of thumb is to include the headers we are direct users of, we have not
to imply any other inclusions done by others, unless it's kinda same family of
headers (like types.h always includes compiler_types.h). Since in your case
the const.h is included the other two are missing and it's even worse, as I
understand you rely on the specific headers to be included _before_ using this
one in the users.
  

Hi, Andy,

On Mon, Sep 18, 2023 at 2:49 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Sat, Sep 16, 2023 at 08:05:52PM +0800, Huacai Chen wrote:
> > On Sat, Sep 16, 2023 at 6:27 PM Andy Shevchenko
> > <andriy.shevchenko@linux.intel.com> wrote:
> > > On Fri, Sep 15, 2023 at 08:36:24AM +0800, Huacai Chen wrote:
> > > > On Fri, Sep 15, 2023 at 2:53 AM Andy Shevchenko
> > > > <andriy.shevchenko@linux.intel.com> wrote:
> > > > > On Thu, Sep 14, 2023 at 11:25:22PM +0800, Huacai Chen wrote:
> > >
> > > > > > Thank you for your patch, can this patch solve the problem below?
> > > > > > https://lore.kernel.org/oe-kbuild-all/202309072237.9zxMv4MZ-lkp@intel.com/T/#u
> > > > >
> > > > > Nope, this just adds missing includes.
> > > > > No functional change, so warnings will still be there.
> > > > But I think a patch should solve a problem.
> > >
> > > No, that problem is static analyser concern, not the compiler nor linker.
> > >
> > > > If we don't get a build
> > > > error or warning without this patch, does that mean the 'missing'
> > > > headers are actually included indirectly?
> > >
> > > I might be missing something, but I do not see any build error in the above message.
> > Hmm, then I think I will take the second patch only.
>
> Thanks, but can you shed a light why?
>
> The rule of thumb is to include the headers we are direct users of, we have not
> to imply any other inclusions done by others, unless it's kinda same family of
> headers (like types.h always includes compiler_types.h). Since in your case
> the const.h is included the other two are missing and it's even worse, as I
> understand you rely on the specific headers to be included _before_ using this
> one in the users.
I agree with you more or less, but I doubt there is another rule: no
break, no fix. Please see:

https://lore.kernel.org/loongarch/20221024070105.306280-1-chenhuacai@loongson.cn/T/#t

Obviously static_key is used in page-flags.h and it really causes
build errors once before, but at last I removed the inclusion of
static_key.h to get that series merged.

Huacai

>
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
>
  

On Mon, Sep 18, 2023 at 04:05:50PM +0800, Huacai Chen wrote:
> On Mon, Sep 18, 2023 at 2:49 PM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> > On Sat, Sep 16, 2023 at 08:05:52PM +0800, Huacai Chen wrote:
> > > On Sat, Sep 16, 2023 at 6:27 PM Andy Shevchenko
> > > <andriy.shevchenko@linux.intel.com> wrote:
> > > > On Fri, Sep 15, 2023 at 08:36:24AM +0800, Huacai Chen wrote:
> > > > > On Fri, Sep 15, 2023 at 2:53 AM Andy Shevchenko
> > > > > <andriy.shevchenko@linux.intel.com> wrote:
> > > > > > On Thu, Sep 14, 2023 at 11:25:22PM +0800, Huacai Chen wrote:
> > > >
> > > > > > > Thank you for your patch, can this patch solve the problem below?
> > > > > > > https://lore.kernel.org/oe-kbuild-all/202309072237.9zxMv4MZ-lkp@intel.com/T/#u
> > > > > >
> > > > > > Nope, this just adds missing includes.
> > > > > > No functional change, so warnings will still be there.
> > > > > But I think a patch should solve a problem.
> > > >
> > > > No, that problem is static analyser concern, not the compiler nor linker.
> > > >
> > > > > If we don't get a build
> > > > > error or warning without this patch, does that mean the 'missing'
> > > > > headers are actually included indirectly?
> > > >
> > > > I might be missing something, but I do not see any build error in the above message.
> > > Hmm, then I think I will take the second patch only.
> >
> > Thanks, but can you shed a light why?
> >
> > The rule of thumb is to include the headers we are direct users of, we have not
> > to imply any other inclusions done by others, unless it's kinda same family of
> > headers (like types.h always includes compiler_types.h). Since in your case
> > the const.h is included the other two are missing and it's even worse, as I
> > understand you rely on the specific headers to be included _before_ using this
> > one in the users.
> I agree with you more or less, but I doubt there is another rule: no
> break, no fix. Please see:
> 
> https://lore.kernel.org/loongarch/20221024070105.306280-1-chenhuacai@loongson.cn/T/#t
> 
> Obviously static_key is used in page-flags.h and it really causes
> build errors once before, but at last I removed the inclusion of
> static_key.h to get that series merged.

This is strange requirement to be honest. Doing like this is to move your
responsibility and understanding of the code to be a burden of the person who
volunteers cleaning up the header mess we have in the Linux kernel source tree.

Since I'm the one who tries to fix some mess (in particular kernel.h), I am
pretty much know what I am talking about from the experience.

Cc'ing Guo. Guo, can you shed a light on the rationale of your comment in
the above mentioned thread?
  

On Mon, Sep 18, 2023 at 4:23 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Mon, Sep 18, 2023 at 04:05:50PM +0800, Huacai Chen wrote:
> > On Mon, Sep 18, 2023 at 2:49 PM Andy Shevchenko
> > <andriy.shevchenko@linux.intel.com> wrote:
> > > On Sat, Sep 16, 2023 at 08:05:52PM +0800, Huacai Chen wrote:
> > > > On Sat, Sep 16, 2023 at 6:27 PM Andy Shevchenko
> > > > <andriy.shevchenko@linux.intel.com> wrote:
> > > > > On Fri, Sep 15, 2023 at 08:36:24AM +0800, Huacai Chen wrote:
> > > > > > On Fri, Sep 15, 2023 at 2:53 AM Andy Shevchenko
> > > > > > <andriy.shevchenko@linux.intel.com> wrote:
> > > > > > > On Thu, Sep 14, 2023 at 11:25:22PM +0800, Huacai Chen wrote:
> > > > >
> > > > > > > > Thank you for your patch, can this patch solve the problem below?
> > > > > > > > https://lore.kernel.org/oe-kbuild-all/202309072237.9zxMv4MZ-lkp@intel.com/T/#u
> > > > > > >
> > > > > > > Nope, this just adds missing includes.
> > > > > > > No functional change, so warnings will still be there.
> > > > > > But I think a patch should solve a problem.
> > > > >
> > > > > No, that problem is static analyser concern, not the compiler nor linker.
> > > > >
> > > > > > If we don't get a build
> > > > > > error or warning without this patch, does that mean the 'missing'
> > > > > > headers are actually included indirectly?
> > > > >
> > > > > I might be missing something, but I do not see any build error in the above message.
> > > > Hmm, then I think I will take the second patch only.
> > >
> > > Thanks, but can you shed a light why?
> > >
> > > The rule of thumb is to include the headers we are direct users of, we have not
> > > to imply any other inclusions done by others, unless it's kinda same family of
> > > headers (like types.h always includes compiler_types.h). Since in your case
> > > the const.h is included the other two are missing and it's even worse, as I
> > > understand you rely on the specific headers to be included _before_ using this
> > > one in the users.
> > I agree with you more or less, but I doubt there is another rule: no
> > break, no fix. Please see:
> >
> > https://lore.kernel.org/loongarch/20221024070105.306280-1-chenhuacai@loongson.cn/T/#t
> >
> > Obviously static_key is used in page-flags.h and it really causes
> > build errors once before, but at last I removed the inclusion of
> > static_key.h to get that series merged.
>
> This is strange requirement to be honest. Doing like this is to move your
> responsibility and understanding of the code to be a burden of the person who
> volunteers cleaning up the header mess we have in the Linux kernel source tree.
>
> Since I'm the one who tries to fix some mess (in particular kernel.h), I am
> pretty much know what I am talking about from the experience.
>
> Cc'ing Guo. Guo, can you shed a light on the rationale of your comment in
> the above mentioned thread?

diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h
index 5c02720c53a5..9cdef3944a75 100644
--- a/include/linux/page-flags.h
+++ b/include/linux/page-flags.h
@@ -9,6 +9,7 @@
 #include <linux/types.h>
 #include <linux/bug.h>
 #include <linux/mmdebug.h>
+#include <linux/static_key.h>
 #ifndef __GENERATING_BOUNDS_H
 #include <linux/mm_types.h>
 #include <generated/bounds.h>

My meaning is riscv needn't include the above header file to support
HVO, and I just tested the above modification with riscv, all passed,
so go ahead.

>
> --
> With Best Regards,
> Andy Shevchenko
>
>