Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp2701782yba; Mon, 8 Apr 2019 02:51:31 -0700 (PDT) X-Google-Smtp-Source: APXvYqxSGHkJDjuyoB+kagCKEwQsjdvLkUw+ry3SKL0pYqD+ie9BBrpgC3o1o/xkjbem41whCxgp X-Received: by 2002:a63:7154:: with SMTP id b20mr27611709pgn.359.1554717090937; Mon, 08 Apr 2019 02:51:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554717090; cv=none; d=google.com; s=arc-20160816; b=RrK3GG2yRItWrkZpGDKNA8zKLbJXtcBrX1wvEXv1xN04myk25vJERDVCEf4D4Egn0d +c87BR8Q4qsUYZReWDF7EpqUSZHJveDRf4nKRYvtDD8V+9gNd2p5IErQdg4+4uVyc/D2 Kcg/65XlaNx6t3BVovJokvQ14Uy0IicYIJX1N+oxxnI40SSlZ6T28/zS9IP3EArw7eX1 bZOfvtL2a3CbM3Iy+eAhx/WerGDTnL/uwQOjyEGSyCrMGzgf+NvsKt7rLWFvjRgLzR9s 8onvKLKM0TiHeSUTgFGxzzGTU3X5+Y+1Q7/IjLS+tEWXpmRiN0ubsVojMq7oOH7N2+UK i3sw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=MsPUuHw6AW/wQnDbNywdnC0zAReJTmK/wjBfGOfYklI=; b=j5JJ0lcTG+2ZvND6KPLNbOSAcuR0Figjp7hljS3dhQDAQRrRmoUZ7Dq8BIwvFoRuXR a0BXLANf0EHR+B2C9gYROZ6DYe/Wf1p2T8EWDC/sVtfVM7XYzz6wmcGS0xGsBVKHzgl6 wG2rd+HUElkFrgc5Wp3P1DeKDgc5XrYNH9vt7Qx8W95CSr8jpdQjmPZN1V5ZyAlLlIWt OIbhMW/dI7y69BDQR3xmCoVrM/O0agcFs5Mhj/iNj8Sdqqx9VOtkyQY5UMqWKylwH/a2 cf0VkvZunoOkBJxIpsXC+TWOsQUoe8bocWUwejsp2E19GUB8rlUylB037qdjEAS8HfLu pJHA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p3si25484337plr.45.2019.04.08.02.51.15; Mon, 08 Apr 2019 02:51:30 -0700 (PDT) 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; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726672AbfDHJtG (ORCPT + 99 others); Mon, 8 Apr 2019 05:49:06 -0400 Received: from bmailout1.hostsharing.net ([83.223.95.100]:46007 "EHLO bmailout1.hostsharing.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726632AbfDHJtG (ORCPT ); Mon, 8 Apr 2019 05:49:06 -0400 Received: from h08.hostsharing.net (h08.hostsharing.net [83.223.95.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.hostsharing.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (not verified)) by bmailout1.hostsharing.net (Postfix) with ESMTPS id 58AD530000CE3; Mon, 8 Apr 2019 11:49:04 +0200 (CEST) Received: by h08.hostsharing.net (Postfix, from userid 100393) id 203F656B89; Mon, 8 Apr 2019 11:49:04 +0200 (CEST) Date: Mon, 8 Apr 2019 11:49:04 +0200 From: Lukas Wunner To: Mika Westerberg Cc: linux-kernel@vger.kernel.org, Michael Jamet , Yehezkel Bernat , Andreas Noever , Andy Shevchenko , Christian Kellner , Mario.Limonciello@dell.com Subject: Re: [PATCH v3 19/36] thunderbolt: Extend tunnel creation to more than 2 adjacent switches Message-ID: <20190408094904.o3fo2anhogyxpaja@wunner.de> References: <20190328123633.42882-1-mika.westerberg@linux.intel.com> <20190328123633.42882-20-mika.westerberg@linux.intel.com> <20190407165425.2z5kqm3wcfrxvqzb@wunner.de> <20190408073517.GA3622@lahna.fi.intel.com> <20190408085337.slcnajkgxjq4twkh@wunner.de> <20190408090744.GK3622@lahna.fi.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190408090744.GK3622@lahna.fi.intel.com> User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Apr 08, 2019 at 12:07:44PM +0300, Mika Westerberg wrote: > On Mon, Apr 08, 2019 at 10:53:37AM +0200, Lukas Wunner wrote: > > Hm, what other cases are there, i.e. what is the meaning of a tb_regs_hop's > > "next_hop" field if "out_port" doesn't have a remote? (And why does it > > need to be tracked on the out_port? In case a remote is added later?) > > We also need to program HopIDs for adapter ports (PCIe, DP, NHI) in > order to enable a path. The "next_hop" from NULL port to an adapter port > tells the HopID a packet gets when it is routed to the adapter port and > the adapter port registers then are used to specify which HopID means > what (for PCIe there is only 8 but for DP there is 8 and 9, for NHI it > can be anything the service driver has negotiated). Okay, so in_hopids are the entries allocated in this port's hop config space, whereas out_hopids only really bears significance for adapter ports. For null ports (in-between two adapter ports on a path), out_hopids is identical to the in_hopids of the next hop (IIUC). That probably merits mentioning in struct tb_port's kerneldoc. Thanks, Lukas