From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-f171.google.com (mail-pg1-f171.google.com [209.85.215.171]) (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 A06123D47A0 for ; Wed, 1 Apr 2026 12:04:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.171 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775045046; cv=none; b=YUx7C/FmnR5fT9PgWRnzH9yue44Z9CySfENwPbKS9NYe8qtjNPnU5LNsT5CvCt1vDjO+wYuO4YvlCG/92uYatfot6MxJU8T+taC2mES5ajSoNETxukLi2/2TYKhXLeBSzAt2jCi9qoaHiCGPwGHgF+N3TGmpDc62asktZiwlXFI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775045046; c=relaxed/simple; bh=irgH7TFKWsCQd+BMrX30N75UFfoSW1iaBqVHxmkQ8sg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=AY9x3bPJyBMIFxKcxG2Ro9YwqwdE7HEgbgSEtfdW/AInIv6/1PkFaiZlEhZ413kL1r8epqEiJSfLuVYnEZ4D824FscvptDbCub9sGusWyMPwg8xm4YKJzckxDfYlrw8LJUWS6OTplRR8tZkuCmpBjU54fEAk3kjxXkiKI1VOiGA= 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=SgRC//do; arc=none smtp.client-ip=209.85.215.171 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="SgRC//do" Received: by mail-pg1-f171.google.com with SMTP id 41be03b00d2f7-c06cb8004e8so2733823a12.0 for ; Wed, 01 Apr 2026 05:04:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1775045044; x=1775649844; 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=eZE0lWI868d7gL9thsanG/G7YM/a6IZbtCTZVwOfg+c=; b=SgRC//doVlTDDlmUVL0zezNIj8e5w+lKF4Im7gMO0c4Ach5MTAjvJDUQntiaXDFOv5 8qdi4OQ/G0g28rWWXm1Vxv0laQ4XN4ll4RI2v3VXrIr6viHopfUEMjvoIWAKGRH+4sYr n+wVwsK5i7KU+JAEowEYZcK5zo8OadKoXbb+5TjGjgkz1L6I7AjoKDoTYJNd79T+VtvO EQGSuejX/raMH8SUEsLnB5aWVPvkWt2sHucPtOJa2dMugrvaHAPmhDUEELRg/TpVrj3r /09J5o4nhsbIOEWIp7UNMO09Ny84Rq+YbWKyVFZYUoRBUb7KrzpNu2YpGuAT48GdnAX1 tlOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775045044; x=1775649844; 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=eZE0lWI868d7gL9thsanG/G7YM/a6IZbtCTZVwOfg+c=; b=Yym3ys51A2MAUR89j32xE075gVVb/z9xddf/JOeSr5NVefOgb+ubF9Z1TusSdCOgvC mt5B+F6+akcjqCc5xpBEDuTJEqrIFGsmeQ7wEFOxGOEeHagmTU40aMi76QXTo2lQtkyN ehQKxBo9uEAb+i9g1szPJa7CkS3gBQLKNjxeW5kL3uruYmL1njUy3lCAuS4RRYW8eu33 Vz5d+/vKuDZS3mehCtX9FJlyC0g0AxMG6YyhOKm5tryo6qYtlBTQwYZ+rxfdW/S7FmPd 2x6u56EQtqWM0f18cPZ4JPt7Uk8UF74YiSCqjnHSFrSX25eeDettIIQ/XFtAv6McWMER TJNA== X-Forwarded-Encrypted: i=1; AJvYcCXrvQ0ek1NtEoeIdAZBQubCguzdT0AqMPoaCzRyZRWLVZcGusg9GzXolE8LSP05+3lDMk4fvy5h4AUVqW8=@vger.kernel.org X-Gm-Message-State: AOJu0YxjNzI6d0oxK0AX+xuzx3llad6FhI0UTb5w6EivnS9FT9QLd5nC ypHl0jAHPfqzbc1DgR+cEEX5nvaqfaqPf3jUDRwzd/kk5Jgx5rdGhxcK X-Gm-Gg: ATEYQzwVCkxGda9nPfGHd2sXsWYJnTRQvDBqu7+8MXmxREdtPJN8tGOjRnI/gspFPe4 UlEghZ1GPwlYwQbWTYBOpQPUfC5XqhiY+2i8wVZFCViyajNUmYtdVvP7P2EeVoKyO1bas8GTNQn eE/06YOBIpqXQsQIJVvziJzZSyTOI2RM28OszCGUhPGEUqStHUhqqzb+w62dzic1VjjF/ZK5drI G1LKafWpKU0h+KeGX20MuwWH7qWleU0ihKylJdp/IdMarWmn6pg4imz+wXlwXvLZua1H2e/Qo+o z82p7ZnRUbpLkRccEqTboBmGwsfcoHWJcrKHIeb/+iSMjdXbMnJDTNiBnDBvv1hvplG6sxzRfP/ fvUO7GXs/6VVtDWBS3C1kH11GnO/EcmTENmPfR+Qn9i6TFpGfwzx6+pGZxlvdKZ13S1vAAxdHpj ejJZCezMP3v/44SQEYpr5pe13GYcXe6OfPiORRa2e7YZUnOf6xqy7smd/QEP4dAp5xx+KMh3kqE kpEdDtIeOw2oaG20ZBR X-Received: by 2002:a17:903:8d0:b0:2b0:4579:ae6 with SMTP id d9443c01a7336-2b269c88bf4mr35049565ad.38.1775045044009; Wed, 01 Apr 2026 05:04:04 -0700 (PDT) Received: from archlinux ([2405:201:1b:225c:eb9d:1fc0:f95c:bd90]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2b24277e8d3sm144736795ad.55.2026.04.01.05.04.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 01 Apr 2026 05:04:03 -0700 (PDT) Date: Wed, 1 Apr 2026 17:33:59 +0530 From: Krishna Chomal To: Ilpo =?utf-8?B?SsOkcnZpbmVu?= Cc: Hans de Goede , platform-driver-x86@vger.kernel.org, LKML Subject: Re: [PATCH 1/4] platform/x86: hp-wmi: fix fan table parsing Message-ID: References: <20260401111748.106970-1-krishna.chomal108@gmail.com> <20260401111748.106970-2-krishna.chomal108@gmail.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 Wed, Apr 01, 2026 at 02:23:31PM +0300, Ilpo Järvinen wrote: >On Wed, 1 Apr 2026, Krishna Chomal wrote: > >> For Victus S devices, the BIOS fan table header was being incorrectly >> parsed as: >> struct { >> u8 unknown; >> u8 num_entries; >> } >> >> The first field should be num_fans and the second should be unknown. It >> is pure coincidence that interpreting an "unknown" field as "num_entries" > >So this coincidence is that both fields happened to contain the same >value? Or (same or) smaller? > Yes, for my board (and for the several recent additions in Victus S list) the second field in the fan table header happened to match the number of entries in the table, making the previous implementation appear correct. However on board 8D87 (and potentially others), the second field contains a larger value which causes the following check to fail: if (fan_table->header.num_entries == 0 || sizeof(struct victus_s_fan_table_header) + sizeof(struct victus_s_fan_table_entry) * fan_table->header.num_entries > sizeof(fan_data)) After reverse engineering the Windows implementation, I found that the official software ignores this second field entirely. Instead it uses the "stop-at-null" approach implemented in this patch. >-- > i.