[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFz=9pmC5gBY11Lcwizro1KzSt1ms6iUkOLUNJovHu4k4A@mail.gmail.com>
Date: Fri, 17 Apr 2015 17:03:09 -0400
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Marcel Holtmann <marcel@...tmann.org>
Cc: Jörg Otte <jrg.otte@...il.com>,
"Gustavo F. Padovan" <gustavo@...ovan.org>,
Johan Hedberg <johan.hedberg@...il.com>,
"bluez mailin list (linux-bluetooth@...r.kernel.org)"
<linux-bluetooth@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [V4.1] Regression: Bluetooth mouse not working.
On Fri, Apr 17, 2015 at 4:35 PM, Marcel Holtmann <marcel@...tmann.org> wrote:
>
> accepting all flags regardless was an oversight on my part in the first place. What this patch tried to do is to limit it to what userspace is currently actually using. My mistake was to look only at BlueZ 5.x userspace and not at BlueZ 4.x userspace.
So what about anybody else? Android doesn't use BlueZ, afaik. Any
other direct accesses?
If we already know that BlueZ 4.x did something else, what makes you
so sure that this now covers all cases?
The thing is, the bluetooth code has clearly never cared about these
bits before. Is there any real reason to think that people haven't
passed in garbage? Do we even know that those flags were *initialized*
at all by user space in all use cases?
So I'm ok with trying to fix things up, but I have to say that if the
fixed-up case also causes problems (because there was some other case
that you didn't think of), I'm going to be pissed off, and I'm going
to expect you to *jump* on it, and revert the whole thing.
Ok?
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists