On Tue, 24 Mar 2026 11:58:36 +0100 Alice Ryhl <[email protected]> wrote:
> On Tue, Mar 24, 2026 at 1:18 AM Deborah Brouwer > <[email protected]> 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.
