[PATCH] Introduce Tyr

Daniel Almeida daniel.almeida at collabora.com
Mon Jun 30 15:22:52 UTC 2025


Hi Miguel,

>> Hmm, I must say I did not know that this was a thing.
>> 
>> Why is it better than [#allow] during the development phase?
> 
> I have some notes at:
> 
>    https://docs.kernel.org/rust/coding-guidelines.html#lints
> 
> Generally speaking, we default to `expect` unless there is a reason
> not to (I list some possible reasons in the link), because `expect`
> forces us to clean it when unneeded.
> 
> Not sure what you mean by "development phase" -- even if Tyr is under
> development, it should still try to conform to the usual guidelines.
> Of course, if a particular `expect` would be a pain, then please feel
> free to use `allow`. But is that case here? i.e. you will want to
> remove the `allow` anyway when you add the new code, no?
> 
> Thanks!
> 
> Cheers,
> Miguel

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 :)

— Daniel


More information about the dri-devel mailing list