[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZnrCKQBaRUlIs8hp@cassiopeiae>
Date: Tue, 25 Jun 2024 15:12:09 +0200
From: Danilo Krummrich <dakr@...hat.com>
To: Andreas Hindborg <nmi@...aspace.dk>
Cc: gregkh@...uxfoundation.org, rafael@...nel.org, bhelgaas@...gle.com,
ojeda@...nel.org, alex.gaynor@...il.com, wedsonaf@...il.com,
boqun.feng@...il.com, gary@...yguo.net, bjorn3_gh@...tonmail.com,
benno.lossin@...ton.me, a.hindborg@...sung.com,
aliceryhl@...gle.com, airlied@...il.com, fujita.tomonori@...il.com,
lina@...hilina.net, pstanner@...hat.com, ajanulgu@...hat.com,
lyude@...hat.com, robh@...nel.org, daniel.almeida@...labora.com,
rust-for-linux@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-pci@...r.kernel.org
Subject: Re: [PATCH v2 07/10] rust: add `io::Io` base type
On Tue, Jun 25, 2024 at 12:59:24PM +0200, Andreas Hindborg wrote:
> Hi Danilo,
>
> Danilo Krummrich <dakr@...hat.com> writes:
>
> [...]
>
> > +
> > +macro_rules! define_write {
> > + ($(#[$attr:meta])* $name:ident, $try_name:ident, $type_name:ty) => {
> > + /// Write IO data from a given offset known at compile time.
> > + ///
> > + /// Bound checks are performed on compile time, hence if the offset is not known at compile
> > + /// time, the build will fail.
> > + $(#[$attr])*
> > + #[inline]
> > + pub fn $name(&self, value: $type_name, offset: usize) {
> > + let addr = self.io_addr_assert::<$type_name>(offset);
> > +
> > + unsafe { bindings::$name(value, addr as _, ) }
> > + }
> > +
> > + /// Write IO data from a given offset.
> > + ///
> > + /// Bound checks are performed on runtime, it fails if the offset (plus the type size) is
> > + /// out of bounds.
> > + $(#[$attr])*
> > + pub fn $try_name(&self, value: $type_name, offset: usize) -> Result {
> > + let addr = self.io_addr::<$type_name>(offset)?;
> > +
> > + unsafe { bindings::$name(value, addr as _) }
> > + Ok(())
> > + }
> > + };
> > +}
> > +
>
> I am curious why we do not need `&mut self` to write to this memory? Is
> it OK to race on these writes?
Yes, concurrent writes to the same I/O mapped memory region (within the same
driver) should be totally fine.
In the end it's only the driver that can know about (and has to ensure) the
semantics, concurrency and ordering of those writes.
>
>
> Best regards,
> Andreas
>
Powered by blists - more mailing lists