Re: [RFC PATCH 07/11] arm64: dts: qcom: hamoa: Move Iris IOMMUs to sub nodes

[Krzysztof Kozlowski <krzk@kernel.org>]

On 16/07/2026 11:07, Vikash Garodia wrote:
> Hi Krzysztof,
> 
> On 7/13/2026 11:32 AM, Vikash Garodia wrote:
>>
>> On 7/12/2026 5:49 PM, Dmitry Baryshkov wrote:
>>> On Fri, Jul 10, 2026 at 11:46:58PM +0100, Bryan O'Donoghue wrote:
>>>> On 09/07/2026 13:35, Vikash Garodia wrote:
>>>>> The Iris VPU has separate streams with different IOVA constraints. The
>>>>> non-pixel stream must be limited to the 0-600 MB IOVA range, while the
>>>>> pixel stream can use the full IOVA space.
>>>>
>>>>
>>>>> Using a single set of IOMMU entries for the Iris node does not describe
>>>>> these per-stream limits and can allow accesses outside the supported
>>>>> range, which may lead to device crashes. One such issue was reported 
>>>>> at:
>>>>> https://gitlab.freedesktop.org/drm/msm/-/work_items/100
>>>>>
>>>>> Add non-pixel and pixel child nodes, move each stream ID to its
>>>>> corresponding child node, and add a reserved IOVA range for the
>>>>> non-pixel stream.
>>>>>
>>>>> Co-developed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
>>>>> Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
>>>>> Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
>>>> The thing of it is, this _is_ a bugfix - perhaps its not one that can be
>>>> backported, actually scratch that, this isn't possible to land in - 
>>>> stable
>>>> realistically.
>>>>
>>>> So what is needed here is a strategy for fixing -stable.
>>>
>>> I think, we need to start with defining, which platforms are affected.
>>> sm8150+? SM8250+? SDM845+? MSM8996+?
>>
>> All platforms, including venus.
>>
>>>
>>>>
>>>> That could be apply Daniel's patch and backport it with Fixes: - with
>>>> mainline then say applying this change and reverting Daniel's patch
>>>>
>>>> or
>>>>
>>>> That could mean some other solution for -stable - up for debate - 
>>>> what's not
>>>> up for debate is this series needs to _address_ what happens to 
>>>> stable for
>>>> all of the target platforms - and then transition mainline to the new 
>>>> and
>>>> shiny way.
>>>>
>>>> That could mean
>>>>
>>>> - Applying Daniel's fix with Fixes: and cc-stable
>>>> - That patch needs to be extended to _each_ Iris platform containing
>>>>    this bug... all of them I think.
>>>> - Updating bindings
>>>> - Updating DT with new method simultaneously reverting Daniel's fix
>>>>
>>
>> Ack. The proposal seems a good way to me addressing stable, i can work 
>> towards this.
>>
>> Will wait for couple of days if there are any alternate suggestion on this.
>>
> 
> I would like to seek you suggestion on handling for the -stable branch.
> The approach proposed here is;
> 
> 1. Pick the workaround from Daniel, and mark it as Fixes: and cc-stable. 
> I have the series ready to post considering for all _iris_ platforms.
> 
> 2. Update the bindings with subnode, and at the same time, *reverting* 
> Daniel's fix on mainline.
> 
> This is due to the fact that #2 might not be easy to apply to all stable 
> branches, #1 would serve as workaround to fix the bug in --stable trees.
> 
> Please suggest if this is fine with you or any other way you would like 
> me to pursue.

Sorry guys, but the logic here is not correct. We do not develop
mainline kernel in a way that satisfies backports. IOW, we do not
organize the commit history in any other way than the mainline
development purpose.

Whatever you try to do, add some semi-correct fixes, then revert them so
backport will work, all this is just wrong.

There is NO DISCUSSION about stable here at all. None.

Best regards,
Krzysztof