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