* [stable] A patch in 2.6.27.9 caused device names to change
@ 2009-02-02 22:02 Chuck Ebbert
2009-02-03 0:05 ` Greg KH
0 siblings, 1 reply; 8+ messages in thread
From: Chuck Ebbert @ 2009-02-02 22:02 UTC (permalink / raw)
To: linux-kernel; +Cc: stable
This patch:
http://git.kernel.org/?p=linux/kernel/git/stable/stable-queue.git;a=blob_plain;f=releases/2.6.27.9/usb-option-add-pantech-cards.patch;hb=HEAD
replaced my wireless adapter's /dev/ttyACM0 interface with three interfaces:
/dev/ttyUSB[012]
That broke my ppp connection scripts. And I have to use /dev/ttyUSB1 to connect,
not USB0. Also it looks like Network Manager only knows how to use the first
interface in its auto-connect mode, so people using that also lost their
connections.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [stable] A patch in 2.6.27.9 caused device names to change
2009-02-02 22:02 [stable] A patch in 2.6.27.9 caused device names to change Chuck Ebbert
@ 2009-02-03 0:05 ` Greg KH
2009-02-03 14:50 ` Dan Williams
0 siblings, 1 reply; 8+ messages in thread
From: Greg KH @ 2009-02-03 0:05 UTC (permalink / raw)
To: Chuck Ebbert, dan williams; +Cc: linux-kernel, stable
On Mon, Feb 02, 2009 at 05:02:38PM -0500, Chuck Ebbert wrote:
> This patch:
> http://git.kernel.org/?p=linux/kernel/git/stable/stable-queue.git;a=blob_plain;f=releases/2.6.27.9/usb-option-add-pantech-cards.patch;hb=HEAD
>
> replaced my wireless adapter's /dev/ttyACM0 interface with three interfaces:
> /dev/ttyUSB[012]
>
> That broke my ppp connection scripts. And I have to use /dev/ttyUSB1 to connect,
> not USB0. Also it looks like Network Manager only knows how to use the first
> interface in its auto-connect mode, so people using that also lost their
> connections.
Ugh, that sucks.
That is what is also in upstream, so 2.6.29-rc also fails for you?
Dan, what's with replacing working devices with the cdc-acm driver with
option device ids? Is there some reason you did this?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [stable] A patch in 2.6.27.9 caused device names to change
2009-02-03 0:05 ` Greg KH
@ 2009-02-03 14:50 ` Dan Williams
2009-02-03 20:14 ` Chuck Ebbert
` (2 more replies)
0 siblings, 3 replies; 8+ messages in thread
From: Dan Williams @ 2009-02-03 14:50 UTC (permalink / raw)
To: Greg KH; +Cc: Chuck Ebbert, linux-kernel, stable
On Mon, 2009-02-02 at 16:05 -0800, Greg KH wrote:
> On Mon, Feb 02, 2009 at 05:02:38PM -0500, Chuck Ebbert wrote:
> > This patch:
> > http://git.kernel.org/?p=linux/kernel/git/stable/stable-queue.git;a=blob_plain;f=releases/2.6.27.9/usb-option-add-pantech-cards.patch;hb=HEAD
> >
> > replaced my wireless adapter's /dev/ttyACM0 interface with three interfaces:
> > /dev/ttyUSB[012]
> >
> > That broke my ppp connection scripts. And I have to use /dev/ttyUSB1 to connect,
> > not USB0. Also it looks like Network Manager only knows how to use the first
> > interface in its auto-connect mode, so people using that also lost their
> > connections.
>
> Ugh, that sucks.
>
> That is what is also in upstream, so 2.6.29-rc also fails for you?
>
> Dan, what's with replacing working devices with the cdc-acm driver with
> option device ids? Is there some reason you did this?
For a long time we've been operating under the assumption that mobile
broadband devices should be driven by option and sierra, since those
drivers had the necessary buffering optimizations to support
higher-speed mobile broadband devices. That was true at least up until
2.6.24.
Furthermore, up until this point, I have not seen mobile broadband
adapters (that aren't cellphones connected via USB) that *are* CDC-ACM
compliant. Everything previously has advertised proprietary interfaces,
some of which are serial ports and some of which are not.
Most mobile broadband cards *do* have more than one TTY, the others are
used for additional control ports or proprietary access for stuff like
GPS and flashing the firmware.
Can we get the 'lsusb -v' output for this card? I'm quite curious how
many endpoints and interfaces the device actually has.
Plus, are we expected to keep device names stable these days? cdc-acm
is the catch-all driver, but if that driver is more "generic" and a
better driver is found, can we not update IDs just because the device
name may change?
Dan
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [stable] A patch in 2.6.27.9 caused device names to change
2009-02-03 14:50 ` Dan Williams
@ 2009-02-03 20:14 ` Chuck Ebbert
2009-02-03 20:43 ` Dan Williams
2009-02-04 0:03 ` Greg KH
2009-02-04 11:20 ` Oliver Neukum
2 siblings, 1 reply; 8+ messages in thread
From: Chuck Ebbert @ 2009-02-03 20:14 UTC (permalink / raw)
To: Dan Williams; +Cc: Greg KH, linux-kernel, stable
On Tue, 03 Feb 2009 09:50:11 -0500
Dan Williams <dcbw@redhat.com> wrote:
> On Mon, 2009-02-02 at 16:05 -0800, Greg KH wrote:
> > On Mon, Feb 02, 2009 at 05:02:38PM -0500, Chuck Ebbert wrote:
> > > This patch:
> > > http://git.kernel.org/?p=linux/kernel/git/stable/stable-queue.git;a=blob_plain;f=releases/2.6.27.9/usb-option-add-pantech-cards.patch;hb=HEAD
> > >
> > > replaced my wireless adapter's /dev/ttyACM0 interface with three interfaces:
> > > /dev/ttyUSB[012]
> > >
> > > That broke my ppp connection scripts. And I have to use /dev/ttyUSB1 to connect,
> > > not USB0. Also it looks like Network Manager only knows how to use the first
> > > interface in its auto-connect mode, so people using that also lost their
> > > connections.
> >
> > Ugh, that sucks.
> >
> > That is what is also in upstream, so 2.6.29-rc also fails for you?
> >
I didn't try it, but it should. I don't have a problem with that, just with
changing the driver in a stable kernel update.
> > Dan, what's with replacing working devices with the cdc-acm driver with
> > option device ids? Is there some reason you did this?
>
> For a long time we've been operating under the assumption that mobile
> broadband devices should be driven by option and sierra, since those
> drivers had the necessary buffering optimizations to support
> higher-speed mobile broadband devices. That was true at least up until
> 2.6.24.
>
> Furthermore, up until this point, I have not seen mobile broadband
> adapters (that aren't cellphones connected via USB) that *are* CDC-ACM
> compliant. Everything previously has advertised proprietary interfaces,
> some of which are serial ports and some of which are not.
>
> Most mobile broadband cards *do* have more than one TTY, the others are
> used for additional control ports or proprietary access for stuff like
> GPS and flashing the firmware.
>
> Can we get the 'lsusb -v' output for this card? I'm quite curious how
> many endpoints and interfaces the device actually has.
>
Bus 002 Device 005: ID 106c:3711 Curitel Communications, Inc.
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 2 Communications
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x106c Curitel Communications, Inc.
idProduct 0x3711
bcdDevice 1.00
iManufacturer 1 PANTECH
iProduct 2 PANTECH USB MODEM
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 113
bNumInterfaces 4
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 500mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 2 Communications
bInterfaceSubClass 2 Abstract (modem)
bInterfaceProtocol 1 AT-commands (v.25ter)
iInterface 0
CDC Header:
bcdCDC 1.09
CDC Call Management:
bmCapabilities 0x03
call management
use DataInterface
bDataInterface 1
CDC ACM:
bmCapabilities 0x0f
connection notifications
sends break
line coding and serial state
get/set/clear comm features
CDC Union:
bMasterInterface 0
bSlaveInterface 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 9
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 10 CDC Data
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0
iInterface 3 Data Interface
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x85 EP 5 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x89 EP 9 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x07 EP 7 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 3
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 80 Bulk (Zip)
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x86 EP 6 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Device Status: 0x0000
(Bus Powered)
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [stable] A patch in 2.6.27.9 caused device names to change
2009-02-03 20:14 ` Chuck Ebbert
@ 2009-02-03 20:43 ` Dan Williams
0 siblings, 0 replies; 8+ messages in thread
From: Dan Williams @ 2009-02-03 20:43 UTC (permalink / raw)
To: Chuck Ebbert; +Cc: Greg KH, linux-kernel, stable
On Tue, 2009-02-03 at 15:14 -0500, Chuck Ebbert wrote:
> On Tue, 03 Feb 2009 09:50:11 -0500
> Dan Williams <dcbw@redhat.com> wrote:
>
> > On Mon, 2009-02-02 at 16:05 -0800, Greg KH wrote:
> > > On Mon, Feb 02, 2009 at 05:02:38PM -0500, Chuck Ebbert wrote:
> > > > This patch:
> > > > http://git.kernel.org/?p=linux/kernel/git/stable/stable-queue.git;a=blob_plain;f=releases/2.6.27.9/usb-option-add-pantech-cards.patch;hb=HEAD
> > > >
> > > > replaced my wireless adapter's /dev/ttyACM0 interface with three interfaces:
> > > > /dev/ttyUSB[012]
> > > >
> > > > That broke my ppp connection scripts. And I have to use /dev/ttyUSB1 to connect,
> > > > not USB0. Also it looks like Network Manager only knows how to use the first
> > > > interface in its auto-connect mode, so people using that also lost their
> > > > connections.
> > >
> > > Ugh, that sucks.
> > >
> > > That is what is also in upstream, so 2.6.29-rc also fails for you?
> > >
>
> I didn't try it, but it should. I don't have a problem with that, just with
> changing the driver in a stable kernel update.
>
> > > Dan, what's with replacing working devices with the cdc-acm driver with
> > > option device ids? Is there some reason you did this?
> >
> > For a long time we've been operating under the assumption that mobile
> > broadband devices should be driven by option and sierra, since those
> > drivers had the necessary buffering optimizations to support
> > higher-speed mobile broadband devices. That was true at least up until
> > 2.6.24.
> >
> > Furthermore, up until this point, I have not seen mobile broadband
> > adapters (that aren't cellphones connected via USB) that *are* CDC-ACM
> > compliant. Everything previously has advertised proprietary interfaces,
> > some of which are serial ports and some of which are not.
> >
> > Most mobile broadband cards *do* have more than one TTY, the others are
> > used for additional control ports or proprietary access for stuff like
> > GPS and flashing the firmware.
> >
> > Can we get the 'lsusb -v' output for this card? I'm quite curious how
> > many endpoints and interfaces the device actually has.
> >
>
> Bus 002 Device 005: ID 106c:3711 Curitel Communications, Inc.
Excellent. Thanks for the dump. My original patch is in error, and the
ID should indeed be handled by cdc-acm. If we figure out what the
additional interfaces are for, we can add matching to other drivers for
them, or something like that. Sound OK? Sorry for the error on my end.
Dan
> Device Descriptor:
> bLength 18
> bDescriptorType 1
> bcdUSB 2.00
> bDeviceClass 2 Communications
> bDeviceSubClass 0
> bDeviceProtocol 0
> bMaxPacketSize0 64
> idVendor 0x106c Curitel Communications, Inc.
> idProduct 0x3711
> bcdDevice 1.00
> iManufacturer 1 PANTECH
> iProduct 2 PANTECH USB MODEM
> iSerial 0
> bNumConfigurations 1
> Configuration Descriptor:
> bLength 9
> bDescriptorType 2
> wTotalLength 113
> bNumInterfaces 4
> bConfigurationValue 1
> iConfiguration 0
> bmAttributes 0x80
> (Bus Powered)
> MaxPower 500mA
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 0
> bAlternateSetting 0
> bNumEndpoints 1
> bInterfaceClass 2 Communications
> bInterfaceSubClass 2 Abstract (modem)
> bInterfaceProtocol 1 AT-commands (v.25ter)
> iInterface 0
> CDC Header:
> bcdCDC 1.09
> CDC Call Management:
> bmCapabilities 0x03
> call management
> use DataInterface
> bDataInterface 1
> CDC ACM:
> bmCapabilities 0x0f
> connection notifications
> sends break
> line coding and serial state
> get/set/clear comm features
> CDC Union:
> bMasterInterface 0
> bSlaveInterface 1
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x81 EP 1 IN
> bmAttributes 3
> Transfer Type Interrupt
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0040 1x 64 bytes
> bInterval 9
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 1
> bAlternateSetting 0
> bNumEndpoints 2
> bInterfaceClass 10 CDC Data
> bInterfaceSubClass 0 Unused
> bInterfaceProtocol 0
> iInterface 3 Data Interface
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x85 EP 5 IN
> bmAttributes 2
> Transfer Type Bulk
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0200 1x 512 bytes
> bInterval 0
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x03 EP 3 OUT
> bmAttributes 2
> Transfer Type Bulk
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0200 1x 512 bytes
> bInterval 0
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 2
> bAlternateSetting 0
> bNumEndpoints 2
> bInterfaceClass 255 Vendor Specific Class
> bInterfaceSubClass 0
> bInterfaceProtocol 0
> iInterface 0
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x89 EP 9 IN
> bmAttributes 2
> Transfer Type Bulk
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0200 1x 512 bytes
> bInterval 0
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x07 EP 7 OUT
> bmAttributes 2
> Transfer Type Bulk
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0200 1x 512 bytes
> bInterval 0
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 3
> bAlternateSetting 0
> bNumEndpoints 2
> bInterfaceClass 8 Mass Storage
> bInterfaceSubClass 6 SCSI
> bInterfaceProtocol 80 Bulk (Zip)
> iInterface 0
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x02 EP 2 OUT
> bmAttributes 2
> Transfer Type Bulk
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0200 1x 512 bytes
> bInterval 0
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x86 EP 6 IN
> bmAttributes 2
> Transfer Type Bulk
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0200 1x 512 bytes
> bInterval 0
> Device Status: 0x0000
> (Bus Powered)
>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [stable] A patch in 2.6.27.9 caused device names to change
2009-02-03 14:50 ` Dan Williams
2009-02-03 20:14 ` Chuck Ebbert
@ 2009-02-04 0:03 ` Greg KH
2009-02-04 7:28 ` Oliver Neukum
2009-02-04 11:20 ` Oliver Neukum
2 siblings, 1 reply; 8+ messages in thread
From: Greg KH @ 2009-02-04 0:03 UTC (permalink / raw)
To: Dan Williams; +Cc: Chuck Ebbert, linux-kernel, stable
On Tue, Feb 03, 2009 at 09:50:11AM -0500, Dan Williams wrote:
> On Mon, 2009-02-02 at 16:05 -0800, Greg KH wrote:
> > On Mon, Feb 02, 2009 at 05:02:38PM -0500, Chuck Ebbert wrote:
> > > This patch:
> > > http://git.kernel.org/?p=linux/kernel/git/stable/stable-queue.git;a=blob_plain;f=releases/2.6.27.9/usb-option-add-pantech-cards.patch;hb=HEAD
> > >
> > > replaced my wireless adapter's /dev/ttyACM0 interface with three interfaces:
> > > /dev/ttyUSB[012]
> > >
> > > That broke my ppp connection scripts. And I have to use /dev/ttyUSB1 to connect,
> > > not USB0. Also it looks like Network Manager only knows how to use the first
> > > interface in its auto-connect mode, so people using that also lost their
> > > connections.
> >
> > Ugh, that sucks.
> >
> > That is what is also in upstream, so 2.6.29-rc also fails for you?
> >
> > Dan, what's with replacing working devices with the cdc-acm driver with
> > option device ids? Is there some reason you did this?
>
> For a long time we've been operating under the assumption that mobile
> broadband devices should be driven by option and sierra, since those
> drivers had the necessary buffering optimizations to support
> higher-speed mobile broadband devices.
Who is "we" here? Not me :)
> That was true at least up until 2.6.24.
It all depends on the type of device. If it says it is a cdc-acm modem,
by all means, let that driver handle it, don't try to bind it to a
different driver (that way lies races and madness...)
> Furthermore, up until this point, I have not seen mobile broadband
> adapters (that aren't cellphones connected via USB) that *are* CDC-ACM
> compliant. Everything previously has advertised proprietary interfaces,
> some of which are serial ports and some of which are not.
Probably because we never see those devices being reported, because they
"just work" with no interaction from us.
> Plus, are we expected to keep device names stable these days? cdc-acm
> is the catch-all driver, but if that driver is more "generic" and a
> better driver is found, can we not update IDs just because the device
> name may change?
cdc-acm is the driver for devices that follow the spec and tell the host
computer that they are following the spec.
I'll go dig out and revert this patch, and then propagate it down to the
-stable releases as well...
thanks,
greg k-h
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [stable] A patch in 2.6.27.9 caused device names to change
2009-02-04 0:03 ` Greg KH
@ 2009-02-04 7:28 ` Oliver Neukum
0 siblings, 0 replies; 8+ messages in thread
From: Oliver Neukum @ 2009-02-04 7:28 UTC (permalink / raw)
To: Greg KH; +Cc: Dan Williams, Chuck Ebbert, linux-kernel, stable
Am Wednesday 04 February 2009 01:03:42 schrieb Greg KH:
> On Tue, Feb 03, 2009 at 09:50:11AM -0500, Dan Williams wrote:
> > For a long time we've been operating under the assumption that mobile
> > broadband devices should be driven by option and sierra, since those
> > drivers had the necessary buffering optimizations to support
> > higher-speed mobile broadband devices.
>
> Who is "we" here? Not me :)
We currently have three drivers that can handle high speed serial
connections in USB, option, sierra and cdc-acm.
> > That was true at least up until 2.6.24.
>
> It all depends on the type of device. If it says it is a cdc-acm modem,
> by all means, let that driver handle it, don't try to bind it to a
> different driver (that way lies races and madness...)
>
> > Furthermore, up until this point, I have not seen mobile broadband
> > adapters (that aren't cellphones connected via USB) that *are* CDC-ACM
> > compliant. Everything previously has advertised proprietary interfaces,
> > some of which are serial ports and some of which are not.
>
> Probably because we never see those devices being reported, because they
> "just work" with no interaction from us.
As far as I can tell, devices implementing the class specification are
new and still quite rare. This is probably related to the relative newness
of the WHC specification.
> > Plus, are we expected to keep device names stable these days? cdc-acm
> > is the catch-all driver, but if that driver is more "generic" and a
> > better driver is found, can we not update IDs just because the device
> > name may change?
There is no such thing as a better driver for a device that correctly
implements the class specification than the class driver. You haven't
seen complaints about cdc-acm's performance in a long time, have you?
Regards
Oliver
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [stable] A patch in 2.6.27.9 caused device names to change
2009-02-03 14:50 ` Dan Williams
2009-02-03 20:14 ` Chuck Ebbert
2009-02-04 0:03 ` Greg KH
@ 2009-02-04 11:20 ` Oliver Neukum
2 siblings, 0 replies; 8+ messages in thread
From: Oliver Neukum @ 2009-02-04 11:20 UTC (permalink / raw)
To: Dan Williams; +Cc: Greg KH, Chuck Ebbert, linux-kernel, stable
Am Tuesday 03 February 2009 15:50:11 schrieb Dan Williams:
> Furthermore, up until this point, I have not seen mobile broadband
> adapters (that aren't cellphones connected via USB) that *are* CDC-ACM
> compliant. Everything previously has advertised proprietary interfaces,
> some of which are serial ports and some of which are not.
>
> Most mobile broadband cards *do* have more than one TTY, the others are
> used for additional control ports or proprietary access for stuff like
> GPS and flashing the firmware.
Exactly for this reason, the cdc-wdm driver has been added to the kernel.
Regards
Oliver
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2009-02-04 11:20 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-02-02 22:02 [stable] A patch in 2.6.27.9 caused device names to change Chuck Ebbert
2009-02-03 0:05 ` Greg KH
2009-02-03 14:50 ` Dan Williams
2009-02-03 20:14 ` Chuck Ebbert
2009-02-03 20:43 ` Dan Williams
2009-02-04 0:03 ` Greg KH
2009-02-04 7:28 ` Oliver Neukum
2009-02-04 11:20 ` Oliver Neukum
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox