From: Marcel Holtmann <marcel@holtmann.org>
To: Emeltchenko Andrei <Andrei.Emeltchenko.news@gmail.com>
Cc: linux-bluetooth@vger.kernel.org
Subject: Re: [RFCv0] Bluetooth: General HCI callback implementation
Date: Thu, 15 Dec 2011 10:40:17 +0100 [thread overview]
Message-ID: <1323942017.1965.79.camel@aeonflux> (raw)
In-Reply-To: <20111215091912.GD15283@aemeltch-MOBL1>
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
prev parent reply other threads:[~2011-12-15 9:40 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-09 13:10 [RFCv0] Bluetooth: General HCI callback implementation Emeltchenko Andrei
2011-12-10 12:47 ` Anderson Lizardo
2011-12-12 9:15 ` Emeltchenko Andrei
2011-12-14 22:20 ` Marcel Holtmann
2011-12-15 9:19 ` Emeltchenko Andrei
2011-12-15 9:40 ` Marcel Holtmann [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1323942017.1965.79.camel@aeonflux \
--to=marcel@holtmann.org \
--cc=Andrei.Emeltchenko.news@gmail.com \
--cc=linux-bluetooth@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox