[PATCH v2 01/15] vfio/type1: Refactor vfio_iommu_type1_ioctl()
This patch refactors the vfio_iommu_type1_ioctl() to use switch instead of
if-else, and each cmd got a helper function.
Cc: Kevin Tian
CC: Jacob Pan
Cc: Alex Williamson
Cc: Eric Auger
Cc: Jean-Philippe Brucker
Cc: Joerg Roedel
Cc: Lu Baolu
Suggested-by: Christoph Hellwig
Signed-off-by: Liu Yi L
---
drivers/vfio/vfio_iommu_type1.c | 183 +++-
1 file changed, 105 insertions(+), 78 deletions(-)
diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index cc1d647..402aad3 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -2106,6 +2106,23 @@ static int vfio_domains_have_iommu_cache(struct
vfio_iommu *iommu)
return ret;
}
+static int vfio_iommu_type1_check_extension(struct vfio_iommu *iommu,
+ unsigned long arg)
+{
+ switch (arg) {
+ case VFIO_TYPE1_IOMMU:
+ case VFIO_TYPE1v2_IOMMU:
+ case VFIO_TYPE1_NESTING_IOMMU:
+ return 1;
+ case VFIO_DMA_CC_IOMMU:
+ if (!iommu)
+ return 0;
+ return vfio_domains_have_iommu_cache(iommu);
+ default:
+ return 0;
+ }
+}
+
static int vfio_iommu_iova_add_cap(struct vfio_info_cap *caps,
struct vfio_iommu_type1_info_cap_iova_range *cap_iovas,
size_t size)
@@ -2173,110 +2190,120 @@ static int vfio_iommu_iova_build_caps(struct
vfio_iommu *iommu,
return ret;
}
-static long vfio_iommu_type1_ioctl(void *iommu_data,
- unsigned int cmd, unsigned long arg)
+static int vfio_iommu_type1_get_info(struct vfio_iommu *iommu,
+unsigned long arg)
{
- struct vfio_iommu *iommu = iommu_data;
+ struct vfio_iommu_type1_info info;
unsigned long minsz;
+ struct vfio_info_cap caps = { .buf = NULL, .size = 0 };
+ unsigned long capsz;
+ int ret;
- if (cmd == VFIO_CHECK_EXTENSION) {
- switch (arg) {
- case VFIO_TYPE1_IOMMU:
- case VFIO_TYPE1v2_IOMMU:
- case VFIO_TYPE1_NESTING_IOMMU:
- return 1;
- case VFIO_DMA_CC_IOMMU:
- if (!iommu)
- return 0;
- return vfio_domains_have_iommu_cache(iommu);
- default:
- return 0;
- }
- } else if (cmd == VFIO_IOMMU_GET_INFO) {
- struct vfio_iommu_type1_info info;
- struct vfio_info_cap caps = { .buf = NULL, .size = 0 };
- unsigned long capsz;
- int ret;
-
- minsz = offsetofend(struct vfio_iommu_type1_info, iova_pgsizes);
+ minsz = offsetofend(struct vfio_iommu_type1_info, iova_pgsizes);
- /* For backward compatibility, cannot require this */
- capsz = offsetofend(struct vfio_iommu_type1_info, cap_offset);
+ /* For backward compatibility, cannot require this */
+ capsz = offsetofend(struct vfio_iommu_type1_info, cap_offset);
- if (copy_from_user(, (void __user *)arg, minsz))
- return -EFAULT;
+ if (copy_from_user(, (void __user *)arg, minsz))
+ return -EFAULT;
- if (info.argsz < minsz)
- return -EINVAL;
+ if (info.argsz < minsz)
+ return -EINVAL;
- if (info.argsz >= capsz) {
- minsz = capsz;
- info.cap_offset = 0; /* output, no-recopy necessary */
- }
+ if (info.argsz >= capsz) {
+ minsz = capsz;
+ info.cap_offset = 0; /* output, no-recopy necessary */
+ }
- info.flags = VFIO_IOMMU_INFO_PGSIZES;
+ info.flags = VFIO_IOMMU_INFO_PGSIZES;
- info.iova_pgsizes = vfio_pgsize_bitmap(iommu);
+ info.iova_pgsizes = vfio_pgsize_bitmap(iommu);
- ret = vfio_iommu_iova_build_caps(iommu, );
- if (ret)
- return ret;
+ ret = vfio_iommu_iova_build_caps(iommu, );
+ if (ret)
+ return ret;
- if (caps.size) {
- info.flags |= VFIO_IOMMU_INFO_CAPS;
+ if (caps.size) {
+ info.flags |= VFIO_IOMMU_INFO_CAPS;
- if (info.argsz < sizeof(info) + caps.size) {
- info.argsz = sizeof(info) + caps.size;
- } else {
- vfio_info_cap_shift(, sizeof(info));
- if (copy_to_user((void __user *)arg +
- sizeof(info), caps.buf,
- caps.size)) {
- kfree(caps.buf);
-
[PATCH v2 10/15] vfio/type1: Support binding guest page tables to PASID
Nesting translation allows two-levels/stages page tables, with 1st level
for guest translations (e.g. GVA->GPA), 2nd level for host translations
(e.g. GPA->HPA). This patch adds interface for binding guest page tables
to a PASID. This PASID must have been allocated to user space before the
binding request.
CC: Jacob Pan
Cc: Alex Williamson
Cc: Eric Auger
Cc: Jean-Philippe Brucker
Cc: Joerg Roedel
Cc: Lu Baolu
Signed-off-by: Jean-Philippe Brucker
Signed-off-by: Liu Yi L
Signed-off-by: Jacob Pan
---
v1 -> v2:
*) rename subject from "vfio/type1: Bind guest page tables to host"
*) remove VFIO_IOMMU_BIND, introduce VFIO_IOMMU_NESTING_OP to support bind/
unbind guet page table
*) replaced vfio_iommu_for_each_dev() with a group level loop since this
series enforces one group per container w/ nesting type as start.
*) rename vfio_bind/unbind_gpasid_fn() to vfio_dev_bind/unbind_gpasid_fn()
*) vfio_dev_unbind_gpasid() always successful
*) use vfio_mm->pasid_lock to avoid race between PASID free and page table
bind/unbind
Cc: Kevin Tian
drivers/vfio/vfio_iommu_type1.c | 191
drivers/vfio/vfio_pasid.c | 30 +++
include/linux/vfio.h| 20 +
include/uapi/linux/vfio.h | 30 +++
4 files changed, 271 insertions(+)
diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index a7b3a83..f1468a0 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -130,6 +130,33 @@ struct vfio_regions {
#define IS_DOMAIN_IN_CONTAINER(iommu) ((iommu->external_domain) || \
(!list_empty(>domain_list)))
+struct domain_capsule {
+ struct vfio_group *group;
+ struct iommu_domain *domain;
+ void *data;
+};
+
+/* iommu->lock must be held */
+static struct vfio_group *vfio_find_nesting_group(struct vfio_iommu *iommu)
+{
+ struct vfio_domain *d;
+ struct vfio_group *g, *group = NULL;
+
+ if (!iommu->nesting_info)
+ return NULL;
+
+ /* only support singleton container with nesting type */
+ list_for_each_entry(d, >domain_list, next) {
+ list_for_each_entry(g, >group_list, next) {
+ if (!group) {
+ group = g;
+ break;
+ }
+ }
+ }
+ return group;
+}
+
static int put_pfn(unsigned long pfn, int prot);
/*
@@ -2014,6 +2041,39 @@ static int vfio_iommu_resv_refresh(struct vfio_iommu
*iommu,
return ret;
}
+static int vfio_dev_bind_gpasid_fn(struct device *dev, void *data)
+{
+ struct domain_capsule *dc = (struct domain_capsule *)data;
+ struct iommu_gpasid_bind_data *bind_data =
+ (struct iommu_gpasid_bind_data *) dc->data;
+
+ return iommu_sva_bind_gpasid(dc->domain, dev, bind_data);
+}
+
+static int vfio_dev_unbind_gpasid_fn(struct device *dev, void *data)
+{
+ struct domain_capsule *dc = (struct domain_capsule *)data;
+ struct iommu_gpasid_unbind_data *unbind_data =
+ (struct iommu_gpasid_unbind_data *) dc->data;
+
+ iommu_sva_unbind_gpasid(dc->domain, dev, unbind_data);
+ return 0;
+}
+
+static void vfio_group_unbind_gpasid_fn(ioasid_t pasid, void *data)
+{
+ struct domain_capsule *dc = (struct domain_capsule *) data;
+ struct iommu_gpasid_unbind_data unbind_data;
+
+ unbind_data.argsz = sizeof(unbind_data);
+ unbind_data.flags = 0;
+ unbind_data.pasid = pasid;
+
+ dc->data = _data;
+ iommu_group_for_each_dev(dc->group->iommu_group,
+dc, vfio_dev_unbind_gpasid_fn);
+}
+
static void vfio_iommu_type1_detach_group(void *iommu_data,
struct iommu_group *iommu_group)
{
@@ -2055,6 +2115,21 @@ static void vfio_iommu_type1_detach_group(void
*iommu_data,
if (!group)
continue;
+ if (iommu->nesting_info && iommu->vmm &&
+ (iommu->nesting_info->features &
+ IOMMU_NESTING_FEAT_BIND_PGTBL)) {
+ struct domain_capsule dc = { .group = group,
+.domain = domain->domain,
+.data = NULL };
+
+ /*
+* Unbind page tables bound with system wide PASIDs
+* which are allocated to user space.
+*/
+ vfio_mm_for_each_pasid(iommu->vmm, ,
+ vfio_group_unbind_gpasid_fn);
+ }
+
vfio_iommu_detach_group(domain, group);
list_del(>next);
kfree(group);
@@ -2453,6 +2528,120 @@ static int vfio_iommu_type1_pasid_request(struct
vfio_iommu *iommu,
[PATCH v2 04/15] vfio: Add PASID allocation/free support
Shared Virtual Addressing (a.k.a Shared Virtual Memory) allows sharing
multiple process virtual address spaces with the device for simplified
programming model. PASID is used to tag an virtual address space in DMA
requests and to identify the related translation structure in IOMMU. When
a PASID-capable device is assigned to a VM, we want the same capability
of using PASID to tag guest process virtual address spaces to achieve
virtual SVA (vSVA).
PASID management for guest is vendor specific. Some vendors (e.g. Intel
VT-d) requires system-wide managed PASIDs cross all devices, regardless
of whether a device is used by host or assigned to guest. Other vendors
(e.g. ARM SMMU) may allow PASIDs managed per-device thus could be fully
delegated to the guest for assigned devices.
For system-wide managed PASIDs, this patch introduces a vfio module to
handle explicit PASID alloc/free requests from guest. Allocated PASIDs
are associated to a process (or, mm_struct) in IOASID core. A vfio_mm
object is introduced to track mm_struct. Multiple VFIO containers within
a process share the same vfio_mm object.
A quota mechanism is provided to prevent malicious user from exhausting
available PASIDs. Currently the quota is a global parameter applied to
all VFIO devices. In the future per-device quota might be supported too.
Cc: Kevin Tian
CC: Jacob Pan
Cc: Eric Auger
Cc: Jean-Philippe Brucker
Cc: Joerg Roedel
Cc: Lu Baolu
Suggested-by: Alex Williamson
Signed-off-by: Liu Yi L
---
v1 -> v2:
*) added in v2, split from the pasid alloc/free support of v1
drivers/vfio/Kconfig | 5 ++
drivers/vfio/Makefile | 1 +
drivers/vfio/vfio_pasid.c | 151 ++
include/linux/vfio.h | 28 +
4 files changed, 185 insertions(+)
create mode 100644 drivers/vfio/vfio_pasid.c
diff --git a/drivers/vfio/Kconfig b/drivers/vfio/Kconfig
index fd17db9..3d8a108 100644
--- a/drivers/vfio/Kconfig
+++ b/drivers/vfio/Kconfig
@@ -19,6 +19,11 @@ config VFIO_VIRQFD
depends on VFIO && EVENTFD
default n
+config VFIO_PASID
+ tristate
+ depends on IOASID && VFIO
+ default n
+
menuconfig VFIO
tristate "VFIO Non-Privileged userspace driver framework"
depends on IOMMU_API
diff --git a/drivers/vfio/Makefile b/drivers/vfio/Makefile
index de67c47..bb836a3 100644
--- a/drivers/vfio/Makefile
+++ b/drivers/vfio/Makefile
@@ -3,6 +3,7 @@ vfio_virqfd-y := virqfd.o
obj-$(CONFIG_VFIO) += vfio.o
obj-$(CONFIG_VFIO_VIRQFD) += vfio_virqfd.o
+obj-$(CONFIG_VFIO_PASID) += vfio_pasid.o
obj-$(CONFIG_VFIO_IOMMU_TYPE1) += vfio_iommu_type1.o
obj-$(CONFIG_VFIO_IOMMU_SPAPR_TCE) += vfio_iommu_spapr_tce.o
obj-$(CONFIG_VFIO_SPAPR_EEH) += vfio_spapr_eeh.o
diff --git a/drivers/vfio/vfio_pasid.c b/drivers/vfio/vfio_pasid.c
new file mode 100644
index 000..dd5b6d1
--- /dev/null
+++ b/drivers/vfio/vfio_pasid.c
@@ -0,0 +1,151 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2020 Intel Corporation.
+ * Author: Liu Yi L
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DRIVER_VERSION "0.1"
+#define DRIVER_AUTHOR "Liu Yi L "
+#define DRIVER_DESC "PASID management for VFIO bus drivers"
+
+#define VFIO_DEFAULT_PASID_QUOTA 1000
+static int pasid_quota = VFIO_DEFAULT_PASID_QUOTA;
+module_param_named(pasid_quota, pasid_quota, uint, 0444);
+MODULE_PARM_DESC(pasid_quota,
+" Set the quota for max number of PASIDs that an application
is allowed to request (default 1000)");
+
+struct vfio_mm_token {
+ unsigned long long val;
+};
+
+struct vfio_mm {
+ struct kref kref;
+ struct vfio_mm_tokentoken;
+ int ioasid_sid;
+ int pasid_quota;
+ struct list_headnext;
+};
+
+static struct vfio_pasid {
+ struct mutexvfio_mm_lock;
+ struct list_headvfio_mm_list;
+} vfio_pasid;
+
+/* called with vfio.vfio_mm_lock held */
+static void vfio_mm_release(struct kref *kref)
+{
+ struct vfio_mm *vmm = container_of(kref, struct vfio_mm, kref);
+
+ list_del(>next);
+ mutex_unlock(_pasid.vfio_mm_lock);
+ ioasid_free_set(vmm->ioasid_sid, true);
+ kfree(vmm);
+}
+
+void vfio_mm_put(struct vfio_mm *vmm)
+{
+ kref_put_mutex(>kref, vfio_mm_release, _pasid.vfio_mm_lock);
+}
+
+static void vfio_mm_get(struct vfio_mm *vmm)
+{
+ kref_get(>kref);
+}
+
+struct vfio_mm *vfio_mm_get_from_task(struct task_struct *task)
+{
+ struct mm_struct *mm = get_task_mm(task);
+ struct vfio_mm *vmm;
+ unsigned long long val = (unsigned long long) mm;
+ int ret;
+
+ mutex_lock(_pasid.vfio_mm_lock);
+ /* Search existing vfio_mm with current mm pointer */
+ list_for_each_entry(vmm, _pasid.vfio_mm_list, next) {
+ if (vmm->token.val == val) {
+ vfio_mm_get(vmm);
+ goto
[PATCH v2 11/15] vfio/type1: Allow invalidating first-level/stage IOMMU cache
This patch provides an interface allowing the userspace to invalidate
IOMMU cache for first-level page table. It is required when the first
level IOMMU page table is not managed by the host kernel in the nested
translation setup.
Cc: Kevin Tian
CC: Jacob Pan
Cc: Alex Williamson
Cc: Eric Auger
Cc: Jean-Philippe Brucker
Cc: Joerg Roedel
Cc: Lu Baolu
Signed-off-by: Liu Yi L
Signed-off-by: Eric Auger
Signed-off-by: Jacob Pan
---
v1 -> v2:
*) rename from "vfio/type1: Flush stage-1 IOMMU cache for nesting type"
*) rename vfio_cache_inv_fn() to vfio_dev_cache_invalidate_fn()
*) vfio_dev_cache_inv_fn() always successful
*) remove VFIO_IOMMU_CACHE_INVALIDATE, and reuse VFIO_IOMMU_NESTING_OP
drivers/vfio/vfio_iommu_type1.c | 59 +
include/uapi/linux/vfio.h | 3 +++
2 files changed, 62 insertions(+)
diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index f1468a0..c233c8e 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -2582,6 +2582,54 @@ static long vfio_iommu_handle_pgtbl_op(struct vfio_iommu
*iommu,
return ret;
}
+static int vfio_dev_cache_invalidate_fn(struct device *dev, void *data)
+{
+ struct domain_capsule *dc = (struct domain_capsule *)data;
+ struct iommu_cache_invalidate_info *cache_info =
+ (struct iommu_cache_invalidate_info *) dc->data;
+
+ iommu_cache_invalidate(dc->domain, dev, cache_info);
+ return 0;
+}
+
+static long vfio_iommu_invalidate_cache(struct vfio_iommu *iommu,
+ struct iommu_cache_invalidate_info *cache_info)
+{
+ struct domain_capsule dc = { .data = cache_info };
+ struct vfio_group *group;
+ struct vfio_domain *domain;
+ int ret = 0;
+ struct iommu_nesting_info *info;
+
+ mutex_lock(>lock);
+ /*
+* Cache invalidation is required for any nesting IOMMU,
+* so no need to check system-wide PASID support.
+*/
+ info = iommu->nesting_info;
+ if (!info || !(info->features & IOMMU_NESTING_FEAT_CACHE_INVLD)) {
+ ret = -ENOTSUPP;
+ goto out_unlock;
+ }
+
+ group = vfio_find_nesting_group(iommu);
+ if (!group) {
+ ret = -EINVAL;
+ goto out_unlock;
+ }
+
+ domain = list_first_entry(>domain_list,
+ struct vfio_domain, next);
+ dc.group = group;
+ dc.domain = domain->domain;
+ iommu_group_for_each_dev(group->iommu_group, ,
+vfio_dev_cache_invalidate_fn);
+
+out_unlock:
+ mutex_unlock(>lock);
+ return ret;
+}
+
static long vfio_iommu_type1_nesting_op(struct vfio_iommu *iommu,
unsigned long arg)
{
@@ -2607,6 +2655,9 @@ static long vfio_iommu_type1_nesting_op(struct vfio_iommu
*iommu,
case VFIO_IOMMU_NESTING_OP_UNBIND_PGTBL:
data_size = sizeof(struct iommu_gpasid_unbind_data);
break;
+ case VFIO_IOMMU_NESTING_OP_CACHE_INVLD:
+ data_size = sizeof(struct iommu_cache_invalidate_info);
+ break;
default:
return -EINVAL;
}
@@ -2633,6 +2684,14 @@ static long vfio_iommu_type1_nesting_op(struct
vfio_iommu *iommu,
case VFIO_IOMMU_NESTING_OP_UNBIND_PGTBL:
ret = vfio_iommu_handle_pgtbl_op(iommu, false, data);
break;
+ case VFIO_IOMMU_NESTING_OP_CACHE_INVLD:
+ {
+ struct iommu_cache_invalidate_info *cache_info =
+ (struct iommu_cache_invalidate_info *)data;
+
+ ret = vfio_iommu_invalidate_cache(iommu, cache_info);
+ break;
+ }
default:
ret = -EINVAL;
}
diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
index e4aa466..9a011d6 100644
--- a/include/uapi/linux/vfio.h
+++ b/include/uapi/linux/vfio.h
@@ -891,6 +891,8 @@ struct vfio_iommu_type1_pasid_request {
* +-+---+
* | UNBIND_PGTBL| struct iommu_gpasid_unbind_data |
* +-+---+
+ * | CACHE_INVLD | struct iommu_cache_invalidate_info |
+ * +-+---+
*
* returns: 0 on success, -errno on failure.
*/
@@ -903,6 +905,7 @@ struct vfio_iommu_type1_nesting_op {
#define VFIO_IOMMU_NESTING_OP_BIND_PGTBL (0)
#define VFIO_IOMMU_NESTING_OP_UNBIND_PGTBL (1)
+#define VFIO_IOMMU_NESTING_OP_CACHE_INVLD (2)
#define VFIO_IOMMU_NESTING_OP _IO(VFIO_TYPE, VFIO_BASE + 23)
--
2.7.4
Re: [PATCH RESEND v9 05/18] media: platform: Improve power on and power off flow
Hi Xia,
On Thu, Jun 04, 2020 at 05:05:40PM +0800, Xia Jiang wrote:
> Call pm_runtime_get_sync() before starting a frame and then
> pm_runtime_put() after completing it. This can save power for the time
> between processing two frames.
>
> Signed-off-by: Xia Jiang
> ---
> v9: use pm_runtime_put() to replace pm_runtime_put_sync()
> ---
> .../media/platform/mtk-jpeg/mtk_jpeg_core.c | 27 +--
> 1 file changed, 6 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
> b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
> index 12609ca46fd9..fb624385969e 100644
> --- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
> +++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
> @@ -710,23 +710,6 @@ static struct vb2_v4l2_buffer
> *mtk_jpeg_buf_remove(struct mtk_jpeg_ctx *ctx,
> return v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx);
> }
>
> -static int mtk_jpeg_start_streaming(struct vb2_queue *q, unsigned int count)
> -{
> - struct mtk_jpeg_ctx *ctx = vb2_get_drv_priv(q);
> - struct vb2_v4l2_buffer *vb;
> - int ret = 0;
> -
> - ret = pm_runtime_get_sync(ctx->jpeg->dev);
> - if (ret < 0)
> - goto err;
> -
> - return 0;
> -err:
> - while ((vb = mtk_jpeg_buf_remove(ctx, q->type)))
> - v4l2_m2m_buf_done(vb, VB2_BUF_STATE_QUEUED);
> - return ret;
> -}
> -
> static void mtk_jpeg_stop_streaming(struct vb2_queue *q)
> {
> struct mtk_jpeg_ctx *ctx = vb2_get_drv_priv(q);
> @@ -751,8 +734,6 @@ static void mtk_jpeg_stop_streaming(struct vb2_queue *q)
>
> while ((vb = mtk_jpeg_buf_remove(ctx, q->type)))
> v4l2_m2m_buf_done(vb, VB2_BUF_STATE_ERROR);
> -
> - pm_runtime_put_sync(ctx->jpeg->dev);
> }
>
> static const struct vb2_ops mtk_jpeg_qops = {
> @@ -761,7 +742,6 @@ static const struct vb2_ops mtk_jpeg_qops = {
> .buf_queue = mtk_jpeg_buf_queue,
> .wait_prepare = vb2_ops_wait_prepare,
> .wait_finish= vb2_ops_wait_finish,
> - .start_streaming= mtk_jpeg_start_streaming,
> .stop_streaming = mtk_jpeg_stop_streaming,
> };
>
> @@ -812,7 +792,7 @@ static void mtk_jpeg_device_run(void *priv)
> struct mtk_jpeg_src_buf *jpeg_src_buf;
> struct mtk_jpeg_bs bs;
> struct mtk_jpeg_fb fb;
> - int i;
> + int i, ret;
>
> src_buf = v4l2_m2m_next_src_buf(ctx->fh.m2m_ctx);
> dst_buf = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
> @@ -832,6 +812,10 @@ static void mtk_jpeg_device_run(void *priv)
> return;
> }
>
> + ret = pm_runtime_get_sync(jpeg->dev);
> + if (ret < 0)
> + goto dec_end;
> +
> mtk_jpeg_set_dec_src(ctx, _buf->vb2_buf, );
> if (mtk_jpeg_set_dec_dst(ctx, _src_buf->dec_param,
> _buf->vb2_buf, ))
> goto dec_end;
> @@ -957,6 +941,7 @@ static irqreturn_t mtk_jpeg_dec_irq(int irq, void *priv)
> v4l2_m2m_buf_done(src_buf, buf_state);
> v4l2_m2m_buf_done(dst_buf, buf_state);
> v4l2_m2m_job_finish(jpeg->m2m_dev, ctx->fh.m2m_ctx);
> + pm_runtime_put(ctx->jpeg->dev);
This patch itself is correct and feel free to add my
Reviewed-by: Tomasz Figa
However, it looks like there might be one more problem with this driver.
What happens if the hardware locks up? The driver doesn't seem to take
any measures to detect that and recover the system.
If you take a look at other drivers, e.g. the MTK FD driver, there is a
delayed work scheduled before starting the hardware and canceled in the
interrupt handler. If the delayed work is executed, it resets the
hardware and reports the failure to V4L2, so that the execution can
continue from next frames.
This should be fixed in a separate patch, could be outside of this
series.
Best regards,
Tomasz
Re: [PATCH V2] crypto: talitos - fix ECB and CBC algs ivsize
Le 11/06/2020 à 13:50, Su Kang Yin a écrit :
commit e1de42fdfc6a ("crypto: talitos - fix ECB algs ivsize")
wrongly modified CBC algs ivsize instead of ECB aggs ivsize.
This restore the CBC algs original ivsize of removes ECB's ones.
Fixes: e1de42fdfc6a ("crypto: talitos - fix ECB algs ivsize")
Signed-off-by: Su Kang Yin
Reviewed-by: Christophe Leroy
---
Patch for 4.9 upstream.
---
drivers/crypto/talitos.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index 8b383d3d21c2..059c2d4ad18f 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -2631,17 +2631,16 @@ static struct talitos_alg_template driver_algs[] = {
.cra_name = "ecb(aes)",
.cra_driver_name = "ecb-aes-talitos",
.cra_blocksize = AES_BLOCK_SIZE,
.cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER |
CRYPTO_ALG_ASYNC,
.cra_ablkcipher = {
.min_keysize = AES_MIN_KEY_SIZE,
.max_keysize = AES_MAX_KEY_SIZE,
- .ivsize = AES_BLOCK_SIZE,
}
},
.desc_hdr_template = DESC_HDR_TYPE_COMMON_NONSNOOP_NO_AFEU |
DESC_HDR_SEL0_AESU,
},
{ .type = CRYPTO_ALG_TYPE_ABLKCIPHER,
.alg.crypto = {
.cra_name = "cbc(aes)",
@@ -2665,16 +2664,17 @@ static struct talitos_alg_template driver_algs[] = {
.cra_name = "ctr(aes)",
.cra_driver_name = "ctr-aes-talitos",
.cra_blocksize = 1,
.cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER |
CRYPTO_ALG_ASYNC,
.cra_ablkcipher = {
.min_keysize = AES_MIN_KEY_SIZE,
.max_keysize = AES_MAX_KEY_SIZE,
+ .ivsize = AES_BLOCK_SIZE,
.setkey = ablkcipher_aes_setkey,
}
},
.desc_hdr_template = DESC_HDR_TYPE_AESU_CTR_NONSNOOP |
DESC_HDR_SEL0_AESU |
DESC_HDR_MODE0_AESU_CTR,
},
{ .type = CRYPTO_ALG_TYPE_ABLKCIPHER,
Re: [PATCH v7] ARM: DTS: Aspeed: Add YADRO Nicole BMC
On Wed, 10 Jun 2020 at 08:15, Alexander A. Filippov wrote: > > On Wed, Apr 29, 2020 at 02:37:11PM +0300, Alexander Filippov wrote: > > Nicole is an OpenPower machine with an Aspeed 2500 BMC SoC manufactured > > by YADRO. > > > > Signed-off-by: Alexander Filippov > > > > ping Reviewed-by: Joel Stanley This missed the merge window for 5.8. I will queue it up after -rc1 is released for 5.9. Cheers, Joel
Re: [PATCH v2 3/3] drm/bridge: Introduce LT9611 DSI to HDMI bridge
Hi Vinod, I love your patch! Yet something to improve: [auto build test ERROR on robh/for-next] [also build test ERROR on drm-intel/for-linux-next drm-tip/drm-tip linus/master v5.7 next-20200611] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system. BTW, we also suggest to use '--base' option to specify the base tree in git format-patch, please see https://stackoverflow.com/a/37406982] url: https://github.com/0day-ci/linux/commits/Vinod-Koul/Add-LT9611-DSI-to-HDMI-bridge/20200611-153921 base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next config: x86_64-allyesconfig (attached as .config) compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project bc2b70982be8f5250cd0082a7190f8b417bd4dfe) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # install x86_64 cross compiling tool for clang build # apt-get install binutils-x86-64-linux-gnu # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>, old ones prefixed by <<): >> make[5]: *** No rule to make target 'drivers/gpu/drm/bridge/lt9611.o', >> needed by 'drivers/gpu/drm/bridge/built-in.a'. make[5]: Target '__build' not remade because of errors. --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
Re: [PATCH v3 4/7] selftests/ftrace: Convert required interface checks into requires list
On 6/10/20 7:32 AM, Steven Rostedt wrote: On Wed, 10 Jun 2020 06:04:33 -0600 Shuah Khan wrote: Steve, what would you think? No worries. As far as kselftest tree is concrned, I can apply these after rc1 comes out with Tom's patch. Or I can give Ack and Steve can take these through tracing tree. All my patches have already made it to Linus's tree. Perhaps cherry-pick the commit needed from Linus's tree (it shouldn't break anything when Linus pulls it). Just let Linus know what you did, and everything should be fine. Good to know. I will get these in. thanks, -- Shuah
Re: [PATCH 1/2] sched/uclamp: Add a new sysctl to control RT default boost value
On Thu, 11 Jun 2020 at 12:24, Qais Yousef wrote: > > On 06/09/20 19:10, Vincent Guittot wrote: > > On Mon, 8 Jun 2020 at 14:31, Qais Yousef wrote: > > > > > > On 06/04/20 14:14, Vincent Guittot wrote: > > > > > > [...] > > > > > > > I have tried your patch and I don't see any difference compared to > > > > previous tests. Let me give you more details of my setup: > > > > I create 3 levels of cgroups and usually run the tests in the 4 levels > > > > (which includes root). The result above are for the root level > > > > > > > > But I see a difference at other levels: > > > > > > > >root level 1 level 2 > > > > level 3 > > > > > > > > /w patch uclamp disable 50097 46615 43806 > > > > 41078 > > > > tip uclamp enable 48706(-2.78%) 45583(-2.21%) 42851(-2.18%) > > > > 40313(-1.86%) > > > > /w patch uclamp enable 48882(-2.43%) 45774(-1.80%) 43108(-1.59%) > > > > 40667(-1.00%) > > > > > > > > Whereas tip with uclamp stays around 2% behind tip without uclamp, the > > > > diff of uclamp with your patch tends to decrease when we increase the > > > > number of level > > > > > > So I did try to dig more into this, but I think it's either not a good > > > reproducer or what we're observing here is uArch level latencies caused > > > by the > > > new code that seem to produce a bigger knock on effect than what they > > > really > > > are. > > > > > > First, CONFIG_FAIR_GROUP_SCHED is 'expensive', for some definition of > > > expensive.. > > > > yes, enabling CONFIG_FAIR_GROUP_SCHED adds an overhead > > > > > > > > *** uclamp disabled/fair group enabled *** > > > > > > # Executed 5 pipe operations between two threads > > > > > > Total time: 0.958 [sec] > > > > > > 19.177100 usecs/op > > > 52145 ops/sec > > > > > > *** uclamp disabled/fair group disabled *** > > > > > > # Executed 5 pipe operations between two threads > > > Total time: 0.808 [sec] > > > > > > 16.176200 usecs/op > > > 61819 ops/sec > > > > > > So there's a 15.6% drop in ops/sec when enabling this option. I think > > > it's good > > > to look at the absolutely number of usecs/op, Fair group adds around > > > 3 usecs/op. > > > > > > I dropped FAIR_GROUP_SCHED from my config to eliminate this overhead and > > > focus > > > on solely on uclamp overhead. > > > > Have you checked that both tests run at the root level ? > > I haven't actively moved tasks to cgroups. As I said that snippet was > particularly bad and I didn't see that level of nesting in every call. > > > Your function-graph log below shows several calls to > > update_cfs_group() which means that your trace below has not been made > > at root level but most probably at the 3rd level and I wonder if you > > used the same setup for running the benchmark above. This could > > explain such huge difference because I don't have such difference on > > my platform but more around 2% > > What promoted me to look at this is when you reported that even without uclamp > the nested cgroup showed a drop at each level. I was just trying to understand > how both affect the hot path in hope to understand the root cause of uclamp > overhead. > > > > > For uclamp disable/fair group enable/ function graph enable : 47994ops/sec > > For uclamp disable/fair group disable/ function graph enable : 49107ops/sec > > > > > > > > With uclamp enabled but no fair group I get > > > > > > *** uclamp enabled/fair group disabled *** > > > > > > # Executed 5 pipe operations between two threads > > > Total time: 0.856 [sec] > > > > > > 17.125740 usecs/op > > > 58391 ops/sec > > > > > > The drop is 5.5% in ops/sec. Or 1 usecs/op. > > > > > > I don't know what's the expectation here. 1 us could be a lot, but I don't > > > think we expect the new code to take more than few 100s of ns anyway. If > > > you > > > add potential caching effects, reaching 1 us wouldn't be that hard. > > > > > > Note that in my runs I chose performance governor and use `taskset 0x2` to > > > > You might want to set 2 CPUs in your cpumask instead of 1 in order to > > have 1 CPU for each thread > > I did try that but it didn't seem to change the number. I think the 2 tasks > interleave so running in 2 CPUs doesn't change the result. But to ease ftrace > capture, it's easier to monitor a single cpu. > > > > > > force running on a big core to make sure the runs are repeatable. > > > > I also use performance governor but don't pinned tasks because I use smp. > > Is your arm platform SMP? Yes, all my tests are done on the Arm64 octo core smp system > > > > > > > > > On Juno-r2 I managed to scrap most of the 1 us with the below patch. It > > > seems > > > there was weird branching behavior that affects the I$ in my case. It'd > > > be good > > > to try it out to see if it makes a difference for you.
Re: Barrier before pushing desc_ring tail: was [PATCH v2 2/3] printk: add lockless buffer
On Tue 2020-06-09 17:56:03, John Ogness wrote:
> On 2020-06-09, Petr Mladek wrote:
> >> --- /dev/null
> >> +++ b/kernel/printk/printk_ringbuffer.c
> >> +/*
> >> + * Advance the desc ring tail. This function advances the tail by one
> >> + * descriptor, thus invalidating the oldest descriptor. Before advancing
> >> + * the tail, the tail descriptor is made reusable and all data blocks up
> >> to
> >> + * and including the descriptor's data block are invalidated (i.e. the
> >> data
> >> + * ring tail is pushed past the data block of the descriptor being made
> >> + * reusable).
> >> + */
> >> +static bool desc_push_tail(struct printk_ringbuffer *rb,
> >> + unsigned long tail_id)
> >> +{
> >> + struct prb_desc_ring *desc_ring = >desc_ring;
> >> + enum desc_state d_state;
> >> + struct prb_desc desc;
> >> +
> >> + d_state = desc_read(desc_ring, tail_id, );
> >> +
> >> + switch (d_state) {
> >> + case desc_miss:
> >> + /*
> >> + * If the ID is exactly 1 wrap behind the expected, it is
> >> + * in the process of being reserved by another writer and
> >> + * must be considered reserved.
> >> + */
> >> + if (DESC_ID(atomic_long_read(_var)) ==
> >> + DESC_ID_PREV_WRAP(desc_ring, tail_id)) {
> >> + return false;
> >> + }
> >> +
> >> + /*
> >> + * The ID has changed. Another writer must have pushed the
> >> + * tail and recycled the descriptor already. Success is
> >> + * returned because the caller is only interested in the
> >> + * specified tail being pushed, which it was.
> >> + */
> >> + return true;
> >> + case desc_reserved:
> >> + return false;
> >> + case desc_committed:
> >> + desc_make_reusable(desc_ring, tail_id);
> >> + break;
> >> + case desc_reusable:
> >> + break;
> >> + }
> >> +
> >> + /*
> >> + * Data blocks must be invalidated before their associated
> >> + * descriptor can be made available for recycling. Invalidating
> >> + * them later is not possible because there is no way to trust
> >> + * data blocks once their associated descriptor is gone.
> >> + */
> >> +
> >> + if (!data_push_tail(rb, >text_data_ring, desc.text_blk_lpos.next))
> >> + return false;
> >> + if (!data_push_tail(rb, >dict_data_ring, desc.dict_blk_lpos.next))
> >> + return false;
> >> +
> >> + /*
> >> + * Check the next descriptor after @tail_id before pushing the tail
> >> + * to it because the tail must always be in a committed or reusable
> >> + * state. The implementation of prb_first_seq() relies on this.
> >> + *
> >> + * A successful read implies that the next descriptor is less than or
> >> + * equal to @head_id so there is no risk of pushing the tail past the
> >> + * head.
> >> + */
> >> + d_state = desc_read(desc_ring, DESC_ID(tail_id + 1),
> >> + ); /* LMM(desc_push_tail:A) */
> >> + if (d_state == desc_committed || d_state == desc_reusable) {
> >> + /*
> >> + * Any CPU that loads the new tail ID, must see that the
> >> + * descriptor at @tail_id is in the reusable state. See the
> >> + * read memory barrier part of desc_reserve:D for details.
> >> + */
> >> + atomic_long_cmpxchg_relaxed(_ring->tail_id, tail_id,
> >> + DESC_ID(tail_id + 1)); /* LMM(desc_push_tail:B) */
> >
> > I was quite confused by the above comment. Does it mean that we need
> > a barrier here? Or does it explain why the cmpxchg has its own
> > LMM marker?
>
> This LMM marker is referenced quite often, but since it is a relaxed
> cmpxchg(), its significance is not immediately clear. I was hoping to
> add some hints as to why it is significant. The comment that it is
> referring to is:
>
> /*
>* Guarantee the tail ID is read before validating the
>* recycled descriptor state. A read memory barrier is
>* sufficient for this. This pairs with data_push_tail:C.
>*
>* Memory barrier involvement:
>*
>* If desc_reserve:C reads from desc_push_tail:B, then
>* desc_reserve:F reads from desc_make_reusable:A.
>*
>* Relies on:
>*
>* MB from desc_make_reusable:A to desc_push_tail:B
>*matching
>* RMB from desc_reserve:C to desc_reserve:F
>*
>* Note: desc_make_reusable:A, desc_push_tail:B, and
>* data_push_tail:C can all be different CPUs. However,
>* the desc_push_tail:B CPU must have previously seen
>* data_push_tail:D and the data_push_tail:D CPU (which
>* performs the full memory barrier) must have
>* previously seen desc_make_reusable:A.
>*/
>
> English translation:
>
> In order to push the data tail, a CPU must first see that the associated
> descriptor is in the
Re: [PATCH RESEND v9 06/18] media: platform: Delete the resetting hardware flow in the system PM ops
Hi Xia, On Thu, Jun 04, 2020 at 05:05:41PM +0800, Xia Jiang wrote: > Delete the resetting hardware flow in suspend and resume function > because that resetting operation will be done in device_run(). > > Signed-off-by: Xia Jiang > --- > v9: new patch > --- > drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c | 2 -- > 1 file changed, 2 deletions(-) > Reviewed-by: Tomasz Figa Best regards, Tomasz
Re: [PATCH RESEND v9 04/18] media: platform: Change the fixed device node number to unfixed value
Hi Xia, On Thu, Jun 04, 2020 at 05:05:39PM +0800, Xia Jiang wrote: > The driver can be instantiated multiple times, e.g. for a decoder and > an encoder. Moreover, other drivers could coexist on the same system. > This makes the static video node number assignment pointless, so switch > to automatic assignment instead. > > Signed-off-by: Xia Jiang > --- > v9: change the commit message > --- > drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > Reviewed-by: Tomasz Figa Best regards, Tomasz
[RFC PATCH][DO NOT COMMIT] media: dvb_frontend: Support concurrent DVB-T/DVB-T2 scan
Some demodulators (e.g. si2168) are able to scan for DVB-T and DVB-T2
signals concurrently. Use SYS_DVBT_AUTO for this purpose.
---
This is a Request For Comments from media maintainers and users :-)
One issue: suppose DVB Project publishes DVB-T3 in a few years.
Today's demods might handle T/T2, but they won't handle T3, while users
may expect SYS_DVBT_AUTO to mean "all DVB-T standards".
Therefore, perhaps the delsys name should be explicit,
like SYS_DVBT_DVBT2 or SYS_DVBT_1_2.
Then if/when DVB_T3 appears, we can add SYS_DVBT_1_2_3 ???
Or maybe use the FE_CAN_2G_MODULATION and hypothetical FE_CAN_3G_MODULATION
Or maybe, with several standards having a v2 and possibly v3 in the future,
delivery system might move to a bitmask approach? (API issues though)
Reference to related implementation:
https://patchwork.kernel.org/patch/10744999/
---
drivers/media/dvb-frontends/si2168.c | 2 +-
include/uapi/linux/dvb/frontend.h| 3 +++
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/media/dvb-frontends/si2168.c
b/drivers/media/dvb-frontends/si2168.c
index 14b93a7d3358..8578b8917955 100644
--- a/drivers/media/dvb-frontends/si2168.c
+++ b/drivers/media/dvb-frontends/si2168.c
@@ -624,7 +624,7 @@ static int si2168_deselect(struct i2c_mux_core *muxc, u32
chan)
}
static const struct dvb_frontend_ops si2168_ops = {
- .delsys = {SYS_DVBT, SYS_DVBT2, SYS_DVBC_ANNEX_A},
+ .delsys = {SYS_DVBT, SYS_DVBT2, SYS_DVBT_AUTO, SYS_DVBC_ANNEX_A},
.info = {
.name = "Silicon Labs Si2168",
.frequency_min_hz = 48 * MHz,
diff --git a/include/uapi/linux/dvb/frontend.h
b/include/uapi/linux/dvb/frontend.h
index 4f9b4551c534..3a6348748041 100644
--- a/include/uapi/linux/dvb/frontend.h
+++ b/include/uapi/linux/dvb/frontend.h
@@ -600,6 +600,8 @@ enum fe_rolloff {
* Terrestrial TV: DVB-T
* @SYS_DVBT2:
* Terrestrial TV: DVB-T2
+ * @SYS_DVBT_AUTO:
+ * Terrestrial TV: Autodetect DVB-T gen
* @SYS_ISDBT:
* Terrestrial TV: ISDB-T
* @SYS_ATSC:
@@ -645,6 +647,7 @@ enum fe_delivery_system {
SYS_DVBT2,
SYS_TURBO,
SYS_DVBC_ANNEX_C,
+ SYS_DVBT_AUTO,
};
/* backward compatibility definitions for delivery systems */
--
2.17.1
Re: [PATCH] .clang-format: update column limit
On Thu, Jun 11, 2020 at 12:36 PM Joe Perches wrote: > > Exactly. So don't set a new hard limit of 100. > > This would _always_ wrap lines to 100 columns when > 80 columns is still preferred. Why is 80 "still preferred" to begin with? The patch you sent for `coding-style.rst` was picked up by Linus, yes, but the wording seems too strong still, considering it is for newcomers. The point is that 80 *isn't* a limit, so I don't see why it is mentioned, much less "preferred". Rather, I would have worded it like [*]. What do you think? > Imagine using a 100 column limit where a statement still > fits on 2 lines. Now imagine the same statement wrapped > at 80 columns still fitting on 2 lines. > > Which would you prefer and why? The former. While sometimes it may be more aesthetically pleasing to have 2 lines of similar lengths rather than a long one and a short one, having a deterministic approach allows us to use automatic formatters. Which in turn makes code more regular since breaks are always done the same way (modulo heuristic differences between clang-format versions etc.). In other words, I prefer automatic breaks vs. discussing every break :-) Cheers, Miguel [*] (please excuse any word-wrap) >From 3b3cad415b56498534fadf732f2762f4dbe108eb Mon Sep 17 00:00:00 2001 From: Miguel Ojeda Date: Thu, 11 Jun 2020 13:16:46 +0200 Subject: [PATCH] coding-style: don't mention line length hard limits, add tips Signed-off-by: Miguel Ojeda --- Documentation/process/coding-style.rst | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/Documentation/process/coding-style.rst b/Documentation/process/coding-style.rst index 17a8e584f15f..309d3ae17e6c 100644 --- a/Documentation/process/coding-style.rst +++ b/Documentation/process/coding-style.rst @@ -84,11 +84,13 @@ Get a decent editor and don't leave whitespace at the end of lines. Coding style is all about readability and maintainability using commonly available tools. -The preferred limit on the length of a single line is 80 columns. +Avoid lines that are too long and use reasonable line lengths. There is no +hard limit: break lines where it makes the most sense, somewhere around +the 80-120 columns. Complex statements should be broken into sensible chunks; +identifiers should not be unreasonably verbose. Follow nearby conventions. -Statements longer than 80 columns should be broken into sensible chunks, -unless exceeding 80 columns significantly increases readability and does -not hide information. +A good test is using `clang-format`: if the formatter is unable to split +the lines wisely, then the code likely needs rearrangement. Descendants are always substantially shorter than the parent and are are placed substantially to the right. A very commonly used style -- 2.27.0
Re: [PATCH v3 47/75] x86/sev-es: Add Runtime #VC Exception Handler
On Sat, May 23, 2020 at 09:59:24AM +0200, Borislav Petkov wrote: > On Tue, Apr 28, 2020 at 05:16:57PM +0200, Joerg Roedel wrote: > > + struct ghcb backup_ghcb; > > I could use some text explaining what those backups are for? I added another comment above that line to better explain why it is needed. Joerg
[PATCH V2] crypto: talitos - fix ECB and CBC algs ivsize
commit e1de42fdfc6a ("crypto: talitos - fix ECB algs ivsize")
wrongly modified CBC algs ivsize instead of ECB aggs ivsize.
This restore the CBC algs original ivsize of removes ECB's ones.
Fixes: e1de42fdfc6a ("crypto: talitos - fix ECB algs ivsize")
Signed-off-by: Su Kang Yin
---
Patch for 4.9 upstream.
---
drivers/crypto/talitos.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index 8b383d3d21c2..059c2d4ad18f 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -2631,17 +2631,16 @@ static struct talitos_alg_template driver_algs[] = {
.cra_name = "ecb(aes)",
.cra_driver_name = "ecb-aes-talitos",
.cra_blocksize = AES_BLOCK_SIZE,
.cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER |
CRYPTO_ALG_ASYNC,
.cra_ablkcipher = {
.min_keysize = AES_MIN_KEY_SIZE,
.max_keysize = AES_MAX_KEY_SIZE,
- .ivsize = AES_BLOCK_SIZE,
}
},
.desc_hdr_template = DESC_HDR_TYPE_COMMON_NONSNOOP_NO_AFEU |
DESC_HDR_SEL0_AESU,
},
{ .type = CRYPTO_ALG_TYPE_ABLKCIPHER,
.alg.crypto = {
.cra_name = "cbc(aes)",
@@ -2665,16 +2664,17 @@ static struct talitos_alg_template driver_algs[] = {
.cra_name = "ctr(aes)",
.cra_driver_name = "ctr-aes-talitos",
.cra_blocksize = 1,
.cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER |
CRYPTO_ALG_ASYNC,
.cra_ablkcipher = {
.min_keysize = AES_MIN_KEY_SIZE,
.max_keysize = AES_MAX_KEY_SIZE,
+ .ivsize = AES_BLOCK_SIZE,
.setkey = ablkcipher_aes_setkey,
}
},
.desc_hdr_template = DESC_HDR_TYPE_AESU_CTR_NONSNOOP |
DESC_HDR_SEL0_AESU |
DESC_HDR_MODE0_AESU_CTR,
},
{ .type = CRYPTO_ALG_TYPE_ABLKCIPHER,
--
2.21.0
Re: [PATCH v3 5/7] venus: Add debugfs interface to set firmware log level
Hi Greg,
Thanks for the comments!
On 6/9/20 2:12 PM, Greg Kroah-Hartman wrote:
> On Tue, Jun 09, 2020 at 01:46:02PM +0300, Stanimir Varbanov wrote:
>> +int venus_dbgfs_init(struct venus_core *core)
>> +{
>> +core->root = debugfs_create_dir("venus", NULL);
>> +if (IS_ERR(core->root))
>> +return IS_ERR(core->root);
>
> You really do not care, and obviously did not test this on a system with
> CONFIG_DEBUG_FS disabled :)
Probably not :(
>
> Just make the call to debugfs, and move on, feed it into other debugfs
> calls, all is good.
>
> This function should just return 'void', no need to care about this at
> all.
>
>> +ret = venus_sys_set_debug(hdev, venus_fw_debug);
>> +if (ret)
>> +dev_warn(dev, "setting fw debug msg ON failed (%d)\n", ret);
>
> Why do you care about this "error"?
I don't care so much, that's why it is dev_warn. But if I enable debug
messages from the firmware and I don't see them this warn will give me
an idea why.
--
regards,
Stan
[v2 PATCH] iov_iter: Move unnecessary inclusion of crypto/hash.h
The header file linux/uio.h includes crypto/hash.h which pulls in
most of the Crypto API. Since linux/uio.h is used throughout the
kernel this means that every tiny bit of change to the Crypto API
causes the entire kernel to get rebuilt.
This patch fixes this by moving it into lib/iov_iter.c instead
where it is actually used.
This patch also fixes the ifdef to use CRYPTO_HASH instead of just
CRYPTO which does not guarantee the existence of ahash.
Unfortunately a number of drivers were relying on linux/uio.h to
provide access to linux/slab.h. This patch adds inclusions of
linux/slab.h as detected by build failures.
Signed-off-by: Herbert Xu
diff --git a/drivers/dma/sf-pdma/sf-pdma.c b/drivers/dma/sf-pdma/sf-pdma.c
index 6d0bec947636..e237d6038407 100644
--- a/drivers/dma/sf-pdma/sf-pdma.c
+++ b/drivers/dma/sf-pdma/sf-pdma.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include "sf-pdma.h"
diff --git a/drivers/misc/uacce/uacce.c b/drivers/misc/uacce/uacce.c
index d39307f060bd..5a984df0e95e 100644
--- a/drivers/misc/uacce/uacce.c
+++ b/drivers/misc/uacce/uacce.c
@@ -4,6 +4,7 @@
#include
#include
#include
+#include
#include
static struct class *uacce_class;
diff --git a/drivers/soc/qcom/pdr_interface.c b/drivers/soc/qcom/pdr_interface.c
index 17ad3b8698e1..aa2e3fe19c0f 100644
--- a/drivers/soc/qcom/pdr_interface.c
+++ b/drivers/soc/qcom/pdr_interface.c
@@ -5,6 +5,7 @@
#include
#include
+#include
#include
#include
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index 320d1062068d..d1e03b8cb6bb 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -3,6 +3,7 @@
* Copyright (C) 2007 Oracle. All rights reserved.
*/
+#include
#include
#include
#include
diff --git a/include/linux/uio.h b/include/linux/uio.h
index 9576fd8158d7..3835a8a8e9ea 100644
--- a/include/linux/uio.h
+++ b/include/linux/uio.h
@@ -7,7 +7,6 @@
#include
#include
-#include
#include
struct page;
diff --git a/lib/iov_iter.c b/lib/iov_iter.c
index 51595bf3af85..2830daf46c73 100644
--- a/lib/iov_iter.c
+++ b/lib/iov_iter.c
@@ -1,4 +1,5 @@
// SPDX-License-Identifier: GPL-2.0-only
+#include
#include
#include
#include
@@ -1566,7 +1567,7 @@ EXPORT_SYMBOL(csum_and_copy_to_iter);
size_t hash_and_copy_to_iter(const void *addr, size_t bytes, void *hashp,
struct iov_iter *i)
{
-#ifdef CONFIG_CRYPTO
+#ifdef CONFIG_CRYPTO_HASH
struct ahash_request *hash = hashp;
struct scatterlist sg;
size_t copied;
diff --git a/drivers/mtd/mtdpstore.c b/drivers/mtd/mtdpstore.c
index a4fe6060b960..a3ae8778f6a9 100644
--- a/drivers/mtd/mtdpstore.c
+++ b/drivers/mtd/mtdpstore.c
@@ -7,6 +7,7 @@
#include
#include
#include
+#include
static struct mtdpstore_context {
int index;
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v3 47/75] x86/sev-es: Add Runtime #VC Exception Handler
On Sat, May 23, 2020 at 09:59:24AM +0200, Borislav Petkov wrote: > On Tue, Apr 28, 2020 at 05:16:57PM +0200, Joerg Roedel wrote: > > + /* > > +* Mark the per-cpu GHCBs as in-use to detect nested #VC exceptions. > > +* There is no need for it to be atomic, because nothing is written to > > +* the GHCB between the read and the write of ghcb_active. So it is safe > > +* to use it when a nested #VC exception happens before the write. > > +*/ > > Looks liks that is that text... support for nested #VC exceptions. > I'm sure this has come up already but why do we even want to support > nested #VCs? IOW, can we do without them first or are they absolutely > necessary? > > I'm guessing VC exceptions inside the VC handler but what are the > sensible use cases? The most important use-case is #VC->NMI->#VC. When an NMI hits while the #VC handler uses the GHCB and the NMI handler causes another #VC, then the contents of the GHCB needs to be backed up, so that it doesn't destroy the GHCB contents of the first #VC handling path. Regards, Joerg
[PATCH V5 8/9] pinctrl: imx8qm: Support building as module
Change configuration to "tristate", add module device table,
author, description and license to support building i.MX8QM
pinctrl driver as module.
Signed-off-by: Anson Huang
---
Changes since V4:
- remove unnecessary change of replacing arch_initcall() with
module_platform_driver();
- add module author and description;
- add more details to commit message.
---
drivers/pinctrl/freescale/Kconfig | 2 +-
drivers/pinctrl/freescale/pinctrl-imx8qm.c | 5 +
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/pinctrl/freescale/Kconfig
b/drivers/pinctrl/freescale/Kconfig
index 412d581..de8d571 100644
--- a/drivers/pinctrl/freescale/Kconfig
+++ b/drivers/pinctrl/freescale/Kconfig
@@ -153,7 +153,7 @@ config PINCTRL_IMX8MQ
Say Y here to enable the imx8mq pinctrl driver
config PINCTRL_IMX8QM
- bool "IMX8QM pinctrl driver"
+ tristate "IMX8QM pinctrl driver"
depends on IMX_SCU && ARCH_MXC && ARM64
select PINCTRL_IMX_SCU
help
diff --git a/drivers/pinctrl/freescale/pinctrl-imx8qm.c
b/drivers/pinctrl/freescale/pinctrl-imx8qm.c
index 9ba3249..8f46b940 100644
--- a/drivers/pinctrl/freescale/pinctrl-imx8qm.c
+++ b/drivers/pinctrl/freescale/pinctrl-imx8qm.c
@@ -301,6 +301,7 @@ static const struct of_device_id imx8qm_pinctrl_of_match[]
= {
{ .compatible = "fsl,imx8qm-iomuxc", },
{ /* sentinel */ }
};
+MODULE_DEVICE_TABLE(of, imx8qm_pinctrl_of_match);
static int imx8qm_pinctrl_probe(struct platform_device *pdev)
{
@@ -327,3 +328,7 @@ static int __init imx8qm_pinctrl_init(void)
return platform_driver_register(_pinctrl_driver);
}
arch_initcall(imx8qm_pinctrl_init);
+
+MODULE_AUTHOR("Aisheng Dong ");
+MODULE_DESCRIPTION("NXP i.MX8QM pinctrl driver");
+MODULE_LICENSE("GPL v2");
--
2.7.4
[PATCH V5 5/9] pinctrl: imx8mq: Support building as module
Change configuration to "tristate", add module device table,
author, description and license to support building i.MX8MQ
pinctrl driver as module.
Signed-off-by: Anson Huang
---
Changes since V4:
- remove unnecessary change of replacing arch_initcall() with
module_platform_driver();
- add module author and description;
- add more details to commit message.
---
drivers/pinctrl/freescale/Kconfig | 2 +-
drivers/pinctrl/freescale/pinctrl-imx8mq.c | 6 ++
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/pinctrl/freescale/Kconfig
b/drivers/pinctrl/freescale/Kconfig
index fe3e49c..968c1e9 100644
--- a/drivers/pinctrl/freescale/Kconfig
+++ b/drivers/pinctrl/freescale/Kconfig
@@ -146,7 +146,7 @@ config PINCTRL_IMX8MP
Say Y here to enable the imx8mp pinctrl driver
config PINCTRL_IMX8MQ
- bool "IMX8MQ pinctrl driver"
+ tristate "IMX8MQ pinctrl driver"
depends on ARCH_MXC
select PINCTRL_IMX
help
diff --git a/drivers/pinctrl/freescale/pinctrl-imx8mq.c
b/drivers/pinctrl/freescale/pinctrl-imx8mq.c
index 50aa1c0..ae3ea5b 100644
--- a/drivers/pinctrl/freescale/pinctrl-imx8mq.c
+++ b/drivers/pinctrl/freescale/pinctrl-imx8mq.c
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -329,6 +330,7 @@ static const struct of_device_id imx8mq_pinctrl_of_match[]
= {
{ .compatible = "fsl,imx8mq-iomuxc", .data = _pinctrl_info, },
{ /* sentinel */ }
};
+MODULE_DEVICE_TABLE(of, imx8mq_pinctrl_of_match);
static int imx8mq_pinctrl_probe(struct platform_device *pdev)
{
@@ -350,3 +352,7 @@ static int __init imx8mq_pinctrl_init(void)
return platform_driver_register(_pinctrl_driver);
}
arch_initcall(imx8mq_pinctrl_init);
+
+MODULE_AUTHOR("Lucas Stach ");
+MODULE_DESCRIPTION("NXP i.MX8MQ pinctrl driver");
+MODULE_LICENSE("GPL v2");
--
2.7.4
[PATCH V5 3/9] pinctrl: imx8mm: Support building as module
Change configuration to "tristate", add module device table,
author, description and license to support building i.MX8MM
pinctrl driver as module.
Signed-off-by: Anson Huang
---
Changes since V4:
- remove unnecessary change of replacing arch_initcall() with
module_platform_driver();
- add module author and description;
- add more details to commit message.
---
drivers/pinctrl/freescale/Kconfig | 2 +-
drivers/pinctrl/freescale/pinctrl-imx8mm.c | 6 ++
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/pinctrl/freescale/Kconfig
b/drivers/pinctrl/freescale/Kconfig
index e281c3f..556adc3 100644
--- a/drivers/pinctrl/freescale/Kconfig
+++ b/drivers/pinctrl/freescale/Kconfig
@@ -125,7 +125,7 @@ config PINCTRL_IMX7ULP
Say Y here to enable the imx7ulp pinctrl driver
config PINCTRL_IMX8MM
- bool "IMX8MM pinctrl driver"
+ tristate "IMX8MM pinctrl driver"
depends on ARCH_MXC
select PINCTRL_IMX
help
diff --git a/drivers/pinctrl/freescale/pinctrl-imx8mm.c
b/drivers/pinctrl/freescale/pinctrl-imx8mm.c
index 6d1038a..31c5d88 100644
--- a/drivers/pinctrl/freescale/pinctrl-imx8mm.c
+++ b/drivers/pinctrl/freescale/pinctrl-imx8mm.c
@@ -5,6 +5,7 @@
#include
#include
+#include
#include
#include
#include
@@ -326,6 +327,7 @@ static const struct of_device_id imx8mm_pinctrl_of_match[]
= {
{ .compatible = "fsl,imx8mm-iomuxc", .data = _pinctrl_info, },
{ /* sentinel */ }
};
+MODULE_DEVICE_TABLE(of, imx8mm_pinctrl_of_match);
static int imx8mm_pinctrl_probe(struct platform_device *pdev)
{
@@ -346,3 +348,7 @@ static int __init imx8mm_pinctrl_init(void)
return platform_driver_register(_pinctrl_driver);
}
arch_initcall(imx8mm_pinctrl_init);
+
+MODULE_AUTHOR("Bai Ping ");
+MODULE_DESCRIPTION("NXP i.MX8MM pinctrl driver");
+MODULE_LICENSE("GPL v2");
--
2.7.4
[PATCH V5 9/9] pinctrl: imx8dxl: Support building as module
Change configuration to "tristate", add module device table,
author, description and license to support building i.MX8DXL
pinctrl driver as module.
Signed-off-by: Anson Huang
---
Changes since V4:
- remove unnecessary change of replacing arch_initcall() with
module_platform_driver();
- add module author and description;
- add more details to commit message.
---
drivers/pinctrl/freescale/Kconfig | 2 +-
drivers/pinctrl/freescale/pinctrl-imx8dxl.c | 5 +
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/pinctrl/freescale/Kconfig
b/drivers/pinctrl/freescale/Kconfig
index de8d571..922ae4b 100644
--- a/drivers/pinctrl/freescale/Kconfig
+++ b/drivers/pinctrl/freescale/Kconfig
@@ -167,7 +167,7 @@ config PINCTRL_IMX8QXP
Say Y here to enable the imx8qxp pinctrl driver
config PINCTRL_IMX8DXL
- bool "IMX8DXL pinctrl driver"
+ tristate "IMX8DXL pinctrl driver"
depends on IMX_SCU && ARCH_MXC && ARM64
select PINCTRL_IMX_SCU
help
diff --git a/drivers/pinctrl/freescale/pinctrl-imx8dxl.c
b/drivers/pinctrl/freescale/pinctrl-imx8dxl.c
index be3b09e..d3020c0 100644
--- a/drivers/pinctrl/freescale/pinctrl-imx8dxl.c
+++ b/drivers/pinctrl/freescale/pinctrl-imx8dxl.c
@@ -168,6 +168,7 @@ static const struct of_device_id imx8dxl_pinctrl_of_match[]
= {
{ .compatible = "fsl,imx8dxl-iomuxc", },
{ /* sentinel */ }
};
+MODULE_DEVICE_TABLE(of, imx8dxl_pinctrl_of_match);
static int imx8dxl_pinctrl_probe(struct platform_device *pdev)
{
@@ -194,3 +195,7 @@ static int __init imx8dxl_pinctrl_init(void)
return platform_driver_register(_pinctrl_driver);
}
arch_initcall(imx8dxl_pinctrl_init);
+
+MODULE_AUTHOR("Anson Huang ");
+MODULE_DESCRIPTION("NXP i.MX8DXL pinctrl driver");
+MODULE_LICENSE("GPL v2");
--
2.7.4
[PATCH V5 2/9] pinctrl: imx: Support building i.MX pinctrl driver as module
Export necessary functions to support building i.MX common pinctrl
driver and its user to be built as module.
i.MX common pinctrl driver should depend on CONFIG_OF to make sure
no build error when i.MX common pinctrl driver is enabled for difference
architectures without CONFIG_OF.
Also, module author, description and license should be added.
Signed-off-by: Anson Huang
---
Changes since V4:
- add module author and description.
---
drivers/pinctrl/freescale/Kconfig | 3 ++-
drivers/pinctrl/freescale/pinctrl-imx.c | 7 +++
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/pinctrl/freescale/Kconfig
b/drivers/pinctrl/freescale/Kconfig
index a3a30f1d..e281c3f 100644
--- a/drivers/pinctrl/freescale/Kconfig
+++ b/drivers/pinctrl/freescale/Kconfig
@@ -1,6 +1,7 @@
# SPDX-License-Identifier: GPL-2.0-only
config PINCTRL_IMX
- bool
+ tristate "IMX pinctrl driver"
+ depends on OF
select GENERIC_PINCTRL_GROUPS
select GENERIC_PINMUX_FUNCTIONS
select GENERIC_PINCONF
diff --git a/drivers/pinctrl/freescale/pinctrl-imx.c
b/drivers/pinctrl/freescale/pinctrl-imx.c
index c1faae1..28be1d6 100644
--- a/drivers/pinctrl/freescale/pinctrl-imx.c
+++ b/drivers/pinctrl/freescale/pinctrl-imx.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -878,6 +879,7 @@ int imx_pinctrl_probe(struct platform_device *pdev,
return pinctrl_enable(ipctl->pctl);
}
+EXPORT_SYMBOL_GPL(imx_pinctrl_probe);
static int __maybe_unused imx_pinctrl_suspend(struct device *dev)
{
@@ -897,3 +899,8 @@ const struct dev_pm_ops imx_pinctrl_pm_ops = {
SET_LATE_SYSTEM_SLEEP_PM_OPS(imx_pinctrl_suspend,
imx_pinctrl_resume)
};
+EXPORT_SYMBOL_GPL(imx_pinctrl_pm_ops);
+
+MODULE_AUTHOR("Linus Walleij ");
+MODULE_DESCRIPTION("NXP i.MX common pinctrl driver");
+MODULE_LICENSE("GPL v2");
--
2.7.4
[PATCH V5 6/9] pinctrl: imx8mp: Support building as module
Change configuration to "tristate", add module device table,
author, description and license to support building i.MX8MP
pinctrl driver as module.
Signed-off-by: Anson Huang
---
Changes since V4:
- remove unnecessary change of replacing arch_initcall() with
module_platform_driver();
- add module author and description;
- add more details to commit message.
---
drivers/pinctrl/freescale/Kconfig | 2 +-
drivers/pinctrl/freescale/pinctrl-imx8mp.c | 6 ++
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/pinctrl/freescale/Kconfig
b/drivers/pinctrl/freescale/Kconfig
index 968c1e9..af28f14 100644
--- a/drivers/pinctrl/freescale/Kconfig
+++ b/drivers/pinctrl/freescale/Kconfig
@@ -139,7 +139,7 @@ config PINCTRL_IMX8MN
Say Y here to enable the imx8mn pinctrl driver
config PINCTRL_IMX8MP
- bool "IMX8MP pinctrl driver"
+ tristate "IMX8MP pinctrl driver"
depends on ARCH_MXC
select PINCTRL_IMX
help
diff --git a/drivers/pinctrl/freescale/pinctrl-imx8mp.c
b/drivers/pinctrl/freescale/pinctrl-imx8mp.c
index e3f644c..bf4bbb5 100644
--- a/drivers/pinctrl/freescale/pinctrl-imx8mp.c
+++ b/drivers/pinctrl/freescale/pinctrl-imx8mp.c
@@ -5,6 +5,7 @@
#include
#include
+#include
#include
#include
#include
@@ -324,6 +325,7 @@ static const struct of_device_id imx8mp_pinctrl_of_match[]
= {
{ .compatible = "fsl,imx8mp-iomuxc", .data = _pinctrl_info, },
{ /* sentinel */ }
};
+MODULE_DEVICE_TABLE(of, imx8mp_pinctrl_of_match);
static int imx8mp_pinctrl_probe(struct platform_device *pdev)
{
@@ -343,3 +345,7 @@ static int __init imx8mp_pinctrl_init(void)
return platform_driver_register(_pinctrl_driver);
}
arch_initcall(imx8mp_pinctrl_init);
+
+MODULE_AUTHOR("Anson Huang ");
+MODULE_DESCRIPTION("NXP i.MX8MP pinctrl driver");
+MODULE_LICENSE("GPL v2");
--
2.7.4
[PATCH V5 7/9] pinctrl: imx8qxp: Support building as module
Change configuration to "tristate", add module device table,
author, description and license to support building i.MX8QXP
pinctrl driver as module.
Signed-off-by: Anson Huang
---
Changes since V4:
- remove unnecessary change of replacing arch_initcall() with
module_platform_driver();
- add module author and description;
- add more details to commit message.
---
drivers/pinctrl/freescale/Kconfig | 2 +-
drivers/pinctrl/freescale/pinctrl-imx8qxp.c | 5 +
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/pinctrl/freescale/Kconfig
b/drivers/pinctrl/freescale/Kconfig
index af28f14..412d581 100644
--- a/drivers/pinctrl/freescale/Kconfig
+++ b/drivers/pinctrl/freescale/Kconfig
@@ -160,7 +160,7 @@ config PINCTRL_IMX8QM
Say Y here to enable the imx8qm pinctrl driver
config PINCTRL_IMX8QXP
- bool "IMX8QXP pinctrl driver"
+ tristate "IMX8QXP pinctrl driver"
depends on IMX_SCU && ARCH_MXC && ARM64
select PINCTRL_IMX_SCU
help
diff --git a/drivers/pinctrl/freescale/pinctrl-imx8qxp.c
b/drivers/pinctrl/freescale/pinctrl-imx8qxp.c
index 05906b9..6776ad6 100644
--- a/drivers/pinctrl/freescale/pinctrl-imx8qxp.c
+++ b/drivers/pinctrl/freescale/pinctrl-imx8qxp.c
@@ -207,6 +207,7 @@ static const struct of_device_id imx8qxp_pinctrl_of_match[]
= {
{ .compatible = "fsl,imx8qxp-iomuxc", },
{ /* sentinel */ }
};
+MODULE_DEVICE_TABLE(of, imx8qxp_pinctrl_of_match);
static int imx8qxp_pinctrl_probe(struct platform_device *pdev)
{
@@ -233,3 +234,7 @@ static int __init imx8qxp_pinctrl_init(void)
return platform_driver_register(_pinctrl_driver);
}
arch_initcall(imx8qxp_pinctrl_init);
+
+MODULE_AUTHOR("Aisheng Dong ");
+MODULE_DESCRIPTION("NXP i.MX8QXP pinctrl driver");
+MODULE_LICENSE("GPL v2");
--
2.7.4
[PATCH V5 1/9] pinctrl: imx: Support building SCU pinctrl driver as module
To support building i.MX SCU pinctrl driver as module, below things
need to be changed:
- Export SCU related functions and use "IS_ENABLED" instead of
"ifdef" to support SCU pinctrl driver user and itself to be
built as module;
- Use function callbacks for SCU related functions in pinctrl-imx.c
in order to support the scenario of PINCTRL_IMX is built in
while PINCTRL_IMX_SCU is built as module;
- All drivers using SCU pinctrl driver need to initialize the
SCU related function callback;
- Change PINCTR_IMX_SCU to tristate;
- Add module author, description and license.
With above changes, i.MX SCU pinctrl driver can be built as module.
Signed-off-by: Anson Huang
---
Changes since V4:
- add module author and description.
---
drivers/pinctrl/freescale/Kconfig | 2 +-
drivers/pinctrl/freescale/pinctrl-imx.c | 18 -
drivers/pinctrl/freescale/pinctrl-imx.h | 57 -
drivers/pinctrl/freescale/pinctrl-imx8dxl.c | 3 ++
drivers/pinctrl/freescale/pinctrl-imx8qm.c | 3 ++
drivers/pinctrl/freescale/pinctrl-imx8qxp.c | 3 ++
drivers/pinctrl/freescale/pinctrl-scu.c | 9 +
7 files changed, 51 insertions(+), 44 deletions(-)
diff --git a/drivers/pinctrl/freescale/Kconfig
b/drivers/pinctrl/freescale/Kconfig
index 4ca44dd..a3a30f1d 100644
--- a/drivers/pinctrl/freescale/Kconfig
+++ b/drivers/pinctrl/freescale/Kconfig
@@ -7,7 +7,7 @@ config PINCTRL_IMX
select REGMAP
config PINCTRL_IMX_SCU
- bool
+ tristate "IMX SCU pinctrl driver"
depends on IMX_SCU
select PINCTRL_IMX
diff --git a/drivers/pinctrl/freescale/pinctrl-imx.c
b/drivers/pinctrl/freescale/pinctrl-imx.c
index cb7e0f0..c1faae1 100644
--- a/drivers/pinctrl/freescale/pinctrl-imx.c
+++ b/drivers/pinctrl/freescale/pinctrl-imx.c
@@ -372,8 +372,8 @@ static int imx_pinconf_get(struct pinctrl_dev *pctldev,
struct imx_pinctrl *ipctl = pinctrl_dev_get_drvdata(pctldev);
const struct imx_pinctrl_soc_info *info = ipctl->info;
- if (info->flags & IMX_USE_SCU)
- return imx_pinconf_get_scu(pctldev, pin_id, config);
+ if ((info->flags & IMX_USE_SCU) && info->imx_pinconf_get)
+ return info->imx_pinconf_get(pctldev, pin_id, config);
else
return imx_pinconf_get_mmio(pctldev, pin_id, config);
}
@@ -422,8 +422,8 @@ static int imx_pinconf_set(struct pinctrl_dev *pctldev,
struct imx_pinctrl *ipctl = pinctrl_dev_get_drvdata(pctldev);
const struct imx_pinctrl_soc_info *info = ipctl->info;
- if (info->flags & IMX_USE_SCU)
- return imx_pinconf_set_scu(pctldev, pin_id,
+ if ((info->flags & IMX_USE_SCU) && info->imx_pinconf_set)
+ return info->imx_pinconf_set(pctldev, pin_id,
configs, num_configs);
else
return imx_pinconf_set_mmio(pctldev, pin_id,
@@ -439,8 +439,8 @@ static void imx_pinconf_dbg_show(struct pinctrl_dev
*pctldev,
unsigned long config;
int ret;
- if (info->flags & IMX_USE_SCU) {
- ret = imx_pinconf_get_scu(pctldev, pin_id, );
+ if ((info->flags & IMX_USE_SCU) && info->imx_pinconf_get) {
+ ret = info->imx_pinconf_get(pctldev, pin_id, );
if (ret) {
dev_err(ipctl->dev, "failed to get %s pinconf\n",
pin_get_name(pctldev, pin_id));
@@ -628,9 +628,9 @@ static int imx_pinctrl_parse_groups(struct device_node *np,
for (i = 0; i < grp->num_pins; i++) {
pin = &((struct imx_pin *)(grp->data))[i];
- if (info->flags & IMX_USE_SCU)
- imx_pinctrl_parse_pin_scu(ipctl, >pins[i],
- pin, );
+ if ((info->flags & IMX_USE_SCU) && info->imx_pinctrl_parse_pin)
+ info->imx_pinctrl_parse_pin(ipctl, >pins[i],
+ pin, );
else
imx_pinctrl_parse_pin_mmio(ipctl, >pins[i],
pin, , np);
diff --git a/drivers/pinctrl/freescale/pinctrl-imx.h
b/drivers/pinctrl/freescale/pinctrl-imx.h
index 333d32b..bdb86c2 100644
--- a/drivers/pinctrl/freescale/pinctrl-imx.h
+++ b/drivers/pinctrl/freescale/pinctrl-imx.h
@@ -75,6 +75,21 @@ struct imx_cfg_params_decode {
bool invert;
};
+/**
+ * @dev: a pointer back to containing device
+ * @base: the offset to the controller in virtual memory
+ */
+struct imx_pinctrl {
+ struct device *dev;
+ struct pinctrl_dev *pctl;
+ void __iomem *base;
+ void __iomem *input_sel_base;
+ const struct imx_pinctrl_soc_info *info;
+ struct imx_pin_reg *pin_regs;
+ unsigned int group_index;
+ struct mutex mutex;
+};
+
struct imx_pinctrl_soc_info {
const
[PATCH V5 4/9] pinctrl: imx8mn: Support building as module
Change configuration to "tristate", add module device table,
author, description and license to support building i.MX8MN
pinctrl driver as module.
Signed-off-by: Anson Huang
---
Changes since V4:
- remove unnecessary change of replacing arch_initcall() with
module_platform_driver();
- add module author and description;
- add more details to commit message.
---
drivers/pinctrl/freescale/Kconfig | 2 +-
drivers/pinctrl/freescale/pinctrl-imx8mn.c | 6 ++
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/pinctrl/freescale/Kconfig
b/drivers/pinctrl/freescale/Kconfig
index 556adc3..fe3e49c 100644
--- a/drivers/pinctrl/freescale/Kconfig
+++ b/drivers/pinctrl/freescale/Kconfig
@@ -132,7 +132,7 @@ config PINCTRL_IMX8MM
Say Y here to enable the imx8mm pinctrl driver
config PINCTRL_IMX8MN
- bool "IMX8MN pinctrl driver"
+ tristate "IMX8MN pinctrl driver"
depends on ARCH_MXC
select PINCTRL_IMX
help
diff --git a/drivers/pinctrl/freescale/pinctrl-imx8mn.c
b/drivers/pinctrl/freescale/pinctrl-imx8mn.c
index 100ed8c..14c9deb 100644
--- a/drivers/pinctrl/freescale/pinctrl-imx8mn.c
+++ b/drivers/pinctrl/freescale/pinctrl-imx8mn.c
@@ -5,6 +5,7 @@
#include
#include
+#include
#include
#include
#include
@@ -326,6 +327,7 @@ static const struct of_device_id imx8mn_pinctrl_of_match[]
= {
{ .compatible = "fsl,imx8mn-iomuxc", .data = _pinctrl_info, },
{ /* sentinel */ }
};
+MODULE_DEVICE_TABLE(of, imx8mn_pinctrl_of_match);
static int imx8mn_pinctrl_probe(struct platform_device *pdev)
{
@@ -346,3 +348,7 @@ static int __init imx8mn_pinctrl_init(void)
return platform_driver_register(_pinctrl_driver);
}
arch_initcall(imx8mn_pinctrl_init);
+
+MODULE_AUTHOR("Anson Huang ");
+MODULE_DESCRIPTION("NXP i.MX8MN pinctrl driver");
+MODULE_LICENSE("GPL v2");
--
2.7.4
[PATCH V5 0/9] Support i.MX8 SoCs pinctrl drivers built as module
There are more and mroe requirements that SoC specific modules should be built as module in order to support generic kernel image, such as Android GKI concept. This patch series supports i.MX8 SoCs pinctrl drivers to be built as module, including i.MX8MQ/MM/MN/MP/QXP/QM/DXL SoCs, and it also supports building i.MX common pinctrl driver and i.MX SCU common pinctrl driver as module. Compared to V4, the changes are as below: - remove unnecessary changes of replacing arch_initcall() with module_platform_driver() in each SoC pinctrl driver, to make sure no probe sequence change for built-in config. - add module author and description to each module. Anson Huang (9): pinctrl: imx: Support building SCU pinctrl driver as module pinctrl: imx: Support building i.MX pinctrl driver as module pinctrl: imx8mm: Support building as module pinctrl: imx8mn: Support building as module pinctrl: imx8mq: Support building as module pinctrl: imx8mp: Support building as module pinctrl: imx8qxp: Support building as module pinctrl: imx8qm: Support building as module pinctrl: imx8dxl: Support building as module drivers/pinctrl/freescale/Kconfig | 19 +- drivers/pinctrl/freescale/pinctrl-imx.c | 25 - drivers/pinctrl/freescale/pinctrl-imx.h | 57 - drivers/pinctrl/freescale/pinctrl-imx8dxl.c | 8 drivers/pinctrl/freescale/pinctrl-imx8mm.c | 6 +++ drivers/pinctrl/freescale/pinctrl-imx8mn.c | 6 +++ drivers/pinctrl/freescale/pinctrl-imx8mp.c | 6 +++ drivers/pinctrl/freescale/pinctrl-imx8mq.c | 6 +++ drivers/pinctrl/freescale/pinctrl-imx8qm.c | 8 drivers/pinctrl/freescale/pinctrl-imx8qxp.c | 8 drivers/pinctrl/freescale/pinctrl-scu.c | 9 + 11 files changed, 106 insertions(+), 52 deletions(-) -- 2.7.4
[PATCH v2] dma-buf: Move dma_buf_release() from fops to dentry_ops
Charan Teja reported a 'use-after-free' in dmabuffs_dname [1], which
happens if the dma_buf_release() is called while the userspace is
accessing the dma_buf pseudo fs's dmabuffs_dname() in another process,
and dma_buf_release() releases the dmabuf object when the last reference
to the struct file goes away.
I discussed with Arnd Bergmann, and he suggested that rather than tying
the dma_buf_release() to the file_operations' release(), we can tie it to
the dentry_operations' d_release(), which will be called when the last ref
to the dentry is removed.
The path exercised by __fput() calls f_op->release() first, and then calls
dput, which eventually calls d_op->d_release().
In the 'normal' case, when no userspace access is happening via dma_buf
pseudo fs, there should be exactly one fd, file, dentry and inode, so
closing the fd will kill of everything right away.
In the presented case, the dentry's d_release() will be called only when
the dentry's last ref is released.
Therefore, lets move dma_buf_release() from fops->release() to
d_ops->d_release()
Many thanks to Arnd for his FS insights :)
[1]: https://lore.kernel.org/patchwork/patch/1238278/
Fixes: bb2bb9030425 ("dma-buf: add DMA_BUF_SET_NAME ioctls")
Reported-by: syzbot+3643a18836bce555b...@syzkaller.appspotmail.com
Cc: [5.3+]
Cc: Arnd Bergmann
Reported-by: Charan Teja Reddy
Reviewed-by: Arnd Bergmann
Signed-off-by: Sumit Semwal
---
v2: per Arnd: Moved dma_buf_release() above to avoid forward declaration;
removed dentry_ops check.
---
drivers/dma-buf/dma-buf.c | 54 ++-
1 file changed, 25 insertions(+), 29 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 01ce125f8e8d..412629601ad3 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -54,37 +54,11 @@ static char *dmabuffs_dname(struct dentry *dentry, char
*buffer, int buflen)
dentry->d_name.name, ret > 0 ? name : "");
}
-static const struct dentry_operations dma_buf_dentry_ops = {
- .d_dname = dmabuffs_dname,
-};
-
-static struct vfsmount *dma_buf_mnt;
-
-static int dma_buf_fs_init_context(struct fs_context *fc)
-{
- struct pseudo_fs_context *ctx;
-
- ctx = init_pseudo(fc, DMA_BUF_MAGIC);
- if (!ctx)
- return -ENOMEM;
- ctx->dops = _buf_dentry_ops;
- return 0;
-}
-
-static struct file_system_type dma_buf_fs_type = {
- .name = "dmabuf",
- .init_fs_context = dma_buf_fs_init_context,
- .kill_sb = kill_anon_super,
-};
-
-static int dma_buf_release(struct inode *inode, struct file *file)
+static void dma_buf_release(struct dentry *dentry)
{
struct dma_buf *dmabuf;
- if (!is_dma_buf_file(file))
- return -EINVAL;
-
- dmabuf = file->private_data;
+ dmabuf = dentry->d_fsdata;
BUG_ON(dmabuf->vmapping_counter);
@@ -110,9 +84,32 @@ static int dma_buf_release(struct inode *inode, struct file
*file)
module_put(dmabuf->owner);
kfree(dmabuf->name);
kfree(dmabuf);
+}
+
+static const struct dentry_operations dma_buf_dentry_ops = {
+ .d_dname = dmabuffs_dname,
+ .d_release = dma_buf_release,
+};
+
+static struct vfsmount *dma_buf_mnt;
+
+static int dma_buf_fs_init_context(struct fs_context *fc)
+{
+ struct pseudo_fs_context *ctx;
+
+ ctx = init_pseudo(fc, DMA_BUF_MAGIC);
+ if (!ctx)
+ return -ENOMEM;
+ ctx->dops = _buf_dentry_ops;
return 0;
}
+static struct file_system_type dma_buf_fs_type = {
+ .name = "dmabuf",
+ .init_fs_context = dma_buf_fs_init_context,
+ .kill_sb = kill_anon_super,
+};
+
static int dma_buf_mmap_internal(struct file *file, struct vm_area_struct *vma)
{
struct dma_buf *dmabuf;
@@ -412,7 +409,6 @@ static void dma_buf_show_fdinfo(struct seq_file *m, struct
file *file)
}
static const struct file_operations dma_buf_fops = {
- .release= dma_buf_release,
.mmap = dma_buf_mmap_internal,
.llseek = dma_buf_llseek,
.poll = dma_buf_poll,
--
2.27.0
Re: [PATCH v5 2/2] regulator: Add driver for cros-ec-regulator
Hi Pi-Hsun, Thank you for your patch, one last change, sorry to not request it before. On 11/6/20 10:25, Pi-Hsun Shih wrote: > Add driver for cros-ec-regulator, representing a voltage regulator that > is connected and controlled by ChromeOS EC, and is controlled by kernel > with EC host commands. > > Signed-off-by: Pi-Hsun Shih > --- > Changes from v4: > * Change compatible name from regulator-cros-ec to cros-ec-regulator. > > Changes from v3: > * Remove check around CONFIG_OF. > * Add new host commands to cros_ec_trace. > * Use devm_kstrdup for duping regulator name. > * Change license header and add MODULE_AUTHOR. > * Address review comments. > > Changes from v2: > * Add 'depends on OF' to Kconfig. > * Add Kconfig description about compiling as module. > > Changes from v1: > * Change compatible string to google,regulator-cros-ec. > * Use reg property in device tree. > * Address comments on code styles. > > This patch contains function cros_ec_cmd that is copied from the series: > https://lore.kernel.org/patchwork/project/lkml/list/?series=428457. > > I can't find the first patch in that v2 series, so the function is > modified from v1 of that series according to reviewers comment: > https://lore.kernel.org/patchwork/patch/1188110/ > > I copied the function instead of depending on that series since I feel > the function is small enough, and the series has stalled for some time. > --- > drivers/platform/chrome/cros_ec_trace.c | 5 + Could you split this patch in two, one for chrome-platform that introduces the new commands (cros_ec_commands and cros_ec_trace) and another one with the regulator driver. > drivers/regulator/Kconfig | 10 + > drivers/regulator/Makefile| 1 + > drivers/regulator/cros-ec-regulator.c | 256 ++ > .../linux/platform_data/cros_ec_commands.h| 82 ++ > 5 files changed, 354 insertions(+) > create mode 100644 drivers/regulator/cros-ec-regulator.c > > diff --git a/drivers/platform/chrome/cros_ec_trace.c > b/drivers/platform/chrome/cros_ec_trace.c > index 523a39bd0ff6..425e9441b7ca 100644 > --- a/drivers/platform/chrome/cros_ec_trace.c > +++ b/drivers/platform/chrome/cros_ec_trace.c > @@ -161,6 +161,11 @@ > TRACE_SYMBOL(EC_CMD_ADC_READ), \ > TRACE_SYMBOL(EC_CMD_ROLLBACK_INFO), \ > TRACE_SYMBOL(EC_CMD_AP_RESET), \ > + TRACE_SYMBOL(EC_CMD_REGULATOR_GET_INFO), \ > + TRACE_SYMBOL(EC_CMD_REGULATOR_ENABLE), \ > + TRACE_SYMBOL(EC_CMD_REGULATOR_IS_ENABLED), \ > + TRACE_SYMBOL(EC_CMD_REGULATOR_SET_VOLTAGE), \ > + TRACE_SYMBOL(EC_CMD_REGULATOR_GET_VOLTAGE), \ Also make sure this is following the order generated by the command sed -n 's/^#define \(EC_CMD_[[:alnum:]_]*\)\s.*/\tTRACE_SYMBOL(\1), \\/p' \ include/linux/platform_data/cros_ec_commands.h after introduce the EC commands. With that fixed you can add: Reviewed-by: Enric Balletbo i Serra on both patches. Thanks, Enric > TRACE_SYMBOL(EC_CMD_CR51_BASE), \ > TRACE_SYMBOL(EC_CMD_CR51_LAST), \ > TRACE_SYMBOL(EC_CMD_FP_PASSTHRU), \ > diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig > index 8f677f5d79b4..c398e90e0e73 100644 > --- a/drivers/regulator/Kconfig > +++ b/drivers/regulator/Kconfig > @@ -238,6 +238,16 @@ config REGULATOR_CPCAP > Say y here for CPCAP regulator found on some Motorola phones > and tablets such as Droid 4. > > +config REGULATOR_CROS_EC > + tristate "ChromeOS EC regulators" > + depends on CROS_EC && OF > + help > + This driver supports voltage regulators that is connected to ChromeOS > + EC and controlled through EC host commands. > + > + This driver can also be built as a module. If so, the module > + will be called cros-ec-regulator. > + > config REGULATOR_DA903X > tristate "Dialog Semiconductor DA9030/DA9034 regulators" > depends on PMIC_DA903X > diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile > index e8f163371071..46592c160d22 100644 > --- a/drivers/regulator/Makefile > +++ b/drivers/regulator/Makefile > @@ -13,6 +13,7 @@ obj-$(CONFIG_REGULATOR_USERSPACE_CONSUMER) += > userspace-consumer.o > obj-$(CONFIG_REGULATOR_88PG86X) += 88pg86x.o > obj-$(CONFIG_REGULATOR_88PM800) += 88pm800-regulator.o > obj-$(CONFIG_REGULATOR_88PM8607) += 88pm8607.o > +obj-$(CONFIG_REGULATOR_CROS_EC) += cros-ec-regulator.o > obj-$(CONFIG_REGULATOR_CPCAP) += cpcap-regulator.o > obj-$(CONFIG_REGULATOR_AAT2870) += aat2870-regulator.o > obj-$(CONFIG_REGULATOR_AB3100) += ab3100.o > diff --git a/drivers/regulator/cros-ec-regulator.c > b/drivers/regulator/cros-ec-regulator.c > new file mode 100644 > index ..830ceefc704a > --- /dev/null > +++ b/drivers/regulator/cros-ec-regulator.c > @@ -0,0 +1,256 @@ > +// SPDX-License-Identifier: GPL-2.0-only > +// > +// Copyright 2020 Google LLC. > + > +#include > +#include > +#include > +#include > +#include >
Re: [PATCH v1] virtio-mem: add memory via add_memory_driver_managed()
On Thu, Jun 11, 2020 at 01:33:04PM +0200, David Hildenbrand wrote:
>
>
> Am 11.06.2020 um 13:18 schrieb Michael S. Tsirkin :
>
>
> On Thu, Jun 11, 2020 at 01:00:24PM +0200, David Hildenbrand wrote:
>
> I'd like to have this patch in 5.8, with the initial merge of
> virtio-mem
>
> if possible (so the user space representation of virtio-mem
> added memory
>
> resources won't change anymore).
>
>
>
> So my plan is to rebase on top of -rc1 and merge this for rc2
> then.
>
> I don't like rebase on top of tip as the results are sometimes
> kind
> of
>
> random.
>
>
>
> Right, I just wanted to get this out early so we can discuss how to
> proceed.
>
>
>
> And let's add a Fixes: tag as well, this way people will remember
> to
>
> pick this.
>
> Makes sense?
>
>
>
> Yes, it's somehow a fix (for kexec). So
>
>
>
> Fixes: 5f1f79bbc9e26 ("virtio-mem: Paravirtualized memory hotplug")
>
>
>
> I can respin after -rc1 with the commit id fixed as noted by Pankaj.
>
> Just let me know what you prefer.
>
>
>
> Thanks!
>
>
> Some once this commit is in Linus' tree, please ping me.
>
>
> It already is as mentioned, only the id was wrong.
>
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=
> 7b7b27214bba1966772f9213cd2d8e5d67f8487f
OK I pushed this into next based on tip. Let's see what happens.
>
>
>
> --
>
> Thanks,
>
>
>
> David / dhildenb
>
>
>
Re: [PATCH v5 1/2] dt-bindings: regulator: Add DT binding for cros-ec-regulator
Hi Pi-Hsun,
On 11/6/20 10:25, Pi-Hsun Shih wrote:
> Add DT binding documentation for cros-ec-regulator, a voltage regulator
> controlled by ChromeOS EC.
>
> Signed-off-by: Pi-Hsun Shih
Reviewed-by: Enric Balletbo i Serra
> ---
> Changes from v4:
> * Change compatible name from regulator-cros-ec to cros-ec-regulator.
>
> Changes from v3:
> * Fix dt bindings file name.
> * Add full example.
>
> Changes from v2:
> * No change
>
> Changes from v1:
> * Change compatible string to google,regulator-cros-ec.
> * Use reg property in device tree.
> * Change license for dt binding according to checkpatch.pl.
> ---
> .../regulator/google,cros-ec-regulator.yaml | 51 +++
> 1 file changed, 51 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/regulator/google,cros-ec-regulator.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/regulator/google,cros-ec-regulator.yaml
> b/Documentation/devicetree/bindings/regulator/google,cros-ec-regulator.yaml
> new file mode 100644
> index ..c9453d7ce227
> --- /dev/null
> +++
> b/Documentation/devicetree/bindings/regulator/google,cros-ec-regulator.yaml
> @@ -0,0 +1,51 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/regulator/google,cros-ec-regulator.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: ChromeOS EC controlled voltage regulators
> +
> +maintainers:
> + - Pi-Hsun Shih
> +
> +description:
> + Any property defined as part of the core regulator binding, defined in
> + regulator.yaml, can also be used.
> +
> +allOf:
> + - $ref: "regulator.yaml#"
> +
> +properties:
> + compatible:
> +const: google,cros-ec-regulator
> +
> + reg:
> +maxItems: 1
> +description: Identifier for the voltage regulator to ChromeOS EC.
> +
> +required:
> + - compatible
> + - reg
> +
> +examples:
> + - |
> +spi0 {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +cros_ec: ec@0 {
> +compatible = "google,cros-ec-spi";
> +reg = <0>;
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +regulator@0 {
> +compatible = "google,cros-ec-regulator";
> +regulator-min-microvolt = <180>;
> +regulator-max-microvolt = <330>;
> +reg = <0>;
> +};
> +};
> +};
> +...
>
[PATCH RFC v8 02/11] vhost: use batched get_vq_desc version
As testing shows no performance change, switch to that now.
Signed-off-by: Michael S. Tsirkin
Signed-off-by: Eugenio Pérez
Link: https://lore.kernel.org/r/20200401183118.8334-3-epere...@redhat.com
Signed-off-by: Michael S. Tsirkin
---
drivers/vhost/test.c | 2 +-
drivers/vhost/vhost.c | 314 --
drivers/vhost/vhost.h | 7 +-
3 files changed, 61 insertions(+), 262 deletions(-)
diff --git a/drivers/vhost/test.c b/drivers/vhost/test.c
index 0466921f4772..7d69778aaa26 100644
--- a/drivers/vhost/test.c
+++ b/drivers/vhost/test.c
@@ -119,7 +119,7 @@ static int vhost_test_open(struct inode *inode, struct file
*f)
dev = >dev;
vqs[VHOST_TEST_VQ] = >vqs[VHOST_TEST_VQ];
n->vqs[VHOST_TEST_VQ].handle_kick = handle_vq_kick;
- vhost_dev_init(dev, vqs, VHOST_TEST_VQ_MAX, UIO_MAXIOV,
+ vhost_dev_init(dev, vqs, VHOST_TEST_VQ_MAX, UIO_MAXIOV + 64,
VHOST_TEST_PKT_WEIGHT, VHOST_TEST_WEIGHT, true, NULL);
f->private_data = n;
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index 11433d709651..dfcdb36d4227 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -304,6 +304,7 @@ static void vhost_vq_reset(struct vhost_dev *dev,
{
vq->num = 1;
vq->ndescs = 0;
+ vq->first_desc = 0;
vq->desc = NULL;
vq->avail = NULL;
vq->used = NULL;
@@ -372,6 +373,11 @@ static int vhost_worker(void *data)
return 0;
}
+static int vhost_vq_num_batch_descs(struct vhost_virtqueue *vq)
+{
+ return vq->max_descs - UIO_MAXIOV;
+}
+
static void vhost_vq_free_iovecs(struct vhost_virtqueue *vq)
{
kfree(vq->descs);
@@ -394,6 +400,9 @@ static long vhost_dev_alloc_iovecs(struct vhost_dev *dev)
for (i = 0; i < dev->nvqs; ++i) {
vq = dev->vqs[i];
vq->max_descs = dev->iov_limit;
+ if (vhost_vq_num_batch_descs(vq) < 0) {
+ return -EINVAL;
+ }
vq->descs = kmalloc_array(vq->max_descs,
sizeof(*vq->descs),
GFP_KERNEL);
@@ -1610,6 +1619,7 @@ long vhost_vring_ioctl(struct vhost_dev *d, unsigned int
ioctl, void __user *arg
vq->last_avail_idx = s.num;
/* Forget the cached index value. */
vq->avail_idx = vq->last_avail_idx;
+ vq->ndescs = vq->first_desc = 0;
break;
case VHOST_GET_VRING_BASE:
s.index = idx;
@@ -2078,253 +2088,6 @@ static unsigned next_desc(struct vhost_virtqueue *vq,
struct vring_desc *desc)
return next;
}
-static int get_indirect(struct vhost_virtqueue *vq,
- struct iovec iov[], unsigned int iov_size,
- unsigned int *out_num, unsigned int *in_num,
- struct vhost_log *log, unsigned int *log_num,
- struct vring_desc *indirect)
-{
- struct vring_desc desc;
- unsigned int i = 0, count, found = 0;
- u32 len = vhost32_to_cpu(vq, indirect->len);
- struct iov_iter from;
- int ret, access;
-
- /* Sanity check */
- if (unlikely(len % sizeof desc)) {
- vq_err(vq, "Invalid length in indirect descriptor: "
- "len 0x%llx not multiple of 0x%zx\n",
- (unsigned long long)len,
- sizeof desc);
- return -EINVAL;
- }
-
- ret = translate_desc(vq, vhost64_to_cpu(vq, indirect->addr), len,
vq->indirect,
-UIO_MAXIOV, VHOST_ACCESS_RO);
- if (unlikely(ret < 0)) {
- if (ret != -EAGAIN)
- vq_err(vq, "Translation failure %d in indirect.\n",
ret);
- return ret;
- }
- iov_iter_init(, READ, vq->indirect, ret, len);
-
- /* We will use the result as an address to read from, so most
-* architectures only need a compiler barrier here. */
- read_barrier_depends();
-
- count = len / sizeof desc;
- /* Buffers are chained via a 16 bit next field, so
-* we can have at most 2^16 of these. */
- if (unlikely(count > USHRT_MAX + 1)) {
- vq_err(vq, "Indirect buffer length too big: %d\n",
- indirect->len);
- return -E2BIG;
- }
-
- do {
- unsigned iov_count = *in_num + *out_num;
- if (unlikely(++found > count)) {
- vq_err(vq, "Loop detected: last one at %u "
- "indirect size %u\n",
- i, count);
- return -EINVAL;
- }
- if (unlikely(!copy_from_iter_full(, sizeof(desc), )))
{
- vq_err(vq, "Failed indirect descriptor: idx %d, %zx\n",
- i, (size_t)vhost64_to_cpu(vq,
[PATCH RFC v8 10/11] vhost/vsock: switch to the buf API
A straight-forward conversion.
Signed-off-by: Michael S. Tsirkin
---
drivers/vhost/vsock.c | 30 ++
1 file changed, 18 insertions(+), 12 deletions(-)
diff --git a/drivers/vhost/vsock.c b/drivers/vhost/vsock.c
index a483cec31d5c..61c6d3dd2ae3 100644
--- a/drivers/vhost/vsock.c
+++ b/drivers/vhost/vsock.c
@@ -103,7 +103,8 @@ vhost_transport_do_send_pkt(struct vhost_vsock *vsock,
unsigned out, in;
size_t nbytes;
size_t iov_len, payload_len;
- int head;
+ struct vhost_buf buf;
+ int ret;
spin_lock_bh(>send_pkt_list_lock);
if (list_empty(>send_pkt_list)) {
@@ -117,16 +118,17 @@ vhost_transport_do_send_pkt(struct vhost_vsock *vsock,
list_del_init(>list);
spin_unlock_bh(>send_pkt_list_lock);
- head = vhost_get_vq_desc(vq, vq->iov, ARRAY_SIZE(vq->iov),
-, , NULL, NULL);
- if (head < 0) {
+ ret = vhost_get_avail_buf(vq, ,
+ vq->iov, ARRAY_SIZE(vq->iov),
+ , , NULL, NULL);
+ if (ret < 0) {
spin_lock_bh(>send_pkt_list_lock);
list_add(>list, >send_pkt_list);
spin_unlock_bh(>send_pkt_list_lock);
break;
}
- if (head == vq->num) {
+ if (!ret) {
spin_lock_bh(>send_pkt_list_lock);
list_add(>list, >send_pkt_list);
spin_unlock_bh(>send_pkt_list_lock);
@@ -186,7 +188,8 @@ vhost_transport_do_send_pkt(struct vhost_vsock *vsock,
*/
virtio_transport_deliver_tap_pkt(pkt);
- vhost_add_used(vq, head, sizeof(pkt->hdr) + payload_len);
+ buf.in_len = sizeof(pkt->hdr) + payload_len;
+ vhost_put_used_buf(vq, );
added = true;
pkt->off += payload_len;
@@ -440,7 +443,8 @@ static void vhost_vsock_handle_tx_kick(struct vhost_work
*work)
struct vhost_vsock *vsock = container_of(vq->dev, struct vhost_vsock,
dev);
struct virtio_vsock_pkt *pkt;
- int head, pkts = 0, total_len = 0;
+ int ret, pkts = 0, total_len = 0;
+ struct vhost_buf buf;
unsigned int out, in;
bool added = false;
@@ -461,12 +465,13 @@ static void vhost_vsock_handle_tx_kick(struct vhost_work
*work)
goto no_more_replies;
}
- head = vhost_get_vq_desc(vq, vq->iov, ARRAY_SIZE(vq->iov),
-, , NULL, NULL);
- if (head < 0)
+ ret = vhost_get_avail_buf(vq, ,
+ vq->iov, ARRAY_SIZE(vq->iov),
+ , , NULL, NULL);
+ if (ret < 0)
break;
- if (head == vq->num) {
+ if (!ret) {
if (unlikely(vhost_enable_notify(>dev, vq))) {
vhost_disable_notify(>dev, vq);
continue;
@@ -494,7 +499,8 @@ static void vhost_vsock_handle_tx_kick(struct vhost_work
*work)
virtio_transport_free_pkt(pkt);
len += sizeof(pkt->hdr);
- vhost_add_used(vq, head, len);
+ buf.in_len = len;
+ vhost_put_used_buf(vq, );
total_len += len;
added = true;
} while(likely(!vhost_exceeds_weight(vq, ++pkts, total_len)));
--
MST
[PATCH RFC v8 01/11] vhost: option to fetch descriptors through an independent struct
The idea is to support multiple ring formats by converting
to a format-independent array of descriptors.
This costs extra cycles, but we gain in ability
to fetch a batch of descriptors in one go, which
is good for code cache locality.
When used, this causes a minor performance degradation,
it's been kept as simple as possible for ease of review.
A follow-up patch gets us back the performance by adding batching.
To simplify benchmarking, I kept the old code around so one can switch
back and forth between old and new code. This will go away in the final
submission.
Signed-off-by: Michael S. Tsirkin
Signed-off-by: Eugenio Pérez
Link: https://lore.kernel.org/r/20200401183118.8334-2-epere...@redhat.com
Signed-off-by: Michael S. Tsirkin
---
drivers/vhost/vhost.c | 305 +-
drivers/vhost/vhost.h | 16 +++
2 files changed, 320 insertions(+), 1 deletion(-)
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index 172da092107e..11433d709651 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -303,6 +303,7 @@ static void vhost_vq_reset(struct vhost_dev *dev,
struct vhost_virtqueue *vq)
{
vq->num = 1;
+ vq->ndescs = 0;
vq->desc = NULL;
vq->avail = NULL;
vq->used = NULL;
@@ -373,6 +374,9 @@ static int vhost_worker(void *data)
static void vhost_vq_free_iovecs(struct vhost_virtqueue *vq)
{
+ kfree(vq->descs);
+ vq->descs = NULL;
+ vq->max_descs = 0;
kfree(vq->indirect);
vq->indirect = NULL;
kfree(vq->log);
@@ -389,6 +393,10 @@ static long vhost_dev_alloc_iovecs(struct vhost_dev *dev)
for (i = 0; i < dev->nvqs; ++i) {
vq = dev->vqs[i];
+ vq->max_descs = dev->iov_limit;
+ vq->descs = kmalloc_array(vq->max_descs,
+ sizeof(*vq->descs),
+ GFP_KERNEL);
vq->indirect = kmalloc_array(UIO_MAXIOV,
sizeof(*vq->indirect),
GFP_KERNEL);
@@ -396,7 +404,7 @@ static long vhost_dev_alloc_iovecs(struct vhost_dev *dev)
GFP_KERNEL);
vq->heads = kmalloc_array(dev->iov_limit, sizeof(*vq->heads),
GFP_KERNEL);
- if (!vq->indirect || !vq->log || !vq->heads)
+ if (!vq->indirect || !vq->log || !vq->heads || !vq->descs)
goto err_nomem;
}
return 0;
@@ -488,6 +496,8 @@ void vhost_dev_init(struct vhost_dev *dev,
for (i = 0; i < dev->nvqs; ++i) {
vq = dev->vqs[i];
+ vq->descs = NULL;
+ vq->max_descs = 0;
vq->log = NULL;
vq->indirect = NULL;
vq->heads = NULL;
@@ -2315,6 +2325,299 @@ int vhost_get_vq_desc(struct vhost_virtqueue *vq,
}
EXPORT_SYMBOL_GPL(vhost_get_vq_desc);
+static struct vhost_desc *peek_split_desc(struct vhost_virtqueue *vq)
+{
+ BUG_ON(!vq->ndescs);
+ return >descs[vq->ndescs - 1];
+}
+
+static void pop_split_desc(struct vhost_virtqueue *vq)
+{
+ BUG_ON(!vq->ndescs);
+ --vq->ndescs;
+}
+
+#define VHOST_DESC_FLAGS (VRING_DESC_F_INDIRECT | VRING_DESC_F_WRITE | \
+ VRING_DESC_F_NEXT)
+static int push_split_desc(struct vhost_virtqueue *vq, struct vring_desc
*desc, u16 id)
+{
+ struct vhost_desc *h;
+
+ if (unlikely(vq->ndescs >= vq->max_descs))
+ return -EINVAL;
+ h = >descs[vq->ndescs++];
+ h->addr = vhost64_to_cpu(vq, desc->addr);
+ h->len = vhost32_to_cpu(vq, desc->len);
+ h->flags = vhost16_to_cpu(vq, desc->flags) & VHOST_DESC_FLAGS;
+ h->id = id;
+
+ return 0;
+}
+
+static int fetch_indirect_descs(struct vhost_virtqueue *vq,
+ struct vhost_desc *indirect,
+ u16 head)
+{
+ struct vring_desc desc;
+ unsigned int i = 0, count, found = 0;
+ u32 len = indirect->len;
+ struct iov_iter from;
+ int ret;
+
+ /* Sanity check */
+ if (unlikely(len % sizeof desc)) {
+ vq_err(vq, "Invalid length in indirect descriptor: "
+ "len 0x%llx not multiple of 0x%zx\n",
+ (unsigned long long)len,
+ sizeof desc);
+ return -EINVAL;
+ }
+
+ ret = translate_desc(vq, indirect->addr, len, vq->indirect,
+UIO_MAXIOV, VHOST_ACCESS_RO);
+ if (unlikely(ret < 0)) {
+ if (ret != -EAGAIN)
+ vq_err(vq, "Translation failure %d in indirect.\n",
ret);
+ return ret;
+ }
+ iov_iter_init(, READ, vq->indirect, ret, len);
+
+ /* We will use the result as an address to read from, so most
+
[PATCH RFC v8 07/11] vhost/net: avoid iov length math
Now that API exposes buffer length, we no longer need to
scan IOVs to figure it out.
Signed-off-by: Michael S. Tsirkin
---
drivers/vhost/net.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index 830fe84912a5..0b509be8d7b1 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -607,11 +607,9 @@ static bool vhost_exceeds_maxpend(struct vhost_net *net)
}
static size_t init_iov_iter(struct vhost_virtqueue *vq, struct iov_iter *iter,
- size_t hdr_size, int out)
+ size_t len, size_t hdr_size, int out)
{
/* Skip header. TODO: support TSO. */
- size_t len = iov_length(vq->iov, out);
-
iov_iter_init(iter, WRITE, vq->iov, out, len);
iov_iter_advance(iter, hdr_size);
@@ -640,7 +638,7 @@ static int get_tx_bufs(struct vhost_net *net,
}
/* Sanity check */
- *len = init_iov_iter(vq, >msg_iter, nvq->vhost_hlen, *out);
+ *len = init_iov_iter(vq, >msg_iter, buf->out_len, nvq->vhost_hlen,
*out);
if (*len == 0) {
vq_err(vq, "Unexpected header len for TX: %zd expected %zd\n",
*len, nvq->vhost_hlen);
@@ -1080,7 +1078,7 @@ static int get_rx_bufs(struct vhost_virtqueue *vq,
nlogs += *log_num;
log += *log_num;
}
- len = iov_length(vq->iov + seg, in);
+ len = bufs[bufcount].in_len;
datalen -= len;
++bufcount;
seg += in;
--
MST
[PATCH RFC v8 08/11] vhost/test: convert to the buf API
Signed-off-by: Michael S. Tsirkin
---
drivers/vhost/test.c | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/vhost/test.c b/drivers/vhost/test.c
index 7d69778aaa26..12304eb8da15 100644
--- a/drivers/vhost/test.c
+++ b/drivers/vhost/test.c
@@ -44,9 +44,10 @@ static void handle_vq(struct vhost_test *n)
{
struct vhost_virtqueue *vq = >vqs[VHOST_TEST_VQ];
unsigned out, in;
- int head;
+ int ret;
size_t len, total_len = 0;
void *private;
+ struct vhost_buf buf;
mutex_lock(>mutex);
private = vhost_vq_get_backend(vq);
@@ -58,15 +59,15 @@ static void handle_vq(struct vhost_test *n)
vhost_disable_notify(>dev, vq);
for (;;) {
- head = vhost_get_vq_desc(vq, vq->iov,
-ARRAY_SIZE(vq->iov),
-, ,
-NULL, NULL);
+ ret = vhost_get_avail_buf(vq, , vq->iov,
+ ARRAY_SIZE(vq->iov),
+ , ,
+ NULL, NULL);
/* On error, stop handling until the next kick. */
- if (unlikely(head < 0))
+ if (unlikely(ret < 0))
break;
/* Nothing new? Wait for eventfd to tell us they refilled. */
- if (head == vq->num) {
+ if (!ret) {
if (unlikely(vhost_enable_notify(>dev, vq))) {
vhost_disable_notify(>dev, vq);
continue;
@@ -78,13 +79,14 @@ static void handle_vq(struct vhost_test *n)
"out %d, int %d\n", out, in);
break;
}
- len = iov_length(vq->iov, out);
+ len = buf.out_len;
/* Sanity check */
if (!len) {
vq_err(vq, "Unexpected 0 len for TX\n");
break;
}
- vhost_add_used_and_signal(>dev, vq, head, 0);
+ vhost_put_used_buf(vq, );
+ vhost_signal(>dev, vq);
total_len += len;
if (unlikely(vhost_exceeds_weight(vq, 0, total_len)))
break;
--
MST
[PATCH RFC v8 03/11] vhost/net: pass net specific struct pointer
In preparation for further cleanup, pass net specific pointer
to ubuf callbacks so we can move net specific fields
out to net structures.
Signed-off-by: Michael S. Tsirkin
---
drivers/vhost/net.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index bf5e1d81ae25..ff594eec8ae3 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -94,7 +94,7 @@ struct vhost_net_ubuf_ref {
*/
atomic_t refcount;
wait_queue_head_t wait;
- struct vhost_virtqueue *vq;
+ struct vhost_net_virtqueue *nvq;
};
#define VHOST_NET_BATCH 64
@@ -231,7 +231,7 @@ static void vhost_net_enable_zcopy(int vq)
}
static struct vhost_net_ubuf_ref *
-vhost_net_ubuf_alloc(struct vhost_virtqueue *vq, bool zcopy)
+vhost_net_ubuf_alloc(struct vhost_net_virtqueue *nvq, bool zcopy)
{
struct vhost_net_ubuf_ref *ubufs;
/* No zero copy backend? Nothing to count. */
@@ -242,7 +242,7 @@ vhost_net_ubuf_alloc(struct vhost_virtqueue *vq, bool zcopy)
return ERR_PTR(-ENOMEM);
atomic_set(>refcount, 1);
init_waitqueue_head(>wait);
- ubufs->vq = vq;
+ ubufs->nvq = nvq;
return ubufs;
}
@@ -384,13 +384,13 @@ static void vhost_zerocopy_signal_used(struct vhost_net
*net,
static void vhost_zerocopy_callback(struct ubuf_info *ubuf, bool success)
{
struct vhost_net_ubuf_ref *ubufs = ubuf->ctx;
- struct vhost_virtqueue *vq = ubufs->vq;
+ struct vhost_net_virtqueue *nvq = ubufs->nvq;
int cnt;
rcu_read_lock_bh();
/* set len to mark this desc buffers done DMA */
- vq->heads[ubuf->desc].len = success ?
+ nvq->vq.heads[ubuf->desc].in_len = success ?
VHOST_DMA_DONE_LEN : VHOST_DMA_FAILED_LEN;
cnt = vhost_net_ubuf_put(ubufs);
@@ -402,7 +402,7 @@ static void vhost_zerocopy_callback(struct ubuf_info *ubuf,
bool success)
* less than 10% of times).
*/
if (cnt <= 1 || !(cnt % 16))
- vhost_poll_queue(>poll);
+ vhost_poll_queue(>vq.poll);
rcu_read_unlock_bh();
}
@@ -1525,7 +1525,7 @@ static long vhost_net_set_backend(struct vhost_net *n,
unsigned index, int fd)
/* start polling new socket */
oldsock = vhost_vq_get_backend(vq);
if (sock != oldsock) {
- ubufs = vhost_net_ubuf_alloc(vq,
+ ubufs = vhost_net_ubuf_alloc(nvq,
sock && vhost_sock_zcopy(sock));
if (IS_ERR(ubufs)) {
r = PTR_ERR(ubufs);
--
MST
[PATCH RFC v8 05/11] vhost: format-independent API for used buffers
Add a new API that doesn't assume used ring, heads, etc.
For now, we keep the old APIs around to make it easier
to convert drivers.
Signed-off-by: Michael S. Tsirkin
---
drivers/vhost/vhost.c | 73 +--
drivers/vhost/vhost.h | 17 +-
2 files changed, 79 insertions(+), 11 deletions(-)
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index c38605b01080..03e6bca02288 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -2335,13 +2335,12 @@ static void unfetch_descs(struct vhost_virtqueue *vq)
* number of output then some number of input descriptors, it's actually two
* iovecs, but we pack them into one and note how many of each there were.
*
- * This function returns the descriptor number found, or vq->num (which is
- * never a valid descriptor number) if none was found. A negative code is
- * returned on error. */
-int vhost_get_vq_desc(struct vhost_virtqueue *vq,
- struct iovec iov[], unsigned int iov_size,
- unsigned int *out_num, unsigned int *in_num,
- struct vhost_log *log, unsigned int *log_num)
+ * This function returns a value > 0 if a descriptor was found, or 0 if none
were found.
+ * A negative code is returned on error. */
+int vhost_get_avail_buf(struct vhost_virtqueue *vq, struct vhost_buf *buf,
+ struct iovec iov[], unsigned int iov_size,
+ unsigned int *out_num, unsigned int *in_num,
+ struct vhost_log *log, unsigned int *log_num)
{
int ret = fetch_descs(vq);
int i;
@@ -2354,6 +2353,8 @@ int vhost_get_vq_desc(struct vhost_virtqueue *vq,
*out_num = *in_num = 0;
if (unlikely(log))
*log_num = 0;
+ buf->in_len = buf->out_len = 0;
+ buf->descs = 0;
for (i = vq->first_desc; i < vq->ndescs; ++i) {
unsigned iov_count = *in_num + *out_num;
@@ -2383,6 +2384,7 @@ int vhost_get_vq_desc(struct vhost_virtqueue *vq,
/* If this is an input descriptor,
* increment that count. */
*in_num += ret;
+ buf->in_len += desc->len;
if (unlikely(log && ret)) {
log[*log_num].addr = desc->addr;
log[*log_num].len = desc->len;
@@ -2398,9 +2400,11 @@ int vhost_get_vq_desc(struct vhost_virtqueue *vq,
goto err;
}
*out_num += ret;
+ buf->out_len += desc->len;
}
- ret = desc->id;
+ buf->id = desc->id;
+ ++buf->descs;
if (!(desc->flags & VRING_DESC_F_NEXT))
break;
@@ -2408,12 +2412,41 @@ int vhost_get_vq_desc(struct vhost_virtqueue *vq,
vq->first_desc = i + 1;
- return ret;
+ return 1;
err:
unfetch_descs(vq);
- return ret ? ret : vq->num;
+ return ret;
+}
+EXPORT_SYMBOL_GPL(vhost_get_avail_buf);
+
+/* Reverse the effect of vhost_get_avail_buf. Useful for error handling. */
+void vhost_discard_avail_bufs(struct vhost_virtqueue *vq,
+ struct vhost_buf *buf, unsigned count)
+{
+ vhost_discard_vq_desc(vq, count);
+}
+EXPORT_SYMBOL_GPL(vhost_discard_avail_bufs);
+
+/* This function returns the descriptor number found, or vq->num (which is
+ * never a valid descriptor number) if none was found. A negative code is
+ * returned on error. */
+int vhost_get_vq_desc(struct vhost_virtqueue *vq,
+ struct iovec iov[], unsigned int iov_size,
+ unsigned int *out_num, unsigned int *in_num,
+ struct vhost_log *log, unsigned int *log_num)
+{
+ struct vhost_buf buf;
+ int ret = vhost_get_avail_buf(vq, ,
+ iov, iov_size, out_num, in_num,
+ log, log_num);
+
+ if (likely(ret > 0))
+ return buf->id;
+ if (likely(!ret))
+ return vq->num;
+ return ret;
}
EXPORT_SYMBOL_GPL(vhost_get_vq_desc);
@@ -2507,6 +2540,26 @@ int vhost_add_used(struct vhost_virtqueue *vq, unsigned
int head, int len)
}
EXPORT_SYMBOL_GPL(vhost_add_used);
+int vhost_put_used_buf(struct vhost_virtqueue *vq, struct vhost_buf *buf)
+{
+ return vhost_add_used(vq, buf->id, buf->in_len);
+}
+EXPORT_SYMBOL_GPL(vhost_put_used_buf);
+
+int vhost_put_used_n_bufs(struct vhost_virtqueue *vq,
+ struct vhost_buf *bufs, unsigned count)
+{
+ unsigned i;
+
+ for (i = 0; i < count; ++i) {
+ vq->heads[i].id = cpu_to_vhost32(vq, bufs[i].id);
+ vq->heads[i].len = cpu_to_vhost32(vq, bufs[i].in_len);
+ }
+
+ return vhost_add_used_n(vq, vq->heads, count);
+}
[PATCH RFC v8 11/11] vhost: drop head based APIs
Everyone's using buf APIs, no need for head based ones anymore.
Signed-off-by: Michael S. Tsirkin
---
drivers/vhost/vhost.c | 64 ++-
drivers/vhost/vhost.h | 12
2 files changed, 8 insertions(+), 68 deletions(-)
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index 03e6bca02288..9096bd291c91 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -2425,39 +2425,11 @@ EXPORT_SYMBOL_GPL(vhost_get_avail_buf);
void vhost_discard_avail_bufs(struct vhost_virtqueue *vq,
struct vhost_buf *buf, unsigned count)
{
- vhost_discard_vq_desc(vq, count);
+ unfetch_descs(vq);
+ vq->last_avail_idx -= count;
}
EXPORT_SYMBOL_GPL(vhost_discard_avail_bufs);
-/* This function returns the descriptor number found, or vq->num (which is
- * never a valid descriptor number) if none was found. A negative code is
- * returned on error. */
-int vhost_get_vq_desc(struct vhost_virtqueue *vq,
- struct iovec iov[], unsigned int iov_size,
- unsigned int *out_num, unsigned int *in_num,
- struct vhost_log *log, unsigned int *log_num)
-{
- struct vhost_buf buf;
- int ret = vhost_get_avail_buf(vq, ,
- iov, iov_size, out_num, in_num,
- log, log_num);
-
- if (likely(ret > 0))
- return buf->id;
- if (likely(!ret))
- return vq->num;
- return ret;
-}
-EXPORT_SYMBOL_GPL(vhost_get_vq_desc);
-
-/* Reverse the effect of vhost_get_vq_desc. Useful for error handling. */
-void vhost_discard_vq_desc(struct vhost_virtqueue *vq, int n)
-{
- unfetch_descs(vq);
- vq->last_avail_idx -= n;
-}
-EXPORT_SYMBOL_GPL(vhost_discard_vq_desc);
-
static int __vhost_add_used_n(struct vhost_virtqueue *vq,
struct vring_used_elem *heads,
unsigned count)
@@ -2490,8 +2462,7 @@ static int __vhost_add_used_n(struct vhost_virtqueue *vq,
return 0;
}
-/* After we've used one of their buffers, we tell them about it. We'll then
- * want to notify the guest, using eventfd. */
+static
int vhost_add_used_n(struct vhost_virtqueue *vq, struct vring_used_elem *heads,
unsigned count)
{
@@ -2525,10 +2496,8 @@ int vhost_add_used_n(struct vhost_virtqueue *vq, struct
vring_used_elem *heads,
}
return r;
}
-EXPORT_SYMBOL_GPL(vhost_add_used_n);
-/* After we've used one of their buffers, we tell them about it. We'll then
- * want to notify the guest, using eventfd. */
+static
int vhost_add_used(struct vhost_virtqueue *vq, unsigned int head, int len)
{
struct vring_used_elem heads = {
@@ -2538,14 +2507,17 @@ int vhost_add_used(struct vhost_virtqueue *vq, unsigned
int head, int len)
return vhost_add_used_n(vq, , 1);
}
-EXPORT_SYMBOL_GPL(vhost_add_used);
+/* After we've used one of their buffers, we tell them about it. We'll then
+ * want to notify the guest, using vhost_signal. */
int vhost_put_used_buf(struct vhost_virtqueue *vq, struct vhost_buf *buf)
{
return vhost_add_used(vq, buf->id, buf->in_len);
}
EXPORT_SYMBOL_GPL(vhost_put_used_buf);
+/* After we've used one of their buffers, we tell them about it. We'll then
+ * want to notify the guest, using vhost_signal. */
int vhost_put_used_n_bufs(struct vhost_virtqueue *vq,
struct vhost_buf *bufs, unsigned count)
{
@@ -2606,26 +2578,6 @@ void vhost_signal(struct vhost_dev *dev, struct
vhost_virtqueue *vq)
}
EXPORT_SYMBOL_GPL(vhost_signal);
-/* And here's the combo meal deal. Supersize me! */
-void vhost_add_used_and_signal(struct vhost_dev *dev,
- struct vhost_virtqueue *vq,
- unsigned int head, int len)
-{
- vhost_add_used(vq, head, len);
- vhost_signal(dev, vq);
-}
-EXPORT_SYMBOL_GPL(vhost_add_used_and_signal);
-
-/* multi-buffer version of vhost_add_used_and_signal */
-void vhost_add_used_and_signal_n(struct vhost_dev *dev,
-struct vhost_virtqueue *vq,
-struct vring_used_elem *heads, unsigned count)
-{
- vhost_add_used_n(vq, heads, count);
- vhost_signal(dev, vq);
-}
-EXPORT_SYMBOL_GPL(vhost_add_used_and_signal_n);
-
/* return true if we're sure that avaiable ring is empty */
bool vhost_vq_avail_empty(struct vhost_dev *dev, struct vhost_virtqueue *vq)
{
diff --git a/drivers/vhost/vhost.h b/drivers/vhost/vhost.h
index 28eea0155efb..264a2a2fae97 100644
--- a/drivers/vhost/vhost.h
+++ b/drivers/vhost/vhost.h
@@ -197,11 +197,6 @@ long vhost_vring_ioctl(struct vhost_dev *d, unsigned int
ioctl, void __user *arg
bool vhost_vq_access_ok(struct vhost_virtqueue *vq);
bool vhost_log_access_ok(struct vhost_dev *);
-int vhost_get_vq_desc(struct vhost_virtqueue *,
- struct iovec
[PATCH RFC v8 04/11] vhost: reorder functions
Reorder functions in the file to not rely on forward
declarations, in preparation to making them static
down the road.
Signed-off-by: Michael S. Tsirkin
---
drivers/vhost/vhost.c | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index dfcdb36d4227..c38605b01080 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -2425,19 +2425,6 @@ void vhost_discard_vq_desc(struct vhost_virtqueue *vq,
int n)
}
EXPORT_SYMBOL_GPL(vhost_discard_vq_desc);
-/* After we've used one of their buffers, we tell them about it. We'll then
- * want to notify the guest, using eventfd. */
-int vhost_add_used(struct vhost_virtqueue *vq, unsigned int head, int len)
-{
- struct vring_used_elem heads = {
- cpu_to_vhost32(vq, head),
- cpu_to_vhost32(vq, len)
- };
-
- return vhost_add_used_n(vq, , 1);
-}
-EXPORT_SYMBOL_GPL(vhost_add_used);
-
static int __vhost_add_used_n(struct vhost_virtqueue *vq,
struct vring_used_elem *heads,
unsigned count)
@@ -2507,6 +2494,19 @@ int vhost_add_used_n(struct vhost_virtqueue *vq, struct
vring_used_elem *heads,
}
EXPORT_SYMBOL_GPL(vhost_add_used_n);
+/* After we've used one of their buffers, we tell them about it. We'll then
+ * want to notify the guest, using eventfd. */
+int vhost_add_used(struct vhost_virtqueue *vq, unsigned int head, int len)
+{
+ struct vring_used_elem heads = {
+ cpu_to_vhost32(vq, head),
+ cpu_to_vhost32(vq, len)
+ };
+
+ return vhost_add_used_n(vq, , 1);
+}
+EXPORT_SYMBOL_GPL(vhost_add_used);
+
static bool vhost_notify(struct vhost_dev *dev, struct vhost_virtqueue *vq)
{
__u16 old, new;
--
MST
[PATCH RFC v8 09/11] vhost/scsi: switch to buf APIs
Switch to buf APIs. Doing this exposes a spec violation in vhost scsi:
all used bufs are marked with length 0.
Fix that is left for another day.
Signed-off-by: Michael S. Tsirkin
---
drivers/vhost/scsi.c | 73 ++--
1 file changed, 44 insertions(+), 29 deletions(-)
diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c
index 0cbaa0b3893d..a5cdd4c01a3a 100644
--- a/drivers/vhost/scsi.c
+++ b/drivers/vhost/scsi.c
@@ -71,8 +71,8 @@ struct vhost_scsi_inflight {
};
struct vhost_scsi_cmd {
- /* Descriptor from vhost_get_vq_desc() for virt_queue segment */
- int tvc_vq_desc;
+ /* Descriptor from vhost_get_avail_buf() for virt_queue segment */
+ struct vhost_buf tvc_vq_desc;
/* virtio-scsi initiator task attribute */
int tvc_task_attr;
/* virtio-scsi response incoming iovecs */
@@ -213,7 +213,7 @@ struct vhost_scsi {
* Context for processing request and control queue operations.
*/
struct vhost_scsi_ctx {
- int head;
+ struct vhost_buf buf;
unsigned int out, in;
size_t req_size, rsp_size;
size_t out_size, in_size;
@@ -443,6 +443,20 @@ static int vhost_scsi_check_stop_free(struct se_cmd
*se_cmd)
return target_put_sess_cmd(se_cmd);
}
+/* Signal to guest that request finished with no input buffer. */
+/* TODO calling this when writing into buffer and most likely a bug */
+static void vhost_scsi_signal_noinput(struct vhost_dev *vdev,
+ struct vhost_virtqueue *vq,
+ struct vhost_buf *bufp)
+{
+ struct vhost_buf buf = *bufp;
+
+ buf.in_len = 0;
+ vhost_put_used_buf(vq, );
+ vhost_signal(vdev, vq);
+}
+
+
static void
vhost_scsi_do_evt_work(struct vhost_scsi *vs, struct vhost_scsi_evt *evt)
{
@@ -450,7 +464,8 @@ vhost_scsi_do_evt_work(struct vhost_scsi *vs, struct
vhost_scsi_evt *evt)
struct virtio_scsi_event *event = >event;
struct virtio_scsi_event __user *eventp;
unsigned out, in;
- int head, ret;
+ struct vhost_buf buf;
+ int ret;
if (!vhost_vq_get_backend(vq)) {
vs->vs_events_missed = true;
@@ -459,14 +474,14 @@ vhost_scsi_do_evt_work(struct vhost_scsi *vs, struct
vhost_scsi_evt *evt)
again:
vhost_disable_notify(>dev, vq);
- head = vhost_get_vq_desc(vq, vq->iov,
- ARRAY_SIZE(vq->iov), , ,
- NULL, NULL);
- if (head < 0) {
+ ret = vhost_get_avail_buf(vq, ,
+ vq->iov, ARRAY_SIZE(vq->iov), , ,
+ NULL, NULL);
+ if (ret < 0) {
vs->vs_events_missed = true;
return;
}
- if (head == vq->num) {
+ if (!ret) {
if (vhost_enable_notify(>dev, vq))
goto again;
vs->vs_events_missed = true;
@@ -488,7 +503,7 @@ vhost_scsi_do_evt_work(struct vhost_scsi *vs, struct
vhost_scsi_evt *evt)
eventp = vq->iov[out].iov_base;
ret = __copy_to_user(eventp, event, sizeof(*event));
if (!ret)
- vhost_add_used_and_signal(>dev, vq, head, 0);
+ vhost_scsi_signal_noinput(>dev, vq, );
else
vq_err(vq, "Faulted on vhost_scsi_send_event\n");
}
@@ -549,7 +564,7 @@ static void vhost_scsi_complete_cmd_work(struct vhost_work
*work)
ret = copy_to_iter(_rsp, sizeof(v_rsp), _iter);
if (likely(ret == sizeof(v_rsp))) {
struct vhost_scsi_virtqueue *q;
- vhost_add_used(cmd->tvc_vq, cmd->tvc_vq_desc, 0);
+ vhost_put_used_buf(cmd->tvc_vq, >tvc_vq_desc);
q = container_of(cmd->tvc_vq, struct
vhost_scsi_virtqueue, vq);
vq = q - vs->vqs;
__set_bit(vq, signal);
@@ -793,7 +808,7 @@ static void vhost_scsi_submission_work(struct work_struct
*work)
static void
vhost_scsi_send_bad_target(struct vhost_scsi *vs,
struct vhost_virtqueue *vq,
- int head, unsigned out)
+ struct vhost_buf *buf, unsigned out)
{
struct virtio_scsi_cmd_resp __user *resp;
struct virtio_scsi_cmd_resp rsp;
@@ -804,7 +819,7 @@ vhost_scsi_send_bad_target(struct vhost_scsi *vs,
resp = vq->iov[out].iov_base;
ret = __copy_to_user(resp, , sizeof(rsp));
if (!ret)
- vhost_add_used_and_signal(>dev, vq, head, 0);
+ vhost_scsi_signal_noinput(>dev, vq, buf);
else
pr_err("Faulted on virtio_scsi_cmd_resp\n");
}
@@ -813,21 +828,21 @@ static int
vhost_scsi_get_desc(struct vhost_scsi *vs, struct vhost_virtqueue *vq,
struct vhost_scsi_ctx *vc)
{
- int ret = -ENXIO;
+ int r, ret = -ENXIO;
- vc->head =
[PATCH RFC v8 00/11] vhost: ring format independence
This still causes corruption issues for people so don't try to use in production please. Posting to expedite debugging. This adds infrastructure required for supporting multiple ring formats. The idea is as follows: we convert descriptors to an independent format first, and process that converting to iov later. Used ring is similar: we fetch into an independent struct first, convert that to IOV later. The point is that we have a tight loop that fetches descriptors, which is good for cache utilization. This will also allow all kind of batching tricks - e.g. it seems possible to keep SMAP disabled while we are fetching multiple descriptors. For used descriptors, this allows keeping track of the buffer length without need to rescan IOV. This seems to perform exactly the same as the original code based on a microbenchmark. Lightly tested. More testing would be very much appreciated. changes from v8: - squashed in fixes. no longer hangs but still known to cause data corruption for some people. under debug. changes from v6: - fixes some bugs introduced in v6 and v5 changes from v5: - addressed comments by Jason: squashed API changes, fixed up discard changes from v4: - added used descriptor format independence - addressed comments by jason - fixed a crash detected by the lkp robot. changes from v3: - fixed error handling in case of indirect descriptors - add BUG_ON to detect buffer overflow in case of bugs in response to comment by Jason Wang - minor code tweaks Changes from v2: - fixed indirect descriptor batching reported by Jason Wang Changes from v1: - typo fixes Michael S. Tsirkin (14): vhost: option to fetch descriptors through an independent struct fixup! vhost: option to fetch descriptors through an independent struct Michael S. Tsirkin (11): vhost: option to fetch descriptors through an independent struct vhost: use batched get_vq_desc version vhost/net: pass net specific struct pointer vhost: reorder functions vhost: format-independent API for used buffers vhost/net: convert to new API: heads->bufs vhost/net: avoid iov length math vhost/test: convert to the buf API vhost/scsi: switch to buf APIs vhost/vsock: switch to the buf API vhost: drop head based APIs drivers/vhost/net.c | 174 +-- drivers/vhost/scsi.c | 73 drivers/vhost/test.c | 22 +-- drivers/vhost/vhost.c | 378 +++--- drivers/vhost/vhost.h | 44 +++-- drivers/vhost/vsock.c | 30 ++-- 6 files changed, 439 insertions(+), 282 deletions(-) -- MST
[PATCH RFC v8 06/11] vhost/net: convert to new API: heads->bufs
Convert vhost net to use the new format-agnostic API.
In particular, don't poke at vq internals such as the
heads array.
Signed-off-by: Michael S. Tsirkin
---
drivers/vhost/net.c | 154 +++-
1 file changed, 82 insertions(+), 72 deletions(-)
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index ff594eec8ae3..830fe84912a5 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -59,13 +59,13 @@ MODULE_PARM_DESC(experimental_zcopytx, "Enable Zero Copy
TX;"
* status internally; used for zerocopy tx only.
*/
/* Lower device DMA failed */
-#define VHOST_DMA_FAILED_LEN ((__force __virtio32)3)
+#define VHOST_DMA_FAILED_LEN (3)
/* Lower device DMA done */
-#define VHOST_DMA_DONE_LEN ((__force __virtio32)2)
+#define VHOST_DMA_DONE_LEN (2)
/* Lower device DMA in progress */
-#define VHOST_DMA_IN_PROGRESS ((__force __virtio32)1)
+#define VHOST_DMA_IN_PROGRESS (1)
/* Buffer unused */
-#define VHOST_DMA_CLEAR_LEN((__force __virtio32)0)
+#define VHOST_DMA_CLEAR_LEN(0)
#define VHOST_DMA_IS_DONE(len) ((__force u32)(len) >= (__force
u32)VHOST_DMA_DONE_LEN)
@@ -112,9 +112,12 @@ struct vhost_net_virtqueue {
/* last used idx for outstanding DMA zerocopy buffers */
int upend_idx;
/* For TX, first used idx for DMA done zerocopy buffers
-* For RX, number of batched heads
+* For RX, number of batched bufs
*/
int done_idx;
+ /* Outstanding user bufs. UIO_MAXIOV in length. */
+ /* TODO: we can make this smaller for sure. */
+ struct vhost_buf *bufs;
/* Number of XDP frames batched */
int batched_xdp;
/* an array of userspace buffers info */
@@ -271,6 +274,8 @@ static void vhost_net_clear_ubuf_info(struct vhost_net *n)
int i;
for (i = 0; i < VHOST_NET_VQ_MAX; ++i) {
+ kfree(n->vqs[i].bufs);
+ n->vqs[i].bufs = NULL;
kfree(n->vqs[i].ubuf_info);
n->vqs[i].ubuf_info = NULL;
}
@@ -282,6 +287,12 @@ static int vhost_net_set_ubuf_info(struct vhost_net *n)
int i;
for (i = 0; i < VHOST_NET_VQ_MAX; ++i) {
+ n->vqs[i].bufs = kmalloc_array(UIO_MAXIOV,
+ sizeof(*n->vqs[i].bufs),
+ GFP_KERNEL);
+ if (!n->vqs[i].bufs)
+ goto err;
+
zcopy = vhost_net_zcopy_mask & (0x1 << i);
if (!zcopy)
continue;
@@ -364,18 +375,18 @@ static void vhost_zerocopy_signal_used(struct vhost_net
*net,
int j = 0;
for (i = nvq->done_idx; i != nvq->upend_idx; i = (i + 1) % UIO_MAXIOV) {
- if (vq->heads[i].len == VHOST_DMA_FAILED_LEN)
+ if (nvq->bufs[i].in_len == VHOST_DMA_FAILED_LEN)
vhost_net_tx_err(net);
- if (VHOST_DMA_IS_DONE(vq->heads[i].len)) {
- vq->heads[i].len = VHOST_DMA_CLEAR_LEN;
+ if (VHOST_DMA_IS_DONE(nvq->bufs[i].in_len)) {
+ nvq->bufs[i].in_len = VHOST_DMA_CLEAR_LEN;
++j;
} else
break;
}
while (j) {
add = min(UIO_MAXIOV - nvq->done_idx, j);
- vhost_add_used_and_signal_n(vq->dev, vq,
- >heads[nvq->done_idx], add);
+ vhost_put_used_n_bufs(vq, >bufs[nvq->done_idx], add);
+ vhost_signal(vq->dev, vq);
nvq->done_idx = (nvq->done_idx + add) % UIO_MAXIOV;
j -= add;
}
@@ -390,7 +401,7 @@ static void vhost_zerocopy_callback(struct ubuf_info *ubuf,
bool success)
rcu_read_lock_bh();
/* set len to mark this desc buffers done DMA */
- nvq->vq.heads[ubuf->desc].in_len = success ?
+ nvq->bufs[ubuf->desc].in_len = success ?
VHOST_DMA_DONE_LEN : VHOST_DMA_FAILED_LEN;
cnt = vhost_net_ubuf_put(ubufs);
@@ -452,7 +463,8 @@ static void vhost_net_signal_used(struct
vhost_net_virtqueue *nvq)
if (!nvq->done_idx)
return;
- vhost_add_used_and_signal_n(dev, vq, vq->heads, nvq->done_idx);
+ vhost_put_used_n_bufs(vq, nvq->bufs, nvq->done_idx);
+ vhost_signal(dev, vq);
nvq->done_idx = 0;
}
@@ -558,6 +570,7 @@ static void vhost_net_busy_poll(struct vhost_net *net,
static int vhost_net_tx_get_vq_desc(struct vhost_net *net,
struct vhost_net_virtqueue *tnvq,
+ struct vhost_buf *buf,
unsigned int *out_num, unsigned int *in_num,
struct msghdr *msghdr, bool *busyloop_intr)
{
@@ -565,10 +578,10 @@ static int vhost_net_tx_get_vq_desc(struct vhost_net *net,
struct vhost_virtqueue *rvq = >vq;
[GIT PULL] sound fixes for 5.8-rc1
Linus, please pull sound fixes for v5.8-rc1 from: git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git tags/sound-fix-5.8-rc1 The topmost commit is a4f55d927d33accd6eb535ce0db031e2df47714a sound fixes for 5.8-rc1 Here are last-minute fixes gathered before merge window close; a few fixes are for the core while the rest majority are driver fixes. * PCM locking annotation fixes and the possible self-lock fix * ASoC DPCM regression fixes with multi-CPU DAI * A fix for inconsistent resume from system-PM on USB-audio * Improved runtime-PM handling with multiple USB interfaces * Quirks for HD-audio and USB-audio * Hardened firmware handling in max98390 codec * A couple of fixes for meson Bard Liao (1): ASoC: core: only convert non DPCM link to DPCM link Colin Ian King (1): ASoC: meson: fix memory leak of links if allocation of ldata fails Dan Carpenter (1): ALSA: emu10k1: delete an unnecessary condition Dan Murphy (1): dt-bindings: ASoc: Fix tdm-slot documentation spelling error Hans de Goede (2): ASoC: Intel: bytcr_rt5640: Add quirk for Toshiba Encore WT10-A tablet ASoC: rt5645: Add platform-data for Asus T101HA Hui Wang (1): ALSA: hda/realtek - add a pintbl quirk for several Lenovo machines Kai-Heng Feng (1): ALSA: usb-audio: Add vendor, product and profile name for HP Thunderbolt Dock Michał Mirosław (2): ALSA: pcm: fix snd_pcm_link() lockdep splat ALSA: pcm: disallow linking stream to itself Oder Chiou (1): ASoC: rl6231: Modify the target DMIC clock rate Pavel Machek (CIP) (1): ASoC: meson: add missing free_irq() in error path Pierre-Louis Bossart (3): ASoC: soc-pcm: dpcm: fix playback/capture checks ASoC: Intel: boards: replace capture_only by dpcm_capture ASoC: SOF: nocodec: conditionally set dpcm_capture/dpcm_playback flags Shengjiu Wang (1): ASoC: fsl-asoc-card: Defer probe when fail to find codec device Steve Lee (1): ASoC: max98390: Fix potential crash during param fw loading Takashi Iwai (4): ASoC: max98390: Fix incorrect printf qualifier ALSA: usb-audio: Fix inconsistent card PM state after resume ALSA: usb-audio: Use the new macro for HP Dock rename quirks ALSA: usb-audio: Manage auto-pm of all bundled interfaces --- .../devicetree/bindings/sound/tdm-slot.txt | 4 +- sound/core/pcm_native.c| 20 +++- sound/pci/emu10k1/emu10k1x.c | 2 +- sound/pci/hda/patch_realtek.c | 6 +++ sound/soc/codecs/max98390.c| 26 +-- sound/soc/codecs/max98390.h| 3 +- sound/soc/codecs/rl6231.c | 4 +- sound/soc/codecs/rt5645.c | 14 ++ sound/soc/fsl/fsl-asoc-card.c | 2 +- sound/soc/intel/boards/bytcr_rt5640.c | 12 + sound/soc/intel/boards/glk_rt5682_max98357a.c | 2 +- sound/soc/intel/boards/kbl_da7219_max98927.c | 4 +- sound/soc/intel/boards/kbl_rt5663_max98927.c | 2 +- .../soc/intel/boards/kbl_rt5663_rt5514_max98927.c | 2 +- sound/soc/meson/axg-fifo.c | 10 +++- sound/soc/meson/meson-card-utils.c | 17 +-- sound/soc/soc-core.c | 22 +++-- sound/soc/soc-pcm.c| 44 ++ sound/soc/sof/nocodec.c| 6 ++- sound/usb/card.c | 54 +- sound/usb/quirks-table.h | 12 + sound/usb/usbaudio.h | 6 ++- 22 files changed, 219 insertions(+), 55 deletions(-)
[PATCH] tools: PCI: Fix memory leak in run_test
We should free "test" before the return of run_test.
Signed-off-by: Peng Fan
---
tools/pci/pcitest.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/pci/pcitest.c b/tools/pci/pcitest.c
index 0a1344c..7c20332 100644
--- a/tools/pci/pcitest.c
+++ b/tools/pci/pcitest.c
@@ -47,6 +47,7 @@ static int run_test(struct pci_test *test)
fd = open(test->device, O_RDWR);
if (fd < 0) {
perror("can't open PCI Endpoint Test device");
+ free(test);
return -ENODEV;
}
@@ -151,6 +152,7 @@ static int run_test(struct pci_test *test)
fflush(stdout);
close(fd);
+ free(test);
return (ret < 0) ? ret : 1 - ret; /* return 0 if test succeeded */
}
--
2.1.0
Re: [PATCH v3 6/7] venus: Make debug infrastructure more flexible
On 6/11/20 1:52 PM, Daniel Thompson wrote:
> On Wed, Jun 10, 2020 at 11:42:43PM -0700, Joe Perches wrote:
>> On Thu, 2020-06-11 at 08:26 +0200, Greg Kroah-Hartman wrote:
>>> On Wed, Jun 10, 2020 at 01:23:56PM -0700, Joe Perches wrote:
On Wed, 2020-06-10 at 12:49 -0700, Joe Perches wrote:
> On Wed, 2020-06-10 at 15:37 +0200, Greg Kroah-Hartman wrote:
>> Please work with the infrastructure we have, we have spent a lot of time
>> and effort to make it uniform to make it easier for users and
>> developers.
>
> Not quite.
>
> This lack of debug grouping by type has been a
> _long_ standing issue with drivers.
>
>> Don't regress and try to make driver-specific ways of doing
>> things, that way lies madness...
>
> It's not driver specific, it allows driver developers to
> better isolate various debug states instead of keeping
> lists of specific debug messages and enabling them
> individually.
For instance, look at the homebrew content in
drivers/gpu/drm/drm_print.c that does _not_ use
dynamic_debug.
MODULE_PARM_DESC(debug, "Enable debug output, where each bit enables a
debug category.\n"
"\t\tBit 0 (0x01) will enable CORE messages (drm core code)\n"
"\t\tBit 1 (0x02) will enable DRIVER messages (drm controller code)\n"
"\t\tBit 2 (0x04) will enable KMS messages (modesetting code)\n"
"\t\tBit 3 (0x08) will enable PRIME messages (prime code)\n"
"\t\tBit 4 (0x10) will enable ATOMIC messages (atomic code)\n"
"\t\tBit 5 (0x20) will enable VBL messages (vblank code)\n"
"\t\tBit 7 (0x80) will enable LEASE messages (leasing code)\n"
"\t\tBit 8 (0x100) will enable DP messages (displayport code)");
module_param_named(debug, __drm_debug, int, 0600);
void drm_dev_dbg(const struct device *dev, enum drm_debug_category
category,
const char *format, ...)
{
struct va_format vaf;
va_list args;
if (!drm_debug_enabled(category))
return;
>>>
>>> Ok, and will this proposal be able to handle stuff like this?
>>
>> Yes, that's the entire point.
>
> Currently I think there not enough "levels" to map something like
> drm.debug to the new dyn dbg feature. I don't think it is intrinsic
> but I couldn't find the bit of the code where the 5-bit level in struct
> _ddebug is converted from a mask to a bit number and vice-versa.
Here [1] is Joe's initial suggestion. But I decided that bitmask is a
good start for the discussion.
I guess we can add new member uint "level" in struct _ddebug so that we
can cover more "levels" (types, groups).
--
regards,
Stan
[1] https://lkml.org/lkml/2020/5/21/915
Re: [PATCH RFC v7 03/14] vhost: use batched get_vq_desc version
On Wed, Jun 10, 2020 at 06:18:32PM +0200, Eugenio Perez Martin wrote:
> On Wed, Jun 10, 2020 at 5:13 PM Michael S. Tsirkin wrote:
> >
> > On Wed, Jun 10, 2020 at 02:37:50PM +0200, Eugenio Perez Martin wrote:
> > > > +/* This function returns a value > 0 if a descriptor was found, or 0
> > > > if none were found.
> > > > + * A negative code is returned on error. */
> > > > +static int fetch_descs(struct vhost_virtqueue *vq)
> > > > +{
> > > > + int ret;
> > > > +
> > > > + if (unlikely(vq->first_desc >= vq->ndescs)) {
> > > > + vq->first_desc = 0;
> > > > + vq->ndescs = 0;
> > > > + }
> > > > +
> > > > + if (vq->ndescs)
> > > > + return 1;
> > > > +
> > > > + for (ret = 1;
> > > > +ret > 0 && vq->ndescs <= vhost_vq_num_batch_descs(vq);
> > > > +ret = fetch_buf(vq))
> > > > + ;
> > >
> > > (Expanding comment in V6):
> > >
> > > We get an infinite loop this way:
> > > * vq->ndescs == 0, so we call fetch_buf() here
> > > * fetch_buf gets less than vhost_vq_num_batch_descs(vq); descriptors. ret
> > > = 1
> > > * This loop calls again fetch_buf, but vq->ndescs > 0 (and avail_vq ==
> > > last_avail_vq), so it just return 1
> >
> > That's what
> > [PATCH RFC v7 08/14] fixup! vhost: use batched get_vq_desc version
> > is supposed to fix.
> >
>
> Sorry, I forgot to include that fixup.
>
> With it I don't see CPU stalls, but with that version latency has
> increased a lot and I see packet lost:
> + ping -c 5 10.200.0.1
> PING 10.200.0.1 (10.200.0.1) 56(84) bytes of data.
> >From 10.200.0.2 icmp_seq=1 Destination Host Unreachable
> >From 10.200.0.2 icmp_seq=2 Destination Host Unreachable
> >From 10.200.0.2 icmp_seq=3 Destination Host Unreachable
> 64 bytes from 10.200.0.1: icmp_seq=5 ttl=64 time=6848 ms
>
> --- 10.200.0.1 ping statistics ---
> 5 packets transmitted, 1 received, +3 errors, 80% packet loss, time 76ms
> rtt min/avg/max/mdev = 6848.316/6848.316/6848.316/0.000 ms, pipe 4
> --
>
> I cannot even use netperf.
OK so that's the bug to try to find and fix I think.
> If I modify with my proposed version:
> + ping -c 5 10.200.0.1
> PING 10.200.0.1 (10.200.0.1) 56(84) bytes of data.
> 64 bytes from 10.200.0.1: icmp_seq=1 ttl=64 time=7.07 ms
> 64 bytes from 10.200.0.1: icmp_seq=2 ttl=64 time=0.358 ms
> 64 bytes from 10.200.0.1: icmp_seq=3 ttl=64 time=5.35 ms
> 64 bytes from 10.200.0.1: icmp_seq=4 ttl=64 time=2.27 ms
> 64 bytes from 10.200.0.1: icmp_seq=5 ttl=64 time=0.426 ms
Not sure which version this is.
> [root@localhost ~]# netperf -H 10.200.0.1 -p 12865 -l 10 -t TCP_STREAM
> MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
> 10.200.0.1 () port 0 AF_INET
> Recv SendSend
> Socket Socket Message Elapsed
> Size SizeSize Time Throughput
> bytes bytes bytessecs.10^6bits/sec
>
> 131072 16384 1638410.014742.36
> [root@localhost ~]# netperf -H 10.200.0.1 -p 12865 -l 10 -t UDP_STREAM
> MIGRATED UDP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
> 10.200.0.1 () port 0 AF_INET
> Socket Message Elapsed Messages
> SizeSize Time Okay Errors Throughput
> bytes bytessecs# # 10^6bits/sec
>
> 212992 65507 10.009214 0 482.83
> 212992 10.009214482.83
>
> I will compare with the non-batch version for reference, but the
> difference between the two is noticeable. Maybe it's worth finding a
> good value for the if() inside fetch_buf?
>
> Thanks!
>
I don't think it's performance, I think it's a bug somewhere,
e.g. maybe we corrupt a packet, or stall the queue, or
something like this.
Let's do this, I will squash the fixups and post v8 so you can bisect
and then debug cleanly.
> > --
> > MST
> >
Re: [Intel-gfx] [PATCH 03/18] dma-fence: basic lockdep annotations
On Thu, Jun 11, 2020 at 12:36 PM Tvrtko Ursulin wrote: > > > On 10/06/2020 16:17, Daniel Vetter wrote: > > On Wed, Jun 10, 2020 at 4:22 PM Tvrtko Ursulin > > wrote: > >> > >> > >> On 04/06/2020 09:12, Daniel Vetter wrote: > >>> Design is similar to the lockdep annotations for workers, but with > >>> some twists: > >>> > >>> - We use a read-lock for the execution/worker/completion side, so that > >>> this explicit annotation can be more liberally sprinkled around. > >>> With read locks lockdep isn't going to complain if the read-side > >>> isn't nested the same way under all circumstances, so ABBA deadlocks > >>> are ok. Which they are, since this is an annotation only. > >>> > >>> - We're using non-recursive lockdep read lock mode, since in recursive > >>> read lock mode lockdep does not catch read side hazards. And we > >>> _very_ much want read side hazards to be caught. For full details of > >>> this limitation see > >>> > >>> commit e91498589746065e3ae95d9a00b068e525eec34f > >>> Author: Peter Zijlstra > >>> Date: Wed Aug 23 13:13:11 2017 +0200 > >>> > >>> locking/lockdep/selftests: Add mixed read-write ABBA tests > >>> > >>> - To allow nesting of the read-side explicit annotations we explicitly > >>> keep track of the nesting. lock_is_held() allows us to do that. > >>> > >>> - The wait-side annotation is a write lock, and entirely done within > >>> dma_fence_wait() for everyone by default. > >>> > >>> - To be able to freely annotate helper functions I want to make it ok > >>> to call dma_fence_begin/end_signalling from soft/hardirq context. > >>> First attempt was using the hardirq locking context for the write > >>> side in lockdep, but this forces all normal spinlocks nested within > >>> dma_fence_begin/end_signalling to be spinlocks. That bollocks. > >>> > >>> The approach now is to simple check in_atomic(), and for these cases > >>> entirely rely on the might_sleep() check in dma_fence_wait(). That > >>> will catch any wrong nesting against spinlocks from soft/hardirq > >>> contexts. > >>> > >>> The idea here is that every code path that's critical for eventually > >>> signalling a dma_fence should be annotated with > >>> dma_fence_begin/end_signalling. The annotation ideally starts right > >>> after a dma_fence is published (added to a dma_resv, exposed as a > >>> sync_file fd, attached to a drm_syncobj fd, or anything else that > >>> makes the dma_fence visible to other kernel threads), up to and > >>> including the dma_fence_wait(). Examples are irq handlers, the > >>> scheduler rt threads, the tail of execbuf (after the corresponding > >>> fences are visible), any workers that end up signalling dma_fences and > >>> really anything else. Not annotated should be code paths that only > >>> complete fences opportunistically as the gpu progresses, like e.g. > >>> shrinker/eviction code. > >>> > >>> The main class of deadlocks this is supposed to catch are: > >>> > >>> Thread A: > >>> > >>>mutex_lock(A); > >>>mutex_unlock(A); > >>> > >>>dma_fence_signal(); > >>> > >>> Thread B: > >>> > >>>mutex_lock(A); > >>>dma_fence_wait(); > >>>mutex_unlock(A); > >>> > >>> Thread B is blocked on A signalling the fence, but A never gets around > >>> to that because it cannot acquire the lock A. > >>> > >>> Note that dma_fence_wait() is allowed to be nested within > >>> dma_fence_begin/end_signalling sections. To allow this to happen the > >>> read lock needs to be upgraded to a write lock, which means that any > >>> other lock is acquired between the dma_fence_begin_signalling() call and > >>> the call to dma_fence_wait(), and still held, this will result in an > >>> immediate lockdep complaint. The only other option would be to not > >>> annotate such calls, defeating the point. Therefore these annotations > >>> cannot be sprinkled over the code entirely mindless to avoid false > >>> positives. > >>> > >>> v2: handle soft/hardirq ctx better against write side and dont forget > >>> EXPORT_SYMBOL, drivers can't use this otherwise. > >>> > >>> v3: Kerneldoc. > >>> > >>> v4: Some spelling fixes from Mika > >>> > >>> Cc: Mika Kuoppala > >>> Cc: Thomas Hellstrom > >>> Cc: linux-me...@vger.kernel.org > >>> Cc: linaro-mm-...@lists.linaro.org > >>> Cc: linux-r...@vger.kernel.org > >>> Cc: amd-...@lists.freedesktop.org > >>> Cc: intel-...@lists.freedesktop.org > >>> Cc: Chris Wilson > >>> Cc: Maarten Lankhorst > >>> Cc: Christian König > >>> Signed-off-by: Daniel Vetter > >>> --- > >>>Documentation/driver-api/dma-buf.rst | 12 +- > >>>drivers/dma-buf/dma-fence.c | 161 +++ > >>>include/linux/dma-fence.h| 12 ++ > >>>3 files changed, 182 insertions(+), 3 deletions(-) > >>> > >>> diff --git a/Documentation/driver-api/dma-buf.rst > >>> b/Documentation/driver-api/dma-buf.rst > >>> index 63dec76d1d8d..05d856131140 100644 >
Re: WIP generic module->debug_flags and dynamic_debug
On 10/06/2020 20.32, jim.cro...@gmail.com wrote: > so Ive got a WIP / broken / partial approach to giving all modules a > u32 flagset, > and enabling pr_debug based upon it. I leave out the "pr_debug_typed( > bitpos )" for now. For Stanimir, bits 1,2,3 could be high, middle, > low. > > ATM its broken on my lack of container_of() skills. > > Im trying to use it to get a struct module* using its name value thats > been copied > into a ddebug_table member. > > Im relying on > cdf6d006968 dynamic_debug: don't duplicate modname in ddebug_add_module > to have the same value in both structs > > but Im clearly missing a few things > besides the likely future trouble with .rodata builtin modules > (after compile prob solved) > > It seems container_of wants me to use struct ddebug_table instead, > but I dont want a *ddebug_table. > Ive blindly guessed at adding & and * to 1st param, w/o understanding. > > can anyone diagnose my problem ? Sorry, I have not the faintest idea of what you're trying to achieve. Can you spell that out? Rasmus
Re: [RFC v6 00/51] Large pages in the page cache
On Wed, Jun 10, 2020 at 11:59:54PM -0700, Christoph Hellwig wrote: > On Wed, Jun 10, 2020 at 01:12:54PM -0700, Matthew Wilcox wrote: > > From: "Matthew Wilcox (Oracle)" > > > > Another fortnight, another dump of my current large pages work. > > I've squished a lot of bugs this time. xfstests is much happier now, > > running for 1631 seconds and getting as far as generic/086. This patchset > > is getting a little big, so I'm going to try to get some bits of it > > upstream soon (the bits that make sense regardless of whether the rest > > of this is merged). > > At this size a git tree to pull would also be nice.. That was literally the next paragraph ... It's now based on linus' master (6f630784cc0d), and you can get it from http://git.infradead.org/users/willy/linux-dax.git/shortlog/refs/heads/xarray-pa +gecache if you'd rather see it there (this branch is force-pushed frequently) Or are you saying you'd rather see the git URL than the link to gitweb?
Re: [PATCH] crypto: talitos - fix ECB and CBC algs ivsize
On Thu, Jun 11, 2020 at 01:09:38PM +0200, Christophe Leroy wrote:
>
>
> Le 11/06/2020 à 13:03, Greg KH a écrit :
> > On Thu, Jun 11, 2020 at 12:50:24PM +0200, Christophe Leroy wrote:
> > > Hi,
> > >
> > > Le 11/06/2020 à 12:07, Su Kang Yin a écrit :
> > > > Patch for 4.9 upstream:
> > > >
> > > > commit e1de42fdfc6a ("crypto: talitos - fix ECB algs ivsize")
> > > > wrongly modified CBC algs ivsize instead of ECB aggs ivsize.
> > >
> > > To make it clear and avoid this problem to happen again, please generate
> > > your patch with option -U8
> >
> > No need, this patch should be fine as-is.
> >
>
> Still, this patch includes more than the original patch as far as I can see
> (scroll down and see other comments in that answer)
Ah, good catch, I'll go drop this now, thanks!
greg k-h
Re: (EXT) Re: Consistent block device references for root= cmdline
On Wed, 2020-06-10 at 12:33 -0500, Roger Heflin wrote: > No idea if this would still work, but back before label/uuid and lvm > in initird I had a staticly linked "C" program that ran inside > initrd, > it searched for likely places a boot device could be (mounted them > and > looked for a file to confirm it was the right device, then unmounted > it), and when it found the right one, it then echo's is major/minor > numbers into /proc/sys/kernel/real-root-dev and that is used for > root= > without it being on the command line. Assuming you could get > something similar started by sytemd and/or udev inside the initrd it > might still work. Using an initramfs is obviously an option, but it complicates both the build setup and boot process, so we would like to avoid making this a hard requirement if possible. > > On Wed, Jun 10, 2020 at 11:51 AM Ulf Hansson > wrote: > > > > On Wed, 10 Jun 2020 at 15:15, Matthias Schiffer > > wrote: > > > > > > Hello all, > > > > > > there have been numerous attempts to make the numbering of mmcblk > > > devices consistent, mostly by using aliases from the DTS ([1], > > > [2], > > > [3]), but all have been (rightfully) rejected. Unless I have > > > overlooked > > > a more recent development, no attempts for a different solution > > > were > > > made. > > > > According to aliases attempts, I think those have failed, mainly > > because of two reasons. > > > > 1. Arguments stating that LABELs/UUIDs are variable alternatives. > > This > > isn't the case, which I think was also concluded from the several > > earlier discussions. > > 2. Patches that tried adding support for mmc aliases, were not > > correctly coded. More precisely, what needs to be addressed is that > > the mmc core also preserves the same ids to be set for the host > > class > > as the block device, mmc[n] must correspond to mmcblk[n]. > > > > > > > > As far as I can tell, the core of the issue seems to be the > > > following: > > > > > > The existing solutions like LABELs and UUIDs are viable > > > alternatives in > > > many cases, but in particular on embedded systems, this is not > > > quite > > > sufficient: In addition to the problem that more knowledge about > > > the > > > system to boot is required in the bootloader, this approach fails > > > completely when the same firmware image exists on multiple > > > devices, for > > > example on an eMMC and an SD card - not an entirely uncommon > > > situation > > > during the development of embedded systems. > > > > > > With udev, I can refer to a specific partition using a path like > > > /dev/disk/by-path/platform-2194000.usdhc-part2. In [4] it was > > > proposed > > > to add a way to refer to a device path/phandle from the kernel > > > command > > > line. Has there been any progress on this proposal? > > > > Lots of time during the years I have been approached, both publicly > > and offlist, about whether it would be possible to add support for > > "consistent" mmcblk devices. To me, I am fine with the aliases > > approach, as long as it gets implemented correctly. > > > > > > > > Kind regards, > > > Matthias > > > > > > > > > [1] https://patchwork.kernel.org/patch/8685711/ > > > [2] https://lore.kernel.org/patchwork/cover/674381/ > > > [3] https://www.spinics.net/lists/linux-mmc/msg26586.html > > > [4] https://www.spinics.net/lists/linux-mmc/msg26708.html > > > > > > > Kind regards > > Uffe
Re: [PATCH v4 00/27] clk: bcm: rpi: Add support for BCM2711 firmware clocks
On Thu, 2020-06-11 at 09:31 +0200, Maxime Ripard wrote: > Hi, > > Since the whole DRM/HDMI support began to grow fairly big, I've chosen > to split away the two discussions between the firmware clocks and the > HDMI support. > > Let me know what you think, > Maxime > With patch #25 manually fixed, the series is: Tested-by: Nicolas Saenz Julienne Regards, Nicolas signature.asc Description: This is a digitally signed message part
[PATCH] ima: fix mprotect checking
Make sure IMA is enabled before checking mprotect change. Addresses
report of a 3.7% regression of boot-time.dhcp.
Fixes: 8eb613c0b8f1 ("ima: verify mprotect change is consistent with mmap
policy")
Reported-by: kernel test robot
Signed-off-by: Mimi Zohar
---
security/integrity/ima/ima_main.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/security/integrity/ima/ima_main.c
b/security/integrity/ima/ima_main.c
index 800fb3bba418..c1583d98c5e5 100644
--- a/security/integrity/ima/ima_main.c
+++ b/security/integrity/ima/ima_main.c
@@ -419,7 +419,8 @@ int ima_file_mprotect(struct vm_area_struct *vma, unsigned
long prot)
int pcr;
/* Is mprotect making an mmap'ed file executable? */
- if (!vma->vm_file || !(prot & PROT_EXEC) || (vma->vm_flags & VM_EXEC))
+ if (!(ima_policy_flag & IMA_APPRAISE) || !vma->vm_file ||
+ !(prot & PROT_EXEC) || (vma->vm_flags & VM_EXEC))
return 0;
security_task_getsecid(current, );
--
2.7.5
Re: (EXT) Re: Consistent block device references for root= cmdline
On Wed, 2020-06-10 at 16:52 +0200, Ulf Hansson wrote: > On Wed, 10 Jun 2020 at 15:15, Matthias Schiffer > wrote: > > > > Hello all, > > > > there have been numerous attempts to make the numbering of mmcblk > > devices consistent, mostly by using aliases from the DTS ([1], [2], > > [3]), but all have been (rightfully) rejected. Unless I have > > overlooked > > a more recent development, no attempts for a different solution > > were > > made. > > According to aliases attempts, I think those have failed, mainly > because of two reasons. > > 1. Arguments stating that LABELs/UUIDs are variable alternatives. > This > isn't the case, which I think was also concluded from the several > earlier discussions. > 2. Patches that tried adding support for mmc aliases, were not > correctly coded. More precisely, what needs to be addressed is that > the mmc core also preserves the same ids to be set for the host class > as the block device, mmc[n] must correspond to mmcblk[n]. > > > > > As far as I can tell, the core of the issue seems to be the > > following: > > > > The existing solutions like LABELs and UUIDs are viable > > alternatives in > > many cases, but in particular on embedded systems, this is not > > quite > > sufficient: In addition to the problem that more knowledge about > > the > > system to boot is required in the bootloader, this approach fails > > completely when the same firmware image exists on multiple devices, > > for > > example on an eMMC and an SD card - not an entirely uncommon > > situation > > during the development of embedded systems. > > > > With udev, I can refer to a specific partition using a path like > > /dev/disk/by-path/platform-2194000.usdhc-part2. In [4] it was > > proposed > > to add a way to refer to a device path/phandle from the kernel > > command > > line. Has there been any progress on this proposal? > > Lots of time during the years I have been approached, both publicly > and offlist, about whether it would be possible to add support for > "consistent" mmcblk devices. To me, I am fine with the aliases > approach, as long as it gets implemented correctly. It seems the principal technical problem is the one described here: https://www.spinics.net/lists/linux-mmc/msg26602.html I don't see any way to solve this completely, as there seem to be two fundamentally conflicting requirements: 1) If a mounted SD card is replaced, it must be assigned a new /dev/mmcblkN 2) /dev/mmcblkN should always match the configured alias IDs What is the reason we need 1) - is it possible to have multiple eMMCs or SD cards on a single bus, with detection at runtime? Otherwise I'd expect this to be handled like other drives with removable media (CD, floppy), with static device assignment. If we can't give up on 1) for some reason, we'll have to accept that we can't guarantee 2) unconditionally. As far as I can tell, the patches provided by Sascha and others did that in a reasonable way: The aliases would work in most cases - in particular for the first assignment on boot, which is required to find the correct rootfs. > > > > > Kind regards, > > Matthias > > > > > > [1] https://patchwork.kernel.org/patch/8685711/ > > [2] https://lore.kernel.org/patchwork/cover/674381/ > > [3] https://www.spinics.net/lists/linux-mmc/msg26586.html > > [4] https://www.spinics.net/lists/linux-mmc/msg26708.html > > > > Kind regards > Uffe
Re: [PATCH v4.19.y 0/2] btrfs: Fix for CVE-2019-18885
On Tue, Jun 09, 2020 at 12:20:16PM +0530, Vikash Bansal wrote: > CVE Description: > NVD Site Link: https://nvd.nist.gov/vuln/detail?vulnId=CVE-2019-18885 > > It was discovered that the btrfs file system in the Linux kernel did not > properly validate metadata, leading to a NULL pointer dereference. An > attacker could use this to specially craft a file system image that, when > mounted, could cause a denial of service (system crash). > > [PATCH v4.19.y 1/2]: > Backporting of upsream commit 09ba3bc9dd15: > btrfs: merge btrfs_find_device and find_device > > [PATCH v4.19.y 2/2]: > Backporting of upstream commit 62fdaa52a3d0: > btrfs: Detect unbalanced tree with empty leaf before crashing > > On NVD site link of "commit 09ba3bc9dd150457c506e4661380a6183af651c1" > was given as the fix for this CVE. But the issue was still reproducible. > So had to apply patch "Commit 62fdaa52a3d00a875da771719b6dc537ca79fce1" > to fix the issue. Looks good, now queued up,t hanks. greg k-h
Re: [PATCH v1] virtio-mem: add memory via add_memory_driver_managed()
On Thu, Jun 11, 2020 at 01:00:24PM +0200, David Hildenbrand wrote:
> >> I'd like to have this patch in 5.8, with the initial merge of virtio-mem
> >> if possible (so the user space representation of virtio-mem added memory
> >> resources won't change anymore).
> >
> > So my plan is to rebase on top of -rc1 and merge this for rc2 then.
> > I don't like rebase on top of tip as the results are sometimes kind of
> > random.
>
> Right, I just wanted to get this out early so we can discuss how to proceed.
>
> > And let's add a Fixes: tag as well, this way people will remember to
> > pick this.
> > Makes sense?
>
> Yes, it's somehow a fix (for kexec). So
>
> Fixes: 5f1f79bbc9e26 ("virtio-mem: Paravirtualized memory hotplug")
>
> I can respin after -rc1 with the commit id fixed as noted by Pankaj.
> Just let me know what you prefer.
>
> Thanks!
Some once this commit is in Linus' tree, please ping me.
> --
> Thanks,
>
> David / dhildenb
Re: [PATCH] iov_iter: Move unnecessary inclusion of crypto/hash.h
Hi Herbert,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v5.7 next-20200611]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Herbert-Xu/iov_iter-Move-unnecessary-inclusion-of-crypto-hash-h/20200611-154742
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
b29482fde649c72441d5478a4ea2c52c56d97a5e
config: c6x-allyesconfig (attached as .config)
compiler: c6x-elf-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=c6x
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All error/warnings (new ones prefixed by >>, old ones prefixed by <<):
drivers/soc/qcom/pdr_interface.c: In function 'pdr_indack_work':
>> drivers/soc/qcom/pdr_interface.c:292:3: error: implicit declaration of
>> function 'kfree' [-Werror=implicit-function-declaration]
292 | kfree(ind);
| ^
drivers/soc/qcom/pdr_interface.c: In function 'pdr_indication_cb':
>> drivers/soc/qcom/pdr_interface.c:328:8: error: implicit declaration of
>> function 'kzalloc' [-Werror=implicit-function-declaration]
328 | ind = kzalloc(sizeof(*ind), GFP_KERNEL);
|^~~
>> drivers/soc/qcom/pdr_interface.c:328:6: warning: assignment to 'struct
>> pdr_list_node *' from 'int' makes pointer from integer without a cast
>> [-Wint-conversion]
328 | ind = kzalloc(sizeof(*ind), GFP_KERNEL);
| ^
drivers/soc/qcom/pdr_interface.c: In function 'pdr_locate_service':
>> drivers/soc/qcom/pdr_interface.c:401:7: warning: assignment to 'struct
>> servreg_get_domain_list_resp *' from 'int' makes pointer from integer
>> without a cast [-Wint-conversion]
401 | resp = kzalloc(sizeof(*resp), GFP_KERNEL);
| ^
drivers/soc/qcom/pdr_interface.c: In function 'pdr_add_lookup':
>> drivers/soc/qcom/pdr_interface.c:526:6: warning: assignment to 'struct
>> pdr_service *' from 'int' makes pointer from integer without a cast
>> [-Wint-conversion]
526 | pds = kzalloc(sizeof(*pds), GFP_KERNEL);
| ^
drivers/soc/qcom/pdr_interface.c: In function 'pdr_handle_alloc':
>> drivers/soc/qcom/pdr_interface.c:656:6: warning: assignment to 'struct
>> pdr_handle *' from 'int' makes pointer from integer without a cast
>> [-Wint-conversion]
656 | pdr = kzalloc(sizeof(*pdr), GFP_KERNEL);
| ^
cc1: some warnings being treated as errors
vim +/kfree +292 drivers/soc/qcom/pdr_interface.c
fbe639b44a8275 Sibi Sankar 2020-03-12 271
fbe639b44a8275 Sibi Sankar 2020-03-12 272 static void
pdr_indack_work(struct work_struct *work)
fbe639b44a8275 Sibi Sankar 2020-03-12 273 {
fbe639b44a8275 Sibi Sankar 2020-03-12 274struct pdr_handle *pdr
= container_of(work, struct pdr_handle,
fbe639b44a8275 Sibi Sankar 2020-03-12 275
indack_work);
fbe639b44a8275 Sibi Sankar 2020-03-12 276struct pdr_list_node
*ind, *tmp;
fbe639b44a8275 Sibi Sankar 2020-03-12 277struct pdr_service *pds;
fbe639b44a8275 Sibi Sankar 2020-03-12 278
fbe639b44a8275 Sibi Sankar 2020-03-12 279
list_for_each_entry_safe(ind, tmp, >indack_list, node) {
fbe639b44a8275 Sibi Sankar 2020-03-12 280pds = ind->pds;
fbe639b44a8275 Sibi Sankar 2020-03-12 281
pdr_send_indack_msg(pdr, pds, ind->transaction_id);
fbe639b44a8275 Sibi Sankar 2020-03-12 282
fbe639b44a8275 Sibi Sankar 2020-03-12 283
mutex_lock(>status_lock);
fbe639b44a8275 Sibi Sankar 2020-03-12 284pds->state =
ind->curr_state;
fbe639b44a8275 Sibi Sankar 2020-03-12 285
pdr->status(pds->state, pds->service_path, pdr->priv);
fbe639b44a8275 Sibi Sankar 2020-03-12 286
mutex_unlock(>status_lock);
fbe639b44a8275 Sibi Sankar 2020-03-12 287
fbe639b44a8275 Sibi Sankar 2020-03-12 288
mutex_lock(>list_lock);
fbe639b44a8275 Sibi Sankar 2020-03-12 289
list_del(>node);
fbe639b44a8275 Sibi Sankar 2020-03-12 290
mutex_unlock(>list_lock);
fbe639b44a8275 Sibi Sankar 2020-03-12 291
fbe639b44a8275 Sibi Sankar 2020-03-12 @292kfree(ind);
fbe639b44a8275 Sibi Sankar 2020-03-12 293}
fbe639b44a8275
Re: [PATCH v4 27/27] clk: bcm: rpi: Remove the quirks for the CPU clock
On Thu, 2020-06-11 at 09:32 +0200, Maxime Ripard wrote: > The CPU clock has had so far a bunch of quirks to expose the clock tree > properly, but since we reverted to exposing them through the MMIO driver, > we can remove that code from the firmware driver. > > Signed-off-by: Maxime Ripard > --- Acked-by: Nicolas Saenz Julienne Regards, Nicolas signature.asc Description: This is a digitally signed message part
Re: [PATCH v2] serial: imx: Fix handling of TC irq in combination with DMA
On Tue, Jun 09, 2020 at 07:23:40AM +, Schrempf Frieder wrote: > From: Uwe Kleine-König > > commit 1866541492641c02874bf51f9d8712b5510f2c64 upstream > > When using RS485 half duplex the Transmitter Complete irq is needed to > determine the moment when the transmitter can be disabled. When using > DMA this irq must only be enabled when DMA has completed to transfer all > data. Otherwise the CPU might busily trigger this irq which is not > properly handled and so the also pending irq for the DMA transfer cannot > trigger. > > Cc: # v4.14.x > Signed-off-by: Uwe Kleine-König > Signed-off-by: Greg Kroah-Hartman > [Backport to v4.14] > Signed-off-by: Frieder Schrempf > --- > When using RS485 with DMA enabled simply transmitting some data on our > i.MX6ULL based boards often freezes the system completely. The higher > the baudrate, the easier it is to reproduce the issue. To test this I > simply used: > > stty -F /dev/ttymxc1 speed 115200 > while true; do echo TEST > /dev/ttymxc1; done > > Without the patch this leads to an almost immediate system freeze, > with the patch applied, everything keeps working as expected. > --- > drivers/tty/serial/imx.c | 22 ++ > 1 file changed, 18 insertions(+), 4 deletions(-) Now queued up, thanks. greg k-h
Re: [PATCH v4 26/27] clk: bcm2835: Don't cache the PLLB rate
On Thu, 2020-06-11 at 09:32 +0200, Maxime Ripard wrote: > The PLLB rate will be changed through the firmware clocks drivers and will > change behind this drivers' back, so we don't want to cache the rate. > > Signed-off-by: Maxime Ripard > --- Thanks! Acked-by: Nicolas Saenz Julienne Regards, Nicolas signature.asc Description: This is a digitally signed message part
Re: [PATCH v4 23/27] Revert "clk: bcm2835: remove pllb"
On Thu, 2020-06-11 at 09:32 +0200, Maxime Ripard wrote: > This reverts commit 2256d89333bd17b8b56b42734a7e1046d52f7fc3. Since we > will be expanding the firmware clock driver, we'll need to remove the > quirks to deal with the PLLB. However, we still want to expose the clock > tree properly, so having that clock in the MMIO driver will allow that. > > Signed-off-by: Maxime Ripard > --- Acked-by: Nicolas Saenz Julienne Regards, Nicolas signature.asc Description: This is a digitally signed message part
Re: [PATCH v4 21/27] clk: bcm: rpi: Discover the firmware clocks
On Thu, 2020-06-11 at 09:32 +0200, Maxime Ripard wrote: > The RaspberryPi4 firmware actually exposes more clocks than are currently > handled by the driver and we will need to change some of them directly > based on the pixel rate for the display related clocks, or the load for the > GPU. > > Since the firmware implements DVFS, this rate change can have a number of > side-effects, including adjusting the various PLL voltages or the PLL > parents. The firmware also implements thermal throttling, so even some > thermal pressure can change those parameters behind Linux back. > > DVFS is currently implemented on the arm, core, h264, v3d, isp and hevc > clocks, so updating any of them using the MMIO driver (and thus behind the > firmware's back) can lead to troubles, the arm clock obviously being the > most problematic. > > In order to make Linux play as nice as possible with those constraints, it > makes sense to rely on the firmware clocks as much as possible. However, > the firmware doesn't seem to provide some equivalents to their MMIO > counterparts, so we can't really replace that driver entirely. > > Fortunately, the firmware has an interface to discover the clocks it > exposes. > > Let's use it to discover, register the clocks in the clocks framework and > then expose them through the device tree for consumers to use them. > > Cc: Michael Turquette > Cc: Stephen Boyd > Cc: linux-...@vger.kernel.org > Reviewed-by: Stephen Boyd > Signed-off-by: Maxime Ripard > --- Acked-by: Nicolas Saenz Julienne Regards, Nicolas signature.asc Description: This is a digitally signed message part
Re: [PATCH] iov_iter: Move unnecessary inclusion of crypto/hash.h
Hi Herbert,
I love your patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v5.7 next-20200611]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Herbert-Xu/iov_iter-Move-unnecessary-inclusion-of-crypto-hash-h/20200611-154742
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
b29482fde649c72441d5478a4ea2c52c56d97a5e
config: x86_64-randconfig-s021-20200611 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-13) 9.3.0
reproduce:
# apt-get install sparse
# sparse version: v0.6.1-250-g42323db3-dirty
# save the attached .config to linux build tree
make W=1 C=1 ARCH=x86_64 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
sparse warnings: (new ones prefixed by >>)
>> net/core/datagram.c:512:25: sparse: sparse: incorrect type in argument 6
>> (incompatible argument 3 (different base types)) @@ expected unsigned
>> long ( *cb )( ... ) @@ got unsigned long ( * )( ... ) @@
>> net/core/datagram.c:512:25: sparse: expected unsigned long ( *cb )( ... )
>> net/core/datagram.c:512:25: sparse: got unsigned long ( * )( ... )
include/net/sock.h:1603:31: sparse: sparse: context imbalance in
'__skb_free_datagram_locked' - unexpected unlock
vim +512 net/core/datagram.c
950fcaecd5cc6c0 Sagi Grimberg 2018-12-03 497
65d69e2505bb64f Sagi Grimberg 2018-12-03 498 /**
65d69e2505bb64f Sagi Grimberg 2018-12-03 499 *
skb_copy_and_hash_datagram_iter - Copy datagram to an iovec iterator
65d69e2505bb64f Sagi Grimberg 2018-12-03 500 * and update a hash.
65d69e2505bb64f Sagi Grimberg 2018-12-03 501 * @skb: buffer to copy
65d69e2505bb64f Sagi Grimberg 2018-12-03 502 * @offset: offset in the
buffer to start copying from
65d69e2505bb64f Sagi Grimberg 2018-12-03 503 * @to: iovec iterator to
copy to
65d69e2505bb64f Sagi Grimberg 2018-12-03 504 * @len: amount of data to
copy from buffer to iovec
65d69e2505bb64f Sagi Grimberg 2018-12-03 505 * @hash: hash request to
update
65d69e2505bb64f Sagi Grimberg 2018-12-03 506 */
65d69e2505bb64f Sagi Grimberg 2018-12-03 507 int
skb_copy_and_hash_datagram_iter(const struct sk_buff *skb, int offset,
65d69e2505bb64f Sagi Grimberg 2018-12-03 508 struct
iov_iter *to, int len,
65d69e2505bb64f Sagi Grimberg 2018-12-03 509 struct
ahash_request *hash)
65d69e2505bb64f Sagi Grimberg 2018-12-03 510 {
65d69e2505bb64f Sagi Grimberg 2018-12-03 511 return __skb_datagram_iter(skb,
offset, to, len, true,
65d69e2505bb64f Sagi Grimberg 2018-12-03 @512
hash_and_copy_to_iter, hash);
65d69e2505bb64f Sagi Grimberg 2018-12-03 513 }
65d69e2505bb64f Sagi Grimberg 2018-12-03 514
EXPORT_SYMBOL(skb_copy_and_hash_datagram_iter);
65d69e2505bb64f Sagi Grimberg 2018-12-03 515
:: The code at line 512 was first introduced by commit
:: 65d69e2505bb64f6a8d7f417f6e46e2a351174c6 datagram: introduce
skb_copy_and_hash_datagram_iter helper
:: TO: Sagi Grimberg
:: CC: Christoph Hellwig
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: [PATCH? v2] powerpc: Hard wire PT_SOFTE value to 1 in gpr_get() too
On Thu, 11 Jun 2020 12:58:31 +0200, Oleg Nesterov wrote:
> On 06/11, Madhavan Srinivasan wrote:
> > On 6/10/20 8:37 PM, Oleg Nesterov wrote:
> > > > This is not consistent and this breaks
> > > > http://sourceware.org/systemtap/wiki/utrace/tests/user-regs-peekpoke
>
> this is 404.
Attaching the testcase, the CVS web interface no longer works on
sourceware.org.
Jan
/* Test case for PTRACE_SETREGS modifying the requested ragisters.
x86* counterpart of the s390* testcase `user-area-access.c'.
This software is provided 'as-is', without any express or implied
warranty. In no event will the authors be held liable for any damages
arising from the use of this software.
Permission is granted to anyone to use this software for any purpose,
including commercial applications, and to alter it and redistribute it
freely. */
/* FIXME: EFLAGS should be tested restricted on the appropriate bits. */
#define _GNU_SOURCE 1
#if defined __powerpc__ || defined __sparc__
# define user_regs_struct pt_regs
#endif
#ifdef __ia64__
#define ia64_fpreg ia64_fpreg_DISABLE
#define pt_all_user_regs pt_all_user_regs_DISABLE
#endif /* __ia64__ */
#include
#ifdef __ia64__
#undef ia64_fpreg
#undef pt_all_user_regs
#endif /* __ia64__ */
#include
#include
#include
#if defined __i386__ || defined __x86_64__
#include
#endif
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
/* ia64 has PTRACE_SETREGS but it has no USER_REGS_STRUCT. */
#if !defined PTRACE_SETREGS || defined __ia64__
int
main (void)
{
return 77;
}
#else /* PTRACE_SETREGS */
/* The minimal alignment we use for the random access ranges. */
#define REGALIGN (sizeof (long))
static pid_t child;
static void
cleanup (void)
{
if (child > 0)
kill (child, SIGKILL);
child = 0;
}
static void
handler_fail (int signo)
{
cleanup ();
signal (SIGABRT, SIG_DFL);
abort ();
}
int
main (void)
{
long l;
int status, i;
pid_t pid;
union
{
struct user_regs_struct user;
unsigned char byte[sizeof (struct user_regs_struct)];
} u, u2;
int start;
setbuf (stdout, NULL);
atexit (cleanup);
signal (SIGABRT, handler_fail);
signal (SIGALRM, handler_fail);
signal (SIGINT, handler_fail);
i = alarm (10);
assert (i == 0);
child = fork ();
switch (child)
{
case -1:
assert_perror (errno);
assert (0);
case 0:
l = ptrace (PTRACE_TRACEME, 0, NULL, NULL);
assert (l == 0);
// Prevent rt_sigprocmask() call called by glibc after raise().
syscall (__NR_tkill, getpid (), SIGSTOP);
assert (0);
default:
break;
}
pid = waitpid (child, , 0);
assert (pid == child);
assert (WIFSTOPPED (status));
assert (WSTOPSIG (status) == SIGSTOP);
/* Fetch U2 from the inferior. */
errno = 0;
# ifdef __sparc__
l = ptrace (PTRACE_GETREGS, child, , NULL);
# else
l = ptrace (PTRACE_GETREGS, child, NULL, );
# endif
assert_perror (errno);
assert (l == 0);
/* Initialize U with a pattern. */
for (i = 0; i < sizeof u.byte; i++)
u.byte[i] = i;
#ifdef __x86_64__
/* non-EFLAGS modifications fail with EIO, EFLAGS gets back different. */
u.user.eflags = u2.user.eflags;
u.user.cs = u2.user.cs;
u.user.ds = u2.user.ds;
u.user.es = u2.user.es;
u.user.fs = u2.user.fs;
u.user.gs = u2.user.gs;
u.user.ss = u2.user.ss;
u.user.fs_base = u2.user.fs_base;
u.user.gs_base = u2.user.gs_base;
/* RHEL-4 refuses to set too high (and invalid) PC values. */
u.user.rip = (unsigned long) handler_fail;
/* 2.6.25 always truncates and sign-extends orig_rax. */
u.user.orig_rax = (int) u.user.orig_rax;
#endif /* __x86_64__ */
#ifdef __i386__
/* These values get back different. */
u.user.xds = u2.user.xds;
u.user.xes = u2.user.xes;
u.user.xfs = u2.user.xfs;
u.user.xgs = u2.user.xgs;
u.user.xcs = u2.user.xcs;
u.user.eflags = u2.user.eflags;
u.user.xss = u2.user.xss;
/* RHEL-4 refuses to set too high (and invalid) PC values. */
u.user.eip = (unsigned long) handler_fail;
#endif /* __i386__ */
#ifdef __powerpc__
/* These fields are constrained. */
u.user.msr = u2.user.msr;
# ifdef __powerpc64__
u.user.softe = u2.user.softe;
# else
u.user.mq = u2.user.mq;
# endif /* __powerpc64__ */
u.user.trap = u2.user.trap;
u.user.dar = u2.user.dar;
u.user.dsisr = u2.user.dsisr;
u.user.result = u2.user.result;
#endif /* __powerpc__ */
/* Poke U. */
# ifdef __sparc__
l = ptrace (PTRACE_SETREGS, child, , NULL);
# else
l = ptrace (PTRACE_SETREGS, child, NULL, );
# endif
assert (l == 0);
/* Peek into U2. */
# ifdef __sparc__
l = ptrace (PTRACE_GETREGS, child, , NULL);
# else
l = ptrace (PTRACE_GETREGS, child, NULL, );
# endif
assert (l == 0);
/* Verify it matches. */
if (memcmp (, , sizeof u.byte) != 0)
{
for (start = 0; start + REGALIGN <= sizeof u.byte; start += REGALIGN)
if (*(unsigned long *) (u.byte +
[PATCH] dma-buf: support to walk the list of dmabuf for debug
Let's support debugging function to show exporter
detail information. The exporter don't need to manage
the lists for debugging because all dmabuf list are
managed on dmabuf framework.
That supports to walk the dmabuf list and show the
detailed information for exporter by passed function
implemented from exporter.
That helps to show exporter detail information.
For example, ION may show the buffer flag, heap name,
or the name of process to request allocation.
Change-Id: I670f04dda4a0870081e1b0fd96b9185b48b9dd15
Signed-off-by: Hyesoo Yu
---
drivers/dma-buf/dma-buf.c | 30 ++
include/linux/dma-buf.h | 2 ++
2 files changed, 32 insertions(+)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 01ce125f8e8d..002bd3ac636e 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -1254,6 +1254,36 @@ void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
}
EXPORT_SYMBOL_GPL(dma_buf_vunmap);
+int dma_buf_exp_show(struct seq_file *s,
+int (*it)(struct seq_file *s, struct dma_buf *dmabuf))
+{
+ int ret;
+ struct dma_buf *buf_obj;
+
+ ret = mutex_lock_interruptible(_list.lock);
+ if (ret)
+ return ret;
+
+ list_for_each_entry(buf_obj, _list.head, list_node) {
+ ret = mutex_lock_interruptible(_obj->lock);
+ if (ret) {
+ seq_puts(s,
+"\tERROR locking buffer object: skipping\n");
+ continue;
+ }
+
+ ret = it(s, buf_obj);
+ mutex_unlock(_obj->lock);
+ if (ret)
+ break;
+ }
+ mutex_unlock(_list.lock);
+
+ return 0;
+
+}
+EXPORT_SYMBOL_GPL(dma_buf_exp_show);
+
#ifdef CONFIG_DEBUG_FS
static int dma_buf_debug_show(struct seq_file *s, void *unused)
{
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index ab0c156abee6..b5c0a10b4eb3 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -502,4 +502,6 @@ int dma_buf_mmap(struct dma_buf *, struct vm_area_struct *,
unsigned long);
void *dma_buf_vmap(struct dma_buf *);
void dma_buf_vunmap(struct dma_buf *, void *vaddr);
+int dma_buf_exp_show(struct seq_file *s,
+int (*it)(struct seq_file *s, struct dma_buf *dmabuf));
#endif /* __DMA_BUF_H__ */
--
2.27.0
Re: [PATCH] crypto: talitos - fix ECB and CBC algs ivsize
Le 11/06/2020 à 13:03, Greg KH a écrit :
On Thu, Jun 11, 2020 at 12:50:24PM +0200, Christophe Leroy wrote:
Hi,
Le 11/06/2020 à 12:07, Su Kang Yin a écrit :
Patch for 4.9 upstream:
commit e1de42fdfc6a ("crypto: talitos - fix ECB algs ivsize")
wrongly modified CBC algs ivsize instead of ECB aggs ivsize.
To make it clear and avoid this problem to happen again, please generate
your patch with option -U8
No need, this patch should be fine as-is.
Still, this patch includes more than the original patch as far as I can
see (scroll down and see other comments in that answer)
Christophe
Re: [PATCH v4] platform: x86: Add ACPI driver for ChromeOS
Hi, On 11/6/20 0:43, Dmitry Torokhov wrote: > On Wed, Jun 10, 2020 at 09:52:12PM +, mario.limoncie...@dell.com wrote: >>> -Original Message- >>> From: Dmitry Torokhov >>> Sent: Wednesday, June 10, 2020 4:41 PM >>> To: Limonciello, Mario >>> Cc: enric.balle...@collabora.com; r...@rjwysocki.net; raf...@kernel.org; >>> linux-kernel@vger.kernel.org; linux-a...@vger.kernel.org; l...@kernel.org; >>> ker...@collabora.com; gro...@chromium.org; ble...@chromium.org; >>> d...@chromium.org; gwen...@chromium.org; vben...@chromium.org; >>> a...@infradead.org; ayman.baga...@gmail.com; benjamin.tissoi...@redhat.com; >>> b...@mxxn.io; dvh...@infradead.org; gre...@linuxfoundation.org; >>> hdego...@redhat.com; jer...@system76.com; 2...@mok.nu; >>> mchehab+sams...@kernel.org; raja...@google.com; >>> srinivas.pandruv...@linux.intel.com; platform-driver-...@vger.kernel.org >>> Subject: Re: [PATCH v4] platform: x86: Add ACPI driver for ChromeOS >>> >>> >>> [EXTERNAL EMAIL] >>> >>> On Wed, Jun 10, 2020 at 09:28:36PM +, mario.limoncie...@dell.com wrote: > > To give you some references, if I'm not wrong, this prefix is used in >>> all > or > almost all Intel Chromebook devices (auron, cyan, eve, fizz, hatch, > octopus, > poppy, strago ...) The ACPI source for this device can be found here >>> [1], > and, > if not all, almost all Intel based Chromebooks are shipped with the > firmware > that supports this. You can potentially carry a small patch in your downstream kernel for the legacy stuff until it reaches EOL. At least for the new stuff you could enact a process that properly reserves unique numbers and changes the >>> driver when the interface provided by the ACPI device has changed. >>> >>> If we use this prefix for hatch EOL is ~7 years from now. >>> >> >> Isn't the whole point of the ACPI registry and choosing an ID? You know >> internally >> if you need to change the interface that a new ID is needed and a new driver >> will >> be needed that comprehends that ID change. So if you can't guarantee that >> 0001 is >> the same driver interface in every firmware implementation google used then >> that is >> where this falls apart. >> As far as I know GGL0001 has the same driver interface in every firmware implementation Google used. But I'll ask to make sure. >> I know there is a long support lifecycle but you're talking about rebasing >> to new LTS kernels a handful of times between now and then. If the >> interface really >> is stable the patch should be small and it shouldn't be a large amount of >> technical >> debt to carry downstream until EOL. > > I think we are talking about different things actually. Let's forget > about Chrome OS and downstream kernels. We have devices that have > already been shipped and in hands of users. Some of them are old, some > of them are new. We can't not enforce that firmware for these devices > will be either released or updated. Therefore, if we want expose this > device in mainline kernel, we need to have it handle "GGL0001" HID in > addition to whatever proper HID we may select for it. > FWIW, after investigate a bit more, although GGL is not in the ACPI ID list it is in the PNP ID list [1]. So as far as I understand GGL0001 is valid ID. I know that PNP ID is the legacy identifier but since this was here for long time and will be here also for long time, I am wondering if we can take that as an argument to have GGL0001 as a valid device to be exposed in the kernel. Thanks, Enric [1] https://uefi.org/pnp_id_list > We internally can fix it (HID) for next generation of devices. > > Thanks. >
Re: [PATCH] Input: joystick - work around "adi" module name confict
On Tue, Jun 9, 2020 at 7:07 PM Arnd Bergmann wrote: > > Making module name conflicts a fatal error breaks sparc64 > allmodconfig: > > Error log: > error: the following would cause module name conflict: > drivers/char/adi.ko > drivers/input/joystick/adi.ko > > Renaming one of the modules would solve the problem, but then cause other > problems because neither of them is automatically loaded and changing > the name is likely to break any setup that relies on manually loading > it by name. > > As there is probably no sparc64 system with this kind of ancient joystick > attached, work around it by adding a Kconfig dependency that forbids > them from both being modules. It is still possible to build the joystick > driver if the sparc64 adi driver is built-in. > > Reported-by: Guenter Roeck > Acked-by: Greg Kroah-Hartman > Cc: Masahiro Yamada > Cc: Dmitry Torokhov > Cc: linux-in...@vger.kernel.org > Signed-off-by: Arnd Bergmann > --- > This should get merged through the kbuild tree together > with the patch that turns the warning into an error, if the > joystick maintainers are ok with the hack. Note: Dmitry picked up this patch. (commit 751ad34fbad74c3ed4a9ede24764b4253d4faa84) > --- > drivers/input/joystick/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/input/joystick/Kconfig b/drivers/input/joystick/Kconfig > index 940b744639c7..6f73f02059b5 100644 > --- a/drivers/input/joystick/Kconfig > +++ b/drivers/input/joystick/Kconfig > @@ -45,6 +45,7 @@ config JOYSTICK_A3D > config JOYSTICK_ADI > tristate "Logitech ADI digital joysticks and gamepads" > select GAMEPORT > + depends on ADI!=m # avoid module name conflict > help > Say Y here if you have a Logitech controller using the ADI > protocol over the PC gameport. > -- > 2.26.2 > -- Best Regards Masahiro Yamada
Re: [PATCH v3 1/4] fs, net: Standardize on file_receive helper to move fds across processes
On Thu, Jun 11, 2020 at 12:01:14PM +0200, Christian Brauner wrote:
> On Wed, Jun 10, 2020 at 07:59:55PM -0700, Kees Cook wrote:
> > On Wed, Jun 10, 2020 at 08:12:38AM +, Sargun Dhillon wrote:
> > > As an aside, all of this junk should be dropped:
> > > + ret = get_user(size, >size);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + ret = copy_struct_from_user(, sizeof(addfd), uaddfd, size);
> > > + if (ret)
> > > + return ret;
> > >
> > > and the size member of the seccomp_notif_addfd struct. I brought this up
> > > off-list with Tycho that ioctls have the size of the struct embedded in
> > > them. We
> > > should just use that. The ioctl definition is based on this[2]:
> > > #define _IOC(dir,type,nr,size) \
> > > (((dir) << _IOC_DIRSHIFT) | \
> > >((type) << _IOC_TYPESHIFT) | \
> > >((nr) << _IOC_NRSHIFT) | \
> > >((size) << _IOC_SIZESHIFT))
> > >
> > >
> > > We should just use copy_from_user for now. In the future, we can either
> > > introduce new ioctl names for new structs, or extract the size
> > > dynamically from
> > > the ioctl (and mask it out on the switch statement in
> > > seccomp_notify_ioctl.
> >
> > Yeah, that seems reasonable. Here's the diff for that part:
>
> Why does it matter that the ioctl() has the size of the struct embedded
> within? Afaik, the kernel itself doesn't do anything with that size. It
> merely checks that the size is not pathological and it does so at
> compile time.
>
> #ifdef __CHECKER__
> #define _IOC_TYPECHECK(t) (sizeof(t))
> #else
> /* provoke compile error for invalid uses of size argument */
> extern unsigned int __invalid_size_argument_for_IOC;
> #define _IOC_TYPECHECK(t) \
> ((sizeof(t) == sizeof(t[1]) && \
> sizeof(t) < (1 << _IOC_SIZEBITS)) ? \
> sizeof(t) : __invalid_size_argument_for_IOC)
> #endif
>
> The size itself is not verified at runtime. copy_struct_from_user()
> still makes sense at least if we're going to allow expanding the struct
> in the future.
Right, but if we simply change our headers and extend the struct, it will break
all existing programs compiled against those headers. In order to avoid that,
if
we intend on extending this struct by appending to it, we need to have a
backwards compatibility mechanism. Just having copy_struct_from_user isn't
enough. The data structure either must be fixed size, or we need a way to
handle
multiple ioctl numbers derived from headers with different sized struct
arguments
The two approaches I see are:
1. use more indirection. This has previous art in drm[1]. That's look
something like this:
struct seccomp_notif_addfd_ptr {
__u64 size;
__u64 addr;
}
... And then it'd be up to us to dereference the addr and copy struct from user.
2. Expose one ioctl to the user, many internally
e.g., public api:
struct seccomp_notif {
__u64 id;
__u64 pid;
struct seccomp_data;
__u64 fancy_new_field;
}
#define SECCOMP_IOCTL_NOTIF_RECVSECCOMP_IOWR(0, struct seccomp_notif)
internally:
struct seccomp_notif_v1 {
__u64 id;
__u64 pid;
struct seccomp_data;
}
struct seccomp_notif_v2 {
__u64 id;
__u64 pid;
struct seccomp_data;
__u64 fancy_new_field;
}
and we can switch like this:
switch (cmd) {
/* for example. We actually have to do this for any struct we intend to
* extend to get proper backwards compatibility
*/
case SECCOMP_IOWR(0, struct seccomp_notif_v1)
return seccomp_notify_recv(filter, buf, sizeof(struct
seccomp_notif_v1));
case SECCOMP_IOWR(0, struct seccomp_notif_v2)
return seccomp_notify_recv(filter, buf, sizeof(struct
seccomp_notif_v3));
...
case SECCOMP_IOCTL_NOTIF_SEND:
return seccomp_notify_send(filter, buf);
case SECCOMP_IOCTL_NOTIF_ID_VALID:
return seccomp_notify_id_valid(filter, buf);
default:
return -EINVAL;
}
This has the downside that programs compiled against more modern kernel headers
will break on older kernels.
3. We can take the approach you suggested.
#define UNSIZED(cmd)(cmd & ~(_IOC_SIZEMASK << _IOC_SIZESHIFT)
static long seccomp_notify_ioctl(struct file *file, unsigned int cmd,
unsigned long arg)
{
struct seccomp_filter *filter = file->private_data;
void __user *buf = (void __user *)arg;
int size = _IOC_SIZE(cmd);
cmd = UNSIZED(cmd);
switch (cmd) {
/* for example. We actually have to do this for any struct we intend to
* extend to get proper backwards compatibility
*/
case UNSIZED(SECCOMP_IOCTL_NOTIF_RECV):
return seccomp_notify_recv(filter, buf, size);
...
case SECCOMP_IOCTL_NOTIF_SEND:
return seccomp_notify_send(filter, buf);
case SECCOMP_IOCTL_NOTIF_ID_VALID:
Re: [RFC PATCH] ALSA: compress: Fix gapless playback state machine
On 11-06-20, 10:42, Charles Keepax wrote: > On Thu, Jun 11, 2020 at 03:14:23PM +0530, Vinod Koul wrote: > > On 11-06-20, 11:09, Jaroslav Kysela wrote: > > > Dne 11. 06. 20 v 10:46 Charles Keepax napsal(a): > > > > On Wed, Jun 10, 2020 at 04:28:20PM +0530, Vinod Koul wrote: > > > > > On 10-06-20, 12:40, Jaroslav Kysela wrote: > > > > > > Dne 10. 06. 20 v 12:07 Srinivas Kandagatla napsal(a): > > > > > > > Here is the sequence of events and state transitions: > > > > > > > > > > > > > > 1. set_params (Track 1), state = SNDRV_PCM_STATE_SETUP > > > > > > > 2. set_metadata (Track 1), no state change, state = > > > > > > > SNDRV_PCM_STATE_SETUP > > > > > > > 3. fill and trigger start (Track 1), state = > > > > > > > SNDRV_PCM_STATE_RUNNING > > > > > > > 4. set_next_track (Track 2), state = SNDRV_PCM_STATE_RUNNING > > > > > > > 5. partial_drain (Track 1), state = SNDRV_PCM_STATE_SETUP > > > > > > > 6 snd_compr_drain_notify (Track 1), state = SNDRV_PCM_STATE_SETUP > > > > > > > 7. fill data (Track 2), state = SNDRV_PCM_STATE_PREPARED > > > > > > > 8. set_metadata (Track 3), no state change, state = > > > > > > > SNDRV_PCM_STATE_PREPARED > > > > > > > 9. set_next_track (Track 3), !! FAILURE as state != > > > > > > > SNDRV_PCM_STATE_RUNNING > > Yeah sorry I overlooked that case and was thinking of it being invoked > > from driver! > > > > Yes this would make the snd_compr_stop() behave incorrectly.. so this > > cant be done as proposed. > > > > But we still need to set the draining stream state properly and I am > > thinking below now: > > > > diff --git a/sound/core/compress_offload.c b/sound/core/compress_offload.c > > index 509290f2efa8..9aba851732d7 100644 > > --- a/sound/core/compress_offload.c > > +++ b/sound/core/compress_offload.c > > @@ -929,7 +929,9 @@ static int snd_compr_partial_drain(struct > > snd_compr_stream *stream) > > } > > > > stream->next_track = false; > > - return snd_compress_wait_for_drain(stream); > > + retval = snd_compress_wait_for_drain(stream); > > + stream->runtime->state = SNDRV_PCM_STATE_RUNNING; > > + return retval; > > This is looking better, I think you probably need to make the > switch to RUNNING conditional on snd_compress_wait_for_drain > succeeding, as the state should remain in DRAINING if we are > interrupted or some such. Hmmm, only interrupt would be terminate, so yes we should not do running conditionally here.. > I also have a slight concern that since > snd_compress_wait_for_drain, releases the lock the set_next_track > could come in before the state is moved to RUNNING, but I guess > from user-spaces perspective that is the same as it coming in > whilst the state is still DRAINING, so should be handled fine? yeah userspace is blocked on this call, till signalling for partial drain is done. So it should work. But next_track 'should' be signalled before this, but yes we need to recheck this logic here and ensure no gaps are left in gapless :-) -- ~Vinod
Re: [f2fs-dev] [PATCH v2] f2fs: add F2FS_IOC_SEC_TRIM_FILE ioctl
2020년 6월 11일 (목) 오후 5:56, Chao Yu 님이 작성:
>
> On 2020/6/11 11:16, Daeho Jeong wrote:
> > From: Daeho Jeong
> >
> > Added a new ioctl to send discard commands or/and zero out
> > to whole data area of a regular file for security reason.
> >
> > Signed-off-by: Daeho Jeong
> > ---
> > fs/f2fs/f2fs.h | 8 +++
> > fs/f2fs/file.c | 143 +
> > 2 files changed, 151 insertions(+)
> >
> > diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> > index c812fb8e2d9c..ca139fac5a73 100644
> > --- a/fs/f2fs/f2fs.h
> > +++ b/fs/f2fs/f2fs.h
> > @@ -434,6 +434,7 @@ static inline bool __has_cursum_space(struct
> > f2fs_journal *journal,
> > _IOR(F2FS_IOCTL_MAGIC, 18, __u64)
> > #define F2FS_IOC_RESERVE_COMPRESS_BLOCKS \
> > _IOR(F2FS_IOCTL_MAGIC, 19, __u64)
> > +#define F2FS_IOC_SEC_TRIM_FILE _IOW(F2FS_IOCTL_MAGIC, 20,
> > __u32)
> >
> > #define F2FS_IOC_GET_VOLUME_NAME FS_IOC_GETFSLABEL
> > #define F2FS_IOC_SET_VOLUME_NAME FS_IOC_SETFSLABEL
> > @@ -453,6 +454,13 @@ static inline bool __has_cursum_space(struct
> > f2fs_journal *journal,
> > #define F2FS_GOING_DOWN_METAFLUSH0x3 /* going down with meta flush
> > */
> > #define F2FS_GOING_DOWN_NEED_FSCK0x4 /* going down to trigger fsck
> > */
> >
> > +/*
> > + * Flags used by F2FS_IOC_SEC_TRIM_FILE
> > + */
> > +#define F2FS_TRIM_FILE_DISCARD 0x1 /* send discard
> > command */
> > +#define F2FS_TRIM_FILE_ZEROOUT 0x2 /* zero out */
> > +#define F2FS_TRIM_FILE_MASK 0x3
> > +
> > #if defined(__KERNEL__) && defined(CONFIG_COMPAT)
> > /*
> > * ioctl commands in 32 bit emulation
> > diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
> > index dfa1ac2d751a..ba9b7ec5d6bf 100644
> > --- a/fs/f2fs/file.c
> > +++ b/fs/f2fs/file.c
> > @@ -3749,6 +3749,146 @@ static int f2fs_reserve_compress_blocks(struct file
> > *filp, unsigned long arg)
> > return ret;
> > }
> >
> > +static int f2fs_secure_erase(struct block_device *bdev, block_t block,
> > + block_t len, u32 flags)
> > +{
> > + struct request_queue *q = bdev_get_queue(bdev);
> > + sector_t sector = SECTOR_FROM_BLOCK(block);
> > + sector_t nr_sects = SECTOR_FROM_BLOCK(len);
> > + int ret = 0;
> > +
> > + if (!q)
> > + return -ENXIO;
> > +
> > + if (flags & F2FS_TRIM_FILE_DISCARD)
> > + ret = blkdev_issue_discard(bdev, sector, nr_sects, GFP_NOFS,
> > + blk_queue_secure_erase(q) ?
> > + BLKDEV_DISCARD_SECURE : 0);
> > +
> > + if (!ret && (flags & F2FS_TRIM_FILE_ZEROOUT))
> > + ret = blkdev_issue_zeroout(bdev, sector, nr_sects, GFP_NOFS,
> > 0);
> > +
> > + return ret;
> > +}
> > +
> > +static int f2fs_sec_trim_file(struct file *filp, unsigned long arg)
> > +{
> > + struct inode *inode = file_inode(filp);
> > + struct f2fs_sb_info *sbi = F2FS_I_SB(inode);
> > + struct address_space *mapping = inode->i_mapping;
> > + struct block_device *prev_bdev = NULL;
> > + pgoff_t index, pg_start = 0, pg_end;
> > + block_t prev_block = 0, len = 0;
> > + u32 flags;
> > + int ret = 0;
> > +
> > + if (!(filp->f_mode & FMODE_WRITE))
> > + return -EBADF;
> > +
> > + if (get_user(flags, (u32 __user *)arg))
> > + return -EFAULT;
> > + if (flags == 0 || (flags & ~F2FS_TRIM_FILE_MASK))
> > + return -EINVAL;
> > +
> > + if ((flags & F2FS_TRIM_FILE_DISCARD) && !f2fs_hw_support_discard(sbi))
> > + return -EOPNOTSUPP;
> > +
> > + file_start_write(filp);
>
> Now, I'm a little confused about when we need to call __mnt_want_write_file(),
> you know, vfs_write() still will call this function when updating time.
> - __generic_file_write_iter
> - file_update_time
> - __mnt_want_write_file
>
> And previously, f2fs ioctl uses mnt_{want,drop}_write_file() whenever there is
> any updates on fs/file, if Eric is correct, we need to clean up most of ioctl
> interface as well.
I also saw most filesytem codes use just mnt_{want,drop}_write_file()
and actually it doesn't affect code working. It's a matter of doing a
redundant job or not.
AFAIUI, if the file is not open for writing (FMODE_WRITE), we have to
call mnt_want_write_file() to increase mnt_writers.
In this case, we already checked it has FMODE_WRITE flag.
>
> > + inode_lock(inode);
> > +
> > + if (!S_ISREG(inode->i_mode) || f2fs_is_atomic_file(inode) ||
> > + f2fs_compressed_file(inode)) {
> > + ret = -EINVAL;
> > + goto err;
> > + }
> > +
> > + if (!inode->i_size)
> > + goto err;
> > + pg_end = DIV_ROUND_UP(inode->i_size, PAGE_SIZE);
> > +
> > + ret = f2fs_convert_inline_inode(inode);
> > + if (ret)
> >
Re: [PATCH 1/2] net: dsa: qca8k: Switch to PHYLINK instead of PHYLIB
On Thu, Jun 11, 2020 at 11:58:43AM +0300, Vladimir Oltean wrote:
> Hi Jonathan,
>
> On Wed, 10 Jun 2020 at 23:19, Jonathan McDowell wrote:
> >
> > Update the driver to use the new PHYLINK callbacks, removing the
> > legacy adjust_link callback.
> >
> > Signed-off-by: Jonathan McDowell
...
> > static void
> > -qca8k_adjust_link(struct dsa_switch *ds, int port, struct phy_device *phy)
> > +qca8k_phylink_mac_config(struct dsa_switch *ds, int port, unsigned int
> > mode,
> > +const struct phylink_link_state *state)
> > {
> > struct qca8k_priv *priv = ds->priv;
> > u32 reg;
> >
> > - /* Force fixed-link setting for CPU port, skip others. */
> > - if (!phy_is_pseudo_fixed_link(phy))
> > + switch (port) {
> > + case 0: /* 1st CPU port */
> > + if (state->interface != PHY_INTERFACE_MODE_RGMII &&
> > + state->interface != PHY_INTERFACE_MODE_RGMII_ID &&
> > + state->interface != PHY_INTERFACE_MODE_SGMII)
> > + return;
> > +
> > + reg = QCA8K_REG_PORT0_PAD_CTRL;
> > + break;
> > + case 1:
> > + case 2:
> > + case 3:
> > + case 4:
> > + case 5:
> > + /* Internal PHY, nothing to do */
> > + return;
> > + case 6: /* 2nd CPU port / external PHY */
> > + if (state->interface != PHY_INTERFACE_MODE_RGMII &&
> > + state->interface != PHY_INTERFACE_MODE_RGMII_ID &&
> > + state->interface != PHY_INTERFACE_MODE_SGMII &&
> > + state->interface != PHY_INTERFACE_MODE_1000BASEX)
> > + return;
> > +
> > + reg = QCA8K_REG_PORT6_PAD_CTRL;
> > + break;
> > + default:
> > + dev_err(ds->dev, "%s: unsupported port: %i\n", __func__,
> > port);
> > + return;
> > + }
> > +
> > + if (port != 6 && phylink_autoneg_inband(mode)) {
> > + dev_err(ds->dev, "%s: in-band negotiation unsupported\n",
> > + __func__);
> > + return;
> > + }
> > +
> > + switch (state->interface) {
> > + case PHY_INTERFACE_MODE_RGMII:
> > + /* RGMII mode means no delay so don't enable the delay */
> > + qca8k_write(priv, reg, QCA8K_PORT_PAD_RGMII_EN);
> > + break;
> > + case PHY_INTERFACE_MODE_RGMII_ID:
> > + /* RGMII_ID needs internal delay. This is enabled through
> > +* PORT5_PAD_CTRL for all ports, rather than individual port
> > +* registers
> > +*/
> > + qca8k_write(priv, reg,
> > + QCA8K_PORT_PAD_RGMII_EN |
> > + QCA8K_PORT_PAD_RGMII_TX_DELAY(QCA8K_MAX_DELAY) |
> > + QCA8K_PORT_PAD_RGMII_RX_DELAY(QCA8K_MAX_DELAY));
>
> 3 points here:
> - Should you prevalidate the device tree bindings that in case rgmii*
> mode are used, same delay settings are applied to all ports?
> - Can any RGMII port be connected to a PHY? If it can, won't the PHY
> enable delays too for RGMII_ID? Will the link work in that case?
> - Should you treat RGMII_TX_DELAY and RGMII_RX_DELAY independently for
> the case where there may be PCB traces?
The intent with this patch was to pull out the conversion to PHYLINK to
be stand-alone, with no functional changes, as request by Andrew. I
think there's room for some future clean-up here around the RGMII
options, but my main purpose in this patch set is to improve the SGMII
portion which my hardware uses that doesn't work with mainline.
> > +static void
> > +qca8k_phylink_validate(struct dsa_switch *ds, int port,
> > + unsigned long *supported,
> > + struct phylink_link_state *state)
> > +{
> > + __ETHTOOL_DECLARE_LINK_MODE_MASK(mask) = { 0, };
> > +
> > + switch (port) {
> > + case 0: /* 1st CPU port */
> > + if (state->interface != PHY_INTERFACE_MODE_NA &&
> > + state->interface != PHY_INTERFACE_MODE_RGMII &&
> > + state->interface != PHY_INTERFACE_MODE_RGMII_ID &&
> > + state->interface != PHY_INTERFACE_MODE_SGMII)
> > + goto unsupported;
> > break;
> > - case 100:
> > - reg = QCA8K_PORT_STATUS_SPEED_100;
> > + case 1:
> > + case 2:
> > + case 3:
> > + case 4:
> > + case 5:
> > + /* Internal PHY */
> > + if (state->interface != PHY_INTERFACE_MODE_NA &&
> > + state->interface != PHY_INTERFACE_MODE_GMII)
> > + goto unsupported;
> > break;
> > - case 1000:
> > - reg = QCA8K_PORT_STATUS_SPEED_1000;
> > + case 6: /* 2nd CPU port / external PHY */
> > + if
Re: [PATCH 6/6] spi: altera: fix size mismatch on 64 bit processors
On Thu, Jun 11, 2020 at 11:25:11AM +0800, Xu Yilun wrote: > From: Matthew Gerlach > > The spi-altera driver was originally written with a 32 > bit processor, where sizeof(unsigned long) is 4. On a > 64 bit processor sizeof(unsigned long) is 8. Change the structure > member to u32 to match the actual size of the control > register. > > Signed-off-by: Matthew Gerlach > --- You've not provided a Signed-off-by for this, I can't do anything with it. For details on what Signed-off-by means and why it's important please see Documentation/process/submitting-patches.rst. signature.asc Description: PGP signature
Re: [PATCH] crypto: talitos - fix ECB and CBC algs ivsize
On Thu, Jun 11, 2020 at 12:50:24PM +0200, Christophe Leroy wrote:
> Hi,
>
> Le 11/06/2020 à 12:07, Su Kang Yin a écrit :
> > Patch for 4.9 upstream:
> >
> > commit e1de42fdfc6a ("crypto: talitos - fix ECB algs ivsize")
> > wrongly modified CBC algs ivsize instead of ECB aggs ivsize.
>
> To make it clear and avoid this problem to happen again, please generate
> your patch with option -U8
No need, this patch should be fine as-is.
thanks,
greg k-h
Re: linux-next: manual merge of the tip tree with Linus' tree
Hi Thomas, On Thu, 11 Jun 2020 12:43:24 +0200 Thomas Gleixner wrote: > > Sorry for that inconveniance. I'm about to get rid of the conflicts on > the tip side. Thanks. I do realise that it can take a little while between when Linus adds something to his tree and previous versions get purged. It doesn't happen to much, thankfully. -- Cheers, Stephen Rothwell pgpVjhxoaP_Vh.pgp Description: OpenPGP digital signature
Re: [PATCH] cros_ec_spi: Even though we're RT priority, don't bump cpu freq
Hi Doug, On Wednesday 10 Jun 2020 at 15:18:43 (-0700), Douglas Anderson wrote: > The cros_ec_spi driver is realtime priority so that it doesn't get > preempted by other taks while it's talking to the EC but overall it > really doesn't need lots of compute power. Unfortunately, by default, > the kernel assumes that all realtime tasks should cause the cpufreq to > jump to max and burn through power to get things done as quickly as > possible. That's just not the correct behavior for cros_ec_spi. Is this specific to this driver, or something you would want applied more globally to all RT tasks in ChromeOS (which is what we'd like to have in Android for instance)? IOW, how do you feel about 20200511154053.7822-1-qais.you...@arm.com ? Otherwise, the patch looks good to me. Thanks, Quentin
Re: [RFC PATCH] ALSA: compress: Fix gapless playback state machine
On 11-06-20, 12:40, Jaroslav Kysela wrote: > Dne 11. 06. 20 v 11:44 Vinod Koul napsal(a): > > On 11-06-20, 11:09, Jaroslav Kysela wrote: > > > Dne 11. 06. 20 v 10:46 Charles Keepax napsal(a): > > > > On Wed, Jun 10, 2020 at 04:28:20PM +0530, Vinod Koul wrote: > > > > > On 10-06-20, 12:40, Jaroslav Kysela wrote: > > > > > > Dne 10. 06. 20 v 12:07 Srinivas Kandagatla napsal(a): > > > > > > > For gapless playback call to snd_compr_drain_notify() after > > > > > > > partial drain should put the state to SNDRV_PCM_STATE_RUNNING > > > > > > > rather than SNDRV_PCM_STATE_SETUP as the driver is ready to > > > > > > > process the buffers for new track. > > > > > > > > > > > > > > With existing code, if we are playing 3 tracks in gapless, after > > > > > > > partial drain finished on previous track 1 the state is set to > > > > > > > SNDRV_PCM_STATE_SETUP which is then moved to > > > > > > > SNDRV_PCM_STATE_PREPARED > > > > > > > after data write. With this state calls to snd_compr_next_track() > > > > > > > and > > > > > > > few other calls will fail as they expect the state to be in > > > > > > > SNDRV_PCM_STATE_RUNNING. > > > > > > > > > > > > > > Here is the sequence of events and state transitions: > > > > > > > > > > > > > > 1. set_params (Track 1), state = SNDRV_PCM_STATE_SETUP > > > > > > > 2. set_metadata (Track 1), no state change, state = > > > > > > > SNDRV_PCM_STATE_SETUP > > > > > > > 3. fill and trigger start (Track 1), state = > > > > > > > SNDRV_PCM_STATE_RUNNING > > > > > > > 4. set_next_track (Track 2), state = SNDRV_PCM_STATE_RUNNING > > > > > > > 5. partial_drain (Track 1), state = SNDRV_PCM_STATE_SETUP > > > > > > > 6 snd_compr_drain_notify (Track 1), state = SNDRV_PCM_STATE_SETUP > > > > > > > 7. fill data (Track 2), state = SNDRV_PCM_STATE_PREPARED > > > > > > > 8. set_metadata (Track 3), no state change, state = > > > > > > > SNDRV_PCM_STATE_PREPARED > > > > > > > 9. set_next_track (Track 3), !! FAILURE as state != > > > > > > > SNDRV_PCM_STATE_RUNNING > > > > > > > > > > > > > > > > > > The snd_compr_drain_notify() is called only from snd_compr_stop(). > > > > > > Something > > > > > > is missing in this sequence? > > > > > > > > > > It is supposed to be invoked by driver when partial drain is > > > > > complete.. > > > > > both intel and sprd driver are calling this. snd_compr_stop is stop > > > > > while draining case so legit > > > > > > > > > > > > > Not sure I follow this statement, could you elaborate a bit? > > > > snd_compr_stop putting the state to RUNNING seems fundamentally > > > > broken to me, the whole point of snd_compr_stop is to take the > > > > state out of RUNNING. > > > > > > Yes. I agree. It seems that the acknowledge for the partial drain should > > > be > > > handled differently. > > > > Yeah sorry I overlooked that case and was thinking of it being invoked > > from driver! > > > > Yes this would make the snd_compr_stop() behave incorrectly.. so this > > cant be done as proposed. > > > > But we still need to set the draining stream state properly and I am > > thinking below now: > > > > diff --git a/sound/core/compress_offload.c b/sound/core/compress_offload.c > > index 509290f2efa8..9aba851732d7 100644 > > --- a/sound/core/compress_offload.c > > +++ b/sound/core/compress_offload.c > > @@ -929,7 +929,9 @@ static int snd_compr_partial_drain(struct > > snd_compr_stream *stream) > > } > > stream->next_track = false; > > - return snd_compress_wait_for_drain(stream); > > + retval = snd_compress_wait_for_drain(stream); > > + stream->runtime->state = SNDRV_PCM_STATE_RUNNING; > > + return retval; > > } > > I see a race possibility when the last track is too small and the driver > signals the end-of-track twice. In this case the partial drain should not > end with the running state. It would be probably better to separate partial > / last track acknowledgements. I completely agree that we should have separate acknowledgements here, and going to rethink all state transitions for gapless here.. Thanks for the help -- ~Vinod
Re: [PATCH] Replace HTTP links with HTTPS ones: Documentation/translations/it_IT
Am 11.06.20 um 12:40 schrieb Miguel Ojeda:
On Thu, Jun 11, 2020 at 9:02 AM Alexander A. Klimov
wrote:
Is any of you familiar with Golang?
Don't worry about that! I'd expect seasoned C programmers to be able
to read Go (or near languages) -- at least to have a general idea of
what an algorithm does.
It is not APL, after all :-)
Fine.
package main
import (
"bufio"
"bytes"
"context"
"errors"
"fmt"
fatomic "github.com/natefinch/atomic"
"golang.org/x/sync/semaphore"
"io"
"io/ioutil"
"net/http"
"os"
"os/exec"
"regexp"
"runtime"
"sync"
"sync/atomic"
"time"
)
var fileSemaphore = semaphore.NewWeighted(int64(runtime.NumCPU()) * 16)
var wg sync.WaitGroup
var processingFiles = struct {
sync.RWMutex
files map[string]struct{}
}{
files: map[string]struct{}{},
}
func main() {
cmd := exec.Command("git", "ls-files", "-sz")
cmd.Stderr = os.Stderr
out, errSP := cmd.StdoutPipe()
if errSP != nil {
fmt.Fprintln(os.Stderr, errSP.Error())
os.Exit(1)
}
if errSt := cmd.Start(); errSt != nil {
fmt.Fprintln(os.Stderr, errSt.Error())
os.Exit(1)
}
//go printProcessingFiles()
buf := bufio.NewReader(out)
for {
file, errRB := buf.ReadBytes(0)
if errRB != nil && errRB != io.EOF {
if errWt := cmd.Wait(); errWt != nil {
fmt.Fprintln(os.Stderr, errWt.Error())
wg.Wait()
os.Exit(1)
}
fmt.Fprintln(os.Stderr, errRB.Error())
wg.Wait()
os.Exit(1)
}
if bytes.HasPrefix(file, []byte{'1', '0', '0'}) {
if fields := bytes.SplitN(bytes.SplitN(file, []byte{0}, 2)[0],
[]byte{9}, 2); len(fields) == 2 {
_ = fileSemaphore.Acquire(context.Background(),
1)
wg.Add(1)
go processFile(string(fields[1]))
}
}
if errRB == io.EOF {
break
}
}
wg.Wait()
if errWt := cmd.Wait(); errWt != nil {
fmt.Fprintln(os.Stderr, errWt.Error())
os.Exit(1)
}
}
/*
func printProcessingFiles() {
for {
time.Sleep(time.Second)
processingFiles.RLock()
fmt.Fprintln(os.Stderr, processingFiles.files)
processingFiles.RUnlock()
}
}
*/
var httpLink = regexp.MustCompile(`\bhttp://[^# \t\r\n]*(?:\w|/)`)
var xmlns = regexp.MustCompile(`\bxmlns\b`)
func processFile(file string) error {
defer fileSemaphore.Release(1)
defer wg.Done()
processingFiles.Lock()
processingFiles.files[file] = struct{}{}
processingFiles.Unlock()
defer func() {
processingFiles.Lock()
delete(processingFiles.files, file)
processingFiles.Unlock()
}()
content, errRF := ioutil.ReadFile(file)
if errRF != nil {
return errRF
}
lines := bytes.Split(content, []byte{'\n'})
for i := range lines {
if !xmlns.Match(lines[i]) {
lines[i] = httpLink.ReplaceAllFunc(lines[i],
processLink)
}
}
if modified := bytes.Join(lines, []byte{'\n'}); bytes.Compare(modified,
content) != 0 {
var buf bytes.Buffer
buf.Write(modified)
return fatomic.WriteFile(file, )
}
return nil
}
type linkOk struct {
sync.Mutex
ok uint32
}
var links = map[string]*linkOk{}
var linksLock sync.RWMutex
var notsecure = http.Client{Timeout: 10 * time.Minute}
var secure = http.Client{Timeout: 10 * time.Minute, CheckRedirect:
httpsRedirect}
func processLink(link []byte) []byte {
linkStr := string(bytes.TrimPrefix(link, []byte("http://;)))
linksLock.RLock()
lo, ok := links[linkStr]
linksLock.RUnlock()
if !ok {
linksLock.Lock()
lo, ok = links[linkStr]
if !ok {
lo = {}
links[linkStr] = lo
}
linksLock.Unlock()
}
for {
switch atomic.LoadUint32() {
case 0:
lo.Lock()
if atomic.LoadUint32() == 0 {
if httpsAble(linkStr) {
atomic.StoreUint32(, 2)
} else {
vdso_join_timens() question
Hey,
I'm about to finish a patch to add CLONE_NEWTIME support to setns().
Since setns() now allows to attach to a multiple namespaces at the same
time I've also reworked it to be atomic (already upstream). Either all
namespaces are switched or no namespace is switched. All namespaces
basically now have a commit mode after which installation should ideally
not fail anymore. That could work for CLONE_NEWTIME too, I think. The
only blocker to this is vdso_join_timens() which can fail due to
mmap_write_lock_killable().
Is it possible to change this to mmap_write_lock()? So sm like:
diff --git a/arch/x86/entry/vdso/vma.c b/arch/x86/entry/vdso/vma.c
index ea7c1f0b79df..5c5b4cc61fce 100644
--- a/arch/x86/entry/vdso/vma.c
+++ b/arch/x86/entry/vdso/vma.c
@@ -144,8 +144,7 @@ int vdso_join_timens(struct task_struct *task, struct
time_namespace *ns)
struct mm_struct *mm = task->mm;
struct vm_area_struct *vma;
- if (mmap_write_lock_killable(mm))
- return -EINTR;
+ mmap_write_lock(mm);
for (vma = mm->mmap; vma; vma = vma->vm_next) {
unsigned long size = vma->vm_end - vma->vm_start;
vdso_join_timens() is called in two places. Once during fork() and once
during timens_install(). I would only need the mmap_write_lock() change
for the latter. So alternatively we could have:
__vdso_join_timens_unlocked()
and then have/expose:
vdso_join_timens_fork()
{
if (mmap_write_lock_killable(mm))
return -EINTR;
__vdso_join_timens_unlocked()
mmap_write_unlock(mm);
}
and
vdso_join_timens_install()
{
mmap_write_lock(mm);
__vdso_join_timens_unlocked()
mmap_write_unlock(mm);
}
Thanks!
Christian
Re: [PATCH 4/6] spi: altera: use regmap instead of direct mmio register access
On Thu, Jun 11, 2020 at 11:25:09AM +0800, Xu Yilun wrote:
> + if (pdata && pdata->use_parent_regmap) {
> + hw->regmap = dev_get_regmap(pdev->dev.parent, NULL);
> + if (!hw->regmap) {
> + dev_err(>dev, "get regmap failed\n");
> + goto exit;
> + }
> + hw->base = pdata->regoff;
This seems very confused - there's some abstraction problem here. This
looks like the driver should know about whatever is causing it to use
the parent regmap, it shouldn't just be "use the parent regmap" directly
since that is too much of an implementation detail. This new feature
also seems like a separate change which should be in a separate patch,
the changelog only talked about converting to use regmap which I'd have
expected to be a straight 1:1 replacement of non-regmap stuff with
regmap stuff.
signature.asc
Description: PGP signature
Re: [PATCH 2/2] soc: mediatek: devapc: add devapc-mt6873 driver
Hi, Neal:
Neal Liu 於 2020年6月11日 週四 下午5:26寫道：
>
> On Wed, 2020-06-10 at 00:01 +0800, Chun-Kuang Hu wrote:
> Hi Chun-Kuang,
>
> [snip]
>
> > > +
> > > +/*
> > > + * mtk_devapc_pd_get - get devapc pd_types of register address.
> > > + *
> > > + * Returns the value of reg addr
> > > + */
> > > +static void __iomem *mtk_devapc_pd_get(int slave_type,
> > > + enum DEVAPC_PD_REG_TYPE
> > > pd_reg_type,
> > > + u32 index)
> > > +{
> > > + struct mtk_devapc_vio_info *vio_info =
> > > mtk_devapc_ctx->soc->vio_info;
> > > + u32 slave_type_num = mtk_devapc_ctx->soc->slave_type_num;
> > > + const u32 *devapc_pds = mtk_devapc_ctx->soc->devapc_pds;
> > > + void __iomem *reg;
> > > +
> > > + if (!devapc_pds)
> > > + return NULL;
> > > +
> > > + if ((slave_type < slave_type_num &&
> > > +index < vio_info->vio_mask_sta_num[slave_type]) &&
> > > + pd_reg_type < PD_REG_TYPE_NUM) {
> > > + reg = mtk_devapc_ctx->devapc_pd_base[slave_type] +
> > > + devapc_pds[pd_reg_type];
> > > +
> > > + if (pd_reg_type == VIO_MASK || pd_reg_type == VIO_STA)
> > > + reg += 0x4 * index;
> > > +
> > > + } else {
> > > + pr_err(PFX "%s:0x%x or %s:0x%x or %s:0x%x is out of
> > > boundary\n",
> > > + "slave_type", slave_type,
> >
> > Move "slave_type" into format string.
>
> Why is this necessary? Is there any benefit for moving this?
Smaller code size, simple, intuition.
> Since the line length is almost over 80 chars.
Single string could be over 80 chars.
>
> >
> > > + "pd_reg_type", pd_reg_type,
> > > + "index", index);
> > > + return NULL;
> > > + }
> > > +
> > > + return reg;
> > > +}
> > > +
> >
>
> [snip]
>
> >
> > > +
> > > +/*
> > > + * devapc_violation_irq - the devapc Interrupt Service Routine (ISR)
> > > will dump
> > > + * violation information including which master
> > > violates
> > > + * access slave.
> > > + */
> > > +static irqreturn_t devapc_violation_irq(int irq_number, void *dev_id)
> > > +{
> > > + u32 slave_type_num = mtk_devapc_ctx->soc->slave_type_num;
> > > + const struct mtk_device_info **device_info;
> > > + struct mtk_devapc_vio_info *vio_info;
> > > + int slave_type, vio_idx, index;
> > > + const char *vio_master;
> > > + unsigned long flags;
> > > + bool normal;
> > > + u8 perm;
> > > +
> > > + spin_lock_irqsave(_lock, flags);
> > > +
> > > + device_info = mtk_devapc_ctx->soc->device_info;
> > > + vio_info = mtk_devapc_ctx->soc->vio_info;
> > > + normal = false;
> > > + vio_idx = -1;
> > > + index = -1;
> > > +
> > > + /* There are multiple DEVAPC_PD */
> > > + for (slave_type = 0; slave_type < slave_type_num; slave_type++) {
> > > + if (!check_type2_vio_status(slave_type, _idx, ))
> > > + if (!mtk_devapc_dump_vio_dbg(slave_type, _idx,
> > > +))
> > > + continue;
> > > +
> > > + /* Ensure that violation info are written before
> > > +* further operations
> > > +*/
> > > + smp_mb();
> > > + normal = true;
> > > +
> > > + mask_module_irq(slave_type, vio_idx, true);
> > > +
> > > + if (clear_vio_status(slave_type, vio_idx))
> > > + pr_warn(PFX "%s, %s:0x%x, %s:0x%x\n",
> > > + "clear vio status failed",
> > > + "slave_type", slave_type,
> > > + "vio_index", vio_idx);
> > > +
> > > + perm = get_permission(slave_type, index,
> > > vio_info->domain_id);
> > > +
> > > + vio_master = mtk_devapc_ctx->soc->master_get
> > > + (vio_info->master_id,
> > > +vio_info->vio_addr,
> > > +slave_type,
> > > +vio_info->shift_sta_bit,
> > > +vio_info->domain_id);
> >
> > Call mt6873_bus_id_to_master() directly. For first patch, make things
> > as simple as possible.
>
> In devapc_violation_irq() function, we use common flow to handle each
> devapc violation on different platforms. The master_get() has different
> implementation on different platforms, that why it called indirectly.
>
> Once we have new platform, we only have to update devapc-mt.c
> instead of common handler flow.
You just upstream one SoC now, so I have no information of 2nd SoC.
Without the 2nd SoC, how do we know what is common and what is SoC special?
So the first patch should not consider the things which does not exist yet.
Re: [PATCH v1] virtio-mem: add memory via add_memory_driver_managed()
>> I'd like to have this patch in 5.8, with the initial merge of virtio-mem
>> if possible (so the user space representation of virtio-mem added memory
>> resources won't change anymore).
>
> So my plan is to rebase on top of -rc1 and merge this for rc2 then.
> I don't like rebase on top of tip as the results are sometimes kind of
> random.
Right, I just wanted to get this out early so we can discuss how to proceed.
> And let's add a Fixes: tag as well, this way people will remember to
> pick this.
> Makes sense?
Yes, it's somehow a fix (for kexec). So
Fixes: 5f1f79bbc9e26 ("virtio-mem: Paravirtualized memory hotplug")
I can respin after -rc1 with the commit id fixed as noted by Pankaj.
Just let me know what you prefer.
Thanks!
--
Thanks,
David / dhildenb
Re: [PATCH? v2] powerpc: Hard wire PT_SOFTE value to 1 in gpr_get() too
On 06/11, Madhavan Srinivasan wrote: > > > On 6/10/20 8:37 PM, Oleg Nesterov wrote: > >Hi, > > > >looks like this patch was forgotten. > > yep, I missed this. But mpe did have comments for the patch. > > https://lkml.org/lkml/2019/9/19/107 Yes, and I thought that I have replied... apparently not, sorry! So let me repeat, I am fine either way, I do not understand this ppc-specific code and I can't really test this change. Let me quote that email from Michael: > We could do it like below. I'm 50/50 though on whether it's worth it, or > if we should just go with the big ifdef like in your patch. up to you ;) Hmm. And yes, > >>This is not consistent and this breaks > >>http://sourceware.org/systemtap/wiki/utrace/tests/user-regs-peekpoke this is 404. Jan, could correct the link above? Oleg.
Re: [PATCH 1/2] sched/uclamp: Add a new sysctl to control RT default boost value
On 06/04/20 14:40, Mel Gorman wrote: > On Wed, Jun 03, 2020 at 01:41:13PM +0100, Qais Yousef wrote: > > > > netperf-udp > > > > ./5.7.0-rc7./5.7.0-rc7 > > > > ./5.7.0-rc7 > > > > without-clamp with-clamp > > > > with-clamp-tskgrp > > > > > > > > Hmean send-64 153.62 ( 0.00%) 151.80 * -1.19%* > > > > 155.60 * 1.28%* > > > > Hmean send-128306.77 ( 0.00%) 306.27 * -0.16%* > > > > 309.39 * 0.85%* > > > > Hmean send-256608.54 ( 0.00%) 604.28 * -0.70%* > > > > 613.42 * 0.80%* > > > > Hmean send-1024 2395.80 ( 0.00%) 2365.67 * -1.26%* > > > > 2409.50 * 0.57%* > > > > Hmean send-2048 4608.70 ( 0.00%) 4544.02 * -1.40%* > > > > 4665.96 * 1.24%* > > > > Hmean send-3312 7223.97 ( 0.00%) 7158.88 * -0.90%* > > > > 7331.23 * 1.48%* > > > > Hmean send-4096 8729.53 ( 0.00%) 8598.78 * -1.50%* > > > > 8860.47 * 1.50%* > > > > Hmean send-8192 14961.77 ( 0.00%)14418.92 * -3.63%* > > > > 14908.36 * -0.36%* > > > > Hmean send-1638425799.50 ( 0.00%)25025.64 * -3.00%* > > > > 25831.20 * 0.12%* > > > > Hmean recv-64 153.62 ( 0.00%) 151.80 * -1.19%* > > > > 155.60 * 1.28%* > > > > Hmean recv-128306.77 ( 0.00%) 306.27 * -0.16%* > > > > 309.39 * 0.85%* > > > > Hmean recv-256608.54 ( 0.00%) 604.28 * -0.70%* > > > > 613.42 * 0.80%* > > > > Hmean recv-1024 2395.80 ( 0.00%) 2365.67 * -1.26%* > > > > 2409.50 * 0.57%* > > > > Hmean recv-2048 4608.70 ( 0.00%) 4544.02 * -1.40%* > > > > 4665.95 * 1.24%* > > > > Hmean recv-3312 7223.97 ( 0.00%) 7158.88 * -0.90%* > > > > 7331.23 * 1.48%* > > > > Hmean recv-4096 8729.53 ( 0.00%) 8598.78 * -1.50%* > > > > 8860.47 * 1.50%* > > > > Hmean recv-8192 14961.61 ( 0.00%)14418.88 * -3.63%* > > > > 14908.30 * -0.36%* > > > > Hmean recv-1638425799.39 ( 0.00%)25025.49 * -3.00%* > > > > 25831.00 * 0.12%* > > > > > > > > netperf-tcp > > > > > > > > Hmean 64 818.65 ( 0.00%) 812.98 * -0.69%* > > > > 826.17 * 0.92%* > > > > Hmean 1281569.55 ( 0.00%) 1555.79 * -0.88%* > > > > 1586.94 * 1.11%* > > > > Hmean 2562952.86 ( 0.00%) 2915.07 * -1.28%* > > > > 2968.15 * 0.52%* > > > > Hmean 1024 10425.91 ( 0.00%)10296.68 * -1.24%* > > > > 10418.38 * -0.07%* > > > > Hmean 2048 17454.51 ( 0.00%)17369.57 * -0.49%* > > > > 17419.24 * -0.20%* > > > > Hmean 3312 22509.95 ( 0.00%)9.69 * -1.25%* > > > > 22373.32 * -0.61%* > > > > Hmean 4096 25033.23 ( 0.00%)24859.59 * -0.69%* > > > > 24912.50 * -0.48%* > > > > Hmean 8192 32080.51 ( 0.00%)31744.51 * -1.05%* > > > > 31800.45 * -0.87%* > > > > Hmean 16384 36531.86 ( 0.00%)37064.68 * 1.46%* > > > > 37397.71 * 2.37%* > > > > > > > > The diffs are smaller than on openSUSE Leap 15.1 and some of the > > > > uclamp taskgroup results are better? > > > > > > > > > > I don't see the stddev and coeff but these look close to borderline. > > > Sure, they are marked with a * so it passed a significant test but it's > > > still a very marginal difference for netperf. It's possible that the > > > systemd configurations differ in some way that is significant for uclamp > > > but I don't know what that is. > > > > Hmm so what you're saying is that Dietmar didn't reproduce the same problem > > you're observing? I was hoping to use that to dig more into it. > > > > Not as such, I'm saying that for whatever reason the problem is not as > visible with Dietmar's setup. It may be machine-specific or distribution > specific. There are alternative suggestions for testing just the fast > paths with a pipe test that may be clearer. I have regained access to the same machine Dietmar ran his tests on. And I got some weird results to share.. First I tried with `perf bench -r 20 sched pipe -T` command to identify the cause of the overhead. And indeed I do see the activate/deactivate_task overhead going up when uclamp is enabled With uclamp run #1: 2.44% sched-pipe [kernel.vmlinux] [k] activate_task 1.59% sched-pipe [kernel.vmlinux] [k] deactivate_task With uclamp run #2: 4.55% sched-pipe [kernel.vmlinux] [k] deactivate_task 2.34% sched-pipe [kernel.vmlinux] [k] activate_task Without uclamp run #1: 0.12% sched-pipe [kernel.vmlinux] [k] activate_task 0.11% sched-pipe [kernel.vmlinux] [k] deactivate_task Without uclamp run #2: 0.11% sched-pipe [kernel.vmlinux] [k] activate_task
Re: [PATCH v1] virtio-mem: add memory via add_memory_driver_managed()
On 11.06.20 12:32, Pankaj Gupta wrote:
>> Virtio-mem managed memory is always detected and added by the virtio-mem
>> driver, never using something like the firmware-provided memory map.
>> This is the case after an ordinary system reboot, and has to be guaranteed
>> after kexec. Especially, virtio-mem added memory resources can contain
>> inaccessible parts ("unblocked memory blocks"), blindly forwarding them
>> to a kexec kernel is dangerous, as unplugged memory will get accessed
>> (esp. written).
>>
>> Let's use the new way of adding special driver-managed memory introduced
>> in commit 75ac4c58bc0d ("mm/memory_hotplug: introduce
>> add_memory_driver_managed()").
>
> Is this commit id correct?
Good point, it's the one from next-20200605.
7b7b27214bba
Is the correct one.
[...]
>
> Looks good to me.
> Reviewed-by: Pankaj Gupta
>
Thanks!
--
Thanks,
David / dhildenb
Re: slub freelist issue / BUG: unable to handle page fault for address: 000000003ffe0018
On 6/11/20 3:40 AM, Kaneda, Erik wrote:
> We'll take this patch for ACPICA and it will be in the next release.
>
> Rafael, do you want to take this as a part of the next rc? Or should we wait
> for the next merge window?
IMHO this should rather be fixed in 5.8 with CC stable, not next merge window.
> Thanks,
> Erik
>>
>> diff --git a/drivers/acpi/acpica/nsaccess.c b/drivers/acpi/acpica/nsaccess.c
>> index 2566e2d4c7803..b76bbab917941 100644
>> --- a/drivers/acpi/acpica/nsaccess.c
>> +++ b/drivers/acpi/acpica/nsaccess.c
>> @@ -98,14 +98,12 @@ acpi_status acpi_ns_root_initialize(void)
>> * predefined names are at the root level. It is much
>> easier to
>> * just create and link the new node(s) here.
>> */
>> - new_node =
>> - ACPI_ALLOCATE_ZEROED(sizeof(struct
>> acpi_namespace_node));
>> + new_node = acpi_ns_create_node(*ACPI_CAST_PTR (u32,
>> init_val->name));
>> if (!new_node) {
>> status = AE_NO_MEMORY;
>> goto unlock_and_exit;
>> }
>>
>> - ACPI_COPY_NAMESEG(new_node->name.ascii, init_val->name);
>> new_node->descriptor_type = ACPI_DESC_TYPE_NAMED;
>> new_node->type = init_val->type;
>>
>>
>> Vegard
>
Re: [PATCH] iov_iter: Move unnecessary inclusion of crypto/hash.h
Hi Herbert,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v5.7 next-20200611]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Herbert-Xu/iov_iter-Move-unnecessary-inclusion-of-crypto-hash-h/20200611-154742
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
b29482fde649c72441d5478a4ea2c52c56d97a5e
config: x86_64-randconfig-m001-20200611 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-13) 9.3.0
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All error/warnings (new ones prefixed by >>, old ones prefixed by <<):
drivers/mtd/mtdpstore.c: In function 'mtdpstore_notify_add':
>> drivers/mtd/mtdpstore.c:419:15: error: implicit declaration of function
>> 'kcalloc' [-Werror=implicit-function-declaration]
419 | cxt->rmmap = kcalloc(longcnt, sizeof(long), GFP_KERNEL);
| ^~~
>> drivers/mtd/mtdpstore.c:419:13: warning: assignment to 'long unsigned int *'
>> from 'int' makes pointer from integer without a cast [-Wint-conversion]
419 | cxt->rmmap = kcalloc(longcnt, sizeof(long), GFP_KERNEL);
| ^
drivers/mtd/mtdpstore.c:420:15: warning: assignment to 'long unsigned int *'
from 'int' makes pointer from integer without a cast [-Wint-conversion]
420 | cxt->usedmap = kcalloc(longcnt, sizeof(long), GFP_KERNEL);
| ^
drivers/mtd/mtdpstore.c:423:14: warning: assignment to 'long unsigned int *'
from 'int' makes pointer from integer without a cast [-Wint-conversion]
423 | cxt->badmap = kcalloc(longcnt, sizeof(long), GFP_KERNEL);
| ^
drivers/mtd/mtdpstore.c: In function 'mtdpstore_flush_removed_do':
>> drivers/mtd/mtdpstore.c:452:8: error: implicit declaration of function
>> 'kmalloc' [-Werror=implicit-function-declaration]
452 | buf = kmalloc(mtd->erasesize, GFP_KERNEL);
|^~~
>> drivers/mtd/mtdpstore.c:452:6: warning: assignment to 'u_char *' {aka
>> 'unsigned char *'} from 'int' makes pointer from integer without a cast
>> [-Wint-conversion]
452 | buf = kmalloc(mtd->erasesize, GFP_KERNEL);
| ^
>> drivers/mtd/mtdpstore.c:485:2: error: implicit declaration of function
>> 'kfree' [-Werror=implicit-function-declaration]
485 | kfree(buf);
| ^
cc1: some warnings being treated as errors
--
drivers/dma/sf-pdma/sf-pdma.c: In function 'sf_pdma_alloc_desc':
>> drivers/dma/sf-pdma/sf-pdma.c:65:9: error: implicit declaration of function
>> 'kzalloc'; did you mean 'vzalloc'? [-Werror=implicit-function-declaration]
65 | desc = kzalloc(sizeof(*desc), GFP_NOWAIT);
| ^~~
| vzalloc
>> drivers/dma/sf-pdma/sf-pdma.c:65:7: warning: assignment to 'struct
>> sf_pdma_desc *' from 'int' makes pointer from integer without a cast
>> [-Wint-conversion]
65 | desc = kzalloc(sizeof(*desc), GFP_NOWAIT);
| ^
drivers/dma/sf-pdma/sf-pdma.c: In function 'sf_pdma_free_chan_resources':
>> drivers/dma/sf-pdma/sf-pdma.c:155:2: error: implicit declaration of function
>> 'kfree'; did you mean 'vfree'? [-Werror=implicit-function-declaration]
155 | kfree(chan->desc);
| ^
| vfree
cc1: some warnings being treated as errors
vim +/kcalloc +419 drivers/mtd/mtdpstore.c
78c08247b9d3e0 WeiXiong Liao 2020-03-25 379
78c08247b9d3e0 WeiXiong Liao 2020-03-25 380 static void
mtdpstore_notify_add(struct mtd_info *mtd)
78c08247b9d3e0 WeiXiong Liao 2020-03-25 381 {
78c08247b9d3e0 WeiXiong Liao 2020-03-25 382int ret;
78c08247b9d3e0 WeiXiong Liao 2020-03-25 383struct mtdpstore_context *cxt =
_cxt;
78c08247b9d3e0 WeiXiong Liao 2020-03-25 384struct pstore_blk_config *info
= >info;
78c08247b9d3e0 WeiXiong Liao 2020-03-25 385unsigned long longcnt;
78c08247b9d3e0 WeiXiong Liao 2020-03-25 386
78c08247b9d3e0 WeiXiong Liao 2020-03-25 387if (!strcmp(mtd->name,
info->device))
78c08247b9d3e0 WeiXiong Liao 2020-03-25 388cxt->index = mtd->index;
78c08247b9d3e0 WeiXiong Liao 2020-03-25 389
78c08247b9d3e0 WeiXiong Liao 2020-03-25 390if (mtd->index != cxt->index ||
cxt->index < 0)
78c08247b9d3e0 WeiXiong Liao 2020-03-25 391return;
78c08247b9d3e0 WeiXiong Liao 2020-03-25 392
78c08247b9d3e0 WeiXiong Liao 2020-03-25 393dev_dbg(>dev, "found
matching MTD device %s\n", mtd->name);
78c08247b9d3e0 WeiXiong Liao 2020-03-25 394
78c08247b9d3e0 WeiXiong Liao 2020-03-25 395if (mtd->size < info->kmsg_size
* 2) {
78c08247b9d3e0 WeiXiong Liao 2020-03-25 396dev_err(>dev, "MTD
partition %d not big enou
Re: [PATCH] crypto: talitos - fix ECB and CBC algs ivsize
On Thu, Jun 11, 2020 at 06:07:45PM +0800, Su Kang Yin wrote:
> Patch for 4.9 upstream:
>
> commit e1de42fdfc6a ("crypto: talitos - fix ECB algs ivsize")
> wrongly modified CBC algs ivsize instead of ECB aggs ivsize.
>
> This restore the CBC algs original ivsize of removes ECB's ones.
>
> Signed-off-by: Su Kang Yin
> ---
> drivers/crypto/talitos.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
Nice catch, sorry about that, patch now queued up.
greg k-h
Re: [LKP] [ima] 8eb613c0b8: stress-ng.icache.ops_per_sec -84.2% regression
On Thu, 2020-06-11 at 15:10 +0800, Xing Zhengjun wrote: > On 6/10/2020 9:53 PM, Mimi Zohar wrote: > ucode: 0x52c > > > > Does the following change resolve it? > > > > diff --git a/security/integrity/ima/ima_main.c > > b/security/integrity/ima/ima_main.c > > index c44414a7f82e..78e1dfc8a3f2 100644 > > --- a/security/integrity/ima/ima_main.c > > +++ b/security/integrity/ima/ima_main.c > > @@ -426,7 +426,8 @@ int ima_file_mprotect(struct vm_area_struct *vma, > > unsigned long prot) > > int pcr; > > > > /* Is mprotect making an mmap'ed file executable? */ > > - if (!vma->vm_file || !(prot & PROT_EXEC) || (vma->vm_flags & VM_EXEC)) > > + if (!(ima_policy_flag & IMA_APPRAISE) || !vma->vm_file || > > + !(prot & PROT_EXEC) || (vma->vm_flags & VM_EXEC)) > > return 0; > > > > security_task_getsecid(current, ); > > > Thanks. I test the change, it can resolve the regression. Thanks! Can I get your "Tested-by" tag? Mimi
Re: [PATCH] iov_iter: Move unnecessary inclusion of crypto/hash.h
Hi Herbert,
I love your patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v5.7 next-20200611]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Herbert-Xu/iov_iter-Move-unnecessary-inclusion-of-crypto-hash-h/20200611-154742
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
b29482fde649c72441d5478a4ea2c52c56d97a5e
config: i386-randconfig-s001-20200611 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-13) 9.3.0
reproduce:
# apt-get install sparse
# sparse version: v0.6.1-250-g42323db3-dirty
# save the attached .config to linux build tree
make W=1 C=1 ARCH=i386 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
sparse warnings: (new ones prefixed by >>)
>> net/core/datagram.c:512:25: sparse: sparse: incorrect type in argument 6
>> (incompatible argument 3 (different base types)) @@ expected unsigned
>> int ( *cb )( ... ) @@ got unsigned int ( * )( ... ) @@
>> net/core/datagram.c:512:25: sparse: expected unsigned int ( *cb )( ... )
>> net/core/datagram.c:512:25: sparse: got unsigned int ( * )( ... )
include/linux/spinlock.h:398:9: sparse: sparse: context imbalance in
'__skb_free_datagram_locked' - unexpected unlock
vim +512 net/core/datagram.c
950fcaecd5cc6c Sagi Grimberg 2018-12-03 497
65d69e2505bb64 Sagi Grimberg 2018-12-03 498 /**
65d69e2505bb64 Sagi Grimberg 2018-12-03 499 *
skb_copy_and_hash_datagram_iter - Copy datagram to an iovec iterator
65d69e2505bb64 Sagi Grimberg 2018-12-03 500 * and update a hash.
65d69e2505bb64 Sagi Grimberg 2018-12-03 501 *@skb: buffer to copy
65d69e2505bb64 Sagi Grimberg 2018-12-03 502 *@offset: offset in the
buffer to start copying from
65d69e2505bb64 Sagi Grimberg 2018-12-03 503 *@to: iovec iterator to
copy to
65d69e2505bb64 Sagi Grimberg 2018-12-03 504 *@len: amount of data to
copy from buffer to iovec
65d69e2505bb64 Sagi Grimberg 2018-12-03 505 * @hash: hash request to
update
65d69e2505bb64 Sagi Grimberg 2018-12-03 506 */
65d69e2505bb64 Sagi Grimberg 2018-12-03 507 int
skb_copy_and_hash_datagram_iter(const struct sk_buff *skb, int offset,
65d69e2505bb64 Sagi Grimberg 2018-12-03 508 struct
iov_iter *to, int len,
65d69e2505bb64 Sagi Grimberg 2018-12-03 509 struct
ahash_request *hash)
65d69e2505bb64 Sagi Grimberg 2018-12-03 510 {
65d69e2505bb64 Sagi Grimberg 2018-12-03 511return __skb_datagram_iter(skb,
offset, to, len, true,
65d69e2505bb64 Sagi Grimberg 2018-12-03 @512
hash_and_copy_to_iter, hash);
65d69e2505bb64 Sagi Grimberg 2018-12-03 513 }
65d69e2505bb64 Sagi Grimberg 2018-12-03 514
EXPORT_SYMBOL(skb_copy_and_hash_datagram_iter);
65d69e2505bb64 Sagi Grimberg 2018-12-03 515
:: The code at line 512 was first introduced by commit
:: 65d69e2505bb64f6a8d7f417f6e46e2a351174c6 datagram: introduce
skb_copy_and_hash_datagram_iter helper
:: TO: Sagi Grimberg
:: CC: Christoph Hellwig
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: [PATCH v3 6/7] venus: Make debug infrastructure more flexible
On Wed, Jun 10, 2020 at 11:42:43PM -0700, Joe Perches wrote:
> On Thu, 2020-06-11 at 08:26 +0200, Greg Kroah-Hartman wrote:
> > On Wed, Jun 10, 2020 at 01:23:56PM -0700, Joe Perches wrote:
> > > On Wed, 2020-06-10 at 12:49 -0700, Joe Perches wrote:
> > > > On Wed, 2020-06-10 at 15:37 +0200, Greg Kroah-Hartman wrote:
> > > > > Please work with the infrastructure we have, we have spent a lot of
> > > > > time
> > > > > and effort to make it uniform to make it easier for users and
> > > > > developers.
> > > >
> > > > Not quite.
> > > >
> > > > This lack of debug grouping by type has been a
> > > > _long_ standing issue with drivers.
> > > >
> > > > > Don't regress and try to make driver-specific ways of doing
> > > > > things, that way lies madness...
> > > >
> > > > It's not driver specific, it allows driver developers to
> > > > better isolate various debug states instead of keeping
> > > > lists of specific debug messages and enabling them
> > > > individually.
> > >
> > > For instance, look at the homebrew content in
> > > drivers/gpu/drm/drm_print.c that does _not_ use
> > > dynamic_debug.
> > >
> > > MODULE_PARM_DESC(debug, "Enable debug output, where each bit enables a
> > > debug category.\n"
> > > "\t\tBit 0 (0x01) will enable CORE messages (drm core code)\n"
> > > "\t\tBit 1 (0x02) will enable DRIVER messages (drm controller code)\n"
> > > "\t\tBit 2 (0x04) will enable KMS messages (modesetting code)\n"
> > > "\t\tBit 3 (0x08) will enable PRIME messages (prime code)\n"
> > > "\t\tBit 4 (0x10) will enable ATOMIC messages (atomic code)\n"
> > > "\t\tBit 5 (0x20) will enable VBL messages (vblank code)\n"
> > > "\t\tBit 7 (0x80) will enable LEASE messages (leasing code)\n"
> > > "\t\tBit 8 (0x100) will enable DP messages (displayport code)");
> > > module_param_named(debug, __drm_debug, int, 0600);
> > >
> > > void drm_dev_dbg(const struct device *dev, enum drm_debug_category
> > > category,
> > >const char *format, ...)
> > > {
> > > struct va_format vaf;
> > > va_list args;
> > >
> > > if (!drm_debug_enabled(category))
> > > return;
> >
> > Ok, and will this proposal be able to handle stuff like this?
>
> Yes, that's the entire point.
Currently I think there not enough "levels" to map something like
drm.debug to the new dyn dbg feature. I don't think it is intrinsic
but I couldn't find the bit of the code where the 5-bit level in struct
_ddebug is converted from a mask to a bit number and vice-versa.
Daniel.
Re: [PATCH] crypto: talitos - fix ECB and CBC algs ivsize
Hi,
Le 11/06/2020 à 12:07, Su Kang Yin a écrit :
Patch for 4.9 upstream:
commit e1de42fdfc6a ("crypto: talitos - fix ECB algs ivsize")
wrongly modified CBC algs ivsize instead of ECB aggs ivsize.
To make it clear and avoid this problem to happen again, please generate
your patch with option -U8
This restore the CBC algs original ivsize of removes ECB's ones.
Signed-off-by: Su Kang Yin
I think it should include a Fixes: tag.
---
drivers/crypto/talitos.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index 8b383d3d21c2..05a35ab5595b 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -2636,7 +2636,6 @@ static struct talitos_alg_template driver_algs[] = {
.cra_ablkcipher = {
.min_keysize = AES_MIN_KEY_SIZE,
.max_keysize = AES_MAX_KEY_SIZE,
- .ivsize = AES_BLOCK_SIZE,
}
},
.desc_hdr_template = DESC_HDR_TYPE_COMMON_NONSNOOP_NO_AFEU |
@@ -2670,6 +2669,7 @@ static struct talitos_alg_template driver_algs[] = {
.cra_ablkcipher = {
.min_keysize = AES_MIN_KEY_SIZE,
.max_keysize = AES_MAX_KEY_SIZE,
+ .ivsize = AES_BLOCK_SIZE,
.setkey = ablkcipher_aes_setkey,
}
},
@@ -2687,7 +2687,6 @@ static struct talitos_alg_template driver_algs[] = {
.cra_ablkcipher = {
.min_keysize = DES_KEY_SIZE,
.max_keysize = DES_KEY_SIZE,
- .ivsize = DES_BLOCK_SIZE,
This change has no link with e1de42fdfc6a
}
},
.desc_hdr_template = DESC_HDR_TYPE_COMMON_NONSNOOP_NO_AFEU |
@@ -2720,7 +2719,6 @@ static struct talitos_alg_template driver_algs[] = {
.cra_ablkcipher = {
.min_keysize = DES3_EDE_KEY_SIZE,
.max_keysize = DES3_EDE_KEY_SIZE,
- .ivsize = DES3_EDE_BLOCK_SIZE,
This change has no link with e1de42fdfc6a
}
},
.desc_hdr_template = DESC_HDR_TYPE_COMMON_NONSNOOP_NO_AFEU |
Christophe
drivers/net/wireless/mediatek/mt76/mt7915/mac.c:1130 mt7915_mac_sta_stats_work() warn: test_bit() takes a bit number
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: b29482fde649c72441d5478a4ea2c52c56d97a5e
commit: e57b7901469fc0b021930b83a8094baaf3d81b09 mt76: add mac80211 driver for
MT7915 PCIe-based chipsets
config: x86_64-randconfig-m031-20200611 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-13) 9.3.0
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
Reported-by: Dan Carpenter
New smatch warnings:
drivers/net/wireless/mediatek/mt76/mt7915/mac.c:1130
mt7915_mac_sta_stats_work() warn: test_bit() takes a bit number
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e57b7901469fc0b021930b83a8094baaf3d81b09
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git remote update linus
git checkout e57b7901469fc0b021930b83a8094baaf3d81b09
vim +1130 drivers/net/wireless/mediatek/mt76/mt7915/mac.c
e57b7901469fc0 Ryder Lee 2020-04-25 1108 void
mt7915_mac_sta_stats_work(struct work_struct *work)
e57b7901469fc0 Ryder Lee 2020-04-25 1109 {
e57b7901469fc0 Ryder Lee 2020-04-25 1110 struct ieee80211_sta *sta;
e57b7901469fc0 Ryder Lee 2020-04-25 struct ieee80211_vif *vif;
e57b7901469fc0 Ryder Lee 2020-04-25 1112 struct mt7915_sta_stats *stats;
e57b7901469fc0 Ryder Lee 2020-04-25 1113 struct mt7915_sta *msta;
e57b7901469fc0 Ryder Lee 2020-04-25 1114 struct mt7915_dev *dev;
e57b7901469fc0 Ryder Lee 2020-04-25 1115
e57b7901469fc0 Ryder Lee 2020-04-25 1116 msta = container_of(work,
struct mt7915_sta, stats_work);
e57b7901469fc0 Ryder Lee 2020-04-25 1117 sta = container_of((void
*)msta, struct ieee80211_sta, drv_priv);
e57b7901469fc0 Ryder Lee 2020-04-25 1118 vif = container_of((void
*)msta->vif, struct ieee80211_vif, drv_priv);
e57b7901469fc0 Ryder Lee 2020-04-25 1119 dev = msta->vif->dev;
e57b7901469fc0 Ryder Lee 2020-04-25 1120 stats = >stats;
e57b7901469fc0 Ryder Lee 2020-04-25 1121
e57b7901469fc0 Ryder Lee 2020-04-25 1122 /* use MT_TX_FREE_RATE to
report Tx rate for further devices */
e57b7901469fc0 Ryder Lee 2020-04-25 1123 if (time_after(jiffies,
stats->jiffies + HZ)) {
e57b7901469fc0 Ryder Lee 2020-04-25 1124
mt7915_mcu_get_rate_info(dev, RATE_CTRL_RU_INFO,
e57b7901469fc0 Ryder Lee 2020-04-25 1125
msta->wcid.idx);
e57b7901469fc0 Ryder Lee 2020-04-25 1126
e57b7901469fc0 Ryder Lee 2020-04-25 1127 stats->jiffies =
jiffies;
e57b7901469fc0 Ryder Lee 2020-04-25 1128 }
e57b7901469fc0 Ryder Lee 2020-04-25 1129
e57b7901469fc0 Ryder Lee 2020-04-25 @1130 if
(test_and_clear_bit(IEEE80211_RC_SUPP_RATES_CHANGED |
e57b7901469fc0 Ryder Lee 2020-04-25 1131
IEEE80211_RC_NSS_CHANGED |
e57b7901469fc0 Ryder Lee 2020-04-25 1132
IEEE80211_RC_BW_CHANGED, >changed))
The test_and_clear_bit() takes a bit number like 1. But this is
passing "(1 << 1) | ...". It won't work at all.
e57b7901469fc0 Ryder Lee 2020-04-25 1133
mt7915_mcu_add_rate_ctrl(dev, vif, sta);
e57b7901469fc0 Ryder Lee 2020-04-25 1134
e57b7901469fc0 Ryder Lee 2020-04-25 1135 if
(test_and_clear_bit(IEEE80211_RC_SMPS_CHANGED, >changed))
e57b7901469fc0 Ryder Lee 2020-04-25 1136
mt7915_mcu_add_smps(dev, vif, sta);
e57b7901469fc0 Ryder Lee 2020-04-25 1137
e57b7901469fc0 Ryder Lee 2020-04-25 1138
spin_lock_bh(>sta_poll_lock);
e57b7901469fc0 Ryder Lee 2020-04-25 1139 if
(list_empty(>poll_list))
e57b7901469fc0 Ryder Lee 2020-04-25 1140
list_add_tail(>poll_list, >sta_poll_list);
e57b7901469fc0 Ryder Lee 2020-04-25 1141
spin_unlock_bh(>sta_poll_lock);
e57b7901469fc0 Ryder Lee 2020-04-25 1142 }
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: [RFC PATCH] ALSA: compress: Fix gapless playback state machine
On Thu, Jun 11, 2020 at 03:14:23PM +0530, Vinod Koul wrote: > On 11-06-20, 11:09, Jaroslav Kysela wrote: > > Dne 11. 06. 20 v 10:46 Charles Keepax napsal(a): > > > On Wed, Jun 10, 2020 at 04:28:20PM +0530, Vinod Koul wrote: > > > > On 10-06-20, 12:40, Jaroslav Kysela wrote: > > > > > Dne 10. 06. 20 v 12:07 Srinivas Kandagatla napsal(a): > > > > > > Here is the sequence of events and state transitions: > > > > > > > > > > > > 1. set_params (Track 1), state = SNDRV_PCM_STATE_SETUP > > > > > > 2. set_metadata (Track 1), no state change, state = > > > > > > SNDRV_PCM_STATE_SETUP > > > > > > 3. fill and trigger start (Track 1), state = SNDRV_PCM_STATE_RUNNING > > > > > > 4. set_next_track (Track 2), state = SNDRV_PCM_STATE_RUNNING > > > > > > 5. partial_drain (Track 1), state = SNDRV_PCM_STATE_SETUP > > > > > > 6 snd_compr_drain_notify (Track 1), state = SNDRV_PCM_STATE_SETUP > > > > > > 7. fill data (Track 2), state = SNDRV_PCM_STATE_PREPARED > > > > > > 8. set_metadata (Track 3), no state change, state = > > > > > > SNDRV_PCM_STATE_PREPARED > > > > > > 9. set_next_track (Track 3), !! FAILURE as state != > > > > > > SNDRV_PCM_STATE_RUNNING > Yeah sorry I overlooked that case and was thinking of it being invoked > from driver! > > Yes this would make the snd_compr_stop() behave incorrectly.. so this > cant be done as proposed. > > But we still need to set the draining stream state properly and I am > thinking below now: > > diff --git a/sound/core/compress_offload.c b/sound/core/compress_offload.c > index 509290f2efa8..9aba851732d7 100644 > --- a/sound/core/compress_offload.c > +++ b/sound/core/compress_offload.c > @@ -929,7 +929,9 @@ static int snd_compr_partial_drain(struct > snd_compr_stream *stream) > } > > stream->next_track = false; > - return snd_compress_wait_for_drain(stream); > + retval = snd_compress_wait_for_drain(stream); > + stream->runtime->state = SNDRV_PCM_STATE_RUNNING; > + return retval; This is looking better, I think you probably need to make the switch to RUNNING conditional on snd_compress_wait_for_drain succeeding, as the state should remain in DRAINING if we are interrupted or some such. I also have a slight concern that since snd_compress_wait_for_drain, releases the lock the set_next_track could come in before the state is moved to RUNNING, but I guess from user-spaces perspective that is the same as it coming in whilst the state is still DRAINING, so should be handled fine? Thanks, Charles
Re: linux-next: manual merge of the tip tree with Linus' tree
Stephen Rothwell writes:
> Today's linux-next merge of the tip tree got conflicts in:
>
> include/linux/compiler.h
>
> between commits:
>
> dee081bf8f82 ("READ_ONCE: Drop pointer qualifiers when reading from scalar
> types")
> 9e343b467c70 ("READ_ONCE: Enforce atomicity for {READ,WRITE}_ONCE() memory
> accesses")
> a5460b5e5fb8 ("READ_ONCE: Simplify implementations of {READ,WRITE}_ONCE()")
>
> from Linus' tree and commits:
>
> 2ab3a0a02905 ("READ_ONCE: Enforce atomicity for {READ,WRITE}_ONCE() memory
> accesses")
> 7b364f0949ae ("READ_ONCE: Drop pointer qualifiers when reading from scalar
> types")
> bbfa112b46bd ("READ_ONCE: Simplify implementations of {READ,WRITE}_ONCE()")
> (and maybe others)
>
> from the tip tree.
Sorry for that inconveniance. I'm about to get rid of the conflicts on
the tip side.
Thanks,
tglx
[PATCH] gpio: mpc8xxx: change the gpio interrupt flags.
From: Song Hui
Delete the interrupt IRQF_NO_THREAD flags in order to gpio interrupts
can be threaded to allow high-priority processes to preempt.
Signed-off-by: Song Hui
---
drivers/gpio/gpio-mpc8xxx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpio/gpio-mpc8xxx.c b/drivers/gpio/gpio-mpc8xxx.c
index 604dfec..1e86652 100644
--- a/drivers/gpio/gpio-mpc8xxx.c
+++ b/drivers/gpio/gpio-mpc8xxx.c
@@ -417,7 +417,7 @@ static int mpc8xxx_probe(struct platform_device *pdev)
ret = devm_request_irq(>dev, mpc8xxx_gc->irqn,
mpc8xxx_gpio_irq_cascade,
- IRQF_NO_THREAD | IRQF_SHARED, "gpio-cascade",
+ IRQF_SHARED, "gpio-cascade",
mpc8xxx_gc);
if (ret) {
dev_err(>dev, "%s: failed to devm_request_irq(%d), ret =
%d\n",
--
2.9.5
