linux-kernel - Re: [Gta04-owner] [PATCH 0/4] UART slave device support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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

On Fri, 22 Jan 2016 20:12:29 +0000
One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk> wrote:

> > 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
> 
> 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
> 
Same is true for i2c devices. The solution there is that you have various
methods for providing the information to the kernel, some 
are autoprobed, some are via board files and you can also tell via sysfs
that there is one device.

> 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.
> 
That boils down to a circular it is not there because it is not there.
If we express the power management, it can be done in kernel.

> 4. Because you don't want to just automatically load and turn on
> bluetooth just because it is there - it burns power
> 
Exactly the same is true for wifi and for many other devices for
which drivers are automatically handled in kernel, too.
Well, do you have a list of devices which do not burn power?
I would be highly interested in those.

Regards,
Andreas

Content of type "application/pgp-signature" skipped