linux-kernel - Re: [GIT PULL v4 00/21] libnd: non-volatile memory device support

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 for Android: free password hash cracker in your pocket

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

Message-ID: <CAJZ5v0h2RpkFRHbGxGRbVXCeySkSZLm71YG16ToiaXg_XgacDQ@mail.gmail.com>
Date:	Thu, 28 May 2015 00:36:11 +0200
From:	"Rafael J. Wysocki" <rafael@...nel.org>
To:	Dan Williams <dan.j.williams@...el.com>
Cc:	axboe@...nel.dk, Boaz Harrosh <boaz@...xistor.com>,
	Neil Brown <neilb@...e.de>, Dave Chinner <david@...morbit.com>,
	Lv Zheng <lv.zheng@...el.com>,
	"H. Peter Anvin" <hpa@...or.com>, hch@....de, sfr@...b.auug.org.au,
	linux-nvdimm@...ts.01.org,
	"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
	Robert Moore <robert.moore@...el.com>,
	Ingo Molnar <mingo@...nel.org>,
	ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
	jmoyer@...hat.com,
	Nicholas Moulin <nicholas.w.moulin@...ux.intel.com>,
	Matthew Wilcox <willy@...ux.intel.com>,
	Ross Zwisler <ross.zwisler@...ux.intel.com>,
	Vishal Verma <vishal.l.verma@...ux.intel.com>,
	Jens Axboe <axboe@...com>, Borislav Petkov <bp@...en8.de>,
	Thomas Gleixner <tglx@...utronix.de>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Andy Lutomirski <luto@...capital.net>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [GIT PULL v4 00/21] libnd: non-volatile memory device support

Hi,

On Thu, May 28, 2015 at 12:24 AM, Dan Williams <dan.j.williams@...el.com> wrote:
> Jens, please pull from...
>
>    git://git.kernel.org/pub/scm/linux/kernel/git/djbw/nvdimm tags/libnd-for-jens
>
> ...to receive the libnd sub-system for the next merge window.  This has
> been through 3 rounds of review.  Incremental diffstats and links to
> previous postings:
>
> v1: 39 files changed, 13102 insertions(+), 36 deletions(-)
>     https://lists.01.org/pipermail/linux-nvdimm/2015-April/000484.html
>
> v2: 30 files changed, 3166 insertions(+), 3935 deletions(-)
>     https://lists.01.org/pipermail/linux-nvdimm/2015-April/000574.html
>
> v3: 33 files changed, 2202 insertions(+), 1233 deletions(-)
>     https://lists.01.org/pipermail/linux-nvdimm/2015-May/000804.html
>
> v4: Full diffstat since v3
>
>     Documentation/blockdev/libnd.txt  |   2 +-
>     arch/x86/Kconfig                  |   4 ++
>     arch/x86/kernel/pmem.c            |  92 +++++++++++++++++++++++------------
>     drivers/acpi/nfit.c               |  20 ++++----
>     drivers/acpi/nfit.h               |   4 +-
>     drivers/block/Kconfig             |   8 ---
>     drivers/block/Makefile            |   1 -
>     drivers/block/e820_pmem.c         | 100 --------------------------------------
>     drivers/block/nd/Kconfig          |  10 ++++
>     drivers/block/nd/btt.h            |   2 +-
>     drivers/block/nd/namespace_devs.c |   5 +-
>     drivers/block/nd/pmem.c           |   2 +-
>     drivers/block/nd/test/nfit.c      |  10 ++--
>     include/acpi/acuuid.h             |  16 +++---
>     14 files changed, 105 insertions(+), 171 deletions(-)
>     delete mode 100644 drivers/block/e820_pmem.c
>
>     1/ Kill drivers/block/e820_pmem.c, we can just register pmem
>        regions directly from arch/x86/kernel/pmem.c without need for an
>        intermediary driver (Christoph).
>
>     2/ Update to latest NFIT UUID definitions (Toshi).  This
>        merges cleanly with, and is identical to the include/acpi/
>        NFIT enabling in Rafael's linux-pm.git/bleeding-edge branch.

Well, I didn't expect you to send a pull request for this right away
to be honest.

Can you please pull from my acpica branch and rebase your patches on
top of that by any chance?

And no, the "merges cleanly" part isn't sufficient as it'll create a
mess of a history if merged together like that.  Can we do that
properly instead?

Thanks,
Rafael
--
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/