Re: [PATCH v1 3/3] samples: rust: platform: Add property child and reference args examples

[Danilo Krummrich]

On Wed, Jun 18, 2025 at 08:31:55AM -0500, Rob Herring wrote:
> On Wed, Jun 18, 2025 at 01:37:08PM +0200, Remo Senekowitsch wrote:
> > On Tue Jun 17, 2025 at 3:11 PM CEST, Danilo Krummrich wrote:
> > > On Tue, Jun 17, 2025 at 08:01:08AM -0500, Rob Herring wrote:
> > >> On Mon, Jun 16, 2025 at 10:45 AM Remo Senekowitsch <remo@xxxxxxxxxxx> wrote:
> > >> > @@ -91,6 +95,13 @@ fn properties_parse(dev: &device::Device) -> Result {
> > >> >          let prop: KVec<i16> = fwnode.property_read_array_vec(name, 4)?.required_by(dev)?;
> > >> >          dev_info!(dev, "'{name}'='{prop:?}' (KVec)\n");
> > >> >
> > >> > +        for child in fwnode.children() {
> > >> > +            let name = c_str!("test,ref-arg");
> > >> > +            let nargs = NArgs::N(2);
> > >> > +            let prop: FwNodeReferenceArgs = child.property_get_reference_args(name, nargs, 0)?;
> > >> 
> > >> Is there some reason we can just pass 2 in rather than nargs? Seems
> > >> overly verbose for my tastes.
> > >
> > > It's because you could also pass NArgs::Prop("foo-bar") to indicate the the
> > > name of the property telling the number of arguments.
> > >
> > > NArgs is defined as
> > >
> > > 	pub enum NArgs<'a> {
> > > 	    /// The name of the property of the reference indicating the number of
> > > 	    /// arguments.
> > > 	    Prop(&'a CStr),
> > > 	    /// The known number of arguments.
> > > 	    N(u32),
> > > 	}
> > >
> > > and FwNode::property_get_reference_args() can match against the corresponding
> > > enum variant to cover both cases.
> > 
> > I guess we could make the function generic if that's deemed worth it?
> > A trait and an implementation for `u32` and `&CStr` each. Similar to how
> > we made `property_read` generic.

I don't think that's worth it; I think the current version is fine as it is.

> There is a case where the cells property is optional and we fallback to 
> 0 cells if not found. #msi-cells is an example. I imagine NArgs could 
> express that while a generic could not? In any case, I don't expect 
> drivers to have to deal with that as it would be subsystem code handling 
> it.
> 
> As-is is fine I think. This function isn't too widely used that it could 
> be changed later if we change our minds.

Agreed.