Re: [PATCH v2] drm/panthor: assign unique names to queues

[Chia-I Wu <olvaffe@gmail.com>]

On Mon, Sep 1, 2025 at 12:27 AM Boris Brezillon
<boris.brezillon@collabora.com> wrote:
<snipped>
> > diff --git a/drivers/gpu/drm/panthor/panthor_sched.c b/drivers/gpu/drm/panthor/panthor_sched.c
> > index ba5dc3e443d9c..62f17476e5852 100644
> > --- a/drivers/gpu/drm/panthor/panthor_sched.c
> > +++ b/drivers/gpu/drm/panthor/panthor_sched.c
> > @@ -360,6 +360,9 @@ struct panthor_queue {
> >       /** @entity: DRM scheduling entity used for this queue. */
> >       struct drm_sched_entity entity;
> >
> > +     /** @name: DRM scheduler name for this queue. */
> > +     char name[32];
>
> The base string ("panthor-queue---") is already 16 characters. You then
> have a group ID that's below 128 IIRC, and a queue ID that's no more
> than 15, so that's 5 more chars. This leaves you 10 chars for the
> client ID (theoretically a 64-bit integer). I know the logic is sane
> because you truncate the string, but I'm wondering if we shouldn't make
> this string bigger to cover the theoretical max client_id, or simply
> dynamically allocate it (kasprintf()), so we don't have to think about
> it if we end up adding more stuff to the string.
It seems we don't validate queue count.  Sending
https://lore.kernel.org/lkml/20250902192001.409738-1-olvaffe@gmail.com/
for that.

On a user device that opens the render node once per second, 10 chars
are good for 317 years.  It lasts significantly shorter on a test
device, but the uptime is also significantly shorter on such a device
(hopefully).

But kasprintf should be harmless here.  I can certainly switch to it.