[PATCH] ARM: defconfig: qcom: add APQ8060 DragonBoard devices

[Arnd Bergmann]

On Wednesday, January 11, 2017 2:19:55 PM CET Linus Walleij wrote:
> On Tue, Jan 10, 2017 at 3:53 PM, Andy Gross <andy.gross at linaro.org> wrote:
> > On Tue, Jan 10, 2017 at 10:55:21AM +0100, Linus Walleij wrote:
> >> This default-enables the devices found on the APQ8060 DragonBoard
> >> in the qcom_defconfig:
> >>
> >> - EBI2 bus
> >> - SMSC911x ethernet
> >> - LEDs class and PM8058 LEDs driver, trigger and heartbeat
> >>   trigger (so we get heartbeat on the board by default)
> >> - IIO framework, including the HRTimer trigger, KXSD9
> >>   accelerometer, MPU3050 gyroscope, AK8975 magnetometer and
> >>   BMP085 pressure sensor
> >>
> >> Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
> >
> > This brings up a point of discussion.  Do we even need the qcom_defconfig any
> > more?  Is everyone comfortable with using the multi_v7_defconfig?

I think having one specialized defconfig for the platform is helpful for
the build/boot testing, e.g. it can show whether a boot failure with
multi_v7_defconfig is the result of a qcom-specific change, or a side-effect
of something that was done on another platform.

> > Aside from size of the image, i can't think of any other reason to keep around
> > the separate qcom file.
> 
> Actually a bit of Arnd/Olof question.
> 
> Bystander opinion below:
> 
> That is pretty much up to the maintainer (you) I guess.
> Reasons would be:
> 
> - Lower footprint (because you may not need all stuff selected
>   as 'y' compiled-in in multi_v7) on some platforms this is even
>   necessary to get a bootable image or one that will load in
>   reasonable time.
> 
> - Enable a few things by default (both compiled-in and modules)
>   that multi_v7 would consider to be littering
> 
> - For "my" systems I usually like them because these defconfigs
>   have vastly shorter compile time (because so much stuff that
>   idon't concern me is left out).
> 
> On the other hand: some ARMv7 system maintainers have x86
> ambitions: compile once, run everywhere, and certainly that is
> the ambition with multi_v7, and if that overshadows all the above,
> just kill off qcom_defconfig and be happy :)

We recently killed of the Broadcom defconfig file that actually
contained some very different platforms that had not much in common
besides the company name.

I think my preference is to keep it, but if Andy wants it removed
and nobody complains, that's fine too.

	Arnd