Re: [PATCH v4] scsi: ufs: Make sysfs attributes writable

[Evan Green]

On Tue, Sep 25, 2018 at 6:46 PM Doug Anderson <dianders@xxxxxxxxxxxx> wrote:
>
> Martin,
>
> On Tue, Sep 25, 2018 at 6:08 PM Martin K. Petersen
> <martin.petersen@xxxxxxxxxx> wrote:
> >
> > Doug,
> >
> > > I came across this patch and Evan's other one and noticed that they
> > > haven't been applied though a batch of other SCSI patches for 4.20
> > > were applied about a week ago.  Martin: is there something about these
> > > patches that needs to change before they can land?
> >
> > I have simply been awaiting some sort of consensus on the various
> > competing approaches. Lots of patches posted with tiny incremental fixes
> > but very little discussion about the merits of one over the other.
>
> Ah, perfect information!  Thank you!  I was just confused because I
> didn't understand all the status and it just looked like silence here.
>
> Maybe someone on this thread can start a discussion with all the
> stakeholders (people who have been involved in competing patches or
> other tiny bits and pieces) and summarize their view of the current
> status?  Maybe that would help get the ball rolling again?
>

Ah, I did not realize that's what was being gated on.

These patches complement, rather than compete with, the other patches
out there. There are two components to completely provisioning a UFS
device: writing the configuration descriptors, and setting
attributes/flags. My original series [1] did contain support for the
provisioning portion, but I opted to leave that to Sayali's patch [2]
that uses configfs, rather than duplicate effort. Sayali's other patch
[3] does handle setting the reference clock frequency, which has some
overlap with this patch in that both set bRefClkFreq. But this patch
and the flag patch [4] are still needed for provisioning activity like
locking the descriptors down once they're set up, and enable other
device experimentation. In other words, they're independent.

There was also another independent fix [5] for devices that start in
sleep mode, which Linux currently can't handle. That patch got no
reviews, which is a shame, and I should probably resend as multiple
patches or at least with some additional information.

-Evan

[1] https://lkml.org/lkml/2018/5/29/969
[2] https://lkml.org/lkml/2018/9/14/293
[3] https://lkml.org/lkml/2018/9/14/292
[4] https://patchwork.kernel.org/patch/10570811/
[5] https://lkml.org/lkml/2018/8/10/669