From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752430AbcAWHlO (ORCPT ); Sat, 23 Jan 2016 02:41:14 -0500 Received: from glaubenleben.de ([85.214.105.140]:49566 "EHLO glaubenleben.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751882AbcAWHlJ (ORCPT ); Sat, 23 Jan 2016 02:41:09 -0500 Date: Sat, 23 Jan 2016 08:40:52 +0100 From: Andreas Kemnade To: One Thousand Gnomes Cc: Tomeu Vizoso , Mark Rutland , Rob Herring , Peter Hurley , Vostrikov Andrey , "devicetree@vger.kernel.org" , Sebastian Reichel , "linux-kernel@vger.kernel.org" , List for communicating with real GTA04 owners , Grant Likely , Rob Herring , "linux-serial@vger.kernel.org" , Greg Kroah-Hartman , NeilBrown , Marek Belisko , Jiri Slaby , Arnd Bergmann Subject: Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4 Message-ID: <20160123084052.0d35f892@kemnade.info> In-Reply-To: <20160122201229.5df0bb2d@lxorguk.ukuu.org.uk> References: <481E05A9-A192-438D-B092-D7700B30BBC4@goldelico.com> <56992959.2020204@hurleysoftware.com> <744620565.20160116103445@cogentembedded.com> <20160116233157.GA7774@rob-hp-laptop> <3D5F35D7-31B5-4E68-875F-7DD492EF0316@goldelico.com> <20160117141912.4aa2e46c@lxorguk.ukuu.org.uk> <1D5F146E-D347-453B-9158-8D269F8DA99C@goldelico.com> <20160117193849.69d00c28@lxorguk.ukuu.org.uk> <37DCE36D-0A5E-41C5-BDA4-857DCF9F2DD1@goldelico.com> <20160118111926.0882b422@lxorguk.ukuu.org.uk> <07F3B6C0-0C87-478C-B6DD-5C0EECB42D0D@goldelico.com> <20160118220319.051c9cc0@lxorguk.ukuu.org.uk> <9E37C552-361C-4A54-980E-E3BFFF834302@goldelico.com> <20160120174610.1c64239a@lxorguk.ukuu.org.uk> <39B850CE-E381-4D3B-BD0A-84AFE7DAEEDF@goldelico.com> <20160122201229.5df0bb2d@lxorguk.ukuu.org.uk> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; i586-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/9NejAcAJmJ5hHYY452F=WSO"; protocol="application/pgp-signature" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --Sig_/9NejAcAJmJ5hHYY452F=WSO Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Fri, 22 Jan 2016 20:12:29 +0000 One Thousand Gnomes 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? >=20 > Lots of reasons, some historic some not >=20 > 1. Different BT chips have different interfaces, especially when it gets > to stuff like firmware reprogramming >=20 > 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 >=20 Same is true for i2c devices. The solution there is that you have various methods for providing the information to the kernel, some=20 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. >=20 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 >=20 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 --Sig_/9NejAcAJmJ5hHYY452F=WSO Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWoy6HAAoJEGGrpYhZ30HuetkH/jAM2ZZOuavdcuvZR98/bsp8 1sh8GIzgTut+UHAw6Nuh4rAUYyoVv/JOLGFCo9KPtDXjJG5wWeWx8lmSaEk2xBf/ MQpAwSxPtBPL/exL3Qnn0OsDwox1AU78OiyX5DNQ4gmT93LR6eN77yl57E+MqntW H4bkBuKkd8EsICDUeuwUA8lCeXj3pWPATp4KZZ4fwx68HaCbrWCRqmHIUEf0w5M/ oykLiU0Yv+BRjSqkP6Up9oKO7O52FfxA6ZOEb2mY6Nb+Biry2GHaAtaUeQqsqdKL hAYm4xOYgmn0DTVQn8WAutkRZ5DkDbgFDNEGBQEdCTvbjuLNtK3yh9+27S0C5ws= =4AF9 -----END PGP SIGNATURE----- --Sig_/9NejAcAJmJ5hHYY452F=WSO--