Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752912AbbK3G05 (ORCPT ); Mon, 30 Nov 2015 01:26:57 -0500 Received: from mail-oi0-f52.google.com ([209.85.218.52]:35740 "EHLO mail-oi0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750917AbbK3G0y (ORCPT ); Mon, 30 Nov 2015 01:26:54 -0500 MIME-Version: 1.0 From: Andy Lutomirski Date: Sun, 29 Nov 2015 22:26:34 -0800 Message-ID: Subject: Cleaning up e820_pmem? To: Christoph Hellwig , Dan Williams , linux-nvdimm , "linux-kernel@vger.kernel.org" , X86 ML Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1161 Lines: 23 My laptop has /sys/devices/platform/e820_pmem and autoloads all the nvdimm infrastructure. While it would be really cool if my laptop had pmem, that's a bit of a pipe dream right now. (Even if it did have it, this laptop is brand new -- it should use NFIT, not e820_pmem.) Could we move the iomem_resource loop from drivers/nvdimm/e820.c to arch/x86/kernel/pmem.c and actually list the iomem resources the standard way as resources belonging to the platform device? That would match accepted practice, and it would keep the grossly x86-specific part of the driver in arch/x86. Then we could further tweak it to skip creating the platform device at all if there are no resources, and we'd avoid needlessly loading the module. I'd do this myself, except that my lovely machine that *does* support e820 pmem has been repurposed, so testing on a machine that actually supports this turd is awkward for me. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/