All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Ellerman <mpe@ellerman.id.au>
To: Nathan Chancellor <natechancellor@gmail.com>,
	linuxppc-dev@lists.ozlabs.org,
	clang-built-linux@googlegroups.com
Cc: Scott Wood <oss@buserror.net>
Subject: Re: -Wincompatible-pointer-types in arch/powerpc/platforms/embedded6xx/mvme5100.c
Date: Tue, 14 Apr 2020 17:33:45 +1000	[thread overview]
Message-ID: <87eesqjzc6.fsf@mpe.ellerman.id.au> (raw)
In-Reply-To: <20200413201034.GA18373@ubuntu-s3-xlarge-x86>

Hi Nathan,

Thanks for the report.

Nathan Chancellor <natechancellor@gmail.com> writes:
> Hi all,
>
> 0day reported a build error in arch/powerpc/platforms/embedded6xx/mvme5100.c
> when building with clang [1]. This is not a clang specific issue since
> it also happens with gcc:
>
> $ curl -LSs https://lore.kernel.org/lkml/202004131704.6MH1jcq3%25lkp@intel.com/2-a.bin | gzip -d > .config
> $ make -j$(nproc) -s ARCH=powerpc CROSS_COMPILE=powerpc-linux- olddefconfig arch/powerpc/platforms/embedded6xx/mvme5100.o
> arch/powerpc/platforms/embedded6xx/mvme5100.c: In function 'mvme5100_add_bridge':
> arch/powerpc/platforms/embedded6xx/mvme5100.c:135:58: error: passing argument 5 of 'early_read_config_dword' from incompatible pointer type [-Werror=incompatible-pointer-types]
>   135 |  early_read_config_dword(hose, 0, 0, PCI_BASE_ADDRESS_1, &pci_membase);
>       |                                                          ^~~~~~~~~~~~
>       |                                                          |
>       |                                                          phys_addr_t * {aka long long unsigned int *}


Yuck.

> ...
> I am not sure how exactly this should be fixed. Should this driver just
> not be selectable when CONFIG_PHYS_ADDR_T_64BIT is selected or is there
> something else that I am missing?

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.

Then Kconfig has:

config PHYS_64BIT
	bool 'Large physical address support' if E500 || PPC_86xx
	depends on (44x || E500 || PPC_86xx) && !PPC_83xx && !PPC_82xx
	select PHYS_ADDR_T_64BIT


So it's PPC_86xx that allows 64-bit phys_addr_t.

That was added in:

  4ee7084eb11e ("POWERPC: Allow 32-bit hashed pgtable code to support 36-bit physical")

Which did:

config PHYS_64BIT
-	bool 'Large physical address support' if E500
-	depends on 44x || E500
+	bool 'Large physical address support' if E500 || PPC_86xx
+	depends on (44x || E500 || PPC_86xx) && !PPC_83xx && !PPC_82xx


ie. it wanted to add support for PPC_86xx but had to deliberately
exclude some of the other BOOK3S_32 based platforms.

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 ^

cheers

  reply	other threads:[~2020-04-14  7:47 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 [this message]
2020-04-14  7:52   ` Nathan Chancellor
2020-04-14 17:04   ` Scott Wood

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=87eesqjzc6.fsf@mpe.ellerman.id.au \
    --to=mpe@ellerman.id.au \
    --cc=clang-built-linux@googlegroups.com \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=natechancellor@gmail.com \
    --cc=oss@buserror.net \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.