Re: [RFC v3 10/33] rust: drm/kms: Add ConnectorGuard::add_modes_noedid()

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

On Fri, Mar 21, 2025 at 07:52:23PM -0400, Lyude Paul wrote:
> On Fri, 2025-03-21 at 19:50 -0400, Lyude Paul wrote:
> > On Fri, 2025-03-14 at 13:02 +0100, Maxime Ripard wrote:
> > > On Wed, Mar 05, 2025 at 05:59:26PM -0500, Lyude Paul wrote:
> > > > A simple binding for drm_add_modes_noedid() using the ConnectorGuard type
> > > > we just added.
> > > > 
> > > > Signed-off-by: Lyude Paul <lyude@redhat.com>
> > > > ---
> > > >  rust/bindings/bindings_helper.h  |  1 +
> > > >  rust/kernel/drm/kms/connector.rs | 11 +++++++++++
> > > >  2 files changed, 12 insertions(+)
> > > > 
> > > > diff --git a/rust/bindings/bindings_helper.h b/rust/bindings/bindings_helper.h
> > > > index 27828dd36d4f2..846eb6eb8fc4c 100644
> > > > --- a/rust/bindings/bindings_helper.h
> > > > +++ b/rust/bindings/bindings_helper.h
> > > > @@ -13,6 +13,7 @@
> > > >  #include <drm/drm_crtc.h>
> > > >  #include <drm/drm_device.h>
> > > >  #include <drm/drm_drv.h>
> > > > +#include <drm/drm_edid.h>
> > > >  #include <drm/drm_encoder.h>
> > > >  #include <drm/drm_file.h>
> > > >  #include <drm/drm_fbdev_dma.h>
> > > > diff --git a/rust/kernel/drm/kms/connector.rs b/rust/kernel/drm/kms/connector.rs
> > > > index 14de3b0529f89..855a47b189a91 100644
> > > > --- a/rust/kernel/drm/kms/connector.rs
> > > > +++ b/rust/kernel/drm/kms/connector.rs
> > > > @@ -446,6 +446,17 @@ fn deref(&self) -> &Self::Target {
> > > >      }
> > > >  }
> > > >  
> > > > +impl<'a, T: DriverConnector> ConnectorGuard<'a, T> {
> > > > +    /// Add modes for a [`ConnectorGuard`] without an EDID.
> > > > +    ///
> > > > +    /// Add the specified modes to the connector's mode list up to the given maximum resultion.
> > > > +    /// Returns how many modes were added.
> > > > +    pub fn add_modes_noedid(&self, (max_h, max_v): (i32, i32)) -> i32 {
> > > 
> > > Why do we need a tuple of i32 there instead of two u32/usize parameter?
> > > 
> > > And the return type should be unsigned as well.
> > 
> > I think I was just copying C (or whatever the bindings here translate the C
> > type to), but I don't see any issue with changing this to u32.
> 
> ...wait. Now I remember why I did this: it's not that we expect it to be
> unsigned, it's that the largest possible u32 value cannot be expressed in a
> i32, and I think the C side of things uses i32. Days like this I really wish
> we had a u31...
> 
> think it would be OK for us to convert this to unsigned on the C side of
> things?

Yes please.