The SMBus standard specifies an address resolution protocol (SMBus ARP.) It has two key features :

  • Handle I2C slave address collisions. If two SMBus slaves would use the same I2C address, ARP lets one of them pick a different address to avoid the address collision.
  • Automatically and reliably identify SMBus slaves. Each SMBus slave supporting ARP has a unique device ID, which can be used to automatically instantiate the right I2C device and subsequently let the needed driver be loaded.


If implemented properly, sensors-detect would no longer be needed on a number of systems, as all required drivers would get loaded automatically.

There has been some work done on SMBus ARP in the past, but nothing good enough to be integrated in the upstream kernel. Mark D. Studebaker wrote proof-of-concept code in 2002, for kernel 2.2. The code was updated for kernel 2.4 but development stopped in 2005.

More recently, Corentin Labbe has been working on proof-of-concept code for kernel 2.6/3. As I recall the code did not actually work, but maybe it can be used as a base.


Miserable failure. Proper hardware support is rare, and prerequisites aren't met.

Looking for mad skills in:

kernel hardware

This project is part of:

Hack Week 10


  • over 3 years ago: zhigangg joined Support for the SMBus ARP protocol
  • about 6 years ago: jdelvare started Support for the SMBus ARP protocol
  • about 6 years ago: duwe liked Support for the SMBus ARP protocol
  • about 6 years ago: wpreston2 liked Support for the SMBus ARP protocol
  • about 6 years ago: ptesarik liked Support for the SMBus ARP protocol
  • Show History


    • jdelvare
      about 6 years ago by jdelvare | Reply

      Things didn't go as good as I hoped. Firstly my own machine no longer replies to the SMBus ARP address, while I'm almost certain it used to. I can't explain it.

      Then I tried to find a machine on the Suse network that would be suitable, but that kind of information doesn't show in orthos, so finding the right machine was difficult. I finally found "knorr", which does reply to the SMBus ARP address, but uses an HT-1000 south bridge for which we don't support SMBus PEC, which is a prerequisite for SMBus ARP. I don't even know if the chipset supports it, and the datasheet is not publicly available.

      So I gave up on "knorr" and now found "fux" which does reply to the SMBus ARP address and uses the i2c-i801 SMBus driver which implements SMBus PEC support. I can start my tests now.

    • jdelvare
      about 6 years ago by jdelvare | Reply

      The curse goes on. "fux" has an ICH10 south bridge, and testing revealed that PEC (CRC) errors during SMBus block transactions (at least) lock up the SMBus controller. I suspect an undocumented erratum. I managed to find a software workaround, I must discuss it with upstream.

      When testing that software workaround on another chip (ICH5) supported by the i2c-i801 driver, I hit another bug related to PEC error handling. I'm still puzzled by that one, I don't understand what is going on and have no idea how to work around it.

      It should be clear by now that I'm not going to complete my hack week project. It turns out that the world is not yet ready for SMBus ARP. First of all we need proper SMBus PEC support on a wide range of machines. Only when this is available, it will make sense to look into SMBus ARP support again.

    Similar Projects

    netlink interface for ethtool by mkubecek

    There seems to be an overall consensus that the...

    Investigate C-Sky architecture by a_faerber

    The youngest architecture addition to the mainl...

    Out-of-the-box SPD support by jdelvare

    In order to see the SPD (detailed memory inform...

    openSUSE/SLE/Mainline U-boot for some not-yet-supported ARM64 boards by ldevulder

    The Khadas VIM ( is an a...

    ethtool ops for netdevsim by mkubecek

    This can be seen as a subproject of [ethtool ne...

    work on sunxi a64 cpufreq driver (for teres-1, pine64) by mbrugger

    With the teres-1 [1] laptop we have a first arm...