On Wed, Aug 11, 2021 at 11:42 AM Jonathan Cameron
wrote:
>
> On Mon, 9 Aug 2021 15:28:46 -0700
> Dan Williams wrote:
>
> > Now that all of use sites of label data have been converted to nsl_*
> > helpers, introduce the CXL label format. The ->cxl flag in
> > nvdimm_drvdata indicates the label
On Wed, Aug 11, 2021 at 11:49 AM Jonathan Cameron
wrote:
>
> On Mon, 9 Aug 2021 15:28:35 -0700
> Dan Williams wrote:
>
> > The EFI definition of the labels represents the Linux "claim class" with
> > a GUID. The CXL definition of the labels stores the same identifier in
> > UUID byte order. In
On Tue, 2021-08-03 at 21:32 -0700, ira.we...@intel.com wrote:
> +static const pks_key_callback
> pks_key_callbacks[PKS_KEY_NR_CONSUMERS] = { 0 };
> +
> +bool handle_pks_key_callback(unsigned long address, bool write, u16
> key)
> +{
> + if (key > PKS_KEY_NR_CONSUMERS)
> +
On Wed, Aug 11, 2021 at 1:50 PM Ben Widawsky wrote:
>
> On Tue, 10 Aug 2021 15:40, Dan Williams wrote:
>
> [snip]
>
> >
> >The rationale is to be able to run cxl_test on a system that might
> >also have real CXL. For example I run this alongside the current QEMU
> >CXL model, and that results in
On Wed, Aug 11, 2021 at 12:18 PM Andy Shevchenko
wrote:
>
> On Wed, Aug 11, 2021 at 10:11:56AM -0700, Dan Williams wrote:
> > On Wed, Aug 11, 2021 at 9:59 AM Andy Shevchenko
> > wrote:
> > > On Wed, Aug 11, 2021 at 11:05:55AM +0300, Andy Shevchenko wrote:
> > > > On Mon, Aug 09, 2021 at
From: Darrick J. Wong
Now that we've moved iomap to the iterator model, rename this file to be
in sync with the functions contained inside of it.
Signed-off-by: Darrick J. Wong
---
fs/iomap/Makefile |2 +-
fs/iomap/iter.c |0
2 files changed, 1 insertion(+), 1 deletion(-)
rename
On Wed, Aug 11, 2021 at 10:11:56AM -0700, Dan Williams wrote:
> On Wed, Aug 11, 2021 at 9:59 AM Andy Shevchenko
> wrote:
> > On Wed, Aug 11, 2021 at 11:05:55AM +0300, Andy Shevchenko wrote:
> > > On Mon, Aug 09, 2021 at 03:28:40PM -0700, Dan Williams wrote:
> > > > In preparation for CXL labels
From: Christoph Hellwig
iomap_apply is unused now, so remove it.
Signed-off-by: Christoph Hellwig
[djwong: rebase this patch to preserve git history of iomap loop control]
Reviewed-by: Darrick J. Wong
Signed-off-by: Darrick J. Wong
---
fs/iomap/apply.c | 91
From: Christoph Hellwig
Rewrite the ->bmap implementation based on iomap_iter.
Signed-off-by: Christoph Hellwig
[djwong: restructure the loop to make its behavior a little clearer]
Reviewed-by: Darrick J. Wong
Signed-off-by: Darrick J. Wong
---
fs/iomap/fiemap.c | 31
From: Christoph Hellwig
The iomap_iter struct provides a convenient way to package up and
maintain all the arguments to the various mapping and operation
functions. It is operated on using the iomap_iter() function that
is called in loop until the whole range has been processed. Compared
to
On Wed, Aug 11, 2021 at 07:38:56AM +0200, Christoph Hellwig wrote:
> On Tue, Aug 10, 2021 at 05:31:18PM -0700, Darrick J. Wong wrote:
> > > +static inline void iomap_iter_done(struct iomap_iter *iter)
> >
> > I wonder why this is a separate function, since it only has debugging
> > warnings and
On Tue, 2021-08-03 at 21:32 -0700, ira.we...@intel.com wrote:
> +static int param_set_pks_fault_mode(const char *val, const struct
> kernel_param *kp)
> +{
> + int ret = -EINVAL;
> +
> + if (!sysfs_streq(val, "relaxed")) {
> + pks_fault_mode = PKS_MODE_RELAXED;
> +
Fix the NFIT parsing code to treat a 0 index in a SPA Range Structure as
a special case and not match Region Mapping Structures that use 0 to
indicate that they are not mapped. Without this fix some platform BIOS
descriptions of "virtual disk" ranges do not result in the pmem driver
attaching to
On Mon, 9 Aug 2021 15:28:35 -0700
Dan Williams wrote:
> The EFI definition of the labels represents the Linux "claim class" with
> a GUID. The CXL definition of the labels stores the same identifier in
> UUID byte order. In preparation for adding CXL label support, enable the
> claim class to
On Mon, 9 Aug 2021 15:28:30 -0700
Dan Williams wrote:
> In preparation for LIBNVDIMM to manage labels on CXL devices deploy
> helpers that abstract the label type from the implementation. The CXL
> label format is mostly similar to the EFI label format with concepts /
> fields added, like
On Mon, 9 Aug 2021 15:28:24 -0700
Dan Williams wrote:
> In preparation for CXL label support, which does not have the type-guid
> concept, wrap the existing users with nsl_set_type_guid, and
> nsl_validate_type_guid. Recall that the type-guid is a value in the ACPI
> NFIT table to indicate how
On Mon, 9 Aug 2021 15:28:19 -0700
Dan Williams wrote:
> In preparation for LIBNVDIMM to manage labels on CXL devices deploy
> helpers that abstract the label type from the implementation. The CXL
> label format is mostly similar to the EFI label format with concepts /
> fields added, like
On Mon, 9 Aug 2021 15:28:14 -0700
Dan Williams wrote:
> In preparation for LIBNVDIMM to manage labels on CXL devices deploy
> helpers that abstract the label type from the implementation. The CXL
> label format is mostly similar to the EFI label format with concepts /
> fields added, like
On Mon, 9 Aug 2021 15:27:57 -0700
Dan Williams wrote:
> In preparation to handle CXL labels with the same code that handles EFI
> labels, add a specific interleave-set-cookie validation helper
> rather than a getter since the CXL label type does not support this
> concept. The answer for CXL
On Mon, 9 Aug 2021 15:28:46 -0700
Dan Williams wrote:
> Now that all of use sites of label data have been converted to nsl_*
> helpers, introduce the CXL label format. The ->cxl flag in
> nvdimm_drvdata indicates the label format the device expects. A
> follow-on patch allows a bus provider to
On Mon, 9 Aug 2021 15:28:03 -0700
Dan Williams wrote:
> In preparation for LIBNVDIMM to manage labels on CXL devices deploy
> helpers that abstract the label type from the implementation. The CXL
> label format is mostly similar to the EFI label format with concepts /
> fields added, like
On Wed, Aug 11, 2021 at 10:27 AM Jonathan Cameron
wrote:
>
> On Mon, 9 Aug 2021 15:28:03 -0700
> Dan Williams wrote:
>
> > In preparation for LIBNVDIMM to manage labels on CXL devices deploy
> > helpers that abstract the label type from the implementation. The CXL
> > label format is mostly
On Wed, Aug 11, 2021 at 9:59 AM Andy Shevchenko
wrote:
>
> On Wed, Aug 11, 2021 at 11:05:55AM +0300, Andy Shevchenko wrote:
> > On Mon, Aug 09, 2021 at 03:28:40PM -0700, Dan Williams wrote:
> > > In preparation for CXL labels that move the uuid to a different offset
> > > in the label, add
On Wed, Aug 11, 2021 at 11:05:55AM +0300, Andy Shevchenko wrote:
> On Mon, Aug 09, 2021 at 03:28:40PM -0700, Dan Williams wrote:
> > In preparation for CXL labels that move the uuid to a different offset
> > in the label, add nsl_{ref,get,validate}_uuid(). These helpers use the
> > proper uuid_t
On Mon, Aug 09, 2021 at 03:28:40PM -0700, Dan Williams wrote:
> In preparation for CXL labels that move the uuid to a different offset
> in the label, add nsl_{ref,get,validate}_uuid(). These helpers use the
> proper uuid_t type. That type definition predated the libnvdimm
> subsystem, so now is
Now that the internals of mailbox operations are abstracted from the PCI
specifics a bulk of infrastructure can move to the core.
The CXL_PMEM driver intends to proxy LIBNVDIMM UAPI and driver requests
to the equivalent functionality provided by the CXL hardware mailbox
interface. In support of
26 matches
Mail list logo
