[PATCH] Introduce Tyr

[Miguel Ojeda]

On Mon, Jun 30, 2025 at 5:23 PM Daniel Almeida
<daniel.almeida at collabora.com> wrote:
>
> When I said "in development"I was referring to "dead_code" specifically, as we
> will invariably have some of that until the other parts of the driver land.
>
> Just as an example: IMHO it doesn't make much sense to only introduce the
> register definitions used for this patch if we know for sure that:
>
> a) the currently unused definitions will be used once the subsequent parts land,
>
> b) they will not change, as they're derived from the hardware itself
>
> It makes more sense to just sit down and transcribe this part of the spec at
> once. It lowers the chance of copy and paste errors too.
>
> As I said, I was unfamiliar with "expect". Can it be made to work on a module
> level? Anyway, I can try to make this work with "expect" instead of “allow", no
> worries :)

Hmm... I am not sure what you are trying to say -- using `expect`
should just generally be as simple as changing the word from `allow`.
`expect` works like `allow`, except it will complain if the lint does
not trigger. It is essentially just that. And, yeah, it works on
modules.

In particular, it should not change how you decide anything else. In
other words, it is not about avoiding `dead_code`, but rather about
using a better `allow(dead_code)`.

Sometimes `allow` is simpler, e.g. when triggering a lint depends on
the kernel configuration or other reasons, in which case using `allow`
is just fine (please see the docs I linked). But I don't think you are
in those cases (e.g. I don't see conditional compilation, at least in
the patch above), so that is why I suggested it.

I hope that clarifies.

Cheers,
Miguel