lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9b1a5e36-337b-4750-9dad-b54e28cde03a@amd.com>
Date:   Mon, 6 Nov 2023 10:59:13 -0600
From:   Mario Limonciello <mario.limonciello@....com>
To:     Lukas Wunner <lukas@...ner.de>
Cc:     Karol Herbst <kherbst@...hat.com>, Lyude Paul <lyude@...hat.com>,
        Alex Deucher <alexander.deucher@....com>,
        Christian König <christian.koenig@....com>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        Hans de Goede <hdegoede@...hat.com>,
        Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>,
        Mika Westerberg <mika.westerberg@...ux.intel.com>,
        Danilo Krummrich <dakr@...hat.com>,
        David Airlie <airlied@...il.com>,
        Daniel Vetter <daniel@...ll.ch>,
        Xinhui Pan <Xinhui.Pan@....com>,
        "Rafael J . Wysocki" <rafael@...nel.org>,
        Mark Gross <markgross@...nel.org>,
        Andreas Noever <andreas.noever@...il.com>,
        Michael Jamet <michael.jamet@...el.com>,
        Yehezkel Bernat <YehezkelShB@...il.com>,
        Pali Rohár <pali@...nel.org>,
        Marek Behún <kabel@...nel.org>,
        "Maciej W . Rozycki" <macro@...am.me.uk>,
        Manivannan Sadhasivam <mani@...nel.org>,
        "open list:DRM DRIVER FOR NVIDIA GEFORCE/QUADRO GPUS" 
        <dri-devel@...ts.freedesktop.org>,
        "open list:DRM DRIVER FOR NVIDIA GEFORCE/QUADRO GPUS" 
        <nouveau@...ts.freedesktop.org>,
        open list <linux-kernel@...r.kernel.org>,
        "open list:RADEON and AMDGPU DRM DRIVERS" 
        <amd-gfx@...ts.freedesktop.org>,
        "open list:PCI SUBSYSTEM" <linux-pci@...r.kernel.org>,
        "open list:ACPI" <linux-acpi@...r.kernel.org>,
        "open list:X86 PLATFORM DRIVERS" 
        <platform-driver-x86@...r.kernel.org>,
        "open list:THUNDERBOLT DRIVER" <linux-usb@...r.kernel.org>
Subject: Re: [PATCH v2 6/9] PCI: Rename is_thunderbolt to is_tunneled

On 11/5/2023 11:39, Lukas Wunner wrote:
> On Fri, Nov 03, 2023 at 02:07:55PM -0500, Mario Limonciello wrote:
>> The `is_thunderbolt` bit has been used to indicate that a PCIe device
>> contained the Intel VSEC which is used by various parts of the kernel
>> to change behavior. To later allow usage with USB4 controllers as well,
>> rename this to `is_tunneled`.
> 
> This doesn't seem to make sense.  is_thunderbolt indicates that a device
> is part of a Thunderbolt controller.  See the code comment:
> 
>> -	unsigned int	is_thunderbolt:1;	/* Thunderbolt controller */
> 
> A Thunderbolt controller is not necessarily tunneled.  The PCIe switch,
> NHI and XHCI of the Thunderbolt host controller are not tunneled at all.
> 
> Thanks,
> 
> Lukas

I could really use some clarification which PCIe devices actually 
contain the Intel VSEC.

Is it in all 3 of those PCIe devices and not just the switch?

If so, I think I would rather introduce a separate bit.  So after this 
series we would have:

is_tunneled:1
is_thunderbolt:1
no_command_complete:1

* TBT1 devices would set no_command_complete
   - The consumer would be pcie_init()
* All devices with the Intel VSEC would set is_thunderbolt and the two 
consumers would be:
  - apple-gmux.c
  - pci_bridge_d3_possible()
* USB4 devices and PCIe switches with the VSEC would set is_tunneled.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ