mbox series

[RFC,00/22] thunderbolt: Add support for USB4

Message ID 20191001113830.13028-1-mika.westerberg@linux.intel.com (mailing list archive)
Headers show
Series thunderbolt: Add support for USB4 | expand

Message

Mika Westerberg Oct. 1, 2019, 11:38 a.m. UTC
Hi all,

I'm sending this as RFC because the series is still missing important
features such as power management so not ready for merging. However, I
think it is good to get any early feedback from the community. We are
working to add support for the missing features.

USB4 is the public specification of Thunderbolt 3 protocol and can be
downloaded here:

  https://www.usb.org/sites/default/files/USB4%20Specification_1.zip

USB4 is about tunneling different protocols over a single cable (in the
same way as Thunderbolt). The current USB4 spec supports PCIe, Display Port
and USB 3.x, and also software based protocols such as networking between
domains (hosts).

So far PCs have been using firmware based Connection Manager and Apple
systems have been using software based one. A Connection Manager is the
entity that handles creation of different tunnel types through the USB4
(and Thunderbolt) fabric. With USB4 the plan is to have software based
Connection Manager everywhere but some early systems will also support
firmware to allow OS downgrade for example.

Current Linux Thunderbolt driver supports both "modes" and can detect which
one to use dynamically.

This series first adds support for Thunderbolt 3 devices to the software
connection manager and then extends that to support USB4 compliant hosts
and devices (this applies to both firmware and software based connection
managers). With this series the following features are supported also for
USB4 compliant devices:

  - PCIe tunneling
  - Display Port tunneling
  - USB 3.x tunneling
  - P2P networking (implemented in drivers/net/thunderbolt.c)
  - Host and device NVM firmware upgrade

We also add two new sysfs attributes under each device that expose link
speed and width to userspace. The rest of the userspace ABI stays the same.

I'm including Linux USB folks as well because USB4 is officially coming
from USB-IF which puts us on same boat now.

While I changed the user visible Kconfig string to mention "USB4" (the
Kconfig option is still CONFIG_THUNDERBOLT), I'm wondering whether we
should move the whole Thunderbolt driver under drivers/usb/thunderbolt as
well? 

Mika Westerberg (19):
  thunderbolt: Introduce tb_switch_is_icm()
  thunderbolt: Log switch route string on config read/write timeout
  thunderbolt: Log warning if adding switch fails
  thunderbolt: Make tb_sw_write() take const parameter
  thunderbolt: Add helper macros to iterate over switch ports
  thunderbolt: Add support for lane bonding
  thunderbolt: Add default linking between ports if not provided by DROM
  thunderbolt: Add downstream PCIe port mappings for Alpine and Titan Ridge
  thunderbolt: Convert basic adapter register names to follow the USB4 spec
  thunderbolt: Convert PCIe adapter register names to use USB4 names
  thunderbolt: Convert DP adapter register names to follow the USB4 spec
  thunderbolt: Add Display Port CM handshake for Titan Ridge devices
  thunderbolt: Add Display Port adapter pairing and resource management
  thunderbolt: Add bandwidth management for Display Port tunnels
  thunderbolt: Make tb_find_port() available to other files
  thunderbolt: Call tb_eeprom_get_drom_offset() from tb_eeprom_read_n()
  thunderbolt: Add initial support for USB4
  thunderbolt: Update documentation with the USB4 information
  thunderbolt: Do not start firmware unless asked by the user

Rajmohan Mani (3):
  thunderbolt: Make tb_switch_find_cap() available to other files
  thunderbolt: Add support for Time Management Unit
  thunderbolt: Add support for USB tunnels

 .../ABI/testing/sysfs-bus-thunderbolt         |  17 +
 Documentation/admin-guide/thunderbolt.rst     |  27 +-
 drivers/thunderbolt/Kconfig                   |   9 +-
 drivers/thunderbolt/Makefile                  |   2 +-
 drivers/thunderbolt/cap.c                     |  11 +-
 drivers/thunderbolt/ctl.c                     |   8 +-
 drivers/thunderbolt/eeprom.c                  | 146 +--
 drivers/thunderbolt/icm.c                     |  36 +-
 drivers/thunderbolt/lc.c                      | 193 +++-
 drivers/thunderbolt/nhi.c                     |   3 +
 drivers/thunderbolt/nhi.h                     |   2 +
 drivers/thunderbolt/path.c                    |  52 +-
 drivers/thunderbolt/switch.c                  | 870 +++++++++++++++---
 drivers/thunderbolt/tb.c                      | 529 +++++++++--
 drivers/thunderbolt/tb.h                      | 198 +++-
 drivers/thunderbolt/tb_msgs.h                 |   2 +
 drivers/thunderbolt/tb_regs.h                 | 160 +++-
 drivers/thunderbolt/tmu.c                     | 380 ++++++++
 drivers/thunderbolt/tunnel.c                  | 517 ++++++++++-
 drivers/thunderbolt/tunnel.h                  |  19 +-
 drivers/thunderbolt/usb4.c                    | 761 +++++++++++++++
 drivers/thunderbolt/xdomain.c                 |   8 +-
 22 files changed, 3578 insertions(+), 372 deletions(-)
 create mode 100644 drivers/thunderbolt/tmu.c
 create mode 100644 drivers/thunderbolt/usb4.c

Comments

Greg KH Oct. 1, 2019, 12:49 p.m. UTC | #1
On Tue, Oct 01, 2019 at 02:38:08PM +0300, Mika Westerberg wrote:
> Hi all,
> 
> I'm sending this as RFC because the series is still missing important
> features such as power management so not ready for merging. However, I
> think it is good to get any early feedback from the community. We are
> working to add support for the missing features.
> 
> USB4 is the public specification of Thunderbolt 3 protocol and can be
> downloaded here:
> 
>   https://www.usb.org/sites/default/files/USB4%20Specification_1.zip
> 
> USB4 is about tunneling different protocols over a single cable (in the
> same way as Thunderbolt). The current USB4 spec supports PCIe, Display Port
> and USB 3.x, and also software based protocols such as networking between
> domains (hosts).
> 
> So far PCs have been using firmware based Connection Manager and Apple
> systems have been using software based one. A Connection Manager is the
> entity that handles creation of different tunnel types through the USB4
> (and Thunderbolt) fabric. With USB4 the plan is to have software based
> Connection Manager everywhere but some early systems will also support
> firmware to allow OS downgrade for example.
> 
> Current Linux Thunderbolt driver supports both "modes" and can detect which
> one to use dynamically.
> 
> This series first adds support for Thunderbolt 3 devices to the software
> connection manager and then extends that to support USB4 compliant hosts
> and devices (this applies to both firmware and software based connection
> managers). With this series the following features are supported also for
> USB4 compliant devices:
> 
>   - PCIe tunneling
>   - Display Port tunneling
>   - USB 3.x tunneling
>   - P2P networking (implemented in drivers/net/thunderbolt.c)
>   - Host and device NVM firmware upgrade
> 
> We also add two new sysfs attributes under each device that expose link
> speed and width to userspace. The rest of the userspace ABI stays the same.
> 
> I'm including Linux USB folks as well because USB4 is officially coming
> from USB-IF which puts us on same boat now.
> 
> While I changed the user visible Kconfig string to mention "USB4" (the
> Kconfig option is still CONFIG_THUNDERBOLT), I'm wondering whether we
> should move the whole Thunderbolt driver under drivers/usb/thunderbolt as
> well? 

Looks "interesting", nice work!

I stopped at patch "Add initial support for USB4" as I don't think we
want to add USB4 code to a system that we know does not have it, right?

Everything up to then is just "normal" thunderbolt, and with the
exception of a few minor comments, all look fine to me.

I didn't actually read the USB4 patch just yet, as I figured we needed
to argue about that some more :)

thanks,

greg k-h
Mika Westerberg Oct. 1, 2019, 1:42 p.m. UTC | #2
On Tue, Oct 01, 2019 at 02:49:54PM +0200, Greg Kroah-Hartman wrote:
> On Tue, Oct 01, 2019 at 02:38:08PM +0300, Mika Westerberg wrote:
> > Hi all,
> > 
> > I'm sending this as RFC because the series is still missing important
> > features such as power management so not ready for merging. However, I
> > think it is good to get any early feedback from the community. We are
> > working to add support for the missing features.
> > 
> > USB4 is the public specification of Thunderbolt 3 protocol and can be
> > downloaded here:
> > 
> >   https://www.usb.org/sites/default/files/USB4%20Specification_1.zip
> > 
> > USB4 is about tunneling different protocols over a single cable (in the
> > same way as Thunderbolt). The current USB4 spec supports PCIe, Display Port
> > and USB 3.x, and also software based protocols such as networking between
> > domains (hosts).
> > 
> > So far PCs have been using firmware based Connection Manager and Apple
> > systems have been using software based one. A Connection Manager is the
> > entity that handles creation of different tunnel types through the USB4
> > (and Thunderbolt) fabric. With USB4 the plan is to have software based
> > Connection Manager everywhere but some early systems will also support
> > firmware to allow OS downgrade for example.
> > 
> > Current Linux Thunderbolt driver supports both "modes" and can detect which
> > one to use dynamically.
> > 
> > This series first adds support for Thunderbolt 3 devices to the software
> > connection manager and then extends that to support USB4 compliant hosts
> > and devices (this applies to both firmware and software based connection
> > managers). With this series the following features are supported also for
> > USB4 compliant devices:
> > 
> >   - PCIe tunneling
> >   - Display Port tunneling
> >   - USB 3.x tunneling
> >   - P2P networking (implemented in drivers/net/thunderbolt.c)
> >   - Host and device NVM firmware upgrade
> > 
> > We also add two new sysfs attributes under each device that expose link
> > speed and width to userspace. The rest of the userspace ABI stays the same.
> > 
> > I'm including Linux USB folks as well because USB4 is officially coming
> > from USB-IF which puts us on same boat now.
> > 
> > While I changed the user visible Kconfig string to mention "USB4" (the
> > Kconfig option is still CONFIG_THUNDERBOLT), I'm wondering whether we
> > should move the whole Thunderbolt driver under drivers/usb/thunderbolt as
> > well? 
> 
> Looks "interesting", nice work!

Thanks!

> I stopped at patch "Add initial support for USB4" as I don't think we
> want to add USB4 code to a system that we know does not have it, right?

You can connect a USB4 device to Thunderbolt 3 system. USB4 hubs
specifically are required to support this by the spec. Of course then it
is in Thunderbolt 3 alternate mode (not in USB4 native mode) but the
USB4 register set is still there. So for example we still need to
configure TMU (Time Management Unit) and access the DROM via router
operations and so on.

Do you mean we don't want that?

> Everything up to then is just "normal" thunderbolt, and with the
> exception of a few minor comments, all look fine to me.
> 
> I didn't actually read the USB4 patch just yet, as I figured we needed
> to argue about that some more :)

Heh, sure and thanks for the feedback so far :)