Messages in this thread | | | Subject | Re: Linux 2.4.19-ac2 | From | (Eric W. Biederman) | Date | 05 Aug 2002 04:21:41 -0600 |
| |
Alan Cox <alan@lxorguk.ukuu.org.uk> writes:
> On Sun, 2002-08-04 at 20:39, Daniela Engert wrote: > > On 04 Aug 2002 21:27:19 +0100, Alan Cox wrote: > > > > > if((r9 & 0x0A) != 0x0A) /* Legacy only */ > > > /* Request programmability */ > > > pci_write_config_byte(dev, PCI_CLASS_PROG, r9|0x05); > > > > There is no guarantee that this will succeed. Quite some PCI IDE > > controller chips (f.e. ALi, SiS) may have config register 9 r/o locked > > by some other means. > > If its locked read only then that is fine. The read back will see the > old value not 0x05 bits set. In which case it'll leave it alone > > pci_write_config_byte(dev, PCI_CLASS_PROG, r9|0x05); > pci_read_config_byte(dev, PCI_CLASS_PROG, &r9); > > if((r9 & 0x05) == 0x05) /* Reprogrammable */ > return 1; > > /* Refused */ > return 0; > > I'm just trying to get this right so we can do a sensible quick fix for > 2.4.19. Its relatively easy to add pci_assign_device(dev) functionality > and make the IDE drivers do the right thing when they kick the devices > out of legacy mode. Thats the longer term right answer.
Why are we kicking IDE devices out of ``legacy'' mode?
Last I checked that was a very sensible mode for IDE devices to operate in. The IRQ and pio resources are where a lot of software expects them, and by using an isa-irq there are fewer shared interrupts.
Plus on the few motherboards I tried it on, the pci-irq line didn't even appear to be hooked up. In these cases I'm thinking of the on-board IDE controller.
Eric
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |