On Sun, Feb 16, 2025 at 04:58:51PM GMT, Bartosz Golaszewski wrote: > On Sun, Feb 16, 2025 at 2:15 PM Koichiro Den <koichiro.den@xxxxxxxxxxxxx> wrote: > > > > > > > > On one hand, I agree that it would make some scenarios simpler, and > > > let us propagate an error code to the sysfs writer in case of failure. > > > > > > On the other hand, it would change user behavior. Currently people can > > > configure a GPIO aggregator, and load the driver module for the parent > > > gpiochip later, relying on deferred probing to bring up everything > > > when it is ready. > > > > Thank you both for your insights, Bartosz and Geert. I've just sent v3 > > (https://lore.kernel.org/all/20250216125816.14430-1-koichiro.den@xxxxxxxxxxxxx/) > > which retains the current behavior, to not suprise anyone now. > > I'm now considering whether we might eventually deprecate the sysfs > > interface in the future. Doing so could simplify the codebase and bring it > > in line with gpio-sim and gpio-virtuser. > > > > Heh, yeah you'd think so. You can watch my talk[1] on how easy it is > to remove sysfs interfaces. :) Well, I just meant new_device/delete_device in this context so my impression was that it would not be that hard. Anyhow, honestly speaking I haven't looked through it thoroughly yet. Thank you! Koichiro > > Bartosz > > [1] https://fosdem.org/2025/schedule/event/fosdem-2025-5288-the-status-of-removing-sys-class-gpio-and-the-global-gpio-numberspace-from-the-kernel/