On 2 February 2017 14:47:34 GMT+00:00, Linus Walleij <linus.walleij@xxxxxxxxxx> wrote: >On Tue, Jan 31, 2017 at 8:54 PM, Jonathan Cameron <jic23@xxxxxxxxxx> >wrote: > >> Applied this one as well with a spot of fuzz but all obvious stuff in >the >> Makefile. >> >> However... >> >> ERROR: "qcom_vadc_decimation_from_dt" >[drivers/iio/adc/qcom-spmi-vadc.ko] undefined! >> ERROR: "qcom_vadc_scale" [drivers/iio/adc/qcom-spmi-vadc.ko] >undefined! >> make[1]: *** [scripts/Makefile.modpost:91: __modpost] Error 1 >> make: *** [Makefile:1198: modules] Error 2 >> >> I've fixed that up and some static declaration issue. >> >> Please do sanity check builds as modules! It all needs to be one one >object file >> when added to the $(magic)-m > >Sorry :( > >I guess I should really get better at that. I guess the sloppiness >comes >from never using modules for anything on any system in the first place. > >I did push a branch to my kernelorg git linux-integrator.git so I was >expecting the zerodaybuild to pick it up and build it and find these >things >but apparently I doesn't. Mea culpa, need to check with Fenguang >about this. > >> However, I can't see any way of keeping them module name as was >(qcom-smpi-vadc.ko) >> without renaming one of the c files out of the way. Please check I >haven't messed >> anything up. The new naming is a bit naff, but I couldn't think of >anything better >> off the top of my head! > >It looks all right to me, there is a dangling space after >+obj-$(CONFIG_QCOM_SPMI_VADC) += qcom-spmi-vadc.o >otherwise it looks fine. > >> Actually this is enough of a mess I'm pulling these last two patches >for now. >> Will push them out in a special testing2 branch for you to take a >look at though. > >By all means save it for whenever later or just tell me to resend after >v4.11-rc1. I have all time in the world. > >Anyways, I cherry-picked a commit needed for a boot regression >and added a hacky DT patch and built and booted this! > >The dmesg detects the device fine with nice calibration results, >lsiio reports it and the readings from the voltage ADCs work just >fine. > >> I also temporarily changed the mfd dependencies to add COMPILE_TEST. >> Seems fine, so if you could do a patch adding that we'll get better >build coverage. > >I added || COMPILE_TEST to MFD_PM8XXX > >Then I get the following with x86_64 allyesconfig: > > LD drivers/iio/adc/built-in.o >drivers/iio/adc/qcom-pm8xxx-xoadc.o: In function >`qcom_vadc_decimation_from_dt': >(.text+0x410): multiple definition of `qcom_vadc_decimation_from_dt' >drivers/iio/adc/qcom-spmi-vadc.o:(.text+0x410): first defined here >drivers/iio/adc/qcom-pm8xxx-xoadc.o: In function `qcom_vadc_scale': >(.text+0x0): multiple definition of `qcom_vadc_scale' >drivers/iio/adc/qcom-spmi-vadc.o:(.text+0x0): first defined here >../scripts/Makefile.build:446: recipe for target >'drivers/iio/adc/built-in.o' failed >make[5]: *** [drivers/iio/adc/built-in.o] Error 1 >../scripts/Makefile.build:551: recipe for target 'drivers/iio/adc' >failed >make[4]: *** [drivers/iio/adc] Error 2 >../scripts/Makefile.build:551: recipe for target 'drivers/iio' failed > >I looked at how you handle it in the Makefile, and it all makes sense >to >me unfortunately, it's just this thing with baking several objects into >one >module - it seems the Kbuild around that is easy to get wrong and >simply hard :( > >I first naturally put all the common code into its own module and >export >the symbols, simple. It just works, but that's just sooo.... ugly. So >the >elegant solutions are hard to get right. > >I can't figure it out right now, will get back to it after dinner or >so. Drat shows I never build other than modules :) Will probably have to be a helper module. J > >Yours, >Linus Walleij -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
