On Wed, Apr 05, 2023, Johan Hovold wrote: > 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). Fair points. I was entertaining the option where this can be used to poll during runtime PM enabled, but the data may not be useful enough in actual debug. > > 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. > I'm convinced now. Thanks, Thinh
