From: Daniel Almeida <daniel.almeida@collabora.com>
To: ojeda@kernel.org, alex.gaynor@gmail.com, boqun.feng@gmail.com,
gary@garyguo.net, bjorn3_gh@protonmail.mco,
benno.lossin@proton.me, a.hindborg@kernel.org,
aliceryhl@google.com, tmgross@umich.edu,
gregkh@linuxfoundation.org, rafael@kernel.org, dakr@kernel.org,
boris.brezillon@collabora.com, robh@kernel.org
Cc: Daniel Almeida <daniel.almeida@collabora.com>,
rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH v6 0/3] rust: platform: add Io support
Date: Thu, 30 Jan 2025 19:05:20 -0300 [thread overview]
Message-ID: <20250130220529.665896-1-daniel.almeida@collabora.com> (raw)
Changes in v6:
- Added Fiona as co-developer in the first patch, as I merged part of his code
from the LED driver series (thanks, Fiona)
- (Fiona) added the ResourceSize type, thereby fixing the u32 vs u64 issues
pointed out by Christian
- Moved the request_region, release_region and friends to resource.rs
- Added the Region type. This type represents a resource returned by
`request_region` and friends. It is also owned, representing the fact
that the region remains marked as busy until release_region is called on
drop. (Thanks Alice, for pointing out this pattern)
- Rewrote the IoMem abstraction to implement a separate type for exclusive
access to an underlying region. I really disliked the `EXCLUSIVE` const
generic, as it was definitely not ergonomic, i.e.:
`IoMem<0, false>`
...doesn't really say much. In fact, I believe that boolean parameters
hurt readability in general.
This new approach lets users build either regular IoMem's, which basically
call ioremap under the covers, and ExclusiveIoMem's , which also call request_region
via the Region type.
- Added access to the ioresource_port and ioresource_mem globals.
Link to v5: https://lore.kernel.org/rust-for-linux/20250116125632.65017-1-daniel.almeida@collabora.com/
Changes in v5:
- resend v5, as the r4l list was not cc'd
- use srctree where applicable in the docs (Alice)
- Remove 'mut' in Resource::from_ptr() (Alice)
- Add 'invariants' section for Resource (Alice)
- Fix typos in mem.rs (Alice)
- Turn 'exclusive' into a const generic (Alice)
- Fix example in platform.rs (Alice)
- Rework the resource.is_null() check (Alice)
- Refactor IoMem::new() to return DevRes<IoMem> directly (Danilo)
link to v4: https://lore.kernel.org/rust-for-linux/20250109133057.243751-1-daniel.almeida@collabora.com/
Changes in v4:
- Rebased on top of driver-core-next
- Split series in multiple patches (Danilo)
- Move IoMem and Resource into its own files (Danilo)
- Fix a missing "if exclusive {...}" check (Danilo)
- Fixed the example, since it was using the old API (Danilo)
- Use Opaque in `Resource`, instead of NonNull and PhantomData (Boqun)
- Highlight that non-exclusive access to the iomem might be required in some cases
- Fixed the safety comment in IoMem::deref()
Link to v3: https://lore.kernel.org/rust-for-linux/20241211-topic-panthor-rs-platform_io_support-v3-1-08ba707e5e3b@collabora.com/
Changes in v3:
- Rebased on top of v5 for the PCI/Platform abstractions
- platform_get_resource is now called only once when calling ioremap
- Introduced a platform::Resource type, which is bound to the lifetime of the
platform Device
- Allow retrieving resources from the platform device either by index or
name
- Make request_mem_region() optional
- Use resource.name() in request_mem_region
- Reword the example to remove an unaligned, out-of-bounds offset
- Update the safety requirements of platform::IoMem
Changes in v2:
- reworked the commit message
- added missing request_mem_region call (Thanks Alice, Danilo)
- IoMem::new() now takes the platform::Device, the resource number and
the name, instead of an address and a size (thanks, Danilo)
- Added a new example for both sized and unsized versions of IoMem.
- Compiled the examples using kunit.py (thanks for the tip, Alice!)
- Removed instances of `foo as _`. All `as` casts now spell out the actual
type.
- Now compiling with CLIPPY=1 (I realized I had forgotten, sorry)
- Rebased on top of rust-next to check for any warnings given the new
unsafe lints.
Daniel Almeida (3):
rust: io: add resource abstraction
rust: io: mem: add a generic iomem abstraction
rust: platform: allow ioremap of platform resources
rust/bindings/bindings_helper.h | 1 +
rust/helpers/io.c | 36 +++++
rust/kernel/io.rs | 3 +
rust/kernel/io/mem.rs | 125 ++++++++++++++++
rust/kernel/io/resource.rs | 252 ++++++++++++++++++++++++++++++++
rust/kernel/platform.rs | 123 +++++++++++++++-
6 files changed, 539 insertions(+), 1 deletion(-)
create mode 100644 rust/kernel/io/mem.rs
create mode 100644 rust/kernel/io/resource.rs
--
2.48.0
next reply other threads:[~2025-01-30 22:14 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-30 22:05 Daniel Almeida [this message]
2025-01-30 22:05 ` [PATCH v6 1/3] rust: io: add resource abstraction Daniel Almeida
2025-01-31 10:02 ` Daniel Sedlak
2025-02-09 11:45 ` Guangbo Cui
2025-01-30 22:05 ` [PATCH v6 2/3] rust: io: mem: add a generic iomem abstraction Daniel Almeida
2025-01-31 10:09 ` Daniel Sedlak
2025-02-02 22:45 ` Asahi Lina
2025-02-03 9:26 ` Alice Ryhl
2025-02-03 14:14 ` Asahi Lina
2025-02-03 9:32 ` Alice Ryhl
2025-02-05 14:56 ` Guangbo Cui
2025-02-06 15:43 ` Alice Ryhl
2025-02-06 15:58 ` Miguel Ojeda
2025-02-06 15:58 ` Guangbo Cui
2025-02-06 16:11 ` Miguel Ojeda
[not found] ` <tencent_E1DC219DB45DC03A8454E2124D238DCEC705@qq.com>
2025-02-06 17:13 ` Danilo Krummrich
2025-02-07 13:25 ` Daniel Almeida
2025-02-06 15:57 ` Daniel Almeida
2025-02-06 16:05 ` Miguel Ojeda
2025-04-01 15:57 ` Joel Fernandes
2025-04-01 16:44 ` Danilo Krummrich
2025-04-01 17:07 ` Joel Fernandes
2025-01-30 22:05 ` [PATCH v6 3/3] rust: platform: allow ioremap of platform resources Daniel Almeida
2025-01-31 10:19 ` Daniel Sedlak
2025-01-31 11:36 ` Alice Ryhl
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=20250130220529.665896-1-daniel.almeida@collabora.com \
--to=daniel.almeida@collabora.com \
--cc=a.hindborg@kernel.org \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=benno.lossin@proton.me \
--cc=bjorn3_gh@protonmail.mco \
--cc=boqun.feng@gmail.com \
--cc=boris.brezillon@collabora.com \
--cc=dakr@kernel.org \
--cc=gary@garyguo.net \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ojeda@kernel.org \
--cc=rafael@kernel.org \
--cc=robh@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=tmgross@umich.edu \
/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.