| Message ID | 20161018001626.GA5976@angband.pl (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi Adam, Thanks, this is looking good. powerpc will be able to use the generic header. On Tue, 18 Oct 2016 02:16:26 +0200 Adam Borowski <kilobyte@angband.pl> wrote: > On Mon, Oct 17, 2016 at 02:22:34PM +0200, Mathieu OTHACEHE wrote: > > > +#include <asm/uaccess.h> > > > +#include <asm/uaccess.h> > > > > Included twice. > > D'oh! > > > > +#include <asm/string.h> > > > +#include <asm/page.h> > > > +#include <asm/checksum.h> > > > + > > > +#include <asm-generic/asm-prototypes.h> > > > + > > > +#include <asm/page.h> > > > +#include <asm/pgtable.h> > > > +#include <asm/special_insns.h> > > > +#include <asm/preempt.h> > > > > No <asm/arch_hweight.h> for __sw_hweight32 and __sw_hweight64 ? > > diff --git a/include/asm-generic/asm-prototypes.h b/include/asm-generic/asm-prototypes.h > new file mode 100644 > index 0000000..df13637 > --- /dev/null > +++ b/include/asm-generic/asm-prototypes.h > @@ -0,0 +1,7 @@ > +#include <linux/bitops.h> > > ... which has these. > > Alexey Dobriyan <adobriyan@gmail.com> wrote: > } bitops.h is wrong header as well. > } Why do you need bitops for bunch of function prototypes? > > Unless you guys prefer using low-level headers only, that is. Well you can't use asm/arch_hweight.h in a generic header of course. I would suggest just including linux/ variants where practical for the asm-generic/asm-prototypes.h header. We should probably just bring all these arch patches through the kbuild tree. I'm sorry for the breakage: I didn't realize it broke the build with some configs, otherwise I would have given Michal a heads up before his pull request, and worked to get this stuff in first. Thanks, Nick -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Dne 18.10.2016 v 03:34 Nicholas Piggin napsal(a): > We should probably just bring all these arch patches through the > kbuild tree. > > I'm sorry for the breakage: I didn't realize it broke the build with > some configs, otherwise I would have given Michal a heads up before > his pull request, and worked to get this stuff in first. It breaks with some binutils versions only (and only with CONFIG_MODVERSIONS=y, of course). Michal -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 19 Oct 2016 16:38:14 +0200 Michal Marek <mmarek@suse.com> wrote: > Dne 18.10.2016 v 03:34 Nicholas Piggin napsal(a): > > We should probably just bring all these arch patches through the > > kbuild tree. > > > > I'm sorry for the breakage: I didn't realize it broke the build with > > some configs, otherwise I would have given Michal a heads up before > > his pull request, and worked to get this stuff in first. > > It breaks with some binutils versions only (and only with > CONFIG_MODVERSIONS=y, of course). Yeah this seems to be the issue, it apparently slipped past all the automated builds. It seems like the existing CRC warnings in the tree only trigger in rare circumstances too, so something could be a bit fragile there. Thanks, Nick -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
(Adding Thorsten because of a serious regression and Steven because he tried to fix something in the same commit) Nicholas Piggin <npiggin@gmail.com> writes: > On Wed, 19 Oct 2016 16:38:14 +0200 > Michal Marek <mmarek@suse.com> wrote: > >> Dne 18.10.2016 v 03:34 Nicholas Piggin napsal(a): >> > We should probably just bring all these arch patches through the >> > kbuild tree. >> > >> > I'm sorry for the breakage: I didn't realize it broke the build with >> > some configs, otherwise I would have given Michal a heads up before >> > his pull request, and worked to get this stuff in first. >> >> It breaks with some binutils versions only (and only with >> CONFIG_MODVERSIONS=y, of course). > > Yeah this seems to be the issue, it apparently slipped past all the > automated builds. It seems like the existing CRC warnings in the tree > only trigger in rare circumstances too, so something could be a bit > fragile there. I upgraded from 4.8 to 4.9-rc2 and noticed that kernel modules fail to load (log below). After investigating for some time I found this thread and apparently this is not still fixed, at least not in Linus' tree. Reverting 784d5699eddc5 fixed the issue for me. As I don't see any fix available (please correct me if I'm wrong) we should just revert that commit until it's properly fixed. Also note that there's a related fix from Steven: [PATCH] x86: Fix export for mcount and __fentry__ https://marc.info/?l=linux-kernel&m=147733572502413 For compiling the kernel I'm using Ubuntu 12.04: ii binutils 2.22-6ubuntu1.4 GNU assembler, linker and binary utilities ii gcc 4:4.6.3-1ubuntu5 GNU C compiler The kernel is running on a separate machine with Ubuntu 14.04. [ 110.703414] bluetooth: disagrees about version of symbol __get_user_2 [ 110.703416] bluetooth: Unknown symbol __get_user_2 (err -22) [ 110.703429] bluetooth: disagrees about version of symbol __put_user_2 [ 110.703430] bluetooth: Unknown symbol __put_user_2 (err -22) [ 110.703579] bluetooth: disagrees about version of symbol __put_user_4 [ 110.703580] bluetooth: Unknown symbol __put_user_4 (err -22) [ 110.703669] bluetooth: disagrees about version of symbol __put_user_1 [ 110.703670] bluetooth: Unknown symbol __put_user_1 (err -22) [ 110.703688] bluetooth: disagrees about version of symbol mcount [ 110.703689] bluetooth: Unknown symbol mcount (err -22)
On Thu, 27 Oct 2016 11:10:03 +0300 Kalle Valo <kvalo@codeaurora.org> wrote: > (Adding Thorsten because of a serious regression and Steven because he > tried to fix something in the same commit) > > Nicholas Piggin <npiggin@gmail.com> writes: > > > On Wed, 19 Oct 2016 16:38:14 +0200 > > Michal Marek <mmarek@suse.com> wrote: > > > >> Dne 18.10.2016 v 03:34 Nicholas Piggin napsal(a): > >> > We should probably just bring all these arch patches through the > >> > kbuild tree. > >> > > >> > I'm sorry for the breakage: I didn't realize it broke the build with > >> > some configs, otherwise I would have given Michal a heads up before > >> > his pull request, and worked to get this stuff in first. > >> > >> It breaks with some binutils versions only (and only with > >> CONFIG_MODVERSIONS=y, of course). > > > > Yeah this seems to be the issue, it apparently slipped past all the > > automated builds. It seems like the existing CRC warnings in the tree > > only trigger in rare circumstances too, so something could be a bit > > fragile there. > > I upgraded from 4.8 to 4.9-rc2 and noticed that kernel modules fail to > load (log below). After investigating for some time I found this thread > and apparently this is not still fixed, at least not in Linus' tree. > > Reverting 784d5699eddc5 fixed the issue for me. As I don't see any fix > available (please correct me if I'm wrong) we should just revert that > commit until it's properly fixed. With these two patches together, does it work for you? http://marc.info/?l=linux-arch&m=147653546809512&w=2 http://marc.info/?l=linux-kernel&m=147669851906489&w=2 It would be helpful if you could test and let us know, because there seems to be a very tiny number of configs and toolchains that causes problems. > > Also note that there's a related fix from Steven: > > [PATCH] x86: Fix export for mcount and __fentry__ > https://marc.info/?l=linux-kernel&m=147733572502413 > > For compiling the kernel I'm using Ubuntu 12.04: > > ii binutils 2.22-6ubuntu1.4 GNU assembler, linker and binary utilities > ii gcc 4:4.6.3-1ubuntu5 GNU C compiler > > The kernel is running on a separate machine with Ubuntu 14.04. > > [ 110.703414] bluetooth: disagrees about version of symbol __get_user_2 > [ 110.703416] bluetooth: Unknown symbol __get_user_2 (err -22) > [ 110.703429] bluetooth: disagrees about version of symbol __put_user_2 > [ 110.703430] bluetooth: Unknown symbol __put_user_2 (err -22) > [ 110.703579] bluetooth: disagrees about version of symbol __put_user_4 > [ 110.703580] bluetooth: Unknown symbol __put_user_4 (err -22) > [ 110.703669] bluetooth: disagrees about version of symbol __put_user_1 > [ 110.703670] bluetooth: Unknown symbol __put_user_1 (err -22) > [ 110.703688] bluetooth: disagrees about version of symbol mcount > [ 110.703689] bluetooth: Unknown symbol mcount (err -22) > I haven't seen that one before. Did you definitely make and install new modules? Thanks, Nick -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Nicholas Piggin <npiggin@gmail.com> writes: > On Thu, 27 Oct 2016 11:10:03 +0300 > Kalle Valo <kvalo@codeaurora.org> wrote: > >> (Adding Thorsten because of a serious regression and Steven because he >> tried to fix something in the same commit) >> >> Nicholas Piggin <npiggin@gmail.com> writes: >> >> > On Wed, 19 Oct 2016 16:38:14 +0200 >> > Michal Marek <mmarek@suse.com> wrote: >> > >> >> Dne 18.10.2016 v 03:34 Nicholas Piggin napsal(a): >> >> > We should probably just bring all these arch patches through the >> >> > kbuild tree. >> >> > >> >> > I'm sorry for the breakage: I didn't realize it broke the build with >> >> > some configs, otherwise I would have given Michal a heads up before >> >> > his pull request, and worked to get this stuff in first. >> >> >> >> It breaks with some binutils versions only (and only with >> >> CONFIG_MODVERSIONS=y, of course). >> > >> > Yeah this seems to be the issue, it apparently slipped past all the >> > automated builds. It seems like the existing CRC warnings in the tree >> > only trigger in rare circumstances too, so something could be a bit >> > fragile there. >> >> I upgraded from 4.8 to 4.9-rc2 and noticed that kernel modules fail to >> load (log below). After investigating for some time I found this thread >> and apparently this is not still fixed, at least not in Linus' tree. >> >> Reverting 784d5699eddc5 fixed the issue for me. As I don't see any fix >> available (please correct me if I'm wrong) we should just revert that >> commit until it's properly fixed. > > With these two patches together, does it work for you? > > http://marc.info/?l=linux-arch&m=147653546809512&w=2 > http://marc.info/?l=linux-kernel&m=147669851906489&w=2 > > It would be helpful if you could test and let us know, because there seems > to be a very tiny number of configs and toolchains that causes > problems. With these two patches (on top of ath-201610251249 from ath.git, in practice 4.9-rc2 + latest wireless patches) module loading works again. If you want you can add my Tested-by: Tested-by: Kalle Valo <kvalo@codeaurora.org> Can we get these patches to Linus' tree soon? It's annoying to revert 784d5699eddc5 everytime I update my tree. >> Also note that there's a related fix from Steven: >> >> [PATCH] x86: Fix export for mcount and __fentry__ >> https://marc.info/?l=linux-kernel&m=147733572502413 >> >> For compiling the kernel I'm using Ubuntu 12.04: >> >> ii binutils 2.22-6ubuntu1.4 GNU assembler, linker and binary utilities >> ii gcc 4:4.6.3-1ubuntu5 GNU C compiler >> >> The kernel is running on a separate machine with Ubuntu 14.04. >> >> [ 110.703414] bluetooth: disagrees about version of symbol __get_user_2 >> [ 110.703416] bluetooth: Unknown symbol __get_user_2 (err -22) >> [ 110.703429] bluetooth: disagrees about version of symbol __put_user_2 >> [ 110.703430] bluetooth: Unknown symbol __put_user_2 (err -22) >> [ 110.703579] bluetooth: disagrees about version of symbol __put_user_4 >> [ 110.703580] bluetooth: Unknown symbol __put_user_4 (err -22) >> [ 110.703669] bluetooth: disagrees about version of symbol __put_user_1 >> [ 110.703670] bluetooth: Unknown symbol __put_user_1 (err -22) >> [ 110.703688] bluetooth: disagrees about version of symbol mcount >> [ 110.703689] bluetooth: Unknown symbol mcount (err -22) >> > > I haven't seen that one before. Did you definitely make and install new > modules? I'm pretty sure modules are correctly installed as I have used the same procedure for years: on my workstation I do 'make bindeb-pkg', copy the .deb to the test laptop and install the deb there. Also once I revert 784d5699eddc5 it starts immeadiately working.
On Thu, 27 Oct 2016 16:14:28 +0300 Kalle Valo <kvalo@codeaurora.org> wrote: > Nicholas Piggin <npiggin@gmail.com> writes: > > > On Thu, 27 Oct 2016 11:10:03 +0300 > > Kalle Valo <kvalo@codeaurora.org> wrote: > > > >> (Adding Thorsten because of a serious regression and Steven because he > >> tried to fix something in the same commit) > >> > >> Nicholas Piggin <npiggin@gmail.com> writes: > >> > >> > On Wed, 19 Oct 2016 16:38:14 +0200 > >> > Michal Marek <mmarek@suse.com> wrote: > >> > > >> >> Dne 18.10.2016 v 03:34 Nicholas Piggin napsal(a): > >> >> > We should probably just bring all these arch patches through the > >> >> > kbuild tree. > >> >> > > >> >> > I'm sorry for the breakage: I didn't realize it broke the build with > >> >> > some configs, otherwise I would have given Michal a heads up before > >> >> > his pull request, and worked to get this stuff in first. > >> >> > >> >> It breaks with some binutils versions only (and only with > >> >> CONFIG_MODVERSIONS=y, of course). > >> > > >> > Yeah this seems to be the issue, it apparently slipped past all the > >> > automated builds. It seems like the existing CRC warnings in the tree > >> > only trigger in rare circumstances too, so something could be a bit > >> > fragile there. > >> > >> I upgraded from 4.8 to 4.9-rc2 and noticed that kernel modules fail to > >> load (log below). After investigating for some time I found this thread > >> and apparently this is not still fixed, at least not in Linus' tree. > >> > >> Reverting 784d5699eddc5 fixed the issue for me. As I don't see any fix > >> available (please correct me if I'm wrong) we should just revert that > >> commit until it's properly fixed. > > > > With these two patches together, does it work for you? > > > > http://marc.info/?l=linux-arch&m=147653546809512&w=2 > > http://marc.info/?l=linux-kernel&m=147669851906489&w=2 > > > > It would be helpful if you could test and let us know, because there seems > > to be a very tiny number of configs and toolchains that causes > > problems. > > With these two patches (on top of ath-201610251249 from ath.git, in > practice 4.9-rc2 + latest wireless patches) module loading works again. > If you want you can add my Tested-by: > > Tested-by: Kalle Valo <kvalo@codeaurora.org> Great, thanks for testing it. > Can we get these patches to Linus' tree soon? It's annoying to revert > 784d5699eddc5 everytime I update my tree. Yes I think it's about ready to merge. Michal is returning from vacation next week so we should get some progress soon. > >> Also note that there's a related fix from Steven: > >> > >> [PATCH] x86: Fix export for mcount and __fentry__ > >> https://marc.info/?l=linux-kernel&m=147733572502413 > >> > >> For compiling the kernel I'm using Ubuntu 12.04: > >> > >> ii binutils 2.22-6ubuntu1.4 GNU assembler, linker and binary utilities > >> ii gcc 4:4.6.3-1ubuntu5 GNU C compiler > >> > >> The kernel is running on a separate machine with Ubuntu 14.04. > >> > >> [ 110.703414] bluetooth: disagrees about version of symbol __get_user_2 > >> [ 110.703416] bluetooth: Unknown symbol __get_user_2 (err -22) > >> [ 110.703429] bluetooth: disagrees about version of symbol __put_user_2 > >> [ 110.703430] bluetooth: Unknown symbol __put_user_2 (err -22) > >> [ 110.703579] bluetooth: disagrees about version of symbol __put_user_4 > >> [ 110.703580] bluetooth: Unknown symbol __put_user_4 (err -22) > >> [ 110.703669] bluetooth: disagrees about version of symbol __put_user_1 > >> [ 110.703670] bluetooth: Unknown symbol __put_user_1 (err -22) > >> [ 110.703688] bluetooth: disagrees about version of symbol mcount > >> [ 110.703689] bluetooth: Unknown symbol mcount (err -22) > >> > > > > I haven't seen that one before. Did you definitely make and install new > > modules? > > I'm pretty sure modules are correctly installed as I have used the same > procedure for years: on my workstation I do 'make bindeb-pkg', copy the > .deb to the test laptop and install the deb there. Also once I revert > 784d5699eddc5 it starts immeadiately working. > Sure, I was just checking because I've seen several types of failure but not this one before. Thanks for reporting and testing. Thanks, Nick -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 27.10.2016 10:10, Kalle Valo wrote: > (Adding Thorsten because of a serious regression and Steven because he > tried to fix something in the same commit) Many thx. I added this report to the list of regressions for Linux 4.9. I'll watch this thread for further updates on this issue to document progress in my weekly reports. Please let me know via regressions@leemhuis.info in case the discussion moves to a different place (bugzilla or another mail thread for example). Current status (afaics): Fix available, waiting for Michal to get back from vacation. tia! Ciao, Thorsten > Nicholas Piggin <npiggin@gmail.com> writes: > >> On Wed, 19 Oct 2016 16:38:14 +0200 >> Michal Marek <mmarek@suse.com> wrote: >> >>> Dne 18.10.2016 v 03:34 Nicholas Piggin napsal(a): >>>> We should probably just bring all these arch patches through the >>>> kbuild tree. >>>> >>>> I'm sorry for the breakage: I didn't realize it broke the build with >>>> some configs, otherwise I would have given Michal a heads up before >>>> his pull request, and worked to get this stuff in first. >>> >>> It breaks with some binutils versions only (and only with >>> CONFIG_MODVERSIONS=y, of course). >> >> Yeah this seems to be the issue, it apparently slipped past all the >> automated builds. It seems like the existing CRC warnings in the tree >> only trigger in rare circumstances too, so something could be a bit >> fragile there. > > I upgraded from 4.8 to 4.9-rc2 and noticed that kernel modules fail to > load (log below). After investigating for some time I found this thread > and apparently this is not still fixed, at least not in Linus' tree. > > Reverting 784d5699eddc5 fixed the issue for me. As I don't see any fix > available (please correct me if I'm wrong) we should just revert that > commit until it's properly fixed. > > Also note that there's a related fix from Steven: > > [PATCH] x86: Fix export for mcount and __fentry__ > https://marc.info/?l=linux-kernel&m=147733572502413 > > For compiling the kernel I'm using Ubuntu 12.04: > > ii binutils 2.22-6ubuntu1.4 GNU assembler, linker and binary utilities > ii gcc 4:4.6.3-1ubuntu5 GNU C compiler > > The kernel is running on a separate machine with Ubuntu 14.04. > > [ 110.703414] bluetooth: disagrees about version of symbol __get_user_2 > [ 110.703416] bluetooth: Unknown symbol __get_user_2 (err -22) > [ 110.703429] bluetooth: disagrees about version of symbol __put_user_2 > [ 110.703430] bluetooth: Unknown symbol __put_user_2 (err -22) > [ 110.703579] bluetooth: disagrees about version of symbol __put_user_4 > [ 110.703580] bluetooth: Unknown symbol __put_user_4 (err -22) > [ 110.703669] bluetooth: disagrees about version of symbol __put_user_1 > [ 110.703670] bluetooth: Unknown symbol __put_user_1 (err -22) > [ 110.703688] bluetooth: disagrees about version of symbol mcount > [ 110.703689] bluetooth: Unknown symbol mcount (err -22) > -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 2016-10-18 03:34, Nicholas Piggin wrote: > Hi Adam, > > Thanks, this is looking good. powerpc will be able to use the generic > header. > > On Tue, 18 Oct 2016 02:16:26 +0200 > Adam Borowski <kilobyte@angband.pl> wrote: > >> On Mon, Oct 17, 2016 at 02:22:34PM +0200, Mathieu OTHACEHE wrote: >>>> +#include <asm/uaccess.h> >>>> +#include <asm/uaccess.h> >>> >>> Included twice. >> >> D'oh! >> >>>> +#include <asm/string.h> >>>> +#include <asm/page.h> >>>> +#include <asm/checksum.h> >>>> + >>>> +#include <asm-generic/asm-prototypes.h> >>>> + >>>> +#include <asm/page.h> >>>> +#include <asm/pgtable.h> >>>> +#include <asm/special_insns.h> >>>> +#include <asm/preempt.h> >>> >>> No <asm/arch_hweight.h> for __sw_hweight32 and __sw_hweight64 ? >> >> diff --git a/include/asm-generic/asm-prototypes.h b/include/asm-generic/asm-prototypes.h >> new file mode 100644 >> index 0000000..df13637 >> --- /dev/null >> +++ b/include/asm-generic/asm-prototypes.h >> @@ -0,0 +1,7 @@ >> +#include <linux/bitops.h> >> >> ... which has these. >> >> Alexey Dobriyan <adobriyan@gmail.com> wrote: >> } bitops.h is wrong header as well. >> } Why do you need bitops for bunch of function prototypes? >> >> Unless you guys prefer using low-level headers only, that is. > > Well you can't use asm/arch_hweight.h in a generic header of course. > I would suggest just including linux/ variants where practical for > the asm-generic/asm-prototypes.h header. > > We should probably just bring all these arch patches through the > kbuild tree. Adam, are you submitting a new version of your x86 asm-prototypes.h patch? Thanks, Michal -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Nov 01, 2016 at 04:48:48PM +0100, Michal Marek wrote: > > Adam Borowski <kilobyte@angband.pl> wrote: > > > >> On Mon, Oct 17, 2016 at 02:22:34PM +0200, Mathieu OTHACEHE wrote: > >>>> +#include <asm/uaccess.h> > >>>> +#include <asm/uaccess.h> > >>> > >>> Included twice. > >> > >> D'oh! This appears to be the only thing to fix, right? > >>>> +#include <asm/string.h> > >>>> +#include <asm/page.h> > >>>> +#include <asm/checksum.h> > >>>> + > >>>> +#include <asm-generic/asm-prototypes.h> > >>>> + > >>>> +#include <asm/page.h> > >>>> +#include <asm/pgtable.h> > >>>> +#include <asm/special_insns.h> > >>>> +#include <asm/preempt.h> > >>> > >>> No <asm/arch_hweight.h> for __sw_hweight32 and __sw_hweight64 ? > >> > >> diff --git a/include/asm-generic/asm-prototypes.h b/include/asm-generic/asm-prototypes.h > >> new file mode 100644 > >> index 0000000..df13637 > >> --- /dev/null > >> +++ b/include/asm-generic/asm-prototypes.h > >> @@ -0,0 +1,7 @@ > >> +#include <linux/bitops.h> > >> > >> ... which has these. > >> > >> Alexey Dobriyan <adobriyan@gmail.com> wrote: > >> } bitops.h is wrong header as well. > >> } Why do you need bitops for bunch of function prototypes? > >> > >> Unless you guys prefer using low-level headers only, that is. > > > > Well you can't use asm/arch_hweight.h in a generic header of course. > > I would suggest just including linux/ variants where practical for > > the asm-generic/asm-prototypes.h header. > > > > We should probably just bring all these arch patches through the > > kbuild tree. I believe inclusion of <linux/bitops.h> is the right thing to do, but if not, the patch would also need: extern unsigned int __sw_hweight8(unsigned int w); extern unsigned int __sw_hweight16(unsigned int w); extern unsigned int __sw_hweight32(unsigned int w); extern unsigned long __sw_hweight64(__u64 w); There's also the issue of mcount/__fentry__, but that's apparently already dealt with in 5de0a8c, already in mainline. > are you submitting a new version of your x86 asm-prototypes.h patch? The update is trivial, but yeah, I can resubmit. If I'm wrong about where __sw_hweight{8,16,32,64} should come from, please say so. Meow!
diff --git a/include/asm-generic/asm-prototypes.h b/include/asm-generic/asm-prototypes.h new file mode 100644 index 0000000..df13637 --- /dev/null +++ b/include/asm-generic/asm-prototypes.h @@ -0,0 +1,7 @@ +#include <linux/bitops.h> ... which has these. Alexey Dobriyan <adobriyan@gmail.com> wrote: } bitops.h is wrong header as well. } Why do you need bitops for bunch of function prototypes?