All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Mukesh Kumar Savaliya" <mukesh.savaliya@oss.qualcomm.com>
Cc: vkoul@kernel.org, Frank.Li@kernel.org,
	devicetree@vger.kernel.org, robh@kernel.org,
	dmaengine@vger.kernel.org, conor+dt@kernel.org
Subject: Re: [PATCH v9 1/4] dt-bindings: i2c: qcom,i2c-geni: Document multi-owner controller support
Date: Thu, 13 Aug 2026 14:10:12 +0000	[thread overview]
Message-ID: <20260813141012.B5ADE1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260813140047.1006478-2-mukesh.savaliya@oss.qualcomm.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The schema documents a runtime restriction for `qcom,qup-multi-owner` but fails to enforce it programmatically, allowing invalid device trees to pass validation.
--

--- Patch [1]: [PATCH v9 1/4] dt-bindings: i2c: qcom,i2c-geni: Document multi-owner controller support ---
commit 744011d8e769def492430680cc665ca844b312d6
Author: Mukesh Kumar Savaliya <mukesh.savaliya@oss.qualcomm.com>

dt-bindings: i2c: qcom,i2c-geni: Document multi-owner controller support

This commit documents a new qcom,qup-multi-owner property for QUP-based I2C
controllers that are shared with other system processors. It instructs the
operating system to avoid assuming exclusive ownership of the hardware.

> diff --git a/Documentation/devicetree/bindings/i2c/qcom,i2c-geni-qcom.yaml b/Documentation/devicetree/bindings/i2c/qcom,i2c-geni-qcom.yaml
> index 51534953a69cf..ed9b029603fdf 100644
> --- a/Documentation/devicetree/bindings/i2c/qcom,i2c-geni-qcom.yaml
> +++ b/Documentation/devicetree/bindings/i2c/qcom,i2c-geni-qcom.yaml

[ ... ]

> @@ -60,6 +60,22 @@ properties:
>    power-domains:
>      maxItems: 1
>  
> +  qcom,qup-multi-owner:
> +    type: boolean
> +    description:
> +      Indicates that the QUP-based controller is shared with one or more
> +      other system processors and must not be assumed to have exclusive
> +      ownership by the operating system.
> +
> +      The associated GPIOs must not be reconfigured into a sleep state
> +      during runtime suspend, as doing so may disrupt transactions
> +      initiated by another owner of the controller.

[Severity: Medium]
The prose correctly documents that the GPIOs must not be put into a sleep
state when this property is present, but should this be enforced
programmatically in the schema?

Without an allOf conditional block restricting pinctrl-names to maxItems: 1
and disallowing pinctrl-1, device trees that mistakenly provide a sleep
pinctrl state alongside qcom,qup-multi-owner will silently pass
dt_binding_check and dtbs_check.

At runtime, the power management core would then automatically apply the sleep
state during runtime suspend, which disrupts the hardware as warned against in
the description.

> +
> +      Each owner is responsible for maintaining any resource votes
> +      required for operation of the shared controller (for example clocks,
> +      power domains, interconnect bandwidth, or other platform-specific
> +      resources)
>
>    reg:
>      maxItems: 1

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260813140047.1006478-1-mukesh.savaliya@oss.qualcomm.com?part=1

  reply	other threads:[~2026-08-13 14:10 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-13 14:00 [PATCH v9 0/4] Enable multi-owner I2C support for QCOM GENI controllers Mukesh Kumar Savaliya
2026-08-13 14:00 ` [PATCH v9 1/4] dt-bindings: i2c: qcom,i2c-geni: Document multi-owner controller support Mukesh Kumar Savaliya
2026-08-13 14:10   ` sashiko-bot [this message]
2026-08-13 14:00 ` [PATCH v9 2/4] dmaengine: qcom: gpi: Add lock/unlock TREs for multi-owner I2C transfers Mukesh Kumar Savaliya
2026-08-13 14:19   ` sashiko-bot
2026-08-13 14:00 ` [PATCH v9 3/4] soc: qcom: geni-se: Keep pinctrl active for multi-owner controllers Mukesh Kumar Savaliya
2026-08-13 14:17   ` sashiko-bot
2026-08-13 14:00 ` [PATCH v9 4/4] i2c: qcom-geni: Support multi-owner controllers in GPI mode Mukesh Kumar Savaliya
2026-08-13 14:14   ` sashiko-bot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260813141012.B5ADE1F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=Frank.Li@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dmaengine@vger.kernel.org \
    --cc=mukesh.savaliya@oss.qualcomm.com \
    --cc=robh@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=vkoul@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.