From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933975AbeALOqx (ORCPT + 1 other); Fri, 12 Jan 2018 09:46:53 -0500 Received: from mail-lf0-f52.google.com ([209.85.215.52]:35014 "EHLO mail-lf0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933764AbeALOqu (ORCPT ); Fri, 12 Jan 2018 09:46:50 -0500 X-Google-Smtp-Source: ACJfBoveY3el0lUZK+NsUBH6w3CHaeaSLqvOnlGHOLHi7+BiE2jbFEUJhyVf+5ofk3bDhFHlAeUD4A== Date: Fri, 12 Jan 2018 15:46:47 +0100 From: Johan Hovold To: Andreas Kemnade Cc: Johan Hovold , Mark Rutland , devicetree@vger.kernel.org, Discussions about the Letux Kernel , Jonathan Cameron , Arnd Bergmann , Tony Lindgren , "H. Nikolaus Schaller" , kernel@pyra-handheld.com, Russell King , linux-kernel@vger.kernel.org, Thierry Reding , Rob Herring , Kevin Hilman , =?iso-8859-1?Q?Beno=EEt?= Cousson , Greg Kroah-Hartman , linux-omap@vger.kernel.org, Andreas =?iso-8859-1?Q?F=E4rber?= , linux-arm-kernel@lists.infradead.org Subject: Re: [Letux-kernel] [PATCH v5 3/5] misc serdev: Add w2sg0004 (gps receiver) power control driver Message-ID: <20180112144647.GA5992@localhost> References: <5494ad34b39a6c62601e3747440268dfb3be7d5a.1512114576.git.hns@goldelico.com> <20171222124427.GI3374@localhost> <20180109184347.28ba0a6e@aktux> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180109184347.28ba0a6e@aktux> User-Agent: Mutt/1.7.2 (2016-11-26) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On Tue, Jan 09, 2018 at 06:43:47PM +0100, Andreas Kemnade wrote: > On Fri, 22 Dec 2017 13:44:27 +0100 > Johan Hovold wrote: > > [...] > > I'd suggest reiterating the problem you're trying to solve and > > enumerating the previously discussed potential solutions in order to > > find a proper abstraction level for this (before getting lost in > > implementation details). > > > The main point here is in short words: Having a device powered on or off > when the uart it is attached to, is used or not used anymore, > so the already available userspace applications do not need to be changed. So we'd end up with something in-between a kernel driver and a user-space solution. What about devices that need to be (partially) powered also when the port isn't open? A pure user-space solution would be able to handle all variants. > I digged out a bit around: > alternative aproaches were: > adding hooks to the uart/tty layer: > https://marc.info/?l=linux-kernel&m=143333222014616&w=2 > https://marc.info/?l=devicetree&m=143130955414580&w=2 Thanks for the pointers, I remember those threads... > I do not find it right now in my archive: > adding a virtual gpio for dtr to the omap_serial driver. > The driver behind the virtual io would then handle pm. One reason it was > rejected was that the devicetree should only contain real hardware and > not virtual stuff. Oh, yeah, I think something like that made it in briefly before getting reverted again. I'll respond to Nikolaus mail as well. Johan From mboxrd@z Thu Jan 1 00:00:00 1970 From: johan@kernel.org (Johan Hovold) Date: Fri, 12 Jan 2018 15:46:47 +0100 Subject: [Letux-kernel] [PATCH v5 3/5] misc serdev: Add w2sg0004 (gps receiver) power control driver In-Reply-To: <20180109184347.28ba0a6e@aktux> References: <5494ad34b39a6c62601e3747440268dfb3be7d5a.1512114576.git.hns@goldelico.com> <20171222124427.GI3374@localhost> <20180109184347.28ba0a6e@aktux> Message-ID: <20180112144647.GA5992@localhost> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Tue, Jan 09, 2018 at 06:43:47PM +0100, Andreas Kemnade wrote: > On Fri, 22 Dec 2017 13:44:27 +0100 > Johan Hovold wrote: > > [...] > > I'd suggest reiterating the problem you're trying to solve and > > enumerating the previously discussed potential solutions in order to > > find a proper abstraction level for this (before getting lost in > > implementation details). > > > The main point here is in short words: Having a device powered on or off > when the uart it is attached to, is used or not used anymore, > so the already available userspace applications do not need to be changed. So we'd end up with something in-between a kernel driver and a user-space solution. What about devices that need to be (partially) powered also when the port isn't open? A pure user-space solution would be able to handle all variants. > I digged out a bit around: > alternative aproaches were: > adding hooks to the uart/tty layer: > https://marc.info/?l=linux-kernel&m=143333222014616&w=2 > https://marc.info/?l=devicetree&m=143130955414580&w=2 Thanks for the pointers, I remember those threads... > I do not find it right now in my archive: > adding a virtual gpio for dtr to the omap_serial driver. > The driver behind the virtual io would then handle pm. One reason it was > rejected was that the devicetree should only contain real hardware and > not virtual stuff. Oh, yeah, I think something like that made it in briefly before getting reverted again. I'll respond to Nikolaus mail as well. Johan