From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S968859AbdEYIFd (ORCPT <rfc822;w@1wt.eu>);
        Thu, 25 May 2017 04:05:33 -0400
Received: from mga11.intel.com ([192.55.52.93]:1488 "EHLO mga11.intel.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S968616AbdEYIEY (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Thu, 25 May 2017 04:04:24 -0400
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.38,390,1491289200"; 
   d="scan'208";a="1152609416"
Date: Thu, 25 May 2017 11:04:08 +0300
From: "mika.westerberg@linux.intel.com" <mika.westerberg@linux.intel.com>
To: "Jamet, Michael" <michael.jamet@intel.com>
Cc: "Mario.Limonciello@dell.com" <Mario.Limonciello@dell.com>,
        "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
        "andreas.noever@gmail.com" <andreas.noever@gmail.com>,
        "Bernat, Yehezkel" <yehezkel.bernat@intel.com>,
        "lukas@wunner.de" <lukas@wunner.de>,
        "Levy, Amir (Jer)" <amir.jer.levy@intel.com>,
        "luto@kernel.org" <luto@kernel.org>,
        "Jared.Dominguez@dell.com" <Jared.Dominguez@dell.com>,
        "andriy.shevchenko@linux.intel.com" 
        <andriy.shevchenko@linux.intel.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 00/24] Thunderbolt security levels and NVM firmware
 upgrade
Message-ID: <20170525080408.GO8541@lahna.fi.intel.com>
References: <c490d209d0584114b7e8cb6627b4ee91@ausx13mpc120.AMER.DELL.COM>
 <20170520082412.GI8541@lahna.fi.intel.com>
 <20170522113709.GX8541@lahna.fi.intel.com>
 <e8face149c224715ab7f6ea15191f181@ausx13mpc120.AMER.DELL.COM>
 <20170522204836.GH8541@lahna.fi.intel.com>
 <3d6c6af6ef3c41bf9ebab9875a8f6689@ausx13mpc120.AMER.DELL.COM>
 <20170524111120.GA8541@lahna.fi.intel.com>
 <e1d99fcdd757474e926525d5bcf938d4@ausx13mpc120.AMER.DELL.COM>
 <BC567D27D6B7384F84318942321624DE3AB91DDD@hasmsx109.ger.corp.intel.com>
 <20170525072010.GK8541@lahna.fi.intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20170525072010.GK8541@lahna.fi.intel.com>
Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
User-Agent: Mutt/1.7.1 (2016-10-04)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Thu, May 25, 2017 at 10:20:10AM +0300, mika.westerberg@linux.intel.com wrote:
> On Wed, May 24, 2017 at 07:32:45PM +0000, Jamet, Michael wrote:
> > I talked to our BIOS expert today. Here is his advice to debugging further:
> > 
> > It looks like something may have been wrong from system (BIOS, FW, others...) perspective.
> > On reboot need to enter EFI shell and check resources of 
> > pci 0000:01:00.0: bridge.
> > At the EFI shell, this bridge MUST be either configured or absent.
> > 
> > I would start this way, once we have this info, we may circle back to
> > him and look into next debugging step.
> 
> Thanks, I'll try this today.


This is the contents dumped directly from EFI shell when a device is
connected. It seems that the vendor_id/device_id is 0xffff but the rest
of the config seems to be present (although not fully configured):

  PCI Segment 00 Bus 01 Device 00 Func 00 [EFI 0001000000]
  00000000: FF FF FF FF 00 00 10 00-00 00 04 06 00 00 01 00  *................*
  00000010: 00 00 00 00 00 00 00 00-00 00 00 00 01 01 00 00  *................*
  00000020: 00 00 00 00 01 00 01 00-00 00 00 00 00 00 00 00  *................*
  00000030: 00 00 00 00 80 00 00 00-00 00 00 00 FF 01 00 00  *................*
  00000040: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  *................*
  00000050: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  *................*
  00000060: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  *................*
  00000070: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  *................*
  00000080: 01 88 C3 FF 08 00 00 00-05 AC 80 00 00 00 00 00  *................*
  00000090: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  *................*
  000000A0: 00 00 00 00 00 00 00 00-00 00 00 00 0D C0 00 00  *................*
  000000B0: 22 22 11 11 00 00 00 00-00 00 00 00 00 00 00 00  *""..............*
  000000C0: 10 00 52 00 20 80 E8 07-10 28 10 00 43 5C 45 00  *..R. ....(..C\E.*
  000000D0: 00 00 23 10 00 00 00 00-00 00 00 00 00 00 00 00  *..#.............*
  000000E0: 00 00 00 00 00 08 00 00-00 00 00 00 0E 00 00 00  *................*
  000000F0: 03 00 1E 00 00 00 00 00-00 00 00 00 00 00 00 00  *................*

I wonder how Linux manages to find the device if vendor_id/device_id
reads 0xffff?