From: Jakub Kicinski <kuba@kernel.org>
To: Kalle Valo <kvalo@kernel.org>
Cc: linux-wireless@vger.kernel.org
Subject: Re: [PATCH wireless-next 0/3] wifi: netif_napi_add() conversions
Date: Mon, 9 May 2022 09:33:33 -0700 [thread overview]
Message-ID: <20220509093333.2c913702@kernel.org> (raw)
In-Reply-To: <87pmkn7ybp.fsf@kernel.org>
On Mon, 09 May 2022 14:14:02 +0300 Kalle Valo wrote:
> > 1) When I send PRs to Linus I always wonder how much he can
> > make out of the shortlog. And if people throw "net:" into the mix
> > whether it's still clear when something is "just" a driver bug vs
> > a core bug affecting everyone. So I started using "eth: " for ethernet
> > drivers, and "wifi: " for wireless drivers in the text of the PRs.
> >
> > 2) For people doing backporting the driver names may not be meaningful,
> > but if I'm doing backports for a datacenter kernel I know to pay
> > attention to "eth:" while "wifi:" I can safely skip.
>
> Is there a specific reason why you use "wifi:" and not "wireless:"? I
> admit the term wireless is not great for our 802.11 subsystem but that
> has been used as long as I know.
Right, I take the liberty of using wifi in PR texts since it seems most
appropriate as none of the low range or WWAN drivers go via the
wireless tree.
> > 3) The case of this set - I have conversions for the entire tree queued
> > up on a branch, it's quite useful for me to use a common area-specific
> > prefix to see what goes were.
> >
> > Anyway, that's just me rambling. I hope you don't mind if I send things
> > with a wifi prefix from time to time given it's a convenient way for me
> > to mark the queued patches.
>
> I don't mind if you submit with "wifi:", it's easy to edit patches with
> my patchwork script during commit :) And if there's a strong need I
> think we can change our title scheme in wireless patches. This has come
> before but I have always resisted due to extra work involved. To me most
> important is consistency within wireless subsystem, if different
> wireless drivers (and stack) use a different scheme when the logs will
> become hard to read. So I would hope everyone can agree to the new
> scheme.
No need to change the scheme overall. What you use now is the most
prevalent in the tree so I'm probably overthinking.
prev parent reply other threads:[~2022-05-09 16:33 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-04 16:33 [PATCH wireless-next 0/3] wifi: netif_napi_add() conversions Jakub Kicinski
2022-05-04 16:33 ` [PATCH wireless-next 1/3] wifi: wil6210: switch to netif_napi_add_tx() Jakub Kicinski
2022-05-06 5:48 ` [wireless-next,1/3] " Kalle Valo
2022-05-04 16:33 ` [PATCH wireless-next 2/3] wifi: mt76: " Jakub Kicinski
2022-05-04 16:33 ` Jakub Kicinski
2022-05-06 5:32 ` Kalle Valo
2022-05-06 5:32 ` Kalle Valo
2022-05-04 16:33 ` [PATCH wireless-next 3/3] wifi: qtnfmac: switch to netif_napi_add_weight() Jakub Kicinski
2022-05-05 4:25 ` [PATCH wireless-next 0/3] wifi: netif_napi_add() conversions Kalle Valo
2022-05-05 15:54 ` Jakub Kicinski
2022-05-06 5:30 ` Kalle Valo
2022-05-09 11:14 ` Kalle Valo
2022-05-09 16:33 ` Jakub Kicinski [this message]
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=20220509093333.2c913702@kernel.org \
--to=kuba@kernel.org \
--cc=kvalo@kernel.org \
--cc=linux-wireless@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.