linux-kernel - Re: [EXT] Re: [PATCH v7 04/12] wifi: mwifiex: fixed missing WMM IE for assoc req.

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]

Message-ID: <ZXplY3Gi6Fv19Y_t@google.com>
Date:   Wed, 13 Dec 2023 18:16:03 -0800
From:   Brian Norris <briannorris@...omium.org>
To:     David Lin <yu-hao.lin@....com>
Cc:     Francesco Dolcini <francesco@...cini.it>,
        "linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "kvalo@...nel.org" <kvalo@...nel.org>,
        Pete Hsieh <tsung-hsien.hsieh@....com>
Subject: Re: [EXT] Re: [PATCH v7 04/12] wifi: mwifiex: fixed missing WMM IE
 for assoc req.

On Fri, Dec 01, 2023 at 10:47:41PM +0000, David Lin wrote:
> > From: Francesco Dolcini <francesco@...cini.it>
> > Sent: Friday, December 1, 2023 6:19 PM

> > On Tue, Nov 28, 2023 at 04:31:07PM +0800, David Lin wrote:
> > > Remain on channel must be removed after authentication is done.
> > > Otherwise WMM setting for assoiation request will be removed.
> > 
> > Same comment as patch 2, this seems a fixup of commit 1, you should fix
> > that patch, not add a followup fixup commit.
> 
> So you think patch 1 to 4 should be merged as a single patch? In fact,
> patch 2 to 4 is issues reported by our QA for patch 1. If you insisted
> merge all of them, I can do this for patch v8.

In case you didn't get a sufficient answer elsewhere: yes, probably? We
don't care to see:

  patch 1: introduce feature
  patch 2: fix bug in patch 1
  patch 3: fix bug in patch 1 and 2
  patch 4: ...


Just ... actually fix patch 1, and send 1 patch. (Or more, if you have
several logical changes. Be sure to read [1].)

In case you're used to GitHub: we don't work like GitHub, where people
tend to stack a bunch of incremental changes during review, and then the
changes get squashed together before committing. We expect each patch to
be a good commit, and that it will get committed as-is.

If we're interested in the history and evolution of your changes, we can
look at the mailing list archives.

Brian

[1] https://docs.kernel.org/process/submitting-patches.html#separate-your-changes