| Message ID | 20190530043642.31421-2-oohall@gmail.com |
|---|---|
| State | Accepted |
| Headers | show |
| Series | [1/2] hw/phb4: Assert Link Disable bit after ETU init | expand |
| Context | Check | Description |
|---|---|---|
| snowpatch_ozlabs/apply_patch | success | Successfully applied on branch master (76f7316bc8fc8a18fdbfcbc0e1fe1bb992d2a7d7) |
| snowpatch_ozlabs/snowpatch_job_snowpatch-skiboot | fail | Test snowpatch/job/snowpatch-skiboot on branch master |
| snowpatch_ozlabs/snowpatch_job_snowpatch-skiboot-dco | success | Signed-off-by present |
Oliver O'Halloran <oohall@gmail.com> wrote on 05/29/2019 11:36:42 PM: > From: Oliver O'Halloran <oohall@gmail.com> > To: skiboot@lists.ozlabs.org > Cc: Oliver O'Halloran <oohall@gmail.com>, Carol L Soto <clsoto@us.ibm.com> > Date: 05/29/2019 11:37 PM > Subject: [EXTERNAL] [PATCH 2/2] hw/phb4: Use read/write_reg in assert_perst > > While the PHB is fenced we can't use the MMIO interface to access PHB > registers. While processing a complete reset we inject a PHB fence to > isolate the PHB from the rest of the system because the PHB won't > respond to MMIOs from the rest of the system while being reset. > > We assert PERST after the fence has been erected which requires us to > use the XSCOM indirect interface to access the PHB registers rather than > the MMIO interface. Previously we did that when asserting PERST in the > CRESET path. However in b8b4c79d4419 ("hw/phb4: Factor out PERST > control"). This was re-written to use the raw in_be64() accessor. This > means that CRESET would not be asserted in the reset path. On some > Mellanox cards this would prevent them from re-loading their firmware > when the system was fast-reset. > > This patch fixes the problem by replacing the raw {in|out}_be64() > accessors with the phb4_{read|write}_reg() functions. > > Reported-by: Carol L Soto <clsoto@us.ibm.com> > Fixes: b8b4c79d4419 ("hw/phb4: Factor out PERST control") > Signed-off-by: Oliver O'Halloran <oohall@gmail.com> > --- > hw/phb4.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/hw/phb4.c b/hw/phb4.c > index 5ebb28ad8b0c..fb6736643ba1 100644 > --- a/hw/phb4.c > +++ b/hw/phb4.c > @@ -2924,7 +2924,7 @@ static void phb4_assert_perst(struct pci_slot > *slot, bool assert) > * bit in the btctl register also works. > */ > phb4_pcicfg_read16(&p->phb, 0, p->ecap + PCICAP_EXP_LCTL, &linkctl); > - reg = in_be64(p->regs + PHB_PCIE_CRESET); > + reg = phb4_read_reg(p, PHB_PCIE_CRESET); > > if (assert) { > linkctl |= PCICAP_EXP_LCTL_LINK_DIS; > @@ -2934,7 +2934,7 @@ static void phb4_assert_perst(struct pci_slot > *slot, bool assert) > reg |= PHB_PCIE_CRESET_PERST_N; > } > > - out_be64(p->regs + PHB_PCIE_CRESET, reg); > + phb4_write_reg(p, PHB_PCIE_CRESET, reg); > phb4_pcicfg_write16(&p->phb, 0, p->ecap + PCICAP_EXP_LCTL, linkctl); > } > > -- > 2.20.1 > Tested-by: Carol L Soto <clsoto@us.ibm.com>
"Oliver O'Halloran" <oohall@gmail.com> writes: > While the PHB is fenced we can't use the MMIO interface to access PHB > registers. While processing a complete reset we inject a PHB fence to > isolate the PHB from the rest of the system because the PHB won't > respond to MMIOs from the rest of the system while being reset. > > We assert PERST after the fence has been erected which requires us to > use the XSCOM indirect interface to access the PHB registers rather than > the MMIO interface. Previously we did that when asserting PERST in the > CRESET path. However in b8b4c79d4419 ("hw/phb4: Factor out PERST > control"). This was re-written to use the raw in_be64() accessor. This > means that CRESET would not be asserted in the reset path. On some > Mellanox cards this would prevent them from re-loading their firmware > when the system was fast-reset. > > This patch fixes the problem by replacing the raw {in|out}_be64() > accessors with the phb4_{read|write}_reg() functions. > > Reported-by: Carol L Soto <clsoto@us.ibm.com> > Fixes: b8b4c79d4419 ("hw/phb4: Factor out PERST control") > Signed-off-by: Oliver O'Halloran <oohall@gmail.com> > --- > hw/phb4.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Merged to master as of 771497098efded8d3a2c0688bab1c1d48d093443
diff --git a/hw/phb4.c b/hw/phb4.c index 5ebb28ad8b0c..fb6736643ba1 100644 --- a/hw/phb4.c +++ b/hw/phb4.c @@ -2924,7 +2924,7 @@ static void phb4_assert_perst(struct pci_slot *slot, bool assert) * bit in the btctl register also works. */ phb4_pcicfg_read16(&p->phb, 0, p->ecap + PCICAP_EXP_LCTL, &linkctl); - reg = in_be64(p->regs + PHB_PCIE_CRESET); + reg = phb4_read_reg(p, PHB_PCIE_CRESET); if (assert) { linkctl |= PCICAP_EXP_LCTL_LINK_DIS; @@ -2934,7 +2934,7 @@ static void phb4_assert_perst(struct pci_slot *slot, bool assert) reg |= PHB_PCIE_CRESET_PERST_N; } - out_be64(p->regs + PHB_PCIE_CRESET, reg); + phb4_write_reg(p, PHB_PCIE_CRESET, reg); phb4_pcicfg_write16(&p->phb, 0, p->ecap + PCICAP_EXP_LCTL, linkctl); }
While the PHB is fenced we can't use the MMIO interface to access PHB registers. While processing a complete reset we inject a PHB fence to isolate the PHB from the rest of the system because the PHB won't respond to MMIOs from the rest of the system while being reset. We assert PERST after the fence has been erected which requires us to use the XSCOM indirect interface to access the PHB registers rather than the MMIO interface. Previously we did that when asserting PERST in the CRESET path. However in b8b4c79d4419 ("hw/phb4: Factor out PERST control"). This was re-written to use the raw in_be64() accessor. This means that CRESET would not be asserted in the reset path. On some Mellanox cards this would prevent them from re-loading their firmware when the system was fast-reset. This patch fixes the problem by replacing the raw {in|out}_be64() accessors with the phb4_{read|write}_reg() functions. Reported-by: Carol L Soto <clsoto@us.ibm.com> Fixes: b8b4c79d4419 ("hw/phb4: Factor out PERST control") Signed-off-by: Oliver O'Halloran <oohall@gmail.com> --- hw/phb4.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)