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 7274736C0DC for ; Thu, 13 Aug 2026 19:27:37 +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=1786649258; cv=none; b=lA1M5855MG648Mzh0ul9waWhEujIpf9xy9J5piEXlpLTtiVqvm3ZPiJyRvo21IpNu0FRrd2oMsyh+x5ztdf0IE/9G2uIRCs2ak/Md9cYSI06audHl9fTU7ZXc2glpiCMBo/byiqaaJ4x/Ps5aGuXiVo22uvaGVAmOa4E779uki0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786649258; c=relaxed/simple; bh=7a1morCh66UOrKmTjaHtFdf9M1LSa0tAMfrHTv+Ha3g=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=hoHTysVQUR+ydErmfqhRPUMSnouwzI9zdluXByr7VzRET9K+xcfhGSRsvC9tICJ22NPSbFuOm+vw3NmTTPjkSHCyMZCa6m+2gKv3SWFjG9HfS6e35YodqD4td5QFuOc0aXiTJf8C5oPwAgm7RAe2/R6onFlyWXaUVcBi5z1M60U= 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=ATjNJaV5; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b=C+SBqRwj; 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="ATjNJaV5"; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b="C+SBqRwj" 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 67DIhJlQ3476126 for ; Thu, 13 Aug 2026 19:27:36 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= D42vDXjyJMK1PmVkhCovHX+1s2WZnnUYkEVKSg7Oya0=; b=ATjNJaV543iwwvh2 j4cDvftJTH6bv1xiwM4jk+19IdUHYpXpIcXjZ9o9ETVAMWeNbcPH36nbDCsXqLze uFjVeCYX49KwGGauVZShNwK7jI8cbNhXbLbAp0Qq1ztGqRe7GKoVi81BeqcTL0OS Lgk2EnN3E/U86eh6YFLV/EkgZa158XpryGxZCeR/TWWrSYTBSmyP5IAG6QZ2H+xF cWmXK96WqDNdM/f8bK6AQ8Iq3zz6zEie1UOd/RCLoPr7Qq5BDGYjVQ/dHz7Q9b4U kVYYdhxICA7xTqRzAowSGE97woYNRUKf0D/X21tQgcEPV7KVrs03LB0hbT/g3Dn7 5Cor5g== Received: from mail-pg1-f198.google.com (mail-pg1-f198.google.com [209.85.215.198]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4g1fg3sgjy-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Thu, 13 Aug 2026 19:27:36 +0000 (GMT) Received: by mail-pg1-f198.google.com with SMTP id 41be03b00d2f7-cbee6bb8408so194505a12.3 for ; Thu, 13 Aug 2026 12:27:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1786649255; x=1787254055; 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=D42vDXjyJMK1PmVkhCovHX+1s2WZnnUYkEVKSg7Oya0=; b=C+SBqRwjAZWGeqhVD86ZtXNm/hjkJnNunPn/S6Apg2tqwYOEcW4BLWlPGk0qoCHZX1 902Ii4EzqD47zabei44S/qs61eVkpCpEjeZE6cEyxAEzfuNr5Xxf+tzReJ1c8tSorNGE zgEDfn/LrZ03GS16tBy/dMSDe/UlXO+GzHErpPHNCwzOmM8LbjEmqfx4+lZRVbhLL4Xs 41K6P5qVDI5zrq62fEF+DPFc5UH3lB9SJEXl5i3U7Vap6UGtgokvFQwpJQYJRMekGHe0 FRh36vSGZr6N/MInksuK2ztouWAIpfx/Io8oDUWz7O3OVfenVhmVi8tzf9k55v6iGSrj SU6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786649255; x=1787254055; 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=D42vDXjyJMK1PmVkhCovHX+1s2WZnnUYkEVKSg7Oya0=; b=StngGZgXZJoxyboy67IRiywKiNVaoU61jzM9rItpL5pbb4q0gKj/h+04fseDe04yrj /eV2Juz6iYt/8J6+D0Lsmkxqz6cI/5pMg8+grVrQkukRrJEn5hjosiDcKohE46G0wQgx D7cqtgMRks7/f/obvnNjNEOE6HNbwCBWxC/Hct0Y6jNMumtv3BlK5Jm0Ogfu2XfVZg0l 9+iBnXEerZ4TDHuS4siZQklLbu+swnIafj9eq+1LwW+/FMntL+J9itTzgemhcE3eZIpV jQkWW4SKh7ggFtZnLgs0+h7QDFAsn4dyCrYH6mOQ51AJETEAw8QC5OwNCFluQzMcP4jk 2Y7Q== X-Forwarded-Encrypted: i=1; AHgh+RpwRjSgTS7zBstYc0RWA2oMkdWkdiqYvwQB7xJ+jE9MGto/x4pnN+lIl16rAbf1Px78gGd4MgUza92QJQo=@vger.kernel.org X-Gm-Message-State: AOJu0YyySdpNt89OscDMB5pWL0OL8E3kotgYkBkoZmsAQHznZlQegvt2 MHEE5i4PI5r3GE+KPOOBU38Fx1/kUnxqiD9mNBfoz1NawPfyJEFhGD47IDfcMTbRs9owkxF83R2 OK5pvQzAegcylTSflJqSH3nc7ZOaZfa4md8CoPHYfAk4edIT0DS4D9wdBWRgAiVAAGKg= X-Gm-Gg: AR+sD13c1GZRVToCaDoOWYkeUwFnp0G1/aWRXbXiTIr7OYaCQ7ew0E1R23OVNC7I8RQ THzfoOKSzCFXAmreH0fQbDOe/IcafSKiL9Pexw6Yr1CfE5TcYWm4uOIcYxw216pgxtHpyd186gH M+s99leeV4+m1ds2zhasdu1wC3yd+ZlyATFJdh38wDfOI8Tc5/l9rNPi51AeC/A6nTkgi6f5Hhi n7Q1RFJ5T90XyciEy4iQEeyfHrPkhvH9rE2HnkB0BL/wfxTqxxCRCIfT7FkaG+9A+FvVnfmhrHH x/MtvOCrOYcmMB/RC/HTd3pno/F9Ero8+FqASZOSKoHkbn26m5okyqYK0lLE+mA+lJN3X123gm3 YPFOuKuYbCY50tbIwXJDm3lHZpj1R2iQ9 X-Received: by 2002:a05:6a20:6a1f:b0:3c6:61b9:917c with SMTP id adf61e73a8af0-3cc71ced6e0mr46761637.11.1786649255139; Thu, 13 Aug 2026 12:27:35 -0700 (PDT) X-Received: by 2002:a05:6a20:6a1f:b0:3c6:61b9:917c with SMTP id adf61e73a8af0-3cc71ced6e0mr46684637.11.1786649254456; Thu, 13 Aug 2026 12:27:34 -0700 (PDT) Received: from [192.168.2.2] ([49.204.16.42]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-31ec002e857sm11727043eec.23.2026.08.13.12.27.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 13 Aug 2026 12:27:34 -0700 (PDT) Message-ID: Date: Fri, 14 Aug 2026 00:57:27 +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 v2 02/10] hwmon: Add Qualcomm PMIC BCL driver To: Guenter Roeck , Daniel Lezcano , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Lee Jones , Stephen Boyd , Bjorn Andersson , Konrad Dybcio Cc: linux-hwmon@vger.kernel.org, linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, mfd@lists.linux.dev, Gaurav Kohli References: <20260722-qcom-bcl-hwmon-v2-0-febe2805e17b@oss.qualcomm.com> <20260722-qcom-bcl-hwmon-v2-2-febe2805e17b@oss.qualcomm.com> <373bd00e-bfcd-4f6c-b64e-a707af01417c@roeck-us.net> <4f2d9c51-1059-489c-a469-562ec52015da@roeck-us.net> <24a0ac2f-792e-4296-949c-047d9ce1c1f3@oss.qualcomm.com> <3635cd34-4c11-40fe-a9ff-48b752fb5150@roeck-us.net> <5861906e-2969-4849-b9ec-ff6c7df65dad@oss.qualcomm.com> <66979a1d-d92c-43b2-892d-cd73b6585509@roeck-us.net> Content-Language: en-US From: Manaf Meethalavalappu Pallikunhi In-Reply-To: <66979a1d-d92c-43b2-892d-cd73b6585509@roeck-us.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Authority-Analysis: v=2.4 cv=NsfhtcdJ c=1 sm=1 tr=0 ts=6a7e1aa8 cx=c_pps a=Qgeoaf8Lrialg5Z894R3/Q==:117 a=BvtW7Q8lqb1UdYndl6lHrw==:17 a=IkcTkHD0fZMA:10 a=Sv0fKeRqtYgA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=ZpdpYltYx_vBUK5n70dp:22 a=VwQbUJbxAAAA:8 a=_jlGtV7tAAAA:8 a=tUoij1vsQbLQIl3R9WQA:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=x9snwWr2DeNwDh03kgHS:22 a=nlm17XC03S6CtCLSeiRr:22 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwODEzMDE0MSBTYWx0ZWRfX7Nv07OPX8nM4 IMM8ldNm1fGE+toSrji5DTDFR9Dtp996OK3yKMsx/CpKL16Ikt3mBMEtXHhDBznmSlbTFayQFYU NOeiPXVXxsZUtEu12Q63j+IVqT/GSg4KaY78WHmHq+dSziStPepfP27uEyV9JCnFugwA8m/tAaK RRePHW0pmb5L7N1PSFCOB6DgGpqjwrzho4YFtN+8OUrlKn7yHGixr4zuBC5gWRazXLZCK0PLgMk 6e4hk/LdDoVNqw6CqxmUVBD6TQ8oaXy4km4GpT0r1n0Dh4GnShMT7bvSSoer0gGTyUMwvWWzkH5 j/jOGQFAo9F4Gi0Hw7ETAM2UpZFLZUnJw13P+8KrsuiTC8aunUE4a9g+c8dCodr1X1Be9JhMUOV JcEZW+M9Dcm2ckIDN/kp7rEzuLFe5RBGyJlKcpm48VPOrPGWAkueZ9U+SMzC9XY3O3k11xE0WKD 9IEdtyWHS3STmwg+s/A== X-Proofpoint-ORIG-GUID: ZuGmKLzdj3w9bBy54Cy6fhHqSFr-Erol X-Proofpoint-GUID: ZuGmKLzdj3w9bBy54Cy6fhHqSFr-Erol X-Proofpoint-Spam-Info: AW1haW4tMjYwODEzMDE0MSBTYWx0ZWRfX1TVTJiLznCH3 zL6ysJ4eOeZZIEGqpw7J5nfgA3KEihaRP6M3W5fDMBE3VJ1MjgzmmjJfTzraEJsHsogd3tyKmBq OgidNhI3atohfz+WxruH9YOSqPk0YVI= X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49 definitions=2026-08-13_06,2026-08-12_01,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 phishscore=0 lowpriorityscore=0 spamscore=0 bulkscore=0 adultscore=0 clxscore=1015 priorityscore=1501 malwarescore=0 suspectscore=0 impostorscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2608130141 Hi Guenter, On 7/30/2026 8:47 PM, Guenter Roeck wrote: > On 7/30/26 04:48, Daniel Lezcano wrote: >> On 7/24/26 02:04, Guenter Roeck wrote: >>> On 7/23/26 12:16, Manaf Meethalavalappu Pallikunhi wrote: >>>> Hi Guenter, >>>> >>>> On 7/23/2026 12:29 AM, Guenter Roeck wrote: >>>>> On 7/22/26 11:19, Manaf Meethalavalappu Pallikunhi wrote: >>>>>> Hi Guenter, >>>>>> >>>>>> On 7/22/2026 11:16 PM, Guenter Roeck wrote: >>>>>>> On 7/22/26 10:38, Manaf Meethalavalappu Pallikunhi wrote: >>>>>>> ... >>>>>>>>> >>>>>>>>> I am curious: Why not use static initialization and use the >>>>>>>>> is_visible >>>>>>>>> function to determine if an attribute is visible or not ? >>>>>>>> >>>>>>>> ACK. There is already a comment in v1 suggesting the use of >>>>>>>> dynamic allocation based on the available attributes rather than >>>>>>>> static initialization. The intent is to avoid having to perform >>>>>>>> enable flag checks in multiple places. >>>>>>>> . > >>>>>>> >>>>>>> You lost me, sorry. There is only a single is_visible function, >>>>>>> and its intent is exactly to handle situations where some sensors >>>>>>> are not always available. >>>>>>> >>>>>>> What would be those "multiple places" ? >>>>>> >>>>>> Understood, thanks for the clarification. I'll revert to static >>>>>> attribute initialization in the next revision and use is_visible() >>>>>> to control attribute visibility where needed. >>>>>> >>>>>>> >>>>>>>>>  From the earlier exchange I had the impression that there is a >>>>>>>>> large >>>>>>>>> number of current and voltage channels, but it looks like there >>>>>>>>> is only >>>>>>>>> one each. That doesn't really warrant or need all this dynamic >>>>>>>>> code >>>>>>>> >>>>>>>> Yes, this hardware only supports one or two channels (voltage >>>>>>>> and current). What we discussed earlier was that each channel >>>>>>>> can have up to three threshold alarms (warning, critical, and >>>>>>>> emergency). However, the hwmon framework currently supports only >>>>>>>> two limit alarms for these sensor types. I have not added >>>>>>>> support for the third alarm threshold in this series to keep the >>>>>>>> initial driver support aligned with the existing hwmon >>>>>>>> capabilities. Once the basic driver support is accepted, I can >>>>>>>> queue a follow-up series to add support for the third limit alarm. >>>>>>>> >>>>>>> >>>>>>> What does that have to do with attribute visibility ? >>>>>> >>>>>> I was only clarifying that the channel count has always been small >>>>>> (maximum of two channels) and has not changed since v1. The >>>>>> earlier discussion was primarily around the limit alarm >>>>>> attributes. That said, you're right that this is unrelated to >>>>>> attribute visibility. >>>>>> >>>>> >>>>> Feel free to use (and test) >>>>> https://lore.kernel.org/linux-hwmon/20260722185749.2313572-1- >>>>> linux@roeck-us.net/T/#u >>>> >>>> Thanks for working on this. I'll use that change as the base, rebase >>>> my series on top of it, and add support for the third alarm level. >>>> By the way, for the voltage channel, the hardware monitors >>>> undervoltage conditions and provides three threshold levels. At the >>>> moment, I am mapping: >>>> >>>> LVL0 → min >>>> LVL1 → lcrit >>>> >>>> For LVL2, would it be possible to introduce a corresponding low- >>>> voltage emergency threshold, such as lemergency (or another more >>>> appropriate name), to represent the third alarm level for voltage >>>> sensors ? >>>> >>> >>> We can, but I really have no idea how to name it. lcrit is bad enough, >>> but lemergency is even worse (or at least I think so). "lemerg" would >>> be almost as bad, but at least it would kind of match "lcrit". >>> I tried to ask Google AI, but it didn't give me any useful ideas. >>> Any other suggestions or ideas ? >> >> 'lfatal' ? >> After thinking about it, I'll stick with "lemergency", reason being that > it matches >     crit -> lcrit >     emergency -> lemergency I pulled in your patch [1] and extended the implementation to add lemergency support for the in sensor type. I validated the third-limit alarm support for both in and curr sensors. The resulting sysfs interface now looks as follows: /sys/class/hwmon/hwmon1# ls curr1_crit curr1_emergency_alarm curr1_max device in0_lcrit in0_lemergency in0_min name power uevent curr1_crit_alarm curr1_input curr1_max_alarm in0_input in0_lcrit_alarm in0_lemergency_alarm in0_min_alarm of_node subsystem [1] https://lore.kernel.org/all/20260722192547.619281F000E9@smtp.kernel.org/ Could you please update your series to add lemergency support for the in sensor type as well ? Thanks, Manaf > > Guenter >