From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1755508AbdKBKjR (ORCPT <rfc822;w@1wt.eu>);
        Thu, 2 Nov 2017 06:39:17 -0400
Received: from mga02.intel.com ([134.134.136.20]:27949 "EHLO mga02.intel.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1752237AbdKBKjP (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Thu, 2 Nov 2017 06:39:15 -0400
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.44,333,1505804400"; 
   d="asc'?scan'208";a="331020515"
From: Felipe Balbi <felipe.balbi@linux.intel.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Lu Baolu <baolu.lu@linux.intel.com>,
        "'Mathias Nyman'" <mathias.nyman@linux.intel.com>,
        "linux-usb\@vger.kernel.org" <linux-usb@vger.kernel.org>,
        "linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3 2/3] usb: xhci: Add DbC support in xHCI driver
In-Reply-To: <20171102093216.GA16369@kroah.com>
References: <1504576740-11689-1-git-send-email-baolu.lu@linux.intel.com> <1504576740-11689-3-git-send-email-baolu.lu@linux.intel.com> <59FA76AA.4060602@linux.intel.com> <20171102081720.GA3298@kroah.com> <871slhvy68.fsf@linux.intel.com> <20171102093216.GA16369@kroah.com>
Date: Thu, 02 Nov 2017 12:38:57 +0200
Message-ID: <87y3npufr2.fsf@linux.intel.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
        micalg=pgp-sha512; protocol="application/pgp-signature"
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

--=-=-=
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable


Hi,

Greg Kroah-Hartman <gregkh@linuxfoundation.org> writes:
>> Greg Kroah-Hartman <gregkh@linuxfoundation.org> writes:
>> >> > xHCI compatible USB host controllers(i.e. super-speed USB3 controll=
ers)
>> >> > can be implemented with the Debug Capability(DbC). It presents a de=
bug
>> >> > device which is fully compliant with the USB framework and provides=
 the
>> >> > equivalent of a very high performance full-duplex serial link. The =
debug
>> >> > capability operation model and registers interface are defined in 7=
.6.8
>> >> > of the xHCI specification, revision 1.1.
>> >> >
>> >> > The DbC debug device shares a root port with the xHCI host. By defa=
ult,
>> >> > the debug capability is disabled and the root port is assigned to x=
HCI.
>> >> > When the DbC is enabled, the root port will be assigned to the DbC =
debug
>> >> > device, and the xHCI sees nothing on this port. This implementation=
 uses
>> >> > a sysfs node named <dbc> under the xHCI device to manage the enabli=
ng
>> >> > and disabling of the debug capability.
>> >> >
>> >> > When the debug capability is enabled, it will present a debug device
>> >> > through the debug port. This debug device is fully compliant with t=
he
>> >> > USB3 framework, and it can be enumerated by a debug host on the oth=
er
>> >> > end of the USB link. As soon as the debug device is configured, a T=
TY
>> >> > serial device named /dev/ttyDBC0 will be created.
>> >> >
>> >> > One use of this link is running a login service on the debug target.
>> >> > Hence it can be remote accessed by a debug host. Another use case c=
an
>> >> > probably be found in servers. It provides a peer-to-peer USB link
>> >> > between two host-only machines. This provides a reasonable out-of-b=
and
>> >> > communication method between two servers.
>> >> >
>> >> > Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
>> >> > ---
>> >> >  .../ABI/testing/sysfs-bus-pci-drivers-xhci_hcd     |   25 +
>> >> >  drivers/usb/host/Kconfig                           |    9 +
>> >> >  drivers/usb/host/Makefile                          |    5 +
>> >> >  drivers/usb/host/xhci-dbgcap.c                     | 1016 ++++++++=
++++++++++++
>> >> >  drivers/usb/host/xhci-dbgcap.h                     |  247 +++++
>> >> >  drivers/usb/host/xhci-dbgtty.c                     |  586 ++++++++=
+++
>> >> >  drivers/usb/host/xhci-trace.h                      |   60 ++
>> >> >  drivers/usb/host/xhci.c                            |   10 +
>> >> >  drivers/usb/host/xhci.h                            |    1 +
>> >> >  9 files changed, 1959 insertions(+)
>> >> >  create mode 100644 Documentation/ABI/testing/sysfs-bus-pci-drivers=
-xhci_hcd
>> >> >  create mode 100644 drivers/usb/host/xhci-dbgcap.c
>> >> >  create mode 100644 drivers/usb/host/xhci-dbgcap.h
>> >> >  create mode 100644 drivers/usb/host/xhci-dbgtty.c
>> >> >
>> >>=20
>> >> [snip]
>> >>=20
>> >> > +#define DBC_VENDOR_ID			0x1d6b	/* Linux Foundation 0x1d6b */
>> >> > +#define DBC_PRODUCT_ID			0x0004	/* device 0004 */
>> >> >
>> >>=20
>> >> The DbC (xHCI DeBug Capability) is an optional functionality in
>> >> some xHCI host controllers. It will present a super-speed debug
>> >> device through the debug port after it is enabled.
>> >>=20
>> >> The DbC register set defines an interface for system software
>> >> to specify the vendor id and product id of the debug device.
>> >> These two values will be presented by the debug device in its
>> >> device descriptor idVendor and idProduct fields.
>> >>=20
>> >> Microsoft Windows have a well established protocol for
>> >> debugging over DbC. And it assigns below values for its use.
>> >>=20
>> >> USB\VID_045E&PID_062D.DeviceDesc=3D"Microsoft USB Debug Target"
>> >>=20
>> >> I'm going to use 0x1d6b/0x0004 value pair for DbC use in
>> >> Linux. Do you approve me to do so?
>> >
>> > No.  Why can't you use the same ids as Windows?  This is implementing
>> > the same protocol, right?
>>=20
>> the protocol running on top is 100% vendor specific. More than likely,
>> we would just run kgdb on top of this, right? We really don't support
>> microsoft's debug architecture.
>
> Ah, I didn't know about the protocol specifics here, if it is
> vendor-specific, then yes, we need our own id.

Great, thanks :-)

Let us know which one we're allowed to use and I'm sure Baolu can respin
the patch in no time.

> As the above text said "well established protocol", I assumed we
> implemented the same thing :)

It's "well established" from Microsoft's point of view :-) They have
that same protocol running over USB, TCP, UDP...

It would be nice if we could ditch TTY and teach gdb about other
transports, but then again, why bother if we can reuse code that already
works? :-)

=2D-=20
balbi

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEElLzh7wn96CXwjh2IzL64meEamQYFAln69cIACgkQzL64meEa
mQbLyw//ULNPgzjUNxaOnrPyth9bhUR1q7C7zHXkNo1kLNkJ61RYUXgzSUNFKJpc
G6LgpuPp3Btwpijp2HJTl64Ocza8O7FLp3TDCTADKArLl2DyL/uURbc1Aq8LT2ng
A5gMDj6nOHkjodfcjuIajb3RnQ9ZXm6xO54e3b83V73neE5qJmSkcTEPnhtUjdZJ
3zF1eVYAqe8uqkSGfQXMiUFhXJ44nU4NRSVgH+aIwtghchhwUiwxqMt81Uk+V+iR
sNjTsLrdnEfuVTthE82FO6RXpOvaQKU1PYt82C0laMg6Whsv+x6kcMsWywZW2NTk
2vLD0IybXyHAt7YZ4PiyHk50X50wOph5URzLm8l8EQPDTtbMJ7FgYJZ2xzMto3z+
zfFULXUz2y3q2XENdtX5AVtJgBGJmO0bqkJf0jpb/3I1P+KCPjqWBJOQHfkpfMKR
ctwBPcvPKDQMFJFFVPoslB7C7pv4mTl8665WR631l4DcYhG1Lq3kseZ9XUY45sxG
OtLRf1ETMyauvhAjV9x+g+7GUt7TcDtp59uSmutQCX7ZsPMIGQ3e/YOqcIV2JXEa
ROgWogj0vsQW5OXxPLmJFQMa07lPRhhmKtpILdvlIRItLhlkJZXoOLMB1o2wjCPC
NgfLO363eVhl63VRdpVaczPHs3dhkqWq09HBiV7VXPRMoMhBypI=
=nJ6g
-----END PGP SIGNATURE-----
--=-=-=--