Kernel 4.7: PAGE_GUARDED and _PAGE_NO_CACHE

[Christian Zigotzky <chzigotzky@xenosoft.de>]

Shall I modify the workaround? Is the workaround for lack of the device 
tree the problem?

FYI: The SB600 doesn't follow normal PCIe address decoding rules, as in 
its original use as an AMD south bridge it was designed to appear as if 
it were integrated into the north bridge.

What shall I do? I don't know how long I can revert the PowerPC updates.

- Christian

On 08 June 2016 at 5:47 PM, Christian Zigotzky wrote:
> Hi Aneesh,
>
> We use it only in the file "pci-common.c".
>
> Part of the Nemo patch with ISA_IO_BASE:
>
> diff -rupN linux-4.7/arch/powerpc/kernel/pci-common.c 
> linux-4.7-nemo/arch/powerpc/kernel/pci-common.c
> --- linux-4.7/arch/powerpc/kernel/pci-common.c    2016-05-20 
> 10:23:06.588299920 +0200
> +++ linux-4.7-nemo/arch/powerpc/kernel/pci-common.c    2016-05-20 
> 10:21:28.652296699 +0200
> @@ -723,6 +723,19 @@ void pci_process_bridge_OF_ranges(struct
>                  isa_io_base =
>                      (unsigned long)hose->io_base_virt;
>  #endif /* CONFIG_PPC32 */
> +
> +
> +#ifdef CONFIG_PPC_PASEMI_SB600
> +                       /* Workaround for lack of device tree. New for 
> kernel 3.17: range.cpu_addr instead of cpu_addr and range.size instead 
> of size Ch. Zigotzky */
> +                       if (primary) {
> +                               __ioremap_at(range.cpu_addr, (void 
> *)ISA_IO_BASE,
> +                               range.size, 
> pgprot_val(pgprot_noncached(__pgprot(0))));
> +                       hose->io_base_virt = (void *)_IO_BASE;
> +               /* _IO_BASE needs unsigned long long for the kernel 
> 3.17 Ch. Zigotzky */
> +                       printk("Initialised io_base_virt 0x%lx 
> _IO_BASE 0x%llx\n", (unsigned long)hose->io_base_virt, (unsigned long 
> long)_IO_BASE);
> +                    }
> +#endif
> +
>
> Cheers,
>
> Christian
>
> On 08 June 2016 at 5:11 PM, Aneesh Kumar K.V wrote:
>>
>> Can you check the value of ISA_IO_BASE where you are
>> using it. If you are calling it early, you will find wrong value in
>> that. With the latest kernel it is a variable and is initialized in
>> hash__early_init_mmu();
>>
>> -aneesh
>>
>>
>