Hi Matthias, Am 22.12.22 um 01:55 schrieb Matthias Kaehlcke:
The above race condition could also impact boards which actually should use the onboard_hub driver, so not creating the pdevs for some boards won't be enough. Out of my head I can't think of a clean solution. The onboard hub driver doesn't control the locks involved. Detaching the driver is necessary to make sure the onboard_hub USB devices don't hold stale pointers to their platform device. Re-attaching is needed because of the detach. One option could be to change the 'attach' work from being a member of struct onboard_hub to a static variable owned by the driver. With that onboard_hub_remove() wouldn't have to wait for the work to finish. An inconvenient is that only one instance of the work can run at any time, which could result in a race condition when multiple onboard hubs are probed closely together. It could happen that the USB device of the 2nd (or 3rd, ...) hub isn't re-attached if it wasn't on the system wide USB 'bus' yet when the 'attach' work of the 1st hub runs. Probably a rare condition within the (as of now) rare scenario of multiple onboard hubs, but it could happen. A mitigation could be to enter a sleepy loop if schedule_work() returns false (work is already running) and schedule it again until it is actually scheduled on behalf of the platform device in question. I might go for that if I don't get a better idea.
i don't have any idea.
Happy holidays!
Thank you. Happy holidays to you, too!
m.
