On Thu Feb 12, 2026 at 3:09 AM CET, John Hubbard wrote:
> 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.
Just to clarify, I mean we should implement Io and IoCapable right away, but
leave the rest as follow-up.
