[PATCH] cdc_ether: flag the Huawei ME906/ME909 as WWAN

2017-10-23 Thread Aleksander Morgado
The Huawei ME906 (12d1:15c1) comes with a standard ECM interface that requires management via AT commands sent over one of the control TTYs (e.g. connected with AT^NDISDUP). Signed-off-by: Aleksander Morgado <aleksan...@aleksander.es> --- drivers/net/usb/cdc_ether.c | 6 ++ 1 file chan

[PATCH] cdc_ether: flag the u-blox TOBY-L2 and SARA-U2 as wwan

2017-10-09 Thread Aleksander Morgado
-by: Aleksander Morgado <aleksan...@aleksander.es> --- drivers/net/usb/cdc_ether.c | 13 + 1 file changed, 13 insertions(+) diff --git a/drivers/net/usb/cdc_ether.c b/drivers/net/usb/cdc_ether.c index 29c7e2ec0dcb..52ea80bcd639 100644 --- a/drivers/net/usb/cdc_ether.c +++ b/drive

[PATCH] rndis_host: support Novatel Verizon USB730L

2017-09-27 Thread Aleksander Morgado
ECM interface which doesn't require any other kernel update to make it work. Signed-off-by: Aleksander Morgado <aleksan...@aleksander.es> --- Hey, I'm not sure if binding this logic to a specific vid:pid (1410:9030) would be more appropriate here, or if it's ok to just bind class/subclass

[PATCH v2] cdc_ncm: flag the u-blox TOBY-L4 as wwan

2017-08-25 Thread Aleksander Morgado
=1,' and then running DHCP on the NCM interface. Signed-off-by: Aleksander Morgado <aleksan...@aleksander.es> --- drivers/net/usb/cdc_ncm.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c index 811b18215cae..47cab1bde065

Re: [PATCH] cdc_ncm: flag the ublox TOBY-L4 as wwan

2017-08-25 Thread Aleksander Morgado
On Fri, Aug 25, 2017 at 3:22 PM, Greg KH <gre...@linuxfoundation.org> wrote: > On Fri, Aug 25, 2017 at 02:59:46PM +0200, Aleksander Morgado wrote: >> Signed-off-by: Aleksander Morgado <aleksan...@aleksander.es> >> --- >> drivers/net/usb/cdc_ncm.c | 7 +++

[PATCH] cdc_ncm: flag the ublox TOBY-L4 as wwan

2017-08-25 Thread Aleksander Morgado
Signed-off-by: Aleksander Morgado <aleksan...@aleksander.es> --- drivers/net/usb/cdc_ncm.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c index 811b18215cae..47cab1bde065 100644 --- a/drivers/net/usb/cdc_ncm.c +++ b/drivers/n

Re: [PATCH 1/1] drivers: net: usb: qmi_wwan: add QMI_QUIRK_SET_DTR for Telit PID 0x1201

2017-04-19 Thread Aleksander Morgado
On Wed, Apr 19, 2017 at 7:28 PM, Bjørn Mork wrote: >> as a side note in latest kernels I had troubles with qmi devices >> (e.g. I/O error when using qmicli). >> >> I found your suggestion in libqmi mailing list to revert commit >> >> 833415a3e781a26fe480a34d45086bdb4fe1e4c0 >>

Re: [PATCH 0/6] net: qmi_wwan: MDM9x30 support

2015-12-04 Thread Aleksander Morgado
On Thu, Dec 3, 2015 at 7:24 PM, Bjørn Mork wrote: > We add new device IDs all the time, often without any testing on > actual hardware. This is usually OK as long as the device is similar > to already supported devices, using the same chipset and firmware > basis. But the Sierra

Re: [RFC][PATCH] net: arinc429: Add ARINC-429 stack

2015-11-18 Thread Aleksander Morgado
On Tue, Nov 10, 2015 at 5:15 PM, Marek Vasut wrote: >> >> >>> > About the parity -- can we add some flag into the datagram to >> >> >>> > indicate we want hardware to calculate the parity for that >> >> >>> > particular datagram for us? And we'd also need to indicate what >> >> >>>

Re: [RFC][PATCH] net: arinc429: Add ARINC-429 stack

2015-11-04 Thread Aleksander Morgado
On Wed, Nov 4, 2015 at 4:18 PM, Vostrikov Andrey wrote: >>> > About the parity -- can we add some flag into the datagram to indicate we >>> > want hardware to calculate the parity for that particular datagram for >>> > us? And we'd also need to indicate what

Re: [RFC][PATCH] net: arinc429: Add ARINC-429 stack

2015-11-04 Thread Aleksander Morgado
On Wed, Nov 4, 2015 at 4:33 PM, Marek Vasut <ma...@denx.de> wrote: > On Wednesday, November 04, 2015 at 04:19:45 PM, Aleksander Morgado wrote: >> On Wed, Nov 4, 2015 at 4:18 PM, Vostrikov Andrey >> >> <andrey.vostri...@cogentembedded.com> wrote: >> >>

Re: [RFC][PATCH] net: arinc429: Add ARINC-429 stack

2015-11-04 Thread Aleksander Morgado
On Tue, Nov 3, 2015 at 10:43 PM, Marek Vasut wrote: > On Tuesday, November 03, 2015 at 08:28:43 PM, Oliver Hartkopp wrote: >> On 11/03/2015 08:19 PM, Marek Vasut wrote: >> > On Tuesday, November 03, 2015 at 07:03:26 PM, Oliver Hartkopp wrote: >> >> On 11/03/2015 06:41 PM, Marek

Re: [RFC][PATCH] net: arinc429: Add ARINC-429 stack

2015-11-04 Thread Aleksander Morgado
On Tue, Nov 3, 2015 at 6:33 PM, Marek Vasut <ma...@denx.de> wrote: > On Tuesday, November 03, 2015 at 05:56:53 PM, Aleksander Morgado wrote: >> On Tue, Nov 3, 2015 at 5:18 PM, Aleksander Morgado >> >> <aleksan...@aleksander.es> wrote: >> > On Tue, Nov 3, 2

Re: [RFC][PATCH] net: arinc429: Add ARINC-429 stack

2015-11-04 Thread Aleksander Morgado
On Tue, Nov 3, 2015 at 6:01 PM, Oliver Hartkopp wrote: >> Unrelated to all this, another key point in ARINC is the timing for >> each label when transmitting. The common case you get is different >> labels being sent continuously with a given rate for each. E.g. labels >>

Re: [RFC][PATCH] net: arinc429: Add ARINC-429 stack

2015-11-03 Thread Aleksander Morgado
On Tue, Nov 3, 2015 at 12:36 PM, Marc Kleine-Budde <m...@pengutronix.de> wrote: > On 11/03/2015 11:36 AM, Aleksander Morgado wrote: >> On Mon, Nov 2, 2015 at 9:25 PM, Marek Vasut <ma...@denx.de> wrote: >>>>> I was thinking about this and I mostly agree with yo

Re: [RFC][PATCH] net: arinc429: Add ARINC-429 stack

2015-11-03 Thread Aleksander Morgado
Hey! On Mon, Nov 2, 2015 at 9:25 PM, Marek Vasut wrote: >> > I was thinking about this and I mostly agree with you. Obviously, copying >> > the code this way was dumb. On the other hand, ARINC and CAN are two >> > different sort of busses, so I'd propose something slightly

Re: [RFC][PATCH] net: arinc429: Add ARINC-429 stack

2015-11-03 Thread Aleksander Morgado
On Tue, Nov 3, 2015 at 5:18 PM, Aleksander Morgado <aleksan...@aleksander.es> wrote: > On Tue, Nov 3, 2015 at 4:19 PM, Marek Vasut <ma...@denx.de> wrote: >>> , or the duplex TX/RX setup for channels >>> (channels are either RX or TX, not both), or the local >

Re: [RFC][PATCH] net: arinc429: Add ARINC-429 stack

2015-11-03 Thread Aleksander Morgado
On Tue, Nov 3, 2015 at 4:19 PM, Marek Vasut wrote: >> , or the duplex TX/RX setup for channels >> (channels are either RX or TX, not both), or the local >> echoing/loopback (which wouldn't make much sense for TX-only >> channels). > > Aren't the RX-only/TX-only channels rather a

Re: [RFC][PATCH] net: arinc429: Add ARINC-429 stack

2015-11-03 Thread Aleksander Morgado
>> or the duplex TX/RX setup for channels >> (channels are either RX or TX, not both), or the local >> echoing/loopback (which wouldn't make much sense for TX-only >> channels). > > Local echo/loopback comes in two flavours: > - Other socket receive local generate frames, too. > This is

Re: [RFC][PATCH] net: arinc429: Add ARINC-429 stack

2015-11-03 Thread Aleksander Morgado
On Tue, Nov 3, 2015 at 4:19 PM, Marek Vasut wrote: >> > I was thinking about this and I mostly agree with you. Obviously, >> > copying the code this way was dumb. On the other hand, ARINC and CAN >> > are two different sort of busses, so I'd propose something slightly

Re: [RFC][PATCH] net: arinc429: Add ARINC-429 stack

2015-11-02 Thread Aleksander Morgado
On Mon, Nov 2, 2015 at 12:14 PM, Oliver Hartkopp wrote: > > What about defining some overlay data structure to map ARINC-429 frames into > CAN frames? > > E.g. we could write the ARINC 32 bit data completely into data[0..3] and > additionally copy the 8 bit label