Re: 2.6.17-rc5-git1: regression: resume from suspend(RAM) fails: libata issue

[Jens Axboe <axboe@suse.de>]

On Sat, May 27 2006, Jeff Garzik wrote:
> Jens Axboe wrote:
> >There was no real discussion on this issue yet. I think we all agree
> >that the functionality of the patch (waiting for BSY clear on resume) is
> >the right thing to do. This posted patch moved SCSI stuff into ata_piix,
> >which isn't really very nice. Jeff wants to do it from the pci resume,
> >which just seems wrong to me since it's a device (disk) condition not a
> 
> Wrong.  It is a _bus_ condition, not a device condition.

See my other mail.

> >diff --git a/drivers/scsi/libata-core.c b/drivers/scsi/libata-core.c
> >index fa476e7..ae7fac1 100644
> >--- a/drivers/scsi/libata-core.c
> >+++ b/drivers/scsi/libata-core.c
> >@@ -4298,6 +4298,8 @@ int ata_device_resume(struct ata_port *a
> > {
> > 	if (ap->flags & ATA_FLAG_SUSPENDED) {
> > 		ap->flags &= ~ATA_FLAG_SUSPENDED;
> >+		if (ap->ops->port_resume)
> >+			ap->ops->port_resume(ap);
> 
> This is even MORE broken!
> 
> A port can have multiple devices hanging off of it.  With this 
> silliness, you will be calling ->port_resume() for both master and slave 
> devices...  or all devices attached to a port multiplier.

Worst case is the N-1 invocations basically being noops. Since
2.6.17-rc5 iirc doesn't even support port multipliers, I'd say this is a
pretty weak case.

What I care about is getting libata suspend/resume working, and so do a
lot of people. So far you've done nothing but whine at the posted
patches from the beginning and absolutely zero work on helping us get
there in _your_ driver/sub system. If you think your posted patch is the
best solution, by all means just put in there. Just make sure that we at
least get _something_ in there that does for 2.6.17.

I'll pick this up again tomorrow and actually test the patches so at
least I can say that 2.6.17 will suspend/resume for me.

-- 
Jens Axboe