On Wed, 2016-07-13 at 16:45 +0000, Lars-Peter Clausen wrote:
> On 07/13/2016 06:18 PM, Jiang, Dave wrote:
> > On Wed, 2016-07-13 at 08:00 +0000, Lars-Peter Clausen wrote:
> > > On 07/13/2016 12:24 AM, Dave Jiang wrote:
> > > > Lars,
> > > > Here's the reworked code per your comment. Let me know if this
> > > > matches
> > > > what you are thinking. Patch 2/4 shows how the driver provides
> > > > the
> > > > error, and patch 3,4/4 show how the errors are received by
> > > > upper
> > > > layer.
> > > > The callback is an addition so people should be able to
> > > > transition
> > > > to the new one when convenient and the old callback still
> > > > remains
> > > > for
> > > > compatibility. We should be able to expand on the new callback
> > > > as
> > > > needed since I don't know much about the slave DMA side of
> > > > things.
> > > > If
> > > > you are ok with it I'll clean it up and add the proper
> > > > comments/docs
> > > > etc and resubmit.
> > >
> > > Looks OK.
> > >
> > > For the dispatching between the two callback functions there
> > > should
> > > be a
> > > helper function in the core and all drivers should be update to
> > > use
> > > this
> > > helper, so that clients can rely on that the right callback will
> > > be
> > > called.
> > > If no result is provided by the driver the helper function should
> > > provide a
> > > dummy result with no errors and no residue.
> > >
> > > What makes the whole thing slightly tricky is that some drivers
> > > store
> > > the
> > > callback on the stack and free (or recycle) the descriptor before
> > > the
> > > callback is called. Since this is actually required for correct
> > > operation we
> > > have to work with it.
> > >
> > > Something like this might work.
> >
> > Maybe I'm missing something. In the example below you proposed two
> > steps. Implement helper function and update drivers, and then
> > change
> > the helper function to provide results and update the drivers again
> > since the new helper function require extra parameter. That would
> > require us to fix up all the drivers twice. Is there anything that
> > prevents us to go directly to step two and implement the the new
> > helper
> > function with results and only touch all the drivers once?
>
> The idea is to include the new extra parameter in the first step.
> It's just
> not functional yet and every driver has to pass NULL instead of a
> result
> struct. Then once the infrastructure to handle the result parameter
> has been
> put in place it is possible to add support for result reporting to
> individual drivers. Drivers which have not implemented result
> reporting will
> still continue to work and they'll also continue to work with clients
> that
> want to use the result callback.
>
> The reason for the multi-step approach is to separate refactoring
> from
> implementing new features, but at the same time keep the code
> compilable and
> functional at all steps.
>
Actually nevermind. I was cross eyed and didn't see the additional
parameter in the first step and thus was confused. ��.n��������+%������w��{.n��������)�)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
