| Message ID | 20200117071923.7445-7-deepak.ukey@microchip.com (mailing list archive) |
|---|---|
| State | Changes Requested |
| Headers | show |
| Series | pm80xx : Updates for the driver version 0.1.39. | expand |
On Fri, Jan 17, 2020 at 8:10 AM Deepak Ukey <deepak.ukey@microchip.com> wrote: > > From: Viswas G <Viswas.G@microchip.com> > > Added sysfs attribute to show number of phys. > > Signed-off-by: Deepak Ukey <deepak.ukey@microchip.com> > Signed-off-by: Viswas G <Viswas.G@microchip.com> > Signed-off-by: Radha Ramachandran <radha@google.com> I agree with John Gary, the mgmt tool can get the info from /sys/class/sas_phy, no need to add an extra sysfs. I suggest dropping the patch. Thanks!
EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe On Fri, Jan 17, 2020 at 8:10 AM Deepak Ukey <deepak.ukey@microchip.com> wrote: > > From: Viswas G <Viswas.G@microchip.com> > > Added sysfs attribute to show number of phys. > > Signed-off-by: Deepak Ukey <deepak.ukey@microchip.com> > Signed-off-by: Viswas G <Viswas.G@microchip.com> > Signed-off-by: Radha Ramachandran <radha@google.com> I agree with John Gary, the mgmt tool can get the info from /sys/class/sas_phy, no need to add an extra sysfs. I suggest dropping the patch. > We have HBA application already in use by customer which uses this sysfs entry. So is it fine to keep this patch? Thanks!
On Mon, Jan 20, 2020 at 5:50 AM <Deepak.Ukey@microchip.com> wrote: > > > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe > > On Fri, Jan 17, 2020 at 8:10 AM Deepak Ukey <deepak.ukey@microchip.com> wrote: > > > > From: Viswas G <Viswas.G@microchip.com> > > > > Added sysfs attribute to show number of phys. > > > > Signed-off-by: Deepak Ukey <deepak.ukey@microchip.com> > > Signed-off-by: Viswas G <Viswas.G@microchip.com> > > Signed-off-by: Radha Ramachandran <radha@google.com> > I agree with John Gary, the mgmt tool can get the info from /sys/class/sas_phy, no need to add an extra sysfs. > > I suggest dropping the patch. > > We have HBA application already in use by customer which uses this sysfs entry. So is it fine to keep this patch? > Thanks! How much effort to convert the HBA application to use general sas_phy information? IMHO converting HBA application to use general interface is the right way to go. Thanks
diff --git a/drivers/scsi/pm8001/pm8001_ctl.c b/drivers/scsi/pm8001/pm8001_ctl.c index 69458b318a20..8091e78a04b0 100644 --- a/drivers/scsi/pm8001/pm8001_ctl.c +++ b/drivers/scsi/pm8001/pm8001_ctl.c @@ -89,6 +89,25 @@ static ssize_t controller_fatal_error_show(struct device *cdev, } static DEVICE_ATTR_RO(controller_fatal_error); +/** + * num_phys_show - Number of phys + * @cdev:pointer to embedded class device + * @buf:the buffer returned + * A sysfs 'read-only' shost attribute. + */ +static ssize_t num_phys_show(struct device *cdev, + struct device_attribute *attr, char *buf) +{ + int ret; + struct Scsi_Host *shost = class_to_shost(cdev); + struct sas_ha_struct *sha = SHOST_TO_SAS_HA(shost); + struct pm8001_hba_info *pm8001_ha = sha->lldd_ha; + + ret = sprintf(buf, "%d", pm8001_ha->chip->n_phy); + return ret; +} +static DEVICE_ATTR_RO(num_phys); + /** * pm8001_ctl_fw_version_show - firmware version * @cdev: pointer to embedded class device @@ -825,6 +844,7 @@ static DEVICE_ATTR(update_fw, S_IRUGO|S_IWUSR|S_IWGRP, struct device_attribute *pm8001_host_attrs[] = { &dev_attr_interface_rev, &dev_attr_controller_fatal_error, + &dev_attr_num_phys, &dev_attr_fw_version, &dev_attr_update_fw, &dev_attr_aap_log,