linux-kernel - Re: No IDE drivers loaded for Toshiba Satellite 320 CDS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <480414E6.2090205@gmail.com>
Date:	Tue, 15 Apr 2008 11:37:26 +0900
From:	Tejun Heo <htejun@...il.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
CC:	Lennart Sorensen <lsorense@...lub.uwaterloo.ca>,
	Frans Pop <elendil@...net.nl>, linux-ide@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>
Subject: Re: No IDE drivers loaded for Toshiba Satellite 320 CDS

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?

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/