https://bugzilla.kernel.org/show_bug.cgi?id=218599 Artem S. Tashkinov (aros@gmx.com) changed: What |Removed |Added ---------------------------------------------------------------------------- Component|Backports |network-wireless Version|unspecified |2.5 Assignee|backports@vger.kernel.org |drivers_network-wireless@ke | |rnel-bugs.osdl.org Product|Backports project |Drivers -- You may reply to this email to add a comment. You are receiving this mail because: You are the assignee for the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=218598 Artem S. Tashkinov (aros@gmx.com) changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |INVALID -- You may reply to this email to add a comment. You are receiving this mail because: You are the assignee for the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=218599 --- Comment #1 from Mostafa (abdolahi68@uvic.ca) --- This is my script to create mesh: #!/bin/bash # Bring down the interface sudo ip link set wlxe8de271f11cd down sleep 2 # Clear any existing IP addresses sudo ip addr flush dev wlxe8de271f11cd sleep 2 # Create the mesh interface sudo iw dev wlxe8de271f11cd interface add mesh1 type mp sleep 2 # Bring up the mesh interface sudo ip link set mesh1 up sleep 2 # Join the mesh network sudo iw dev mesh1 mesh join mymesh sleep 2 # Assign an IP address to the mesh interface sudo ip addr add 192.168.1.1/24 dev mesh1 -- You may reply to this email to add a comment. You are receiving this mail because: You are the assignee for the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=218599 Bug ID: 218599 Summary: create mesh network in backport213-5.15 Product: Backports project Version: unspecified Hardware: All OS: Linux Status: NEW Severity: normal Priority: P3 Component: Backports Assignee: backports@vger.kernel.org Reporter: abdolahi68@uvic.ca Regression: No Dear Sir, I intend to create a mesh network using backport 5.13, 5.14, and 5.15, However, I received the following error in all of them: command failed: operation not supported (-95). Also, I have used deconfig-ath9k. I am available if you require more information. Thanks. Mostafa -- You may reply to this email to add a comment. You are receiving this mail because: You are the assignee for the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=218598 Bug ID: 218598 Summary: create mesh network in backport2 Product: Backports project Version: unspecified Hardware: All OS: Linux Status: NEW Severity: normal Priority: P3 Component: Backports Assignee: backports@vger.kernel.org Reporter: abdolahi68@uvic.ca Regression: No -- You may reply to this email to add a comment. You are receiving this mail because: You are the assignee for the bug.
subscribe
On Tue, 2024-01-30 at 23:09 +0100, Hauke Mehrtens wrote:
> I am planning to drop support for kernel < 4.19 from backports
> based on kernel 6.1 and later.
>
I guess that makes sense, 4.14 is EOL at last :)
johannes
Hi backports-5.15.148-1 was released. This is based on Linux 5.15.148. https://cdn.kernel.org/pub/linux/kernel/projects/backports/stable/v5.15.148/backports-5.15.148-1.tar.xz There is now a updated wiki page with the releases: https://backports.wiki.kernel.org/index.php/Releases The source code can be found here: https://git.kernel.org/cgit/linux/kernel/git/backports/backports.git/ I am planning to work on backprots based on kernel 6.1 and 6.6. In this process I am planning to drop support for kernel < 4.19 from backports based on kernel 6.1 and later. Hauke
Use github actions to build test changes in backports. This creates a docker container with the test kernel files to test compile against. This should get stored persistently. In addition the patch adds a github action which creates a new backports tar file and uses this new container to build test the newly created backports tar. This allows to build test a backports release using github actions. Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> --- .github/workflows/build_publish_container.yml | 46 +++++++ .../build_publish_container/Dockerfile | 16 +++ .github/workflows/create.yml | 115 ++++++++++++++++++ 3 files changed, 177 insertions(+) create mode 100644 .github/workflows/build_publish_container.yml create mode 100644 .github/workflows/build_publish_container/Dockerfile create mode 100644 .github/workflows/create.yml diff --git a/.github/workflows/build_publish_container.yml b/.github/workflows/build_publish_container.yml new file mode 100644 index 00000000..d4fabbd5 --- /dev/null +++ b/.github/workflows/build_publish_container.yml @@ -0,0 +1,46 @@ +name: Build and publish container + +on: + workflow_dispatch: + push: + tags: + - 'v*' + +env: + REGISTRY: ghcr.io + IMAGE_NAME: ${{ github.repository }} + +jobs: + push_to_registry: + name: push to registry + runs-on: ubuntu-latest + + permissions: + contents: read + packages: write + + steps: + - name: Check out the repo + uses: actions/checkout@v4 + + - name: Log in to Docker Hub + uses: docker/login-action@343f7c4344506bcbf9b4de18042ae17996df046d + with: + registry: ${{ env.REGISTRY }} + username: ${{ github.actor }} + password: ${{ secrets.GITHUB_TOKEN }} + + - name: Extract metadata (tags, labels) for Docker + id: meta + uses: docker/metadata-action@dbef88086f6cef02e264edb7dbf63250c17cef6c + with: + images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }} + + - name: Build and push Docker image + uses: docker/build-push-action@4a13e500e55cf31b7a5d59a38ab2040ab0f42f56 + with: + context: . + file: .github/workflows/build_publish_container/Dockerfile + push: true + tags: ${{ steps.meta.outputs.tags }} + labels: ${{ steps.meta.outputs.labels }} diff --git a/.github/workflows/build_publish_container/Dockerfile b/.github/workflows/build_publish_container/Dockerfile new file mode 100644 index 00000000..1dcdb06f --- /dev/null +++ b/.github/workflows/build_publish_container/Dockerfile @@ -0,0 +1,16 @@ +FROM ubuntu:22.04 + +RUN apt update && \ + apt install -y git coccinelle build-essential python3 python3-pip python-is-python3 flex bison libelf1 && \ + rm -rf /var/lib/apt/lists/* + +RUN pip install pyzstd + +RUN git clone https://github.com/hauke/backports.git --branch github-action + +RUN /backports/devel/backports-update-manager --yes --no-git-update && \ + rm -rf /ksrc-backports/debs/ + +RUN rm -rf /backports + +WORKDIR / diff --git a/.github/workflows/create.yml b/.github/workflows/create.yml new file mode 100644 index 00000000..6ed0a270 --- /dev/null +++ b/.github/workflows/create.yml @@ -0,0 +1,115 @@ +name: 'Create backports tar' + +on: + push: + +jobs: + create_tar: + name: Create backports tar + runs-on: ubuntu-latest + + steps: + - name: Install coccinelle + run: | + sudo apt update + sudo apt install -y coccinelle + + - name: Checkout backports + uses: actions/checkout@v4 + with: + path: backports + + - name: Checkout kernel + uses: actions/checkout@v4 + with: + repository: gregkh/linux + ref: refs/heads/linux-5.15.y + path: linux + + - name: Generate backports tar + working-directory: backports + run: ./gentree.py --refresh ${GITHUB_WORKSPACE}/linux ${GITHUB_WORKSPACE}/backports-generated + + - name: Check for git changes + working-directory: backports + run: git diff + + - name: Pack backports-generated.tar.gz + run: tar cfz backports-generated.tar.gz backports-generated + + - name: Upload backports-generated.tar.gz + uses: actions/upload-artifact@v3 + with: + name: backports-generated.tar.gz + path: backports-generated.tar.gz + + + check_build: + name: Test backports tar + runs-on: ubuntu-latest + container: + image: ghcr.io/hauke/backports + + needs: create_tar + continue-on-error: true + strategy: + matrix: + kernel: [ + "4.4", + "4.5", + "4.6", + "4.7", + "4.8", + "4.9", + "4.10", + "4.11", + "4.12", + "4.13", + "4.14", + "4.15", + "4.16", + "4.17", + "4.18", + "4.19", + "5.0", + "5.1", + "5.2", + "5.3", + "5.4", + "5.5", + "5.6", + "5.7", + "5.8", + "5.9", + "5.10", + "5.11", + "5.12", + "5.13", + "5.14", + "5.15"] + config: [ + allyesconfig, + defconfig-wifi] + + steps: + - name: Checkout backports + uses: actions/checkout@v4 + with: + path: backports + + - name: Download backports-generated.tar.gz + uses: actions/download-artifact@v3 + with: + name: backports-generated.tar.gz + + - name: Unpack backports-generated.tar.gz + run: tar xf backports-generated.tar.gz + + - name: Create build configuration + working-directory: backports-generated + run: make -j$(nproc) KLIB=/ksrc-backports/lib/modules/${{ matrix.kernel }}.*/build/ KLIB_BUILD=/ksrc-backports/lib/modules/${{ matrix.kernel }}.*/build/ ${{ matrix.config }} + + - name: Build + working-directory: backports-generated + run: make -j$(nproc) KLIB=/ksrc-backports/lib/modules/${{ matrix.kernel }}.*/build/ KLIB_BUILD=/ksrc-backports/lib/modules/${{ matrix.kernel }}.*/build/ + -- 2.43.0
Add the '--no-git-update which will deactivate updating the git trees. This can be used in the github actions. Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> --- devel/backports-update-manager | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/devel/backports-update-manager b/devel/backports-update-manager index 9177be76..815a0421 100755 --- a/devel/backports-update-manager +++ b/devel/backports-update-manager @@ -629,6 +629,8 @@ def _main(): parser.add_argument('--reference', metavar='<path-to-git-obj-dir>', type=str, default=None, help='Override what argument to use to git clone --reference') + parser.add_argument('--no-git-update', const=True, default=False, action="store_const", + help='Don\'t update git trees') args = parser.parse_args() bk_updater = backport_kernel_updater(yes=args.yes or args.force, @@ -649,7 +651,8 @@ def _main(): bk_updater.remove_stale_kernel_dirs() bk_updater.get_backport_pkgs() bk_updater.extract_backport_pkgs() - bk_updater.update_git_trees() + if not args.no_git_update: + bk_updater.update_git_trees() return 0 -- 2.43.0
Add the usb_check_bulk_endpoints() function. This function was added to kernel 6.4 and backported to kernel 5.15. Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> --- backport/backport-include/linux/usb.h | 6 ++++ backport/compat/backport-5.15.c | 51 +++++++++++++++++++++++++++ 2 files changed, 57 insertions(+) diff --git a/backport/backport-include/linux/usb.h b/backport/backport-include/linux/usb.h index acb5b2ee..4830aebd 100644 --- a/backport/backport-include/linux/usb.h +++ b/backport/backport-include/linux/usb.h @@ -13,4 +13,10 @@ usb_find_common_endpoints(struct usb_host_interface *alt, struct usb_endpoint_descriptor **int_out); #endif /* < 4.12 */ +#if LINUX_VERSION_IS_LESS(5,15,0) +#define usb_check_bulk_endpoints LINUX_BACKPORT(usb_check_bulk_endpoints) +bool usb_check_bulk_endpoints( + const struct usb_interface *intf, const u8 *ep_addrs); +#endif /* < 5.15 */ + #endif /* __BACKPORT_LINUX_USB_H */ diff --git a/backport/compat/backport-5.15.c b/backport/compat/backport-5.15.c index fafe9c77..11aa74f6 100644 --- a/backport/compat/backport-5.15.c +++ b/backport/compat/backport-5.15.c @@ -4,6 +4,7 @@ #include <linux/export.h> #include <linux/uaccess.h> #include <linux/netdevice.h> +#include <linux/usb.h> #include <uapi/linux/if.h> @@ -53,3 +54,53 @@ int put_user_ifreq(struct ifreq *ifr, void __user *arg) EXPORT_SYMBOL(put_user_ifreq); #endif /* >= 4.6.0 */ + +/** + * usb_find_endpoint() - Given an endpoint address, search for the endpoint's + * usb_host_endpoint structure in an interface's current altsetting. + * @intf: the interface whose current altsetting should be searched + * @ep_addr: the endpoint address (number and direction) to find + * + * Search the altsetting's list of endpoints for one with the specified address. + * + * Return: Pointer to the usb_host_endpoint if found, %NULL otherwise. + */ +static const struct usb_host_endpoint *usb_find_endpoint( + const struct usb_interface *intf, unsigned int ep_addr) +{ + int n; + const struct usb_host_endpoint *ep; + + n = intf->cur_altsetting->desc.bNumEndpoints; + ep = intf->cur_altsetting->endpoint; + for (; n > 0; (--n, ++ep)) { + if (ep->desc.bEndpointAddress == ep_addr) + return ep; + } + return NULL; +} + +/** + * usb_check_bulk_endpoints - Check whether an interface's current altsetting + * contains a set of bulk endpoints with the given addresses. + * @intf: the interface whose current altsetting should be searched + * @ep_addrs: 0-terminated array of the endpoint addresses (number and + * direction) to look for + * + * Search for endpoints with the specified addresses and check their types. + * + * Return: %true if all the endpoints are found and are bulk, %false otherwise. + */ +bool usb_check_bulk_endpoints( + const struct usb_interface *intf, const u8 *ep_addrs) +{ + const struct usb_host_endpoint *ep; + + for (; *ep_addrs; ++ep_addrs) { + ep = usb_find_endpoint(intf, *ep_addrs); + if (!ep || !usb_endpoint_xfer_bulk(&ep->desc)) + return false; + } + return true; +} +EXPORT_SYMBOL_GPL(usb_check_bulk_endpoints); -- 2.43.0
Add the struct_group from Linux. Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> --- backport/backport-include/linux/stddef.h | 77 ++++++++++++++++++++++++ 1 file changed, 77 insertions(+) diff --git a/backport/backport-include/linux/stddef.h b/backport/backport-include/linux/stddef.h index a0765ef3..5a73ec71 100644 --- a/backport/backport-include/linux/stddef.h +++ b/backport/backport-include/linux/stddef.h @@ -56,4 +56,81 @@ __DECLARE_FLEX_ARRAY(TYPE, NAME) #endif +#ifndef __struct_group +/** + * __struct_group() - Create a mirrored named and anonyomous struct + * + * @TAG: The tag name for the named sub-struct (usually empty) + * @NAME: The identifier name of the mirrored sub-struct + * @ATTRS: Any struct attributes (usually empty) + * @MEMBERS: The member declarations for the mirrored structs + * + * Used to create an anonymous union of two structs with identical layout + * and size: one anonymous and one named. The former's members can be used + * normally without sub-struct naming, and the latter can be used to + * reason about the start, end, and size of the group of struct members. + * The named struct can also be explicitly tagged for layer reuse, as well + * as both having struct attributes appended. + */ +#define __struct_group(TAG, NAME, ATTRS, MEMBERS...) \ + union { \ + struct { MEMBERS } ATTRS; \ + struct TAG { MEMBERS } ATTRS NAME; \ + } +#endif + +#ifndef struct_group +/** + * struct_group() - Wrap a set of declarations in a mirrored struct + * + * @NAME: The identifier name of the mirrored sub-struct + * @MEMBERS: The member declarations for the mirrored structs + * + * Used to create an anonymous union of two structs with identical + * layout and size: one anonymous and one named. The former can be + * used normally without sub-struct naming, and the latter can be + * used to reason about the start, end, and size of the group of + * struct members. + */ +#define struct_group(NAME, MEMBERS...) \ + __struct_group(/* no tag */, NAME, /* no attrs */, MEMBERS) +#endif /* struct_group */ + +#ifndef struct_group_attr +/** + * struct_group_attr() - Create a struct_group() with trailing attributes + * + * @NAME: The identifier name of the mirrored sub-struct + * @ATTRS: Any struct attributes to apply + * @MEMBERS: The member declarations for the mirrored structs + * + * Used to create an anonymous union of two structs with identical + * layout and size: one anonymous and one named. The former can be + * used normally without sub-struct naming, and the latter can be + * used to reason about the start, end, and size of the group of + * struct members. Includes structure attributes argument. + */ +#define struct_group_attr(NAME, ATTRS, MEMBERS...) \ + __struct_group(/* no tag */, NAME, ATTRS, MEMBERS) +#endif /* struct_group_attr */ + +#ifndef struct_group_tagged +/** + * struct_group_tagged() - Create a struct_group with a reusable tag + * + * @TAG: The tag name for the named sub-struct + * @NAME: The identifier name of the mirrored sub-struct + * @MEMBERS: The member declarations for the mirrored structs + * + * Used to create an anonymous union of two structs with identical + * layout and size: one anonymous and one named. The former can be + * used normally without sub-struct naming, and the latter can be + * used to reason about the start, end, and size of the group of + * struct members. Includes struct tag argument for the named copy, + * so the specified layout can be reused later. + */ +#define struct_group_tagged(TAG, NAME, MEMBERS...) \ + __struct_group(TAG, NAME, /* no attrs */, MEMBERS) +#endif /* struct_group_tagged */ + #endif /* __BACKPORT_LINUX_STDDEF_H */ -- 2.43.0
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> --- .../include_net_cfg80211.patch | 2 +- patches/0077-genl-ro-after-init/hwsim.patch | 2 +- patches/0077-genl-ro-after-init/nl80211.patch | 2 +- patches/0079-netdev-destructor/brcmfmac.patch | 4 ++-- patches/0097-skb-list/mac80211-rx.patch | 10 +++++----- patches/0097-skb-list/mt76.patch | 8 ++++---- patches/0097-skb-list/mt7601u.patch | 2 +- patches/0099-netlink-range/mac80211.patch | 8 ++++---- patches/0100-revert-small_ops/mac80211.patch | 4 ++-- patches/0100-revert-small_ops/mac80211_hwsim.patch | 4 ++-- patches/0101-net_device-threaded/mt76.patch | 2 +- patches/verify.patch | 4 ++-- 12 files changed, 26 insertions(+), 26 deletions(-) diff --git a/patches/0003-cfg80211-wext-padding/include_net_cfg80211.patch b/patches/0003-cfg80211-wext-padding/include_net_cfg80211.patch index 8f9b0985..a602d1a0 100644 --- a/patches/0003-cfg80211-wext-padding/include_net_cfg80211.patch +++ b/patches/0003-cfg80211-wext-padding/include_net_cfg80211.patch @@ -1,6 +1,6 @@ --- a/include/net/cfg80211.h +++ b/include/net/cfg80211.h -@@ -4987,6 +4987,9 @@ struct wiphy { +@@ -4990,6 +4990,9 @@ struct wiphy { /* assign these fields before you register the wiphy */ diff --git a/patches/0077-genl-ro-after-init/hwsim.patch b/patches/0077-genl-ro-after-init/hwsim.patch index 1d00b43b..9029a443 100644 --- a/patches/0077-genl-ro-after-init/hwsim.patch +++ b/patches/0077-genl-ro-after-init/hwsim.patch @@ -1,6 +1,6 @@ --- a/drivers/net/wireless/mac80211_hwsim.c +++ b/drivers/net/wireless/mac80211_hwsim.c -@@ -4128,7 +4128,7 @@ static const struct genl_small_ops hwsim +@@ -4129,7 +4129,7 @@ static const struct genl_small_ops hwsim }, }; diff --git a/patches/0077-genl-ro-after-init/nl80211.patch b/patches/0077-genl-ro-after-init/nl80211.patch index 2891f23e..0bed66d3 100644 --- a/patches/0077-genl-ro-after-init/nl80211.patch +++ b/patches/0077-genl-ro-after-init/nl80211.patch @@ -1,6 +1,6 @@ --- a/net/wireless/nl80211.c +++ b/net/wireless/nl80211.c -@@ -15940,7 +15940,7 @@ static const struct genl_small_ops nl802 +@@ -15941,7 +15941,7 @@ static const struct genl_small_ops nl802 }, }; diff --git a/patches/0079-netdev-destructor/brcmfmac.patch b/patches/0079-netdev-destructor/brcmfmac.patch index c67ae5b6..0e32a83c 100644 --- a/patches/0079-netdev-destructor/brcmfmac.patch +++ b/patches/0079-netdev-destructor/brcmfmac.patch @@ -1,6 +1,6 @@ --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c -@@ -639,6 +639,23 @@ static const struct net_device_ops brcmf +@@ -640,6 +640,23 @@ static const struct net_device_ops brcmf .ndo_set_rx_mode = brcmf_netdev_set_multicast_list }; @@ -24,7 +24,7 @@ int brcmf_net_attach(struct brcmf_if *ifp, bool locked) { struct brcmf_pub *drvr = ifp->drvr; -@@ -889,7 +906,11 @@ struct brcmf_if *brcmf_add_if(struct brc +@@ -890,7 +907,11 @@ struct brcmf_if *brcmf_add_if(struct brc if (!ndev) return ERR_PTR(-ENOMEM); diff --git a/patches/0097-skb-list/mac80211-rx.patch b/patches/0097-skb-list/mac80211-rx.patch index 29cefa93..9b95de51 100644 --- a/patches/0097-skb-list/mac80211-rx.patch +++ b/patches/0097-skb-list/mac80211-rx.patch @@ -49,7 +49,7 @@ the older kernel instead. The list attributes where also backported to else netif_receive_skb(skb); } -@@ -4699,7 +4703,11 @@ static bool ieee80211_prepare_and_rx_han +@@ -4703,7 +4707,11 @@ static bool ieee80211_prepare_and_rx_han static void __ieee80211_rx_handle_8023(struct ieee80211_hw *hw, struct ieee80211_sta *pubsta, struct sk_buff *skb, @@ -61,7 +61,7 @@ the older kernel instead. The list attributes where also backported to { struct ieee80211_local *local = hw_to_local(hw); struct ieee80211_fast_rx *fast_rx; -@@ -4740,7 +4748,11 @@ drop: +@@ -4744,7 +4752,11 @@ drop: static void __ieee80211_rx_handle_packet(struct ieee80211_hw *hw, struct ieee80211_sta *pubsta, struct sk_buff *skb, @@ -73,7 +73,7 @@ the older kernel instead. The list attributes where also backported to { struct ieee80211_local *local = hw_to_local(hw); struct ieee80211_sub_if_data *sdata; -@@ -4865,7 +4877,11 @@ static void __ieee80211_rx_handle_packet +@@ -4869,7 +4881,11 @@ static void __ieee80211_rx_handle_packet * 802.11 MPDU is received from the hardware. */ void ieee80211_rx_list(struct ieee80211_hw *hw, struct ieee80211_sta *pubsta, @@ -85,7 +85,7 @@ the older kernel instead. The list attributes where also backported to { struct ieee80211_local *local = hw_to_local(hw); struct ieee80211_rate *rate = NULL; -@@ -4989,7 +5005,13 @@ void ieee80211_rx_napi(struct ieee80211_ +@@ -4993,7 +5009,13 @@ void ieee80211_rx_napi(struct ieee80211_ struct sk_buff *skb, struct napi_struct *napi) { struct sk_buff *tmp; @@ -99,7 +99,7 @@ the older kernel instead. The list attributes where also backported to /* -@@ -5006,8 +5028,13 @@ void ieee80211_rx_napi(struct ieee80211_ +@@ -5010,8 +5032,13 @@ void ieee80211_rx_napi(struct ieee80211_ return; } diff --git a/patches/0097-skb-list/mt76.patch b/patches/0097-skb-list/mt76.patch index f5ea0599..21a49be8 100644 --- a/patches/0097-skb-list/mt76.patch +++ b/patches/0097-skb-list/mt76.patch @@ -1,6 +1,6 @@ --- a/drivers/net/wireless/mediatek/mt76/mac80211.c +++ b/drivers/net/wireless/mediatek/mt76/mac80211.c -@@ -1025,7 +1025,13 @@ void mt76_rx_complete(struct mt76_dev *d +@@ -1026,7 +1026,13 @@ void mt76_rx_complete(struct mt76_dev *d struct ieee80211_sta *sta; struct ieee80211_hw *hw; struct sk_buff *skb, *tmp; @@ -14,7 +14,7 @@ spin_lock(&dev->rx_lock); while ((skb = __skb_dequeue(frames)) != NULL) { -@@ -1057,8 +1063,13 @@ void mt76_rx_complete(struct mt76_dev *d +@@ -1058,8 +1064,13 @@ void mt76_rx_complete(struct mt76_dev *d return; } @@ -30,7 +30,7 @@ } --- a/drivers/net/wireless/mediatek/mt76/mt76.h +++ b/drivers/net/wireless/mediatek/mt76/mt76.h -@@ -1096,7 +1096,11 @@ struct sk_buff *mt76_tx_status_skb_get(s +@@ -1098,7 +1098,11 @@ struct sk_buff *mt76_tx_status_skb_get(s void mt76_tx_status_skb_done(struct mt76_dev *dev, struct sk_buff *skb, struct sk_buff_head *list); void __mt76_tx_complete_skb(struct mt76_dev *dev, u16 wcid, struct sk_buff *skb, @@ -136,7 +136,7 @@ --- a/drivers/net/wireless/mediatek/mt76/tx.c +++ b/drivers/net/wireless/mediatek/mt76/tx.c -@@ -195,7 +195,11 @@ mt76_tx_check_non_aql(struct mt76_dev *d +@@ -197,7 +197,11 @@ mt76_tx_check_non_aql(struct mt76_dev *d } void __mt76_tx_complete_skb(struct mt76_dev *dev, u16 wcid_idx, struct sk_buff *skb, diff --git a/patches/0097-skb-list/mt7601u.patch b/patches/0097-skb-list/mt7601u.patch index 97d78aff..dbea84da 100644 --- a/patches/0097-skb-list/mt7601u.patch +++ b/patches/0097-skb-list/mt7601u.patch @@ -12,7 +12,7 @@ { struct sk_buff *skb; struct mt7601u_rxwi *rxwi; -@@ -135,8 +139,14 @@ mt7601u_rx_process_entry(struct mt7601u_ +@@ -136,8 +140,14 @@ mt7601u_rx_process_entry(struct mt7601u_ u32 seg_len, data_len = e->urb->actual_length; u8 *data = page_address(e->p); struct page *new_p = NULL; diff --git a/patches/0099-netlink-range/mac80211.patch b/patches/0099-netlink-range/mac80211.patch index bc55cc2f..662b73e9 100644 --- a/patches/0099-netlink-range/mac80211.patch +++ b/patches/0099-netlink-range/mac80211.patch @@ -1,6 +1,6 @@ --- a/net/wireless/nl80211.c +++ b/net/wireless/nl80211.c -@@ -412,10 +412,15 @@ static const struct nla_policy +@@ -413,10 +413,15 @@ static const struct nla_policy nl80211_fils_discovery_policy[NL80211_FILS_DISCOVERY_ATTR_MAX + 1] = { [NL80211_FILS_DISCOVERY_ATTR_INT_MIN] = NLA_POLICY_MAX(NLA_U32, 10000), [NL80211_FILS_DISCOVERY_ATTR_INT_MAX] = NLA_POLICY_MAX(NLA_U32, 10000), @@ -16,7 +16,7 @@ }; static const struct nla_policy -@@ -510,7 +515,11 @@ static const struct nla_policy nl80211_p +@@ -511,7 +516,11 @@ static const struct nla_policy nl80211_p [NL80211_ATTR_MPATH_NEXT_HOP] = NLA_POLICY_ETH_ADDR_COMPAT, /* allow 3 for NUL-termination, we used to declare this NLA_STRING */ @@ -28,7 +28,7 @@ [NL80211_ATTR_REG_RULES] = { .type = NLA_NESTED }, [NL80211_ATTR_BSS_CTS_PROT] = { .type = NLA_U8 }, -@@ -656,16 +665,26 @@ static const struct nla_policy nl80211_p +@@ -657,16 +666,26 @@ static const struct nla_policy nl80211_p * The value of the Length field of the Supported Operating * Classes element is between 2 and 253. */ @@ -55,7 +55,7 @@ [NL80211_ATTR_MAC_HINT] = NLA_POLICY_EXACT_LEN_WARN(ETH_ALEN), [NL80211_ATTR_WIPHY_FREQ_HINT] = { .type = NLA_U32 }, [NL80211_ATTR_TDLS_PEER_CAPABILITY] = { .type = NLA_U32 }, -@@ -720,10 +739,15 @@ static const struct nla_policy nl80211_p +@@ -721,10 +740,15 @@ static const struct nla_policy nl80211_p [NL80211_ATTR_TXQ_LIMIT] = { .type = NLA_U32 }, [NL80211_ATTR_TXQ_MEMORY_LIMIT] = { .type = NLA_U32 }, [NL80211_ATTR_TXQ_QUANTUM] = { .type = NLA_U32 }, diff --git a/patches/0100-revert-small_ops/mac80211.patch b/patches/0100-revert-small_ops/mac80211.patch index 1bae5a0b..9d0acca4 100644 --- a/patches/0100-revert-small_ops/mac80211.patch +++ b/patches/0100-revert-small_ops/mac80211.patch @@ -1,6 +1,6 @@ --- a/net/wireless/nl80211.c +++ b/net/wireless/nl80211.c -@@ -15184,9 +15184,11 @@ static const struct genl_ops nl80211_ops +@@ -15185,9 +15185,11 @@ static const struct genl_ops nl80211_ops /* can be retrieved by unprivileged users */ .internal_flags = NL80211_FLAG_NEED_WIPHY, }, @@ -12,7 +12,7 @@ { .cmd = NL80211_CMD_SET_WIPHY, .validate = GENL_DONT_VALIDATE_STRICT | GENL_DONT_VALIDATE_DUMP, -@@ -15976,8 +15978,10 @@ static struct genl_family nl80211_fam __ +@@ -15977,8 +15979,10 @@ static struct genl_family nl80211_fam __ .module = THIS_MODULE, .ops = nl80211_ops, .n_ops = ARRAY_SIZE(nl80211_ops), diff --git a/patches/0100-revert-small_ops/mac80211_hwsim.patch b/patches/0100-revert-small_ops/mac80211_hwsim.patch index 30a09e47..a24d22f6 100644 --- a/patches/0100-revert-small_ops/mac80211_hwsim.patch +++ b/patches/0100-revert-small_ops/mac80211_hwsim.patch @@ -1,6 +1,6 @@ --- a/drivers/net/wireless/mac80211_hwsim.c +++ b/drivers/net/wireless/mac80211_hwsim.c -@@ -4091,7 +4091,11 @@ done: +@@ -4092,7 +4092,11 @@ done: } /* Generic Netlink operations array */ @@ -12,7 +12,7 @@ { .cmd = HWSIM_CMD_REGISTER, .validate = GENL_DONT_VALIDATE_STRICT | GENL_DONT_VALIDATE_DUMP, -@@ -4135,8 +4139,13 @@ static struct genl_family hwsim_genl_fam +@@ -4136,8 +4140,13 @@ static struct genl_family hwsim_genl_fam .policy = hwsim_genl_policy, .netnsok = true, .module = THIS_MODULE, diff --git a/patches/0101-net_device-threaded/mt76.patch b/patches/0101-net_device-threaded/mt76.patch index e6b93839..9cc1e126 100644 --- a/patches/0101-net_device-threaded/mt76.patch +++ b/patches/0101-net_device-threaded/mt76.patch @@ -29,7 +29,7 @@ debugfs_create_blob("otp", 0400, dir, &dev->otp); --- a/drivers/net/wireless/mediatek/mt76/dma.c +++ b/drivers/net/wireless/mediatek/mt76/dma.c -@@ -645,7 +645,9 @@ mt76_dma_init(struct mt76_dev *dev, +@@ -650,7 +650,9 @@ mt76_dma_init(struct mt76_dev *dev, init_dummy_netdev(&dev->tx_napi_dev); snprintf(dev->napi_dev.name, sizeof(dev->napi_dev.name), "%s", wiphy_name(dev->hw->wiphy)); diff --git a/patches/verify.patch b/patches/verify.patch index 50dce893..370fd5f7 100644 --- a/patches/verify.patch +++ b/patches/verify.patch @@ -23,7 +23,7 @@ #include "x509_parser.h" /* -@@ -149,6 +146,7 @@ not_self_signed: +@@ -154,6 +151,7 @@ not_self_signed: return 0; } @@ -31,7 +31,7 @@ /* * Attempt to parse a data blob for a key as an X509 certificate. */ -@@ -267,3 +265,4 @@ module_exit(x509_key_exit); +@@ -272,3 +270,4 @@ module_exit(x509_key_exit); MODULE_DESCRIPTION("X.509 certificate parser"); MODULE_AUTHOR("Red Hat, Inc."); MODULE_LICENSE("GPL"); -- 2.43.0
Thanks a lot guys.
That tree seems to have contributions from all the right people and it seems to generate a working 6.5 tree.
br,
Cristian.
On vineri, 24 noiembrie 2023 19:38:07 EET Brian Witte wrote:
>
> > ----------------------------------------
> > From: Larry Finger <Larry.Finger@lwfinger.net>
> > Date: Nov 24, 2023, 7:34:16 AM
> >
> > Christian,
> >
> > I do not know the details, but Brian Witte (Cc'd here) recently informed me that
> > Felix Flietkau has a backports tree for kernel 6.5.
> >
> > Larry
> >
> >
>
> Cristian,
>
> I was asking questions on #backports IRC channel since I also am trying to get a
> more up-to-date backports release. I had started patching from 5.15 and was
> making some progress, but it was going slower than I'd like and then Hauke
> shared this tree with me:
>
> https://github.com/nbd168/backports
>
> It appears to be on 6.5, I have only pulled the code at this point and haven't
> fully tested it since we had a holiday here in US and I have been traveling and
> with family.
>
> Felix is maintaining that tree for OpenWrt from what I have been told.
> You can see various 6.x backports tarballs here if you search "backports":
>
> https://mirror2.openwrt.org/sources/
>
> I am going to be digging into this for Realtek backports repos that Larry and I
> work on. It seems like there is some renewed interest in backports these
> days, haha.
>
> Let me know if I can help in any way as I am working on similar problems.
>
> I will report back if any issues come while working with Felix's tree. I am very
> grateful it was shared with me to say the least...
>
> Brian Witte
>
> ---------------------------------------- > From: Larry Finger <Larry.Finger@lwfinger.net> > Date: Nov 24, 2023, 7:34:16 AM > > Christian, > > I do not know the details, but Brian Witte (Cc'd here) recently informed me that > Felix Flietkau has a backports tree for kernel 6.5. > > Larry > > Cristian, I was asking questions on #backports IRC channel since I also am trying to get a more up-to-date backports release. I had started patching from 5.15 and was making some progress, but it was going slower than I'd like and then Hauke shared this tree with me: https://github.com/nbd168/backports It appears to be on 6.5, I have only pulled the code at this point and haven't fully tested it since we had a holiday here in US and I have been traveling and with family. Felix is maintaining that tree for OpenWrt from what I have been told. You can see various 6.x backports tarballs here if you search "backports": https://mirror2.openwrt.org/sources/ I am going to be digging into this for Realtek backports repos that Larry and I work on. It seems like there is some renewed interest in backports these days, haha. Let me know if I can help in any way as I am working on similar problems. I will report back if any issues come while working with Felix's tree. I am very grateful it was shared with me to say the least... Brian Witte
On 11/23/23 08:24, Cristian Cimpianu wrote:
> Hi guys,
>
> I've been working on a project using the backports project to build some custom wifi modules for different kernel versions.
> Now the customer wants to do a wifi-7 chip keeping the infrastructure the same as much as possible. But wifi-7 has been added into kernel 6.5, while the backports project is still at 5.15. And the customer wants that in like 6 months.
> So, in the hope I will understand better what would be the easiest solution, I figured I could ask here.
> Is there a plan to add support in the backports project for kernel 6.5 or for the wifi-7 changes to the mac80211 and cfg80211 modules?
Christian,
I do not know the details, but Brian Witte (Cc'd here) recently informed me that
Felix Flietkau has a backports tree for kernel 6.5.
Larry
Hi guys, I've been working on a project using the backports project to build some custom wifi modules for different kernel versions. Now the customer wants to do a wifi-7 chip keeping the infrastructure the same as much as possible. But wifi-7 has been added into kernel 6.5, while the backports project is still at 5.15. And the customer wants that in like 6 months. So, in the hope I will understand better what would be the easiest solution, I figured I could ask here. Is there a plan to add support in the backports project for kernel 6.5 or for the wifi-7 changes to the mac80211 and cfg80211 modules? best regards, Cristian.
Hi Brian, Sorry for the delay - had a bit of a crazy week last week. > I was able to get a new backports package built and running on my > machine over the weekend. Nice :) > First, I did a `./gentree.py` on Hauke's v5.15.92 release I didn't even know there was a backports release of the scripts itself rather than just the output ... :) > with it's > corrresponding branch in stable with success and installed backports on > my hardware running v5.10.0. The new driver code was loaded and worked > as intended with a couple different usb dongles I have. Great! So progress, I guess :) > Second, as a test I built a package release for v5.16.20 because initial > rtw89 commit appears here: > > $ pwd > /home/bkz/linux-stable > > $ git symbolic-ref --short HEAD && git rev-parse --short HEAD > master > ffc253263a13 > > $ git describe --contains e3ec7017f6a20d12ddd9fe23d345ebb7b8c104dd > v5.16-rc1~159^2~121^2~39 > > I was able to cut that release package that works for the rtw89 driver > by adjust existing patch file diff hunks to apply properly and adding a > new header that came in to net. Right. > What other testing do you recommend for a "new driver" besides testing > "builds" as mentioned in docs [1] here in 'Adding new driver'? Well if you have the devices, you could test them too, but ... if we trust backports to more or less do the right thing, it should work :) > It goes over supporting latest minor versions and says, "you should install > all supported kernel with the script in devel/get-compat-kernels and > then run devel/ckmake to build backports against every kernel version." > > [1] https://backports.wiki.kernel.org/index.php/Documentation/backports/hacking > > I am working on test/automation for our new backports workflow so any > insight you have would be helpful. Ah, well, that's more to make sure backports itself (as in the compatibility code it adds and the changes it makes) actually compiles against all the different kernels. You might want to check that, and ckmake and all is just a nicer way of achieving that. But you might want to restrict yourself to kernels that you see actually in (broad) use from your users? > Honestly, we could probably use some key points from this thread to make > some newbie friendly docs considering how confused I was at first, haha! > > I could probably draw a nice diagram based on your explanations. > I wouldn't mind (you) adding something to the wiki but I'm not even sure I know how to use it :) johannes
> From: Luis Chamberlain <mcgrof@kernel.org>
> Date: Oct 31, 2023, 2:36:46 PM
>
> If you decide to give kdevops a shot to allow folks to test wifi
> devices easily
> I'm happy to give any tips / advice. PCIe passthrough is supported through
Luis,
Yes, the plan is still kdevops for this.
At Linux Plumbers Conference, my main goals are:
1. Learn about kernel testing, debugging, and net/wireless.
2. Meet and get advice, tips from backports/wireless/kdevops folks.
I wanted to have kdevops set up in time for LPC so could I talk shop
better with other kdevops users, but figuring out how to get Larry's
most popular GitHub backport repos up-to-date took priority and I
stalled on the kdevops setup.
Right now I have a basic scripted QEMU setup that is a pain.
Good news is now that we have our ducks in a row with the gameplan for
using backports, I can jump back fully into testing workflow and
automation so we can start bumping up the release package versions that
work with rtw88/rtw89 to a more current stable. Larry thinks sticking to
stable will be better for the GitHub repos going forward with backports
instead of wireless-next like we were for the manual backports.
I will reach out on the kdevops channels as I go through it.
Thanks,
Brian Witte
On Tue, Oct 31, 2023 at 05:24:04PM +0100, Brian Witte wrote: > What other testing do you recommend for a "new driver" besides testing > "builds" as mentioned in docs [1] here in 'Adding new driver'? Whatever this ends up being: > I am working on test/automation for our new backports workflow so any > insight you have would be helpful. If you decide to give kdevops a shot to allow folks to test wifi devices easily I'm happy to give any tips / advice. PCIe passthrough is supported through 'make dynconfig' so you could end up using that so to not crash a host. We're using that to test new block devices with new filesystem developments. The only issue we've run into when doing this is when a PCI device resets the sysfs file changes on the host so PCI passthrough stops, working around this manually is documented here: https://lore.kernel.org/all/ZQIRh+fpU1sR8BTN@bombadil.infradead.org/T/#u How we fix this upstream for pcie passthrough remains unclear yet. For wifi devices I am not sure what sort of things triggers full PCI device resets, perhaps firmware crashes? Luis
> > I am going to get started now. > Johannes, Sorry for not getting back sooner. Busy at work, etc. then wanted to make sure Larry could run the release package successfully. I was able to get a new backports package built and running on my machine over the weekend. First, I did a `./gentree.py` on Hauke's v5.15.92 release with it's corrresponding branch in stable with success and installed backports on my hardware running v5.10.0. The new driver code was loaded and worked as intended with a couple different usb dongles I have. Second, as a test I built a package release for v5.16.20 because initial rtw89 commit appears here: $ pwd /home/bkz/linux-stable $ git symbolic-ref --short HEAD && git rev-parse --short HEAD master ffc253263a13 $ git describe --contains e3ec7017f6a20d12ddd9fe23d345ebb7b8c104dd v5.16-rc1~159^2~121^2~39 I was able to cut that release package that works for the rtw89 driver by adjust existing patch file diff hunks to apply properly and adding a new header that came in to net. Preliminary test was successful: $ ./wi_stat.sh Kernel Version: 5.10.0-26-amd64 debian Wireless Driver: device: wlp2s0 driver: rtw89_pci Driver Stats: rx_bytes : 359634613 rx_packets : 271727 tx_bytes : 8117768 tx_packets : 46573 My last question re: rtw89, since I just cut a release that "added it" even though I did not do anything driver specific since the in-tree subsystem and realtek/ dir do actual config, is this: What other testing do you recommend for a "new driver" besides testing "builds" as mentioned in docs [1] here in 'Adding new driver'? It goes over supporting latest minor versions and says, "you should install all supported kernel with the script in devel/get-compat-kernels and then run devel/ckmake to build backports against every kernel version." [1] https://backports.wiki.kernel.org/index.php/Documentation/backports/hacking I am working on test/automation for our new backports workflow so any insight you have would be helpful. Again, thank you for your help. Larry and I appreciate it. I will end this thread after your reply and come back to this list with patches, general questions, and coordinating on helping cut new releases for https://backports.wiki.kernel.org/index.php/Releases or updating docs on the wiki. Honestly, we could probably use some key points from this thread to make some newbie friendly docs considering how confused I was at first, haha! I could probably draw a nice diagram based on your explanations. Anyway, thanks again! Brian Witte
Johannes, Thank you for quick reply. > >> I am going to first try a variation of the approach you suggested where >> I generate backports for Linux versions in the repo in ascending order >> then have our Makefile detect user's version and install accordingly. > > Wait, no, what? You don't need to detect the user's version or anything. > Ah, yes! Ok, wow. Sorry. Things are finally adding up... ¬‿¬ > No no, misunderstanding here I think. You don't need anything granular > at all, *all* your users should be able to use a *single* current > backports-based package. > > The granularity question only comes in when you say have a user who > reports that something doesn't work. Now what, how do you get them to > e.g. bisect? Right now you have a git tree they can normally bisect in. > > Now, if you > - release backports tarballs for them to use, or > - commit the output of backports into a git tree for them to use > > *then* you get into the granularity question, which ends up being a > trade-off between what's effectively bisectability (you don't really > need to care about the history, after all, it's preserved upstream), and > effort on your end to generate (and test) them all. > Right, yes. >> After that, our Makefile and/or scripts it coordinates will have to >> detect the user version, then cd into that package, and install it >> properly. >> > > No, you should just give them the output of backports (gentree.py) > directly, it does all this. > >> I am suspending any upstream commit history shenanigans for a >> later point as making sure the driver is performant and in-line with the >> up-to-date wireless stack. > > OK, so then you just need to release a single tarball effectively. > Whether as a git branch or a literal tarball is pretty much irrelevant. > Ok, I now understand. I think because of the way I was trying to do things before I was failing to see how radically backports could simplify the task in many ways. The approach I have been using is far away from this way of doing things. I am going to get started now. Again, thank you for your patience and help. Thanks, Brian Witte
>
> > After that, our Makefile and/or scripts it coordinates will have to
> > detect the user version, then cd into that package, and install it
> > properly.
> >
>
> No, you should just give them the output of backports (gentree.py)
> directly, it does all this.
>
Well I phrased this badly - it doesn't of course "cd into that package"
etc, it's just a single package. However, it handles being compatible
with pretty much any kernel version.
johannes
Hi Brian, > I spoke to Larry off list and considering the cfg80211 and mac80211 > situation with older kernels further, he wants me to try and get a > simple backports setup validated so that people can still > `make` and `make install`. > Sure. That should pretty much, after all, we do it many times every day with iwlwifi with our internal tree :) But yeah, getting it generated might take a bit of work. > He is focused on a few other important tasks > and will probably get back with us here later, I just wanted to start > running downhill with this ASAP so I slid in here. :) > I am going to first try a variation of the approach you suggested where > I generate backports for Linux versions in the repo in ascending order > then have our Makefile detect user's version and install accordingly. Wait, no, what? You don't need to detect the user's version or anything. If you generate a single backports from say v6.6-rc6 today, users should be able to run it on any kernel as far back as 4.something. The only time you need _multiple_ backports is if you don't want to stick to v6.6-rc6 (per example), but want to have v6.6-rc7 this week and v6.6 release next week. > Again, my understanding is often the bottleneck so I want to first say > what I intend to do and then ask a question: > > 1. I want to use wireless-next as the upstream kernel source for > building the backports, I would need to build all backports via the > "package release" workflow [1] Not sure I'd say that - the workflow page [1] is written with instructions for your *users*, not for *you* as the one providing the packages. > in order to provide users with a package > that they can use without needing the upstream source on their machine, > effectively giving them "a patch file" for compatibility for driver > specific modifications and the up-to-date 80211 stack. I would then only > need to decide which git tags for older kernels to use for the versions > we want to support, create the packages, then include those in the > repository. Yes. > [1] https://backports.wiki.kernel.org/index.php/Documentation/packaging (just to keep the link) > 2. I am trying to figure this out currently, but am not entirely sure > how granular the built package versions have to be in order to work with > a users kernel version. How do I decide the coverage of an individual > package per major-minor version or other variations? You mentioned RCs > earlier. For this first PoC, I want to make sure users can get the > driver working for any version they are running going back to 5.4. No no, misunderstanding here I think. You don't need anything granular at all, *all* your users should be able to use a *single* current backports-based package. The granularity question only comes in when you say have a user who reports that something doesn't work. Now what, how do you get them to e.g. bisect? Right now you have a git tree they can normally bisect in. Now, if you - release backports tarballs for them to use, or - commit the output of backports into a git tree for them to use *then* you get into the granularity question, which ends up being a trade-off between what's effectively bisectability (you don't really need to care about the history, after all, it's preserved upstream), and effort on your end to generate (and test) them all. > After that, our Makefile and/or scripts it coordinates will have to > detect the user version, then cd into that package, and install it > properly. > No, you should just give them the output of backports (gentree.py) directly, it does all this. > I am suspending any upstream commit history shenanigans for a > later point as making sure the driver is performant and in-line with the > up-to-date wireless stack. OK, so then you just need to release a single tarball effectively. Whether as a git branch or a literal tarball is pretty much irrelevant. > Being able to use those features and have a > consistent API across the components is much more of a priority, at the > moment. > > Thank you for you help and patience with all of this. You have helped > make this process an enjoyable thing to dive into and I am excited to > start hacking on backports. > :) johannes
Johannes, > Right. Keep in mind also though that you're doing it differently from > what backports does - backports comes with cfg80211 and mac80211, so > it's easier to do than adjusting to older versions of mac80211. I spoke to Larry off list and considering the cfg80211 and mac80211 situation with older kernels further, he wants me to try and get a simple backports setup validated so that people can still `make` and `make install`. He is focused on a few other important tasks and will probably get back with us here later, I just wanted to start running downhill with this ASAP so I slid in here. I am going to first try a variation of the approach you suggested where I generate backports for Linux versions in the repo in ascending order then have our Makefile detect user's version and install accordingly. Again, my understanding is often the bottleneck so I want to first say what I intend to do and then ask a question: 1. I want to use wireless-next as the upstream kernel source for building the backports, I would need to build all backports via the "package release" workflow [1] in order to provide users with a package that they can use without needing the upstream source on their machine, effectively giving them "a patch file" for compatibility for driver specific modifications and the up-to-date 80211 stack. I would then only need to decide which git tags for older kernels to use for the versions we want to support, create the packages, then include those in the repository. [1] https://backports.wiki.kernel.org/index.php/Documentation/packaging 2. I am trying to figure this out currently, but am not entirely sure how granular the built package versions have to be in order to work with a users kernel version. How do I decide the coverage of an individual package per major-minor version or other variations? You mentioned RCs earlier. For this first PoC, I want to make sure users can get the driver working for any version they are running going back to 5.4. After that, our Makefile and/or scripts it coordinates will have to detect the user version, then cd into that package, and install it properly. I am suspending any upstream commit history shenanigans for a later point as making sure the driver is performant and in-line with the up-to-date wireless stack. Being able to use those features and have a consistent API across the components is much more of a priority, at the moment. Thank you for you help and patience with all of this. You have helped make this process an enjoyable thing to dive into and I am excited to start hacking on backports. Thanks, Brian Witte