On Tue, May 24, 2011 at 1:17 PM, Dan Williams <dan.j.williams@xxxxxxxxx> wrote: > During initial scan libsas drivers start their phys and notify libsas > with PORTE_BYTES_DMAED events as port links are established. This > notification in turn causes libsas to post DISCE_DISCOVER_DOMAIN events > to the queue. Calling scsi_flush_work() at the end of scan_finished > guarantees that all preceding PORTE_BYTES_DMAED events have been > registered in the queue, but it does not guarantee that the resulting > DISCE_DISCOVER_DOMAIN events have been processed because > flush_workqueue() explicitly avoids live-locking with incoming work. > > Introduce sas_flush_discovery() to guarantee that all initial discovery > events have completed. It is called after the driver determines all > initial PORTE_BYTES_DMAED events have had a chance to enter the queue. > This does not cover BCNs that are generated during expander bring up, > only the initial sas_discover_domain() event. I notice that scsi-misc picked up all the patches from the series, save this one. Oversight, or nak? Note that latest upstream still says the following for flush_workqueue(): * We sleep until all works which were queued on entry have been handled, * but we are not livelocked by new incoming ones. ...so isci will continue to open code this double flush. -- Dan -- 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
