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? > > 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 :) Yours, Linus Walleij -- 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
