Hi all > Subject: aspeed: Split the machine definition into individual source files > > Hi, > > This is a follow up of a private discussion with Patrick. > > Aspeed modeling started nearly 10y ago with the palmetto-bmc machine. > We now have 5 SoCs and 25 machines which are mostly defined in in a single > aspeed.c file. Multi SoC machines, fby35 and ast2700fc, are defined in fby35.c > and aspeed_ast27x0-fc.c respectively. > > Since we started separating the SoCs : > > hw/arm/aspeed_ast10x0.c > hw/arm/aspeed_ast2400.c > hw/arm/aspeed_ast2600.c > hw/arm/aspeed_ast27x0.c > hw/arm/aspeed_ast27x0-ssp.c > hw/arm/aspeed_ast27x0-tsp.c > > We could do the same for the machines keeping an 'aspeed_ast<rev>' > prefix (and maybe avoid the 'bmc' suffix). I think this would ease > introduction > of new machines. We would be able to get rid of aspeed_eeprom.[ch] and > move machine custom data in the machine source file. Which seems cleaner. > > Timing is about right for code reshuffling, still 3w before soft freeze, no > important changes inflight, but if we start doing this conversion, we should > do > it for all. See the list below for the brave. > > Comments ? > > Thanks, > > C. > > > > * AST2400 > > palmetto-bmc > quanta-q71l-bmc > supermicrox11-bmc > > * AST2500 > > ast2500-evb > romulus-bmc > sonorapass-bmc > witherspoon-bmc > yosemitev2-bmc > supermicro-x11spi-bmc > fp5280g2-bmc > g220a-bmc > tiogapass-bmc > > * AST2600 > > ast2600-evb > qcom-dc-scm-v1-bmc > qcom-firework-bmc > rainier-bmc > fuji-bmc > bletchley-bmc > fby35-bmc (fby35.c should rename to > aspeed_ast2600-fby35.c) > > * AST2700 > > ast2700a0-evb > ast2700a1-evb > ast2700fc (aspeed_ast27x0-fc.c) > > * AST1030 > > ast1030-evb
I’ve started working on this refactoring and have sent the first patch for the AST1030: https://patchwork.kernel.org/project/qemu-devel/patch/[email protected]/ I’m doing this because I plan to add a new machine for the AST1060, and it seems like a good opportunity to perform this cleanup first. I just want to make sure I’m moving in the right direction — could you please help review it? If you agree with the following plan, I’ll create a new patch series to move all existing machines into separate aspeed_ast<rev>_boards.c files: Planned structure Create aspeed_ast10x0_boards.c ast1030-evb Create aspeed_ast2400_boards.c palmetto-bmc quanta-q71l-bmc supermicrox11-bmc Create aspeed_ast2500_boards.c (Or should these be grouped with aspeed_ast2400_boards.c? — I’d appreciate your thoughts.) ast2500-evb romulus-bmc sonorapass-bmc witherspoon-bmc yosemitev2-bmc supermicro-x11spi-bmc fp5280g2-bmc g220a-bmc tiogapass-bmc Create aspeed_ast2600_boards.c ast2600-evb qcom-dc-scm-v1-bmc qcom-firework-bmc rainier-bmc fuji-bmc bletchley-bmc Rename fby35.c -> aspeed_ast2600-fby35.c fby35-bmc Create aspeed_ast27x0_board.c ast2700a0-evb ast2700a1-evb Keep aspeed_ast27x0-fc.c ast2700fc One last question Do you think it’s better to: Create one commit per SoC generation (e.g. one for all AST2500-based machines), or Create one commit per board (e.g. one for ast2500-evb, one for romulus-bmc, etc.)? Thanks, Jamin
