On Tue, Apr 04, 2023 at 10:03:09PM +0000, Thinh Nguyen wrote: > On Tue, Apr 04, 2023, 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. > > > > How can we know when to use and when not to use it? We can't just rely > on runtime_status for that. The device can go into suspend any time. You can disable runtime PM through sysfs if you want to avoid prevent the device from suspending underneath you. The point is that by having a consistent behaviour for debugfs with respect to runtime PM you can *always* use it. It doesn't crash and it does not return random errors based on external events. Sure, if you are trying to debug some runtime PM related issue, this may or may not interfere with that, but then you probably need a more specialised instrumentation to debug that anyway (e.g. dumping state when you receive wakeup events, etc). A manually controlled sysfs interface for dumping registers really isn't enough to debug power-state *transitions*. That leaves inspection of the suspended state, but the whole reason that we're having this discussion is that that state is not available to the driver while suspended in the first place. Johan
