linux-kernel - Re: [PATCH] bcma: Fix 'allmodconfig' and BCMA builds on MIPS targets

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 15 Jan 2018 12:58:20 -0800
From:   Guenter Roeck <linux@...ck-us.net>
To:     James Hogan <james.hogan@...s.com>
Cc:     Paul Burton <paul.burton@...s.com>,
        Rafał Miłecki <zajec5@...il.com>,
        linux-wireless@...r.kernel.org, linux-kernel@...r.kernel.org,
        Matt Redfearn <matt.redfearn@...tec.com>,
        Linux MIPS Mailing List <linux-mips@...ux-mips.org>
Subject: Re: [PATCH] bcma: Fix 'allmodconfig' and BCMA builds on MIPS targets

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@...nel.org>
>>>
>>> Likewise, with the "Fixes:" tag fixed:
>>>
>>>       Reviewed-by: Paul Burton <paul.burton@...s.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