[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAK8P3a1g1zQtY6o1hnXGxe5moZ5-z9vR4fuN8VPtSvKipALMcw@mail.gmail.com>
Date: Wed, 5 Jan 2022 17:01:47 -0500
From: Arnd Bergmann <arnd@...db.de>
To: Christophe JAILLET <christophe.jaillet@...adoo.fr>
Cc: Arnd Bergmann <arnd@...db.de>, Richard Henderson <rth@...ddle.net>,
Ivan Kokshaysky <ink@...assic.park.msu.ru>,
Matt Turner <mattst88@...il.com>,
Logan Gunthorpe <logang@...tatee.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Mike Rapoport <rppt@...nel.org>,
David Hildenbrand <david@...hat.com>,
martin.oliveira@...eticom.com, alpha <linux-alpha@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
kernel-janitors <kernel-janitors@...r.kernel.org>
Subject: Re: [PATCH] alpha: Remove usage of the deprecated "pci-dma-compat.h" API
On Wed, Jan 5, 2022 at 4:23 PM Christophe JAILLET
<christophe.jaillet@...adoo.fr> wrote:
> Le 03/01/2022 à 02:51, Arnd Bergmann a écrit :
> > On Sun, Jan 2, 2022 at 10:32 AM Christophe JAILLET
> > It looks like the number of remaining files that use the old
> > interfaces has gone down
> > a lot more since you last sent these patches. I would suggest you send them as a
> > series that includes the patch to remove the header as the last change, and
> > ask Andrew to pick up the ones that remain after this resend into the -mm tree,
> > possibly after the next -rc1. How many patches do you have left?
> >
>
> This would be ~ 10 patches.
> I sent recently some missing ones because I was not aware of
> --include-headers. So .h files were missing in my previous patches.
>
>
> The main remaining issue is linked to files in message/fusion.
> The patches are big.
> They have to be looked at carefully because it touches some GFP flags
> when s/pci_alloc_consistent/dma_alloc_coherent/.
>
> My last try did not get any attention.
> Even [1] which is purely mechanical
>
> I'll try another approach without trying to turn some (hidden)
> GFP_ATOMIC into GFP_KERNEL.
> 1st patch: only mechanical changes done with coccinelle, leaving GFP_ATOMIC
> 2nd patch: add some FIXME comments explaining why some could be turned
> into GFP_KERNEL
> 3rd patch: remove the comments and update the GFP flags accordingly.
>
> So, a maintainer could either apply 1 (no risk at all, should even
> generate the same .o file), or 1+2 (only FIXME comments for future
> analysis) or 1+2+3 for full clean-up (if he trusts me and/or has time to
> check my explanations).
>
> This way, I hope that some could at least apply the first one.
If it's down to 10 patches, just send them as a series with Andrew Morton,
Christoph Hellwig and me as recipients, in addition to the respective
subsystem maintainers. Christoph and I can make sure that every
patch is reviewed and then it's either the subsystem maintainers that pick
them up, and one of us that applies all the remaining ones in the mm,
dma-mapping, or asm-generic trees.
What I've seen from your patches all looks good, and I just want
them to be done, no need to wait forever for maintainers to reply
when they have had their chance several times before.
Arnd
Powered by blists - more mailing lists