Re: Linux 2.4.19-ac2

Eric W. Biederman
2002-08-05T10:31:00Z

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