* Re: [PATCH v3 0/3] epoll: introduce round robin wakeup mode
From: Jason Baron @ 2015-03-02 5:04 UTC (permalink / raw)
To: Jonathan Corbet, Andrew Morton
Cc: Ingo Molnar, peterz-wEGCiKHe2LqWVfeAwA7xHQ,
mingo-H+wXaHxf7aLQT0dZR+AlfA,
viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn, normalperson-rMlxZR9MS24,
davidel-AhlLAIvw+VEjIGhXcJzhZg,
mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w, luto-kltTT9wpgjJwATOyAt5JVQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA, Linus Torvalds, Alexander Viro
In-Reply-To: <20150227143147.07785626-T1hC0tSOHrs@public.gmane.org>
On 02/27/2015 04:31 PM, Jonathan Corbet wrote:
> On Fri, 27 Feb 2015 13:10:34 -0800
> Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> wrote:
>
>> I don't really understand the need for rotation/round-robin. We can
>> solve the thundering herd via exclusive wakeups, but what is the point
>> in choosing to wake the task which has been sleeping for the longest
>> time? Why is that better than waking the task which has been sleeping
>> for the *least* time? That's probably faster as that task's data is
>> more likely to still be in cache.
> So here's my chance to show the world what a fool I am (again)... If I
> understand this at all, a task woken from epoll_wait() remains on the wait
> queues while it is off doing other stuff. If you're doing exclusive
> wakeups, the task at the head of the queue will get all of them, since it
> never gets removed from the queue. So you don't spread your load around,
> and, indeed, you may "wake" a process that is busy doing something else and
> can't deal with the event now anyway. You need some way to shuffle up the
> wait queue, and round-robin is probably as good as any.
>
> (The alternative would be to take the process off the queue until it calls
> epoll_wait() again, but that runs counter to what epoll is all about).
>
> At least, that was my impression when I took a look at this stuff.
>
> jon
So tasks do not remain on wait queues when they are not in
epoll_wait(). That is, tasks are added to the associated epoll
fd wait queue at the beginning of epoll_wait(), and removed
from the associated epoll fd wait queue when epoll_wait()
returns.
One can think about the problem, perhaps, as assigning fd
events - POLLIN, POLLLOUT, etc., to a set of tasks. And this
discussion is about how to do the assignment in certain
cases. Namely, one could start by partitioning the set of fds
into unique sets and then assigning them
(via EPOLL_CTL_ADD) to different epoll fds. Then, if there
is say a single task blocking on each epoll fd (via epoll_wait())
then each task can work nicely on its own set of events
without needing to necessarily co-ordinate with the other
tasks.
Now, this all works fine until, we have an 'fd' or event source
that we wish to share among all the tasks. We might
want to share it because it generates events or work, that
would potentially overwhelm a single task.
So in this shared event source case, where we have added
the fd to all of the epoll fds, we currently do a wake all.
This series attempts to change that behavior (with an
optional flag to epoll_create1()), into a round robin wakeup
(both to avoid excessive wakeups and to more evenly distribute
the wakeups). Note also that it will continue to wake up tasks,
as long as it doesn't find any in epoll_wait(). Thus, it still can
potentially wake up all if nobody is in epoll_wait().
Now, we could try and distribute the fd events among tasks
all waiting on a single epoll fd (meaning we have a single
event queue). But, we have already partitioned most of the
events, why combine them back into a single queue?
Thanks,
-Jason
^ permalink raw reply
* Re: [PATCH 1/9] HSI: cmt_speech: Add cmt-speech driver
From: Oliver Neukum @ 2015-03-02 10:22 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Peter Ujfalusi, Kai Vehmanen, Pavel Machek, Pali Rohar,
Aaro Koskinen, Ivaylo Dimitrov, linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA, Kai Vehmanen, Carlos Chinea,
Joni Lapilainen
In-Reply-To: <1425271139-24715-2-git-send-email-sre-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> +static ssize_t cs_char_read(struct file *file, char __user *buf, size_t count,
> + loff_t *unused)
> +{
> + struct cs_char *csdata = file->private_data;
> + u32 data;
> + ssize_t retval;
> +
> + if (count < sizeof(data))
> + return -EINVAL;
> +
> + for ( ; ; ) {
> + DEFINE_WAIT(wait);
> +
> + spin_lock_bh(&csdata->lock);
> + if (!list_empty(&csdata->chardev_queue)) {
> + data = cs_pop_entry(&csdata->chardev_queue);
> + } else if (!list_empty(&csdata->dataind_queue)) {
> + data = cs_pop_entry(&csdata->dataind_queue);
> + --csdata->dataind_pending;
> +
> + } else {
> + data = 0;
> + }
> + spin_unlock_bh(&csdata->lock);
> +
> + if (data)
> + break;
> + if (file->f_flags & O_NONBLOCK) {
> + retval = -EAGAIN;
> + goto out;
> + } else if (signal_pending(current)) {
> + retval = -ERESTARTSYS;
> + goto out;
> + }
> + prepare_to_wait_exclusive(&csdata->wait, &wait,
> + TASK_INTERRUPTIBLE);
> + schedule();
> + finish_wait(&csdata->wait, &wait);
> + }
> +
> + retval = put_user(data, (u32 __user *)buf);
> + if (!retval)
> + retval = sizeof(data);
> +
> +out:
> + return retval;
> +}
> +
> +static ssize_t cs_char_write(struct file *file, const char __user *buf,
> + size_t count, loff_t *unused)
> +{
> + struct cs_char *csdata = file->private_data;
> + u32 data;
> + int err;
> + ssize_t retval;
> +
> + if (count < sizeof(data))
> + return -EINVAL;
> +
> + if (get_user(data, (u32 __user *)buf))
> + retval = -EFAULT;
> + else
> + retval = count;
You want to execute the command even if you got -EFAULT?
That is highly unusual.
> +
> + err = cs_hsi_command(csdata->hi, data);
> + if (err < 0)
> + retval = err;
> +
> + return retval;
> +}
> +
> +static long cs_char_ioctl(struct file *file, unsigned int cmd,
> + unsigned long arg)
> +{
> + struct cs_char *csdata = file->private_data;
> + int r = 0;
> +
> + switch (cmd) {
> + case CS_GET_STATE: {
> + unsigned int state;
> +
> + state = cs_hsi_get_state(csdata->hi);
> + if (copy_to_user((void __user *)arg, &state, sizeof(state)))
> + r = -EFAULT;
> + }
> + break;
> + case CS_SET_WAKELINE: {
> + unsigned int state;
> +
> + if (copy_from_user(&state, (void __user *)arg, sizeof(state)))
> + r = -EFAULT;
> + else
> + cs_hsi_set_wakeline(csdata->hi, state);
No sanity checking for state?
> + }
> + break;
> + case CS_GET_IF_VERSION: {
> + unsigned int ifver = CS_IF_VERSION;
> +
> + if (copy_to_user((void __user *)arg, &ifver, sizeof(ifver)))
> + r = -EFAULT;
> + break;
> + }
> + case CS_CONFIG_BUFS: {
> + struct cs_buffer_config buf_cfg;
> +
> + if (copy_from_user(&buf_cfg, (void __user *)arg,
> + sizeof(buf_cfg)))
> + r = -EFAULT;
> + else
> + r = cs_hsi_buf_config(csdata->hi, &buf_cfg);
Sanity checking?
> + break;
> + }
> + default:
> + r = -ENOTTY;
> + break;
> + }
> +
> + return r;
> +}
> +
> +static int cs_char_mmap(struct file *file, struct vm_area_struct *vma)
> +{
> + if (vma->vm_end < vma->vm_start)
> + return -EINVAL;
> +
> + if (((vma->vm_end - vma->vm_start) >> PAGE_SHIFT) != 1)
> + return -EINVAL;
> +
> + vma->vm_flags |= VM_RESERVED;
> + vma->vm_ops = &cs_char_vm_ops;
> + vma->vm_private_data = file->private_data;
> +
> + return 0;
> +}
> +
> +static int cs_char_open(struct inode *unused, struct file *file)
> +{
> + int ret = 0;
> +
> + spin_lock_bh(&cs_char_data.lock);
> + if (cs_char_data.opened) {
> + ret = -EBUSY;
> + spin_unlock_bh(&cs_char_data.lock);
> + goto out;
> + }
> + cs_char_data.mmap_base = get_zeroed_page(GFP_ATOMIC);
This could be moved outside the locked sectionand use GFP_KERNEL.
> + if (!cs_char_data.mmap_base) {
> + dev_err(&cs_char_data.cl->device,
> + "Shared memory allocation failed.\n");
> + ret = -ENOMEM;
> + spin_unlock_bh(&cs_char_data.lock);
> + goto out;
> + }
> + cs_char_data.mmap_size = CS_MMAP_SIZE;
> + cs_char_data.dataind_pending = 0;
> + cs_char_data.opened = 1;
> + file->private_data = &cs_char_data;
> + spin_unlock_bh(&cs_char_data.lock);
> +
> + BUG_ON(cs_char_data.hi);
> +
> + ret = cs_hsi_start(&cs_char_data.hi, cs_char_data.cl,
> + cs_char_data.mmap_base, cs_char_data.mmap_size);
> + if (ret) {
> + dev_err(&cs_char_data.cl->device, "Unable to initialize HSI\n");
> + free_page(cs_char_data.mmap_base);
> + goto out;
> + }
> +
> +out:
> + return ret;
> +}
^ permalink raw reply
* Re: [PATCH 1/9] HSI: cmt_speech: Add cmt-speech driver
From: Oliver Neukum @ 2015-03-02 10:29 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Peter Ujfalusi, Kai Vehmanen, Pavel Machek, Pali Rohar,
Aaro Koskinen, Ivaylo Dimitrov, linux-omap, linux-kernel,
linux-api, Kai Vehmanen, Carlos Chinea, Joni Lapilainen
In-Reply-To: <1425271139-24715-2-git-send-email-sre@kernel.org>
On Mon, 2015-03-02 at 05:38 +0100, Sebastian Reichel wrote:
> +static int cs_alloc_cmds(struct cs_hsi_iface *hi)
> +{
> + struct hsi_msg *msg;
> + u32 *buf;
> + unsigned int i;
> +
> + INIT_LIST_HEAD(&hi->cmdqueue);
> +
> + for (i = 0; i < CS_MAX_CMDS; i++) {
> + msg = hsi_alloc_msg(1, GFP_ATOMIC);
Why does this need to be ATOMIC?
> + if (!msg)
> + goto out;
> + buf = kmalloc(sizeof(*buf), GFP_ATOMIC);
> + if (!buf) {
> + hsi_free_msg(msg);
> + goto out;
> + }
> + sg_init_one(msg->sgt.sgl, buf, sizeof(*buf));
> + msg->channel = CONTROL_HSI_CH;
> + msg->context = hi;
> + list_add_tail(&msg->link, &hi->cmdqueue);
> + }
> +
> + return 0;
> +
> +out:
> + cs_free_cmds(hi);
> + return -ENOMEM;
> +}
> +
^ permalink raw reply
* Re: [PATCH v5 tip 1/7] bpf: make internal bpf API independent of CONFIG_BPF_SYSCALL ifdefs
From: Masami Hiramatsu @ 2015-03-02 10:53 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Ingo Molnar, Steven Rostedt, Namhyung Kim,
Arnaldo Carvalho de Melo, Jiri Olsa, David S. Miller,
Daniel Borkmann, Peter Zijlstra, linux-api-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1425252465-27527-2-git-send-email-ast-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org>
(2015/03/02 8:27), Alexei Starovoitov wrote:
> From: Daniel Borkmann <daniel-FeC+5ew28dpmcu3hnIyYJQ@public.gmane.org>
>
> Socket filter code and other subsystems with upcoming eBPF support should
> not need to deal with the fact that we have CONFIG_BPF_SYSCALL defined or
> not.
>
> Having the bpf syscall as a config option is a nice thing and I'd expect
> it to stay that way for expert users (I presume one day the default setting
> of it might change, though), but code making use of it should not care if
> it's actually enabled or not.
Hmm, it seems that this still doesn't hide some APIs which is provided
only when CONFIG_BPF_SYSCALL. For example bpf_register_map_type etc.
I think all those APIs should be hidden in #ifdef or at least be commented
so that the user doesn't refer that without the kconfig.
(I don't think we need to provide dummy functions for those APIs,
but it's better to clarify which API we can use with which kconfig)
Thank you,
>
> Instead, hide this via header files and let the rest deal with it.
>
> Signed-off-by: Daniel Borkmann <daniel-FeC+5ew28dpmcu3hnIyYJQ@public.gmane.org>
> Signed-off-by: Alexei Starovoitov <ast-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org>
> ---
> include/linux/bpf.h | 20 ++++++++++++++++----
> 1 file changed, 16 insertions(+), 4 deletions(-)
>
> diff --git a/include/linux/bpf.h b/include/linux/bpf.h
> index bbfceb756452..c2e21113ecc0 100644
> --- a/include/linux/bpf.h
> +++ b/include/linux/bpf.h
> @@ -113,8 +113,6 @@ struct bpf_prog_type_list {
> enum bpf_prog_type type;
> };
>
> -void bpf_register_prog_type(struct bpf_prog_type_list *tl);
> -
> struct bpf_prog;
>
> struct bpf_prog_aux {
> @@ -129,11 +127,25 @@ struct bpf_prog_aux {
> };
>
> #ifdef CONFIG_BPF_SYSCALL
> +void bpf_register_prog_type(struct bpf_prog_type_list *tl);
> +
> void bpf_prog_put(struct bpf_prog *prog);
> +struct bpf_prog *bpf_prog_get(u32 ufd);
> #else
> -static inline void bpf_prog_put(struct bpf_prog *prog) {}
> +static inline void bpf_register_prog_type(struct bpf_prog_type_list *tl)
> +{
> +}
> +
> +static inline struct bpf_prog *bpf_prog_get(u32 ufd)
> +{
> + return ERR_PTR(-EOPNOTSUPP);
> +}
> +
> +static inline void bpf_prog_put(struct bpf_prog *prog)
> +{
> +}
> #endif
> -struct bpf_prog *bpf_prog_get(u32 ufd);
> +
> /* verify correctness of eBPF program */
> int bpf_check(struct bpf_prog *fp, union bpf_attr *attr);
>
>
--
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt-FCd8Q96Dh0JBDgjK7y7TUQ@public.gmane.org
^ permalink raw reply
* Re: [PATCH v5 tip 1/7] bpf: make internal bpf API independent of CONFIG_BPF_SYSCALL ifdefs
From: Daniel Borkmann @ 2015-03-02 11:10 UTC (permalink / raw)
To: Masami Hiramatsu, Alexei Starovoitov
Cc: Ingo Molnar, Steven Rostedt, Namhyung Kim,
Arnaldo Carvalho de Melo, Jiri Olsa, David S. Miller,
Peter Zijlstra, linux-api-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <54F44115.40505-FCd8Q96Dh0JBDgjK7y7TUQ@public.gmane.org>
On 03/02/2015 11:53 AM, Masami Hiramatsu wrote:
...
> Hmm, it seems that this still doesn't hide some APIs which is provided
> only when CONFIG_BPF_SYSCALL. For example bpf_register_map_type etc.
> I think all those APIs should be hidden in #ifdef or at least be commented
> so that the user doesn't refer that without the kconfig.
> (I don't think we need to provide dummy functions for those APIs,
> but it's better to clarify which API we can use with which kconfig)
Well, currently all possible map types (hash table, array map) that
would actually call into bpf_register_map_type() are only built when
CONFIG_BPF_SYSCALL is enabled (see kernel/bpf/Makefile). I don't think
new map additions should be added that are not under kernel/bpf/ and/or
enabled outside the CONFIG_BPF_SYSCALL, as it should be considered
part of the eBPF core code.
The difference here (this patch) is simply that we don't want users to
build ifdef spaghetti constructs in user code, so the API that is
actually used by eBPF _users_ is being properly ifdef'ed in the headers.
So, I don't think this is a big problem, but we could move these bits
under the ifdef CONFIG_BPF_SYSCALL w/o providing a dummy in the else part.
I can do that outside of the scope of this set.
^ permalink raw reply
* Re: [PATCH 0/2] add cursor blink interval terminal escape sequence
From: Tomi Valkeinen @ 2015-03-02 11:15 UTC (permalink / raw)
To: Scot Doyle
Cc: Greg Kroah-Hartman, Jiri Slaby, Jean-Christophe Plagniol-Villard,
Michael Kerrisk, Pavel Machek, Geert Uytterhoeven, linux-kernel,
linux-fbdev, linux-api, linux-man
In-Reply-To: <alpine.LNX.2.11.1502271905580.4212@localhost>
[-- Attachment #1: Type: text/plain, Size: 512 bytes --]
On 27/02/15 21:10, Scot Doyle wrote:
> Greg, the first patch of this series is for the tty tree.
>
> Tomi, the second patch of this series is for your tree, but it depends on
> the first patch. Also, will you remove these two previously queued patches?
> "fbcon: store cursor blink interval in fbcon_ops"
> "fbcon: expose cursor blink interval via sysfs"
I have dropped those two patches from fbdev tree.
I don't know much about the console side, so I can't comment anything on
that.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v5 tip 1/7] bpf: make internal bpf API independent of CONFIG_BPF_SYSCALL ifdefs
From: Masami Hiramatsu @ 2015-03-02 11:51 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Alexei Starovoitov, Ingo Molnar, Steven Rostedt, Namhyung Kim,
Arnaldo Carvalho de Melo, Jiri Olsa, David S. Miller,
Peter Zijlstra, linux-api, netdev, linux-kernel
In-Reply-To: <54F4451B.8000703@iogearbox.net>
(2015/03/02 20:10), Daniel Borkmann wrote:
> On 03/02/2015 11:53 AM, Masami Hiramatsu wrote:
> ...
>> Hmm, it seems that this still doesn't hide some APIs which is provided
>> only when CONFIG_BPF_SYSCALL. For example bpf_register_map_type etc.
>> I think all those APIs should be hidden in #ifdef or at least be commented
>> so that the user doesn't refer that without the kconfig.
>> (I don't think we need to provide dummy functions for those APIs,
>> but it's better to clarify which API we can use with which kconfig)
>
> Well, currently all possible map types (hash table, array map) that
> would actually call into bpf_register_map_type() are only built when
> CONFIG_BPF_SYSCALL is enabled (see kernel/bpf/Makefile). I don't think
> new map additions should be added that are not under kernel/bpf/ and/or
> enabled outside the CONFIG_BPF_SYSCALL, as it should be considered
> part of the eBPF core code.
>
> The difference here (this patch) is simply that we don't want users to
> build ifdef spaghetti constructs in user code, so the API that is
> actually used by eBPF _users_ is being properly ifdef'ed in the headers.
>
> So, I don't think this is a big problem, but we could move these bits
> under the ifdef CONFIG_BPF_SYSCALL w/o providing a dummy in the else part.
> I can do that outside of the scope of this set.
Or, maybe we'd better move them into new include/linux/bpf_prog.h which
includes basic include/linux/bpf.h. Then, user can include the bpf_prog.h
instead of bpf.h. Also, we can check CONFIG_BPF_SYSCAL=y at the top of
bpf_prog.h. This makes things clearer :)
Thank you,
--
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@hitachi.com
^ permalink raw reply
* Re: [PATCH v5 tip 1/7] bpf: make internal bpf API independent of CONFIG_BPF_SYSCALL ifdefs
From: Daniel Borkmann @ 2015-03-02 12:26 UTC (permalink / raw)
To: Masami Hiramatsu
Cc: Alexei Starovoitov, Ingo Molnar, Steven Rostedt, Namhyung Kim,
Arnaldo Carvalho de Melo, Jiri Olsa, David S. Miller,
Peter Zijlstra, linux-api, netdev, linux-kernel
In-Reply-To: <54F44EC3.4070504@hitachi.com>
On 03/02/2015 12:51 PM, Masami Hiramatsu wrote:
> (2015/03/02 20:10), Daniel Borkmann wrote:
>> On 03/02/2015 11:53 AM, Masami Hiramatsu wrote:
>> ...
>>> Hmm, it seems that this still doesn't hide some APIs which is provided
>>> only when CONFIG_BPF_SYSCALL. For example bpf_register_map_type etc.
>>> I think all those APIs should be hidden in #ifdef or at least be commented
>>> so that the user doesn't refer that without the kconfig.
>>> (I don't think we need to provide dummy functions for those APIs,
>>> but it's better to clarify which API we can use with which kconfig)
>>
>> Well, currently all possible map types (hash table, array map) that
>> would actually call into bpf_register_map_type() are only built when
>> CONFIG_BPF_SYSCALL is enabled (see kernel/bpf/Makefile). I don't think
>> new map additions should be added that are not under kernel/bpf/ and/or
>> enabled outside the CONFIG_BPF_SYSCALL, as it should be considered
>> part of the eBPF core code.
>>
>> The difference here (this patch) is simply that we don't want users to
>> build ifdef spaghetti constructs in user code, so the API that is
>> actually used by eBPF _users_ is being properly ifdef'ed in the headers.
>>
>> So, I don't think this is a big problem, but we could move these bits
>> under the ifdef CONFIG_BPF_SYSCALL w/o providing a dummy in the else part.
>> I can do that outside of the scope of this set.
>
> Or, maybe we'd better move them into new include/linux/bpf_prog.h which
> includes basic include/linux/bpf.h. Then, user can include the bpf_prog.h
> instead of bpf.h. Also, we can check CONFIG_BPF_SYSCAL=y at the top of
> bpf_prog.h. This makes things clearer :)
I'm preferring the 1st variant, though. We have currently two native eBPF
users, that is, socket filters and tc's cls_bpf (queued in net-next) and
looking at the code/API usage, it's really not that hard, where it would
justify to move this to an extra header file, really.
I'm cooking a patch for net-next right now with the first variant (which is
on top of this patch that resides in net-next as-is as well).
Thanks,
Daniel
^ permalink raw reply
* Re: [PATCH RFC 0/3] Drivers: hv: utils: re-implement the kernel/userspace communication layer
From: Vitaly Kuznetsov @ 2015-03-02 13:33 UTC (permalink / raw)
To: Radim Krčmář
Cc: K. Y. Srinivasan, devel-tBiZLqfeLfOHmIFyCCdPziST3g8Odh+X,
Haiyang Zhang, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Dexuan Cui,
Greg Kroah-Hartman, linux-api-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20150227210744.GA11904-KfRq7+sF/6zkZJWtSm8s3NvLeJWuRmrY@public.gmane.org>
Radim Krčmář <rkrcmar-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> writes:
> 2015-02-27 17:14+0100, Vitaly Kuznetsov:
>> This series converts kvp/vss daemons to use misc char devices instead of
>> netlink for userspace/kernel communication and then updates fcopy to be
>> consistent with kvp/vss.
>>
>> Userspace/kernel communication via netlink has a number of issues:
>> - It is hard for userspace to figure out if the kernel part was loaded or not
>> and this fact can change as there is a way to enable/disable the service from
>> host side.
>
> (Hm, this should be just a message to the userspace daemon, but netlink
> probably makes it complicated anyway.)
>
>> Racy daemon startup is also a problem.
>
> (Is it significantly worse than what we need to protect devices?)
>
>> - When the userspace daemon restarts/dies kernel part doesn't receive a
>> notification.
>
> (True, we could use a other-side-closed callback.)
With normal devices we can use e.g. udev/systemd machinery to start/stop
service on device hotplug/hotunplug (and these devices are actually
pluggable/unpluggable from host side) without any special code in
kernel/userspace parts and I'd like to use that.
>
>> - Netlink communication is not stable under heavy load.
>
> (The message order changes?)
>
It is a disaster if it does (the whole transaction will get lost). Same
if any of these messages gets lost.
>> RFC: I'm a bit puzzled on how to split commits 1 and 2 avoiding breakages.
>
> Split the userspace part -- it won't break bisects.
>
Sure if it simplifies the review.
> And then, you could refactor drivers first ... the way we communicate
> with userspace should have little impact on what the rest does (or how).
> At first sight, there are three units, apart from glue,
> 1) communication with host
> 2) communication with userspace
> 3) repacking of data between first two
>
> With an API for userspace communication, the amount of code to replace
> netlink could be lower and resulting patches definitely easier to
> review. (And with extra work, both ABIs could even live side-by-side ;)
Ok, thanks!
--
Vitaly
^ permalink raw reply
* Re: [PATCH RFC 0/3] Drivers: hv: utils: re-implement the kernel/userspace communication layer
From: Vitaly Kuznetsov @ 2015-03-02 13:37 UTC (permalink / raw)
To: KY Srinivasan
Cc: Radim Krčmář, Greg Kroah-Hartman, Haiyang Zhang,
linux-kernel@vger.kernel.org, linux-api@vger.kernel.org,
devel@linuxdriverproject.org
In-Reply-To: <BY2PR0301MB071107C31972876159BB360CA0100@BY2PR0301MB0711.namprd03.prod.outlook.com>
KY Srinivasan <kys@microsoft.com> writes:
>> -----Original Message-----
>> From: Vitaly Kuznetsov [mailto:vkuznets@redhat.com]
>> Sent: Friday, February 27, 2015 8:14 AM
>> To: KY Srinivasan; devel@linuxdriverproject.org
>> Cc: Haiyang Zhang; linux-kernel@vger.kernel.org; Dexuan Cui; Radim Krčmář;
>> Greg Kroah-Hartman; linux-api@vger.kernel.org
>> Subject: [PATCH RFC 0/3] Drivers: hv: utils: re-implement the
>> kernel/userspace communication layer
>>
>> This series converts kvp/vss daemons to use misc char devices instead of
>> netlink for userspace/kernel communication and then updates fcopy to be
>> consistent with kvp/vss.
>>
>> Userspace/kernel communication via netlink has a number of issues:
>> - It is hard for userspace to figure out if the kernel part was loaded or not
>> and this fact can change as there is a way to enable/disable the service from
>> host side. Racy daemon startup is also a problem.
>> - When the userspace daemon restarts/dies kernel part doesn't receive a
>> notification.
>> - Netlink communication is not stable under heavy load.
>> - ...
>>
>> RFC: I'm a bit puzzled on how to split commits 1 and 2 avoiding breakages.
>> Commit 3 can definitely be split, however, it is consistent with commits 1 and
>> 2 at this moment and I'm not sure such split will simplify the review.
>>
>> Vitaly Kuznetsov (3):
>> Drivers: hv: kvp: convert userspace/kernel communication to using char
>> device
>> Drivers: hv: vss: convert userspace/kernel communication to using char
>> device
>> Drivers: hv: fcopy: make it consistent with vss/kvp
>
> Vitaly,
>
> Thank you for working on this. Before I give you detailed comments on your
> patches, I wanted to understand if the cost of maintaining compatibility was
> carefully considered. As a first step we could look at cleanly abstracting the
> transport (between user level and the kernel) out of the kernel driver code
> as well as the new daemon code. What are your thoughts on
> this. Version negotiation is obviously key to maintaining
> compatibility. One of the options we can explore is to continue to
> use netlink for version negotiation and for appropriate daemon versions, we could use
> the char device mechanism for transporting the payload.
Ok, I'll try making it backwards compatible (though I'd opt for
full migratiot to char devices one day and thus having negotiation
possible via the same device as well as via netlink for now).
>
> I like the new state machine you have defined and this is orthogonal to the transport
> options we have. You have sought feedback on how we can split up these changes into
> smaller patches. This is how I would proceed here:
>
> Patch(es) to clean up the current code:
> Patch(es) to clean up the state machine.
> Patch(es) to isolate the kernel/user transport
> Patch(es) to implement the new transport
Thanks, I'll proceed in this way.
>
> Regards,
>
> K. Y
>>
>> drivers/hv/hv_fcopy.c | 395 +++++++++++++++++++++++++---------------
>> ---
>> drivers/hv/hv_kvp.c | 396 +++++++++++++++++++++++++++-------------
>> ----
>> drivers/hv/hv_snapshot.c | 335 +++++++++++++++++++++++++++---------
>> -
>> include/uapi/linux/hyperv.h | 10 ++
>> tools/hv/hv_fcopy_daemon.c | 48 ++++--
>> tools/hv/hv_kvp_daemon.c | 187 ++++-----------------
>> tools/hv/hv_vss_daemon.c | 141 +++-------------
>> 7 files changed, 824 insertions(+), 688 deletions(-)
>>
>> --
>> 1.9.3
--
Vitaly
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
^ permalink raw reply
* Re: [PATCH v1 1/5] IB/uverbs: ex_query_device: answer must not depend on request's comp_mask
From: Yann Droneaud @ 2015-03-02 14:08 UTC (permalink / raw)
To: Or Gerlitz, Or Gerlitz
Cc: Roland Dreier, Jason Gunthorpe, Sagi Grimberg, Shachar Raindel,
Eli Cohen, Haggai Eran,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-api-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CAJ3xEMhDtD7MpJ+1Y3z2yMpTrb9C5SaUa94E8xpVLHN4pHe3fw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi Or,
Le samedi 31 janvier 2015 à 22:09 +0200, Or Gerlitz a écrit :
> On Fri, Jan 30, 2015, Yann Droneaud <ydroneaud-RlY5vtjFyJ3QT0dZR+AlfA@public.gmane.org> wrote:
> > [..] I have not the chance
> > of owning HCA with the support for this feature, nor the patches
> > libibverbs / libmlx5 ... (anyway I would not have the time to test). [...]
>
> Yann, have you ever run Linux over RDMA capable HW (IB, RoCE, iWARP or alike?)
That was a silly question.
So I've took a little time to consider answering it,
perhaps you were gently kidding me.
Anyway, please take the following links as an answer to your question:
"rdma_create_qp() and max_send_wr"
<http://mid.gmane.org/1303404264.2243.19.camel-H/AUWmsJYVeqvyCYKW+Xr6xOck334EZe@public.gmane.org>
"ibv_create_qp() and max_inline_data behavior"
<http://mid.gmane.org/d7685e13978f93890b2939c5ac2d5c7f-zgzEX58YAwA@public.gmane.org>
"[PATCH librdmacm 0/3] no IBV_SEND_INLINE thus memory registration
required on QLogic/Intel HCA"
<http://mid.gmane.org/cover.1376746185.git.ydroneaud-RlY5vtjFyJ3QT0dZR+AlfA@public.gmane.org>
"[PATCH 00/22] infiniband: improve userspace input check"
<http://mid.gmane.org/cover.1376847403.git.ydroneaud-RlY5vtjFyJ3QT0dZR+AlfA@public.gmane.org>
I hope this would be enough to join the gang^Wclub. Where're the
by-laws ?
Regards.
--
Yann Droneaud
OPTEYA
^ permalink raw reply
* [PATCH v4 1/4] scsi: ufs: add ioctl interface for query request
From: Gilad Broner @ 2015-03-02 14:56 UTC (permalink / raw)
To: James.Bottomley
Cc: linux-kernel, linux-scsi, linux-arm-msm, santoshsy,
linux-scsi-owner, subhashj, ygardi, draviv, Noa Rubens,
Raviv Shvili, Vinayak Holikatti, James E.J. Bottomley,
open list:ABI/API
In-Reply-To: <1425308203-20695-1-git-send-email-gbroner@codeaurora.org>
From: Dolev Raviv <draviv@codeaurora.org>
This patch exposes the ioctl interface for UFS driver via SCSI device
ioctl interface. As of now UFS driver would provide the ioctl for query
interface to connected UFS device.
Signed-off-by: Dolev Raviv <draviv@codeaurora.org>
Signed-off-by: Noa Rubens <noag@codeaurora.org>
Signed-off-by: Raviv Shvili <rshvili@codeaurora.org>
Signed-off-by: Yaniv Gardi <ygardi@codeaurora.org>
---
drivers/scsi/ufs/ufs.h | 53 +++-------
drivers/scsi/ufs/ufshcd.c | 225 +++++++++++++++++++++++++++++++++++++++++-
include/uapi/scsi/Kbuild | 1 +
include/uapi/scsi/ufs/Kbuild | 3 +
include/uapi/scsi/ufs/ioctl.h | 57 +++++++++++
include/uapi/scsi/ufs/ufs.h | 66 +++++++++++++
6 files changed, 361 insertions(+), 44 deletions(-)
create mode 100644 include/uapi/scsi/ufs/Kbuild
create mode 100644 include/uapi/scsi/ufs/ioctl.h
create mode 100644 include/uapi/scsi/ufs/ufs.h
diff --git a/drivers/scsi/ufs/ufs.h b/drivers/scsi/ufs/ufs.h
index 42c459a..1f023c4 100644
--- a/drivers/scsi/ufs/ufs.h
+++ b/drivers/scsi/ufs/ufs.h
@@ -38,6 +38,7 @@
#include <linux/mutex.h>
#include <linux/types.h>
+#include <scsi/ufs/ufs.h>
#define MAX_CDB_SIZE 16
#define GENERAL_UPIU_REQUEST_SIZE 32
@@ -71,6 +72,16 @@ enum {
UFS_UPIU_RPMB_WLUN = 0xC4,
};
+/**
+ * ufs_is_valid_unit_desc_lun - checks if the given LUN has a unit descriptor
+ * @lun: LU number to check
+ * @return: true if the lun has a matching unit descriptor, false otherwise
+ */
+static inline bool ufs_is_valid_unit_desc_lun(u8 lun)
+{
+ return (lun == UFS_UPIU_RPMB_WLUN || (lun < UFS_UPIU_MAX_GENERAL_LUN));
+}
+
/*
* UFS Protocol Information Unit related definitions
*/
@@ -126,35 +137,6 @@ enum {
UPIU_QUERY_FUNC_STANDARD_WRITE_REQUEST = 0x81,
};
-/* Flag idn for Query Requests*/
-enum flag_idn {
- QUERY_FLAG_IDN_FDEVICEINIT = 0x01,
- QUERY_FLAG_IDN_PWR_ON_WPE = 0x03,
- QUERY_FLAG_IDN_BKOPS_EN = 0x04,
-};
-
-/* Attribute idn for Query requests */
-enum attr_idn {
- QUERY_ATTR_IDN_ACTIVE_ICC_LVL = 0x03,
- QUERY_ATTR_IDN_BKOPS_STATUS = 0x05,
- QUERY_ATTR_IDN_EE_CONTROL = 0x0D,
- QUERY_ATTR_IDN_EE_STATUS = 0x0E,
-};
-
-/* Descriptor idn for Query requests */
-enum desc_idn {
- QUERY_DESC_IDN_DEVICE = 0x0,
- QUERY_DESC_IDN_CONFIGURAION = 0x1,
- QUERY_DESC_IDN_UNIT = 0x2,
- QUERY_DESC_IDN_RFU_0 = 0x3,
- QUERY_DESC_IDN_INTERCONNECT = 0x4,
- QUERY_DESC_IDN_STRING = 0x5,
- QUERY_DESC_IDN_RFU_1 = 0x6,
- QUERY_DESC_IDN_GEOMETRY = 0x7,
- QUERY_DESC_IDN_POWER = 0x8,
- QUERY_DESC_IDN_MAX,
-};
-
enum desc_header_offset {
QUERY_DESC_LENGTH_OFFSET = 0x00,
QUERY_DESC_DESC_TYPE_OFFSET = 0x01,
@@ -247,19 +229,6 @@ enum bkops_status {
BKOPS_STATUS_MAX = BKOPS_STATUS_CRITICAL,
};
-/* UTP QUERY Transaction Specific Fields OpCode */
-enum query_opcode {
- UPIU_QUERY_OPCODE_NOP = 0x0,
- UPIU_QUERY_OPCODE_READ_DESC = 0x1,
- UPIU_QUERY_OPCODE_WRITE_DESC = 0x2,
- UPIU_QUERY_OPCODE_READ_ATTR = 0x3,
- UPIU_QUERY_OPCODE_WRITE_ATTR = 0x4,
- UPIU_QUERY_OPCODE_READ_FLAG = 0x5,
- UPIU_QUERY_OPCODE_SET_FLAG = 0x6,
- UPIU_QUERY_OPCODE_CLEAR_FLAG = 0x7,
- UPIU_QUERY_OPCODE_TOGGLE_FLAG = 0x8,
-};
-
/* Query response result code */
enum {
QUERY_RESULT_SUCCESS = 0x00,
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 5d60a86..cb357f8 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -3,7 +3,7 @@
*
* This code is based on drivers/scsi/ufs/ufshcd.c
* Copyright (C) 2011-2013 Samsung India Software Operations
- * Copyright (c) 2013-2014, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2013-2015, The Linux Foundation. All rights reserved.
*
* Authors:
* Santosh Yaraganavi <santosh.sy@samsung.com>
@@ -39,6 +39,7 @@
#include <linux/async.h>
#include <linux/devfreq.h>
+#include <scsi/ufs/ioctl.h>
#include "ufshcd.h"
#include "unipro.h"
@@ -74,6 +75,9 @@
/* Interrupt aggregation default timeout, unit: 40us */
#define INT_AGGR_DEF_TO 0x02
+/* IOCTL opcode for command - ufs set device read only */
+#define UFS_IOCTL_BLKROSET BLKROSET
+
#define ufshcd_toggle_vreg(_dev, _vreg, _on) \
({ \
int _ret; \
@@ -1882,7 +1886,7 @@ static inline int ufshcd_read_unit_desc_param(struct ufs_hba *hba,
* Unit descriptors are only available for general purpose LUs (LUN id
* from 0 to 7) and RPMB Well known LU.
*/
- if (lun != UFS_UPIU_RPMB_WLUN && (lun >= UFS_UPIU_MAX_GENERAL_LUN))
+ if (!ufs_is_valid_unit_desc_lun(lun))
return -EOPNOTSUPP;
return ufshcd_read_desc_param(hba, QUERY_DESC_IDN_UNIT, lun,
@@ -4201,6 +4205,222 @@ static void ufshcd_async_scan(void *data, async_cookie_t cookie)
ufshcd_probe_hba(hba);
}
+/**
+ * ufshcd_query_ioctl - perform user read queries
+ * @hba: per-adapter instance
+ * @lun: used for lun specific queries
+ * @buffer: user space buffer for reading and submitting query data and params
+ * @return: 0 for success negative error code otherwise
+ *
+ * Expected/Submitted buffer structure is struct ufs_ioctl_query_data.
+ * It will read the opcode, idn and buf_length parameters, and, put the
+ * response in the buffer field while updating the used size in buf_length.
+ */
+static int ufshcd_query_ioctl(struct ufs_hba *hba, u8 lun, void __user *buffer)
+{
+ struct ufs_ioctl_query_data *ioctl_data;
+ int err = 0;
+ int length = 0;
+ void *data_ptr;
+ bool flag;
+ u32 att;
+ u8 index;
+ u8 *desc = NULL;
+
+ ioctl_data = kzalloc(sizeof(struct ufs_ioctl_query_data), GFP_KERNEL);
+ if (!ioctl_data) {
+ err = -ENOMEM;
+ goto out;
+ }
+
+ /* extract params from user buffer */
+ err = copy_from_user(ioctl_data, buffer,
+ sizeof(struct ufs_ioctl_query_data));
+ if (err) {
+ dev_err(hba->dev,
+ "%s: Failed copying buffer from user, err %d\n",
+ __func__, err);
+ goto out_release_mem;
+ }
+
+ /* verify legal parameters & send query */
+ switch (ioctl_data->opcode) {
+ case UPIU_QUERY_OPCODE_READ_DESC:
+ switch (ioctl_data->idn) {
+ case QUERY_DESC_IDN_DEVICE:
+ case QUERY_DESC_IDN_CONFIGURAION:
+ case QUERY_DESC_IDN_INTERCONNECT:
+ case QUERY_DESC_IDN_GEOMETRY:
+ case QUERY_DESC_IDN_POWER:
+ index = 0;
+ break;
+ case QUERY_DESC_IDN_UNIT:
+ if (!ufs_is_valid_unit_desc_lun(lun)) {
+ dev_err(hba->dev,
+ "%s: No unit descriptor for lun 0x%x\n",
+ __func__, lun);
+ err = -EINVAL;
+ goto out_release_mem;
+ }
+ index = lun;
+ break;
+ default:
+ goto out_einval;
+ }
+ length = min_t(int, QUERY_DESC_MAX_SIZE,
+ ioctl_data->buf_size);
+ desc = kzalloc(length, GFP_KERNEL);
+ if (!desc) {
+ dev_err(hba->dev, "%s: Failed allocating %d bytes\n",
+ __func__, length);
+ err = -ENOMEM;
+ goto out_release_mem;
+ }
+ err = ufshcd_query_descriptor(hba, ioctl_data->opcode,
+ ioctl_data->idn, index, 0, desc, &length);
+ break;
+ case UPIU_QUERY_OPCODE_READ_ATTR:
+ switch (ioctl_data->idn) {
+ case QUERY_ATTR_IDN_BOOT_LU_EN:
+ case QUERY_ATTR_IDN_POWER_MODE:
+ case QUERY_ATTR_IDN_ACTIVE_ICC_LVL:
+ case QUERY_ATTR_IDN_OOO_DATA_EN:
+ case QUERY_ATTR_IDN_BKOPS_STATUS:
+ case QUERY_ATTR_IDN_PURGE_STATUS:
+ case QUERY_ATTR_IDN_MAX_DATA_IN:
+ case QUERY_ATTR_IDN_MAX_DATA_OUT:
+ case QUERY_ATTR_IDN_REF_CLK_FREQ:
+ case QUERY_ATTR_IDN_CONF_DESC_LOCK:
+ case QUERY_ATTR_IDN_MAX_NUM_OF_RTT:
+ case QUERY_ATTR_IDN_EE_CONTROL:
+ case QUERY_ATTR_IDN_EE_STATUS:
+ case QUERY_ATTR_IDN_SECONDS_PASSED:
+ index = 0;
+ break;
+ case QUERY_ATTR_IDN_DYN_CAP_NEEDED:
+ case QUERY_ATTR_IDN_CORR_PRG_BLK_NUM:
+ index = lun;
+ break;
+ default:
+ goto out_einval;
+ }
+ err = ufshcd_query_attr(hba, ioctl_data->opcode,
+ ioctl_data->idn, index, 0, &att);
+ break;
+ case UPIU_QUERY_OPCODE_READ_FLAG:
+ switch (ioctl_data->idn) {
+ case QUERY_FLAG_IDN_FDEVICEINIT:
+ case QUERY_FLAG_IDN_PERMANENT_WPE:
+ case QUERY_FLAG_IDN_PWR_ON_WPE:
+ case QUERY_FLAG_IDN_BKOPS_EN:
+ case QUERY_FLAG_IDN_PURGE_ENABLE:
+ case QUERY_FLAG_IDN_FPHYRESOURCEREMOVAL:
+ case QUERY_FLAG_IDN_BUSY_RTC:
+ break;
+ default:
+ goto out_einval;
+ }
+ err = ufshcd_query_flag(hba, ioctl_data->opcode,
+ ioctl_data->idn, &flag);
+ break;
+ default:
+ goto out_einval;
+ }
+
+ if (err) {
+ dev_err(hba->dev, "%s: Query for idn %d failed\n", __func__,
+ ioctl_data->idn);
+ goto out_release_mem;
+ }
+
+ /*
+ * copy response data
+ * As we might end up reading less data then what is specified in
+ * "ioct_data->buf_size". So we are updating "ioct_data->
+ * buf_size" to what exactly we have read.
+ */
+ switch (ioctl_data->opcode) {
+ case UPIU_QUERY_OPCODE_READ_DESC:
+ ioctl_data->buf_size = min_t(int, ioctl_data->buf_size, length);
+ data_ptr = desc;
+ break;
+ case UPIU_QUERY_OPCODE_READ_ATTR:
+ ioctl_data->buf_size = sizeof(u32);
+ data_ptr = &att;
+ break;
+ case UPIU_QUERY_OPCODE_READ_FLAG:
+ ioctl_data->buf_size = 1;
+ data_ptr = &flag;
+ break;
+ default:
+ BUG_ON(true);
+ }
+
+ /* copy to user */
+ err = copy_to_user(buffer, ioctl_data,
+ sizeof(struct ufs_ioctl_query_data));
+ if (err)
+ dev_err(hba->dev, "%s: Failed copying back to user.\n",
+ __func__);
+ err = copy_to_user(buffer + sizeof(struct ufs_ioctl_query_data),
+ data_ptr, ioctl_data->buf_size);
+ if (err)
+ dev_err(hba->dev, "%s: err %d copying back to user.\n",
+ __func__, err);
+ goto out_release_mem;
+
+out_einval:
+ dev_err(hba->dev,
+ "%s: illegal ufs query ioctl data, opcode 0x%x, idn 0x%x\n",
+ __func__, ioctl_data->opcode, (unsigned int)ioctl_data->idn);
+ err = -EINVAL;
+out_release_mem:
+ kfree(ioctl_data);
+ kfree(desc);
+out:
+ return err;
+}
+
+/**
+ * ufshcd_ioctl - ufs ioctl callback registered in scsi_host
+ * @dev: scsi device required for per LUN queries
+ * @cmd: command opcode
+ * @buffer: user space buffer for transferring data
+ *
+ * Supported commands:
+ * UFS_IOCTL_QUERY
+ */
+static int ufshcd_ioctl(struct scsi_device *dev, int cmd, void __user *buffer)
+{
+ struct ufs_hba *hba = shost_priv(dev->host);
+ int err = 0;
+
+ BUG_ON(!hba);
+ if (!buffer) {
+ dev_err(hba->dev, "%s: User buffer is NULL!\n", __func__);
+ return -EINVAL;
+ }
+
+ switch (cmd) {
+ case UFS_IOCTL_QUERY:
+ pm_runtime_get_sync(hba->dev);
+ err = ufshcd_query_ioctl(hba, ufshcd_scsi_to_upiu_lun(dev->lun),
+ buffer);
+ pm_runtime_put_sync(hba->dev);
+ break;
+ case UFS_IOCTL_BLKROSET:
+ err = -ENOIOCTLCMD;
+ break;
+ default:
+ err = -EINVAL;
+ dev_err(hba->dev, "%s: Illegal ufs-IOCTL cmd %d\n", __func__,
+ cmd);
+ break;
+ }
+
+ return err;
+}
+
static struct scsi_host_template ufshcd_driver_template = {
.module = THIS_MODULE,
.name = UFSHCD,
@@ -4213,6 +4433,7 @@ static struct scsi_host_template ufshcd_driver_template = {
.eh_abort_handler = ufshcd_abort,
.eh_device_reset_handler = ufshcd_eh_device_reset_handler,
.eh_host_reset_handler = ufshcd_eh_host_reset_handler,
+ .ioctl = ufshcd_ioctl,
.this_id = -1,
.sg_tablesize = SG_ALL,
.cmd_per_lun = UFSHCD_CMD_PER_LUN,
diff --git a/include/uapi/scsi/Kbuild b/include/uapi/scsi/Kbuild
index 75746d5..d404525 100644
--- a/include/uapi/scsi/Kbuild
+++ b/include/uapi/scsi/Kbuild
@@ -1,5 +1,6 @@
# UAPI Header export list
header-y += fc/
+header-y += ufs/
header-y += scsi_bsg_fc.h
header-y += scsi_netlink.h
header-y += scsi_netlink_fc.h
diff --git a/include/uapi/scsi/ufs/Kbuild b/include/uapi/scsi/ufs/Kbuild
new file mode 100644
index 0000000..cc3ef20
--- /dev/null
+++ b/include/uapi/scsi/ufs/Kbuild
@@ -0,0 +1,3 @@
+# UAPI Header export list
+header-y += ioctl.h
+header-y += ufs.h
diff --git a/include/uapi/scsi/ufs/ioctl.h b/include/uapi/scsi/ufs/ioctl.h
new file mode 100644
index 0000000..bc4eed7
--- /dev/null
+++ b/include/uapi/scsi/ufs/ioctl.h
@@ -0,0 +1,57 @@
+#ifndef UAPI_UFS_IOCTL_H_
+#define UAPI_UFS_IOCTL_H_
+
+#include <linux/types.h>
+
+/*
+ * IOCTL opcode for ufs queries has the following opcode after
+ * SCSI_IOCTL_GET_PCI
+ */
+#define UFS_IOCTL_QUERY 0x5388
+
+/**
+ * struct ufs_ioctl_query_data - used to transfer data to and from user via ioctl
+ * @opcode: type of data to query (descriptor/attribute/flag)
+ * @idn: id of the data structure
+ * @buf_size: number of allocated bytes/data size on return
+ * @buffer: data location
+ *
+ * Received: buffer and buf_size (available space for transferred data)
+ * Submitted: opcode, idn, length, buf_size
+ */
+struct ufs_ioctl_query_data {
+ /*
+ * User should select one of the opcode defined in "enum query_opcode".
+ * Please check include/uapi/scsi/ufs/ufs.h for the definition of it.
+ * Note that only UPIU_QUERY_OPCODE_READ_DESC,
+ * UPIU_QUERY_OPCODE_READ_ATTR & UPIU_QUERY_OPCODE_READ_FLAG are
+ * supported as of now. All other query_opcode would be considered
+ * invalid.
+ * As of now only read query operations are supported.
+ */
+ __u32 opcode;
+ /*
+ * User should select one of the idn from "enum flag_idn" or "enum
+ * attr_idn" or "enum desc_idn" based on whether opcode above is
+ * attribute, flag or descriptor.
+ * Please check include/uapi/scsi/ufs/ufs.h for the definition of it.
+ */
+ __u8 idn;
+ /*
+ * User should specify the size of the buffer (buffer[0] below) where
+ * it wants to read the query data (attribute/flag/descriptor).
+ * As we might end up reading less data then what is specified in
+ * buf_size. So we are updating buf_size to what exactly we have read.
+ */
+ __u16 buf_size;
+ /*
+ * placeholder for the start of the data buffer where kernel will copy
+ * the query data (attribute/flag/descriptor) read from the UFS device
+ * Note:
+ * For Read Attribute you will have to allocate 4 bytes
+ * For Read Flag you will have to allocate 1 byte
+ */
+ __u8 buffer[0];
+};
+
+#endif /* UAPI_UFS_IOCTL_H_ */
diff --git a/include/uapi/scsi/ufs/ufs.h b/include/uapi/scsi/ufs/ufs.h
new file mode 100644
index 0000000..894ea45
--- /dev/null
+++ b/include/uapi/scsi/ufs/ufs.h
@@ -0,0 +1,66 @@
+#ifndef UAPI_UFS_H_
+#define UAPI_UFS_H_
+
+/* Flag idn for Query Requests*/
+enum flag_idn {
+ QUERY_FLAG_IDN_FDEVICEINIT = 0x01,
+ QUERY_FLAG_IDN_PERMANENT_WPE = 0x02,
+ QUERY_FLAG_IDN_PWR_ON_WPE = 0x03,
+ QUERY_FLAG_IDN_BKOPS_EN = 0x04,
+ QUERY_FLAG_IDN_RESERVED1 = 0x05,
+ QUERY_FLAG_IDN_PURGE_ENABLE = 0x06,
+ QUERY_FLAG_IDN_RESERVED2 = 0x07,
+ QUERY_FLAG_IDN_FPHYRESOURCEREMOVAL = 0x08,
+ QUERY_FLAG_IDN_BUSY_RTC = 0x09,
+};
+
+/* Attribute idn for Query requests */
+enum attr_idn {
+ QUERY_ATTR_IDN_BOOT_LU_EN = 0x00,
+ QUERY_ATTR_IDN_RESERVED = 0x01,
+ QUERY_ATTR_IDN_POWER_MODE = 0x02,
+ QUERY_ATTR_IDN_ACTIVE_ICC_LVL = 0x03,
+ QUERY_ATTR_IDN_OOO_DATA_EN = 0x04,
+ QUERY_ATTR_IDN_BKOPS_STATUS = 0x05,
+ QUERY_ATTR_IDN_PURGE_STATUS = 0x06,
+ QUERY_ATTR_IDN_MAX_DATA_IN = 0x07,
+ QUERY_ATTR_IDN_MAX_DATA_OUT = 0x08,
+ QUERY_ATTR_IDN_DYN_CAP_NEEDED = 0x09,
+ QUERY_ATTR_IDN_REF_CLK_FREQ = 0x0A,
+ QUERY_ATTR_IDN_CONF_DESC_LOCK = 0x0B,
+ QUERY_ATTR_IDN_MAX_NUM_OF_RTT = 0x0C,
+ QUERY_ATTR_IDN_EE_CONTROL = 0x0D,
+ QUERY_ATTR_IDN_EE_STATUS = 0x0E,
+ QUERY_ATTR_IDN_SECONDS_PASSED = 0x0F,
+ QUERY_ATTR_IDN_CNTX_CONF = 0x10,
+ QUERY_ATTR_IDN_CORR_PRG_BLK_NUM = 0x11,
+};
+
+/* Descriptor idn for Query requests */
+enum desc_idn {
+ QUERY_DESC_IDN_DEVICE = 0x0,
+ QUERY_DESC_IDN_CONFIGURAION = 0x1,
+ QUERY_DESC_IDN_UNIT = 0x2,
+ QUERY_DESC_IDN_RFU_0 = 0x3,
+ QUERY_DESC_IDN_INTERCONNECT = 0x4,
+ QUERY_DESC_IDN_STRING = 0x5,
+ QUERY_DESC_IDN_RFU_1 = 0x6,
+ QUERY_DESC_IDN_GEOMETRY = 0x7,
+ QUERY_DESC_IDN_POWER = 0x8,
+ QUERY_DESC_IDN_RFU_2 = 0x9,
+ QUERY_DESC_IDN_MAX,
+};
+
+/* UTP QUERY Transaction Specific Fields OpCode */
+enum query_opcode {
+ UPIU_QUERY_OPCODE_NOP = 0x0,
+ UPIU_QUERY_OPCODE_READ_DESC = 0x1,
+ UPIU_QUERY_OPCODE_WRITE_DESC = 0x2,
+ UPIU_QUERY_OPCODE_READ_ATTR = 0x3,
+ UPIU_QUERY_OPCODE_WRITE_ATTR = 0x4,
+ UPIU_QUERY_OPCODE_READ_FLAG = 0x5,
+ UPIU_QUERY_OPCODE_SET_FLAG = 0x6,
+ UPIU_QUERY_OPCODE_CLEAR_FLAG = 0x7,
+ UPIU_QUERY_OPCODE_TOGGLE_FLAG = 0x8,
+};
+#endif /* UAPI_UFS_H_ */
--
Qualcomm Israel, on behalf of Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
* Re: [PATCH 1/9] HSI: cmt_speech: Add cmt-speech driver
From: Sebastian Reichel @ 2015-03-02 15:26 UTC (permalink / raw)
To: Oliver Neukum
Cc: Peter Ujfalusi, Kai Vehmanen, Pavel Machek, Pali Rohar,
Aaro Koskinen, Ivaylo Dimitrov, linux-omap, linux-kernel,
linux-api, Joni Lapilainen
In-Reply-To: <1425291753.2014.5.camel@neukum.org>
[-- Attachment #1: Type: text/plain, Size: 5284 bytes --]
Hi Oliver,
On Mon, Mar 02, 2015 at 11:22:33AM +0100, Oliver Neukum wrote:
> > +static ssize_t cs_char_read(struct file *file, char __user *buf, size_t count,
> > + loff_t *unused)
> > +{
> > + struct cs_char *csdata = file->private_data;
> > + u32 data;
> > + ssize_t retval;
> > +
> > + if (count < sizeof(data))
> > + return -EINVAL;
> > +
> > + for ( ; ; ) {
> > + DEFINE_WAIT(wait);
> > +
> > + spin_lock_bh(&csdata->lock);
> > + if (!list_empty(&csdata->chardev_queue)) {
> > + data = cs_pop_entry(&csdata->chardev_queue);
> > + } else if (!list_empty(&csdata->dataind_queue)) {
> > + data = cs_pop_entry(&csdata->dataind_queue);
> > + --csdata->dataind_pending;
> > +
> > + } else {
> > + data = 0;
> > + }
> > + spin_unlock_bh(&csdata->lock);
> > +
> > + if (data)
> > + break;
> > + if (file->f_flags & O_NONBLOCK) {
> > + retval = -EAGAIN;
> > + goto out;
> > + } else if (signal_pending(current)) {
> > + retval = -ERESTARTSYS;
> > + goto out;
> > + }
> > + prepare_to_wait_exclusive(&csdata->wait, &wait,
> > + TASK_INTERRUPTIBLE);
> > + schedule();
> > + finish_wait(&csdata->wait, &wait);
> > + }
> > +
> > + retval = put_user(data, (u32 __user *)buf);
> > + if (!retval)
> > + retval = sizeof(data);
> > +
> > +out:
> > + return retval;
> > +}
> > +
> > +static ssize_t cs_char_write(struct file *file, const char __user *buf,
> > + size_t count, loff_t *unused)
> > +{
> > + struct cs_char *csdata = file->private_data;
> > + u32 data;
> > + int err;
> > + ssize_t retval;
> > +
> > + if (count < sizeof(data))
> > + return -EINVAL;
> > +
> > + if (get_user(data, (u32 __user *)buf))
> > + retval = -EFAULT;
> > + else
> > + retval = count;
>
> You want to execute the command even if you got -EFAULT?
> That is highly unusual.
I will change this in PATCHv2.
> > +
> > + err = cs_hsi_command(csdata->hi, data);
> > + if (err < 0)
> > + retval = err;
> > +
> > + return retval;
> > +}
> > +
> > +static long cs_char_ioctl(struct file *file, unsigned int cmd,
> > + unsigned long arg)
> > +{
> > + struct cs_char *csdata = file->private_data;
> > + int r = 0;
> > +
> > + switch (cmd) {
> > + case CS_GET_STATE: {
> > + unsigned int state;
> > +
> > + state = cs_hsi_get_state(csdata->hi);
> > + if (copy_to_user((void __user *)arg, &state, sizeof(state)))
> > + r = -EFAULT;
> > + }
> > + break;
> > + case CS_SET_WAKELINE: {
> > + unsigned int state;
> > +
> > + if (copy_from_user(&state, (void __user *)arg, sizeof(state)))
> > + r = -EFAULT;
> > + else
> > + cs_hsi_set_wakeline(csdata->hi, state);
>
> No sanity checking for state?
Will be added in PATCHv2, so that -EINVAL is returned for values > 1.
> > + }
> > + break;
> > + case CS_GET_IF_VERSION: {
> > + unsigned int ifver = CS_IF_VERSION;
> > +
> > + if (copy_to_user((void __user *)arg, &ifver, sizeof(ifver)))
> > + r = -EFAULT;
> > + break;
> > + }
> > + case CS_CONFIG_BUFS: {
> > + struct cs_buffer_config buf_cfg;
> > +
> > + if (copy_from_user(&buf_cfg, (void __user *)arg,
> > + sizeof(buf_cfg)))
> > + r = -EFAULT;
> > + else
> > + r = cs_hsi_buf_config(csdata->hi, &buf_cfg);
>
> Sanity checking?
cs_hsi_buf_config() calls check_buf_params().
> > + break;
> > + }
> > + default:
> > + r = -ENOTTY;
> > + break;
> > + }
> > +
> > + return r;
> > +}
> > +
> > +static int cs_char_mmap(struct file *file, struct vm_area_struct *vma)
> > +{
> > + if (vma->vm_end < vma->vm_start)
> > + return -EINVAL;
> > +
> > + if (((vma->vm_end - vma->vm_start) >> PAGE_SHIFT) != 1)
> > + return -EINVAL;
> > +
> > + vma->vm_flags |= VM_RESERVED;
> > + vma->vm_ops = &cs_char_vm_ops;
> > + vma->vm_private_data = file->private_data;
> > +
> > + return 0;
> > +}
> > +
> > +static int cs_char_open(struct inode *unused, struct file *file)
> > +{
> > + int ret = 0;
> > +
> > + spin_lock_bh(&cs_char_data.lock);
> > + if (cs_char_data.opened) {
> > + ret = -EBUSY;
> > + spin_unlock_bh(&cs_char_data.lock);
> > + goto out;
> > + }
> > + cs_char_data.mmap_base = get_zeroed_page(GFP_ATOMIC);
>
> This could be moved outside the locked sectionand use GFP_KERNEL.
Right, this is fixed by a follow up patch. I kept the patchset split
to keep authorship information. I guess I can squash the first three
patches, though.
> > + if (!cs_char_data.mmap_base) {
> > + dev_err(&cs_char_data.cl->device,
> > + "Shared memory allocation failed.\n");
> > + ret = -ENOMEM;
> > + spin_unlock_bh(&cs_char_data.lock);
> > + goto out;
> > + }
> > + cs_char_data.mmap_size = CS_MMAP_SIZE;
> > + cs_char_data.dataind_pending = 0;
> > + cs_char_data.opened = 1;
> > + file->private_data = &cs_char_data;
> > + spin_unlock_bh(&cs_char_data.lock);
> > +
> > + BUG_ON(cs_char_data.hi);
> > +
> > + ret = cs_hsi_start(&cs_char_data.hi, cs_char_data.cl,
> > + cs_char_data.mmap_base, cs_char_data.mmap_size);
> > + if (ret) {
> > + dev_err(&cs_char_data.cl->device, "Unable to initialize HSI\n");
> > + free_page(cs_char_data.mmap_base);
> > + goto out;
> > + }
> > +
> > +out:
> > + return ret;
> > +}
-- Sebastian
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] capabilities: Ambient capability set V2
From: Christoph Lameter @ 2015-03-02 15:43 UTC (permalink / raw)
To: Serge E. Hallyn
Cc: Serge Hallyn, Andy Lutomirski, Jonathan Corbet, Aaron Jones,
linux-security-module, linux-kernel, akpm, Andrew G. Morgan,
Mimi Zohar, Austin S Hemmelgarn, Markku Savela, Jarkko Sakkinen,
linux-api, Michael Kerrisk
In-Reply-To: <20150301044407.GA14196@mail.hallyn.com>
On Sat, 28 Feb 2015, Serge E. Hallyn wrote:
> Your example program is not filling in pI though?
The setcap sets the inheritance bit. When the binary runs the i bits
should be set.
> Ah, i see why. In get_file_caps() you are still assigning
>
> fP = pA
>
> if the file has no file capabilities. so then you are actually
> doing
>
> pP' = (X & (fP | pA)) | (pI & (fI | pA))
> rather than
> pP' = (X & fP) | (pI & (fI | pA))
I thought that fP, fI and pI = {} since the file has no caps
so this comes out as
pP' = pA
> Other than that, the patch is looking good to me. We should
> consider emitting an audit record when a task fills in its
How do I do that?
> pA, and I do still wonder whether we should be requiring
> CAP_SETFCAP (unsure how best to think of it). But assuming the
> fP = pA was not intended, I think this largely does the right
> thing.
^ permalink raw reply
* Re: [PATCH v2 04/18] clocksource: Add ARM System timer driver
From: Maxime Coquelin @ 2015-03-02 16:53 UTC (permalink / raw)
To: Paul Bolle, Uwe Kleine-König
Cc: Andreas Färber, Geert Uytterhoeven, Rob Herring,
Philipp Zabel, Jonathan Corbet, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, Russell King, Daniel Lezcano,
Thomas Gleixner, Linus Walleij, Greg Kroah-Hartman, Jiri Slaby,
Arnd Bergmann, Andrew Morton, David S. Miller,
Mauro Carvalho Chehab, Joe Perches, Antti Palosaari, Tejun Heo,
Will Deacon
In-Reply-To: <1424468908.24292.10.camel@x220>
Hi Paul, Uwe,
2015-02-20 22:48 GMT+01:00 Paul Bolle <pebolle@tiscali.nl>:
> On Fri, 2015-02-20 at 20:54 +0100, Uwe Kleine-König wrote:
>> On Fri, Feb 20, 2015 at 07:01:03PM +0100, Maxime Coquelin wrote:
>> > This patch adds clocksource support for ARMv7-M's System timer,
>> > also known as SysTick.
>> >
>> > Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
>> > ---
>> > drivers/clocksource/Kconfig | 7 ++++
>> > drivers/clocksource/Makefile | 1 +
>> > drivers/clocksource/armv7m_systick.c | 78 ++++++++++++++++++++++++++++++++++++
>> > 3 files changed, 86 insertions(+)
>> > create mode 100644 drivers/clocksource/armv7m_systick.c
>> >
>> > diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
>> > index fc01ec2..fb6011e 100644
>> > --- a/drivers/clocksource/Kconfig
>> > +++ b/drivers/clocksource/Kconfig
>> > @@ -124,6 +124,13 @@ config CLKSRC_ARM_GLOBAL_TIMER_SCHED_CLOCK
>> > help
>> > Use ARM global timer clock source as sched_clock
>> >
>> > +config ARMV7M_SYSTICK
>> > + bool
>> I assume this symbol is enabled later in the series.
>
> Yes, I noticed it was selected in 14/18 ("ARM: Add STM32 family
> machine").
>
>> Would it make sense
>> to allow enabing the symbol for compile test coverage?
>>
>> > + select CLKSRC_OF if OF
>> What happens if ARMV7M_SYSTICK=y but OF=n? Doesn't the driver fail to
>> compile?
>>
>> > + select CLKSRC_MMIO
>> > + help
>> > + This options enables support for the ARMv7M system timer unit
>> the right spelling is ARMv7-M.
>
> This Kconfig entry has no prompt, so no one is going to see this text
> during make *config. Perhaps this should be made a comment. In that case
> the right spelling should still be used.
Yes, you are right.
Do you agree if I define it like this:
config ARMV7M_SYSTICK
bool "Clocksource driver for ARMv7-M System timer"
depends on OF && (CPU_V7M || COMPILE_TEST)
select CLKSRC_OF
select CLKSRC_MMIO
help
This options enables clocksource support for the ARMv7-M system
timer unit.
Thanks,
Maxime
>
> Thanks,
>
>
> Paul Bolle
>
^ permalink raw reply
* Re: [PATCH v5 tip 1/7] bpf: make internal bpf API independent of CONFIG_BPF_SYSCALL ifdefs
From: Alexei Starovoitov @ 2015-03-02 16:58 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Masami Hiramatsu, Ingo Molnar, Steven Rostedt, Namhyung Kim,
Arnaldo Carvalho de Melo, Jiri Olsa, David S. Miller,
Peter Zijlstra, Linux API, Network Development, LKML
On Mon, Mar 2, 2015 at 4:26 AM, Daniel Borkmann <daniel@iogearbox.net> wrote:
> On 03/02/2015 12:51 PM, Masami Hiramatsu wrote:
>> (2015/03/02 20:10), Daniel Borkmann wrote:
>>>
>>> Well, currently all possible map types (hash table, array map) that
>>> would actually call into bpf_register_map_type() are only built when
>>> CONFIG_BPF_SYSCALL is enabled (see kernel/bpf/Makefile). I don't think
>>> new map additions should be added that are not under kernel/bpf/ and/or
>>> enabled outside the CONFIG_BPF_SYSCALL, as it should be considered
>>> part of the eBPF core code.
agree. New map types will be only under kernel/bpf/
since this is really core infra that every component should be
able to share.
>>> The difference here (this patch) is simply that we don't want users to
>>> build ifdef spaghetti constructs in user code, so the API that is
>>> actually used by eBPF _users_ is being properly ifdef'ed in the headers.
+1
>> Or, maybe we'd better move them into new include/linux/bpf_prog.h which
>> includes basic include/linux/bpf.h. Then, user can include the bpf_prog.h
>> instead of bpf.h. Also, we can check CONFIG_BPF_SYSCAL=y at the top of
>> bpf_prog.h. This makes things clearer :)
>
> I'm preferring the 1st variant, though. We have currently two native eBPF
> users, that is, socket filters and tc's cls_bpf (queued in net-next) and
> looking at the code/API usage, it's really not that hard, where it would
> justify to move this to an extra header file, really.
agree. new header seems overkill to fix something
that is not an issue today.
^ permalink raw reply
* [PATCH v4 1/5] vfio: implement iommu driver capabilities with an enum
From: Baptiste Reynal @ 2015-03-02 16:58 UTC (permalink / raw)
To: iommu, kvmarm
Cc: open list:VFIO DRIVER, open list:ABI/API, open list,
Alex Williamson, tech
In-Reply-To: <1425315507-29661-1-git-send-email-b.reynal@virtualopensystems.com>
From: Antonios Motakis <a.motakis@virtualopensystems.com>
Currently a VFIO driver's IOMMU capabilities are encoded as a series of
numerical defines. Replace this with an enum for future maintainability.
Signed-off-by: Antonios Motakis <a.motakis@virtualopensystems.com>
Signed-off-by: Baptiste Reynal <b.reynal@virtualopensystems.com>
---
include/uapi/linux/vfio.h | 24 +++++++++++-------------
1 file changed, 11 insertions(+), 13 deletions(-)
diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
index 82889c3..5fb3d46 100644
--- a/include/uapi/linux/vfio.h
+++ b/include/uapi/linux/vfio.h
@@ -19,22 +19,20 @@
/* Kernel & User level defines for VFIO IOCTLs. */
-/* Extensions */
-
-#define VFIO_TYPE1_IOMMU 1
-#define VFIO_SPAPR_TCE_IOMMU 2
-#define VFIO_TYPE1v2_IOMMU 3
/*
- * IOMMU enforces DMA cache coherence (ex. PCIe NoSnoop stripping). This
- * capability is subject to change as groups are added or removed.
+ * Capabilities exposed by the VFIO IOMMU driver. Some capabilities are subject
+ * to change as groups are added or removed.
*/
-#define VFIO_DMA_CC_IOMMU 4
-
-/* Check if EEH is supported */
-#define VFIO_EEH 5
+enum vfio_iommu_cap {
+ VFIO_TYPE1_IOMMU = 1,
+ VFIO_SPAPR_TCE_IOMMU = 2,
+ VFIO_TYPE1v2_IOMMU = 3,
+ VFIO_DMA_CC_IOMMU = 4, /* IOMMU enforces DMA cache coherence
+ (ex. PCIe NoSnoop stripping) */
+ VFIO_EEH = 5, /* Check if EEH is supported */
+ VFIO_TYPE1_NESTING_IOMMU = 6, /* Two-stage IOMMU, implies v2 */
+};
-/* Two-stage IOMMU */
-#define VFIO_TYPE1_NESTING_IOMMU 6 /* Implies v2 */
/*
* The IOCTL interface is designed for extensibility by embedding the
--
2.3.1
^ permalink raw reply related
* [PATCH v4 2/5] vfio: introduce the VFIO_DMA_MAP_FLAG_NOEXEC flag
From: Baptiste Reynal @ 2015-03-02 16:58 UTC (permalink / raw)
To: iommu, kvmarm
Cc: open list:VFIO DRIVER, open list:ABI/API, open list,
Alex Williamson, tech
In-Reply-To: <1425315507-29661-1-git-send-email-b.reynal@virtualopensystems.com>
From: Antonios Motakis <a.motakis@virtualopensystems.com>
We introduce the VFIO_DMA_MAP_FLAG_NOEXEC flag to the VFIO dma map call,
and expose its availability via the capability VFIO_DMA_NOEXEC_IOMMU.
This way the user can control whether the XN flag will be set on the
requested mappings. The IOMMU_NOEXEC flag needs to be available for all
the IOMMUs of the container used.
Signed-off-by: Antonios Motakis <a.motakis@virtualopensystems.com>
Signed-off-by: Baptiste Reynal <b.reynal@virtualopensystems.com>
---
include/uapi/linux/vfio.h | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
index 5fb3d46..30801a7 100644
--- a/include/uapi/linux/vfio.h
+++ b/include/uapi/linux/vfio.h
@@ -31,6 +31,7 @@ enum vfio_iommu_cap {
(ex. PCIe NoSnoop stripping) */
VFIO_EEH = 5, /* Check if EEH is supported */
VFIO_TYPE1_NESTING_IOMMU = 6, /* Two-stage IOMMU, implies v2 */
+ VFIO_DMA_NOEXEC_IOMMU = 7,
};
@@ -397,12 +398,17 @@ struct vfio_iommu_type1_info {
*
* Map process virtual addresses to IO virtual addresses using the
* provided struct vfio_dma_map. Caller sets argsz. READ &/ WRITE required.
+ *
+ * To use the VFIO_DMA_MAP_FLAG_NOEXEC flag, the container must support the
+ * VFIO_DMA_NOEXEC_IOMMU capability. If mappings are created using this flag,
+ * any groups subsequently added to the container must support this capability.
*/
struct vfio_iommu_type1_dma_map {
__u32 argsz;
__u32 flags;
#define VFIO_DMA_MAP_FLAG_READ (1 << 0) /* readable from device */
#define VFIO_DMA_MAP_FLAG_WRITE (1 << 1) /* writable from device */
+#define VFIO_DMA_MAP_FLAG_NOEXEC (1 << 2) /* not executable from device */
__u64 vaddr; /* Process virtual address */
__u64 iova; /* IO virtual address */
__u64 size; /* Size of mapping (bytes) */
--
2.3.1
^ permalink raw reply related
* [PATCH v14 02/20] vfio: platform: probe to devices on the platform bus
From: Baptiste Reynal @ 2015-03-02 16:59 UTC (permalink / raw)
To: iommu, kvmarm
Cc: open list:VFIO DRIVER, open list:ABI/API, open list,
Alex Williamson, tech
In-Reply-To: <1425315600-29761-1-git-send-email-b.reynal@virtualopensystems.com>
From: Antonios Motakis <a.motakis@virtualopensystems.com>
Driver to bind to Linux platform devices, and callbacks to discover their
resources to be used by the main VFIO PLATFORM code.
Signed-off-by: Antonios Motakis <a.motakis@virtualopensystems.com>
Signed-off-by: Baptiste Reynal <b.reynal@virtualopensystems.com>
---
drivers/vfio/platform/vfio_platform.c | 103 ++++++++++++++++++++++++++++++++++
include/uapi/linux/vfio.h | 1 +
2 files changed, 104 insertions(+)
create mode 100644 drivers/vfio/platform/vfio_platform.c
diff --git a/drivers/vfio/platform/vfio_platform.c b/drivers/vfio/platform/vfio_platform.c
new file mode 100644
index 0000000..cef645c
--- /dev/null
+++ b/drivers/vfio/platform/vfio_platform.c
@@ -0,0 +1,103 @@
+/*
+ * Copyright (C) 2013 - Virtual Open Systems
+ * Author: Antonios Motakis <a.motakis@virtualopensystems.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License, version 2, as
+ * published by the Free Software Foundation.
+ *
+ * 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 <linux/module.h>
+#include <linux/slab.h>
+#include <linux/vfio.h>
+#include <linux/platform_device.h>
+
+#include "vfio_platform_private.h"
+
+#define DRIVER_VERSION "0.10"
+#define DRIVER_AUTHOR "Antonios Motakis <a.motakis@virtualopensystems.com>"
+#define DRIVER_DESC "VFIO for platform devices - User Level meta-driver"
+
+/* probing devices from the linux platform bus */
+
+static struct resource *get_platform_resource(struct vfio_platform_device *vdev,
+ int num)
+{
+ struct platform_device *dev = (struct platform_device *) vdev->opaque;
+ int i;
+
+ for (i = 0; i < dev->num_resources; i++) {
+ struct resource *r = &dev->resource[i];
+
+ if (resource_type(r) & (IORESOURCE_MEM|IORESOURCE_IO)) {
+ if (!num)
+ return r;
+
+ num--;
+ }
+ }
+ return NULL;
+}
+
+static int get_platform_irq(struct vfio_platform_device *vdev, int i)
+{
+ struct platform_device *pdev = (struct platform_device *) vdev->opaque;
+
+ return platform_get_irq(pdev, i);
+}
+
+static int vfio_platform_probe(struct platform_device *pdev)
+{
+ struct vfio_platform_device *vdev;
+ int ret;
+
+ vdev = kzalloc(sizeof(*vdev), GFP_KERNEL);
+ if (!vdev)
+ return -ENOMEM;
+
+ vdev->opaque = (void *) pdev;
+ vdev->name = pdev->name;
+ vdev->flags = VFIO_DEVICE_FLAGS_PLATFORM;
+ vdev->get_resource = get_platform_resource;
+ vdev->get_irq = get_platform_irq;
+
+ ret = vfio_platform_probe_common(vdev, &pdev->dev);
+ if (ret)
+ kfree(vdev);
+
+ return ret;
+}
+
+static int vfio_platform_remove(struct platform_device *pdev)
+{
+ struct vfio_platform_device *vdev;
+
+ vdev = vfio_platform_remove_common(&pdev->dev);
+ if (vdev) {
+ kfree(vdev);
+ return 0;
+ }
+
+ return -EINVAL;
+}
+
+static struct platform_driver vfio_platform_driver = {
+ .probe = vfio_platform_probe,
+ .remove = vfio_platform_remove,
+ .driver = {
+ .name = "vfio-platform",
+ .owner = THIS_MODULE,
+ },
+};
+
+module_platform_driver(vfio_platform_driver);
+
+MODULE_VERSION(DRIVER_VERSION);
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR(DRIVER_AUTHOR);
+MODULE_DESCRIPTION(DRIVER_DESC);
diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
index 30801a7..e33b04b 100644
--- a/include/uapi/linux/vfio.h
+++ b/include/uapi/linux/vfio.h
@@ -159,6 +159,7 @@ struct vfio_device_info {
__u32 flags;
#define VFIO_DEVICE_FLAGS_RESET (1 << 0) /* Device supports reset */
#define VFIO_DEVICE_FLAGS_PCI (1 << 1) /* vfio-pci device */
+#define VFIO_DEVICE_FLAGS_PLATFORM (1 << 2) /* vfio-platform device */
__u32 num_regions; /* Max region index + 1 */
__u32 num_irqs; /* Max IRQ index + 1 */
};
--
2.3.1
^ permalink raw reply related
* [PATCH v14 04/20] vfio: amba: VFIO support for AMBA devices
From: Baptiste Reynal @ 2015-03-02 16:59 UTC (permalink / raw)
To: iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
kvmarm-FPEHb7Xf0XXUo1n7N8X6UoWGPAHP3yOg
Cc: open list:VFIO DRIVER, open list:ABI/API, open list,
Antonios Motakis, tech-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J
In-Reply-To: <1425315600-29761-1-git-send-email-b.reynal-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org>
From: Antonios Motakis <a.motakis-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org>
Add support for discovering AMBA devices with VFIO and handle them
similarly to Linux platform devices.
Signed-off-by: Antonios Motakis <a.motakis-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org>
Signed-off-by: Baptiste Reynal <b.reynal-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org>
---
drivers/vfio/platform/vfio_amba.c | 115 ++++++++++++++++++++++++++++++++++++++
include/uapi/linux/vfio.h | 1 +
2 files changed, 116 insertions(+)
create mode 100644 drivers/vfio/platform/vfio_amba.c
diff --git a/drivers/vfio/platform/vfio_amba.c b/drivers/vfio/platform/vfio_amba.c
new file mode 100644
index 0000000..ff0331f
--- /dev/null
+++ b/drivers/vfio/platform/vfio_amba.c
@@ -0,0 +1,115 @@
+/*
+ * Copyright (C) 2013 - Virtual Open Systems
+ * Author: Antonios Motakis <a.motakis-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License, version 2, as
+ * published by the Free Software Foundation.
+ *
+ * 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 <linux/module.h>
+#include <linux/slab.h>
+#include <linux/vfio.h>
+#include <linux/amba/bus.h>
+
+#include "vfio_platform_private.h"
+
+#define DRIVER_VERSION "0.10"
+#define DRIVER_AUTHOR "Antonios Motakis <a.motakis-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org>"
+#define DRIVER_DESC "VFIO for AMBA devices - User Level meta-driver"
+
+/* probing devices from the AMBA bus */
+
+static struct resource *get_amba_resource(struct vfio_platform_device *vdev,
+ int i)
+{
+ struct amba_device *adev = (struct amba_device *) vdev->opaque;
+
+ if (i == 0)
+ return &adev->res;
+
+ return NULL;
+}
+
+static int get_amba_irq(struct vfio_platform_device *vdev, int i)
+{
+ struct amba_device *adev = (struct amba_device *) vdev->opaque;
+ int ret = 0;
+
+ if (i < AMBA_NR_IRQS)
+ ret = adev->irq[i];
+
+ /* zero is an unset IRQ for AMBA devices */
+ return ret ? ret : -ENXIO;
+}
+
+static int vfio_amba_probe(struct amba_device *adev, const struct amba_id *id)
+{
+ struct vfio_platform_device *vdev;
+ int ret;
+
+ vdev = kzalloc(sizeof(*vdev), GFP_KERNEL);
+ if (!vdev)
+ return -ENOMEM;
+
+ vdev->name = kasprintf(GFP_KERNEL, "vfio-amba-%08x", adev->periphid);
+ if (!vdev->name) {
+ kfree(vdev);
+ return -ENOMEM;
+ }
+
+ vdev->opaque = (void *) adev;
+ vdev->flags = VFIO_DEVICE_FLAGS_AMBA;
+ vdev->get_resource = get_amba_resource;
+ vdev->get_irq = get_amba_irq;
+
+ ret = vfio_platform_probe_common(vdev, &adev->dev);
+ if (ret) {
+ kfree(vdev->name);
+ kfree(vdev);
+ }
+
+ return ret;
+}
+
+static int vfio_amba_remove(struct amba_device *adev)
+{
+ struct vfio_platform_device *vdev;
+
+ vdev = vfio_platform_remove_common(&adev->dev);
+ if (vdev) {
+ kfree(vdev->name);
+ kfree(vdev);
+ return 0;
+ }
+
+ return -EINVAL;
+}
+
+static struct amba_id pl330_ids[] = {
+ { 0, 0 },
+};
+
+MODULE_DEVICE_TABLE(amba, pl330_ids);
+
+static struct amba_driver vfio_amba_driver = {
+ .probe = vfio_amba_probe,
+ .remove = vfio_amba_remove,
+ .id_table = pl330_ids,
+ .drv = {
+ .name = "vfio-amba",
+ .owner = THIS_MODULE,
+ },
+};
+
+module_amba_driver(vfio_amba_driver);
+
+MODULE_VERSION(DRIVER_VERSION);
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR(DRIVER_AUTHOR);
+MODULE_DESCRIPTION(DRIVER_DESC);
diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
index e33b04b..da07c1a 100644
--- a/include/uapi/linux/vfio.h
+++ b/include/uapi/linux/vfio.h
@@ -160,6 +160,7 @@ struct vfio_device_info {
#define VFIO_DEVICE_FLAGS_RESET (1 << 0) /* Device supports reset */
#define VFIO_DEVICE_FLAGS_PCI (1 << 1) /* vfio-pci device */
#define VFIO_DEVICE_FLAGS_PLATFORM (1 << 2) /* vfio-platform device */
+#define VFIO_DEVICE_FLAGS_AMBA (1 << 3) /* vfio-amba device */
__u32 num_regions; /* Max region index + 1 */
__u32 num_irqs; /* Max IRQ index + 1 */
};
--
2.3.1
^ permalink raw reply related
* Re: [PATCH v2 16/18] ARM: dts: Introduce STM32F429 MCU
From: Andreas Färber @ 2015-03-02 17:42 UTC (permalink / raw)
To: Maxime Coquelin, u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ,
geert-Td1EMuHUCqxL1ZNQvxDV9g, Rob Herring, Philipp Zabel,
Jonathan Corbet, Pawel Moll, Mark Rutland, Ian Campbell,
Kumar Gala, Russell King, Daniel Lezcano, Thomas Gleixner,
Linus Walleij, Greg Kroah-Hartman, Jiri Slaby, Arnd Bergmann,
Andrew Morton, David S. Miller, Mauro Carvalho Chehab,
Joe Perches, Antti Palosaari, Tejun Heo,
Will Deacon <will.deacon>
In-Reply-To: <1424455277-29983-17-git-send-email-mcoquelin.stm32-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 14096 bytes --]
Hi Maxime,
Please don't put the whole world in To, that makes replying to you much
harder. You can put maintainers in CC instead.
Am 20.02.2015 um 19:01 schrieb Maxime Coquelin:
> The STMicrolectornics's STM32F419 MCU has the following main features:
> - Cortex-M4 core running up to @180MHz
> - 2MB internal flash, 256KBytes internal RAM
> - FMC controller to connect SDRAM, NOR and NAND memories
> - SD/MMC/SDIO support
> - Ethernet controller
> - USB OTFG FS & HS controllers
> - I2C, SPI, CAN busses support
> - Several 16 & 32 bits general purpose timers
> - Serial Audio interface
> - LCD controller
>
> Signed-off-by: Maxime Coquelin <mcoquelin.stm32-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/stm32f429-disco.dts | 41 ++++
> arch/arm/boot/dts/stm32f429.dtsi | 396 ++++++++++++++++++++++++++++++++++
> 3 files changed, 438 insertions(+)
> create mode 100644 arch/arm/boot/dts/stm32f429-disco.dts
> create mode 100644 arch/arm/boot/dts/stm32f429.dtsi
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 91bd5bd..d7da0ef 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -442,6 +442,7 @@ dtb-$(CONFIG_ARCH_STI)+= stih407-b2120.dtb \
> stih416-b2000.dtb \
> stih416-b2020.dtb \
> stih416-b2020e.dtb
> +dtb-$(CONFIG_ARCH_STM32)+= stm32f429-disco.dtb
> dtb-$(CONFIG_MACH_SUN4I) += \
> sun4i-a10-a1000.dtb \
> sun4i-a10-ba10-tvbox.dtb \
> diff --git a/arch/arm/boot/dts/stm32f429-disco.dts b/arch/arm/boot/dts/stm32f429-disco.dts
> new file mode 100644
> index 0000000..0e79cc1
> --- /dev/null
> +++ b/arch/arm/boot/dts/stm32f429-disco.dts
> @@ -0,0 +1,41 @@
Add a suitable license header here? There had been attempts to
dual-license as GPL and MIT/X11.
> +/dts-v1/;
> +#include "stm32f429.dtsi"
> +
> +/ {
> + model = "STMicroelectronics's STM32F429i-DISCO board";
"'s" seems uncommon here and "s's" looks wrong. Just use
"STMicroelectronics STM32F429I-DISCO board"?
> + compatible = "st,stm32f429i-disco", "st,stm32f429";
> +
> + chosen {
> + bootargs = "console=ttyS0,115200 root=/dev/ram rdinit=/linuxrc";
> + linux,stdout-path = &usart1;
I have actually been using USART3, following a guide I found on GitHub.
Which pins do you use for USART1, and is one better than the other?
> + };
> +
> + memory {
> + reg = <0xd0000000 0x800000>;
I have it at 0x90000000!
> + };
> +
> + aliases {
> + ttyS0 = &usart1;
Why ttyS0 here? Shouldn't that be serial0 by convention?
> + };
> +
> + soc {
> + usart1: usart@40011000 {
> + status = "okay";
> + };
This is a new target, so please use the new-style &usart1 {...};
reference rather than replicating the hierarchy.
> +
> + leds {
These LEDs are definitely not on the SoC, they're on the board. Please
move one level up.
> + compatible = "gpio-leds";
In this file you're being parsimonious with newline, yet in the .dtsi
you unnecessarily add newlines before the trailing status property.
> + red {
> + #gpio-cells = <2>;
This looks weird. Drop it?
> + label = "Front Panel LED";
"Front Panel"? Both LEDs are on the front, and several other
architectures avoid spaces in the label for accessing it from /sys.
> + gpios = <&gpiog 14 0>;
GPIO_ACTIVE_HIGH
> + linux,default-trigger = "heartbeat";
Suggest to leave both off by default.
> + };
> + green {
> + #gpio-cells = <2>;
Ditto.
> + gpios = <&gpiog 13 0>;
Ditto.
> + default-state = "off";
> + };
> + };
> + };
> +};
> diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
> new file mode 100644
> index 0000000..5b3442a
> --- /dev/null
> +++ b/arch/arm/boot/dts/stm32f429.dtsi
> @@ -0,0 +1,396 @@
> +/*
> + * Device tree for STM32F429
License?
> + */
> +#include "armv7-m.dtsi"
> +#include <dt-bindings/pinctrl/pinctrl-stm32.h>
> +#include <dt-bindings/reset/st,stm32f429.h>
> +
> +/ {
> +
> + aliases {
> + gpio0 = &gpioa;
> + gpio1 = &gpiob;
> + gpio2 = &gpioc;
> + gpio3 = &gpiod;
> + gpio4 = &gpioe;
> + gpio5 = &gpiof;
> + gpio6 = &gpiog;
> + gpio7 = &gpioh;
> + gpio8 = &gpioi;
> + gpio9 = &gpioj;
> + gpio10 = &gpiok;
> + };
> +
> + clocks {
> + clk_sysclk: clk-sysclk {
> + #clock-cells = <0>;
> + compatible = "fixed-clock";
> + clock-frequency = <180000000>;
> + };
> +
> + clk_hclk: clk-hclk {
> + #clock-cells = <0>;
> + compatible = "fixed-clock";
> + clock-frequency = <180000000>;
> + };
> +
> + clk_pclk1: clk-pclk1 {
> + #clock-cells = <0>;
> + compatible = "fixed-clock";
> + clock-frequency = <45000000>;
> + };
> +
> + clk_pclk2: clk-pclk2 {
> + #clock-cells = <0>;
> + compatible = "fixed-clock";
> + clock-frequency = <90000000>;
> + };
> +
> + clk_pmtr1: clk-pmtr1 {
> + #clock-cells = <0>;
> + compatible = "fixed-clock";
> + clock-frequency = <90000000>;
> + };
> +
> + clk_pmtr2: clk-pmtr2 {
> + #clock-cells = <0>;
> + compatible = "fixed-clock";
> + clock-frequency = <180000000>;
> + };
> +
> + clk_systick: clk-systick {
> + compatible = "fixed-factor-clock";
> + clocks = <&clk_hclk>;
> + #clock-cells = <0>;
> + clock-div = <8>;
> + clock-mult = <1>;
> + };
Most of these should be replaceable with my clk driver.
> + };
> +
> + systick: timer@e000e010 {
> + clocks = <&clk_systick>;
> +
> + status = "okay";
> + };
&systick {...};
> +
> + soc {
> + reset: reset@40023810 {
> + #reset-cells = <1>;
> + compatible = "st,stm32-reset";
> + reg = <0x40023810 0x18>;
> + };
Still, this feels wrong, given that it's an RCC IP block...
> +
> + pin-controller {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "st,stm32-pinctrl";
> + ranges = <0 0x40020000 0x3000>;
> +
> + gpioa: gpio@40020000 {
> + gpio-controller;
> + #gpio-cells = <2>;
> + reg = <0x0 0x400>;
> + resets = <&reset GPIOA_RESET>;
> + st,bank-name = "GPIOA";
> + };
> +
> + gpiob: gpio@40020400 {
> + gpio-controller;
> + #gpio-cells = <2>;
> + reg = <0x400 0x400>;
> + resets = <&reset GPIOB_RESET>;
> + st,bank-name = "GPIOB";
> + };
> +
> + gpioc: gpio@40020800 {
> + gpio-controller;
> + #gpio-cells = <2>;
> + reg = <0x800 0x400>;
> + resets = <&reset GPIOC_RESET>;
> + st,bank-name = "GPIOC";
> + };
> +
> + gpiod: gpio@40020c00 {
> + gpio-controller;
> + #gpio-cells = <2>;
> + reg = <0xc00 0x400>;
> + resets = <&reset GPIOD_RESET>;
> + st,bank-name = "GPIOD";
> + };
> +
> + gpioe: gpio@40021000 {
> + gpio-controller;
> + #gpio-cells = <2>;
> + reg = <0x1000 0x400>;
> + resets = <&reset GPIOE_RESET>;
> + st,bank-name = "GPIOE";
> + };
> +
> + gpiof: gpio@40021400 {
> + gpio-controller;
> + #gpio-cells = <2>;
> + reg = <0x1400 0x400>;
> + resets = <&reset GPIOF_RESET>;
> + st,bank-name = "GPIOF";
> + };
> +
> + gpiog: gpio@40021800 {
> + gpio-controller;
> + #gpio-cells = <2>;
> + reg = <0x1800 0x400>;
> + resets = <&reset GPIOG_RESET>;
> + st,bank-name = "GPIOG";
> + };
> +
> + gpioh: gpio@40021c00 {
> + gpio-controller;
> + #gpio-cells = <2>;
> + reg = <0x1c00 0x400>;
> + resets = <&reset GPIOH_RESET>;
> + st,bank-name = "GPIOH";
> + };
> +
> + gpioi: gpio@40022000 {
> + gpio-controller;
> + #gpio-cells = <2>;
> + reg = <0x2000 0x400>;
> + resets = <&reset GPIOI_RESET>;
> + st,bank-name = "GPIOI";
> + };
> +
> + gpioj: gpio@40022400 {
> + gpio-controller;
> + #gpio-cells = <2>;
> + reg = <0x2400 0x400>;
> + resets = <&reset GPIOJ_RESET>;
> + st,bank-name = "GPIOJ";
> + };
> +
> + gpiok: gpio@40022800 {
> + gpio-controller;
> + #gpio-cells = <2>;
> + reg = <0x2800 0x400>;
> + resets = <&reset GPIOK_RESET>;
> + st,bank-name = "GPIOK";
> + };
> +
> + usart1 {
> + pinctrl_usart1: usart1-0 {
> + st,pins {
> + tx = <&gpioa 9 ALT7 NO_PULL PUSH_PULL LOW_SPEED>;
> + rx = <&gpioa 10 ALT7 NO_PULL>;
> + };
> + };
> + };
> +
> + usart2 {
> + pinctrl_usart2: usart2-0 {
> + st,pins {
> + tx = <&gpioa 2 ALT7 NO_PULL PUSH_PULL LOW_SPEED>;
> + rx = <&gpioa 3 ALT7 NO_PULL>;
> + };
> + };
> + };
> +
> + usart3 {
> + pinctrl_usart3: usart3-0 {
> + st,pins {
> + tx = <&gpiob 10 ALT7 NO_PULL PUSH_PULL LOW_SPEED>;
> + rx = <&gpiob 11 ALT7 NO_PULL>;
> + };
> + };
> + };
> +
> + usart4 {
> + pinctrl_usart4: usart4-0 {
> + st,pins {
> + tx = <&gpioa 0 ALT8 NO_PULL PUSH_PULL LOW_SPEED>;
> + rx = <&gpioa 1 ALT8 NO_PULL>;
> + };
> + };
> + };
> +
> + usart5 {
> + pinctrl_usart5: usart5-0 {
> + st,pins {
> + tx = <&gpioc 12 ALT8 NO_PULL PUSH_PULL LOW_SPEED>;
> + rx = <&gpiod 2 ALT8 NO_PULL>;
> + };
> + };
> + };
> +
> + usart6 {
> + pinctrl_usart6: usart6-0 {
> + st,pins {
> + tx = <&gpioc 6 ALT8 NO_PULL PUSH_PULL LOW_SPEED>;
> + rx = <&gpioc 7 ALT8 NO_PULL>;
> + };
> + };
> + };
> +
> + usart7 {
> + pinctrl_usart7: usart7-0 {
> + st,pins {
> + tx = <&gpioe 8 ALT8 NO_PULL PUSH_PULL LOW_SPEED>;
> + rx = <&gpioe 7 ALT8 NO_PULL>;
> + };
> + };
> + };
> +
> + usart8 {
> + pinctrl_usart8: usart8-0 {
> + st,pins {
> + tx = <&gpioe 1 ALT8 NO_PULL PUSH_PULL LOW_SPEED>;
> + rx = <&gpioe 0 ALT8 NO_PULL>;
> + };
> + };
> + };
Can't the outer level be avoided here to save space and indentation?
> + };
> +
> + timer2: timer@40000000 {
> + compatible = "st,stm32-timer";
> + reg = <0x40000000 0x400>;
> + interrupts = <28>;
> + resets = <&reset TIM2_RESET>;
> + clocks = <&clk_pmtr1>;
> +
> + status = "disabled";
> + };
> +
> + timer3: timer@40000400 {
> + compatible = "st,stm32-timer";
> + reg = <0x40000400 0x400>;
> + interrupts = <29>;
> + resets = <&reset TIM3_RESET>;
> + clocks = <&clk_pmtr1>;
> +
> + status = "disabled";
> + };
> +
> + timer4: timer@40000800 {
> + compatible = "st,stm32-timer";
> + reg = <0x40000800 0x400>;
> + interrupts = <30>;
> + resets = <&reset TIM4_RESET>;
> + clocks = <&clk_pmtr1>;
> +
> + status = "disabled";
> + };
> +
> + timer5: timer@40000c00 {
> + compatible = "st,stm32-timer";
> + reg = <0x40000c00 0x400>;
> + interrupts = <50>;
> + resets = <&reset TIM5_RESET>;
> + clocks = <&clk_pmtr1>;
> + };
> +
> + timer6: timer@40001000 {
> + compatible = "st,stm32-timer";
> + reg = <0x40001000 0x400>;
> + interrupts = <54>;
> + resets = <&reset TIM6_RESET>;
> + clocks = <&clk_pmtr1>;
> +
> + status = "disabled";
> + };
> +
> + timer7: timer@40001400 {
> + compatible = "st,stm32-timer";
> + reg = <0x40001400 0x400>;
> + interrupts = <55>;
> + resets = <&reset TIM7_RESET>;
> + clocks = <&clk_pmtr1>;
> +
> + status = "disabled";
> + };
> +
> + usart1: usart@40011000 {
> + compatible = "st,stm32-usart";
> + reg = <0x40011000 0x400>;
> + interrupts = <37>;
> + clocks = <&clk_pclk2>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usart1>;
> +
> + status = "disabled";
> + };
> +
> + usart2: usart@40004400 {
> + compatible = "st,stm32-usart";
> + reg = <0x40004400 0x400>;
> + interrupts = <38>;
> + clocks = <&clk_pclk1>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usart1>;
Copy&paste, also below. Is this really .dtsi material?
> +
> + status = "disabled";
> + };
> +
> + usart3: usart@40004800 {
> + compatible = "st,stm32-usart";
> + reg = <0x40004800 0x400>;
> + interrupts = <39>;
> + clocks = <&clk_pclk1>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usart1>;
> +
> + status = "disabled";
> + };
> +
> + usart4: usart@40004c00 {
> + compatible = "st,stm32-usart";
> + reg = <0x40004c00 0x400>;
> + interrupts = <52>;
> + clocks = <&clk_pclk1>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usart1>;
> +
> + status = "disabled";
> + };
> +
> + usart5: usart@40005000 {
> + compatible = "st,stm32-usart";
> + reg = <0x40005000 0x400>;
> + interrupts = <53>;
> + clocks = <&clk_pclk1>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usart1>;
> +
> + status = "disabled";
> + };
> +
> + usart6: usart@40011400 {
> + compatible = "st,stm32-usart";
> + reg = <0x40011400 0x400>;
> + interrupts = <71>;
> + clocks = <&clk_pclk2>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usart1>;
> +
> + status = "disabled";
> + };
> +
> + usart7: usart@40007800 {
Please order all nodes by unit address, not by label.
> + compatible = "st,stm32-usart";
> + reg = <0x40007800 0x400>;
> + interrupts = <82>;
> + clocks = <&clk_pclk1>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usart1>;
> +
> + status = "disabled";
> + };
> +
> + usart8: usart@40007c00 {
> + compatible = "st,stm32-usart";
> + reg = <0x40007c00 0x400>;
> + interrupts = <83>;
> + clocks = <&clk_pclk1>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usart1>;
> +
> + status = "disabled";
> + };
I remember two of them not being USART but UART? Similarly, two of them
support flow control (or two don't?), for which we would either need a
property or two different compatible strings.
> + };
> +};
Regards,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu,
Graham Norton; HRB 21284 (AG Nürnberg)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 0/9] N900 Modem Speech Support
From: Pali Rohár @ 2015-03-02 19:05 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Peter Ujfalusi, Kai Vehmanen, Pavel Machek, Aaro Koskinen,
Ivaylo Dimitrov, linux-omap, linux-kernel, linux-api
In-Reply-To: <1425271139-24715-1-git-send-email-sre@kernel.org>
[-- Attachment #1: Type: Text/Plain, Size: 2195 bytes --]
On Monday 02 March 2015 05:38:50 Sebastian Reichel wrote:
> Hi,
>
> This patchset contains the missing speech data support for the
> Nokia N900 modem.
>
> Userland access goes via /dev/cmt_speech. The API is
> implemented in libcmtspeechdata, which is used by ofono and
> the freesmartphone.org project. Apart from that the device is
> also used by the phone binaries distributed with Maemo. So
> while this is a new userland ABI for the mainline kernel it
> has been tested in the wild for some years.
>
> Simple Testing of the API can be done by checking out
> libcmtspeechdata [0], building the test tool and executing
> it. The tool will loop back audio data received from the
> caller.
>
> I have prepared a kernel branch, which includes these changes
> at [1].
>
> [0] https://lkml.org/lkml/2015/2/11/526
> [1]
> git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-hsi.g
> it branch/cmt-speech
>
> -- Sebastian
>
> Kai Vehmanen (3):
> HSI: cmt_speech: Add cmt-speech driver
> HSI: cmt_speech: Avoid GFP_ATOMIC in cs_char_open
> HSI: cmt_speech: Return error if HSI port not configured
>
> Sebastian Reichel (6):
> HSI: cmt_speech: Fix build for 4.0 kernel
> HSI: cmt_speech: Cleanup initialisation
> HSI: cmt_speech: Rename driver to cmt-speech
> HSI: cmt_speech: Move cs-protocol.h to
> include/uapi/linux/hsi HSI: cmt_speech: Remove hardcoded
> channel numbers
> HSI: nokia-modem: Add cmt_speech support
>
> drivers/hsi/clients/Kconfig | 11 +-
> drivers/hsi/clients/Makefile | 1 +
> drivers/hsi/clients/cmt_speech.c | 1451
> ++++++++++++++++++++++++++++++++++
> drivers/hsi/clients/nokia-modem.c | 31 +-
> include/uapi/linux/hsi/Kbuild | 2 +-
> include/uapi/linux/hsi/cs-protocol.h | 113 +++
> 6 files changed, 1606 insertions(+), 3 deletions(-)
> create mode 100644 drivers/hsi/clients/cmt_speech.c
> create mode 100644 include/uapi/linux/hsi/cs-protocol.h
Hello, do you have also DT patches? Or no DT changes are needed?
Is this cmt_speech version one from linux-n900 git tree? or it is
new or modified?
--
Pali Rohár
pali.rohar@gmail.com
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH 0/9] N900 Modem Speech Support
From: Sebastian Reichel @ 2015-03-02 20:51 UTC (permalink / raw)
To: Pali Rohár
Cc: Peter Ujfalusi, Kai Vehmanen, Pavel Machek, Aaro Koskinen,
Ivaylo Dimitrov, linux-omap, linux-kernel, linux-api
In-Reply-To: <201503022005.31729@pali>
[-- Attachment #1: Type: text/plain, Size: 906 bytes --]
Hi,
On Mon, Mar 02, 2015 at 08:05:31PM +0100, Pali Rohár wrote:
> On Monday 02 March 2015 05:38:50 Sebastian Reichel wrote:
> > This patchset contains the missing speech data support for the
> > Nokia N900 modem.
> > [...]
>
> Hello, do you have also DT patches? Or no DT changes are needed?
No DT changes are needed. The DT already contains the n900-modem endpoint
(look for compatible = "nokia,n900-modem"), which is handled by
drivers/hsi/clients/nokia-modem.c.
The nokia-modem driver currently takes care of gpios, irqs, pinctrl
and loads ssi-protocol. After this patchset it also loads
cmt-speech.
> Is this cmt_speech version one from linux-n900 git tree? or it is
> new or modified?
The first 3 patches are from linux-n900 git tree, the other patches
are cleanups and fixups for mainline. Some of those are partly
available in the linux-n900 git tree.
-- Sebastian
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 1/9] HSI: cmt_speech: Add cmt-speech driver
From: Aaro Koskinen @ 2015-03-02 20:56 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Peter Ujfalusi, Kai Vehmanen, Pavel Machek, Pali Rohar,
Ivaylo Dimitrov, linux-omap, linux-kernel, linux-api,
Kai Vehmanen, Carlos Chinea, Joni Lapilainen
In-Reply-To: <1425271139-24715-2-git-send-email-sre@kernel.org>
Hi,
On Mon, Mar 02, 2015 at 05:38:51AM +0100, Sebastian Reichel wrote:
> From: Kai Vehmanen <kai.vehmanen@nokia.com>
>
> Introduces the cmt-speech driver, which implements
> a character device interface for transferring speech
> data frames over HSI/SSI.
>
> The driver is used to exchange voice/speech data between
> the Nokia N900/N950/N9's modem and its cpu.
>
> Signed-off-by: Kai Vehmanen <kai.vehmanen@nokia.com>
> Signed-off-by: Carlos Chinea <carlos.chinea@nokia.com>
> Signed-off-by: Joni Lapilainen <joni.lapilainen@gmail.com>
> Signed-off-by: Sebastian Reichel <sre@kernel.org>
I think the initial mainline kernel submission for this driver should be
a single patch, so just squash all the cleanups and fixes into this one.
You can document the changes you have made by describing the changes
before your own Signed-off-by line.
A.
^ permalink raw reply
* Re: [GIT PULL] Kselftest updates for 3.20-rc1
From: Dave Jones @ 2015-03-02 21:19 UTC (permalink / raw)
To: Michael Ellerman
Cc: Shuah Khan, Linus Torvalds, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1423538165.19657.8.camel-Gsx/Oe8HsFggBc27wqDAHg@public.gmane.org>
On Tue, Feb 10, 2015 at 02:16:05PM +1100, Michael Ellerman wrote:
> > On 02/09/2015 05:43 PM, Michael Ellerman wrote:
> > > On Mon, 2015-02-09 at 17:36 -0700, Shuah Khan wrote:
> > >> On 02/09/2015 05:30 PM, Michael Ellerman wrote:
> > >>> On Mon, 2015-02-09 at 11:36 -0700, Shuah Khan wrote:
> > >>>> Hi Linus,
> > >>>>
> > >>>> Please pull the following Kselftest updates for 3.20-rc1
> > >>>>
> > >>>> thanks,
> > >>>> -- Shuah
> > >>>>
> > >>> ...
> > >>>
> > >>> I don't understand why you insist on merging this series with the logic copied
> > >>> 18 times.
> > >>>
> > >>> I'm happy to tweak my series that uses an include file, but I don't see the
> > >>> point of merging this series first when almost every line will be removed when
> > >>> my series goes in.
> > >>
> > >> Please work on the suggestions I made and rework the patches
> > >> and resend. As I mentioned earlier, I want to enable this work
> > >> and them make improvements.
> > >
> > > Yes I would like install to work to. I'd also like it to work for the powerpc
> > > tests you ignored. But I don't want it to involve copying the same logic into
> > > every Makefile in the tree.
> >
> > > My series was sent over a month ago, with plenty of time for you to merge it
> > > instead of this cut-and-paste solution.
> >
> > I asked you to re-work the patches based on my suggestions
> > and resend. I didn't see any patches from you that addressed
> > the comments. I can't merge the patches you sent without
> > addressing the comments.
>
> Your comments were "please rebase on my series", and as I explained that is
> pointless because my series replaces your series.
Michael's series also has a bunch of features this pull doesn't.
I had started implementing some of these features myself before realizing
this stuff was in limbo. (Especially the ability to install to a
different directory: our use case involves packaging up the latest
selftests for use to be run against a long-term stable kernel).
What needs to happen to unblock this, given that nothing has been
merged so far.
Working on selftests is sort of frustrating with all this stuff pending
given the potential conflicts.
Dave
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox