Hello!
> The problem I'm seeing is that at least one driver
> has signed up to handle the wrong IRQ because,
> when it queried that PCI config value, it went
> back and got it from PCI config space rather
> than from the in-kernel data structures where the
> (correct) recalculated value had been
>> The problem I'm seeing is that at least one driver
>> has signed up to handle the wrong IRQ because,
>> when it queried that PCI config value, it went
>> back and got it from PCI config space rather
>> than from the in-kernel data structures where the
>> (correct) recalculated value had been
Michael O'Donnell wrote:
> [...] Later on, various
> drivers use code like pcibios_read_config_byte()
> to query the IRQ value for use during setup of
> their interrupt handlers.
Unless there is a very special reason, that's a driver bug. Please
define "various drivers" so we can fix them :)
>
On Sat, 21 Oct 2000, Michael O'Donnell wrote:
>
>
> Is there something (other than the kernel sources)
> that I can read in order to understand the background
> to the current state of PCI handling? I'm asking
> because I (think I) have found an interrupt handling
> bug that derives from uncoo
Is there something (other than the kernel sources)
that I can read in order to understand the background
to the current state of PCI handling? I'm asking
because I (think I) have found an interrupt handling
bug that derives from uncoordinated management of
PCI config info, but I don't want to p
5 matches
Mail list logo
