On Wed, Aug 9, 2017 at 10:15 AM, Bjørn Mork <bjorn@xxxxxxx> wrote: > loïc tourlonias <loic.tourlonias@xxxxxxxxx> writes: >> On Wed, Aug 9, 2017 at 9:25 AM, Bjørn Mork <bjorn@xxxxxxx> wrote: >> >>> Sounds like your system has other issues, but whatever... >> >> I may not have been clear in my explanation. What seems wrong with my system? > > "ethXX which interferes with a service". It should not. Agreed, but fixing our service is really complex, that's why I'm looking for a simple solution for this specific device before we have the resource to fix the service. > >>> The cdc_ether driver treats any ID entry with .driver_info = 0 as a >>> blacklist entry. So you can dynamically blacklist devices by writing >>> the "VID PID" to /sys/bus/usb/drivers/cdc_ether/new_id before the device >>> is probed. >>> >> I have tried this and look at the source code of >> driver/usb/core/driver.c. But I think this is not what I required. >> What I understand is that the new_id file is used to dynamically add >> new USB id to the cdc_ether driver. > > True. But as I said: The cdc_ether driver use the device ID list for > blacklisting. This is an implementation detail specific to this driver. > It will use the .driver_info field as a pointer to usbnet specific data. > But if the field is 0, then the entry becomes a blacklist entry instead. > > Dynamically added entries have all fields set to 0 by default, and will > also be tried before the built-in entries (since v3.15). So adding a > dynamic entry to the cdc_ether driver means adding a blacklist entry > (Unless you explicitly reference an existing entry for inheritance). > > Try it. > I have (finally) understood how it works and I will try it a little bit harder and try to figure out why my first attempts doesn't work as expected. Thanks Loic > > Bjørn _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
