From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754602AbcHSBDp (ORCPT ); Thu, 18 Aug 2016 21:03:45 -0400 Received: from mo4-p00-ob.smtp.rzone.de ([81.169.146.163]:32447 "EHLO mo4-p00-ob.smtp.rzone.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754241AbcHSBCI (ORCPT ); Thu, 18 Aug 2016 21:02:08 -0400 X-RZG-AUTH: :JGIXVUS7cutRB/49FwqZ7WcecEarQROEYabkiUo6lSGtGsaxaXmwxFVAKQfU X-RZG-CLASS-ID: mo00 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: [RFC PATCH 0/3] UART slave device bus From: "H. Nikolaus Schaller" In-Reply-To: <20160818163809.1b2fcfe5@lxorguk.ukuu.org.uk> Date: Thu, 18 Aug 2016 20:31:52 +0200 Cc: Rob Herring , Greg Kroah-Hartman , Marcel Holtmann , Jiri Slaby , Sebastian Reichel , Pavel Machek , Peter Hurley , NeilBrown , Arnd Bergmann , Linus Walleij , linux-bluetooth@vger.kernel.org, linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org Message-Id: References: <20160818011445.22726-1-robh@kernel.org> <20160818152528.569eb426@lxorguk.ukuu.org.uk> <227BE734-C9C1-4059-B0B4-EB47819703A8@goldelico.com> <20160818163809.1b2fcfe5@lxorguk.ukuu.org.uk> To: One Thousand Gnomes X-Mailer: Apple Mail (2.3124) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.home.local id u7J13m4R028310 > Am 18.08.2016 um 17:38 schrieb One Thousand Gnomes : > >>> Your changes also don't work because serial uart drivers are not obliged >>> to use any of the uart buffering helpers and particularly on the rx side >>> many do not do so and the performance hit would be too high. >> >> The SoC I have, is using it. > > The Linux kernel does generalised implementations. Yes it may work on > your board but it doesn't work for everything. It needs to work only on boards with a SoC UART. Not with a tty over USB or something else. This is the generalisation I see. Any SoC with uart_port driver support (and as far as I see many are). > It's the difference > between doing it properly and hacking your board to work. Agreed. But solving problems nobody really has is overengineering. Especially if the generalised implementation that is being discussed (tty_port) does not even solve the problem. Or only in a very clumsy and difficult way. In such a case a generalisation seems to be the wrong approach to me. And we should start to accept that we mix up different requirements and try a single solution for almost everyone we can imagine (which isn't bad initially, but can prohibit to find a solution at all) except the real use case that is on the table. That is why I always come back to the practical problem to implement my driver and want to know how it can be done. BR, Nikolaus From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: [RFC PATCH 0/3] UART slave device bus From: "H. Nikolaus Schaller" In-Reply-To: <20160818163809.1b2fcfe5@lxorguk.ukuu.org.uk> Date: Thu, 18 Aug 2016 20:31:52 +0200 Cc: Rob Herring , Greg Kroah-Hartman , Marcel Holtmann , Jiri Slaby , Sebastian Reichel , Pavel Machek , Peter Hurley , NeilBrown , Arnd Bergmann , Linus Walleij , linux-bluetooth@vger.kernel.org, linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org Message-Id: References: <20160818011445.22726-1-robh@kernel.org> <20160818152528.569eb426@lxorguk.ukuu.org.uk> <227BE734-C9C1-4059-B0B4-EB47819703A8@goldelico.com> <20160818163809.1b2fcfe5@lxorguk.ukuu.org.uk> To: One Thousand Gnomes List-ID: > Am 18.08.2016 um 17:38 schrieb One Thousand Gnomes = : >=20 >>> Your changes also don't work because serial uart drivers are not = obliged >>> to use any of the uart buffering helpers and particularly on the rx = side >>> many do not do so and the performance hit would be too high. =20 >>=20 >> The SoC I have, is using it. >=20 > The Linux kernel does generalised implementations. Yes it may work on > your board but it doesn't work for everything. It needs to work only on boards with a SoC UART. Not with a tty over USB or something else. This is the generalisation I see. Any SoC with uart_port driver support (and as far as I see many are). > It's the difference > between doing it properly and hacking your board to work. Agreed. But solving problems nobody really has is overengineering. Especially if the generalised implementation that is being discussed (tty_port) does not even solve the problem. Or only in a very clumsy and difficult way. In such a case a generalisation seems to be the wrong approach to me. And we should start to accept that we mix up different requirements and try a single solution for almost everyone we can imagine (which isn't bad initially, but can prohibit to find a solution at all) except = the real use case that is on the table. That is why I always come back to the practical problem to implement my driver and want to know how it can be done. BR, Nikolaus