On Sat, Mar 28, 2020 at 07:56:17PM -0700, Matthew Wilcox wrote:
> On Fri, Mar 27, 2020 at 06:11:47PM +1100, Alastair D'Silva wrote:
> > +static struct mutex minors_idr_lock;
> > +static struct idr minors_idr;
> ...
> > + mutex_lock(_idr_lock);
> > + minor = idr_alloc(_idr, ocxlpmem, 0,
On Fri, Mar 27, 2020 at 06:11:47PM +1100, Alastair D'Silva wrote:
> +static struct mutex minors_idr_lock;
> +static struct idr minors_idr;
...
> + mutex_lock(_idr_lock);
> + minor = idr_alloc(_idr, ocxlpmem, 0, NUM_MINORS, GFP_KERNEL);
> + mutex_unlock(_idr_lock);
...
> +
This patch retrieves the serial number of the card and makes it available
to consumers of the ocxl driver via the ocxl_fn struct.
Signed-off-by: Alastair D'Silva
Acked-by: Frederic Barrat
Acked-by: Andrew Donnellan
---
drivers/misc/ocxl/config.c | 46 ++
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 PMEM storage
at the start to hold this. The rest of the PMEM range is
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
---
drivers/nvdimm/ocxl/Makefile| 2 +-
Add OPAL calls for LPC memory alloc/release
Signed-off-by: Alastair D'Silva
Acked-by: Andrew Donnellan
Acked-by: Frederic Barrat
---
arch/powerpc/include/asm/opal-api.h| 2 ++
arch/powerpc/include/asm/opal.h| 2 ++
arch/powerpc/platforms/powernv/opal-call.c | 2 ++
3 files
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
---
drivers/misc/ocxl/config.c | 4
1 file changed, 4 insertions(+)
diff --git
On 03/28/20 at 11:31am, Hoan Tran wrote:
> In NUMA layout which nodes have memory ranges that span across other nodes,
> the mm driver can detect the memory node id incorrectly.
>
> For example, with layout below
> Node 0 address:
> Node 1 address:
Sorry,
... in boot_init_stack_canary().
This is the archetypical example of where the extra security of
get_random_bytes() is wasted. The canary is only important as
long as it's stored in __stack_chk_guard.
It's also a great example of code that has been copied around
a lot and not updated.
Remove
In NUMA layout which nodes have memory ranges that span across other nodes,
the mm driver can detect the memory node id incorrectly.
For example, with layout below
Node 0 address:
Node 1 address:
Note:
- Memory from low to high
- 0/1: Node id
- x:
Remove CONFIG_NODES_SPAN_OTHER_NODES as it's enabled
by default with NUMA.
Signed-off-by: Hoan Tran
---
arch/s390/Kconfig | 8
1 file changed, 8 deletions(-)
diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index bc88841..d86066e 100644
--- a/arch/s390/Kconfig
+++
Remove CONFIG_NODES_SPAN_OTHER_NODES as it's enabled
by default with NUMA.
Signed-off-by: Hoan Tran
---
arch/sparc/Kconfig | 9 -
1 file changed, 9 deletions(-)
diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig
index eb24cb1..6fc615e 100644
--- a/arch/sparc/Kconfig
+++
Remove CONFIG_NODES_SPAN_OTHER_NODES as it's enabled
by default. It is now enabled for x86(32 bit) configurations
and do not depend on X64_64_ACPI_NUMA config.
Because of that, on NUMA enabled system, early_pfn_in_nid()
function is called by memmap_init_zone() during boot-time.
It doesn't affect
Remove CONFIG_NODES_SPAN_OTHER_NODES as it's enabled by
default with NUMA.
Signed-off-by: Hoan Tran
---
arch/powerpc/Kconfig | 9 -
1 file changed, 9 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index e2a4121..4af2699 100644
--- a/arch/powerpc/Kconfig
+++
In NUMA layout which nodes have memory ranges that span across other nodes,
the mm driver can detect the memory node id incorrectly.
For example, with layout below
Node 0 address:
Node 1 address:
Note:
- Memory from low to high
- 0/1: Node id
- x:
> Remove duplicate memory allocation failure error messages.
A single message can be omitted here.
https://lkml.org/lkml/2017/10/17/870
https://lore.kernel.org/patchwork/patch/842101/
https://lore.kernel.org/linuxppc-dev/e16c8b7d-de3a-6c96-9af4-dd0551cca...@users.sourceforge.net/
Will this
(Sorry for the bounces, yes my smarthost mail setup breaks from time to time
and I had to cut the CC since it complained about the length.)
On Saturday, 28 March 2020 12:17:58 CET Christophe Leroy wrote:
>
> Le 27/03/2020 à 15:14, Andy Shevchenko a écrit :
>> On Fri, Mar 27, 2020 at 02:22:55PM
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. This
functionality is implemented in newly introduced
The PAPR standard[1][3] provides mechanisms to query the health and
performance stats of an NVDIMM via various hcalls as described in Ref[2].
Until now these stats were never available nor exposed to the user-space
tools like 'ndctl'. This is partly due to PAPR platform not having support
for ACPI
Add PAPR-scm family of DSM command-set to the white list of NVDIMM
command sets.
Signed-off-by: Vaibhav Jain
---
include/uapi/linux/ndctl.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/uapi/linux/ndctl.h b/include/uapi/linux/ndctl.h
index de5d90212409..99fb60600ef8 100644
---
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 exposed to user-space via
newly introduced dimm specific
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 receive.
The layout of the DSM commands as we expect from
Le 27/03/2020 à 15:14, Andy Shevchenko a écrit :
On Fri, Mar 27, 2020 at 02:22:55PM +0100, Arnd Bergmann wrote:
On Fri, Mar 27, 2020 at 2:15 PM Andy Shevchenko
wrote:
On Fri, Mar 27, 2020 at 03:10:26PM +0200, Andy Shevchenko wrote:
On Fri, Mar 27, 2020 at 01:54:33PM +0100, Arnd Bergmann
Hi Leonardo,
On 03/27/2020 03:51 PM, Leonardo Bras wrote:
Hello Christophe, thanks for the feedback.
I noticed an error in this patch and sent a v2, that can be seen here:
http://patchwork.ozlabs.org/patch/1262468/
Comments inline::
On Fri, 2020-03-27 at 07:50 +0100, Christophe Leroy wrote:
On Fri, 2020-03-27 at 16:12 +0100, Christophe Leroy wrote:
>
> Le 27/03/2020 à 10:03, Balamuruhan S a écrit :
> > On Fri, 2020-03-27 at 07:48 +0100, Christophe Leroy wrote:
> > > Le 26/03/2020 à 07:15, Balamuruhan S a écrit :
> > > > Data Cache Block Invalidate (dcbi) instruction was implemented
Hi Brian,
On Fri, Mar 27, 2020 at 09:48:38PM -0500, Brian Cain wrote:
> > Note 2: hexagon final image creation fails even w/o my patch
> What's the nature of the failure in "Note 2"?
drivers/base/firmware_loader/main.o: In function `fw_is_builtin_firmware':
26 matches
Mail list logo
