devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Eduard Bostina" <egbostina@gmail.com>
Cc: mfd@lists.linux.dev, robh@kernel.org, lee@kernel.org,
	devicetree@vger.kernel.org, conor+dt@kernel.org
Subject: Re: [PATCH v2] dt-bindings: mfd: Convert TI TWL6040 to DT schema
Date: Sun, 16 Aug 2026 09:36:54 +0000	[thread overview]
Message-ID: <20260816093654.8ACFC1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260816092847.2522994-1-egbostina@gmail.com>

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:

New issues:
- [Medium] Missing dependency enforcement for the 'vibra' node power supplies ('vddvibl-supply' and 'vddvibr-supply').

Pre-existing issues:
- [High] The twl6040 driver constructs its mfd_cell array dynamically at runtime and mutates a global static resource array, violating MFD static reference rules.
- [High] Hardcoded cell indexing via PLATFORM_DEVID_NONE creates sysfs naming collisions.
--

--- Patch [1]: [PATCH v2] dt-bindings: mfd: Convert TI TWL6040 to DT schema ---
commit 940b493f232639b743b8f6ddfb4feba28f32a8ab
Author: Eduard Bostina <egbostina@gmail.com>

dt-bindings: mfd: Convert TI TWL6040 to DT schema

Convert the Texas Instruments TWL6040 audio codecs family bindings to DT
schema. During the conversion, ti,audpwron-gpio was renamed and made
optional along with gpio-controller. The vibra voltage properties were also
renamed to match what the driver actually reads.

Link: https://lore.kernel.org/all/20260815083451.2147129-1-egbostina@gmail.com/

While reviewing this binding conversion, I noticed a couple of pre-existing
issues in the corresponding driver.

[Severity: High]
This isn't a bug introduced by this patch, but does the dynamic mutation of
mfd_cell resources in twl6040_probe() cause a data race?

drivers/mfd/twl6040.c:twl6040_probe() {
    ...
    twl6040_codec_rsrc[0].start = irq;
    twl6040_codec_rsrc[0].end = irq;
    cell->resources = twl6040_codec_rsrc;
    cell->num_resources = ARRAY_SIZE(twl6040_codec_rsrc);
    ...
}

If two TWL6040 devices probe concurrently, could they race to overwrite these
globally shared arrays, resulting in incorrect IRQ assignments for the child
devices?

[Severity: High]
This is a pre-existing issue, but does using the hardcoded value of -1
instead of PLATFORM_DEVID_AUTO prevent multiple TWL6040 chips from being
used in the same system?

drivers/mfd/twl6040.c:twl6040_probe() {
    ...
    ret = mfd_add_devices(&client->dev, -1, twl6040->cells, children,
                          NULL, 0, NULL);
    ...
}

If a system integrates more than one TWL6040 device, would the second
instance fail to probe its child devices due to identical sysfs device names?

> diff --git a/Documentation/devicetree/bindings/mfd/ti,twl6040.yaml b/Documentation/devicetree/bindings/mfd/ti,twl6040.yaml
> new file mode 100644
> index 0000000000000..011a1a58615a6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/ti,twl6040.yaml
[ ... ]
> +  vibra:
> +    type: object
> +    additionalProperties: false
> +    properties:
> +      ti,vibldrv-res:

[Severity: Medium]
Should the vibra configuration object include a dependencies constraint to
ensure vddvibl-supply and vddvibr-supply are present?

The previous twl6040.txt binding explicitly marked vddvibl-supply and
vddvibr-supply as required when the vibra functionality is present.

Without this constraint, would an incomplete device tree missing these
regulators silently pass dt_binding_check validation but fail in
twl6040-vibra.c at runtime?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260816092847.2522994-1-egbostina@gmail.com?part=1

  reply	other threads:[~2026-08-16  9:36 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-16  9:28 [PATCH v2] dt-bindings: mfd: Convert TI TWL6040 to DT schema Eduard Bostina
2026-08-16  9:36 ` sashiko-bot [this message]
2026-08-16 16:00 ` Dhruva G

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=20260816093654.8ACFC1F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=egbostina@gmail.com \
    --cc=lee@kernel.org \
    --cc=mfd@lists.linux.dev \
    --cc=robh@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).