From: DongdongZhang <zhangdongdong@eswincomputing.com>
To: "Alex Williamson" <alex.williamson@redhat.com>
Cc: bhelgaas@google.com, yishaih@nvidia.com, avihaih@nvidia.com,
yi.l.liu@intel.com, ankita@nvidia.com, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org
Subject: Re: Re: [PATCH v2] PCI: Remove redundant macro
Date: Fri, 3 Jan 2025 11:03:56 +0800 (GMT+08:00) [thread overview]
Message-ID: <29fffca1.18a8.1942a1e9aa0.Coremail.zhangdongdong@eswincomputing.com> (raw)
In-Reply-To: <20250102165004.2470fbb0.alex.williamson@redhat.com>
Hi Alex,
Thank you for the review and for providing your Acked-by!
I agree that this patch primarily involves PCI changes,
including a modification to PCI UAPI. Therefore, I believe
it would make the most sense to have it go through the PCI tree.
Please let me know if there are any additional steps I
should take to ensure a smooth submission.
Thanks again for your time and support!
Best regards,
Dongdong Zhang
> -----原始邮件-----
> 发件人: "Alex Williamson" <alex.williamson@redhat.com>
> 发送时间:2025-01-03 07:50:04 (星期五)
> 收件人: zhangdongdong@eswincomputing.com
> 抄送: bhelgaas@google.com, yishaih@nvidia.com, avihaih@nvidia.com, yi.l.liu@intel.com, ankita@nvidia.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org
> 主题: Re: [PATCH v2] PCI: Remove redundant macro
>
> On Mon, 16 Dec 2024 09:35:36 +0800
> zhangdongdong@eswincomputing.com wrote:
>
> > From: Dongdong Zhang <zhangdongdong@eswincomputing.com>
> >
> > Removed the duplicate macro `PCI_VSEC_HDR` and its related macro
> > `PCI_VSEC_HDR_LEN_SHIFT` from `pci_regs.h` to avoid redundancy and
> > inconsistencies. Updated VFIO PCI code to use `PCI_VNDR_HEADER` and
> > `PCI_VNDR_HEADER_LEN()` for consistent naming and functionality.
> >
> > These changes aim to streamline header handling while minimizing
> > impact, given the niche usage of these macros in userspace.
> >
> > Signed-off-by: Dongdong Zhang <zhangdongdong@eswincomputing.com>
> > ---
> > drivers/vfio/pci/vfio_pci_config.c | 5 +++--
>
> Acked-by: Alex Williamson <alex.williamson@redhat.com>
>
> Let me know if this is expected to go through the vfio tree. Given
> that vfio is just collateral to a PCI change and it's touching PCI
> uapi, I'm assuming it'll go through the PCI tree. Thanks,
>
> Alex
>
> > include/uapi/linux/pci_regs.h | 3 ---
> > 2 files changed, 3 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/vfio/pci/vfio_pci_config.c b/drivers/vfio/pci/vfio_pci_config.c
> > index ea2745c1ac5e..5572fd99b921 100644
> > --- a/drivers/vfio/pci/vfio_pci_config.c
> > +++ b/drivers/vfio/pci/vfio_pci_config.c
> > @@ -1389,11 +1389,12 @@ static int vfio_ext_cap_len(struct vfio_pci_core_device *vdev, u16 ecap, u16 epo
> >
> > switch (ecap) {
> > case PCI_EXT_CAP_ID_VNDR:
> > - ret = pci_read_config_dword(pdev, epos + PCI_VSEC_HDR, &dword);
> > + ret = pci_read_config_dword(pdev, epos + PCI_VNDR_HEADER,
> > + &dword);
> > if (ret)
> > return pcibios_err_to_errno(ret);
> >
> > - return dword >> PCI_VSEC_HDR_LEN_SHIFT;
> > + return PCI_VNDR_HEADER_LEN(dword);
> > case PCI_EXT_CAP_ID_VC:
> > case PCI_EXT_CAP_ID_VC9:
> > case PCI_EXT_CAP_ID_MFVC:
> > diff --git a/include/uapi/linux/pci_regs.h b/include/uapi/linux/pci_regs.h
> > index 1601c7ed5fab..bcd44c7ca048 100644
> > --- a/include/uapi/linux/pci_regs.h
> > +++ b/include/uapi/linux/pci_regs.h
> > @@ -1001,9 +1001,6 @@
> > #define PCI_ACS_CTRL 0x06 /* ACS Control Register */
> > #define PCI_ACS_EGRESS_CTL_V 0x08 /* ACS Egress Control Vector */
> >
> > -#define PCI_VSEC_HDR 4 /* extended cap - vendor-specific */
> > -#define PCI_VSEC_HDR_LEN_SHIFT 20 /* shift for length field */
> > -
> > /* SATA capability */
> > #define PCI_SATA_REGS 4 /* SATA REGs specifier */
> > #define PCI_SATA_REGS_MASK 0xF /* location - BAR#/inline */
next prev parent reply other threads:[~2025-01-03 3:04 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-16 1:35 [PATCH v2] PCI: Remove redundant macro zhangdongdong
2025-01-02 23:50 ` Alex Williamson
2025-01-03 3:03 ` DongdongZhang [this message]
2025-01-03 20:34 ` Bjorn Helgaas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=29fffca1.18a8.1942a1e9aa0.Coremail.zhangdongdong@eswincomputing.com \
--to=zhangdongdong@eswincomputing.com \
--cc=alex.williamson@redhat.com \
--cc=ankita@nvidia.com \
--cc=avihaih@nvidia.com \
--cc=bhelgaas@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=yi.l.liu@intel.com \
--cc=yishaih@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox