* Alan Cox <[EMAIL PROTECTED]> wrote: > There is another reason we can't just do a dumb changeover - two > actually > > #1: Some drivers are using inb_p/outb_p in PCI cases which are going > #to cause PCI posting changes. Most are probably just wrong in the > #first place but they need hand checking
hm, any intelligent way to force PCI posting? I guess not. here's a list of candidate drivers (match the out*_p() pattern and do pci) ./char/epca.c ./char/sonypi.c ./scsi/megaraid.c ./ide/pci/serverworks.c ./ide/pci/cmd640.c ./input/mouse/pc110pad.c ./i2c/busses/i2c-amd756.c ./i2c/busses/i2c-ali15x3.c ./i2c/busses/i2c-ali1563.c ./i2c/busses/i2c-ali1535.c ./i2c/busses/i2c-viapro.c ./i2c/busses/i2c-nforce2.c ./i2c/busses/i2c-i801.c ./i2c/busses/i2c-piix4.c ./hwmon/vt8231.c ./hwmon/via686a.c ./hwmon/sis5595.c ./telephony/ixj.c ./net/irda/donauboe.c ./watchdog/pcwd_pci.c ./watchdog/wdt_pci.c > #2: We've got SMP cases that only 'work' because the odds of splitting > the outb and the following port 0x80 cycle, which locks the bus, are tiny. > > That is we've got > > CPU1 CPU2 > main path irq path > outb > outb > > inb 0x80 > inb 0x80 > > races in one or two spots. which seems to suggest we are better off not doing the port 0x80 trick at all. Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/