FreeBSD source tree https://cgit-dev.freebsd.org/src/atom?h=main 2025-10-31T18:50:40Z 2025-10-31T18:50:40Z Gordon Bergling gbe@FreeBSD.org 2025-10-29T15:21:25Z urn:sha1:85d6c86f4b53e6ac2a9b163c553b48466638f394 - s/temparature/temperature/ MFC after: 5 days 2025-06-21T02:57:45Z Ahmad Khalifa vexeduxr@FreeBSD.org 2025-06-11T00:25:08Z urn:sha1:b670c9bafc0e31c7609969bf374b2e80bdc00211 Reviewed by: imp, jhb Approved by: imp (mentor) Differential Revision: https://reviews.freebsd.org/D50913 2025-05-10T19:20:37Z Ravi Pokala rpokala@FreeBSD.org 2025-05-10T06:26:42Z urn:sha1:2a042fab4f91a525daa6255b69892fb434c62831 I found the '1AH_MxxH_ROOT' PCI device IDs in the Linux "AMD K8 Northbridge" driver [1][5]. Since Family 19h (Zen3, Zen4) uses the same registers as Family 17h (Zen1, Zen2), I tried using those same registers for Family 1Ah (Zen5) as well, and they worked. I pulled the 1Ah model ranges from Linux as well [2][3][4][6]. Added some additional logging under 'bootverbose', and used a local variable and macro for the stepping, rather than repeatedly using the mask directly. Consistently report the CPUID (family, model, stepping) using two, zero-padded, un-prefixed, uppercase nybbles, with an 'h' suffix. This is the format used in documentation and in Linux. My own testing with various models of Zen4 EPYC 9xx4 ("Genoa") shows that their CPUID models are in the range 0x10 .. 0x1f. Similar testing with various models of Zen5 EPYC 9xx5 ("Turin") shows that their CPUID models are in the range 0x00 ... 0x2f. [1] 2023-08-10: https://github.com/torvalds/linux/commit/c640166 [2] 2024-01-23: https://github.com/torvalds/linux/commit/3e4147f [3] 2024-01-25: https://github.com/torvalds/linux/commit/b9328fd [4] 2024-04-24: https://github.com/torvalds/linux/commit/2718a7f [5] 2024-07-28: https://github.com/torvalds/linux/commit/59c3400 [6] 2024-07-30: https://github.com/torvalds/linux/commit/bf5641e Sponsored by: Vdura MFC after: 3 days Reviewed by: delphij Differential Revision: https://reviews.freebsd.org/D50278 2025-01-12T12:14:01Z Simon Wells swel024@gmail.com 2025-01-12T11:46:05Z urn:sha1:a9a71513ccfcb38346c84b006b43d45511d1652c Zen 5 support, tested on Ryzen 7 9700X PR: 284010 MFC after: 1 week 2025-01-12T12:14:01Z Simon Wells swel024@gmail.com 2025-01-12T11:45:05Z urn:sha1:7aa6eeb220d89a3c29eb4f768f258622c3803f46 Tested on AMD 5700G PR: 284009 MFC after: 1 week 2024-10-13T13:21:19Z Matthias Lanter freebsd@lanter-it.ch 2024-10-13T13:21:19Z urn:sha1:ecbe99e1627627b6797153899e4d95fde3e230e2 PR: 281962 MFC after: 2 weeks 2024-08-23T04:51:19Z Oliver Fromme olli@FreeBSD.org 2024-08-23T04:46:19Z urn:sha1:ef3f8aa0a0492487ac7db839de078b1913f61b4c Adds support for AMD Ryzen 7 "Phoenix" processors (family 0x19, model 0x70-0x7f) to the amdsmn(4) and amdtemp(4) drivers. This enables temperature readings of these CPUs via sysctl. The sensors function identically to those for the "Raphael" processors (model 0x60-0x6f); only the PCI device ID differs. PR: kern/280942 Relnotes: yes MFC after: 3 days 2024-07-25T04:22:58Z Warner Losh imp@FreeBSD.org 2024-07-25T04:22:58Z urn:sha1:5b56413d04e608379c9a306373554a8e4d321bc0 Sponsored by: Netflix 2024-04-14T07:52:08Z Xin LI delphij@FreeBSD.org 2024-04-14T07:45:17Z urn:sha1:51c69c8682e8ab0e5d82ab3d6f2d16419d40bad4 Tested on AMD Threadripper 7960X. PR: kern/278311 Tested by: jbo MFC after: 1 week 2023-11-29T18:31:47Z John Baldwin jhb@FreeBSD.org 2023-11-29T18:31:47Z urn:sha1:1587a9db92c03c738bb3f0fc5874b43c961e7c99 This commit changes the API of pci_cfgreg(read|write) to add a domain argument (referred to as a segment in ACPI parlance) (note that this is not the same as a NUMA domain, but something PCI-specific). This does not yet enable access to domains other than 0, but updates the API to support domains. Places that use hard-coded bus/slot/function addresses have been updated to hardcode a domain of 0. A few places that have the PCI domain (segment) available such as the acpi_pcib_acpi.c Host-PCI bridge driver pass the PCI domain. The hpt27xx(4) and hptnr(4) drivers fail to attach to a device not on domain 0 since they provide APIs to their binary blobs that only permit bus/slot/function addressing. The x86 non-ACPI PCI bus drivers all hardcode a domain of 0 as they do not support multiple domains. Reviewed by: imp Differential Revision: https://reviews.freebsd.org/D42827