On 11/02/2023 23.00, Arend Van Spriel wrote:
On February 11, 2023 1:50:00 PM Aditya Garg <gargaditya08@xxxxxxxx> wrote:
On 11-Feb-2023, at 6:16 PM, Hector Martin <marcan@xxxxxxxxx> wrote:
On 11/02/2023 20.23, Arend Van Spriel wrote:
On February 11, 2023 11:09:02 AM Hector Martin <marcan@xxxxxxxxx> wrote:
On 10/02/2023 12.42, Ping-Ke Shih wrote:
-----Original Message-----
From: Hector Martin <marcan@xxxxxxxxx>
Sent: Friday, February 10, 2023 10:50 AM
To: Arend van Spriel <aspriel@xxxxxxxxx>; Franky Lin
<franky.lin@xxxxxxxxxxxx>; Hante Meuleman
<hante.meuleman@xxxxxxxxxxxx>; Kalle Valo <kvalo@xxxxxxxxxx>; David S.
Miller <davem@xxxxxxxxxxxxx>; Eric
Dumazet <edumazet@xxxxxxxxxx>; Jakub Kicinski <kuba@xxxxxxxxxx>; Paolo
Abeni <pabeni@xxxxxxxxxx>
Cc: Alexander Prutskov <alep@xxxxxxxxxxx>; Chi-Hsien Lin
<chi-hsien.lin@xxxxxxxxxxx>; Wright Feng
<wright.feng@xxxxxxxxxxx>; Ian Lin <ian.lin@xxxxxxxxxxxx>; Soontak Lee
<soontak.lee@xxxxxxxxxxx>; Joseph
chuang <jiac@xxxxxxxxxxx>; Sven Peter <sven@xxxxxxxxxxxxx>; Alyssa
Rosenzweig <alyssa@xxxxxxxxxxxxx>;
Aditya Garg <gargaditya08@xxxxxxxx>; Jonas Gorski <jonas.gorski@xxxxxxxxx>;
asahi@xxxxxxxxxxxxxxx;
linux-wireless@xxxxxxxxxxxxxxx; brcm80211-dev-list.pdl@xxxxxxxxxxxx;
SHA-cyfmac-dev-list@xxxxxxxxxxxx;
netdev@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; Hector Martin
<marcan@xxxxxxxxx>; Arend van Spriel
<arend.vanspriel@xxxxxxxxxxxx>
Subject: [PATCH v3 1/4] wifi: brcmfmac: Rename Cypress 89459 to BCM4355
The commit that introduced support for this chip incorrectly claimed it
is a Cypress-specific part, while in actuality it is just a variant of
BCM4355 silicon (as evidenced by the chip ID).
The relationship between Cypress products and Broadcom products isn't
entirely clear but given what little information is available and prior
art in the driver, it seems the convention should be that originally
Broadcom parts should retain the Broadcom name.
Thus, rename the relevant constants and firmware file. Also rename the
specific 89459 PCIe ID to BCM43596, which seems to be the original
subvariant name for this PCI ID (as defined in the out-of-tree bcmdhd
driver).
v2: Since Cypress added this part and will presumably be providing
its supported firmware, we keep the CYW designation for this device.
v3: Drop the RAW device ID in this commit. We don't do this for the
other chips since apparently some devices with them exist in the wild,
but there is already a 4355 entry with the Broadcom subvendor and WCC
firmware vendor, so adding a generic fallback to Cypress seems
redundant (no reason why a device would have the raw device ID *and* an
explicitly programmed subvendor).
Do you really want to add changes of v2 and v3 to commit message? Or,
just want to let reviewers know that? If latter one is what you want,
move them after s-o-b with delimiter ---
Both; I thought those things were worth mentioning in the commit message
as it stands on its own, and left the version tags in so reviewers know
when they were introduced.
The commit message is documenting what we end up with post reviewing so
patch versions are meaningless there. Of course useful information that
came up in review cycles should end up in the commit message.
Do you really want me to respin this again just to remove 8 characters
from the commit message? I know it doesn't have much meaning post review
but it's not unheard of either, grep git logs and you'll find plenty of
examples.
- Hector
Adding to that, I guess the maintainers can do a bit on their part. Imao it’s
really frustrating preparing the same patch again and again, especially for
bits like these.
Frustrating? I am sure that maintainers have another view on that when they
have to mention the same type of submission errors again and again. That's
why there is a wireless wiki page on the subject:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Which does not mention this particular issue as far as I can tell. How
exactly is this a "submission error"? Neither you nor Kalle pointed it
out through two revisions, only a drive-by reviewer did.
If Kalle is willing to cleanup the commit message in the current patch you
are lucky. You are free to ask. Otherwise it should be not too much trouble
resubmitting it.
It's even less trouble to just take it as is, since an extra "v2: " in
the commit message doesn't hurt anyone other than those who choose to be
hurt by it. And as I said there's *tons* of commits with a changelog
like this in Linux. It's not uncommon.
I swear, some maintainers seem to take a perverse delight in making
things as painful as possible for submitters, even when there is
approximately zero benefit to the end result. And I say this as a
maintainer myself.
Maybe y'all should be the ones feeling lucky that so many people are
willing to put up with all this bullshit to get things upstreamed to
Linux. It's literally the worst open source project to upstream things
to, by a *very long* shot. I'll respin a v4 if I must, but but it's.
Just. This. Kind. Of. Nonsense. Every. Single. Time. And. Every. Single.
Time. It's. Something. Different. This stuff burns people out and
discourages submissions and turns huge numbers of people off from ever
contributing to Linux, and you all need to seriously be aware of that.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature