On Wed, 2014-02-19 at 19:11 +0200, Luiz Augusto von Dentz wrote: > Hi Patrick, > > On Tue, Feb 18, 2014 at 6:54 PM, Patrick Ohly <patrick.ohly@xxxxxxxxx> wrote: > > On Tue, 2014-02-18 at 11:30 +0200, Luiz Augusto von Dentz wrote: > >> Hi Patrick, > >> > >> On Tue, Feb 18, 2014 at 11:09 AM, Patrick Ohly <patrick.ohly@xxxxxxxxx> wrote: > > I think I would prefer to *not* get errors when Suspend() is called on > > an already suspended transfer or when Resume() is called on a running > > transfer. The rationale is that the caller will typically only care > > about the end result and not so much whether it was the one who > > triggered the change. If we remove NotInProgress resp. InProgress errors > > from the API, then such a caller can treat all errors as fatal problem, > > without having to check the exact error. > > Actually the NotInProgress error is for transfer queued, I guess for > this case it makes sense to return an error since otherwise we would > have to queue commands to be send when the transfer becomes active I > believe this should probably be considered an error. Agreed, if suspending can't be done, then an error needs to be returned. It would be good to add information about the error to the documentation, so that apps get at least some hint what they are supposed to do in case of such an error (like aborting the queued transfer (most likely) or waiting for it to start before suspending it (seems a bit odd, but perhaps it is useful sometimes)). -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
