[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1163009130.23956.57.camel@localhost.localdomain>
Date: Wed, 08 Nov 2006 18:05:30 +0000
From: Alan Cox <alan@...rguk.ukuu.org.uk>
To: Sergey Vlasov <vsu@...linux.ru>
Cc: Sergio Monteiro Basto <sergio@...giomb.no-ip.org>, akpm@...l.org,
Wilco Beekhuizen <wilcobeekhuizen@...il.com>,
linux-kernel@...r.kernel.org
Subject: Re: VIA IRQ quirk missing PCI ids since 2.6.16.17
Ar Mer, 2006-11-08 am 20:22 +0300, ysgrifennodd Sergey Vlasov:
> Hmm, the old comment mentions 686A/B explicitly - seems that these old
> chips also use PCI_INTERRUPT_LINE to control interrupt routing. Is it
> correct to ignore them here? Yes, that chips used PCI and not VLink,
> but they also had an internal PIC (and even internal IO-APIC).
>
> Unfortunately, I no longer have such hardware available.
I have enough docs to extend this approach to those chips if neccessary.
Anyone got an old 686 board to check.
> > + /* May not be needed for the 8237 */
> > + { PCI_VDEVICE(VIA, PCI_DEVICE_ID_VIA_8237), 15 },
> > + { PCI_VDEVICE(VIA, PCI_DEVICE_ID_VIA_8237A), 15 },
>
> 8237 definitely uses PCI_INTERRUPT_LINE to control interrupt routing in
> PIC mode - tested with the audio part by writing bogus values with
> setpci and checking whether interrupts are delivered.
Ok
> If there is no VIA ISA bridge in the system, this won't cache anything.
I no, thats noted in the comments when I posted the diff. If it works
I'll cache ->driver_data instead.
> > -int pci_dev_present(const struct pci_device_id *ids)
> > +struct pci_device_id *pci_find_present(const struct pci_device_id *ids)
>
> New API without proper refcounting? Ewww.
pci_device_id objects are not refcounted and don't vanish underneath us.
Devices may but we aren't dealing in devices. The function operates
under the list lock internally so should be safe.
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists