* Re: backports spatch question [not found] <e26b0d55-8662-ecf7-6630-ac23a99374b5@candelatech.com> @ 2021-07-01 21:40 ` Johannes Berg 2021-07-01 21:40 ` Ben Greear 0 siblings, 1 reply; 20+ messages in thread From: Johannes Berg @ 2021-07-01 21:40 UTC (permalink / raw) To: Ben Greear, Hauke Mehrtens; +Cc: backports On Thu, 2021-07-01 at 14:39 -0700, Ben Greear wrote: > Hello, > > I'm trying to get backports to work against my 5.13 kernel. I'm executing > this attempt on a Fedora-34 system, freshly updated. > > I am stuck on an spatch thing: > > [greearb@v-f34-64 backports]$ mkdir /tmp/x > [greearb@v-f34-64 backports]$ spatch --sp-file patches/0049-no-pfmemalloc/no-pfmemalloc.cocci --dir /tmp/x > init_defs_builtins: /usr/lib64/coccinelle/standard.h > minus: parse error: > File "patches/0049-no-pfmemalloc/no-pfmemalloc.cocci", line 7, column 4, charpos = 90 > around = 'page_is_pfmemalloc', > whole content = || page_is_pfmemalloc(page) > > > [greearb@v-f34-64 backports]$ cat patches/0049-no-pfmemalloc/no-pfmemalloc.cocci > @r1@ > struct page *page; > expression E1; > @@ > return E1 > +#if LINUX_VERSION_IS_GEQ(3,6,0) > || page_is_pfmemalloc(page) > +#endif /* if LINUX_VERSION_IS_GEQ(3,6,0) */ > ; > > > Any idea how to fix this? What's your spatch version on that system? johannes -- To unsubscribe from this list: send the line "unsubscribe backports" in ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: backports spatch question 2021-07-01 21:40 ` backports spatch question Johannes Berg @ 2021-07-01 21:40 ` Ben Greear 2021-07-01 21:51 ` Johannes Berg 0 siblings, 1 reply; 20+ messages in thread From: Ben Greear @ 2021-07-01 21:40 UTC (permalink / raw) To: Johannes Berg, Hauke Mehrtens; +Cc: backports On 7/1/21 2:40 PM, Johannes Berg wrote: > On Thu, 2021-07-01 at 14:39 -0700, Ben Greear wrote: >> Hello, >> >> I'm trying to get backports to work against my 5.13 kernel. I'm executing >> this attempt on a Fedora-34 system, freshly updated. >> >> I am stuck on an spatch thing: >> >> [greearb@v-f34-64 backports]$ mkdir /tmp/x >> [greearb@v-f34-64 backports]$ spatch --sp-file patches/0049-no-pfmemalloc/no-pfmemalloc.cocci --dir /tmp/x >> init_defs_builtins: /usr/lib64/coccinelle/standard.h >> minus: parse error: >> File "patches/0049-no-pfmemalloc/no-pfmemalloc.cocci", line 7, column 4, charpos = 90 >> around = 'page_is_pfmemalloc', >> whole content = || page_is_pfmemalloc(page) >> >> >> [greearb@v-f34-64 backports]$ cat patches/0049-no-pfmemalloc/no-pfmemalloc.cocci >> @r1@ >> struct page *page; >> expression E1; >> @@ >> return E1 >> +#if LINUX_VERSION_IS_GEQ(3,6,0) >> || page_is_pfmemalloc(page) >> +#endif /* if LINUX_VERSION_IS_GEQ(3,6,0) */ >> ; >> >> >> Any idea how to fix this? > > What's your spatch version on that system? > > johannes > [greearb@v-f34-64 backports]$ spatch --version spatch version 1.0.8-gf4ba8df-dirty compiled with OCaml version 4.11.1 Flags passed to the configure script: --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu --program-prefix= --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-python=/usr/bin/python3 --with-menhir=/usr/bin/menhir OCaml scripting support: yes Python scripting support: yes Syntax of regular expressions: PCRE [greearb@v-f34-64 backports]$ -- Ben Greear <greearb@candelatech.com> Candela Technologies Inc http://www.candelatech.com -- To unsubscribe from this list: send the line "unsubscribe backports" in ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: backports spatch question 2021-07-01 21:40 ` Ben Greear @ 2021-07-01 21:51 ` Johannes Berg 2021-07-01 22:33 ` Ben Greear ` (2 more replies) 0 siblings, 3 replies; 20+ messages in thread From: Johannes Berg @ 2021-07-01 21:51 UTC (permalink / raw) To: Ben Greear, Hauke Mehrtens; +Cc: backports On Thu, 2021-07-01 at 14:40 -0700, Ben Greear wrote: > > [greearb@v-f34-64 backports]$ spatch --version > spatch version 1.0.8-gf4ba8df-dirty compiled with OCaml version 4.11.1 I just realized I never even tried on my system recently, I'm still on F33 and have spatch version 1.0.8-gc1dbb4f-dirty compiled with OCaml version 4.11.1 Could you try some other version? Backports says it needs "at least" 1.0.7 but perhaps only exactly that works? johannes -- To unsubscribe from this list: send the line "unsubscribe backports" in ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: backports spatch question 2021-07-01 21:51 ` Johannes Berg @ 2021-07-01 22:33 ` Ben Greear 2021-07-01 22:55 ` Ben Greear 2021-07-05 17:47 ` Ben Greear 2 siblings, 0 replies; 20+ messages in thread From: Ben Greear @ 2021-07-01 22:33 UTC (permalink / raw) To: Johannes Berg, Hauke Mehrtens; +Cc: backports On 7/1/21 2:51 PM, Johannes Berg wrote: > On Thu, 2021-07-01 at 14:40 -0700, Ben Greear wrote: >> >> [greearb@v-f34-64 backports]$ spatch --version >> spatch version 1.0.8-gf4ba8df-dirty compiled with OCaml version 4.11.1 > > > I just realized I never even tried on my system recently, I'm still on > F33 and have > > spatch version 1.0.8-gc1dbb4f-dirty compiled with OCaml version 4.11.1 > > Could you try some other version? Backports says it needs "at least" > 1.0.7 but perhaps only exactly that works? I tried compiling 1.0.8 tag from github, and it seemed to compile and install OK, but then it complains about python: [greearb@v-f34-64 backports]$ spatch --sp-file patches/0001-group-attr/0001-group_attr_class.cocci --dir /tmp/x init_defs_builtins: /usr/local/bin/../lib/coccinelle/standard.h Py.find_library: unable to find the Python library [/lib64/libpython3.9.so.1.0 returned Cannot resolve PyImport_Cleanup. ] [greearb@v-f34-64 backports]$ I'll try to reproduce my work on a Fedora-33 system, every time I tangle with spatch & friends it never goes well for me. Thanks, Ben > > johannes > -- Ben Greear <greearb@candelatech.com> Candela Technologies Inc http://www.candelatech.com -- To unsubscribe from this list: send the line "unsubscribe backports" in ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: backports spatch question 2021-07-01 21:51 ` Johannes Berg 2021-07-01 22:33 ` Ben Greear @ 2021-07-01 22:55 ` Ben Greear 2021-07-05 17:47 ` Ben Greear 2 siblings, 0 replies; 20+ messages in thread From: Ben Greear @ 2021-07-01 22:55 UTC (permalink / raw) To: Johannes Berg, Hauke Mehrtens; +Cc: backports On 7/1/21 2:51 PM, Johannes Berg wrote: > On Thu, 2021-07-01 at 14:40 -0700, Ben Greear wrote: >> >> [greearb@v-f34-64 backports]$ spatch --version >> spatch version 1.0.8-gf4ba8df-dirty compiled with OCaml version 4.11.1 > > > I just realized I never even tried on my system recently, I'm still on > F33 and have > > spatch version 1.0.8-gc1dbb4f-dirty compiled with OCaml version 4.11.1 > > Could you try some other version? Backports says it needs "at least" > 1.0.7 but perhaps only exactly that works? > > johannes > I get the same error on F33, with same version of spatch as you show above. Maybe I broke something trying to update the patches to work against my 5.13 tree (and, in case you can use any of those patches when you do your own port to 5.13, of course feel free to grab them from my tree.) If you have time to try it out: Here is my backports project tree: https://github.com/greearb/backports-project-5.13 And this is the tree I'm trying to generate from: https://github.com/greearb/linux-ct-5.13 I cloned both in ~/git and ran from ~/git/backports/: ./gentree.py --clean ~/git/linux-5.13.dev.y/ ~/tmp/backports Thanks, Ben -- Ben Greear <greearb@candelatech.com> Candela Technologies Inc http://www.candelatech.com -- To unsubscribe from this list: send the line "unsubscribe backports" in ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: backports spatch question 2021-07-01 21:51 ` Johannes Berg 2021-07-01 22:33 ` Ben Greear 2021-07-01 22:55 ` Ben Greear @ 2021-07-05 17:47 ` Ben Greear 2021-07-05 17:55 ` Johannes Berg 2 siblings, 1 reply; 20+ messages in thread From: Ben Greear @ 2021-07-05 17:47 UTC (permalink / raw) To: Johannes Berg, Hauke Mehrtens; +Cc: backports On 7/1/21 2:51 PM, Johannes Berg wrote: > On Thu, 2021-07-01 at 14:40 -0700, Ben Greear wrote: >> >> [greearb@v-f34-64 backports]$ spatch --version >> spatch version 1.0.8-gf4ba8df-dirty compiled with OCaml version 4.11.1 > > > I just realized I never even tried on my system recently, I'm still on > F33 and have > > spatch version 1.0.8-gc1dbb4f-dirty compiled with OCaml version 4.11.1 > > Could you try some other version? Backports says it needs "at least" > 1.0.7 but perhaps only exactly that works? > > johannes > I hacked through this by removing the offending spatches. Seems to have worked OK since the kernels I am using are relatively recent. I spent a while getting the mac80211 patches from owrt tweaked or otherwise resolved so that it would patch against my backports tree. But now I'm having trouble with rfkill and not sure best way forward. Is backports supposed to take care of this somehow, or do I need to go hacking in openwrt? Building backport-include/backport/autoconf.h ... done. CC [M] /home/greearb/git/tip/wlan-ap-ct-e8450-new/openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_mt7622/backports-ct-5.13.0/compat/main.o LD [M] /home/greearb/git/tip/wlan-ap-ct-e8450-new/openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_mt7622/backports-ct-5.13.0/compat/compat.o CC [M] /home/greearb/git/tip/wlan-ap-ct-e8450-new/openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_mt7622/backports-ct-5.13.0/net/wireless/core.o In file included from /home/greearb/git/tip/wlan-ap-ct-e8450-new/openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_mt7622/backports-ct-5.13.0/net/wireless/core.c:26: /home/greearb/git/tip/wlan-ap-ct-e8450-new/openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_mt7622/backports-ct-5.13.0/include/net/cfg80211.h:6653:16: warning: 'enum rfkill_hard_block_reasons' declared inside parameter list will not be visible outside of this definition or declaration enum rfkill_hard_block_reasons reason); ^~~~~~~~~~~~~~~~~~~~~~~~~ /home/greearb/git/tip/wlan-ap-ct-e8450-new/openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_mt7622/backports-ct-5.13.0/include/net/cfg80211.h: In function 'wiphy_rfkill_set_hw_state': /home/greearb/git/tip/wlan-ap-ct-e8450-new/openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_mt7622/backports-ct-5.13.0/include/net/cfg80211.h:6658:7: error: 'RFKILL_HARD_BLOCK_SIGNAL' undeclared (first use in this function) RFKILL_HARD_BLOCK_SIGNAL); ^~~~~~~~~~~~~~~~~~~~~~~~ /home/greearb/git/tip/wlan-ap-ct-e8450-new/openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_mt7622/backports-ct-5.13.0/include/net/cfg80211.h:6658:7: note: each undeclared identifier is reported only once for each function it appears in /home/greearb/git/tip/wlan-ap-ct-e8450-new/openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_mt7622/backports-ct-5.13.0/include/net/cfg80211.h:6658:7: error: type of formal parameter 3 is incomplete /home/greearb/git/tip/wlan-ap-ct-e8450-new/openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_mt7622/backports-ct-5.13.0/net/wireless/core.c: At top level: /home/greearb/git/tip/wlan-ap-ct-e8450-new/openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_mt7622/backports-ct-5.13.0/net/wireless/core.c:1125:16: warning: 'enum rfkill_hard_block_reasons' declared inside parameter list will not be visible outside of this definition or declaration enum rfkill_hard_block_reasons reason) ^~~~~~~~~~~~~~~~~~~~~~~~~ /home/greearb/git/tip/wlan-ap-ct-e8450-new/openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_mt7622/backports-ct-5.13.0/net/wireless/core.c:1125:42: error: parameter 3 ('reason') has incomplete type enum rfkill_hard_block_reasons reason) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~ /home/greearb/git/tip/wlan-ap-ct-e8450-new/openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_mt7622/backports-ct-5.13.0/net/wireless/core.c: In function 'wiphy_rfkill_set_hw_state_reason': /home/greearb/git/tip/wlan-ap-ct-e8450-new/openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_mt7622/backports-ct-5.13.0/net/wireless/core.c:1129:6: error: implicit declaration of function 'rfkill_set_hw_state_reason'; did you mean 'wiphy_rfkill_set_hw_state_reason'? [-Werror=implicit-function-declaration] if (rfkill_set_hw_state_reason(rdev->rfkill, blocked, reason)) ^~~~~~~~~~~~~~~~~~~~~~~~~~ wiphy_rfkill_set_hw_state_reason cc1: some warnings being treated as errors make[9]: *** [scripts/Makefile.build:279: /home/greearb/git/tip/wlan-ap-ct-e8450-new/openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_mt7622/backports-ct-5.13.0/net/wireless/core.o] Error 1 make[8]: *** [scripts/Makefile.build:496: /home/greearb/git/tip/wlan-ap-ct-e8450-new/openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_mt7622/backports-ct-5.13.0/net/wireless] Error 2 make[7]: *** [Makefile:1810: /home/greearb/git/tip/wlan-ap-ct-e8450-new/openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_mt7622/backports-ct-5.13.0] Error 2 make[6]: *** [Makefile.build:13: modules] Error 2 make[5]: *** [Makefile.real:93: modules] Error 2 make[4]: *** [Makefile:121: modules] Error 2 make[4]: Leaving directory '/home/greearb/git/tip/wlan-ap-ct-e8450-new/openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_mt7622/backports-ct-5.13.0' make[3]: *** [Makefile:561: /home/greearb/git/tip/wlan-ap-ct-e8450-new/openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_mt7622/backports-ct-5.13.0/.built] Error 2 make[3]: Leaving directory '/home/greearb/git/tip/wlan-ap-ct-e8450-new/openwrt/package/kernel/mac80211' time: package/kernel/mac80211/compile#3.68#1.38#4.72 ERROR: package/kernel/mac80211 failed to build. make[2]: *** [package/Makefile:114: package/kernel/mac80211/compile] Error 1 make[2]: Leaving directory '/home/greearb/git/tip/wlan-ap-ct-e8450-new/openwrt' make[1]: *** [package/Makefile:108: /home/greearb/git/tip/wlan-ap-ct-e8450-new/openwrt/staging_dir/target-aarch64_cortex-a53_musl/stamp/.package_compile] Error 2 make[1]: Leaving directory '/home/greearb/git/tip/wlan-ap-ct-e8450-new/openwrt' make: *** [/home/greearb/git/tip/wlan-ap-ct-e8450-new/openwrt/include/toplevel.mk:230: world] Error 2 Compilation exited abnormally with code 2 at Mon Jul 5 10:21:42 Thanks, Ben -- Ben Greear <greearb@candelatech.com> Candela Technologies Inc http://www.candelatech.com -- To unsubscribe from this list: send the line "unsubscribe backports" in ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: backports spatch question 2021-07-05 17:47 ` Ben Greear @ 2021-07-05 17:55 ` Johannes Berg 2021-07-05 19:10 ` Ben Greear 0 siblings, 1 reply; 20+ messages in thread From: Johannes Berg @ 2021-07-05 17:55 UTC (permalink / raw) To: Ben Greear, Hauke Mehrtens; +Cc: backports On Mon, 2021-07-05 at 10:47 -0700, Ben Greear wrote: > On 7/1/21 2:51 PM, Johannes Berg wrote: > > On Thu, 2021-07-01 at 14:40 -0700, Ben Greear wrote: > > > > > > [greearb@v-f34-64 backports]$ spatch --version > > > spatch version 1.0.8-gf4ba8df-dirty compiled with OCaml version 4.11.1 > > > > > > I just realized I never even tried on my system recently, I'm still on > > F33 and have > > > > spatch version 1.0.8-gc1dbb4f-dirty compiled with OCaml version 4.11.1 > > > > Could you try some other version? Backports says it needs "at least" > > 1.0.7 but perhaps only exactly that works? > > > > johannes > > > > I hacked through this by removing the offending spatches. Seems to have worked OK > since the kernels I am using are relatively recent. > > I spent a while getting the mac80211 patches from owrt tweaked or otherwise > resolved so that it would patch against my backports tree. > > But now I'm having trouble with rfkill and not sure best way forward. Is backports > supposed to take care of this somehow, or do I need to go hacking in openwrt? You need this bit in backport-include/linux/rfkill.h, not sure why it's not there yet: #if LINUX_VERSION_IS_LESS(5,11,0) /* This should come from uapi/linux/rfkill.h, but it was much easier * to do it this way. */ enum rfkill_hard_block_reasons { RFKILL_HARD_BLOCK_SIGNAL = 1 << 0, RFKILL_HARD_BLOCK_NOT_OWNER = 1 << 1, }; static inline bool rfkill_set_hw_state_reason(struct rfkill *rfkill, bool blocked, unsigned long reason) { return rfkill_set_hw_state(rfkill, blocked); } #endif /* 5.11 */ johannes -- To unsubscribe from this list: send the line "unsubscribe backports" in ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: backports spatch question 2021-07-05 17:55 ` Johannes Berg @ 2021-07-05 19:10 ` Ben Greear 2021-07-05 19:14 ` Johannes Berg 0 siblings, 1 reply; 20+ messages in thread From: Ben Greear @ 2021-07-05 19:10 UTC (permalink / raw) To: Johannes Berg, Hauke Mehrtens; +Cc: backports On 7/5/21 10:55 AM, Johannes Berg wrote: > On Mon, 2021-07-05 at 10:47 -0700, Ben Greear wrote: >> On 7/1/21 2:51 PM, Johannes Berg wrote: >>> On Thu, 2021-07-01 at 14:40 -0700, Ben Greear wrote: >>>> >>>> [greearb@v-f34-64 backports]$ spatch --version >>>> spatch version 1.0.8-gf4ba8df-dirty compiled with OCaml version 4.11.1 >>> >>> >>> I just realized I never even tried on my system recently, I'm still on >>> F33 and have >>> >>> spatch version 1.0.8-gc1dbb4f-dirty compiled with OCaml version 4.11.1 >>> >>> Could you try some other version? Backports says it needs "at least" >>> 1.0.7 but perhaps only exactly that works? >>> >>> johannes >>> >> >> I hacked through this by removing the offending spatches. Seems to have worked OK >> since the kernels I am using are relatively recent. >> >> I spent a while getting the mac80211 patches from owrt tweaked or otherwise >> resolved so that it would patch against my backports tree. >> >> But now I'm having trouble with rfkill and not sure best way forward. Is backports >> supposed to take care of this somehow, or do I need to go hacking in openwrt? > > You need this bit in backport-include/linux/rfkill.h, not sure why it's > not there yet: > > #if LINUX_VERSION_IS_LESS(5,11,0) > > /* This should come from uapi/linux/rfkill.h, but it was much easier > * to do it this way. > */ > enum rfkill_hard_block_reasons { > RFKILL_HARD_BLOCK_SIGNAL = 1 << 0, > RFKILL_HARD_BLOCK_NOT_OWNER = 1 << 1, > }; > > static inline bool rfkill_set_hw_state_reason(struct rfkill *rfkill, > bool blocked, unsigned > long reason) > { > return rfkill_set_hw_state(rfkill, blocked); > } > > #endif /* 5.11 */ > > > johannes > I added that patch to the bottom of the file, just above the final #endif It still fails to build. I added invalid tokens (BUGME2, BUGME) to the file, and that does show that it is being included in some places, but not from cfg80211.h I guess: make -C "/home/greearb/git/tip/wlan-ap-ct-e8450-new/openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_mt7622/backports-ct-5.13.0" HOSTCFLAGS="-O2 -I/home/greearb/git/tip/wlan-ap-ct-e8450-new/openwrt/staging_dir/host/include -I/home/greearb/git/tip/wlan-ap-ct-e8450-new/openwrt/staging_dir/hostpkg/include -I/home/greearb/git/tip/wlan-ap-ct-e8450-new/openwrt/staging_dir/target-aarch64_cortex-a53_musl/host/include -Wall -Wmissing-prototypes -Wstrict-prototypes" CROSS_COMPILE="aarch64-openwrt-linux-musl-" ARCH="arm64" KBUILD_HAVE_NLS=no KBUILD_BUILD_USER="" KBUILD_BUILD_HOST="" KBUILD_BUILD_TIMESTAMP="Mon Jul 5 17:34:30 2021" KBUILD_BUILD_VERSION="0" HOST_LOADLIBES="-L/home/greearb/git/tip/wlan-ap-ct-e8450-new/openwrt/staging_dir/host/lib" KBUILD_HOSTLDLIBS="-L/home/greearb/git/tip/wlan-ap-ct-e8450-new/openwrt/staging_dir/host/lib" CONFIG_SHELL="bash" V='' cmd_syscalls= KBUILD_EXTRA_SYMBOLS="/home/greearb/git/tip/wlan-ap-ct-e8450-new/openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_mt7622/symvers/gpio-button-hotplug.symvers" KERNELRELEASE=5.10.27 EXTRA_CFLAGS="-I/home/greearb/git/tip/wlan-ap-ct-e8450-new/openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_mt7622/backports-ct-5.13.0/include " KLIB_BUILD="/home/greearb/git/tip/wlan-ap-ct-e8450-new/openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_mt7622/linux-5.10.27" MODPROBE=true KLIB=/lib/modules/5.10.27 KERNEL_SUBLEVEL=10 KBUILD_LDFLAGS_MODULE_PREREQ= modules make[4]: Entering directory '/home/greearb/git/tip/wlan-ap-ct-e8450-new/openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_mt7622/backports-ct-5.13.0' make[5]: 'Kconfig.versions' is up to date. make[7]: 'Kconfig.versions' is up to date. make[8]: 'conf' is up to date. boolean symbol CRYPTO_LIB_ARC4 tested for 'm'? test forced to 'n' # # configuration written to .config # Building backport-include/backport/autoconf.h ... done. CC [M] /home/greearb/git/tip/wlan-ap-ct-e8450-new/openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_mt7622/backports-ct-5.13.0/net/wireless/core.o In file included from /home/greearb/git/tip/wlan-ap-ct-e8450-new/openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_mt7622/backports-ct-5.13.0/net/wireless/core.c:26: /home/greearb/git/tip/wlan-ap-ct-e8450-new/openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_mt7622/backports-ct-5.13.0/include/net/cfg80211.h:6653:16: warning: 'enum rfkill_hard_block_reasons' declared inside parameter list will not be visible outside of this definition or declaration enum rfkill_hard_block_reasons reason); ^~~~~~~~~~~~~~~~~~~~~~~~~ /home/greearb/git/tip/wlan-ap-ct-e8450-new/openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_mt7622/backports-ct-5.13.0/include/net/cfg80211.h: In function 'wiphy_rfkill_set_hw_state': /home/greearb/git/tip/wlan-ap-ct-e8450-new/openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_mt7622/backports-ct-5.13.0/include/net/cfg80211.h:6658:7: error: 'RFKILL_HARD_BLOCK_SIGNAL' undeclared (first use in this function) RFKILL_HARD_BLOCK_SIGNAL); ^~~~~~~~~~~~~~~~~~~~~~~~ /home/greearb/git/tip/wlan-ap-ct-e8450-new/openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_mt7622/backports-ct-5.13.0/include/net/cfg80211.h:6658:7: note: each undeclared identifier is reported only once for each function it appears in /home/greearb/git/tip/wlan-ap-ct-e8450-new/openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_mt7622/backports-ct-5.13.0/include/net/cfg80211.h:6658:7: error: type of formal parameter 3 is incomplete In file included from /home/greearb/git/tip/wlan-ap-ct-e8450-new/openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_mt7622/backports-ct-5.13.0/net/wireless/core.h:14, from /home/greearb/git/tip/wlan-ap-ct-e8450-new/openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_mt7622/backports-ct-5.13.0/net/wireless/nl80211.h:9, from /home/greearb/git/tip/wlan-ap-ct-e8450-new/openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_mt7622/backports-ct-5.13.0/net/wireless/core.c:27: /home/greearb/git/tip/wlan-ap-ct-e8450-new/openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_mt7622/backports-ct-5.13.0/backport-include/linux/rfkill.h: At top level: /home/greearb/git/tip/wlan-ap-ct-e8450-new/openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_mt7622/backports-ct-5.13.0/backport-include/linux/rfkill.h:173:1: error: unknown type name 'BUGME2'; did you mean 'BUG'? BUGME2 ^~~~~~ BUG /home/greearb/git/tip/wlan-ap-ct-e8450-new/openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_mt7622/backports-ct-5.13.0/backport-include/linux/rfkill.h:175:6: error: expected ';' before 'enum' BUGME ^ ; /home/greearb/git/tip/wlan-ap-ct-e8450-new/openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_mt7622/backports-ct-5.13.0/backport-include/linux/rfkill.h:179:1: enum rfkill_hard_block_reasons { ~~~~ /home/greearb/git/tip/wlan-ap-ct-e8450-new/openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_mt7622/backports-ct-5.13.0/net/wireless/core.c:1124:6: error: conflicting types for 'wiphy_rfkill_set_hw_state_reason' void wiphy_rfkill_set_hw_state_reason(struct wiphy *wiphy, bool blocked, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from /home/greearb/git/tip/wlan-ap-ct-e8450-new/openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_mt7622/backports-ct-5.13.0/net/wireless/core.c:26: /home/greearb/git/tip/wlan-ap-ct-e8450-new/openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_mt7622/backports-ct-5.13.0/include/net/cfg80211.h:6652:6: note: previous declaration of 'wiphy_rfkill_set_hw_state_reason' was here void wiphy_rfkill_set_hw_state_reason(struct wiphy *wiphy, bool blocked, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from /home/greearb/git/tip/wlan-ap-ct-e8450-new/openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_mt7622/backports-ct-5.13.0/backport-include/linux/export.h:7, from ./include/linux/linkage.h:7, from ./include/linux/kernel.h:8, from /home/greearb/git/tip/wlan-ap-ct-e8450-new/openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_mt7622/backports-ct-5.13.0/backport-include/linux/kernel.h:3, from ./include/linux/uio.h:8, from ./include/linux/socket.h:8, from /home/greearb/git/tip/wlan-ap-ct-e8450-new/openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_mt7622/backports-ct-5.13.0/backport-include/linux/socket.h:3, from ./include/uapi/linux/if.h:25, from /home/greearb/git/tip/wlan-ap-ct-e8450-new/openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_mt7622/backports-ct-5.13.0/net/wireless/core.c:13: /home/greearb/git/tip/wlan-ap-ct-e8450-new/openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_mt7622/backports-ct-5.13.0/net/wireless/core.c:1132:15: error: conflicting types for 'wiphy_rfkill_set_hw_state_reason' EXPORT_SYMBOL(wiphy_rfkill_set_hw_state_reason); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./include/linux/export.h:104:21: note: in definition of macro '___EXPORT_SYMBOL' extern typeof(sym) sym; \ ^~~ ./include/linux/export.h:161:34: note: in expansion of macro '__EXPORT_SYMBOL' #define _EXPORT_SYMBOL(sym, sec) __EXPORT_SYMBOL(sym, sec, "") ^~~~~~~~~~~~~~~ ./include/linux/export.h:164:29: note: in expansion of macro '_EXPORT_SYMBOL' #define EXPORT_SYMBOL(sym) _EXPORT_SYMBOL(sym, "") ^~~~~~~~~~~~~~ /home/greearb/git/tip/wlan-ap-ct-e8450-new/openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_mt7622/backports-ct-5.13.0/net/wireless/core.c:1132:1: note: in expansion of macro 'EXPORT_SYMBOL' EXPORT_SYMBOL(wiphy_rfkill_set_hw_state_reason); ^~~~~~~~~~~~~ In file included from /home/greearb/git/tip/wlan-ap-ct-e8450-new/openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_mt7622/backports-ct-5.13.0/net/wireless/core.c:26: /home/greearb/git/tip/wlan-ap-ct-e8450-new/openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_mt7622/backports-ct-5.13.0/include/net/cfg80211.h:6652:6: note: previous declaration of 'wiphy_rfkill_set_hw_state_reason' was here void wiphy_rfkill_set_hw_state_reason(struct wiphy *wiphy, bool blocked, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ make[9]: *** [scripts/Makefile.build:279: /home/greearb/git/tip/wlan-ap-ct-e8450-new/openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_mt7622/backports-ct-5.13.0/net/wireless/core.o] Error 1 make[8]: *** [scripts/Makefile.build:496: /home/greearb/git/tip/wlan-ap-ct-e8450-new/openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_mt7622/backports-ct-5.13.0/net/wireless] Error 2 make[7]: *** [Makefile:1810: /home/greearb/git/tip/wlan-ap-ct-e8450-new/openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_mt7622/backports-ct-5.13.0] Error 2 make[6]: *** [Makefile.build:13: modules] Error 2 make[5]: *** [Makefile.real:93: modules] Error 2 make[4]: *** [Makefile:121: modules] Error 2 make[4]: Leaving directory '/home/greearb/git/tip/wlan-ap-ct-e8450-new/openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_mt7622/backports-ct-5.13.0' make[3]: *** [Makefile:561: /home/greearb/git/tip/wlan-ap-ct-e8450-new/openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_mt7622/backports-ct-5.13.0/.built] Error 2 make[3]: Leaving directory '/home/greearb/git/tip/wlan-ap-ct-e8450-new/openwrt/package/kernel/mac80211' time: package/kernel/mac80211/compile#0.97#0.43#1.35 ERROR: package/kernel/mac80211 failed to build. make[2]: *** [package/Makefile:114: package/kernel/mac80211/compile] Error 1 make[2]: Leaving directory '/home/greearb/git/tip/wlan-ap-ct-e8450-new/openwrt' make[1]: *** [package/Makefile:108: /home/greearb/git/tip/wlan-ap-ct-e8450-new/openwrt/staging_dir/target-aarch64_cortex-a53_musl/stamp/.package_compile] Error 2 make[1]: Leaving directory '/home/greearb/git/tip/wlan-ap-ct-e8450-new/openwrt' make: *** [/home/greearb/git/tip/wlan-ap-ct-e8450-new/openwrt/include/toplevel.mk:230: world] Error 2 Compilation exited abnormally with code 2 at Mon Jul 5 12:07:49 Thanks, Ben -- Ben Greear <greearb@candelatech.com> Candela Technologies Inc http://www.candelatech.com -- To unsubscribe from this list: send the line "unsubscribe backports" in ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: backports spatch question 2021-07-05 19:10 ` Ben Greear @ 2021-07-05 19:14 ` Johannes Berg 2021-07-05 19:17 ` Ben Greear 0 siblings, 1 reply; 20+ messages in thread From: Johannes Berg @ 2021-07-05 19:14 UTC (permalink / raw) To: Ben Greear, Hauke Mehrtens; +Cc: backports On Mon, 2021-07-05 at 12:10 -0700, Ben Greear wrote: > On 7/5/21 10:55 AM, Johannes Berg wrote: > > On Mon, 2021-07-05 at 10:47 -0700, Ben Greear wrote: > > > On 7/1/21 2:51 PM, Johannes Berg wrote: > > > > On Thu, 2021-07-01 at 14:40 -0700, Ben Greear wrote: > > > > > > > > > > [greearb@v-f34-64 backports]$ spatch --version > > > > > spatch version 1.0.8-gf4ba8df-dirty compiled with OCaml version 4.11.1 > > > > > > > > > > > > I just realized I never even tried on my system recently, I'm still on > > > > F33 and have > > > > > > > > spatch version 1.0.8-gc1dbb4f-dirty compiled with OCaml version 4.11.1 > > > > > > > > Could you try some other version? Backports says it needs "at least" > > > > 1.0.7 but perhaps only exactly that works? > > > > > > > > johannes > > > > > > > > > > I hacked through this by removing the offending spatches. Seems to have worked OK > > > since the kernels I am using are relatively recent. > > > > > > I spent a while getting the mac80211 patches from owrt tweaked or otherwise > > > resolved so that it would patch against my backports tree. > > > > > > But now I'm having trouble with rfkill and not sure best way forward. Is backports > > > supposed to take care of this somehow, or do I need to go hacking in openwrt? > > > > You need this bit in backport-include/linux/rfkill.h, not sure why it's > > not there yet: > > > > #if LINUX_VERSION_IS_LESS(5,11,0) > > > > /* This should come from uapi/linux/rfkill.h, but it was much easier > > * to do it this way. > > */ > > enum rfkill_hard_block_reasons { > > RFKILL_HARD_BLOCK_SIGNAL = 1 << 0, > > RFKILL_HARD_BLOCK_NOT_OWNER = 1 << 1, > > }; > > > > static inline bool rfkill_set_hw_state_reason(struct rfkill *rfkill, > > bool blocked, unsigned > > long reason) > > { > > return rfkill_set_hw_state(rfkill, blocked); > > } > > > > #endif /* 5.11 */ > > > > > > johannes > > > > I added that patch to the bottom of the file, just above the final #endif Well I guess it needs to be at the beginning in the first existing ifdef block. https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/backport-iwlwifi.git/tree/backport-include/linux/rfkill.h johannes -- To unsubscribe from this list: send the line "unsubscribe backports" in ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: backports spatch question 2021-07-05 19:14 ` Johannes Berg @ 2021-07-05 19:17 ` Ben Greear 2021-07-05 19:19 ` Johannes Berg 0 siblings, 1 reply; 20+ messages in thread From: Ben Greear @ 2021-07-05 19:17 UTC (permalink / raw) To: Johannes Berg, Hauke Mehrtens; +Cc: backports On 7/5/21 12:14 PM, Johannes Berg wrote: > On Mon, 2021-07-05 at 12:10 -0700, Ben Greear wrote: >> On 7/5/21 10:55 AM, Johannes Berg wrote: >>> On Mon, 2021-07-05 at 10:47 -0700, Ben Greear wrote: >>>> On 7/1/21 2:51 PM, Johannes Berg wrote: >>>>> On Thu, 2021-07-01 at 14:40 -0700, Ben Greear wrote: >>>>>> >>>>>> [greearb@v-f34-64 backports]$ spatch --version >>>>>> spatch version 1.0.8-gf4ba8df-dirty compiled with OCaml version 4.11.1 >>>>> >>>>> >>>>> I just realized I never even tried on my system recently, I'm still on >>>>> F33 and have >>>>> >>>>> spatch version 1.0.8-gc1dbb4f-dirty compiled with OCaml version 4.11.1 >>>>> >>>>> Could you try some other version? Backports says it needs "at least" >>>>> 1.0.7 but perhaps only exactly that works? >>>>> >>>>> johannes >>>>> >>>> >>>> I hacked through this by removing the offending spatches. Seems to have worked OK >>>> since the kernels I am using are relatively recent. >>>> >>>> I spent a while getting the mac80211 patches from owrt tweaked or otherwise >>>> resolved so that it would patch against my backports tree. >>>> >>>> But now I'm having trouble with rfkill and not sure best way forward. Is backports >>>> supposed to take care of this somehow, or do I need to go hacking in openwrt? >>> >>> You need this bit in backport-include/linux/rfkill.h, not sure why it's >>> not there yet: >>> >>> #if LINUX_VERSION_IS_LESS(5,11,0) >>> >>> /* This should come from uapi/linux/rfkill.h, but it was much easier >>> * to do it this way. >>> */ >>> enum rfkill_hard_block_reasons { >>> RFKILL_HARD_BLOCK_SIGNAL = 1 << 0, >>> RFKILL_HARD_BLOCK_NOT_OWNER = 1 << 1, >>> }; >>> >>> static inline bool rfkill_set_hw_state_reason(struct rfkill *rfkill, >>> bool blocked, unsigned >>> long reason) >>> { >>> return rfkill_set_hw_state(rfkill, blocked); >>> } >>> >>> #endif /* 5.11 */ >>> >>> >>> johannes >>> >> >> I added that patch to the bottom of the file, just above the final #endif > > Well I guess it needs to be at the beginning in the first existing ifdef > block. > > https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/backport-iwlwifi.git/tree/backport-include/linux/rfkill.h > > johannes > Did you test it? Because that should be logically identical to what I tried if I read this file properly: [greearb@v-f34-64 backports]$ git show commit d3480ef5f9024dfe712700832473c90c577d8ca5 (HEAD -> master) Author: Ben Greear <greearb@candelatech.com> Date: Mon Jul 5 11:12:14 2021 -0700 Fix rfkill for earlier than 5.11 kernels From Johannes Berg <johannes@sipsolutions.net> Signed-off-by: Ben Greear <greearb@candelatech.com> diff --git a/backport/backport-include/linux/rfkill.h b/backport/backport-include/linux/rfkill.h index 99015af7..c4aa2bd2 100644 --- a/backport/backport-include/linux/rfkill.h +++ b/backport/backport-include/linux/rfkill.h @@ -164,4 +164,23 @@ static inline bool backport_rfkill_blocked(struct rfkill *rfkill) #define rfkill_blocked backport_rfkill_blocked #endif +#if LINUX_VERSION_IS_LESS(5,11,0) + +/* This should come from uapi/linux/rfkill.h, but it was much easier + * to do it this way. + */ +enum rfkill_hard_block_reasons { + RFKILL_HARD_BLOCK_SIGNAL = 1 << 0, + RFKILL_HARD_BLOCK_NOT_OWNER = 1 << 1, +}; + +static inline bool rfkill_set_hw_state_reason(struct rfkill *rfkill, + bool blocked, unsigned +long reason) +{ + return rfkill_set_hw_state(rfkill, blocked); +} + +#endif /* 5.11 */ + #endif -- Ben Greear <greearb@candelatech.com> Candela Technologies Inc http://www.candelatech.com -- To unsubscribe from this list: send the line "unsubscribe backports" in ^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: backports spatch question 2021-07-05 19:17 ` Ben Greear @ 2021-07-05 19:19 ` Johannes Berg 2021-07-05 19:26 ` Ben Greear 0 siblings, 1 reply; 20+ messages in thread From: Johannes Berg @ 2021-07-05 19:19 UTC (permalink / raw) To: Ben Greear, Hauke Mehrtens; +Cc: backports On Mon, 2021-07-05 at 12:17 -0700, Ben Greear wrote: > > Did you test it? > Yes, pretty sure we do it basically all the time. We don't have kernels that new yet in most of our test setups. > Because that should be logically identical to what I tried if I read this file properly: Actually, your version might be more correct than ours ... I dunno. I note we also have an <linux/rfkill.h> include in cfg80211.h, but that should be there upstream too, so not sure. johannes -- To unsubscribe from this list: send the line "unsubscribe backports" in ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: backports spatch question 2021-07-05 19:19 ` Johannes Berg @ 2021-07-05 19:26 ` Ben Greear 2021-07-05 19:26 ` Johannes Berg 0 siblings, 1 reply; 20+ messages in thread From: Ben Greear @ 2021-07-05 19:26 UTC (permalink / raw) To: Johannes Berg, Hauke Mehrtens; +Cc: backports On 7/5/21 12:19 PM, Johannes Berg wrote: > On Mon, 2021-07-05 at 12:17 -0700, Ben Greear wrote: >> >> Did you test it? >> > > Yes, pretty sure we do it basically all the time. We don't have kernels > that new yet in most of our test setups. > >> Because that should be logically identical to what I tried if I read this file properly: > > Actually, your version might be more correct than ours ... > > I dunno. I note we also have an <linux/rfkill.h> include in cfg80211.h, > but that should be there upstream too, so not sure. There are a lot of rfkill.h files, what logic makes the backports code include the specific backport/backport-include/linux/rfkill.h file? I suspect that isn't working for the cfg80211.h file for whatever reason. Thanks, Ben > > johannes > -- Ben Greear <greearb@candelatech.com> Candela Technologies Inc http://www.candelatech.com -- To unsubscribe from this list: send the line "unsubscribe backports" in ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: backports spatch question 2021-07-05 19:26 ` Ben Greear @ 2021-07-05 19:26 ` Johannes Berg 2021-07-05 19:32 ` Ben Greear 0 siblings, 1 reply; 20+ messages in thread From: Johannes Berg @ 2021-07-05 19:26 UTC (permalink / raw) To: Ben Greear, Hauke Mehrtens; +Cc: backports On Mon, 2021-07-05 at 12:26 -0700, Ben Greear wrote: > On 7/5/21 12:19 PM, Johannes Berg wrote: > > On Mon, 2021-07-05 at 12:17 -0700, Ben Greear wrote: > > > > > > Did you test it? > > > > > > > Yes, pretty sure we do it basically all the time. We don't have kernels > > that new yet in most of our test setups. > > > > > Because that should be logically identical to what I tried if I read this file properly: > > > > Actually, your version might be more correct than ours ... > > > > I dunno. I note we also have an <linux/rfkill.h> include in cfg80211.h, > > but that should be there upstream too, so not sure. > > There are a lot of rfkill.h files, what logic makes the backports code include the specific > backport/backport-include/linux/rfkill.h file? I suspect that isn't working for the cfg80211.h > file for whatever reason. It's just an additional -I flag on the compiler command line, or - isystem or something like that. johannes -- To unsubscribe from this list: send the line "unsubscribe backports" in ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: backports spatch question 2021-07-05 19:26 ` Johannes Berg @ 2021-07-05 19:32 ` Ben Greear 2021-07-05 19:32 ` Johannes Berg 0 siblings, 1 reply; 20+ messages in thread From: Ben Greear @ 2021-07-05 19:32 UTC (permalink / raw) To: Johannes Berg, Hauke Mehrtens; +Cc: backports On 7/5/21 12:26 PM, Johannes Berg wrote: > On Mon, 2021-07-05 at 12:26 -0700, Ben Greear wrote: >> On 7/5/21 12:19 PM, Johannes Berg wrote: >>> On Mon, 2021-07-05 at 12:17 -0700, Ben Greear wrote: >>>> >>>> Did you test it? >>>> >>> >>> Yes, pretty sure we do it basically all the time. We don't have kernels >>> that new yet in most of our test setups. >>> >>>> Because that should be logically identical to what I tried if I read this file properly: >>> >>> Actually, your version might be more correct than ours ... >>> >>> I dunno. I note we also have an <linux/rfkill.h> include in cfg80211.h, >>> but that should be there upstream too, so not sure. >> >> There are a lot of rfkill.h files, what logic makes the backports code include the specific >> backport/backport-include/linux/rfkill.h file? I suspect that isn't working for the cfg80211.h >> file for whatever reason. > > It's just an additional -I flag on the compiler command line, or - > isystem or something like that. > > johannes > my cfg80211.h shows this line: #include <uapi/linux/rfkill.h> As does stock 5.13 upstream kernel. So I guess that would not include the hacked backport/backport-include/linux/rfkill.h I can probably hack around that one way or another, but suggestions for proper fix? Thanks, Ben -- Ben Greear <greearb@candelatech.com> Candela Technologies Inc http://www.candelatech.com -- To unsubscribe from this list: send the line "unsubscribe backports" in ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: backports spatch question 2021-07-05 19:32 ` Ben Greear @ 2021-07-05 19:32 ` Johannes Berg 2021-07-05 19:38 ` Ben Greear ` (2 more replies) 0 siblings, 3 replies; 20+ messages in thread From: Johannes Berg @ 2021-07-05 19:32 UTC (permalink / raw) To: Ben Greear, Hauke Mehrtens; +Cc: backports On Mon, 2021-07-05 at 12:32 -0700, Ben Greear wrote: > On 7/5/21 12:26 PM, Johannes Berg wrote: > > On Mon, 2021-07-05 at 12:26 -0700, Ben Greear wrote: > > > On 7/5/21 12:19 PM, Johannes Berg wrote: > > > > On Mon, 2021-07-05 at 12:17 -0700, Ben Greear wrote: > > > > > > > > > > Did you test it? > > > > > > > > > > > > > Yes, pretty sure we do it basically all the time. We don't have kernels > > > > that new yet in most of our test setups. > > > > > > > > > Because that should be logically identical to what I tried if I read this file properly: > > > > > > > > Actually, your version might be more correct than ours ... > > > > > > > > I dunno. I note we also have an <linux/rfkill.h> include in cfg80211.h, > > > > but that should be there upstream too, so not sure. > > > > > > There are a lot of rfkill.h files, what logic makes the backports code include the specific > > > backport/backport-include/linux/rfkill.h file? I suspect that isn't working for the cfg80211.h > > > file for whatever reason. > > > > It's just an additional -I flag on the compiler command line, or - > > isystem or something like that. > > > > johannes > > > > my cfg80211.h shows this line: > > #include <uapi/linux/rfkill.h> Not a later <linux/rfkill.h> line? We have one like that in our version ... I guess we should really only have the <linux/rfkill.h> one, but since we want the function declaration, we really ought to have that? johannes -- To unsubscribe from this list: send the line "unsubscribe backports" in ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: backports spatch question 2021-07-05 19:32 ` Johannes Berg @ 2021-07-05 19:38 ` Ben Greear 2021-07-05 20:07 ` Ben Greear 2021-07-05 20:30 ` Ben Greear 2 siblings, 0 replies; 20+ messages in thread From: Ben Greear @ 2021-07-05 19:38 UTC (permalink / raw) To: Johannes Berg, Hauke Mehrtens; +Cc: backports On 7/5/21 12:32 PM, Johannes Berg wrote: > On Mon, 2021-07-05 at 12:32 -0700, Ben Greear wrote: >> On 7/5/21 12:26 PM, Johannes Berg wrote: >>> On Mon, 2021-07-05 at 12:26 -0700, Ben Greear wrote: >>>> On 7/5/21 12:19 PM, Johannes Berg wrote: >>>>> On Mon, 2021-07-05 at 12:17 -0700, Ben Greear wrote: >>>>>> >>>>>> Did you test it? >>>>>> >>>>> >>>>> Yes, pretty sure we do it basically all the time. We don't have kernels >>>>> that new yet in most of our test setups. >>>>> >>>>>> Because that should be logically identical to what I tried if I read this file properly: >>>>> >>>>> Actually, your version might be more correct than ours ... >>>>> >>>>> I dunno. I note we also have an <linux/rfkill.h> include in cfg80211.h, >>>>> but that should be there upstream too, so not sure. >>>> >>>> There are a lot of rfkill.h files, what logic makes the backports code include the specific >>>> backport/backport-include/linux/rfkill.h file? I suspect that isn't working for the cfg80211.h >>>> file for whatever reason. >>> >>> It's just an additional -I flag on the compiler command line, or - >>> isystem or something like that. >>> >>> johannes >>> >> >> my cfg80211.h shows this line: >> >> #include <uapi/linux/rfkill.h> > > Not a later <linux/rfkill.h> line? We have one like that in our version > ... > > I guess we should really only have the <linux/rfkill.h> one, but since > we want the function declaration, we really ought to have that? > > johannes > > This is from Linus' 5.13 tree. My grep sucks, but gets the job done. [greearb@ben-dt4 configs]$ grep rfkill\.h ~/git/linux-2.6/include/net/cfg80211.h #include <uapi/linux/rfkill.h> * functions to adjust rfkill hw state * @reason: one of reasons in &enum rfkill_hard_block_reasons enum rfkill_hard_block_reasons reason); Is 'your version' of the kernel public somewhere? I can try changing the cfg80211.h in the upstream kernel that I am generating the backports package from, but that will not help anyone else trying to create a backports package from a stock 5.13 kernel... Thanks, Ben -- Ben Greear <greearb@candelatech.com> Candela Technologies Inc http://www.candelatech.com -- To unsubscribe from this list: send the line "unsubscribe backports" in ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: backports spatch question 2021-07-05 19:32 ` Johannes Berg 2021-07-05 19:38 ` Ben Greear @ 2021-07-05 20:07 ` Ben Greear 2021-07-05 20:30 ` Ben Greear 2 siblings, 0 replies; 20+ messages in thread From: Ben Greear @ 2021-07-05 20:07 UTC (permalink / raw) To: Johannes Berg, Hauke Mehrtens; +Cc: backports On 7/5/21 12:32 PM, Johannes Berg wrote: > On Mon, 2021-07-05 at 12:32 -0700, Ben Greear wrote: >> On 7/5/21 12:26 PM, Johannes Berg wrote: >>> On Mon, 2021-07-05 at 12:26 -0700, Ben Greear wrote: >>>> On 7/5/21 12:19 PM, Johannes Berg wrote: >>>>> On Mon, 2021-07-05 at 12:17 -0700, Ben Greear wrote: >>>>>> >>>>>> Did you test it? >>>>>> >>>>> >>>>> Yes, pretty sure we do it basically all the time. We don't have kernels >>>>> that new yet in most of our test setups. >>>>> >>>>>> Because that should be logically identical to what I tried if I read this file properly: >>>>> >>>>> Actually, your version might be more correct than ours ... >>>>> >>>>> I dunno. I note we also have an <linux/rfkill.h> include in cfg80211.h, >>>>> but that should be there upstream too, so not sure. >>>> >>>> There are a lot of rfkill.h files, what logic makes the backports code include the specific >>>> backport/backport-include/linux/rfkill.h file? I suspect that isn't working for the cfg80211.h >>>> file for whatever reason. >>> >>> It's just an additional -I flag on the compiler command line, or - >>> isystem or something like that. >>> >>> johannes >>> >> >> my cfg80211.h shows this line: >> >> #include <uapi/linux/rfkill.h> > > Not a later <linux/rfkill.h> line? We have one like that in our version > ... > > I guess we should really only have the <linux/rfkill.h> one, but since > we want the function declaration, we really ought to have that? > > johannes > > This got me further....will debug next problem now... [greearb@ben-dt4 linux-5.13.dev.y]$ git show commit 2c307ff3476bdedd76b2929028b3a9cdc9a42620 (HEAD -> master, origin/master, origin/HEAD) Author: Ben Greear <greearb@candelatech.com> Date: Mon Jul 5 12:52:11 2021 -0700 cfg80211: Include linux/rfkill.h, not uapi/linux/rfkill.h This should help when using the kernel with backports. Signed-off-by: Ben Greear <greearb@candelatech.com> diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h index 49154fb347e7..cf41d75b23d2 100644 --- a/include/net/cfg80211.h +++ b/include/net/cfg80211.h @@ -11,7 +11,7 @@ */ #include <linux/ethtool.h> -#include <uapi/linux/rfkill.h> +#include <linux/rfkill.h> #include <linux/netdevice.h> #include <linux/debugfs.h> #include <linux/list.h> -- Ben Greear <greearb@candelatech.com> Candela Technologies Inc http://www.candelatech.com -- To unsubscribe from this list: send the line "unsubscribe backports" in ^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: backports spatch question 2021-07-05 19:32 ` Johannes Berg 2021-07-05 19:38 ` Ben Greear 2021-07-05 20:07 ` Ben Greear @ 2021-07-05 20:30 ` Ben Greear 2021-07-06 6:41 ` Johannes Berg 2 siblings, 1 reply; 20+ messages in thread From: Ben Greear @ 2021-07-05 20:30 UTC (permalink / raw) To: Johannes Berg, Hauke Mehrtens; +Cc: backports So next problem is kcov stuff. This is just FYI, I'll just revert this patch since I don't need it. [greearb@ben-dt4 linux-5.13.dev.y]$ git show 261e411bb283d commit 261e411bb283d348a6a977cccb5db393594e7695 Author: Aleksandr Nogikh <nogikh@google.com> Date: Thu Oct 29 17:36:20 2020 +0000 mac80211: add KCOV remote annotations to incoming frame processing Add KCOV remote annotations to ieee80211_iface_work() and ieee80211_rx_list(). This will enable coverage-guided fuzzing of mac80211 code that processes incoming 802.11 frames. Signed-off-by: Aleksandr Nogikh <nogikh@google.com> Reviewed-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: Jakub Kicinski <kuba@kernel.org> diff --git a/net/mac80211/iface.c b/net/mac80211/iface.c index 1be775979132..56a1bcea2c1c 100644 --- a/net/mac80211/iface.c +++ b/net/mac80211/iface.c @@ -1356,6 +1356,7 @@ static void ieee80211_iface_work(struct work_struct *work) while ((skb = skb_dequeue(&sdata->skb_queue))) { struct ieee80211_mgmt *mgmt = (void *)skb->data; + kcov_remote_start_common(skb_get_kcov_handle(skb)); ..... Thanks, Ben -- Ben Greear <greearb@candelatech.com> Candela Technologies Inc http://www.candelatech.com -- To unsubscribe from this list: send the line "unsubscribe backports" in ^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: backports spatch question 2021-07-05 20:30 ` Ben Greear @ 2021-07-06 6:41 ` Johannes Berg 2021-07-06 13:24 ` Ben Greear 0 siblings, 1 reply; 20+ messages in thread From: Johannes Berg @ 2021-07-06 6:41 UTC (permalink / raw) To: Ben Greear, Hauke Mehrtens; +Cc: backports On Mon, 2021-07-05 at 13:30 -0700, Ben Greear wrote: > So next problem is kcov stuff. This is just FYI, I'll just revert this > patch since I don't need it. I guess that works, but FWIW, I did point you to our tree already earlier in the thread and generally we do have backports there for everything we needed. In this instance: https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/backport-iwlwifi.git/tree/backport-include/linux/kcov.h johannes -- To unsubscribe from this list: send the line "unsubscribe backports" in ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: backports spatch question 2021-07-06 6:41 ` Johannes Berg @ 2021-07-06 13:24 ` Ben Greear 0 siblings, 0 replies; 20+ messages in thread From: Ben Greear @ 2021-07-06 13:24 UTC (permalink / raw) To: Johannes Berg, Hauke Mehrtens; +Cc: backports On 7/5/21 11:41 PM, Johannes Berg wrote: > On Mon, 2021-07-05 at 13:30 -0700, Ben Greear wrote: >> So next problem is kcov stuff. This is just FYI, I'll just revert this >> patch since I don't need it. > > I guess that works, but FWIW, I did point you to our tree already > earlier in the thread and generally we do have backports there for > everything we needed. In this instance: > > https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/backport-iwlwifi.git/tree/backport-include/linux/kcov.h > > johannes > Oh, I thought you had a full kernel tree somewhere that you ran upstream 'backports' gentree.py against. Either way, after kcov, there was another hack to fix some stats logic, a hack for mt76, and then everything compiled. I'll run-time test it today. https://github.com/greearb/linux-ct-5.13/commit/9adefb55567bf9bddb6b1a35c3dcc2536ba79ed4 https://github.com/greearb/linux-ct-5.13/commit/fda0314f45cd32592b0db9fd18bf70e0c8a1e932 https://github.com/greearb/linux-ct-5.13/commit/9578910a5710ecc487fa6a46bafa9bedeb0ddd00 Thanks, Ben -- Ben Greear <greearb@candelatech.com> Candela Technologies Inc http://www.candelatech.com -- To unsubscribe from this list: send the line "unsubscribe backports" in ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2021-07-06 13:24 UTC | newest]
Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <e26b0d55-8662-ecf7-6630-ac23a99374b5@candelatech.com>
2021-07-01 21:40 ` backports spatch question Johannes Berg
2021-07-01 21:40 ` Ben Greear
2021-07-01 21:51 ` Johannes Berg
2021-07-01 22:33 ` Ben Greear
2021-07-01 22:55 ` Ben Greear
2021-07-05 17:47 ` Ben Greear
2021-07-05 17:55 ` Johannes Berg
2021-07-05 19:10 ` Ben Greear
2021-07-05 19:14 ` Johannes Berg
2021-07-05 19:17 ` Ben Greear
2021-07-05 19:19 ` Johannes Berg
2021-07-05 19:26 ` Ben Greear
2021-07-05 19:26 ` Johannes Berg
2021-07-05 19:32 ` Ben Greear
2021-07-05 19:32 ` Johannes Berg
2021-07-05 19:38 ` Ben Greear
2021-07-05 20:07 ` Ben Greear
2021-07-05 20:30 ` Ben Greear
2021-07-06 6:41 ` Johannes Berg
2021-07-06 13:24 ` Ben Greear
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.