From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f175.google.com (mail-pl1-f175.google.com [209.85.214.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C1A9D3254AE for ; Wed, 21 Jan 2026 10:30:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.175 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768991414; cv=none; b=SV0Cj5m+tNmDnRJOBkj5jXDBsoszcpDlycpzxlCVApoyQDyg4jsVMFLp8UNm4KgFzC1Rf02STlieG8kFXW37bOl+1yQj3qgnfhjjaqlC8mJBqta9gB3LLQ82MDBco0HlIUBLZcelGYze+FD0yeE+MQxTM4KUW8IixsYDkYNx2CU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768991414; c=relaxed/simple; bh=lW4Ce7dLJPHMTLk6Mv06UcJtVlCOaAK7+a6GWD3D3UY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=GhuS62CxgQdCZQxP6/SILg7tQ6/6ZkO1kdxRyFycuavVV2bSTJGOC0RdrwALuiZEpV5KBL0HT/TsenQUuFbOXZAg1GWuJY72htdl5u6s3b16olBeSbBgf4QWX4o3MKkvzAJjJ6AFeo0CDwGbcDV2aAYV5s8GfTCMDs/8y3ZU/LI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=an16QfGj; arc=none smtp.client-ip=209.85.214.175 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="an16QfGj" Received: by mail-pl1-f175.google.com with SMTP id d9443c01a7336-2a0d67f1877so44063675ad.2 for ; Wed, 21 Jan 2026 02:30:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768991412; x=1769596212; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=96kP93qtZ4BKG7UuG8FjtrMc+ltMMq7DIO2YZPNik6o=; b=an16QfGjhH62ozfkGermNhXaL3X0aHNc9K7g7/E8zI0sDT9dykEI6S7bD1eyjm3qhr oqfWs4jNel9mweHG65HhXMENgXt3LGetxagk9vNttUgS5dZa1EF6BuKt87ACmBgNvq9B mXEopI5CsbUEPxrzwn/I91q3YHwdaZcW7n5x27MDhmH1QoRaIVR7SgBLwOWj3GCZ2HnR iZUrIN++Hdirs0bc1My21z6mNcUH/zC8Wz5I4sCGAg0sET2dILYC82gtp3zGT71qvDwr c4iYuKzu6e+PlZ/SNPdzEmX//uFoAcivy0zm1pMeOIp6LqHvOJKuNlN2WKq2XdYcHJNx FQVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768991412; x=1769596212; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=96kP93qtZ4BKG7UuG8FjtrMc+ltMMq7DIO2YZPNik6o=; b=dcfSJ5f3sxsjG7jzKSCRv5pwJ7NJga86agdhbQA+WzeT6bvnREcCifYLh7sirJDgXS YwJcTCH7vfNgZkYG1s/FDb291chFEiE/vpa5kd01rRBdWycm3dtZdVD6M9E8jr6Y1m5Y fZvvYRrkCp8PbOLuGsn3WfeBI6uxrON2vuABy/XKXSzChUo6rdDSdtPg5mnAIOJ4P+pj f+CUyHTtzX4HYjKYcD+7sudwY2Y83IYTHKIYSfHXJfzAAzNw1EQwAQI7eJD+lKDPVTaB JcSptqsgStnGs24DK6EmzLbLiD+oSYIR1MADWlmM2T95+DooQQtwdNgsoz87peU4xcv0 CJXg== X-Forwarded-Encrypted: i=1; AJvYcCW1zTasMAVIXRMe0FbNnk5Pz8yj0kpD174Cau8IHTqaIPmKCqVCOEQwzUu2XtjjifENAit1TahlB5PNyco=@vger.kernel.org X-Gm-Message-State: AOJu0YzEpTZ2/+OvI/6s0FfBzksCnBihkolBeWMjdWPYYXCj7345Arir TOFbYVuLn4dWEj7BvkVLmVf9mNMDCXgh7CujhT57+GdLLw/rkCiZ4oyU X-Gm-Gg: AZuq6aJnY0/+BcmB1W1BwPAGzNdngmlAUgN83urdKjD6eKFv8X44VAgXKXscgviBd6b oRg4vLmh304odLRuXtmdxPM5Ob/HBYQthh3bAFrNfGxIrBns4LbQNWqXY8AMqdOYe07QP0ut2kf t8Y3oyVW4dgx2jqUQRbTjDZhjb05sJD3UcZJ0WIIWrvfU3/VlSgPqIoXqgyXBQNo1V4Y5DD9VKJ yNgCZ1Mmk3/b9zJRLrEc81M8LseBMf5fNVtI02nxxGzxcvoiTouXlMlktsGiaqCNL2q6t69XC0e aC6L3LMWIQsdHnrnlz+2TmzXgIjDXmPKzYo1XbFN4x9Go45Dcwjnr1Ub5Ael7+/D9oH8Oml/8z3 pYdpXp1Wiop/waFgBDrXsvABHZ5CMd0nJXzZDsrbikPqxfzhXDM8uM7/BP8hnci2GV//JRYnqin HClOsk9gawIz1I9htQB8A= X-Received: by 2002:a17:902:f788:b0:2a2:f465:1271 with SMTP id d9443c01a7336-2a718949948mr165766795ad.44.1768991411950; Wed, 21 Jan 2026 02:30:11 -0800 (PST) Received: from archlinux ([2405:201:1b:225c:bd87:a308:8427:d21d]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2a7193dd533sm77430885ad.66.2026.01.21.02.30.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Jan 2026 02:30:11 -0800 (PST) Date: Wed, 21 Jan 2026 16:00:07 +0530 From: Krishna Chomal To: Ilpo =?utf-8?B?SsOkcnZpbmVu?= Cc: Hans de Goede , platform-driver-x86@vger.kernel.org, LKML Subject: Re: [PATCH v5 2/2] platform/x86: hp-wmi: Add EC offsets to read Victus S thermal profile Message-ID: References: <20251218124303.22024-1-krishna.chomal108@gmail.com> <20260113182604.115211-1-krishna.chomal108@gmail.com> <20260113182604.115211-3-krishna.chomal108@gmail.com> <60c0e7ad-f25e-4e73-668b-4bb08dbbb79e@linux.intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Tue, Jan 20, 2026 at 05:10:00PM +0200, Ilpo Järvinen wrote: [snip] >> I agree that iterative EC reads are not ideal. However, since these two >> offsets (0x95 and 0x59) cover all (or almost all) known Victus/Omen layouts, >> the risk of "hoping" is low. >> >> Storing them at compile time in the victus_s array as a part of >> .driver_data is indeed the best thing. But since we do not know what EC >> layout is followed by the existing boards in the array, we can take a >> hybrid approach here: >> 1. I (and subsequent additions) will store their EC offset in the >> .driver_data field struct. >> 2. For already existing boards we will perform this iterative probe once >> during init, and store it somewhere common. >> 3. Then platform_profile_victus_s_get_ec() can simply use this "definite" >> offset to perform the EC read. > >I guess we'll have to settle to that but it likely means we'll never be >able to source those offsets because things appear "working" and therefore >cannot get rid of the extra code necessary for the EC offset iteration. > >Another alternative would be to add pr_warn() if we don't have the EC >offset yet for a board and not read anything (and hope somebody who has >one of those boards will come to us with the information or patch). > >-- > i. Hi Ilpo, That is a very fair point, if the driver just works, we would never get the actual offsets. I have adopted a stricter version for v6: 1. I removed the iterative probing entirely. 2. Added a pr_warn() in setup_active_thermal_profile_params() for unknown boards. 3. Known boards (like 8C78) now have their offsets hardcoded in the DMI table. This ensures that thermal profile readback is only enabled when we have definite hardware data. I will send v6, based on the for-next branch, shortly after thorough testing. Thanks for the guidance!