On Fri, Oct 1, 2021 at 12:02 PM Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > On Fri, Oct 01, 2021 at 11:09:52AM -0700, Dan Williams wrote: > > On Fri, Oct 1, 2021 at 9:47 AM Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > > > > > On Fri, Oct 01, 2021 at 09:13:54AM -0700, Dan Williams wrote: > > > > Bear with me, and perhaps it's a lack of imagination on my part, but I > > > > don't see how to get to a globally generic "authorized" sysfs ABI > > > > given that USB and Thunderbolt want to do bus specific actions on > > > > authorization toggle events. Certainly a default generic authorized > > > > attribute can be defined for all the other buses that don't have > > > > legacy here, but Thunderbolt will still require support for '2' as an > > > > authorized value, and USB will still want to base probe decisions on > > > > the authorization state of both the usb_device and the usb_interface. > > > > > > The USB part isn't really accurate (I can't speak for Thunderbolt). > > > When a usb_device is deauthorized, the device will be unconfigured, > > > deleting all its interfaces and removing the need for any probe > > > decisions about them. In other words, the probe decision for a > > > usb_device or usb_interface depends only on the device's/interface's > > > own authorization state. > > > > > > True, the interface binding code does contain a test of the device's > > > authorization setting. That test is redundant and can be removed. > > > > > > The actions that USB wants to take on authorization toggle events for > > > usb_devices are: for authorize, select and install a configuration; > > > for deauthorize, unconfigure the device. Each of these could be > > > handled simply enough just by binding/unbinding the device. (There > > > is some special code for handling wireless USB devices, but wireless > > > USB is now defunct.) > > > > Ah, so are you saying that it would be sufficient for USB if the > > generic authorized implementation did something like: > > > > dev->authorized = 1; > > device_attach(dev); > > > > ...for the authorize case, and: > > > > dev->authorize = 0; > > device_release_driver(dev); > > > > ...for the deauthorize case? > > Yes, I think so. But I haven't tried making this change to test and > see what really happens. Sounds like a useful path for this effort to explore. Especially as Greg seems to want the proposed "has_probe_authorization" flag in the bus_type to disappear and make this all generic. It just seems that Thunderbolt would need deeper surgery to move what it does in the authorization toggle path into the probe and remove paths. Mika, do you see a path for Thunderbolt to align its authorization paths behind bus ->probe() ->remove() events similar to what USB might be able to support for a generic authorization path? _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
