Chipset's Display was using Debug formatting ("{self:?}"), which is not
guaranteed to be stable. Use the existing name() method instead, which
provides stable lowercase strings suitable for firmware path generation.

Signed-off-by: Maurice Hieronymus <mhi@mailbox.org>
---
 drivers/gpu/nova-core/gpu.rs | 10 +---------
 1 file changed, 1 insertion(+), 9 deletions(-)

diff --git a/drivers/gpu/nova-core/gpu.rs b/drivers/gpu/nova-core/gpu.rs
index 629c9d2dc994..be8c882338ea 100644
--- a/drivers/gpu/nova-core/gpu.rs
+++ b/drivers/gpu/nova-core/gpu.rs
@@ -107,17 +107,9 @@ pub(crate) fn arch(&self) -> Architecture {
     }
 }
 
-// TODO
-//
-// The resulting strings are used to generate firmware paths, hence the
-// generated strings have to be stable.
-//
-// Hence, replace with something like strum_macros derive(Display).
-//
-// For now, redirect to fmt::Debug for convenience.
 impl fmt::Display for Chipset {
     fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
-        write!(f, "{self:?}")
+        write!(f, "{}", self.name())
     }
 }
 

base-commit: b69053dd3ffbc0d2dedbbc86182cdef6f641fe1b
-- 
2.51.2

On Thu Jan 1, 2026 at 7:41 PM CET, Maurice Hieronymus wrote:
> Chipset's Display was using Debug formatting ("{self:?}"), which is not
> guaranteed to be stable. Use the existing name() method instead, which
> provides stable lowercase strings suitable for firmware path generation.
>
> Signed-off-by: Maurice Hieronymus <mhi@mailbox.org>
> ---
>  drivers/gpu/nova-core/gpu.rs | 10 +---------
>  1 file changed, 1 insertion(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/nova-core/gpu.rs b/drivers/gpu/nova-core/gpu.rs
> index 629c9d2dc994..be8c882338ea 100644
> --- a/drivers/gpu/nova-core/gpu.rs
> +++ b/drivers/gpu/nova-core/gpu.rs
> @@ -107,17 +107,9 @@ pub(crate) fn arch(&self) -> Architecture {
>      }
>  }
>  
> -// TODO
> -//
> -// The resulting strings are used to generate firmware paths, hence the
> -// generated strings have to be stable.
> -//
> -// Hence, replace with something like strum_macros derive(Display).
> -//
> -// For now, redirect to fmt::Debug for convenience.
>  impl fmt::Display for Chipset {
>      fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
> -        write!(f, "{self:?}")
> +        write!(f, "{}", self.name())
>      }
>  }

This also converts the printed string to lowercase. While this is not that big a
deal, the solution we are looking for instead is what the TODO comment says: be
able to derive a Display implementation (for enums).

Now that we have syn in the kernel, this seems quite straight forward to
implement. Are you interested in working on this instead?

Thanks,
Danilo

On Sat, 2026-01-03 at 10:52 +0100, Danilo Krummrich wrote:
> On Thu Jan 1, 2026 at 7:41 PM CET, Maurice Hieronymus wrote:
> > Chipset's Display was using Debug formatting ("{self:?}"), which is
> > not
> > guaranteed to be stable. Use the existing name() method instead,
> > which
> > provides stable lowercase strings suitable for firmware path
> > generation.
> > 
> > Signed-off-by: Maurice Hieronymus <mhi@mailbox.org>
> > ---
> >  drivers/gpu/nova-core/gpu.rs | 10 +---------
> >  1 file changed, 1 insertion(+), 9 deletions(-)
> > 
> > diff --git a/drivers/gpu/nova-core/gpu.rs b/drivers/gpu/nova-
> > core/gpu.rs
> > index 629c9d2dc994..be8c882338ea 100644
> > --- a/drivers/gpu/nova-core/gpu.rs
> > +++ b/drivers/gpu/nova-core/gpu.rs
> > @@ -107,17 +107,9 @@ pub(crate) fn arch(&self) -> Architecture {
> >      }
> >  }
> >  
> > -// TODO
> > -//
> > -// The resulting strings are used to generate firmware paths,
> > hence the
> > -// generated strings have to be stable.
> > -//
> > -// Hence, replace with something like strum_macros
> > derive(Display).
> > -//
> > -// For now, redirect to fmt::Debug for convenience.
> >  impl fmt::Display for Chipset {
> >      fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
> > -        write!(f, "{self:?}")
> > +        write!(f, "{}", self.name())
> >      }
> >  }
> 
> This also converts the printed string to lowercase. While this is not
> that big a
> deal, the solution we are looking for instead is what the TODO
> comment says: be
> able to derive a Display implementation (for enums).
> 
> Now that we have syn in the kernel, this seems quite straight forward
> to
> implement. Are you interested in working on this instead?
> 
Definitely!

The Display implementation should print the enum value as it is,
without changing the case, correct?

I will have a look into that and send a new patch set in the next few
days.

> Thanks,
> Danilo