Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Henry Lin <henryl@nvidia.com>
To:     Peter Chen <peter.chen@nxp.com>
CC:     Felipe Balbi <balbi@kernel.org>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Romain Izard <romain.izard.pro@gmail.com>,
        "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] usb: gadget: f_ncm: fix wrong usb_ep
Thread-Topic: [PATCH] usb: gadget: f_ncm: fix wrong usb_ep
Thread-Index: AQHVoCLus26pLsIkukm9vcuV6VVAeqebTyAAgAG/7WqAAA5WAIAAH+35
Date:   Tue, 26 Nov 2019 10:03:35 +0000
Message-ID: <MN2PR12MB33894E3D1D9AC14B8C9E2966AC450@MN2PR12MB3389.namprd12.prod.outlook.com>
References: <20191121041858.15746-1-henryl@nvidia.com>,<20191125042039.GA10953@b29397-desktop>
 <MN2PR12MB33899F0DEEA0A22086ACE0ECAC450@MN2PR12MB3389.namprd12.prod.outlook.com>,<VI1PR04MB53277359AF0E283AE948F34C8B450@VI1PR04MB5327.eurprd04.prod.outlook.com>
In-Reply-To: <VI1PR04MB53277359AF0E283AE948F34C8B450@VI1PR04MB5327.eurprd04.prod.outlook.com>
Accept-Language: en-US, zh-TW
received-spf: None (protection.outlook.com: nvidia.com does not designate
 permitted sender hosts)
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: f165d0b5-f4df-4150-384d-08d77257e6bb
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Nov 2019 10:03:35.0777
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: vjdeuVkdQgGqA5tzLleEr4NAogss5rlVyL3C/tB6HGU5XvHT4kDuel1ga2jXkd5mNEPeOr6ZanJCTGJxa3AHjg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR12MB3583
X-OriginatorOrg: Nvidia.com
Content-Language: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nvidia.com; s=n1;
        t=1574762619; bh=XCUz/3I4esOCmkaOsUuYOG8gu2Mosrqt8F3JbuwR1Cw=;
        h=X-PGP-Universal:ARC-Seal:ARC-Message-Signature:
         ARC-Authentication-Results:From:To:CC:Subject:Thread-Topic:
         Thread-Index:Date:Message-ID:References:In-Reply-To:
         Accept-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator:
         authentication-results:x-originating-ip:x-ms-publictraffictype:
         x-ms-office365-filtering-correlation-id:x-ms-traffictypediagnostic:
         x-microsoft-antispam-prvs:x-ms-oob-tlc-oobclassifiers:
         x-forefront-prvs:x-forefront-antispam-report:received-spf:
         x-ms-exchange-senderadcheck:x-microsoft-antispam:
         x-microsoft-antispam-message-info:x-ms-exchange-transport-forked:
         MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id:
         X-MS-Exchange-CrossTenant-originalarrivaltime:
         X-MS-Exchange-CrossTenant-fromentityheader:
         X-MS-Exchange-CrossTenant-id:X-MS-Exchange-CrossTenant-mailboxtype:
         X-MS-Exchange-CrossTenant-userprincipalname:
         X-MS-Exchange-Transport-CrossTenantHeadersStamped:X-OriginatorOrg:
         Content-Language:Content-Type:Content-Transfer-Encoding;
        b=mm18gwiLQ+NcBljt+eWqADqTjCSYod/S8GOGo2q5umLKKnlip8fhBNWU9peSeLorD
         zK23lT0yy3SWlY9+kX1eO2tRoTuxxMIzFg66/EuHmoUe68bgUJ3jAdvqe0JPxBwLMi
         WoTJYa2jY4zXzC35/aifkKw5fMrAPBToQmI1Tn1ozw/qIsLB8ZOckbh54Ho54Gc8QJ
         Pqn1lbFwEhlI166EM8bwYtFq3UFyzCI6ux7qV2V3J8qV/0acU8luWEKRrcPScjCZ+g
         tLx08dbAhkgoiQHS7Mbp+CqtaJw4UtLuSNzOvls3ENePUSq5EKFL9d/dC10EznDrNd
         rKQ46WXla36hA==
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

>> >Would you please share the use case how to reproduce it?=0A=
>> We checked again and found NCM gadget driver should not have this issue.=
=0A=
>> Please ignore this patch.=0A=
>>=0A=
>> However, we still observe similar issue in ECM and RNDIS gadget driver. =
Take=0A=
>> ECM as example, if we plug ECM gadget in high-speed host port first. And=
, the host=0A=
>> only set interface with alternate setting !=3D 1 (alt !=3D 1 in ecm_set_=
alt()) for ECM=0A=
>> gadget. Then, if we unplug gadget from high-speed host port to another s=
uper-=0A=
>> speed host port afterwards, we will see both in_ep->desc and out_ep->des=
c in ecm-=0A=
> >port keep values for high-speed endpoints. Although NCM's implementation=
 is=0A=
>> similar to ECM in this part, NCM doesn't have same issue as it only does=
=0A=
>> config_ep_by_speed() under if alt is 1.=0A=
=0A=
>Does your UDC driver call composite_disconnect when disconnect from the ho=
st?=0A=
>It should set all desc to NULL at related function ->disable.=0A=
=0A=
For ECM case, if ecm_set_alt() gets called with alt =3D=3D 0, in_ep->desc a=
nd=0A=
out_ep->desc will be set up. But these two ep will not be enabled as gether=
_connect()=0A=
is not executed. During disconnect from the host, ecm_disable() gets called=
 with ep=0A=
disabled. In this case, gether_disconnect() will not get called to set desc=
 to NULL.=