Re: [PATCH v8 07/10] rust: io: introduce `IntoIoVal` trait and single-argument `write_val`

[Alexandre Courbot]

On Fri Mar 13, 2026 at 12:54 AM JST, Danilo Krummrich wrote:
<snip>
>>>> which is exactly the same length as the `write_val` equivalent - it's
>>>> just that you need to remember that `()` can be used in this case. But
>>>> if you can remember that your register type can be used with
>>>> `write_val`, then why not this? This actually makes me doubt that
>>>> `write_val` is needed at all, and if we get rid of it, then we have a
>>>> symmetric API.
>>>
>>> Still not symmetric, and I also don't think we will have a lot of fun explaining
>>> people why they have to call it as bar.write((), reg). :(
>>>
>>> OOC, how would you explain it when the question is raised without arguing with
>>> implementation details?
>>
>> This seems to indicate that instead of a `Io::write_val` method in `io.rs`,
>> we might need a `Io::write_reg` method in `register.rs` that is
>> dedicated to writing unambiguous registers exclusively. How does that
>> sound to you?
>
> I don't see it adds any value to factor it out with an extention trait, rename
> to write_reg() seems fine.
>
> Additionally, I'd like to leave it open for the future to add read_reg() method
> returning a generic (loc, val) tuple dereferencing to the value in case we see a
> repetition of the following pattern.
>
> 	let reg = bar.read(regs::NV_PFALCON_FALCON_RM::of::<E>());
>
> 	// modify reg
>
> 	bar.write(WithBase::of::<E>(), reg)
>
> The reason is the same as mentioned above. In most cases drivers don't want to
> switch the base location between a read and a write, i.e. write the value from A
> to B.

That's definitely a pattern we are seeing a lot already. I agree there
is a use-case for that.

>
> The most common case is to read from A and write back to A. For instance,
> talking to the Tyr folks, they told me that for the array registers they will
> have, they will never have the case that they want to write a register value
> from A to B.
>
> So, I still think it would be good to provide an option for drivers to prevent
> any mistakes in the first place.
>
> Now, obviously this would require that we also provide register accessors that
> take a mutable reference for this to work, but that doesn't seem like a big
> deal.
>
> I also don't think we have to do this now, but I'd like to have something like
> this in the future.

There are several ways we can achieve this. One would be to use the
macro to forward the bitfield setter methods to the containing type and
return an updated one. Or, we implement `Deref` on the containing type,
and add a set of `set_<field>` methods that modify the value in-place.

That way `read_reg` and `write_reg` should be symmetric and we remove
another cause of typos and mistakes.

I'l start thinking about it once I post the extracted `bitfield`
patches, as it makes it easier to look at the problem space.