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;
Date:   Mon, 10 Sep 2018 12:44:54 +0300
From:   Mika Westerberg <mika.westerberg@linux.intel.com>
To:     Lukas Wunner <lukas@wunner.de>
Cc:     Andreas Noever <andreas.noever@gmail.com>,
        Michael Jamet <michael.jamet@intel.com>,
        Yehezkel Bernat <YehezkelShB@gmail.com>,
        Stephen Hemminger <stephen@networkplumber.org>,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH 4/5] thunderbolt: Correlate PCI devices with Thunderbolt
 ports
Message-ID: <20180910094454.GJ14465@lahna.fi.intel.com>
References: <cover.1536517047.git.lukas@wunner.de>
 <f53ea40a7487e145aa1a62c347cef1814072e140.1536517047.git.lukas@wunner.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <f53ea40a7487e145aa1a62c347cef1814072e140.1536517047.git.lukas@wunner.de>
Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hi Lukas,

On Sun, Sep 09, 2018 at 11:42:01PM +0200, Lukas Wunner wrote:
> Ideas what we can do with correlation:
> 
> * Represent the relationship between PCI devices and Thunderbolt ports
>   with symlinks in sysfs.

I wonder is that really useful? I don't think we should be adding sysfs
entries without any real reason why it would be needed and who would be
using them.

> * Thunderbolt controllers up to revision 1 of Cactus Ridge 4C have to
>   use INTx because MSI signaling is broken.  This results in hotplug
>   ports sharing interrupts with other devices and, when daisy-chaining
>   multiple affected Thunderbolt controllers, can lead to extremely
>   unbalanced interrupt usage.  To avoid this we could prefer downstream
>   ports for tunnel establishment which do not share interrupts (based
>   on the nr_actions field of the correlated PCI device's irq_desc).
> 
> * Alternatively, we could use non-working MSI signaling on affected
>   controllers and synthesize an interrupt whenever a tunnel is
>   established or goes down on unplug.

Problem I see with this patch as it stands is that you add 200+ lines of
code into the driver that is not being used by anything as far as I
understand it.