Re: [PATCH v2 01/12] dt-bindings: media: qcom,venus: Add context bank subnodes to common schema

On 06/08/2026 12:24, Bryan O'Donoghue wrote:
> On 06/08/2026 11:14, Krzysztof Kozlowski wrote:
>> On 06/08/2026 12:07, Bryan O'Donoghue wrote:
>>> I tend to think - absent an obvious an immediately applicable fix these
>>> two drivers must be marked BROKEN, the alternative is to apply Daniel's
>>> fix and then live with the results for the bindings.
>>>
>>> Since the DT schema change is still under debate - what alternative is
>>> there ?
>>>
>>> I'm not far off sending that patch now myself because I'm not seeing
>>> urgency on fixing this and TBH that's pissing me off.
>>>
>>> As a user of a system, I expect resonsible and honest behaviour wrt to
>>> bugs, not architecture astronauty while my system can still reset
>>> despite perfectly functional fixes being available.
>>>
>>> Great you want to do sub-nodes in DT. Not great, that's not agreed yet,
>>> even more not great - the venus stuff isn't even on the list.
>>>
>>> Please indicate what should be done for -stable this week else both of
>>> these drivers need to be marked BROKEN.
>>
>> Nothing should be done for stable. Or rather: you can do whatever you
>> wish for the stable, because we discuss here mainline, not stable kernel.
>>
>> There is no problem here "devices running stable kernel are affected"
>> which we are solving.
>>
>> The only problem we are solving is "devices running mainline kernel are
>> affected". Fix this one and stable will follow.
>>
>> Best regards,
>> Krzysztof
> 
> Yes -master.
> 
> My issue is how long this will take. Several kernel cycles and the 
> debate is ongoing.
> 
> Daneil's fix has not been applied which means the replicable system bug 
> is out there in the wild, not addressed.
> 
> Daniel's fix could have been applied and rolled out to all users in 
> mainline and consequently stable.
> 
> Instead another architectural level fix is still under discussion, which 
> is of no value to end users whose systems can reset in the meantime.
> 
> Its just not responsible behaviour. So I feel both of these drivers need 
> to be marked as BROKEN unless/until a fix lands.
> 
> I'm hoping the vidc team will come up with something else.

I did not object taking a known fix for the problem for the mainline
kernel, regardless if the fix is optimal or not. I only objected the
reason of taking patches because of something in stable kernels or
making backports easier or whatever other semi-expressed reason, which
is not the mainline-kernel reason.

Best regards,
Krzysztof