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;
MIME-Version: 1.0
References: <DB8PR04MB682649CA98B0704FAF037A40F1840@DB8PR04MB6826.eurprd04.prod.outlook.com>
 <Pine.LNX.4.44L0.1909271305030.4732-100000@iolanthe.rowland.org>
In-Reply-To: <Pine.LNX.4.44L0.1909271305030.4732-100000@iolanthe.rowland.org>
From:   Peter Chen <hzpeterchen@gmail.com>
Date:   Sun, 29 Sep 2019 14:36:10 +0800
Message-ID: <CAL411-o-dRJ+fQTxXhVBzwdd0L6B26B_75+DKxUaLziwLkuCtg@mail.gmail.com>
Subject: Re: [PATCH] usb: hub add filter for device with specific VID&PID
To:     Alan Stern <stern@rowland.harvard.edu>
Cc:     Ran Wang <ran.wang_1@nxp.com>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Kai-Heng Feng <kai.heng.feng@canonical.com>,
        Mathias Nyman <mathias.nyman@linux.intel.com>,
        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>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Sat, Sep 28, 2019 at 1:11 AM Alan Stern <stern@rowland.harvard.edu> wrot=
e:
>
> On Tue, 24 Sep 2019, Ran Wang wrote:
>
> > Hi Greg,
> >
> > On Monday, September 23, 2019 19:07, Greg Kroah-Hartman wrote:
> > >
> > > 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 wit=
h
> > > > VID=3D0x1a0a PID=3D0x0201 and pop message to declare this device is=
 not
> > > supported.
> > >
> > > Why is this a requirement?
> >
> > This comes from <USB On-The-Go and Embedded Host Automated Compliance P=
lan
> > for the On-The-Go& Embedded Host Supplement Revision2.0>
>
> How much do we care about our support for USB OTG?  Isn't it dying off?
>

Hi Alan,

The OTG Compliance is really dead, but for non-PC host product, if we
would like to
pass USB certification, it needs to pass EH compliance test. Before
going to Lab,
the vendor will fill Compliance Checklist, it could declare HNP, SRP
and ADP are not
supported, then the PET test will bypass related test items.

Peter

> > 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-support=
ed error message
> >       when a device it doesn't recognize, and does not support HNP, con=
nects to it.
> > Applies to: All Targeted Hosts
> > Description: Get VBUS turned on, and connect to the A-UUT. Get enumerat=
ed and respond
> >       as an unknown device not supporting HNP. Check that a suitable er=
ror message is generated.
> > Pass Criteria: Message "Unsupported Device"or similar is displayed on U=
UT
> >
> > 6.7.23.1 Test Procedure
> > 1. Start with cable still attached, PET applying 10=C3=ACF capacitance =
and 10k=C3=99 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 reac=
hing VOTG_SESS_VLD max.
> > 4. Connect PET using D+ pull-up.
> > 5. Allow A-UUT to enumerate PET, responding with a VID / PID combinatio=
n not on the TPL
> >     of the UUT and also with the OTG descriptor stating that it does no=
t support HNP.
> > 6. Start 30s timer when Device Descriptor is read.
> > 7. Display Message "Click OK if 'Unsupported Device' indication display=
ed on 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 =
leaves a capacitance of
> >     10=C3=ACF and a pull-down resistance of 10k=C3=99 connected across =
VBUS.
> > 11. Wait 2s to allow disconnection to be detected.
> > End of Test.
>
> In fact, the system should respond the same way to any unrecognized
> device that doesn't support HNP, right?  There's nothing special about
> these VID/PID values.
>
> > > 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(Allio=
n.inc at Taiwang). Looks like
> > this is a reserved ID pair and will not be allocated to any vendor for =
their 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).
>
> Don't we do this already?
>
> Alan Stern
>