All of lore.kernel.org
 help / color / mirror / Atom feed
From: Niklas Cassel <cassel@kernel.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: "Manivannan Sadhasivam" <manivannan.sadhasivam@linaro.org>,
	"Krzysztof Wilczyński" <kw@linux.com>,
	"Kishon Vijay Abraham I" <kishon@kernel.org>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Damien Le Moal" <dlemoal@kernel.org>,
	linux-pci@vger.kernel.org
Subject: Re: [PATCH] misc: pci_endpoint_test: Use memcpy_toio()/memcpy_fromio() for BAR tests
Date: Tue, 19 Mar 2024 22:36:05 +0100	[thread overview]
Message-ID: <ZfoFRTAh9O88o8ZD@ryzen> (raw)
In-Reply-To: <e284c1cc-0258-4363-930f-5b508855c094@app.fastmail.com>

Hello Arnd,

On Tue, Mar 19, 2024 at 08:55:19PM +0100, Arnd Bergmann wrote:
> On Tue, Mar 19, 2024, at 17:53, Niklas Cassel wrote:
> > On Tue, Mar 19, 2024 at 10:18:26PM +0530, Manivannan Sadhasivam wrote:
> >> > 
> >> > I did also see this comment:
> >> > https://github.com/torvalds/linux/blob/master/Documentation/memory-barriers.txt#L2785-L2790
> >> > 
> >> > Do you think that we need to perform any flushing after the memset(),
> >> > to ensure that the data written using memcpy_toio() is actually what
> >> > we expect it to me?
> >> > 
> >> 
> >> The documentation recommends cache flushing only if the normal memory write and
> >> MMIO access are dependent. But here you are just accessing the MMIO. So no
> >> explicit ordering or cache flushing is required.
> >
> > What does dependent mean in this case then?
> >
> > Since the data that we are writing to the device is the data that was
> > just written to memory using memset().
> 
> You need a barrier for the case where the memset() writes to
> a buffer in RAM and then you write the address of that buffer
> into a device register, which triggers a DMA read from the
> buffer. Without a barrier, the side effect of the MMIO write
> may come before the data in the RAM buffer is visible.
> 
> A memcpy_fromio() only involves a single master accessing
> the memory (i.e. the CPU executing both the memset() and the
> memcpy()), so there is no way this can go wrong.

Thank you for the clarification.


Kind regards,
Niklas

      reply	other threads:[~2024-03-19 21:36 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-18 19:30 [PATCH] misc: pci_endpoint_test: Use memcpy_toio()/memcpy_fromio() for BAR tests Niklas Cassel
2024-03-18 20:02 ` Arnd Bergmann
2024-03-19  4:31   ` Manivannan Sadhasivam
2024-03-19  6:41     ` Arnd Bergmann
2024-03-19 16:40   ` Niklas Cassel
2024-03-19 16:48     ` Manivannan Sadhasivam
2024-03-19 16:53       ` Niklas Cassel
2024-03-19 19:55         ` Arnd Bergmann
2024-03-19 21:36           ` Niklas Cassel [this message]

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=ZfoFRTAh9O88o8ZD@ryzen \
    --to=cassel@kernel.org \
    --cc=arnd@arndb.de \
    --cc=dlemoal@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=kishon@kernel.org \
    --cc=kw@linux.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=manivannan.sadhasivam@linaro.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.