Quoting Evan Green (2019-01-11 15:01:21) > > Because the UFS PHY reset bit is now toggled in the PHY, rather > than in ufs-qcom, this also percolated to all other PHYs using > ufs-qcom, which from what I can see is just 8996. > > There are a couple of tradeoffs in this series that I'd welcome feedback > on. First, it breaks compatibility with device trees that don't expose > this new reset controller. Making this work with older device trees > would be pretty ugly in the code, and given that the SDM845 UFS DT nodes > aren't accepted upstream yet, the breakage seemed worth it. I'm not as > sure about 8996. It may take some minor surgery to the reset framework, but it should be possible to register a reset lookup that can be used if nothing matches in DT. Right now the reset code looks to only want to use DT if it's there for the device requesting the reset. If there isn't a DT node for the device it will look in the global lookup list. That could be changed to fallback to the global lookup that uses device names (similar to clk framework) when the DT lookup fails. Then it's just a matter of registering the lookup for this reset with the handful of device names that need the non-DT way of finding the reset. Of course, that's another change and if breaking DT is simpler and acceptable then I would say go for the path of least resistance and don't try to modify reset framework for this.
