On 30.10.24 15:05, Rob Herring 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. > >> >> [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 > } I think we have "optional" properties which can be there (== true) or not (== false). Let's assume for this example "test,i16-array" is such kind of "optional" property. With what you gave above we need two device tree accesses, then? One to check if it is there and one to read the data: let mut array = <empty_marker>; if dev.property_present(c_str!("test,i16-array")) { array = dev.property_read(c_str!("test,i16-array"))?; } ? Instead of these two accesses, I was thinking to use the error property_read() will return if the optional property is not there to just do one access: let mut array = <empty_marker>; if let Ok(val) = dev.property_read(c_str!("test,i16-array")) { array = val; } (and ignore the error case as its irrelvant in the optional case) Have I missed anything? Best regards Dirk
