Re: [PATCH rtw-next v2] wifi: rtl8xxxu: Detect the maximum supported channel width

On 5/12/26 11:36, Johannes Berg wrote:
> On Tue, 2026-05-12 at 10:54 +0200, Thorsten Leemhuis wrote:
>>>> You
>>>> can cherry-pick or directly apply the fix to a pending branch (or even
>>>> ask Linus to merge it directly from the list, but that is likely not
>>>> worth it here) and git will normally later notice this and fully
>>>> automatically handle everything when the fix comes in again during the
>>>> next merge window.
>>>
>>> I know git can handle that, but is it an acceptable practice for single one
>>> commit to appear twice?
>>
>> Depends on whom you ask. I'd say: It's kinda normal. It's best avoided
>> if there is no need, but if there is a need (like here) it's fine. And
>> some subsystems it even happens regularly iirc.
> > FWIW, it's generally frowned upon and actually uncommon enough that
> linux-next actively warns about it [1] (or at least used to?), so I
> wouldn't really say your description here is all that accurate.
>
> [1] https://lore.kernel.org/lkml/?q=%22duplicate+patch+in+the%22
> 
> What does happen fairly frequently is the same immutable commit getting
> merged through different branches, but that's a single commit, not the
> same change being committed twice.

Well, that made me look up my "regularly iirc" claim. Now I remember
where I got that from: the cherry-picking (which results in a second
commit-id) the DRM subsystem regularly did:
https://lwn.net/Articles/1005222/

That's was early 2025, so the workflows there might have changed in
between due to the criticism. But from a quick 'git log --grep "(cherry
picked from commit"' in mainline it doesn't look like it did. Here is
one example of a commit that made it into 7.0 that sits with a different
commit-id in -next a second time:

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/log/?qt=grep&q=Avoid+memory+allocations+in+xe_device_declare_wedged
b08ceb44386680 ("drm/xe: Avoid memory allocations in
xe_device_declare_wedged()") [next-20260330]
56b7432b7e8e6a ("drm/xe: Avoid memory allocations in
xe_device_declare_wedged()") [v7.0-rc7]

Here are a few from the current cycle:

0d831487b5be0a ("drm/amdgpu: nuke amdgpu_userq_fence_slab v2")
[next-20260506]
4e02e0afa95f69 ("drm/amdgpu: nuke amdgpu_userq_fence_slab v2") [v7.1-rc3]
1fc6c8ab45dbee ("drm/amdgpu/userq: fix access to stale wptr mapping")
[next-20260506]
6da7b1242da445 ("drm/amdgpu/userq: fix access to stale wptr mapping")
[v7.1-rc3]
d12d05c4bc4c15 ("drm/amdkfd: Check if there are kfd porcesses using adev
by kfd_processes_count") [next-20260506]
81665e35f143d9 ("drm/amdkfd: Check if there are kfd porcesses using adev
by kfd_processes_count") [v7.1-rc3]
d9af8263b82b6e ("drm/amdgpu: zero-initialize GART table on allocation")
[next-20260506]
e6c2e6c2e1fa06 ("drm/amdgpu: zero-initialize GART table on allocation")
[v7.1-rc3]

I found a few dozen more. But this is not my area of expertise, so
please correct me if I'm missing something.

In the end I don't care about all that. I just think it would be good to
get this regression fixed in mainline this cycle. And I suspect Linus
wants that, too. For example due to previous discussions like this:
https://lore.kernel.org/all/CAHk-=wis_qQy4oDNynNKi5b7Qhosmxtoj1jxo5wmB6SRUwQUBQ@mail.gmail.com/

Ciao, Thorsten