Re: git: 2ed9833791f2 - main - thunderbolt: Import USB4 code
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sat, 11 Oct 2025 13:41:42 UTC
obiwac <obiwac_at_freebsd.org> wrote on
Date: Sat, 11 Oct 2025 10:11:26 UTC :
> Sorry for the late reply.
>
> > I'll note that ACPI 6.4 appears to have a way for the
> > OS to indicate that it it wants to do its own handling
> > of connection management, even for when ICM is available.
> > So to say that ICM use will not be supported need not
> > be an indication of if the context will have its own
> > support of connection management in the OS. (I seem to
> > remember seeing _OSC notation in the context I was
> > reading. I also think that I remember: Query Flag being 0
> > and Native USB4 Support being 1 for the call in something
> > I was reading.)
>
> If you're referring to 6.2.11.3. (Operating System Capabilities (_OSC)
> for USB), the way I read this is that we tell the platform which
> features our HCM supports so that it can mux between DP alt mode and
> the XHCI controller instead of expecting USB4 to tunnel these on the
> type-C ports, rather than a way to tell the platform whether or not we
> want a certain feature to be handled by us (HCM) or the ICM.
>
> I'd have to look into if it's possible to use a HCM even with certain
> ICM devices but I doubt it. Might be wrong about this though so if you
> have a reference to this send it my way!
Section 6.2.11.2 Platform-Wide OSPM Capaabilities is where:
QUOTE
Table 6.13 Platform-Wide _OSC Capabilities DWORD 2
Bits Field Name Definition
. . .
18 Native USB4 Support The OS sets this bit to indicate support
for an OSPM-native USB4 Connection Manager,
which handles USB4 connection events and
link management.
. . .
* As part of the handshake provided through _OSC, the OS will pass in
flags to indicate whether it supports Platform Coordinated Low Power
Idle or OS Initiated Low Power Idle or both (see Section 8.4.4.2),
through flags 7 and 8. The platform will indicate which of the modes
it supports in its response by clearing flags that are not supported.
If both are supported, the default is platform coordinated and OSPM
can switch the platform to OS Initiated via a processor architecture
specific mechanism. By setting either flag 7 or 8 or both, the OSPM is
asserting it supports any objects associated with Low Power Idle states
(see Section 8.4.4.3, Table 8.16, and Section 7.2.5), and supports a
Processor Container Device.
. . .
Return Value Information
Capabilities Buffer (Buffer) - The platform acknowledges the
Capabilities Buffer by returning a buffer of DWORDs of the same length.
Set bits indicate acknowledgment and cleared bits indicate that the
platform does not support the capability.
END QUOTE
So it appears that lack of support by the platform for any Native USB4
support of the OS could be used to reject supporting the environment.
But that is an OS choice of policy.
After that is used to request for OS control, then comes the
use of:
QUOTE
6.2.11.3. Operating System Capabilities (_OSC) for USB
Platform hardware and operating systems with support for USB4 require
a few controls for passing information back and forth. The following
definition is used to convey this information.
Along with the Platform-Wide OSPM Capabilities defined in Section
6.2.11.2, this _OSC interface is implemented within the same scope,
and therefore the same _OSC Control Method, using a different UUID
value. If the platform does not support USB4, the UUID defined in
this section should not be supported.
Note that if control of any features described in Table 6.15 are
granted to OSPM, system firmware must not attempt to control any
other features not granted to OSPM; only one Connection Manager is
permitted to be active at any point in time. OSPM evaluates \_SB._OSC
to manage USB capabilities within the platform. Argument definitions
are as follows.
. . .
Note: OSPM must re-invoke _OSC during S4 resume.
. . .
Table 6.15 OSPM USB Control Field
Bits Field Name Definition
0 USB Tunneling OSPM requests control of USB tunneling across
USB4 connections via the OSPM-native Connection
Manager. Once OSPM receives control of this
feature, it must not relinquish support to the
platform.
1 DisplayPort Tunneling OSPM requests control of DisplayPort tunneling
across USB4 connections via the OSPM-native
Connection Manager. Once OSPM receives control
of this feature, it must not relinquish support
to the platform.
2 PCI Express Tunneling OSPM requests control of PCI Express tunneling
across USB4 connections via the OSPM-native
Connection Manager. Once OSPM receives control
of this feature, it must not relinquish support
to the platform.
3 Inter-domain USB4 Inter-domain USB4 protocol: OSPM requests
control of inter-domain USB4 connections via
the OSPM-native Connection Manager. Once OSPM
receives control of this feature, it must not
relinquish support to the platform.
. . .
Return Value Information
Capabilities Buffer (Buffer): The platform acknowledges the Capabilities
Buffer by returning a buffer of DWORDs of the same length. Preserved bits
in the Control Field convey control from the platform to OSPM, while
masked/cleared bits in the Control Field indicate that the platform does
not permit OSPM control of the respective capability or feature.
END QUOTE
Note the various:
"Once OSPM receives control of this feature, it must not relinquish
support to the platform."
That goes along with:
"Note that if control of any features described in Table 6.15 are
granted to OSPM, system firmware must not attempt to control any
other features not granted to OSPM; only one Connection Manager is
permitted to be active at any point in time."
The implication would be that all platform control is effectively
disabled (not used) when the OS is granted any control --and the OS
has to be in full control of what has been granted but the
non-granted is just not supported by either.
Again: if requests for control by the OS are not granted for USB Tunneling,
DP Tunneling, or Inter-domain USB4, it appears that the OS can refuse to
support the environment if the OS policy is to require control for
support of what was not granted. As PCIe Tunneling is a security policy issue,
it likely needs to just avoid trying to use any USB4 PCIe Tunneling if it
is not granted.
Refusing to support the environment may well require shutdown, given that:
"Once OSPM receives control of this feature, it must not relinquish
support to the platform." So if a mix of granting control and not granting
control happens, the OS would have to be involved for what it was granted
and neither would support what was not granted: only one connection manager
is active, never both of them.
Referencing notes about existing implementations
as a cross check on interpretation . . .
https://git.zx2c4.com/linux-rng/commit/drivers/thunderbolt?id=c6da62a219d028de10f2e22e93a34c7ee2b88d03
QUOTE
ACPI 6.4 introduced a new _OSC capability used to negotiate whether
the OS is supposed to use Software (native) or Firmware based
Connection Manager. If the native support is granted then there are
set of bits that enable/disable different tunnel types that the
Software Connection Manager is allowed to tunnel.
This adds support for this new USB4 _OSC accordingly. When PCIe
tunneling is disabled then the driver switches security level to be
"nopcie" following the security level 5 used in Firmware based
Connection Manager.
. . .
+ * Returns %true if the platform granted OS native control over
+ * TBT/USB4. In this case software based connection manager can be used,
+ * otherwise there is firmware based connection manager running.'
. . .
+ * When software based connection manager is used, this function
+ * returns %true if platform allows native USB3 tunneling.
. . .
+ * When software based connection manager is used, this function
+ * returns %true if platform allows native DP tunneling.
. . .
+ * When software based connection manager is used, this function
+ * returns %true if platform allows native PCIe tunneling.
. . .
+ * When software based connection manager is used, this function
+ * returns %true if platform allows XDomain connections.
END QUOTE
https://learn.microsoft.com/en-us/windows-hardware/design/component-guidelines/usb4-acpi-requirements
QUOTE
_OSC (Operating System Capabilities) for USB4
The BIOS must grant control to the USB4 connection manager as per
ACPI 6.4 specification. The system must grant control of native
USB4 support in platform-wide operating system power management
(OSPM) capabilities. Control is granted when _OSC is called by the
operating system with Query Flag set to 0 and Native USB4 Support
set to 1.
Additionally, _OSC for USB must also be implemented. The BIOS may
disallow control over PCIe tunneling for security reasons as per
required policies or user-settings. However, USB tunneling,
DisplayPort™ tunneling and interdomain USB4 connections must
always be enabled. The connection manager will place the device
into a failed state if USB tunneling, DisplayPort™ tunneling or
interdomain connections are disabled.
END QUOTE
Side note:
I did not receive your Email directly, despite your:
QUOTE
To: Mark Millard <marklmi at yahoo.com>
Cc: "Bjoern A. Zeeb" <bzeeb-lists at lists.zabbadoz.net>,
dev-commits-src-main <dev-commits-src-main at freebsd.org>
END QUOTE
I used the web interface to the list to form this separate
reply.
I wonder how much this sort of thing has been happening. I've
not been monitoring for such. I just accidentally noticed
that "Original text of this message" indicated that you had
sent directly to me, despite my not receiving such.
===
Mark Millard
marklmi at yahoo.com