Message ID | cover.1708635408.git.luizcap@redhat.com |
---|---|
Headers |
Return-Path: <linux-kernel+bounces-77349-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:a81b:b0:108:e6aa:91d0 with SMTP id bq27csp205423dyb; Thu, 22 Feb 2024 12:58:50 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCVmWNPASz3NVpah1lCC1x0aOyZAmftDW7fIod2rup1nSRMhvL/Al1tSShODTiduZEvhC99bFLjpwnuhIVmyvJYK6XLCSA== X-Google-Smtp-Source: AGHT+IEkXXajGhJ8sJY/lUVbbGquLtEZetAkzkZDWs0Q84PkPFOvnvPdWN1gCMQZYUQlMsBfP3AW X-Received: by 2002:a17:906:c306:b0:a3c:d7a5:6ab1 with SMTP id s6-20020a170906c30600b00a3cd7a56ab1mr28997ejz.0.1708635530393; Thu, 22 Feb 2024 12:58:50 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1708635530; cv=pass; d=google.com; s=arc-20160816; b=SCVZjzMGV20MdhbiVSa+biZHU9Xlm9M7Xc2DVxgFBhqWnSZCbRekknMe87nlDoFDLS Wka/B+bqFwIbHlRB87ZQWUwGeOb812Pc/Yid2WszYSNAQ3Tzi2qbkHcfJrcFsgBgfVg+ eekqYE8ypJ9/uPJ3fKb9b8cO6smj638c8nSpDJTpeWz7N2uxpcc+MFSBcT9qQfXLTMaK PZANp5Ypv+qX2nMQSAuXsuSKPE8yWtXA88oMFp6VYbE5VQ3sh0eMPLTcBvyJyk6QbgEl DhqTSUwIwirDJ77Ynk+Mlzbr9f3Zke1DPQbFuWAst3GlcbsN56SVER+plV9sH4sq75QM 5ewg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:date:subject:cc:to :from:dkim-signature; bh=uQNCPPxOXSIi1YvPzBU8stcQQepKpFfnl3c3A7lEn1w=; fh=l74HcAni2UfQJngIxo7C8HfGMgimKQ1jenNpkLLX2CQ=; b=T0KkeMh7dE60XDM8Q2/6HMcpn74IjqaiDL2N2+ge+oH618/B2pnyM5r0m5gkO7Li8a DnzMjmvDoKUzZGjvvEDY3SX4yB7JHFSTVHLqq7HcrBnNvPItxvgiQIzVnpX7Uyl9KaMV PRzKacC6Gn8avXeqiB/ZWzN8oAD7O2VixQNkBi66ku96Yezc6N7MzLVo8fz3Cwuj/Jey Setb/mNVW4cX2AsWN7wCpiy/EJR8uuHuHrQMn4jvLt8f/JsTqDsha2DP/ZisjdJr246d o7eD6ks/JFu/IsqYYbw0UcNyL82HhStQb/BOra+jhydJQR9dNDREwDiUEj/jnGESm1RJ VNjA==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=GfpSA7iM; arc=pass (i=1 spf=pass spfdomain=redhat.com dkim=pass dkdomain=redhat.com dmarc=pass fromdomain=redhat.com); spf=pass (google.com: domain of linux-kernel+bounces-77349-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-77349-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [147.75.80.249]) by mx.google.com with ESMTPS id ov28-20020a170906fc1c00b00a3d777aa900si5432341ejb.147.2024.02.22.12.58.50 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 22 Feb 2024 12:58:50 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-77349-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=GfpSA7iM; arc=pass (i=1 spf=pass spfdomain=redhat.com dkim=pass dkdomain=redhat.com dmarc=pass fromdomain=redhat.com); spf=pass (google.com: domain of linux-kernel+bounces-77349-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-77349-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id E911E1F2453A for <ouuuleilei@gmail.com>; Thu, 22 Feb 2024 20:58:49 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 58E6312D206; Thu, 22 Feb 2024 20:58:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="GfpSA7iM" Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (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 3E9AA73F0C for <linux-kernel@vger.kernel.org>; Thu, 22 Feb 2024 20:58:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708635486; cv=none; b=KEa/FKsdN6yoVxJpZrlY8Hgvp0fMWK7dtFpuzF2LSorxz+cg1OGFvZ56uJsUSIDOBtT5PZeX8u/aL5SEcUODZpQkfO9zzbF3PKwJr8b9UV4TrxfhPjzfU16cy4KP1wPFrafLIFAVnVMPeQ+pN+XpGig3NTr2DTOOkT8wdyM/4O4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708635486; c=relaxed/simple; bh=KO17FxZqGQUTkWpzYZMY3Yy4KQM5Bz9Xy9i+eEsb9uU=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=TrjamSw3tibInCgiLoZJ77sINaqp2PK7yVVn56a/5M70v+jJ3bY2VPkZeEeZHfSyPrYDFrJlu2e+H6hogw2d9Zij5aRvo1er2FTecspHKuU99xA2ZSCgbUfN8GMPC+C4VKuEyB8Nc1giGl6jNojI5jjAEA/fYFIic+dG7JjKcyo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=GfpSA7iM; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1708635484; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=uQNCPPxOXSIi1YvPzBU8stcQQepKpFfnl3c3A7lEn1w=; b=GfpSA7iMstK3TApu2JFY6mmuYZs9vWfU793d/EA5McPw0zmMJcW2Fs2feneAxPZK76u73N Mvlp66MDTdweIfJnd6XDVQMjPYFDFcESoTruIgMXA4N2BJ26dRKmlSEj4Uvc6k65yKQSOV fLAQti2wJR7750gzy1gfUPRvSimWizc= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-640-iPvArl2jNXObXjSmQJpj3Q-1; Thu, 22 Feb 2024 15:57:58 -0500 X-MC-Unique: iPvArl2jNXObXjSmQJpj3Q-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 43454890F64; Thu, 22 Feb 2024 20:57:58 +0000 (UTC) Received: from ibm-p8-16-fsp.mgmt.pnr.lab.eng.rdu2.redhat.com (unknown [10.22.8.53]) by smtp.corp.redhat.com (Postfix) with ESMTP id EC3EB10802; Thu, 22 Feb 2024 20:57:56 +0000 (UTC) From: Luiz Capitulino <luizcap@redhat.com> To: ilpo.jarvinen@linux.intel.com, shravankr@nvidia.com Cc: davthompson@nvidia.com, ndalvi@redhat.com, linux-kernel@vger.kernel.org, platform-driver-x86@vger.kernel.org, Luiz Capitulino <luizcap@redhat.com> Subject: [PATCH 0/2] platform/mellanox: mlxbf-pmc: Fix module loading Date: Thu, 22 Feb 2024 15:57:28 -0500 Message-ID: <cover.1708635408.git.luizcap@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.5 X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1791634209845108385 X-GMAIL-MSGID: 1791634209845108385 |
Series |
platform/mellanox: mlxbf-pmc: Fix module loading
|
|
Message
Luiz Capitulino
Feb. 22, 2024, 8:57 p.m. UTC
Hi, The mlxbf-pmc driver fails to load when the firmware reports a new but not yet implemented performance block. I can reproduce this today with a Bluefield-3 card and UEFI version 4.6.0-18-g7d063bb-BId13035, since this reports the new clock_measure performance block. This[1] patch from Shravan implements the clock_measure support and will solve the issue. But this series avoids the situation by ignoring and logging unsupported performance blocks. NOTE: This series is based on latest linux-next which contains new changes to mlxbf-pmc. [1] https://lore.kernel.org/lkml/1c2f1b6da51523fe0f338f9ddce9e3903148f604.1707808180.git.shravankr@nvidia.com/ Luiz Capitulino (2): platform/mellanox: mlxbf-pmc: mlxbf_pmc_event_list(): make size ptr optional platform/mellanox: mlxbf-pmc: Ignore unsupported performance blocks drivers/platform/mellanox/mlxbf-pmc.c | 56 +++++++++++++++++---------- 1 file changed, 36 insertions(+), 20 deletions(-)
Comments
On Thu, 22 Feb 2024 15:57:28 -0500, Luiz Capitulino wrote: > The mlxbf-pmc driver fails to load when the firmware reports a new but not > yet implemented performance block. I can reproduce this today with a > Bluefield-3 card and UEFI version 4.6.0-18-g7d063bb-BId13035, since this > reports the new clock_measure performance block. > > This[1] patch from Shravan implements the clock_measure support and will > solve the issue. But this series avoids the situation by ignoring and > logging unsupported performance blocks. > > [...] Thank you for your contribution, it has been applied to my local review-ilpo branch. Note it will show up in the public platform-drivers-x86/review-ilpo branch only once I've pushed my local branch there, which might take a while. The list of commits applied: [1/2] platform/mellanox: mlxbf-pmc: mlxbf_pmc_event_list(): make size ptr optional commit: c5b649996ac63d43f1d4185de177c90d664b2230 [2/2] platform/mellanox: mlxbf-pmc: Ignore unsupported performance blocks commit: 4e39d7be4123f65adf78b0a466cbaf1169d7cedb -- i.
On 2024-02-26 08:27, Ilpo Järvinen wrote: > On Thu, 22 Feb 2024 15:57:28 -0500, Luiz Capitulino wrote: > >> The mlxbf-pmc driver fails to load when the firmware reports a new but not >> yet implemented performance block. I can reproduce this today with a >> Bluefield-3 card and UEFI version 4.6.0-18-g7d063bb-BId13035, since this >> reports the new clock_measure performance block. >> >> This[1] patch from Shravan implements the clock_measure support and will >> solve the issue. But this series avoids the situation by ignoring and >> logging unsupported performance blocks. >> >> [...] > > > Thank you for your contribution, it has been applied to my local > review-ilpo branch. Note it will show up in the public > platform-drivers-x86/review-ilpo branch only once I've pushed my > local branch there, which might take a while. Thank you Ilpo and thanks Hans for the review. The only detail is that we probably want this merged for 6.8 since the driver doesn't currently load with the configuration mentioned above. - Luiz > > The list of commits applied: > [1/2] platform/mellanox: mlxbf-pmc: mlxbf_pmc_event_list(): make size ptr optional > commit: c5b649996ac63d43f1d4185de177c90d664b2230 > [2/2] platform/mellanox: mlxbf-pmc: Ignore unsupported performance blocks > commit: 4e39d7be4123f65adf78b0a466cbaf1169d7cedb > > -- > i. > >
On Mon, 26 Feb 2024, Luiz Capitulino wrote: > On 2024-02-26 08:27, Ilpo Järvinen wrote: > > On Thu, 22 Feb 2024 15:57:28 -0500, Luiz Capitulino wrote: > > > > > The mlxbf-pmc driver fails to load when the firmware reports a new but not > > > yet implemented performance block. I can reproduce this today with a > > > Bluefield-3 card and UEFI version 4.6.0-18-g7d063bb-BId13035, since this > > > reports the new clock_measure performance block. > > > > > > This[1] patch from Shravan implements the clock_measure support and will > > > solve the issue. But this series avoids the situation by ignoring and > > > logging unsupported performance blocks. > > > > > > [...] > > > > > > Thank you for your contribution, it has been applied to my local > > review-ilpo branch. Note it will show up in the public > > platform-drivers-x86/review-ilpo branch only once I've pushed my > > local branch there, which might take a while. > > Thank you Ilpo and thanks Hans for the review. > > The only detail is that we probably want this merged for 6.8 since > the driver doesn't currently load with the configuration mentioned above. Oh, sorry, I missed the mention in the coverletter. So you'd want I drop these from review-ilpo branch as there they end up into for-next branch, and they should go through Hans instead who handles fixes branch for this cycle?
On 2024-02-26 11:04, Ilpo Järvinen wrote: > On Mon, 26 Feb 2024, Luiz Capitulino wrote: > >> On 2024-02-26 08:27, Ilpo Järvinen wrote: >>> On Thu, 22 Feb 2024 15:57:28 -0500, Luiz Capitulino wrote: >>> >>>> The mlxbf-pmc driver fails to load when the firmware reports a new but not >>>> yet implemented performance block. I can reproduce this today with a >>>> Bluefield-3 card and UEFI version 4.6.0-18-g7d063bb-BId13035, since this >>>> reports the new clock_measure performance block. >>>> >>>> This[1] patch from Shravan implements the clock_measure support and will >>>> solve the issue. But this series avoids the situation by ignoring and >>>> logging unsupported performance blocks. >>>> >>>> [...] >>> >>> >>> Thank you for your contribution, it has been applied to my local >>> review-ilpo branch. Note it will show up in the public >>> platform-drivers-x86/review-ilpo branch only once I've pushed my >>> local branch there, which might take a while. >> >> Thank you Ilpo and thanks Hans for the review. >> >> The only detail is that we probably want this merged for 6.8 since >> the driver doesn't currently load with the configuration mentioned above. > > Oh, sorry, I missed the mention in the coverletter. > > So you'd want I drop these from review-ilpo branch as there they end > up into for-next branch, and they should go through Hans instead who > handles fixes branch for this cycle? If that's the path to get this series merged for this cycle then yes, but let's see if Hans agrees (sorry that I didn't know this before posting). One additional detail is that this series is on top of linux-next, which has two additional mlxbf-pmc changes: * https://lore.kernel.org/lkml/39be055af3506ce6f843d11e45d71620f2a96e26.1707808180.git.shravankr@nvidia.com/ * https://lore.kernel.org/lkml/d8548c70339a29258a906b2b518e5c48f669795c.1707808180.git.shravankr@nvidia.com/ Maybe those two should be included for 6.8 as well? - Luiz
Hi Luiz, On 2/26/24 17:10, Luiz Capitulino wrote: > On 2024-02-26 11:04, Ilpo Järvinen wrote: >> On Mon, 26 Feb 2024, Luiz Capitulino wrote: >> >>> On 2024-02-26 08:27, Ilpo Järvinen wrote: >>>> On Thu, 22 Feb 2024 15:57:28 -0500, Luiz Capitulino wrote: >>>> >>>>> The mlxbf-pmc driver fails to load when the firmware reports a new but not >>>>> yet implemented performance block. I can reproduce this today with a >>>>> Bluefield-3 card and UEFI version 4.6.0-18-g7d063bb-BId13035, since this >>>>> reports the new clock_measure performance block. >>>>> >>>>> This[1] patch from Shravan implements the clock_measure support and will >>>>> solve the issue. But this series avoids the situation by ignoring and >>>>> logging unsupported performance blocks. >>>>> >>>>> [...] >>>> >>>> >>>> Thank you for your contribution, it has been applied to my local >>>> review-ilpo branch. Note it will show up in the public >>>> platform-drivers-x86/review-ilpo branch only once I've pushed my >>>> local branch there, which might take a while. >>> >>> Thank you Ilpo and thanks Hans for the review. >>> >>> The only detail is that we probably want this merged for 6.8 since >>> the driver doesn't currently load with the configuration mentioned above. >> >> Oh, sorry, I missed the mention in the coverletter. >> >> So you'd want I drop these from review-ilpo branch as there they end >> up into for-next branch, and they should go through Hans instead who >> handles fixes branch for this cycle? > > If that's the path to get this series merged for this cycle then yes, > but let's see if Hans agrees (sorry that I didn't know this before > posting). Hmm, new hw enablement typically goes through -next and not to the current fixes branch. And AFAICT this is new hw enablement, not a regression / bug-fix. Is there any special reason why this needs to be in 6.8 ? For RHEL kernels you can cherry-pick patches from -next as necessary. > One additional detail is that this series is on top of linux-next, which > has two additional mlxbf-pmc changes: > > * https://lore.kernel.org/lkml/39be055af3506ce6f843d11e45d71620f2a96e26.1707808180.git.shravankr@nvidia.com/ > * https://lore.kernel.org/lkml/d8548c70339a29258a906b2b518e5c48f669795c.1707808180.git.shravankr@nvidia.com/ Hmm, those are not small patches, any other reason why this really should go to -next IMHO. Regards, Hans
On Mon, 26 Feb 2024, Luiz Capitulino wrote: > On 2024-02-26 11:04, Ilpo Järvinen wrote: > > On Mon, 26 Feb 2024, Luiz Capitulino wrote: > > > > > On 2024-02-26 08:27, Ilpo Järvinen wrote: > > > > On Thu, 22 Feb 2024 15:57:28 -0500, Luiz Capitulino wrote: > > > > > > > > > The mlxbf-pmc driver fails to load when the firmware reports a new but > > > > > not > > > > > yet implemented performance block. I can reproduce this today with a > > > > > Bluefield-3 card and UEFI version 4.6.0-18-g7d063bb-BId13035, since > > > > > this > > > > > reports the new clock_measure performance block. > > > > > > > > > > This[1] patch from Shravan implements the clock_measure support and > > > > > will > > > > > solve the issue. But this series avoids the situation by ignoring and > > > > > logging unsupported performance blocks. > > > > > > > > > > [...] > > > > > > > > > > > > Thank you for your contribution, it has been applied to my local > > > > review-ilpo branch. Note it will show up in the public > > > > platform-drivers-x86/review-ilpo branch only once I've pushed my > > > > local branch there, which might take a while. > > > > > > Thank you Ilpo and thanks Hans for the review. > > > > > > The only detail is that we probably want this merged for 6.8 since > > > the driver doesn't currently load with the configuration mentioned above. > > > > Oh, sorry, I missed the mention in the coverletter. > > > > So you'd want I drop these from review-ilpo branch as there they end > > up into for-next branch, and they should go through Hans instead who > > handles fixes branch for this cycle? > > If that's the path to get this series merged for this cycle then yes, > but let's see if Hans agrees (sorry that I didn't know this before > posting). > > One additional detail is that this series is on top of linux-next, which > has two additional mlxbf-pmc changes: > > * > https://lore.kernel.org/lkml/39be055af3506ce6f843d11e45d71620f2a96e26.1707808180.git.shravankr@nvidia.com/ > * > https://lore.kernel.org/lkml/d8548c70339a29258a906b2b518e5c48f669795c.1707808180.git.shravankr@nvidia.com/ > > Maybe those two should be included for 6.8 as well? Those look a new feature to me so they belong to for-next. So no, they will not end up into 6.8 (to fixes branch). If the 2 patches in this series do not apply without some for-next targetting dependencies, you should rebase on top of fixes branch and send a new version. About those two patches, please also see my reply. I intentionally only 2 patches of that series because I wanted to see sysfs documentation first so you should resend those two patches to for-next with sysfs documentation.
On 2024-02-26 11:57, Hans de Goede wrote: > Hi Luiz, > > On 2/26/24 17:10, Luiz Capitulino wrote: >> On 2024-02-26 11:04, Ilpo Järvinen wrote: >>> On Mon, 26 Feb 2024, Luiz Capitulino wrote: >>> >>>> On 2024-02-26 08:27, Ilpo Järvinen wrote: >>>>> On Thu, 22 Feb 2024 15:57:28 -0500, Luiz Capitulino wrote: >>>>> >>>>>> The mlxbf-pmc driver fails to load when the firmware reports a new but not >>>>>> yet implemented performance block. I can reproduce this today with a >>>>>> Bluefield-3 card and UEFI version 4.6.0-18-g7d063bb-BId13035, since this >>>>>> reports the new clock_measure performance block. >>>>>> >>>>>> This[1] patch from Shravan implements the clock_measure support and will >>>>>> solve the issue. But this series avoids the situation by ignoring and >>>>>> logging unsupported performance blocks. >>>>>> >>>>>> [...] >>>>> >>>>> >>>>> Thank you for your contribution, it has been applied to my local >>>>> review-ilpo branch. Note it will show up in the public >>>>> platform-drivers-x86/review-ilpo branch only once I've pushed my >>>>> local branch there, which might take a while. >>>> >>>> Thank you Ilpo and thanks Hans for the review. >>>> >>>> The only detail is that we probably want this merged for 6.8 since >>>> the driver doesn't currently load with the configuration mentioned above. >>> >>> Oh, sorry, I missed the mention in the coverletter. >>> >>> So you'd want I drop these from review-ilpo branch as there they end >>> up into for-next branch, and they should go through Hans instead who >>> handles fixes branch for this cycle? >> >> If that's the path to get this series merged for this cycle then yes, >> but let's see if Hans agrees (sorry that I didn't know this before >> posting). > > Hmm, new hw enablement typically goes through -next and not to > the current fixes branch. And AFAICT this is new hw enablement, > not a regression / bug-fix. > > Is there any special reason why this needs to be in 6.8 ? Since the new firmware feature is causing the driver not to load, I'm seeing this more as a bug than new enablement. But it's fine with me if you decide on not having them on 6.8. > For RHEL kernels you can cherry-pick patches from -next > as necessary. I know :) >> One additional detail is that this series is on top of linux-next, which >> has two additional mlxbf-pmc changes: >> >> * https://lore.kernel.org/lkml/39be055af3506ce6f843d11e45d71620f2a96e26.1707808180.git.shravankr@nvidia.com/ >> * https://lore.kernel.org/lkml/d8548c70339a29258a906b2b518e5c48f669795c.1707808180.git.shravankr@nvidia.com/ > > Hmm, those are not small patches, any other reason > why this really should go to -next IMHO. OK. - Luiz
On 2024-02-26 11:59, Ilpo Järvinen wrote: > On Mon, 26 Feb 2024, Luiz Capitulino wrote: > >> On 2024-02-26 11:04, Ilpo Järvinen wrote: >>> On Mon, 26 Feb 2024, Luiz Capitulino wrote: >>> >>>> On 2024-02-26 08:27, Ilpo Järvinen wrote: >>>>> On Thu, 22 Feb 2024 15:57:28 -0500, Luiz Capitulino wrote: >>>>> >>>>>> The mlxbf-pmc driver fails to load when the firmware reports a new but >>>>>> not >>>>>> yet implemented performance block. I can reproduce this today with a >>>>>> Bluefield-3 card and UEFI version 4.6.0-18-g7d063bb-BId13035, since >>>>>> this >>>>>> reports the new clock_measure performance block. >>>>>> >>>>>> This[1] patch from Shravan implements the clock_measure support and >>>>>> will >>>>>> solve the issue. But this series avoids the situation by ignoring and >>>>>> logging unsupported performance blocks. >>>>>> >>>>>> [...] >>>>> >>>>> >>>>> Thank you for your contribution, it has been applied to my local >>>>> review-ilpo branch. Note it will show up in the public >>>>> platform-drivers-x86/review-ilpo branch only once I've pushed my >>>>> local branch there, which might take a while. >>>> >>>> Thank you Ilpo and thanks Hans for the review. >>>> >>>> The only detail is that we probably want this merged for 6.8 since >>>> the driver doesn't currently load with the configuration mentioned above. >>> >>> Oh, sorry, I missed the mention in the coverletter. >>> >>> So you'd want I drop these from review-ilpo branch as there they end >>> up into for-next branch, and they should go through Hans instead who >>> handles fixes branch for this cycle? >> >> If that's the path to get this series merged for this cycle then yes, >> but let's see if Hans agrees (sorry that I didn't know this before >> posting). >> >> One additional detail is that this series is on top of linux-next, which >> has two additional mlxbf-pmc changes: >> >> * >> https://lore.kernel.org/lkml/39be055af3506ce6f843d11e45d71620f2a96e26.1707808180.git.shravankr@nvidia.com/ >> * >> https://lore.kernel.org/lkml/d8548c70339a29258a906b2b518e5c48f669795c.1707808180.git.shravankr@nvidia.com/ >> >> Maybe those two should be included for 6.8 as well? > > Those look a new feature to me so they belong to for-next. So no, they > will not end up into 6.8 (to fixes branch). If the 2 patches in this > series do not apply without some for-next targetting dependencies, you > should rebase on top of fixes branch and send a new version. Understood. > About those two patches, please also see my reply. I intentionally only 2 > patches of that series because I wanted to see sysfs documentation first > so you should resend those two patches to for-next with sysfs > documentation. I'm actually not author of the other patches :) - Luiz
On Mon, 26 Feb 2024, Hans de Goede wrote: > Hi Luiz, > > On 2/26/24 17:10, Luiz Capitulino wrote: > > On 2024-02-26 11:04, Ilpo Järvinen wrote: > >> On Mon, 26 Feb 2024, Luiz Capitulino wrote: > >> > >>> On 2024-02-26 08:27, Ilpo Järvinen wrote: > >>>> On Thu, 22 Feb 2024 15:57:28 -0500, Luiz Capitulino wrote: > >>>> > >>>>> The mlxbf-pmc driver fails to load when the firmware reports a new but not > >>>>> yet implemented performance block. I can reproduce this today with a > >>>>> Bluefield-3 card and UEFI version 4.6.0-18-g7d063bb-BId13035, since this > >>>>> reports the new clock_measure performance block. > >>>>> > >>>>> This[1] patch from Shravan implements the clock_measure support and will > >>>>> solve the issue. But this series avoids the situation by ignoring and > >>>>> logging unsupported performance blocks. > >>>>> > >>>>> [...] > >>>> > >>>> > >>>> Thank you for your contribution, it has been applied to my local > >>>> review-ilpo branch. Note it will show up in the public > >>>> platform-drivers-x86/review-ilpo branch only once I've pushed my > >>>> local branch there, which might take a while. > >>> > >>> Thank you Ilpo and thanks Hans for the review. > >>> > >>> The only detail is that we probably want this merged for 6.8 since > >>> the driver doesn't currently load with the configuration mentioned above. > >> > >> Oh, sorry, I missed the mention in the coverletter. > >> > >> So you'd want I drop these from review-ilpo branch as there they end > >> up into for-next branch, and they should go through Hans instead who > >> handles fixes branch for this cycle? > > > > If that's the path to get this series merged for this cycle then yes, > > but let's see if Hans agrees (sorry that I didn't know this before > > posting). > > Hmm, new hw enablement typically goes through -next and not to > the current fixes branch. And AFAICT this is new hw enablement, > not a regression / bug-fix. > > Is there any special reason why this needs to be in 6.8 ? To me it sounded like fix to 1a218d312e65 ("platform/mellanox: mlxbf-pmc: Add Mellanox BlueField PMC driver") and 423c3361855c ("platform/mellanox: mlxbf-pmc: Add support for BlueField-3") although not explicitly marked as such. But I'm fine with taking these through for-next, it's relatively late into the cycle already anyway. > For RHEL kernels you can cherry-pick patches from -next > as necessary. It's also possible to send them later directly to stable folks once Linus' tree has them after the next merge window if you feel they're useful for stable inclusion. > > One additional detail is that this series is on top of linux-next, which > > has two additional mlxbf-pmc changes: > > > > * https://lore.kernel.org/lkml/39be055af3506ce6f843d11e45d71620f2a96e26.1707808180.git.shravankr@nvidia.com/ > > * https://lore.kernel.org/lkml/d8548c70339a29258a906b2b518e5c48f669795c.1707808180.git.shravankr@nvidia.com/ > > Hmm, those are not small patches, any other reason > why this really should go to -next IMHO. Those two linked patches are totally unrelated.
On Mon, 26 Feb 2024, Luiz Capitulino wrote: > On 2024-02-26 11:59, Ilpo Järvinen wrote: > > On Mon, 26 Feb 2024, Luiz Capitulino wrote: > > > > > On 2024-02-26 11:04, Ilpo Järvinen wrote: > > > > On Mon, 26 Feb 2024, Luiz Capitulino wrote: > > > > > > > > > On 2024-02-26 08:27, Ilpo Järvinen wrote: > > > > > > On Thu, 22 Feb 2024 15:57:28 -0500, Luiz Capitulino wrote: > > > > > > > > > > > > > The mlxbf-pmc driver fails to load when the firmware reports a new > > > > > > > but > > > > > > > not > > > > > > > yet implemented performance block. I can reproduce this today with > > > > > > > a > > > > > > > Bluefield-3 card and UEFI version 4.6.0-18-g7d063bb-BId13035, > > > > > > > since > > > > > > > this > > > > > > > reports the new clock_measure performance block. > > > > > > > > > > > > > > This[1] patch from Shravan implements the clock_measure support > > > > > > > and > > > > > > > will > > > > > > > solve the issue. But this series avoids the situation by ignoring > > > > > > > and > > > > > > > logging unsupported performance blocks. > > > > > > > > > > > > > > [...] > > > > > > > > > > > > > > > > > > Thank you for your contribution, it has been applied to my local > > > > > > review-ilpo branch. Note it will show up in the public > > > > > > platform-drivers-x86/review-ilpo branch only once I've pushed my > > > > > > local branch there, which might take a while. > > > > > > > > > > Thank you Ilpo and thanks Hans for the review. > > > > > > > > > > The only detail is that we probably want this merged for 6.8 since > > > > > the driver doesn't currently load with the configuration mentioned > > > > > above. > > > > > > > > Oh, sorry, I missed the mention in the coverletter. > > > > > > > > So you'd want I drop these from review-ilpo branch as there they end > > > > up into for-next branch, and they should go through Hans instead who > > > > handles fixes branch for this cycle? > > > > > > If that's the path to get this series merged for this cycle then yes, > > > but let's see if Hans agrees (sorry that I didn't know this before > > > posting). > > > > > > One additional detail is that this series is on top of linux-next, which > > > has two additional mlxbf-pmc changes: > > > > > > * > > > https://lore.kernel.org/lkml/ 39be055af3506ce6f843d11e45d71620f2a96e26.1707808180.git.shravankr@nvidia.com/ > > > * > > > https://lore.kernel.org/lkml/d8548c70339a29258a906b2b518e5c48f669795c.1707808180.git.shravankr@nvidia.com/ > > > > > > Maybe those two should be included for 6.8 as well? > > > > Those look a new feature to me so they belong to for-next. So no, they > > will not end up into 6.8 (to fixes branch). If the 2 patches in this > > series do not apply without some for-next targetting dependencies, you > > should rebase on top of fixes branch and send a new version. > > Understood. > > > About those two patches, please also see my reply. I intentionally only 2 > > patches of that series because I wanted to see sysfs documentation first > > so you should resend those two patches to for-next with sysfs > > documentation. > > I'm actually not author of the other patches :) Ah, sorry. I didn't pay enough attention to that. :-)
On 2024-02-27 08:18, Ilpo Järvinen wrote: > On Mon, 26 Feb 2024, Hans de Goede wrote: > >> Hi Luiz, >> >> On 2/26/24 17:10, Luiz Capitulino wrote: >>> On 2024-02-26 11:04, Ilpo Järvinen wrote: >>>> On Mon, 26 Feb 2024, Luiz Capitulino wrote: >>>> >>>>> On 2024-02-26 08:27, Ilpo Järvinen wrote: >>>>>> On Thu, 22 Feb 2024 15:57:28 -0500, Luiz Capitulino wrote: >>>>>> >>>>>>> The mlxbf-pmc driver fails to load when the firmware reports a new but not >>>>>>> yet implemented performance block. I can reproduce this today with a >>>>>>> Bluefield-3 card and UEFI version 4.6.0-18-g7d063bb-BId13035, since this >>>>>>> reports the new clock_measure performance block. >>>>>>> >>>>>>> This[1] patch from Shravan implements the clock_measure support and will >>>>>>> solve the issue. But this series avoids the situation by ignoring and >>>>>>> logging unsupported performance blocks. >>>>>>> >>>>>>> [...] >>>>>> >>>>>> >>>>>> Thank you for your contribution, it has been applied to my local >>>>>> review-ilpo branch. Note it will show up in the public >>>>>> platform-drivers-x86/review-ilpo branch only once I've pushed my >>>>>> local branch there, which might take a while. >>>>> >>>>> Thank you Ilpo and thanks Hans for the review. >>>>> >>>>> The only detail is that we probably want this merged for 6.8 since >>>>> the driver doesn't currently load with the configuration mentioned above. >>>> >>>> Oh, sorry, I missed the mention in the coverletter. >>>> >>>> So you'd want I drop these from review-ilpo branch as there they end >>>> up into for-next branch, and they should go through Hans instead who >>>> handles fixes branch for this cycle? >>> >>> If that's the path to get this series merged for this cycle then yes, >>> but let's see if Hans agrees (sorry that I didn't know this before >>> posting). >> >> Hmm, new hw enablement typically goes through -next and not to >> the current fixes branch. And AFAICT this is new hw enablement, >> not a regression / bug-fix. >> >> Is there any special reason why this needs to be in 6.8 ? > > To me it sounded like fix to 1a218d312e65 ("platform/mellanox: mlxbf-pmc: > Add Mellanox BlueField PMC driver") and 423c3361855c ("platform/mellanox: > mlxbf-pmc: Add support for BlueField-3") although not explicitly marked as > such. > > But I'm fine with taking these through for-next, it's relatively late into > the cycle already anyway. > >> For RHEL kernels you can cherry-pick patches from -next >> as necessary. > > It's also possible to send them later directly to stable folks once > Linus' tree has them after the next merge window if you feel they're > useful for stable inclusion. Fair enough. Let's proceed with the original plan of having them merged in the for-next branch. Sorry for the noise this discussion may have caused. - Luiz > >>> One additional detail is that this series is on top of linux-next, which >>> has two additional mlxbf-pmc changes: >>> >>> * https://lore.kernel.org/lkml/39be055af3506ce6f843d11e45d71620f2a96e26.1707808180.git.shravankr@nvidia.com/ >>> * https://lore.kernel.org/lkml/d8548c70339a29258a906b2b518e5c48f669795c.1707808180.git.shravankr@nvidia.com/ >> >> Hmm, those are not small patches, any other reason >> why this really should go to -next IMHO. > > Those two linked patches are totally unrelated. > >