All of lore.kernel.org
 help / color / mirror / Atom feed
From: Evan Green <evgreen@chromium.org>
To: Stanislav.Nijnikov@wdc.com
Cc: Vinayak Holikatti <vinholikatti@gmail.com>,
	jejb@linux.vnet.ibm.com, martin.petersen@oracle.com,
	linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org,
	Gwendal Grignou <gwendal@chromium.org>,
	Alex.Lemberg@wdc.com, Avri.Altman@wdc.com
Subject: Re: [PATCH 0/7] Enable UFS provisioning via Linux
Date: Fri, 1 Jun 2018 07:44:08 -0700	[thread overview]
Message-ID: <CAE=gft4LoNiRtxgTA_ZPghZGEVOzu_GAwMgqhs-8NCYVgj_AVw@mail.gmail.com> (raw)
In-Reply-To: <MWHPR04MB11372C75BFC9416BAF5E81A19A630@MWHPR04MB1137.namprd04.prod.outlook.com>

Hi Stanislav. Thanks for taking a look. Responses below.

On Thu, May 31, 2018 at 3:04 AM Stanislav Nijnikov
<Stanislav.Nijnikov@wdc.com> wrote:
>
> Hi Evan,
> I have some generic notes:
> - Why to create new sysfs entries for the configuration descriptor fields if they are just duplication of fields in the device and unit descriptors? And the sysfs representation of the device and unit descriptors is existing already.

Well, UFS describes them as different descriptors. I worry that if I
add a bunch of clever logic to hide the config descriptor behind other
descriptors, there might be trouble later if 1) there is a quirky
device that doesn't reflect the values between descriptors quite the
same way or at the same time, or 2) if a later UFS spec adds more
configuration descriptor fields that don't exactly reflect into other
non-config descriptors, the cleverness will look awkward.

> - It would be nice to have some "packet" mode allowing to gather configuration changes and apply them at once, not one by one.

That's definitely doable. Do you think it's needed? I suppose if there
were a device that truly allowed you to do only a single write to the
config descriptor, then the commit style would be needed. The two
devices I've tested (Toshiba and Samsung) allow multiple writes to the
config descriptor, which makes me lean towards not needing the
batch-and-commit style, since if you get interrupted you can simply
try again. I'm happy to do either, though.

> - Why to put documentation update in the separate patches?
Well, in case some piece of this turned out to be controversial, I
wanted to allow for the option of taking these changes independently,
without the concern of missing the documentation. I'm happy to squash
all the documentation changes into one if that's preferred.

-Evan

  reply	other threads:[~2018-06-01 14:44 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-29 18:17 [PATCH 0/7] Enable UFS provisioning via Linux Evan Green
2018-05-29 18:17 ` [PATCH 1/7] scsi: ufs: Add Configuration Descriptor to sysfs Evan Green
2018-06-04  8:31   ` Bart Van Assche
2018-06-04 15:39     ` Evan Green
2018-05-29 18:17 ` [PATCH 2/7] scsi: ufs: Add config descriptor documentation Evan Green
2018-06-04  8:34   ` Bart Van Assche
2018-06-04 15:39     ` Evan Green
2018-05-29 18:17 ` [PATCH 3/7] scsi: ufs: Make sysfs attributes writable Evan Green
2018-06-04  8:33   ` Bart Van Assche
2018-06-04 15:39     ` Evan Green
2018-05-29 18:17 ` [PATCH 4/7] scsi: ufs: sysfs: Document attribute writability Evan Green
2018-06-04  8:35   ` Bart Van Assche
2018-06-04 15:39     ` Evan Green
2018-05-29 18:17 ` [PATCH 5/7] scsi: ufs: Refactor descriptor read for write Evan Green
2018-05-30 17:21   ` Evan Green
2018-06-04  8:40   ` Bart Van Assche
2018-06-04 15:40     ` Evan Green
2018-05-29 18:17 ` [PATCH 6/7] scsi: ufs: Enable writing config descriptor Evan Green
2018-06-04  8:46   ` Bart Van Assche
2018-05-29 18:17 ` [PATCH 7/7] scsi: ufs: Update config descriptor documentation Evan Green
2018-05-31 10:04 ` [PATCH 0/7] Enable UFS provisioning via Linux Stanislav Nijnikov
2018-06-01 14:44   ` Evan Green [this message]
2018-06-03 10:21     ` Stanislav Nijnikov
2018-06-04 14:59       ` Evan Green
2018-06-08 12:30         ` Adrian Hunter
2018-06-10  9:31           ` Stanislav Nijnikov
2018-06-12 19:42             ` Evan Green
2018-06-12 20:11               ` Bart Van Assche
2018-06-13 10:12               ` Stanislav Nijnikov
2018-06-15 21:19                 ` Evan Green
2018-06-04 11:11 ` Kyuho Choi
2018-06-04 15:03   ` Evan Green

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='CAE=gft4LoNiRtxgTA_ZPghZGEVOzu_GAwMgqhs-8NCYVgj_AVw@mail.gmail.com' \
    --to=evgreen@chromium.org \
    --cc=Alex.Lemberg@wdc.com \
    --cc=Avri.Altman@wdc.com \
    --cc=Stanislav.Nijnikov@wdc.com \
    --cc=gwendal@chromium.org \
    --cc=jejb@linux.vnet.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=vinholikatti@gmail.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.