mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Remo Senekowitsch" <remo@buenzli.dev>
To: "Rob Herring" <robh@kernel.org>
Cc: "Saravana Kannan" <saravanak@google.com>,
	"Miguel Ojeda" <ojeda@kernel.org>,
	"Alex Gaynor" <alex.gaynor@gmail.com>,
	"Boqun Feng" <boqun.feng@gmail.com>,
	"Gary Guo" <gary@garyguo.net>,
	"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
	"Benno Lossin" <lossin@kernel.org>,
	"Andreas Hindborg" <a.hindborg@kernel.org>,
	"Alice Ryhl" <aliceryhl@google.com>,
	"Trevor Gross" <tmgross@umich.edu>,
	"Danilo Krummrich" <dakr@kernel.org>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	"Dirk Behme" <dirk.behme@de.bosch.com>,
	linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
	rust-for-linux@vger.kernel.org
Subject: Re: [PATCH v7 5/9] rust: device: Introduce PropertyGuard
Date: Thu, 05 Jun 2025 18:16:41 +0200	[thread overview]
Message-ID: <DAEQGBNLMOP1.2RW2A0A4OBZQS@buenzli.dev> (raw)
In-Reply-To: <20250605150840.GA2539727-robh@kernel.org>

On Thu Jun 5, 2025 at 5:08 PM CEST, Rob Herring wrote:
> On Fri, May 30, 2025 at 09:28:52PM +0200, Remo Senekowitsch wrote:
>> This abstraction is a way to force users to specify whether a property
>> is supposed to be required or not. This allows us to move error
>> logging of missing required properties into core, preventing a lot of
>> boilerplate in drivers.
>> 
>> It will be used by upcoming methods for reading device properties.
>> 
>> Signed-off-by: Remo Senekowitsch <remo@buenzli.dev>
>> ---
>>  rust/kernel/device/property.rs | 59 ++++++++++++++++++++++++++++++++++
>>  1 file changed, 59 insertions(+)
>> 
>> diff --git a/rust/kernel/device/property.rs b/rust/kernel/device/property.rs
>> index 8e0414b0517e4..b789fbbd0e6cc 100644
>> --- a/rust/kernel/device/property.rs
>> +++ b/rust/kernel/device/property.rs
>> @@ -155,3 +155,62 @@ unsafe fn dec_ref(obj: ptr::NonNull<Self>) {
>>          unsafe { bindings::fwnode_handle_put(obj.cast().as_ptr()) }
>>      }
>>  }
>> +
>> +/// A helper for reading device properties.
>> +///
>> +/// Use [`Self::required_by`] if a missing property is considered a bug and
>> +/// [`Self::optional`] otherwise.
>> +///
>> +/// For convenience, [`Self::or`] and [`Self::or_default`] are provided.
>> +pub struct PropertyGuard<'fwnode, 'name, T> {
>> +    /// The result of reading the property.
>> +    inner: Result<T>,
>> +    /// The fwnode of the property, used for logging in the "required" case.
>> +    fwnode: &'fwnode FwNode,
>> +    /// The name of the property, used for logging in the "required" case.
>> +    name: &'name CStr,
>> +}
>> +
>> +impl<T> PropertyGuard<'_, '_, T> {
>> +    /// Access the property, indicating it is required.
>> +    ///
>> +    /// If the property is not present, the error is automatically logged. If a
>> +    /// missing property is not an error, use [`Self::optional`] instead. The
>> +    /// device is required to associate the log with it.
>> +    pub fn required_by(self, dev: &super::Device) -> Result<T> {
>> +        if self.inner.is_err() {
>> +            dev_err!(
>> +                dev,
>> +                "{}: property '{}' is missing\n",
>> +                self.fwnode.display_path(),
>
> Is it possible to make "{self.fwnode}: property..." work? Just need to 
> implement Display trait on FwNode, right?
>
> Doesn't look to me like we can alter what we print like in C, but for 
> dmesg it's usually the full path we want anyways.

Well, field access is not allowed directly in the format string. But if
there is a variable `fwnode`, then yes, one can do "{fwnode}" directly.
Implementing Display directly on FwNode seems like a good idea if the
full path is the intuitive default.

I tried it with an `ARef<FwNode>`, but that didn't work. I had to force
the dereference with `&*fwnode`. Maybe an `impl<T: Display> for ARef<T>`
could be added, the standard library does that for its smart pointers.

Remo

  reply	other threads:[~2025-06-05 16:16 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-30 19:28 [PATCH v7 0/9] More Rust bindings for device property reads Remo Senekowitsch
2025-05-30 19:28 ` [PATCH v7 1/9] rust: device: Create FwNode abstraction for accessing device properties Remo Senekowitsch
2025-05-30 19:28 ` [PATCH v7 2/9] rust: device: Enable accessing the FwNode of a Device Remo Senekowitsch
2025-05-30 19:28 ` [PATCH v7 3/9] rust: device: Add property_present() to FwNode Remo Senekowitsch
2025-05-30 19:28 ` [PATCH v7 4/9] rust: device: Enable printing fwnode name and path Remo Senekowitsch
2025-05-30 19:28 ` [PATCH v7 5/9] rust: device: Introduce PropertyGuard Remo Senekowitsch
2025-06-05 15:08   ` Rob Herring
2025-06-05 16:16     ` Remo Senekowitsch [this message]
2025-05-30 19:28 ` [PATCH v7 6/9] rust: device: Implement accessors for firmware properties Remo Senekowitsch
2025-05-30 19:28 ` [PATCH v7 7/9] rust: device: Add child accessor and iterator Remo Senekowitsch
2025-05-30 19:28 ` [PATCH v7 8/9] rust: device: Add property_get_reference_args Remo Senekowitsch
2025-05-30 19:28 ` [PATCH v7 9/9] samples: rust: platform: Add property read examples Remo Senekowitsch
2025-05-30 19:56 ` [PATCH v7 0/9] More Rust bindings for device property reads Danilo Krummrich
2025-05-30 21:45   ` Remo Senekowitsch
2025-05-30 21:50     ` Danilo Krummrich
2025-06-05 15:21       ` Rob Herring
2025-06-03  5:10 ` Dirk Behme

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DAEQGBNLMOP1.2RW2A0A4OBZQS@buenzli.dev \
    --to=remo@buenzli.dev \
    --cc=a.hindborg@kernel.org \
    --cc=alex.gaynor@gmail.com \
    --cc=aliceryhl@google.com \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun.feng@gmail.com \
    --cc=dakr@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dirk.behme@de.bosch.com \
    --cc=gary@garyguo.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lossin@kernel.org \
    --cc=ojeda@kernel.org \
    --cc=rafael@kernel.org \
    --cc=robh@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=saravanak@google.com \
    --cc=tmgross@umich.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®