linux-kernel - Re: Loading both the pata_atiixp and the ahci driver causes problems

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: <45FCDE73.8090002@gmail.com>
Date:	Sun, 18 Mar 2007 15:38:43 +0900
From:	Tejun Heo <htejun@...il.com>
To:	Jon Masters <jonathan@...masters.org>
CC:	Chuck Ebbert <cebbert@...hat.com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Jeff Garzik <jgarzik@...ox.com>, linux-ide@...r.kernel.org,
	Conke Hu <conke.hu@...il.com>
Subject: Re: Loading both the pata_atiixp and the ahci driver causes problems

Hello, Jon.

Jon Masters wrote:
>> Dunno much about sb600 but ahci and pata_atiixp are probably using
>> separate IO regions && separate PCI functions.
> 
> Yeah. I actually thought about this whole issue a bit more recently -
> things like SATA/PATA interference when you've got a part that emulates
> legacy functionality so can appear as two different kinds of device -
> since I don't think my brain was really bothering to listen before.
> Words were going in, but it chose to ignore what was being said.

Dunno about the history.  Oh well, as long as the problem gets fixed.

> Only thing that comes to mind is in-driver logic/driver loading ordering
> hack combinations. At least if you've got loadable modules, you've got a
> fighting chance of fixing this kind of situation - built-in and you need
> to fight with whatever ordering exists in the array of init functions.

Not sure whether it applies to sb600 directly but libata policy for this
type of situation is..

* always prefer the native / more capable (read ahci) interface over
emulated SFF interface.

* program the device and update PCI header using a PCI quirk such that
module loading order or BIOS setting doesn't affect which driver gets
attached.  Note that if the controller needs to programmed in specific
way, the quirk also needs to be called during resume.  In this case, the
function for SFF interface can simply be disabled.

Please take a look at the JMB quirk in drivers/pci/quirks.c in the
latest libata-dev#upstream tree for details.

Thanks.

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