Date:	Sat, 23 Jan 2016 13:19:09 +0100
From:	"H. Nikolaus Schaller" <hns@...delico.com>
To:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
Cc:	Tomeu Vizoso <tomeu@...euvizoso.net>,
	Rob Herring <robh@...nel.org>,
	Vostrikov Andrey <andrey.vostrikov@...entembedded.com>,
	Mark Rutland <mark.rutland@....com>,
	Peter Hurley <peter@...leysoftware.com>,
	Rob Herring <robherring2@...il.com>,
	List for communicating with real GTA04 owners 
	<gta04-owner@...delico.com>, NeilBrown <neil@...wn.name>,
	Arnd Bergmann <arnd@...db.de>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Sebastian Reichel <sre@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-serial@...r.kernel.org" <linux-serial@...r.kernel.org>,
	Grant Likely <grant.likely@...aro.org>,
	Jiri Slaby <jslaby@...e.cz>,
	Marek Belisko <marek@...delico.com>
Subject: Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4

Am 22.01.2016 um 21:12 schrieb One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>:

>> I would have expected that the main (and IMO sufficient) reason why
>> the kernel should do it is because the particular bus used to connect
>> a BT chip to the CPU is a hw detail that a kernel that does its job
>> should keep to itself. Same as userspace not needing to care if a BT
>> chip is behind SDIO or USB, why does it have to tell the kernel behind
>> which UART a BT chip is sitting?
> 
> Lots of reasons, some historic some not
> 
> 1. Different BT chips have different interfaces, especially when it gets
> to stuff like firmware reprogramming

HCI protocol is quite standardized. And firmware reprogramming is
rarely done. If it is needed, each chip type can have its own driver
module that knows how to inject firmware.

This just needs a decent kernel API for a chip driver to communicate
with the chip.

For SDIO connected WiFi chips it appears that firmware download done
by kernel modules is a standard solution.

> 
> 2. In many cases we don't know at the kernel level where there are BT
> uarts. It's improving with recent ACPI but for many systems it's simply
> not available to the OS

We just need to describe the connection of some peer driver to some
UART by means of DT. Then, kernel level can know.

> 
> 3. The power management for a lot of BT (especially on device tree) is
> not actually expressed, so you need a slightly customised daemon for each
> device - that one is ugly but the serial and bt layers can't fix it.

The peer chip driver (not the serial or bt layers) could fix it. With help
from bt and serial layers.

> 
> 4. Because you don't want to just automatically load and turn on
> bluetooth just because it is there - it burns power

That is obviously something nobody wants.

If the chip must be turned on (or turns on) during boot, the driver
can turn it off right after initialization and make the subsystem sleep
until activated again. Then it does not burn power although it
loads automatically.

> 
> 
> There is lots of stuff we probe and bind via user space - most things
> these days in fact. That's much of why we have notifiers and udev. It's
> frequently a win in flexibility, security and configurability to do stuff
> via user daemons. We do it for example with all the volume management,
> raid and disk encryption.

Because volumes are something users really want to configure. They
can change their hardware configuration every now and then. And
there are removable media to be considered.

In our UART cases the underlaying hardware can't be reconfigured. So
there is no need to load this burden of config to the user.

For BT or GPS I just want it to work the same on all devices (independently
on how the specific chip is connected). Kernel should unify such things.
Or it would not be a Un(iplexed)ix.

-- hns

Powered by blists - more mailing lists