From: Scott Wood <oss@buserror.net>
To: Michael Ellerman <mpe@ellerman.id.au>,
Nathan Chancellor <natechancellor@gmail.com>,
linuxppc-dev@lists.ozlabs.org,
clang-built-linux@googlegroups.com
Subject: Re: -Wincompatible-pointer-types in arch/powerpc/platforms/embedded6xx/mvme5100.c
Date: Tue, 14 Apr 2020 12:04:52 -0500 [thread overview]
Message-ID: <9796bef636f2aabab6eaf44237b63bd94c01d26f.camel@buserror.net> (raw)
In-Reply-To: <87eesqjzc6.fsf@mpe.ellerman.id.au>
On Tue, 2020-04-14 at 17:33 +1000, Michael Ellerman wrote:
> I'm not sure TBH. This is all ancient history as far as I can tell, none
> of it's been touched for ~7 years.
>
> Your config has:
>
> CONFIG_EMBEDDED6xx=y
> CONFIG_PPC_BOOK3S_32=y
> CONFIG_PPC_BOOK3S_6xx=y
> CONFIG_PPC_MPC52xx=y
> CONFIG_PPC_86xx=y
>
>
> Which I'm not sure really makes sense at all, ie. it's trying to build a
> kernel for multiple platforms at once (EMBEDDED6xx, MPC52xx, 86xx), but
> the Kconfig doesn't exclude that so I guess we have to live with it for
> now.
I thought supporting multiple platforms in a kernel was something we tried to
support when practical?
> So I'm going to guess it should have also excluded embedded6xx, and this
> seems to fix it:
>
> diff --git a/arch/powerpc/platforms/Kconfig.cputype
> b/arch/powerpc/platforms/Kconfig.cputype
> index 0c3c1902135c..134fc383daf7 100644
> --- a/arch/powerpc/platforms/Kconfig.cputype
> +++ b/arch/powerpc/platforms/Kconfig.cputype
> @@ -278,7 +278,7 @@ config PTE_64BIT
>
> config PHYS_64BIT
> bool 'Large physical address support' if E500 || PPC_86xx
> - depends on (44x || E500 || PPC_86xx) && !PPC_83xx && !PPC_82xx
> + depends on (44x || E500 || PPC_86xx) && !PPC_83xx && !PPC_82xx &&
> !EMBEDDED6xx
> select PHYS_ADDR_T_64BIT
> ---help---
> This option enables kernel support for larger than 32-bit physical
>
>
> So unless anyone can tell me otherwise I'm inclined to commit that ^
This could silently break someone's config who's depending on PHYS_64BIT (e.g.
an 86xx kernel that happens to include an embedded6xx target as well, even if
just by accident). It'd be better to have the MVME500 depend on
!CONFIG_PHYS_ADDR_T_64BIT as Nathan suggested (if there's nobody around to
test a fix to the actual bug), which shouldn't break anyone since it already
didn't build.
-Scott
prev parent reply other threads:[~2020-04-14 17:33 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-13 20:10 -Wincompatible-pointer-types in arch/powerpc/platforms/embedded6xx/mvme5100.c Nathan Chancellor
2020-04-14 7:33 ` Michael Ellerman
2020-04-14 7:52 ` Nathan Chancellor
2020-04-14 17:04 ` Scott Wood [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9796bef636f2aabab6eaf44237b63bd94c01d26f.camel@buserror.net \
--to=oss@buserror.net \
--cc=clang-built-linux@googlegroups.com \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
--cc=natechancellor@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).