* Re: [PATCH v9 5/7] leds: Add driver for ASUS Transformer LEDs
From: sashiko-bot @ 2026-06-25 8:22 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: conor+dt, linux-input, dmitry.torokhov, robh, devicetree,
linux-leds, lee
In-Reply-To: <20260625081529.22447-6-clamor95@gmail.com>
> From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
>
> ASUS Transformer tablets have a green and an amber LED on both the Pad
> and the Dock. If both LEDs are enabled simultaneously, the emitted light
> will be yellow.
>
> Co-developed-by: Svyatoslav Ryhel <clamor95@gmail.com>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625081529.22447-1-clamor95@gmail.com?part=5
^ permalink raw reply
* Re: [PATCH v9 7/7] power: supply: Add charger driver for Asus Transformers
From: sashiko-bot @ 2026-06-25 8:23 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: linux-input, dmitry.torokhov, robh, lee, linux-leds, conor+dt,
devicetree
In-Reply-To: <20260625081529.22447-8-clamor95@gmail.com>
> From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
>
> Add support for charger detection capabilities found in the embedded
> controller of ASUS Transformer devices.
>
> Suggested-by: Maxim Schwalm <maxim.schwalm@gmail.com>
> Suggested-by: Svyatoslav Ryhel <clamor95@gmail.com>
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625081529.22447-1-clamor95@gmail.com?part=7
^ permalink raw reply
* Re: [PATCH v6 2/6 RESEND] dt-bindings: input: cpcap-pwrbutton: convert to DT schema
From: sashiko-bot @ 2026-06-25 8:23 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: conor+dt, devicetree, linux-leds, linux-input, robh, lee,
dmitry.torokhov
In-Reply-To: <20260625081812.33474-3-clamor95@gmail.com>
> Convert power button devicetree bindings for the Motorola CPCAP MFD from
> TXT to YAML format. This patch does not change any functionality; the
> bindings remain the same.
>
> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625081812.33474-1-clamor95@gmail.com?part=2
^ permalink raw reply
* Re: [PATCH v6 6/6 RESEND] mfd: motorola-cpcap: add support for Mot CPCAP composition
From: sashiko-bot @ 2026-06-25 8:23 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: robh, linux-leds, dmitry.torokhov, conor+dt, linux-input,
devicetree, lee
In-Reply-To: <20260625081812.33474-7-clamor95@gmail.com>
> Add a MFD subdevice composition used in Tegra20 based Mot board
> (Motorola Atrix 4G and Droid X2).
>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625081812.33474-1-clamor95@gmail.com?part=6
^ permalink raw reply
* Re: [PATCH v6 1/6 RESEND] dt-bindings: leds: leds-cpcap: convert to DT schema
From: sashiko-bot @ 2026-06-25 8:24 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: devicetree, robh, linux-input, dmitry.torokhov, lee, conor+dt,
linux-leds
In-Reply-To: <20260625081812.33474-2-clamor95@gmail.com>
> Convert LEDs devicetree bindings for the Motorola CPCAP MFD from TXT to
> YAML format. This patch does not change any functionality; the bindings
> remain the same.
>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625081812.33474-1-clamor95@gmail.com?part=1
^ permalink raw reply
* Re: [PATCH v9 4/7] input: keyboard: Add driver for ASUS Transformer dock multimedia keys
From: sashiko-bot @ 2026-06-25 8:25 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: robh, linux-input, dmitry.torokhov, lee, devicetree, conor+dt,
linux-leds
In-Reply-To: <20260625081529.22447-5-clamor95@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Explicitly calling `input_unregister_device()` on a device allocated with `devm_input_allocate_device()`.
--
commit b1b4cf8c044b790c2019bf0bb44a52ad2de52358
Author: Michał Mirosław <mirq-linux@rere.qmqm.pl>
input: keyboard: Add driver for ASUS Transformer dock multimedia keys
This patch adds support for the multimedia top button row of the ASUS
Transformer's Mobile Dock keyboard. It tracks keyboard input events for
AltGr presses to switch to multimedia keys.
> diff --git a/drivers/input/keyboard/asus-transformer-ec-keys.c b/drivers/input/keyboard/asus-transformer-ec-keys.c
> new file mode 100644
> index 0000000000000..53aff3ce7146d
> --- /dev/null
> +++ b/drivers/input/keyboard/asus-transformer-ec-keys.c
[ ... ]
> +static int asus_ec_keys_probe(struct platform_device *pdev)
> +{
> + struct i2c_client *parent = to_i2c_client(pdev->dev.parent);
> + struct asusec_core *ec = dev_get_drvdata(pdev->dev.parent);
> + struct device *dev = &pdev->dev;
> + struct asus_ec_keys_data *priv;
> + int error;
> +
> + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + platform_set_drvdata(pdev, priv);
> + priv->ec = ec;
> +
> + priv->xidev = devm_input_allocate_device(dev);
[ ... ]
> + error = input_register_device(priv->xidev);
> + if (error)
> + return dev_err_probe(dev, error,
> + "failed to register extension keys\n");
> +
> + error = asus_ec_keys_register_handler(dev, priv);
> + if (error) {
> + input_unregister_device(priv->xidev);
[Severity: Medium]
Since priv->xidev is allocated with devm_input_allocate_device() earlier in
asus_ec_keys_probe(), does explicitly calling input_unregister_device()
here in the error path lead to a double-unregistration when the managed API
automatic cleanup triggers?
> + return error;
> + }
> +
> + priv->nb.notifier_call = asus_ec_keys_notify;
> +
> + error = blocking_notifier_chain_register(&ec->notify_list, &priv->nb);
> + if (error) {
> + input_unregister_device(priv->xidev);
[Severity: Medium]
Could manually unregistering the devm-managed input device here in the
notifier registration error path similarly cause a double-unregistration?
> + input_unregister_handler(&priv->input_handler);
> + return error;
> + }
> +
> + return 0;
> +}
> +
> +static void asus_ec_keys_remove(struct platform_device *pdev)
> +{
> + struct asus_ec_keys_data *priv = platform_get_drvdata(pdev);
> + struct asusec_core *ec = priv->ec;
> +
> + blocking_notifier_chain_unregister(&ec->notify_list, &priv->nb);
> + input_unregister_handler(&priv->input_handler);
> + input_unregister_device(priv->xidev);
[Severity: Medium]
Does bypassing the automatic devm lifecycle by explicitly calling
input_unregister_device() in asus_ec_keys_remove() on a managed device lead
to double-unregistration when the device is unbound?
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625081529.22447-1-clamor95@gmail.com?part=4
^ permalink raw reply
* Re: [PATCH v9 2/7] mfd: Add driver for ASUS Transformer embedded controller
From: sashiko-bot @ 2026-06-25 8:26 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: conor+dt, lee, linux-input, devicetree, robh, linux-leds,
dmitry.torokhov
In-Reply-To: <20260625081529.22447-3-clamor95@gmail.com>
> From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
>
> Support Nuvoton NPCE795-based ECs as used in Asus Transformer TF201,
> TF300T, TF300TG, TF300TL and TF700T pad and dock, as well as TF101 dock
> and TF600T, P1801-T and TF701T pad. This is a glue driver handling
> detection and common operations for EC's functions.
>
> Co-developed-by: Svyatoslav Ryhel <clamor95@gmail.com>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625081529.22447-1-clamor95@gmail.com?part=2
^ permalink raw reply
* Re: [PATCH v9 3/7] input: serio: Add driver for ASUS Transformer dock keyboard and touchpad
From: sashiko-bot @ 2026-06-25 8:27 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: dmitry.torokhov, conor+dt, linux-input, devicetree, robh,
linux-leds, lee
In-Reply-To: <20260625081529.22447-4-clamor95@gmail.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] Premature registration of the event notifier before callback initialization causes a race condition leading to a NULL pointer dereference.
- [High] Incorrect devres ordering leaves the notifier active after serio ports are destroyed, causing a Use-After-Free during teardown.
- [High] Incorrect bounds check on the EC packet length allows an out-of-bounds heap read and exposes uninitialized memory.
--
commit 27a9e7909b45cc654374940aa7f4c4574172729b
Author: Michał Mirosław <mirq-linux@rere.qmqm.pl>
input: serio: Add driver for ASUS Transformer dock keyboard and touchpad
Add input driver for ASUS Transformer dock keyboard and touchpad. Modify
incoming keyboard data to send proper scancodes for keys that don't match
their position.
> diff --git a/drivers/input/serio/asus-transformer-ec-kbc.c b/drivers/input/serio/asus-transformer-ec-kbc.c
> new file mode 100644
> index 0000000000000..3ddfa9925b2b0
> --- /dev/null
> +++ b/drivers/input/serio/asus-transformer-ec-kbc.c
[ ... ]
> +static int asus_ec_kbc_notify(struct notifier_block *nb,
> + unsigned long action, void *data_)
> +{
[ ... ]
> + /*
> + * The data[0] is the length of the packet including itself. The data[]
> + * buffer has to be at least 3 bytes (length + ctrl + 1 data byte) and
> + * must not exceed the EC buffer size.
> + */
> + if (data[0] < 2 || data[0] > ASUSEC_ENTRY_BUFSIZE)
> + return NOTIFY_BAD;
> +
> + n = data[0] - 1;
> + data += 2;
[ ... ]
> + while (n--)
> + serio_interrupt(priv->sdev[port_idx], *data++, 0);
[Severity: High]
If data[0] is ASUSEC_ENTRY_BUFSIZE (33), n becomes 32, and data is advanced
by 2. Will the loop read 32 bytes from data[2] up to data[33]?
Since the buffer is exactly 33 bytes long, could this read past the end of
the array or access uninitialized data?
> +
> + return NOTIFY_OK;
> +}
[ ... ]
> +static int asus_ec_kbc_probe(struct platform_device *pdev)
> +{
> + struct asusec_core *ec = dev_get_drvdata(pdev->dev.parent);
> + struct asus_ec_kbc_data *priv;
> + int error;
> +
> + priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + platform_set_drvdata(pdev, priv);
> +
> + priv->ec = ec;
> + priv->parent = to_i2c_client(pdev->dev.parent);
> +
> + error = blocking_notifier_chain_register(&ec->notify_list, &priv->nb);
[Severity: High]
Is it safe to register the notifier here before priv->nb.notifier_call is
initialized?
If an interrupt fires immediately after registration, could the notifier core
attempt to call a NULL pointer?
> + if (error)
> + return dev_err_probe(&pdev->dev, error,
> + "failed to register blocking notifier chain");
> +
> + error = devm_add_action_or_reset(&pdev->dev,
> + asus_ec_notifier_chain_unregister,
> + priv);
[Severity: High]
Since managed resources (devm) are released in LIFO order, will the serio
ports registered below be unregistered and freed before this notifier is
unregistered?
If an interrupt arrives during the unbind window or if the probe function
fails after port registration, could the notifier loop in asus_ec_kbc_notify()
dereference the freed serio port pointers?
> + if (error)
> + return error;
> +
> + error = asus_ec_register_serio(pdev, 0, "Keyboard", 0);
> + if (error)
> + return error;
> +
> + error = asus_ec_register_serio(pdev, 1, "Touchpad", I8042_CMD_AUX_SEND);
> + if (error)
> + return error;
> +
> + priv->nb.notifier_call = asus_ec_kbc_notify;
> +
> + return 0;
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625081529.22447-1-clamor95@gmail.com?part=3
^ permalink raw reply
* Re: [PATCH v6 4/6 RESEND] dt-bindings: mfd: motorola-cpcap: document Mapphone and Mot CPCAP
From: sashiko-bot @ 2026-06-25 8:27 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: robh, devicetree, lee, conor+dt, dmitry.torokhov, linux-input,
linux-leds
In-Reply-To: <20260625081812.33474-5-clamor95@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The newly added device tree compatible strings `motorola,mapphone-cpcap` and `motorola,mot-cpcap` are defined as a standalone enum without a fallback, forcing device trees to either break schema validation or break OMAP platform initialization.
--
commit 6926040210bec2501eaa0528dd29bde0ac318c6c
Author: Svyatoslav Ryhel <clamor95@gmail.com>
dt-bindings: mfd: motorola-cpcap: document Mapphone and Mot CPCAP
Add compatibles for Mapphone and Mot CPCAP subdevice compositions. Both
variations cannot use st,6556002 fallback since they may be based on
different controllers.
> diff --git a/Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml b/Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml
> --- a/Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml
> +++ b/Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml
[ ... ]
> @@ -14,9 +14,14 @@ allOf:
>
> properties:
> compatible:
> - items:
> - - const: motorola,cpcap
> - - const: st,6556002
> + oneOf:
> + - enum:
> + - motorola,mapphone-cpcap
> + - motorola,mot-cpcap
[Severity: High]
Will this schema change break OMAP platform initialization for devices
using these new variants?
The schema defines the new compatibles as a standalone enum. However, the
OMAP platform initialization code explicitly relies on finding a node with the
generic motorola,cpcap compatible to configure the PMIC:
arch/arm/mach-omap2/pmic-cpcap.c:omap4_cpcap_init() {
...
if (!of_find_compatible_node(NULL, NULL, "motorola,cpcap"))
return -ENODEV;
...
}
If a device tree conforms to this new schema (using only the specific variant
compatible), the platform code will fail to find the node, breaking PMIC setup
and CPU voltage scaling.
Conversely, if a device tree defines an items array using motorola,cpcap as a
fallback to successfully initialize the platform code, it will fail schema
validation because this oneOf block expects either a standalone enum or the
specific ["motorola,cpcap", "st,6556002"] items list.
Should the new variants include motorola,cpcap as a fallback in an items
array, or does the OMAP platform code need an update to recognize these
new standalone compatibles?
> +
> + - items:
> + - const: motorola,cpcap
> + - const: st,6556002
>
> reg:
> maxItems: 1
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625081812.33474-1-clamor95@gmail.com?part=4
^ permalink raw reply
* Re: [PATCH v6 5/6 RESEND] mfd: motorola-cpcap: diverge configuration per-board
From: sashiko-bot @ 2026-06-25 8:29 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: devicetree, linux-input, conor+dt, linux-leds, robh, lee,
dmitry.torokhov
In-Reply-To: <20260625081812.33474-6-clamor95@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Critical] Repurposing the `motorola,cpcap` compatible string and removing `st,6556002` breaks backwards compatibility with existing Device Trees.
- [Low] Direct cast from `const void *` to `enum cpcap_variant` will cause a `-Wpointer-to-int-cast` compiler warning on 64-bit architectures.
--
commit bcc834e6accda9ec696d0ed365c9e5ada87bff4f
Author: Svyatoslav Ryhel <clamor95@gmail.com>
mfd: motorola-cpcap: diverge configuration per-board
MFD have rigid subdevice structure which does not allow flexible dynamic
subdevice linking. Address this by diverging CPCAP subdevice composition
to take into account board specific configuration.
> 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 const struct mfd_cell cpcap_default_devices[] = {
> + MFD_CELL_OF("cpcap_adc", NULL, NULL, 0, 0, "motorola,cpcap-adc"),
> + MFD_CELL_OF("cpcap-regulator", NULL, NULL, 0, 0, "motorola,cpcap-regulator"),
> + MFD_CELL_OF("cpcap-usb-phy", NULL, NULL, 0, 0, "motorola,cpcap-usb-phy"),
> +};
[Severity: Critical]
Does repurposing the default configuration break backwards compatibility with
existing Device Trees?
Existing hardware using the "motorola,cpcap" compatible string will now
use this generic array. It completely omits the charger and uses non-Mapphone
of_compatible strings, which will prevent existing child nodes (like
"motorola,mapphone-cpcap-adc") from successfully binding.
[ ... ]
> 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]
Will this direct cast from const void * to enum cpcap_variant cause a
-Wpointer-to-int-cast compiler warning when building on 64-bit architectures?
[ ... ]
> @@ -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 removing the "st,6556002" compatible string and re-mapping
"motorola,cpcap" to CPCAP_DEFAULT break existing devices?
Devices in the wild using "motorola,cpcap" or "st,6556002" in their
device tree may fail to probe critical PMIC functionality because they
are no longer correctly matched with their required Mapphone components.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625081812.33474-1-clamor95@gmail.com?part=5
^ permalink raw reply
* Re: [PATCH v9 6/7] power: supply: Add driver for ASUS Transformer battery
From: sashiko-bot @ 2026-06-25 8:31 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: conor+dt, robh, devicetree, linux-leds, dmitry.torokhov,
linux-input, lee
In-Reply-To: <20260625081529.22447-7-clamor95@gmail.com>
> From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
>
> Driver implements one battery cell per EC controller and supports reading
> of battery status for ASUS Transformer's pad and mobile dock.
>
> Co-developed-by: Svyatoslav Ryhel <clamor95@gmail.com>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625081529.22447-1-clamor95@gmail.com?part=6
^ permalink raw reply
* Re: [PATCH v2] leds: rgb: leds-qcom-lpg: Fix LED color balancing in HW pattern mode
From: Konrad Dybcio @ 2026-06-25 9:10 UTC (permalink / raw)
To: Fenglin Wu, linux-arm-msm, Lee Jones, Pavel Machek,
Bjorn Andersson, Marijn Suijten, Anjelique Melendez,
Guru Das Srinagesh
Cc: David Collins, Subbaraman Narayanamurthy, Kamal Wadhwa, kernel,
Pavel Machek, linux-leds, linux-kernel
In-Reply-To: <20260624-lpg-rgb-color-balance-fix-v2-1-c01b0e50caf6@oss.qualcomm.com>
On 6/24/26 9:37 AM, Fenglin Wu wrote:
> Currently, when the LED is configured as a RGB LED or a multi-color
> LED device, the same pattern is programmed for all LED channels
> regardless of the sub-led intensities when triggered by HW pattern.
> It results that the LED device is always working in a white-balanced
> mode regardless of the intensity settings.
>
> To fix this, scale the pattern data according to the sub-led intensity
> and program the HW pattern separately for each LPG channel.
>
> Fixes: 24e2d05d1b68 ("leds: Add driver for Qualcomm LPG")
> Fixes: 6ab1f766a80a ("leds: rgb: leds-qcom-lpg: Add support for PPG through single SDAM")
> Fixes: 5e9ff626861a ("leds: rgb: leds-qcom-lpg: Include support for PPG with dedicated LUT SDAM")
> Assisted-by: Claude:claude-4-6-sonnet
> Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com>
> ---
[...]
> +out_free:
> + kfree(pattern);
We can use __free() from cleanup.h to get rid of the gotos
[...]
> out_unlock:
> mutex_unlock(&lpg->lock);
> -out_free_pattern:
> - kfree(pattern);
> + kfree(pattern.data);
likewise here, also with guard(mutex)(foo)
and same below
Konrad
^ permalink raw reply
* Re: [PATCH v6 3/6 RESEND] dt-bindings: mfd: motorola-cpcap: convert to DT schema
From: sashiko-bot @ 2026-06-25 10:34 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: dmitry.torokhov, linux-input, lee, linux-leds, robh, conor+dt,
devicetree
In-Reply-To: <20260625081812.33474-4-clamor95@gmail.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [Medium] The YAML schema introduces a `ports` wrapper node for the `audio-codec`, which conflicts with the original TXT binding and existing device trees that define `port@X` directly as children.
- [Medium] The schema explicitly expects the power button subnode to be named exactly `key-power`, but the in-tree device tree uses `button`.
- [Medium] The `spi-cs-high` property, which is physically required by the hardware and was explicitly listed as required in the legacy text binding, has been omitted from the `required` list in the YAML schema.
--
commit 30a40e2d4eb937fd9bbca306ed8246e061a54ab4
Author: Svyatoslav Ryhel <clamor95@gmail.com>
dt-bindings: mfd: motorola-cpcap: convert to DT schema
Convert devicetree bindings for the Motorola CPCAP MFD from TXT to YAML.
> diff --git a/Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml b/Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml
> new file mode 100644
> index 0000000000000..76705ea56805a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml
[ ... ]
> + audio-codec:
> + type: object
> + additionalProperties: false
> +
> + properties:
[ ... ]
> + ports:
> + $ref: /schemas/graph.yaml#/properties/ports
[Severity: Medium]
Will this break validation for existing device trees?
The legacy text binding example shows port@0 and port@1 directly under the
audio-codec node, but this schema requires them to be wrapped in a ports
node. Because additionalProperties is set to false on audio-codec, direct
port@X nodes in existing device trees will be rejected.
[ ... ]
> + charger:
> + $ref: /schemas/power/supply/cpcap-charger.yaml#
> +
> + key-power:
> + $ref: /schemas/input/motorola,cpcap-pwrbutton.yaml#
[Severity: Medium]
Is it intentional to restrict the subnode name strictly to key-power?
Existing in-tree device trees use button for this node. By strictly matching
key-power, existing configurations will be rejected as an undocumented
property during schema validation.
[ ... ]
> +patternProperties:
> + "^led(-[a-z]+)?$":
> + $ref: /schemas/leds/motorola,cpcap-leds.yaml#
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - interrupt-controller
> + - "#interrupt-cells"
> + - spi-max-frequency
[Severity: Medium]
Does this schema incorrectly omit spi-cs-high from the required list?
The legacy text binding explicitly listed spi-cs-high as a required property.
Without it, incomplete device trees lacking this hardware-critical property
will incorrectly pass validation.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625081812.33474-1-clamor95@gmail.com?part=3
^ permalink raw reply
page: | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox