[PATCH v2 0/3] Document Media Controller IOCTL number assignments

Sakari Ailus posted 3 patches 6 months, 3 weeks ago
Documentation/userspace-api/ioctl/ioctl-number.rst |  4 ++--
include/uapi/linux/media.h                         |  4 ++++
samples/rust/rust_misc_device.rs                   | 14 +++++++-------
3 files changed, 13 insertions(+), 9 deletions(-)
[PATCH v2 0/3] Document Media Controller IOCTL number assignments
Posted by Sakari Ailus 6 months, 3 weeks ago
Hello all,

The Media Controller uses IOCTL numbers with '|' type up to 0x81 but the
range from 0x80 upwards is documented to belong to samples. The samples,
however, are currently using these values. Solve the problem by bumping
the top of the MC range and the samples allocation by 0x10 as the samples
don't require a stable IOCTL interface.

since v1:

- Improved the commit message in the first patch.

- Added a patch to change the IOCTLs also in the Rust sample.

Sakari Ailus (3):
  Documentation: Bump media IOCTL reserved numbers
  media: uapi: Document IOCTL number assignment
  samples: rust_misc_device: Bump IOCTL numbers

 Documentation/userspace-api/ioctl/ioctl-number.rst |  4 ++--
 include/uapi/linux/media.h                         |  4 ++++
 samples/rust/rust_misc_device.rs                   | 14 +++++++-------
 3 files changed, 13 insertions(+), 9 deletions(-)

-- 
2.39.5
Re: [PATCH v2 0/3] Document Media Controller IOCTL number assignments
Posted by Sakari Ailus 3 months, 1 week ago
Hi Jonathan, Greg, Miguel, others,

On Tue, May 27, 2025 at 08:56:45AM +0300, Sakari Ailus wrote:
> Hello all,
> 
> The Media Controller uses IOCTL numbers with '|' type up to 0x81 but the
> range from 0x80 upwards is documented to belong to samples. The samples,
> however, are currently using these values. Solve the problem by bumping
> the top of the MC range and the samples allocation by 0x10 as the samples
> don't require a stable IOCTL interface.

Could you comment on this, please?

I'd prefer to merge this via the media tree if that's ok.

> 
> since v1:
> 
> - Improved the commit message in the first patch.
> 
> - Added a patch to change the IOCTLs also in the Rust sample.
> 
> Sakari Ailus (3):
>   Documentation: Bump media IOCTL reserved numbers
>   media: uapi: Document IOCTL number assignment
>   samples: rust_misc_device: Bump IOCTL numbers
> 
>  Documentation/userspace-api/ioctl/ioctl-number.rst |  4 ++--
>  include/uapi/linux/media.h                         |  4 ++++
>  samples/rust/rust_misc_device.rs                   | 14 +++++++-------
>  3 files changed, 13 insertions(+), 9 deletions(-)
> 

-- 
Kind regards,

Sakari Ailus
Re: [PATCH v2 0/3] Document Media Controller IOCTL number assignments
Posted by Greg Kroah-Hartman 3 months, 1 week ago
On Fri, Sep 05, 2025 at 01:25:33PM +0300, Sakari Ailus wrote:
> Hi Jonathan, Greg, Miguel, others,
> 
> On Tue, May 27, 2025 at 08:56:45AM +0300, Sakari Ailus wrote:
> > Hello all,
> > 
> > The Media Controller uses IOCTL numbers with '|' type up to 0x81 but the
> > range from 0x80 upwards is documented to belong to samples. The samples,
> > however, are currently using these values. Solve the problem by bumping
> > the top of the MC range and the samples allocation by 0x10 as the samples
> > don't require a stable IOCTL interface.
> 
> Could you comment on this, please?

Why not just live with the overlap?  What problem is this causing?  It's
the MC subsystem's "bug" in that it took over an ioctl range that was
already documented as being used by something else :)

thanks,

greg k-h
Re: [PATCH v2 0/3] Document Media Controller IOCTL number assignments
Posted by Sakari Ailus 3 months, 1 week ago
Hi Greg,

On Fri, Sep 05, 2025 at 12:32:45PM +0200, Greg Kroah-Hartman wrote:
> On Fri, Sep 05, 2025 at 01:25:33PM +0300, Sakari Ailus wrote:
> > Hi Jonathan, Greg, Miguel, others,
> > 
> > On Tue, May 27, 2025 at 08:56:45AM +0300, Sakari Ailus wrote:
> > > Hello all,
> > > 
> > > The Media Controller uses IOCTL numbers with '|' type up to 0x81 but the
> > > range from 0x80 upwards is documented to belong to samples. The samples,
> > > however, are currently using these values. Solve the problem by bumping
> > > the top of the MC range and the samples allocation by 0x10 as the samples
> > > don't require a stable IOCTL interface.
> > 
> > Could you comment on this, please?
> 
> Why not just live with the overlap?  What problem is this causing?  It's
> the MC subsystem's "bug" in that it took over an ioctl range that was
> already documented as being used by something else :)

I do agree ideally this shouldn't have happened in the first place, but I
think it's also cleaner if we can have separate ranges. Pushing samples out
a little doesn't look like an issue to me. The set also adds a comment on
not adding media IOCTLs beyond the new allocation.

-- 
Kind regards,

Sakari Ailus