Hi Johan, >>>> When hci_req_run() calls its provided complete function and one of the >>>> HCI commands in the sequence fails, then provide the opcode of failing >>>> command. In case of success HCI_OP_NOP is provided since all commands >>>> completed. >>>> >>>> This patch fixes the prototype of hci_req_complete_t and all its users. >>>> >>>> Signed-off-by: Marcel Holtmann <marcel@xxxxxxxxxxxx> >>>> --- >>>> include/net/bluetooth/bluetooth.h | 2 +- >>>> net/bluetooth/hci_conn.c | 2 +- >>>> net/bluetooth/hci_core.c | 9 ++++---- >>>> net/bluetooth/hci_request.c | 3 ++- >>>> net/bluetooth/mgmt.c | 44 ++++++++++++++++++++++----------------- >>>> 5 files changed, 34 insertions(+), 26 deletions(-) >>> >>> Applied to bluetooth-next. Thanks. >>> >>> Would it make sense to also change the return value of the callback from >>> void to bool. That way the callback could let the request handling code >>> know whether to proceed even after a single command failure or to abort >>> the request. >> >> do we need this actually? Is there a case where we can continue if one >> of the commands fails. > > I was mainly thinking of the various quirks we have for not issuing > certain commands for adapters that don't properly support them - another > way would be to simply ignore the errors from failing commands and > proceed with the init sequence anyway. But you're right, this may not be > a very useful feature. initially we did ignore failing commands if we did not consider them crucial. I think that was a big mistake. Actually having controller init fail and people having to dig out why these vendors screwed it up is a good idea. That way we know exactly what is going on. So I really want to keep it that way. >> I think what we actually need is to have a way to revert the actions >> taken by an earlier command. So if a command in sequence configured >> something, we might want to revert that action when a later command >> fails. > > In theory sounds like a nice feature, but doubt this will work out very > well in the end, at least not in a generic way. If an HCI command fails > there's no guarantee that the "undo" HCI command wont fail too. Agreed. You can not convert all of it. However we could worst case just reset the whole stack. Which is a feature that we need anyway to handle the Hardware Error event. Regards Marcel -- 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
