[PATCH v5 5/6] rust: cpufreq: Remove unnecessary `of` dependency in cpufreq example

Igor Korotin posted 6 patches 4 months ago
There is a newer version of this series
[PATCH v5 5/6] rust: cpufreq: Remove unnecessary `of` dependency in cpufreq example
Posted by Igor Korotin 4 months ago
Drop the explicit `use of` and `OF_ID_TABLE = None` assignment in the
cpufreq driver registration example.

Since `Adapter::OF_ID_TABLE` now defaults to `None`, drivers that do
not require OpenFirmware matching no longer need to import `of` or
define the constant explicitly.

Signed-off-by: Igor Korotin <igor.korotin.linux@gmail.com>
---
 rust/kernel/cpufreq.rs | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/rust/kernel/cpufreq.rs b/rust/kernel/cpufreq.rs
index b0a9c6182aec..789c4a8936ab 100644
--- a/rust/kernel/cpufreq.rs
+++ b/rust/kernel/cpufreq.rs
@@ -842,7 +842,7 @@ fn register_em(_policy: &mut Policy) {
 ///     c_str,
 ///     device::{Core, Device},
 ///     macros::vtable,
-///     of, platform,
+///     platform,
 ///     sync::Arc,
 /// };
 /// struct SampleDevice;
@@ -887,7 +887,6 @@ fn register_em(_policy: &mut Policy) {
 ///
 /// impl platform::Driver for SampleDriver {
 ///     type IdInfo = ();
-///     const OF_ID_TABLE: Option<of::IdTable<Self::IdInfo>> = None;
 ///
 ///     fn probe(
 ///         pdev: &platform::Device<Core>,
-- 
2.43.0
Re: [PATCH v5 5/6] rust: cpufreq: Remove unnecessary `of` dependency in cpufreq example
Posted by Danilo Krummrich 4 months ago
On Wed, Jun 11, 2025 at 06:53:53PM +0100, Igor Korotin wrote:
> Drop the explicit `use of` and `OF_ID_TABLE = None` assignment in the
> cpufreq driver registration example.
> 
> Since `Adapter::OF_ID_TABLE` now defaults to `None`, drivers that do
> not require OpenFirmware matching no longer need to import `of` or
> define the constant explicitly.

This is slightly outside of the scope of this patch series and given that it
doesn't add immediate value it's usually better to wait with such patches until
the prerequisite is in Linus' tree.

However, if Viresh is fine with the patch and with taking it through the
driver-core tree and does not expect any conflicts, I'm fine picking it up.