On 2/11/26 2:57 AM, Danilo Krummrich wrote:
> On Tue Feb 10, 2026 at 3:45 AM CET, John Hubbard wrote:
...
>> + #[expect(unused)]
>> + pub(crate) fn read_emem(&self, bar: &Bar0, offset: u32, data: &mut
>> [u8]) -> Result {
>> + // TODO: replace with `is_multiple_of` once the MSRV is >= 1.82.
>> + if offset % 4 != 0 || data.len() % 4 != 0 {
>> + return Err(EINVAL);
>> + }
>> +
>> + regs::NV_PFALCON_FALCON_EMEM_CTL::default()
>> + .set_rd_mode(true)
>> + .set_offset(offset)
>> + .write(bar, &Fsp::ID);
>> +
>> + for chunk in data.chunks_exact_mut(4) {
>> + let word = regs::NV_PFALCON_FALCON_EMEM_DATA::read(bar,
>> &Fsp::ID).data();
>> + chunk.copy_from_slice(&word.to_le_bytes());
>> + }
>> +
>> + Ok(())
>> + }
>> +}
>
> Technically, we could represent this as a separate I/O backend and use IoView
> /
> IoSlice (once we have it).
>
> So, you could have Falcon<Fsp>::emem(), which returns an &Emem that implements
> Io [1].
>
> This way we would get IoView and register!() for free on top of it. IoView
> will
> allow you to modify fields of the FSP structures similar to what we have for
> DMA
> with dma_read!() and dma_write!().
>
> I just briefly glanced at the subsequent patches, but it looks like this could
> save quite some code.
>
> We may not get the full potential right away, as IoView is still WIP, but I
> think it makes sense to consider it for a follow-up.
>
Yes, let's keep this in mind.
thanks,
--
John Hubbard
