linux-kernel - Cleaning up e820

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 29 Nov 2015 22:26:34 -0800
From:	Andy Lutomirski <luto@...capital.net>
To:	Christoph Hellwig <hch@...radead.org>,
	Dan Williams <dan.j.williams@...el.com>,
	linux-nvdimm <linux-nvdimm@...ts.01.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	X86 ML <x86@...nel.org>
Subject: Cleaning up e820_pmem?

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/