patches for DPDK stable branches
 help / color / mirror / Atom feed
From: "Sevincer, Abdullah" <abdullah.sevincer@intel.com>
To: Jerin Jacob <jerinjacobk@gmail.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
	"jerinj@marvell.com" <jerinj@marvell.com>,
	 "Chen, Mike Ximing" <mike.ximing.chen@intel.com>,
	"Richardson, Bruce" <bruce.richardson@intel.com>,
	"stable@dpdk.org" <stable@dpdk.org>
Subject: RE: [PATCH v3] event/dlb2: fix disable PASID for kernel 6.2
Date: Tue, 31 Oct 2023 15:13:46 +0000	[thread overview]
Message-ID: <BYAPR11MB315806B04257956B084B1F83E9A0A@BYAPR11MB3158.namprd11.prod.outlook.com> (raw)
In-Reply-To: <CALBAE1P5OmQ90+RsnqVUYjo7SVE6CpPG168aP67NgmFPHhRuNw@mail.gmail.com>


> +This patch can be splited as two,
> +1) Generic PCIe function to enable/disable PASID
> +2) Call generic function to disable PASID in drivers/event/dlb2/. Also mention which Linux kernel commit is introducing this issue in the git commit log.

Hi Jerrin,
I think I need to provide more information here, then we can decide which way we will go would be good for now. I agree to having 2 functions in pci common 
code to enable/disable PASID, but we need to have hardcoded PASID cap offset inside these functions as well since PASID capability is not exposed to user. Hence, to be more specific 
main reason to have hardcoded PASID is, rte_pci_find_ext_capability() function to retrieve the offset returns '0' since PASID is not exposed to user yet. 

We can see this is vfio_pci_config.c in kernel code where PASID is not exposed to user.
[PCI_EXT_CAP_ID_PASID]	=	0,	/* not yet */

So if it is okay to go with hardcoded offset now in these functions I will move the implementation to pci_common file.

  reply	other threads:[~2023-10-31 15:13 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20230607210050.107944-1-abdullah.sevincer@intel.com>
2023-10-30 21:12 ` Abdullah Sevincer
2023-10-31  8:21   ` Jerin Jacob
2023-10-31 15:13     ` Sevincer, Abdullah [this message]
2023-10-31 17:06       ` Jerin Jacob
2023-10-31 17:15         ` Bruce Richardson
2023-10-31 18:42           ` Jerin Jacob
2023-10-31 20:44             ` Bruce Richardson
2023-11-01  4:51               ` Jerin Jacob
2023-11-01 19:05                 ` Sevincer, Abdullah
2023-11-02 10:23                   ` Bruce Richardson
2023-11-02 10:48                     ` Thomas Monjalon
2023-11-02 18:17                       ` Sevincer, Abdullah

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=BYAPR11MB315806B04257956B084B1F83E9A0A@BYAPR11MB3158.namprd11.prod.outlook.com \
    --to=abdullah.sevincer@intel.com \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=jerinj@marvell.com \
    --cc=jerinjacobk@gmail.com \
    --cc=mike.ximing.chen@intel.com \
    --cc=stable@dpdk.org \
    /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;
as well as URLs for NNTP newsgroup(s).