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:   Ran Wang <ran.wang_1@nxp.com>
To:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CC:     Kai-Heng Feng <kai.heng.feng@canonical.com>,
        Mathias Nyman <mathias.nyman@linux.intel.com>,
        Alan Stern <stern@rowland.harvard.edu>,
        Mathias Payer <mathias.payer@nebelwelt.net>,
        Dennis Wassenberg <dennis.wassenberg@secunet.com>,
        "open list:USB SUBSYSTEM" <linux-usb@vger.kernel.org>,
        open list <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH] usb: hub add filter for device with specific VID&PID
Thread-Topic: [PATCH] usb: hub add filter for device with specific VID&PID
Thread-Index: AQHVcfycJPrHn/IcK0qf/xic1GWPZ6c5GiAAgAEI5+A=
Date:   Tue, 24 Sep 2019 03:23:52 +0000
Message-ID: <DB8PR04MB682649CA98B0704FAF037A40F1840@DB8PR04MB6826.eurprd04.prod.outlook.com>
References: <20190923105102.37413-1-ran.wang_1@nxp.com>
 <20190923110712.GA2796979@kroah.com>
In-Reply-To: <20190923110712.GA2796979@kroah.com>
Accept-Language: en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: nxp.com does not designate
 permitted sender hosts)
Content-Type: text/plain; charset="iso-8859-7"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 9bff4d26-f463-4111-e937-08d7409e9fe9
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Sep 2019 03:23:52.6790
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 1BXMyfEy37DFBqBUcXSbWp4OJ+j7nOZiNM7ki/NVNoZ41Q7tT0xlSyrDJl3P7vMGKMqLbJNFkKEZAPR50oycQA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR04MB7097
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi Greg,

On Monday, September 23, 2019 19:07, Greg Kroah-Hartman wrote:
>=20
> On Mon, Sep 23, 2019 at 06:51:02PM +0800, Ran Wang wrote:
> > USB 2.0 Embedded Host PET Automated Test (CH6) 6.7.23 A-UUT
> > "Unsupported Device" Message require to stop enumerating device with
> > VID=3D0x1a0a PID=3D0x0201 and pop message to declare this device is not
> supported.
>=20
> Why is this a requirement?

This comes from <USB On-The-Go and Embedded Host Automated Compliance Plan
for the On-The-Go& Embedded Host Supplement Revision2.0>

Below is related description I quote from it:
6.7.23 A-UUT "Unsupported Device" Message
Purpose: This test verifies that an A-UUT produces a device non-supported e=
rror message
	when a device it doesn't recognize, and does not support HNP, connects to =
it.
Applies to: All Targeted Hosts
Description: Get VBUS turned on, and connect to the A-UUT. Get enumerated a=
nd respond
	as an unknown device not supporting HNP. Check that a suitable error messa=
ge is generated.
Pass Criteria: Message "Unsupported Device"or similar is displayed on UUT

6.7.23.1 Test Procedure
1. Start with cable still attached, PET applying 10=ECF capacitance and 10k=
=D9 pull-down
    resistance between VBUS and ground, data lines not pulled up.
2. Get VBUS turned on, using the method described in Section6.7.1.
3. Wait for almost TB_SVLD_BCON max (1s - 0.1s =3D 0.9s) from VBUS reaching=
 VOTG_SESS_VLD max.
4. Connect PET using D+ pull-up.
5. Allow A-UUT to enumerate PET, responding with a VID / PID combination no=
t on the TPL
    of the UUT and also with the OTG descriptor stating that it does not su=
pport HNP.
6. Start 30s timer when Device Descriptor is read.
7. Display Message "Click OK if 'Unsupported Device' indication displayed o=
n UUT".
8. If operator clicks OK before 30s timer expires, then UUT passes test.
9. If 30selapses first, then UUT fails test.
10. PET disconnects by removing any termination on the data lines, but leav=
es a capacitance of
    10=ECF and a pull-down resistance of 10k=D9 connected across VBUS.
11. Wait 2s to allow disconnection to be detected.
End of Test.

> And why those specific vid/pid values?  What do they refer to?

For step 5, we got the VID / PID number from USB IF certified lab(Allion.in=
c at Taiwang). Looks like
this is a reserved ID pair and will not be allocated to any vendor for thei=
r products. So it's hence used for this
case test (like saying: you should be able to pop a not-support message for=
 this reserved VID&PID).
=20
> >
> > Signed-off-by: Ran Wang <ran.wang_1@nxp.com>
> > ---
> >  drivers/usb/core/hub.c | 12 ++++++++++++
> >  1 file changed, 12 insertions(+)
> >
> > diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c index
> > bbcfa63..3cda0da 100644
> > --- a/drivers/usb/core/hub.c
> > +++ b/drivers/usb/core/hub.c
> > @@ -4982,6 +4982,18 @@ static void hub_port_connect(struct usb_hub *hub=
,
> int port1, u16 portstatus,
> >  		if (status < 0)
> >  			goto loop;
> >
> > +		 /* USB 2.0 Embedded Host PET Automated Test (CH6)
> > +		 * 6.7.23 A-UUT "Unsupported Device" Message
> > +		 * require to filter out below device when enumeration
> > +		 */
>=20
> Nit, can you align your comment lines, to match the other multi-line comm=
ents
> in this file?  Otherwise it starts to look bad over time.

Yes, will update.

>=20
>=20
> > +		if ((udev->descriptor.idVendor =3D=3D 0x1a0a)
> > +		 && (udev->descriptor.idProduct =3D=3D 0x0201)) {
>=20
> Are you sure you don't have to convert this value into cpu endian before
> checking it?

Thanks for pointing out, how about this:
	if ((le16_to_cpu(udev->descriptor.idVendor) =3D=3D 0x1a0a)
	 && (le16_to_cpu(udev->descriptor.idProduct) =3D=3D 0x0201)) {

Regards,
Ran