Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops


* Alan Cox <alan@xxxxxxxxxxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/