From: "Gustavo F. Padovan" <padovan@profusion.mobi>
To: "John W. Linville" <linville@tuxdriver.com>
Cc: linux-wireless@vger.kernel.org, linux-bluetooth@vger.kernel.org
Subject: Re: pull request: bluetooth-2.6 2010-11-22
Date: Mon, 22 Nov 2010 18:13:31 -0200 [thread overview]
Message-ID: <20101122201330.GE23109@vigoh> (raw)
In-Reply-To: <20101122193029.GE2117@tuxdriver.com>
* John W. Linville <linville@tuxdriver.com> [2010-11-22 14:30:30 -0500]:
> On Mon, Nov 22, 2010 at 04:14:11PM -0200, Gustavo F. Padovan wrote:
> > Hi John,
> >
> > Following batch is intended to 2.6.37, it includes a very trivial return
> > err fix from myself and an remote name request fix from Johan Hedberg.
> > This fix move the remote name request (during the connection creation
> > process) to the kernelspace. In addition we have removed this operation
> > from BlueZ in userspace. Quoting part of Johan's patch which already
> > explain the change:
> >
> > "So far userspace has been responsible for this extra name request but
> > tighter control is needed in order not to flood Bluetooth controllers
> > with two many commands during connection creation. It has been shown
> > that some controllers simply fail to function correctly if they get too
> > many (almost) simultaneous commands during connection creation. The
> > simplest way to acheive better control of these commands is to move
> > their sending completely to the kernel side."
> >
> > As side effect, we have a clean up patch in preparation to this fix.
> >
> > Please pull, or let me know any problems you find here. Thanks.
>
> The return code fix seems reasonable -- small and obvious, etc.
>
> The other fixes are larger than I would like to see. What is the
> effect of the bug? Does the Bluetooth controller stop completely?
> Does it cause a crash?
>
> Is this a newly-introduced bug? Or one that has been around for
> a while?
No, it is not serious like that. By not having this patch we won't have
the remote name request command during connection setup, The remote name
request was done by bluetoothd, but we already removed it from
userspace. It is not a really big problem once we also cache the remote
devices names in bluetoothd.
So I'm seeing no way to convince you tou pull this patch (actually I'm
now also covinced to queue this to bluetooth-next). I'll sent a new
pull request soon, after wait some time for new patches.
--
Gustavo F. Padovan
http://profusion.mobi
next prev parent reply other threads:[~2010-11-22 20:14 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-22 18:14 pull request: bluetooth-2.6 2010-11-22 Gustavo F. Padovan
2010-11-22 19:30 ` John W. Linville
2010-11-22 20:13 ` Gustavo F. Padovan [this message]
2010-11-22 22:03 ` Johan Hedberg
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=20101122201330.GE23109@vigoh \
--to=padovan@profusion.mobi \
--cc=linux-bluetooth@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
/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;
as well as URLs for NNTP newsgroup(s).