On 01/15/2018 12:30 PM, James Hogan wrote:
On Mon, Jan 15, 2018 at 12:05:48PM -0800, Guenter Roeck wrote:
On 01/15/2018 09:10 AM, Paul Burton wrote:
Hello,
On Mon, Jan 15, 2018 at 10:23:37AM +0000, James Hogan wrote:
On Sun, Jan 14, 2018 at 01:34:02PM -0800, Guenter Roeck wrote:
Mips builds with BCMA host mode enabled fail in mainline and -next
with:
In file included from include/linux/bcma/bcma.h:10:0,
from drivers/bcma/bcma_private.h:9,
from drivers/bcma/main.c:8:
include/linux/bcma/bcma_driver_pci.h:218:24: error:
field 'pci_controller' has incomplete type
Bisect points to commit d41e6858ba58c ("MIPS: Kconfig: Set default MIPS
system type as generic") as the culprit. Analysis shows that the commmit
changes PCI configuration and enables PCI_DRIVERS_GENERIC. This in turn
disables PCI_DRIVERS_LEGACY. 'struct pci_controller' is, however, only
defined if PCI_DRIVERS_LEGACY is enabled.
Ultimately that means that BCMA_DRIVER_PCI_HOSTMODE depends on
PCI_DRIVERS_LEGACY. Add the missing dependency.
Fixes: d41e6858ba58c ("MIPS: Kconfig: Set default MIPS system type as ...")
Well, technically I think commit c5611df96804 ("MIPS: PCI: Introduce
CONFIG_PCI_DRIVERS_LEGACY") is to blame (Cc'ing paul), and the first bad
commit would be commit eed0eabd12ef ("MIPS: generic: Introduce generic
DT-based board support") which selects PCI_DRIVERS_GENERIC and is the
only platform to do so. Both commits were first in v4.9-rc1 and I can
reproduce this problem at that latter commit with the appropriate
configuration.
Ah - yes if I recall correctly my assumption was that the MIPS-specific
struct pci_controller was only used by the MIPS-specific PCI drivers
under arch/mips/pci/, which are only built when configured for the
appropriate platform.
In this case use of that MIPS-specific struct pci_controller has spread
beyond arch/mips/ & the user can be configured in for platforms other
than the one that will actually use the driver, including the generic
platform which moves towards more generic PCI drivers in
drivers/pci/host/.
But yes clearly the mentioned commit does also expose that existing
problem more widely and to the default allmodconfig, and it looks like a
reasonable approach for now, so if some mention of the other two commits
is added:
Reviewed-by: James Hogan <jhogan@xxxxxxxxxx>
Likewise, with the "Fixes:" tag fixed:
Reviewed-by: Paul Burton <paul.burton@xxxxxxxx>
Unfortunately, that alone doesn't fix the problem. SSB driver dependencies
are also broken, and in much worse shape. I had to add dependencies in five
places to get it to build, and the result is so messy that I won't even try
to submit it.
Oh, thats interesting. When I tried this earlier I just added "&&
PCI_DRIVERS_LEGACY" to the SSB_PCIHOST_POSSIBLE dependencies, but I was
waiting for Paul's feedback before submitting a similar patch.
You are right, that is much more straightforward than my attempted fix,
and it works.
But that wasn't -next, it was mainline + mips fixes branch + individual
fixes:
Mine is mainline plus "MIPS: Fix CPS SMP NS16550 UART defaults"
which for some reason never made it into mainline. For the nightly builds,
I ended up modifying my buildripts to fix that up manually in the created
configuration file.
And if that is fixed, mips:allmodconfig still doesn't build -
the next error is an undefined reference to physical_memsize in
arch/mips/kernel/vpe-mt.o.
That one is fairly easy to fix properly, I'll hopefully submit something
this evening.
I wonder if I should just stop trying to build allmodconfig for mips.
Any thoughts ?
With a few fixes applied it should be buildable I think. Sorry its been
late in the cycle before we've been able to get fixes merged.
Ok, I'll wait a bit longer before giving up on it.
Thanks,
Guenter
