[Openipmi-developer] [patch 1/1] ipmi: add autosensing of ipmi device on powerpc using device-tree

[Arnd Bergmann]

On Sunday 10 December 2006 19:42, Heiko J Schick wrote:
> On 09.12.2006, at 12:44, Arnd Bergmann wrote:
> 
> 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.

There should be no legacy I/O on an of_platform device, but only
on behind a PCI or ISA bus, right? For PCI, the probing happens
using the pci ipmi driver, so that's not our problem here, and
I hope we don't need to worry about ISA buses any more.

> Furthermore, we have to include the register information that it will  
> work not only for KCS interfaces. It should be possible to include BT  
> and SMIC interfaces, too.

yes

> We have two options how we wanna present IPMI in the OFDT.
> 
> (1)
> 
> name = ipmi
> device_type = ipmi
> compatible = ipmi-kcs, ipmi-1.5, ...
> 
> regs = <addr> <len> <addr> <len> (for KCS interfaces)
> 	or
> regs = <addr> <len> <addr> <len> <addr> <len> (for BT and SMIC  
> interfaces)
> 
> (2)
> name = ipmi
> device_type
> 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. Because of that  
> you have to include additional properties.
> 
> 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.
> 
> Personally I prefer (1), because I a the moment I don't see a big  
> benefit in (2). For both options of have to implement source code  
> 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.
> 
> In (2) you have to calculate two or three addresses (with the help of  
> reg and the additional reg-spacing, etc. properties).

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.

	Arnd <><