| Message ID | 20200512063318.13825-1-yanaijie@huawei.com (mailing list archive) |
|---|---|
| State | Mainlined |
| Commit | 55ce24b3bfd75f76696a00f2666caaf806eebea2 |
| Headers | show |
| Series | scsi: hisi_sas: display correct proc_name in sysfs | expand |
On 12/05/2020 07:33, Jason Yan wrote: > The 'proc_name' entry in sysfs for hisi_sas is 'null' now becuase it is > not initialized in scsi_host_template. It looks like: > > [root@localhost ~]# cat /sys/class/scsi_host/host2/proc_name > (null) > hmmm.. it would be good to tell us what this buys us, apart from the proc_name file. I mean, if we had the sht show_info method implemented, then it could be useful (which is even marked as obsolete now). Thanks, John > While the other driver's entry looks like: > > linux-vnMQMU:~ # cat /sys/class/scsi_host/host0/proc_name > megaraid_sas > > Cc: John Garry <john.garry@huawei.com> > Cc: Xiang Chen <chenxiang66@hisilicon.com> > Signed-off-by: Jason Yan <yanaijie@huawei.com> > --- > drivers/scsi/hisi_sas/hisi_sas_v1_hw.c | 1 + > drivers/scsi/hisi_sas/hisi_sas_v2_hw.c | 1 + > drivers/scsi/hisi_sas/hisi_sas_v3_hw.c | 1 + > 3 files changed, 3 insertions(+) > > diff --git a/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c b/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c > index fa25766502a2..c205bff20943 100644 > --- a/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c > +++ b/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c > @@ -1757,6 +1757,7 @@ static struct device_attribute *host_attrs_v1_hw[] = { > > static struct scsi_host_template sht_v1_hw = { > .name = DRV_NAME, > + .proc_name = DRV_NAME, > .module = THIS_MODULE, > .queuecommand = sas_queuecommand, > .target_alloc = sas_target_alloc, > diff --git a/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c b/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c > index e05faf315dcd..c725cffe141e 100644 > --- a/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c > +++ b/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c > @@ -3533,6 +3533,7 @@ static struct device_attribute *host_attrs_v2_hw[] = { > > static struct scsi_host_template sht_v2_hw = { > .name = DRV_NAME, > + .proc_name = DRV_NAME, > .module = THIS_MODULE, > .queuecommand = sas_queuecommand, > .target_alloc = sas_target_alloc, > diff --git a/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c b/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c > index 374885aa8d77..59b1421607dd 100644 > --- a/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c > +++ b/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c > @@ -3071,6 +3071,7 @@ static int debugfs_set_bist_v3_hw(struct hisi_hba *hisi_hba, bool enable) > > static struct scsi_host_template sht_v3_hw = { > .name = DRV_NAME, > + .proc_name = DRV_NAME, > .module = THIS_MODULE, > .queuecommand = sas_queuecommand, > .target_alloc = sas_target_alloc, >
在 2020/5/12 16:23, John Garry 写道: > On 12/05/2020 07:33, Jason Yan wrote: >> The 'proc_name' entry in sysfs for hisi_sas is 'null' now becuase it is >> not initialized in scsi_host_template. It looks like: >> >> [root@localhost ~]# cat /sys/class/scsi_host/host2/proc_name >> (null) >> > > hmmm.. it would be good to tell us what this buys us, apart from the > proc_name file. > When there is more than one storage cards(or controllers) in the system, I'm tring to find out which host is belong to which card. And then I found this in scsi_host in sysfs but the output is '(null)' which is odd. > I mean, if we had the sht show_info method implemented, then it could be > useful (which is even marked as obsolete now). > I found this is interesting while in the sysfs filesystem we have a procfs stuff in it. I was planned to rename this entry to 'name' and use the struct member 'name' directly in struct scsi_host_template. But this may break userspace applications. > Thanks, > John > >> While the other driver's entry looks like: >> >> linux-vnMQMU:~ # cat /sys/class/scsi_host/host0/proc_name >> megaraid_sas >> >> Cc: John Garry <john.garry@huawei.com> >> Cc: Xiang Chen <chenxiang66@hisilicon.com> >> Signed-off-by: Jason Yan <yanaijie@huawei.com> >> --- >> drivers/scsi/hisi_sas/hisi_sas_v1_hw.c | 1 + >> drivers/scsi/hisi_sas/hisi_sas_v2_hw.c | 1 + >> drivers/scsi/hisi_sas/hisi_sas_v3_hw.c | 1 + >> 3 files changed, 3 insertions(+) >> >> diff --git a/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c >> b/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c >> index fa25766502a2..c205bff20943 100644 >> --- a/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c >> +++ b/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c >> @@ -1757,6 +1757,7 @@ static struct device_attribute >> *host_attrs_v1_hw[] = { >> static struct scsi_host_template sht_v1_hw = { >> .name = DRV_NAME, >> + .proc_name = DRV_NAME, >> .module = THIS_MODULE, >> .queuecommand = sas_queuecommand, >> .target_alloc = sas_target_alloc, >> diff --git a/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c >> b/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c >> index e05faf315dcd..c725cffe141e 100644 >> --- a/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c >> +++ b/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c >> @@ -3533,6 +3533,7 @@ static struct device_attribute >> *host_attrs_v2_hw[] = { >> static struct scsi_host_template sht_v2_hw = { >> .name = DRV_NAME, >> + .proc_name = DRV_NAME, >> .module = THIS_MODULE, >> .queuecommand = sas_queuecommand, >> .target_alloc = sas_target_alloc, >> diff --git a/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c >> b/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c >> index 374885aa8d77..59b1421607dd 100644 >> --- a/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c >> +++ b/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c >> @@ -3071,6 +3071,7 @@ static int debugfs_set_bist_v3_hw(struct >> hisi_hba *hisi_hba, bool enable) >> static struct scsi_host_template sht_v3_hw = { >> .name = DRV_NAME, >> + .proc_name = DRV_NAME, >> .module = THIS_MODULE, >> .queuecommand = sas_queuecommand, >> .target_alloc = sas_target_alloc, >> > > > .
On 12/05/2020 10:35, Jason Yan wrote: > > > 在 2020/5/12 16:23, John Garry 写道: >> On 12/05/2020 07:33, Jason Yan wrote: >>> The 'proc_name' entry in sysfs for hisi_sas is 'null' now becuase it is >>> not initialized in scsi_host_template. It looks like: >>> >>> [root@localhost ~]# cat /sys/class/scsi_host/host2/proc_name >>> (null) >>> >> >> hmmm.. it would be good to tell us what this buys us, apart from the >> proc_name file. >> > > When there is more than one storage cards(or controllers) in the system, > I'm tring to find out which host is belong to which card. And then I > found this in scsi_host in sysfs but the output is '(null)' which is odd. "dmesg | grep host" would give this info, like: root@(none)$ dmesg | grep host0 [ 8.877245] scsi host0: hisi_sas_v2_hw > >> I mean, if we had the sht show_info method implemented, then it could >> be useful (which is even marked as obsolete now). >> > > I found this is interesting while in the sysfs filesystem we have a > procfs stuff in it. It's only the name of the procfs entry, if it exists. And, since .show_info is obsolete, I don't see why .proc_name is not also obsolete. > I was planned to rename this entry to 'name' and use > the struct member 'name' directly in struct scsi_host_template. But this > may break userspace applications. > Thanks, John
在 2020/5/12 18:00, John Garry 写道: > On 12/05/2020 10:35, Jason Yan wrote: >> >> >> 在 2020/5/12 16:23, John Garry 写道: >>> On 12/05/2020 07:33, Jason Yan wrote: >>>> The 'proc_name' entry in sysfs for hisi_sas is 'null' now becuase it is >>>> not initialized in scsi_host_template. It looks like: >>>> >>>> [root@localhost ~]# cat /sys/class/scsi_host/host2/proc_name >>>> (null) >>>> >>> >>> hmmm.. it would be good to tell us what this buys us, apart from the >>> proc_name file. >>> >> >> When there is more than one storage cards(or controllers) in the >> system, I'm tring to find out which host is belong to which card. And >> then I found this in scsi_host in sysfs but the output is '(null)' >> which is odd. > > "dmesg | grep host" would give this info, like: > > root@(none)$ dmesg | grep host0 > [ 8.877245] scsi host0: hisi_sas_v2_hw > NO, if long time after the system boot, dmesg cannot get this infomation. It is flushed by other logs. >> >>> I mean, if we had the sht show_info method implemented, then it could >>> be useful (which is even marked as obsolete now). >>> >> >> I found this is interesting while in the sysfs filesystem we have a >> procfs stuff in it. > > It's only the name of the procfs entry, if it exists. > > And, since .show_info is obsolete, I don't see why .proc_name is not > also obsolete. > >> I was planned to rename this entry to 'name' and use the struct member >> 'name' directly in struct scsi_host_template. But this may break >> userspace applications. >> > > Thanks, > John > > .
On 12/05/2020 11:30, Jason Yan wrote: > > > 在 2020/5/12 18:00, John Garry 写道: >> On 12/05/2020 10:35, Jason Yan wrote: >>> >>> >>> 在 2020/5/12 16:23, John Garry 写道: >>>> On 12/05/2020 07:33, Jason Yan wrote: >>>>> The 'proc_name' entry in sysfs for hisi_sas is 'null' now becuase >>>>> it is >>>>> not initialized in scsi_host_template. It looks like: >>>>> >>>>> [root@localhost ~]# cat /sys/class/scsi_host/host2/proc_name >>>>> (null) >>>>> >>>> >>>> hmmm.. it would be good to tell us what this buys us, apart from the >>>> proc_name file. >>>> >>> >>> When there is more than one storage cards(or controllers) in the >>> system, I'm tring to find out which host is belong to which card. And >>> then I found this in scsi_host in sysfs but the output is '(null)' >>> which is odd. >> >> "dmesg | grep host" would give this info, like: >> >> root@(none)$ dmesg | grep host0 >> [ 8.877245] scsi host0: hisi_sas_v2_hw >> > > NO, if long time after the system boot, dmesg cannot get this > infomation. It is flushed by other logs. ok, so I don't see any other way to currently do this, even though using proc_name is a bit suspect, so: Acked-by: John Garry <john.garry@huawei.com> And the $subject is not right. It should be simply "display proc_name in sysfs". Thanks, John
在 2020/5/12 19:07, John Garry 写道: > On 12/05/2020 11:30, Jason Yan wrote: >> >> >> 在 2020/5/12 18:00, John Garry 写道: >>> On 12/05/2020 10:35, Jason Yan wrote: >>>> >>>> >>>> 在 2020/5/12 16:23, John Garry 写道: >>>>> On 12/05/2020 07:33, Jason Yan wrote: >>>>>> The 'proc_name' entry in sysfs for hisi_sas is 'null' now becuase >>>>>> it is >>>>>> not initialized in scsi_host_template. It looks like: >>>>>> >>>>>> [root@localhost ~]# cat /sys/class/scsi_host/host2/proc_name >>>>>> (null) >>>>>> >>>>> >>>>> hmmm.. it would be good to tell us what this buys us, apart from >>>>> the proc_name file. >>>>> >>>> >>>> When there is more than one storage cards(or controllers) in the >>>> system, I'm tring to find out which host is belong to which card. >>>> And then I found this in scsi_host in sysfs but the output is >>>> '(null)' which is odd. >>> >>> "dmesg | grep host" would give this info, like: >>> >>> root@(none)$ dmesg | grep host0 >>> [ 8.877245] scsi host0: hisi_sas_v2_hw >>> >> >> NO, if long time after the system boot, dmesg cannot get this >> infomation. It is flushed by other logs. > > > ok, so I don't see any other way to currently do this, even though using > proc_name is a bit suspect, so: > > Acked-by: John Garry <john.garry@huawei.com> > > And the $subject is not right. It should be simply "display proc_name in > sysfs". > Thanks, will send v2 with right $subject. Jason > Thanks, > John > > .
diff --git a/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c b/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c index fa25766502a2..c205bff20943 100644 --- a/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c +++ b/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c @@ -1757,6 +1757,7 @@ static struct device_attribute *host_attrs_v1_hw[] = { static struct scsi_host_template sht_v1_hw = { .name = DRV_NAME, + .proc_name = DRV_NAME, .module = THIS_MODULE, .queuecommand = sas_queuecommand, .target_alloc = sas_target_alloc, diff --git a/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c b/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c index e05faf315dcd..c725cffe141e 100644 --- a/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c +++ b/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c @@ -3533,6 +3533,7 @@ static struct device_attribute *host_attrs_v2_hw[] = { static struct scsi_host_template sht_v2_hw = { .name = DRV_NAME, + .proc_name = DRV_NAME, .module = THIS_MODULE, .queuecommand = sas_queuecommand, .target_alloc = sas_target_alloc, diff --git a/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c b/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c index 374885aa8d77..59b1421607dd 100644 --- a/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c +++ b/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c @@ -3071,6 +3071,7 @@ static int debugfs_set_bist_v3_hw(struct hisi_hba *hisi_hba, bool enable) static struct scsi_host_template sht_v3_hw = { .name = DRV_NAME, + .proc_name = DRV_NAME, .module = THIS_MODULE, .queuecommand = sas_queuecommand, .target_alloc = sas_target_alloc,
The 'proc_name' entry in sysfs for hisi_sas is 'null' now becuase it is not initialized in scsi_host_template. It looks like: [root@localhost ~]# cat /sys/class/scsi_host/host2/proc_name (null) While the other driver's entry looks like: linux-vnMQMU:~ # cat /sys/class/scsi_host/host0/proc_name megaraid_sas Cc: John Garry <john.garry@huawei.com> Cc: Xiang Chen <chenxiang66@hisilicon.com> Signed-off-by: Jason Yan <yanaijie@huawei.com> --- drivers/scsi/hisi_sas/hisi_sas_v1_hw.c | 1 + drivers/scsi/hisi_sas/hisi_sas_v2_hw.c | 1 + drivers/scsi/hisi_sas/hisi_sas_v3_hw.c | 1 + 3 files changed, 3 insertions(+)