Re: [PATCH 2/8] platform: arm64: qcom-hamoa-ec: Add SoC junction temperature reporting

Anvesh Jain P <[email protected]> Fri, 31 Jul 2026 11:17:59 +0530
Newsgroups org.kernel.vger.platform-driver-x86,org.kernel.vger.linux-arm-msm,org.kernel.vger.linux-devicetree,org.kernel.vger.linux-kernel
Message-ID <[email protected]>

On 7/30/2026 10:34 PM, Konrad Dybcio wrote:
> On 7/29/26 3:03 PM, Anvesh Jain P wrote:
>>
>>
>> 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.
>>>> ---
> 
> [...]
> 
>> 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.
> 
> I hope I'm misjudging here, but if I'm going to talk to your agent
> instead of you, this is pointless..
> 
> Konrad

I do use tools to help format and reword replies faster, but the inputs
and technical decisions here are all mine.

-- 
Best Regards,
Anvesh