[PATCH v4 06/10] IB/hns: Replace counting semaphore event_sem with wait_event
Counting semaphores are going away in the future, so replace the semaphore
mthca_cmd::event_sem with a conditional wait_event.
Signed-off-by: Binoy Jayan
---
drivers/infiniband/hw/hns/hns_roce_cmd.c| 46 -
drivers/infiniband/hw/hns/hns_roce_device.h | 2 +-
2 files changed, 33 insertions(+), 15 deletions(-)
diff --git a/drivers/infiniband/hw/hns/hns_roce_cmd.c
b/drivers/infiniband/hw/hns/hns_roce_cmd.c
index 51a0675..12ef3d8 100644
--- a/drivers/infiniband/hw/hns/hns_roce_cmd.c
+++ b/drivers/infiniband/hw/hns/hns_roce_cmd.c
@@ -189,6 +189,34 @@ void hns_roce_cmd_event(struct hns_roce_dev *hr_dev, u16
token, u8 status,
complete(&context->done);
}
+static inline struct hns_roce_cmd_context *
+hns_roce_try_get_context(struct hns_roce_cmdq *cmd)
+{
+ struct hns_roce_cmd_context *context = NULL;
+
+ spin_lock(&cmd->context_lock);
+
+ if (cmd->free_head < 0)
+ goto out;
+
+ context = &cmd->context[cmd->free_head];
+ context->token += cmd->token_mask + 1;
+ cmd->free_head = context->next;
+out:
+ spin_unlock(&cmd->context_lock);
+ return context;
+}
+
+/* wait for and acquire a free context */
+static inline struct hns_roce_cmd_context *
+hns_roce_get_free_context(struct hns_roce_cmdq *cmd)
+{
+ struct hns_roce_cmd_context *context;
+
+ wait_event(cmd->wq, (context = hns_roce_try_get_context(cmd)));
+ return context;
+}
+
/* this should be called with "use_events" */
static int __hns_roce_cmd_mbox_wait(struct hns_roce_dev *hr_dev, u64 in_param,
u64 out_param, unsigned long in_modifier,
@@ -200,13 +228,7 @@ static int __hns_roce_cmd_mbox_wait(struct hns_roce_dev
*hr_dev, u64 in_param,
struct hns_roce_cmd_context *context;
int ret = 0;
- spin_lock(&cmd->context_lock);
- WARN_ON(cmd->free_head < 0);
- context = &cmd->context[cmd->free_head];
- context->token += cmd->token_mask + 1;
- cmd->free_head = context->next;
- spin_unlock(&cmd->context_lock);
-
+ context = hns_roce_get_free_context(cmd);
init_completion(&context->done);
ret = hns_roce_cmd_mbox_post_hw(hr_dev, in_param, out_param,
@@ -238,6 +260,7 @@ static int __hns_roce_cmd_mbox_wait(struct hns_roce_dev
*hr_dev, u64 in_param,
context->next = cmd->free_head;
cmd->free_head = context - cmd->context;
spin_unlock(&cmd->context_lock);
+ wake_up(&cmd->wq);
return ret;
}
@@ -248,10 +271,8 @@ static int hns_roce_cmd_mbox_wait(struct hns_roce_dev
*hr_dev, u64 in_param,
{
int ret = 0;
- down(&hr_dev->cmd.event_sem);
ret = __hns_roce_cmd_mbox_wait(hr_dev, in_param, out_param,
in_modifier, op_modifier, op, timeout);
- up(&hr_dev->cmd.event_sem);
return ret;
}
@@ -313,7 +334,7 @@ int hns_roce_cmd_use_events(struct hns_roce_dev *hr_dev)
hr_cmd->context[hr_cmd->max_cmds - 1].next = -1;
hr_cmd->free_head = 0;
- sema_init(&hr_cmd->event_sem, hr_cmd->max_cmds);
+ init_waitqueue_head(&hr_cmd->wq);
spin_lock_init(&hr_cmd->context_lock);
hr_cmd->token_mask = CMD_TOKEN_MASK;
@@ -325,12 +346,9 @@ int hns_roce_cmd_use_events(struct hns_roce_dev *hr_dev)
void hns_roce_cmd_use_polling(struct hns_roce_dev *hr_dev)
{
struct hns_roce_cmdq *hr_cmd = &hr_dev->cmd;
- int i;
hr_cmd->use_events = 0;
-
- for (i = 0; i < hr_cmd->max_cmds; ++i)
- down(&hr_cmd->event_sem);
+ hr_cmd->free_head = -1;
kfree(hr_cmd->context);
}
diff --git a/drivers/infiniband/hw/hns/hns_roce_device.h
b/drivers/infiniband/hw/hns/hns_roce_device.h
index 2afe075..ac95f52 100644
--- a/drivers/infiniband/hw/hns/hns_roce_device.h
+++ b/drivers/infiniband/hw/hns/hns_roce_device.h
@@ -364,7 +364,7 @@ struct hns_roce_cmdq {
* Event mode: cmd register mutex protection,
* ensure to not exceed max_cmds and user use limit region
*/
- struct semaphoreevent_sem;
+ wait_queue_head_t wq;
int max_cmds;
spinlock_t context_lock;
int free_head;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH v4 03/10] IB/hns: Replace semaphore poll_sem with mutex
The semaphore 'poll_sem' is a simple mutex, so it should be written as one.
Semaphores are going away in the future. So replace it with a mutex. Also,
remove mutex_[un]lock from mthca_cmd_use_events and mthca_cmd_use_polling
respectively.
Signed-off-by: Binoy Jayan
---
drivers/infiniband/hw/hns/hns_roce_cmd.c| 11 ---
drivers/infiniband/hw/hns/hns_roce_device.h | 3 ++-
2 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/infiniband/hw/hns/hns_roce_cmd.c
b/drivers/infiniband/hw/hns/hns_roce_cmd.c
index 2a0b6c0..51a0675 100644
--- a/drivers/infiniband/hw/hns/hns_roce_cmd.c
+++ b/drivers/infiniband/hw/hns/hns_roce_cmd.c
@@ -119,7 +119,7 @@ static int hns_roce_cmd_mbox_post_hw(struct hns_roce_dev
*hr_dev, u64 in_param,
return ret;
}
-/* this should be called with "poll_sem" */
+/* this should be called with "poll_mutex" */
static int __hns_roce_cmd_mbox_poll(struct hns_roce_dev *hr_dev, u64 in_param,
u64 out_param, unsigned long in_modifier,
u8 op_modifier, u16 op,
@@ -167,10 +167,10 @@ static int hns_roce_cmd_mbox_poll(struct hns_roce_dev
*hr_dev, u64 in_param,
{
int ret;
- down(&hr_dev->cmd.poll_sem);
+ mutex_lock(&hr_dev->cmd.poll_mutex);
ret = __hns_roce_cmd_mbox_poll(hr_dev, in_param, out_param, in_modifier,
op_modifier, op, timeout);
- up(&hr_dev->cmd.poll_sem);
+ mutex_unlock(&hr_dev->cmd.poll_mutex);
return ret;
}
@@ -275,7 +275,7 @@ int hns_roce_cmd_init(struct hns_roce_dev *hr_dev)
struct device *dev = &hr_dev->pdev->dev;
mutex_init(&hr_dev->cmd.hcr_mutex);
- sema_init(&hr_dev->cmd.poll_sem, 1);
+ mutex_init(&hr_dev->cmd.poll_mutex);
hr_dev->cmd.use_events = 0;
hr_dev->cmd.toggle = 1;
hr_dev->cmd.max_cmds = CMD_MAX_NUM;
@@ -319,8 +319,6 @@ int hns_roce_cmd_use_events(struct hns_roce_dev *hr_dev)
hr_cmd->token_mask = CMD_TOKEN_MASK;
hr_cmd->use_events = 1;
- down(&hr_cmd->poll_sem);
-
return 0;
}
@@ -335,7 +333,6 @@ void hns_roce_cmd_use_polling(struct hns_roce_dev *hr_dev)
down(&hr_cmd->event_sem);
kfree(hr_cmd->context);
- up(&hr_cmd->poll_sem);
}
struct hns_roce_cmd_mailbox
diff --git a/drivers/infiniband/hw/hns/hns_roce_device.h
b/drivers/infiniband/hw/hns/hns_roce_device.h
index 3417315..2afe075 100644
--- a/drivers/infiniband/hw/hns/hns_roce_device.h
+++ b/drivers/infiniband/hw/hns/hns_roce_device.h
@@ -34,6 +34,7 @@
#define _HNS_ROCE_DEVICE_H
#include
+#include
#define DRV_NAME "hns_roce"
@@ -358,7 +359,7 @@ struct hns_roce_cmdq {
struct dma_pool *pool;
u8 __iomem *hcr;
struct mutexhcr_mutex;
- struct semaphorepoll_sem;
+ struct mutexpoll_mutex;
/*
* Event mode: cmd register mutex protection,
* ensure to not exceed max_cmds and user use limit region
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH v4 01/10] IB/core: iwpm_nlmsg_request: Replace semaphore with completion
Semaphore sem in iwpm_nlmsg_request is used as completion, so
convert it to a struct completion type. Semaphores are going
away in the future.
Signed-off-by: Binoy Jayan
---
drivers/infiniband/core/iwpm_msg.c | 8
drivers/infiniband/core/iwpm_util.c | 7 +++
drivers/infiniband/core/iwpm_util.h | 3 ++-
3 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/infiniband/core/iwpm_msg.c
b/drivers/infiniband/core/iwpm_msg.c
index 1c41b95..761358f 100644
--- a/drivers/infiniband/core/iwpm_msg.c
+++ b/drivers/infiniband/core/iwpm_msg.c
@@ -394,7 +394,7 @@ int iwpm_register_pid_cb(struct sk_buff *skb, struct
netlink_callback *cb)
/* always for found nlmsg_request */
kref_put(&nlmsg_request->kref, iwpm_free_nlmsg_request);
barrier();
- up(&nlmsg_request->sem);
+ complete(&nlmsg_request->comp);
return 0;
}
EXPORT_SYMBOL(iwpm_register_pid_cb);
@@ -463,7 +463,7 @@ int iwpm_add_mapping_cb(struct sk_buff *skb, struct
netlink_callback *cb)
/* always for found request */
kref_put(&nlmsg_request->kref, iwpm_free_nlmsg_request);
barrier();
- up(&nlmsg_request->sem);
+ complete(&nlmsg_request->comp);
return 0;
}
EXPORT_SYMBOL(iwpm_add_mapping_cb);
@@ -555,7 +555,7 @@ int iwpm_add_and_query_mapping_cb(struct sk_buff *skb,
/* always for found request */
kref_put(&nlmsg_request->kref, iwpm_free_nlmsg_request);
barrier();
- up(&nlmsg_request->sem);
+ complete(&nlmsg_request->comp);
return 0;
}
EXPORT_SYMBOL(iwpm_add_and_query_mapping_cb);
@@ -749,7 +749,7 @@ int iwpm_mapping_error_cb(struct sk_buff *skb, struct
netlink_callback *cb)
/* always for found request */
kref_put(&nlmsg_request->kref, iwpm_free_nlmsg_request);
barrier();
- up(&nlmsg_request->sem);
+ complete(&nlmsg_request->comp);
return 0;
}
EXPORT_SYMBOL(iwpm_mapping_error_cb);
diff --git a/drivers/infiniband/core/iwpm_util.c
b/drivers/infiniband/core/iwpm_util.c
index ade71e7..08ddd2e 100644
--- a/drivers/infiniband/core/iwpm_util.c
+++ b/drivers/infiniband/core/iwpm_util.c
@@ -323,8 +323,7 @@ struct iwpm_nlmsg_request *iwpm_get_nlmsg_request(__u32
nlmsg_seq,
nlmsg_request->nl_client = nl_client;
nlmsg_request->request_done = 0;
nlmsg_request->err_code = 0;
- sema_init(&nlmsg_request->sem, 1);
- down(&nlmsg_request->sem);
+ init_completion(&nlmsg_request->comp);
return nlmsg_request;
}
@@ -368,8 +367,8 @@ int iwpm_wait_complete_req(struct iwpm_nlmsg_request
*nlmsg_request)
{
int ret;
- ret = down_timeout(&nlmsg_request->sem, IWPM_NL_TIMEOUT);
- if (ret) {
+ ret = wait_for_completion_timeout(&nlmsg_request->comp,
IWPM_NL_TIMEOUT);
+ if (!ret) {
ret = -EINVAL;
pr_info("%s: Timeout %d sec for netlink request (seq = %u)\n",
__func__, (IWPM_NL_TIMEOUT/HZ),
nlmsg_request->nlmsg_seq);
diff --git a/drivers/infiniband/core/iwpm_util.h
b/drivers/infiniband/core/iwpm_util.h
index af1fc14..ea6c299 100644
--- a/drivers/infiniband/core/iwpm_util.h
+++ b/drivers/infiniband/core/iwpm_util.h
@@ -43,6 +43,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -69,7 +70,7 @@ struct iwpm_nlmsg_request {
u8 nl_client;
u8 request_done;
u16 err_code;
- struct semaphoresem;
+ struct completion comp;
struct kref kref;
};
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH v4 07/10] IB/mthca: Replace counting semaphore event_sem with wait_event
Counting semaphores are going away in the future, so replace the semaphore
mthca_cmd::event_sem with a conditional wait_event.
Signed-off-by: Binoy Jayan
---
drivers/infiniband/hw/mthca/mthca_cmd.c | 47 ++---
drivers/infiniband/hw/mthca/mthca_dev.h | 3 ++-
2 files changed, 34 insertions(+), 16 deletions(-)
diff --git a/drivers/infiniband/hw/mthca/mthca_cmd.c
b/drivers/infiniband/hw/mthca/mthca_cmd.c
index 49c6e19..d6a048a 100644
--- a/drivers/infiniband/hw/mthca/mthca_cmd.c
+++ b/drivers/infiniband/hw/mthca/mthca_cmd.c
@@ -405,6 +405,34 @@ void mthca_cmd_event(struct mthca_dev *dev,
complete(&context->done);
}
+static inline struct mthca_cmd_context *
+mthca_try_get_context(struct mthca_cmd *cmd)
+{
+ struct mthca_cmd_context *context = NULL;
+
+ spin_lock(&cmd->context_lock);
+
+ if (cmd->free_head < 0)
+ goto out;
+
+ context = &cmd->context[cmd->free_head];
+ context->token += cmd->token_mask + 1;
+ cmd->free_head = context->next;
+out:
+ spin_unlock(&cmd->context_lock);
+ return context;
+}
+
+/* wait for and acquire a free context */
+static inline struct mthca_cmd_context *
+mthca_get_free_context(struct mthca_cmd *cmd)
+{
+ struct mthca_cmd_context *context;
+
+ wait_event(cmd->wq, (context = mthca_try_get_context(cmd)));
+ return context;
+}
+
static int mthca_cmd_wait(struct mthca_dev *dev,
u64 in_param,
u64 *out_param,
@@ -417,15 +445,7 @@ static int mthca_cmd_wait(struct mthca_dev *dev,
int err = 0;
struct mthca_cmd_context *context;
- down(&dev->cmd.event_sem);
-
- spin_lock(&dev->cmd.context_lock);
- BUG_ON(dev->cmd.free_head < 0);
- context = &dev->cmd.context[dev->cmd.free_head];
- context->token += dev->cmd.token_mask + 1;
- dev->cmd.free_head = context->next;
- spin_unlock(&dev->cmd.context_lock);
-
+ context = mthca_get_free_context(&dev->cmd);
init_completion(&context->done);
err = mthca_cmd_post(dev, in_param,
@@ -458,8 +478,8 @@ static int mthca_cmd_wait(struct mthca_dev *dev,
context->next = dev->cmd.free_head;
dev->cmd.free_head = context - dev->cmd.context;
spin_unlock(&dev->cmd.context_lock);
+ wake_up(&dev->cmd.wq);
- up(&dev->cmd.event_sem);
return err;
}
@@ -571,7 +591,7 @@ int mthca_cmd_use_events(struct mthca_dev *dev)
dev->cmd.context[dev->cmd.max_cmds - 1].next = -1;
dev->cmd.free_head = 0;
- sema_init(&dev->cmd.event_sem, dev->cmd.max_cmds);
+ init_waitqueue_head(&dev->cmd.wq);
spin_lock_init(&dev->cmd.context_lock);
for (dev->cmd.token_mask = 1;
@@ -590,12 +610,9 @@ int mthca_cmd_use_events(struct mthca_dev *dev)
*/
void mthca_cmd_use_polling(struct mthca_dev *dev)
{
- int i;
-
dev->cmd.flags &= ~MTHCA_CMD_USE_EVENTS;
- for (i = 0; i < dev->cmd.max_cmds; ++i)
- down(&dev->cmd.event_sem);
+ dev->cmd.free_head = -1;
kfree(dev->cmd.context);
}
diff --git a/drivers/infiniband/hw/mthca/mthca_dev.h
b/drivers/infiniband/hw/mthca/mthca_dev.h
index 87ab964..2fc86db 100644
--- a/drivers/infiniband/hw/mthca/mthca_dev.h
+++ b/drivers/infiniband/hw/mthca/mthca_dev.h
@@ -46,6 +46,7 @@
#include
#include
+#include
#include "mthca_provider.h"
#include "mthca_doorbell.h"
@@ -121,7 +122,7 @@ struct mthca_cmd {
struct pci_pool *pool;
struct mutex hcr_mutex;
struct mutex poll_mutex;
- struct semaphore event_sem;
+ wait_queue_head_t wq;
int max_cmds;
spinlock_tcontext_lock;
int free_head;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH v4 02/10] IB/core: Replace semaphore sm_sem with an atomic wait
The semaphore 'sm_sem' is used for an exclusive ownership of the device
so model the same as an atomic variable with an associated wait_event.
Semaphores are going away in the future.
Signed-off-by: Binoy Jayan
---
drivers/infiniband/core/user_mad.c | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/infiniband/core/user_mad.c
b/drivers/infiniband/core/user_mad.c
index 415a318..6101c0a 100644
--- a/drivers/infiniband/core/user_mad.c
+++ b/drivers/infiniband/core/user_mad.c
@@ -67,6 +67,8 @@ enum {
IB_UMAD_MINOR_BASE = 0
};
+#define UMAD_F_CLAIM 0x01
+
/*
* Our lifetime rules for these structs are the following:
* device special file is opened, we take a reference on the
@@ -87,7 +89,8 @@ struct ib_umad_port {
struct cdev sm_cdev;
struct device *sm_dev;
- struct semaphore sm_sem;
+ wait_queue_head_t wq;
+ unsigned long flags;
struct mutex file_mutex;
struct list_head file_list;
@@ -1030,12 +1033,14 @@ static int ib_umad_sm_open(struct inode *inode, struct
file *filp)
port = container_of(inode->i_cdev, struct ib_umad_port, sm_cdev);
if (filp->f_flags & O_NONBLOCK) {
- if (down_trylock(&port->sm_sem)) {
+ if (test_and_set_bit(UMAD_F_CLAIM, &port->flags)) {
ret = -EAGAIN;
goto fail;
}
} else {
- if (down_interruptible(&port->sm_sem)) {
+ if (wait_event_interruptible(port->wq,
+!test_and_set_bit(UMAD_F_CLAIM,
+&port->flags))) {
ret = -ERESTARTSYS;
goto fail;
}
@@ -1060,7 +1065,8 @@ static int ib_umad_sm_open(struct inode *inode, struct
file *filp)
ib_modify_port(port->ib_dev, port->port_num, 0, &props);
err_up_sem:
- up(&port->sm_sem);
+ clear_bit(UMAD_F_CLAIM, &port->flags);
+ wake_up(&port->wq);
fail:
return ret;
@@ -1079,7 +1085,8 @@ static int ib_umad_sm_close(struct inode *inode, struct
file *filp)
ret = ib_modify_port(port->ib_dev, port->port_num, 0, &props);
mutex_unlock(&port->file_mutex);
- up(&port->sm_sem);
+ clear_bit(UMAD_F_CLAIM, &port->flags);
+ wake_up(&port->wq);
kobject_put(&port->umad_dev->kobj);
@@ -1177,7 +1184,8 @@ static int ib_umad_init_port(struct ib_device *device,
int port_num,
port->ib_dev = device;
port->port_num = port_num;
- sema_init(&port->sm_sem, 1);
+ init_waitqueue_head(&port->wq);
+ __clear_bit(UMAD_F_CLAIM, &port->flags);
mutex_init(&port->file_mutex);
INIT_LIST_HEAD(&port->file_list);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH v4 00/10] infiniband: Remove semaphores
Hi, These are a set of patches [v4] which removes semaphores from infiniband. These are part of a bigger effort to eliminate all semaphores from the linux kernel. v3 -> v4: IB/mlx5: Added patch - Replace semaphore umr_common:sem with wait_event IB/mlx5: Fixed a bug pointed out by Leon Romanovsky Thanks, Binoy Binoy Jayan (10): IB/core: iwpm_nlmsg_request: Replace semaphore with completion IB/core: Replace semaphore sm_sem with an atomic wait IB/hns: Replace semaphore poll_sem with mutex IB/mthca: Replace semaphore poll_sem with mutex IB/isert: Replace semaphore sem with completion IB/hns: Replace counting semaphore event_sem with wait_event IB/mthca: Replace counting semaphore event_sem with wait_event IB/mlx5: Add helper mlx5_ib_post_send_wait IB/mlx5: Replace semaphore umr_common:sem with wait_event IB/mlx5: Simplify completion into a wait_event drivers/infiniband/core/iwpm_msg.c | 8 +- drivers/infiniband/core/iwpm_util.c | 7 +- drivers/infiniband/core/iwpm_util.h | 3 +- drivers/infiniband/core/user_mad.c | 20 +++-- drivers/infiniband/hw/hns/hns_roce_cmd.c| 57 - drivers/infiniband/hw/hns/hns_roce_device.h | 5 +- drivers/infiniband/hw/mlx5/main.c | 6 +- drivers/infiniband/hw/mlx5/mlx5_ib.h| 9 +- drivers/infiniband/hw/mlx5/mr.c | 124 +--- drivers/infiniband/hw/mthca/mthca_cmd.c | 57 - drivers/infiniband/hw/mthca/mthca_cmd.h | 1 + drivers/infiniband/hw/mthca/mthca_dev.h | 5 +- drivers/infiniband/ulp/isert/ib_isert.c | 6 +- drivers/infiniband/ulp/isert/ib_isert.h | 3 +- include/rdma/ib_verbs.h | 1 + 15 files changed, 153 insertions(+), 159 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH v4 04/10] IB/mthca: Replace semaphore poll_sem with mutex
The semaphore 'poll_sem' is a simple mutex, so it should be written as one.
Semaphores are going away in the future. So replace it with a mutex. Also,
remove mutex_[un]lock from mthca_cmd_use_events and mthca_cmd_use_polling
respectively.
Signed-off-by: Binoy Jayan
---
drivers/infiniband/hw/mthca/mthca_cmd.c | 10 +++---
drivers/infiniband/hw/mthca/mthca_cmd.h | 1 +
drivers/infiniband/hw/mthca/mthca_dev.h | 2 +-
3 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/infiniband/hw/mthca/mthca_cmd.c
b/drivers/infiniband/hw/mthca/mthca_cmd.c
index c7f49bb..49c6e19 100644
--- a/drivers/infiniband/hw/mthca/mthca_cmd.c
+++ b/drivers/infiniband/hw/mthca/mthca_cmd.c
@@ -347,7 +347,7 @@ static int mthca_cmd_poll(struct mthca_dev *dev,
unsigned long end;
u8 status;
- down(&dev->cmd.poll_sem);
+ mutex_lock(&dev->cmd.poll_mutex);
err = mthca_cmd_post(dev, in_param,
out_param ? *out_param : 0,
@@ -382,7 +382,7 @@ static int mthca_cmd_poll(struct mthca_dev *dev,
}
out:
- up(&dev->cmd.poll_sem);
+ mutex_unlock(&dev->cmd.poll_mutex);
return err;
}
@@ -520,7 +520,7 @@ static int mthca_cmd_imm(struct mthca_dev *dev,
int mthca_cmd_init(struct mthca_dev *dev)
{
mutex_init(&dev->cmd.hcr_mutex);
- sema_init(&dev->cmd.poll_sem, 1);
+ mutex_init(&dev->cmd.poll_mutex);
dev->cmd.flags = 0;
dev->hcr = ioremap(pci_resource_start(dev->pdev, 0) + MTHCA_HCR_BASE,
@@ -582,8 +582,6 @@ int mthca_cmd_use_events(struct mthca_dev *dev)
dev->cmd.flags |= MTHCA_CMD_USE_EVENTS;
- down(&dev->cmd.poll_sem);
-
return 0;
}
@@ -600,8 +598,6 @@ void mthca_cmd_use_polling(struct mthca_dev *dev)
down(&dev->cmd.event_sem);
kfree(dev->cmd.context);
-
- up(&dev->cmd.poll_sem);
}
struct mthca_mailbox *mthca_alloc_mailbox(struct mthca_dev *dev,
diff --git a/drivers/infiniband/hw/mthca/mthca_cmd.h
b/drivers/infiniband/hw/mthca/mthca_cmd.h
index d2e5b19..a7f197e 100644
--- a/drivers/infiniband/hw/mthca/mthca_cmd.h
+++ b/drivers/infiniband/hw/mthca/mthca_cmd.h
@@ -35,6 +35,7 @@
#ifndef MTHCA_CMD_H
#define MTHCA_CMD_H
+#include
#include
#define MTHCA_MAILBOX_SIZE 4096
diff --git a/drivers/infiniband/hw/mthca/mthca_dev.h
b/drivers/infiniband/hw/mthca/mthca_dev.h
index 4393a02..87ab964 100644
--- a/drivers/infiniband/hw/mthca/mthca_dev.h
+++ b/drivers/infiniband/hw/mthca/mthca_dev.h
@@ -120,7 +120,7 @@ enum {
struct mthca_cmd {
struct pci_pool *pool;
struct mutex hcr_mutex;
- struct semaphore poll_sem;
+ struct mutex poll_mutex;
struct semaphore event_sem;
int max_cmds;
spinlock_tcontext_lock;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH v4 10/10] IB/mlx5: Simplify completion into a wait_event
Convert the completion 'mlx5_ib_umr_context:done' to a wait_event as it
just waits for the return value to be filled.
Signed-off-by: Binoy Jayan
---
drivers/infiniband/hw/mlx5/mlx5_ib.h | 2 +-
drivers/infiniband/hw/mlx5/mr.c | 9 +
include/rdma/ib_verbs.h | 1 +
3 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/infiniband/hw/mlx5/mlx5_ib.h
b/drivers/infiniband/hw/mlx5/mlx5_ib.h
index de31b5f..cf496b5 100644
--- a/drivers/infiniband/hw/mlx5/mlx5_ib.h
+++ b/drivers/infiniband/hw/mlx5/mlx5_ib.h
@@ -524,7 +524,7 @@ struct mlx5_ib_mw {
struct mlx5_ib_umr_context {
struct ib_cqe cqe;
enum ib_wc_status status;
- struct completion done;
+ wait_queue_head_t wq;
};
struct umr_common {
diff --git a/drivers/infiniband/hw/mlx5/mr.c b/drivers/infiniband/hw/mlx5/mr.c
index dfaf6f6..49ff2af 100644
--- a/drivers/infiniband/hw/mlx5/mr.c
+++ b/drivers/infiniband/hw/mlx5/mr.c
@@ -846,14 +846,14 @@ static void mlx5_ib_umr_done(struct ib_cq *cq, struct
ib_wc *wc)
container_of(wc->wr_cqe, struct mlx5_ib_umr_context, cqe);
context->status = wc->status;
- complete(&context->done);
+ wake_up(&context->wq);
}
static inline void mlx5_ib_init_umr_context(struct mlx5_ib_umr_context
*context)
{
context->cqe.done = mlx5_ib_umr_done;
- context->status = -1;
- init_completion(&context->done);
+ context->status = IB_WC_STATUS_NONE;
+ init_waitqueue_head(&context->wq);
}
static inline int mlx5_ib_post_send_wait(struct mlx5_ib_dev *dev,
@@ -873,7 +873,8 @@ static inline int mlx5_ib_post_send_wait(struct mlx5_ib_dev
*dev,
if (err) {
mlx5_ib_warn(dev, "UMR post send failed, err %d\n", err);
} else {
- wait_for_completion(&umr_context.done);
+ wait_event(umr_context.wq,
+ umr_context.status != IB_WC_STATUS_NONE);
if (umr_context.status != IB_WC_SUCCESS) {
mlx5_ib_warn(dev, "reg umr failed (%u)\n",
umr_context.status);
diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h
index 5ad43a4..8b15b6f 100644
--- a/include/rdma/ib_verbs.h
+++ b/include/rdma/ib_verbs.h
@@ -823,6 +823,7 @@ struct ib_ah_attr {
};
enum ib_wc_status {
+ IB_WC_STATUS_NONE = -1,
IB_WC_SUCCESS,
IB_WC_LOC_LEN_ERR,
IB_WC_LOC_QP_OP_ERR,
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH v4 08/10] IB/mlx5: Add helper mlx5_ib_post_send_wait
Clean up the following common code (to post a list of work requests to the
send queue of the specified QP) at various places and add a helper function
'mlx5_ib_post_send_wait' to implement the same.
- Initialize 'mlx5_ib_umr_context' on stack
- Assign "mlx5_umr_wr:wr:wr_cqe to umr_context.cqe
- Acquire the semaphore
- call ib_post_send with a single ib_send_wr
- wait_for_completion()
- Check for umr_context.status
- Release the semaphore
As semaphores are going away in the future, moving all of these into the
shared helper leaves only a single function using the semaphore, which
can then be rewritten to use something else.
Signed-off-by: Binoy Jayan
---
drivers/infiniband/hw/mlx5/mr.c | 115 +++-
1 file changed, 32 insertions(+), 83 deletions(-)
diff --git a/drivers/infiniband/hw/mlx5/mr.c b/drivers/infiniband/hw/mlx5/mr.c
index d4ad672..1593856 100644
--- a/drivers/infiniband/hw/mlx5/mr.c
+++ b/drivers/infiniband/hw/mlx5/mr.c
@@ -856,16 +856,40 @@ static inline void mlx5_ib_init_umr_context(struct
mlx5_ib_umr_context *context)
init_completion(&context->done);
}
+static inline int mlx5_ib_post_send_wait(struct mlx5_ib_dev *dev,
+struct mlx5_umr_wr *umrwr)
+{
+ struct umr_common *umrc = &dev->umrc;
+ struct ib_send_wr *bad;
+ int err;
+ struct mlx5_ib_umr_context umr_context;
+
+ mlx5_ib_init_umr_context(&umr_context);
+ umrwr->wr.wr_cqe = &umr_context.cqe;
+
+ down(&umrc->sem);
+ err = ib_post_send(umrc->qp, &umrwr->wr, &bad);
+ if (err) {
+ mlx5_ib_warn(dev, "UMR post send failed, err %d\n", err);
+ } else {
+ wait_for_completion(&umr_context.done);
+ if (umr_context.status != IB_WC_SUCCESS) {
+ mlx5_ib_warn(dev, "reg umr failed (%u)\n",
+umr_context.status);
+ err = -EFAULT;
+ }
+ }
+ up(&umrc->sem);
+ return err;
+}
+
static struct mlx5_ib_mr *reg_umr(struct ib_pd *pd, struct ib_umem *umem,
u64 virt_addr, u64 len, int npages,
int page_shift, int order, int access_flags)
{
struct mlx5_ib_dev *dev = to_mdev(pd->device);
struct device *ddev = dev->ib_dev.dma_device;
- struct umr_common *umrc = &dev->umrc;
- struct mlx5_ib_umr_context umr_context;
struct mlx5_umr_wr umrwr = {};
- struct ib_send_wr *bad;
struct mlx5_ib_mr *mr;
struct ib_sge sg;
int size;
@@ -894,24 +918,12 @@ static struct mlx5_ib_mr *reg_umr(struct ib_pd *pd,
struct ib_umem *umem,
if (err)
goto free_mr;
- mlx5_ib_init_umr_context(&umr_context);
-
- umrwr.wr.wr_cqe = &umr_context.cqe;
prep_umr_reg_wqe(pd, &umrwr.wr, &sg, dma, npages, mr->mmkey.key,
page_shift, virt_addr, len, access_flags);
- down(&umrc->sem);
- err = ib_post_send(umrc->qp, &umrwr.wr, &bad);
- if (err) {
- mlx5_ib_warn(dev, "post send failed, err %d\n", err);
+ err = mlx5_ib_post_send_wait(dev, &umrwr);
+ if (err && err != -EFAULT)
goto unmap_dma;
- } else {
- wait_for_completion(&umr_context.done);
- if (umr_context.status != IB_WC_SUCCESS) {
- mlx5_ib_warn(dev, "reg umr failed\n");
- err = -EFAULT;
- }
- }
mr->mmkey.iova = virt_addr;
mr->mmkey.size = len;
@@ -920,7 +932,6 @@ static struct mlx5_ib_mr *reg_umr(struct ib_pd *pd, struct
ib_umem *umem,
mr->live = 1;
unmap_dma:
- up(&umrc->sem);
dma_unmap_single(ddev, dma, size, DMA_TO_DEVICE);
kfree(mr_pas);
@@ -940,13 +951,10 @@ int mlx5_ib_update_mtt(struct mlx5_ib_mr *mr, u64
start_page_index, int npages,
{
struct mlx5_ib_dev *dev = mr->dev;
struct device *ddev = dev->ib_dev.dma_device;
- struct umr_common *umrc = &dev->umrc;
- struct mlx5_ib_umr_context umr_context;
struct ib_umem *umem = mr->umem;
int size;
__be64 *pas;
dma_addr_t dma;
- struct ib_send_wr *bad;
struct mlx5_umr_wr wr;
struct ib_sge sg;
int err = 0;
@@ -1011,10 +1019,7 @@ int mlx5_ib_update_mtt(struct mlx5_ib_mr *mr, u64
start_page_index, int npages,
dma_sync_single_for_device(ddev, dma, size, DMA_TO_DEVICE);
- mlx5_ib_init_umr_context(&umr_context);
-
memset(&wr, 0, sizeof(wr));
- wr.wr.wr_cqe = &umr_context.cqe;
sg.addr = dma;
sg.length = ALIGN(npages * sizeof(u64),
@@ -1031,19 +1036,7 @@ int mlx5_ib_update_mtt(struct mlx5_ib_mr *mr, u64
start_page_index, int npages,
wr.mkey = mr->mmkey.key;
wr.target.offset = sta
[PATCH v4 05/10] IB/isert: Replace semaphore sem with completion
The semaphore 'sem' in isert_device is used as completion, so convert
it to struct completion. Semaphores are going away in the future.
Signed-off-by: Binoy Jayan
---
drivers/infiniband/ulp/isert/ib_isert.c | 6 +++---
drivers/infiniband/ulp/isert/ib_isert.h | 3 ++-
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/infiniband/ulp/isert/ib_isert.c
b/drivers/infiniband/ulp/isert/ib_isert.c
index 6dd43f6..de80f56 100644
--- a/drivers/infiniband/ulp/isert/ib_isert.c
+++ b/drivers/infiniband/ulp/isert/ib_isert.c
@@ -619,7 +619,7 @@
mutex_unlock(&isert_np->mutex);
isert_info("np %p: Allow accept_np to continue\n", isert_np);
- up(&isert_np->sem);
+ complete(&isert_np->comp);
}
static void
@@ -2311,7 +2311,7 @@ struct rdma_cm_id *
isert_err("Unable to allocate struct isert_np\n");
return -ENOMEM;
}
- sema_init(&isert_np->sem, 0);
+ init_completion(&isert_np->comp);
mutex_init(&isert_np->mutex);
INIT_LIST_HEAD(&isert_np->accepted);
INIT_LIST_HEAD(&isert_np->pending);
@@ -2427,7 +2427,7 @@ struct rdma_cm_id *
int ret;
accept_wait:
- ret = down_interruptible(&isert_np->sem);
+ ret = wait_for_completion_interruptible(&isert_np->comp);
if (ret)
return -ENODEV;
diff --git a/drivers/infiniband/ulp/isert/ib_isert.h
b/drivers/infiniband/ulp/isert/ib_isert.h
index c02ada5..a1277c0 100644
--- a/drivers/infiniband/ulp/isert/ib_isert.h
+++ b/drivers/infiniband/ulp/isert/ib_isert.h
@@ -3,6 +3,7 @@
#include
#include
#include
+#include
#include
#include
@@ -190,7 +191,7 @@ struct isert_device {
struct isert_np {
struct iscsi_np *np;
- struct semaphoresem;
+ struct completion comp;
struct rdma_cm_id *cm_id;
struct mutexmutex;
struct list_headaccepted;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH v4 09/10] IB/mlx5: Replace semaphore umr_common:sem with wait_event
Remove semaphore umr_common:sem used to limit concurrent access to umr qp
and introduce an atomic value 'users' to keep track of the same. Use a
wait_event to block when the limit is reached.
Signed-off-by: Binoy Jayan
---
drivers/infiniband/hw/mlx5/main.c| 6 +-
drivers/infiniband/hw/mlx5/mlx5_ib.h | 7 ++-
drivers/infiniband/hw/mlx5/mr.c | 6 --
3 files changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/infiniband/hw/mlx5/main.c
b/drivers/infiniband/hw/mlx5/main.c
index 2217477..eb72bff 100644
--- a/drivers/infiniband/hw/mlx5/main.c
+++ b/drivers/infiniband/hw/mlx5/main.c
@@ -2437,10 +2437,6 @@ static void destroy_umrc_res(struct mlx5_ib_dev *dev)
ib_dealloc_pd(dev->umrc.pd);
}
-enum {
- MAX_UMR_WR = 128,
-};
-
static int create_umr_res(struct mlx5_ib_dev *dev)
{
struct ib_qp_init_attr *init_attr = NULL;
@@ -2520,7 +2516,7 @@ static int create_umr_res(struct mlx5_ib_dev *dev)
dev->umrc.cq = cq;
dev->umrc.pd = pd;
- sema_init(&dev->umrc.sem, MAX_UMR_WR);
+ init_waitqueue_head(&dev->umrc.wq);
ret = mlx5_mr_cache_init(dev);
if (ret) {
mlx5_ib_warn(dev, "mr cache init failed %d\n", ret);
diff --git a/drivers/infiniband/hw/mlx5/mlx5_ib.h
b/drivers/infiniband/hw/mlx5/mlx5_ib.h
index dcdcd19..de31b5f 100644
--- a/drivers/infiniband/hw/mlx5/mlx5_ib.h
+++ b/drivers/infiniband/hw/mlx5/mlx5_ib.h
@@ -533,7 +533,12 @@ struct umr_common {
struct ib_qp*qp;
/* control access to UMR QP
*/
- struct semaphoresem;
+ wait_queue_head_t wq;
+ atomic_tusers;
+};
+
+enum {
+ MAX_UMR_WR = 128,
};
enum {
diff --git a/drivers/infiniband/hw/mlx5/mr.c b/drivers/infiniband/hw/mlx5/mr.c
index 1593856..dfaf6f6 100644
--- a/drivers/infiniband/hw/mlx5/mr.c
+++ b/drivers/infiniband/hw/mlx5/mr.c
@@ -867,7 +867,8 @@ static inline int mlx5_ib_post_send_wait(struct mlx5_ib_dev
*dev,
mlx5_ib_init_umr_context(&umr_context);
umrwr->wr.wr_cqe = &umr_context.cqe;
- down(&umrc->sem);
+ /* limit number of concurrent ib_post_send() on qp */
+ wait_event(umrc->wq, atomic_add_unless(&umrc->users, 1, MAX_UMR_WR));
err = ib_post_send(umrc->qp, &umrwr->wr, &bad);
if (err) {
mlx5_ib_warn(dev, "UMR post send failed, err %d\n", err);
@@ -879,7 +880,8 @@ static inline int mlx5_ib_post_send_wait(struct mlx5_ib_dev
*dev,
err = -EFAULT;
}
}
- up(&umrc->sem);
+ atomic_dec(&umrc->users);
+ wake_up(&umrc->wq);
return err;
}
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: [RFC 0/8] Define coherent device memory node
On 10/27/2016 10:08 AM, Anshuman Khandual wrote: > On 10/26/2016 09:32 PM, Jerome Glisse wrote: >> On Wed, Oct 26, 2016 at 04:43:10PM +0530, Anshuman Khandual wrote: >>> On 10/26/2016 12:22 AM, Jerome Glisse wrote: On Tue, Oct 25, 2016 at 11:01:08PM +0530, Aneesh Kumar K.V wrote: > Jerome Glisse writes: > >> On Tue, Oct 25, 2016 at 10:29:38AM +0530, Aneesh Kumar K.V wrote: >>> Jerome Glisse writes: On Mon, Oct 24, 2016 at 10:01:49AM +0530, Anshuman Khandual wrote: >> >> [...] >> You can take a look at hmm-v13 if you want to see how i do non LRU page migration. While i put most of the migration code inside hmm_migrate.c it could easily be move to migrate.c without hmm_ prefix. There is 2 missing piece with existing migrate code. First is to put memory allocation for destination under control of who call the migrate code. Second is to allow offloading the copy operation to device (ie not use the CPU to copy data). I believe same requirement also make sense for platform you are targeting. Thus same code can be use. hmm-v13 https://cgit.freedesktop.org/~glisse/linux/log/?h=hmm-v13 I haven't posted this patchset yet because we are doing some modifications to the device driver API to accomodate some new features. But the ZONE_DEVICE changes and the overall migration code will stay the same more or less (i have patches that move it to migrate.c and share more code with existing migrate code). If you think i missed anything about lru and page cache please point it to me. Because when i audited code for that i didn't see any road block with the few fs i was looking at (ext4, xfs and core page cache code). >>> >>> The other restriction around ZONE_DEVICE is, it is not a managed zone. >>> That prevents any direct allocation from coherent device by application. >>> ie, we would like to force allocation from coherent device using >>> interface like mbind(MPOL_BIND..) . Is that possible with ZONE_DEVICE ? >> >> To achieve this we rely on device fault code path ie when device take a >> page fault >> with help of HMM it will use existing memory if any for fault address >> but if CPU >> page table is empty (and it is not file back vma because of readback) >> then device >> can directly allocate device memory and HMM will update CPU page table >> to point to >> newly allocated device memory. >> > > That is ok if the device touch the page first. What if we want the > allocation touched first by cpu to come from GPU ?. Should we always > depend on GPU driver to migrate such pages later from system RAM to GPU > memory ? > I am not sure what kind of workload would rather have every first CPU access for a range to use device memory. So no my code does not handle that and it is pointless for it as CPU can not access device memory for me. That said nothing forbid to add support for ZONE_DEVICE with mbind() like syscall. Thought my personnal preference would still be to avoid use of such generic syscall but have device driver set allocation policy through its own userspace API (device driver could reuse internal of mbind() to achieve the end result). I am not saying that eveything you want to do is doable now with HMM but, nothing preclude achieving what you want to achieve using ZONE_DEVICE. I really don't think any of the existing mm mechanism (kswapd, lru, numa, ...) are nice fit and can be reuse with device memory. Each device is so different from the other that i don't believe in a one API fit all. The drm GPU subsystem of the kernel is a testimony of how little can be share when it comes to GPU. The only common code is modesetting. Everything that deals with how to use GPU to compute stuff is per device and most of the logic is in userspace. So i do not see any commonality that could be abstracted at syscall level. I would rather let device driver stack (kernel and userspace) take such decision and have the higher level API (OpenCL, Cuda, C++17, ...) expose something that make sense for each of them. Programmer target those high level API and they intend to use the mechanism each offer to manage memory and memory placement. I would say forcing them to use a second linux specific API to achieve the latter is wrong, at lest for now. So in the end if the mbind() syscall is done by the userspace side of the device driver then why not
Re: [PATCH v2] mm: remove unnecessary __get_user_pages_unlocked() calls
On Wed, Oct 26, 2016 at 05:12:07PM -0700, Andrew Morton wrote: > It's a KVM patch and should have been called "kvm: remove ...". > Possibly the KVM maintainers will miss it for this reason. > Ah, indeed, however I think given my and Michal's discussion in this thread regarding adjusting get_user_pages_remote() to allow for the unexporting of __get_user_pages_unlocked() it would make more sense for me to batch up this change with that change also (and then in fact actually be an mm patch.)
Re: Build regressions/improvements in v4.9-rc1
Hello, On Thu, 27 Oct 2016 10:56:02 +1100, Michael Ellerman wrote: > > Hm... that's strange - it used to work but doesn't work with newer > > Buildroot... > > > > Anyways if something very simple (i.e. with no extra libraries) works for > > you just go > > ahead and grab pre-built image that Thomas Petazzoni builds. > > > > That's the most recent one: > > http://autobuild.buildroot.org/toolchains/tarballs/br-arcle-hs38-full-2016.08-613-ge98b4dd.tar.bz2 > > > > Thanks, I grabbed that and it works for axs103_smp_defconfig: > > http://kisskb.ellerman.id.au/kisskb/buildresult/12840656/ > > > It doesn't work for axs101_defconfig, saying: > > arch/arc/Makefile:29: *** Toolchain not configured for ARCompact builds. > Stop. axs101 is using a 770 core, while the toolchain is built for the HS38 core. I'm somewhat surprised that a single ARC toolchain cannot produce code for both 770 and HS38, but it seems to be the case. So you need a separate toolchain for ARC770. Best regards, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
Re: [PATCH] arm64: defconfig: Enable DRM DU and V4L2 FCP + VSP modules
On Wed, Oct 26, 2016 at 02:24:22PM +0900, Magnus Damm wrote: > From: Magnus Damm > > Extend the ARM64 defconfig to enable the DU DRM device as module > together with required dependencies of V4L2 FCP and VSP modules. > > This enables VGA output on the r8a7795 Salvator-X board. > > Signed-off-by: Magnus Damm Thanks, I have queued this up.
Re: [PATCH v4 00/10] infiniband: Remove semaphores
On Thu, Oct 27, 2016 at 12:29:04PM +0530, Binoy Jayan wrote: > Hi, > > These are a set of patches [v4] which removes semaphores from infiniband. > These are part of a bigger effort to eliminate all semaphores from the > linux kernel. > > v3 -> v4: > > IB/mlx5: Added patch - Replace semaphore umr_common:sem with wait_event > IB/mlx5: Fixed a bug pointed out by Leon Romanovsky Please keep full changelog for your next submissions/respins. Thanks signature.asc Description: PGP signature
Re: [PATCH] arm64: defconfig: Enable DRM DU and V4L2 FCP + VSP modules
On Thu, Oct 27, 2016 at 09:08:01AM +0200, Simon Horman wrote: > On Wed, Oct 26, 2016 at 02:24:22PM +0900, Magnus Damm wrote: > > From: Magnus Damm > > > > Extend the ARM64 defconfig to enable the DU DRM device as module > > together with required dependencies of V4L2 FCP and VSP modules. > > > > This enables VGA output on the r8a7795 Salvator-X board. > > > > Signed-off-by: Magnus Damm > > Thanks, I have queued this up. Given discussion elsewhere on enabling DU I am holding off on this for a little; it is not queued up for now.
Re: [PATCH 0/6] pwm: imx: Provide atomic operation for IMX PWM driver
On Tue, 25 Oct 2016 15:09:03 -0200 Fabio Estevam wrote: > On Tue, Oct 25, 2016 at 3:08 PM, Fabio Estevam > wrote: > > >> the i.MX6q is not booting. Apparently I do need to wait for things > >> to calm down. > > > > Does this commit help with the boot issue you observed? > > Sorry, missed to put the commit. Here it goes: > https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/arch/arm/mach-imx/gpc.c?id=eef0b282bb586259d35548851cf6a4ce847bb804 I can confirm that the above patch fixed the problem. My iMX6q board boots on 4.9.0-rc2 Thanks for support, Łukasz Majewski pgpxrCBxozcEm.pgp Description: OpenPGP digital signature
Re: [PATCH 1/2] backlight: pwm_bl: Move the checks for initial power state to a separate function
On 10/26/16 16:02, Peter Ujfalusi wrote:
> On 10/26/16 15:12, Lee Jones wrote:
>> On Fri, 30 Sep 2016, Peter Ujfalusi wrote:
>>
>>> Move the check for gpio and regulator initial state to a new function and
>>> document better what we are checking and why.
>>>
>>> It is going to be easier to fix or improve the initial power state
>>> configuration later and it is easier to read the code.
>>>
>>> Signed-off-by: Peter Ujfalusi
>>> ---
>>> drivers/video/backlight/pwm_bl.c | 55
>>> +---
>>> 1 file changed, 35 insertions(+), 20 deletions(-)
>>>
>>> diff --git a/drivers/video/backlight/pwm_bl.c
>>> b/drivers/video/backlight/pwm_bl.c
>>> index b2b366bb0f97..9bc4715bf116 100644
>>> --- a/drivers/video/backlight/pwm_bl.c
>>> +++ b/drivers/video/backlight/pwm_bl.c
>>> @@ -192,6 +192,40 @@ static int pwm_backlight_parse_dt(struct device *dev,
>>> }
>>> #endif
>>>
>>> +static int pwm_backlight_initial_power_state(const struct pwm_bl_data *pb)
>>> +{
>>> + struct device_node *node = pb->dev->of_node;
>>> +
>>> + /* Not booted with device tree or no phandle link to the node */
>>> + if (!node || !node->phandle)
>>> + return FB_BLANK_UNBLANK;
>>
>> This changes the semantics of the current implementation.
>>
>> In the code you're removing, if the enable_gpio is present and no DT
>> is found, we set the GPIO direction to output. In your implementation,
>> if no DT is found you don't do anything regardless.
>>
>> Is that intentional?
>
> Argh, no, it is not intentional.
>
> It should have been like this:
>
> /* Not booted with device tree or no phandle link to the node */
> if (!node || !node->phandle) {
> /* Set enable GPIO if it is valid */
> if (pb->enable_gpio)
> gpiod_direction_output(pb->enable_gpio, 1);
>
> return FB_BLANK_UNBLANK;
> }
>
> On the other hand we are not doing the same for the regulator in case of non
> DT boot or when the backlight has no users. So we do enable the GPIO, but the
> regulator might be left disabled...
>
> I'll resend the series with this change.
This is not really correct either.
If we boot in legacy mode the data->enable_gpio number is used to get the GPIO
and we configure the initial state as GPIOF_OUT_INIT_HIGH. So legacy boot will
have the line high in any case.
I think the only case we should handle differently is when the GPIO is
configured as input (I don't think it happens, but just to be sure). In that
case we need to change the direction to output and set the GPIO as disabled.
If it was input, it was not driving the line.
In the pwm_backlight_initial_power_state() function we will not need to check
for GPIO direction as it is guaranteed that it is output, we can only check
for the value of the GPIO.
I will resubmit with this change.
>
>>
>>> + /*
>>> +* If the driver is probed from the device tree and there is a
>>> +* phandle link pointing to the backlight node, it is safe to
>>> +* assume that another driver will enable the backlight at the
>>> +* appropriate time. Therefore, if it is disabled, keep it so.
>>> +*/
>>> +
>>> + /*
>>> +* if the enable GPIO is set as output and it is disabled, do not enable
>>> +* the backlight
>>> +*/
>>> + if (pb->enable_gpio) {
>>> + if (gpiod_get_direction(pb->enable_gpio) == GPIOF_DIR_OUT &&
>>> + gpiod_get_value(pb->enable_gpio) == 0)
>>> + return FB_BLANK_POWERDOWN;
>>> +
>>> + gpiod_direction_output(pb->enable_gpio, 1);
>>> + }
>>> +
>>> + /* The regulator is disabled, do not enable the backlight */
>>> + if (!regulator_is_enabled(pb->power_supply))
>>> + return FB_BLANK_POWERDOWN;
>>> +
>>> + return FB_BLANK_UNBLANK;
>>> +}
>>> +
>>> static int pwm_backlight_probe(struct platform_device *pdev)
>>> {
>>> struct platform_pwm_backlight_data *data = dev_get_platdata(&pdev->dev);
>>> @@ -200,7 +234,6 @@ static int pwm_backlight_probe(struct platform_device
>>> *pdev)
>>> struct backlight_device *bl;
>>> struct device_node *node = pdev->dev.of_node;
>>> struct pwm_bl_data *pb;
>>> - int initial_blank = FB_BLANK_UNBLANK;
>>> struct pwm_args pargs;
>>> int ret;
>>>
>>> @@ -267,30 +300,12 @@ static int pwm_backlight_probe(struct platform_device
>>> *pdev)
>>> pb->enable_gpio = gpio_to_desc(data->enable_gpio);
>>> }
>>>
>>> - if (pb->enable_gpio) {
>>> - /*
>>> -* If the driver is probed from the device tree and there is a
>>> -* phandle link pointing to the backlight node, it is safe to
>>> -* assume that another driver will enable the backlight at the
>>> -* appropriate time. Therefore, if it is disabled, keep it so.
>>> -*/
>>> - if (node && node->phandle &&
>>> - gpiod_get_direction(pb->enable_gpio) == GPIOF_DIR_OUT &&
>>> -
Re: [PATCH] lib/ida: Document locking requirements a bit better
On Wed, Oct 26, 2016 at 04:07:25PM -0400, Tejun Heo wrote: > Hello, Daniel. > > On Wed, Oct 26, 2016 at 09:25:25PM +0200, Daniel Vetter wrote: > > > > + * Note that callers must ensure that concurrent access to @ida is not > > > > possible. > > > > + * When simplicity trumps concurrency needs look at ida_simple_get() > > > > instead. > > > > > > Maybe we can make it a bit less dramatic? > > > > What about? > > > > "Note that callers must ensure that concurrent access to @ida is not > > possible. > > See ida_simple_get() for a varaint which takes care of locking. > > Yeah, that reads easier to me. > > > > Hmm... so, this isn't necessarily about speed. For example, id > > > allocation might have to happen inside a spinlock which protects a > > > larger scope. To guarantee GFP_KERNEL allocation behavior in such > > > cases, the caller would have to call ida_pre_get() outside the said > > > spinlock and then call ida_get_new_above() inside the lock. > > > > Hm, ida_simple_get does that for you already ... > > Here's an example. > > spin_lock(); > do some stuff; > something->id = ida_simple_get(some gfp flag); > do some stuff; > spin_unlock(); > > In this scenario, you can't use sleeping GFPs for ida_simple_get() > because it does preloading inside it. What one has to do is... > > ida_pre_get(GFP_KERNEL); > spin_lock(); > do some stuff; > something->id = ida_get_new_above(GFP_NOWAIT); > do some stuff; > spin_unlock(); > > So, I guess it can be sometimes about avoiding the extra locking > overhead but it's more often about separating out allocation context > into an earlier call. Hm yeah, calling ida_simple_get in that case isn't recommend really. > > > I think it'd be better to explain what the simple version does and > > > expects and then say that unless there are specific requirements using > > > the simple version is recommended. > > > > What about: > > > > "Compared to ida_get_new_above() this function does its own locking, and > > should be used unless there are special requirements." > > Yeah, looks good to me. Ok, will respin, thanks for the review comments. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [Qemu-devel] [PATCH v9 04/12] vfio iommu: Add support for mediated devices
On 18/10/16 08:22, Kirti Wankhede wrote: > VFIO IOMMU drivers are designed for the devices which are IOMMU capable. > Mediated device only uses IOMMU APIs, the underlying hardware can be > managed by an IOMMU domain. > > Aim of this change is: > - To use most of the code of TYPE1 IOMMU driver for mediated devices > - To support direct assigned device and mediated device in single module > > Added two new callback functions to struct vfio_iommu_driver_ops. Backend > IOMMU module that supports pining and unpinning pages for mdev devices > should provide these functions. > Added APIs for pining and unpining pages to VFIO module. These calls back > into backend iommu module to actually pin and unpin pages. > > This change adds pin and unpin support for mediated device to TYPE1 IOMMU > backend module. More details: > - When iommu_group of mediated devices is attached, task structure is > cached which is used later to pin pages and page accounting. For SPAPR TCE IOMMU driver, I ended up caching mm_struct with atomic_inc(&container->mm->mm_count) (patches are on the way) instead of using @current or task as the process might be gone while VFIO container is still alive and @mm might be needed to do proper cleanup; this might not be an issue with this patchset now but still you seem to only use @mm from task_struct. > - It keeps track of pinned pages for mediated domain. This data is used to > verify unpinning request and to unpin remaining pages while detaching, if > there are any. > - Used existing mechanism for page accounting. If iommu capable domain > exist in the container then all pages are already pinned and accounted. > Accouting for mdev device is only done if there is no iommu capable > domain in the container. > - Page accouting is updated on hot plug and unplug mdev device and pass > through device. > > Tested by assigning below combinations of devices to a single VM: > - GPU pass through only > - vGPU device only > - One GPU pass through and one vGPU device > - Linux VM hot plug and unplug vGPU device while GPU pass through device > exist > - Linux VM hot plug and unplug GPU pass through device while vGPU device > exist > > Signed-off-by: Kirti Wankhede > Signed-off-by: Neo Jia > Change-Id: I295d6f0f2e0579b8d9882bfd8fd5a4194b97bd9a -- Alexey
Re: [PATCH 1/2] mm/memblock: prepare a capability to support memblock near alloc
On Thu 27-10-16 10:41:24, Leizhen (ThunderTown) wrote: > > > On 2016/10/26 17:31, Michal Hocko wrote: > > On Wed 26-10-16 11:10:44, Leizhen (ThunderTown) wrote: > >> > >> > >> On 2016/10/25 21:23, Michal Hocko wrote: > >>> On Tue 25-10-16 10:59:17, Zhen Lei wrote: > If HAVE_MEMORYLESS_NODES is selected, and some memoryless numa nodes are > actually exist. The percpu variable areas and numa control blocks of that > memoryless numa nodes need to be allocated from the nearest available > node to improve performance. > > Although memblock_alloc_try_nid and memblock_virt_alloc_try_nid try the > specified nid at the first time, but if that allocation failed it will > directly drop to use NUMA_NO_NODE. This mean any nodes maybe possible at > the second time. > > To compatible the above old scene, I use a marco node_distance_ready to > control it. By default, the marco node_distance_ready is not defined in > any platforms, the above mentioned functions will work as normal as > before. Otherwise, they will try the nearest node first. > >>> > >>> I am sorry but it is absolutely unclear to me _what_ is the motivation > >>> of the patch. Is this a performance optimization, correctness issue or > >>> something else? Could you please restate what is the problem, why do you > >>> think it has to be fixed at memblock layer and describe what the actual > >>> fix is please? > >> > >> This is a performance optimization. > > > > Do you have any numbers to back the improvements? > > I have not collected any performance data, but at least in theory, > it's beneficial and harmless, except make code looks a bit > urly. The whole memoryless area is cluttered with hacks because everybody just adds pieces here and there to make his particular usecase work IMHO. Adding more on top for performance reasons which are even not measured to prove a clear win is a no go. Please step back try to think how this could be done with an existing infrastructure we have (some cleanups while doing that would be hugely appreciated) and if that is not possible then explain why and why it is not feasible to fix that before you start adding a new API. Thanks! -- Michal Hocko SUSE Labs
[PATCH] lib/ida: Document locking requirements a bit better v2
I wanted to wrap a bunch of ida_simple_get calls into their own
locking, until I dug around and read the original commit message.
Stuff like this should imo be added to the kernel doc, let's do that.
v2: Improve the kerneldoc per Tejun's review.
Cc: Mel Gorman
Cc: Michal Hocko
Cc: Vlastimil Babka
Cc: Tejun Heo
Cc: Andrew Morton
Signed-off-by: Daniel Vetter
---
lib/idr.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/lib/idr.c b/lib/idr.c
index 6098336df267..52d2979a05e8 100644
--- a/lib/idr.c
+++ b/lib/idr.c
@@ -927,6 +927,9 @@ EXPORT_SYMBOL(ida_pre_get);
* and go back to the ida_pre_get() call. If the ida is full, it will
* return %-ENOSPC.
*
+ * Note that callers must ensure that concurrent access to @ida is not
possible.
+ * See ida_simple_get() for a varaint which takes care of locking.
+ *
* @p_id returns a value in the range @starting_id ... %0x7fff.
*/
int ida_get_new_above(struct ida *ida, int starting_id, int *p_id)
@@ -1073,6 +1076,9 @@ EXPORT_SYMBOL(ida_destroy);
* Allocates an id in the range start <= id < end, or returns -ENOSPC.
* On memory allocation failure, returns -ENOMEM.
*
+ * Compared to ida_get_new_above() this function does its own locking, and
+ * should be used unless there are special requirements.
+ *
* Use ida_simple_remove() to get rid of an id.
*/
int ida_simple_get(struct ida *ida, unsigned int start, unsigned int end,
@@ -1119,6 +1125,11 @@ EXPORT_SYMBOL(ida_simple_get);
* ida_simple_remove - remove an allocated id.
* @ida: the (initialized) ida.
* @id: the id returned by ida_simple_get.
+ *
+ * Use to release an id allocated with ida_simple_get().
+ *
+ * Compared to ida_remove() this function does its own locking, and should be
+ * used unless there are special requirements.
*/
void ida_simple_remove(struct ida *ida, unsigned int id)
{
--
2.10.1
Re: [PATCH v1] memcg: Prevent caches to be both OFF_SLAB & OBJFREELIST_SLAB
The patch is marked for memcg but I do not see any direct relation.
I am not familiar with this code enough probably but if this really is
memcg kmem related, please do not forget to CC Vladimir
On Wed 26-10-16 10:41:28, Thomas Garnier wrote:
> While testing OBJFREELIST_SLAB integration with pagealloc, we found a
> bug where kmem_cache(sys) would be created with both CFLGS_OFF_SLAB &
> CFLGS_OBJFREELIST_SLAB.
>
> The original kmem_cache is created early making OFF_SLAB not possible.
> When kmem_cache(sys) is created, OFF_SLAB is possible and if pagealloc
> is enabled it will try to enable it first under certain conditions.
> Given kmem_cache(sys) reuses the original flag, you can have both flags
> at the same time resulting in allocation failures and odd behaviors.
>
> The proposed fix removes these flags by default at the entrance of
> __kmem_cache_create. This way the function will define which way the
> freelist should be handled at this stage for the new cache.
>
> Fixes: b03a017bebc4 ("mm/slab: introduce new slab management type,
> OBJFREELIST_SLAB")
> Signed-off-by: Thomas Garnier
> Signed-off-by: Greg Thelen
> ---
> Based on next-20161025
> ---
> mm/slab.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/mm/slab.c b/mm/slab.c
> index 3c83c29..efe280a 100644
> --- a/mm/slab.c
> +++ b/mm/slab.c
> @@ -2027,6 +2027,14 @@ __kmem_cache_create (struct kmem_cache *cachep,
> unsigned long flags)
> int err;
> size_t size = cachep->size;
>
> + /*
> + * memcg re-creates caches with the flags of the originals. Remove
> + * the freelist related flags to ensure they are re-defined at this
> + * stage. Prevent having both flags on edge cases like with pagealloc
> + * if the original cache was created too early to be OFF_SLAB.
> + */
> + flags &= ~(CFLGS_OBJFREELIST_SLAB|CFLGS_OFF_SLAB);
> +
> #if DEBUG
> #if FORCED_DEBUG
> /*
> --
> 2.8.0.rc3.226.g39d4020
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org";> em...@kvack.org
--
Michal Hocko
SUSE Labs
Re: [PATCH] [media] smiapp: make PM functions as __maybe_unused
Hi Arnd,
On Wed, Oct 26, 2016 at 10:38:01PM +0200, Arnd Bergmann wrote:
> The rework of the PM support has caused two functions to
> be orphaned when CONFIG_PM is disabled:
>
> media/i2c/smiapp/smiapp-core.c:1352:12: error: 'smiapp_power_off' defined but
> not used [-Werror=unused-function]
> media/i2c/smiapp/smiapp-core.c:1206:12: error: 'smiapp_power_on' defined but
> not used [-Werror=unused-function]
>
> This changes all four PM entry points to __maybe_unused and
> removes the #ifdef markers for consistency. This avoids the
> warnings even when something changes again.
>
> Fixes: cbba45d43631 ("[media] smiapp: Use runtime PM")
> Signed-off-by: Arnd Bergmann
The power-on sequence is in fact mandatory as it involves writing the
initial configuration to the sensor as well.
Instead, I believe the correct fix is to make the driver depend on
CONFIG_PM.
--
Kind regards,
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
Re: [RFC PATCH] kbuild: add -fno-PIE
Hi Andrew, On 2016-10-26 19:51:03 [+0200], Sven Joachim wrote: > On 2016-10-25 09:30 +0200, Sebastian Andrzej Siewior wrote: > > > On 2016-10-24 19:32:30 [+0200], Sven Joachim wrote: > >> On 2016-10-24 09:43 +0200, Sebastian Andrzej Siewior wrote: > >> > >> > On 2016-10-24 09:38:49 [+0200], Sven Joachim wrote: > >> >> > >> >> But make still fails with it. :-( > >> > > >> > try setting CONFIG_CC_STACKPROTECTOR_NONE=y and please let me know if > >> > the resulting kernel built with v3.2 gcc boots & works. > >> > >> Sorry, I don't have gcc 3.2 around, and my gcc 3.3 environment produces > >> assembler errors in arch/x86/entry/entry_32.S. Maybe binutils 2.15 is > >> not recent enough anymore? > > I have done a few more tests, and I can confirm that binutils 2.17 is > the oldest version that works. Also, I have succeeded installing gcc > 3.2 in a Debian 4.0 chroot now. > > > so we use stone age gcc but take latest binutils and kernel? What about > > lifting the limit of gcc 3.2? > > Would probably make sense, since gcc 3.2 cannot compile kernel/bounds.c, > at least not on x86. > > , > | CC kernel/bounds.s > | In file included from /tmp/linux/arch/x86/include/asm/bitops.h:512, > | from include/linux/bitops.h:22, > | from include/linux/kernel.h:10, > | from include/asm-generic/bug.h:13, > | from /tmp/linux/arch/x86/include/asm/bug.h:38, > | from include/linux/bug.h:4, > | from include/linux/page-flags.h:9, > | from kernel/bounds.c:9: > | /tmp/linux/arch/x86/include/asm/arch_hweight.h: In function > `__arch_hweight32': > | /tmp/linux/arch/x86/include/asm/arch_hweight.h:29: syntax error before > string constant > | make[1]: *** [kernel/bounds.s] Error 1 > ` > > Building with gcc 3.3 is apparently still possible, although it produces > tons of warnings and a modpost section mismatch. Still, requiring gcc > 4.1 or newer would not be unreasonable, I think (still released a few > months earlier than binutils 2.17). I remember you had once a server box running some enterprise distro which had an old gcc. Do you see any reason for not lifting the minimum gcc version to v4.1 ? > Cheers, >Sven Sebastian
Re: Re: [PATCH] i2c: imx: add slave support. v2 status
Hi Maxim, Dmitriy, Wolfram, If there is no immediate plan for a third release of the below patch set, would it be possible to continue with merging v2 after addressing the remaining concerns? Thank you and regards, Joshua Hi Maxim, On 2016-03-04 11:06:10 in the thread "Re: [PATCH] i2c: imx: add slave support. v2" referenced here: https://patchwork.ozlabs.org/patch/573353/ you said: Hi Wolfram, I'm now working on creating new driver version. I think I'll be able to sent it soon. Do you still plan to release a driver update for an i2c imx driver slave support? Best regards, Jim Baxter
Re: [PATCH v4] time: alarmtimer: Add the trcepoints for alarmtimer
Hi, On 18 October 2016 at 14:47, Baolin Wang wrote: > For system debugging, we sometimes want to know who sets one > alarm timer, the time of the timer, when the timer started and > fired and so on. Thus adding tracepoints can help us trace the > alarmtimer information. > > For example, when we debug the system supend/resume, if the > system is always resumed by RTC alarm, we can find out which > process set the alarm timer to resume system by below trace log: > > .. > > Binder:3292_2-3304 [000] d..2 149.981123: alarmtimer_cancel: > alarmtimer:ffc1319a7800 type:REALTIME > expires:13254631200 now:1325376810370370245 > > Binder:3292_2-3304 [000] d..2 149.981136: alarmtimer_start: > alarmtimer:ffc1319a7800 type:REALTIME > expires:13253768400 now:1325376810370384591 > > Binder:3292_9-3953 [000] d..2 150.212991: alarmtimer_cancel: > alarmtimer:ffc1319a5a00 type:BOOTTIME > expires:17955200 now:150154008122 > > Binder:3292_9-3953 [000] d..2 150.213006: alarmtimer_start: > alarmtimer:ffc1319a5a00 type:BOOTTIME > expires:17955100 now:150154025622 > > .. > > system_server-3000 [002] ...1 162.701940: alarmtimer_suspend: > alarmtimer type:REALTIME expires:1325376839802714584 > > .. > > From the trace log, we can find out the 'Binder:3292_2' process > set one alarm timer which resumes the system. > > Signed-off-by: Baolin Wang > Acked-by: Steven Rostedt > --- > Changes since v3: > - Remove the "ALARM_" prefix in the string. > - Add the ACK by Steven Rostedt. > > Changes since v2: > - Save time as s64 type. > - Remove 'process_name' parameter and add 'now' parameter. > - Rename the trace event name. > - Remove restart trace event. > - Other optimization. Any comments about this version? Thanks. -- Baolin.wang Best Regards
Re: [PATCH v18 0/4] Introduce usb charger framework to deal with the usb gadget power negotation
Hi Felipe, On 19 October 2016 at 10:37, Baolin Wang wrote: > Currently the Linux kernel does not provide any standard integration of this > feature that integrates the USB subsystem with the system power regulation > provided by PMICs meaning that either vendors must add this in their kernels > or USB gadget devices based on Linux (such as mobile phones) may not behave > as they should. Thus provide a standard framework for doing this in kernel. > > Now introduce one user with wm831x_power to support and test the usb charger, > which is pending testing. Moreover there may be other potential users will use > it in future. > > Changes since v17: > - Remove goto section in usb_charger_register() function. > - Remove 'extern' in charger.h file. > - Move the kfree() to usb_charger_exit() function. > > Changes since v16: > - Modify the charger current range with introducing the maximum and minimum > current. > - Remove the getting charger type method from power supply. > - Add the getting charger type method from extcon system. > - Introduce new usb_charger_get_current() API for users to get the maximum > and > minimum current. > - Rename some APIs and other optimization. > > Changes since v15: > - Add charger state checking to avoid sending out duplicate notifies to > users. > - Add one work to notify power users the current has been changed. > > Changes since v14: > - Add kernel documentation for struct usb_cahrger. > - Remove some redundant WARN() functions. > > Changes since v13: > - Remove the charger checking in usb_gadget_vbus_draw() function. > - Rename some functions in charger.c file. > - Rebase on git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git > tags/usb-for-v4.8 > > Changes since v12: > - Remove the class and device things. > - Link usb charger to udc-core.ko. > - Create one "charger" subdirectory which holds all charger-related > attributes. > > Changes since v11: > - Reviewed and tested by Li Jun. > > Changes since v10: > - Introduce usb_charger_get_state() function to check charger state. > - Remove the mutex lock in usb_charger_set_cur_limit_by_type() function > in case will be issued in atomic context. Could you apply this patchset into your branch if there are no other comments? Thanks. > > Baolin Wang (4): > usb: gadget: Introduce the usb charger framework > usb: gadget: Support for the usb charger framework > usb: gadget: Integrate with the usb gadget supporting for usb charger > power: wm831x_power: Support USB charger current limit management > > drivers/power/wm831x_power.c | 75 > drivers/usb/gadget/Kconfig |8 + > drivers/usb/gadget/udc/Makefile |1 + > drivers/usb/gadget/udc/charger.c | 877 > ++ > drivers/usb/gadget/udc/core.c| 19 +- > include/linux/mfd/wm831x/pdata.h |3 + > include/linux/usb/charger.h | 185 > include/linux/usb/gadget.h |3 + > include/uapi/linux/usb/charger.h | 31 ++ > 9 files changed, 1201 insertions(+), 1 deletion(-) > create mode 100644 drivers/usb/gadget/udc/charger.c > create mode 100644 include/linux/usb/charger.h > create mode 100644 include/uapi/linux/usb/charger.h > > -- > 1.7.9.5 > -- Baolin.wang Best Regards
Re: [PATCH] arm64: defconfig: Enable DRM DU and V4L2 FCP + VSP modules
Hi Simon, On Thu, Oct 27, 2016 at 4:15 PM, Simon Horman wrote: > On Thu, Oct 27, 2016 at 09:08:01AM +0200, Simon Horman wrote: >> On Wed, Oct 26, 2016 at 02:24:22PM +0900, Magnus Damm wrote: >> > From: Magnus Damm >> > >> > Extend the ARM64 defconfig to enable the DU DRM device as module >> > together with required dependencies of V4L2 FCP and VSP modules. >> > >> > This enables VGA output on the r8a7795 Salvator-X board. >> > >> > Signed-off-by: Magnus Damm >> >> Thanks, I have queued this up. > > Given discussion elsewhere on enabling DU I am holding off on this for a > little; it is not queued up for now. Sure, thanks for holding off the DT integration patches for r8a7796. Please note that as of mainline v4.9-rc2 the r8a7795 Salvator-X board has thanks to DU, FCP and VSP a working VGA port. So enabling those devices in the defconfig from now on makes sense to me. Cheers, / magnus
[tip:core/urgent] objtool: Fix rare switch jump table pattern detection
Commit-ID: 56fb2d6eb63acd48b50437b415b6f7d2fcffe75d
Gitweb: http://git.kernel.org/tip/56fb2d6eb63acd48b50437b415b6f7d2fcffe75d
Author: Josh Poimboeuf
AuthorDate: Wed, 26 Oct 2016 10:34:08 -0500
Committer: Ingo Molnar
CommitDate: Thu, 27 Oct 2016 08:20:27 +0200
objtool: Fix rare switch jump table pattern detection
The following commit:
3732710ff6f2 ("objtool: Improve rare switch jump table pattern detection")
... improved objtool's ability to detect GCC switch statement jump
tables for GCC 6. However the check to allow short jumps with the
scanned range of instructions wasn't quite right. The pattern detection
should allow jumps to the indirect jump instruction itself.
This fixes the following warning:
drivers/infiniband/sw/rxe/rxe_comp.o: warning: objtool:
rxe_completer()+0x315: sibling call from callable instruction with changed
frame pointer
Reported-by: Arnd Bergmann
Signed-off-by: Josh Poimboeuf
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Fixes: 3732710ff6f2 ("objtool: Improve rare switch jump table pattern
detection")
Link: http://lkml.kernel.org/r/20161026153408.2rifnw7bvoc5sex7@treble
Signed-off-by: Ingo Molnar
---
tools/objtool/builtin-check.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/objtool/builtin-check.c b/tools/objtool/builtin-check.c
index 4490601..e8a1f69 100644
--- a/tools/objtool/builtin-check.c
+++ b/tools/objtool/builtin-check.c
@@ -754,7 +754,7 @@ static struct rela *find_switch_table(struct objtool_file
*file,
if (insn->type == INSN_JUMP_UNCONDITIONAL &&
insn->jump_dest &&
(insn->jump_dest->offset <= insn->offset ||
-insn->jump_dest->offset >= orig_insn->offset))
+insn->jump_dest->offset > orig_insn->offset))
break;
text_rela = find_rela_by_dest_range(insn->sec, insn->offset,
[tip:x86/asm] x86/unwind: Warn on bad frame pointer
Commit-ID: c32c47c68a0ae701088c5b2c3798856ed16746ae
Gitweb: http://git.kernel.org/tip/c32c47c68a0ae701088c5b2c3798856ed16746ae
Author: Josh Poimboeuf
AuthorDate: Wed, 26 Oct 2016 10:41:48 -0500
Committer: Ingo Molnar
CommitDate: Thu, 27 Oct 2016 08:32:37 +0200
x86/unwind: Warn on bad frame pointer
Detect situations in the unwinder where the frame pointer refers to a
bad address, and print an appropriate warning.
Use printk_deferred_once() because the unwinder can be called with the
console lock by lockdep via save_stack_trace().
Signed-off-by: Josh Poimboeuf
Cc: Andy Lutomirski
Cc: Borislav Petkov
Cc: Brian Gerst
Cc: Denys Vlasenko
Cc: H. Peter Anvin
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Link:
http://lkml.kernel.org/r/03c888f6f7414d54fa56b393ea25482be6899b5f.1477496147.git.jpoim...@redhat.com
Signed-off-by: Ingo Molnar
---
arch/x86/kernel/unwind_frame.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/unwind_frame.c b/arch/x86/kernel/unwind_frame.c
index 5795427..9be9a8f 100644
--- a/arch/x86/kernel/unwind_frame.c
+++ b/arch/x86/kernel/unwind_frame.c
@@ -123,8 +123,17 @@ bool unwind_next_frame(struct unwind_state *state)
}
/* make sure the next frame's data is accessible */
- if (!update_stack_state(state, next_frame, next_len))
- return false;
+ if (!update_stack_state(state, next_frame, next_len)) {
+ /*
+* Don't warn on bad regs->bp. An interrupt in entry code
+* might cause a false positive warning.
+*/
+ if (state->regs)
+ goto the_end;
+
+ goto bad_address;
+ }
+
/* move to the next frame */
if (regs) {
state->regs = regs;
@@ -136,6 +145,11 @@ bool unwind_next_frame(struct unwind_state *state)
return true;
+bad_address:
+ printk_deferred_once(KERN_WARNING
+ "WARNING: kernel stack frame pointer at %p in %s:%d has bad
value %p\n",
+ state->bp, state->task->comm,
+ state->task->pid, next_bp);
the_end:
state->stack_info.type = STACK_TYPE_UNKNOWN;
return false;
[tip:sched/urgent] sched/fair: Remove unused but set variable 'rq'
Commit-ID: f5d6d2da0d9098a4aa0ebcc187aa0fc167045d6b
Gitweb: http://git.kernel.org/tip/f5d6d2da0d9098a4aa0ebcc187aa0fc167045d6b
Author: Tobias Klauser
AuthorDate: Wed, 26 Oct 2016 13:37:04 +0200
Committer: Ingo Molnar
CommitDate: Thu, 27 Oct 2016 08:33:52 +0200
sched/fair: Remove unused but set variable 'rq'
Since commit:
8663e24d56dc ("sched/fair: Reorder cgroup creation code")
... the variable 'rq' in alloc_fair_sched_group() is set but no longer used.
Remove it to fix the following GCC warning when building with 'W=1':
kernel/sched/fair.c:8842:13: warning: variable ‘rq’ set but not used
[-Wunused-but-set-variable]
Signed-off-by: Tobias Klauser
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Link: http://lkml.kernel.org/r/20161026113704.8981-1-tklau...@distanz.ch
Signed-off-by: Ingo Molnar
---
kernel/sched/fair.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index d941c97..c242944 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -8839,7 +8839,6 @@ int alloc_fair_sched_group(struct task_group *tg, struct
task_group *parent)
{
struct sched_entity *se;
struct cfs_rq *cfs_rq;
- struct rq *rq;
int i;
tg->cfs_rq = kzalloc(sizeof(cfs_rq) * nr_cpu_ids, GFP_KERNEL);
@@ -8854,8 +8853,6 @@ int alloc_fair_sched_group(struct task_group *tg, struct
task_group *parent)
init_cfs_bandwidth(tg_cfs_bandwidth(tg));
for_each_possible_cpu(i) {
- rq = cpu_rq(i);
-
cfs_rq = kzalloc_node(sizeof(struct cfs_rq),
GFP_KERNEL, cpu_to_node(i));
if (!cfs_rq)
Re: [PATCH v2 03/10] pwm: imx: Rewrite imx_pwm_*_v1 code to facilitate switch to atomic pwm operation
On Thu, 27 Oct 2016 08:29:39 +0200
Lukasz Majewski wrote:
> The code has been rewritten to remove "generic" calls to
> imx_pwm_{enable|disable|config}.
>
> Such approach would facilitate switch to atomic PWM (a.k.a ->apply())
> implementation.
>
> Suggested-by: Stefan Agner
> Suggested-by: Boris Brezillon
> Signed-off-by: Lukasz Majewski
> ---
> Changes for v2:
> - Add missing clock unprepare for clk_ipg
> - Enable peripheral PWM clock (clk_per)
> ---
> drivers/pwm/pwm-imx.c | 50 ++
> 1 file changed, 38 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/pwm/pwm-imx.c b/drivers/pwm/pwm-imx.c
> index ea3ce79..822eb5a 100644
> --- a/drivers/pwm/pwm-imx.c
> +++ b/drivers/pwm/pwm-imx.c
> @@ -65,8 +65,6 @@ struct imx_chip {
> static int imx_pwm_config_v1(struct pwm_chip *chip,
> struct pwm_device *pwm, int duty_ns, int period_ns)
> {
> - struct imx_chip *imx = to_imx_chip(chip);
> -
> /*
>* The PWM subsystem allows for exact frequencies. However,
>* I cannot connect a scope on my device to the PWM line and
> @@ -84,26 +82,56 @@ static int imx_pwm_config_v1(struct pwm_chip *chip,
>* both the prescaler (/1 .. /128) and then by CLKSEL
>* (/2 .. /16).
>*/
> + struct imx_chip *imx = to_imx_chip(chip);
> u32 max = readl(imx->mmio_base + MX1_PWMP);
> u32 p = max * duty_ns / period_ns;
> + int ret;
> +
> + ret = clk_prepare_enable(imx->clk_ipg);
> + if (ret)
> + return ret;
> +
> writel(max - p, imx->mmio_base + MX1_PWMS);
>
> + clk_disable_unprepare(imx->clk_ipg);
> +
> return 0;
> }
>
> -static void imx_pwm_set_enable_v1(struct pwm_chip *chip, bool enable)
> +static int imx_pwm_enable_v1(struct pwm_chip *chip, struct pwm_device *pwm)
> {
> struct imx_chip *imx = to_imx_chip(chip);
> + int ret;
> u32 val;
>
> + ret = clk_prepare_enable(imx->clk_ipg);
> + if (ret)
> + return ret;
> +
> + ret = clk_prepare_enable(imx->clk_per);
> + if (ret)
> + return ret;
> +
> val = readl(imx->mmio_base + MX1_PWMC);
> + val |= MX1_PWMC_EN;
> + writel(val, imx->mmio_base + MX1_PWMC);
>
> - if (enable)
> - val |= MX1_PWMC_EN;
> - else
> - val &= ~MX1_PWMC_EN;
> + clk_disable_unprepare(imx->clk_ipg);
> +
> + return 0;
> +}
> +
> +static void imx_pwm_disable_v1(struct pwm_chip *chip, struct pwm_device *pwm)
> +{
> + struct imx_chip *imx = to_imx_chip(chip);
> + u32 val;
> +
> + val = readl(imx->mmio_base + MX1_PWMC);
> + val &= ~MX1_PWMC_EN;
>
> writel(val, imx->mmio_base + MX1_PWMC);
Are you sure you don't need to enable the ipg clk when manipulating the
PWMC register?
If it's not needed here, then it's probably not needed in
imx_pwm_enable_v1() either.
> +
> + clk_disable_unprepare(imx->clk_per);
> }
>
> static int imx_pwm_config_v2(struct pwm_chip *chip,
> @@ -241,9 +269,9 @@ static void imx_pwm_disable(struct pwm_chip *chip, struct
> pwm_device *pwm)
> }
>
> static struct pwm_ops imx_pwm_ops_v1 = {
> - .enable = imx_pwm_enable,
> - .disable = imx_pwm_disable,
> - .config = imx_pwm_config,
> + .enable = imx_pwm_enable_v1,
> + .disable = imx_pwm_disable_v1,
> + .config = imx_pwm_config_v1,
> .owner = THIS_MODULE,
> };
>
> @@ -262,8 +290,6 @@ struct imx_pwm_data {
> };
>
> static struct imx_pwm_data imx_pwm_data_v1 = {
> - .config = imx_pwm_config_v1,
> - .set_enable = imx_pwm_set_enable_v1,
> .pwm_ops = &imx_pwm_ops_v1,
> };
>
[tip:x86/asm] x86/unwind: Detect bad stack return address
Commit-ID: b6959a362177053c1c90db6dc1af25b6bddd8548
Gitweb: http://git.kernel.org/tip/b6959a362177053c1c90db6dc1af25b6bddd8548
Author: Josh Poimboeuf
AuthorDate: Wed, 26 Oct 2016 10:41:51 -0500
Committer: Ingo Molnar
CommitDate: Thu, 27 Oct 2016 08:32:38 +0200
x86/unwind: Detect bad stack return address
If __kernel_text_address() doesn't recognize a return address on the
stack, it probably means that it's some generated code which
__kernel_text_address() doesn't know about yet.
Otherwise there's probably some stack corruption.
Either way, warn about it.
Use printk_deferred_once() because the unwinder can be called with the
console lock by lockdep via save_stack_trace().
Signed-off-by: Josh Poimboeuf
Cc: Andy Lutomirski
Cc: Borislav Petkov
Cc: Brian Gerst
Cc: Denys Vlasenko
Cc: H. Peter Anvin
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Link:
http://lkml.kernel.org/r/2d897898f324e275943b590d160b55e482bba65f.1477496147.git.jpoim...@redhat.com
Signed-off-by: Ingo Molnar
---
arch/x86/kernel/unwind_frame.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/unwind_frame.c b/arch/x86/kernel/unwind_frame.c
index 9be9a8f..5639db6 100644
--- a/arch/x86/kernel/unwind_frame.c
+++ b/arch/x86/kernel/unwind_frame.c
@@ -20,7 +20,15 @@ unsigned long unwind_get_return_address(struct unwind_state
*state)
addr = ftrace_graph_ret_addr(state->task, &state->graph_idx, *addr_p,
addr_p);
- return __kernel_text_address(addr) ? addr : 0;
+ if (!__kernel_text_address(addr)) {
+ printk_deferred_once(KERN_WARNING
+ "WARNING: unrecognized kernel stack return address %p
at %p in %s:%d\n",
+ (void *)addr, addr_p, state->task->comm,
+ state->task->pid);
+ return 0;
+ }
+
+ return addr;
}
EXPORT_SYMBOL_GPL(unwind_get_return_address);
[tip:x86/asm] x86/dumpstack: Warn on stack recursion
Commit-ID: 0d2b8579add41e08aa1110da864f1071d58e6048
Gitweb: http://git.kernel.org/tip/0d2b8579add41e08aa1110da864f1071d58e6048
Author: Josh Poimboeuf
AuthorDate: Wed, 26 Oct 2016 10:41:50 -0500
Committer: Ingo Molnar
CommitDate: Thu, 27 Oct 2016 08:32:38 +0200
x86/dumpstack: Warn on stack recursion
Print a warning if stack recursion is detected.
Use printk_deferred_once() because the unwinder can be called with the
console lock by lockdep via save_stack_trace().
Signed-off-by: Josh Poimboeuf
Cc: Andy Lutomirski
Cc: Borislav Petkov
Cc: Brian Gerst
Cc: Denys Vlasenko
Cc: H. Peter Anvin
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Link:
http://lkml.kernel.org/r/def18247aafaab480844484398e793f552b79bda.1477496147.git.jpoim...@redhat.com
[ Unbroke the lines. ]
Signed-off-by: Ingo Molnar
---
arch/x86/kernel/dumpstack_32.c | 4 +++-
arch/x86/kernel/dumpstack_64.c | 4 +++-
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/dumpstack_32.c b/arch/x86/kernel/dumpstack_32.c
index 90cf460..d7d20999 100644
--- a/arch/x86/kernel/dumpstack_32.c
+++ b/arch/x86/kernel/dumpstack_32.c
@@ -109,8 +109,10 @@ recursion_check:
* just break out and report an unknown stack type.
*/
if (visit_mask) {
- if (*visit_mask & (1UL << info->type))
+ if (*visit_mask & (1UL << info->type)) {
+ printk_deferred_once(KERN_WARNING "WARNING: stack
recursion on stack type %d\n", info->type);
goto unknown;
+ }
*visit_mask |= 1UL << info->type;
}
diff --git a/arch/x86/kernel/dumpstack_64.c b/arch/x86/kernel/dumpstack_64.c
index 310abf4..ab0f8b9 100644
--- a/arch/x86/kernel/dumpstack_64.c
+++ b/arch/x86/kernel/dumpstack_64.c
@@ -128,8 +128,10 @@ recursion_check:
* just break out and report an unknown stack type.
*/
if (visit_mask) {
- if (*visit_mask & (1UL << info->type))
+ if (*visit_mask & (1UL << info->type)) {
+ printk_deferred_once(KERN_WARNING "WARNING: stack
recursion on stack type %d\n", info->type);
goto unknown;
+ }
*visit_mask |= 1UL << info->type;
}
Re: [PATCH] [media] smiapp: make PM functions as __maybe_unused
On Thursday, October 27, 2016 10:28:18 AM CEST Sakari Ailus wrote:
>
> On Wed, Oct 26, 2016 at 10:38:01PM +0200, Arnd Bergmann wrote:
> > The rework of the PM support has caused two functions to
> > be orphaned when CONFIG_PM is disabled:
> >
> > media/i2c/smiapp/smiapp-core.c:1352:12: error: 'smiapp_power_off' defined
> > but not used [-Werror=unused-function]
> > media/i2c/smiapp/smiapp-core.c:1206:12: error: 'smiapp_power_on' defined
> > but not used [-Werror=unused-function]
> >
> > This changes all four PM entry points to __maybe_unused and
> > removes the #ifdef markers for consistency. This avoids the
> > warnings even when something changes again.
> >
> > Fixes: cbba45d43631 ("[media] smiapp: Use runtime PM")
> > Signed-off-by: Arnd Bergmann
>
> The power-on sequence is in fact mandatory as it involves writing the
> initial configuration to the sensor as well.
>
> Instead, I believe the correct fix is to make the driver depend on
> CONFIG_PM.
(adding linux-pm list)
That would be a rather unusual dependency, though it's possible that
a lot of drivers in fact need it but never listed this explictly in
Kconfig.
What do other drivers do that need to have their runtime_resume
function called at probe time when CONFIG_PM is disabled?
Arnd
Re: [PATCH 8/9] mfd: wm97xx-core: core support for wm97xx Codec
On Wed, Oct 26, 2016 at 09:41:46PM +0200, Robert Jarzmik wrote: > The WM9705, WM9712 and WM9713 are highly integrated codecs, with an > audio codec, DAC and ADC, GPIO unit and a touchscreen interface. > > Historically the support was spread across drivers/input/touchscreen and > sound/soc/codecs. The sharing was done through ac97 bus sharing. This > model will not withstand the new AC97 bus model, where codecs are > discovered on runtime. > > Signed-off-by: Robert Jarzmik > --- Acked-by: Charles Keepax Thanks, Charles
Re: [PATCH v2 11/11] mpt3sas: Bump driver version as "14.101.00.00"
On 10/26/2016 10:04 AM, Suganath Prabu S wrote: > Signed-off-by: Chaitra P B > Signed-off-by: Sathya Prakash > Signed-off-by: Suganath Prabu S > --- > drivers/scsi/mpt3sas/mpt3sas_base.h | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h > b/drivers/scsi/mpt3sas/mpt3sas_base.h > index 5d9ae15..8de0eda 100644 > --- a/drivers/scsi/mpt3sas/mpt3sas_base.h > +++ b/drivers/scsi/mpt3sas/mpt3sas_base.h > @@ -73,9 +73,9 @@ > #define MPT3SAS_DRIVER_NAME "mpt3sas" > #define MPT3SAS_AUTHOR "Avago Technologies > " > #define MPT3SAS_DESCRIPTION "LSI MPT Fusion SAS 3.0 Device Driver" > -#define MPT3SAS_DRIVER_VERSION "14.100.00.00" > +#define MPT3SAS_DRIVER_VERSION "14.101.00.00" > #define MPT3SAS_MAJOR_VERSION14 > -#define MPT3SAS_MINOR_VERSION100 > +#define MPT3SAS_MINOR_VERSION101 > #define MPT3SAS_BUILD_VERSION0 > #define MPT3SAS_RELEASE_VERSION 00 > > Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes ReineckeTeamlead Storage & Networking h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG Nürnberg)
Re: [PATCH v2 03/11] mpt3sas: Implement device_remove_in_progress check in IOCTL path
On 10/26/2016 10:04 AM, Suganath Prabu S wrote: > When device missing event arrives, device_remove_in_progress bit will be > set and hence driver has to stop sending IOCTL commands.Now the check has > been added in IOCTL path to test device_remove_in_progress bit is set, if > so then IOCTL will be failed printing failure message. > > Signed-off-by: Chaitra P B > Signed-off-by: Sathya Prakash > Signed-off-by: Suganath Prabu S > --- > drivers/scsi/mpt3sas/mpt3sas_base.c | 19 +++ > drivers/scsi/mpt3sas/mpt3sas_base.h | 5 > drivers/scsi/mpt3sas/mpt3sas_ctl.c | 46 > ++-- > drivers/scsi/mpt3sas/mpt3sas_scsih.c | 24 ++- > 4 files changed, 86 insertions(+), 8 deletions(-) > Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes ReineckeTeamlead Storage & Networking h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG Nürnberg)
Re: [PATCH V3] mfd: wm8994-core: Don't use managed regulator bulk get API
On Thu, Oct 27, 2016 at 09:09:30AM +0530, Viresh Kumar wrote: > The kernel WARNs and then crashes today if wm8994_device_init() fails > after calling devm_regulator_bulk_get(). > > That happens because there are multiple devices involved here and the > order in which resources are freed isn't correct. > > The regulators are added as children of wm8994->dev. > devm_regulator_bulk_get() receives wm8994->dev as the device, though it > gets the same regulators which were added as children of wm8994->dev > earlier. > > During failures, the children are removed first and the core eventually > calls regulator_unregister() for them. As regulator_put() was never done > for them (opposite of devm_regulator_bulk_get()), the kernel WARNs at > > WARN_ON(rdev->open_count); > > And eventually it crashes from debugfs_remove_recursive(). > > x--x The back track seems to have got really really long again. Thanks, Charles > > wm8994 3-001a: Device is not a WM8994, ID is 0 > [ cut here ] > WARNING: CPU: 0 PID: 1 at > /mnt/ssd/all/work/repos/devel/linux/drivers/regulator/core.c:4072 > regulator_unregister+0xc8/0xd0 > Modules linked in: > CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.8.0-rc6-00154-g54fe84cbd50b #41 > Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) > [] (unwind_backtrace) from [] (show_stack+0x10/0x14) > [] (show_stack) from [] (dump_stack+0x88/0x9c) > [] (dump_stack) from [] (__warn+0xe8/0x100) > [] (__warn) from [] (warn_slowpath_null+0x20/0x28) > [] (warn_slowpath_null) from [] > (regulator_unregister+0xc8/0xd0) > [] (regulator_unregister) from [] > (release_nodes+0x16c/0x1dc) > [] (release_nodes) from [] > (__device_release_driver+0x8c/0x110) > [] (__device_release_driver) from [] > (device_release_driver+0x1c/0x28) > [] (device_release_driver) from [] > (bus_remove_device+0xd8/0x104) > [] (bus_remove_device) from [] (device_del+0x10c/0x218) > [] (device_del) from [] (platform_device_del+0x1c/0x88) > [] (platform_device_del) from [] > (platform_device_unregister+0xc/0x20) > [] (platform_device_unregister) from [] > (mfd_remove_devices_fn+0x5c/0x64) > [] (mfd_remove_devices_fn) from [] > (device_for_each_child_reverse+0x4c/0x78) > [] (device_for_each_child_reverse) from [] > (mfd_remove_devices+0x20/0x30) > [] (mfd_remove_devices) from [] > (wm8994_device_init+0x2ac/0x7f0) > [] (wm8994_device_init) from [] > (i2c_device_probe+0x178/0x1fc) > [] (i2c_device_probe) from [] > (driver_probe_device+0x214/0x2c0) > [] (driver_probe_device) from [] > (__driver_attach+0xac/0xb0) > [] (__driver_attach) from [] (bus_for_each_dev+0x68/0x9c) > [] (bus_for_each_dev) from [] > (bus_add_driver+0x1a0/0x218) > [] (bus_add_driver) from [] (driver_register+0x78/0xf8) > [] (driver_register) from [] > (i2c_register_driver+0x34/0x84) > [] (i2c_register_driver) from [] > (do_one_initcall+0x40/0x170) > [] (do_one_initcall) from [] > (kernel_init_freeable+0x15c/0x1fc) > [] (kernel_init_freeable) from [] (kernel_init+0x8/0x114) > [] (kernel_init) from [] (ret_from_fork+0x14/0x3c) > ---[ end trace 0919d3d0bc998260 ]--- > [ cut here ] > WARNING: CPU: 0 PID: 1 at > /mnt/ssd/all/work/repos/devel/linux/drivers/regulator/core.c:4072 > regulator_unregister+0xc8/0xd0 > Modules linked in: > CPU: 0 PID: 1 Comm: swapper/0 Tainted: GW > 4.8.0-rc6-00154-g54fe84cbd50b #41 > Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) > [] (unwind_backtrace) from [] (show_stack+0x10/0x14) > [] (show_stack) from [] (dump_stack+0x88/0x9c) > [] (dump_stack) from [] (__warn+0xe8/0x100) > [] (__warn) from [] (warn_slowpath_null+0x20/0x28) > [] (warn_slowpath_null) from [] > (regulator_unregister+0xc8/0xd0) > [] (regulator_unregister) from [] > (release_nodes+0x16c/0x1dc) > [] (release_nodes) from [] > (__device_release_driver+0x8c/0x110) > [] (__device_release_driver) from [] > (device_release_driver+0x1c/0x28) > [] (device_release_driver) from [] > (bus_remove_device+0xd8/0x104) > [] (bus_remove_device) from [] (device_del+0x10c/0x218) > [] (device_del) from [] (platform_device_del+0x1c/0x88) > wm8994 3-001a: Device is not a WM8994, ID is 0 > [ cut here ] > WARNING: CPU: 0 PID: 1 at > /mnt/ssd/all/work/repos/devel/linux/drivers/regulator/core.c:4072 > regulator_unregister+0xc8/0xd0 > Modules linked in: > CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.8.0-rc6-00154-g54fe84cbd50b #41 > Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) > [] (unwind_backtrace) from [] (show_stack+0x10/0x14) > [] (show_stack) from [] (dump_stack+0x88/0x9c) > [] (dump_stack) from [] (__warn+0xe8/0x100) > [] (__warn) from [] (warn_slowpath_null+0x20/0x28) > [] (warn_slowpath_null) from [] > (regulator_unregister+0xc8/0xd0) > [] (regulator_unregister) from [] > (release_nodes+0x16c/0x1dc) > [] (release_nodes) from [] > (__device_release_driver+0x8c/
Re: [PATCH] can: fix warning in bcm_connect/proc_register
On 10/24/2016 10:17 PM, Cong Wang wrote:
> On Mon, Oct 24, 2016 at 1:10 PM, Cong Wang wrote:
>> On Mon, Oct 24, 2016 at 12:11 PM, Oliver Hartkopp
>> wrote:
>>> if (proc_dir) {
>>> /* unique socket address as filename */
>>> sprintf(bo->procname, "%lu", sock_i_ino(sk));
>>> bo->bcm_proc_read = proc_create_data(bo->procname, 0644,
>>> proc_dir,
>>> &bcm_proc_fops, sk);
>>> + if (!bo->bcm_proc_read) {
>>> + ret = -ENOMEM;
>>> + goto fail;
>>> + }
>>
>> Well, I meant we need to call proc_create_data() once per socket,
>> so we need a check before proc_create_data() too.
>
> Hmm, bo->bound should guarantee it, so never mind, your patch
> looks fine.
Can I add your Acked-by?
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917- |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
signature.asc
Description: OpenPGP digital signature
[PATCH v6 5/8] DT:omap3+tsc2007: use new common touchscreen bindings
While we fix the GTA04 we add proper pinmux for the
penirq gpio.
Tested on: GTA04A4 and Pyra-Handheld
Signed-off-by: H. Nikolaus Schaller
---
arch/arm/boot/dts/omap3-gta04.dtsi | 25 +++--
1 file changed, 23 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi
b/arch/arm/boot/dts/omap3-gta04.dtsi
index b3a8b1f..64d6ee3 100644
--- a/arch/arm/boot/dts/omap3-gta04.dtsi
+++ b/arch/arm/boot/dts/omap3-gta04.dtsi
@@ -273,6 +273,13 @@
OMAP3_CORE1_IOPAD(0x2134, PIN_INPUT_PULLUP | MUX_MODE4)
/* gpio112 */
>;
};
+
+ penirq_pins: pinmux_penirq_pins {
+ pinctrl-single,pins = <
+ /* here we could enable to wakeup the cpu from suspend
by a pen touch */
+ OMAP3_CORE1_IOPAD(0x2194, PIN_INPUT_PULLUP | MUX_MODE4)
/* gpio160 */
+ >;
+ };
};
&omap3_pmx_core2 {
@@ -410,10 +417,24 @@
tsc2007@48 {
compatible = "ti,tsc2007";
reg = <0x48>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&penirq_pins>;
interrupt-parent = <&gpio6>;
interrupts = <0 IRQ_TYPE_EDGE_FALLING>; /* GPIO_160 */
- gpios = <&gpio6 0 GPIO_ACTIVE_LOW>;
- ti,x-plate-ohms = <600>;
+ gpios = <&gpio6 0 GPIO_ACTIVE_LOW>; /* GPIO_160 */
+ touchscreen-size-x = <480>;
+ touchscreen-size-y = <640>;
+ touchscreen-max-pressure = <1000>;
+ touchscreen-fuzz-x = <3>;
+ touchscreen-fuzz-y = <8>;
+ touchscreen-fuzz-pressure = <10>;
+ touchscreen-inverted-y;
+ ti,min-x = <0x100>;
+ ti,max-x = <0xf00>;
+ ti,min-y = <0x100>;
+ ti,max-y = <0xf00>;
+ ti,max-rt = <4096>;
+ ti,x-plate-ohms = <550>;
};
/* RFID EEPROM */
--
2.7.3
[PATCH v6 0/8] drivers: touchscreen: tsc2007 and ads7846/tsc2046 improvements (use common touchscreen bindings, pre-calibration, spi fix and provide iio raw values)
Changes V6:
* iio patch (no changes elsewhere)
- tsc2007_iio: fix a missing return 0 for non-iio case (found by kbuid
test robot)
- tsc2007_core: group error return paths so that
tsc2007_iio_unconfigure is called at only one place
- tsc2007_iio: fix copyright (this file is 100% original work)
2016-10-25 21:26:46: Changes V5:
* ads7846: remove an empty line (suggested by Andrew F. Davis )
* ads7846: remove MODULE_ALIAS for SPI (suggested by Andrew F. Davis
)
* tsc2007: fix a bug from swapping patch 3/n and patch 4/n (found by kbuid test
robot)
* refactored tsc2007 into tsc2007_core and tsc2007_iio (asked for by Jonathan
Cameron )
2016-10-17 16:00:02: Changes V4:
* fix a merge/squash issue resulting in a non-bisectable patch set (suggested
by kbuid test robot)
* remove some unnecessary #include (suggested by Jonathan Cameron
)
* make the iio extension depend on CONFIG_IIO rather than selecting it
(suggested by Jonathan Cameron )
* swapped patch 3/n and patch 4/n to remove internal dependency
2016-09-23 14:41:23: Changes V3:
* fix an issue with swapping
* remove hard clipping to min/max rectangle - some systems expect to handle
negative coordinates
* make use of commit ed7c9870c9bc ("Input: of_touchscreen - add support for
inverted / swapped axes")
2015-11-13 21:36:07: Changes V2:
* add a patch to make drivers still recognise the old "ti,swap-xy" property
(suggested by Rob Herring)
2015-11-06 16:14:53: This patch series improves the drivers for the tsc2007 and
ads7846/tsc2046 touchscreen controllers which are e.g. used by the GTA04
OpenPandora and Pyra devices.
New common bindings have been defined by
commit b98abe52fa8e ("Input: add common DT binding for touchscreens"):
Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
which also defines a helper function to parse the DT. These new parameters
allow to specify the fuzz factors (jitter suppression), inversion of x or y
axis and
swapping of x and y to achieve inversion and rotation so that the touch
coordinate axes match the natural orientation of the display panel.
Another improvement is to better use the min/max ADC values and
scale to the screen size as defined by the DT. This allows to coarsely
calibrate the touch to match the LCD to which it is glued on so that the
touch can quite precisely be operated before any user-space fine-calibration
can be (and needs to be) started.
For the adc7846 we fix an issue with the spi module table.
Finally we add an iio interface for the AUX and temperature ADC channels of
the tsc2007 and also provide the touch screen raw values. This allows to read
an optional ambient light sensor installed on the gta04 board and improves
calibration and hardware monitoring.
H. Nikolaus Schaller (8):
drivers:input:tsc2007: add new common binding names, pre-calibration,
flipping and rotation
drivers:input:tsc2007: send pendown and penup only once like
ads7846(+tsc2046) driver does
drivers:input:tsc2007: check for presence and power down tsc2007
during probe
drivers:input:tsc2007: add iio interface to read external ADC input
and temperature
DT:omap3+tsc2007: use new common touchscreen bindings
drivers:input:ads7846(+tsc2046): add new common binding names,
pre-calibration and flipping
drivers:input:ads7846(+tsc2046): fix spi module table
DT:omap3+ads7846: use new common touchscreen bindings
.../devicetree/bindings/input/ads7846.txt | 9 +-
.../bindings/input/touchscreen/tsc2007.txt | 20 +-
arch/arm/boot/dts/omap3-gta04.dtsi | 25 ++-
arch/arm/boot/dts/omap3-lilly-a83x.dtsi| 2 +-
arch/arm/boot/dts/omap3-pandora-common.dtsi| 17 +-
.../boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi| 3 +-
drivers/input/touchscreen/Makefile | 2 +
drivers/input/touchscreen/ads7846.c| 71 +-
drivers/input/touchscreen/tsc2007.h| 129 +++
.../touchscreen/{tsc2007.c => tsc2007_core.c} | 244 -
drivers/input/touchscreen/tsc2007_iio.c| 151 +
include/linux/i2c/tsc2007.h| 8 +
12 files changed, 551 insertions(+), 130 deletions(-)
create mode 100644 drivers/input/touchscreen/tsc2007.h
rename drivers/input/touchscreen/{tsc2007.c => tsc2007_core.c} (70%)
create mode 100644 drivers/input/touchscreen/tsc2007_iio.c
--
2.7.3
Re: CONFIG_VMAP_STACK, on-stack struct, and wake_up_bit
On Thu, Oct 27, 2016 at 10:08:52AM +0200, Peter Zijlstra wrote:
> On Thu, Oct 27, 2016 at 12:07:26AM +0100, Mel Gorman wrote:
> > > but I consider PeterZ's
> > > patch the fix to that, so I wouldn't worry about it.
> > >
> >
> > Agreed. Peter, do you plan to finish that patch?
>
> I was waiting for you guys to hash out the 32bit issue. But if we're now
> OK with having this for 64bit only, I can certainly look at doing a new
> version.
>
I've no problem with it being 64-bit only.
> I'll have to look at fixing Alpha's bitops for that first though,
> because as is that patch relies on atomics to the same word not needing
> ordering, but placing the contended/waiters bit in the high word for
> 64bit only sorta breaks that.
>
I see the problem assuming you're referring to the requirement that locked
and waiter bits are on the same word. Without it, you need a per-arch helper
that forces ordering or takes a spinlock. I doubt it's worth the trouble.
> Hurm, we could of course play games with the layout, the 64bit only
> flags don't _have_ to be at the end.
>
> Something like so could work I suppose, but then there's a slight
> regression in the page_unlock() path, where we now do an unconditional
> spinlock; iow. we loose the unlocked waitqueue_active() test.
>
I can't convince myself it's worthwhile. At least, I can't see a penalty
of potentially moving one of the two bits to the high word. It's the
same cache line and the same op when it matters.
> We could re-instate this with an #ifndef CONFIG_NUMA I suppose.. not
> pretty though.
>
> Also did the s/contended/waiters/ rename per popular request.
>
> ---
> include/linux/page-flags.h | 19
> include/linux/pagemap.h| 25 --
> include/trace/events/mmflags.h |7 +++
> mm/filemap.c | 94
> +
> 4 files changed, 130 insertions(+), 15 deletions(-)
>
> --- a/include/linux/page-flags.h
> +++ b/include/linux/page-flags.h
> @@ -73,6 +73,14 @@
> */
> enum pageflags {
> PG_locked, /* Page is locked. Don't touch. */
> +#ifdef CONFIG_NUMA
> + /*
> + * This bit must end up in the same word as PG_locked (or any other bit
> + * we're waiting on), as per all architectures their bitop
> + * implementations.
> + */
> + PG_waiters, /* The hashed waitqueue has waiters */
> +#endif
> PG_error,
> PG_referenced,
> PG_uptodate,
I don't see why it should be NUMA-specific even though with Linus'
patch, NUMA is a concern. Even then, you still need a 64BIT check
because 32BIT && NUMA is allowed on a number of architectures.
Otherwise, nothing jumped out at me but glancing through it looked very
similar to the previous patch.
--
Mel Gorman
SUSE Labs
[PATCH v6 8/8] DT:omap3+ads7846: use new common touchscreen bindings
The standard touch screen bindings [1] replace the private ti,swap-xy with touchscreen-swaped-x-y. And for the Openpandora we use touchscreen-size etc. to match the LCD screen size. [1]: Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt Tested with OpenPandora. Signed-off-by: H. Nikolaus Schaller --- arch/arm/boot/dts/omap3-lilly-a83x.dtsi | 2 +- arch/arm/boot/dts/omap3-pandora-common.dtsi | 17 + arch/arm/boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi | 3 ++- 3 files changed, 16 insertions(+), 6 deletions(-) diff --git a/arch/arm/boot/dts/omap3-lilly-a83x.dtsi b/arch/arm/boot/dts/omap3-lilly-a83x.dtsi index fa611a5..b8b3864 100644 --- a/arch/arm/boot/dts/omap3-lilly-a83x.dtsi +++ b/arch/arm/boot/dts/omap3-lilly-a83x.dtsi @@ -325,7 +325,7 @@ ti,y-max = /bits/ 16 <3600>; ti,x-plate-ohms = /bits/ 16 <80>; ti,pressure-max = /bits/ 16 <255>; - ti,swap-xy; + touchscreen-swapped-x-y; wakeup-source; }; diff --git a/arch/arm/boot/dts/omap3-pandora-common.dtsi b/arch/arm/boot/dts/omap3-pandora-common.dtsi index b0d1551..d12008a 100644 --- a/arch/arm/boot/dts/omap3-pandora-common.dtsi +++ b/arch/arm/boot/dts/omap3-pandora-common.dtsi @@ -700,10 +700,19 @@ pendown-gpio = <&gpio3 30 GPIO_ACTIVE_HIGH>; vcc-supply = <&vaux4>; - ti,x-min = /bits/ 16 <0>; - ti,x-max = /bits/ 16 <8000>; - ti,y-min = /bits/ 16 <0>; - ti,y-max = /bits/ 16 <4800>; + touchscreen-size-x = <800>; + touchscreen-size-y = <480>; + touchscreen-max-pressure = <1000>; + touchscreen-fuzz-x = <16>; + touchscreen-fuzz-y = <16>; + touchscreen-fuzz-pressure = <10>; + touchscreen-inverted-x; + touchscreen-inverted-y; + + ti,x-min = /bits/ 16 <160>; + ti,x-max = /bits/ 16 <3900>; + ti,y-min = /bits/ 16 <220>; + ti,y-max = /bits/ 16 <3750>; ti,x-plate-ohms = /bits/ 16 <40>; ti,pressure-max = /bits/ 16 <255>; diff --git a/arch/arm/boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi b/arch/arm/boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi index 157345b..3627a63 100644 --- a/arch/arm/boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi +++ b/arch/arm/boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi @@ -66,6 +66,7 @@ ti,x-plate-ohms = /bits/ 16 <40>; ti,pressure-max = /bits/ 16 <255>; ti,swap-xy; - wakeup-source; + touchscreen-swapped-x-y; + linux,wakeup; }; }; -- 2.7.3
Re: [PATCH 9/9] Input: wm97xx: add new AC97 bus support
On Wed, Oct 26, 2016 at 09:41:47PM +0200, Robert Jarzmik wrote: > This adds support for the new AC97 bus code, which discovers the devices > rather than uses platform data. > > As part of this discovery, it enables a multi-function device wm97xx, > which supports touchscreen, battery, ADC and an audio codec. This patch > adds the code to bind the touchscreen "cell" as the touchscreen driver. > > This was tested on the pxa architecture with a pxa270 + wm9713 + the > mioa701 touchscreen. > > Signed-off-by: Robert Jarzmik > --- Acked-by: Charles Keepax Thanks, Charles
Re: [RFC v1 02/14] bus1: provide stub cdev /dev/bus1
On Thursday, October 27, 2016 1:54:05 AM CEST Tom Gundersen wrote:
> On Thu, Oct 27, 2016 at 1:19 AM, Andy Lutomirski wrote:
> > This may have been covered elsewhere, but could this use syscalls instead?
>
> Yes, syscalls would work essentially the same. For now, we are using a
> cdev as it makes it a lot more convenient to develop and test as an
> out-of-tree module, but that could be changed easily before the final
> submission, if that's what we want.
Generally speaking, I think syscalls would be appropriate here, and put
bus1 into a similar category as the other ipc interfaces (shm, msg, sem,
mqueue, ...).
However, syscall API design is nontrivial, and will require a bit of
work to come to a set of syscalls that is fairly compact but also
extensible enough. I think it makes sense to go through the exercise
of working out what the syscall interface would end up looking like,
and then make a decision.
There is currently a set of file operations:
@@ -48,7 +90,11 @@ const struct file_operations bus1_fops = {
.owner = THIS_MODULE,
.open = bus1_fop_open,
.release= bus1_fop_release,
+ .poll = bus1_fop_poll,
.llseek = noop_llseek,
+ .mmap = bus1_fop_mmap,
+ .unlocked_ioctl = bus1_peer_ioctl,
+ .compat_ioctl = bus1_peer_ioctl,
.show_fdinfo= bus1_fop_show_fdinfo,
};
and then another set of ioctls:
+enum {
+ BUS1_CMD_PEER_DISCONNECT= _IOWR(BUS1_IOCTL_MAGIC, 0x00,
+ __u64),
+ BUS1_CMD_PEER_QUERY = _IOWR(BUS1_IOCTL_MAGIC, 0x01,
+ struct bus1_cmd_peer_reset),
+ BUS1_CMD_PEER_RESET = _IOWR(BUS1_IOCTL_MAGIC, 0x02,
+ struct bus1_cmd_peer_reset),
+ BUS1_CMD_HANDLE_RELEASE = _IOWR(BUS1_IOCTL_MAGIC, 0x10,
+ __u64),
+ BUS1_CMD_HANDLE_TRANSFER= _IOWR(BUS1_IOCTL_MAGIC, 0x11,
+ struct bus1_cmd_handle_transfer),
+ BUS1_CMD_NODES_DESTROY = _IOWR(BUS1_IOCTL_MAGIC, 0x20,
+ struct bus1_cmd_nodes_destroy),
+ BUS1_CMD_SLICE_RELEASE = _IOWR(BUS1_IOCTL_MAGIC, 0x30,
+ __u64),
+ BUS1_CMD_SEND = _IOWR(BUS1_IOCTL_MAGIC, 0x40,
+ struct bus1_cmd_send),
+ BUS1_CMD_RECV = _IOWR(BUS1_IOCTL_MAGIC, 0x50,
+ struct bus1_cmd_recv),
+};
I think there is no alternative to having some sort of file descriptor
with the basic operations you have above, but there is a question of
how to get that file descriptor if the ioctls get changed to a syscall,
the basic options being:
- Keep using a chardev. This works, but feels a little odd to me,
and I can't think of any other interfaces combining syscalls with
a chardev.
- Have one syscall that returns an open file descriptor, replacing
the fops->open() function. One advantage is that you can pass
additional arguments in that you can't have with open.
An example for this would be mqueue_open().
- Have a mountable file system, and use open() on that to create
connections. Advantages are that it's fairly easy to have one
instance per fs-namespace, and you can have user-defined naming
of objects in the file system.
For the other operations, the obvious translation would be to
turn each ioctl command into one syscall, but that may not always
be the best representation. One limitation is that you cannot
generally have more than six 'long' arguments on a lot of
architectures, and passing 'u64' arguments to syscalls is awkward.
For some of the commands, the transformation would be straightforward
if we assume that the 'u64' arguments can actually be 'long',
I guess like this:
+struct bus1_cmd_handle_transfer {
+ __u64 flags;
+ __u64 src_handle;
+ __u64 dst_fd;
+ __u64 dst_handle;
+} __attribute__((__aligned__(8)));
long bus1_handle_transfer(int fd, unsigned long handle,
int dst_fd, unsigned long *dst_handle, unsigned int flags);
+struct bus1_cmd_nodes_destroy {
+ __u64 flags;
+ __u64 ptr_nodes;
+ __u64 n_nodes;
+} __attribute__((__aligned__(8)));
long bus1_nodes_destroy(int fd, u64 *ptr_nodes,
long n_nodes, unsigned int flags);
However, the peer_reset would exceed the 6-argument limit when you count
the initial file descriptor even if you assume that 'flags' can be
made 32-bit:
+struct bus1_cmd_peer_reset {
+ __u64 flags;
+ __u64 peer_flags;
+ __u32 max_slices;
+ __u32 max_handles;
+ __u32 max_inflight_bytes;
+ __u32 max_inflight_fds;
+} __attribute__((__aligned__(8)));
maybe something slig
[PATCH 4/4] arm: dts: am57xx-idk-common: Add overide powerhold property
The PMICs have POWERHOLD set by default which prevents PMIC shutdown
even on DEV_CTRL On bit set to 0 as the Powerhold has higher priority.
So to enable pmic power off this property lets one over ride the default
value and enable pmic power off.
Signed-off-by: Keerthy
---
arch/arm/boot/dts/am57xx-idk-common.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/am57xx-idk-common.dtsi
b/arch/arm/boot/dts/am57xx-idk-common.dtsi
index 6d537cf..18297f3 100644
--- a/arch/arm/boot/dts/am57xx-idk-common.dtsi
+++ b/arch/arm/boot/dts/am57xx-idk-common.dtsi
@@ -200,6 +200,7 @@
#interrupt-cells = <2>;
interrupt-controller;
ti,system-power-controller;
+ ti,palmas-override-powerhold;
tps659038_pmic {
compatible = "ti,tps659038-pmic";
--
1.9.1
Re: [PATCH v2 05/11] mpt3sas: Bump driver version as "14.100.00.00"
On 10/26/2016 10:04 AM, Suganath Prabu S wrote: > Signed-off-by: Chaitra P B > Signed-off-by: Sathya Prakash > Signed-off-by: Suganath Prabu S > --- > drivers/scsi/mpt3sas/mpt3sas_base.h | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h > b/drivers/scsi/mpt3sas/mpt3sas_base.h > index e923c91..6f03a86 100644 > --- a/drivers/scsi/mpt3sas/mpt3sas_base.h > +++ b/drivers/scsi/mpt3sas/mpt3sas_base.h > @@ -73,8 +73,8 @@ > #define MPT3SAS_DRIVER_NAME "mpt3sas" > #define MPT3SAS_AUTHOR "Avago Technologies > " > #define MPT3SAS_DESCRIPTION "LSI MPT Fusion SAS 3.0 Device Driver" > -#define MPT3SAS_DRIVER_VERSION "13.100.00.00" > -#define MPT3SAS_MAJOR_VERSION13 > +#define MPT3SAS_DRIVER_VERSION "14.100.00.00" > +#define MPT3SAS_MAJOR_VERSION14 > #define MPT3SAS_MINOR_VERSION100 > #define MPT3SAS_BUILD_VERSION0 > #define MPT3SAS_RELEASE_VERSION 00 > Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes ReineckeTeamlead Storage & Networking h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG Nürnberg)
Re: [PATCH 0/5] mm: workingset: radix tree subtleties & single-page file refaults
On Wed 26-10-16 14:15:09, Johannes Weiner wrote:
> On Wed, Oct 26, 2016 at 11:21:07AM +0200, Jan Kara wrote:
> > On Mon 24-10-16 14:47:39, Johannes Weiner wrote:
> > > From: Johannes Weiner
> > > Date: Mon, 17 Oct 2016 09:00:04 -0400
> > > Subject: [PATCH] mm: workingset: restore single-page file refault tracking
> > >
> > > Currently, we account shadow entries in the page cache in the upper
> > > bits of the radix_tree_node->count, behind the back of the radix tree
> > > implementation. Because the radix tree code has no awareness of them,
> > > we have to prevent shadow entries from going through operations where
> > > the tree implementation relies on or modifies node->count: extending
> > > and shrinking the tree from and to a single direct root->rnode entry.
> > >
> > > As a consequence, we cannot store shadow entries for files that only
> > > have index 0 populated, and thus cannot detect refaults from them,
> > > which in turn degrades the thrashing compensation in LRU reclaim.
> > >
> > > Another consequence is that we rely on subtleties throughout the radix
> > > tree code, such as the node->count != 1 check in the shrinking code,
> > > which is meant to exclude multi-entry nodes but also skips nodes with
> > > only one shadow entry since they are accounted in the upper bits. This
> > > is error prone, and has in fact caused the bug fixed in d3798ae8c6f3
> > > ("mm: filemap: don't plant shadow entries without radix tree node").
> > >
> > > To fix this, this patch moves the shadow counter from the upper bits
> > > of node->count into the new node->exceptional counter, where all
> > > exceptional entries are explicitely tracked by the radix tree.
> > > node->count then counts all tree entries again, including shadows.
> > >
> > > Switching from a magic node->count to accounting exceptional entries
> > > natively in the radix tree code removes the fragile subtleties
> > > mentioned above. It also allows us to store shadow entries for
> > > single-page files again, as the radix tree recognizes exceptional
> > > entries when extending the tree from the root->rnode singleton, and
> > > thus restore refault detection and thrashing compensation for them.
> >
> > I like this solution.
>
> Thanks Jan.
>
> > Just one suggestion: I think radix_tree_replace_slot() can now do
> > the node counter update on its own and that would save us having to
> > do quite a bit of accounting outside of the radix tree code itself
> > and it would be less prone to bugs (forgotten updates of a
> > counter). What do you think?
>
> This would be nice indeed, but it's bigger surgery. We need the node
> in the context of existing users that do slot lookup and replacement,
> which is easier for individual lookups, and harder for gang lookups
> (e.g. drivers/sh/intc/virq.c::intc_subgroup_map). And they'd all get
> more complicated, AFAICS, without even using exceptional entries.
Hum, I agree. But actually looking at e.g. the usage of
radix_tree_replace_slot() in mm/khugepaged.c I think this is even buggy
when replacing a slot referencing a page with NULL without updating
node->count. It is in the error bail-out path so I'm not surprised we did
not stumble over it.
So a relatively easy solution looks like: Create new function like
radix_tree_replace_node_slot() taking both node & slot and updating the
accounting information as needed. Make this function WARN if node is NULL
and accounting information should be updated. Make original
radix_tree_replace_slot() a wrapper around radix_tree_replace_node_slot()
passing NULL as node.
This should provide safe accounting info updates without forcing all users
to work with node pointers...
Honza
--
Jan Kara
SUSE Labs, CR
Re: Getting interrupt every million cache misses
On Thu, Oct 27, 2016 at 10:46:38AM +0200, Pavel Machek wrote: > And actually, printk() is not needed, udelay(50msec) is. Reason is, > that DRAM becomes unreliable if about milion cache misses happen in > under 64msec -- so I'd like to slow the system down in such cases to > prevent bug from biting me. > > (Details are here > https://googleprojectzero.blogspot.cz/2015/03/exploiting-dram-rowhammer-bug-to-gain.html > ). Bug is exploitable to get local root; it is also exploitable to > gain local code execution from javascript... so it is rather severe. Cute, a rowhammer defence. So we can do in-kernel perf events too, see for example kernel/watchdog.c:wd_hw_attr and its users. I suppose you want PERF_COUNT_HW_CACHE_MISSES as config, although depending on platform you could use better (u-arch specific) events.
[PATCH v6 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation
commit b98abe52fa8e ("Input: add common DT binding for touchscreens")
introduced common DT bindings for touchscreens [1] and a helper function to
parse the DT.
commit ed7c9870c9bc ("Input: of_touchscreen - add support for inverted /
swapped axes")
added another helper for parsing axis inversion and swapping
and applying them to x and y coordinates.
Both helpers have been integrated to accommodate any orientation of the
touch panel in relation to the LCD.
A new feature is to introduce scaling the min/max ADC values to the screen
size.
This makes it possible to pre-calibrate the touch so that is (almost)
exactly matches the LCD pixel coordinates it is glued onto. This allows to
well enough operate the touch before a user space calibration step can
improve the precision.
Finally, calculate_pressure has been renamed to calculate_resistance
because that is what it is doing.
[1]: Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
Signed-off-by: H. Nikolaus Schaller
---
.../bindings/input/touchscreen/tsc2007.txt | 20 ++--
drivers/input/touchscreen/tsc2007.c| 120 +
include/linux/i2c/tsc2007.h| 8 ++
3 files changed, 118 insertions(+), 30 deletions(-)
diff --git a/Documentation/devicetree/bindings/input/touchscreen/tsc2007.txt
b/Documentation/devicetree/bindings/input/touchscreen/tsc2007.txt
index ec365e1..6e9fd55 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/tsc2007.txt
+++ b/Documentation/devicetree/bindings/input/touchscreen/tsc2007.txt
@@ -6,6 +6,7 @@ Required properties:
- ti,x-plate-ohms: X-plate resistance in ohms.
Optional properties:
+- generic touch screen properties: see touchscreen binding [2].
- gpios: the interrupt gpio the chip is connected to (trough the penirq pin).
The penirq pin goes to low when the panel is touched.
(see GPIO binding[1] for more details).
@@ -13,17 +14,20 @@ Optional properties:
(see interrupt binding[0]).
- interrupts: (gpio) interrupt to which the chip is connected
(see interrupt binding[0]).
-- ti,max-rt: maximum pressure.
-- ti,fuzzx: specifies the absolute input fuzz x value.
- If set, it will permit noise in the data up to +- the value given to the fuzz
- parameter, that is used to filter noise from the event stream.
-- ti,fuzzy: specifies the absolute input fuzz y value.
-- ti,fuzzz: specifies the absolute input fuzz z value.
+- ti,max-rt: maximum pressure resistance above which samples are ignored
+ (default: 4095).
+- ti,report-resistance: report resistance (no pressure = max_rt) instead
+ of pressure (no pressure = 0).
+- ti,min-x: minimum value reported by X axis ADC (default 0).
+- ti,max-x: maximum value reported by X axis ADC (default 4095).
+- ti,min-y: minimum value reported by Y axis ADC (default 0).
+- ti,max-y: maximum value reported by Y axis ADC (default 4095).
- ti,poll-period: how much time to wait (in milliseconds) before reading again
the
- values from the tsc2007.
+ values from the tsc2007 (default 1).
[0]: Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
[1]: Documentation/devicetree/bindings/gpio/gpio.txt
+[2]: Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
Example:
&i2c1 {
@@ -35,6 +39,8 @@ Example:
interrupts = <0x0 0x8>;
gpios = <&gpio4 0 0>;
ti,x-plate-ohms = <180>;
+ touchscreen-size-x = <640>;
+ touchscreen-size-y = <480>;
};
/* ... */
diff --git a/drivers/input/touchscreen/tsc2007.c
b/drivers/input/touchscreen/tsc2007.c
index 5d0cd51..c1d9593 100644
--- a/drivers/input/touchscreen/tsc2007.c
+++ b/drivers/input/touchscreen/tsc2007.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#define TSC2007_MEASURE_TEMP0 (0x0 << 4)
#define TSC2007_MEASURE_AUX(0x2 << 4)
@@ -74,6 +75,14 @@ struct tsc2007 {
u16 model;
u16 x_plate_ohms;
+
+ struct touchscreen_properties prop;
+
+ boolreport_resistance;
+ u16 min_x;
+ u16 min_y;
+ u16 max_x;
+ u16 max_y;
u16 max_rt;
unsigned long poll_period; /* in jiffies */
int fuzzx;
@@ -128,7 +137,8 @@ static void tsc2007_read_values(struct tsc2007 *tsc, struct
ts_event *tc)
tsc2007_xfer(tsc, PWRDOWN);
}
-static u32 tsc2007_calculate_pressure(struct tsc2007 *tsc, struct ts_event *tc)
+static u32 tsc2007_calculate_resistance(struct tsc2007 *tsc,
+ struct ts_event *tc)
{
u32 rt = 0;
@@ -177,12 +187,13 @@ static irqreturn_t tsc2007_soft_irq(int irq, void *handle)
struct ts_event tc;
u32 rt;
+ de
[PATCH v6 2/8] drivers:input:tsc2007: send pendown and penup only once like ads7846(+tsc2046) driver does
this should reduce unnecessary input events.
Signed-off-by: H. Nikolaus Schaller
---
drivers/input/touchscreen/tsc2007.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/input/touchscreen/tsc2007.c
b/drivers/input/touchscreen/tsc2007.c
index c1d9593..e9d5086 100644
--- a/drivers/input/touchscreen/tsc2007.c
+++ b/drivers/input/touchscreen/tsc2007.c
@@ -94,6 +94,7 @@ struct tsc2007 {
wait_queue_head_t wait;
boolstopped;
+ boolpendown;
int (*get_pendown_state)(struct device *);
void(*clear_penirq)(void);
@@ -227,7 +228,11 @@ static irqreturn_t tsc2007_soft_irq(int irq, void *handle)
sx, sy, rt);
/* report event */
- input_report_key(input, BTN_TOUCH, 1);
+ if (!ts->pendown) {
+ input_report_key(input, BTN_TOUCH, 1);
+ ts->pendown = true;
+ }
+
touchscreen_report_pos(ts->input, &ts->prop,
(unsigned int) sx,
(unsigned int) sy,
@@ -250,9 +255,13 @@ static irqreturn_t tsc2007_soft_irq(int irq, void *handle)
dev_dbg(&ts->client->dev, "UP\n");
- input_report_key(input, BTN_TOUCH, 0);
- input_report_abs(input, ABS_PRESSURE, 0);
- input_sync(input);
+ if (ts->pendown) {
+ input_report_key(input, BTN_TOUCH, 0);
+ input_report_abs(input, ABS_PRESSURE, 0);
+ input_sync(input);
+
+ ts->pendown = false;
+ }
if (ts->clear_penirq)
ts->clear_penirq();
--
2.7.3
Re: [PATCH 1/2] perf, x86-mm: Add exit-fault tracing
On Wed, Oct 26, 2016 at 04:53:39PM -0200, Arnaldo Carvalho de Melo wrote: > > > +++ b/arch/x86/mm/fault.c > > > @@ -1488,6 +1488,7 @@ trace_do_page_fault(struct pt_regs *regs, unsigned > > > long error_code) > > > prev_state = exception_enter(); > > > trace_page_fault_entries(address, regs, error_code); > > > __do_page_fault(regs, error_code, address); > > > + trace_page_fault_exit(address); > > > > Aside from my general hatred of tracepoint, it bugs me that its not > > symmetric like the irq vector ones. But I'll leave that to x86 people. > > What is the simmetry problem, you think we should have: Look at arch/x86/include/asm/trace/irq_vectors.h and $ git grep "trace.*_VECTOR" The entry and exit tracepoints are fully symmetric and generate from a single macro.
Re: [PATCH 0/3] iopmem : A block device for PCIe memory
On Thu, Oct 27, 2016 at 01:22:49PM +0300, Sagi Grimberg wrote: > Christoph, did you manage to leap to the future and solve the > RDMA persistency hole? :) > > e.g. what happens with O_DSYNC in this model? Or you did > a message exchange for commits? Yes, pNFS calls this the layoutcommit. That being said once we get a RDMA commit or flush operation we could easily make the layoutcommit optional for some operations. There already is a precedence for the in the flexfiles layout specification.
Re: [RFC PATCH 02/13] of: Remove excessive printks to reduce clutter
Hi Rob, Frank,
> On Oct 27, 2016, at 15:21 , Rob Herring wrote:
>
> On Tue, Oct 25, 2016 at 3:58 PM, wrote:
>> From: Frank Rowand
>
> Maybe some should be debug?
>
Yes, please do not get rid of them completely.
Leave them at least as debug level so that if there’s a problem
there’s a way to figure out why something happened.
>> Signed-off-by: Frank Rowand
>> ---
>> drivers/of/resolver.c | 28
>> 1 file changed, 28 deletions(-)
>>
>> diff --git a/drivers/of/resolver.c b/drivers/of/resolver.c
>> index 4ff0220d7aa2..93a7ca0bf98c 100644
>> --- a/drivers/of/resolver.c
>> +++ b/drivers/of/resolver.c
>> @@ -116,8 +116,6 @@ static int __of_adjust_phandle_ref(struct device_node
>> *node,
>>
>>propval = kmalloc(rprop->length, GFP_KERNEL);
>>if (!propval) {
>> - pr_err("%s: Could not copy value of '%s'\n",
>> - __func__, rprop->name);
>>return -ENOMEM;
>>}
>
> I would remove the brackets in this patch rather than separately.
>
>>memcpy(propval, rprop->value, rprop->length);
Regards
— Pantelis
Re: [PATCH v2 1/2] staging: lustre: remove broken dead code in cfs_cpt_table_create_pattern
On Tue, Oct 25, 2016 at 11:22:30PM +0200, Arnd Bergmann wrote:
> After a recent bugfix, we get a warning about the use of an uninitialized
> variable:
>
> drivers/staging/lustre/lnet/libcfs/linux/linux-cpu.c: In function
> 'cfs_cpt_table_create_pattern':
> drivers/staging/lustre/lnet/libcfs/linux/linux-cpu.c:833:7: error: 'str' may
> be used uninitialized in this function [-Werror=maybe-uninitialized]
>
> This part of the function used to not do anything as we would reassign
> the 'str' pointer to something else right away, but now we pass an
> uninitialized pointer into 'strchr', which can cause a kernel page fault
> or worse.
>
> Fixes: 239fd5d41f9b ("staging: lustre: libcfs: shortcut to create CPT from
> NUMA topology")
> Signed-off-by: Arnd Bergmann
> ---
> drivers/staging/lustre/lnet/libcfs/linux/linux-cpu.c | 7 ---
> 1 file changed, 7 deletions(-)
Hm, I already applied the v1 versions of these, right? What changed
with these, they seem identical to me...
thanks,
greg k-h
[RFC PATCH v2 2/2] module: When modifying a module's text ignore modules which are going away too
By default, during the access permission modification of a module's core
and init pages, we only ignore modules that are malformed. Albeit for a
module which is going away, it does not make sense to change its text to
RO since the module should be RW, before deallocation.
This patch makes set_all_modules_text_ro() skip modules which are going
away too.
Signed-off-by: Aaron Tomlin
---
kernel/module.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/kernel/module.c b/kernel/module.c
index ff93ab8..2a383df 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -1969,7 +1969,8 @@ void set_all_modules_text_ro(void)
mutex_lock(&module_mutex);
list_for_each_entry_rcu(mod, &modules, list) {
- if (mod->state == MODULE_STATE_UNFORMED)
+ if (mod->state == MODULE_STATE_UNFORMED ||
+ mod->state == MODULE_STATE_GOING)
continue;
frob_text(&mod->core_layout, set_memory_ro);
--
2.5.5
Re: [RFC v1 04/14] bus1: util - fixed list utility library
Hi
On Thu, Oct 27, 2016 at 2:56 PM, Arnd Bergmann wrote:
> On Thursday, October 27, 2016 2:48:46 PM CEST David Herrmann wrote:
>> On Thu, Oct 27, 2016 at 2:37 PM, Peter Zijlstra wrote:
>> > On Wed, Oct 26, 2016 at 09:18:00PM +0200, David Herrmann wrote:
>> >> + e = kmalloc_array(sizeof(*e), BUS1_FLIST_BATCH + 1, gfp);
>> >
>> >> +#define BUS1_FLIST_BATCH (1024)
>> >
>> >> +struct bus1_flist {
>> >> + union {
>> >> + struct bus1_flist *next;
>> >> + void *ptr;
>> >> + };
>> >> +};
>> >
>> > So that's an allocation of 8*(1024+1), or slightly more than 2 pages.
>> >
>> > kmalloc will round up to the next power of two, so you'll end up with an
>> > allocation of 16*1024, wasting a whopping 8184 bytes per such allocation
>> > in slack space.
>> >
>> > Please consider using 1023 or something for your batch size, 511 would
>> > get you to exactly 1 page which would be even better.
>>
>> Thanks for the hint! 511 looks like the obvious choice. Maybe even
>> (PAGE_SIZE / sizeof(long) - 1). I will put a comment next to the
>> definition.
>>
>>
>
> PAGE_SIZE can be up to 64KB though, so that might lead wasting a lot
> of memory.
The bus1-flist implementation never over-allocates. It is a fixed size
list, so it only allocates as much memory as needed. The issue PeterZ
pointed out is passing suitable sizes to kmalloc(), which internally
over-allocates to power-of-2 bounds (or some similar bounds). So we
only ever waste space here if kmalloc() internally rounds up. The code
in bus1-flist allocates exactly the needed space.
Thanks
David
Re: [RFC v1 05/14] bus1: util - pool utility library
On Wed, Oct 26, 2016 at 09:18:01PM +0200, David Herrmann wrote:
> +/* insert slice into the free tree */
> +static void bus1_pool_slice_link_free(struct bus1_pool_slice *slice,
> + struct bus1_pool *pool)
> +{
> + struct rb_node **n, *prev = NULL;
> + struct bus1_pool_slice *ps;
> +
> + n = &pool->slices_free.rb_node;
> + while (*n) {
> + prev = *n;
> + ps = container_of(prev, struct bus1_pool_slice, rb);
> + if (slice->size < ps->size)
> + n = &prev->rb_left;
> + else
> + n = &prev->rb_right;
> + }
> +
> + rb_link_node(&slice->rb, prev, n);
> + rb_insert_color(&slice->rb, &pool->slices_free);
> +}
If you only sort free slices by size, how do you merge contiguous free
slices?
> +/* find free slice big enough to hold @size bytes */
> +static struct bus1_pool_slice *
> +bus1_pool_slice_find_by_size(struct bus1_pool *pool, size_t size)
> +{
> + struct bus1_pool_slice *ps, *closest = NULL;
> + struct rb_node *n;
> +
> + n = pool->slices_free.rb_node;
> + while (n) {
> + ps = container_of(n, struct bus1_pool_slice, rb);
> + if (size < ps->size) {
> + closest = ps;
> + n = n->rb_left;
> + } else if (size > ps->size) {
> + n = n->rb_right;
> + } else /* if (size == ps->size) */ {
> + return ps;
> + }
> + }
> +
> + return closest;
> +}
> +
> +/* find used slice with given offset */
> +static struct bus1_pool_slice *
> +bus1_pool_slice_find_by_offset(struct bus1_pool *pool, size_t offset)
> +{
> + struct bus1_pool_slice *ps;
> + struct rb_node *n;
> +
> + n = pool->slices_busy.rb_node;
> + while (n) {
> + ps = container_of(n, struct bus1_pool_slice, rb);
> + if (offset < ps->offset)
> + n = n->rb_left;
> + else if (offset > ps->offset)
> + n = n->rb_right;
> + else /* if (offset == ps->offset) */
> + return ps;
> + }
> +
> + return NULL;
> +}
I find these two function names misleading. They don't find_by_size or
find_by_offset. They find_free_by_size and find_busy_by_offset. You
could reduce that to find_free and find_busy and have the 'size' and
'offset' in the argument name.
Re: [PATCH v2] mm: remove unnecessary __get_user_pages_unlocked() calls
On Thu, Oct 27, 2016 at 11:27:24AM +0200, Paolo Bonzini wrote: > > > On 27/10/2016 02:12, Andrew Morton wrote: > > > > > >> Subject: [PATCH v2] mm: remove unnecessary __get_user_pages_unlocked() > >> calls > > > > The patch is rather misidentified. > > > >> virt/kvm/async_pf.c | 7 --- > >> virt/kvm/kvm_main.c | 5 ++--- > >> 2 files changed, 6 insertions(+), 6 deletions(-) > > > > It's a KVM patch and should have been called "kvm: remove ...". > > Possibly the KVM maintainers will miss it for this reason. > > I noticed it, but I confused it with "mm: unexport __get_user_pages()". > > I'll merge this through the KVM tree for -rc3. Actually Paolo could you hold off on this? As I think on reflection it'd make more sense to batch this change up with a change to get_user_pages_remote() as suggested by Michal.
[PATCH v2 0/2] backlight: pwm_bl: Fix the initial power state selection
Hi, Changes since v1: - Handling of the enable GPIO is reworked: - Only change direction to output when the pin was input and in this case set the GPIO line physical low - With this change we can ensure that the enable GPIO is output so we do not need to check the direction of it later on. Cover letter: 3698d7e7d221 backlight: pwm_bl: Avoid backlight flicker when probed from DT added support for avoiding backlight flickering, which in essence was designed to not enable the baclkight when the driver loads, but let the user of the backlight to enable it later on. There are boards (like am437x-gp-evm) where we do not have valid GPIO to enable the backlight (TPS61081DRC's EN pin is connected to V3_3D) and the regulator is always on (VBAT in case of the gp-evm). In this board the logic to check the GPIO state and the regulator is failing and the backlight will be enabled as soon as the pwm_bl driver is loaded. By extending the check to look at the PWM state this issue can be avoided and the backlight will be enabled only when it's user is asking it to be enabled. Regards, Peter --- Peter Ujfalusi (2): backlight: pwm_bl: Move the checks for initial power state to a separate function backlight: pwm_bl: Check the pwm state for initial backlight power state drivers/video/backlight/pwm_bl.c | 58 +++- 1 file changed, 39 insertions(+), 19 deletions(-) -- 2.10.1
Re: [RFC PATCH v2 2/2] module: When modifying a module's text ignore modules which are going away too
This looks line to me. Rusty, do you have any issues with this?
Maybe we should add a comment to why a going module shouldn't be
converted to ro (because of ftrace and kprobes). But other than that,
I have no issue with it.
I also added Jessica to the Cc as I notice she will be the new module
maintainer: http://lwn.net/Articles/704653/
-- Steve
On Thu, 27 Oct 2016 10:36:06 +0100
Aaron Tomlin wrote:
> By default, during the access permission modification of a module's core
> and init pages, we only ignore modules that are malformed. Albeit for a
> module which is going away, it does not make sense to change its text to
> RO since the module should be RW, before deallocation.
>
> This patch makes set_all_modules_text_ro() skip modules which are going
> away too.
>
> Signed-off-by: Aaron Tomlin
> ---
> kernel/module.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/module.c b/kernel/module.c
> index ff93ab8..2a383df 100644
> --- a/kernel/module.c
> +++ b/kernel/module.c
> @@ -1969,7 +1969,8 @@ void set_all_modules_text_ro(void)
>
> mutex_lock(&module_mutex);
> list_for_each_entry_rcu(mod, &modules, list) {
> - if (mod->state == MODULE_STATE_UNFORMED)
> + if (mod->state == MODULE_STATE_UNFORMED ||
> + mod->state == MODULE_STATE_GOING)
> continue;
>
> frob_text(&mod->core_layout, set_memory_ro);
Re: [f2fs-dev] [PATCH 04/28] f2fs: replace a build-time warning with runtime WARN_ON
On 2016/10/26 22:57, Arnd Bergmann wrote:
> On Wednesday, October 26, 2016 10:05:00 PM CEST Chao Yu wrote:
>> On 2016/10/18 6:05, Arnd Bergmann wrote:
>>> gcc is unsure about the use of last_ofs_in_node, which might happen
>>> without a prior initialization:
>>>
>>> fs/f2fs//git/arm-soc/fs/f2fs/data.c: In function ‘f2fs_map_blocks’:
>>> fs/f2fs/data.c:799:54: warning: ‘last_ofs_in_node’ may be used
>>> uninitialized in this function [-Wmaybe-uninitialized]
>>>if (prealloc && dn.ofs_in_node != last_ofs_in_node + 1) {
>>
>> In each round of dnode block traverse, we will init 'prealloc' and then
>> update
>> 'prealloc' and 'last_ofs_in_node' together in below lines of f2fs_map_blocks:
>> if (flag == F2FS_GET_BLOCK_PRE_AIO) {
>> if (blkaddr == NULL_ADDR) {
>> prealloc++;
>> last_ofs_in_node = dn.ofs_in_node;
>> }
>> }
>>
>> Then in below codes, it is safe to use 'last_ofs_in_node' since we will check
>> 'prealloc' firstly, so if 'prealloc' is non-zero, 'last_ofs_in_node' must be
>> valid.
>> if (prealloc && dn.ofs_in_node != last_ofs_in_node + 1) {
>>
>> So I think we should not add WARN_ON there.
>
> Ok, that make sense. Thanks for taking a closer look!
>
> Should we just set last_ofs_in_node to the same value as ofs_in_node
> before the loop?
I think it's OK as it can remove warning compiler reports. :)
Thanks,
>
> diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
> index 9ae194f..14db4b7 100644
> --- a/fs/f2fs/data.c
> +++ b/fs/f2fs/data.c
> @@ -716,7 +716,7 @@ int f2fs_map_blocks(struct inode *inode, struct
> f2fs_map_blocks *map,
> }
>
> prealloc = 0;
> - ofs_in_node = dn.ofs_in_node;
> + last_ofs_in_node = ofs_in_node = dn.ofs_in_node;
> end_offset = ADDRS_PER_PAGE(dn.node_page, inode);
>
> next_block:
>
> Arnd
>
> .
>
Re: [PATCH v10 07/19] vfio iommu type1: Update argument of vaddr_get_pfn()
On 10/27/2016 05:29 AM, Kirti Wankhede wrote:
> Update arguments of vaddr_get_pfn() to take struct mm_struct *mm as input
> argument.
>
> Signed-off-by: Kirti Wankhede
> Signed-off-by: Neo Jia
> Change-Id: I885fd4cd4a9f66f4ee2c1caf58267464ec239f52
> ---
> drivers/vfio/vfio_iommu_type1.c | 25 ++---
> 1 file changed, 18 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
> index 72fee415044a..3d916b965492 100644
> --- a/drivers/vfio/vfio_iommu_type1.c
> +++ b/drivers/vfio/vfio_iommu_type1.c
> @@ -228,20 +228,31 @@ static int put_pfn(unsigned long pfn, int prot)
> return 0;
> }
>
> -static int vaddr_get_pfn(unsigned long vaddr, int prot, unsigned long *pfn)
> +static int vaddr_get_pfn(struct mm_struct *remote_mm, unsigned long vaddr,
> + int prot, unsigned long *pfn)
> {
> struct page *page[1];
> struct vm_area_struct *vma;
> + struct mm_struct *mm = (remote_mm ? remote_mm : current->mm);
> int ret = -EFAULT;
>
> - if (get_user_pages_fast(vaddr, 1, !!(prot & IOMMU_WRITE), page) == 1) {
> + if (remote_mm) {
> + down_read(&mm->mmap_sem);
> + ret = get_user_pages_remote(NULL, mm, vaddr, 1,
> + !!(prot & IOMMU_WRITE), 0, page, NULL);
Hi Kirti,
It seems that get_user_pages_remote has only 7 args but you somehow gives 8
here?
--
Thanks,
Jike
> + up_read(&mm->mmap_sem);
> + } else
> + ret = get_user_pages_fast(vaddr, 1,
> + !!(prot & IOMMU_WRITE), page);
> +
> + if (ret == 1) {
> *pfn = page_to_pfn(page[0]);
> return 0;
> }
>
> - down_read(¤t->mm->mmap_sem);
> + down_read(&mm->mmap_sem);
>
> - vma = find_vma_intersection(current->mm, vaddr, vaddr + 1);
> + vma = find_vma_intersection(mm, vaddr, vaddr + 1);
>
> if (vma && vma->vm_flags & VM_PFNMAP) {
> *pfn = ((vaddr - vma->vm_start) >> PAGE_SHIFT) + vma->vm_pgoff;
> @@ -249,7 +260,7 @@ static int vaddr_get_pfn(unsigned long vaddr, int prot,
> unsigned long *pfn)
> ret = 0;
> }
>
> - up_read(¤t->mm->mmap_sem);
> + up_read(&mm->mmap_sem);
>
> return ret;
> }
> @@ -270,7 +281,7 @@ static long vfio_pin_pages(unsigned long vaddr, long
> npage,
> if (!current->mm)
> return -ENODEV;
>
> - ret = vaddr_get_pfn(vaddr, prot, pfn_base);
> + ret = vaddr_get_pfn(NULL, vaddr, prot, pfn_base);
> if (ret)
> return ret;
>
> @@ -293,7 +304,7 @@ static long vfio_pin_pages(unsigned long vaddr, long
> npage,
> for (i = 1, vaddr += PAGE_SIZE; i < npage; i++, vaddr += PAGE_SIZE) {
> unsigned long pfn = 0;
>
> - ret = vaddr_get_pfn(vaddr, prot, &pfn);
> + ret = vaddr_get_pfn(NULL, vaddr, prot, &pfn);
> if (ret)
> break;
>
>
Re: [PATCH v2 1/2] staging: lustre: remove broken dead code in cfs_cpt_table_create_pattern
On Thursday, October 27, 2016 3:12:42 PM CEST Greg Kroah-Hartman wrote:
> On Tue, Oct 25, 2016 at 11:22:30PM +0200, Arnd Bergmann wrote:
> > After a recent bugfix, we get a warning about the use of an uninitialized
> > variable:
> >
> > drivers/staging/lustre/lnet/libcfs/linux/linux-cpu.c: In function
> > 'cfs_cpt_table_create_pattern':
> > drivers/staging/lustre/lnet/libcfs/linux/linux-cpu.c:833:7: error: 'str'
> > may be used uninitialized in this function [-Werror=maybe-uninitialized]
> >
> > This part of the function used to not do anything as we would reassign
> > the 'str' pointer to something else right away, but now we pass an
> > uninitialized pointer into 'strchr', which can cause a kernel page fault
> > or worse.
> >
> > Fixes: 239fd5d41f9b ("staging: lustre: libcfs: shortcut to create CPT from
> > NUMA topology")
> > Signed-off-by: Arnd Bergmann
> > ---
> > drivers/staging/lustre/lnet/libcfs/linux/linux-cpu.c | 7 ---
> > 1 file changed, 7 deletions(-)
>
> Hm, I already applied the v1 versions of these, right? What changed
> with these, they seem identical to me...
The patches you applied were fine, they just had not made it into linux-next
by Tuesday, and I thought they got lost as I had sent them as part of a longer
series and I screwed up one of the two changelogs initially (you applied the
fixed v2 patch I sent immediately afterwards).
Sorry about the confusion.
Arnd
Re: printk badness with VMAP_STACK
Hello, thanks for Cc-ing. On (10/27/16 11:19), Petr Mladek wrote: [..] > Yeah, logbuf_lock is taken on many locations but logbuf_cpu is set > only in vprintk_emit(). It means that the other locations, including > console_unlock() are not protected against this type of recursion. > > There is actually a whole bunch of possible printk-related deadlocks. > There are several approaches how to handle some of them, for example: > > + printk_save(), see > > https://lkml.kernel.org/r/20161018154045.7364-1-sergey.senozhat...@gmail.com > > + async printk, see > > https://lkml.kernel.org/r/1459789048-1337-1-git-send-email-sergey.senozhat...@gmail.com > > + early console, see >https://lkml.kernel.org/r/20161018170830.405990...@infradead.org > > > The more we try to fix them, the more problems we see. Sergey probably > has the best overview about it at the moment. yep. I think I'll re-fresh my printk_safe patch set tonight. it will conflict with Linus' pr_cont() rework, so I'll keep my patch set as a RFC. > We are going to discuss a possible progress on Plumbers next week. yep. I'll prepare some PDF slides :) I'm afraid due to the lack of experience/time/"anything else that is crucially important" I have no idea at the moment if my KS tech-topic proposal [1][2] has been approved or rejected (is KS schedule available somewhere online already? I can't find it) and I absolutely forgot to submit it as a LPC micro-conference as a back-up plan (hm, can people actually do this?). so in the worst case (printk tech-topic is out of KS schedule) we will have to find an empty room on our own (I'm available *any* time). my apologies for any incontinence in advance. [1] https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2016-July/002740.html [2] https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2016-September/004006.html -ss
Re: [PATCH v3] ARM: davinci: da8xx: Fix some redefined symbol warnings
On Thursday 27 October 2016 05:13 PM, Sekhar Nori wrote: > On Wednesday 26 October 2016 06:09 PM, Alexandre Bailon wrote: >> Some macro for DA8xx CFGCHIP are defined in usb-davinci.h, >> but da8xx-cfgchip.h intend to replace them. >> The usb-da8xx.c is using both headers, causing redefined symbol warnings. > > Looks like this is not true for v4.9-rc2 and so I don't see any warnings Ah, just noticed that _this_ is the patch that introduces da8xx-cfgchip.h into usb-da8xx.c. So this is the patch that introduces the warnings (and fixes them). I can queue this for v4.10 (with Greg's ack) if you change the description to make it about cleaning up duplicated defines between da8xx-cfgchip.h and usb-davinci.h and not talk about "redefined symbol warnings". Also, when adding a header file, can you please keep it sorted in alphabetical order. Thanks, Sekhar
Re: [RFC v1 05/14] bus1: util - pool utility library
On Wed, Oct 26, 2016 at 09:18:01PM +0200, David Herrmann wrote:
> +static struct bus1_pool_slice *
> +bus1_pool_slice_free(struct bus1_pool_slice *slice)
> +{
> + if (!slice)
> + return NULL;
> +
> + kfree(slice);
> +
> + return NULL;
> +}
The return value is never used. Which reduces the entire thing to:
kfree(slice);
since kfree() already accepts a NULL.
> + bus1_pool_slice_free(slice);
> + bus1_pool_slice_free(slice);
> + bus1_pool_slice_free(ps);
Re: [RFC PATCH 0/5] Add an overlay manager to handle board capes
Please Cc the maintainers of drivers/of/. + Frank R, Hans, Dmitry S On Wed, Oct 26, 2016 at 9:57 AM, Antoine Tenart wrote: > Hi all, > > Many boards now come with dips and compatible capes; among others the > C.H.I.P, or Beaglebones. All these boards have a kernel implementing an > out-of-tree "cape manager" which is used to detected capes, retrieve > their description and apply a corresponding overlay. This series is an > attempt to start a discussion, with an implementation of such a manager > which is somehow generic (i.e. formats or cape detectors can be added). > Other use cases could make use of this manager to dynamically load dt > overlays based on some input / hw presence. I'd like to see an input source be the kernel command line and/or a DT chosen property. Another overlay manager was proposed not to long ago[1] as well. There's also the Allwinner tablet use case from Hans where i2c devices are probed and detected. That's not using overlays currently, but maybe could. Another thing to consider is different sources of overlays. Besides in the filesystem, overlays could be built into the kernel (already supported), embedded in the dtb (as the other overlay mgr did) or we could extend FDT format to append them. > The proposed design is a library which can be used by detector drivers > to parse headers and load the corresponding overlay. Helpers are > provided for this purpose. The whole thing is divided into 3 entities: > > - The parser which is project-specific (to allow supporting headers > already into the wild). It registers a function parsing an header's > data and filling one or more strings which will be used to find > matching dtbo on the fs. > > - The overlay manager helpers allowing to parse a header to retrieve > the previously mentioned strings and to load a compatible overlay. > > - The detectors which are used to detect capes and get their description > (to be parsed). What about things like power has to be turned on first to detect boards and read their ID? I think this needs to be tied into the driver model. Though, don't go sticking cape mgr nodes into DT. Maybe a driver gets bound to a connector node, but we've got to sort out connector bindings first. > An example of parser and detector is given, compatible with what's done > for the C.H.I.P. As the w1 framework is really bad (and we should > probably do something about that) the detector code is far from being > perfect; but that's not related to what we try to achieve here. > > The actual implementation has a limitation: the detectors cannot be > built-in the kernel image as they would likely detect capes at boot time > but will fail to get their corresponding dt overlays as the fs isn't > mounted yet. The only case this can work is when dt overlays are > built-in firmwares. This isn't an issue for the C.H.I.P. use case right > now. There was a discussion about making an helper to wait for the > rootfs to be mount but the answer was "this is the driver's problem". I thought there are firmware loading calls that will wait. I think this all needs to work asynchronously both for firmware loading and because w1 is really slow. > I'd like to get comments, specifically from people using custom cape > managers, to see if this could fill their needs (with I guess some > modifications). Having 2 would certainly give a better sense this is generic. Rob [1] https://patchwork.ozlabs.org/patch/667805/
Re: [PATCH v3 1/1] kthread: allocate kthread structure using kmalloc
On 10/26, Josh Poimboeuf wrote: > > On Wed, Oct 26, 2016 at 04:14:00PM +0200, Oleg Nesterov wrote: > > +/* > > + * TODO: kill it and use to_kthread(). But we still need the users > > + * like kthread_stop() which has to sync with the exiting kthread. > > + */ > > static struct kthread *to_live_kthread(struct task_struct *k) > > Now that the kthread struct is no longer on the stack, are the > try_get_task_stack() and its corresponding put_task_stack()'s still > needed? It seems you missed this part Of course, with this patch we are ready to remove put_task_stack() from kthread.c right now. The next change should kill to_live_kthread() altogether. in the same email ;) Oleg.
Re: [PATCH] soc: qcom: Add SoC info driver
On 10/26/2016 8:16 PM, Arnd Bergmann wrote: > On Wednesday, October 26, 2016 7:42:08 PM CEST Imran Khan wrote: >> On 10/26/2016 7:35 PM, Arnd Bergmann wrote: > As we are talking about generic soc_device_attribute fields, I was hoping > that > having a vendor field would be helpful as along with family it would > provide > a more thorough information. Also as more than one foundries may be used > for > a soc, can we have a field say foundry_id to provide this information. >>> My first feeling is that this 'vendor' information can should be >>> derived from the family. It's also not clear what would happen >>> to this when a company gets bought. E.g. the Oxnas product family >>> was subsequently owned by Oxford, PLX, Avago and Broadcom, and the >>> mxs family was Sigmatel, Freescale, now NXP and might soon be >>> Qualcomm. What would you put in there in this case? >> >> Okay, not having vendor field is fine for me. Could you also suggest >> something about the foundry_id field. > > This one seems more well-defined, so it's probably ok to add. What > would be the use case of reading this? Would you want to read it > just from user space or also from the kernel? > As of now the use case I can think of, only involve reading this from user space. For example for the same soc, coming from different foundries with different manufacturing process, we may have a situation where some inconsistent h/w behavior is being observed only on parts received from a certain foundry and in those cases this information may help in segregation of problematic socs and may also be used in testing these socs under a different set of settings like voltage, frequency etc. > Maybe this can be combined with a manufacturing process, which probably > falls into a similar category, so we could have something like > "TSMC 28ULP" as a string in there. > Yes. Having a manufacturing process as part of foundry-id can provide a more thorough information. > Arnd > -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a\nmember of the Code Aurora Forum, hosted by The Linux Foundation
[PATCH 1/2] mm: add locked parameter to get_user_pages_remote()
This patch adds a int *locked parameter to get_user_pages_remote() to allow
VM_FAULT_RETRY faulting behaviour similar to get_user_pages_[un]locked().
Taking into account the previous adjustments to get_user_pages*() functions
allowing for the passing of gup_flags, we are now in a position where
__get_user_pages_unlocked() need only be exported for his ability to allow
VM_FAULT_RETRY behaviour, this adjustment allows us to subsequently unexport
__get_user_pages_unlocked() as well as allowing for future flexibility in the
use of get_user_pages_remote().
Signed-off-by: Lorenzo Stoakes
---
drivers/gpu/drm/etnaviv/etnaviv_gem.c | 2 +-
drivers/gpu/drm/i915/i915_gem_userptr.c | 2 +-
drivers/infiniband/core/umem_odp.c | 2 +-
fs/exec.c | 2 +-
include/linux/mm.h | 2 +-
kernel/events/uprobes.c | 4 ++--
mm/gup.c| 12
mm/memory.c | 2 +-
security/tomoyo/domain.c| 2 +-
9 files changed, 17 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
index 0370b84..0c69a97f 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
@@ -763,7 +763,7 @@ static struct page **etnaviv_gem_userptr_do_get_pages(
down_read(&mm->mmap_sem);
while (pinned < npages) {
ret = get_user_pages_remote(task, mm, ptr, npages - pinned,
- flags, pvec + pinned, NULL);
+ flags, pvec + pinned, NULL, NULL);
if (ret < 0)
break;
diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c
b/drivers/gpu/drm/i915/i915_gem_userptr.c
index c6f780f..836b525 100644
--- a/drivers/gpu/drm/i915/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
@@ -522,7 +522,7 @@ __i915_gem_userptr_get_pages_worker(struct work_struct
*_work)
obj->userptr.ptr + pinned * PAGE_SIZE,
npages - pinned,
flags,
-pvec + pinned, NULL);
+pvec + pinned, NULL, NULL);
if (ret < 0)
break;
diff --git a/drivers/infiniband/core/umem_odp.c
b/drivers/infiniband/core/umem_odp.c
index 1f0fe32..6b079a3 100644
--- a/drivers/infiniband/core/umem_odp.c
+++ b/drivers/infiniband/core/umem_odp.c
@@ -578,7 +578,7 @@ int ib_umem_odp_map_dma_pages(struct ib_umem *umem, u64
user_virt, u64 bcnt,
*/
npages = get_user_pages_remote(owning_process, owning_mm,
user_virt, gup_num_pages,
- flags, local_page_list, NULL);
+ flags, local_page_list, NULL, NULL);
up_read(&owning_mm->mmap_sem);
if (npages < 0)
diff --git a/fs/exec.c b/fs/exec.c
index 4e497b9..2cf049d 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -209,7 +209,7 @@ static struct page *get_arg_page(struct linux_binprm *bprm,
unsigned long pos,
* doing the exec and bprm->mm is the new process's mm.
*/
ret = get_user_pages_remote(current, bprm->mm, pos, 1, gup_flags,
- &page, NULL);
+ &page, NULL, NULL);
if (ret <= 0)
return NULL;
diff --git a/include/linux/mm.h b/include/linux/mm.h
index a92c8d7..cc15445 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1274,7 +1274,7 @@ extern int access_remote_vm(struct mm_struct *mm,
unsigned long addr,
long get_user_pages_remote(struct task_struct *tsk, struct mm_struct *mm,
unsigned long start, unsigned long nr_pages,
unsigned int gup_flags, struct page **pages,
- struct vm_area_struct **vmas);
+ struct vm_area_struct **vmas, int *locked);
long get_user_pages(unsigned long start, unsigned long nr_pages,
unsigned int gup_flags, struct page **pages,
struct vm_area_struct **vmas);
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index f9ec9ad..215871b 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -301,7 +301,7 @@ int uprobe_write_opcode(struct mm_struct *mm, unsigned long
vaddr,
retry:
/* Read the page with vaddr into memory */
ret = get_user_pages_remote(NULL, mm, vaddr, 1, FOLL_FORCE, &old_page,
- &vma);
+ &vma, NULL);
if (ret <= 0)
return ret;
@@ -1712,7 +1712,7 @@ static int is_trap_at_addr(struct mm_struct *mm, unsigned
long vaddr)
* essentially a kernel a
Re: [RFC v1 04/14] bus1: util - fixed list utility library
On Thursday, October 27, 2016 2:48:46 PM CEST David Herrmann wrote:
> On Thu, Oct 27, 2016 at 2:37 PM, Peter Zijlstra wrote:
> > On Wed, Oct 26, 2016 at 09:18:00PM +0200, David Herrmann wrote:
> >> + e = kmalloc_array(sizeof(*e), BUS1_FLIST_BATCH + 1, gfp);
> >
> >> +#define BUS1_FLIST_BATCH (1024)
> >
> >> +struct bus1_flist {
> >> + union {
> >> + struct bus1_flist *next;
> >> + void *ptr;
> >> + };
> >> +};
> >
> > So that's an allocation of 8*(1024+1), or slightly more than 2 pages.
> >
> > kmalloc will round up to the next power of two, so you'll end up with an
> > allocation of 16*1024, wasting a whopping 8184 bytes per such allocation
> > in slack space.
> >
> > Please consider using 1023 or something for your batch size, 511 would
> > get you to exactly 1 page which would be even better.
>
> Thanks for the hint! 511 looks like the obvious choice. Maybe even
> (PAGE_SIZE / sizeof(long) - 1). I will put a comment next to the
> definition.
>
>
PAGE_SIZE can be up to 64KB though, so that might lead wasting a lot
of memory.
Arnd
Re: [RFC PATCH 00/13] of: Make drivers/of/resolver.c more readable
Hi Frank, > On Oct 26, 2016, at 00:02 , Frank Rowand wrote: > > On 10/25/16 13:58, frowand.l...@gmail.com wrote: >> From: Frank Rowand >> >> drivers/of/resolve.c is a bit difficult to read. Clean it up so >> that review of future overlay related patches will be easier. > > < snip > > > Hi Pantelis, > > Can you test this patch series on some real hardware? > Sure, I’ll give it whirl today. Been swamped after ELCE but now I have a little bit of time. > Thanks, > > Frank Regards — Pantelis
[PATCH v1] HID: udraw: Add support for the uDraw tablet for PS3
This adds support for the THQ uDraw tablet for the PS3, as
4 separate device nodes, so that user-space can easily consume
events coming from the hardware.
Note that the touchpad two-finger support is fairly unreliable,
and a right-click can only be achieved with a two-finger tap
with the two fingers slightly apart (about 1cm should be enough).
Tested-by: Bastien Nocera
Signed-off-by: Bastien Nocera
---
MAINTAINERS | 6 +
drivers/hid/Kconfig | 7 +
drivers/hid/Makefile| 1 +
drivers/hid/hid-core.c | 1 +
drivers/hid/hid-ids.h | 3 +
drivers/hid/hid-udraw.c | 478
6 files changed, 496 insertions(+)
create mode 100644 drivers/hid/hid-udraw.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 33d7779..57f6bea 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12197,6 +12197,12 @@ S: Maintained
F: Documentation/filesystems/udf.txt
F: fs/udf/
+UDRAW TABLET
+M: Bastien Nocera
+L: linux-in...@vger.kernel.org
+S: Maintained
+F: drivers/hid/hid-udraw.c
+
UFS FILESYSTEM
M: Evgeniy Dushistov
S: Maintained
diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
index cd4599c..88c831e 100644
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -861,6 +861,13 @@ config THRUSTMASTER_FF
a THRUSTMASTER Dual Trigger 3-in-1 or a THRUSTMASTER Ferrari
GT
Rumble Force or Force Feedback Wheel.
+config HID_UDRAW
+ tristate "THQ PS3 uDraw tablet"
+ depends on HID
+ ---help---
+ Say Y here if you want to use the THQ uDraw gaming tablet
for
+ the PS3.
+
config HID_WACOM
tristate "Wacom Intuos/Graphire tablet support (USB)"
depends on HID
diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile
index 86b2b57..d0d9b34 100644
--- a/drivers/hid/Makefile
+++ b/drivers/hid/Makefile
@@ -96,6 +96,7 @@ obj-$(CONFIG_HID_TIVO)+= hid-tivo.o
obj-$(CONFIG_HID_TOPSEED) += hid-topseed.o
obj-$(CONFIG_HID_TWINHAN) += hid-twinhan.o
obj-$(CONFIG_HID_UCLOGIC) += hid-uclogic.o
+obj-$(CONFIG_HID_UDRAW)+= hid-udraw.o
obj-$(CONFIG_HID_LED) += hid-led.o
obj-$(CONFIG_HID_XINMO)+= hid-xinmo.o
obj-$(CONFIG_HID_ZEROPLUS) += hid-zpff.o
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 2b89c70..3611ec7 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -2086,6 +2086,7 @@ static const struct hid_device_id
hid_have_special_driver[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_UCLOGIC,
USB_DEVICE_ID_UCLOGIC_TABLET_WP1062) },
{ HID_USB_DEVICE(USB_VENDOR_ID_UCLOGIC,
USB_DEVICE_ID_UCLOGIC_WIRELESS_TABLET_TWHL850) },
{ HID_USB_DEVICE(USB_VENDOR_ID_UCLOGIC,
USB_DEVICE_ID_UCLOGIC_TABLET_TWHA60) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_THQ,
USB_DEVICE_ID_THQ_PS3_UDRAW) },
{ HID_USB_DEVICE(USB_VENDOR_ID_UCLOGIC,
USB_DEVICE_ID_YIYNOVA_TABLET) },
{ HID_USB_DEVICE(USB_VENDOR_ID_UCLOGIC,
USB_DEVICE_ID_UGEE_TABLET_81) },
{ HID_USB_DEVICE(USB_VENDOR_ID_UCLOGIC,
USB_DEVICE_ID_UGEE_TABLET_45) },
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index cd59c79..4ff9ecc 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -955,6 +955,9 @@
#define USB_VENDOR_ID_THINGM 0x27b8
#define USB_DEVICE_ID_BLINK1 0x01ed
+#define USB_VENDOR_ID_THQ 0x20d6
+#define USB_DEVICE_ID_THQ_PS3_UDRAW0xcb17
+
#define USB_VENDOR_ID_THRUSTMASTER 0x044f
#define USB_VENDOR_ID_TIVO 0x150a
diff --git a/drivers/hid/hid-udraw.c b/drivers/hid/hid-udraw.c
new file mode 100644
index 000..794aae5
--- /dev/null
+++ b/drivers/hid/hid-udraw.c
@@ -0,0 +1,478 @@
+/*
+ * HID driver for THQ PS3 uDraw tablet
+ *
+ * Copyright (C) 2016 Red Hat Inc. All Rights Reserved
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation,
and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include "hid-ids.h"
+
+MODULE_AUTHOR("Bastien Nocera ");
+MODULE_DESCRIPTION("PS3 uDraw tablet driver");
+MODULE_LICENSE("GPL");
+
+/*
+ * Protocol information from:
+ * http://brandonw.net/udraw/
+ * and the source code of:
+ * https://.org/contribution/udraw-hid
+ */
+
+/*
+ * The device is setup with multiple input devices to make it easier
+ * to handle in user-space:
+ * - the touch area which works as a touchpad
+ * - the tablet area which works as a touchpad/drawing tablet
+ * - a joypad with a d-pad, and 7 buttons
+ * - an accelerometer device
+ */
+
+enum {
+ TOUCH_NONE,
+ TOUCH_PEN,
+ TOUCH_FINGER,
+
[PATCH v2] USB: OHCI: make ohci-da8xx a separate driver
From: Manjunath Goudar
Separate the Davinci OHCI host controller driver from ohci-hcd
host code so that it can be built as a separate driver module.
This work is part of enabling multi-platform kernels on ARM
Tested-by: David Lechner
Signed-off-by: Manjunath Goudar
[Axel: adapted and rebased, fixed minor comments]
Signed-off-by: Axel Haslam
---
This was a previews patch submited by Manjunath [1]
that was never taken in because of an undefined symbol
when loading as a module. That symbol is not present anymore
so we can safly build the driver as a module.
I rebased, fixing the minor remaining comments.
V1->V2
* changed hdc_name to a #define and use it in MODE_ALIAS (David)
* Added tested-by tag from David
http://patches.linaro.org/patch/18234/
drivers/usb/host/Kconfig | 4 +-
drivers/usb/host/Makefile | 1 +
drivers/usb/host/ohci-da8xx.c | 182 --
drivers/usb/host/ohci-hcd.c | 18 -
4 files changed, 74 insertions(+), 131 deletions(-)
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 83b6cec..6361fc7 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -479,9 +479,9 @@ config USB_OHCI_HCD_OMAP3
OMAP3 and later chips.
config USB_OHCI_HCD_DAVINCI
- bool "OHCI support for TI DaVinci DA8xx"
+ tristate "OHCI support for TI DaVinci DA8xx"
depends on ARCH_DAVINCI_DA8XX
- depends on USB_OHCI_HCD=y
+ depends on USB_OHCI_HCD
select PHY_DA8XX_USB
default y
help
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 6ef785b..2644537 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -61,6 +61,7 @@ obj-$(CONFIG_USB_OHCI_HCD_AT91) += ohci-at91.o
obj-$(CONFIG_USB_OHCI_HCD_S3C2410) += ohci-s3c2410.o
obj-$(CONFIG_USB_OHCI_HCD_LPC32XX) += ohci-nxp.o
obj-$(CONFIG_USB_OHCI_HCD_PXA27X) += ohci-pxa27x.o
+obj-$(CONFIG_USB_OHCI_HCD_DAVINCI) += ohci-da8xx.o
obj-$(CONFIG_USB_UHCI_HCD) += uhci-hcd.o
obj-$(CONFIG_USB_FHCI_HCD) += fhci.o
diff --git a/drivers/usb/host/ohci-da8xx.c b/drivers/usb/host/ohci-da8xx.c
index 3656d7c..30c4878 100644
--- a/drivers/usb/host/ohci-da8xx.c
+++ b/drivers/usb/host/ohci-da8xx.c
@@ -11,16 +11,29 @@
* kind, whether express or implied.
*/
+#include
+#include
#include
#include
+#include
+#include
#include
-#include
#include
#include
+#include
+#include
+#include
-#ifndef CONFIG_ARCH_DAVINCI_DA8XX
-#error "This file is DA8xx bus glue. Define CONFIG_ARCH_DAVINCI_DA8XX."
-#endif
+#include "ohci.h"
+
+#define DRIVER_DESC "DA8XX"
+#define DRV_NAME "ohci"
+
+static struct hc_driver __read_mostly ohci_da8xx_hc_driver;
+
+static int (*orig_ohci_hub_control)(struct usb_hcd *hcd, u16 typeReq,
+ u16 wValue, u16 wIndex, char *buf, u16 wLength);
+static int (*orig_ohci_hub_status_data)(struct usb_hcd *hcd, char *buf);
static struct clk *usb11_clk;
static struct phy *usb11_phy;
@@ -74,7 +87,7 @@ static void ohci_da8xx_ocic_handler(struct
da8xx_ohci_root_hub *hub,
hub->set_power(port, 0);
}
-static int ohci_da8xx_init(struct usb_hcd *hcd)
+static int ohci_da8xx_reset(struct usb_hcd *hcd)
{
struct device *dev = hcd->self.controller;
struct da8xx_ohci_root_hub *hub = dev_get_platdata(dev);
@@ -94,7 +107,7 @@ static int ohci_da8xx_init(struct usb_hcd *hcd)
*/
ohci->num_ports = 1;
- result = ohci_init(ohci);
+ result = ohci_setup(hcd);
if (result < 0) {
ohci_da8xx_disable();
return result;
@@ -122,30 +135,12 @@ static int ohci_da8xx_init(struct usb_hcd *hcd)
return result;
}
-static void ohci_da8xx_stop(struct usb_hcd *hcd)
-{
- ohci_stop(hcd);
- ohci_da8xx_disable();
-}
-
-static int ohci_da8xx_start(struct usb_hcd *hcd)
-{
- struct ohci_hcd *ohci = hcd_to_ohci(hcd);
- int result;
-
- result = ohci_run(ohci);
- if (result < 0)
- ohci_da8xx_stop(hcd);
-
- return result;
-}
-
/*
* Update the status data from the hub with the over-current indicator change.
*/
static int ohci_da8xx_hub_status_data(struct usb_hcd *hcd, char *buf)
{
- int length = ohci_hub_status_data(hcd, buf);
+ int length = orig_ohci_hub_status_data(hcd, buf);
/* See if we have OCIC bit set on port 1 */
if (ocic_mask & (1 << 1)) {
@@ -227,66 +222,13 @@ static int ohci_da8xx_hub_control(struct usb_hcd *hcd,
u16 typeReq, u16 wValue,
}
}
- return ohci_hub_control(hcd, typeReq, wValue, wIndex, buf, wLength);
+ return orig_ohci_hub_control(hcd, typeReq, wValue,
+ wIndex, buf, wLength);
}
-static const struct hc_driver ohci_da8xx_hc_driver = {
- .description= hcd_name,
- .product_desc = "DA8xx OHCI",
-
Re: [PATCH 0/2] mm: unexport __get_user_pages_unlocked()
On Thu, Oct 27, 2016 at 10:51:39AM +0100, Lorenzo Stoakes wrote: > This patch series continues the cleanup of get_user_pages*() functions taking > advantage of the fact we can now pass gup_flags as we please. Note that this patch series has an unfortunate trivial dependency on my recent 'fix up get_user_pages* comments' patch which means this series applies against -mmots but not mainline at this point in time.
Re: [Qemu-devel] [PATCH v9 04/12] vfio iommu: Add support for mediated devices
On 10/27/2016 12:50 PM, Alexey Kardashevskiy wrote: > On 18/10/16 08:22, Kirti Wankhede wrote: >> VFIO IOMMU drivers are designed for the devices which are IOMMU capable. >> Mediated device only uses IOMMU APIs, the underlying hardware can be >> managed by an IOMMU domain. >> >> Aim of this change is: >> - To use most of the code of TYPE1 IOMMU driver for mediated devices >> - To support direct assigned device and mediated device in single module >> >> Added two new callback functions to struct vfio_iommu_driver_ops. Backend >> IOMMU module that supports pining and unpinning pages for mdev devices >> should provide these functions. >> Added APIs for pining and unpining pages to VFIO module. These calls back >> into backend iommu module to actually pin and unpin pages. >> >> This change adds pin and unpin support for mediated device to TYPE1 IOMMU >> backend module. More details: >> - When iommu_group of mediated devices is attached, task structure is >> cached which is used later to pin pages and page accounting. > > > For SPAPR TCE IOMMU driver, I ended up caching mm_struct with > atomic_inc(&container->mm->mm_count) (patches are on the way) instead of > using @current or task as the process might be gone while VFIO container is > still alive and @mm might be needed to do proper cleanup; this might not be > an issue with this patchset now but still you seem to only use @mm from > task_struct. > Consider the example of QEMU process which creates VFIO container, QEMU in its teardown path would release the container. How could container be alive when process is gone? Kirti > > >> - It keeps track of pinned pages for mediated domain. This data is used to >> verify unpinning request and to unpin remaining pages while detaching, if >> there are any. >> - Used existing mechanism for page accounting. If iommu capable domain >> exist in the container then all pages are already pinned and accounted. >> Accouting for mdev device is only done if there is no iommu capable >> domain in the container. >> - Page accouting is updated on hot plug and unplug mdev device and pass >> through device. >> >> Tested by assigning below combinations of devices to a single VM: >> - GPU pass through only >> - vGPU device only >> - One GPU pass through and one vGPU device >> - Linux VM hot plug and unplug vGPU device while GPU pass through device >> exist >> - Linux VM hot plug and unplug GPU pass through device while vGPU device >> exist >> >> Signed-off-by: Kirti Wankhede >> Signed-off-by: Neo Jia >> Change-Id: I295d6f0f2e0579b8d9882bfd8fd5a4194b97bd9a > >
Re: [PATCH 4/5] ARM: davinci: enable LEDs default-on trigger in default config
On Saturday 22 October 2016 12:06 AM, David Lechner wrote: > The LEDs default-on trigger is nice to have. For example, it can be used > to configure a LED as a power indicator. > > Signed-off-by: David Lechner > --- > arch/arm/configs/davinci_all_defconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm/configs/davinci_all_defconfig > b/arch/arm/configs/davinci_all_defconfig > index 9d7f0bc..e380743 100644 > --- a/arch/arm/configs/davinci_all_defconfig > +++ b/arch/arm/configs/davinci_all_defconfig > @@ -181,6 +181,7 @@ CONFIG_LEDS_GPIO=m > CONFIG_LEDS_TRIGGERS=y > CONFIG_LEDS_TRIGGER_TIMER=m > CONFIG_LEDS_TRIGGER_HEARTBEAT=m > +CONFIG_LEDS_TRIGGER_DEFAULT_ON=y Can this be module like rest of the triggers? It will come on later, but not sure if you care about the difference that much. Having it a module will be better for those boards that don't need it. Thanks, Sekhar
Re: multi-threads libvmmalloc fork test hang
Thanks for the report. I'll try to reproduce it... Honza On Thu 27-10-16 19:22:30, Xiong Zhou wrote: > # description > > nvml test suite vmmalloc_fork test hang. > > $ ps -eo stat,comm | grep vmma > S+ vmmalloc_fork > Sl+ vmmalloc_fork > Z+ vmmalloc_fork > Sl+ vmmalloc_fork > Z+ vmmalloc_fork > Z+ vmmalloc_fork > Sl+ vmmalloc_fork > Z+ vmmalloc_fork > Z+ vmmalloc_fork > Z+ vmmalloc_fork > > dmesg: > > [ 250.499097] INFO: task vmmalloc_fork:9805 blocked for more than 120 > seconds. > [ 250.530667] Not tainted 4.9.09fe68ca+ #27 > [ 250.550901] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables > this message. > [ 250.585752] vmmalloc_fork D[ 250.598362] 8171813c 0 9805 > 9765 0x0080 > [ 250.623445] 88075dc68f80[ 250.636052] > 88076058db00 88017c5b 880763b19340[ 250.668510] > c9000fe1bbb0 8171813c c9000fe1bc20 c9000fe1bbe0[ > 250.704220] 82248898 88076058db00 82248898Call Trace: > [ 250.738382] [] ? __schedule+0x21c/0x6a0 > [ 250.763404] [] schedule+0x36/0x80 > [ 250.786177] [] get_unlocked_mapping_entry+0xc1/0x120 > [ 250.815869] [] ? iomap_dax_rw+0x110/0x110 > [ 250.841350] [] grab_mapping_entry+0x4a/0x220 > [ 250.868442] [] iomap_dax_fault+0xa9/0x3b0 > [ 250.894437] [] xfs_filemap_fault+0xce/0xf0 [xfs] > [ 250.922805] [] __do_fault+0x79/0x100 > [ 250.947035] [] do_fault+0x49b/0x690 > [ 250.970964] [] ? xfs_filemap_pmd_fault+0x9c/0x160 [xfs] > [ 251.001812] [] handle_mm_fault+0x61a/0xa50 > [ 251.027736] [] __do_page_fault+0x22a/0x4a0 > [ 251.053700] [] do_page_fault+0x30/0x80 > [ 251.077962] [] ? do_syscall_64+0x175/0x180 > [ 251.103835] [] page_fault+0x28/0x30 > > > # kernel versions: > > v4.6 pass in seconds > v4.7 hang > v4.9-rc1 hang > Linus tree to commit 9fe68ca hang > > bisect points to > first bad commit: [ac401cc782429cc8560ce4840b1405d603740917] dax: New fault > locking > > v4.7 with these 3 commits reverted pass: > 4d9a2c8 - Jan Kara, 6 months ago : dax: Remove i_mmap_lock protection > bc2466e - Jan Kara, 6 months ago : dax: Use radix tree entry lock to protect > cow faults > ac401cc - Jan Kara, 6 months ago : dax: New fault locking > > # nvml version: > https://github.com/pmem/nvml.git > to commit: > feab4d6f65102139ce460890c898fcad09ce20ae > > # How reproducible: > always > > # Test steps: > > > > $cd nvml > $make install -j64 > > $cat > src/test/testconfig.sh < PMEM_FS_DIR=/daxmnt > NON_PMEM_FS_DIR=/tmp > EOF > > $mkfs.xfs /dev/pmem0 > $mkdir -p /daxmnt/ > $mount -o dax /dev/pmem0 /daxmnt/ > > $make -C src/test/vmmalloc_fork/ TEST_TIME=60m clean > $make -C src/test/vmmalloc_fork/ TEST_TIME=60m check > $umount /daxmnt -- Jan Kara SUSE Labs, CR
Re: Build regressions/improvements in v4.9-rc1
Hi Thomas, Michael, On Thu, 2016-10-27 at 09:07 +0200, Thomas Petazzoni wrote: > Hello, > > On Thu, 27 Oct 2016 10:56:02 +1100, Michael Ellerman wrote: > > > > > > > > > Hm... that's strange - it used to work but doesn't work with newer > > > Buildroot... > > > > > > Anyways if something very simple (i.e. with no extra libraries) works for > > > you just go > > > ahead and grab pre-built image that Thomas Petazzoni builds. > > > > > > That's the most recent one: > > > http://autobuild.buildroot.org/toolchains/tarballs/br-arcle-hs38-full-2016.08-613-ge98b4dd.tar.bz2 > > > > > > > Thanks, I grabbed that and it works for axs103_smp_defconfig: > > > > http://kisskb.ellerman.id.au/kisskb/buildresult/12840656/ > > > > > > It doesn't work for axs101_defconfig, saying: > > > > arch/arc/Makefile:29: *** Toolchain not configured for ARCompact builds. > > Stop. > > axs101 is using a 770 core, while the toolchain is built for the HS38 > core. I'm somewhat surprised that a single ARC toolchain cannot produce > code for both 770 and HS38, but it seems to be the case. > > So you need a separate toolchain for ARC770. Indeed axs101 uses ARC770 core which is ARCv1 AKA ARCompact ISA while axs103 sports the same base-board but CPU daughter-card contains ARC HS38 core which has ARCv2 ISA (binary incompatible with ARCompact). Essentially both gcc and binutils will happily build for both architectures given proper options were passed on the command line. But Linux kernel gets linked with pre-built libgcc (it is a part of toolchain). And so it all boils down to a requirement to have multilibbed uClibc toolchain. Which we don't have. I think we discussed it a couple of times already and probably at some point will have it but for now we have to use 2 different toolchains for ARCompact and ARCv2 cores. I hope explanation above makes some sense. -Alexey
Re: [GIT PULL] kbuild changes for v4.9-rc1
Nicholas Piggin writes: > On Thu, 27 Oct 2016 11:10:03 +0300 > Kalle Valo wrote: > >> (Adding Thorsten because of a serious regression and Steven because he >> tried to fix something in the same commit) >> >> Nicholas Piggin writes: >> >> > On Wed, 19 Oct 2016 16:38:14 +0200 >> > Michal Marek wrote: >> > >> >> Dne 18.10.2016 v 03:34 Nicholas Piggin napsal(a): >> >> > We should probably just bring all these arch patches through the >> >> > kbuild tree. >> >> > >> >> > I'm sorry for the breakage: I didn't realize it broke the build with >> >> > some configs, otherwise I would have given Michal a heads up before >> >> > his pull request, and worked to get this stuff in first. >> >> >> >> It breaks with some binutils versions only (and only with >> >> CONFIG_MODVERSIONS=y, of course). >> > >> > Yeah this seems to be the issue, it apparently slipped past all the >> > automated builds. It seems like the existing CRC warnings in the tree >> > only trigger in rare circumstances too, so something could be a bit >> > fragile there. >> >> I upgraded from 4.8 to 4.9-rc2 and noticed that kernel modules fail to >> load (log below). After investigating for some time I found this thread >> and apparently this is not still fixed, at least not in Linus' tree. >> >> Reverting 784d5699eddc5 fixed the issue for me. As I don't see any fix >> available (please correct me if I'm wrong) we should just revert that >> commit until it's properly fixed. > > With these two patches together, does it work for you? > > http://marc.info/?l=linux-arch&m=147653546809512&w=2 > http://marc.info/?l=linux-kernel&m=147669851906489&w=2 > > It would be helpful if you could test and let us know, because there seems > to be a very tiny number of configs and toolchains that causes > problems. With these two patches (on top of ath-201610251249 from ath.git, in practice 4.9-rc2 + latest wireless patches) module loading works again. If you want you can add my Tested-by: Tested-by: Kalle Valo Can we get these patches to Linus' tree soon? It's annoying to revert 784d5699eddc5 everytime I update my tree. >> Also note that there's a related fix from Steven: >> >> [PATCH] x86: Fix export for mcount and __fentry__ >> https://marc.info/?l=linux-kernel&m=147733572502413 >> >> For compiling the kernel I'm using Ubuntu 12.04: >> >> ii binutils 2.22-6ubuntu1.4 GNU assembler, linker and >> binary utilities >> ii gcc 4:4.6.3-1ubuntu5 GNU C compiler >> >> The kernel is running on a separate machine with Ubuntu 14.04. >> >> [ 110.703414] bluetooth: disagrees about version of symbol __get_user_2 >> [ 110.703416] bluetooth: Unknown symbol __get_user_2 (err -22) >> [ 110.703429] bluetooth: disagrees about version of symbol __put_user_2 >> [ 110.703430] bluetooth: Unknown symbol __put_user_2 (err -22) >> [ 110.703579] bluetooth: disagrees about version of symbol __put_user_4 >> [ 110.703580] bluetooth: Unknown symbol __put_user_4 (err -22) >> [ 110.703669] bluetooth: disagrees about version of symbol __put_user_1 >> [ 110.703670] bluetooth: Unknown symbol __put_user_1 (err -22) >> [ 110.703688] bluetooth: disagrees about version of symbol mcount >> [ 110.703689] bluetooth: Unknown symbol mcount (err -22) >> > > I haven't seen that one before. Did you definitely make and install new > modules? I'm pretty sure modules are correctly installed as I have used the same procedure for years: on my workstation I do 'make bindeb-pkg', copy the .deb to the test laptop and install the deb there. Also once I revert 784d5699eddc5 it starts immeadiately working. -- Kalle Valo
Re: [PATCH] soc: qcom: Add SoC info driver
On Thursday, October 27, 2016 6:40:27 PM CEST Imran Khan wrote: > On 10/26/2016 8:16 PM, Arnd Bergmann wrote: > > On Wednesday, October 26, 2016 7:42:08 PM CEST Imran Khan wrote: > >> On 10/26/2016 7:35 PM, Arnd Bergmann wrote: > > As we are talking about generic soc_device_attribute fields, I was > > hoping that > > having a vendor field would be helpful as along with family it would > > provide > > a more thorough information. Also as more than one foundries may be > > used for > > a soc, can we have a field say foundry_id to provide this information. > >>> My first feeling is that this 'vendor' information can should be > >>> derived from the family. It's also not clear what would happen > >>> to this when a company gets bought. E.g. the Oxnas product family > >>> was subsequently owned by Oxford, PLX, Avago and Broadcom, and the > >>> mxs family was Sigmatel, Freescale, now NXP and might soon be > >>> Qualcomm. What would you put in there in this case? > >> > >> Okay, not having vendor field is fine for me. Could you also suggest > >> something about the foundry_id field. > > > > This one seems more well-defined, so it's probably ok to add. What > > would be the use case of reading this? Would you want to read it > > just from user space or also from the kernel? > > > > As of now the use case I can think of, only involve reading this from user > space. For example for the same soc, coming from different foundries with > different manufacturing process, we may have a situation where some > inconsistent > h/w behavior is being observed only on parts received from a certain foundry > and in those cases this information may help in segregation of problematic > socs > and may also be used in testing these socs under a different set of settings > like > voltage, frequency etc. > > > Maybe this can be combined with a manufacturing process, which probably > > falls into a similar category, so we could have something like > > "TSMC 28ULP" as a string in there. > > > > Yes. Having a manufacturing process as part of foundry-id can provide a more > thorough information. Ok, sounds good. Let's do it like this. We can always add support for in-kernel matching of this string if needed later. Arnd
Re: [PATCH v12 1/5] Input: goodix - add sysfs interface to dump config
On Sat, 2016-09-10 at 20:57 +0300, Irina Tirdea wrote:
> Goodix devices have a configuration information register area that
> specifies various parameters for the device. The configuration
> information
> has a specific format described in the Goodix datasheet. It includes
> X/Y
> resolution, maximum supported touch points, interrupt flags, various
> sesitivity factors and settings for advanced features (like gesture
> recognition).
>
> Export a sysfs interface that would allow reading the configuration
> information. The default device configuration can be used as a
> starting
> point for creating a valid configuration firmware used by the device
> at
> init time to update its configuration.
>
> This sysfs interface will be exported only if the gpio pins are
> properly
> initialized from ACPI/DT.
Reviewed-by: Bastien Nocera
Only thing I don't like is the overly complicated bash script. I'd
really rather the code was in C, making it easier to debug, and not
rely on a fair number of external utilities.
>
> Signed-off-by: Irina Tirdea
> ---
> Documentation/input/goodix.txt | 84
> ++
> drivers/input/touchscreen/goodix.c | 64 ++
> ---
> 2 files changed, 143 insertions(+), 5 deletions(-)
> create mode 100644 Documentation/input/goodix.txt
>
> diff --git a/Documentation/input/goodix.txt
> b/Documentation/input/goodix.txt
> new file mode 100644
> index 000..f9be1e2
> --- /dev/null
> +++ b/Documentation/input/goodix.txt
> @@ -0,0 +1,84 @@
> +Goodix touchscreen driver
> +=
> +
> +How to update configuration firmware
> +=
> +
> +Goodix touchscreen devices have a set of registers that specify
> configuration
> +information for the device. The configuration information has a
> specific format
> +described in the Goodix datasheet. It includes X/Y resolution,
> maximum
> +supported touch points, interrupt flags, various sesitivity factors
> and
> +settings for advanced features (like gesture recognition).
> +
> +The devices have an initial default configuration that can be read
> through
> +the sysfs interface (/sys/class/input/inputX/device/dump_config).
> This default
> +configuration can be used as a starting point for creating a new
> configuration
> +firmware file. At init, the driver will read the configuration
> firmware file
> +and update the device configuration.
> +
> +This configuration can be accesed only if both interrupt and reset
> gpio pins
> +are connected and properly configured through ACPI _DSD/DT
> properties.
> +
> +Below are instructions on how to generate a valid configuration
> starting from
> +the device default configuration.
> +
> +1. Dump the default configuration of the device to a file:
> + $ cat /sys/class/input/inputX/device/dump_config >
> goodix__cfg
> +
> +2. Make the needed changes to the configuration (e.g. change
> resolution of
> +x/y axes, maximum reported touch points, switch X,Y axes, etc.). For
> more
> +details check the Goodix datasheet for format of Configuration
> Registers.
> +
> +3. Generate a valid configuration starting from goodix__cfg.
> +After making changes, you need to recompute the checksum of the
> entire
> +configuration data, set Config_Fresh to 1 and generate the binary
> config
> +firmware image. This can be done using a helper script similar to
> the
> +one below:
> +
> +#!/bin/bash
> +
> +if [[ $# -lt 1 ]]; then
> +echo "$0 fw_filename"
> +exit 1
> +fi
> +
> +file_in="$1"
> +file_out_bin=${file_in}.bin
> +
> +print_val ()
> +{
> +val="$1"
> +printf "0x%.2x" "$val" | xxd -r -p >> ${file_out_bin}
> +}
> +
> +rm -f ${file_out_bin}
> +
> +size=`cat ${file_in} | wc -w`
> +
> +checksum=0
> +i=1
> +for val in `cat ${file_in}`; do
> +val="0x$val"
> +if [[ $i == $size ]]; then
> + # Config_Fresh
> + print_val 0x01
> +elif [[ $i == $((size-1)) ]]; then
> + # Config_Chksum
> + checksum=$(( (~ checksum + 1) & 0xFF))
> + print_val $checksum
> +else
> + checksum=$((checksum + val))
> + print_val $val
> +fi
> +i=$((i+1))
> +done
> +
> +echo "Wrote ${file_out_bin}"
> +
> +4. Copy the binary config firmware in the appropriate location
> +(e.g. /lib/firmware), using the name goodix__cfg.bin (e.g.
> for gt911,
> +use goodix_911_cfg.bin).
> +
> +5. Check that the new firmware was successfully written to the
> device
> +after reboot. Config_Fresh is reset to 0 after a successful update
> of the
> +configuration.
> diff --git a/drivers/input/touchscreen/goodix.c
> b/drivers/input/touchscreen/goodix.c
> index 240b16f..2447b73 100644
> --- a/drivers/input/touchscreen/goodix.c
> +++ b/drivers/input/touchscreen/goodix.c
> @@ -430,6 +430,40 @@ static int goodix_reset(struct goodix_ts_data
> *ts)
> return 0;
> }
>
> +static ssize_t goodix_dump_config_show(struct device *dev,
> + struct device_attribute
> *attr, char *bu
Re: Build regressions/improvements in v4.9-rc1
Hi Thomas, On Thu, 2016-10-27 at 11:24 +0200, Geert Uytterhoeven wrote: > On Thu, Oct 27, 2016 at 11:11 AM, Thomas Petazzoni > wrote: > > > > On Thu, 27 Oct 2016 09:07:55 +, Alexey Brodkin wrote: > > > > > > > > > > > > > axs101 is using a 770 core, while the toolchain is built for the HS38 > > > > core. I'm somewhat surprised that a single ARC toolchain cannot produce > > > > code for both 770 and HS38, but it seems to be the case. > > > > > > > > So you need a separate toolchain for ARC770. > > > > > > Indeed axs101 uses ARC770 core which is ARCv1 AKA ARCompact ISA while > > > axs103 sports the same base-board but CPU daughter-card contains ARC HS38 > > > core > > > which has ARCv2 ISA (binary incompatible with ARCompact). > > > > > > Essentially both gcc and binutils will happily build for both > > > architectures given > > > proper options were passed on the command line. But Linux kernel gets > > > linked with > > > pre-built libgcc (it is a part of toolchain). And so it all boils down to > > > a requirement > > > to have multilibbed uClibc toolchain. Which we don't have. > > > > Interesting. Why is libgcc linked with the kernel on ARC? I don't think > > that's the case on other architectures: the kernel is freestanding and > > provides everything that it needs without relying on the compiler > > runtime. > > ARC is not the only one: > > $ git grep print-libgcc-file-name > arch/arc/Makefile:LIBGCC := $(shell $(CC) $(cflags-y) > --print-libgcc-file-name) > arch/h8300/boot/compressed/Makefile:LIBGCC := $(shell > $(CROSS-COMPILE)$(CC) $(KBUILD_CFLAGS) -print-libgcc-file-name) > arch/hexagon/Makefile:LIBGCC := $(shell $(CC) $(KBUILD_CFLAGS) > -print-libgcc-file-name) > arch/m32r/Makefile:LIBGCC := $(shell $(CC) $(KBUILD_CFLAGS) > -print-libgcc-file-name) > arch/nios2/Makefile:LIBGCC := $(shell $(CC) $(KBUILD_CFLAGS) > $(KCFLAGS) -print-libgcc-file-name) > arch/openrisc/Makefile:LIBGCC := $(shell $(CC) $(KBUILD_CFLAGS) > -print-libgcc-file-name) > arch/parisc/Makefile:LIBGCC = $(shell $(CC) $(KBUILD_CFLAGS) > -print-libgcc-file-name) > arch/tile/Makefile: $(shell $(CC) $(KBUILD_CFLAGS) $(KCFLAGS) > -print-libgcc-file-name) > arch/xtensa/Makefile:LIBGCC := $(shell $(CC) $(KBUILD_CFLAGS) > -print-libgcc-file-name) > arch/xtensa/boot/boot-redboot/Makefile:LIBGCC := $(shell $(CC) > $(KBUILD_CFLAGS) -print-libgcc-file-name) Right. I'm not 100% sure about all the details in case of Linux kernel on ARC but I actually implemented decoupling from libgcc in U-Boot for ARC. And from that experience I know what was required out of libgcc, see http://git.denx.de/?p=u-boot.git;a=patch;h=a67ef280f46803e319639f5380ff8da6c6b7fbe7 And these are functions required by U-Boot (most probably the same is applied to kernel): 1) so-called millicode, stuff like __ld_rX_to_rY, __st_rX_to_rX 2) shifts: __ashldi3, __ashrdi3, __lshrdi3, 3) divisions: udivmodsi4, __divsi3, __modsi3, __udivsi3, __umodsi3 Indeed it is possible to have so-called private libgcc in kernel as well but benefit will be only for people building kernels but not user-space because in absence of multilibbed toolchain 2 separate toolchains will be required anyways. Still we'll have to pay an additional maintenance price to keep kernel's libgcc in sync with the one from gcc. -Alexey
[PATCH v2 0/3] powernv:stop: Use psscr_val,mask provided by firmware
From: "Gautham R. Shenoy" Hi, This is the second iteration of the patchset to use the psscr_val and psscr_mask provided by the firmware for each of the stop states. The previous version can be found here: https://lkml.org/lkml/2016/9/29/45 The main changes in this version are: 1) Add a helper function in powernv-cpuidle.c to help initialize the powernv_states cpuidle table. 2) Handle the older firmware which populates only the Requested Level (RL) fields of the psscr and psscr_mask in the device tree. This patchset ensures that in the presence of the older firmware, the other fields of PSSCR are initalized to sane default values. Synopsis == In the current implementation, the code for ISA v3.0 stop implementation has a couple of shortcomings. a) The code hand-codes the values for ESL,EC,TR,MTL bits of PSSCR and uses only the RL field from the firmware. While this is not incorrect, since the hand-coded values are legitimate, it is not a very flexible design since the firmware has the capability to communicate these values via the "ibm,cpu-idle-state-psscr" and "ibm,cpu-idle-state-psscr-mask" properties. In case where the firmware provides values for these fields that is different from the hand-coded values, the current code will not work as intended. b) Due to issue a), the current code assumes that ESL=EC=1 for all the stop states and hence the wakeup from the stop instruction will happen at 0x100, the system-reset vector. However, the ISA v3.0 allows the ESL=EC=0 behaviour where the corresponding stop-state loses no state and wakes up from the subsequent instruction. The current code doesn't handle this case. This patch series addresses these issues. The first patch in the series renames the existing IDLE_STATE_ENTER_SEQ macro to IDLE_STATE_ENTER_SEQ_NORET. It reuses the name IDLE_STATE_ENTER_SEQ for entering into stop-states which wake up at the subsequent instruction. The second patch adds a helper function in cpuidle-powernv.c for initializing entries of the powernv_states[] table that is passed to the cpu-idle core. This eliminates some of the code duplication in the function that discovers and initializes the stop states. The third patch in the series fixes issues a) and b) by ensuring that the psscr-value and the psscr-mask provided by the firmware are what will be used to set a particular stop state. It also adds support for handling wake-up from stop states which were entered with ESL=EC=0. The third patch also handles the older firmware which sets only the Requested Level (RL) field in the psscr and psscr-mask exposed in the device tree. In the presence of such older firmware, this patch will set the default sane values for for remaining PSSCR fields (i.e PSLL, MTL, ESL, EC, and TR). The skiboot patch populates all the relevant fields in the PSSCR values and the mask for all the stop states can be found here: https://lists.ozlabs.org/pipermail/skiboot/2016-September/004869.html The patches are based on top of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git fixes Gautham R. Shenoy (3): powernv:idle: Add IDLE_STATE_ENTER_SEQ_NORET macro cpuidle:powernv: Add helper function to populate powernv idle states. powernv: Pass PSSCR value and mask to power9_idle_stop arch/powerpc/include/asm/cpuidle.h | 42 +++- arch/powerpc/include/asm/processor.h | 3 +- arch/powerpc/kernel/exceptions-64s.S | 6 +- arch/powerpc/kernel/idle_book3s.S| 41 +++- arch/powerpc/platforms/powernv/idle.c| 81 +++ arch/powerpc/platforms/powernv/powernv.h | 3 +- arch/powerpc/platforms/powernv/smp.c | 14 ++-- drivers/cpuidle/cpuidle-powernv.c| 110 --- include/linux/cpuidle.h | 1 + 9 files changed, 220 insertions(+), 81 deletions(-) -- 1.9.4
Re: [RFC PATCH 5/5] of: overlay-mgr: add a detector for headers stored on a ds2431 eeprom over w1
Hello Matthias, On Thu, Oct 27, 2016 at 11:19:14AM +0200, Matthias Brugger wrote: > On 10/26/2016 04:57 PM, Antoine Tenart wrote: > > Signed-off-by: Antoine Tenart > > --- > > Please provide a commit message. Sure. There are other modifications I'd like to do in the series if it happens to be an use case for people. This patch is given as an example of how we could implement this. Antoine -- Antoine Ténart, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature
[RFC PATCH 0/5] add support for DMO embedded controller
This patch series adds support for the Data Modul Embedded Controller(dmec) which is implemented within an on board FPGA found on Data Modul embedded CPU modules. The dmec is connected to the host through the LPC bus and its registers are mapped into the host I/O space. The controller supports two addressing modes: linear and indexed. The driver adds support for the following functionality: - i2c - gpio - watchdog - running time meter (rtm) Zahari Doychev (5): dmec: add DMO mfd driver i2c-dmec: add i2c bus support for dmec gpio-dmec: gpio support for dmec wdt-dmec: watchdog support for dmec rtm-dmec: running time meter support drivers/staging/Kconfig | 2 +- drivers/staging/Makefile | 1 +- drivers/staging/dmec/Kconfig | 50 +++- drivers/staging/dmec/Makefile| 5 +- drivers/staging/dmec/dmec-core.c | 500 - drivers/staging/dmec/dmec.h | 20 +- drivers/staging/dmec/gpio-dmec.c | 390 ++- drivers/staging/dmec/i2c-dmec.c | 524 +- drivers/staging/dmec/rtm-dmec.c | 203 +++- drivers/staging/dmec/wdt-dmec.c | 569 - 10 files changed, 2264 insertions(+), 0 deletions(-) create mode 100644 drivers/staging/dmec/Kconfig create mode 100644 drivers/staging/dmec/Makefile create mode 100644 drivers/staging/dmec/dmec-core.c create mode 100644 drivers/staging/dmec/dmec.h create mode 100644 drivers/staging/dmec/gpio-dmec.c create mode 100644 drivers/staging/dmec/i2c-dmec.c create mode 100644 drivers/staging/dmec/rtm-dmec.c create mode 100644 drivers/staging/dmec/wdt-dmec.c base-commit: 9fe68cad6e74967b88d0c6aeca7d9cd6b6e91942 -- git-series 0.8.10
Re: [PATCH 0/4] Generic #pinctrl-cells and and pinctrl_parse_index_with_args
On Tue, Oct 25, 2016 at 6:45 PM, Tony Lindgren wrote: > Here are some pinctrl changes to introduce #pinctrl-cells and a generic > parser pinctrl_parse_index_with_args that the drivers can optionally use. I like this set. If we can get ACK from the DT people and get the modifier of_* functions exported I'm generally happy to merge it. Yours, Linus Walleij
[PATCH v2 2/3] cpuidle:powernv: Add helper function to populate powernv idle states.
From: "Gautham R. Shenoy"
In the current code for powernv_add_idle_states, there is a lot of code
duplication while initializing an idle state in powernv_states table.
Add an inline helper function to populate the powernv_states[] table for
a given idle state. Invoke this for populating the "Nap", "Fastsleep"
and the stop states in powernv_add_idle_states.
Signed-off-by: Gautham R. Shenoy
---
drivers/cpuidle/cpuidle-powernv.c | 82 +++
include/linux/cpuidle.h | 1 +
2 files changed, 49 insertions(+), 34 deletions(-)
diff --git a/drivers/cpuidle/cpuidle-powernv.c
b/drivers/cpuidle/cpuidle-powernv.c
index 7fe442c..11b22b9 100644
--- a/drivers/cpuidle/cpuidle-powernv.c
+++ b/drivers/cpuidle/cpuidle-powernv.c
@@ -167,6 +167,28 @@ static int powernv_cpuidle_driver_init(void)
return 0;
}
+static inline void add_powernv_state(int index, const char *name,
+unsigned int flags,
+int (*idle_fn)(struct cpuidle_device *,
+ struct cpuidle_driver *,
+ int),
+unsigned int target_residency,
+unsigned int exit_latency,
+u64 psscr_val)
+{
+ strncpy(powernv_states[index].name, name, CPUIDLE_NAME_LEN);
+ strncpy(powernv_states[index].desc, name, CPUIDLE_NAME_LEN);
+ powernv_states[index].flags = flags;
+ powernv_states[index].target_residency = target_residency;
+ powernv_states[index].exit_latency = exit_latency;
+ powernv_states[index].enter = idle_fn;
+
+ if (idle_fn != stop_loop)
+ return;
+
+ stop_psscr_table[index] = psscr_val;
+}
+
static int powernv_add_idle_states(void)
{
struct device_node *power_mgt;
@@ -236,6 +258,7 @@ static int powernv_add_idle_states(void)
"ibm,cpu-idle-state-residency-ns", residency_ns,
dt_idle_states);
for (i = 0; i < dt_idle_states; i++) {
+ unsigned int exit_latency, target_residency;
/*
* If an idle state has exit latency beyond
* POWERNV_THRESHOLD_LATENCY_NS then don't use it
@@ -244,27 +267,30 @@ static int powernv_add_idle_states(void)
if (latency_ns[i] > POWERNV_THRESHOLD_LATENCY_NS)
continue;
+ exit_latency = ((unsigned int)latency_ns[i]) / 1000;
+ target_residency = (!rc) ? ((unsigned int)residency_ns[i]) : 0;
+ /*
+* Firmware passes residency values in ns.
+* cpuidle expects it in us.
+*/
+ target_residency /= 1000;
+
/*
* Cpuidle accepts exit_latency and target_residency in us.
* Use default target_residency values if f/w does not expose
it.
*/
if (flags[i] & OPAL_PM_NAP_ENABLED) {
+ target_residency = 100;
/* Add NAP state */
- strcpy(powernv_states[nr_idle_states].name, "Nap");
- strcpy(powernv_states[nr_idle_states].desc, "Nap");
- powernv_states[nr_idle_states].flags = 0;
- powernv_states[nr_idle_states].target_residency = 100;
- powernv_states[nr_idle_states].enter = nap_loop;
+ add_powernv_state(nr_idle_states, "Nap",
+ CPUIDLE_FLAG_NONE, nap_loop,
+ target_residency, exit_latency, 0);
} else if ((flags[i] & OPAL_PM_STOP_INST_FAST) &&
!(flags[i] & OPAL_PM_TIMEBASE_STOP)) {
- strncpy(powernv_states[nr_idle_states].name,
- names[i], CPUIDLE_NAME_LEN);
- strncpy(powernv_states[nr_idle_states].desc,
- names[i], CPUIDLE_NAME_LEN);
- powernv_states[nr_idle_states].flags = 0;
-
- powernv_states[nr_idle_states].enter = stop_loop;
- stop_psscr_table[nr_idle_states] = psscr_val[i];
+ add_powernv_state(nr_idle_states, names[i],
+ CPUIDLE_FLAG_NONE, stop_loop,
+ target_residency, exit_latency,
+ psscr_val[i]);
}
/*
@@ -274,32 +300,20 @@ static int powernv_add_idle_states(void)
#ifdef CONFIG_TICK_ONESHOT
if (flags[i] & OPAL_PM_SLEEP_ENABLED ||
flags[i] & OPAL_PM_SLEEP_ENABLED_ER1) {
+ target_residency = 30;
/* Add FASTSLEEP state */
-
RE: [PATCH V2 08/10] watchdog: da9062/61: watchdog driver
On 26 October 2016 19:59 Guenter Roeck wrote:
> On Wed, Oct 26, 2016 at 05:56:39PM +0100, Steve Twiss wrote:
> > From: Steve Twiss
> >
> > +static const struct of_device_id da9062_compatible_id_table[] = {
> > + { .compatible = "dlg,da9062-watchdog", .data = &da9062_watchdog_info },
> > + { },
> > +};
> > +
> > static int da9062_wdt_probe(struct platform_device *pdev)
> > {
> > int ret;
> > struct da9062 *chip;
> > struct da9062_watchdog *wdt;
> > + const struct of_device_id *match;
> >
> > chip = dev_get_drvdata(pdev->dev.parent);
> > if (!chip)
> > return -EINVAL;
> >
> > + match = of_match_node(da9062_compatible_id_table,
> > + pdev->dev.of_node);
> > + if (!match)
> > + return -ENXIO;
> > +
> > wdt = devm_kzalloc(&pdev->dev, sizeof(*wdt), GFP_KERNEL);
> > if (!wdt)
> > return -ENOMEM;
> >
> > wdt->hw = chip;
> >
> > - wdt->wdtdev.info = &da9062_watchdog_info;
> > + wdt->wdtdev.info = (const struct watchdog_info *)match->data;
>
> I don't see why you would need match->data or of_match_node above.
Hi Guenter,
True. I do not need to do any matching on the table any more if the assumption
is
to use a fall-back compatible string for DA9061 devices (to use the da9062
device
driver).
I can erase most of that content. Including the .data = &da9062_watchdog_info.
Regards,
Steve
Re: [PATCH 4/9] ASoC: wm9713: add ac97 new bus support
On Wed, Oct 26, 2016 at 09:41:42PM +0200, Robert Jarzmik wrote: > Add support for the new ac97 bus model, where devices are automatically > discovered on AC-Links. > > Signed-off-by: Robert Jarzmik > --- Acked-by: Charles Keepax Thanks, Charles
Re: [patch v1 1/2] drivers/platform/x86: move module mlx-platform from arch/x86 to drivers/platform/x86
On Thu, 2016-10-27 at 13:59 +, vad...@mellanox.com wrote: > From: Vadim Pasternak > > Move module mlx-platform.c from arch/x86/platform/mellanox/ to > drivers/platform/x86/. > Remove folder arch/x86/platform/mellanox/ and update relevant Makefile > and Kconfig. No way, please use -M -C. > > Signed-off-by: Vadim Pasternak > --- > MAINTAINERS | 2 +- > arch/x86/Kconfig | 12 -- > arch/x86/platform/Makefile| 1 - > arch/x86/platform/mellanox/Makefile | 1 - > arch/x86/platform/mellanox/mlx-platform.c | 266 --- > --- > drivers/platform/x86/Kconfig | 14 +- > drivers/platform/x86/Makefile | 1 + > drivers/platform/x86/mlx-platform.c | 266 > ++ > 8 files changed, 281 insertions(+), 282 deletions(-) > delete mode 100644 arch/x86/platform/mellanox/Makefile > delete mode 100644 arch/x86/platform/mellanox/mlx-platform.c > create mode 100644 drivers/platform/x86/mlx-platform.c -- Andy Shevchenko Intel Finland Oy
Re: [PATCH V4 2/3] ARM64 LPC: Add missing range exception for special ISA
Hi, Rob,
Thanks for your comments!
Please check the response blow.
BTW, Are there any comments from other maintainers/hackers??
Thanks in advance!
On 2016/10/27 6:25, Rob Herring wrote:
> On Thu, Oct 20, 2016 at 05:15:39PM +0800, zhichang.yuan wrote:
>> Currently if the range property is not specified of_translate_one
>> returns an error. There are some special devices that work on a
>> range of I/O ports where it's is not correct to specify a range
>> property as the cpu addresses are used by special accessors.
>> Here we add a new exception in of_translate_one to return
>> the cpu address if the range property is not there. The exception
>> checks if the parent bus is ISA and if the special accessors are
>> defined.
>>
>> Signed-off-by: zhichang.yuan
>> Signed-off-by: Gabriele Paoloni
>> ---
>> arch/arm64/include/asm/io.h | 7 +++
>> arch/arm64/kernel/extio.c | 24 +++
>> drivers/of/address.c| 47
>> +++--
>> drivers/pci/pci.c | 6 +++---
>> include/linux/of_address.h | 17
>> 5 files changed, 96 insertions(+), 5 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
>> index 136735d..e480199 100644
>> --- a/arch/arm64/include/asm/io.h
>> +++ b/arch/arm64/include/asm/io.h
>> @@ -175,6 +175,13 @@ static inline u64 __raw_readq(const volatile void
>> __iomem *addr)
>> #define outsl outsl
>>
>> DECLARE_EXTIO(l, u32)
>> +
>> +
>> +#define indirect_io_ison indirect_io_ison
>> +extern int indirect_io_ison(void);
>> +
>> +#define chk_indirect_range chk_indirect_range
>> +extern int chk_indirect_range(u64 taddr);
>> #endif
>>
>>
>> diff --git a/arch/arm64/kernel/extio.c b/arch/arm64/kernel/extio.c
>> index 80cafd5..55df8dc 100644
>> --- a/arch/arm64/kernel/extio.c
>> +++ b/arch/arm64/kernel/extio.c
>> @@ -19,6 +19,30 @@
>>
>> struct extio_ops *arm64_extio_ops;
>>
>> +/**
>> + * indirect_io_ison - check whether indirectIO can work well. This function
>> only call
>> + * before the target I/O address was obtained.
>> + *
>> + * Returns 1 when indirectIO can work.
>> + */
>> +int indirect_io_ison()
>> +{
>> +return arm64_extio_ops ? 1 : 0;
>> +}
>> +
>> +/**
>> + * check_indirect_io - check whether the input taddr is for indirectIO.
>> + * @taddr: the io address to be checked.
>> + *
>> + * Returns 1 when taddr is in the range; otherwise return 0.
>> + */
>> +int chk_indirect_range(u64 taddr)
>> +{
>> +if (arm64_extio_ops->start > taddr || arm64_extio_ops->end < taddr)
>> +return 0;
>> +
>> +return 1;
>> +}
>>
>> BUILD_EXTIO(b, u8)
>>
>> diff --git a/drivers/of/address.c b/drivers/of/address.c
>> index 02b2903..0bee822 100644
>> --- a/drivers/of/address.c
>> +++ b/drivers/of/address.c
>> @@ -479,6 +479,39 @@ static int of_empty_ranges_quirk(struct device_node *np)
>> return false;
>> }
>>
>> +
>> +/*
>> + * Check whether the current device being translating use indirectIO.
>> + *
>> + * return 1 if the check is past, or 0 represents fail checking.
>> + */
>> +static int of_isa_indirect_io(struct device_node *parent,
>
> Make the return bool.
ok. will update it.
>
>> +struct of_bus *bus, __be32 *addr,
>> +int na, u64 *presult)
>> +{
>> +unsigned int flags;
>> +unsigned int rlen;
>> +
>> +/* whether support indirectIO */
>> +if (!indirect_io_ison())
>
> indirect_io_is_enabled() would be a bit more readable.
Ok.
>
>> +return 0;
>> +
>> +if (!of_bus_isa_match(parent))
>> +return 0;
>> +
>> +flags = bus->get_flags(addr);
>> +if (!(flags & IORESOURCE_IO))
>> +return 0;
>> +
>> +/* there is ranges property, apply the normal translation directly. */
>> +if (of_get_property(parent, "ranges", &rlen))
>> +return 0;
>> +
>> +*presult = of_read_number(addr + 1, na - 1);
>> +
>> +return chk_indirect_range(*presult);
>> +}
>> +
>> static int of_translate_one(struct device_node *parent, struct of_bus *bus,
>> struct of_bus *pbus, __be32 *addr,
>> int na, int ns, int pna, const char *rprop)
>> @@ -532,7 +565,7 @@ static int of_translate_one(struct device_node *parent,
>> struct of_bus *bus,
>> }
>> memcpy(addr, ranges + na, 4 * pna);
>>
>> - finish:
>> +finish:
>
> This hunk is unrelated. Drop it.
Yes. Will drop this change.
>
>> of_dump_addr("parent translation for:", addr, pna);
>> pr_debug("with offset: %llx\n", (unsigned long long)offset);
>>
>> @@ -595,6 +628,15 @@ static u64 __of_translate_address(struct device_node
>> *dev,
>> result = of_read_number(addr, na);
>> break;
>> }
>> +/*
>> + * For indirectIO device which has no ranges property, get
>> + * the address from reg directly.
>> + */
>>
Re: [patch v1 2/2] drivers/platform/x86: add mlxcpld-hotplug driver registration to mlx-platform driver
On Thu, 2016-10-27 at 13:59 +, vad...@mellanox.com wrote: > From: Vadim Pasternak Care to fix that ^^^ ? (Hint: it shouldn't be there if author and submitter is the same guy) > Add calls for mlxcpld-hotplug platform driver > registration/unregistration > and add platform hotplug data configurations. Would you provide more information what is done, where it is described in the specs and how user can utilize the change? > --- a/drivers/platform/x86/mlx-platform.c > +++ b/drivers/platform/x86/mlx-platform.c > @@ -37,8 +37,9 @@ > #include > #include > #include > -#include This... > #include > +#include > +#include ...and this doesn't belong to the patch. -- Andy Shevchenko Intel Finland Oy
Re: [PATCH v2 2/4] dt-bindings: Add TI SCI PM Domains
On 10/27/2016 04:02 AM, Tero Kristo wrote:
> On 27/10/16 01:04, Rob Herring wrote:
>> On Wed, Oct 19, 2016 at 03:33:45PM -0500, Dave Gerlach wrote:
>>> Add a generic power domain implementation, TI SCI PM Domains, that
>>> will hook into the genpd framework and allow the TI SCI protocol to
>>> control device power states.
>>>
>>> Also, provide macros representing each device index as understood
>>> by TI SCI to be used in the device node power-domain references.
>>> These are identifiers for the K2G devices managed by the PMMC.
>>>
>>> Signed-off-by: Nishanth Menon
>>> Signed-off-by: Dave Gerlach
>>> ---
>>> .../devicetree/bindings/soc/ti/sci-pm-domain.txt | 54 +
>>> MAINTAINERS| 2 +
>>> include/dt-bindings/genpd/k2g.h| 90
>>> ++
>>> 3 files changed, 146 insertions(+)
>>> create mode 100644
>>> Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>> create mode 100644 include/dt-bindings/genpd/k2g.h
>>>
>>> diff --git a/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>> b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>> new file mode 100644
>>> index ..32f38a349656
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>> @@ -0,0 +1,54 @@
>>> +Texas Instruments TI-SCI Generic Power Domain
>>> +-
>>> +
>>> +Some TI SoCs contain a system controller (like the PMMC, etc...) that is
>>> +responsible for controlling the state of the IPs that are present.
>>> +Communication between the host processor running an OS and the system
>>> +controller happens through a protocol known as TI-SCI [1]. This pm domain
>>> +implementation plugs into the generic pm domain framework and makes use of
>>> +the TI SCI protocol power on and off each device when needed.
>>> +
>>> +[1] Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
>>> +
>>> +PM Domain Node
>>> +==
>>> +The PM domain node represents the global PM domain managed by the PMMC,
>>> +which in this case is the single implementation as documented by the
>>> generic
>>> +PM domain bindings in
>>> Documentation/devicetree/bindings/power/power_domain.txt.
>>> +
>>> +Required Properties:
>>> +
>>> +- compatible: should be "ti,sci-pm-domain"
>>> +- #power-domain-cells: Must be 0.
>>> +- ti,sci: Phandle to the TI SCI device to use for managing the devices.
>>> +
>>> +Example:
>>> +
>>> +k2g_pds: k2g_pds {
>>> +compatible = "ti,sci-pm-domain";
>>> +#power-domain-cells = <0>;
>>> +ti,sci = <&pmmc>;
>>> +};
>>
>> Why not just make the PMMC node be the power-domain provider itself? If
>> not that, then make this a child node of it. The same comment applies to
>> all the SCI functions, but I guess I've already acked some of them.
>
> This seems to be a bug in this documentation actually. ti,sci handle is no
> longer supported, and all the sci stuff must be under the parent sci node.
>
>>
>> I really don't like reviewing all these TI SCI bindings one by one. Each
>> one on its own seems fine, but I don't see the full picture.
>
> The full picture is represented under the documentation for the main protocol
> support itself. See this patch:
>
> https://patchwork.kernel.org/patch/9383281/
>
> Copy pasted here as ref:
>
> Example (K2G):
> -
> pmmc: pmmc {
> compatible = "ti,k2g-sci";
> ...
>
> my_clk_node: clk_node {
> ...
> ...
> };
>
> my_pd_node: pd_node {
> ...
> ...
> };
> };
>
>
Yes my bad I will fix this in V3 once we straighten out the ID portion of the
binding.
Regards,
Dave
Re: [PATCH 7/9] Input: wm97xx: split out touchscreen registering
On Wed, Oct 26, 2016 at 09:41:45PM +0200, Robert Jarzmik wrote:
> wm97xx-core does several things in it initialization :
> - touchscreen input device setup
> - battery device creation
>
> As the wm97xx is actually a multi-function device handling an audio
> codec, a touchscreen, a gpio block and an ADC, reshape the probing to
> isolate what is truly input/touchscreen specific from the remaining
> part.
>
> This is only code shuffling, there is no functional change.
>
> Signed-off-by: Robert Jarzmik
> ---
> drivers/input/touchscreen/wm97xx-core.c | 193
> ++--
> 1 file changed, 112 insertions(+), 81 deletions(-)
>
> diff --git a/drivers/input/touchscreen/wm97xx-core.c
> b/drivers/input/touchscreen/wm97xx-core.c
> index 83cf11312fd9..50a110e2988b 100644
> +static void wm97xx_remove_battery(struct wm97xx *wm)
> +{
> + platform_device_put(wm->battery_dev);
> +}
> @@ -724,10 +757,8 @@ static int wm97xx_remove(struct device *dev)
> {
> struct wm97xx *wm = dev_get_drvdata(dev);
>
> - platform_device_unregister(wm->battery_dev);
> - platform_device_unregister(wm->touch_dev);
> - input_unregister_device(wm->input_dev);
> - kfree(wm);
> + wm97xx_remove_battery(wm);
The commit message says this is just shifting code around but the
platform_device_unregister for the battery_dev seems to have
turned into a platform_device_put here.
Thanks,
Charles
Re: [PATCH 02/12] ASoC: dapm: Implement stereo mixer control support
On Thu, Oct 27, 2016 at 1:50 AM, Mark Brown wrote:
> On Mon, Oct 03, 2016 at 07:07:54PM +0800, Chen-Yu Tsai wrote:
>
>> /* find dapm widget path assoc with kcontrol */
>> dapm_kcontrol_for_each_path(path, kcontrol) {
>> + /*
>> + * If status for the second channel was given ( >= 0 ),
>> + * consider the second and later paths as the second
>> + * channel.
>> + */
>> + if (found && rconnect >= 0)
>> + soc_dapm_connect_path(path, rconnect, "mixer update");
>> + else
>> + soc_dapm_connect_path(path, connect, "mixer update");
>> found = 1;
>> - soc_dapm_connect_path(path, connect, "mixer update");
>
> This really only works for two channels with the current inteface - the
> comment makes it sound like it'll work for more but we can only pass in
> two (and there's only support for specifying two everywhere).
I could rework it to pass a list of connected status' and the number
of elements instead, but it wouldn't work well for situations where
the number of channels on the kcontrol != the number of paths. I'm not
sure if that's even a valid setup, but it does work with the current
core code.
On the other hand, are there kcontrols that are multi-channel
(> 2 channels)?
I'm inclined to just fixup the comment to make it clear that the
implementation supports stereo, i.e. 2 channels, only.
>
>> - change = dapm_kcontrol_set_value(kcontrol, val);
>> + /* This assumes field width < (bits in unsigned int / 2) */
>> + change = dapm_kcontrol_set_value(kcontrol, val | (rval << width));
>
> That seems like a bit of an assumption in cases where we've got a single
> control for both power and volume? They're very rare though, I'm not
> even sure any exist. It'd be good to have a check in the code just in
> case it does come up, it'll likely be a nightmare to debug if someone
> does run into it.
Agreed. I'll put a check and warning before it.
>
> Otherwise I think this makes sense.
Thanks for the review!
Regards
ChenYu
