On Thu, Jun 13, 2024, at 15:51, Bartosz Golaszewski wrote: > On Thu, Jun 13, 2024 at 3:47 PM Linus Walleij <linus.walleij@xxxxxxxxxx> wrote: >> >> On Thu, Jun 13, 2024 at 11:43 AM Bartosz Golaszewski <brgl@xxxxxxxx> wrote: >> >> > To prove this point, I even moved the gpio-virtuser driver I'm working >> > on to drivers/misc/ too as it isn't a GPIO provider either and merely >> > a GPIO consumer with a one-shot user-space interface not conforming to >> > any standards. >> >> We *could* just create drivers/gpio/consumers/* and an entry into the >> top-level drivers/Kconfig to have those appear right under the GPIO >> providers... >> >> Yours, >> Linus Walleij > > That would just add to confusion. GPIO consumers are all over the tree > after all. > > Whatever, let's keep it in drivers/gpio/. Greg KH just shot down my > idea of putting gpio-virtuser in drivers/misc/. I could imagine treating both gpio-virtuser and this code as a gpiolib extension rather than a consumer (which is usually part of some other subsystem's driver). It would also make sense to me to separate gpio providers from gpiolib in a way, moving one or both of them into a subdirectory of drivers/gpio/. It's probably not worth the pain of moving files, but at least in Kconfig and filenames, they could be named gpiolib-virtuser.c and gpiolib-sloppy-logic-analyzer.c to make it clear that these are not gpio provider drivers but something else, more along the lines of gpiolib-cdev.c and gpiolib-sysfs.c. Arnd