Re: [NEW PATCH] VIA IRQ quirk behaviour change

[Sergio Monteiro Basto]

On Wed, 2006-09-06 at 19:49 -0400, Daniel Drake wrote:
> Sergio,
> 
> Stian appears to be walking proof that quirks are sometimes required
> in 
> IO-APIC mode.
> 
> My next move would be to modify the patch to not revert Bjorn's
> changes 
> (but leave Linus' modification in place, alongside the southbridge 
> detection). Any thoughts? 

Hi Daniel, since you ask for thoughts :)

yap, is the obvious conclusion, but no, my bet is one problem with USB
and USB guys could put the USB things working. 
I just had remember, my Asrock with VIA8237 and VIA SATA (where I am
write now) is working without quirks and USB guys made a patch, by
coincidence. Since then have been working great.
http://bugzilla.kernel.org/show_bug.cgi?id=6419#c19

About Linus patch I have to correct me about what I had write,
http://lkml.org/lkml/2005/9/27/113
«(it used to say "if we have an IO-APIC, don't do this" (my patch), now
it says "if this irq is bound to an IO-APIC, don't do this")»
Or my patch or the Linus patch, not both.


diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c 
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -546,7 +546,10 @@ static void quirk_via_irq(struct pci_dev
 {
 	u8 irq, new_irq;
 
-	new_irq = dev->irq & 0xf;
+	new_irq = dev->irq;
+	if (!new_irq || new_irq >= 15)
+		return;
+
 	pci_read_config_byte(dev, PCI_INTERRUPT_LINE, &irq);
 	if (new_irq != irq) {

but I look to this Linus patch and I see 2 bugs
one should be > not >= and new_irq after tests new_irq should be dev->irq & 0xf;
like this:
-	new_irq = dev->irq & 0xf;
+	new_irq = dev->irq;
+	if (!new_irq || new_irq > 15)
+		return;
+	new_irq = dev->irq & 0xf;
	pci_read_config_byte(dev, PCI_INTERRUPT_LINE, &irq);
 	if (new_irq != irq) {

or simply :

+	if (!dev->irq || dev->irq > 15)
+		return;
	new_irq = dev->irq & 0xf;

About Stian computer, looking for /proc/interrupts 

11:      30696      27559   IO-APIC-level  uhci_hcd:usb1, uhci_hcd:usb2, uhci_hcd:usb3

have USB on irq 11, with IO-APIC-level, which less acpi is not normal on
low numbers ( <=15  )  be IO-APIC-level,  normally is IO-APIC-edge. 
Could be a ACPI problem .

Thanks,
-- 
Sérgio M. B.

Attachment: smime.p7s
Description: S/MIME cryptographic signature