Dan Williams 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 ECM s
On Mon, 2013-11-11 at 18:41 +0100, Bjørn Mork wrote:
> Dan Williams writes:
> > On Mon, 2013-11-11 at 18:03 +0100, Bjørn Mork wrote:
> >> Dan Williams writes:
> >> > On Mon, 2013-11-11 at 15:43 +0100, Bjørn Mork wrote:
> >> >
> >> >> Maybe run a small discussion on the ModemManager list first? T
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 sur
Dan Williams writes:
> On Mon, 2013-11-11 at 18:03 +0100, Bjørn Mork wrote:
>> Dan Williams 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 th
On Mon, 2013-11-11 at 18:27 +0100, Bjørn Mork wrote:
> Gustavo Zacarias 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 b
On Mon, 2013-11-11 at 18:03 +0100, Bjørn Mork wrote:
> Dan Williams 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
> >> prepare
Gustavo Zacarias 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 device after
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 th
Dan Williams 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 ModemManager
On Mon, 2013-11-11 at 15:43 +0100, Bjørn Mork wrote:
> Gustavo Zacarias 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.
This is a bit
Gustavo Zacarias 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 first? This would
be
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_12D1&PID_1C07&MI_00
HUAWEI Mobile Connect Network
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 {
> USB_VENDOR_AND_I
Gustavo Zacarias 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 drivers i can't ge
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 th
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:
%QcomDevic
On Fri, Nov 08, 2013 at 08:44:35AM +0100, Bjørn Mork wrote:
> Johan Hovold 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 ne
Johan Hovold 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 from this list: s
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
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: Gustav
20 matches
Mail list logo
