All of lore.kernel.org
 help / color / mirror / Atom feed
From: Danilo Krummrich <dakr@redhat.com>
To: Greg KH <greg@kroah.com>
Cc: "Viresh Kumar" <viresh.kumar@linaro.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	"Miguel Ojeda" <miguel.ojeda.sandonis@gmail.com>,
	"Miguel Ojeda" <ojeda@kernel.org>,
	"Alex Gaynor" <alex.gaynor@gmail.com>,
	"Wedson Almeida Filho" <wedsonaf@gmail.com>,
	"Boqun Feng" <boqun.feng@gmail.com>,
	"Gary Guo" <gary@garyguo.net>,
	"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
	"Benno Lossin" <benno.lossin@proton.me>,
	"Andreas Hindborg" <a.hindborg@samsung.com>,
	"Alice Ryhl" <aliceryhl@google.com>,
	linux-pm@vger.kernel.org,
	"Vincent Guittot" <vincent.guittot@linaro.org>,
	"Stephen Boyd" <sboyd@kernel.org>, "Nishanth Menon" <nm@ti.com>,
	rust-for-linux@vger.kernel.org,
	"Manos Pitsidianakis" <manos.pitsidianakis@linaro.org>,
	"Erik Schilling" <erik.schilling@linaro.org>,
	"Alex Bennée" <alex.bennee@linaro.org>,
	"Joakim Bech" <joakim.bech@linaro.org>,
	"Rob Herring" <robh@kernel.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH V4 8/8] cpufreq: Add Rust based cpufreq-dt driver
Date: Thu, 11 Jul 2024 18:12:08 +0200	[thread overview]
Message-ID: <ZpAEWAzETnrVI-cs@pollux> (raw)
In-Reply-To: <2024071122-escargot-treadmill-6e9a@gregkh>

On Thu, Jul 11, 2024 at 04:37:50PM +0200, Greg KH wrote:
> On Thu, Jul 11, 2024 at 03:21:31PM +0200, Danilo Krummrich wrote:
> > (2) You require drivers to always implement a "dummy" struct platform_device,
> > there is platform_device_register_simple() for that purpose.
> 
> No, NEVER do that.  platform devices are only for real platform devices,
> do not abuse that interface any more than it already is.

I thought we're talking about cases like [1] or [2], but please correct me if
those are considered abusing the platform bus as well.

(Those drivers read the CPU OF nodes, instead of OF nodes that represent a
separate device.)

[1] https://elixir.bootlin.com/linux/latest/source/drivers/cpuidle/cpuidle-riscv-sbi.c#L586
[2] https://elixir.bootlin.com/linux/latest/source/drivers/cpuidle/cpuidle-psci.c#L441

> 
> > I think (2) is the preferred option.
> 
> No, not at all, sorry.
> 
> Use a real device, you have one somewhere that relates to this hardware,
> otherwise you aren't controlling anything and then you can use a virtual
> device.

Of course we should stick to a real device if there is one, I didn't meant to
say anything else.

But since it came up now, some virtual drivers still require a parent device.

For instance, in DRM we have vGEM [3] and vKMS [4], that use
platform_device_register_simple() for this purpose.

What should they use instead? I'm happy to fix things up if required.

[3] https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/vgem/vgem_drv.c
[4] https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/vkms/vkms_drv.c

> 
> Again, do NOT abuse the platform subsystem.  It's one reason I am loath
> to even want to allow rust bindings to it.

How is that related to Rust?

> 
> greg k-h
> 


  reply	other threads:[~2024-07-11 16:12 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-11  6:57 [PATCH V4 0/8] Rust bindings for cpufreq and OPP core + sample driver Viresh Kumar
2024-07-11  6:57 ` [PATCH V4 1/8] rust: Add initial bindings for OPP framework Viresh Kumar
2024-07-11  6:57 ` [PATCH V4 2/8] rust: Extend OPP bindings for the OPP table Viresh Kumar
2024-07-11  6:57 ` [PATCH V4 3/8] rust: Extend OPP bindings for the configuration options Viresh Kumar
2024-07-11  6:57 ` [PATCH V4 4/8] rust: Add initial bindings for cpufreq framework Viresh Kumar
2024-07-11  6:57 ` [PATCH V4 5/8] rust: Extend cpufreq bindings for policy and driver ops Viresh Kumar
2024-07-11  6:57 ` [PATCH V4 6/8] rust: Extend cpufreq bindings for driver registration Viresh Kumar
2024-07-11  6:57 ` [PATCH V4 7/8] rust: Extend OPP bindings with CPU frequency table Viresh Kumar
2024-07-11  6:57 ` [PATCH V4 8/8] cpufreq: Add Rust based cpufreq-dt driver Viresh Kumar
2024-07-11 10:43   ` Danilo Krummrich
2024-07-11 13:08     ` Viresh Kumar
2024-07-11 13:21       ` Danilo Krummrich
2024-07-11 14:37         ` Greg KH
2024-07-11 16:12           ` Danilo Krummrich [this message]
2024-07-11 16:34             ` Greg KH
2024-07-11 16:41               ` Greg KH
2024-07-11 17:21                 ` Greg KH
2024-07-11 17:42                   ` Danilo Krummrich
2024-07-16 15:15               ` Danilo Krummrich
2024-07-16 15:22                 ` Greg KH
2024-07-16 15:53                   ` Rob Herring
2024-07-16 22:33                     ` Danilo Krummrich

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=ZpAEWAzETnrVI-cs@pollux \
    --to=dakr@redhat.com \
    --cc=a.hindborg@samsung.com \
    --cc=alex.bennee@linaro.org \
    --cc=alex.gaynor@gmail.com \
    --cc=aliceryhl@google.com \
    --cc=benno.lossin@proton.me \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun.feng@gmail.com \
    --cc=erik.schilling@linaro.org \
    --cc=gary@garyguo.net \
    --cc=greg@kroah.com \
    --cc=joakim.bech@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=manos.pitsidianakis@linaro.org \
    --cc=miguel.ojeda.sandonis@gmail.com \
    --cc=nm@ti.com \
    --cc=ojeda@kernel.org \
    --cc=rafael@kernel.org \
    --cc=robh@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=sboyd@kernel.org \
    --cc=vincent.guittot@linaro.org \
    --cc=viresh.kumar@linaro.org \
    --cc=wedsonaf@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.