On Sun, May 30, 2010 at 12:15:07AM -0400, Wolfram Sang wrote: > > > So, the approach I see (unless I miss something) would be writing an > > > hwmon-I2C-driver named pmbus-devices.c or so which covers the generic > > > functionality and provides some hooks for manufacturer extensions, if those are > > > necessary? (Altough I'd hope a number of devices would be covered by the > > > generic driver) Makes sense? > > > > > That would be one option. It would require either a register() API call, or a table > > of supported chips, or a combination of both, to identify how many channels > > (or pages, in PMBus terminology) per chip are supported and to identify supported > > objects/registers. > > I am missing the details here, i.e. what data is needed to describe a device > and is the data static or can it be retrieved/updated at runtime. A decision > between tables[] or register() or both depends probably on that. > It _may_ be possible to detect the supported commands (ie sensors per page/phase) reliably using the QUERY command, but I do not feel comfortable doing the same to determine the number of pages and phases supported. I'll have to see once I get my hands on actual HW what can be detected reliably and what has to be configured. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
