Hi Bjorn, 2015-11-12 12:39 GMT+01:00 Bjørn Mork <bj...@mork.no>: > Oliver Neukum <oneu...@suse.com> writes: >> On Thu, 2015-11-12 at 10:12 +0100, Johan Hovold wrote: >>> What exactly do you mean by "not work"? Does the driver fail to probe? >>> Or is it just that your user-space tool expects the tty devices to be >>> named ttyUSBn rather than ttyACMn (in which case the tool needs to be >>> fixed)? >> >> Hi, >> >> actually the cdc-acm driver contains some baggage for status >> inquiries, the parsing of the extra headers and other stuff. >> If you really just need a serial link, cdc-acm is not a good choice. > > True. But that decision is really up to the firmware developer, isn't > it? They should know what they are doing. Yes, that's a bad joke if it > wasn't obvious :) > > But trying to be serious - I'm wondering a bit about this application > that supposedly fails. Any chance we could have a look at that? Given > the rather contentless descriptions of the problem, I wouldn't be > surprised if it all boils down to some stupid device name assumption or > something like that. If so, then I think it is wrong trying to work > around the problem in the kernel. >
Unfortunately the application has a proprietary firmware flashing protocol under NDA, so I am not able to share it. I know that I will lose points for that... I can confirm that it is not a stupid device name assumption, since the device name is an argument of the flashing application. Being the device an "Infineon" device, it would be really interesting what developers at Infineon think about that... But I see that Infineon flashing devices in newer chipsets have become an only bulk serial link device (see device 0x8087/0x0716 in usb-serial-simple), so maybe this has a meaning... > > Bjørn Regards, Daniele -- 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
