On Tue, Oct 29, 2024 at 8:35 PM Rob Herring <robh@xxxxxxxxxx> wrote: > > On Tue, Oct 29, 2024 at 1:57 PM Miguel Ojeda > <miguel.ojeda.sandonis@xxxxxxxxx> wrote: > > > > On Tue, Oct 29, 2024 at 7:48 PM Alice Ryhl <aliceryhl@xxxxxxxxxx> wrote: > > > > > > One option is to define a trait for integers: > > Yeah, but that doesn't feel like something I should do here. I imagine > other things might need the same thing. Perhaps the bindings for > readb/readw/readl for example. And essentially the crate:num already > has the trait I need. Shouldn't the kernel mirror that? I recall > seeing some topic of including crates in the kernel? You can design the trait to look similar to traits in external crates. We did that for FromBytes/AsBytes. I assume you're referring to the PrimInt trait [1]? That trait doesn't really let you get rid of the catch-all case, and it's not even unreachable due to the u128 type. [1]: https://docs.rs/num-traits/0.2.19/num_traits/int/trait.PrimInt.html > > +1, one more thing to consider is whether it makes sense to define a > > DT-only trait that holds all the types that can be a device property > > (like `bool` too, not just the `Integer`s). > > > > Then we can avoid e.g. `property_read_bool` and simply do it in `property_read`. > > Is there no way to say must have traitA or traitB? No. What should it do if you pass it something that implements both traits? If you want a single function name, you'll need one trait. Alice
