Re: RFC, RFT: AHCI driver reorganization

Søren Schmidt wrote:
> This does massive changes to the way AHCI devices are treated, so it 
> will need testing on all the AHCI platforms currently supported to make 
> sure nothing breaks. The adding of PM learned me this is a critical part 
> to touch, ouch :)

Yes, I agree. I think 2 weeks is good time to test :)

> At any rate, fixing the suspend / resume problems should be dealt with 
> in a more generic manner, not just for AHCI, by splitting the work done 
> by the _chipinit and _allocate functions so that just the chipset 
> specifics can be restored on resume, not the allocations etc.

No, splitting was made before.. It targeted to be more conform to AHCI
spec. I think after vacation you will have much more time to review.
Currently I replaced bus_generic_suspend/bus_generic_resume to:

int
ata_pci_suspend(device_t dev)
{
     struct ata_pci_controller *ctlr = device_get_softc(dev);
     int error = 0;

     bus_generic_suspend(dev);
     if (ctlr->suspend)
         error = ctlr->suspend(dev);

     return error;
}
int
ata_pci_resume(device_t dev)
{
     struct ata_pci_controller *ctlr = device_get_softc(dev);
     int error = 0;

     if (ctlr->resume)
         error = ctlr->resume(dev);
     bus_generic_resume(dev);

     return error;
}

So, I think it's easy to implement ctlr->suspend/resume for each
specific controller..

> I'm in doubt as to what makes most sense todo, I'm spare time limitted 
> still, so progress here is slow, heck my WIP on NCQ support is still 
> just that and touches the same code parts in ACHI so they willl get even 
> more behind, oh well...
> 
> I'm starting to wonder if I should just let it go and leave ATA to its 
> own faith, and get on with other things...

What about merging some parts of your WIP (which may be published) to
perforce repository, it may take some time for you, but after that
some people can help to do some work with your review. ATA is a big
subsystem and it isn't easy to maintain it alone. I think..

-- 
WBR, Andrey V. Elsukov