Right now, only when we failed cpufreq driver registration with -ENODEV, we get
the chance to try the fallback option.
There are two code path erroring out other than -ENODEV in cpufreq driver
registration: one is when the driver itself is broken, like missing mandatory
hooks, cpufreq_register_driver() will fail with -EINVAL, in which we shall
be able to try the fallback option, and the other is -EBUSY due to repeated
registration, in which we shall just exit the loop.
So in conclusion, when error code is -EBUSY or successful return, both
indicating a proper driver is already registered, we shall bail the loop,
other than that, we shall continue to try the fallback option.
Signed-off-by: Penny Zheng <penny.zh...@amd.com>
---
v5 -> v6:
- new commit
---
xen/arch/x86/acpi/cpufreq/cpufreq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/x86/acpi/cpufreq/cpufreq.c
b/xen/arch/x86/acpi/cpufreq/cpufreq.c
index 61e98b67bd..45f301f354 100644
--- a/xen/arch/x86/acpi/cpufreq/cpufreq.c
+++ b/xen/arch/x86/acpi/cpufreq/cpufreq.c
@@ -150,7 +150,7 @@ static int __init cf_check cpufreq_driver_init(void)
break;
}
- if ( ret != -ENODEV )
+ if ( !ret || ret == -EBUSY )
break;
}
break;
--
2.34.1
