On Tue, Apr 04, 2023 at 02:30:25PM +0200, Johan Hovold wrote: > On Tue, Apr 04, 2023 at 02:07:22PM +0200, Oliver Neukum wrote: > > > > > > On 04.04.23 13:43, Johan Hovold wrote: > > > > > The device is being used; by the driver and ultimately by a user telling > > > > I am afraid that is just an assumption we cannot make. The user may just as > > well be reading a device state before a device is being used as that may matter. > > It's a perfectly valid assumption to make, and it is was all drivers do > for debugfs (as well as sysfs). You are the one arguing for making an > exception, which I don't think is warranted. > > > > the driver to do something on their behalf. The fact that the user is > > > initiating an action through an interface which intended for debugging > > > should not matter (and the user always has the option to check the > > > runtime pm state before initiating the action if that matters at all). > > > > 1. That is a race condition. > > Sure, but you can't have it both ways. Your proposed inverted logic is > racy as you may or may not get any data. > > > 2. Quite a lot of bugs we are looking at involve power transitions. > > You just cannot assume that a device will react the same way if it was > > waken up between events. > > Then just don't use the interface if you for whatever reason don't want > to wake the device up. For what it's worth, the ehci-hcd driver tests (under its private spinlock) whether the hardware is accessible -- i.e., not suspended -- before trying to carry out any debugfs operations that would use the device registers. If not, all you get is something like: bus <buspath>, device <devname> <description> SUSPENDED (no register access) Alan Stern
