On Saturday, July 27, 2019 7:37:07 PM CEST Tri Vo wrote: > On Sat, Jul 27, 2019 at 6:10 AM Rafael J. Wysocki <raf...@kernel.org> wrote: > > > > On Sat, Jul 27, 2019 at 3:11 AM Stephen Boyd <swb...@chromium.org> wrote: > > > > > > If a device is wakeup capable and the driver calls device_wakeup_init() > > > on it during probe and then userspace writes 'enabled' to that device's > > > power/wakeup file in sysfs we'll try to create the same named wakeup > > > device in sysfs. The kernel will complain about duplicate file names. > > Thanks for reporting the issue, Stephen! > > > > > > sysfs: cannot create duplicate filename '/devices/virtual/wakeup/1-1.1' > > > kobject_add_internal failed for 1-1.1 with -EEXIST, don't try to register > > > things with the same name in the same directory. > > > > > > It may be advantageous to not write 'enabled' to the wakeup file (see > > > wakeup_store()) from userspace for these devices because we allocate > > > devices and register them and then throw them all away later on if the > > > device driver has already initialized the wakeup attribute. The > > > implementation currently tries to avoid taking locks here so it seems > > > best to optimize that path in a separate patch. > > > > > > Let's rename the wakeup class devices as 'wakeupN' with an IDA that's > > > simple enough to just return some sort of number. In addition, let's > > > make the device registering the wakeup the parent and include a 'name' > > > attribute in case userspace wants to figure out the type of wakeup it is > > > (in the case of virtual wakeups) or the device associated with the > > > wakeup. This makes it easier for userspace to go from /sys/class/wakeup > > > to a place in the device hierarchy where the wakeup is generated from > > > like an input device. > > > > > > Cc: Tri Vo <tr...@android.com> > > > Cc: Kalesh Singh <kaleshsi...@google.com> > > > Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org> > > > Cc: Ravi Chandra Sadineni <ravisadin...@chromium.org> > > > Signed-off-by: Stephen Boyd <swb...@chromium.org> > > > > I'd rather change the commit that introduced this issue which is only > > in linux-next for now. > > Raphael, could you roll back my patch? I'll work with Stephen to fix it.
I'll drop it, thanks!
