Message-ID: <20160823005749.io6x4oi7muttkhfx@earth>
Date:   Tue, 23 Aug 2016 02:57:52 +0200
From:   Sebastian Reichel <sre@...nel.org>
To:     One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
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

Hi,

On Tue, Aug 23, 2016 at 01:15:21AM +0100, One Thousand Gnomes wrote:
> > > 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.

So you mean if I do "hciconfig hci0 down", then the uart-bus should
"down" the tty and only on "hciconfig hci0 up" it should "up" the
tty? I would expect a uart-bus slave-device takes control of the
device ("up" it) on probe. It's hardwired anyway.

Also what should happen if old userspace use hciattach while
uart-bus slave-device doesn't have control over it? Do you
suggest to implement some dummy code, that detects uart-bus already
registered a hci device and returns success without doing anything?
Then "hciconfig hci0 up" will fail, since the tty is already taken
by hciattach.

Or do you suggest to register hci1 and one cannot use hci0? I guess
this breaks even more devices, as the device number changes.

Also note, that there is a chance, that hci0 will go up by some
script before hciattach has been called in your legacy userspace.
Then it will also fail.

So yes, from your point of view there is a regression, just because
it's working automatically. So let's just not convert existing boards
with working hciattach based bluetooth devices. New devices can use
the uart-bus, as it's not a regression for them and Nokia N series
can also do it, since they have no working bluetooth at all at the
moment.

> In many cases you'll also still need the tty interface to do
> things like firmware upgrades.

I would expect the uart-slave driver to know how to do firmware
updates. Actually most bluetooth chips are initialized by uploading
a firmware to them.

And there are definitely uart drivers not caring about having a tty
device. Nokia's vendor driver for their bluetooth protocol contains
a custom omap-serial driver combined with the actual bluetooth
driver. There is nothing related to the tty framework. I think the
same would work for the other hardwired bluetooth chips perfectly
fine.

Note: I'm not in favour of merging uart and bluetooth drivers. This
is really bad design. But it shows, that /dev/tty interface is not
needed by in-kernel drivers.

Of course tty is needed by userland drivers, but I expect, that
those do not use the uart-bus. They already require all kind of
hardware knowledge and don't work out-of-the-box anyway, so they
do not gain from this framework.

-- Sebastian

Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)

Powered by blists - more mailing lists