From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932987AbcHVWyq (ORCPT ); Mon, 22 Aug 2016 18:54:46 -0400 Received: from lxorguk.ukuu.org.uk ([81.2.110.251]:36214 "EHLO lxorguk.ukuu.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932915AbcHVWyi (ORCPT ); Mon, 22 Aug 2016 18:54:38 -0400 Date: Mon, 22 Aug 2016 23:54:14 +0100 From: One Thousand Gnomes To: Pavel Machek Cc: Marcel Holtmann , Rob Herring , Arnd Bergmann , Greg Kroah-Hartman , Jiri Slaby , Sebastian Reichel , 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: <20160822235414.4b2f8712@lxorguk.ukuu.org.uk> In-Reply-To: <20160822220017.GA10689@amd> References: <20160818011445.22726-1-robh@kernel.org> <12886761.WF058qtZp8@wuerfel> <2775954.hrE2UdODgU@wuerfel> <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> 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: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 23 Aug 2016 00:00:17 +0200 Pavel Machek wrote: > On Mon 2016-08-22 22:32:23, One Thousand Gnomes wrote: > > > why would we even have it create a /dev/ttyX for these devices in the first place. Lets just not create an uevent for it and lets not create a dev_t for it. > > > > Because if you don't it's a regression. It's not permissible to break > > existing userspace. > > Well... it would be good to do the right thing, at least in the places > where we can. > > Yes, renumbering people's serials is bad, OTOH for new platforms it > would be nice not to expose ttyS15 which can only return -EBUSY. That would still be a regression. Not everyone even uses the kernel bluetooth stack. It would only return EBUSY if you had done an "up" on it via the direct bluetooth stack. Alan