On Wed, Nov 16, 2005 at 07:43:29PM +0300, Andrey Volkov wrote: <snip> > > Same reasonment holds for the m41t00 vs. m41t85 choice. You can't decide > > at compilation time. If we go for a common driver, it has to support > > both devices at the same time. Mark suggested to use platform-specific > > data. I'm not familiar with this, but it sounds reasonable. > It's pity, but all chips of m41xx family (approx. 20 members) have same > i2c slave address (0x68) and have not some hwd model specific id > registers. Hence I couldn't made any clue about chip specific > regs/pins/... at run-time The hope is that your platform determines the type of rtc chip and then passes that into the m41txx driver. If your platform can have different rtc chips and no way to determine which one is there at runtime, we have a problem. > (and couldn't use two or more chips in one i2c subnet :)). > And the situation worsens, as various chips have various > time regs offsets, as ex. REG_SEC of m41t00 have offset 0, but > in m41t85 _SAME_ REG_SEC have offset 1, etc (God, who in ST was so, > hm, ...., so made such decision?). I'll peruse the datasheets to see how feasible it is to merge. At this point, I think its possible but that may be my ignorance talking. > So I coldn't see any suitable run-time method of detection which > function driver could use for current "unknown" m41xx chip (from driver > probe point of view) whithout Kconfig/module parameter prompting. See above. > > I don't know for sure at this point whether having a single driver is > > the right choice, I'll let you and Mark check it out and decide. But > > the right way to determine this is definitely not through the use of > > #if/#endif preprocessing stuff. > IMHO - single driver for all m41xx will be nice thing, but I'm not > sure that it will not be monster- alike when it be released. Understood. I'll see what I can come up with. If it looks reasonable, I'll run it past everyone. Mark
