[PATCH 3/3 v4] iio: adc: add a driver for Qualcomm PM8xxx HK/XOADC

Linus Walleij linus.walleij at linaro.org
Thu Feb 2 06:47:34 PST 2017


On Tue, Jan 31, 2017 at 8:54 PM, Jonathan Cameron <jic23 at kernel.org> 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.

Yours,
Linus Walleij



More information about the linux-arm-kernel mailing list