Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933964AbcJRHQ2 (ORCPT ); Tue, 18 Oct 2016 03:16:28 -0400 Received: from mga07.intel.com ([134.134.136.100]:55112 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933592AbcJRHPS (ORCPT ); Tue, 18 Oct 2016 03:15:18 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.31,361,1473145200"; d="asc'?scan'208";a="1055399497" From: Felipe Balbi To: Lipengcheng , Peter Chen Cc: "gregkh\@linuxfoundation.org" , "linux-usb\@vger.kernel.org" , "linux-kernel\@vger.kernel.org" Subject: RE: USB GADGET: have a question about usb2eth In-Reply-To: <637796ED17F7774FB27D6AAE3C6951584A949EA3@SZXEMA509-MBS.china.huawei.com> References: <637796ED17F7774FB27D6AAE3C6951584A949A31@SZXEMA509-MBS.china.huawei.com> <20161017015618.GB1301@b29397-desktop> <637796ED17F7774FB27D6AAE3C6951584A949CBB@SZXEMA509-MBS.china.huawei.com> <87y41ns4s5.fsf@linux.intel.com> <637796ED17F7774FB27D6AAE3C6951584A949EA3@SZXEMA509-MBS.china.huawei.com> Date: Tue, 18 Oct 2016 10:14:32 +0300 Message-ID: <871szeruw7.fsf@linux.intel.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4060 Lines: 106 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi, Lipengcheng writes: >> -----Original Message----- >> From: Felipe Balbi [mailto:balbi@kernel.org] >> Sent: Monday, October 17, 2016 5:29 PM >> To: Lipengcheng; Peter Chen >> Cc: gregkh@linuxfoundation.org; linux-usb@vger.kernel.org; linux-kernel@= vger.kernel.org >> Subject: RE: USB GADGET: have a question about usb2eth >>=20 >>=20 >> Hi, >>=20 >> (please, avoid top-posting: http://daringfireball.net/2007/07/on_top) >>=20 >> 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 =3D >> > dev->port_usb->cdc_filter in the function eth_start_xmit of the u_ethe= r.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 >>=20 >> because they are defined by different specifications. You should read bo= th 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 a= nd 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 ru= le. >>=20 >> > and USB_CDC_PACKET_TYPE_PROMISCUOUS is same, then the linux ping the >> > win7 is normal speed. >>=20 >> I don't understand what's going on here. Care to describe which kernel y= ou're using, which USB peripheral controller, what is the actual >> problem you're trying to solve? > > VERSION =3D 3.18.20 why not v4.9-rc1? We can't help you with your kernel in this forum, I reckon you realise that :-) > 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. so you're not using drivers/usb/dwc2? > 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. many have tried and succeeded before you :-) > 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. Well, if you can reproduce the same problem with v4.8 or v4.9-rc1, then we'll be happy to review your patch. Thank you =2D-=20 balbi --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJYBcvYAAoJEMy+uJnhGpkG9xUP/RFihiYkQmxb3OnxYaKaP0Ag ec6myYkxCMrJRx+MdMoMU1YA4HO5eTa6dhyAudvgeNPqDd6ayvq+muP1UQ52mZOX ssfh/lVsvCJESJupCz5XsBNt8dT/swTd69uPw0rsCd2k0TEVMn9p8AbNreVJHowd 8jNDc0KP/ZaGJi79izYFHhdr2q/inqmyPDObmalpoP5Gt+FtjhZC+c7BbUweMX/5 vmQH/BsQ94MjR9ZZG5M1WdY1IKxg5CkUXOfoPUfWfrpKYb98jwjlzbtV1uw0IgFP BebdJM/2/UVcRM+LBVS4dBoWCHeNXc8FTlBmf2b1zGrgAg1HDGSlTAJd6uIC0/g0 bebVGDnzbecXhRhhrDFYq/28y3isDyX44eXZQTvHts75tQUmYhEhxRe5Lpx2Kz4d PrXqX6T2HxMa//76oi28EecgYOe8XjYyhbc8GgN7CQKdeQmfK0L2mYoNNpRY39FS SYxKijxVF6LHvIHq1N+M3cqLhBnHL/xwAA9Su57tT1hGvXB7K9VLb7tiUxqi65wO 1Fr3x9aSpRPz7+EROamUQlfZw5f1Eo9DQoSoMYZ/JUqWajf4tYztK8KG4m03A8mQ DKPIYEXdus+MCEdSa9zClbIWsmvYajfkhsXxRl4fQZzmmu/Q3rSeTWZsYNPNtmkh i6Jk82sbTZGoNT8U7OL4 =C6e2 -----END PGP SIGNATURE----- --=-=-=--