Am Samstag, den 13.06.2015, 10:55 -0400 schrieb Alan Stern: > 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. > OK. This approach works fine. I have implemented it. > > 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 do you solve the problem that the devices authorization show and store functions are in the same file? If the others get the same name this wouldn't work. One option could be to make the functions used by both attributes (device and interface) and check the device type. Or is it possible to set a different name in SysFS with indivudual function name? Do you now a simplier method? > > > > 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 have tested it. If the autoprobing is disbaled and device_attach() will used the interface driver binds, too. If bus_probe_device() is used the driver doesn't binds. The manaual probing is possible in both cases, that is correct. But only bus_probe_device() could avoid driver probing after authorization. So I think the move from the one header file to the other makes sense. > > > > 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. The next upcoming patch uses the attribute. > > Alan Stern > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
