next-20160225 build: 2 failures 44 warnings (next-20160225)

next-20160225 build: 2 failures 44 warnings (next-20160225)

[Mark Brown]

On Thu, Feb 25, 2016 at 10:04:29AM +0000, Build bot for Mark Brown wrote:

Today's -next fails to build an arm64 allmodconfig due to:

> 	arm64-allmodconfig
> ../drivers/pci/host/pci-mvebu.c:755:12: error: dereferencing pointer to incomplete type 'struct pci_sys_data'
> ../drivers/pci/host/pci-mvebu.c:855:31: error: dereferencing pointer to incomplete type 'struct pci_sys_data'
> ../drivers/pci/host/pci-mvebu.c:904:16: error: storage size of 'hw' isn't known
> ../drivers/pci/host/pci-mvebu.c:919:2: error: implicit declaration of function 'pci_common_init_dev' [-Werror=implicit-function-declaration]
> ../drivers/pci/host/pci-mvebu.c:1282:3: error: implicit declaration of function 'pci_ioremap_io' [-Werror=implicit-function-declaration]

caused by b4f596b19624 (arm64: add mvebu architecture entry) which
enables MVBEU on arm64, the commit was present for a little while and
the error cropped up but didn't get reported due to other things masking
it.  This looks like the driver needs modernization and probably ought
to have a !ARM64 dependency for now.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160226/1f18ad67/attachment.sig>

next-20160225 build: 2 failures 44 warnings (next-20160225)

[Thomas Petazzoni]

Mark,

On Fri, 26 Feb 2016 12:04:11 +0900, Mark Brown wrote:

> Today's -next fails to build an arm64 allmodconfig due to:
> 
> > 	arm64-allmodconfig
> > ../drivers/pci/host/pci-mvebu.c:755:12: error: dereferencing pointer to incomplete type 'struct pci_sys_data'
> > ../drivers/pci/host/pci-mvebu.c:855:31: error: dereferencing pointer to incomplete type 'struct pci_sys_data'
> > ../drivers/pci/host/pci-mvebu.c:904:16: error: storage size of 'hw' isn't known
> > ../drivers/pci/host/pci-mvebu.c:919:2: error: implicit declaration of function 'pci_common_init_dev' [-Werror=implicit-function-declaration]
> > ../drivers/pci/host/pci-mvebu.c:1282:3: error: implicit declaration of function 'pci_ioremap_io' [-Werror=implicit-function-declaration]
> 
> caused by b4f596b19624 (arm64: add mvebu architecture entry) which
> enables MVBEU on arm64, the commit was present for a little while and
> the error cropped up but didn't get reported due to other things masking
> it.  This looks like the driver needs modernization and probably ought
> to have a !ARM64 dependency for now.

This has already been fixed by:

	[PATCH] PCI: mvebu: Restrict build to 32-bit ARM

submitted by Thierry Redding. I'm Cc'ing Bjorn, who is the one in
charge of merging this fix.

Thanks for reporting!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

next-20160225 build: 2 failures 44 warnings (next-20160225)

[Bjorn Helgaas]

On Fri, Feb 26, 2016 at 2:08 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Mark,
>
> On Fri, 26 Feb 2016 12:04:11 +0900, Mark Brown wrote:
>
>> Today's -next fails to build an arm64 allmodconfig due to:
>>
>> >     arm64-allmodconfig
>> > ../drivers/pci/host/pci-mvebu.c:755:12: error: dereferencing pointer to incomplete type 'struct pci_sys_data'
>> > ../drivers/pci/host/pci-mvebu.c:855:31: error: dereferencing pointer to incomplete type 'struct pci_sys_data'
>> > ../drivers/pci/host/pci-mvebu.c:904:16: error: storage size of 'hw' isn't known
>> > ../drivers/pci/host/pci-mvebu.c:919:2: error: implicit declaration of function 'pci_common_init_dev' [-Werror=implicit-function-declaration]
>> > ../drivers/pci/host/pci-mvebu.c:1282:3: error: implicit declaration of function 'pci_ioremap_io' [-Werror=implicit-function-declaration]
>>
>> caused by b4f596b19624 (arm64: add mvebu architecture entry) which
>> enables MVBEU on arm64, the commit was present for a little while and
>> the error cropped up but didn't get reported due to other things masking
>> it.  This looks like the driver needs modernization and probably ought
>> to have a !ARM64 dependency for now.
>
> This has already been fixed by:
>
>         [PATCH] PCI: mvebu: Restrict build to 32-bit ARM
>
> submitted by Thierry Redding. I'm Cc'ing Bjorn, who is the one in
> charge of merging this fix.

I applied Thierry's patch ("PCI: mvebu: Restrict build to 32-bit ARM")
to my for-linus branch, so it should appear in Linus' tree before
v4.5.

Bjorn

next-20160225 build: 2 failures 44 warnings (next-20160225)

[Mark Brown]

On Thu, Feb 25, 2016 at 10:04:29AM +0000, Build bot for Mark Brown wrote:

Today's -next fails to build an arm64 allmodconfig due to:

> 	arm64-allmodconfig
> ../drivers/watchdog/orion_wdt.c:109:2: error: implicit declaration of function 'atomic_io_modify' [-Werror=implicit-function-declaration]

also caused by b4f596b19624 (arm64: add mvebu architecture entry) which
enables MVBEU on arm64, the commit was present for a little while and
the error cropped up but didn't get reported due to other things masking
it.  atomic_io_modify() is only available on ARM, I'm unsure if this
needs a driver change or if the driver is just specific to older
hardware anyway.  The code is only used in the init path accessing what
look to be device specific registers so I'm not 100% clear why it
specifically needs to be an atomic modify.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160226/23d7bd97/attachment.sig>

next-20160225 build: 2 failures 44 warnings (next-20160225)

[Guenter Roeck]

Hi Mark,

On 02/25/2016 07:09 PM, Mark Brown wrote:
> On Thu, Feb 25, 2016 at 10:04:29AM +0000, Build bot for Mark Brown wrote:
>
> Today's -next fails to build an arm64 allmodconfig due to:
>
>> 	arm64-allmodconfig
>> ../drivers/watchdog/orion_wdt.c:109:2: error: implicit declaration of function 'atomic_io_modify' [-Werror=implicit-function-declaration]
>
> also caused by b4f596b19624 (arm64: add mvebu architecture entry) which
> enables MVBEU on arm64, the commit was present for a little while and
> the error cropped up but didn't get reported due to other things masking
> it.  atomic_io_modify() is only available on ARM, I'm unsure if this
> needs a driver change or if the driver is just specific to older
> hardware anyway.  The code is only used in the init path accessing what
> look to be device specific registers so I'm not 100% clear why it
> specifically needs to be an atomic modify.
>
Thierry already submitted a patch yesterday to restrict the driver to only
build on ARM. We can revisit if/when the driver is needed on ARM64.

Guenter

next-20160225 build: 2 failures 44 warnings (next-20160225)

[Thomas Petazzoni]

Guenter,

On Thu, 25 Feb 2016 23:41:50 -0800, Guenter Roeck wrote:

> > also caused by b4f596b19624 (arm64: add mvebu architecture entry) which
> > enables MVBEU on arm64, the commit was present for a little while and
> > the error cropped up but didn't get reported due to other things masking
> > it.  atomic_io_modify() is only available on ARM, I'm unsure if this
> > needs a driver change or if the driver is just specific to older
> > hardware anyway.  The code is only used in the init path accessing what
> > look to be device specific registers so I'm not 100% clear why it
> > specifically needs to be an atomic modify.
> >
> Thierry already submitted a patch yesterday to restrict the driver to only
> build on ARM. We can revisit if/when the driver is needed on ARM64.

Ah, good, thanks. It isn't clear yet whether the driver will be needed
on ARM64 for the Marvell platforms. For Armada 7K/8K, there is a SBSA
compliant watchdog. For Armada 3700, I have only briefly looked, but it
seems to be a different IP than the one used on the 32 bits SoCs.

Thanks Thierry for fixing the issue!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

next-20160225 build: 2 failures 44 warnings (next-20160225)

[Thomas Petazzoni]

Mark,

On Fri, 26 Feb 2016 12:09:49 +0900, Mark Brown wrote:

> also caused by b4f596b19624 (arm64: add mvebu architecture entry) which
> enables MVBEU on arm64, the commit was present for a little while and
> the error cropped up but didn't get reported due to other things masking
> it.  atomic_io_modify() is only available on ARM, I'm unsure if this
> needs a driver change or if the driver is just specific to older
> hardware anyway.  The code is only used in the init path accessing what
> look to be device specific registers so I'm not 100% clear why it
> specifically needs to be an atomic modify.

atomic_io_modify() is also used in the ->start() and ->stop() hooks, so
not only during initialization. The reason we use atomic_io_modify()
here is because this TIMER_CTRL register is shared with the clocksource
drivers (time-orion.c, time-armada-370-xp.c). Indeed, the timers and
watchdogs share a single register that allows to enable/disable all
timers/watchdogs. Somewhat unfortunate choice, but that's how the HW is.

By far the easiest solution is to add "depends on ARM" to
ORION_WATCHDOG.

Another solution would be to provide an implementation of
atomic_io_modify() on arm64, though that would need the ACK from the
ARM64 maintainers.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

next-20160225 build: 2 failures 44 warnings (next-20160225)

[Mark Brown]

On Fri, Feb 26, 2016 at 09:14:10AM +0100, Thomas Petazzoni wrote:

> atomic_io_modify() is also used in the ->start() and ->stop() hooks, so
> not only during initialization. The reason we use atomic_io_modify()
> here is because this TIMER_CTRL register is shared with the clocksource
> drivers (time-orion.c, time-armada-370-xp.c). Indeed, the timers and
> watchdogs share a single register that allows to enable/disable all
> timers/watchdogs. Somewhat unfortunate choice, but that's how the HW is.

> By far the easiest solution is to add "depends on ARM" to
> ORION_WATCHDOG.

> Another solution would be to provide an implementation of
> atomic_io_modify() on arm64, though that would need the ACK from the
> ARM64 maintainers.

It also sounds like a more modern solution might be to use syscon for
the shared register, but perhaps I'm missing something about how the IP
is set up so ICBW.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160226/c084c32b/attachment.sig>

next-20160225 build: 2 failures 44 warnings (next-20160225)

[Thomas Petazzoni]

Mark,

On Fri, 26 Feb 2016 21:12:20 +0900, Mark Brown wrote:

> > Another solution would be to provide an implementation of
> > atomic_io_modify() on arm64, though that would need the ACK from the
> > ARM64 maintainers.
> 
> It also sounds like a more modern solution might be to use syscon for
> the shared register, but perhaps I'm missing something about how the IP
> is set up so ICBW.

I think back when we implemented this, syscon/simple-mfd was
not available or widely used - I don't really remember. We could indeed
try to switch to a syscon based solution.

Thanks,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com