On Fri, 12 Jun 2015, Stefan Koch wrote: > Am Freitag, den 12.06.2015, 16:34 -0400 schrieb Alan Stern: > > On Fri, 12 Jun 2015, Stefan Koch wrote: > > > > > Am Freitag, den 12.06.2015, 14:09 -0400 schrieb Alan Stern: > > > > On Fri, 12 Jun 2015, Stefan Koch wrote: > > > > There is a lot of questionable material here. > > > > > > > > First of all, I agree with Krzysztof that having an "authorized" > > > > attribute in each interface's sysfs directory would be simpler and > > > > easier to use than having a bitmask of all authorized interfaces. > > > OK I can provide a patch for it. But note that the mask allows to enable > > > multiple interfaces at once. And the mechanism does enable all > > > (multiple) interfaces first and then does start the driver probing for > > > all interfaces. This mechanism is not possible without a mask. > > > > You could probe all the interfaces whenever any interface is > > authorized. Or there could be a separate mechanism to initiate > > probing. > > > Does this affect any running communication with the interface?
Of course it does. If you de-authorize an interface while it is being used, what do you expect will happen? Maybe you're asking what happens if an interface is probed while it is in use? Nothing will happen. Probing skips devices that already have a driver. > I'll send a simple patch. So in the one case the mask could used and in > the other case the interface attribute. It's dumb to add two different mechanisms that do the same thing. Just add the interface attribute and not the mask. And call the attribute "authorize", not "interface_authorize". It will be obvious that the attribute applies to the interface, because the attribute file will be inside the interface's sysfs directory. > > How about calling device_attach() instead? > bus_probe_device() checks the autoprobe status... Otherwise a getter for > the autoprobe status must implemented... Actually, this isn't necessary at all. After updating all the "authorize" attributes, the user can simply write the interface names to /sys/bus/usb/drivers_probe. This has the advantages of using a mask without the disadvantages. > > I don't understand. If you want to make sure the mask is set > > correctly, you need to check the mask's _current_ value. You don't > > care whether the mask has been changed from its _initial_ value. > If you connect a device to an usb port udev runs for the device and all > interfaces. > > If you change a configuration per hand udev runs only for interfaces, > not for the device. > > So if you want to avoid to set the device's mask multiple times a status > bit helps. I still don't understand. If you want to avoid setting the device's mask multiple times, all you have to do is check the current mask value before trying to change it. If the current value is already equal to the new value, you don't need to change the mask. Besides, this will be irrelevant if you implement "authorized" attributes rather than a mask. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
