[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <A8AA3046-E635-4697-BA01-86FFFBB5B2E0@holtmann.org>
Date: Wed, 24 Aug 2016 10:29:58 -0400
From: Marcel Holtmann <marcel@...tmann.org>
To: One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
Cc: Sebastian Reichel <sre@...nel.org>, Pavel Machek <pavel@....cz>,
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 Alan,
>> 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.
>
> Today you can switch stacks at runtime, you can switch between the kernel
> stack and debug tools at runtime. Breaking that is a regression.
actually that is not true. We have HCI User Channel since a long time that gives you raw access to the devices. And also kernel interfaces to do all vendor / debug tasks.
Regards
Marcel
Powered by blists - more mailing lists