Re: linux-next: build warnings in Linus' tree
On Thu, 14 Oct 2021 10:44:46 +0200 Arnd Bergmann a...@arndb.de wrote: >On Thu, Oct 14, 2021 at 12:12 AM Anatolij Gustschin wrote: >> On Tue, 12 Oct 2021 16:39:56 +0200 >> Arnd Bergmann a...@arndb.de wrote: >> ... >> >Grant Likely was the original maintainer for MPC52xx until 2011, >> >Anatolij Gustschin is still listed as maintainer since then but hasn't >> >been active in it for a while either. Anatolij can probably best judge >> >which of these boards are still in going to be used with future kernels, >> >but I suspect once you start removing bits from 52xx, the newer >> >but less common 512x platform can go away as well. >> >> many of these boards are still used, i.e. o2d*, digsy_mtc, tqm5200. > >Just for clarification, I assume when you say "still used" that implies >getting updated to new kernels rather than just running the old BSPs, >right? yes, at least some of them. I used v5.4 kernel on digsy_mtc and tqm5200 last year, and v5.10 kernel is also known to work. >What are the typical distro release cycles for those machines >you list: do you move from one LTS kernel to the next each year, >or are they getting more sporadic over time? these machines are in embedded systems and do not get regular distro updates, therefore more sporadic over time. >Do you expect the machines with the lowest memory such as the >32MB digsy to stop getting kernel updates before the others? No. There are also digsy variants with 256MiB DRAM. Thanks, Anatolij
Re: linux-next: build warnings in Linus' tree
On Thu, Oct 14, 2021 at 12:12 AM Anatolij Gustschin wrote: > On Tue, 12 Oct 2021 16:39:56 +0200 > Arnd Bergmann a...@arndb.de wrote: > ... > >Grant Likely was the original maintainer for MPC52xx until 2011, > >Anatolij Gustschin is still listed as maintainer since then but hasn't > >been active in it for a while either. Anatolij can probably best judge > >which of these boards are still in going to be used with future kernels, > >but I suspect once you start removing bits from 52xx, the newer > >but less common 512x platform can go away as well. > > many of these boards are still used, i.e. o2d*, digsy_mtc, tqm5200. Just for clarification, I assume when you say "still used" that implies getting updated to new kernels rather than just running the old BSPs, right? What are the typical distro release cycles for those machines you list: do you move from one LTS kernel to the next each year, or are they getting more sporadic over time? Do you expect the machines with the lowest memory such as the 32MB digsy to stop getting kernel updates before the others? > I've sent first series to fix some warnings. Other dts fixes > require driver changes, so it will take some time to fix them. Thanks! Arnd
Re: linux-next: build warnings in Linus' tree
On Wed, Oct 13, 2021 at 5:28 PM Anatolij Gustschin wrote: > > On Wed, 13 Oct 2021 17:17:25 -0500 > Rob Herring robh...@kernel.org wrote: > ... > >In general, you shouldn't need to be changing the drivers. Can you > >tell me which warnings need driver changes? > > ethernet and mdio drivers share registers, so they use same unit-address: > > arch/powerpc/boot/dts/tqm5200.dts:127.17-133.5: Warning > (unique_unit_address): /soc5200@f000/ethernet@3000: duplicate > unit-address (also used in node /soc5200@f000/mdio@3000) > > arch/powerpc/boot/dts/mpc5200b.dtsi:218.23-223.5: Warning > (unique_unit_address): /soc5200@f000/ethernet@3000: duplicate > unit-address (also used in node /soc5200@f000/mdio@3000) > also defined at arch/powerpc/boot/dts/digsy_mtc.dts:60.17-62.5 Those are W=1 warnings and off by default. You shouldn't fix them if it breaks compatibility with the driver. Rob
Re: linux-next: build warnings in Linus' tree
On Wed, 13 Oct 2021 17:17:25 -0500 Rob Herring robh...@kernel.org wrote: ... >In general, you shouldn't need to be changing the drivers. Can you >tell me which warnings need driver changes? ethernet and mdio drivers share registers, so they use same unit-address: arch/powerpc/boot/dts/tqm5200.dts:127.17-133.5: Warning (unique_unit_address): /soc5200@f000/ethernet@3000: duplicate unit-address (also used in node /soc5200@f000/mdio@3000) arch/powerpc/boot/dts/mpc5200b.dtsi:218.23-223.5: Warning (unique_unit_address): /soc5200@f000/ethernet@3000: duplicate unit-address (also used in node /soc5200@f000/mdio@3000) also defined at arch/powerpc/boot/dts/digsy_mtc.dts:60.17-62.5 Anatolij
Re: linux-next: build warnings in Linus' tree
On Wed, Oct 13, 2021 at 5:12 PM Anatolij Gustschin wrote: > > Hi Arnd, Rob, > > On Tue, 12 Oct 2021 16:39:56 +0200 > Arnd Bergmann a...@arndb.de wrote: > ... > >Grant Likely was the original maintainer for MPC52xx until 2011, > >Anatolij Gustschin is still listed as maintainer since then but hasn't > >been active in it for a while either. Anatolij can probably best judge > >which of these boards are still in going to be used with future kernels, > >but I suspect once you start removing bits from 52xx, the newer > >but less common 512x platform can go away as well. > > many of these boards are still used, i.e. o2d*, digsy_mtc, tqm5200. > I've sent first series to fix some warnings. Other dts fixes > require driver changes, so it will take some time to fix them. In general, you shouldn't need to be changing the drivers. Can you tell me which warnings need driver changes? Rob
Re: linux-next: build warnings in Linus' tree
Hi Arnd, Rob, On Tue, 12 Oct 2021 16:39:56 +0200 Arnd Bergmann a...@arndb.de wrote: ... >Grant Likely was the original maintainer for MPC52xx until 2011, >Anatolij Gustschin is still listed as maintainer since then but hasn't >been active in it for a while either. Anatolij can probably best judge >which of these boards are still in going to be used with future kernels, >but I suspect once you start removing bits from 52xx, the newer >but less common 512x platform can go away as well. many of these boards are still used, i.e. o2d*, digsy_mtc, tqm5200. I've sent first series to fix some warnings. Other dts fixes require driver changes, so it will take some time to fix them. Anatolij
Re: linux-next: build warnings in Linus' tree
On Mon, Oct 11, 2021 at 10:42 PM Rob Herring wrote: > On Sun, Oct 10, 2021 at 4:27 PM Stephen Rothwell > wrote: > FYI, u-boot removed mpc5xxx support in 2017, so maybe there's > similarly not a need to keep them in the kernel? It does appear NXP > will still sell you the parts though the last BSP was 2009. Specifically, MPC5200B has a 15 year lifetime, which ends in 11 months from now. The original bplan/Genesi Efika 5K2 was quite popular at the time it came out, and there are probably still some of those hanging around, but they came with Open Firmware rather than relying on the dts files that ship with the kernel. Grant Likely was the original maintainer for MPC52xx until 2011, Anatolij Gustschin is still listed as maintainer since then but hasn't been active in it for a while either. Anatolij can probably best judge which of these boards are still in going to be used with future kernels, but I suspect once you start removing bits from 52xx, the newer but less common 512x platform can go away as well. Arnd
Re: linux-next: build warnings in Linus' tree
+Arnd in regards to removing platforms. On Sun, Oct 10, 2021 at 4:27 PM Stephen Rothwell wrote: > > Hi all, > > [Cc'ing Rob] > > Rob: these warnings have been there for a long time ... If anyone cares about these platforms, then the warnings should be fixed by folks that care. If not, then perhaps the DT files should just get removed. FYI, u-boot removed mpc5xxx support in 2017, so maybe there's similarly not a need to keep them in the kernel? It does appear NXP will still sell you the parts though the last BSP was 2009. Rob
Re: linux-next: build warnings in Linus' tree
Hi all, [Cc'ing Rob] Rob: these warnings have been there for a long time ... On Fri, 8 Oct 2021 16:47:28 +1100 Stephen Rothwell wrote: > > Hi all, > > After merging the origin tree, today's linux-next build (powerpc > allyesconfig) produced these warnings (along with many others): > > arch/powerpc/boot/dts/mpc5200b.dtsi:267.20-280.4: Warning (pci_bridge): > /pci@fd00: missing ranges for PCI bridge (or not a bridge) > arch/powerpc/boot/dts/mpc5200b.dtsi:267.20-280.4: Warning (pci_bridge): > /pci@fd00: missing ranges for PCI bridge (or not a bridge) > arch/powerpc/boot/dts/mpc5200b.dtsi:267.20-280.4: Warning (pci_bridge): > /pci@fd00: missing ranges for PCI bridge (or not a bridge) > arch/powerpc/boot/dts/mpc5200b.dtsi:267.20-280.4: Warning (pci_bridge): > /pci@fd00: missing ranges for PCI bridge (or not a bridge) > arch/powerpc/boot/dts/mpc5200b.dtsi:182.18-186.5: Warning (spi_bus_bridge): > /soc5200@f000/psc@2000: node name for SPI buses should be 'spi' > arch/powerpc/boot/dts/mpc5200b.dtsi:267.20-280.4: Warning (pci_bridge): > /pci@fd00: missing ranges for PCI bridge (or not a bridge) > arch/powerpc/boot/dts/mpc5200b.dtsi:182.18-186.5: Warning (spi_bus_bridge): > /soc5200@f000/psc@2000: node name for SPI buses should be 'spi' > arch/powerpc/boot/dts/mpc5200b.dtsi:267.20-280.4: Warning (pci_bridge): > /pci@fd00: missing ranges for PCI bridge (or not a bridge) > arch/powerpc/boot/dts/mpc5200b.dtsi:182.18-186.5: Warning (spi_bus_bridge): > /soc5200@f000/psc@2000: node name for SPI buses should be 'spi' > arch/powerpc/boot/dts/mpc5200b.dtsi:267.20-280.4: Warning (pci_bridge): > /pci@fd00: missing ranges for PCI bridge (or not a bridge) > arch/powerpc/boot/dts/mpc5200b.dtsi:182.18-186.5: Warning (spi_bus_bridge): > /soc5200@f000/psc@2000: node name for SPI buses should be 'spi' > arch/powerpc/boot/dts/mpc5200b.dtsi:267.20-280.4: Warning (pci_bridge): > /pci@fd00: missing ranges for PCI bridge (or not a bridge) > arch/powerpc/boot/dts/mpc5200b.dtsi:182.18-186.5: Warning (spi_bus_bridge): > /soc5200@f000/psc@2000: node name for SPI buses should be 'spi' > arch/powerpc/boot/dts/mpc5200b.dtsi:267.20-280.4: Warning (pci_bridge): > /pci@fd00: missing ranges for PCI bridge (or not a bridge) > arch/powerpc/boot/dts/mpc5200b.dtsi:182.18-186.5: Warning (spi_bus_bridge): > /soc5200@f000/psc@2000: node name for SPI buses should be 'spi' > arch/powerpc/boot/dts/mpc5200b.dtsi:267.20-280.4: Warning (pci_bridge): > /pci@fd00: missing ranges for PCI bridge (or not a bridge) > > Given that arch/powerpc/boot/dts/mpc5200b.dtsi is oncluded by several > other dts files, fixing this one file would go quite a long way to > silencing our allyesoncig build. Unfotunatley, I have no idea how to > fix this file (ad maybe some fo the interactions it has with other files). -- Cheers, Stephen Rothwell pgpn0gFLQCRw8.pgp Description: OpenPGP digital signature
Re: linux-next: build warnings from Linus' tree
On Sun, 18 Nov 2018 at 21:52, Alan Modra wrote:
>
> On Wed, Nov 14, 2018 at 09:20:23PM +1100, Michael Ellerman wrote:
> > Joel Stanley writes:
> > > Hello Alan,
> > >
> > > On Tue, 12 Jun 2018 at 07:44, Stephen Rothwell
> > > wrote:
> > >
> > >> Building Linus' tree, today's linux-next build (powerpc ppc64_defconfig)
> > >> produced these warning:
> > >>
> > >> ld: warning: orphan section `.gnu.hash' from `linker stubs' being placed
> > >> in section `.gnu.hash'.
> > >> ld: warning: orphan section `.gnu.hash' from `linker stubs' being placed
> > >> in section `.gnu.hash'.
> > >> ld: warning: orphan section `.gnu.hash' from `linker stubs' being placed
> > >> in section `.gnu.hash'.
> > >>
> > >> This may just be because I have started building using the native Debian
> > >> gcc for the powerpc builds ...
> > >
> > > Do you know why we started creating these?
> >
> > It's controlled by the ld option --hash-style, which AFAICS still
> > defaults to sysv (generating .hash).
> >
> > But it seems gcc can be configured to have a different default, and at
> > least my native ppc64le toolchains are passing gnu, eg:
> >
> > /usr/lib/gcc/powerpc64le-linux-gnu/6/collect2 -plugin
> > /usr/lib/gcc/powerpc64le-linux-gnu/6/liblto_plugin.so
> > -plugin-opt=/usr/lib/gcc/powerpc64le-linux-gnu/6/lto-wrapper
> > -plugin-opt=-fresolution=/tmp/ccw1U2fF.res
> > -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s
> > -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc
> > -plugin-opt=-pass-through=-lgcc_s --sysroot=/ --build-id --eh-frame-hdr
> > -V -shared -m elf64lppc
> > --hash-style=gnu
> >
> >
> > So that's presumably why we're seeing it, some GCCs are configured to
> > use it.
> >
> > > If it's intentional, should we be putting including them in the same
> > > way as .hash sections?
> > >
> > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/kernel/vmlinux.lds.S#n282
> > >
> > > .hash : AT(ADDR(.hash) - LOAD_OFFSET) { *(.hash) }
> >
> > That would presumably work.
> >
> > My question though is do we even need it?
> >
> > >From what I can see for it to be useful you need the section as well as
> > an entry in the dynamic section pointing at it, and we don't have a
> > dynamic section at all:
> >
> > $ readelf -S vmlinux | grep gnu.hash
> > [ 4] .gnu.hash GNU_HASH c0dbbdb0 00dcbdb0
> > $ readelf -d vmlinux
> >
> > There is no dynamic section in this file.
> >
> > Compare to the vdso:
> >
> > $ readelf -d arch/powerpc/kernel/vdso64/vdso64.so
> >
> > Dynamic section at offset 0x868 contains 12 entries:
> > TagType Name/Value
> > 0x000e (SONAME) Library soname: [linux-vdso64.so.1]
> > 0x0004 (HASH) 0x120
> > 0x6ef5 (GNU_HASH) 0x170
> > 0x0005 (STRTAB) 0x320
> > 0x0006 (SYMTAB) 0x1d0
> > 0x000a (STRSZ) 269 (bytes)
> > 0x000b (SYMENT) 24 (bytes)
> > 0x7003 (PPC64_OPT) 0x0
> > 0x6ffc (VERDEF) 0x450
> > 0x6ffd (VERDEFNUM) 2
> > 0x6ff0 (VERSYM) 0x42e
> > 0x (NULL) 0x0
> >
> >
> > So can't we just discard .gnu.hash? And in fact do we need .hash either?
> >
> > Actually arm64 discards the latter, and parisc discards both.
> >
> > Would still be good to hear from Alan or someone else who knows anything
> > about toolchain stuff, ie. not me :)
>
> .gnu.hash, like .hash, is used by glibc ld.so for dynamic symbol
> lookup. I imagine you don't need either section in a kernel, so
> discarding both sounds reasonable. Likely you could discard .interp
> and .dynstr too, and .dynsym when !CONFIG_PPC32.
Thanks for the digging Michael, and thanks Alan for clarifying the
details. I'll cook up a patch or two.
Cheers,
Joel
Re: linux-next: build warnings from Linus' tree
On Wed, Nov 14, 2018 at 09:20:23PM +1100, Michael Ellerman wrote:
> Joel Stanley writes:
> > Hello Alan,
> >
> > On Tue, 12 Jun 2018 at 07:44, Stephen Rothwell
> > wrote:
> >
> >> Building Linus' tree, today's linux-next build (powerpc ppc64_defconfig)
> >> produced these warning:
> >>
> >> ld: warning: orphan section `.gnu.hash' from `linker stubs' being placed
> >> in section `.gnu.hash'.
> >> ld: warning: orphan section `.gnu.hash' from `linker stubs' being placed
> >> in section `.gnu.hash'.
> >> ld: warning: orphan section `.gnu.hash' from `linker stubs' being placed
> >> in section `.gnu.hash'.
> >>
> >> This may just be because I have started building using the native Debian
> >> gcc for the powerpc builds ...
> >
> > Do you know why we started creating these?
>
> It's controlled by the ld option --hash-style, which AFAICS still
> defaults to sysv (generating .hash).
>
> But it seems gcc can be configured to have a different default, and at
> least my native ppc64le toolchains are passing gnu, eg:
>
> /usr/lib/gcc/powerpc64le-linux-gnu/6/collect2 -plugin
> /usr/lib/gcc/powerpc64le-linux-gnu/6/liblto_plugin.so
> -plugin-opt=/usr/lib/gcc/powerpc64le-linux-gnu/6/lto-wrapper
> -plugin-opt=-fresolution=/tmp/ccw1U2fF.res
> -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s
> -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc
> -plugin-opt=-pass-through=-lgcc_s --sysroot=/ --build-id --eh-frame-hdr
> -V -shared -m elf64lppc
> --hash-style=gnu
>
>
> So that's presumably why we're seeing it, some GCCs are configured to
> use it.
>
> > If it's intentional, should we be putting including them in the same
> > way as .hash sections?
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/kernel/vmlinux.lds.S#n282
> >
> > .hash : AT(ADDR(.hash) - LOAD_OFFSET) { *(.hash) }
>
> That would presumably work.
>
> My question though is do we even need it?
>
> >From what I can see for it to be useful you need the section as well as
> an entry in the dynamic section pointing at it, and we don't have a
> dynamic section at all:
>
> $ readelf -S vmlinux | grep gnu.hash
> [ 4] .gnu.hash GNU_HASH c0dbbdb0 00dcbdb0
> $ readelf -d vmlinux
>
> There is no dynamic section in this file.
>
> Compare to the vdso:
>
> $ readelf -d arch/powerpc/kernel/vdso64/vdso64.so
>
> Dynamic section at offset 0x868 contains 12 entries:
> TagType Name/Value
> 0x000e (SONAME) Library soname: [linux-vdso64.so.1]
> 0x0004 (HASH) 0x120
> 0x6ef5 (GNU_HASH) 0x170
> 0x0005 (STRTAB) 0x320
> 0x0006 (SYMTAB) 0x1d0
> 0x000a (STRSZ) 269 (bytes)
> 0x000b (SYMENT) 24 (bytes)
> 0x7003 (PPC64_OPT) 0x0
> 0x6ffc (VERDEF) 0x450
> 0x6ffd (VERDEFNUM) 2
> 0x6ff0 (VERSYM) 0x42e
> 0x (NULL) 0x0
>
>
> So can't we just discard .gnu.hash? And in fact do we need .hash either?
>
> Actually arm64 discards the latter, and parisc discards both.
>
> Would still be good to hear from Alan or someone else who knows anything
> about toolchain stuff, ie. not me :)
.gnu.hash, like .hash, is used by glibc ld.so for dynamic symbol
lookup. I imagine you don't need either section in a kernel, so
discarding both sounds reasonable. Likely you could discard .interp
and .dynstr too, and .dynsym when !CONFIG_PPC32.
--
Alan Modra
Australia Development Lab, IBM
Re: linux-next: build warnings from Linus' tree
Joel Stanley writes:
> Hello Alan,
>
> On Tue, 12 Jun 2018 at 07:44, Stephen Rothwell wrote:
>
>> Building Linus' tree, today's linux-next build (powerpc ppc64_defconfig)
>> produced these warning:
>>
>> ld: warning: orphan section `.gnu.hash' from `linker stubs' being placed in
>> section `.gnu.hash'.
>> ld: warning: orphan section `.gnu.hash' from `linker stubs' being placed in
>> section `.gnu.hash'.
>> ld: warning: orphan section `.gnu.hash' from `linker stubs' being placed in
>> section `.gnu.hash'.
>>
>> This may just be because I have started building using the native Debian
>> gcc for the powerpc builds ...
>
> Do you know why we started creating these?
It's controlled by the ld option --hash-style, which AFAICS still
defaults to sysv (generating .hash).
But it seems gcc can be configured to have a different default, and at
least my native ppc64le toolchains are passing gnu, eg:
/usr/lib/gcc/powerpc64le-linux-gnu/6/collect2 -plugin
/usr/lib/gcc/powerpc64le-linux-gnu/6/liblto_plugin.so
-plugin-opt=/usr/lib/gcc/powerpc64le-linux-gnu/6/lto-wrapper
-plugin-opt=-fresolution=/tmp/ccw1U2fF.res
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s
-plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcc_s --sysroot=/ --build-id --eh-frame-hdr
-V -shared -m elf64lppc
--hash-style=gnu
So that's presumably why we're seeing it, some GCCs are configured to
use it.
> If it's intentional, should we be putting including them in the same
> way as .hash sections?
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/kernel/vmlinux.lds.S#n282
>
> .hash : AT(ADDR(.hash) - LOAD_OFFSET) { *(.hash) }
That would presumably work.
My question though is do we even need it?
>From what I can see for it to be useful you need the section as well as
an entry in the dynamic section pointing at it, and we don't have a
dynamic section at all:
$ readelf -S vmlinux | grep gnu.hash
[ 4] .gnu.hash GNU_HASH c0dbbdb0 00dcbdb0
$ readelf -d vmlinux
There is no dynamic section in this file.
Compare to the vdso:
$ readelf -d arch/powerpc/kernel/vdso64/vdso64.so
Dynamic section at offset 0x868 contains 12 entries:
TagType Name/Value
0x000e (SONAME) Library soname: [linux-vdso64.so.1]
0x0004 (HASH) 0x120
0x6ef5 (GNU_HASH) 0x170
0x0005 (STRTAB) 0x320
0x0006 (SYMTAB) 0x1d0
0x000a (STRSZ) 269 (bytes)
0x000b (SYMENT) 24 (bytes)
0x7003 (PPC64_OPT) 0x0
0x6ffc (VERDEF) 0x450
0x6ffd (VERDEFNUM) 2
0x6ff0 (VERSYM) 0x42e
0x (NULL) 0x0
So can't we just discard .gnu.hash? And in fact do we need .hash either?
Actually arm64 discards the latter, and parisc discards both.
Would still be good to hear from Alan or someone else who knows anything
about toolchain stuff, ie. not me :)
cheers
Re: linux-next: build warnings from Linus' tree
Hello Alan,
On Tue, 12 Jun 2018 at 07:44, Stephen Rothwell wrote:
> Building Linus' tree, today's linux-next build (powerpc ppc64_defconfig)
> produced these warning:
>
> ld: warning: orphan section `.gnu.hash' from `linker stubs' being placed in
> section `.gnu.hash'.
> ld: warning: orphan section `.gnu.hash' from `linker stubs' being placed in
> section `.gnu.hash'.
> ld: warning: orphan section `.gnu.hash' from `linker stubs' being placed in
> section `.gnu.hash'.
>
> This may just be because I have started building using the native Debian
> gcc for the powerpc builds ...
Do you know why we started creating these?
If it's intentional, should we be putting including them in the same
way as .hash sections?
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/kernel/vmlinux.lds.S#n282
.hash : AT(ADDR(.hash) - LOAD_OFFSET) { *(.hash) }
Cheers,
Joel
