On Fri, Aug 23, 2024 at 11:05:12AM -0700, Bart Van Assche wrote: > On 8/23/24 9:48 AM, Manivannan Sadhasivam wrote: > > On Fri, Aug 23, 2024 at 09:07:18AM -0700, Bart Van Assche wrote: > > > On 8/23/24 7:58 AM, Manivannan Sadhasivam wrote: > > > > Then why can't you send the change at that time? > > > > > > We use the Android GKI kernel and any patches must be sent upstream > > > first before these can be considered for inclusion in the GKI kernel. > > > > But that's the same requirement for other SoC vendors as well. Anyway, these > > don't justify the fact that the core code should be modified to workaround a > > controller defect. Please use quirks as like other vendors. > > Let me repeat what I mentioned earlier: > * Introducing a new quirk without introducing a user for that quirk is > not acceptable because that would involve introducing code that is > dead code from the point of view of the upstream kernel. As I pointed out earlier, you should just submit the quirk change when you are submitting your driver. But you said that for GKI requirement you are doing the change in core driver. But again, that is applicable for other vendors as well. What if other vendors start adding the workaround in the core driver citing GKI requirement (provided it also removes some code as you justified)? Will it be acceptable? NO. > * The UFS driver core is already complicated. If we don't need a new > quirk we shouldn't introduce a new quirk. > Sorry, the quirk is a quirk. All the existing quirks can be worked around in the core driver in some way. But we have the quirk mechanisms to specifically not to do that to avoid polluting the core code which has to follow the spec. Moreover, this workaround you are adding is not at all common for other controllers. So this definitely doesn't justify modifying the core code. IMO adding more code alone will not make a driver complicated, but changing the logic will. - Mani -- மணிவண்ணன் சதாசிவம்
