On Wed Feb 18, 2026 at 3:50 PM JST, Eliot Courtney wrote:
> On Wed Feb 18, 2026 at 12:23 PM JST, Alexandre Courbot wrote:
>>> +/// Maximum size of a single GSP command in bytes.
>>> +///
>>> +/// A single command can span up to 16 GSP pages.
>>> +pub(crate) const MSGQ_MSG_SIZE_MAX: usize = GSP_PAGE_SIZE * 16;
>>
>> Where does this limitation come from? Is there a value in OpenRM that we
>> can add to the bindings as the source of truth?
>
> This is a GSP protocol level limitation. And yes, there's a constant
> so I'll add that to the bindings. Thanks!
>
>>
>>> +
>>> /// Circular buffer of a [`Msgq`].
>>> ///
>>> /// This area of memory is to be shared between the driver and the GSP to
>>> exchange commands or
>>> @@ -329,8 +334,11 @@ fn allocate_command(&mut self, size: usize) ->
>>> Result<GspCommand<'_>> {
>>> /// # Errors
>>> ///
>>> /// - `ETIMEDOUT` if space does not become available within the
>>> timeout.
>>> - /// - `EIO` if the command header is not properly aligned.
>>> + /// - `EIO` if the command header is not properly aligned or sizing is
>>> impossible.
>>
>> `sizing is impossible` should be its own error - probably `EMSGSIZE`
>> (which would need to be added to `kernel/error.rs` in its own patch).
>> Also the wording sounds a bit confusing to me, why not say "if the
>> command is larger than `MSGQ_MSG_SIZE_MAX`"?
>
> Do you mean in its own patch in this series, or sent as a separate patch
> to a different tree (e.g. rfl)?
Please send it with this series, it is small enough that we can probably
get an Acked-by and merge it through the DRM tree.
>
> Tangential but I feel like some of the errors in this file are a bit
> odd, like the existing EIO if the command doesn't fit (which it always
> should). WDYT?
There is certainly room for improvement - if you see room for improving
(or better, removing!) errors, please don't hesitate!
