linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kalle Valo <kvalo@codeaurora.org>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jerome Pouiller <Jerome.Pouiller@silabs.com>,
	devel@driverdev.osuosl.org, linux-wireless@vger.kernel.org,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	"David S . Miller" <davem@davemloft.net>
Subject: Re: [PATCH 0/7] wfx: move out from the staging area
Date: Thu, 08 Oct 2020 10:30:06 +0300	[thread overview]
Message-ID: <87ft6p2n0h.fsf@codeaurora.org> (raw)
In-Reply-To: <20201007105513.GA1078344@kroah.com> (Greg Kroah-Hartman's message of "Wed, 7 Oct 2020 12:55:13 +0200")

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

> On Wed, Oct 07, 2020 at 12:19:36PM +0200, Jerome Pouiller wrote:
>> From: Jérôme Pouiller <jerome.pouiller@silabs.com>
>> 
>> I think the wfx driver is now mature enough to be accepted in the
>> drivers/net/wireless directory.
>> 
>> There is still one item on the TODO list. It is an idea to improve the rate
>> control in some particular cases[1]. However, the current performances of the
>> driver seem to satisfy everyone. In add, the suggested change is large enough.
>> So, I would prefer to implement it only if it really solves an issue. I think it
>> is not an obstacle to move the driver out of the staging area.
>> 
>> In order to comply with the last rules for the DT bindings, I have converted the
>> documentation to yaml. I am moderately happy with the result. Especially, for
>> the description of the binding. Any comments are welcome.
>> 
>> The series also update the copyrights dates of the files. I don't know exactly
>> how this kind of changes should be sent. It's a bit weird to change all the
>> copyrights in one commit, but I do not see any better way.
>> 
>> I also include a few fixes I have found these last weeks.
>> 
>> [1] https://lore.kernel.org/lkml/3099559.gv3Q75KnN1@pc-42
>
> I'll take the first 6 patches here, the last one you should work with
> the wireless maintainers to get reviewed.
>
> Maybe that might want to wait until after 5.10-rc1 is out, with all of
> these changes in it, making it an easier move.

Yes, the driver needs to be reviewed in linux-wireless list. I recommend
submitting the whole driver in a patchset with one file per patch, which
seems to be the easiest way to review a full driver. The final move will
be in just one commit moving the driver, just like patch 7 does here. As
an example see how wilc1000 review was done.

Device tree bindings needs to be reviewed by the DT maintainer so CC
devicetree on that patch.

But do note that there's currently one new driver in review queue, so it
will most likely take some time before wfx is reviewed.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

  reply	other threads:[~2020-10-08  7:30 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-07 10:19 [PATCH 0/7] wfx: move out from the staging area Jerome Pouiller
2020-10-07 10:19 ` [PATCH 1/7] staging: wfx: fix handling of MMIC error Jerome Pouiller
2020-10-07 10:19 ` [PATCH 2/7] staging: wfx: remove remaining code of 'secure link' feature Jerome Pouiller
2020-10-07 10:19 ` [PATCH 3/7] staging: wfx: fix BA sessions for older firmwares Jerome Pouiller
2020-10-07 10:19 ` [PATCH 4/7] staging: wfx: fix QoS priority for slow buses Jerome Pouiller
2020-10-07 10:19 ` [PATCH 5/7] staging: wfx: update copyrights dates Jerome Pouiller
2020-10-07 10:19 ` [PATCH 6/7] dt-bindings: staging: wfx: silabs,wfx yaml conversion Jerome Pouiller
2020-10-07 10:19 ` [PATCH 7/7] wfx: move out from the staging area Jerome Pouiller
2020-10-07 10:55 ` [PATCH 0/7] " Greg Kroah-Hartman
2020-10-08  7:30   ` Kalle Valo [this message]
2020-10-08  9:50     ` Kalle Valo
2020-10-08 10:10     ` Jérôme Pouiller
2020-10-08 11:00       ` Kalle Valo
2020-10-08 13:13 ` Dan Carpenter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87ft6p2n0h.fsf@codeaurora.org \
    --to=kvalo@codeaurora.org \
    --cc=Jerome.Pouiller@silabs.com \
    --cc=davem@davemloft.net \
    --cc=devel@driverdev.osuosl.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).