Feature #13144


refactor amdf17nbdf into a nexus

Added by Robert Mustacchi about 3 years ago. Updated about 3 years ago.

driver - device drivers
Start date:
Due date:
% Done:


Estimated time:
Gerrit CR:
External Bug:


The amdf17nbdf driver originally was written with dual purposes. The first was to provide a temperature sensor for AMD Zen family platforms. Secondly, it was to provide a foundation for additional work such as dealing with the memory controller and other aspects of the system. The combination of the northbridge and data fabric PCI devices that are bound to the driver are useful for providing access to two different services:

  • The System Management Network
  • Direct and Indirect access to the Data Fabric

As I started looking at adding additional functionality, we needed to consider even more PCI devices and mapping them together. Rather than try and continuing to push functionality into the amdf17nbdf driver directly, I instead decided to transform it into a nexus driver that provides services and concretely can provide access to services for child devices.

This distinction makes it much easier for us to actually separate out the act of amalgamating all of the different per-processor die PCI devices and the actual child devices which would provide services such as temperature services, memory controller data, etc.

This will create three drivers as a result:

  • amdzen: The Nexus driver itself
  • amdzen_stub: A driver that will attach to the PCI devices on the system that constitute the northbridge and data fabric.
  • smntemp: A child device of amdzen that provides sensor access through the SMN.
Actions #1

Updated by Robert Mustacchi about 3 years ago

  • Description updated (diff)
Actions #2

Updated by Electric Monk about 3 years ago

  • Gerrit CR set to 940
Actions #3

Updated by Robert Mustacchi about 3 years ago

I've tested this in a couple of different ways:

  • Verifying that everything came up correctly on a Zen 1 2P Naples system
  • Verifying that everything came up correctly on a Zen 2 1P Rome system
  • With future work, have tested that everything works on a Zen 3 2P system
  • Verifying that not having some of the various children devices such as the usmn does not impact the other drivers from coming up (because it's in a different package)
  • Verifying that missing a given PCI ID from the DF set ends up leaves this non-functional as expected; however, it does not interfere with the rest of the system (merely the children devices)
  • Verified that several children devices that are specified all worked correctly
  • Verified that I could onu from a system with amdf17nbdf installed to a system with this driver
Actions #4

Updated by Electric Monk about 3 years ago

  • Status changed from New to Closed
  • % Done changed from 80 to 100

git commit 047043c2181e939608ea2c09257fd2d515e99643

commit  047043c2181e939608ea2c09257fd2d515e99643
Author: Robert Mustacchi <>
Date:   2020-10-21T21:02:57.000Z

    13144 refactor amdf17nbdf into a nexus
    13145 rewrite amdf17nbdf to use the ksensor framework
    13146 Want a driver for AMD SMN user access
    Reviewed by: Patrick Mooney <>
    Reviewed by: Mike Zeller <>
    Reviewed by: Robert French <>
    Approved by: Richard Lowe <>


Also available in: Atom PDF