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
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:
> >> >>
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
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
> | |--
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.
> >
>
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’
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
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.
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
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
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
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,
> > &
hing to unwind.
The rest looks good to me. After dropping "goto out;" you can add:
Reviewed-by: Dan Williams
rough device_add()."
Fixes: 41cd8b70c37a ("libnvdimm, btt: add support for blk integrity")
With that you can add:
Reviewed-by: 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
. 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
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
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
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
> ---
>
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
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
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
> 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.
reduce the LOC in a subsequent patch to refactor some
> of cxl_pci register mapping.
Looks good to me:
Reviewed-by: 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
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
> ---
>
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
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
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
> ---
>
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
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:
>
> ...
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
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.
: 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_
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
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:
[ 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
> ---
>
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.
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
> >
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
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.
[ 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
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
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
>
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 |
| 5 +-
> drivers/nvdimm/pmem.c | 5 +-
For drivers/nvdimm
Acked-by: 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
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?
> >
>
>
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-
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
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
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.
>
>
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
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
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
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
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:
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:
> >>
> >>
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
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:
> &
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
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
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!
> >>
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.).
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
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.
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
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]
>
>
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
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
> -
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
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
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
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
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
> ---
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?
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
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.
>
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
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
> ---
>
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
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 - 100 of 432 matches
Mail list logo
