On 24.06.19 23:46, Linus Walleij wrote: > A GPS unit should be handled using the GNSS subsystem in > drivers/gnss: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gnss yes, since serdev we can also easily drive serial-connected devices (which many gps receivers are) from inside the kernel. there're also composite devices (eg. combined basebands) which also have gps amongst other things, so an own subsystem for gps devices is the way to go. > While we do encourage to use the right subsystems for this kind > of stuff there are certain cases we do defer to be handled in userspace, > but not many. These include one-off things like prototypes and Those are cases which probably nobody wants to have special support in the mainline kernel ... i recall some rules about no kernel drivers without corresponding free userland ... > factory lines with a myriad of relays (some PLC usecases), > door openers (we don't want drivers/dooropener) Actually, I've got something like that in the pipeline: a generic relais subsystem for anything that just switches on/off. Haven't gathered all requirements yet - for now just abusing LED for that (yes, also actually door openers). Okay, door openers could be a complex matter on their own, depending on how it electrically/mechanically works - some devices let motors spin until an end reached, etc. ... but haven't had an actual usecase for putting such things into the kernel. > or fire alarm button Button -> input subsystem ? > (but definately any elaborate IIO sensors > goes into drivers/iio) so it is a bit on case-by-case intuition > here. yes, and it's primarily about high level functionality. in industrial world we often have composite devices that span multiple subsystems. I any case, for a good decision we need to know what exactly some individual device actually does. --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering info@xxxxxxxxx -- +49-151-27565287