ed021daf2d
We're not storing all GPIO lines we're retrieving with
qdev_get_gpio_in() in mal_irqs[]. We're storing just the last one in the
first index:
for (i = 0; i < ARRAY_SIZE(mal_irqs); i++) {
mal_irqs[0] = qdev_get_gpio_in(uic[2], 3 + i);
}
ppc4xx_mal_init(env, 4, 16, mal_irqs);
mal_irqs is used in ppc4xx_mal_init() to assign the IRQs to MAL:
for (i = 0; i < 4; i++) {
mal->irqs[i] = irqs[i];
}
Since only irqs[0] has been initialized, mal->irqs[1,2,3] are being
zeroed.
This doesn´t seem to trigger any apparent issues at this moment, but
Cedric's QOMification of the MAL device [1] is executing a
sysbus_connect_irq() that will fail if we do not store all GPIO lines
properly.
[1] https://lists.gnu.org/archive/html/qemu-devel/2022-08/msg00497.html
Cc: Peter Maydell <peter.maydell@linaro.org>
Cc: BALATON Zoltan <balaton@eik.bme.hu>
Fixes:
|
||
---|---|---|
.. | ||
e500-ccsr.h | ||
e500.c | ||
e500.h | ||
e500plat.c | ||
fdt.c | ||
fw_cfg.c | ||
Kconfig | ||
mac_newworld.c | ||
mac_oldworld.c | ||
mac.h | ||
meson.build | ||
mpc8544_guts.c | ||
mpc8544ds.c | ||
pef.c | ||
pegasos2.c | ||
pnv_bmc.c | ||
pnv_core.c | ||
pnv_homer.c | ||
pnv_lpc.c | ||
pnv_occ.c | ||
pnv_pnor.c | ||
pnv_psi.c | ||
pnv_xscom.c | ||
pnv.c | ||
ppc4xx_devs.c | ||
ppc4xx_pci.c | ||
ppc405_boards.c | ||
ppc405_uc.c | ||
ppc405.h | ||
ppc440_bamboo.c | ||
ppc440_pcix.c | ||
ppc440_uc.c | ||
ppc440.h | ||
ppc_booke.c | ||
ppc.c | ||
ppce500_spin.c | ||
prep_systemio.c | ||
prep.c | ||
rs6000_mc.c | ||
sam460ex.c | ||
spapr_caps.c | ||
spapr_cpu_core.c | ||
spapr_drc.c | ||
spapr_events.c | ||
spapr_hcall.c | ||
spapr_iommu.c | ||
spapr_irq.c | ||
spapr_numa.c | ||
spapr_nvdimm.c | ||
spapr_ovec.c | ||
spapr_pci_nvlink2.c | ||
spapr_pci_vfio.c | ||
spapr_pci.c | ||
spapr_rng.c | ||
spapr_rtas_ddw.c | ||
spapr_rtas.c | ||
spapr_rtc.c | ||
spapr_softmmu.c | ||
spapr_tpm_proxy.c | ||
spapr_vio.c | ||
spapr_vof.c | ||
spapr.c | ||
trace-events | ||
trace.h | ||
virtex_ml507.c | ||
vof.c |