It seems that smbmsg is another victim in "Great SMBus Slave Address
Confusion" - there are two schools: one that think that slave address is
(addr >> 1) and there other thinks that slave address is (addr &
~0x1).
It seems that smb driver in FreeBSD takes the first approach, but smbmsg
is keen on the second.
smbmsg.c:
...
/*
* The I2C specs say that all addresses below 16 and above or equal
* 240 are reserved. Address 0 is the global address, but we do not
* care for this detail.
*/
#define MIN_I2C_ADDR 16
#define MAX_I2C_ADDR 240
.
.
.
static void
probe_i2c(void)
{
...
for (addr = MIN_I2C_ADDR; addr < MAX_I2C_ADDR; addr += 2) {
...
And sample output on my machine (releng/7 amd64):
$ mbmsg -p
Probing for devices on /dev/smb0:
Device @0x44: rw
Device @0x50: rw
Device @0x52: rw
Device @0x80: rw
Device @0x88: w
Device @0xc4: rw
Device @0xd0: rw
Device @0xd2: rw
Now:
(0x44 << 1) & 0xff == (0xc4 << 1) & 0xff = 0x88 (looks like
RTC)
(0x50 << 1) & 0xff == (0xd0 << 1) & 0xff = 0xa0 (well known
SPD addr)
(0x52 << 1) & 0xff == (0xd2 << 1) & 0xff = 0xa4 (well known
SPD addr)
(0x80 << 1) & 0xff = 0x0 (mentioned above "global address")
(0x88 << 1) & 0xff == MIN_I2C_ADDR = 0x10 (something weird)
I think that this demonstrates that FreeBSD smb driver expects slave
addresses in range 0x0-0x7f.
--
Andriy Gapon
on 21/11/2008 15:55 Andriy Gapon said the following:> It seems that smbmsg is another victim in "Great SMBus Slave Address > Confusion" - there are two schools: one that think that slave address is > (addr >> 1) and there other thinks that slave address is (addr & ~0x1). > It seems that smb driver in FreeBSD takes the first approach, but smbmsg > is keen on the second.Patch and new output: diff --git a/usr.sbin/smbmsg/smbmsg.c b/usr.sbin/smbmsg/smbmsg.c index 425b782..f2b8139 100644 --- a/usr.sbin/smbmsg/smbmsg.c +++ b/usr.sbin/smbmsg/smbmsg.c @@ -68,8 +68,8 @@ static unsigned short oword, iword; * 240 are reserved. Address 0 is the global address, but we do not * care for this detail. */ -#define MIN_I2C_ADDR 16 -#define MAX_I2C_ADDR 240 +#define MIN_I2C_ADDR 8 +#define MAX_I2C_ADDR 120 static int do_io(void); static int getnum(const char *s); @@ -109,7 +109,7 @@ probe_i2c(void) printf("Probing for devices on %s:\n", dev); - for (addr = MIN_I2C_ADDR; addr < MAX_I2C_ADDR; addr += 2) { + for (addr = MIN_I2C_ADDR; addr < MAX_I2C_ADDR; addr++) { c.slave = addr; flags = 0; if (ioctl(fd, SMB_RECVB, &c) != -1) $ smbmsg -p Probing for devices on /dev/smb0: Device @0x08: w Device @0x44: rw Device @0x50: rw Device @0x52: rw Device @0x69: rw The only thing I am hesitant about - which address format is to present to user? (addr >> 1) as above or (addr & ~0x1) as conventional for linux folk. -- Andriy Gapon
As Andriy Gapon wrote:> Now: > > (0x44 << 1) & 0xff == (0xc4 << 1) & 0xff = 0x88 (looks like RTC) > (0x50 << 1) & 0xff == (0xd0 << 1) & 0xff = 0xa0 (well known SPD addr) > (0x52 << 1) & 0xff == (0xd2 << 1) & 0xff = 0xa4 (well known SPD addr) > (0x80 << 1) & 0xff = 0x0 (mentioned above "global address") > (0x88 << 1) & 0xff == MIN_I2C_ADDR = 0x10 (something weird) > > I think that this demonstrates that FreeBSD smb driver expects slave > addresses in range 0x0-0x7f.Well, the machine I've been writing smbmsg(8) on has been a Sun E450 I don't have access to any longer, so I cannot post a live example output. However, I could swear the output did make sense on that machine, i. e. the typical 0xa0 etc. addresses were populated there. Basically, the 0xa0 example you can find in the EXAMPLES section of the man page has been tailored after an actual session transcript made on said Sun E450. (I'm not completely sure about the 0x70 example anymore, this could be a hypothetical one.) So could that be a backend driver issue, so various backend drivers use different addressing formats? *shudder* -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)