All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arthur Simchaev <Arthur.Simchaev@wdc.com>
To: Bart Van Assche <bvanassche@acm.org>,
	"James E . J . Bottomley" <jejb@linux.vnet.ibm.com>,
	"Martin K . Petersen" <martin.petersen@oracle.com>,
	"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Cc: "alim.akhtar@samsung.com" <alim.akhtar@samsung.com>,
	Bean Huo <beanhuo@micron.com>
Subject: RE: [PATCH v2] scsi: ufs: sysfs: Print string descriptors as raw data
Date: Thu, 8 Apr 2021 10:25:13 +0000	[thread overview]
Message-ID: <BY5PR04MB632750DA310BEBF92DB80908ED749@BY5PR04MB6327.namprd04.prod.outlook.com> (raw)
In-Reply-To: <9ade874b-b69e-615d-b101-2ecc664ba64d@acm.org>


> -----Original Message-----
> From: Bart Van Assche <bvanassche@acm.org>
> Sent: Wednesday, March 17, 2021 5:31 AM
> To: Arthur Simchaev <Arthur.Simchaev@wdc.com>; James E . J . Bottomley
> <jejb@linux.vnet.ibm.com>; Martin K . Petersen
> <martin.petersen@oracle.com>; linux-scsi@vger.kernel.org; linux-
> kernel@vger.kernel.org
> Cc: alim.akhtar@samsung.com; Bean Huo <beanhuo@micron.com>
> Subject: Re: [PATCH v2] scsi: ufs: sysfs: Print string descriptors as raw data
> 
> CAUTION: This email originated from outside of Western Digital. Do not click
> on links or open attachments unless you recognize the sender and know that
> the content is safe.
> 
> 
> On 2/15/21 9:40 AM, Arthur Simchaev wrote:
> > -#define UFS_STRING_DESCRIPTOR(_name, _pname)                         \
> > +#define UFS_STRING_DESCRIPTOR(_name, _pname, _is_ascii)              \
> >  static ssize_t _name##_show(struct device *dev,                              \
> >       struct device_attribute *attr, char *buf)                       \
> >  {                                                                    \
> > @@ -690,10 +690,18 @@ static ssize_t _name##_show(struct device *dev,
> \
> >       kfree(desc_buf);                                                \
> >       desc_buf = NULL;                                                \
> >       ret = ufshcd_read_string_desc(hba, index, &desc_buf,            \
> > -                                   SD_ASCII_STD);                    \
> > +                                   _is_ascii);                       \
> >       if (ret < 0)                                                    \
> >               goto out;                                               \
> > -     ret = sysfs_emit(buf, "%s\n", desc_buf);                        \
> > +     if (_is_ascii) {                                                \
> > +             ret = sysfs_emit(buf, "%s\n", desc_buf);                \
> > +     } else {                                                        \
> > +             int i;                                                  \
> > +                                                                     \
> > +             for (i = 0; i < desc_buf[0]; i++)                       \
> > +                     hex_byte_pack(buf + i * 2, desc_buf[i]);        \
> > +             ret = sysfs_emit(buf, "%s\n", buf);                     \
> > +     }                       \
> >  out:                                                                 \
> >       pm_runtime_put_sync(hba->dev);                                  \
> >       kfree(desc_buf);                                                \
> 
> Hex data needs to be parsed before it can be used by any software. Has
> it been considered to make the "raw" attributes binary attributes
> instead of hex-encoded binary? See also sysfs_create_bin_file().
> 
> Thanks,
> 
> Bart.

Hi Bart,
Thank you for your comments.

The typical use case that originate this issue, is of some flash vendor's field engineer reading the serial part number.
All other string descriptors are less of an issue.

The current Jedec spec allows the serial number may not be ascii convertible . For example:
 - ufshcd_read_string_desc(bool asci = false):  00 1d 00 20 00 95 00 20 00 ec 00 84 00 5b 00 14
 - ufshcd_read_string_desc(bool asci = true):  "  ]  "

Therefore, upon reading the "raw" serial number, the user can verify the data integrity.

How about just applying this change to the serial number sysfs entry, and drop all others?

Regards
Arthur

      reply	other threads:[~2021-04-08 10:26 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-15 17:40 [PATCH v2] scsi: ufs: sysfs: Print string descriptors as raw data Arthur Simchaev
2021-03-16 11:27 ` Arthur Simchaev
2021-03-17  2:59   ` Martin K. Petersen
2021-03-17  3:31 ` Bart Van Assche
2021-04-08 10:25   ` Arthur Simchaev [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=BY5PR04MB632750DA310BEBF92DB80908ED749@BY5PR04MB6327.namprd04.prod.outlook.com \
    --to=arthur.simchaev@wdc.com \
    --cc=alim.akhtar@samsung.com \
    --cc=beanhuo@micron.com \
    --cc=bvanassche@acm.org \
    --cc=jejb@linux.vnet.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.