[PATCH RFC v2 15/18] dmaengine: idxd: add dedicated wq mdev type

[Dave Jiang]

Add the support code for "1dwq" mdev type. This mdev type follows the
standard VFIO mdev flow. The "1dwq" type will export a single dedicated wq
to the mdev. The dwq will have read-only configuration that is configured
by the host. The mdev type does not support PASID and SVA and will match
the stage 1 driver in functional support. For backward compatibility, the
mdev will maintain the DSA spec definition of this mdev type once the
commit goes upstream.

Signed-off-by: Dave Jiang 
Reviewed-by: Kevin Tian 
---
 drivers/dma/idxd/mdev.c |  142 ---
 1 file changed, 133 insertions(+), 9 deletions(-)

diff --git a/drivers/dma/idxd/mdev.c b/drivers/dma/idxd/mdev.c
index 01207ca42a79..744adfdc06cd 100644
--- a/drivers/dma/idxd/mdev.c
+++ b/drivers/dma/idxd/mdev.c
@@ -113,21 +113,58 @@ static void idxd_vdcm_release_work(struct work_struct 
*work)
__idxd_vdcm_release(vidxd);
 }
 
+static struct idxd_wq *find_any_dwq(struct idxd_device *idxd)
+{
+   int i;
+   struct idxd_wq *wq;
+   unsigned long flags;
+
+   spin_lock_irqsave(>dev_lock, flags);
+   for (i = 0; i < idxd->max_wqs; i++) {
+   wq = >wqs[i];
+
+   if (wq->state != IDXD_WQ_ENABLED)
+   continue;
+
+   if (!wq_dedicated(wq))
+   continue;
+
+   if (idxd_wq_refcount(wq) != 0)
+   continue;
+
+   spin_unlock_irqrestore(>dev_lock, flags);
+   mutex_lock(>wq_lock);
+   if (idxd_wq_refcount(wq)) {
+   spin_lock_irqsave(>dev_lock, flags);
+   continue;
+   }
+
+   idxd_wq_get(wq);
+   mutex_unlock(>wq_lock);
+   return wq;
+   }
+
+   spin_unlock_irqrestore(>dev_lock, flags);
+   return NULL;
+}
+
 static struct vdcm_idxd *vdcm_vidxd_create(struct idxd_device *idxd, struct 
mdev_device *mdev,
   struct vdcm_idxd_type *type)
 {
struct vdcm_idxd *vidxd;
struct idxd_wq *wq = NULL;
-   int i;
-
-   /* PLACEHOLDER, wq matching comes later */
+   int i, rc;
 
+   if (type->type == IDXD_MDEV_TYPE_1_DWQ)
+   wq = find_any_dwq(idxd);
if (!wq)
return ERR_PTR(-ENODEV);
 
vidxd = kzalloc(sizeof(*vidxd), GFP_KERNEL);
-   if (!vidxd)
-   return ERR_PTR(-ENOMEM);
+   if (!vidxd) {
+   rc = -ENOMEM;
+   goto err;
+   }
 
mutex_init(>dev_lock);
vidxd->idxd = idxd;
@@ -142,14 +179,23 @@ static struct vdcm_idxd *vdcm_vidxd_create(struct 
idxd_device *idxd, struct mdev
 
INIT_WORK(>vdev.release_work, idxd_vdcm_release_work);
idxd_vdcm_init(vidxd);
-   mutex_lock(>wq_lock);
-   idxd_wq_get(wq);
-   mutex_unlock(>wq_lock);
 
return vidxd;
+
+ err:
+   mutex_lock(>wq_lock);
+   idxd_wq_put(wq);
+   mutex_unlock(>wq_lock);
+   return ERR_PTR(rc);
 }
 
-static struct vdcm_idxd_type idxd_mdev_types[IDXD_MDEV_TYPES];
+static struct vdcm_idxd_type idxd_mdev_types[IDXD_MDEV_TYPES] = {
+   {
+   .name = "1dwq",
+   .description = "IDXD MDEV with 1 dedicated workqueue",
+   .type = IDXD_MDEV_TYPE_1_DWQ,
+   },
+};
 
 static struct vdcm_idxd_type *idxd_vdcm_find_vidxd_type(struct device *dev,
const char *name)
@@ -932,7 +978,85 @@ static long idxd_vdcm_ioctl(struct mdev_device *mdev, 
unsigned int cmd,
return rc;
 }
 
+static ssize_t name_show(struct kobject *kobj, struct device *dev, char *buf)
+{
+   struct vdcm_idxd_type *type;
+
+   type = idxd_vdcm_find_vidxd_type(dev, kobject_name(kobj));
+
+   if (type)
+   return sprintf(buf, "%s\n", type->description);
+
+   return -EINVAL;
+}
+static MDEV_TYPE_ATTR_RO(name);
+
+static int find_available_mdev_instances(struct idxd_device *idxd, struct 
vdcm_idxd_type *type)
+{
+   int count = 0, i;
+   unsigned long flags;
+
+   if (type->type != IDXD_MDEV_TYPE_1_DWQ)
+   return 0;
+
+   spin_lock_irqsave(>dev_lock, flags);
+   for (i = 0; i < idxd->max_wqs; i++) {
+   struct idxd_wq *wq;
+
+   wq = >wqs[i];
+   if (!is_idxd_wq_mdev(wq) || !wq_dedicated(wq) || 
idxd_wq_refcount(wq))
+   continue;
+
+   count++;
+   }
+   spin_unlock_irqrestore(>dev_lock, flags);
+
+   return count;
+}
+
+static ssize_t available_instances_show(struct kobject *kobj,
+   struct device *dev, char *buf)
+{
+   int count;
+   struct idxd_device *idxd = dev_get_drvdata(dev);
+   struct vdcm_idxd_type *type;
+
+   type = idxd_vdcm_find_vidxd_type(dev, kobject_name(kobj));
+   if (!type)
+   return -EINVAL;
+
+   count = 

[PATCH RFC v2 11/18] dmaengine: idxd: prep for virtual device commands

[Dave Jiang]

Update some of the device commands in order to support usage by the virtual
device commands emulated by the vdcm. Expose some of the commands' raw
status so the virtual commands can utilize them accordingly.

Signed-off-by: Dave Jiang 
Reviewed-by: Kevin Tian 
---
 drivers/dma/idxd/cdev.c   |2 +
 drivers/dma/idxd/device.c |   69 +
 drivers/dma/idxd/idxd.h   |8 +++--
 drivers/dma/idxd/irq.c|2 +
 drivers/dma/idxd/mdev.c   |2 +
 drivers/dma/idxd/sysfs.c  |8 +++--
 6 files changed, 56 insertions(+), 35 deletions(-)

diff --git a/drivers/dma/idxd/cdev.c b/drivers/dma/idxd/cdev.c
index ffeae646f947..90266c0bdef3 100644
--- a/drivers/dma/idxd/cdev.c
+++ b/drivers/dma/idxd/cdev.c
@@ -158,7 +158,7 @@ static int idxd_cdev_release(struct inode *node, struct 
file *filep)
if (rc < 0)
dev_err(dev, "wq disable pasid failed.\n");
}
-   idxd_wq_drain(wq);
+   idxd_wq_drain(wq, NULL);
}
 
if (ctx->sva)
diff --git a/drivers/dma/idxd/device.c b/drivers/dma/idxd/device.c
index 7443ffb5d3c3..6e9d27f59638 100644
--- a/drivers/dma/idxd/device.c
+++ b/drivers/dma/idxd/device.c
@@ -197,22 +197,25 @@ void idxd_wq_free_resources(struct idxd_wq *wq)
sbitmap_queue_free(>sbq);
 }
 
-int idxd_wq_enable(struct idxd_wq *wq)
+int idxd_wq_enable(struct idxd_wq *wq, u32 *status)
 {
struct idxd_device *idxd = wq->idxd;
struct device *dev = >pdev->dev;
-   u32 status;
+   u32 stat;
 
if (wq->state == IDXD_WQ_ENABLED) {
dev_dbg(dev, "WQ %d already enabled\n", wq->id);
return -ENXIO;
}
 
-   idxd_cmd_exec(idxd, IDXD_CMD_ENABLE_WQ, wq->id, );
+   idxd_cmd_exec(idxd, IDXD_CMD_ENABLE_WQ, wq->id, );
 
-   if (status != IDXD_CMDSTS_SUCCESS &&
-   status != IDXD_CMDSTS_ERR_WQ_ENABLED) {
-   dev_dbg(dev, "WQ enable failed: %#x\n", status);
+   if (status)
+   *status = stat;
+
+   if (stat != IDXD_CMDSTS_SUCCESS &&
+   stat != IDXD_CMDSTS_ERR_WQ_ENABLED) {
+   dev_dbg(dev, "WQ enable failed: %#x\n", stat);
return -ENXIO;
}
 
@@ -221,11 +224,11 @@ int idxd_wq_enable(struct idxd_wq *wq)
return 0;
 }
 
-int idxd_wq_disable(struct idxd_wq *wq)
+int idxd_wq_disable(struct idxd_wq *wq, u32 *status)
 {
struct idxd_device *idxd = wq->idxd;
struct device *dev = >pdev->dev;
-   u32 status, operand;
+   u32 stat, operand;
 
dev_dbg(dev, "Disabling WQ %d\n", wq->id);
 
@@ -235,10 +238,13 @@ int idxd_wq_disable(struct idxd_wq *wq)
}
 
operand = BIT(wq->id % 16) | ((wq->id / 16) << 16);
-   idxd_cmd_exec(idxd, IDXD_CMD_DISABLE_WQ, operand, );
+   idxd_cmd_exec(idxd, IDXD_CMD_DISABLE_WQ, operand, );
+
+   if (status)
+   *status = stat;
 
-   if (status != IDXD_CMDSTS_SUCCESS) {
-   dev_dbg(dev, "WQ disable failed: %#x\n", status);
+   if (stat != IDXD_CMDSTS_SUCCESS) {
+   dev_dbg(dev, "WQ disable failed: %#x\n", stat);
return -ENXIO;
}
 
@@ -247,20 +253,31 @@ int idxd_wq_disable(struct idxd_wq *wq)
return 0;
 }
 
-void idxd_wq_drain(struct idxd_wq *wq)
+int idxd_wq_drain(struct idxd_wq *wq, u32 *status)
 {
struct idxd_device *idxd = wq->idxd;
struct device *dev = >pdev->dev;
-   u32 operand;
+   u32 operand, stat;
 
if (wq->state != IDXD_WQ_ENABLED) {
dev_dbg(dev, "WQ %d in wrong state: %d\n", wq->id, wq->state);
-   return;
+   return 0;
}
 
dev_dbg(dev, "Draining WQ %d\n", wq->id);
operand = BIT(wq->id % 16) | ((wq->id / 16) << 16);
-   idxd_cmd_exec(idxd, IDXD_CMD_DRAIN_WQ, operand, NULL);
+   idxd_cmd_exec(idxd, IDXD_CMD_DRAIN_WQ, operand, );
+
+   if (status)
+   *status = stat;
+
+   if (stat != IDXD_CMDSTS_SUCCESS) {
+   dev_dbg(dev, "WQ drain failed: %#x\n", stat);
+   return -ENXIO;
+   }
+
+   dev_dbg(dev, "WQ %d drained\n", wq->id);
+   return 0;
 }
 
 int idxd_wq_map_portal(struct idxd_wq *wq)
@@ -287,11 +304,11 @@ void idxd_wq_unmap_portal(struct idxd_wq *wq)
devm_iounmap(dev, wq->portal);
 }
 
-int idxd_wq_abort(struct idxd_wq *wq)
+int idxd_wq_abort(struct idxd_wq *wq, u32 *status)
 {
struct idxd_device *idxd = wq->idxd;
struct device *dev = >pdev->dev;
-   u32 operand, status;
+   u32 operand, stat;
 
dev_dbg(dev, "Abort WQ %d\n", wq->id);
if (wq->state != IDXD_WQ_ENABLED) {
@@ -301,9 +318,13 @@ int idxd_wq_abort(struct idxd_wq *wq)
 
operand = BIT(wq->id % 16) | ((wq->id / 16) << 16);
dev_dbg(dev, "cmd: %u operand: %#x\n", IDXD_CMD_ABORT_WQ, operand);
-   idxd_cmd_exec(idxd, IDXD_CMD_ABORT_WQ, operand, );
-   if (status != 

[PATCH RFC v2 12/18] dmaengine: idxd: virtual device commands emulation

[Dave Jiang]

Add all the helper functions that supports the emulation of the commands
that are submitted to the device command register.

Signed-off-by: Dave Jiang 
Reviewed-by: Kevin Tian 
---
 drivers/dma/idxd/registers.h |   16 +-
 drivers/dma/idxd/vdev.c  |  398 ++
 2 files changed, 409 insertions(+), 5 deletions(-)

diff --git a/drivers/dma/idxd/registers.h b/drivers/dma/idxd/registers.h
index f8e4dd10a738..6531a40fad2e 100644
--- a/drivers/dma/idxd/registers.h
+++ b/drivers/dma/idxd/registers.h
@@ -115,7 +115,8 @@ union gencfg_reg {
 union genctrl_reg {
struct {
u32 softerr_int_en:1;
-   u32 rsvd:31;
+   u32 halt_state_int_en:1;
+   u32 rsvd:30;
};
u32 bits;
 } __packed;
@@ -137,6 +138,8 @@ enum idxd_device_status_state {
IDXD_DEVICE_STATE_HALT,
 };
 
+#define IDXD_GENSTATS_MASK 0x03
+
 enum idxd_device_reset_type {
IDXD_DEVICE_RESET_SOFTWARE = 0,
IDXD_DEVICE_RESET_FLR,
@@ -149,6 +152,7 @@ enum idxd_device_reset_type {
 #define IDXD_INTC_CMD  0x02
 #define IDXD_INTC_OCCUPY   0x04
 #define IDXD_INTC_PERFMON_OVFL 0x08
+#define IDXD_INTC_HALT_STATE   0x10
 
 #define IDXD_CMD_OFFSET0xa0
 union idxd_command_reg {
@@ -160,6 +164,7 @@ union idxd_command_reg {
};
u32 bits;
 } __packed;
+#define IDXD_CMD_INT_MASK  0x8000
 
 enum idxd_cmd {
IDXD_CMD_ENABLE_DEVICE = 1,
@@ -217,7 +222,7 @@ enum idxd_cmdsts_err {
/* disable device errors */
IDXD_CMDSTS_ERR_DIS_DEV_EN = 0x31,
/* disable WQ, drain WQ, abort WQ, reset WQ */
-   IDXD_CMDSTS_ERR_DEV_NOT_EN,
+   IDXD_CMDSTS_ERR_WQ_NOT_EN,
/* request interrupt handle */
IDXD_CMDSTS_ERR_INVAL_INT_IDX = 0x41,
IDXD_CMDSTS_ERR_NO_HANDLE,
@@ -353,4 +358,11 @@ union wqcfg {
 #define WQCFG_OFFSET(idxd_dev, n, ofs) ((idxd_dev)->wqcfg_offset +\
(n) * sizeof(union wqcfg) +\
sizeof(u32) * (ofs))
+
+enum idxd_wq_hw_state {
+   IDXD_WQ_DEV_DISABLED = 0,
+   IDXD_WQ_DEV_ENABLED,
+   IDXD_WQ_DEV_BUSY,
+};
+
 #endif
diff --git a/drivers/dma/idxd/vdev.c b/drivers/dma/idxd/vdev.c
index b4eace02199e..df99d0bce5e9 100644
--- a/drivers/dma/idxd/vdev.c
+++ b/drivers/dma/idxd/vdev.c
@@ -81,6 +81,18 @@ static void vidxd_report_error(struct vdcm_idxd *vidxd, 
unsigned int error)
}
 }
 
+static int idxd_get_mdev_pasid(struct mdev_device *mdev)
+{
+   struct iommu_domain *domain;
+   struct device *dev = mdev_dev(mdev);
+
+   domain = mdev_get_iommu_domain(dev);
+   if (!domain)
+   return -EINVAL;
+
+   return iommu_aux_get_pasid(domain, dev->parent);
+}
+
 int vidxd_mmio_write(struct vdcm_idxd *vidxd, u64 pos, void *buf, unsigned int 
size)
 {
u32 offset = pos & (vidxd->bar_size[0] - 1);
@@ -474,15 +486,395 @@ void vidxd_mmio_init(struct vdcm_idxd *vidxd)
 
 static void idxd_complete_command(struct vdcm_idxd *vidxd, enum 
idxd_cmdsts_err val)
 {
-   /* PLACEHOLDER */
+   u8 *bar0 = vidxd->bar0;
+   u32 *cmd = (u32 *)(bar0 + IDXD_CMD_OFFSET);
+   u32 *cmdsts = (u32 *)(bar0 + IDXD_CMDSTS_OFFSET);
+   u32 *intcause = (u32 *)(bar0 + IDXD_INTCAUSE_OFFSET);
+   struct mdev_device *mdev = vidxd->vdev.mdev;
+   struct device *dev = mdev_dev(mdev);
+
+   *cmdsts = val;
+   dev_dbg(dev, "%s: cmd: %#x  status: %#x\n", __func__, *cmd, val);
+
+   if (*cmd & IDXD_CMD_INT_MASK) {
+   *intcause |= IDXD_INTC_CMD;
+   vidxd_send_interrupt(vidxd, 0);
+   }
+}
+
+static void vidxd_enable(struct vdcm_idxd *vidxd)
+{
+   u8 *bar0 = vidxd->bar0;
+   union gensts_reg *gensts = (union gensts_reg *)(bar0 + 
IDXD_GENSTATS_OFFSET);
+   struct mdev_device *mdev = vidxd->vdev.mdev;
+   struct device *dev = mdev_dev(mdev);
+
+   dev_dbg(dev, "%s\n", __func__);
+   if (gensts->state == IDXD_DEVICE_STATE_ENABLED)
+   return idxd_complete_command(vidxd, 
IDXD_CMDSTS_ERR_DEV_ENABLED);
+
+   /* Check PCI configuration */
+   if (!(vidxd->cfg[PCI_COMMAND] & PCI_COMMAND_MASTER))
+   return idxd_complete_command(vidxd, 
IDXD_CMDSTS_ERR_BUSMASTER_EN);
+
+   gensts->state = IDXD_DEVICE_STATE_ENABLED;
+
+   return idxd_complete_command(vidxd, IDXD_CMDSTS_SUCCESS);
+}
+
+static void vidxd_disable(struct vdcm_idxd *vidxd)
+{
+   struct idxd_wq *wq;
+   union wqcfg *wqcfg;
+   u8 *bar0 = vidxd->bar0;
+   union gensts_reg *gensts = (union gensts_reg *)(bar0 + 
IDXD_GENSTATS_OFFSET);
+   struct mdev_device *mdev = vidxd->vdev.mdev;
+   struct device *dev = mdev_dev(mdev);
+   u32 status;
+
+   dev_dbg(dev, "%s\n", __func__);
+   if (gensts->state == IDXD_DEVICE_STATE_DISABLED) {
+   idxd_complete_command(vidxd, 

[PATCH RFC v2 13/18] dmaengine: idxd: ims setup for the vdcm

[Dave Jiang]

Add support for IMS enabling on the mediated device.

On the actual hardware the MSIX vector 0 is misc interrupt and handles
events such as administrative command completion, error reporting,
performance monitor overflow, and etc. The MSIX vectors 1...N
are used for descriptor completion interrupts. On the guest kernel,
the MSIX interrupts are backed by the mediated device through emulation
or IMS vectors. Vector 0 is handled through emulation by the host vdcm.
The vector 1 (and more may be supported later) is backed by IMS. IMS can
be setup with interrupt handlers via request_irq() just like MSIX
interrupts once the relevant IRQ domain is set with
dev_msi_domain_alloc_irqs().

Signed-off-by: Dave Jiang 
Reviewed-by: Kevin Tian 
---
 drivers/dma/Kconfig |1 
 drivers/dma/idxd/ims.c  |  142 +--
 drivers/dma/idxd/ims.h  |7 ++
 drivers/dma/idxd/vdev.c |   76 +
 4 files changed, 195 insertions(+), 31 deletions(-)

diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 69c1ae72df86..a19e5dbeab9b 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -311,6 +311,7 @@ config INTEL_IDXD_MDEV
depends on INTEL_IDXD
depends on VFIO_MDEV
depends on VFIO_MDEV_DEVICE
+   depends on DEV_MSI
 
 config INTEL_IOATDMA
tristate "Intel I/OAT DMA support"
diff --git a/drivers/dma/idxd/ims.c b/drivers/dma/idxd/ims.c
index bffc74c2b305..f9b7fbcb61df 100644
--- a/drivers/dma/idxd/ims.c
+++ b/drivers/dma/idxd/ims.c
@@ -7,22 +7,13 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include "registers.h"
 #include "idxd.h"
 #include "mdev.h"
-
-int vidxd_setup_ims_entries(struct vdcm_idxd *vidxd)
-{
-   /* PLACEHOLDER */
-   return 0;
-}
-
-int vidxd_free_ims_entries(struct vdcm_idxd *vidxd)
-{
-   /* PLACEHOLDER */
-   return 0;
-}
+#include "ims.h"
+#include "vdev.h"
 
 static void idxd_free_ims_index(struct idxd_device *idxd,
unsigned long ims_idx)
@@ -42,21 +33,65 @@ static int idxd_alloc_ims_index(struct idxd_device *idxd)
 
 static unsigned int idxd_ims_irq_mask(struct msi_desc *desc)
 {
-   // Filled out later when VDCM is introduced.
+   int ims_offset;
+   u32 mask_bits;
+   struct device *dev = desc->dev;
+   struct mdev_device *mdev = mdev_from_dev(dev);
+   struct vdcm_idxd *vidxd = mdev_get_drvdata(mdev);
+   struct idxd_device *idxd = vidxd->idxd;
+   void __iomem *base;
+   int ims_id = desc->platform.msi_index;
 
-   return 0;
+   dev_dbg(dev, "idxd irq mask: %d\n", ims_id);
+
+   ims_offset = idxd->ims_offset + vidxd->ims_index[ims_id] * 0x10;
+   base = idxd->reg_base + ims_offset;
+   mask_bits = ioread32(base + IMS_ENTRY_VECTOR_CTRL);
+   mask_bits |= IMS_ENTRY_CTRL_MASKBIT;
+   iowrite32(mask_bits, base + IMS_ENTRY_VECTOR_CTRL);
+
+   return mask_bits;
 }
 
 static unsigned int idxd_ims_irq_unmask(struct msi_desc *desc)
 {
-   // Filled out later when VDCM is introduced.
+   int ims_offset;
+   u32 mask_bits;
+   struct device *dev = desc->dev;
+   struct mdev_device *mdev = mdev_from_dev(dev);
+   struct vdcm_idxd *vidxd = mdev_get_drvdata(mdev);
+   struct idxd_device *idxd = vidxd->idxd;
+   void __iomem *base;
+   int ims_id = desc->platform.msi_index;
 
-   return 0;
+   dev_dbg(dev, "idxd irq unmask: %d\n", ims_id);
+
+   ims_offset = idxd->ims_offset + vidxd->ims_index[ims_id] * 0x10;
+   base = idxd->reg_base + ims_offset;
+   mask_bits = ioread32(base + IMS_ENTRY_VECTOR_CTRL);
+   mask_bits &= ~IMS_ENTRY_CTRL_MASKBIT;
+   iowrite32(mask_bits, base + IMS_ENTRY_VECTOR_CTRL);
+
+   return mask_bits;
 }
 
 static void idxd_ims_write_msg(struct msi_desc *desc, struct msi_msg *msg)
 {
-   // Filled out later when VDCM is introduced.
+   int ims_offset;
+   struct device *dev = desc->dev;
+   struct mdev_device *mdev = mdev_from_dev(dev);
+   struct vdcm_idxd *vidxd = mdev_get_drvdata(mdev);
+   struct idxd_device *idxd = vidxd->idxd;
+   void __iomem *base;
+   int ims_id = desc->platform.msi_index;
+
+   dev_dbg(dev, "ims_write: %d %x\n", ims_id, msg->address_lo);
+
+   ims_offset = idxd->ims_offset + vidxd->ims_index[ims_id] * 0x10;
+   base = idxd->reg_base + ims_offset;
+   iowrite32(msg->address_lo, base + IMS_ENTRY_LOWER_ADDR);
+   iowrite32(msg->address_hi, base + IMS_ENTRY_UPPER_ADDR);
+   iowrite32(msg->data, base + IMS_ENTRY_DATA);
 }
 
 static struct platform_msi_ops idxd_ims_ops  = {
@@ -64,3 +99,76 @@ static struct platform_msi_ops idxd_ims_ops  = {
.irq_unmask = idxd_ims_irq_unmask,
.write_msg  = idxd_ims_write_msg,
 };
+
+int vidxd_free_ims_entries(struct vdcm_idxd *vidxd)
+{
+   struct idxd_device *idxd = vidxd->idxd;
+   struct ims_irq_entry *irq_entry;
+   struct 

[PATCH RFC v2 09/18] dmaengine: idxd: add basic mdev registration and helper functions

[Dave Jiang]

Create a mediated device through the VFIO mediated device framework. The
mdev framework allows creation of an mediated device by the driver with
portion of the device's resources. The driver will emulate the slow path
such as the PCI config space, MMIO bar, and the command registers. The
descriptor submission portal(s) will be mmaped to the guest in order to
submit descriptors directly by the guest kernel or apps. The mediated
device support code in the idxd will be referred to as the Virtual
Device Composition Module (vdcm). Add basic plumbing to fill out the
mdev_parent_ops struct that VFIO mdev requires to support a mediated
device.

Signed-off-by: Dave Jiang 
Reviewed-by: Kevin Tian 
---
 drivers/dma/Kconfig   |6 
 drivers/dma/idxd/Makefile |4 
 drivers/dma/idxd/idxd.h   |   11 +
 drivers/dma/idxd/ims.c|   13 +
 drivers/dma/idxd/ims.h|   10 
 drivers/dma/idxd/init.c   |   11 +
 drivers/dma/idxd/mdev.c   |  980 +
 drivers/dma/idxd/mdev.h   |  118 +
 drivers/dma/idxd/vdev.c   |   76 +++
 drivers/dma/idxd/vdev.h   |   19 +
 10 files changed, 1247 insertions(+), 1 deletion(-)
 create mode 100644 drivers/dma/idxd/ims.h
 create mode 100644 drivers/dma/idxd/mdev.c
 create mode 100644 drivers/dma/idxd/mdev.h
 create mode 100644 drivers/dma/idxd/vdev.c
 create mode 100644 drivers/dma/idxd/vdev.h

diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 6a908785a5f7..69c1ae72df86 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -306,6 +306,12 @@ config INTEL_IDXD_SVM
depends on PCI_PASID
depends on PCI_IOV
 
+config INTEL_IDXD_MDEV
+   bool "IDXD VFIO Mediated Device Support"
+   depends on INTEL_IDXD
+   depends on VFIO_MDEV
+   depends on VFIO_MDEV_DEVICE
+
 config INTEL_IOATDMA
tristate "Intel I/OAT DMA support"
depends on PCI && X86_64
diff --git a/drivers/dma/idxd/Makefile b/drivers/dma/idxd/Makefile
index d1519b9d1dd0..18622f81eb3f 100644
--- a/drivers/dma/idxd/Makefile
+++ b/drivers/dma/idxd/Makefile
@@ -1,2 +1,4 @@
 obj-$(CONFIG_INTEL_IDXD) += idxd.o
-idxd-y := init.o irq.o device.o sysfs.o submit.o dma.o cdev.o ims.o
+idxd-y := init.o irq.o device.o sysfs.o submit.o dma.o cdev.o
+
+idxd-$(CONFIG_INTEL_IDXD_MDEV) += ims.o mdev.o vdev.o
diff --git a/drivers/dma/idxd/idxd.h b/drivers/dma/idxd/idxd.h
index 438d6478a3f8..9588872cd273 100644
--- a/drivers/dma/idxd/idxd.h
+++ b/drivers/dma/idxd/idxd.h
@@ -121,6 +121,7 @@ struct idxd_wq {
struct sbitmap_queue sbq;
struct dma_chan dma_chan;
char name[WQ_NAME_SIZE + 1];
+   struct list_head vdcm_list;
 };
 
 struct idxd_engine {
@@ -153,6 +154,7 @@ enum idxd_device_flag {
IDXD_FLAG_CMD_RUNNING,
IDXD_FLAG_PASID_ENABLED,
IDXD_FLAG_SIOV_SUPPORTED,
+   IDXD_FLAG_MDEV_ENABLED,
 };
 
 struct idxd_device {
@@ -245,6 +247,11 @@ static inline bool device_pasid_enabled(struct idxd_device 
*idxd)
return test_bit(IDXD_FLAG_PASID_ENABLED, >flags);
 }
 
+static inline bool device_mdev_enabled(struct idxd_device *idxd)
+{
+   return test_bit(IDXD_FLAG_MDEV_ENABLED, >flags);
+}
+
 enum idxd_portal_prot {
IDXD_PORTAL_UNLIMITED = 0,
IDXD_PORTAL_LIMITED,
@@ -363,4 +370,8 @@ int idxd_cdev_get_major(struct idxd_device *idxd);
 int idxd_wq_add_cdev(struct idxd_wq *wq);
 void idxd_wq_del_cdev(struct idxd_wq *wq);
 
+/* mdev */
+int idxd_mdev_host_init(struct idxd_device *idxd);
+void idxd_mdev_host_release(struct idxd_device *idxd);
+
 #endif
diff --git a/drivers/dma/idxd/ims.c b/drivers/dma/idxd/ims.c
index 5fece66122a2..bffc74c2b305 100644
--- a/drivers/dma/idxd/ims.c
+++ b/drivers/dma/idxd/ims.c
@@ -10,6 +10,19 @@
 #include 
 #include "registers.h"
 #include "idxd.h"
+#include "mdev.h"
+
+int vidxd_setup_ims_entries(struct vdcm_idxd *vidxd)
+{
+   /* PLACEHOLDER */
+   return 0;
+}
+
+int vidxd_free_ims_entries(struct vdcm_idxd *vidxd)
+{
+   /* PLACEHOLDER */
+   return 0;
+}
 
 static void idxd_free_ims_index(struct idxd_device *idxd,
unsigned long ims_idx)
diff --git a/drivers/dma/idxd/ims.h b/drivers/dma/idxd/ims.h
new file mode 100644
index ..3d823606e3a3
--- /dev/null
+++ b/drivers/dma/idxd/ims.h
@@ -0,0 +1,10 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/* Copyright(c) 2019,2020 Intel Corporation. All rights rsvd. */
+
+#ifndef _IDXD_IMS_H_
+#define _IDXD_IMS_H_
+
+int vidxd_setup_ims_entries(struct vdcm_idxd *vidxd);
+int vidxd_free_ims_entries(struct vdcm_idxd *vidxd);
+
+#endif
diff --git a/drivers/dma/idxd/init.c b/drivers/dma/idxd/init.c
index 3e2c7ac83daf..639ca74ae1f8 100644
--- a/drivers/dma/idxd/init.c
+++ b/drivers/dma/idxd/init.c
@@ -211,6 +211,7 @@ static int idxd_setup_internals(struct idxd_device *idxd)
wq->idxd = idxd;
mutex_init(>wq_lock);
wq->idxd_cdev.minor = -1;
+   INIT_LIST_HEAD(>vdcm_list);
}
 
for (i = 0; i 

[PATCH RFC v2 08/18] dmaengine: idxd: add device support functions in prep for mdev

[Dave Jiang]

Add device support helper functions in preparation of adding VFIO
mdev support.

Signed-off-by: Dave Jiang 
Reviewed-by: Kevin Tian 
---
 drivers/dma/idxd/device.c |   61 +
 drivers/dma/idxd/idxd.h   |4 +++
 2 files changed, 65 insertions(+)

diff --git a/drivers/dma/idxd/device.c b/drivers/dma/idxd/device.c
index 2b4e8ab99ebd..7443ffb5d3c3 100644
--- a/drivers/dma/idxd/device.c
+++ b/drivers/dma/idxd/device.c
@@ -287,6 +287,30 @@ void idxd_wq_unmap_portal(struct idxd_wq *wq)
devm_iounmap(dev, wq->portal);
 }
 
+int idxd_wq_abort(struct idxd_wq *wq)
+{
+   struct idxd_device *idxd = wq->idxd;
+   struct device *dev = >pdev->dev;
+   u32 operand, status;
+
+   dev_dbg(dev, "Abort WQ %d\n", wq->id);
+   if (wq->state != IDXD_WQ_ENABLED) {
+   dev_dbg(dev, "WQ %d not active\n", wq->id);
+   return -ENXIO;
+   }
+
+   operand = BIT(wq->id % 16) | ((wq->id / 16) << 16);
+   dev_dbg(dev, "cmd: %u operand: %#x\n", IDXD_CMD_ABORT_WQ, operand);
+   idxd_cmd_exec(idxd, IDXD_CMD_ABORT_WQ, operand, );
+   if (status != IDXD_CMDSTS_SUCCESS) {
+   dev_dbg(dev, "WQ abort failed: %#x\n", status);
+   return -ENXIO;
+   }
+
+   dev_dbg(dev, "WQ %d aborted\n", wq->id);
+   return 0;
+}
+
 int idxd_wq_set_pasid(struct idxd_wq *wq, int pasid)
 {
struct idxd_device *idxd = wq->idxd;
@@ -366,6 +390,32 @@ void idxd_wq_disable_cleanup(struct idxd_wq *wq)
}
 }
 
+void idxd_wq_setup_pasid(struct idxd_wq *wq, int pasid)
+{
+   struct idxd_device *idxd = wq->idxd;
+   int offset;
+
+   lockdep_assert_held(>dev_lock);
+
+   /* PASID fields are 8 bytes into the WQCFG register */
+   offset = idxd->wqcfg_offset + wq->id * 32 + 8;
+   wq->wqcfg.pasid = pasid;
+   iowrite32(wq->wqcfg.bits[2], idxd->reg_base + offset);
+}
+
+void idxd_wq_setup_priv(struct idxd_wq *wq, int priv)
+{
+   struct idxd_device *idxd = wq->idxd;
+   int offset;
+
+   lockdep_assert_held(>dev_lock);
+
+   /* priv field is 8 bytes into the WQCFG register */
+   offset = idxd->wqcfg_offset + wq->id * 32 + 8;
+   wq->wqcfg.priv = !!priv;
+   iowrite32(wq->wqcfg.bits[2], idxd->reg_base + offset);
+}
+
 /* Device control bits */
 static inline bool idxd_is_enabled(struct idxd_device *idxd)
 {
@@ -502,6 +552,17 @@ void idxd_device_drain_pasid(struct idxd_device *idxd, int 
pasid)
dev_dbg(dev, "pasid %d drained\n", pasid);
 }
 
+void idxd_device_abort_pasid(struct idxd_device *idxd, int pasid)
+{
+   struct device *dev = >pdev->dev;
+   u32 operand;
+
+   operand = pasid;
+   dev_dbg(dev, "cmd: %u operand: %#x\n", IDXD_CMD_ABORT_PASID, operand);
+   idxd_cmd_exec(idxd, IDXD_CMD_ABORT_PASID, operand, NULL);
+   dev_dbg(dev, "pasid %d aborted\n", pasid);
+}
+
 #define INT_HANDLE_IMS_TABLE   0x1
 int idxd_device_request_int_handle(struct idxd_device *idxd, int idx,
   int *handle, enum idxd_interrupt_type 
irq_type)
diff --git a/drivers/dma/idxd/idxd.h b/drivers/dma/idxd/idxd.h
index c65fb6dcb7e0..438d6478a3f8 100644
--- a/drivers/dma/idxd/idxd.h
+++ b/drivers/dma/idxd/idxd.h
@@ -321,6 +321,7 @@ void idxd_device_cleanup(struct idxd_device *idxd);
 int idxd_device_config(struct idxd_device *idxd);
 void idxd_device_wqs_clear_state(struct idxd_device *idxd);
 void idxd_device_drain_pasid(struct idxd_device *idxd, int pasid);
+void idxd_device_abort_pasid(struct idxd_device *idxd, int pasid);
 int idxd_device_load_config(struct idxd_device *idxd);
 int idxd_device_request_int_handle(struct idxd_device *idxd, int idx, int 
*handle,
   enum idxd_interrupt_type irq_type);
@@ -336,6 +337,9 @@ void idxd_wq_unmap_portal(struct idxd_wq *wq);
 void idxd_wq_disable_cleanup(struct idxd_wq *wq);
 int idxd_wq_set_pasid(struct idxd_wq *wq, int pasid);
 int idxd_wq_disable_pasid(struct idxd_wq *wq);
+int idxd_wq_abort(struct idxd_wq *wq);
+void idxd_wq_setup_pasid(struct idxd_wq *wq, int pasid);
+void idxd_wq_setup_priv(struct idxd_wq *wq, int priv);
 
 /* submission */
 int idxd_submit_desc(struct idxd_wq *wq, struct idxd_desc *desc);

[PATCH RFC v2 04/18] irq/dev-msi: Introduce APIs to allocate/free dev-msi interrupts

[Dave Jiang]

From: Megha Dey 

The dev-msi interrupts are to be allocated/freed only for custom devices,
not standard PCI-MSIX devices.

These interrupts are device-defined and they are distinct from the already
existing msi interrupts:
pci-msi: Standard PCI MSI/MSI-X setup format
platform-msi: Platform custom, but device-driver opaque MSI setup/control
arch-msi: fallback for devices not assigned to the generic PCI domain
dev-msi: device defined IRQ domain for ancillary devices. For e.g. DSA
portal devices use device specific IMS(Interrupt message store) interrupts.

dev-msi interrupts are represented by their own device-type. That means
dev->msi_list is never contended for different interrupt types. It
will either be all PCI-MSI or all device-defined.

Reviewed-by: Dan Williams 
Signed-off-by: Megha Dey 
Signed-off-by: Dave Jiang 
---
 drivers/base/dev-msi.c |   23 +++
 include/linux/msi.h|4 
 2 files changed, 27 insertions(+)

diff --git a/drivers/base/dev-msi.c b/drivers/base/dev-msi.c
index 43d6ed3ba10f..4cc75bfd62da 100644
--- a/drivers/base/dev-msi.c
+++ b/drivers/base/dev-msi.c
@@ -145,3 +145,26 @@ struct irq_domain *create_remap_dev_msi_irq_domain(struct 
irq_domain *parent,
return domain;
 }
 #endif
+
+int dev_msi_domain_alloc_irqs(struct device *dev, unsigned int nvec,
+ const struct platform_msi_ops *platform_ops)
+{
+   if (!dev->msi_domain) {
+   dev->msi_domain = dev_msi_default_domain;
+   } else if (dev->msi_domain != dev_msi_default_domain) {
+   dev_WARN_ONCE(dev, 1, "already registered to another irq 
domain?\n");
+   return -ENXIO;
+   }
+
+   return platform_msi_domain_alloc_irqs(dev, nvec, platform_ops);
+}
+EXPORT_SYMBOL_GPL(dev_msi_domain_alloc_irqs);
+
+void dev_msi_domain_free_irqs(struct device *dev)
+{
+   if (dev->msi_domain != dev_msi_default_domain)
+   dev_WARN_ONCE(dev, 1, "registered to incorrect irq domain?\n");
+
+   platform_msi_domain_free_irqs(dev);
+}
+EXPORT_SYMBOL_GPL(dev_msi_domain_free_irqs);
diff --git a/include/linux/msi.h b/include/linux/msi.h
index 7098ba566bcd..9dde8a43a0f7 100644
--- a/include/linux/msi.h
+++ b/include/linux/msi.h
@@ -381,6 +381,10 @@ void platform_msi_mask_irq(struct irq_data *data);
 
 int dev_msi_prepare(struct irq_domain *domain, struct device *dev,
int nvec, msi_alloc_info_t *arg);
+
+int dev_msi_domain_alloc_irqs(struct device *dev, unsigned int nvec,
+ const struct platform_msi_ops *platform_ops);
+void dev_msi_domain_free_irqs(struct device *dev);
 #endif /* CONFIG_GENERIC_MSI_IRQ_DOMAIN */
 
 #ifdef CONFIG_PCI_MSI_IRQ_DOMAIN

[PATCH RFC v2 07/18] dmaengine: idxd: add DEV-MSI support in base driver

[Dave Jiang]

In preparation for support of VFIO mediated device for idxd driver, the
enabling for Interrupt Message Store (IMS) interrupts is added for the idxd
base driver. DEV-MSI is the generic kernel support that mechanisms like
IMS can use to get their interrupts enabled. With IMS support the idxd
driver can dynamically allocate interrupts on a per mdev basis based on how
many IMS vectors that are mapped to the mdev device. This commit only
provides the support functions in the base driver and not the VFIO mdev
code utilization.

The commit has some portal related changes. A "portal" is a special
location within the MMIO BAR2 of the DSA device where descriptors are
submitted via the CPU command MOVDIR64B or ENQCMD(S). The offset for the
portal address determines whether the submitted descriptor is for MSI-X
or IMS notification.

See Intel SIOV spec for more details:
https://software.intel.com/en-us/download/intel-scalable-io-virtualization-technical-specification

Signed-off-by: Dave Jiang 
Reviewed-by: Kevin Tian 
---
 drivers/dma/idxd/Makefile |2 +-
 drivers/dma/idxd/cdev.c   |4 ++-
 drivers/dma/idxd/idxd.h   |   14 
 drivers/dma/idxd/ims.c|   53 +
 drivers/dma/idxd/init.c   |   52 
 drivers/dma/idxd/submit.c |   10 +++-
 drivers/dma/idxd/sysfs.c  |   11 +
 7 files changed, 137 insertions(+), 9 deletions(-)
 create mode 100644 drivers/dma/idxd/ims.c

diff --git a/drivers/dma/idxd/Makefile b/drivers/dma/idxd/Makefile
index 8978b898d777..d1519b9d1dd0 100644
--- a/drivers/dma/idxd/Makefile
+++ b/drivers/dma/idxd/Makefile
@@ -1,2 +1,2 @@
 obj-$(CONFIG_INTEL_IDXD) += idxd.o
-idxd-y := init.o irq.o device.o sysfs.o submit.o dma.o cdev.o
+idxd-y := init.o irq.o device.o sysfs.o submit.o dma.o cdev.o ims.o
diff --git a/drivers/dma/idxd/cdev.c b/drivers/dma/idxd/cdev.c
index d4841d8c0928..ffeae646f947 100644
--- a/drivers/dma/idxd/cdev.c
+++ b/drivers/dma/idxd/cdev.c
@@ -202,8 +202,8 @@ static int idxd_cdev_mmap(struct file *filp, struct 
vm_area_struct *vma)
return rc;
 
vma->vm_flags |= VM_DONTCOPY;
-   pfn = (base + idxd_get_wq_portal_full_offset(wq->id,
-   IDXD_PORTAL_LIMITED)) >> PAGE_SHIFT;
+   pfn = (base + idxd_get_wq_portal_full_offset(wq->id, 
IDXD_PORTAL_LIMITED,
+IDXD_IRQ_MSIX)) >> 
PAGE_SHIFT;
vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
vma->vm_private_data = ctx;
 
diff --git a/drivers/dma/idxd/idxd.h b/drivers/dma/idxd/idxd.h
index 2cd190a3da73..c65fb6dcb7e0 100644
--- a/drivers/dma/idxd/idxd.h
+++ b/drivers/dma/idxd/idxd.h
@@ -152,6 +152,7 @@ enum idxd_device_flag {
IDXD_FLAG_CONFIGURABLE = 0,
IDXD_FLAG_CMD_RUNNING,
IDXD_FLAG_PASID_ENABLED,
+   IDXD_FLAG_SIOV_SUPPORTED,
 };
 
 struct idxd_device {
@@ -178,6 +179,7 @@ struct idxd_device {
 
int num_groups;
 
+   u32 ims_offset;
u32 msix_perm_offset;
u32 wqcfg_offset;
u32 grpcfg_offset;
@@ -185,6 +187,7 @@ struct idxd_device {
 
u64 max_xfer_bytes;
u32 max_batch_size;
+   int ims_size;
int max_groups;
int max_engines;
int max_tokens;
@@ -204,6 +207,7 @@ struct idxd_device {
struct work_struct work;
 
int *int_handles;
+   struct sbitmap ims_sbmap;
 };
 
 /* IDXD software descriptor */
@@ -251,15 +255,17 @@ enum idxd_interrupt_type {
IDXD_IRQ_IMS,
 };
 
-static inline int idxd_get_wq_portal_offset(enum idxd_portal_prot prot)
+static inline int idxd_get_wq_portal_offset(enum idxd_portal_prot prot,
+   enum idxd_interrupt_type irq_type)
 {
-   return prot * 0x1000;
+   return prot * 0x1000 + irq_type * 0x2000;
 }
 
 static inline int idxd_get_wq_portal_full_offset(int wq_id,
-enum idxd_portal_prot prot)
+enum idxd_portal_prot prot,
+enum idxd_interrupt_type 
irq_type)
 {
-   return ((wq_id * 4) << PAGE_SHIFT) + idxd_get_wq_portal_offset(prot);
+   return ((wq_id * 4) << PAGE_SHIFT) + idxd_get_wq_portal_offset(prot, 
irq_type);
 }
 
 static inline void idxd_set_type(struct idxd_device *idxd)
diff --git a/drivers/dma/idxd/ims.c b/drivers/dma/idxd/ims.c
new file mode 100644
index ..5fece66122a2
--- /dev/null
+++ b/drivers/dma/idxd/ims.c
@@ -0,0 +1,53 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright(c) 2019,2020 Intel Corporation. All rights rsvd. */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "registers.h"
+#include "idxd.h"
+
+static void idxd_free_ims_index(struct idxd_device *idxd,
+   unsigned long ims_idx)
+{
+   sbitmap_clear_bit(>ims_sbmap, ims_idx);
+}
+
+static 

[PATCH RFC v2 01/18] platform-msi: Introduce platform_msi_ops

[Dave Jiang]

From: Megha Dey 

platform-msi.c provides a generic way to handle non-PCI message
signaled interrupts. However, it assumes that only the message
needs to be customized. Given that an MSI is just a write
transaction, some devices may need custom callbacks to
mask/unmask their interrupts.

Hence, introduce a new structure platform_msi_ops, which would
provide device specific write function for now and introduce device
device specific callbacks (mask/unmask), in subsequent patches.

Devices may find more efficient ways to store addr/data pairs
than what is recommended by the PCI sig. (For e.g. the storage of
the vector might not be resident on the device. Consider GPGPU
for instance, where the vector could be part of the execution
context instead of being stored on the device.)

Reviewed-by: Dan Williams 
Signed-off-by: Megha Dey 
Signed-off-by: Dave Jiang 
---
 drivers/base/platform-msi.c  |   29 +++--
 drivers/dma/mv_xor_v2.c  |6 +-
 drivers/dma/qcom/hidma.c |6 +-
 drivers/iommu/arm-smmu-v3.c  |6 +-
 drivers/irqchip/irq-mbigen.c |8 ++--
 drivers/irqchip/irq-mvebu-icu.c  |6 +-
 drivers/mailbox/bcm-flexrm-mailbox.c |6 +-
 drivers/perf/arm_smmuv3_pmu.c|6 +-
 include/linux/msi.h  |   20 ++--
 9 files changed, 65 insertions(+), 28 deletions(-)

diff --git a/drivers/base/platform-msi.c b/drivers/base/platform-msi.c
index c4a17e5edf8b..9d94cd699468 100644
--- a/drivers/base/platform-msi.c
+++ b/drivers/base/platform-msi.c
@@ -18,14 +18,14 @@
 
 /*
  * Internal data structure containing a (made up, but unique) devid
- * and the callback to write the MSI message.
+ * and the platform-msi ops
  */
 struct platform_msi_priv_data {
-   struct device   *dev;
-   void*host_data;
-   msi_alloc_info_targ;
-   irq_write_msi_msg_t write_msg;
-   int devid;
+   struct device   *dev;
+   void*host_data;
+   msi_alloc_info_targ;
+   const struct platform_msi_ops   *ops;
+   int devid;
 };
 
 /* The devid allocator */
@@ -83,7 +83,7 @@ static void platform_msi_write_msg(struct irq_data *data, 
struct msi_msg *msg)
 
priv_data = desc->platform.msi_priv_data;
 
-   priv_data->write_msg(desc, msg);
+   priv_data->ops->write_msg(desc, msg);
 }
 
 static void platform_msi_update_chip_ops(struct msi_domain_info *info)
@@ -194,16 +194,17 @@ struct irq_domain *platform_msi_create_irq_domain(struct 
fwnode_handle *fwnode,
 
 static struct platform_msi_priv_data *
 platform_msi_alloc_priv_data(struct device *dev, unsigned int nvec,
-irq_write_msi_msg_t write_msi_msg)
+const struct platform_msi_ops *platform_ops)
 {
struct platform_msi_priv_data *datap;
+
/*
 * Limit the number of interrupts to 2048 per device. Should we
 * need to bump this up, DEV_ID_SHIFT should be adjusted
 * accordingly (which would impact the max number of MSI
 * capable devices).
 */
-   if (!dev->msi_domain || !write_msi_msg || !nvec || nvec > MAX_DEV_MSIS)
+   if (!dev->msi_domain || !platform_ops->write_msg || !nvec || nvec > 
MAX_DEV_MSIS)
return ERR_PTR(-EINVAL);
 
if (dev->msi_domain->bus_token != DOMAIN_BUS_PLATFORM_MSI) {
@@ -227,7 +228,7 @@ platform_msi_alloc_priv_data(struct device *dev, unsigned 
int nvec,
return ERR_PTR(err);
}
 
-   datap->write_msg = write_msi_msg;
+   datap->ops = platform_ops;
datap->dev = dev;
 
return datap;
@@ -249,12 +250,12 @@ static void platform_msi_free_priv_data(struct 
platform_msi_priv_data *data)
  * Zero for success, or an error code in case of failure
  */
 int platform_msi_domain_alloc_irqs(struct device *dev, unsigned int nvec,
-  irq_write_msi_msg_t write_msi_msg)
+  const struct platform_msi_ops *platform_ops)
 {
struct platform_msi_priv_data *priv_data;
int err;
 
-   priv_data = platform_msi_alloc_priv_data(dev, nvec, write_msi_msg);
+   priv_data = platform_msi_alloc_priv_data(dev, nvec, platform_ops);
if (IS_ERR(priv_data))
return PTR_ERR(priv_data);
 
@@ -324,7 +325,7 @@ struct irq_domain *
 __platform_msi_create_device_domain(struct device *dev,
unsigned int nvec,
bool is_tree,
-   irq_write_msi_msg_t write_msi_msg,
+   const struct platform_msi_ops *platform_ops,
const struct irq_domain_ops *ops,
void *host_data)
 {
@@ -332,7 +333,7 @@ 

Re: [PATCH v2 1/3] dt-bindings: vendor-prefixes: add Seeed Studio

[Rob Herring]

On Tue, 21 Jul 2020 17:20:13 +0200, Marcin Sloniewski wrote:
> Add the "seeed" vendor prefix for Seeed Technology Co., Ltd
> Website: https://www.seeedstudio.com/
> 
> Signed-off-by: Marcin Sloniewski 
> Acked-by: Rob Herring 
> ---
>  Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
>  1 file changed, 2 insertions(+)
> 


Please add Acked-by/Reviewed-by tags when posting new versions. However,
there's no need to repost patches *only* to add the tags. The upstream
maintainer will do that for acks received on the version they apply.

If a tag was not added on purpose, please state why and what changed.

[PATCH RFC v2 05/18] dmaengine: idxd: add support for readonly config devices

[Dave Jiang]

The VFIO mediated device for idxd driver will provide a virtual DSA
device by backing it with a workqueue. The virtual device will be limited
with the wq configuration registers set to read-only. Add support and
helper functions for the handling of a DSA device with the configuration
registers marked as read-only.

Signed-off-by: Dave Jiang 
Reviewed-by: Kevin Tian 
---
 drivers/dma/idxd/device.c |  116 +
 drivers/dma/idxd/idxd.h   |1 
 drivers/dma/idxd/init.c   |8 +++
 drivers/dma/idxd/sysfs.c  |   21 +---
 4 files changed, 137 insertions(+), 9 deletions(-)

diff --git a/drivers/dma/idxd/device.c b/drivers/dma/idxd/device.c
index 9032b50b31af..7531ed9c1b81 100644
--- a/drivers/dma/idxd/device.c
+++ b/drivers/dma/idxd/device.c
@@ -750,3 +750,119 @@ int idxd_device_config(struct idxd_device *idxd)
 
return 0;
 }
+
+static int idxd_wq_load_config(struct idxd_wq *wq)
+{
+   struct idxd_device *idxd = wq->idxd;
+   struct device *dev = >pdev->dev;
+   int wqcfg_offset;
+   int i;
+
+   wqcfg_offset = idxd->wqcfg_offset + wq->id * 32;
+   memcpy_fromio(>wqcfg, idxd->reg_base + wqcfg_offset, sizeof(union 
wqcfg));
+
+   wq->size = wq->wqcfg.wq_size;
+   wq->threshold = wq->wqcfg.wq_thresh;
+   if (wq->wqcfg.priv)
+   wq->type = IDXD_WQT_KERNEL;
+
+   /* The driver does not support shared WQ mode in read-only config yet */
+   if (wq->wqcfg.mode == 0 || wq->wqcfg.pasid_en)
+   return -EOPNOTSUPP;
+
+   set_bit(WQ_FLAG_DEDICATED, >flags);
+
+   wq->priority = wq->wqcfg.priority;
+
+   for (i = 0; i < 8; i++) {
+   wqcfg_offset = idxd->wqcfg_offset + wq->id * 32 + i * 
sizeof(u32);
+   dev_dbg(dev, "WQ[%d][%d][%#x]: %#x\n",
+   wq->id, i, wqcfg_offset, wq->wqcfg.bits[i]);
+   }
+
+   return 0;
+}
+
+static void idxd_group_load_config(struct idxd_group *group)
+{
+   struct idxd_device *idxd = group->idxd;
+   struct device *dev = >pdev->dev;
+   int i, j, grpcfg_offset;
+
+   /*
+* Load WQS bit fields
+* Iterate through all 256 bits 64 bits at a time
+*/
+   for (i = 0; i < 4; i++) {
+   struct idxd_wq *wq;
+
+   grpcfg_offset = idxd->grpcfg_offset + group->id * 64 + i * 
sizeof(u64);
+   group->grpcfg.wqs[i] = ioread64(idxd->reg_base + grpcfg_offset);
+   dev_dbg(dev, "GRPCFG wq[%d:%d: %#x]: %#llx\n",
+   group->id, i, grpcfg_offset, group->grpcfg.wqs[i]);
+
+   if (i * 64 >= idxd->max_wqs)
+   break;
+
+   /* Iterate through all 64 bits and check for wq set */
+   for (j = 0; j < 64; j++) {
+   int id = i * 64 + j;
+
+   /* No need to check beyond max wqs */
+   if (id >= idxd->max_wqs)
+   break;
+
+   /* Set group assignment for wq if wq bit is set */
+   if (group->grpcfg.wqs[i] & BIT(j)) {
+   wq = >wqs[id];
+   wq->group = group;
+   }
+   }
+   }
+
+   grpcfg_offset = idxd->grpcfg_offset + group->id * 64 + 32;
+   group->grpcfg.engines = ioread64(idxd->reg_base + grpcfg_offset);
+   dev_dbg(dev, "GRPCFG engs[%d: %#x]: %#llx\n", group->id,
+   grpcfg_offset, group->grpcfg.engines);
+
+   for (i = 0; i < 64; i++) {
+   if (i >= idxd->max_engines)
+   break;
+
+   if (group->grpcfg.engines & BIT(i)) {
+   struct idxd_engine *engine = >engines[i];
+
+   engine->group = group;
+   }
+   }
+
+   grpcfg_offset = idxd->grpcfg_offset + group->id * 64 + 40;
+   group->grpcfg.flags.bits = ioread32(idxd->reg_base + grpcfg_offset);
+   dev_dbg(dev, "GRPFLAGS flags[%d: %#x]: %#x\n",
+   group->id, grpcfg_offset, group->grpcfg.flags.bits);
+}
+
+int idxd_device_load_config(struct idxd_device *idxd)
+{
+   union gencfg_reg reg;
+   int i, rc;
+
+   reg.bits = ioread32(idxd->reg_base + IDXD_GENCFG_OFFSET);
+   idxd->token_limit = reg.token_limit;
+
+   for (i = 0; i < idxd->max_groups; i++) {
+   struct idxd_group *group = >groups[i];
+
+   idxd_group_load_config(group);
+   }
+
+   for (i = 0; i < idxd->max_wqs; i++) {
+   struct idxd_wq *wq = >wqs[i];
+
+   rc = idxd_wq_load_config(wq);
+   if (rc < 0)
+   return rc;
+   }
+
+   return 0;
+}
diff --git a/drivers/dma/idxd/idxd.h b/drivers/dma/idxd/idxd.h
index 518768885d7b..fcea8bc060f5 100644
--- a/drivers/dma/idxd/idxd.h
+++ b/drivers/dma/idxd/idxd.h
@@ -306,6 +306,7 @@ void idxd_device_cleanup(struct idxd_device *idxd);
 int 

[PATCH RFC v2 06/18] dmaengine: idxd: add interrupt handle request support

[Dave Jiang]

Add support for requesting interrupt handle from the device. The interrupt
handle is put in the interrupt handle field of a descriptor for the device
to determine which interrupt vector to use be it MSI-X or IMS. On the host
device, the interrupt handle is indexed to the MSI-X table. This allows a
descriptor to program the interrupt handle 1:1 with the MSI-X index without
getting it from the request interrupt handle device command. For a guest
device, the index can be any index that the host assigned for the IMS
table, and therefore it must be requested from the virtual device during
MSI-X setup by the driver running on the guest.

On the actual hardware the MSIX vector 0 is misc interrupt and handles
events such as administrative command completion, error reporting,
performance monitor overflow, and etc. The MSIX vectors 1...N
are used for descriptor completion interrupts. On the guest kernel,
the MSIX interrupts are backed by the mediated device through emulation
or IMS vectors. Vector 0 is handled through emulation by the host vdcm.
It only requires the host driver to send the signal to qemu. The vector 1
(and more may be supported later) is backed by IMS.

Signed-off-by: Dave Jiang 
Reviewed-by: Kevin Tian 
---
 drivers/dma/idxd/device.c|   30 ++
 drivers/dma/idxd/idxd.h  |   11 +++
 drivers/dma/idxd/init.c  |   29 +
 drivers/dma/idxd/registers.h |4 +++-
 drivers/dma/idxd/submit.c|   29 ++---
 5 files changed, 95 insertions(+), 8 deletions(-)

diff --git a/drivers/dma/idxd/device.c b/drivers/dma/idxd/device.c
index 7531ed9c1b81..2b4e8ab99ebd 100644
--- a/drivers/dma/idxd/device.c
+++ b/drivers/dma/idxd/device.c
@@ -502,6 +502,36 @@ void idxd_device_drain_pasid(struct idxd_device *idxd, int 
pasid)
dev_dbg(dev, "pasid %d drained\n", pasid);
 }
 
+#define INT_HANDLE_IMS_TABLE   0x1
+int idxd_device_request_int_handle(struct idxd_device *idxd, int idx,
+  int *handle, enum idxd_interrupt_type 
irq_type)
+{
+   struct device *dev = >pdev->dev;
+   u32 operand, status;
+
+   if (!(idxd->hw.cmd_cap & BIT(IDXD_CMD_REQUEST_INT_HANDLE)))
+   return -EOPNOTSUPP;
+
+   dev_dbg(dev, "get int handle, idx %d\n", idx);
+
+   operand = idx & 0x;
+   if (irq_type == IDXD_IRQ_IMS)
+   operand |= INT_HANDLE_IMS_TABLE;
+   dev_dbg(dev, "cmd: %u operand: %#x\n",
+   IDXD_CMD_REQUEST_INT_HANDLE, operand);
+   idxd_cmd_exec(idxd, IDXD_CMD_REQUEST_INT_HANDLE, operand, );
+
+   if ((status & 0xff) != IDXD_CMDSTS_SUCCESS) {
+   dev_dbg(dev, "request int handle failed: %#x\n", status);
+   return -ENXIO;
+   }
+
+   *handle = (status >> 8) & 0x;
+
+   dev_dbg(dev, "int handle acquired: %u\n", *handle);
+   return 0;
+}
+
 /* Device configuration bits */
 static void idxd_group_config_write(struct idxd_group *group)
 {
diff --git a/drivers/dma/idxd/idxd.h b/drivers/dma/idxd/idxd.h
index fcea8bc060f5..2cd190a3da73 100644
--- a/drivers/dma/idxd/idxd.h
+++ b/drivers/dma/idxd/idxd.h
@@ -138,6 +138,7 @@ struct idxd_hw {
union group_cap_reg group_cap;
union engine_cap_reg engine_cap;
struct opcap opcap;
+   u32 cmd_cap;
 };
 
 enum idxd_device_state {
@@ -201,6 +202,8 @@ struct idxd_device {
struct dma_device dma_dev;
struct workqueue_struct *wq;
struct work_struct work;
+
+   int *int_handles;
 };
 
 /* IDXD software descriptor */
@@ -214,6 +217,7 @@ struct idxd_desc {
struct list_head list;
int id;
int cpu;
+   unsigned int vec_ptr;
struct idxd_wq *wq;
 };
 
@@ -242,6 +246,11 @@ enum idxd_portal_prot {
IDXD_PORTAL_LIMITED,
 };
 
+enum idxd_interrupt_type {
+   IDXD_IRQ_MSIX = 0,
+   IDXD_IRQ_IMS,
+};
+
 static inline int idxd_get_wq_portal_offset(enum idxd_portal_prot prot)
 {
return prot * 0x1000;
@@ -307,6 +316,8 @@ int idxd_device_config(struct idxd_device *idxd);
 void idxd_device_wqs_clear_state(struct idxd_device *idxd);
 void idxd_device_drain_pasid(struct idxd_device *idxd, int pasid);
 int idxd_device_load_config(struct idxd_device *idxd);
+int idxd_device_request_int_handle(struct idxd_device *idxd, int idx, int 
*handle,
+  enum idxd_interrupt_type irq_type);
 
 /* work queue control */
 int idxd_wq_alloc_resources(struct idxd_wq *wq);
diff --git a/drivers/dma/idxd/init.c b/drivers/dma/idxd/init.c
index 50c68de6b4ab..9fd505a03444 100644
--- a/drivers/dma/idxd/init.c
+++ b/drivers/dma/idxd/init.c
@@ -132,6 +132,22 @@ static int idxd_setup_interrupts(struct idxd_device *idxd)
}
dev_dbg(dev, "Allocated idxd-msix %d for vector %d\n",
i, msix->vector);
+
+   if (idxd->hw.cmd_cap & BIT(IDXD_CMD_REQUEST_INT_HANDLE)) {
+   /*
+ 

[PATCH RFC v2 00/18] Add VFIO mediated device support and DEV-MSI support for the idxd driver

[Dave Jiang]

v2:
IMS (now dev-msi):
With recommendations from Jason/Thomas/Dan on making IMS more generic:
Pass a non-pci generic device(struct device) for IMS management instead of mdev
Remove all references to mdev and symbol_get/put
Remove all references to IMS in common code and replace with dev-msi
remove dynamic allocation of platform-msi interrupts: no groups,no new msi list 
or list helpers
Create a generic dev-msi domain with and without interrupt remapping enabled.
Introduce dev_msi_domain_alloc_irqs and dev_msi_domain_free_irqs apis

mdev: 
Removing unrelated bits from SVA enabling that’s not necessary for the 
submission. (Kevin)
Restructured entire mdev driver series to make reviewing easier (Kevin)
Made rw emulation more robust (Kevin)
Removed uuid wq type and added single dedicated wq type (Kevin)
Locking fixes for vdev (Yan Zhao)
VFIO MSIX trigger fixes (Yan Zhao)

Link to previous discussions with Jason:
https://lore.kernel.org/lkml/57296ad1-20fe-caf2-b83f-46d823ca0...@intel.com/
The emulation part that can be moved to user space is very small due to the 
majority of the
emulations being control bits and need to reside in the kernel. We can revisit 
the necessity of
moving the small emulation part to userspace and required architectural changes 
at a later time.

This RFC series has been reviewed by Dan Williams 

The actual code can be independent of the stage 2 driver code submission that 
adds support for SVM,
ENQCMD(S), PASID, and shared workqueues. This code series will match the 
support of the 5.6 kernel
(stage 1) driver but on guest. The code is dependent on Baolu’s iommu 
aux-domain API extensions
patches that’s still in process of being reviewed:
https://lkml.org/lkml/2020/7/14/48

Stage 1 of the driver has been accepted in v5.6 kernel. It supports dedicated 
workqueue (wq)
without Shared Virtual Memory (SVM) support. Stage 2 supports shared wq and 
SVM. It is pending
upstream review and targeting kernel v5.9.

VFIO mediated device framework allows vendor drivers to wrap a portion of 
device resources into
virtual devices (mdev). Each mdev can be assigned to different guest using the 
same set of VFIO
uAPIs as assigning a physical device. Accessing to the mdev resource is served 
with mixed policies.
For example, vendor drivers typically mark data-path interface as pass-through 
for fast guest
operations, and then trap-and-mediate the control-path interface to avoid 
undesired interference
between mdevs. Some level of emulation is necessary behind vfio mdev to compose 
the virtual device
interface. 

This series brings mdev to idxd driver to enable Intel Scalable IOV (SIOV), a 
hardware-assisted
mediated pass-through technology. SIOV makes each DSA wq independently 
assignable through
PASID-granular resource/DMA isolation. It helps improve scalability and reduces 
mediation
complexity against purely software-based mdev implementations. Each assigned wq 
is configured by
host and exposed to the guest in a read-only configuration mode, which allows 
the guest to use the
wq w/o additional setup. This design greatly reduces the emulation bits to 
focus on handling
commands from guests.

Introducing mdev types “1dwq” type. This mdev type allows allocation of a 
single dedicated wq from
available dedicated wqs. After a workqueue (wq) is enabled, the user will 
generate an uuid. On mdev
creation, the mdev driver code will find a dwq depending on the mdev type. When 
the create operation
is successful, the user generated uuid can be passed to qemu. When the guest 
boots up, it should
discover a DSA device when doing PCI discovery.

For example of “1dwq” type:
1. Enable wq with “mdev” wq type
2. A user generated uuid.
3. The uuid is written to the mdev class sysfs path:
echo $UUID > 
/sys/class/mdev_bus/\:00\:0a.0/mdev_supported_types/idxd-wq/create
4. Pass the following parameter to qemu:
"-device vfio-pci,sysfsdev=/sys/bus/pci/devices/:00:0a.0/$UUID"
 
The wq exported through mdev will have the read only config bit set for 
configuration. This means
that the device does not require the typical configuration. After enabling the 
device, the user
must set the WQ type and name. That is all is necessary to enable the WQ and 
start using it. The
single wq configuration is not the only way to create the mdev. Multi wqs 
support for mdev will be
in the future works.
 
The mdev utilizes Interrupt Message Store or IMS[3], a device-specific MSI 
implementation, instead
of MSIX for interrupts for the guest. This preserves MSIX for host usages and 
also allows a
significantly larger number of interrupt vectors for guest usage.

The idxd driver implements IMS as on-device memory mapped unified storage. Each 
interrupt message
is stored as a DWORD size data payload and a 64-bit address (same as MSI-X). 
Access to the IMS is
through the host idxd driver.

This patchset extends the existing platform-msi framework (which provides a 
generic mechanism to
support non-PCI compliant MSI interrupts) to benefit 

[PATCH RFC v2 03/18] irq/dev-msi: Create IR-DEV-MSI irq domain

[Dave Jiang]

From: Megha Dey 

When DEV_MSI is enabled, the dev_msi_default_domain is updated to the
base DEV-MSI irq  domain. If interrupt remapping is enabled, we create
a new IR-DEV-MSI irq domain and update the dev_msi_default domain to
the same.

For X86, introduce a new irq_alloc_type which will be used by the
interrupt remapping driver.

Reviewed-by: Dan Williams 
Signed-off-by: Megha Dey 
Signed-off-by: Dave Jiang 
---
 arch/x86/include/asm/hw_irq.h   |1 +
 arch/x86/kernel/apic/msi.c  |   12 ++
 drivers/base/dev-msi.c  |   66 +++
 drivers/iommu/intel/irq_remapping.c |   11 +-
 include/linux/intel-iommu.h |1 +
 include/linux/irqdomain.h   |   11 ++
 include/linux/msi.h |3 ++
 7 files changed, 96 insertions(+), 9 deletions(-)

diff --git a/arch/x86/include/asm/hw_irq.h b/arch/x86/include/asm/hw_irq.h
index 8ecd7570589d..b63add41 100644
--- a/arch/x86/include/asm/hw_irq.h
+++ b/arch/x86/include/asm/hw_irq.h
@@ -40,6 +40,7 @@ enum irq_alloc_type {
X86_IRQ_ALLOC_TYPE_MSIX,
X86_IRQ_ALLOC_TYPE_DMAR,
X86_IRQ_ALLOC_TYPE_UV,
+   X86_IRQ_ALLOC_TYPE_DEV_MSI,
 };
 
 struct irq_alloc_info {
diff --git a/arch/x86/kernel/apic/msi.c b/arch/x86/kernel/apic/msi.c
index 5cbaca58af95..8b25cadbae09 100644
--- a/arch/x86/kernel/apic/msi.c
+++ b/arch/x86/kernel/apic/msi.c
@@ -507,3 +507,15 @@ int hpet_assign_irq(struct irq_domain *domain, struct 
hpet_channel *hc,
return irq_domain_alloc_irqs(domain, 1, NUMA_NO_NODE, );
 }
 #endif
+
+#ifdef CONFIG_DEV_MSI
+int dev_msi_prepare(struct irq_domain *domain, struct device *dev,
+  int nvec, msi_alloc_info_t *arg)
+{
+   memset(arg, 0, sizeof(*arg));
+
+   arg->type = X86_IRQ_ALLOC_TYPE_DEV_MSI;
+
+   return 0;
+}
+#endif
diff --git a/drivers/base/dev-msi.c b/drivers/base/dev-msi.c
index 240ccc353933..43d6ed3ba10f 100644
--- a/drivers/base/dev-msi.c
+++ b/drivers/base/dev-msi.c
@@ -5,6 +5,7 @@
  * Author: Megha Dey 
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -32,7 +33,7 @@ static void dev_msi_set_desc(msi_alloc_info_t *arg, struct 
msi_desc *desc)
arg->hwirq = dev_msi_calc_hwirq(desc);
 }
 
-static int dev_msi_prepare(struct irq_domain *domain, struct device *dev,
+int __weak dev_msi_prepare(struct irq_domain *domain, struct device *dev,
   int nvec, msi_alloc_info_t *arg)
 {
memset(arg, 0, sizeof(*arg));
@@ -81,15 +82,66 @@ static int __init create_dev_msi_domain(void)
if (!fn)
return -ENXIO;
 
-   dev_msi_default_domain = msi_create_irq_domain(fn, 
_msi_domain_info, parent);
+   /*
+* This initcall may come after remap code is initialized. Ensure that
+* dev_msi_default domain is updated correctly.
+*/
if (!dev_msi_default_domain) {
-   pr_warn("failed to initialize irqdomain for DEV-MSI.\n");
-   return -ENXIO;
+   dev_msi_default_domain = msi_create_irq_domain(fn, 
_msi_domain_info, parent);
+   if (!dev_msi_default_domain) {
+   pr_warn("failed to initialize irqdomain for 
DEV-MSI.\n");
+   return -ENXIO;
+   }
+
+   irq_domain_update_bus_token(dev_msi_default_domain, 
DOMAIN_BUS_PLATFORM_MSI);
+   irq_domain_free_fwnode(fn);
}
 
-   irq_domain_update_bus_token(dev_msi_default_domain, 
DOMAIN_BUS_PLATFORM_MSI);
-   irq_domain_free_fwnode(fn);
-
return 0;
 }
 device_initcall(create_dev_msi_domain);
+
+#ifdef CONFIG_IRQ_REMAP
+static struct irq_chip dev_msi_ir_controller = {
+   .name   = "IR-DEV-MSI",
+   .irq_unmask = platform_msi_unmask_irq,
+   .irq_mask   = platform_msi_mask_irq,
+   .irq_write_msi_msg  = platform_msi_write_msg,
+   .irq_ack= irq_chip_ack_parent,
+   .irq_retrigger  = irq_chip_retrigger_hierarchy,
+   .irq_set_vcpu_affinity  = irq_chip_set_vcpu_affinity_parent,
+   .flags  = IRQCHIP_SKIP_SET_WAKE,
+};
+
+static struct msi_domain_info dev_msi_ir_domain_info = {
+   .flags  = MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS,
+   .ops= _msi_domain_ops,
+   .chip   = _msi_ir_controller,
+   .handler= handle_edge_irq,
+   .handler_name   = "edge",
+};
+
+struct irq_domain *create_remap_dev_msi_irq_domain(struct irq_domain *parent,
+  const char *name)
+{
+   struct fwnode_handle *fn;
+   struct irq_domain *domain;
+
+   fn = irq_domain_alloc_named_fwnode(name);
+   if (!fn)
+   return NULL;
+
+   domain = msi_create_irq_domain(fn, _msi_ir_domain_info, parent);
+   if (!domain) {
+   pr_warn("failed to initialize irqdomain for IR-DEV-MSI.\n");
+   

[PATCH RFC v2 02/18] irq/dev-msi: Add support for a new DEV_MSI irq domain

[Dave Jiang]

From: Megha Dey 

Add support for the creation of a new DEV_MSI irq domain. It creates a
new irq chip associated with the DEV_MSI domain and adds the necessary
domain operations to it.

Add a new config option DEV_MSI which must be enabled by any
driver that wants to support device-specific message-signaled-interrupts
outside of PCI-MSI(-X).

Lastly, add device specific mask/unmask callbacks in addition to a write
function to the platform_msi_ops.

Reviewed-by: Dan Williams 
Signed-off-by: Megha Dey 
Signed-off-by: Dave Jiang 
---
 arch/x86/include/asm/hw_irq.h |5 ++
 drivers/base/Kconfig  |7 +++
 drivers/base/Makefile |1 
 drivers/base/dev-msi.c|   95 +
 drivers/base/platform-msi.c   |   45 +--
 drivers/base/platform-msi.h   |   23 ++
 include/linux/msi.h   |8 +++
 7 files changed, 168 insertions(+), 16 deletions(-)
 create mode 100644 drivers/base/dev-msi.c
 create mode 100644 drivers/base/platform-msi.h

diff --git a/arch/x86/include/asm/hw_irq.h b/arch/x86/include/asm/hw_irq.h
index 74c12437401e..8ecd7570589d 100644
--- a/arch/x86/include/asm/hw_irq.h
+++ b/arch/x86/include/asm/hw_irq.h
@@ -61,6 +61,11 @@ struct irq_alloc_info {
irq_hw_number_t msi_hwirq;
};
 #endif
+#ifdef CONFIG_DEV_MSI
+   struct {
+   irq_hw_number_t hwirq;
+   };
+#endif
 #ifdef CONFIG_X86_IO_APIC
struct {
int ioapic_id;
diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index 8d7001712062..f00901bac056 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -210,4 +210,11 @@ config GENERIC_ARCH_TOPOLOGY
  appropriate scaling, sysfs interface for reading capacity values at
  runtime.
 
+config DEV_MSI
+   bool "Device Specific Interrupt Messages"
+   select IRQ_DOMAIN_HIERARCHY
+   select GENERIC_MSI_IRQ_DOMAIN
+   help
+ Allow device drivers to generate device-specific interrupt messages
+ for devices independent of PCI MSI/-X.
 endmenu
diff --git a/drivers/base/Makefile b/drivers/base/Makefile
index 157452080f3d..ca1e4d39164e 100644
--- a/drivers/base/Makefile
+++ b/drivers/base/Makefile
@@ -21,6 +21,7 @@ obj-$(CONFIG_REGMAP)  += regmap/
 obj-$(CONFIG_SOC_BUS) += soc.o
 obj-$(CONFIG_PINCTRL) += pinctrl.o
 obj-$(CONFIG_DEV_COREDUMP) += devcoredump.o
+obj-$(CONFIG_DEV_MSI) += dev-msi.o
 obj-$(CONFIG_GENERIC_MSI_IRQ_DOMAIN) += platform-msi.o
 obj-$(CONFIG_GENERIC_ARCH_TOPOLOGY) += arch_topology.o
 
diff --git a/drivers/base/dev-msi.c b/drivers/base/dev-msi.c
new file mode 100644
index ..240ccc353933
--- /dev/null
+++ b/drivers/base/dev-msi.c
@@ -0,0 +1,95 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright © 2020 Intel Corporation.
+ *
+ * Author: Megha Dey 
+ */
+
+#include 
+#include 
+#include 
+#include "platform-msi.h"
+
+struct irq_domain *dev_msi_default_domain;
+
+static irq_hw_number_t dev_msi_get_hwirq(struct msi_domain_info *info,
+msi_alloc_info_t *arg)
+{
+   return arg->hwirq;
+}
+
+static irq_hw_number_t dev_msi_calc_hwirq(struct msi_desc *desc)
+{
+   u32 devid;
+
+   devid = desc->platform.msi_priv_data->devid;
+
+   return (devid << (32 - DEV_ID_SHIFT)) | desc->platform.msi_index;
+}
+
+static void dev_msi_set_desc(msi_alloc_info_t *arg, struct msi_desc *desc)
+{
+   arg->hwirq = dev_msi_calc_hwirq(desc);
+}
+
+static int dev_msi_prepare(struct irq_domain *domain, struct device *dev,
+  int nvec, msi_alloc_info_t *arg)
+{
+   memset(arg, 0, sizeof(*arg));
+
+   return 0;
+}
+
+static struct msi_domain_ops dev_msi_domain_ops = {
+   .get_hwirq  = dev_msi_get_hwirq,
+   .set_desc   = dev_msi_set_desc,
+   .msi_prepare= dev_msi_prepare,
+};
+
+static struct irq_chip dev_msi_controller = {
+   .name   = "DEV-MSI",
+   .irq_unmask = platform_msi_unmask_irq,
+   .irq_mask   = platform_msi_mask_irq,
+   .irq_write_msi_msg  = platform_msi_write_msg,
+   .irq_ack= irq_chip_ack_parent,
+   .irq_retrigger  = irq_chip_retrigger_hierarchy,
+   .flags  = IRQCHIP_SKIP_SET_WAKE,
+};
+
+static struct msi_domain_info dev_msi_domain_info = {
+   .flags  = MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS,
+   .ops= _msi_domain_ops,
+   .chip   = _msi_controller,
+   .handler= handle_edge_irq,
+   .handler_name   = "edge",
+};
+
+static int __init create_dev_msi_domain(void)
+{
+   struct irq_domain *parent = NULL;
+   struct fwnode_handle *fn;
+
+   /*
+* Modern code should never have to use irq_get_default_host. But since
+* dev-msi is invisible to DT/ACPI, this is an exception case.
+*/

Re: [PATCH] KVM: x86/mmu: Add capability to zap only sptes for the affected memslot

[Alex Williamson]

On Mon, 20 Jul 2020 20:03:19 -0700
Sean Christopherson  wrote:

> +Weijiang
> 
> On Mon, Jul 13, 2020 at 12:06:50PM -0700, Sean Christopherson wrote:
> > The only ideas I have going forward are to:
> > 
> >   a) Reproduce the bug outside of your environment and find a resource that
> >  can go through the painful bisection.  
> 
> We're trying to reproduce the original issue in the hopes of biesecting, but
> have not yet discovered the secret sauce.  A few questions:
> 
>   - Are there any known hardware requirements, e.g. specific flavor of GPU?

I'm using an old GeForce GT635, I don't think there's anything special
about this card.

>   - What's the average time to failure when running FurMark/PassMark?  E.g.
> what's a reasonable time to wait before rebooting to rerun the tests (I
> assume this is what you meant when you said you sometimes needed to
> reboot to observe failure).

The failure mode ranges from graphics glitches, ex. vectors drawn
across a window during the test or stray lines when interacting with
the Windows menu button, to graphics driver failures triggering an
error dialog, usually from PassMark.  I usually start FurMark, run the
stress test for ~10s, kill it, then run a PassMark benchmark.  If I
don't observe any glitching during the run, I'll trigger the Windows
menu a few times, then reboot and try again.  The graphics tests within
PassMark are generally when the glitches are triggered, both 2D and 3D,
sometimes it's sufficient to only run those tests rather than the full
system benchmark.  That's largely the trouble with this bisect is that
the test is very interactive and requires observation.  Sometimes when
it fails it snowballs into worse and worse errors and there's high
confidence that it's bad, but other times you'll be suspicious that
something occurred and need to repeat the testing.  Thanks,

Alex

Re: nouveau regression with 5.7 caused by "PCI/PM: Assume ports without DLL Link Active train links in 100 ms"

[Lyude Paul]

On Tue, 2020-07-21 at 18:27 +0300, Mika Westerberg wrote:
> On Tue, Jul 21, 2020 at 11:01:55AM -0400, Lyude Paul wrote:
> > Sure thing. Also, feel free to let me know if you'd like access to one of
> > the
> > systems we saw breaking with this patch - I'm fairly sure I've got one of
> > them
> > locally at my apartment and don't mind setting up AMT/KVM/SSH
> 
> Probably no need for remote access (thanks for the offer, though). I
> attached a test patch to the bug report:
> 
>   https://bugzilla.kernel.org/show_bug.cgi?id=208597
> 
> that tries to work it around (based on the ->pm_cap == 0). I wonder if
> anyone would have time to try it out.

Will give it a shot today and let you know the result

> 
-- 
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat

Re: kworker/0:3+pm hogging CPU

[Michal Hocko]

On Tue 21-07-20 10:33:25, Alan Stern wrote:
[...]

Thanks a lot for your analysis. The laptop is slowly dying so this can
be related.

> So yes, this looks like a hardware design error.  Turning off 
> autosuspend by writing to the sysfs power/control file is probably the 
> best way to handle the problem.

I can use that workaround. But it seems that this also prevents me from
suspending the maching into RAM with
PM: Some devices failed to suspend, or early wake event detected

:/

If there is any workaround for that then I would be really happy but
considering the overal state of the machine I suspect this is not the
case.

Thanks again for your great help!
-- 
Michal Hocko
SUSE Labs

Re: [fsnotify] c738fbabb0: will-it-scale.per_process_ops -9.5% regression

[Amir Goldstein]

On Tue, Jul 21, 2020 at 3:15 AM kernel test robot  wrote:
>
> Greeting,
>
> FYI, we noticed a -9.5% regression of will-it-scale.per_process_ops due to 
> commit:
>
>
> commit: c738fbabb0ff62d0f9a9572e56e65d05a1b34c6a ("fsnotify: fold fsnotify() 
> call into fsnotify_parent()")

Strange, that's a pretty dumb patch moving some inlined code from one
function to
another (assuming there are no fsnotify marks in this test).

Unless I am missing something the only thing that changes slightly is
an extra d_inode(file->f_path.dentry) deference.
I can get rid of it.

Is it possible to ask for a re-test with fix patch (attached)?

Thanks,
Amir.
From 26dc3d2bff623768cbbd0c8053ddd6390fd828d2 Mon Sep 17 00:00:00 2001
From: Amir Goldstein 
Date: Tue, 21 Jul 2020 18:52:18 +0300
Subject: [PATCH] fsnotify: pass inode to fsnotify_parent()

We can get inode by dereferenceing dentry->d_inode, but that may have
performance impact in the fast path of non watched file.

Kernel test robot reported a performance regression in concurrent open
workload, so maybe that can fix it.

Reported-by: kernel test robot 
Fixes: c738fbabb0ff ("fsnotify: fold fsnotify() call into fsnotify_parent()")
Signed-off-by: Amir Goldstein 
---
 include/linux/fsnotify.h | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/include/linux/fsnotify.h b/include/linux/fsnotify.h
index 316c9b820517..d49e5318aad9 100644
--- a/include/linux/fsnotify.h
+++ b/include/linux/fsnotify.h
@@ -46,10 +46,9 @@ static inline void fsnotify_dirent(struct inode *dir, struct 
dentry *dentry,
 
 /* Notify this dentry's parent about a child's events. */
 static inline int fsnotify_parent(struct dentry *dentry, __u32 mask,
- const void *data, int data_type)
+ const void *data, int data_type,
+ struct inode *inode)
 {
-   struct inode *inode = d_inode(dentry);
-
if (S_ISDIR(inode->i_mode))
mask |= FS_ISDIR;
 
@@ -68,7 +67,8 @@ static inline int fsnotify_parent(struct dentry *dentry, 
__u32 mask,
  */
 static inline void fsnotify_dentry(struct dentry *dentry, __u32 mask)
 {
-   fsnotify_parent(dentry, mask, d_inode(dentry), FSNOTIFY_EVENT_INODE);
+   fsnotify_parent(dentry, mask, d_inode(dentry), FSNOTIFY_EVENT_INODE,
+   d_inode(dentry));
 }
 
 static inline int fsnotify_file(struct file *file, __u32 mask)
@@ -78,7 +78,8 @@ static inline int fsnotify_file(struct file *file, __u32 mask)
if (file->f_mode & FMODE_NONOTIFY)
return 0;
 
-   return fsnotify_parent(path->dentry, mask, path, FSNOTIFY_EVENT_PATH);
+   return fsnotify_parent(path->dentry, mask, path, FSNOTIFY_EVENT_PATH,
+  file_inode(file));
 }
 
 /* Simple call site for access decisions */
-- 
2.17.1

Re: strace of io_uring events?

[Stefano Garzarella]

On Tue, Jul 21, 2020 at 08:27:34AM -0700, Andy Lutomirski wrote:
> On Fri, Jul 17, 2020 at 1:02 AM Stefano Garzarella  
> wrote:
> >
> > On Thu, Jul 16, 2020 at 08:12:35AM -0700, Kees Cook wrote:
> > > On Thu, Jul 16, 2020 at 03:14:04PM +0200, Stefano Garzarella wrote:
> 
> > > access (IIUC) is possible without actually calling any of the io_uring
> > > syscalls. Is that correct? A process would receive an fd (via SCM_RIGHTS,
> > > pidfd_getfd, or soon seccomp addfd), and then call mmap() on it to gain
> > > access to the SQ and CQ, and off it goes? (The only glitch I see is
> > > waking up the worker thread?)
> >
> > It is true only if the io_uring istance is created with SQPOLL flag (not the
> > default behaviour and it requires CAP_SYS_ADMIN). In this case the
> > kthread is created and you can also set an higher idle time for it, so
> > also the waking up syscall can be avoided.
> 
> I stared at the io_uring code for a while, and I'm wondering if we're
> approaching this the wrong way. It seems to me that most of the
> complications here come from the fact that io_uring SQEs don't clearly
> belong to any particular security principle.  (We have struct creds,
> but we don't really have a task or mm.)  But I'm also not convinced
> that io_uring actually supports cross-mm submission except by accident
> -- as it stands, unless a user is very careful to only submit SQEs
> that don't use user pointers, the results will be unpredictable.
> Perhaps we can get away with this:
> 
> diff --git a/fs/io_uring.c b/fs/io_uring.c
> index 74bc4a04befa..92266f869174 100644
> --- a/fs/io_uring.c
> +++ b/fs/io_uring.c
> @@ -7660,6 +7660,20 @@ SYSCALL_DEFINE6(io_uring_enter, unsigned int,
> fd, u32, to_submit,
>  if (!percpu_ref_tryget(>refs))
>  goto out_fput;
> 
> +if (unlikely(current->mm != ctx->sqo_mm)) {
> +/*
> + * The mm used to process SQEs will be current->mm or
> + * ctx->sqo_mm depending on which submission path is used.
> + * It's also unclear who is responsible for an SQE submitted
> + * out-of-process from a security and auditing perspective.
> + *
> + * Until a real usecase emerges and there are clear semantics
> + * for out-of-process submission, disallow it.
> + */
> +ret = -EACCES;
> +goto out;
> +}
> +
>  /*
>   * For SQ polling, the thread will do all submissions and completions.
>   * Just return the requested submit count, and wake the thread if
> 
> If we can do that, then we could bind seccomp-like io_uring filters to
> an mm, and we get obvious semantics that ought to cover most of the
> bases.
> 
> Jens, Christoph?
> 
> Stefano, what's your intended usecase for your restriction patchset?
> 

Hi Andy,
my use case concerns virtualization. The idea, that I described in the
proposal of io-uring restrictions [1], is to share io_uring CQ and SQ queues
with a guest VM for block operations.

In the PoC that I realized, there is a block device driver in the guest that
uses io_uring queues coming from the host to submit block requests.

Since the guest is not trusted, we need restrictions to allow only
a subset of syscalls on a subset of file descriptors and memory.


Cheers,
Stefano

[1] https://lore.kernel.org/io-uring/20200609142406.upuwpfmgqjeji4lc@steredhat/

Re: [PATCH v4 3/6] dt-bindings: remoteproc: Add common TI SCI rproc bindings

[Rob Herring]

On Fri, Jul 17, 2020 at 5:48 PM Suman Anna  wrote:
>
> Add a bindings document that lists the common TI SCI properties
> used by the K3 R5F and DSP remoteproc devices.
>
> Signed-off-by: Suman Anna 
> ---
> v4: Addressed both of Rob's review comments on ti,sci-proc-ids property
> v3: https://patchwork.kernel.org/patch/11602317/
>
>  .../bindings/remoteproc/ti,k3-sci-proc.yaml   | 48 +++
>  1 file changed, 48 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/remoteproc/ti,k3-sci-proc.yaml
>
> diff --git a/Documentation/devicetree/bindings/remoteproc/ti,k3-sci-proc.yaml 
> b/Documentation/devicetree/bindings/remoteproc/ti,k3-sci-proc.yaml
> new file mode 100644
> index ..0dca2ffdbc48
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/remoteproc/ti,k3-sci-proc.yaml
> @@ -0,0 +1,48 @@
> +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/remoteproc/ti,k3-sci-proc.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Common TI K3 remote processor device bindings
> +
> +maintainers:
> +  - Suman Anna 
> +
> +description: |
> +  The TI K3 family of SoCs usually have one or more remote processor 
> sub-systems
> +  like the dual-core R5F sub-system or a C66x or C71x DSP processor 
> subsystem.
> +  The device management of these remote processors is managed by a dedicated
> +  System Processor, and the communication with that processor is managed 
> through
> +  the TI-SCI protocol.
> +
> +  Each remote processor device node should define a common set of properties
> +  that allows the System Processor firmware to perform the device management
> +  such as powering the IPs, asserting/deasserting the resets for each of 
> these
> +  processors.
> +
> +properties:
> +  ti,sci:
> +$ref: /schemas/types.yaml#/definitions/phandle
> +description:
> +  Should be a phandle to the TI-SCI System Controller node
> +
> +  ti,sci-dev-id:
> +$ref: /schemas/types.yaml#/definitions/uint32
> +description: |
> +  Should contain the TI-SCI device id corresponding to the remote 
> processor
> +  core. Please refer to the corresponding System Controller documentation
> +  for valid values.

These also apply on Lokesh's series converting ti,sci-int[ra]
bindings. Please rework to use for both.

> +
> +  ti,sci-proc-ids:
> +description: Should contain a single tuple of .
> +$ref: /schemas/types.yaml#/definitions/uint32-array
> +items:
> +  - description: TI-SCI processor id for the remote processor device
> +  - description: TI-SCI host id to which processor control ownership
> + should be transferred to
> +
> +required:
> +  - ti,sci
> +  - ti,sci-dev-id
> +  - ti,sci-proc-ids
> --
> 2.26.0
>

Re: [PATCH V6 09/14] perf/x86/intel: Support TopDown metrics on Ice Lake

[Liang, Kan]

On 7/21/2020 10:31 AM, pet...@infradead.org wrote:

On Tue, Jul 21, 2020 at 10:23:36AM -0400, Liang, Kan wrote:


Patch 13 forces the slots event to be part of a metric group. In patch 7,
for a metric group, we only update the values once with slots event.
I think the normal case mentioned above should not happen.

+   /* Only need to call update_topdown_event() once for group read. */
+   if ((cpuc->txn_flags & PERF_PMU_TXN_READ) &&
+   !is_slots_event(event))
+   return;
+
+   perf_pmu_disable(event->pmu);
+   x86_pmu.update_topdown_event(event);
+   perf_pmu_enable(event->pmu);


Ah, I missed that.

That also requires SLOTS to be the leader so that it will be the first
read. Did we enforce that somewhere?


I think it's missed in the current patch set. The suggested code in 
patch 11 forces SLOTS to be the leader. I will apply it in V7.


Thanks,
Kan

Re: [PATCH -next] drm/nouveau/kms/nvd9-: Fix file release memory leak

[Lyude Paul]

Reviewed-by: Lyude Paul 

Thanks!

On Tue, 2020-07-21 at 15:17 +, Wei Yongjun wrote:
> When using single_open() for opening, single_release() should be
> used instead of seq_release(), otherwise there is a memory leak.
> 
> Fixes: 12885ecbfe62 ("drm/nouveau/kms/nvd9-: Add CRC support")
> Reported-by: Hulk Robot 
> Signed-off-by: Wei Yongjun 
> ---
>  drivers/gpu/drm/nouveau/dispnv50/crc.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/crc.c
> b/drivers/gpu/drm/nouveau/dispnv50/crc.c
> index f17fb6d56757..4971a1042415 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/crc.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/crc.c
> @@ -706,6 +706,7 @@ static const struct file_operations
> nv50_crc_flip_threshold_fops = {
>   .open = nv50_crc_debugfs_flip_threshold_open,
>   .read = seq_read,
>   .write = nv50_crc_debugfs_flip_threshold_set,
> + .release = single_release,
>  };
>  
>  int nv50_head_crc_late_register(struct nv50_head *head)
> 
> 
> 
-- 
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat

Re: [RFC PATCH] mm: silence soft lockups from unlock_page

[Michal Hocko]

On Tue 21-07-20 08:33:33, Linus Torvalds wrote:
> On Mon, Jul 20, 2020 at 11:33 PM Michal Hocko  wrote:
> >
> > The lockup is in page_unlock in do_read_fault and I suspect that this is
> > yet another effect of a very long waitqueue chain which has been
> > addresses by 11a19c7b099f ("sched/wait: Introduce wakeup boomark in
> > wake_up_page_bit") previously.
> 
> Hmm.
> 
> I do not believe that you can actually get to the point where you have
> a million waiters and it takes 20+ seconds to wake everybody up.

I was really suprised as well!

> More likely, it's actually *caused* by that commit 11a19c7b099f, and
> what might be happening is that other CPU's are just adding new
> waiters to the list *while* we're waking things up, because somebody
> else already got the page lock again.
> 
> Humor me.. Does something like this work instead? It's
> whitespace-damaged because of just a cut-and-paste, but it's entirely
> untested, and I haven't really thought about any memory ordering
> issues, but I think it's ok.
> 
> The logic is that anybody who called wake_up_page_bit() _must_ have
> cleared that bit before that. So if we ever see it set again (and
> memory ordering doesn't matter), then clearly somebody else got access
> to the page bit (whichever it was), and we should not
> 
>  (a) waste time waking up people who can't get the bit anyway
> 
>  (b) be in a  livelock where other CPU's continually add themselves to
> the wait queue because somebody else got the bit.
> 
> and it's that (b) case that I think happens for you.
> 
> NOTE! Totally UNTESTED patch follows. I think it's good, but maybe
> somebody sees some problem with this approach?

I can ask them to give it a try.

-- 
Michal Hocko
SUSE Labs

Re: [PATCH v7 03/14] PCI: cadence: Convert all r/w accessors to perform only 32-bit accesses

[Lorenzo Pieralisi]

On Mon, Jul 13, 2020 at 04:31:30PM +0530, Kishon Vijay Abraham I wrote:
> Certain platforms like TI's J721E using Cadence PCIe IP can perform only
> 32-bit accesses for reading or writing to Cadence registers. Convert all
> read and write accesses to 32-bit in Cadence PCIe driver in preparation
> for adding PCIe support in TI's J721E SoC.
> 
> Also add spin lock to disable interrupts while modifying PCI_STATUS
> register while raising legacy interrupt since PCI_STATUS is accessible
> by both remote RC and EP and time between read and write should be
> minimized.
> 
> Signed-off-by: Kishon Vijay Abraham I 
> ---
>  .../pci/controller/cadence/pcie-cadence-ep.c  |  4 +
>  drivers/pci/controller/cadence/pcie-cadence.h | 76 ++-
>  2 files changed, 62 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/pci/controller/cadence/pcie-cadence-ep.c 
> b/drivers/pci/controller/cadence/pcie-cadence-ep.c
> index 4a829ccff7d0..c6eb2db94680 100644
> --- a/drivers/pci/controller/cadence/pcie-cadence-ep.c
> +++ b/drivers/pci/controller/cadence/pcie-cadence-ep.c
> @@ -228,6 +228,7 @@ static void cdns_pcie_ep_assert_intx(struct cdns_pcie_ep 
> *ep, u8 fn,
>u8 intx, bool is_asserted)
>  {
>   struct cdns_pcie *pcie = >pcie;
> + unsigned long flags;
>   u32 offset;
>   u16 status;
>   u8 msg_code;
> @@ -252,11 +253,13 @@ static void cdns_pcie_ep_assert_intx(struct 
> cdns_pcie_ep *ep, u8 fn,
>   msg_code = MSG_CODE_DEASSERT_INTA + intx;
>   }
>  
> + spin_lock_irqsave(>lock, flags);
>   status = cdns_pcie_ep_fn_readw(pcie, fn, PCI_STATUS);
>   if (((status & PCI_STATUS_INTERRUPT) != 0) ^ (ep->irq_pending != 0)) {
>   status ^= PCI_STATUS_INTERRUPT;
>   cdns_pcie_ep_fn_writew(pcie, fn, PCI_STATUS, status);
>   }
> + spin_unlock_irqrestore(>lock, flags);
>  
>   offset = CDNS_PCIE_NORMAL_MSG_ROUTING(MSG_ROUTING_LOCAL) |
>CDNS_PCIE_NORMAL_MSG_CODE(msg_code) |
> @@ -464,6 +467,7 @@ int cdns_pcie_ep_setup(struct cdns_pcie_ep *ep)
>   ep->irq_pci_addr = CDNS_PCIE_EP_IRQ_PCI_ADDR_NONE;
>   /* Reserve region 0 for IRQs */
>   set_bit(0, >ob_region_map);
> + spin_lock_init(>lock);
>  
>   return 0;
>  
> diff --git a/drivers/pci/controller/cadence/pcie-cadence.h 
> b/drivers/pci/controller/cadence/pcie-cadence.h
> index bc49c22e48a9..a45c11158f49 100644
> --- a/drivers/pci/controller/cadence/pcie-cadence.h
> +++ b/drivers/pci/controller/cadence/pcie-cadence.h
> @@ -304,6 +304,9 @@ struct cdns_pcie_rc {
>   * @irq_pci_fn: the latest PCI function that has updated the mapping of
>   *   the MSI/legacy IRQ dedicated outbound region.
>   * @irq_pending: bitmask of asserted legacy IRQs.
> + * @lock: spin lock to disable interrupts while modifying PCIe controller
> + *registers fields (RMW) accessible by both remote RC and EP to
> + *minimize time between read and write
>   */
>  struct cdns_pcie_ep {
>   struct cdns_pciepcie;
> @@ -315,54 +318,94 @@ struct cdns_pcie_ep {
>   u64 irq_pci_addr;
>   u8  irq_pci_fn;
>   u8  irq_pending;
> + /* protect writing to PCI_STATUS while raising legacy interrupts */
> + spinlock_t  lock;
>  };
>  
>  
>  /* Register access */
> -static inline void cdns_pcie_writeb(struct cdns_pcie *pcie, u32 reg, u8 
> value)
> +static inline void cdns_pcie_writel(struct cdns_pcie *pcie, u32 reg, u32 
> value)
>  {
> - writeb(value, pcie->reg_base + reg);
> + writel(value, pcie->reg_base + reg);
>  }
>  
> -static inline void cdns_pcie_writew(struct cdns_pcie *pcie, u32 reg, u16 
> value)
> +static inline u32 cdns_pcie_readl(struct cdns_pcie *pcie, u32 reg)
>  {
> - writew(value, pcie->reg_base + reg);
> + return readl(pcie->reg_base + reg);
>  }
>  
> -static inline void cdns_pcie_writel(struct cdns_pcie *pcie, u32 reg, u32 
> value)
> +static inline u32 cdns_pcie_read_sz(void __iomem *addr, int size)
>  {
> - writel(value, pcie->reg_base + reg);
> + void __iomem *aligned_addr = PTR_ALIGN_DOWN(addr, 0x4);
> + unsigned int offset = (unsigned long)addr & 0x3;
> + u32 val = readl(aligned_addr);
> +
> + if (!IS_ALIGNED((uintptr_t)addr, size)) {
> + WARN(1, "Address %p and size %d are not aligned\n", addr, size);

This is overkill - please consider a less severe logging (eg pr_warn()).

https://www.kernel.org/doc/html/latest/process/deprecated.html

Same below. I can make these changes before applying but the series
does not apply to v5.8-rc1, please rebase it and I will apply then.

Thanks,
Lorenzo

> + return 0;
> + }
> +
> + if (size > 2)
> + return val;
> +
> + return (val >> (8 * offset)) & ((1 << (size * 8)) - 1);
>  }
>  
> -static inline u32 cdns_pcie_readl(struct cdns_pcie *pcie, u32 reg)
> +static inline void cdns_pcie_write_sz(void 

Re: [PATCH v2 3/3] ARM: dts: stm32: add initial support for stm32mp157-odyssey board

[Ahmad Fatoum]

Hello Marcin,

On 7/21/20 5:20 PM, Marcin Sloniewski wrote:
> Add support for Seeed Studio's stm32mp157c odyssey board.
> Board consists of SoM with stm32mp157c with 4GB eMMC and 512 MB DDR3 RAM
> and carrier board with USB and ETH interfaces, SD card connector,
> wifi and BT chip AP6236.
> 
> In this patch only basic kernel boot is supported and interfacing
> SD card and on-board eMMC.
> 
> Signed-off-by: Marcin Sloniewski 
> ---
> 
> Changes in v2:
> - add new odyssey dts to Makefile
> 
>  arch/arm/boot/dts/Makefile|   3 +-
>  .../arm/boot/dts/stm32mp157c-odyssey-som.dtsi | 276 ++
>  arch/arm/boot/dts/stm32mp157c-odyssey.dts |  72 +
>  3 files changed, 350 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm/boot/dts/stm32mp157c-odyssey-som.dtsi
>  create mode 100644 arch/arm/boot/dts/stm32mp157c-odyssey.dts
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index e6a1cac0bfc7..a3ea2301c82c 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -1047,7 +1047,8 @@ dtb-$(CONFIG_ARCH_STM32) += \
>   stm32mp157c-dk2.dtb \
>   stm32mp157c-ed1.dtb \
>   stm32mp157c-ev1.dtb \
> - stm32mp157c-lxa-mc1.dtb
> + stm32mp157c-lxa-mc1.dtb \
> + stm32mp157c-odyssey.dtb
>  dtb-$(CONFIG_MACH_SUN4I) += \
>   sun4i-a10-a1000.dtb \
>   sun4i-a10-ba10-tvbox.dtb \
> diff --git a/arch/arm/boot/dts/stm32mp157c-odyssey-som.dtsi 
> b/arch/arm/boot/dts/stm32mp157c-odyssey-som.dtsi
> new file mode 100644
> index ..620ff9e7f370
> --- /dev/null
> +++ b/arch/arm/boot/dts/stm32mp157c-odyssey-som.dtsi
> @@ -0,0 +1,276 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
> +/*
> + * Copyright (C) 2020 Marcin Sloniewski .
> + */
> +
> +/dts-v1/;
> +
> +#include "stm32mp157.dtsi"
> +#include "stm32mp15xc.dtsi"
> +#include "stm32mp15-pinctrl.dtsi"
> +#include "stm32mp15xxac-pinctrl.dtsi"
> +#include 
> +#include 
> +
> +/ {
> + model = "Seeed Studio Odyssey-STM32MP157C SOM";
> + compatible = "seeed,stm32mp157c-odyssey-som", "st,stm32mp157";
> +
> + memory@c000 {
> + reg = <0xc000 0x2000>;
> + };

device_type = "memory"; is mandatory here per spec. There is no longer a 
skeleton.dtsi
that adds this for you.

> +
> + reserved-memory {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + mcuram2: mcuram2@1000 {
> + compatible = "shared-dma-pool";
> + reg = <0x1000 0x4>;
> + no-map;
> + };
> +
> + vdev0vring0: vdev0vring0@1004 {
> + compatible = "shared-dma-pool";
> + reg = <0x1004 0x1000>;
> + no-map;
> + };
> +
> + vdev0vring1: vdev0vring1@10041000 {
> + compatible = "shared-dma-pool";
> + reg = <0x10041000 0x1000>;
> + no-map;
> + };
> +
> + vdev0buffer: vdev0buffer@10042000 {
> + compatible = "shared-dma-pool";
> + reg = <0x10042000 0x4000>;
> + no-map;
> + };
> +
> + mcuram: mcuram@3000 {
> + compatible = "shared-dma-pool";
> + reg = <0x3000 0x4>;
> + no-map;
> + };
> +
> + retram: retram@3800 {
> + compatible = "shared-dma-pool";
> + reg = <0x3800 0x1>;
> + no-map;
> + };
> +
> + gpu_reserved: gpu@d400 {
> + reg = <0xd400 0x400>;
> + no-map;
> + };
> + };
> +
> + led {
> + compatible = "gpio-leds";
> + blue {

This is not aligned with the leds-gpio.yaml binding. You could change it to 
led-blue.
Run dtbs_check to find maybe more such issues.

> + label = "heartbeat";

Per binding this is deprecated. Function/color should be used instead.

> + gpios = < 3 GPIO_ACTIVE_HIGH>;
> + linux,default-trigger = "heartbeat";
> + default-state = "off";

Does it make sense to have a trigger but still default-state = "off"?

> + };
> + };
> +};
> +
> + {
> + contiguous-area = <_reserved>;
> + status = "okay";
> +};
> +
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins_a>;
> + i2c-scl-rising-time-ns = <185>;
> + i2c-scl-falling-time-ns = <20>;
> + status = "okay";
> + /* spare dmas for other usage */
> + /delete-property/dmas;
> + /delete-property/dma-names;
> +
> + pmic: stpmic@33 {
> + compatible = "st,stpmic1";
> + reg = <0x33>;
> + interrupts-extended = < 0 

Re: arm: tinyconfig: entry-common.S:156: Error: r13 not allowed here -- `bic tsk,sp,#(((1<<12)<<1)-1)&~63'

[Russell King - ARM Linux admin]

On Tue, Jul 21, 2020 at 05:43:15PM +0200, Arnd Bergmann wrote:
> On Tue, Jul 21, 2020 at 5:07 PM Naresh Kamboju
>  wrote:
> >
> > This might add little value.
> >
> > arm build sets failed on linux next 20200721.
> > The defconfig ( +config fragments ) builds PASS.
> > The tinyconfig and allnoconfig FAILED with gcc-8, gcc-9 and gcc-10.
> >
> > make -sk KBUILD_BUILD_USER=TuxBuild -C/linux -j32 ARCH=arm
> > CROSS_COMPILE=arm-linux-gnueabihf- HOSTCC=gcc CC="sccache
> > arm-linux-gnueabihf-gcc" O=build zImage
> > #
> > ../arch/arm/kernel/entry-common.S: Assembler messages:
> > ../arch/arm/kernel/entry-common.S:156: Error: r13 not allowed here --
> > `bic tsk,sp,#(((1<<12)<<1)-1)&~63'
> > ../arch/arm/kernel/entry-common.S:243: Error: r13 not allowed here --
> > `bic tsk,sp,#(((1<<12)<<1)-1)&~63'
> > make[3]: *** [../scripts/Makefile.build:361:
> > arch/arm/kernel/entry-common.o] Error 1
> > ../arch/arm/kernel/entry-v7m.S: Assembler messages:
> > ../arch/arm/kernel/entry-v7m.S:60: Error: r13 not allowed here -- `bic
> > tsk,sp,#(((1<<12)<<1)-1)&~63'
> > ../arch/arm/kernel/entry-v7m.S:86: Error: r13 not allowed here -- `bic
> > tsk,sp,#(((1<<12)<<1)-1)&~63'
> > make[3]: *** [../scripts/Makefile.build:361:
> > arch/arm/kernel/entry-v7m.o] Error 1
> >
> > full build link,
> > https://gitlab.com/Linaro/lkft/kernel-runs/-/jobs/648560264
> 
> This must come from
> ac5bb8f8445f ("ARM: 8983/1: asm: Rewrite get_thread_info using BIC")
> 
> Adding Linus and Ard to Cc as well.

Absolutely no point.

It was known about last night (see your irc scrollback - I mentioned it
to sfr).  It was reported earlier this afternoon just after I dropped
the commit.  It's now been reported again.

So, please ignore these reports.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

Re: [PATCH v3 00/14] Enable GPU for SM8150 and SM8250

[Dmitry Baryshkov]

On 21/07/2020 10:54, Stephen Boyd wrote:

Quoting Jonathan Marek (2020-07-09 06:52:31)

This series adds the missing clock drivers and dts nodes to enable
the GPU on both SM8150 and SM8250.

Note an extra drm/msm patch [1] is required for SM8250.

As noted by Dmitry, GMU init fails with newer firmware, needs this patch [2].

[1] https://patchwork.freedesktop.org/series/78968/
[2] 
https://git.linaro.org/landing-teams/working/qualcomm/kernel.git/commit/?h=tracking-qcomlt-sm8250=01331f2ccbe7e6c4719dbe038a5fb496db32646d


Vinod, can you test this patch series? And Taniya, can you review it?


On SM8250:

Tested-by: Dmitry Baryshkov 


--
With best wishes
Dmitry

Re: [PATCH 1/1] iommu/arm-smmu: Implement qcom,skip-init

[Jordan Crouse]

On Tue, Jul 21, 2020 at 05:04:11PM +0200, Konrad Dybcio wrote:
> So.. is this a no-no?
> 
> I of course would like to omit this entirely, but SMMUs on sdm630 and
> friends are REALLY picky.. What seems to happen is that when the
> driver tries to do things the "standard" way, hypervisor decides to
> hang the platform or force a reboot. Not very usable.
> 
> 
> This thing is needed for the platform to even boot properly and one
> more [1] is required to make mdss work with video mode panels (the
> fact that CMD-mode panels work is kinda hilarious to me).
> 
> To be honest, there are even more qcom quirks (of which at least
> qcom,dynamic and qcom-use-3-lvl-tables are used on 630).. [2]
> 
> Looking forward to your answers and possibly better solutions.

Nobody is disputing that the qcom SMMUs don't have their share of quirks but it
seems that the community has mostly settled on the agreement that there are
better ways to solve this than a handful of device tree properties. The current
focus has been on moving more of the SMMU specific bits into the arm-smmu-qcom
implementation [1] and I think that is the right way to go.

As for the other quirks we can probably discuss those on a case by case basis.
I doubt you will find much enthusiasm for qcom,use-3-lvl-tables and I've been
working on replacing qcom,dynamic with something much better [2].

[1] https://lists.linuxfoundation.org/pipermail/iommu/2020-July/046304.html
[2] https://lists.linuxfoundation.org/pipermail/iommu/2020-July/046756.html

Jordan

> [1] 
> https://github.com/konradybcio/linux/commit/83ac38af259968f92b6a8b7eab90096c78469f87
> [2] 
> https://github.com/sonyxperiadev/kernel/blob/aosp/LA.UM.7.1.r1/drivers/iommu/arm-smmu.c#L404-L415
> 
> Regards
> Konrad

-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: arm: tinyconfig: entry-common.S:156: Error: r13 not allowed here -- `bic tsk,sp,#(((1<<12)<<1)-1)&~63'

[Arnd Bergmann]

On Tue, Jul 21, 2020 at 5:07 PM Naresh Kamboju
 wrote:
>
> This might add little value.
>
> arm build sets failed on linux next 20200721.
> The defconfig ( +config fragments ) builds PASS.
> The tinyconfig and allnoconfig FAILED with gcc-8, gcc-9 and gcc-10.
>
> make -sk KBUILD_BUILD_USER=TuxBuild -C/linux -j32 ARCH=arm
> CROSS_COMPILE=arm-linux-gnueabihf- HOSTCC=gcc CC="sccache
> arm-linux-gnueabihf-gcc" O=build zImage
> #
> ../arch/arm/kernel/entry-common.S: Assembler messages:
> ../arch/arm/kernel/entry-common.S:156: Error: r13 not allowed here --
> `bic tsk,sp,#(((1<<12)<<1)-1)&~63'
> ../arch/arm/kernel/entry-common.S:243: Error: r13 not allowed here --
> `bic tsk,sp,#(((1<<12)<<1)-1)&~63'
> make[3]: *** [../scripts/Makefile.build:361:
> arch/arm/kernel/entry-common.o] Error 1
> ../arch/arm/kernel/entry-v7m.S: Assembler messages:
> ../arch/arm/kernel/entry-v7m.S:60: Error: r13 not allowed here -- `bic
> tsk,sp,#(((1<<12)<<1)-1)&~63'
> ../arch/arm/kernel/entry-v7m.S:86: Error: r13 not allowed here -- `bic
> tsk,sp,#(((1<<12)<<1)-1)&~63'
> make[3]: *** [../scripts/Makefile.build:361:
> arch/arm/kernel/entry-v7m.o] Error 1
>
> full build link,
> https://gitlab.com/Linaro/lkft/kernel-runs/-/jobs/648560264

This must come from
ac5bb8f8445f ("ARM: 8983/1: asm: Rewrite get_thread_info using BIC")

Adding Linus and Ard to Cc as well.

   Arnd

[PATCH v3] mm: Fix kthread_use_mm() vs TLB invalidate

[Peter Zijlstra]

For SMP systems using IPI based TLB invalidation, looking at
current->active_mm is entirely reasonable. This then presents the
following race condition:


  CPU0  CPU1

  flush_tlb_mm(mm)  use_mm(mm)

  tsk->active_mm = mm;
  
if (tsk->active_mm == mm)
  // flush TLBs
  
  switch_mm(old_mm,mm,tsk);


Where it is possible the IPI flushed the TLBs for @old_mm, not @mm,
because the IPI lands before we actually switched.

Avoid this by disabling IRQs across changing ->active_mm and
switch_mm().

[ There are all sorts of reasons this might be harmless for various
architecture specific reasons, but best not leave the door open at
all. ]

Cc: sta...@kernel.org
Reported-by: Andy Lutomirski 
Signed-off-by: Peter Zijlstra (Intel) 
---

Sorry, I dropped the ball on this and only found it because I was
looking at the whole membarrier things vs use_mm().


 kernel/kthread.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/kernel/kthread.c b/kernel/kthread.c
index 1d9e2fdfd67a..7221dcbffef3 100644
--- a/kernel/kthread.c
+++ b/kernel/kthread.c
@@ -1241,13 +1241,15 @@ void kthread_use_mm(struct mm_struct *mm)
WARN_ON_ONCE(tsk->mm);
 
task_lock(tsk);
+   local_irq_disable();
active_mm = tsk->active_mm;
if (active_mm != mm) {
mmgrab(mm);
tsk->active_mm = mm;
}
tsk->mm = mm;
-   switch_mm(active_mm, mm, tsk);
+   switch_mm_irqs_off(active_mm, mm, tsk);
+   local_irq_enable();
task_unlock(tsk);
 #ifdef finish_arch_post_lock_switch
finish_arch_post_lock_switch();
@@ -1276,9 +1278,11 @@ void kthread_unuse_mm(struct mm_struct *mm)
 
task_lock(tsk);
sync_mm_rss(mm);
+   local_irq_disable();
tsk->mm = NULL;
/* active_mm is still 'mm' */
enter_lazy_tlb(mm, tsk);
+   local_irq_enable();
task_unlock(tsk);
 }
 EXPORT_SYMBOL_GPL(kthread_unuse_mm);

Re: [PATCH 2/4] printk: store instead of processing cont parts

[Linus Torvalds]

On Tue, Jul 21, 2020 at 7:42 AM Sergey Senozhatsky
 wrote:
>
> OK, so basically, extending printk_caller_id() so that for IRQ/NMI
> we will have more info than just "0x8000 + raw_smp_processor_id()".

I think it's really preempt_count() that we want to have there.

That has the softirq/hardirq/NMI information in it.

So the "context" identifier of an incomplete write would be { task,
cpu, preempt_count() } of the writer. If a new KERN_CONT writer comes
in, it would have to match in that context to actually combine.

You can probably play "hide the bits" tricks to not *ac tually* use
three words for it. The task structure in particular tends to be very
aligned, you could hide bits in the low bits there. The CPU number
would fit in there, for example.

 Linus

Re: [PATCH] sched: Fix race against ptrace_freeze_trace()

[Oleg Nesterov]

On 07/21, Peter Zijlstra wrote:
>
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -4193,9 +4193,6 @@ static void __sched notrace __schedule(b
>   local_irq_disable();
>   rcu_note_context_switch(preempt);
>
> - /* See deactivate_task() below. */
> - prev_state = prev->state;
> -
>   /*
>* Make sure that signal_pending_state()->signal_pending() below
>* can't be reordered with __set_current_state(TASK_INTERRUPTIBLE)
> @@ -4219,11 +4216,16 @@ static void __sched notrace __schedule(b
>   update_rq_clock(rq);
>
>   switch_count = >nivcsw;
> +
>   /*
> -  * We must re-load prev->state in case ttwu_remote() changed it
> -  * before we acquired rq->lock.
> +  * We must load prev->state once (task_struct::state is volatile), such
> +  * that:
> +  *
> +  *  - we form a control dependency vs deactivate_task() below.
> +  *  - ptrace_{,un}freeze_traced() can change ->state underneath us.
>*/
> - if (!preempt && prev_state && prev_state == prev->state) {
> + prev_state = prev->state;
> + if (!preempt && prev_state) {

Thanks! FWIW,

Acked-by: Oleg Nesterov 

[PATCH v4 1/3] powerpc/powernv/idle: Replace CPU features check with PVR check

[Pratik Rajesh Sampat]

As the idle framework's architecture is incomplete, hence instead of
checking for just the processor type advertised in the device tree CPU
features; check for the Processor Version Register (PVR) so that finer
granularity can be leveraged while making processor checks.

Hence, making the PVR check on the outer level function, subsequently in
the hierarchy keeping the CPU_FTR_ARCH_300 check intact as it is a
faster check to do because of static branches

Signed-off-by: Pratik Rajesh Sampat 
---
 arch/powerpc/platforms/powernv/idle.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/platforms/powernv/idle.c 
b/arch/powerpc/platforms/powernv/idle.c
index 2dd467383a88..642abf0b8329 100644
--- a/arch/powerpc/platforms/powernv/idle.c
+++ b/arch/powerpc/platforms/powernv/idle.c
@@ -1205,7 +1205,7 @@ static void __init pnv_probe_idle_states(void)
return;
}
 
-   if (cpu_has_feature(CPU_FTR_ARCH_300))
+   if (pvr_version_is(PVR_POWER9))
pnv_power9_idle_init();
 
for (i = 0; i < nr_pnv_idle_states; i++)
-- 
2.25.4

[PATCH v4 3/3] powerpc/powernv/idle: Exclude mfspr on HID1,4,5 on P9 and above

[Pratik Rajesh Sampat]

POWER9 onwards the support for the registers HID1, HID4, HID5 has been
receded.
Although mfspr on the above registers worked in Power9, In Power10
simulator is unrecognized. Moving their assignment under the
check for machines lower than Power9

Signed-off-by: Pratik Rajesh Sampat 
Reviewed-by: Gautham R. Shenoy 
Reviewed-by: Nicholas Piggin 
---
 arch/powerpc/platforms/powernv/idle.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/platforms/powernv/idle.c 
b/arch/powerpc/platforms/powernv/idle.c
index 28462d59a8e1..92098d6106be 100644
--- a/arch/powerpc/platforms/powernv/idle.c
+++ b/arch/powerpc/platforms/powernv/idle.c
@@ -73,9 +73,6 @@ static int pnv_save_sprs_for_deep_states(void)
 */
uint64_t lpcr_val   = mfspr(SPRN_LPCR);
uint64_t hid0_val   = mfspr(SPRN_HID0);
-   uint64_t hid1_val   = mfspr(SPRN_HID1);
-   uint64_t hid4_val   = mfspr(SPRN_HID4);
-   uint64_t hid5_val   = mfspr(SPRN_HID5);
uint64_t hmeer_val  = mfspr(SPRN_HMEER);
uint64_t msr_val = MSR_IDLE;
uint64_t psscr_val = pnv_deepest_stop_psscr_val;
@@ -117,6 +114,9 @@ static int pnv_save_sprs_for_deep_states(void)
 
/* Only p8 needs to set extra HID regiters */
if (!cpu_has_feature(CPU_FTR_ARCH_300)) {
+   uint64_t hid1_val = mfspr(SPRN_HID1);
+   uint64_t hid4_val = mfspr(SPRN_HID4);
+   uint64_t hid5_val = mfspr(SPRN_HID5);
 
rc = opal_slw_set_reg(pir, SPRN_HID1, hid1_val);
if (rc != 0)
-- 
2.25.4

[PATCH v4 0/3] powernv/idle: Power9 idle cleanup

[Pratik Rajesh Sampat]

v3: https://lkml.org/lkml/2020/7/17/1093
Changelog v3-->v4:
Based on comments from Nicholas Piggin and Gautham Shenoy,
1. Changed the naming of pnv_first_spr_loss_level from
pnv_first_fullstate_loss_level to deep_spr_loss_state
2. Make the P9 PVR check only on the top level function
pnv_probe_idle_states and let the rest of the checks be DT based because
it is faster to do so

Pratik Rajesh Sampat (3):
  powerpc/powernv/idle: Replace CPU features check with PVR check
  powerpc/powernv/idle: Rename pnv_first_spr_loss_level variable
  powerpc/powernv/idle: Exclude mfspr on HID1,4,5 on P9 and above

 arch/powerpc/platforms/powernv/idle.c | 26 +-
 1 file changed, 13 insertions(+), 13 deletions(-)

-- 
2.25.4

[PATCH v4 2/3] powerpc/powernv/idle: Rename pnv_first_spr_loss_level variable

[Pratik Rajesh Sampat]

Replace the variable name from using "pnv_first_spr_loss_level" to
"deep_spr_loss_state".

pnv_first_spr_loss_level is supposed to be the earliest state that
has OPAL_PM_LOSE_FULL_CONTEXT set, in other places the kernel uses the
"deep" states as terminology. Hence renaming the variable to be coherent
to its semantics.

Signed-off-by: Pratik Rajesh Sampat 
---
 arch/powerpc/platforms/powernv/idle.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/arch/powerpc/platforms/powernv/idle.c 
b/arch/powerpc/platforms/powernv/idle.c
index 642abf0b8329..28462d59a8e1 100644
--- a/arch/powerpc/platforms/powernv/idle.c
+++ b/arch/powerpc/platforms/powernv/idle.c
@@ -48,7 +48,7 @@ static bool default_stop_found;
  * First stop state levels when SPR and TB loss can occur.
  */
 static u64 pnv_first_tb_loss_level = MAX_STOP_STATE + 1;
-static u64 pnv_first_spr_loss_level = MAX_STOP_STATE + 1;
+static u64 deep_spr_loss_state = MAX_STOP_STATE + 1;
 
 /*
  * psscr value and mask of the deepest stop idle state.
@@ -657,7 +657,7 @@ static unsigned long power9_idle_stop(unsigned long psscr, 
bool mmu_on)
  */
mmcr0   = mfspr(SPRN_MMCR0);
}
-   if ((psscr & PSSCR_RL_MASK) >= pnv_first_spr_loss_level) {
+   if ((psscr & PSSCR_RL_MASK) >= deep_spr_loss_state) {
sprs.lpcr   = mfspr(SPRN_LPCR);
sprs.hfscr  = mfspr(SPRN_HFSCR);
sprs.fscr   = mfspr(SPRN_FSCR);
@@ -741,7 +741,7 @@ static unsigned long power9_idle_stop(unsigned long psscr, 
bool mmu_on)
 * just always test PSSCR for SPR/TB state loss.
 */
pls = (psscr & PSSCR_PLS) >> PSSCR_PLS_SHIFT;
-   if (likely(pls < pnv_first_spr_loss_level)) {
+   if (likely(pls < deep_spr_loss_state)) {
if (sprs_saved)
atomic_stop_thread_idle();
goto out;
@@ -1088,7 +1088,7 @@ static void __init pnv_power9_idle_init(void)
 * the deepest loss-less (OPAL_PM_STOP_INST_FAST) stop state.
 */
pnv_first_tb_loss_level = MAX_STOP_STATE + 1;
-   pnv_first_spr_loss_level = MAX_STOP_STATE + 1;
+   deep_spr_loss_state = MAX_STOP_STATE + 1;
for (i = 0; i < nr_pnv_idle_states; i++) {
int err;
struct pnv_idle_states_t *state = _idle_states[i];
@@ -1099,8 +1099,8 @@ static void __init pnv_power9_idle_init(void)
pnv_first_tb_loss_level = psscr_rl;
 
if ((state->flags & OPAL_PM_LOSE_FULL_CONTEXT) &&
-(pnv_first_spr_loss_level > psscr_rl))
-   pnv_first_spr_loss_level = psscr_rl;
+(deep_spr_loss_state > psscr_rl))
+   deep_spr_loss_state = psscr_rl;
 
/*
 * The idle code does not deal with TB loss occurring
@@ -,8 +,8 @@ static void __init pnv_power9_idle_init(void)
 * compatibility.
 */
if ((state->flags & OPAL_PM_TIMEBASE_STOP) &&
-(pnv_first_spr_loss_level > psscr_rl))
-   pnv_first_spr_loss_level = psscr_rl;
+(deep_spr_loss_state > psscr_rl))
+   deep_spr_loss_state = psscr_rl;
 
err = validate_psscr_val_mask(>psscr_val,
  >psscr_mask,
@@ -1158,7 +1158,7 @@ static void __init pnv_power9_idle_init(void)
}
 
pr_info("cpuidle-powernv: First stop level that may lose SPRs = 
0x%llx\n",
-   pnv_first_spr_loss_level);
+   deep_spr_loss_state);
 
pr_info("cpuidle-powernv: First stop level that may lose timebase = 
0x%llx\n",
pnv_first_tb_loss_level);
-- 
2.25.4

[PATCH v4 2/3] MAINTAINERS: Add Purism Librem 5 section to the list

[Martin Kepplinger]

Add development information for the devicetree files for hardware
by Purism SPC.

Signed-off-by: Martin Kepplinger 
---
 MAINTAINERS | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 760b5d02e726..46ff4d67ff1c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -13932,6 +13932,13 @@ T: git git://linuxtv.org/media_tree.git
 F: Documentation/admin-guide/media/pulse8-cec.rst
 F: drivers/media/cec/usb/pulse8/
 
+PURISM LIBREM 5
+M: Purism Kernel Team 
+S: Supported
+B: https://source.puri.sm/Librem5/linux-next/issues
+T: https://source.puri.sm/Librem5/linux-next
+F: arch/arm64/boot/dts/freescale/imx8mq-librem5*
+
 PVRUSB2 VIDEO4LINUX DRIVER
 M: Mike Isely 
 L: pvru...@isely.net   (subscribers-only)
-- 
2.20.1

[PATCH v4 3/3] dt-bindings: arm: fsl: Add the librem 5 phone

[Martin Kepplinger]

Add entries for the imx8mq based Librem 5 phone. The "Birch" and
"Chestnut" hardware revisions are supported by r2. The "Dogwood"
revision by r3.
See https://puri.sm/products/librem-5/ and https://developer.puri.sm/Librem5/
for the schematics and more information.

Signed-off-by: Martin Kepplinger 
---
 Documentation/devicetree/bindings/arm/fsl.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml 
b/Documentation/devicetree/bindings/arm/fsl.yaml
index f63895c8ce2d..1cce4ff58ff8 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -365,6 +365,8 @@ properties:
   - fsl,imx8mq-evk# i.MX8MQ EVK Board
   - google,imx8mq-phanbell# Google Coral Edge TPU
   - purism,librem5-devkit # Purism Librem5 devkit
+  - purism,librem5r2  # Purism Librem5 phone "Chestnut"
+  - purism,librem5r3  # Purism Librem5 phone "Dogwood"
   - solidrun,hummingboard-pulse # SolidRun Hummingboard Pulse
   - technexion,pico-pi-imx8m  # TechNexion PICO-PI-8M evk
   - const: fsl,imx8mq
-- 
2.20.1

[PATCH v4 1/3] arm64: dts: Add a device tree for the Librem 5 phone

[Martin Kepplinger]

From: "Angus Ainslie (Purism)" 

Add a devicetree description for the Librem 5 phone. 4 hardware revisions
have been available. Some revisions include changes that need different
software to be run. So far, r3 ("Dogwood") is one such example, see:

"Aspen" r0  not supported (very few devices exist)
"Birch" r1  supported by r2
"Chestnut"  r2  added by this patch
"Dogwood"   r3  added by this patch
"Evergreen" r4  tba / most likely supported by r3

See https://puri.sm/products/librem-5/ for more information.

This boots to a working console with working WWAN modem, wifi usdhc,
IMU sensor device, proximity sensor, haptic motor, gpio keys, GNSS and LEDs.

Signed-off-by: Martin Kepplinger 
Signed-off-by: Angus Ainslie (Purism) 
Signed-off-by: Guido Günther 
For audio related part:
Reviewed-by: Daniel Baluta 
---


revision history

v4:
thanks a lot Shawn for reviewing. changes since v3:
 * rename to dtsi and split out r2 and r3 dts with revision specifics
 * add the USB2642 hard-wired Hub
 * fix charge controller boost-max-current
 * disable pullup on CHRG_INT (not needed due to external one)
 * add documentation for the boards' compatible strings
 * fix led-backlight propery usage
 * coding style fixes

v3:
thanks a lot Mark for reviewing! changes since v2:
 * nicer audio cards names
 * squash unneeded audio_pwr regulator
 * remove the susphy_quirk from dwc3_1 after more testing
 * add usdhc2 card detect via gpio
 * add headphone detect for audio card
https://lore.kernel.org/linux-arm-kernel/20200617073821.16737-1-martin.kepplin...@puri.sm/T/

v2:
thanks a lot Marco, Daniel and Pavel for reviewing. changes since v1:
 * alphabetical sortings / more consistent node names
 * remove unused regulator and pinctrl descriptions
 * generic labels for leds, backlight, flash and torch
 * audio clk settings moved to sai2 node
https://lore.kernel.org/linux-arm-kernel/20200604084756.586-1-martin.kepplin...@puri.sm/T/

v1:
https://lore.kernel.org/linux-arm-kernel/20200514155737.12160-1-martin.kepplin...@puri.sm/



 arch/arm64/boot/dts/freescale/Makefile|2 +
 .../boot/dts/freescale/imx8mq-librem5-r2.dts  |   26 +
 .../boot/dts/freescale/imx8mq-librem5-r3.dts  |   24 +
 .../boot/dts/freescale/imx8mq-librem5.dtsi| 1146 +
 4 files changed, 1198 insertions(+)
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mq-librem5-r2.dts
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mq-librem5-r3.dts
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi

diff --git a/arch/arm64/boot/dts/freescale/Makefile 
b/arch/arm64/boot/dts/freescale/Makefile
index a39f0a1723e0..97335205b600 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -35,6 +35,8 @@ dtb-$(CONFIG_ARCH_MXC) += imx8mp-evk.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mq-evk.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mq-hummingboard-pulse.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mq-librem5-devkit.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx8mq-librem5-r2.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx8mq-librem5-r3.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mq-nitrogen.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mq-phanbell.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mq-pico-pi.dtb
diff --git a/arch/arm64/boot/dts/freescale/imx8mq-librem5-r2.dts 
b/arch/arm64/boot/dts/freescale/imx8mq-librem5-r2.dts
new file mode 100644
index ..9f34b63cd4d2
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mq-librem5-r2.dts
@@ -0,0 +1,26 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+// Copyright (C) 2020 Purism SPC 
+//
+// Librem 5 Chestnut
+
+/dts-v1/;
+
+#include "imx8mq-librem5.dtsi"
+
+/ {
+   model = "Purism Librem 5r2";
+   compatible = "purism,librem5r2", "purism,librem5", "fsl,imx8mq";
+};
+
+ {
+   ti,battery-regulation-voltage = <4192000>; /* uV */
+   ti,charge-current = <160>; /* uA */
+   ti,termination-current = <66000>;  /* uA */
+};
+
+_gyro {
+   mount-matrix =  "1",  "0",  "0",
+   "0", "-1",  "0",
+   "0",  "0",  "1";
+};
+
diff --git a/arch/arm64/boot/dts/freescale/imx8mq-librem5-r3.dts 
b/arch/arm64/boot/dts/freescale/imx8mq-librem5-r3.dts
new file mode 100644
index ..64027ba4754e
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mq-librem5-r3.dts
@@ -0,0 +1,24 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+// Copyright (C) 2020 Purism SPC 
+
+/dts-v1/;
+
+#include "imx8mq-librem5.dtsi"
+
+/ {
+   model = "Purism Librem 5r3";
+   compatible = "purism,librem5r3", "purism,librem5", "fsl,imx8mq";
+};
+
+ {
+   ti,battery-regulation-voltage = <420>; /* uV */
+   ti,charge-current = <150>; /* uA */
+   ti,termination-current = <144000>;  /* uA */
+};
+
+_gyro {
+   mount-matrix =  "1",  "0",  "0",
+   "0",  "1",  "0",
+   "0",  "0", "-1";
+};
+
diff --git 

Re: [PATCH] ath10k: Add interrupt summary based CE processing

[Doug Anderson]

Hi,

On Mon, Jul 20, 2020 at 6:32 PM Peter Oh  wrote:
>
> I'll take my word back.
> It's not this patch problem, but by others.
> I have 2 extra patches before the 3 patches so my system looks like
>
> backports from ath.git 5.6-rc1 + linux kernel 4.4 (similar to OpenWrt)
> On top of the working system, I cherry-picked these 5.
>
> #1.
> ath10k: Avoid override CE5 configuration for QCA99X0 chipsets
> ath.git commit 521fc37be3d879561ca5ab42d64719cf94116af0
> #2.
> ath10k: Fix NULL pointer dereference in AHB device probe
> wireless-drivers.git commit 1cfd3426ef989b83fa6176490a38777057e57f6c
> #3.
> ath10k: Add interrupt summary based CE processing
> https://patchwork.kernel.org/patch/11628299/
> #4.
> ath10k: Keep track of which interrupts fired, don't poll them
> https://patchwork.kernel.org/patch/11654631/
> #5.
> ath10k: Get rid of "per_ce_irq" hw param
> https://patchwork.kernel.org/patch/11654633/
>
> The error "[  14.226184] ath10k_ahb a00.wifi: failed to receive
> initialized event from target: 8000" is because of #1 and #2,
> since this happens even after I reverted #3~#5.
> Once I reverted all except #1 I got another crash.
>
> [   11.179595] !#% P<__ath10k_ce_rx_post_buf+0x14/0x98
> [ath10k_core]> L<0x4bc00> F<005> [000c]
> [   11.179643] Unable to handle kernel NULL pointer dereference at
> virtual address 000c
> [   11.439207] [<7f15a69c>] (__ath10k_ce_rx_post_buf [ath10k_core])
> from [<7f15a874>] (ath10k_ce_rx_post_buf+0x3c/0x50 [ath10k_core])
> [   11.447204] [<7f15a874>] (ath10k_ce_rx_post_buf [ath10k_core]) from
> [<7f2889a4>] (ath10k_pci_diag_read_mem+0x104/0x2a8 [ath10k_pci])
> [   11.458706] [<7f2889a4>] (ath10k_pci_diag_read_mem [ath10k_pci])
> from [<7f288b68>] (ath10k_pci_diag_read32+0x1c/0x2c [ath10k_pci])
> [   11.470767] [<7f288b68>] (ath10k_pci_diag_read32 [ath10k_pci]) from
> [<7f28abe8>] (ath10k_pci_init_config+0x2c/0x290 [ath10k_pci])
> [   11.482314] [<7f28abe8>] (ath10k_pci_init_config [ath10k_pci]) from
> [<7f28d160>] (ath10k_ahb_hif_power_up+0x7c/0xe8 [ath10k_pci])
> [   11.494153] [<7f28d160>] (ath10k_ahb_hif_power_up [ath10k_pci])
> from [<7f135348>] (ath10k_core_register_work+0x84/0x8f8 [ath10k_core])
> [   11.505766] [<7f135348>] (ath10k_core_register_work [ath10k_core])
> from [<8023b614>] (process_one_work+0x1c0/0x2f8)
> [   11.517594] [<8023b614>] (process_one_work) from [<8023c650>]
> (worker_thread+0x280/0x3c0)
> [   11.527919] [<8023c650>] (worker_thread) from [<802408f8>]
> (kthread+0xd8/0xe8)
> [   11.536247] [<802408f8>] (kthread) from [<80209ce8>]
> (ret_from_fork+0x14/0x2c)
>
> When I revert #1 eventually, my system is back to working.
> So I'm blaming the #1 and #2 could have potential bugs or require
> ath.git branch up-to-date.

You caught me just as I was signing off yesterday evening, but just to
confirm that you are now fairly certain that none of the 3 patches I
was involved with[*] are related to your problems.  If that's wrong
and there's an action I need to take on the patches then let me know!
:-)

[*] The three patches I was involved with:

ath10k: Add interrupt summary based CE processing
https://patchwork.kernel.org/patch/11628299/

ath10k: Keep track of which interrupts fired, don't poll them
https://patchwork.kernel.org/patch/11654631/

ath10k: Get rid of "per_ce_irq" hw param
https://patchwork.kernel.org/patch/11654633/

-Doug

Re: [PATCH 0/2] Fix warnings in display/bridge/nwl-dsi.yaml DT example

[Rob Herring]

On Fri, Jul 3, 2020 at 5:47 AM Ondrej Jirman  wrote:
>
> This patchset fixes warnings in the example in display/bridge/nwl-dsi.yaml
> revealed during port of display/panel/rocktech,jh057n00900.yaml to
> yaml.
>
> Please take a look.
>
> thank you and regards,
>   Ondrej Jirman
>
> Ondrej Jirman (2):
>   dt-bindings: display: Fix example in nwl-dsi.yaml
>   dt-binding: display: Allow a single port node on rocktech,jh057n00900

Series applied to drm-misc.

Rob

Re: [RFC PATCH] mm: silence soft lockups from unlock_page

[Linus Torvalds]

On Mon, Jul 20, 2020 at 11:33 PM Michal Hocko  wrote:
>
> The lockup is in page_unlock in do_read_fault and I suspect that this is
> yet another effect of a very long waitqueue chain which has been
> addresses by 11a19c7b099f ("sched/wait: Introduce wakeup boomark in
> wake_up_page_bit") previously.

Hmm.

I do not believe that you can actually get to the point where you have
a million waiters and it takes 20+ seconds to wake everybody up.

More likely, it's actually *caused* by that commit 11a19c7b099f, and
what might be happening is that other CPU's are just adding new
waiters to the list *while* we're waking things up, because somebody
else already got the page lock again.

Humor me.. Does something like this work instead? It's
whitespace-damaged because of just a cut-and-paste, but it's entirely
untested, and I haven't really thought about any memory ordering
issues, but I think it's ok.

The logic is that anybody who called wake_up_page_bit() _must_ have
cleared that bit before that. So if we ever see it set again (and
memory ordering doesn't matter), then clearly somebody else got access
to the page bit (whichever it was), and we should not

 (a) waste time waking up people who can't get the bit anyway

 (b) be in a  livelock where other CPU's continually add themselves to
the wait queue because somebody else got the bit.

and it's that (b) case that I think happens for you.

NOTE! Totally UNTESTED patch follows. I think it's good, but maybe
somebody sees some problem with this approach?

I realize that people can wait for other bits than the unlocked, and
if you're waiting for writeback to complete maybe you don't care if
somebody else then started writeback *AGAIN* on the page and you'd
actually want to be woken up regardless, but honestly, I don't think
it really matters.

Linus

--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -1054,6 +1054,15 @@ static void wake_up_page_bit(struct page *page,
int bit_nr)
 * from wait queue
 */
spin_unlock_irqrestore(>lock, flags);
+
+   /*
+* If somebody else set the bit again, stop waking
+* people up. It's now the responsibility of that
+* other page bit owner to do so.
+*/
+   if (test_bit(bit_nr, >flags))
+   return;
+
cpu_relax();
spin_lock_irqsave(>lock, flags);
__wake_up_locked_key_bookmark(q, TASK_NORMAL, , );

Re: strace of io_uring events?

[Jens Axboe]

On 7/21/20 9:27 AM, Andy Lutomirski wrote:
> On Fri, Jul 17, 2020 at 1:02 AM Stefano Garzarella  
> wrote:
>>
>> On Thu, Jul 16, 2020 at 08:12:35AM -0700, Kees Cook wrote:
>>> On Thu, Jul 16, 2020 at 03:14:04PM +0200, Stefano Garzarella wrote:
> 
>>> access (IIUC) is possible without actually calling any of the io_uring
>>> syscalls. Is that correct? A process would receive an fd (via SCM_RIGHTS,
>>> pidfd_getfd, or soon seccomp addfd), and then call mmap() on it to gain
>>> access to the SQ and CQ, and off it goes? (The only glitch I see is
>>> waking up the worker thread?)
>>
>> It is true only if the io_uring istance is created with SQPOLL flag (not the
>> default behaviour and it requires CAP_SYS_ADMIN). In this case the
>> kthread is created and you can also set an higher idle time for it, so
>> also the waking up syscall can be avoided.
> 
> I stared at the io_uring code for a while, and I'm wondering if we're
> approaching this the wrong way. It seems to me that most of the
> complications here come from the fact that io_uring SQEs don't clearly
> belong to any particular security principle.  (We have struct creds,
> but we don't really have a task or mm.)  But I'm also not convinced
> that io_uring actually supports cross-mm submission except by accident
> -- as it stands, unless a user is very careful to only submit SQEs
> that don't use user pointers, the results will be unpredictable.

How so? 

> Perhaps we can get away with this:
> 
> diff --git a/fs/io_uring.c b/fs/io_uring.c
> index 74bc4a04befa..92266f869174 100644
> --- a/fs/io_uring.c
> +++ b/fs/io_uring.c
> @@ -7660,6 +7660,20 @@ SYSCALL_DEFINE6(io_uring_enter, unsigned int,
> fd, u32, to_submit,
>  if (!percpu_ref_tryget(>refs))
>  goto out_fput;
> 
> +if (unlikely(current->mm != ctx->sqo_mm)) {
> +/*
> + * The mm used to process SQEs will be current->mm or
> + * ctx->sqo_mm depending on which submission path is used.
> + * It's also unclear who is responsible for an SQE submitted
> + * out-of-process from a security and auditing perspective.
> + *
> + * Until a real usecase emerges and there are clear semantics
> + * for out-of-process submission, disallow it.
> + */
> +ret = -EACCES;
> +goto out;
> +}
> +
>  /*
>   * For SQ polling, the thread will do all submissions and completions.
>   * Just return the requested submit count, and wake the thread if

That'll break postgres that already uses this, also see:

commit 73e08e711d9c1d79fae01daed4b0e1fee5f8a275
Author: Jens Axboe 
Date:   Sun Jan 26 09:53:12 2020 -0700

Revert "io_uring: only allow submit from owning task"

So no, we can't do that.

-- 
Jens Axboe

[ANNOUNCE] 5.4.52-rt31

[Steven Rostedt]

Dear RT Folks,

I'm pleased to announce the 5.4.52-rt31 stable release.


This release is just an update to the new stable 5.4.52 version
and no RT specific changes have been made.

It did have some issues with merging of v5.4.48, which caused a
conflict and required some updates to "sched: Move mmdrop to RCU on RT".

v5.4.49 also had a conflict that required reverting "net: Add a mutex
around devnet_rename_seq".

Due to these conflicts, this release took a little more time and
testing.


You can get this release via the git tree at:

  git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git

  branch: v5.4-rt
  Head SHA1: ce24f034d80d0433977b8d7d3bbfcddcfe2b1d84


Or to build 5.4.52-rt31 directly, the following patches should be applied:

  http://www.kernel.org/pub/linux/kernel/v5.x/linux-5.4.tar.xz

  http://www.kernel.org/pub/linux/kernel/v5.x/patch-5.4.52.xz

  
http://www.kernel.org/pub/linux/kernel/projects/rt/5.4/patch-5.4.52-rt31.patch.xz




Enjoy,

-- Steve

Re: strace of io_uring events?

[Andy Lutomirski]

On Fri, Jul 17, 2020 at 1:02 AM Stefano Garzarella  wrote:
>
> On Thu, Jul 16, 2020 at 08:12:35AM -0700, Kees Cook wrote:
> > On Thu, Jul 16, 2020 at 03:14:04PM +0200, Stefano Garzarella wrote:

> > access (IIUC) is possible without actually calling any of the io_uring
> > syscalls. Is that correct? A process would receive an fd (via SCM_RIGHTS,
> > pidfd_getfd, or soon seccomp addfd), and then call mmap() on it to gain
> > access to the SQ and CQ, and off it goes? (The only glitch I see is
> > waking up the worker thread?)
>
> It is true only if the io_uring istance is created with SQPOLL flag (not the
> default behaviour and it requires CAP_SYS_ADMIN). In this case the
> kthread is created and you can also set an higher idle time for it, so
> also the waking up syscall can be avoided.

I stared at the io_uring code for a while, and I'm wondering if we're
approaching this the wrong way. It seems to me that most of the
complications here come from the fact that io_uring SQEs don't clearly
belong to any particular security principle.  (We have struct creds,
but we don't really have a task or mm.)  But I'm also not convinced
that io_uring actually supports cross-mm submission except by accident
-- as it stands, unless a user is very careful to only submit SQEs
that don't use user pointers, the results will be unpredictable.
Perhaps we can get away with this:

diff --git a/fs/io_uring.c b/fs/io_uring.c
index 74bc4a04befa..92266f869174 100644
--- a/fs/io_uring.c
+++ b/fs/io_uring.c
@@ -7660,6 +7660,20 @@ SYSCALL_DEFINE6(io_uring_enter, unsigned int,
fd, u32, to_submit,
 if (!percpu_ref_tryget(>refs))
 goto out_fput;

+if (unlikely(current->mm != ctx->sqo_mm)) {
+/*
+ * The mm used to process SQEs will be current->mm or
+ * ctx->sqo_mm depending on which submission path is used.
+ * It's also unclear who is responsible for an SQE submitted
+ * out-of-process from a security and auditing perspective.
+ *
+ * Until a real usecase emerges and there are clear semantics
+ * for out-of-process submission, disallow it.
+ */
+ret = -EACCES;
+goto out;
+}
+
 /*
  * For SQ polling, the thread will do all submissions and completions.
  * Just return the requested submit count, and wake the thread if

If we can do that, then we could bind seccomp-like io_uring filters to
an mm, and we get obvious semantics that ought to cover most of the
bases.

Jens, Christoph?

Stefano, what's your intended usecase for your restriction patchset?

Re: nouveau regression with 5.7 caused by "PCI/PM: Assume ports without DLL Link Active train links in 100 ms"

[Mika Westerberg]

On Tue, Jul 21, 2020 at 11:01:55AM -0400, Lyude Paul wrote:
> Sure thing. Also, feel free to let me know if you'd like access to one of the
> systems we saw breaking with this patch - I'm fairly sure I've got one of them
> locally at my apartment and don't mind setting up AMT/KVM/SSH

Probably no need for remote access (thanks for the offer, though). I
attached a test patch to the bug report:

  https://bugzilla.kernel.org/show_bug.cgi?id=208597

that tries to work it around (based on the ->pm_cap == 0). I wonder if
anyone would have time to try it out.

Re: [PATCH][next] x86/ioperm: initialize pointer bitmap with NULL rather than 0

[Jürgen Groß]

On 21.07.20 12:02, Colin King wrote:

From: Colin Ian King 

The pointer bitmap is being initialized with a plain integer 0,
fix this by initializing it with a NULL instead.

Cleans up sparse warning:
arch/x86/xen/enlighten_pv.c:876:27: warning: Using plain integer
as NULL pointer

Signed-off-by: Colin Ian King 


Reviewed-by: Juergen Gross 


Juergen

Re: [PATCH 1/2] KVM: LAPIC: Prevent setting the tscdeadline timer if the lapic is hw disabled

[Sean Christopherson]

On Tue, Jul 21, 2020 at 12:35:01PM +0200, Vitaly Kuznetsov wrote:
> Wanpeng Li  writes:
> 
> > From: Wanpeng Li 
> >
> > Prevent setting the tscdeadline timer if the lapic is hw disabled.
> >
> > Signed-off-by: Wanpeng Li 

A Fixes and/or Cc stable is probably needed for this.

> > ---
> >  arch/x86/kvm/lapic.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
> > index 5bf72fc..4ce2ddd 100644
> > --- a/arch/x86/kvm/lapic.c
> > +++ b/arch/x86/kvm/lapic.c
> > @@ -2195,7 +2195,7 @@ void kvm_set_lapic_tscdeadline_msr(struct kvm_vcpu 
> > *vcpu, u64 data)
> >  {
> > struct kvm_lapic *apic = vcpu->arch.apic;
> >  
> > -   if (!lapic_in_kernel(vcpu) || apic_lvtt_oneshot(apic) ||
> > +   if (!kvm_apic_present(vcpu) || apic_lvtt_oneshot(apic) ||
> > apic_lvtt_period(apic))
> > return;
> 
> Out of pure curiosity, what is the architectural behavior if I disable
> LAPIC, write to IA32_TSC_DEADLINE and then re-enable LAPIC before the
> timer was supposed to fire?

Intel's SDM reserves the right for the CPU to do whatever it wants :-)

   When IA32_APIC_BASE[11] is set to 0, prior initialization to the APIC
   may be lost and the APIC may return to the state described in Section
   10.4.7.1, “Local APIC State After Power-Up or Reset.”

Practically speaking, resetting APIC state seems like the sane approach,
i.e. KVM should probably call kvm_lapic_reset() when the APIC transitions
from HW enabled -> disabled.  Maybe in a follow-up patch to this one?

Re: [RFC 02/11] Drivers: hv: vmbus: Move __vmbus_open()

[Wei Liu]

On Tue, Jul 21, 2020 at 09:41:26AM +0800, Boqun Feng wrote:
> Pure function movement, no functional changes. The move is made, because
> in a later change, __vmbus_open() will rely on some static functions
> afterwards, so we sperate the move and the modification of
> __vmbus_open() in two patches to make it easy to review.
> 
> Signed-off-by: Boqun Feng 

Reviewed-by: Wei Liu 

Re: [PATCH] dma-pool: Do not allocate pool memory from CMA

[Amit Pundir]

On Tue, 21 Jul 2020 at 18:15, Nicolas Saenz Julienne
 wrote:
>
> On Tue, 2020-07-21 at 17:45 +0530, Amit Pundir wrote:
> > On Tue, 21 Jul 2020 at 16:45, Nicolas Saenz Julienne
> >  wrote:
> > > On Tue, 2020-07-21 at 14:24 +0530, Amit Pundir wrote:
> > > > On Tue, 21 Jul 2020 at 14:09, Nicolas Saenz Julienne
> > > >  wrote:
> > > > > Hi Amit,
> > > > > > Hi Nicolas,
> > > > > >
> > > > > > I see a boot regression with this commit d9765e41d8e9 "dma-
> > > > > > pool:
> > > > > > Do not allocate pool memory from CMA" on my Xiaomi Poco F1
> > > > > > (Qcom sdm845) phone running v5.8-rc6. I can't boot past the
> > > > > > bootloader splash screen with this patch.
> > > > > >
> > > > > > Phone boots fine if I revert this patch. I carry only one out
> > > > > > of
> > > > > > tree
> > > > > > dts patch https://lkml.org/lkml/2020/6/25/52. And since this
> > > > > > is a
> > > > > > stock
> > > > > > phone, I don't have access to serial/dmesg logs until I boot
> > > > > > to
> > > > > > AOSP
> > > > > > (adb) shell.
> > > > > >
> > > > > > Any thoughts as to what might be going wrong here? I'd be
> > > > > > happy
> > > > > > to
> > > > > > help debug things. For what it's worth, I don't see this
> > > > > > regression
> > > > > > on
> > > > > > other two sdm845 devices (db845c and Pixel 3) I tested on.
> > > > >
> > > > > Can you provide a boot log (even if without my patch) and the
> > > > > device-
> > > > > tree files? It'd help a lot figuring things out.
> > > >
> > > > Thank you for the prompt reply Nicolas.
> > > >
> > > > Here is the boot log with the reverted patch
> > > > https://pastebin.ubuntu.com/p/BrhPf83nKF/
> > > >
> > > > Here is my phone's dts
> > > > https://github.com/pundiramit/linux/commit/2a394c199deeaf4c91e0e008e8fba2a72f494d8c
> > >
> > > I'm at loss at what could be failing here. Your device should be
> > > able
> > > to address the whole 8GB memory space, which AFAIK is the max
> > > available
> > > on that smartphone family. But maybe the device-tree is lying, who
> > > knows...
> >
> > If it helps, my phone has 6GB memory space.
> >
> > > Can you try booting *without* my patch and this in the kernel
> > > command
> > > line: "cma=16M@0x1-0x2".
> >
> > It doesn't boot with this added kernel command line.
>
>
> For the record, this placed the CMA in the [4GB, 8GB] address space
> instead of you setup's default: [3GB, 4GB]. All atomic pools fall in
> that memory area without my patch, which makes me think some of the
> devices on your board might not like higher addresses.
>

Thank you Nicolas for the details. Though we don't set the CMA
alloc-ranges explicitly in upstream sdm845 dts, but I dug around and
found that CMA alloc-ranges in the downstream kernel are indeed in
lower address space.
https://github.com/MiCode/Xiaomi_Kernel_OpenSource/blob/dipper-q-oss/arch/arm64/boot/dts/qcom/sdm845.dtsi#L662

/* global autoconfigured region for contiguous allocations */
linux,cma {
compatible = "shared-dma-pool";
alloc-ranges = <0 0x 0 0x>;
reusable;
alignment = <0 0x40>;
size = <0 0x200>;
linux,cma-default;
};

> What happens if you boot with my troublesome patch with this in your
> device tree? (insert it at the bottom of sdm845-beryllium.dts)
>
>  {
> dma-ranges = <0 0 0 0 0x1 0>;
> };
>

Device still doesn't boot up to adb shell.

Regards,
Amit Pundir

> Regards,
> Nicolas
>
> > Regards,
> > Amit Pundir
> >
> > > Regards,
> > > Nicolas
> > >
> > > And here is my kernel tree just in case
> > > > https://github.com/pundiramit/linux/commits/beryllium-mainline
> > > >
> > > > Regards,
> > > > Amit Pundir
> > > >
> > > >
> > > > > Regards,
> > > > > Nicolas
> > > > >
> > > > > > Regards,
> > > > > > Amit Pundir
> > > > > >
> > > > > > > Reported-by: Jeremy Linton 
> > > > > > > Signed-off-by: Nicolas Saenz Julienne <
> > > > > > > nsaenzjulie...@suse.de>
> > > > > > > ---
> > > > > > >
> > > > > > > An more costly alternative would be adding an option to
> > > > > > > dma_alloc_from_contiguous() so it fails when the allocation
> > > > > > > doesn't
> > > > > > > fall
> > > > > > > in a specific zone.
> > > > > > >
> > > > > > >  kernel/dma/pool.c | 11 ++-
>

Re: [RFC 01/11] Drivers: hv: vmbus: Always use HV_HYP_PAGE_SIZE for gpadl

[Wei Liu]

On Tue, Jul 21, 2020 at 09:41:25AM +0800, Boqun Feng wrote:
> Since the hypervisor always uses 4K as its page size, the size of PFNs
> used for gpadl should be HV_HYP_PAGE_SIZE rather than PAGE_SIZE, so
> adjust this accordingly as the preparation for supporting 16K/64K page
> size guests.

It may be worth calling out there is no change on x86 because
HV_HYP_PAGE_SHIFT and PAGE_SHIFT are of the same value there.

Wei.

Re: [RFC PATCH 4/7] x86: use exit_lazy_tlb rather than membarrier_mm_sync_core_before_usermode

[Mathieu Desnoyers]

- On Jul 21, 2020, at 11:19 AM, Peter Zijlstra pet...@infradead.org wrote:

> On Tue, Jul 21, 2020 at 11:15:13AM -0400, Mathieu Desnoyers wrote:
>> - On Jul 21, 2020, at 11:06 AM, Peter Zijlstra pet...@infradead.org 
>> wrote:
>> 
>> > On Tue, Jul 21, 2020 at 08:04:27PM +1000, Nicholas Piggin wrote:
>> > 
>> >> That being said, the x86 sync core gap that I imagined could be fixed
>> >> by changing to rq->curr == rq->idle test does not actually exist because
>> >> the global membarrier does not have a sync core option. So fixing the
>> >> exit_lazy_tlb points that this series does *should* fix that. So
>> >> PF_KTHREAD may be less problematic than I thought from implementation
>> >> point of view, only semantics.
>> > 
>> > So I've been trying to figure out where that PF_KTHREAD comes from,
>> > commit 227a4aadc75b ("sched/membarrier: Fix p->mm->membarrier_state racy
>> > load") changed 'p->mm' to '!(p->flags & PF_KTHREAD)'.
>> > 
>> > So the first version:
>> > 
>> >  
>> > https://lkml.kernel.org/r/20190906031300.1647-5-mathieu.desnoy...@efficios.com
>> > 
>> > appears to unconditionally send the IPI and checks p->mm in the IPI
>> > context, but then v2:
>> > 
>> >  
>> > https://lkml.kernel.org/r/20190908134909.12389-1-mathieu.desnoy...@efficios.com
>> > 
>> > has the current code. But I've been unable to find the reason the
>> > 'p->mm' test changed into '!(p->flags & PF_KTHREAD)'.
>> 
>> Looking back at my inbox, it seems like you are the one who proposed to
>> skip all kthreads:
>> 
>> https://lkml.kernel.org/r/20190904124333.gq2...@hirez.programming.kicks-ass.net
> 
> I had a feeling it might've been me ;-) I just couldn't find the email.
> 
>> > The comment doesn't really help either; sure we have the whole lazy mm
>> > thing, but that's ->active_mm, not ->mm.
>> > 
>> > Possibly it is because {,un}use_mm() do not have sufficient barriers to
>> > make the remote p->mm test work? Or were we over-eager with the !p->mm
>> > doesn't imply kthread 'cleanups' at the time?
>> 
>> The nice thing about adding back kthreads to the threads considered for
>> membarrier
>> IPI is that it has no observable effect on the user-space ABI. No 
>> pre-existing
>> kthread
>> rely on this, and we just provide an additional guarantee for future kthread
>> implementations.
>> 
>> > Also, I just realized, I still have a fix for use_mm() now
>> > kthread_use_mm() that seems to have been lost.
>> 
>> I suspect we need to at least document the memory barriers in kthread_use_mm 
>> and
>> kthread_unuse_mm to state that they are required by membarrier if we want to
>> ipi kthreads as well.
> 
> Right, so going by that email you found it was mostly a case of being
> lazy, but yes, if we audit the kthread_{,un}use_mm() barriers and add
> any other bits that might be needed, covering kthreads should be
> possible.
> 
> No objections from me for making it so.

I'm OK on making membarrier cover kthreads using mm as well, provided we
audit kthread_{,un}use_mm() to make sure the proper barriers are in place
after setting task->mm and before clearing it.

Thanks,

Mathieu


-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

[PATCH v2 2/3] dt-bindings: arm: stm32: document Odyssey compatible

[Marcin Sloniewski]

Document device tree bindings of Seeed SoM and carrier board.

Signed-off-by: Marcin Sloniewski 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/arm/stm32/stm32.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/stm32/stm32.yaml 
b/Documentation/devicetree/bindings/arm/stm32/stm32.yaml
index 790e6dd48e34..22b9aaa75eee 100644
--- a/Documentation/devicetree/bindings/arm/stm32/stm32.yaml
+++ b/Documentation/devicetree/bindings/arm/stm32/stm32.yaml
@@ -39,6 +39,8 @@ properties:
   - enum:
   - arrow,stm32mp157a-avenger96 # Avenger96
   - lxa,stm32mp157c-mc1
+  - seeed,stm32mp157c-odyssey
+  - seeed,stm32mp157c-odyssey-som
   - shiratech,stm32mp157a-iot-box # IoT Box
   - shiratech,stm32mp157a-stinger96 # Stinger96
   - st,stm32mp157c-ed1
-- 
2.27.0

[PATCH v2 3/3] ARM: dts: stm32: add initial support for stm32mp157-odyssey board

[Marcin Sloniewski]

Add support for Seeed Studio's stm32mp157c odyssey board.
Board consists of SoM with stm32mp157c with 4GB eMMC and 512 MB DDR3 RAM
and carrier board with USB and ETH interfaces, SD card connector,
wifi and BT chip AP6236.

In this patch only basic kernel boot is supported and interfacing
SD card and on-board eMMC.

Signed-off-by: Marcin Sloniewski 
---

Changes in v2:
- add new odyssey dts to Makefile

 arch/arm/boot/dts/Makefile|   3 +-
 .../arm/boot/dts/stm32mp157c-odyssey-som.dtsi | 276 ++
 arch/arm/boot/dts/stm32mp157c-odyssey.dts |  72 +
 3 files changed, 350 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/stm32mp157c-odyssey-som.dtsi
 create mode 100644 arch/arm/boot/dts/stm32mp157c-odyssey.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index e6a1cac0bfc7..a3ea2301c82c 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -1047,7 +1047,8 @@ dtb-$(CONFIG_ARCH_STM32) += \
stm32mp157c-dk2.dtb \
stm32mp157c-ed1.dtb \
stm32mp157c-ev1.dtb \
-   stm32mp157c-lxa-mc1.dtb
+   stm32mp157c-lxa-mc1.dtb \
+   stm32mp157c-odyssey.dtb
 dtb-$(CONFIG_MACH_SUN4I) += \
sun4i-a10-a1000.dtb \
sun4i-a10-ba10-tvbox.dtb \
diff --git a/arch/arm/boot/dts/stm32mp157c-odyssey-som.dtsi 
b/arch/arm/boot/dts/stm32mp157c-odyssey-som.dtsi
new file mode 100644
index ..620ff9e7f370
--- /dev/null
+++ b/arch/arm/boot/dts/stm32mp157c-odyssey-som.dtsi
@@ -0,0 +1,276 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
+/*
+ * Copyright (C) 2020 Marcin Sloniewski .
+ */
+
+/dts-v1/;
+
+#include "stm32mp157.dtsi"
+#include "stm32mp15xc.dtsi"
+#include "stm32mp15-pinctrl.dtsi"
+#include "stm32mp15xxac-pinctrl.dtsi"
+#include 
+#include 
+
+/ {
+   model = "Seeed Studio Odyssey-STM32MP157C SOM";
+   compatible = "seeed,stm32mp157c-odyssey-som", "st,stm32mp157";
+
+   memory@c000 {
+   reg = <0xc000 0x2000>;
+   };
+
+   reserved-memory {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   mcuram2: mcuram2@1000 {
+   compatible = "shared-dma-pool";
+   reg = <0x1000 0x4>;
+   no-map;
+   };
+
+   vdev0vring0: vdev0vring0@1004 {
+   compatible = "shared-dma-pool";
+   reg = <0x1004 0x1000>;
+   no-map;
+   };
+
+   vdev0vring1: vdev0vring1@10041000 {
+   compatible = "shared-dma-pool";
+   reg = <0x10041000 0x1000>;
+   no-map;
+   };
+
+   vdev0buffer: vdev0buffer@10042000 {
+   compatible = "shared-dma-pool";
+   reg = <0x10042000 0x4000>;
+   no-map;
+   };
+
+   mcuram: mcuram@3000 {
+   compatible = "shared-dma-pool";
+   reg = <0x3000 0x4>;
+   no-map;
+   };
+
+   retram: retram@3800 {
+   compatible = "shared-dma-pool";
+   reg = <0x3800 0x1>;
+   no-map;
+   };
+
+   gpu_reserved: gpu@d400 {
+   reg = <0xd400 0x400>;
+   no-map;
+   };
+   };
+
+   led {
+   compatible = "gpio-leds";
+   blue {
+   label = "heartbeat";
+   gpios = < 3 GPIO_ACTIVE_HIGH>;
+   linux,default-trigger = "heartbeat";
+   default-state = "off";
+   };
+   };
+};
+
+ {
+   contiguous-area = <_reserved>;
+   status = "okay";
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_a>;
+   i2c-scl-rising-time-ns = <185>;
+   i2c-scl-falling-time-ns = <20>;
+   status = "okay";
+   /* spare dmas for other usage */
+   /delete-property/dmas;
+   /delete-property/dma-names;
+
+   pmic: stpmic@33 {
+   compatible = "st,stpmic1";
+   reg = <0x33>;
+   interrupts-extended = < 0 IRQ_TYPE_EDGE_FALLING>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   status = "okay";
+
+   regulators {
+   compatible = "st,stpmic1-regulators";
+   ldo1-supply = <>;
+   ldo3-supply = <_ddr>;
+   ldo6-supply = <>;
+   pwr_sw1-supply = <_out>;
+   pwr_sw2-supply = <_out>;
+
+   vddcore: buck1 {
+   regulator-name = "vddcore";
+   

[PATCH v2 3/5] dt-bindings: firmware: imx-scu: Add SECVIO resource

[franck . lenormand]

From: Franck LENORMAND 

The SNVS can trigger interruption when detecting a SECurity
VIOlation.
This patch adds the definition of the resource.

Signed-off-by: Franck LENORMAND 
---
 include/dt-bindings/firmware/imx/rsrc.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/include/dt-bindings/firmware/imx/rsrc.h 
b/include/dt-bindings/firmware/imx/rsrc.h
index 54278d5..fe5f25f 100644
--- a/include/dt-bindings/firmware/imx/rsrc.h
+++ b/include/dt-bindings/firmware/imx/rsrc.h
@@ -1,7 +1,7 @@
 /* SPDX-License-Identifier: GPL-2.0+ */
 /*
  * Copyright (C) 2016 Freescale Semiconductor, Inc.
- * Copyright 2017-2018 NXP
+ * Copyright 2017-2018, 2020 NXP
  */
 
 #ifndef __DT_BINDINGS_RSCRC_IMX_H
@@ -50,6 +50,7 @@
 #define IMX_SC_R_DC_1_BLIT238
 #define IMX_SC_R_DC_1_BLIT_OUT 39
 #define IMX_SC_R_DC_1_WARP 42
+#define IMX_SC_R_SECVIO44
 #define IMX_SC_R_DC_1_VIDEO0   45
 #define IMX_SC_R_DC_1_VIDEO1   46
 #define IMX_SC_R_DC_1_FRAC047
-- 
2.7.4

[PATCH v2 5/5] soc: imx8: Add the SC SECVIO driver

[franck . lenormand]

From: Franck LENORMAND 

The SNVS is a hardware component in the imx8 SoC. One of its
function is to detect hardware attacks, in which case it creates
a SECurity VIOlation.

This patch adds the support for the reception of these secvio and
report it to the audit framework.

It also gives the possibility to perform custom processing when a
secvio is detected.

Signed-off-by: Franck LENORMAND 
Reported-by: kernel test robot 
---
 drivers/soc/imx/Kconfig |  10 +
 drivers/soc/imx/Makefile|   1 +
 drivers/soc/imx/secvio/Kconfig  |  10 +
 drivers/soc/imx/secvio/Makefile |   3 +
 drivers/soc/imx/secvio/imx-secvio-audit.c   |  39 ++
 drivers/soc/imx/secvio/imx-secvio-debugfs.c | 379 
 drivers/soc/imx/secvio/imx-secvio-sc-int.h  |  84 +++
 drivers/soc/imx/secvio/imx-secvio-sc.c  | 858 
 include/soc/imx/imx-secvio-sc.h | 177 ++
 9 files changed, 1561 insertions(+)
 create mode 100644 drivers/soc/imx/secvio/Kconfig
 create mode 100644 drivers/soc/imx/secvio/Makefile
 create mode 100644 drivers/soc/imx/secvio/imx-secvio-audit.c
 create mode 100644 drivers/soc/imx/secvio/imx-secvio-debugfs.c
 create mode 100644 drivers/soc/imx/secvio/imx-secvio-sc-int.h
 create mode 100644 drivers/soc/imx/secvio/imx-secvio-sc.c
 create mode 100644 include/soc/imx/imx-secvio-sc.h

diff --git a/drivers/soc/imx/Kconfig b/drivers/soc/imx/Kconfig
index a9370f4..6c1bc78 100644
--- a/drivers/soc/imx/Kconfig
+++ b/drivers/soc/imx/Kconfig
@@ -19,4 +19,14 @@ config SOC_IMX8M
  support, it will provide the SoC info like SoC family,
  ID and revision etc.
 
+config SECVIO_SC
+tristate "NXP SC secvio support"
+depends on IMX_SCU
+help
+   If you say yes here you get support for the NXP SNVS security
+   violation module. It includes the possibility to read information
+   related to security violations and tampers. It also gives the
+   possibility to register user callbacks when a security violation
+   occurs.
+
 endmenu
diff --git a/drivers/soc/imx/Makefile b/drivers/soc/imx/Makefile
index 078dc91..c91a499 100644
--- a/drivers/soc/imx/Makefile
+++ b/drivers/soc/imx/Makefile
@@ -5,3 +5,4 @@ endif
 obj-$(CONFIG_HAVE_IMX_GPC) += gpc.o
 obj-$(CONFIG_IMX_GPCV2_PM_DOMAINS) += gpcv2.o
 obj-$(CONFIG_SOC_IMX8M) += soc-imx8m.o
+obj-${CONFIG_SECVIO_SC} += secvio/
diff --git a/drivers/soc/imx/secvio/Kconfig b/drivers/soc/imx/secvio/Kconfig
new file mode 100644
index 000..dcfaea5
--- /dev/null
+++ b/drivers/soc/imx/secvio/Kconfig
@@ -0,0 +1,10 @@
+config SECVIO_SC
+tristate "NXP SC secvio support"
+depends on IMX_SCU
+help
+   If you say yes here you get support for the NXP SNVS security
+   violation module. It includes the possibility to read information
+   related to security violations and tampers. It also gives the
+   possibility to register user callbacks when a security violation
+   occurs.
+
diff --git a/drivers/soc/imx/secvio/Makefile b/drivers/soc/imx/secvio/Makefile
new file mode 100644
index 000..d5a89ba
--- /dev/null
+++ b/drivers/soc/imx/secvio/Makefile
@@ -0,0 +1,3 @@
+obj-y +=  imx-secvio-sc.o
+obj-$(CONFIG_DEBUG_FS) += imx-secvio-debugfs.o
+obj-$(CONFIG_AUDIT) += imx-secvio-audit.o
diff --git a/drivers/soc/imx/secvio/imx-secvio-audit.c 
b/drivers/soc/imx/secvio/imx-secvio-audit.c
new file mode 100644
index 000..dc96e16
--- /dev/null
+++ b/drivers/soc/imx/secvio/imx-secvio-audit.c
@@ -0,0 +1,39 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2019-2020 NXP
+ */
+
+#include 
+
+#include 
+
+/**
+ * report_to_audit_notify() - Report secvio and tamper status to audit FW
+ *
+ * This function can be chained in a notifier list
+ *
+ * @nb: notifier block
+ * @status: error code
+ * @notif_info: Pointer on secvio_sc_notifier_info structure
+ *
+ * Return:
+ * 0 - OK
+ * < 0 - error.
+ */
+int report_to_audit_notify(struct notifier_block *nb, unsigned long status,
+  void *notif_info)
+{
+   struct audit_buffer *ab;
+   struct secvio_sc_notifier_info *info = notif_info;
+
+   ab = audit_log_start(audit_context(), GFP_KERNEL, AUDIT_INTEGRITY_RULE);
+   if (!ab)
+   return -ENOMEM;
+
+   audit_log_format(ab, " hpsvs=0x%.08x lps=0x%.08x lptds=0x%.08x",
+info->hpsvs, info->lps, info->lptds);
+   audit_log_task_info(ab);
+   audit_log_end(ab);
+
+   return 0;
+}
diff --git a/drivers/soc/imx/secvio/imx-secvio-debugfs.c 
b/drivers/soc/imx/secvio/imx-secvio-debugfs.c
new file mode 100644
index 000..bcbd77a
--- /dev/null
+++ b/drivers/soc/imx/secvio/imx-secvio-debugfs.c
@@ -0,0 +1,379 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2019-2020 NXP
+ */
+
+/*
+ * The module exposes 3 files in debugfs:
+ *  - secvio/info:
+ *  * Read: It returns the value of the 

[PATCH v2 1/3] dt-bindings: vendor-prefixes: add Seeed Studio

[Marcin Sloniewski]

Add the "seeed" vendor prefix for Seeed Technology Co., Ltd
Website: https://www.seeedstudio.com/

Signed-off-by: Marcin Sloniewski 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml 
b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 9aeab66be85f..7dd03b3e9d3c 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -902,6 +902,8 @@ patternProperties:
 description: Schindler
   "^seagate,.*":
 description: Seagate Technology PLC
+  "^seeed,.*":
+description: Seeed Technology Co., Ltd
   "^seirobotics,.*":
 description: Shenzhen SEI Robotics Co., Ltd
   "^semtech,.*":
-- 
2.27.0

[PATCH v2 4/5] dt-bindings: arm: imx: Documentation of the SC secvio driver

[franck . lenormand]

From: Franck LENORMAND 

This patch adds the documentation for the SECurity VIOlation
driver using the SCU on imx8x and imx8q.

Signed-off-by: Franck LENORMAND 
---
 .../bindings/arm/freescale/fsl,imx-sc-secvio.yaml  | 34 ++
 1 file changed, 34 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/arm/freescale/fsl,imx-sc-secvio.yaml

diff --git 
a/Documentation/devicetree/bindings/arm/freescale/fsl,imx-sc-secvio.yaml 
b/Documentation/devicetree/bindings/arm/freescale/fsl,imx-sc-secvio.yaml
new file mode 100644
index 000..59b9a86
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/freescale/fsl,imx-sc-secvio.yaml
@@ -0,0 +1,34 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/freescale/fsl,imx-sc-secvio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP i.MX Security Violation driver
+
+maintainers:
+  - Franck LENORMAND 
+
+description: |
+  Receive security violation from the SNVS via the SCU firmware. Allow to
+  register notifier for additional processing
+
+properties:
+  compatible:
+enum:
+  - fsl,imx-sc-secvio
+  nvmem:
+$ref: /schemas/types.yaml#/definitions/phandle
+description:
+  Phandle to the nvmem provider.
+
+required:
+  - compatible
+  - nvmem
+
+examples:
+  - |
+sc_secvio: sc-secvio
+compatible = "fsl,imx-sc-secvio";
+nvmem = <>
+};
-- 
2.7.4

[PATCH v2 2/5] firmware: imx: scu-irq: Add API to retrieve status of IRQ

[franck . lenormand]

From: Franck LENORMAND 

This patch adds the API to retrieve the status of an IRQ.

It also adds values used to process SECVIO IRQ from the SCU.

Signed-off-by: Franck LENORMAND 
---
 drivers/firmware/imx/imx-scu-irq.c | 37 -
 include/linux/firmware/imx/sci.h   |  4 
 2 files changed, 40 insertions(+), 1 deletion(-)

diff --git a/drivers/firmware/imx/imx-scu-irq.c 
b/drivers/firmware/imx/imx-scu-irq.c
index d9dcc20..d31d600 100644
--- a/drivers/firmware/imx/imx-scu-irq.c
+++ b/drivers/firmware/imx/imx-scu-irq.c
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0+
 /*
- * Copyright 2019 NXP
+ * Copyright 2019-2020 NXP
  *
  * Implementation of the SCU IRQ functions using MU.
  *
@@ -97,6 +97,41 @@ static void imx_scu_irq_work_handler(struct work_struct 
*work)
}
 }
 
+/**
+ * imx_scu_irq_get_status() - Get the status of the IRQs of a group
+ *
+ * @group: The group of IRQ to retrieve status
+ * @irq_status: Status of the IRQs retrieved
+ *
+ * Return:
+ * 0 - OK
+ * < 0 - error.
+ */
+int imx_scu_irq_get_status(u8 group, u32 *irq_status)
+{
+   struct imx_sc_msg_irq_get_status msg;
+   struct imx_sc_rpc_msg *hdr = 
+   int ret;
+
+   hdr->ver = IMX_SC_RPC_VERSION;
+   hdr->svc = IMX_SC_RPC_SVC_IRQ;
+   hdr->func = IMX_SC_IRQ_FUNC_STATUS;
+   hdr->size = 2;
+
+   msg.data.req.resource = mu_resource_id;
+   msg.data.req.group = group;
+
+   ret = imx_scu_call_rpc(imx_sc_irq_ipc_handle, , true);
+   if (ret)
+   return ret;
+
+   if (irq_status)
+   *irq_status = msg.data.resp.status;
+
+   return 0;
+}
+EXPORT_SYMBOL(imx_scu_irq_get_status);
+
 int imx_scu_irq_group_enable(u8 group, u32 mask, u8 enable)
 {
struct imx_sc_msg_irq_enable msg;
diff --git a/include/linux/firmware/imx/sci.h b/include/linux/firmware/imx/sci.h
index 914dce1..20a16a7 100644
--- a/include/linux/firmware/imx/sci.h
+++ b/include/linux/firmware/imx/sci.h
@@ -17,9 +17,13 @@
 #include 
 #include 
 
+#define IMX_SC_IRQ_GROUP_WAKE   3U /* Wakeup interrupts */
+#define IMX_SC_IRQ_SECVIOBIT(6)/* Security violation */
+
 int imx_scu_enable_general_irq_channel(struct device *dev);
 int imx_scu_irq_register_notifier(struct notifier_block *nb);
 int imx_scu_irq_unregister_notifier(struct notifier_block *nb);
 int imx_scu_irq_group_enable(u8 group, u32 mask, u8 enable);
 int imx_scu_soc_init(struct device *dev);
+int imx_scu_irq_get_status(u8 group, u32 *irq_status);
 #endif /* _SC_SCI_H */
-- 
2.7.4

[PATCH v2 1/5] firmware: imx: scu-seco: Add SEcure Controller APIS

[franck . lenormand]

From: Franck LENORMAND 

This patch adds the APIs:
 - imx_sc_seco_build_info: get commit and sha of SECO
 - imx_sc_seco_secvio_enable: enable SNVS IRQ handling
 - imx_sc_seco_secvio_config: configure SNVS register
 - imx_sc_seco_secvio_dgo_config: configure SNVS DGO register

Signed-off-by: Franck LENORMAND 
---
 drivers/firmware/imx/Makefile |   2 +-
 drivers/firmware/imx/imx-scu.c|   3 +
 drivers/firmware/imx/seco.c   | 275 ++
 include/linux/firmware/imx/ipc.h  |   1 +
 include/linux/firmware/imx/sci.h  |   1 +
 include/linux/firmware/imx/svc/seco.h |  73 +
 6 files changed, 354 insertions(+), 1 deletion(-)
 create mode 100644 drivers/firmware/imx/seco.c
 create mode 100644 include/linux/firmware/imx/svc/seco.h

diff --git a/drivers/firmware/imx/Makefile b/drivers/firmware/imx/Makefile
index b76acba..f23e2b0 100644
--- a/drivers/firmware/imx/Makefile
+++ b/drivers/firmware/imx/Makefile
@@ -1,4 +1,4 @@
 # SPDX-License-Identifier: GPL-2.0
 obj-$(CONFIG_IMX_DSP)  += imx-dsp.o
-obj-$(CONFIG_IMX_SCU)  += imx-scu.o misc.o imx-scu-irq.o rm.o 
imx-scu-soc.o
+obj-$(CONFIG_IMX_SCU)  += imx-scu.o misc.o imx-scu-irq.o rm.o 
imx-scu-soc.o seco.o
 obj-$(CONFIG_IMX_SCU_PD)   += scu-pd.o
diff --git a/drivers/firmware/imx/imx-scu.c b/drivers/firmware/imx/imx-scu.c
index dca79ca..ed7b87b 100644
--- a/drivers/firmware/imx/imx-scu.c
+++ b/drivers/firmware/imx/imx-scu.c
@@ -245,6 +245,9 @@ int imx_scu_call_rpc(struct imx_sc_ipc *sc_ipc, void *msg, 
bool have_resp)
(saved_func == IMX_SC_MISC_FUNC_UNIQUE_ID ||
 saved_func == IMX_SC_MISC_FUNC_GET_BUTTON_STATUS))
ret = 0;
+   if (saved_svc == IMX_SC_RPC_SVC_SECO &&
+   saved_func == IMX_SC_SECO_FUNC_BUILD_INFO)
+   ret = 0;
}
 
 out:
diff --git a/drivers/firmware/imx/seco.c b/drivers/firmware/imx/seco.c
new file mode 100644
index 000..9047a75
--- /dev/null
+++ b/drivers/firmware/imx/seco.c
@@ -0,0 +1,275 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2020 NXP
+ *
+ * File containing client-side RPC functions for the SECO service. These
+ * functions are ported to clients that communicate to the SC.
+ */
+
+#include 
+
+struct imx_sc_msg_seco_get_build_id {
+   struct imx_sc_rpc_msg hdr;
+   u32 version;
+   u32 commit;
+};
+
+/**
+ * imx_sc_seco_build_info() - Get version and coomit ID of the SECO
+ *
+ * @ipc: IPC handle
+ * @version: Version of the SECO
+ * @commit: Commit ID of the SECO
+ *
+ * Return:
+ * 0 - OK
+ * < 0 - error.
+ */
+int imx_sc_seco_build_info(struct imx_sc_ipc *ipc, uint32_t *version,
+  uint32_t *commit)
+{
+   int ret;
+   struct imx_sc_msg_seco_get_build_id msg = {0};
+   struct imx_sc_rpc_msg *hdr = 
+
+   hdr->ver = IMX_SC_RPC_VERSION;
+   hdr->svc = IMX_SC_RPC_SVC_SECO;
+   hdr->func = IMX_SC_SECO_FUNC_BUILD_INFO;
+   hdr->size = 1;
+
+   ret = imx_scu_call_rpc(ipc, , true);
+   if (ret)
+   return ret;
+
+   if (version)
+   *version = msg.version;
+   if (commit)
+   *commit = msg.commit;
+
+   return 0;
+}
+EXPORT_SYMBOL(imx_sc_seco_build_info);
+
+struct imx_sc_msg_seco_sab_msg {
+   struct imx_sc_rpc_msg hdr;
+   u32 smsg_addr_hi;
+   u32 smsg_addr_lo;
+};
+
+/**
+ * imx_sc_seco_secvio_enable() - Enable the processing of secvio IRQ from the
+ * SNVS by the SECO
+ *
+ * @ipc: IPC handle
+ *
+ * Return:
+ * 0 - OK
+ * < 0 - error.
+ */
+int imx_sc_seco_secvio_enable(struct imx_sc_ipc *ipc)
+{
+   struct imx_sc_rpc_msg msg;
+   struct imx_sc_rpc_msg *hdr = 
+   int ret;
+
+   hdr->ver = IMX_SC_RPC_VERSION;
+   hdr->svc = IMX_SC_RPC_SVC_SECO;
+   hdr->func = IMX_SC_SECO_FUNC_SECVIO_ENABLE;
+   hdr->size = 1;
+
+   ret = imx_scu_call_rpc(ipc, , true);
+   if (ret)
+   return ret;
+
+   return 0;
+}
+EXPORT_SYMBOL(imx_sc_seco_secvio_enable);
+
+struct imx_sc_msg_req_seco_config {
+   struct imx_sc_rpc_msg hdr;
+   u32 data0;
+   u32 data1;
+   u32 data2;
+   u32 data3;
+   u32 data4;
+   u8 id;
+   u8 access;
+   u8 size;
+} __packed __aligned(4);
+
+struct imx_sc_msg_resp_seco_config {
+   struct imx_sc_rpc_msg hdr;
+   u32 data0;
+   u32 data1;
+   u32 data2;
+   u32 data3;
+   u32 data4;
+} __packed;
+
+/**
+ * imx_sc_seco_secvio_config() - Configure a set of SNVS registers for SECure
+ * VIOlation
+ *
+ * Some registers are extended by others registers, they configure the same
+ * kind of behavior, it constitutes a set
+ *
+ * @ipc: IPC handle
+ * @id: ID of the register, ie the offset of the first register of the set
+ * @access: Write (1) or Read (0) the registers
+ * @data0: Data for the first register
+ * @data1: Data for the second register
+ * @data2: Data for 

[PATCH v2 0/5] Add support of SECVIO from SNVS on iMX8q/x

[franck . lenormand]

From: Franck LENORMAND 

This patchset aims to add support for the SECurity VIOlation (SECVIO) of the
SNVS. A secvio is a signal emitted by the SNVS when a hardware attack
is detected. On imx8x and imx8q SoC, the SNVS is controlled by the
SECO and it is possible to interact with it using the SCU using the SC APIs.

For the driver to communicate with the SNVS via the SCU and the SECO, I had to:
 - Add support for exchange of big message with the SCU (needed for
imx_scu_irq_get_status)
 - Add API to check linux can control the SECVIO (imx_sc_rm_is_resource_owned)
 - Add APIs for the driver to read the state of the SECVIO registers of the
SNVS and DGO (imx_sc_seco_secvio_enable and imx_sc_seco_secvio_enable).

To check the state of the SECVIO IRQ in the SCU, I added the
imx_scu_irq_get_status API.

The secvio driver is designed to receive the IRQ produced by the
SNVS in case of hardware attack and notify the status to the
audit framework which can be used by the user.

The goal of the driver is to be self suficient but can be extended by the
user to perform custom operations on values read (imx_sc_seco_secvio_enable)

v2:
 - Removed (firmware: imx: scu-rm: Add Resource Management APIs)
-> Code required is already present
 - Removed (firmware: imx: scu: Support reception of messages of any size)
-> The imx-scu is already working in fast-ipc mode
 - (soc: imx8: Add the SC SECVIO driver):
- Fixed the warnings reported by kernel test robot

Franck LENORMAND (5):
  firmware: imx: scu-seco: Add SEcure Controller APIS
  firmware: imx: scu-irq: Add API to retrieve status of IRQ
  dt-bindings: firmware: imx-scu: Add SECVIO resource
  dt-bindings: arm: imx: Documentation of the SC secvio driver
  soc: imx8: Add the SC SECVIO driver

 .../bindings/arm/freescale/fsl,imx-sc-secvio.yaml  |  34 +
 drivers/firmware/imx/Makefile  |   2 +-
 drivers/firmware/imx/imx-scu-irq.c |  37 +-
 drivers/firmware/imx/imx-scu.c |   3 +
 drivers/firmware/imx/seco.c| 275 +++
 drivers/soc/imx/Kconfig|  10 +
 drivers/soc/imx/Makefile   |   1 +
 drivers/soc/imx/secvio/Kconfig |  10 +
 drivers/soc/imx/secvio/Makefile|   3 +
 drivers/soc/imx/secvio/imx-secvio-audit.c  |  39 +
 drivers/soc/imx/secvio/imx-secvio-debugfs.c| 379 +
 drivers/soc/imx/secvio/imx-secvio-sc-int.h |  84 ++
 drivers/soc/imx/secvio/imx-secvio-sc.c | 858 +
 include/dt-bindings/firmware/imx/rsrc.h|   3 +-
 include/linux/firmware/imx/ipc.h   |   1 +
 include/linux/firmware/imx/sci.h   |   5 +
 include/linux/firmware/imx/svc/seco.h  |  73 ++
 include/soc/imx/imx-secvio-sc.h| 177 +
 18 files changed, 1991 insertions(+), 3 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/arm/freescale/fsl,imx-sc-secvio.yaml
 create mode 100644 drivers/firmware/imx/seco.c
 create mode 100644 drivers/soc/imx/secvio/Kconfig
 create mode 100644 drivers/soc/imx/secvio/Makefile
 create mode 100644 drivers/soc/imx/secvio/imx-secvio-audit.c
 create mode 100644 drivers/soc/imx/secvio/imx-secvio-debugfs.c
 create mode 100644 drivers/soc/imx/secvio/imx-secvio-sc-int.h
 create mode 100644 drivers/soc/imx/secvio/imx-secvio-sc.c
 create mode 100644 include/linux/firmware/imx/svc/seco.h
 create mode 100644 include/soc/imx/imx-secvio-sc.h

-- 
2.7.4

Re: [PATCH] interconnect: Do not skip aggregation for disabled paths

[adhudase]

On 2020-07-21 17:37, Georgi Djakov wrote:
When an interconnect path is being disabled, currently we don't 
aggregate
the requests for it afterwards. But the re-aggregation step shouldn't 
be

skipped, as it may leave the nodes with outdated bandwidth data. This
outdated data may actually keep the path still enabled and prevent the
device from going into lower power states.

Reported-by: Atul Dhudase 
Fixes: 7d374b209083 ("interconnect: Add helpers for enabling/disabling 
a path")

Signed-off-by: Georgi Djakov 
---


Tested-by: Atul Dhudase 
Reviewed-by: Atul Dhudase 


 drivers/interconnect/core.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/interconnect/core.c b/drivers/interconnect/core.c
index 37d5ec970cc1..5174dcb31ab7 100644
--- a/drivers/interconnect/core.c
+++ b/drivers/interconnect/core.c
@@ -243,6 +243,7 @@ static int aggregate_requests(struct icc_node 
*node)

 {
struct icc_provider *p = node->provider;
struct icc_req *r;
+   u32 avg_bw, peak_bw;

node->avg_bw = 0;
node->peak_bw = 0;
@@ -251,9 +252,14 @@ static int aggregate_requests(struct icc_node 
*node)

p->pre_aggregate(node);

hlist_for_each_entry(r, >req_list, req_node) {
-   if (!r->enabled)
-   continue;
-   p->aggregate(node, r->tag, r->avg_bw, r->peak_bw,
+   if (r->enabled) {
+   avg_bw = r->avg_bw;
+   peak_bw = r->peak_bw;
+   } else {
+   avg_bw = 0;
+   peak_bw = 0;
+   }
+   p->aggregate(node, r->tag, avg_bw, peak_bw,
 >avg_bw, >peak_bw);
}

Re: [RFC PATCH 4/7] x86: use exit_lazy_tlb rather than membarrier_mm_sync_core_before_usermode

[Peter Zijlstra]

On Tue, Jul 21, 2020 at 11:15:13AM -0400, Mathieu Desnoyers wrote:
> - On Jul 21, 2020, at 11:06 AM, Peter Zijlstra pet...@infradead.org wrote:
> 
> > On Tue, Jul 21, 2020 at 08:04:27PM +1000, Nicholas Piggin wrote:
> > 
> >> That being said, the x86 sync core gap that I imagined could be fixed
> >> by changing to rq->curr == rq->idle test does not actually exist because
> >> the global membarrier does not have a sync core option. So fixing the
> >> exit_lazy_tlb points that this series does *should* fix that. So
> >> PF_KTHREAD may be less problematic than I thought from implementation
> >> point of view, only semantics.
> > 
> > So I've been trying to figure out where that PF_KTHREAD comes from,
> > commit 227a4aadc75b ("sched/membarrier: Fix p->mm->membarrier_state racy
> > load") changed 'p->mm' to '!(p->flags & PF_KTHREAD)'.
> > 
> > So the first version:
> > 
> >  
> > https://lkml.kernel.org/r/20190906031300.1647-5-mathieu.desnoy...@efficios.com
> > 
> > appears to unconditionally send the IPI and checks p->mm in the IPI
> > context, but then v2:
> > 
> >  
> > https://lkml.kernel.org/r/20190908134909.12389-1-mathieu.desnoy...@efficios.com
> > 
> > has the current code. But I've been unable to find the reason the
> > 'p->mm' test changed into '!(p->flags & PF_KTHREAD)'.
> 
> Looking back at my inbox, it seems like you are the one who proposed to
> skip all kthreads: 
> 
> https://lkml.kernel.org/r/20190904124333.gq2...@hirez.programming.kicks-ass.net

I had a feeling it might've been me ;-) I just couldn't find the email.

> > The comment doesn't really help either; sure we have the whole lazy mm
> > thing, but that's ->active_mm, not ->mm.
> > 
> > Possibly it is because {,un}use_mm() do not have sufficient barriers to
> > make the remote p->mm test work? Or were we over-eager with the !p->mm
> > doesn't imply kthread 'cleanups' at the time?
> 
> The nice thing about adding back kthreads to the threads considered for 
> membarrier
> IPI is that it has no observable effect on the user-space ABI. No 
> pre-existing kthread
> rely on this, and we just provide an additional guarantee for future kthread
> implementations.
> 
> > Also, I just realized, I still have a fix for use_mm() now
> > kthread_use_mm() that seems to have been lost.
> 
> I suspect we need to at least document the memory barriers in kthread_use_mm 
> and
> kthread_unuse_mm to state that they are required by membarrier if we want to
> ipi kthreads as well.

Right, so going by that email you found it was mostly a case of being
lazy, but yes, if we audit the kthread_{,un}use_mm() barriers and add
any other bits that might be needed, covering kthreads should be
possible.

No objections from me for making it so.

Re: [PATCH ghak84 v4] audit: purge audit_log_string from the intra-kernel audit API

[Paul Moore]

On Tue, Jul 14, 2020 at 5:00 PM Richard Guy Briggs  wrote:
> On 2020-07-14 16:29, Paul Moore wrote:
> > On Tue, Jul 14, 2020 at 1:44 PM Richard Guy Briggs  wrote:
> > > On 2020-07-14 12:21, Paul Moore wrote:
> > > > On Mon, Jul 13, 2020 at 3:52 PM Richard Guy Briggs  
> > > > wrote:
> > > > >
> > > > > audit_log_string() was inteded to be an internal audit function and
> > > > > since there are only two internal uses, remove them.  Purge all 
> > > > > external
> > > > > uses of it by restructuring code to use an existing audit_log_format()
> > > > > or using audit_log_format().
> > > > >
> > > > > Please see the upstream issue
> > > > > https://github.com/linux-audit/audit-kernel/issues/84
> > > > >
> > > > > Signed-off-by: Richard Guy Briggs 
> > > > > ---
> > > > > Passes audit-testsuite.
> > > > >
> > > > > Changelog:
> > > > > v4
> > > > > - use double quotes in all replaced audit_log_string() calls
> > > > >
> > > > > v3
> > > > > - fix two warning: non-void function does not return a value in all 
> > > > > control paths
> > > > > Reported-by: kernel test robot 
> > > > >
> > > > > v2
> > > > > - restructure to piggyback on existing audit_log_format() calls, 
> > > > > checking quoting needs for each.
> > > > >
> > > > > v1 Vlad Dronov
> > > > > - 
> > > > > https://github.com/nefigtut/audit-kernel/commit/dbbcba46335a002f44b05874153a85b9cc18aebf
> > > > >
> > > > >  include/linux/audit.h |  5 -
> > > > >  kernel/audit.c|  4 ++--
> > > > >  security/apparmor/audit.c | 10 --
> > > > >  security/apparmor/file.c  | 25 +++--
> > > > >  security/apparmor/ipc.c   | 46 
> > > > > +++---
> > > > >  security/apparmor/net.c   | 14 --
> > > > >  security/lsm_audit.c  |  4 ++--
> > > > >  7 files changed, 46 insertions(+), 62 deletions(-)
> > > >
> > > > Thanks for restoring the quotes, just one question below ...
> > > >
> > > > > diff --git a/security/apparmor/ipc.c b/security/apparmor/ipc.c
> > > > > index 4ecedffbdd33..fe36d112aad9 100644
> > > > > --- a/security/apparmor/ipc.c
> > > > > +++ b/security/apparmor/ipc.c
> > > > > @@ -20,25 +20,23 @@
> > > > >
> > > > >  /**
> > > > >   * audit_ptrace_mask - convert mask to permission string
> > > > > - * @buffer: buffer to write string to (NOT NULL)
> > > > >   * @mask: permission mask to convert
> > > > > + *
> > > > > + * Returns: pointer to static string
> > > > >   */
> > > > > -static void audit_ptrace_mask(struct audit_buffer *ab, u32 mask)
> > > > > +static const char *audit_ptrace_mask(u32 mask)
> > > > >  {
> > > > > switch (mask) {
> > > > > case MAY_READ:
> > > > > -   audit_log_string(ab, "read");
> > > > > -   break;
> > > > > +   return "read";
> > > > > case MAY_WRITE:
> > > > > -   audit_log_string(ab, "trace");
> > > > > -   break;
> > > > > +   return "trace";
> > > > > case AA_MAY_BE_READ:
> > > > > -   audit_log_string(ab, "readby");
> > > > > -   break;
> > > > > +   return "readby";
> > > > > case AA_MAY_BE_TRACED:
> > > > > -   audit_log_string(ab, "tracedby");
> > > > > -   break;
> > > > > +   return "tracedby";
> > > > > }
> > > > > +   return "";
> > > >
> > > > Are we okay with this returning an empty string ("") in this case?
> > > > Should it be a question mark ("?")?
> > > >
> > > > My guess is that userspace parsing should be okay since it still has
> > > > quotes, I'm just not sure if we wanted to use a question mark as we do
> > > > in other cases where the field value is empty/unknown.
> > >
> > > Previously, it would have been an empty value, not even double quotes.
> > > "?" might be an improvement.
> >
> > Did you want to fix that now in this patch, or leave it to later?  As
> > I said above, I'm not too bothered by it with the quotes so either way
> > is fine by me.
>
> I'd defer to Steve, otherwise I'd say leave it, since there wasn't
> anything there before and this makes that more evident.
>
> > John, I'm assuming you are okay with this patch?

With no comments from John or Steve in the past week, I've gone ahead
and merged the patch into audit/next.

-- 
paul moore
www.paul-moore.com

Re: [PATCH v1] crypto: ccp: sp-pci: use generic power management

[Tom Lendacky]

On 7/21/20 7:31 AM, Vaibhav Gupta wrote:
> Drivers using legacy power management .suspen()/.resume() callbacks
> have to manage PCI states and device's PM states themselves. They also
> need to take care of standard configuration registers.
> 
> Switch to generic power management framework using a single
> "struct dev_pm_ops" variable to take the unnecessary load from the driver.
> This also avoids the need for the driver to directly call most of the PCI
> helper functions and device power state control functions as through
> the generic framework, PCI Core takes care of the necessary operations,
> and drivers are required to do only device-specific jobs.
> 
> Signed-off-by: Vaibhav Gupta 
> ---
>  drivers/crypto/ccp/ccp-dev.c |  8 +++-
>  drivers/crypto/ccp/sp-dev.c  |  6 ++
>  drivers/crypto/ccp/sp-dev.h  |  6 +++---
>  drivers/crypto/ccp/sp-pci.c  | 17 ++---
>  drivers/crypto/ccp/sp-platform.c |  2 +-
>  5 files changed, 15 insertions(+), 24 deletions(-)
> 
> diff --git a/drivers/crypto/ccp/ccp-dev.c b/drivers/crypto/ccp/ccp-dev.c
> index 19ac509ed76e..8ae26d3c 100644
> --- a/drivers/crypto/ccp/ccp-dev.c
> +++ b/drivers/crypto/ccp/ccp-dev.c
> @@ -531,8 +531,7 @@ int ccp_trng_read(struct hwrng *rng, void *data, size_t 
> max, bool wait)
>   return len;
>  }
>  
> -#ifdef CONFIG_PM
> -bool ccp_queues_suspended(struct ccp_device *ccp)
> +bool __maybe_unused ccp_queues_suspended(struct ccp_device *ccp)

These aren't static functions, so is the __maybe_unused necessary?

(Same comment on the other non-static functions changed below)

>  {
>   unsigned int suspended = 0;
>   unsigned long flags;
> @@ -549,7 +548,7 @@ bool ccp_queues_suspended(struct ccp_device *ccp)
>   return ccp->cmd_q_count == suspended;
>  }
>  
> -int ccp_dev_suspend(struct sp_device *sp, pm_message_t state)
> +int __maybe_unused ccp_dev_suspend(struct sp_device *sp)
>  {
>   struct ccp_device *ccp = sp->ccp_data;
>   unsigned long flags;
> @@ -577,7 +576,7 @@ int ccp_dev_suspend(struct sp_device *sp, pm_message_t 
> state)
>   return 0;
>  }
>  
> -int ccp_dev_resume(struct sp_device *sp)
> +int __maybe_unused ccp_dev_resume(struct sp_device *sp)
>  {
>   struct ccp_device *ccp = sp->ccp_data;
>   unsigned long flags;
> @@ -601,7 +600,6 @@ int ccp_dev_resume(struct sp_device *sp)
>  
>   return 0;
>  }
> -#endif
>  
>  int ccp_dev_init(struct sp_device *sp)
>  {
> diff --git a/drivers/crypto/ccp/sp-dev.c b/drivers/crypto/ccp/sp-dev.c
> index ce42675d3274..6284a15e5047 100644
> --- a/drivers/crypto/ccp/sp-dev.c
> +++ b/drivers/crypto/ccp/sp-dev.c
> @@ -211,13 +211,12 @@ void sp_destroy(struct sp_device *sp)
>   sp_del_device(sp);
>  }
>  
> -#ifdef CONFIG_PM
> -int sp_suspend(struct sp_device *sp, pm_message_t state)
> +int sp_suspend(struct sp_device *sp)
>  {
>   int ret;
>  
>   if (sp->dev_vdata->ccp_vdata) {
> - ret = ccp_dev_suspend(sp, state);
> + ret = ccp_dev_suspend(sp);
>   if (ret)
>   return ret;
>   }
> @@ -237,7 +236,6 @@ int sp_resume(struct sp_device *sp)
>  
>   return 0;
>  }
> -#endif
>  
>  struct sp_device *sp_get_psp_master_device(void)
>  {
> diff --git a/drivers/crypto/ccp/sp-dev.h b/drivers/crypto/ccp/sp-dev.h
> index f913f1494af9..0218d0670eee 100644
> --- a/drivers/crypto/ccp/sp-dev.h
> +++ b/drivers/crypto/ccp/sp-dev.h
> @@ -119,7 +119,7 @@ int sp_init(struct sp_device *sp);
>  void sp_destroy(struct sp_device *sp);
>  struct sp_device *sp_get_master(void);
>  
> -int sp_suspend(struct sp_device *sp, pm_message_t state);
> +int sp_suspend(struct sp_device *sp);
>  int sp_resume(struct sp_device *sp);
>  int sp_request_ccp_irq(struct sp_device *sp, irq_handler_t handler,
>  const char *name, void *data);
> @@ -134,7 +134,7 @@ struct sp_device *sp_get_psp_master_device(void);
>  int ccp_dev_init(struct sp_device *sp);
>  void ccp_dev_destroy(struct sp_device *sp);
>  
> -int ccp_dev_suspend(struct sp_device *sp, pm_message_t state);
> +int ccp_dev_suspend(struct sp_device *sp);
>  int ccp_dev_resume(struct sp_device *sp);
>  
>  #else/* !CONFIG_CRYPTO_DEV_SP_CCP */
> @@ -145,7 +145,7 @@ static inline int ccp_dev_init(struct sp_device *sp)
>  }
>  static inline void ccp_dev_destroy(struct sp_device *sp) { }
>  
> -static inline int ccp_dev_suspend(struct sp_device *sp, pm_message_t state)
> +static inline int ccp_dev_suspend(struct sp_device *sp)
>  {
>   return 0;
>  }
> diff --git a/drivers/crypto/ccp/sp-pci.c b/drivers/crypto/ccp/sp-pci.c
> index cb6cb47053f4..f471dbaef1fb 100644
> --- a/drivers/crypto/ccp/sp-pci.c
> +++ b/drivers/crypto/ccp/sp-pci.c
> @@ -252,23 +252,19 @@ static void sp_pci_remove(struct pci_dev *pdev)
>   sp_free_irqs(sp);
>  }
>  
> -#ifdef CONFIG_PM
> -static int sp_pci_suspend(struct pci_dev *pdev, pm_message_t state)
> +static int __maybe_unused sp_pci_suspend(struct device *dev)
>  {
> - 

Re: [RFC PATCH 4/7] x86: use exit_lazy_tlb rather than membarrier_mm_sync_core_before_usermode

[Mathieu Desnoyers]

- On Jul 21, 2020, at 11:06 AM, Peter Zijlstra pet...@infradead.org wrote:

> On Tue, Jul 21, 2020 at 08:04:27PM +1000, Nicholas Piggin wrote:
> 
>> That being said, the x86 sync core gap that I imagined could be fixed
>> by changing to rq->curr == rq->idle test does not actually exist because
>> the global membarrier does not have a sync core option. So fixing the
>> exit_lazy_tlb points that this series does *should* fix that. So
>> PF_KTHREAD may be less problematic than I thought from implementation
>> point of view, only semantics.
> 
> So I've been trying to figure out where that PF_KTHREAD comes from,
> commit 227a4aadc75b ("sched/membarrier: Fix p->mm->membarrier_state racy
> load") changed 'p->mm' to '!(p->flags & PF_KTHREAD)'.
> 
> So the first version:
> 
>  
> https://lkml.kernel.org/r/20190906031300.1647-5-mathieu.desnoy...@efficios.com
> 
> appears to unconditionally send the IPI and checks p->mm in the IPI
> context, but then v2:
> 
>  
> https://lkml.kernel.org/r/20190908134909.12389-1-mathieu.desnoy...@efficios.com
> 
> has the current code. But I've been unable to find the reason the
> 'p->mm' test changed into '!(p->flags & PF_KTHREAD)'.

Looking back at my inbox, it seems like you are the one who proposed to
skip all kthreads: 

https://lkml.kernel.org/r/20190904124333.gq2...@hirez.programming.kicks-ass.net

> 
> The comment doesn't really help either; sure we have the whole lazy mm
> thing, but that's ->active_mm, not ->mm.
> 
> Possibly it is because {,un}use_mm() do not have sufficient barriers to
> make the remote p->mm test work? Or were we over-eager with the !p->mm
> doesn't imply kthread 'cleanups' at the time?

The nice thing about adding back kthreads to the threads considered for 
membarrier
IPI is that it has no observable effect on the user-space ABI. No pre-existing 
kthread
rely on this, and we just provide an additional guarantee for future kthread
implementations.

> Also, I just realized, I still have a fix for use_mm() now
> kthread_use_mm() that seems to have been lost.

I suspect we need to at least document the memory barriers in kthread_use_mm and
kthread_unuse_mm to state that they are required by membarrier if we want to
ipi kthreads as well.

Thanks,

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

Re: [PATCH 02/10] block: virtio-blk: check logical block size

[Christoph Hellwig]

On Tue, Jul 21, 2020 at 01:52:31PM +0300, Maxim Levitsky wrote:
> Linux kernel only supports logical block sizes which are power of two,
> at least 512 bytes and no more that PAGE_SIZE.
> 
> Check this instead of crashing later on.
> 
> Note that there is no need to check physical block size since it is
> only a hint, and virtio-blk already only supports power of two values.
> 
> Bugzilla link: https://bugzilla.redhat.com/show_bug.cgi?id=1664619
> 
> Signed-off-by: Maxim Levitsky 
> ---
>  drivers/block/virtio_blk.c | 15 +--
>  1 file changed, 13 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
> index 980df853ee497..b5ee87cba00ed 100644
> --- a/drivers/block/virtio_blk.c
> +++ b/drivers/block/virtio_blk.c
> @@ -809,10 +809,18 @@ static int virtblk_probe(struct virtio_device *vdev)
>   err = virtio_cread_feature(vdev, VIRTIO_BLK_F_BLK_SIZE,
>  struct virtio_blk_config, blk_size,
>  _size);
> - if (!err)
> + if (!err) {
> + if (!blk_is_valid_logical_block_size(blk_size)) {
> + dev_err(>dev,
> + "%s failure: invalid logical block size %d\n",
> + __func__, blk_size);
> + err = -EINVAL;
> + goto out_cleanup_queue;
> + }
>   blk_queue_logical_block_size(q, blk_size);

Hmm, I wonder if we should simply add the check and warning to
blk_queue_logical_block_size and add an error in that case.  Then
drivers only have to check the error return, which might add a lot
less boiler plate code.

Re: Linux 5.8-rc6

[Linus Torvalds]

On Tue, Jul 21, 2020 at 1:17 AM Sedat Dilek  wrote:
>
> You happen to know if I can configure in my ~/.gitconfig to pull
> linux-git stuff from two repositories - check first git.kernel.org
> then GitHub.

Just script it. IOW, do

   git pull ..kernel.org..
   git pull ...github..

and if you _want_ to, you can just create an alias for that in your
.gitconfig so that you can do it with one "git update" command or
whatever.

But normally, they are both updated at pretty much the same time.

 Linus

Re: [PATCH v2 1/4] dt-bindings: hwlock: qcom: Migrate binding to YAML

[Rob Herring]

On Mon, Jun 22, 2020 at 1:59 AM Bjorn Andersson
 wrote:
>
> Migrate the Qualcomm TCSR mutex binding to YAML to allow validation.
>
> Reviewed-by: Vinod Koul 
> Signed-off-by: Bjorn Andersson 
> ---
>
> Changes since v1:
> - Actually remove the old binding doc
>
>  .../bindings/hwlock/qcom-hwspinlock.txt   | 39 --
>  .../bindings/hwlock/qcom-hwspinlock.yaml  | 51 +++
>  2 files changed, 51 insertions(+), 39 deletions(-)
>  delete mode 100644 
> Documentation/devicetree/bindings/hwlock/qcom-hwspinlock.txt
>  create mode 100644 
> Documentation/devicetree/bindings/hwlock/qcom-hwspinlock.yaml

[...]

> diff --git a/Documentation/devicetree/bindings/hwlock/qcom-hwspinlock.yaml 
> b/Documentation/devicetree/bindings/hwlock/qcom-hwspinlock.yaml
> new file mode 100644
> index ..71e63b52edd5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hwlock/qcom-hwspinlock.yaml
> @@ -0,0 +1,51 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/hwlock/qcom-hwspinlock.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Qualcomm Hardware Mutex Block
> +
> +maintainers:
> +  - Bjorn Andersson 
> +
> +description:
> +  The hardware block provides mutexes utilized between different processors 
> on
> +  the SoC as part of the communication protocol used by these processors.
> +
> +properties:
> +  compatible:
> +enum:
> +  - qcom,sfpb-mutex
> +  - qcom,tcsr-mutex
> +
> +  '#hwlock-cells':
> +const: 1
> +
> +  syscon:
> +$ref: "/schemas/types.yaml#/definitions/phandle-array"
> +description:
> +  Should be a triple of phandle referencing the TCSR mutex syscon, offset
> +  of first mutex within the syscon and stride between each mutex.
> +
> +required:
> +  - compatible
> +  - '#hwlock-cells'
> +  - syscon
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +tcsr_mutex_block: syscon@fd484000 {
> +compatible = "syscon";

'syscon' alone now generates warnings. Can you drop this node or add a
specific compatible.

> +reg = <0xfd484000 0x2000>;
> +};
> +
> +hwlock {
> +compatible = "qcom,tcsr-mutex";
> +syscon = <_mutex_block 0 0x80>;
> +
> +#hwlock-cells = <1>;
> +};
> +...
> --
> 2.26.2
>

[PATCH -next] drm/nouveau/kms/nvd9-: Fix file release memory leak

[Wei Yongjun]

When using single_open() for opening, single_release() should be
used instead of seq_release(), otherwise there is a memory leak.

Fixes: 12885ecbfe62 ("drm/nouveau/kms/nvd9-: Add CRC support")
Reported-by: Hulk Robot 
Signed-off-by: Wei Yongjun 
---
 drivers/gpu/drm/nouveau/dispnv50/crc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/nouveau/dispnv50/crc.c 
b/drivers/gpu/drm/nouveau/dispnv50/crc.c
index f17fb6d56757..4971a1042415 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/crc.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/crc.c
@@ -706,6 +706,7 @@ static const struct file_operations 
nv50_crc_flip_threshold_fops = {
.open = nv50_crc_debugfs_flip_threshold_open,
.read = seq_read,
.write = nv50_crc_debugfs_flip_threshold_set,
+   .release = single_release,
 };
 
 int nv50_head_crc_late_register(struct nv50_head *head)

Re: [PATCH 01/10] block: introduce blk_is_valid_logical_block_size

[Christoph Hellwig]

> +/**
> + * blk_check_logical_block_size - check if logical block size is supported
> + * by the kernel
> + * @size:  the logical block size, in bytes
> + *
> + * Description:
> + *   This function checks if the block layers supports given block size
> + **/
> +bool blk_is_valid_logical_block_size(unsigned int size)
> +{
> + return size >= SECTOR_SIZE && size <= PAGE_SIZE && !is_power_of_2(size);

Shouldn't this be a ... && is_power_of_2(size)?

>   if (q->limits.io_min < q->limits.physical_block_size)
>   q->limits.io_min = q->limits.physical_block_size;
> +
>  }

This adds a pointless empty line.

> +extern bool blk_is_valid_logical_block_size(unsigned int size);

No need for externs on function declarations.

Re: [PATCH] isst: isst_if.h: drop a duplicated word

[Srinivas Pandruvada]

On Sat, 2020-07-18 at 17:29 -0700, Randy Dunlap wrote:
> Drop the repeated word "for" in a comment.
> 
> Signed-off-by: Randy Dunlap 
> Cc: Srinivas Pandruvada 
> Cc: platform-driver-...@vger.kernel.org
> Cc: Darren Hart 
> Cc: Andy Shevchenko 
Acked-by: Srinivas Pandruvada 

> ---
> This description could still use some better wording.

I will fix the wording in a follow up patch.

>  include/uapi/linux/isst_if.h |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> --- linux-next-20200717.orig/include/uapi/linux/isst_if.h
> +++ linux-next-20200717/include/uapi/linux/isst_if.h
> @@ -69,7 +69,7 @@ struct isst_if_cpu_maps {
>   * @logical_cpu: Logical CPU number to get target PCI device.
>   * @reg: PUNIT register offset
>   * @value:   For write operation value to write and for
> - *   for read placeholder read value
> + *   read placeholder read value
>   *
>   * Structure to specify read/write data to PUNIT registers.
>   */

Re: kernel BUG at include/linux/swapops.h:LINE!

[Jens Axboe]

On 7/21/20 5:11 AM, Kirill A. Shutemov wrote:
> On Mon, Jul 20, 2020 at 04:51:44PM -0700, Andrew Morton wrote:
>> On Sun, 19 Jul 2020 14:10:19 -0700 syzbot 
>>  wrote:
>>
>>> syzbot has found a reproducer for the following issue on:
>>>
>>> HEAD commit:4c43049f Add linux-next specific files for 20200716
>>> git tree:   linux-next
>>> console output: https://syzkaller.appspot.com/x/log.txt?x=12c5608710
>>> kernel config:  https://syzkaller.appspot.com/x/.config?x=2c76d72659687242
>>> dashboard link: https://syzkaller.appspot.com/bug?extid=c48f34012b06c4ac67dd
>>> compiler:   gcc (GCC) 10.1.0-syz 20200507
>>> syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=1344abeb10
>>>
>>> IMPORTANT: if you fix the issue, please add the following tag to the commit:
>>> Reported-by: syzbot+c48f34012b06c4ac6...@syzkaller.appspotmail.com
>>
>> Thanks.
>>
>> __handle_mm_fault
>>   ->pmd_migration_entry_wait
>> ->migration_entry_to_page
>>
>> stumbled onto an unlocked page.
>>
>> I don't immediately see a cause.  Perhaps Matthew's "THP prep patches",
>> perhaps something else.
>>
>> Is it possible to perform a bisection?
> 
> Maybe it's related to the new lock_page_async()?

Shouldn't be used for any of those paths at all, though of course can't
rule out a bug that triggers it somehow. A bisection would be nice.


-- 
Jens Axboe

Re: [PATCH v1] hostap: use generic power management

[Vaibhav Gupta]

This patch is compile-tested only.

--Vaibhav Gupta

Re: [RFC PATCH 4/7] x86: use exit_lazy_tlb rather than membarrier_mm_sync_core_before_usermode

[peterz]

On Tue, Jul 21, 2020 at 08:04:27PM +1000, Nicholas Piggin wrote:

> That being said, the x86 sync core gap that I imagined could be fixed 
> by changing to rq->curr == rq->idle test does not actually exist because
> the global membarrier does not have a sync core option. So fixing the
> exit_lazy_tlb points that this series does *should* fix that. So
> PF_KTHREAD may be less problematic than I thought from implementation
> point of view, only semantics.

So I've been trying to figure out where that PF_KTHREAD comes from,
commit 227a4aadc75b ("sched/membarrier: Fix p->mm->membarrier_state racy
load") changed 'p->mm' to '!(p->flags & PF_KTHREAD)'.

So the first version:

  https://lkml.kernel.org/r/20190906031300.1647-5-mathieu.desnoy...@efficios.com

appears to unconditionally send the IPI and checks p->mm in the IPI
context, but then v2:

  
https://lkml.kernel.org/r/20190908134909.12389-1-mathieu.desnoy...@efficios.com

has the current code. But I've been unable to find the reason the
'p->mm' test changed into '!(p->flags & PF_KTHREAD)'.

The comment doesn't really help either; sure we have the whole lazy mm
thing, but that's ->active_mm, not ->mm.

Possibly it is because {,un}use_mm() do not have sufficient barriers to
make the remote p->mm test work? Or were we over-eager with the !p->mm
doesn't imply kthread 'cleanups' at the time?

Also, I just realized, I still have a fix for use_mm() now
kthread_use_mm() that seems to have been lost.

[PATCH v1] hostap: use generic power management

[Vaibhav Gupta]

Drivers using legacy power management .suspen()/.resume() callbacks
have to manage PCI states and device's PM states themselves. They also
need to take care of standard configuration registers.

Switch to generic power management framework using a single
"struct dev_pm_ops" variable to take the unnecessary load from the driver.
This also avoids the need for the driver to directly call most of the PCI
helper functions and device power state control functions as through
the generic framework, PCI Core takes care of the necessary operations,
and drivers are required to do only device-specific jobs.

Signed-off-by: Vaibhav Gupta 
---
 .../net/wireless/intersil/hostap/hostap_hw.c  |  6 ++--
 .../net/wireless/intersil/hostap/hostap_pci.c | 34 ++-
 2 files changed, 13 insertions(+), 27 deletions(-)

diff --git a/drivers/net/wireless/intersil/hostap/hostap_hw.c 
b/drivers/net/wireless/intersil/hostap/hostap_hw.c
index 2ab34cf74ecc..b6c497ce12e1 100644
--- a/drivers/net/wireless/intersil/hostap/hostap_hw.c
+++ b/drivers/net/wireless/intersil/hostap/hostap_hw.c
@@ -3366,8 +3366,8 @@ static void prism2_free_local_data(struct net_device *dev)
 }
 
 
-#if (defined(PRISM2_PCI) && defined(CONFIG_PM)) || defined(PRISM2_PCCARD)
-static void prism2_suspend(struct net_device *dev)
+#if defined(PRISM2_PCI) || defined(PRISM2_PCCARD)
+static void __maybe_unused prism2_suspend(struct net_device *dev)
 {
struct hostap_interface *iface;
struct local_info *local;
@@ -3385,7 +3385,7 @@ static void prism2_suspend(struct net_device *dev)
/* Disable hardware and firmware */
prism2_hw_shutdown(dev, 0);
 }
-#endif /* (PRISM2_PCI && CONFIG_PM) || PRISM2_PCCARD */
+#endif /* PRISM2_PCI || PRISM2_PCCARD */
 
 
 /* These might at some point be compiled separately and used as separate
diff --git a/drivers/net/wireless/intersil/hostap/hostap_pci.c 
b/drivers/net/wireless/intersil/hostap/hostap_pci.c
index 0c2aa880e32a..101887e6bd0f 100644
--- a/drivers/net/wireless/intersil/hostap/hostap_pci.c
+++ b/drivers/net/wireless/intersil/hostap/hostap_pci.c
@@ -403,36 +403,23 @@ static void prism2_pci_remove(struct pci_dev *pdev)
pci_disable_device(pdev);
 }
 
-
-#ifdef CONFIG_PM
-static int prism2_pci_suspend(struct pci_dev *pdev, pm_message_t state)
+static int __maybe_unused prism2_pci_suspend(struct device *dev_d)
 {
-   struct net_device *dev = pci_get_drvdata(pdev);
+   struct net_device *dev = dev_get_drvdata(dev_d);
 
if (netif_running(dev)) {
netif_stop_queue(dev);
netif_device_detach(dev);
}
prism2_suspend(dev);
-   pci_save_state(pdev);
-   pci_disable_device(pdev);
-   pci_set_power_state(pdev, PCI_D3hot);
 
return 0;
 }
 
-static int prism2_pci_resume(struct pci_dev *pdev)
+static int __maybe_unused prism2_pci_resume(struct device *dev_d)
 {
-   struct net_device *dev = pci_get_drvdata(pdev);
-   int err;
-
-   err = pci_enable_device(pdev);
-   if (err) {
-   printk(KERN_ERR "%s: pci_enable_device failed on resume\n",
-  dev->name);
-   return err;
-   }
-   pci_restore_state(pdev);
+   struct net_device *dev = dev_get_drvdata(dev_d);
+
prism2_hw_config(dev, 0);
if (netif_running(dev)) {
netif_device_attach(dev);
@@ -441,20 +428,19 @@ static int prism2_pci_resume(struct pci_dev *pdev)
 
return 0;
 }
-#endif /* CONFIG_PM */
-
 
 MODULE_DEVICE_TABLE(pci, prism2_pci_id_table);
 
+static SIMPLE_DEV_PM_OPS(prism2_pci_pm_ops,
+prism2_pci_suspend,
+prism2_pci_resume);
+
 static struct pci_driver prism2_pci_driver = {
.name   = "hostap_pci",
.id_table   = prism2_pci_id_table,
.probe  = prism2_pci_probe,
.remove = prism2_pci_remove,
-#ifdef CONFIG_PM
-   .suspend= prism2_pci_suspend,
-   .resume = prism2_pci_resume,
-#endif /* CONFIG_PM */
+   .driver.pm  = _pci_pm_ops,
 };
 
 module_pci_driver(prism2_pci_driver);
-- 
2.27.0

[PATCH -next] mtd: rawnand: pasemi: Make pasemi_device_ready() static

[Wei Yongjun]

The sparse tool complains as follows:

drivers/mtd/nand/raw/pasemi_nand.c:71:5: warning:
 symbol 'pasemi_device_ready' was not declared. Should it be static?

This function is not used outside of pasemi_nand.c, so this commit
marks it static.

Reported-by: Hulk Robot 
Signed-off-by: Wei Yongjun 
---
 drivers/mtd/nand/raw/pasemi_nand.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/nand/raw/pasemi_nand.c 
b/drivers/mtd/nand/raw/pasemi_nand.c
index d8eca8c3fdcd..81e2e667037e 100644
--- a/drivers/mtd/nand/raw/pasemi_nand.c
+++ b/drivers/mtd/nand/raw/pasemi_nand.c
@@ -68,7 +68,7 @@ static void pasemi_hwcontrol(struct nand_chip *chip, int cmd,
inl(lpcctl);
 }
 
-int pasemi_device_ready(struct nand_chip *chip)
+static int pasemi_device_ready(struct nand_chip *chip)
 {
return !!(inl(lpcctl) & LBICTRL_LPCCTL_NR);
 }

arm: tinyconfig: entry-common.S:156: Error: r13 not allowed here -- `bic tsk,sp,#(((1<<12)<<1)-1)&~63'

[Naresh Kamboju]

This might add little value.

arm build sets failed on linux next 20200721.
The defconfig ( +config fragments ) builds PASS.
The tinyconfig and allnoconfig FAILED with gcc-8, gcc-9 and gcc-10.

make -sk KBUILD_BUILD_USER=TuxBuild -C/linux -j32 ARCH=arm
CROSS_COMPILE=arm-linux-gnueabihf- HOSTCC=gcc CC="sccache
arm-linux-gnueabihf-gcc" O=build zImage
#
../arch/arm/kernel/entry-common.S: Assembler messages:
../arch/arm/kernel/entry-common.S:156: Error: r13 not allowed here --
`bic tsk,sp,#(((1<<12)<<1)-1)&~63'
../arch/arm/kernel/entry-common.S:243: Error: r13 not allowed here --
`bic tsk,sp,#(((1<<12)<<1)-1)&~63'
make[3]: *** [../scripts/Makefile.build:361:
arch/arm/kernel/entry-common.o] Error 1
../arch/arm/kernel/entry-v7m.S: Assembler messages:
../arch/arm/kernel/entry-v7m.S:60: Error: r13 not allowed here -- `bic
tsk,sp,#(((1<<12)<<1)-1)&~63'
../arch/arm/kernel/entry-v7m.S:86: Error: r13 not allowed here -- `bic
tsk,sp,#(((1<<12)<<1)-1)&~63'
make[3]: *** [../scripts/Makefile.build:361:
arch/arm/kernel/entry-v7m.o] Error 1

full build link,
https://gitlab.com/Linaro/lkft/kernel-runs/-/jobs/648560264

-- 
Linaro LKFT
https://lkft.linaro.org

[PATCH -next] soc: TI knav_qmss: make symbol 'knav_acc_range_ops' static

[Wei Yongjun]

The sparse tool complains as follows:

drivers/soc/ti/knav_qmss_acc.c:453:23: warning:
 symbol 'knav_acc_range_ops' was not declared. Should it be static?

'knav_acc_range_ops' is not used outside of knav_qmss_acc.c,
so marks it static.

Reported-by: Hulk Robot 
Signed-off-by: Wei Yongjun 
---
 drivers/soc/ti/knav_qmss_acc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/soc/ti/knav_qmss_acc.c b/drivers/soc/ti/knav_qmss_acc.c
index 1762d89fc05d..fde66e28e046 100644
--- a/drivers/soc/ti/knav_qmss_acc.c
+++ b/drivers/soc/ti/knav_qmss_acc.c
@@ -450,7 +450,7 @@ static int knav_acc_free_range(struct knav_range_info 
*range)
return 0;
 }
 
-struct knav_range_ops knav_acc_range_ops = {
+static struct knav_range_ops knav_acc_range_ops = {
.set_notify = knav_acc_set_notify,
.init_queue = knav_acc_init_queue,
.open_queue = knav_acc_open_queue,

[PATCH][next] phy: qualcomm: fix setting of tx_deamp_3_5db when device property read fails

[Colin King]

From: Colin Ian King 

Currently when reading of the device property for "qcom,tx-deamp_3_5db"
fails the default is being assigned incorrectly to phy_dwc3->rx_eq. This
looks like a copy-n-paste error and in fact should be assigning the
default instead to phy_dwc3->tx_deamp_3_5db

Addresses-Coverity: ("Copy-paste error")
Fixes: ef19b117b834 ("phy: qualcomm: add qcom ipq806x dwc usb phy driver")
Signed-off-by: Colin Ian King 
---
 drivers/phy/qualcomm/phy-qcom-ipq806x-usb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/phy/qualcomm/phy-qcom-ipq806x-usb.c 
b/drivers/phy/qualcomm/phy-qcom-ipq806x-usb.c
index a7241bf110d7..71f257b4a7f5 100644
--- a/drivers/phy/qualcomm/phy-qcom-ipq806x-usb.c
+++ b/drivers/phy/qualcomm/phy-qcom-ipq806x-usb.c
@@ -531,7 +531,7 @@ static int qcom_ipq806x_usb_phy_probe(struct 
platform_device *pdev)
 
if (device_property_read_u32(>dev, "qcom,tx-deamp_3_5db",
 _dwc3->tx_deamp_3_5db))
-   phy_dwc3->rx_eq = SSPHY_TX_DEEMPH_3_5DB;
+   phy_dwc3->tx_deamp_3_5db = SSPHY_TX_DEEMPH_3_5DB;
 
if (device_property_read_u32(>dev, "qcom,mpll", _dwc3->mpll))
phy_dwc3->mpll = SSPHY_MPLL_VALUE;
-- 
2.27.0

Re: [PATCH 1/1] iommu/arm-smmu: Implement qcom,skip-init

[Konrad Dybcio]

So.. is this a no-no?

I of course would like to omit this entirely, but SMMUs on sdm630 and
friends are REALLY picky.. What seems to happen is that when the
driver tries to do things the "standard" way, hypervisor decides to
hang the platform or force a reboot. Not very usable.


This thing is needed for the platform to even boot properly and one
more [1] is required to make mdss work with video mode panels (the
fact that CMD-mode panels work is kinda hilarious to me).

To be honest, there are even more qcom quirks (of which at least
qcom,dynamic and qcom-use-3-lvl-tables are used on 630).. [2]

Looking forward to your answers and possibly better solutions.

[1] 
https://github.com/konradybcio/linux/commit/83ac38af259968f92b6a8b7eab90096c78469f87
[2] 
https://github.com/sonyxperiadev/kernel/blob/aosp/LA.UM.7.1.r1/drivers/iommu/arm-smmu.c#L404-L415

Regards
Konrad

Re: [PATCH] selftests: txtimestamp: tear down setup() 'tc' and 'ip' env on EXIT

[Willem de Bruijn]

On Tue, Jul 21, 2020 at 10:52 AM Paolo Pisati
 wrote:
>
> Add a cleanup() path upon exit, making it possible to run the test twice in a
> row:
>
> $ sudo bash -x ./txtimestamp.sh
> + set -e
> ++ ip netns identify
> + [[ '' == \r\o\o\t ]]
> + main
> + [[ 0 -eq 0 ]]
> + run_test_all
> + setup
> + tc qdisc add dev lo root netem delay 1ms
> Error: Exclusivity flag on, cannot modify.
>
> Signed-off-by: Paolo Pisati 

The test should already clean up after itself, by being run inside a
network namespace. That is a more robust method to ensure that all
state is reset.

The issue here is that the else branch is taken in

  if [[ "$(ip netns identify)" == "root" ]]; then
  ./in_netns.sh $0 $@
  else
  main $@
  fi

because the ip netns identify usually returns an empty string, not
"root". If we fix that, no need to add additional cleanup.

Re: [PATCH v2] Fix zone-append error code

[Kanchan Joshi]

Hi Jens,
Is this fine to be picked?

On Mon, Jul 6, 2020 at 1:06 AM Kanchan Joshi  wrote:
>
> Changes since v1:
> - updated commit description
> - added reviewed-by
>
> Kanchan Joshi (1):
>   block: fix error code for zone-append
>
>  block/bio.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> --
> 2.7.4
>


-- 
Kanchan Joshi

Re: nouveau regression with 5.7 caused by "PCI/PM: Assume ports without DLL Link Active train links in 100 ms"

[Lyude Paul]

Sure thing. Also, feel free to let me know if you'd like access to one of the
systems we saw breaking with this patch - I'm fairly sure I've got one of them
locally at my apartment and don't mind setting up AMT/KVM/SSH

On Tue, 2020-07-21 at 15:22 +0300, Mika Westerberg wrote:
> Hi,
> 
> [Sorry for the delay, I was on vacation]
> 
> On Fri, Jul 17, 2020 at 01:32:10PM +0200, Karol Herbst wrote:
> > Filed at https://bugzilla.kernel.org/show_bug.cgi?id=208597
> 
> Thanks for reporting.
> 
> I'll check your logs and try to figure if there is something we can do
> to make both nouveau and TBT working at the same time.
> 
> > oddly enough I wasn't able to reproduce it on my XPS 9560, will ping
> > once something breaks.
-- 
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat

Re: [PATCH] arm64: dts: qcom: sdm845: Support ETMv4 power management

[Mathieu Poirier]

On Tue, Jul 21, 2020 at 12:43:43PM +0530, Sai Prakash Ranjan wrote:
> Add "arm,coresight-loses-context-with-cpu" property to coresight
> ETM nodes to avoid failure of trace session because of losing
> context on entering deep idle states.
> 
> Signed-off-by: Sai Prakash Ranjan 
> ---
>  arch/arm64/boot/dts/qcom/sdm845.dtsi | 8 
>  1 file changed, 8 insertions(+)

Reviewed-by: Mathieu Poirier 

> 
> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi 
> b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> index e506793407d8..0b5f063dcaea 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> @@ -3016,6 +3016,7 @@ etm@704 {
>  
>   clocks = <_qmp>;
>   clock-names = "apb_pclk";
> + arm,coresight-loses-context-with-cpu;
>  
>   out-ports {
>   port {
> @@ -3035,6 +3036,7 @@ etm@714 {
>  
>   clocks = <_qmp>;
>   clock-names = "apb_pclk";
> + arm,coresight-loses-context-with-cpu;
>  
>   out-ports {
>   port {
> @@ -3054,6 +3056,7 @@ etm@724 {
>  
>   clocks = <_qmp>;
>   clock-names = "apb_pclk";
> + arm,coresight-loses-context-with-cpu;
>  
>   out-ports {
>   port {
> @@ -3073,6 +3076,7 @@ etm@734 {
>  
>   clocks = <_qmp>;
>   clock-names = "apb_pclk";
> + arm,coresight-loses-context-with-cpu;
>  
>   out-ports {
>   port {
> @@ -3092,6 +3096,7 @@ etm@744 {
>  
>   clocks = <_qmp>;
>   clock-names = "apb_pclk";
> + arm,coresight-loses-context-with-cpu;
>  
>   out-ports {
>   port {
> @@ -3111,6 +3116,7 @@ etm@754 {
>  
>   clocks = <_qmp>;
>   clock-names = "apb_pclk";
> + arm,coresight-loses-context-with-cpu;
>  
>   out-ports {
>   port {
> @@ -3130,6 +3136,7 @@ etm@764 {
>  
>   clocks = <_qmp>;
>   clock-names = "apb_pclk";
> + arm,coresight-loses-context-with-cpu;
>  
>   out-ports {
>   port {
> @@ -3149,6 +3156,7 @@ etm@774 {
>  
>   clocks = <_qmp>;
>   clock-names = "apb_pclk";
> + arm,coresight-loses-context-with-cpu;
>  
>   out-ports {
>   port {
> -- 
> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
> of Code Aurora Forum, hosted by The Linux Foundation
> 

Re: [RFC PATCH] mm: silence soft lockups from unlock_page

[Michal Hocko]

On Tue 21-07-20 15:17:49, Chris Down wrote:
> I understand the pragmatic considerations here, but I'm quite concerned
> about the maintainability and long-term ability to reason about a patch like
> this.  For example, how do we know when this patch is safe to remove? Also,
> what other precedent does this set for us covering for poor userspace
> behaviour?
> 
> Speaking as a systemd maintainer, if udev could be doing something better on
> these machines, we'd be more than receptive to help fix it. In general I am
> against explicit watchdog tweaking here because a.) there's potential to
> mask other problems, and b.) it seems like the kind of one-off trivia nobody
> is going to remember exists when doing complex debugging in future.
> 
> Is there anything preventing this being remedied in udev, instead of the
> kernel?

Yes, I believe that there is a configuration to cap the maximum number
of workers. This is not my area but my understanding is that the maximum
is tuned based on available memory and/or cpus. We have been hit byt
this quite heavily on SLES. Maybe newer version of systemd have a better
tuning.

But, it seems that udev is just a messenger here. There is nothing
really fundamentally udev specific in the underlying problem unless I
miss something. It is quite possible that this could be triggered by
other userspace which happens to fire many workers at the same time and
condending on a shared page.

Not that I like this workaround in the first place but it seems that the
existing code allows very long wait chains and !PREEMPT kernels simply
do not have any scheduling point for a long time potentially. I believe
we should focus on that even if the systemd as the current trigger can
be tuned better. I do not insist on this patch, hence RFC, but I am
simply not seeing a much better, yet not convoluted, solution.

-- 
Michal Hocko
SUSE Labs

Re: [PATCH v3 0/2] Selftest for cpuidle latency measurement

[Daniel Lezcano]

On 21/07/2020 14:42, Pratik Rajesh Sampat wrote:
> v2: https://lkml.org/lkml/2020/7/17/369
> Changelog v2-->v3
> Based on comments from Gautham R. Shenoy adding the following in the
> selftest,
> 1. Grepping modules to determine if already loaded
> 2. Wrapper to enable/disable states
> 3. Preventing any operation/test on offlined CPUs 
> ---
> 
> The patch series introduces a mechanism to measure wakeup latency for
> IPI and timer based interrupts
> The motivation behind this series is to find significant deviations
> behind advertised latency and resisdency values

Why do you want to measure for the timer and the IPI ? Whatever the
source of the wakeup, the exit latency remains the same, no ?

Is all this kernel-ish code really needed ?

What about using a highres periodic timer and make it expires every eg.
50ms x 2400, so it is 120 secondes and measure the deviation. Repeat the
operation for each idle states.

And in order to make it as much accurate as possible, set the program
affinity on a CPU and isolate this one by preventing other processes to
be scheduled on and migrate the interrupts on the other CPUs.

That will be all userspace code, no?





-- 
 Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

Re: [PATCH 2/4] printk: store instead of processing cont parts

[John Ogness]

On 2020-07-21, Sergey Senozhatsky  wrote:
>> That said, we have traditionally used not just "current process", but
>> also "last irq-level" as the context information, so I do think it
>> would be good to continue to do that.
>
> OK, so basically, extending printk_caller_id() so that for IRQ/NMI
> we will have more info than just "0x8000 + raw_smp_processor_id()".

If bit31 is set, the upper 8 bits could specify what the lower 24 bits
represent. That would give some freedom for the future.

For example:

0x80 = cpu id (generic context)
0x81 = interrupt number
0x82 = cpu id (nmi context)

Or maybe ascii should be used instead?

0x80 | '\0' = cpu id (generic context)
0x80 | 'i'  = interrupt number
0x80 | 'n'  = cpu id (nmi context)

Just an idea.

John Ogness

Re: [PATCH v3 2/3] powerpc/powernv/idle: Rename pnv_first_spr_loss_level variable

[Gautham R Shenoy]

Hi,

On Wed, Jul 22, 2020 at 12:37:41AM +1000, Nicholas Piggin wrote:
> Excerpts from Pratik Sampat's message of July 21, 2020 8:29 pm:
> > 
> > 
> > On 20/07/20 5:27 am, Nicholas Piggin wrote:
> >> Excerpts from Pratik Rajesh Sampat's message of July 18, 2020 4:53 am:
> >>> Replace the variable name from using "pnv_first_spr_loss_level" to
> >>> "pnv_first_fullstate_loss_level".
> >>>
> >>> As pnv_first_spr_loss_level is supposed to be the earliest state that
> >>> has OPAL_PM_LOSE_FULL_CONTEXT set, however as shallow states too loose
> >>> SPR values, render an incorrect terminology.
> >> It also doesn't lose "full" state at this loss level though. From the
> >> architecture it could be called "hv state loss level", but in POWER10
> >> even that is not strictly true.
> >>
> > Right. Just discovered that deep stop states won't loose full state
> > P10 onwards.
> > Would it better if we rename it as "pnv_all_spr_loss_state" instead
> > so that it stays generic enough while being semantically coherent?
> 
> It doesn't lose all SPRs. It does physically, but for Linux it appears 
> at least timebase SPRs are retained and that's mostly how it's 
> documented.
> 
> Maybe there's no really good name for it, but we do call it "deep" stop 
> in other places, you could call it deep_spr_loss maybe. I don't mind too 
> much though, whatever Gautham is happy with.

Nick's suggestion is fine by me. We can call it deep_spr_loss_state.

> 
> Thanks,
> Nick

--
Thanks and Regards
gautham.

[Regression] hangs caused by commit 3202fa62fb (slub: relocate freelist pointer to middle of object)

[Paul Menzel]

Dear Kees, dear Andrew,


No idea, if you are aware of it yet, but three people verified that 
commit 3202fa62fb (slub: relocate freelist pointer to middle of object) 
causes a regression on AMD hardware [1].


It’d be great, if you took a look, and advised if this commit (and 
follow-ups) should be reverted, until the issue is analyzed.



Kind regards,

Paul


[1]: https://bugzilla.kernel.org/show_bug.cgi?id=207383
 "[Regression] 5.7 amdgpu/polaris11 gpf: amdgpu_atomic_commit_tail"

Re: [PATCH] PCI/ATS: PASID and PRI are only enumerated in PF devices.

[Bjorn Helgaas]

On Mon, Jul 20, 2020 at 09:43:00AM -0700, Ashok Raj wrote:
> PASID and PRI capabilities are only enumerated in PF devices. VF devices
> do not enumerate these capabilites. IOMMU drivers also need to enumerate
> them before enabling features in the IOMMU. Extending the same support as
> PASID feature discovery (pci_pasid_features) for PRI.
> 
> Signed-off-by: Ashok Raj 

Hi Ashok,

When you update this for the 0-day implicit declaration thing, can you
update the subject to say what the patch *does*, as opposed to what it
is solving?  Also, no need for a period at the end.

Does this fix a regression?  Is it associated with a commit that we
could add as a "Fixes:" tag so we know how far back to try to apply
to stable kernels?

> To: Bjorn Helgaas 
> To: Joerg Roedel 
> To: Lu Baolu 
> Cc: sta...@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: Ashok Raj 
> Cc: io...@lists.linux-foundation.org
> ---
>  drivers/iommu/intel/iommu.c |  2 +-
>  drivers/pci/ats.c   | 14 ++
>  include/linux/pci-ats.h |  1 +
>  3 files changed, 16 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
> index d759e7234e98..276452f5e6a7 100644
> --- a/drivers/iommu/intel/iommu.c
> +++ b/drivers/iommu/intel/iommu.c
> @@ -2560,7 +2560,7 @@ static struct dmar_domain 
> *dmar_insert_one_dev_info(struct intel_iommu *iommu,
>   }
>  
>   if (info->ats_supported && ecap_prs(iommu->ecap) &&
> - pci_find_ext_capability(pdev, PCI_EXT_CAP_ID_PRI))
> + pci_pri_supported(pdev))
>   info->pri_supported = 1;
>   }
>   }
> diff --git a/drivers/pci/ats.c b/drivers/pci/ats.c
> index b761c1f72f67..ffb4de8c5a77 100644
> --- a/drivers/pci/ats.c
> +++ b/drivers/pci/ats.c
> @@ -461,6 +461,20 @@ int pci_pasid_features(struct pci_dev *pdev)
>  }
>  EXPORT_SYMBOL_GPL(pci_pasid_features);
>  
> +/**
> + * pci_pri_supported - Check if PRI is supported.
> + * @pdev: PCI device structure
> + *
> + * Returns false when no PRI capability is present.
> + * Returns true if PRI feature is supported and enabled
> + */
> +bool pci_pri_supported(struct pci_dev *pdev)
> +{
> + /* VFs share the PF PRI configuration */
> + return !!(pci_physfn(pdev)->pri_cap);
> +}
> +EXPORT_SYMBOL_GPL(pci_pri_supported);
> +
>  #define PASID_NUMBER_SHIFT   8
>  #define PASID_NUMBER_MASK(0x1f << PASID_NUMBER_SHIFT)
>  /**
> diff --git a/include/linux/pci-ats.h b/include/linux/pci-ats.h
> index f75c307f346d..073d57292445 100644
> --- a/include/linux/pci-ats.h
> +++ b/include/linux/pci-ats.h
> @@ -28,6 +28,7 @@ int pci_enable_pri(struct pci_dev *pdev, u32 reqs);
>  void pci_disable_pri(struct pci_dev *pdev);
>  int pci_reset_pri(struct pci_dev *pdev);
>  int pci_prg_resp_pasid_required(struct pci_dev *pdev);
> +bool pci_pri_supported(struct pci_dev *pdev);
>  #endif /* CONFIG_PCI_PRI */
>  
>  #ifdef CONFIG_PCI_PASID
> -- 
> 2.7.4
> 

[PATCH] selftests: txtimestamp: tear down setup() 'tc' and 'ip' env on EXIT

[Paolo Pisati]

Add a cleanup() path upon exit, making it possible to run the test twice in a
row:

$ sudo bash -x ./txtimestamp.sh
+ set -e
++ ip netns identify
+ [[ '' == \r\o\o\t ]]
+ main
+ [[ 0 -eq 0 ]]
+ run_test_all
+ setup
+ tc qdisc add dev lo root netem delay 1ms
Error: Exclusivity flag on, cannot modify.

Signed-off-by: Paolo Pisati 
---
 tools/testing/selftests/net/txtimestamp.sh | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/tools/testing/selftests/net/txtimestamp.sh 
b/tools/testing/selftests/net/txtimestamp.sh
index eea6f5193693..77f29cabff87 100755
--- a/tools/testing/selftests/net/txtimestamp.sh
+++ b/tools/testing/selftests/net/txtimestamp.sh
@@ -23,6 +23,14 @@ setup() {
action mirred egress redirect dev ifb_netem0
 }
 
+cleanup() {
+   tc filter del dev lo parent :
+   tc qdisc del dev lo handle : ingress
+   tc qdisc del dev ifb_netem0 root
+   ip link del ifb_netem0
+   tc qdisc del dev lo root
+}
+
 run_test_v4v6() {
# SND will be delayed 1000us
# ACK will be delayed 6000us: 1 + 2 ms round-trip
@@ -75,6 +83,8 @@ main() {
fi
 }
 
+trap cleanup EXIT
+
 if [[ "$(ip netns identify)" == "root" ]]; then
./in_netns.sh $0 $@
 else
-- 
2.27.0

Re: [PATCH v2] Makefile: Fix GCC_TOOLCHAIN_DIR prefix for Clang cross compilation

[Sedat Dilek]

On Tue, Jul 21, 2020 at 12:40 PM Greg KH  wrote:
>
> On Mon, Jul 20, 2020 at 09:19:38PM -0700, Fangrui Song wrote:
> > When CROSS_COMPILE is set (e.g. aarch64-linux-gnu-), if
> > $(CROSS_COMPILE)elfedit is found at /usr/bin/aarch64-linux-gnu-elfedit,
> > GCC_TOOLCHAIN_DIR will be set to /usr/bin/.  --prefix= will be set to
> > /usr/bin/ and Clang as of 11 will search for both
> > $(prefix)aarch64-linux-gnu-$needle and $(prefix)$needle.
> >
> > GCC searchs for $(prefix)aarch64-linux-gnu/$version/$needle,
> > $(prefix)aarch64-linux-gnu/$needle and $(prefix)$needle. In practice,
> > $(prefix)aarch64-linux-gnu/$needle rarely contains executables.
> >
> > To better model how GCC's -B/--prefix takes in effect in practice, newer
> > Clang (since
> > https://github.com/llvm/llvm-project/commit/3452a0d8c17f7166f479706b293caf6ac76ffd90)
> > only searches for $(prefix)$needle. Currently it will find /usr/bin/as
> > instead of /usr/bin/aarch64-linux-gnu-as.
> >
> > Set --prefix= to $(GCC_TOOLCHAIN_DIR)$(CROSS_COMPILE)
> > (/usr/bin/aarch64-linux-gnu-) so that newer Clang can find the
> > appropriate cross compiling GNU as (when -no-integrated-as is in
> > effect).
> >
> > Reported-by: Nathan Chancellor 
> > Signed-off-by: Fangrui Song 
> > Reviewed-by: Nathan Chancellor 
> > Tested-by: Nathan Chancellor 
> > Tested-by: Nick Desaulniers 
> > Link: https://github.com/ClangBuiltLinux/linux/issues/1099
> > ---
> > Changes in v2:
> > * Updated description to add tags and the llvm-project commit link.
> > * Fixed a typo.
>
>
> 
>
> This is not the correct way to submit patches for inclusion in the
> stable kernel tree.  Please read:
> https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
> for how to do this properly.
>
> 
>

Hi Fangrui,

your patch needs to be accepted first in Linus tree - among other
things to have a unique commit-id for inclusion into any affected
Linux-stable trees.

Regards,
- Sedat -

[PATCH 1/2] gpio: gpio-sch.c: changed every 'unsigned' to 'unsigned int'

[Abanoub Sameh]

Changed 'unsigned' to 'unsigned int'.
This makes the code more uniform, and compliant with the kernel coding style.

Signed-off-by: Abanoub Sameh 
---
 drivers/gpio/gpio-sch.c | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/gpio/gpio-sch.c b/drivers/gpio/gpio-sch.c
index c65f35b68202..d7cade67717b 100644
--- a/drivers/gpio/gpio-sch.c
+++ b/drivers/gpio/gpio-sch.c
@@ -26,10 +26,10 @@ struct sch_gpio {
unsigned short resume_base;
 };
 
-static unsigned sch_gpio_offset(struct sch_gpio *sch, unsigned gpio,
-   unsigned reg)
+static unsigned int sch_gpio_offset(struct sch_gpio *sch, unsigned int gpio,
+   unsigned int reg)
 {
-   unsigned base = 0;
+   unsigned int base = 0;
 
if (gpio >= sch->resume_base) {
gpio -= sch->resume_base;
@@ -39,14 +39,14 @@ static unsigned sch_gpio_offset(struct sch_gpio *sch, 
unsigned gpio,
return base + reg + gpio / 8;
 }
 
-static unsigned sch_gpio_bit(struct sch_gpio *sch, unsigned gpio)
+static unsigned int sch_gpio_bit(struct sch_gpio *sch, unsigned int gpio)
 {
if (gpio >= sch->resume_base)
gpio -= sch->resume_base;
return gpio % 8;
 }
 
-static int sch_gpio_reg_get(struct sch_gpio *sch, unsigned gpio, unsigned reg)
+static int sch_gpio_reg_get(struct sch_gpio *sch, unsigned int gpio, unsigned 
int reg)
 {
unsigned short offset, bit;
u8 reg_val;
@@ -59,7 +59,7 @@ static int sch_gpio_reg_get(struct sch_gpio *sch, unsigned 
gpio, unsigned reg)
return reg_val;
 }
 
-static void sch_gpio_reg_set(struct sch_gpio *sch, unsigned gpio, unsigned reg,
+static void sch_gpio_reg_set(struct sch_gpio *sch, unsigned int gpio, unsigned 
int reg,
 int val)
 {
unsigned short offset, bit;
@@ -76,7 +76,7 @@ static void sch_gpio_reg_set(struct sch_gpio *sch, unsigned 
gpio, unsigned reg,
outb((reg_val & ~BIT(bit)), sch->iobase + offset);
 }
 
-static int sch_gpio_direction_in(struct gpio_chip *gc, unsigned gpio_num)
+static int sch_gpio_direction_in(struct gpio_chip *gc, unsigned int gpio_num)
 {
struct sch_gpio *sch = gpiochip_get_data(gc);
 
@@ -86,13 +86,13 @@ static int sch_gpio_direction_in(struct gpio_chip *gc, 
unsigned gpio_num)
return 0;
 }
 
-static int sch_gpio_get(struct gpio_chip *gc, unsigned gpio_num)
+static int sch_gpio_get(struct gpio_chip *gc, unsigned int gpio_num)
 {
struct sch_gpio *sch = gpiochip_get_data(gc);
return sch_gpio_reg_get(sch, gpio_num, GLV);
 }
 
-static void sch_gpio_set(struct gpio_chip *gc, unsigned gpio_num, int val)
+static void sch_gpio_set(struct gpio_chip *gc, unsigned int gpio_num, int val)
 {
struct sch_gpio *sch = gpiochip_get_data(gc);
 
@@ -101,7 +101,7 @@ static void sch_gpio_set(struct gpio_chip *gc, unsigned 
gpio_num, int val)
spin_unlock(>lock);
 }
 
-static int sch_gpio_direction_out(struct gpio_chip *gc, unsigned gpio_num,
+static int sch_gpio_direction_out(struct gpio_chip *gc, unsigned int gpio_num,
  int val)
 {
struct sch_gpio *sch = gpiochip_get_data(gc);
@@ -123,7 +123,7 @@ static int sch_gpio_direction_out(struct gpio_chip *gc, 
unsigned gpio_num,
return 0;
 }
 
-static int sch_gpio_get_direction(struct gpio_chip *gc, unsigned gpio_num)
+static int sch_gpio_get_direction(struct gpio_chip *gc, unsigned int gpio_num)
 {
struct sch_gpio *sch = gpiochip_get_data(gc);
 
-- 
2.28.0.rc0

[PATCH 3/4] gpio: gpio-msic.c: fixed coding style issues

[Abanoub Sameh]

Added a lined between declarations and other statements according to the
kenel coding style.

Signed-off-by: Abanoub Sameh 
---
 drivers/gpio/gpio-msic.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpio/gpio-msic.c b/drivers/gpio/gpio-msic.c
index 0bef1a5a9b70..84e00e0ab953 100644
--- a/drivers/gpio/gpio-msic.c
+++ b/drivers/gpio/gpio-msic.c
@@ -166,12 +166,14 @@ static int msic_irq_type(struct irq_data *data, unsigned 
int type)
 static int msic_gpio_to_irq(struct gpio_chip *chip, unsigned int offset)
 {
struct msic_gpio *mg = gpiochip_get_data(chip);
+
return mg->irq_base + offset;
 }
 
 static void msic_bus_lock(struct irq_data *data)
 {
struct msic_gpio *mg = irq_data_get_irq_chip_data(data);
+
mutex_lock(>buslock);
 }
 
-- 
2.28.0.rc0

[PATCH 1/4] gpio: gpio-msic.c: changed every 'unsigned' to 'unsigned int'

[Abanoub Sameh]

Changed 'unsigned' to 'unsigned int'.
This makes the code more uniform, and compliant with the kernel coding style.

Signed-off-by: Abanoub Sameh 
---
 drivers/gpio/gpio-msic.c | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/gpio/gpio-msic.c b/drivers/gpio/gpio-msic.c
index 7e3c96e4ab2c..ea5ff2c84a26 100644
--- a/drivers/gpio/gpio-msic.c
+++ b/drivers/gpio/gpio-msic.c
@@ -43,9 +43,9 @@ struct msic_gpio {
struct mutexbuslock;
struct gpio_chipchip;
int irq;
-   unsignedirq_base;
+   unsigned intirq_base;
unsigned long   trig_change_mask;
-   unsignedtrig_type;
+   unsigned inttrig_type;
 };
 
 /*
@@ -58,7 +58,7 @@ struct msic_gpio {
  * GPIO1HV0..GPIO1HV3: high voltage, bank 1, gpio_base + 20
  */
 
-static int msic_gpio_to_ireg(unsigned offset)
+static int msic_gpio_to_ireg(unsigned int offset)
 {
if (offset >= MSIC_NUM_GPIO)
return -EINVAL;
@@ -73,7 +73,7 @@ static int msic_gpio_to_ireg(unsigned offset)
return INTEL_MSIC_GPIO1HV0CTLI - offset + 20;
 }
 
-static int msic_gpio_to_oreg(unsigned offset)
+static int msic_gpio_to_oreg(unsigned int offset)
 {
if (offset >= MSIC_NUM_GPIO)
return -EINVAL;
@@ -88,7 +88,7 @@ static int msic_gpio_to_oreg(unsigned offset)
return INTEL_MSIC_GPIO1HV0CTLO - offset + 20;
 }
 
-static int msic_gpio_direction_input(struct gpio_chip *chip, unsigned offset)
+static int msic_gpio_direction_input(struct gpio_chip *chip, unsigned int 
offset)
 {
int reg;
 
@@ -100,10 +100,10 @@ static int msic_gpio_direction_input(struct gpio_chip 
*chip, unsigned offset)
 }
 
 static int msic_gpio_direction_output(struct gpio_chip *chip,
-   unsigned offset, int value)
+   unsigned int offset, int value)
 {
int reg;
-   unsigned mask;
+   unsigned int mask;
 
value = (!!value) | MSIC_GPIO_DIR_OUT;
mask = MSIC_GPIO_DIR_MASK | MSIC_GPIO_DOUT_MASK;
@@ -115,7 +115,7 @@ static int msic_gpio_direction_output(struct gpio_chip 
*chip,
return intel_msic_reg_update(reg, value, mask);
 }
 
-static int msic_gpio_get(struct gpio_chip *chip, unsigned offset)
+static int msic_gpio_get(struct gpio_chip *chip, unsigned int offset)
 {
u8 r;
int ret;
@@ -132,7 +132,7 @@ static int msic_gpio_get(struct gpio_chip *chip, unsigned 
offset)
return !!(r & MSIC_GPIO_DIN_MASK);
 }
 
-static void msic_gpio_set(struct gpio_chip *chip, unsigned offset, int value)
+static void msic_gpio_set(struct gpio_chip *chip, unsigned int offset, int 
value)
 {
int reg;
 
@@ -148,7 +148,7 @@ static void msic_gpio_set(struct gpio_chip *chip, unsigned 
offset, int value)
  * irq_desc->lock held. We can not access the scu bus here, so we
  * store the change and update in the bus_sync_unlock() function below
  */
-static int msic_irq_type(struct irq_data *data, unsigned type)
+static int msic_irq_type(struct irq_data *data, unsigned int type)
 {
struct msic_gpio *mg = irq_data_get_irq_chip_data(data);
u32 gpio = data->irq - mg->irq_base;
@@ -163,7 +163,7 @@ static int msic_irq_type(struct irq_data *data, unsigned 
type)
return 0;
 }
 
-static int msic_gpio_to_irq(struct gpio_chip *chip, unsigned offset)
+static int msic_gpio_to_irq(struct gpio_chip *chip, unsigned int offset)
 {
struct msic_gpio *mg = gpiochip_get_data(chip);
return mg->irq_base + offset;
-- 
2.28.0.rc0

[PATCH 2/2] gpio: gpio-pch.c: fixed coding style issue

[Abanoub Sameh]

Added a lined between a declaration and other statements according to the
kenel coding style.

Signed-off-by: Abanoub Sameh 
---
 drivers/gpio/gpio-pch.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpio/gpio-pch.c b/drivers/gpio/gpio-pch.c
index 71dde7ceb7af..039822978eaf 100644
--- a/drivers/gpio/gpio-pch.c
+++ b/drivers/gpio/gpio-pch.c
@@ -199,6 +199,7 @@ static void __maybe_unused pch_gpio_restore_reg_conf(struct 
pch_gpio *chip)
 static int pch_gpio_to_irq(struct gpio_chip *gpio, unsigned int offset)
 {
struct pch_gpio *chip = gpiochip_get_data(gpio);
+
return chip->irq_base + offset;
 }
 
-- 
2.28.0.rc0

[PATCH 4/4] gpio: gpio-msic.c: fixed a coding style error

[Abanoub Sameh]

Removed space before comma to fix coding style error.

Signed-off-by: Abanoub Sameh 
---
 drivers/gpio/gpio-msic.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpio/gpio-msic.c b/drivers/gpio/gpio-msic.c
index 84e00e0ab953..37664e7b3ddd 100644
--- a/drivers/gpio/gpio-msic.c
+++ b/drivers/gpio/gpio-msic.c
@@ -140,7 +140,7 @@ static void msic_gpio_set(struct gpio_chip *chip, unsigned 
int offset, int value
if (reg < 0)
return;
 
-   intel_msic_reg_update(reg, !!value , MSIC_GPIO_DOUT_MASK);
+   intel_msic_reg_update(reg, !!value, MSIC_GPIO_DOUT_MASK);
 }
 
 /*
-- 
2.28.0.rc0

[PATCH 2/2] gpio: gpio-sch.c: fixed coding style issue

[Abanoub Sameh]

Added a lined between a declaration and other statements according to the
kenel coding style.

Signed-off-by: Abanoub Sameh 
---
 drivers/gpio/gpio-sch.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpio/gpio-sch.c b/drivers/gpio/gpio-sch.c
index d7cade67717b..3a1b1adb08c6 100644
--- a/drivers/gpio/gpio-sch.c
+++ b/drivers/gpio/gpio-sch.c
@@ -89,6 +89,7 @@ static int sch_gpio_direction_in(struct gpio_chip *gc, 
unsigned int gpio_num)
 static int sch_gpio_get(struct gpio_chip *gc, unsigned int gpio_num)
 {
struct sch_gpio *sch = gpiochip_get_data(gc);
+
return sch_gpio_reg_get(sch, gpio_num, GLV);
 }
 
-- 
2.28.0.rc0