On 11/08/2013 04:44 AM, Bjørn Mork wrote:
I believe it's nice to document the layout of complex composite devices
if known, but if not then I don't see any need to delay a patch like
this.
From looking at the .inf files from the windows drivers i can't get much
info other than:
On 11/09/2013 10:47 AM, Johan Hovold wrote:
Ok. Thanks.
Gustavo, could you fix up the commit message (the subject line) and
resend so we can apply this?
Sure, but it was already handled by {
USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0xff, 0xff) }
which caused issues without the
Gustavo Zacarias gust...@zacarias.com.ar writes:
On 11/08/2013 04:44 AM, Bjørn Mork wrote:
I believe it's nice to document the layout of complex composite devices
if known, but if not then I don't see any need to delay a patch like
this.
From looking at the .inf files from the windows
On Mon, Nov 11, 2013 at 06:47:52AM -0300, Gustavo Zacarias wrote:
On 11/09/2013 10:47 AM, Johan Hovold wrote:
Ok. Thanks.
Gustavo, could you fix up the commit message (the subject line) and
resend so we can apply this?
Sure, but it was already handled by {
On 11/11/2013 10:41 AM, Bjørn Mork wrote:
One way, if you have access to a Windows system, is observing what
happens there. You can look up vid/pid/intfnumber in the Windows device
manager.
From windows i've got:
3G Modem - usbcdcacm\VID_12D1PID_1C07MI_00
HUAWEI Mobile Connect Network
Gustavo Zacarias gust...@zacarias.com.ar writes:
With minicom on /dev/cdc-wdm0 after patching qmi_wwan it seems to be
responsive to AT commands so yes it seems we are dealing with ECM here.
I'll send a followup patch to include qmi_wwan.
Maybe run a small discussion on the ModemManager list
On Mon, 2013-11-11 at 15:43 +0100, Bjørn Mork wrote:
Gustavo Zacarias gust...@zacarias.com.ar writes:
With minicom on /dev/cdc-wdm0 after patching qmi_wwan it seems to be
responsive to AT commands so yes it seems we are dealing with ECM here.
I'll send a followup patch to include
Dan Williams d...@redhat.com writes:
On Mon, 2013-11-11 at 15:43 +0100, Bjørn Mork wrote:
Maybe run a small discussion on the ModemManager list first? This would
be the first non-QMI device there, and I don't think userspace is
prepared for that
We've got a bug open for this in
On 11/11/2013 01:10 PM, Dan Williams wrote:
This is a bit confusing... so you added the device to qmi_wwan, and now
one of the AT ports works (cdc-wdm0) and the net port also works, as
exposed by qmi_wwan?
What's the full lsusb -v for this device after it's modeswitched? I
looked through
Gustavo Zacarias gust...@zacarias.com.ar writes:
On 11/11/2013 01:10 PM, Dan Williams wrote:
This is a bit confusing... so you added the device to qmi_wwan, and now
one of the AT ports works (cdc-wdm0) and the net port also works, as
exposed by qmi_wwan?
What's the full lsusb -v for this
On Mon, 2013-11-11 at 18:03 +0100, Bjørn Mork wrote:
Dan Williams d...@redhat.com writes:
On Mon, 2013-11-11 at 15:43 +0100, Bjørn Mork wrote:
Maybe run a small discussion on the ModemManager list first? This would
be the first non-QMI device there, and I don't think userspace is
On Mon, 2013-11-11 at 18:27 +0100, Bjørn Mork wrote:
Gustavo Zacarias gust...@zacarias.com.ar writes:
On 11/11/2013 01:10 PM, Dan Williams wrote:
This is a bit confusing... so you added the device to qmi_wwan, and now
one of the AT ports works (cdc-wdm0) and the net port also works, as
Dan Williams d...@redhat.com writes:
On Mon, 2013-11-11 at 18:03 +0100, Bjørn Mork wrote:
Dan Williams d...@redhat.com writes:
On Mon, 2013-11-11 at 15:43 +0100, Bjørn Mork wrote:
Maybe run a small discussion on the ModemManager list first? This would
be the first non-QMI device there,
On 11/11/2013 02:27 PM, Bjørn Mork wrote:
If dhcp doesn't work after a successful AT^NDISDUP connection, then
there is still a chance that this actuall is a NCM device. That would
make things easier in many ways :-)
Please try the huawei_cdc_ncm driver, although I am not completely sure
On Mon, 2013-11-11 at 18:41 +0100, Bjørn Mork wrote:
Dan Williams d...@redhat.com writes:
On Mon, 2013-11-11 at 18:03 +0100, Bjørn Mork wrote:
Dan Williams d...@redhat.com writes:
On Mon, 2013-11-11 at 15:43 +0100, Bjørn Mork wrote:
Maybe run a small discussion on the ModemManager
Dan Williams d...@redhat.com writes:
So the net-port parts of qmi_wwan just do standard ECM then?
Yes. Only the descriptors are weird. The rest is standard ECM.
Well, including all the IPv4/IPv6 quirks?
No, all the firmware bugs are very implementation specific :-)
I don't know if the
On Fri, Nov 08, 2013 at 08:44:35AM +0100, Bjørn Mork wrote:
Johan Hovold jhov...@gmail.com writes:
Bjørn, do you want any more info for the commit message (e.g. interface
layout)?
I believe it's nice to document the layout of complex composite devices
if known, but if not then I don't
On Tue, Nov 05, 2013 at 07:20:41AM -0300, Gustavo Zacarias wrote:
Interface 1 on this device isn't for option to bind to otherwise an oops
on usb_wwan with log flooding will happen when accessing the port:
tty_release: ttyUSB1: read/write wait queue active!
It doesn't seem to respond to
Johan Hovold jhov...@gmail.com writes:
Bjørn, do you want any more info for the commit message (e.g. interface
layout)?
I believe it's nice to document the layout of complex composite devices
if known, but if not then I don't see any need to delay a patch like
this.
Bjørn
--
To unsubscribe
Interface 1 on this device isn't for option to bind to otherwise an oops
on usb_wwan with log flooding will happen when accessing the port:
tty_release: ttyUSB1: read/write wait queue active!
It doesn't seem to respond to QMI if it's added to qmi_wwan so don't add
it there.
Signed-off-by:
20 matches
Mail list logo
