| Message ID | 20230210025009.21873-1-marcan@marcan.st |
|---|---|
| Headers | show |
| Series | BCM4355/4364/4377 support & identification fixes | expand |
On 10/02/2023 12.42, Ping-Ke Shih wrote: > > >> -----Original Message----- >> From: Hector Martin <marcan@marcan.st> >> Sent: Friday, February 10, 2023 10:50 AM >> To: Arend van Spriel <aspriel@gmail.com>; Franky Lin <franky.lin@broadcom.com>; Hante Meuleman >> <hante.meuleman@broadcom.com>; Kalle Valo <kvalo@kernel.org>; David S. Miller <davem@davemloft.net>; Eric >> Dumazet <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; Paolo Abeni <pabeni@redhat.com> >> Cc: Alexander Prutskov <alep@cypress.com>; Chi-Hsien Lin <chi-hsien.lin@cypress.com>; Wright Feng >> <wright.feng@cypress.com>; Ian Lin <ian.lin@infineon.com>; Soontak Lee <soontak.lee@cypress.com>; Joseph >> chuang <jiac@cypress.com>; Sven Peter <sven@svenpeter.dev>; Alyssa Rosenzweig <alyssa@rosenzweig.io>; >> Aditya Garg <gargaditya08@live.com>; Jonas Gorski <jonas.gorski@gmail.com>; asahi@lists.linux.dev; >> linux-wireless@vger.kernel.org; brcm80211-dev-list.pdl@broadcom.com; SHA-cyfmac-dev-list@infineon.com; >> netdev@vger.kernel.org; linux-kernel@vger.kernel.org; Hector Martin <marcan@marcan.st>; Arend van Spriel >> <arend.vanspriel@broadcom.com> >> 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. - Hector
On February 11, 2023 11:09:02 AM Hector Martin <marcan@marcan.st> wrote: > On 10/02/2023 12.42, Ping-Ke Shih wrote: >> >> >>> -----Original Message----- >>> From: Hector Martin <marcan@marcan.st> >>> Sent: Friday, February 10, 2023 10:50 AM >>> To: Arend van Spriel <aspriel@gmail.com>; Franky Lin >>> <franky.lin@broadcom.com>; Hante Meuleman >>> <hante.meuleman@broadcom.com>; Kalle Valo <kvalo@kernel.org>; David S. >>> Miller <davem@davemloft.net>; Eric >>> Dumazet <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; Paolo >>> Abeni <pabeni@redhat.com> >>> Cc: Alexander Prutskov <alep@cypress.com>; Chi-Hsien Lin >>> <chi-hsien.lin@cypress.com>; Wright Feng >>> <wright.feng@cypress.com>; Ian Lin <ian.lin@infineon.com>; Soontak Lee >>> <soontak.lee@cypress.com>; Joseph >>> chuang <jiac@cypress.com>; Sven Peter <sven@svenpeter.dev>; Alyssa >>> Rosenzweig <alyssa@rosenzweig.io>; >>> Aditya Garg <gargaditya08@live.com>; Jonas Gorski <jonas.gorski@gmail.com>; >>> asahi@lists.linux.dev; >>> linux-wireless@vger.kernel.org; brcm80211-dev-list.pdl@broadcom.com; >>> SHA-cyfmac-dev-list@infineon.com; >>> netdev@vger.kernel.org; linux-kernel@vger.kernel.org; Hector Martin >>> <marcan@marcan.st>; Arend van Spriel >>> <arend.vanspriel@broadcom.com> >>> 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. Regards, Arend
On 11/02/2023 20.23, Arend Van Spriel wrote: > On February 11, 2023 11:09:02 AM Hector Martin <marcan@marcan.st> wrote: > >> On 10/02/2023 12.42, Ping-Ke Shih wrote: >>> >>> >>>> -----Original Message----- >>>> From: Hector Martin <marcan@marcan.st> >>>> Sent: Friday, February 10, 2023 10:50 AM >>>> To: Arend van Spriel <aspriel@gmail.com>; Franky Lin >>>> <franky.lin@broadcom.com>; Hante Meuleman >>>> <hante.meuleman@broadcom.com>; Kalle Valo <kvalo@kernel.org>; David S. >>>> Miller <davem@davemloft.net>; Eric >>>> Dumazet <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; Paolo >>>> Abeni <pabeni@redhat.com> >>>> Cc: Alexander Prutskov <alep@cypress.com>; Chi-Hsien Lin >>>> <chi-hsien.lin@cypress.com>; Wright Feng >>>> <wright.feng@cypress.com>; Ian Lin <ian.lin@infineon.com>; Soontak Lee >>>> <soontak.lee@cypress.com>; Joseph >>>> chuang <jiac@cypress.com>; Sven Peter <sven@svenpeter.dev>; Alyssa >>>> Rosenzweig <alyssa@rosenzweig.io>; >>>> Aditya Garg <gargaditya08@live.com>; Jonas Gorski <jonas.gorski@gmail.com>; >>>> asahi@lists.linux.dev; >>>> linux-wireless@vger.kernel.org; brcm80211-dev-list.pdl@broadcom.com; >>>> SHA-cyfmac-dev-list@infineon.com; >>>> netdev@vger.kernel.org; linux-kernel@vger.kernel.org; Hector Martin >>>> <marcan@marcan.st>; Arend van Spriel >>>> <arend.vanspriel@broadcom.com> >>>> 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
> On 11-Feb-2023, at 6:16 PM, Hector Martin <marcan@marcan.st> wrote: > > On 11/02/2023 20.23, Arend Van Spriel wrote: >>> On February 11, 2023 11:09:02 AM Hector Martin <marcan@marcan.st> wrote: >>> >>> On 10/02/2023 12.42, Ping-Ke Shih wrote: >>>> >>>> >>>>> -----Original Message----- >>>>> From: Hector Martin <marcan@marcan.st> >>>>> Sent: Friday, February 10, 2023 10:50 AM >>>>> To: Arend van Spriel <aspriel@gmail.com>; Franky Lin >>>>> <franky.lin@broadcom.com>; Hante Meuleman >>>>> <hante.meuleman@broadcom.com>; Kalle Valo <kvalo@kernel.org>; David S. >>>>> Miller <davem@davemloft.net>; Eric >>>>> Dumazet <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; Paolo >>>>> Abeni <pabeni@redhat.com> >>>>> Cc: Alexander Prutskov <alep@cypress.com>; Chi-Hsien Lin >>>>> <chi-hsien.lin@cypress.com>; Wright Feng >>>>> <wright.feng@cypress.com>; Ian Lin <ian.lin@infineon.com>; Soontak Lee >>>>> <soontak.lee@cypress.com>; Joseph >>>>> chuang <jiac@cypress.com>; Sven Peter <sven@svenpeter.dev>; Alyssa >>>>> Rosenzweig <alyssa@rosenzweig.io>; >>>>> Aditya Garg <gargaditya08@live.com>; Jonas Gorski <jonas.gorski@gmail.com>; >>>>> asahi@lists.linux.dev; >>>>> linux-wireless@vger.kernel.org; brcm80211-dev-list.pdl@broadcom.com; >>>>> SHA-cyfmac-dev-list@infineon.com; >>>>> netdev@vger.kernel.org; linux-kernel@vger.kernel.org; Hector Martin >>>>> <marcan@marcan.st>; Arend van Spriel >>>>> <arend.vanspriel@broadcom.com> >>>>> 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.
On February 11, 2023 1:50:00 PM Aditya Garg <gargaditya08@live.com> wrote: >> On 11-Feb-2023, at 6:16 PM, Hector Martin <marcan@marcan.st> wrote: >> >> On 11/02/2023 20.23, Arend Van Spriel wrote: >>>> On February 11, 2023 11:09:02 AM Hector Martin <marcan@marcan.st> wrote: >>>> >>>> On 10/02/2023 12.42, Ping-Ke Shih wrote: >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Hector Martin <marcan@marcan.st> >>>>>> Sent: Friday, February 10, 2023 10:50 AM >>>>>> To: Arend van Spriel <aspriel@gmail.com>; Franky Lin >>>>>> <franky.lin@broadcom.com>; Hante Meuleman >>>>>> <hante.meuleman@broadcom.com>; Kalle Valo <kvalo@kernel.org>; David S. >>>>>> Miller <davem@davemloft.net>; Eric >>>>>> Dumazet <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; Paolo >>>>>> Abeni <pabeni@redhat.com> >>>>>> Cc: Alexander Prutskov <alep@cypress.com>; Chi-Hsien Lin >>>>>> <chi-hsien.lin@cypress.com>; Wright Feng >>>>>> <wright.feng@cypress.com>; Ian Lin <ian.lin@infineon.com>; Soontak Lee >>>>>> <soontak.lee@cypress.com>; Joseph >>>>>> chuang <jiac@cypress.com>; Sven Peter <sven@svenpeter.dev>; Alyssa >>>>>> Rosenzweig <alyssa@rosenzweig.io>; >>>>>> Aditya Garg <gargaditya08@live.com>; Jonas Gorski <jonas.gorski@gmail.com>; >>>>>> asahi@lists.linux.dev; >>>>>> linux-wireless@vger.kernel.org; brcm80211-dev-list.pdl@broadcom.com; >>>>>> SHA-cyfmac-dev-list@infineon.com; >>>>>> netdev@vger.kernel.org; linux-kernel@vger.kernel.org; Hector Martin >>>>>> <marcan@marcan.st>; Arend van Spriel >>>>>> <arend.vanspriel@broadcom.com> >>>>>> 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 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. Regards, Arend
On 11/02/2023 23.00, Arend Van Spriel wrote: > On February 11, 2023 1:50:00 PM Aditya Garg <gargaditya08@live.com> wrote: > >>> On 11-Feb-2023, at 6:16 PM, Hector Martin <marcan@marcan.st> wrote: >>> >>> On 11/02/2023 20.23, Arend Van Spriel wrote: >>>>> On February 11, 2023 11:09:02 AM Hector Martin <marcan@marcan.st> wrote: >>>>> >>>>> On 10/02/2023 12.42, Ping-Ke Shih wrote: >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Hector Martin <marcan@marcan.st> >>>>>>> Sent: Friday, February 10, 2023 10:50 AM >>>>>>> To: Arend van Spriel <aspriel@gmail.com>; Franky Lin >>>>>>> <franky.lin@broadcom.com>; Hante Meuleman >>>>>>> <hante.meuleman@broadcom.com>; Kalle Valo <kvalo@kernel.org>; David S. >>>>>>> Miller <davem@davemloft.net>; Eric >>>>>>> Dumazet <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; Paolo >>>>>>> Abeni <pabeni@redhat.com> >>>>>>> Cc: Alexander Prutskov <alep@cypress.com>; Chi-Hsien Lin >>>>>>> <chi-hsien.lin@cypress.com>; Wright Feng >>>>>>> <wright.feng@cypress.com>; Ian Lin <ian.lin@infineon.com>; Soontak Lee >>>>>>> <soontak.lee@cypress.com>; Joseph >>>>>>> chuang <jiac@cypress.com>; Sven Peter <sven@svenpeter.dev>; Alyssa >>>>>>> Rosenzweig <alyssa@rosenzweig.io>; >>>>>>> Aditya Garg <gargaditya08@live.com>; Jonas Gorski <jonas.gorski@gmail.com>; >>>>>>> asahi@lists.linux.dev; >>>>>>> linux-wireless@vger.kernel.org; brcm80211-dev-list.pdl@broadcom.com; >>>>>>> SHA-cyfmac-dev-list@infineon.com; >>>>>>> netdev@vger.kernel.org; linux-kernel@vger.kernel.org; Hector Martin >>>>>>> <marcan@marcan.st>; Arend van Spriel >>>>>>> <arend.vanspriel@broadcom.com> >>>>>>> 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. - Hector
On 2/11/2023 8:15 PM, Hector Martin wrote: > On 11/02/2023 23.00, Arend Van Spriel wrote: >> On February 11, 2023 1:50:00 PM Aditya Garg <gargaditya08@live.com> wrote: >> >>>> On 11-Feb-2023, at 6:16 PM, Hector Martin <marcan@marcan.st> wrote: >>>> >>>> On 11/02/2023 20.23, Arend Van Spriel wrote: >>>>>> On February 11, 2023 11:09:02 AM Hector Martin <marcan@marcan.st> wrote: >>>>>> >>>>>> On 10/02/2023 12.42, Ping-Ke Shih wrote: >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Hector Martin <marcan@marcan.st> >>>>>>>> Sent: Friday, February 10, 2023 10:50 AM >>>>>>>> To: Arend van Spriel <aspriel@gmail.com>; Franky Lin >>>>>>>> <franky.lin@broadcom.com>; Hante Meuleman >>>>>>>> <hante.meuleman@broadcom.com>; Kalle Valo <kvalo@kernel.org>; David S. >>>>>>>> Miller <davem@davemloft.net>; Eric >>>>>>>> Dumazet <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; Paolo >>>>>>>> Abeni <pabeni@redhat.com> >>>>>>>> Cc: Alexander Prutskov <alep@cypress.com>; Chi-Hsien Lin >>>>>>>> <chi-hsien.lin@cypress.com>; Wright Feng >>>>>>>> <wright.feng@cypress.com>; Ian Lin <ian.lin@infineon.com>; Soontak Lee >>>>>>>> <soontak.lee@cypress.com>; Joseph >>>>>>>> chuang <jiac@cypress.com>; Sven Peter <sven@svenpeter.dev>; Alyssa >>>>>>>> Rosenzweig <alyssa@rosenzweig.io>; >>>>>>>> Aditya Garg <gargaditya08@live.com>; Jonas Gorski <jonas.gorski@gmail.com>; >>>>>>>> asahi@lists.linux.dev; >>>>>>>> linux-wireless@vger.kernel.org; brcm80211-dev-list.pdl@broadcom.com; >>>>>>>> SHA-cyfmac-dev-list@infineon.com; >>>>>>>> netdev@vger.kernel.org; linux-kernel@vger.kernel.org; Hector Martin >>>>>>>> <marcan@marcan.st>; Arend van Spriel >>>>>>>> <arend.vanspriel@broadcom.com> >>>>>>>> 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. It does mention how to provide the changelog and I would have guessed you were smart enough to see the reason behind it. It is a bit lame to say it is not mentioned. >> 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. I leave this to Kalle. Personally I do not have a problem with it, but the drive-by reviewer, Ping-Ke Shih, did have a point and respinning a patch series really is not a big effort. In 30+ years of programming I have been annoyed many times about seemingly trivial review comments or straight bullshit remarks or even solid remarks, but you learn to swallow that, make the changes, and move forward. Don't get discouraged. Regards, Arend
> -----Original Message----- > From: Hector Martin <marcan@marcan.st> > Sent: Saturday, February 11, 2023 6:09 PM > To: Ping-Ke Shih <pkshih@realtek.com>; Arend van Spriel <aspriel@gmail.com>; Franky Lin > <franky.lin@broadcom.com>; Hante Meuleman <hante.meuleman@broadcom.com>; Kalle Valo <kvalo@kernel.org>; > David S. Miller <davem@davemloft.net>; Eric Dumazet <edumazet@google.com>; Jakub Kicinski > <kuba@kernel.org>; Paolo Abeni <pabeni@redhat.com> > Cc: Alexander Prutskov <alep@cypress.com>; Chi-Hsien Lin <chi-hsien.lin@cypress.com>; Wright Feng > <wright.feng@cypress.com>; Ian Lin <ian.lin@infineon.com>; Soontak Lee <soontak.lee@cypress.com>; Joseph > chuang <jiac@cypress.com>; Sven Peter <sven@svenpeter.dev>; Alyssa Rosenzweig <alyssa@rosenzweig.io>; > Aditya Garg <gargaditya08@live.com>; Jonas Gorski <jonas.gorski@gmail.com>; asahi@lists.linux.dev; > linux-wireless@vger.kernel.org; brcm80211-dev-list.pdl@broadcom.com; SHA-cyfmac-dev-list@infineon.com; > netdev@vger.kernel.org; linux-kernel@vger.kernel.org; Arend van Spriel <arend.vanspriel@broadcom.com> > Subject: Re: [PATCH v3 1/4] wifi: brcmfmac: Rename Cypress 89459 to BCM4355 > > On 10/02/2023 12.42, Ping-Ke Shih wrote: > > > > > >> -----Original Message----- > >> From: Hector Martin <marcan@marcan.st> > >> Sent: Friday, February 10, 2023 10:50 AM > >> To: Arend van Spriel <aspriel@gmail.com>; Franky Lin <franky.lin@broadcom.com>; Hante Meuleman > >> <hante.meuleman@broadcom.com>; Kalle Valo <kvalo@kernel.org>; David S. Miller <davem@davemloft.net>; > Eric > >> Dumazet <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; Paolo Abeni <pabeni@redhat.com> > >> Cc: Alexander Prutskov <alep@cypress.com>; Chi-Hsien Lin <chi-hsien.lin@cypress.com>; Wright Feng > >> <wright.feng@cypress.com>; Ian Lin <ian.lin@infineon.com>; Soontak Lee <soontak.lee@cypress.com>; > Joseph > >> chuang <jiac@cypress.com>; Sven Peter <sven@svenpeter.dev>; Alyssa Rosenzweig <alyssa@rosenzweig.io>; > >> Aditya Garg <gargaditya08@live.com>; Jonas Gorski <jonas.gorski@gmail.com>; asahi@lists.linux.dev; > >> linux-wireless@vger.kernel.org; brcm80211-dev-list.pdl@broadcom.com; > SHA-cyfmac-dev-list@infineon.com; > >> netdev@vger.kernel.org; linux-kernel@vger.kernel.org; Hector Martin <marcan@marcan.st>; Arend van > Spriel > >> <arend.vanspriel@broadcom.com> > >> 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. > With this reply, it is clear that you did those intentionally, not forgot something, so things are clear to me. The further discussion in different aspects of view in thread are also helpful for me to get much. Ping-Ke
Hector Martin <marcan@marcan.st> writes: >> 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. FWIW I can edit commit logs as long as the changes are simple and the edit instructions are clear, ie. it takes no more than a minute for me to do the edit. > 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. I understand it's frustrating but please also try understand us maintainers. For example, I have 150 patches in patchwork right now. So it's not easy for us maintainers either, far from it.
Hi all, This series adds support for the BCM4355, BCM4364, and BCM4377 variants found on Intel Apple Macs of the T2 era (and a few pre-T2 ones). The first patch fixes a bunch of confusion introduced when adding support for the Cypress 89459 chip, which is, as far as I can tell, just a BCM4355. This also drops the RAW device ID (just for this one chip), as there's no reason to add it unless we find actual hardware in the wild that uses it, and besides the raw device ID is already there twice (with a subvendor match), which was added by 2fef681a4cf7 ("brcmfmac: add CYW89342 mini-PCIe device"). The subsequent patches add the firmware names and remaining missing device IDs, including splitting the BCM4364 firmware name by revision (since it was previously added without giving thought to the existence of more than one revision in the wild with different firmwares, resulting in different users manually copying different incompatible firmwares as the same firmware name). None of these devices have firmware in linux-firmware, so we should still be able to tweak firmware filenames without breaking anyone that matters. Apple T2 users these days are mostly using downstream trees with the Asahi Linux WLAN patches merged anyway, so they already know about this. Note that these devices aren't fully usable as far as firmware selection on these platforms without some extra patches to add support for fetching the required info from ACPI, but I want to get the device ID stuff out of the way first to move forward. v2: Added a commit in front to drop all the RAW device IDs as discussed, and also fixed the 4364 firmware interface from BCA to WCC, as pointed out in the v1 thread. v3: Dropped the raw cleanup commit because apparently some platforms rely on those. Still removing the redundant raw ID for CYW89459, though. It seems highly unlikely that will break anything, as it'd have to be a device with no proper ID programmed *and* a custom subvendor programmed. Hector Martin (4): wifi: brcmfmac: Rename Cypress 89459 to BCM4355 brcmfmac: pcie: Add IDs/properties for BCM4355 brcmfmac: pcie: Add IDs/properties for BCM4377 brcmfmac: pcie: Perform correct BCM4364 firmware selection .../broadcom/brcm80211/brcmfmac/chip.c | 6 ++-- .../broadcom/brcm80211/brcmfmac/pcie.c | 33 +++++++++++++++---- .../broadcom/brcm80211/include/brcm_hw_ids.h | 8 +++-- 3 files changed, 34 insertions(+), 13 deletions(-)