On 2 February 2017 14:47:34 GMT+00:00, Linus Walleij [off-list ref] wrote:

On Tue, Jan 31, 2017 at 8:54 PM, Jonathan Cameron [off-list ref]
wrote:

quoted

Applied this one as well with a spot of fuzz but all obvious stuff in

the

quoted

Makefile.

However...

ERROR: "qcom_vadc_decimation_from_dt"

[drivers/iio/adc/qcom-spmi-vadc.ko] undefined!

quoted

ERROR: "qcom_vadc_scale" [drivers/iio/adc/qcom-spmi-vadc.ko]

undefined!

quoted

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

quoted

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.

quoted

However, I can't see any way of keeping them module name as was

(qcom-smpi-vadc.ko)

quoted

without renaming one of the c files out of the way. Please check I

haven't messed

quoted

anything up.  The new naming is a bit naff, but I couldn't think of

anything better

quoted

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.

quoted

Actually this is enough of a mess I'm pulling these last two patches

for now.

quoted

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.

quoted

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.