* [PATCH net-next 8/9] mlx5: Fix sparse warnings
From: Eli Cohen @ 2014-12-02 10:26 UTC (permalink / raw)
To: davem; +Cc: roland, linux-rdma, netdev, ogerlitz, amirv, Eli Cohen
In-Reply-To: <1417515979-22418-1-git-send-email-eli@mellanox.com>
1. Add required __acquire/__release statements to balance spinlock usage.
2. Change the index parameter of begin_wqe() to be unsigned to match supplied
argument type.
Signed-off-by: Eli Cohen <eli@mellanox.com>
---
drivers/infiniband/hw/mlx5/qp.c | 16 +++++++++++++++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/infiniband/hw/mlx5/qp.c b/drivers/infiniband/hw/mlx5/qp.c
index 0e2ef9fe0e29..1cae1c7132b4 100644
--- a/drivers/infiniband/hw/mlx5/qp.c
+++ b/drivers/infiniband/hw/mlx5/qp.c
@@ -1011,9 +1011,14 @@ static void mlx5_ib_lock_cqs(struct mlx5_ib_cq *send_cq, struct mlx5_ib_cq *recv
}
} else {
spin_lock_irq(&send_cq->lock);
+ __acquire(&recv_cq->lock);
}
} else if (recv_cq) {
spin_lock_irq(&recv_cq->lock);
+ __acquire(&send_cq->lock);
+ } else {
+ __acquire(&send_cq->lock);
+ __acquire(&recv_cq->lock);
}
}
@@ -1033,10 +1038,15 @@ static void mlx5_ib_unlock_cqs(struct mlx5_ib_cq *send_cq, struct mlx5_ib_cq *re
spin_unlock_irq(&recv_cq->lock);
}
} else {
+ __release(&recv_cq->lock);
spin_unlock_irq(&send_cq->lock);
}
} else if (recv_cq) {
+ __release(&send_cq->lock);
spin_unlock_irq(&recv_cq->lock);
+ } else {
+ __release(&recv_cq->lock);
+ __release(&send_cq->lock);
}
}
@@ -2411,7 +2421,7 @@ static u8 get_fence(u8 fence, struct ib_send_wr *wr)
static int begin_wqe(struct mlx5_ib_qp *qp, void **seg,
struct mlx5_wqe_ctrl_seg **ctrl,
- struct ib_send_wr *wr, int *idx,
+ struct ib_send_wr *wr, unsigned *idx,
int *size, int nreq)
{
int err = 0;
@@ -2737,6 +2747,8 @@ out:
if (bf->need_lock)
spin_lock(&bf->lock);
+ else
+ __acquire(&bf->lock);
/* TBD enable WC */
if (0 && nreq == 1 && bf->uuarn && inl && size > 1 && size <= bf->buf_size / 16) {
@@ -2753,6 +2765,8 @@ out:
bf->offset ^= bf->buf_size;
if (bf->need_lock)
spin_unlock(&bf->lock);
+ else
+ __release(&bf->lock);
}
spin_unlock_irqrestore(&qp->sq.lock, flags);
--
2.1.3
^ permalink raw reply related
* Re: Is this 32-bit NCM?
From: Enrico Mioso @ 2014-12-02 10:32 UTC (permalink / raw)
To: Kevin Zhu
Cc: Eli Britstein, Bjørn Mork, Alex Strizhevsky,
Midge Shaojun Tan, youtux@gmail.com, linux-usb@vger.kernel.org,
netdev@vger.kernel.org
In-Reply-To: <547D7243.80508@audiocodes.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 18265 bytes --]
Kevin - it works! the key seems to be in the tx_fixup function; there is a
special handling for frames effectively.
Please ... help me backport those changes to the standard Linux driver - it
will be a gain for us all, and in general you'll have a more probable
maintenance than you would with the driver from huawei.
Sorry huawei guys - I respect you, but there is a reason if drivers needs some
modifications to get merged. Hoping not to sound arrogant, my intent was only
to be clear.
On Tue, 2 Dec 2014, Kevin Zhu wrote:
==Date: Tue, 2 Dec 2014 09:03:21
==From: Kevin Zhu <Mingying.Zhu@audiocodes.com>
==To: Eli Britstein <Eli.Britstein@audiocodes.com>,
== Enrico Mioso <mrkiko.rs@gmail.com>
==Cc: Bjørn Mork <bjorn@mork.no>, Alex Strizhevsky <alexxst@gmail.com>,
== Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>,
== "youtux@gmail.com" <youtux@gmail.com>,
== "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
== "netdev@vger.kernel.org" <netdev@vger.kernel.org>
==Subject: Re: Is this 32-bit NCM?
==
==Below is the content of the INF file oem54.inf.
==
==; Copyright (c) 2010,2011 Huawei Incorporated
==; Manufacturer: Huawei Incorporated
==;
==; CDC ECM & NCM driver
==;
==
==[Version]
==Signature="$WINDOWS NT$"
==Class=Net
==ClassGUID={4d36e972-e325-11ce-bfc1-08002be10318}
==Provider=%Mfg%
==DriverVer=04/14/2014,1.0.13.0
==CatalogFile=ew_wwanecm.cat
==
==[Manufacturer]
==%Mfg% = DeviceList,NTx86,NTamd64
==
==[SourceDisksNames]
==1 = %ew_wwanecm.DiskName%,,,""
==
==[SourceDisksFiles]
==ew_wwanecm.sys = 1,,
==
==; For Win2K
==[DeviceList]
==%PNP21_HW_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_16
==%PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_46
==%PNP21_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_76
==
==%PNP21_HW_3G_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_07
==%PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_37
==%PNP21_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_67
==
==%PNP21_HW_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_11
==
==; for logo test
==%HUAWEI_NDISDeviceDesc% = ew_wwanecm.ndi, USB\VID_12D1&PID_158F&MI_00
==
==; For WinXP and later
==[DeviceList.NTx86]
==%PNP21_HW_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_16
==%PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_46
==%PNP21_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_76
==
==%PNP21_HW_3G_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_07
==%PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_37
==%PNP21_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_67
==
==%PNP21_HW_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_11
==
==; for logo test
==%HUAWEI_NDISDeviceDesc% = ew_wwanecm.ndi, USB\VID_12D1&PID_158F&MI_00
==
==; For XP and later x64
==[DeviceList.NTamd64]
==%PNP21_HW_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_16
==%PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_46
==%PNP21_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_76
==
==%PNP21_HW_3G_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_07
==%PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_37
==%PNP21_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_67
==
==%PNP21_HW_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_11
==
==; for logo test
==%HUAWEI_NDISDeviceDesc% = ew_wwanecm.ndi, USB\VID_12D1&PID_158F&MI_00
==
==;-------------------------------------------------------------------------------
==
==; Virtual Ethernet Adapter
==;
==[ew_wwanecm.ndi]
==*IfType = 243 ; IF_TYPE_WWANPP
==*MediaType = 9; NdisMediumWirelessWan
==*PhysicalMediaType = 8 ; NdisPhysicalMediumWirelessWan
==EnableDhcp = 0 ; DHCP Disabled
==Characteristics = 0x84 ; NCF_HAS_UI | NCF_PHYSICAL
==BusType = 15 ; if you specify NCF_PHYSICAL, you must specify
==bustype
==AddReg = ew_wwanecm.Reg, ParamsPromiscuous, ParamsFrameType,
==ParamsIsNtb32, ParamsNTBInputSize, ParamsPacketsAccumulationTimeout,
==ParamsMaxNumOfDatagramsInNTB, FlowControlTimeOut,
==DisableAccumulationUpdate, WwanMbimEnable, NcmReinitializeEnable
==CopyFiles = ew_wwanecm.CopyFiles
==
==
==[WWAN_AddReg]
==HKR,, Platform,0x00010001,0x3
==HKR,, WWAN,0x00010001,0x1
==HKR,, "SelectiveSuspendIdleTime", 0x00010001, 0x05
==[ew_wwanecm.ndi.Services]
==AddService = %ServiceName%, 2, ew_wwanecm.Service, ew_wwanecm.EventLog
==
==[ew_wwanecm.ndi.HW]
==AddReg = WWAN_AddReg
==
==;-----------------------------------------------------------------------------
==
==;
==[ew_wwanecm.Reg]
==HKR, , BusNumber, 0, "0"
==HKR, , MPRadioState, 0x00010001,
==0x00000001 ;RadioState
==HKR, Ndi, Service, 0, "hwusb_wwanecm"
==HKR, Ndi\Interfaces, UpperRange, 0, "flpp4" and
=="flpp6"
==HKR, Ndi\Interfaces, LowerRange, 0, "ppip"
==
==[ParamsPromiscuous]
==;
==; Should the physical NIC be set to Promiscuous mode
==;
==HKR, Ndi\Params\Promiscuous, ParamDesc, , %Promiscuous%
==HKR, Ndi\Params\Promiscuous, Default, ,"0"
==HKR, Ndi\Params\Promiscuous, type, , enum
==HKR, Ndi\Params\Promiscuous\enum,"1", , %Promiscuous_Enable%
==HKR, Ndi\Params\Promiscuous\enum,"0", , %Promiscuous_Disable%
==
==[ParamsFrameType]
==HKR, Ndi\Params\FrameType, ParamDesc, 0, %FrameType%
==HKR, Ndi\Params\FrameType, type, 0, enum
==HKR, Ndi\Params\FrameType, Default, 0, "0"
==HKR, Ndi\Params\FrameType\enum,"1", 0, %FrameType_IP%
==HKR, Ndi\Params\FrameType\enum,"0", 0, %FrameType_Ethernet%
==
==[ParamsIsNtb32]
==HKR, Ndi\Params\IsNtb32, ParamDesc, , %IsNtb32%
==HKR, Ndi\Params\IsNtb32, Default, , "1"
==HKR, Ndi\Params\IsNtb32, type, , enum
==HKR, Ndi\Params\IsNtb32\enum, "1", , "Yes"
==HKR, Ndi\Params\IsNtb32\enum, "0", , "No"
==
==[ParamsNTBInputSize]
==HKR, Ndi\Params\NTBInputSize, ParamDesc, , %NTBInputSize%
==; If the following size is larger than the maximum allowed by the
==device, the
==; maximum value is used. 0 means to use the maximum allowed value of the
==device.
==HKR, Ndi\Params\NTBInputSize, Default, , "0"
==HKR, Ndi\Params\NTBInputSize, type, , dword
==
==[ParamsPacketsAccumulationTimeout]
==HKR, Ndi\Params\PacketsAccumulationTimeout, ParamDesc, ,
==%PacketsAccumulationTimeout%
==; Unit of PacketsAccumulationTimeout is usecs. Default value is 20 us.
==HKR, Ndi\Params\PacketsAccumulationTimeout, Default, , "20"
==HKR, Ndi\Params\PacketsAccumulationTimeout, type, , dword
==
==[ParamsMaxNumOfDatagramsInNTB]
==HKR, Ndi\Params\MaxNumOfDatagramsInNTB, ParamDesc, ,
==%MaxNumOfDatagramsInNTB%
==HKR, Ndi\Params\MaxNumOfDatagramsInNTB, Default, , "64"
==HKR, Ndi\Params\MaxNumOfDatagramsInNTB, type, , dword
==
==[FlowControlTimeOut]
==HKR, Ndi\Params\FlowControlTimeOut, ParamDesc, , %FlowControlTimeout%
==HKR, Ndi\Params\FlowControlTimeOut, Default, , "2800"
==HKR, Ndi\Params\FlowControlTimeOut, type, , dword
==
==[DisableAccumulationUpdate]
==HKR, Ndi\Params\disable_accumulation_update, ParamDesc, ,
==%DisableAccumulationUpdate%
==HKR, Ndi\Params\disable_accumulation_update, Default, , "0"
==HKR, Ndi\Params\disable_accumulation_update, type, , dword
==
==[WwanMbimEnable]
==HKR, Ndi\Params\WwanMbimEnable, ParamDesc, , %WwanMbimEnable%
==HKR, Ndi\Params\WwanMbimEnable, Default, , "0"
==HKR, Ndi\Params\WwanMbimEnable, type, , dword
==
==[NcmReinitializeEnable]
==HKR, Ndi\Params\NcmReinitializeEnable, ParamDesc, , %NcmReinitializeEnable%
==HKR, Ndi\Params\NcmReinitializeEnable, Default, , "1"
==HKR, Ndi\Params\NcmReinitializeEnable, type, , dword
==
==;-----------------------------------------------------------------------------
==
==; DestinationDirs
==;
==[DestinationDirs]
==ew_wwanecm.CopyFiles = 12
==
==[ew_wwanecm.CopyFiles]
==ew_wwanecm.sys,,,0x6 ;COPYFLG_NOSKIP | COPYFLG_NOVERSIONCHECK
==;-----------------------------------------------------------------------------
==
==; Driver and Service Section
==;
==
==[ew_wwanecm.Service]
==ServiceType = 1 ;%SERVICE_KERNEL_DRIVER%
==StartType = 3 ;%SERVICE_DEMAND_START%
==ErrorControl = 1 ;%SERVICE_ERROR_NORMAL%
==ServiceBinary = %12%\ew_wwanecm.sys
==LoadOrderGroup = NDIS
==AddReg = ew_wwanecm.Service.Reg
==
==[ew_wwanecm.Service.Reg]
==HKR, , TextModeFlags, 0x00010001, 0x0001
==HKR, Parameters, DebugLevel, 0x00010001, 1
==HKR, Parameters, WwanLogoTestOn, 0x00010001, 0
==
==[ew_wwanecm.EventLog]
==AddReg = ew_wwanecm.AddEventLog.Reg
==
==[ew_wwanecm.AddEventLog.Reg]
==HKR, , EventMessageFile, 0x00020000, "%%SystemRoot%%\System32\netevent.dll"
==HKR, , TypesSupported, 0x00010001, 7
==
==;-----------------------------------------------------------------------------
==
==; Localizable Strings
==;
==[Strings]
==Mfg = "HUAWEI"
==
==HUAWEI_NDISDeviceDesc = "HUAWEI Mobile Connect - Network Adapter"
==
==;PNP2.1 Device descriptor
==PNP21_HW_3G_NetworkDesc = "HUAWEI Mobile Connect - 3G Network Card"
==PNP21_HW_NetworkDesc = "HUAWEI Mobile Connect - Network Card"
==PNP21_NetworkDesc = "Mobile Connect - Network Card"
==PNP21_VDF_NetworkDesc = "Vodafone Mobile Broadband Network Adapter
==(Huawei)"
==
==ew_wwanecm.DiskName = "DriverCore Installation Disk"
==Promiscuous = "Set the physical NIC to promiscuous mode"
==Promiscuous_Disable = "Disable"
==ServiceName = "hwusb_wwanecm"
==Promiscuous_Enable = "Enable"
==FrameType = "Frame Type in driver-device communications"
==FrameType_Ethernet = "Ethernet"
==FrameType_IP = "IP"
==
==IsNtb32 = "32bit mode"
==NTBInputSize = "NTB input size"
==PacketsAccumulationTimeout = "Packets Accumulation Timeout [usec]"
==MaxNumOfDatagramsInNTB = "Maximum number of datagrams in NTB"
==FlowControlTimeout = "Flow Control timeout interval in ms"
==DisableAccumulationUpdate = "Flag to disable NCM accumulation auto
==updation"
==WwanMbimEnable = "Flag to enable WWAN MBIM function"
==NcmReinitializeEnable = "Flag to enable NCM reinitialize after resume"
==
==Regards,
==Kevin
==
==On 12/02/2014 03:45 PM, Eli Britstein wrote:
==> Outlook blocked the attachment. Please zip it and resend.
==>
==> Thanks,
==> Best regards,
==>
==> Eli Britstein
==> SW Team Leader and Project Manager
==> MP2xx Residential Gateways
==>
==> Tel: +972-3-9764148
==> Mobile: +972-54-2312677
==> Fax: +972-3-9764040
==> Email: Eli.Britstein@audiocodes.com
==> Web: www.audiocodes.com
==>
==>
==>
==> -----Original Message-----
==> From: Kevin Zhu
==> Sent: Tuesday, December 02, 2014 9:44
==> To: Enrico Mioso
==> Cc: Eli Britstein; Bjørn Mork; Alex Strizhevsky; Midge Shaojun Tan; youtux@gmail.com; linux-usb@vger.kernel.org; netdev@vger.kernel.org
==> Subject: Re: Is this 32-bit NCM?
==>
==> Hi all,
==>
==> Here's the registry from windows 7. Attached. One parameter that might be interesting is MaxNumOfDatagramInNTB, which is 64. I wonder if it has something to do with MaxDatagramSize. Can someone also check the registry, in case I missed something?
==>
==> Regards,
==> Kevin
==>
==> On 12/02/2014 02:49 PM, Enrico Mioso wrote:
==>> Can you try to look at Windows registry keys based on the INF file as
==>> suggested or would this be a problem for you?
==>> And... if you have any Huawei manutal talking about it: even device's
==>> ^DSFLOWRPT might be useful to some extent, but ... this is only just a
==>> note in case we don't find anything else.
==>> Regards ... and good day to all of you, Enrico
==>>
==>>
==>> On Tue, 2 Dec 2014, Kevin Zhu wrote:
==>>
==>> ==Date: Tue, 2 Dec 2014 07:43:24
==>> ==From: Kevin Zhu <Mingying.Zhu@audiocodes.com>
==>> ==To: Enrico Mioso <mrkiko.rs@gmail.com>
==>> ==Cc: Eli Britstein <Eli.Britstein@audiocodes.com>, Bjørn Mork <bjorn@mork.no>,
==>> == Alex Strizhevsky <alexxst@gmail.com>,
==>> == Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>,
==>> == "youtux@gmail.com" <youtux@gmail.com>,
==>> == "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
==>> == "netdev@vger.kernel.org" <netdev@vger.kernel.org>
==>> ==Subject: Re: Is this 32-bit NCM?
==>> ==
==>> ==I also tried to define CDC_NCM_DPT_DATAGRAMS_MAX as 1 to eliminate
==>> the ==paddings, but it did not work either, not even DHCP.
==>> ==
==>> ==Regards,
==>> ==Kevin
==>> ==
==>> ==On 12/02/2014 02:32 PM, Enrico Mioso wrote:
==>> ==> Hi again Eli,
==>> ==> Hi Kevin,
==>> ==> Hi everyone...
==>> ==>
==>> ==> As I understand it anyway - the distinction here tends not to be
==>> between ==> different types of packets.
==>> ==> It tends to be between received and sent packet.
==>> ==> We are not able to generate packets that the device retains valid.
==>> ==> If you manually configure the IP the device would have assigned
==>> you via DHCP, ==> your system will start answering ARP request, saying
==>> that the host with IP ==> aa.bb.cc.dd is at aa:bb:cc:dd:ee (using the MC address of the dongle).
==>> ==> However, the other host (gateway) will never know that. Indeed,
==>> it'll continue ==> asking who-is at aa.bb.cc.dd ?
==>> ==> At least, this is the situation I observed in the test system.
==>> ==>
==>> ==>
==>> ==> On Tue, 2 Dec 2014, Kevin Zhu wrote:
==>> ==>
==>> ==> ==Date: Tue, 2 Dec 2014 04:53:53
==>> ==> ==From: Kevin Zhu <Mingying.Zhu@audiocodes.com> ==> ==To: Eli
==>> Britstein <Eli.Britstein@audiocodes.com>,
==>> ==> == Enrico Mioso <mrkiko.rs@gmail.com>
==>> ==> ==Cc: Bjørn Mork <bjorn@mork.no>, Alex Strizhevsky <alexxst@gmail.com>,
==>> ==> == Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>,
==>> ==> == "youtux@gmail.com" <youtux@gmail.com>,
==>> ==> == "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
==>> ==> == "netdev@vger.kernel.org" <netdev@vger.kernel.org>
==>> ==> ==Subject: Re: Is this 32-bit NCM?
==>> ==> ==
==>> ==> ==Hi,
==>> ==> ==
==>> ==> ==The DHCP packets have the maximum size of dwNtbOutMaxSize=16384,
==>> while ==> ==the other packets are less than that. However, the DHCP
==>> queries are not ==> ==replied in time either, there's always some delay.
==>> ==> ==
==>> ==> ==By the way, though the device claims to support
==>> GET_MAX_DATAGRAM_SIZE, ==> ==but it returns error when the host sends
==>> this command to it. I disabled ==> ==this command in NCM driver and tried, but it's the same result.
==>> ==> ==
==>> ==> ==Regards,
==>> ==> ==Kevin
==>> ==> ==
==>> ==> ==On 12/02/2014 06:02 AM, Eli Britstein wrote:
==>> ==> ==> Hi Enrico and all,
==>> ==> ==>
==>> ==> ==> Maybe I missed something but what is the difference by the driver point of view between the dhcp discover and request (that are ok) to others (like arp, that is nok)?
==>> ==> ==> Maybe we can trace to compare them?
==>> ==> ==>
==>> ==> ==> Sent from my iPhone
==>> ==> ==>
==>> ==> ==>> On 1 בדצמ 2014, at 23:11, "Enrico Mioso" <mrkiko.rs@gmail.com> wrote:
==>> ==> ==>>
==>> ==> ==>> So ... I have two ideas left for now.
==>> ==> ==>> We know for sure the problem is in the way we TX frames, not
==>> the way we RX them ==> ==>> (the way we send, generate them, not the way we receive them).
==>> ==> ==>> Si I have two ideas, and I ask for help from the Linux-usb
==>> mailing list for ==> ==>> this first one.
==>> ==> ==>>
==>> ==> ==>> 1 - Does a wayexist to "replay" traffic crom a usb capture?
==>> ==> ==>> We might try to take the usb frames generated by Windows, and
==>> send them to the ==> ==>> device to see if there is any reaction. It
==>> should not be science fiction, I saw ==> ==>> them do that in the eciadsl old project.
==>> ==> ==>> 2 - The huawei ndis driver: does it work with these devices?
==>> ==> ==>> It should be a little bit out-dated now (at least in terms of
==>> dates, it might ==> ==>> work as well): the code is A LOT but, just in
==>> case, to see if there is any ==> ==>> chances it'll work. It remains
==>> to be seen in which kernels it can actually ==> ==>> compile again.
==>> ==> ==>>
==>> ==> ==>> If this works we might analyse what's happening and try to debug this out.
==>> ==> ==>> But I really would like this to work in the cdc_ncm driver + huawei_cdc_ncm.
==>> ==> ==>> Thank you.
==>> ==> ==This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful.
==>> ==> ==
==>> ==> ==If you have received this email in error please immediately
==>> notify the sender and delete or destroy any copy of this message ==>
==>> == ==This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful.
==>> ==
==>> ==If you have received this email in error please immediately notify
==>> the sender and delete or destroy any copy of this message ==
==>
==This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful.
==
==If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message
==
^ permalink raw reply
* Re: Is this 32-bit NCM?
From: Enrico Mioso @ 2014-12-02 10:37 UTC (permalink / raw)
To: Kevin Zhu
Cc: Eli Britstein, Enrico Mioso, Bjørn Mork, Alex Strizhevsky,
Midge Shaojun Tan, youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <547D7243.80508-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 19101 bytes --]
So, we can say that:
1 - They use 32-bit NCM if I am not wrong: so we where in the right direction
Alex!
2 - The driver is "all-in-one": it supports QMI also, not only cdc_ncm.
3 - It #undefs some things from the headers and might be redefine them...
mhm...
On Tue, 2 Dec 2014, Kevin Zhu wrote:
==Date: Tue, 2 Dec 2014 09:03:21
==From: Kevin Zhu <Mingying.Zhu-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>
==To: Eli Britstein <Eli.Britstein-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>,
== Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
==Cc: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>, Alex Strizhevsky <alexxst-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
== Midge Shaojun Tan <ShaojunMidge.Tan-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>,
== "youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org" <youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
== "linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
== "netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
==Subject: Re: Is this 32-bit NCM?
==
==Below is the content of the INF file oem54.inf.
==
==; Copyright (c) 2010,2011 Huawei Incorporated
==; Manufacturer: Huawei Incorporated
==;
==; CDC ECM & NCM driver
==;
==
==[Version]
==Signature="$WINDOWS NT$"
==Class=Net
==ClassGUID={4d36e972-e325-11ce-bfc1-08002be10318}
==Provider=%Mfg%
==DriverVer=04/14/2014,1.0.13.0
==CatalogFile=ew_wwanecm.cat
==
==[Manufacturer]
==%Mfg% = DeviceList,NTx86,NTamd64
==
==[SourceDisksNames]
==1 = %ew_wwanecm.DiskName%,,,""
==
==[SourceDisksFiles]
==ew_wwanecm.sys = 1,,
==
==; For Win2K
==[DeviceList]
==%PNP21_HW_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_16
==%PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_46
==%PNP21_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_76
==
==%PNP21_HW_3G_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_07
==%PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_37
==%PNP21_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_67
==
==%PNP21_HW_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_11
==
==; for logo test
==%HUAWEI_NDISDeviceDesc% = ew_wwanecm.ndi, USB\VID_12D1&PID_158F&MI_00
==
==; For WinXP and later
==[DeviceList.NTx86]
==%PNP21_HW_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_16
==%PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_46
==%PNP21_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_76
==
==%PNP21_HW_3G_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_07
==%PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_37
==%PNP21_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_67
==
==%PNP21_HW_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_11
==
==; for logo test
==%HUAWEI_NDISDeviceDesc% = ew_wwanecm.ndi, USB\VID_12D1&PID_158F&MI_00
==
==; For XP and later x64
==[DeviceList.NTamd64]
==%PNP21_HW_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_16
==%PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_46
==%PNP21_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_76
==
==%PNP21_HW_3G_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_07
==%PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_37
==%PNP21_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_67
==
==%PNP21_HW_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_11
==
==; for logo test
==%HUAWEI_NDISDeviceDesc% = ew_wwanecm.ndi, USB\VID_12D1&PID_158F&MI_00
==
==;-------------------------------------------------------------------------------
==
==; Virtual Ethernet Adapter
==;
==[ew_wwanecm.ndi]
==*IfType = 243 ; IF_TYPE_WWANPP
==*MediaType = 9; NdisMediumWirelessWan
==*PhysicalMediaType = 8 ; NdisPhysicalMediumWirelessWan
==EnableDhcp = 0 ; DHCP Disabled
==Characteristics = 0x84 ; NCF_HAS_UI | NCF_PHYSICAL
==BusType = 15 ; if you specify NCF_PHYSICAL, you must specify
==bustype
==AddReg = ew_wwanecm.Reg, ParamsPromiscuous, ParamsFrameType,
==ParamsIsNtb32, ParamsNTBInputSize, ParamsPacketsAccumulationTimeout,
==ParamsMaxNumOfDatagramsInNTB, FlowControlTimeOut,
==DisableAccumulationUpdate, WwanMbimEnable, NcmReinitializeEnable
==CopyFiles = ew_wwanecm.CopyFiles
==
==
==[WWAN_AddReg]
==HKR,, Platform,0x00010001,0x3
==HKR,, WWAN,0x00010001,0x1
==HKR,, "SelectiveSuspendIdleTime", 0x00010001, 0x05
==[ew_wwanecm.ndi.Services]
==AddService = %ServiceName%, 2, ew_wwanecm.Service, ew_wwanecm.EventLog
==
==[ew_wwanecm.ndi.HW]
==AddReg = WWAN_AddReg
==
==;-----------------------------------------------------------------------------
==
==;
==[ew_wwanecm.Reg]
==HKR, , BusNumber, 0, "0"
==HKR, , MPRadioState, 0x00010001,
==0x00000001 ;RadioState
==HKR, Ndi, Service, 0, "hwusb_wwanecm"
==HKR, Ndi\Interfaces, UpperRange, 0, "flpp4" and
=="flpp6"
==HKR, Ndi\Interfaces, LowerRange, 0, "ppip"
==
==[ParamsPromiscuous]
==;
==; Should the physical NIC be set to Promiscuous mode
==;
==HKR, Ndi\Params\Promiscuous, ParamDesc, , %Promiscuous%
==HKR, Ndi\Params\Promiscuous, Default, ,"0"
==HKR, Ndi\Params\Promiscuous, type, , enum
==HKR, Ndi\Params\Promiscuous\enum,"1", , %Promiscuous_Enable%
==HKR, Ndi\Params\Promiscuous\enum,"0", , %Promiscuous_Disable%
==
==[ParamsFrameType]
==HKR, Ndi\Params\FrameType, ParamDesc, 0, %FrameType%
==HKR, Ndi\Params\FrameType, type, 0, enum
==HKR, Ndi\Params\FrameType, Default, 0, "0"
==HKR, Ndi\Params\FrameType\enum,"1", 0, %FrameType_IP%
==HKR, Ndi\Params\FrameType\enum,"0", 0, %FrameType_Ethernet%
==
==[ParamsIsNtb32]
==HKR, Ndi\Params\IsNtb32, ParamDesc, , %IsNtb32%
==HKR, Ndi\Params\IsNtb32, Default, , "1"
==HKR, Ndi\Params\IsNtb32, type, , enum
==HKR, Ndi\Params\IsNtb32\enum, "1", , "Yes"
==HKR, Ndi\Params\IsNtb32\enum, "0", , "No"
==
==[ParamsNTBInputSize]
==HKR, Ndi\Params\NTBInputSize, ParamDesc, , %NTBInputSize%
==; If the following size is larger than the maximum allowed by the
==device, the
==; maximum value is used. 0 means to use the maximum allowed value of the
==device.
==HKR, Ndi\Params\NTBInputSize, Default, , "0"
==HKR, Ndi\Params\NTBInputSize, type, , dword
==
==[ParamsPacketsAccumulationTimeout]
==HKR, Ndi\Params\PacketsAccumulationTimeout, ParamDesc, ,
==%PacketsAccumulationTimeout%
==; Unit of PacketsAccumulationTimeout is usecs. Default value is 20 us.
==HKR, Ndi\Params\PacketsAccumulationTimeout, Default, , "20"
==HKR, Ndi\Params\PacketsAccumulationTimeout, type, , dword
==
==[ParamsMaxNumOfDatagramsInNTB]
==HKR, Ndi\Params\MaxNumOfDatagramsInNTB, ParamDesc, ,
==%MaxNumOfDatagramsInNTB%
==HKR, Ndi\Params\MaxNumOfDatagramsInNTB, Default, , "64"
==HKR, Ndi\Params\MaxNumOfDatagramsInNTB, type, , dword
==
==[FlowControlTimeOut]
==HKR, Ndi\Params\FlowControlTimeOut, ParamDesc, , %FlowControlTimeout%
==HKR, Ndi\Params\FlowControlTimeOut, Default, , "2800"
==HKR, Ndi\Params\FlowControlTimeOut, type, , dword
==
==[DisableAccumulationUpdate]
==HKR, Ndi\Params\disable_accumulation_update, ParamDesc, ,
==%DisableAccumulationUpdate%
==HKR, Ndi\Params\disable_accumulation_update, Default, , "0"
==HKR, Ndi\Params\disable_accumulation_update, type, , dword
==
==[WwanMbimEnable]
==HKR, Ndi\Params\WwanMbimEnable, ParamDesc, , %WwanMbimEnable%
==HKR, Ndi\Params\WwanMbimEnable, Default, , "0"
==HKR, Ndi\Params\WwanMbimEnable, type, , dword
==
==[NcmReinitializeEnable]
==HKR, Ndi\Params\NcmReinitializeEnable, ParamDesc, , %NcmReinitializeEnable%
==HKR, Ndi\Params\NcmReinitializeEnable, Default, , "1"
==HKR, Ndi\Params\NcmReinitializeEnable, type, , dword
==
==;-----------------------------------------------------------------------------
==
==; DestinationDirs
==;
==[DestinationDirs]
==ew_wwanecm.CopyFiles = 12
==
==[ew_wwanecm.CopyFiles]
==ew_wwanecm.sys,,,0x6 ;COPYFLG_NOSKIP | COPYFLG_NOVERSIONCHECK
==;-----------------------------------------------------------------------------
==
==; Driver and Service Section
==;
==
==[ew_wwanecm.Service]
==ServiceType = 1 ;%SERVICE_KERNEL_DRIVER%
==StartType = 3 ;%SERVICE_DEMAND_START%
==ErrorControl = 1 ;%SERVICE_ERROR_NORMAL%
==ServiceBinary = %12%\ew_wwanecm.sys
==LoadOrderGroup = NDIS
==AddReg = ew_wwanecm.Service.Reg
==
==[ew_wwanecm.Service.Reg]
==HKR, , TextModeFlags, 0x00010001, 0x0001
==HKR, Parameters, DebugLevel, 0x00010001, 1
==HKR, Parameters, WwanLogoTestOn, 0x00010001, 0
==
==[ew_wwanecm.EventLog]
==AddReg = ew_wwanecm.AddEventLog.Reg
==
==[ew_wwanecm.AddEventLog.Reg]
==HKR, , EventMessageFile, 0x00020000, "%%SystemRoot%%\System32\netevent.dll"
==HKR, , TypesSupported, 0x00010001, 7
==
==;-----------------------------------------------------------------------------
==
==; Localizable Strings
==;
==[Strings]
==Mfg = "HUAWEI"
==
==HUAWEI_NDISDeviceDesc = "HUAWEI Mobile Connect - Network Adapter"
==
==;PNP2.1 Device descriptor
==PNP21_HW_3G_NetworkDesc = "HUAWEI Mobile Connect - 3G Network Card"
==PNP21_HW_NetworkDesc = "HUAWEI Mobile Connect - Network Card"
==PNP21_NetworkDesc = "Mobile Connect - Network Card"
==PNP21_VDF_NetworkDesc = "Vodafone Mobile Broadband Network Adapter
==(Huawei)"
==
==ew_wwanecm.DiskName = "DriverCore Installation Disk"
==Promiscuous = "Set the physical NIC to promiscuous mode"
==Promiscuous_Disable = "Disable"
==ServiceName = "hwusb_wwanecm"
==Promiscuous_Enable = "Enable"
==FrameType = "Frame Type in driver-device communications"
==FrameType_Ethernet = "Ethernet"
==FrameType_IP = "IP"
==
==IsNtb32 = "32bit mode"
==NTBInputSize = "NTB input size"
==PacketsAccumulationTimeout = "Packets Accumulation Timeout [usec]"
==MaxNumOfDatagramsInNTB = "Maximum number of datagrams in NTB"
==FlowControlTimeout = "Flow Control timeout interval in ms"
==DisableAccumulationUpdate = "Flag to disable NCM accumulation auto
==updation"
==WwanMbimEnable = "Flag to enable WWAN MBIM function"
==NcmReinitializeEnable = "Flag to enable NCM reinitialize after resume"
==
==Regards,
==Kevin
==
==On 12/02/2014 03:45 PM, Eli Britstein wrote:
==> Outlook blocked the attachment. Please zip it and resend.
==>
==> Thanks,
==> Best regards,
==>
==> Eli Britstein
==> SW Team Leader and Project Manager
==> MP2xx Residential Gateways
==>
==> Tel: +972-3-9764148
==> Mobile: +972-54-2312677
==> Fax: +972-3-9764040
==> Email: Eli.Britstein-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org
==> Web: www.audiocodes.com
==>
==>
==>
==> -----Original Message-----
==> From: Kevin Zhu
==> Sent: Tuesday, December 02, 2014 9:44
==> To: Enrico Mioso
==> Cc: Eli Britstein; Bjørn Mork; Alex Strizhevsky; Midge Shaojun Tan; youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org; linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
==> Subject: Re: Is this 32-bit NCM?
==>
==> Hi all,
==>
==> Here's the registry from windows 7. Attached. One parameter that might be interesting is MaxNumOfDatagramInNTB, which is 64. I wonder if it has something to do with MaxDatagramSize. Can someone also check the registry, in case I missed something?
==>
==> Regards,
==> Kevin
==>
==> On 12/02/2014 02:49 PM, Enrico Mioso wrote:
==>> Can you try to look at Windows registry keys based on the INF file as
==>> suggested or would this be a problem for you?
==>> And... if you have any Huawei manutal talking about it: even device's
==>> ^DSFLOWRPT might be useful to some extent, but ... this is only just a
==>> note in case we don't find anything else.
==>> Regards ... and good day to all of you, Enrico
==>>
==>>
==>> On Tue, 2 Dec 2014, Kevin Zhu wrote:
==>>
==>> ==Date: Tue, 2 Dec 2014 07:43:24
==>> ==From: Kevin Zhu <Mingying.Zhu-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>
==>> ==To: Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
==>> ==Cc: Eli Britstein <Eli.Britstein-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>, Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>,
==>> == Alex Strizhevsky <alexxst-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
==>> == Midge Shaojun Tan <ShaojunMidge.Tan-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>,
==>> == "youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org" <youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
==>> == "linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
==>> == "netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
==>> ==Subject: Re: Is this 32-bit NCM?
==>> ==
==>> ==I also tried to define CDC_NCM_DPT_DATAGRAMS_MAX as 1 to eliminate
==>> the ==paddings, but it did not work either, not even DHCP.
==>> ==
==>> ==Regards,
==>> ==Kevin
==>> ==
==>> ==On 12/02/2014 02:32 PM, Enrico Mioso wrote:
==>> ==> Hi again Eli,
==>> ==> Hi Kevin,
==>> ==> Hi everyone...
==>> ==>
==>> ==> As I understand it anyway - the distinction here tends not to be
==>> between ==> different types of packets.
==>> ==> It tends to be between received and sent packet.
==>> ==> We are not able to generate packets that the device retains valid.
==>> ==> If you manually configure the IP the device would have assigned
==>> you via DHCP, ==> your system will start answering ARP request, saying
==>> that the host with IP ==> aa.bb.cc.dd is at aa:bb:cc:dd:ee (using the MC address of the dongle).
==>> ==> However, the other host (gateway) will never know that. Indeed,
==>> it'll continue ==> asking who-is at aa.bb.cc.dd ?
==>> ==> At least, this is the situation I observed in the test system.
==>> ==>
==>> ==>
==>> ==> On Tue, 2 Dec 2014, Kevin Zhu wrote:
==>> ==>
==>> ==> ==Date: Tue, 2 Dec 2014 04:53:53
==>> ==> ==From: Kevin Zhu <Mingying.Zhu-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org> ==> ==To: Eli
==>> Britstein <Eli.Britstein-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>,
==>> ==> == Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
==>> ==> ==Cc: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>, Alex Strizhevsky <alexxst-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
==>> ==> == Midge Shaojun Tan <ShaojunMidge.Tan-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>,
==>> ==> == "youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org" <youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
==>> ==> == "linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
==>> ==> == "netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
==>> ==> ==Subject: Re: Is this 32-bit NCM?
==>> ==> ==
==>> ==> ==Hi,
==>> ==> ==
==>> ==> ==The DHCP packets have the maximum size of dwNtbOutMaxSize=16384,
==>> while ==> ==the other packets are less than that. However, the DHCP
==>> queries are not ==> ==replied in time either, there's always some delay.
==>> ==> ==
==>> ==> ==By the way, though the device claims to support
==>> GET_MAX_DATAGRAM_SIZE, ==> ==but it returns error when the host sends
==>> this command to it. I disabled ==> ==this command in NCM driver and tried, but it's the same result.
==>> ==> ==
==>> ==> ==Regards,
==>> ==> ==Kevin
==>> ==> ==
==>> ==> ==On 12/02/2014 06:02 AM, Eli Britstein wrote:
==>> ==> ==> Hi Enrico and all,
==>> ==> ==>
==>> ==> ==> Maybe I missed something but what is the difference by the driver point of view between the dhcp discover and request (that are ok) to others (like arp, that is nok)?
==>> ==> ==> Maybe we can trace to compare them?
==>> ==> ==>
==>> ==> ==> Sent from my iPhone
==>> ==> ==>
==>> ==> ==>> On 1 בדצמ 2014, at 23:11, "Enrico Mioso" <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
==>> ==> ==>>
==>> ==> ==>> So ... I have two ideas left for now.
==>> ==> ==>> We know for sure the problem is in the way we TX frames, not
==>> the way we RX them ==> ==>> (the way we send, generate them, not the way we receive them).
==>> ==> ==>> Si I have two ideas, and I ask for help from the Linux-usb
==>> mailing list for ==> ==>> this first one.
==>> ==> ==>>
==>> ==> ==>> 1 - Does a wayexist to "replay" traffic crom a usb capture?
==>> ==> ==>> We might try to take the usb frames generated by Windows, and
==>> send them to the ==> ==>> device to see if there is any reaction. It
==>> should not be science fiction, I saw ==> ==>> them do that in the eciadsl old project.
==>> ==> ==>> 2 - The huawei ndis driver: does it work with these devices?
==>> ==> ==>> It should be a little bit out-dated now (at least in terms of
==>> dates, it might ==> ==>> work as well): the code is A LOT but, just in
==>> case, to see if there is any ==> ==>> chances it'll work. It remains
==>> to be seen in which kernels it can actually ==> ==>> compile again.
==>> ==> ==>>
==>> ==> ==>> If this works we might analyse what's happening and try to debug this out.
==>> ==> ==>> But I really would like this to work in the cdc_ncm driver + huawei_cdc_ncm.
==>> ==> ==>> Thank you.
==>> ==> ==This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful.
==>> ==> ==
==>> ==> ==If you have received this email in error please immediately
==>> notify the sender and delete or destroy any copy of this message ==>
==>> == ==This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful.
==>> ==
==>> ==If you have received this email in error please immediately notify
==>> the sender and delete or destroy any copy of this message ==
==>
==This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful.
==
==If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message
==
^ permalink raw reply
* Re: Is this 32-bit NCM?
From: Enrico Mioso @ 2014-12-02 10:45 UTC (permalink / raw)
To: Kevin Zhu
Cc: Eli Britstein, Bjørn Mork, Alex Strizhevsky,
Midge Shaojun Tan, youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <547D7243.80508-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 19161 bytes --]
Oh - they define even custom structs for NCM_NTH32! :)
Mhm... unfortunately reading all the driver will be needed to find out the
details.
Probably using 16 or 32 bit is ok, but you have the choise now that a cdc_ncm.c
32-bit capable driver exists. But in that case an eventual merge will be
needed, and I might try.
On Tue, 2 Dec 2014, Kevin Zhu wrote:
==Date: Tue, 2 Dec 2014 09:03:21
==From: Kevin Zhu <Mingying.Zhu-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>
==To: Eli Britstein <Eli.Britstein-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>,
== Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
==Cc: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>, Alex Strizhevsky <alexxst-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
== Midge Shaojun Tan <ShaojunMidge.Tan-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>,
== "youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org" <youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
== "linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
== "netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
==Subject: Re: Is this 32-bit NCM?
==
==Below is the content of the INF file oem54.inf.
==
==; Copyright (c) 2010,2011 Huawei Incorporated
==; Manufacturer: Huawei Incorporated
==;
==; CDC ECM & NCM driver
==;
==
==[Version]
==Signature="$WINDOWS NT$"
==Class=Net
==ClassGUID={4d36e972-e325-11ce-bfc1-08002be10318}
==Provider=%Mfg%
==DriverVer=04/14/2014,1.0.13.0
==CatalogFile=ew_wwanecm.cat
==
==[Manufacturer]
==%Mfg% = DeviceList,NTx86,NTamd64
==
==[SourceDisksNames]
==1 = %ew_wwanecm.DiskName%,,,""
==
==[SourceDisksFiles]
==ew_wwanecm.sys = 1,,
==
==; For Win2K
==[DeviceList]
==%PNP21_HW_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_16
==%PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_46
==%PNP21_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_76
==
==%PNP21_HW_3G_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_07
==%PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_37
==%PNP21_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_67
==
==%PNP21_HW_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_11
==
==; for logo test
==%HUAWEI_NDISDeviceDesc% = ew_wwanecm.ndi, USB\VID_12D1&PID_158F&MI_00
==
==; For WinXP and later
==[DeviceList.NTx86]
==%PNP21_HW_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_16
==%PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_46
==%PNP21_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_76
==
==%PNP21_HW_3G_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_07
==%PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_37
==%PNP21_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_67
==
==%PNP21_HW_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_11
==
==; for logo test
==%HUAWEI_NDISDeviceDesc% = ew_wwanecm.ndi, USB\VID_12D1&PID_158F&MI_00
==
==; For XP and later x64
==[DeviceList.NTamd64]
==%PNP21_HW_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_16
==%PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_46
==%PNP21_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_76
==
==%PNP21_HW_3G_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_07
==%PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_37
==%PNP21_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_67
==
==%PNP21_HW_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_11
==
==; for logo test
==%HUAWEI_NDISDeviceDesc% = ew_wwanecm.ndi, USB\VID_12D1&PID_158F&MI_00
==
==;-------------------------------------------------------------------------------
==
==; Virtual Ethernet Adapter
==;
==[ew_wwanecm.ndi]
==*IfType = 243 ; IF_TYPE_WWANPP
==*MediaType = 9; NdisMediumWirelessWan
==*PhysicalMediaType = 8 ; NdisPhysicalMediumWirelessWan
==EnableDhcp = 0 ; DHCP Disabled
==Characteristics = 0x84 ; NCF_HAS_UI | NCF_PHYSICAL
==BusType = 15 ; if you specify NCF_PHYSICAL, you must specify
==bustype
==AddReg = ew_wwanecm.Reg, ParamsPromiscuous, ParamsFrameType,
==ParamsIsNtb32, ParamsNTBInputSize, ParamsPacketsAccumulationTimeout,
==ParamsMaxNumOfDatagramsInNTB, FlowControlTimeOut,
==DisableAccumulationUpdate, WwanMbimEnable, NcmReinitializeEnable
==CopyFiles = ew_wwanecm.CopyFiles
==
==
==[WWAN_AddReg]
==HKR,, Platform,0x00010001,0x3
==HKR,, WWAN,0x00010001,0x1
==HKR,, "SelectiveSuspendIdleTime", 0x00010001, 0x05
==[ew_wwanecm.ndi.Services]
==AddService = %ServiceName%, 2, ew_wwanecm.Service, ew_wwanecm.EventLog
==
==[ew_wwanecm.ndi.HW]
==AddReg = WWAN_AddReg
==
==;-----------------------------------------------------------------------------
==
==;
==[ew_wwanecm.Reg]
==HKR, , BusNumber, 0, "0"
==HKR, , MPRadioState, 0x00010001,
==0x00000001 ;RadioState
==HKR, Ndi, Service, 0, "hwusb_wwanecm"
==HKR, Ndi\Interfaces, UpperRange, 0, "flpp4" and
=="flpp6"
==HKR, Ndi\Interfaces, LowerRange, 0, "ppip"
==
==[ParamsPromiscuous]
==;
==; Should the physical NIC be set to Promiscuous mode
==;
==HKR, Ndi\Params\Promiscuous, ParamDesc, , %Promiscuous%
==HKR, Ndi\Params\Promiscuous, Default, ,"0"
==HKR, Ndi\Params\Promiscuous, type, , enum
==HKR, Ndi\Params\Promiscuous\enum,"1", , %Promiscuous_Enable%
==HKR, Ndi\Params\Promiscuous\enum,"0", , %Promiscuous_Disable%
==
==[ParamsFrameType]
==HKR, Ndi\Params\FrameType, ParamDesc, 0, %FrameType%
==HKR, Ndi\Params\FrameType, type, 0, enum
==HKR, Ndi\Params\FrameType, Default, 0, "0"
==HKR, Ndi\Params\FrameType\enum,"1", 0, %FrameType_IP%
==HKR, Ndi\Params\FrameType\enum,"0", 0, %FrameType_Ethernet%
==
==[ParamsIsNtb32]
==HKR, Ndi\Params\IsNtb32, ParamDesc, , %IsNtb32%
==HKR, Ndi\Params\IsNtb32, Default, , "1"
==HKR, Ndi\Params\IsNtb32, type, , enum
==HKR, Ndi\Params\IsNtb32\enum, "1", , "Yes"
==HKR, Ndi\Params\IsNtb32\enum, "0", , "No"
==
==[ParamsNTBInputSize]
==HKR, Ndi\Params\NTBInputSize, ParamDesc, , %NTBInputSize%
==; If the following size is larger than the maximum allowed by the
==device, the
==; maximum value is used. 0 means to use the maximum allowed value of the
==device.
==HKR, Ndi\Params\NTBInputSize, Default, , "0"
==HKR, Ndi\Params\NTBInputSize, type, , dword
==
==[ParamsPacketsAccumulationTimeout]
==HKR, Ndi\Params\PacketsAccumulationTimeout, ParamDesc, ,
==%PacketsAccumulationTimeout%
==; Unit of PacketsAccumulationTimeout is usecs. Default value is 20 us.
==HKR, Ndi\Params\PacketsAccumulationTimeout, Default, , "20"
==HKR, Ndi\Params\PacketsAccumulationTimeout, type, , dword
==
==[ParamsMaxNumOfDatagramsInNTB]
==HKR, Ndi\Params\MaxNumOfDatagramsInNTB, ParamDesc, ,
==%MaxNumOfDatagramsInNTB%
==HKR, Ndi\Params\MaxNumOfDatagramsInNTB, Default, , "64"
==HKR, Ndi\Params\MaxNumOfDatagramsInNTB, type, , dword
==
==[FlowControlTimeOut]
==HKR, Ndi\Params\FlowControlTimeOut, ParamDesc, , %FlowControlTimeout%
==HKR, Ndi\Params\FlowControlTimeOut, Default, , "2800"
==HKR, Ndi\Params\FlowControlTimeOut, type, , dword
==
==[DisableAccumulationUpdate]
==HKR, Ndi\Params\disable_accumulation_update, ParamDesc, ,
==%DisableAccumulationUpdate%
==HKR, Ndi\Params\disable_accumulation_update, Default, , "0"
==HKR, Ndi\Params\disable_accumulation_update, type, , dword
==
==[WwanMbimEnable]
==HKR, Ndi\Params\WwanMbimEnable, ParamDesc, , %WwanMbimEnable%
==HKR, Ndi\Params\WwanMbimEnable, Default, , "0"
==HKR, Ndi\Params\WwanMbimEnable, type, , dword
==
==[NcmReinitializeEnable]
==HKR, Ndi\Params\NcmReinitializeEnable, ParamDesc, , %NcmReinitializeEnable%
==HKR, Ndi\Params\NcmReinitializeEnable, Default, , "1"
==HKR, Ndi\Params\NcmReinitializeEnable, type, , dword
==
==;-----------------------------------------------------------------------------
==
==; DestinationDirs
==;
==[DestinationDirs]
==ew_wwanecm.CopyFiles = 12
==
==[ew_wwanecm.CopyFiles]
==ew_wwanecm.sys,,,0x6 ;COPYFLG_NOSKIP | COPYFLG_NOVERSIONCHECK
==;-----------------------------------------------------------------------------
==
==; Driver and Service Section
==;
==
==[ew_wwanecm.Service]
==ServiceType = 1 ;%SERVICE_KERNEL_DRIVER%
==StartType = 3 ;%SERVICE_DEMAND_START%
==ErrorControl = 1 ;%SERVICE_ERROR_NORMAL%
==ServiceBinary = %12%\ew_wwanecm.sys
==LoadOrderGroup = NDIS
==AddReg = ew_wwanecm.Service.Reg
==
==[ew_wwanecm.Service.Reg]
==HKR, , TextModeFlags, 0x00010001, 0x0001
==HKR, Parameters, DebugLevel, 0x00010001, 1
==HKR, Parameters, WwanLogoTestOn, 0x00010001, 0
==
==[ew_wwanecm.EventLog]
==AddReg = ew_wwanecm.AddEventLog.Reg
==
==[ew_wwanecm.AddEventLog.Reg]
==HKR, , EventMessageFile, 0x00020000, "%%SystemRoot%%\System32\netevent.dll"
==HKR, , TypesSupported, 0x00010001, 7
==
==;-----------------------------------------------------------------------------
==
==; Localizable Strings
==;
==[Strings]
==Mfg = "HUAWEI"
==
==HUAWEI_NDISDeviceDesc = "HUAWEI Mobile Connect - Network Adapter"
==
==;PNP2.1 Device descriptor
==PNP21_HW_3G_NetworkDesc = "HUAWEI Mobile Connect - 3G Network Card"
==PNP21_HW_NetworkDesc = "HUAWEI Mobile Connect - Network Card"
==PNP21_NetworkDesc = "Mobile Connect - Network Card"
==PNP21_VDF_NetworkDesc = "Vodafone Mobile Broadband Network Adapter
==(Huawei)"
==
==ew_wwanecm.DiskName = "DriverCore Installation Disk"
==Promiscuous = "Set the physical NIC to promiscuous mode"
==Promiscuous_Disable = "Disable"
==ServiceName = "hwusb_wwanecm"
==Promiscuous_Enable = "Enable"
==FrameType = "Frame Type in driver-device communications"
==FrameType_Ethernet = "Ethernet"
==FrameType_IP = "IP"
==
==IsNtb32 = "32bit mode"
==NTBInputSize = "NTB input size"
==PacketsAccumulationTimeout = "Packets Accumulation Timeout [usec]"
==MaxNumOfDatagramsInNTB = "Maximum number of datagrams in NTB"
==FlowControlTimeout = "Flow Control timeout interval in ms"
==DisableAccumulationUpdate = "Flag to disable NCM accumulation auto
==updation"
==WwanMbimEnable = "Flag to enable WWAN MBIM function"
==NcmReinitializeEnable = "Flag to enable NCM reinitialize after resume"
==
==Regards,
==Kevin
==
==On 12/02/2014 03:45 PM, Eli Britstein wrote:
==> Outlook blocked the attachment. Please zip it and resend.
==>
==> Thanks,
==> Best regards,
==>
==> Eli Britstein
==> SW Team Leader and Project Manager
==> MP2xx Residential Gateways
==>
==> Tel: +972-3-9764148
==> Mobile: +972-54-2312677
==> Fax: +972-3-9764040
==> Email: Eli.Britstein-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org
==> Web: www.audiocodes.com
==>
==>
==>
==> -----Original Message-----
==> From: Kevin Zhu
==> Sent: Tuesday, December 02, 2014 9:44
==> To: Enrico Mioso
==> Cc: Eli Britstein; Bjørn Mork; Alex Strizhevsky; Midge Shaojun Tan; youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org; linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
==> Subject: Re: Is this 32-bit NCM?
==>
==> Hi all,
==>
==> Here's the registry from windows 7. Attached. One parameter that might be interesting is MaxNumOfDatagramInNTB, which is 64. I wonder if it has something to do with MaxDatagramSize. Can someone also check the registry, in case I missed something?
==>
==> Regards,
==> Kevin
==>
==> On 12/02/2014 02:49 PM, Enrico Mioso wrote:
==>> Can you try to look at Windows registry keys based on the INF file as
==>> suggested or would this be a problem for you?
==>> And... if you have any Huawei manutal talking about it: even device's
==>> ^DSFLOWRPT might be useful to some extent, but ... this is only just a
==>> note in case we don't find anything else.
==>> Regards ... and good day to all of you, Enrico
==>>
==>>
==>> On Tue, 2 Dec 2014, Kevin Zhu wrote:
==>>
==>> ==Date: Tue, 2 Dec 2014 07:43:24
==>> ==From: Kevin Zhu <Mingying.Zhu-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>
==>> ==To: Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
==>> ==Cc: Eli Britstein <Eli.Britstein-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>, Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>,
==>> == Alex Strizhevsky <alexxst-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
==>> == Midge Shaojun Tan <ShaojunMidge.Tan-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>,
==>> == "youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org" <youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
==>> == "linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
==>> == "netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
==>> ==Subject: Re: Is this 32-bit NCM?
==>> ==
==>> ==I also tried to define CDC_NCM_DPT_DATAGRAMS_MAX as 1 to eliminate
==>> the ==paddings, but it did not work either, not even DHCP.
==>> ==
==>> ==Regards,
==>> ==Kevin
==>> ==
==>> ==On 12/02/2014 02:32 PM, Enrico Mioso wrote:
==>> ==> Hi again Eli,
==>> ==> Hi Kevin,
==>> ==> Hi everyone...
==>> ==>
==>> ==> As I understand it anyway - the distinction here tends not to be
==>> between ==> different types of packets.
==>> ==> It tends to be between received and sent packet.
==>> ==> We are not able to generate packets that the device retains valid.
==>> ==> If you manually configure the IP the device would have assigned
==>> you via DHCP, ==> your system will start answering ARP request, saying
==>> that the host with IP ==> aa.bb.cc.dd is at aa:bb:cc:dd:ee (using the MC address of the dongle).
==>> ==> However, the other host (gateway) will never know that. Indeed,
==>> it'll continue ==> asking who-is at aa.bb.cc.dd ?
==>> ==> At least, this is the situation I observed in the test system.
==>> ==>
==>> ==>
==>> ==> On Tue, 2 Dec 2014, Kevin Zhu wrote:
==>> ==>
==>> ==> ==Date: Tue, 2 Dec 2014 04:53:53
==>> ==> ==From: Kevin Zhu <Mingying.Zhu-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org> ==> ==To: Eli
==>> Britstein <Eli.Britstein-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>,
==>> ==> == Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
==>> ==> ==Cc: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>, Alex Strizhevsky <alexxst-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
==>> ==> == Midge Shaojun Tan <ShaojunMidge.Tan-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>,
==>> ==> == "youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org" <youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
==>> ==> == "linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
==>> ==> == "netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
==>> ==> ==Subject: Re: Is this 32-bit NCM?
==>> ==> ==
==>> ==> ==Hi,
==>> ==> ==
==>> ==> ==The DHCP packets have the maximum size of dwNtbOutMaxSize=16384,
==>> while ==> ==the other packets are less than that. However, the DHCP
==>> queries are not ==> ==replied in time either, there's always some delay.
==>> ==> ==
==>> ==> ==By the way, though the device claims to support
==>> GET_MAX_DATAGRAM_SIZE, ==> ==but it returns error when the host sends
==>> this command to it. I disabled ==> ==this command in NCM driver and tried, but it's the same result.
==>> ==> ==
==>> ==> ==Regards,
==>> ==> ==Kevin
==>> ==> ==
==>> ==> ==On 12/02/2014 06:02 AM, Eli Britstein wrote:
==>> ==> ==> Hi Enrico and all,
==>> ==> ==>
==>> ==> ==> Maybe I missed something but what is the difference by the driver point of view between the dhcp discover and request (that are ok) to others (like arp, that is nok)?
==>> ==> ==> Maybe we can trace to compare them?
==>> ==> ==>
==>> ==> ==> Sent from my iPhone
==>> ==> ==>
==>> ==> ==>> On 1 בדצמ 2014, at 23:11, "Enrico Mioso" <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
==>> ==> ==>>
==>> ==> ==>> So ... I have two ideas left for now.
==>> ==> ==>> We know for sure the problem is in the way we TX frames, not
==>> the way we RX them ==> ==>> (the way we send, generate them, not the way we receive them).
==>> ==> ==>> Si I have two ideas, and I ask for help from the Linux-usb
==>> mailing list for ==> ==>> this first one.
==>> ==> ==>>
==>> ==> ==>> 1 - Does a wayexist to "replay" traffic crom a usb capture?
==>> ==> ==>> We might try to take the usb frames generated by Windows, and
==>> send them to the ==> ==>> device to see if there is any reaction. It
==>> should not be science fiction, I saw ==> ==>> them do that in the eciadsl old project.
==>> ==> ==>> 2 - The huawei ndis driver: does it work with these devices?
==>> ==> ==>> It should be a little bit out-dated now (at least in terms of
==>> dates, it might ==> ==>> work as well): the code is A LOT but, just in
==>> case, to see if there is any ==> ==>> chances it'll work. It remains
==>> to be seen in which kernels it can actually ==> ==>> compile again.
==>> ==> ==>>
==>> ==> ==>> If this works we might analyse what's happening and try to debug this out.
==>> ==> ==>> But I really would like this to work in the cdc_ncm driver + huawei_cdc_ncm.
==>> ==> ==>> Thank you.
==>> ==> ==This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful.
==>> ==> ==
==>> ==> ==If you have received this email in error please immediately
==>> notify the sender and delete or destroy any copy of this message ==>
==>> == ==This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful.
==>> ==
==>> ==If you have received this email in error please immediately notify
==>> the sender and delete or destroy any copy of this message ==
==>
==This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful.
==
==If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message
==
^ permalink raw reply
* Re: Is this 32-bit NCM?
From: Enrico Mioso @ 2014-12-02 10:48 UTC (permalink / raw)
To: Kevin Zhu
Cc: Eli Britstein, Bjørn Mork, Alex Strizhevsky,
Midge Shaojun Tan, youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <547D7243.80508-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 18949 bytes --]
Errata corrige - they might re-define those structurtes to be able to re-use
the same parsing code.
Sorry.
On Tue, 2 Dec 2014, Kevin Zhu wrote:
==Date: Tue, 2 Dec 2014 09:03:21
==From: Kevin Zhu <Mingying.Zhu-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>
==To: Eli Britstein <Eli.Britstein-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>,
== Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
==Cc: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>, Alex Strizhevsky <alexxst-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
== Midge Shaojun Tan <ShaojunMidge.Tan-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>,
== "youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org" <youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
== "linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
== "netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
==Subject: Re: Is this 32-bit NCM?
==
==Below is the content of the INF file oem54.inf.
==
==; Copyright (c) 2010,2011 Huawei Incorporated
==; Manufacturer: Huawei Incorporated
==;
==; CDC ECM & NCM driver
==;
==
==[Version]
==Signature="$WINDOWS NT$"
==Class=Net
==ClassGUID={4d36e972-e325-11ce-bfc1-08002be10318}
==Provider=%Mfg%
==DriverVer=04/14/2014,1.0.13.0
==CatalogFile=ew_wwanecm.cat
==
==[Manufacturer]
==%Mfg% = DeviceList,NTx86,NTamd64
==
==[SourceDisksNames]
==1 = %ew_wwanecm.DiskName%,,,""
==
==[SourceDisksFiles]
==ew_wwanecm.sys = 1,,
==
==; For Win2K
==[DeviceList]
==%PNP21_HW_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_16
==%PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_46
==%PNP21_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_76
==
==%PNP21_HW_3G_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_07
==%PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_37
==%PNP21_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_67
==
==%PNP21_HW_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_11
==
==; for logo test
==%HUAWEI_NDISDeviceDesc% = ew_wwanecm.ndi, USB\VID_12D1&PID_158F&MI_00
==
==; For WinXP and later
==[DeviceList.NTx86]
==%PNP21_HW_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_16
==%PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_46
==%PNP21_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_76
==
==%PNP21_HW_3G_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_07
==%PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_37
==%PNP21_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_67
==
==%PNP21_HW_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_11
==
==; for logo test
==%HUAWEI_NDISDeviceDesc% = ew_wwanecm.ndi, USB\VID_12D1&PID_158F&MI_00
==
==; For XP and later x64
==[DeviceList.NTamd64]
==%PNP21_HW_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_16
==%PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_46
==%PNP21_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_76
==
==%PNP21_HW_3G_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_07
==%PNP21_VDF_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_37
==%PNP21_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_67
==
==%PNP21_HW_NetworkDesc% = ew_wwanecm.ndi,
==USB\VID_12D1&Subclass_03&Prot_11
==
==; for logo test
==%HUAWEI_NDISDeviceDesc% = ew_wwanecm.ndi, USB\VID_12D1&PID_158F&MI_00
==
==;-------------------------------------------------------------------------------
==
==; Virtual Ethernet Adapter
==;
==[ew_wwanecm.ndi]
==*IfType = 243 ; IF_TYPE_WWANPP
==*MediaType = 9; NdisMediumWirelessWan
==*PhysicalMediaType = 8 ; NdisPhysicalMediumWirelessWan
==EnableDhcp = 0 ; DHCP Disabled
==Characteristics = 0x84 ; NCF_HAS_UI | NCF_PHYSICAL
==BusType = 15 ; if you specify NCF_PHYSICAL, you must specify
==bustype
==AddReg = ew_wwanecm.Reg, ParamsPromiscuous, ParamsFrameType,
==ParamsIsNtb32, ParamsNTBInputSize, ParamsPacketsAccumulationTimeout,
==ParamsMaxNumOfDatagramsInNTB, FlowControlTimeOut,
==DisableAccumulationUpdate, WwanMbimEnable, NcmReinitializeEnable
==CopyFiles = ew_wwanecm.CopyFiles
==
==
==[WWAN_AddReg]
==HKR,, Platform,0x00010001,0x3
==HKR,, WWAN,0x00010001,0x1
==HKR,, "SelectiveSuspendIdleTime", 0x00010001, 0x05
==[ew_wwanecm.ndi.Services]
==AddService = %ServiceName%, 2, ew_wwanecm.Service, ew_wwanecm.EventLog
==
==[ew_wwanecm.ndi.HW]
==AddReg = WWAN_AddReg
==
==;-----------------------------------------------------------------------------
==
==;
==[ew_wwanecm.Reg]
==HKR, , BusNumber, 0, "0"
==HKR, , MPRadioState, 0x00010001,
==0x00000001 ;RadioState
==HKR, Ndi, Service, 0, "hwusb_wwanecm"
==HKR, Ndi\Interfaces, UpperRange, 0, "flpp4" and
=="flpp6"
==HKR, Ndi\Interfaces, LowerRange, 0, "ppip"
==
==[ParamsPromiscuous]
==;
==; Should the physical NIC be set to Promiscuous mode
==;
==HKR, Ndi\Params\Promiscuous, ParamDesc, , %Promiscuous%
==HKR, Ndi\Params\Promiscuous, Default, ,"0"
==HKR, Ndi\Params\Promiscuous, type, , enum
==HKR, Ndi\Params\Promiscuous\enum,"1", , %Promiscuous_Enable%
==HKR, Ndi\Params\Promiscuous\enum,"0", , %Promiscuous_Disable%
==
==[ParamsFrameType]
==HKR, Ndi\Params\FrameType, ParamDesc, 0, %FrameType%
==HKR, Ndi\Params\FrameType, type, 0, enum
==HKR, Ndi\Params\FrameType, Default, 0, "0"
==HKR, Ndi\Params\FrameType\enum,"1", 0, %FrameType_IP%
==HKR, Ndi\Params\FrameType\enum,"0", 0, %FrameType_Ethernet%
==
==[ParamsIsNtb32]
==HKR, Ndi\Params\IsNtb32, ParamDesc, , %IsNtb32%
==HKR, Ndi\Params\IsNtb32, Default, , "1"
==HKR, Ndi\Params\IsNtb32, type, , enum
==HKR, Ndi\Params\IsNtb32\enum, "1", , "Yes"
==HKR, Ndi\Params\IsNtb32\enum, "0", , "No"
==
==[ParamsNTBInputSize]
==HKR, Ndi\Params\NTBInputSize, ParamDesc, , %NTBInputSize%
==; If the following size is larger than the maximum allowed by the
==device, the
==; maximum value is used. 0 means to use the maximum allowed value of the
==device.
==HKR, Ndi\Params\NTBInputSize, Default, , "0"
==HKR, Ndi\Params\NTBInputSize, type, , dword
==
==[ParamsPacketsAccumulationTimeout]
==HKR, Ndi\Params\PacketsAccumulationTimeout, ParamDesc, ,
==%PacketsAccumulationTimeout%
==; Unit of PacketsAccumulationTimeout is usecs. Default value is 20 us.
==HKR, Ndi\Params\PacketsAccumulationTimeout, Default, , "20"
==HKR, Ndi\Params\PacketsAccumulationTimeout, type, , dword
==
==[ParamsMaxNumOfDatagramsInNTB]
==HKR, Ndi\Params\MaxNumOfDatagramsInNTB, ParamDesc, ,
==%MaxNumOfDatagramsInNTB%
==HKR, Ndi\Params\MaxNumOfDatagramsInNTB, Default, , "64"
==HKR, Ndi\Params\MaxNumOfDatagramsInNTB, type, , dword
==
==[FlowControlTimeOut]
==HKR, Ndi\Params\FlowControlTimeOut, ParamDesc, , %FlowControlTimeout%
==HKR, Ndi\Params\FlowControlTimeOut, Default, , "2800"
==HKR, Ndi\Params\FlowControlTimeOut, type, , dword
==
==[DisableAccumulationUpdate]
==HKR, Ndi\Params\disable_accumulation_update, ParamDesc, ,
==%DisableAccumulationUpdate%
==HKR, Ndi\Params\disable_accumulation_update, Default, , "0"
==HKR, Ndi\Params\disable_accumulation_update, type, , dword
==
==[WwanMbimEnable]
==HKR, Ndi\Params\WwanMbimEnable, ParamDesc, , %WwanMbimEnable%
==HKR, Ndi\Params\WwanMbimEnable, Default, , "0"
==HKR, Ndi\Params\WwanMbimEnable, type, , dword
==
==[NcmReinitializeEnable]
==HKR, Ndi\Params\NcmReinitializeEnable, ParamDesc, , %NcmReinitializeEnable%
==HKR, Ndi\Params\NcmReinitializeEnable, Default, , "1"
==HKR, Ndi\Params\NcmReinitializeEnable, type, , dword
==
==;-----------------------------------------------------------------------------
==
==; DestinationDirs
==;
==[DestinationDirs]
==ew_wwanecm.CopyFiles = 12
==
==[ew_wwanecm.CopyFiles]
==ew_wwanecm.sys,,,0x6 ;COPYFLG_NOSKIP | COPYFLG_NOVERSIONCHECK
==;-----------------------------------------------------------------------------
==
==; Driver and Service Section
==;
==
==[ew_wwanecm.Service]
==ServiceType = 1 ;%SERVICE_KERNEL_DRIVER%
==StartType = 3 ;%SERVICE_DEMAND_START%
==ErrorControl = 1 ;%SERVICE_ERROR_NORMAL%
==ServiceBinary = %12%\ew_wwanecm.sys
==LoadOrderGroup = NDIS
==AddReg = ew_wwanecm.Service.Reg
==
==[ew_wwanecm.Service.Reg]
==HKR, , TextModeFlags, 0x00010001, 0x0001
==HKR, Parameters, DebugLevel, 0x00010001, 1
==HKR, Parameters, WwanLogoTestOn, 0x00010001, 0
==
==[ew_wwanecm.EventLog]
==AddReg = ew_wwanecm.AddEventLog.Reg
==
==[ew_wwanecm.AddEventLog.Reg]
==HKR, , EventMessageFile, 0x00020000, "%%SystemRoot%%\System32\netevent.dll"
==HKR, , TypesSupported, 0x00010001, 7
==
==;-----------------------------------------------------------------------------
==
==; Localizable Strings
==;
==[Strings]
==Mfg = "HUAWEI"
==
==HUAWEI_NDISDeviceDesc = "HUAWEI Mobile Connect - Network Adapter"
==
==;PNP2.1 Device descriptor
==PNP21_HW_3G_NetworkDesc = "HUAWEI Mobile Connect - 3G Network Card"
==PNP21_HW_NetworkDesc = "HUAWEI Mobile Connect - Network Card"
==PNP21_NetworkDesc = "Mobile Connect - Network Card"
==PNP21_VDF_NetworkDesc = "Vodafone Mobile Broadband Network Adapter
==(Huawei)"
==
==ew_wwanecm.DiskName = "DriverCore Installation Disk"
==Promiscuous = "Set the physical NIC to promiscuous mode"
==Promiscuous_Disable = "Disable"
==ServiceName = "hwusb_wwanecm"
==Promiscuous_Enable = "Enable"
==FrameType = "Frame Type in driver-device communications"
==FrameType_Ethernet = "Ethernet"
==FrameType_IP = "IP"
==
==IsNtb32 = "32bit mode"
==NTBInputSize = "NTB input size"
==PacketsAccumulationTimeout = "Packets Accumulation Timeout [usec]"
==MaxNumOfDatagramsInNTB = "Maximum number of datagrams in NTB"
==FlowControlTimeout = "Flow Control timeout interval in ms"
==DisableAccumulationUpdate = "Flag to disable NCM accumulation auto
==updation"
==WwanMbimEnable = "Flag to enable WWAN MBIM function"
==NcmReinitializeEnable = "Flag to enable NCM reinitialize after resume"
==
==Regards,
==Kevin
==
==On 12/02/2014 03:45 PM, Eli Britstein wrote:
==> Outlook blocked the attachment. Please zip it and resend.
==>
==> Thanks,
==> Best regards,
==>
==> Eli Britstein
==> SW Team Leader and Project Manager
==> MP2xx Residential Gateways
==>
==> Tel: +972-3-9764148
==> Mobile: +972-54-2312677
==> Fax: +972-3-9764040
==> Email: Eli.Britstein-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org
==> Web: www.audiocodes.com
==>
==>
==>
==> -----Original Message-----
==> From: Kevin Zhu
==> Sent: Tuesday, December 02, 2014 9:44
==> To: Enrico Mioso
==> Cc: Eli Britstein; Bjørn Mork; Alex Strizhevsky; Midge Shaojun Tan; youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org; linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
==> Subject: Re: Is this 32-bit NCM?
==>
==> Hi all,
==>
==> Here's the registry from windows 7. Attached. One parameter that might be interesting is MaxNumOfDatagramInNTB, which is 64. I wonder if it has something to do with MaxDatagramSize. Can someone also check the registry, in case I missed something?
==>
==> Regards,
==> Kevin
==>
==> On 12/02/2014 02:49 PM, Enrico Mioso wrote:
==>> Can you try to look at Windows registry keys based on the INF file as
==>> suggested or would this be a problem for you?
==>> And... if you have any Huawei manutal talking about it: even device's
==>> ^DSFLOWRPT might be useful to some extent, but ... this is only just a
==>> note in case we don't find anything else.
==>> Regards ... and good day to all of you, Enrico
==>>
==>>
==>> On Tue, 2 Dec 2014, Kevin Zhu wrote:
==>>
==>> ==Date: Tue, 2 Dec 2014 07:43:24
==>> ==From: Kevin Zhu <Mingying.Zhu-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>
==>> ==To: Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
==>> ==Cc: Eli Britstein <Eli.Britstein-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>, Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>,
==>> == Alex Strizhevsky <alexxst-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
==>> == Midge Shaojun Tan <ShaojunMidge.Tan-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>,
==>> == "youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org" <youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
==>> == "linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
==>> == "netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
==>> ==Subject: Re: Is this 32-bit NCM?
==>> ==
==>> ==I also tried to define CDC_NCM_DPT_DATAGRAMS_MAX as 1 to eliminate
==>> the ==paddings, but it did not work either, not even DHCP.
==>> ==
==>> ==Regards,
==>> ==Kevin
==>> ==
==>> ==On 12/02/2014 02:32 PM, Enrico Mioso wrote:
==>> ==> Hi again Eli,
==>> ==> Hi Kevin,
==>> ==> Hi everyone...
==>> ==>
==>> ==> As I understand it anyway - the distinction here tends not to be
==>> between ==> different types of packets.
==>> ==> It tends to be between received and sent packet.
==>> ==> We are not able to generate packets that the device retains valid.
==>> ==> If you manually configure the IP the device would have assigned
==>> you via DHCP, ==> your system will start answering ARP request, saying
==>> that the host with IP ==> aa.bb.cc.dd is at aa:bb:cc:dd:ee (using the MC address of the dongle).
==>> ==> However, the other host (gateway) will never know that. Indeed,
==>> it'll continue ==> asking who-is at aa.bb.cc.dd ?
==>> ==> At least, this is the situation I observed in the test system.
==>> ==>
==>> ==>
==>> ==> On Tue, 2 Dec 2014, Kevin Zhu wrote:
==>> ==>
==>> ==> ==Date: Tue, 2 Dec 2014 04:53:53
==>> ==> ==From: Kevin Zhu <Mingying.Zhu-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org> ==> ==To: Eli
==>> Britstein <Eli.Britstein-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>,
==>> ==> == Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
==>> ==> ==Cc: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>, Alex Strizhevsky <alexxst-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
==>> ==> == Midge Shaojun Tan <ShaojunMidge.Tan-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>,
==>> ==> == "youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org" <youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
==>> ==> == "linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
==>> ==> == "netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
==>> ==> ==Subject: Re: Is this 32-bit NCM?
==>> ==> ==
==>> ==> ==Hi,
==>> ==> ==
==>> ==> ==The DHCP packets have the maximum size of dwNtbOutMaxSize=16384,
==>> while ==> ==the other packets are less than that. However, the DHCP
==>> queries are not ==> ==replied in time either, there's always some delay.
==>> ==> ==
==>> ==> ==By the way, though the device claims to support
==>> GET_MAX_DATAGRAM_SIZE, ==> ==but it returns error when the host sends
==>> this command to it. I disabled ==> ==this command in NCM driver and tried, but it's the same result.
==>> ==> ==
==>> ==> ==Regards,
==>> ==> ==Kevin
==>> ==> ==
==>> ==> ==On 12/02/2014 06:02 AM, Eli Britstein wrote:
==>> ==> ==> Hi Enrico and all,
==>> ==> ==>
==>> ==> ==> Maybe I missed something but what is the difference by the driver point of view between the dhcp discover and request (that are ok) to others (like arp, that is nok)?
==>> ==> ==> Maybe we can trace to compare them?
==>> ==> ==>
==>> ==> ==> Sent from my iPhone
==>> ==> ==>
==>> ==> ==>> On 1 בדצמ 2014, at 23:11, "Enrico Mioso" <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
==>> ==> ==>>
==>> ==> ==>> So ... I have two ideas left for now.
==>> ==> ==>> We know for sure the problem is in the way we TX frames, not
==>> the way we RX them ==> ==>> (the way we send, generate them, not the way we receive them).
==>> ==> ==>> Si I have two ideas, and I ask for help from the Linux-usb
==>> mailing list for ==> ==>> this first one.
==>> ==> ==>>
==>> ==> ==>> 1 - Does a wayexist to "replay" traffic crom a usb capture?
==>> ==> ==>> We might try to take the usb frames generated by Windows, and
==>> send them to the ==> ==>> device to see if there is any reaction. It
==>> should not be science fiction, I saw ==> ==>> them do that in the eciadsl old project.
==>> ==> ==>> 2 - The huawei ndis driver: does it work with these devices?
==>> ==> ==>> It should be a little bit out-dated now (at least in terms of
==>> dates, it might ==> ==>> work as well): the code is A LOT but, just in
==>> case, to see if there is any ==> ==>> chances it'll work. It remains
==>> to be seen in which kernels it can actually ==> ==>> compile again.
==>> ==> ==>>
==>> ==> ==>> If this works we might analyse what's happening and try to debug this out.
==>> ==> ==>> But I really would like this to work in the cdc_ncm driver + huawei_cdc_ncm.
==>> ==> ==>> Thank you.
==>> ==> ==This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful.
==>> ==> ==
==>> ==> ==If you have received this email in error please immediately
==>> notify the sender and delete or destroy any copy of this message ==>
==>> == ==This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful.
==>> ==
==>> ==If you have received this email in error please immediately notify
==>> the sender and delete or destroy any copy of this message ==
==>
==This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful.
==
==If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message
==
^ permalink raw reply
* Fwd: [Bug 89161] New: Regression in bonding driver with devices that have no MAC address
From: Daniel Borkmann @ 2014-12-02 10:56 UTC (permalink / raw)
To: tjc; +Cc: netdev, vfalico
In-Reply-To: <bug-89161-65011@https.bugzilla.kernel.org/>
-------- Original Message --------
Subject: [Bug 89161] New: Regression in bonding driver with devices that have no MAC address
Date: Tue, 02 Dec 2014 10:14:56 +0000
From: bugzilla-daemon@bugzilla.kernel.org
To: dborkman@redhat.com
https://bugzilla.kernel.org/show_bug.cgi?id=89161
Bug ID: 89161
Summary: Regression in bonding driver with devices that have no
MAC address
Product: Networking
Version: 2.5
Kernel Version: 3.17.4
Hardware: All
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Other
Assignee: shemminger@linux-foundation.org
Reporter: tjc@wintrmute.net
Regression: No
In kernel 3.13 and earlier, a user could use the "bonding" network module to
enslave devices without MAC addresses, such as ppp devices, in certain modes
(such as balance-rr).
At some point between 3.13 and 3.17, this ability was removed -- even though
apparently a commit was made to specifically ALLOW this to happen:
https://github.com/torvalds/linux/commit/f54424412b6b2f64cae4d7c39d981ca14ce0052c
On kernel 3.13, this was printed to syslog upon enslaving ppp0:
bonding: bond0: Warning: The first slave device specified does not support
setting the MAC address. Setting fail_over_mac to active.
bonding: bond0: enslaving ppp0 as an active interface with an up link.
On kernel 3.17.2 and 3.17.4 (and probably others) instead this error comes up:
bond0: Adding slave ppp0
bond0: The slave device specified does not support setting the MAC address
And the slave is not added.
In case it was relevant, I resorted to manually creating the bond0 with
appropriate options (including fail_over_mac) preset, and yet the problem
persists.
To replicate the problem, setup at least one ppp connection, and then follow
these instructions:
modprobe bonding
echo '+bond0' > /sys/class/net/bonding_masters
echo 'active' > /sys/class/net/bond0/bonding/fail_over_mac
ifconfig bond0 down
echo 'balance-rr' > /sys/class/net/bond0/bonding/mode
ifconfig bond0 202.xx.xx.xx netmask 255.255.255.255 mtu 1492 up
echo '500' > /sys/class/net/bond0/bonding/miimon
ifconfig ppp0 down
echo '+ppp0' > /sys/class/net/bond0/bonding/slaves
Under earlier kernel versions, that would work -- but current stable kernels
fail.
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* Re: Is this 32-bit NCM?
From: Bjørn Mork @ 2014-12-02 11:21 UTC (permalink / raw)
To: Enrico Mioso
Cc: Kevin Zhu, Eli Britstein, Alex Strizhevsky, Midge Shaojun Tan,
youtux@gmail.com, linux-usb@vger.kernel.org,
netdev@vger.kernel.org
In-Reply-To: <alpine.LNX.2.03.1412021130410.2697@gmail.com>
Enrico Mioso <mrkiko.rs@gmail.com> writes:
> Kevin - it works! the key seems to be in the tx_fixup function; there is a
> special handling for frames effectively.
> Please ... help me backport those changes to the standard Linux driver - it
> will be a gain for us all, and in general you'll have a more probable
> maintenance than you would with the driver from huawei.
Very interesting. The NCM code in the huawei driver has a different
origin, so it is quite different and not too easy to merge into the
existing Linux cdc_ncm driver.
But this does pinpoint differences we should explore. One is the
placement of the NDP: The Huawei driver puts it at the end. Another,
which is much easier to test out quickly, is the sequence numbering: The
Huawei driver doesn't use it.
So I wonder if this makes any difference:
diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index 80a844e0ae03..37f11770acb6 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -1049,7 +1049,7 @@ cdc_ncm_fill_tx_frame(struct usbnet *dev, struct sk_buff *skb, __le32 sign)
nth16 = (struct usb_cdc_ncm_nth16 *)memset(skb_put(skb_out, sizeof(struct usb_cdc_ncm_nth16)), 0, sizeof(struct usb_cdc_ncm_nth16));
nth16->dwSignature = cpu_to_le32(USB_CDC_NCM_NTH16_SIGN);
nth16->wHeaderLength = cpu_to_le16(sizeof(struct usb_cdc_ncm_nth16));
- nth16->wSequence = cpu_to_le16(ctx->tx_seq++);
+// nth16->wSequence = cpu_to_le16(ctx->tx_seq++);
/* count total number of frames in this NTB */
ctx->tx_curr_frame_num = 0;
Bjørn
^ permalink raw reply related
* Re: Is this 32-bit NCM?
From: Enrico Mioso @ 2014-12-02 11:28 UTC (permalink / raw)
To: Bjørn Mork
Cc: Kevin Zhu, Eli Britstein, Alex Strizhevsky, Midge Shaojun Tan,
youtux@gmail.com, linux-usb@vger.kernel.org,
netdev@vger.kernel.org
In-Reply-To: <87fvcyqoup.fsf@nemi.mork.no>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2241 bytes --]
Testing it right now - let you know in a moment.
On Tue, 2 Dec 2014, Bjørn Mork wrote:
==Date: Tue, 2 Dec 2014 12:21:18
==From: Bjørn Mork <bjorn@mork.no>
==To: Enrico Mioso <mrkiko.rs@gmail.com>
==Cc: Kevin Zhu <Mingying.Zhu@audiocodes.com>,
== Eli Britstein <Eli.Britstein@audiocodes.com>,
== Alex Strizhevsky <alexxst@gmail.com>,
== Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>,
== "youtux@gmail.com" <youtux@gmail.com>,
== "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
== "netdev@vger.kernel.org" <netdev@vger.kernel.org>
==Subject: Re: Is this 32-bit NCM?
==
==Enrico Mioso <mrkiko.rs@gmail.com> writes:
==
==> Kevin - it works! the key seems to be in the tx_fixup function; there is a
==> special handling for frames effectively.
==> Please ... help me backport those changes to the standard Linux driver - it
==> will be a gain for us all, and in general you'll have a more probable
==> maintenance than you would with the driver from huawei.
==
==Very interesting. The NCM code in the huawei driver has a different
==origin, so it is quite different and not too easy to merge into the
==existing Linux cdc_ncm driver.
==
==But this does pinpoint differences we should explore. One is the
==placement of the NDP: The Huawei driver puts it at the end. Another,
==which is much easier to test out quickly, is the sequence numbering: The
==Huawei driver doesn't use it.
==
==So I wonder if this makes any difference:
==
==diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
==index 80a844e0ae03..37f11770acb6 100644
==--- a/drivers/net/usb/cdc_ncm.c
==+++ b/drivers/net/usb/cdc_ncm.c
==@@ -1049,7 +1049,7 @@ cdc_ncm_fill_tx_frame(struct usbnet *dev, struct sk_buff *skb, __le32 sign)
== nth16 = (struct usb_cdc_ncm_nth16 *)memset(skb_put(skb_out, sizeof(struct usb_cdc_ncm_nth16)), 0, sizeof(struct usb_cdc_ncm_nth16));
== nth16->dwSignature = cpu_to_le32(USB_CDC_NCM_NTH16_SIGN);
== nth16->wHeaderLength = cpu_to_le16(sizeof(struct usb_cdc_ncm_nth16));
==- nth16->wSequence = cpu_to_le16(ctx->tx_seq++);
==+// nth16->wSequence = cpu_to_le16(ctx->tx_seq++);
==
== /* count total number of frames in this NTB */
== ctx->tx_curr_frame_num = 0;
==
==
==
==Bjørn
==
^ permalink raw reply
* Re: Is this 32-bit NCM?
From: Enrico Mioso @ 2014-12-02 11:39 UTC (permalink / raw)
To: Bjørn Mork
Cc: Kevin Zhu, Eli Britstein, Alex Strizhevsky, Midge Shaojun Tan,
youtux@gmail.com, linux-usb@vger.kernel.org,
netdev@vger.kernel.org
In-Reply-To: <87fvcyqoup.fsf@nemi.mork.no>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2598 bytes --]
To be clear - I also rebooted the remote system to power cycle the modem,
wanting to avoid
at^reset
But this modification of the driver unfortunately seems to lead to no changes.
Thank you so much Bjorn.
Interetingly - a misbehaviour of the firmware was observed - I wasn't able to
at^ndisdup=1,0
... the firmware seemed to ignore it.
But this might not be related to the patch.
Thank you again.
Enrico
On Tue, 2 Dec 2014, Bjørn Mork wrote:
==Date: Tue, 2 Dec 2014 12:21:18
==From: Bjørn Mork <bjorn@mork.no>
==To: Enrico Mioso <mrkiko.rs@gmail.com>
==Cc: Kevin Zhu <Mingying.Zhu@audiocodes.com>,
== Eli Britstein <Eli.Britstein@audiocodes.com>,
== Alex Strizhevsky <alexxst@gmail.com>,
== Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>,
== "youtux@gmail.com" <youtux@gmail.com>,
== "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
== "netdev@vger.kernel.org" <netdev@vger.kernel.org>
==Subject: Re: Is this 32-bit NCM?
==
==Enrico Mioso <mrkiko.rs@gmail.com> writes:
==
==> Kevin - it works! the key seems to be in the tx_fixup function; there is a
==> special handling for frames effectively.
==> Please ... help me backport those changes to the standard Linux driver - it
==> will be a gain for us all, and in general you'll have a more probable
==> maintenance than you would with the driver from huawei.
==
==Very interesting. The NCM code in the huawei driver has a different
==origin, so it is quite different and not too easy to merge into the
==existing Linux cdc_ncm driver.
==
==But this does pinpoint differences we should explore. One is the
==placement of the NDP: The Huawei driver puts it at the end. Another,
==which is much easier to test out quickly, is the sequence numbering: The
==Huawei driver doesn't use it.
==
==So I wonder if this makes any difference:
==
==diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
==index 80a844e0ae03..37f11770acb6 100644
==--- a/drivers/net/usb/cdc_ncm.c
==+++ b/drivers/net/usb/cdc_ncm.c
==@@ -1049,7 +1049,7 @@ cdc_ncm_fill_tx_frame(struct usbnet *dev, struct sk_buff *skb, __le32 sign)
== nth16 = (struct usb_cdc_ncm_nth16 *)memset(skb_put(skb_out, sizeof(struct usb_cdc_ncm_nth16)), 0, sizeof(struct usb_cdc_ncm_nth16));
== nth16->dwSignature = cpu_to_le32(USB_CDC_NCM_NTH16_SIGN);
== nth16->wHeaderLength = cpu_to_le16(sizeof(struct usb_cdc_ncm_nth16));
==- nth16->wSequence = cpu_to_le16(ctx->tx_seq++);
==+// nth16->wSequence = cpu_to_le16(ctx->tx_seq++);
==
== /* count total number of frames in this NTB */
== ctx->tx_curr_frame_num = 0;
==
==
==
==Bjørn
==
^ permalink raw reply
* [PATCH net] cxgb4: Add a check for flashing FW using ethtool
From: Hariprasad Shenai @ 2014-12-02 12:09 UTC (permalink / raw)
To: netdev; +Cc: davem, leedom, anish, nirranjan, kumaras, Hariprasad Shenai
Don't let T4 firmware flash on a T5 adapter and vice-versa
using ethtool
Based on original work by Casey Leedom <leedom@chelsio.com>
Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
---
drivers/net/ethernet/chelsio/cxgb4/t4_hw.c | 26 ++++++++++++++++++++++++++
1 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
index 163a2a1..fae205a 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
@@ -1131,6 +1131,27 @@ unsigned int t4_flash_cfg_addr(struct adapter *adapter)
return FLASH_CFG_START;
}
+/* Return TRUE if the specified firmware matches the adapter. I.e. T4
+ * firmware for T4 adapters, T5 firmware for T5 adapters, etc. We go ahead
+ * and emit an error message for mismatched firmware to save our caller the
+ * effort ...
+ */
+static int t4_fw_matches_chip(const struct adapter *adap,
+ const struct fw_hdr *hdr)
+{
+ /* The expression below will return FALSE for any unsupported adapter
+ * which will keep us "honest" in the future ...
+ */
+ if ((is_t4(adap->params.chip) && hdr->chip == FW_HDR_CHIP_T4) ||
+ (is_t5(adap->params.chip) && hdr->chip == FW_HDR_CHIP_T5))
+ return 1;
+
+ dev_err(adap->pdev_dev,
+ "FW image (%d) is not suitable for this adapter (%d)\n",
+ hdr->chip, CHELSIO_CHIP_VERSION(adap->params.chip));
+ return 0;
+}
+
/**
* t4_load_fw - download firmware
* @adap: the adapter
@@ -1170,6 +1191,8 @@ int t4_load_fw(struct adapter *adap, const u8 *fw_data, unsigned int size)
FW_MAX_SIZE);
return -EFBIG;
}
+ if (!t4_fw_matches_chip(adap, hdr))
+ return -EINVAL;
for (csum = 0, i = 0; i < size / sizeof(csum); i++)
csum += ntohl(p[i]);
@@ -3080,6 +3103,9 @@ int t4_fw_upgrade(struct adapter *adap, unsigned int mbox,
const struct fw_hdr *fw_hdr = (const struct fw_hdr *)fw_data;
int reset, ret;
+ if (!t4_fw_matches_chip(adap, fw_hdr))
+ return -EINVAL;
+
ret = t4_fw_halt(adap, mbox, force);
if (ret < 0 && !force)
return ret;
--
1.7.1
^ permalink raw reply related
* RE: [PATCH] Documentation: bindings: net: DPAA corenet binding document
From: Madalin-Cristian Bucur @ 2014-12-02 12:12 UTC (permalink / raw)
To: Scott Wood
Cc: devicetree@vger.kernel.org, netdev@vger.kernel.org, Emilian Medve,
Igal.Liberman@freescale.com, galak@codeaurora.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1417495189.15957.209.camel@freescale.com>
> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Tuesday, December 02, 2014 6:40 AM
> On Fri, 2014-11-28 at 12:10 +0200, Madalin Bucur wrote:
> > Add the device tree binding document for the DPAA corenet node
> > and DPAA Ethernet nodes.
> >
> > Signed-off-by: Madalin Bucur <madalin.bucur@freescale.com>
> > ---
> > Documentation/devicetree/bindings/net/fsl-dpaa.txt | 31
> ++++++++++++++++++++++
> > 1 file changed, 31 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/net/fsl-dpaa.txt
> >
> > diff --git a/Documentation/devicetree/bindings/net/fsl-dpaa.txt
> b/Documentation/devicetree/bindings/net/fsl-dpaa.txt
> > new file mode 100644
> > index 0000000..822c668
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/net/fsl-dpaa.txt
> > @@ -0,0 +1,31 @@
> > +*DPAA corenet
> > +
> > +The corenet bus containing all DPAA Ethernet nodes.
>
> What does this have to do with corenet?
>
The corenet-generic platform code uses this compatible. Here are some excerpts
from the platform code found in SDK arch/powerpc/platforms/85xx/corenet_generic.c
...
* Corenet based SoC DS Setup
*
* Maintained by Kumar Gala (see MAINTAINERS for contact information)
*
* Copyright 2009-2011 Freescale Semiconductor Inc.
...
static const struct of_device_id of_device_ids[] = {
{
.compatible = "simple-bus"
},
{
.compatible = "fsl,dpaa"
},
...
int __init corenet_gen_publish_devices(void)
{
return of_platform_bus_probe(NULL, of_device_ids, NULL);
}
...
> > +Required property
> > + - compatible: string property. Must include "fsl,dpaa". Can include
> > + also "fsl,<SoC>-dpaa".
>
> No need for the <SoC> part. As we previously discussed, the only
> purpose of this node is backwards compatibility with the U-Boot MAC
> address fixup -- if U-Boot doesn't look for the <SoC> version, then
> don't complicate things.
>
> Though, I can't find where U-Boot references this node. Are you sure
> it's not using the ethernet%d aliases like everything else, in which
> case why do we need this node at all?
>
> -Scott
>
The initial (Freescale SDK) binding document contained those compatibles,
not sure what the initial intent was for the <SoC> variants.
The "fsl,dpaa" node is of interest to the DPAA Ethernet because it is
the parent of the "fsl,dpa-ethernet" nodes.
Madalin
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH] net: mvneta: fix Tx interrupt delay
From: Eric Dumazet @ 2014-12-02 12:18 UTC (permalink / raw)
To: Willy Tarreau
Cc: netdev, Maggie Mae Roxas, Thomas Petazzoni, Gregory CLEMENT,
Ezequiel Garcia
In-Reply-To: <20141202071304.GA22512@1wt.eu>
On Tue, 2014-12-02 at 08:13 +0100, Willy Tarreau wrote:
> The mvneta driver sets the amount of Tx coalesce packets to 16 by
> default. Normally that does not cause any trouble since the driver
> uses a much larger Tx ring size (532 packets). But some sockets
> might run with very small buffers, much smaller than the equivalent
> of 16 packets. This is what ping is doing for example, by setting
> SNDBUF to 324 bytes rounded up to 2kB by the kernel.
>
> The problem is that there is no documented method to force a specific
> packet to emit an interrupt (eg: the last of the ring) nor is it
> possible to make the NIC emit an interrupt after a given delay.
>
> In this case, it causes trouble, because when ping sends packets over
> its raw socket, the few first packets leave the system, and the first
> 15 packets will be emitted without an IRQ being generated, so without
> the skbs being freed. And since the socket's buffer is small, there's
> no way to reach that amount of packets, and the ping ends up with
> "send: no buffer available" after sending 6 packets. Running with 3
> instances of ping in parallel is enough to hide the problem, because
> with 6 packets per instance, that's 18 packets total, which is enough
> to grant a Tx interrupt before all are sent.
>
> The original driver in the LSP kernel worked around this design flaw
> by using a software timer to clean up the Tx descriptors. This timer
> was slow and caused terrible network performance on some Tx-bound
> workloads (such as routing) but was enough to make tools like ping
> work correctly.
>
> Instead here, we simply set the packet counts before interrupt to 1.
> This ensures that each packet sent will produce an interrupt. NAPI
> takes care of coalescing interrupts since the interrupt is disabled
> once generated.
>
> No measurable performance impact nor CPU usage were observed on small
> nor large packets, including when saturating the link on Tx, and this
> fixes tools like ping which rely on too small a send buffer. If one
> wants to increase this value for certain workloads where it is safe
> to do so, "ethtool -C $dev tx-frames" will override this default
> setting.
>
> This fix needs to be applied to stable kernels starting with 3.10.
>
> Tested-By: Maggie Mae Roxas <maggie.mae.roxas@gmail.com>
> Signed-off-by: Willy Tarreau <w@1wt.eu>
>
> ---
> drivers/net/ethernet/marvell/mvneta.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
> index 4762994..35bfba7 100644
> --- a/drivers/net/ethernet/marvell/mvneta.c
> +++ b/drivers/net/ethernet/marvell/mvneta.c
> @@ -214,7 +214,7 @@
> /* Various constants */
>
> /* Coalescing */
> -#define MVNETA_TXDONE_COAL_PKTS 16
> +#define MVNETA_TXDONE_COAL_PKTS 1
> #define MVNETA_RX_COAL_PKTS 32
> #define MVNETA_RX_COAL_USEC 100
>
I am surprised TCP even worked correctly with this problem.
I highly suggest BQL for this driver, now this issue is fixed.
I wonder if this high setting was not because of race conditions in the
driver :
mvneta_tx() seems to access skb->len too late, TX completion might have
already freed skb :
u64_stats_update_begin(&stats->syncp);
stats->tx_packets++;
stats->tx_bytes += skb->len; // potential use after free
u64_stats_update_end(&stats->syncp);
Thanks Willy !
^ permalink raw reply
* [PATCH] net: mvneta: fix race condition in mvneta_tx()
From: Eric Dumazet @ 2014-12-02 12:30 UTC (permalink / raw)
To: Willy Tarreau
Cc: netdev, Maggie Mae Roxas, Thomas Petazzoni, Gregory CLEMENT,
Ezequiel Garcia
In-Reply-To: <1417522688.5303.35.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <edumazet@google.com>
mvneta_tx() dereferences skb to get skb->len too late,
as hardware might have completed the transmit and TX completion
could have freed the skb from another cpu.
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
drivers/net/ethernet/marvell/mvneta.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index ccc3ce2e8c8c7c8d929b2ff5e271bf62948c7012..34f58150d693b4215b58285c1dcbb4b16cc03697 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -1721,6 +1721,7 @@ static int mvneta_tx(struct sk_buff *skb, struct net_device *dev)
u16 txq_id = skb_get_queue_mapping(skb);
struct mvneta_tx_queue *txq = &pp->txqs[txq_id];
struct mvneta_tx_desc *tx_desc;
+ int len = skb->len;
int frags = 0;
u32 tx_cmd;
@@ -1788,7 +1789,7 @@ out:
u64_stats_update_begin(&stats->syncp);
stats->tx_packets++;
- stats->tx_bytes += skb->len;
+ stats->tx_bytes += len;
u64_stats_update_end(&stats->syncp);
} else {
dev->stats.tx_dropped++;
^ permalink raw reply related
* Re: [PATCH] net: mvneta: fix race condition in mvneta_tx()
From: Eric Dumazet @ 2014-12-02 12:37 UTC (permalink / raw)
To: Willy Tarreau
Cc: netdev, Maggie Mae Roxas, Thomas Petazzoni, Gregory CLEMENT,
Ezequiel Garcia
In-Reply-To: <1417523459.5303.39.camel@edumazet-glaptop2.roam.corp.google.com>
On Tue, 2014-12-02 at 04:30 -0800, Eric Dumazet wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> mvneta_tx() dereferences skb to get skb->len too late,
> as hardware might have completed the transmit and TX completion
> could have freed the skb from another cpu.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
For completeness, this bug was added in linux-3.14 and seems a stable
candidate.
Fixes: 71f6d1b31fb1 ("net: mvneta: replace Tx timer with a real interrupt")
^ permalink raw reply
* Re: [PATCH] net: mvneta: fix Tx interrupt delay
From: Willy Tarreau @ 2014-12-02 12:39 UTC (permalink / raw)
To: Eric Dumazet
Cc: netdev, Maggie Mae Roxas, Thomas Petazzoni, Gregory CLEMENT,
Ezequiel Garcia
In-Reply-To: <1417522688.5303.35.camel@edumazet-glaptop2.roam.corp.google.com>
Hi Eric,
On Tue, Dec 02, 2014 at 04:18:08AM -0800, Eric Dumazet wrote:
> > diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
> > index 4762994..35bfba7 100644
> > --- a/drivers/net/ethernet/marvell/mvneta.c
> > +++ b/drivers/net/ethernet/marvell/mvneta.c
> > @@ -214,7 +214,7 @@
> > /* Various constants */
> >
> > /* Coalescing */
> > -#define MVNETA_TXDONE_COAL_PKTS 16
> > +#define MVNETA_TXDONE_COAL_PKTS 1
> > #define MVNETA_RX_COAL_PKTS 32
> > #define MVNETA_RX_COAL_USEC 100
> >
>
>
> I am surprised TCP even worked correctly with this problem.
There are multiple explanations to this :
- we used to flush Tx queues upon Rx interrupt, which used to hide
the problem.
- we tend to have large socket buffers, which cover the issue. I've
never had any issue at high data rates. After all only 23kB send
buffer is needed to get it to work.
- most often you have multiple parallel streams which hide the issue
even more.
> I highly suggest BQL for this driver, now this issue is fixed.
How does that work ?
> I wonder if this high setting was not because of race conditions in the
> driver :
>
> mvneta_tx() seems to access skb->len too late, TX completion might have
> already freed skb :
>
> u64_stats_update_begin(&stats->syncp);
> stats->tx_packets++;
> stats->tx_bytes += skb->len; // potential use after free
> u64_stats_update_end(&stats->syncp);
Good catch! But no, this is unrelated since it does not fix the race either.
Initially this driver used to implement a timer to flush the Tx queue after
10ms, resulting in abysmal Tx-only performance as you can easily imagine. In
my opinion there's a design flaw in the chip, and they did everything they
could to workaround it (let's not say "hide it"), but that was not enough.
When I "fixed" the performance issue by enabling the Tx interrupt, I kept
the value 16 which gave pretty good results to me, without realizing that
there was this corner case :-/
> Thanks Willy !
Thanks for your review :-)
Willy
^ permalink raw reply
* Re: [PATCH] net: mvneta: fix race condition in mvneta_tx()
From: Willy Tarreau @ 2014-12-02 12:40 UTC (permalink / raw)
To: Eric Dumazet
Cc: netdev, Maggie Mae Roxas, Thomas Petazzoni, Gregory CLEMENT,
Ezequiel Garcia
In-Reply-To: <1417523835.5303.41.camel@edumazet-glaptop2.roam.corp.google.com>
On Tue, Dec 02, 2014 at 04:37:15AM -0800, Eric Dumazet wrote:
> On Tue, 2014-12-02 at 04:30 -0800, Eric Dumazet wrote:
> > From: Eric Dumazet <edumazet@google.com>
> >
> > mvneta_tx() dereferences skb to get skb->len too late,
> > as hardware might have completed the transmit and TX completion
> > could have freed the skb from another cpu.
> >
> > Signed-off-by: Eric Dumazet <edumazet@google.com>
>
>
>
> For completeness, this bug was added in linux-3.14 and seems a stable
> candidate.
>
> Fixes: 71f6d1b31fb1 ("net: mvneta: replace Tx timer with a real interrupt")
Absolutely, we backported this one back to 3.10.
Thanks Eric!
Willy
^ permalink raw reply
* Humble Request
From: Cirotti-Levine, Marie @ 2014-12-02 12:42 UTC (permalink / raw)
An Urgent Situation, that requires your Attention, Please only reply to (khalidmohamed@qq.com<mailto:khalidmohamed@qq.com>) for more details.
^ permalink raw reply
* Re: [PATCH] net: mvneta: fix Tx interrupt delay
From: Eric Dumazet @ 2014-12-02 13:04 UTC (permalink / raw)
To: Willy Tarreau
Cc: netdev, Maggie Mae Roxas, Thomas Petazzoni, Gregory CLEMENT,
Ezequiel Garcia
In-Reply-To: <20141202123951.GA16347@1wt.eu>
On Tue, 2014-12-02 at 13:39 +0100, Willy Tarreau wrote:
> Hi Eric,
>
> On Tue, Dec 02, 2014 at 04:18:08AM -0800, Eric Dumazet wrote:
>
> > I highly suggest BQL for this driver, now this issue is fixed.
>
> How does that work ?
This works very well ;)
Its super easy to implement, take a look at commits
bdbc063129e811264cd6c311d8c2d9b95de01231 or
7070ce0a6419a118842298bc967061ad6cea40db
^ permalink raw reply
* Re: Is this 32-bit NCM?
From: Enrico Mioso @ 2014-12-02 13:11 UTC (permalink / raw)
To: Bjørn Mork
Cc: Kevin Zhu, Eli Britstein, Alex Strizhevsky, Midge Shaojun Tan,
youtux@gmail.com, linux-usb@vger.kernel.org,
netdev@vger.kernel.org
In-Reply-To: <87fvcyqoup.fsf@nemi.mork.no>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2429 bytes --]
... but out of curiosity: are NCM specs allowing to change order of things in
the package or not?
This is not to start philosofical falames or something, but to understand
better how things work. And, if they do: how much arbitrarily?
On Tue, 2 Dec 2014, Bjørn Mork wrote:
==Date: Tue, 2 Dec 2014 12:21:18
==From: Bjørn Mork <bjorn@mork.no>
==To: Enrico Mioso <mrkiko.rs@gmail.com>
==Cc: Kevin Zhu <Mingying.Zhu@audiocodes.com>,
== Eli Britstein <Eli.Britstein@audiocodes.com>,
== Alex Strizhevsky <alexxst@gmail.com>,
== Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>,
== "youtux@gmail.com" <youtux@gmail.com>,
== "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
== "netdev@vger.kernel.org" <netdev@vger.kernel.org>
==Subject: Re: Is this 32-bit NCM?
==
==Enrico Mioso <mrkiko.rs@gmail.com> writes:
==
==> Kevin - it works! the key seems to be in the tx_fixup function; there is a
==> special handling for frames effectively.
==> Please ... help me backport those changes to the standard Linux driver - it
==> will be a gain for us all, and in general you'll have a more probable
==> maintenance than you would with the driver from huawei.
==
==Very interesting. The NCM code in the huawei driver has a different
==origin, so it is quite different and not too easy to merge into the
==existing Linux cdc_ncm driver.
==
==But this does pinpoint differences we should explore. One is the
==placement of the NDP: The Huawei driver puts it at the end. Another,
==which is much easier to test out quickly, is the sequence numbering: The
==Huawei driver doesn't use it.
==
==So I wonder if this makes any difference:
==
==diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
==index 80a844e0ae03..37f11770acb6 100644
==--- a/drivers/net/usb/cdc_ncm.c
==+++ b/drivers/net/usb/cdc_ncm.c
==@@ -1049,7 +1049,7 @@ cdc_ncm_fill_tx_frame(struct usbnet *dev, struct sk_buff *skb, __le32 sign)
== nth16 = (struct usb_cdc_ncm_nth16 *)memset(skb_put(skb_out, sizeof(struct usb_cdc_ncm_nth16)), 0, sizeof(struct usb_cdc_ncm_nth16));
== nth16->dwSignature = cpu_to_le32(USB_CDC_NCM_NTH16_SIGN);
== nth16->wHeaderLength = cpu_to_le16(sizeof(struct usb_cdc_ncm_nth16));
==- nth16->wSequence = cpu_to_le16(ctx->tx_seq++);
==+// nth16->wSequence = cpu_to_le16(ctx->tx_seq++);
==
== /* count total number of frames in this NTB */
== ctx->tx_curr_frame_num = 0;
==
==
==
==Bjørn
==
^ permalink raw reply
* Re: [PATCH] net: mvneta: fix Tx interrupt delay
From: Willy Tarreau @ 2014-12-02 13:24 UTC (permalink / raw)
To: Eric Dumazet
Cc: netdev, Maggie Mae Roxas, Thomas Petazzoni, Gregory CLEMENT,
Ezequiel Garcia
In-Reply-To: <1417525458.5303.48.camel@edumazet-glaptop2.roam.corp.google.com>
On Tue, Dec 02, 2014 at 05:04:18AM -0800, Eric Dumazet wrote:
> On Tue, 2014-12-02 at 13:39 +0100, Willy Tarreau wrote:
> > Hi Eric,
> >
> > On Tue, Dec 02, 2014 at 04:18:08AM -0800, Eric Dumazet wrote:
> >
> > > I highly suggest BQL for this driver, now this issue is fixed.
> >
> > How does that work ?
>
> This works very well ;)
>
> Its super easy to implement, take a look at commits
> bdbc063129e811264cd6c311d8c2d9b95de01231 or
> 7070ce0a6419a118842298bc967061ad6cea40db
Thanks but I'm not sure I entirely understand the concept. Is it to
notify the sender that the packets were already queued for the NIC ?
And if so, how does that improve the situation ? I'm sorry if this
sounds like a stupid question, it's just that the concept by itself
is not clear to me.
Willy
^ permalink raw reply
* Re: Is this 32-bit NCM?
From: Bjørn Mork @ 2014-12-02 13:37 UTC (permalink / raw)
To: Enrico Mioso
Cc: Kevin Zhu, Eli Britstein, Alex Strizhevsky, Midge Shaojun Tan,
youtux@gmail.com, linux-usb@vger.kernel.org,
netdev@vger.kernel.org
In-Reply-To: <alpine.LNX.2.03.1412021410270.29633-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
> ... but out of curiosity: are NCM specs allowing to change order of things in
> the package or not?
> This is not to start philosofical falames or something, but to understand
> better how things work. And, if they do: how much arbitrarily?
Only the NTB header has a fixed location. The rest can be anywhere and
in any order. Quoting from section 3 Data Transport:
"Within any given NTB, the NTH always must be first; but the other
items may occur in arbitrary order."
Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* re: net-caif: add CAIF core protocol stack
From: Dan Carpenter @ 2014-12-02 13:40 UTC (permalink / raw)
To: sjur.brandeland; +Cc: netdev, Jörn Engel
Hello Sjur Braendeland,
The patch b482cd2053e3: "net-caif: add CAIF core protocol stack" from
Mar 30, 2010, leads to the following static checker warning:
net/caif/cfctrl.c:440 cfctrl_recv()
error: potentially using uninitialized 'tmp'.
net/caif/cfpkt_skbuff.c
124 int cfpkt_extr_head(struct cfpkt *pkt, void *data, u16 len)
125 {
126 struct sk_buff *skb = pkt_to_skb(pkt);
127 u8 *from;
128 if (unlikely(is_erronous(pkt)))
129 return -EPROTO;
130
131 if (unlikely(len > skb->len)) {
132 PKT_ERROR(pkt, "read beyond end of packet\n");
133 return -EPROTO;
134 }
135
136 if (unlikely(len > skb_headlen(skb))) {
^^^^^^^^^^^^^^^^^^^^^
Assume we can hit this condition with "len == 1". I don't know if
that's possible.
137 if (unlikely(skb_linearize(skb) != 0)) {
138 PKT_ERROR(pkt, "linearize failed\n");
139 return -EPROTO;
140 }
141 }
142 from = skb_pull(skb, len);
143 from -= len;
144 if (data)
145 memcpy(data, from, len);
146 return 0;
147 }
148 EXPORT_SYMBOL(cfpkt_extr_head);
net/caif/cfctrl.c
430 case CFCTRL_SRV_RFM:
431 /* Construct a frame, convert
432 * DatagramConnectionID
433 * to network format long and copy it out...
434 */
435 cfpkt_extr_head(pkt, &tmp32, 4);
436 linkparam.u.rfm.connid =
437 le32_to_cpu(tmp32);
438 cp = (u8 *) linkparam.u.rfm.volume;
439 for (cfpkt_extr_head(pkt, &tmp, 1);
440 cfpkt_more(pkt) && tmp != '\0';
^^^^^^^^^^
cfpkt_more() would be true and "tmp" is uninitliazed so it is a forever
loop.
441 cfpkt_extr_head(pkt, &tmp, 1))
442 *cp++ = tmp;
443 *cp = '\0';
regards,
dan carpenter
^ permalink raw reply
* Re: Is this 32-bit NCM?
From: Enrico Mioso @ 2014-12-02 13:53 UTC (permalink / raw)
To: Bjørn Mork
Cc: Kevin Zhu, Eli Britstein, Alex Strizhevsky, Midge Shaojun Tan,
youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <87lhmqp400.fsf-lbf33ChDnrE/G1V5fR+Y7Q@public.gmane.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1490 bytes --]
Thank you very much Bjorn.
On Tue, 2 Dec 2014, Bjørn Mork wrote:
==Date: Tue, 2 Dec 2014 14:37:03
==From: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>
==To: Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
==Cc: Kevin Zhu <Mingying.Zhu-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>,
== Eli Britstein <Eli.Britstein-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>,
== Alex Strizhevsky <alexxst-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
== Midge Shaojun Tan <ShaojunMidge.Tan-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>,
== "youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org" <youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
== "linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
== "netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
==Subject: Re: Is this 32-bit NCM?
==
==Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
==
==> ... but out of curiosity: are NCM specs allowing to change order of things in
==> the package or not?
==> This is not to start philosofical falames or something, but to understand
==> better how things work. And, if they do: how much arbitrarily?
==
==Only the NTB header has a fixed location. The rest can be anywhere and
==in any order. Quoting from section 3 Data Transport:
==
== "Within any given NTB, the NTH always must be first; but the other
== items may occur in arbitrary order."
==
==
==Bjørn
==
^ permalink raw reply
* Re: [PATCH net] cxgb4: Add a check for flashing FW using ethtool
From: Sergei Shtylyov @ 2014-12-02 14:18 UTC (permalink / raw)
To: Hariprasad Shenai, netdev; +Cc: davem, leedom, anish, nirranjan, kumaras
In-Reply-To: <1417522177-14842-1-git-send-email-hariprasad@chelsio.com>
Hello.
On 12/2/2014 3:09 PM, Hariprasad Shenai wrote:
> Don't let T4 firmware flash on a T5 adapter and vice-versa
> using ethtool
> Based on original work by Casey Leedom <leedom@chelsio.com>
> Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
> ---
> drivers/net/ethernet/chelsio/cxgb4/t4_hw.c | 26 ++++++++++++++++++++++++++
> 1 files changed, 26 insertions(+), 0 deletions(-)
> diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
> index 163a2a1..fae205a 100644
> --- a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
> +++ b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
> @@ -1131,6 +1131,27 @@ unsigned int t4_flash_cfg_addr(struct adapter *adapter)
> return FLASH_CFG_START;
> }
>
> +/* Return TRUE if the specified firmware matches the adapter. I.e. T4
> + * firmware for T4 adapters, T5 firmware for T5 adapters, etc. We go ahead
> + * and emit an error message for mismatched firmware to save our caller the
> + * effort ...
> + */
> +static int t4_fw_matches_chip(const struct adapter *adap,
s/int/bool/?
> + const struct fw_hdr *hdr)
> +{
> + /* The expression below will return FALSE for any unsupported adapter
> + * which will keep us "honest" in the future ...
> + */
> + if ((is_t4(adap->params.chip) && hdr->chip == FW_HDR_CHIP_T4) ||
> + (is_t5(adap->params.chip) && hdr->chip == FW_HDR_CHIP_T5))
> + return 1;
s/1/true/?
> +
> + dev_err(adap->pdev_dev,
> + "FW image (%d) is not suitable for this adapter (%d)\n",
> + hdr->chip, CHELSIO_CHIP_VERSION(adap->params.chip));
> + return 0;
s/0/false/?
[...]
WBR, Sergei
^ permalink raw reply
* [PATCH net-next V2 0/2] ethtool, net/mlx4_en: RSS hash function selection
From: Amir Vadai @ 2014-12-02 14:20 UTC (permalink / raw)
To: David S. Miller, Ben Hutchings
Cc: netdev, Or Gerlitz, Eyal Perry, Yevgeny Petrilin, Amir Vadai
Hi,
This patchset by Eyal adds support in set/get of RSS hash function. Current
supported functions are Toeplitz and XOR. The API is design to enable adding
new hash functions without breaking backward compatibility.
Userspace patch will be sent after API is available in kernel.
The patchset was applied and tested over commit cd4c910 ("netpoll: delete
defconfig references to obsolete NETPOLL_TRAP")
Amir
Changes from V1:
- Patch 1/2 - ethtool: Support for configurable RSS hash function:
- Accept an hfunc the chip is using instead of only ETH_RSS_HASH_NO_CHANGE.
- Provide an accurate hfunc value in get_rxfh() call.
- Changed the behavior of the get_rxfh() w.r.t the validation of the
arguments. Function will return 0 instead of -EOPNOSUPP when all arguments
are NULL.
Changes from V0:
- Patch 1/2 - ethtool: Support for configurable RSS hash function:
- Add ETH prefix to RSS_HASH_* definitions
- Moved the strings array to ethtool.c
- Extend {get,set}_rxfh with additional arg instead of adding new
ethtool_option and adopt the change into drivers implementations.
- Moved indir_size and key_size validation into drivers implantation
- Documented hfunc filed in ethtool_rxfh struct
- Patch 2/2 - net/mlx4_en: Support for configurable RSS hash function
- Remove redundant priv->rss_hash_fn_caps
- Use == operator instead & when determining requested hash function.
Eyal Perry (2):
ethtool: Support for configurable RSS hash function
net/mlx4_en: Support for configurable RSS hash function
drivers/net/ethernet/amd/xgbe/xgbe-ethtool.c | 11 +++-
.../net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c | 20 ++++++-
drivers/net/ethernet/broadcom/tg3.c | 20 ++++++-
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 18 +++++-
drivers/net/ethernet/emulex/benet/be_ethtool.c | 12 +++-
drivers/net/ethernet/intel/fm10k/fm10k_ethtool.c | 12 +++-
drivers/net/ethernet/intel/i40evf/i40evf_ethtool.c | 17 +++++-
drivers/net/ethernet/intel/igb/igb_ethtool.c | 16 ++++-
drivers/net/ethernet/mellanox/mlx4/en_ethtool.c | 37 +++++++++++-
drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 11 ++++
drivers/net/ethernet/mellanox/mlx4/en_rx.c | 14 ++++-
drivers/net/ethernet/mellanox/mlx4/mlx4_en.h | 2 +-
drivers/net/ethernet/sfc/ethtool.c | 18 ++++--
drivers/net/vmxnet3/vmxnet3_ethtool.c | 15 ++++-
include/linux/ethtool.h | 42 +++++++++----
include/uapi/linux/ethtool.h | 10 +++-
net/core/ethtool.c | 69 ++++++++++++----------
17 files changed, 272 insertions(+), 72 deletions(-)
--
1.8.3.4
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox