On Wed, 2016-11-23 at 09:48 +0100, Cédric Le Goater wrote: > On 11/23/2016 01:46 AM, Alastair D'Silva wrote: > > On Tue, 2016-11-22 at 17:56 +0100, Cédric Le Goater wrote: > > > On 11/17/2016 05:36 AM, Alastair D'Silva wrote: > > > > > > > > > > > > From: Alastair D'Silva <alast...@d-silva.org> > > > > > > > > Connect an RX8900 RTC to i2c12 of the AST2500 SOC at address 0x32 > > > > > > If this is a board device, we should include it under a machine > > > routine. > > > > > > Is that for the palmetto ? The ast2500 does not have a RTC. > > > > > > Thanks, > > > > > > C. > > > > Ok > > > I suppose we could change aspeed_board_init() to return > a AspeedSoCState* and use the soc object in the specific > <machine>_init routines to add devices. > > Andrew, what is your opinion on that ?
I see the I2C bus configuration as a declarative problem. In a similar vein we already have AspeedBoardConfig, so I think we should try to describe the buses and attached devices there. That way we can have a generic aspeed_i2c_bus_init() routine that we call inside aspeed_board_init(). This would avoid encoding the buses and their slaves in the board- specific init code. Is that a reasonable alternative? I agree that we need to use a different approach to that which the current patch is using. Andrew
signature.asc
Description: This is a digitally signed message part
