lkml.org 
[lkml]   [2018]   [Jan]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] bcma: Fix 'allmodconfig' and BCMA builds on MIPS targets
From
Date
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@kernel.org>
>>>
>>> Likewise, with the "Fixes:" tag fixed:
>>>
>>> Reviewed-by: Paul Burton <paul.burton@mips.com>
>>>
>>
>> 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

\
 
 \ /
  Last update: 2018-01-15 21:59    [W:0.031 / U:2.184 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site