> -----Original Message----- > From: Robin Murphy [mailto:robin.mur...@arm.com] > Sent: Monday, August 01, 2016 10:53 PM > To: 이광우(LEE KWANGWOO) MS SW; Russell King - ARM Linux; Catalin Marinas; Will > Deacon; Mark Rutland; > linux-arm-ker...@lists.infradead.org > Cc: 김현철(KIM HYUNCHUL) MS SW; linux-kernel@vger.kernel.org; 정우석(CHUNG WOO SUK) > MS SW > Subject: Re: [PATCH v2] arm64: mm: convert __dma_* routines to use start, size > > On 01/08/16 14:36, Robin Murphy wrote: > > On 01/08/16 00:45, kwangwoo....@sk.com wrote: > > [...] > >>>>> -----8<----- > >>>>> diff --git a/arch/arm64/include/asm/assembler.h > >>>>> b/arch/arm64/include/asm/assembler.h > >>>>> index 10b017c4bdd8..1c005c90387e 100644 > >>>>> --- a/arch/arm64/include/asm/assembler.h > >>>>> +++ b/arch/arm64/include/asm/assembler.h > >>>>> @@ -261,7 +261,16 @@ lr .req x30 // link register > >>>>> add \size, \kaddr, \size > >>>>> sub \tmp2, \tmp1, #1 > >>>>> bic \kaddr, \kaddr, \tmp2 > >>>>> -9998: dc \op, \kaddr > >>>>> +9998: > >>>>> + .ifeqs "\op", "cvac" > >>>>> +alternative_if_not ARM64_WORKAROUND_CLEAN_CACHE > >>>>> + dc cvac, \kaddr > >>>>> +alternative_else > >>>>> + dc civac, \kaddr > >>>>> +alternative_endif > >>>>> + .else > >>>>> + dc \op, \kaddr > >>>>> + .endif > >>>>> add \kaddr, \kaddr, \tmp1 > >>>>> cmp \kaddr, \size > >>>>> b.lo 9998b > >>>> > >>>> I agree that it looks not viable because it makes the macro bigger and > >>>> conditional specifically with CVAC op. > >>> > >>> Actually, having had a poke around in the resulting disassembly, it > >>> looks like this does work correctly. I can't think of a viable reason > >>> for the whole dcache_by_line_op to ever be wrapped in yet another > >>> alternative (which almost certainly would go horribly wrong), and it > >>> would mean that any other future users are automatically covered for > >>> free. It's just horrible to look at at the source level. > >> > >> Then, Are you going to send a patch for this? Or should I include this > >> change? > > > > I'll do a bit more testing just to make sure, then spin a separate patch > > (and try to remember to keep you on CC..) > > ...and said patch turns out to conflict with 823066d9edcd, since I > hadn't realised it's already been fixed! So you can go ahead with the > dcache_by_line_op cleanup as well, just rebase onto arm64/for-next/core > (or linux/master, since it's been pulled already).
Thank you very much for the information! I'll rebase with it. > Robin. Best Regards, Kwangwoo Lee
