On Mon Sep 14, 2026 at 2:45 AM CEST, Alexandre Courbot wrote:
> On Mon Sep 14, 2026 at 6:08 AM JST, Matteo Kloiber wrote:
>> On Mon Sep 7, 2026 at 11:43 AM JST, Alexandre Courbot wrote:
>>> It also means that without patch 1, nova-core would split the firmware
>>> into hundreds of 64KB SG entries, which is not breaking but still
>>> something we want to avoid. The correct fix is to make sure that
>>> `dma_set_max_seg_size` is called by the driver, and while we are at it
>>> we also want every driver to call `dma_set_mask_and_coherent`. Ideally
>>> we would use the type system to make sure that both functions are called
>>> before any DMA operation can take place (using a safe interface), but
>>> I'm not quite sure yet how we can do this.
>>
>> This sounds sensible indeed. Should I open a thread regarding that on Zulip?
>
> Probably not necessary, the mailing-list has a larger audience and is
> the right place for this. I expect people will jump in here with their
> thoughts.
The problem with those is not that they must strictly be called before
allocating DMA memory, but they must not be called concurrently with other DMA
operations, such as allocating DMA memory, as it would technically be a data
race.
Now, we can't really have drivers define them statically (e.g. in the driver
trait) as there may be cases where it depends on the runtime state or properties
of the device queried at runtime. Sometimes it is also defined through OF
properties (which from a kernel perspective are runtime values too).
For the same reason it is also pretty hard to invent a type state pattern for
those setters that is not getting ridiculously complex without much value, which
is why we just kept them unsafe for the time being.
The best option to get rid of the unsafe would probably be to use atomics
instead. It would however be a rather big change, what makes it a bit of a hard
sell, given that the reason of this unsafe is more on the theoretical side of
things.
Theoretically, we could also optimize the situation for when it is statically
known, e.g. some dma::Config trait that can be implemented, such that the bus
can set the before calling probe(). But we'd really want this to work per device
ID table entry, as it may differ between supported devices. But that might not
be quite straight forward without associated_type_defaults. The simplest thing I
could think of is some callback, such as
fn dma_info(id_info: Option<&Self::IdInfo>) -> DmaInfo
which is called before probe(), but that's not great either. Maybe there is a
good solution for this, but I'd first want to exhaust getting the setters safe.
