[PATCH v2] arm64: mm: convert __dma_* routines to use start, size

[kwangwoo.lee at sk.com]

> -----Original Message-----
> From: Robin Murphy [mailto:robin.murphy at 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-kernel at lists.infradead.org
> Cc: 김현철(KIM HYUNCHUL) MS SW; linux-kernel at 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.lee at 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