On Mon, Feb 12, 2024 at 01:22:42PM +0100, Oliver Neukum wrote: > On 04.02.24 11:52, Laurent Pinchart wrote: > > Hi Ricardo, > > > > Thank you for the patch. > > Hi, > > sorry for commenting on this late, but this patch has > a fundamental issue. In fact this issue is the reason the > handling for quirks is in usbcore at all. > > If you leave the setting/clearing of this flag to a driver you > are introducing a race condition. The driver may or may not be > present at the time a device is enumerated. And you have > no idea how long the autosuspend delay is on a system > and what its default policy is regarding suspending > devices. > That means that a device can have been suspended and > resumed before it is probed. On a device that needs > RESET_RESUME, we are in trouble. Not necessarily. If the driver knows that one of these devices may already have been suspend and resumed, it can issue its own preemptive reset at probe time. > The inverse issue will arise if a device does not react > well to RESET_RESUME. You cannot rule out that a device > that must not be reset will be reset. That's a separate issue, with its own list of potential problems. > I am sorry, but it seems to me that the exceptions need > to go into usbcore. If we do then we may want to come up with a better scheme for seeing which devices need to have a quirk flag set. A static listing probably won't be good enough; the decision may have to be made dynamically. Alan Stern
