Load partially USB composite device

[loïc tourlonias]

On Wed, Aug 9, 2017 at 10:15 AM, Bjørn Mork <bjorn at mork.no> wrote:
> loïc tourlonias <loic.tourlonias at gmail.com> writes:
>> On Wed, Aug 9, 2017 at 9:25 AM, Bjørn Mork <bjorn at mork.no> 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