From: Stephan Gerhold <stephan.gerhold@linaro.org>
To: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
Cc: robh@kernel.org, krzk+dt@kernel.org, andersson@kernel.org,
konradybcio@kernel.org, bryan.odonoghue@linaro.org,
ilpo.jarvinen@linux.intel.com, hansg@kernel.org,
conor+dt@kernel.org, linux-arm-msm@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
platform-driver-x86@vger.kernel.org,
Maya Matuszczyk <maccraft123mc@gmail.com>
Subject: Re: [PATCH V3 2/5] platform: arm64: Add driver for EC found on Qualcomm reference devices
Date: Mon, 9 Mar 2026 10:03:21 +0100 [thread overview]
Message-ID: <aa6M2QSXW72xqYiB@linaro.org> (raw)
In-Reply-To: <20260308233646.2318676-3-sibi.sankar@oss.qualcomm.com>
On Mon, Mar 09, 2026 at 05:06:43AM +0530, Sibi Sankar wrote:
> Add Embedded controller driver support for Hamoa/Purwa/Glymur qualcomm
> reference boards. It handles fan control, temperature sensors, access
> to EC state changes and supports reporting suspend entry/exit to the
> EC.
>
> Co-developed-by: Maya Matuszczyk <maccraft123mc@gmail.com>
> Signed-off-by: Maya Matuszczyk <maccraft123mc@gmail.com>
> Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
> ---
> MAINTAINERS | 7 +
> drivers/platform/arm64/Kconfig | 12 +
> drivers/platform/arm64/Makefile | 1 +
> drivers/platform/arm64/qcom-hamoa-ec.c | 462 +++++++++++++++++++++++++
> 4 files changed, 482 insertions(+)
> create mode 100644 drivers/platform/arm64/qcom-hamoa-ec.c
>
> [...]
> diff --git a/drivers/platform/arm64/qcom-hamoa-ec.c b/drivers/platform/arm64/qcom-hamoa-ec.c
> new file mode 100644
> index 000000000000..83aa869fad8f
> --- /dev/null
> +++ b/drivers/platform/arm64/qcom-hamoa-ec.c
> @@ -0,0 +1,462 @@
> [...]
> +static int qcom_ec_read(struct qcom_ec *ec, u8 cmd, u8 resp_len, u8 *resp)
> +{
> + int ret;
> +
> + mutex_lock(&ec->lock);
> + ret = i2c_smbus_read_i2c_block_data(ec->client, cmd, resp_len, resp);
> + mutex_unlock(&ec->lock);
This mutex looks redundant to me for the current implementation. You
don't have any read-modify-write sequences and I think the I2C core
already has internal locking for the bus itself.
> [...]
> +/*
> + * Fan Debug control command:
> + *
> + * Command Payload:
> + * ------------------------------------------------------------------------------
> + * | Offset | Name | Description |
> + * ------------------------------------------------------------------------------
> + * | 0x00 | Command | Fan control command |
> + * ------------------------------------------------------------------------------
> + * | 0x01 | Fan ID | 0x1 : Fan 1 |
> + * | | | 0x2 : Fan 2 |
> + * ------------------------------------------------------------------------------
> + * | 0x02 | Byte count = 4| Size of data to set fan speed |
> + * ------------------------------------------------------------------------------
> + * | 0x03 | Mode | Bit 0: Debug Mode On/Off (0 - OFF, 1 - ON ) |
> + * | | | Bit 1: Fan On/Off (0 - Off, 1 - ON) |
> + * | | | Bit 2: Debug Type (0 - RPM, 1 - PWM) |
> + * ------------------------------------------------------------------------------
> + * | 0x04 (LSB) | Speed in RPM | RPM value, if mode selected is RPM |
> + * | 0x05 | | |
> + * ------------------------------------------------------------------------------
> + * | 0x06 | Speed in PWM | PWM value, if mode selected is PWM (0 - 255) |
> + * ______________________________________________________________________________
> + *
> + */
> +static int qcom_ec_fan_set_cur_state(struct thermal_cooling_device *cdev, unsigned long state)
> +{
> + struct qcom_ec_cooling_dev *ec_cdev = cdev->devdata;
> + struct device *dev = ec_cdev->parent_dev;
> + struct i2c_client *client = to_i2c_client(dev);
> +
> + u8 request[6] = { ec_cdev->fan_id, EC_FAN_SPEED_DATA_SIZE,
> + EC_FAN_DEBUG_MODE_ON | EC_FAN_ON | EC_FAN_DEBUG_TYPE_PWM,
> + 0, 0, state };
> + int ret;
> +
> + ret = i2c_smbus_write_i2c_block_data(client, EC_FAN_DBG_CONTROL_CMD,
> + sizeof(request), request);
I think it's nice to provide users a way to override the fan speed, but
is this really the main interface of the EC that we want to use for
influencing the fan speed?
As the name of the command suggests, this is a debug command that
essentially overrides the internal fan control algorithm of the EC. If
you use this to turn the fan off and then Linux hangs, I would expect
that the fan stays off until the device will eventually overheat.
I think it would be more reliable if:
(1) The default mode of operation does not make use of the "debug mode"
command and instead sends the internal SoC temperatures to the EC
to help optimize the fan control. (This is what Windows does on
Hamoa, not sure if this is still needed on Glymur?)
(2) If we provide a way to enable the fan control debug mode, there
should be also a way to disable it again at runtime (with
EC_FAN_DEBUG_MODE_OFF).
Thanks,
Stephan
next prev parent reply other threads:[~2026-03-09 9:03 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-08 23:36 [PATCH V3 0/5] Add driver for EC found on Qualcomm reference devices Sibi Sankar
2026-03-08 23:36 ` [PATCH V3 1/5] dt-bindings: embedded-controller: Add EC bindings for " Sibi Sankar
2026-03-09 7:23 ` Krzysztof Kozlowski
2026-03-09 11:35 ` Sibi Sankar
2026-03-09 21:06 ` Dmitry Baryshkov
2026-03-10 5:10 ` Sibi Sankar
2026-03-08 23:36 ` [PATCH V3 2/5] platform: arm64: Add driver for EC found on " Sibi Sankar
2026-03-09 9:03 ` Stephan Gerhold [this message]
2026-03-09 10:04 ` Sibi Sankar
2026-03-09 11:47 ` Konrad Dybcio
2026-03-09 11:55 ` Stephan Gerhold
2026-03-09 12:10 ` Konrad Dybcio
2026-03-10 4:58 ` Sibi Sankar
2026-03-16 10:33 ` Konrad Dybcio
2026-03-10 6:18 ` kernel test robot
2026-03-10 6:29 ` kernel test robot
2026-03-08 23:36 ` [PATCH V3 3/5] arm64: dts: qcom: glymur-crd: Add Embedded controller node Sibi Sankar
2026-03-08 23:36 ` [PATCH V3 4/5] arm64: dts: qcom: x1-crd: " Sibi Sankar
2026-03-09 7:25 ` Krzysztof Kozlowski
2026-03-09 9:03 ` Sibi Sankar
2026-03-09 9:09 ` Krzysztof Kozlowski
2026-03-09 10:51 ` Sibi Sankar
2026-03-09 10:53 ` Krzysztof Kozlowski
2026-03-09 11:48 ` Konrad Dybcio
2026-03-10 7:10 ` Krzysztof Kozlowski
2026-03-09 11:50 ` Sibi Sankar
2026-03-09 21:13 ` Dmitry Baryshkov
2026-03-10 5:11 ` Sibi Sankar
2026-03-10 9:45 ` Konrad Dybcio
2026-03-08 23:36 ` [PATCH V3 5/5] arm64: dts: qcom: hamoa-iot-evk: " Sibi Sankar
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=aa6M2QSXW72xqYiB@linaro.org \
--to=stephan.gerhold@linaro.org \
--cc=andersson@kernel.org \
--cc=bryan.odonoghue@linaro.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=hansg@kernel.org \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=konradybcio@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maccraft123mc@gmail.com \
--cc=platform-driver-x86@vger.kernel.org \
--cc=robh@kernel.org \
--cc=sibi.sankar@oss.qualcomm.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