From nobody Sat Oct 11 13:41:42 2025 X-Original-To: dev-commits-src-main@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4ckPt51JW9z6Bvk9 for ; Sat, 11 Oct 2025 13:42:05 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-54.consmr.mail.gq1.yahoo.com (sonic316-54.consmr.mail.gq1.yahoo.com [98.137.69.30]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4ckPt458Kjz46ch for ; Sat, 11 Oct 2025 13:42:04 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=WDqliPaN; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.30 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1760190118; bh=POGIfdl5ULJ6FuvexSdnk4rzOm9CZuqmPr3ap8Dc3sw=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=WDqliPaNJ5LuzbGxnX/fWLvM0TsExR5X2gBT7vpP7jd1XnVYgrz3Ta+hp2xaCcwbBJ7qEux4ZrVDSP5wdJaQz2NlQJa82EShGrUEMrbLWHHPp4NnPY/RdTetVziE7aXrXh6LgukOLh56xtGi5cmi7ya0oE34BAvkWnmEGAJBw2KCUp8O4N3XQny/KVj6sVyMYwu1up5SnQWDa0NYNe7/t2Hfzp7Bh7Y9l6Xa/kNOH3b2hY5xH9oFU+XnaFsHoxrCcCKe82xnGlfb8m9I/RunRuzdfiN7OSlUDvcwYfay171Ftqy8eFPlNoQi+3968ZPQKcF9BPYprBs2550Cosnzhw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1760190118; bh=1HwCdkBQ6RR6TxKqTL8JBNETFFBjTWM2f6WEZotsl4T=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=QAH+BKXPrCT0tCgn+jxCs0SqHBWd1h6r3IM5ykOs02dFH97T+bNhVeIsyX46sRgp4JEtEQPSEG59TgFaJI+DPFokckm3iHpH0c774ezsq7smVzXwrOkU6IU7qd/nzulfQ4089ZdVzEnSen27zOcU4wPnO2Am+cVUZomJMy4BFGUg2FBGjzsN7aU1p0vIPnE799ovwP7PuZ2gY5AE47+Hwqp/2uLHPNBlEPgy/Uky8ODVVROtmYlI1MIC8yPIejRwT9xpDEhBHs74IRj6iAgwPbse1tU7vxzlr7tnB27fttXp6oOXQKIpaVY8dhViT3qydzliGduZXjUT7u/WhG6p+A== X-YMail-OSG: myMKWlQVM1lA5naIxrNE_.q9SAjWQo8rY2AQIl3790gsuwSnYHk0DZWc0gQy52i LwNiBqeoIgNdmw4IpczHl2WD0vkx6IoC9QS81T..FbYLHduqwiatQqCOC21ZHbpSTUFeoplS0Cep UoSL1AF2hvO1SHwCQgENNIeHDNREJgYDnHWlO0sejbNU6PRa7AImXG3luoKAxi0kni3cgz1VJeZH S6nMhluq6gFAkN1a5vWBAS8tUa9PEgvG5oq7X0xD2Rpr4whiTyoCbY6IKMb96ixJDF4vKhxu5wAn WGwpEqcpLBvBLmDJf2kUnxuEttpIpwp1Bd1UpEilG8rKJGyn8ZwAaU.9IEOJLBgJNh1g2Ai4ozFU 2P1adky0j4qknRz_SHc70hfeeB9sY1OqXj.k1WnKyyAYgp2hRjnzNVf7NrY02.taXsJgZIvFl22u VFCg8B6BTK0HkarERLmeePIhTzfriGyK50Admw7tcTRYAiW.BXvTectMq8tnrVgu9rbq6IDRH3Wc MJNJHzzzKtp2Td8nU1p0vWrn8LdPmD9o2R_F3h.qPMKhLGXeyN3RHNYdV1xe4hUCqVfveNrOeL.9 KlCW0c6y89uVOXYOk5JKpgxM9kALReDdE5aCH91LXmhTd79HxHEre6u7DVqeFLN.TngvLC69O624 rLzWdAcGUHXJDxXWM7h87S1NhOUFbNtZWCiRrgXbbAnC2dZpJteR1HvnKN8MPqtkW6rmqTQ4mZsO DsljHYgyIbAmswC7PE1MGkD.xmnY2I_vGZzuEaZNkEOkC5CDueIcPxg4PxMkW._Aq9s2tnmB_cjn zbQYYi8YlSbpuJkcIx5Lato_VHCzUH9zSTiNJ3jRF1zX5wU2b89ZY.uEDE6IBYOI14e8ALisSZ5e uYvXgra2NwlRfu0_9sSnMOe8NslikPzGerKBkbnZ.5OHRywe9tUv0ElK_F2zlgcuXzlq7vSCGRiS CyjV3CutEAcvOMDsYvnCxlsukIfYNdL8U4.xt1ser0vEjuiC6FN4B3PsKY8.bQFe9oM9uFl9y9a7 qodFU8B42q3eDeVs48cXzi_QU84gxganfYnRKGBHGmPJL7snrk8pI_9nYlKtNbOLtPK30YkQ39nH mZTPIj3NX2ZQ6HoN05eGZ7XqKEjDpn1TAMCJmXY3PIqpPFDO1kA11wxFZ6L2gOfb7GHlRwLX4qSk vpHVfCVIBlx71ExjkT6cTXdPoAJGeLujHPDtz0Y51oDm5wcAh8bIMckhD2X.qfpX6o0.aJ.66jH4 AuAsR1M0KGL99K5S0rVHdKxtoOxq9l_MeI4k6wjledQs1jzmL3c3xLAMrObUuEtF8EvqDCO6DvEG ojV0qyqzVD0wQDKwIE.V_9eiZSOA.IhTQsN9TXQZSnW097Z6A.T2AsNjg.o9UYo26DFOKOxJEugd 4NYuzWpLwg7FxmXNgTTkGb7xu2oKPD1F92p7FzXO5IeIF0Nf1Klr4uFN_CDcaPHEdpsr7JZsBykN 6oSqMb_wIOPukl6DgCxCxI_J5vBoE7y3hdmD9LIkn0gRuC50yNDY2FVB..2wUQ6PQwBQ53tLGB3P TI5FCUBH0gWiMEN8t_ub060hQtpwDa6L2GKQ8oV7L5PBmfEvDbbR6Rir9ZQOxeL9gqPnQvnkvVNr M3GMDNhowkAY7C8xxEkvTHUyhoyAHppICdxQK5XxA8RXgGNElymysugRAVm7AGiNXpavX7451UDl c_.aBW9LWXoLT9m6AHSh.cCGmgFak4RTnVyyL3ti.gWsfTL4YHoWYdNmf.SFuUPpQWzKgFxOL0zE kNZtzPej_RrfapSWPDB62m19HZZwYxtCvW9AKjncjiqqSl1wPlqm3ezfsppvioFkolKIb1k4Yaur iQvGwI6KDtjVNBLSS7mt3k4e4yo2HXklfDK3EwRYiN9R_FKDqauLUYvQ71S1qUysSQFVBEHXeJqV CX.79nBTyLmpvM38yv.Lh9B6teyv6UeDve2XAPnmp03mcTSE0IT4XoGj2bZTwgjKNPFgOlNsg9nq zGAwdjIQ83UA9bKGupIZCmWmVDrZoKxksemREGiWmhDb8xMSmhF5p7kMzYO92U3k4OU50EftUy6n .EE1MKscqxq5J36sTeKqOpasv98jpuRgdbpfpewP2vHxGEF00tnMVuwm5RQQn4AImk36Gkz.tsFC 962JhKqk922EjrdoC_yIJepZB0_tL_rjgkAJHWsDuU77VW3BtMoZmthdZTi4aMq18Bif4RUh_zsL lNNLnX_DZOd9Ati4YoMYxo.QCREcED.ingw.rU.cbuC31sMTHUZmtPuU8ZKfQdJU9rWOoQbTtxVz pplAxtJWf3f8FFAzaVtTKGDF1m9U1Ibli_gYhFZ8- X-Sonic-MF: X-Sonic-ID: da1a5367-6c57-4eb7-9fe1-7df79393d0bf Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Sat, 11 Oct 2025 13:41:58 +0000 Received: by hermes--production-gq1-66b66ffd5-q7pm6 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 6292248961739d4d24a45df09407b77b; Sat, 11 Oct 2025 13:41:53 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: Commit messages for the main branch of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-main List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-src-main@freebsd.org Sender: owner-dev-commits-src-main@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.700.81\)) Subject: Re: git: 2ed9833791f2 - main - thunderbolt: Import USB4 code Message-Id: Date: Sat, 11 Oct 2025 06:41:42 -0700 To: obiwac , dev-commits-src-main@freebsd.org X-Mailer: Apple Mail (2.3826.700.81) References: X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.35 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_MEDIUM(-0.34)[-0.343]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_SHORT(-0.01)[-0.009]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MLMMJ_DEST(0.00)[dev-commits-src-main@freebsd.org]; APPLE_MAILER_COMMON(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.30:from]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.30:from] X-Rspamd-Queue-Id: 4ckPt458Kjz46ch obiwac wrote on Date: Sat, 11 Oct 2025 10:11:26 UTC : > Sorry for the late reply. >=20 > > 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.) >=20 > 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. >=20 > 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=3Dc6da62a219= d028de10f2e22e93a34c7ee2b88d03 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-guidel= ines/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=E2=84=A2 tunneling and interdomain USB4 connections must always be enabled. The connection manager will place the device into a failed state if USB tunneling, DisplayPort=E2=84=A2 tunneling or interdomain connections are disabled. END QUOTE Side note: I did not receive your Email directly, despite your: QUOTE To: Mark Millard Cc: "Bjoern A. Zeeb" ,=20 dev-commits-src-main 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. =3D=3D=3D Mark Millard marklmi at yahoo.com