On 2/4/2025 3:01 PM, Johan Hovold wrote: > On Mon, Feb 03, 2025 at 05:16:50PM +0200, Dmitry Baryshkov wrote: >> On Mon, Feb 03, 2025 at 09:22:51AM +0100, Johan Hovold wrote: >>> On Fri, Jan 31, 2025 at 10:44:28AM -0800, Abhinav Kumar wrote: > >>>> Solution: If the user prefers iris driver and iris driver has not probed >>>> yet, and if venus tries to probe ahead of iris we keep -EDEFERing till >>>> iris probes and succeeds. Vice-versa when the preference is venus as well. >>> >>> This sounds wrong too. >>> >>> Look, first you guys need to explain *why* you want to have two drivers >>> for the same hardware (not just to me, in the commit message and cover >>> letter). >>> >>> That's something that really should never be the case and would need to >>> be motivated properly. >> >> I think it has been written several time (not sure about this commit): >> to provide a way for a migration path _while_ people are working on Iris >> features. Being able to A/B test Venus and Iris drivers and to report >> possible regressions or lack of those on the common platforms supported >> by those (sm8250 at this moment). > > You don't need a module parameter for that. > > And we're still waiting to hear the answers to all of Hans' questions. I > still haven't seen anyone explaining why any of this is needed. You > could have just continued letting Venus support 8250 so presumably there > is some benefit in using Iris instead. Which? And is that potential > benefit important enough to not just wait until Iris is up to par > feature wise? They are documented in this RFC [1] as comments, and would be added in v10 as we conclude the ongoing discussion to handle 2 drivers during the transition phase. [1] https://patchwork.kernel.org/project/linux-media/patch/20250128080429.3911091-2-quic_dikshita@xxxxxxxxxxx/ Regards, Vikash > > I'm sure you have some answers, but you need to provide them as part of > the series. > >>> Second, if the reasons for keeping both drivers are deemed justifiable, >>> you need to come up with mechanism for only binding one of them. >>> >>> I already told you that module parameters is not the way to go here (and >>> the msm drm driver's abuse of module parameters is not a good precedent >>> here). >>> >>> If this is a transitional thing (which it must be), then just add a >>> Kconfig symbol to determine which driver should probe. That's good >>> enough for evaluating whatever needs to be evaluated, and doesn't >>> depend on adding anti-patterns like module parameters (and helper >>> modules for them). >> >> No, Kconfig complicates A/B testing. What you usually want to do is to >> boot a kernel, then go over a bunch of files testing that they work with >> both drivers. Kconfig implies booting abother kernel, etc. > > No, I'm pretty sure you'd even want to reboot in between so as not to > rely on state left behind by the other driver. > > Unbinding and rebinding drivers is not part of any normal work flow > expect possibly during development. And a developer can easily compare > Venus and Iris for 8250 without a module parameter too. > > Johan
