[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200501171828.GA673260@iweiny-DESK2.sc.intel.com>
Date: Fri, 1 May 2020 10:18:28 -0700
From: Ira Weiny <ira.weiny@...el.com>
To: Christoph Hellwig <hch@...radead.org>
Cc: linux-kernel@...r.kernel.org,
Andrew Morton <akpm@...ux-foundation.org>,
Christian Koenig <christian.koenig@....com>,
Huang Rui <ray.huang@....com>,
Peter Zijlstra <peterz@...radead.org>,
Dave Hansen <dave.hansen@...ux.intel.com>,
dri-devel@...ts.freedesktop.org,
"James E.J. Bottomley" <James.Bottomley@...senpartnership.com>,
Max Filippov <jcmvbkbc@...il.com>,
Paul Mackerras <paulus@...ba.org>,
"H. Peter Anvin" <hpa@...or.com>, sparclinux@...r.kernel.org,
Thomas Gleixner <tglx@...utronix.de>,
Helge Deller <deller@....de>, x86@...nel.org,
linux-csky@...r.kernel.org, Ingo Molnar <mingo@...hat.com>,
linux-snps-arc@...ts.infradead.org, linux-xtensa@...ux-xtensa.org,
Borislav Petkov <bp@...en8.de>,
Andy Lutomirski <luto@...nel.org>,
Dan Williams <dan.j.williams@...el.com>,
linux-arm-kernel@...ts.infradead.org,
Chris Zankel <chris@...kel.net>,
Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
linux-parisc@...r.kernel.org, linux-mips@...r.kernel.org,
linuxppc-dev@...ts.ozlabs.org,
"David S. Miller" <davem@...emloft.net>
Subject: Re: [PATCH V1 00/10] Remove duplicated kmap code
On Fri, May 01, 2020 at 01:54:56AM -0700, Christoph Hellwig wrote:
> In addition to the work already it the series, it seems like
> LAST_PKMAP_MASK, PKMAP_ADDR and PKMAP_NR can also be consolidated
> to common code.
Agreed, I mentioned in the cover letter there are similarities...
>
> Also kmap_atomic_high_prot / kmap_atomic_pfn could move into common
> code, maybe keyed off a symbol selected by the actual users that
> need it. It also seems like it doesn't actually ever need to be
> exported.
... but these are not as readily obvious, at least to me. I do see a pattern
but the differences seemed subtle enough that it would take a while to ensure
correctness. So I'd like to see this series go in and build on it.
>
> This in turn would lead to being able to allow io_mapping_map_atomic_wc
> on all architectures, which might make nouveau and qxl happy, but maybe
> that can be left for another series.
I agree, that this should be follow on patches. I still need to fix the
bisect-ability and I don't want to bog down 0-day with a longer series.
Thanks for the review!
Ira
Powered by blists - more mailing lists