Re: [PATCH 1/2] cdc_acm: Ignore Infineon Flash Loader utility

[Jonas Jonsson]

Hi,

On Fri, Nov 13, 2015 at 03:56:22PM +0100, Johan Hovold wrote:
...

> I'll take a look at these patches when 4.4-rc1 is out.
Thanks. I'll post an update including Daniele Tested-by:.

/Jonas
--
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

Re: [PATCH 1/2] cdc_acm: Ignore Infineon Flash Loader utility

[Johan Hovold]

On Thu, Nov 12, 2015 at 02:55:04PM +0100, Bjørn Mork wrote:
> Daniele Palmas  writes:

> > 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...
> 
> Yes.  I have a Sierra Wireless EM7345 modem which is based on the same
> chipset. I haven't really paid much attemtion to the flashloader
> functionality before, but this is how that modem looks before it loads
> its Sierra firmware:

> So this device looks very much like an ACM device, except that it is
> missing the necessary control interface and status endpoint.  And
> without a control interface there is of course no way to send a properly
> formatted CDC control request either.
> 
> I assume the different vendors also use the same Intel provided firmware
> toolkit, making the firmwares share basic functionality like bootloader
> and flashing.  But the USB descriptors are likely configurable by the
> vendor.  Telit might have tried to "improve" the above into a proper ACM
> device.
> 
> I believe this supports the assumption that Infineon Flash Loader
> devices have some ACM descriptors without actually being ACM class
> devices, and that it is best to just collect them all in the
> usb-serial-simple "flashloader" driver.

I'm still not convinced. The device at hand does look and apparently
behaves like a compliant ACM device, and I think we need to figure out
why it does not work with this particular proprietary user-space tool
before modifying the kernel.

For example, using usb-serial-simple means that no line-control requests
are sent. Perhaps the tool simply needs to set the termios settings to
something else than the default 9600N81 that the cdc-acm driver uses.

Modem control-requests would not be sent either (and HUPCL determines if
DTR/RTS is lowered at close).

Daniele, could you provide some more details about what happens when the
proprietary tool fails. Do you have access to the sources?

Johan
--
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

Re: [PATCH 1/2] cdc_acm: Ignore Infineon Flash Loader utility

[Johan Hovold]

On Fri, Nov 13, 2015 at 03:13:41PM +0100, Daniele Palmas wrote:
> 2015-11-13 11:58 GMT+01:00 Johan Hovold :
> > On Thu, Nov 12, 2015 at 02:55:04PM +0100, Bjørn Mork wrote:

> >> I believe this supports the assumption that Infineon Flash Loader
> >> devices have some ACM descriptors without actually being ACM class
> >> devices, and that it is best to just collect them all in the
> >> usb-serial-simple "flashloader" driver.
> >
> > I'm still not convinced. The device at hand does look and apparently
> > behaves like a compliant ACM device, and I think we need to figure out
> > why it does not work with this particular proprietary user-space tool
> > before modifying the kernel.
> >
> > For example, using usb-serial-simple means that no line-control requests
> > are sent. Perhaps the tool simply needs to set the termios settings to
> > something else than the default 9600N81 that the cdc-acm driver uses.
> >
> > Modem control-requests would not be sent either (and HUPCL determines if
> > DTR/RTS is lowered at close).
> >
> > Daniele, could you provide some more details about what happens when the
> > proprietary tool fails. Do you have access to the sources?
> 
> I'll try to explain how the whole thing should work.

> Using the cdc-acm driver, the string, though being sent in the same
> way than using the usb-serial-simple driver (I can confirm that the
> data is passing properly since I used an hw usb sniffer), does not
> make the device to stay in flashing mode.
> 
> I thought that the problem was something done by the acm driver when
> opening the port that is not accepted well by the flashing device on
> the firmware side, so I tried also in the past to debug the driver,
> but without success.
> 
> I can start again to understand which is really the problem with
> cdc-acm, but my fear is that to have a working solution with cdc-acm
> will be more complicated (e.g. adding a new quirk) than adding support
> in the usb-serial-simple driver. Consider also that this is not really
> a communication device with subclass modem, as wrongly stated by the
> usb descriptors, since it is simply a flashing device.
> 
> Another interesting piece of the puzzle is that in Windows this device
> requires a specific flashloader driver and does not use the acm driver
> suggested by the vendor.

Thanks for the details. I agree with you now, moving the device to
usb-serial-simple makes sense.

I'll take a look at these patches when 4.4-rc1 is out.

Johan
--
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

Re: [PATCH 1/2] cdc_acm: Ignore Infineon Flash Loader utility

[Daniele Palmas]

Hi Johan,

2015-11-13 11:58 GMT+01:00 Johan Hovold :
> On Thu, Nov 12, 2015 at 02:55:04PM +0100, Bjørn Mork wrote:
>> Daniele Palmas  writes:
>
>> > 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...
>>
>> Yes.  I have a Sierra Wireless EM7345 modem which is based on the same
>> chipset. I haven't really paid much attemtion to the flashloader
>> functionality before, but this is how that modem looks before it loads
>> its Sierra firmware:
>
>> So this device looks very much like an ACM device, except that it is
>> missing the necessary control interface and status endpoint.  And
>> without a control interface there is of course no way to send a properly
>> formatted CDC control request either.
>>
>> I assume the different vendors also use the same Intel provided firmware
>> toolkit, making the firmwares share basic functionality like bootloader
>> and flashing.  But the USB descriptors are likely configurable by the
>> vendor.  Telit might have tried to "improve" the above into a proper ACM
>> device.
>>
>> I believe this supports the assumption that Infineon Flash Loader
>> devices have some ACM descriptors without actually being ACM class
>> devices, and that it is best to just collect them all in the
>> usb-serial-simple "flashloader" driver.
>
> I'm still not convinced. The device at hand does look and apparently
> behaves like a compliant ACM device, and I think we need to figure out
> why it does not work with this particular proprietary user-space tool
> before modifying the kernel.
>
> For example, using usb-serial-simple means that no line-control requests
> are sent. Perhaps the tool simply needs to set the termios settings to
> something else than the default 9600N81 that the cdc-acm driver uses.
>
> Modem control-requests would not be sent either (and HUPCL determines if
> DTR/RTS is lowered at close).
>
> Daniele, could you provide some more details about what happens when the
> proprietary tool fails. Do you have access to the sources?

I'll try to explain how the whole thing should work.

This is what happens when the device is turned on (without modifying
the drivers):

[155492.352031] usb 1-3: new high-speed USB device number 27 using ehci-pci
[155492.485429] usb 1-3: config 1 interface 0 altsetting 0 endpoint
0x81 has an invalid bInterval 255, changing to 11
[155492.485436] usb 1-3: New USB device found, idVendor=058b, idProduct=0041
[155492.485439] usb 1-3: New USB device strings: Mfr=0, Product=0,
SerialNumber=0
[155492.485952] cdc_acm 1-3:1.0: ttyACM0: USB ACM device

This is the flashing device that is caught by the cdc-acm driver. Once
the ttyACM appears, the application starts sending a magic string
(simple write on the file descriptor) to keep the device in flashing
mode. If this magic string is not properly received in a certain time
interval, the modem goes on in normal operative mode:

[155493.748094] usb 1-3: USB disconnect, device number 27
[155494.916025] usb 1-3: new high-speed USB device number 28 using ehci-pci
[155495.059978] usb 1-3: New USB device found, idVendor=1bc7, idProduct=0021
[155495.059983] usb 1-3: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[155495.059986] usb 1-3: Product: 6 CDC-ACM + 1 CDC-ECM
[155495.059989] usb 1-3: Manufacturer: Telit
[155495.059992] usb 1-3: SerialNumber: 359658044004697
[155495.138958] cdc_acm 1-3:1.0: ttyACM0: USB ACM device
[155495.140832] cdc_acm 1-3:1.2: ttyACM1: USB ACM device
[155495.142827] cdc_acm 1-3:1.4: ttyACM2: USB ACM device
[155495.144462] cdc_acm 1-3:1.6: ttyACM3: USB ACM device
[155495.145967] cdc_acm 1-3:1.8: ttyACM4: USB ACM device
[155495.147588] cdc_acm 1-3:1.10: ttyACM5: USB ACM device
[155495.154322] cdc_ether 1-3:1.12 wwan0: register 'cdc_ether' at
usb-:00:1a.7-3, Mobile Broadband Network Device, 00:00:11:12:13:14

Using the cdc-acm driver, the string, though being sent in the same
way than using the usb-serial-simple driver (I can confirm that the
data is passing properly since I used an hw usb sniffer), does not
make the device to stay in flashing mode.

I thought that the problem was something done by the acm driver when
opening the port that is not accepted well by the flashing device on
the firmware side, so I tried also in the past to debug the driver,
but without success.

I can start again to understand which is really the problem with
cdc-acm, but my fear is that to have a working solution with cdc-acm
will be more complicated (e.g. adding a new quirk) than adding support
in the usb-serial-simple driver. Consider also that this is not really
a communication device with subclass modem, as wrongly stated by the
usb descriptors, since it is simply a flashing device.

Another interesting piece of the puzzle is that in Windows this device
requires a specific flashloader driver and does not use the acm driver

Re: [PATCH 1/2] cdc_acm: Ignore Infineon Flash Loader utility

[Johan Hovold]

On Wed, Nov 11, 2015 at 07:24:23PM +0100, Daniele Palmas wrote:
> Hi Johan,
> 
> 2015-11-06 12:24 GMT+01:00 Johan Hovold :
> > On Thu, Nov 05, 2015 at 01:57:43PM +0100, Jonas Jonsson wrote:
> >> Some modems, such as the Telit UE910, are using an Infineon Flash Loader
> >> utility. It has two interfaces, 2/2/0 (Abstract Modem) and 10/0/0 (CDC
> >> Data). The latter can be used as a serial interface to upgrade the
> >> firmware of the modem. However, that isn't possible when the cdc-acm
> >> driver takes control of the device.
> >
> > Why can't you just use the tty device that the cdc-acm driver provides?
> 
> I have the same problem reported by Jonas.
> 
> Telit flashing procedure does not work with the cdc-acm driver.

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)?

> Moreover, the device 0x058b/0x0041 is in itself a flashing device, so
> /* Infineon Flashloader driver */ section of usb-serial-simple seems a
> good place for it.
> 
> Since the procedure is working properly with only bulk endpoints I suspect
> that on the firmware side the definition of the device is not correct.

What is the lsusb -v output for this device? Could you also provide the
logs from when plugging it in?

Thanks,
Johan
--
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

Re: [PATCH 1/2] cdc_acm: Ignore Infineon Flash Loader utility

[Daniele Palmas]

Hi Bjorn,

2015-11-12 12:39 GMT+01:00 Bjørn Mork :
> Oliver Neukum  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

Re: [PATCH 1/2] cdc_acm: Ignore Infineon Flash Loader utility

[Oliver Neukum]

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.

Regards
Oliver



--
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

Re: [PATCH 1/2] cdc_acm: Ignore Infineon Flash Loader utility

[Johan Hovold]

On Thu, Nov 12, 2015 at 10:59:28AM +0100, Oliver Neukum wrote:
> 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.

My point is that *if* this is a cdc-compliant device, we should not move
it to usb-serial just to provide a renamed device node.

Johan
--
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

Re: [PATCH 1/2] cdc_acm: Ignore Infineon Flash Loader utility

[Bjørn Mork]

Oliver Neukum  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.


Bjørn
--
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

Re: [PATCH 1/2] cdc_acm: Ignore Infineon Flash Loader utility

[Bjørn Mork]

Bjørn Mork  writes:

> Yes.  I have a Sierra Wireless EM7345 modem which is based on the same
> chipset.

No, it's not.  But it's probably from the same family of chipsets.


Bjørn
--
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

Re: [PATCH 1/2] cdc_acm: Ignore Infineon Flash Loader utility

[Bjørn Mork]

Daniele Palmas  writes:

> 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 was afraid of that.

> I can confirm that it is not a stupid device name assumption, since
> the device name is an argument of the flashing application.

OK, thanks.

> Being the device an "Infineon" device, it would be really interesting
> what developers at Infineon think about that...

I guess you have to do s/Infineon/Intel/ now.  Not sure that helps much,
though.  The Intel modem division haven't been much more open about
their business than Infineon used to be (or Qualcomm is for that sake -
it looks like a radio modem related disease)

> 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...

Yes.  I have a Sierra Wireless EM7345 modem which is based on the same
chipset. I haven't really paid much attemtion to the flashloader
functionality before, but this is how that modem looks before it loads
its Sierra firmware:


Bus 003 Device 013: ID 8087:0716 Intel Corp. 
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass2 Communications
  bDeviceSubClass 0 
  bDeviceProtocol 0 
  bMaxPacketSize064
  idVendor   0x8087 Intel Corp.
  idProduct  0x0716 
  bcdDevice0.00
  iManufacturer   0 
  iProduct0 
  iSerial 0 
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   46
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  0 
bmAttributes 0xc0
  Self Powered
MaxPower  500mA
** UNRECOGNIZED:  05 24 00 10 01
** UNRECOGNIZED:  05 24 01 00 00
** UNRECOGNIZED:  04 24 02 02
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   2
  bInterfaceClass10 CDC Data
  bInterfaceSubClass  0 Unused
  bInterfaceProtocol  0 
  iInterface  0 
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83  EP 3 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02  EP 2 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
Device Qualifier (for other device speed):
  bLength10
  bDescriptorType 6
  bcdUSB   2.00
  bDeviceClass2 Communications
  bDeviceSubClass 0 
  bDeviceProtocol 0 
  bMaxPacketSize064
  bNumConfigurations  1
Device Status: 0x0001
  Self Powered


There are a couple of oddities in the above lsusb output which I believe
supports the proposed patch: Note the use of a "CDC Data" class
interface for an assumed vendor specific function.  There is no
"Communications" interface here.  And do note the three unrecognised
descriptors.  These are obviously CDC class specific functional
descriptors.  You have the

 Header:  05 24 00 10 01
 Call Management: 05 24 01 00 00
 ACM: 04 24 02 02


So this device looks very much like an ACM device, except that it is
missing the necessary control interface and status endpoint.  And
without a control interface there is of course no way to send a properly
formatted CDC control request either.

I assume the different vendors also use the same Intel provided firmware
toolkit, making the firmwares share basic functionality like bootloader
and flashing.  But the USB descriptors are likely configurable by the
vendor.  Telit might have tried to "improve" the above into a proper ACM
device.

I believe this supports the assumption that Infineon Flash Loader
devices have some ACM descriptors without actually being ACM class
devices, and that it is best to just collect them all in the
usb-serial-simple "flashloader" driver.


Bjørn
--
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

Re: [PATCH 1/2] cdc_acm: Ignore Infineon Flash Loader utility

[Daniele Palmas]

Hi,

2015-11-12 14:55 GMT+01:00 Bjørn Mork :
> Daniele Palmas  writes:
>
>> 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 was afraid of that.
>
>> I can confirm that it is not a stupid device name assumption, since
>> the device name is an argument of the flashing application.
>
> OK, thanks.
>
>> Being the device an "Infineon" device, it would be really interesting
>> what developers at Infineon think about that...
>
> I guess you have to do s/Infineon/Intel/ now.  Not sure that helps much,
> though.  The Intel modem division haven't been much more open about
> their business than Infineon used to be (or Qualcomm is for that sake -
> it looks like a radio modem related disease)
>
>> 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...
>
> Yes.  I have a Sierra Wireless EM7345 modem which is based on the same
> chipset. I haven't really paid much attemtion to the flashloader
> functionality before, but this is how that modem looks before it loads
> its Sierra firmware:
>
>
> Bus 003 Device 013: ID 8087:0716 Intel Corp.
> Device Descriptor:
>   bLength18
>   bDescriptorType 1
>   bcdUSB   2.00
>   bDeviceClass2 Communications
>   bDeviceSubClass 0
>   bDeviceProtocol 0
>   bMaxPacketSize064
>   idVendor   0x8087 Intel Corp.
>   idProduct  0x0716
>   bcdDevice0.00
>   iManufacturer   0
>   iProduct0
>   iSerial 0
>   bNumConfigurations  1
>   Configuration Descriptor:
> bLength 9
> bDescriptorType 2
> wTotalLength   46
> bNumInterfaces  1
> bConfigurationValue 1
> iConfiguration  0
> bmAttributes 0xc0
>   Self Powered
> MaxPower  500mA
> ** UNRECOGNIZED:  05 24 00 10 01
> ** UNRECOGNIZED:  05 24 01 00 00
> ** UNRECOGNIZED:  04 24 02 02
> Interface Descriptor:
>   bLength 9
>   bDescriptorType 4
>   bInterfaceNumber0
>   bAlternateSetting   0
>   bNumEndpoints   2
>   bInterfaceClass10 CDC Data
>   bInterfaceSubClass  0 Unused
>   bInterfaceProtocol  0
>   iInterface  0
>   Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x83  EP 3 IN
> bmAttributes2
>   Transfer TypeBulk
>   Synch Type   None
>   Usage Type   Data
> wMaxPacketSize 0x0200  1x 512 bytes
> bInterval   0
>   Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x02  EP 2 OUT
> bmAttributes2
>   Transfer TypeBulk
>   Synch Type   None
>   Usage Type   Data
> wMaxPacketSize 0x0200  1x 512 bytes
> bInterval   0
> Device Qualifier (for other device speed):
>   bLength10
>   bDescriptorType 6
>   bcdUSB   2.00
>   bDeviceClass2 Communications
>   bDeviceSubClass 0
>   bDeviceProtocol 0
>   bMaxPacketSize064
>   bNumConfigurations  1
> Device Status: 0x0001
>   Self Powered
>
>
> There are a couple of oddities in the above lsusb output which I believe
> supports the proposed patch: Note the use of a "CDC Data" class
> interface for an assumed vendor specific function.  There is no
> "Communications" interface here.  And do note the three unrecognised
> descriptors.  These are obviously CDC class specific functional
> descriptors.  You have the
>
>  Header:  05 24 00 10 01
>  Call Management: 05 24 01 00 00
>  ACM: 04 24 02 02
>
>
> So this device looks very much like an ACM device, except that it is
> missing the necessary control interface and status endpoint.  And
> without a control interface there is of course no way to send a properly
> formatted CDC control request either.
>

Thanks for this analysis, it is very very interesting!

> I assume the different vendors also use the same Intel provided firmware
> toolkit, making the firmwares share basic functionality like bootloader
> and flashing.  But the USB descriptors are likely configurable by the
> vendor.  Telit might have tried to "improve" the above into a proper ACM
> device.
>

No, I can confirm you that Telit does not modify the USB descriptors
of the flashing device.

> I believe this supports the assumption that Infineon Flash Loader
> devices have some ACM 

Re: [PATCH 1/2] cdc_acm: Ignore Infineon Flash Loader utility

[Daniele Palmas]

Hi Johan,

2015-11-06 12:24 GMT+01:00 Johan Hovold :
> On Thu, Nov 05, 2015 at 01:57:43PM +0100, Jonas Jonsson wrote:
>> Some modems, such as the Telit UE910, are using an Infineon Flash Loader
>> utility. It has two interfaces, 2/2/0 (Abstract Modem) and 10/0/0 (CDC
>> Data). The latter can be used as a serial interface to upgrade the
>> firmware of the modem. However, that isn't possible when the cdc-acm
>> driver takes control of the device.
>
> Why can't you just use the tty device that the cdc-acm driver provides?

I have the same problem reported by Jonas.

Telit flashing procedure does not work with the cdc-acm driver.

Moreover, the device 0x058b/0x0041 is in itself a flashing device, so
/* Infineon Flashloader driver */ section of usb-serial-simple seems a
good place for it.

Since the procedure is working properly with only bulk endpoints I suspect
that on the firmware side the definition of the device is not correct.

Best regards,
Daniele

>
> Thanks,
> Johan
> --
> 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
--
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

Re: [PATCH 1/2] cdc_acm: Ignore Infineon Flash Loader utility

[Johan Hovold]

On Thu, Nov 05, 2015 at 01:57:43PM +0100, Jonas Jonsson wrote:
> Some modems, such as the Telit UE910, are using an Infineon Flash Loader
> utility. It has two interfaces, 2/2/0 (Abstract Modem) and 10/0/0 (CDC
> Data). The latter can be used as a serial interface to upgrade the
> firmware of the modem. However, that isn't possible when the cdc-acm
> driver takes control of the device.

Why can't you just use the tty device that the cdc-acm driver provides?

Thanks,
Johan
--
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

[PATCH 1/2] cdc_acm: Ignore Infineon Flash Loader utility

[Jonas Jonsson]

Some modems, such as the Telit UE910, are using an Infineon Flash Loader
utility. It has two interfaces, 2/2/0 (Abstract Modem) and 10/0/0 (CDC
Data). The latter can be used as a serial interface to upgrade the
firmware of the modem. However, that isn't possible when the cdc-acm
driver takes control of the device.

Signed-off-by: Jonas Jonsson 
---
 drivers/usb/class/cdc-acm.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c
index b30e742..26ca4f9 100644
--- a/drivers/usb/class/cdc-acm.c
+++ b/drivers/usb/class/cdc-acm.c
@@ -1838,6 +1838,11 @@ static const struct usb_device_id acm_ids[] = {
},
 #endif
 
+   /* Exclude Infineon Flash Loader utility */
+   { USB_DEVICE(0x058b, 0x0041),
+   .driver_info = IGNORE_DEVICE,
+   },
+
/* control interfaces without any protocol set */
{ USB_INTERFACE_INFO(USB_CLASS_COMM, USB_CDC_SUBCLASS_ACM,
USB_CDC_PROTO_NONE) },
-- 
2.5.0

--
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