Hi all,
After merging the sound-asoc tree, today's linux-next build (x86_64
allmodconfig) failed like this:
In file included from sound/soc/codecs/ics43432.c:12:0:
sound/soc/codecs/ics43432.c:60:25: error: 'ics43432_dt_ids' undeclared here (not in a function)
MODULE_DEVICE_TABLE(of, ics43432_dt_ids);
^
include/linux/module.h:223:21: note: in definition of macro 'MODULE_DEVICE_TABLE'
extern const typeof(name) __mod_##type##__##name##_device_table \
^
include/linux/module.h:223:27: error: '__mod_of__ics43432_dt_ids_device_table' aliased to undefined symbol 'ics43432_dt_ids'
extern const typeof(name) __mod_##type##__##name##_device_table \
^
sound/soc/codecs/ics43432.c:60:1: note: in expansion of macro 'MODULE_DEVICE_TABLE'
MODULE_DEVICE_TABLE(of, ics43432_dt_ids);
^
Caused by commit
3b7ce99748f0 ("ASoC: ics43432: Add codec driver for InvenSense ICS-43432")
Not really build tested with CONFIG_OF set, right? :-(
I have reverted that commit for today.
--
Cheers,
Stephen Rothwell [email protected]
On Fri, 28 Aug 2015, Stephen Rothwell wrote:
> After merging the sound-asoc tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> In file included from sound/soc/codecs/ics43432.c:12:0:
> sound/soc/codecs/ics43432.c:60:25: error: 'ics43432_dt_ids' undeclared here (not in a function)
> MODULE_DEVICE_TABLE(of, ics43432_dt_ids);
> ^
> include/linux/module.h:223:21: note: in definition of macro 'MODULE_DEVICE_TABLE'
> extern const typeof(name) __mod_##type##__##name##_device_table \
> ^
> include/linux/module.h:223:27: error: '__mod_of__ics43432_dt_ids_device_table' aliased to undefined symbol 'ics43432_dt_ids'
> extern const typeof(name) __mod_##type##__##name##_device_table \
> ^
> sound/soc/codecs/ics43432.c:60:1: note: in expansion of macro 'MODULE_DEVICE_TABLE'
> MODULE_DEVICE_TABLE(of, ics43432_dt_ids);
> ^
>
> Caused by commit
>
> 3b7ce99748f0 ("ASoC: ics43432: Add codec driver for InvenSense ICS-43432")
>
> Not really build tested with CONFIG_OF set, right? :-(
Well, actually, yes.
In fact the exact same construct is used by a handful of other codec
drivers which apparently don't fail.
I'm suspecting something slightly more convoluted like a missing #include .
> I have reverted that commit for today.
Ok. I'll get to work on this ASAP.
/Ricard
--
Ricard Wolf Wanderl?f ricardw(at)axis.com
Axis Communications AB, Lund, Sweden http://www.axis.com
Phone +46 46 272 2016 Fax +46 46 13 61 30
On Fri, Aug 28, 2015 at 09:40:41AM +0200, Ricard Wanderlof wrote:
> On Fri, 28 Aug 2015, Stephen Rothwell wrote:
> In fact the exact same construct is used by a handful of other codec
> drivers which apparently don't fail.
> I'm suspecting something slightly more convoluted like a missing #include .
No, the issue is that you have used a different variable name when
declaring the IDs and when referencing them in the module device table.
On Fri, 28 Aug 2015, Mark Brown wrote:
> On Fri, Aug 28, 2015 at 09:40:41AM +0200, Ricard Wanderlof wrote:
> > On Fri, 28 Aug 2015, Stephen Rothwell wrote:
>
> > In fact the exact same construct is used by a handful of other codec
> > drivers which apparently don't fail.
>
> > I'm suspecting something slightly more convoluted like a missing
> #include .
>
> No, the issue is that you have used a different variable name when
> declaring the IDs and when referencing them in the module device table.
Yeah, I realized that upon closer inspection.
What bugs me is that my ARM gcc didn't seem to flag this, whereas the
x86 gcc did upon subsequent testing. And yes, CONFIG_OF is set during my
build.
/Ricard
--
Ricard Wolf Wanderl?f ricardw(at)axis.com
Axis Communications AB, Lund, Sweden http://www.axis.com
Phone +46 46 272 2016 Fax +46 46 13 61 30
Hi Ricard,
On Mon, 31 Aug 2015 09:04:22 +0200 Ricard Wanderlof <[email protected]> wrote:
>
> On Fri, 28 Aug 2015, Mark Brown wrote:
>
> > On Fri, Aug 28, 2015 at 09:40:41AM +0200, Ricard Wanderlof wrote:
> > > On Fri, 28 Aug 2015, Stephen Rothwell wrote:
> >
> > > In fact the exact same construct is used by a handful of other codec
> > > drivers which apparently don't fail.
> >
> > > I'm suspecting something slightly more convoluted like a missing
> > #include .
> >
> > No, the issue is that you have used a different variable name when
> > declaring the IDs and when referencing them in the module device table.
>
> Yeah, I realized that upon closer inspection.
>
> What bugs me is that my ARM gcc didn't seem to flag this, whereas the
> x86 gcc did upon subsequent testing. And yes, CONFIG_OF is set during my
> build.
Do you have CONFIG_MODULE set in your build? (just guessing)
--
Cheers,
Stephen Rothwell [email protected]
Hi Ricard,
On Mon, 31 Aug 2015 17:48:42 +1000 Stephen Rothwell <[email protected]> wrote:
>
> On Mon, 31 Aug 2015 09:04:22 +0200 Ricard Wanderlof <[email protected]> wrote:
> >
> > On Fri, 28 Aug 2015, Mark Brown wrote:
> >
> > > On Fri, Aug 28, 2015 at 09:40:41AM +0200, Ricard Wanderlof wrote:
> > > > On Fri, 28 Aug 2015, Stephen Rothwell wrote:
> > >
> > > > In fact the exact same construct is used by a handful of other codec
> > > > drivers which apparently don't fail.
> > >
> > > > I'm suspecting something slightly more convoluted like a missing
> > > #include .
> > >
> > > No, the issue is that you have used a different variable name when
> > > declaring the IDs and when referencing them in the module device table.
> >
> > Yeah, I realized that upon closer inspection.
> >
> > What bugs me is that my ARM gcc didn't seem to flag this, whereas the
> > x86 gcc did upon subsequent testing. And yes, CONFIG_OF is set during my
> > build.
>
> Do you have CONFIG_MODULE set in your build? (just guessing)
Actually what matters is if you build the driver as a module or not.
See include/linux/module.h and the definitions of MODULE_DEVICE_TABLE().
--
Cheers,
Stephen Rothwell [email protected]
On Mon, 31 Aug 2015, Stephen Rothwell wrote:
> On Mon, 31 Aug 2015 17:48:42 +1000 Stephen Rothwell <[email protected]> wrote:
> >
> > On Mon, 31 Aug 2015 09:04:22 +0200 Ricard Wanderlof <[email protected]> wrote:
> > >
> > > On Fri, 28 Aug 2015, Mark Brown wrote:
> > >
> > > > On Fri, Aug 28, 2015 at 09:40:41AM +0200, Ricard Wanderlof wrote:
> > > > > On Fri, 28 Aug 2015, Stephen Rothwell wrote:
> > > >
> > > > > In fact the exact same construct is used by a handful of other codec
> > > > > drivers which apparently don't fail.
> > > >
> > > > > I'm suspecting something slightly more convoluted like a missing
> > > > #include .
> > > >
> > > > No, the issue is that you have used a different variable name when
> > > > declaring the IDs and when referencing them in the module device table.
> > >
> > > Yeah, I realized that upon closer inspection.
> > >
> > > What bugs me is that my ARM gcc didn't seem to flag this, whereas the
> > > x86 gcc did upon subsequent testing. And yes, CONFIG_OF is set during my
> > > build.
> >
> > Do you have CONFIG_MODULE set in your build? (just guessing)
>
> Actually what matters is if you build the driver as a module or not.
> See include/linux/module.h and the definitions of MODULE_DEVICE_TABLE().
Bingo.
Haven't verified that, but it's true, the kernel build for our ARM system
is largely monolithic as we have no need to reconfigure it once it has
been built. Whereas in my x86 test build the driver was built as a module.
Thanks Stegphen!
/Ricard
--
Ricard Wolf Wanderl?f ricardw(at)axis.com
Axis Communications AB, Lund, Sweden http://www.axis.com
Phone +46 46 272 2016 Fax +46 46 13 61 30