Hi Andrei,
> > > Add general HCI callback implementation. Can be used for executing
> > > HCI commands from A2MP protocol.
> > > ---
> > > include/net/bluetooth/hci_core.h | 14 +++++++++++
> > > net/bluetooth/hci_core.c | 47 ++++++++++++++++++++++++++++++++++++++
> > > net/bluetooth/hci_event.c | 4 +++
> > > 3 files changed, 65 insertions(+), 0 deletions(-)
> > >
> > > diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
> > > index cc5481d..e473cd2 100644
> > > --- a/include/net/bluetooth/hci_core.h
> > > +++ b/include/net/bluetooth/hci_core.h
> > > @@ -121,6 +121,15 @@ struct adv_entry {
> > > u8 bdaddr_type;
> > > };
> > >
> > > +struct hci_dev;
> > > +
> > > +struct cb_cmd {
> > > + struct list_head list;
> > > + u16 opcode;
> > > + void *opt;
> > > + void (*cb)(struct hci_dev *hdev, void *opt);
> > > +};
> > > +
> >
> > so I am actually thinking that we might just update hci_request into a
> > bit more flexible schema.
>
> Do you mean that we can use blocking hci_request? This may work but some
> commands requires special logic (like executing several Read AMP Assoc
> data requests). I don't know would it be the best solution especially when
> executing from A2MP/L2CAP code.
that is my point exactly. Once we do HCI processing in process context,
we will also have L2CAP running fully in process context. Hence it could
just wait for the result.
> > Gustavo is working on moving everything into a process context, so we
> > can actually sleep. And we could just make a simple premise to only
>
> This would be good, meanwhile I have implemented callback execution in a
> workqueue. I will send second RFC version later today.
Not sure how that helps us right now. I rather wait a bit for Gustavo to
submit his patchset and then we figure this out. It seems to be a more
general problem anyway and we keep hitting it quite of often right now.
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
