Message ID | 20231027083811.9200-1-ilpo.jarvinen@linux.intel.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:d641:0:b0:403:3b70:6f57 with SMTP id cy1csp450516vqb; Fri, 27 Oct 2023 01:38:40 -0700 (PDT) X-Google-Smtp-Source: AGHT+IExaeST/XEzC3/FXPV7+n1vxLZVtLx1Yd3VEJgwSpl5p6ms0PX9gW1Lvcx7sVy4ANNYhK7N X-Received: by 2002:a1f:ab4d:0:b0:4a1:b73a:d2c9 with SMTP id u74-20020a1fab4d000000b004a1b73ad2c9mr2240248vke.10.1698395919749; Fri, 27 Oct 2023 01:38:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1698395919; cv=none; d=google.com; s=arc-20160816; b=EYNH/CN6d6Dd2ncvbx/E0fwikj/3vszp8ZfXtC3aTxD5GDzXmp+3V726tfZuo9Z2Lt goaNWDOtAznn9jmXvLI59wAF3YmIsjpl/uFNzeHfx7+89NFe6gN4zWwwHA6+fFxab1lh X23ZI9c1fOxREx6ju4FmtNbSa4NvjfucnUUFijkrAsLSqrtGss6FNzt4oL7S3LiKD0qG 8TH6hw0hybMGYxGTlh/tmhbpG5vWd5AF/IAipm/b6fKlF3OjbjpPiI5I2PPhsIeMFZVI CE4YJPWTEcc1Ab5eZgVd5UQFqhywrtCpDWEubvCyoCf8WVLEFOU6nym7Ru1We/q1DCzl sAoQ== 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=I6iEOUwiFGLWDQ6prS7HgQaTcD2PLT8Vo7BRkC0Uxtk=; fh=E3kzHqS1Jm88FpWLmLYVxK5f65z6O2nEEtILSQsq/7g=; b=xDMq07IgtrMvMWksZm68rLAIZ5EsZhINkVVOQuYlcFXwkcD1CTHs4CAfT4lFNZqxqM N56k5j7bC00w0/DP4yl1mm7P/cZqm3L6wTyLeU4gHryetZH/4voNitBqgzMCTnAxlPpl U4sNG0LV7K1q745SdOfEir3HCj0hvNipDRurqnmgGEWP2iWcSf2TEc5QEB4i+E893WlA YWrEG/QrapNeTD8hNv1MazMT+xqEkXxx6VeGwsDQEeqGrWj5AKU0036RQWSRuCOZ7j47 VFfB9tvua/ze6EQGIBmTlSxXNmljXXr7BMA88aClqLCPgE2HJpp3VMB+FZu5W5L2sZqC fggw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=SFzFPe7m; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from snail.vger.email (snail.vger.email. [23.128.96.37]) by mx.google.com with ESMTPS id f68-20020a0ddc47000000b005a7b4f9ba80si1733954ywe.170.2023.10.27.01.38.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 27 Oct 2023 01:38:39 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) client-ip=23.128.96.37; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=SFzFPe7m; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by snail.vger.email (Postfix) with ESMTP id B8EB882CA0C5; Fri, 27 Oct 2023 01:38:38 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at snail.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345584AbjJ0Iic (ORCPT <rfc822;aposhian.dev@gmail.com> + 26 others); Fri, 27 Oct 2023 04:38:32 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37566 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235107AbjJ0IiX (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 27 Oct 2023 04:38:23 -0400 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.65]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EC3F3106; Fri, 27 Oct 2023 01:38:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1698395901; x=1729931901; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=SBl7gvq5bTKZ2qBWsxuRcqwqbwBEKeoZL83t6kWoQH4=; b=SFzFPe7mCYj6XvD3S4cNgadIpsou6aR/MziGFT3HHEF8QeUNr1L+xast GJgKzbrNQKZICUtEzJZNu1vFskr8/sN92HOgFDA8qX9UZQVoNIn1EPGsM RqX1cEHT2e+lou2pLm7XazRsg5aMT5EkckdC7mSWbN/dV2oWKzCzhbVvH SGktee8bnaijwEBeb1H9nc/94zl42YJGUTp0Uxlz7lmbsO4K8DDwnm0uN 8ylsuBlZbhLk0LNFWc7TQ9cWIDa/Zn6gTCCkyZ+hP4mgu7PTLk/FxUDnl YRj6Yp/z6aUo02Cjv0EXaj5XCYKqm/vAk31WPbcP3cV/WXkNXkjzvxBZ9 g==; X-IronPort-AV: E=McAfee;i="6600,9927,10875"; a="391609777" X-IronPort-AV: E=Sophos;i="6.03,255,1694761200"; d="scan'208";a="391609777" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Oct 2023 01:38:20 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10875"; a="753056267" X-IronPort-AV: E=Sophos;i="6.03,255,1694761200"; d="scan'208";a="753056267" Received: from amyachev-mobl3.ccr.corp.intel.com (HELO localhost) ([10.252.49.46]) by orsmga007-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Oct 2023 01:38:18 -0700 From: =?utf-8?q?Ilpo_J=C3=A4rvinen?= <ilpo.jarvinen@linux.intel.com> To: Bjorn Helgaas <bhelgaas@google.com>, linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org Cc: =?utf-8?q?Ilpo_J=C3=A4rvinen?= <ilpo.jarvinen@linux.intel.com> Subject: [PATCH 1/1] PCI: Use FIELD_PREP() and remove *_SHIFT defines Date: Fri, 27 Oct 2023 11:38:11 +0300 Message-Id: <20231027083811.9200-1-ilpo.jarvinen@linux.intel.com> X-Mailer: git-send-email 2.30.2 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,RCVD_IN_DNSWL_BLOCKED, SPF_HELO_NONE,SPF_NONE,URIBL_BLOCKED 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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (snail.vger.email [0.0.0.0]); Fri, 27 Oct 2023 01:38:38 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1780897200042961664 X-GMAIL-MSGID: 1780897200042961664 |
Series |
[1/1] PCI: Use FIELD_PREP() and remove *_SHIFT defines
|
|
Commit Message
Ilpo Järvinen
Oct. 27, 2023, 8:38 a.m. UTC
Instead of open-coded masking and shifting with PCI_CONF1_* bitfields,
use GENMASK() and FIELD_PREP(), and then remove the *_SHIFT defines
that are no longer needed.
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
---
drivers/pci/pci.h | 23 ++++++++++-------------
1 file changed, 10 insertions(+), 13 deletions(-)
Comments
On Fri, Oct 27, 2023 at 11:38:11AM +0300, Ilpo Järvinen wrote: > Instead of open-coded masking and shifting with PCI_CONF1_* bitfields, > use GENMASK() and FIELD_PREP(), and then remove the *_SHIFT defines > that are no longer needed. > > Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> > --- > > drivers/pci/pci.h | 23 ++++++++++------------- > 1 file changed, 10 insertions(+), 13 deletions(-) > > diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h > index 39a8932dc340..31da9fde8aca 100644 > --- a/drivers/pci/pci.h > +++ b/drivers/pci/pci.h > @@ -2,6 +2,8 @@ > #ifndef DRIVERS_PCI_H > #define DRIVERS_PCI_H > > +#include <linux/bitfield.h> > +#include <linux/bits.h> > #include <linux/pci.h> > > /* Number of possible devfns: 0.0 to 1f.7 inclusive */ > @@ -797,19 +799,15 @@ static inline pci_power_t mid_pci_get_power_state(struct pci_dev *pdev) > * Section 3.2.2.3.2, Figure 3-2, p. 50. > */ > > -#define PCI_CONF1_BUS_SHIFT 16 /* Bus number */ > -#define PCI_CONF1_DEV_SHIFT 11 /* Device number */ > -#define PCI_CONF1_FUNC_SHIFT 8 /* Function number */ > - > -#define PCI_CONF1_BUS_MASK 0xff > -#define PCI_CONF1_DEV_MASK 0x1f > -#define PCI_CONF1_FUNC_MASK 0x7 > +#define PCI_CONF1_BUS_MASK GENMASK(23, 16) > +#define PCI_CONF1_DEV_MASK GENMASK(15, 11) > +#define PCI_CONF1_FUNC_MASK GENMASK(10, 8) > #define PCI_CONF1_REG_MASK 0xfc /* Limit aligned offset to a maximum of 256B */ > > #define PCI_CONF1_ENABLE BIT(31) > -#define PCI_CONF1_BUS(x) (((x) & PCI_CONF1_BUS_MASK) << PCI_CONF1_BUS_SHIFT) > -#define PCI_CONF1_DEV(x) (((x) & PCI_CONF1_DEV_MASK) << PCI_CONF1_DEV_SHIFT) > -#define PCI_CONF1_FUNC(x) (((x) & PCI_CONF1_FUNC_MASK) << PCI_CONF1_FUNC_SHIFT) > +#define PCI_CONF1_BUS(x) FIELD_PREP(PCI_CONF1_BUS_MASK, (x)) > +#define PCI_CONF1_DEV(x) FIELD_PREP(PCI_CONF1_DEV_MASK, (x)) > +#define PCI_CONF1_FUNC(x) FIELD_PREP(PCI_CONF1_FUNC_MASK, (x)) > #define PCI_CONF1_REG(x) ((x) & PCI_CONF1_REG_MASK) I love getting rid of the _SHIFT #defines. I'm a dinosaur and haven't been completely converted to the wonders of GENMASK yet. PCI_CONF1_ADDRESS is the only user of PCI_CONF1_BUS etc, so I think this would be simpler overall: #define PCI_CONF1_BUS 0x00ff0000 #define PCI_CONF1_DEV 0x0000f800 #define PCI_CONF1_FUNC 0x00000700 #define PCI_CONF1_REG 0x000000ff #define PCI_CONF1_ADDRESS(bus, dev, func, reg) \ (FIELD_PREP(PCI_CONF1_BUS, (bus)) | \ FIELD_PREP(PCI_CONF1_DEV, (dev)) | \ FIELD_PREP(PCI_CONF1_FUNC, (func)) | \ FIELD_PREP(PCI_CONF1_REG, (reg & ~0x3))) The v6.7 merge window just opened, and I won't start merging v6.8 material until v6.7-rc1 (probably Nov 12), so no hurry on this. Bjorn
On Tue, 31 Oct 2023, Bjorn Helgaas wrote: > On Fri, Oct 27, 2023 at 11:38:11AM +0300, Ilpo Järvinen wrote: > > Instead of open-coded masking and shifting with PCI_CONF1_* bitfields, > > use GENMASK() and FIELD_PREP(), and then remove the *_SHIFT defines > > that are no longer needed. > > @@ -797,19 +799,15 @@ static inline pci_power_t mid_pci_get_power_state(struct pci_dev *pdev) > > * Section 3.2.2.3.2, Figure 3-2, p. 50. > > */ > > > > -#define PCI_CONF1_BUS_SHIFT 16 /* Bus number */ > > -#define PCI_CONF1_DEV_SHIFT 11 /* Device number */ > > -#define PCI_CONF1_FUNC_SHIFT 8 /* Function number */ > > - > > -#define PCI_CONF1_BUS_MASK 0xff > > -#define PCI_CONF1_DEV_MASK 0x1f > > -#define PCI_CONF1_FUNC_MASK 0x7 > > +#define PCI_CONF1_BUS_MASK GENMASK(23, 16) > > +#define PCI_CONF1_DEV_MASK GENMASK(15, 11) > > +#define PCI_CONF1_FUNC_MASK GENMASK(10, 8) > > #define PCI_CONF1_REG_MASK 0xfc /* Limit aligned offset to a maximum of 256B */ > > > > #define PCI_CONF1_ENABLE BIT(31) > > -#define PCI_CONF1_BUS(x) (((x) & PCI_CONF1_BUS_MASK) << PCI_CONF1_BUS_SHIFT) > > -#define PCI_CONF1_DEV(x) (((x) & PCI_CONF1_DEV_MASK) << PCI_CONF1_DEV_SHIFT) > > -#define PCI_CONF1_FUNC(x) (((x) & PCI_CONF1_FUNC_MASK) << PCI_CONF1_FUNC_SHIFT) > > +#define PCI_CONF1_BUS(x) FIELD_PREP(PCI_CONF1_BUS_MASK, (x)) > > +#define PCI_CONF1_DEV(x) FIELD_PREP(PCI_CONF1_DEV_MASK, (x)) > > +#define PCI_CONF1_FUNC(x) FIELD_PREP(PCI_CONF1_FUNC_MASK, (x)) > > #define PCI_CONF1_REG(x) ((x) & PCI_CONF1_REG_MASK) > > I love getting rid of the _SHIFT #defines. > > I'm a dinosaur and haven't been completely converted to the wonders of > GENMASK yet. Okay but would it convince even "a dinosaur" like you :-) if you imagine a Bit Location column in some spec which says: 23:16 GENMASK just happens to mystically repeat those two numbers: GENMASK(23, 16) Pretty magic, isn't it? > PCI_CONF1_ADDRESS is the only user of PCI_CONF1_BUS etc, > so I think this would be simpler overall: > > #define PCI_CONF1_BUS 0x00ff0000 > #define PCI_CONF1_DEV 0x0000f800 > #define PCI_CONF1_FUNC 0x00000700 > #define PCI_CONF1_REG 0x000000ff > > #define PCI_CONF1_ADDRESS(bus, dev, func, reg) \ > (FIELD_PREP(PCI_CONF1_BUS, (bus)) | \ > FIELD_PREP(PCI_CONF1_DEV, (dev)) | \ > FIELD_PREP(PCI_CONF1_FUNC, (func)) | \ > FIELD_PREP(PCI_CONF1_REG, (reg & ~0x3))) Yes, it makes sense to remove the extra layer. One additional thing, I just noticed lots of arch/ code is duplicating this calculation so perhaps this should also be moved outside of drivers/pci/ into include/linux/pci.h ? (Not in the same patch.) > The v6.7 merge window just opened, and I won't start merging v6.8 > material until v6.7-rc1 (probably Nov 12), so no hurry on this. Yes I knew I was sending it quite late because I tried to meet your request in getting it all done in the same merge window (which I obviously failed but it isn't the end of the world).
On Fri, 3 Nov 2023, Ilpo Järvinen wrote: > On Tue, 31 Oct 2023, Bjorn Helgaas wrote: > > On Fri, Oct 27, 2023 at 11:38:11AM +0300, Ilpo Järvinen wrote: > > > Instead of open-coded masking and shifting with PCI_CONF1_* bitfields, > > > use GENMASK() and FIELD_PREP(), and then remove the *_SHIFT defines > > > that are no longer needed. > > > > @@ -797,19 +799,15 @@ static inline pci_power_t mid_pci_get_power_state(struct pci_dev *pdev) > > > * Section 3.2.2.3.2, Figure 3-2, p. 50. > > > */ > > > > > > -#define PCI_CONF1_BUS_SHIFT 16 /* Bus number */ > > > -#define PCI_CONF1_DEV_SHIFT 11 /* Device number */ > > > -#define PCI_CONF1_FUNC_SHIFT 8 /* Function number */ > > > - > > > -#define PCI_CONF1_BUS_MASK 0xff > > > -#define PCI_CONF1_DEV_MASK 0x1f > > > -#define PCI_CONF1_FUNC_MASK 0x7 > > > +#define PCI_CONF1_BUS_MASK GENMASK(23, 16) > > > +#define PCI_CONF1_DEV_MASK GENMASK(15, 11) > > > +#define PCI_CONF1_FUNC_MASK GENMASK(10, 8) > > > #define PCI_CONF1_REG_MASK 0xfc /* Limit aligned offset to a maximum of 256B */ > > > > > > #define PCI_CONF1_ENABLE BIT(31) > > > -#define PCI_CONF1_BUS(x) (((x) & PCI_CONF1_BUS_MASK) << PCI_CONF1_BUS_SHIFT) > > > -#define PCI_CONF1_DEV(x) (((x) & PCI_CONF1_DEV_MASK) << PCI_CONF1_DEV_SHIFT) > > > -#define PCI_CONF1_FUNC(x) (((x) & PCI_CONF1_FUNC_MASK) << PCI_CONF1_FUNC_SHIFT) > > > +#define PCI_CONF1_BUS(x) FIELD_PREP(PCI_CONF1_BUS_MASK, (x)) > > > +#define PCI_CONF1_DEV(x) FIELD_PREP(PCI_CONF1_DEV_MASK, (x)) > > > +#define PCI_CONF1_FUNC(x) FIELD_PREP(PCI_CONF1_FUNC_MASK, (x)) > > > #define PCI_CONF1_REG(x) ((x) & PCI_CONF1_REG_MASK) > > > > I love getting rid of the _SHIFT #defines. > > > > I'm a dinosaur and haven't been completely converted to the wonders of > > GENMASK yet. > > Okay but would it convince even "a dinosaur" like you :-) if you imagine > a Bit Location column in some spec which says: > 23:16 > > GENMASK just happens to mystically repeat those two numbers: > GENMASK(23, 16) > > Pretty magic, isn't it? > > > PCI_CONF1_ADDRESS is the only user of PCI_CONF1_BUS etc, > > so I think this would be simpler overall: > > > > #define PCI_CONF1_BUS 0x00ff0000 > > #define PCI_CONF1_DEV 0x0000f800 > > #define PCI_CONF1_FUNC 0x00000700 > > #define PCI_CONF1_REG 0x000000ff > > > > #define PCI_CONF1_ADDRESS(bus, dev, func, reg) \ > > (FIELD_PREP(PCI_CONF1_BUS, (bus)) | \ > > FIELD_PREP(PCI_CONF1_DEV, (dev)) | \ > > FIELD_PREP(PCI_CONF1_FUNC, (func)) | \ > > FIELD_PREP(PCI_CONF1_REG, (reg & ~0x3))) This ended up not working, because FIELD_PREP() detects ext regs not fitting into PCI_CONF1_REG: FIELD_PREP(PCI_CONF1_REG, (reg) & ~0x3) There are two partially overlapping things here when it comes to reg (addressing side and parameter input side): #define PCI_CONF1_REG_ADDR 0x000000ff // for PCI_CONF1_EXT_ADDRESS: #define PCI_CONF1_EXT_REG_ADDR 0x0f000000 /* PCI Config register (parameter input side) */ #define PCI_CONF1_REG 0x0fc #define PCI_CONF1_EXT_REG 0xf00 Would those 4 defines be acceptable? Or should I mark the input side with _IN or use different prefix for the defines? > Yes, it makes sense to remove the extra layer. > > One additional thing, I just noticed lots of arch/ code is duplicating > this calculation so perhaps this should also be moved outside of > drivers/pci/ into include/linux/pci.h ? (Not in the same patch.) I also noticed you took PCI_CONF1_ENABLE away from PCI_CONF1_ADDRESS(), did you intend for it to be moved at the caller site? Moving it outside of PCI_CONF1_ADDRESS() would certainly help reusing this code as notall arch code wants PCI_CONF1_ENABLE I think. > > The v6.7 merge window just opened, and I won't start merging v6.8 > > material until v6.7-rc1 (probably Nov 12), so no hurry on this. > > Yes I knew I was sending it quite late because I tried to meet your > request in getting it all done in the same merge window (which I > obviously failed but it isn't the end of the world). > >
On Fri, Nov 03, 2023 at 04:07:19PM +0200, Ilpo Järvinen wrote: > On Fri, 3 Nov 2023, Ilpo Järvinen wrote: > > > On Tue, 31 Oct 2023, Bjorn Helgaas wrote: > > > On Fri, Oct 27, 2023 at 11:38:11AM +0300, Ilpo Järvinen wrote: > > > > Instead of open-coded masking and shifting with PCI_CONF1_* bitfields, > > > > use GENMASK() and FIELD_PREP(), and then remove the *_SHIFT defines > > > > that are no longer needed. > > > > > > @@ -797,19 +799,15 @@ static inline pci_power_t mid_pci_get_power_state(struct pci_dev *pdev) > > > > * Section 3.2.2.3.2, Figure 3-2, p. 50. > > > > */ > > > > > > > > -#define PCI_CONF1_BUS_SHIFT 16 /* Bus number */ > > > > -#define PCI_CONF1_DEV_SHIFT 11 /* Device number */ > > > > -#define PCI_CONF1_FUNC_SHIFT 8 /* Function number */ > > > > - > > > > -#define PCI_CONF1_BUS_MASK 0xff > > > > -#define PCI_CONF1_DEV_MASK 0x1f > > > > -#define PCI_CONF1_FUNC_MASK 0x7 > > > > +#define PCI_CONF1_BUS_MASK GENMASK(23, 16) > > > > +#define PCI_CONF1_DEV_MASK GENMASK(15, 11) > > > > +#define PCI_CONF1_FUNC_MASK GENMASK(10, 8) > > > > #define PCI_CONF1_REG_MASK 0xfc /* Limit aligned offset to a maximum of 256B */ > > > > > > > > #define PCI_CONF1_ENABLE BIT(31) > > > > -#define PCI_CONF1_BUS(x) (((x) & PCI_CONF1_BUS_MASK) << PCI_CONF1_BUS_SHIFT) > > > > -#define PCI_CONF1_DEV(x) (((x) & PCI_CONF1_DEV_MASK) << PCI_CONF1_DEV_SHIFT) > > > > -#define PCI_CONF1_FUNC(x) (((x) & PCI_CONF1_FUNC_MASK) << PCI_CONF1_FUNC_SHIFT) > > > > +#define PCI_CONF1_BUS(x) FIELD_PREP(PCI_CONF1_BUS_MASK, (x)) > > > > +#define PCI_CONF1_DEV(x) FIELD_PREP(PCI_CONF1_DEV_MASK, (x)) > > > > +#define PCI_CONF1_FUNC(x) FIELD_PREP(PCI_CONF1_FUNC_MASK, (x)) > > > > #define PCI_CONF1_REG(x) ((x) & PCI_CONF1_REG_MASK) > > > > > > I love getting rid of the _SHIFT #defines. > > > > > > I'm a dinosaur and haven't been completely converted to the wonders of > > > GENMASK yet. > > > > Okay but would it convince even "a dinosaur" like you :-) if you imagine > > a Bit Location column in some spec which says: > > 23:16 > > > > GENMASK just happens to mystically repeat those two numbers: > > GENMASK(23, 16) > > > > Pretty magic, isn't it? > > > > > PCI_CONF1_ADDRESS is the only user of PCI_CONF1_BUS etc, > > > so I think this would be simpler overall: > > > > > > #define PCI_CONF1_BUS 0x00ff0000 > > > #define PCI_CONF1_DEV 0x0000f800 > > > #define PCI_CONF1_FUNC 0x00000700 > > > #define PCI_CONF1_REG 0x000000ff > > > > > > #define PCI_CONF1_ADDRESS(bus, dev, func, reg) \ > > > (FIELD_PREP(PCI_CONF1_BUS, (bus)) | \ > > > FIELD_PREP(PCI_CONF1_DEV, (dev)) | \ > > > FIELD_PREP(PCI_CONF1_FUNC, (func)) | \ > > > FIELD_PREP(PCI_CONF1_REG, (reg & ~0x3))) > > This ended up not working, because FIELD_PREP() detects ext regs not > fitting into PCI_CONF1_REG: > FIELD_PREP(PCI_CONF1_REG, (reg) & ~0x3) > > There are two partially overlapping things here when it comes to reg > (addressing side and parameter input side): > > #define PCI_CONF1_REG_ADDR 0x000000ff > // for PCI_CONF1_EXT_ADDRESS: > #define PCI_CONF1_EXT_REG_ADDR 0x0f000000 > > /* PCI Config register (parameter input side) */ > #define PCI_CONF1_REG 0x0fc > #define PCI_CONF1_EXT_REG 0xf00 > > Would those 4 defines be acceptable? Or should I mark the input side with > _IN or use different prefix for the defines? No opinion here yet. Maybe PCI_CONF1_EXT_ADDRESS() needs to explicitly pull out the low 8 bits before giving them to PCI_CONF1_ADDRESS()? > > Yes, it makes sense to remove the extra layer. > > > > One additional thing, I just noticed lots of arch/ code is duplicating > > this calculation so perhaps this should also be moved outside of > > drivers/pci/ into include/linux/pci.h ? (Not in the same patch.) > > I also noticed you took PCI_CONF1_ENABLE away from PCI_CONF1_ADDRESS(), > did you intend for it to be moved at the caller site? > > Moving it outside of PCI_CONF1_ADDRESS() would certainly help reusing this > code as notall arch code wants PCI_CONF1_ENABLE I think. Honestly, I didn't think about PCI_CONF1_ENABLE; I just wanted to show the idea of using FIELD_PREP() directly in PCI_CONF1_ADDRESS(). I *did* later think that the "& ~0x3" part maybe doesn't belong in PCI_CONF1_ADDRESS(), since that's really connected with the use of readl()/writel() in the caller. Hmmm, I guess only faraday_raw_pci_read_config() and ixp4xx_config_addr() actually use this. Maybe those places should mask out the low bits themselves? Maybe the same with PCI_CONF1_ENABLE, since ixp4xx_config_addr() removes that bit anyway? Not sure. Bjorn
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h index 39a8932dc340..31da9fde8aca 100644 --- a/drivers/pci/pci.h +++ b/drivers/pci/pci.h @@ -2,6 +2,8 @@ #ifndef DRIVERS_PCI_H #define DRIVERS_PCI_H +#include <linux/bitfield.h> +#include <linux/bits.h> #include <linux/pci.h> /* Number of possible devfns: 0.0 to 1f.7 inclusive */ @@ -797,19 +799,15 @@ static inline pci_power_t mid_pci_get_power_state(struct pci_dev *pdev) * Section 3.2.2.3.2, Figure 3-2, p. 50. */ -#define PCI_CONF1_BUS_SHIFT 16 /* Bus number */ -#define PCI_CONF1_DEV_SHIFT 11 /* Device number */ -#define PCI_CONF1_FUNC_SHIFT 8 /* Function number */ - -#define PCI_CONF1_BUS_MASK 0xff -#define PCI_CONF1_DEV_MASK 0x1f -#define PCI_CONF1_FUNC_MASK 0x7 +#define PCI_CONF1_BUS_MASK GENMASK(23, 16) +#define PCI_CONF1_DEV_MASK GENMASK(15, 11) +#define PCI_CONF1_FUNC_MASK GENMASK(10, 8) #define PCI_CONF1_REG_MASK 0xfc /* Limit aligned offset to a maximum of 256B */ #define PCI_CONF1_ENABLE BIT(31) -#define PCI_CONF1_BUS(x) (((x) & PCI_CONF1_BUS_MASK) << PCI_CONF1_BUS_SHIFT) -#define PCI_CONF1_DEV(x) (((x) & PCI_CONF1_DEV_MASK) << PCI_CONF1_DEV_SHIFT) -#define PCI_CONF1_FUNC(x) (((x) & PCI_CONF1_FUNC_MASK) << PCI_CONF1_FUNC_SHIFT) +#define PCI_CONF1_BUS(x) FIELD_PREP(PCI_CONF1_BUS_MASK, (x)) +#define PCI_CONF1_DEV(x) FIELD_PREP(PCI_CONF1_DEV_MASK, (x)) +#define PCI_CONF1_FUNC(x) FIELD_PREP(PCI_CONF1_FUNC_MASK, (x)) #define PCI_CONF1_REG(x) ((x) & PCI_CONF1_REG_MASK) #define PCI_CONF1_ADDRESS(bus, dev, func, reg) \ @@ -827,9 +825,8 @@ static inline pci_power_t mid_pci_get_power_state(struct pci_dev *pdev) * are used for specifying additional 4 high bits of PCI Express register. */ -#define PCI_CONF1_EXT_REG_SHIFT 16 -#define PCI_CONF1_EXT_REG_MASK 0xf00 -#define PCI_CONF1_EXT_REG(x) (((x) & PCI_CONF1_EXT_REG_MASK) << PCI_CONF1_EXT_REG_SHIFT) +#define PCI_CONF1_EXT_REG_MASK GENMASK(27, 24) +#define PCI_CONF1_EXT_REG(x) FIELD_PREP(PCI_CONF1_EXT_REG_MASK, (x) >> 8) #define PCI_CONF1_EXT_ADDRESS(bus, dev, func, reg) \ (PCI_CONF1_ADDRESS(bus, dev, func, reg) | \