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] [day] [month] [year] [list]

Message-ID: <aFLKKr1bQue9iuTk@pollux>
Date: Wed, 18 Jun 2025 16:16:10 +0200
From: Danilo Krummrich <dakr@...nel.org>
To: Rob Herring <robh@...nel.org>
Cc: Remo Senekowitsch <remo@...nzli.dev>,
	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 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@...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.

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.