[PATCH] pci: More PRI/PASID cleanup

[PATCH] pci: More PRI/PASID cleanup

[Alex Williamson]

More consistency cleanups.  Drop the _OFF, separate and indent
CTRL/CAP/STATUS bit definitions, fix that PASID_CAP doesn't
actually report the ENABLE bit.

Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
---

Joerg, I can't test this, so you may want to make sure I'm not
breaking your API.  The March 31, 2011 version of the PASID ECN
shows bit 0 of the PASID capability register as reserved, not
an indicator of support for or status of the enable bit.
Presumably the entire capability wouldn't be included if it
can't be enabled.  With the below, pci_enable_pasid() now checks
the right bit, but also pci_pasid_features() no longer masks in
bit 0, but being reserved, it should have been clear anyway.
Thanks,

Alex

 drivers/pci/ats.c        |   70 +++++++++++++++++++++++-----------------------
 include/linux/pci_regs.h |   30 +++++++++++---------
 2 files changed, 51 insertions(+), 49 deletions(-)

diff --git a/drivers/pci/ats.c b/drivers/pci/ats.c
index 831e192..cc9e8b5 100644
--- a/drivers/pci/ats.c
+++ b/drivers/pci/ats.c
@@ -178,17 +178,18 @@ int pci_enable_pri(struct pci_dev *pdev, u32 reqs)
 	if (!pos)
 		return -EINVAL;
 
-	pci_read_config_word(pdev, pos + PCI_PRI_CONTROL_OFF, &control);
-	pci_read_config_word(pdev, pos + PCI_PRI_STATUS_OFF,  &status);
-	if ((control & PCI_PRI_ENABLE) || !(status & PCI_PRI_STATUS_STOPPED))
+	pci_read_config_word(pdev, pos + PCI_PRI_CTRL, &control);
+	pci_read_config_word(pdev, pos + PCI_PRI_STATUS,  &status);
+	if ((control & PCI_PRI_CTRL_ENABLE) ||
+	    !(status & PCI_PRI_STATUS_STOPPED))
 		return -EBUSY;
 
-	pci_read_config_dword(pdev, pos + PCI_PRI_MAX_REQ_OFF, &max_requests);
+	pci_read_config_dword(pdev, pos + PCI_PRI_MAX_REQ, &max_requests);
 	reqs = min(max_requests, reqs);
-	pci_write_config_dword(pdev, pos + PCI_PRI_ALLOC_REQ_OFF, reqs);
+	pci_write_config_dword(pdev, pos + PCI_PRI_ALLOC_REQ, reqs);
 
-	control |= PCI_PRI_ENABLE;
-	pci_write_config_word(pdev, pos + PCI_PRI_CONTROL_OFF, control);
+	control |= PCI_PRI_CTRL_ENABLE;
+	pci_write_config_word(pdev, pos + PCI_PRI_CTRL, control);
 
 	return 0;
 }
@@ -209,9 +210,9 @@ void pci_disable_pri(struct pci_dev *pdev)
 	if (!pos)
 		return;
 
-	pci_read_config_word(pdev, pos + PCI_PRI_CONTROL_OFF, &control);
-	control &= ~PCI_PRI_ENABLE;
-	pci_write_config_word(pdev, pos + PCI_PRI_CONTROL_OFF, control);
+	pci_read_config_word(pdev, pos + PCI_PRI_CTRL, &control);
+	control &= ~PCI_PRI_CTRL_ENABLE;
+	pci_write_config_word(pdev, pos + PCI_PRI_CTRL, control);
 }
 EXPORT_SYMBOL_GPL(pci_disable_pri);
 
@@ -230,9 +231,9 @@ bool pci_pri_enabled(struct pci_dev *pdev)
 	if (!pos)
 		return false;
 
-	pci_read_config_word(pdev, pos + PCI_PRI_CONTROL_OFF, &control);
+	pci_read_config_word(pdev, pos + PCI_PRI_CTRL, &control);
 
-	return (control & PCI_PRI_ENABLE) ? true : false;
+	return (control & PCI_PRI_CTRL_ENABLE) ? true : false;
 }
 EXPORT_SYMBOL_GPL(pci_pri_enabled);
 
@@ -252,13 +253,13 @@ int pci_reset_pri(struct pci_dev *pdev)
 	if (!pos)
 		return -EINVAL;
 
-	pci_read_config_word(pdev, pos + PCI_PRI_CONTROL_OFF, &control);
-	if (control & PCI_PRI_ENABLE)
+	pci_read_config_word(pdev, pos + PCI_PRI_CTRL, &control);
+	if (control & PCI_PRI_CTRL_ENABLE)
 		return -EBUSY;
 
-	control |= PCI_PRI_RESET;
+	control |= PCI_PRI_CTRL_RESET;
 
-	pci_write_config_word(pdev, pos + PCI_PRI_CONTROL_OFF, control);
+	pci_write_config_word(pdev, pos + PCI_PRI_CTRL, control);
 
 	return 0;
 }
@@ -285,10 +286,10 @@ bool pci_pri_stopped(struct pci_dev *pdev)
 	if (!pos)
 		return true;
 
-	pci_read_config_word(pdev, pos + PCI_PRI_CONTROL_OFF, &control);
-	pci_read_config_word(pdev, pos + PCI_PRI_STATUS_OFF,  &status);
+	pci_read_config_word(pdev, pos + PCI_PRI_CTRL, &control);
+	pci_read_config_word(pdev, pos + PCI_PRI_STATUS,  &status);
 
-	if (control & PCI_PRI_ENABLE)
+	if (control & PCI_PRI_CTRL_ENABLE)
 		return false;
 
 	return (status & PCI_PRI_STATUS_STOPPED) ? true : false;
@@ -314,11 +315,11 @@ int pci_pri_status(struct pci_dev *pdev)
 	if (!pos)
 		return -EINVAL;
 
-	pci_read_config_word(pdev, pos + PCI_PRI_CONTROL_OFF, &control);
-	pci_read_config_word(pdev, pos + PCI_PRI_STATUS_OFF,  &status);
+	pci_read_config_word(pdev, pos + PCI_PRI_CTRL, &control);
+	pci_read_config_word(pdev, pos + PCI_PRI_STATUS,  &status);
 
 	/* Stopped bit is undefined when enable == 1, so clear it */
-	if (control & PCI_PRI_ENABLE)
+	if (control & PCI_PRI_CTRL_ENABLE)
 		status &= ~PCI_PRI_STATUS_STOPPED;
 
 	return status;
@@ -345,21 +346,21 @@ int pci_enable_pasid(struct pci_dev *pdev, int features)
 	if (!pos)
 		return -EINVAL;
 
-	pci_read_config_word(pdev, pos + PCI_PASID_CONTROL_OFF, &control);
-	pci_read_config_word(pdev, pos + PCI_PASID_CAP_OFF,     &supported);
+	pci_read_config_word(pdev, pos + PCI_PASID_CTRL, &control);
+	pci_read_config_word(pdev, pos + PCI_PASID_CAP, &supported);
 
-	if (!(supported & PCI_PASID_ENABLE))
+	if (!(control & PCI_PASID_CTRL_ENABLE))
 		return -EINVAL;
 
-	supported &= PCI_PASID_EXEC | PCI_PASID_PRIV;
+	supported &= PCI_PASID_CAP_EXEC | PCI_PASID_CAP_PRIV;
 
 	/* User wants to enable anything unsupported? */
 	if ((supported & features) != features)
 		return -EINVAL;
 
-	control = PCI_PASID_ENABLE | features;
+	control = PCI_PASID_CTRL_ENABLE | features;
 
-	pci_write_config_word(pdev, pos + PCI_PASID_CONTROL_OFF, control);
+	pci_write_config_word(pdev, pos + PCI_PASID_CTRL, control);
 
 	return 0;
 }
@@ -379,7 +380,7 @@ void pci_disable_pasid(struct pci_dev *pdev)
 	if (!pos)
 		return;
 
-	pci_write_config_word(pdev, pos + PCI_PASID_CONTROL_OFF, control);
+	pci_write_config_word(pdev, pos + PCI_PASID_CTRL, control);
 }
 EXPORT_SYMBOL_GPL(pci_disable_pasid);
 
@@ -390,9 +391,8 @@ EXPORT_SYMBOL_GPL(pci_disable_pasid);
  * Returns a negative value when no PASI capability is present.
  * Otherwise is returns a bitmask with supported features. Current
  * features reported are:
- * PCI_PASID_ENABLE - PASID capability can be enabled
- * PCI_PASID_EXEC - Execute permission supported
- * PCI_PASID_PRIV - Priviledged mode supported
+ * PCI_PASID_CAP_EXEC - Execute permission supported
+ * PCI_PASID_CAP_PRIV - Priviledged mode supported
  */
 int pci_pasid_features(struct pci_dev *pdev)
 {
@@ -403,9 +403,9 @@ int pci_pasid_features(struct pci_dev *pdev)
 	if (!pos)
 		return -EINVAL;
 
-	pci_read_config_word(pdev, pos + PCI_PASID_CAP_OFF, &supported);
+	pci_read_config_word(pdev, pos + PCI_PASID_CAP, &supported);
 
-	supported &= PCI_PASID_ENABLE | PCI_PASID_EXEC | PCI_PASID_PRIV;
+	supported &= PCI_PASID_CAP_EXEC | PCI_PASID_CAP_PRIV;
 
 	return supported;
 }
@@ -429,7 +429,7 @@ int pci_max_pasids(struct pci_dev *pdev)
 	if (!pos)
 		return -EINVAL;
 
-	pci_read_config_word(pdev, pos + PCI_PASID_CAP_OFF, &supported);
+	pci_read_config_word(pdev, pos + PCI_PASID_CAP, &supported);
 
 	supported = (supported & PASID_NUMBER_MASK) >> PASID_NUMBER_SHIFT;
 
diff --git a/include/linux/pci_regs.h b/include/linux/pci_regs.h
index 090d3a9..4dc97f6 100644
--- a/include/linux/pci_regs.h
+++ b/include/linux/pci_regs.h
@@ -666,22 +666,24 @@
 #define  PCI_ATS_MIN_STU	12	/* shift of minimum STU block */
 
 /* Page Request Interface */
-#define PCI_PRI_CONTROL_OFF	0x04	/* Offset of control register */
-#define PCI_PRI_STATUS_OFF	0x06	/* Offset of status register */
-#define PCI_PRI_ENABLE		0x0001	/* Enable mask */
-#define PCI_PRI_RESET		0x0002	/* Reset bit mask */
-#define PCI_PRI_STATUS_RF	0x0001  /* Request Failure */
-#define PCI_PRI_STATUS_UPRGI	0x0002  /* Unexpected PRG index */
-#define PCI_PRI_STATUS_STOPPED	0x0100  /* PRI Stopped */
-#define PCI_PRI_MAX_REQ_OFF	0x08	/* Cap offset for max reqs supported */
-#define PCI_PRI_ALLOC_REQ_OFF	0x0c	/* Cap offset for max reqs allowed */
+#define PCI_PRI_CTRL		0x04	/* Offset of control register */
+#define  PCI_PRI_CTRL_ENABLE	0x01	/* Enabled */
+#define  PCI_PRI_CTRL_RESET	0x02	/* Reset */
+#define PCI_PRI_STATUS		0x06	/* Offset of status register */
+#define  PCI_PRI_STATUS_RF	0x001	/* Response Failure */
+#define  PCI_PRI_STATUS_UPRGI	0x002	/* Unexpected PRG index */
+#define  PCI_PRI_STATUS_STOPPED	0x100	/* PRI Stopped */
+#define PCI_PRI_MAX_REQ		0x08	/* Cap offset for max reqs supported */
+#define PCI_PRI_ALLOC_REQ	0x0c	/* Cap offset for max reqs allowed */
 
 /* PASID capability */
-#define PCI_PASID_CAP_OFF	0x04    /* PASID feature register */
-#define PCI_PASID_CONTROL_OFF   0x06    /* PASID control register */
-#define PCI_PASID_ENABLE	0x01	/* Enable/Supported bit */
-#define PCI_PASID_EXEC		0x02	/* Exec permissions Enable/Supported */
-#define PCI_PASID_PRIV		0x04	/* Priviledge Mode Enable/Support */
+#define PCI_PASID_CAP		0x04    /* PASID feature register */
+#define  PCI_PASID_CAP_EXEC	0x02	/* Exec permissions Supported */
+#define  PCI_PASID_CAP_PRIV	0x04	/* Priviledge Mode Supported */
+#define PCI_PASID_CTRL		0x06    /* PASID control register */
+#define  PCI_PASID_CTRL_ENABLE	0x01	/* Enable bit */
+#define  PCI_PASID_CTRL_EXEC	0x02	/* Exec permissions Enable */
+#define  PCI_PASID_CTRL_PRIV	0x04	/* Priviledge Mode Enable */
 
 /* Single Root I/O Virtualization */
 #define PCI_SRIOV_CAP		0x04	/* SR-IOV Capabilities */

Re: [PATCH] pci: More PRI/PASID cleanup

[Roedel, Joerg]

On Wed, Nov 02, 2011 at 11:53:56PM -0400, Alex Williamson wrote:
> More consistency cleanups.  Drop the _OFF, separate and indent
> CTRL/CAP/STATUS bit definitions, fix that PASID_CAP doesn't
> actually report the ENABLE bit.
> 
> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
> ---
> 
> Joerg, I can't test this, so you may want to make sure I'm not
> breaking your API.  The March 31, 2011 version of the PASID ECN
> shows bit 0 of the PASID capability register as reserved, not
> an indicator of support for or status of the enable bit.
> Presumably the entire capability wouldn't be included if it
> can't be enabled.  With the below, pci_enable_pasid() now checks
> the right bit, but also pci_pasid_features() no longer masks in
> bit 0, but being reserved, it should have been clear anyway.

Looks like you are only renaming stuff. I don't see the real point but I
also don't object unless this will be merged upstream soon. I plan to
push the code using these capabilities for the next merge-window and if
this one will me merged then too it will cause a lot of pain.

	
	Joerg

-- 
AMD Operating System Research Center

Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach
General Managers: Alberto Bozzo, Andrew Bowd
Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632

Re: [PATCH] pci: More PRI/PASID cleanup

[Alex Williamson]

On Tue, 2011-11-08 at 17:28 +0100, Roedel, Joerg wrote:
> On Wed, Nov 02, 2011 at 11:53:56PM -0400, Alex Williamson wrote:
> > More consistency cleanups.  Drop the _OFF, separate and indent
> > CTRL/CAP/STATUS bit definitions, fix that PASID_CAP doesn't
> > actually report the ENABLE bit.
> > 
> > Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
> > ---
> > 
> > Joerg, I can't test this, so you may want to make sure I'm not
> > breaking your API.  The March 31, 2011 version of the PASID ECN
> > shows bit 0 of the PASID capability register as reserved, not
> > an indicator of support for or status of the enable bit.
> > Presumably the entire capability wouldn't be included if it
> > can't be enabled.  With the below, pci_enable_pasid() now checks
> > the right bit, but also pci_pasid_features() no longer masks in
> > bit 0, but being reserved, it should have been clear anyway.
> 
> Looks like you are only renaming stuff. I don't see the real point but I
> also don't object unless this will be merged upstream soon. I plan to
> push the code using these capabilities for the next merge-window and if
> this one will me merged then too it will cause a lot of pain.

I'll paste the functional change below, but the renaming pulls PRI/PASID
in line with the rest of the defines in the file.  Consistent naming
promotes proper usage, imho.

 /* PASID capability */
> -#define PCI_PASID_CAP_OFF	0x04    /* PASID feature register */
> -#define PCI_PASID_CONTROL_OFF   0x06    /* PASID control register */
> -#define PCI_PASID_ENABLE	0x01	/* Enable/Supported bit */
> -#define PCI_PASID_EXEC		0x02	/* Exec permissions Enable/Supported */
> -#define PCI_PASID_PRIV		0x04	/* Priviledge Mode Enable/Support */
> +#define PCI_PASID_CAP		0x04    /* PASID feature register */
> +#define  PCI_PASID_CAP_EXEC	0x02	/* Exec permissions Supported */
> +#define  PCI_PASID_CAP_PRIV	0x04	/* Priviledge Mode Supported */
> +#define PCI_PASID_CTRL		0x06    /* PASID control register */
> +#define  PCI_PASID_CTRL_ENABLE	0x01	/* Enable bit */
> +#define  PCI_PASID_CTRL_EXEC	0x02	/* Exec permissions Enable */
> +#define  PCI_PASID_CTRL_PRIV	0x04	/* Priviledge Mode Enable */

bit 0 (PCI_PASID_ENABLE) is reserved in the CAP register...

@@ -345,21 +346,21 @@ int pci_enable_pasid(struct pci_dev *pdev, int features)
>  	if (!pos)
>  		return -EINVAL;
>  
> -	pci_read_config_word(pdev, pos + PCI_PASID_CONTROL_OFF, &control);
> -	pci_read_config_word(pdev, pos + PCI_PASID_CAP_OFF,     &supported);
> +	pci_read_config_word(pdev, pos + PCI_PASID_CTRL, &control);
> +	pci_read_config_word(pdev, pos + PCI_PASID_CAP, &supported);
>  
> -	if (!(supported & PCI_PASID_ENABLE))
> +	if (!(control & PCI_PASID_CTRL_ENABLE))
>  		return -EINVAL;

Which means we need to check CTRL, not CAP to see if it was previously
enabled... or maybe this check is entirely wrong and we're was trying to
see if enable is supported.

@@ -390,9 +391,8 @@ EXPORT_SYMBOL_GPL(pci_disable_pasid);
>   * Returns a negative value when no PASI capability is present.
>   * Otherwise is returns a bitmask with supported features. Current
>   * features reported are:
> - * PCI_PASID_ENABLE - PASID capability can be enabled
> - * PCI_PASID_EXEC - Execute permission supported
> - * PCI_PASID_PRIV - Priviledged mode supported
> + * PCI_PASID_CAP_EXEC - Execute permission supported
> + * PCI_PASID_CAP_PRIV - Priviledged mode supported
>   */
>  int pci_pasid_features(struct pci_dev *pdev)
>  {
> @@ -403,9 +403,9 @@ int pci_pasid_features(struct pci_dev *pdev)
>  	if (!pos)
>  		return -EINVAL;
>  
> -	pci_read_config_word(pdev, pos + PCI_PASID_CAP_OFF, &supported);
> +	pci_read_config_word(pdev, pos + PCI_PASID_CAP, &supported);
>  
> -	supported &= PCI_PASID_ENABLE | PCI_PASID_EXEC | PCI_PASID_PRIV;
> +	supported &= PCI_PASID_CAP_EXEC | PCI_PASID_CAP_PRIV;

And nobody exposes PCI_PASID_ENABLE because it doesn't exist as a
capability.

It's easy to see this if the bit definitions are named appropriately and
specified per register instead of being lumped together as "close
enough".  Thanks,

Alex

Re: [PATCH] pci: More PRI/PASID cleanup

[Roedel, Joerg]

On Tue, Nov 08, 2011 at 09:44:30AM -0700, Alex Williamson wrote:

> bit 0 (PCI_PASID_ENABLE) is reserved in the CAP register...

Is it? Which spec are you using? In my version it is not reserved but
states if it is supported to set the enable-bit.

> Which means we need to check CTRL, not CAP to see if it was previously
> enabled... or maybe this check is entirely wrong and we're was trying to
> see if enable is supported.

I will check how this looks in my test environment.

> And nobody exposes PCI_PASID_ENABLE because it doesn't exist as a
> capability.
> 
> It's easy to see this if the bit definitions are named appropriately and
> specified per register instead of being lumped together as "close
> enough".  Thanks,

I don't object against your renames as long as it doesn't cause
merge-conflicts with what I plan to send upstream.

Thanks,

	Joerg

-- 
AMD Operating System Research Center

Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach
General Managers: Alberto Bozzo, Andrew Bowd
Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632

Re: [PATCH] pci: More PRI/PASID cleanup

[Alex Williamson]

On Tue, 2011-11-08 at 18:17 +0100, Roedel, Joerg wrote:
> On Tue, Nov 08, 2011 at 09:44:30AM -0700, Alex Williamson wrote:
> 
> > bit 0 (PCI_PASID_ENABLE) is reserved in the CAP register...
> 
> Is it? Which spec are you using? In my version it is not reserved but
> states if it is supported to set the enable-bit.

Latest I can find is the March 31, 2011 PASID ECN, which just lists that
bit as reserved.

> > Which means we need to check CTRL, not CAP to see if it was previously
> > enabled... or maybe this check is entirely wrong and we're was trying to
> > see if enable is supported.
> 
> I will check how this looks in my test environment.
> 
> > And nobody exposes PCI_PASID_ENABLE because it doesn't exist as a
> > capability.
> > 
> > It's easy to see this if the bit definitions are named appropriately and
> > specified per register instead of being lumped together as "close
> > enough".  Thanks,
> 
> I don't object against your renames as long as it doesn't cause
> merge-conflicts with what I plan to send upstream.

I can drop it if need be, was just trying to do some cleanup on the
consistency of pci_reg.h before adding a bunch more defines to help
bounds checking and parsing for vfio-pci.  Unless my spec is outdated,
it seems like there's more than an aesthetic change here though, so
resolving the conflicts with your latest work might be warranted.
Thanks,

Alex

Re: [PATCH] pci: More PRI/PASID cleanup

[Roedel, Joerg]

On Tue, Nov 08, 2011 at 10:31:58AM -0700, Alex Williamson wrote:
> On Tue, 2011-11-08 at 18:17 +0100, Roedel, Joerg wrote:
> > On Tue, Nov 08, 2011 at 09:44:30AM -0700, Alex Williamson wrote:
> > 
> > > bit 0 (PCI_PASID_ENABLE) is reserved in the CAP register...
> > 
> > Is it? Which spec are you using? In my version it is not reserved but
> > states if it is supported to set the enable-bit.
> 
> Latest I can find is the March 31, 2011 PASID ECN, which just lists that
> bit as reserved.

Okay, my one is older and there it is stated as I implemented it. I will
check with reality first before changing the code...

> I can drop it if need be, was just trying to do some cleanup on the
> consistency of pci_reg.h before adding a bunch more defines to help
> bounds checking and parsing for vfio-pci.  Unless my spec is outdated,
> it seems like there's more than an aesthetic change here though, so
> resolving the conflicts with your latest work might be warranted.

Fine with me. The best is probably when I carry this change forward
(when Jesse is ok with that) and put my changes on-top of that.

Thanks,

	Joerg

-- 
AMD Operating System Research Center

Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach
General Managers: Alberto Bozzo, Andrew Bowd
Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632

Re: [PATCH] pci: More PRI/PASID cleanup

[Alex Williamson]

On Tue, 2011-11-08 at 18:54 +0100, Roedel, Joerg wrote:
> On Tue, Nov 08, 2011 at 10:31:58AM -0700, Alex Williamson wrote:
> > On Tue, 2011-11-08 at 18:17 +0100, Roedel, Joerg wrote:
> > > On Tue, Nov 08, 2011 at 09:44:30AM -0700, Alex Williamson wrote:
> > > 
> > > > bit 0 (PCI_PASID_ENABLE) is reserved in the CAP register...
> > > 
> > > Is it? Which spec are you using? In my version it is not reserved but
> > > states if it is supported to set the enable-bit.
> > 
> > Latest I can find is the March 31, 2011 PASID ECN, which just lists that
> > bit as reserved.
> 
> Okay, my one is older and there it is stated as I implemented it. I will
> check with reality first before changing the code...

My guess is that someone asked why a device would ever expose this table
if it didn't support enable as a capability.  So, I wouldn't be
surprised if your hardware sets it, but it's probably just as safe to
assume enable is supported if the PASID table exists.  Thanks,

Alex

> > I can drop it if need be, was just trying to do some cleanup on the
> > consistency of pci_reg.h before adding a bunch more defines to help
> > bounds checking and parsing for vfio-pci.  Unless my spec is outdated,
> > it seems like there's more than an aesthetic change here though, so
> > resolving the conflicts with your latest work might be warranted.
> 
> Fine with me. The best is probably when I carry this change forward
> (when Jesse is ok with that) and put my changes on-top of that.
> 
> Thanks,
> 
> 	Joerg
> 

Re: [PATCH] pci: More PRI/PASID cleanup

[Roedel, Joerg]

On Tue, Nov 08, 2011 at 11:20:06AM -0700, Alex Williamson wrote:

> My guess is that someone asked why a device would ever expose this table
> if it didn't support enable as a capability.  So, I wouldn't be
> surprised if your hardware sets it, but it's probably just as safe to
> assume enable is supported if the PASID table exists.

That is probably true. I suggest that you split the functional change
out of the patch and do only the renaming. I look over the code again
then and change it in a way that works with reality and the spec. Does
that work for you?


	Joerg

-- 
AMD Operating System Research Center

Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach
General Managers: Alberto Bozzo, Andrew Bowd
Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632