RE: [PATCH] usb: gadget: uvc:change the UVC_NUM_REQUESTS value
Hi,
> -Original Message-
> From: Manu Gautam [mailto:mgau...@codeaurora.org]
> Sent: Tuesday, December 26, 2017 1:01 PM
> To: Lipengcheng; ba...@kernel.org
> Cc: gre...@linuxfoundation.org; linux-ker...@vger.kernel.org;
> linux-usb@vger.kernel.org
> Subject: Re: [PATCH] usb: gadget: uvc:change the UVC_NUM_REQUESTS value
>
> Hi,
>
>
> On 12/26/2017 8:22 AM, Lipengcheng wrote:
> > The value is 4, it can cache four descriptors. When streaming_interval
> > = 1, it can tolerate 500us. Some busy scenes, it may be more than
> > 500us because cpu scheduling is not timely. There will have some
> > problems. It is better set to eight.
> >
> > Signed-off-by: Pengcheng Li
> > ---
> > drivers/usb/gadget/function/uvc.h | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/usb/gadget/function/uvc.h
> > b/drivers/usb/gadget/function/uvc.h
> > index a64e07e..901487e 100644
> > --- a/drivers/usb/gadget/function/uvc.h
> > +++ b/drivers/usb/gadget/function/uvc.h
> > @@ -90,7 +90,7 @@ extern unsigned int uvc_gadget_trace_param;
> > * Driver specific constants
> > */
> >
> > -#define UVC_NUM_REQUESTS 4
> > +#define UVC_NUM_REQUESTS 8
>
> Can we rather make it 16?
> I ran into similar issue on QCOM platform with DWC3 and with 8 requests also
> data loss was observed. 16 requests (i.e. ~2msec) worked fine.
I think 16 is ok. The value 4 has a bit too small .In hisilicon asic, I set the
value 32(4ms) and it is ok. The bad impact is the need to expend more memory
space. So therefore need to match with the respective chip platform to find the
appropriate value.
>
> > #define UVC_MAX_REQUEST_SIZE 64
> > #define UVC_MAX_EVENTS 4
> >
> > --
> > 2.7.4
> >
> > N r y b X ǧv ^ ){.n +{ ^n r z h& G h (
> > 階 ݢj" m z ޖ f h ~ mml==
>
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a
> Linux Foundation Collaborative Project
[PATCH] usb: gadget: uvc:change the UVC_NUM_REQUESTS value
The value is 4, it can cache four descriptors. When streaming_interval = 1,
it can tolerate 500us. Some busy scenes, it may be more than 500us because
cpu scheduling is not timely. There will have some problems. It is better
set to eight.
Signed-off-by: Pengcheng Li
---
drivers/usb/gadget/function/uvc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/function/uvc.h
b/drivers/usb/gadget/function/uvc.h
index a64e07e..901487e 100644
--- a/drivers/usb/gadget/function/uvc.h
+++ b/drivers/usb/gadget/function/uvc.h
@@ -90,7 +90,7 @@ extern unsigned int uvc_gadget_trace_param;
* Driver specific constants
*/
-#define UVC_NUM_REQUESTS 4
+#define UVC_NUM_REQUESTS 8
#define UVC_MAX_REQUEST_SIZE 64
#define UVC_MAX_EVENTS 4
--
2.7.4
N�r��yb�X��ǧv�^�){.n�+{��^n�r���z���h�&�� �G���h�(�階�ݢj"���m��z�ޖ���f���h���~�m�
[PATCH] usb: dwc3: gadget: decrease the queued_requests in removal
In removal requests, it is necessary to make the corresponding trb
disable state (HWO = 1) and dep->queued_requests a corresponding reduction.
It is better to use a alone funtion to disable trb (HWO = 0).
Signed-off-by: Pengcheng Li
---
drivers/usb/dwc3/gadget.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 1e6c42e..273b51d 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -707,6 +707,36 @@ static void dwc3_remove_requests(struct dwc3 *dwc, struct
dwc3_ep *dep)
while (!list_empty(&dep->started_list)) {
req = next_request(&dep->started_list);
+ if (req->trb) {
+ if (req->num_pending_sgs) {
+ struct dwc3_trb *trb;
+ int i = 0;
+
+ for (i = 0; i < req->num_pending_sgs; i++) {
+ trb = req->trb + i;
+ trb->ctrl &= ~DWC3_TRB_CTRL_HWO;
+ dwc3_ep_inc_deq(dep);
+ }
+
+ if (req->unaligned || req->zero) {
+ trb = req->trb + req->num_pending_sgs + 1;
+ trb->ctrl &= ~DWC3_TRB_CTRL_HWO;
+ dwc3_ep_inc_deq(dep);
+ }
+ } else {
+ struct dwc3_trb *trb = req->trb;
+
+ trb->ctrl &= ~DWC3_TRB_CTRL_HWO;
+ dwc3_ep_inc_deq(dep);
+
+ if (req->unaligned || req->zero) {
+ trb = req->trb + 1;
+ trb->ctrl &= ~DWC3_TRB_CTRL_HWO;
+ dwc3_ep_inc_deq(dep);
+ }
+ }
+ }
+ dep->queued_requests--;
dwc3_gadget_giveback(dep, req, -ESHUTDOWN);
}
--
2.7.4
--
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: dwc3: gadget:Core consumes a trb software to fill a trb, in ISO
Hi, > -Original Message- > From: Felipe Balbi [mailto:ba...@kernel.org] > Sent: Friday, December 22, 2017 3:54 PM > To: Lipengcheng > Cc: linux-usb@vger.kernel.org; linux-ker...@vger.kernel.org; Lipengcheng > Subject: Re: [PATCH] usb: dwc3: gadget:Core consumes a trb software to fill a > trb, in ISO > > > Hi, > > Lipengcheng writes: > > > Iso transmission, the current process is that all trb(HWO=1) is handled. > > Then core generate DWC3_DEPEVT_XFERNOTREADY event, Software begin > > refill trb, this will produce 0 length package, the patch is to > > achieve the core consumes a trb, and then the software fill a trb. > > Normally, there will never be DWC3_DEPEVT_XFERNOTREADY event and 0-length > > packet. > > > > Signed-off-by: l00229106 > > who is 100229106?? Sorry. It is my job number. I will use Pengcheng li to replace it. > > > --- > > drivers/usb/dwc3/gadget.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c > > index 981fd98..1e6c42e 100644 > > --- a/drivers/usb/dwc3/gadget.c > > +++ b/drivers/usb/dwc3/gadget.c > > @@ -2420,7 +2420,7 @@ static void dwc3_endpoint_transfer_complete(struct > > dwc3 *dwc, > > if (!dep->endpoint.desc) > > return; > > > > - if (!usb_endpoint_xfer_isoc(dep->endpoint.desc)) > > + if (!usb_endpoint_xfer_isoc(dep->endpoint.desc) || (dep->flags & > > + DWC3_EP_TRANSFER_STARTED)) > > this is wrong. isoc endpoints should NEVER be prestarted. The main purpose is to core handle a trb and sofware re-fill the next trb in the DWC3_DEPEVT_XFERINPROGRESS interrupt. Mayebe it can be modified: if (!usb_endpoint_xfer_isoc(dep->endpoint.desc)) __dwc3_gadget_kick_transfer(dep); + else + dwc3_prepare_trbs(dep); + > > -- > balbi -- 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: [usb gadget]use dev_kfree_skb_irq instead of dev_kfree_skb
Hi, > -Original Message- > From: Greg KH [mailto:gre...@linuxfoundation.org] > Sent: Friday, December 22, 2017 3:50 PM > To: Lipengcheng > Cc: ba...@kernel.org; linux-usb@vger.kernel.org; linux-ker...@vger.kernel.org > Subject: Re: [usb gadget]use dev_kfree_skb_irq instead of dev_kfree_skb > > On Fri, Dec 22, 2017 at 03:43:15PM +0800, lpc.li wrote: > > Hi, > > Ethernet Gadget (with CDC Ethernet support) and RNDIS support, device > > is Hisilicon asic and host is PC Windows. Howerver, it has one > > warning. In the rndis_add_header of the file f_rndis.c, > > dev_kfree_skb_irq replaces dev_kfree_skb. And the waning is > > eliminated. I think we can't use dev_kfree_skb in irq disable context, > > because spin_lock_irqsave make sure we are always in irq disable > > context, use dev_kfree_skb_irq instead of dev_kfree_skb is better than > > dev_kfree_skb_any. > > Can you make up a patch for this please? Ok. > > > > > #<--CO[ cut here ] > > WARNING: CPU: 0 PID: 22 at kernel/softirq.c:146 > > __local_bh_enable_ip+0x8c/0xb4() Modules linked in: g_ether usb_f_ecm > > usb_f_rndis u_ether libcomposite configfs udc_hisi hi_gpio(O) hifb(O) > > hi3559_tde(PO) hi3559_sys(PO) hi3559_base(PO) hi_osal(O) hi_ipcm(O) > > CPU: 0 PID: 22 Comm: kworker/0:1 Tainted: P O 3.18.20 #1 > > Note, 3.18 is _VERY_ old, are you sure this isn't resolved in a modern and > secure kernel release? :) The problem still exists in a modern and secure kernel release > > 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
[PATCH] usb: dwc3: gadget:Core consumes a trb software to fill a trb, in ISO
Iso transmission, the current process is that all trb(HWO=1) is handled.
Then core generate DWC3_DEPEVT_XFERNOTREADY event, Software begin refill
trb, this will produce 0 length package, the patch is to achieve the core
consumes a trb, and then the software fill a trb. Normally, there will never
be DWC3_DEPEVT_XFERNOTREADY event and 0-length packet.
Signed-off-by: l00229106
---
drivers/usb/dwc3/gadget.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 981fd98..1e6c42e 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -2420,7 +2420,7 @@ static void dwc3_endpoint_transfer_complete(struct dwc3
*dwc,
if (!dep->endpoint.desc)
return;
- if (!usb_endpoint_xfer_isoc(dep->endpoint.desc))
+ if (!usb_endpoint_xfer_isoc(dep->endpoint.desc) || (dep->flags &
DWC3_EP_TRANSFER_STARTED))
__dwc3_gadget_kick_transfer(dep);
}
--
2.7.4
N�r��yb�X��ǧv�^�){.n�+{��^n�r���z���h�&�� �G���h�(�階�ݢj"���m��z�ޖ���f���h���~�m�
RE: EHCI
Hi, > -Original Message- > From: Alan Stern [mailto:st...@rowland.harvard.edu] > Sent: Saturday, March 18, 2017 12:44 AM > To: Lipengcheng > Cc: gre...@linuxfoundation.org; linux-usb@vger.kernel.org; > linux-ker...@vger.kernel.org > Subject: Re: EHCI > > On Fri, 17 Mar 2017, Lipengcheng wrote: > > > Hi, > > In the ehci-hub.c,the ehci_handshake(ehci, status_reg, PORT_RESET, 0, > > 1000) use that the timeout is 1000us. The 1000us timeout can not > > satisfy all the chips. The EHCI protocol describes:A host controller > > must terminate the reset and stabilize the state of the port within 2 > > milliseconds of software transitioning this bit from a one to a zero. > > So I think timeout time is set to 2000us more appropriate. If I set > > the timeout time is set to 2000us and may it produce side effects? > > That is a long time to wait with interrupts disabled. You probably should > release the spinlock and enable interrupts during the handshake. > > Have you seen any errors with the current 1000 us value? If you haven't, > there's no reason to change the code. > Yes, I have some error -110(-ETIMEDOUT) with the current 1000us value. When I set the value 2000us, it is ok. > Alan Stern Best Regards, Pengcheng Li -- 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: dwc2: Clear GUSBCFG.UsbTrdTim before setting
> -Original Message-
> From: Felipe Balbi [mailto:felipe.ba...@linux.intel.com]
> Sent: Monday, October 17, 2016 5:37 PM
> To: Lipengcheng; johny...@synopsys.com
> Cc: gre...@linuxfoundation.org; linux-usb@vger.kernel.org;
> linux-ker...@vger.kernel.org; Xuejiancheng; Lidongpo; Caizhiyong; Lipengcheng
> Subject: Re: [PATCH V2]usb: dwc2: Clear GUSBCFG.UsbTrdTim before setting
>
>
> Hi,
>
> Pengcheng Li writes:
> > The USBTRDTIM field needs to be cleared before setting a new value.
> > Otherwise it will result in an incorrect value if phyif == GUSBCFG_PHYIF8.
> >
> > Change-Id: Ib3e33cf4fd15ada41dc070ff7b93858daafbd10f
> > Signed-off-by: Pengcheng Li
> > Acked-by: John Youn
>
> which commit are you fixing? Seems like you're missing a:
>
commit c45574ff02d1d1f35a6bf4b8ad051fc06c001fc7.
> Fixes: foobar
>
> line here. Also, you need to remove Gerritisms from commit log ;-)
>
Ok, I will remove at the next patch.
> --
> Balbi
Best Regards
Pengcheng Li
N�r��yb�X��ǧv�^�){.n�+{��^n�r���z���h�&�� �G���h�(�階�ݢj"���m��z�ޖ���f���h���~�m�
RE: USB GADGET: have a question about usb2eth
> -Original Message- > From: Felipe Balbi [mailto:ba...@kernel.org] > Sent: Monday, October 17, 2016 5:29 PM > To: Lipengcheng; Peter Chen > Cc: gre...@linuxfoundation.org; linux-usb@vger.kernel.org; > linux-ker...@vger.kernel.org > Subject: RE: USB GADGET: have a question about usb2eth > > > Hi, > > (please, avoid top-posting: http://daringfireball.net/2007/07/on_top) > > Lipengcheng writes: > > Hi, > > thank you for your suggestion. > > > > I have a question about usb2eth. In the function gen_ndis_set_resp of > > the rndis.c, the value of *params->filter may be 0x20 from the pc set > > command; Howerver the value is used cdc_filter = > > dev->port_usb->cdc_filter in the function eth_start_xmit of the u_ether.c. > > If we do not judge the RNDIS_PACKET_TYPE_PROMISCUOUS and the value is > > 0x20, the broadcast packet can not send the pc win7; At the result, > > the linux ping the win7 is slow an the first. At the same time, Why > > are different value between RNDIS_PACKET_TYPE_PROMISCUOUS and > > USB_CDC_PACKET_TYPE_PROMISCUOUS? If the value of > > RNDIS_PACKET_TYPE_PROMISCUOUS > > because they are defined by different specifications. You should read both > CDC specification from USB.org and RNDIS spec from Microsoft to > understand the details of that. Ok. I will understand the different both CDC specification from USB.org and RNDIS spec from Microsoft. They should have transformational rule in the linux code between CDC spe and RNDIS spe. Through debugging, I found there has been no conversion about the filter. I feel a little problem. I will find the rule. > > > and USB_CDC_PACKET_TYPE_PROMISCUOUS is same, then the linux ping the > > win7 is normal speed. > > I don't understand what's going on here. Care to describe which kernel you're > using, which USB peripheral controller, what is the actual > problem you're trying to solve? VERSION = 3.18.20 USB peripheral controller: Synopsys HS OTG Linux Software Driver. It's not the standard linux code. But I think the controller do not have problem. The probem is that I am using one controller board with Linux running on it. I want to interface my device to the Host computer (Windows OS) through USB. I have driver ready at device side (linux) and the bridge has been established. The device side ping the Host computer is very slow at the first time. It spends a few minutes. The problem is the first ping takes too long time. Now I have a way to quickly ping at the first , but I do not know the risk about the change.I will continue debug the problem. If it is valuable, I will submit the kernel community. Thanks very much! > > -- > Balbi Best Regards Pengcheng Li
RE: USB GADGET: have a question about usb2eth
Hi, thank you for your suggestion. I have a question about usb2eth. In the function gen_ndis_set_resp of the rndis.c, the value of *params->filter may be 0x20 from the pc set command; Howerver the value is used cdc_filter = dev->port_usb->cdc_filter in the function eth_start_xmit of the u_ether.c. If we do not judge the RNDIS_PACKET_TYPE_PROMISCUOUS and the value is 0x20, the broadcast packet can not send the pc win7; At the result, the linux ping the win7 is slow an the first. At the same time, Why are different value between RNDIS_PACKET_TYPE_PROMISCUOUS and USB_CDC_PACKET_TYPE_PROMISCUOUS? If the value of RNDIS_PACKET_TYPE_PROMISCUOUS and USB_CDC_PACKET_TYPE_PROMISCUOUS is same, then the linux ping the win7 is normal speed. Best Regards Pengcheng Li > -Original Message- > From: Peter Chen [mailto:hzpeterc...@gmail.com] > Sent: Monday, October 17, 2016 9:56 AM > To: Lipengcheng > Cc: ba...@ti.com; gre...@linuxfoundation.org; linux-usb@vger.kernel.org; > linux-ker...@vger.kernel.org > Subject: Re: USB GADGET: have a question about usb2eth > > On Sat, Oct 15, 2016 at 09:19:33AM +, Lipengcheng wrote: > > Hi, > > I have a question about usb2eth. In the function gen_ndis_set_resp of > > the rndis.c, the value of *params->filter may be 0x20 from the pc > set command; Howerver the value is used cdc_filter = > dev->port_usb->cdc_filter in the function eth_start_xmit of the u_ether.c. If > we do not > judge the RNDIS_PACKET_TYPE_PROMISCUOUS and the value is 0x20, the broadcast > packet can not send the pc win7; At the result, the linux > ping the win7 is slow an the first. > > > > The Felipe's email has changed, please check MAINTAINERS. > Besides, would you wrap up line to 75 characters please? > > -- > > Best Regards, > Peter Chen
USB GADGET: have a question about usb2eth
Hi, I have a question about usb2eth. In the function gen_ndis_set_resp of the rndis.c, the value of *params->filter may be 0x20 from the pc set command; Howerver the value is used cdc_filter = dev->port_usb->cdc_filter in the function eth_start_xmit of the u_ether.c. If we do not judge the RNDIS_PACKET_TYPE_PROMISCUOUS and the value is 0x20, the broadcast packet can not send the pc win7; At the result, the linux ping the win7 is slow an the first. Best Regard Pengcheng Li
Why is the max_sectors set the 240
Hi, Some special superspeed u3 disk connect xhci control. Then the u3 disk is read/write and has the Transfer error on endpoint (COMP_TX_ERR) error. However in the pc windows does not have the problem.By analysis, the windows is each transfer 64K size. The Linux is 120K size. In the scsiglue.c, the max_sectors value set the 128 and each transfer 64K size. Then the Linux system is no problem too. Why is the max_sectors set the 240? May the max_sectors be the other values? Best Regard Pengcheng Li
RE: usb device to ether is not identification in 64bit Windows OS
Hi,
In windows official web, download a new linux.inf file, and add our
hisilicon usb id. Now it can be used correct identification in PC windows 64bit
OS. At the same time, it can also be used correctly in PC windows 32bit OS.
windows official web:
https://msdn.microsoft.com/zh-cn/windows/hardware/drivers/network/remote-ndis-inf-template
the new file(add hisilicon usb id):
; Remote NDIS template device setup file
; Copyright (c) Microsoft Corporation
;
; This is the template for the INF installation script for the RNDIS-over-USB
; host driver that leverages the newer NDIS 6.x miniport (rndismp6.sys) for
; improved performance. This INF works for Windows 7, Windows Server 2008 R2,
; and later operating systems on x86, amd64 and ia64 platforms.
[Version]
Signature = "$Windows NT$"
Class = Net
ClassGUID = {4d36e972-e325-11ce-bfc1-08002be10318}
Provider= %Microsoft%
DriverVer = 07/21/2008,6.0.6000.16384
;CatalogFile= device.cat
[Manufacturer]
%Microsoft% = RndisDevices,NTx86,NTamd64,NTia64
; Decoration for x86 architecture
[RndisDevices.NTx86]
%RndisDevice%= RNDIS.NT.6.0, USB\VID_0525&PID_a4a2,
USB\VID_1d6b&PID_0104&MI_00, USB\VID_0525&PID_A4A2&REV_0318
; Decoration for x64 architecture
[RndisDevices.NTamd64]
%RndisDevice%= RNDIS.NT.6.0, USB\VID_0525&PID_a4a2,
USB\VID_1d6b&PID_0104&MI_00, USB\VID_0525&PID_A4A2&REV_0318
; Decoration for ia64 architecture
[RndisDevices.NTia64]
%RndisDevice%= RNDIS.NT.6.0, USB\VID_0525&PID_a4a2,
USB\VID_1d6b&PID_0104&MI_00, USB\VID_0525&PID_A4A2&REV_0318
;@@@ This is the common setting for setup
[ControlFlags]
ExcludeFromSelect=*
; DDInstall section
; References the in-build Netrndis.inf
[RNDIS.NT.6.0]
Characteristics = 0x84 ; NCF_PHYSICAL + NCF_HAS_UI
BusType = 15
; NEVER REMOVE THE FOLLOWING REFERENCE FOR NETRNDIS.INF
include = netrndis.inf
needs = usbrndis6.ndi
AddReg = Rndis_AddReg
*IfType= 6; IF_TYPE_ETHERNET_CSMACD.
*MediaType = 16 ; NdisMediumNative802_11
*PhysicalMediaType = 14 ; NdisPhysicalMedium802_3
; DDInstal.Services section
[RNDIS.NT.6.0.Services]
include = netrndis.inf
needs = usbrndis6.ndi.Services
; Optional registry settings. You can modify as needed.
[RNDIS_AddReg]
HKR, NDI\params\RndisProperty, ParamDesc, 0, %Rndis_Property%
HKR, NDI\params\RndisProperty, type, 0, "edit"
HKR, NDI\params\RndisProperty, LimitText, 0, "12"
HKR, NDI\params\RndisProperty, UpperCase, 0, "1"
HKR, NDI\params\RndisProperty, default,0, " "
HKR, NDI\params\RndisProperty, optional, 0, "1"
; No sys copyfiles - the sys files are already in-build
; (part of the operating system).
; Modify these strings for your device as needed.
[Strings]
Microsoft = "Microsoft Corporation"
RndisDevice = "Remote NDIS6 based Device"
Rndis_Property = "Optional RNDIS Property"
> -Original Message-
> From: gre...@linuxfoundation.org [mailto:gre...@linuxfoundation.org]
> Sent: Monday, September 19, 2016 12:46 AM
> To: Lipengcheng
> Cc: cor...@lwn.net; linux-usb@vger.kernel.org; linux-...@vger.kernel.org;
> linux-ker...@vger.kernel.org
> Subject: Re: usb device to ether is not identification in 64bit Windows OS
>
> On Sun, Sep 18, 2016 at 01:16:59PM +, Lipengcheng wrote:
> > Hi,
> > kernel version：4.8.0
> > file:Documentation / usb / linux.inf
> > problem:PC windows is 32bit OS, using Ethernet gadget driver, it can
> > be correct identification. But PC windows is 64bit OS, while modifying
> > linux.inf file LinuxDevice parameters, it can not correct
> > identification, the serial port can be printed correctly:g_ether
> > gadget: high-speed config # 2: RNDIS. I suspect that the linux.inf
> > files are not mismatch 64bit windows OS.
>
> Given that everyone here does not use Windows at all, you are going to be on
> your own here, sorry. If you do come up with an updated .inf
> file, we will be glad to take a patch.
>
> good luck,
>
> greg k-h
Best regards,
Pengcheng Li
usb device to ether is not identification in 64bit Windows OS
Hi, kernel version：4.8.0 file:Documentation / usb / linux.inf problem:PC windows is 32bit OS, using Ethernet gadget driver, it can be correct identification. But PC windows is 64bit OS, while modifying linux.inf file LinuxDevice parameters, it can not correct identification, the serial port can be printed correctly:g_ether gadget: high-speed config # 2: RNDIS. I suspect that the linux.inf files are not mismatch 64bit windows OS. Best regards, Pengcheng Li
RE: [PATCH] usb:solve resume usb device identification problem
> -Original Message-
> From: Lu Baolu [mailto:baolu...@linux.intel.com]
> Sent: Tuesday, July 12, 2016 10:24 AM
> To: Lipengcheng; gre...@linuxfoundation.org; st...@rowland.harvard.edu;
> chasemetzge...@gmail.com; mathias.ny...@linux.intel.com;
> oneu...@suse.com; jun...@freescale.com
> Cc: linux-usb@vger.kernel.org; linux-ker...@vger.kernel.org
> Subject: Re: [PATCH] usb:solve resume usb device identification problem
>
> Hi,
>
> On 07/12/2016 09:48 AM, Lipengcheng wrote:
> > Hi,
> >
> >> -Original Message-
> >> From: Lu Baolu [mailto:baolu...@linux.intel.com]
> >> Sent: Tuesday, July 12, 2016 8:42 AM
> >> To: Lipengcheng; gre...@linuxfoundation.org;
> >> st...@rowland.harvard.edu; chasemetzge...@gmail.com;
> >> mathias.ny...@linux.intel.com; oneu...@suse.com; jun...@freescale.com
> >> Cc: linux-usb@vger.kernel.org; linux-ker...@vger.kernel.org
> >> Subject: Re: [PATCH] usb:solve resume usb device identification
> >> problem
> >>
> >> Hi,
> >>
> >> On 07/11/2016 08:57 PM, Pengcheng Li wrote:
> >>> A usb device in the connection state. Then host is suspend and resume.
> >>> But the usb device could not be at the right speed. We should be
> >>> reset the reset.
> >> Have you tried applying XHCI_RESET_ON_RESUME quirk to your host controller
> >> driver? Is your usb device self powered?
> >>
> > I do not apply XHCI_RESET_ON_RESUME quir to my host controller driver. I
> > select no pci platform. Our usb device is not self powered.
>
> This quirk is not pci specific.
>
I'm sorry. I will try to it.
> >> Best regards,
> >> Lu Baolu
> >>
> >>> Signed-off-by: Pengcheng Li
> >>> ---
> >>> drivers/usb/core/hub.c | 6 +-
> >>> 1 file changed, 5 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c index
> >>> bee1351..cd71bb3 100644
> >>> --- a/drivers/usb/core/hub.c
> >>> +++ b/drivers/usb/core/hub.c
> >>> @@ -3455,7 +3455,7 @@ int usb_port_resume(struct usb_device *udev,
> >>> pm_message_t msg)
> >>> struct usb_hub *hub = usb_hub_to_struct_hub(udev->parent);
> >>> struct usb_port *port_dev = hub->ports[udev->portnum - 1];
> >>> int port1 = udev->portnum;
> >>> - int status;
> >>> + int status, retval;
> >>> u16 portchange, portstatus;
> >>>
> >>> if (!test_and_set_bit(port1, hub->child_usage_bits)) { @@ -3512,6
> >>> +3512,10 @@ int usb_port_resume(struct usb_device *udev,
> >>> +pm_message_t msg)
> >>> }
> >>> }
> >>>
> >>> + retval = hub_port_reset(hub, port1, udev, HUB_ROOT_RESET_TIME, false);
> >>> + if (retval < 0)
> >>> + hub_port_disable(hub, port1, 0);
> >>> +
>
> If I understand it right, this is a "host + device" specific issue. This line
> of code might solve your issue, but it impacts all other hosts and devices
> which don't have such problem.
>
Yes. You are right. This line of code can solve my issue. But I suspect this is
a common issue. At normal enumeration, the device has a reset operation. The
resume
should have the same operation. In USB3.0 spec, superspeed device is at the
wrong statue(u2 statue), and we should be reset the device.
> Best regards,
> Lu Baolu
Best regards,
Pengcheng Li
RE: [PATCH] usb:solve resume usb device identification problem
Hi,
> -Original Message-
> From: Lu Baolu [mailto:baolu...@linux.intel.com]
> Sent: Tuesday, July 12, 2016 8:42 AM
> To: Lipengcheng; gre...@linuxfoundation.org; st...@rowland.harvard.edu;
> chasemetzge...@gmail.com; mathias.ny...@linux.intel.com;
> oneu...@suse.com; jun...@freescale.com
> Cc: linux-usb@vger.kernel.org; linux-ker...@vger.kernel.org
> Subject: Re: [PATCH] usb:solve resume usb device identification problem
>
> Hi,
>
> On 07/11/2016 08:57 PM, Pengcheng Li wrote:
> > A usb device in the connection state. Then host is suspend and resume.
> > But the usb device could not be at the right speed. We should be reset
> > the reset.
>
> Have you tried applying XHCI_RESET_ON_RESUME quirk to your host controller
> driver? Is your usb device self powered?
>
I do not apply XHCI_RESET_ON_RESUME quir to my host controller driver. I select
no pci platform. Our usb device is not self powered.
> Best regards,
> Lu Baolu
>
> >
> > Signed-off-by: Pengcheng Li
> > ---
> > drivers/usb/core/hub.c | 6 +-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c index
> > bee1351..cd71bb3 100644
> > --- a/drivers/usb/core/hub.c
> > +++ b/drivers/usb/core/hub.c
> > @@ -3455,7 +3455,7 @@ int usb_port_resume(struct usb_device *udev,
> > pm_message_t msg)
> > struct usb_hub *hub = usb_hub_to_struct_hub(udev->parent);
> > struct usb_port *port_dev = hub->ports[udev->portnum - 1];
> > int port1 = udev->portnum;
> > - int status;
> > + int status, retval;
> > u16 portchange, portstatus;
> >
> > if (!test_and_set_bit(port1, hub->child_usage_bits)) { @@ -3512,6
> > +3512,10 @@ int usb_port_resume(struct usb_device *udev, pm_message_t msg)
> > }
> > }
> >
> > + retval = hub_port_reset(hub, port1, udev, HUB_ROOT_RESET_TIME, false);
> > + if (retval < 0)
> > + hub_port_disable(hub, port1, 0);
> > +
> > if (udev->persist_enabled)
> > status = wait_for_connected(udev, hub, &port1, &portchange,
> > &portstatus);
Best regards
Pengcheng Li
N�r��yb�X��ǧv�^�){.n�+{��^n�r���z���h�&�� �G���h�(�階�ݢj"���m��z�ޖ���f���h���~�m�
RE: [PATCH] usb:solve resume usb device identification problem
Hi, > -Original Message- > From: Alan Stern [mailto:st...@rowland.harvard.edu] > Sent: Monday, July 11, 2016 10:51 PM > To: Lipengcheng > Cc: gre...@linuxfoundation.org; baolu...@linux.intel.com; > chasemetzge...@gmail.com; mathias.ny...@linux.intel.com; > oneu...@suse.com; jun...@freescale.com; linux-usb@vger.kernel.org; > linux-ker...@vger.kernel.org > Subject: Re: [PATCH] usb:solve resume usb device identification problem > > On Mon, 11 Jul 2016, Pengcheng Li wrote: > > > A usb device in the connection state. Then host is suspend and resume. > > But the usb device could not be at the right speed. We should be reset > > the reset. > > > > Signed-off-by: Pengcheng Li > > Why wouldn't the USB device be at the right speed? > For example, some USB3 devices are resume, the device may be in USB 2.0 Device States. We should have USB 2.0 reset and make the device into the right speed. > You should _not_ reset the device if it is at the right speed. > > > @@ -3512,6 +3512,10 @@ int usb_port_resume(struct usb_device *udev, > > pm_message_t msg) > > } > > } > > > > + retval = hub_port_reset(hub, port1, udev, HUB_ROOT_RESET_TIME, false); > > + if (retval < 0) > > + hub_port_disable(hub, port1, 0); > > + > > Most of the time (for example, for non-USB3 devices) this would be wrong. > Yes, USB3 devices have this problem. So far, USB2 device can not find this problem. I mainly refer to the reset process of usb enumeration process. > Alan Stern Thanks, Pengcheng Li
RE: ehci and ohci reset number doubt
Hi, > The ohci-platform and ehci-platform drivers already perform their own root-hub and bus resets. I don't understand the sentence clearly. Synopsis control VERSION： DesignWare Cores USB2.0 Host-AHB Controller, Version 2.98a The synopsis has the three source clocks for EHCI Host Controller implementation: A, System (AHB BIU) Clock B, PHY Clock(BUS clock) C, UTMI PHY Clock(per port) A clock corresponding to a reset, so the ehci control should have the same number reset. We are ready to put the utmi phy clock and utmi reset into the phy module. The ehci-platform is on the lack of a reset number. Clock and reset detail: Signal Description ehci_hclk_i EHCI AHB System Clock Function: The EHCI AHB System clock supports 30- to 166- MHz operation and has been tested at 40/50/60 MHz in FPGA technology. All signal timings are related to the rising edge of ehci_hclk_i. The EHCI System Clock runs off this clock. For correct synchronization between the AHB and UTMI, the minimum required AHB frequency is 30 MHz. This clock is valid only if "Dedicated AHB interface for EHCI and OHCI" is Selected ehci_hreset_i_n EHCI System Reset Function: This active-low, synchronous or asynchronous (depending on the configuration) reset serves as power-on reset and resets all the EHCI control signals. This signal is active only if "Dedicated AHB interface for EHCI and OHCI" is selected Phy_clk_i Local EHCI PHY Clock Function: This free-running clock provides an operating frequency in the Root Hub for clocking receive and transmit parallel data. phy_rst_i_n Power-on Reset Function: This signal is synchronous (asynchronous, if ASYNC reset option selected) to phy_clk_i, and resets all registers and state machines in receive and transmit logic. Best regards, Pengcheng Li > -Original Message- > From: Alan Stern [mailto:st...@rowland.harvard.edu] > Sent: Friday, March 18, 2016 1:52 AM > To: Lipengcheng > Cc: ba...@ti.com; chasemetzge...@gmail.com; baolu...@linux.intel.com; > mj...@coreos.com; kbo...@gmail.com; jun...@freescale.com; > robert.schlabb...@gmx.net; linux-usb@vger.kernel.org > Subject: Re: ehci and ohci reset number doubt > > On Thu, 17 Mar 2016, Lipengcheng wrote: > > > Hi, > >In the files of ohci-platform.c and ehci-platform.c, they have only a > > control reset. Can the files have one more controller reset? > > Currently only one reset is allowed. > > >Our usb2 controller using a synopsis, need bus reset, root hub reset, > > utmi reset. The usb controller of reset and clock have the same > number. > > If your platform has a Synopsis (now DesignWare) USB2 controller, why not use > the dwc2 driver that's already in the kernel? > > The ohci-platform and ehci-platform drivers already perform their own > root-hub and bus resets. They do not perform a UTMI reset, but they > do call phy_init() and phy_power_on(). Will that be good enough for you? > > Alan Stern
RE: 答复: 答复: 答复: 答复: 【xhci】suspend and resume core dump problem
Hi Thanks Baolu very much! Because of the reason usb3 module can not be used, it will affect the strong of usb3 module; 1, the xhci control is suspend and resume, why to re-allocate memory? 2, whether we can allocate memory for more times, so we can avoid the problem; Best Regards, Pengcheng Li > -Original Message- > From: Lu Baolu [mailto:baolu...@linux.intel.com] > Sent: Friday, March 25, 2016 10:19 PM > To: Lipengcheng; Mathias Nyman; gre...@linuxfoundation.org > Cc: st...@rowland.harvard.edu; ba...@ti.com; chasemetzge...@gmail.com; > mj...@coreos.com; kbo...@gmail.com; jun...@freescale.com; > robert.schlabb...@gmx.net; linux-usb@vger.kernel.org > Subject: Re: 答复: 答复: 答复: 答复: 【xhci】suspend and resume core dump problem > > Hi, > > On 03/25/2016 03:39 PM, Lipengcheng wrote: > > Hi, > >Thanks Baolu very much! > >The kernel is 3.10.Before the problem is inevitable emergence. But we > > fix patch number:b630d4b9d05ba2e66878ca4614946d0f950d4111 > and your suggest. > > Then we resume and suspend the seventh and it is ok only if the usb3 can > > not work. So the changes are effective. > > Thanks for testing. > > >In the wrong state which the usb3 can not work, we continue to suspend > > and resume. It will be core dump. Should it be a normal > phenomenon? > > dpm_run_callback(): platform_pm_resume+0x0/0x5c returns -12 > PM: Device hiusb-xhci.0 failed to resume: error -12 > > > Your xHCI host controller failed to resume. As the result, your usb3 devices > should not work. You couldn't suspend it once more either. > > Best Regards, > Baolu
RE: 答复: 答复: 答复: 答复: 【xhci】suspend and resume core dump problem
00 a681de9c a681debc a681dea8 8006c028 0002 80606560 dea0: 0007 8070b9bc a78f0a40 806476a4 a681ded4 a681dec0 8006c858 8006c290 dec0: a72b 0007 a681defc a681ded8 8006b498 8006c688 0007 a6298a00 dee0: a6298a18 a681df70 a78f0b40 802fbc0c a681df0c a681df00 802fbc2c 8006b400 df00: a681df3c a681df10 8016ebe4 802fbc18 a681df70 a724d0c0 0007 76f49000 df20: a681df70 0007 a681df6c a681df40 80104994 8016eae4 df40: a681df4c a724d0c0 a681df70 76f49000 0007 df60: a681dfa4 a681df70 80104b4c 801048cc 0022 0007 df80: 00f07008 0007 0004 80015348 a681c000 a681dfa8 dfa0: 80015100 80104b04 0007 00f07008 0005 76f49000 0007 dfc0: 0007 00f07008 0007 0004 76f49000 00f07008 7ef4bd2c dfe0: 7ef4ba40 76d9b2bc 76df9ccc 6010 0005 f5dfdfad df3d1857 [<7f8ff624>] (xhci_suspend+0x168/0x410 [xhci_hcd]) from [<7f8ff8f0>] (hiusb_xhci_hcd_drv_suspend+0x24/0x38 [xhci_hcd]) [<7f8ff8f0>] (hiusb_xhci_hcd_drv_suspend+0x24/0x38 [xhci_hcd]) from [<80352ff8>] (platform_pm_suspend+0x3c/0x64) [<80352ff8>] (platform_pm_suspend+0x3c/0x64) from [<80358538>] (dpm_run_callback+0x28/0x58) [<80358538>] (dpm_run_callback+0x28/0x58) from [<80358c98>] (__device_suspend+0x140/0x30c) [<80358c98>] (__device_suspend+0x140/0x30c) from [<80359244>] (dpm_suspend+0x70/0x21c) [<80359244>] (dpm_suspend+0x70/0x21c) from [<8035945c>] (dpm_suspend_start+0x6c/0x70) [<8035945c>] (dpm_suspend_start+0x6c/0x70) from [<8006c304>] (suspend_devices_and_enter+0x80/0x3f8) [<8006c304>] (suspend_devices_and_enter+0x80/0x3f8) from [<8006c858>] (pm_suspend+0x1dc/0x23c) [<8006c858>] (pm_suspend+0x1dc/0x23c) from [<8006b498>] (state_store+0xa4/0x134) [<8006b498>] (state_store+0xa4/0x134) from [<802fbc2c>] (kobj_attr_store+0x20/0x24) [<802fbc2c>] (kobj_attr_store+0x20/0x24) from [<8016ebe4>] (sysfs_write_file+0x10c/0x18c) [<8016ebe4>] (sysfs_write_file+0x10c/0x18c) from [<80104994>] (vfs_write+0xd4/0x1a0) [<80104994>] (vfs_write+0xd4/0x1a0) from [<80104b4c>] (SyS_write+0x54/0x80) [<80104b4c>] (SyS_write+0x54/0x80) from [<80015100>] (ret_fast_syscall+0x0/0x30) Code: e30c0fb0 e59f12a8 e3470f90 e300234e (e5965018) ---[ end trace 719c467f2461e924 ]--- > -Original Message- > From: Lu Baolu [mailto:baolu...@linux.intel.com] > Sent: Thursday, March 24, 2016 10:37 AM > To: Lipengcheng; Mathias Nyman; gre...@linuxfoundation.org > Cc: st...@rowland.harvard.edu; ba...@ti.com; chasemetzge...@gmail.com; > mj...@coreos.com; kbo...@gmail.com; jun...@freescale.com; > robert.schlabb...@gmx.net; linux-usb@vger.kernel.org > Subject: Re: 答复: 答复: 答复: 答复: 【xhci】suspend and resume core dump problem > > Hi, > > On 03/23/2016 11:38 AM, Lipengcheng wrote: > >> It looks like a wild pointer exists after xhci_mem_cleanup() is called. > >> >Let me try to reproduce it and seek for a fix. > > > > Hi, > >Thanks very much. > >The kernel is 3.10 and is inevitable emergence. The kernel 3.18 is > > accidental, but I don't know the reason. > > > > Operation steps: > > > > usb usb1: root hub lost power or was reset usb usb2: root hub lost > > power or was reset usb usb3: root hub lost power or was reset usb > > usb4: root hub lost power or was reset usb 1-2: reset high-speed USB > > device number 2 using hiusb-ehci > > ^Cusb usb5: root hub lost power or was reset <-press ctrl > > +c and the problem will happen > > usb usb6: root hub lost power or was reset > > Can you please test below change? It doesn't fix your dma_alloc_coherent() > failure issue. It is supposed to fix the core dump issue when > dma_alloc_coherent() fails in xhci_mem_init(). > > diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c index > 80c1de2..53fe4ad 100644 > --- a/drivers/usb/host/xhci-mem.c > +++ b/drivers/usb/host/xhci-mem.c > @@ -1860,6 +1860,11 @@ no_bw: > kfree(xhci->port_array); > kfree(xhci->rh_bw); > kfree(xhci->ext_caps); > + xhci->usb2_ports = NULL; > + xhci->usb3_ports = NULL; > + xhci->port_array = NULL; > + xhci->rh_bw = NULL; > + xhci->ext_caps = NULL; > > xhci->page_size = 0; > xhci->page_shift = 0; > > Best regards, > Baolu > > > Thanks, > > Pengcheng Li
ehci and ohci reset number doubt
Hi, In the files of ohci-platform.c and ehci-platform.c, they have only a control reset. Can the files have one more controller reset? Our usb2 controller using a synopsis, need bus reset, root hub reset, utmi reset. The usb controller of reset and clock have the same number. Such as: Thanks very much Best Regards, Pengcheng Li
答复: Re:
Thank you very much for your reply, Your reply can solve our problems, thank you Best Regards, Pengcheng Li -邮件原件- 发件人: Matthew Dharm [mailto:mdharm-...@one-eyed-alien.net] 发送时间: 2016年3月3日 23:45 收件人: Lipengcheng 抄送: gre...@linuxfoundation.org; linux-usb@vger.kernel.org 主题: Re: The delay is present because we discovered many usb-storage devices that were not ready to accept commands immediately after insertion. We studied the behavior of Microsoft Windows and discovered it used a small delay before sending commands to the device, and thus we also implemented a delay. Some devices will work with delay_use = 0. Some will not. Matt On Thu, Mar 3, 2016 at 4:24 AM, Lipengcheng wrote: > Hi, > >Please tell me why the process to delay to call in the 1s? The > delay_use = 0, we also found no side effects.So we can set the delay_use = 0? > > > > drivers/usb/storage/usb.c > > > > Best Regards, > > Pengcheng Li -- Matthew Dharm Maintainer, USB Mass Storage driver for Linux
