On Thu, Feb 13, 2014 at 01:22:15PM -0500, Paul Gortmaker wrote:
> On Thu, Feb 13, 2014 at 12:31 PM, Paul Gortmaker
> <paul.gortmaker@xxxxxxxxxxxxx> wrote:
> > On Wed, Feb 12, 2014 at 9:19 PM, Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx> wrote:
> >> Hi John,
> >>
> >> After merging the wireless-next tree, today's linux-next build (x86_64
> >> allmodconfig) failed like this:
> >>
> >> drivers/staging/rtl8821ae/rc.c:289:2: error: unknown field 'module' specified in initializer
> >> .module = NULL,
> >> ^
> >>
> >> Caused by commit cc01f9b55fe7 ("mac80211: remove module handling from
> >> rate control ops") interacting with commit 3c05bedb5fef ("Staging:
> >> rtl8812ae: Add Realtek 8821 PCI WIFI driver") which entered Linus' tree
> >> before v3.14-rc1.
> >
> > It seems this new driver has multiple issues; I'm seeing this on sparc32
> > allmodconfig builds.
> >
> > In file included from drivers/staging/rtl8821ae/btcoexist/halbt_precomp.h:31:0,
> > from drivers/staging/rtl8821ae/btcoexist/halbtc8192e2ant.c:14:
> > drivers/staging/rtl8821ae/btcoexist/../pci.h:290:15: error: expected
> > '=', ',', ';', 'asm' or '__attribute__' before 'rtl_pci_probe'
> > make[3]: *** [drivers/staging/rtl8821ae/btcoexist/halbtc8192e2ant.o] Error 1
> > make[3]: *** Waiting for unfinished jobs....
> >
> > It looks like a mangled version check which is allowing it to try and use
> > __devinit on the rtl_pci_probe function, but of course __devinit is gone.
> >
> > Ideally all that version check stuff should be gutted.
>
> While it still should be gutted, I tracked down the source of the version
> skew. If a person is bisecting and if you go back to pre-UAPI days,
> you will create an include/linux/version.h -- then if you checkout a
> post-UAPI kernel, and run "make distclean" it won't delete that file.
> So you get a situation like this:
>
> $ grep -R LINUX_VERSION_CODE include/
> include/generated/uapi/linux/version.h:#define LINUX_VERSION_CODE 200192
> include/linux/version.h:#define LINUX_VERSION_CODE 132646
>
> Note the presence of a v2.6.38 version. And it will be sourced/used,
> hence the fail above. We might want to unconditionally clobber the
> old file in new kernels to avoid this trap, since it is subtle.
Yeah, I've run into that problem a number of times before, a 'git clean
-fdx' usually fixes it up for me, and is why I do it all the time when
switching major kernel versions.
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-next" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
