On Thu Feb 12, 2026 at 9:26 AM CET, Alexandre Courbot wrote:
> + fn try_as_pio_loadable(&self) -> Result<FalconDmaFirmwarePioAdapter<'_,
> Self>> {
[...]
> + let dmem = {
> + let params = self.dmem_load_params();
> +
> + // SAFETY: we keep a reference to `self` for as long as this
> slice is alive, and the
> + // device will not access this DMA object since we are using PIO.
How is this guaranteed by this function? I.e. how is it prevented that this
function is never called when the device acesses the DMA memory?
> + let data = unsafe {
> + self.as_slice(
> + usize::from_safe_cast(params.src_start),
> + usize::from_safe_cast(params.len),
> + )?
> + };
> +
> + let dst_start = u16::try_from(params.dst_start).map_err(|_|
> EINVAL)?;
> +
> + FalconPioDmemLoadTarget { data, dst_start }
> + };
> +
> + Ok(FalconDmaFirmwarePioAdapter {
> + fw: self,
> + imem_sec,
> + imem_ns,
> + dmem,
> + })
> + }
> +}
<snip>
> +/// Adapter type that makes any DMA-loadable firmware also loadable via PIO.
> +///
> +/// Created using [`FalconDmaLoadable::try_as_pio_loadable`].
> +pub(crate) struct FalconDmaFirmwarePioAdapter<'a, T: FalconDmaLoadable +
> ?Sized> {
> + /// Reference to the DMA firmware.
> + fw: &'a T,
In v6 [1] I wrote:
> @@ -221,6 +286,8 @@ pub(crate) struct FwsecFirmware {
> desc: FalconUCodeDesc,
> /// GPU-accessible DMA object containing the firmware.
> ucode: FirmwareDmaObject<Self, Signed>,
> + /// Generic bootloader
> + gen_bootloader: Option<GenericBootloader>,
I'm not convinced this is a good idea. We probably want a HAL here and
have different FwsecFirmware types:
One with a DMA object and one with a system memory object when the
architecture uses PIO. In the latter case the object can have a
GenericBootloader field, i.e. this also gets us rid of the Option and
all the subsequent 'if chipset < Chipset::GA102' checks and 'match
gbl_fw' matches below.
So, I still wonder, why use an Adapter impl on top of DMA memory for PIO rather
than different base types with a common trait to avoid DMA allocations in the
PIO case altogether?
[1] https://lore.kernel.org/all/[email protected]/
