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.

Plan

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.

Results

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

Activity

  • about 2 years ago: zhigangg joined Support for the SMBus ARP protocol
  • almost 5 years ago: jdelvare started Support for the SMBus ARP protocol
  • almost 5 years ago: duwe liked Support for the SMBus ARP protocol
  • almost 5 years ago: wpreston2 liked Support for the SMBus ARP protocol
  • almost 5 years ago: ptesarik liked Support for the SMBus ARP protocol
  • Show History

    Comments

    • jdelvare
      almost 5 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
      almost 5 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

    openSUSE/SLE/Mainline U-boot for Khadas VIM/VIM2 board by ldevulder

    The Khadas VIM (http://khadas.com/vim/) is an a...


    Help with mainline support for the Mediatek chromebook by mbrugger

    Lately the necessary patches to get rudimentary...


    Upstreaming of mediatek helios board by mbrugger

    The only Mediatek "hacker" board available is f...


    Kernel Boot/Testing Framework with LinuxKit by vrothberg

    Problem statement

    Once a kernel is built, a...


    netlink interface for ethtool by mkubecek

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