From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E854F486E60 for ; Wed, 29 Jul 2026 13:03:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=205.220.180.131 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785330204; cv=none; b=RdZ0oi9ClL0c5S403QCyrGOZqRBw16cC88ydoE75+XbtrEU/Fw4wcxM3JqCYMWbCCDrR1eFXIlsyuxzajbe45+m6YG+o55Ny093kPzejd7eIqGoBCHOlV4jqf2tZybKW+WsdfrSVcBm+34oIkjkeNDuvTmivld6n7q7HaueWsLg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785330204; c=relaxed/simple; bh=/YeA6e4h90/TYAApBQ5RFPCojqWub7XeOGXkeguNddg=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=dl/XpxJDX5rEYsqkiOyeMRwdn++xo4/pB+lRsKsCHPyIT4iA/KwS3S96JXtHG2h1lr3Lk6xaR1cTguaX4yOpTl2xP6thyBnx3/t0cmcAvnyjJ+ZDGd3E0XPDDcc144pkTZBSnWqVm28ctooRfAyKp7dhCsJP38dthijMLuKDLrk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com; spf=pass smtp.mailfrom=oss.qualcomm.com; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b=opC6dvDf; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b=PCzr11gm; arc=none smtp.client-ip=205.220.180.131 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b="opC6dvDf"; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b="PCzr11gm" Received: from pps.filterd (m0279870.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 66TBXI3d1847259 for ; Wed, 29 Jul 2026 13:03:20 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qualcomm.com; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s=qcppdkim1; bh= tlh3rnxfJkXfV5KarGkZfL1Q3S+pBYhT9xp1RWLyIIQ=; b=opC6dvDf4y7teSIq f1gZnd7WLAx8MAXMbfxooWoZlq+OgUkKeTEFcLhao8AZlmjo8kNpYbBz+O03AtMT 89w1oWmt4iQnJkwyMKmNyW1FpJxk1Z75bSnpPhT71QOaqI0nCWCZIG7n7gZAv2YU JqDJJkLc5Mzdm/mQlq17YUTZutsubQxjumWApDHuwcWH1vAOr0NYM//2d+p4gVqd zIrWAX59UsOANgV6LQJ85bqfNh+Dltm3EFvdjtDS6KmsX3bMieEYFQ5fPbVie7UI AsdoKYZZgLjuCXn8vs5x9STsc5JBBPRjdpt2JF1KCzHRjhc3LwDCO8yOLlQ23IVL Pz0N7Q== Received: from mail-pj1-f69.google.com (mail-pj1-f69.google.com [209.85.216.69]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4fqgrcgavj-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Wed, 29 Jul 2026 13:03:19 +0000 (GMT) Received: by mail-pj1-f69.google.com with SMTP id 98e67ed59e1d1-38e7621655eso1587531a91.0 for ; Wed, 29 Jul 2026 06:03:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1785330199; x=1785934999; darn=vger.kernel.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=tlh3rnxfJkXfV5KarGkZfL1Q3S+pBYhT9xp1RWLyIIQ=; b=PCzr11gmm24eh/HiEe2HodBacW6eUyRSmHfzpznTP6RX8eVYogKP/hUsXV0izWZit8 lbwkWEG3OP4m2UzOa2gL0LieG6AVn8hQzzbIRsfwO5B0DZLm/1WvZHvrhNhHhJPfjF+C QgCaKlNYltQ7yK+0DdSN50TmK+YtvJZp2j2iPH6VJ0eFJ8pxDy9Ab7a2CW//wfkp5wsg wcAg7mi4KgD4lHgIQIKWEO2ccYLs7zDMqEsNYtKFYjrIW3ezorwTYVfZ7AO+FZZJXCZz 1rh6Q3P4iYLfbEnkCiXrgYubznQdDWEMQW8OVUXlW6NeatIlNj3ipjgkkeelD9cgqADn ZReg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785330199; x=1785934999; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=tlh3rnxfJkXfV5KarGkZfL1Q3S+pBYhT9xp1RWLyIIQ=; b=XvCWt+szmtQUxKdDXHw25bKZWkaRa2773R+M665mm3HAsTI9BtkjNK9YkYul+1QBot 6cLNIids6oS99eWIDrytMDVGK06fZDryb1Iv081M3lLV2s46s+tWOjKW0PNztScFSSrr 2dbVEIpbsRIcgkd1zcGG4Xa6fAO4RPYm7MFtq5LxtD++KC0FnkeWccTtiBxgK1RCMmcS kbUjyyYOsFj1O735VxrbJuwO7XYAP50DAbv8b8dEfh7RTRsY9g+kkgOrsr6vWtvSALc6 YH8ACvfATPHTvnjCCMOcpZ9Yr5/aykApYAWvoKgxLVC737Dkb/FuXcK0ipTMse2fMTS/ S4rg== X-Forwarded-Encrypted: i=1; AHgh+RqPbgNg64GPO9ApQHJfxpL33YUNeZeGZmbHCTMh7LENJ2bBQrIVEq9sUVDEeCzR0/ArtDmuLoXDd8/x5zw=@vger.kernel.org X-Gm-Message-State: AOJu0YxxdpK0E+nYshgf0sALhGBU8gTidA1BvHwfSro3koDYludU1geT K9xNCU5ak5pvoW2U4kD3rDSd4sfIsAWOv2IsLMHtdmXzEYaglAUkgkZGjUXEdQ9FprdQLbgPhoa NqmgCsnixtCW/7XTxbj9QDRy6K11vDTit40Sq+rtyA6ZufO8bKfddykQK+nncwL2go/k= X-Gm-Gg: AR+sD11lh2xJI+dRerCvtn8CuVo97WMr1UIVTpZvceu3/9aNdi4gOSK2OHIDBCHoWLP Z66Tf2HzaTUGyYzLrlUVBO1CArdJsAeMeOaTjDILPgh8svYtKoyoKbyJSB//BrSECv/FtpU8244 A3NV49SSRtLx+the9XsEgHGQmK6YiqO7MemYl46S05KQ1OKv7e7iwQVDrw3dd1HxOLhYdqMvPNH Jyhny3wDIzVGpH6B9xRda28k6J1GWHaIRWRcIR7N9DtyEPw/nABK5loR1PUxmK2rxkGZGKDm4WO oFOOSEb0UEgGCutbIkBYMTodQWW2DuTfNx1mRn98Jd2P5v5AwUyV49d/anHW3KgcBz6VWOA+K9P Xp6wf1EbbHSl4aHC75kP8YUreHJELAHpjF25lDyfI+au+Sj29e9gZGIXN8uc5NIgKJjQXRKhQBQ NSnYVvAfa8cVxJ X-Received: by 2002:a17:90b:55c5:b0:366:3517:1aa2 with SMTP id 98e67ed59e1d1-38f6a1b8aa0mr6429842a91.0.1785330197202; Wed, 29 Jul 2026 06:03:17 -0700 (PDT) X-Received: by 2002:a17:90b:55c5:b0:366:3517:1aa2 with SMTP id 98e67ed59e1d1-38f6a1b8aa0mr6429771a91.0.1785330196459; Wed, 29 Jul 2026 06:03:16 -0700 (PDT) Received: from [10.149.71.180] (blr-bdr-fw-01_GlobalNAT_AllZones-Outside.qualcomm.com. [103.229.18.19]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-38f642bfc71sm2710478a91.11.2026.07.29.06.03.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 29 Jul 2026 06:03:15 -0700 (PDT) Message-ID: <95133f63-c7fa-4c68-9db0-2123cf754f50@oss.qualcomm.com> Date: Wed, 29 Jul 2026 18:33:09 +0530 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/8] platform: arm64: qcom-hamoa-ec: Add SoC junction temperature reporting To: Konrad Dybcio , Sibi Sankar , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Hans de Goede , =?UTF-8?Q?Ilpo_J=C3=A4rvinen?= , Bryan O'Donoghue , Bjorn Andersson , Konrad Dybcio Cc: linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, platform-driver-x86@vger.kernel.org References: <20260728-ec_add_more_commands-v1-0-771abd65ee1a@oss.qualcomm.com> <20260728-ec_add_more_commands-v1-2-771abd65ee1a@oss.qualcomm.com> <94081897-2e6a-4c8f-bd95-1961ca843478@oss.qualcomm.com> Content-Language: en-US From: Anvesh Jain P In-Reply-To: <94081897-2e6a-4c8f-bd95-1961ca843478@oss.qualcomm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Proofpoint-GUID: FzzcSK_WwK0b-23IYSUHlbr9L6kg1L0E X-Authority-Analysis: v=2.4 cv=Id+3n2qa c=1 sm=1 tr=0 ts=6a69fa17 cx=c_pps a=vVfyC5vLCtgYJKYeQD43oA==:117 a=Ou0eQOY4+eZoSc0qltEV5Q==:17 a=IkcTkHD0fZMA:10 a=RAioF0-LDSMA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=gowsoOTTUOVcmtlkKump:22 a=gdiicE2fkixeoH3Uy70A:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=rl5im9kqc5Lf4LNbBjHf:22 X-Proofpoint-ORIG-GUID: FzzcSK_WwK0b-23IYSUHlbr9L6kg1L0E X-Proofpoint-Spam-Info: AW1haW4tMjYwNzI5MDEwOCBTYWx0ZWRfXy1iN4F2a24ob o30JDid5q0m/4644k1Mg7WNx5z3mYXSqCGcxasrDs/rMf4koK77Y1qzRCrtIBpBZ9R+8WdVW5Pf hqzdoRUxcGaiPftlMNbQqHapQ/kYXkI= X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwNzI5MDEwOCBTYWx0ZWRfXx52TpVR1vHz4 NGXonCF35/8LC6ZxWictgkCO196Oayt+BhrJbav9wc6PJipx9mMkS+u7FDPsi3pDOB9IihyXZTf j7dm/G6FYAObKdJ+MDP8Q4d3ybbZAyVdrbWmHx8wY9o4ITiGwLktmuXcybmGGnjLIFWxJTGR3PA K6iY3ojjgnuDR47xP3hwoIZSbq1Mfvn6loC8XT2zmktSAe+b59KIV43SOoWVv4N9HIk7+6Mndyb /5PD2PJXH5unzEen73yGf70b6r0IZOKEA+LgnCve5XTLPqTgLws3gIx++F7+GMi8UyoOT4vyEWm a1APNRrP3Rz1wFzTb6ymNrduqya0I+JiIGgAVxK+eOuwvJ6zDTA23kmvd+bDchz8tBHJbsBDRoV Sq3MsXUkzySIlNNzfmSBv1yvbmWvu/4L6xPw+hXhbRjCfIp8eQIOE3CgrpEItUr52rvV4TbPEd9 BExjhG05bCqsebJRwTA== X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.134,FMLib:17.12.100.49 definitions=2026-07-29_04,2026-07-28_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 phishscore=0 priorityscore=1501 impostorscore=0 suspectscore=0 clxscore=1015 adultscore=0 malwarescore=0 spamscore=0 bulkscore=0 lowpriorityscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2607290108 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