Mikael Pettersson wrote: > > Actually, this is common to many SATA controllers. Lots of them raise > > PHY event or hotplug interrupt during COMRESET and they all plug PHY > > events from ->freeze. > > Hmm, no I didn't know that. It's still undocumented, but perhaps > shouldn't be called a "quirk" if it's as common as you say. Yeap, it's common behavior. "quirk" would be a bit unfair to promise. :-) > > > Although SATA hotplug status and control is per-port, it resides in > > > a single register shared by all ports. Therefore accesses to it must > > > be serialised: the controller's host->lock is used for that. The > > > interrupt handler is also adjusted so its hotplug register accesses > > > are inside the region protected by host->lock. > > > > Hmmm... This is supposed to be handled by setting ap->lock appropriately > > and ap->lock already is initialized to &host->lock, so sticking with > > ap->lock is the right thing to do. > > I'll check this. The code relies on the lock being shared by all ports, > so at a minimum it will need a comment stating that requirement. That's the default assumption all other LLDs depend on. I agree it needs documentation. > > ->freeze() is called with ap->lock held, trying to lock host->lock > > inside pdc_sata_enable/disable_hotplug() will result in deadlock. Have > > you tested w/ SMP configuration or spinlock debugging turned on? > > No, I'll do that and fix whatever damage occurs. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
