[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180227070415.GB18666@localhost>
Date: Tue, 27 Feb 2018 08:04:15 +0100
From: Johan Hovold <johan@...nel.org>
To: Pavel Machek <pavel@....cz>
Cc: Johan Hovold <johan@...nel.org>,
"H. Nikolaus Schaller" <hns@...delico.com>,
Mark Rutland <mark.rutland@....com>,
DTML <devicetree@...r.kernel.org>,
Thierry Reding <treding@...dia.com>,
Jonathan Cameron <jic23@...nel.org>,
Arnd Bergmann <arnd@...db.de>,
Tony Lindgren <tony@...mide.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Russell King <linux@...linux.org.uk>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Rob Herring <robh+dt@...nel.org>,
Kevin Hilman <khilman@...libre.com>,
Benoît Cousson <bcousson@...libre.com>,
kernel@...a-handheld.com,
Discussions about the Letux Kernel
<letux-kernel@...nphoenux.org>,
linux-omap <linux-omap@...r.kernel.org>,
Andreas Färber <afaerber@...e.de>,
Linux ARM <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [Letux-kernel] [PATCH v5 3/5] misc serdev: Add w2sg0004 (gps
receiver) power control driver
On Mon, Feb 12, 2018 at 04:26:18PM +0100, Pavel Machek wrote:
> Hi!
>
> > > Let's restart this discussion and focus on the main roadblock (others
> > > are minor details which can be sorted out later).
> > >
> > > If it feels like a hack, the key issue seems to me to be the choice of
> > > the API to present the GPS data to user space. Right?
> >
> > Or even more fundamentally, does this belong in the kernel at all?
>
> Yes, it does.
But not necessarily in its current form.
> > Now, if we'd ever have a proper GPS framework that handled everything in
> > kernel space (i.e. no more gpsd) then we would be able to write kernel
> > drivers that also take care of PM. But perhaps that's unlikely to ever
> > be realised given the state of things (proprietary protocols, numerous
> > quirky implementations, etc).
>
> That is what needs to happen.
>
> > The kernel is probably not the place to be working around issues like
> > that, even if serdev at least allows for such hacks to be fairly
> > isolated in drivers (unlike some of the earlier proposals touching core
> > code).
>
> Oh, kernel is indeed right place to provide hardware abstraction --
> and that includes bug workarounds.
Right, at least when such hacks can be confined to a driver and not be
spread all over the place.
Johan
Powered by blists - more mailing lists