> On 2019-12-11 19:22, Avri Altman wrote: > >> > >> > >> On 2019-12-11 18:37, Avri Altman wrote: > >> >> > >> >> In ufshcd_remove(), after SCSI host is removed, put it once so > >> >> that its resources can be released. > >> >> > >> >> Signed-off-by: Can Guo <cang@xxxxxxxxxxxxxx> > >> > > >> > This is not really part of this patchset, is it? > >> > > >> > >> Hi Avri, > >> > >> I put this change in the same patchset due to #1. The main patch has > >> dependency on it #2. Consider a scenario where platform driver is > >> also compiled as a module, say ufs_qcom.ko. > >> In this case, we have two modules, ufs-qcom.ko and ufs-bsg.ko. > >> If do insmod ufs-qcom.ko > >> then rmmod ufs-qcom.ko and do insmod ufs-qcom.ko again, without > >> this change, because scsi > >> host was not release, the new scsi host will have a different > >> host number, meaning > >> hba->host->host_no will be 1, but not 0. Now if do insmod > >> ufs-bsg.ko now, the ufs-bsg dev > >> created in /dev/bsg/ will be ufs-bsg1, but not ufs-bsg0. If keep > >> trying these operations, > >> the ufs-bsg device's name will be messed up. This change make > >> sure after ufs- qcom.ko is removed > >> and installed back, its hba->host->host_no stays 0, so that > >> ufs-bsg device name stays same. > > Looks like we needed to manage the ufs-bsg nodes using an IDA, instead > > of host_no? > > > > > > Marking one ufs-bsg dev with host_no still has its advantage. If we have more > than one hba host, we can find the right ufs-bsgX dev by reading the sg/sd/bsg > device's host->host_unique_id (through SCSI_IOCTL_GET_IDLUN for example). > But If ufs-bsg has its own ID, we will lost this "mapping". OK.
