On Mon, Jul 02, 2018 at 09:32:26PM +0200, Pavel Machek wrote: > On Fri 2018-06-29 14:09:14, Johan Hovold wrote: > > On Fri, Jun 29, 2018 at 02:05:54PM +0200, Pavel Machek wrote: > > > On Fri 2018-06-29 13:46:46, Johan Hovold wrote: > > > > On Fri, Jun 29, 2018 at 11:46:07AM +0200, Pavel Machek wrote: > > > > > > > > > > > > Finally, note that documentation (including kerneldoc) remains to be > > > > > > > written, but hopefully this will not hinder review given that the > > > > > > > current interfaces are fairly self-describing. > > > > > > > > > > > > This all looks great. Thanks for doing this work and adding a new > > > > > > subsystem for something that has been asked for for many years. > > > > > > > > > > > > All now merged in my tree, nice job! > > > > > > > > > > I don't think discussion was finished on this one. > > > > > > > > > > In particular, we agreed that /dev/gnssrawX would be better device > > > > > name, so that we still have place where to put proper abstraction > > > > > layer in future. > > > > > > > > I did not agree with you on that. I said we could consider that name if > > > > this was to be changed at all, which I do not think is necessary for > > > > the reasons spelled out in this thread. > > > > > > So, again: there's nothing gnss specific in those patches. It does not > > > know about the format of the data passed around. (Best you can claim > > > that somehow data flow characteristics are unique to gnss.) And this > > > takes namespace needed for real gnss subsystem. Please don't do it. > > > > This is the real gnss subsystem. Get over it. > > Congratulations. You have created gnss subsystem that has 0 lines of > code that are gnss-specific. We have been through this already. > This is not real gnss subsystem. This is pipe that passes data, > similar to /dev/psaux or mouse on /dev/ttyS0. Sooner or later, real > gnss subsystem (with unified interface) will be needed, as it was for > input, and this "pipe and gpio" thing should not hog required > namespace. It is still the gnss subsystem with a raw interface to the underlying protocols. As I've said repeatedly, *if* someone ever comes up with a way of abstracting these protocols, and can make the case this is really something we want to handle in the kernel, we would still be using the same drivers for managing power and I/O. Get it? It's the same subsystem, you'd just be adding a second higher-level interface (cf. hiddev and hidraw). So again, all that this comes down to is bike shedding about the device node name. Johan -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
