rust/kernel/devres.rs | 18 +++++++++++++++--- rust/kernel/io.rs | 26 +++++++++++++++++++++++--- rust/kernel/io/resource.rs | 13 ++++++------- rust/kernel/scatterlist.rs | 2 +- 4 files changed, 45 insertions(+), 14 deletions(-)
This changes ResourceSize to use the resource_size_t typedef (currently
ResourceSize is defined as phys_addr_t), and moves ResourceSize to
kernel::io and defines PhysAddr next to it. Any usage of ResourceSize or
bindings::phys_addr_t that references a physical address is updated to
use the new PhysAddr typedef.
I included some cc stable annotations because I think it is useful to
backport this to v6.18. This is to make backporting drivers to the 6.18
LTS easier as we will not have to worry about changing imports when
backporting.
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
---
Changes in v2:
- Fix build error in last patch.
- Add cc stable.
- Link to v1: https://lore.kernel.org/r/20251106-resource-phys-typedefs-v1-0-0c0edc7301ce@google.com
---
Alice Ryhl (4):
rust: io: define ResourceSize as resource_size_t
rust: io: move ResourceSize to top-level io module
rust: scatterlist: import ResourceSize from kernel::io
rust: io: add typedef for phys_addr_t
rust/kernel/devres.rs | 18 +++++++++++++++---
rust/kernel/io.rs | 26 +++++++++++++++++++++++---
rust/kernel/io/resource.rs | 13 ++++++-------
rust/kernel/scatterlist.rs | 2 +-
4 files changed, 45 insertions(+), 14 deletions(-)
---
base-commit: 211ddde0823f1442e4ad052a2f30f050145ccada
change-id: 20251106-resource-phys-typedefs-6db37927d159
Best regards,
--
Alice Ryhl <aliceryhl@google.com>
On Wed Nov 12, 2025 at 8:48 PM AEDT, Alice Ryhl wrote:
Applied to driver-core-testing, thanks!
(@Miguel: Thanks for adding the tags for convenience. :)
I adjusted the tags as follows:
> Alice Ryhl (4):
> rust: io: define ResourceSize as resource_size_t
Cc: stable@vger.kernel.org
Fixes: 493fc33ec252 ("rust: io: add resource abstraction")
> rust: io: move ResourceSize to top-level io module
Cc: stable@vger.kernel.org # for v6.18 [1]
Link: https://lore.kernel.org/all/20251112-resource-phys-typedefs-v2-0-538307384f82@google.com/ [1]
> rust: scatterlist: import ResourceSize from kernel::io
> rust: io: add typedef for phys_addr_t
Cc: stable@vger.kernel.org # for v6.18 [1]
Link: https://lore.kernel.org/all/20251112-resource-phys-typedefs-v2-0-538307384f82@google.com/ [1]
On Wed, Nov 12, 2025 at 10:49 AM Alice Ryhl <aliceryhl@google.com> wrote: > > This changes ResourceSize to use the resource_size_t typedef (currently > ResourceSize is defined as phys_addr_t), and moves ResourceSize to > kernel::io and defines PhysAddr next to it. Any usage of ResourceSize or > bindings::phys_addr_t that references a physical address is updated to > use the new PhysAddr typedef. Should we have these as actual types instead of aliases? i.e. same discussion as for `Offset`. If there is a change of these getting mixed up, then I think we should just pay that price (not necessarily now, of course). > I included some cc stable annotations because I think it is useful to > backport this to v6.18. This is to make backporting drivers to the 6.18 > LTS easier as we will not have to worry about changing imports when > backporting. For context, will those drivers be backported upstream too? i.e. we have sometimes backported bits to simplify further backporting elsewhere, which is fine and up to the stable team of course, but I am not sure if using Option 1 (i.e. the Cc tag) may be a bit confusing in the log, i.e. Option 2 or 3 offer a better chance to give a reason. Thanks! Cheers, Miguel
On Wed, Nov 12, 2025 at 11:12:32AM +0100, Miguel Ojeda wrote: > On Wed, Nov 12, 2025 at 10:49 AM Alice Ryhl <aliceryhl@google.com> wrote: > > > > This changes ResourceSize to use the resource_size_t typedef (currently > > ResourceSize is defined as phys_addr_t), and moves ResourceSize to > > kernel::io and defines PhysAddr next to it. Any usage of ResourceSize or > > bindings::phys_addr_t that references a physical address is updated to > > use the new PhysAddr typedef. > > Should we have these as actual types instead of aliases? i.e. same > discussion as for `Offset`. > > If there is a change of these getting mixed up, then I think we should > just pay that price (not necessarily now, of course). Maybe later. Right now I think it's more trouble than it's worth. > > I included some cc stable annotations because I think it is useful to > > backport this to v6.18. This is to make backporting drivers to the 6.18 > > LTS easier as we will not have to worry about changing imports when > > backporting. > > For context, will those drivers be backported upstream too? I could imagine cases where a normal fix gets backported upstream and benefits from this, but I mainly thought it was useful for backports that happen downstream. > i.e. we have sometimes backported bits to simplify further backporting > elsewhere, which is fine and up to the stable team of course, but I am > not sure if using Option 1 (i.e. the Cc tag) may be a bit confusing in > the log, i.e. Option 2 or 3 offer a better chance to give a reason. Using a different option makes sense to me. Alice
On Wed, Nov 12, 2025 at 11:24 AM Alice Ryhl <aliceryhl@google.com> wrote:
>
> Maybe later. Right now I think it's more trouble than it's worth.
In case it may inspire a newcomer, I filled:
https://github.com/Rust-for-Linux/linux/issues/1203
https://github.com/Rust-for-Linux/linux/issues/1204
Cheers,
Miguel
On Wed, Nov 12, 2025 at 10:24:45AM +0000, Alice Ryhl wrote: > On Wed, Nov 12, 2025 at 11:12:32AM +0100, Miguel Ojeda wrote: > > On Wed, Nov 12, 2025 at 10:49 AM Alice Ryhl <aliceryhl@google.com> wrote: > > > > > > This changes ResourceSize to use the resource_size_t typedef (currently > > > ResourceSize is defined as phys_addr_t), and moves ResourceSize to > > > kernel::io and defines PhysAddr next to it. Any usage of ResourceSize or > > > bindings::phys_addr_t that references a physical address is updated to > > > use the new PhysAddr typedef. > > > > Should we have these as actual types instead of aliases? i.e. same > > discussion as for `Offset`. > > > > If there is a change of these getting mixed up, then I think we should > > just pay that price (not necessarily now, of course). > > Maybe later. Right now I think it's more trouble than it's worth. > > > > I included some cc stable annotations because I think it is useful to > > > backport this to v6.18. This is to make backporting drivers to the 6.18 > > > LTS easier as we will not have to worry about changing imports when > > > backporting. > > > > For context, will those drivers be backported upstream too? > > I could imagine cases where a normal fix gets backported upstream and > benefits from this, but I mainly thought it was useful for backports > that happen downstream. > > > i.e. we have sometimes backported bits to simplify further backporting > > elsewhere, which is fine and up to the stable team of course, but I am > > not sure if using Option 1 (i.e. the Cc tag) may be a bit confusing in > > the log, i.e. Option 2 or 3 offer a better chance to give a reason. > > Using a different option makes sense to me. On the other hand, I think that the first patch qualifies as an actual fix. Alice
On Wed, Nov 12, 2025 at 11:43 AM Alice Ryhl <aliceryhl@google.com> wrote:
>
> On the other hand, I think that the first patch qualifies as an actual
> fix.
Yes -- for that one we should add a Fixes instead:
Fixes: 493fc33ec252 ("rust: io: add resource abstraction")
Which means it may go to 6.17 as well and the "# for 6.18" part is not
needed in the other tag.
Cheers,
Miguel
© 2016 - 2025 Red Hat, Inc.