> -----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.
Can you please refer me to those scsi drivers that you mentioned?
Thanks a lot,
Avri
>
> Thanks,
>
> Bart.
