The scope of the unsafe block can be appropriately reduced

[peamaeq]

In this function you use the unsafe keyword for some safe expressions.

We need to mark unsafe operations more precisely using unsafe keyword. Keeping unsafe blocks small can bring many benefits. For example, when mistakes happen, we can locate any errors related to memory safety within an unsafe block. This is the balance between Safe and Unsafe Rust. The separation is designed to make using Safe Rust as ergonomic as possible, but requires extra effort and care when writing Unsafe Rust.

Hope this PR can help you. Best regards. References https://doc.rust-lang.org/nomicon/safe-unsafe-meaning.html https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html

[jonas-schievink]

I don't think this is very good advice. It can often be helpful to include closely related operations in the unsafe block that contribute to making the unsafe operations safe, since that groups them together and makes the safety review easier.

That said, seeing this did remind me that set_bit_timing allows one to set arbitrary bits in the BTR register, which is potentially a bad idea, so I've pushed 3fc7a0e81975d4f25e61e0da81cd9e7a5e969e81 to fix that.