Hi Oliver
Would you prefer a version like this?
https://lore.kernel.org/all/20231222-rallybar-v2-1-5849d62a9514@chromium.org...
If so I can re-submit a version with the 3 vid/pids. Alan, would you be happy with that?
Regards!
On Tue, 13 Feb 2024 at 11:47, Laurent Pinchart laurent.pinchart@ideasonboard.com wrote:
On Mon, Feb 12, 2024 at 02:04:31PM -0500, Alan Stern wrote:
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.
I don't mind either way personally. Oliver, could you try to find a good solution with Ricardo ? I'll merge the outcome.
-- Regards,
Laurent Pinchart