From: Tzung-Bi Shih <tzungbi@kernel.org>
To: Gwendal Grignou <gwendal@chromium.org>
Cc: chrome-platform@lists.linux.dev, Gwendal Grignou <gwendal@google.com>
Subject: Re: [PATCH 1/2] chrome: lightbar: Report number of segments
Date: Mon, 26 Jan 2026 07:13:53 +0000 [thread overview]
Message-ID: <aXcUMXt0kN9W26PV@google.com> (raw)
In-Reply-To: <20260124085856.826357-1-gwendal@google.com>
On Sat, Jan 24, 2026 at 12:58:55AM -0800, Gwendal Grignou wrote:
> Add attribue `num_segments` to return the number of exposed LED segments
> in the lightbar. It can be smaller than the number of physical leds in
> the lightbar.
>
> Test: Check the attribute is present and returns a value when read.
Please use "platform/chrome" prefix for the commit title.
> +static ssize_t num_segments_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + uint32_t num = 0;
`./scripts/checkpatch.pl --strict`:
CHECK: Prefer kernel type 'u32' over 'uint32_t'
> + struct cros_ec_dev *ec = to_cros_ec_dev(dev);
> + int ret;
> +
> + ret = lb_throttle();
> + if (ret)
> + return ret;
> +
> + struct ec_params_lightbar *param;
> + struct ec_response_lightbar *resp;
> + struct cros_ec_command *msg;
For clarity, I prefer to move the 3 declarations before calling lb_throttle()
in the case.
> +
> + msg = alloc_lightbar_cmd_msg(ec);
> + if (!msg)
> + return -ENOMEM;
> +
> + param = (struct ec_params_lightbar *)msg->data;
> + param->cmd = LIGHTBAR_CMD_GET_PARAMS_V3;
> + msg->outsize = sizeof(param->cmd);
> + msg->result = sizeof(resp->get_params_v3);
^^^^^^ insize
> + ret = cros_ec_cmd_xfer_status(ec->ec_dev, msg);
> + if (ret < 0 && ret != -EINVAL)
> + goto exit;
> +
> + if (msg->result == EC_RES_SUCCESS) {
> + resp = (struct ec_response_lightbar *)msg->data;
> + num = resp->get_params_v3.reported_led_num;
> + }
> +
> + /*
> + * Anything else (ie, EC_RES_INVALID_COMMAND) - no direct control over
> + * LEDs, return that no leds are supported.
> + */
> + ret = 0;
> +exit:
> + kfree(msg);
> + if (ret)
> + return ret;
> + return sysfs_emit(buf, "%d\n", num);
^ `num` is an u32.
> +}
How about:
ret = sysfs_emit(buf, "%u\n", num);
exit:
kfree(msg);
return ret;
> diff --git a/include/linux/platform_data/cros_ec_commands.h b/include/linux/platform_data/cros_ec_commands.h
> index 69294f79cc88..9cbf024f56c3 100644
> --- a/include/linux/platform_data/cros_ec_commands.h
> +++ b/include/linux/platform_data/cros_ec_commands.h
> @@ -2005,6 +2005,14 @@ struct lightbar_params_v2_colors {
> struct rgb_s color[8]; /* 0-3 are Google colors */
> } __ec_todo_packed;
>
> +struct lightbar_params_v3 {
> + /*
> + * Number of LEDs reported by the EC.
> + * May be less than the actual number of LEDs in the lightbar.
> + */
> + uint8_t reported_led_num;
> +} __ec_todo_packed;
> +
> /* Lightbar program. */
> #define EC_LB_PROG_LEN 192
> struct lightbar_program {
> @@ -2086,6 +2094,8 @@ struct ec_response_lightbar {
> struct lightbar_params_v2_thresholds get_params_v2_thlds;
> struct lightbar_params_v2_colors get_params_v2_colors;
>
> + struct lightbar_params_v3 get_params_v3;
> +
> struct __ec_todo_unpacked {
> uint32_t num;
> uint32_t flags;
> @@ -2143,6 +2153,7 @@ enum lightbar_command {
> LIGHTBAR_CMD_SET_PARAMS_V2_THRESHOLDS = 31,
> LIGHTBAR_CMD_GET_PARAMS_V2_COLORS = 32,
> LIGHTBAR_CMD_SET_PARAMS_V2_COLORS = 33,
> + LIGHTBAR_CMD_GET_PARAMS_V3 = 34,
> LIGHTBAR_NUM_CMDS
> };
Haven't seen the change in
https://chromium.googlesource.com/chromiumos/platform/ec/+/refs/heads/main/include/ec_commands.h,
do we need to wait until the change landed in EC firmware?
next prev parent reply other threads:[~2026-01-26 7:13 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-24 8:58 [PATCH 1/2] chrome: lightbar: Report number of segments Gwendal Grignou
2026-01-26 7:13 ` Tzung-Bi Shih [this message]
2026-01-26 8:54 ` Gwendal Grignou
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=aXcUMXt0kN9W26PV@google.com \
--to=tzungbi@kernel.org \
--cc=chrome-platform@lists.linux.dev \
--cc=gwendal@chromium.org \
--cc=gwendal@google.com \
/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