On Thu, 2018-08-09 at 16:22 +0000, Avri Altman wrote: > > -----Original Message----- > > From: Bart Van Assche > > Sent: Wednesday, August 08, 2018 7:58 PM > > To: h...@lst.de; Avri Altman ; linux-scsi@vger.kernel.org; > > jthumsh...@suse.de; h...@suse.com; martin.peter...@oracle.com; > > j...@linux.vnet.ibm.com > > Cc: Vinayak Holikatti ; Avi Shchislowski ; Alex Lemberg ; Stanislav > > Nijnikov ; > > subha...@codeaurora.org > > Subject: Re: [PATCH v2 1/8] scsi: Add ufs transport class > > > > On Sun, 2018-08-05 at 14:39 +0300, Avri Altman wrote: > > > A “ufs-port” is purely a software object. Evidently, the function > > > template takes no port as an argument, as the driver has no concept > > > of "port". We only need it as a hanging point in the bsg device tree, > > > so maybe a more appropriate term would be: "ufs-bsg-dev-node". > > > > > > The ufs-port has a pretty lean structure. This is because we are > > > using upiu transactions that contains the outmost detailed info, > > > so we don't really need complex constructs to support it. > > > > > > The transport will keep track of its ufs-ports via its scsi host. > > > > Since no port concept has been defined in the UFS standard, can the port > > concept be left out? Have you considered to attach the bsg queue directly > > to the UFS SCSI host? There are two struct device instances in each > > Scsi_Host > > structure, namely shost_gendev and shost_dev. I think the former > > corresponds > > to /sys/bus/scsi/devices/host<n> and the latter corresponds to > > /sys/class/scsi_host/host<n>. The bsg queue probably can be attached to the > > latter. Several SCSI drivers already add additional sysfs attributes to the > > /sys/class/scsi_host/host<n>. > > Yeah - so today we are using shost_gendev, and the newly created classes > points to /sys/devices/... : > > htc_ocnwhl:/sys/class/ufs_host # ls -la > lrwxrwxrwx 1 root root 0 2018-06-17 13:15 host0 -> > ../../devices/soc/1da4000.ufshc/host0/ufs_host/host0 > > htc_ocnwhl:/sys/class/ufs_ports # ls -la > lrwxrwxrwx 1 root root 0 2018-06-17 13:05 ufs-port-0:1 -> > ../../devices/soc/1da4000.ufshc/host0/ufs-port-0:1/ufs_ports/ufs-port-0:0 > > and under /dev/ we get: > htc_ocnwhl:/dev # ls -la | grep ufs > crw------- 1 root root 246, 3 1970-02-26 03:12 ufs-port-0:0 > > We didn't add any sysfs attribute to those classes, and I don't expect any to > be added, > as I tried to explain in the commit: > "Those classes are left empty for now, as ufs-sysfs already contains > an abundant amount of attributes." > > Practically, this infrastructure provides the bsg device files /dev/<xxx-id>. > > Anyway, if you think it's better, I will try to switch it as you suggested.
My concern is that no port concept is defined in the UFS standard and hence that users will be confused if they see a UFS port object in sysfs. > Can you please refer me to those scsi drivers that you mentioned? The following command will yield plenty of examples: git grep -nHE 'device_(create|remove)_file|shost_attrs' drivers/scsi drivers/infiniband Thanks, Bart.
