Some early stage USB4 devices do not like that any of the enumerating
router config space fields (ROUTER_CS_1 - ROUTER_CS_4) are written after
the initial enumeration for example when entering sleep states. The
default timeout by the USB4 spec is 10 ms which should be fine for the
driver to handle.

For this reason do not change the notification timeout from the default
10 ms for USB4 routers.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>

The TMU will be reset after router exits sleep so in order to
re-configure it upon resume make sure the structure is initialized again
based on the current hardware state.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>

First generation routers may need the reset command upon resume but it
is not supported by newer generations.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>

USB4 spec says that NFC buffers field is not used for protocol adapters,
only for lane adapters so make tb_port_add_nfc_credits() skip non-lane
adapters in order to follow the spec.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>

Doesn't really matter for an individual driver, but it may
get coppied to lots more. I consider it's a little tidy up.
Signed-off-by: NTian Tao <tiantao6@hisilicon.com>
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>

Replace the existing /* fall through */ comments and its variants with
the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary
fall-through markings when it is the case.

[1] https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-throughSigned-off-by: NGustavo A. R. Silva <gustavoars@kernel.org>

Some external devices can support completing thunderbolt authentication
when they are unplugged. For this to work though, the link controller must
remain operational.

The only device known to support this right now is the Dell WD19TB, so add
a quirk for this.
Signed-off-by: NMario Limonciello <mario.limonciello@dell.com>
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>

This allows userspace to have a shorter period of time that the device
is unusable and to call it at a more convenient time.

For example flushing the image may happen while the user is using the
machine and authenticating/rebooting may happen while logging out.
Signed-off-by: NMario Limonciello <mario.limonciello@dell.com>
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>

USB4 spec specifies standard access to retimers (both on-board and
cable) through USB4 port sideband access. This makes it possible to
upgrade their firmware in the same way than we already do with the
routers.

This enumerates on-board retimers under each USB4 port when the link
comes up and adds them to the bus under the router the retimer belongs
to. Retimers are exposed in sysfs with name like <device>:<port>.<index>
where device is the router the retimer belongs to, port is the USB4 port
the retimer is connected to and index is the retimer index under that
port (starting from 1). This applies to the upstream USB4 port as well
so if there is on-board retimer between the port and the router it is
also added accordingly.

At this time we do not add cable retimers but there is no techincal
restriction to do so in the future if needed. It is not clear whether it
makes sense to upgrade their firmwares and at least Thunderbolt 3 cables
it has not been done outside of lab environments.

The sysfs interface is made to follow the router NVM upgrade to make it
easy to extend the existing userspace (fwupd) to handle these as well.
Signed-off-by: NKranthi Kuntala <kranthi.kuntala@intel.com>
Co-developed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>

We are going to reuse some of this functionality to implement retimer
NVM upgrade so move common NVM functionality into its own file. We also
rename the structure from tb_switch_nvm to tb_nvm to make it clear that
it is not just for switches.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>

With USB4 Intel is also using its USB-IF ID (0x8087) with the new
devices. The NVM format is the same. Add this to the driver so NVM
upgrade is possible with these devices as well.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>

We need to call this from tb.c when we improve the bandwidth management
to take USB3 into account.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>

USB4 makes it possible to have tree topology of devices connected in the
same way than USB3. This was actually possible in Thunderbolt 1, 2 and 3
as well but all the available devices only had two ports which allows
building only daisy-chains of devices.

With USB4 it is possible for example that there is DP IN adapter as part
of eGPU device router and that should be tunneled over the tree topology
to a DP OUT adapter. This updates the tb_next_port_on_path() to support
such topologies.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>

NHI (The host interface adapter) is allowed to use HopIDs 1-7 as well so
relax the restriction in tb_port_alloc_hopid() to support this.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>

Previously we used pcie_find_root_port() to find a Root Port from a PCIe
device and pci_find_pcie_root_port() to find a Root Port from a
Conventional PCI device.

Unify the two functions and use pcie_find_root_port() to find a Root Port
from either a Conventional PCI device or a PCIe device.  Then there is no
need to distinguish the type of the device.

Link: https://lore.kernel.org/r/1589019568-5216-1-git-send-email-yangyicong@hisilicon.comSigned-off-by: NYicong Yang <yangyicong@hisilicon.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: Kalle Valo <kvalo@codeaurora.org> # wireless
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> # thunderbolt

This reverts commit 03cd45d2.

Commit 664f0549 ("nvmem: core: use is_bin_visible for permissions")
incidentally adds support for write-only nvmem. Hence, this workaround
is no longer required, so drop it.
Signed-off-by: NNicholas Johnson <nicholas.johnson-opensource@outlook.com.au>
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>

This function is type bool, and it's supposed to return true on success.
Unfortunately, this path takes negative error codes and casts them to
bool (true) so it's treated as success instead of failure.

Fixes: 91c0c120 ("thunderbolt: Add support for lane bonding")
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>

The driver does not populate .reg_read callback for the non-active NVMem
because the file is supposed to be write-only. However, it turns out
NVMem subsystem does not yet support this and expects that the .reg_read
callback is provided. If user reads the binary attribute it triggers
NULL pointer dereference like this one:

  BUG: kernel NULL pointer dereference, address: 0000000000000000
  ...
  Call Trace:
   bin_attr_nvmem_read+0x64/0x80
   kernfs_fop_read+0xa7/0x180
   vfs_read+0xbd/0x170
   ksys_read+0x5a/0xd0
   do_syscall_64+0x43/0x150
   entry_SYSCALL_64_after_hwframe+0x44/0xa9

Fix this in the driver by providing .reg_read callback that always
returns an error.
Reported-by: NNicholas Johnson <nicholas.johnson-opensource@outlook.com.au>
Fixes: e6b245cc ("thunderbolt: Add support for host and device NVM firmware upgrade")
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20200213095604.1074-1-mika.westerberg@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

In the case where the call tb_switch_exceeds_max_depth is true
the error reurn path leaks memory in sw.  Fix this by setting
the return error code to -EADDRNOTAVAIL and returning via the
error exit path err_free_sw_ports to free sw. sw has been kzalloc'd
so the free of the NULL sw->ports is fine.

Addresses-Coverity: ("Resource leak")
Fixes: b0407983 ("thunderbolt: Add initial support for USB4")
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Link: https://lore.kernel.org/r/20191220220526.11307-1-colin.king@canonical.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

USB4 added a capability to tunnel USB 3.x protocol over the USB4
fabric. USB4 device routers may include integrated SuperSpeed HUB or a
function or both. USB tunneling follows PCIe so that the tunnel is
created between the parent and the child router from USB3 downstream
adapter port to USB3 upstream adapter port over a single USB4 link.

This adds support for USB 3.x tunneling and also capability to discover
existing USB 3.x tunnels (for example created by connection manager in
boot firmware).
Signed-off-by: NRajmohan Mani <rajmohan.mani@intel.com>
Co-developed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Link: https://lore.kernel.org/r/20191217123345.31850-9-mika.westerberg@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Time Management Unit (TMU) is included in each USB4 router. It is used
to synchronize time across the USB4 fabric. By default when USB4 router
is plugged to the domain, its TMU is turned off. This differs from
Thunderbolt (1, 2 and 3) devices whose TMU is by default configured to
bi-directional HiFi mode. Since time synchronization is needed for
proper Display Port tunneling this means we need to configure the TMU on
USB4 compliant devices.

The USB4 spec allows some flexibility on how the TMU can be configured.
This makes it possible to enable link power management states (CLx) in
certain topologies, where for example DP tunneling is not used. TMU can
also be re-configured dynamicaly depending on types of tunnels created
over the USB4 fabric.

In this patch we simply configure the TMU to be in bi-directional HiFi
mode. This way we can tunnel any kind of traffic without need to perform
complex steps to re-configure the domain dynamically. We can add more
fine-grained TMU configuration later on when we start enabling CLx
states.
Signed-off-by: NRajmohan Mani <rajmohan.mani@intel.com>
Co-developed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Link: https://lore.kernel.org/r/20191217123345.31850-8-mika.westerberg@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

USB4 is the public specification based on Thunderbolt 3 protocol. There
are some differences in register layouts and flows. In addition to PCIe
and DP tunneling, USB4 supports tunneling of USB 3.x. USB4 is also
backward compatible with Thunderbolt 3 (and older generations but the
spec only talks about 3rd generation). USB4 compliant devices can be
identified by checking USB4 version field in router configuration space.

This patch adds initial support for USB4 compliant hosts and devices
which enables following features provided by the existing functionality
in the driver:

  - PCIe tunneling
  - Display Port tunneling
  - Host and device NVM firmware upgrade
  - P2P networking

This brings the USB4 support to the same level that we already have for
Thunderbolt 1, 2 and 3 devices.

Note the spec talks about host and device "routers" but in the driver we
still use term "switch" in most places. Both can be used interchangeably.
Co-developed-by: NRajmohan Mani <rajmohan.mani@intel.com>
Signed-off-by: NRajmohan Mani <rajmohan.mani@intel.com>
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Link: https://lore.kernel.org/r/20191217123345.31850-5-mika.westerberg@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

We will be needing this when adding initial USB4 support so make it
available to other files in the driver as well. We also rename it to
tb_switch_find_port() to follow conventions used in switch.c.

No functional changes.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Link: https://lore.kernel.org/r/20191217123345.31850-2-mika.westerberg@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

On zang's Dell XPS 13 9370 after Thunderbolt NVM firmware upgrade the
Thunderbolt controller did not come back as expected. Only after the
system was rebooted it became available again. It is not entirely clear
what happened but I suspect the new NVM firmware image authentication
failed for some reason. Regardless of this the router needs to be power
cycled if NVM authentication fails in order to get it fully functional
again.

This modifies the driver to issue a power cycle in case the NVM
authentication fails immediately when dma_port_flash_update_auth()
returns. We also need to call tb_switch_set_uuid() earlier to be able to
fetch possible NVM authentication failure when DMA port is added.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=205457Reported-by: Nzang <dump@tzib.net>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

To perform proper Display Port tunneling for Thunderbolt 3 devices we
need to allocate DP resources for DP IN port before they can be used.
The reason for this is that the user can also connect a monitor directly
to the Type-C ports in which case the Thunderbolt controller acts as
re-driver for Display Port (no tunneling takes place) taking the DP
sinks away from the connection manager. This allocation is done using
special sink allocation registers available through the link controller.

We can pair DP IN to DP OUT only if

 * DP IN has sink allocated via link controller
 * DP OUT port receives hotplug event

For DP IN adapters (only for the host router) we first query whether
there is DP resource available (it may be the previous instance of the
driver for example already allocated it) and if it is we add it to the
list. We then update the list when after each plug/unplug event to a DP
IN/OUT adapter. Each time the list is updated we try to find additional
DP IN <-> DP OUT pairs for tunnel establishment. This strategy also
makes it possible to establish another tunnel in case there are 3
monitors connected and one gets unplugged releasing the DP IN adapter
for the new tunnel.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>

We currently read how sibling lane adapter ports relate each other from
DROM (Device ROM). If the two lane adapter ports go through the same
physical connector these lanes can then be bonded together. However,
some cases DROM does not provide this information or it is missing
completely (host routers typically do not have DROM). In this case we
have hard-coded the relationship.

Expand this to work with both legacy devices where lane adapter ports 1
and 2, and 3 and 4 are always linked together, and with USB4 devices
where lane adapter 1 is always following lane adapter 0 or is disabled
completely (see USB4 section 5.2.1 for more information).
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>

Lane bonding allows aggregating two 10/20 Gb/s (depending on the
generation) lanes into a single 20/40 Gb/s bonded link. This allows
sharing the full bandwidth more efficiently. In order to establish lane
bonding we need to check that lane bonding is possible through link
controller and that both ends of the link actually supports 2x widths.
This also means that all the paths should be established through the
primary port so update tb_path_alloc() to handle this as well.

Lane bonding is supported starting from Falcon Ridge (2nd generation)
controllers.

We also expose the current speed and number of lanes under each device
except the host router following similar attribute naming than USB bus.
Expose speed and number of lanes for both directions to allow possibility
of asymmetric link in the future.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>

There are quite many places in the driver where we iterate over each
port in the switch. To make it bit more convenient, add a macro that can
be used to iterate over each port and convert existing call sites to use it.

This is based on code by Lukas Wunner.

No functional changes.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>

Now that USB4 spec has names for these DP adapter registers we can use
them instead. This makes it easier to match certain register to the spec.

No functional changes.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>

Now that USB4 spec has names for these PCIe adapter registers we can use
them instead. This makes it easier to match certain register to the spec.

No functional changes.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>

Now that USB4 spec has names for these basic registers we can use them
instead. This makes it easier to match certain register to the spec.

No functional changes.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>

If we fail to add a switch for some reason log an error instead of
keeping silent. This is useful for debugging.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>

We currently differentiate between SW CM (Software Connection Manager,
sometimes also called External Connection Manager) and ICM (Firmware
based Connection Manager, Internal Connection Manager) by looking
directly at the sw->config.enabled field which may be rather hard to
understand for the casual reader. For this reason introduce a wrapper
function with documentation that should make the intention more clear.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>

The Thunderbolt standard went through several major iterations, here
called generation. USB4, which will be based on Thunderbolt, will be
generation 4. Let userspace know the generation of the controller in
the devices in order to distinguish between Thunderbolt and USB4, so
it can be shown in various user interfaces.
Signed-off-by: NChristian Kellner <christian@kellner.me>
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>

When lockdep is enabled, plugging Thunderbolt dock on Dominik's laptop
triggers following splat:

  ======================================================
  WARNING: possible circular locking dependency detected
  5.3.0-rc6+ #1 Tainted: G                T
  ------------------------------------------------------
  pool-/usr/lib/b/1258 is trying to acquire lock:
  000000005ab0ad43 (pci_rescan_remove_lock){+.+.}, at: authorized_store+0xe8/0x210

  but task is already holding lock:
  00000000bfb796b5 (&tb->lock){+.+.}, at: authorized_store+0x7c/0x210

  which lock already depends on the new lock.

  the existing dependency chain (in reverse order) is:

  -> #1 (&tb->lock){+.+.}:
         __mutex_lock+0xac/0x9a0
         tb_domain_add+0x2d/0x130
         nhi_probe+0x1dd/0x330
         pci_device_probe+0xd2/0x150
         really_probe+0xee/0x280
         driver_probe_device+0x50/0xc0
         bus_for_each_drv+0x84/0xd0
         __device_attach+0xe4/0x150
         pci_bus_add_device+0x4e/0x70
         pci_bus_add_devices+0x2e/0x66
         pci_bus_add_devices+0x59/0x66
         pci_bus_add_devices+0x59/0x66
         enable_slot+0x344/0x450
         acpiphp_check_bridge.part.0+0x119/0x150
         acpiphp_hotplug_notify+0xaa/0x140
         acpi_device_hotplug+0xa2/0x3f0
         acpi_hotplug_work_fn+0x1a/0x30
         process_one_work+0x234/0x580
         worker_thread+0x50/0x3b0
         kthread+0x10a/0x140
         ret_from_fork+0x3a/0x50

  -> #0 (pci_rescan_remove_lock){+.+.}:
         __lock_acquire+0xe54/0x1ac0
         lock_acquire+0xb8/0x1b0
         __mutex_lock+0xac/0x9a0
         authorized_store+0xe8/0x210
         kernfs_fop_write+0x125/0x1b0
         vfs_write+0xc2/0x1d0
         ksys_write+0x6c/0xf0
         do_syscall_64+0x50/0x180
         entry_SYSCALL_64_after_hwframe+0x49/0xbe

  other info that might help us debug this:
   Possible unsafe locking scenario:
         CPU0                    CPU1
         ----                    ----
    lock(&tb->lock);
                                 lock(pci_rescan_remove_lock);
                                 lock(&tb->lock);
    lock(pci_rescan_remove_lock);

   *** DEADLOCK ***
  5 locks held by pool-/usr/lib/b/1258:
   #0: 000000003df1a1ad (&f->f_pos_lock){+.+.}, at: __fdget_pos+0x4d/0x60
   #1: 0000000095a40b02 (sb_writers#6){.+.+}, at: vfs_write+0x185/0x1d0
   #2: 0000000017a7d714 (&of->mutex){+.+.}, at: kernfs_fop_write+0xf2/0x1b0
   #3: 000000004f262981 (kn->count#208){.+.+}, at: kernfs_fop_write+0xfa/0x1b0
   #4: 00000000bfb796b5 (&tb->lock){+.+.}, at: authorized_store+0x7c/0x210

  stack backtrace:
  CPU: 0 PID: 1258 Comm: pool-/usr/lib/b Tainted: G                T 5.3.0-rc6+ #1

On an system using ACPI hotplug the host router gets hotplugged first and then
the firmware starts sending notifications about connected devices so the above
scenario should not happen in reality. However, after taking a second
look at commit a03e8289 ("thunderbolt: Serialize PCIe tunnel
creation with PCI rescan") that introduced the locking, I don't think it
is actually correct. It may have cured the symptom but probably the real
root cause was somewhere closer to PCI stack and possibly is already
fixed with recent kernels. I also tried to reproduce the original issue
with the commit reverted but could not.

So to keep lockdep happy and the code bit less complex drop calls to
pci_lock_rescan_remove()/pci_unlock_rescan_remove() in
tb_switch_set_authorized() effectively reverting a03e8289.

Link: https://lkml.org/lkml/2019/8/30/513
Fixes: a03e8289 ("thunderbolt: Serialize PCIe tunnel creation with PCI rescan")
Reported-by: NDominik Brodowski <linux@dominikbrodowski.net>
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>

When we discover existing DP tunnels the code checks whether DP IN
adapter port is enabled by calling tb_dp_port_is_enabled() before it
continues the discovery process. On Light Ridge (gen 1) controller
reading only the first dword of the DP IN config space causes subsequent
access to the same DP IN port path config space to fail or return
invalid data as can be seen in the below splat:

  thunderbolt 0000:07:00.0: CFG_ERROR(0:d): Invalid config space or offset
  Call Trace:
   tb_cfg_read+0xb9/0xd0
   __tb_path_deactivate_hop+0x98/0x210
   tb_path_activate+0x228/0x7d0
   tb_tunnel_restart+0x95/0x200
   tb_handle_hotplug+0x30e/0x630
   process_one_work+0x1b4/0x340
   worker_thread+0x44/0x3d0
   kthread+0xeb/0x120
   ? process_one_work+0x340/0x340
   ? kthread_park+0xa0/0xa0
   ret_from_fork+0x1f/0x30

If both DP In adapter config dwords are read in one go the issue does
not reproduce. This is likely firmware bug but we can work it around by
always reading the two dwords in one go. There should be no harm for
other controllers either so can do it unconditionally.

Link: https://lkml.org/lkml/2019/8/28/160Reported-by: NBrad Campbell <lists2009@fnarfbargle.com>
Tested-by: NBrad Campbell <lists2009@fnarfbargle.com>
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>

The Thunderbolt controller is integrated into the Ice Lake CPU itself
and requires special flows to power it on and off using force power bit
in NHI VSEC registers. Runtime PM (RTD3) and Sx flows also differ from
the discrete solutions. Now the firmware notifies the driver whether
RTD3 entry or exit are possible. The driver is responsible of sending
Go2Sx command through link controller mailbox when system enters Sx
states (suspend-to-mem/disk). Rest of the ICM firwmare flows follow
Titan Ridge.
Signed-off-by: NRaanan Avargil <raanan.avargil@intel.com>
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: NYehezkel Bernat <YehezkelShB@gmail.com>
Tested-by: NMario Limonciello <mario.limonciello@dell.com>

Ice Lake Thunderbolt controller NVM firmware is part of the BIOS image
which means it is not writable through the DMA port anymore. However, we
can still read it so we can keep nvm_version and active parts of NVM.
This way users still can find out the active NVM version and other
potentially useful information directly from Linux.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: NYehezkel Bernat <YehezkelShB@gmail.com>
Tested-by: NMario Limonciello <mario.limonciello@dell.com>

Thunderbolt host routers may not always contain DROM that includes
device identification information. This is mostly needed for Ice Lake
systems but some Falcon Ridge controllers on PCs also do not have DROM.

In that case hide the identification attributes.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: NYehezkel Bernat <YehezkelShB@gmail.com>
Tested-by: NMario Limonciello <mario.limonciello@dell.com>

There are two ways to mark a port as unimplemented. Typical way is to
return port type as TB_TYPE_INACTIVE when its config space is read.
Alternatively if the port is not physically present (such as ports 10
and 11 in ICL) reading from port config space returns
TB_CFG_ERROR_INVALID_CONFIG_SPACE instead. Currently the driver bails
out from adding the switch if it receives any error during port
inititialization which is wrong.

Handle this properly and just leave the port as TB_TYPE_INACTIVE before
continuing to the next port.

This also allows us to get rid of special casing for Light Ridge port 5
in eeprom.c.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: NYehezkel Bernat <YehezkelShB@gmail.com>
Tested-by: NMario Limonciello <mario.limonciello@dell.com>