<div dir="auto"><div dir="auto">It seemed like if just one interface in the description list was somehow compliant with modem manager, the full device seemed claimed.</div><div dir="auto"><br></div>I may have missed something in my headers while experimenting. Can you give an example of a header structure that will not be assumed to be a modem by MM while still accessible as a proper CDC serial device - without blacklisting anything?<div dir="auto"><br></div><div dir="auto">BR</div><div dir="auto">Lars</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Jan 9, 2017 18:13, "Bjørn Mork" <<a href="mailto:bjorn@mork.no">bjorn@mork.no</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="quoted-text">Greg KH <<a href="mailto:greg@kroah.com">greg@kroah.com</a>> writes:<br>
> On Mon, Jan 09, 2017 at 09:40:59AM +0000, Kenneth Rohde Christiansen wrote:<br>
>> Web USB can only grab devices which has special Web USB headers. It can not<br>
>> grab any USB device.<br>
>><br>
>> <a href="https://wicg.github.io/webusb/#webusb-descriptors" rel="noreferrer" target="_blank">https://wicg.github.io/webusb/<wbr>#webusb-descriptors</a><br>
><br>
> Ah, fun :(<br>
><br>
> So, we can add a quirk into the kernel cdc-acm driver to never bind to a<br>
> device that has the wusb platform capability descriptor,<br>
<br>
</div>I fail to see why a quirk should be necessary. New device classes are<br>
expected to use new class/subclass codes distintly different from<br>
anything handled by existing class drivers.<br>
<font color="#888888"><br>
<br>
Bjørn<br>
</font></blockquote></div><br></div>