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

Domenico Andreoli cavokz at gmail.com
Thu Aug 1 10:15:59 EDT 2013


On Thu, Aug 01, 2013 at 10:23:48AM +0100, Florian Fainelli wrote:
> 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.

I've already explained my point elsewhere in this thread. It's not technical,
it's social. I don't see any technical disproportion to go either way.

thanks,
Domenico



More information about the linux-arm-kernel mailing list