Re: [PATCH 2/5] rust: dma: add DMA addressing capabilities

[Danilo Krummrich]

On Wed Jul 16, 2025 at 11:15 AM CEST, Greg KH wrote:
> On Thu, Jul 10, 2025 at 09:45:44PM +0200, Danilo Krummrich wrote:
>> +/// Returns a bitmask with the lowest `n` bits set to `1`.
>> +///
>> +/// For `n` in `0..=64`, returns a mask with the lowest `n` bits set.
>> +/// For `n > 64`, returns `u64::MAX` (all bits set).
>> +///
>> +/// # Examples
>> +///
>> +/// ```
>> +/// use kernel::dma::dma_bit_mask;
>> +///
>> +/// assert_eq!(dma_bit_mask(0), 0);
>> +/// assert_eq!(dma_bit_mask(1), 0b1);
>> +/// assert_eq!(dma_bit_mask(64), u64::MAX);
>> +/// assert_eq!(dma_bit_mask(100), u64::MAX); // Saturates at all bits set.
>> +/// ```
>> +pub const fn dma_bit_mask(n: usize) -> u64 {
>> +    match n {
>> +        0 => 0,
>> +        1..=64 => u64::MAX >> (64 - n),
>> +        _ => u64::MAX,
>> +    }
>> +}
>
> This is just the C macro DMA_BIT_MASK(), right?  If so, can that be said
> here somewhere?

Yes, I think that'd be good.

> Or, how about turning DMA_BIT_MASK() into an inline
> function which could then be just called by the rust code directly
> instead?

Unfortunately, bindgen doesn't pick up either, so converting to an inline
function wouldn't help.

We could use it through a Rust helper though, but I considered this to be
unnecessary overhead. Whether that's relevant in this case is of course
questionable though. :)

Given that we also concluded that we want to return a new type (i.e. DmaMask)
rather than a u64, I feel like it's a bit cleaner to keep it self-contained.