linux-kernel - Re: [RFC PATCH v10 1/2] media: iris: introduce helper module to select video driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <812c4f61-724c-cee8-b7c9-a799ade0631c@quicinc.com>
Date: Tue, 4 Feb 2025 20:38:56 +0530
From: Vikash Garodia <quic_vgarodia@...cinc.com>
To: Johan Hovold <johan@...nel.org>,
        Dmitry Baryshkov
	<dmitry.baryshkov@...aro.org>
CC: Abhinav Kumar <quic_abhinavk@...cinc.com>,
        Krzysztof Kozlowski
	<krzk@...nel.org>,
        Dikshita Agarwal <quic_dikshita@...cinc.com>, <mchehab@...nel.org>,
        <robh@...nel.org>, <krzk+dt@...nel.org>, <p.zabel@...gutronix.de>,
        <hverkuil@...all.nl>, <sebastian.fricke@...labora.com>,
        <bryan.odonoghue@...aro.org>, <neil.armstrong@...aro.org>,
        <nicolas@...fresne.ca>, <u.kleine-koenig@...libre.com>,
        <stefan.schmidt@...aro.org>, <lujianhua000@...il.com>,
        <linux-arm-msm@...r.kernel.org>, <linux-media@...r.kernel.org>,
        <devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <krzysztof.kozlowski@...aro.org>
Subject: Re: [RFC PATCH v10 1/2] media: iris: introduce helper module to
 select video driver


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@quicinc.com/

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