[GIT,PULL] libnvdimm for v5.8-rc2
mbox series

Message ID CAPcyv4jA-_Wd4S6gM2jf_VhVsgsdR5rQTeAc3AEPr6SAvhq3eA@mail.gmail.com
State Accepted
Commit eede2b9b3fe01168940bb42ff3ab502ef5f6375c
Headers show
Series
  • [GIT,PULL] libnvdimm for v5.8-rc2
Related show

Pull-request

git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm tags/libnvdimm-for-5.8-rc2

Message

Dan Williams June 19, 2020, 10:07 p.m. UTC
Hi Linus, please pull from:

  git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm
tags/libnvdimm-for-5.8-rc2

...to receive a feature (papr_scm health retrieval) and a fix (sysfs
attribute visibility) for v5.8.

Vaibhav explains in the merge commit below why missing v5.8 would be
painful and I agreed to try a -rc2 pull because only cosmetics kept
this out of -rc1 and his initial versions were posted in more than
enough time for v5.8 consideration.

===
    These patches are tied to specific features that were committed to
    customers in upcoming distros releases (RHEL and SLES) whose time-lines
    are tied to 5.8 kernel release.

    Being able to track the health of an nvdimm is critical for our
    customers that are running workloads leveraging papr-scm nvdimms.
    Missing the 5.8 kernel would mean missing the distro timelines and
    shifting forward the availability of this feature in distro kernels by
    at least 6 months.
===

I notice that these do not have an ack from Michael, but I had been
assuming that he was deferring this to a libnvdimm subsystem decision
ever since v7 back at the end of May where he said "I don't have
strong opinions about the user API, it's really up to the nvdimm
folks." [1]

This pull request includes v13 of papr_scm set, and it looks good to me.

Please consider pulling, I would not normally have broached asking for
this exception, but Vaibhav made sure to have less than 24 hour turn
around on all final review comments.

This has been in -next all week with no reported issues.

[1]: http://lore.kernel.org/r/875zcigafk.fsf@mpe.ellerman.id.au

---

The following changes since commit b3a9e3b9622ae10064826dccb4f7a52bd88c7407:

  Linux 5.8-rc1 (2020-06-14 12:45:04 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm
tags/libnvdimm-for-5.8-rc2

for you to fetch changes up to 9df24eaef86f5d5cb38c77eaa1cfa3eec09ebfe8:

  Merge branch 'for-5.8/papr_scm' into libnvdimm-for-next (2020-06-19
14:18:51 -0700)

----------------------------------------------------------------
libnvdimm for 5.8-rc2

- Fix the visibility of the region 'align' attribute. The new unit tests
  for region alignment handling caught a corner case where the alignment
  cannot be specified if the region is converted from static to dynamic
  provisioning at runtime.

- Add support for device health retrieval for the persistent memory
  supported by the papr_scm driver. This includes both the standard
  sysfs "health flags" that the nfit persistent memory driver publishes
  and a mechanism for the ndctl tool to retrieve a health-command payload.

----------------------------------------------------------------
Dan Williams (1):
      Merge branch 'for-5.8/papr_scm' into libnvdimm-for-next

Vaibhav Jain (6):
      powerpc: Document details on H_SCM_HEALTH hcall
      seq_buf: Export seq_buf_printf
      powerpc/papr_scm: Fetch nvdimm health information from PHYP
      powerpc/papr_scm: Improve error logging and handling papr_scm_ndctl()
      ndctl/papr_scm,uapi: Add support for PAPR nvdimm specific methods
      powerpc/papr_scm: Implement support for PAPR_PDSM_HEALTH

Vishal Verma (1):
      nvdimm/region: always show the 'align' attribute

 Documentation/ABI/testing/sysfs-bus-papr-pmem |  27 ++
 Documentation/powerpc/papr_hcalls.rst         |  46 ++-
 arch/powerpc/include/uapi/asm/papr_pdsm.h     | 132 ++++++++
 arch/powerpc/platforms/pseries/papr_scm.c     | 420 +++++++++++++++++++++++++-
 drivers/nvdimm/region_devs.c                  |  14 +-
 include/uapi/linux/ndctl.h                    |   1 +
 lib/seq_buf.c                                 |   1 +
 7 files changed, 618 insertions(+), 23 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-bus-papr-pmem
 create mode 100644 arch/powerpc/include/uapi/asm/papr_pdsm.h

Comments

Linus Torvalds June 20, 2020, 8:16 p.m. UTC | #1
On Fri, Jun 19, 2020 at 3:07 PM Dan Williams <dan.j.williams@intel.com> wrote:
>
>     These patches are tied to specific features that were committed to
>     customers in upcoming distros releases (RHEL and SLES) whose time-lines
>     are tied to 5.8 kernel release.

Ugh. I'd have much preferred to see this during the merge window, but
the code looks straightforward and harmless enough.

            Linus
pr-tracker-bot@kernel.org June 20, 2020, 8:25 p.m. UTC | #2
The pull request you sent on Fri, 19 Jun 2020 15:07:04 -0700:

> git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm tags/libnvdimm-for-5.8-rc2

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/eede2b9b3fe01168940bb42ff3ab502ef5f6375c

Thank you!
Michael Ellerman June 22, 2020, 2:39 a.m. UTC | #3
Dan Williams <dan.j.williams@intel.com> writes:
> Hi Linus, please pull from:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm
> tags/libnvdimm-for-5.8-rc2
>
> ...to receive a feature (papr_scm health retrieval) and a fix (sysfs
> attribute visibility) for v5.8.
>
> Vaibhav explains in the merge commit below why missing v5.8 would be
> painful and I agreed to try a -rc2 pull because only cosmetics kept
> this out of -rc1 and his initial versions were posted in more than
> enough time for v5.8 consideration.
>
> ===
>     These patches are tied to specific features that were committed to
>     customers in upcoming distros releases (RHEL and SLES) whose time-lines
>     are tied to 5.8 kernel release.
>
>     Being able to track the health of an nvdimm is critical for our
>     customers that are running workloads leveraging papr-scm nvdimms.
>     Missing the 5.8 kernel would mean missing the distro timelines and
>     shifting forward the availability of this feature in distro kernels by
>     at least 6 months.
> ===
>
> I notice that these do not have an ack from Michael, but I had been
> assuming that he was deferring this to a libnvdimm subsystem decision
> ever since v7 back at the end of May where he said "I don't have
> strong opinions about the user API, it's really up to the nvdimm
> folks." [1]

Yeah, sorry for not providing an actual ack, I didn't realise you were
planning to send it for 5.8.

The arch parts of that series are pretty boring plumbing of hypervisor
calls, so the important details were all the libnvdimm related issues
IMO.

So please consider this a belated ack and thanks for getting it merged.

cheers