> We have to include the IPMI information in a way which can be used > for controllers which are accessed via memory mapped or legacy I/O.
How to access registers is implicit in the device tree; just look at the parent bus, it knows how to do it, given the "reg" value in your device. > (2) > name = ipmi > device_type device_type = ipmi-kcs There's no real reason to include the IPMI version number in here, if you really need the version it's trivial to probe for; it's not a property of the hardware but of the software on the controller (unless some day the IPMI spec breaks backwards compatibility, of course). > regs = <addr> <len> > reg-spacing = <number> > reg-size = <number> > reg-shift = <number> > > The main difference between (1) and (2) is that (2) will represent > the whole register region within the reg property. Which is the proper thing to do. The "reg" property should describe all of the address space your device listens to. Some IPMI-KCS devices listen to just the two registers, some listen to an 8-reg block, some to a 16-reg block. > Because of that > you have to include additional properties. Yes, since the device driver needs some additional information. This is quite natural and logical. Trying to do some clever workaround will only come back to bite you later. > In (1) you will include every register (e.g. Cmd / Status, Data_In / > Data_Out, etc.) within the reg property. The values for reg-spacing > are calculated by subtracting addr2 - addr1. The reg-size are the > len's within the reg property. This is giving additional semantics to the "reg" property that is compatible to its standard semantics for "standard" IPMI-KCS devices (which don't really _need_ that extra info, those are the default values); however, they will not be compatible for some (future) "special" devices. > Personally I prefer (1), because I a the moment I don't seea big > benefit in (2). For both options of have to implement source code You shouldn't be thinking "how does Linux use the device tree"; you should think "how does the device tree describe the hardware". > which checks the compatible node to get the used interface type. > According to the emitted interface type you have to read in (1) two > or three registers from the reg property. The "reg" property has some semantics independent of the device node it is in, too -- only dependent on that device's parent bus. Don't break that :-) 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
