All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Svyatoslav Ryhel" <clamor95@gmail.com>
Cc: conor+dt@kernel.org, devicetree@vger.kernel.org,
	dmitry.torokhov@gmail.com, linux-input@vger.kernel.org,
	robh@kernel.org
Subject: Re: [PATCH v6 5/6] mfd: motorola-cpcap: diverge configuration per-board
Date: Wed, 20 May 2026 19:28:18 +0000	[thread overview]
Message-ID: <20260520192819.629261F00894@smtp.kernel.org> (raw)
In-Reply-To: <20260520182124.117863-6-clamor95@gmail.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Critical] Modifying the OF match table breaks backward compatibility with existing Device Trees.
- [Low] Casting a pointer directly to an enum causes a `-Wpointer-to-int-cast` compiler warning on 64-bit architectures.
--

commit d4fffaca1e4a78c4406875cbdeef7c59b0fe0b1a
Author: Svyatoslav Ryhel <clamor95@gmail.com>

mfd: motorola-cpcap: diverge configuration per-board

This commit introduces board-specific subdevice configurations for the
Motorola CPCAP MFD. It defines common, default, and mapphone device lists
and uses SPI/OF match data to select the variant.

> diff --git a/drivers/mfd/motorola-cpcap.c b/drivers/mfd/motorola-cpcap.c
> index d8243b956f875..5b6ca6b81c232 100644
> --- a/drivers/mfd/motorola-cpcap.c
> +++ b/drivers/mfd/motorola-cpcap.c
[ ... ]
> @@ -241,62 +229,58 @@ static int cpcap_resume(struct device *dev)
[ ... ]
>  static int cpcap_probe(struct spi_device *spi)
>  {
>  	struct cpcap_ddata *cpcap;
> +	const struct mfd_cell *cells;
> +	unsigned int num_cells;
>  	int ret;
>  
>  	cpcap = devm_kzalloc(&spi->dev, sizeof(*cpcap), GFP_KERNEL);
>  	if (!cpcap)
>  		return -ENOMEM;
>  
> +	cpcap->variant = (enum cpcap_variant)spi_get_device_match_data(spi);

[Severity: Low]
Does this direct cast from a pointer to an enum cause a compiler warning on
64-bit architectures?

spi_get_device_match_data() returns a const void *, which is 64-bit on
64-bit architectures, while enum cpcap_variant is typically a 32-bit integer.
Casting directly from a 64-bit pointer to a 32-bit enum can trigger a
-Wpointer-to-int-cast warning and cause build failures when compiled with
-Werror.

Should the pointer be cast to an intermediate integer type like
(uintptr_t) or (unsigned long) first?

[ ... ]
> @@ -331,10 +315,29 @@ static int cpcap_probe(struct spi_device *spi)
[ ... ]
> +static const struct of_device_id cpcap_of_match[] = {
> +	{ .compatible = "motorola,cpcap", .data = (void *)CPCAP_DEFAULT },
> +	{ .compatible = "motorola,mapphone-cpcap", .data = (void *)CPCAP_MAPPHONE },
> +	{ /* sentinel */ }
> +};

[Severity: Critical]
Does this modification to the OF match table break backward compatibility with
existing Device Trees?

The Device Tree is considered a stable ABI in the kernel. This change reassigns
the existing "motorola,cpcap" compatible string to map to CPCAP_DEFAULT instead
of preserving its legacy behavior (which included Mapphone-specific child
nodes).

Older DTBs rely on "motorola,cpcap" to instantiate devices such as the battery
charger and Mapphone-specific ADC/regulator/USB-PHY. By mapping to
CPCAP_DEFAULT, the MFD core uses generic compatible strings (e.g.,
"motorola,cpcap-adc" instead of "motorola,mapphone-cpcap-adc") and entirely
omits the charger. As a result, the child devices fail to match their DT nodes,
leaving them without of_node pointers and breaking critical functionality.

Additionally, could the complete removal of the "st,6556002" compatible string
(mentioned in the commit message) break devices relying on it?

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

  reply	other threads:[~2026-05-20 19:28 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-20 18:21 [PATCH v6 0/6] mfd: cpcap: convert documentation to schema and add Mot board support Svyatoslav Ryhel
2026-05-20 18:21 ` [PATCH v6 1/6] dt-bindings: leds: leds-cpcap: convert to DT schema Svyatoslav Ryhel
2026-05-20 20:13   ` Rob Herring (Arm)
2026-05-20 18:21 ` [PATCH v6 2/6] dt-bindings: input: cpcap-pwrbutton: " Svyatoslav Ryhel
2026-05-20 20:13   ` Rob Herring (Arm)
2026-05-20 18:21 ` [PATCH v6 3/6] dt-bindings: mfd: motorola-cpcap: " Svyatoslav Ryhel
2026-05-20 18:52   ` sashiko-bot
2026-05-20 18:21 ` [PATCH v6 4/6] dt-bindings: mfd: motorola-cpcap: document Mapphone and Mot CPCAP Svyatoslav Ryhel
2026-05-20 18:21 ` [PATCH v6 5/6] mfd: motorola-cpcap: diverge configuration per-board Svyatoslav Ryhel
2026-05-20 19:28   ` sashiko-bot [this message]
2026-05-20 18:21 ` [PATCH v6 6/6] mfd: motorola-cpcap: add support for Mot CPCAP composition Svyatoslav Ryhel
2026-05-27 15:14 ` [PATCH v6 0/6] mfd: cpcap: convert documentation to schema and add Mot board support Lee Jones
2026-05-28  5:17   ` Svyatoslav Ryhel

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=20260520192819.629261F00894@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=clamor95@gmail.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=linux-input@vger.kernel.org \
    --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 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.