On 2012-01-13 16:57, Andreas Färber wrote: > Am 13.01.2012 10:21, schrieb Jan Kiszka: >> On 2012-01-13 04:09, Andreas Färber wrote: >>> + isa_bus = DO_UPCAST(ISABus, qbus, qdev_get_child_bus(&pci->qdev, >>> "isa.0")); >>> + >>> + i8259 = isa_bus->irqs; >> >> I think this is unneeded. > > The problem here was that isa_get_irq() needs an ISADevice*, not just > the ISABus*, so I had to access ->irqs directly at this point.
Which is a hack that should not be merged. > > Some of the later ISA devices are optional, others will be moved to the > pc87312. The i8042 might be an option if we really have to. > >> You only access i8259[8] later on for >> initializing the m48t59. > > And immediately following your quote i8259[9] and i8259[11] for the host > bridge. I was looking at upstream. Which patch is this? > > The alternative would be to access the i8259's IRQs (initialized in the > PCI-ISA bridge needing the PCI host bridge) via a QOM property from > here. Or access the PCI host bridge from the PCI-ISA bridge init. > >> But that one should be creatable as ISA device >> now (m48t59_init_isa), no? Please check. > > Ah, that matches a patch by Hervé confusingly named "fix compilation". > Using the ISA version even resolves the m48t59 io_base issue I reported > earlier. I'll send a separate patch and rebase onto that. What about the other IRQs? Can they be associated with ISADevices as well? Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
