-----Original Message-----
From: One Thousand Gnomes <gnomes@xxxxxxxxxxxxxxxxxxx>
To: Andy Falanga (afalanga) <afalanga@xxxxxxxxxx>
Subject: Re: Please help me to understand the interaction of the various
ATA drivers
Date: Thu, 30 Apr 2015 11:43:06 +0100
On Wed, 29 Apr 2015 21:38:41 +0000
"Andy Falanga (afalanga)" <afalanga@xxxxxxxxxx> wrote:
>> Jeff,
>>
>> I don't know if you're still the maintainer of these drivers but you're
>> listed as the original author of the code in the 2.6 kernel which I'm
> Think Jeff is mostly off doing wonderous things with Bitcoin.
I'm wonderfully out of touch. Ha, I had to look up Bitcoin.
>> My question for you is simply, how are these various drivers supposed to
>> work together? On the VM which I'm doing my development, I see the
>> following from lsmod:
>>
>> # lsmod
>> ...
>> ahci 41208 2
>> pata_acpi 3701 0
>> ata_generic 3837 0
>> ata_piix 24409 1
> ata_generic is a bus mastering driver for PCI IDE class devices. In your
> case its been loaded for some reason but is not being used
> pata_acpi is a driver for ACPI described generic interfaces, and again is
> not being used
I had figured out that pata_acpi was for IDE devices but I hadn't figured
that ata_generic was. Thanks. Yes, my VM placed a CD drive on the PATA
interface. As you know, my application needn't worry about this one.
> ata_piix is a driver specifically for Intel PIIX/ICH interfaces in legacy
> mode and does seem to be getting used, so presumably your virtual machine
> has at least one legacy mode PIIX or ICH emulated on it
I can ignore this one as well it would seem.
> ahci is a driver for controllers that are AHCI class, or match a few
> identifiers for AHCI controllers not declaring themselves AHCI class (eg
> those that try and hide from Windows AHCI drivers so proprietary raid
> products can be used with them on Windows)
This is the one I was hoping I could tap into. That is, I was hoping to
write a high-level driver, exposing a device node, which I could just pass
requests to ahci.ko. Sounds like this may be more trouble that it's worth
given that you're suggesting I modify it to ignore the hardware I'd like
to control and write a simple driver to so. The one drawback is that my
driver really needs to work with all AHCI devices. This would mean I either
remove ahci or hamstring it to ignore all AHCI hardware.
> So I think you'd need to
>
> a) modify ahci to ignore your specific device in its probe method
> b) write a simple driver so you can poke the ports and do any needed DMA
Thanks for the suggestions. This gives me something to go on.
Andy
��.n��������+%������w��{.n�����{��'^�)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
