Thx Christoph, On Fri, Aug 16, 2019 at 3:03 PM Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > > On Thu, Aug 15, 2019 at 07:28:57PM +0800, guoren@xxxxxxxxxx wrote: > > From: Guo Ren <ren_guo@xxxxxxxxx> > > > > Implement the following apis to meet usage in different scenarios. > > > > - ioremap (NonCache + StrongOrder) > > - ioremap_nocache (NonCache + StrongOrder) > > - ioremap_wc (NonCache + WeakOrder ) > > - ioremap_cache ( Cache + WeakOrder ) > > > > Also change flag VM_ALLOC to VM_IOREMAP in get_vm_area_caller. > > Looks generally fine, but two comments: > > - do you have a need for ioremap_cache? We are generally try to > phase it out in favour of memremap, and it is generally only used > by arch specific code. Yes, some drivers of our customers use ioremap_cache to map phy_addr which isn't belong to system memory. > - I have a big series pending to clean up the mess with our > ioremap_* functions, including adding a generic implementation > that csky should be able to use. Unless this patch is urgent it > might make sense to rebase it on top. Here is my current tree, I > plan to post it soon: > > http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/generic-ioremap I agree to use GENERIC_IOREMAP, but I want to add csky support GENERIC_IOREMAP patch by myself. You could remove "csky: use generic ioremap" in your patchset first and I'll add support GENERIC_IORMAP patch later. Then we won't get confilct :) -- Best Regards Guo Ren ML: https://lore.kernel.org/linux-csky/
