[PATCH v2 1/5] ARM: Broadcom: Unconditionally build arch/arm/mach-bcm

[Florian Fainelli]

Hello,

2013/7/26 Domenico Andreoli <cavokz at gmail.com>:
> On Fri, Jul 26, 2013 at 11:29:18AM -0400, Jason Cooper wrote:
>> On Fri, Jul 26, 2013 at 04:56:40PM +0200, Domenico Andreoli wrote:
>> > From: Domenico Andreoli <domenico.andreoli at linux.com>
>> >
>> > arch/arm/mach-bcm contains a plurality of Broadcom SoCs, each configured
>> > separately. As a matter of flexibility and maintenance, it needs to be
>> > always included in the build.
>>
>> So if I'm building mach-kirkwood, I _have_ to build Broadcom?  What is
>> the *specific* problem you're encountering that this solves?
>
> In mach-bcm we (or I, it's not very clear to me) want to have support for
> multiple SoCs.
>
> In trying the approach
>
> machine-$(CONFIG_ARCH_BCM)              += bcm
> machine-$(CONFIG_ARCH_BCM4760)          += bcm
>
> I got linker complains about multiple symbol definitiion in case both the
> config options are selected.
>
> The first thought was to use a common option which purpose was only to
> include the subdir but then, given my allergy to the tons of config options
> with usually not straghtforward purpose, I opted for something more simple.

I do not understand why are you trying so hard to put your SoC support
in mach-bcm. I was one of the only people to complain that mach-bcm
was both confusing and not generic enough to cover all Broadcom SoCs.
I still think it should have been specified to mach-bcmmobile or
something like mach-bcm28xxx. Back in the days where ARM drivers were
mostly living in arch/arm/*, it *might* have made some sense but now,
I really think that you should go with your own mach-bcm470x
directory.

BCM47060, BCM53xx and BCM28xx all have both different CPU backends and
different on-chip peripherals, which are even connected differently,
put clearly, they share very little but the ARM architecture.
-- 
Florian