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 507E3175A89 for ; Fri, 19 Jun 2026 06:45:18 +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=1781851519; cv=none; b=PqqpOboYOP/htXaZPsYv+N5BCb9ykjP8I1iBMU1x2sVSWhR0Xr2PAkub/iVrEimrDZrcbJAE9IxTjvxnwtcg88SEtvbYC5OS/QEeRzrr9HIw+H5kaIGXu60Nsbat4W2mZO6BtS7lCLkn3G82bUcVimTv2LerfX4tM332pmOxsmc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781851519; c=relaxed/simple; bh=VvdYi542VVA8C+Q8HCRrmxb9lDjEJqxG11S2VZLN9Ek=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=b+mDkseLwr5+xwl3KvgCCCQKoNf31LcrBiKvyvq0fMbBMvmUb5yBL51t6Bd92pRTQP4QMZ0qZ3J97dzzQbA+NyqxHXoNwQfRpEFH2U7DEXEGKS2EFctu6aNiOSZeurZm0SAenYo1cTsau5wA9nQAlQsQRarDmKnnq+78RjSeyUc= 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=Bm+po5Xh; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b=Y9o1lrT9; 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="Bm+po5Xh"; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b="Y9o1lrT9" Received: from pps.filterd (m0279868.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 65J2ux0r3464665 for ; Fri, 19 Jun 2026 06:45:17 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= 6lkZ7tEMewe+zT45oVBiLxcf7tLC6xWFQ+vqhyQwRkM=; b=Bm+po5Xhdr02gEr1 0utyOZxyYcnCqf+zuae/FNkqputt/d4Qy8PTlQe1hE9Idm79RVMUxtiZJytUVYhR ZQGkK61ciehoSYLl2KLw1OexB62DIZA1JsEvo/ltHxkclM6nBq78ZCw5qImVjt0A rtV0Sw1iKz6/Oill820DYDKU6VVOr7PncQVYi3cs5sQH74Xm8UADleoxhhwH+lNT ACbtD06ey1rrChFzOBKl1Oc1oYDlUR6KiMH6CsXjy9gTYy/PJDIywCkxxDWhwxDF K1cf8JbDX1nJYF9Wx4u69+/OjtfxFaGFi0xR8wQUccWpJrLESNJx8A0HZT7aEA4C /8RgSQ== Received: from mail-pg1-f197.google.com (mail-pg1-f197.google.com [209.85.215.197]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4evp6sa6vs-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Fri, 19 Jun 2026 06:45:17 +0000 (GMT) Received: by mail-pg1-f197.google.com with SMTP id 41be03b00d2f7-c8ab01bc3d3so371501a12.1 for ; Thu, 18 Jun 2026 23:45:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1781851516; x=1782456316; darn=vger.kernel.org; h=content-transfer-encoding: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; bh=6lkZ7tEMewe+zT45oVBiLxcf7tLC6xWFQ+vqhyQwRkM=; b=Y9o1lrT9zI9oXj06DAy9463vTj8ZqVDz5zsHHOyTnnTy0Dz9VdpCDb8K74TanhM/Uy Jb2X61nL+6frF5RUojjsppZtl7bs+38mAkKQ3tZih/OKK+u/dlAcyERVuIeTvZz8rQlQ 8yd9Wz/7/MDZ3i33nM/oTy4xlUbNnq5NlsTlcto0t0r5u6tLJCcHxdAoWPUuFRyLvjQG J9bAa8brur4M9v1rBC5z9hw4a2ilU9/lgTh5e/c9E/hV+ffgiB1Y/jU0tRxL+24R52yR Qjn+h8g4I9CNuO9g7kPh0bXuU4+Uk+Otu4YRouQTzeNwVra3Nsh6OtzBJUA3Yhxq/eT9 fiaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781851516; x=1782456316; h=content-transfer-encoding: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; bh=6lkZ7tEMewe+zT45oVBiLxcf7tLC6xWFQ+vqhyQwRkM=; b=QUP8gtbj38J7LsIRP5hFvHSRYeEbczYIuJMCzPhT9nkTaOixO7AjlaxjIaLVueYfn2 pROgrsbnzHMT/cHpk3YdQPvX7w4suMX8dbvhrxBD1vEkpzyE0zhazsdLn0gfJP+85bpl H1Uj8GnGtu2DR+qw/mW0f0CxEIq7OqMgVdOh97bX6cTHMPB2m/cX/tJCN/opP7jLV9cj 3BtYUOC2jErYwkYUEuAuFfhZVfP1Rr9cn0Ac3a5IvFpqv9X/BEXXIEnubrxoONtgGQ0B FoZTJLCxh5PReb2q48ja9Zh5kaGnLkx/qeVTi3VNx+KHjaJP0DRceqKBKzMBNpkDuZnQ j8tg== X-Forwarded-Encrypted: i=1; AFNElJ9uNC36ZouGs4TqpIBQTGdAk+gkhRxqiexFK+EAyB2Puu0Z5+Oc96QLatOOkD/HnD054mYkKjdiTnxRCPg=@vger.kernel.org X-Gm-Message-State: AOJu0YyWh5otSQEZDvafsHcK9e6h2ML1SubndxkvieauCcTrlIVYfe5C O3u0h/3FfP84jnzxcf8V+54tlpYKM6oPBiNQ4fhK9Rj/SQa/j+SPXrPuevxKtUzHOsAlaFdgx4z nx1MLmzFWJiUh16Fhu/bsoprP4GSKQPNoE3/fIFzIWA/UYZz8uFNSALHuTmCoRg6bCi0= X-Gm-Gg: AfdE7cl1gPyLEaOW5DDJ5e6CV1wHDZ42xM2znME6WvO1vB0AoaojaVAuPqetXxMYVOD xy1JglOlC+TcAShQl/KH2IIRIOmUEb0Rg1Y+xDNRJrKPtIqH2UVixUkk/f/39nc34s2LomwQw0M 9JwJXGX5FP4P+N4CNBgC629NpBymLoVSm1CRncV16cj0/44xddYSUQfjie3veaFCaRN6kAzC/42 9oCfNaYfN3kVoht+Foo3v2+OJ+jGnkd72Q6wYdaBbgVxdFgrT5gsDFuXp/a2kfqhQvhCzufEclN UYRnh24jR/2vEVFC51n2x6H0aIhVuWRrOFJ5fVs7c/wqLjEwEqoxCgxdiXBkK5NlIVg8z98/QHW uWfOupdPDS2DFa4y4ybmyEKmdmcyG6jeChS9rpIzN X-Received: by 2002:a05:6a21:9092:b0:3a2:e089:ae4c with SMTP id adf61e73a8af0-3bb3364fe14mr2290187637.5.1781851515964; Thu, 18 Jun 2026 23:45:15 -0700 (PDT) X-Received: by 2002:a05:6a21:9092:b0:3a2:e089:ae4c with SMTP id adf61e73a8af0-3bb3364fe14mr2290138637.5.1781851515412; Thu, 18 Jun 2026 23:45:15 -0700 (PDT) Received: from [10.92.184.233] ([202.46.23.19]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-c8a890ad726sm1286070a12.28.2026.06.18.23.45.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 18 Jun 2026 23:45:15 -0700 (PDT) Message-ID: <487f0ed1-dfc2-4f7b-94ce-60045017a663@oss.qualcomm.com> Date: Fri, 19 Jun 2026 12:15:03 +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/2] thermal: qcom: Add support for Qualcomm MBG thermal monitoring To: Konrad Dybcio , Lee Jones , Rob Herring , Krzysztof Kozlowski , Conor Dooley , "Rafael J. Wysocki" , Daniel Lezcano , Zhang Rui , Lukasz Luba , Stephen Boyd , Jishnu Prakash , Kamal Wadhwa , Amit Kucheria , Thara Gopinath Cc: linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, Satya Priya Kakitapalli , Ajit Pandey , Imran Shaik , Taniya Das , Jagadeesh Kona References: <20260601-spmi-mbg-driver-v1-0-b4892b55a17f@oss.qualcomm.com> <20260601-spmi-mbg-driver-v1-2-b4892b55a17f@oss.qualcomm.com> <7478c540-a5fc-4238-bba0-5b04547f57c7@oss.qualcomm.com> Content-Language: en-US From: Sachin Gupta In-Reply-To: <7478c540-a5fc-4238-bba0-5b04547f57c7@oss.qualcomm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Proofpoint-GUID: O2hYJtO45xq7wV1dv4xIRtL4s6jvrXiC X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwNjE5MDA2MCBTYWx0ZWRfX1jflbVLJNmey 9/HkG5EPp/vhc44PnLNWF5Vh5KgO8o1lY6MJXzV3237wkfNv+0+ah3iRSVib2SrljIn9sHmepDw SJvyGkuK3OUwSjBQHTtmSW82EaWmzeX6U7cIwC+skP4LjXdhqiRH3+SmXDwB/TyOv3NkHOGFqC6 o7WYVw3vMrbmSEfQ8TpHC7cX8giDoZ5pqjCYt4VMMEkBHsv1PkjB6Qf5fO415bI3C7MoJZrQn0L i1R7xOBqorV7gr4BJTmb79c0iXQGdhUxcMYeq50MWGPn+it+lcpJxB38pvCtWvNHZdaG8aQsb9W XfjEQV24tjbciXP1OXw1fhgS/9yD+gAW6jqvYkGG3RBAloK49B9fTXF0XwxWVdgCz5rTQg/VCz+ 9Ym5pojzEUb90rYwZ+zj+oTwKyKAi7SdASm/bcXFM/pf/jbWfDSxffQ6mmN4xp1uHFg6QI78jRS WCQY5wQrvVauWfgPasg== X-Proofpoint-Spam-Info: AW1haW4tMjYwNjE5MDA2MCBTYWx0ZWRfX2aLY7WXghnMx zNbw9OctlLTtm+9rvxOuAMiAW6hueGs3pqYJBSCfGjYi6tWQdLlbfZJsVMMfYS6mb9u80ivM52M n9GUskGbbQxA7NbbkkOOrzXq/NeRmR4= X-Proofpoint-ORIG-GUID: O2hYJtO45xq7wV1dv4xIRtL4s6jvrXiC X-Authority-Analysis: v=2.4 cv=KbzidwYD c=1 sm=1 tr=0 ts=6a34e57d cx=c_pps a=rz3CxIlbcmazkYymdCej/Q==:117 a=j4ogTh8yFefVWWEFDRgCtg==:17 a=IkcTkHD0fZMA:10 a=FelO9ux0wxsA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=ZpdpYltYx_vBUK5n70dp:22 a=COk6AnOGAAAA:8 a=EUspDBNiAAAA:8 a=bQejZYuZTa88olzWoIwA:9 a=QEXdDO2ut3YA:10 a=bFCP_H2QrGi7Okbo017w:22 a=TjNXssC_j7lpFel5tvFf:22 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.125,FMLib:17.12.100.49 definitions=2026-06-19_01,2026-06-18_03,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 malwarescore=0 suspectscore=0 priorityscore=1501 lowpriorityscore=0 bulkscore=0 spamscore=0 impostorscore=0 adultscore=0 phishscore=0 clxscore=1015 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2606190060 On 6/16/2026 3:40 PM, Konrad Dybcio wrote: > On 6/1/26 1:01 PM, Sachin Gupta wrote: >> From: Satya Priya Kakitapalli >> >> Add driver for the Qualcomm MBG thermal monitoring device. It monitors >> the die temperature, and when there is a level 1 upper threshold >> violation, it receives an interrupt over spmi. The driver reads >> the fault status register and notifies thermal accordingly. >> >> Signed-off-by: Satya Priya Kakitapalli >> Co-developed-by: Sachin Gupta >> Signed-off-by: Sachin Gupta >> --- > > [...] > >> +static const struct mbg_map_table map_table[] = { >> + /* minT vtemp0 tc */ > > The struct is defined 2 lines above, the reader can tell the names > of the fields I will remove this in the next patch series. >> + { -60000, 4337, 1967 }, >> + { -40000, 4731, 1964 }, >> + { -20000, 5124, 1957 }, >> + { 0, 5515, 1949 }, >> + { 20000, 5905, 1940 }, >> + { 40000, 6293, 1930 }, >> + { 60000, 6679, 1921 }, >> + { 80000, 7064, 1910 }, >> + { 100000, 7446, 1896 }, >> + { 120000, 7825, 1878 }, >> + { 140000, 8201, 1859 }, >> +}; > > Please add a comment stating this map is not PMIC-specific > This table is PMIC-specific and applies only to the PM8775 MBG block. MBG is used only on PM8775 PMIC. > [...] > >> + /* The HW has a limitation that the trip set must be above 25C */ >> + if (temp > MBG_MIN_TRIP_TEMP && temp < MBG_MAX_SUPPORTED_TEMP) { >> + ret = regmap_set_bits(chip->map, chip->base + MBG_TEMP_MON2_MISC_CFG, >> + MON2_UP_THRESH_EN); >> + if (ret < 0) >> + return ret; >> + >> + ret = regmap_write(chip->map, chip->base + MON2_LVL1_UP_THRESH, >> + temp_to_vtemp_mv(temp)); >> + if (ret < 0) >> + return ret; >> + } else { >> + dev_dbg(chip->dev, "Set trip b/w 25C and 160C\n"); > > Should this be an error print, returning an error condition? > Yes, this should be treated as an error path. For out-of-range trip requests, I will return -ERANGE and update the log to an error-level message in the next patch series. >> + ret = regmap_clear_bits(chip->map, chip->base + MBG_TEMP_MON2_MISC_CFG, >> + MON2_UP_THRESH_EN); >> + return ret; >> + } >> + >> + /* >> + * Configure the last_temp one degree higher, to ensure the >> + * violated temp is returned to thermal framework when it reads >> + * temperature for the first time after the violation happens. >> + * This is needed to account for the inaccuracy in the conversion >> + * formula used which leads to the thermal framework setting back >> + * the same thresholds in case the temperature it reads does not >> + * show violation. >> + */ >> + chip->last_temp = temp + MBG_TEMP_CONSTANT; > > Will this work fine if the user tries to set the max temp supported > by the hardware (i.e. is there headroom for max+1)? > In the current implementation, temp == MBG_MAX_SUPPORTED_TEMP is not accepted (temp < MBG_MAX_SUPPORTED_TEMP), so the last_temp = temp + MBG_TEMP_CONSTANT path is never taken at absolute max. For accepted trips (strictly below max), there is headroom for the +1C adjustment. >> + >> + return ret; >> +} >> + >> +static const struct thermal_zone_device_ops mbg_tm_ops = { >> + .get_temp = mbg_tm_get_temp, >> + .set_trips = mbg_tm_set_trip_temp, >> +}; >> + >> +static irqreturn_t mbg_tm_isr(int irq, void *data) >> +{ >> + struct mbg_tm_chip *chip = data; >> + int ret, val; >> + >> + scoped_guard(mutex, &chip->lock) { >> + ret = regmap_read(chip->map, chip->base + MBG_TEMP_MON2_FAULT_STATUS, &val); >> + if (ret < 0) >> + return IRQ_HANDLED; >> + } >> + >> + if (FIELD_GET(MON_FAULT_STATUS_MASK, val) & MON_FAULT_LVL1_UPR) { >> + chip->last_thres_crossed = true; >> + dev_dbg(chip->dev, "Notifying Thermal, fault status=%d\n", val); >> + thermal_zone_device_update(chip->tz_dev, THERMAL_TRIP_VIOLATED); > > Should the assignment and this call also be guarded by the mutex? > > Konrad Yes, agreed. I will update this locking in the next patch series. Thanks, Sachin