>> I'd like to see (2), because that's what the driver currently >> expects. >> The common ipmi code in linux _always_ does this calculation >> anyway, and >> (1) only means we have to compute the reg-spacing and reg-size from >> the >> layout of the registers, which gets rather complicated if you have >> more >> than two of them in the reg property. > > Yes, that is correct, but what happens if you have three registers > and because of stupid reasons the reg-spacing and reg-size is > different. > > In (1) you can handle it without problems, in (2) not.
You mean, say, a 32-bit reg at (local) address 0 and 4, and an 8-bit reg at offset 16? Neither (1) nor (2) can handle that -- the Linux interface isn't generic enough for that. Both (1) and (2) can describe the register space just fine in "reg"; the "reg" property doesn't describe how to use the registers, just where they are. I doubt the IPMI spec allows such weird devices anyway. > Also, where is > the difference if you have to calculate the reg-spacing, etc. (1) or > the addresses (2). The effort is more or less exactly the same. The device tree describes the hardware. How an OS (like Linux) has to interpret it to fit that info to its internal interfaces is the OS' problem, it's a big layering violation to put that info into the device tree. I wouldn't worry about supporting non-KCS controllers in your Linux code right now at all -- you can't test it anyway, it's dead code until someone makes such a device. Segher ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Openipmi-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openipmi-developer
