Re: [PATCH v4 2/5] dma-buf/sync_file: refactor fence storage in struct sync_file

[Greg Kroah-Hartman]

On Thu, Jul 28, 2016 at 04:30:36PM +0530, Sumit Semwal wrote:
> Hi Greg,
> 
> On 19 July 2016 at 17:51, Sumit Semwal <sumit.semwal@xxxxxxxxxx> wrote:
> > (Adding Greg KH)
> >
> > Hi Greg,
> >
> > On 19 July 2016 at 17:45, Sumit Semwal <sumit.semwal@xxxxxxxxxx> wrote:
> >> Hi Greg,
> >>
> >>
> >> On 12 July 2016 at 23:38, Gustavo Padovan <gustavo@xxxxxxxxxxx> wrote:
> >>> From: Gustavo Padovan <gustavo.padovan@xxxxxxxxxxxxxxx>
> >>>
> >>> Create sync_file->fence to abstract the type of fence we are using for
> >>> each sync_file. If only one fence is present we use a normal struct fence
> >>> but if there is more fences to be added to the sync_file a fence_array
> >>> is created.
> >>>
> >>> This change cleans up sync_file a bit. We don't need to have sync_file_cb
> >>> array anymore. Instead, as we always have  one fence, only one fence
> >>> callback is registered per sync_file.
> >>>
> >> Since this is a simple change in sync_debug,c, may I request for your
> >> Ack so I could take it along with the other dma-buf patches?
> >>
> > Missed the fact that you weren't CCed; for this simple update to
> > sync_debug,c, may I request for your Ack so I can take it with dam-buf
> > patches?
> 
> Gentle reminder please: since it's a small change, if you could Ack
> it, I'd be happy to take it along with the dma-buf patches and queue
> it up.

Ugh, sorry, vacation and travel and merge window hasn't been good to me
this cycle...

This is fine with me, please take it through your tree if you want to,
and again, sorry for the delay in responding.  Usually, for staging
bits, if you want/need to merge something due to an api change, no need
to wait for me, I can handle any merge conflicts / issues that might
come up after the fact.

Acked-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>

thanks,

greg k-h