Received: by 2002:a05:6358:45e:b0:b5:b6eb:e1f9 with SMTP id 30csp938508rwe; Wed, 24 Aug 2022 11:38:03 -0700 (PDT) X-Google-Smtp-Source: AA6agR6Un2BHaRdBL7jV6JkxAqUflqlAQ7Bh7OQf2i8zC9mRjowYDsh6VYdEwX9EzRVKpAU0xwpm X-Received: by 2002:a17:907:72cc:b0:73d:72c1:cc19 with SMTP id du12-20020a17090772cc00b0073d72c1cc19mr184911ejc.130.1661366282612; Wed, 24 Aug 2022 11:38:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1661366282; cv=none; d=google.com; s=arc-20160816; b=hFOrCKGRngYi8wbTY+hEPMI9IvdL/X2FfgSnRxPJF9wLQGPrVtGmx2jvH+rxJAvLJA NgUUvXi5jRa5HVmtga33iOq/h20T8lSlmB+QVuv0iGgQU0l3ITOU1N12742aQCNX1PWI w+EYhy5uViaHiEpeyzukf0lUHswc4K8TPrkjQCCdnJOuCEVVWzQXV9qq0sXxNfyDUo7X 4HJ0LSn2SAebw8ywdl/I4JiM7HEwOmLhgmdmrCTBYPOiN9+oqLKsqaAmWlM6tqdjCJrU nIWLK1s2o3TIUeq8iGxyvgGajJKlhrZSQrX0XYI095wRl+yBrmnN39vEi5GeldQwQCHS UPfw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=QwXjWp6VPuOIeH9a6I+1cEg+zMTR92fuUCrgnYOwFxU=; b=VxNteDc+fL76cl4Qmy7Y614s+NZOZn/hWS9LoRtrHboYJj0IinNUlTMONYIDQo4A/k H2iScNKm6dAokUKaZr8wuZmDK8BaZmVujwQcNq5jIGkPdbRylCgaUqdnTV/fxXp2g3lM 6QzJb1KQLyUCKMjsiGjC9vOHMMel/8QduiMngxjKDJkGj7/p2rYB5saDFFB20hYYBozZ lCmGNHWZTYE9qVvK+7vLpw/RLgOC20hx2xbYwcCefo3wFDaDVrhTLt91jOH0aqC+giGG e6YKI3GsZ1I8rcUzXONWuO043cqXkk6PXm4omY6ZjGxOeg6M1ozzdJv8qIg08JztY20A Yfjg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=WiZahHRZ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id dd20-20020a1709069b9400b0073d76645bb6si1269663ejc.877.2022.08.24.11.37.37; Wed, 24 Aug 2022 11:38:02 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=WiZahHRZ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240585AbiHXSEA (ORCPT + 99 others); Wed, 24 Aug 2022 14:04:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42322 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240589AbiHXSD1 (ORCPT ); Wed, 24 Aug 2022 14:03:27 -0400 Received: from mail-qv1-xf2d.google.com (mail-qv1-xf2d.google.com [IPv6:2607:f8b0:4864:20::f2d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0755760687 for ; Wed, 24 Aug 2022 11:03:04 -0700 (PDT) Received: by mail-qv1-xf2d.google.com with SMTP id y4so13485617qvp.3 for ; Wed, 24 Aug 2022 11:03:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=QwXjWp6VPuOIeH9a6I+1cEg+zMTR92fuUCrgnYOwFxU=; b=WiZahHRZjssP30ci297qxHBwM/n8W74ekOBzVVtrt9VDVKx69dQJ5wT3faWxLreN4i Tsx4R76cpJ/VQkF6ORngMs/uatCpRwFst26t7yNsGu9aEUxlYsGH/kML7x1RFFH2rdtv sngPiHYn8ALDq7cvMkV4D/NQGEBedwB8fk6qb730Q30S2FG16h17bKlBFy6dtx3aU6cS hNt2r9yzo3s7D+UwMi/CZ5PtXmw3aQRqmVWXXusAFZUiBza8a+NIyljV17BE5N/USKsm J2GtLze5k1xgXPamf9n51t8Am8YndizCVx1DmUq5UYSNSmOkJQYavf6gCH7y2Y8c0KKX mX1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=QwXjWp6VPuOIeH9a6I+1cEg+zMTR92fuUCrgnYOwFxU=; b=fme1149bcoV7xzU4DQPaqtXtdKK8cPIrBkYyKP/pR0u5Rr9IJmfUb9cXzQrcA/5uqa NEEDJVGLExA88cRvyuHY6arePhu2WgPQGdbp26aH1WKq63mDtNL/2Q+JMRCIYZbmT6Pq qUpHW23u1ciq1614gPmSDHxnCu6Ak8waxnzijhkqr+xAzjQiV8kZ01eKh559/IXVjHgz 4phl/Q7Fgwg5PkU1JfEPVh0Kejz2WqWexQ7dfhRpJkk4dSPMHcCMky84CjdaFZx7Ubdw fDC9ww2y4s2Ncc6Ywf9RoECpAK6T/LhkuRSqhmSO9TDkyhb+5Fwfjw6DT3yXLjw8f8fM ye6Q== X-Gm-Message-State: ACgBeo0/wH7Om1lSFkBj2eK+I4wUod6H+9zkdYl3AvEtudN9nyTb4iGG cWX02dr35RXiQYYIixwDJj6JBx2Ojdk58rkhOSruacHSc2A= X-Received: by 2002:a05:6214:29c2:b0:497:8b2:442 with SMTP id gh2-20020a05621429c200b0049708b20442mr209833qvb.97.1661364182917; Wed, 24 Aug 2022 11:03:02 -0700 (PDT) MIME-Version: 1.0 References: <20220822141930.5f43b5e7@endymion.delvare> In-Reply-To: From: Andy Shevchenko Date: Wed, 24 Aug 2022 21:02:26 +0300 Message-ID: Subject: Re: [GIT PULL] dmi update for v5.19 To: Linus Torvalds Cc: Jean Delvare , LKML Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Aug 24, 2022 at 8:41 PM Linus Torvalds wrote: > On Mon, Aug 22, 2022 at 5:19 AM Jean Delvare wrote: > > > > Andy Shevchenko (1): > > firmware: dmi: Use the proper accessor for the version field > > I pulled this, but I kind of question it. > > This replaces a single 32-bit memory access (and an optimized byte > swap) and a mask operation with three load-byte-and-shift operations. > > It's not clear that the new code is better. That concern was arisen during discussion, but my point here is that when you read the SMBus specification and look at the offset 6 the operation on it, even optimized, may confuse the reader. At least it confused me. Hence the patch. > That said, I can't imagine it matters - but because I looked at it, I > note that the length check seems to be kind of iffy. > > The code checks that the length of the block is < 32 before doing the > checksum on it, but shouldn't it also check for some minimum size? > Otherwise the dmi checksum is kind of pointless, isn't it? > > It will access a minimum of 24 bytes for that dmi_base thing, so that > would be the most obvious minimum value. But maybe there is some > spec-defined size for that that only covers the header? -- With Best Regards, Andy Shevchenko