On Tue, Jan 10, 2023 at 09:09:21AM +0100, Linus Walleij wrote: > On Mon, Jan 9, 2023 at 2:41 PM Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote: > > On Mon, Jan 9, 2023 at 2:16 PM Linus Walleij <linus.walleij@xxxxxxxxxx> wrote: > > > On Tue, Jan 3, 2023 at 10:01 AM Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote: > > > > > If this should go into sysfs we should probably create something > > > > > generic, such as a list of stuff to be exported as sysfs switches. > > > > > > > > > > It generally also looks really dangerous, which is another reason > > > > > for keeping it in debugfs. It's the big hammer to hurt yourself with, > > > > > more or less. > > > > > > > > Yes, generic would be nice. Anyone familiar with other hardware > > > > that could make use of this? > > > > > > Drew was using this for Beagle Bone IIRC, Drew? > > > > Yes, that's what I remember, too. And I tested it on Koelsch. > > > > But again, that's for debugging purposes. For non-debugging > > operation, we need something different. > > Actually Drew's usecase wasn't for debugging. It was kind-of production, > but it was for "one-offs" such as factory lines and other very specific-purpose > embedded. > > The placement in debugfs was mostly because it is fragile and dangerous. > > Yours, > Linus Walleij For the BeagleBone, the use case for selecting pin fuctions from userspace with pinmux-select in debugfs is to allow for rapid prototyping situations such as breadboarding. Our Debian install on the boards has an utility named config-pin that allows the user to select between defined pinctrl states for each pin on the expansion header. Some users like this as it means they do not need to constantly be editing device tree files and rebooting while protoyping. I agree that this is not a fool-proof scheme but Beaglebones have been shipping with this functionality for many years without any significant problems that I'm aware of. I do admit that it is possible for someone to potentially damage circuits with this flexibility, so having a warning in the kernel log like Andy suggested elsewhere in this thread might be a good idea. Thanks, Drew
