> > 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. > The other option would be to write separate drivers (one for each chip) and not provide > a common infrastructure. Not sure if that is a good idea, though; I personally prefer > the first option. Same here. It will be a lot easier to maintain the code dealing with generic PMBus commands if it is centralized. Regards, Wolfram -- Pengutronix e.K. | Wolfram Sang | Industrial Linux Solutions | http://www.pengutronix.de/ |
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ lm-sensors mailing list lm-sensors@xxxxxxxxxxxxxx http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
