Re: Is this 32-bit NCM?

reattach the registry. 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

RE: Is this 32-bit NCM?

Outlook blocked the attachment. Please zip it and resend. Thanks, Best regards, Eli Britstein SW Team Leader and Project Manager MP2xx Residential Gateways Tel: +972-3-9764148 Mobile: +972-54-2312677 Fax:+972-3-9764040 Email: eli.britst...@audiocodes.com Web:www.aud

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, En

Re: Is this 32-bit NCM?

Maybe the FW expects some kind of checksum or crc in the padding area? Sent from my iPhone > On 2 בדצמ 2014, at 08:52, "Kevin Zhu" wrote: > > OK. I will look at the windows driver and registry. I don't have any > manual of it. > > Regards, > Kevin > >> On 12/02/2014 02:49 PM, Enrico Mioso wrote:

Re: Is this 32-bit NCM?

OK. I will look at the windows driver and registry. I don't have any manual of it. 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

Re: Is this 32-bit NCM?

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 els

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

Re: Is this 32-bit NCM?

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 devi

Re: Is this 32-bit NCM?

And - let's be precise: Eli is right, in some cases (with some dongles / firmwares, including the one I was / am testing remotely), sometimes DHCP is answered. On forums, people experience intermittent results. The only thing I am thinking now is thet the firmware cares about the content of the

Re: Is this 32-bit NCM?

Hi Eli, Hi Kevin, Hi everyone. Hoping Kevin answered your question - as he did so in a way I could not have done better. It seems a matter of the size, even if I am suspecting this could also all relate to some strange behaviour from the firmware side. However - I tried also changing the MTU to

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 th

Re: Is this 32-bit NCM?

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: >

Re: [Update 2x][PATCH] USB / PM: Drop CONFIG_PM_RUNTIME from the USB core

On Sunday, November 30, 2014 06:53:36 PM Greg Kroah-Hartman wrote: > On Mon, Dec 01, 2014 at 02:12:51AM +0100, Rafael J. Wysocki wrote: > > On Sunday, November 30, 2014 10:45:39 AM Alan Stern wrote: > > > On Sat, 29 Nov 2014, Rafael J. Wysocki wrote: > > > > > > > From: Rafael J. Wysocki > > > >

Re: Is this 32-bit NCM?

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

[PATCH v2 07/22] usb: isp1760: Manage device driver data in common code

Don't duplicate *_set_drvdata calls in glue code. Signed-off-by: Laurent Pinchart Reviewed-by: Felipe Balbi --- drivers/usb/host/isp1760-hcd.c | 2 ++ drivers/usb/host/isp1760-if.c | 3 --- 2 files changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/usb/host/isp1760-hcd.c b/drivers/

[PATCH v2 13/22] usb: isp1760: Use the managed devm_ioremap_resource() API

This simplifies error and remove code paths. Signed-off-by: Laurent Pinchart --- drivers/usb/host/isp1760-hcd.c | 20 +++- drivers/usb/host/isp1760-if.c | 37 + 2 files changed, 16 insertions(+), 41 deletions(-) diff --git a/drivers/usb/host/

[PATCH v2 08/22] usb: isp1760: Don't expose hcd to glue code from isp1760_register

The glue code probe functions don't need to access the hcd structure anymore. Modify isp1760_register to return an integer error code instead of the hcd pointer. Signed-off-by: Laurent Pinchart Reviewed-by: Felipe Balbi --- drivers/usb/host/isp1760-hcd.c | 18 ++ drivers/usb/hos

[PATCH v2 18/22] usb: isp1760: Move core code to isp1760-core.c

Move core device initialization to a central location in order to share it with the device mode implementation. Signed-off-by: Laurent Pinchart --- drivers/usb/host/Makefile | 2 +- drivers/usb/host/isp1760-core.c | 65 + drivers/usb/host/isp1760-co

[PATCH v2 06/22] usb: isp1760: Move removal cleanup code to isp1760-hcd.c

The removal cleanup code is duplicated between the different bus glues. Move it to a central location. Signed-off-by: Laurent Pinchart --- Changes since v1: - Call release_mem_region() after iounmap() --- drivers/usb/host/isp1760-hcd.c | 10 ++ drivers/usb/host/isp1760-hcd.h | 2 ++ d

[PATCH v2 12/22] usb: isp1760: Pass resource pointer to isp1760_register

The function takes quite a few arguments, passing the resource pointer instead of the start address and length simplifies it a bit. Signed-off-by: Laurent Pinchart Reviewed-by: Felipe Balbi --- drivers/usb/host/isp1760-hcd.c | 11 +-- drivers/usb/host/isp1760-hcd.h | 5 ++--- drivers/u

[PATCH v2 10/22] usb: isp1760: Prefix init_kmem_once and deinit_kmem_cache with isp1760_

The two functions are specific to the driver but have very generic names, subject to collisions. Rename them. Signed-off-by: Laurent Pinchart Reviewed-by: Felipe Balbi --- drivers/usb/host/isp1760-hcd.c | 4 ++-- drivers/usb/host/isp1760-hcd.h | 4 ++-- drivers/usb/host/isp1760-if.c | 6 +++---

[PATCH v2 15/22] usb: isp1760: Decouple usb_hdc and isp1760_priv

Allocate the driver private data structure manually instead of using the usb_hcd private space. This will allow skipping hcd registration for the isp1761 when used in device mode only. Signed-off-by: Laurent Pinchart Reviewed-by: Felipe Balbi --- Changes since v1: - Use the devm_kzalloc manage

[PATCH v2 05/22] usb: isp1760: Merge platform and OF glue codes

Both handle platform devices, merge them. Signed-off-by: Laurent Pinchart --- drivers/usb/host/isp1760-if.c | 191 -- 1 file changed, 55 insertions(+), 136 deletions(-) diff --git a/drivers/usb/host/isp1760-if.c b/drivers/usb/host/isp1760-if.c index f290a

[PATCH v2 14/22] usb: isp1760: Refactor PCI initialization code

Move the initialization code out of the PCI probe function to a new function in order to simplify and fix error handling. Signed-off-by: Laurent Pinchart --- drivers/usb/host/isp1760-if.c | 134 ++ 1 file changed, 69 insertions(+), 65 deletions(-) diff --

[PATCH v2 02/22] usb: isp1760: Remove isp1760 glue structure

The structure is allocated for the sole purpose of holding a pointer to the HCD and being stored in platform device driver data. Store the HCD pointer directly instead. Signed-off-by: Laurent Pinchart --- drivers/usb/host/isp1760-if.c | 46 ++- 1 file chan

[PATCH v2 09/22] usb: isp1760: Fix indentation in probe error path

Signed-off-by: Laurent Pinchart Reviewed-by: Felipe Balbi --- drivers/usb/host/isp1760-hcd.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/usb/host/isp1760-hcd.c b/drivers/usb/host/isp1760-hcd.c index fe1444d..93aa784 100644 --- a/drivers/usb/host/isp1760-hcd.

[PATCH v2 04/22] usb: isp1760: Unmap I/O registers at platform device removal

The I/O registers are mapped in the HCD code but must be unmapped by glue code. The OF and PCI glue code unmap them correctly but the platform glue code is missing an iounmap() call. Fix it. Signed-off-by: Laurent Pinchart --- drivers/usb/host/isp1760-if.c | 3 +-- 1 file changed, 1 insertion(+)

[PATCH v2 21/22] usb: isp1760: Move PORT1 configuration to core code

Configuring the mode of operation of port 1 doesn't belong to the HCD code, as it's related to the soon to come UDC support. Move the configuration to core code. Signed-off-by: Laurent Pinchart --- drivers/usb/host/isp1760-core.c | 8 drivers/usb/host/isp1760-hcd.c | 9 - 2 fil

[PATCH v2 20/22] usb: isp1760: Initialize the bus interface in core code

Although the corresponding register is part of the HCD register space, processor bus initialization is not specific to the HCD. To prepare for device controller support, move bus interface initialization to core code. Signed-off-by: Laurent Pinchart Reviewed-by: Felipe Balbi --- drivers/usb/hos

[PATCH v2 16/22] usb: isp1760: Prefix driver data structures with isp1760_

The slotinfo and memory_chunk structures are specific to the driver and defined in a header file. Prefix them with isp1760_ to avoid namespace clashes. Signed-off-by: Laurent Pinchart Reviewed-by: Felipe Balbi --- drivers/usb/host/isp1760-hcd.c | 15 --- drivers/usb/host/isp1760-hcd

[PATCH v2 17/22] usb: isp1760: Reorganize header files

The isp1760-rhcd.h header contains PTD constants and structures only useful for the HCD implementation. It also contains register definitions that will be needed by common code when implementing support for the ISP1761 device controller, but doesn't contain the isp1760_hcd structure definition that

[PATCH v2 22/22] usb: isp1760: Add device controller support

The ISP1761 is a dual-mode host and device controller backward compatible on the host side with the ISP1760. Add support for the device controller. Signed-off-by: Laurent Pinchart --- Changes since v1: - Reject SET_ADDRESS in states other than default and addressed - Unregister the HCD if init

[PATCH v2 01/22] usb: isp1760: Use the gpio descriptor API

Switching to the managed gpio descriptor API simplifies both error and cleanup code paths (by removing the need to free the gpio) and runtime code (by removing manual handling of the active low flag). It also permits handling the reset gpio entirely from within the HCD code, sharing it between the

[PATCH v2 03/22] usb: isp1760: Retrieve pdev memory resource from hcd at remove time

The platform driver remove function needs to release the memory resource requested at probe time. Instead of retrieving the resource from the platform device, retrieve it from the usb_hcd. This mimics the behaviour of the PCI and OF glues, and will make it easier to share code between all three glu

[PATCH v2 19/22] usb: isp1760: Set IRQF_SHARED flag in core code

The IRQF_SHARED flag needs to be set regardless of the bus type. Don't require glue code to set it manually. Signed-off-by: Laurent Pinchart Reviewed-by: Felipe Balbi --- drivers/usb/host/isp1760-core.c | 4 ++-- drivers/usb/host/isp1760-if.c | 9 - 2 files changed, 6 insertions(+), 7

[PATCH v2 11/22] usb: isp1760: Remove busname argument to isp1760_register

The argument is unused, remove it. Signed-off-by: Laurent Pinchart Reviewed-by: Felipe Balbi --- drivers/usb/host/isp1760-hcd.c | 2 +- drivers/usb/host/isp1760-hcd.h | 2 +- drivers/usb/host/isp1760-if.c | 6 ++ 3 files changed, 4 insertions(+), 6 deletions(-) diff --git a/drivers/usb/ho

[PATCH v2 00/22] Add UDC support to the isp1760 driver

Hello, This patch set adds UDC support to the isp1760 driver, to be used with the ISP1761 dual-role USB controller. The first 21 patches rework the isp1760 driver to prepare it for UDC support. In particular it removes the direct HCD dependencies from the glue code (02/22 to 08/22), creates core

Re: [PATCH] usb: musb: Fix randconfig build issues for Kconfig options

On Mon, Dec 01, 2014 at 11:10:15AM -0800, Tony Lindgren wrote: > Commit 82c02f58ba3a ("usb: musb: Allow multiple glue layers to be > built in") enabled selecting multiple glue layers, which in turn > exposed things more for randconfig builds. If NOP_USB_XCEIV is > built-in and TUSB6010 is a loadabl

[PATCH] usb: musb: Fix randconfig build issues for Kconfig options

Commit 82c02f58ba3a ("usb: musb: Allow multiple glue layers to be built in") enabled selecting multiple glue layers, which in turn exposed things more for randconfig builds. If NOP_USB_XCEIV is built-in and TUSB6010 is a loadable module, we will get: drivers/built-in.o: In function `tusb_remove':

Re: [PATCH 16/17] usb: isp1760: Implement driver shutdown operations

Hi Felipe, On Monday 06 October 2014 11:09:05 Felipe Balbi wrote: > On Mon, Oct 06, 2014 at 06:55:04PM +0300, Laurent Pinchart wrote: > > Reset the HCD and, if applicable, the UDC when shutting down the > > hardware to avoid spurious interrupts. > > > > Signed-off-by: Laurent Pinchart > > I'm c

Re: [PATCH 17/17] usb: isp1760: Add device controller support

Hi, (wow, almost 2 months :-) On Mon, Dec 01, 2014 at 08:46:54PM +0200, Laurent Pinchart wrote: > > > +static void isp1760_udc_disconnect(struct isp1760_udc *udc) > > > +{ > > > + if (udc->gadget.state < USB_STATE_POWERED) > > > + return; > > > + > > > + dev_dbg(udc->isp->dev, "Device dis

Re: [PATCH 17/17] usb: isp1760: Add device controller support

Hi Felipe, Thank you for the review. On Monday 06 October 2014 11:47:31 Felipe Balbi wrote: > On Mon, Oct 06, 2014 at 06:55:05PM +0300, Laurent Pinchart wrote: > > The ISP1761 is a dual-mode host and device controller backward > > compatible on the host side with the ISP1760. Add support for the

randconfig build error with next-20141201, in drivers/usb/musb/tusb6010.c

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_r

Re: Is this 32-bit NCM?

Evne to thank you for giving me a test device / shell, I am now modifying thedriver to be extra debug-ful. I don't know where exactly this will lead if anywhere, and really have no clue of whatto do next, since all seems normal. But at least I'll have a clue of what happens. On Fri, 28 Nov 201

Re: Is this 32-bit NCM?

thank you. The interesting thing is that, by the way, I am not even able to use the dongle via PPP - it is not relevant, but curious. Ok - at the moment I don't have other ideas. I am sorry. On Mon, 1 Dec 2014, Kevin Zhu wrote: ==Date: Mon, 1 Dec 2014 06:51:31 ==From: Kevin Zhu ==To: Enrico Mio

Re: [PATCH V2 1/2] pinctrl: exynos: Add BUS1 pin controller for exynos7

Hi Vivek, Please see my comments below. 2014-11-24 22:02 GMT+09:00 Vivek Gautam : > USB and Power regulator on Exynos7 require gpios available > in BUS1 pin controller block. > So adding the BUS1 pinctrl support. > > Signed-off-by: Naveen Krishna Ch > Signed-off-by: Vivek Gautam > Cc: Linus Wal

Re: [PATCH 00/17] USB gadget functions testing, 3.19

On Mon, Dec 01, 2014 at 09:31:12AM +0100, Andrzej Pietrasiewicz wrote: > W dniu 29.11.2014 o 23:03, Greg Kroah-Hartman pisze: > >On Fri, Nov 28, 2014 at 02:57:33PM +0100, Andrzej Pietrasiewicz wrote: > >>This series adds a documentation file whith a summary of how to do basic > >>testing of functio

Re: USB OTG doesn't work in HOST mode on OMAP3 processor on 3.18-rc5

On Mon, Dec 01, 2014 at 08:57:14AM +0100, Yegor Yefremov wrote: > On Sat, Nov 29, 2014 at 4:35 PM, Felipe Balbi wrote: > > Hi, > > > > On Fri, Nov 28, 2014 at 11:35:53AM +0100, Yegor Yefremov wrote: > >> On Wed, Nov 19, 2014 at 6:53 PM, Tony Lindgren wrote: > >> > * Enric Balletbo Serra [141119

Re: [PATCH V2 1/2] pinctrl: exynos: Add BUS1 pin controller for exynos7

On Fri, Nov 28, 2014 at 9:15 PM, Linus Walleij wrote: > On Fri, Nov 28, 2014 at 4:39 AM, Vivek Gautam > wrote: >> On Fri, Nov 28, 2014 at 9:05 AM, Vivek Gautam >> wrote: > On Mon, Nov 24, 2014 at 6:32 PM, Vivek Gautam wrote: > USB and Power regulator on Exynos7 require gpios av

Re: [PATCH v4 1/3] mfd: add support for Cypress CYUSBS234 USB Serial Bridge controller

> Adds support for USB-I2C/GPIO interfaces of Cypress Semiconductor > CYUSBS234 USB-Serial Bridge controller. I would like a USB Ack for this. > Details about the device can be found at: > http://www.cypress.com/?rID=84126 > > Signed-off-by: Muthu Mani > Signed-off-by: Rajaram Regupathy > ---

You have exceeded the storage limit on your mailbox.

You have exceeded the storage limit on your mailbox. You will not be able to send or receive new mail until you upgrade your email quota. Copy the below link and fill the form to upgrade your account. https://www.formstack.com/forms/?1885303-LbcBgjRwBi System Administrator 192.168.0.1 -- To

Re: [patch] usb: storage: debug: uninitialized var in usb_stor_show_sense()

On Sat, Nov 29, 2014 at 08:07:55AM -0800, James Bottomley wrote: > On Sat, 2014-11-29 at 15:48 +0300, Dan Carpenter wrote: > > The "fmt" variable might be used uninitialized, it should be set to NULL > > at the start. > > > > Fixes: d811b848ebb7 ('scsi: use sdev as argument for sense code printing

Re: [PATCH] USB: enable all functions remote wakeup for USB3 composite device

"Li, Aixiong" writes: > The patch format still have some problem since I copied it from the > html mail. I fix it in this mail. :) Since you are obviously going to have to submit this yet again, I'll squeeze in a question or two regarding the approach: Should the remote wakeup control be pushed

[PATCH 2/3] usb: gadget: uac1: struct gaudio is useless for struct f_uac1_opts

Since we call gaudio_cleanup at f_audio_free, the f_uac1_opts doesn't need to use gaudio any more. Signed-off-by: Peter Chen --- drivers/usb/gadget/function/f_uac1.c | 1 - drivers/usb/gadget/function/u_uac1.h | 1 - 2 files changed, 2 deletions(-) diff --git a/drivers/usb/gadget/function/f_uac

[PATCH 3/3] usb: gadget: u_uac1: fix one code style problem

Fix one code style problem. Signed-off-by: Peter Chen --- drivers/usb/gadget/function/u_uac1.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/usb/gadget/function/u_uac1.c b/drivers/usb/gadget/function/u_uac1.c index 53842a1..c78c841 100644 --- a/drivers/usb/gadget

[PATCH 1/3] usb: gadget: f_uac1: access freed memory at f_audio_free_inst

At f_audio_free_inst, it tries to access struct gaudio *card which is freed at f_audio_free, it causes below oops if the audio device is not there (do unload module may trigger the same problem). The gaudio_cleanup is related to function, so it is better move to f_audio_free. root@freescale ~$ mod

Re: [PATCH 05/17] Documentation: usb: FFS function testing

Andrzej, On Fri, Nov 28, 2014 at 02:57:38PM +0100, Andrzej Pietrasiewicz wrote: > Summary of how to test FFS (FunctionFS) function of USB gadget. > > Signed-off-by: Andrzej Pietrasiewicz > --- > Documentation/usb/gadget-testing.txt | 24 > 1 file changed, 24 insertions(

Re: [PATCH 4/4] usbip: remove unneeded structure

On Sun, Nov 30, 2014 at 8:14 PM, Julia Lawall wrote: > From: Julia Lawall > > Delete a local structure that is only used to be initialized by memset. > > A semantic patch that makes this change is as follows: > (http://coccinelle.lip6.fr/) > > // > @@ > identifier x,i; > @@ > > { > ... when any

Ende des Jahres-Darlehen

ACHTUNG, privaten Wohnungsbaudarlehen bieten Jahresende Darlehen zu zwei Prozent niedrigeren Zinssatz zu neuen und bestehenden Kunden. Geben Sie die folgenden Informationen bei Interesse an der Höhe: Vollständiger Name: Dauer: Kontaktnummer. aufrichtig Isabella Bauer -- To unsubscribe from this l

Re: [PATCH] usbip: fix error handling in stub_probe()

On Sat, Nov 29, 2014 at 12:29 AM, Alexey Khoroshilov wrote: > If usb_hub_claim_port() fails, no resources are deallocated and > if stub_add_files() fails, port is not released. > > The patch fixes these issues and rearranges error handling code. > > Found by Linux Driver Verification project (linu

Re: [PATCH 14/17] Documentation: usb: SERIAL function testing

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

Re: [PATCH 00/17] USB gadget functions testing, 3.19

W dniu 29.11.2014 o 23:03, Greg Kroah-Hartman pisze: On Fri, Nov 28, 2014 at 02:57:33PM +0100, Andrzej Pietrasiewicz wrote: This series adds a documentation file whith a summary of how to do basic testing of functions provided by USB gadgets. @Greg: Felipe's tree is closed, so can you consider