On 05/04/2015 05:15 PM, James Bottomley wrote: > On Mon, 2015-05-04 at 23:46 +0900, Akinobu Mita wrote: >> While accessing a scsi_device, the use count of the underlying LLDD module >> is incremented. The module reference is retrieved through .module field of >> struct scsi_host_template. >> >> This mapping between scsi_device and underlying LLDD module works well >> except ufs, unusual usb storage drivers, and sub drivers for esp_scsi. >> These drivers consist with core driver and actual LLDDs, and >> scsi_host_template is defined in the core driver. So the actual LLDDs can >> be unloaded even if the scsi_device is being accessed. >> >> This patch series first adds ability to adjust module reference for >> scsi host by LLDDs and then fixes actual LLDDs by adjusting module >> reference after scsi host allocation. > > This series is still missing an ack from ufs. However, as we're on > series 6, final warning: object now or I'll take it without ufs ack. > > However, it does also strike me that these three drivers have problems > because they're using the wrong initialisation pattern: the template is > supposed to be in the bus connector for compound drivers not in the > core. To see how the pattern is supposed to work look at the 53c700 > series of drivers. They have a tiny template in the bus connector part > and then the function NCR_700_detect() fills in the rest. > > 53c700 is possibly not the best example because it fills in the template > for every host rather than once at module init time, but you get the > idea. how difficult would it be to convert these things to use the > correct pattern rather than hacking it in the mid layer? > Probably not _that_ difficult. I'll give esp_scsi a shot. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage hare@xxxxxxx +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
