aboutsummaryrefslogtreecommitdiff
path: root/hw/timer/omap_gptimer.c
diff options
context:
space:
mode:
authorDaniel Henrique Barboza <danielhb413@gmail.com>2022-08-11 13:39:41 -0300
committerDaniel Henrique Barboza <danielhb413@gmail.com>2022-08-31 14:08:05 -0300
commitb7c1750dc440bb46ddc38dd0c391d6394db7bdb1 (patch)
treee466ae192c4c245f3959d78d2bcae47fafdfe9c0 /hw/timer/omap_gptimer.c
parent8ec1e4f1ef974e901b416fef6c3b38a5cc2eeffa (diff)
downloadqemu-b7c1750dc440bb46ddc38dd0c391d6394db7bdb1.zip
qemu-b7c1750dc440bb46ddc38dd0c391d6394db7bdb1.tar.gz
qemu-b7c1750dc440bb46ddc38dd0c391d6394db7bdb1.tar.bz2
ppc/pnv: add phb-id/chip-id PnvPHB4RootBus properties
The same rationale provided in the PHB3 bus case applies here. Note: we could have merged both buses in a single object, like we did with the root ports, and spare some boilerplate. The reason we opted to preserve both buses objects is twofold: - there's not user side advantage in doing so. Unifying the root ports presents a clear user QOL change when we enable user created devices back. The buses objects, aside from having a different QOM name, is transparent to the user; - we leave a door opened in case we want to increase the root port limit for phb4/5 later on without having to deal with phb3 code. Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-Id: <20220811163950.578927-3-danielhb413@gmail.com>
Diffstat (limited to 'hw/timer/omap_gptimer.c')
0 files changed, 0 insertions, 0 deletions