public inbox for linux-pwm@vger.kernel.org
 help / color / mirror / Atom feed
From: "Gary Guo" <gary@garyguo.net>
To: "Matthew Maurer" <mmaurer@google.com>,
	"Bjorn Andersson" <andersson@kernel.org>,
	"Konrad Dybcio" <konradybcio@kernel.org>,
	"Satya Durga Srinivasu Prabhala" <satyap@quicinc.com>,
	"Miguel Ojeda" <ojeda@kernel.org>,
	"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>,
	"Daniel Almeida" <daniel.almeida@collabora.com>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	"David Airlie" <airlied@gmail.com>,
	"Simona Vetter" <simona@ffwll.ch>,
	"Michal Wilczynski" <m.wilczynski@samsung.com>,
	"Dave Ertman" <david.m.ertman@intel.com>,
	"Ira Weiny" <ira.weiny@intel.com>,
	"Leon Romanovsky" <leon@kernel.org>
Cc: "Trilok Soni" <tsoni@quicinc.com>, <linux-kernel@vger.kernel.org>,
	<linux-arm-msm@vger.kernel.org>, <rust-for-linux@vger.kernel.org>,
	<driver-core@lists.linux.dev>, <dri-devel@lists.freedesktop.org>,
	<linux-pwm@vger.kernel.org>
Subject: Re: [PATCH v2 5/6] rust: debugfs: Allow access to device in Devres-wrapped scopes
Date: Tue, 03 Feb 2026 16:47:55 +0000	[thread overview]
Message-ID: <DG5HAM6F5QYE.1ZFO7GD3SL9V0@garyguo.net> (raw)
In-Reply-To: <20260203-qcom-socinfo-v2-5-d6719db85637@google.com>

On Tue Feb 3, 2026 at 3:46 PM GMT, Matthew Maurer wrote:
> This adds support for creating a DebugFS directory which is aware that
> it is bound to a device. As a result, callbacks under that directory
> have access to a bound device which gives them efficient access to other
> Devres, ability to use dev_err! and friends, etc.
>
> Signed-off-by: Matthew Maurer <mmaurer@google.com>
> ---
>  rust/kernel/debugfs.rs | 40 ++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 40 insertions(+)
>
> diff --git a/rust/kernel/debugfs.rs b/rust/kernel/debugfs.rs
> index d7b8014a6474698235203f2b7d8fec96f2bb43f8..ac614d693fa73929d095b669e9ba61958bec609e 100644
> --- a/rust/kernel/debugfs.rs
> +++ b/rust/kernel/debugfs.rs
> @@ -11,6 +11,11 @@
>  #[cfg(CONFIG_DEBUG_FS)]
>  use crate::sync::Arc;
>  use crate::{
> +    device::{
> +        Bound,
> +        Device, //
> +    },
> +    devres::Devres,
>      fmt,
>      prelude::*,
>      str::CStr,
> @@ -722,3 +727,38 @@ fn new(name: &CStr) -> ScopedDir<'data, 'static> {
>          }
>      }
>  }
> +
> +impl<'a, T: 'a + Send> Devres<Scope<T>> {
> +    /// Creates a new scope, which is a directory at the root of the debugfs filesystem,
> +    /// associated with some data `T`, enclosed in a [`Devres`] for the provided device.
> +    ///
> +    /// The `init` closure is called to populate the directory with files and subdirectories. These
> +    /// files can reference the data stored in the scope. Because it is stored inside a `Devres`,
> +    /// the init method is granted access to a `&Device<Bound>`.
> +    ///
> +    /// This can be used for cheaply accessing device-protected data inside DebugFS methods or
> +    /// accessing device-specific methods (e.g. [`dev_err!`]).
> +    ///
> +    /// The entire directory tree created within the scope will be removed when the returned
> +    /// `Scope` handle is dropped.
> +    pub fn dir<E: 'a, F>(
> +        dev: &'a Device<Bound>,
> +        data: impl PinInit<T, E> + 'a,
> +        name: &'a CStr,
> +        init: F,
> +    ) -> impl PinInit<Self, Error> + 'a
> +    where
> +        F: for<'data, 'dir> FnOnce(&'data T, &'data Device<Bound>, &'dir ScopedDir<'data, 'dir>)
> +            + 'a,
> +        Error: From<E>,
> +    {
> +        Devres::new(
> +            dev,
> +            Scope::new(data, |data| {
> +                let scoped = ScopedDir::new(name);
> +                init(data, dev, &scoped);
> +                scoped.into_entry()
> +            }),
> +        )
> +    }
> +}

I think it is a big strange to have this on `Devres` (in patch v6 it has `Devres::dir` doesn't make
too much sense). I would suggest that we domsomething like

    impl<'a, T: 'a + Send> Scope<T> {
        pub fn devres_dir(
            ...
        ) -> impl PinInit<Devres<Self>, Error> + 'a;
    }

To me `Devres` is just a generic container type, just like `Arc` and `ARef`, so
the assoc functions should be defined on the concrete type.

Also: is there a reason that this needs a special API, and by

    Devres::new(device, Scope::dir(data, c"name", |data| {
        // use data and device
    });

?

Best,
Gary



  parent reply	other threads:[~2026-02-03 16:48 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-03 15:46 [PATCH v2 0/6] soc: qcom: socinfo: Convert to Rust Matthew Maurer
2026-02-03 15:46 ` [PATCH v2 1/6] rust: Add sparse_array! helper macro Matthew Maurer
2026-02-03 15:46 ` [PATCH v2 2/6] rust: io: Support copying arrays and slices Matthew Maurer
2026-02-03 15:53   ` Danilo Krummrich
2026-02-03 15:46 ` [PATCH v2 3/6] rust: device: Support testing devices for equality Matthew Maurer
2026-02-03 15:56   ` Danilo Krummrich
2026-02-03 16:05   ` Gary Guo
2026-02-03 16:15   ` Greg Kroah-Hartman
2026-02-03 16:17   ` Greg Kroah-Hartman
2026-02-03 16:29     ` Danilo Krummrich
2026-02-03 16:40       ` Greg Kroah-Hartman
2026-02-03 16:46         ` Danilo Krummrich
2026-02-03 17:17           ` Matthew Maurer
2026-04-02 13:46   ` Uwe Kleine-König
2026-02-03 15:46 ` [PATCH v2 4/6] rust: auxiliary: Support accessing raw aux pointer Matthew Maurer
2026-02-03 15:55   ` Danilo Krummrich
2026-02-03 15:46 ` [PATCH v2 5/6] rust: debugfs: Allow access to device in Devres-wrapped scopes Matthew Maurer
2026-02-03 15:59   ` Danilo Krummrich
2026-02-03 16:47   ` Gary Guo [this message]
2026-02-03 16:58     ` Danilo Krummrich
2026-02-03 18:04     ` Matthew Maurer
2026-02-03 15:46 ` [PATCH v2 6/6] soc: qcom: socinfo: Convert to Rust Matthew Maurer
2026-02-03 16:28   ` Greg Kroah-Hartman
2026-02-03 16:35     ` Danilo Krummrich
2026-02-03 16:48       ` Greg Kroah-Hartman
2026-02-03 16:56         ` Danilo Krummrich
2026-02-03 17:17           ` Gary Guo
2026-02-03 17:26             ` Matthew Maurer
2026-02-03 17:59             ` Danilo Krummrich
2026-02-03 17:37     ` Matthew Maurer
2026-02-04  8:38       ` Greg Kroah-Hartman
2026-02-03 20:27   ` Bjorn Andersson
2026-02-04  8:40     ` Greg Kroah-Hartman

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=DG5HAM6F5QYE.1ZFO7GD3SL9V0@garyguo.net \
    --to=gary@garyguo.net \
    --cc=a.hindborg@kernel.org \
    --cc=airlied@gmail.com \
    --cc=aliceryhl@google.com \
    --cc=andersson@kernel.org \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun.feng@gmail.com \
    --cc=dakr@kernel.org \
    --cc=daniel.almeida@collabora.com \
    --cc=david.m.ertman@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=driver-core@lists.linux.dev \
    --cc=gregkh@linuxfoundation.org \
    --cc=ira.weiny@intel.com \
    --cc=konradybcio@kernel.org \
    --cc=leon@kernel.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pwm@vger.kernel.org \
    --cc=lossin@kernel.org \
    --cc=m.wilczynski@samsung.com \
    --cc=mmaurer@google.com \
    --cc=ojeda@kernel.org \
    --cc=rafael@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=satyap@quicinc.com \
    --cc=simona@ffwll.ch \
    --cc=tmgross@umich.edu \
    --cc=tsoni@quicinc.com \
    /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