Re: backports spatch question

Re: backports spatch question

[Johannes Berg]

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

Re: backports spatch question

[Ben Greear]

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

Re: backports spatch question

[Johannes Berg]

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

Re: backports spatch question

[Ben Greear]

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

Re: backports spatch question

[Ben Greear]

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

Re: backports spatch question

[Ben Greear]

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

Re: backports spatch question

[Johannes Berg]

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

Re: backports spatch question

[Ben Greear]

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

Re: backports spatch question

[Johannes Berg]

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

Re: backports spatch question

[Ben Greear]

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

Re: backports spatch question

[Johannes Berg]

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

Re: backports spatch question

[Ben Greear]

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

Re: backports spatch question

[Johannes Berg]

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

Re: backports spatch question

[Ben Greear]

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

Re: backports spatch question

[Johannes Berg]

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

Re: backports spatch question

[Ben Greear]

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

Re: backports spatch question

[Ben Greear]

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

Re: backports spatch question

[Ben Greear]

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

Re: backports spatch question

[Johannes Berg]

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

Re: backports spatch question

[Ben Greear]

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