On Wed, Oct 30, 2024 at 3:06 PM Rob Herring <robh@xxxxxxxxxx> wrote: > > On Wed, Oct 30, 2024 at 3:15 AM Alice Ryhl <aliceryhl@xxxxxxxxxx> wrote: > > > > 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. > > It was num::Integer which seems to be similar. Abstracting over a set of C functions that matches on the different integer types seems like it'll be pretty common in the kernel. I think it's perfectly fine for you to add a trait for that purpose. > > [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. > > I'm not sure I want that actually. > > DT boolean is a bit special. A property not present is false. > Everything else is true. For example, 'prop = <0>' or 'prop = > "string"' are both true. I'm moving things in the kernel to be > stricter so that those cases are errors. I recently introduced > (of|device)_property_present() for that reason. There's no type > information stored in DT. At the DT level, it's all just byte arrays. > However, we now have all the type information for properties within > the schema. So eventually, I want to use that to warn on accessing > properties with the wrong type. > > For example, I think I don't want this to work: > > if dev.property_read(c_str!("test,i16-array"))? { > // do something > } > > But instead have: > > if dev.property_present(c_str!("test,i16-array")) { > // do something > } > > To actually warn on property_read_bool, I'm going to have to rework > the underlying C implementation to separate device_property_present > and device_property_read_bool implementations. Having bool separate seems fine to me. Alice
