On Wed, Sep 29, 2021 at 6:43 PM Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > On Wed, Sep 29, 2021 at 06:05:06PM -0700, Kuppuswamy Sathyanarayanan wrote: > > Currently bus drivers like "USB" or "Thunderbolt" implement a custom > > version of device authorization to selectively authorize the driver > > probes. Since there is a common requirement, move the "authorized" > > attribute support to the driver core in order to allow it to be used > > by other subsystems / buses. > > > > Similar requirements have been discussed in the PCI [1] community for > > PCI bus drivers as well. > > > > No functional changes are intended. It just converts authorized > > attribute from int to bool and moves it to the driver core. There > > should be no user-visible change in the location or semantics of > > attributes for USB devices. > > > > Regarding thunderbolt driver, although it declares sw->authorized as > > "int" and allows 0,1,2 as valid values for sw->authorized attribute, > > but within the driver, in all authorized attribute related checks, > > it is treated as bool value. So when converting the authorized > > attribute from int to bool value, there should be no functional > > changes other than value 2 being not visible to the user. > > > > [1]: https://lore.kernel.org/all/CACK8Z6E8pjVeC934oFgr=VB3pULx_GyT2NkzAogdRQJ9TKSX9A@xxxxxxxxxxxxxx/ > > > > Reviewed-by: Dan Williams <dan.j.williams@xxxxxxxxx> > > Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@xxxxxxxxxxxxxxx> > > Since you're moving the authorized flag from the USB core to the > driver core, the corresponding sysfs attribute functions should be > moved as well. Unlike when 'removable' moved from USB to the driver core there isn't a common definition for how the 'authorized' sysfs-attribute behaves across buses. The only common piece is where this flag is stored in the data structure, i.e. the 'authorized' sysfs interface is purposefully left bus specific. > Also, you ignored the usb_[de]authorize_interface() functions and > their friends. Ugh, yes. _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
