Messages in this thread | | | Date | Mon, 19 Mar 2018 14:54:18 +0100 | From | Johan Hovold <> | Subject | Re: [Letux-kernel] [PATCH v5 3/5] misc serdev: Add w2sg0004 (gps receiver) power control driver |
| |
On Tue, Feb 27, 2018 at 08:32:50AM +0100, H. Nikolaus Schaller wrote: > Hi Johan, > > > Am 27.02.2018 um 08:04 schrieb Johan Hovold <johan@kernel.org>: > > > > 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. > > Thanks, Pavel for supporting our view. > > > > > But not necessarily in its current form. > > Is this a "yes after some code fixes"?
No, we need some kind of at least rudimentary gps framework even if we allow for a raw (NMEA) interface for the time being (possibly indefinitely).
> Pavel mentioned an example where such an evolutionary approach was taken. > > > >>> 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. > > It seems that you forgot that the driver we propose is not spread all over > the place. It *is* confined to a single driver thanks to the serdev api.
I believe that's what I wrote above.
Johan
| |