[PATCH v2 6/9] arm64: bcmbca: Make BCM4908 drivers depend on ARCH_BCMBCA

Florian Fainelli f.fainelli at gmail.com
Thu Jul 28 12:22:12 PDT 2022


On 7/27/22 05:31, Rafał Miłecki wrote:
> On 2022-07-25 07:53, William Zhang wrote:
>> With Broadcom Broadband arch ARCH_BCMBCA supported in the kernel, this
>> patch series migrate the ARCH_BCM4908 symbol to ARCH_BCMBCA. Hence
>> replace ARCH_BCM4908 with ARCH_BCMBCA in subsystem Kconfig files.
>>
>> Signed-off-by: William Zhang <william.zhang at broadcom.com>
>> Acked-by: Guenter Roeck <linux at roeck-us.net> (for watchdog)
>> Acked-by: Bjorn Helgaas <bhelgaas at google.com> (for drivers/pci)
> 
> I still think it may be a bad idea for all below drivers. Please see my
> previous e-mail:
> Re: [RESEND PATCH 6/9] arm64: bcmbca: Make BCM4908 drivers depend on ARCH_BCMBCA
> https://lore.kernel.org/linux-arm-kernel/eee8c85652e6dac69420a876d03f67c4@milecki.pl/
> 
> I think we should:
> 1. Keep ARCH_BCM4908 for 4908 specific drivers (e.g. mtd, pinctrl, net)
> 2. Use ARCH_BCMBCA for more generic drivers (e.g. I2C, PCI,serial, WD)

IMHO here is no point in keeping an ARCH_BCM4908 anymore when the whole point of the patch series is to do a broad conversion of ARCH_BCM4908 into ARCH_BCMBCA. Even if some of the drivers are considered or thought to be 4908-specific, this is not going to be an issue in practice because there ought to be appropriate compatible strings such that even if you built a 4908-specific driver into a generic ARCH_BCMCA kernel, the actual probing would only happen on 4908.

Now let us flip it the other way round, let's say we keep ARCH_BCM4908 as a sub-arch of ARCH_BCMBCA, then this sets a precedent for adding more and more of those ARCH_BCM4906, ARCH_BCM4912 etc. etc to future kernels under the same reasons that we might want to gate certain drivers to certain sub-arches. But what good does that do?

At some point we got to make it simple for the users, and the simplest way is to have ARCH_BCMBCA only and let DT dictate the device specific probing.
-- 
Florian



More information about the linux-phy mailing list