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