[PATCH v5 0/2] wcn36xx: Miscellaneous updates

[Kalle Valo]

Bryan O'Donoghue <pure.logic at nexus-software.ie> writes:

> On 10/09/2020 16:08, Bryan O'Donoghue wrote:
>> This series is seven in a set of seven to add support for wcn3680 at 802.11ac
>> data-rates.
>>
>> This set marks functions previously declared non-static as static. In order
>> to facilitate granular standalone commits and avoid single patch
>> code-bombs. A series of functions were previously declared non-static.
>> Antecedent changes have made use of those functions so we can now mark them
>> static.
>>
>> In a similar theme of cleanup, I've added on a fix for some whitespace
>> damage in main.c and smd.c which while not strictly related to wcn3680 I've
>> opted to throw into the bucket under a "miscellaneous update" title.
>>
>> Hope that's OK.
>>
>> V5:
>> - No change to V4 but need to send the set again so that
>>    prerequisite-patch-id makes sense to the build robot here.
>>
>> V4:
>> - No functional change.
>>    Sending out full set again using --base=ath-202009090652 to aid kernel
>>    test robot
>> - https://lore.kernel.org/linux-wireless/20200908183424.2871101-1-bryan.odonoghue@linaro.org/T/#t
>>
>> V3/RESEND:
>> - Messed up my .git/config resending from my @linaro.org address
>>
>> Bryan O'Donoghue (2):
>>    wcn36xx: Mark internal smd functions static
>>    wcn36xx: Ensure spaces between functions
>>
>>   drivers/net/wireless/ath/wcn36xx/main.c |  1 +
>>   drivers/net/wireless/ath/wcn36xx/smd.c  | 65 +++++++++----------------
>>   2 files changed, 23 insertions(+), 43 deletions(-)
>>
>>
>> base-commit: 160b351d75cb50a0dd2abf9b63e1891935aa9e4a
>> prerequisite-patch-id: 9a4ac7faca179f6594c9b3a115ee69a2da540a69
>> prerequisite-patch-id: 183286f9c22d1aaa12f356651224e6b337ef1938
>> prerequisite-patch-id: af468d413daaf8d2aad195fcb43c6e66390d8468
>> prerequisite-patch-id: 08122a9557904ce5358f52dd08cc33270fa202c1
>> prerequisite-patch-id: 82e0b7c5b2e9fa80baca001cce12577d98e306a9
>> prerequisite-patch-id: 8ee7f5bd6cb5b7b7d713947b554ad93bb90d8230
>> prerequisite-patch-id: d05c2253e4523b05b2e43491aa13ceeef68fd2f0
>> prerequisite-patch-id: 8be29513d3efa64df15297bcf81ec3db55088ee1
>> prerequisite-patch-id: d267dcd834afad75a69bcd2adcccfdad6566a7ba
>> prerequisite-patch-id: 47145acae6e24e8e6580fca1dbddfbec24f7b50b
>> prerequisite-patch-id: 8c66bccb923be821cf109a3a0d3a1a028edb4930
>> prerequisite-patch-id: d0f5f3769b2963208fd2348840726fa1d3501b63
>> prerequisite-patch-id: 746f63cf58fa3bf62736435c81dba2558aba8e81
>> prerequisite-patch-id: 375bb7847ae74c63d2eacdbd0d73371aef1546fe
>> prerequisite-patch-id: 8a598e22a08b0ec233d0ec56eeb53673eb1b8feb
>> prerequisite-patch-id: b0eba574ddc35ecec2d0e39c0d3351d1b260420e
>> prerequisite-patch-id: 143a1019813b7e4974a67e9eea1f1d599c0fdfdf
>> prerequisite-patch-id: f66d9fe9eb731272b825c9430c15dca89d6c6129
>> prerequisite-patch-id: c8c2d2dd1452c357f73fc4c92e5b564d59a05562
>> prerequisite-patch-id: 273c13464a69354d32790ed7509472d9c2b11231
>> prerequisite-patch-id: adbde1c98b85a16a6500b4210d4f055b9493418c
>> prerequisite-patch-id: 559b6f9af6b26f860896dea4c7eb385ba9bdf0d5
>> prerequisite-patch-id: 94c091c0c78b754d4c842a097a6db126bf6e770f
>> prerequisite-patch-id: f2e549349c09f4675775b40bf9bb9b1f2bec6db8
>> prerequisite-patch-id: c3a6aa788141f5b8782d28dac264470c8081bb97
>> prerequisite-patch-id: 452450f26295dc4fc48dec07ba85538d78bae4b4
>> prerequisite-patch-id: 8e7850077db9ec00df9be4fe3e0e4a4e8b06fbba
>> prerequisite-patch-id: 233db8337812d9d34f99b41ccebd8758a6ada6d9
>> prerequisite-patch-id: 0bbaaf402d2dd50a50aaa6505e5d10e743cf03e5
>>
>
> Is there any reason these emails are percolating through this list so
> slowly ?

I think vger has been slow the last few days, just give it time. At
least I have not yet noticed any mails gone missing.

But please stop with the patch bombs, they are making me crazy. For
example, even just changing the state of 36 patches in patchwork takes
time.

When I said to split the huge patchset into smaller patchsets I didn't
mean that you still send _all_ of them at the _same_ time, and _every_
time you change something. This is even worse than submitting one huge
patchset. The easiest way is to send one patchset first, wait for few
days (ideally wait for me to apply it) and then send a new one.

More info in the link below.

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