Re: [RFC PATCH 0/1] cxl: Media Operations

[Davidlohr Bueso <dave@stgolabs.net>]

On Tue, 24 Mar 2026, Jonathan Cameron wrote:

>On Mon, 23 Mar 2026 13:40:12 -0700
>Davidlohr Bueso <dave@stgolabs.net> wrote:
>
>> Hello,
>>
>> This implements support for Media Operation cmd. It is marked RFC because of these
>> noteworthy points:
>>
>>  (i) Sysfs interfaces. These changes implement 'security/zero' and multiplex
>>      'security/sanitize' to allow dpa, len pairs for the range (no impact for
>>      current usage as whole-device). This breaks the 1 value per file "rule",
>>      and would be a first for drivers/cxl/*, so am I open to suggestions.
>
>Value is a vague sort of term.  It's one thing (an range) so seems fine to me.

I agree.

>
>>
>>  (ii) Background cmd handling semantics. Media operations are synchronous,
>>       which for raged zeroing operations makes sense and for range sanitize
>
>ranged
>
>>       differs from the current async handling for whole-device, so user response
>>       differs significantly, something I am not crazy about. Another downside
>>       of this is that it exposes lock hold times to be user-controllable, but is
>>       no different than what we do for fw. Fundamentally, users have the
>>       responsibility to break up the work into sane ranges.
>
>We could apply a limit on this and make that discoverable via another sysfs attribute.
>So let userspace request in say 1Gig chunks.  Would have to check that the device
>supports that granularity though.

If we agree that this will be performed synchronously, then yes, adding a size cap
would be necessary. I don't love having it in ie: security/range_limit(?), but that
could be created at discovery time when we know the granularity. Another way would
be to avoid the extra file and just print the limit in the error message - but I
guess dev_dbg() would be needed to not spam the dmesg. In any case with a cap,
while no guarantees, this also reduces the chances of the user triggering driver timeouts.

>I don't think there is anything in the spec today to let us query how long
>something takes (which would be a better way to bound this).

Correct, that is just something Scan Media allows for - and yes, that's exactly
the sane way to do the work breakup.

Thanks,
Davidlohr