[PATCH V14 5/9] dma: qcom_hidma: implement lower level hardware interface
Sinan Kaya
okaya at codeaurora.org
Mon Mar 14 06:56:01 PDT 2016
Hi Vinod,
On 3/13/2016 11:59 AM, Vinod Koul wrote:
> I would write this as:
>
> memcpy(lldev->tre_ring + lldev->tre_write_offset,
> &tre->tre_local[0], TRE_SIZE);
>
> To make it look more readable
Got it.
>
>>>> > >>
>>>>>>>>>> > >>>>>>>> + lldev->tx_status_list[tre->idx].err_code = 0;
>>>>>>>>>> > >>>>>>>> + lldev->tx_status_list[tre->idx].err_info = 0;
>>>>>>>>>> > >>>>>>>> + tre->queued = 1;
>>>>>>>>>> > >>>>>>>> + lldev->pending_tre_count++;
>>>>>> > >>>>
>>>>>> > >>>> Is this the only one without alignment? I couldn't understand what you mean by
>>>>>> > >>>> above one?
>>>> > >> quoting Coding Style:
>>>> > >>
>>>> > >> Statements longer than 80 columns will be broken into sensible chunks, unless
>>>> > >> exceeding 80 columns significantly increases readability and does not hide
>>>> > >> information.
>>> > >
>>>> > >> "Descendants are always substantially shorter than the parent and
>>>> > >> are placed substantially to the right."
>>>> > >>
>>>> > >>
>>> > >
>>> > > Sorry for my poor English. I never got this rule.
>>> > >
>>> > > Which one is a "substantially" right? Can you give me an example?
>>> > >
>>> > > I need to understand how you'd write this to satisfy the above rule.
>>> > >
>>> > > like this:
>>> > >
>>> > > memcpy(lldev->tre_ring + lldev->tre_write_offset, &tre->tre_local[0],
>>> > > TRE_SIZE);
> No
>
>>> > >
>>> > > or
>>> > >
>>> > > memcpy(lldev->tre_ring + lldev->tre_write_offset,
>>> > > &tre->tre_local[0], TRE_SIZE);
> Better or above
>
I'll do this to be consistent with the rest of the code.
Please let me know when you want to have the updated version. I don't want to post v16
while you are reviewing the rest of the code.
--
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
More information about the linux-arm-kernel
mailing list