Re: [PATCH v3 00/12] drm/tyr: Use register! macro

[Boris Brezillon <boris.brezillon@collabora.com>]

On Tue, 24 Mar 2026 11:58:36 +0100
Alice Ryhl <aliceryhl@google.com> wrote:

> On Tue, Mar 24, 2026 at 1:18 AM Deborah Brouwer
> <deborah.brouwer@collabora.com> wrote:
> >
> > This series changes the Tyr driver to use the kernel's register! macro
> > for hardware register access, replacing manual bit manipulation and custom
> > register structures with a more type-safe and maintainable approach.  
> 
> Please double check the AI review:
> https://sashiko.dev/#/patchset/20260323-b4-tyr-use-register-macro-v3-v3-0-a87daf9e4701%40collabora.com
> 
> There are some concerns regarding clock cleanup on patch 3 that seem valid.

I think all comments are valid except

> The commit message explicitly notes that the previous format matches
> the ID printed by the panthor driver. Is there a strong technical
> reason to break this log consistency between related DRM drivers just
> to avoid a single bit shift operation?

I don't think there was a good reason to hide the lower half of the raw
ID in Panthor. It's true that all the fields in the lower 16-bits are
extracted and printed separately, but it's just super confusing to have
only the higher 16 bits exposed (I've been tricked multiple times when
looking at some logs, and had to go look back at the source code to
remember what this raw id was exactly).

TLDR; that's one case where I think diverging from Panthor is a good
thing. I don't mind if the decision is to not expose the raw ID at
all and have all the fields extracted with something like

	mali-<name> (arch: <major>.<minor> product: <product> version: <major>.<minor>.<status>)

or if we decide to keep the raw ID around.