mbox series

[v10,0/1] wfx: get out from the staging area

Message ID 20220226092142.10164-1-Jerome.Pouiller@silabs.com (mailing list archive)
Headers show
Series wfx: get out from the staging area | expand

Message

Jérôme Pouiller Feb. 26, 2022, 9:21 a.m. UTC
From: Jérôme Pouiller <jerome.pouiller@silabs.com>

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.Pouiller@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)
  - data_tx.c: Import patch "staging: wfx: fix use of uninitialized
      pointer"
  - sta.c: Import patch "staging: wfx: make a const array static, makes
      object smaller" (Colin)

v1:
  - Drop the function name in the warning message (Kalle)
  - Replace goto by return in wfx_send_pdata_pds() (Kalle, Dan)
  - Improve error label in wfx_send_pdata_pds() (Kalle)


Jérôme Pouiller (1):
  wfx: get out from the staging area

 .../{staging => }/net/wireless/silabs,wfx.yaml |  2 +-
 MAINTAINERS                                    |  4 ++--
 drivers/net/wireless/Kconfig                   |  1 +
 drivers/net/wireless/Makefile                  |  1 +
 drivers/net/wireless/silabs/Kconfig            | 18 ++++++++++++++++++
 drivers/net/wireless/silabs/Makefile           |  3 +++
 .../wireless/silabs}/wfx/Kconfig               |  0
 .../wireless/silabs}/wfx/Makefile              |  0
 .../{staging => net/wireless/silabs}/wfx/bh.c  |  0
 .../{staging => net/wireless/silabs}/wfx/bh.h  |  0
 .../{staging => net/wireless/silabs}/wfx/bus.h |  0
 .../wireless/silabs}/wfx/bus_sdio.c            |  0
 .../wireless/silabs}/wfx/bus_spi.c             |  0
 .../wireless/silabs}/wfx/data_rx.c             |  0
 .../wireless/silabs}/wfx/data_rx.h             |  0
 .../wireless/silabs}/wfx/data_tx.c             |  0
 .../wireless/silabs}/wfx/data_tx.h             |  0
 .../wireless/silabs}/wfx/debug.c               |  0
 .../wireless/silabs}/wfx/debug.h               |  0
 .../wireless/silabs}/wfx/fwio.c                |  0
 .../wireless/silabs}/wfx/fwio.h                |  0
 .../wireless/silabs}/wfx/hif_api_cmd.h         |  0
 .../wireless/silabs}/wfx/hif_api_general.h     |  0
 .../wireless/silabs}/wfx/hif_api_mib.h         |  0
 .../wireless/silabs}/wfx/hif_rx.c              |  0
 .../wireless/silabs}/wfx/hif_rx.h              |  0
 .../wireless/silabs}/wfx/hif_tx.c              |  0
 .../wireless/silabs}/wfx/hif_tx.h              |  0
 .../wireless/silabs}/wfx/hif_tx_mib.c          |  0
 .../wireless/silabs}/wfx/hif_tx_mib.h          |  0
 .../wireless/silabs}/wfx/hwio.c                |  0
 .../wireless/silabs}/wfx/hwio.h                |  0
 .../{staging => net/wireless/silabs}/wfx/key.c |  0
 .../{staging => net/wireless/silabs}/wfx/key.h |  0
 .../wireless/silabs}/wfx/main.c                |  0
 .../wireless/silabs}/wfx/main.h                |  0
 .../wireless/silabs}/wfx/queue.c               |  0
 .../wireless/silabs}/wfx/queue.h               |  0
 .../wireless/silabs}/wfx/scan.c                |  0
 .../wireless/silabs}/wfx/scan.h                |  0
 .../{staging => net/wireless/silabs}/wfx/sta.c |  0
 .../{staging => net/wireless/silabs}/wfx/sta.h |  0
 .../wireless/silabs}/wfx/traces.h              |  0
 .../{staging => net/wireless/silabs}/wfx/wfx.h |  0
 drivers/staging/Kconfig                        |  1 -
 drivers/staging/Makefile                       |  1 -
 drivers/staging/wfx/TODO                       |  6 ------
 47 files changed, 26 insertions(+), 11 deletions(-)
 rename Documentation/devicetree/bindings/{staging => }/net/wireless/silabs,wfx.yaml (98%)
 create mode 100644 drivers/net/wireless/silabs/Kconfig
 create mode 100644 drivers/net/wireless/silabs/Makefile
 rename drivers/{staging => net/wireless/silabs}/wfx/Kconfig (100%)
 rename drivers/{staging => net/wireless/silabs}/wfx/Makefile (100%)
 rename drivers/{staging => net/wireless/silabs}/wfx/bh.c (100%)
 rename drivers/{staging => net/wireless/silabs}/wfx/bh.h (100%)
 rename drivers/{staging => net/wireless/silabs}/wfx/bus.h (100%)
 rename drivers/{staging => net/wireless/silabs}/wfx/bus_sdio.c (100%)
 rename drivers/{staging => net/wireless/silabs}/wfx/bus_spi.c (100%)
 rename drivers/{staging => net/wireless/silabs}/wfx/data_rx.c (100%)
 rename drivers/{staging => net/wireless/silabs}/wfx/data_rx.h (100%)
 rename drivers/{staging => net/wireless/silabs}/wfx/data_tx.c (100%)
 rename drivers/{staging => net/wireless/silabs}/wfx/data_tx.h (100%)
 rename drivers/{staging => net/wireless/silabs}/wfx/debug.c (100%)
 rename drivers/{staging => net/wireless/silabs}/wfx/debug.h (100%)
 rename drivers/{staging => net/wireless/silabs}/wfx/fwio.c (100%)
 rename drivers/{staging => net/wireless/silabs}/wfx/fwio.h (100%)
 rename drivers/{staging => net/wireless/silabs}/wfx/hif_api_cmd.h (100%)
 rename drivers/{staging => net/wireless/silabs}/wfx/hif_api_general.h (100%)
 rename drivers/{staging => net/wireless/silabs}/wfx/hif_api_mib.h (100%)
 rename drivers/{staging => net/wireless/silabs}/wfx/hif_rx.c (100%)
 rename drivers/{staging => net/wireless/silabs}/wfx/hif_rx.h (100%)
 rename drivers/{staging => net/wireless/silabs}/wfx/hif_tx.c (100%)
 rename drivers/{staging => net/wireless/silabs}/wfx/hif_tx.h (100%)
 rename drivers/{staging => net/wireless/silabs}/wfx/hif_tx_mib.c (100%)
 rename drivers/{staging => net/wireless/silabs}/wfx/hif_tx_mib.h (100%)
 rename drivers/{staging => net/wireless/silabs}/wfx/hwio.c (100%)
 rename drivers/{staging => net/wireless/silabs}/wfx/hwio.h (100%)
 rename drivers/{staging => net/wireless/silabs}/wfx/key.c (100%)
 rename drivers/{staging => net/wireless/silabs}/wfx/key.h (100%)
 rename drivers/{staging => net/wireless/silabs}/wfx/main.c (100%)
 rename drivers/{staging => net/wireless/silabs}/wfx/main.h (100%)
 rename drivers/{staging => net/wireless/silabs}/wfx/queue.c (100%)
 rename drivers/{staging => net/wireless/silabs}/wfx/queue.h (100%)
 rename drivers/{staging => net/wireless/silabs}/wfx/scan.c (100%)
 rename drivers/{staging => net/wireless/silabs}/wfx/scan.h (100%)
 rename drivers/{staging => net/wireless/silabs}/wfx/sta.c (100%)
 rename drivers/{staging => net/wireless/silabs}/wfx/sta.h (100%)
 rename drivers/{staging => net/wireless/silabs}/wfx/traces.h (100%)
 rename drivers/{staging => net/wireless/silabs}/wfx/wfx.h (100%)
 delete mode 100644 drivers/staging/wfx/TODO

Comments

Kalle Valo Feb. 26, 2022, 10:41 a.m. UTC | #1
+ jakub

Jerome Pouiller <Jerome.Pouiller@silabs.com> 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.
Greg Kroah-Hartman Feb. 26, 2022, 12:56 p.m. UTC | #2
On Sat, Feb 26, 2022 at 12:41:41PM +0200, Kalle Valo wrote:
> + jakub
> 
> Jerome Pouiller <Jerome.Pouiller@silabs.com> 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
Kalle Valo Feb. 26, 2022, 1:15 p.m. UTC | #3
Greg Kroah-Hartman <gregkh@linuxfoundation.org> writes:

> On Sat, Feb 26, 2022 at 12:41:41PM +0200, Kalle Valo wrote:
>> + jakub
>> 
>> Jerome Pouiller <Jerome.Pouiller@silabs.com> 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.Pouiller@silabs.com/

Jerome, feel free to remind me about this after v5.18-rc1 is released.
Jérôme Pouiller Feb. 28, 2022, 4 p.m. UTC | #4
+ Rob
+ devicetree

On Saturday 26 February 2022 11:41:41 CET Kalle Valo wrote:
> + jakub
> 
> Jerome Pouiller <Jerome.Pouiller@silabs.com> 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.Pouiller@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 April 4, 2022, 9:31 a.m. UTC | #5
Hi Kalle,

On Saturday 26 February 2022 14:15:33 CEST Kalle Valo wrote:
> Greg Kroah-Hartman <gregkh@linuxfoundation.org> writes:
> 
> > On Sat, Feb 26, 2022 at 12:41:41PM +0200, Kalle Valo wrote:
> >> + jakub
> >>
> >> Jerome Pouiller <Jerome.Pouiller@silabs.com> 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.Pouiller@silabs.com/
> 
> Jerome, feel free to remind me about this after v5.18-rc1 is released.

v5.18-rc1 is released :)
Kalle Valo April 4, 2022, 10:49 a.m. UTC | #6
Jérôme Pouiller <jerome.pouiller@silabs.com> writes:

> On Saturday 26 February 2022 14:15:33 CEST Kalle Valo wrote:
>> Greg Kroah-Hartman <gregkh@linuxfoundation.org> 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.Pouiller@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.
Jakub Kicinski April 5, 2022, 6:22 a.m. UTC | #7
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.
Jakub Kicinski April 5, 2022, 6:29 a.m. UTC | #8
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?
Kalle Valo April 5, 2022, 7:16 a.m. UTC | #9
Jakub Kicinski <kuba@kernel.org> 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.
Jakub Kicinski April 5, 2022, 4:20 p.m. UTC | #10
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!
Kalle Valo April 6, 2022, 7:06 a.m. UTC | #11
Jakub Kicinski <kuba@kernel.org> 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.
Greg Kroah-Hartman April 7, 2022, 5:42 p.m. UTC | #12
On Wed, Apr 06, 2022 at 10:06:33AM +0300, Kalle Valo wrote:
> Jakub Kicinski <kuba@kernel.org> 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
Kalle Valo April 12, 2022, 2:42 p.m. UTC | #13
+ stephen

Greg Kroah-Hartman <gregkh@linuxfoundation.org> writes:

> On Wed, Apr 06, 2022 at 10:06:33AM +0300, Kalle Valo wrote:
>> Jakub Kicinski <kuba@kernel.org> 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.