x86: OLPC: add support for calling into OpenFirmware (v5)
in [Kernel]
|
Prev: [PATCH] x86: OLPC: add support for calling into OpenFirmware (v5)
Next: I NEED HELP PLEASE HELP ME??
From: Ingo Molnar on 18 Jun 2010 16:00 * H. Peter Anvin <hpa(a)zytor.com> wrote: > On 06/18/2010 12:42 PM, Andres Salomon wrote: > > + > > + /* install OFW's PDE permanently into the kernel's pgtable */ > > + set_pgd(&swapper_pg_dir[OLPC_OFW_PDE_NR], *ofw_pde); > > + flush_tlb(); > > + early_iounmap(base, sizeof(olpc_ofw_pgd) * PTRS_PER_PGD); > > I just realized... this flush_tlb() is actually not necessary since on x86 > it is always legal to go from a less permissive configuration to a more > permissive, and the initial configuration is "not present" which is > maximally nonpermissive. > > Could you take it out and make sure it still works? small nit: an optimization barrier would still be needed if the result is being relied on by the kernel. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Ingo Molnar on 19 Jun 2010 03:50
* H. Peter Anvin <hpa(a)zytor.com> wrote: > On 06/18/2010 12:56 PM, Ingo Molnar wrote: > > > > * H. Peter Anvin <hpa(a)zytor.com> wrote: > > > >> On 06/18/2010 12:42 PM, Andres Salomon wrote: > >>> + > >>> + /* install OFW's PDE permanently into the kernel's pgtable */ > >>> + set_pgd(&swapper_pg_dir[OLPC_OFW_PDE_NR], *ofw_pde); > >>> + flush_tlb(); > >>> + early_iounmap(base, sizeof(olpc_ofw_pgd) * PTRS_PER_PGD); > >> > >> I just realized... this flush_tlb() is actually not necessary since on x86 > >> it is always legal to go from a less permissive configuration to a more > >> permissive, and the initial configuration is "not present" which is > >> maximally nonpermissive. > >> > >> Could you take it out and make sure it still works? > > > > small nit: an optimization barrier would still be needed if the result is > > being relied on by the kernel. > > > > In this case the optimization barrier is implicit at the return from an > out of line function. Which non-obvious side-effect at minimum deserves a comment. (but yes, i'm just nitpicking) Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |