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: <20180308071459.310d0ba2@aktux>
Date:   Thu, 8 Mar 2018 07:16:44 +0100
From:   Andreas Kemnade <andreas@...nade.info>
To:     Johan Hovold <johan@...nel.org>
Cc:     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

Hi,

On Thu, 18 Jan 2018 17:47:36 +1100
Johan Hovold <johan@...nel.org> wrote:

[...]
> > 
> > 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.
> 
Hmm, devicetree without in-kernel drivers, do we have anything like that
somewhere? I thought that was a big no-go. But maybe I am wrong.

> 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).

So a bit like that mmc-powerseq stuff we already have?
> 
> But sure, that wouldn't be sufficient to deal with the
> unknown-power-state problem with the device in question.
> 
Maybe there could be a kind of active flag set by the tty if
there is traffic, so that active flag could be used in these
power sequence stuff? But then again the tty layer has to be extended
which would probably also cause a lot of ruffled feathers.

Regards,
Andreas

Content of type "application/pgp-signature" skipped