History log of /linux-6.15/rust/helpers/io.c (Results 1 – 2 of 2)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: v6.15, v6.15-rc7, v6.15-rc6, v6.15-rc5, v6.15-rc4, v6.15-rc3, v6.15-rc2
# 584e6145 12-Apr-2025 FUJITA Tomonori <[email protected]>

rust: helpers: Remove volatile qualifier from io helpers

Remove the `volatile` qualifier used with __iomem in helper functions
in io.c. These helper functions are just wrappers around the
correspond

rust: helpers: Remove volatile qualifier from io helpers

Remove the `volatile` qualifier used with __iomem in helper functions
in io.c. These helper functions are just wrappers around the
corresponding accessors so they are unnecessary.

This fixes the following UML build error with CONFIG_RUST enabled:

In file included from rust/helpers/helpers.c:19:
rust/helpers/io.c:12:10: error: passing 'volatile void *' to parameter of type 'void *' discards qualifiers [-Werror,-Wincompatible-pointer-types-discards-qualifiers]
12 | iounmap(addr);
| ^~~~
arch/um/include/asm/io.h:19:42: note: passing argument to parameter 'addr' here
19 | static inline void iounmap(void __iomem *addr)
| ^
1 error generated.

[ Arnd explains [1] that removing the qualifier is the way forward
(thanks!):

Rihgt, I tried this last week when it came up first, removing the
'volatile' annotations in the asm-generic/io.h header and then
all the ones that caused build regressions on arm/arm64/x86
randconfig and allmodconfig builds. This patch is a little
longer than my original version as I did run into a few
regressions later.

As far as I can tell, none of these volatile annotations have
any actual effect, and most of them date back to ancient kernels
where this may have been required.

Leaving it out of the rust interface is clearly the right way,
and it shouldn't be too hard to upstream the changes below
when we need to, but I also don't see any priority to send these.
If anyone wants to help out, I can send them the whole patch.

I created an issue [2] in case someone wants to help. - Miguel ]

Fixes: ce30d94e6855 ("rust: add `io::{Io, IoRaw}` base types")
Signed-off-by: FUJITA Tomonori <[email protected]>
Cc: [email protected]
Reviewed-by: Danilo Krummrich <[email protected]>
Link: https://lore.kernel.org/rust-for-linux/[email protected]/ [1]
Link: https://github.com/Rust-for-Linux/linux/issues/1156 [2]
Link: https://lore.kernel.org/r/[email protected]
[ Reworded for relative paths. - Miguel ]
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...


Revision tags: v6.15-rc1, v6.14, v6.14-rc7, v6.14-rc6, v6.14-rc5, v6.14-rc4, v6.14-rc3, v6.14-rc2, v6.14-rc1, v6.13, v6.13-rc7, v6.13-rc6, v6.13-rc5, v6.13-rc4
# ce30d94e 19-Dec-2024 Danilo Krummrich <[email protected]>

rust: add `io::{Io, IoRaw}` base types

I/O memory is typically either mapped through direct calls to ioremap()
or subsystem / bus specific ones such as pci_iomap().

Even though subsystem / bus spec

rust: add `io::{Io, IoRaw}` base types

I/O memory is typically either mapped through direct calls to ioremap()
or subsystem / bus specific ones such as pci_iomap().

Even though subsystem / bus specific functions to map I/O memory are
based on ioremap() / iounmap() it is not desirable to re-implement them
in Rust.

Instead, implement a base type for I/O mapped memory, which generically
provides the corresponding accessors, such as `Io::readb` or
`Io:try_readb`.

`Io` supports an optional const generic, such that a driver can indicate
the minimal expected and required size of the mapping at compile time.
Correspondingly, calls to the 'non-try' accessors, support compile time
checks of the I/O memory offset to read / write, while the 'try'
accessors, provide boundary checks on runtime.

`IoRaw` is meant to be embedded into a structure (e.g. pci::Bar or
io::IoMem) which creates the actual I/O memory mapping and initializes
`IoRaw` accordingly.

To ensure that I/O mapped memory can't out-live the device it may be
bound to, subsystems must embed the corresponding I/O memory type (e.g.
pci::Bar) into a `Devres` container, such that it gets revoked once the
device is unbound.

Reviewed-by: Alice Ryhl <[email protected]>
Tested-by: Daniel Almeida <[email protected]>
Reviewed-by: Daniel Almeida <[email protected]>
Signed-off-by: Danilo Krummrich <[email protected]>
Tested-by: Dirk Behme <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...