Devicetree
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "James Hilliard" <james.hilliard1@gmail.com>
Cc: robh@kernel.org, conor+dt@kernel.org, lee@kernel.org,
	devicetree@vger.kernel.org, mfd@lists.linux.dev,
	linux-sunxi@lists.linux.dev
Subject: Re: [PATCH v9 4/4] mfd: ac200: Add codec and TV encoder cells
Date: Thu, 03 Sep 2026 20:20:02 +0000	[thread overview]
Message-ID: <20260903202002.E06D81F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260903-submit-ac200-mfd-v9-4-6b7ed278989c@gmail.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] Using PLATFORM_DEVID_NONE instead of PLATFORM_DEVID_AUTO causes sysfs device naming collisions.
- [Low] Dynamic creation of a local stack copy of the mfd_cell array for filtering violates MFD architectural rules.
--

commit 5b7692c955e218224dd53b696f2b08c851828b93
Author: Jernej Skrabec <jernej.skrabec@gmail.com>

mfd: ac200: Add codec and TV encoder cells

Register the AC200 audio codec and TV encoder as MFD cells when their
enabled child nodes are present. Filtering the cell list avoids creating
unused platform devices.

> diff --git a/drivers/mfd/ac200.c b/drivers/mfd/ac200.c
> index 94aa13deb0f8c..f7d818141d9cb 100644
> --- a/drivers/mfd/ac200.c
> +++ b/drivers/mfd/ac200.c
[ ... ]
> +static int ac200_add_devices(struct device *dev)
> +{
> +	struct mfd_cell cells[ARRAY_SIZE(ac200_cells)];
> +	unsigned int num_cells = 0;
> +	unsigned int i;
> +	int ret;
> +
> +	for (i = 0; i < ARRAY_SIZE(ac200_cells); i++) {
> +		const struct mfd_cell *cell = &ac200_cells[i];
> +		struct device_node *child;
> +
> +		child = of_get_compatible_child(dev->of_node,
> +						cell->of_compatible);
> +		if (!child)
> +			continue;
> +		if (of_device_is_available(child))
> +			cells[num_cells++] = *cell;

[Severity: Low]
Does creating a dynamic local stack copy of the mfd_cell array here
violate the MFD architectural guidelines?

The MFD subsystem rules typically require cell arrays to remain static const.
Dynamically amending and explicitly copying into a local array during probe
in ac200_add_devices() bypasses the standard static definition approach. 

Could this instead use static references or a switch statement if variants 
or filtering are needed?

> +		of_node_put(child);
> +	}
> +
> +	if (!num_cells)
> +		return 0;
> +
> +	ret = devm_mfd_add_devices(dev, PLATFORM_DEVID_NONE, cells, num_cells,
> +				   NULL, 0, NULL);

[Severity: Medium]
Can passing PLATFORM_DEVID_NONE here cause sysfs device naming collisions?

If a system developer instantiates multiple AC200 chips in the device tree,
the second instance might fail during devm_mfd_add_devices() because both
instances will attempt to register child platform devices with identical
hard-coded names (like 'ac200-codec').

Would it be safer to use PLATFORM_DEVID_AUTO to allow automatic cell
indexing and properly support multi-instance configurations?

> +	if (ret)
> +		return dev_err_probe(dev, ret,
> +				     "failed to add function devices\n");
> +
> +	return 0;
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260903-submit-ac200-mfd-v9-0-6b7ed278989c@gmail.com?part=4

      reply	other threads:[~2026-09-03 20:20 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-03 20:09 [PATCH v9 0/4] mfd: add X-Powers AC200 support James Hilliard
2026-09-03 20:09 ` [PATCH v9 1/4] dt-bindings: mfd: x-powers: Add AC200 James Hilliard
2026-09-03 20:17   ` sashiko-bot
2026-09-03 20:09 ` [PATCH v9 2/4] mfd: ac200: Add X-Powers AC200 support James Hilliard
2026-09-03 20:21   ` sashiko-bot
2026-09-03 20:09 ` [PATCH v9 3/4] dt-bindings: mfd: x-powers: Describe AC200 functions James Hilliard
2026-09-03 20:14   ` sashiko-bot
2026-09-04 15:50   ` Conor Dooley
2026-09-04 17:06     ` James Hilliard
2026-09-03 20:09 ` [PATCH v9 4/4] mfd: ac200: Add codec and TV encoder cells James Hilliard
2026-09-03 20:20   ` sashiko-bot [this message]

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=20260903202002.E06D81F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=james.hilliard1@gmail.com \
    --cc=lee@kernel.org \
    --cc=linux-sunxi@lists.linux.dev \
    --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