From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754051AbdATBhT (ORCPT ); Thu, 19 Jan 2017 20:37:19 -0500 Received: from mx2.suse.de ([195.135.220.15]:35915 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751949AbdATBhR (ORCPT ); Thu, 19 Jan 2017 20:37:17 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 20 Jan 2017 02:36:12 +0100 From: msuchanek To: Rob Herring Cc: Greg Kroah-Hartman , Marcel Holtmann , Jiri Slaby , Sebastian Reichel , Arnd Bergmann , "Dr . H . Nikolaus Schaller" , Peter Hurley , Andy Shevchenko , Alan Cox , Loic Poulain , Pavel Machek , NeilBrown , Linus Walleij , linux-bluetooth@vger.kernel.org, linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org, linux-serial-owner@vger.kernel.org Subject: Re: [PATCH v2 0/9] Serial slave device bus In-Reply-To: <20170116225436.17505-1-robh@kernel.org> References: <20170116225436.17505-1-robh@kernel.org> Message-ID: <7d6a8a629f8b618cdb09c9112d1e5986@suse.de> User-Agent: Roundcube Webmail Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2017-01-16 23:54, Rob Herring wrote: > Here's a new version of the serdev bus support with all the review > feedback so far incorporated. I've left it named serdev for now pending > any further votes one way or the other, but I did rename the sysfs > visible > portions to "serial". > > There's still some discussion about what to do with devices that pass > thru > data to userspace unmodified like GPS and could still use tty device > for > the data path. IMO, we should treat this as a separate problem > following > this series. Drivers we want to convert to serdev and already in the > kernel don't need this functionality. The whole point of the serial bus is to simplify and clean up support for serial devices. If tty users cannot use the kernel support for automagic kill switches/resets/whatever with kernel GPIO or whatever framework and must continue supporting userspace GPIO and hacks for writing IO space from userland for their devices there is just no point. I mean it's fine to add support for your single pet device but if you are to support non-trivial number of devices they don't get all perfect kernel driver overnight. And if you need userspace GPIO for half of your devices you can just continue using it for all to *simplify* your userspace code. It has already happened for SPI devices and the implementation of the userspace access to SPI is dragging for years. Thanks Michal