From: Anvesh Jain P <anvesh.p@oss.qualcomm.com>
To: "Konrad Dybcio" <konrad.dybcio@oss.qualcomm.com>,
"Sibi Sankar" <sibi.sankar@oss.qualcomm.com>,
"Rob Herring" <robh@kernel.org>,
"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
"Conor Dooley" <conor+dt@kernel.org>,
"Hans de Goede" <hansg@kernel.org>,
"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
"Bryan O'Donoghue" <bryan.odonoghue@linaro.org>,
"Bjorn Andersson" <andersson@kernel.org>,
"Konrad Dybcio" <konradybcio@kernel.org>
Cc: linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
platform-driver-x86@vger.kernel.org
Subject: Re: [PATCH 2/8] platform: arm64: qcom-hamoa-ec: Add SoC junction temperature reporting
Date: Wed, 29 Jul 2026 18:33:09 +0530 [thread overview]
Message-ID: <95133f63-c7fa-4c68-9db0-2123cf754f50@oss.qualcomm.com> (raw)
In-Reply-To: <94081897-2e6a-4c8f-bd95-1961ca843478@oss.qualcomm.com>
On 7/29/2026 4:29 PM, Konrad Dybcio wrote:
> On 7/28/26 7:44 PM, Anvesh Jain P wrote:
>> Add the EC command definitions and handler function for reporting the
>> SoC junction temperature (Tj) to the EC.
>>
>> Discover the platform's thermal sensor to zone mapping via the
>> qcom,tsens device tree property, average the junction temperatures
>> across the mapped zones, and periodically report the result to the EC
>> over SMBus using a delayed work item. Serialize this and the existing
>> EC command sequences (firmware version read, thermal capability read,
>> SCI event control, and the SCI IRQ handler) under a new io_lock mutex,
>> since the delayed work item now runs concurrently with those paths.
>>
>> Re-arm the periodic report on resume and cancel it on suspend to avoid
>> racing with the modern standby transition.
>> ---
>
> Missing sign-off, have you run b4 prep --check?
>
Thanks for reviewing my series.
Ack, I missed to add sign-off while splitting the patches. I verified b4
prep --check did pass clean here. Will add the trailer in v2.
> [...]
>
>
>> + mutex_lock(&ec->io_lock);
>> ret = qcom_ec_read(ec, EC_FW_VERSION_CMD, EC_FW_VERSION_RESP_LEN, resp);
>> + mutex_unlock(&ec->io_lock);
>
> Does it make more sense to simply stick a guard(mutex)(&ec->io_lock)
> at the beginning of qcom_ec_read()?
>
For this call site it'd be equivalent, but a few other callers (e.g.
qcom_ec_update_profile_from_power_supply(), qcom_ec_fan_calibrate())
hold io_lock across multiple qcom_ec_read()/qcom_ec_write() calls plus
state checks in between, for atomicity. Pushing the lock into
qcom_ec_read()/qcom_ec_write() themselves would self-deadlock those
callers unless their outer locking is also removed, which would then
narrow the lock scope to a single command and break that atomicity.
Keeping it at the call site here for consistency with the rest of the file.
> [...]
>
>> +static struct thermal_zone_device *
>> +qcom_ec_sensor_to_zone(struct device_node *sensor_np, u32 sensor_id)
>> +{
>> + struct device_node *tz_np __free(device_node) =
>> + of_find_node_by_name(NULL, "thermal-zones");
>> +
>> + if (!tz_np)
>> + return ERR_PTR(-ENODEV);
>> +
>> + for_each_available_child_of_node_scoped(tz_np, child) {
>> + struct of_phandle_args args;
>> +
>> + if (of_parse_phandle_with_args(child, "thermal-sensors",
>> + "#thermal-sensor-cells", 0, &args))
>> + continue;
>> +
>> + of_node_put(args.np);
>> +
>> + if (args.np == sensor_np &&
>> + sensor_id == (args.args_count ? args.args[0] : 0))
>> + return thermal_zone_get_zone_by_name(child->name);
>> + }
>
> I'm not sure that's the intended use of the API, but this is NHI
> of_thermal_zone_find()
>
You're right, this duplicates of_thermal_zone_find()'s algorithm almost
exactly. It's static in drivers/thermal/thermal_of.c though, so it's not
callable from here as-is — keeping the local copy rather than touching
that file.
> [...]
>
>> +static void qcom_ec_sci_evt_disable(void *data)
>> +{
>> + struct device *dev = data;
>> + int ret;
>> +
>> + ret = qcom_ec_sci_evt_control(dev, false);
>> + if (ret < 0)
>> + dev_err(dev, "Failed to disable SCI events: %d\n", ret);
>> }
>
> This should be a separate fix. FWIW suspending and resuming on
> linux-next/master currently gives me:
>
> [ 43.754787] geni_i2c a84000.i2c: error turning SE resources:-13
> [ 43.754811] qcom-hamoa-ec 3-0076: Failed to read EC SCI Event: -13
>
> Konrad
Agreed, will split the devm_add_action_or_reset() conversion into its
own commit — it's an independent correctness fix (also disables SCI
events on partial probe failure, not just on remove()), unrelated to SoC
Tj reporting.
On the -13 during suspend/resume: that looks like the SCI IRQ firing (or
its threaded handler still running) while the I2C SE resources are down
for suspend. Will dig into whether the IRQ needs to be quiesced/disabled
around suspend/resume here and follow up.
--
Best Regards,
Anvesh
next prev parent reply other threads:[~2026-07-29 13:03 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-28 17:44 [PATCH 0/8] Extend Qualcomm reference device EC driver with fan LUT, profile and SoC Tj support Anvesh Jain P
2026-07-28 17:44 ` [PATCH 1/8] dt-bindings: embedded-controller: qcom,hamoa-crd-ec: Add qcom,tsens Anvesh Jain P
2026-07-28 17:54 ` sashiko-bot
2026-07-29 11:08 ` Krzysztof Kozlowski
2026-07-29 11:54 ` Anvesh Jain P
2026-07-29 12:32 ` Krzysztof Kozlowski
2026-07-29 13:00 ` Anvesh Jain P
2026-07-29 11:13 ` Konrad Dybcio
2026-07-29 12:13 ` Anvesh Jain P
2026-07-28 17:44 ` [PATCH 2/8] platform: arm64: qcom-hamoa-ec: Add SoC junction temperature reporting Anvesh Jain P
2026-07-28 18:02 ` sashiko-bot
2026-07-29 10:59 ` Konrad Dybcio
2026-07-29 13:03 ` Anvesh Jain P [this message]
2026-07-28 17:44 ` [PATCH 3/8] platform: arm64: qcom-hamoa-ec: Switch fan profile based on power supply state Anvesh Jain P
2026-07-28 18:05 ` sashiko-bot
2026-07-29 11:02 ` Konrad Dybcio
2026-07-30 6:21 ` Anvesh Jain P
2026-07-28 17:44 ` [PATCH 4/8] platform: arm64: qcom-hamoa-ec: Add fan RPM query and LUT calibration Anvesh Jain P
2026-07-28 18:15 ` sashiko-bot
2026-07-29 11:07 ` Konrad Dybcio
2026-07-30 6:35 ` Anvesh Jain P
2026-07-28 17:44 ` [PATCH 5/8] platform: arm64: qcom-hamoa-ec: Verify required I2C adapter functionality Anvesh Jain P
2026-07-28 18:14 ` sashiko-bot
2026-07-29 11:08 ` Konrad Dybcio
2026-07-30 6:37 ` Anvesh Jain P
2026-07-28 17:44 ` [PATCH 6/8] platform: arm64: qcom-hamoa-ec: Retry I2C transfers on NACK Anvesh Jain P
2026-07-28 18:26 ` sashiko-bot
2026-07-29 11:11 ` Konrad Dybcio
2026-07-30 6:40 ` Anvesh Jain P
2026-07-28 17:44 ` [PATCH 7/8] arm64: dts: qcom: x1p42100-crd: Add qcom,tsens for EC fan thermal management Anvesh Jain P
2026-07-28 18:26 ` sashiko-bot
2026-07-28 17:44 ` [PATCH 8/8] arm64: dts: qcom: x1e80100-crd: " Anvesh Jain P
2026-07-28 18:36 ` sashiko-bot
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=95133f63-c7fa-4c68-9db0-2123cf754f50@oss.qualcomm.com \
--to=anvesh.p@oss.qualcomm.com \
--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=konrad.dybcio@oss.qualcomm.com \
--cc=konradybcio@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--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