Re: [PATCH v7 3/4] soc: qcom: geni-se: Keep pinctrl active for multi-owner controllers

[Mukesh Savaliya]

Hi Bjorn, Thanks for the detailed review.

On 5/22/2026 8:36 AM, Bjorn Andersson wrote:
> On Thu, Apr 23, 2026 at 08:25:50PM +0530, Mukesh Kumar Savaliya wrote:
> > On platforms where a GENI Serial Engine is shared with another system
> > processor, selecting the "sleep" pinctrl state can disrupt ongoing
> > transfers initiated by the other processor.
>
> Isn't it strange that the DeviceTree will define a sleep state for the
> OS to select, but when this other property is set the OS should never
> select this state?

The intent here is that for multi-owner configurations the
“sleep” pinctrl state is not safe to use, since the pins may
still be actively driven by another execution environment.
Selecting the sleep state in such cases can disrupt transfers
initiated by the other owner.

You're right that this constraint is currently not described
in the binding, which makes the behavior non-obvious.

shall i update the DT binding to clarify that when
"qcom,qup-multi-owner" is present ? The OS must not transition
the pins to the "sleep" state, as the hardware is shared and
may be active outside of Linux control.

Alternatively, we can also consider relaxing the requirement
to define a sleep state for such nodes if that aligns better
with DT expectations.

> > Teach geni_se_resources_off() to skip selecting the pinctrl sleep state
> > when the Serial Engine is marked as shared, while still allowing the
> > rest of the resource shutdown sequence to proceed.
> >
> > This is required for multi-owner configurations (described via DeviceTree
> > with qcom,qup-multi-owner on the protocol controller node).
>
> The requirement as such is reasonable, but you don't define in the
> binding that when this property is set, the sleep state must not be
> selected by the OS...

Please let me know if you prefer second approach over the first, i shall 
update accordingly.

> Regards,
> Bjorn
>
> > Reviewed-by: Konrad Dybcio <konrad.dybcio@xxxxxxxxxxxxxxxx>
> > Signed-off-by: Mukesh Kumar Savaliya <mukesh.savaliya@xxxxxxxxxxxxxxxx>
> > ---
[...]