From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.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 F096D1A8F71 for ; Thu, 2 Jan 2025 23:50:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1735861812; cv=none; b=eAqFtlTUAL60NP+g2ktXbtvswQMarVx5VurKWcFIUnIG8TaphglClMFuaqLjiuoo2mM/8becz/0/Pj2tPxxiZPz18xge2Gkj1KQ894+mPa9nDsA7n7PKTNjM36fkYj95nU2LtPUKUfZW61lQadXGAWVnb/bNQNGeiz315Xr+U2Y= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1735861812; c=relaxed/simple; bh=P3f0e0KsZC3uxVFqjTtm1/WBjQsByv+LK7vD91x80rY=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=AkvCQYSJq4CQhb0sBxr9j0yG2X3XZsNKDsUFX1ERcUBBxWl2hdNhXY7ZUf9X2RI6jMEbmf8l7QohUFwiz9c8kzWKYb5xLIHutchD4XH1ckeX3Iwwv2s8r1G/2rkKo2gQ99H5ocwN0ZP2plC5npYtynHkEBhDjuM06HXVfb+GYdc= 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=KCcAe/Pf; arc=none smtp.client-ip=170.10.129.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 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="KCcAe/Pf" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1735861808; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=+31JuwM03Y6EdVp3v3LgbQg7ZDKiY/lu+6/XlJPbttk=; b=KCcAe/PfoPWaSIVFsAXUJsR3lRT8YRsA0y4vKju122nzh8MeNe0fKNUkEeO941c+Wf5zbP 4lvvh+Y0LKSKqe6LbgJ0xT1SRBAXk+4x963dTQRKMdOPUC5QYPkQbhQWJXcvoI+v5zBLaN ukC8ftGO6WIdGuUg5mn3swXwUp88r6k= Received: from mail-il1-f198.google.com (mail-il1-f198.google.com [209.85.166.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-691-3beOYZ1WN3Giq_5Hj7EHVg-1; Thu, 02 Jan 2025 18:50:07 -0500 X-MC-Unique: 3beOYZ1WN3Giq_5Hj7EHVg-1 X-Mimecast-MFC-AGG-ID: 3beOYZ1WN3Giq_5Hj7EHVg Received: by mail-il1-f198.google.com with SMTP id e9e14a558f8ab-3a817a1106bso14483195ab.1 for ; Thu, 02 Jan 2025 15:50:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1735861807; x=1736466607; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=+31JuwM03Y6EdVp3v3LgbQg7ZDKiY/lu+6/XlJPbttk=; b=oAkKnPwqEd7YeKF1+LF3vZg46juhusCTBHkyjgosiKdYUJ3vAwslpemC7eNAoagGT+ g3ICDvDrb3obmxXU+HbWfVrjR23YJXsb+Zp4SxrO77VDx+rZ7v/CpZOgdQkQmfwiPrzh wYNlHOpoOxgyCKB4Fy4VVYRf/QzE7GFy/MkZiR7NTSy3cTAXcnWUu1RndLeuTAmtLoU/ JLBubbvI8ea9gvxEfF8YciPPQn7bC7jS2TmAlrW+vmGCqZPmPxWBqy/KRmHEGsszwkyq Im9NEKRNGEsON5h9B2jzDmc8hyNkuJttJNnunXFiUNICb3pQ9e1RxOqPq6EZIjBQ4S65 dung== X-Forwarded-Encrypted: i=1; AJvYcCW7ejB9XMptps93zCZfXkJqKRNAaB7ToQPH1UmQIcf2PuKgfB5joScPAID3cAhOfC9NVPJNXiZjFM37XKE=@vger.kernel.org X-Gm-Message-State: AOJu0YyarxXjU1LINd0xe+JV1qCbE1Wsx63C99IPDlv0hBxWuWMxVP3z tVWDcJ0xsNKuUGTAWcBXuRPM+lvPcwZDBl0DAYezc+aQ+6mlom6TzpswKYA8UYLV3BkBBOafzqU hPRnIjvzryZrpby7nnwZvhip9vbgk5uRs4yg8zzVIEhuoLd80hF9NC4xv/Vk5hA== X-Gm-Gg: ASbGnctn4JiGWNuGYq4GI3vckXP6MD0NKSxkjbvCA6LqyXOnOj6ReSt3DCsH26JQxlU /U90U83dM8Vq3oBamJErZCWZh2j1Rc6vK4Ef4IKmP99zUD4Jb4y39i7Aet+FgQ7K9HwQ8cSMZQ/ rZYpJS740iVovcjKHCMgDrslhB6llZHyGDxihHrBMmpyaFlDPNoKxKcNwMjhnuGM1hmhkHG2GwJ urU3jFUogov+k/oPjQ4sBMhgFYDlSRSVWlmb15co2hU5LrKubgp+GDUBm/L X-Received: by 2002:a05:6e02:2198:b0:3a7:bc95:bae5 with SMTP id e9e14a558f8ab-3c2d5247952mr101091325ab.5.1735861806813; Thu, 02 Jan 2025 15:50:06 -0800 (PST) X-Google-Smtp-Source: AGHT+IFPdiuvD3nbQOVUd7KLLxbQIFjMW4WTn8Dgh4Oc4yWHhIFUQMePiqwfOYLyExiaxztN6ea8Zg== X-Received: by 2002:a05:6e02:2198:b0:3a7:bc95:bae5 with SMTP id e9e14a558f8ab-3c2d5247952mr101091245ab.5.1735861806487; Thu, 02 Jan 2025 15:50:06 -0800 (PST) Received: from redhat.com ([38.15.36.11]) by smtp.gmail.com with ESMTPSA id 8926c6da1cb9f-4e68bf4f405sm7075401173.6.2025.01.02.15.50.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 02 Jan 2025 15:50:05 -0800 (PST) Date: Thu, 2 Jan 2025 16:50:04 -0700 From: Alex Williamson To: zhangdongdong@eswincomputing.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: [PATCH v2] PCI: Remove redundant macro Message-ID: <20250102165004.2470fbb0.alex.williamson@redhat.com> In-Reply-To: <20241216013536.4487-1-zhangdongdong@eswincomputing.com> References: <20241216013536.4487-1-zhangdongdong@eswincomputing.com> X-Mailer: Claws Mail 4.3.0 (GTK 3.24.43; x86_64-redhat-linux-gnu) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Mon, 16 Dec 2024 09:35:36 +0800 zhangdongdong@eswincomputing.com wrote: > From: Dongdong Zhang > > 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 > --- > drivers/vfio/pci/vfio_pci_config.c | 5 +++-- Acked-by: Alex Williamson 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 */