On Wed, May 30, 2012 at 09:23:56PM +0300, Michael S. Tsirkin wrote: > On Wed, May 30, 2012 at 07:57:04PM +0200, Jan Kiszka wrote: > > On 2012-05-30 19:51, Jan Kiszka wrote: > > >> Well, I'll stop ranting here. The patch that I sent is not intrusive > > >> and simply gives you a simple way to implement pci_device_get_host_irq, > > >> also optimizing emulated devices somewhat. So if you think you need > > >> pci_device_get_host_irq I think this is a reasonable way to support > > >> that. But if you changed your mind, I don't mind. > > > > > > Sorry, your patch doesn't help me in any way. > > > > [to finish the sentence] > > > > ...as it doesn't handle the final routing step in the host bridge. > > I think you mean the logic in piix3_set_irq_level? > > True. I suggest we make piix3_set_irq_level use the map_irq > infrastructure somehow:
BTW, can't we simply override map_irq and make it read from piix3->dev.config[PIIX_PIRQC + pirq]? The root bus is part of root complex I don't see why doesn't it output an IRQ# that is directly useful to feed into the CPU. > generalize it not to rely on device->bus > relationship. > > Then something like my patch will solve the problem completely. > > > > I > > still need to look this up and provide that via pci_device_get_host_irq. > > For that I need the additional callback for host bridges. But I also > > need to solve the other problems discussed in the past hours. I'm back > > at the drawing board. > > > > Jan > > > > -- > > Siemens AG, Corporate Technology, CT T DE IT 1 > > Corporate Competence Center Embedded Linux