Re: [PATCH v10 5/6] i2c: designware: add SLAVE mode functions
Hi Luis,
[auto build test ERROR on wsa/i2c/for-next]
[also build test ERROR on v4.12-rc4 next-20170608]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Luis-Oliveira/i2c-designware-add-I2C-SLAVE-support/20170609-143533
base: https://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git
i2c/for-next
config: x86_64-randconfig-x012-201723 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All error/warnings (new ones prefixed by >>):
drivers/i2c/busses/i2c-designware-slave.c: In function
'i2c_dw_irq_handler_slave':
>> drivers/i2c/busses/i2c-designware-slave.c:285:3: error: implicit declaration
>> of function 'i2c_slave_event' [-Werror=implicit-function-declaration]
i2c_slave_event(dev->slave, I2C_SLAVE_WRITE_REQUESTED, &val);
^~~
>> drivers/i2c/busses/i2c-designware-slave.c:285:31: error:
>> 'I2C_SLAVE_WRITE_REQUESTED' undeclared (first use in this function)
i2c_slave_event(dev->slave, I2C_SLAVE_WRITE_REQUESTED, &val);
^
drivers/i2c/busses/i2c-designware-slave.c:285:31: note: each undeclared
identifier is reported only once for each function it appears in
>> drivers/i2c/busses/i2c-designware-slave.c:293:9: error:
>> 'I2C_SLAVE_WRITE_RECEIVED' undeclared (first use in this function)
I2C_SLAVE_WRITE_RECEIVED, &val)) {
^~~~
>> drivers/i2c/busses/i2c-designware-slave.c:305:8: error:
>> 'I2C_SLAVE_READ_REQUESTED' undeclared (first use in this function)
I2C_SLAVE_READ_REQUESTED, &val))
^~~~
>> drivers/i2c/busses/i2c-designware-slave.c:311:36: error:
>> 'I2C_SLAVE_READ_PROCESSED' undeclared (first use in this function)
if (!i2c_slave_event(dev->slave, I2C_SLAVE_READ_PROCESSED,
^~~~
>> drivers/i2c/busses/i2c-designware-slave.c:315:31: error: 'I2C_SLAVE_STOP'
>> undeclared (first use in this function)
i2c_slave_event(dev->slave, I2C_SLAVE_STOP, &val);
^~
drivers/i2c/busses/i2c-designware-slave.c: At top level:
>> drivers/i2c/busses/i2c-designware-slave.c:351:2: error: unknown field
>> 'reg_slave' specified in initializer
.reg_slave = i2c_dw_reg_slave,
^
>> drivers/i2c/busses/i2c-designware-slave.c:351:15: warning: excess elements
>> in struct initializer
.reg_slave = i2c_dw_reg_slave,
^~~~
drivers/i2c/busses/i2c-designware-slave.c:351:15: note: (near initialization
for 'i2c_dw_algo')
>> drivers/i2c/busses/i2c-designware-slave.c:352:2: error: unknown field
>> 'unreg_slave' specified in initializer
.unreg_slave = i2c_dw_unreg_slave,
^
drivers/i2c/busses/i2c-designware-slave.c:352:17: warning: excess elements
in struct initializer
.unreg_slave = i2c_dw_unreg_slave,
^~
drivers/i2c/busses/i2c-designware-slave.c:352:17: note: (near initialization
for 'i2c_dw_algo')
cc1: some warnings being treated as errors
vim +/i2c_slave_event +285 drivers/i2c/busses/i2c-designware-slave.c
279 dev_dbg(dev->dev,
280 "%#x STAUTS SLAVE_ACTTVITY=%#x : RAW_INTR_STAT=%#x"
281 " : INTR_STAT=%#x\n",
282 enabled, slave_activity, raw_stat, stat);
283
284 if ((stat & DW_IC_INTR_RX_FULL) && (stat & DW_IC_INTR_STOP_DET))
> 285 i2c_slave_event(dev->slave, I2C_SLAVE_WRITE_REQUESTED,
> &val);
286
287 if (stat & DW_IC_INTR_RD_REQ) {
288 if (slave_activity) {
289 if (stat & DW_IC_INTR_RX_FULL) {
290 val = dw_readl(dev, DW_IC_DATA_CMD);
291
292 if (!i2c_slave_event(dev->slave,
> 293 I2C_SLAVE_WRITE_RECEIVED, &val)) {
294 dev_vdbg(dev->dev, "Byte %X
acked!",
295 val);
296 }
297 dw_readl(dev, DW_IC_CLR_RD_REQ);
298 stat =
i2c_dw_read_clear_intrbits_slave(dev);
299 } else {
300 dw_readl(dev, DW_IC_CLR_RD_REQ);
301
Re: [PATCH] iscsi-target: Reject immediate data underflow larger than SCSI transfer length
On Thu, 2017-06-08 at 15:37 +, Bart Van Assche wrote:
> On Thu, 2017-06-08 at 04:21 +, Nicholas A. Bellinger wrote:
> > + /*
> > +* Check for underflow case where both EDTL and immediate data payload
> > +* exceeds what is presented by CDB's TRANSFER LENGTH, and what has
> > +* already been set in target_cmd_size_check() as se_cmd->data_length.
> > +*
> > +* For this special case, fail the command and dump the immediate data
> > +* payload.
> > +*/
> > + if (cmd->first_burst_len > cmd->se_cmd.data_length) {
> > + cmd->sense_reason = TCM_INVALID_CDB_FIELD;
> > + goto after_immediate_data;
> > + }
>
> A quote from the iSCSI RFC (https://tools.ietf.org/html/rfc5048):
>
>If SPDTL < EDTL for a task, iSCSI Underflow MUST be signaled in the
>SCSI Response PDU as specified in [RFC3720]. The Residual Count MUST
>be set to the numerical value of (EDTL - SPDTL).
>
> Sorry but I don't think that sending TCM_INVALID_CDB_FIELD back to the
> initiator is compliant with the iSCSI RFC.
Alas, the nuance of what this patch actually does was missed when you
cut the context.
First, a bit of history. LIO has rejected underflow for all WRITEs for
the first ~12.5 years of RFC-3720, and in the context of iscsi-target
mode there has never been a single host environment that ever once
cared.
Since Roland's patch to allow underflow for control CDBs in v4.3+ opened
this discussion for control CDBs with a WRITE payload in order to make
MSFT/FCP cert for PERSISTENT_RESERVE_OUT happy, the question has become
what control CDB WRITE underflow cases should we allow..?
The point with this patch is when a host is sending a underflow with a
iscsi immediate data payload that exceeds SCSI transfer length, it's a
bogus request with a garbage payload. It's a garbage payload because
the SCSI CDB itself obviously doesn't want anything to do it.
I'm very dubious of any host environment who's trying to do this for any
CDB, and expects achieve expected results.
Of course, since v4.3+ normal overflow where SCSI transfer length
matches the iscsi immediate data payload just works with or without this
patch.
So to that extent, I'm going to push this patch as a defensive fix for
v4.3+, to let those imaginary iscsi host environments know they being
very, very naughty.
> Please note that a fix that is
> compliant with the iSCSI RFC is present in the following patch series: [PATCH
> 00/33] SCSI target driver patches for kernel v4.13, 23 May 2017
> (https://www.spinics.net/lists/target-devel/msg15370.html).
So I might still consider this as a v4.13-rc item for control CDB
underflow, but no way as stable material.
Also, there is certainly no way I'm going to allow a patch to randomly
enable underflow/overflow for all WRITE non control CDBs tree-wide
across all fabric drivers, because 1) no host environments actually care
about this, and 2) it's still dangerous to do for all fabrics without
some serious auditing.
[PATCH v8 4/6] vfio: Define vfio based vgpu's dma-buf operations
Here we defined a new ioctl to create a fd for a vfio device based on
the input type. Now only one type is supported that is a dma-buf
management fd.
Two ioctls are defined for the dma-buf management fd: query the vfio
vgpu's plane information and create a dma-buf for a plane.
Signed-off-by: Xiaoguang Chen
---
include/uapi/linux/vfio.h | 58 +++
1 file changed, 58 insertions(+)
diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
index ae46105..24427b7 100644
--- a/include/uapi/linux/vfio.h
+++ b/include/uapi/linux/vfio.h
@@ -502,6 +502,64 @@ struct vfio_pci_hot_reset {
#define VFIO_DEVICE_PCI_HOT_RESET _IO(VFIO_TYPE, VFIO_BASE + 13)
+/**
+ * VFIO_DEVICE_GET_FD - _IO(VFIO_TYPE, VFIO_BASE + 14, __u32)
+ *
+ * Create a fd for a vfio device based on the input type
+ * Vendor driver should handle this ioctl to create a fd and manage the
+ * life cycle of this fd.
+ *
+ * Return: a fd if vendor support that type, -errno if not supported
+ */
+
+#define VFIO_DEVICE_GET_FD _IO(VFIO_TYPE, VFIO_BASE + 14)
+
+struct vfio_vgpu_plane_info {
+ __u64 start;
+ __u64 drm_format_mod;
+ __u32 drm_format;
+ __u32 width;
+ __u32 height;
+ __u32 stride;
+ __u32 size;
+ __u32 x_pos;
+ __u32 y_pos;
+ __u32 padding;
+};
+
+#define VFIO_DEVICE_DMABUF_MGR_FD 0 /* Supported fd types */
+
+/*
+ * VFIO_DEVICE_QUERY_PLANE - _IO(VFIO_TYPE, VFIO_BASE + 15,
+ * struct vfio_vgpu_query_plane)
+ * Query plane information
+ */
+struct vfio_vgpu_query_plane {
+ __u32 argsz;
+ __u32 flags;
+ struct vfio_vgpu_plane_info plane_info;
+ __u32 plane_id;
+ __u32 padding;
+};
+
+#define VFIO_DEVICE_QUERY_PLANE _IO(VFIO_TYPE, VFIO_BASE + 15)
+
+/*
+ * VFIO_DEVICE_CREATE_DMABUF - _IO(VFIO, VFIO_BASE + 16,
+ * struct vfio_vgpu_create_dmabuf)
+ *
+ * Create a dma-buf for a plane
+ */
+struct vfio_vgpu_create_dmabuf {
+ __u32 argsz;
+ __u32 flags;
+ struct vfio_vgpu_plane_info plane_info;
+ __s32 fd;
+ __u32 plane_id;
+};
+
+#define VFIO_DEVICE_CREATE_DMABUF _IO(VFIO_TYPE, VFIO_BASE + 16)
+
/* API for Type1 VFIO IOMMU */
/**
--
2.7.4
[PATCH v8 6/6] drm/i915/gvt: Adding user interface for dma-buf
User space should create the management fd for the dma-buf operation first.
Then user can query the plane information and create dma-buf if necessary
using the management fd.
Signed-off-by: Xiaoguang Chen
Tested-by: Kechen Lu
---
drivers/gpu/drm/i915/gvt/dmabuf.c| 37 -
drivers/gpu/drm/i915/gvt/dmabuf.h| 5 ++
drivers/gpu/drm/i915/gvt/gvt.c | 3 +
drivers/gpu/drm/i915/gvt/gvt.h | 5 ++
drivers/gpu/drm/i915/gvt/hypercall.h | 3 +
drivers/gpu/drm/i915/gvt/kvmgt.c | 145 +++
drivers/gpu/drm/i915/gvt/mpt.h | 30
drivers/gpu/drm/i915/gvt/vgpu.c | 2 +
8 files changed, 229 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gvt/dmabuf.c
b/drivers/gpu/drm/i915/gvt/dmabuf.c
index c38ed8e9fc..1811abd 100644
--- a/drivers/gpu/drm/i915/gvt/dmabuf.c
+++ b/drivers/gpu/drm/i915/gvt/dmabuf.c
@@ -81,6 +81,28 @@ static void intel_vgpu_gem_put_pages(struct
drm_i915_gem_object *obj,
static void intel_vgpu_gem_release(struct drm_i915_gem_object *obj)
{
+ struct intel_vgpu_dmabuf_obj *dmabuf_obj;
+ struct intel_vgpu_fb_info *fb_info;
+ struct intel_vgpu *vgpu = NULL;
+ struct list_head *pos;
+
+ fb_info = (struct intel_vgpu_fb_info *)obj->gvt_info;
+ if (WARN_ON(!fb_info && !fb_info->vgpu)) {
+ gvt_vgpu_err("gvt info is invalid\n");
+ goto out;
+ }
+
+ vgpu = fb_info->vgpu;
+ list_for_each(pos, &vgpu->dmabuf_obj_list_head) {
+ dmabuf_obj = container_of(pos, struct intel_vgpu_dmabuf_obj,
+ list);
+ if ((dmabuf_obj != NULL) && (dmabuf_obj->obj == obj)) {
+ kfree(dmabuf_obj);
+ break;
+ }
+ }
+ intel_gvt_hypervisor_put_vfio_device(vgpu);
+out:
kfree(obj->gvt_info);
}
@@ -215,6 +237,7 @@ int intel_vgpu_create_dmabuf(struct intel_vgpu *vgpu, void
*args)
struct vfio_vgpu_create_dmabuf *gvt_dmabuf = args;
struct intel_vgpu_fb_info *fb_info;
int ret;
+ struct intel_vgpu_dmabuf_obj *dmabuf_obj;
ret = intel_vgpu_get_plane_info(dev, vgpu, &gvt_dmabuf->plane_info,
gvt_dmabuf->plane_id);
@@ -237,6 +260,16 @@ int intel_vgpu_create_dmabuf(struct intel_vgpu *vgpu, void
*args)
fb_info->vgpu = vgpu;
obj->gvt_info = fb_info;
+ dmabuf_obj = kmalloc(sizeof(*dmabuf_obj), GFP_KERNEL);
+ if (!dmabuf_obj) {
+ gvt_vgpu_err("alloc dmabuf_obj failed\n");
+ ret = -ENOMEM;
+ goto out_free_info;
+ }
+ dmabuf_obj->obj = obj;
+ INIT_LIST_HEAD(&dmabuf_obj->list);
+ list_add_tail(&dmabuf_obj->list, &vgpu->dmabuf_obj_list_head);
+
dmabuf = i915_gem_prime_export(dev, &obj->base, DRM_CLOEXEC | DRM_RDWR);
if (IS_ERR(dmabuf)) {
@@ -250,11 +283,13 @@ int intel_vgpu_create_dmabuf(struct intel_vgpu *vgpu,
void *args)
gvt_vgpu_err("create dma-buf fd failed ret:%d\n", ret);
goto out_free;
}
-
+ intel_gvt_hypervisor_get_vfio_device(vgpu);
gvt_dmabuf->fd = ret;
return 0;
out_free:
+ kfree(dmabuf_obj);
+out_free_info:
kfree(fb_info);
out:
i915_gem_object_put(obj);
diff --git a/drivers/gpu/drm/i915/gvt/dmabuf.h
b/drivers/gpu/drm/i915/gvt/dmabuf.h
index 8be9979..cafa781 100644
--- a/drivers/gpu/drm/i915/gvt/dmabuf.h
+++ b/drivers/gpu/drm/i915/gvt/dmabuf.h
@@ -31,6 +31,11 @@ struct intel_vgpu_fb_info {
uint32_t fb_size;
};
+struct intel_vgpu_dmabuf_obj {
+ struct drm_i915_gem_object *obj;
+ struct list_head list;
+};
+
int intel_vgpu_query_plane(struct intel_vgpu *vgpu, void *args);
int intel_vgpu_create_dmabuf(struct intel_vgpu *vgpu, void *args);
diff --git a/drivers/gpu/drm/i915/gvt/gvt.c b/drivers/gpu/drm/i915/gvt/gvt.c
index 2032917..d589830 100644
--- a/drivers/gpu/drm/i915/gvt/gvt.c
+++ b/drivers/gpu/drm/i915/gvt/gvt.c
@@ -54,6 +54,9 @@ static const struct intel_gvt_ops intel_gvt_ops = {
.vgpu_reset = intel_gvt_reset_vgpu,
.vgpu_activate = intel_gvt_activate_vgpu,
.vgpu_deactivate = intel_gvt_deactivate_vgpu,
+ .vgpu_query_plane = intel_vgpu_query_plane,
+ .vgpu_create_dmabuf = intel_vgpu_create_dmabuf,
+
};
/**
diff --git a/drivers/gpu/drm/i915/gvt/gvt.h b/drivers/gpu/drm/i915/gvt/gvt.h
index 763a8c5..8f08c42 100644
--- a/drivers/gpu/drm/i915/gvt/gvt.h
+++ b/drivers/gpu/drm/i915/gvt/gvt.h
@@ -185,8 +185,11 @@ struct intel_vgpu {
struct kvm *kvm;
struct work_struct release_work;
atomic_t released;
+ struct vfio_device *vfio_device;
} vdev;
#endif
+ atomic_t mgr_fd_opened;
+ struct list_head dmabuf_obj_list_head;
};
struct intel_gvt_gm {
@@ -467,6 +470,8 @@ struct intel_gvt_ops {
voi
[PATCH v8 3/6] drm/i915/gvt: Frame buffer decoder support for GVT-g
decode frambuffer attributes of primary, cursor and sprite plane
Signed-off-by: Xiaoguang Chen
---
drivers/gpu/drm/i915/gvt/Makefile | 3 +-
drivers/gpu/drm/i915/gvt/display.c| 2 +-
drivers/gpu/drm/i915/gvt/display.h| 2 +
drivers/gpu/drm/i915/gvt/fb_decoder.c | 425 ++
drivers/gpu/drm/i915/gvt/fb_decoder.h | 171 ++
drivers/gpu/drm/i915/gvt/gvt.h| 1 +
include/uapi/drm/drm_fourcc.h | 6 +
7 files changed, 608 insertions(+), 2 deletions(-)
create mode 100644 drivers/gpu/drm/i915/gvt/fb_decoder.c
create mode 100644 drivers/gpu/drm/i915/gvt/fb_decoder.h
diff --git a/drivers/gpu/drm/i915/gvt/Makefile
b/drivers/gpu/drm/i915/gvt/Makefile
index b123c20..192ca26 100644
--- a/drivers/gpu/drm/i915/gvt/Makefile
+++ b/drivers/gpu/drm/i915/gvt/Makefile
@@ -1,7 +1,8 @@
GVT_DIR := gvt
GVT_SOURCE := gvt.o aperture_gm.o handlers.o vgpu.o trace_points.o firmware.o \
interrupt.o gtt.o cfg_space.o opregion.o mmio.o display.o edid.o \
- execlist.o scheduler.o sched_policy.o render.o cmd_parser.o
+ execlist.o scheduler.o sched_policy.o render.o cmd_parser.o \
+ fb_decoder.o
ccflags-y += -I$(src) -I$(src)/$(GVT_DIR) -Wall
i915-y += $(addprefix $(GVT_DIR)/,
$(GVT_SOURCE))
diff --git a/drivers/gpu/drm/i915/gvt/display.c
b/drivers/gpu/drm/i915/gvt/display.c
index e0261fc..f5f63c5 100644
--- a/drivers/gpu/drm/i915/gvt/display.c
+++ b/drivers/gpu/drm/i915/gvt/display.c
@@ -67,7 +67,7 @@ static int edp_pipe_is_enabled(struct intel_vgpu *vgpu)
return 1;
}
-static int pipe_is_enabled(struct intel_vgpu *vgpu, int pipe)
+int pipe_is_enabled(struct intel_vgpu *vgpu, int pipe)
{
struct drm_i915_private *dev_priv = vgpu->gvt->dev_priv;
diff --git a/drivers/gpu/drm/i915/gvt/display.h
b/drivers/gpu/drm/i915/gvt/display.h
index d73de22..b46b868 100644
--- a/drivers/gpu/drm/i915/gvt/display.h
+++ b/drivers/gpu/drm/i915/gvt/display.h
@@ -179,4 +179,6 @@ int intel_vgpu_init_display(struct intel_vgpu *vgpu, u64
resolution);
void intel_vgpu_reset_display(struct intel_vgpu *vgpu);
void intel_vgpu_clean_display(struct intel_vgpu *vgpu);
+int pipe_is_enabled(struct intel_vgpu *vgpu, int pipe);
+
#endif
diff --git a/drivers/gpu/drm/i915/gvt/fb_decoder.c
b/drivers/gpu/drm/i915/gvt/fb_decoder.c
new file mode 100644
index 000..beac70b
--- /dev/null
+++ b/drivers/gpu/drm/i915/gvt/fb_decoder.c
@@ -0,0 +1,425 @@
+/*
+ * Copyright(c) 2011-2016 Intel Corporation. All rights reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
THE
+ * SOFTWARE.
+ *
+ * Authors:
+ *Kevin Tian
+ *
+ * Contributors:
+ *Bing Niu
+ *Xu Han
+ *Ping Gao
+ *Xiaoguang Chen
+ *Yang Liu
+ *
+ */
+
+#include
+#include "i915_drv.h"
+#include "gvt.h"
+
+#define PRIMARY_FORMAT_NUM 16
+struct pixel_format {
+ int drm_format; /* Pixel format in DRM definition */
+ int bpp;/* Bits per pixel, 0 indicates invalid */
+ char *desc; /* The description */
+};
+
+/* non-supported format has bpp default to 0 */
+static struct pixel_format bdw_pixel_formats[PRIMARY_FORMAT_NUM] = {
+ [0x2] = {DRM_FORMAT_C8, 8, "8-bit Indexed"},
+ [0x5] = {DRM_FORMAT_RGB565, 16, "16-bit BGRX (5:6:5 MSB-R:G:B)"},
+ [0x6] = {DRM_FORMAT_XRGB, 32,
+ "32-bit BGRX (8:8:8:8 MSB-X:R:G:B)"},
+ [0x8] = {DRM_FORMAT_XBGR2101010, 32,
+ "32-bit RGBX (2:10:10:10 MSB-X:B:G:R)"},
+ [0xa] = {DRM_FORMAT_XRGB2101010, 32,
+ "32-bit BGRX (2:10:10:10 MSB-X:R:G:B)"},
+ [0xc] = {DRM_FORMAT_XRGB161616_GVT, 64,
+ "64-bit RGBX Floating Point(16:16:16:16 MSB-X:B:G:R)"},
+ [0xe] = {DRM_FORMAT_XBGR, 32,
+ "32-bit RGBX (8:8:8:8 MSB-X:B:G:R)"},
+};
+
+/* non-supported format has bpp def
[PATCH v8 0/6] drm/i915/gvt: Dma-buf support for GVT-g
v7->v8: 1) refine framebuffer decoder code 2) fix a bug in decoding primary plane v6->v7: 1) release dma-buf related allocations in dma-buf's associated release function. 2) refine ioctl interface for querying plane info or create dma-buf 3) refine framebuffer decoder code 4) the patch series is based on 4.12.0-rc1 v5->v6: 1) align the dma-buf life cycle with the vfio device. 2) add the dma-buf releated operations in a separate patch. 3) i915 releated changes. v4->v5: 1) fix bug while checking whether the gem obj is gvt's dma-buf when user change caching mode or domains. Add a helper function to do it. 2) add definition for the query plane and create dma-buf. v3->v4: 1) fix bug while checking whether the gem obj is gvt's dma-buf when set caching mode or doamins. v2->v3: 1) add a field gvt_plane_info in the drm_i915_gem_obj structure to save the decoded plane information to avoid look up while need the plane info. 2) declare a new flag I915_GEM_OBJECT_IS_GVT_DMABUF in drm_i915_gem_object to represent the gem obj for gvt's dma-buf. The tiling mode, caching mode and domains can not be changed for this kind of gem object. 3) change dma-buf related information to be more generic. So other vendor can use the same interface. v1->v2: 1) create a management fd for dma-buf operations. 2) alloc gem object's backing storage in gem obj's get_pages() callback. This patch set adds the dma-buf support for intel GVT-g. dma-buf is a uniform mechanism to share DMA buffers across different devices and sub-systems. dma-buf for intel GVT-g is mainly used to share the vgpu's framebuffer to other users or sub-systems so they can use the dma-buf to show the desktop of a vm which uses intel vgpu. The main idea is we create a gem object and set vgpu's framebuffer as the backing storage of this gem object. And associate this gem obj to a dma-buf object then export this dma-buf at the meantime generate a file descriptor for this dma-buf. Finally deliver this file descriptor to user space. And user can use this dma-buf fd to do render or other operations. User need to create a fd(for intel GVT-g dma-buf support it is a:dma-buf management fd) then user can use this fd to query the plane information or create a dma-buf. The life cycle of this fd is managed by GVT-g user do not need to care about that. We have an example program on how to use the dma-buf. You can download the program to have a try. Good luck :) git repo: https://github.com/01org/igvtg-qemu branch:kvmgt_dmabuf_example Xiaoguang Chen (6): drm/i915/gvt: Extend the GVT-g architecture to support vfio device region drm/i915/gvt: OpRegion support for GVT-g drm/i915/gvt: Frame buffer decoder support for GVT-g vfio: Define vfio based vgpu's dma-buf operations drm/i915/gvt: Dmabuf support for GVT-g drm/i915/gvt: Adding user interface for dma-buf drivers/gpu/drm/i915/gvt/Makefile | 3 +- drivers/gpu/drm/i915/gvt/display.c | 2 +- drivers/gpu/drm/i915/gvt/display.h | 2 + drivers/gpu/drm/i915/gvt/dmabuf.c | 298 +++ drivers/gpu/drm/i915/gvt/dmabuf.h | 42 drivers/gpu/drm/i915/gvt/fb_decoder.c | 425 + drivers/gpu/drm/i915/gvt/fb_decoder.h | 171 + drivers/gpu/drm/i915/gvt/gvt.c | 3 + drivers/gpu/drm/i915/gvt/gvt.h | 7 + drivers/gpu/drm/i915/gvt/hypercall.h | 4 + drivers/gpu/drm/i915/gvt/kvmgt.c | 254 +++- drivers/gpu/drm/i915/gvt/mpt.h | 45 drivers/gpu/drm/i915/gvt/opregion.c| 26 +- drivers/gpu/drm/i915/gvt/vgpu.c| 6 + drivers/gpu/drm/i915/i915_gem.c| 26 +- drivers/gpu/drm/i915/i915_gem_object.h | 9 + drivers/gpu/drm/i915/i915_gem_tiling.c | 5 + include/uapi/drm/drm_fourcc.h | 6 + include/uapi/linux/vfio.h | 58 + 19 files changed, 1380 insertions(+), 12 deletions(-) create mode 100644 drivers/gpu/drm/i915/gvt/dmabuf.c create mode 100644 drivers/gpu/drm/i915/gvt/dmabuf.h create mode 100644 drivers/gpu/drm/i915/gvt/fb_decoder.c create mode 100644 drivers/gpu/drm/i915/gvt/fb_decoder.h -- 2.7.4
[PATCH v8 2/6] drm/i915/gvt: OpRegion support for GVT-g
OpRegion is needed to support display related operation for
intel vgpu.
A vfio device region is added to intel vgpu to deliver the
host OpRegion information to user space so user space can
construct the OpRegion for vgpu.
Signed-off-by: Bing Niu
Signed-off-by: Xiaoguang Chen
---
drivers/gpu/drm/i915/gvt/hypercall.h | 1 +
drivers/gpu/drm/i915/gvt/kvmgt.c | 88
drivers/gpu/drm/i915/gvt/mpt.h | 15 ++
drivers/gpu/drm/i915/gvt/opregion.c | 26 ---
drivers/gpu/drm/i915/gvt/vgpu.c | 4 ++
5 files changed, 128 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/hypercall.h
b/drivers/gpu/drm/i915/gvt/hypercall.h
index df7f33a..32c345c 100644
--- a/drivers/gpu/drm/i915/gvt/hypercall.h
+++ b/drivers/gpu/drm/i915/gvt/hypercall.h
@@ -55,6 +55,7 @@ struct intel_gvt_mpt {
unsigned long mfn, unsigned int nr, bool map);
int (*set_trap_area)(unsigned long handle, u64 start, u64 end,
bool map);
+ int (*set_opregion)(void *vgpu);
};
extern struct intel_gvt_mpt xengt_mpt;
diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index 3c6a02b..6b4652a 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -53,6 +53,8 @@ static const struct intel_gvt_ops *intel_gvt_ops;
#define VFIO_PCI_INDEX_TO_OFFSET(index) ((u64)(index) << VFIO_PCI_OFFSET_SHIFT)
#define VFIO_PCI_OFFSET_MASK(((u64)(1) << VFIO_PCI_OFFSET_SHIFT) - 1)
+#define OPREGION_SIGNATURE "IntelGraphicsMem"
+
struct vfio_region;
struct intel_vgpu_regops {
size_t (*rw)(struct intel_vgpu *vgpu, char *buf,
@@ -436,6 +438,91 @@ static void kvmgt_protect_table_del(struct
kvmgt_guest_info *info,
}
}
+static size_t intel_vgpu_reg_rw_opregion(struct intel_vgpu *vgpu, char *buf,
+ size_t count, loff_t *ppos, bool iswrite)
+{
+ unsigned int i = VFIO_PCI_OFFSET_TO_INDEX(*ppos) -
+ VFIO_PCI_NUM_REGIONS;
+ void *base = vgpu->vdev.region[i].data;
+ loff_t pos = *ppos & VFIO_PCI_OFFSET_MASK;
+
+ if (pos >= vgpu->vdev.region[i].size || iswrite) {
+ gvt_vgpu_err("invalid op or offset for Intel vgpu OpRegion\n");
+ return -EINVAL;
+ }
+ count = min(count, (size_t)(vgpu->vdev.region[i].size - pos));
+ memcpy(buf, base + pos, count);
+
+ return count;
+}
+
+static void intel_vgpu_reg_release_opregion(struct intel_vgpu *vgpu,
+ struct vfio_region *region)
+{
+ memunmap(region->data);
+}
+
+static const struct intel_vgpu_regops intel_vgpu_regops_opregion = {
+ .rw = intel_vgpu_reg_rw_opregion,
+ .release = intel_vgpu_reg_release_opregion,
+};
+
+static int intel_vgpu_register_reg(struct intel_vgpu *vgpu,
+ unsigned int type, unsigned int subtype,
+ const struct intel_vgpu_regops *ops,
+ size_t size, u32 flags, void *data)
+{
+ struct vfio_region *region;
+
+ region = krealloc(vgpu->vdev.region,
+ (vgpu->vdev.num_regions + 1) * sizeof(*region),
+ GFP_KERNEL);
+ if (!region)
+ return -ENOMEM;
+
+ vgpu->vdev.region = region;
+ vgpu->vdev.region[vgpu->vdev.num_regions].type = type;
+ vgpu->vdev.region[vgpu->vdev.num_regions].subtype = subtype;
+ vgpu->vdev.region[vgpu->vdev.num_regions].ops = ops;
+ vgpu->vdev.region[vgpu->vdev.num_regions].size = size;
+ vgpu->vdev.region[vgpu->vdev.num_regions].flags = flags;
+ vgpu->vdev.region[vgpu->vdev.num_regions].data = data;
+ vgpu->vdev.num_regions++;
+
+ return 0;
+}
+
+static int kvmgt_set_opregion(void *p_vgpu)
+{
+ struct intel_vgpu *vgpu = (struct intel_vgpu *)p_vgpu;
+ unsigned int addr;
+ void *base;
+ int ret;
+
+ addr = vgpu->gvt->opregion.opregion_pa;
+ if (!addr || !(~addr))
+ return -ENODEV;
+
+ base = memremap(addr, OPREGION_SIZE, MEMREMAP_WB);
+ if (!base)
+ return -ENOMEM;
+
+ if (memcmp(base, OPREGION_SIGNATURE, 16)) {
+ memunmap(base);
+ return -EINVAL;
+ }
+
+ ret = intel_vgpu_register_reg(vgpu,
+ PCI_VENDOR_ID_INTEL | VFIO_REGION_TYPE_PCI_VENDOR_TYPE,
+ VFIO_REGION_SUBTYPE_INTEL_IGD_OPREGION,
+ &intel_vgpu_regops_opregion, OPREGION_SIZE,
+ VFIO_REGION_INFO_FLAG_READ, base);
+ if (ret)
+ memunmap(base);
+
+ return ret;
+}
+
static int intel_vgpu_create(struct kobject *kobj, struct mdev_device *mdev)
{
struct intel_vgpu *vgpu = NULL;
@@ -1524,6 +1611,7 @@ struct intel_gvt_mpt kvmgt_mpt = {
.read_gpa = kvmgt_read_gpa,
.write_gpa = kvmgt_write_gpa,
.gfn_to_mfn = kvmgt_gfn_to_pfn,
+ .set_opregion = kvmgt_set_o
[PATCH v8 1/6] drm/i915/gvt: Extend the GVT-g architecture to support vfio device region
Signed-off-by: Xiaoguang Chen
---
drivers/gpu/drm/i915/gvt/kvmgt.c | 21 ++---
1 file changed, 18 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index 1ae0b40..3c6a02b 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -53,11 +53,21 @@ static const struct intel_gvt_ops *intel_gvt_ops;
#define VFIO_PCI_INDEX_TO_OFFSET(index) ((u64)(index) << VFIO_PCI_OFFSET_SHIFT)
#define VFIO_PCI_OFFSET_MASK(((u64)(1) << VFIO_PCI_OFFSET_SHIFT) - 1)
+struct vfio_region;
+struct intel_vgpu_regops {
+ size_t (*rw)(struct intel_vgpu *vgpu, char *buf,
+ size_t count, loff_t *ppos, bool iswrite);
+ void (*release)(struct intel_vgpu *vgpu,
+ struct vfio_region *region);
+};
+
struct vfio_region {
u32 type;
u32 subtype;
size_t size;
u32 flags;
+ const struct intel_vgpu_regops *ops;
+ void*data;
};
struct kvmgt_pgfn {
@@ -642,7 +652,7 @@ static ssize_t intel_vgpu_rw(struct mdev_device *mdev, char
*buf,
int ret = -EINVAL;
- if (index >= VFIO_PCI_NUM_REGIONS) {
+ if (index >= VFIO_PCI_NUM_REGIONS + vgpu->vdev.num_regions) {
gvt_vgpu_err("invalid index: %u\n", index);
return -EINVAL;
}
@@ -676,8 +686,11 @@ static ssize_t intel_vgpu_rw(struct mdev_device *mdev,
char *buf,
case VFIO_PCI_BAR5_REGION_INDEX:
case VFIO_PCI_VGA_REGION_INDEX:
case VFIO_PCI_ROM_REGION_INDEX:
+ break;
default:
- gvt_vgpu_err("unsupported region: %u\n", index);
+ index -= VFIO_PCI_NUM_REGIONS;
+ return vgpu->vdev.region[index].ops->rw(vgpu, buf, count,
+ ppos, is_write);
}
return ret == 0 ? count : ret;
@@ -940,7 +953,8 @@ static long intel_vgpu_ioctl(struct mdev_device *mdev,
unsigned int cmd,
info.flags = VFIO_DEVICE_FLAGS_PCI;
info.flags |= VFIO_DEVICE_FLAGS_RESET;
- info.num_regions = VFIO_PCI_NUM_REGIONS;
+ info.num_regions = VFIO_PCI_NUM_REGIONS +
+ vgpu->vdev.num_regions;
info.num_irqs = VFIO_PCI_NUM_IRQS;
return copy_to_user((void __user *)arg, &info, minsz) ?
@@ -1061,6 +1075,7 @@ static long intel_vgpu_ioctl(struct mdev_device *mdev,
unsigned int cmd,
}
if (caps.size) {
+ info.flags |= VFIO_REGION_INFO_FLAG_CAPS;
if (info.argsz < sizeof(info) + caps.size) {
info.argsz = sizeof(info) + caps.size;
info.cap_offset = 0;
--
2.7.4
[PATCH v8 5/6] drm/i915/gvt: Dmabuf support for GVT-g
dmabuf for GVT-g can be exported to users who can use the dmabuf to show
the desktop of vm which use intel vgpu.
Currently we provide query and create new dmabuf operations.
Users of dmabuf can cache some created dmabufs and related information
such as the framebuffer's address, size, tiling mode, width, height etc.
When refresh the screen first query the currnet vgpu's frambuffer and
compare with the cached ones(address, size, tiling, width, height etc)
if found one then reuse the found dmabuf to gain performance improvment.
If there is no dmabuf created yet or not found in the cached dmabufs then
need to create a new dmabuf. To create a dmabuf first a gem object will
be created and the backing storage of this gem object is the vgpu's
framebuffer(primary/cursor).
Set caching mode, change tiling mode and set domains of this gem object
is not supported.
Then associate this gem object to a dmabuf and export this dmabuf.
A file descriptor will be generated for this dmabuf and this file
descriptor can be sent to user space to do display.
Signed-off-by: Xiaoguang Chen
Tested-by: Kechen Lu
---
drivers/gpu/drm/i915/gvt/Makefile | 2 +-
drivers/gpu/drm/i915/gvt/dmabuf.c | 263 +
drivers/gpu/drm/i915/gvt/dmabuf.h | 37 +
drivers/gpu/drm/i915/gvt/gvt.h | 1 +
drivers/gpu/drm/i915/i915_gem.c| 26 +++-
drivers/gpu/drm/i915/i915_gem_object.h | 9 ++
drivers/gpu/drm/i915/i915_gem_tiling.c | 5 +
7 files changed, 341 insertions(+), 2 deletions(-)
create mode 100644 drivers/gpu/drm/i915/gvt/dmabuf.c
create mode 100644 drivers/gpu/drm/i915/gvt/dmabuf.h
diff --git a/drivers/gpu/drm/i915/gvt/Makefile
b/drivers/gpu/drm/i915/gvt/Makefile
index 192ca26..e480f7d 100644
--- a/drivers/gpu/drm/i915/gvt/Makefile
+++ b/drivers/gpu/drm/i915/gvt/Makefile
@@ -2,7 +2,7 @@ GVT_DIR := gvt
GVT_SOURCE := gvt.o aperture_gm.o handlers.o vgpu.o trace_points.o firmware.o \
interrupt.o gtt.o cfg_space.o opregion.o mmio.o display.o edid.o \
execlist.o scheduler.o sched_policy.o render.o cmd_parser.o \
- fb_decoder.o
+ fb_decoder.o dmabuf.o
ccflags-y += -I$(src) -I$(src)/$(GVT_DIR) -Wall
i915-y += $(addprefix $(GVT_DIR)/,
$(GVT_SOURCE))
diff --git a/drivers/gpu/drm/i915/gvt/dmabuf.c
b/drivers/gpu/drm/i915/gvt/dmabuf.c
new file mode 100644
index 000..c38ed8e9fc
--- /dev/null
+++ b/drivers/gpu/drm/i915/gvt/dmabuf.c
@@ -0,0 +1,263 @@
+/*
+ * Copyright 2017 Intel Corporation. All rights reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Authors:
+ *Zhiyuan Lv
+ *
+ * Contributors:
+ *Xiaoguang Chen
+ */
+
+#include
+#include
+#include
+
+#include "i915_drv.h"
+#include "gvt.h"
+
+#define GEN8_DECODE_PTE(pte) (pte & GENMASK_ULL(63, 12))
+
+static struct sg_table *intel_vgpu_gem_get_pages(
+ struct drm_i915_gem_object *obj)
+{
+ struct drm_i915_private *dev_priv = to_i915(obj->base.dev);
+ struct sg_table *st;
+ struct scatterlist *sg;
+ int i, ret;
+ gen8_pte_t __iomem *gtt_entries;
+ struct intel_vgpu_fb_info *fb_info;
+
+ fb_info = (struct intel_vgpu_fb_info *)obj->gvt_info;
+ if (WARN_ON(!fb_info))
+ return ERR_PTR(-ENODEV);
+
+ st = kmalloc(sizeof(*st), GFP_KERNEL);
+ if (!st)
+ return ERR_PTR(-ENOMEM);
+
+ ret = sg_alloc_table(st, fb_info->fb_size, GFP_KERNEL);
+ if (ret) {
+ kfree(st);
+ return ERR_PTR(ret);
+ }
+ gtt_entries = (gen8_pte_t __iomem *)dev_priv->ggtt.gsm +
+ (fb_info->fb_addr >> PAGE_SHIFT);
+ for_each_sg(st->sgl, sg, fb_info->fb_size, i) {
+ sg->offset = 0;
+ sg->length = PAGE_SIZE;
+ sg_dma_address(sg) =
+ GEN8_DECODE_PTE(read
[REGRESSION next] gpio-keys broken with commit 2233bf7a92e7 ("gpio: mvebu: switch to regmap for register access")
Hi Thomas,
Commit 2233bf7a92e7 ("gpio: mvebu: switch to regmap for register
access") in next-20170607 breaks gpio-keys on an armada-385 (Linksys
WRT3200ACM), noticed due to missing /dev/input/event0 and the below
dmesg output.
# dmesg -l 0,1,2,3
[2.421130] genirq: Setting trigger mode 3 for irq 49 failed
(mvebu_gpio_irq_set_type+0x0/0x168)
[2.429953] gpio-keys gpio-keys: Unable to claim irq 49; error -22
After reverting the offending commit all works again.
Ralph
Re: [PATCH] staging: wlan-ng: cfg80211.c: fixed a line over 80 characters long
On Thu, Jun 08, 2017 at 11:25:55PM -0700, Elias Carter wrote: > On Fri, Jun 09, 2017 at 07:41:12AM +0200, Greg KH wrote: > > On Thu, Jun 08, 2017 at 06:38:30PM -0700, Elias Carter wrote: > > > From: edcarter > > > > > > Fixed a coding style issue where a line was longer than 80 characters. > > > > > > Signed-off-by: Elias Carter > > > > Your from and signed-off-by names have to match :( > > Hi Greg, thanks for the feedback. > > I fixed the issue but I was wondering if I should include the patch in a > reply to this email or resend a new patch? Totally new patch. > I am just trying to find my way around the development process. You did read Documenation/development_process/ right? Also, please use scripts/get_maintainer.pl to determine who else to cc: patches on. good luck! greg k-h
Re: Sleeping BUG in khugepaged for i586
On 06/08/2017 10:30 PM, Michal Hocko wrote: > But I guess you are primary after syncing the preemptive mode for 64 and > 32b systems, right? I agree that having a different model is more than > unfortunate because 32b gets much less testing coverage and so a risk of > introducing a new bug is just a matter of time. Maybe we should make > pte_offset_map disable preemption and currently noop pte_unmap to > preempt_enable. The overhead should be pretty marginal on x86_64 but not > all arches have per-cpu preempt count. So I am not sure we really want > to add this to just for the debugging purposes... I think adding that overhead for everyone would be unfortunate. It would be acceptable, if it was done only for the config option that enables the might_sleep() checks (CONFIG_DEBUG_ATOMIC_SLEEP?) Vlastimil
linux-next: Tree for Jun 9
Hi all,
Changes since 20170608:
The net tree lost its build failure.
The drm tree gained a conflict against the drm-intel-fixes tree.
The sound-asoc tree lost its build failure.
The device-mapper tree gained a build failure so I used the version
from next-20170608.
The devicetree tree gained a conflict against the renesas tree.
The kvms390 tree gained a conflict against the kvm-arm tree.
The uuid tree lost its build failure but gained another, so I have used
the version from next-20170607.
The akpm-current tree still had its build failure for which I reverted
a commit.
Non-merge commits (relative to Linus' tree): 5193
5322 files changed, 197077 insertions(+), 108218 deletions(-)
I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one. You should use "git fetch" and checkout or reset to the new
master.
You can see which trees have been included by looking in the Next/Trees
file in the source. There are also quilt-import.log and merge.log
files in the Next directory. Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And
finally, a simple boot test of the powerpc pseries_le_defconfig kernel
in qemu.
Below is a summary of the state of the merge.
I am currently merging 264 trees (counting Linus' and 41 trees of bug
fix patches pending for the current merge release).
Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .
Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next . If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.
Thanks to Randy Dunlap for doing many randconfig builds. And to Paul
Gortmaker for triage and bug fixes.
--
Cheers,
Stephen Rothwell
$ git checkout master
$ git reset --hard stable
Merging origin/master (aea4156c3086 Merge tag 'modules-for-v4.12-rc5' of
git://git.kernel.org/pub/scm/linux/kernel/git/jeyu/linux)
Merging fixes/master (97da3854c526 Linux 4.11-rc3)
Merging kbuild-current/fixes (9ba26a7283f5 Kbuild: tiny correction on `make
help`)
Merging arc-current/for-curr (f90b8bf8dbe7 hsdk: initial port for HSDK board)
Merging arm-current/fixes (06a4b6d009a1 ARM: 8677/1: boot/compressed: fix
decompressor header layout for v7-M)
Merging m68k-current/for-linus (f6ab4d59a5fe nubus: Add MVC and VSC video card
definitions)
Merging metag-fixes/fixes (b884a190afce metag/usercopy: Add missing fixups)
Merging powerpc-fixes/fixes (c6ee9619e2ed powerpc/book3s64: Move
PPC_DT_CPU_FTRs and enable it by default)
Merging sparc/master (b3aefc2fbdff Merge branch 'sparc64-context-wrap-fixes')
Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and
linking special files)
Merging net/master (097d3c9508dc net: vrf: Make add_fib_rules per network
namespace flag)
Merging ipsec/master (b81f884a547b xfrm: fix xfrm_dev_event() missing when
compile without CONFIG_XFRM_OFFLOAD)
Merging netfilter/master (468b0df61a51 Merge
git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf)
Merging ipvs/master (3c5ab3f395d6 ipvs: SNAT packet replies only for NATed
connections)
Merging wireless-drivers/master (dc89481bb4c9 Merge tag
'iwlwifi-for-kalle-2017-06-05' of
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes)
Merging mac80211/master (f0fd108e141d mac80211: don't look at the PM bit of BAR
frames)
Merging sound-current/for-linus (ba3021b2c79b ALSA: timer: Fix missing queue
indices reset at SNDRV_TIMER_IOCTL_SELECT)
Merging pci-current/for-linus (bd2df9b1e094 PCI: Make error code types
consistent in pci_{read,write}_config_*)
Merging driver-core.current/driver-core-linus (08332893e37a Linux 4.12-rc2)
Merging tty.current/tty-linus (3c2993b8c614 Linux 4.12-rc4)
Merging usb.current/usb-linus (29532e7b67f0 Merge tag 'phy-for-4.12-rc-v2' of
git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy into usb-linus)
Merging usb-gadget-fixes/fixes (afbbc7913a28 usb: gadget: udc: renesas_usb3:
Fix PN_INT_ENA disabling timing)
Merging usb-serial-fixes/usb-linus (5ed02dbb4974 Linux 4.12-rc3)
Merging usb-chipidea-fixes/ci-for-usb-stable (cbb22ebcfb99 usb: chipidea: core:
check before accessing ci_role in ci_role_show)
Re: WMI and Kernel:User interface
On Sat, Jun 03, 2017 at 12:50:58PM -0700, Darren Hart wrote: > On Wed, May 10, 2017 at 07:13:41AM +0200, Greg Kroah-Hartman wrote: > > On Tue, May 09, 2017 at 04:16:39PM -0700, Darren Hart wrote: > > > Linus and Greg, > > > > > > We are in the process of redesigning the Windows Management > > > Instrumentation > > > (WMI) [1] system in the kernel. WMI is the Microsoft implementation of > > > Web-Based > > > Enterprise Management (WBEM). We are looking to provide WMI access to > > > userspace, > > > while allowing the kernel to filter requests that conflict with its own > > > usage. > > > We'd like your take on how this approach relates to our commitment to not > > > break > > > userspace. > > > > > > For this discussion, we are specifically referring to ACPI PNP0C14 WMI > > > devices, consisting of a GUID and a set of methods and events, as well as > > > a > > > precompiled intermediate description of the methods and arguments (MOF). > > > Exposed > > > to userspace, these methods provide for BIOS interaction and are used for > > > system > > > management as well as LEDs, hot keys, radio switches, etc. There is vendor > > > interest in achieving feature parity with Windows by exposing WMI methods > > > to > > > userspace for system management. > > > > > > While it appears WMI intended to be accessed from userspace, we have > > > made use of it in the kernel to support various laptop features by > > > connecting > > > the WMI methods to other subsystems, notably input, leds, and rfkill [2]. > > > The > > > challenge is continuing to use WMI for these platform features, while > > > allowing > > > userspace to use it for system management tasks. Unfortunately, the WMI > > > methods > > > are not guaranteed to be split up along granular functional lines, and we > > > will > > > certainly face situations where the same GUID::METHOD_ID will be needed > > > for a > > > kernel feature (say LED support) as well as a system management task. > > > > > > To address this, I have proposed [3] that exporting WMI be opt-in, only > > > done at > > > the request of and in collaboration with a vendor, with the kernel > > > platform > > > driver given the opportunity to filter requests. This filtering would > > > need to be > > > at the method and argument inspection level, such as checking for > > > specific bits > > > in the input buffer, and rejecting the request if they conflict with an in > > > kernel usage (that's worst case, in some cases just GUID or method ID > > > could be > > > sufficient). > > > > > > Because the kernel and the platform drivers are under continual > > > development, and > > > new systems appear regularly, we will encounter necessary changes to the > > > platform driver WMI request filters. These changes could be considered a > > > change > > > to the kernel provided WMI interface to userspace. For example, we could > > > regularly accept a call to $GUID::$METHOD_ID with bit 4 of the buffer > > > set, and > > > later deny the call when we determine it interferes with kernel usage. > > > > > > In your view, is it acceptable to provide a chardev interface, for > > > example, > > > exposing WMI methods to userspace, with the understanding that the kernel > > > may > > > choose to filter certain requests which conflict with its own use? And > > > that this > > > filtering may change as new features are added to the platform drivers? > > > > So, for example, if a new driver for a "brightness key" were added to > > the kernel, all of a sudden the "raw" access to the wmi data through the > > chardev would filtered away by the kernel and not seen by userspace? > > > > Why would you want to do that? What's wrong with providing "raw" access > > through a chardev, and the current in-kernel access as well at the same > > time? > > > > I don't really understand what would "break" over time here. > > > > Just a bump now that we're out of the merge window in case either Greg or > Linus > care to follow up with the responses to this. > > To Greg's last point - any kernel state that is built up in conjunction with > the > WMI interface could be invalidated by a userspace application. It may or may > not > be recoverable, depending on the WMI implementation. This would be true for > multiple WMI userspace applications as well, and I suppose the question is, do > we defend the kernel drivers against this, or do we consider the kernel > drivers > on equal footing with WMI applications, and say "don't do that then" when some > combination of apps and drivers don't play well together? In the end, this shouldn't really matter, as long as nothing breaks as far as a user notices. And that's the key here, apis can change, but if you do it in a way that breaks something, or anyone notices, then it's not ok. So I don't have a solid answer other than "good luck!" :) greg k-h
[PATCH] ARM: dts: ls1021a: update the clockgen node
qoriq clock driver has been updated to parse the clock configuration
information defined in driver itself not in dts.
Since the new implementation and the bindings have been merged,
it is time to update the clock related node and remove redundent clock
configuration information from the dts.
Signed-off-by: Tang Yuantian
---
arch/arm/boot/dts/ls1021a.dtsi | 90 --
1 file changed, 33 insertions(+), 57 deletions(-)
diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
index 45ea57f..7bb9df2 100644
--- a/arch/arm/boot/dts/ls1021a.dtsi
+++ b/arch/arm/boot/dts/ls1021a.dtsi
@@ -75,7 +75,7 @@
compatible = "arm,cortex-a7";
device_type = "cpu";
reg = <0xf00>;
- clocks = <&cluster1_clk>;
+ clocks = <&clockgen 1 0>;
#cooling-cells = <2>;
};
@@ -83,10 +83,17 @@
compatible = "arm,cortex-a7";
device_type = "cpu";
reg = <0xf01>;
- clocks = <&cluster1_clk>;
+ clocks = <&clockgen 1 0>;
};
};
+ sysclk: sysclk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <1>;
+ clock-output-names = "sysclk";
+ };
+
timer {
compatible = "arm,armv7-timer";
interrupts = ,
@@ -165,7 +172,7 @@
<0x0 0x20220520 0x0 0x4>;
reg-names = "ahci", "sata-ecc";
interrupts = ;
- clocks = <&platform_clk 1>;
+ clocks = <&clockgen 4 1>;
dma-coherent;
status = "disabled";
};
@@ -216,41 +223,10 @@
};
clockgen: clocking@1ee1000 {
- #address-cells = <1>;
- #size-cells = <1>;
- ranges = <0x0 0x0 0x1ee1000 0x1>;
-
- sysclk: sysclk {
- compatible = "fixed-clock";
- #clock-cells = <0>;
- clock-output-names = "sysclk";
- };
-
- cga_pll1: pll@800 {
- compatible = "fsl,qoriq-core-pll-2.0";
- #clock-cells = <1>;
- reg = <0x800 0x10>;
- clocks = <&sysclk>;
- clock-output-names = "cga-pll1",
"cga-pll1-div2",
-"cga-pll1-div4";
- };
-
- platform_clk: pll@c00 {
- compatible = "fsl,qoriq-core-pll-2.0";
- #clock-cells = <1>;
- reg = <0xc00 0x10>;
- clocks = <&sysclk>;
- clock-output-names = "platform-clk",
"platform-clk-div2";
- };
-
- cluster1_clk: clk0c0@0 {
- compatible = "fsl,qoriq-core-mux-2.0";
- #clock-cells = <0>;
- reg = <0x0 0x10>;
- clock-names = "pll1cga", "pll1cga-div2",
"pll1cga-div4";
- clocks = <&cga_pll1 0>, <&cga_pll1 1>,
<&cga_pll1 2>;
- clock-output-names = "cluster1-clk";
- };
+ compatible = "fsl,ls1021a-clockgen";
+ reg = <0x0 0x1ee1000 0x0 0x1000>;
+ #clock-cells = <2>;
+ clocks = <&sysclk>;
};
tmu: tmu@1f0 {
@@ -338,7 +314,7 @@
reg = <0x0 0x210 0x0 0x1>;
interrupts = ;
clock-names = "dspi";
- clocks = <&platform_clk 1>;
+ clocks = <&clockgen 4 1>;
spi-num-chipselects = <6>;
big-endian;
status = "disabled";
@@ -351,7 +327,7 @@
reg = <0x0 0x211 0x0 0x1>;
interrupts = ;
clock-names = "dspi";
- clocks = <&platform_clk 1>;
+ clocks = <&clockgen 4 1>;
spi-num-chipselects = <6>;
big-endian;
status = "disabled";
@@ -364,7 +340,7 @@
reg = <0x0 0x218 0x0 0x1>;
interrupts = ;
clock-names = "i2c";
-
Re: [lkp-robot] [KEYS] 501901ac94: ltp.add_key02.fail
On 06/09, David Howells wrote: >kernel test robot wrote: > >> user :notice: [ 82.772613] add_key02.c:65: FAIL: add_key() failed >> unexpectedly, expected EINVAL: EFAULT > >The LTP test needs updating. Eric has a patch for that. Got it, thanks for the information. Thanks, Xiaolong > >David
Re: [PATCH] staging: wlan-ng: cfg80211.c: fixed a line over 80 characters long
On Fri, Jun 09, 2017 at 07:41:12AM +0200, Greg KH wrote: > On Thu, Jun 08, 2017 at 06:38:30PM -0700, Elias Carter wrote: > > From: edcarter > > > > Fixed a coding style issue where a line was longer than 80 characters. > > > > Signed-off-by: Elias Carter > > Your from and signed-off-by names have to match :( Hi Greg, thanks for the feedback. I fixed the issue but I was wondering if I should include the patch in a reply to this email or resend a new patch? I am just trying to find my way around the development process.
Re: [RFC 00/10] V4L2 explicit synchronization support
2017-06-08 Shuah Khan : > Hi Gustavo, > > On Thu, Jun 8, 2017 at 2:17 PM, Mauro Carvalho Chehab > wrote: > > Hi Gustavo, > > > > Em Wed, 24 May 2017 21:31:01 -0300 > > Gustavo Padovan escreveu: > > > >> Hi all, > >> > >> I've been working on the v2 of this series, but I think I hit a blocker > >> when trying to cover the case where the driver asks to requeue the > >> buffer. It is related to the out-fence side. > >> > >> In the current implementation we return on QBUF an out-fence fd that is not > >> tied to any buffer, because we don't know the queueing order until the > >> buffer is queued to the driver. Then when the buffer is queued we use > >> the BUF_QUEUED event to notify userspace of the index of the buffer, > >> so now userspace knows the buffer associated to the out-fence fd > >> received earlier. > >> > >> Userspace goes ahead and send a DRM Atomic Request to the kernel to > >> display that buffer on the screen once the fence signals. If it is > >> a nonblocking request the fence waiting is past the check phase, thus > >> it isn't allowed to fail anymore. > >> > >> But now, what happens if the V4L2 driver calls buffer_done() asking > >> to requeue the buffer. That means the operation failed and can't > >> signal the fence, starving the DRM side. > >> > >> We need to fix that. The only way I can see is to guarantee ordering of > >> buffers when out-fences are used. Ordering is something that HAL3 needs > >> to so maybe there is more than one reason to do it like this. I'm not > >> a V4L2 expert, so I don't know all the consequences of such a change. > >> > >> Any other ideas? > >> > >> The current patchset is at: > >> > >> https://git.kernel.org/pub/scm/linux/kernel/git/padovan/linux.git/log/?h=v4l2-fences > > Do you plan to send the v2 out? I did a quick review and have a few comments. > > [media] vb2: split out queueing from vb_core_qbuf() > > It changes the sequence a bit. > > /* Fill buffer information for the userspace */ > if (pb) > call_void_bufop(q, fill_user_buffer, vb, pb); > > With the changes - user information is filled before __enqueue_in_driver(vb); Without my changes it also fills it before __enqueue_in_driver() when start_streaming wasn't called yet. So I don't think it really matters. > > Anyway, it might be a good idea to send the v2 out for review and we can > review > patches in detail. I am hoping to test your patch series on odroid-xu4 > next week. > Could you please add me to the thread as well as include me when you send > v2 and subsequent versions. I will send a v2 as soon as I can, but from Thursday next week until the 25th I'll be on vacation. Gustavo
[PATCH v11 02/12] sun4i-codec: Add Differential Line Capture Switch and its routes
Signed-off-by: Danny Milosavljevic
---
sound/soc/sunxi/sun4i-codec.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
index 2f65aa72..a2435c6e 100644
--- a/sound/soc/sunxi/sun4i-codec.c
+++ b/sound/soc/sunxi/sun4i-codec.c
@@ -96,6 +96,7 @@
#define SUN4I_CODEC_ADC_ACTL_VMICEN(27)
#define SUN4I_CODEC_ADC_ACTL_VADCG (20)
#define SUN4I_CODEC_ADC_ACTL_ADCIS (17)
+#define SUN4I_CODEC_ADC_ACTL_LNRDF (16)
#define SUN4I_CODEC_ADC_ACTL_PA_EN (4)
#define SUN4I_CODEC_ADC_ACTL_DDE (3)
#define SUN4I_CODEC_ADC_DEBUG (0x2c)
@@ -644,6 +645,20 @@ static const struct snd_kcontrol_new sun4i_codec_pa_mute =
static DECLARE_TLV_DB_SCALE(sun4i_codec_pa_volume_scale, -6300, 100, 1);
+static const char * const sun4i_codec_difflinein_capture_source[] = {
+ "Stereo",
+ "Differential",
+};
+
+static SOC_ENUM_SINGLE_DECL(sun4i_codec_enum_difflinein_capture_source,
+ SUN4I_CODEC_ADC_ACTL,
+ SUN4I_CODEC_ADC_ACTL_LNRDF,
+ sun4i_codec_difflinein_capture_source);
+
+static const struct snd_kcontrol_new
sun4i_codec_difflinein_capture_source_controls =
+ SOC_DAPM_ENUM("Differential Line Capture Switch",
+ sun4i_codec_enum_difflinein_capture_source);
+
static const struct snd_kcontrol_new sun4i_codec_controls[] = {
SOC_SINGLE_TLV("Power Amplifier Volume", SUN4I_CODEC_DAC_ACTL,
SUN4I_CODEC_DAC_ACTL_PA_VOL, 0x3F, 0,
@@ -720,6 +735,12 @@ static const struct snd_soc_dapm_widget
sun4i_codec_codec_dapm_widgets[] = {
SND_SOC_DAPM_SWITCH("Power Amplifier Mute", SND_SOC_NOPM, 0, 0,
&sun4i_codec_pa_mute),
+ /* MUX */
+ SND_SOC_DAPM_MUX("Differential Line Capture Switch", SND_SOC_NOPM,
+0,
+0,
+&sun4i_codec_difflinein_capture_source_controls),
+
/* Inputs */
SND_SOC_DAPM_INPUT("Mic1"),
SND_SOC_DAPM_INPUT("Mic2"),
@@ -767,6 +788,11 @@ static const struct snd_soc_dapm_route
sun4i_codec_codec_dapm_routes[] = {
{ "Right ADC", NULL, "MIC1 Pre-Amplifier" },
{ "MIC1 Pre-Amplifier", NULL, "Mic1"},
{ "Mic1", NULL, "VMIC" },
+
+ /* LNRDF Routes */
+ { "Differential Line Capture Switch", "Differential", "Line Left" },
+ { "Differential Line Capture Switch", "Differential", "Line Right" },
+
};
static struct snd_soc_codec_driver sun4i_codec_codec = {
[PATCH v11 04/12] sun4i-codec: Add Mic1 Capture Volume, Mic2 Capture Volume.
Signed-off-by: Danny Milosavljevic
---
sound/soc/sunxi/sun4i-codec.c | 41 +
1 file changed, 41 insertions(+)
diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
index b5a3b5b3..25870a64 100644
--- a/sound/soc/sunxi/sun4i-codec.c
+++ b/sound/soc/sunxi/sun4i-codec.c
@@ -97,6 +97,8 @@
#define SUN4I_CODEC_ADC_ACTL_PREG1EN (29)
#define SUN4I_CODEC_ADC_ACTL_PREG2EN (28)
#define SUN4I_CODEC_ADC_ACTL_VMICEN(27)
+#define SUN4I_CODEC_ADC_ACTL_PREG1 (25)
+#define SUN4I_CODEC_ADC_ACTL_PREG2 (23)
#define SUN4I_CODEC_ADC_ACTL_ADCG (20)
#define SUN4I_CODEC_ADC_ACTL_ADCIS (17)
#define SUN4I_CODEC_ADC_ACTL_LNRDF (16)
@@ -115,6 +117,9 @@
/* Microphone controls (sun7i only) */
#define SUN7I_CODEC_AC_MIC_PHONE_CAL (0x3c)
+#define SUN7I_CODEC_AC_MIC_PHONE_CAL_PREG1 (29)
+#define SUN7I_CODEC_AC_MIC_PHONE_CAL_PREG2 (26)
+
/*
* sun6i specific registers
*
@@ -665,6 +670,12 @@ static
DECLARE_TLV_DB_SCALE(sun4i_codec_micin_loopback_gain_scale,
150,
0);
static DECLARE_TLV_DB_SCALE(sun4i_codec_adc_gain_scale, -450, 150, 0);
+static DECLARE_TLV_DB_RANGE(sun4i_codec_micin_preamp_gain_scale,
+ 0, 0, TLV_DB_SCALE_ITEM(0, 0, 0),
+ 1, 7, TLV_DB_SCALE_ITEM(3500, 300, 0));
+static DECLARE_TLV_DB_RANGE(sun7i_codec_micin_preamp_gain_scale,
+ 0, 0, TLV_DB_SCALE_ITEM(0, 0, 0),
+ 1, 7, TLV_DB_SCALE_ITEM(2400, 300, 0));
static const char * const sun4i_codec_difflinein_capture_source[] = {
"Stereo",
@@ -718,6 +729,36 @@ static const struct snd_kcontrol_new
sun4i_codec_controls[] = {
sun4i_codec_adc_gain_scale),
};
+static const struct snd_kcontrol_new sun4i_codec_extra_controls[] = {
+ SOC_SINGLE_TLV("Mic1 Capture Volume",
+ SUN4I_CODEC_ADC_ACTL,
+ SUN4I_CODEC_ADC_ACTL_PREG1,
+ 3,
+ 0,
+ sun4i_codec_micin_preamp_gain_scale),
+ SOC_SINGLE_TLV("Mic2 Capture Volume",
+ SUN4I_CODEC_ADC_ACTL,
+ SUN4I_CODEC_ADC_ACTL_PREG2,
+ 3,
+ 0,
+ sun4i_codec_micin_preamp_gain_scale),
+};
+
+static const struct snd_kcontrol_new sun7i_codec_extra_controls[] = {
+ SOC_SINGLE_TLV("Mic1 Capture Volume",
+ SUN7I_CODEC_AC_MIC_PHONE_CAL,
+ SUN7I_CODEC_AC_MIC_PHONE_CAL_PREG1,
+ 7,
+ 0,
+ sun7i_codec_micin_preamp_gain_scale),
+ SOC_SINGLE_TLV("Mic2 Capture Volume",
+ SUN7I_CODEC_AC_MIC_PHONE_CAL,
+ SUN7I_CODEC_AC_MIC_PHONE_CAL_PREG2,
+ 7,
+ 0,
+ sun7i_codec_micin_preamp_gain_scale),
+};
+
static const struct snd_kcontrol_new sun4i_codec_left_mixer_controls[] = {
SOC_DAPM_SINGLE("Left DAC Playback Switch", SUN4I_CODEC_DAC_ACTL,
SUN4I_CODEC_DAC_ACTL_LDACLMIXS, 1, 0),
Re: [lkp-robot] [KEYS] 501901ac94: ltp.add_key02.fail
kernel test robot wrote: > user :notice: [ 82.772613] add_key02.c:65: FAIL: add_key() failed > unexpectedly, expected EINVAL: EFAULT The LTP test needs updating. Eric has a patch for that. David
[PATCH v11 06/12] sun4i-codec: Add support for extra controls to struct sun4i_codec_quirks and use them.
Signed-off-by: Danny Milosavljevic
---
sound/soc/sunxi/sun4i-codec.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
index f56a59ad..b1da14d1 100644
--- a/sound/soc/sunxi/sun4i-codec.c
+++ b/sound/soc/sunxi/sun4i-codec.c
@@ -897,9 +897,22 @@ struct sun4i_codec_quirks {
unsigned int reg_dac_txdata;/* TX FIFO offset for DMA config */
unsigned int reg_adc_rxdata;/* RX FIFO offset for DMA config */
bool has_reset;
+ const struct snd_kcontrol_new *controls;
+ unsigned int num_controls;
};
+static int sun4i_codec_codec_probe(struct snd_soc_codec *scodec)
+{
+ const struct sun4i_codec_quirks *quirks;
+
+ quirks = of_device_get_match_data(scodec->dev);
+ return snd_soc_add_codec_controls(scodec,
+ quirks->controls,
+ quirks->num_controls);
+}
+
static struct snd_soc_codec_driver sun4i_codec_codec = {
+ .probe = sun4i_codec_codec_probe,
.component_driver = {
.controls = sun4i_codec_controls,
.num_controls = ARRAY_SIZE(sun4i_codec_controls),
[PATCH v11 11/12] sun4i-codec: Add MIC2 Pre-Amplifier.
Signed-off-by: Danny Milosavljevic
---
sound/soc/sunxi/sun4i-codec.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
index 730f6151..a9e10dce 100644
--- a/sound/soc/sunxi/sun4i-codec.c
+++ b/sound/soc/sunxi/sun4i-codec.c
@@ -860,6 +860,8 @@ static const struct snd_soc_dapm_widget
sun4i_codec_codec_dapm_widgets[] = {
/* Mic Pre-Amplifiers */
SND_SOC_DAPM_PGA("MIC1 Pre-Amplifier", SUN4I_CODEC_ADC_ACTL,
SUN4I_CODEC_ADC_ACTL_PREG1EN, 0, NULL, 0),
+ SND_SOC_DAPM_PGA("MIC2 Pre-Amplifier", SUN4I_CODEC_ADC_ACTL,
+SUN4I_CODEC_ADC_ACTL_PREG2EN, 0, NULL, 0),
/* Power Amplifier */
SND_SOC_DAPM_MIXER("Power Amplifier", SUN4I_CODEC_ADC_ACTL,
[PATCH v11 08/12] sun4i-codec: Merge sun4i_codec_left_mixer_controls and sun4i_codec_right_mixer_controls into sun4i_codec_mixer_controls.
Signed-off-by: Danny Milosavljevic
---
sound/soc/sunxi/sun4i-codec.c | 21 +
1 file changed, 9 insertions(+), 12 deletions(-)
diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
index d453af65..07ed4fd4 100644
--- a/sound/soc/sunxi/sun4i-codec.c
+++ b/sound/soc/sunxi/sun4i-codec.c
@@ -759,15 +759,12 @@ static const struct snd_kcontrol_new
sun7i_codec_extra_controls[] = {
sun7i_codec_micin_preamp_gain_scale),
};
-static const struct snd_kcontrol_new sun4i_codec_left_mixer_controls[] = {
- SOC_DAPM_SINGLE("Left DAC Playback Switch", SUN4I_CODEC_DAC_ACTL,
- SUN4I_CODEC_DAC_ACTL_LDACLMIXS, 1, 0),
-};
-
-static const struct snd_kcontrol_new sun4i_codec_right_mixer_controls[] = {
- SOC_DAPM_SINGLE("Right DAC Playback Switch", SUN4I_CODEC_DAC_ACTL,
+static const struct snd_kcontrol_new sun4i_codec_mixer_controls[] = {
+ SOC_DAPM_DOUBLE("DAC Playback Switch",
+ SUN4I_CODEC_DAC_ACTL,
+ SUN4I_CODEC_DAC_ACTL_LDACLMIXS,
SUN4I_CODEC_DAC_ACTL_RDACRMIXS, 1, 0),
- SOC_DAPM_SINGLE("Left DAC Playback Switch", SUN4I_CODEC_DAC_ACTL,
+ SOC_DAPM_SINGLE("Right Mixer Left DAC Playback Switch",
SUN4I_CODEC_DAC_ACTL,
SUN4I_CODEC_DAC_ACTL_LDACRMIXS, 1, 0),
};
@@ -803,11 +800,11 @@ static const struct snd_soc_dapm_widget
sun4i_codec_codec_dapm_widgets[] = {
/* Mixers */
SND_SOC_DAPM_MIXER("Left Mixer", SND_SOC_NOPM, 0, 0,
- sun4i_codec_left_mixer_controls,
- ARRAY_SIZE(sun4i_codec_left_mixer_controls)),
+ sun4i_codec_mixer_controls,
+ ARRAY_SIZE(sun4i_codec_mixer_controls)),
SND_SOC_DAPM_MIXER("Right Mixer", SND_SOC_NOPM, 0, 0,
- sun4i_codec_right_mixer_controls,
- ARRAY_SIZE(sun4i_codec_right_mixer_controls)),
+ sun4i_codec_mixer_controls,
+ ARRAY_SIZE(sun4i_codec_mixer_controls)),
/* Global Mixer Enable */
SND_SOC_DAPM_SUPPLY("Mixer Enable", SUN4I_CODEC_DAC_ACTL,
[PATCH v11 12/12] sun4i-codec: Add routes for playback switches, Mic2, Capture Select.
Signed-off-by: Danny Milosavljevic
---
sound/soc/sunxi/sun4i-codec.c | 51 ---
1 file changed, 48 insertions(+), 3 deletions(-)
diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
index a9e10dce..315d79a3 100644
--- a/sound/soc/sunxi/sun4i-codec.c
+++ b/sound/soc/sunxi/sun4i-codec.c
@@ -905,12 +905,20 @@ static const struct snd_soc_dapm_route
sun4i_codec_codec_dapm_routes[] = {
/* Right Mixer Routes */
{ "Right Mixer", NULL, "Mixer Enable" },
- { "Right Mixer", "Left DAC Playback Switch", "Left DAC" },
- { "Right Mixer", "Right DAC Playback Switch", "Right DAC" },
+ { "Right Mixer", "Right Mixer Left DAC Playback Switch", "Left DAC" },
+ { "Right Mixer", "DAC Playback Switch", "Right DAC" },
+ { "Right Mixer", "Mic1 Playback Switch", "MIC1 Pre-Amplifier" },
+ { "Right Mixer", "Mic2 Playback Switch", "MIC2 Pre-Amplifier" },
+ { "Right Mixer", "Line Playback Switch", "Line Right" },
+ { "Right Mixer", "FM Playback Switch", "FM Right" },
/* Left Mixer Routes */
{ "Left Mixer", NULL, "Mixer Enable" },
- { "Left Mixer", "Left DAC Playback Switch", "Left DAC" },
+ { "Left Mixer", "DAC Playback Switch", "Left DAC" },
+ { "Left Mixer", "Mic1 Playback Switch", "MIC1 Pre-Amplifier" },
+ { "Left Mixer", "Mic2 Playback Switch", "MIC2 Pre-Amplifier" },
+ { "Left Mixer", "Line Playback Switch", "Line Left" },
+ { "Left Mixer", "FM Playback Switch", "FM Left" },
/* Power Amplifier Routes */
{ "Power Amplifier", "Mixer Playback Switch", "Left Mixer" },
@@ -928,11 +936,48 @@ static const struct snd_soc_dapm_route
sun4i_codec_codec_dapm_routes[] = {
{ "Right ADC", NULL, "MIC1 Pre-Amplifier" },
{ "MIC1 Pre-Amplifier", NULL, "Mic1"},
{ "Mic1", NULL, "VMIC" },
+ /* see also Left Mixer Routes, Right Mixer Routes */
+
+ /* Mic2 Routes */
+ { "Left ADC", NULL, "MIC2 Pre-Amplifier" },
+ { "Right ADC", NULL, "MIC2 Pre-Amplifier" },
+ { "MIC2 Pre-Amplifier", NULL, "Mic2"},
+ { "Mic2", NULL, "VMIC" },
+ /* see also Left Mixer Routes, Right Mixer Routes */
+
+ /* Line, FM Routes */
+ /* see also Left Mixer Routes, Right Mixer Routes */
/* LNRDF Routes */
{ "Differential Line Capture Switch", "Differential", "Line Left" },
{ "Differential Line Capture Switch", "Differential", "Line Right" },
+ /* Right ADC Input Routes */
+ { "Right Capture Select", "Line", "Line Right" },
+ { "Right Capture Select", "Line", "Differential Line Capture Switch" },
+ { "Right Capture Select", "FM", "FM Right" },
+ { "Right Capture Select", "Mic1", "MIC1 Pre-Amplifier" },
+ { "Right Capture Select", "Mic2", "MIC2 Pre-Amplifier" },
+ { "Right Capture Select", "Mic1,Mic2", "MIC2 Pre-Amplifier" },
+ { "Right Capture Select", "Mic1+Mic2", "MIC2 Pre-Amplifier" },
+ { "Right Capture Select", "Mic1+Mic2", "MIC1 Pre-Amplifier" },
+ { "Right Capture Select", "Output Mixer", "Right Mixer" },
+ { "Right Capture Select", "Line,Mic1", "MIC1 Pre-Amplifier" },
+ { "Right ADC", NULL, "Right Capture Select" },
+
+ /* Left ADC Input Routes */
+ { "Left Capture Select", "Line", "Line Left" },
+ { "Left Capture Select", "Line", "Differential Line Capture Switch" },
+ { "Left Capture Select", "FM", "FM Left" },
+ { "Left Capture Select", "Mic1", "MIC1 Pre-Amplifier" },
+ { "Left Capture Select", "Mic2", "MIC2 Pre-Amplifier" },
+ { "Left Capture Select", "Mic1,Mic2", "MIC1 Pre-Amplifier" },
+ { "Left Capture Select", "Mic1+Mic2", "MIC1 Pre-Amplifier" },
+ { "Left Capture Select", "Mic1+Mic2", "MIC2 Pre-Amplifier" },
+ { "Left Capture Select", "Output Mixer", "Left Mixer" },
+ { "Left Capture Select", "Line,Mic1", "Line Left" },
+ { "Left Capture Select", "Line,Mic1", "Differential Line Capture
Switch" },
+ { "Left ADC", NULL, "Left Capture Select" },
};
struct sun4i_codec_quirks {
[PATCH v11 07/12] sun4i-codec: Add extra controls to sun4i_codec_quirks, sun7i_codec_quirks.
Signed-off-by: Danny Milosavljevic
---
sound/soc/sunxi/sun4i-codec.c | 4
1 file changed, 4 insertions(+)
diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
index b1da14d1..d453af65 100644
--- a/sound/soc/sunxi/sun4i-codec.c
+++ b/sound/soc/sunxi/sun4i-codec.c
@@ -1576,6 +1576,8 @@ static const struct sun4i_codec_quirks sun4i_codec_quirks
= {
.reg_adc_fifoc = REG_FIELD(SUN4I_CODEC_ADC_FIFOC, 0, 31),
.reg_dac_txdata = SUN4I_CODEC_DAC_TXDATA,
.reg_adc_rxdata = SUN4I_CODEC_ADC_RXDATA,
+ .controls = sun4i_codec_extra_controls,
+ .num_controls = ARRAY_SIZE(sun4i_codec_extra_controls),
};
static const struct sun4i_codec_quirks sun6i_a31_codec_quirks = {
@@ -1595,6 +1597,8 @@ static const struct sun4i_codec_quirks sun7i_codec_quirks
= {
.reg_adc_fifoc = REG_FIELD(SUN4I_CODEC_ADC_FIFOC, 0, 31),
.reg_dac_txdata = SUN4I_CODEC_DAC_TXDATA,
.reg_adc_rxdata = SUN4I_CODEC_ADC_RXDATA,
+ .controls = sun7i_codec_extra_controls,
+ .num_controls = ARRAY_SIZE(sun7i_codec_extra_controls),
};
static const struct sun4i_codec_quirks sun8i_a23_codec_quirks = {
[PATCH v11 10/12] sun4i-codec: Add Left Capture Select, Right Capture Select.
Signed-off-by: Danny Milosavljevic
---
sound/soc/sunxi/sun4i-codec.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
index 21ece880..730f6151 100644
--- a/sound/soc/sunxi/sun4i-codec.c
+++ b/sound/soc/sunxi/sun4i-codec.c
@@ -685,6 +685,25 @@ static
DECLARE_TLV_DB_RANGE(sun7i_codec_micin_preamp_gain_scale,
0, 0, TLV_DB_SCALE_ITEM(0, 0, 0),
1, 7, TLV_DB_SCALE_ITEM(2400, 300, 0));
+static const char * const sun4i_codec_capture_source[] = {
+ "Line",
+ "FM",
+ "Mic1",
+ "Mic2",
+ "Mic1,Mic2",
+ "Mic1+Mic2",
+ "Output Mixer",
+ "Line,Mic1",
+};
+
+static SOC_ENUM_SINGLE_DECL(sun4i_codec_enum_capture_source,
+ SUN4I_CODEC_ADC_ACTL,
+ SUN4I_CODEC_ADC_ACTL_ADCIS,
+ sun4i_codec_capture_source);
+
+static const struct snd_kcontrol_new sun4i_codec_capture_source_controls =
+ SOC_DAPM_ENUM("Capture Source", sun4i_codec_enum_capture_source);
+
static const char * const sun4i_codec_difflinein_capture_source[] = {
"Stereo",
"Differential",
@@ -851,6 +870,10 @@ static const struct snd_soc_dapm_widget
sun4i_codec_codec_dapm_widgets[] = {
&sun4i_codec_pa_mute),
/* MUX */
+ SND_SOC_DAPM_MUX("Left Capture Select", SND_SOC_NOPM, 0, 0,
+&sun4i_codec_capture_source_controls),
+ SND_SOC_DAPM_MUX("Right Capture Select", SND_SOC_NOPM, 0, 0,
+&sun4i_codec_capture_source_controls),
SND_SOC_DAPM_MUX("Differential Line Capture Switch", SND_SOC_NOPM,
0,
0,
[PATCH v11 09/12] sun4i-codec: Add Line Playback Switch, FM Playback Switch, Mic1 Playback Switch, Mic2 Playback Switch.
Signed-off-by: Danny Milosavljevic
---
sound/soc/sunxi/sun4i-codec.c | 24
1 file changed, 24 insertions(+)
diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
index 07ed4fd4..21ece880 100644
--- a/sound/soc/sunxi/sun4i-codec.c
+++ b/sound/soc/sunxi/sun4i-codec.c
@@ -67,9 +67,17 @@
#define SUN4I_CODEC_DAC_ACTL_LNG (26)
#define SUN4I_CODEC_DAC_ACTL_FMG (23)
#define SUN4I_CODEC_DAC_ACTL_MICG (20)
+#define SUN4I_CODEC_DAC_ACTL_LLNS (19)
+#define SUN4I_CODEC_DAC_ACTL_RLNS (18)
+#define SUN4I_CODEC_DAC_ACTL_LFMS (17)
+#define SUN4I_CODEC_DAC_ACTL_RFMS (16)
#define SUN4I_CODEC_DAC_ACTL_LDACLMIXS (15)
#define SUN4I_CODEC_DAC_ACTL_RDACRMIXS (14)
#define SUN4I_CODEC_DAC_ACTL_LDACRMIXS (13)
+#define SUN4I_CODEC_DAC_ACTL_MIC1LS(12)
+#define SUN4I_CODEC_DAC_ACTL_MIC1RS(11)
+#define SUN4I_CODEC_DAC_ACTL_MIC2LS(10)
+#define SUN4I_CODEC_DAC_ACTL_MIC2RS(9)
#define SUN4I_CODEC_DAC_ACTL_DACPAS(8)
#define SUN4I_CODEC_DAC_ACTL_MIXPAS(7)
#define SUN4I_CODEC_DAC_ACTL_PA_MUTE (6)
@@ -764,6 +772,22 @@ static const struct snd_kcontrol_new
sun4i_codec_mixer_controls[] = {
SUN4I_CODEC_DAC_ACTL,
SUN4I_CODEC_DAC_ACTL_LDACLMIXS,
SUN4I_CODEC_DAC_ACTL_RDACRMIXS, 1, 0),
+ SOC_DAPM_DOUBLE("Line Playback Switch",
+ SUN4I_CODEC_DAC_ACTL,
+ SUN4I_CODEC_DAC_ACTL_LLNS,
+ SUN4I_CODEC_DAC_ACTL_RLNS, 1, 0),
+ SOC_DAPM_DOUBLE("FM Playback Switch",
+ SUN4I_CODEC_DAC_ACTL,
+ SUN4I_CODEC_DAC_ACTL_LFMS,
+ SUN4I_CODEC_DAC_ACTL_RFMS, 1, 0),
+ SOC_DAPM_DOUBLE("Mic1 Playback Switch",
+ SUN4I_CODEC_DAC_ACTL,
+ SUN4I_CODEC_DAC_ACTL_MIC1LS,
+ SUN4I_CODEC_DAC_ACTL_MIC1RS, 1, 0),
+ SOC_DAPM_DOUBLE("Mic2 Playback Switch",
+ SUN4I_CODEC_DAC_ACTL,
+ SUN4I_CODEC_DAC_ACTL_MIC2LS,
+ SUN4I_CODEC_DAC_ACTL_MIC2RS, 1, 0),
SOC_DAPM_SINGLE("Right Mixer Left DAC Playback Switch",
SUN4I_CODEC_DAC_ACTL,
SUN4I_CODEC_DAC_ACTL_LDACRMIXS, 1, 0),
};
[PATCH v11 03/12] sun4i-codec: Add Line Playback Volume, FM Playback Volume, Mic Playback Volume, Capture Volume, Line Capture Volume.
Signed-off-by: Danny Milosavljevic
---
sound/soc/sunxi/sun4i-codec.c | 55 ++-
1 file changed, 54 insertions(+), 1 deletion(-)
diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
index a2435c6e..b5a3b5b3 100644
--- a/sound/soc/sunxi/sun4i-codec.c
+++ b/sound/soc/sunxi/sun4i-codec.c
@@ -64,6 +64,9 @@
#define SUN4I_CODEC_DAC_ACTL_DACAENR (31)
#define SUN4I_CODEC_DAC_ACTL_DACAENL (30)
#define SUN4I_CODEC_DAC_ACTL_MIXEN (29)
+#define SUN4I_CODEC_DAC_ACTL_LNG (26)
+#define SUN4I_CODEC_DAC_ACTL_FMG (23)
+#define SUN4I_CODEC_DAC_ACTL_MICG (20)
#define SUN4I_CODEC_DAC_ACTL_LDACLMIXS (15)
#define SUN4I_CODEC_DAC_ACTL_RDACRMIXS (14)
#define SUN4I_CODEC_DAC_ACTL_LDACRMIXS (13)
@@ -94,9 +97,10 @@
#define SUN4I_CODEC_ADC_ACTL_PREG1EN (29)
#define SUN4I_CODEC_ADC_ACTL_PREG2EN (28)
#define SUN4I_CODEC_ADC_ACTL_VMICEN(27)
-#define SUN4I_CODEC_ADC_ACTL_VADCG (20)
+#define SUN4I_CODEC_ADC_ACTL_ADCG (20)
#define SUN4I_CODEC_ADC_ACTL_ADCIS (17)
#define SUN4I_CODEC_ADC_ACTL_LNRDF (16)
+#define SUN4I_CODEC_ADC_ACTL_LNPREG(13)
#define SUN4I_CODEC_ADC_ACTL_PA_EN (4)
#define SUN4I_CODEC_ADC_ACTL_DDE (3)
#define SUN4I_CODEC_ADC_DEBUG (0x2c)
@@ -644,6 +648,23 @@ static const struct snd_kcontrol_new sun4i_codec_pa_mute =
SUN4I_CODEC_DAC_ACTL_PA_MUTE, 1, 0);
static DECLARE_TLV_DB_SCALE(sun4i_codec_pa_volume_scale, -6300, 100, 1);
+static DECLARE_TLV_DB_SCALE(sun4i_codec_linein_loopback_gain_scale,
+ -150,
+ 150,
+ 0);
+static DECLARE_TLV_DB_SCALE(sun4i_codec_linein_preamp_gain_scale,
+ -1200,
+ 300,
+ 0);
+static DECLARE_TLV_DB_SCALE(sun4i_codec_fmin_loopback_gain_scale,
+ -450,
+ 150,
+ 0);
+static DECLARE_TLV_DB_SCALE(sun4i_codec_micin_loopback_gain_scale,
+ -450,
+ 150,
+ 0);
+static DECLARE_TLV_DB_SCALE(sun4i_codec_adc_gain_scale, -450, 150, 0);
static const char * const sun4i_codec_difflinein_capture_source[] = {
"Stereo",
@@ -663,6 +684,38 @@ static const struct snd_kcontrol_new
sun4i_codec_controls[] = {
SOC_SINGLE_TLV("Power Amplifier Volume", SUN4I_CODEC_DAC_ACTL,
SUN4I_CODEC_DAC_ACTL_PA_VOL, 0x3F, 0,
sun4i_codec_pa_volume_scale),
+ /* Line, FM, Mic1, Mic2 */
+ SOC_SINGLE_TLV("Line Playback Volume",
+ SUN4I_CODEC_DAC_ACTL,
+ SUN4I_CODEC_DAC_ACTL_LNG,
+ 1,
+ 0,
+ sun4i_codec_linein_loopback_gain_scale),
+ SOC_SINGLE_TLV("Line Capture Volume",
+ SUN4I_CODEC_ADC_ACTL,
+ SUN4I_CODEC_ADC_ACTL_LNPREG,
+ 7,
+ 0,
+ sun4i_codec_linein_preamp_gain_scale),
+ SOC_SINGLE_TLV("FM Playback Volume",
+ SUN4I_CODEC_DAC_ACTL,
+ SUN4I_CODEC_DAC_ACTL_FMG,
+ 3,
+ 0,
+ sun4i_codec_fmin_loopback_gain_scale),
+ SOC_SINGLE_TLV("Mic Playback Volume",
+ SUN4I_CODEC_DAC_ACTL,
+ SUN4I_CODEC_DAC_ACTL_MICG,
+ 7,
+ 0,
+ sun4i_codec_micin_loopback_gain_scale),
+ /* ADC */
+ SOC_SINGLE_TLV("Capture Volume",
+ SUN4I_CODEC_ADC_ACTL,
+ SUN4I_CODEC_ADC_ACTL_ADCG,
+ 4,
+ 0,
+ sun4i_codec_adc_gain_scale),
};
static const struct snd_kcontrol_new sun4i_codec_left_mixer_controls[] = {
[PATCH v11 01/12] sun4i-codec: Add inputs: Mic2, Line Right, Line Left, FM Right, FM Left.
Signed-off-by: Danny Milosavljevic
---
sound/soc/sunxi/sun4i-codec.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
index 15006998..2f65aa72 100644
--- a/sound/soc/sunxi/sun4i-codec.c
+++ b/sound/soc/sunxi/sun4i-codec.c
@@ -720,8 +720,15 @@ static const struct snd_soc_dapm_widget
sun4i_codec_codec_dapm_widgets[] = {
SND_SOC_DAPM_SWITCH("Power Amplifier Mute", SND_SOC_NOPM, 0, 0,
&sun4i_codec_pa_mute),
+ /* Inputs */
SND_SOC_DAPM_INPUT("Mic1"),
+ SND_SOC_DAPM_INPUT("Mic2"),
+ SND_SOC_DAPM_INPUT("Line Right"),
+ SND_SOC_DAPM_INPUT("Line Left"),
+ SND_SOC_DAPM_INPUT("FM Right"),
+ SND_SOC_DAPM_INPUT("FM Left"),
+ /* Outputs */
SND_SOC_DAPM_OUTPUT("HP Right"),
SND_SOC_DAPM_OUTPUT("HP Left"),
};
[PATCH 05/12] sun4i-codec: Move struct sun4i_codec_quirks further up.
Signed-off-by: Danny Milosavljevic
---
sound/soc/sunxi/sun4i-codec.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
index 25870a64..f56a59ad 100644
--- a/sound/soc/sunxi/sun4i-codec.c
+++ b/sound/soc/sunxi/sun4i-codec.c
@@ -889,6 +889,16 @@ static const struct snd_soc_dapm_route
sun4i_codec_codec_dapm_routes[] = {
};
+struct sun4i_codec_quirks {
+ const struct regmap_config *regmap_config;
+ const struct snd_soc_codec_driver *codec;
+ struct snd_soc_card * (*create_card)(struct device *dev);
+ struct reg_field reg_adc_fifoc; /* used for regmap_field */
+ unsigned int reg_dac_txdata;/* TX FIFO offset for DMA config */
+ unsigned int reg_adc_rxdata;/* RX FIFO offset for DMA config */
+ bool has_reset;
+};
+
static struct snd_soc_codec_driver sun4i_codec_codec = {
.component_driver = {
.controls = sun4i_codec_controls,
@@ -1546,16 +1556,6 @@ static const struct regmap_config
sun8i_v3s_codec_regmap_config = {
.max_register = SUN8I_H3_CODEC_ADC_DBG,
};
-struct sun4i_codec_quirks {
- const struct regmap_config *regmap_config;
- const struct snd_soc_codec_driver *codec;
- struct snd_soc_card * (*create_card)(struct device *dev);
- struct reg_field reg_adc_fifoc; /* used for regmap_field */
- unsigned int reg_dac_txdata;/* TX FIFO offset for DMA config */
- unsigned int reg_adc_rxdata;/* RX FIFO offset for DMA config */
- bool has_reset;
-};
-
static const struct sun4i_codec_quirks sun4i_codec_quirks = {
.regmap_config = &sun4i_codec_regmap_config,
.codec = &sun4i_codec_codec,
[PATCH v11 00/12] sun4i-codec: Add Line-In, FM-In, Mic 2, Capture Source, Differential Line-In
This patchset adds some mixer controls to sun4i-codec. It also adds a mux for the capture source and the PGA for the MIC2 preamp. Where possible, it uses SOC_DAPM_DOUBLE in order to cut down on the number of distinct controls in alsamixer. v11 changes compared to v10 are: - Split up patchset. - Fixed typo in Differential Line Capture Switch. - Renamed "Non-Differential" value to "Stereo". - Removed duplicate PA Volume mixer control. v10 changes compared to v9 are: - Use SOC_DAPM_DOUBLE where possible and it makes sense in order to cut down on the number of controls. v9 changes compared to v8 are: - added Line Differential Capture Switch. - split Capture Source into Left Capture Select, Right Capture Select. - added Line Capture Volume. - rename "sun4i_codec_widgets" to "sun4i_codec_controls" for consistency with the struct field it's used in. - rename "Line-In" to "Line". - rename "Power Amplifier Playback Volume" to "Headphone Playback Volume". v8 changes compared to v7 are: - fixed the routes for line and mic capturing. v7 changes compared to v6 are: - preparation for different A20, A10 controls is now in an extra patch. - all register definitions are now at the top. - sun7i-specific things (A20-specific things) are now less grouped-together. - rename "Power Amplifier Volume" to "Power Amplifier Playback Volume". v6 changes compared to v5 are: - Mic preamplifier special cases for A20 and A10 now are now not icky: There are two different _widget arrays and the probe() function now selects the right one to pass to snd_soc_register_codec() unmodified. - sun7i-specific things (A20-specific things) are now grouped together. v5 changes compared to v4 are: - Mic preamplifier controls have more common names now. - Mic preamplifier scale has a 0 dB entry as well now, as documented in the A20 user manual. - Mic preamplifier has special cases for A20 and A10 now. - Gain controls have "Gain" in the name now. v4 changes compared to v3 are: - names of the input are not uppercase anymore. - bit index constants are now named as in the A20 user manual v1.4. - added Mic1-In, Mac2-In. - added Mic1 and Mic2 Pre-Amplifiers. v3 changes compared to v2 are: - added DAPM routes. v2 changes compared to v1 are: - moved Line-In and FM-In playback switches to their respective sun4i_codec_*_mixer_controls. v1 changes: - added linein, fmin output volumes and switches. Danny Milosavljevic (12): sun4i-codec: Add inputs: Mic2, Line Right, Line Left, FM Right, FM Left. sun4i-codec: Add Differential Line Capture Switch and its routes sun4i-codec: Add Line Playback Volume, FM Playback Volume, Mic Playback Volume, Capture Volume, Line Capture Volume. sun4i-codec: Add Mic1 Capture Volume, Mic2 Capture Volume. sun4i-codec: Move struct sun4i_codec_quirks further up. sun4i-codec: Add support for extra controls to struct sun4i_codec_quirks and use them. sun4i-codec: Add extra controls to sun4i_codec_quirks, sun7i_codec_quirks. sun4i-codec: Merge sun4i_codec_left_mixer_controls and sun4i_codec_right_mixer_controls into sun4i_codec_mixer_controls. sun4i-codec: Add Line Playback Switch, FM Playback Switch, Mic1 Playback Switch, Mic2 Playback Switch. sun4i-codec: Add Left Capture Select, Right Capture Select. sun4i-codec: Add MIC2 Pre-Amplifier. sun4i-codec: Add routes for playback switches, Mic2, Capture Select. sound/soc/sunxi/sun4i-codec.c | 283 ++ 1 file changed, 259 insertions(+), 24 deletions(-)
[PATCH] Drivers: rtl8192u - style fix
Fixed checkpatch error of "no spaces at the start of a line"
Signed-off-by: Derek Robson
---
drivers/staging/rtl8192u/r8192U.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/rtl8192u/r8192U.h
b/drivers/staging/rtl8192u/r8192U.h
index 4c7a5e3d3e5e..2959ea087148 100644
--- a/drivers/staging/rtl8192u/r8192U.h
+++ b/drivers/staging/rtl8192u/r8192U.h
@@ -917,9 +917,9 @@ typedef struct r8192_priv {
int rx_inx;
#endif
- struct sk_buff_head rx_queue;
- struct sk_buff_head skb_queue;
- struct work_struct qos_activate;
+ struct sk_buff_head rx_queue;
+ struct sk_buff_head skb_queue;
+ struct work_struct qos_activate;
short tx_urb_index;
atomic_t tx_pending[0x10]; /* UART_PRIORITY + 1 */
--
2.13.0
Re: [GIT PULL rcu/urgent] Allow SRCU readers in irq handlers for KVM
* Paul E. McKenney wrote: > Hello, Ingo, > > This series enables srcu_read_lock() and srcu_read_unlock to be used from > interrupt handlers, which fixes a bug in KVM's use of SRCU in delivery > of interrupts to guest OSes. These patches have been exposed to 0day > Test Robot and to -next testing, have been tested by the KVM folks, > and were posted to LKML: > > http://lkml.kernel.org/r/20170605220919.ga27...@linux.vnet.ibm.com > > These changes, based on v4.2-rc4, are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git > rcu/urgent > > for you to fetch changes up to 1123a6041654e8f889014659593bad4168e542c2: > > srcu: Allow use of Classic SRCU from both process and interrupt context > (2017-06-08 08:25:19 -0700) > > > Paolo Bonzini (2): > srcu: Allow use of Tiny/Tree SRCU from both process and interrupt > context > srcu: Allow use of Classic SRCU from both process and interrupt context > > include/linux/srcu.h | 2 -- > kernel/rcu/srcu.c | 5 ++--- > kernel/rcu/srcutiny.c | 7 --- > kernel/rcu/srcutree.c | 5 ++--- > 4 files changed, 8 insertions(+), 11 deletions(-) Pulled, thanks a lot Paul! Ingo
Re: [PATCH 5/5] power: supply: bq27xxx: Correct supply status with current draw
Le jeudi 08 juin 2017 à 21:27 +0200, Sebastian Reichel a écrit : > Hi, > > On Thu, Jun 08, 2017 at 01:08:52PM +0300, Paul Kocialkowski wrote: > > > > On Wed, 2017-06-07 at 09:52 +0200, Pavel Machek wrote: > > > > > > [0]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux. > > > > > > git/ > > > > > > comm > > > > > > it/? > > > > > > h=v4.12-rc4&id=7f93e1fa032bb5ee19b868b9649bc98c82553003 > > > > > > > > > > Is there some documentation that explains what different power supply > > > > > statuses mean? Because without that, we can have long and useless > > > > > discussions. > > > > > > > > Well, I couldn't really find much except the following from > > > > Documentation/ > > > > (which is not that helpful, and the BATTERY_STATUS_* don't seem to exist > > > > anymore): > > > > > > > > " STATUS - this attribute represents operating status (charging, full, > > > > discharging (i.e. powering a load), etc.). This corresponds to > > > > BATTERY_STATUS_* values, as defined in battery.h. " > > > > > > > > Generally speaking, I think the question to be asked is what information > > > > users > > > > will be interested in in each scenario we have to consider. > > > > > > Hmm. We really should add some documentation :-(. > > > > Maybe we should start a new thread about this to give it more visibility. > > That way, PM maintainers could weigh-in and share thoughts. > > > > I definitely agree there is a need to clarify what we want to report to > > userspace given the various scenarios we've been discussing. > > +1 for extension and update of documentation. If its known, that > the battery is trickle charged, it should report FULL. No need > to annoy people by constantly updating the status. Think of it > being mapped directly to a status LED. Of course the CURRENT/ENERGY > properties should still be updated, so that anyone interested in > the details can see them. Agreed. Do ou think there is a need to start a specific discussion about various scenarios and how to handle them or do shall we just use common sense here? -- Paul Kocialkowski, developer of free digital technology and hardware support Website: https://www.paulk.fr/ Coding blog: https://code.paulk.fr/ Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/ signature.asc Description: This is a digitally signed message part
Re: [RFC 00/10] V4L2 explicit synchronization support
Hi Mauro, 2017-06-08 Mauro Carvalho Chehab : > Hi Gustavo, > > Em Wed, 24 May 2017 21:31:01 -0300 > Gustavo Padovan escreveu: > > > Hi all, > > > > I've been working on the v2 of this series, but I think I hit a blocker > > when trying to cover the case where the driver asks to requeue the > > buffer. It is related to the out-fence side. > > > > In the current implementation we return on QBUF an out-fence fd that is not > > tied to any buffer, because we don't know the queueing order until the > > buffer is queued to the driver. Then when the buffer is queued we use > > the BUF_QUEUED event to notify userspace of the index of the buffer, > > so now userspace knows the buffer associated to the out-fence fd > > received earlier. > > > > Userspace goes ahead and send a DRM Atomic Request to the kernel to > > display that buffer on the screen once the fence signals. If it is > > a nonblocking request the fence waiting is past the check phase, thus > > it isn't allowed to fail anymore. > > > > But now, what happens if the V4L2 driver calls buffer_done() asking > > to requeue the buffer. That means the operation failed and can't > > signal the fence, starving the DRM side. > > > > We need to fix that. The only way I can see is to guarantee ordering of > > buffers when out-fences are used. Ordering is something that HAL3 needs > > to so maybe there is more than one reason to do it like this. I'm not > > a V4L2 expert, so I don't know all the consequences of such a change. > > > > Any other ideas? > > > > The current patchset is at: > > > > https://git.kernel.org/pub/scm/linux/kernel/git/padovan/linux.git/log/?h=v4l2-fences > > Currently, nothing warrants that buffers will be returned in order, > but that should be the case of most drivers. I guess the main > exception would be mem2mem codec drivers. On those, the driver > or the hardware may opt to reorder the buffers. > > If this is a mandatory requirement for explicit fences to work, then > we'll need to be able to explicitly enable it, per driver, and > clearly document that drivers using it *should* warrant that the > dequeued buffer will follow the queued order. It is mandatory in the sense it won't work properly and make DRM fail an atomic commit if a buffer is requeued. So it is fair to ask drivers to guarantee ordering is a good thing. Then later we can deal with the drivers that can't. > > We may need to modify VB2 in order to enforce it or return an > error if the order doesn't match. Yeah, I'll look into how to do this. Gustavo
[PATCH] usb: gadget: functions: add ftrace export over USB
Allow for ftrace data to be exported over a USB Gadget
Controller. With this, we have a potentially very fast pipe for
transmitting ftrace data to a Host PC for further analysis.
Note that in order to decode the data, one needs access to kernel
symbols in order to convert binary data into function names and what
not.
Signed-off-by: Felipe Balbi
---
I wanted to take this through the gadget tree, but there is a
dependency with a previous patch of mine adding and extra argument to
the ->write() function. Hoping someone else will take it.
drivers/usb/gadget/Kconfig| 15 ++
drivers/usb/gadget/function/Makefile | 2 +
drivers/usb/gadget/function/f-trace.c | 400 ++
3 files changed, 417 insertions(+)
create mode 100644 drivers/usb/gadget/function/f-trace.c
diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index c164d6b788c3..617921f19b5e 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -188,6 +188,9 @@ config USB_F_MASS_STORAGE
config USB_F_FS
tristate
+config USB_F_TRACE
+ tristate
+
config USB_F_UAC1
tristate
@@ -362,6 +365,18 @@ config USB_CONFIGFS_F_FS
implemented in kernel space (for instance Ethernet, serial or
mass storage) and other are implemented in user space.
+config USB_CONFIGFS_F_TRACE
+ bool "Linux FTrace Export Over USB"
+ depends on USB_CONFIGFS
+ select USB_F_TRACE
+ help
+ The Linux FTrace Export Over USB lets one export ftrace buffer
+ over a USB cable to a host computer for further processing.
+
+ If you want support for that, say Y or M here. Otherwise say N.
+
+ If unsure, say N.
+
config USB_CONFIGFS_F_UAC1
bool "Audio Class 1.0"
depends on USB_CONFIGFS
diff --git a/drivers/usb/gadget/function/Makefile
b/drivers/usb/gadget/function/Makefile
index cb8c225e8549..1433e8ad7675 100644
--- a/drivers/usb/gadget/function/Makefile
+++ b/drivers/usb/gadget/function/Makefile
@@ -46,3 +46,5 @@ usb_f_printer-y := f_printer.o
obj-$(CONFIG_USB_F_PRINTER)+= usb_f_printer.o
usb_f_tcm-y:= f_tcm.o
obj-$(CONFIG_USB_F_TCM)+= usb_f_tcm.o
+usb_f_trace-y := f-trace.o
+obj-$(CONFIG_USB_F_TRACE) += usb_f_trace.o
diff --git a/drivers/usb/gadget/function/f-trace.c
b/drivers/usb/gadget/function/f-trace.c
new file mode 100644
index ..7de92950c0e7
--- /dev/null
+++ b/drivers/usb/gadget/function/f-trace.c
@@ -0,0 +1,400 @@
+/*
+ * f_trace.c -- USB FTrace Export
+ *
+ * Copyright (C) 2017 Intel Corporation
+ * Author: Felipe Balbi
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License v2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct usb_ftrace {
+ struct trace_export ftrace;
+ struct usb_function function;
+ struct work_struct queue_work;
+ spinlock_t lock;
+
+ struct list_head list;
+ struct list_head pending;
+ struct list_head queued;
+
+ struct usb_ep *in;
+
+ u8 intf_id;
+};
+#define ftrace_to_trace(f) (container_of((f), struct usb_ftrace, ftrace))
+#define work_to_trace(w) (container_of((w), struct usb_ftrace,
queue_work))
+#define to_trace(f)(container_of((f), struct usb_ftrace, function))
+
+#define FTRACE_REQUEST_QUEUE_LENGTH250
+
+static inline struct usb_request *next_request(struct list_head *list)
+{
+ return list_first_entry_or_null(list, struct usb_request, list);
+}
+
+struct usb_ftrace_opts {
+ struct usb_function_instance func_inst;
+};
+#define to_opts(fi)(container_of((fi), struct usb_ftrace_opts, func_inst))
+
+static struct usb_interface_descriptor ftrace_intf_desc = {
+ .bLength= USB_DT_INTERFACE_SIZE,
+ .bDescriptorType= USB_DT_INTERFACE,
+
+ .bAlternateSetting = 0,
+ .bNumEndpoints = 1,
+ .bInterfaceClass= USB_CLASS_VENDOR_SPEC,
+ .bInterfaceSubClass = USB_SUBCLASS_VENDOR_SPEC,
+};
+
+/* Super-Speed Support */
+static struct usb_endpoint_descriptor ftrace_ss_in_desc = {
+ .bLength= USB_DT_ENDPOINT_SIZE,
+ .bDescriptorType= USB_DT_ENDPOINT,
+
+ .bEndpointAddress = USB_DIR_IN,
+ .bmAttributes = USB_ENDPOINT_XFER_BULK,
+ .wMaxPacketSize = cpu_to_le16(1024),
+};
+
+static struct usb_ss_ep_comp_descriptor ftrace_ss_in_comp_desc = {
+ .bLength= USB_DT_SS_EP_COMP_SIZE,
+ .bDescriptorType= USB_DT_SS_ENDPOINT_COMP,
+
+ .bMaxBurst = 15,
+};
+
+static struct usb_descriptor_header *ftrace_ss_function[] = {
+ (struct usb_descriptor_header *) &ftrace_intf_de
[PATCH] ALSA : pcsp: pcsp_lib: constify snd_pcsp_playback_ops
File size before:
textdata bss dec hex filename
2027 168 12196 894 sound/drivers/pcsp/pcsp_lib.o
File size After:
textdata bss dec hex filename
2155 40 12196 894 sound/drivers/pcsp/pcsp_lib.o
Signed-off-by: Arvind Yadav
---
sound/drivers/pcsp/pcsp_lib.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/drivers/pcsp/pcsp_lib.c b/sound/drivers/pcsp/pcsp_lib.c
index aca2d7d..44b3632 100644
--- a/sound/drivers/pcsp/pcsp_lib.c
+++ b/sound/drivers/pcsp/pcsp_lib.c
@@ -323,7 +323,7 @@ static int snd_pcsp_playback_open(struct snd_pcm_substream
*substream)
return 0;
}
-static struct snd_pcm_ops snd_pcsp_playback_ops = {
+static const struct snd_pcm_ops snd_pcsp_playback_ops = {
.open = snd_pcsp_playback_open,
.close = snd_pcsp_playback_close,
.ioctl = snd_pcm_lib_ioctl,
--
1.9.1
[PATCH v2] platform/x86: ideapad-laptop: constify rfkill_ops structure
Add const to rfkill_ops structure as it is only passed as an argument
to the functions rfkill_alloc. This argument is of type const,
so annotate the structure with const.
Signed-off-by: Bhumika Goyal
---
Changes since v1:
* Split the changes to one patch per vendor.
drivers/platform/x86/ideapad-laptop.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/platform/x86/ideapad-laptop.c
b/drivers/platform/x86/ideapad-laptop.c
index 24ca9fb..3beec1e 100644
--- a/drivers/platform/x86/ideapad-laptop.c
+++ b/drivers/platform/x86/ideapad-laptop.c
@@ -478,7 +478,7 @@ static int ideapad_rfk_set(void *data, bool blocked)
return write_ec_cmd(priv->priv->adev->handle, opcode, !blocked);
}
-static struct rfkill_ops ideapad_rfk_ops = {
+static const struct rfkill_ops ideapad_rfk_ops = {
.set_block = ideapad_rfk_set,
};
--
2.7.4
[PATCH] Drivers: ccree - style fix
Align block comments
Found using checkpatch
Signed-off-by: Derek Robson
---
drivers/staging/ccree/cc_hw_queue_defs.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/ccree/cc_hw_queue_defs.h
b/drivers/staging/ccree/cc_hw_queue_defs.h
index aaa56c85bda2..0e6416ed9a58 100644
--- a/drivers/staging/ccree/cc_hw_queue_defs.h
+++ b/drivers/staging/ccree/cc_hw_queue_defs.h
@@ -23,8 +23,8 @@
#include
/**
-* DEFINITIONS
-**/
+ * DEFINITIONS
+
**/
#define HW_DESC_SIZE_WORDS 6
#define HW_QUEUE_SLOTS_MAX 15 /* Max. available slots in HW queue
*/
@@ -70,8 +70,8 @@
#define WORD5_DOUT_ADDR_HIGH CC_GENMASK(5, DOUT_ADDR_HIGH)
/**
-* TYPE DEFINITIONS
-**/
+ * TYPE DEFINITIONS
+
**/
struct cc_hw_desc {
union {
--
2.13.0
Re: [PATCH v5 3/3] drivers:power:twl4030-charger: add deferred probing for phy and iio
Hi,
> Am 07.06.2017 um 22:44 schrieb Sebastian Reichel :
>
> Hi,
>
> On Sun, May 21, 2017 at 12:38:18PM +0200, H. Nikolaus Schaller wrote:
>> This fixes an issue if both this twl4030_charger driver and
>> phy-twl4030-usb are compiled as modules and loaded in random order.
>> It has been observed on GTA04 and OpenPandora devices that in worst
>> case the boot process hangs and in best case the AC detection fails
>> with a warning.
>>
>> Therefore we add deferred probing checks for the usb_phy and the
>> iio channel for AC detection.
>>
>> For implementing this we must reorder code because we can't safely
>> return -EPROBE_DEFER after allocating any devm managed interrupt
>> (it might already/still be enabled without working interrupt handler).
>>
>> So the check for required resources that may abort probing by
>> returning -EPROBE_DEFER, must come first.
>
> This sounds fishy. EPROBE_DEFER should not be different from
> other error codes in this regard and devm_ requested resources
> should be free'd on any error. Why is irq handler not working?
1. there is no other error code involved, before we try to convert the driver
to handle EPROBE_DEFER.
So it is not that EPROBE_DEFER is special but that we add an error return path
for it.
2. I don't know why it is not working - I just know that the handler seems to
be triggered before
all resources are available (if probe() is aborted with EPROBE_DEFER error
paths) which ends up in kernel panics.
Therefore just to be safe, I have reordered things a little (without changing
the function):
1. check for resources (with some EPROBE_DEFER)
2. allocate non-devm (with optional EPROBE_DEFER)
3. allocate devm
So this should be safe in any case.
Please also compare a discussion
https://lkml.org/lkml/2013/2/22/65
>
>> Signed-off-by: H. Nikolaus Schaller
>> ---
>> drivers/power/supply/twl4030_charger.c | 37
>> --
>> 1 file changed, 22 insertions(+), 15 deletions(-)
>>
>> diff --git a/drivers/power/supply/twl4030_charger.c
>> b/drivers/power/supply/twl4030_charger.c
>> index 785a07bc4f39..945eabdbbc89 100644
>> --- a/drivers/power/supply/twl4030_charger.c
>> +++ b/drivers/power/supply/twl4030_charger.c
>> @@ -984,6 +984,28 @@ static int twl4030_bci_probe(struct platform_device
>> *pdev)
>>
>> platform_set_drvdata(pdev, bci);
>>
>> +if (bci->dev->of_node) {
>> +struct device_node *phynode;
>> +
>> +phynode = of_find_compatible_node(bci->dev->of_node->parent,
>> + NULL, "ti,twl4030-usb");
>> +if (phynode) {
>> +bci->transceiver = devm_usb_get_phy_by_node(
>> +bci->dev, phynode, &bci->usb_nb);
>> +if (IS_ERR(bci->transceiver) &&
>> +PTR_ERR(bci->transceiver) == -EPROBE_DEFER)
>> +return -EPROBE_DEFER; /* PHY not ready */
>> +}
>> +}
>> +
>> +bci->channel_vac = iio_channel_get(&pdev->dev, "vac");
>> +if (IS_ERR(bci->channel_vac)) {
>> +if (PTR_ERR(bci->channel_vac) == -EPROBE_DEFER)
>> +return -EPROBE_DEFER; /* iio not ready */
>> +dev_warn(&pdev->dev, "could not request vac iio channel");
>> +bci->channel_vac = NULL;
>> +}
>> +
>
> You should not request non-devm managed iio_channel before
> devm-managed power-supply.
Well, it is not *me* doing that.
It is the unpatched driver which already does. See:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/power/supply/twl4030_charger.c?h=v4.12-rc4#n1069
I have just moved this line to a different location to be able to add a proper
EPROBE_DEFER return path.
> This could be fixed by switching to
> devm_iio_channel_get(), which also cleans up some code.
Yes, this could be an alternative solution.
We still need EPROBE_DEFER handling.
>
> I suspect, that this is also your IRQ problem, since iio_channel
> is currently free'd before irqs are free'd, but its used in irq
> code.
Hm. No.
In upstream code it is never freed on probe failure because there is only
an error return (goto fail) after allocating irqs in case the
twl_i2c_write_u8 fails. Which usually doesn't.
The EPROBE_DEFER returned by iio_channel_get not being ready simply prints
a warning and turns off AC detection (bci->channel_vac = NULL) forever.
>
>> bci->ac = devm_power_supply_register(&pdev->dev, &twl4030_bci_ac_desc,
>> NULL);
>> if (IS_ERR(bci->ac)) {
>> @@ -1017,25 +1039,10 @@ static int twl4030_bci_probe(struct platform_device
>> *pdev)
>> return ret;
>> }
>>
>> -bci->channel_vac = iio_channel_get(&pdev->dev, "vac");
>> -if (IS_ERR(bci->channel_vac)) {
My first attempt to fix EPROBE_DEFER was to add this
+ if (PTR_ERR(bci->channel_vac) == -EPROBE_DEFER)
+
[PATCH v2] platform/x86: samsung-laptop: constify rfkill_ops structures
Add const to rfkill_ops structures that are only passed as an argument
to the functions rfkill_alloc or samsung_new_rfkill. These arguments are
of type const, so such structures can be annotated with const.
Signed-off-by: Bhumika Goyal
---
Changes since v1:
* Split the changes to one patch per vendor.
drivers/platform/x86/samsung-laptop.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/platform/x86/samsung-laptop.c
b/drivers/platform/x86/samsung-laptop.c
index 8c146e2..e1e8897 100644
--- a/drivers/platform/x86/samsung-laptop.c
+++ b/drivers/platform/x86/samsung-laptop.c
@@ -591,7 +591,7 @@ static int seclinux_rfkill_set(void *data, bool blocked)
!blocked);
}
-static struct rfkill_ops seclinux_rfkill_ops = {
+static const struct rfkill_ops seclinux_rfkill_ops = {
.set_block = seclinux_rfkill_set,
};
@@ -651,7 +651,7 @@ static void swsmi_rfkill_query(struct rfkill *rfkill, void
*priv)
rfkill_set_sw_state(rfkill, !ret);
}
-static struct rfkill_ops swsmi_rfkill_ops = {
+static const struct rfkill_ops swsmi_rfkill_ops = {
.set_block = swsmi_rfkill_set,
.query = swsmi_rfkill_query,
};
--
2.7.4
Re: [PATCH v7 1/3] ACPI/IORT: Fixup SMMUv3 resource size for Cavium ThunderX2 SMMUv3 model
On Thu, Jun 8, 2017 at 2:28 PM, Lorenzo Pieralisi
wrote:
> On Tue, May 30, 2017 at 05:33:39PM +0530, Geetha sowjanya wrote:
>> From: Linu Cherian
>>
>> Cavium ThunderX2 implementation doesn't support second page in SMMU
>> register space. Hence, resource size is set as 64k for this model.
>>
>> Signed-off-by: Linu Cherian
>> Signed-off-by: Geetha Sowjanya
>> ---
>> drivers/acpi/arm64/iort.c | 10 +-
>> 1 files changed, 9 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
>> index c5fecf9..bba2b59 100644
>> --- a/drivers/acpi/arm64/iort.c
>> +++ b/drivers/acpi/arm64/iort.c
>> @@ -833,12 +833,20 @@ static void __init arm_smmu_v3_init_resources(struct
>> resource *res,
>> {
>> struct acpi_iort_smmu_v3 *smmu;
>> int num_res = 0;
>> + unsigned long size = SZ_128K;
>>
>> /* Retrieve SMMUv3 specific data */
>> smmu = (struct acpi_iort_smmu_v3 *)node->node_data;
>>
>> + /*
>> + * Override the size, for Cavium ThunderX2 implementation
>> + * which doesn't support the page 1 SMMU register space.
>> + */
>> + if (smmu->model == ACPI_IORT_SMMU_CAVIUM_CN99XX)
>> + size = SZ_64K;
>
> Nit: add a function, say arm_smmu_v3_resource_size() with the logic
> above that by default returns SZ_128K, I do not like this switch
> in the middle of this function.
I will resubmit the patch with suggested changes.
Thanks,
Geetha.
>
> Lorenzo
>
>> +
>> res[num_res].start = smmu->base_address;
>> - res[num_res].end = smmu->base_address + SZ_128K - 1;
>> + res[num_res].end = smmu->base_address + size - 1;
>> res[num_res].flags = IORESOURCE_MEM;
>>
>> num_res++;
>> --
>> 1.7.1
>>
[PATCH v2] dell-rbtn: constify rfkill_ops structures
Add const to rfkill_ops structures that are only passed as an argument
to the functions rfkill_alloc or samsung_new_rfkill. These arguments are
of type const, so such structures can be annotated with const.
Signed-off-by: Bhumika Goyal
---
Changes since v1:
* Split the changes to one patch per vendor.
drivers/platform/x86/dell-rbtn.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/platform/x86/dell-rbtn.c b/drivers/platform/x86/dell-rbtn.c
index dcd9f40..6b5bbaf 100644
--- a/drivers/platform/x86/dell-rbtn.c
+++ b/drivers/platform/x86/dell-rbtn.c
@@ -110,7 +110,7 @@ static int rbtn_rfkill_set_block(void *data, bool blocked)
return -EINVAL;
}
-static struct rfkill_ops rbtn_ops = {
+static const struct rfkill_ops rbtn_ops = {
.query = rbtn_rfkill_query,
.set_block = rbtn_rfkill_set_block,
};
--
2.7.4
Re: [PATCH 2/3] target: Add TARGET_SCF_LOOKUP_LUN_FROM_TAG support for ABORT_TASK
On Mon, 2017-06-05 at 15:57 +, Bart Van Assche wrote:
> On Sat, 2017-06-03 at 22:10 +, Nicholas A. Bellinger wrote:
> > +static bool target_lookup_lun_from_tag(struct se_session *se_sess, u64 tag,
> > + u64 *unpacked_lun)
> > +{
> > + struct se_cmd *se_cmd;
> > + unsigned long flags;
> > + bool ret = false;
> > +
> > + spin_lock_irqsave(&se_sess->sess_cmd_lock, flags);
> > + list_for_each_entry(se_cmd, &se_sess->sess_cmd_list, se_cmd_list) {
> > + if (se_cmd->se_cmd_flags & SCF_SCSI_TMR_CDB)
> > + continue;
> > +
> > + if (se_cmd->tag == tag) {
> > + *unpacked_lun = se_cmd->orig_fe_lun;
> > + ret = true;
> > + break;
> > + }
> > + }
> > + spin_unlock_irqrestore(&se_sess->sess_cmd_lock, flags);
> > +
> > + return ret;
> > +}
> > +
> > /**
> > * target_submit_tmr - lookup unpacked lun and submit uninitialized se_cmd
> > * for TMR CDBs
> > @@ -1639,19 +1662,31 @@ int target_submit_tmr(struct se_cmd *se_cmd, struct
> > se_session *se_sess,
> > core_tmr_release_req(se_cmd->se_tmr_req);
> > return ret;
> > }
> > + /*
> > +* If this is ABORT_TASK with no explicit fabric provided LUN,
> > +* go ahead and search active session tags for a match to figure
> > +* out unpacked_lun for the original se_cmd.
> > +*/
> > + if (tm_type == TMR_ABORT_TASK && (flags &
> > TARGET_SCF_LOOKUP_LUN_FROM_TAG)) {
> > + if (!target_lookup_lun_from_tag(se_sess, tag, &unpacked_lun))
> > + goto failure;
> > + }
> >
> > ret = transport_lookup_tmr_lun(se_cmd, unpacked_lun);
> > - if (ret) {
> > - /*
> > -* For callback during failure handling, push this work off
> > -* to process context with TMR_LUN_DOES_NOT_EXIST status.
> > -*/
> > - INIT_WORK(&se_cmd->work, target_complete_tmr_failure);
> > - schedule_work(&se_cmd->work);
> > - return 0;
> > - }
> > + if (ret)
> > + goto failure;
> > +
> > transport_generic_handle_tmr(se_cmd);
> > return 0;
>
> Hello Nic,
>
> So after LUN lookup has finished sess_cmd_lock lock is dropped, a context
> switch occurs due to the queue_work() call in transport_generic_handle_tmr()
> and next core_tmr_abort_task() reacquires that lock? Sorry but I'm afraid
> that if after that lock is dropped and before it is reacquired a command
> finishes and the initiator reuses the same tag for another command for the
> same LUN that this may result in the wrong command being aborted.
This is only getting a unpacked_lun to determine where the incoming
ABORT_TASK should perform a se_lun lookup and percpu ref upon.
The scenario you are talking about would require a tag be reused on the
same session for the same device between when the ABORT_TASK is
dispatched here, and actually processed.
Because qla2xxx doesn't reuse tags, it's not a problem since it's the
only consumer of TARGET_SCF_LOOKUP_LUN_FROM_TAG.
Since Himanshu and Quinn are OK it with, I'm OK with it.
If you have another driver that needs to use this logic where an
ABORT_TASK doesn't know the unpacked_lun to reference, and does reuse
tags then I'd consider a patch for that.
[git pull] drm fixes for 4.12-rc5
Hi Linus, Bit more spread out fixes this time, fixes for 7 drivers + a couple of core fixes. i915 and vmwgfx are the main ones. The vmwgfx ones fix a bunch of regressions in their atomic rework, and a few fixes destined for stable. i915 has some 4.12 regressions and older things that need to be fixed in stable as well. nouveau also has some runtime pm fixes and a timer list handling fix, otherwise a couple of core and small driver regression fixes. Thanks, Dave, The following changes since commit 3c2993b8c6143d8a5793746a54eba8f86f95240f: Linux 4.12-rc4 (2017-06-04 16:47:43 -0700) are available in the git repository at: git://people.freedesktop.org/~airlied/linux tags/drm-fixes-for-v4.12-rc5 for you to fetch changes up to 6e88007e224ce51969ccf9afeec645146c638816: Merge branch 'vmwgfx-fixes-4.12' of git://people.freedesktop.org/~thomash/linux into drm-fixes (2017-06-09 13:12:02 +1000) intel, nouveau, rockchip, vmwgfx, imx, meson, mediatek and core fixes Ben Skeggs (3): drm/nouveau: replace multiple open-coded runpm support checks with function drm/nouveau: enable autosuspend only when it'll actually be used drm/nouveau/tmr: fully separate alarm execution/pending lists Chris Wilson (4): drm/i915: Short-circuit i915_gem_wait_for_idle() if already idle drm/i915: Hold a wakeref for probing the ring registers drm/i915: Guard against i915_ggtt_disable_guc() being invoked unconditionally drm/i915: Fix logical inversion for gen4 quirking Colin Ian King (1): drm/vmwgfx: fix spelling mistake "exeeds" -> "exceeds" Dan Carpenter (2): drm/mediatek: fix a timeout loop drm/vmwgfx: Handle vmalloc() failure in vmw_local_fifo_reserve() Daniel Vetter (1): drm: Fix locking in drm_atomic_helper_resume Dave Airlie (7): Merge branch 'linux-4.12' of git://github.com/skeggsb/linux into drm-fixes Merge tag 'drm-misc-fixes-2017-06-02' of git://anongit.freedesktop.org/git/drm-misc into drm-fixes Merge tag 'imx-drm-fixes-2017-06-08' of git://git.pengutronix.de/git/pza/linux into drm-fixes Merge branch 'mediatek-drm-fixes-4.12-rc1' of https://github.com/ckhu-mediatek/linux.git-tags into drm-fixes Merge tag 'drm-misc-fixes-2017-06-07' of git://anongit.freedesktop.org/git/drm-misc into drm-fixes Merge tag 'drm-intel-fixes-2017-06-08' of git://anongit.freedesktop.org/git/drm-intel into drm-fixes Merge branch 'vmwgfx-fixes-4.12' of git://people.freedesktop.org/~thomash/linux into drm-fixes Gustavo A. R. Silva (1): drm/nouveau/kms/nv50: add null check before pointer dereference Hans de Goede (1): drm: Fix oops + Xserver hang when unplugging USB drm devices Imre Deak (1): drm/i915: Prevent the system suspend complete optimization Jani Nikula (1): drm/i915: fix warning for unused variable John Stultz (1): drm: kirin: Fix drm_of_find_panel_or_bridge conversion Jon Bloomfield (1): drm/i915: Serialize GTT/Aperture accesses on BXT Kai Chen (1): drm/i915: Disable decoupled MMIO Leonard Crestez (1): drm/imx: imx-ldb: Accept drm_of_find_panel_or_bridge failure Lucas Stach (1): gpu: ipu-v3: pre: only use internal clock gating Maarten Lankhorst (1): drm/i915: Always recompute watermarks when distrust_bios_wm is set, v2. Marek Vasut (1): gpu: ipu-v3: Fix CSI selection for VDIC Mark yao (1): drm/rockchip: Correct vop out_mode configure Michal Wajdeczko (1): drm/i915/guc: Remove stale comment for q_fail Nagaraju, Vathsala (1): drm/i915/psr: disable psr2 for resolution greater than 32X20 Neil Armstrong (1): drm/meson: Fix driver bind when only CVBS is available Sinclair Yeh (5): drm/vmwgfx: Don't create proxy surface for cursor drm/vmwgfx: Make sure backup_handle is always valid drm/vmwgfx: Make sure to update STDU when FB is updated drm/vmwgfx: Fix large topology crash drm/vmwgfx: Remove unused legacy cursor functions Thomas Hellstrom (1): drm/vmwgfx: Bump driver minor and date Ville Syrjälä (3): drm/i915: Workaround VLV/CHV DSI scanline counter hardware fail drm/i915: Restore has_fbc=1 for ILK-M drm/i915: Fix 90/270 rotated coordinates for FBC Vladis Dronov (1): drm/vmwgfx: limit the number of mip levels in vmw_gb_surface_define_ioctl() YYS (1): drm/mediatek: fix mtk_hdmi_setup_vendor_specific_infoframe mistake drivers/gpu/drm/drm_atomic_helper.c| 11 ++ drivers/gpu/drm/drm_drv.c | 7 +- drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 2 +- drivers/gpu/drm/i915/i915_drv.c| 9 ++ drivers/gpu/drm/i915/i915_drv.h| 10 ++ drivers/gpu/drm/i915/i915_gem.c| 4 + drivers/gpu/drm/i915/i915_gem_gtt.c| 10
Re: [PATCHv3] Bluetooth: hci_ll: Add compatible values for more WL chips
Hi Sebastian, > Add compatible values for WiLink chips from 128x and 180x series. > Also the DT binding already contained compatible values for the 127x > series, but the driver did not. This brings the list on par with > the list from wlcore (the wifi driver). > > Signed-off-by: Sebastian Reichel > --- > Hi, > > This patch originally was part of the "Motorola Droid 4: Add WL1285C support" > series. It can be queued standalone via the bluetooth tree, though. > > Changes since PATCHv2: > * none > Changes since PATCHv1: > * patch did not exist > > -- Sebastian > --- > Documentation/devicetree/bindings/net/ti,wilink-st.txt | 6 ++ > drivers/bluetooth/hci_ll.c | 8 > 2 files changed, 14 insertions(+) patch has been applied to bluetooth-next tree. Regards Marcel
Re: [PATCH linux-next v3 1/1] spi: imx: dynamic burst length adjust for PIO mode
On Thu, Jun 08, 2017 at 10:09:07PM -0700, Jiada Wang wrote: > On 06/01/2017 10:38 PM, Sascha Hauer wrote: > > On Thu, Jun 01, 2017 at 04:58:47AM -0700, Jiada Wang wrote: > > > Hi Sascha > > > > > > On 05/29/2017 02:50 AM, Sascha Hauer wrote: > > > > Hi, > > > > > > > > On Thu, May 25, 2017 at 10:02:42PM -0700, jiada_w...@mentor.com wrote: > > > > > From: Jiada Wang > > > > > > > > > > previously burst length (BURST_LENGTH) is always set to equal > > > > > to bits_per_word, causes a 10us gap between each word in > > > > > transfer, which significantly affects performance. > > > > > > > > > > This patch uses 32 bits transfer to simulate lower bits transfer, > > > > > and adjusts burst length runtimely to use biggeest burst length > > > > > as possible to reduce the gaps in transfer for PIO mode. > > > > > > > > > First let me say that I'm not really looking forward to have this patch > > > > in the driver. It adds quite some code to already hairy code pathes in > > > > the imx-spi driver and I saw you have the same patch for DMA mode > > > > aswell. > > > > > > > > The driver has different function hooks for the different controllers. > > > > This patch breaks that. In some places it assumes that dynamic burst > > > > is only possible on i.MX51 type controllers and also that in case > > > > dynamic burst is enabled it must be an i.MX51 type controller. > > > > > > > > We should really see how this patch can be better integrated into the > > > > driver, or, how the driver can be changed to better support the dynamic > > > > burst usecase. > > > Yes, I can understand your concern, as this patch brings in a bunch of > > > change, > > > and changes the behaviour of data transfer. > > > how about introduce a new DTS property like "fsl,spi-dynamic-burst", > > > and only enables dynamic burst when this property is added. > > This will only reduce the testing coverage of the feature, not a good > > option. > As an improvement, I am thinking about the following > 1. introduce a 'fsl,spi-dynamic-burst' property in dts as mentioned before > 2. remove all change in specific functions hooks, for example > "mx51_ecspi_config" > 3. introduce spi_imx_pio_dynamic_burst_transfer(), which will handle actual > swapped data transfer, > and burst length adjustment. Whether or not the spi driver uses dynamic bursts is an implementation detail of the driver and should be decided by the driver, not by the device tree. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
Re: [PATCH 11/16] powerpc: vio_cmo: use dev_groups and not dev_attrs for bus_type
On Fri, Jun 09, 2017 at 08:53:22AM +1000, Michael Ellerman wrote: > Greg Kroah-Hartman writes: > > > On Thu, Jun 08, 2017 at 11:12:10PM +1000, Michael Ellerman wrote: > >> Greg Kroah-Hartman writes: > >> > >> > The dev_attrs field has long been "depreciated" and is finally being > >> > removed, so move the driver to use the "correct" dev_groups field > >> > instead for struct bus_type. > >> > > >> > Cc: Benjamin Herrenschmidt > >> > Cc: Paul Mackerras > >> > Cc: Michael Ellerman > >> > Cc: Vineet Gupta > >> > Cc: Bart Van Assche > >> > Cc: Robin Murphy > >> > Cc: Joerg Roedel > >> > Cc: Johan Hovold > >> > Cc: Alexey Kardashevskiy > >> > Cc: Krzysztof Kozlowski > >> > Cc: > >> > Signed-off-by: Greg Kroah-Hartman > >> > --- > >> > arch/powerpc/platforms/pseries/vio.c | 37 > >> > +--- > >> > 1 file changed, 22 insertions(+), 15 deletions(-) > >> > >> This one needed a bit more work to get building, the incremental diff is > >> below. We need a forward declaration of name, devspec and modalias, > >> which is a bit weird, but that's how the code is currently structured. > >> And there's dev and bus attributes with the same name, so that needed an > >> added "bus". > >> > >> I booted v2 of patch 10 and this one and everything looks identical to > >> upstream. > > > > Ah, many thanks, this was on my todo list to fix up today. > > > > But you renamed the sysfs files when you added "bus" to the function > > names, are you sure you want to do that? I don't mind, but if you > > happen to have userspace tools that look at those files, they just broke > > :( > > Ugh crap, no that won't work. > > I didn't see it when I tested because my machine doesn't have the CMO > feature enabled. > > I guess we have to open code some of the BUS_ATTR_RO() etc. so we can > avoid the name clash. Or split it into multiple files, I've solved this that way in the past. You shouldn't have to "open code" BUS_ATTR_RO(). thanks, greg k-h
linux-next: build failure after merge of the uuid tree
Hi Christoph,
After merging the uuid tree, today's linux-next build (x86_64
allmodconfig) failed like this:
/home/sfr/next/next/drivers/thermal/int340x_thermal/int3400_thermal.c: In
function 'int3400_thermal_get_uuids':
/home/sfr/next/next/drivers/thermal/int340x_thermal/int3400_thermal.c:146:4:
error: implicit declaration of function 'acpi_str_to_uuid'
[-Werror=implicit-function-declaration]
acpi_str_to_uuid(int3400_thermal_uuids[j], uuid);
^
Caused by commit
94116f8126de ("ACPI: Switch to use generic guid_t in acpi_evaluate_dsm()")
I have used the uuid tree from next-20170607 again today.
--
Cheers,
Stephen Rothwell
Re: [PATCH] staging: wlan-ng: cfg80211.c: fixed a line over 80 characters long
On Thu, Jun 08, 2017 at 06:38:30PM -0700, Elias Carter wrote: > From: edcarter > > Fixed a coding style issue where a line was longer than 80 characters. > > Signed-off-by: Elias Carter Your from and signed-off-by names have to match :(
Re: [PATCH 0/3] target: Add TARGET_SCF_LOOKUP_LUN_FROM_TAG support
Hi Himanshu & Quinn, On Wed, 2017-06-07 at 05:02 +, Madhani, Himanshu wrote: > > On Jun 3, 2017, at 3:10 PM, Nicholas A. Bellinger > > wrote: > > > > From: Nicholas Bellinger > > > > Hi Himanshu + Quinn, > > > > Here is a small series to introduce proper percpu se_lun->lun_ref > > counting for TMR, and add common code in target_submit_tmr() to > > do tag lookup for unpacked_lun in order to drop the original > > driver specific lookup within __qlt_24xx_handle_abts(). > > > > It's rather straight-forward, so review and test as a v4.13 item. > > > > Thanks! > > > > Nicholas Bellinger (3): > > target: Add support for TMR percpu reference counting > > target: Add TARGET_SCF_LOOKUP_LUN_FROM_TAG support for ABORT_TASK > > qla2xxx: Convert QLA_TGT_ABTS to TARGET_SCF_LOOKUP_LUN_FROM_TAG > > > > drivers/scsi/qla2xxx/qla_target.c | 39 ++- > > drivers/scsi/qla2xxx/tcm_qla2xxx.c | 4 ++- > > drivers/target/target_core_device.c| 14 ++--- > > drivers/target/target_core_transport.c | 56 > > -- > > include/target/target_core_base.h | 3 +- > > 5 files changed, 71 insertions(+), 45 deletions(-) > > > > -- > > 1.9.1 > > > > -- > > To unsubscribe from this list: send the line "unsubscribe target-devel" in > > the body of a message to majord...@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > Series looks good. > > Acked-by: Himanshu Madhani > Thanks for the review!
Re: [PATCH 4/7] zram: use class_groups instead of class_attrs
On (06/08/17 10:12), Greg Kroah-Hartman wrote: > The class_attrs pointer is long depreciated, and is about to be finally > removed, so move to use the class_groups pointer instead. > > Cc: Minchan Kim > Cc: Nitin Gupta > Cc: Sergey Senozhatsky > Signed-off-by: Greg Kroah-Hartman FWIW, looks good to me. Reviewed-by: Sergey Senozhatsky -ss
[lkp-robot] [x86/mm] d52d163f42: WARNING:at_arch/x86/mm/tlb.c:#switch_mm_irqs_off
FYI, we noticed the following commit:
commit: d52d163f428136feb592f7546cb2333cfad775bf ("x86/mm: Rework lazy TLB mode
and TLB freshness tracking")
https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git x86/pcid
in testcase: trinity
with following parameters:
runtime: 300s
test-description: Trinity is a linux system call fuzz tester.
test-url: http://codemonkey.org.uk/projects/trinity/
on test machine: qemu-system-i386 -enable-kvm -smp 2 -m 320M
caused below changes (please refer to attached dmesg/kmsg for entire
log/backtrace):
+--+++
| | 195a7a2576 | d52d163f42 |
+--+++
| boot_successes | 8 | 3 |
| boot_failures| 0 | 7 |
| WARNING:at_arch/x86/mm/tlb.c:#switch_mm_irqs_off | 0 | 7 |
| EIP:switch_mm_irqs_off | 0 | 7 |
+--+++
[7.985468] WARNING: CPU: 0 PID: 0 at arch/x86/mm/tlb.c:83
switch_mm_irqs_off+0x23/0x393
[7.986572] Modules linked in:
[7.986920] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
4.12.0-rc4-00017-gd52d163 #1
[7.987754] task: 79fb4a40 task.stack: 79faa000
[7.988257] EIP: switch_mm_irqs_off+0x23/0x393
[7.988761] EFLAGS: 00010203 CPU: 0
[7.989157] EAX: 0202 EBX: 79fe5260 ECX: EDX: 79e4aa05
[7.989854] ESI: 8b0959c0 EDI: 79fe5498 EBP: 79fabf18 ESP: 79fabf08
[7.990552] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[7.991159] CR0: 80050033 CR2: 6f6f79c0 CR3: 0c453000 CR4: 0690
[7.991858] Call Trace:
[7.992145] idle_task_exit+0x45/0x55
[7.992565] play_dead_common+0x8/0x1a
[7.992988] native_play_dead+0xa/0xd2
[7.993407] arch_cpu_idle_dead+0x9/0xb
[7.993847] do_idle+0x42/0x166
[7.994206] cpu_startup_entry+0x56/0x58
[7.994654] rest_init+0x108/0x10d
[7.995039] start_kernel+0x3fe/0x406
[7.995463] i386_start_kernel+0x9a/0x9e
[7.995902] startup_32_smp+0x166/0x168
[7.996333] Code: e5 e8 02 fd ff ff 5d c3 55 89 e5 57 56 53 51 89 d3 e8 fc
e7 36 00 64 8b 35 00 04 17 7a 89 c1 9c 58 8d 74 26 00 0f ba e0 09 73 02 <0f> ff
39 de a1 5c 02 0c 7a 0f 85 3c 01 00 00 39 c1 8b 93 bc 01
[7.998498] ---[ end trace 67c561e2f6b242ff ]---
To reproduce:
git clone https://github.com/01org/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k job-script # job-script is attached in this
email
Thanks,
Xiaolong
#
# Automatically generated file; DO NOT EDIT.
# Linux/i386 4.12.0-rc4 Kernel Configuration
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf32-i386"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_BITS_MAX=16
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_32_SMP=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=2
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y
#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
CONFIG_KERNEL_XZ=y
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
# CONFIG_SYSVIPC is not set
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
# CONFIG_CROSS_MEMORY_ATTACH is not set
CONFIG_FHANDLE=y
CONFIG_USELIB=y
CONFIG_AUDIT=y
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
CONFIG_AUDITSYSCALL=y
CONFIG_AUDIT_WATCH=y
CONFIG_AUDIT_TREE=y
#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_GENERIC_IRQ_CHIP=y
CONFIG_IRQ_DOMAIN=y
[lkp-robot] [drm] e1f8a89c4f: pft.faults_per_sec_per_cpu -77.9% regression
Greeting,
FYI, we noticed a -77.9% regression of pft.faults_per_sec_per_cpu due to commit:
commit: e1f8a89c4f33f5b32cfb047f07fdf6d38cda854a ("drm: introduce sync objects
(v4)")
git://people.freedesktop.org/~airlied/linux.git drm-syncobj-sem
in testcase: pft
on test machine: qemu-system-x86_64 -enable-kvm -cpu Penryn -smp 4 -m 2G
with following parameters:
iterations: 20x
test-description: Pft is the page fault test micro benchmark.
test-url: https://github.com/gormanm/pft
Details are as below:
-->
To reproduce:
git clone https://github.com/01org/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k job-script # job-script is attached in this
email
testcase/path_params/tbox_group/run: pft/20x/vm-vp-2G
v4.12-rc2 e1f8a89c4f33f5b32cfb047f07
--
%stddev %change %stddev
\ |\
878620 ±
15% -77.9% 194209 ± 12% pft.faults_per_sec_per_cpu
7.16 ± 23%+257.2% 25.58 ± 12% pft.time.elapsed_time
7.16 ± 23%+257.2% 25.58 ± 12% pft.time.elapsed_time.max
1223 ± 10%+199.9% 3667 ± 15%
pft.time.involuntary_context_switches
61828 ± 2% +10106.0%6310202 ± 0% pft.time.minor_page_faults
145.40 ± 3% +20.6% 175.33 ± 5%
pft.time.percent_of_cpu_this_job_got
9.37 ± 22%+345.2% 41.72 ± 15% pft.time.system_time
5.04 ± 11% -45.6% 2.74 ± 9% mpstat.cpu.usr%
131734 ± 12% +20.3% 158487 ± 5% softirqs.TIMER
1335 ± 11%+105.1% 2738 ±
19% vmstat.system.cs
5390 ± 4% -27.6% 3904 ± 38% slabinfo.kmalloc-96.active_objs
5420 ± 3% -21.5% 4252 ± 27% slabinfo.kmalloc-96.num_objs
68.30 ±209% +13218.2% 9096 ± 84%
latency_stats.max.pipe_read.__vfs_read.vfs_read.SyS_read.entry_SYSCALL_64_fastpath
588552 ± 32% -74.2% 151873 ± 37%
latency_stats.sum.ep_poll.SyS_epoll_wait.do_syscall_64.return_from_SYSCALL_64
74.20 ±203% +12326.8% 9220 ± 82%
latency_stats.sum.pipe_read.__vfs_read.vfs_read.SyS_read.entry_SYSCALL_64_fastpath
160550 ± 14%-100.0% 0.00 ± -1% meminfo.AnonHugePages
204792 ± 0%-100.0% 0.00 ± -1% meminfo.CmaFree
204800 ± 0%-100.0% 0.00 ± -1% meminfo.CmaTotal
3041 ± 0% +13.4% 3449 ± 0% meminfo.KernelStack
51198 ± 0%-100.0% 0.00 ± -1% proc-vmstat.nr_free_cma
3033 ± 1% +13.6% 3446 ± 0% proc-vmstat.nr_kernel_stack
73394 ± 9% +8258.9%6134982 ± 2% proc-vmstat.numa_hit
73394 ± 9% +8258.9%6134982 ± 2% proc-vmstat.numa_local
67006 ± 9% +9043.7%6126912 ± 2% proc-vmstat.pgfault
11161 ± 7%-100.0% 0.00 ± -1%
proc-vmstat.thp_deferred_split_page
11217 ± 7%-100.0% 0.00 ± -1% proc-vmstat.thp_fault_alloc
7.16 ± 23%+257.2% 25.58 ± 12% time.elapsed_time
7.16 ± 23%+257.2% 25.58 ± 12% time.elapsed_time.max
1223 ± 10%+199.9% 3667 ± 15% time.involuntary_context_switches
61828 ± 2% +10106.0%6310202 ± 0% time.minor_page_faults
pft.faults_per_sec_per_cpu
1e+06 ++--*--+
90 ++*.. .. |
| *: ..|
80 ++ : : : ...*|
70 ++ ...* : : : *...|
*...: : : : |
60 ++ : : :: |
50 ++ : : : : |
40 ++ : : : :|
| : : : :|
30 ++ : : : : |
20 O+ O : O :O: O : O OO
Re: [PATCH RFC] KVM: async_pf: fix async_pf exception injection
2017-06-08 19:52 GMT+08:00 Paolo Bonzini : > > 3) add an async_page_fault member to vcpu->arch.exception Do you think we should also add an async_page_fault field to x86_exception, then pass down to kvm_inject_page_fault() through x86_exception? Maybe we should modify kvm_queue_exception_e/kvm_multiple_exception etc to add an function parameter for async_page_fault. Regards, Wanpeng Li
Re: [PATCH] iscsi-target: Fix delayed logout processing greater than SECONDS_FOR_LOGOUT_COMP
Reviews pretty please..?
On Sat, 2017-06-03 at 21:32 +, Nicholas A. Bellinger wrote:
> From: Nicholas Bellinger
>
> This patch fixes a BUG() in iscsit_close_session() that could be
> triggered when iscsit_logout_post_handler() execution from within
> tx thread context was not run for more than SECONDS_FOR_LOGOUT_COMP
> (15 seconds), and the TCP connection didn't already close before
> then forcing tx thread context to automatically exit.
>
> This would manifest itself during explicit logout as:
>
> [33206.974254] 1 connection(s) still exist for iSCSI session to
> iqn.1993-08.org.debian:01:3f5523242179
> [33206.980184] INFO: NMI handler (kgdb_nmi_handler) took too long to run:
> 2100.772 msecs
> [33209.078643] [ cut here ]
> [33209.078646] kernel BUG at drivers/target/iscsi/iscsi_target.c:4346!
>
> Normally when explicit logout attempt fails, the tx thread context
> exits and iscsit_close_connection() from rx thread context does the
> extra cleanup once it detects conn->conn_logout_remove has not been
> cleared by the logout type specific post handlers.
>
> To address this special case, if the logout post handler in tx thread
> context detects conn->tx_thread_active has already been cleared, simply
> return and exit in order for existing iscsit_close_connection()
> logic from rx thread context do failed logout cleanup.
>
> Reported-by: Bart Van Assche
> Cc: Mike Christie
> Cc: Hannes Reinecke
> Cc: Sagi Grimberg
> Cc: sta...@vger.kernel.org # 3.14+
> Signed-off-by: Nicholas Bellinger
> ---
> drivers/target/iscsi/iscsi_target.c | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/target/iscsi/iscsi_target.c
> b/drivers/target/iscsi/iscsi_target.c
> index 0d8f815..c025451 100644
> --- a/drivers/target/iscsi/iscsi_target.c
> +++ b/drivers/target/iscsi/iscsi_target.c
> @@ -4423,8 +4423,11 @@ static void iscsit_logout_post_handler_closesession(
>* always sleep waiting for RX/TX thread shutdown to complete
>* within iscsit_close_connection().
>*/
> - if (!conn->conn_transport->rdma_shutdown)
> + if (!conn->conn_transport->rdma_shutdown) {
> sleep = cmpxchg(&conn->tx_thread_active, true, false);
> + if (!sleep)
> + return;
> + }
>
> atomic_set(&conn->conn_logout_remove, 0);
> complete(&conn->conn_logout_comp);
> @@ -4440,8 +4443,11 @@ static void iscsit_logout_post_handler_samecid(
> {
> int sleep = 1;
>
> - if (!conn->conn_transport->rdma_shutdown)
> + if (!conn->conn_transport->rdma_shutdown) {
> sleep = cmpxchg(&conn->tx_thread_active, true, false);
> + if (!sleep)
> + return;
> + }
>
> atomic_set(&conn->conn_logout_remove, 0);
> complete(&conn->conn_logout_comp);
Re: [PATCH] target: Fix kref->refcount underflow in transport_cmd_finish_abort
(Adding Quinn CC')
Reviews please..?
On Sat, 2017-06-03 at 21:09 +, Nicholas A. Bellinger wrote:
> From: Nicholas Bellinger
>
> This patch fixes a se_cmd->cmd_kref underflow during CMD_T_ABORTED
> when a fabric driver drops it's second reference from below the
> target_core_tmr.c based callers of transport_cmd_finish_abort().
>
> Recently with the conversion of kref to refcount_t, this bug was
> manifesting itself as:
>
> [705519.601034] refcount_t: underflow; use-after-free.
> [705519.604034] INFO: NMI handler (kgdb_nmi_handler) took too long to run:
> 20116.512 msecs
> [705539.719111] [ cut here ]
> [705539.719117] WARNING: CPU: 3 PID: 26510 at lib/refcount.c:184
> refcount_sub_and_test+0x33/0x51
>
> Since the original kref atomic_t based kref_put() didn't check for
> underflow and only invoked the final callback when zero was reached,
> this bug did not manifest in practice since all se_cmd memory is
> using preallocated tags.
>
> To address this, go ahead and propigate the existing return from
> transport_put_cmd() up via transport_cmd_finish_abort(), and
> change transport_cmd_finish_abort() + core_tmr_handle_tas_abort()
> callers to only do their local target_put_sess_cmd() if necessary.
>
> Reported-by: Bart Van Assche
> Cc: Mike Christie
> Cc: Hannes Reinecke
> Cc: Christoph Hellwig
> Cc: Himanshu Madhani
> Cc: Sagi Grimberg
> Cc: sta...@vger.kernel.org # 3.14+
> Signed-off-by: Nicholas Bellinger
> ---
> drivers/target/target_core_internal.h | 2 +-
> drivers/target/target_core_tmr.c | 16
> drivers/target/target_core_transport.c | 9 ++---
> 3 files changed, 15 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/target/target_core_internal.h
> b/drivers/target/target_core_internal.h
> index 9ab7090..0912de7 100644
> --- a/drivers/target/target_core_internal.h
> +++ b/drivers/target/target_core_internal.h
> @@ -136,7 +136,7 @@ struct se_node_acl
> *core_tpg_add_initiator_node_acl(struct se_portal_group *tpg,
> void release_se_kmem_caches(void);
> u32 scsi_get_new_index(scsi_index_t);
> void transport_subsystem_check_init(void);
> -void transport_cmd_finish_abort(struct se_cmd *, int);
> +int transport_cmd_finish_abort(struct se_cmd *, int);
> unsigned char *transport_dump_cmd_direction(struct se_cmd *);
> void transport_dump_dev_state(struct se_device *, char *, int *);
> void transport_dump_dev_info(struct se_device *, struct se_lun *,
> diff --git a/drivers/target/target_core_tmr.c
> b/drivers/target/target_core_tmr.c
> index dce1e1b..13f47bf 100644
> --- a/drivers/target/target_core_tmr.c
> +++ b/drivers/target/target_core_tmr.c
> @@ -75,7 +75,7 @@ void core_tmr_release_req(struct se_tmr_req *tmr)
> kfree(tmr);
> }
>
> -static void core_tmr_handle_tas_abort(struct se_cmd *cmd, int tas)
> +static int core_tmr_handle_tas_abort(struct se_cmd *cmd, int tas)
> {
> unsigned long flags;
> bool remove = true, send_tas;
> @@ -91,7 +91,7 @@ static void core_tmr_handle_tas_abort(struct se_cmd *cmd,
> int tas)
> transport_send_task_abort(cmd);
> }
>
> - transport_cmd_finish_abort(cmd, remove);
> + return transport_cmd_finish_abort(cmd, remove);
> }
>
> static int target_check_cdb_and_preempt(struct list_head *list,
> @@ -184,8 +184,8 @@ void core_tmr_abort_task(
> cancel_work_sync(&se_cmd->work);
> transport_wait_for_tasks(se_cmd);
>
> - transport_cmd_finish_abort(se_cmd, true);
> - target_put_sess_cmd(se_cmd);
> + if (!transport_cmd_finish_abort(se_cmd, true))
> + target_put_sess_cmd(se_cmd);
>
> printk("ABORT_TASK: Sending TMR_FUNCTION_COMPLETE for"
> " ref_tag: %llu\n", ref_tag);
> @@ -281,8 +281,8 @@ static void core_tmr_drain_tmr_list(
> cancel_work_sync(&cmd->work);
> transport_wait_for_tasks(cmd);
>
> - transport_cmd_finish_abort(cmd, 1);
> - target_put_sess_cmd(cmd);
> + if (!transport_cmd_finish_abort(cmd, 1))
> + target_put_sess_cmd(cmd);
> }
> }
>
> @@ -380,8 +380,8 @@ static void core_tmr_drain_state_list(
> cancel_work_sync(&cmd->work);
> transport_wait_for_tasks(cmd);
>
> - core_tmr_handle_tas_abort(cmd, tas);
> - target_put_sess_cmd(cmd);
> + if (!core_tmr_handle_tas_abort(cmd, tas))
> + target_put_sess_cmd(cmd);
> }
> }
>
> diff --git a/drivers/target/target_core_transport.c
> b/drivers/target/target_core_transport.c
> index 6025935..f1b3a46 100644
> --- a/drivers/target/target_core_transport.c
> +++ b/drivers/target/target_core_transport.c
> @@ -651,9 +651,10 @@ static void transport_lun_remove_cmd(struct se_cmd *cmd)
> percpu_ref_put(&lun->lun_ref);
> }
>
> -void transport_cmd_finish_abort(struct se_cmd *cmd,
Re: [PATCH 3/3] libnvdimm: New ACPI 6.2 DSM functions
On Thu, Jun 8, 2017 at 1:02 AM, Johannes Thumshirn wrote: > On 06/07/2017 07:04 PM, Jerry Hoemann wrote: >> @@ -179,6 +217,10 @@ static inline const char *nvdimm_bus_cmd_name(unsigned >> cmd) >> [ND_CMD_ARS_START] = "ars_start", >> [ND_CMD_ARS_STATUS] = "ars_status", >> [ND_CMD_CLEAR_ERROR] = "clear_error", >> + [5] = "trans_spa", >> + [7] = "ars_err_inj", >> + [8] = "ars_err_inj_clr", >> + [9] = "ars_err_inj_stat", >> [ND_CMD_CALL] = "cmd_call", >> }; > > Can you please add the new values to the enum in uapi/ndctl.h? I don't > really like the magic numbers here. I think the reason Jerry didn't add them is due to symmetry. All the current ND_CMD_ definitions have corresponding ND_IOCTL_ definitions. These new commands we're only adding function number support and using ND_CMD_CALL for the ioctl transport. We can still add definitions for them, but perhaps with an ACPI_NFIT_DSM_ prefix? The only consumer in the kernel of this is debug output code. I think perhaps we should just delete them here and either print raw numbers or enable acpi_nfit_ctl() to the decode and not rely on nvdimm_bus_cmd_name() which is meant to represent NVDIMM bus type generic command numbers.
[PATCH] Drivers: unisys: visorhba - style fix
Fixed style of permissions to octal.
Found using checkpatch
Signed-off-by: Derek Robson
---
drivers/staging/unisys/visorhba/visorhba_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/unisys/visorhba/visorhba_main.c
b/drivers/staging/unisys/visorhba/visorhba_main.c
index 2fd31c9762c6..a6e7a6bbc428 100644
--- a/drivers/staging/unisys/visorhba/visorhba_main.c
+++ b/drivers/staging/unisys/visorhba/visorhba_main.c
@@ -1090,7 +1090,7 @@ static int visorhba_probe(struct visor_device *dev)
goto err_scsi_remove_host;
}
devdata->debugfs_info =
- debugfs_create_file("info", S_IRUSR | S_IRGRP,
+ debugfs_create_file("info", 0440,
devdata->debugfs_dir, devdata,
&info_debugfs_fops);
if (!devdata->debugfs_info) {
--
2.13.0
[PATCH 2/9] libnvdimm, label: add v1.2 interleave-set-cookie algorithm
The interleave-set-cookie algorithm is extended to incorporate all the
same components that are used to generate an nvdimm unique-id. For
backwards compatibility we still maintain the old v1.1 definition.
Signed-off-by: Dan Williams
---
drivers/acpi/nfit/core.c| 53 ++-
drivers/nvdimm/label.c |3 +-
drivers/nvdimm/namespace_devs.c |9 +--
drivers/nvdimm/nd.h |3 +-
drivers/nvdimm/region_devs.c| 43
include/linux/libnvdimm.h |5 +++-
6 files changed, 104 insertions(+), 12 deletions(-)
diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c
index 097eff0b963d..db21f5b62562 100644
--- a/drivers/acpi/nfit/core.c
+++ b/drivers/acpi/nfit/core.c
@@ -1663,12 +1663,29 @@ struct nfit_set_info {
} mapping[0];
};
+struct nfit_set_info2 {
+ struct nfit_set_info_map2 {
+ u64 region_offset;
+ u32 serial_number;
+ u16 vendor_id;
+ u16 manufacturing_date;
+ u8 manufacturing_location;
+ u8 reserved[31];
+ } mapping[0];
+};
+
static size_t sizeof_nfit_set_info(int num_mappings)
{
return sizeof(struct nfit_set_info)
+ num_mappings * sizeof(struct nfit_set_info_map);
}
+static size_t sizeof_nfit_set_info2(int num_mappings)
+{
+ return sizeof(struct nfit_set_info2)
+ + num_mappings * sizeof(struct nfit_set_info_map2);
+}
+
static int cmp_map_compat(const void *m0, const void *m1)
{
const struct nfit_set_info_map *map0 = m0;
@@ -1690,6 +1707,18 @@ static int cmp_map(const void *m0, const void *m1)
return 0;
}
+static int cmp_map2(const void *m0, const void *m1)
+{
+ const struct nfit_set_info_map2 *map0 = m0;
+ const struct nfit_set_info_map2 *map1 = m1;
+
+ if (map0->region_offset < map1->region_offset)
+ return -1;
+ else if (map0->region_offset > map1->region_offset)
+ return 1;
+ return 0;
+}
+
/* Retrieve the nth entry referencing this spa */
static struct acpi_nfit_memory_map *memdev_from_spa(
struct acpi_nfit_desc *acpi_desc, u16 range_index, int n)
@@ -1711,6 +1740,7 @@ static int acpi_nfit_init_interleave_set(struct
acpi_nfit_desc *acpi_desc,
struct device *dev = acpi_desc->dev;
struct nd_interleave_set *nd_set;
u16 nr = ndr_desc->num_mappings;
+ struct nfit_set_info2 *info2;
struct nfit_set_info *info;
if (spa_type == NFIT_SPA_PM || spa_type == NFIT_SPA_VOLATILE)
@@ -1725,9 +1755,15 @@ static int acpi_nfit_init_interleave_set(struct
acpi_nfit_desc *acpi_desc,
info = devm_kzalloc(dev, sizeof_nfit_set_info(nr), GFP_KERNEL);
if (!info)
return -ENOMEM;
+
+ info2 = devm_kzalloc(dev, sizeof_nfit_set_info2(nr), GFP_KERNEL);
+ if (!info2)
+ return -ENOMEM;
+
for (i = 0; i < nr; i++) {
struct nd_mapping_desc *mapping = &ndr_desc->mapping[i];
struct nfit_set_info_map *map = &info->mapping[i];
+ struct nfit_set_info_map2 *map2 = &info2->mapping[i];
struct nvdimm *nvdimm = mapping->nvdimm;
struct nfit_mem *nfit_mem = nvdimm_provider_data(nvdimm);
struct acpi_nfit_memory_map *memdev = memdev_from_spa(acpi_desc,
@@ -1740,19 +1776,32 @@ static int acpi_nfit_init_interleave_set(struct
acpi_nfit_desc *acpi_desc,
map->region_offset = memdev->region_offset;
map->serial_number = nfit_mem->dcr->serial_number;
+
+ map2->region_offset = memdev->region_offset;
+ map2->serial_number = nfit_mem->dcr->serial_number;
+ map2->vendor_id = nfit_mem->dcr->vendor_id;
+ map2->manufacturing_date = nfit_mem->dcr->manufacturing_date;
+ map2->manufacturing_location =
nfit_mem->dcr->manufacturing_location;
}
+ /* v1.1 namespaces */
sort(&info->mapping[0], nr, sizeof(struct nfit_set_info_map),
cmp_map, NULL);
- nd_set->cookie = nd_fletcher64(info, sizeof_nfit_set_info(nr), 0);
+ nd_set->cookie1 = nd_fletcher64(info, sizeof_nfit_set_info(nr), 0);
+
+ /* v1.2 namespaces */
+ sort(&info2->mapping[0], nr, sizeof(struct nfit_set_info_map2),
+ cmp_map2, NULL);
+ nd_set->cookie2 = nd_fletcher64(info, sizeof_nfit_set_info2(nr), 0);
- /* support namespaces created with the wrong sort order */
+ /* support v1.1 namespaces created with the wrong sort order */
sort(&info->mapping[0], nr, sizeof(struct nfit_set_info_map),
cmp_map_compat, NULL);
nd_set->altcookie = nd_fletcher64(info, sizeof_nfit_set_info(nr), 0);
ndr_desc->nd_set = nd_set;
devm_kfree(dev, info);
+ devm_kfree(dev, info2);
[PATCH 4/9] libnvdimm, label: populate the type_guid property for v1.2 namespaces
The type_guid refers to the "Address Range Type GUID" for the region
backing a namespace as defined the ACPI NFIT (NVDIMM Firmware Interface
Table). This 'type' identifier specifies an access mechanism for the
given namespace. This capability replaces the confusing usage of the
'NSLABEL_FLAG_LOCAL' flag to indicate a block-aperture-mode namespace.
Signed-off-by: Dan Williams
---
drivers/acpi/nfit/core.c| 15 +++---
drivers/nvdimm/label.c |6
drivers/nvdimm/namespace_devs.c | 57 ++-
include/linux/libnvdimm.h |3 ++
4 files changed, 57 insertions(+), 24 deletions(-)
diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c
index db21f5b62562..83ee3c829411 100644
--- a/drivers/acpi/nfit/core.c
+++ b/drivers/acpi/nfit/core.c
@@ -1743,15 +1743,17 @@ static int acpi_nfit_init_interleave_set(struct
acpi_nfit_desc *acpi_desc,
struct nfit_set_info2 *info2;
struct nfit_set_info *info;
+ nd_set = devm_kzalloc(dev, sizeof(*nd_set), GFP_KERNEL);
+ if (!nd_set)
+ return -ENOMEM;
+ ndr_desc->nd_set = nd_set;
+ guid_copy(&nd_set->type_guid, (guid_t *) spa->range_guid);
+
if (spa_type == NFIT_SPA_PM || spa_type == NFIT_SPA_VOLATILE)
/* pass */;
else
return 0;
- nd_set = devm_kzalloc(dev, sizeof(*nd_set), GFP_KERNEL);
- if (!nd_set)
- return -ENOMEM;
-
info = devm_kzalloc(dev, sizeof_nfit_set_info(nr), GFP_KERNEL);
if (!info)
return -ENOMEM;
@@ -2228,7 +2230,7 @@ static int acpi_nfit_init_mapping(struct acpi_nfit_desc
*acpi_desc,
struct acpi_nfit_system_address *spa = nfit_spa->spa;
struct nd_blk_region_desc *ndbr_desc;
struct nfit_mem *nfit_mem;
- int blk_valid = 0;
+ int blk_valid = 0, rc;
if (!nvdimm) {
dev_err(acpi_desc->dev, "spa%d dimm: %#x not found\n",
@@ -2260,6 +2262,9 @@ static int acpi_nfit_init_mapping(struct acpi_nfit_desc
*acpi_desc,
ndbr_desc = to_blk_region_desc(ndr_desc);
ndbr_desc->enable = acpi_nfit_blk_region_enable;
ndbr_desc->do_io = acpi_desc->blk_do_io;
+ rc = acpi_nfit_init_interleave_set(acpi_desc, ndr_desc, spa);
+ if (rc)
+ return rc;
nfit_spa->nd_region =
nvdimm_blk_region_create(acpi_desc->nvdimm_bus,
ndr_desc);
if (!nfit_spa->nd_region)
diff --git a/drivers/nvdimm/label.c b/drivers/nvdimm/label.c
index 1aacd4866c76..d8b87d3a0ebe 100644
--- a/drivers/nvdimm/label.c
+++ b/drivers/nvdimm/label.c
@@ -553,6 +553,7 @@ static int __pmem_label_update(struct nd_region *nd_region,
struct nd_mapping *nd_mapping, struct nd_namespace_pmem *nspm,
int pos)
{
+ struct nd_interleave_set *nd_set = nd_region->nd_set;
struct nvdimm_drvdata *ndd = to_ndd(nd_mapping);
struct nd_label_ent *label_ent, *victim = NULL;
struct nd_namespace_label *nd_label;
@@ -597,6 +598,8 @@ static int __pmem_label_update(struct nd_region *nd_region,
nd_label->rawsize = __cpu_to_le64(resource_size(res));
nd_label->dpa = __cpu_to_le64(res->start);
nd_label->slot = __cpu_to_le32(slot);
+ if (namespace_label_has(ndd, type_guid))
+ guid_copy(&nd_label->type_guid, &nd_set->type_guid);
nd_dbg_dpa(nd_region, ndd, res, "%s\n", __func__);
/* update label */
@@ -684,6 +687,7 @@ static int __blk_label_update(struct nd_region *nd_region,
int num_labels)
{
int i, alloc, victims, nfree, old_num_resources, nlabel, rc = -ENXIO;
+ struct nd_interleave_set *nd_set = nd_region->nd_set;
struct nvdimm_drvdata *ndd = to_ndd(nd_mapping);
struct nd_namespace_label *nd_label;
struct nd_label_ent *label_ent, *e;
@@ -788,6 +792,8 @@ static int __blk_label_update(struct nd_region *nd_region,
nd_label->rawsize = __cpu_to_le64(resource_size(res));
nd_label->lbasize = __cpu_to_le64(nsblk->lbasize);
nd_label->slot = __cpu_to_le32(slot);
+ if (namespace_label_has(ndd, type_guid))
+ guid_copy(&nd_label->type_guid, &nd_set->type_guid);
/* update label */
offset = nd_label_offset(ndd, nd_label);
diff --git a/drivers/nvdimm/namespace_devs.c b/drivers/nvdimm/namespace_devs.c
index e034b003a5e2..e101aec186c7 100644
--- a/drivers/nvdimm/namespace_devs.c
+++ b/drivers/nvdimm/namespace_devs.c
@@ -1639,6 +1639,8 @@ static bool has_uuid_at_pos(struct nd_region *nd_region,
u8 *uuid,
for (i = 0; i < nd_region->ndr_mappings; i++) {
struct nd_mapping *nd_mapping = &nd_region->mapping[i];
+ struct nd_interleave_set *nd_set = nd_region->nd_set;
+ struct nvdimm_dr
[PATCH 7/9] libnvdimm, label: add v1.2 label checksum support
The v1.2 namespace label specification adds a fletcher checksum to each
label instance. Add generation and validation support for the new field.
Signed-off-by: Dan Williams
---
drivers/nvdimm/label.c | 39 +++
1 file changed, 35 insertions(+), 4 deletions(-)
diff --git a/drivers/nvdimm/label.c b/drivers/nvdimm/label.c
index d7f9916c6ed5..c503362a03c7 100644
--- a/drivers/nvdimm/label.c
+++ b/drivers/nvdimm/label.c
@@ -326,7 +326,8 @@ static bool preamble_next(struct nvdimm_drvdata *ndd,
free, nslot);
}
-static bool slot_valid(struct nd_namespace_label *nd_label, u32 slot)
+static bool slot_valid(struct nvdimm_drvdata *ndd,
+ struct nd_namespace_label *nd_label, u32 slot)
{
/* check that we are written where we expect to be written */
if (slot != __le32_to_cpu(nd_label->slot))
@@ -337,6 +338,21 @@ static bool slot_valid(struct nd_namespace_label
*nd_label, u32 slot)
| __le64_to_cpu(nd_label->rawsize)) % SZ_4K)
return false;
+ /* check checksum */
+ if (namespace_label_has(ndd, checksum)) {
+ u64 sum, sum_save;
+
+ sum_save = __le64_to_cpu(nd_label->checksum);
+ nd_label->checksum = __cpu_to_le64(0);
+ sum = nd_fletcher64(nd_label, sizeof_namespace_label(ndd), 1);
+ nd_label->checksum = __cpu_to_le64(sum_save);
+ if (sum != sum_save) {
+ dev_dbg(ndd->dev, "%s fail checksum. slot: %d expect:
%#llx\n",
+ __func__, slot, sum);
+ return false;
+ }
+ }
+
return true;
}
@@ -359,7 +375,7 @@ int nd_label_reserve_dpa(struct nvdimm_drvdata *ndd)
nd_label = to_label(ndd, slot);
- if (!slot_valid(nd_label, slot))
+ if (!slot_valid(ndd, nd_label, slot))
continue;
memcpy(label_uuid, nd_label->uuid, NSLABEL_UUID_LEN);
@@ -391,7 +407,7 @@ int nd_label_active_count(struct nvdimm_drvdata *ndd)
nd_label = to_label(ndd, slot);
- if (!slot_valid(nd_label, slot)) {
+ if (!slot_valid(ndd, nd_label, slot)) {
u32 label_slot = __le32_to_cpu(nd_label->slot);
u64 size = __le64_to_cpu(nd_label->rawsize);
u64 dpa = __le64_to_cpu(nd_label->dpa);
@@ -419,7 +435,7 @@ struct nd_namespace_label *nd_label_active(struct
nvdimm_drvdata *ndd, int n)
struct nd_namespace_label *nd_label;
nd_label = to_label(ndd, slot);
- if (!slot_valid(nd_label, slot))
+ if (!slot_valid(ndd, nd_label, slot))
continue;
if (n-- == 0)
@@ -600,6 +616,13 @@ static int __pmem_label_update(struct nd_region *nd_region,
nd_label->slot = __cpu_to_le32(slot);
if (namespace_label_has(ndd, type_guid))
guid_copy(&nd_label->type_guid, &nd_set->type_guid);
+ if (namespace_label_has(ndd, checksum)) {
+ u64 sum;
+
+ nd_label->checksum = __cpu_to_le64(0);
+ sum = nd_fletcher64(nd_label, sizeof_namespace_label(ndd), 1);
+ nd_label->checksum = __cpu_to_le64(sum);
+ }
nd_dbg_dpa(nd_region, ndd, res, "%s\n", __func__);
/* update label */
@@ -825,6 +848,14 @@ static int __blk_label_update(struct nd_region *nd_region,
nd_label->slot = __cpu_to_le32(slot);
if (namespace_label_has(ndd, type_guid))
guid_copy(&nd_label->type_guid, &nd_set->type_guid);
+ if (namespace_label_has(ndd, checksum)) {
+ u64 sum;
+
+ nd_label->checksum = __cpu_to_le64(0);
+ sum = nd_fletcher64(nd_label,
+ sizeof_namespace_label(ndd), 1);
+ nd_label->checksum = __cpu_to_le64(sum);
+ }
/* update label */
offset = nd_label_offset(ndd, nd_label);
[PATCH 9/9] libnvdimm, label: switch to using v1.2 labels by default
The rules for which version of the label specification are in effect at
any given point in time are as follows:
1/ If a DIMM has an existing / valid index block then the version
specified is used regardless if it is a previous version.
2/ By default when the kernel is initializing new index blocks the
latest specification version (v1.2 at time of writing) is used.
3/ An environment that wants to force create v1.1 label-sets must
arrange for userspace to disable all active regions / namespaces /
dimms and write a valid set of v1.1 index blocks to the dimms.
Signed-off-by: Dan Williams
---
drivers/nvdimm/label.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/nvdimm/label.c b/drivers/nvdimm/label.c
index 837bf21c8555..235f2089fab2 100644
--- a/drivers/nvdimm/label.c
+++ b/drivers/nvdimm/label.c
@@ -222,9 +222,10 @@ int nd_label_validate(struct nvdimm_drvdata *ndd)
* need to know the size of the labels, and we can't trust the
* size of the labels until we validate the index blocks.
* Resolve this dependency loop by probing for known label
-* sizes.
+* sizes, but default to v1.2 256-byte namespace labels if
+* discovery fails.
*/
- int label_size[] = { 256, 128 };
+ int label_size[] = { 128, 256 };
int i, rc;
for (i = 0; i < ARRAY_SIZE(label_size); i++) {
@@ -532,7 +533,10 @@ static int nd_label_write_index(struct nvdimm_drvdata
*ndd, int index, u32 seq,
nsindex->labeloff = __cpu_to_le64(offset);
nsindex->nslot = __cpu_to_le32(nslot);
nsindex->major = __cpu_to_le16(1);
- nsindex->minor = __cpu_to_le16(1);
+ if (sizeof_namespace_label(ndd) < 256)
+ nsindex->minor = __cpu_to_le16(1);
+ else
+ nsindex->minor = __cpu_to_le16(2);
nsindex->checksum = __cpu_to_le64(0);
if (flags & ND_NSINDEX_INIT) {
unsigned long *free = (unsigned long *) nsindex->free;
[PATCH 8/9] libnvdimm, label: add address abstraction identifiers
Starting with v1.2 labels, 'address abstractions' can be hinted via an
address abstraction id that implies an info-block format. The standard
address abstraction in the specification is the v2 format of the
Block-Translation-Table (BTT). Support for that is saved for a later
patch, for now we add support for the Linux supported address
abstractions BTT (v1), PFN, and DAX.
The new 'holder_class' attribute for namespace devices is added for
tooling to specify the 'abstraction_guid' to store in the namespace label.
For v1.1 labels this field is undefined and any setting of
'holder_class' away from the default 'none' value will only have effect
until the driver is unloaded. Setting 'holder_class' requires that
whatever device tries to claim the namespace must be of the specified
class.
Cc: Vishal Verma
Signed-off-by: Dan Williams
---
drivers/nvdimm/btt_devs.c |8
drivers/nvdimm/claim.c | 28 +++
drivers/nvdimm/core.c |3 ++
drivers/nvdimm/dax_devs.c |8
drivers/nvdimm/label.c | 58 +++
drivers/nvdimm/label.h |5 +++
drivers/nvdimm/namespace_devs.c | 74 +++
drivers/nvdimm/nd.h |1 +
drivers/nvdimm/pfn_devs.c |8
include/linux/nd.h | 10 +
10 files changed, 203 insertions(+)
diff --git a/drivers/nvdimm/btt_devs.c b/drivers/nvdimm/btt_devs.c
index 4c989bb9a8a0..31d875a91569 100644
--- a/drivers/nvdimm/btt_devs.c
+++ b/drivers/nvdimm/btt_devs.c
@@ -295,6 +295,14 @@ int nd_btt_probe(struct device *dev, struct
nd_namespace_common *ndns)
if (ndns->force_raw)
return -ENODEV;
+ switch (ndns->claim_class) {
+ case NVDIMM_CCLASS_NONE:
+ case NVDIMM_CCLASS_BTT:
+ break;
+ default:
+ return -ENODEV;
+ }
+
nvdimm_bus_lock(&ndns->dev);
btt_dev = __nd_btt_create(nd_region, 0, NULL, ndns);
nvdimm_bus_unlock(&ndns->dev);
diff --git a/drivers/nvdimm/claim.c b/drivers/nvdimm/claim.c
index 7ceb5fa4f2a1..de9b1cce242e 100644
--- a/drivers/nvdimm/claim.c
+++ b/drivers/nvdimm/claim.c
@@ -184,6 +184,34 @@ ssize_t nd_namespace_store(struct device *dev,
}
ndns = to_ndns(found);
+
+ switch (ndns->claim_class) {
+ case NVDIMM_CCLASS_NONE:
+ break;
+ case NVDIMM_CCLASS_BTT:
+ if (!is_nd_btt(dev)) {
+ len = -EBUSY;
+ goto out_attach;
+ }
+ break;
+ case NVDIMM_CCLASS_PFN:
+ if (!is_nd_pfn(dev)) {
+ len = -EBUSY;
+ goto out_attach;
+ }
+ break;
+ case NVDIMM_CCLASS_DAX:
+ if (!is_nd_dax(dev)) {
+ len = -EBUSY;
+ goto out_attach;
+ }
+ break;
+ default:
+ len = -EBUSY;
+ goto out_attach;
+ break;
+ }
+
if (__nvdimm_namespace_capacity(ndns) < SZ_16M) {
dev_dbg(dev, "%s too small to host\n", name);
len = -ENXIO;
diff --git a/drivers/nvdimm/core.c b/drivers/nvdimm/core.c
index 2dee908e4bae..ed0bf174d128 100644
--- a/drivers/nvdimm/core.c
+++ b/drivers/nvdimm/core.c
@@ -699,6 +699,9 @@ static __init int libnvdimm_init(void)
rc = nd_region_init();
if (rc)
goto err_region;
+
+ nd_label_init();
+
return 0;
err_region:
nvdimm_exit();
diff --git a/drivers/nvdimm/dax_devs.c b/drivers/nvdimm/dax_devs.c
index c1b6556aea6e..59f676381ae5 100644
--- a/drivers/nvdimm/dax_devs.c
+++ b/drivers/nvdimm/dax_devs.c
@@ -111,6 +111,14 @@ int nd_dax_probe(struct device *dev, struct
nd_namespace_common *ndns)
if (ndns->force_raw)
return -ENODEV;
+ switch (ndns->claim_class) {
+ case NVDIMM_CCLASS_NONE:
+ case NVDIMM_CCLASS_DAX:
+ break;
+ default:
+ return -ENODEV;
+ }
+
nvdimm_bus_lock(&ndns->dev);
nd_dax = nd_dax_alloc(nd_region);
nd_pfn = &nd_dax->nd_pfn;
diff --git a/drivers/nvdimm/label.c b/drivers/nvdimm/label.c
index c503362a03c7..837bf21c8555 100644
--- a/drivers/nvdimm/label.c
+++ b/drivers/nvdimm/label.c
@@ -12,6 +12,7 @@
*/
#include
#include
+#include
#include
#include
#include
@@ -19,6 +20,10 @@
#include "label.h"
#include "nd.h"
+static guid_t nvdimm_btt_guid;
+static guid_t nvdimm_pfn_guid;
+static guid_t nvdimm_dax_guid;
+
static u32 best_seq(u32 a, u32 b)
{
a &= NSINDEX_SEQ_MASK;
@@ -565,10 +570,44 @@ static unsigned long nd_label_offset(struct
nvdimm_drvdata *ndd,
- (unsigned long) to_namespace_index(ndd, 0);
}
+enum nvdimm_claim_class to_nvdimm_cclass(guid_t *guid)
+{
+ if (guid_equal(guid, &nvdimm_btt_guid))
+
[PATCH 0/9] libnvdimm, label: namespace specification v1.2 support
The recently released UEFI 2.7 Specification [1], includes an updated
version (v1.2) of the NVDIMM Namespace Label Specification that was previously
published on pmem.io [2] (v1.1).
In the process of moving to a UEFI standard definition the v1.2 updates
adds several features for improved cross-OS and pre-OS (EFI driver)
compatibility and safety. The major highlights include:
1/ Support for an "address abstraction guid" so that implementations can
uniquely identify personalities layered on top of a namespace. A
standard address abstraction definition example is the BTT (Block
Translation Table for sector atomicity) layout. A private / local
abstraction definition example is the Linux device-DAX personality.
2/ Checksums for individual label slots
3/ Additional safety and self-consistency properties like an updated
interleave-set-cookie algorithm and recording the NFIT address-type-guid
in the namespace.
UEFI mandates that these labels be accessed through new ACPI methods
_LSI, _LSR, and _LSW (Label Storage {Info,Read,Write}), however support
for those is saved for a later patch series once the ACPICA enabling for
ACPI 6.2 lands in an immutable form in the acpi tree.
These updates pass a run through the nvdimm unit tests and an updated
version of the tests targeting the address-abstraction guid. This set is
based on the 'uuid-types' branch of git.infradead.org/users/hch/uuid.git
which includes Christoph's and Andy's revamp of the kernel's uuid + guid
helper routines.
[1]: http://www.uefi.org/sites/default/files/resources/UEFI_Spec_2_7.pdf
[2]: http://pmem.io/documents/NVDIMM_Namespace_Spec.pdf
---
Dan Williams (9):
libnvdimm, label: add v1.2 nvdimm label definitions
libnvdimm, label: add v1.2 interleave-set-cookie algorithm
libnvdimm, label: honor the lba size specified in v1.2 labels
libnvdimm, label: populate the type_guid property for v1.2 namespaces
libnvdimm, label: populate 'isetcookie' for blk-aperture namespaces
libnvdimm, label: update 'nlabel' and 'position' handling for local
namespaces
libnvdimm, label: add v1.2 label checksum support
libnvdimm, label: add address abstraction identifiers
libnvdimm, label: switch to using v1.2 labels by default
drivers/acpi/nfit/core.c| 67 +--
drivers/nvdimm/btt_devs.c |8 +
drivers/nvdimm/claim.c | 28
drivers/nvdimm/core.c |3
drivers/nvdimm/dax_devs.c |8 +
drivers/nvdimm/label.c | 244 +++
drivers/nvdimm/label.h | 20 +++
drivers/nvdimm/namespace_devs.c | 211 +-
drivers/nvdimm/nd.h | 13 ++
drivers/nvdimm/pfn_devs.c |8 +
drivers/nvdimm/pmem.c |1
drivers/nvdimm/region_devs.c| 43 ++-
include/linux/libnvdimm.h |8 +
include/linux/nd.h | 12 ++
14 files changed, 596 insertions(+), 78 deletions(-)
[PATCH 1/9] libnvdimm, label: add v1.2 nvdimm label definitions
In support of improved interoperability between operating systems and pre-boot
environments the Intel proposed NVDIMM Namespace Specification [1], has been
adopted and modified to the the UEFI 2.7 NVDIMM Label Protocol [2].
Update the definitions of the namespace label data structures so that the new
format can be supported alongside the existing label format.
The new specification changes the default label size to 256 bytes, so
everywhere that relied on sizeof(struct nd_namespace_label) must now use the
sizeof_namespace_label() helper.
There should be no functional differences from these changes as the
default is still the v1.1 128-byte format. Future patches will move the
default to the v1.2 definition.
[1]: http://pmem.io/documents/NVDIMM_Namespace_Spec.pdf
[2]: http://www.uefi.org/sites/default/files/resources/UEFI_Spec_2_7.pdf
Signed-off-by: Dan Williams
---
drivers/nvdimm/label.c | 95 +++-
drivers/nvdimm/label.h | 15 +++-
drivers/nvdimm/nd.h|8
3 files changed, 97 insertions(+), 21 deletions(-)
diff --git a/drivers/nvdimm/label.c b/drivers/nvdimm/label.c
index dd615345699f..d6233d220bfd 100644
--- a/drivers/nvdimm/label.c
+++ b/drivers/nvdimm/label.c
@@ -34,6 +34,11 @@ static u32 best_seq(u32 a, u32 b)
return a;
}
+unsigned sizeof_namespace_label(struct nvdimm_drvdata *ndd)
+{
+ return ndd->nslabel_size;
+}
+
size_t sizeof_namespace_index(struct nvdimm_drvdata *ndd)
{
u32 index_span;
@@ -49,7 +54,7 @@ size_t sizeof_namespace_index(struct nvdimm_drvdata *ndd)
* starts to waste space at larger config_sizes, but it's
* unlikely we'll ever see anything but 128K.
*/
- index_span = ndd->nsarea.config_size / 129;
+ index_span = ndd->nsarea.config_size / (sizeof_namespace_label(ndd) +
1);
index_span /= NSINDEX_ALIGN * 2;
ndd->nsindex_size = index_span * NSINDEX_ALIGN;
@@ -58,10 +63,10 @@ size_t sizeof_namespace_index(struct nvdimm_drvdata *ndd)
int nvdimm_num_label_slots(struct nvdimm_drvdata *ndd)
{
- return ndd->nsarea.config_size / 129;
+ return ndd->nsarea.config_size / (sizeof_namespace_label(ndd) + 1);
}
-int nd_label_validate(struct nvdimm_drvdata *ndd)
+static int __nd_label_validate(struct nvdimm_drvdata *ndd)
{
/*
* On media label format consists of two index blocks followed
@@ -104,6 +109,7 @@ int nd_label_validate(struct nvdimm_drvdata *ndd)
u32 nslot;
u8 sig[NSINDEX_SIG_LEN];
u64 sum_save, sum, size;
+ unsigned int version, labelsize;
memcpy(sig, nsindex[i]->sig, NSINDEX_SIG_LEN);
if (memcmp(sig, NSINDEX_SIGNATURE, NSINDEX_SIG_LEN) != 0) {
@@ -111,6 +117,21 @@ int nd_label_validate(struct nvdimm_drvdata *ndd)
__func__, i);
continue;
}
+
+ /* label sizes larger than 128 arrived with v1.2 */
+ version = __le16_to_cpu(nsindex[i]->major) * 100
+ + __le16_to_cpu(nsindex[i]->minor);
+ if (version >= 102)
+ labelsize = 1 << (7 + nsindex[i]->labelsize);
+ else
+ labelsize = 128;
+
+ if (labelsize != sizeof_namespace_label(ndd)) {
+ dev_dbg(dev, "%s: nsindex%d labelsize %d invalid\n",
+ __func__, i, nsindex[i]->labelsize);
+ continue;
+ }
+
sum_save = __le64_to_cpu(nsindex[i]->checksum);
nsindex[i]->checksum = __cpu_to_le64(0);
sum = nd_fletcher64(nsindex[i], sizeof_namespace_index(ndd), 1);
@@ -153,7 +174,7 @@ int nd_label_validate(struct nvdimm_drvdata *ndd)
}
nslot = __le32_to_cpu(nsindex[i]->nslot);
- if (nslot * sizeof(struct nd_namespace_label)
+ if (nslot * sizeof_namespace_label(ndd)
+ 2 * sizeof_namespace_index(ndd)
> ndd->nsarea.config_size) {
dev_dbg(dev, "%s: nsindex%d nslot: %u invalid,
config_size: %#x\n",
@@ -189,6 +210,28 @@ int nd_label_validate(struct nvdimm_drvdata *ndd)
return -1;
}
+int nd_label_validate(struct nvdimm_drvdata *ndd)
+{
+ /*
+* In order to probe for and validate namespace index blocks we
+* need to know the size of the labels, and we can't trust the
+* size of the labels until we validate the index blocks.
+* Resolve this dependency loop by probing for known label
+* sizes.
+*/
+ int label_size[] = { 256, 128 };
+ int i, rc;
+
+ for (i = 0; i < ARRAY_SIZE(label_size); i++) {
+ ndd->nslabel_size = label_size[i];
+ rc = __nd_label_validate(ndd);
+ if (
[PATCH 6/9] libnvdimm, label: update 'nlabel' and 'position' handling for local namespaces
The v1.2 namespace label specification requires 'nlabel' and 'position'
to be valid for the first ("lowest dpa") label in the set. It also
requires all non-first labels to set those fields to 0xff.
Linux does not much care if these values are correct, because we can
just trust the count of labels with the matching uuid like the v1.1
case. However, we set them correctly in case other environments care.
Signed-off-by: Dan Williams
---
drivers/nvdimm/label.c | 33 +++--
1 file changed, 27 insertions(+), 6 deletions(-)
diff --git a/drivers/nvdimm/label.c b/drivers/nvdimm/label.c
index ba0582fb0e21..d7f9916c6ed5 100644
--- a/drivers/nvdimm/label.c
+++ b/drivers/nvdimm/label.c
@@ -696,6 +696,7 @@ static int __blk_label_update(struct nd_region *nd_region,
struct resource *res, **old_res_list;
struct nd_label_id label_id;
u8 uuid[NSLABEL_UUID_LEN];
+ int min_dpa_idx = 0;
LIST_HEAD(list);
u32 nslot, slot;
@@ -767,6 +768,18 @@ static int __blk_label_update(struct nd_region *nd_region,
}
}
+ /*
+* Find the resource associated with the first label in the set
+* per the v1.2 namespace specification.
+*/
+ for (i = 0; i < nsblk->num_resources; i++) {
+ struct resource *min = nsblk->res[min_dpa_idx];
+
+ res = nsblk->res[i];
+ if (res->start < min->start)
+ min_dpa_idx = i;
+ }
+
for (i = 0; i < nsblk->num_resources; i++) {
size_t offset;
@@ -785,18 +798,26 @@ static int __blk_label_update(struct nd_region *nd_region,
memcpy(nd_label->name, nsblk->alt_name,
NSLABEL_NAME_LEN);
nd_label->flags = __cpu_to_le32(NSLABEL_FLAG_LOCAL);
- nd_label->nlabel = __cpu_to_le16(0); /* N/A */
- nd_label->position = __cpu_to_le16(0); /* N/A */
/*
* Use the presence of the type_guid as a flag to
-* determine isetcookie usage for blk-aperture
-* namespaces.
+* determine isetcookie usage and nlabel + position
+* policy for blk-aperture namespaces.
*/
- if (namespace_label_has(ndd, type_guid))
+ if (namespace_label_has(ndd, type_guid)) {
+ if (i == min_dpa_idx) {
+ nd_label->nlabel =
__cpu_to_le16(nsblk->num_resources);
+ nd_label->position = __cpu_to_le16(0);
+ } else {
+ nd_label->nlabel = __cpu_to_le16(0x);
+ nd_label->position = __cpu_to_le16(0x);
+ }
nd_label->isetcookie = __cpu_to_le64(nd_set->cookie2);
- else
+ } else {
+ nd_label->nlabel = __cpu_to_le16(0); /* N/A */
+ nd_label->position = __cpu_to_le16(0); /* N/A */
nd_label->isetcookie = __cpu_to_le64(0); /* N/A */
+ }
nd_label->dpa = __cpu_to_le64(res->start);
nd_label->rawsize = __cpu_to_le64(resource_size(res));
[PATCH 3/9] libnvdimm, label: honor the lba size specified in v1.2 labels
Previously we only honored the lba size for blk-aperture mode
namespaces. For pmem namespaces the lba size was just assumed to be 512.
With the new v1.2 label definition and compatibility with other
operating environments, the ->lbasize property is now respected for pmem
namespaces.
Cc: Ross Zwisler
Signed-off-by: Dan Williams
---
drivers/nvdimm/namespace_devs.c | 65 ---
drivers/nvdimm/nd.h |1 +
drivers/nvdimm/pmem.c |1 +
include/linux/nd.h |2 +
4 files changed, 57 insertions(+), 12 deletions(-)
diff --git a/drivers/nvdimm/namespace_devs.c b/drivers/nvdimm/namespace_devs.c
index 51f304fe8a52..e034b003a5e2 100644
--- a/drivers/nvdimm/namespace_devs.c
+++ b/drivers/nvdimm/namespace_devs.c
@@ -163,6 +163,29 @@ bool pmem_should_map_pages(struct device *dev)
}
EXPORT_SYMBOL(pmem_should_map_pages);
+unsigned int pmem_sector_size(struct nd_namespace_common *ndns)
+{
+ if (is_namespace_pmem(&ndns->dev)) {
+ struct nd_namespace_pmem *nspm;
+
+ nspm = to_nd_namespace_pmem(&ndns->dev);
+ if (nspm->lbasize == 0 || nspm->lbasize == 512)
+ /* default */;
+ else if (nspm->lbasize == 4096)
+ return 4096;
+ else
+ dev_WARN(&ndns->dev, "unsupported sector size: %ld\n",
+ nspm->lbasize);
+ }
+
+ /*
+* There is no namespace label (is_namespace_io()), or the label
+* indicates the default sector size.
+*/
+ return 512;
+}
+EXPORT_SYMBOL(pmem_sector_size);
+
const char *nvdimm_namespace_disk_name(struct nd_namespace_common *ndns,
char *name)
{
@@ -1283,28 +1306,49 @@ static ssize_t resource_show(struct device *dev,
}
static DEVICE_ATTR_RO(resource);
-static const unsigned long ns_lbasize_supported[] = { 512, 520, 528,
+static const unsigned long blk_lbasize_supported[] = { 512, 520, 528,
4096, 4104, 4160, 4224, 0 };
+static const unsigned long pmem_lbasize_supported[] = { 512, 4096, 0 };
+
static ssize_t sector_size_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
- struct nd_namespace_blk *nsblk = to_nd_namespace_blk(dev);
+ if (is_namespace_blk(dev)) {
+ struct nd_namespace_blk *nsblk = to_nd_namespace_blk(dev);
- if (!is_namespace_blk(dev))
- return -ENXIO;
+ return nd_sector_size_show(nsblk->lbasize,
+ blk_lbasize_supported, buf);
+ }
- return nd_sector_size_show(nsblk->lbasize, ns_lbasize_supported, buf);
+ if (is_namespace_pmem(dev)) {
+ struct nd_namespace_pmem *nspm = to_nd_namespace_pmem(dev);
+
+ return nd_sector_size_show(nspm->lbasize,
+ pmem_lbasize_supported, buf);
+ }
+ return -ENXIO;
}
static ssize_t sector_size_store(struct device *dev,
struct device_attribute *attr, const char *buf, size_t len)
{
- struct nd_namespace_blk *nsblk = to_nd_namespace_blk(dev);
struct nd_region *nd_region = to_nd_region(dev->parent);
+ const unsigned long *supported;
+ unsigned long *lbasize;
ssize_t rc = 0;
- if (!is_namespace_blk(dev))
+ if (is_namespace_blk(dev)) {
+ struct nd_namespace_blk *nsblk = to_nd_namespace_blk(dev);
+
+ lbasize = &nsblk->lbasize;
+ supported = blk_lbasize_supported;
+ } else if (is_namespace_pmem(dev)) {
+ struct nd_namespace_pmem *nspm = to_nd_namespace_pmem(dev);
+
+ lbasize = &nspm->lbasize;
+ supported = pmem_lbasize_supported;
+ } else
return -ENXIO;
device_lock(dev);
@@ -1312,8 +1356,7 @@ static ssize_t sector_size_store(struct device *dev,
if (to_ndns(dev)->claim)
rc = -EBUSY;
if (rc >= 0)
- rc = nd_sector_size_store(dev, buf, &nsblk->lbasize,
- ns_lbasize_supported);
+ rc = nd_sector_size_store(dev, buf, lbasize, supported);
if (rc >= 0)
rc = nd_namespace_label_update(nd_region, dev);
dev_dbg(dev, "%s: result: %zd %s: %s%s", __func__,
@@ -1458,9 +1501,6 @@ static umode_t namespace_visible(struct kobject *kobj,
if (a == &dev_attr_size.attr)
return 0644;
- if (is_namespace_pmem(dev) && a == &dev_attr_sector_size.attr)
- return 0;
-
return a->mode;
}
@@ -1795,6 +1835,7 @@ struct device *create_namespace_pmem(struct nd_region
*nd_region,
NSLABEL_NAME_LEN, GFP_KERNEL);
nspm->uuid = kmemdup((void __force *) label0->uuid,
NSLABEL_UUID_LEN, GFP_KERNEL);
[PATCH 5/9] libnvdimm, label: populate 'isetcookie' for blk-aperture namespaces
Starting with the v1.2 definition of namespace labels, the isetcookie
field is populated and validated for blk-aperture namespaces. This adds
some safety against inadvertent copying of namespace labels from one
DIMM-device to another.
Signed-off-by: Dan Williams
---
drivers/acpi/nfit/core.c|7 +--
drivers/nvdimm/label.c | 12 +++-
drivers/nvdimm/namespace_devs.c | 20 ++--
3 files changed, 26 insertions(+), 13 deletions(-)
diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c
index 83ee3c829411..47d2dbb45695 100644
--- a/drivers/acpi/nfit/core.c
+++ b/drivers/acpi/nfit/core.c
@@ -1736,12 +1736,12 @@ static int acpi_nfit_init_interleave_set(struct
acpi_nfit_desc *acpi_desc,
struct nd_region_desc *ndr_desc,
struct acpi_nfit_system_address *spa)
{
- int i, spa_type = nfit_spa_type(spa);
struct device *dev = acpi_desc->dev;
struct nd_interleave_set *nd_set;
u16 nr = ndr_desc->num_mappings;
struct nfit_set_info2 *info2;
struct nfit_set_info *info;
+ int i;
nd_set = devm_kzalloc(dev, sizeof(*nd_set), GFP_KERNEL);
if (!nd_set)
@@ -1749,11 +1749,6 @@ static int acpi_nfit_init_interleave_set(struct
acpi_nfit_desc *acpi_desc,
ndr_desc->nd_set = nd_set;
guid_copy(&nd_set->type_guid, (guid_t *) spa->range_guid);
- if (spa_type == NFIT_SPA_PM || spa_type == NFIT_SPA_VOLATILE)
- /* pass */;
- else
- return 0;
-
info = devm_kzalloc(dev, sizeof_nfit_set_info(nr), GFP_KERNEL);
if (!info)
return -ENOMEM;
diff --git a/drivers/nvdimm/label.c b/drivers/nvdimm/label.c
index d8b87d3a0ebe..ba0582fb0e21 100644
--- a/drivers/nvdimm/label.c
+++ b/drivers/nvdimm/label.c
@@ -787,7 +787,17 @@ static int __blk_label_update(struct nd_region *nd_region,
nd_label->flags = __cpu_to_le32(NSLABEL_FLAG_LOCAL);
nd_label->nlabel = __cpu_to_le16(0); /* N/A */
nd_label->position = __cpu_to_le16(0); /* N/A */
- nd_label->isetcookie = __cpu_to_le64(0); /* N/A */
+
+ /*
+* Use the presence of the type_guid as a flag to
+* determine isetcookie usage for blk-aperture
+* namespaces.
+*/
+ if (namespace_label_has(ndd, type_guid))
+ nd_label->isetcookie = __cpu_to_le64(nd_set->cookie2);
+ else
+ nd_label->isetcookie = __cpu_to_le64(0); /* N/A */
+
nd_label->dpa = __cpu_to_le64(res->start);
nd_label->rawsize = __cpu_to_le64(resource_size(res));
nd_label->lbasize = __cpu_to_le64(nsblk->lbasize);
diff --git a/drivers/nvdimm/namespace_devs.c b/drivers/nvdimm/namespace_devs.c
index e101aec186c7..7aba9a569c8e 100644
--- a/drivers/nvdimm/namespace_devs.c
+++ b/drivers/nvdimm/namespace_devs.c
@@ -2065,12 +2065,20 @@ struct device *create_namespace_blk(struct nd_region
*nd_region,
struct device *dev = NULL;
struct resource *res;
- if (namespace_label_has(ndd, type_guid)
- && !guid_equal(&nd_set->type_guid,
- &nd_label->type_guid)) {
- dev_dbg(ndd->dev, "expect type_guid %pUb got %pUb\n",
- nd_set->type_guid.b, nd_label->type_guid.b);
- return ERR_PTR(-EAGAIN);
+ if (namespace_label_has(ndd, type_guid)) {
+ if (!guid_equal(&nd_set->type_guid, &nd_label->type_guid)) {
+ dev_dbg(ndd->dev, "expect type_guid %pUb got %pUb\n",
+ nd_set->type_guid.b,
+ nd_label->type_guid.b);
+ return ERR_PTR(-EAGAIN);
+ }
+
+ if (nd_label->isetcookie != __cpu_to_le64(nd_set->cookie2)) {
+ dev_dbg(ndd->dev, "expect cookie %#llx got %#llx\n",
+ nd_set->cookie2,
+ __le64_to_cpu(nd_label->isetcookie));
+ return ERR_PTR(-EAGAIN);
+ }
}
nsblk = kzalloc(sizeof(*nsblk), GFP_KERNEL);
Re: [PATCH v10 1/6] i2c: designware: Cleaning and comment style fixes.
On 2017-06-08 19:36, Luis Oliveira wrote: > complicated to review. The work here won't bring any additional work to > backported fixes because is just style and reordering. I challenge that. If there is an old bug that existed before this patch that is fixed in the future after this patch has been applied, it might very well be hard_er_ to backport that fix to a point before this patch has been applied. So, what do you mean? > @@ -984,12 +984,12 @@ int i2c_dw_probe(struct dw_i2c_dev *dev) > } > > i2c_dw_disable_int(dev); > - r = devm_request_irq(dev->dev, dev->irq, i2c_dw_isr, irq_flags, > + ret = devm_request_irq(dev->dev, dev->irq, i2c_dw_isr, irq_flags, >dev_name(dev->dev), dev); Two extra spaces needed to align with the opening bracket. Cheers, peda
Re: [PATCH linux-next v3 1/1] spi: imx: dynamic burst length adjust for PIO mode
On 06/01/2017 10:38 PM, Sascha Hauer wrote: On Thu, Jun 01, 2017 at 04:58:47AM -0700, Jiada Wang wrote: Hi Sascha On 05/29/2017 02:50 AM, Sascha Hauer wrote: Hi, On Thu, May 25, 2017 at 10:02:42PM -0700, jiada_w...@mentor.com wrote: From: Jiada Wang previously burst length (BURST_LENGTH) is always set to equal to bits_per_word, causes a 10us gap between each word in transfer, which significantly affects performance. This patch uses 32 bits transfer to simulate lower bits transfer, and adjusts burst length runtimely to use biggeest burst length as possible to reduce the gaps in transfer for PIO mode. First let me say that I'm not really looking forward to have this patch in the driver. It adds quite some code to already hairy code pathes in the imx-spi driver and I saw you have the same patch for DMA mode aswell. The driver has different function hooks for the different controllers. This patch breaks that. In some places it assumes that dynamic burst is only possible on i.MX51 type controllers and also that in case dynamic burst is enabled it must be an i.MX51 type controller. We should really see how this patch can be better integrated into the driver, or, how the driver can be changed to better support the dynamic burst usecase. Yes, I can understand your concern, as this patch brings in a bunch of change, and changes the behaviour of data transfer. how about introduce a new DTS property like "fsl,spi-dynamic-burst", and only enables dynamic burst when this property is added. This will only reduce the testing coverage of the feature, not a good option. As an improvement, I am thinking about the following 1. introduce a 'fsl,spi-dynamic-burst' property in dts as mentioned before 2. remove all change in specific functions hooks, for example "mx51_ecspi_config" 3. introduce spi_imx_pio_dynamic_burst_transfer(), which will handle actual swapped data transfer, and burst length adjustment. What do you think ? Sascha
Re: [PATCH v1 00/25] lib, rtc: Print rtc_time via %pt[dt][rv]
On Thu, 2017-06-08 at 18:02 +0300, Andy Shevchenko wrote: > On Thu, Jun 8, 2017 at 5:52 PM, Joe Perches wrote: > > On Thu, 2017-06-08 at 16:47 +0300, Andy Shevchenko wrote: > > > Recently I have noticed too many users of struct rtc_time that printing > > > its content field by field. > > > > > > In this series I introduce %pt[dt][rv] specifier to make life a bit > > > easier. [] > > > Most of the users currently are RTC drivers, thus the patch series is > > > assumed to go via RTC tree. > > > > What I wonder about this series is how much > > larger it makes a typical kernel and how > > often multiple rtc clocks are built for a > > single kernel? > > We may hide it under CONFIG_RTC_??? if we want to reduce kernel for > non RTC cases. Depends whether it is for rtc_time only > > What is the size impact on an embedded kernel > > that uses a single rtc driver? > > I would You would what?
[PATCH] staging: ks7010: use little-endian types
This patch fixes a number of sparse warnings of the form:
drivers/staging/ks7010/ks_hostif.c:2187:29:
warning: incorrect type in assignment (different base types)
generated when storing little-endian data in variables
that do not have a specified endianness.
Signed-off-by: Perry Hooker
---
drivers/staging/ks7010/ks_hostif.c | 24 +---
1 file changed, 13 insertions(+), 11 deletions(-)
diff --git a/drivers/staging/ks7010/ks_hostif.c
b/drivers/staging/ks7010/ks_hostif.c
index 697347b..db01a48 100644
--- a/drivers/staging/ks7010/ks_hostif.c
+++ b/drivers/staging/ks7010/ks_hostif.c
@@ -1821,7 +1821,7 @@ void hostif_receive(struct ks_wlan_private *priv,
unsigned char *p,
static
void hostif_sme_set_wep(struct ks_wlan_private *priv, int type)
{
- u32 val;
+ __le32 val;
switch (type) {
case SME_WEP_INDEX_REQUEST:
@@ -1870,13 +1870,13 @@ void hostif_sme_set_wep(struct ks_wlan_private *priv,
int type)
}
struct wpa_suite_t {
- unsigned short size;
+ __le16 size;
unsigned char suite[4][CIPHER_ID_LEN];
} __packed;
struct rsn_mode_t {
- u32 rsn_mode;
- u16 rsn_capability;
+ __le32 rsn_mode;
+ __le16 rsn_capability;
} __packed;
static
@@ -1884,7 +1884,7 @@ void hostif_sme_set_rsn(struct ks_wlan_private *priv, int
type)
{
struct wpa_suite_t wpa_suite;
struct rsn_mode_t rsn_mode;
- u32 val;
+ __le32 val;
memset(&wpa_suite, 0, sizeof(wpa_suite));
@@ -1936,7 +1936,8 @@ void hostif_sme_set_rsn(struct ks_wlan_private *priv, int
type)
hostif_mib_set_request(priv, DOT11_RSN_CONFIG_UNICAST_CIPHER,
sizeof(wpa_suite.size) +
- CIPHER_ID_LEN * wpa_suite.size,
+ CIPHER_ID_LEN *
+ le16_to_cpu(wpa_suite.size),
MIB_VALUE_TYPE_OSTRING, &wpa_suite);
break;
case SME_RSN_MCAST_REQUEST:
@@ -2028,7 +2029,8 @@ void hostif_sme_set_rsn(struct ks_wlan_private *priv, int
type)
hostif_mib_set_request(priv, DOT11_RSN_CONFIG_AUTH_SUITE,
sizeof(wpa_suite.size) +
- KEY_MGMT_ID_LEN * wpa_suite.size,
+ KEY_MGMT_ID_LEN *
+ le16_to_cpu(wpa_suite.size),
MIB_VALUE_TYPE_OSTRING, &wpa_suite);
break;
case SME_RSN_ENABLED_REQUEST:
@@ -2165,7 +2167,7 @@ void hostif_sme_multicast_set(struct ks_wlan_private
*priv)
int mc_count;
struct netdev_hw_addr *ha;
char set_address[NIC_MAX_MCAST_LIST * ETH_ALEN];
- unsigned long filter_type;
+ __le32 filter_type;
int i = 0;
DPRINTK(3, "\n");
@@ -2276,7 +2278,7 @@ void hostif_sme_sleep_set(struct ks_wlan_private *priv)
static
void hostif_sme_set_key(struct ks_wlan_private *priv, int type)
{
- u32 val;
+ __le32 val;
switch (type) {
case SME_SET_FLAG:
@@ -2335,7 +2337,7 @@ static
void hostif_sme_set_pmksa(struct ks_wlan_private *priv)
{
struct pmk_cache_t {
- u16 size;
+ __le16 size;
struct {
u8 bssid[ETH_ALEN];
u8 pmkid[IW_PMKID_LEN];
@@ -2366,7 +2368,7 @@ void hostif_sme_set_pmksa(struct ks_wlan_private *priv)
static
void hostif_sme_execute(struct ks_wlan_private *priv, int event)
{
- u32 val;
+ __le32 val;
DPRINTK(3, "event=%d\n", event);
switch (event) {
--
2.4.11
[PATCH 0/3] Add support for the s6e63j0x03 panel on Rinato board
Hi all, The purpose of this patch is add support for s6e63j0x03 AMOLED panel on the rinato board(Samsung Galaxy Gear 2). The first and second patches are Add the binding document and panel driver. The third patch is remove the unnecessary properties in the rinato dts. Best regards, Hoegeun Hoegeun Kwon (3): dt-bindings: Add support for samsung s6e63j0x03 panel binding drm/panel: Add support for s6e63j0x03 panel driver ARM: dts: exynos: Remove the display-timing and delay from rinato dts .../bindings/display/panel/samsung,s6e63j0x03.txt | 24 + arch/arm/boot/dts/exynos3250-rinato.dts| 22 - drivers/gpu/drm/panel/Kconfig | 7 + drivers/gpu/drm/panel/Makefile | 1 + drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c | 491 + 5 files changed, 523 insertions(+), 22 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/panel/samsung,s6e63j0x03.txt create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c -- 1.9.1
[PATCH 3/3] ARM: dts: exynos: Remove the display-timing and delay from rinato dts
The display-timing and delay are included in the panel driver. So it
should be removed in dts.
Signed-off-by: Hoegeun Kwon
---
arch/arm/boot/dts/exynos3250-rinato.dts | 22 --
1 file changed, 22 deletions(-)
diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts
b/arch/arm/boot/dts/exynos3250-rinato.dts
index 82e676a..3d19b7c 100644
--- a/arch/arm/boot/dts/exynos3250-rinato.dts
+++ b/arch/arm/boot/dts/exynos3250-rinato.dts
@@ -227,28 +227,6 @@
vci-supply = <&ldo20_reg>;
reset-gpios = <&gpe0 1 GPIO_ACTIVE_HIGH>;
te-gpios = <&gpx0 6 GPIO_ACTIVE_HIGH>;
- power-on-delay= <30>;
- power-off-delay= <120>;
- reset-delay = <5>;
- init-delay = <100>;
- flip-horizontal;
- flip-vertical;
- panel-width-mm = <29>;
- panel-height-mm = <29>;
-
- display-timings {
- timing-0 {
- clock-frequency = <460>;
- hactive = <320>;
- vactive = <320>;
- hfront-porch = <1>;
- hback-porch = <1>;
- hsync-len = <1>;
- vfront-porch = <150>;
- vback-porch = <1>;
- vsync-len = <2>;
- };
- };
};
};
--
1.9.1
[PATCH 1/3] dt-bindings: Add support for samsung s6e63j0x03 panel binding
The Samsung s6e63j0x03 is a 1.63" 320x320 AMOLED panel connected using
MIPI-DSI interfaces.
Signed-off-by: Hoegeun Kwon
---
.../bindings/display/panel/samsung,s6e63j0x03.txt | 24 ++
1 file changed, 24 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/samsung,s6e63j0x03.txt
diff --git
a/Documentation/devicetree/bindings/display/panel/samsung,s6e63j0x03.txt
b/Documentation/devicetree/bindings/display/panel/samsung,s6e63j0x03.txt
new file mode 100644
index 000..34b6e2a
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/samsung,s6e63j0x03.txt
@@ -0,0 +1,24 @@
+Samsung S6E63J0X03 1.63" 320x320 AMOLED panel
+
+Required properties:
+ - compatible: "samsung,s6e63j0x03"
+ - reg: the virtual channel number of a DSI peripheral
+ - vdd3-supply: I/O voltage supply
+ - vci-supply: voltage supply for analog circuits
+ - reset-gpios: a GPIO spec for the reset pin (active high)
+ - te-gpios: a GPIO spec for the tearing effect synchronization signal
+gpio pin (active high)
+
+Example:
+&dsi {
+ ...
+
+ panel@0 {
+ compatible = "samsung,s6e63j0x03";
+ reg = <0>;
+ vdd3-supply = <&ldo16_reg>;
+ vci-supply = <&ldo20_reg>;
+ reset-gpios = <&gpe0 1 GPIO_ACTIVE_HIGH>;
+ te-gpios = <&gpx0 6 GPIO_ACTIVE_HIGH>;
+ };
+};
--
1.9.1
[PATCH 2/3] drm/panel: Add support for s6e63j0x03 panel driver
This patch adds MIPI-DSI based S6E63J0X03 AMOLED LCD panel driver
which uses mipi_dsi bus to communicate with panel. The panel has
320×320 resolution in 1.63" physical panel. This panel is used in
Samsung Galaxy Gear 2.
Signed-off-by: Inki Dae
Signed-off-by: Hyungwon Hwang
Signed-off-by: Hoegeun Kwon
---
drivers/gpu/drm/panel/Kconfig| 7 +
drivers/gpu/drm/panel/Makefile | 1 +
drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c | 491 +++
3 files changed, 499 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 3e29a99..e47e56d 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -68,6 +68,13 @@ config DRM_PANEL_SAMSUNG_S6E3HA2
depends on DRM_MIPI_DSI
select VIDEOMODE_HELPERS
+config DRM_PANEL_SAMSUNG_S6E63J0X03
+ tristate "Samsung S6E63J0X03 DSI video mode panel"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
+ select VIDEOMODE_HELPERS
+
config DRM_PANEL_SAMSUNG_S6E8AA0
tristate "Samsung S6E8AA0 DSI video mode panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 292b3c7..f028269 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -5,6 +5,7 @@ obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
obj-$(CONFIG_DRM_PANEL_PANASONIC_VVX10F034N00) +=
panel-panasonic-vvx10f034n00.o
obj-$(CONFIG_DRM_PANEL_SAMSUNG_LD9040) += panel-samsung-ld9040.o
obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E3HA2) += panel-samsung-s6e3ha2.o
+obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E63J0X03) += panel-samsung-s6e63j0x03.o
obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0) += panel-samsung-s6e8aa0.o
obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c
b/drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c
new file mode 100644
index 000..bf70a20
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c
@@ -0,0 +1,491 @@
+/*
+ * MIPI-DSI based S6E63J0X03 AMOLED lcd 1.63 inch panel driver.
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd
+ *
+ * Inki Dae,
+ * Hoegeun Kwon,
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define MCS_LEVEL2_KEY 0xf0
+#define MCS_MTP_KEY0xf1
+#define MCS_MTP_SET3 0xd4
+
+#define MIN_BRIGHTNESS 0
+#define MAX_BRIGHTNESS 100
+#define DEFAULT_BRIGHTNESS 80
+
+#define NUM_GAMMA_STEPS9
+#define GAMMA_CMD_CNT 28
+
+struct s6e63j0x03 {
+ struct device *dev;
+ struct drm_panel panel;
+ struct backlight_device *bl_dev;
+
+ struct regulator_bulk_data supplies[2];
+ struct gpio_desc *reset_gpio;
+};
+
+static const unsigned char gamma_tbl[NUM_GAMMA_STEPS][GAMMA_CMD_CNT] = {
+ { /* Gamma 10 */
+ MCS_MTP_SET3,
+ 0x00, 0x00, 0x00, 0x7f, 0x7f, 0x7f, 0x52, 0x6b, 0x6f, 0x26,
+ 0x28, 0x2d, 0x28, 0x26, 0x27, 0x33, 0x34, 0x32, 0x36, 0x36,
+ 0x35, 0x00, 0xab, 0x00, 0xae, 0x00, 0xbf
+ },
+ { /* gamma 30 */
+ MCS_MTP_SET3,
+ 0x00, 0x00, 0x00, 0x70, 0x7f, 0x7f, 0x4e, 0x64, 0x69, 0x26,
+ 0x27, 0x2a, 0x28, 0x29, 0x27, 0x31, 0x32, 0x31, 0x35, 0x34,
+ 0x35, 0x00, 0xc4, 0x00, 0xca, 0x00, 0xdc
+ },
+ { /* gamma 60 */
+ MCS_MTP_SET3,
+ 0x00, 0x00, 0x00, 0x65, 0x7b, 0x7d, 0x5f, 0x67, 0x68, 0x2a,
+ 0x28, 0x29, 0x28, 0x2a, 0x27, 0x31, 0x2f, 0x30, 0x34, 0x33,
+ 0x34, 0x00, 0xd9, 0x00, 0xe4, 0x00, 0xf5
+ },
+ { /* gamma 90 */
+ MCS_MTP_SET3,
+ 0x00, 0x00, 0x00, 0x4d, 0x6f, 0x71, 0x67, 0x6a, 0x6c, 0x29,
+ 0x28, 0x28, 0x28, 0x29, 0x27, 0x30, 0x2e, 0x30, 0x32, 0x31,
+ 0x31, 0x00, 0xea, 0x00, 0xf6, 0x01, 0x09
+ },
+ { /* gamma 120 */
+ MCS_MTP_SET3,
+ 0x00, 0x00, 0x00, 0x3d, 0x66, 0x68, 0x69, 0x69, 0x69, 0x28,
+ 0x28, 0x27, 0x28, 0x28, 0x27, 0x30, 0x2e, 0x2f, 0x31, 0x31,
+ 0x30, 0x00, 0xf9, 0x01, 0x05, 0x01, 0x1b
+ },
+ { /* gamma 150 */
+ MCS_MTP_SET3,
+ 0x00, 0x00, 0x00, 0x31, 0x51, 0x53, 0x66, 0x66, 0x67, 0x28,
+ 0x29, 0x27, 0x28, 0x27, 0x27, 0x2e, 0x2d, 0x2e, 0x31, 0x31,
+ 0x30, 0x01, 0x04, 0x01, 0x11, 0x01, 0x29
+ },
+ { /* gamma 200 */
[PATCH] netfilter: ctnetlink: move CTA_TIMEOUT case to outside
When cda[CTA_TIMEOUT] is zero, ctnetlink_new_conntrack will
free allocated ct and return, so move it to outside to optimize
this situation.
Signed-off-by: Haishuang Yan
---
net/netfilter/nf_conntrack_netlink.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/net/netfilter/nf_conntrack_netlink.c
b/net/netfilter/nf_conntrack_netlink.c
index a8be9b7..d1e6b1c 100644
--- a/net/netfilter/nf_conntrack_netlink.c
+++ b/net/netfilter/nf_conntrack_netlink.c
@@ -1768,9 +1768,6 @@ static int change_seq_adj(struct nf_ct_seqadj *seq,
if (IS_ERR(ct))
return ERR_PTR(-ENOMEM);
- if (!cda[CTA_TIMEOUT])
- goto err1;
-
ct->timeout = nfct_time_stamp + ntohl(nla_get_be32(cda[CTA_TIMEOUT])) *
HZ;
rcu_read_lock();
@@ -1944,7 +1941,7 @@ static int ctnetlink_new_conntrack(struct net *net,
struct sock *ctnl,
if (nlh->nlmsg_flags & NLM_F_CREATE) {
enum ip_conntrack_events events;
- if (!cda[CTA_TUPLE_ORIG] || !cda[CTA_TUPLE_REPLY])
+ if (!cda[CTA_TUPLE_ORIG] || !cda[CTA_TUPLE_REPLY] ||
!cda[CTA_TIMEOUT])
return -EINVAL;
if (otuple.dst.protonum != rtuple.dst.protonum)
return -EINVAL;
--
1.8.3.1
Re: [PATCH 1/3] media: ngene: Replace semaphore cmd_mutex with mutex
On 8 June 2017 at 20:40, Arnd Bergmann wrote:
> On Thu, Jun 8, 2017 at 12:04 PM, Binoy Jayan wrote:
>> The semaphore 'cmd_mutex' is used as a simple mutex, so
>> it should be written as one. Semaphores are going away in the future.
>>
>> Signed-off-by: Binoy Jayan
>> ---
>
>> @@ -1283,7 +1283,7 @@ static int ngene_load_firm(struct ngene *dev)
>>
>> static void ngene_stop(struct ngene *dev)
>> {
>> - down(&dev->cmd_mutex);
>> + mutex_lock(&dev->cmd_mutex);
>> i2c_del_adapter(&(dev->channel[0].i2c_adapter));
>> i2c_del_adapter(&(dev->channel[1].i2c_adapter));
>> ngwritel(0, NGENE_INT_ENABLE);
>
> Are you sure about this one? There is only one mutex_lock() and
> then the structure gets freed without a corresponding mutex_unlock().
>
> I suspect this violates some rules of mutexes, either when compile
> testing with "make C=1", or when running with lockdep enabled.
>
> Can we actually have a concurrently held mutex at the time we
> get here? If not, using mutex_destroy() in place of the down()
> may be the right answer.
I noticed the missing 'up' here, but may be semaphores do not have
to adhere to that rule? Thank you for pointing out that. I'll check the
concurrency part. By the way why do we need mutex_destoy?
To debug an aberrate condition?
Thanks,
Binoy
Re: [PATCH v2 2/2] ARM: sun8i: a83t: add dwmac-sun8i ethernet driver
On Thu, Jun 8, 2017 at 8:48 PM, Maxime Ripard
wrote:
> On Thu, Jun 08, 2017 at 10:42:22AM +0200, Corentin Labbe wrote:
>> On Thu, Jun 08, 2017 at 10:34:28AM +0200, Maxime Ripard wrote:
>> > On Wed, Jun 07, 2017 at 07:33:45PM +0200, Corentin Labbe wrote:
>> > > The dwmac-sun8i is an ethernet MAC hardware that support 10/100/1000
>> > > speed.
>> > > This patch enable the dwmac-sun8i on the Allwinner a83t SoC Device-tree.
>> > >
>> > > Signed-off-by: Corentin Labbe
>> > > Reviewed-by: Chen-Yu Tsai
>> > > ---
>> > > arch/arm/boot/dts/sun8i-a83t.dtsi | 28
>> > > 1 file changed, 28 insertions(+)
>> > >
>> > > diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi
>> > > b/arch/arm/boot/dts/sun8i-a83t.dtsi
>> > > index 01a83406f9ae..7d719b4aeaa9 100644
>> > > --- a/arch/arm/boot/dts/sun8i-a83t.dtsi
>> > > +++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
>> > > @@ -200,6 +200,14 @@
>> > > #interrupt-cells = <3>;
>> > > #gpio-cells = <3>;
>> > >
>> > > + emac_rgmii_pins: emac-rgmii-pins {
>> > > + pins = "PD2", "PD3", "PD4", "PD5", "PD6",
>> > > "PD7",
>> > > +"PD11", "PD12", "PD13", "PD14", "PD18",
>> > > +"PD19", "PD21", "PD22", "PD23";
>> > > + function = "gmac";
>> > > + drive-strength = <40>;
>> > > + };
>> > > +
>> >
>> > This is not used anywhere.
>> >
>> But will be used by bpim3 board
>
> Then will add it when we'll add support for that board, until then,
> it's dead code.
I'll include this in my A83T work branch and resend it when I get around to it.
Thanks
ChenYu
[PATCH v2] acpi: handle the acpi hotplug schedule error
Kernel should decrements the reference count of acpi device
when the scheduling of acpi hotplug work is failed, and
evaluates _OST to notify BIOS the failure.
v2:
To simplify the code. (Andy Shevchenko)
Cc: "Rafael J. Wysocki"
Cc: Len Brown
Cc: Andy Shevchenko
Signed-off-by: "Lee, Chun-Yi"
---
drivers/acpi/bus.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index 34fbe02..91adb71 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -427,12 +427,17 @@ static void acpi_bus_notify(acpi_handle handle, u32 type,
void *data)
(driver->flags & ACPI_DRIVER_ALL_NOTIFY_EVENTS))
driver->ops.notify(adev, type);
- if (hotplug_event && ACPI_SUCCESS(acpi_hotplug_schedule(adev, type)))
- return;
+ if (hotplug_event) {
+ if (ACPI_SUCCESS(acpi_hotplug_schedule(adev, type)))
+ return;
+ goto err_put_device;
+ }
acpi_bus_put_acpi_device(adev);
return;
+ err_put_device:
+ acpi_bus_put_acpi_device(adev);
err:
acpi_evaluate_ost(handle, type, ost_code, NULL);
}
--
2.10.2
Re: [PATCH 0/2] perf stat: fix segfault when closing events
ping?
On Tue, May 23, 2017 at 8:44 PM, Ganapatrao Kulkarni
wrote:
> On Tue, May 23, 2017 at 3:34 PM, Mark Rutland wrote:
>> Hi,
>>
>> Does anyone have any comments on these?
>>
>> I'm happy to rebase/resend if necessary.
>>
>> I'd very much like to see this fixed.
>
> arm64 platforms have dependency on this patch set to use latest perf tool.
> Earliest merge/review is much appreciated!!
>
>>
>> Thanks,
>> Mark.
>>
>> On Fri, Apr 28, 2017 at 12:47:08PM +0100, Mark Rutland wrote:
>>> Hi,
>>>
>>> These patches fix a segfault seen in some cases when perf stat is exiting.
>>>
>>> We don't balance opening/closing of events in all cases, and go
>>> out-of-bounds
>>> when we close events. Full details in the patch 2 commit message.
>>>
>>> Thanks,
>>> Mark.
>>>
>>> Mark Rutland (2):
>>> perf evsel: add per{cpu,thread} close helpers
>>> perf stat: balance opening/closing of events
>>>
>>> tools/perf/builtin-stat.c | 24 +++-
>>> tools/perf/util/evsel.c | 26 --
>>> tools/perf/util/evsel.h | 4
>>> 3 files changed, 47 insertions(+), 7 deletions(-)
>>>
>>> --
>>> 1.9.1
>>>
>
> thanks
> Ganapat
linux-next: manual merge of the kvms390 tree with the kvm-arm tree
Hi all,
Today's linux-next merge of the kvms390 tree got a conflict in:
arch/s390/include/asm/kvm_host.h
between commit:
2387149eade2 ("KVM: improve arch vcpu request defining")
from the kvm-arm tree and commit:
8611a6a64661 ("KVM: s390: CMMA tracking, ESSA emulation, migration mode")
from the kvms390 tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc arch/s390/include/asm/kvm_host.h
index 9c3bd94204ac,a8cafed79eb4..
--- a/arch/s390/include/asm/kvm_host.h
+++ b/arch/s390/include/asm/kvm_host.h
@@@ -42,9 -42,11 +42,11 @@@
#define KVM_HALT_POLL_NS_DEFAULT 8
/* s390-specific vcpu->requests bit members */
-#define KVM_REQ_ENABLE_IBS 8
-#define KVM_REQ_DISABLE_IBS9
-#define KVM_REQ_ICPT_OPEREXC 10
-#define KVM_REQ_START_MIGRATION 11
-#define KVM_REQ_STOP_MIGRATION12
+#define KVM_REQ_ENABLE_IBSKVM_ARCH_REQ(0)
+#define KVM_REQ_DISABLE_IBS KVM_ARCH_REQ(1)
+#define KVM_REQ_ICPT_OPEREXC KVM_ARCH_REQ(2)
++#define KVM_REQ_START_MIGRATION KVM_ARCH_REQ(3)
++#define KVM_REQ_STOP_MIGRATIONKVM_ARCH_REQ(4)
#define SIGP_CTRL_C 0x80
#define SIGP_CTRL_SCN_MASK0x3f
Re: linux-next: build failure after merge of the device-mapper tree
Stephen,
On 6/9/17 12:12, Stephen Rothwell wrote:
> Hi all,
>
> After merging the device-mapper tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/md/dm-zoned-target.c:947:2: error: unknown field 'suspend' specified
> in initializer
> .suspend = dmz_suspend,
> ^
> drivers/md/dm-zoned-target.c:947:14: error: initialization from incompatible
> pointer type [-Werror=incompatible-pointer-types]
> .suspend = dmz_suspend,
> ^
>
> Caused by commit
>
> 02da2e15e81f ("dm zoned: drive-managed zoned block device target")
>
> I have used the device-mapper tree from next-20170608 for today.
My apologies for that. My mistake.
I just posted a patch to dm-devel to fix this.
Everything should come in order after Mike's review.
Best regards.
--
Damien Le Moal, Ph.D.
Sr Manager, System Software Group,
Western Digital Research
damien.lem...@wdc.com
Tel: (+81) 0466-98-3593 (Ext. 51-3593)
1 kirihara-cho, Fujisawa, Kanagawa, 252-0888 Japan
www.wdc.com, www.hgst.com
Re: [PATCH v2] refcount: Create unchecked atomic_t implementation
Hi Davidlohr, On 06/08/2017 10:09 PM, Davidlohr Bueso wrote: Yes, this would be a prerequisite for ipc; which I initially thought didn't take a performance hit. Did you see a regression for ipc? The fast paths don't use the refcount, it is only used for rare situations: - GETALL, SETALL for large arrays - alloc undo -- Manfred
Re: [PATCH] s390/crash: Fix KEXEC_NOTE_BYTES definition
On Friday 09 June 2017 07:47 AM, Xunlei Pang wrote:
S390 KEXEC_NOTE_BYTES is not used by note_buf_t as before, which
is now defined as follows:
typedef u32 note_buf_t[CRASH_CORE_NOTE_BYTES/4];
It was changed by the CONFIG_CRASH_CORE feature.
This patch gets rid of all the old KEXEC_NOTE_BYTES stuff, and
renames KEXEC_NOTE_BYTES to CRASH_CORE_NOTE_BYTES for S390.
Fixes: 692f66f26a4c ("crash: move crashkernel parsing and vmcore related code under
CONFIG_CRASH_CORE")
Cc: Dave Young
Cc: Dave Anderson
Cc: Hari Bathini
Cc: Gustavo Luiz Duarte
Signed-off-by: Xunlei Pang
---
arch/s390/include/asm/kexec.h | 2 +-
include/linux/crash_core.h| 7 +++
include/linux/kexec.h | 11 +--
3 files changed, 9 insertions(+), 11 deletions(-)
diff --git a/arch/s390/include/asm/kexec.h b/arch/s390/include/asm/kexec.h
index 2f924bc..352deb8 100644
--- a/arch/s390/include/asm/kexec.h
+++ b/arch/s390/include/asm/kexec.h
@@ -47,7 +47,7 @@
* Seven notes plus zero note at the end: prstatus, fpregset, timer,
* tod_cmp, tod_reg, control regs, and prefix
*/
-#define KEXEC_NOTE_BYTES \
+#define CRASH_CORE_NOTE_BYTES \
(ALIGN(sizeof(struct elf_note), 4) * 8 + \
ALIGN(sizeof("CORE"), 4) * 7 + \
ALIGN(sizeof(struct elf_prstatus), 4) + \
diff --git a/include/linux/crash_core.h b/include/linux/crash_core.h
index e9de6b4..dbc6e5c 100644
--- a/include/linux/crash_core.h
+++ b/include/linux/crash_core.h
@@ -10,9 +10,16 @@
#define CRASH_CORE_NOTE_NAME_BYTES ALIGN(sizeof(CRASH_CORE_NOTE_NAME), 4)
#define CRASH_CORE_NOTE_DESC_BYTES ALIGN(sizeof(struct elf_prstatus), 4)
+/*
+ * The per-cpu notes area is a list of notes terminated by a "NULL"
+ * note header. For kdump, the code in vmcore.c runs in the context
+ * of the second kernel to combine them into one note.
+ */
+#ifndef CRASH_CORE_NOTE_BYTES
#define CRASH_CORE_NOTE_BYTES((CRASH_CORE_NOTE_HEAD_BYTES * 2) + \
CRASH_CORE_NOTE_NAME_BYTES + \
CRASH_CORE_NOTE_DESC_BYTES)
+#endif
#define VMCOREINFO_BYTES PAGE_SIZE
#define VMCOREINFO_NOTE_NAME "VMCOREINFO"
diff --git a/include/linux/kexec.h b/include/linux/kexec.h
index 3ea8275..133df03 100644
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -14,7 +14,6 @@
#if !defined(__ASSEMBLY__)
-#include
#include
#include
@@ -25,6 +24,7 @@
#include
#include
#include
+#include
/* Verify architecture specific macros are defined */
@@ -63,15 +63,6 @@
#define KEXEC_CORE_NOTE_NAME CRASH_CORE_NOTE_NAME
/*
- * The per-cpu notes area is a list of notes terminated by a "NULL"
- * note header. For kdump, the code in vmcore.c runs in the context
- * of the second kernel to combine them into one note.
- */
-#ifndef KEXEC_NOTE_BYTES
-#define KEXEC_NOTE_BYTES CRASH_CORE_NOTE_BYTES
-#endif
-
-/*
* This structure is used to hold the arguments that are used when loading
* kernel binaries.
*/
Looks good to me. Thanks for the fix..
- Hari
Re: [PATCH 1/4] drm: bridge: dw-hdmi: Export hdmi_phy_configure_dwc_hdmi_3d_tx
Ignore this patch, Jose has a better patch to solve rk3399 hdmi phy
configure.
Hi Jose
Sorry for missing your patch about hdmi 2.0 vendor phy fixup:
https://patchwork.kernel.org/patch/9702229
It works fine on rk3399/rk3288, can you resend a standard patch to upstream?
Thanks
On 2017年06月09日 10:45, Mark Yao wrote:
So dw-hdmi vendor driver can reuse hdmi_phy_configure_dwc_hdmi_3d_tx
to configure their hardware.
Signed-off-by: Mark Yao
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 3 ++-
include/drm/bridge/dw_hdmi.h | 3 +++
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 4e1f54a..c1ceec7 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -1097,7 +1097,7 @@ static int dw_hdmi_phy_power_on(struct dw_hdmi *hdmi)
* information the DWC MHL PHY has the same register layout and is thus also
* supported by this function.
*/
-static int hdmi_phy_configure_dwc_hdmi_3d_tx(struct dw_hdmi *hdmi,
+int hdmi_phy_configure_dwc_hdmi_3d_tx(struct dw_hdmi *hdmi,
const struct dw_hdmi_plat_data *pdata,
unsigned long mpixelclock)
{
@@ -1146,6 +1146,7 @@ static int hdmi_phy_configure_dwc_hdmi_3d_tx(struct
dw_hdmi *hdmi,
return 0;
}
+EXPORT_SYMBOL_GPL(hdmi_phy_configure_dwc_hdmi_3d_tx);
static int hdmi_phy_configure(struct dw_hdmi *hdmi)
{
diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
index ed599be..7eb67e6 100644
--- a/include/drm/bridge/dw_hdmi.h
+++ b/include/drm/bridge/dw_hdmi.h
@@ -150,6 +150,9 @@ int dw_hdmi_probe(struct platform_device *pdev,
int dw_hdmi_bind(struct platform_device *pdev, struct drm_encoder *encoder,
const struct dw_hdmi_plat_data *plat_data);
+int hdmi_phy_configure_dwc_hdmi_3d_tx(struct dw_hdmi *hdmi,
+ const struct dw_hdmi_plat_data *pdata,
+ unsigned long mpixelclock);
void dw_hdmi_setup_rx_sense(struct device *dev, bool hpd, bool rx_sense);
void dw_hdmi_set_sample_rate(struct dw_hdmi *hdmi, unsigned int rate);
--
Ｍark Yao
[PATCH v6] mtd: handle partitioning on devices with 0 erasesize
erasesize is meaningful for flash devices but for SRAM there is no
concept of an erase block so erasesize is set to 0. When partitioning
these devices instead of ensuring partitions fall on erasesize
boundaries we ensure they fall on writesize boundaries.
Helped-by: Boris Brezillon
Signed-off-by: Chris Packham
---
Changes in v3:
- new
Changes in v4:
- None
Changes in v5:
- None (yet). There is some active discussion on this so it may change.
patch 4/5 is somewhat dependent on this but only if partitions are
specified on the dt node.
Changes in v6:
- Use MTD_NO_ERASE flag to decide whether to use writesize or erasesize
for alignment purposes
drivers/mtd/mtdpart.c | 26 +-
1 file changed, 17 insertions(+), 9 deletions(-)
diff --git a/drivers/mtd/mtdpart.c b/drivers/mtd/mtdpart.c
index ea5e5307f667..2e152e53ace0 100644
--- a/drivers/mtd/mtdpart.c
+++ b/drivers/mtd/mtdpart.c
@@ -393,8 +393,12 @@ static struct mtd_part *allocate_partition(struct mtd_info
*master,
const struct mtd_partition *part, int partno,
uint64_t cur_offset)
{
+ int wr_alignment = (master->flags & MTD_NO_ERASE) ? master->writesize:
+ master->erasesize;
struct mtd_part *slave;
+ u32 remainder;
char *name;
+ u64 tmp;
/* allocate the partition structure */
slave = kzalloc(sizeof(*slave), GFP_KERNEL);
@@ -499,10 +503,11 @@ static struct mtd_part *allocate_partition(struct
mtd_info *master,
if (slave->offset == MTDPART_OFS_APPEND)
slave->offset = cur_offset;
if (slave->offset == MTDPART_OFS_NXTBLK) {
+ tmp = cur_offset;
slave->offset = cur_offset;
- if (mtd_mod_by_eb(cur_offset, master) != 0) {
- /* Round up to next erasesize */
- slave->offset = (mtd_div_by_eb(cur_offset, master) + 1)
* master->erasesize;
+ remainder = do_div(tmp, wr_alignment);
+ if (remainder) {
+ slave->offset += wr_alignment - remainder;
printk(KERN_NOTICE "Moving partition %d: "
"0x%012llx -> 0x%012llx\n", partno,
(unsigned long long)cur_offset, (unsigned long
long)slave->offset);
@@ -567,19 +572,22 @@ static struct mtd_part *allocate_partition(struct
mtd_info *master,
slave->mtd.erasesize = master->erasesize;
}
- if ((slave->mtd.flags & MTD_WRITEABLE) &&
- mtd_mod_by_eb(slave->offset, &slave->mtd)) {
+ tmp = slave->offset;
+ remainder = do_div(tmp, wr_alignment);
+ if ((slave->mtd.flags & MTD_WRITEABLE) && remainder) {
/* Doesn't start on a boundary of major erase size */
/* FIXME: Let it be writable if it is on a boundary of
* _minor_ erase size though */
slave->mtd.flags &= ~MTD_WRITEABLE;
- printk(KERN_WARNING"mtd: partition \"%s\" doesn't start on an
erase block boundary -- force read-only\n",
+ printk(KERN_WARNING"mtd: partition \"%s\" doesn't start on an
erase/write block boundary -- force read-only\n",
part->name);
}
- if ((slave->mtd.flags & MTD_WRITEABLE) &&
- mtd_mod_by_eb(slave->mtd.size, &slave->mtd)) {
+
+ tmp = slave->mtd.size;
+ remainder = do_div(tmp, wr_alignment);
+ if ((slave->mtd.flags & MTD_WRITEABLE) && remainder) {
slave->mtd.flags &= ~MTD_WRITEABLE;
- printk(KERN_WARNING"mtd: partition \"%s\" doesn't end on an
erase block -- force read-only\n",
+ printk(KERN_WARNING"mtd: partition \"%s\" doesn't end on an
erase/write block -- force read-only\n",
part->name);
}
--
2.13.0
Re: [kernel-hardening] [PATCH 0/6] LSM: Security module blob management
On Thu, 8 Jun 2017, Matt Brown wrote: > On 6/8/17 4:43 PM, Casey Schaufler wrote: > > Subject: [PATCH 0/6] LSM: Security module blob management > > > > This patch set moves management of security blobs out of > > the Linux security modules and into the security module > > infrastructure. This allows "major" security modules that > > use blobs to be stacked, just as "minor" modules that > > do not use blobs can be stacked today. It stops short of > > providing a safe interface for the Netlabel and SO_PEERSEC. > > As a result, any of the existing security modules may be > > used in combination except for SELinux and Smack. > > Very excited about this! I can definitely see use cases for special > purpose LSMs that require data blobs but do not replace things like > SELinux, SMACK or AppArmor. I have had a few ideas recently that would > not be possible under the current setup of one shared blob. Please post details of these ideas once you have say a prototype working with Casey's patches. -- James Morris
Re: [HMM 07/15] mm/ZONE_DEVICE: new type of ZONE_DEVICE for unaddressable memory v3
On 05/24/2017 10:20 AM, Jérôme Glisse wrote:
[...8<...]
+#if IS_ENABLED(CONFIG_DEVICE_PRIVATE)
+int device_private_entry_fault(struct vm_area_struct *vma,
+ unsigned long addr,
+ swp_entry_t entry,
+ unsigned int flags,
+ pmd_t *pmdp)
+{
+ struct page *page = device_private_entry_to_page(entry);
+
+ /*
+* The page_fault() callback must migrate page back to system memory
+* so that CPU can access it. This might fail for various reasons
+* (device issue, device was unsafely unplugged, ...). When such
+* error conditions happen, the callback must return VM_FAULT_SIGBUS.
+*
+* Note that because memory cgroup charges are accounted to the device
+* memory, this should never fail because of memory restrictions (but
+* allocation of regular system page might still fail because we are
+* out of memory).
+*
+* There is a more in-depth description of what that callback can and
+* cannot do, in include/linux/memremap.h
+*/
+ return page->pgmap->page_fault(vma, addr, page, flags, pmdp);
+}
+EXPORT_SYMBOL(device_private_entry_fault);
+#endif /* CONFIG_DEVICE_PRIVATE */
+
static void pgmap_radix_release(struct resource *res)
{
resource_size_t key, align_start, align_size, align_end;
@@ -321,6 +351,10 @@ void *devm_memremap_pages(struct device *dev, struct
resource *res,
}
pgmap->ref = ref;
pgmap->res = &page_map->res;
+ pgmap->type = MEMORY_DEVICE_PUBLIC;
+ pgmap->page_fault = NULL;
+ pgmap->page_free = NULL;
+ pgmap->data = NULL;
mutex_lock(&pgmap_lock);
error = 0;
diff --git a/mm/Kconfig b/mm/Kconfig
index d744cff..f5357ff 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -736,6 +736,19 @@ config ZONE_DEVICE
If FS_DAX is enabled, then say Y.
+config DEVICE_PRIVATE
+ bool "Unaddressable device memory (GPU memory, ...)"
+ depends on X86_64
+ depends on ZONE_DEVICE
+ depends on MEMORY_HOTPLUG
+ depends on MEMORY_HOTREMOVE
+ depends on SPARSEMEM_VMEMMAP
+
+ help
+ Allows creation of struct pages to represent unaddressable device
+ memory; i.e., memory that is only accessible from the device (or
+ group of devices).
+
Hi Jerome,
CONFIG_DEVICE_PRIVATE has caused me some problems, because it's not coupled to
HMM_DEVMEM.
To fix this, my first choice would be to just s/DEVICE_PRIVATE/HMM_DEVMEM/g , because I don't see
any value to DEVICE_PRIVATE as an independent Kconfig choice. It's complicating the Kconfig choices,
and adding problems. However, if DEVICE_PRIVATE must be kept, then something like this also fixes my
HMM tests:
From: John Hubbard
Date: Thu, 8 Jun 2017 20:13:13 -0700
Subject: [PATCH] hmm: select CONFIG_DEVICE_PRIVATE with HMM_DEVMEM
The HMM_DEVMEM feature is useless without the various
features that are guarded with CONFIG_DEVICE_PRIVATE.
Therefore, auto-select DEVICE_PRIVATE when selecting
HMM_DEVMEM.
Otherwise, you can easily end up with a partially
working HMM installation: if you select HMM_DEVMEM,
but do not select DEVICE_PRIVATE, then faulting and
migrating to a device (such as a GPU) works, but CPU
page faults are ignored, so the page never migrates
back to the CPU.
Signed-off-by: John Hubbard
---
mm/Kconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/mm/Kconfig b/mm/Kconfig
index 46296d5d7570..23d2f5ec865e 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -318,6 +318,8 @@ config HMM_DEVMEM
bool "HMM device memory helpers (to leverage ZONE_DEVICE)"
depends on ARCH_HAS_HMM
select HMM
+ select DEVICE_PRIVATE
+
help
HMM devmem is a set of helper routines to leverage the ZONE_DEVICE
feature. This is just to avoid having device drivers to replicating a
lot
--
2.13.1
This is a minor thing, and I don't think this needs to hold up merging HMM v23 into -mm, IMHO. But I
would like it fixed at some point.
thanks,
--
John Hubbard
NVIDIA
linux-next: manual merge of the devicetree tree with the renesas tree
Hi Rob,
Today's linux-next merge of the devicetree tree got a conflict in:
Documentation/devicetree/bindings/vendor-prefixes.txt
between commit:
d795f15618b8 ("of: Add vendor prefix for iWave Systems Technologies Pvt. Ltd")
from the renesas tree and commit:
97a0268e764c ("devicetree: add Itead vendor prefix")
from the devicetree tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc Documentation/devicetree/bindings/vendor-prefixes.txt
index b946fc4b172a,b81092afe76d..
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@@ -158,7 -159,7 +159,8 @@@ iomIomega Corporatio
isee ISEE 2007 S.L.
isil Intersil
issi Integrated Silicon Solutions Inc.
+ itead ITEAD Intelligent Systems Co.Ltd
+iwave iWave Systems Technologies Pvt. Ltd.
jdi Japan Display Inc.
jedec JEDEC Solid State Technology Association
karo Ka-Ro electronics GmbH
Re: [PATCH v3 0/3] Add support for the S6E3HF2 panel on TM2e board
Dear Thierry, Could you check these patches. Regards, Hoegeun On 05/19/2017 03:56 PM, Hoegeun Kwon wrote: Dear Thierry, Could you check these patches? I think this patches have accumulated enough dust. If you have a another opinion, please tell me. Best regards, Hoegeun On 04/18/2017 05:40 PM, Hoegeun Kwon wrote: Hi all, The purpose of this patch is add support for s6e3hf2 AMOLED panel on the TM2e board. The panel has 1600x2560 resolution in 5.65" physical panel in the TM2e device. The s6e3hf2 panel(5.65") is simliar to the previous s6e3ha2 panel(5.7"), but resolution and some command message are different. So it can be distinguished as a compatiblitiy string. Best regards, Hoegeun Changes for V3: - Remove te-gpios property in dts. - Added Reviewed-by: Andrzej Hajda on all patches. - Added Reviewed-by: Inki Dae on patch (2/3). Changes for V2: - Add new compatible string to "samsung,s6e3ha2.txt binding with comments. - Fix the panel name from s6e3ha2-e to s6e3hf2 Hoegeun Kwon (3): dt-bindings: Add support for samsung s6e3hf2 panel drm/panel: s6e3ha2: Add support for s6e3hf2 panel on TM2e board arm64: dts: exynos: Add support for s6e3hf2 panel device on TM2e board .../bindings/display/panel/samsung,s6e3ha2.txt | 5 +- arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts | 11 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c | 64 +++--- 3 files changed, 72 insertions(+), 8 deletions(-)
Re: [PATCH v2 1/1] Add Trusted Path Execution as a stackable LSM
On 06/08/2017 10:38 PM, Kees Cook wrote: On Wed, Jun 7, 2017 at 8:43 PM, Matt Brown wrote: This patch was modified from Brad Spengler's Trusted Path Execution (TPE) feature. It also adds features and config options that were found in Corey Henderson's tpe-lkm project. Modifications from Brad Spengler's implementation of TPE were made to turn it into a stackable LSM using the existing LSM hook bprm_set_creds. Also, a new denial logging function was used to simplify printing messages to the kernel log. Additionally, mmap and mprotect restrictions were taken from Corey Henderson's tpe-lkm project and implemented using the LSM hooks mmap_file and file_mprotect. Trusted Path Execution is not a new idea: http://phrack.org/issues/52/6.html#article | A trusted path is one that is inside a root owned directory that | is not group or world writable. /bin, /usr/bin, /usr/local/bin, are | (under normal circumstances) considered trusted. Any non-root | users home directory is not trusted, nor is /tmp. To be clear, Trusted Path Execution is no replacement for a MAC system like SELinux, SMACK, or AppArmor. This LSM is designed to be good enough without requiring a userland utility to configure policies. The fact that TPE only requires the user to turn on a few sysctl options lowers the barrier to implementing a security framework substantially. Threat Models: 1. Attacker on system executing exploit on system vulnerability * If attacker uses a binary as a part of their system exploit, TPE can frustrate their efforts * This protection can be more effective when an attacker does not yet have an interactive shell on a system * Issues: * Can be bypassed by interpreted languages such as python. You can run malicious code by doing: python -c 'evil code' What's the recommendation for people interested in using TPE but having interpreters installed? If you don't need a given interpreter installed, uninstall it. While this is common sense system hardening it especially would make a difference under the TPE threat model. I don't have a knock down answer for this. Interpreters are a hard problem for TPE. 2. Attacker on system replaces binary used by a privileged user with a malicious one * This situation arises when the administrator of a system leaves a binary as world writable. * TPE is very effective against this threat model This Trusted Path Execution implementation introduces the following Kconfig options and sysctls. The Kconfig text and sysctl options are taken heavily from Brad Spengler's implementation. Some extra sysctl options were taken from Corey Henderson's implementation. CONFIG_SECURITY_TPE (sysctl=kernel.tpe.enabled) default: n This option enables Trusted Path Execution. TPE blocks *untrusted* users from executing files that meet the following conditions: * file is not in a root-owned directory * file is writable by a user other than root NOTE: By default root is not restricted by TPE. CONFIG_SECURITY_TPE_GID (sysctl=kernel.tpe.gid) default: 0 This option defines a group id that, by default, is the trusted group. If a user is not trusted then it has the checks described in CONFIG_SECURITY_TPE applied. Otherwise, the user is trusted and the checks are not applied. You can disable the trusted gid option by setting it to 0. This makes all non-root users untrusted. CONFIG_SECURITY_TPE_STRICT (sysctl=kernel.tpe.strict) default: n This option applies another set of restrictions to all non-root users even if they are trusted. This only allows execution under the following conditions: * file is in a directory owned by the user that is not group or world-writable * file is in a directory owned by root and writable only by root CONFIG_SECURITY_TPE_RESTRICT_ROOT (sysctl=kernel.tpe.restrict_root) default: n This option applies all enabled TPE restrictions to root. CONFIG_SECURITY_TPE_INVERT_GID (sysctl=kernel.tpe.invert_gid) default: n This option reverses the trust logic of the gid option and makes kernel.tpe.gid into the untrusted group. This means that all other groups become trusted. This sysctl is helpful when you want TPE restrictions to be limited to a small subset of users. Signed-off-by: Matt Brown --- Documentation/security/tpe.txt | 59 +++ MAINTAINERS| 5 + include/linux/lsm_hooks.h | 5 + security/Kconfig | 1 + security/Makefile | 2 + security/security.c| 1 + security/tpe/Kconfig | 64 security/tpe/Makefile | 3 + security/tpe/tpe_lsm.c | 218 + 9 files changed, 358 insertions(+) create mode 100644 Documentation/security/tpe.txt create mode 100644 security/tpe/Kconfig create mode 100644 security/tpe/Makefile create mode 100644 security/tpe/tpe_lsm.c diff --git a/Documentation/security/tpe.txt b/Documentation/security/tpe.txt new file mode 100644 index 000..226afc
[GIT PULL] Keys subsystem update
Please pull these Keys subsystem fixes for 4.12. From David Howells: "Here are a bunch of fixes for Linux keyrings, including: (*) Fixing up the refcount handling now that key structs use the refcount_t type and the refcount_t ops don't allow a 0->1 transition. (*) Fix a potential NULL deref after error in x509_cert_parse(). (*) Don't put data for the crypto algorithms to use on the stack. (*) Fix the handling of a null payload being passed to add_key(). (*) Fix incorrect cleanup an uninitialised key_preparsed_payload in key_update(). (*) Explicit sanitisation of potentially secure data before freeing. (*) Fixes for the Diffie-Helman code." --- The following changes since commit aea4156c308670699d74dedb182ebceffb633185: Merge tag 'modules-for-v4.12-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/jeyu/linux (2017-06-08 16:28:49 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git for-linus Bilal Amarni (1): security/keys: add CONFIG_KEYS_COMPAT to Kconfig Dan Carpenter (1): X.509: Fix error code in x509_cert_parse() Davidlohr Bueso (1): security: use READ_ONCE instead of deprecated ACCESS_ONCE Eric Biggers (16): KEYS: put keyring if install_session_keyring_to_cred() fails KEYS: encrypted: avoid encrypting/decrypting stack buffers KEYS: encrypted: fix buffer overread in valid_master_desc() KEYS: encrypted: fix race causing incorrect HMAC calculations KEYS: encrypted: use constant-time HMAC comparison KEYS: fix dereferencing NULL payload with nonzero length KEYS: fix freeing uninitialized memory in key_update() KEYS: sanitize add_key() and keyctl() key payloads KEYS: user_defined: sanitize key payloads KEYS: encrypted: sanitize all key material KEYS: trusted: sanitize all key material KEYS: sanitize key structs before freeing KEYS: DH: forbid using digest_null as the KDF hash KEYS: DH: don't feed uninitialized "otherinfo" into KDF KEYS: DH: ensure the KDF counter is properly aligned KEYS: DH: add __user annotations to keyctl_kdf_params Loganaden Velvindron (1): crypto : asymmetric_keys : verify_pefile:zero memory content before freeing Mark Rutland (1): KEYS: fix refcount_inc() on zero Markus Elfring (1): KEYS: Delete an error message for a failed memory allocation in get_derived_key() Mat Martineau (1): KEYS: Convert KEYCTL_DH_COMPUTE to use the crypto KPP API arch/arm64/Kconfig|4 - arch/powerpc/Kconfig |5 - arch/s390/Kconfig |3 - arch/sparc/Kconfig|3 - arch/x86/Kconfig |4 - crypto/asymmetric_keys/verify_pefile.c|4 +- crypto/asymmetric_keys/x509_cert_parser.c |1 + include/linux/key.h |1 - include/uapi/linux/keyctl.h |4 +- security/keys/Kconfig |6 +- security/keys/dh.c| 300 ++--- security/keys/encrypted-keys/encrypted.c | 204 +++- security/keys/gc.c|4 +- security/keys/key.c | 16 +- security/keys/keyctl.c| 16 +- security/keys/keyring.c | 12 +- security/keys/process_keys.c |7 +- security/keys/trusted.c | 50 ++--- security/keys/user_defined.c | 16 ++- 19 files changed, 330 insertions(+), 330 deletions(-)
Re: [PATCH] ASoC: Intel: sst: Remove unused function sst_restore_shim64()
On Wed, Jun 07, 2017 at 11:40:19PM +0200, Takashi Iwai wrote:
> On Tue, 23 May 2017 02:12:58 +0200,
> Matthias Kaehlcke wrote:
> >
> > Looks like the function has never been used since it was added by commit
> > b0d94acd634a ("ASoC: Intel: mrfld - add shim save restore"). Removing it
> > fixes the following warning when building with clang:
> >
> > sound/soc/intel/atom/sst/sst.c:360:20: error: unused function
> > 'sst_restore_shim64' [-Werror,-Wunused-function]
> >
> > Signed-off-by: Matthias Kaehlcke
>
> Hmm, although this patch was already merged, I now think this is
> rather a bug. If the restore is never executed, why the counterpart,
> sst_save_shim64() is required at all at runtime suspend?
>
> Vinod?
It was supposed to be required in early BYT boards. I do not seem to recall
why the call to sst_restore_shim64 was removed from resume routine, it was
there when we added it and due to file move git log is useless.
Any idea how to get changes to file before the file was moved?
> thanks,
>
> Takashi
>
> > ---
> > sound/soc/intel/atom/sst/sst.c | 16
> > 1 file changed, 16 deletions(-)
> >
> > diff --git a/sound/soc/intel/atom/sst/sst.c b/sound/soc/intel/atom/sst/sst.c
> > index f9ba71315e33..fb608d3a90c8 100644
> > --- a/sound/soc/intel/atom/sst/sst.c
> > +++ b/sound/soc/intel/atom/sst/sst.c
> > @@ -397,22 +397,6 @@ static inline void sst_save_shim64(struct
> > intel_sst_drv *ctx,
> > spin_unlock_irqrestore(&ctx->ipc_spin_lock, irq_flags);
> > }
> >
> > -static inline void sst_restore_shim64(struct intel_sst_drv *ctx,
> > - void __iomem *shim,
> > - struct sst_shim_regs64 *shim_regs)
> > -{
> > - unsigned long irq_flags;
> > -
> > - /*
> > -* we only need to restore IMRX for this case, rest will be
> > -* initialize by FW or driver when firmware is loaded
> > -*/
> > - spin_lock_irqsave(&ctx->ipc_spin_lock, irq_flags);
> > - sst_shim_write64(shim, SST_IMRX, shim_regs->imrx);
> > - sst_shim_write64(shim, SST_CSR, shim_regs->csr);
> > - spin_unlock_irqrestore(&ctx->ipc_spin_lock, irq_flags);
> > -}
> > -
> > void sst_configure_runtime_pm(struct intel_sst_drv *ctx)
> > {
> > pm_runtime_set_autosuspend_delay(ctx->dev, SST_SUSPEND_DELAY);
> > --
> > 2.13.0.303.g4ebf302169-goog
> >
> >
--
~Vinod
Re: [PATCH] md: don't use flush_signals in userspace processes
On Fri, 09 Jun 2017, NeilBrown wrote: > Or maybe it could be discarded - the md_check_recovery() thing. > The idea was that if you alt-sysrq-K to kill all processes, md arrays > would go into immediate-safe-mode where the metadata is marked clean > immediately after writes finish, rather than waiting a few seconds. The > chance of having a clean array after shutdown is hopefully improved. > > I've never actually used this though, and I doubt many people know about > it. And bitmaps make it fairly pointless. Hmm, I have, although I had no idea this was why my arrays were getting far less frazzled than expected... It is really useful behavior, now that I know it can do that. If you can teach SysRq+S, and especially SysRq+U, to force all arrays into safe-mode *after* they carried their current meanings (sync/umount), that would be more useful though, and it would help a lot of people to avoid dirty arrays without them even knowing why... -- Henrique Holschuh
[PATCH tip/sched/core] Add comments to aid in safer usage of swake_up.
The behavior of swake_up() differs from that of wake_up(), and from the
swake_up() that came from RT linux. A memory barrier, or some other
synchronization, is needed prior to a swake_up so that the waiter sees
the condition set by the waker, and so that the waker does not see an
empty wait list.
Signed-off-by: Krister Johansen
---
include/linux/swait.h | 27 +++
kernel/sched/swait.c | 18 +-
2 files changed, 44 insertions(+), 1 deletion(-)
This came out of a discussion that Paul McKenney and I had about
whether other callers of swake_up() knew that they needed to issue
some kind of barrier prior to invoking swake_up. In the case of
wake_up(), the caller will always wake any waiters. With the simple
queues, a swait_active occurs locklessly prior to the wakeup so
additional synchronization may be needed on behalf of the caller.
diff --git a/include/linux/swait.h b/include/linux/swait.h
index c1f9c62..fede974 100644
--- a/include/linux/swait.h
+++ b/include/linux/swait.h
@@ -79,6 +79,33 @@ extern void __init_swait_queue_head(struct swait_queue_head
*q, const char *name
DECLARE_SWAIT_QUEUE_HEAD(name)
#endif
+/**
+ * swait_active -- locklessly test for waiters on the queue
+ * @q: the swait_queue to test for waiters
+ *
+ * returns true if the wait list is not empty
+ *
+ * NOTE: this function is lockless and requires care, incorrect usage _will_
+ * lead to sporadic and non-obvious failure.
+ *
+ * Use either while holding swait_queue_head_t::lock or when used for wakeups
+ * with an extra smp_mb() like:
+ *
+ * CPU0 - wakerCPU1 - waiter
+ *
+ * @cond = true;
+ * smp_mb();
+ * if (swait_active(wq)) swait_event(wq, cond);
+ *swake_up(wq);
+ *
+ *
+ * Because without the explicit smp_mb() it's possible for the
+ * swait_active() load to get hoisted over the @cond store such that we'll
+ * observe an empty wait list while the waiter might not observe @cond.
+ *
+ * Also note that this 'optimization' trades a spin_lock() for an smp_mb(),
+ * which (when the lock is uncontended) are of roughly equal cost.
+ */
static inline int swait_active(struct swait_queue_head *q)
{
return !list_empty(&q->task_list);
diff --git a/kernel/sched/swait.c b/kernel/sched/swait.c
index 3d5610d..6e949a8 100644
--- a/kernel/sched/swait.c
+++ b/kernel/sched/swait.c
@@ -29,6 +29,16 @@ void swake_up_locked(struct swait_queue_head *q)
}
EXPORT_SYMBOL(swake_up_locked);
+/**
+ * swake_up - wake up a waiter on a simple waitqueue
+ * @q: the simple wait queue head
+ *
+ * In order for this to function properly, since it uses swait_active()
+ * internally, some kind of memory barrier must occur prior to calling this.
+ * Typically, this will be smp_mb__after_atomic(), but if the value is
+ * manipulated non-atomically, one may need to use a less regular barrier, such
+ * as smp_mb(). spin_unlock() does not guarantee a memory barrier.
+ */
void swake_up(struct swait_queue_head *q)
{
unsigned long flags;
@@ -45,7 +55,13 @@ EXPORT_SYMBOL(swake_up);
/*
* Does not allow usage from IRQ disabled, since we must be able to
* release IRQs to guarantee bounded hold time.
- */
+ *
+ * In order for this to function properly, since it uses swait_active()
+ * internally, some kind of memory barrier must occur prior to calling this.
+ * Typically, this will be smp_mb__after_atomic(), but if the value is
+ * manipulated non-atomically, one may need to use a less regular barrier, such
+ * as smp_mb(). spin_unlock() does not guarantee a memory barrier.
+ */
void swake_up_all(struct swait_queue_head *q)
{
struct swait_queue *curr;
--
2.7.4
Re: [PATCH tip/core/rcu 45/88] rcu: Add memory barriers for NOCB leader wakeup
On Thu, Jun 08, 2017 at 04:47:43PM -0700, Paul E. McKenney wrote: > On Thu, Jun 08, 2017 at 02:28:14PM -0700, Krister Johansen wrote: > > On Thu, Jun 08, 2017 at 01:55:00PM -0700, Paul E. McKenney wrote: > > > Interesting! This is the first that I have heard that this was anything > > > other than a theoretical bug. To the comment in your second URL, it is > > > wise to recall that a seismologist was in fact arrested for failing to > > > predict an earthquake. Later acquitted/pardoned/whatever, but arrested > > > nonetheless. ;-) > > > > Point taken. I do realize that we all make mistakes, and certainly I do > > too. > > Indeed! Let's just say that the author of that email will have no > trouble returning the favor, and sooner rather than later. ;-) No doubt he's polishing up an extra small extra tight pair of handcuffs with my name on them. > > Perhaps I should have said that my survey of current callers of > > swake_up() was enough to convince me that I didn't have an immediate > > problem elsewhere, but that I'm not familiar enough with the code base > > to make that statement with a lot of authority. The concern being that if > > the patch came from RT-linux where the barrier was present in > > swake_up(), are there other places where swake_up() callers still assume > > this is being handled on their behalf? > > > > As part of this, I also pondered whether I should add a comment around > > swake_up(), similar to what's already there for waitqueue_active. > > I wasn't sure how subtle this is for other consumers, though. > > In my case, I assume I need barriers for swake_up(), which is why I > found this bug by inspection. Still, I wouldn't mind a comment. > Others might have other opinions. Since you don't mind, I've prepared a small patch for those comments. I'll send that in a separate thread. Thanks again, -K
[PATCH] wireless: wlcore: spi: remove unnecessary variable
Remove unnecessary variable and refactor the code.
Addresses-Coverity-ID: 1365000
Signed-off-by: Gustavo A. R. Silva
---
drivers/net/wireless/ti/wlcore/spi.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/ti/wlcore/spi.c
b/drivers/net/wireless/ti/wlcore/spi.c
index fa3547e..d2d899a 100644
--- a/drivers/net/wireless/ti/wlcore/spi.c
+++ b/drivers/net/wireless/ti/wlcore/spi.c
@@ -366,17 +366,14 @@ static int __wl12xx_spi_raw_write(struct device *child,
int addr,
static int __must_check wl12xx_spi_raw_write(struct device *child, int addr,
void *buf, size_t len, bool fixed)
{
- int ret;
-
/* The ELP wakeup write may fail the first time due to internal
* hardware latency. It is safer to send the wakeup command twice to
* avoid unexpected failures.
*/
if (addr == HW_ACCESS_ELP_CTRL_REG)
- ret = __wl12xx_spi_raw_write(child, addr, buf, len, fixed);
- ret = __wl12xx_spi_raw_write(child, addr, buf, len, fixed);
+ __wl12xx_spi_raw_write(child, addr, buf, len, fixed);
- return ret;
+ return __wl12xx_spi_raw_write(child, addr, buf, len, fixed);
}
/**
--
2.5.0
