linux-kernel - Re: [PATCH] staging: rtl8192e: Rename variable bCurrentHTSupport

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 18 Jul 2023 21:56:24 +0200
From:   Philipp Hortmann <philipp.g.hortmann@...il.com>
To:     Tree Davies <tdavies@...kphysics.net>
Cc:     gregkh@...uxfoundation.org, dan.carpenter@...aro.org,
        linux-staging@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] staging: rtl8192e: Rename variable bCurrentHTSupport

On 7/15/23 22:14, Tree Davies wrote:
> Philipp,
> 
> I think I understand what I did wrong. Each of these original patches were
> created/based from the same commit hash. So it makes sense that only the
> first one applied would apply cleanly and the others would fail.
> 
> My apologies,
> Tree

Hi Tree,

you could work this way if you ensure that each patch does not modify 
code (and some lines above and below) a previous patch modified. But it 
is not a good way to do so. Existing tools assume that you create your 
commits onto each other and then make patches out of them.

Another issue right now is that approximately 18 patches send in and are 
possibly applied (for rtl8192e). Your patches need to fit onto those 
patches. Otherwise they cannot be applied and will be rejected.

Typically Greg applies all patches once a week. But it seems that he has 
a bunch of other more urgent tasks. So you need to focus on other kernel 
related task like educate yourself or prepare patches without sending 
them in.

Thanks for your support.

Bye Philipp