Re: [PATCH v10 0/1] wfx: get out from the staging area
+ stephen Greg Kroah-Hartman writes: > On Wed, Apr 06, 2022 at 10:06:33AM +0300, Kalle Valo wrote: >> Jakub Kicinski writes: >> >> > On Tue, 05 Apr 2022 10:16:58 +0300 Kalle Valo wrote: >> >> Sure, that would technically work. But I just think it's cleaner to use >> >> -rc1 (or later) as the baseline for an immutable branch. If the baseline >> >> is an arbitrary commit somewhere within merge windows commits, it's more >> >> work for everyone to verify the branch is suitable. >> >> >> >> Also in general I would also prefer to base -next trees to -rc1 or newer >> >> to make the bisect cleaner. The less we need to test kernels from the >> >> merge window (ie. commits after the final release and before -rc1) the >> >> better. >> >> >> >> But this is just a small wish from me, I fully understand that it might >> >> be too much changes to your process. Wanted to point out this anyway. >> > >> > Forwarded! >> >> Awesome, thank you Jakub! >> >> Greg, I now created an immutable branch for moving wfx from >> drivers/staging to drivers/net/wireless/silabs: >> >> git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next.git >> wfx-move-out-of-staging >> >> The baseline for this branch is v5.18-rc1. If you think the branch is >> ok, please pull it to staging-next and let me know. I can then pull the >> branch to wireless-next and the transition should be complete. And do >> let me know if there are any problems. > > Looks great to me! I've pulled it into staging-next now. And will not > take any more patches to the driver (some happened before the merge but > git handled the move just fine.) Great, thanks Greg! I now merged the immutable branch also to wireless-next: 79649041edc8 Merge branch 'wfx-move-out-of-staging' 4a5fb1bbcdf1 wfx: get out from the staging area So from now on wfx patches should be submitted for wireless-next via the linux-wireless mailing list, instructions in the wiki link below. Stephen, I want to warn you in advance about this driver move but hopefully everything goes smoothly. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v10 0/1] wfx: get out from the staging area
On Wed, Apr 06, 2022 at 10:06:33AM +0300, Kalle Valo wrote: > Jakub Kicinski writes: > > > On Tue, 05 Apr 2022 10:16:58 +0300 Kalle Valo wrote: > >> Sure, that would technically work. But I just think it's cleaner to use > >> -rc1 (or later) as the baseline for an immutable branch. If the baseline > >> is an arbitrary commit somewhere within merge windows commits, it's more > >> work for everyone to verify the branch is suitable. > >> > >> Also in general I would also prefer to base -next trees to -rc1 or newer > >> to make the bisect cleaner. The less we need to test kernels from the > >> merge window (ie. commits after the final release and before -rc1) the > >> better. > >> > >> But this is just a small wish from me, I fully understand that it might > >> be too much changes to your process. Wanted to point out this anyway. > > > > Forwarded! > > Awesome, thank you Jakub! > > Greg, I now created an immutable branch for moving wfx from > drivers/staging to drivers/net/wireless/silabs: > > git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next.git > wfx-move-out-of-staging > > The baseline for this branch is v5.18-rc1. If you think the branch is > ok, please pull it to staging-next and let me know. I can then pull the > branch to wireless-next and the transition should be complete. And do > let me know if there are any problems. Looks great to me! I've pulled it into staging-next now. And will not take any more patches to the driver (some happened before the merge but git handled the move just fine.) thanks! greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v10 0/1] wfx: get out from the staging area
Jakub Kicinski writes: > On Tue, 05 Apr 2022 10:16:58 +0300 Kalle Valo wrote: >> Sure, that would technically work. But I just think it's cleaner to use >> -rc1 (or later) as the baseline for an immutable branch. If the baseline >> is an arbitrary commit somewhere within merge windows commits, it's more >> work for everyone to verify the branch is suitable. >> >> Also in general I would also prefer to base -next trees to -rc1 or newer >> to make the bisect cleaner. The less we need to test kernels from the >> merge window (ie. commits after the final release and before -rc1) the >> better. >> >> But this is just a small wish from me, I fully understand that it might >> be too much changes to your process. Wanted to point out this anyway. > > Forwarded! Awesome, thank you Jakub! Greg, I now created an immutable branch for moving wfx from drivers/staging to drivers/net/wireless/silabs: git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next.git wfx-move-out-of-staging The baseline for this branch is v5.18-rc1. If you think the branch is ok, please pull it to staging-next and let me know. I can then pull the branch to wireless-next and the transition should be complete. And do let me know if there are any problems. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v10 0/1] wfx: get out from the staging area
On Tue, 05 Apr 2022 10:16:58 +0300 Kalle Valo wrote: > Sure, that would technically work. But I just think it's cleaner to use > -rc1 (or later) as the baseline for an immutable branch. If the baseline > is an arbitrary commit somewhere within merge windows commits, it's more > work for everyone to verify the branch is suitable. > > Also in general I would also prefer to base -next trees to -rc1 or newer > to make the bisect cleaner. The less we need to test kernels from the > merge window (ie. commits after the final release and before -rc1) the > better. > > But this is just a small wish from me, I fully understand that it might > be too much changes to your process. Wanted to point out this anyway. Forwarded! ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v10 0/1] wfx: get out from the staging area
Jakub Kicinski writes: > On Mon, 4 Apr 2022 23:22:47 -0700 Jakub Kicinski wrote: >> On Mon, 04 Apr 2022 13:49:18 +0300 Kalle Valo wrote: >> > Dave&Jakub, once you guys open net-next will it be based on -rc1? >> >> Not normally. We usually let net feed net-next so it'd get -rc1 this >> Thursday. But we should be able to fast-forward, let me confirm with >> Dave. > > Wait, why is -rc1 magic? If you based the branch on whatever > the merge-base of net-next and staging-next is, would that be > an aberration? Sure, that would technically work. But I just think it's cleaner to use -rc1 (or later) as the baseline for an immutable branch. If the baseline is an arbitrary commit somewhere within merge windows commits, it's more work for everyone to verify the branch is suitable. Also in general I would also prefer to base -next trees to -rc1 or newer to make the bisect cleaner. The less we need to test kernels from the merge window (ie. commits after the final release and before -rc1) the better. But this is just a small wish from me, I fully understand that it might be too much changes to your process. Wanted to point out this anyway. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v10 0/1] wfx: get out from the staging area
On Mon, 4 Apr 2022 23:22:47 -0700 Jakub Kicinski wrote: > On Mon, 04 Apr 2022 13:49:18 +0300 Kalle Valo wrote: > > Dave&Jakub, once you guys open net-next will it be based on -rc1? > > Not normally. We usually let net feed net-next so it'd get -rc1 this > Thursday. But we should be able to fast-forward, let me confirm with > Dave. Wait, why is -rc1 magic? If you based the branch on whatever the merge-base of net-next and staging-next is, would that be an aberration? ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v10 0/1] wfx: get out from the staging area
On Mon, 04 Apr 2022 13:49:18 +0300 Kalle Valo wrote: > Dave&Jakub, once you guys open net-next will it be based on -rc1? Not normally. We usually let net feed net-next so it'd get -rc1 this Thursday. But we should be able to fast-forward, let me confirm with Dave. > That would make it easier for me to create an immutable branch between > staging-next and wireless-next. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v10 0/1] wfx: get out from the staging area
Jérôme Pouiller writes: > On Saturday 26 February 2022 14:15:33 CEST Kalle Valo wrote: >> Greg Kroah-Hartman writes: >> >> > That sounds great to me, let's plan on that happening after 5.18-rc1 is >> > out. >> >> Very good, we have a plan then. I marked the patch as deferred in >> patchwork: >> >> https://patchwork.kernel.org/project/linux-wireless/patch/20220226092142.10164-2-jerome.pouil...@silabs.com/ >> >> Jerome, feel free to remind me about this after v5.18-rc1 is released. > > v5.18-rc1 is released :) Thanks for the reminder :) Once we open wireless-next I'll start preparing the branch. Dave&Jakub, once you guys open net-next will it be based on -rc1? That would make it easier for me to create an immutable branch between staging-next and wireless-next. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v10 0/1] wfx: get out from the staging area
Hi Kalle,
On Saturday 26 February 2022 14:15:33 CEST Kalle Valo wrote:
> Greg Kroah-Hartman writes:
>
> > On Sat, Feb 26, 2022 at 12:41:41PM +0200, Kalle Valo wrote:
> >> + jakub
> >>
> >> Jerome Pouiller writes:
> >>
> >> > The firmware and the PDS files (= antenna configurations) are now a part
> >> > of
> >> > the linux-firmware repository.
> >> >
> >> > All the issues have been fixed in staging tree. I think we are ready to
> >> > get
> >> > out from the staging tree for the kernel 5.18.
> >>
> >> [...]
> >>
> >> > rename Documentation/devicetree/bindings/{staging =>
> >> > }/net/wireless/silabs,wfx.yaml (98%)
> >>
> >> I lost track, is this file acked by the DT maintainers now?
> >>
> >> What I suggest is that we queue this for v5.19. After v5.18-rc1 is
> >> released I could create an immutable branch containing this one commit.
> >> Then I would merge the branch to wireless-next and Greg could merge it
> >> to the staging tree, that way we would minimise the chance of conflicts
> >> between trees.
> >>
> >> Greg, what do you think? Would this work for you? IIRC we did the same
> >> with wilc1000 back in 2020 and I recall it went without hiccups.
> >
> > That sounds great to me, let's plan on that happening after 5.18-rc1 is
> > out.
>
> Very good, we have a plan then. I marked the patch as deferred in
> patchwork:
>
> https://patchwork.kernel.org/project/linux-wireless/patch/20220226092142.10164-2-jerome.pouil...@silabs.com/
>
> Jerome, feel free to remind me about this after v5.18-rc1 is released.
v5.18-rc1 is released :)
--
Jérôme Pouiller
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v10 0/1] wfx: get out from the staging area
+ Rob
+ devicetree
On Saturday 26 February 2022 11:41:41 CET Kalle Valo wrote:
> + jakub
>
> Jerome Pouiller writes:
>
> > The firmware and the PDS files (= antenna configurations) are now a part of
> > the linux-firmware repository.
> >
> > All the issues have been fixed in staging tree. I think we are ready to get
> > out from the staging tree for the kernel 5.18.
>
> [...]
>
> > rename Documentation/devicetree/bindings/{staging =>
> > }/net/wireless/silabs,wfx.yaml (98%)
>
> I lost track, is this file acked by the DT maintainers now?
Indeed, it seems Greg applied this patch[1] before Rob acked it.
However, the is DT now included in "make dt_binding_check" (because
it is now located in Documentation/devicetree/bindings/) and Rob
haven't raised any red flag.
[1]:
https://lore.kernel.org/netdev/20220217103248.183770-1-jerome.pouil...@silabs.com/t/
> What I suggest is that we queue this for v5.19. After v5.18-rc1 is
> released I could create an immutable branch containing this one commit.
> Then I would merge the branch to wireless-next and Greg could merge it
> to the staging tree, that way we would minimise the chance of conflicts
> between trees.
Right.
> Greg, what do you think? Would this work for you? IIRC we did the same
> with wilc1000 back in 2020 and I recall it went without hiccups.
--
Jérôme Pouiller
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v10 0/1] wfx: get out from the staging area
Greg Kroah-Hartman writes:
> On Sat, Feb 26, 2022 at 12:41:41PM +0200, Kalle Valo wrote:
>> + jakub
>>
>> Jerome Pouiller writes:
>>
>> > The firmware and the PDS files (= antenna configurations) are now a part of
>> > the linux-firmware repository.
>> >
>> > All the issues have been fixed in staging tree. I think we are ready to get
>> > out from the staging tree for the kernel 5.18.
>>
>> [...]
>>
>> > rename Documentation/devicetree/bindings/{staging =>
>> > }/net/wireless/silabs,wfx.yaml (98%)
>>
>> I lost track, is this file acked by the DT maintainers now?
>>
>> What I suggest is that we queue this for v5.19. After v5.18-rc1 is
>> released I could create an immutable branch containing this one commit.
>> Then I would merge the branch to wireless-next and Greg could merge it
>> to the staging tree, that way we would minimise the chance of conflicts
>> between trees.
>>
>> Greg, what do you think? Would this work for you? IIRC we did the same
>> with wilc1000 back in 2020 and I recall it went without hiccups.
>
> That sounds great to me, let's plan on that happening after 5.18-rc1 is
> out.
Very good, we have a plan then. I marked the patch as deferred in
patchwork:
https://patchwork.kernel.org/project/linux-wireless/patch/20220226092142.10164-2-jerome.pouil...@silabs.com/
Jerome, feel free to remind me about this after v5.18-rc1 is released.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v10 0/1] wfx: get out from the staging area
On Sat, Feb 26, 2022 at 12:41:41PM +0200, Kalle Valo wrote:
> + jakub
>
> Jerome Pouiller writes:
>
> > The firmware and the PDS files (= antenna configurations) are now a part of
> > the linux-firmware repository.
> >
> > All the issues have been fixed in staging tree. I think we are ready to get
> > out from the staging tree for the kernel 5.18.
>
> [...]
>
> > rename Documentation/devicetree/bindings/{staging =>
> > }/net/wireless/silabs,wfx.yaml (98%)
>
> I lost track, is this file acked by the DT maintainers now?
>
> What I suggest is that we queue this for v5.19. After v5.18-rc1 is
> released I could create an immutable branch containing this one commit.
> Then I would merge the branch to wireless-next and Greg could merge it
> to the staging tree, that way we would minimise the chance of conflicts
> between trees.
>
> Greg, what do you think? Would this work for you? IIRC we did the same
> with wilc1000 back in 2020 and I recall it went without hiccups.
That sounds great to me, let's plan on that happening after 5.18-rc1 is
out.
thanks,
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v10 0/1] wfx: get out from the staging area
+ jakub
Jerome Pouiller writes:
> The firmware and the PDS files (= antenna configurations) are now a part of
> the linux-firmware repository.
>
> All the issues have been fixed in staging tree. I think we are ready to get
> out from the staging tree for the kernel 5.18.
[...]
> rename Documentation/devicetree/bindings/{staging =>
> }/net/wireless/silabs,wfx.yaml (98%)
I lost track, is this file acked by the DT maintainers now?
What I suggest is that we queue this for v5.19. After v5.18-rc1 is
released I could create an immutable branch containing this one commit.
Then I would merge the branch to wireless-next and Greg could merge it
to the staging tree, that way we would minimise the chance of conflicts
between trees.
Greg, what do you think? Would this work for you? IIRC we did the same
with wilc1000 back in 2020 and I recall it went without hiccups.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v10 0/1] wfx: get out from the staging area
From: Jérôme Pouiller Hello, The firmware and the PDS files (= antenna configurations) are now a part of the linux-firmware repository. All the issues have been fixed in staging tree. I think we are ready to get out from the staging tree for the kernel 5.18. v10: - Rebase on last staging tree. v9: - Rebase on mmc tree (ulfh/next, 356f3f2c5756). Indeed, I rely on the series named "mmc: core: extend mmc_fixup_device and transplant ti,wl1251 quirks from to be retired omap_hsmmc" by "H. Nikolaus Schaller". This work is only included in the mmc tree. Anyway, I think the merge of mmc tree into Linus's tree is going to happen soon. - Locate the SDIO quirks into mmc/core/quirks.h. (Ulf, Pali) - Change the PDS format. It is now based on TLV. The tool to generate these files is ready, but I have not yet published it. (Kalle) - Fix the firmware location. It didn't match with linux-firmware. I take this opportunity to relocate these file into wfx/ instead of silabs/. I am going to send a PR to linux-firmware to reflect this changes when this PR will be accepted. (Kalle) - In the v8, some parts were formatted in 80 columns and somes in 100 columns. Unify the coding style by applying 100 columns rule everywhere. Also change structs alignement in some places. - Improve output of "make DT_CHECKER_FLAGS=-m dt_binding_check" (but not yet perfect, see above) (Rob) v8: - Change the way the DT is handled. The user can now specify the name of the board (= chip + antenna) he use. It easier for board designers to add new entries. I plan to send a PR to linux-firmware to include PDS files of the developpement boards belong the firmware (I also plan to relocate these file into wfx/ instead of silabs/). (Kalle, Pali) - Prefix visible functions and structs with "wfx_". I mostly kept the code under 80 columns. (Kalle, Pali, Greg) - Remove support for force_ps_timeout for now. (Kalle) - Fix licenses of Makefile, Kconfig and hif_api*.h. (Kalle) - Do not mix and match endianess in struct hif_ind_startup. (Kalle) - Remove magic values. (Kalle) - Use IS_ALIGNED(). (BTW, PTR_IS_ALIGNED() does not exist?) (Kalle) - I have also noticed that some headers files did not declare all the struct they used. v7: - Update location of mmc-pwrseq-simple.txt (Rob) v6: - Rebase on last staging-next (roughtly somewhere after the 5.15 merge window). So, this series include the patches from: https://lore.kernel.org/netdev/20210913130203.1903622-1-jerome.pouil...@silabs.com/ v5: - Add reference to the PR to linux-firmware in the cover letter - Rebase on last staging tree (that mainly include commit 6efed0a69794 "staging: wfx: fix possible panic with re-queued frames" and a few cosmetics changes) - Remove useless trailing spaces in DT binding (Rob) - Add a commit message in the patch 2 since I am not sure it will be squashed with the other (Rob) v4: - Rebase on last staging tree - Add 'additionalProperties: false' to the DT specification (I made that change blindly because I am able to reproduce Rob's error) (Rob) - Replace C++ comments with Ansi C comments (Kalle) - Check that existing Ansi C comments comply with net/ "compact" style - Drop one obsolete comment - Remove comments after '#endif' in header files - Remove macro redefinitions in hif_api_general.h (Kalle) - Replace compiletime_assert() with BUILD_BUG_ON_MSG() (Kalle) - Rename ieee80211_is_action_back() (Kalle) - Add a comment explaining how the PDS is sent to the device (Kalle) - Add a comment about case where CONFIG_MMC==m in the Makefile (Kalle) - Fix irrevelant comment about CONFIG_VMAP_STACK (Kalle) - Talk about the unreliable SDIO Vendor ID in the Kconfig help (Kalle) - Mention the firmware status in the cover letter (Kalle) - Fix misaligned function arguments in key.c v3: - dt-bindings: Rename config-file property (Rob) - dt-bindings: No additional properties are allowed (spi-max-frequency is already listed) (Rob) - dt-bindings: Remove references for mac-address properties (Rob) - Rebase on staging/staging-next v2: - dt-bindings: Improve device description and add link to the datasheet (Rob) - dt-bindings: Add blank lines between each DT property (Rob) - dt-bindings: Explicitly mention mac-address and local-mac-address and add references to ethernet-controller.yaml (Rob) - dt-bindings: "config-file" is not for development/debug (Rob) - dt-bindings: Remove description of "spi-max-frequency" (Rob) - dt-bindings: Use "folded scalar" syntax instead of escaping the colons - bus_sdio.c: A compatible node in the DT is now mandatory to probe the device. Also change documentation of dt-bindings accordingly (Pali, Ulf) - bus_sdio.c: Move SDIO IDs to sdio_ids.h (Pali) - bh.c: Import patch "staging: wfx: fix test on return value of gpiod_get_value()" (Nathan) - dat
