LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 33/38] cxlflash: Setup LISNs for master contexts
From: Uma Krishnan @ 2018-02-22 22:27 UTC (permalink / raw)
  To: linux-scsi, James Bottomley, Martin K. Petersen, Matthew R. Ochs,
	Manoj N. Kumar
  Cc: linuxppc-dev, Andrew Donnellan, Frederic Barrat,
	Christophe Lombard
In-Reply-To: <1519338010-51782-1-git-send-email-ukrishn@linux.vnet.ibm.com>

Similar to user contexts, master contexts also require that the per-context
LISN registers be programmed for certain AFUs. The mapped trigger page is
obtained from underlying transport and registered with AFU for each master
context.

Signed-off-by: Uma Krishnan <ukrishn@linux.vnet.ibm.com>
---
 drivers/scsi/cxlflash/main.c | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/drivers/scsi/cxlflash/main.c b/drivers/scsi/cxlflash/main.c
index 5d754d1..8c55fcd 100644
--- a/drivers/scsi/cxlflash/main.c
+++ b/drivers/scsi/cxlflash/main.c
@@ -1756,6 +1756,8 @@ static int init_global(struct cxlflash_cfg *cfg)
 	u64 wwpn[MAX_FC_PORTS];	/* wwpn of AFU ports */
 	int i = 0, num_ports = 0;
 	int rc = 0;
+	int j;
+	void *ctx;
 	u64 reg;
 
 	rc = read_vpd(cfg, &wwpn[0]);
@@ -1816,6 +1818,25 @@ static int init_global(struct cxlflash_cfg *cfg)
 		msleep(100);
 	}
 
+	if (afu_is_ocxl_lisn(afu)) {
+		/* Set up the LISN effective address for each master */
+		for (i = 0; i < afu->num_hwqs; i++) {
+			hwq = get_hwq(afu, i);
+			ctx = hwq->ctx_cookie;
+
+			for (j = 0; j < hwq->num_irqs; j++) {
+				reg = cfg->ops->get_irq_objhndl(ctx, j);
+				writeq_be(reg, &hwq->ctrl_map->lisn_ea[j]);
+			}
+
+			reg = hwq->ctx_hndl;
+			writeq_be(SISL_LISN_PASID(reg, reg),
+				  &hwq->ctrl_map->lisn_pasid[0]);
+			writeq_be(SISL_LISN_PASID(0UL, reg),
+				  &hwq->ctrl_map->lisn_pasid[1]);
+		}
+	}
+
 	/* Set up master's own CTX_CAP to allow real mode, host translation */
 	/* tables, afu cmds and read/write GSCSI cmds. */
 	/* First, unlock ctx_cap write by reading mbox */
-- 
2.1.0

^ permalink raw reply related

* [PATCH 34/38] cxlflash: Update synchronous interrupt status bits
From: Uma Krishnan @ 2018-02-22 22:28 UTC (permalink / raw)
  To: linux-scsi, James Bottomley, Martin K. Petersen, Matthew R. Ochs,
	Manoj N. Kumar
  Cc: linuxppc-dev, Andrew Donnellan, Frederic Barrat,
	Christophe Lombard
In-Reply-To: <1519338010-51782-1-git-send-email-ukrishn@linux.vnet.ibm.com>

The SISLite specification has been updated to define new synchronous
interrupt status bits. These bits are set by the AFU when a given PASID or
EA is bad and a synchronous interrupt is triggered.

The SISLite header file is updated to support these new bits. Note that
there are also some formatting updates to some of the existing bits to
allow all of the definitions to line up uniformly.

Signed-off-by: Uma Krishnan <ukrishn@linux.vnet.ibm.com>
---
 drivers/scsi/cxlflash/sislite.h | 35 +++++++++++++++++++++--------------
 1 file changed, 21 insertions(+), 14 deletions(-)

diff --git a/drivers/scsi/cxlflash/sislite.h b/drivers/scsi/cxlflash/sislite.h
index c08b9d3..874abce 100644
--- a/drivers/scsi/cxlflash/sislite.h
+++ b/drivers/scsi/cxlflash/sislite.h
@@ -258,23 +258,30 @@ struct sisl_host_map {
 				 * exit since there is no way to tell which
 				 * command caused the error.
 				 */
-#define SISL_ISTATUS_PERM_ERR_CMDROOM    0x0010ULL	/* b59, user error */
-#define SISL_ISTATUS_PERM_ERR_RCB_READ   0x0008ULL	/* b60, user error */
-#define SISL_ISTATUS_PERM_ERR_SA_WRITE   0x0004ULL	/* b61, user error */
-#define SISL_ISTATUS_PERM_ERR_RRQ_WRITE  0x0002ULL	/* b62, user error */
+#define SISL_ISTATUS_PERM_ERR_LISN_3_EA		0x0400ULL /* b53, user error */
+#define SISL_ISTATUS_PERM_ERR_LISN_2_EA		0x0200ULL /* b54, user error */
+#define SISL_ISTATUS_PERM_ERR_LISN_1_EA		0x0100ULL /* b55, user error */
+#define SISL_ISTATUS_PERM_ERR_LISN_3_PASID	0x0080ULL /* b56, user error */
+#define SISL_ISTATUS_PERM_ERR_LISN_2_PASID	0x0040ULL /* b57, user error */
+#define SISL_ISTATUS_PERM_ERR_LISN_1_PASID	0x0020ULL /* b58, user error */
+#define SISL_ISTATUS_PERM_ERR_CMDROOM		0x0010ULL /* b59, user error */
+#define SISL_ISTATUS_PERM_ERR_RCB_READ		0x0008ULL /* b60, user error */
+#define SISL_ISTATUS_PERM_ERR_SA_WRITE		0x0004ULL /* b61, user error */
+#define SISL_ISTATUS_PERM_ERR_RRQ_WRITE		0x0002ULL /* b62, user error */
 	/* Page in wait accessing RCB/IOASA/RRQ is reported in b63.
 	 * Same error in data/LXT/RHT access is reported via IOASA.
 	 */
-#define SISL_ISTATUS_TEMP_ERR_PAGEIN     0x0001ULL	/* b63, can be generated
-							 * only when AFU auto
-							 * retry is disabled.
-							 * If user can determine
-							 * the command that
-							 * caused the error, it
-							 * can be retried.
-							 */
-#define SISL_ISTATUS_UNMASK  (0x001FULL)	/* 1 means unmasked */
-#define SISL_ISTATUS_MASK    ~(SISL_ISTATUS_UNMASK)	/* 1 means masked */
+#define SISL_ISTATUS_TEMP_ERR_PAGEIN		0x0001ULL /* b63, can only be
+							   * generated when AFU
+							   * auto retry is
+							   * disabled. If user
+							   * can determine the
+							   * command that caused
+							   * the error, it can
+							   * be retried.
+							   */
+#define SISL_ISTATUS_UNMASK	(0x07FFULL)		/* 1 means unmasked */
+#define SISL_ISTATUS_MASK	~(SISL_ISTATUS_UNMASK)	/* 1 means masked */
 
 	__be64 intr_clear;
 	__be64 intr_mask;
-- 
2.1.0

^ permalink raw reply related

* [PATCH 35/38] cxlflash: Introduce OCXL context state machine
From: Uma Krishnan @ 2018-02-22 22:28 UTC (permalink / raw)
  To: linux-scsi, James Bottomley, Martin K. Petersen, Matthew R. Ochs,
	Manoj N. Kumar
  Cc: linuxppc-dev, Andrew Donnellan, Frederic Barrat,
	Christophe Lombard
In-Reply-To: <1519338010-51782-1-git-send-email-ukrishn@linux.vnet.ibm.com>

In order to protect the OCXL hardware contexts from getting clobbered,
a simple state machine is added to indicate when a context is in open,
close or start state. The expected states are validated throughout the
code to prevent illegal operations on a context. A mutex is added to
protect writes to the context state field.

Signed-off-by: Uma Krishnan <ukrishn@linux.vnet.ibm.com>
---
 drivers/scsi/cxlflash/ocxl_hw.c | 59 ++++++++++++++++++++++++++++++++++++++---
 drivers/scsi/cxlflash/ocxl_hw.h |  8 ++++++
 2 files changed, 64 insertions(+), 3 deletions(-)

diff --git a/drivers/scsi/cxlflash/ocxl_hw.c b/drivers/scsi/cxlflash/ocxl_hw.c
index 1044bee..535b21a 100644
--- a/drivers/scsi/cxlflash/ocxl_hw.c
+++ b/drivers/scsi/cxlflash/ocxl_hw.c
@@ -163,6 +163,16 @@ static struct file *ocxlflash_getfile(struct device *dev, const char *name,
 static void __iomem *ocxlflash_psa_map(void *ctx_cookie)
 {
 	struct ocxlflash_context *ctx = ctx_cookie;
+	struct device *dev = ctx->hw_afu->dev;
+
+	mutex_lock(&ctx->state_mutex);
+	if (ctx->state != STARTED) {
+		dev_err(dev, "%s: Context not started, state=%d\n", __func__,
+			ctx->state);
+		mutex_unlock(&ctx->state_mutex);
+		return NULL;
+	}
+	mutex_unlock(&ctx->state_mutex);
 
 	return ioremap(ctx->psn_phys, ctx->psn_size);
 }
@@ -343,6 +353,14 @@ static int start_context(struct ocxlflash_context *ctx)
 	int rc = 0;
 	u32 pid;
 
+	mutex_lock(&ctx->state_mutex);
+	if (ctx->state != OPENED) {
+		dev_err(dev, "%s: Context state invalid, state=%d\n",
+			__func__, ctx->state);
+		rc = -EINVAL;
+		goto out;
+	}
+
 	if (master) {
 		ctx->psn_size = acfg->global_mmio_size;
 		ctx->psn_phys = afu->gmmio_phys;
@@ -366,7 +384,10 @@ static int start_context(struct ocxlflash_context *ctx)
 			__func__, rc);
 		goto out;
 	}
+
+	ctx->state = STARTED;
 out:
+	mutex_unlock(&ctx->state_mutex);
 	return rc;
 }
 
@@ -396,7 +417,15 @@ static int ocxlflash_stop_context(void *ctx_cookie)
 	struct ocxl_afu_config *acfg = &afu->acfg;
 	struct pci_dev *pdev = afu->pdev;
 	struct device *dev = afu->dev;
-	int rc;
+	enum ocxlflash_ctx_state state;
+	int rc = 0;
+
+	mutex_lock(&ctx->state_mutex);
+	state = ctx->state;
+	ctx->state = CLOSED;
+	mutex_unlock(&ctx->state_mutex);
+	if (state != STARTED)
+		goto out;
 
 	rc = ocxl_config_terminate_pasid(pdev, acfg->dvsec_afu_control_pos,
 					 ctx->pe);
@@ -474,7 +503,9 @@ static void *ocxlflash_dev_context_init(struct pci_dev *pdev, void *afu_cookie)
 
 	spin_lock_init(&ctx->slock);
 	init_waitqueue_head(&ctx->wq);
+	mutex_init(&ctx->state_mutex);
 
+	ctx->state = OPENED;
 	ctx->pe = rc;
 	ctx->master = false;
 	ctx->mapping = NULL;
@@ -499,11 +530,23 @@ static void *ocxlflash_dev_context_init(struct pci_dev *pdev, void *afu_cookie)
 static int ocxlflash_release_context(void *ctx_cookie)
 {
 	struct ocxlflash_context *ctx = ctx_cookie;
+	struct device *dev;
 	int rc = 0;
 
 	if (!ctx)
 		goto out;
 
+	dev = ctx->hw_afu->dev;
+	mutex_lock(&ctx->state_mutex);
+	if (ctx->state >= STARTED) {
+		dev_err(dev, "%s: Context in use, state=%d\n", __func__,
+			ctx->state);
+		mutex_unlock(&ctx->state_mutex);
+		rc = -EBUSY;
+		goto out;
+	}
+	mutex_unlock(&ctx->state_mutex);
+
 	idr_remove(&ctx->hw_afu->idr, ctx->pe);
 	ocxlflash_release_mapping(ctx);
 	kfree(ctx);
@@ -939,7 +982,7 @@ static unsigned int afu_poll(struct file *file, struct poll_table_struct *poll)
 	spin_lock_irqsave(&ctx->slock, lock_flags);
 	if (ctx_event_pending(ctx))
 		mask |= POLLIN | POLLRDNORM;
-	else
+	else if (ctx->state == CLOSED)
 		mask |= POLLERR;
 	spin_unlock_irqrestore(&ctx->slock, lock_flags);
 
@@ -982,7 +1025,7 @@ static ssize_t afu_read(struct file *file, char __user *buf, size_t count,
 	for (;;) {
 		prepare_to_wait(&ctx->wq, &event_wait, TASK_INTERRUPTIBLE);
 
-		if (ctx_event_pending(ctx))
+		if (ctx_event_pending(ctx) || (ctx->state == CLOSED))
 			break;
 
 		if (file->f_flags & O_NONBLOCK) {
@@ -1068,12 +1111,22 @@ static int ocxlflash_mmap_fault(struct vm_fault *vmf)
 {
 	struct vm_area_struct *vma = vmf->vma;
 	struct ocxlflash_context *ctx = vma->vm_file->private_data;
+	struct device *dev = ctx->hw_afu->dev;
 	u64 mmio_area, offset;
 
 	offset = vmf->pgoff << PAGE_SHIFT;
 	if (offset >= ctx->psn_size)
 		return VM_FAULT_SIGBUS;
 
+	mutex_lock(&ctx->state_mutex);
+	if (ctx->state != STARTED) {
+		dev_err(dev, "%s: Context not started, state=%d\n",
+			__func__, ctx->state);
+		mutex_unlock(&ctx->state_mutex);
+		return VM_FAULT_SIGBUS;
+	}
+	mutex_unlock(&ctx->state_mutex);
+
 	mmio_area = ctx->psn_phys;
 	mmio_area += offset;
 
diff --git a/drivers/scsi/cxlflash/ocxl_hw.h b/drivers/scsi/cxlflash/ocxl_hw.h
index bdf9422..c23b681 100644
--- a/drivers/scsi/cxlflash/ocxl_hw.h
+++ b/drivers/scsi/cxlflash/ocxl_hw.h
@@ -45,6 +45,12 @@ struct ocxl_hw_afu {
 	int max_pasid;			/* Maximum number of contexts */
 };
 
+enum ocxlflash_ctx_state {
+	CLOSED,
+	OPENED,
+	STARTED
+};
+
 struct ocxlflash_context {
 	struct ocxl_hw_afu *hw_afu;	/* HW AFU back pointer */
 	struct address_space *mapping;	/* Mapping for pseudo filesystem */
@@ -56,6 +62,8 @@ struct ocxlflash_context {
 
 	spinlock_t slock;		/* Protects irq/fault/event updates */
 	wait_queue_head_t wq;		/* Wait queue for poll and interrupts */
+	struct mutex state_mutex;	/* Mutex to update context state */
+	enum ocxlflash_ctx_state state;	/* Context state */
 
 	struct ocxlflash_irqs *irqs;	/* Pointer to array of structures */
 	int num_irqs;			/* Number of interrupts */
-- 
2.1.0

^ permalink raw reply related

* [PATCH 36/38] cxlflash: Register for translation errors
From: Uma Krishnan @ 2018-02-22 22:28 UTC (permalink / raw)
  To: linux-scsi, James Bottomley, Martin K. Petersen, Matthew R. Ochs,
	Manoj N. Kumar
  Cc: linuxppc-dev, Andrew Donnellan, Frederic Barrat,
	Christophe Lombard
In-Reply-To: <1519338010-51782-1-git-send-email-ukrishn@linux.vnet.ibm.com>

While enabling a context on the link, a predefined callback can be
registered with the OCXL provider services to be notified on translation
errors. These errors can in turn be passed back to the user on a read
operation.

Signed-off-by: Uma Krishnan <ukrishn@linux.vnet.ibm.com>
---
 drivers/scsi/cxlflash/ocxl_hw.c | 31 +++++++++++++++++++++++++++++--
 drivers/scsi/cxlflash/ocxl_hw.h |  4 ++++
 2 files changed, 33 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/cxlflash/ocxl_hw.c b/drivers/scsi/cxlflash/ocxl_hw.c
index 535b21a..dc45ed2 100644
--- a/drivers/scsi/cxlflash/ocxl_hw.c
+++ b/drivers/scsi/cxlflash/ocxl_hw.c
@@ -335,6 +335,25 @@ static u64 ocxlflash_get_irq_objhndl(void *ctx_cookie, int irq)
 }
 
 /**
+ * ocxlflash_xsl_fault() - callback when translation error is triggered
+ * @data:	Private data provided at callback registration, the context.
+ * @addr:	Address that triggered the error.
+ * @dsisr:	Value of dsisr register.
+ */
+static void ocxlflash_xsl_fault(void *data, u64 addr, u64 dsisr)
+{
+	struct ocxlflash_context *ctx = data;
+
+	spin_lock(&ctx->slock);
+	ctx->fault_addr = addr;
+	ctx->fault_dsisr = dsisr;
+	ctx->pending_fault = true;
+	spin_unlock(&ctx->slock);
+
+	wake_up_all(&ctx->wq);
+}
+
+/**
  * start_context() - local routine to start a context
  * @ctx:	Adapter context to be started.
  *
@@ -378,7 +397,8 @@ static int start_context(struct ocxlflash_context *ctx)
 		mm = current->mm;
 	}
 
-	rc = ocxl_link_add_pe(link_token, ctx->pe, pid, 0, 0, mm, NULL, NULL);
+	rc = ocxl_link_add_pe(link_token, ctx->pe, pid, 0, 0, mm,
+			      ocxlflash_xsl_fault, ctx);
 	if (unlikely(rc)) {
 		dev_err(dev, "%s: ocxl_link_add_pe failed rc=%d\n",
 			__func__, rc);
@@ -512,6 +532,7 @@ static void *ocxlflash_dev_context_init(struct pci_dev *pdev, void *afu_cookie)
 	ctx->hw_afu = afu;
 	ctx->irq_bitmap = 0;
 	ctx->pending_irq = false;
+	ctx->pending_fault = false;
 out:
 	return ctx;
 err2:
@@ -957,7 +978,7 @@ static void *ocxlflash_create_afu(struct pci_dev *pdev)
  */
 static inline bool ctx_event_pending(struct ocxlflash_context *ctx)
 {
-	if (ctx->pending_irq)
+	if (ctx->pending_irq || ctx->pending_fault)
 		return true;
 
 	return false;
@@ -1062,6 +1083,12 @@ static ssize_t afu_read(struct file *file, char __user *buf, size_t count,
 		event.irq.irq = bit + 1;
 		if (bitmap_empty(&ctx->irq_bitmap, ctx->num_irqs))
 			ctx->pending_irq = false;
+	} else if (ctx->pending_fault) {
+		event.header.size += sizeof(struct cxl_event_data_storage);
+		event.header.type = CXL_EVENT_DATA_STORAGE;
+		event.fault.addr = ctx->fault_addr;
+		event.fault.dsisr = ctx->fault_dsisr;
+		ctx->pending_fault = false;
 	}
 
 	spin_unlock_irqrestore(&ctx->slock, lock_flags);
diff --git a/drivers/scsi/cxlflash/ocxl_hw.h b/drivers/scsi/cxlflash/ocxl_hw.h
index c23b681..c48465a 100644
--- a/drivers/scsi/cxlflash/ocxl_hw.h
+++ b/drivers/scsi/cxlflash/ocxl_hw.h
@@ -69,4 +69,8 @@ struct ocxlflash_context {
 	int num_irqs;			/* Number of interrupts */
 	bool pending_irq;		/* Pending interrupt on the context */
 	ulong irq_bitmap;		/* Bits indicating pending irq num */
+
+	u64 fault_addr;			/* Address that triggered the fault */
+	u64 fault_dsisr;		/* Value of dsisr register at fault */
+	bool pending_fault;		/* Pending translation fault */
 };
-- 
2.1.0

^ permalink raw reply related

* [PATCH 37/38] cxlflash: Support AFU reset
From: Uma Krishnan @ 2018-02-22 22:28 UTC (permalink / raw)
  To: linux-scsi, James Bottomley, Martin K. Petersen, Matthew R. Ochs,
	Manoj N. Kumar
  Cc: linuxppc-dev, Andrew Donnellan, Frederic Barrat,
	Christophe Lombard
In-Reply-To: <1519338010-51782-1-git-send-email-ukrishn@linux.vnet.ibm.com>

The cxlflash core driver resets the AFU when the master contexts are
created in the initialization or recovery paths. Today, the OCXL
provider service to perform this operation is pending implementation.
To avoid a crash due to a missing fop, log an error once and return
success to continue with execution.

Signed-off-by: Uma Krishnan <ukrishn@linux.vnet.ibm.com>
---
 drivers/scsi/cxlflash/ocxl_hw.c | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/drivers/scsi/cxlflash/ocxl_hw.c b/drivers/scsi/cxlflash/ocxl_hw.c
index dc45ed2..8a1a9fc 100644
--- a/drivers/scsi/cxlflash/ocxl_hw.c
+++ b/drivers/scsi/cxlflash/ocxl_hw.c
@@ -468,6 +468,22 @@ static int ocxlflash_stop_context(void *ctx_cookie)
 }
 
 /**
+ * ocxlflash_afu_reset() - reset the AFU
+ * @ctx_cookie:	Adapter context.
+ */
+static int ocxlflash_afu_reset(void *ctx_cookie)
+{
+	struct ocxlflash_context *ctx = ctx_cookie;
+	struct device *dev = ctx->hw_afu->dev;
+
+	/* Pending implementation from OCXL transport services */
+	dev_err_once(dev, "%s: afu_reset() fop not supported\n", __func__);
+
+	/* Silently return success until it is implemented */
+	return 0;
+}
+
+/**
  * ocxlflash_set_master() - sets the context as master
  * @ctx_cookie:	Adapter context to set as master.
  */
@@ -1393,6 +1409,7 @@ const struct cxlflash_backend_ops cxlflash_ocxl_ops = {
 	.get_irq_objhndl	= ocxlflash_get_irq_objhndl,
 	.start_context		= ocxlflash_start_context,
 	.stop_context		= ocxlflash_stop_context,
+	.afu_reset		= ocxlflash_afu_reset,
 	.set_master		= ocxlflash_set_master,
 	.get_context		= ocxlflash_get_context,
 	.dev_context_init	= ocxlflash_dev_context_init,
-- 
2.1.0

^ permalink raw reply related

* [PATCH 38/38] cxlflash: Enable OpenCXL operations
From: Uma Krishnan @ 2018-02-22 22:28 UTC (permalink / raw)
  To: linux-scsi, James Bottomley, Martin K. Petersen, Matthew R. Ochs,
	Manoj N. Kumar
  Cc: linuxppc-dev, Andrew Donnellan, Frederic Barrat,
	Christophe Lombard
In-Reply-To: <1519338010-51782-1-git-send-email-ukrishn@linux.vnet.ibm.com>

This commit enables the OpenCXL operations for the OpenCXL devices.

Signed-off-by: Uma Krishnan <ukrishn@linux.vnet.ibm.com>
---
 drivers/scsi/cxlflash/main.c | 9 +++++++--
 drivers/scsi/cxlflash/main.h | 1 +
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/cxlflash/main.c b/drivers/scsi/cxlflash/main.c
index 8c55fcd..42a95b7 100644
--- a/drivers/scsi/cxlflash/main.c
+++ b/drivers/scsi/cxlflash/main.c
@@ -3168,7 +3168,8 @@ static struct dev_dependent_vals dev_corsa_vals = { CXLFLASH_MAX_SECTORS,
 static struct dev_dependent_vals dev_flash_gt_vals = { CXLFLASH_MAX_SECTORS,
 					CXLFLASH_NOTIFY_SHUTDOWN };
 static struct dev_dependent_vals dev_briard_vals = { CXLFLASH_MAX_SECTORS,
-					CXLFLASH_NOTIFY_SHUTDOWN };
+					(CXLFLASH_NOTIFY_SHUTDOWN |
+					CXLFLASH_OCXL_DEV) };
 
 /*
  * PCI device binding table
@@ -3679,9 +3680,13 @@ static int cxlflash_probe(struct pci_dev *pdev,
 
 	cfg->init_state = INIT_STATE_NONE;
 	cfg->dev = pdev;
-	cfg->ops = &cxlflash_cxl_ops;
 	cfg->cxl_fops = cxlflash_cxl_fops;
 
+	if (ddv->flags & CXLFLASH_OCXL_DEV)
+		cfg->ops = &cxlflash_ocxl_ops;
+	else
+		cfg->ops = &cxlflash_cxl_ops;
+
 	/*
 	 * Promoted LUNs move to the top of the LUN table. The rest stay on
 	 * the bottom half. The bottom half grows from the end (index = 255),
diff --git a/drivers/scsi/cxlflash/main.h b/drivers/scsi/cxlflash/main.h
index ba0108a..6f1be62 100644
--- a/drivers/scsi/cxlflash/main.h
+++ b/drivers/scsi/cxlflash/main.h
@@ -97,6 +97,7 @@ struct dev_dependent_vals {
 	u64 flags;
 #define CXLFLASH_NOTIFY_SHUTDOWN	0x0000000000000001ULL
 #define CXLFLASH_WWPN_VPD_REQUIRED	0x0000000000000002ULL
+#define CXLFLASH_OCXL_DEV		0x0000000000000004ULL
 };
 
 struct asyc_intr_info {
-- 
2.1.0

^ permalink raw reply related

* Re: [PATCH 4.9 34/77] powerpc: fix build errors in stable tree
From: Michael Ellerman @ 2018-02-22 22:31 UTC (permalink / raw)
  To: Yves-Alexis Perez, Greg Kroah-Hartman, linux-kernel
  Cc: stable, Guenter Roeck, Nicholas Piggin, linuxppc-dev
In-Reply-To: <1519306335.2388.18.camel@debian.org>

Yves-Alexis Perez <corsac@debian.org> writes:
> On Fri, 2018-02-23 at 00:16 +1100, Michael Ellerman wrote:
>> With the patches I just sent, for pseries and powernv, the mitigation
>> should be in place. On machines with updated firmware we'll use the
>> hardware-assisted L1 flush, otherwise we fallback to doing it in
>> software.
>
> So as of 4.9.82 meltdown is *not* addressed on those arches, but it should be
> ok in 4.9.83 or 4.9.84 depending on when the patches are merged?

As of 4.9.82 *most* of the patches to do the mitigation have been
merged.

One of them was missed, due to it not applying (because it was actually
a back port to 4.4 that was sent) that is:

  222f20f14062 ("powerpc/64s: Simple RFI macro conversions")


That patch adds calls to do the L1D cache flush when returning to
user/guest, so it is important that it's missing, the mitigation is not
fully effective without that patch.

However, 4.9.82 *does* have a backport of:

  b8e90cb7bc04 ("powerpc/64: Convert the syscall exit path to use RFI_TO_USER/KERNEL")

So the syscall path is protected, which means any attack which uses
syscalls is likely to fail.

Because the data the attack is trying to read has to be in the L1D, you
can't write an attack that remains in userspace 100% of the time, you
have to enter the kernel and have the kernel load the target data into
the L1D for you. With the syscall flush in place you can't use a syscall
for that, you have to trigger some other kernel entry/exit, eg. a page
fault.

TLDR is with the syscall flush in place it's much harder to write an
attack.

Greg has already released 4.9.83, so hopefully 4.9.84 will be fully
protected.

Note also that 4.9.82/83 have a bug in the SLB miss handler that can
lead to hangs in userspace, fixed by the first patch I sent.

cheers

^ permalink raw reply

* Re: [PATCH] PCI/AER: Add a null check before eeh_ops->notify_resume callback.
From: Michael Ellerman @ 2018-02-22 22:34 UTC (permalink / raw)
  To: Vaibhav Jain, Russell Currey
  Cc: Vaibhav Jain, Frederic Barrat, linuxppc-dev,
	Benjamin Herrenschmidt, Bryant G . Ly
In-Reply-To: <20180222115803.21738-1-vaibhav@linux.vnet.ibm.com>

Vaibhav Jain <vaibhav@linux.vnet.ibm.com> writes:
> This patch puts a NULL check before branching to the address pointed
> to by eeh_ops->notify_resume in eeh_report_resume(). The callback
> is used to notify the arch EEH code that a pci device is back
> online.
>
> For PPC64 presently, only an implementation for pseries platform is
> available and not for powernv. Hence without this patch EEH recovery
> on all non-virtualized hosts is causing a kernel panic when
> CONFIG_PCI_IOV is set. The panic is usually is of the form:
>
> EEH: Notify device driver to resume
> Unable to handle kernel paging request for instruction fetch
> Faulting instruction address: 0x00000000
> Oops: Kernel access of bad area, sig: 11 [#1]
> <snip>
> LR eeh_report_resume+0x218/0x220
> Call Trace:
>  eeh_report_resume+0x1f0/0x220 (unreliable)
>  eeh_pe_dev_traverse+0x98/0x170
>  eeh_handle_normal_event+0x3f4/0x650
>  eeh_handle_event+0x188/0x380
>  eeh_event_handler+0x208/0x210
>  kthread+0x168/0x1b0
>  ret_from_kernel_thread+0x5c/0xb4
>
> Cc: Bryant G. Ly <bryantly@linux.vnet.ibm.com>
> Fixes: 856e1eb9bdd4("PCI/AER: Add uevents in AER and EEH error/resume")
> Signed-off-by: Vaibhav Jain <vaibhav@linux.vnet.ibm.com>

10 out of 10 for the change log!

But yeah this is already fixed in my fixes branch, thanks anyway.

cheers

^ permalink raw reply

* [PATCH 15/38] cxlflash: Support image reload policy modification
From: Uma Krishnan @ 2018-02-22 22:24 UTC (permalink / raw)
  To: linux-scsi, James Bottomley, Martin K. Petersen, Matthew R. Ochs,
	Manoj N. Kumar
  Cc: linuxppc-dev, Andrew Donnellan, Frederic Barrat,
	Christophe Lombard
In-Reply-To: <1519338010-51782-1-git-send-email-ukrishn@linux.vnet.ibm.com>

On a PERST, the AFU image can be reloaded or left intact. Provide means to
set this image reload policy.

Signed-off-by: Uma Krishnan <ukrishn@linux.vnet.ibm.com>
---
 drivers/scsi/cxlflash/ocxl_hw.c | 13 +++++++++++++
 drivers/scsi/cxlflash/ocxl_hw.h |  1 +
 2 files changed, 14 insertions(+)

diff --git a/drivers/scsi/cxlflash/ocxl_hw.c b/drivers/scsi/cxlflash/ocxl_hw.c
index 2dab547..6f78e71 100644
--- a/drivers/scsi/cxlflash/ocxl_hw.c
+++ b/drivers/scsi/cxlflash/ocxl_hw.c
@@ -252,6 +252,18 @@ static int ocxlflash_release_context(void *ctx_cookie)
 }
 
 /**
+ * ocxlflash_perst_reloads_same_image() - sets the image reload policy
+ * @afu_cookie:	Hardware AFU associated with the host.
+ * @image:	Whether to load the same image on PERST.
+ */
+static void ocxlflash_perst_reloads_same_image(void *afu_cookie, bool image)
+{
+	struct ocxl_hw_afu *afu = afu_cookie;
+
+	afu->perst_same_image = image;
+}
+
+/**
  * ocxlflash_destroy_afu() - destroy the AFU structure
  * @afu_cookie:	AFU to be freed.
  */
@@ -493,6 +505,7 @@ const struct cxlflash_backend_ops cxlflash_ocxl_ops = {
 	.get_context		= ocxlflash_get_context,
 	.dev_context_init	= ocxlflash_dev_context_init,
 	.release_context	= ocxlflash_release_context,
+	.perst_reloads_same_image = ocxlflash_perst_reloads_same_image,
 	.create_afu		= ocxlflash_create_afu,
 	.destroy_afu		= ocxlflash_destroy_afu,
 	.get_fd			= ocxlflash_get_fd,
diff --git a/drivers/scsi/cxlflash/ocxl_hw.h b/drivers/scsi/cxlflash/ocxl_hw.h
index 7f234b1..6d6e323 100644
--- a/drivers/scsi/cxlflash/ocxl_hw.h
+++ b/drivers/scsi/cxlflash/ocxl_hw.h
@@ -17,6 +17,7 @@ struct ocxl_hw_afu {
 	struct ocxlflash_context *ocxl_ctx; /* Host context */
 	struct pci_dev *pdev;		/* PCI device */
 	struct device *dev;		/* Generic device */
+	bool perst_same_image;		/* Same image loaded on perst */
 
 	struct ocxl_fn_config fcfg;	/* DVSEC config of the function */
 	struct ocxl_afu_config acfg;	/* AFU configuration data */
-- 
2.1.0

^ permalink raw reply related

* Re: [PATCH v3] watchdog: add SPDX identifiers for watchdog subsystem
From: Michael Ellerman @ 2018-02-22 22:38 UTC (permalink / raw)
  To: Marcus Folkesson, Wim Van Sebroeck, Guenter Roeck, Joel Stanley,
	Nicolas Ferre, Alexandre Belloni, Eric Anholt, Stefan Wahren,
	Florian Fainelli, Ray Jui, Scott Branden,
	bcm-kernel-feedback-list, Linus Walleij, Support Opensource,
	Baruch Siach, William Breathitt Gray, Jimmy Vance, Keguang Zhang,
	Joachim Eastwood, Tomas Winkler, Johannes Thumshirn,
	Andreas Werner, Carlo Caione, Kevin Hilman, Matthias Brugger,
	Wan ZongShun, Michal Simek, Vladimir Zapolskiy, Sylvain Lemieux,
	Kukjin Kim, Krzysztof Kozlowski, Zwane Mwaikambo, Jim Cromie,
	Barry Song, Patrice Chotard, Maxime Ripard, Chen-Yu Tsai,
	Marc Gonzalez, Mans Rullgard, Thierry Reding, Jonathan Hunter,
	Masahiro Yamada, Benjamin Herrenschmidt, Paul Mackerras, Jun Nie,
	Baoyou Xie, Shawn Guo
  Cc: Marcus Folkesson, linux-watchdog, linux-kernel, linux-arm-kernel,
	linux-rpi-kernel, adi-buildroot-devel, linux-mips, linux-amlogic,
	linux-mediatek, linux-samsung-soc, linux-tegra, linuxppc-dev,
	patches, Utz Bacher
In-Reply-To: <20180221122744.28300-1-marcus.folkesson@gmail.com>

Marcus Folkesson <marcus.folkesson@gmail.com> writes:
> - Add SPDX identifier
> - Remove boiler plate license text
> - If MODULE_LICENSE and boiler plate does not match, go for boiler plate
>   license
>
> Signed-off-by: Marcus Folkesson <marcus.folkesson@gmail.com>

<snip>

> diff --git a/drivers/watchdog/wdrtas.c b/drivers/watchdog/wdrtas.c
> index 0240c60d14e3..af07f746b7cc 100644
> --- a/drivers/watchdog/wdrtas.c
> +++ b/drivers/watchdog/wdrtas.c
> @@ -1,3 +1,4 @@
> +// SPDX-License-Identifier: GPL-2.0+
>  /*
>   * FIXME: add wdrtas_get_status and wdrtas_get_boot_status as soon as
>   * RTAS calls are available
> @@ -10,20 +11,6 @@
>   * device driver to exploit watchdog RTAS functions
>   *
>   * Authors : Utz Bacher <utz.bacher@de.ibm.com>
> - *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License as published by
> - * the Free Software Foundation; either version 2, or (at your option)
> - * any later version.
> - *
> - * This program is distributed in the hope that it will be useful,
> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> - * GNU General Public License for more details.
> - *
> - * You should have received a copy of the GNU General Public License
> - * along with this program; if not, write to the Free Software
> - * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
>   */

LGTM.

Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)

cheers

^ permalink raw reply

* Re: [PATCH] PCI/AER: Move pci_uevent_ers() out of pci.h
From: Bjorn Helgaas @ 2018-02-22 23:12 UTC (permalink / raw)
  To: Bryant G. Ly
  Cc: Michael Ellerman, bhelgaas, linux-pci, linuxppc-dev, torvalds,
	ruscur, jjalvare
In-Reply-To: <dcfc6411-20cf-5b3f-20c5-14167de54700@linux.vnet.ibm.com>

On Thu, Feb 08, 2018 at 09:05:45AM -0600, Bryant G. Ly wrote:
> 
> On 2/8/18 6:20 AM, Michael Ellerman wrote:
> 
> > There's no reason pci_uevent_ers() needs to be inline in pci.h, so
> > move it out to a C file.
> >
> > Given it's used by AER the obvious location would be somewhere in
> > drivers/pci/pcie/aer, but because it's also used by powerpc EEH code
> > unfortunately that doesn't work in the case where EEH is enabled but
> > PCIEPORTBUS is not.
> >
> > So for now put it in pci-driver.c, next to pci_uevent(), with an
> > appropriate #ifdef so it's not built if AER and EEH are both disabled.
> >
> > While we're moving it also fix up the kernel doc comment for @pdev to
> > be accurate.
> >
> > Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
> > Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
> > ---
> >  drivers/pci/pci-driver.c | 36 ++++++++++++++++++++++++++++++++++++
> >  include/linux/pci.h      | 38 +++-----------------------------------
> >  2 files changed, 39 insertions(+), 35 deletions(-)
> 
> Looks good, thanks for fixing it!
> 
> Signed-off-by: Bryant G. Ly <bryantly@linux.vnet.ibm.com>

This would normally be a "Reviewed-by" unless you actually
participated in developing the patch, and in that case, your
"Signed-off-by" would normally be included in the original posting.

What do you intend?  I'll be glad to add either.

Bjorn

^ permalink raw reply

* Re: [PATCH] PCI/AER: Move pci_uevent_ers() out of pci.h
From: Bjorn Helgaas @ 2018-02-22 23:12 UTC (permalink / raw)
  To: Michael Ellerman
  Cc: bhelgaas, linux-pci, linuxppc-dev, torvalds, ruscur, bryantly,
	jjalvare
In-Reply-To: <20180208122035.9305-1-mpe@ellerman.id.au>

On Thu, Feb 08, 2018 at 11:20:35PM +1100, Michael Ellerman wrote:
> There's no reason pci_uevent_ers() needs to be inline in pci.h, so
> move it out to a C file.
> 
> Given it's used by AER the obvious location would be somewhere in
> drivers/pci/pcie/aer, but because it's also used by powerpc EEH code
> unfortunately that doesn't work in the case where EEH is enabled but
> PCIEPORTBUS is not.
> 
> So for now put it in pci-driver.c, next to pci_uevent(), with an
> appropriate #ifdef so it's not built if AER and EEH are both disabled.
> 
> While we're moving it also fix up the kernel doc comment for @pdev to
> be accurate.
> 
> Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>

Applied to pci/aer for v4.17, thanks!

> ---
>  drivers/pci/pci-driver.c | 36 ++++++++++++++++++++++++++++++++++++
>  include/linux/pci.h      | 38 +++-----------------------------------
>  2 files changed, 39 insertions(+), 35 deletions(-)
> 
> diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
> index 3bed6beda051..f21e8b1bef80 100644
> --- a/drivers/pci/pci-driver.c
> +++ b/drivers/pci/pci-driver.c
> @@ -1517,6 +1517,42 @@ static int pci_uevent(struct device *dev, struct kobj_uevent_env *env)
>  	return 0;
>  }
>  
> +#if defined(CONFIG_PCIEAER) || defined(CONFIG_EEH)
> +/**
> + * pci_uevent_ers - emit a uevent during recovery path of pci device
> + * @pdev: pci device undergoing error recovery
> + * @err_type: type of error event
> + */
> +void pci_uevent_ers(struct pci_dev *pdev, enum pci_ers_result err_type)
> +{
> +	int idx = 0;
> +	char *envp[3];
> +
> +	switch (err_type) {
> +	case PCI_ERS_RESULT_NONE:
> +	case PCI_ERS_RESULT_CAN_RECOVER:
> +		envp[idx++] = "ERROR_EVENT=BEGIN_RECOVERY";
> +		envp[idx++] = "DEVICE_ONLINE=0";
> +		break;
> +	case PCI_ERS_RESULT_RECOVERED:
> +		envp[idx++] = "ERROR_EVENT=SUCCESSFUL_RECOVERY";
> +		envp[idx++] = "DEVICE_ONLINE=1";
> +		break;
> +	case PCI_ERS_RESULT_DISCONNECT:
> +		envp[idx++] = "ERROR_EVENT=FAILED_RECOVERY";
> +		envp[idx++] = "DEVICE_ONLINE=0";
> +		break;
> +	default:
> +		break;
> +	}
> +
> +	if (idx > 0) {
> +		envp[idx++] = NULL;
> +		kobject_uevent_env(&pdev->dev.kobj, KOBJ_CHANGE, envp);
> +	}
> +}
> +#endif
> +
>  static int pci_bus_num_vf(struct device *dev)
>  {
>  	return pci_num_vf(to_pci_dev(dev));
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index 024a1beda008..19c1dbcff0c6 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -2280,41 +2280,9 @@ static inline bool pci_is_thunderbolt_attached(struct pci_dev *pdev)
>  	return false;
>  }
>  
> -/**
> - * pci_uevent_ers - emit a uevent during recovery path of pci device
> - * @pdev: pci device to check
> - * @err_type: type of error event
> - *
> - */
> -static inline void pci_uevent_ers(struct pci_dev *pdev,
> -				  enum  pci_ers_result err_type)
> -{
> -	int idx = 0;
> -	char *envp[3];
> -
> -	switch (err_type) {
> -	case PCI_ERS_RESULT_NONE:
> -	case PCI_ERS_RESULT_CAN_RECOVER:
> -		envp[idx++] = "ERROR_EVENT=BEGIN_RECOVERY";
> -		envp[idx++] = "DEVICE_ONLINE=0";
> -		break;
> -	case PCI_ERS_RESULT_RECOVERED:
> -		envp[idx++] = "ERROR_EVENT=SUCCESSFUL_RECOVERY";
> -		envp[idx++] = "DEVICE_ONLINE=1";
> -		break;
> -	case PCI_ERS_RESULT_DISCONNECT:
> -		envp[idx++] = "ERROR_EVENT=FAILED_RECOVERY";
> -		envp[idx++] = "DEVICE_ONLINE=0";
> -		break;
> -	default:
> -		break;
> -	}
> -
> -	if (idx > 0) {
> -		envp[idx++] = NULL;
> -		kobject_uevent_env(&pdev->dev.kobj, KOBJ_CHANGE, envp);
> -	}
> -}
> +#if defined(CONFIG_PCIEAER) || defined(CONFIG_EEH)
> +void pci_uevent_ers(struct pci_dev *pdev, enum  pci_ers_result err_type);
> +#endif
>  
>  /* Provide the legacy pci_dma_* API */
>  #include <linux/pci-dma-compat.h>
> -- 
> 2.14.1
> 

^ permalink raw reply

* Re: [PATCH] powerpc/powernv: Turn on SCSI_AACRAID in powernv_defconfig
From: Stewart Smith @ 2018-02-23  0:16 UTC (permalink / raw)
  To: Michael Ellerman, Brian King, Guilherme G. Piccoli
  Cc: linuxppc-dev, dougmill@us.ibm.com
In-Reply-To: <87y3jkpt0p.fsf@concordia.ellerman.id.au>

Michael Ellerman <mpe@ellerman.id.au> writes:
> Brian King <brking@linux.vnet.ibm.com> writes:
>> On 09/03/2017 06:19 PM, Stewart Smith wrote:
>>> Michael Ellerman <mpe@ellerman.id.au> writes:
>>>>> 2. On a bare metal machine, if you set ipr.fast_reboot=1 on the skiboot
>>>>>    kernel, then we should also avoid resetting the ipr adapter, so ipr
>>>>>    init on the kernel being kexec booted from skiboot should be extremely fast. 
>>>>
>>>> OK, I didn't know that was an option, so that might help.
>>>>
>>>>> ...
>>>>> If you've got cases where ipr init is taking a long time, I'd be
>>>>> interested to know what scenarios are the most annoying to see if there
>>>>> is any opportunity to improve.
>>>>
>>>> Yeah booting bare metal is where I see it (not using ipr.fast_reboot).
>>> 
>>> Hrm... We should probably enable that by default for petitboot then.
>>> 
>>> It'd at least cut some time off booting straight through to OS.
>>
>> Agreed. I'd be interested to hear if that helps address the issue
>> Michael is seeing.
>>
>> You can easily test this by exiting to a petitboot shell:
>>
>> echo 1 > /sys/module/ipr/parameters/fast_reboot
>>
>> Then go back to petitboot and boot the OS.
>
> Just following up on this (!).
>
> This does work, and I've now been running it in my CI for about a month
> (~1000 boots) with no problems.
>
> You can also make it persistent by doing:
>
>   $ nvram -p ibm,skiboot --update-config bootargs="ipr.fast_reboot=1"

Okay, cool. https://github.com/open-power/op-build/pull/1900 will set it
in firmware - we may as well run with this and fix any bugs we find.

Any reason why it isn't the default behaviour?

-- 
Stewart Smith
OPAL Architect, IBM.

^ permalink raw reply

* Re: [PATCH] PCI/AER: Move pci_uevent_ers() out of pci.h
From: Michael Ellerman @ 2018-02-23  4:09 UTC (permalink / raw)
  To: Bjorn Helgaas
  Cc: bhelgaas, linux-pci, linuxppc-dev, torvalds, ruscur, bryantly,
	jjalvare
In-Reply-To: <20180222231251.GC14632@bhelgaas-glaptop.roam.corp.google.com>

Bjorn Helgaas <helgaas@kernel.org> writes:
> On Thu, Feb 08, 2018 at 11:20:35PM +1100, Michael Ellerman wrote:
>> There's no reason pci_uevent_ers() needs to be inline in pci.h, so
>> move it out to a C file.
>> 
>> Given it's used by AER the obvious location would be somewhere in
>> drivers/pci/pcie/aer, but because it's also used by powerpc EEH code
>> unfortunately that doesn't work in the case where EEH is enabled but
>> PCIEPORTBUS is not.
>> 
>> So for now put it in pci-driver.c, next to pci_uevent(), with an
>> appropriate #ifdef so it's not built if AER and EEH are both disabled.
>> 
>> While we're moving it also fix up the kernel doc comment for @pdev to
>> be accurate.
>> 
>> Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
>> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
>
> Applied to pci/aer for v4.17, thanks!

Thanks.

cheers

^ permalink raw reply

* Re: [PATCH] PCI/AER: Move pci_uevent_ers() out of pci.h
From: Michael Ellerman @ 2018-02-23  4:10 UTC (permalink / raw)
  To: Bjorn Helgaas, Bryant G. Ly
  Cc: bhelgaas, linux-pci, linuxppc-dev, torvalds, ruscur, jjalvare
In-Reply-To: <20180222231236.GB14632@bhelgaas-glaptop.roam.corp.google.com>

Bjorn Helgaas <helgaas@kernel.org> writes:

> On Thu, Feb 08, 2018 at 09:05:45AM -0600, Bryant G. Ly wrote:
>> 
>> On 2/8/18 6:20 AM, Michael Ellerman wrote:
>> 
>> > There's no reason pci_uevent_ers() needs to be inline in pci.h, so
>> > move it out to a C file.
>> >
>> > Given it's used by AER the obvious location would be somewhere in
>> > drivers/pci/pcie/aer, but because it's also used by powerpc EEH code
>> > unfortunately that doesn't work in the case where EEH is enabled but
>> > PCIEPORTBUS is not.
>> >
>> > So for now put it in pci-driver.c, next to pci_uevent(), with an
>> > appropriate #ifdef so it's not built if AER and EEH are both disabled.
>> >
>> > While we're moving it also fix up the kernel doc comment for @pdev to
>> > be accurate.
>> >
>> > Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
>> > Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
>> > ---
>> >  drivers/pci/pci-driver.c | 36 ++++++++++++++++++++++++++++++++++++
>> >  include/linux/pci.h      | 38 +++-----------------------------------
>> >  2 files changed, 39 insertions(+), 35 deletions(-)
>> 
>> Looks good, thanks for fixing it!
>> 
>> Signed-off-by: Bryant G. Ly <bryantly@linux.vnet.ibm.com>
>
> This would normally be a "Reviewed-by" unless you actually
> participated in developing the patch, and in that case, your
> "Signed-off-by" would normally be included in the original posting.
>
> What do you intend?  I'll be glad to add either.

I wrote the patch, so Bryant meant Reviewed-by or maybe Acked-by.

cheers

^ permalink raw reply

* Re: [PATCH 00/38] cxlflash: OpenCXL transport support
From: Andrew Donnellan @ 2018-02-23  4:13 UTC (permalink / raw)
  To: Uma Krishnan, linux-scsi, James Bottomley, Martin K. Petersen,
	Matthew R. Ochs, Manoj N. Kumar
  Cc: linuxppc-dev, Frederic Barrat, Christophe Lombard
In-Reply-To: <1519338010-51782-1-git-send-email-ukrishn@linux.vnet.ibm.com>

On 23/02/18 09:20, Uma Krishnan wrote:
> This patch series adds OpenCXL support to the cxlflash driver. With
> this support, new devices using the OpenCXL transport will be supported
> by the cxlflash driver along with the existing CXL devices. An effort is
> made to keep this transport specific function independent of the existing
> core driver that communicates with the AFU.

It's "OpenCAPI" for the standard, and "ocxl" for the driver - I'd rather 
not add "OpenCXL" to our already somewhat confusing proliferation of 
names :)

I'll try to review as much of the ocxl-specific stuff as I can get to, 
though I'm a bit busy with the OpenCAPI skiboot work and reviewing the 
libocxl userspace library at the moment.


Andrew

-- 
Andrew Donnellan              OzLabs, ADL Canberra
andrew.donnellan@au1.ibm.com  IBM Australia Limited

^ permalink raw reply

* Re: [PATCH 04/38] cxlflash: Introduce OpenCXL backend
From: Andrew Donnellan @ 2018-02-23  4:28 UTC (permalink / raw)
  To: Uma Krishnan, linux-scsi, James Bottomley, Martin K. Petersen,
	Matthew R. Ochs, Manoj N. Kumar
  Cc: linuxppc-dev, Frederic Barrat, Christophe Lombard
In-Reply-To: <1519338163-51928-1-git-send-email-ukrishn@linux.vnet.ibm.com>

On 23/02/18 09:22, Uma Krishnan wrote:
> Add initial infrastructure to support a new cxlflash transport, OpenCXL.
> 
> Claim a dependency on OpenCXL (OCXL) and add a new file, ocxl_hw.c, which
> will host the backend routines that are specific to OpenCXL.
> 
> Signed-off-by: Uma Krishnan <ukrishn@linux.vnet.ibm.com>

Is it necessary to depend on OCXL in all cases? IMHO it should be 
possible to build a cxl-only version without ocxl, though I don't feel 
very strongly on this.

-- 
Andrew Donnellan              OzLabs, ADL Canberra
andrew.donnellan@au1.ibm.com  IBM Australia Limited

^ permalink raw reply

* Re: powerpc: Revert support for ibm,drc-info devtree property
From: Michael Ellerman @ 2018-02-23  5:39 UTC (permalink / raw)
  To: Michael Bringmann, linuxppc-dev; +Cc: Nathan Fontenot, Michael Ellerman
In-Reply-To: <f5baf8d9-ece2-d3b8-2793-7701a1184c2a@linux.vnet.ibm.com>

On Tue, 2018-02-13 at 20:02:53 UTC, Michael Bringmann wrote:
> This reverts commit 02ef6dd8109b581343ebeb1c4c973513682535d6.
> 
> The earlier patch tried to enable support for a new property
> "ibm,drc-info" on powerpc systems.
> 
> Unfortunately, some errors in the associated patch set break things
> in some of the DLPAR operations.  In particular when attempting to
> hot-add a new CPU or set of CPUs, the original patch failed to
> properly calculate the available resources, and aborted the operation.
> In addition, the original set missed several opportunities to compress
> and reuse common code.
> 
> As the associated patch set was meant to provide an optimization of
> storage and performance of a set of device-tree properties for future
> systems with large amounts of resources, reverting just restores
> the previous behavior for existing systems.  It seems unnecessary
> to enable this feature and introduce the consequent problems in the
> field that it will cause at this time, so please revert it for now
> until testing of the corrections are finished properly.
> 
> Signed-off-by: Michael W. Bringmann <mwb@linux.vnet.ibm.com>

Applied to powerpc fixes, thanks.

https://git.kernel.org/powerpc/c/c7a3275e0f9e461bb8942132aa6914

cheers

^ permalink raw reply

* Re: bpf, powerpc: fix jit for seccomp_data access
From: Michael Ellerman @ 2018-02-23  5:39 UTC (permalink / raw)
  To: Mark Lord, Naveen N. Rao, Alexei Starovoitov, Daniel Borkmann,
	Kees Cook, Andy Lutomirski, Will Drewry
  Cc: linuxppc-dev
In-Reply-To: <2f428cf9-23f3-d1f1-1524-46d6faa17386@pobox.com>

On Tue, 2018-02-20 at 19:49:20 UTC, Mark Lord wrote:
> I am using SECCOMP to filter syscalls on a ppc32 platform,
> and noticed that the JIT compiler was failing on the BPF
> even though the interpreter was working fine.
> 
> The issue was that the compiler was missing one of the instructions
> used by SECCOMP, so here is a patch to enable JIT for that instruction.
> 
> Signed-Off-By:  Mark Lord <mlord@pobox.com>
> 
> --- old/arch/powerpc/net/bpf_jit_comp.c 2018-02-16 14:07:01.000000000 -0500
> +++ linux/arch/powerpc/net/bpf_jit_comp.c       2018-02-20 14:41:20.805227494 -0500
> @@ -329,6 +329,9 @@ static int bpf_jit_build_body(struct bpf
>                         BUILD_BUG_ON(FIELD_SIZEOF(struct sk_buff, len) != 4);
>                         PPC_LWZ_OFFS(r_A, r_skb, offsetof(struct sk_buff, len));
>                         break;
> +               case BPF_LDX | BPF_W | BPF_ABS: /* A = *((u32 *)(seccomp_data + K)); */
> +                       PPC_LWZ_OFFS(r_A, r_skb, K);
> +                       break;
>                 case BPF_LDX | BPF_W | BPF_LEN: /* X = skb->len; */
>                         PPC_LWZ_OFFS(r_X, r_skb, offsetof(struct sk_buff, len));
>                         break;

Applied to powerpc fixes, thanks.

https://git.kernel.org/powerpc/c/083b20907185b076f21c265b30fe5b

cheers

^ permalink raw reply

* Re: powerpc/pseries: Fix duplicate firmware feature for DRC_INFO
From: Michael Ellerman @ 2018-02-23  5:39 UTC (permalink / raw)
  To: Michael Ellerman, mwb, nfont; +Cc: linuxppc-dev
In-Reply-To: <20180221130523.27836-1-mpe@ellerman.id.au>

On Wed, 2018-02-21 at 13:05:23 UTC, Michael Ellerman wrote:
> We had a mid-air collision between two new firmware features, DRMEM_V2
> and DRC_INFO, and they ended up with the same value.
> 
> No one's actually reported any problems, presumably because the new
> firmware that supports both properties is not widely available, and
> the two properties tend to be enabled together.
> 
> Still if we ever had one enabled but not the other, the bugs that
> could result are many and varied. So fix it.
> 
> Fixes: 3f38000eda48 ("powerpc/firmware: Add definitions for new drc-info firmware feature")
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
> Reviewed-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>

Applied to powerpc fixes.

https://git.kernel.org/powerpc/c/5539d31a04b3b9ac5f55edb766f1d2

cheers

^ permalink raw reply

* Re: [PATCH v12 1/3] mm, powerpc, x86: define VM_PKEY_BITx bits if CONFIG_ARCH_HAS_PKEYS is enabled
From: kbuild test robot @ 2018-02-23  7:11 UTC (permalink / raw)
  To: Ram Pai
  Cc: kbuild-all, mpe, mingo, akpm, linuxppc-dev, linux-mm, x86,
	linux-arch, linux-kernel, dave.hansen, benh, paulus, khandual,
	aneesh.kumar, bsingharora, hbabu, mhocko, bauerman, ebiederm,
	linuxram, corbet, arnd, fweimer, msuchanek
In-Reply-To: <1519257138-23797-2-git-send-email-linuxram@us.ibm.com>

[-- Attachment #1: Type: text/plain, Size: 4584 bytes --]

Hi Ram,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v4.16-rc2 next-20180222]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]

url:    https://github.com/0day-ci/linux/commits/Ram-Pai/mm-x86-powerpc-Enhancements-to-Memory-Protection-Keys/20180223-042743
config: powerpc-allmodconfig (attached as .config)
compiler: powerpc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        make.cross ARCH=powerpc 

Note: the linux-review/Ram-Pai/mm-x86-powerpc-Enhancements-to-Memory-Protection-Keys/20180223-042743 HEAD c5692bca45543c242ffca15c811923e4c548ed19 builds fine.
      It only hurts bisectibility.

All error/warnings (new ones prefixed by >>):

   In file included from include/linux/pkeys.h:9:0,
                    from arch/powerpc/include/asm/mman.h:16,
                    from include/uapi/linux/mman.h:5,
                    from include/linux/mman.h:9,
                    from arch/powerpc/kernel/asm-offsets.c:22:
   arch/powerpc/include/asm/pkeys.h: In function 'pkey_to_vmflag_bits':
>> arch/powerpc/include/asm/pkeys.h:32:23: error: 'VM_PKEY_BIT4' undeclared (first use in this function); did you mean 'VM_PKEY_BIT0'?
           VM_PKEY_BIT3 | VM_PKEY_BIT4)
                          ^
>> arch/powerpc/include/asm/pkeys.h:42:41: note: in expansion of macro 'ARCH_VM_PKEY_FLAGS'
     return (((u64)pkey << VM_PKEY_SHIFT) & ARCH_VM_PKEY_FLAGS);
                                            ^~~~~~~~~~~~~~~~~~
   arch/powerpc/include/asm/pkeys.h:32:23: note: each undeclared identifier is reported only once for each function it appears in
           VM_PKEY_BIT3 | VM_PKEY_BIT4)
                          ^
>> arch/powerpc/include/asm/pkeys.h:42:41: note: in expansion of macro 'ARCH_VM_PKEY_FLAGS'
     return (((u64)pkey << VM_PKEY_SHIFT) & ARCH_VM_PKEY_FLAGS);
                                            ^~~~~~~~~~~~~~~~~~
   arch/powerpc/include/asm/pkeys.h: In function 'vmflag_to_pte_pkey_bits':
   arch/powerpc/include/asm/pkeys.h:54:16: error: 'VM_PKEY_BIT4' undeclared (first use in this function); did you mean 'VM_PKEY_BIT0'?
      ((vm_flags & VM_PKEY_BIT4) ? H_PTE_PKEY_BIT0 : 0x0UL));
                   ^~~~~~~~~~~~
                   VM_PKEY_BIT0
   arch/powerpc/include/asm/pkeys.h: In function 'vma_pkey':
>> arch/powerpc/include/asm/pkeys.h:32:23: error: 'VM_PKEY_BIT4' undeclared (first use in this function); did you mean 'VM_PKEY_BIT0'?
           VM_PKEY_BIT3 | VM_PKEY_BIT4)
                          ^
   arch/powerpc/include/asm/pkeys.h:61:26: note: in expansion of macro 'ARCH_VM_PKEY_FLAGS'
     return (vma->vm_flags & ARCH_VM_PKEY_FLAGS) >> VM_PKEY_SHIFT;
                             ^~~~~~~~~~~~~~~~~~
   make[2]: *** [arch/powerpc/kernel/asm-offsets.s] Error 1
   make[2]: Target '__build' not remade because of errors.
   make[1]: *** [prepare0] Error 2
   make[1]: Target 'prepare' not remade because of errors.
   make: *** [sub-make] Error 2

vim +32 arch/powerpc/include/asm/pkeys.h

4fb158f6 Ram Pai 2018-01-18  30  
4fb158f6 Ram Pai 2018-01-18  31  #define ARCH_VM_PKEY_FLAGS (VM_PKEY_BIT0 | VM_PKEY_BIT1 | VM_PKEY_BIT2 | \
4fb158f6 Ram Pai 2018-01-18 @32  			    VM_PKEY_BIT3 | VM_PKEY_BIT4)
4fb158f6 Ram Pai 2018-01-18  33  
013a91b3 Ram Pai 2018-01-18  34  /* Override any generic PKEY permission defines */
013a91b3 Ram Pai 2018-01-18  35  #define PKEY_DISABLE_EXECUTE   0x4
013a91b3 Ram Pai 2018-01-18  36  #define PKEY_ACCESS_MASK       (PKEY_DISABLE_ACCESS | \
013a91b3 Ram Pai 2018-01-18  37  				PKEY_DISABLE_WRITE  | \
013a91b3 Ram Pai 2018-01-18  38  				PKEY_DISABLE_EXECUTE)
013a91b3 Ram Pai 2018-01-18  39  
013a91b3 Ram Pai 2018-01-18  40  static inline u64 pkey_to_vmflag_bits(u16 pkey)
013a91b3 Ram Pai 2018-01-18  41  {
013a91b3 Ram Pai 2018-01-18 @42  	return (((u64)pkey << VM_PKEY_SHIFT) & ARCH_VM_PKEY_FLAGS);
013a91b3 Ram Pai 2018-01-18  43  }
013a91b3 Ram Pai 2018-01-18  44  

:::::: The code at line 32 was first introduced by commit
:::::: 4fb158f65ac5556b9b4a6f63f38272853ed99b22 powerpc: track allocation status of all pkeys

:::::: TO: Ram Pai <linuxram@us.ibm.com>
:::::: CC: Michael Ellerman <mpe@ellerman.id.au>

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 56627 bytes --]

^ permalink raw reply

* Re: [PATCH 0/5] PPC32/ioremap: Use memblock API to check for RAM
From: Christophe LEROY @ 2018-02-23  8:01 UTC (permalink / raw)
  To: Jonathan Neuschäfer, linuxppc-dev
  Cc: linux-kernel, Michael Ellerman, linux-mm, Joel Stanley
In-Reply-To: <20180222121516.23415-1-j.neuschaefer@gmx.net>



Le 22/02/2018 à 13:15, Jonathan Neuschäfer a écrit :
> This patchset solves the same problem as my previous one[1] but follows
> a rather different approach. Instead of implementing DISCONTIGMEM for
> PowerPC32, I simply switched the "is this RAM" check in __ioremap_caller
> to the existing page_is_ram function, and unified page_is_ram to search
> memblock.memory on PPC64 and PPC32.
> 
> The intended result is, as before, that my Wii can allocate the MMIO
> range of its GPIO controller, which was previously not possible, because
> the reserved memory hack (__allow_ioremap_reserved) didn't affect the
> API in kernel/resource.c.
> 
> Thanks to Christophe Leroy for reviewing the previous patchset.

I tested your new serie, it doesn't break my 8xx so it is OK for me.

Christophe

> 
> [1]: https://www.spinics.net/lists/kernel/msg2726786.html
> 
> Jonathan Neuschäfer (5):
>    powerpc: mm: Simplify page_is_ram by using memblock_is_memory
>    powerpc: mm: Use memblock API for PPC32 page_is_ram
>    powerpc/mm/32: Use page_is_ram to check for RAM
>    powerpc: wii: Don't rely on the reserved memory hack
>    powerpc/mm/32: Remove the reserved memory hack
> 
>   arch/powerpc/mm/init_32.c                |  5 -----
>   arch/powerpc/mm/mem.c                    | 12 +-----------
>   arch/powerpc/mm/mmu_decl.h               |  1 -
>   arch/powerpc/mm/pgtable_32.c             |  4 +---
>   arch/powerpc/platforms/embedded6xx/wii.c | 14 +-------------
>   5 files changed, 3 insertions(+), 33 deletions(-)
> 

^ permalink raw reply

* Re: [PATCH v12 1/3] mm, powerpc, x86: define VM_PKEY_BITx bits if CONFIG_ARCH_HAS_PKEYS is enabled
From: kbuild test robot @ 2018-02-23  8:06 UTC (permalink / raw)
  To: Ram Pai
  Cc: kbuild-all, mpe, mingo, akpm, linuxppc-dev, linux-mm, x86,
	linux-arch, linux-kernel, dave.hansen, benh, paulus, khandual,
	aneesh.kumar, bsingharora, hbabu, mhocko, bauerman, ebiederm,
	linuxram, corbet, arnd, fweimer, msuchanek
In-Reply-To: <1519257138-23797-2-git-send-email-linuxram@us.ibm.com>

[-- Attachment #1: Type: text/plain, Size: 3907 bytes --]

Hi Ram,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v4.16-rc2 next-20180223]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]

url:    https://github.com/0day-ci/linux/commits/Ram-Pai/mm-x86-powerpc-Enhancements-to-Memory-Protection-Keys/20180223-042743
config: powerpc-skiroot_defconfig (attached as .config)
compiler: powerpc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        make.cross ARCH=powerpc 

Note: the linux-review/Ram-Pai/mm-x86-powerpc-Enhancements-to-Memory-Protection-Keys/20180223-042743 HEAD c5692bca45543c242ffca15c811923e4c548ed19 builds fine.
      It only hurts bisectibility.

All errors (new ones prefixed by >>):

   In file included from include/linux/pkeys.h:9:0,
                    from arch/powerpc/include/asm/mman.h:16,
                    from include/uapi/linux/mman.h:5,
                    from include/linux/mman.h:9,
                    from arch/powerpc/kernel/asm-offsets.c:22:
   arch/powerpc/include/asm/pkeys.h: In function 'pkey_to_vmflag_bits':
>> arch/powerpc/include/asm/pkeys.h:32:23: error: 'VM_PKEY_BIT4' undeclared (first use in this function); did you mean 'VM_PKEY_BIT3'?
           VM_PKEY_BIT3 | VM_PKEY_BIT4)
                          ^
   arch/powerpc/include/asm/pkeys.h:42:41: note: in expansion of macro 'ARCH_VM_PKEY_FLAGS'
     return (((u64)pkey << VM_PKEY_SHIFT) & ARCH_VM_PKEY_FLAGS);
                                            ^~~~~~~~~~~~~~~~~~
   arch/powerpc/include/asm/pkeys.h:32:23: note: each undeclared identifier is reported only once for each function it appears in
           VM_PKEY_BIT3 | VM_PKEY_BIT4)
                          ^
   arch/powerpc/include/asm/pkeys.h:42:41: note: in expansion of macro 'ARCH_VM_PKEY_FLAGS'
     return (((u64)pkey << VM_PKEY_SHIFT) & ARCH_VM_PKEY_FLAGS);
                                            ^~~~~~~~~~~~~~~~~~
   arch/powerpc/include/asm/pkeys.h: In function 'vmflag_to_pte_pkey_bits':
   arch/powerpc/include/asm/pkeys.h:54:16: error: 'VM_PKEY_BIT4' undeclared (first use in this function); did you mean 'VM_PKEY_BIT3'?
      ((vm_flags & VM_PKEY_BIT4) ? H_PTE_PKEY_BIT0 : 0x0UL));
                   ^~~~~~~~~~~~
                   VM_PKEY_BIT3
   arch/powerpc/include/asm/pkeys.h: In function 'vma_pkey':
>> arch/powerpc/include/asm/pkeys.h:32:23: error: 'VM_PKEY_BIT4' undeclared (first use in this function); did you mean 'VM_PKEY_BIT3'?
           VM_PKEY_BIT3 | VM_PKEY_BIT4)
                          ^
   arch/powerpc/include/asm/pkeys.h:61:26: note: in expansion of macro 'ARCH_VM_PKEY_FLAGS'
     return (vma->vm_flags & ARCH_VM_PKEY_FLAGS) >> VM_PKEY_SHIFT;
                             ^~~~~~~~~~~~~~~~~~
   make[2]: *** [arch/powerpc/kernel/asm-offsets.s] Error 1
   make[2]: Target '__build' not remade because of errors.
   make[1]: *** [prepare0] Error 2
   make[1]: Target 'prepare' not remade because of errors.
   make: *** [sub-make] Error 2

vim +32 arch/powerpc/include/asm/pkeys.h

4fb158f6 Ram Pai 2018-01-18  30  
4fb158f6 Ram Pai 2018-01-18  31  #define ARCH_VM_PKEY_FLAGS (VM_PKEY_BIT0 | VM_PKEY_BIT1 | VM_PKEY_BIT2 | \
4fb158f6 Ram Pai 2018-01-18 @32  			    VM_PKEY_BIT3 | VM_PKEY_BIT4)
4fb158f6 Ram Pai 2018-01-18  33  

:::::: The code at line 32 was first introduced by commit
:::::: 4fb158f65ac5556b9b4a6f63f38272853ed99b22 powerpc: track allocation status of all pkeys

:::::: TO: Ram Pai <linuxram@us.ibm.com>
:::::: CC: Michael Ellerman <mpe@ellerman.id.au>

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 19998 bytes --]

^ permalink raw reply

* Hotplug + Reboot is crashing HPT guest with HPT resizing enabled
From: Bharata B Rao @ 2018-02-23  9:32 UTC (permalink / raw)
  To: linuxppc-dev; +Cc: David Gibson

[-- Attachment #1: Type: text/plain, Size: 882 bytes --]

Hi,

Rebooting a hash guest after hotplugging memory to it is crashing the
guest. This is seen only when HPT resizing is enabled. I see guest crashing
at multiple places, but this location is fairly commonly seen:

kernel BUG at mm/slub.c:3912!

Testing with latest guest kernel and ppc-for-2.12 branch of QEMU.

A bit of debugging shows me that when memory is added, the guest kernel
tries to resize HPT to a htab_shift value lesser than the value with which
the guest has booted. For eg. a 8GB guest boots with htab_shift of 26. When
1G is hot-added,
arch/powerpc/mm/hash_utils_64.c:resize_hpt_for_hotplug() ends up assigning
24 to target_hpt_shift. This looks suspicious as we are increasing the
memory, but kernel is asking for shrinking the HPT size. HPT resizing
requests fail though, but next reboot crashes the guest.

Regards,
Bharata.
-- 
http://raobharata.wordpress.com/

[-- Attachment #2: Type: text/html, Size: 1058 bytes --]

^ permalink raw reply

* Re: samples/seccomp/ broken when cross compiling s390, ppc allyesconfig
From: Michal Hocko @ 2018-02-23  9:12 UTC (permalink / raw)
  To: Kees Cook; +Cc: Michael Ellerman, Will Drewry, linux-s390, PowerPC, LKML
In-Reply-To: <CAGXu5jLLDOqoSn9usuA-pRLb5X=zK6MYdUVMPEh7x7oMgnU5cQ@mail.gmail.com>

On Thu 22-02-18 09:30:35, Kees Cook wrote:
> On Thu, Feb 22, 2018 at 5:07 AM, Michal Hocko <mhocko@kernel.org> wrote:
> > On Wed 14-02-18 09:14:47, Kees Cook wrote:
> > [...]
> >> I can send it through my seccomp tree via James Morris.
> >
> > Could you please do it?
> 
> Hi! Yes, sorry, this fell through the cracks. Now applied.

Thanks!

-- 
Michal Hocko
SUSE Labs

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox