From: Andrew Morton <akpm@linux-foundation.org>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Yury Norov <yury.norov@gmail.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux-Arch <linux-arch@vger.kernel.org>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
Yoshinori Sato <ysato@users.osdn.me>,
Brian Cain <bcain@codeaurora.org>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
Jonas Bonn <jonas@southpole.se>,
Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>,
"James E.J. Bottomley" <James.Bottomley@hansenpartnership.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Heiko Carstens <hca@linux.ibm.com>, Rich Felker <dalias@libc.org>,
David Hildenbrand <david@redhat.com>,
Jaegeuk Kim <jaegeuk@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Rasmus Villemoes <linux@rasmusvillemoes.dk>,
Alexander Lobakin <alobakin@pm.me>,
Samuel Mendoza-Jonas <sam@mendozajonas.com>,
Jakub Kicinski <kuba@kernel.org>,
Daniel Bristot de Oliveira <bristot@redhat.com>,
Alexey Klimov <aklimov@redhat.com>,
Ingo Molnar <mingo@redhat.com>
Subject: Re: [PATCH 7/8] all: replace find_next{,_zero}_bit with find_first{,_zero}_bit where appropriate
Date: Mon, 14 Jun 2021 18:07:06 -0700 [thread overview]
Message-ID: <20210614180706.1e8564854bfed648dd4c039b@linux-foundation.org> (raw)
In-Reply-To: <CAHp75VeXJcPai=w3Fbx11TPf_CZTusD6U_E2R+XSaCcebV7uBw@mail.gmail.com>
On Sun, 13 Jun 2021 12:41:38 +0300 Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
> On Sunday, June 13, 2021, Yury Norov <yury.norov@gmail.com> wrote:
>
> > On Sun, Jun 13, 2021 at 12:47:31AM +0300, Andy Shevchenko wrote:
> > > On Sat, Jun 12, 2021 at 3:39 PM Yury Norov <yury.norov@gmail.com> wrote:
> > > >
> > > > find_first{,_zero}_bit is a more effective analogue of 'next' version
> > if
> > > > start == 0. This patch replaces 'next' with 'first' where things look
> > > > trivial.
> > >
> > > Depending on the maintainers (but I think there will be at least few
> > > in this case) they would like to have this be split on a per-driver
> > > basis.
> > > I counted 17 patches. I would split.
> > >
> > > Since many of them are independent you may send without Cc'ing all
> > > non-relevant people in each case.
> >
> > submitting-patches.rst says:
> >
> > On the other hand, if you make a single change to numerous files,
> > group those changes into a single patch. Thus a single logical
> > change
> > is contained within a single patch.
> >
> > Also refer 96d4f267e40f9 ("Remove 'type' argument from access_ok()
> > functioin.")
>
>
> Mixing arch and non arch is not good, fs stuff can be separated as well,
> so, at least 4 patches. Otherwise it might be not good for bissection /
> reverting.
Actually I don't have a problem taking/merging splatterpatches like
this one, as long as all relevant maintainers are cc'ed throughout.
If they review/test/ack then great. If they don't then their stuff
breaks during -rc and they get to fix it (this almost never happens
anyway).
If the splatterpatch is prepared as a series of patches then that's OK
as well. I'll queue them all up behind linux-next so I can see when
maintainers have merged them and drop the individual patches as/when
needed.
On balance... I guess individual patches is a bit better because the
more diligent maintainers will sometimes merge them and get them better
tested. But in practice, 95% of maintainers will eyeball it, say "yeah
fine" and let Andrew handle it.
next prev parent reply other threads:[~2021-06-15 2:46 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-12 12:36 [PATCH 0/8] all: use find_next_*_bit() instead of find_first_*_bit() where possible Yury Norov
2021-06-12 12:36 ` [PATCH 1/8] bitops: protect find_first_{,zero}_bit properly Yury Norov
2021-06-12 21:38 ` Andy Shevchenko
2021-06-29 1:29 ` Yury Norov
2021-06-12 12:36 ` [PATCH 2/8] bitops: move find_bit_*_le functions from le.h to find.h Yury Norov
2021-06-12 12:36 ` [PATCH 3/8] include: move find.h from asm_generic to linux Yury Norov
2021-06-12 12:36 ` [PATCH RESEND 4/8] arch: remove GENERIC_FIND_FIRST_BIT entirely Yury Norov
2021-06-12 12:36 ` [PATCH 5/8] lib: add find_first_and_bit() Yury Norov
2021-06-14 15:45 ` Alexey Klimov
2021-06-12 12:36 ` [PATCH 6/8] cpumask: use find_first_and_bit() Yury Norov
2021-06-12 12:36 ` [PATCH 7/8] all: replace find_next{,_zero}_bit with find_first{,_zero}_bit where appropriate Yury Norov
2021-06-12 21:47 ` Andy Shevchenko
2021-06-13 0:32 ` Yury Norov
[not found] ` <CAHp75VeXJcPai=w3Fbx11TPf_CZTusD6U_E2R+XSaCcebV7uBw@mail.gmail.com>
2021-06-15 1:07 ` Andrew Morton [this message]
2021-06-12 12:36 ` [PATCH 8/8] tools: sync tools/bitmap with mother linux Yury Norov
2021-06-13 23:16 ` [PATCH] cpumask: replace cpumask_next_* with cpumask_first_* where appropriate Yury Norov
2021-06-29 1:48 ` [PATCH 0/8] all: use find_next_*_bit() instead of find_first_*_bit() where possible Yury Norov
2021-06-29 16:18 ` Andy Shevchenko
2021-07-28 15:00 ` Yury Norov
2021-07-28 15:13 ` Joe Perches
2021-07-28 15:55 ` Yury Norov
2021-07-28 16:06 ` Joe Perches
2021-07-28 16:28 ` Yury Norov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210614180706.1e8564854bfed648dd4c039b@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=James.Bottomley@hansenpartnership.com \
--cc=aklimov@redhat.com \
--cc=alobakin@pm.me \
--cc=andriy.shevchenko@linux.intel.com \
--cc=andy.shevchenko@gmail.com \
--cc=arnd@arndb.de \
--cc=bcain@codeaurora.org \
--cc=benh@kernel.crashing.org \
--cc=bristot@redhat.com \
--cc=catalin.marinas@arm.com \
--cc=dalias@libc.org \
--cc=david@redhat.com \
--cc=geert@linux-m68k.org \
--cc=hca@linux.ibm.com \
--cc=jaegeuk@kernel.org \
--cc=jonas@southpole.se \
--cc=kuba@kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@rasmusvillemoes.dk \
--cc=mingo@redhat.com \
--cc=palmer@dabbelt.com \
--cc=sam@mendozajonas.com \
--cc=stefan.kristiansson@saunalahti.fi \
--cc=tsbogend@alpha.franken.de \
--cc=will@kernel.org \
--cc=ysato@users.osdn.me \
--cc=yury.norov@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.