On Tue, 2016-09-06 at 16:42 +0200, Cédric Le Goater wrote: > > Alternatively.. it might be simpler to just drop the SCOM as a > > separate device. I think you could just hang the scom bus directly > > off the chip object. IIUC the scom is basically the only chip- > level > > control mechanism, so this does make a certain amount of sense. > > yes. I am exposing more and more stuff of the chip object under the > xscom object so we should merge them. I agree. We will still need > some XScomDevice of some sort.
What you can do is split it this way which matches the HW: - The chip object is the XSCOM parent, it owns the XSCOM bus, and expose functions (methods) to read/write XSCOMs. WE could rename XSCOM to "PIB" or "PCB" which is the real name of the bus ;-) But that might confuse things more than help . - A separate ADU object on each chip that is a SysDevice and does the MMIO bridge to XSCOM. It decodes the MMIO range for that chip and calls the above accessors. That makes it easy to generate XSCOMs using different mechanisms if we wish to do so, which could come in handy, such as monitor commands, or if we ever do cosimulation with a separate BMC, a simulated FSI, all by just calling the first object's methods. Cheers, Ben.