linux-kernel - Re: Re: [PATCH v2] PCI: Remove redundant macro

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <29fffca1.18a8.1942a1e9aa0.Coremail.zhangdongdong@eswincomputing.com>
Date: Fri, 3 Jan 2025 11:03:56 +0800 (GMT+08:00)
From: DongdongZhang <zhangdongdong@...incomputing.com>
To: "Alex Williamson" <alex.williamson@...hat.com>
Cc: bhelgaas@...gle.com, yishaih@...dia.com, avihaih@...dia.com,
	yi.l.liu@...el.com, ankita@...dia.com, kvm@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-pci@...r.kernel.org
Subject: Re: Re: [PATCH v2] PCI: Remove redundant macro

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@...hat.com>
> 发送时间:2025-01-03 07:50:04 (星期五)
> 收件人: zhangdongdong@...incomputing.com
> 抄送: bhelgaas@...gle.com, yishaih@...dia.com, avihaih@...dia.com, yi.l.liu@...el.com, ankita@...dia.com, kvm@...r.kernel.org, linux-kernel@...r.kernel.org, linux-pci@...r.kernel.org
> 主题: Re: [PATCH v2] PCI: Remove redundant macro
> 
> On Mon, 16 Dec 2024 09:35:36 +0800
> zhangdongdong@...incomputing.com wrote:
> 
> > From: Dongdong Zhang <zhangdongdong@...incomputing.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@...incomputing.com>
> > ---
> >  drivers/vfio/pci/vfio_pci_config.c | 5 +++--
> 
> Acked-by: Alex Williamson <alex.williamson@...hat.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 */