From patchwork Thu Feb 9 01:16:32 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Zev Weiss X-Patchwork-Id: 54660 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp55247wrn; Wed, 8 Feb 2023 17:32:09 -0800 (PST) X-Google-Smtp-Source: AK7set+N6UarcMRXEW2lQ6yES3fq+xL8vRR+dYcWYAwLoJSUPFAngwXSbbqui6117vT1rgGRPEqZ X-Received: by 2002:a17:906:d6:b0:86e:2051:a514 with SMTP id 22-20020a17090600d600b0086e2051a514mr9486340eji.5.1675906329420; Wed, 08 Feb 2023 17:32:09 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1675906329; cv=none; d=google.com; s=arc-20160816; b=BHD5a5XLrqyOj28Y5o/zGdnMFfg8+ami1uFc1M3pn9eHTHLD5LZEZwvqfiYhT6tieS BkZ0mOOfPmf3raZLuvBbgw4Ytm1lDEGolXqFCAS3yhKbOy2ZHTL4KYLXI3oezRuk9835 dNWuS7h0F6S9VZ5f7j5DLhcOkf23Ajm5Lq5fJQmUT8grzfq48zlv37ERqi0CX8c2F8gR mJWtfbDqpFfp+ze3cfiGrpXl4wYflpATnpGv/0y2BmsmtajPiYtT0OJnsWXGFJwDIhYD doeCuTzRiI3rFyQ3Lac6pWzejzecq2HJ4ECjTjkY1vaQhx6VSHyjK4PSp1YdSvZ6PjcS Nrbw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=4fufzuT0XEbDZ7/n77MQbHSDfZq8tIFpOdmjNWCtVwQ=; b=Ag4Ex78dULOM13927F7J2i98VzVZk4qm9CQCbm7TgqWW7MWhYBetmefuyGadQ6MCH3 9kqYNZ0v/e4r54a4FQqKhOxFPpvA5qwPKpMrxg1pOnv9Yj+SROnwchlyXXiZbeRMNNio 5Do4k+v0+VE9BkrUrIyF9lo5rO7LuMOoHtYn8a1wX8W8gi8HyZOtZdnlKslRzKHQSzyq xmhpbRVRKhjLfiMeMHrr7OCYgoPFPlDO7LVxyfa1B9vK5hU5tmUllbvPfaDRTXDget3M rWDk34iXRJ9wr8lZhj8GgPsb5qwl/Pc8jSsLInOH6dFhawoL+gvGLozuImFfmf6ijrX8 fy2Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@bewilderbeest.net header.s=thorn header.b=bNYvWYkT; 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=NONE dis=NONE) header.from=bewilderbeest.net Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id v10-20020a17090610ca00b0088c22d8e86bsi558579ejv.772.2023.02.08.17.31.45; Wed, 08 Feb 2023 17:32:09 -0800 (PST) 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=@bewilderbeest.net header.s=thorn header.b=bNYvWYkT; 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=NONE dis=NONE) header.from=bewilderbeest.net Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231330AbjBIBQs (ORCPT + 99 others); Wed, 8 Feb 2023 20:16:48 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51848 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231349AbjBIBQm (ORCPT ); Wed, 8 Feb 2023 20:16:42 -0500 Received: from thorn.bewilderbeest.net (thorn.bewilderbeest.net [71.19.156.171]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1257CA5E3; Wed, 8 Feb 2023 17:16:39 -0800 (PST) Received: from hatter.bewilderbeest.net (97-113-250-99.tukw.qwest.net [97.113.250.99]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: zev) by thorn.bewilderbeest.net (Postfix) with ESMTPSA id 1522B421; Wed, 8 Feb 2023 17:16:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bewilderbeest.net; s=thorn; t=1675905399; bh=4fufzuT0XEbDZ7/n77MQbHSDfZq8tIFpOdmjNWCtVwQ=; h=From:To:Cc:Subject:Date:From; b=bNYvWYkTG2kGbLjCcdyN2z5G03oOqNy+AHJ19gIAfThi5LU04zPqeggpnoDZrSDUz rQEK0g43zCkLA4INkrcHcMGM4WqQ1HZpaCSNl+g6Tgo553srH54WlYD1yvUX1UEDxS IXKOBmmAxJS6TjHMW8C60M8yLGdYkA3A6iyCMWAQ= From: Zev Weiss To: Iwona Winiarska Cc: Zev Weiss , Guenter Roeck , openbmc@lists.ozlabs.org, Jean Delvare , linux-hwmon@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [RFC PATCH] hwmon: (peci/cputemp) Number cores as seen by host system Date: Wed, 8 Feb 2023 17:16:32 -0800 Message-Id: <20230209011632.32668-1-zev@bewilderbeest.net> X-Mailer: git-send-email 2.39.1 MIME-Version: 1.0 X-Spam-Status: No, score=-0.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS, SUBJ_AS_SEEN autolearn=no 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 X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1757315154940222497?= X-GMAIL-MSGID: =?utf-8?q?1757315154940222497?= While porting OpenBMC to a new platform with a Xeon Gold 6314U CPU (Ice Lake, 32 cores), I discovered that the core numbering used by the PECI interface appears to correspond to the cores that are present in the physical silicon, rather than those that are actually enabled and usable by the host OS (i.e. it includes cores that the chip was manufactured with but later had fused off). Thus far the cputemp driver has transparently exposed that numbering to userspace in its 'tempX_label' sysfs files, making the core numbers it reported not align with the core numbering used by the host system, which seems like an unfortunate source of confusion. We can instead use a separate counter to label the cores in a contiguous fashion (0 through numcores-1) so that the core numbering reported by the PECI cputemp driver matches the numbering seen by the host. Signed-off-by: Zev Weiss --- Offhand I can't think of any other examples of side effects of that manufacturing detail (fused-off cores) leaking out in externally-visible ways, so I'd think it's probably not something we really want to propagate further. I've verified that at least on the system I'm working on the numbering provided by this patch aligns with the host's CPU numbering (loaded each core individually one by one and saw a corresponding temperature increase visible via PECI), but I'm not sure if that relationship is guaranteed to hold on all parts -- Iwona, do you know if that's something we can rely on? This patch also leaves the driver's internal core tracking with the "physical" numbering the PECI interface uses, and hence it's still sort of visible to userspace in the form of the hwmon channel numbers used in the names of the sysfs attribute files. If desired we could also change that to keep the tempX_* file numbers contiguous as well, though it would necessitate a bit of additional remapping in the driver to translate between the two. drivers/hwmon/peci/cputemp.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/hwmon/peci/cputemp.c b/drivers/hwmon/peci/cputemp.c index 30850a479f61..6b4010cbbfdf 100644 --- a/drivers/hwmon/peci/cputemp.c +++ b/drivers/hwmon/peci/cputemp.c @@ -400,14 +400,15 @@ static int init_core_mask(struct peci_cputemp *priv) static int create_temp_label(struct peci_cputemp *priv) { unsigned long core_max = find_last_bit(priv->core_mask, CORE_NUMS_MAX); - int i; + int i, corenum = 0; priv->coretemp_label = devm_kzalloc(priv->dev, (core_max + 1) * sizeof(char *), GFP_KERNEL); if (!priv->coretemp_label) return -ENOMEM; for_each_set_bit(i, priv->core_mask, CORE_NUMS_MAX) { - priv->coretemp_label[i] = devm_kasprintf(priv->dev, GFP_KERNEL, "Core %d", i); + priv->coretemp_label[i] = devm_kasprintf(priv->dev, GFP_KERNEL, + "Core %d", corenum++); if (!priv->coretemp_label[i]) return -ENOMEM; }