On Fri Oct 17, 2025 at 3:38 AM CEST, Alexandre Courbot wrote: > On Fri Oct 17, 2025 at 10:15 AM JST, Alistair Popple wrote: >> On 2025-10-17 at 11:43 +1100, Alexandre Courbot <[email protected]> >> wrote... >>> On Fri Oct 17, 2025 at 8:11 AM JST, Danilo Krummrich wrote: >>> > On Fri Oct 17, 2025 at 1:03 AM CEST, Alistair Popple wrote: >>> >> On 2025-10-16 at 17:23 +1100, Alexandre Courbot <[email protected]> >>> >> wrote... >>> >>> On Mon Oct 13, 2025 at 3:20 PM JST, Alistair Popple wrote: >>> >>> > +impl GspFwWprMeta { >>> >>> > + pub(crate) fn new(gsp_firmware: &GspFirmware, fb_layout: >>> >>> > &FbLayout) -> Self { >>> >>> > + Self(bindings::GspFwWprMeta { >>> >>> > + magic: r570_144::GSP_FW_WPR_META_MAGIC as u64, >>> >>> > + revision: u64::from(r570_144::GSP_FW_WPR_META_REVISION), >>> >>> > + sysmemAddrOfRadix3Elf: gsp_firmware.radix3_dma_handle(), >>> >>> > + sizeOfRadix3Elf: gsp_firmware.size as u64, >>> >>> >>> >>> Very unfortunately I'm afraid we will need to replace the `as` in this >>> >>> method with `u64::try_from` and make it return a `Result` for now. >>> >> >>> >> And presumably most of the other `as` keywords in this function dealing >>> >> with >>> >> usize as well? Have made the change but would you mind quickly explaining >>> >> why this is needed? Is the concern that usize might be more than 64 bits >>> >> or >>> >> something? >>> >>> Indeed, the concern is that `as` performs a lossy conversion without >>> warning, which could catch us off-guard if e.g. some type changes in the >>> bindings. >>> >>> > >>> > Since nova-core depends on CONFIG_64BIT, I think we want a helper >>> > function that >>> > converts usize to u64 infallibly. >>> > >>> > This helper function can simply generate a compile time error, when >>> > !CONFIG_64BIT, etc. >>> > >>> > We can do this locally in nova-core, but it could also find it's place in >>> > the >>> > generic infrastructure. nova-core clearly won't be the last driver >>> > running into >>> > this inconvinience. >>> >>> That would definitely be the correct way to address this. >> >> Sure. Although I don't really have a problem with the binding constructors >> being >> fallible as plenty of the others are anyway. > > I think we can address the non-fallible conversions as a separate task > (as there are many sites that could be similarly optimized in the > nova-core code), so fallible constructors are acceptable imho.
The infallible conversion function is trivial to implement. If you prefer, we can also add it in nova-core first and subsequently move it to generic infrastructure. I prefer not to introduce more as-casts or fallible conversions we have to clean up subsequently.
