George Joseph wrote: > It's always that last 10% that gets you. :) > > When I started the driver last year, I cloned one of the LM* drivers and > it worked just fine for the basic stuff just by modifying the chip and > manfacturer id. Then I thought if I'm going to do a driver for this > thing, I probably should expose as much of the chip's functionality as I > could. With 98 registers to read and 160+ sysfs entries to create > though, ?I quickly realized it would be impossible to code and maintain > the driver using the existing paradigms. Hence the table driven > approach. The details of the registers and sysfs entries are all in one > easy-to-read table. > > I think at this point the approach will have to stand unless it's going > to prevent acceptance of the driver. If it is going to be an issue I > think I'm just going to have to give up on it for a while. I only have > limited windows of time to work on it. > The table driven approach should not be a problem. Atleast one other driver (abituguru3) uses lots of tables too. Disclaimer: I'ven't look (much) at the code yet. Regards, Hans
