On Fri, Aug 23, 2024 at 07:23:57AM -0700, Bart Van Assche wrote: > On 8/23/24 5:01 AM, Manivannan Sadhasivam wrote: > > Unfortunately you never mentioned which UFS controller this behavior applies to. > > Does your employer allow you to publish detailed information about > unreleased SoCs? > Certainly not! But in that case I will explicitly mention that the controller is used in an upcoming SoC or something like that. Otherwise, how can the community know whether you are sending the patch for an existing controller or a secret one? > > > - The workaround results in a simplification of the UFS driver core > > > code. More lines are removed from the UFS driver than added. > > > > This doesn't justify the modification of the UFS code driver for an errantic > > behavior of a UFS controller. > > Patch 2/2 deletes more code than it adds and hence helps to make the UFS > driver core easier to maintain. Adding yet another quirk would make the > UFS driver core more complicated and hence harder to maintain. > IMO nobody can make the UFS driver more complicated. It is complicated at its best :) But you are just applying the plaster in the core code for a quirky behavior of an unreleased SoC. IMO that is not something we would want. Imagine if other vendor also decides to do the same with the argument of removing more lines of code etc... we will end up with a situation where the core code doing something out of the spec for a buggy controller without any mentioning of the quirky behavior. So that will make the code more complex to understand. > > > Although it would be possible to select whether the old or the new > > > behavior is selected by introducing yet another host controller quirk, I > > > prefer not to do that because it would make the UFSHCI driver even more > > > complex. > > > > I strongly believe that using the quirk is the way forward to address this > > issue. Because this is not a documented behavior to be handled in the core > > driver and also defeats the purpose of having the quirks in first place. > > Adding a quirk is not an option in this case because adding a new quirk > without code that uses the quirk is not allowed. It may take another > year before the code that uses that new quirk is sent upstream because > the team that sends Pixel SoC drivers upstream only does this after > devices with that SoC are publicly available. > Then why can't you send the change at that time? We do the same for Qcom SoCs all the time and I'm pretty sure that the Pixel SoCs are no different. At that time, the SoC may get a new revision and we may end up not needing the quirk at all. I'm not saying that it will happen, but that is a common practice among the semiconductor companies. - Mani -- மணிவண்ணன் சதாசிவம்
