On Tue, Apr 28, 2015 at 5:25 PM, Rafael J. Wysocki <rjw@xxxxxxxxxxxxx> wrote:
> On Tuesday, April 28, 2015 02:24:12 PM Dan Williams wrote:
>> Changes since v1 [1]: Incorporates feedback received prior to April 24.
>>
>> 1/ Ingo said [2]:
>>
>> "So why on earth is this whole concept and the naming itself
>> ('drivers/block/nd/' stands for 'NFIT Defined', apparently)
>> revolving around a specific 'firmware' mindset and revolving
>> around specific, weirdly named, overly complicated looking
>> firmware interfaces that come with their own new weird
>> glossary??"
>>
>> Indeed, we of course consulted the NFIT specification to determine
>> the shape of the sub-system, but then let its terms and data
>> structures permeate too deep into the implementation. That is fixed
>> now with all NFIT specifics factored out into acpi.c. The NFIT is no
>> longer required reading to review libnd. Only three concepts are
>> needed:
>>
>> i/ PMEM - contiguous memory range where cpu stores are
>> persistent once they are flushed through the memory
>> controller.
>>
>> ii/ BLK - mmio apertures (sliding windows) that can be
>> programmed to access an aperture's-worth of persistent
>> media at a time.
>>
>> iii/ DPA - "dimm-physical-address", address space local to a
>> dimm. A dimm may provide both PMEM-mode and BLK-mode
>> access to a range of DPA. libnd manages allocation of DPA
>> to either PMEM or BLK-namespaces to resolve this aliasing.
>>
>> The v1..v2 diffstat below shows the migration of nfit-specifics to
>> acpi.c and the new state of libnd being nfit-free. "nd" now only
>> refers to "non-volatile devices". Note, reworked documentation will
>> return once the review has settled.
>>
>> Documentation/blockdev/nd.txt | 867 ---------------------
>> MAINTAINERS | 34 +-
>> arch/ia64/kernel/efi.c | 5 +-
>> arch/x86/kernel/e820.c | 11 +-
>> arch/x86/kernel/pmem.c | 2 +-
>> drivers/block/Makefile | 2 +-
>> drivers/block/nd/Kconfig | 135 ++--
>> drivers/block/nd/Makefile | 32 +-
>> drivers/block/nd/acpi.c | 1506 +++++++++++++++++++++++++++++++------
>> drivers/block/nd/acpi_nfit.h | 321 ++++++++
>> drivers/block/nd/blk.c | 27 +-
>> drivers/block/nd/btt.c | 6 +-
>> drivers/block/nd/btt_devs.c | 8 +-
>> drivers/block/nd/bus.c | 337 +++++----
>> drivers/block/nd/core.c | 574 +-------------
>> drivers/block/nd/dimm.c | 11 -
>> drivers/block/nd/dimm_devs.c | 292 ++-----
>> drivers/block/nd/e820.c | 100 +++
>> drivers/block/nd/libnd.h | 122 +++
>> drivers/block/nd/namespace_devs.c | 10 +-
>> drivers/block/nd/nd-private.h | 107 +--
>> drivers/block/nd/nd.h | 91 +--
>> drivers/block/nd/nfit.h | 238 ------
>> drivers/block/nd/pmem.c | 56 +-
>> drivers/block/nd/region.c | 78 +-
>> drivers/block/nd/region_devs.c | 783 +++----------------
>> drivers/block/nd/test/iomap.c | 86 +--
>> drivers/block/nd/test/nfit.c | 1115 +++++++++++++++------------
>> drivers/block/nd/test/nfit_test.h | 15 +-
>> include/uapi/linux/ndctl.h | 130 ++--
>> 30 files changed, 3166 insertions(+), 3935 deletions(-)
>> delete mode 100644 Documentation/blockdev/nd.txt
>> create mode 100644 drivers/block/nd/acpi_nfit.h
>> create mode 100644 drivers/block/nd/e820.c
>> create mode 100644 drivers/block/nd/libnd.h
>> delete mode 100644 drivers/block/nd/nfit.h
>>
>> [1]: https://lists.01.org/pipermail/linux-nvdimm/2015-April/000484.html
>> [2]: https://lists.01.org/pipermail/linux-nvdimm/2015-April/000520.html
>>
>> 2/ Christoph asked the pmem ida conversion to be moved to its own patch
>> (done), and to consider leaving the current pmem.c in drivers/block/.
>> Instead, I converted the e820-type-12 enabling to be the first
>> non-ACPI-NFIT based consumer of libnd. The new nd_e820 driver simply
>> registers e820-type-12 ranges as libnd PMEM regions. Among other
>> things this conversion enables BTT for these ranges. The alternative
>> is to move drivers/block/nd/nd.h internals out to include/linux/
>> which I think is worse.
>>
>> 3/ Toshi reported that the NFIT parsing fails to handle the case of a
>> PMEM range with a single-dimm (non-aliasing) interleave description.
>> Support for this case was added and is tested by default by the
>> nfit_test.1 configuration.
>>
>> 4/ Toshi reported that we should not be treating a missing _STA property
>> as a "dimm disabled by firmware" case. (fixed).
>>
>> 5/ Christoph noted that ND_ARCH_HAS_IOREMAP_CACHE needs to be moved to
>> arch code. It is gone for now and we'll revisit when adding cached
>> mappings back to the PMEM driver.
>>
>> 6/ Toshi mentioned that the presence of two different nd_bus_probe()
>> functions was confusing. (cleaned up).
>>
>> 7/ Robert asked for s/btt_checksum/nd_btt_checksum/ (done).
>>
>> 8/ Linda asked for nfit_test to honor dynamic cma reservations via the
>> cma= command line (done). The cma requirements have also been
>> reduced to 128M as only the simulated DAX regions need CMA. The rest
>> can use vmalloc().
>>
>> ---
>>
>> Available here:
>> git://git.kernel.org/pub/scm/linux/kernel/git/djbw/nvdimm nd-v2
>>
>> ---
>>
>> Dan Williams (18):
>> e820, efi: add ACPI 6.0 persistent memory types
>> libnd, nd_acpi: initial libnd infrastructure and NFIT support
>> nd_acpi, nfit-test: manufactured NFITs for interface development
>> libnd: ndctl class device, and nd bus attributes
>> libnd, nd_acpi: dimm/memory-devices
>> libnd: ndctl.h, the nd ioctl abi
>> libnd, nd_dimm: dimm driver and base libnd device-driver infrastructure
>> libnd, nd_acpi: regions (block-data-window, persistent memory, volatile memory)
>> libnd: support for legacy (non-aliasing) nvdimms
>> pmem: use ida
>> libnd, nd_pmem: add libnd support to the pmem driver
>> libnd, nd_acpi: add interleave-set state-tracking infrastructure
>> libnd: namespace indices: read and validate
>> libnd: pmem label sets and namespace instantiation.
>> libnd: blk labels and namespace instantiation
>> libnd: write pmem label set
>> libnd: write blk label set
>> libnd: infrastructure for btt devices
>>
>> Ross Zwisler (1):
>> libnd, nd_acpi, nd_blk: driver for BLK-mode access persistent memory
>>
>> Vishal Verma (1):
>> nd_btt: atomic sector updates
>
> I'm wondering what's wrong with CCing all of the series to linux-acpi?
>
> Is there anything in it that the people on that list should not see, by any
> chance?
linux-acpi may not care about the dimm-metadata labeling patches that
are completely independent of ACPI, but might as well include
linux-acpi on the whole series at this point.
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
