On 11.04.21 11:10, Borislav Petkov wrote: > 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.kis...@siemens.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.kis...@siemens.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? >
The patches are coming from downstream usage, yes, but I think the solutions are relevant cleanups for upstream as well. Jan