All of lore.kernel.org
 help / color / mirror / Atom feed
From: Niklas Cassel <cassel@kernel.org>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: "Jingoo Han" <jingoohan1@gmail.com>,
	"Manivannan Sadhasivam" <manivannan.sadhasivam@linaro.org>,
	"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
	"Krzysztof Wilczyński" <kw@linux.com>,
	"Rob Herring" <robh@kernel.org>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Kishon Vijay Abraham I" <kishon@kernel.org>,
	"Damien Le Moal" <dlemoal@kernel.org>,
	"Frank Li" <Frank.Li@nxp.com>,
	"Jesper Nilsson" <jesper.nilsson@axis.com>,
	stable@vger.kernel.org, linux-pci@vger.kernel.org
Subject: Re: [PATCH v5 1/6] PCI: dwc: ep: iATU registers must be written after the BAR_MASK
Date: Fri, 13 Dec 2024 14:34:35 +0100	[thread overview]
Message-ID: <Z1w364da43KCOIGY@ryzen> (raw)
In-Reply-To: <20241204173352.GA3006363@bhelgaas>

Hello Bjorn,

On Wed, Dec 04, 2024 at 11:33:52AM -0600, Bjorn Helgaas wrote:
> In subject, maybe "Write BAR_MASK before iATU registers"

Ok. Will fix in v6.


> 
> I guess writing BAR_MASK is really configuring the *size* of the BAR?

I am quite sure that you know how host software determines the size of
a BAR :)

But yes, writing the BAR_MASK will directly decide a BARs size:
https://wiki.osdev.org/PCI#Address_and_size_of_the_BAR

So BAR_MASK is "BAR size - 1".


> Maybe the size is the important semantic connection with iATU config?

The connection is:
"Field size depends on log2(BAR_MASK+1) in BAR match mode."

So I think it makes sense for the subject to include BAR_MASK
rather than BAR size.


> 
> On Wed, Nov 27, 2024 at 11:30:17AM +0100, Niklas Cassel wrote:
> > The DWC Databook description for the LWR_TARGET_RW and LWR_TARGET_HW fields
> > in the IATU_LWR_TARGET_ADDR_OFF_INBOUND_i registers state that:
> > "Field size depends on log2(BAR_MASK+1) in BAR match mode."
> 
> Can we include a databook revision and section here to help future
> maintainers?

Ok. Will fix in v6.


> 
> > I.e. only the upper bits are writable, and the number of writable bits is
> > dependent on the configured BAR_MASK.
> > 
> > If we do not write the BAR_MASK before writing the iATU registers, we are
> > relying the reset value of the BAR_MASK being larger than the requested
> > size of the first set_bar() call. The reset value of the BAR_MASK is SoC
> > dependent.
> > 
> > Thus, if the first set_bar() call requests a size that is larger than the
> > reset value of the BAR_MASK, the iATU will try to write to read-only bits,
> > which will cause the iATU to end up redirecting to a physical address that
> > is different from the address that was intended.
> > 
> > Thus, we should always write the iATU registers after writing the BAR_MASK.
> 
> Apparently we write BAR_MASK and the iATU registers in the wrong
> order?  I assume dw_pcie_ep_inbound_atu() writes the iATU registers.

Yes.


> 
> I can't quite connect the commit log with the code change.  I assume
> the dw_pcie_ep_writel_dbi2() and dw_pcie_ep_writel_dbi() writes update
> BAR_MASK?

dw_pcie_ep_writel_dbi2() writes the BAR_MASK.
dw_pcie_ep_writel_dbi() writes the BAR type.


> 
> And I guess the problem is that the previous code does:
> 
>   dw_pcie_ep_inbound_atu        # iATU
>   dw_pcie_ep_writel_dbi2        # BAR_MASK (?)
>   dw_pcie_ep_writel_dbi
> 
> and the new code basically does this:
> 
>   if (ep->epf_bar[bar]) {
>     dw_pcie_ep_writel_dbi2      # BAR_MASK (?)
>     dw_pcie_ep_writel_dbi
>   }
>   dw_pcie_ep_inbound_atu        # iATU
>   ep->epf_bar[bar] = epf_bar
> 
> so the first time we call dw_pcie_ep_set_bar(), we write BAR_MASK
> before iATU, and if we call dw_pcie_ep_set_bar() again, we skip the 
> BAR_MASK update?

The problem is as described in the commit message:
"If we do not write the BAR_MASK before writing the iATU registers, we are
relying the reset value of the BAR_MASK being larger than the requested
size of the first set_bar() call. The reset value of the BAR_MASK is SoC
dependent."


Before:
dw_pcie_ep_inbound_atu() # iATU - the writable bits in this write depends on
                         # BAR_MASK, which has not been written yet, thus the
			 # write will be at the mercy of the reset value of
			 # BAR_MASK, which is SoC dependent.
dw_pcie_ep_writel_dbi2() # BAR_MASK
dw_pcie_ep_writel_dbi()  # BAR type

After:
dw_pcie_ep_writel_dbi2() # BAR_MASK
dw_pcie_ep_writel_dbi()  # BAR type
dw_pcie_ep_inbound_atu() # iATU - this write is now done after BAR_MASK has
			 # been written, so we know that all the bits in this
			 # write is writable.


Kind regards,
Niklas

  reply	other threads:[~2024-12-13 13:34 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-27 10:30 [PATCH v5 0/6] PCI endpoint additional pci_epc_set_bar() checks Niklas Cassel
2024-11-27 10:30 ` [PATCH v5 1/6] PCI: dwc: ep: iATU registers must be written after the BAR_MASK Niklas Cassel
2024-11-30  8:23   ` Manivannan Sadhasivam
2024-12-04 17:33   ` Bjorn Helgaas
2024-12-13 13:34     ` Niklas Cassel [this message]
2024-12-13 14:38       ` Niklas Cassel
2024-11-27 10:30 ` [PATCH v5 2/6] PCI: dwc: ep: Add missing checks when dynamically changing a BAR Niklas Cassel
2024-11-30  8:24   ` Manivannan Sadhasivam
2024-12-04 17:17   ` Bjorn Helgaas
2024-12-13 13:37     ` Niklas Cassel
2024-11-27 10:30 ` [PATCH v5 3/6] PCI: dwc: ep: Add 'address' alignment to 'size' check in dw_pcie_prog_ep_inbound_atu() Niklas Cassel
2024-11-27 10:30 ` [PATCH v5 4/6] PCI: artpec6: Implement dw_pcie_ep operation get_features Niklas Cassel
2024-11-27 10:30 ` [PATCH v5 5/6] PCI: endpoint: Add size check for fixed size BARs in pci_epc_set_bar() Niklas Cassel
2024-11-27 10:30 ` [PATCH v5 6/6] PCI: endpoint: Verify that requested BAR size is a power of two Niklas Cassel

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=Z1w364da43KCOIGY@ryzen \
    --to=cassel@kernel.org \
    --cc=Frank.Li@nxp.com \
    --cc=bhelgaas@google.com \
    --cc=dlemoal@kernel.org \
    --cc=helgaas@kernel.org \
    --cc=jesper.nilsson@axis.com \
    --cc=jingoohan1@gmail.com \
    --cc=kishon@kernel.org \
    --cc=kw@linux.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=lpieralisi@kernel.org \
    --cc=manivannan.sadhasivam@linaro.org \
    --cc=robh@kernel.org \
    --cc=stable@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.