[GIT PULL] LIBNVDIMM update for v5.18

2022-03-29 Thread Dan Williams
support for nvdimm events, initially only for 'papr_scm' devices. - Deprecate the 'block aperture' support in libnvdimm, it only ever existed in the specification, not in shipping product. Dan Williams (6): nvdimm/region

Re: [PATCH 2/2] powerpc/papr_scm: Fix build failure when CONFIG_PERF_EVENTS is not set

2022-03-23 Thread Dan Williams
On Wed, Mar 23, 2022 at 3:05 AM Michael Ellerman wrote: > > Dan Williams writes: > > On Tue, Mar 22, 2022 at 7:30 AM kajoljain wrote: > >> On 3/22/22 03:09, Dan Williams wrote: > >> > On Fri, Mar 18, 2022 at 4:42 AM Kajol Jain wrote: > >> >>

Re: [PATCH 2/2] powerpc/papr_scm: Fix build failure when CONFIG_PERF_EVENTS is not set

2022-03-22 Thread Dan Williams
On Tue, Mar 22, 2022 at 7:30 AM kajoljain wrote: > > > > On 3/22/22 03:09, Dan Williams wrote: > > On Fri, Mar 18, 2022 at 4:42 AM Kajol Jain wrote: > >> > >> The following build failure occures when CONFIG_PERF_EVENTS is not set > >> as generic p

Re: [PATCH 1/2] drivers/nvdimm: Fix build failure when CONFIG_PERF_EVENTS is not set

2022-03-21 Thread Dan Williams
On Fri, Mar 18, 2022 at 4:42 AM Kajol Jain wrote: > > The following build failure occures when CONFIG_PERF_EVENTS is not set > as generic pmu functions are not visible in that scenario. > > |-- s390-randconfig-r044-20220313 > | |--

Re: [PATCH 2/2] powerpc/papr_scm: Fix build failure when CONFIG_PERF_EVENTS is not set

2022-03-21 Thread Dan Williams
On Mon, Mar 21, 2022 at 2:39 PM Dan Williams wrote: > > On Fri, Mar 18, 2022 at 4:42 AM Kajol Jain wrote: > > > > The following build failure occures when CONFIG_PERF_EVENTS is not set > > as generic pmu functions are not visible in that scenario. > > >

Re: [PATCH 2/2] powerpc/papr_scm: Fix build failure when CONFIG_PERF_EVENTS is not set

2022-03-21 Thread Dan Williams
On Fri, Mar 18, 2022 at 4:42 AM Kajol Jain wrote: > > The following build failure occures when CONFIG_PERF_EVENTS is not set > as generic pmu functions are not visible in that scenario. > > arch/powerpc/platforms/pseries/papr_scm.c:372:35: error: ‘struct perf_event’ > has no member named ‘attr’

Re: linux-next: manual merge of the nvdimm tree with the powerpc tree

2022-03-15 Thread Dan Williams
On Tue, Mar 15, 2022 at 4:21 AM Michael Ellerman wrote: > > Stephen Rothwell writes: > > Hi all, > > > > Today's linux-next merge of the nvdimm tree got a conflict in: > > > > arch/powerpc/platforms/pseries/papr_scm.c > > > > between commit: > > > > bbbca72352bb ("powerpc/papr_scm: Implement

Re: [PATCH v7 0/4] Add perf interface to expose nvdimm

2022-03-09 Thread Dan Williams
On Mon, Mar 7, 2022 at 9:27 PM kajoljain wrote: > > Hi Dan, > Can you take this patch-set if it looks fine to you. > Pushed out to my libnvdimm-pending branch for a 0day confirmation before heading over to linux-next.

Re: [PATCH v6 0/4] Add perf interface to expose nvdimm

2022-02-23 Thread Dan Williams
On Wed, Feb 23, 2022 at 11:07 AM Dan Williams wrote: > > On Fri, Feb 18, 2022 at 10:06 AM Dan Williams > wrote: > > > > On Thu, Feb 17, 2022 at 8:34 AM Kajol Jain wrote: > > > > > > Patchset adds performance stats reporting support for nvdimm. > &g

Re: [PATCH v6 0/4] Add perf interface to expose nvdimm

2022-02-23 Thread Dan Williams
On Fri, Feb 18, 2022 at 10:06 AM Dan Williams wrote: > > On Thu, Feb 17, 2022 at 8:34 AM Kajol Jain wrote: > > > > Patchset adds performance stats reporting support for nvdimm. > > Added interface includes support for pmu register/unregister > > functions. A struct

Re: [PATCH v6 0/4] Add perf interface to expose nvdimm

2022-02-18 Thread Dan Williams
5 -> Resend v5 > - Resend the patchset > > - Link to the patchset v5: https://lkml.org/lkml/2021/9/28/643 > > v4 -> v5: > - Remove multiple variables defined in nvdimm_pmu structure include > name and pmu functions(event_int/add/del/read) as they are just > used

Re: [PATCH 06/13] nvdimm/blk: avoid calling del_gendisk() on early failures

2021-11-02 Thread Dan Williams
On Tue, Nov 2, 2021 at 5:10 PM Luis Chamberlain wrote: > > On Fri, Oct 15, 2021 at 05:13:48PM -0700, Dan Williams wrote: > > On Fri, Oct 15, 2021 at 4:53 PM Luis Chamberlain wrote: > > > > > > If nd_integrity_init() fails we'd get del_gendisk() called, > > &

Re: [PATCH 04/13] nvdimm/btt: use goto error labels on btt_blk_init()

2021-10-31 Thread Dan Williams
hing to unwind. The rest looks good to me. After dropping "goto out;" you can add: Reviewed-by: Dan Williams

Re: [PATCH 03/13] nvdimm/btt: do not call del_gendisk() if not needed

2021-10-31 Thread Dan Williams
rough device_add()." Fixes: 41cd8b70c37a ("libnvdimm, btt: add support for blk integrity") With that you can add: Reviewed-by: Dan Williams

Re: [PATCH 06/13] nvdimm/blk: avoid calling del_gendisk() on early failures

2021-10-15 Thread Dan Williams
On Fri, Oct 15, 2021 at 4:53 PM Luis Chamberlain wrote: > > If nd_integrity_init() fails we'd get del_gendisk() called, > but that's not correct as we should only call that if we're > done with device_add_disk(). Fix this by providing unwinding > prior to the devm call being registered and moving

[PATCH v3 10/10] ocxl: Use pci core's DVSEC functionality

2021-10-09 Thread Dan Williams
. As that change is less trivial it is reserved for later. Cc: linuxppc-dev@lists.ozlabs.org Cc: Andrew Donnellan Acked-by: Frederic Barrat (v1) Signed-off-by: Ben Widawsky Reviewed-by: Andrew Donnellan Signed-off-by: Dan Williams --- arch/powerpc/platforms/powernv/ocxl.c |3 ++- drivers/misc

[PATCH v3 08/10] PCI: Add pci_find_dvsec_capability to find designated VSEC

2021-10-09 Thread Dan Williams
e not tied to the Vendor ID of the PCI component. Where the DVSEC Vendor may be a standards body like CXL. Cc: David E. Box Cc: Jonathan Cameron Cc: Bjorn Helgaas Cc: Dan Williams Cc: linux-...@vger.kernel.org Cc: linuxppc-dev@lists.ozlabs.org Cc: Andrew Donnellan Cc: Lu Baolu Reviewed-by: Frederic Barr

[PATCH v3 00/10] cxl_pci refactor for reusability

2021-10-09 Thread Dan Williams
pci_setup_regs() PCI: Add pci_find_dvsec_capability to find designated VSEC cxl/pci: Use pci core's DVSEC functionality ocxl: Use pci core's DVSEC functionality Dan Williams (2): cxl/pci: Fix NULL vs ERR_PTR confusion cxl/pci: Add @base to cxl_register_map arch/powerpc/pla

Re: [PATCH v2 9/9] iommu/vt-d: Use pci core's DVSEC functionality

2021-09-28 Thread Dan Williams
On Thu, Sep 23, 2021 at 10:27 AM Ben Widawsky wrote: > > Reduce maintenance burden of DVSEC query implementation by using the > centralized PCI core implementation. > > Cc: io...@lists.linux-foundation.org > Cc: David Woodhouse > Cc: Lu Baolu > Signed-off-by: Ben Widawsky > --- >

Re: [PATCH v2 7/9] cxl/pci: Use pci core's DVSEC functionality

2021-09-28 Thread Dan Williams
On Thu, Sep 23, 2021 at 10:27 AM Ben Widawsky wrote: > > Reduce maintenance burden of DVSEC query implementation by using the > centralized PCI core implementation. > > Signed-off-by: Ben Widawsky > --- > drivers/cxl/pci.c | 20 +--- > 1 file changed, 1 insertion(+), 19

Re: [PATCH v2 5/9] cxl/pci: Make more use of cxl_register_map

2021-09-28 Thread Dan Williams
On Thu, Sep 23, 2021 at 10:27 AM Ben Widawsky wrote: > > The structure exists to pass around information about register mapping. > Using it more extensively cleans up many existing functions. I would have liked to have seen "add @base to cxl_register_map" and "use @map for @bar and @offset

Re: [PATCH v2 4/9] cxl/pci: Refactor cxl_pci_setup_regs

2021-09-28 Thread Dan Williams
On Thu, Sep 23, 2021 at 10:27 AM Ben Widawsky wrote: > > In preparation for moving parts of register mapping to cxl_core, the > cxl_pci driver is refactored to utilize a new helper to find register > blocks by type. > > cxl_pci scanned through all register blocks and mapping the ones that > the

Re: [PATCH v2 3/9] cxl/pci: Remove pci request/release regions

2021-09-28 Thread Dan Williams
> only comes when the registers are mapped for their final usage, and that > will have more precision in the request." Looks good to me: Reviewed-by: Dan Williams > > Recommended-by: Dan Williams This isn't one of the canonical tags: Documentation/process/submitting-patches.

Re: [PATCH v2 2/9] cxl/pci: Remove dev_dbg for unknown register blocks

2021-09-28 Thread Dan Williams
reduce the LOC in a subsequent patch to refactor some > of cxl_pci register mapping. Looks good to me: Reviewed-by: Dan Williams

Re: [PATCH v2 1/9] cxl: Convert "RBI" to enum

2021-09-27 Thread Dan Williams
Please spell out "register block indicator" in the subject so that the shortlog remains somewhat readable. On Thu, Sep 23, 2021 at 10:27 AM Ben Widawsky wrote: > > In preparation for passing around the Register Block Indicator (RBI) as > a parameter, it is desirable to convert the type to an

Re: [PATCH 7/7] ocxl: Use pci core's DVSEC functionality

2021-09-21 Thread Dan Williams
On Tue, Sep 21, 2021 at 3:05 PM Ben Widawsky wrote: > > Reduce maintenance burden of DVSEC query implementation by using the > centralized PCI core implementation. > > Cc: linuxppc-dev@lists.ozlabs.org > Cc: Frederic Barrat > Cc: Andrew Donnellan > Signed-off-by: Ben Widawsky > --- >

Re: [RESEND PATCH v4 1/4] drivers/nvdimm: Add nvdimm pmu structure

2021-09-14 Thread Dan Williams
On Tue, Sep 14, 2021 at 9:08 PM Dan Williams wrote: > > On Thu, Sep 9, 2021 at 12:56 AM kajoljain wrote: > > > > > > > > On 9/8/21 3:29 AM, Dan Williams wrote: > > > Hi Kajol, > > > > > > Apologies for the delay in responding to this serie

Re: [RESEND PATCH v4 1/4] drivers/nvdimm: Add nvdimm pmu structure

2021-09-14 Thread Dan Williams
On Thu, Sep 9, 2021 at 12:56 AM kajoljain wrote: > > > > On 9/8/21 3:29 AM, Dan Williams wrote: > > Hi Kajol, > > > > Apologies for the delay in responding to this series, some comments below: > > Hi Dan, > No issues, thanks for reviewing the patches. &g

Re: [RESEND PATCH v4 4/4] powerpc/papr_scm: Document papr_scm sysfs event format entries

2021-09-07 Thread Dan Williams
On Thu, Sep 2, 2021 at 10:11 PM Kajol Jain wrote: > > Details is added for the event, cpumask and format attributes > in the ABI documentation. > > Acked-by: Peter Zijlstra (Intel) > Reviewed-by: Madhavan Srinivasan > Tested-by: Nageswara R Sastry > Signed-off-by: Kajol Jain > --- >

Re: [RESEND PATCH v4 1/4] drivers/nvdimm: Add nvdimm pmu structure

2021-09-07 Thread Dan Williams
Hi Kajol, Apologies for the delay in responding to this series, some comments below: On Thu, Sep 2, 2021 at 10:10 PM Kajol Jain wrote: > > A structure is added, called nvdimm_pmu, for performance > stats reporting support of nvdimm devices. It can be used to add > nvdimm pmu data such as

Re: [PATCH v3] lockdown,selinux: fix wrong subject in some SELinux lockdown checks

2021-08-31 Thread Dan Williams
On Tue, Aug 31, 2021 at 6:53 AM Paul Moore wrote: > > On Tue, Aug 31, 2021 at 5:09 AM Ondrej Mosnacek wrote: > > On Sat, Jun 19, 2021 at 12:18 AM Dan Williams > > wrote: > > > On Wed, Jun 16, 2021 at 1:51 AM Ondrej Mosnacek > > > wrote: > > ...

Re: [PATCH v2 4/4] bus: Make remove callback return void

2021-07-06 Thread Dan Williams
mented buses return an ignored error code and so don't anticipate > wrong expectations for driver authors. > > drivers/cxl/core.c| 3 +-- > drivers/dax/bus.c | 4 +--- > drivers/nvdimm/bus.c | 3 +-- For CXL, DAX, and NVDIMM Acked-by: Dan Williams

Re: [RESEND-PATCH v2] powerpc/papr_scm: Add support for reporting dirty-shutdown-count

2021-06-26 Thread Dan Williams
em.io/documents/Dirty_Shutdown_Handling-V1.0.pdf > > Signed-off-by: Vaibhav Jain > Reviewed-by: Aneesh Kumar K.V Belated: Acked-by: Dan Williams It's looking like CXL will add one of these as well. Might be time to add a unified location when that happens and deprecate these bus-specific locations.

Re: [PATCH v3] lockdown,selinux: fix wrong subject in some SELinux lockdown checks

2021-06-18 Thread Dan Williams
: Ondrej Mosnacek [..] > diff --git a/drivers/cxl/mem.c b/drivers/cxl/mem.c > index 2acc6173da36..c1747b6555c7 100644 > --- a/drivers/cxl/mem.c > +++ b/drivers/cxl/mem.c > @@ -568,7 +568,7 @@ static bool cxl_mem_raw_command_allowed(u16 opcode) > if (!IS_ENABLED(CONFIG_CXL_MEM_RAW_

[PATCH v2] libnvdimm/pmem: Fix blk_cleanup_disk() usage

2021-06-07 Thread Dan Williams
son Cc: Jens Axboe Signed-off-by: Dan Williams --- Changes in v2 Improve the changelog. drivers/nvdimm/pmem.c |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/nvdimm/pmem.c b/drivers/nvdimm/pmem.c index 31f3c4bd6f72..fc6b78dd2d24 100644 --- a/drivers/nvdimm

[PATCH] libnvdimm/pmem: Fix blk_cleanup_disk() usage

2021-06-07 Thread Dan Williams
The queue_to_disk() helper can not be used after del_gendisk() communicate @disk via the pgmap->owner. Reported-by: Sachin Sant Fixes: 87eb73b2ca7c ("nvdimm-pmem: convert to blk_alloc_disk/blk_cleanup_disk") Cc: Christoph Hellwig Cc: Ulf Hansson Cc: Jens Axboe Signed-off-by:

Re: [PATCH 17/26] nvdimm-pmem: convert to blk_alloc_disk/blk_cleanup_disk

2021-06-06 Thread Dan Williams
[ add Sachin who reported this commit in -next ] On Thu, May 20, 2021 at 10:52 PM Christoph Hellwig wrote: > > Convert the nvdimm-pmem driver to use the blk_alloc_disk and > blk_cleanup_disk helpers to simplify gendisk and request_queue > allocation. > > Signed-off-by: Christoph Hellwig > --- >

Re: [PATCH v2] powerpc/papr_scm: Make 'perf_stats' invisible if perf-stats unavailable

2021-05-12 Thread Dan Williams
p->res.name = pdev->name; > p->res.flags = IORESOURCE_MEM; > > + /* Try retriving the stat buffer and see if its supported */ s/retriving/retrieving/ > + stat_size = drc_pmem_query_stats(p, NULL, 0); > + if (stat_size > 0) { > + p->stat_buffer_len = stat_size; > + dev_dbg(>pdev->dev, "Max perf-stat size %lu-bytes\n", > + p->stat_buffer_len); > + } > + > rc = papr_scm_nvdimm_init(p); > if (rc) > goto err2; > -- > 2.31.1 > After the minor fixups above you can add: Reviewed-by: Dan Williams ...I assume this will go through the PPC tree.

Re: [PATCH] powerpc/papr_scm: Reduce error severity if nvdimm stats inaccessible

2021-04-15 Thread Dan Williams
On Thu, Apr 15, 2021 at 4:44 AM Vaibhav Jain wrote: > > Thanks for looking into this Dan, > > Dan Williams writes: > > > On Wed, Apr 14, 2021 at 5:40 AM Vaibhav Jain wrote: > >> > >> Currently drc_pmem_qeury_stats() generates a dev_err in case > >

Re: [PATCH] powerpc/papr_scm: Reduce error severity if nvdimm stats inaccessible

2021-04-14 Thread Dan Williams
On Wed, Apr 14, 2021 at 5:40 AM Vaibhav Jain wrote: > > Currently drc_pmem_qeury_stats() generates a dev_err in case > "Enable Performance Information Collection" feature is disabled from > HMC. The error is of the form below: > > papr_scm ibm,persistent-memory:ibm,pmemory@44104001: Failed to

Re: [PATCH] mm/pmem: Avoid inserting hugepage PTE entry with fsdax if hugepage support is disabled

2021-02-05 Thread Dan Williams
ble of THP and prevent a huge fault if the hardware lacks hugepage > support. Looks good to me. Reviewed-by: Dan Williams I assume this will go through Andrew.

Re: [RFC][PATCH 1/2] libnvdimm: Introduce ND_CMD_GET_STAT to retrieve nvdimm statistics

2020-12-07 Thread Dan Williams
[ add perf maintainers ] On Sun, Nov 8, 2020 at 1:16 PM Vaibhav Jain wrote: > > Implement support for exposing generic nvdimm statistics via newly > introduced dimm-command ND_CMD_GET_STAT that can be handled by nvdimm > command handler function and provide values for these statistics back > to

[PATCH] powerpc: fix create_section_mapping compile warning

2020-11-16 Thread Dan Williams
of linux/mmzone.h is not sufficient. Cc: Michael Ellerman Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Andrew Morton Reported-by: kernel test robot Signed-off-by: Dan Williams --- arch/powerpc/include/asm/mmzone.h |7 +-- arch/powerpc/mm/mem.c |1 + 2 files changed

Re: error: redefinition of ‘dax_supported’

2020-09-21 Thread Dan Williams
On Mon, Sep 21, 2020 at 11:35 AM Nick Desaulniers wrote: > > Hello DAX maintainers, > I noticed our PPC64LE builds failing last night: > https://travis-ci.com/github/ClangBuiltLinux/continuous-integration/jobs/388047043 >

Re: [PATCH 12/20] Documentation: maintainer-entry-profile: eliminate duplicated word

2020-07-07 Thread Dan Williams
On Tue, Jul 7, 2020 at 11:07 AM Randy Dunlap wrote: > > Drop the doubled word "have". > > Signed-off-by: Randy Dunlap > Cc: Jonathan Corbet > Cc: linux-...@vger.kernel.org > Cc: Dan Williams > --- > Documentation/maintainer/maintainer-entry-profile.rst |

Re: [PATCH 16/20] block: move ->make_request_fn to struct block_device_operations

2020-07-01 Thread Dan Williams
| 5 +- > drivers/nvdimm/pmem.c | 5 +- For drivers/nvdimm Acked-by: Dan Williams

Re: [PATCH v6 6/8] powerpc/pmem: Avoid the barrier in flush routines

2020-06-30 Thread Dan Williams
On Tue, Jun 30, 2020 at 8:09 PM Aneesh Kumar K.V wrote: > > On 7/1/20 1:15 AM, Dan Williams wrote: > > On Tue, Jun 30, 2020 at 2:21 AM Aneesh Kumar K.V > > wrote: > > [..] > >>>> The bio argument isn't for range based flushing, it is for flush

Re: [PATCH v6 6/8] powerpc/pmem: Avoid the barrier in flush routines

2020-06-30 Thread Dan Williams
On Tue, Jun 30, 2020 at 2:21 AM Aneesh Kumar K.V wrote: [..] > >> The bio argument isn't for range based flushing, it is for flush > >> operations that need to complete asynchronously. > > How does the block layer determine that the pmem device needs > > asynchronous fushing? > > > >

Re: [PATCH updated] libnvdimm/nvdimm/flush: Allow architecture to override the flush barrier

2020-06-30 Thread Dan Williams
turally visible for > the platform buffer flush. Looks good, after a few minor fixups below you can add: Reviewed-by: Dan Williams I'm expecting that these will be merged through the powerpc tree since they mostly impact powerpc with only minor touches to libnvdimm. > Signed-

Re: [PATCH v6 5/8] powerpc/pmem/of_pmem: Update of_pmem to use the new barrier instruction.

2020-06-30 Thread Dan Williams
On Mon, Jun 29, 2020 at 10:05 PM Aneesh Kumar K.V wrote: > > Dan Williams writes: > > > On Mon, Jun 29, 2020 at 6:58 AM Aneesh Kumar K.V > > wrote: > >> > >> of_pmem on POWER10 can now use phwsync instead of hwsync to ensure > >> all previous wri

Re: [PATCH updated] libnvdimm/nvdimm/flush: Allow architecture to override the flush barrier

2020-06-30 Thread Dan Williams
On Mon, Jun 29, 2020 at 10:02 PM Aneesh Kumar K.V wrote: > > Dan Williams writes: > > > On Mon, Jun 29, 2020 at 1:29 PM Aneesh Kumar K.V > > wrote: > >> > >> Architectures like ppc64 provide persistent memory specific barriers > >> that will en

Re: [PATCH v6 7/8] powerpc/pmem: Add WARN_ONCE to catch the wrong usage of pmem flush functions.

2020-06-29 Thread Dan Williams
On Mon, Jun 29, 2020 at 6:58 AM Aneesh Kumar K.V wrote: > > We only support persistent memory on P8 and above. This is enforced by the > firmware and further checked on virtualzied platform during platform init. > Add WARN_ONCE in pmem flush routines to catch the wrong usage of these. > >

Re: [PATCH v6 6/8] powerpc/pmem: Avoid the barrier in flush routines

2020-06-29 Thread Dan Williams
On Mon, Jun 29, 2020 at 1:41 PM Aneesh Kumar K.V wrote: > > Michal Suchánek writes: > > > Hello, > > > > On Mon, Jun 29, 2020 at 07:27:20PM +0530, Aneesh Kumar K.V wrote: > >> nvdimm expect the flush routines to just mark the cache clean. The barrier > >> that mark the store globally visible is

Re: [PATCH v6 5/8] powerpc/pmem/of_pmem: Update of_pmem to use the new barrier instruction.

2020-06-29 Thread Dan Williams
On Mon, Jun 29, 2020 at 6:58 AM Aneesh Kumar K.V wrote: > > of_pmem on POWER10 can now use phwsync instead of hwsync to ensure > all previous writes are architecturally visible for the platform > buffer flush. > > Signed-off-by: Aneesh Kumar K.V > --- > arch/powerpc/include/asm/cacheflush.h | 7

Re: [PATCH updated] libnvdimm/nvdimm/flush: Allow architecture to override the flush barrier

2020-06-29 Thread Dan Williams
On Mon, Jun 29, 2020 at 1:29 PM Aneesh Kumar K.V wrote: > > Architectures like ppc64 provide persistent memory specific barriers > that will ensure that all stores for which the modifications are > written to persistent storage by preceding dcbfps and dcbstps > instructions have updated

Re: [PATCH v13 2/6] seq_buf: Export seq_buf_printf

2020-06-15 Thread Dan Williams
On Mon, Jun 15, 2020 at 5:56 AM Borislav Petkov wrote: > > On Mon, Jun 15, 2020 at 06:14:03PM +0530, Vaibhav Jain wrote: > > 'seq_buf' provides a very useful abstraction for writing to a string > > buffer without needing to worry about it over-flowing. However even > > though the API has been

Re: [PATCH v11 5/6] ndctl/papr_scm, uapi: Add support for PAPR nvdimm specific methods

2020-06-10 Thread Dan Williams
On Wed, Jun 10, 2020 at 5:10 AM Vaibhav Jain wrote: > > Dan Williams writes: > > > On Tue, Jun 9, 2020 at 10:54 AM Vaibhav Jain wrote: > >> > >> Thanks Dan for the consideration and taking time to look into this. > >> > >> My responses below:

Re: [PATCH v11 5/6] ndctl/papr_scm, uapi: Add support for PAPR nvdimm specific methods

2020-06-09 Thread Dan Williams
On Tue, Jun 9, 2020 at 10:54 AM Vaibhav Jain wrote: > > Thanks Dan for the consideration and taking time to look into this. > > My responses below: > > Dan Williams writes: > > > On Mon, Jun 8, 2020 at 5:16 PM kernel test robot wrote: > >> > >>

Re: [PATCH v11 5/6] ndctl/papr_scm, uapi: Add support for PAPR nvdimm specific methods

2020-06-08 Thread Dan Williams
On Mon, Jun 8, 2020 at 5:16 PM kernel test robot wrote: > > Hi Vaibhav, > > Thank you for the patch! Perhaps something to improve: > > [auto build test WARNING on powerpc/next] > [also build test WARNING on linus/master v5.7 next-20200605] > [cannot apply to linux-nvdimm/libnvdimm-for-next

Re: [PATCH v10 5/6] ndctl/papr_scm, uapi: Add support for PAPR nvdimm specific methods

2020-06-05 Thread Dan Williams
se of a PDSM request is received via ND_CMD_CALL > > command from libnvdimm. > > > > Cc: "Aneesh Kumar K . V" > > Cc: Dan Williams > > Cc: Michael Ellerman > > Cc: Ira Weiny > > Signed-off-by: Vaibhav Jain > > --- > > Changelog: > &

Re: [PATCH v10 4/6] powerpc/papr_scm: Improve error logging and handling papr_scm_ndctl()

2020-06-05 Thread Dan Williams
y ensuring that value of > > 'cmd_rc' is always logged when papr_scm_ndctl() returns. > > > > Cc: "Aneesh Kumar K . V" > > Cc: Dan Williams > > Cc: Michael Ellerman > > Cc: Ira Weiny > > Signed-off-by: Vaibhav Jain > > --- > > Changel

Re: [RESEND PATCH v9 4/5] ndctl/papr_scm,uapi: Add support for PAPR nvdimm specific methods

2020-06-05 Thread Dan Williams
On Fri, Jun 5, 2020 at 8:22 AM Vaibhav Jain wrote: [..] > > Oh, why not define a maximal health payload with all the attributes > > you know about today, leave some room for future expansion, and then > > report a validity flag for each attribute? This is how the "intel" > > smart-health payload

Re: [RFC PATCH 1/2] libnvdimm: Add prctl control for disabling synchronous fault support.

2020-05-30 Thread Dan Williams
On Sat, May 30, 2020 at 12:18 AM Aneesh Kumar K.V wrote: > > On 5/30/20 12:52 AM, Dan Williams wrote: > > On Fri, May 29, 2020 at 3:55 AM Aneesh Kumar K.V > > wrote: > >> > >> On 5/29/20 3:22 PM, Jan Kara wrote: > >>> Hi! > >>

Re: [RFC PATCH 1/2] libnvdimm: Add prctl control for disabling synchronous fault support.

2020-05-29 Thread Dan Williams
On Fri, May 29, 2020 at 3:55 AM Aneesh Kumar K.V wrote: > > On 5/29/20 3:22 PM, Jan Kara wrote: > > Hi! > > > > On Fri 29-05-20 15:07:31, Aneesh Kumar K.V wrote: > >> Thanks Michal. I also missed Jeff in this email thread. > > > > And I think you'll also need some of the sched maintainers for the

Re: [PATCH v8 1/5] powerpc: Document details on H_SCM_HEALTH hcall

2020-05-27 Thread Dan Williams
already have 2 ways to describe persistent memory devices, let's not perpetuate a third so that "grep" has a chance to find interrelated code across architectures. Other than that this looks good to me. > Cc: "Aneesh Kumar K . V" > Cc: Dan Williams > Cc: Mic

Re: [PATCH v2 3/5] libnvdimm/nvdimm/flush: Allow architecture to override the flush barrier

2020-05-21 Thread Dan Williams
On Thu, May 21, 2020 at 7:39 AM Jeff Moyer wrote: > > Dan Williams writes: > > >> But I agree with your concern that if we have older kernel/applications > >> that continue to use `dcbf` on future hardware we will end up > >> having issues w.r.t powerfa

Re: [PATCH v2 3/5] libnvdimm/nvdimm/flush: Allow architecture to override the flush barrier

2020-05-21 Thread Dan Williams
On Thu, May 21, 2020 at 10:03 AM Aneesh Kumar K.V wrote: > > On 5/21/20 8:08 PM, Jeff Moyer wrote: > > Dan Williams writes: > > > >>> But I agree with your concern that if we have older kernel/applications > >>> that continue to use `dcbf` on future h

Re: [PATCH v2 3/5] libnvdimm/nvdimm/flush: Allow architecture to override the flush barrier

2020-05-19 Thread Dan Williams
On Tue, May 19, 2020 at 6:53 AM Aneesh Kumar K.V wrote: > > Dan Williams writes: > > > On Mon, May 18, 2020 at 10:30 PM Aneesh Kumar K.V > > wrote: > > ... > > >> Applications using new instructions will behave as expected when running > >> on P8

Re: [PATCH v2 3/5] libnvdimm/nvdimm/flush: Allow architecture to override the flush barrier

2020-05-19 Thread Dan Williams
On Mon, May 18, 2020 at 10:30 PM Aneesh Kumar K.V wrote: > > > Hi Dan, > > Apologies for the delay in response. I was waiting for feedback from > hardware team before responding to this email. > > > Dan Williams writes: > > > On Tue, May 12, 2020 at

Re: remove a few uses of ->queuedata

2020-05-13 Thread Dan Williams
On Tue, May 12, 2020 at 1:08 AM Christoph Hellwig wrote: > > On Sat, May 09, 2020 at 08:07:14AM -0700, Dan Williams wrote: > > > which are all used in the I/O submission path (generic_make_request / > > > generic_make_request_checks). This is mostly a prep cleanup pa

Re: [PATCH v2 3/5] libnvdimm/nvdimm/flush: Allow architecture to override the flush barrier

2020-05-13 Thread Dan Williams
On Tue, May 12, 2020 at 8:47 PM Aneesh Kumar K.V wrote: > > Architectures like ppc64 provide persistent memory specific barriers > that will ensure that all stores for which the modifications are > written to persistent storage by preceding dcbfps and dcbstps > instructions have updated

Re: remove a few uses of ->queuedata

2020-05-09 Thread Dan Williams
On Sat, May 9, 2020 at 1:24 AM Christoph Hellwig wrote: > > On Fri, May 08, 2020 at 11:04:45AM -0700, Dan Williams wrote: > > On Fri, May 8, 2020 at 9:16 AM Christoph Hellwig wrote: > > > > > > Hi all, > > > > > > various bio based drivers use queu

Re: remove a few uses of ->queuedata

2020-05-08 Thread Dan Williams
On Fri, May 8, 2020 at 9:16 AM Christoph Hellwig wrote: > > Hi all, > > various bio based drivers use queue->queuedata despite already having > set up disk->private_data, which can be used just as easily. This > series cleans them up to only use a single private data pointer. ...but isn't the

Re: [PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP

2020-05-02 Thread Dan Williams
On Sat, May 2, 2020 at 2:27 AM David Hildenbrand wrote: > > >> Now, let's clarify what I want regarding virtio-mem: > >> > >> 1. kexec should not add virtio-mem memory to the initial firmware > >>memmap. The driver has to be in charge as discussed. > >> 2. kexec should not place kexec images

Re: [PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP

2020-05-01 Thread Dan Williams
On Fri, May 1, 2020 at 2:11 PM David Hildenbrand wrote: > > On 01.05.20 22:12, Dan Williams wrote: [..] > >>> Consider the case of EFI Special Purpose (SP) Memory that is > >>> marked EFI Conventional Memory with the SP attribute. In that case the &g

Re: [PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP

2020-05-01 Thread Dan Williams
On Fri, May 1, 2020 at 12:18 PM David Hildenbrand wrote: > > On 01.05.20 20:43, Dan Williams wrote: > > On Fri, May 1, 2020 at 11:14 AM David Hildenbrand wrote: > >> > >> On 01.05.20 20:03, Dan Williams wrote: > >>> On Fri, May 1, 2020 a

Re: [PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP

2020-05-01 Thread Dan Williams
On Fri, May 1, 2020 at 11:14 AM David Hildenbrand wrote: > > On 01.05.20 20:03, Dan Williams wrote: > > On Fri, May 1, 2020 at 10:51 AM David Hildenbrand wrote: > >> > >> On 01.05.20 19:45, David Hildenbrand wrote: > >>> On 01.05.20 19:39, Dan Williams

Re: [PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP

2020-05-01 Thread Dan Williams
On Fri, May 1, 2020 at 10:51 AM David Hildenbrand wrote: > > On 01.05.20 19:45, David Hildenbrand wrote: > > On 01.05.20 19:39, Dan Williams wrote: > >> On Fri, May 1, 2020 at 10:21 AM David Hildenbrand wrote: > >>> > >>> On 01.05.20 18:56, Dan Willi

Re: [PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP

2020-05-01 Thread Dan Williams
On Fri, May 1, 2020 at 10:21 AM David Hildenbrand wrote: > > On 01.05.20 18:56, Dan Williams wrote: > > On Fri, May 1, 2020 at 2:34 AM David Hildenbrand wrote: > >> > >> On 01.05.20 00:24, Andrew Morton wrote: > >>> On Thu, 30 Apr 2020 20:4

Re: [PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP

2020-05-01 Thread Dan Williams
On Fri, May 1, 2020 at 2:34 AM David Hildenbrand wrote: > > On 01.05.20 00:24, Andrew Morton wrote: > > On Thu, 30 Apr 2020 20:43:39 +0200 David Hildenbrand > > wrote: > > > >>> > >>> Why does the firmware map support hotplug entries? > >> > >> I assume: > >> > >> The firmware memmap was added

Re: [PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP

2020-04-30 Thread Dan Williams
On Thu, Apr 30, 2020 at 11:44 AM David Hildenbrand wrote: > > >>> If the class of memory is different then please by all means let's mark > >>> it differently in struct resource so everyone knows it is different. > >>> But that difference needs to be more than hotplug. > >>> > >>> That

Re: [PATCH v1 2/3] mm/memory_hotplug: Introduce MHP_DRIVER_MANAGED

2020-04-30 Thread Dan Williams
On Thu, Apr 30, 2020 at 1:21 AM David Hildenbrand wrote: > >> Just because we decided to use some DAX memory in the current kernel as > >> system ram, doesn't mean we should make that decision for the kexec > >> kernel (e.g., using it as initial memory, placing kexec binaries onto > >> it, etc.).

Re: [PATCH v1 2/3] mm/memory_hotplug: Introduce MHP_DRIVER_MANAGED

2020-04-30 Thread Dan Williams
On Thu, Apr 30, 2020 at 12:20 AM David Hildenbrand wrote: > > On 29.04.20 18:08, David Hildenbrand wrote: > > Some paravirtualized devices that add memory via add_memory() and > > friends (esp. virtio-mem) don't want to create entries in > > /sys/firmware/memmap/ - primarily to hinder kexec from

Re: [PATCH v5 4/4] powerpc/papr_scm: Implement support for DSM_PAPR_SCM_HEALTH

2020-04-03 Thread Dan Williams
On Tue, Mar 31, 2020 at 7:33 AM Vaibhav Jain wrote: > > This patch implements support for papr_scm command > 'DSM_PAPR_SCM_HEALTH' that returns a newly introduced 'struct > nd_papr_scm_dimm_health_stat' instance containing dimm health > information back to user space in response to ND_CMD_CALL.

Re: [PATCH v5 3/4] powerpc/papr_scm,uapi: Add support for handling PAPR DSM commands

2020-04-03 Thread Dan Williams
On Tue, Mar 31, 2020 at 7:33 AM Vaibhav Jain wrote: > > Implement support for handling PAPR DSM commands in papr_scm > module. We advertise support for ND_CMD_CALL for the dimm command mask > and implement necessary scaffolding in the module to handle ND_CMD_CALL > ioctl and DSM commands that we

Re: [PATCH v5 2/4] ndctl/uapi: Introduce NVDIMM_FAMILY_PAPR_SCM as a new NVDIMM DSM family

2020-04-03 Thread Dan Williams
On Tue, Mar 31, 2020 at 7:33 AM Vaibhav Jain wrote: > > Add PAPR-scm family of DSM command-set to the white list of NVDIMM > command sets. > > Signed-off-by: Vaibhav Jain > --- > Changelog: > > v4..v5 : None > > v3..v4 : None > > v2..v3 : Updated the patch prefix to 'ndctl/uapi' [Aneesh] > >

Re: [PATCH v5 1/4] powerpc/papr_scm: Fetch nvdimm health information from PHYP

2020-04-02 Thread Dan Williams
On Wed, Apr 1, 2020 at 8:08 PM Dan Williams wrote: [..] > > * "locked" : Indicating that nvdimm contents cant be modified > >until next power cycle. > > There is the generic NDD_LOCKED flag, can you use that? ...and in > general I wonde

Re: [PATCH v4 16/25] nvdimm/ocxl: Implement the Read Error Log command

2020-04-02 Thread Dan Williams
On Tue, Mar 31, 2020 at 1:59 AM Alastair D'Silva wrote: > > The read error log command extracts information from the controller's > internal error log. > > This patch exposes this information in 2 ways: > - During probe, if an error occurs & a log is available, print it to the > console > -

Re: [PATCH v4 14/25] nvdimm/ocxl: Add support for Admin commands

2020-04-02 Thread Dan Williams
On Sun, Mar 29, 2020 at 10:23 PM Alastair D'Silva wrote: > > Admin commands for these devices are the primary means of interacting > with the device controller to provide functionality beyond the load/store > capabilities offered via the NPU. > > For example, SMART data, firmware update, and

Re: [PATCH v5 1/4] powerpc/papr_scm: Fetch nvdimm health information from PHYP

2020-04-01 Thread Dan Williams
On Tue, Mar 31, 2020 at 7:33 AM Vaibhav Jain wrote: > > Implement support for fetching nvdimm health information via > H_SCM_HEALTH hcall as documented in Ref[1]. The hcall returns a pair > of 64-bit big-endian integers which are then stored in 'struct > papr_scm_priv' and subsequently partially

Re: [PATCH v4 19/25] nvdimm/ocxl: Forward events to userspace

2020-04-01 Thread Dan Williams
On Tue, Mar 31, 2020 at 1:59 AM Alastair D'Silva wrote: > > Some of the interrupts that the card generates are better handled > by the userspace daemon, in particular: > Controller Hardware/Firmware Fatal > Controller Dump Available > Error Log available > > This patch allows a userspace

Re: [PATCH v4 15/25] nvdimm/ocxl: Register a character device for userspace to interact with

2020-04-01 Thread Dan Williams
On Sun, Mar 29, 2020 at 10:53 PM Alastair D'Silva wrote: > > This patch introduces a character device (/dev/ocxlpmemX) which further > patches will use to interact with userspace, such as error logs, > controller stats and card debug functionality. This was asked earlier, but I'll reiterate, I

Re: [PATCH v4 13/25] nvdimm/ocxl: Read the capability registers & wait for device ready

2020-04-01 Thread Dan Williams
On Sun, Mar 29, 2020 at 10:23 PM Alastair D'Silva wrote: > > This patch reads timeouts & firmware version from the controller, and > uses those timeouts to wait for the controller to report that it is ready > before handing the memory over to libnvdimm. > > Signed-off-by: Alastair D'Silva > ---

Re: [PATCH v4 12/25] nvdimm/ocxl: Add register addresses & status values to the header

2020-04-01 Thread Dan Williams
On Sun, Mar 29, 2020 at 10:53 PM Alastair D'Silva wrote: > > These values have been taken from the device specifications. Link to specification?

Re: [PATCH v4 11/25] powerpc: Enable the OpenCAPI Persistent Memory driver for powernv_defconfig

2020-04-01 Thread Dan Williams
On Sun, Mar 29, 2020 at 10:23 PM Alastair D'Silva wrote: > > This patch enables the OpenCAPI Persistent Memory driver, as well > as DAX support, for the 'powernv' defconfig. > > DAX is not a strict requirement for the functioning of the driver, but it > is likely that a user will want to create a

Re: [PATCH v4 10/25] nvdimm: Add driver for OpenCAPI Persistent Memory

2020-04-01 Thread Dan Williams
On Wed, Apr 1, 2020 at 1:49 AM Dan Williams wrote: > > On Sun, Mar 29, 2020 at 10:23 PM Alastair D'Silva > wrote: > > > > This driver exposes LPC memory on OpenCAPI pmem cards > > as an NVDIMM, allowing the existing nvram infrastructure > > to be used. >

Re: [PATCH v4 10/25] nvdimm: Add driver for OpenCAPI Persistent Memory

2020-04-01 Thread Dan Williams
On Sun, Mar 29, 2020 at 10:23 PM Alastair D'Silva wrote: > > This driver exposes LPC memory on OpenCAPI pmem cards > as an NVDIMM, allowing the existing nvram infrastructure > to be used. > > Namespace metadata is stored on the media itself, so > scm_reserve_metadata() maps 1 section's worth of

Re: [PATCH v4 08/25] ocxl: Emit a log message showing how much LPC memory was detected

2020-04-01 Thread Dan Williams
On Sun, Mar 29, 2020 at 10:23 PM Alastair D'Silva wrote: > > This patch emits a message showing how much LPC memory & special purpose > memory was detected on an OCXL device. > > Signed-off-by: Alastair D'Silva > Acked-by: Frederic Barrat > Acked-by: Andrew Donnellan > --- >

Re: [PATCH v4 07/25] ocxl: Add functions to map/unmap LPC memory

2020-04-01 Thread Dan Williams
On Sun, Mar 29, 2020 at 10:23 PM Alastair D'Silva wrote: > > Add functions to map/unmap LPC memory > "map memory" is an overloaded term. I'm guessing this patch has nothing to do with mapping memory in the MMU. Is it updating hardware resource decoders to start claiming address space that was

Re: [PATCH v4 05/25] ocxl: Address kernel doc errors & warnings

2020-04-01 Thread Dan Williams
On Sun, Mar 29, 2020 at 10:23 PM Alastair D'Silva wrote: > > This patch addresses warnings and errors from the kernel doc scripts for > the OpenCAPI driver. > > It also makes minor tweaks to make the docs more consistent. > > Signed-off-by: Alastair D'Silva > Acked-by: Andrew Donnellan > --- >

  1   2   3   4   5   >