Subject: Re: SMBus implementation
To: Allen Briggs <briggs@netbsd.org>
From: Michael <macallan18@earthlink.net>
List: tech-kern
Date: 10/28/2005 23:56:26
--Signature_Fri__28_Oct_2005_23_56_26_-0400_+Ndop/g=zqYvPyJR
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Hello,

> > The only downside that I can think of is that an smbus-compliant
> > device might try to attach to a non-SMBus i2c host driver. smbus(4)
> > children should only be allowed to speak "SMBus", not "I2C", to the
> > target IC.
>=20
> OK.  Thinking about this a bit more, I get stuck unless we define
> smbus and attach smbus devices to either smbus directly-configured
> or iic indirectly-configured.
>=20
> As you know, the i2c devices aren't smart and will just match if
> the address matches (or in the case of Michael's, if the match
> function is called at all).

My iic_match functions can do better, I didn't pay too much attention
to them since the drivers usually attach directly to ki2c where the
addresses are supplied by the OF device tree and we can patch against
the 'compatible' property. It's not used by anything right now anyway.
lm75.c for instance just matches against the bus address.

> smbus devices have a standard mfg/dev in regs 0xfe/0xff, right?
> So the match functions for these would presumably compare these
> ids against a constant/list.

Hmm, the datasheets for both AD chips mention vendor, device ID and
revision number in registers 0x3d-0x3f, no idea if that's compliant to
anything.

> So I'd really be inclined to go the route of providing iic and
> smbus attachments for smbus devices and make an smbus_attach_args
> that looks something like:
>=20
> 	struct smbus_attach_args {
> 		struct i2c_attach_args	sma_ia;
> 		u_int8_t		sma_mfgid;
> 		u_int8_t		sma_devid;
> 	};
>=20
> So the attach functions could be shared between smbus and iic,
> but they would need separate match functions, cfattach_decl, etc.
> It seems a little more than necessary, but I don't see a way
> around it at the moment.

Sounds reasonable. On the other hand - the iic match function would try
to read the vendor and device IDs anyway ( I think at least mine should
really do that since ADT7467 and ADM1030 default to the same bus address
but are otherwise incompatible ) so having two match functions
essentially doing the same and differing only where they get the IDs
from seems a bit redundant.=20

have fun
Michael

--Signature_Fri__28_Oct_2005_23_56_26_-0400_+Ndop/g=zqYvPyJR
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (NetBSD)

iQEVAwUBQ2Ly6spnzkX8Yg2nAQJ2dgf+OlE+Ky1I9UDBYB82PlE5p//U10vryXuV
EiAvaZFschAgRpS1+nY0jmFIfALSJaRuqrLkGDFE053YE0pn1i8iRtk8TS0GOsJ9
9Y7/lvd3vW5MrifRo2aNb0RSuOl3dr3Xkl4f/e4SnvseYLrT/nmT1mmr67IcHzrK
RGPxGVCIwaFBnJWnQ/dLmQrP/OYLuOvnlBPfDWGNNIG42pxTSEJENq9TmgW0wJTf
1GmyREfIclM00v3YBoq9BD545YhgMq5wjyJoJDHTp8WH3BU/xeYdKZdbV3DAqgie
wt+P1ZLHU+jfZA3CF42keDGfDolE7UOjRJfTvm+CTFcwlvjqd+VJGA==
=pg4N
-----END PGP SIGNATURE-----

--Signature_Fri__28_Oct_2005_23_56_26_-0400_+Ndop/g=zqYvPyJR--