[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210411091056.GA14022@zn.tnic>
Date: Sun, 11 Apr 2021 11:10:56 +0200
From: Borislav Petkov <bp@...en8.de>
To: Jan Kiszka <jan.kiszka@....de>
Cc: Thomas Gleixner <tglx@...utronix.de>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Andy Lutomirski <luto@...nel.org>,
Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...hat.com>,
"H. Peter Anvin" <hpa@...or.com>, x86 <x86@...nel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] x86: pat: Do not compile stubbed functions when
X86_PAT is off
On Sun, Apr 11, 2021 at 10:22:19AM +0200, Jan Kiszka wrote:
> On 26.10.20 18:39, Jan Kiszka wrote:
> > From: Jan Kiszka <jan.kiszka@...mens.com>
> >
> > Those are already provided by linux/io.h as stubs.
> >
> > The conflict remains invisible until someone would pull linux/io.h into
> > memtype.c.
> >
> > Signed-off-by: Jan Kiszka <jan.kiszka@...mens.com>
> > ---
> >
> > Change in v2:
> > - correct commit message
> >
> > arch/x86/mm/pat/memtype.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/arch/x86/mm/pat/memtype.c b/arch/x86/mm/pat/memtype.c
> > index 8f665c352bf0..41a4ac585af3 100644
> > --- a/arch/x86/mm/pat/memtype.c
> > +++ b/arch/x86/mm/pat/memtype.c
> > @@ -800,6 +800,7 @@ void memtype_free_io(resource_size_t start, resource_size_t end)
> > memtype_free(start, end);
> > }
> >
> > +#ifdef CONFIG_X86_PAT
> > int arch_io_reserve_memtype_wc(resource_size_t start, resource_size_t size)
> > {
> > enum page_cache_mode type = _PAGE_CACHE_MODE_WC;
> > @@ -813,6 +814,7 @@ void arch_io_free_memtype_wc(resource_size_t start, resource_size_t size)
> > memtype_free_io(start, start + size);
> > }
> > EXPORT_SYMBOL(arch_io_free_memtype_wc);
> > +#endif
> >
> > pgprot_t phys_mem_access_prot(struct file *file, unsigned long pfn,
> > unsigned long size, pgprot_t vma_prot)
> >
>
> What happened to this?
What is this patch and your other asm/proto.h thing fixing?
Looks like you're using kernel headers in something else and don't want
to include the whole world thus those fixes... so that you can include
upstream kernel headers without having to touch them...
Or am I way off base here?
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
Powered by blists - more mailing lists