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@xxxxxxxxxx> 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@xxxxxxxxxx> > > > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
