2015-01-08 0:09 GMT+09:00 Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>: > On Wed, 7 Jan 2015, Christoph Hellwig wrote: > >> On Wed, Jan 07, 2015 at 11:02:59PM +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 some scsi drivers (ufs and unusual usb storage drivers). 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. >> >> Why don't ufs and usb-storage define the host templates in the sub drivers? >> That's what libata or the mpt fusion driver do. > > Originally the subdrivers were all part of usb-storage. When they were > split out into separate modules, there didn't seem to be any need to > copy the host template into each one. (Especially since some of the > method pointers in the host template refer to routines in usb-storage > itself, not in the subdrivers.) The fact that the .module member was > no longer adequate escaped our notice at the time. For ufs, the reason why a host template is shared by sub drivers is similar to usb-storage. Originally there was only a single pci driver for ufs. When platform driver for ufs was introduced, it was split into core driver (ufshcd) and sub drivers (ufshcd-pci and ufshcd-pltfrm). They require exactly the same host template. Is there any other preferable way to fix this problem? The first time I found this in ufs driver, I was trying to fix it by merging core and sub drivers into a single compound module. But I realized that usm-* drivers have the same problem, then I decided to propose what this patch series do instead. -- 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
