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
> ---
>
On Sun, Mar 29, 2020 at 10:53 PM Alastair D'Silva wrote:
>
> OpenCAPI LPC memory is allocated per link, but each link supports
> multiple AFUs, and each AFU can have LPC memory assigned to it.
Is there an OpenCAPI primer to decode these objects and their
associations that I can reference?
>
>
On Sun, Mar 29, 2020 at 10:23 PM Alastair D'Silva wrote:
>
> Function declarations don't need externs, remove the existing ones
> so they are consistent with newer code
>
> Signed-off-by: Alastair D'Silva
> Acked-by: Andrew Donnellan
> Acked-by: Frederic Barrat
Looks good.
> ---
>
On Sun, Mar 29, 2020 at 10:23 PM Alastair D'Silva wrote:
>
> This patch adds OPAL calls to powernv so that the OpenCAPI
> driver can map & release LPC (Lowest Point of Coherency) memory.
>
> Signed-off-by: Alastair D'Silva
> Reviewed-by: Andrew Donnellan
> ---
>
On Sun, Mar 29, 2020 at 10:23 PM Alastair D'Silva wrote:
>
> When setting up OpenCAPI connected persistent memory, the range check may
> not be performed until quite late (or perhaps not at all, if the user does
> not establish a DAX device).
>
> This patch makes the range check callable so we
On Sun, Mar 29, 2020 at 10:23 PM Alastair D'Silva wrote:
>
> Add OPAL calls for LPC memory alloc/release
>
This seems to be referencing an existing api definition, can you
include a pointer to the spec in case someone wanted to understand
what these routines do? I suspect this is not allocating
On Sun, Mar 29, 2020 at 10:23 PM Alastair D'Silva wrote:
>
> This series adds support for OpenCAPI Persistent Memory devices on bare metal
> (arch/powernv), exposing them as nvdimms so that we can make use of the
> existing infrastructure. There already exists a driver for the same devices
>
On Fri, Mar 20, 2020 at 2:25 AM Aneesh Kumar K.V
wrote:
>
>
> Hi Dan,
>
>
> Dan Williams writes:
>
> ...
>
>
> >
> >>
> >> Or are you suggesting that application should not infer any of those
> >> details looking at persis
Reported-by: Jeff Moyer
Reviewed-by: Aneesh Kumar K.V
Reviewed-by: Jeff Moyer
Link:
https://lore.kernel.org/r/158041478371.3889308.14542630147672668068.st...@dwillia2-desk3.amr.corp.intel.com
Signed-off-by: Dan Williams
---
drivers/nvdimm/dimm_devs.c | 86 +++
drivers
Moyer
Reviewed-by: Aneesh Kumar K.V
Link:
https://lore.kernel.org/r/158041477856.3889308.4212605617834097674.st...@dwillia2-desk3.amr.corp.intel.com
Signed-off-by: Dan Williams
---
arch/powerpc/platforms/pseries/papr_scm.c |2 +-
drivers/acpi/nfit/core.c |4 +++-
drivers
-by: Aneesh Kumar K.V
Cc: Jeff Moyer
Fixes: a3619190d62e ("libnvdimm/pfn: stop padding pmem namespaces to section
alignment")
Reviewed-by: Aneesh Kumar K.V
Signed-off-by: Dan Williams
---
drivers/nvdimm/namespace_devs.c | 17 +
drivers/nvdimm/pfn.h
exposing the namespace to I/O when the infoblock needs to
be corrected, or the system needs to be put into a different
configuration (like changing the page size on PowerPC).
Cc: Aneesh Kumar K.V
Cc: Jeff Moyer
Reviewed-by: Aneesh Kumar K.V
Signed-off-by: Dan Williams
---
drivers/nvdimm/pfn_devs.c
ern for arch
overrides.
Based on an initial patch by Aneesh.
Link:
http://lore.kernel.org/r/capcyv4gbgnp95apyabcsocea50tqj9b5h__83vgngjq3oug...@mail.gmail.com
Reported-by: Aneesh Kumar K.V
Reported-by: Jeff Moyer
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Reviewed-by: Aneesh Kumar K.
ride where necessary.
Thanks to Aneesh for early feedback and testing on this change to
alignment handling.
---
Dan Williams (5):
mm/memremap_pages: Introduce memremap_compat_align()
libnvdimm/pfn: Prevent raw mode fallback if pfn-infoblock valid
libnvdimm/namespace: Enforce m
On Mon, Mar 2, 2020 at 10:55 AM Logan Gunthorpe wrote:
>
>
>
> On 2020-02-29 3:44 p.m., Dan Williams wrote:
> > On Fri, Feb 21, 2020 at 10:25 AM Logan Gunthorpe
> > wrote:
> >>
> >> devm_memremap_pages() is currently used by the PCI P2PDMA code to crea
On Mon, Mar 2, 2020 at 4:09 AM Aneesh Kumar K.V
wrote:
>
> Dan Williams writes:
>
> > The pmem driver on PowerPC crashes with the following signature when
> > instantiating misaligned namespaces that map their capacity via
> > memremap_pages().
> >
> >
On Mon, Mar 2, 2020 at 9:59 AM Frederic Barrat wrote:
>
>
>
> Le 21/02/2020 à 04:27, Alastair D'Silva a écrit :
> > From: Alastair D'Silva
> >
> > Similar to the previous patch, this adds support for near storage commands.
> >
> > Signed-off-by: Alastair D'Silva
> > ---
>
>
> Is any of these
aching type, as some P2PDMA cases will not want WC.
> However, those use-cases are not upstream yet and this can be changed
> when they arrive.
>
> Cc: Dan Williams
> Cc: Christoph Hellwig
> Cc: Jason Gunthorpe
> Signed-off-by: Logan Gunthorpe
> ---
> mm/memremap.c |
eing these architectures don't support ZONE_DEVICE.
>
> A check in __add_pages() is also added to ensure the pgprot parameter was
> set for all arches.
>
> Cc: Dan Williams
> Signed-off-by: Logan Gunthorpe
> Acked-by: David Hildenbrand
> Acked-by: Michal Hocko
> ---
&
Thomas Gleixner
> Cc: Ingo Molnar
> Cc: Borislav Petkov
> Cc: "H. Peter Anvin"
> Cc: x...@kernel.org
> Cc: Dave Hansen
> Cc: Andy Lutomirski
> Cc: Peter Zijlstra
> Signed-off-by: Logan Gunthorpe
Looks good, checked for argument confusion, passes the nvdimm unit tests.
Reviewed-by: Dan Williams
want new usages to make the mistake of
calling:
_set_memory_prot(..., pgprot_writecombine(pgprot))
...instead of
_set_memory_wc()
I'm thinking just a double underscore rename (__set_memory_prot) and a
kerneldoc comment for that pointing people to use the direct
_set_memory_ helpers.
With that you can add:
Reviewed-by: Dan Williams
d looks good to me:
Reviewed-by: Dan Williams
On Tue, Feb 18, 2020 at 1:03 PM Dan Williams wrote:
>
> On Tue, Feb 18, 2020 at 1:00 PM Jeff Moyer wrote:
> >
> > Vaibhav Jain writes:
> >
> > > Presently the error code returned via out variable 'cmd_rc' from the
> > > nvdimm-bus controller function is
On Fri, Feb 21, 2020 at 10:25 AM Logan Gunthorpe wrote:
>
> This variable is not used anywhere and should therefore be removed
> from the structure.
>
> Signed-off-by: Logan Gunthorpe
> Reviewed-by: David Hildenbrand
Reviewed-by: Dan Williams
Reported-by: Jeff Moyer
Reviewed-by: Aneesh Kumar K.V
Reviewed-by: Jeff Moyer
Link:
https://lore.kernel.org/r/158041478371.3889308.14542630147672668068.st...@dwillia2-desk3.amr.corp.intel.com
Signed-off-by: Dan Williams
---
drivers/nvdimm/dimm_devs.c | 86 +++
drivers
Moyer
Reviewed-by: Aneesh Kumar K.V
Link:
https://lore.kernel.org/r/158041477856.3889308.4212605617834097674.st...@dwillia2-desk3.amr.corp.intel.com
Signed-off-by: Dan Williams
---
arch/powerpc/platforms/pseries/papr_scm.c |2 +-
drivers/acpi/nfit/core.c |4 +++-
drivers
-by: Aneesh Kumar K.V
Cc: Jeff Moyer
Fixes: a3619190d62e ("libnvdimm/pfn: stop padding pmem namespaces to section
alignment")
Signed-off-by: Dan Williams
---
drivers/nvdimm/namespace_devs.c | 12
drivers/nvdimm/pfn_devs.c | 26 +++---
2 files c
exposing the namespace to I/O when the infoblock needs to
be corrected, or the system needs to be put into a different
configuration (like changing the page size on PowerPC).
Cc: Aneesh Kumar K.V
Cc: Jeff Moyer
Signed-off-by: Dan Williams
---
drivers/nvdimm/pfn_devs.c |8
1 file
ern for arch
overrides.
Based on an initial patch by Aneesh.
Link:
http://lore.kernel.org/r/capcyv4gbgnp95apyabcsocea50tqj9b5h__83vgngjq3oug...@mail.gmail.com
Reported-by: Aneesh Kumar K.V
Reported-by: Jeff Moyer
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Signed-off-by: Dan Willi
e same
namespace creation capability as previous kernels.
The ndctl unit tests, which have some misaligned namespace assumptions,
are updated to use the alignment override where necessary.
Thanks to Aneesh for early feedback and testing on this improved
alignment handling.
---
Dan Williams (5)
On Thu, Feb 27, 2020 at 10:03 AM Jason Gunthorpe wrote:
>
> On Thu, Feb 27, 2020 at 09:55:04AM -0800, Dan Williams wrote:
> > On Thu, Feb 27, 2020 at 9:43 AM Jason Gunthorpe wrote:
> > >
> > > On Thu, Feb 27, 2020 at 10:21:50AM -0700, Logan Gunthorpe wrote:
> &g
On Thu, Feb 27, 2020 at 9:43 AM Jason Gunthorpe wrote:
>
> On Thu, Feb 27, 2020 at 10:21:50AM -0700, Logan Gunthorpe wrote:
> >
> >
> > On 2020-02-27 10:17 a.m., Jason Gunthorpe wrote:
> > >> Instead of this, this series proposes a change to arch_add_memory()
> > >> to take the pgprot required by
On Thu, Feb 20, 2020 at 7:28 PM Alastair D'Silva wrote:
>
> From: Alastair D'Silva
>
> Similar to the previous patch, this adds support for near storage commands.
Similar comment as the last patch. This changelog does not give the
reviewer any frame of reference to review the patch.
On Thu, Feb 20, 2020 at 7:28 PM Alastair D'Silva wrote:
>
> From: Alastair D'Silva
>
> This patch requests the metadata required to issue admin commands, as well
> as some helper functions to construct and check the completion of the
> commands.
What are the admin commands? Any pointer to a
is at odds with how
> > most subsystems operate. Is there any particular reason we're doing
> > things this way or should we think about moving libnvdimm users to
> > drivers/nvdimm/?
> >
> > Oliver
>
>
> I'm not too fussed where it ends up, as long as i
On Fri, Feb 21, 2020 at 8:21 AM Dan Williams wrote:
>
> On Thu, Feb 20, 2020 at 7:28 PM Alastair D'Silva wrote:
> >
> > From: Alastair D'Silva
> >
> > This series adds support for OpenCAPI Persistent Memory devices, exposing
> > them as nvdimms so
On Thu, Feb 20, 2020 at 7:28 PM Alastair D'Silva wrote:
>
> From: Alastair D'Silva
>
> This series adds support for OpenCAPI Persistent Memory devices, exposing
> them as nvdimms so that we can make use of the existing infrastructure.
A single sentence to introduce:
24 files changed, 3029
On Tue, Feb 18, 2020 at 1:00 PM Jeff Moyer wrote:
>
> Vaibhav Jain writes:
>
> > Presently the error code returned via out variable 'cmd_rc' from the
> > nvdimm-bus controller function is ignored when called from
> > __nd_ioctl() and never communicated back to user-space code that called
> > an
On Fri, Feb 14, 2020 at 12:59 PM Jeff Moyer wrote:
>
> Dan Williams writes:
>
> > On Thu, Feb 13, 2020 at 8:58 AM Jeff Moyer wrote:
>
> >> I have just a couple of questions.
> >>
> >> First, can you please add a comment above the generic implementa
On Thu, Feb 13, 2020 at 1:55 PM Jeff Moyer wrote:
>
> Dan Williams writes:
>
> > The pmem driver on PowerPC crashes with the following signature when
> > instantiating misaligned namespaces that map their capacity via
> > memremap_pages().
> >
> > B
On Thu, Feb 13, 2020 at 8:58 AM Jeff Moyer wrote:
>
> Dan Williams writes:
>
> > The "sub-section memory hotplug" facility allows memremap_pages() users
> > like libnvdimm to compensate for hardware platforms like x86 that have a
> > section size larg
Reported-by: Jeff Moyer
Signed-off-by: Dan Williams
Reviewed-by: Aneesh Kumar K.V
Link:
https://lore.kernel.org/r/158041478371.3889308.14542630147672668068.st...@dwillia2-desk3.amr.corp.intel.com
Signed-off-by: Dan Williams
---
drivers/nvdimm/dimm_devs.c | 86
Reviewed-by: Aneesh Kumar K.V
Link:
https://lore.kernel.org/r/158041477856.3889308.4212605617834097674.st...@dwillia2-desk3.amr.corp.intel.com
Signed-off-by: Dan Williams
---
arch/powerpc/platforms/pseries/papr_scm.c |2 +-
drivers/acpi/nfit/core.c |4 +++-
drivers
...@dwillia2-desk3.amr.corp.intel.com
Signed-off-by: Dan Williams
---
drivers/nvdimm/namespace_devs.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/nvdimm/namespace_devs.c b/drivers/nvdimm/namespace_devs.c
index 032dc61725ff..aff1f32fdb4f 100644
--- a/drivers/nvdimm
1 - 100 of 389 matches
Mail list logo
