lkml.org 
[lkml]   [2019]   [Feb]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v2 16/28] thunderbolt: Discover preboot PCIe paths the boot firmware established
On Wed, Feb 06, 2019 at 04:17:26PM +0300, Mika Westerberg wrote:
> +static struct tb_port *tb_port_remote(struct tb_port *port)
> +{
> + struct tb_port *remote = port->remote;
> +
> + /*
> + * If we have a dual link, the remote is available through the
> + * primary link.
> + */
> + if (!remote && port->dual_link_port && port->dual_link_port->remote)
> + return port->dual_link_port->remote->dual_link_port;
> + return remote;
> +}

Yet more special-casing for dual-link ports. :-(


> + if (tunnel->dst_port->config.type != TB_TYPE_PCIE_UP) {
> + tb_port_warn(tunnel->dst_port,
> + "path does not end to a PCIe adapter\n");

Nit: I think the proper proposition is "on" or "at", not "to".

The tunnel discovery algorithm looks solid to me, so:
Reviewed-by: Lukas Wunner <lukas@wunner.de>

When the module is unloaded, tb_stop() currently deactivates all PCI
tunnels. Is this still a good idea now that tunnels are discovered
on probe? We could just leave the tunnels in place and rediscover
them when the module is reloaded. If something was unplugged in the
meantime, pciehp will have disconnected the devices and we should
notice on reprobe that certain tunnels cannot be rediscovered, so no
harm no foul. Thoughts?

Thanks,

Lukas

\
 
 \ /
  Last update: 2019-02-12 20:43    [W:1.089 / U:0.332 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site