From: Alan on
> * Unlike Jmicron's case, this doesn't affect PCI bus scan. Actually, it
> does change class code but that's not as disruptive as Jmicron's case
> and as long as ahci ignores class code, it doesn't really matter.
> Driver can be chosen by changing loading order - this is both plus and
> minus.

The load order is basically undefined. You want AHCI so we should do
this early. That means either putting the same gunk all over the kernel
(drivers/ide, drivers/ata/*ati* drivers/ata/ahci) or in one place.

> * As Arjan pointed out, that unlock-modify-lock sequence should be done
> on resume too.

The infrastructure for this is already handled by the pci resume quirk
patches I sent.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Tejun Heo on
Alan wrote:
>> * Unlike Jmicron's case, this doesn't affect PCI bus scan. Actually, it
>> does change class code but that's not as disruptive as Jmicron's case
>> and as long as ahci ignores class code, it doesn't really matter.
>> Driver can be chosen by changing loading order - this is both plus and
>> minus.
>
> The load order is basically undefined. You want AHCI so we should do
> this early. That means either putting the same gunk all over the kernel
> (drivers/ide, drivers/ata/*ati* drivers/ata/ahci) or in one place.
>
>> * As Arjan pointed out, that unlock-modify-lock sequence should be done
>> on resume too.
>
> The infrastructure for this is already handled by the pci resume quirk
> patches I sent.

As long as resume is properly handled, no problem.

Thanks.

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