Pasi Kärkkäinen writes:
> I applied the patch on top of Linux 3.13.6 kernel and now I'm able to use the
> wwan0 NCM interface successfully!
> I do get an IP with a dhcp client (this failed earlier without the patch),
> and Internet seems to work OK.
> So the patch definitely fixes the problem
On Mon, Mar 17, 2014 at 03:23:22PM +0100, Bjørn Mork wrote:
> Pasi Kärkkäinen writes:
> > On Mon, Mar 17, 2014 at 02:15:23PM +0100, Bjørn Mork wrote:
> >
> >> I still don't know for sure, but I do hope this bug is the real cause of
> >> the problems you are having. I'll send you a patch for testi
linux-usb@vger.kernel.org,
==Enrico Mioso , Oliver Neukum
==Subject: Re: [PATCH net-next v6 0/3] The huawei_cdc_ncm driver / E3276 problem
==
==Pasi Kärkkäinen writes:
==> On Mon, Mar 17, 2014 at 02:15:23PM +0100, Bjørn Mork wrote:
==>
==>> I still don't know for sure, but I d
Pasi Kärkkäinen writes:
> On Mon, Mar 17, 2014 at 02:15:23PM +0100, Bjørn Mork wrote:
>
>> I still don't know for sure, but I do hope this bug is the real cause of
>> the problems you are having. I'll send you a patch for testing as soon
>> as it is ready.
>>
>
> Sure. I'll be happy to test the
On Mon, Mar 17, 2014 at 02:15:23PM +0100, Bjørn Mork wrote:
> Pasi Kärkkäinen writes:
>
> > After playing with it for a while I got this:
> >
> > [ 1082.972880] cdc_ncm_setup: huawei_cdc_ncm 3-1:1.1: dwNtbInMaxSize=262144
> > dwNtbOutMaxSize=32768 wNdpOutPayloadRemainder=2 wNdpOutDivisor=4
> >
Pasi Kärkkäinen writes:
> After playing with it for a while I got this:
>
> [ 1082.972880] cdc_ncm_setup: huawei_cdc_ncm 3-1:1.1: dwNtbInMaxSize=262144
> dwNtbOutMaxSize=32768 wNdpOutPayloadRemainder=2 wNdpOutDivisor=4
> wNdpOutAlignment=4 wNtbOutMaxDatagrams=0 flags=0x1f
> [ 1082.972893] cdc_n
Bjørn Mork writes:
> But looking closer, I see that the SET_NTB_FORMAT returned -EPIPE,
> i.e. stall. The driver currently ignores this error, which is why we
> end up with different device and host settings.
>
> Anyone know what the proper driver action is? Note that this error
> cannot happen
Bjørn Mork writes:
> But here we have a device which does not comform to spec (that's OK,
> Huawei doesn't claim it does - this is a vendor specific function after
> all), and which seems to be locked to 32 bit mode? Either it requires
> the 32 bit variant, or we are doing something "wrong" duri
On Mon, Mar 17, 2014 at 01:59:19PM +0200, Pasi Kärkkäinen wrote:
> On Mon, Mar 17, 2014 at 12:31:53PM +0100, Bjørn Mork wrote:
> > Pasi Kärkkäinen writes:
> >
> > > http://pasik.reaktio.net/huawei-e3276-usbmon3.pcapng
> > >
> > > (I did move the dongle to a different usb bus nr 3 to make it the o
On Mon, Mar 17, 2014 at 12:31:53PM +0100, Bjørn Mork wrote:
> Pasi Kärkkäinen writes:
>
> > http://pasik.reaktio.net/huawei-e3276-usbmon3.pcapng
> >
> > (I did move the dongle to a different usb bus nr 3 to make it the only
> > device on that bus before capturing..)
>
> Thanks. That helps.
>
Pasi Kärkkäinen writes:
> http://pasik.reaktio.net/huawei-e3276-usbmon3.pcapng
>
> (I did move the dongle to a different usb bus nr 3 to make it the only device
> on that bus before capturing..)
Thanks. That helps.
> So what I did:
>
> - Start wireshark capture on USB bus nr 3.
> - Plug in t
On Fri, Mar 14, 2014 at 12:16:55PM -0500, Dan Williams wrote:
> On Fri, 2014-03-14 at 16:25 +0200, Pasi Kärkkäinen wrote:
> > On Fri, Mar 14, 2014 at 02:33:36PM +0100, Bjørn Mork wrote:
> > > Pasi Kärkkäinen writes:
> > > > On Fri, Mar 14, 2014 at 10:24:51AM +0100, Bjørn Mork wrote:
> > > >> Pasi
On Fri, 2014-03-14 at 16:25 +0200, Pasi Kärkkäinen wrote:
> On Fri, Mar 14, 2014 at 02:33:36PM +0100, Bjørn Mork wrote:
> > Pasi Kärkkäinen writes:
> > > On Fri, Mar 14, 2014 at 10:24:51AM +0100, Bjørn Mork wrote:
> > >> Pasi Kärkkäinen writes:
> > >>
> > >> > # ifconfig wwp0s26u1u5i1
> > >> > w
On Fri, Mar 14, 2014 at 02:33:36PM +0100, Bjørn Mork wrote:
> Pasi Kärkkäinen writes:
> > On Fri, Mar 14, 2014 at 10:24:51AM +0100, Bjørn Mork wrote:
> >> Pasi Kärkkäinen writes:
> >>
> >> > # ifconfig wwp0s26u1u5i1
> >> > wwp0s26u1u5i1: flags=4163 mtu 1500
> >> > inet 10.8.219.204 net
Pasi Kärkkäinen writes:
> On Fri, Mar 14, 2014 at 10:24:51AM +0100, Bjørn Mork wrote:
>> Pasi Kärkkäinen writes:
>>
>> > # ifconfig wwp0s26u1u5i1
>> > wwp0s26u1u5i1: flags=4163 mtu 1500
>> > inet 10.8.219.204 netmask 255.255.255.248 broadcast 10.8.219.207
>> > inet6 fe80::e5b:
On Fri, Mar 14, 2014 at 10:24:51AM +0100, Bjørn Mork wrote:
> Pasi Kärkkäinen writes:
>
> > # ifconfig wwp0s26u1u5i1
> > wwp0s26u1u5i1: flags=4163 mtu 1500
> > inet 10.8.219.204 netmask 255.255.255.248 broadcast 10.8.219.207
> > inet6 fe80::e5b:8fff:fe27:9a64 prefixlen 64 sco
Am 14.03.2014 10:24, schrieb Enrico Mioso:
Other than this, I do not have this device at hand, so can't see what happens.
From the version number, I expect the firmware being HiSilicon (not Qualcomm).
Try also using dhcpcd if you can / want / like :) .
Thank you.
dhcpcd doesn’t work too.
I h
net-next v6 0/3] The huawei_cdc_ncm driver / E3276 problem
==
==Pasi Kärkkäinen writes:
==
==> # ifconfig wwp0s26u1u5i1
==> wwp0s26u1u5i1: flags=4163 mtu 1500
==> inet 10.8.219.204 netmask 255.255.255.248 broadcast 10.8.219.207
==> inet6 fe80::e5b:8fff:fe27:9a64
Pasi Kärkkäinen writes:
> # ifconfig wwp0s26u1u5i1
> wwp0s26u1u5i1: flags=4163 mtu 1500
> inet 10.8.219.204 netmask 255.255.255.248 broadcast 10.8.219.207
> inet6 fe80::e5b:8fff:fe27:9a64 prefixlen 64 scopeid 0x20
> ether 0c:5b:8f:27:9a:64 txqueuelen 1000 (Ethernet)
rnel.org, Enrico Mioso ,
==Oliver Neukum
==Subject: Re: [PATCH net-next v6 0/3] The huawei_cdc_ncm driver / E3276 problem
==
==On Fri, Mar 14, 2014 at 09:58:43AM +0100, Bjørn Mork wrote:
==> Pasi Kärkkäinen writes:
==>
==> > ^NDISSTAT:1,,,"IPV4"
==> > ^RSSI: 2
On Fri, Mar 14, 2014 at 09:58:43AM +0100, Bjørn Mork wrote:
> Pasi Kärkkäinen writes:
>
> > ^NDISSTAT:1,,,"IPV4"
> > ^RSSI: 21
> >
> >
> > ^DHCP: CCDB080A,F8FF,C9DB080A,C9DB080A,E67B59C0,E77B59C0,85600,85600
>
>
> The hex numbers are IPv4 addresses in little endian. The decimal numbers
> a
Pasi Kärkkäinen writes:
> ^NDISSTAT:1,,,"IPV4"
> ^RSSI: 21
>
>
> ^DHCP: CCDB080A,F8FF,C9DB080A,C9DB080A,E67B59C0,E77B59C0,85600,85600
The hex numbers are IPv4 addresses in little endian. The decimal numbers
at the end are speed down/up IIRC.
Printed in a more readable form, this is:
10
On Fri, Mar 14, 2014 at 09:34:39AM +0100, Bjørn Mork wrote:
> Pasi Kärkkäinen writes:
> > On Fri, Mar 14, 2014 at 12:08:12AM +0200, Pasi Kärkkäinen wrote:
> >>
> >> I've been using:
> >>
> >> ATQ0 V1 E1 S0=0
> >> AT^NDISDUP=1,1,"internet"
> >> AT^DHCP?
> >>
> >
> > Oh, I forgot to mention.. after
Pasi Kärkkäinen writes:
> On Fri, Mar 14, 2014 at 12:08:12AM +0200, Pasi Kärkkäinen wrote:
>>
>> I've been using:
>>
>> ATQ0 V1 E1 S0=0
>> AT^NDISDUP=1,1,"internet"
>> AT^DHCP?
>>
>
> Oh, I forgot to mention.. after I send AT^NDISDUP=1,1,"internet" I get this:
>
> ^NDISSTAT:1,,,"IPV4"
>
> .. whic
t also as a
> >>>>> mean
> >>>>> to encapsulate other protocols, as is the case for the Huawei E3131 and
> >>>>> E3251 modem devices.
> >>>>
> >>>> Hello,
> >>>>
> >>>> I'm tryin
ion of the huawei_cdc_ncm.c driver, which
>>>>> supports devices resembling the NCM standard, but using it also as a mean
>>>>> to encapsulate other protocols, as is the case for the Huawei E3131 and
>>>>> E3251 modem devices.
>>>>
>>>> H
> > > to encapsulate other protocols, as is the case for the Huawei E3131 and
> > > > E3251 modem devices.
> > > >
> > >
> > > Hello,
> > >
> > > I'm trying to use Huawei E3276 4G/LTE USB dongle with Linux 3.13.6 kernel,
&g
gt; Hello,
> >
> > I'm trying to use Huawei E3276 4G/LTE USB dongle with Linux 3.13.6 kernel,
> > and thus i'm using the new huawei_cdc_ncm driver.
> >
> > I'm using the /dev/cdc-wdm0 device to send AT commands to it, and that
> > seems to w
ng the NCM standard, but using it also as a mean
> > to encapsulate other protocols, as is the case for the Huawei E3131 and
> > E3251 modem devices.
> >
>
> Hello,
>
> I'm trying to use Huawei E3276 4G/LTE USB dongle with Linux 3.13.6 kernel,
> and thus i&
s the case for the Huawei E3131 and
> E3251 modem devices.
>
Hello,
I'm trying to use Huawei E3276 4G/LTE USB dongle with Linux 3.13.6 kernel,
and thus i'm using the new huawei_cdc_ncm driver.
I'm using the /dev/cdc-wdm0 device to send AT commands to it, and that seems
"Thomas Schäfer" wrote:
>So problem seems to be somewhere but not in you driver.
Let's hope so. I always worry when making changes, no matter how insignificant
they are. I often feel like my bug to line ratio is a two digit number...
Thanks for checking.
Bjørn
--
To unsubscribe from this
> If that still does not change anything, then I'd really appreciate it if
> you could run through (assuming the v3.11 driver was OK):
>
> git bisect start 9fea037de5f3 v3.11 -- drivers/net/usb/cdc_ncm.c
>
That failed too.
(switching was ok, compiling was ok, booting, recognizing the devic
Hi,
> I do not have any Huawei NCM device, so I cannot really test the new
> huawei_cdc_ncm.
> A simple test would be just reverting commit 9fea037de5f3 ("net:
> cdc_ncm: remove non-standard NCM device IDs"), to make the cdc_ncm
> driver (with all the recent changes) handle this device again.
Thomas Schäfer writes:
>> > The second device with problems is Huawei E3276 (Speedstick LTE III,
>> > Telekom, no Hilink, but ipv6-cabable version) This device worked before
>> > with SLAAC, now with -next-20131107 it doesn't.
>> Ouch. I noticed after submitting this driver that it probably has
> >
> > The second device with problems is Huawei E3276 (Speedstick LTE III,
> > Telekom, no Hilink, but ipv6-cabable version) This device worked before
> > with SLAAC, now with -next-20131107 it doesn't.
> Ouch. I noticed after submitting this driver that it probably has some
> flawed logic wr
Thomas Schäfer writes:
> Hi,
>
> I know that next-kernel may not stable/work. But for your information.
>
> I tried 3.12.0-next-20131107-1-vanilla (next repository from Suse, because
> compiling needs time and patience :-))
>
> Two devices which worked with cdc_ncm now changed to huawei_cdc_ncm
Hi,
I know that next-kernel may not stable/work. But for your information.
I tried 3.12.0-next-20131107-1-vanilla (next repository from Suse, because
compiling needs time and patience :-))
Two devices which worked with cdc_ncm now changed to huawei_cdc_ncm. So far so
ok.
But: E5776-s-32 (loc
From: Bjørn Mork
Date: Mon, 4 Nov 2013 09:50:46 +0100
> Enrico has been kind enough to let me repost his driver with the changes
> requested by Oliver Neukum during the last review of this series.
>
> The changes I have made from Enricos original v5 series to this version
> are:
>
> v6:
> - f
On Fri, 2013-11-01 at 12:35 +0100, Bjørn Mork wrote:
> So I believe we should do the update unconditionally, and but skip
> usb_autopm_put_interface if the get failed. Accordingly, these
> functions should always return 0 (not that there is anything currently
> checking the return anyway).
>
> I
any list except the Modem Manager's one, so please
CC me, thanks!!
[/quote]
Enrico Mioso (3):
net: cdc_ncm: Export cdc_ncm_{tx,rx}_fixup functions for re-use
net: huawei_cdc_ncm: Introduce the huawei_cdc_ncm driver
net: cdc_ncm: remove non-standard NCM device IDs
drivers/net/usb/Kco
From: Enrico Mioso
This driver supports devices using the NCM protocol as an encapsulation layer
for other protocols, like the E3131 Huawei 3G modem. This drivers approach was
heavily inspired by the qmi_wwan/cdc_mbim approach & code model.
Signed-off-by: Enrico Mioso
Signed-off-by: Bjørn Mork
Oliver Neukum writes:
> On Mon, 2013-09-30 at 04:50 +, Enrico Mioso wrote:
>
>> +static int huawei_cdc_ncm_manage_power(struct usbnet *usbnet_dev, int on)
>> +{
>> +struct huawei_cdc_ncm_state *drvstate = (void *)&usbnet_dev->data;
>> +int rv = 0;
>> +
>> +if ((on && atomic_add_ret
On Mon, 2013-09-30 at 04:50 +, Enrico Mioso wrote:
> +static int huawei_cdc_ncm_manage_power(struct usbnet *usbnet_dev, int on)
> +{
> + struct huawei_cdc_ncm_state *drvstate = (void *)&usbnet_dev->data;
> + int rv = 0;
> +
> + if ((on && atomic_add_return(1, &drvstate->pmcount) ==
Enrico Mioso writes:
> So this is a new, revised, edition of the huawei_cdc_ncm.c driver, which
> supports devices resembling the NCM standard, but using it also as a mean
> to encapsulate other protocols, as is the case for the Huawei E3131 and
> E3251 modem devices.
> Some precisations are ne
This driver supports devices using the NCM protocol as an encapsulation layer
for other protocols, like the E3131 Huawei 3G modem. This drivers approach was
heavily inspired by the qmi_wwan/cdc_mbim approach & code model.
Suggested-by: Bjorn Mork
Signed-off-by: Enrico Mioso
create mode 100644
one, so please
CC me, thanks!!
Enrico Mioso (3):
net: cdc_ncm: Export cdc_ncm_{tx,rx}_fixup functions for re-use
net: huawei_cdc_ncm: Introduce the huawei_cdc_ncm driver
net: cdc_ncm: remove non-standard NCM device IDs
drivers/net/usb/Kconfig | 15 +++
drivers/net/usb/Makefile
Hi guys!! :)
First of all - I would like to thank both of you for your interest and time in
my patches.
I agree with Joe's point of view, completely. The Coding style document tries
to leverage on the developer's good sense, even when defining some rules.
Apart from that - checkpatch.po informed
On Mon, 2013-08-26 at 17:09 -0400, David Miller wrote:
> From: Joe Perches
[]
> Don't try to over-simplify things and act as if they are black
> and white when they aren't.
It wasn't me simplifying.
I commented on your request to:
"order local function variable declarations by line
length, lon
From: Joe Perches
Date: Mon, 26 Aug 2013 14:05:55 -0700
> On Mon, 2013-08-26 at 16:58 -0400, David Miller wrote:
>> From: Joe Perches
>> Date: Mon, 26 Aug 2013 13:45:13 -0700
>>
>> > I think the premise of local variable
>> > declaration by line length is flawed.
>>
>> I disagree.
>>
>> > It
On Mon, 2013-08-26 at 16:58 -0400, David Miller wrote:
> From: Joe Perches
> Date: Mon, 26 Aug 2013 13:45:13 -0700
>
> > I think the premise of local variable
> > declaration by line length is flawed.
>
> I disagree.
>
> > It can't work when local variables are
> > dependent on initialization o
From: Joe Perches
Date: Mon, 26 Aug 2013 13:45:13 -0700
> I think the premise of local variable
> declaration by line length is flawed.
I disagree.
> It can't work when local variables are
> dependent on initialization order as
> above.
Move the initialization below the declarations.
--
To uns
On Mon, 2013-08-26 at 16:31 -0400, David Miller wrote:
> From: Enrico Mioso
[]
> > + int ret = 0;
> > + struct usbnet *usbnet_dev = usb_get_intfdata(intf);
> > + struct huawei_cdc_ncm_state *drvstate = (void *)&usbnet_dev->data;
> > + struct cdc_ncm_ctx *ctx = drvstate->ctx;
> > +
From: Enrico Mioso
Date: Fri, 23 Aug 2013 09:56:29 +0200
> + if ((on && atomic_add_return(1, &drvstate->pmcount) == 1) || (!on &&
> atomic_dec_and_test(&drvstate->pmcount))) {
These line significantly exceeds 80 columns.
> + subdriver = usb_cdc_wdm_register(ctx->control,
> +
These patches are all related to the new huawei_cdc_ncm driver, supporting
devices that use the NCM protocol as a transport layer for other protocols.
this is the case of the Huawei E3131 3G modem.
In this version - I actually added the driver file! :) I don't know how I ended
up forge
This driver supports devices using the NCM protocol as an encapsulation layer
for other protocols, like the E3131 Huawei 3G modem. This drivers approach was
heavily inspired by the qmi_wwan approach & code model.
Suggested-by: Bjorn Mork
Signed-off-by: Enrico Mioso
---
drivers/net/usb/Kconfig
On Thu, Aug 22, 2013 at 04:30:40AM +0200, Enrico Mioso wrote:
> This driver supports devices using the NCM protocol as an encapsulation layer
> for other protocols, like the E3131 Huawei 3G modem. This driver was heavily
> inspired by the qmi_wwan approach & code model.
Line-wrap your changelog l
This driver supports devices using the NCM protocol as an encapsulation layer
for other protocols, like the E3131 Huawei 3G modem. This driver was heavily
inspired by the qmi_wwan approach & code model.
Suggested-by: Bjorn Mork
Signed-off-by: Enrico Mioso
---
drivers/net/usb/Kconfig | 11 ++
This driver supports devices using the NCM protocol as an encapsulation layer
for other protocols, like the E3131 Huawei 3G modem.
Suggested-by: Bjorn Mork
Signed-off-by: Enrico Mioso
---
drivers/net/usb/Kconfig | 11 ++
drivers/net/usb/Makefile |1 +
drivers/net/usb/hua
58 matches
Mail list logo
