While checking how to fix the VIA quirk regressions for several users
introduced into -stable in 2.6.16.17, I started looking through all
drivers/pci/quirks.c updates up to both -stable and 2.6.19.
Below is the selection the seemed good and safe.
Any comments on whether it's really good or whether I should change
anything?
TIA
Adrian
Bauke Jan Douma (1):
PCI: quirk for asus a8v and a8v delux motherboards
Bjorn Helgaas (1):
PCI: quirk to disable e100 interrupt if RESET failed to
Brice Goglin (1):
PCI: nVidia quirk to make AER PCI-E extended capability visible
Daniel Drake (1):
PCI: VIA IRQ quirk behaviour change
Daniel Ritz (2):
PCI: fix ICH6 quirks
PCI: add ICH7/8 ACPI/GPIO io resource quirks
Jean Delvare (1):
PCI: Unhide the SMBus on Asus PU-DLS
John W. Linville (1):
pci_ids.h: correct naming of 1022:7450 (AMD 8131 Bridge)
Linus Torvalds (1):
Add PIIX4 APCI quirk for the 440MX chipset too
Tomasz Koprowski (1):
PCI: SMBus unhide on HP Compaq nx6110
drivers/pci/quirks.c | 172 +++++++++++++++++++++++++++++++++++++---
include/linux/pci_ids.h | 5 -
2 files changed, 167 insertions(+), 10 deletions(-)
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 381f36b..5640be5 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -390,6 +390,7 @@ static void __devinit quirk_piix4_acpi(struct pci_dev *dev)
piix4_io_quirk(dev, "PIIX4 devres J", 0x7c, 1 << 20);
}
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82371AB_3, quirk_piix4_acpi );
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82443MX_3, quirk_piix4_acpi );
/*
* ICH4, ICH4-M, ICH5, ICH5-M ACPI: Three IO regions pointed to by longwords at
@@ -427,7 +428,14 @@ static void __devinit quirk_ich6_lpc_acpi(struct pci_dev *dev)
pci_read_config_dword(dev, 0x48, ®ion);
quirk_io_region(dev, region, 64, PCI_BRIDGE_RESOURCES+1, "ICH6 GPIO");
}
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH6_0, quirk_ich6_lpc_acpi );
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH6_1, quirk_ich6_lpc_acpi );
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH7_0, quirk_ich6_lpc_acpi );
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH7_1, quirk_ich6_lpc_acpi );
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH7_31, quirk_ich6_lpc_acpi );
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH8_0, quirk_ich6_lpc_acpi );
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH8_2, quirk_ich6_lpc_acpi );
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH8_3, quirk_ich6_lpc_acpi );
/*
* VIA ACPI: One IO region pointed to by longword at
@@ -589,7 +597,7 @@ static void __init quirk_amd_8131_ioapic(struct pci_dev *dev)
pci_write_config_byte( dev, AMD8131_MISC, tmp);
}
}
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_8131_APIC, quirk_amd_8131_ioapic );
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_8131_BRIDGE, quirk_amd_8131_ioapic);
static void __init quirk_svw_msi(struct pci_dev *dev)
{
@@ -635,11 +643,43 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_4, quirk_vi
* Some of the on-chip devices are actually '586 devices' so they are
* listed here.
*/
+
+static int via_irq_fixup_needed = -1;
+
+/*
+ * As some VIA hardware is available in PCI-card form, we need to restrict
+ * this quirk to VIA PCI hardware built onto VIA-based motherboards only.
+ * We try to locate a VIA southbridge before deciding whether the quirk
+ * should be applied.
+ */
+static const struct pci_device_id via_irq_fixup_tbl[] = {
+ {
+ .vendor = PCI_VENDOR_ID_VIA,
+ .device = PCI_ANY_ID,
+ .subvendor = PCI_ANY_ID,
+ .subdevice = PCI_ANY_ID,
+ .class = PCI_CLASS_BRIDGE_ISA << 8,
+ .class_mask = 0xffff00,
+ },
+ { 0, },
+};
+
static void quirk_via_irq(struct pci_dev *dev)
{
u8 irq, new_irq;
- new_irq = dev->irq & 0xf;
+ if (via_irq_fixup_needed == -1)
+ via_irq_fixup_needed = pci_dev_present(via_irq_fixup_tbl);
+
+ if (!via_irq_fixup_needed)
+ return;
+
+ new_irq = dev->irq;
+
+ /* Don't quirk interrupts outside the legacy IRQ range */
+ if (!new_irq || new_irq > 15)
+ return;
+
pci_read_config_byte(dev, PCI_INTERRUPT_LINE, &irq);
if (new_irq != irq) {
printk(KERN_INFO "PCI: VIA IRQ fixup for %s, from %d to %d\n",
@@ -648,13 +688,7 @@ static void quirk_via_irq(struct pci_dev *dev)
pci_write_config_byte(dev, PCI_INTERRUPT_LINE, new_irq);
}
}
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_0, quirk_via_irq);
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_1, quirk_via_irq);
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_2, quirk_via_irq);
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_3, quirk_via_irq);
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686, quirk_via_irq);
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_4, quirk_via_irq);
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_5, quirk_via_irq);
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_ANY_ID, quirk_via_irq);
/*
* VIA VT82C598 has its device ID settable and many BIOSes
@@ -917,6 +951,11 @@ static void __init asus_hides_smbus_hostbridge(struct pci_dev *dev)
case 0x8070: /* P4G8X Deluxe */
asus_hides_smbus = 1;
}
+ if (dev->device == PCI_DEVICE_ID_INTEL_E7501_MCH)
+ switch (dev->subsystem_device) {
+ case 0x80c9: /* PU-DLS */
+ asus_hides_smbus = 1;
+ }
if (dev->device == PCI_DEVICE_ID_INTEL_82855GM_HB)
switch (dev->subsystem_device) {
case 0x1751: /* M2N notebook */
@@ -948,6 +987,12 @@ static void __init asus_hides_smbus_hostbridge(struct pci_dev *dev)
case 0x12bd: /* HP D530 */
asus_hides_smbus = 1;
}
+ if (dev->device == PCI_DEVICE_ID_INTEL_82915GM_HB) {
+ switch (dev->subsystem_device) {
+ case 0x099c: /* HP Compaq nx6110 */
+ asus_hides_smbus = 1;
+ }
+ }
} else if (unlikely(dev->subsystem_vendor == PCI_VENDOR_ID_TOSHIBA)) {
if (dev->device == PCI_DEVICE_ID_INTEL_82855GM_HB)
switch(dev->subsystem_device) {
@@ -978,6 +1023,7 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82845G_HB, asu
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82850_HB, asus_hides_smbus_hostbridge );
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82865_HB, asus_hides_smbus_hostbridge );
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_7205_0, asus_hides_smbus_hostbridge );
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_E7501_MCH, asus_hides_smbus_hostbridge );
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82855PM_HB, asus_hides_smbus_hostbridge );
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82855GM_HB, asus_hides_smbus_hostbridge );
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82915GM_HB, asus_hides_smbus_hostbridge );
@@ -1001,6 +1047,7 @@ static void __init asus_hides_smbus_lpc(struct pci_dev *dev)
}
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801DB_0, asus_hides_smbus_lpc );
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801BA_0, asus_hides_smbus_lpc );
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801CA_0, asus_hides_smbus_lpc );
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801CA_12, asus_hides_smbus_lpc );
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801DB_12, asus_hides_smbus_lpc );
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801EB_0, asus_hides_smbus_lpc );
@@ -1084,6 +1131,37 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_SI, PCI_DEVICE_ID_SI_651, quirk_sis_96x_
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_SI, PCI_DEVICE_ID_SI_735, quirk_sis_96x_compatible );
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_SI, PCI_DEVICE_ID_SI_503, quirk_sis_503 );
+/*
+ * On ASUS A8V and A8V Deluxe boards, the onboard AC97 audio controller
+ * and MC97 modem controller are disabled when a second PCI soundcard is
+ * present. This patch, tweaking the VT8237 ISA bridge, enables them.
+ * -- bjd
+ */
+static void __init asus_hides_ac97_lpc(struct pci_dev *dev)
+{
+ u8 val;
+ int asus_hides_ac97 = 0;
+
+ if (likely(dev->subsystem_vendor == PCI_VENDOR_ID_ASUSTEK)) {
+ if (dev->device == PCI_DEVICE_ID_VIA_8237)
+ asus_hides_ac97 = 1;
+ }
+
+ if (!asus_hides_ac97)
+ return;
+
+ pci_read_config_byte(dev, 0x50, &val);
+ if (val & 0xc0) {
+ pci_write_config_byte(dev, 0x50, val & (~0xc0));
+ pci_read_config_byte(dev, 0x50, &val);
+ if (val & 0xc0)
+ printk(KERN_INFO "PCI: onboard AC97/MC97 devices continue to play 'hide and seek'! 0x%x\n", val);
+ else
+ printk(KERN_INFO "PCI: enabled onboard AC97/MC97 devices\n");
+ }
+}
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_8237, asus_hides_ac97_lpc );
+
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_SI, PCI_DEVICE_ID_SI_961, quirk_sis_96x_smbus );
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_SI, PCI_DEVICE_ID_SI_962, quirk_sis_96x_smbus );
@@ -1292,6 +1370,63 @@ static void __devinit quirk_netmos(struct pci_dev *dev)
}
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_NETMOS, PCI_ANY_ID, quirk_netmos);
+static void __devinit quirk_e100_interrupt(struct pci_dev *dev)
+{
+ u16 command;
+ u32 bar;
+ u8 __iomem *csr;
+ u8 cmd_hi;
+
+ switch (dev->device) {
+ /* PCI IDs taken from drivers/net/e100.c */
+ case 0x1029:
+ case 0x1030 ... 0x1034:
+ case 0x1038 ... 0x103E:
+ case 0x1050 ... 0x1057:
+ case 0x1059:
+ case 0x1064 ... 0x106B:
+ case 0x1091 ... 0x1095:
+ case 0x1209:
+ case 0x1229:
+ case 0x2449:
+ case 0x2459:
+ case 0x245D:
+ case 0x27DC:
+ break;
+ default:
+ return;
+ }
+
+ /*
+ * Some firmware hands off the e100 with interrupts enabled,
+ * which can cause a flood of interrupts if packets are
+ * received before the driver attaches to the device. So
+ * disable all e100 interrupts here. The driver will
+ * re-enable them when it's ready.
+ */
+ pci_read_config_word(dev, PCI_COMMAND, &command);
+ pci_read_config_dword(dev, PCI_BASE_ADDRESS_0, &bar);
+
+ if (!(command & PCI_COMMAND_MEMORY) || !bar)
+ return;
+
+ csr = ioremap(bar, 8);
+ if (!csr) {
+ printk(KERN_WARNING "PCI: Can't map %s e100 registers\n",
+ pci_name(dev));
+ return;
+ }
+
+ cmd_hi = readb(csr + 3);
+ if (cmd_hi == 0) {
+ printk(KERN_WARNING "PCI: Firmware left %s e100 interrupts "
+ "enabled, disabling\n", pci_name(dev));
+ writeb(1, csr + 3);
+ }
+
+ iounmap(csr);
+}
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, PCI_ANY_ID, quirk_e100_interrupt);
static void __devinit fixup_rev1_53c810(struct pci_dev* dev)
{
@@ -1387,6 +1522,25 @@ static void __devinit quirk_p64h2_1k_io(struct pci_dev *dev)
}
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x1460, quirk_p64h2_1k_io);
+/* Under some circumstances, AER is not linked with extended capabilities.
+ * Force it to be linked by setting the corresponding control bit in the
+ * config space.
+ */
+static void __devinit quirk_nvidia_ck804_pcie_aer_ext_cap(struct pci_dev *dev)
+{
+ uint8_t b;
+ if (pci_read_config_byte(dev, 0xf41, &b) == 0) {
+ if (!(b & 0x20)) {
+ pci_write_config_byte(dev, 0xf41, b | 0x20);
+ printk(KERN_INFO
+ "PCI: Linking AER extended capability on %s\n",
+ pci_name(dev));
+ }
+ }
+}
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_CK804_PCIE,
+ quirk_nvidia_ck804_pcie_aer_ext_cap);
+
EXPORT_SYMBOL(pcie_mch_quirk);
#ifdef CONFIG_HOTPLUG
EXPORT_SYMBOL(pci_fixup_device);
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index 77ccd6e..386c6a7 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -496,7 +496,8 @@
#define PCI_DEVICE_ID_AMD_8111_SMBUS 0x746b
#define PCI_DEVICE_ID_AMD_8111_AUDIO 0x746d
#define PCI_DEVICE_ID_AMD_8151_0 0x7454
-#define PCI_DEVICE_ID_AMD_8131_APIC 0x7450
+#define PCI_DEVICE_ID_AMD_8131_BRIDGE 0x7450
+#define PCI_DEVICE_ID_AMD_8131_APIC 0x7451
#define PCI_DEVICE_ID_AMD_CS5536_ISA 0x2090
#define PCI_DEVICE_ID_AMD_CS5536_FLASH 0x2091
#define PCI_DEVICE_ID_AMD_CS5536_AUDIO 0x2093
@@ -1007,6 +1008,7 @@
#define PCI_DEVICE_ID_NVIDIA_NVENET_8 0x0056
#define PCI_DEVICE_ID_NVIDIA_NVENET_9 0x0057
#define PCI_DEVICE_ID_NVIDIA_CK804_AUDIO 0x0059
+#define PCI_DEVICE_ID_NVIDIA_CK804_PCIE 0x005d
#define PCI_DEVICE_ID_NVIDIA_NFORCE2_SMBUS 0x0064
#define PCI_DEVICE_ID_NVIDIA_NFORCE2_IDE 0x0065
#define PCI_DEVICE_ID_NVIDIA_NVENET_2 0x0066
@@ -2081,6 +2083,7 @@
#define PCI_DEVICE_ID_INTEL_82820_UP_HB 0x2501
#define PCI_DEVICE_ID_INTEL_82850_HB 0x2530
#define PCI_DEVICE_ID_INTEL_82860_HB 0x2531
+#define PCI_DEVICE_ID_INTEL_E7501_MCH 0x254c
#define PCI_DEVICE_ID_INTEL_82845G_HB 0x2560
#define PCI_DEVICE_ID_INTEL_82845G_IG 0x2562
#define PCI_DEVICE_ID_INTEL_82865_HB 0x2570
On Thu, 7 Dec 2006 14:24:30 +0100 Adrian Bunk wrote:
> While checking how to fix the VIA quirk regressions for several users
> introduced into -stable in 2.6.16.17, I started looking through all
> drivers/pci/quirks.c updates up to both -stable and 2.6.19.
>
> Below is the selection the seemed good and safe.
>
> Any comments on whether it's really good or whether I should change
> anything?
>
> TIA
> Adrian
>
>
> Bauke Jan Douma (1):
> PCI: quirk for asus a8v and a8v delux motherboards
This quirk will cause breakage for people who used an external PCI
soundcard with these boards - the builtin sound chip which was
invisible before may become the first audio device.
It also enables the MC97 device, which does not really work (there is
no MC97 codec attached to the controller at least on A8V Deluxe; I'm
not sure if there is some other variant of this board which has MC97,
but it seems unlikely).
[...]
Adrian Bunk wrote:
> Daniel Drake (1):
> PCI: VIA IRQ quirk behaviour change
Please drop this one, Alan isn't 100% on it and is working on getting a
better fix into mainline
Daniel
On Thu, Dec 07, 2006 at 09:38:44AM -0500, Daniel Drake wrote:
> Adrian Bunk wrote:
> >Daniel Drake (1):
> > PCI: VIA IRQ quirk behaviour change
>
> Please drop this one, Alan isn't 100% on it and is working on getting a
> better fix into mainline
Thanks for this information.
That's the one that fixes the breakage introduced in 2.6.16.17...
Looking at Alan's patch in -mm, it seems the best current solution for
2.6.16 is to go back to the pre-2.6.16.17
DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_ANY_ID, quirk_via_irq);
and revisit this after Alan's patch was released with 2.6.20?
> Daniel
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Thu, Dec 07, 2006 at 03:57:56PM +0100, Adrian Bunk wrote:
> Looking at Alan's patch in -mm, it seems the best current solution for
> 2.6.16 is to go back to the pre-2.6.16.17
> DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_ANY_ID, quirk_via_irq);
> and revisit this after Alan's patch was released with 2.6.20?
If you want 2.6.16.* not to risk any reversions of good behaviour then I'd agree
I'm pretty sure the new code is right cool and wonderful *BUT* it may not be
of course and it may also break broken bioses differently 8(
On Thu, Dec 07, 2006 at 09:32:17PM +0300, Sergey Vlasov wrote:
> On Thu, Dec 07, 2006 at 06:27:40PM +0100, Bauke Jan Douma wrote:
>...
> > I for one need this quirk to get both soundcards at all (which
> > I need) -- no matter what indexing order.
>
> I don't question the need for this patch in mainline; however, it does
> not seem to be suitable for -stable.
>...
Thanks to both of you.
First of all, I agree that this is not 2.6.16 material.
And looking at this issue at my A7V600-X, it's also a "feature" of this
quirk that it enables the onboard audio even if you explicitely disabled
it in the BIOS. I'm not sure about the correct solution in this case.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Thu, Dec 07, 2006 at 09:45:56PM +0100, Tomek Koprowski wrote:
> On Thursday 07 of December 2006 20:54, Jean Delvare wrote:
>
> > > Tomasz Koprowski (1):
> > > PCI: SMBus unhide on HP Compaq nx6110
> >
> > Bug #6944 might be related to this one, so I'd not include it in
> > 2.6.16-stable.
>
> Actually, the #6944 requires more investigation. I've noticed the
> kacpid going to 100% cpu without the unhide patch applied as well. It
> happens sometimes after dehibernation, putting the laptop to sleep
> and waking it up again resolves the issue. I can't figure out why.
>
> To be on the safe side I'd suggest dumping the patch, but I really
> don't think it should fix anything.
Thanks for this information, I've dropped it.
And this problem really be debugged and fixed in Linus' tree...
> Tomek
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Thanks for all the comments I've gotten so far.
Below is my current stack of PCI quirks updates for 2.6.16.36.
Does all of this look OK?
TIA
Adrian
Adrian Bunk (1):
revert the quirk_via_irq changes
Bjorn Helgaas (1):
PCI: quirk to disable e100 interrupt if RESET failed to
Brice Goglin (1):
PCI: nVidia quirk to make AER PCI-E extended capability visible
Daniel Ritz (2):
PCI: fix ICH6 quirks
PCI: add ICH7/8 ACPI/GPIO io resource quirks
Jean Delvare (1):
PCI: Unhide the SMBus on Asus PU-DLS
John W. Linville (1):
pci_ids.h: correct naming of 1022:7450 (AMD 8131 Bridge)
Linus Torvalds (1):
Add PIIX4 APCI quirk for the 440MX chipset too
drivers/pci/quirks.c | 101 ++++++++++++++++++++++++++++++++++++----
include/linux/pci_ids.h | 5 +
2 files changed, 97 insertions(+), 9 deletions(-)
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 381f36b..2a66e39 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -390,6 +390,7 @@ static void __devinit quirk_piix4_acpi(struct pci_dev *dev)
piix4_io_quirk(dev, "PIIX4 devres J", 0x7c, 1 << 20);
}
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82371AB_3, quirk_piix4_acpi );
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82443MX_3, quirk_piix4_acpi );
/*
* ICH4, ICH4-M, ICH5, ICH5-M ACPI: Three IO regions pointed to by longwords at
@@ -427,7 +428,14 @@ static void __devinit quirk_ich6_lpc_acpi(struct pci_dev *dev)
pci_read_config_dword(dev, 0x48, ®ion);
quirk_io_region(dev, region, 64, PCI_BRIDGE_RESOURCES+1, "ICH6 GPIO");
}
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH6_0, quirk_ich6_lpc_acpi );
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH6_1, quirk_ich6_lpc_acpi );
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH7_0, quirk_ich6_lpc_acpi );
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH7_1, quirk_ich6_lpc_acpi );
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH7_31, quirk_ich6_lpc_acpi );
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH8_0, quirk_ich6_lpc_acpi );
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH8_2, quirk_ich6_lpc_acpi );
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH8_3, quirk_ich6_lpc_acpi );
/*
* VIA ACPI: One IO region pointed to by longword at
@@ -589,7 +597,7 @@ static void __init quirk_amd_8131_ioapic(struct pci_dev *dev)
pci_write_config_byte( dev, AMD8131_MISC, tmp);
}
}
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_8131_APIC, quirk_amd_8131_ioapic );
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_8131_BRIDGE, quirk_amd_8131_ioapic);
static void __init quirk_svw_msi(struct pci_dev *dev)
{
@@ -648,13 +656,7 @@ static void quirk_via_irq(struct pci_dev *dev)
pci_write_config_byte(dev, PCI_INTERRUPT_LINE, new_irq);
}
}
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_0, quirk_via_irq);
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_1, quirk_via_irq);
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_2, quirk_via_irq);
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_3, quirk_via_irq);
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686, quirk_via_irq);
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_4, quirk_via_irq);
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_5, quirk_via_irq);
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_ANY_ID, quirk_via_irq);
/*
* VIA VT82C598 has its device ID settable and many BIOSes
@@ -917,6 +919,11 @@ static void __init asus_hides_smbus_hostbridge(struct pci_dev *dev)
case 0x8070: /* P4G8X Deluxe */
asus_hides_smbus = 1;
}
+ if (dev->device == PCI_DEVICE_ID_INTEL_E7501_MCH)
+ switch (dev->subsystem_device) {
+ case 0x80c9: /* PU-DLS */
+ asus_hides_smbus = 1;
+ }
if (dev->device == PCI_DEVICE_ID_INTEL_82855GM_HB)
switch (dev->subsystem_device) {
case 0x1751: /* M2N notebook */
@@ -978,6 +985,7 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82845G_HB, asu
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82850_HB, asus_hides_smbus_hostbridge );
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82865_HB, asus_hides_smbus_hostbridge );
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_7205_0, asus_hides_smbus_hostbridge );
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_E7501_MCH, asus_hides_smbus_hostbridge );
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82855PM_HB, asus_hides_smbus_hostbridge );
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82855GM_HB, asus_hides_smbus_hostbridge );
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82915GM_HB, asus_hides_smbus_hostbridge );
@@ -1001,6 +1009,7 @@ static void __init asus_hides_smbus_lpc(struct pci_dev *dev)
}
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801DB_0, asus_hides_smbus_lpc );
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801BA_0, asus_hides_smbus_lpc );
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801CA_0, asus_hides_smbus_lpc );
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801CA_12, asus_hides_smbus_lpc );
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801DB_12, asus_hides_smbus_lpc );
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801EB_0, asus_hides_smbus_lpc );
@@ -1292,6 +1301,63 @@ static void __devinit quirk_netmos(struct pci_dev *dev)
}
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_NETMOS, PCI_ANY_ID, quirk_netmos);
+static void __devinit quirk_e100_interrupt(struct pci_dev *dev)
+{
+ u16 command;
+ u32 bar;
+ u8 __iomem *csr;
+ u8 cmd_hi;
+
+ switch (dev->device) {
+ /* PCI IDs taken from drivers/net/e100.c */
+ case 0x1029:
+ case 0x1030 ... 0x1034:
+ case 0x1038 ... 0x103E:
+ case 0x1050 ... 0x1057:
+ case 0x1059:
+ case 0x1064 ... 0x106B:
+ case 0x1091 ... 0x1095:
+ case 0x1209:
+ case 0x1229:
+ case 0x2449:
+ case 0x2459:
+ case 0x245D:
+ case 0x27DC:
+ break;
+ default:
+ return;
+ }
+
+ /*
+ * Some firmware hands off the e100 with interrupts enabled,
+ * which can cause a flood of interrupts if packets are
+ * received before the driver attaches to the device. So
+ * disable all e100 interrupts here. The driver will
+ * re-enable them when it's ready.
+ */
+ pci_read_config_word(dev, PCI_COMMAND, &command);
+ pci_read_config_dword(dev, PCI_BASE_ADDRESS_0, &bar);
+
+ if (!(command & PCI_COMMAND_MEMORY) || !bar)
+ return;
+
+ csr = ioremap(bar, 8);
+ if (!csr) {
+ printk(KERN_WARNING "PCI: Can't map %s e100 registers\n",
+ pci_name(dev));
+ return;
+ }
+
+ cmd_hi = readb(csr + 3);
+ if (cmd_hi == 0) {
+ printk(KERN_WARNING "PCI: Firmware left %s e100 interrupts "
+ "enabled, disabling\n", pci_name(dev));
+ writeb(1, csr + 3);
+ }
+
+ iounmap(csr);
+}
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, PCI_ANY_ID, quirk_e100_interrupt);
static void __devinit fixup_rev1_53c810(struct pci_dev* dev)
{
@@ -1387,6 +1453,25 @@ static void __devinit quirk_p64h2_1k_io(struct pci_dev *dev)
}
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x1460, quirk_p64h2_1k_io);
+/* Under some circumstances, AER is not linked with extended capabilities.
+ * Force it to be linked by setting the corresponding control bit in the
+ * config space.
+ */
+static void __devinit quirk_nvidia_ck804_pcie_aer_ext_cap(struct pci_dev *dev)
+{
+ uint8_t b;
+ if (pci_read_config_byte(dev, 0xf41, &b) == 0) {
+ if (!(b & 0x20)) {
+ pci_write_config_byte(dev, 0xf41, b | 0x20);
+ printk(KERN_INFO
+ "PCI: Linking AER extended capability on %s\n",
+ pci_name(dev));
+ }
+ }
+}
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_CK804_PCIE,
+ quirk_nvidia_ck804_pcie_aer_ext_cap);
+
EXPORT_SYMBOL(pcie_mch_quirk);
#ifdef CONFIG_HOTPLUG
EXPORT_SYMBOL(pci_fixup_device);
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index 77ccd6e..386c6a7 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -496,7 +496,8 @@
#define PCI_DEVICE_ID_AMD_8111_SMBUS 0x746b
#define PCI_DEVICE_ID_AMD_8111_AUDIO 0x746d
#define PCI_DEVICE_ID_AMD_8151_0 0x7454
-#define PCI_DEVICE_ID_AMD_8131_APIC 0x7450
+#define PCI_DEVICE_ID_AMD_8131_BRIDGE 0x7450
+#define PCI_DEVICE_ID_AMD_8131_APIC 0x7451
#define PCI_DEVICE_ID_AMD_CS5536_ISA 0x2090
#define PCI_DEVICE_ID_AMD_CS5536_FLASH 0x2091
#define PCI_DEVICE_ID_AMD_CS5536_AUDIO 0x2093
@@ -1007,6 +1008,7 @@
#define PCI_DEVICE_ID_NVIDIA_NVENET_8 0x0056
#define PCI_DEVICE_ID_NVIDIA_NVENET_9 0x0057
#define PCI_DEVICE_ID_NVIDIA_CK804_AUDIO 0x0059
+#define PCI_DEVICE_ID_NVIDIA_CK804_PCIE 0x005d
#define PCI_DEVICE_ID_NVIDIA_NFORCE2_SMBUS 0x0064
#define PCI_DEVICE_ID_NVIDIA_NFORCE2_IDE 0x0065
#define PCI_DEVICE_ID_NVIDIA_NVENET_2 0x0066
@@ -2081,6 +2083,7 @@
#define PCI_DEVICE_ID_INTEL_82820_UP_HB 0x2501
#define PCI_DEVICE_ID_INTEL_82850_HB 0x2530
#define PCI_DEVICE_ID_INTEL_82860_HB 0x2531
+#define PCI_DEVICE_ID_INTEL_E7501_MCH 0x254c
#define PCI_DEVICE_ID_INTEL_82845G_HB 0x2560
#define PCI_DEVICE_ID_INTEL_82845G_IG 0x2562
#define PCI_DEVICE_ID_INTEL_82865_HB 0x2570
On Thu, Dec 07, 2006 at 06:27:40PM +0100, Bauke Jan Douma wrote:
> Sergey Vlasov wrote on 07-12-06 14:53:
> >On Thu, 7 Dec 2006 14:24:30 +0100 Adrian Bunk wrote:
> >
> >>While checking how to fix the VIA quirk regressions for several users
> >>introduced into -stable in 2.6.16.17, I started looking through all
> >>drivers/pci/quirks.c updates up to both -stable and 2.6.19.
> >>
> [snip]
> >>
> >>Bauke Jan Douma (1):
> >> PCI: quirk for asus a8v and a8v delux motherboards
> >
> >This quirk will cause breakage for people who used an external PCI
> >soundcard with these boards - the builtin sound chip which was
> >invisible before may become the first audio device.
>
> I'm afraid I don't understand the problem described here, when
> ALSA can assign any arbitrary index number of a user's choice
> to cards that are detected.
The problem is that -stable patches should not introduce regression.
And if this patch would be included in the next -stable release,
people who upgrade to this release may get unexpected changes of sound
cards indexes. This may be OK for a new 2.6.x release, but not for a
new 2.6.16.y.
> Indeed, on my system (an A8V Deluxe motherboard, with this
> quirk active), my first soundcard (given index=0) is an offboard
> Creative SB Live, and the onboard card I have assigned index=1.
Yes, now I have exactly the same setup. But before this patch I did
not have any index=N assignments in my configuration; after the patch
I needed to add them to get my system working as before.
> I for one need this quirk to get both soundcards at all (which
> I need) -- no matter what indexing order.
I don't question the need for this patch in mainline; however, it does
not seem to be suitable for -stable.
> >It also enables the MC97 device, which does not really work (there is
> >no MC97 codec attached to the controller at least on A8V Deluxe; I'm
> >not sure if there is some other variant of this board which has MC97,
> >but it seems unlikely).
>
> This one can be disabled separate of the AC97 -- let me get back
> on that. I, for one (however much that is), don't need it either.
Currently I get:
VIA 82xx Modem: probe of 0000:00:11.6 failed with error -13
on every boot (and snd_via82xx_modem module in memory). Not a grave
bug, but not a good thing either (and another reason for not adding
this patch to 2.6.16.y).
Sergey Vlasov wrote on 07-12-06 14:53:
> On Thu, 7 Dec 2006 14:24:30 +0100 Adrian Bunk wrote:
>
>> While checking how to fix the VIA quirk regressions for several users
>> introduced into -stable in 2.6.16.17, I started looking through all
>> drivers/pci/quirks.c updates up to both -stable and 2.6.19.
>>
[snip]
>>
>>
>> Bauke Jan Douma (1):
>> PCI: quirk for asus a8v and a8v delux motherboards
>
> This quirk will cause breakage for people who used an external PCI
> soundcard with these boards - the builtin sound chip which was
> invisible before may become the first audio device.
I'm afraid I don't understand the problem described here, when
ALSA can assign any arbitrary index number of a user's choice
to cards that are detected.
Indeed, on my system (an A8V Deluxe motherboard, with this
quirk active), my first soundcard (given index=0) is an offboard
Creative SB Live, and the onboard card I have assigned index=1.
I for one need this quirk to get both soundcards at all (which
I need) -- no matter what indexing order.
> It also enables the MC97 device, which does not really work (there is
> no MC97 codec attached to the controller at least on A8V Deluxe; I'm
> not sure if there is some other variant of this board which has MC97,
> but it seems unlikely).
This one can be disabled separate of the AC97 -- let me get back
on that. I, for one (however much that is), don't need it either.
bjd
Hi Adrian,
On Thu, 7 Dec 2006 14:24:30 +0100, Adrian Bunk wrote:
> While checking how to fix the VIA quirk regressions for several users
> introduced into -stable in 2.6.16.17, I started looking through all
> drivers/pci/quirks.c updates up to both -stable and 2.6.19.
>
> Below is the selection the seemed good and safe.
>
> Any comments on whether it's really good or whether I should change
> anything?
> (...)
> Jean Delvare (1):
> PCI: Unhide the SMBus on Asus PU-DLS
Should be safe.
> Tomasz Koprowski (1):
> PCI: SMBus unhide on HP Compaq nx6110
Bug #6944 might be related to this one, so I'd not include it in
2.6.16-stable.
--
Jean Delvare
On Thursday 07 of December 2006 20:54, Jean Delvare wrote:
> > Tomasz Koprowski (1):
> > PCI: SMBus unhide on HP Compaq nx6110
>
> Bug #6944 might be related to this one, so I'd not include it in
> 2.6.16-stable.
Actually, the #6944 requires more investigation. I've noticed the
kacpid going to 100% cpu without the unhide patch applied as well. It
happens sometimes after dehibernation, putting the laptop to sleep
and waking it up again resolves the issue. I can't figure out why.
To be on the safe side I'd suggest dumping the patch, but I really
don't think it should fix anything.
Tomek
--
[ [email protected] http://www.koprowski.org ]
[ JabberID: [email protected] gg#: 2348134 ]
[ Life is as bad as you make it be ]
Adrian Bunk wrote:
> While checking how to fix the VIA quirk regressions for several users
> introduced into -stable in 2.6.16.17, I started looking through all
> drivers/pci/quirks.c updates up to both -stable and 2.6.19.
>
> Below is the selection the seemed good and safe.
>
> Any comments on whether it's really good or whether I should change
> anything?
>
>
> Brice Goglin (1):
> PCI: nVidia quirk to make AER PCI-E extended capability visible
>
No problem with this one (but it won't be very useful since nobody used
the PCIe AER cap before myri10ge in 2.6.18 IIRC).
Thanks.
Brice
On Thu, 2006-12-07 at 09:38 -0500, Daniel Drake wrote:
> Adrian Bunk wrote:
> > Daniel Drake (1):
> > PCI: VIA IRQ quirk behaviour change
>
> Please drop this one, Alan isn't 100% on it and is working on getting a
> better fix into mainline
>
> Daniel
Sorry Daniel, I don't agree with you, this patch is a improvement of the
original patch and in my opinion should go in.
As Alan explain to us, is not the prefect one, but still be an
improvement.
Thanks,
--
Sérgio M. B.
On Sun, Dec 10, 2006 at 04:09:39AM +0000, Sergio Monteiro Basto wrote:
> On Thu, 2006-12-07 at 09:38 -0500, Daniel Drake wrote:
> > Adrian Bunk wrote:
> > > Daniel Drake (1):
> > > PCI: VIA IRQ quirk behaviour change
> >
> > Please drop this one, Alan isn't 100% on it and is working on getting a
> > better fix into mainline
> >
> > Daniel
>
> Sorry Daniel, I don't agree with you, this patch is a improvement of the
> original patch and in my opinion should go in.
> As Alan explain to us, is not the prefect one, but still be an
> improvement.
Below is the patch for going back to the 2.6.16.16 status quo that is in
2.6.16.36-rc1.
Does this cause any serious regression for anyone?
> Thanks,
> S?rgio M. B.
cu
Adrian
commit dcb1715778026c4aec20d186dc794245d9a1f5de
Author: Adrian Bunk <[email protected]>
Date: Fri Dec 8 17:00:35 2006 +0100
revert the quirk_via_irq changes
This patch reverts the quirk_via_irq changes in 2.6.16.17 that
caused regressions for several people.
Signed-off-by: Adrian Bunk <[email protected]>
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index a1cdf06..2a66e39 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -656,13 +656,7 @@ static void quirk_via_irq(struct pci_dev *dev)
pci_write_config_byte(dev, PCI_INTERRUPT_LINE, new_irq);
}
}
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_0, quirk_via_irq);
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_1, quirk_via_irq);
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_2, quirk_via_irq);
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_3, quirk_via_irq);
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686, quirk_via_irq);
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_4, quirk_via_irq);
-DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_5, quirk_via_irq);
+DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_ANY_ID, quirk_via_irq);
/*
* VIA VT82C598 has its device ID settable and many BIOSes
Adrian Bunk wrote:
> Below is the patch for going back to the 2.6.16.16 status quo that is in
> 2.6.16.36-rc1.
>
> Does this cause any serious regression for anyone?
If I remember right, it breaks Chris Wedgwood's box
> cu
> Adrian
>
>
> commit dcb1715778026c4aec20d186dc794245d9a1f5de
> Author: Adrian Bunk <[email protected]>
> Date: Fri Dec 8 17:00:35 2006 +0100
>
> revert the quirk_via_irq changes
>
> This patch reverts the quirk_via_irq changes in 2.6.16.17 that
> caused regressions for several people.
>
> Signed-off-by: Adrian Bunk <[email protected]>
>
> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index a1cdf06..2a66e39 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
> @@ -656,13 +656,7 @@ static void quirk_via_irq(struct pci_dev *dev)
> pci_write_config_byte(dev, PCI_INTERRUPT_LINE, new_irq);
> }
> }
> -DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_0, quirk_via_irq);
> -DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_1, quirk_via_irq);
> -DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_2, quirk_via_irq);
> -DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_3, quirk_via_irq);
> -DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686, quirk_via_irq);
> -DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_4, quirk_via_irq);
> -DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_5, quirk_via_irq);
> +DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_ANY_ID, quirk_via_irq);
>
> /*
> * VIA VT82C598 has its device ID settable and many BIOSes
>
On Sun, Dec 10, 2006 at 11:22:53AM -0500, Daniel Drake wrote:
> >Does this cause any serious regression for anyone?
> If I remember right, it breaks Chris Wedgwood's box
I'm not bothered about 2.6.16.x anymore, feel free to do whatever is
needed there.
On Sun, 10 Dec 2006, Chris Wedgwood wrote:
>
> > If I remember right, it breaks Chris Wedgwood's box
>
> I'm not bothered about 2.6.16.x anymore, feel free to do whatever is
> needed there.
That's really not the point.
What's the whole _reason_ for 2.6.x.y releases?
They should be safe, and OBVIOUS.
If there is a box that breaks with a 2.6.x.y release, then that .y release
was clearly a mistake, and fundamentally broke the whole point of the
stable tree. If you can't depend on the stable tree being a real
improvement - regardless of what hw you are on - then the stable tree has
lost all meaning, and you'd be better off just getting 2.6.x+1 instead.
Linus
On Sun, Dec 10, 2006 at 02:39:37PM -0800, Linus Torvalds wrote:
> They should be safe, and OBVIOUS.
Well, it's not clear to me that reverting to a quirk the pokes *all*
VIA pci devices on all machines is safe, it's not even clear if it was
a good idea to merge this.
All the same, I can retest the latest 2.6.16.x with that change
reverted but since it originally caused pain there has been a BIOS
upgrade (or two, I forget) that might affect things (for many poeple
the quirk isn't needed and CPI does the right thing).
> If there is a box that breaks with a 2.6.x.y release, then that .y
> release was clearly a mistake, and fundamentally broke the whole
> point of the 3Astable tree.
Well, I think the current 2.6.16.x release series is already broken on
some other subset of hardware.
There might be more of those than there are with the quirk-me-hard
approach --- in which case do we try to accommodate the (potential)
majority with something that is clearly wrong or so we leave them
broken for a bit longer until we can get some more coverage on Alan's
much cleaner and specific fix which I think is slated for 2.6.20 and
then backport that?
On Sun, Dec 10, 2006 at 02:39:37PM -0800, Linus Torvalds wrote:
>
> On Sun, 10 Dec 2006, Chris Wedgwood wrote:
> >
> > > If I remember right, it breaks Chris Wedgwood's box
> >
> > I'm not bothered about 2.6.16.x anymore, feel free to do whatever is
> > needed there.
>
> That's really not the point.
>
> What's the whole _reason_ for 2.6.x.y releases?
>
> They should be safe, and OBVIOUS.
>
> If there is a box that breaks with a 2.6.x.y release, then that .y release
> was clearly a mistake, and fundamentally broke the whole point of the
> stable tree. If you can't depend on the stable tree being a real
> improvement - regardless of what hw you are on - then the stable tree has
> lost all meaning, and you'd be better off just getting 2.6.x+1 instead.
If life was that easy... ;-)
The problem is that the fix for Chris' issue went into the -stable
2.6.16.17.
So we have the following situation:
- 2.6.16 - 2.6.16.16 : problems for Chris
(and possibly many other people)
- 2.6.16.17 - 2.6.16.35 : problems for many other people
(I remember 4-5 bug reports in the kernel
Bugzilla alone)
The fix in 2.6.19 was considered suboptimal, and Alan's patch for fixing
this whole issue more properly is currently not even in your tree.
Looking at the patch description of the patch that was merged into
2.6.16.17 I got the wrong impression this was a non-critical issue on
Chris' machine, and the patch could therefore be reverted.
Now it seems the best choice is to:
- go back to the 2.6.16.35 code and
- apply commit 1ae4f9ba84b94b85d995a6ae0064b869ff15b080 from your tree
that went into 2.6.18 and fixes breakage for at least some devices and
- to perhaps revisit the situation after 2.6.20 got released
(but I'm becoming more and more inclined to fix the 2.6.16.17
regression by adding more devices to the quirk if required)
> Linus
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Sun, 10 Dec 2006, Chris Wedgwood wrote:
>
> Well, it's not clear to me that reverting to a quirk the pokes *all*
> VIA pci devices on all machines is safe, it's not even clear if it was
> a good idea to merge this.
I'm just saying that the stable tree should never merge anything that can
possibly cause a regression.
> Well, I think the current 2.6.16.x release series is already broken on
> some other subset of hardware.
That's not the point. If it was broken on some subset of hardware, as long
as it's not a REGRESSION from 2.6.16, that's better than _changing_ the
breakage. And no, it doesn't really matter how many machines are affected
(ie it's not better to have a "smaller" set of cases that break, unless
it's a _strict_ subset).
The reason? It's better to be _dependable_ than to work on a maximum
number of machines. This is why _regressions_ are always much worse than
old bugs. It's much better to have "it didn't work before, and it still
doesn't work" than to have "it used to work, but now it broke".
Because people for whom something used to work should always be able to
update to a new kernel without having to constantly worry.
So for the _stable_ series, if you don't understand the problem 100%, and
you don't know that something really fixes something and never causes
regressions, such a patch simply SHOULD NOT be applied. It's that easy.
(And the argument that it "fixes more than it breaks" is a total garbage
argument for several reasons:
- you don't actually know that. You may have a lot of reports about
breakage that you think will be fixed (so you _think_ it fixes a lot),
but by definition you won't have any clue AT ALL about how much it will
break, since nobody will have tested it. The machines that weren't
broken before generally won't even bother to upgrade, so you'll find
out only much later.
- machines that didn't use to work well before are much less important
than machines that worked fine. People don't _expect_ them to work,
people don't have a history of them working. So if you fix ten machines
that didn't work before, but you break one that _did_ work before,
that's _still_ not actually a good deal. Because angst-wise, you
actually lost on it.
So please revert anythign that is even slightly open for debate in the
stable series. The whole point of the stable series is to be _stable_, and
regressions are bad.
Linus
On Mon, 11 Dec 2006, Adrian Bunk wrote:
>
> If life was that easy... ;-)
No. Life _is_ that easy.
If the 2.6.16 stable tree took a patch that was questionable, and we don't
know what the right answer to it is from the _regular_ tree, than the
patch violated the stable tree rules in the first place and should just be
reverted.
Once people know what the right answer is (and by "know", I mean: "not
guess") from the regular tree having been tested with it, and people
understanding the problem, then it can be re-instated.
But if you're just guessing, and people don't _know_ the right answer,
then just revert the whole questionable area. The patch shouldn't have
been there in the first place.
It really _is_ that simple.
Either it's a stable tree or it isn't.
Linus
On Sun, 2006-12-10 at 17:00 +0100, Adrian Bunk wrote:
> +DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_ANY_ID,
> quirk_via_irq);
This is back to state of kernel 2.6.16 final (without .x)
In kernel 2.6.17 final we got
(http://lkml.org/lkml/2006/4/19/16)
commit 75cf7456dd87335f574dcd53c4ae616a2ad71a11
Author: Chris Wedgwood <[email protected]>
Date: Tue Apr 18 23:57:09 2006 -0700
Signed-off-by: Chris Wedgwood <[email protected]>
Acked-by: Jeff Garzik <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
and
commit a7b862f663d81858531dfccc0537bc9d8a2a4121
Author: Chris Wedgwood <[email protected]>
Date: Mon May 15 09:43:55 2006 -0700
[PATCH] VIA quirk fixup, additional PCI IDs
BUT the latest stable and tested patch is the commit 09d6029f43ebbe7307854abdae204c25d711ff94
PCI: VIA IRQ quirk behaviour change, which in my opinion that should go in.
Thanks,
--
S?rgio M.B.
On Mon, Dec 11, 2006 at 01:42:48AM +0000, Sergio Monteiro Basto wrote:
> On Sun, 2006-12-10 at 17:00 +0100, Adrian Bunk wrote:
> > +DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_ANY_ID,
> > quirk_via_irq);
>
> This is back to state of kernel 2.6.16 final (without .x)
>
> In kernel 2.6.17 final we got
> (http://lkml.org/lkml/2006/4/19/16)
> commit 75cf7456dd87335f574dcd53c4ae616a2ad71a11
> Author: Chris Wedgwood <[email protected]>
> Date: Tue Apr 18 23:57:09 2006 -0700
> Signed-off-by: Chris Wedgwood <[email protected]>
> Acked-by: Jeff Garzik <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> and
> commit a7b862f663d81858531dfccc0537bc9d8a2a4121
> Author: Chris Wedgwood <[email protected]>
> Date: Mon May 15 09:43:55 2006 -0700
> [PATCH] VIA quirk fixup, additional PCI IDs
>
> BUT the latest stable and tested patch is the commit 09d6029f43ebbe7307854abdae204c25d711ff94
> PCI: VIA IRQ quirk behaviour change, which in my opinion that should go in.
Commit 09d6029f43ebbe7307854abdae204c25d711ff94 is what Alan wasn't
happy with, and -mm contains Alan's solution...
> Thanks,
> S?rgio M.B.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Mon, 2006-12-11 at 13:41 +0100, Adrian Bunk wrote:
> On Mon, Dec 11, 2006 at 01:42:48AM +0000, Sergio Monteiro Basto wrote:
> > On Sun, 2006-12-10 at 17:00 +0100, Adrian Bunk wrote:
> > > +DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_ANY_ID,
> > > quirk_via_irq);
> >
> > This is back to state of kernel 2.6.16 final (without .x)
> >
> > In kernel 2.6.17 final we got
> > (http://lkml.org/lkml/2006/4/19/16)
> > commit 75cf7456dd87335f574dcd53c4ae616a2ad71a11
> > Author: Chris Wedgwood <[email protected]>
> > Date: Tue Apr 18 23:57:09 2006 -0700
> > Signed-off-by: Chris Wedgwood <[email protected]>
> > Acked-by: Jeff Garzik <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
> > and
> > commit a7b862f663d81858531dfccc0537bc9d8a2a4121
> > Author: Chris Wedgwood <[email protected]>
> > Date: Mon May 15 09:43:55 2006 -0700
> > [PATCH] VIA quirk fixup, additional PCI IDs
> >
> > BUT the latest stable and tested patch is the commit 09d6029f43ebbe7307854abdae204c25d711ff94
> > PCI: VIA IRQ quirk behaviour change, which in my opinion that should go in.
>
> Commit 09d6029f43ebbe7307854abdae204c25d711ff94 is what Alan wasn't
> happy with, and -mm contains Alan's solution...
No, Alan's solution was a post solution , which still on -mm, I think .
Thanks,
>
> > Thanks,
> > Sérgio M.B.
>
> cu
> Adrian
>
On Sun, Dec 10, 2006 at 05:23:59PM -0800, Linus Torvalds wrote:
>
>
> On Mon, 11 Dec 2006, Adrian Bunk wrote:
> >
> > If life was that easy... ;-)
>
> No. Life _is_ that easy.
>
> If the 2.6.16 stable tree took a patch that was questionable, and we don't
> know what the right answer to it is from the _regular_ tree, than the
> patch violated the stable tree rules in the first place and should just be
> reverted.
>
> Once people know what the right answer is (and by "know", I mean: "not
> guess") from the regular tree having been tested with it, and people
> understanding the problem, then it can be re-instated.
>
> But if you're just guessing, and people don't _know_ the right answer,
> then just revert the whole questionable area. The patch shouldn't have
> been there in the first place.
>
> It really _is_ that simple.
>
> Either it's a stable tree or it isn't.
The non-easy part is that the patch that turned out as being
questionable was merged back in May, and that it actually fixed issues
for some people...
Unless you can lend me a time machine for telling Greg and Chris Wr.
that they mustn't merge this patch for 2.6.16.17, there doesn't seem to
be any regression free solution available at the moment.
> Linus
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Mon, Dec 11, 2006 at 12:48:10PM +0000, Sergio Monteiro Basto wrote:
> On Mon, 2006-12-11 at 13:41 +0100, Adrian Bunk wrote:
> > On Mon, Dec 11, 2006 at 01:42:48AM +0000, Sergio Monteiro Basto wrote:
> > > On Sun, 2006-12-10 at 17:00 +0100, Adrian Bunk wrote:
> > > > +DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_ANY_ID,
> > > > quirk_via_irq);
> > >
> > > This is back to state of kernel 2.6.16 final (without .x)
> > >
> > > In kernel 2.6.17 final we got
> > > (http://lkml.org/lkml/2006/4/19/16)
> > > commit 75cf7456dd87335f574dcd53c4ae616a2ad71a11
> > > Author: Chris Wedgwood <[email protected]>
> > > Date: Tue Apr 18 23:57:09 2006 -0700
> > > Signed-off-by: Chris Wedgwood <[email protected]>
> > > Acked-by: Jeff Garzik <[email protected]>
> > > Signed-off-by: Greg Kroah-Hartman <[email protected]>
> > > and
> > > commit a7b862f663d81858531dfccc0537bc9d8a2a4121
> > > Author: Chris Wedgwood <[email protected]>
> > > Date: Mon May 15 09:43:55 2006 -0700
> > > [PATCH] VIA quirk fixup, additional PCI IDs
> > >
> > > BUT the latest stable and tested patch is the commit 09d6029f43ebbe7307854abdae204c25d711ff94
> > > PCI: VIA IRQ quirk behaviour change, which in my opinion that should go in.
> >
> > Commit 09d6029f43ebbe7307854abdae204c25d711ff94 is what Alan wasn't
> > happy with, and -mm contains Alan's solution...
>
> No, Alan's solution was a post solution , which still on -mm, I think .
Look at the patch in -mm, it contains essentially the next rewrite of
this quirk...
> Thanks,
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Mon, 2006-12-11 at 00:47 +0100, Adrian Bunk wrote:
> So we have the following situation:
> - 2.6.16 - 2.6.16.16 : problems for Chris
> (and possibly many other people)
> - 2.6.16.17 - 2.6.16.35 : problems for many other people
> (I remember 4-5 bug reports in the kernel
> Bugzilla alone)
>
> The fix in 2.6.19 was considered suboptimal, and Alan's patch for
> fixing
> this whole issue more properly is currently not even in your tree.
Right,
Those 4-5 bug reports should test Alan's patch.
All the problem is detected the correct devices that should be quirked.
In 2.6.16, all ( PCI_VENDOR_ID_VIA, PCI_ANY_ID), in 2.6.16.17 just some.
Still questionable if this quirks is for on-board VIA when interrupts
are in PIC mode, or for all interrupts modes (historically before the
patch to be for IO-APIC and PIC mode, was just for PIC mode, but in that
time IO-APIC wasn't common on PC) .
So with Alan's patch the question is:if a device need to be quirked and
don't.
Those 4-5 reports will answer the question, they needs VIA quirks and we
want know is the patch do the right job.
My laptop that need the quirks and I can test it is not available right
now and I am too busy to test on it, sorry.
Thanks,
--
S?rgio M.B.