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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250618133155.GB1550757-robh@kernel.org>
Date: Wed, 18 Jun 2025 08:31:55 -0500
From: Rob Herring <robh@...nel.org>
To: Remo Senekowitsch <remo@...nzli.dev>
Cc: Danilo Krummrich <dakr@...nel.org>,
	Saravana Kannan <saravanak@...gle.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"Rafael J. Wysocki" <rafael@...nel.org>,
	Miguel Ojeda <ojeda@...nel.org>,
	Alex Gaynor <alex.gaynor@...il.com>,
	Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>,
	Björn Roy Baron <bjorn3_gh@...tonmail.com>,
	Benno Lossin <lossin@...nel.org>,
	Andreas Hindborg <a.hindborg@...nel.org>,
	Alice Ryhl <aliceryhl@...gle.com>, Trevor Gross <tmgross@...ch.edu>,
	Mark Brown <broonie@...nel.org>,
	Dirk Behme <dirk.behme@...bosch.com>, devicetree@...r.kernel.org,
	linux-kernel@...r.kernel.org, rust-for-linux@...r.kernel.org
Subject: Re: [PATCH v1 3/3] samples: rust: platform: Add property child and
 reference args examples

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@...nzli.dev> 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.

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.

Rob