From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755987AbcHXN5u convert rfc822-to-8bit (ORCPT ); Wed, 24 Aug 2016 09:57:50 -0400 Received: from lxorguk.ukuu.org.uk ([81.2.110.251]:46538 "EHLO lxorguk.ukuu.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753174AbcHXN5s (ORCPT ); Wed, 24 Aug 2016 09:57:48 -0400 Date: Wed, 24 Aug 2016 14:57:14 +0100 From: One Thousand Gnomes To: Sebastian Reichel Cc: Pavel Machek , Marcel Holtmann , Rob Herring , Arnd Bergmann , Greg Kroah-Hartman , Jiri Slaby , Peter Hurley , NeilBrown , "Dr . H . Nikolaus Schaller" , Linus Walleij , "open list:BLUETOOTH DRIVERS" , "linux-serial@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: [RFC PATCH 0/3] UART slave device bus Message-ID: <20160824145714.02bbebb3@lxorguk.ukuu.org.uk> In-Reply-To: <20160823005749.io6x4oi7muttkhfx@earth> References: <20160822180254.5c95af7c@lxorguk.ukuu.org.uk> <20160822183849.6dfdb9d2@lxorguk.ukuu.org.uk> <2D07EA08-1055-4292-96B3-32913EC9BBE1@holtmann.org> <20160822223223.398ee72d@lxorguk.ukuu.org.uk> <20160822220017.GA10689@amd> <20160822235414.4b2f8712@lxorguk.ukuu.org.uk> <20160822235758.gh33xupgyroye5wa@earth> <20160823011521.0ed94283@lxorguk.ukuu.org.uk> <20160823005749.io6x4oi7muttkhfx@earth> Organization: Intel Corporation X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > 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. > Also what should happen if old userspace use hciattach while > uart-bus slave-device doesn't have control over it? Do you You would either use the old hciattach in which case you wouldn't be able to manage it via a new API while attached, or the new API in which case you wouldn't be able to manage it via the old interface while it was being used directly. > Or do you suggest to register hci1 and one cannot use hci0? I guess > this breaks even more devices, as the device number changes. Device numbers are dynamic anyway. Plug a USB adapter in and if it beats your onboard adapter to registration then the order changes. > 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 >>From a distribution point of view that would be a nightmare. > 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. The Nokia N series is a weird corner case. > > 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. Usually no - you don't want a ton of kernel code for flashing adapters when they have built in firmware (similar issue for 3G modems) > 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. That means having two different omap serial drivers to maintain which is not ideal. To me there are four different things 1. bluetooth devices "just work". That can be user space (eg it seems to just work on my Fedora boxes and bluetooth enumeration is being done via user space, or may be via kernel enumeration, or a mix. PPP is an existing example of this - serial port PPP is an ldisc but ports that are not UART like speak directly to the PPP layer as network adapters. 2. Sideband controls and power management, where we need to give the tty_port a child device and power it up/down properly and have the tty_port hooks to do so based upon the ldisc protocol state machine when talking stuff like NMEA or HCI. 3. The special case UART power saving features/hacks like GPIO snooping, again with the right hooks 4. Whether it's useful to be able to create a tty device in kernel and attach that to stuff with no userspace involved. All are independent. Alan From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Wed, 24 Aug 2016 14:57:14 +0100 From: One Thousand Gnomes To: Sebastian Reichel Cc: Pavel Machek , Marcel Holtmann , Rob Herring , Arnd Bergmann , Greg Kroah-Hartman , Jiri Slaby , Peter Hurley , NeilBrown , "Dr . H . Nikolaus Schaller" , Linus Walleij , "open list:BLUETOOTH DRIVERS" , "linux-serial@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: [RFC PATCH 0/3] UART slave device bus Message-ID: <20160824145714.02bbebb3@lxorguk.ukuu.org.uk> In-Reply-To: <20160823005749.io6x4oi7muttkhfx@earth> References: <20160822180254.5c95af7c@lxorguk.ukuu.org.uk> <20160822183849.6dfdb9d2@lxorguk.ukuu.org.uk> <2D07EA08-1055-4292-96B3-32913EC9BBE1@holtmann.org> <20160822223223.398ee72d@lxorguk.ukuu.org.uk> <20160822220017.GA10689@amd> <20160822235414.4b2f8712@lxorguk.ukuu.org.uk> <20160822235758.gh33xupgyroye5wa@earth> <20160823011521.0ed94283@lxorguk.ukuu.org.uk> <20160823005749.io6x4oi7muttkhfx@earth> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII List-ID: > 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. > Also what should happen if old userspace use hciattach while > uart-bus slave-device doesn't have control over it? Do you You would either use the old hciattach in which case you wouldn't be able to manage it via a new API while attached, or the new API in which case you wouldn't be able to manage it via the old interface while it was being used directly. > Or do you suggest to register hci1 and one cannot use hci0? I guess > this breaks even more devices, as the device number changes. Device numbers are dynamic anyway. Plug a USB adapter in and if it beats your onboard adapter to registration then the order changes. > 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 =46rom a distribution point of view that would be a nightmare. > 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. The Nokia N series is a weird corner case. > > In many cases you'll also still need the tty interface to do > > things like firmware upgrades. =20 >=20 > 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. Usually no - you don't want a ton of kernel code for flashing adapters when they have built in firmware (similar issue for 3G modems) > 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. That means having two different omap serial drivers to maintain which is not ideal. To me there are four different things 1. bluetooth devices "just work". That can be user space (eg it seems to just work on my Fedora boxes and bluetooth enumeration is being done via user space, or may be via kernel enumeration, or a mix. PPP is an existing example of this - serial port PPP is an ldisc but ports that are not UART like speak directly to the PPP layer as network adapters. 2. Sideband controls and power management, where we need to give the tty_port a child device and power it up/down properly and have the tty_port hooks to do so based upon the ldisc protocol state machine when talking stuff like NMEA or HCI. 3. The special case UART power saving features/hacks like GPIO snooping, again with the right hooks 4. Whether it's useful to be able to create a tty device in kernel and attach that to stuff with no userspace involved. All are independent. Alan