>> Actually it does in some cases. I know of two devices that have analog
>> tuners on an smbus-like interface (OV511 USB TV and W9967CF USB TV). The
>> tuner can be controlled using a pair of i2c_smbus_write_byte_data()
>> calls.
>
> Hmm, maybe we should rename the SMBUS class to SENSORS or MAINBOARD or
> something like that? I assumed you smbus interfaces are used for
> mainboard sensors only ...
I think it's best as-is. SMBus adapters have no specific purpose; they are just an attach point for various systems management devices. Without some sort of external config, there would be no way to know in advance whether a particular SMBus adapter is intended for temperature sensors, DRAM SPD, or Thinkpad-self-destruct chips. MAINBOARD wouldn't even be accurate, now that SMBus can be in SATA II enclosures etc...
SMBus *algorithm*, OTOH can be used by just about any adapter that has a high-level register interface and doesn't want to implement full I2C protocol. The video devices mentioned above use i2c_algo_smbus, but aren't full-fledged SMBus adapters (they are 100% self-contained). Their class will be (CAM_DIGITAL | TV_ANALOG).
I do think that an SMBus or I2C adapter that knows exactly what chips are attached to it (based on PCI IDs or whatever) should have some way to filter out undesired I/O. Right now, client drivers can whitelist/blacklist adapters, but not vice-versa (the client ID isn't passed to master_xfer or smbus_xfer).
It's a pain when all sorts of random clients probe my webcams. Your client scheme thankfully fixes most of that, but not all. Example: I have a webcam that can't detect I2C NAKs, and can't handle the usual "ADDR + 0-data-bytes" probes. Various clients probe it, and since they get no NAK, they start uploading registers and crash the poor camera. I have no way to whitelist the desired clients.
>> Would a patch that adds smbus algorithm support to tuner.c be
>> acceptable?
>
> Yes.
OK, I'll send you it soon. BTW, who should I submit my camera chip driver to? (It will live somewhere under drivers/media I think)
> Certainly makes more sense than duplicating the whole rest of
> tuner.c just for a smbus-aware tuner driver ;)
My original solution was an algorithm layer that splits 4 bytes into 2 iff the client is tuner.c, but that was an abominable hack ;)
Thanks,
-- Mark McClelland mark@alpha.dyndns.org__________________________________________________________________ Try AOL and get 1045 hours FREE for 45 days! http://free.aol.com/tryaolfree/index.adp?375380
Get AOL Instant Messenger 5.1 free of charge. Download Now! http://aim.aol.com/aimnew/Aim/register.adp?promo=380455 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/