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. > But the attribute may be useful for single interfaces that work alone. > > > > Secondly, the patches have not been carefully edited. There are > > several misspelled words in comments and descriptions. And why does > > patch 3/5 modify drivers/base/base.h and include/linux/device.h? > > > It's needed that bus_probe_device() is defined in hub.c. To start > probing after authorize an interface. How about calling device_attach() instead? > > Thirdly, what is the purpose of the mask_changed bit? The changelog > > describes it as "a status bit to control a manual setting of the mask", > > which is not very clear. _How_ does it control manual setting of the > > mask? _Why_ does manual setting of the mask need to be controlled? > > > If someone sets the mask the bit get's TRUE. After setting a new > configuration it is set back to FALSE. > > So you could check if it is needed to ensure correct mask setting > (again). 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. 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
