* Re: RFC on writel and writel_relaxed
From: David Miller @ 2018-03-29 14:04 UTC (permalink / raw)
To: okaya
Cc: benh, torvalds, alexander.duyck, will.deacon, arnd, jgg,
David.Laight, oohall, linuxppc-dev, linux-rdma, alexander.h.duyck,
paulmck, netdev, linus971
In-Reply-To: <29fe17e0-9978-dc43-d02c-de8fabdc66c2@codeaurora.org>
From: Sinan Kaya <okaya@codeaurora.org>
Date: Thu, 29 Mar 2018 09:56:01 -0400
> sparc question sent
Sparc never lets physical memory accesses pass MMIO, and vice versa.
They are always strongly ordered amongst eachother.
Therefore no explicit barrier instructions are necessary.
^ permalink raw reply
* Re: [PATCH V2] powerpc/mm/hugetlb: initialize the pagetable cache correctly for hugetlb
From: Michael Ellerman @ 2018-03-29 14:23 UTC (permalink / raw)
To: Aneesh Kumar K.V, benh, paulus; +Cc: linuxppc-dev, Aneesh Kumar K.V
In-Reply-To: <20180307140925.5755-1-aneesh.kumar@linux.vnet.ibm.com>
"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> writes:
> With 64k page size, we have hugetlb pte entries at the pmd and pud level for
> book3s64. We don't need to create a separate page table cache for that. With 4k
> we need to make sure hugepd page table cache for 16M is placed at PUD level
> and 16G at the PGD level.
>
> Simplify all these by not using HUGEPD_PD_SHIFT which is confusing for book3s64.
>
> Without this patch, with 64k page size we create pagetable caches with shift
> value 10 and 7 which are not used at all.
>
> Fixes:419df06eea5bfa81("powerpc: Reduce the PTE_INDEX_SIZE")
That's:
Fixes: 419df06eea5b ("powerpc: Reduce the PTE_INDEX_SIZE")
In ~/.gitconfig:
[pretty]
fixes = Fixes: %h (\"%s\")
> diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
> index 876da2bc1796..3b509b268030 100644
> --- a/arch/powerpc/mm/hugetlbpage.c
> +++ b/arch/powerpc/mm/hugetlbpage.c
> @@ -669,12 +666,24 @@ static int __init hugetlbpage_init(void)
> if (add_huge_page_size(1ULL << shift) < 0)
> continue;
>
> +
> +#ifdef CONFIG_PPC_BOOK3S_64
> + if (shift > PGDIR_SHIFT)
> + BUG();
Can we not add BUG()s for things that aren't utterly fatal.
In this case I think we could move this whole block above
add_huge_page_size() above, and then instead of BUG() we could just
WARN() and continue?
> + else if (shift > PUD_SHIFT)
> + pdshift = PGDIR_SHIFT;
> + else if (shift > PMD_SHIFT)
> + pdshift = PUD_SHIFT;
> + else
> + pdshift = PMD_SHIFT;
> +#else
> if (shift < HUGEPD_PUD_SHIFT)
> pdshift = PMD_SHIFT;
> else if (shift < HUGEPD_PGD_SHIFT)
> pdshift = PUD_SHIFT;
> else
> pdshift = PGDIR_SHIFT;
> +#endif
> /*
> * if we have pdshift and shift value same, we don't
> * use pgt cache for hugepd.
cheers
^ permalink raw reply
* Re: RFC on writel and writel_relaxed
From: Jason Gunthorpe @ 2018-03-29 14:45 UTC (permalink / raw)
To: Will Deacon
Cc: Benjamin Herrenschmidt, Arnd Bergmann, Sinan Kaya, David Laight,
Oliver, open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
linux-rdma@vger.kernel.org, Paul E. McKenney, Peter Zijlstra,
Ingo Molnar, Jonathan Corbet
In-Reply-To: <20180329091941.GA22926@arm.com>
On Thu, Mar 29, 2018 at 10:19:41AM +0100, Will Deacon wrote:
> On Wed, Mar 28, 2018 at 10:57:32AM -0600, Jason Gunthorpe wrote:
> > On Wed, Mar 28, 2018 at 11:13:45AM +0100, Will Deacon wrote:
> > > On Wed, Mar 28, 2018 at 09:01:27PM +1100, Benjamin Herrenschmidt wrote:
> > > > On Wed, 2018-03-28 at 11:55 +0200, Arnd Bergmann wrote:
> > > > > > powerpc and ARM can't quite make them synchronous I think, but at least
> > > > > > they should have the same semantics as writel.
> > > > >
> > > > > One thing that ARM does IIRC is that it only guarantees to order writel() within
> > > > > one device, and the memory mapped PCI I/O space window almost certainly
> > > > > counts as a separate device to the CPU.
> > > >
> > > > That sounds bogus.
> > >
> > > To elaborate, if you do the following on arm:
> > >
> > > writel(DEVICE_FOO);
> > > writel(DEVICE_BAR);
> > >
> > > we generally cannot guarantee in which order those accesses will hit the
> > > devices even if we add every barrier under the sun. You'd need something
> > > in between, specific to DEVICE_FOO (probably a read-back) to really push
> > > the first write out. This doesn't sound like it would be that uncommon to
> > > me.
> >
> > The PCI posted write does not require the above to execute 'in order'
> > only that any bus segment shared by the two devices have the writes
> > issued in CPU order. ie at a shared PCI root port for instance.
> >
> > If I recall this is very similar to the ordering that ARM's on-chip
> > AXI interconnect is supposed to provide.. So I'd be very surprised if
> > a modern ARM64 has an meaningful difference from x86 here.
>
> From the architectural perspective, writes to different "peripherals" are
> not ordered with respect to each other. The first writel will complete once
> it gets its write acknowledgement, but this may not necessarily come from
> the endpoint -- it could come from an intermediate buffer past the point of
> serialisation (i.e. the write will then be ordered with respect to other
> accesses to that same endpoint). The PCI root port would look like one
> peripheral here.
That is basically the same as PCI - PCI has no write ACK, so all
writes are buffered by the PCI interconnect and complete in some
undefined temporal order when multiple end points are involved.
This does not seem very different from what happens in x86..
> > When talking about ordering between the devices, the relevant question
> > is what happens if the writel(DEVICE_BAR) triggers DEVICE_BAR to DMA
> > from the DEVICE_FOO. 'ordered' means that in this case
> > writel(DEVICE_FOO) must be presented to FOO before anything generated
> > by BAR.
>
> Yes, and that isn't the case for arm because the writes can still be
> buffered.
The statement is not about buffering, or temporal completion order, or
the order of acks returning to the CPU. It is about pure transaction
ordering inside the interconnect.
Can write BAR -> FOO pass write CPU -> FOO?
Jason
^ permalink raw reply
* RE: RFC on writel and writel_relaxed
From: David Laight @ 2018-03-29 14:58 UTC (permalink / raw)
To: 'Jason Gunthorpe', Will Deacon
Cc: Benjamin Herrenschmidt, Arnd Bergmann, Sinan Kaya, Oliver,
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
linux-rdma@vger.kernel.org, Paul E. McKenney, Peter Zijlstra,
Ingo Molnar, Jonathan Corbet
In-Reply-To: <20180329144515.GA13656@ziepe.ca>
From: Jason Gunthorpe
> Sent: 29 March 2018 15:45
...
> > > When talking about ordering between the devices, the relevant questio=
n
> > > is what happens if the writel(DEVICE_BAR) triggers DEVICE_BAR to DMA
> > > from the DEVICE_FOO. 'ordered' means that in this case
> > > writel(DEVICE_FOO) must be presented to FOO before anything generated
> > > by BAR.
> >
> > Yes, and that isn't the case for arm because the writes can still be
> > buffered.
>=20
> The statement is not about buffering, or temporal completion order, or
> the order of acks returning to the CPU. It is about pure transaction
> ordering inside the interconnect.
>=20
> Can write BAR -> FOO pass write CPU -> FOO?
Almost certainly.
The first cpu write can almost certainly be 'stalled' at the shared PCIe br=
idge.
The second cpu write then completes (to a different target).
That target then issues a peer to peer transfer that reaches the shared bri=
dge.
I doubt the order of the transactions is guaranteed when it becomes 'un-sta=
lled'.
Of course, these are peer to peer transfers, and strange ones at that.
Normally you'd not be doing peer to peer transfers that access 'memory'
the cpu has just written to.
Requiring extra barriers in this case, or different functions for WC access=
es
shouldn't really be an issue.
Even requiring a barrier between a write to dma coherent memory and a write
that starts dma isn't really onerous.
Even if it is a nop on all current architectures it is a good comment in th=
e code.
It could even have a 'dev' argument.
David
^ permalink raw reply
* Re: [PATCH 12/14] powerpc: pass node id into create_section_mapping
From: Nicholas Piggin @ 2018-03-29 15:15 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
In-Reply-To: <87o9j71lbf.fsf@concordia.ellerman.id.au>
On Thu, 29 Mar 2018 16:51:16 +1100
Michael Ellerman <mpe@ellerman.id.au> wrote:
> Nicholas Piggin <npiggin@gmail.com> writes:
>
> > diff --git a/arch/powerpc/mm/pgtable-radix.c b/arch/powerpc/mm/pgtable-radix.c
> > index 328ff9abc333..435b19e74508 100644
> > --- a/arch/powerpc/mm/pgtable-radix.c
> > +++ b/arch/powerpc/mm/pgtable-radix.c
> > @@ -862,9 +862,9 @@ static void remove_pagetable(unsigned long start, unsigned long end)
> > radix__flush_tlb_kernel_range(start, end);
> > }
> >
> > -int __ref radix__create_section_mapping(unsigned long start, unsigned long end)
> > +int __ref radix__create_section_mapping(unsigned long start, unsigned long end, int nid)
> > {
> > - return create_physical_mapping(start, end);
> > + return create_physical_mapping(start, end, nid);
> > }
>
> This got a little muddled. We add the nid argument here, but
> create_physical_mapping() doesn't take it until patch 14.
>
> I managed to fix it by rearranging the last three patches and fiddling
> things a bit. If you can check the result once I push that would be good.
I think it looks okay how you've got it.
Thanks,
Nick
^ permalink raw reply
* Re: [PATCH] Extract initrd free logic from arch-specific code.
From: Russell King - ARM Linux @ 2018-03-29 15:27 UTC (permalink / raw)
To: Oliver
Cc: Rob Landley, Shea Levy, linux-riscv, linux-kernel,
Christoph Hellwig, Richard Henderson, Ivan Kokshaysky,
Matt Turner, Vineet Gupta, Catalin Marinas, Will Deacon,
Mark Salter, Aurelien Jacquiot, Mikael Starvik, Jesper Nilsson,
Yoshinori Sato, Richard Kuo, Tony Luck, Fenghua Yu,
Geert Uytterhoeven, James Hogan, Michal Simek, Ralf Baechle,
David Howells, Ley Foon Tan, Jonas Bonn, Stefan Kristiansson,
Stafford Horne, James E.J. Bottomley, Helge Deller,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Palmer Dabbelt, Albert Ou, Martin Schwidefsky, Heiko Carstens,
Chen Liqin, Lennox Wu, Rich Felker, David S. Miller, Jeff Dike,
Richard Weinberger, Guan Xuetao, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, x86, Chris Zankel, Max Filippov, Kate Stewart,
Greg Kroah-Hartman, Philippe Ombredanne, Eugeniy Paltsev, Al Viro,
Vladimir Murzin, Linus Walleij, Michal Hocko, Andrew Morton,
Sudip Mukherjee, Marc Zyngier, Rob Herring, Kees Cook,
Vlastimil Babka, Balbir Singh, Christophe Leroy, Joe Perches,
Dan Williams, Wei Yang, Christian König, Arnd Bergmann,
Deepa Dinamani, Daniel Thompson, Florian Fainelli, linux-alpha,
linux-snps-arc, linux-arm-kernel, adi-buildroot-devel,
linux-c6x-dev, linux-cris-kernel, uclinux-h8-devel, linux-hexagon,
linux-ia64, linux-m68k, linux-metag, linux-mips, linux-am33-list,
nios2-dev, openrisc, linux-parisc, linuxppc-dev, linux-s390,
linux-sh, sparclinux, user-mode-linux-devel, user-mode-linux-user,
linux-xtensa, Nicholas Piggin
In-Reply-To: <CAOSf1CG8gQjoL5rDMRMcZp=D8jBEQ9JBSG68=CiXnitC+4Kjvg@mail.gmail.com>
On Thu, Mar 29, 2018 at 09:37:52AM +1100, Oliver wrote:
> On Thu, Mar 29, 2018 at 9:14 AM, Russell King - ARM Linux
> <linux@armlinux.org.uk> wrote:
> > On Wed, Mar 28, 2018 at 02:04:22PM -0500, Rob Landley wrote:
> >>
> >>
> >> On 03/28/2018 11:48 AM, Russell King - ARM Linux wrote:
> >> > On Wed, Mar 28, 2018 at 10:58:51AM -0500, Rob Landley wrote:
> >> >> On 03/28/2018 10:26 AM, Shea Levy wrote:
> >> >>> Now only those architectures that have custom initrd free requirements
> >> >>> need to define free_initrd_mem.
> >> >> ...
> >> >>> --- a/arch/arc/mm/init.c
> >> >>> +++ b/arch/arc/mm/init.c
> >> >>> @@ -229,10 +229,3 @@ void __ref free_initmem(void)
> >> >>> {
> >> >>> free_initmem_default(-1);
> >> >>> }
> >> >>> -
> >> >>> -#ifdef CONFIG_BLK_DEV_INITRD
> >> >>> -void __init free_initrd_mem(unsigned long start, unsigned long end)
> >> >>> -{
> >> >>> - free_reserved_area((void *)start, (void *)end, -1, "initrd");
> >> >>> -}
> >> >>> -#endif
> >> >>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> >> >>> index 3f972e83909b..19d1c5594e2d 100644
> >> >>> --- a/arch/arm/Kconfig
> >> >>> +++ b/arch/arm/Kconfig
> >> >>> @@ -47,6 +47,7 @@ config ARM
> >> >>> select HARDIRQS_SW_RESEND
> >> >>> select HAVE_ARCH_AUDITSYSCALL if (AEABI && !OABI_COMPAT)
> >> >>> select HAVE_ARCH_BITREVERSE if (CPU_32v7M || CPU_32v7) && !CPU_32v6
> >> >>> + select HAVE_ARCH_FREE_INITRD_MEM
> >> >>> select HAVE_ARCH_JUMP_LABEL if !XIP_KERNEL && !CPU_ENDIAN_BE32 && MMU
> >> >>> select HAVE_ARCH_KGDB if !CPU_ENDIAN_BE32 && MMU
> >> >>> select HAVE_ARCH_MMAP_RND_BITS if MMU
> >> >>
> >> >> Isn't this why weak symbols were invented?
> >> >
> >> > Weak symbols means that we end up with both the weakly-referenced code
> >> > and the arch code in the kernel image. That's fine if the weak code
> >> > is small.
> >>
> >> The kernel's been able to build with link time garbage collection since 2016:
> >>
> >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b67067f1176d
> >>
> >> Wouldn't that remove the unused one?
> >
> > Probably, if anyone bothered to use that, which they don't.
> >
> > LD_DEAD_CODE_DATA_ELIMINATION is a symbol without a prompt, and from
> > what I can see, nothing selects it. Therefore, the symbol is always
> > disabled, and so the feature never gets used in mainline kernels.
> >
> > Brings up the obvious question - why is it there if it's completely
> > unused? (Maybe to cause confusion, and allowing a justification
> > for __weak ?)
>
> IIRC Nick had some patches to do the arch enablement for powerpc, but
> I'm not sure what happened to them though. I suspect it just fell down
> Nick's ever growing TODO list.
I've given it a go on ARM, marking every linker-built table with KEEP()
and comparing the System.map files. The resulting kernel is around
150k smaller, which seems good.
However, it doesn't boot - and I don't know why. Booting the kernel
under kvmtool in a VM using virtio-console, I can find no way to get
any kernel messages out of it. Using lkvm debug, I can see that the
PC is stuck inside die(), and that's the only information I have.
It dies before bringing up the other CPUs, so it's a very early death.
I don't think other console types are available under ARM64.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* Re: [PATCH] powerpc/64: Fix checksum folding in csum_add
From: LEROY Christophe @ 2018-03-29 15:36 UTC (permalink / raw)
To: Paul Mackerras
Cc: Benjamin Herrenschmidt, Michael Ellerman, linuxppc-dev,
Shile Zhang
In-Reply-To: <20180328204027.GA2069@fergus.ozlabs.ibm.com>
Paul Mackerras <paulus@ozlabs.org> a =C3=A9crit=C2=A0:
> On Tue, Mar 27, 2018 at 05:22:32PM +0200, LEROY Christophe wrote:
>> Shile Zhang <shile.zhang@nokia.com> a =C3=A9crit=C2=A0:
>>
>> >fix the missed point in Paul's patch:
>> >"powerpc/64: Fix checksum folding in csum_tcpudp_nofold and
>> >ip_fast_csum_nofold"
>> >
>> >Signed-off-by: Shile Zhang <shile.zhang@nokia.com>
>> >---
>> > arch/powerpc/include/asm/checksum.h | 2 +-
>> > 1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> >diff --git a/arch/powerpc/include/asm/checksum.h
>> >b/arch/powerpc/include/asm/checksum.h
>> >index 5b1a6e3..430d038 100644
>> >--- a/arch/powerpc/include/asm/checksum.h
>> >+++ b/arch/powerpc/include/asm/checksum.h
>> >@@ -108,7 +108,7 @@ static inline __wsum csum_add(__wsum csum,=20=20
>>=20__wsum addend)
>> >
>> > #ifdef __powerpc64__
>> > res +=3D (__force u64)addend;
>> >- return (__force __wsum)((u32)res + (res >> 32));
>> >+ return (__force __wsum) from64to32(res);
>>
>> Did you encounter a bug due to that ?
>> As far as i understand, csum and addend are 32 bits so can't exceed=20=
=20
>>=200xffffffff
>> Then their sum won't exceed 0x1fffffffe. So the sum of upper and lower p=
art
>> won't carry
>
> If the sum of the two halves was 0x1fffffffe, then that previously got
> truncated to 32 bits and returned as 0xfffffffe, which is wrong - the
> result should be 0xffffffff.
>
It is the sum of the two arguments of csum_add() which can't exceed=20=20
0x1fffffffe
So=20the sum of the two halves will be 0xffffffff which is the expected res=
ult.
The issue would start with res =3D 0x1ffffffff, in that case the sum of=20=
=20
the=20two halves would be 0x100000000 which would have been truncated to=20=
=20
0=20whereas we expect the result to be 1 in that case.
But in order to obtain res =3D 0x1ffffffff or higher, you have to sum at=20=
=20
least=20three 32 bits numbers. You can't obtain such a value with a sum=20=
=20
of=20two 32 bits numbers.
Christophe
^ permalink raw reply
* Re: [PATCH] Extract initrd free logic from arch-specific code.
From: Geert Uytterhoeven @ 2018-03-29 15:43 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Oliver, Rob Landley, Shea Levy, linux-riscv,
Linux Kernel Mailing List, Christoph Hellwig, Richard Henderson,
Ivan Kokshaysky, Matt Turner, Vineet Gupta, Catalin Marinas,
Will Deacon, Mark Salter, Aurelien Jacquiot, Mikael Starvik,
Jesper Nilsson, Yoshinori Sato, Richard Kuo, Tony Luck,
Fenghua Yu, James Hogan, Michal Simek, Ralf Baechle,
David Howells, Ley Foon Tan, Jonas Bonn, Stefan Kristiansson,
Stafford Horne, James E.J. Bottomley, Helge Deller,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Palmer Dabbelt, Albert Ou, Martin Schwidefsky, Heiko Carstens,
Chen Liqin, Lennox Wu, Rich Felker, David S. Miller, Jeff Dike,
Richard Weinberger, Guan Xuetao, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, the arch/x86 maintainers, Chris Zankel,
Max Filippov, Kate Stewart, Greg Kroah-Hartman,
Philippe Ombredanne, Eugeniy Paltsev, Al Viro, Vladimir Murzin,
Linus Walleij, Michal Hocko, Andrew Morton, Sudip Mukherjee,
Marc Zyngier, Rob Herring, Kees Cook, Vlastimil Babka,
Balbir Singh, Christophe Leroy, Joe Perches, Dan Williams,
Wei Yang, Christian König, Arnd Bergmann, Deepa Dinamani,
Daniel Thompson, Florian Fainelli, alpha, arcml, Linux ARM,
adi-buildroot-devel, linux-c6x-dev, Cris,
moderated list:H8/300 ARCHITECTURE, open list:QUALCOMM HEXAGON...,
linux-ia64, linux-m68k, open list:METAG ARCHITECTURE,
Linux MIPS Mailing List, moderated list:PANASONIC MN10300...,
nios2-dev, Openrisc, Parisc List, linuxppc-dev, linux-s390,
Linux-sh list, sparclinux, uml-devel, uml-user, linux-xtensa,
Nicholas Piggin
In-Reply-To: <20180329152749.GC16141@n2100.armlinux.org.uk>
On Thu, Mar 29, 2018 at 5:27 PM, Russell King - ARM Linux
<linux@armlinux.org.uk> wrote:
> On Thu, Mar 29, 2018 at 09:37:52AM +1100, Oliver wrote:
>> On Thu, Mar 29, 2018 at 9:14 AM, Russell King - ARM Linux
>> <linux@armlinux.org.uk> wrote:
>> > On Wed, Mar 28, 2018 at 02:04:22PM -0500, Rob Landley wrote:
>> >> On 03/28/2018 11:48 AM, Russell King - ARM Linux wrote:
>> >> > On Wed, Mar 28, 2018 at 10:58:51AM -0500, Rob Landley wrote:
>> >> >> On 03/28/2018 10:26 AM, Shea Levy wrote:
>> >> >>> Now only those architectures that have custom initrd free requirements
>> >> >>> need to define free_initrd_mem.
>> >> >> ...
>> >> >>> --- a/arch/arc/mm/init.c
>> >> >>> +++ b/arch/arc/mm/init.c
>> >> >>> @@ -229,10 +229,3 @@ void __ref free_initmem(void)
>> >> >>> {
>> >> >>> free_initmem_default(-1);
>> >> >>> }
>> >> >>> -
>> >> >>> -#ifdef CONFIG_BLK_DEV_INITRD
>> >> >>> -void __init free_initrd_mem(unsigned long start, unsigned long end)
>> >> >>> -{
>> >> >>> - free_reserved_area((void *)start, (void *)end, -1, "initrd");
>> >> >>> -}
>> >> >>> -#endif
>> >> >>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>> >> >>> index 3f972e83909b..19d1c5594e2d 100644
>> >> >>> --- a/arch/arm/Kconfig
>> >> >>> +++ b/arch/arm/Kconfig
>> >> >>> @@ -47,6 +47,7 @@ config ARM
>> >> >>> select HARDIRQS_SW_RESEND
>> >> >>> select HAVE_ARCH_AUDITSYSCALL if (AEABI && !OABI_COMPAT)
>> >> >>> select HAVE_ARCH_BITREVERSE if (CPU_32v7M || CPU_32v7) && !CPU_32v6
>> >> >>> + select HAVE_ARCH_FREE_INITRD_MEM
>> >> >>> select HAVE_ARCH_JUMP_LABEL if !XIP_KERNEL && !CPU_ENDIAN_BE32 && MMU
>> >> >>> select HAVE_ARCH_KGDB if !CPU_ENDIAN_BE32 && MMU
>> >> >>> select HAVE_ARCH_MMAP_RND_BITS if MMU
>> >> >>
>> >> >> Isn't this why weak symbols were invented?
>> >> >
>> >> > Weak symbols means that we end up with both the weakly-referenced code
>> >> > and the arch code in the kernel image. That's fine if the weak code
>> >> > is small.
>> >>
>> >> The kernel's been able to build with link time garbage collection since 2016:
>> >>
>> >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b67067f1176d
>> >>
>> >> Wouldn't that remove the unused one?
>> >
>> > Probably, if anyone bothered to use that, which they don't.
>> >
>> > LD_DEAD_CODE_DATA_ELIMINATION is a symbol without a prompt, and from
>> > what I can see, nothing selects it. Therefore, the symbol is always
>> > disabled, and so the feature never gets used in mainline kernels.
>> >
>> > Brings up the obvious question - why is it there if it's completely
>> > unused? (Maybe to cause confusion, and allowing a justification
>> > for __weak ?)
>>
>> IIRC Nick had some patches to do the arch enablement for powerpc, but
>> I'm not sure what happened to them though. I suspect it just fell down
>> Nick's ever growing TODO list.
>
> I've given it a go on ARM, marking every linker-built table with KEEP()
> and comparing the System.map files. The resulting kernel is around
> 150k smaller, which seems good.
>
> However, it doesn't boot - and I don't know why. Booting the kernel
> under kvmtool in a VM using virtio-console, I can find no way to get
> any kernel messages out of it. Using lkvm debug, I can see that the
> PC is stuck inside die(), and that's the only information I have.
> It dies before bringing up the other CPUs, so it's a very early death.
>
> I don't think other console types are available under ARM64.
earlycon?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 11/19] powerpc/powermac: Move pmac_pfunc_base_install prototype to header file
From: LEROY Christophe @ 2018-03-29 15:51 UTC (permalink / raw)
To: Mathieu Malaterre; +Cc: linuxppc-dev, Paul Mackerras, LKML, Michael Ellerman
In-Reply-To: <CA+7wUsxtWCoE1rxP6e57MEfB_zjLUzTa36CD=TyZS4_DkrQ81Q@mail.gmail.com>
Mathieu Malaterre <malat@debian.org> a =C3=A9crit=C2=A0:
> On Fri, Mar 23, 2018 at 1:13 PM, christophe leroy
> <christophe.leroy@c-s.fr> wrote:
>>
>>
>> Le 22/03/2018 =C3=A0 21:19, Mathieu Malaterre a =C3=A9crit :
>>>
>>> The pmac_pfunc_base_install prototype was declared in powermac/smp.c si=
nce
>>> function was used there, move it to pmac_pfunc.h header to be visible i=
n
>>> pfunc_base.c. Fix a warning treated as error with W=3D1:
>>>
>>> arch/powerpc/platforms/powermac/pfunc_base.c:330:12: error: no previ=
ous
>>> prototype for =E2=80=98pmac_pfunc_base_install=E2=80=99 [-Werror=3Dmiss=
ing-prototypes]
>>>
>>> Signed-off-by: Mathieu Malaterre <malat@debian.org>
>>> ---
>>> arch/powerpc/include/asm/pmac_pfunc.h | 1 +
>>> arch/powerpc/platforms/powermac/smp.c | 1 -
>>> 2 files changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/arch/powerpc/include/asm/pmac_pfunc.h
>>> b/arch/powerpc/include/asm/pmac_pfunc.h
>>> index 73bd8f28f2a8..99f7a288789a 100644
>>> --- a/arch/powerpc/include/asm/pmac_pfunc.h
>>> +++ b/arch/powerpc/include/asm/pmac_pfunc.h
>>> @@ -245,6 +245,7 @@ extern void pmf_put_function(struct pmf_function
>>> *func);
>>> extern int pmf_call_one(struct pmf_function *func, struct pmf_args
>>> *args);
>>> +extern int pmac_pfunc_base_install(void);
>>
>>
>>
>> extern keyword is not needed
>
> I understand; but for consistency every single protoypes in this
> header file actually use the extern keyword. Is there a guide/best
> practice to refer to in this case ?
Consistancy is not a valid reason to continue bad practice. Every=20=20
single=20modufication is an opportunity to clean things up
You should run script/checkpatch.pl --strict on all your patches=20=20
before=20submitting.
And follow as much as possible the linux codying style
Christophe
>
>> Christophe
>>
>>> /* Suspend/resume code called by via-pmu directly for now */
>>> extern void pmac_pfunc_base_suspend(void);
>>> diff --git a/arch/powerpc/platforms/powermac/smp.c
>>> b/arch/powerpc/platforms/powermac/smp.c
>>> index 95275e0e2efa..447da6db450a 100644
>>> --- a/arch/powerpc/platforms/powermac/smp.c
>>> +++ b/arch/powerpc/platforms/powermac/smp.c
>>> @@ -65,7 +65,6 @@
>>> #endif
>>> extern void __secondary_start_pmac_0(void);
>>> -extern int pmac_pfunc_base_install(void);
>>> static void (*pmac_tb_freeze)(int freeze);
>>> static u64 timebase;
>>>
>>
>> ---
>> L'absence de virus dans ce courrier =C3=A9lectronique a =C3=A9t=C3=A9 v=
=C3=A9rifi=C3=A9e par le
>> logiciel antivirus Avast.
>> https://www.avast.com/antivirus
>>
^ permalink raw reply
* Re: [PATCH] Extract initrd free logic from arch-specific code.
From: Russell King - ARM Linux @ 2018-03-29 15:58 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Oliver, Rob Landley, Shea Levy, linux-riscv,
Linux Kernel Mailing List, Christoph Hellwig, Richard Henderson,
Ivan Kokshaysky, Matt Turner, Vineet Gupta, Catalin Marinas,
Will Deacon, Mark Salter, Aurelien Jacquiot, Mikael Starvik,
Jesper Nilsson, Yoshinori Sato, Richard Kuo, Tony Luck,
Fenghua Yu, James Hogan, Michal Simek, Ralf Baechle,
David Howells, Ley Foon Tan, Jonas Bonn, Stefan Kristiansson,
Stafford Horne, James E.J. Bottomley, Helge Deller,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Palmer Dabbelt, Albert Ou, Martin Schwidefsky, Heiko Carstens,
Chen Liqin, Lennox Wu, Rich Felker, David S. Miller, Jeff Dike,
Richard Weinberger, Guan Xuetao, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, the arch/x86 maintainers, Chris Zankel,
Max Filippov, Kate Stewart, Greg Kroah-Hartman,
Philippe Ombredanne, Eugeniy Paltsev, Al Viro, Vladimir Murzin,
Linus Walleij, Michal Hocko, Andrew Morton, Sudip Mukherjee,
Marc Zyngier, Rob Herring, Kees Cook, Vlastimil Babka,
Balbir Singh, Christophe Leroy, Joe Perches, Dan Williams,
Wei Yang, Christian König, Arnd Bergmann, Deepa Dinamani,
Daniel Thompson, Florian Fainelli, alpha, arcml, Linux ARM,
adi-buildroot-devel, linux-c6x-dev, Cris,
moderated list:H8/300 ARCHITECTURE, open list:QUALCOMM HEXAGON...,
linux-ia64, linux-m68k, open list:METAG ARCHITECTURE,
Linux MIPS Mailing List, moderated list:PANASONIC MN10300...,
nios2-dev, Openrisc, Parisc List, linuxppc-dev, linux-s390,
Linux-sh list, sparclinux, uml-devel, uml-user, linux-xtensa,
Nicholas Piggin
In-Reply-To: <CAMuHMdXAckNiUQKT2WU6xaJjbECrifmH6fg_mET+h3iXf_RgDQ@mail.gmail.com>
On Thu, Mar 29, 2018 at 05:43:47PM +0200, Geert Uytterhoeven wrote:
> On Thu, Mar 29, 2018 at 5:27 PM, Russell King - ARM Linux
> <linux@armlinux.org.uk> wrote:
> > On Thu, Mar 29, 2018 at 09:37:52AM +1100, Oliver wrote:
> >> On Thu, Mar 29, 2018 at 9:14 AM, Russell King - ARM Linux
> >> <linux@armlinux.org.uk> wrote:
> >> > On Wed, Mar 28, 2018 at 02:04:22PM -0500, Rob Landley wrote:
> >> >> On 03/28/2018 11:48 AM, Russell King - ARM Linux wrote:
> >> >> > On Wed, Mar 28, 2018 at 10:58:51AM -0500, Rob Landley wrote:
> >> >> >> On 03/28/2018 10:26 AM, Shea Levy wrote:
> >> >> >>> Now only those architectures that have custom initrd free requirements
> >> >> >>> need to define free_initrd_mem.
> >> >> >> ...
> >> >> >>> --- a/arch/arc/mm/init.c
> >> >> >>> +++ b/arch/arc/mm/init.c
> >> >> >>> @@ -229,10 +229,3 @@ void __ref free_initmem(void)
> >> >> >>> {
> >> >> >>> free_initmem_default(-1);
> >> >> >>> }
> >> >> >>> -
> >> >> >>> -#ifdef CONFIG_BLK_DEV_INITRD
> >> >> >>> -void __init free_initrd_mem(unsigned long start, unsigned long end)
> >> >> >>> -{
> >> >> >>> - free_reserved_area((void *)start, (void *)end, -1, "initrd");
> >> >> >>> -}
> >> >> >>> -#endif
> >> >> >>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> >> >> >>> index 3f972e83909b..19d1c5594e2d 100644
> >> >> >>> --- a/arch/arm/Kconfig
> >> >> >>> +++ b/arch/arm/Kconfig
> >> >> >>> @@ -47,6 +47,7 @@ config ARM
> >> >> >>> select HARDIRQS_SW_RESEND
> >> >> >>> select HAVE_ARCH_AUDITSYSCALL if (AEABI && !OABI_COMPAT)
> >> >> >>> select HAVE_ARCH_BITREVERSE if (CPU_32v7M || CPU_32v7) && !CPU_32v6
> >> >> >>> + select HAVE_ARCH_FREE_INITRD_MEM
> >> >> >>> select HAVE_ARCH_JUMP_LABEL if !XIP_KERNEL && !CPU_ENDIAN_BE32 && MMU
> >> >> >>> select HAVE_ARCH_KGDB if !CPU_ENDIAN_BE32 && MMU
> >> >> >>> select HAVE_ARCH_MMAP_RND_BITS if MMU
> >> >> >>
> >> >> >> Isn't this why weak symbols were invented?
> >> >> >
> >> >> > Weak symbols means that we end up with both the weakly-referenced code
> >> >> > and the arch code in the kernel image. That's fine if the weak code
> >> >> > is small.
> >> >>
> >> >> The kernel's been able to build with link time garbage collection since 2016:
> >> >>
> >> >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b67067f1176d
> >> >>
> >> >> Wouldn't that remove the unused one?
> >> >
> >> > Probably, if anyone bothered to use that, which they don't.
> >> >
> >> > LD_DEAD_CODE_DATA_ELIMINATION is a symbol without a prompt, and from
> >> > what I can see, nothing selects it. Therefore, the symbol is always
> >> > disabled, and so the feature never gets used in mainline kernels.
> >> >
> >> > Brings up the obvious question - why is it there if it's completely
> >> > unused? (Maybe to cause confusion, and allowing a justification
> >> > for __weak ?)
> >>
> >> IIRC Nick had some patches to do the arch enablement for powerpc, but
> >> I'm not sure what happened to them though. I suspect it just fell down
> >> Nick's ever growing TODO list.
> >
> > I've given it a go on ARM, marking every linker-built table with KEEP()
> > and comparing the System.map files. The resulting kernel is around
> > 150k smaller, which seems good.
> >
> > However, it doesn't boot - and I don't know why. Booting the kernel
> > under kvmtool in a VM using virtio-console, I can find no way to get
> > any kernel messages out of it. Using lkvm debug, I can see that the
> > PC is stuck inside die(), and that's the only information I have.
> > It dies before bringing up the other CPUs, so it's a very early death.
> >
> > I don't think other console types are available under ARM64.
>
> earlycon?
Through what - as I say above, I think the only thing that's present is
virtio-console, and the virtio stack only get initialised much later in
boot.
Eg, there's the memory-based virtio driver which interfaces any virtio
driver to a memory-based ring structures for communication with the host
(drivers/virtio/virtio_mmio.c) which is initialised at module_init()
time, and so isn't available for earlycon.
I don't think merely changing the module_init() calls in the appropriate
virtio bits will suffice - it's why I pointed out that it dies before
SMP initialisation, which also means that it dies before we start
running the initcalls for subsystems and drivers.
I'm not aware of there being an emulated UART in the guest's address
space, so serial based stuff doesn't work.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* Re: [PATCH 15/19] powerpc: Add missing prototype
From: LEROY Christophe @ 2018-03-29 16:02 UTC (permalink / raw)
To: Mathieu Malaterre; +Cc: linuxppc-dev, Paul Mackerras, LKML, Michael Ellerman
In-Reply-To: <CA+7wUsyRSSkwgpBodKkPjhUxiHy-t1q2Q7nsorfRoL=wfxgyFQ@mail.gmail.com>
Mathieu Malaterre <malat@debian.org> a =C3=A9crit=C2=A0:
> On Fri, Mar 23, 2018 at 1:20 PM, christophe leroy
> <christophe.leroy@c-s.fr> wrote:
>>
>>
>> Le 22/03/2018 =C3=A0 21:20, Mathieu Malaterre a =C3=A9crit :
>>>
>>> Add one missing prototype for function rh_dump_blk. Fix warning treated=
as
>>> error in W=3D1:
>>>
>>> arch/powerpc/lib/rheap.c:740:6: error: no previous prototype for
>>> =E2=80=98rh_dump_blk=E2=80=99 [-Werror=3Dmissing-prototypes]
>>>
>>> Signed-off-by: Mathieu Malaterre <malat@debian.org>
>>> ---
>>> arch/powerpc/include/asm/rheap.h | 3 +++
>>> 1 file changed, 3 insertions(+)
>>>
>>> diff --git a/arch/powerpc/include/asm/rheap.h
>>> b/arch/powerpc/include/asm/rheap.h
>>> index 172381769cfc..e75d96de19a0 100644
>>> --- a/arch/powerpc/include/asm/rheap.h
>>> +++ b/arch/powerpc/include/asm/rheap.h
>>> @@ -83,6 +83,9 @@ extern int rh_get_stats(rh_info_t * info, int what, i=
nt
>>> max_stats,
>>> /* Simple dump of remote heap info */
>>> extern void rh_dump(rh_info_t * info);
>>> +/* Simple dump of remote info block */
>>> +extern void rh_dump_blk(rh_info_t *info, rh_block_t *blk);
>>> +
>>
>>
>> Only used in one place, should be static
>
> Well here is what I see over here:
>
> $ git grep rh_dump_blk
> ...
> arch/powerpc/lib/rheap.c:EXPORT_SYMBOL_GPL(rh_dump_blk);
If it was really used by anybody in a module, it would already be in a=20=
=20
.h=20so I think we should simply delete the function
Christophe
>
>
>
>> Christophe
>>
>>> /* Set owner of taken block */
>>> extern int rh_set_owner(rh_info_t * info, unsigned long start, const
>>> char *owner);
>>>
>>
>>
>> ---
>> L'absence de virus dans ce courrier =C3=A9lectronique a =C3=A9t=C3=A9 v=
=C3=A9rifi=C3=A9e par le
>> logiciel antivirus Avast.
>> https://www.avast.com/antivirus
>>
^ permalink raw reply
* Re: [PATCH v2 01/19] powerpc/powermac: Mark variable x as unused
From: LEROY Christophe @ 2018-03-29 16:07 UTC (permalink / raw)
To: Mathieu Malaterre
Cc: linux-kernel, linuxppc-dev, Paul Mackerras,
Benjamin Herrenschmidt, Michael Ellerman
In-Reply-To: <20180328192717.656-1-malat@debian.org>
Mathieu Malaterre <malat@debian.org> a =C3=A9crit=C2=A0:
> Since the value of x is never intended to be read, declare it with gcc
> attribute as unused. Fix warning treated as error with W=3D1:
>
> arch/powerpc/platforms/powermac/bootx_init.c:471:21: error:=20=20
>=20variable =E2=80=98x=E2=80=99 set but not used [-Werror=3Dunused-but-set=
-variable]
>
> Signed-off-by: Mathieu Malaterre <malat@debian.org>
> ---
> v2: move x variable within its local scope
>
> arch/powerpc/platforms/powermac/bootx_init.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/platforms/powermac/bootx_init.c=20=20
>=20b/arch/powerpc/platforms/powermac/bootx_init.c
> index c3c9bbb3573a..d44e8571c1ec 100644
> --- a/arch/powerpc/platforms/powermac/bootx_init.c
> +++ b/arch/powerpc/platforms/powermac/bootx_init.c
> @@ -468,7 +468,7 @@ void __init bootx_init(unsigned long r3,=20=20
>=20unsigned long r4)
> boot_infos_t *bi =3D (boot_infos_t *) r4;
> unsigned long hdr;
> unsigned long space;
> - unsigned long ptr, x;
> + unsigned long ptr;
> char *model;
> unsigned long offset =3D reloc_offset();
>
> @@ -562,6 +562,7 @@ void __init bootx_init(unsigned long r3,=20=20
>=20unsigned long r4)
> * MMU switched OFF, so this should not be useful anymore.
> */
> if (bi->version < 4) {
> + unsigned long x __maybe_unused;
> bootx_printf("Touching pages...\n");
Stylewise, there should be an empty line after your declaration.
But I believe you should remove that ugly loop and replace it by a=20=20
call=20to fault_in_pages_readable()
Christophe
>
> /*
> --
> 2.11.0
^ permalink raw reply
* Re: [PATCH v2 02/19] powerpc/powermac: Mark variable x as unused
From: LEROY Christophe @ 2018-03-29 16:09 UTC (permalink / raw)
To: Mathieu Malaterre
Cc: linux-kernel, linuxppc-dev, Paul Mackerras,
Benjamin Herrenschmidt, Michael Ellerman
In-Reply-To: <20180328193028.823-1-malat@debian.org>
Mathieu Malaterre <malat@debian.org> a =C3=A9crit=C2=A0:
> Since the value of x is never intended to be read, remove it. Fix warning
> treated as error with W=3D1:
>
> arch/powerpc/platforms/powermac/udbg_scc.c:76:9: error: variable=20=20
>=20=E2=80=98x=E2=80=99 set but not used [-Werror=3Dunused-but-set-variable=
]
>
> Suggested-by: Christophe Leroy <christophe.leroy@c-s.fr>
> Signed-off-by: Mathieu Malaterre <malat@debian.org>
Reviewed-by: Christophe Leroy <christophe.leroy@c-s.fr>
> ---
> v2: remove x completely
>
> arch/powerpc/platforms/powermac/udbg_scc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/platforms/powermac/udbg_scc.c=20=20
>=20b/arch/powerpc/platforms/powermac/udbg_scc.c
> index d83135a9830e..8901973ed683 100644
> --- a/arch/powerpc/platforms/powermac/udbg_scc.c
> +++ b/arch/powerpc/platforms/powermac/udbg_scc.c
> @@ -73,7 +73,7 @@ void udbg_scc_init(int force_scc)
> struct device_node *stdout =3D NULL, *escc =3D NULL, *macio =3D NULL;
> struct device_node *ch, *ch_def =3D NULL, *ch_a =3D NULL;
> const char *path;
> - int i, x;
> + int i;
>
> escc =3D of_find_node_by_name(NULL, "escc");
> if (escc =3D=3D NULL)
> @@ -120,7 +120,7 @@ void udbg_scc_init(int force_scc)
> mb();
>
> for (i =3D 20000; i !=3D 0; --i)
> - x =3D in_8(sccc);
> + in_8(sccc);
> out_8(sccc, 0x09); /* reset A or B side */
> out_8(sccc, 0xc0);
>
> --
> 2.11.0
^ permalink raw reply
* Re: [PATCH v2 03/19] powerpc: Mark variables as unused
From: LEROY Christophe @ 2018-03-29 16:14 UTC (permalink / raw)
To: Mathieu Malaterre
Cc: linux-kernel, linuxppc-dev, Paul Mackerras,
Benjamin Herrenschmidt, Michael Ellerman
In-Reply-To: <20180328193307.978-1-malat@debian.org>
Mathieu Malaterre <malat@debian.org> a =C3=A9crit=C2=A0:
> Add gcc attribute unused for two variables. Fix warnings treated as error=
s
> with W=3D1:
>
> arch/powerpc/kernel/prom_init.c:1388:8: error: variable =E2=80=98path=
=E2=80=99 set=20=20
>=20but not used [-Werror=3Dunused-but-set-variable]
>
> Suggested-by: Christophe Leroy <christophe.leroy@c-s.fr>
> Signed-off-by: Mathieu Malaterre <malat@debian.org>
> ---
> v2: move path within ifdef DEBUG_PROM
>
> arch/powerpc/kernel/prom_init.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/kernel/prom_init.c=20=20
>=20b/arch/powerpc/kernel/prom_init.c
> index acf4b2e0530c..4163b11abb6c 100644
> --- a/arch/powerpc/kernel/prom_init.c
> +++ b/arch/powerpc/kernel/prom_init.c
> @@ -603,7 +603,7 @@ static void __init early_cmdline_parse(void)
> const char *opt;
>
> char *p;
> - int l =3D 0;
> + int l __maybe_unused =3D 0;
>
> prom_cmd_line[0] =3D 0;
> p =3D prom_cmd_line;
> @@ -1385,7 +1385,7 @@ static void __init reserve_mem(u64 base, u64 size)
> static void __init prom_init_mem(void)
> {
> phandle node;
> - char *path, type[64];
> + char *path __maybe_unused, type[64];
You should enclose that in an ifdef DEBUG_PROM instead of hiding the warnin=
g
Christophe
> unsigned int plen;
> cell_t *p, *endp;
> __be32 val;
> @@ -1406,7 +1406,6 @@ static void __init prom_init_mem(void)
> prom_debug("root_size_cells: %x\n", rsc);
>
> prom_debug("scanning memory:\n");
> - path =3D prom_scratch;
>
> for (node =3D 0; prom_next_node(&node); ) {
> type[0] =3D 0;
> @@ -1431,6 +1430,7 @@ static void __init prom_init_mem(void)
> endp =3D p + (plen / sizeof(cell_t));
>
> #ifdef DEBUG_PROM
> + path =3D prom_scratch;
> memset(path, 0, PROM_SCRATCH_SIZE);
> call_prom("package-to-path", 3, 1, node, path, PROM_SCRATCH_SIZE-1);
> prom_debug(" node %s :\n", path);
> --
> 2.11.0
^ permalink raw reply
* Re: [PATCH v2 05/19] powerpc/chrp/setup: Add attribute unused and make some functions static
From: LEROY Christophe @ 2018-03-29 16:16 UTC (permalink / raw)
To: Mathieu Malaterre
Cc: linux-kernel, linuxppc-dev, Paul Mackerras,
Benjamin Herrenschmidt, Michael Ellerman
In-Reply-To: <20180328193553.1122-1-malat@debian.org>
The subject of the patch should be updated as well
Christophe
Mathieu Malaterre <malat@debian.org> a =C3=A9crit=C2=A0:
> Remove variable declaration idu_size and associated code since not used.
>
> These functions can all be static, make it so. Fix warnings treated as
> errors with W=3D1:
>
> arch/powerpc/platforms/chrp/setup.c:97:6: error: no previous=20=20
>=20prototype for =E2=80=98chrp_show_cpuinfo=E2=80=99 [-Werror=3Dmissing-pr=
ototypes]
> arch/powerpc/platforms/chrp/setup.c:302:13: error: no previous=20=20
>=20prototype for =E2=80=98chrp_setup_arch=E2=80=99 [-Werror=3Dmissing-prot=
otypes]
> arch/powerpc/platforms/chrp/setup.c:385:16: error: variable=20=20
>=20=E2=80=98idu_size=E2=80=99 set but not used [-Werror=3Dunused-but-set-v=
ariable]
> arch/powerpc/platforms/chrp/setup.c:526:13: error: no previous=20=20
>=20prototype for =E2=80=98chrp_init_IRQ=E2=80=99 [-Werror=3Dmissing-protot=
ypes]
> arch/powerpc/platforms/chrp/setup.c:559:1: error: no previous=20=20
>=20prototype for =E2=80=98chrp_init2=E2=80=99 [-Werror=3Dmissing-prototype=
s]
>
> Suggested-by: Christophe Leroy <christophe.leroy@c-s.fr>
> Signed-off-by: Mathieu Malaterre <malat@debian.org>
> ---
> v2: Remove totally variable idu_size
> arch/powerpc/platforms/chrp/setup.c | 12 +++++-------
> 1 file changed, 5 insertions(+), 7 deletions(-)
>
> diff --git a/arch/powerpc/platforms/chrp/setup.c=20=20
>=20b/arch/powerpc/platforms/chrp/setup.c
> index 481ed133e04b..d6d8ffc0271e 100644
> --- a/arch/powerpc/platforms/chrp/setup.c
> +++ b/arch/powerpc/platforms/chrp/setup.c
> @@ -94,7 +94,7 @@ static const char *chrp_names[] =3D {
> "Total Impact Briq"
> };
>
> -void chrp_show_cpuinfo(struct seq_file *m)
> +static void chrp_show_cpuinfo(struct seq_file *m)
> {
> int i, sdramen;
> unsigned int t;
> @@ -299,7 +299,7 @@ static __init void chrp_init(void)
> of_node_put(node);
> }
>
> -void __init chrp_setup_arch(void)
> +static void __init chrp_setup_arch(void)
> {
> struct device_node *root =3D of_find_node_by_path("/");
> const char *machine =3D NULL;
> @@ -382,7 +382,7 @@ static void __init chrp_find_openpic(void)
> {
> struct device_node *np, *root;
> int len, i, j;
> - int isu_size, idu_size;
> + int isu_size;
> const unsigned int *iranges, *opprop =3D NULL;
> int oplen =3D 0;
> unsigned long opaddr;
> @@ -427,11 +427,9 @@ static void __init chrp_find_openpic(void)
> }
>
> isu_size =3D 0;
> - idu_size =3D 0;
> if (len > 0 && iranges[1] !=3D 0) {
> printk(KERN_INFO "OpenPIC irqs %d..%d in IDU\n",
> iranges[0], iranges[0] + iranges[1] - 1);
> - idu_size =3D iranges[1];
> }
> if (len > 1)
> isu_size =3D iranges[3];
> @@ -523,7 +521,7 @@ static void __init chrp_find_8259(void)
> }
> }
>
> -void __init chrp_init_IRQ(void)
> +static void __init chrp_init_IRQ(void)
> {
> #if defined(CONFIG_VT) && defined(CONFIG_INPUT_ADBHID) &&=20=20
>=20defined(CONFIG_XMON)
> struct device_node *kbd;
> @@ -555,7 +553,7 @@ void __init chrp_init_IRQ(void)
> #endif
> }
>
> -void __init
> +static void __init
> chrp_init2(void)
> {
> #ifdef CONFIG_NVRAM
> --
> 2.11.0
^ permalink raw reply
* Re: [PATCH v2 04/19] powerpc/kvm: Prefer fault_in_pages_readable function
From: LEROY Christophe @ 2018-03-29 16:18 UTC (permalink / raw)
To: Mathieu Malaterre
Cc: linux-kernel, linuxppc-dev, kvm-ppc, Benjamin Herrenschmidt,
Paul Mackerras, Michael Ellerman
In-Reply-To: <20180328195811.27758-1-malat@debian.org>
Mathieu Malaterre <malat@debian.org> a =C3=A9crit=C2=A0:
> Directly use fault_in_pages_readable instead of manual __get_user code. F=
ix
> warning treated as error with W=3D1:
>
> arch/powerpc/kernel/kvm.c:675:6: error: variable =E2=80=98tmp=E2=80=99 =
set but not=20=20
>=20used [-Werror=3Dunused-but-set-variable]
>
> Suggested-by: Christophe Leroy <christophe.leroy@c-s.fr>
> Signed-off-by: Mathieu Malaterre <malat@debian.org>
Reviewed-by: Christophe Leroy <christophe.leroy@c-s.fr>
> ---
> v2: use fault_in_pages_readable instead
> arch/powerpc/kernel/kvm.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/kernel/kvm.c b/arch/powerpc/kernel/kvm.c
> index 9ad37f827a97..124c51030b75 100644
> --- a/arch/powerpc/kernel/kvm.c
> +++ b/arch/powerpc/kernel/kvm.c
> @@ -25,6 +25,7 @@
> #include <linux/kvm_para.h>
> #include <linux/slab.h>
> #include <linux/of.h>
> +#include <linux/pagemap.h>
>
> #include <asm/reg.h>
> #include <asm/sections.h>
> @@ -672,14 +673,13 @@ static void kvm_use_magic_page(void)
> {
> u32 *p;
> u32 *start, *end;
> - u32 tmp;
> u32 features;
>
> /* Tell the host to map the magic page to -4096 on all CPUs */
> on_each_cpu(kvm_map_magic_page, &features, 1);
>
> /* Quick self-test to see if the mapping works */
> - if (__get_user(tmp, (u32*)KVM_MAGIC_PAGE)) {
> + if (!fault_in_pages_readable((const char *)KVM_MAGIC_PAGE, sizeof(u32))=
) {
> kvm_patching_worked =3D false;
> return;
> }
> --
> 2.11.0
^ permalink raw reply
* Re: RFC on writel and writel_relaxed
From: Arnd Bergmann @ 2018-03-29 16:29 UTC (permalink / raw)
To: Sinan Kaya
Cc: David Miller, Benjamin Herrenschmidt, Linus Torvalds,
Alexander Duyck, Will Deacon, Jason Gunthorpe, David Laight,
Oliver O'Halloran, linuxppc-dev, linux-rdma, Alexander Duyck,
Paul E. McKenney, Networking, Linus Torvalds
In-Reply-To: <29fe17e0-9978-dc43-d02c-de8fabdc66c2@codeaurora.org>
On Thu, Mar 29, 2018 at 3:56 PM, Sinan Kaya <okaya@codeaurora.org> wrote:
> On 3/28/2018 11:55 AM, David Miller wrote:
>> From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>> Date: Thu, 29 Mar 2018 02:13:16 +1100
>>
>>> Let's fix all archs, it's way easier than fixing all drivers. Half of
>>> the archs are unused or dead anyway.
>>
>> Agreed.
>>
>
> I pinged most of the maintainers yesterday.
> Which arches do we care about these days?
> I have not been paying attention any other architecture besides arm64.
>
> arch status detail
> ------ ------------- ------------------------------------
> alpha question sent
I'm guessing alpha has problems
extern inline u32 readl(const volatile void __iomem *addr)
{
u32 ret = __raw_readl(addr);
mb();
return ret;
}
extern inline void writel(u32 b, volatile void __iomem *addr)
{
__raw_writel(b, addr);
mb();
}
There is a barrier in writel /after/ the acess but not before.
> arc question sent ysato@users.sourceforge.jp will fix it.
> arm no issues
> arm64 no issues
> blackfin question sent about to be removed
> c6x question sent
no PCI, so it might not matter that much -- all drivers
are platform specific in the end.
> cris question sent
> frv
cris and frv are getting removed
> h8300 question sent
no PCI
> hexagon question sent
no PCI
> ia64 no issues confirmed by Tony Luck
> m32r
removed
> m68k question sent
> metag
removed
> microblaze question sent
> mips question sent
I'm guessing that some mips platforms have problems, but others don't.
> mn10300 question sent
removed
> nios2 question sent
no PCI
> openrisc no issues shorne@gmail.com says should no issues
> parisc no issues grantgrundler@gmail.com says most probably no problem but still looking
> powerpc no issues
> riscv question sent
riscv should be fine
> s390 question sent
Pretty sure this is also fine
> score question sent
removed
> sh question sent
> sparc question sent
> tile question sent
removed
> unicore32 question sent
Note the maintainer's new email address in linux-next.
> x86 no issues
> xtensa question sent
removed.
Arnd
^ permalink raw reply
* Re: [PATCH] Extract initrd free logic from arch-specific code.
From: Rob Landley @ 2018-03-29 16:39 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Shea Levy, linux-riscv, linux-kernel, Christoph Hellwig,
Richard Henderson, Ivan Kokshaysky, Matt Turner, Vineet Gupta,
Catalin Marinas, Will Deacon, Mark Salter, Aurelien Jacquiot,
Mikael Starvik, Jesper Nilsson, Yoshinori Sato, Richard Kuo,
Tony Luck, Fenghua Yu, Geert Uytterhoeven, James Hogan,
Michal Simek, Ralf Baechle, David Howells, Ley Foon Tan,
Jonas Bonn, Stefan Kristiansson, Stafford Horne,
James E.J. Bottomley, Helge Deller, Benjamin Herrenschmidt,
Paul Mackerras, Michael Ellerman, Palmer Dabbelt, Albert Ou,
Martin Schwidefsky, Heiko Carstens, Chen Liqin, Lennox Wu,
Rich Felker, David S. Miller, Jeff Dike, Richard Weinberger,
Guan Xuetao, Thomas Gleixner, Ingo Molnar, H. Peter Anvin, x86,
Chris Zankel, Max Filippov, Kate Stewart, Greg Kroah-Hartman,
Philippe Ombredanne, Eugeniy Paltsev, Al Viro, Vladimir Murzin,
Linus Walleij, Michal Hocko, Andrew Morton, Sudip Mukherjee,
Marc Zyngier, Rob Herring, Kees Cook, Vlastimil Babka,
Balbir Singh, Christophe Leroy, Joe Perches,
Oliver O'Halloran, Dan Williams, Wei Yang,
Christian König, Arnd Bergmann, Deepa Dinamani,
Daniel Thompson, Florian Fainelli, linux-alpha, linux-snps-arc,
linux-arm-kernel, adi-buildroot-devel, linux-c6x-dev,
linux-cris-kernel, uclinux-h8-devel, linux-hexagon, linux-ia64,
linux-m68k, linux-metag, linux-mips, linux-am33-list, nios2-dev,
openrisc, linux-parisc, linuxppc-dev, linux-s390, linux-sh,
sparclinux, user-mode-linux-devel, user-mode-linux-user,
linux-xtensa
In-Reply-To: <20180328221401.GA14084@n2100.armlinux.org.uk>
On 03/28/2018 05:14 PM, Russell King - ARM Linux wrote:
> On Wed, Mar 28, 2018 at 02:04:22PM -0500, Rob Landley wrote:
>>
>>
>> On 03/28/2018 11:48 AM, Russell King - ARM Linux wrote:
>>> On Wed, Mar 28, 2018 at 10:58:51AM -0500, Rob Landley wrote:
>>>> On 03/28/2018 10:26 AM, Shea Levy wrote:
>>>>> Now only those architectures that have custom initrd free requirements
>>>>> need to define free_initrd_mem.
>>>> ...
>>>>> --- a/arch/arc/mm/init.c
>>>>> +++ b/arch/arc/mm/init.c
>>>>> @@ -229,10 +229,3 @@ void __ref free_initmem(void)
>>>>> {
>>>>> free_initmem_default(-1);
>>>>> }
>>>>> -
>>>>> -#ifdef CONFIG_BLK_DEV_INITRD
>>>>> -void __init free_initrd_mem(unsigned long start, unsigned long end)
>>>>> -{
>>>>> - free_reserved_area((void *)start, (void *)end, -1, "initrd");
>>>>> -}
>>>>> -#endif
>>>>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>>>>> index 3f972e83909b..19d1c5594e2d 100644
>>>>> --- a/arch/arm/Kconfig
>>>>> +++ b/arch/arm/Kconfig
>>>>> @@ -47,6 +47,7 @@ config ARM
>>>>> select HARDIRQS_SW_RESEND
>>>>> select HAVE_ARCH_AUDITSYSCALL if (AEABI && !OABI_COMPAT)
>>>>> select HAVE_ARCH_BITREVERSE if (CPU_32v7M || CPU_32v7) && !CPU_32v6
>>>>> + select HAVE_ARCH_FREE_INITRD_MEM
>>>>> select HAVE_ARCH_JUMP_LABEL if !XIP_KERNEL && !CPU_ENDIAN_BE32 && MMU
>>>>> select HAVE_ARCH_KGDB if !CPU_ENDIAN_BE32 && MMU
>>>>> select HAVE_ARCH_MMAP_RND_BITS if MMU
>>>>
>>>> Isn't this why weak symbols were invented?
>>>
>>> Weak symbols means that we end up with both the weakly-referenced code
>>> and the arch code in the kernel image. That's fine if the weak code
>>> is small.
>>
>> The kernel's been able to build with link time garbage collection since 2016:
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b67067f1176d
>>
>> Wouldn't that remove the unused one?
>
> Probably, if anyone bothered to use that, which they don't.
>
> LD_DEAD_CODE_DATA_ELIMINATION is a symbol without a prompt, and from
> what I can see, nothing selects it. Therefore, the symbol is always
> disabled, and so the feature never gets used in mainline kernels.
It looks like there are per-architecture linker scripts that need to be updated?
So if an architecture supports it, it's always done (well, it probes for the
toolchain supporting the flag). And if the architecture doesn't support it, the
linker script needs to be updated to mark sections with "I know nothing seems to
reference this at the ELF level but keep it anyway, we're pulling an assembly
trick".
> Brings up the obvious question - why is it there if it's completely
> unused? (Maybe to cause confusion, and allowing a justification
> for __weak ?)
Presumably it will become the default on architectures as their linker scripts
are converted. Once they're all converted the config symbol can go away. (Given
the move to requiring gcc 4.7 or whatever it is, there can't be an architecture
depending on a toolchain that _doesn't_ support it after that point. I doubt you
can pair gcc 4.7 with a >12 year old binutils and expect good things...)
Rob
^ permalink raw reply
* Re: RFC on writel and writel_relaxed
From: Jason Gunthorpe @ 2018-03-29 16:40 UTC (permalink / raw)
To: David Laight
Cc: Will Deacon, Benjamin Herrenschmidt, Arnd Bergmann, Sinan Kaya,
Oliver, open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
linux-rdma@vger.kernel.org, Paul E. McKenney, Peter Zijlstra,
Ingo Molnar, Jonathan Corbet
In-Reply-To: <4ce6f0338fe04574bd3c0633c522a1c7@AcuMS.aculab.com>
On Thu, Mar 29, 2018 at 02:58:34PM +0000, David Laight wrote:
> From: Jason Gunthorpe
> > Sent: 29 March 2018 15:45
> ...
> > > > When talking about ordering between the devices, the relevant question
> > > > is what happens if the writel(DEVICE_BAR) triggers DEVICE_BAR to DMA
> > > > from the DEVICE_FOO. 'ordered' means that in this case
> > > > writel(DEVICE_FOO) must be presented to FOO before anything generated
> > > > by BAR.
> > >
> > > Yes, and that isn't the case for arm because the writes can still be
> > > buffered.
> >
> > The statement is not about buffering, or temporal completion order, or
> > the order of acks returning to the CPU. It is about pure transaction
> > ordering inside the interconnect.
> >
> > Can write BAR -> FOO pass write CPU -> FOO?
>
> Almost certainly.
> The first cpu write can almost certainly be 'stalled' at the shared PCIe bridge.
> The second cpu write then completes (to a different target).
> That target then issues a peer to peer transfer that reaches the shared bridge.
> I doubt the order of the transactions is guaranteed when it becomes 'un-stalled'.
The PCI spec has very strong wording on ordering that covers this
case. Stalled bridges have to follow the ordering rules, and posted
writes cannot pass other posted writes.
Since in PCI all three transactions:
CPU -> FOO
CPU -> BAR
BAR -> FOO
Must traverse a shared bus segment, they must be placed on that bus in
the above order, and the bridge(s) toward FOO must preserve this
order.
ARM's AXI has similar rules, I just can't recall the tiny details
right now :)
> Of course, these are peer to peer transfers, and strange ones at that.
> Normally you'd not be doing peer to peer transfers that access 'memory'
> the cpu has just written to.
It is the best situation I can think of where order of completion to
different devices would matter to a generic Linux driver..
.. And there are patches circulating right now for NVMe that enable
exactly this kind of transfer, and rely on these kind of semantics, so
it is a relevant detail :)
Jason
^ permalink raw reply
* Re: [PATCH] Extract initrd free logic from arch-specific code.
From: Marc Zyngier @ 2018-03-29 16:53 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Geert Uytterhoeven, Oliver, Rob Landley, Shea Levy, linux-riscv,
Linux Kernel Mailing List, Christoph Hellwig, Richard Henderson,
Ivan Kokshaysky, Matt Turner, Vineet Gupta, Catalin Marinas,
Will Deacon, Mark Salter, Aurelien Jacquiot, Mikael Starvik,
Jesper Nilsson, Yoshinori Sato, Richard Kuo, Tony Luck,
Fenghua Yu, James Hogan, Michal Simek, Ralf Baechle,
David Howells, Ley Foon Tan, Jonas Bonn, Stefan Kristiansson,
Stafford Horne, James E.J. Bottomley, Helge Deller,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Palmer Dabbelt, Albert Ou, Martin Schwidefsky, Heiko Carstens,
Chen Liqin, Lennox Wu, Rich Felker, David S. Miller, Jeff Dike,
Richard Weinberger, Guan Xuetao, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, the arch/x86 maintainers, Chris Zankel,
Max Filippov, Kate Stewart, Greg Kroah-Hartman,
Philippe Ombredanne, Eugeniy Paltsev, Al Viro, Vladimir Murzin,
Linus Walleij, Michal Hocko, Andrew Morton, Sudip Mukherjee,
Rob Herring, Kees Cook, Vlastimil Babka, Balbir Singh,
Christophe Leroy, Joe Perches, Dan Williams, Wei Yang,
Christian König, Arnd Bergmann, Deepa Dinamani,
Daniel Thompson, Florian Fainelli, alpha, arcml, Linux ARM,
adi-buildroot-devel, linux-c6x-dev, Cris,
moderated list:H8/300 ARCHITECTURE, open list:QUALCOMM HEXAGON...,
linux-ia64, linux-m68k, open list:METAG ARCHITECTURE,
Linux MIPS Mailing List, moderated list:PANASONIC MN10300...,
nios2-dev, Openrisc, Parisc List, linuxppc-dev, linux-s390,
Linux-sh list, sparclinux, uml-devel, uml-user, linux-xtensa,
Nicholas Piggin
In-Reply-To: <20180329155827.GD16141@n2100.armlinux.org.uk>
On Thu, 29 Mar 2018 16:58:27 +0100,
Russell King - ARM Linux wrote:
>
> On Thu, Mar 29, 2018 at 05:43:47PM +0200, Geert Uytterhoeven wrote:
> > On Thu, Mar 29, 2018 at 5:27 PM, Russell King - ARM Linux
> > <linux@armlinux.org.uk> wrote:
> > > On Thu, Mar 29, 2018 at 09:37:52AM +1100, Oliver wrote:
> > >> On Thu, Mar 29, 2018 at 9:14 AM, Russell King - ARM Linux
> > >> <linux@armlinux.org.uk> wrote:
> > >> > On Wed, Mar 28, 2018 at 02:04:22PM -0500, Rob Landley wrote:
> > >> >> On 03/28/2018 11:48 AM, Russell King - ARM Linux wrote:
> > >> >> > On Wed, Mar 28, 2018 at 10:58:51AM -0500, Rob Landley wrote:
> > >> >> >> On 03/28/2018 10:26 AM, Shea Levy wrote:
> > >> >> >>> Now only those architectures that have custom initrd free requirements
> > >> >> >>> need to define free_initrd_mem.
> > >> >> >> ...
> > >> >> >>> --- a/arch/arc/mm/init.c
> > >> >> >>> +++ b/arch/arc/mm/init.c
> > >> >> >>> @@ -229,10 +229,3 @@ void __ref free_initmem(void)
> > >> >> >>> {
> > >> >> >>> free_initmem_default(-1);
> > >> >> >>> }
> > >> >> >>> -
> > >> >> >>> -#ifdef CONFIG_BLK_DEV_INITRD
> > >> >> >>> -void __init free_initrd_mem(unsigned long start, unsigned long end)
> > >> >> >>> -{
> > >> >> >>> - free_reserved_area((void *)start, (void *)end, -1, "initrd");
> > >> >> >>> -}
> > >> >> >>> -#endif
> > >> >> >>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > >> >> >>> index 3f972e83909b..19d1c5594e2d 100644
> > >> >> >>> --- a/arch/arm/Kconfig
> > >> >> >>> +++ b/arch/arm/Kconfig
> > >> >> >>> @@ -47,6 +47,7 @@ config ARM
> > >> >> >>> select HARDIRQS_SW_RESEND
> > >> >> >>> select HAVE_ARCH_AUDITSYSCALL if (AEABI && !OABI_COMPAT)
> > >> >> >>> select HAVE_ARCH_BITREVERSE if (CPU_32v7M || CPU_32v7) && !CPU_32v6
> > >> >> >>> + select HAVE_ARCH_FREE_INITRD_MEM
> > >> >> >>> select HAVE_ARCH_JUMP_LABEL if !XIP_KERNEL && !CPU_ENDIAN_BE32 && MMU
> > >> >> >>> select HAVE_ARCH_KGDB if !CPU_ENDIAN_BE32 && MMU
> > >> >> >>> select HAVE_ARCH_MMAP_RND_BITS if MMU
> > >> >> >>
> > >> >> >> Isn't this why weak symbols were invented?
> > >> >> >
> > >> >> > Weak symbols means that we end up with both the weakly-referenced code
> > >> >> > and the arch code in the kernel image. That's fine if the weak code
> > >> >> > is small.
> > >> >>
> > >> >> The kernel's been able to build with link time garbage collection since 2016:
> > >> >>
> > >> >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b67067f1176d
> > >> >>
> > >> >> Wouldn't that remove the unused one?
> > >> >
> > >> > Probably, if anyone bothered to use that, which they don't.
> > >> >
> > >> > LD_DEAD_CODE_DATA_ELIMINATION is a symbol without a prompt, and from
> > >> > what I can see, nothing selects it. Therefore, the symbol is always
> > >> > disabled, and so the feature never gets used in mainline kernels.
> > >> >
> > >> > Brings up the obvious question - why is it there if it's completely
> > >> > unused? (Maybe to cause confusion, and allowing a justification
> > >> > for __weak ?)
> > >>
> > >> IIRC Nick had some patches to do the arch enablement for powerpc, but
> > >> I'm not sure what happened to them though. I suspect it just fell down
> > >> Nick's ever growing TODO list.
> > >
> > > I've given it a go on ARM, marking every linker-built table with KEEP()
> > > and comparing the System.map files. The resulting kernel is around
> > > 150k smaller, which seems good.
> > >
> > > However, it doesn't boot - and I don't know why. Booting the kernel
> > > under kvmtool in a VM using virtio-console, I can find no way to get
> > > any kernel messages out of it. Using lkvm debug, I can see that the
> > > PC is stuck inside die(), and that's the only information I have.
> > > It dies before bringing up the other CPUs, so it's a very early death.
> > >
> > > I don't think other console types are available under ARM64.
> >
> > earlycon?
>
> Through what - as I say above, I think the only thing that's present is
> virtio-console, and the virtio stack only get initialised much later in
> boot.
>
> Eg, there's the memory-based virtio driver which interfaces any virtio
> driver to a memory-based ring structures for communication with the host
> (drivers/virtio/virtio_mmio.c) which is initialised at module_init()
> time, and so isn't available for earlycon.
>
> I don't think merely changing the module_init() calls in the appropriate
> virtio bits will suffice - it's why I pointed out that it dies before
> SMP initialisation, which also means that it dies before we start
> running the initcalls for subsystems and drivers.
>
> I'm not aware of there being an emulated UART in the guest's address
> space, so serial based stuff doesn't work.
"earlycon=uart,mmio,0x3f8" is what you're looking for:
$ Work/kvmtool/lkvm run -c2 -k zImage -p "earlycon=uart,mmio,0x3f8" --console virtio --aarch32
# lkvm run -k zImage -m 320 -c 2 --name guest-3856
Info: Loaded kernel to 0x80008000 (6767104 bytes)
Info: Placing fdt at 0x8fe00000 - 0x8fffffff
Info: virtio-mmio.devices=0x200@0x10000:36
Info: virtio-mmio.devices=0x200@0x10200:37
Info: virtio-mmio.devices=0x200@0x10400:38
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 4.16.0-rc6+ (maz@approximate) (gcc version 6.3.0 20170516 (Debian 6.3.0-18)) #8407 SMP PREEMPT Tue Mar 20 15:01:43 GMT 2018
[ 0.000000] CPU: ARMv7 Processor [410fd082] revision 2 (ARMv7), cr=30c5383d
[ 0.000000] CPU: div instructions available: patching division code
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
[ 0.000000] OF: fdt: Machine model: linux,dummy-virt
[ 0.000000] earlycon: uart0 at MMIO 0x00000000000003f8 (options '')
[ 0.000000] bootconsole [uart0] enabled
[ 0.000000] Memory policy: Data cache writealloc
[ 0.000000] efi: Getting EFI parameters from FDT:
[ 0.000000] efi: UEFI not found.
[...]
M.
--
Jazz is not dead, it just smell funny.
^ permalink raw reply
* Re: RFC on writel and writel_relaxed
From: Sinan Kaya @ 2018-03-29 16:59 UTC (permalink / raw)
To: Arnd Bergmann
Cc: David Miller, Benjamin Herrenschmidt, Linus Torvalds,
Alexander Duyck, Will Deacon, Jason Gunthorpe, David Laight,
Oliver O'Halloran, linuxppc-dev, linux-rdma, Alexander Duyck,
Paul E. McKenney, Networking, Linus Torvalds
In-Reply-To: <CAK8P3a2qcXmPx-j6XZPGhWZ_K3=cBym8tVFzwcZMSCjVfzMs1g@mail.gmail.com>
On 3/29/2018 12:29 PM, Arnd Bergmann wrote:
> On Thu, Mar 29, 2018 at 3:56 PM, Sinan Kaya <okaya@codeaurora.org> wrote:
>> On 3/28/2018 11:55 AM, David Miller wrote:
>>> From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>>> Date: Thu, 29 Mar 2018 02:13:16 +1100
>>>
>>>> Let's fix all archs, it's way easier than fixing all drivers. Half of
>>>> the archs are unused or dead anyway.
>>>
>>> Agreed.
>>>
>>
>> I pinged most of the maintainers yesterday.
>> Which arches do we care about these days?
>> I have not been paying attention any other architecture besides arm64.
>>
>> arch status detail
>> ------ ------------- ------------------------------------
>> alpha question sent
Thanks for the detailed analysis.
>
> I'm guessing alpha has problems
>
> extern inline u32 readl(const volatile void __iomem *addr)
> {
> u32 ret = __raw_readl(addr);
> mb();
> return ret;
> }
> extern inline void writel(u32 b, volatile void __iomem *addr)
> {
> __raw_writel(b, addr);
> mb();
> }
Looks like a problem to me too. I'll start a thread with the alpha
people and CC you.
>
> There is a barrier in writel /after/ the acess but not before.
>
This is the consolidated list. I also heart back from m68k and corrected
contacts for arc and h8300.
arch status detail
------ ------------- ------------------------------------
alpha question sent Arnd: alpha has problems
arc question sent Vineet.Gupta1@synopsys.com says he'll get to this
in the next few days
arm no issues
arm64 no issues
c6x no issues no PCI
h8300 no issues no PCI: ysato@users.sourceforge.jp will fix it.
hexagon no issues no PCI
ia64 no issues confirmed by Tony Luck
m68k no issues geert@linux-m68k.org says no problem
metag no issues arnd: removed
microblaze question sent arnd: some mips platforms have problems
mips question sent arnd: some mips platforms have problems
nds32 question sent
nios2 no issues no PCI
openrisc no issues shorne@gmail.com says should no issues
parisc no issues grantgrundler@gmail.com says most probably no problem
but still looking
powerpc no issues
riscv no issues arnd: riscv should be fine
s390 no issues arnd: Pretty sure this is also fine
sh question sent
sparc no issues davem@davemloft.net says always strongly ordered
unicore32 question sent resent to gxt@pku.edu.cn
x86 no issues
x86_64 no issues
>
> Arnd
>
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* Re: [PATCH] Extract initrd free logic from arch-specific code.
From: Russell King - ARM Linux @ 2018-03-29 17:31 UTC (permalink / raw)
To: Rob Landley
Cc: Shea Levy, linux-riscv, linux-kernel, Christoph Hellwig,
Richard Henderson, Ivan Kokshaysky, Matt Turner, Vineet Gupta,
Catalin Marinas, Will Deacon, Mark Salter, Aurelien Jacquiot,
Mikael Starvik, Jesper Nilsson, Yoshinori Sato, Richard Kuo,
Tony Luck, Fenghua Yu, Geert Uytterhoeven, James Hogan,
Michal Simek, Ralf Baechle, David Howells, Ley Foon Tan,
Jonas Bonn, Stefan Kristiansson, Stafford Horne,
James E.J. Bottomley, Helge Deller, Benjamin Herrenschmidt,
Paul Mackerras, Michael Ellerman, Palmer Dabbelt, Albert Ou,
Martin Schwidefsky, Heiko Carstens, Chen Liqin, Lennox Wu,
Rich Felker, David S. Miller, Jeff Dike, Richard Weinberger,
Guan Xuetao, Thomas Gleixner, Ingo Molnar, H. Peter Anvin, x86,
Chris Zankel, Max Filippov, Kate Stewart, Greg Kroah-Hartman,
Philippe Ombredanne, Eugeniy Paltsev, Al Viro, Vladimir Murzin,
Linus Walleij, Michal Hocko, Andrew Morton, Sudip Mukherjee,
Marc Zyngier, Rob Herring, Kees Cook, Vlastimil Babka,
Balbir Singh, Christophe Leroy, Joe Perches,
Oliver O'Halloran, Dan Williams, Wei Yang,
Christian König, Arnd Bergmann, Deepa Dinamani,
Daniel Thompson, Florian Fainelli, linux-alpha, linux-snps-arc,
linux-arm-kernel, adi-buildroot-devel, linux-c6x-dev,
linux-cris-kernel, uclinux-h8-devel, linux-hexagon, linux-ia64,
linux-m68k, linux-metag, linux-mips, linux-am33-list, nios2-dev,
openrisc, linux-parisc, linuxppc-dev, linux-s390, linux-sh,
sparclinux, user-mode-linux-devel, user-mode-linux-user,
linux-xtensa
In-Reply-To: <c91e8781-5f31-70e8-e7ef-1a80bd5d9454@landley.net>
On Thu, Mar 29, 2018 at 11:39:24AM -0500, Rob Landley wrote:
>
>
> On 03/28/2018 05:14 PM, Russell King - ARM Linux wrote:
> > On Wed, Mar 28, 2018 at 02:04:22PM -0500, Rob Landley wrote:
> >>
> >>
> >> On 03/28/2018 11:48 AM, Russell King - ARM Linux wrote:
> >>> On Wed, Mar 28, 2018 at 10:58:51AM -0500, Rob Landley wrote:
> >>>> On 03/28/2018 10:26 AM, Shea Levy wrote:
> >>>>> Now only those architectures that have custom initrd free requirements
> >>>>> need to define free_initrd_mem.
> >>>> ...
> >>>>> --- a/arch/arc/mm/init.c
> >>>>> +++ b/arch/arc/mm/init.c
> >>>>> @@ -229,10 +229,3 @@ void __ref free_initmem(void)
> >>>>> {
> >>>>> free_initmem_default(-1);
> >>>>> }
> >>>>> -
> >>>>> -#ifdef CONFIG_BLK_DEV_INITRD
> >>>>> -void __init free_initrd_mem(unsigned long start, unsigned long end)
> >>>>> -{
> >>>>> - free_reserved_area((void *)start, (void *)end, -1, "initrd");
> >>>>> -}
> >>>>> -#endif
> >>>>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> >>>>> index 3f972e83909b..19d1c5594e2d 100644
> >>>>> --- a/arch/arm/Kconfig
> >>>>> +++ b/arch/arm/Kconfig
> >>>>> @@ -47,6 +47,7 @@ config ARM
> >>>>> select HARDIRQS_SW_RESEND
> >>>>> select HAVE_ARCH_AUDITSYSCALL if (AEABI && !OABI_COMPAT)
> >>>>> select HAVE_ARCH_BITREVERSE if (CPU_32v7M || CPU_32v7) && !CPU_32v6
> >>>>> + select HAVE_ARCH_FREE_INITRD_MEM
> >>>>> select HAVE_ARCH_JUMP_LABEL if !XIP_KERNEL && !CPU_ENDIAN_BE32 && MMU
> >>>>> select HAVE_ARCH_KGDB if !CPU_ENDIAN_BE32 && MMU
> >>>>> select HAVE_ARCH_MMAP_RND_BITS if MMU
> >>>>
> >>>> Isn't this why weak symbols were invented?
> >>>
> >>> Weak symbols means that we end up with both the weakly-referenced code
> >>> and the arch code in the kernel image. That's fine if the weak code
> >>> is small.
> >>
> >> The kernel's been able to build with link time garbage collection since 2016:
> >>
> >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b67067f1176d
> >>
> >> Wouldn't that remove the unused one?
> >
> > Probably, if anyone bothered to use that, which they don't.
> >
> > LD_DEAD_CODE_DATA_ELIMINATION is a symbol without a prompt, and from
> > what I can see, nothing selects it. Therefore, the symbol is always
> > disabled, and so the feature never gets used in mainline kernels.
>
> It looks like there are per-architecture linker scripts that need to be updated?
> So if an architecture supports it, it's always done (well, it probes for the
> toolchain supporting the flag). And if the architecture doesn't support it, the
> linker script needs to be updated to mark sections with "I know nothing seems to
> reference this at the ELF level but keep it anyway, we're pulling an assembly
> trick".
It looks like it needs much more than just architecture changes as the
reason it fails on ARM is because the init thread structure is missing
due to missing KEEP()s in INIT_TASK_DATA(). Probably means it doesn't
work anywhere.
8<===
From: Russell King <rmk+kernel@armlinux.org.uk>
Subject: [PATCH] Fix LD_DEAD_CODE_DATA_ELIMINATION
LD_DEAD_CODE_DATA_ELIMINATION fails to boot on ARM because the linker
eliminates the init thread data from the bottom of the init threads
stack. This causes recursive faults that end up overwriting parts
of the kernel before they can print any message.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
include/asm-generic/vmlinux.lds.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index 1ab0e520d6fc..41af8a74aae4 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -279,8 +279,8 @@
VMLINUX_SYMBOL(__start_init_task) = .; \
VMLINUX_SYMBOL(init_thread_union) = .; \
VMLINUX_SYMBOL(init_stack) = .; \
- *(.data..init_task) \
- *(.data..init_thread_info) \
+ KEEP(*(.data..init_task)) \
+ KEEP(*(.data..init_thread_info)) \
. = VMLINUX_SYMBOL(__start_init_task) + THREAD_SIZE; \
VMLINUX_SYMBOL(__end_init_task) = .;
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply related
* Re: [PATCH] Extract initrd free logic from arch-specific code.
From: Russell King - ARM Linux @ 2018-03-29 17:32 UTC (permalink / raw)
To: Marc Zyngier
Cc: Geert Uytterhoeven, Oliver, Rob Landley, Shea Levy, linux-riscv,
Linux Kernel Mailing List, Christoph Hellwig, Richard Henderson,
Ivan Kokshaysky, Matt Turner, Vineet Gupta, Catalin Marinas,
Will Deacon, Mark Salter, Aurelien Jacquiot, Mikael Starvik,
Jesper Nilsson, Yoshinori Sato, Richard Kuo, Tony Luck,
Fenghua Yu, James Hogan, Michal Simek, Ralf Baechle,
David Howells, Ley Foon Tan, Jonas Bonn, Stefan Kristiansson,
Stafford Horne, James E.J. Bottomley, Helge Deller,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Palmer Dabbelt, Albert Ou, Martin Schwidefsky, Heiko Carstens,
Chen Liqin, Lennox Wu, Rich Felker, David S. Miller, Jeff Dike,
Richard Weinberger, Guan Xuetao, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, the arch/x86 maintainers, Chris Zankel,
Max Filippov, Kate Stewart, Greg Kroah-Hartman,
Philippe Ombredanne, Eugeniy Paltsev, Al Viro, Vladimir Murzin,
Linus Walleij, Michal Hocko, Andrew Morton, Sudip Mukherjee,
Rob Herring, Kees Cook, Vlastimil Babka, Balbir Singh,
Christophe Leroy, Joe Perches, Dan Williams, Wei Yang,
Christian König, Arnd Bergmann, Deepa Dinamani,
Daniel Thompson, Florian Fainelli, alpha, arcml, Linux ARM,
adi-buildroot-devel, linux-c6x-dev, Cris,
moderated list:H8/300 ARCHITECTURE, open list:QUALCOMM HEXAGON...,
linux-ia64, linux-m68k, open list:METAG ARCHITECTURE,
Linux MIPS Mailing List, moderated list:PANASONIC MN10300...,
nios2-dev, Openrisc, Parisc List, linuxppc-dev, linux-s390,
Linux-sh list, sparclinux, uml-devel, uml-user, linux-xtensa,
Nicholas Piggin
In-Reply-To: <86zi2qrfgl.wl-marc.zyngier@arm.com>
On Thu, Mar 29, 2018 at 05:53:14PM +0100, Marc Zyngier wrote:
> On Thu, 29 Mar 2018 16:58:27 +0100,
> Russell King - ARM Linux wrote:
> >
> > On Thu, Mar 29, 2018 at 05:43:47PM +0200, Geert Uytterhoeven wrote:
> > > On Thu, Mar 29, 2018 at 5:27 PM, Russell King - ARM Linux
> > > <linux@armlinux.org.uk> wrote:
> > > > On Thu, Mar 29, 2018 at 09:37:52AM +1100, Oliver wrote:
> > > >> On Thu, Mar 29, 2018 at 9:14 AM, Russell King - ARM Linux
> > > >> <linux@armlinux.org.uk> wrote:
> > > >> > On Wed, Mar 28, 2018 at 02:04:22PM -0500, Rob Landley wrote:
> > > >> >> On 03/28/2018 11:48 AM, Russell King - ARM Linux wrote:
> > > >> >> > On Wed, Mar 28, 2018 at 10:58:51AM -0500, Rob Landley wrote:
> > > >> >> >> On 03/28/2018 10:26 AM, Shea Levy wrote:
> > > >> >> >>> Now only those architectures that have custom initrd free requirements
> > > >> >> >>> need to define free_initrd_mem.
> > > >> >> >> ...
> > > >> >> >>> --- a/arch/arc/mm/init.c
> > > >> >> >>> +++ b/arch/arc/mm/init.c
> > > >> >> >>> @@ -229,10 +229,3 @@ void __ref free_initmem(void)
> > > >> >> >>> {
> > > >> >> >>> free_initmem_default(-1);
> > > >> >> >>> }
> > > >> >> >>> -
> > > >> >> >>> -#ifdef CONFIG_BLK_DEV_INITRD
> > > >> >> >>> -void __init free_initrd_mem(unsigned long start, unsigned long end)
> > > >> >> >>> -{
> > > >> >> >>> - free_reserved_area((void *)start, (void *)end, -1, "initrd");
> > > >> >> >>> -}
> > > >> >> >>> -#endif
> > > >> >> >>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > > >> >> >>> index 3f972e83909b..19d1c5594e2d 100644
> > > >> >> >>> --- a/arch/arm/Kconfig
> > > >> >> >>> +++ b/arch/arm/Kconfig
> > > >> >> >>> @@ -47,6 +47,7 @@ config ARM
> > > >> >> >>> select HARDIRQS_SW_RESEND
> > > >> >> >>> select HAVE_ARCH_AUDITSYSCALL if (AEABI && !OABI_COMPAT)
> > > >> >> >>> select HAVE_ARCH_BITREVERSE if (CPU_32v7M || CPU_32v7) && !CPU_32v6
> > > >> >> >>> + select HAVE_ARCH_FREE_INITRD_MEM
> > > >> >> >>> select HAVE_ARCH_JUMP_LABEL if !XIP_KERNEL && !CPU_ENDIAN_BE32 && MMU
> > > >> >> >>> select HAVE_ARCH_KGDB if !CPU_ENDIAN_BE32 && MMU
> > > >> >> >>> select HAVE_ARCH_MMAP_RND_BITS if MMU
> > > >> >> >>
> > > >> >> >> Isn't this why weak symbols were invented?
> > > >> >> >
> > > >> >> > Weak symbols means that we end up with both the weakly-referenced code
> > > >> >> > and the arch code in the kernel image. That's fine if the weak code
> > > >> >> > is small.
> > > >> >>
> > > >> >> The kernel's been able to build with link time garbage collection since 2016:
> > > >> >>
> > > >> >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b67067f1176d
> > > >> >>
> > > >> >> Wouldn't that remove the unused one?
> > > >> >
> > > >> > Probably, if anyone bothered to use that, which they don't.
> > > >> >
> > > >> > LD_DEAD_CODE_DATA_ELIMINATION is a symbol without a prompt, and from
> > > >> > what I can see, nothing selects it. Therefore, the symbol is always
> > > >> > disabled, and so the feature never gets used in mainline kernels.
> > > >> >
> > > >> > Brings up the obvious question - why is it there if it's completely
> > > >> > unused? (Maybe to cause confusion, and allowing a justification
> > > >> > for __weak ?)
> > > >>
> > > >> IIRC Nick had some patches to do the arch enablement for powerpc, but
> > > >> I'm not sure what happened to them though. I suspect it just fell down
> > > >> Nick's ever growing TODO list.
> > > >
> > > > I've given it a go on ARM, marking every linker-built table with KEEP()
> > > > and comparing the System.map files. The resulting kernel is around
> > > > 150k smaller, which seems good.
> > > >
> > > > However, it doesn't boot - and I don't know why. Booting the kernel
> > > > under kvmtool in a VM using virtio-console, I can find no way to get
> > > > any kernel messages out of it. Using lkvm debug, I can see that the
> > > > PC is stuck inside die(), and that's the only information I have.
> > > > It dies before bringing up the other CPUs, so it's a very early death.
> > > >
> > > > I don't think other console types are available under ARM64.
> > >
> > > earlycon?
> >
> > Through what - as I say above, I think the only thing that's present is
> > virtio-console, and the virtio stack only get initialised much later in
> > boot.
> >
> > Eg, there's the memory-based virtio driver which interfaces any virtio
> > driver to a memory-based ring structures for communication with the host
> > (drivers/virtio/virtio_mmio.c) which is initialised at module_init()
> > time, and so isn't available for earlycon.
> >
> > I don't think merely changing the module_init() calls in the appropriate
> > virtio bits will suffice - it's why I pointed out that it dies before
> > SMP initialisation, which also means that it dies before we start
> > running the initcalls for subsystems and drivers.
> >
> > I'm not aware of there being an emulated UART in the guest's address
> > space, so serial based stuff doesn't work.
>
> "earlycon=uart,mmio,0x3f8" is what you're looking for:
Does that also mean that we have a RTC at the standard PC IO addresses
as well, but in mmio space?
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* Re: [PATCH] Extract initrd free logic from arch-specific code.
From: Rob Landley @ 2018-03-29 17:43 UTC (permalink / raw)
To: Russell King - ARM Linux, Oliver
Cc: Shea Levy, linux-riscv, linux-kernel, Christoph Hellwig,
Richard Henderson, Ivan Kokshaysky, Matt Turner, Vineet Gupta,
Catalin Marinas, Will Deacon, Mark Salter, Aurelien Jacquiot,
Mikael Starvik, Jesper Nilsson, Yoshinori Sato, Richard Kuo,
Tony Luck, Fenghua Yu, Geert Uytterhoeven, James Hogan,
Michal Simek, Ralf Baechle, David Howells, Ley Foon Tan,
Jonas Bonn, Stefan Kristiansson, Stafford Horne,
James E.J. Bottomley, Helge Deller, Benjamin Herrenschmidt,
Paul Mackerras, Michael Ellerman, Palmer Dabbelt, Albert Ou,
Martin Schwidefsky, Heiko Carstens, Chen Liqin, Lennox Wu,
Rich Felker, David S. Miller, Jeff Dike, Richard Weinberger,
Guan Xuetao, Thomas Gleixner, Ingo Molnar, H. Peter Anvin, x86,
Chris Zankel, Max Filippov, Kate Stewart, Greg Kroah-Hartman,
Philippe Ombredanne, Eugeniy Paltsev, Al Viro, Vladimir Murzin,
Linus Walleij, Michal Hocko, Andrew Morton, Sudip Mukherjee,
Marc Zyngier, Rob Herring, Kees Cook, Vlastimil Babka,
Balbir Singh, Christophe Leroy, Joe Perches, Dan Williams,
Wei Yang, Christian König, Arnd Bergmann, Deepa Dinamani,
Daniel Thompson, Florian Fainelli, linux-alpha, linux-snps-arc,
linux-arm-kernel, adi-buildroot-devel, linux-c6x-dev,
linux-cris-kernel, uclinux-h8-devel, linux-hexagon, linux-ia64,
linux-m68k, linux-metag, linux-mips, linux-am33-list, nios2-dev,
openrisc, linux-parisc, linuxppc-dev, linux-s390, linux-sh,
sparclinux, user-mode-linux-devel, user-mode-linux-user,
linux-xtensa, Nicholas Piggin
In-Reply-To: <20180329152749.GC16141@n2100.armlinux.org.uk>
[-- Attachment #1: Type: text/plain, Size: 3072 bytes --]
On 03/29/2018 10:27 AM, Russell King - ARM Linux wrote:
> On Thu, Mar 29, 2018 at 09:37:52AM +1100, Oliver wrote:
>> On Thu, Mar 29, 2018 at 9:14 AM, Russell King - ARM Linux
>>> LD_DEAD_CODE_DATA_ELIMINATION is a symbol without a prompt, and from
>>> what I can see, nothing selects it. Therefore, the symbol is always
>>> disabled, and so the feature never gets used in mainline kernels.
>>>
>>> Brings up the obvious question - why is it there if it's completely
>>> unused? (Maybe to cause confusion, and allowing a justification
>>> for __weak ?)
>>
>> IIRC Nick had some patches to do the arch enablement for powerpc, but
>> I'm not sure what happened to them though. I suspect it just fell down
>> Nick's ever growing TODO list.
>
> I've given it a go on ARM, marking every linker-built table with KEEP()
> and comparing the System.map files. The resulting kernel is around
> 150k smaller, which seems good.
>
> However, it doesn't boot - and I don't know why. Booting the kernel
> under kvmtool in a VM using virtio-console, I can find no way to get
> any kernel messages out of it. Using lkvm debug, I can see that the
> PC is stuck inside die(), and that's the only information I have.
qemu-system-arm's "-s" option lets you hook to the hardware with gdb, as if
using one of those jtags that speaks gdbserver protocol. It stops waiting for
you to attach with 'target remote' it, then 'file vmlinux' to load the symbols...
The miniconfig and qemu invocation I use for arm64 are attached, tested with
2.11.0 on a 4.14 kernel. You should be able to just "qemu-aarch64.sh -s" and
then probably "target remote 127.0.0.1:1234"? (Been a while since I've used it,
don't have a cross-gdb for arm64 lying around...)
Sigh, I just tried -s and qemu 2.11.0 is _not_ waiting for gdb to attach on
arm64, despite what the docs say:
$ qemu-system-aarch64 --help | grep gdb
-gdb dev wait for gdb connection on 'dev'
-s shorthand for -gdb tcp::1234
Another random regression in qemu, gee what a surprise.
> It dies before bringing up the other CPUs, so it's a very early death.
>
> I don't think other console types are available under ARM64.
I've often found useful the two line version of:
https://balau82.wordpress.com/2010/02/28/hello-world-for-bare-metal-arm-using-qemu/
Which is generally some variant of:
{char *XX = "blah"; while (*XX) {while (*SERIAL_STATUS_REGISTER & OUT_READY);
*SERIAL_OUT = *XX++;}}
(I.E. balu cheated not spinning checking the ready-for-next-byte bit, because
qemu's always angry.)
That trick lets you cut and paste a print statement into all sorts of early
hardware nonsense, on most architectures. You just have to look up
SERIAL_STATUS_REGISTER, OUT_OK_BIT, and SERIAL_OUT values for the serial port du
jour.
That said I've mostly used it in things like u-boot. I dunno at what point the
kernel's done enough setup that direct banging on registers would stop working.
(Works in the decompresion code, anyway.) And it assumes the port's set to the
right speed (usually left there by the bootloader)...
Rob
[-- Attachment #2: aarch64.miniconf --]
[-- Type: text/plain, Size: 1387 bytes --]
# make ARCH=arm64 allnoconfig KCONFIG_ALLCONFIG=aarch64.miniconf
# make ARCH=arm64 -j $(nproc)
# boot arch/arm64/boot/Image
CONFIG_MMU=y
CONFIG_ARCH_MULTI_V7=y
CONFIG_ARCH_VIRT=y
CONFIG_SOC_DRA7XX=y
CONFIG_ARCH_OMAP2PLUS_TYPICAL=y
CONFIG_ARCH_ALPINE=y
CONFIG_ARM_THUMB=y
CONFIG_VDSO=y
CONFIG_CPU_IDLE=y
CONFIG_ARM_CPUIDLE=y
CONFIG_KERNEL_MODE_NEON=y
CONFIG_SERIAL_AMBA_PL011=y
CONFIG_SERIAL_AMBA_PL011_CONSOLE=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_DRV_PL031=y
CONFIG_NET_CORE=y
CONFIG_VIRTIO_NET=y
CONFIG_PCI=y
CONFIG_PCI_HOST_GENERIC=y
CONFIG_VIRTIO_BLK=y
CONFIG_VIRTIO_PCI=y
CONFIG_VIRTIO_MMIO=y
CONFIG_ATA=y
CONFIG_ATA_SFF=y
CONFIG_ATA_BMDMA=y
CONFIG_ATA_PIIX=y
CONFIG_PATA_PLATFORM=y
CONFIG_PATA_OF_PLATFORM=y
CONFIG_ATA_GENERIC=y
# CONFIG_EMBEDDED is not set
CONFIG_EARLY_PRINTK=y
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_SCRIPT=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_BLK_DEV=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_RD_GZIP=y
CONFIG_BLK_DEV_LOOP=y
CONFIG_EXT4_FS=y
CONFIG_EXT4_USE_FOR_EXT2=y
CONFIG_VFAT_FS=y
CONFIG_FAT_DEFAULT_UTF8=y
CONFIG_MISC_FILESYSTEMS=y
CONFIG_SQUASHFS=y
CONFIG_SQUASHFS_XATTR=y
CONFIG_SQUASHFS_ZLIB=y
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
CONFIG_TMPFS=y
CONFIG_TMPFS_POSIX_ACL=y
CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_IPV6=y
CONFIG_NETDEVICES=y
#CONFIG_NET_CORE=y
#CONFIG_NETCONSOLE=y
CONFIG_ETHERNET=y
[-- Attachment #3: qemu-aarch64.sh --]
[-- Type: application/x-shellscript, Size: 186 bytes --]
^ permalink raw reply
* Re: [PATCH] Extract initrd free logic from arch-specific code.
From: Marc Zyngier @ 2018-03-29 17:53 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Geert Uytterhoeven, Oliver, Rob Landley, Shea Levy, linux-riscv,
Linux Kernel Mailing List, Christoph Hellwig, Richard Henderson,
Ivan Kokshaysky, Matt Turner, Vineet Gupta, Catalin Marinas,
Will Deacon, Mark Salter, Aurelien Jacquiot, Mikael Starvik,
Jesper Nilsson, Yoshinori Sato, Richard Kuo, Tony Luck,
Fenghua Yu, James Hogan, Michal Simek, Ralf Baechle,
David Howells, Ley Foon Tan, Jonas Bonn, Stefan Kristiansson,
Stafford Horne, James E.J. Bottomley, Helge Deller,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Palmer Dabbelt, Albert Ou, Martin Schwidefsky, Heiko Carstens,
Chen Liqin, Lennox Wu, Rich Felker, David S. Miller, Jeff Dike,
Richard Weinberger, Guan Xuetao, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, the arch/x86 maintainers, Chris Zankel,
Max Filippov, Kate Stewart, Greg Kroah-Hartman,
Philippe Ombredanne, Eugeniy Paltsev, Al Viro, Vladimir Murzin,
Linus Walleij, Michal Hocko, Andrew Morton, Sudip Mukherjee,
Rob Herring, Kees Cook, Vlastimil Babka, Balbir Singh,
Christophe Leroy, Joe Perches, Dan Williams, Wei Yang,
Christian König, Arnd Bergmann, Deepa Dinamani,
Daniel Thompson, Florian Fainelli, alpha, arcml, Linux ARM,
adi-buildroot-devel, linux-c6x-dev, Cris,
moderated list:H8/300 ARCHITECTURE, open list:QUALCOMM HEXAGON...,
linux-ia64, linux-m68k, open list:METAG ARCHITECTURE,
Linux MIPS Mailing List, moderated list:PANASONIC MN10300...,
nios2-dev, Openrisc, Parisc List, linuxppc-dev, linux-s390,
Linux-sh list, sparclinux, uml-devel, uml-user, linux-xtensa,
Nicholas Piggin
In-Reply-To: <20180329173247.GF16141@n2100.armlinux.org.uk>
On Thu, 29 Mar 2018 18:32:47 +0100,
Russell King - ARM Linux wrote:
>
> On Thu, Mar 29, 2018 at 05:53:14PM +0100, Marc Zyngier wrote:
> > On Thu, 29 Mar 2018 16:58:27 +0100,
> > Russell King - ARM Linux wrote:
[...]
> > > I'm not aware of there being an emulated UART in the guest's address
> > > space, so serial based stuff doesn't work.
> >
> > "earlycon=uart,mmio,0x3f8" is what you're looking for:
>
> Does that also mean that we have a RTC at the standard PC IO addresses
> as well, but in mmio space?
There is one, together with an i8042. Not exposed in the DT though.
M.
--
Jazz is not dead, it just smell funny.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox