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

[Avri Altman]

> > >
> > > 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.
> 
Also, in this context there is the series in 
https://www.spinics.net/lists/linux-scsi/msg123479.html
which allows to send UPIUs via a bsg device.

It's not a provisioning series per-se like Evan's and Sayali's.
It covers the provisioning functionality,
But also allow to send task management UPIU, and UIC commands,
Which can be used for testing and validation.

Thanks,
Avri


> 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