Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1644627 > unrolled thread

[PATCH 00/24] Thunderbolt security levels and NVM firmware upgrade

Back to article view | Back to linux.kernel

Contents

  [PATCH 00/24] Thunderbolt security levels and NVM firmware upgrade Mika Westerberg <mika.westerberg@linux.intel.com> - 2017-05-18 16:50 +0200
    [PATCH 09/24] thunderbolt: Do not fail if DROM data CRC32 is invalid Mika Westerberg <mika.westerberg@linux.intel.com> - 2017-05-18 16:50 +0200
    [PATCH 16/24] thunderbolt: Add Thunderbolt 3 PCI IDs Mika Westerberg <mika.westerberg@linux.intel.com> - 2017-05-18 16:50 +0200
    [PATCH 03/24] thunderbolt: Do not warn about newer DROM versions Mika Westerberg <mika.westerberg@linux.intel.com> - 2017-05-18 16:50 +0200
    [PATCH 13/24] thunderbolt: Expose make_header() to other files Mika Westerberg <mika.westerberg@linux.intel.com> - 2017-05-18 16:50 +0200
    [PATCH 12/24] thunderbolt: Expose get_route() to other files Mika Westerberg <mika.westerberg@linux.intel.com> - 2017-05-18 16:50 +0200
    [PATCH 24/24] MAINTAINERS: Add maintainers for Thunderbolt driver Mika Westerberg <mika.westerberg@linux.intel.com> - 2017-05-18 16:50 +0200
    [PATCH 08/24] thunderbolt: Fail switch adding operation if reading DROM fails Mika Westerberg <mika.westerberg@linux.intel.com> - 2017-05-18 16:50 +0200
    Re: [PATCH 00/24] Thunderbolt security levels and NVM firmware  upgrade Mika Westerberg <mika.westerberg@linux.intel.com> - 2017-05-19 19:30 +0200
      RE: [PATCH 00/24] Thunderbolt security levels and NVM firmware  upgrade <Mario.Limonciello@dell.com> - 2017-05-19 20:00 +0200
        Re: [PATCH 00/24] Thunderbolt security levels and NVM firmware  upgrade Mika Westerberg <mika.westerberg@linux.intel.com> - 2017-05-20 10:30 +0200
          Re: [PATCH 00/24] Thunderbolt security levels and NVM firmware  upgrade Mika Westerberg <mika.westerberg@linux.intel.com> - 2017-05-22 13:40 +0200
            RE: [PATCH 00/24] Thunderbolt security levels and NVM firmware  upgrade <Mario.Limonciello@dell.com> - 2017-05-22 22:10 +0200
              RE: [PATCH 00/24] Thunderbolt security levels and NVM firmware  upgrade "Bernat, Yehezkel" <yehezkel.bernat@intel.com> - 2017-05-22 22:20 +0200
                RE: [PATCH 00/24] Thunderbolt security levels and NVM firmware  upgrade <Mario.Limonciello@dell.com> - 2017-05-23 02:00 +0200
              Re: [PATCH 00/24] Thunderbolt security levels and NVM firmware  upgrade Mika Westerberg <mika.westerberg@linux.intel.com> - 2017-05-22 23:00 +0200
                Re: [PATCH 00/24] Thunderbolt security levels and NVM firmware  upgrade Mika Westerberg <mika.westerberg@linux.intel.com> - 2017-05-24 13:20 +0200
                  RE: [PATCH 00/24] Thunderbolt security levels and NVM firmware  upgrade <Mario.Limonciello@dell.com> - 2017-05-24 21:10 +0200
                    RE: [PATCH 00/24] Thunderbolt security levels and NVM firmware  upgrade "Jamet, Michael" <michael.jamet@intel.com> - 2017-05-24 21:40 +0200
                      Re: [PATCH 00/24] Thunderbolt security levels and NVM firmware  upgrade "mika.westerberg@linux.intel.com" <mika.westerberg@linux.intel.com> - 2017-05-25 09:30 +0200
                        Re: [PATCH 00/24] Thunderbolt security levels and NVM firmware  upgrade "mika.westerberg@linux.intel.com" <mika.westerberg@linux.intel.com> - 2017-05-25 10:10 +0200
                          Re: [PATCH 00/24] Thunderbolt security levels and NVM firmware  upgrade "mika.westerberg@linux.intel.com" <mika.westerberg@linux.intel.com> - 2017-05-25 14:10 +0200
                    Re: [PATCH 00/24] Thunderbolt security levels and NVM firmware  upgrade Mika Westerberg <mika.westerberg@linux.intel.com> - 2017-05-25 09:20 +0200
      Re: [PATCH 00/24] Thunderbolt security levels and NVM firmware  upgrade Mika Westerberg <mika.westerberg@linux.intel.com> - 2017-05-19 20:10 +0200
    RE: [PATCH 00/24] Thunderbolt security levels and NVM firmware  upgrade "Levy, Amir (Jer)" <amir.jer.levy@intel.com> - 2017-05-20 11:20 +0200
      Re: [PATCH 00/24] Thunderbolt security levels and NVM firmware  upgrade "mika.westerberg@linux.intel.com" <mika.westerberg@linux.intel.com> - 2017-05-21 10:10 +0200
    Re: [PATCH 00/24] Thunderbolt security levels and NVM firmware  upgrade Andy Shevchenko <andriy.shevchenko@linux.intel.com> - 2017-05-23 15:30 +0200

Page 2 of 2 — ← Prev page 1 [2]

#1650270 — Re: [PATCH 00/24] Thunderbolt security levels and NVM firmware upgrade

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?

[toc] | [prev] | [next] | [standalone]

#1650438 — Re: [PATCH 00/24] Thunderbolt security levels and NVM firmware upgrade

On Thu, May 25, 2017 at 11:04:08AM +0300, mika.westerberg@linux.intel.com wrote:
> 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?

OK, here's the explanation.

When Linux initializes ACPI (this happens before PCI initial scan), it
calls acpi_initialize_objects(). This in turn causes _INI methods of
devices to be executed. Now, the _SB.PCI0._INI() ends up calling
\_GPE.TINI() which executes Thunderbolt specific OSUP() method. Purpose
of this method is to overwrite vendor_id/device_id to the correct values
with the assumption that the OS has already done the initial PCI scan.

In case of Linux this is not true and that is the reason the upstream
port is found half-initialized leading to the failure.

[toc] | [prev] | [next] | [standalone]

#1650248 — Re: [PATCH 00/24] Thunderbolt security levels and NVM firmware upgrade

On Wed, May 24, 2017 at 07:06:33PM +0000, Mario.Limonciello@dell.com wrote:
> > -----Original Message-----
> > From: Mika Westerberg [mailto:mika.westerberg@linux.intel.com]
> > Sent: Wednesday, May 24, 2017 6:11 AM
> > To: Limonciello, Mario <Mario_Limonciello@Dell.com>
> > Cc: gregkh@linuxfoundation.org; andreas.noever@gmail.com;
> > michael.jamet@intel.com; yehezkel.bernat@intel.com; lukas@wunner.de;
> > amir.jer.levy@intel.com; luto@kernel.org; Dominguez, Jared
> > <Jared_Dominguez@DELL.com>; andriy.shevchenko@linux.intel.com; linux-
> > kernel@vger.kernel.org
> > Subject: Re: [PATCH 00/24] Thunderbolt security levels and NVM firmware upgrade
> > 
> > On Tue, May 23, 2017 at 05:30:43PM +0000, Mario.Limonciello@dell.com wrote:
> > > (Sorry my email client is not going to wrap these at 80 columns)o
> > 
> > That's fine. It is more readable this way :)
> > 
> > > [    0.467319] pci 0000:00:1c.0: [8086:9d10] type 01 class 0x060400
> > > [    0.467389] pci 0000:00:1c.0: PME# supported from D0 D3hot D3cold
> > > [    0.467513] pci 0000:00:1c.0: System wakeup disabled by ACPI
> > 
> > [...]
> > 
> > > [    0.469363] pci 0000:01:00.0: [8086:1576] type 01 class 0x060400
> > > [    0.469483] pci 0000:01:00.0: supports D1 D2
> > > [    0.469484] pci 0000:01:00.0: PME# supported from D0 D1 D2 D3hot D3cold
> > > [    0.469570] pci 0000:01:00.0: System wakeup disabled by ACPI
> > > [    0.469609] pci 0000:00:1c.0: PCI bridge to [bus 01-39]
> > > [    0.469614] pci 0000:00:1c.0:   bridge window [mem 0xc4000000-0xda0fffff]
> > > [    0.469618] pci 0000:00:1c.0:   bridge window [mem 0xa0000000-0xc1ffffff
> > 64bit pref]
> > > [    0.469621] pci 0000:01:00.0: bridge configuration invalid ([bus 00-00]),
> > reconfiguring
> > 
> > This is the problem. Here the PCIe upstream port (0000:01:00.0) is
> > visible to Linux but it is not fully configured by the BIOS ->
> > (primary/secondary/subordinate) is set to 0.
> 
> So at least for me the other difference between a successful run (where you plug
> in after boot instead) is that it shows up as instead:
> PCI bridge to [bus 02-39]
> 
> Same bridge window though.
> 
> > 
> > At this point Linux decides to configure the port itself and goes wrong
> > since our allocation strategy tries to keep resource windows, including
> > reserved buses as small as possible so that everything we currently find
> > barely fits there.
> > 
> > This continues few lines below:
> > 
> > > [    0.469670] pci_bus 0000:02: busn_res: can not insert [bus 02-ff] under [bus 01-
> > 39] (conflicts with (null) [bus 01-39])
> > > [    0.469688] pci 0000:02:00.0: [8086:1576] type 01 class 0x060400
> > > [    0.469809] pci 0000:02:00.0: supports D1 D2
> > > [    0.469810] pci 0000:02:00.0: PME# supported from D0 D1 D2 D3hot D3cold
> > > [    0.469877] pci 0000:02:01.0: [8086:1576] type 01 class 0x060400
> > > [    0.470000] pci 0000:02:01.0: supports D1 D2
> > > [    0.470001] pci 0000:02:01.0: PME# supported from D0 D1 D2 D3hot D3cold
> > > [    0.470067] pci 0000:02:02.0: [8086:1576] type 01 class 0x060400
> > > [    0.470188] pci 0000:02:02.0: supports D1 D2
> > > [    0.470189] pci 0000:02:02.0: PME# supported from D0 D1 D2 D3hot D3cold
> > > [    0.470277] pci 0000:01:00.0: PCI bridge to [bus 02-ff]
> > > [    0.470283] pci 0000:01:00.0:   bridge window [io  0x0000-0x0fff]
> > > [    0.470287] pci 0000:01:00.0:   bridge window [mem 0x00000000-0x000fffff]
> > > [    0.470294] pci 0000:01:00.0:   bridge window [mem 0x00000000-0x000fffff
> > 64bit pref]
> > > [    0.470296] pci 0000:02:00.0: bridge configuration invalid ([bus 00-00]),
> > reconfiguring
> > > [    0.470304] pci 0000:02:01.0: bridge configuration invalid ([bus 00-00]),
> > reconfiguring
> > > [    0.470312] pci 0000:02:02.0: bridge configuration invalid ([bus 00-00]),
> > reconfiguring
> > 
> > Here.
> > 
> > And ends up in failure when we create PCIe tunnels later on.
> 
> For what it's worth the XPS 9365 which has a different BIOS core has these
> exact same behaviors on Linux if booted with the TBT dock plugged in.
> 
> > 
> > Now, this is probably where Windows does something else, like it may
> > skip re-configuring phase which could explain why it works. However, to
> > me this looks pretty much like a bug in the BIOS/firmware as we are
> > expecting the BIOS to configure the PCIe devices properly before the OS
> > is send ACPI hotplug event.
> > 
> 
> I'll reach out to the BIOS guys to see if they can give some more comments
> from their perspective.
> 
> I came across something interesting from browsing MSDN about this topic.
> It hasn't been updated in a long time but I think should still be a relevant 
> indication of the approach that Windows was taking and why the firmware 
> is this way and expecting OS to reconfigure.
> 
> "The BIOS cannot preconfigure PCI-to-PCI (P2P) bridges on adapters during 
> hot plug. Consequently, the operating system assigns resource windows of 
> a default size to a bridge.
> 
> I/O window. The default size for the I/O window is 4 KB in Windows 2000, 
> Windows XP, and Windows Server 2003.  
> Memory window. The configuration for the memory window differs for 
> Windows 2000, Windows XP, and Windows Server 2003:
> *	For Windows 2000, the default size for the memory window is 2 MB.
> *	For Windows XP and Windows Server 2003, the operating system 
> first attempts to find a memory window of 32 MB. If it cannot find a 
> window of that size, the operating system attempts to find a memory 
> window of progressively smaller sizes (16, 8, 4, 2, and finally 1 MB) until
>  it finds a size that works."

I think the way current BIOS does it, is that it actually configures the
hotplugged bridge and assigns resources accordingly. Once that is done
it trigggers hotplug to the OS using ACPI event.

> > We need to handle this in Linux in the same way Windows does but
> > currently I have no idea. It is however, more related to our PCI
> > enumeration code than the patches in question, I think.
> > 
> 
> Come to think of it, I have seen the dock have troubles if plugged in at 
> boot on Linux even with SL0 before this patch series.
> 
> > I also have a Dell 9350 here so I can reproduce the problem and I'm
> > going to investigate this further probably involving Linux PCI people.
> To clarify are you reproducing it with a TB16 or some other TBT device?

I'm using a chain of 1 to 5 devices. I don't have TB16 here but I don't
think it matters here.

> > My testing on the machine shows this behaviour only when the cable is
> > connected during boot.
> 
> Yep same.
> 
> > 
> > If I connect the cable after OS is booted I don't see the problem, even
> > if I do unplug / plug cycle.
> > 
> > Can you try that also (again)? And if you see the problem, send me the
> > dmesg? I have the latest BIOS (1.4.17) and NVM 16 so this machine
> > configuration should match yours if I'm not mistaken.
> 
> It does work properly if I boot no cable plugged in and then plug one in.	

OK, so we see the same behavior.

To summarize: This happens only on boot when Thunderbolt device is
already connected.

[toc] | [prev] | [next] | [standalone]

#1645816 — Re: [PATCH 00/24] Thunderbolt security levels and NVM firmware upgrade

On Fri, May 19, 2017 at 08:19:48PM +0300, Mika Westerberg wrote:
> These two I've seen before.
> 
> > [    7.428503] pcieport 0000:02:02.0: PCI bridge to [bus 39]
> > [    7.428512] pcieport 0000:02:02.0:   bridge window [mem 0xd9f00000-0xd9ffffff]
> > [    7.428519] pci_bus 0000:39: [bus 39] partially hidden behind bridge 0000:02 [bus 02-05]
> 
> And this.
> 
> It happens occasionally when you reboot the machine when a device is
> connected but seems to be dependent on the BIOS version. Since it is the
> BIOS who is supposed to enumerated these devices, I suspect that it is
> either problem in BIOS or our PCI enumeration code does something wrong.

I tried on Intel Skull Canyon NUC so that I downgraded the NVM firmware
from 25 to 18. With that I see the exactly same issue. Upgrading it back
to 25 seems to fix it.

Even with version 18 if I plug devices after boot or if the machine is
completely shut down from power button with devices connected, it works.
The problem happens only when the machine is warn booted.

However, since I'm able to reproduce this - I'll try to investigate what
might be the root cause.

[toc] | [prev] | [next] | [standalone]

#1646090 — RE: [PATCH 00/24] Thunderbolt security levels and NVM firmware upgrade

On Fri, May 19 2017, 07:35 PM, Mario.Limonciello@dell.com wrote:
> Here's my setup:
> System: I'm using is an XPS 9350 (Has Alpine Ridge).  It's got NVM 16.0.  BIOS
> 1.4.13 TBT Device: Dell TB16 (which has AR in the cable and in dock - both
> NVM 16.0).
> 

Is it BIOS assist or native enumeration?

> I created a udev rule that will automatically authorize the dock and cable.
> #dell cable
> ACTION=="add", SUBSYSTEM=="thunderbolt", ATTR{authorized}=="0",
> ATTR{vendor}=="0xd4", ATTR{device}=="0xb051", ATTR{authorized}="1"
> #dell dock
> ACTION=="add", SUBSYSTEM=="thunderbolt", ATTR{authorized}=="0",
> ATTR{vendor}=="0xd4", ATTR{device}=="0xb054", ATTR{authorized}="1"
> 

Note that the udev rule should authorize the cable first and then the dock.

> If I boot the system with the dock connected the cable shows up and authorizes
> but the dock doesn't.

I assume it works in Linux with SL0, right?

[toc] | [prev] | [next] | [standalone]

#1646282 — Re: [PATCH 00/24] Thunderbolt security levels and NVM firmware upgrade

On Sat, May 20, 2017 at 09:15:17AM +0000, Levy, Amir (Jer) wrote:
> > I created a udev rule that will automatically authorize the dock and cable.
> > #dell cable
> > ACTION=="add", SUBSYSTEM=="thunderbolt", ATTR{authorized}=="0",
> > ATTR{vendor}=="0xd4", ATTR{device}=="0xb051", ATTR{authorized}="1"
> > #dell dock
> > ACTION=="add", SUBSYSTEM=="thunderbolt", ATTR{authorized}=="0",
> > ATTR{vendor}=="0xd4", ATTR{device}=="0xb054", ATTR{authorized}="1"
> > 
> 
> Note that the udev rule should authorize the cable first and then the dock.

That should be fine, the devices appear in order closest to the host and
get added to the system in that order so udev should see them in that
order as well. Also the cable device will be parent to the dock.

[toc] | [prev] | [next] | [standalone]

#1648042 — Re: [PATCH 00/24] Thunderbolt security levels and NVM firmware upgrade

On Thu, 2017-05-18 at 17:38 +0300, Mika Westerberg wrote:
> Hi all,
> 
> This patch series adds support for Thunderbolt security levels, which
> were
> first introduced in Intel Falcon Ridge Thunderbolt controller, to
> prevent
> DMA attacks when PCIe is tunneled over Thunderbolt fabric. This is
> needed
> if there is no IOMMU available for various reasons.
> 
> Most PCs out there having Falcon Ridge or newer have security level
> set to
> "user" which means that user authorization is needed before PCIe
> tunnel is
> creaded (the PCIe device appears). This effectively means that without
> driver support the user needs to configure security level from BIOS to
> "none" to get Thunderbolt devices connected. With these patches the
> user
> can authorize devices using sysfs attributes like:
> 
>   # echo 1 > /sys/bus/thunderbolt/devices/0-1/authorized
> 
> In addition these patches add support for upgrading NVM firmware
> running on
> a host or device by running something like:
> 
>   # dd if=KYK_TBT_FW_0018.bin of=/sys/bus/thunderbolt/devices/0-
> 0/nvm_non_active0/nvmem
>   # echo 1 > /sys/bus/thunderbolt/devices/0-0/nvm_authenticate
> 
> This is documented with more details in patch [23/24].
> 
> This series is based on Amir's networking patches [1] but instead of
> splitting the functionality between kernel driver and userspace
> daemon, we
> take advantage of Linux driver core by converting the existing driver
> to
> expose a Linux bus (domain) and devices (switches). Notifications to
> the
> userspace about plugged/unplugged devices is handled by standard
> uevents
> when a device is added to/removed from the Thunderbolt bus.
> 
> Since thunderbolt device identification and authorization can be done
> directly through sysfs attributes there is no need for userspace
> daemon.
> However, there still should be an application that promps user for
> unknown
> devices and allows selecting between "single connect" and "connect
> always"
> keeping this information in a database or similar persistent storage.
> This
> patch series only provides mechanism for userspace applications to
> achieve
> that.
> 
> Where Internal Connection Manager (ICM) firmware is available and
> usable,
> we use it in the driver. This also includes newer Apple Macbooks with
> Alpine Ridge. For older Macbooks the driver works as before but in
> addition
> the Thunderbolt bus is available there as well (including possibility
> to
> upgrade NVM firmware of connected devices).
> 
> We are also in works of porting Amir's networking driver to work on
> top of
> the new Thunderbolt bus pretty much the same way firewire networking
> is
> currently done. In addition this makes is possible to introduce other
> protocols like a char device that allows userspace directly to
> communicate
> accross Thunderbolt domains.
> 
> Note for Macs the Linux native PCIe hotplug support does not work well
> with
> the Thunderbolt PCIe topologies where there is need to put all
> available
> resources to the PCIe downstream port where the PCIe chain is
> extended.
> This is something we need to fix. In the mean time is a way to work it
> around by passing "pci=hpbussize=10,hpmemsize=2M" or so to the kernel
> command line.
> 
> These patches use uuid_be from uuid.h but I've learned that there is a
> work
> to remove the type completely in favor of new uuid_t [2]. I'm not sure
> what
> to do regarding that because those patches are not yet in the
> mainline.

Looks like we may use uuid_be for now, though having a patch to switch
to uuid_t eventually.

I have commented few patches (some minor comments), other than that,
FWIW:
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

> 
> [1] https://lkml.org/lkml/2016/11/9/341
> [2] http://git.infradead.org/users/hch/vfs.git/shortlog/refs/heads/uui
> d-types
> 
> Mika Westerberg (24):
>   thunderbolt: Use const buffer pointer in write operations
>   thunderbolt: Do not try to read UID if DROM offset is read as 0
>   thunderbolt: Do not warn about newer DROM versions
>   thunderbolt: Add MSI-X support
>   thunderbolt: Rework capability handling
>   thunderbolt: Introduce thunderbolt bus and connection manager
>   thunderbolt: Convert switch to a device
>   thunderbolt: Fail switch adding operation if reading DROM fails
>   thunderbolt: Do not fail if DROM data CRC32 is invalid
>   thunderbolt: Read vendor and device name from DROM
>   thunderbolt: Move control channel messages to tb_msgs.h
>   thunderbolt: Expose get_route() to other files
>   thunderbolt: Expose make_header() to other files
>   thunderbolt: Let the connection manager handle all notifications
>   thunderbolt: Rework control channel to be more reliable
>   thunderbolt: Add Thunderbolt 3 PCI IDs
>   thunderbolt: Add support for NHI mailbox
>   thunderbolt: Store Thunderbolt generation in the switch structure
>   thunderbolt: Add support for DMA configuration based mailbox
>   thunderbolt: Do not touch the hardware if the NHI is gone on resume
>   thunderbolt: Add support for Internal Connection Manager (ICM)
>   thunderbolt: Add support for host and device NVM firmware upgrade
>   thunderbolt: Add documentation how Thunderbolt bus can be used
>   MAINTAINERS: Add maintainers for Thunderbolt driver
> 
>  Documentation/ABI/testing/sysfs-bus-thunderbolt |  108 +++
>  Documentation/admin-guide/index.rst             |    1 +
>  Documentation/admin-guide/thunderbolt.rst       |  197 ++++
>  MAINTAINERS                                     |    3 +
>  drivers/thunderbolt/Kconfig                     |   13 +-
>  drivers/thunderbolt/Makefile                    |    2 +-
>  drivers/thunderbolt/cap.c                       |  169 ++--
>  drivers/thunderbolt/ctl.c                       |  655 +++++++++----
>  drivers/thunderbolt/ctl.h                       |  105 ++-
>  drivers/thunderbolt/dma_port.c                  |  524 +++++++++++
>  drivers/thunderbolt/dma_port.h                  |   34 +
>  drivers/thunderbolt/domain.c                    |  455 ++++++++++
>  drivers/thunderbolt/eeprom.c                    |   84 +-
>  drivers/thunderbolt/icm.c                       | 1098
> ++++++++++++++++++++++
>  drivers/thunderbolt/nhi.c                       |  302 +++++-
>  drivers/thunderbolt/nhi.h                       |   91 +-
>  drivers/thunderbolt/nhi_regs.h                  |   27 +
>  drivers/thunderbolt/switch.c                    | 1109
> +++++++++++++++++++++--
>  drivers/thunderbolt/tb.c                        |  237 ++---
>  drivers/thunderbolt/tb.h                        |  242 ++++-
>  drivers/thunderbolt/tb_msgs.h                   |  260 ++++++
>  drivers/thunderbolt/tb_regs.h                   |   31 +-
>  drivers/thunderbolt/tunnel_pci.c                |   17 +-
>  23 files changed, 5213 insertions(+), 551 deletions(-)
>  create mode 100644 Documentation/ABI/testing/sysfs-bus-thunderbolt
>  create mode 100644 Documentation/admin-guide/thunderbolt.rst
>  create mode 100644 drivers/thunderbolt/dma_port.c
>  create mode 100644 drivers/thunderbolt/dma_port.h
>  create mode 100644 drivers/thunderbolt/domain.c
>  create mode 100644 drivers/thunderbolt/icm.c
>  create mode 100644 drivers/thunderbolt/tb_msgs.h
> 

-- 
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.kernel

csiph-web