[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.11.1506182304510.4107@nanos>
Date: Thu, 18 Jun 2015 23:12:49 +0200 (CEST)
From: Thomas Gleixner <tglx@...utronix.de>
To: Andi Kleen <andi@...stfloor.org>
cc: peterz@...radead.org, linux-kernel@...r.kernel.org,
Andi Kleen <ak@...ux.intel.com>
Subject: Re: [PATCH 3/3] x86, perf, uncore: Don't make MSR uncore depend on
PCI uncore
On Thu, 18 Jun 2015, Andi Kleen wrote:
> static int __init intel_uncore_init(void)
> {
> - int ret;
> + int ret1, ret2;
>
> if (boot_cpu_data.x86_vendor != X86_VENDOR_INTEL)
> return -ENODEV;
> @@ -1295,19 +1297,12 @@ static int __init intel_uncore_init(void)
> if (cpu_has_hypervisor)
> return -ENODEV;
>
> - ret = uncore_pci_init();
> - if (ret)
> - goto fail;
> - ret = uncore_cpu_init();
> - if (ret) {
> - uncore_pci_exit();
> - goto fail;
> + ret1 = uncore_pci_init();
> + ret2 = uncore_cpu_init();
> + if (!ret1 || !ret2) {
> + uncore_cpumask_init();
> + uncore_pmus_register();
> }
> - uncore_cpumask_init();
> -
> - uncore_pmus_register();
> return 0;
So now we return success, if nothing is there or stuff failed?
One possible solution is to split the initcall and have one
for uncore_pci and one for uncode_msr, but that does not work well if
you want to make it a module.
But we should at least have some indication, what worked and what went
wrong instead of unconditionally returning success.
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists