Re: Workaround for some broken BIOSes that forgot to enableATAchannels [patch]

On Mon, Apr 14, 2003 at 03:14:53PM -0400, John Baldwin wrote:
> 
> On 14-Apr-2003 Soeren Schmidt wrote:
> > It seems Maxim Sobolev wrote:
> >> > > This is BIOS on my new vprMatrix 175B4 notebook (P4M-1.7GHz).
> >> > > Along with ATA, it "forgets" to enable ports on network card
> >> > > (fxp driver), I've already committed patch for it. Funny thing
> >> > > is that the problem doesn't exists on 4.7 - both ata and fxp
> >> > > work here OOB. This might be somehow related to ACPI, but
> >> > > forcefully disabling it in 5-CURRENT doesn't help.
> >> > 
> >> > I heard BIOSes, and now its just one :)
> >> > 
> >> > I'll wait and see if there is more of this, before committing code that
> >> > might be just a one off...
> >> 
> >> :(((
> >> 
> >> I am really wonder why ata driver is so strict in this area.
> >> Many other drivers don't rely on BIOS to do the right job and
> >> enable ports, memory space and busmastering explicitly. And
> >> this is the right thing (IMO), since most modern operating
> >> systems including FreeBSD don't give a shit to BIOS settings
> >> anyway. If device is probed and user didn't disable the driver
> >> explicitly, it should do everything to attach to device, no
> >> matter in which weird state the BIOS left it.
> > 
> > The current way of things are implemented because:
> > 1. Users wanted our driver to honor the BIOS setting an ATA channel on or off
> 
> This isn't always easy, esp. when we start supporting PNP OS = yes at
> some point.
> 
> > 2. If the BIOS doesn't enable the port, it most likely hasn't setup 
> >    interrupt routing etc as well..
> 
> When I get PCI interrupt routing working right on SMP I plan to always
> reroute PCI interrupts.  In the case of UP and an unrouted interrupt,
> we already route the interrupt properly anyways.
> 
> A note to Maxim: please use pci_enable_io() instead of messing with
> the config regs directly.

Already done.

-Maxim