[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <a7e3fdcd-d5e6-4261-85be-3ec1221edf24@app.fastmail.com>
Date: Thu, 26 Oct 2023 13:36:13 +0100
From: "Jiaxun Yang" <jiaxun.yang@...goat.com>
To: "Baoquan He" <bhe@...hat.com>, linux-kernel@...r.kernel.org
Cc: linux-arch@...r.kernel.org, linux-mm@...ck.org,
"Andrew Morton" <akpm@...ux-foundation.org>,
"Arnd Bergmann" <arnd@...db.de>, mpe@...erman.id.au,
"Geert Uytterhoeven" <geert@...ux-m68k.org>,
"Luis Chamberlain" <mcgrof@...nel.org>, hch@...radead.org,
"Thomas Bogendoerfer" <tsbogend@...ha.franken.de>,
"Florian Fainelli" <f.fainelli@...il.com>, deller@....de
Subject: Re: [PATCH v5 0/4] arch/*/io.h: remove ioremap_uc in some architectures
在2023年9月21日九月 下午12:04,Baoquan He写道:
> This patchset tries to remove ioremap_uc() in the current architectures
> except of x86 and ia64. They will use the default ioremap_uc version
> in <asm-generic/io.h> which returns NULL. Anyone who wants to add new
> invocation of ioremap_uc(), please consider using ioremap() instead or
> adding a new ARCH specific ioremap_uc(), or refer to the callsite
> in drivers/video/fbdev/aty/atyfb_base.c.
>
> This change won't cuase breakage to the current kernel because in the
> only ioremap_uc callsite, an adjustment is made to eliminate impact in
> patch 1 of this series.
>
> To get rid of all of them other than x86 and ia64, add asm-generic/io.h
> to asm/io.h of mips ARCH. With this adding, we can get rid of the
> ioremap_uc() in mips too. This is done in patch 2. And a followup patch
> 4 is added to remove duplicated code according to Arnd's suggestion.
>
> Test:
> =====
> Except of Jiaxun's efficient testing on patch 2/4, I also did cross compiling
> of this series on mips64, building passed.
>
For whole series:
Tested-by: Jiaxun Yang <jiaxun.yang@...goat.com>
Hi Arnd and Thomas,
I've got some work pending based on this series, however I'm unclear about
which tree this series will go since both of you give acked-by.
Given that there are some tree-wide modifications, I guess it should go into
Arnd's asm-generic tree?
Thanks
--
- Jiaxun
Powered by blists - more mailing lists