From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754430AbcAVUNI (ORCPT ); Fri, 22 Jan 2016 15:13:08 -0500 Received: from lxorguk.ukuu.org.uk ([81.2.110.251]:32930 "EHLO lxorguk.ukuu.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752344AbcAVUND (ORCPT ); Fri, 22 Jan 2016 15:13:03 -0500 Date: Fri, 22 Jan 2016 20:12:29 +0000 From: One Thousand Gnomes To: Tomeu Vizoso Cc: "H. Nikolaus Schaller" , Rob Herring , Vostrikov Andrey , Mark Rutland , Peter Hurley , Rob Herring , List for communicating with real GTA04 owners , NeilBrown , Arnd Bergmann , "devicetree@vger.kernel.org" , Greg Kroah-Hartman , Sebastian Reichel , "linux-kernel@vger.kernel.org" , "linux-serial@vger.kernel.org" , Grant Likely , Jiri Slaby , Marek Belisko Subject: Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4 Message-ID: <20160122201229.5df0bb2d@lxorguk.ukuu.org.uk> In-Reply-To: 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> Organization: Intel Corporation X-Mailer: Claws Mail 3.13.1 (GTK+ 2.24.29; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > 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 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. 4. Because you don't want to just automatically load and turn on bluetooth just because it is there - it burns power 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. Alan