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
-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
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
=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
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 +++
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
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
>>
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
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
>> >> >>>
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
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:
>> >>
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
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
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
>>
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
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
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
>
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
>> 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
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
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
21 matches
Mail list logo