Re: No IDE drivers loaded for Toshiba Satellite 320 CDS

[Lennart Sorensen]

On Tue, Apr 15, 2008 at 11:37:26AM +0900, Tejun Heo wrote:
> Alan Cox wrote:
> >>If a driver supports a device with dual interfaces, then it better
> >>reserve both sets of ports to prevent the generic driver from trying to
> >>use them.
> >
> >That isn't the problem. The generic driver doesn't know if there is
> >another valid driver for the ports - how can it - and the other driver
> >may not be loaded first so cannot reserve the ports. If you load the
> >generic driver last then you should be fine, and the link order for IDE
> >and libata puts acpi, pci generic and legacy at the end for good reason.
> >
> >Libata pata_legacy has some smarts in this area but they are only good
> >for the common cases.
> 
> Always loading generic or ata_generic used to be safe.  It's still 
> pretty safe but not as much as before.  Nowadays, there are good number 
> of controllers which have dual interfaces.  Usually an ahci interface 
> and a legacy one but there are other controllers which also implement 
> dual interface.
> 
> Because PCI BARs usually contain IO regions for legacy interface in PCI 
> BAR 0-4, the native driver can work it out by claiming all PCI BARs on 
> attach, which I learned the hard way after seeing the generic driver 
> borking the native one on certain configurations.  The thing I'm worried 
> about is that there are a lot of vendors making this type of controllers 
> nowadays and a lot of BIOS implementations for each of them.  And of 
> course each BIOS implementation has its own many ways of configuring the 
> dual mode (or more thanks to fake RAIDs) controller.
> 
> I wouldn't be too surprised if one of those plethora of configurations 
> gets the compatible IO port and BAR configurations mismatched. 
> Especially when the controller is put into native mode.  It's entirely 
> possible to leave the compatible IO ports enabled while not setting the 
> PCI BARs accordingly.  Some of them might even think that's better to 
> prevent IDE drivers from attaching to it.
> 
> So, I don't really want to depend on that.  I don't know.  Do I sound 
> paranoid?

Yes.  After all you would quickly see a problem if you built a kernel
with all the IDE drivers built in, which some people do.  In that case
ide generic is always activated last and anything bad that would happen
with loading a module would happen built in too.

I think it is the wrong place to worry about problems.  If a native
driver takes control of a chip, it is that drivers responsibility to
reserve any relevant ports on that chip sufficiently to prevent another
driver from messing with it that doesn't know anything about that chip.
If the native driver doesn't load at all, then ide-generic ought to try
and drive the chip if it has legacy ports.

So my opinion is that making life easy to those machines with legacy ide
ports is a good thing, while trying to be overly paranoid about one
driver potentially hitting a bug in another driver is just silly.  Why
couldn't two native ide drivers potentially go looking for the same
ports too?  Are you sure no native driver uses the legacy IDE port
numbers to control a chip in native mode?  Finding bugs is good since
then they can be fixed.  Trying to prevent hitting bugs (which shouldn't
be there in the first place) doesn't seem useful.

-- 
Len Sorensen
--
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/