[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC PATCH v2 09/12] xen: arm: implement platform hypercall
>>> On 22.10.14 at 10:40, <oleksandr.dmytryshyn@xxxxxxxxxxxxxxx> wrote: > On Fri, Oct 17, 2014 at 3:44 PM, Jan Beulich <JBeulich@xxxxxxxx> wrote: >>>>> On 16.10.14 at 13:27, <oleksandr.dmytryshyn@xxxxxxxxxxxxxxx> wrote: >>> +long arch_do_platform_op(struct xen_platform_op *platform_op, >>> + XEN_GUEST_HANDLE_PARAM(xen_platform_op_t) > u_xenpf_op) >>> +{ >>> + long ret = 0; >>> + struct xen_platform_op *op = platform_op; >>> + >>> + switch ( op->cmd ) >>> + { >>> + case XENPF_set_processor_pminfo: >>> + switch ( op->u.set_pminfo.type ) >>> + { >>> + case XEN_PM_PX: >>> + if ( !(xen_processor_pmbits & XEN_PROCESSOR_PM_PX) ) >>> + { >>> + ret = -ENOSYS; >>> + break; >>> + } >>> +#ifdef HAS_CPUFREQ >>> + ret = set_px_pminfo(op->u.set_pminfo.id, > &op->u.set_pminfo.u.perf); >> >> This cannot possibly be HAS_CPUFREQ, since ->u.set_pminfo >> specifically uses ACPI notation for e.g. the CPU numbering. And >> with that it becomes questionable whether the whole series is >> doing right in abstracting away ACPI. > set_px_pminfo() function is implemented in the cpufreq.c file and this file > will be compiled only if HAS_CPUFREQ is defined. Thus I've used HAS_CPUFREQ > in > this case. If HAS_CPUFREQ is not defined then set_px_pminfo() will not be > compiled and there will be errors on compilation without this definition. > ->u.set_pminfo uses ACPI notation for the CPU numbering but > patch "cpufreq: make cpufreq driver more generalizable" skips ACPI > notation for the CPU numbering if CONFIG_ACPI is not defined. This all looks very kludgy and hence is likely going to become a maintenance nightmare. Please separate things properly that are separate by design. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |