linux-kernel - Re: [PATCH V4 8/8] cpufreq: Add Rust based cpufreq-dt driver

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: <2024071106-handed-oversleep-2377@gregkh>
Date: Thu, 11 Jul 2024 19:21:59 +0200
From: Greg KH <greg@...ah.com>
To: Danilo Krummrich <dakr@...hat.com>
Cc: Viresh Kumar <viresh.kumar@...aro.org>,
	"Rafael J. Wysocki" <rafael@...nel.org>,
	Miguel Ojeda <miguel.ojeda.sandonis@...il.com>,
	Miguel Ojeda <ojeda@...nel.org>,
	Alex Gaynor <alex.gaynor@...il.com>,
	Wedson Almeida Filho <wedsonaf@...il.com>,
	Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>,
	Björn Roy Baron <bjorn3_gh@...tonmail.com>,
	Benno Lossin <benno.lossin@...ton.me>,
	Andreas Hindborg <a.hindborg@...sung.com>,
	Alice Ryhl <aliceryhl@...gle.com>, linux-pm@...r.kernel.org,
	Vincent Guittot <vincent.guittot@...aro.org>,
	Stephen Boyd <sboyd@...nel.org>, Nishanth Menon <nm@...com>,
	rust-for-linux@...r.kernel.org,
	Manos Pitsidianakis <manos.pitsidianakis@...aro.org>,
	Erik Schilling <erik.schilling@...aro.org>,
	Alex Bennée <alex.bennee@...aro.org>,
	Joakim Bech <joakim.bech@...aro.org>, Rob Herring <robh@...nel.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH V4 8/8] cpufreq: Add Rust based cpufreq-dt driver

On Thu, Jul 11, 2024 at 06:41:29PM +0200, Greg KH wrote:
> On Thu, Jul 11, 2024 at 06:34:22PM +0200, Greg KH wrote:
> > On Thu, Jul 11, 2024 at 06:12:08PM +0200, Danilo Krummrich wrote:
> > > 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
> > 
> > Yes, these are abuses of that and should be virtual devices as they have
> > nothing to do with the platform bus.
> > 
> > > > > 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.
> > 
> > Great, use the default one that the kernel gives you :)
> > 
> > > For instance, in DRM we have vGEM [3] and vKMS [4], that use
> > > platform_device_register_simple() for this purpose.
> > 
> > Again, abuse, please do not do so.
> > 
> > > 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
> > 
> > Use the virtual device interface please, that's what it is there for.
> 
> To be specific, look at the devices in /sys/devices/virtual/ that's
> where yours should be showing up in, not in the root of /sys/devices/
> like they are by creating a "fake" platform device at the root of the
> device tree.

Ok, at first glance this seems a little bit more complex than what the
platform api gives you, let me knock something up next week during the
merge window to make this more simple and then let some interns at it to
sweep the kernel tree and fix up this proliferation of platform device
abuse.

thanks,

greg k-h