lkml.org 
[lkml]   [2018]   [Jun]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [PATCH 0/7] Enable UFS provisioning via Linux
Date


> -----Original Message-----
> From: linux-scsi-owner@vger.kernel.org <linux-scsi-owner@vger.kernel.org> On Behalf Of Evan Green
> Sent: Friday, June 1, 2018 5:44 PM
> To: Stanislav Nijnikov <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
> <Alex.Lemberg@wdc.com>; Avri Altman <Avri.Altman@wdc.com>
> Subject: Re: [PATCH 0/7] Enable UFS provisioning via Linux
>
> 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.

No additional logic will be required to attach write functionality to the
existing entries instead of new defined ones. It will reduce the patch
size significantly. And there will be no need for the unit selector
mechanism which I'm not sure will be accepted by the SCSI community.

>
> > - 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.

Agree. It doesn't have to be part of this patch set. It's just thoughts
about "quirky devices and future changes" :) that might require to
change several parameters simultaneously.

>
> > - 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

Regards
Stanislav
\
 
 \ /
  Last update: 2018-06-03 12:22    [W:0.432 / U:0.008 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site