[PATCH] iommu/amd: Add prefetch iommu pages command build function

2020-09-05 Thread Wesley Sheng 
Add function to build prefetch iommu pages command

Signed-off-by: Wesley Sheng 
---
 drivers/iommu/amd/amd_iommu_types.h |  2 ++
 drivers/iommu/amd/iommu.c   | 19 +++
 2 files changed, 21 insertions(+)

diff --git a/drivers/iommu/amd/amd_iommu_types.h 
b/drivers/iommu/amd/amd_iommu_types.h
index baa31cd2411c..73734a0c4679 100644
--- a/drivers/iommu/amd/amd_iommu_types.h
+++ b/drivers/iommu/amd/amd_iommu_types.h
@@ -173,6 +173,7 @@
 #define CMD_INV_IOMMU_PAGES0x03
 #define CMD_INV_IOTLB_PAGES0x04
 #define CMD_INV_IRT0x05
+#define CMD_PF_IOMMU_PAGES 0x06
 #define CMD_COMPLETE_PPR   0x07
 #define CMD_INV_ALL0x08
 
@@ -181,6 +182,7 @@
 #define CMD_INV_IOMMU_PAGES_SIZE_MASK  0x01
 #define CMD_INV_IOMMU_PAGES_PDE_MASK   0x02
 #define CMD_INV_IOMMU_PAGES_GN_MASK0x04
+#define CMD_PF_IOMMU_PAGES_INV_MASK0x10
 
 #define PPR_STATUS_MASK0xf
 #define PPR_STATUS_SHIFT   12
diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c
index ba9f3dbc5b94..b3971595b0e9 100644
--- a/drivers/iommu/amd/iommu.c
+++ b/drivers/iommu/amd/iommu.c
@@ -976,6 +976,25 @@ static void build_inv_irt(struct iommu_cmd *cmd, u16 devid)
CMD_SET_TYPE(cmd, CMD_INV_IRT);
 }
 
+static void build_pf_iommu_pages(struct iommu_cmd *cmd, u64 address,
+   u16 devid, int pfcnt, bool size,
+   bool inv)
+{
+   memset(cmd, 0, sizeof(*cmd));
+
+   address &= PAGE_MASK;
+
+   cmd->data[0]  = devid;
+   cmd->data[0] |= (pfcnt & 0xff) << 24;
+   cmd->data[2]  = lower_32_bits(address);
+   cmd->data[3]  = upper_32_bits(address;
+   if (size)
+   cmd->data[2] |= CMD_INV_IOMMU_PAGES_SIZE_MASK;
+   if (inv)
+   cmd->data[2] |= CMD_PF_IOMMU_PAGES_INV_MASK;
+   CMD_SET_TYPE(cmd, CMD_PF_IOMMU_PAGES);
+}
+
 /*
  * Writes the command to the IOMMUs command buffer and informs the
  * hardware about the new command.
-- 
2.16.2

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH 2/2] iommu/amd: Revise ga_tag member in struct of fields_remap

2020-09-05 Thread Wesley Sheng 
Per <>
ga_tag member is only available when IRTE[GuestMode]=1, this field
should be reserved when IRTE[GuestMode]=0. So change the ga_tag
to rsvd_1 in struct of fields_remap.

Signed-off-by: Wesley Sheng 
---
 drivers/iommu/amd/amd_iommu_types.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iommu/amd/amd_iommu_types.h 
b/drivers/iommu/amd/amd_iommu_types.h
index e5b05a97eb46..baa31cd2411c 100644
--- a/drivers/iommu/amd/amd_iommu_types.h
+++ b/drivers/iommu/amd/amd_iommu_types.h
@@ -832,7 +832,7 @@ union irte_ga_lo {
/* -- */
guest_mode  : 1,
destination : 24,
-   ga_tag  : 32;
+   rsvd_1  : 32;
} fields_remap;
 
/* For guest vAPIC */
-- 
2.16.2

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH 1/2] iommu/amd: Unify reserved member naming convention in struct

2020-09-05 Thread Wesley Sheng 
Unify reserved member naming convention to rsvd_x in struct

Signed-off-by: Wesley Sheng 
---
 drivers/iommu/amd/amd_iommu_types.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iommu/amd/amd_iommu_types.h 
b/drivers/iommu/amd/amd_iommu_types.h
index 30a5d412255a..e5b05a97eb46 100644
--- a/drivers/iommu/amd/amd_iommu_types.h
+++ b/drivers/iommu/amd/amd_iommu_types.h
@@ -841,7 +841,7 @@ union irte_ga_lo {
no_fault: 1,
/* -- */
ga_log_intr : 1,
-   rsvd1   : 3,
+   rsvd_1  : 3,
is_run  : 1,
/* -- */
guest_mode  : 1,
-- 
2.16.2

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH] iommu/amd: Add prefetch iommu pages command build function

2020-09-05 Thread Wesley Sheng 
Add function to build prefetch iommu pages command

Signed-off-by: Wesley Sheng 
---
 drivers/iommu/amd/amd_iommu_types.h |  2 ++
 drivers/iommu/amd/iommu.c   | 19 +++
 2 files changed, 21 insertions(+)

diff --git a/drivers/iommu/amd/amd_iommu_types.h 
b/drivers/iommu/amd/amd_iommu_types.h
index baa31cd2411c..73734a0c4679 100644
--- a/drivers/iommu/amd/amd_iommu_types.h
+++ b/drivers/iommu/amd/amd_iommu_types.h
@@ -173,6 +173,7 @@
 #define CMD_INV_IOMMU_PAGES0x03
 #define CMD_INV_IOTLB_PAGES0x04
 #define CMD_INV_IRT0x05
+#define CMD_PF_IOMMU_PAGES 0x06
 #define CMD_COMPLETE_PPR   0x07
 #define CMD_INV_ALL0x08
 
@@ -181,6 +182,7 @@
 #define CMD_INV_IOMMU_PAGES_SIZE_MASK  0x01
 #define CMD_INV_IOMMU_PAGES_PDE_MASK   0x02
 #define CMD_INV_IOMMU_PAGES_GN_MASK0x04
+#define CMD_PF_IOMMU_PAGES_INV_MASK0x10
 
 #define PPR_STATUS_MASK0xf
 #define PPR_STATUS_SHIFT   12
diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c
index ba9f3dbc5b94..b3971595b0e9 100644
--- a/drivers/iommu/amd/iommu.c
+++ b/drivers/iommu/amd/iommu.c
@@ -976,6 +976,25 @@ static void build_inv_irt(struct iommu_cmd *cmd, u16 devid)
CMD_SET_TYPE(cmd, CMD_INV_IRT);
 }
 
+static void build_pf_iommu_pages(struct iommu_cmd *cmd, u64 address,
+   u16 devid, int pfcnt, bool size,
+   bool inv)
+{
+   memset(cmd, 0, sizeof(*cmd));
+
+   address &= PAGE_MASK;
+
+   cmd->data[0]  = devid;
+   cmd->data[0] |= (pfcnt & 0xff) << 24;
+   cmd->data[2]  = lower_32_bits(address);
+   cmd->data[3]  = upper_32_bits(address);
+   if (size)
+   cmd->data[2] |= CMD_INV_IOMMU_PAGES_SIZE_MASK;
+   if (inv)
+   cmd->data[2] |= CMD_PF_IOMMU_PAGES_INV_MASK;
+   CMD_SET_TYPE(cmd, CMD_PF_IOMMU_PAGES);
+}
+
 /*
  * Writes the command to the IOMMUs command buffer and informs the
  * hardware about the new command.
-- 
2.16.2

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH v3] NTB: switchtec_ntb: Update switchtec documentation with pre-requisites for NTB

2018-10-10 Thread Wesley Sheng 
From: Wesley Yung 

The ntb_hw_switchtec driver has requirements on kernel configuration
so we add these notes to the documentation and also clean up a few 
other sentences in the documentation.

Signed-off-by: Wesley Yung 
Signed-off-by: Kelvin Cao 
Signed-off-by: Wesley Sheng 
---
 Documentation/switchtec.txt | 30 --
 1 file changed, 20 insertions(+), 10 deletions(-)

diff --git a/Documentation/switchtec.txt b/Documentation/switchtec.txt
index f788264..d6f04dcc 100644
--- a/Documentation/switchtec.txt
+++ b/Documentation/switchtec.txt
@@ -23,7 +23,7 @@ The primary means of communicating with the Switchtec 
management firmware is
 through the Memory-mapped Remote Procedure Call (MRPC) interface.
 Commands are submitted to the interface with a 4-byte command
 identifier and up to 1KB of command specific data. The firmware will
-respond with a 4 bytes return code and up to 1KB of command specific
+respond with a 4-byte return code and up to 1KB of command specific
 data. The interface only processes a single command at a time.
 
 
@@ -36,8 +36,8 @@ device: /dev/switchtec#, one for each management endpoint in 
the system.
 The char device has the following semantics:
 
 * A write must consist of at least 4 bytes and no more than 1028 bytes.
-  The first four bytes will be interpreted as the command to run and
-  the remainder will be used as the input data. A write will send the
+  The first 4 bytes will be interpreted as the Command ID and the
+  remainder will be used as the input data. A write will send the
   command to the firmware to begin processing.
 
 * Each write must be followed by exactly one read. Any double write will
@@ -45,9 +45,9 @@ The char device has the following semantics:
   produce an error.
 
 * A read will block until the firmware completes the command and return
-  the four bytes of status plus up to 1024 bytes of output data. (The
-  length will be specified by the size parameter of the read call --
-  reading less than 4 bytes will produce an error.
+  the 4-byte Command Return Value plus up to 1024 bytes of output
+  data. (The length will be specified by the size parameter of the read
+  call -- reading less than 4 bytes will produce an error.)
 
 * The poll call will also be supported for userspace applications that
   need to do other things while waiting for the command to complete.
@@ -83,10 +83,20 @@ The following IOCTLs are also supported by the device:
 Non-Transparent Bridge (NTB) Driver
 ===
 
-An NTB driver is provided for the switchtec hardware in switchtec_ntb.
-Currently, it only supports switches configured with exactly 2
-partitions. It also requires the following configuration settings:
+An NTB hardware driver is provided for the Switchtec hardware in
+ntb_hw_switchtec. Currently, it only supports switches configured with
+exactly 2 NT partitions and zero or more non-NT partitions. It also requires
+the following configuration settings:
 
-* Both partitions must be able to access each other's GAS spaces.
+* Both NT partitions must be able to access each other's GAS spaces.
   Thus, the bits in the GAS Access Vector under Management Settings
   must be set to support this.
+* Kernel configuration MUST include support for NTB (CONFIG_NTB needs
+  to be set)
+
+NT EP BAR 2 will be dynamically configured as a Direct Window, and
+the configuration file does not need to configure it explicitly.
+
+Please refer to Documentation/ntb.txt in Linux source tree for an overall
+understanding of the Linux NTB stack. ntb_hw_switchtec works as an NTB
+Hardware Driver in this stack.
-- 
2.7.4

[PATCH] Documentation PCI: Fix typo in pci-error-recovery.rst

2021-05-31 Thread Wesley Sheng 
Replace "It" with "If", since it is a conditional statement.

Signed-off-by: Wesley Sheng 
---
 Documentation/PCI/pci-error-recovery.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/PCI/pci-error-recovery.rst 
b/Documentation/PCI/pci-error-recovery.rst
index 84ceebb08cac..187f43a03200 100644
--- a/Documentation/PCI/pci-error-recovery.rst
+++ b/Documentation/PCI/pci-error-recovery.rst
@@ -295,7 +295,7 @@ and let the driver restart normal I/O processing.
 A driver can still return a critical failure for this function if
 it can't get the device operational after reset.  If the platform
 previously tried a soft reset, it might now try a hard reset (power
-cycle) and then call slot_reset() again.  It the device still can't
+cycle) and then call slot_reset() again.  If the device still can't
 be recovered, there is nothing more that can be done;  the platform
 will typically report a "permanent failure" in such a case.  The
 device will be considered "dead" in this case.
-- 
2.25.1

[PATCH] Documentation: PCI: pci-error-recovery: rearrange the general sequence

2021-06-17 Thread Wesley Sheng 
Reset_link() callback function was called before mmio_enabled() in
pcie_do_recovery() function actually, so rearrange the general
sequence betwen step 2 and step 3 accordingly.

Signed-off-by: Wesley Sheng 
---
 Documentation/PCI/pci-error-recovery.rst | 23 ---
 1 file changed, 12 insertions(+), 11 deletions(-)

diff --git a/Documentation/PCI/pci-error-recovery.rst 
b/Documentation/PCI/pci-error-recovery.rst
index 187f43a03200..ac6a8729ef28 100644
--- a/Documentation/PCI/pci-error-recovery.rst
+++ b/Documentation/PCI/pci-error-recovery.rst
@@ -184,7 +184,14 @@ is STEP 6 (Permanent Failure).
and prints an error to syslog.  A reboot is then required to
get the device working again.
 
-STEP 2: MMIO Enabled
+STEP 2: Link Reset
+--
+The platform resets the link.  This is a PCI-Express specific step
+and is done whenever a fatal error has been detected that can be
+"solved" by resetting the link.
+
+
+STEP 3: MMIO Enabled
 
 The platform re-enables MMIO to the device (but typically not the
 DMA), and then calls the mmio_enabled() callback on all affected
@@ -197,8 +204,8 @@ information, if any, and eventually do things like trigger 
a device local
 reset or some such, but not restart operations. This callback is made if
 all drivers on a segment agree that they can try to recover and if no automatic
 link reset was performed by the HW. If the platform can't just re-enable IOs
-without a slot reset or a link reset, it will not call this callback, and
-instead will have gone directly to STEP 3 (Link Reset) or STEP 4 (Slot Reset)
+without a slot reset, it will not call this callback, and
+instead will have gone directly or STEP 4 (Slot Reset)
 
 .. note::
 
@@ -210,7 +217,7 @@ instead will have gone directly to STEP 3 (Link Reset) or 
STEP 4 (Slot Reset)
such an error might cause IOs to be re-blocked for the whole
segment, and thus invalidate the recovery that other devices
on the same segment might have done, forcing the whole segment
-   into one of the next states, that is, link reset or slot reset.
+   into next states, that is, slot reset.
 
 The driver should return one of the following result codes:
   - PCI_ERS_RESULT_RECOVERED
@@ -233,17 +240,11 @@ The driver should return one of the following result 
codes:
 
 The next step taken depends on the results returned by the drivers.
 If all drivers returned PCI_ERS_RESULT_RECOVERED, then the platform
-proceeds to either STEP3 (Link Reset) or to STEP 5 (Resume Operations).
+proceeds to STEP 5 (Resume Operations).
 
 If any driver returned PCI_ERS_RESULT_NEED_RESET, then the platform
 proceeds to STEP 4 (Slot Reset)
 
-STEP 3: Link Reset
---
-The platform resets the link.  This is a PCI-Express specific step
-and is done whenever a fatal error has been detected that can be
-"solved" by resetting the link.
-
 STEP 4: Slot Reset
 --
 
-- 
2.25.1

Re: [PATCH] Documentation: PCI: pci-error-recovery: rearrange the general sequence

2021-06-28 Thread Wesley Sheng 
On Fri, Jun 18, 2021 at 05:21:32PM +1000, Oliver O'Halloran wrote:
> On Fri, Jun 18, 2021 at 4:05 PM Wesley Sheng  wrote:
> >
> > Reset_link() callback function was called before mmio_enabled() in
> > pcie_do_recovery() function actually, so rearrange the general
> > sequence betwen step 2 and step 3 accordingly.
> 
> I don't think this is true in all cases. If pcie_do_recovery() is
> called with state==pci_channel_io_normal (i.e. non-fatal AER) the link
> won't be reset. EEH (ppc PCI error recovery thing) also uses
> .mmio_enabled() as described.

Yes, in case of non-fatal AER, reset_link() callback (aer_root_reset() for 
AER and dpc_reset_link() for DPC) will not be invoked. And if 
.error_detected() return PCI_ERS_RESULT_CAN_RECOVER, .mmio_enabled() be
called followed.

But if pcie_do_recovery() is called with state == pci_channel_io_frozen,
reset_link() callback is called after .error_detected() but before
.mmio_enabled(). So I thought Step 2: MMIO Enabled and Step 3: Link Reset
should rearrange their sequence.

Re: [PATCH] Documentation: PCI: pci-error-recovery: rearrange the general sequence

2021-07-01 Thread Wesley Sheng 
On Thu, Jul 01, 2021 at 05:22:31PM -0500, Bjorn Helgaas wrote:
> Please make the subject a little more specific.  "rearrange the
> general sequence" doesn't say anything about what was affected.
> 
> On Fri, Jun 18, 2021 at 02:04:46PM +0800, Wesley Sheng wrote:
> > Reset_link() callback function was called before mmio_enabled() in
> > pcie_do_recovery() function actually, so rearrange the general
> > sequence betwen step 2 and step 3 accordingly.
> 
> s/betwen/between/
> 
> Not sure "general" adds anything in this sentence.  "Step 2 and step
> 3" are not meaningful here in the commit log.  It needs to spell out
> what those steps are so the log makes sense by itself.
> 
> "reset_link" does not appear in pcie_do_recovery().  I'm guessing
> you're referring to the "reset_subordinates" function pointer?
>
Yes, you are right.
pcieaer-howto.rst has a section named with "Provide callbacks",
the callback supplied to pcie_do_recovery() was referred to 
reset_link.
 
> > Signed-off-by: Wesley Sheng 
> 
> I didn't quite understand your response to Oliver, so I'll wait for
> your corrections and his ack before proceeding.
>
OK.
I thought step 2 MMIO Enabled and step 3 link reset should swap sequence.

> > ---
> >  Documentation/PCI/pci-error-recovery.rst | 23 ---
> >  1 file changed, 12 insertions(+), 11 deletions(-)
> > 
> > diff --git a/Documentation/PCI/pci-error-recovery.rst 
> > b/Documentation/PCI/pci-error-recovery.rst
> > index 187f43a03200..ac6a8729ef28 100644
> > --- a/Documentation/PCI/pci-error-recovery.rst
> > +++ b/Documentation/PCI/pci-error-recovery.rst
> > @@ -184,7 +184,14 @@ is STEP 6 (Permanent Failure).
> > and prints an error to syslog.  A reboot is then required to
> > get the device working again.
> >  
> > -STEP 2: MMIO Enabled
> > +STEP 2: Link Reset
> > +--
> > +The platform resets the link.  This is a PCI-Express specific step
> > +and is done whenever a fatal error has been detected that can be
> > +"solved" by resetting the link.
> > +
> > +
> > +STEP 3: MMIO Enabled
> >  
> >  The platform re-enables MMIO to the device (but typically not the
> >  DMA), and then calls the mmio_enabled() callback on all affected
> > @@ -197,8 +204,8 @@ information, if any, and eventually do things like 
> > trigger a device local
> >  reset or some such, but not restart operations. This callback is made if
> >  all drivers on a segment agree that they can try to recover and if no 
> > automatic
> >  link reset was performed by the HW. If the platform can't just re-enable 
> > IOs
> > -without a slot reset or a link reset, it will not call this callback, and
> > -instead will have gone directly to STEP 3 (Link Reset) or STEP 4 (Slot 
> > Reset)
> > +without a slot reset, it will not call this callback, and
> > +instead will have gone directly or STEP 4 (Slot Reset)
> 
> s/or/to/  ?
> 
> >  .. note::
> >  
> > @@ -210,7 +217,7 @@ instead will have gone directly to STEP 3 (Link Reset) 
> > or STEP 4 (Slot Reset)
> > such an error might cause IOs to be re-blocked for the whole
> > segment, and thus invalidate the recovery that other devices
> > on the same segment might have done, forcing the whole segment
> > -   into one of the next states, that is, link reset or slot reset.
> > +   into next states, that is, slot reset.
> 
> s/into next states/into the next state/ ?
> 
> >  The driver should return one of the following result codes:
> >- PCI_ERS_RESULT_RECOVERED
> > @@ -233,17 +240,11 @@ The driver should return one of the following result 
> > codes:
> >  
> >  The next step taken depends on the results returned by the drivers.
> >  If all drivers returned PCI_ERS_RESULT_RECOVERED, then the platform
> > -proceeds to either STEP3 (Link Reset) or to STEP 5 (Resume Operations).
> > +proceeds to STEP 5 (Resume Operations).
> >  
> >  If any driver returned PCI_ERS_RESULT_NEED_RESET, then the platform
> >  proceeds to STEP 4 (Slot Reset)
> >  
> > -STEP 3: Link Reset
> > ---
> > -The platform resets the link.  This is a PCI-Express specific step
> > -and is done whenever a fatal error has been detected that can be
> > -"solved" by resetting the link.
> > -
> >  STEP 4: Slot Reset
> >  --
> >  
> > -- 
> > 2.25.1
> >

[PATCH v2] Documentation: PCI: pci-error-recovery: swap sequence between MMIO Enabled and Link Reset

2021-07-01 Thread Wesley Sheng 
Reset_link() callback function (named with reset_subordinates()
in pcie_do_recovery() function) was called before mmio_enabled(),
so exchange the sequence between step 2 MMIO Enabled and step 3
Link Reset accordingly.

Signed-off-by: Wesley Sheng 
---
 Documentation/PCI/pci-error-recovery.rst | 25 
 1 file changed, 13 insertions(+), 12 deletions(-)

diff --git a/Documentation/PCI/pci-error-recovery.rst 
b/Documentation/PCI/pci-error-recovery.rst
index 187f43a03200..0e2f3f77bf0a 100644
--- a/Documentation/PCI/pci-error-recovery.rst
+++ b/Documentation/PCI/pci-error-recovery.rst
@@ -157,7 +157,7 @@ drivers.
 If all drivers on the segment/slot return PCI_ERS_RESULT_CAN_RECOVER,
 then the platform should re-enable IOs on the slot (or do nothing in
 particular, if the platform doesn't isolate slots), and recovery
-proceeds to STEP 2 (MMIO Enable).
+proceeds to STEP 3 (MMIO Enable).
 
 If any driver requested a slot reset (by returning PCI_ERS_RESULT_NEED_RESET),
 then recovery proceeds to STEP 4 (Slot Reset).
@@ -184,7 +184,14 @@ is STEP 6 (Permanent Failure).
and prints an error to syslog.  A reboot is then required to
get the device working again.
 
-STEP 2: MMIO Enabled
+STEP 2: Link Reset
+--
+The platform resets the link.  This is a PCI-Express specific step
+and is done whenever a fatal error has been detected that can be
+"solved" by resetting the link.
+
+
+STEP 3: MMIO Enabled
 
 The platform re-enables MMIO to the device (but typically not the
 DMA), and then calls the mmio_enabled() callback on all affected
@@ -197,8 +204,8 @@ information, if any, and eventually do things like trigger 
a device local
 reset or some such, but not restart operations. This callback is made if
 all drivers on a segment agree that they can try to recover and if no automatic
 link reset was performed by the HW. If the platform can't just re-enable IOs
-without a slot reset or a link reset, it will not call this callback, and
-instead will have gone directly to STEP 3 (Link Reset) or STEP 4 (Slot Reset)
+without a slot reset, it will not call this callback, and
+instead will have gone directly to STEP 4 (Slot Reset)
 
 .. note::
 
@@ -210,7 +217,7 @@ instead will have gone directly to STEP 3 (Link Reset) or 
STEP 4 (Slot Reset)
such an error might cause IOs to be re-blocked for the whole
segment, and thus invalidate the recovery that other devices
on the same segment might have done, forcing the whole segment
-   into one of the next states, that is, link reset or slot reset.
+   into the next states, that is, slot reset.
 
 The driver should return one of the following result codes:
   - PCI_ERS_RESULT_RECOVERED
@@ -233,17 +240,11 @@ The driver should return one of the following result 
codes:
 
 The next step taken depends on the results returned by the drivers.
 If all drivers returned PCI_ERS_RESULT_RECOVERED, then the platform
-proceeds to either STEP3 (Link Reset) or to STEP 5 (Resume Operations).
+proceeds to STEP 5 (Resume Operations).
 
 If any driver returned PCI_ERS_RESULT_NEED_RESET, then the platform
 proceeds to STEP 4 (Slot Reset)
 
-STEP 3: Link Reset
---
-The platform resets the link.  This is a PCI-Express specific step
-and is done whenever a fatal error has been detected that can be
-"solved" by resetting the link.
-
 STEP 4: Slot Reset
 --
 
-- 
2.25.1

[PATCH] nvme: Correct the prps per page calculation method

2021-06-15 Thread Wesley Sheng 
From: wesleywesley 

Each prp is 8 bytes, calculate the number of prps
per page should just divide page size by 8
there is no need to minus 1

Signed-off-by: wesleywesley 
---
 drivers/nvme/nvme.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/nvme/nvme.c b/drivers/nvme/nvme.c
index fc64d93ab8..622bb378c0 100644
--- a/drivers/nvme/nvme.c
+++ b/drivers/nvme/nvme.c
@@ -79,7 +79,7 @@ static int nvme_setup_prps(struct nvme_dev *dev, u64 *prp2,
u64 *prp_pool;
int length = total_len;
int i, nprps;
-   u32 prps_per_page = (page_size >> 3) - 1;
+   u32 prps_per_page = page_size >> 3;
u32 num_pages;
 
length -= (page_size - offset);
-- 
2.25.1

[PATCH] nvme: Remove the redundant aqa value setting

2021-06-15 Thread Wesley Sheng 
From: wesleywesley 

AQA (Admin Queue Attributes) register is a dword size with
lower word of ASQS, and higher word of ACQS.

The code set the variable aqa twice, but it is redundant.

Signed-off-by: wesleywesley 
---
 drivers/nvme/nvme.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/nvme/nvme.c b/drivers/nvme/nvme.c
index fc64d93ab8..a062234163 100644
--- a/drivers/nvme/nvme.c
+++ b/drivers/nvme/nvme.c
@@ -379,7 +379,6 @@ static int nvme_configure_admin_queue(struct nvme_dev *dev)
 
aqa = nvmeq->q_depth - 1;
aqa |= aqa << 16;
-   aqa |= aqa << 16;
 
dev->page_size = 1 << page_shift;
 
-- 
2.25.1

[PATCH] nvme: Correct the prps per page calculation method

2021-06-21 Thread Wesley Sheng 
From: Wesley Sheng 

Each prp is 8 bytes, calculate the number of prps
per page should just divide page size by 8
there is no need to minus 1

Signed-off-by: Wesley Sheng 
---
 drivers/nvme/nvme.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/nvme/nvme.c b/drivers/nvme/nvme.c
index fc64d93ab8..622bb378c0 100644
--- a/drivers/nvme/nvme.c
+++ b/drivers/nvme/nvme.c
@@ -79,7 +79,7 @@ static int nvme_setup_prps(struct nvme_dev *dev, u64 *prp2,
u64 *prp_pool;
int length = total_len;
int i, nprps;
-   u32 prps_per_page = (page_size >> 3) - 1;
+   u32 prps_per_page = page_size >> 3;
u32 num_pages;
 
length -= (page_size - offset);
-- 
2.25.1

[PATCH] nvme: Remove the redundant aqa value setting

2021-06-21 Thread Wesley Sheng 
From: Wesley Sheng 

AQA (Admin Queue Attributes) register is a dword size with
lower word of ASQS, and higher word of ACQS.

The code set the variable aqa twice, but it is redundant.

Signed-off-by: Wesley Sheng 
---
 drivers/nvme/nvme.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/nvme/nvme.c b/drivers/nvme/nvme.c
index fc64d93ab8..a062234163 100644
--- a/drivers/nvme/nvme.c
+++ b/drivers/nvme/nvme.c
@@ -379,7 +379,6 @@ static int nvme_configure_admin_queue(struct nvme_dev *dev)
 
aqa = nvmeq->q_depth - 1;
aqa |= aqa << 16;
-   aqa |= aqa << 16;
 
dev->page_size = 1 << page_shift;
 
-- 
2.25.1