linux-kernel - Re: [Letux-kernel] [PATCH v5 3/5] misc serdev: Add w2sg0004 (gps receiver) power control driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20180118064736.GH3286@localhost>
Date:   Thu, 18 Jan 2018 17:47:36 +1100
From:   Johan Hovold <johan@...nel.org>
To:     Andreas Kemnade <andreas@...nade.info>
Cc:     Johan Hovold <johan@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        devicetree@...r.kernel.org,
        Discussions about the Letux Kernel 
        <letux-kernel@...nphoenux.org>,
        Jonathan Cameron <jic23@...nel.org>,
        Arnd Bergmann <arnd@...db.de>,
        Tony Lindgren <tony@...mide.com>,
        "H. Nikolaus Schaller" <hns@...delico.com>,
        kernel@...a-handheld.com, Russell King <linux@...linux.org.uk>,
        linux-kernel@...r.kernel.org, Thierry Reding <treding@...dia.com>,
        Rob Herring <robh+dt@...nel.org>,
        Kevin Hilman <khilman@...libre.com>,
        Benoît Cousson <bcousson@...libre.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-omap@...r.kernel.org,
        Andreas Färber <afaerber@...e.de>,
        linux-arm-kernel@...ts.infradead.org
Subject: Re: [Letux-kernel] [PATCH v5 3/5] misc serdev: Add w2sg0004 (gps
 receiver) power control driver

On Fri, Jan 12, 2018 at 07:40:35PM +0100, Andreas Kemnade wrote:
> On Fri, 12 Jan 2018 15:46:47 +0100
> Johan Hovold <johan@...nel.org> wrote:
> 
> > On Tue, Jan 09, 2018 at 06:43:47PM +0100, Andreas Kemnade wrote:
> > > On Fri, 22 Dec 2017 13:44:27 +0100
> > > Johan Hovold <johan@...nel.org> 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.
> > 
> Well partly powered devices are at many places, And they hide that problem
> from userspace, just get the open()/get() and close()/put() from there and power the
> device accordingly. 
> 
> So the question still remains why should the kernel hide some things and some
> it should not.
> If it all is in userspace, then there is still something needed in the devicetree
> (if I understand correctly, every information about hardware which cannot be
> auto-probed belongs into device tree) so that the userspace knows what kind of
> device is at that port. So there can be a daemon powering on and off devices.
> But that would break existing applications which just expect that they just need
> to open/close the device. 
> 
> Or you need to have some inotify handler in userspace and attach it there to
> react on close() and open() of that device.
> But this thing needs to have two kind of information:
> 
> 1. the type of chip available to do the right powerup sequence. 
> 
> 2. how the chip is wired up to the cpu. 
> 
> So to avoid having hardware information spread all over the table at least
> these information would need to be in devicetree. But that also all feels
> like a hack and hard to maintain.

Having the device described in the device tree is certainly desirable,
not least for chip identification. And with a GPS framework in the
kernel with a well-defined interface, implementing power management
would be straight forward.

I'm just not convinced that the proposed tty interface is the right
interface for this. User space would still rely on gpsd for the GPS
protocols, and would also ultimately be managing power by killing gpsd
or whatever daemon that would otherwise be holding the port open.

Something like the generic power sequences that has been discussed
elsewhere might be a better fit for this if all you want to do is power
on and off on port open and close (and on suspend/resume). There really
isn't anything GPS-specific in the current proposal (besides the
suggested tty-device name).

But sure, that wouldn't be sufficient to deal with the
unknown-power-state problem with the device in question.

Johan