[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160823011521.0ed94283@lxorguk.ukuu.org.uk>
Date: Tue, 23 Aug 2016 01:15:21 +0100
From: One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
To: Sebastian Reichel <sre@...nel.org>
Cc: Pavel Machek <pavel@....cz>, Marcel Holtmann <marcel@...tmann.org>,
Rob Herring <robh@...nel.org>, Arnd Bergmann <arnd@...db.de>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Jiri Slaby <jslaby@...e.com>,
Peter Hurley <peter@...leysoftware.com>,
NeilBrown <neil@...wn.name>,
"Dr . H . Nikolaus Schaller" <hns@...delico.com>,
Linus Walleij <linus.walleij@...aro.org>,
"open list:BLUETOOTH DRIVERS" <linux-bluetooth@...r.kernel.org>,
"linux-serial@...r.kernel.org" <linux-serial@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH 0/3] UART slave device bus
> > That would still be a regression. Not everyone even uses the kernel
> > bluetooth stack. It would only return EBUSY if you had done an "up"
> > on it via the direct bluetooth stack.
>
> So it returns EBUSY when uart-bus is used. Since uart-bus is about
> hardwired devices that's basically always.
That would only be when the bluetooth port in question was active via the
hardwired interface - which is not always. You choose to turn on/off
bluetooth interfaces. If you boot with an older user space you'd use
hciattach instead.
In many cases you'll also still need the tty interface to do things like
firmware upgrades.
Alan
Powered by blists - more mailing lists