Re: USB 3.0 drive crashes system when plugged in - regression
On Wed, 2014-12-03 at 00:29 +0100, Marcin Zajączkowski wrote: > Hi, > > After upgrade to Fedora 21 with 3.17.3-300.fc21.x86_64 (from 3.14.x in > Fedora 19) my USB 3.0 drive (Seagate Backup+ 1TB) stopped working with > USB 3.0 port (works fine with USB 2.0 port). > > When plug in for the first time (USB 3.0 port) I see in log: > > > kernel: xhci_hcd :04:00.0: ERROR Transfer event for disabled > endpoint or incorrect stream ring > > kernel: xhci_hcd :04:00.0: @000241eec570 11979000 0002 > 0500 01078001 Are you using the UAS driver? Regards Oliver -- Oliver Neukum -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next] r8152: reduce memory copy for rx
On Wed, 2014-12-03 at 07:05 +, Hayes Wang wrote: > Eric Dumazet [mailto:eric.duma...@gmail.com] > > Sent: Wednesday, December 03, 2014 2:08 PM > [...] > > Better performance for what workload exactly ? > > I test it by using Chariot with 4 Tx and 4 Rx. > It has about 4% improvement. > Have you tried using more concurrent RX flows, in a possibly lossy environment (so that TCP is forced to queue packets in out of order queue) ? > > cloning in rx path has many drawbacks, with skb->truesize > > being usually wrong. > > Excuse me. I find the skb_clone() would copy the > truesize from original skb. Do you mean the value > may not be suitable for the cloned skb? With cloning, (skb->len / skb->truesize) will eventually be very very small, forcing TCP stack to perform collapses (copies !!!) under pressure. > > Could other method do the same thing? Or, do you > think keeping the original one is better? skb cloning prevents GRO and TCP coalescing from working. netfilter might also be forced to copy whole frame in case a mangle is needed (eg with NAT ...) I would rather try to implement GRO, and/or using fragments instead of pure linear skbs. (skb->head would be around 128 or 256 bytes, and you attach to skb the frame as a page fragment) -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH net-next] r8152: reduce memory copy for rx
Eric Dumazet [mailto:eric.duma...@gmail.com] > Sent: Wednesday, December 03, 2014 2:08 PM [...] > Better performance for what workload exactly ? I test it by using Chariot with 4 Tx and 4 Rx. It has about 4% improvement. > cloning in rx path has many drawbacks, with skb->truesize > being usually wrong. Excuse me. I find the skb_clone() would copy the truesize from original skb. Do you mean the value may not be suitable for the cloned skb? Could other method do the same thing? Or, do you think keeping the original one is better? Best Regards, Hayes -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Is this 32-bit NCM?
No problems. I remain there - for anything. Especially because if we collaborate and are able to find a good solution to this problem, then it is so much better for all. Tell me if I can do something useful or try something useful... Enrico On Wed, 3 Dec 2014, Kevin Zhu wrote: ==Date: Wed, 3 Dec 2014 07:05:37 ==From: Kevin Zhu ==To: Enrico Mioso ==Cc: Bjørn Mork , Eli Britstein , ==Alex Strizhevsky , ==Midge Shaojun Tan , =="you...@gmail.com" , =="linux-usb@vger.kernel.org" , =="net...@vger.kernel.org" ==Subject: Re: Is this 32-bit NCM? == ==OK. I will. Thank you for everything! == ==Regards, ==Kevin == ==On 12/03/2014 02:00 PM, Enrico Mioso wrote: ==> Yes - I think this would be ok. You might try this with the 16-bit river first, ==> and then with the 32-bit one to see how things work. ==> I hope for the best. ==> Let us all know, ==> Enrico ==> ==> ==> On Wed, 3 Dec 2014, Kevin Zhu wrote: ==> ==> ==Date: Wed, 3 Dec 2014 06:38:27 ==> ==From: Kevin Zhu ==> ==To: Enrico Mioso ==> ==Cc: Bjørn Mork , Eli Britstein , ==> ==Alex Strizhevsky , ==> ==Midge Shaojun Tan , ==> =="you...@gmail.com" , ==> =="linux-usb@vger.kernel.org" , ==> =="net...@vger.kernel.org" ==> ==Subject: Re: Is this 32-bit NCM? ==> == ==> ==My dongle also works with the huawei driver. I think only the 32bit ==> ==format and NDP location matter. We may modify the TX function to put NTH ==> ==and NDP at the beginning of a NTB and see if it will work with the ==> ==driver cdc_ncm. ==> == ==> ==Regards, ==> ==Kevin ==> == ==> ==On 12/02/2014 11:28 PM, Enrico Mioso wrote: ==> ==> ... And what do you think about the source code of their ndis driver? ==> ==> We at least know now the device work with it, so we have something to mimic :D ==> ==> thank you for your work and patience Kevin. ==> ==> ==> ==> On Tue, 2 Dec 2014, Kevin Zhu wrote: ==> ==> ==> ==> ==Date: Tue, 2 Dec 2014 16:04:25 ==> ==> ==From: Kevin Zhu ==> ==> ==To: Enrico Mioso , Bjørn Mork ==> ==> ==Cc: Eli Britstein , ==> ==> ==Alex Strizhevsky , ==> ==> ==Midge Shaojun Tan , ==> ==> =="you...@gmail.com" , ==> ==> =="linux-usb@vger.kernel.org" , ==> ==> =="net...@vger.kernel.org" ==> ==> ==Subject: Re: Is this 32-bit NCM? ==> ==> == ==> ==> ==I do not understand why the wSequence matters. By the way, I think I see some NDPs are right after NTH headers in the windows capture. ==> ==> == ==> ==> == ==> ==> ==From: Enrico Mioso ==> ==> ==Sent: Tuesday, December 2, 2014 21:53 ==> ==> ==To: Bjørn Mork ==> ==> ==Cc: Kevin Zhu; Eli Britstein; Alex Strizhevsky; Midge Shaojun Tan; you...@gmail.com; linux-usb@vger.kernel.org; net...@vger.kernel.org ==> ==> ==Subject: Re: Is this 32-bit NCM? ==> ==> == ==> ==> ==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 ==> ==> To: Enrico Mioso ==> ==> Cc: Kevin Zhu , ==> ==> Eli Britstein , ==> ==> Alex Strizhevsky , ==> ==> Midge Shaojun Tan , ==> ==> "you...@gmail.com" , ==> ==> "linux-usb@vger.kernel.org" , ==> ==> "net...@vger.kernel.org" ==> ==> Subject: Re: Is this 32-bit NCM? ==> ==> ==> ==> Enrico Mioso 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 ==> ==> ==> ==> ==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
Re: [PATCH net-next] r8152: reduce memory copy for rx
On Wed, 2014-12-03 at 13:14 +0800, Hayes Wang wrote: > If the data size is more than half of the AGG_BUG_SZ, allocate a new > rx buffer and use skb_clone() to avoid the memory copy. > > The original method is that allocate the memory and copy data for each > packet in a rx buffer. The new one is that when the data size for a rx > buffer is more than RX_THRESHOLD_CLONED, allocate a new rx buffer and > use skb_clone for each packet in the rx buffer. According to the > experiment, the new mothod has better performance. Better performance for what workload exactly ? cloning in rx path has many drawbacks, with skb->truesize being usually wrong. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Is this 32-bit NCM?
OK. I will. Thank you for everything! Regards, Kevin On 12/03/2014 02:00 PM, Enrico Mioso wrote: > Yes - I think this would be ok. You might try this with the 16-bit river > first, > and then with the 32-bit one to see how things work. > I hope for the best. > Let us all know, > Enrico > > > On Wed, 3 Dec 2014, Kevin Zhu wrote: > > ==Date: Wed, 3 Dec 2014 06:38:27 > ==From: Kevin Zhu > ==To: Enrico Mioso > ==Cc: Bjørn Mork , Eli Britstein > , > ==Alex Strizhevsky , > ==Midge Shaojun Tan , > =="you...@gmail.com" , > =="linux-usb@vger.kernel.org" , > =="net...@vger.kernel.org" > ==Subject: Re: Is this 32-bit NCM? > == > ==My dongle also works with the huawei driver. I think only the 32bit > ==format and NDP location matter. We may modify the TX function to put NTH > ==and NDP at the beginning of a NTB and see if it will work with the > ==driver cdc_ncm. > == > ==Regards, > ==Kevin > == > ==On 12/02/2014 11:28 PM, Enrico Mioso wrote: > ==> ... And what do you think about the source code of their ndis driver? > ==> We at least know now the device work with it, so we have something to > mimic :D > ==> thank you for your work and patience Kevin. > ==> > ==> On Tue, 2 Dec 2014, Kevin Zhu wrote: > ==> > ==> ==Date: Tue, 2 Dec 2014 16:04:25 > ==> ==From: Kevin Zhu > ==> ==To: Enrico Mioso , Bjørn Mork > ==> ==Cc: Eli Britstein , > ==> ==Alex Strizhevsky , > ==> ==Midge Shaojun Tan , > ==> =="you...@gmail.com" , > ==> =="linux-usb@vger.kernel.org" , > ==> =="net...@vger.kernel.org" > ==> ==Subject: Re: Is this 32-bit NCM? > ==> == > ==> ==I do not understand why the wSequence matters. By the way, I think I > see some NDPs are right after NTH headers in the windows capture. > ==> == > ==> == > ==> ==From: Enrico Mioso > ==> ==Sent: Tuesday, December 2, 2014 21:53 > ==> ==To: Bjørn Mork > ==> ==Cc: Kevin Zhu; Eli Britstein; Alex Strizhevsky; Midge Shaojun Tan; > you...@gmail.com; linux-usb@vger.kernel.org; net...@vger.kernel.org > ==> ==Subject: Re: Is this 32-bit NCM? > ==> == > ==> ==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 > ==> To: Enrico Mioso > ==> Cc: Kevin Zhu , > ==> Eli Britstein , > ==> Alex Strizhevsky , > ==> Midge Shaojun Tan , > ==> "you...@gmail.com" , > ==> "linux-usb@vger.kernel.org" , > ==> "net...@vger.kernel.org" > ==> Subject: Re: Is this 32-bit NCM? > ==> > ==> Enrico Mioso 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 > ==> > ==> ==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 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel
Re: Is this 32-bit NCM?
Yes - I think this would be ok. You might try this with the 16-bit river first, and then with the 32-bit one to see how things work. I hope for the best. Let us all know, Enrico On Wed, 3 Dec 2014, Kevin Zhu wrote: ==Date: Wed, 3 Dec 2014 06:38:27 ==From: Kevin Zhu ==To: Enrico Mioso ==Cc: Bjørn Mork , Eli Britstein , ==Alex Strizhevsky , ==Midge Shaojun Tan , =="you...@gmail.com" , =="linux-usb@vger.kernel.org" , =="net...@vger.kernel.org" ==Subject: Re: Is this 32-bit NCM? == ==My dongle also works with the huawei driver. I think only the 32bit ==format and NDP location matter. We may modify the TX function to put NTH ==and NDP at the beginning of a NTB and see if it will work with the ==driver cdc_ncm. == ==Regards, ==Kevin == ==On 12/02/2014 11:28 PM, Enrico Mioso wrote: ==> ... And what do you think about the source code of their ndis driver? ==> We at least know now the device work with it, so we have something to mimic :D ==> thank you for your work and patience Kevin. ==> ==> On Tue, 2 Dec 2014, Kevin Zhu wrote: ==> ==> ==Date: Tue, 2 Dec 2014 16:04:25 ==> ==From: Kevin Zhu ==> ==To: Enrico Mioso , Bjørn Mork ==> ==Cc: Eli Britstein , ==> ==Alex Strizhevsky , ==> ==Midge Shaojun Tan , ==> =="you...@gmail.com" , ==> =="linux-usb@vger.kernel.org" , ==> =="net...@vger.kernel.org" ==> ==Subject: Re: Is this 32-bit NCM? ==> == ==> ==I do not understand why the wSequence matters. By the way, I think I see some NDPs are right after NTH headers in the windows capture. ==> == ==> == ==> ==From: Enrico Mioso ==> ==Sent: Tuesday, December 2, 2014 21:53 ==> ==To: Bjørn Mork ==> ==Cc: Kevin Zhu; Eli Britstein; Alex Strizhevsky; Midge Shaojun Tan; you...@gmail.com; linux-usb@vger.kernel.org; net...@vger.kernel.org ==> ==Subject: Re: Is this 32-bit NCM? ==> == ==> ==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 ==> To: Enrico Mioso ==> Cc: Kevin Zhu , ==> Eli Britstein , ==> Alex Strizhevsky , ==> Midge Shaojun Tan , ==> "you...@gmail.com" , ==> "linux-usb@vger.kernel.org" , ==> "net...@vger.kernel.org" ==> Subject: Re: Is this 32-bit NCM? ==> ==> Enrico Mioso 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 ==> ==> ==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 ==
Re: [PATCH] arm: omap3: twl: remove usb phy init data
Hi Greg,
On Monday 01 December 2014 02:14 PM, Kishon Vijay Abraham I wrote:
> From: Heikki Krogerus
>
> The driver does no use it any more.
>
> Signed-off-by: Heikki Krogerus
> Signed-off-by: Kishon Vijay Abraham I
This patch is required to get rid of the error that Stephen Rothwell reported.
Thanks
Kishon
> ---
> While this patch was part of the original series sent by Heikki, I couldn't
> get Ack from Tony to be merged this in my tree and I failed to catch the
> build error during my testing :-(
>
> This patch should fix the error pointed out by Stephen Rothwell.
> arch/arm/mach-omap2/twl-common.c:94:21: error: array type has incomplete
> element type
> struct phy_consumer consumers[] = {
> ^
> arch/arm/mach-omap2/twl-common.c | 12 +---
> include/linux/i2c/twl.h | 2 --
> 2 files changed, 1 insertion(+), 13 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/twl-common.c
> b/arch/arm/mach-omap2/twl-common.c
> index b0d54da..4457e73 100644
> --- a/arch/arm/mach-omap2/twl-common.c
> +++ b/arch/arm/mach-omap2/twl-common.c
> @@ -91,18 +91,8 @@ void __init omap_pmic_late_init(void)
> }
>
> #if defined(CONFIG_ARCH_OMAP3)
> -struct phy_consumer consumers[] = {
> - PHY_CONSUMER("musb-hdrc.0", "usb"),
> -};
> -
> -struct phy_init_data init_data = {
> - .consumers = consumers,
> - .num_consumers = ARRAY_SIZE(consumers),
> -};
> -
> static struct twl4030_usb_data omap3_usb_pdata = {
> - .usb_mode = T2_USB_MODE_ULPI,
> - .init_data = &init_data,
> + .usb_mode = T2_USB_MODE_ULPI,
> };
>
> static int omap3_batt_table[] = {
> diff --git a/include/linux/i2c/twl.h b/include/linux/i2c/twl.h
> index 8cfb50f..0bc03f1 100644
> --- a/include/linux/i2c/twl.h
> +++ b/include/linux/i2c/twl.h
> @@ -26,7 +26,6 @@
> #define __TWL_H_
>
> #include
> -#include
> #include
>
> /*
> @@ -634,7 +633,6 @@ enum twl4030_usb_mode {
> struct twl4030_usb_data {
> enum twl4030_usb_mode usb_mode;
> unsigned long features;
> - struct phy_init_data*init_data;
>
> int (*phy_init)(struct device *dev);
> int (*phy_exit)(struct device *dev);
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Is this 32-bit NCM?
My dongle also works with the huawei driver. I think only the 32bit format and NDP location matter. We may modify the TX function to put NTH and NDP at the beginning of a NTB and see if it will work with the driver cdc_ncm. Regards, Kevin On 12/02/2014 11:28 PM, Enrico Mioso wrote: > ... And what do you think about the source code of their ndis driver? > We at least know now the device work with it, so we have something to mimic :D > thank you for your work and patience Kevin. > > On Tue, 2 Dec 2014, Kevin Zhu wrote: > > ==Date: Tue, 2 Dec 2014 16:04:25 > ==From: Kevin Zhu > ==To: Enrico Mioso , Bjørn Mork > ==Cc: Eli Britstein , > ==Alex Strizhevsky , > ==Midge Shaojun Tan , > =="you...@gmail.com" , > =="linux-usb@vger.kernel.org" , > =="net...@vger.kernel.org" > ==Subject: Re: Is this 32-bit NCM? > == > ==I do not understand why the wSequence matters. By the way, I think I see > some NDPs are right after NTH headers in the windows capture. > == > == > ==From: Enrico Mioso > ==Sent: Tuesday, December 2, 2014 21:53 > ==To: Bjørn Mork > ==Cc: Kevin Zhu; Eli Britstein; Alex Strizhevsky; Midge Shaojun Tan; > you...@gmail.com; linux-usb@vger.kernel.org; net...@vger.kernel.org > ==Subject: Re: Is this 32-bit NCM? > == > ==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 > To: Enrico Mioso > Cc: Kevin Zhu , > Eli Britstein , > Alex Strizhevsky , > Midge Shaojun Tan , > "you...@gmail.com" , > "linux-usb@vger.kernel.org" , > "net...@vger.kernel.org" > Subject: Re: Is this 32-bit NCM? > > Enrico Mioso 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 > > ==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 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-next] r8152: reduce memory copy for rx
If the data size is more than half of the AGG_BUG_SZ, allocate a new
rx buffer and use skb_clone() to avoid the memory copy.
The original method is that allocate the memory and copy data for each
packet in a rx buffer. The new one is that when the data size for a rx
buffer is more than RX_THRESHOLD_CLONED, allocate a new rx buffer and
use skb_clone for each packet in the rx buffer. According to the
experiment, the new mothod has better performance.
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 110 +---
1 file changed, 77 insertions(+), 33 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 4a9ece0..e44b9fb 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -26,7 +26,7 @@
#include
/* Version Information */
-#define DRIVER_VERSION "v1.07.0 (2014/10/09)"
+#define DRIVER_VERSION "v1.08.0 (2014/11/27)"
#define DRIVER_AUTHOR "Realtek linux nic maintainers "
#define DRIVER_DESC "Realtek RTL8152/RTL8153 Based USB Ethernet Adapters"
#define MODULENAME "r8152"
@@ -447,6 +447,8 @@ enum rtl_register_content {
#define RTL8152_RMS(VLAN_ETH_FRAME_LEN + VLAN_HLEN)
#define RTL8153_RMSRTL8153_MAX_PACKET
#define RTL8152_TX_TIMEOUT (5 * HZ)
+#define AGG_BUF_SZ 16384 /* 16K */
+#define RX_THRESHOLD_CLONED(AGG_BUF_SZ / 2)
/* rtl8152 flags */
enum rtl8152_flags {
@@ -534,8 +536,7 @@ struct rx_agg {
struct list_head list;
struct urb *urb;
struct r8152 *context;
- void *buffer;
- void *head;
+ struct sk_buff *skb;
};
struct tx_agg {
@@ -605,9 +606,8 @@ enum tx_csum_stat {
* The RTL chips use a 64 element hash table based on the Ethernet CRC.
*/
static const int multicast_filter_limit = 32;
-static unsigned int agg_buf_sz = 16384;
-#define RTL_LIMITED_TSO_SIZE (agg_buf_sz - sizeof(struct tx_desc) - \
+#define RTL_LIMITED_TSO_SIZE (AGG_BUF_SZ - sizeof(struct tx_desc) - \
VLAN_ETH_HLEN - VLAN_HLEN)
static
@@ -1210,9 +1210,8 @@ static void free_all_mem(struct r8152 *tp)
usb_free_urb(tp->rx_info[i].urb);
tp->rx_info[i].urb = NULL;
- kfree(tp->rx_info[i].buffer);
- tp->rx_info[i].buffer = NULL;
- tp->rx_info[i].head = NULL;
+ dev_kfree_skb(tp->rx_info[i].skb);
+ tp->rx_info[i].skb = NULL;
}
for (i = 0; i < RTL8152_MAX_TX; i++) {
@@ -1231,6 +1230,31 @@ static void free_all_mem(struct r8152 *tp)
tp->intr_buff = NULL;
}
+static struct sk_buff *rtl_alloc_rx_skb(struct r8152 *tp, gfp_t gfp_mask)
+{
+ struct net_device *netdev = tp->netdev;
+ struct sk_buff *skb;
+
+ skb = __netdev_alloc_skb(netdev, AGG_BUF_SZ, gfp_mask);
+ if (!skb)
+ goto out1;
+
+ if (skb->data != rx_agg_align(skb->data)) {
+ int rl;
+
+ dev_kfree_skb_any(skb);
+ skb = __netdev_alloc_skb(netdev, AGG_BUF_SZ + RX_ALIGN,
+gfp_mask);
+ if (!skb)
+ goto out1;
+
+ rl = (int)(rx_agg_align(skb->data) - (void *)skb->data);
+ skb_reserve(skb, rl);
+ }
+out1:
+ return skb;
+}
+
static int alloc_all_mem(struct r8152 *tp)
{
struct net_device *netdev = tp->netdev;
@@ -1239,7 +1263,6 @@ static int alloc_all_mem(struct r8152 *tp)
struct usb_host_endpoint *ep_intr = alt->endpoint + 2;
struct urb *urb;
int node, i;
- u8 *buf;
node = netdev->dev.parent ? dev_to_node(netdev->dev.parent) : -1;
@@ -1249,39 +1272,33 @@ static int alloc_all_mem(struct r8152 *tp)
skb_queue_head_init(&tp->tx_queue);
for (i = 0; i < RTL8152_MAX_RX; i++) {
- buf = kmalloc_node(agg_buf_sz, GFP_KERNEL, node);
- if (!buf)
- goto err1;
+ struct sk_buff *skb;
- if (buf != rx_agg_align(buf)) {
- kfree(buf);
- buf = kmalloc_node(agg_buf_sz + RX_ALIGN, GFP_KERNEL,
- node);
- if (!buf)
- goto err1;
- }
+ skb = rtl_alloc_rx_skb(tp, GFP_KERNEL);
+ if (!skb)
+ goto err1;
urb = usb_alloc_urb(0, GFP_KERNEL);
if (!urb) {
- kfree(buf);
+ dev_kfree_skb(skb);
goto err1;
}
INIT_LIST_HEAD(&tp->rx_info[i].list);
tp->rx_info[i].context = tp;
tp->rx_info[i].urb = urb;
- tp->rx_info[i].buffer = buf;
- tp->rx_info[i].head = rx_agg_align(buf);
+ tp->rx_info[i].skb = skb;
}
for (i = 0; i < R
Re: [PATCH 8/8] wusb: replace memset by memzero_explicit
On 12/03/2014 01:14 AM, Greg Kroah-Hartman wrote:
On Sun, Nov 30, 2014 at 05:59:34PM +0100, Julia Lawall wrote:
From: Julia Lawall
Memset on a local variable may be removed when it is called just before the
variable goes out of scope. Using memzero_explicit defeats this
optimization. A simplified version of the semantic patch that makes this
change is as follows: (http://coccinelle.lip6.fr/)
//
@@
identifier x;
type T;
@@
{
... when any
T x[...];
... when any
when exists
- memset
+ memzero_explicit
(x,
-0,
...)
... when != x
when strict
}
//
This change was suggested by Daniel Borkmann
Signed-off-by: Julia Lawall
---
Daniel Borkmann suggested that these patches could go through Herbert Xu's
cryptodev tree.
Why? There's no dependancy on anything in the cryptodev tree,
memzero_explicit is in Linus's tree now.
Sorry, I guess this was not really clear, that comment actually only
refers to the arch/*/crypto/ patches.
Anyway, thanks for queueing this up, Greg.
Cheers,
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 8/8] wusb: replace memset by memzero_explicit
On Sun, Nov 30, 2014 at 05:59:34PM +0100, Julia Lawall wrote:
> From: Julia Lawall
>
> Memset on a local variable may be removed when it is called just before the
> variable goes out of scope. Using memzero_explicit defeats this
> optimization. A simplified version of the semantic patch that makes this
> change is as follows: (http://coccinelle.lip6.fr/)
>
> //
> @@
> identifier x;
> type T;
> @@
>
> {
> ... when any
> T x[...];
> ... when any
> when exists
> - memset
> + memzero_explicit
> (x,
> -0,
> ...)
> ... when != x
> when strict
> }
> //
>
> This change was suggested by Daniel Borkmann
>
> Signed-off-by: Julia Lawall
>
> ---
> Daniel Borkmann suggested that these patches could go through Herbert Xu's
> cryptodev tree.
Why? There's no dependancy on anything in the cryptodev tree,
memzero_explicit is in Linus's tree now.
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2] usb: {ohci,ehci}-platform: Use new OF big-endian helper function
On Thu, Nov 27, 2014 at 08:43:43PM -0800, Kevin Cernekee wrote: > This handles the existing "big-endian" case, and in addition, it also does > the right thing when "native-endian" is specified. > > Signed-off-by: Kevin Cernekee > Acked-by: Alan Stern > --- > Documentation/devicetree/bindings/usb/usb-ehci.txt | 2 ++ > Documentation/devicetree/bindings/usb/usb-ohci.txt | 2 ++ > drivers/usb/host/ehci-platform.c | 2 +- > drivers/usb/host/ohci-platform.c | 2 +- > 4 files changed, 6 insertions(+), 2 deletions(-) > > > V1->V2: Tweak documentation per feedback on the list > > This depends on the new of_device_is_big_endian() function, which is being > handled through Grant's tree. Feel free to take this one through Grant's tree too: Acked-by: Greg Kroah-Hartman -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
USB 3.0 drive crashes system when plugged in - regression
Hi, After upgrade to Fedora 21 with 3.17.3-300.fc21.x86_64 (from 3.14.x in Fedora 19) my USB 3.0 drive (Seagate Backup+ 1TB) stopped working with USB 3.0 port (works fine with USB 2.0 port). When plug in for the first time (USB 3.0 port) I see in log: > kernel: xhci_hcd :04:00.0: ERROR Transfer event for disabled endpoint or > incorrect stream ring > kernel: xhci_hcd :04:00.0: @000241eec570 11979000 0002 0500 > 01078001 On the second try system crashes: > kernel: kernel BUG at block/blk-core.c:2565! > -- Reboot -- I had no problems with kernel 3.14 on the same hardware. USB 2.0 pendrives work fine with that USB 3.0 port. Asus N43SN. > $ lspci | grep USB > 00:1a.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family > USB Enhanced Host Controller #2 (rev 05) > 00:1d.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family > USB Enhanced Host Controller #1 (rev 05) > 04:00.0 USB controller: Fresco Logic FL1000G USB 3.0 Host Controller (rev 04) I reported that issue some time ago in Fedora/RedHat bugzilla (https://bugzilla.redhat.com/show_bug.cgi?id=1164945) with full logs, but I wonder if it is a known problem (I haven't found similar open issues for 3.17) or maybe there is a patch I could test? Marcin -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: randconfig build error with next-20141201, in drivers/usb/musb/tusb6010.c
Hi, On Tue, Dec 02, 2014 at 10:13:16AM -0800, Greg Kroah-Hartman wrote: > On Mon, Dec 01, 2014 at 10:00:35AM -0700, Jim Davis wrote: > > Building with the attached random configuration file, > > > > drivers/built-in.o: In function `tusb_remove': > > tusb6010.c:(.text+0x16a817): undefined reference to > > `usb_phy_generic_unregister' > > drivers/built-in.o: In function `tusb_probe': > > tusb6010.c:(.text+0x16b24e): undefined reference to > > `usb_phy_generic_register' > > make: *** [vmlinux] Error 1 > > This looks like a phy issue, Kishon and Heikki? Tony Lindgren sent a patch adding a few dependencies to MUSB's Kconfig. This bug has been there forever though, so I'll merge Tony's fix during 3.19-rc1. No clue how come I never got this as I always run 300 randconfigs on my pull requests before sending them to you. -- balbi signature.asc Description: Digital signature
Re: [PATCH V6 05/12] mailbox: Add NVIDIA Tegra XUSB mailbox driver
On Tue, Dec 2, 2014 at 1:47 AM, Thierry Reding wrote: > On Mon, Nov 24, 2014 at 04:17:17PM -0800, Andrew Bresticker wrote: >> The Tegra xHCI controller's firmware communicates requests to the host >> processor through a mailbox interface. While there is only a single >> physical channel, messages sent by the controller can be divided >> into two groups: those intended for the PHY driver and those intended >> for the host-controller driver. The requesting driver is assigned >> one of two virtual channels when the single physical channel is >> requested. All incoming messages are sent to both virtual channels. >> >> Signed-off-by: Andrew Bresticker >> Reviewed-by: Stephen Warren >> --- >> Thierry, >> >> I've left this as a separate driver because I don't think it should be >> combined with the xHCI host. Stephen and I discussed this earlier in >> review of v1 of this series and he agreed that the mailbox belongs in >> its own DT node and driver. > > My objection wasn't strictly against merging the drivers. What I don't > want to see is two devices sharing the same memory-mapped regions in DT. > > That's based on earlier discussion with Stephen as well, because we have > had the same problem with USB and USB-PHY before. Unless I completely > misinterpreted we came to the conclusion that we should avoid this in > the future. Yes, I understand your objection to having multiple drivers map the same IO memory, however Stephen and I discussed this before [1] and came to the conclusion that, although mapping the MMIO region in both drivers was non-ideal, the alternatives had their own drawbacks as well and that the approach I had taken was fine. > Like I said, this doesn't mean that both need to be in the same driver. > We could use MFD for example, or provide an entry point in the mailbox > driver that can be called from the XUSB driver to instantiate the > mailbox (which is really the same as MFD). This does not look like the typical MFD, but I would agree that it's the only reasonable alternative. If Lee is fine with it, then I suppose I could go the MFD route... Lee: for context, the mailbox registers live in one of the host-controller's MMIO regions - there are no other shared resources. This has been discussed, along with a possible binding, in [1] as well. [1] https://lkml.org/lkml/2014/8/27/727 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] USB driver fixes for 3.18-rc7
On Sun, Nov 30, 2014 at 11:47:20AM -0800, Linus Torvalds wrote: > Hmm, Greg. > > I seem to get this problem possibly more commonly at boot these days: > > usb 1-6: new full-speed USB device number 2 using xhci_hcd > usb 1-6: device descriptor read/64, error -71 > xhci_hcd :00:14.0: Setup ERROR: setup context command for slot 1. > usb 1-6: hub failed to enable device, error -22 > usb 1-6: new full-speed USB device number 3 using xhci_hcd > usb 1-6: device descriptor read/64, error -71 > usb 1-6: hub failed to enable device, error -22 > usb 1-6: new full-speed USB device number 4 using xhci_hcd > usb 1-6: Device not responding to setup address. > usb 1-6: Device not responding to setup address. > usb 1-6: device not accepting address 4, error -71 > usb 1-6: new full-speed USB device number 5 using xhci_hcd > usb 1-6: Device not responding to setup address. > usb 1-6: Device not responding to setup address. > usb 1-6: device not accepting address 5, error -71 > usb usb1-port6: unable to enumerate USB device > > and my keyboard doesn't work. I then unplug and re-plug it, and get > > usb 1-6: new full-speed USB device number 9 using xhci_hcd > usb 1-6: New USB device found, idVendor=2516, idProduct=0020 > usb 1-6: New USB device strings: Mfr=1, Product=2, SerialNumber=0 > usb 1-6: Product: Quickfire Rapid i > usb 1-6: Manufacturer: CM Storm > > Any ideas? Some setup delay that isn't long enough at boot time for a > slightly finicky device? It has happened before, but now I've gotten > it twice within a couple of days: > > Nov 02 12:18:56 i7.lan kernel: usb 1-6: device descriptor read/64, error -71 > Nov 28 16:54:06 i7.lan kernel: usb 1-6: device descriptor read/64, error -71 > Nov 30 11:26:35 i7.lan kernel: usb 1-6: device descriptor read/64, error -71 > > (I've had this keyboard since mid-September, and looking at the logs > this machine has been rebooted 41 times since, with those three > failures..) I've been seeing this occasionally recently as well, but was blaming a "bad" USB 3 hub I have here that I use, and the problem goes away with a replug. Mathias, any ideas what is going on here? thanks, greg k-h > > Linus -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: randconfig build error with next-20141201, in drivers/usb/musb/tusb6010.c
On Mon, Dec 01, 2014 at 10:00:35AM -0700, Jim Davis wrote: > Building with the attached random configuration file, > > drivers/built-in.o: In function `tusb_remove': > tusb6010.c:(.text+0x16a817): undefined reference to > `usb_phy_generic_unregister' > drivers/built-in.o: In function `tusb_probe': > tusb6010.c:(.text+0x16b24e): undefined reference to `usb_phy_generic_register' > make: *** [vmlinux] Error 1 This looks like a phy issue, Kishon and Heikki? > # > # Automatically generated file; DO NOT EDIT. > # Linux/x86 3.18.0-rc6 Kernel Configuration > # > CONFIG_64BIT=y > CONFIG_X86_64=y > CONFIG_X86=y > CONFIG_INSTRUCTION_DECODER=y > CONFIG_OUTPUT_FORMAT="elf64-x86-64" > CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig" > CONFIG_LOCKDEP_SUPPORT=y > CONFIG_STACKTRACE_SUPPORT=y > CONFIG_HAVE_LATENCYTOP_SUPPORT=y > CONFIG_MMU=y > CONFIG_NEED_DMA_MAP_STATE=y > CONFIG_NEED_SG_DMA_LENGTH=y > CONFIG_GENERIC_ISA_DMA=y > CONFIG_GENERIC_BUG=y > CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y > CONFIG_GENERIC_HWEIGHT=y > CONFIG_ARCH_MAY_HAVE_PC_FDC=y > CONFIG_RWSEM_XCHGADD_ALGORITHM=y > CONFIG_GENERIC_CALIBRATE_DELAY=y > CONFIG_ARCH_HAS_CPU_RELAX=y > CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y > CONFIG_HAVE_SETUP_PER_CPU_AREA=y > CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y > CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y > CONFIG_ARCH_HIBERNATION_POSSIBLE=y > CONFIG_ARCH_SUSPEND_POSSIBLE=y > CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y > CONFIG_ARCH_WANT_GENERAL_HUGETLB=y > CONFIG_ZONE_DMA32=y > CONFIG_AUDIT_ARCH=y > CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y > CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y > CONFIG_X86_INTEL_MPX=y > CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi > -fcall-saved-rdx -fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 > -fcall-saved-r10 -fcall-saved-r11" > CONFIG_ARCH_SUPPORTS_UPROBES=y > CONFIG_FIX_EARLYCON_MEM=y > CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" > CONFIG_IRQ_WORK=y > CONFIG_BUILDTIME_EXTABLE_SORT=y > > # > # General setup > # > CONFIG_BROKEN_ON_SMP=y > CONFIG_INIT_ENV_ARG_LIMIT=32 > CONFIG_CROSS_COMPILE="" > CONFIG_COMPILE_TEST=y > CONFIG_LOCALVERSION="" > # CONFIG_LOCALVERSION_AUTO is not set > CONFIG_HAVE_KERNEL_GZIP=y > CONFIG_HAVE_KERNEL_BZIP2=y > CONFIG_HAVE_KERNEL_LZMA=y > CONFIG_HAVE_KERNEL_XZ=y > CONFIG_HAVE_KERNEL_LZO=y > CONFIG_HAVE_KERNEL_LZ4=y > CONFIG_KERNEL_GZIP=y > # CONFIG_KERNEL_BZIP2 is not set > # CONFIG_KERNEL_LZMA is not set > # CONFIG_KERNEL_XZ is not set > # CONFIG_KERNEL_LZO is not set > # CONFIG_KERNEL_LZ4 is not set > CONFIG_DEFAULT_HOSTNAME="(none)" > CONFIG_SWAP=y > CONFIG_SYSVIPC=y > CONFIG_SYSVIPC_SYSCTL=y > # CONFIG_POSIX_MQUEUE is not set > # CONFIG_CROSS_MEMORY_ATTACH is not set > # CONFIG_FHANDLE is not set > # CONFIG_USELIB is not set > CONFIG_AUDIT=y > CONFIG_HAVE_ARCH_AUDITSYSCALL=y > CONFIG_AUDITSYSCALL=y > CONFIG_AUDIT_WATCH=y > CONFIG_AUDIT_TREE=y > > # > # IRQ subsystem > # > CONFIG_GENERIC_IRQ_PROBE=y > CONFIG_GENERIC_IRQ_SHOW=y > CONFIG_GENERIC_IRQ_LEGACY_ALLOC_HWIRQ=y > CONFIG_IRQ_DOMAIN=y > CONFIG_IRQ_DOMAIN_DEBUG=y > CONFIG_IRQ_FORCED_THREADING=y > CONFIG_SPARSE_IRQ=y > CONFIG_CLOCKSOURCE_WATCHDOG=y > CONFIG_ARCH_CLOCKSOURCE_DATA=y > CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y > CONFIG_GENERIC_TIME_VSYSCALL=y > CONFIG_GENERIC_CLOCKEVENTS=y > CONFIG_GENERIC_CLOCKEVENTS_BUILD=y > CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y > CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y > CONFIG_GENERIC_CMOS_UPDATE=y > > # > # Timers subsystem > # > CONFIG_HZ_PERIODIC=y > # CONFIG_NO_HZ_IDLE is not set > # CONFIG_NO_HZ is not set > # CONFIG_HIGH_RES_TIMERS is not set > > # > # CPU/Task time and stats accounting > # > CONFIG_TICK_CPU_ACCOUNTING=y > # CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set > # CONFIG_IRQ_TIME_ACCOUNTING is not set > # CONFIG_BSD_PROCESS_ACCT is not set > CONFIG_TASKSTATS=y > CONFIG_TASK_DELAY_ACCT=y > CONFIG_TASK_XACCT=y > # CONFIG_TASK_IO_ACCOUNTING is not set > > # > # RCU Subsystem > # > CONFIG_TINY_RCU=y > CONFIG_TASKS_RCU=y > # CONFIG_RCU_STALL_COMMON is not set > # CONFIG_TREE_RCU_TRACE is not set > CONFIG_BUILD_BIN2C=y > CONFIG_IKCONFIG=y > CONFIG_IKCONFIG_PROC=y > CONFIG_LOG_BUF_SHIFT=17 > CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y > CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y > CONFIG_ARCH_SUPPORTS_INT128=y > CONFIG_CGROUPS=y > # CONFIG_CGROUP_DEBUG is not set > CONFIG_CGROUP_FREEZER=y > CONFIG_CGROUP_DEVICE=y > CONFIG_CPUSETS=y > # CONFIG_PROC_PID_CPUSET is not set > CONFIG_CGROUP_CPUACCT=y > CONFIG_PAGE_COUNTER=y > CONFIG_MEMCG=y > # CONFIG_MEMCG_SWAP is not set > CONFIG_MEMCG_KMEM=y > CONFIG_CGROUP_HUGETLB=y > CONFIG_CGROUP_PERF=y > CONFIG_CGROUP_SCHED=y > CONFIG_FAIR_GROUP_SCHED=y > CONFIG_CFS_BANDWIDTH=y > # CONFIG_RT_GROUP_SCHED is not set > # CONFIG_BLK_CGROUP is not set > # CONFIG_CHECKPOINT_RESTORE is not set > CONFIG_NAMESPACES=y > CONFIG_UTS_NS=y > CONFIG_IPC_NS=y > # CONFIG_USER_NS is not set > CONFIG_PID_NS=y > # CONFIG_NET_NS is not set > CONFIG_SCHED_AUTOGROUP=y > CONFIG_SYSFS_DEPRECATED=y > # CONFIG_SYSFS_DEPRECATED_V2 is not set > C
Re: [PATCH] usb: gadget: zero: fix INT endpoint assignment
On 11/26/2014 10:40 PM, Alan Stern wrote: > On Wed, 26 Nov 2014, Sebastian Andrzej Siewior wrote: > >> On 11/26/2014 04:24 PM, Alan Stern wrote: On 11/25/2014 10:52 PM, Sebastian Andrzej Siewior wrote: > The max packet size within the FS descriptor has to be highest possible > value and _not_ the one that is (or will be) used on FS. The current code sets wMaxPacketSize of FS interrupt endpoint descriptor as 64, which is in accordance with the usb 2.0 specification, section 5.7.3 The maximum allowable interrupt data payload size is 64 bytes or less for full-speed. High-speed endpoints are allowed maximum data payload sizes up to 1024 bytes. >>> >>> The real problem is that we are assuming endpoints can be allocated in >>> a single way that will work correctly for all possible connection >>> speeds. (I suspect it was done this way out of laziness and a desire >>> to minimize the code size.) This assumption is obviously incorrect >>> when the hardware has an interrupt endpoint that supports packet sizes >>> of 64 but no larger. >> >> The code will check properly if you pass 1024 and check the size >> accordingly. You have to "downsize" your FS descriptor later. This >> function will only fail to do this if your gadget isn't dual speed. In >> that case it expects 64 as the upper limit for INT (if I recall >> correctly). > > It will also fail in situations where you use up a lot of endpoints. > For example, let's say the UDC only supports 4 endpoints, one of which > must have a maxpacket value <= 64. If you want to have four interrupt > endpoints, you can't run at high speed -- but you can run at full > speed. However, the approach you outlined above won't allow it. fair enough. So we could try to look for one with 1024 and it fails we could re-try with 512 and then 64. If all three fail we would continue without INT support. >> Ah. And endpoints are never returned to the allocator. Some gadgets set >> ->private to NULL, other just ignore it and let the core do it. So >> re-doing the endpoint allocator is probably the right thing to do. And > > The allocator doesn't need to be changed. We already have a > usb_ep_autoconfig_reset() function. yes, that one that frees them all. >> then force every gadget to allocate an endpoint for FS/HS/SS and give >> it back _and_ please edit the copy of the descriptor and not the global >> "original". > > Yes. > >> But the work will not be done before we have the next release is out >> and as of now it breaks g_zero on musb, net2280 and maybe others. > > Felipe will have to decide how to handle this. > > Alan Stern > Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: gadget: zero: fix INT endpoint assignment
On 11/25/2014 08:39 PM, Paul Zimmerman wrote:
>> diff --git a/drivers/usb/gadget/function/f_sourcesink.c
>> b/drivers/usb/gadget/function/f_sourcesink.c
>> index 80be25b32cd7..7d8f0216e1a6 100644
>> --- a/drivers/usb/gadget/function/f_sourcesink.c
>> +++ b/drivers/usb/gadget/function/f_sourcesink.c
>> @@ -161,7 +161,7 @@ static struct usb_endpoint_descriptor fs_int_source_desc
>> = {
>>
>> .bEndpointAddress = USB_DIR_IN,
>> .bmAttributes = USB_ENDPOINT_XFER_INT,
>> -.wMaxPacketSize = cpu_to_le16(64),
>> +.wMaxPacketSize = cpu_to_le16(1024),
>
> This seems strange. You are setting the max packet size in the FS Intr
> endpoint descriptor to a value that is illegal for FS. Won't that cause
> usb_ep_autoconfig() to fail if the UDC only has a FS Intr endpoint?
Funny at it is, tests have shown to work as expected. Only if UDC is FS
only then it won't pass. This could be fixed…
> Maybe you should set wMaxPacketSize to 0 instead? The ep_matches()
> function in epautoconf.c has this code:
> /*
>* If the protocol driver hasn't yet decided on wMaxPacketSize
>* and wants to know the maximum possible, provide the info.
>*/
> if (desc->wMaxPacketSize == 0)
> desc->wMaxPacketSize = cpu_to_le16(ep->maxpacket_limit);
>
This means we get most likely the smallest possible endpoint and won't
be able to perform transfers @1024 even if we would have such an
endpoint.
Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: gadget: zero: fix INT endpoint assignment
On 11/26/2014 02:08 PM, Amit Virdi wrote:
> Dear Sebastian,
Hi Amit,
> On 11/25/2014 10:52 PM, Sebastian Andrzej Siewior wrote:
>> The max packet size within the FS descriptor has to be highest possible
>> value and _not_ the one that is (or will be) used on FS.
>
> The current code sets wMaxPacketSize of FS interrupt endpoint descriptor
> as 64, which is in accordance with the usb 2.0 specification, section 5.7.3
I know about the specification. The "1024" is only used initially while
allocating endpoints. It is never passed to the host at FS.
>> The way the code works (since day 1) is that usb_ep_autoconfig() is
>> invoked _only_ on the FS endpoint and then the endpoint address is
>> copies over to HS/SS endpoints. If the any of the "critical" options are
>> different between FS and HS then we have to pass the HS value and
>> correct later.
>>
>> What now happens is that we look for an INT-OUT endpoint of 64bytes. The
>> code will return an endpoint matching this category. Further the
>> sourcesink will take this endpoint and increase the MPS to 1024. On
>
> This is valid only for HS and SS interrupt endpoints. Right?
Correct *but* the chosen endpoint may not be capable of MPS > what you
were looking for.
>> net2280 for instance the code tries to be clever to return an endpoint
>> which can only do 64 MPS. The same happens on musb where we mostlike get
>> an endpoint which can only do 512. The result is then on the host side:
>>
>
> What is the speed at which your device is operating?
HS.
>> |~# testusb -a -t 9 -c 2
>> |unknown speed /dev/bus/usb/002/0450
>> |usbtest 2-1:3.0: TEST 9: ch9 (subset) control tests, 2 times
>> |usbtest 2-1:3.0: can't set_interface = 2, -32
>> |usbtest 2-1:3.0: ch9 subset failed, iterations left 1
>> |/dev/bus/usb/002/045 test 9 --> 32 (Broken pipe)
>>
>> because the on the gadget side we can't enable the endpoint because
>> desc->size > ep->max_size.
>>
>> Fixes: ef11982dd7a6 ("usb: gadget: zero: Add support for interrupt EP")
>> Signed-off-by: Sebastian Andrzej Siewior
>> ---
>> drivers/usb/gadget/function/f_sourcesink.c | 24
>>
>> 1 file changed, 12 insertions(+), 12 deletions(-)
>>
>> diff --git a/drivers/usb/gadget/function/f_sourcesink.c
>> b/drivers/usb/gadget/function/f_sourcesink.c
>> index 80be25b32cd7..7d8f0216e1a6 100644
>> --- a/drivers/usb/gadget/function/f_sourcesink.c
>> +++ b/drivers/usb/gadget/function/f_sourcesink.c
>> @@ -161,7 +161,7 @@ static struct usb_endpoint_descriptor
>> fs_int_source_desc = {
>>
>> .bEndpointAddress =USB_DIR_IN,
>> .bmAttributes =USB_ENDPOINT_XFER_INT,
>> -.wMaxPacketSize =cpu_to_le16(64),
>> +.wMaxPacketSize =cpu_to_le16(1024),
>> .bInterval =GZERO_INT_INTERVAL,
>> };
>>
>> @@ -171,7 +171,7 @@ static struct usb_endpoint_descriptor
>> fs_int_sink_desc = {
>>
>> .bEndpointAddress =USB_DIR_OUT,
>> .bmAttributes =USB_ENDPOINT_XFER_INT,
>> -.wMaxPacketSize =cpu_to_le16(64),
>> +.wMaxPacketSize =cpu_to_le16(1024),
>> .bInterval =GZERO_INT_INTERVAL,
>> };
>>
>
> This change in wMAxPacketSize of FS interrupt descriptors is violation
> of the specs.
It is changed back before the descriptor is sent to the host.
>> @@ -556,16 +556,6 @@ sourcesink_bind(struct usb_configuration *c,
>> struct usb_function *f)
>> if (int_maxburst > 15)
>> int_maxburst = 15;
>>
>> -/* fill in the FS interrupt descriptors from the module
>> parameters */
>> -fs_int_source_desc.wMaxPacketSize = int_maxpacket > 64 ?
>> -64 : int_maxpacket;
>> -fs_int_source_desc.bInterval = int_interval > 255 ?
>> -255 : int_interval;
>> -fs_int_sink_desc.wMaxPacketSize = int_maxpacket > 64 ?
>> -64 : int_maxpacket;
>> -fs_int_sink_desc.bInterval = int_interval > 255 ?
>> -255 : int_interval;
>> -
>> /* allocate int endpoints */
>> ss->int_in_ep = usb_ep_autoconfig(cdev->gadget,
>> &fs_int_source_desc);
>> if (!ss->int_in_ep)
>> @@ -587,6 +577,16 @@ sourcesink_bind(struct usb_configuration *c,
>> struct usb_function *f)
>> if (int_maxpacket > 1024)
>> int_maxpacket = 1024;
>>
>> +/* fill in the FS interrupt descriptors from the module
>> parameters */
>> +fs_int_source_desc.wMaxPacketSize = int_maxpacket > 64 ?
>> +64 : int_maxpacket;
>> +fs_int_source_desc.bInterval = int_interval > 255 ?
>> +255 : int_interval;
>> +fs_int_sink_desc.wMaxPacketSize = int_maxpacket > 64 ?
>> +64 : int_maxpacket;
>> +fs_int_sink_desc.bInterval = int_interval > 255 ?
>> +255 : int_interval;
>> +
>> /* support high speed hardware */
>> hs_source_desc.bEndpointAddress = fs_source_desc.bEndpointAddress;
>> hs_sink_desc.bEndpointAddress = fs_sink_desc.bE
Re: Is this 32-bit NCM?
... And what do you think about the source code of their ndis driver? We at least know now the device work with it, so we have something to mimic :D thank you for your work and patience Kevin. On Tue, 2 Dec 2014, Kevin Zhu wrote: ==Date: Tue, 2 Dec 2014 16:04:25 ==From: Kevin Zhu ==To: Enrico Mioso , Bjørn Mork ==Cc: Eli Britstein , ==Alex Strizhevsky , ==Midge Shaojun Tan , =="you...@gmail.com" , =="linux-usb@vger.kernel.org" , =="net...@vger.kernel.org" ==Subject: Re: Is this 32-bit NCM? == ==I do not understand why the wSequence matters. By the way, I think I see some NDPs are right after NTH headers in the windows capture. == == ==From: Enrico Mioso ==Sent: Tuesday, December 2, 2014 21:53 ==To: Bjørn Mork ==Cc: Kevin Zhu; Eli Britstein; Alex Strizhevsky; Midge Shaojun Tan; you...@gmail.com; linux-usb@vger.kernel.org; net...@vger.kernel.org ==Subject: Re: Is this 32-bit NCM? == ==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 To: Enrico Mioso Cc: Kevin Zhu , Eli Britstein , Alex Strizhevsky , Midge Shaojun Tan , "you...@gmail.com" , "linux-usb@vger.kernel.org" , "net...@vger.kernel.org" Subject: Re: Is this 32-bit NCM? Enrico Mioso 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 ==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 ==
Re: [RFC] usb: gadget: libcomposite: provide usb_get_cdesc()
On 11/27/2014 11:09 AM, Andrzej Pietrasiewicz wrote:
> Hi Sebastian,
Hi Andrzej,
>> +struct usb_descriptor_header *usb_get_cdesc(struct
>> usb_descriptor_header **hdr,
>> + struct usb_descriptor_header *desc,
>> + struct usb_descriptor_header **c)
>> +{
>> +unsigned off;
>> +
>> +for (off = 0; hdr[off] && c[off]; off++) {
>> +if (hdr[off] == desc)
>> +break;
>> +}
>> +if (!hdr[off] || !c[off])
>> +return NULL;
>> +return c[off];
>> +}
>> +EXPORT_SYMBOL_GPL(usb_get_cdesc);
>> +
>
> If usb_get_cdesc() is newly added _and_ EXPORTed, it is intended for
> use by other modules, and if that is the case, the other modules should
> probably be able to see its prototype for compilation, shouldn't they?
This is correct, the header is missing. However this is RFC and meant
to talk about it and to apply as-is. I pointed out a problem and two
possible solutions. One would a global mutex and making sure the
gadgets "reverts" critical members of the descriptor to its initial
state if required. The way would be to copy the descriptors (before
touching them) and "taking" the appropriate copy of the descriptor
using this function.
>
> AP
Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Is this 32-bit NCM?
I do not understand why the wSequence matters. By the way, I think I see some NDPs are right after NTH headers in the windows capture. From: Enrico Mioso Sent: Tuesday, December 2, 2014 21:53 To: Bjørn Mork Cc: Kevin Zhu; Eli Britstein; Alex Strizhevsky; Midge Shaojun Tan; you...@gmail.com; linux-usb@vger.kernel.org; net...@vger.kernel.org Subject: Re: Is this 32-bit NCM? 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 ==To: Enrico Mioso ==Cc: Kevin Zhu , ==Eli Britstein , ==Alex Strizhevsky , ==Midge Shaojun Tan , =="you...@gmail.com" , =="linux-usb@vger.kernel.org" , =="net...@vger.kernel.org" ==Subject: Re: Is this 32-bit NCM? == ==Enrico Mioso 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 == 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 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: "Real" USB3 mass storage speed
On 12/02/2014 03:20 PM, Felipe Balbi wrote: > > Sebastian, do you still have any notes on how to use UASP gadget with > either RAM or a real storage backend ? I have a shell script dated 2k11: CONFIGFS=/sys/kernel/config/; TARGET=$CONFIGFS/target/core/ FABRIC=$CONFIGFS/target/loopback/ mkdir -p $TARGET/rd_mcp_0/ramdisk echo -n rd_pages=32768 > $TARGET/rd_mcp_0/ramdisk/control echo -n 1 > $TARGET/rd_mcp_0/ramdisk/enable mkdir -p $FABRIC/naa.6001405c3214b06a/tpgt_1 mkdir $FABRIC/naa.6001405c3214b06a/tpgt_1/lun/lun_0 echo -n naa.6001405c3214b06b > $FABRIC/naa.6001405c3214b06a/tpgt_1/nexus ln -sv $TARGET/rd_mcp_0/ramdisk $FABRIC/naa.6001405c3214b06a/tpgt_1/lun/lun_0/virtual_scsi_port --- and a link http://article.gmane.org/gmane.linux.scsi.target.devel/654 > > cheers > Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: "Real" USB3 mass storage speed
Hi, On Tue, Dec 02, 2014 at 11:55:29AM +0100, Ricardo Ribalda Delgado wrote: > Hello > > As you know I am trying to improve the net2280 driver to a point where > it is usable for my company (qtec.com). We develop smart cameras based > on linux, and we want to provide also a mass storage interface to the > camera. > > Right now, the maximum speed I have been able to achieve is around 80 > MiB per second. This is with the governor in performance mode and > disabling idle states on the cpu. > > I wonder if any of you have meassured the maximum speed achievable via > usb gadget mass storage via usb 3.0? I got more than 100MiB/sec and I know Paul Zimmerman got 350MiB/sec using a different host side stack. Both of these numbers were achieved using dwc3 (drivers/usb/dwc3). > And what about the fastest usb 3.0 ssd hard drive (no usb gadget)? > > If I want to get closer to the maximum speed should I just forget > about mass storage and use something else? What? not forget, but sniff. Get yourself a USB 3.0 bus analyzer and look at the bus, why are you getting impacted so badly ? too many SOFs ? Also, you might want to let g_mass_storage use 4 buffers (or maybe more) of 128KiB. Another option is to try the UASP gadget which Sebastian Siewior wrote. That's a much better approach and also supports BOT. Sebastian, do you still have any notes on how to use UASP gadget with either RAM or a real storage backend ? cheers -- balbi signature.asc Description: Digital signature
Re: Is this 32-bit NCM?
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 ==To: Enrico Mioso ==Cc: Kevin Zhu , ==Eli Britstein , ==Alex Strizhevsky , ==Midge Shaojun Tan , =="you...@gmail.com" , =="linux-usb@vger.kernel.org" , =="net...@vger.kernel.org" ==Subject: Re: Is this 32-bit NCM? == ==Enrico Mioso 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 ==
Re: Is this 32-bit NCM?
Enrico Mioso 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: "Real" USB3 mass storage speed
Hello >> If I want to get closer to the maximum speed should I just forget >> about mass storage and use something else? What? >> > > You might want to look into UAS (USB Attached SCSI). > There is "USB Gadget Target Fabric Module" in Kconfig. > There is a gadget-cli tool to control it from userspace. > > You can ask Sebastian for more information: Google could only find https://github.com/evinrude/controller-gadget-kmod/blob/master/cli/gadget-cli.c . But I guess it is not the right tool isn't it? Thanks! -- Ricardo Ribalda -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Is this 32-bit NCM?
... 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 ==To: Enrico Mioso ==Cc: Kevin Zhu , ==Eli Britstein , ==Alex Strizhevsky , ==Midge Shaojun Tan , =="you...@gmail.com" , =="linux-usb@vger.kernel.org" , =="net...@vger.kernel.org" ==Subject: Re: Is this 32-bit NCM? == ==Enrico Mioso 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 ==
Re: Is this 32-bit NCM?
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 ==To: Enrico Mioso ==Cc: Kevin Zhu , ==Eli Britstein , ==Alex Strizhevsky , ==Midge Shaojun Tan , =="you...@gmail.com" , =="linux-usb@vger.kernel.org" , =="net...@vger.kernel.org" ==Subject: Re: Is this 32-bit NCM? == ==Enrico Mioso 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 ==
Re: Is this 32-bit NCM?
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 ==To: Enrico Mioso ==Cc: Kevin Zhu , ==Eli Britstein , ==Alex Strizhevsky , ==Midge Shaojun Tan , =="you...@gmail.com" , =="linux-usb@vger.kernel.org" , =="net...@vger.kernel.org" ==Subject: Re: Is this 32-bit NCM? == ==Enrico Mioso 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 ==
Re: Is this 32-bit NCM?
Enrico Mioso 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 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: "Real" USB3 mass storage speed
W dniu 02.12.2014 o 11:55, Ricardo Ribalda Delgado pisze: Hello As you know I am trying to improve the net2280 driver to a point where it is usable for my company (qtec.com). We develop smart cameras based on linux, and we want to provide also a mass storage interface to the camera. Right now, the maximum speed I have been able to achieve is around 80 MiB per second. This is with the governor in performance mode and disabling idle states on the cpu. I wonder if any of you have meassured the maximum speed achievable via usb gadget mass storage via usb 3.0? And what about the fastest usb 3.0 ssd hard drive (no usb gadget)? If I want to get closer to the maximum speed should I just forget about mass storage and use something else? What? You might want to look into UAS (USB Attached SCSI). There is "USB Gadget Target Fabric Module" in Kconfig. There is a gadget-cli tool to control it from userspace. You can ask Sebastian for more information: c52661d60f636d17e26ad834457db333bd1df494 Author: Sebastian Andrzej Siewior 2012-05-04 04:51:36 Committer: Nicholas Bellinger 2012-05-10 00:25:59 Child: 70baf0ab3b2608727515086bee4c484a93e22880 (target: remove transport_generic_process_write) Branches: balbi-testing-next and many more (556) Follows: v3.4-rc2 Precedes: v3.5-rc1 usb-gadget: Initial merge of target module for UASP + BOT AP -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
"Real" USB3 mass storage speed
Hello As you know I am trying to improve the net2280 driver to a point where it is usable for my company (qtec.com). We develop smart cameras based on linux, and we want to provide also a mass storage interface to the camera. Right now, the maximum speed I have been able to achieve is around 80 MiB per second. This is with the governor in performance mode and disabling idle states on the cpu. I wonder if any of you have meassured the maximum speed achievable via usb gadget mass storage via usb 3.0? And what about the fastest usb 3.0 ssd hard drive (no usb gadget)? If I want to get closer to the maximum speed should I just forget about mass storage and use something else? What? Thanks! PS: With a Delock CFast reader I am able to achieve 84 MiB. -- Ricardo Ribalda -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Is this 32-bit NCM?
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
==To: Eli Britstein ,
==Enrico Mioso
==Cc: Bjørn Mork , Alex Strizhevsky ,
==Midge Shaojun Tan ,
=="you...@gmail.com" ,
=="linux-usb@vger.kernel.org" ,
=="net...@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,
==0x0001 ;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%
Re: Is this 32-bit NCM?
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
==To: Eli Britstein ,
==Enrico Mioso
==Cc: Bjørn Mork , Alex Strizhevsky ,
==Midge Shaojun Tan ,
=="you...@gmail.com" ,
=="linux-usb@vger.kernel.org" ,
=="net...@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,
==0x0001 ;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\Pr
Re: Is this 32-bit NCM?
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
==To: Eli Britstein ,
==Enrico Mioso
==Cc: Bjørn Mork , Alex Strizhevsky ,
==Midge Shaojun Tan ,
=="you...@gmail.com" ,
=="linux-usb@vger.kernel.org" ,
=="net...@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,
==0x0001 ;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\
Re: Is this 32-bit NCM?
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
==To: Eli Britstein ,
==Enrico Mioso
==Cc: Bjørn Mork , Alex Strizhevsky ,
==Midge Shaojun Tan ,
=="you...@gmail.com" ,
=="linux-usb@vger.kernel.org" ,
=="net...@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,
==0x0001 ;RadioState
==HKR, Ndi, Service, 0, "hwusb_wwanecm"
==HKR, Ndi\Interfaces, UpperRange, 0, "flpp4" and
=="flpp6"
==HKR
Re: [PATCH 14/17] Documentation: usb: SERIAL function testing
On Mon, Dec 01, 2014 at 09:33:45AM +0100, Andrzej Pietrasiewicz wrote: > W dniu 28.11.2014 o 16:37, Johan Hovold pisze: > > On Fri, Nov 28, 2014 at 02:57:47PM +0100, Andrzej Pietrasiewicz wrote: > >> Summary of how to test SERIAL function of USB gadget. > > > >> +Testing the SERIAL function > >> +--- > >> + > >> +On host: insmod usbserial vendor= product= > > > > You should use the sysfs interface to add the IDs dynamically instead of > > the legacy module parameters here. > > > Thank you for pointing that out. Can you tell how to actually do it? Sure, just do echo VID PID >/sys/bus/usb-serial/drivers/generic/new_id > I followed the instruction in Documentation/usb/gadget_serial.txt. > It says: > > "You must explicitly load the usbserial driver with parameters to > configure it to recognize the gadget serial device, like this: > >modprobe usbserial vendor=0x0525 product=0xA4A6". That one should probably be updated as well then. Thanks, Johan -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Is this 32-bit NCM?
It works!
Now the modem is working... and the answer is in the huawei NDIS driver.
https://dl.dropboxusercontent.com/u/15043728/ArchLinuxArm/huawei_ndis/ndis_src.tar.xz
On Tue, 2 Dec 2014, Kevin Zhu wrote:
==Date: Tue, 2 Dec 2014 09:03:21
==From: Kevin Zhu
==To: Eli Britstein ,
==Enrico Mioso
==Cc: Bjørn Mork , Alex Strizhevsky ,
==Midge Shaojun Tan ,
=="you...@gmail.com" ,
=="linux-usb@vger.kernel.org" ,
=="net...@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,
==0x0001 ;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,
Re: Is this 32-bit NCM?
Ok - I am a newbie; but looking back at the mistake I did last time - I did
modify the memset call at line 1049 to change the padding.
This is wrong ... but, it was an attempt.
On Tue, 2 Dec 2014, Kevin Zhu wrote:
==Date: Tue, 2 Dec 2014 09:03:21
==From: Kevin Zhu
==To: Eli Britstein ,
==Enrico Mioso
==Cc: Bjørn Mork , Alex Strizhevsky ,
==Midge Shaojun Tan ,
=="you...@gmail.com" ,
=="linux-usb@vger.kernel.org" ,
=="net...@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,
==0x0001 ;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, , en
Re: Is this 32-bit NCM?
Mhmhm; trying to change different values in the cdc_ncm.c driver might be the only way. I am sorry - I am not noticing strange things, but fixed parameters. Try to change them ... I can not do that, I lost my test system due to a kernel-related programming error, so for now I am a passive observer. On Tue, 2 Dec 2014, Kevin Zhu wrote: ==Date: Tue, 2 Dec 2014 08:44:11 ==From: Kevin Zhu ==To: Enrico Mioso ==Cc: Eli Britstein , Bjørn Mork , ==Alex Strizhevsky , ==Midge Shaojun Tan , =="you...@gmail.com" , =="linux-usb@vger.kernel.org" , =="net...@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 ==> ==To: Enrico Mioso ==> ==Cc: Eli Britstein , Bjørn Mork , ==> ==Alex Strizhevsky , ==> ==Midge Shaojun Tan , ==> =="you...@gmail.com" , ==> =="linux-usb@vger.kernel.org" , ==> =="net...@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 ==> ==> ==To: Eli Britstein , ==> ==> ==Enrico Mioso ==> ==> ==Cc: Bjørn Mork , Alex Strizhevsky , ==> ==> ==Midge Shaojun Tan , ==> ==> =="you...@gmail.com" , ==> ==> =="linux-usb@vger.kernel.org" , ==> ==> =="net...@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" 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
Re: [PATCH V6 05/12] mailbox: Add NVIDIA Tegra XUSB mailbox driver
On Mon, Nov 24, 2014 at 04:17:17PM -0800, Andrew Bresticker wrote: > The Tegra xHCI controller's firmware communicates requests to the host > processor through a mailbox interface. While there is only a single > physical channel, messages sent by the controller can be divided > into two groups: those intended for the PHY driver and those intended > for the host-controller driver. The requesting driver is assigned > one of two virtual channels when the single physical channel is > requested. All incoming messages are sent to both virtual channels. > > Signed-off-by: Andrew Bresticker > Reviewed-by: Stephen Warren > --- > Thierry, > > I've left this as a separate driver because I don't think it should be > combined with the xHCI host. Stephen and I discussed this earlier in > review of v1 of this series and he agreed that the mailbox belongs in > its own DT node and driver. My objection wasn't strictly against merging the drivers. What I don't want to see is two devices sharing the same memory-mapped regions in DT. That's based on earlier discussion with Stephen as well, because we have had the same problem with USB and USB-PHY before. Unless I completely misinterpreted we came to the conclusion that we should avoid this in the future. Like I said, this doesn't mean that both need to be in the same driver. We could use MFD for example, or provide an entry point in the mailbox driver that can be called from the XUSB driver to instantiate the mailbox (which is really the same as MFD). Thierry pgpLmibRCA3_n.pgp Description: PGP signature
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,
0x0001 ;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 l
