Re: [RFC PATCH] Randomization of address chosen by mmap.

[Daniel Micay]

On 5 March 2018 at 08:09, Ilya Smith  wrote:
>
>> On 4 Mar 2018, at 23:56, Matthew Wilcox  wrote:
>> Thinking about this more ...
>>
>> - When you call munmap, if you pass in the same (addr, length) that were
>>   used for mmap, then it should unmap the guard pages as well (that
>>   wasn't part of the patch, so it would have to be added)
>> - If 'addr' is higher than the mapped address, and length at least
>>   reaches the end of the mapping, then I would expect the guard pages to
>>   "move down" and be after the end of the newly-shortened mapping.
>> - If 'addr' is higher than the mapped address, and the length doesn't
>>   reach the end of the old mapping, we split the old mapping into two.
>>   I would expect the guard pages to apply to both mappings, insofar as
>>   they'll fit.  For an example, suppose we have a five-page mapping with
>>   two guard pages (MGG), and then we unmap the fourth page.  Now we
>>   have a three-page mapping with one guard page followed immediately
>>   by a one-page mapping with two guard pages (MMMGMGG).
>
> I’m analysing that approach and see much more problems:
> - each time you call mmap like this, you still  increase count of vmas as my
> patch did
> - now feature vma_merge shouldn’t work at all, until MAP_FIXED is set or
> PROT_GUARD(0)
> - the entropy you provide is like 16 bit, that is really not so hard to brute
> - in your patch you don’t use vm_guard at address searching, I see many roots
> of bugs here
> - if you unmap/remap one page inside region, field vma_guard will show head
> or tail pages for vma, not both; kernel don’t know how to handle it
> - user mode now choose entropy with PROT_GUARD macro, where did he gets it?
> User mode shouldn’t be responsible for entropy at all

I didn't suggest this as the way of implementing fine-grained
randomization but rather a small starting point for hardening address
space layout further. I don't think it should be tied to a mmap flag
but rather something like a personality flag or a global sysctl. It
doesn't need to be random at all to be valuable, and it's just a first
step. It doesn't mean there can't be switches between random pivots
like OpenBSD mmap, etc. I'm not so sure that randomly switching around
is going to result in isolating things very well though.

The VMA count issue is at least something very predictable with a
performance cost only for kernel operations.

> I can’t understand what direction this conversation is going to. I was talking
> about weak implementation in Linux kernel but got many comments about ASLR
> should be implemented in user mode what is really weird to me.

That's not what I said. I was saying that splitting things into
regions based on the type of allocation works really well and allows
for high entropy bases, but that the kernel can't really do that right
now. It could split up code that starts as PROT_EXEC into a region but
that's generally not how libraries are mapped in so it won't know
until mprotect which is obviously too late. Unless it had some kind of
type key passed from userspace, it can't really do that.

> I think it is possible  to add GUARD pages into my implementations, but 
> initially
> problem was about entropy of address choosing. I would like to resolve it 
> step by
> step.

Starting with fairly aggressive fragmentation of the address space is
going to be a really hard sell. The costs of a very spread out address
space in terms of TLB misses, etc. are unclear. Starting with enforced
gaps (1 page) and randomization for those wouldn't rule out having
finer-grained randomization, like randomly switching between different
regions. This needs to be cheap enough that people want to enable it,
and the goals need to be clearly spelled out. The goal needs to be
clearer than "more randomization == good" and then accepting a high
performance cost for that.

I'm not dictating how things should be done, I don't have any say
about that. I'm just trying to discuss it.

Re: [PATCH v6 05/20] firmware: arm_scmi: add scmi protocol bus to enumerate protocol devices

[Jonathan Cameron]

On Fri, 23 Feb 2018 16:23:35 +
Sudeep Holla  wrote:

> The SCMI specification encompasses various protocols. However, not every
> protocol has to be present on a given platform/implementation as not
> every protocol is relevant for it.
> 
> Furthermore, the platform chooses which protocols it exposes to a given
> agent. The only protocol that must be implemented is the base protocol.
> The base protocol is used by an agent to discover which protocols are
> available to it.
> 
> In order to enumerate the discovered implemented protocols, this patch
> adds support for a separate scmi protocol bus. It also adds mechanism to
> register support for different protocols.
> 
> Cc: Arnd Bergmann 
> Cc: Greg Kroah-Hartman 
> Signed-off-by: Sudeep Holla 

Comments inline.

Jonathan

> ---
>  drivers/firmware/arm_scmi/Makefile |   3 +-
>  drivers/firmware/arm_scmi/bus.c| 232 
> +
>  drivers/firmware/arm_scmi/common.h |   1 +
>  include/linux/scmi_protocol.h  |  64 ++
>  4 files changed, 299 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/firmware/arm_scmi/bus.c
> 
> diff --git a/drivers/firmware/arm_scmi/Makefile 
> b/drivers/firmware/arm_scmi/Makefile
> index 5d9c7ef35f0f..5f4ec2613db6 100644
> --- a/drivers/firmware/arm_scmi/Makefile
> +++ b/drivers/firmware/arm_scmi/Makefile
> @@ -1,3 +1,4 @@
> -obj-y= scmi-driver.o scmi-protocols.o
> +obj-y= scmi-bus.o scmi-driver.o scmi-protocols.o
> +scmi-bus-y = bus.o
>  scmi-driver-y = driver.o
>  scmi-protocols-y = base.o
> diff --git a/drivers/firmware/arm_scmi/bus.c b/drivers/firmware/arm_scmi/bus.c
> new file mode 100644
> index ..58bb4f46fde1
> --- /dev/null
> +++ b/drivers/firmware/arm_scmi/bus.c
> @@ -0,0 +1,232 @@
> +/*
> + * System Control and Management Interface (SCMI) Message Protocol bus layer
> + *
> + * Copyright (C) 2017 ARM Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope 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.
> + *
> + * You should have received a copy of the GNU General Public License along
> + * with this program. If not, see .
> + */
> +
> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "common.h"
> +
> +static DEFINE_IDA(scmi_bus_id);
> +static DEFINE_IDR(scmi_protocols);
> +static DEFINE_SPINLOCK(protocol_lock);
> +
> +static const struct scmi_device_id *
> +scmi_dev_match_id(struct scmi_device *scmi_dev, struct scmi_driver *scmi_drv)
> +{
> + const struct scmi_device_id *id = scmi_drv->id_table;
> +
> + if (!id)
> + return NULL;
> +
> + for (; id->protocol_id; id++)
> + if (id->protocol_id == scmi_dev->protocol_id)
> + return id;
> +
> + return NULL;
> +}
> +
> +static int scmi_dev_match(struct device *dev, struct device_driver *drv)
> +{
> + struct scmi_driver *scmi_drv = to_scmi_driver(drv);
> + struct scmi_device *scmi_dev = to_scmi_dev(dev);
> + const struct scmi_device_id *id;
> +
> + id = scmi_dev_match_id(scmi_dev, scmi_drv);
> + if (id)
> + return 1;
> +
> + return 0;
> +}
> +
> +static int scmi_protocol_init(int protocol_id, struct scmi_handle *handle)
> +{
> + scmi_prot_init_fn_t fn = idr_find(&scmi_protocols, protocol_id);
> +
> + if (unlikely(!fn))
> + return -EINVAL;
> + return fn(handle);
> +}
> +
> +static int scmi_dev_probe(struct device *dev)
> +{
> + struct scmi_driver *scmi_drv = to_scmi_driver(dev->driver);
> + struct scmi_device *scmi_dev = to_scmi_dev(dev);
> + const struct scmi_device_id *id;
> + int ret;
> +
> + id = scmi_dev_match_id(scmi_dev, scmi_drv);
> + if (!id)
> + return -ENODEV;
> +
> + if (!scmi_dev->handle)
> + return -EPROBE_DEFER;
> +
> + ret = scmi_protocol_init(scmi_dev->protocol_id, scmi_dev->handle);
> + if (ret)
> + return ret;
> +
> + return scmi_drv->probe(scmi_dev);
> +}
> +
> +static int scmi_dev_remove(struct device *dev)
> +{
> + struct scmi_driver *scmi_drv = to_scmi_driver(dev->driver);
> + struct scmi_device *scmi_dev = to_scmi_dev(dev);
> +
> + if (scmi_drv->remove)
> + scmi_drv->remove(scmi_dev);
> +
> + return 0;
> +}
> +
> +static struct bus_type scmi_bus_type = {
> + .name = "scmi_protocol",
> + .match = scmi_dev_match,
> + .probe = scmi_dev_probe,
> + .remove = scmi_dev_remove,
> +};
> +
> +int scmi_driver_register(struct scmi_driver *driver, struct module *owner,
> + 

Re: [PATCH] audit: add containerid support for IMA-audit

[Mimi Zohar]

On Mon, 2018-03-05 at 08:50 -0500, Richard Guy Briggs wrote:
> On 2018-03-05 08:43, Mimi Zohar wrote:
> > Hi Richard,
> > 
> > This patch has been compiled, but not runtime tested.
> 
> Ok, great, thank you.  I assume you are offering this patch to be
> included in this patchset?

Yes, thank you.

> I'll have a look to see where it fits in the
> IMA record.  It might be better if it were an AUDIT_CONTAINER_INFO
> auxiliary record, but I'll have a look at the circumstances of the
> event.  Can you suggest a procedure to test it?

Like IMA-measurement and IMA-appraisal, IMA-audit is enabled based on
policy. The example IMA policy, below, includes IMA-audit messages for
files executed. 'cat' the policy to /sys/kernel/security/ima/policy.

/etc/ima/ima-policy:
audit func=BPRM_CHECK

There's a FireEye blog titled "Extending Linux Executable Logging With
The Integrity Measurement Architecture"* that explains how to augment
their existing system security analytics with file hashes.

* https://www.fireeye.com/blog/threat-research/2016/11/extending_linux
_exec.html


Mimi

> 
> > ---
> > 
> > If the containerid is defined, include it in the IMA-audit record.
> > 
> > Signed-off-by: Mimi Zohar 
> > ---
> >  security/integrity/ima/ima_api.c | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/security/integrity/ima/ima_api.c 
> > b/security/integrity/ima/ima_api.c
> > index 33b4458cdbef..41d29a06f28f 100644
> > --- a/security/integrity/ima/ima_api.c
> > +++ b/security/integrity/ima/ima_api.c
> > @@ -335,6 +335,9 @@ void ima_audit_measurement(struct integrity_iint_cache 
> > *iint,
> > audit_log_untrustedstring(ab, algo_hash);
> >  
> > audit_log_task_info(ab, current);
> > +   if (audit_containerid_set(current))
> > +   audit_log_format(ab, " contid=%llu",
> > +audit_get_containerid(current));
> > audit_log_end(ab);
> >  
> > iint->flags |= IMA_AUDITED;
> > -- 
> > 2.7.5
> > 
> 
> - RGB
> 
> --
> Richard Guy Briggs 
> Sr. S/W Engineer, Kernel Security, Base Operating Systems
> Remote, Ottawa, Red Hat Canada
> IRC: rgb, SunRaycer
> Voice: +1.647.777.2635, Internal: (81) 32635
> 

Re: [PATCH 02/14] perf trace: Apply new perf_mmap__read_event() interface

[Liang, Kan]

On 3/2/2018 6:30 PM, Jiri Olsa wrote:

On Thu, Mar 01, 2018 at 06:08:59PM -0500, kan.li...@linux.intel.com wrote:

From: Kan Liang 

The perf trace still use the legacy interface.

Apply the new perf_mmap__read_event() interface for perf trace.

No functional change.

Signed-off-by: Kan Liang 
---
  tools/perf/builtin-trace.c | 11 +--
  1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
index e7f1b18..a46644f 100644
--- a/tools/perf/builtin-trace.c
+++ b/tools/perf/builtin-trace.c
@@ -2472,8 +2472,14 @@ static int trace__run(struct trace *trace, int argc, 
const char **argv)
  
  	for (i = 0; i < evlist->nr_mmaps; i++) {

union perf_event *event;
+   struct perf_mmap *md;
+   u64 end, start;
  
-		while ((event = perf_evlist__mmap_read(evlist, i)) != NULL) {

+   md = &evlist->mmap[i];
+   if (perf_mmap__read_init(md, 0, &start, &end) < 0)
+   continue;


should we break the loop if this returns -EINVAL?



It only means the ring buffer is broken for current mmaps.
For others, the data should still be good.
I don't think we should drop them by breaking the loop.

Also, the -EINVAL is only valid for overwrite mode. It is impossible to 
return -EINVAL in current code.


Thanks,
Kan


jirka


+
+   while ((event = perf_mmap__read_event(md, 0, &start, end)) != 
NULL) {
struct perf_sample sample;
  
  			++trace->nr_events;

@@ -2486,7 +2492,7 @@ static int trace__run(struct trace *trace, int argc, 
const char **argv)
  
  			trace__handle_event(trace, event, &sample);

  next_event:
-   perf_evlist__mmap_consume(evlist, i);
+   perf_mmap__consume(md, 0);
  
  			if (interrupted)

goto out_disable;
@@ -2496,6 +2502,7 @@ static int trace__run(struct trace *trace, int argc, 
const char **argv)
draining = true;
}
}
+   perf_mmap__read_done(md);
}
  
  	if (trace->nr_events == before) {

--
2.4.11

Re: [PATCH v6 06/20] firmware: arm_scmi: add initial support for performance protocol

[Jonathan Cameron]

On Fri, 23 Feb 2018 16:23:36 +
Sudeep Holla  wrote:

> The performance protocol is intended for the performance management of
> group(s) of device(s) that run in the same performance domain. It
> includes even the CPUs. A performance domain is defined by a set of
> devices that always have to run at the same performance level.
> For example, a set of CPUs that share a voltage domain, and have a
> common frequency control, is said to be in the same performance domain.
> 
> The commands in this protocol provide functionality to describe the
> protocol version, describe various attribute flags, set and get the
> performance level of a domain. It also supports discovery of the list
> of performance levels supported by a performance domain, and the
> properties of each performance level.
> 

> +
> +static int scmi_perf_attributes_get(const struct scmi_handle *handle,
> + struct scmi_perf_info *pi)
> +{
> + int ret;
> + struct scmi_xfer *t;
> + struct scmi_msg_resp_perf_attributes *attr;
> +
> + ret = scmi_one_xfer_init(handle, PROTOCOL_ATTRIBUTES,
> +  SCMI_PROTOCOL_PERF, 0, sizeof(*attr), &t);
> + if (ret)
> + return ret;
> +
> + attr = t->rx.buf;
> +
> + ret = scmi_do_xfer(handle, t);
> + if (!ret) {
Use a goto for the error path rather than indenting all this good path stuff.
The same would help readability in various other places.

> + u16 flags = le16_to_cpu(attr->flags);
> +
> + pi->num_domains = le16_to_cpu(attr->num_domains);
> + pi->power_scale_mw = POWER_SCALE_IN_MILLIWATT(flags);
> + pi->stats_addr = le32_to_cpu(attr->stats_addr_low) |
> + (u64)le32_to_cpu(attr->stats_addr_high) << 32;
> + pi->stats_size = le32_to_cpu(attr->stats_size);
> + }
> +
> + scmi_one_xfer_put(handle, t);
> + return ret;
> +}
> +
...
> +
> +static struct scmi_perf_ops perf_ops = {
> + .limits_set = scmi_perf_limits_set,
> + .limits_get = scmi_perf_limits_get,
> + .level_set = scmi_perf_level_set,
> + .level_get = scmi_perf_level_get,
> + .device_domain_id = scmi_dev_domain_id,
> + .get_transition_latency = scmi_dvfs_get_transition_latency,
> + .add_opps_to_device = scmi_dvfs_add_opps_to_device,
> + .freq_set = scmi_dvfs_freq_set,
> + .freq_get = scmi_dvfs_freq_get,
> +};
> +
> +static int scmi_perf_protocol_init(struct scmi_handle *handle)
> +{
> + int domain;
> + u32 version;
> + struct scmi_perf_info *pinfo;
> +
> + scmi_version_get(handle, SCMI_PROTOCOL_PERF, &version);
> +
> + dev_dbg(handle->dev, "Performance Version %d.%d\n",
> + PROTOCOL_REV_MAJOR(version), PROTOCOL_REV_MINOR(version));
> +
> + pinfo = devm_kzalloc(handle->dev, sizeof(*pinfo), GFP_KERNEL);
> + if (!pinfo)
> + return -ENOMEM;
> +
> + scmi_perf_attributes_get(handle, pinfo);
> +
> + pinfo->dom_info = devm_kcalloc(handle->dev, pinfo->num_domains,
> +sizeof(*pinfo->dom_info), GFP_KERNEL);
> + if (!pinfo->dom_info)
> + return -ENOMEM;
> +
> + for (domain = 0; domain < pinfo->num_domains; domain++) {
> + struct perf_dom_info *dom = pinfo->dom_info + domain;
> +
> + scmi_perf_domain_attributes_get(handle, domain, dom);
> + scmi_perf_describe_levels_get(handle, domain, dom);
> + }
> +
> + handle->perf_ops = &perf_ops;
> + handle->perf_priv = pinfo;
> +
> + return 0;
> +}
> +
> +static int __init scmi_perf_init(void)
> +{
> + return scmi_protocol_register(SCMI_PROTOCOL_PERF,
> +   &scmi_perf_protocol_init);
> +}
> +subsys_initcall(scmi_perf_init);
> diff --git a/include/linux/scmi_protocol.h b/include/linux/scmi_protocol.h
> index db995126134d..d80f4c9a0fad 100644
> --- a/include/linux/scmi_protocol.h
> +++ b/include/linux/scmi_protocol.h
> @@ -44,15 +44,57 @@ struct scmi_revision_info {
>   char sub_vendor_id[SCMI_MAX_STR_SIZE];
>  };
>  
> +struct scmi_handle;
> +
> +/**
> + * struct scmi_perf_ops - represents the various operations provided
> + *   by SCMI Performance Protocol
> + *
> + * @limits_set: sets limits on the performance level of a domain
> + * @limits_get: gets limits on the performance level of a domain
> + * @level_set: sets the performance level of a domain
> + * @level_get: gets the performance level of a domain
> + * @device_domain_id: gets the scmi domain id for a given device
> + * @get_transition_latency: gets the DVFS transition latency for a given 
> device
> + * @add_opps_to_device: adds all the OPPs for a given device
> + * @freq_set: sets the frequency for a given device using sustained frequency
> + *   to sustained performance level mapping
> + * @freq_get: gets the frequency for a given device using sustained frequency
> + *   to sustained performance level mapping
> + */
> +struct scmi_

[PATCH 01/28] perf kallsyms: Fix the usage on the man page

[Arnaldo Carvalho de Melo]

From: Sangwon Hong 

First, all man pages highlight only perf and subcommands except 'perf
kallsyms', which includes the full usage. Fix it for commands to
monopolize underlines.

Second, options can be ommited when executing 'perf kallsyms', so add
square brackets between .

Signed-off-by: Sangwon Hong 
Acked-by: Namhyung Kim 
Cc: Jiri Olsa 
Cc: Taeung Song 
Link: 
http://lkml.kernel.org/r/1518377864-20353-1-git-send-email-qpa...@gmail.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/Documentation/perf-kallsyms.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/Documentation/perf-kallsyms.txt 
b/tools/perf/Documentation/perf-kallsyms.txt
index 954ea9e21236..cf9f4040ea5c 100644
--- a/tools/perf/Documentation/perf-kallsyms.txt
+++ b/tools/perf/Documentation/perf-kallsyms.txt
@@ -8,7 +8,7 @@ perf-kallsyms - Searches running kernel for symbols
 SYNOPSIS
 
 [verse]
-'perf kallsyms  symbol_name[,symbol_name...]'
+'perf kallsyms' [] symbol_name[,symbol_name...]
 
 DESCRIPTION
 ---
-- 
2.14.3

[PATCH 03/28] perf cgroup: Simplify arguments when tracking multiple events

[Arnaldo Carvalho de Melo]

From: weiping zhang 

When using -G with one cgroup and -e with multiple events, only the
first event gets the correct cgroup setting, all events from the second
onwards will track system-wide events.

If the user wants to track multiple events for a specific cgroup, the
user must give parameters like the following:

  $ perf stat -e e1 -e e2 -e e3 -G test,test,test

This patch simplify this case, just type one cgroup:

  $ perf stat -e e1 -e e2 -e e3 -G test

  $ mkdir -p /sys/fs/cgroup/perf_event/empty_cgroup
  $ perf stat -e cycles -e cache-misses -a -I 1000 -G empty_cgroup

Before:

 1.001007226 cycles   empty_cgroup
 1.001007226   7,506  cache-misses

After:

 1.000834097 cycles   empty_cgroup
 1.000834097 cache-misses empty_cgroup

Signed-off-by: weiping zhang 
Acked-by: Jiri Olsa 
Tested-by: Arnaldo Carvalho de Melo 
Cc: Alexander Shishkin 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/20180129154805.ga6...@localhost.didichuxing.com
[ Improved the doc text a bit, providing an example for cgroup + system wide 
counting ]
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/Documentation/perf-record.txt |  6 +-
 tools/perf/Documentation/perf-stat.txt   |  6 +-
 tools/perf/util/cgroup.c | 17 -
 3 files changed, 26 insertions(+), 3 deletions(-)

diff --git a/tools/perf/Documentation/perf-record.txt 
b/tools/perf/Documentation/perf-record.txt
index 3eea6de35a38..76bc2181d214 100644
--- a/tools/perf/Documentation/perf-record.txt
+++ b/tools/perf/Documentation/perf-record.txt
@@ -308,7 +308,11 @@ can be provided. Each cgroup is applied to the 
corresponding event, i.e., first
 to first event, second cgroup to second event and so on. It is possible to 
provide
 an empty cgroup (monitor all the time) using, e.g., -G foo,,bar. Cgroups must 
have
 corresponding events, i.e., they always refer to events defined earlier on the 
command
-line.
+line. If the user wants to track multiple events for a specific cgroup, the 
user can
+use '-e e1 -e e2 -G foo,foo' or just use '-e e1 -e e2 -G foo'.
+
+If wanting to monitor, say, 'cycles' for a cgroup and also for system wide, 
this
+command line can be used: 'perf stat -e cycles -G cgroup_name -a -e cycles'.
 
 -b::
 --branch-any::
diff --git a/tools/perf/Documentation/perf-stat.txt 
b/tools/perf/Documentation/perf-stat.txt
index 2bbe79a50d3c..2b38e222016a 100644
--- a/tools/perf/Documentation/perf-stat.txt
+++ b/tools/perf/Documentation/perf-stat.txt
@@ -118,7 +118,11 @@ can be provided. Each cgroup is applied to the 
corresponding event, i.e., first
 to first event, second cgroup to second event and so on. It is possible to 
provide
 an empty cgroup (monitor all the time) using, e.g., -G foo,,bar. Cgroups must 
have
 corresponding events, i.e., they always refer to events defined earlier on the 
command
-line.
+line. If the user wants to track multiple events for a specific cgroup, the 
user can
+use '-e e1 -e e2 -G foo,foo' or just use '-e e1 -e e2 -G foo'.
+
+If wanting to monitor, say, 'cycles' for a cgroup and also for system wide, 
this
+command line can be used: 'perf stat -e cycles -G cgroup_name -a -e cycles'.
 
 -o file::
 --output file::
diff --git a/tools/perf/util/cgroup.c b/tools/perf/util/cgroup.c
index 984f69144f87..5dd9b5ea314d 100644
--- a/tools/perf/util/cgroup.c
+++ b/tools/perf/util/cgroup.c
@@ -157,9 +157,11 @@ int parse_cgroups(const struct option *opt __maybe_unused, 
const char *str,
  int unset __maybe_unused)
 {
struct perf_evlist *evlist = *(struct perf_evlist **)opt->value;
+   struct perf_evsel *counter;
+   struct cgroup_sel *cgrp = NULL;
const char *p, *e, *eos = str + strlen(str);
char *s;
-   int ret;
+   int ret, i;
 
if (list_empty(&evlist->entries)) {
fprintf(stderr, "must define events before cgroups\n");
@@ -188,5 +190,18 @@ int parse_cgroups(const struct option *opt __maybe_unused, 
const char *str,
break;
str = p+1;
}
+   /* for the case one cgroup combine to multiple events */
+   i = 0;
+   if (nr_cgroups == 1) {
+   evlist__for_each_entry(evlist, counter) {
+   if (i == 0)
+   cgrp = counter->cgrp;
+   else {
+   counter->cgrp = cgrp;
+   refcount_inc(&cgrp->refcnt);
+   }
+   i++;
+   }
+   }
return 0;
 }
-- 
2.14.3

[PATCH 0/6] Support for fsl-mc bus and its devices in SMMU

[Nipun Gupta]

This patchset defines IOMMU DT binding for fsl-mc bus and adds
support in SMMU for fsl-mc bus.

These patches
  - Define the new property 'iommu-parent' for fsl-mc bus (patch 1)
  - Integrates the fsl-mc bus with the SMMU using this
IOMMU binding (patch 2,3)
  - Adds the dma-mapping support for fsl-mc bus (patch 4,5)
  - Updates the fsl-mc device node with iommu/dma related changes

This patchset is based on staging-testing tree where fsl-mc bus is out
from staging

This patchset is dependent on patch 
https://patchwork.kernel.org/patch/10207507/;
otherwise DPAA2 Ethernet driver functionality will break.

Nipun Gupta (6):
  Docs: dt: add fsl-mc iommu-parent device-tree binding
  iommu: support iommu configuration for fsl-mc devices
  iommu: arm-smmu: Add support for the fsl-mc bus
  bus: fsl-mc: remove dma ops setup from driver
  dma-mapping: support fsl-mc bus
  dts: fsl-ls208x: updated DT with SMMU support for fsl-mc

 .../devicetree/bindings/misc/fsl,qoriq-mc.txt  | 31 ++
 arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi |  6 -
 drivers/base/dma-mapping.c |  7 +
 drivers/bus/fsl-mc/fsl-mc-bus.c|  5 +---
 drivers/iommu/arm-smmu.c   |  7 +
 drivers/iommu/iommu.c  | 21 +++
 drivers/iommu/of_iommu.c   | 23 
 include/linux/fsl/mc.h |  8 ++
 include/linux/iommu.h  |  2 ++
 9 files changed, 105 insertions(+), 5 deletions(-)

-- 
1.9.1

[PATCH 2/6] iommu: support iommu configuration for fsl-mc devices

[Nipun Gupta]

Signed-off-by: Nipun Gupta 
---
 drivers/iommu/of_iommu.c | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index 5c36a8b..cc2fb9c 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define NO_IOMMU   1
 
@@ -160,6 +161,26 @@ static int of_pci_iommu_init(struct pci_dev *pdev, u16 
alias, void *data)
return err;
 }
 
+static int
+of_fsl_mc_iommu_init(struct fsl_mc_device *mc_dev,
+ struct device_node *master_np)
+{
+   struct of_phandle_args iommu_spec;
+   int err;
+
+   iommu_spec.np = of_parse_phandle(master_np, "iommu-parent", 0);
+   if (!iommu_spec.np)
+   return NO_IOMMU;
+
+   iommu_spec.args[0] = mc_dev->icid;
+   iommu_spec.args_count = 1;
+
+   err = of_iommu_xlate(&mc_dev->dev, &iommu_spec);
+   of_node_put(iommu_spec.np);
+
+   return err;
+}
+
 const struct iommu_ops *of_iommu_configure(struct device *dev,
   struct device_node *master_np)
 {
@@ -191,6 +212,8 @@ const struct iommu_ops *of_iommu_configure(struct device 
*dev,
 
err = pci_for_each_dma_alias(to_pci_dev(dev),
 of_pci_iommu_init, &info);
+   } else if (dev_is_fsl_mc(dev)) {
+   err = of_fsl_mc_iommu_init(to_fsl_mc_device(dev), master_np);
} else {
struct of_phandle_args iommu_spec;
int idx = 0;
-- 
1.9.1

[PATCH 20/28] perf test: Switch to new perf_mmap__read_event() interface for "keep tracking" test

[Arnaldo Carvalho de Melo]

From: Kan Liang 

The perf test 'keep tracking' still use the legacy interface.

No functional change.

Committer testing:

  # perf test tracking
  25: Use a dummy software event to keep tracking   : Ok
  #

Signed-off-by: Kan Liang 
Tested-by: Arnaldo Carvalho de Melo 
Cc: Andi Kleen 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Wang Nan 
Link: 
http://lkml.kernel.org/r/1519945751-37786-6-git-send-email-kan.li...@linux.intel.com
[ Changed bool parameters from 0 to 'false', as per Jiri comment ]
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/tests/keep-tracking.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/tools/perf/tests/keep-tracking.c b/tools/perf/tests/keep-tracking.c
index c46530918938..4590d8fb91ab 100644
--- a/tools/perf/tests/keep-tracking.c
+++ b/tools/perf/tests/keep-tracking.c
@@ -27,18 +27,24 @@
 static int find_comm(struct perf_evlist *evlist, const char *comm)
 {
union perf_event *event;
+   struct perf_mmap *md;
+   u64 end, start;
int i, found;
 
found = 0;
for (i = 0; i < evlist->nr_mmaps; i++) {
-   while ((event = perf_evlist__mmap_read(evlist, i)) != NULL) {
+   md = &evlist->mmap[i];
+   if (perf_mmap__read_init(md, false, &start, &end) < 0)
+   continue;
+   while ((event = perf_mmap__read_event(md, false, &start, end)) 
!= NULL) {
if (event->header.type == PERF_RECORD_COMM &&
(pid_t)event->comm.pid == getpid() &&
(pid_t)event->comm.tid == getpid() &&
strcmp(event->comm.comm, comm) == 0)
found += 1;
-   perf_evlist__mmap_consume(evlist, i);
+   perf_mmap__consume(md, false);
}
+   perf_mmap__read_done(md);
}
return found;
 }
-- 
2.14.3

[PATCH 18/28] perf test: Switch to new perf_mmap__read_event() interface for bpf

[Arnaldo Carvalho de Melo]

From: Kan Liang 

The perf test 'bpf' still use the legacy interface.

No functional change.

Committer notes:

Tested with:

  # perf test bpf
  39: BPF filter:
  39.1: Basic BPF filtering : Ok
  39.2: BPF pinning : Ok
  39.3: BPF prologue generation : Ok
  39.4: BPF relocation checker  : Ok
  #

Signed-off-by: Kan Liang 
Tested-by: Arnaldo Carvalho de Melo 
Cc: Andi Kleen 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Wang Nan 
Link: 
http://lkml.kernel.org/r/1519945751-37786-4-git-send-email-kan.li...@linux.intel.com
[ Changed bool parameters from 0 to 'false', as per Jiri comment ]
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/tests/bpf.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/tools/perf/tests/bpf.c b/tools/perf/tests/bpf.c
index e8399beca62b..09c9c9f9e827 100644
--- a/tools/perf/tests/bpf.c
+++ b/tools/perf/tests/bpf.c
@@ -176,13 +176,20 @@ static int do_test(struct bpf_object *obj, int 
(*func)(void),
 
for (i = 0; i < evlist->nr_mmaps; i++) {
union perf_event *event;
+   struct perf_mmap *md;
+   u64 end, start;
 
-   while ((event = perf_evlist__mmap_read(evlist, i)) != NULL) {
+   md = &evlist->mmap[i];
+   if (perf_mmap__read_init(md, false, &start, &end) < 0)
+   continue;
+
+   while ((event = perf_mmap__read_event(md, false, &start, end)) 
!= NULL) {
const u32 type = event->header.type;
 
if (type == PERF_RECORD_SAMPLE)
count ++;
}
+   perf_mmap__read_done(md);
}
 
if (count != expect) {
-- 
2.14.3

[PATCH 4/6] bus: fsl-mc: remove dma ops setup from driver

[Nipun Gupta]

The dma setup for fsl-mc devices is being done from device_add()
function. So, no need to call in mc bus driver.

Signed-off-by: Nipun Gupta 
---
 drivers/bus/fsl-mc/fsl-mc-bus.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c b/drivers/bus/fsl-mc/fsl-mc-bus.c
index 1b333c4..c9a239a 100644
--- a/drivers/bus/fsl-mc/fsl-mc-bus.c
+++ b/drivers/bus/fsl-mc/fsl-mc-bus.c
@@ -616,6 +616,7 @@ int fsl_mc_device_add(struct fsl_mc_obj_desc *obj_desc,
mc_dev->icid = parent_mc_dev->icid;
mc_dev->dma_mask = FSL_MC_DEFAULT_DMA_MASK;
mc_dev->dev.dma_mask = &mc_dev->dma_mask;
+   mc_dev->dev.coherent_dma_mask = mc_dev->dma_mask;
dev_set_msi_domain(&mc_dev->dev,
   dev_get_msi_domain(&parent_mc_dev->dev));
}
@@ -633,10 +634,6 @@ int fsl_mc_device_add(struct fsl_mc_obj_desc *obj_desc,
goto error_cleanup_dev;
}
 
-   /* Objects are coherent, unless 'no shareability' flag set. */
-   if (!(obj_desc->flags & FSL_MC_OBJ_FLAG_NO_MEM_SHAREABILITY))
-   arch_setup_dma_ops(&mc_dev->dev, 0, 0, NULL, true);
-
/*
 * The device-specific probe callback will get invoked by device_add()
 */
-- 
1.9.1

[PATCH 22/28] perf test: Switch to new perf_mmap__read_event() interface for tp fields

[Arnaldo Carvalho de Melo]

From: Kan Liang 

The perf test 'syscalls:sys_enter_openat event fields' still use the
legacy interface.

No functional change.

Committer notes:

Testing it:

  # perf test sys_enter_openat
  15: syscalls:sys_enter_openat event fields: Ok
  #

Signed-off-by: Kan Liang 
Tested-by: Arnaldo Carvalho de Melo 
Cc: Andi Kleen 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Wang Nan 
Link: 
http://lkml.kernel.org/r/1519945751-37786-8-git-send-email-kan.li...@linux.intel.com
[ Changed bool parameters from 0 to 'false', as per Jiri comment ]
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/tests/openat-syscall-tp-fields.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/tools/perf/tests/openat-syscall-tp-fields.c 
b/tools/perf/tests/openat-syscall-tp-fields.c
index 43519267b93b..620b21023f72 100644
--- a/tools/perf/tests/openat-syscall-tp-fields.c
+++ b/tools/perf/tests/openat-syscall-tp-fields.c
@@ -86,8 +86,14 @@ int test__syscall_openat_tp_fields(struct test *test 
__maybe_unused, int subtest
 
for (i = 0; i < evlist->nr_mmaps; i++) {
union perf_event *event;
+   struct perf_mmap *md;
+   u64 end, start;
 
-   while ((event = perf_evlist__mmap_read(evlist, i)) != 
NULL) {
+   md = &evlist->mmap[i];
+   if (perf_mmap__read_init(md, false, &start, &end) < 0)
+   continue;
+
+   while ((event = perf_mmap__read_event(md, false, 
&start, end)) != NULL) {
const u32 type = event->header.type;
int tp_flags;
struct perf_sample sample;
@@ -95,7 +101,7 @@ int test__syscall_openat_tp_fields(struct test *test 
__maybe_unused, int subtest
++nr_events;
 
if (type != PERF_RECORD_SAMPLE) {
-   perf_evlist__mmap_consume(evlist, i);
+   perf_mmap__consume(md, false);
continue;
}
 
@@ -115,6 +121,7 @@ int test__syscall_openat_tp_fields(struct test *test 
__maybe_unused, int subtest
 
goto out_ok;
}
+   perf_mmap__read_done(md);
}
 
if (nr_events == before)
-- 
2.14.3

[PATCH 27/28] perf test: Switch to new perf_mmap__read_event() interface for task-exit

[Arnaldo Carvalho de Melo]

From: Kan Liang 

The perf test 'task-exit' still use the legacy interface.

No functional change.

Committer notes:

Testing it:

  # perf test exit
  21: Number of exit events of a simple workload: Ok
  #

Signed-off-by: Kan Liang 
Tested-by: Arnaldo Carvalho de Melo 
Cc: Andi Kleen 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Wang Nan 
Link: 
http://lkml.kernel.org/r/1519945751-37786-13-git-send-email-kan.li...@linux.intel.com
[ Changed bool parameters from 0 to 'false', as per Jiri comment ]
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/tests/task-exit.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/tools/perf/tests/task-exit.c b/tools/perf/tests/task-exit.c
index 01b62b81751b..02b0888b72a3 100644
--- a/tools/perf/tests/task-exit.c
+++ b/tools/perf/tests/task-exit.c
@@ -47,6 +47,8 @@ int test__task_exit(struct test *test __maybe_unused, int 
subtest __maybe_unused
char sbuf[STRERR_BUFSIZE];
struct cpu_map *cpus;
struct thread_map *threads;
+   struct perf_mmap *md;
+   u64 end, start;
 
signal(SIGCHLD, sig_handler);
 
@@ -110,13 +112,19 @@ int test__task_exit(struct test *test __maybe_unused, int 
subtest __maybe_unused
perf_evlist__start_workload(evlist);
 
 retry:
-   while ((event = perf_evlist__mmap_read(evlist, 0)) != NULL) {
+   md = &evlist->mmap[0];
+   if (perf_mmap__read_init(md, false, &start, &end) < 0)
+   goto out_init;
+
+   while ((event = perf_mmap__read_event(md, false, &start, end)) != NULL) 
{
if (event->header.type == PERF_RECORD_EXIT)
nr_exit++;
 
-   perf_evlist__mmap_consume(evlist, 0);
+   perf_mmap__consume(md, false);
}
+   perf_mmap__read_done(md);
 
+out_init:
if (!exited || !nr_exit) {
perf_evlist__poll(evlist, -1);
goto retry;
-- 
2.14.3

[PATCH 08/28] perf tests: Rename trace+probe_libc_inet_pton to record+probe_libc_inet_pton

[Arnaldo Carvalho de Melo]

From: Jiri Olsa 

Because the test is no longer using perf trace but perf record instead.

Signed-off-by: Jiri Olsa 
Tested-by: Arnaldo Carvalho de Melo 
Cc: Alexander Shishkin 
Cc: David Ahern 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/20180301165215.6780-2-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 .../{trace+probe_libc_inet_pton.sh => record+probe_libc_inet_pton.sh} | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename tools/perf/tests/shell/{trace+probe_libc_inet_pton.sh => 
record+probe_libc_inet_pton.sh} (100%)

diff --git a/tools/perf/tests/shell/trace+probe_libc_inet_pton.sh 
b/tools/perf/tests/shell/record+probe_libc_inet_pton.sh
similarity index 100%
rename from tools/perf/tests/shell/trace+probe_libc_inet_pton.sh
rename to tools/perf/tests/shell/record+probe_libc_inet_pton.sh
-- 
2.14.3

[PATCH 26/28] perf test: Switch to new perf_mmap__read_event() interface for switch-tracking

[Arnaldo Carvalho de Melo]

From: Kan Liang 

The perf test 'switch-tracking' still use the legacy interface.

No functional change.

Committer testing:

  # perf test switch
  32: Track with sched_switch   : Ok
  #

Signed-off-by: Kan Liang 
Tested-by: Arnaldo Carvalho de Melo 
Cc: Andi Kleen 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Wang Nan 
Link: 
http://lkml.kernel.org/r/1519945751-37786-12-git-send-email-kan.li...@linux.intel.com
[ Changed bool parameters from 0 to 'false', as per Jiri comment ]
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/tests/switch-tracking.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/tools/perf/tests/switch-tracking.c 
b/tools/perf/tests/switch-tracking.c
index 33e00295a972..10c4dcdc2324 100644
--- a/tools/perf/tests/switch-tracking.c
+++ b/tools/perf/tests/switch-tracking.c
@@ -258,16 +258,23 @@ static int process_events(struct perf_evlist *evlist,
unsigned pos, cnt = 0;
LIST_HEAD(events);
struct event_node *events_array, *node;
+   struct perf_mmap *md;
+   u64 end, start;
int i, ret;
 
for (i = 0; i < evlist->nr_mmaps; i++) {
-   while ((event = perf_evlist__mmap_read(evlist, i)) != NULL) {
+   md = &evlist->mmap[i];
+   if (perf_mmap__read_init(md, false, &start, &end) < 0)
+   continue;
+
+   while ((event = perf_mmap__read_event(md, false, &start, end)) 
!= NULL) {
cnt += 1;
ret = add_event(evlist, &events, event);
-   perf_evlist__mmap_consume(evlist, i);
+perf_mmap__consume(md, false);
if (ret < 0)
goto out_free_nodes;
}
+   perf_mmap__read_done(md);
}
 
events_array = calloc(cnt, sizeof(struct event_node));
-- 
2.14.3

[PATCH 28/28] perf mmap: Discard legacy interfaces for mmap read forward

[Arnaldo Carvalho de Melo]

From: Kan Liang 

Discards legacy interfaces perf_evlist__mmap_read_forward(),
perf_evlist__mmap_read() and perf_evlist__mmap_consume().

No tools use them.

Signed-off-by: Kan Liang 
Cc: Andi Kleen 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Wang Nan 
Link: 
http://lkml.kernel.org/r/1519945751-37786-14-git-send-email-kan.li...@linux.intel.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/evlist.c | 25 +
 tools/perf/util/evlist.h |  4 
 tools/perf/util/mmap.c   | 21 +
 3 files changed, 2 insertions(+), 48 deletions(-)

diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index 7b7d535396f7..41a4666f1519 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -702,29 +702,6 @@ static int perf_evlist__resume(struct perf_evlist *evlist)
return perf_evlist__set_paused(evlist, false);
 }
 
-union perf_event *perf_evlist__mmap_read_forward(struct perf_evlist *evlist, 
int idx)
-{
-   struct perf_mmap *md = &evlist->mmap[idx];
-
-   /*
-* Check messup is required for forward overwritable ring buffer:
-* memory pointed by md->prev can be overwritten in this case.
-* No need for read-write ring buffer: kernel stop outputting when
-* it hit md->prev (perf_mmap__consume()).
-*/
-   return perf_mmap__read_forward(md);
-}
-
-union perf_event *perf_evlist__mmap_read(struct perf_evlist *evlist, int idx)
-{
-   return perf_evlist__mmap_read_forward(evlist, idx);
-}
-
-void perf_evlist__mmap_consume(struct perf_evlist *evlist, int idx)
-{
-   perf_mmap__consume(&evlist->mmap[idx], false);
-}
-
 static void perf_evlist__munmap_nofree(struct perf_evlist *evlist)
 {
int i;
@@ -761,7 +738,7 @@ static struct perf_mmap *perf_evlist__alloc_mmap(struct 
perf_evlist *evlist)
map[i].fd = -1;
/*
 * When the perf_mmap() call is made we grab one refcount, plus
-* one extra to let perf_evlist__mmap_consume() get the last
+* one extra to let perf_mmap__consume() get the last
 * events after all real references (perf_mmap__get()) are
 * dropped.
 *
diff --git a/tools/perf/util/evlist.h b/tools/perf/util/evlist.h
index 336b838e6957..6c41b2f78713 100644
--- a/tools/perf/util/evlist.h
+++ b/tools/perf/util/evlist.h
@@ -129,10 +129,6 @@ struct perf_sample_id *perf_evlist__id2sid(struct 
perf_evlist *evlist, u64 id);
 
 void perf_evlist__toggle_bkw_mmap(struct perf_evlist *evlist, enum 
bkw_mmap_state state);
 
-union perf_event *perf_evlist__mmap_read(struct perf_evlist *evlist, int idx);
-
-union perf_event *perf_evlist__mmap_read_forward(struct perf_evlist *evlist,
-int idx);
 void perf_evlist__mmap_consume(struct perf_evlist *evlist, int idx);
 
 int perf_evlist__open(struct perf_evlist *evlist);
diff --git a/tools/perf/util/mmap.c b/tools/perf/util/mmap.c
index 91531a7c8fbf..4f27c464ce0b 100644
--- a/tools/perf/util/mmap.c
+++ b/tools/perf/util/mmap.c
@@ -63,25 +63,6 @@ static union perf_event *perf_mmap__read(struct perf_mmap 
*map,
return event;
 }
 
-/*
- * legacy interface for mmap read.
- * Don't use it. Use perf_mmap__read_event().
- */
-union perf_event *perf_mmap__read_forward(struct perf_mmap *map)
-{
-   u64 head;
-
-   /*
-* Check if event was unmapped due to a POLLHUP/POLLERR.
-*/
-   if (!refcount_read(&map->refcnt))
-   return NULL;
-
-   head = perf_mmap__read_head(map);
-
-   return perf_mmap__read(map, &map->prev, head);
-}
-
 /*
  * Read event from ring buffer one by one.
  * Return one event for each call.
@@ -191,7 +172,7 @@ void perf_mmap__munmap(struct perf_mmap *map)
 int perf_mmap__mmap(struct perf_mmap *map, struct mmap_params *mp, int fd)
 {
/*
-* The last one will be done at perf_evlist__mmap_consume(), so that we
+* The last one will be done at perf_mmap__consume(), so that we
 * make sure we don't prevent tools from consuming every last event in
 * the ring buffer.
 *
-- 
2.14.3

[PATCH 25/28] perf test: Switch to new perf_mmap__read_event() interface for sw-clock

[Arnaldo Carvalho de Melo]

From: Kan Liang 

The perf test 'sw-clock' still use the legacy interface.

No functional change.

Committer testing:

  # perf test clock
  22: Software clock events period values   : Ok
  #

Signed-off-by: Kan Liang 
Tested-by: Arnaldo Carvalho de Melo 
Cc: Andi Kleen 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Wang Nan 
Link: 
http://lkml.kernel.org/r/1519945751-37786-11-git-send-email-kan.li...@linux.intel.com
[ Changed bool parameters from 0 to 'false', as per Jiri comment ]
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/tests/sw-clock.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/tools/perf/tests/sw-clock.c b/tools/perf/tests/sw-clock.c
index f6c72f915d48..e6320e267ba5 100644
--- a/tools/perf/tests/sw-clock.c
+++ b/tools/perf/tests/sw-clock.c
@@ -39,6 +39,8 @@ static int __test__sw_clock_freq(enum perf_sw_ids clock_id)
};
struct cpu_map *cpus;
struct thread_map *threads;
+   struct perf_mmap *md;
+   u64 end, start;
 
attr.sample_freq = 500;
 
@@ -93,7 +95,11 @@ static int __test__sw_clock_freq(enum perf_sw_ids clock_id)
 
perf_evlist__disable(evlist);
 
-   while ((event = perf_evlist__mmap_read(evlist, 0)) != NULL) {
+   md = &evlist->mmap[0];
+   if (perf_mmap__read_init(md, false, &start, &end) < 0)
+   goto out_init;
+
+   while ((event = perf_mmap__read_event(md, false, &start, end)) != NULL) 
{
struct perf_sample sample;
 
if (event->header.type != PERF_RECORD_SAMPLE)
@@ -108,9 +114,11 @@ static int __test__sw_clock_freq(enum perf_sw_ids clock_id)
total_periods += sample.period;
nr_samples++;
 next_event:
-   perf_evlist__mmap_consume(evlist, 0);
+   perf_mmap__consume(md, false);
}
+   perf_mmap__read_done(md);
 
+out_init:
if ((u64) nr_samples == total_periods) {
pr_debug("All (%d) samples have period value of 1!\n",
 nr_samples);
-- 
2.14.3

[PATCH 23/28] perf test: Switch to new perf_mmap__read_event() interface for perf-record

[Arnaldo Carvalho de Melo]

From: Kan Liang 

The perf test 'perf-record' still use the legacy interface.

No functional change.

Committer notes:

Testing it:

  # perf test PERF_RECORD
   8: PERF_RECORD_* events & perf_sample fields : Ok
  #

Signed-off-by: Kan Liang 
Tested-by: Arnaldo Carvalho de Melo 
Cc: Andi Kleen 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Wang Nan 
Link: 
http://lkml.kernel.org/r/1519945751-37786-9-git-send-email-kan.li...@linux.intel.com
[ Changed bool parameters from 0 to 'false', as per Jiri comment ]
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/tests/perf-record.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/tools/perf/tests/perf-record.c b/tools/perf/tests/perf-record.c
index 0afafab85238..31f3f70adca6 100644
--- a/tools/perf/tests/perf-record.c
+++ b/tools/perf/tests/perf-record.c
@@ -164,8 +164,14 @@ int test__PERF_RECORD(struct test *test __maybe_unused, 
int subtest __maybe_unus
 
for (i = 0; i < evlist->nr_mmaps; i++) {
union perf_event *event;
+   struct perf_mmap *md;
+   u64 end, start;
 
-   while ((event = perf_evlist__mmap_read(evlist, i)) != 
NULL) {
+   md = &evlist->mmap[i];
+   if (perf_mmap__read_init(md, false, &start, &end) < 0)
+   continue;
+
+   while ((event = perf_mmap__read_event(md, false, 
&start, end)) != NULL) {
const u32 type = event->header.type;
const char *name = perf_event__name(type);
 
@@ -266,8 +272,9 @@ int test__PERF_RECORD(struct test *test __maybe_unused, int 
subtest __maybe_unus
++errs;
}
 
-   perf_evlist__mmap_consume(evlist, i);
+   perf_mmap__consume(md, false);
}
+   perf_mmap__read_done(md);
}
 
/*
-- 
2.14.3

[PATCH 24/28] perf test: Switch to new perf_mmap__read_event() interface for time-to-tsc

[Arnaldo Carvalho de Melo]

From: Kan Liang 

The perf test 'time-to-tsc' still use the legacy interface.

No functional change.

Commiter notes:

Testing it:

  # perf test tsc
  57: Convert perf time to TSC  : Ok
  #

Signed-off-by: Kan Liang 
Tested-by: Arnaldo Carvalho de Melo 
Cc: Andi Kleen 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Wang Nan 
Link: 
http://lkml.kernel.org/r/1519945751-37786-10-git-send-email-kan.li...@linux.intel.com
[ Changed bool parameters from 0 to 'false', as per Jiri comment ]
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/arch/x86/tests/perf-time-to-tsc.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/tools/perf/arch/x86/tests/perf-time-to-tsc.c 
b/tools/perf/arch/x86/tests/perf-time-to-tsc.c
index 06abe8108b33..7f82d91ef473 100644
--- a/tools/perf/arch/x86/tests/perf-time-to-tsc.c
+++ b/tools/perf/arch/x86/tests/perf-time-to-tsc.c
@@ -60,6 +60,8 @@ int test__perf_time_to_tsc(struct test *test __maybe_unused, 
int subtest __maybe
union perf_event *event;
u64 test_tsc, comm1_tsc, comm2_tsc;
u64 test_time, comm1_time = 0, comm2_time = 0;
+   struct perf_mmap *md;
+   u64 end, start;
 
threads = thread_map__new(-1, getpid(), UINT_MAX);
CHECK_NOT_NULL__(threads);
@@ -109,7 +111,11 @@ int test__perf_time_to_tsc(struct test *test 
__maybe_unused, int subtest __maybe
perf_evlist__disable(evlist);
 
for (i = 0; i < evlist->nr_mmaps; i++) {
-   while ((event = perf_evlist__mmap_read(evlist, i)) != NULL) {
+   md = &evlist->mmap[i];
+   if (perf_mmap__read_init(md, false, &start, &end) < 0)
+   continue;
+
+   while ((event = perf_mmap__read_event(md, false, &start, end)) 
!= NULL) {
struct perf_sample sample;
 
if (event->header.type != PERF_RECORD_COMM ||
@@ -128,8 +134,9 @@ int test__perf_time_to_tsc(struct test *test 
__maybe_unused, int subtest __maybe
comm2_time = sample.time;
}
 next_event:
-   perf_evlist__mmap_consume(evlist, i);
+   perf_mmap__consume(md, false);
}
+   perf_mmap__read_done(md);
}
 
if (!comm1_time || !comm2_time)
-- 
2.14.3

[PATCH 21/28] perf test: Switch to new perf_mmap__read_event() interface for mmap-basic

[Arnaldo Carvalho de Melo]

From: Kan Liang 

The perf test 'mmap-basic' still use the legacy interface.

No functional change.

Committer notes:

Testing it:

  # perf test "mmap interface"
   4: Read samples using the mmap interface : Ok
  #

Signed-off-by: Kan Liang 
Tested-by: Arnaldo Carvalho de Melo 
Cc: Andi Kleen 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Wang Nan 
Link: 
http://lkml.kernel.org/r/1519945751-37786-7-git-send-email-kan.li...@linux.intel.com
[ Changed bool parameters from 0 to 'false', as per Jiri comment ]
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/tests/mmap-basic.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/tools/perf/tests/mmap-basic.c b/tools/perf/tests/mmap-basic.c
index c0e971da965c..44c58d69cd87 100644
--- a/tools/perf/tests/mmap-basic.c
+++ b/tools/perf/tests/mmap-basic.c
@@ -38,6 +38,8 @@ int test__basic_mmap(struct test *test __maybe_unused, int 
subtest __maybe_unuse
 expected_nr_events[nsyscalls], i, j;
struct perf_evsel *evsels[nsyscalls], *evsel;
char sbuf[STRERR_BUFSIZE];
+   struct perf_mmap *md;
+   u64 end, start;
 
threads = thread_map__new(-1, getpid(), UINT_MAX);
if (threads == NULL) {
@@ -106,7 +108,11 @@ int test__basic_mmap(struct test *test __maybe_unused, int 
subtest __maybe_unuse
++foo;
}
 
-   while ((event = perf_evlist__mmap_read(evlist, 0)) != NULL) {
+   md = &evlist->mmap[0];
+   if (perf_mmap__read_init(md, false, &start, &end) < 0)
+   goto out_init;
+
+   while ((event = perf_mmap__read_event(md, false, &start, end)) != NULL) 
{
struct perf_sample sample;
 
if (event->header.type != PERF_RECORD_SAMPLE) {
@@ -129,9 +135,11 @@ int test__basic_mmap(struct test *test __maybe_unused, int 
subtest __maybe_unuse
goto out_delete_evlist;
}
nr_events[evsel->idx]++;
-   perf_evlist__mmap_consume(evlist, 0);
+   perf_mmap__consume(md, false);
}
+   perf_mmap__read_done(md);
 
+out_init:
err = 0;
evlist__for_each_entry(evlist, evsel) {
if (nr_events[evsel->idx] != expected_nr_events[evsel->idx]) {
-- 
2.14.3

[PATCH 19/28] perf test: Switch to new perf_mmap__read_event() interface for 'code reading' test

[Arnaldo Carvalho de Melo]

From: Kan Liang 

The perf test 'object code reading' still use the legacy interface.

No functional change.

Committer notes:

Testing:

  # perf test reading
  23: Object code reading: Ok
  #

Signed-off-by: Kan Liang 
Tested-by: Arnaldo Carvalho de Melo 
Cc: Andi Kleen 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Wang Nan 
Link: 
http://lkml.kernel.org/r/1519945751-37786-5-git-send-email-kan.li...@linux.intel.com
[ Changed bool parameters from 0 to 'false', as per Jiri comment ]
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/tests/code-reading.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/tools/perf/tests/code-reading.c b/tools/perf/tests/code-reading.c
index c7115d369511..03ed8c77b1bb 100644
--- a/tools/perf/tests/code-reading.c
+++ b/tools/perf/tests/code-reading.c
@@ -409,15 +409,22 @@ static int process_events(struct machine *machine, struct 
perf_evlist *evlist,
  struct state *state)
 {
union perf_event *event;
+   struct perf_mmap *md;
+   u64 end, start;
int i, ret;
 
for (i = 0; i < evlist->nr_mmaps; i++) {
-   while ((event = perf_evlist__mmap_read(evlist, i)) != NULL) {
+   md = &evlist->mmap[i];
+   if (perf_mmap__read_init(md, false, &start, &end) < 0)
+   continue;
+
+   while ((event = perf_mmap__read_event(md, false, &start, end)) 
!= NULL) {
ret = process_event(machine, evlist, event, state);
-   perf_evlist__mmap_consume(evlist, i);
+   perf_mmap__consume(md, false);
if (ret < 0)
return ret;
}
+   perf_mmap__read_done(md);
}
return 0;
 }
-- 
2.14.3

[PATCH 17/28] perf python: Switch to new perf_mmap__read_event() interface

[Arnaldo Carvalho de Melo]

From: Kan Liang 

The perf python binding still use the legacy interface.

No functional change.

Committer notes:

Tested before and after with:

  [root@jouet perf]# export PYTHONPATH=/tmp/build/perf/python
  [root@jouet perf]# tools/perf/python/twatch.py
  cpu: 0, pid: 1183, tid: 6293 { type: exit, pid: 1183, ppid: 1183, tid: 6293, 
ptid: 6293, time: 17886646588257}
  cpu: 2, pid: 13820, tid: 13820 { type: fork, pid: 13820, ppid: 13820, tid: 
6306, ptid: 13820, time: 17886869099529}
  cpu: 1, pid: 13820, tid: 6306 { type: comm, pid: 13820, tid: 6306, comm: 
TaskSchedulerFo }
  ^CTraceback (most recent call last):
File "tools/perf/python/twatch.py", line 68, in 
  main()
File "tools/perf/python/twatch.py", line 40, in main
  evlist.poll(timeout = -1)
  KeyboardInterrupt
  [root@jouet perf]#

No problems found.

Signed-off-by: Kan Liang 
Tested-by: Arnaldo Carvalho de Melo 
Cc: Andi Kleen 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Wang Nan 
Link: 
http://lkml.kernel.org/r/1519945751-37786-3-git-send-email-kan.li...@linux.intel.com
[ Changed bool parameters from 0 to 'false', as per Jiri comment ]
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/python.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/tools/perf/util/python.c b/tools/perf/util/python.c
index 2918cac7a142..35fb5ef7d290 100644
--- a/tools/perf/util/python.c
+++ b/tools/perf/util/python.c
@@ -983,13 +983,19 @@ static PyObject *pyrf_evlist__read_on_cpu(struct 
pyrf_evlist *pevlist,
union perf_event *event;
int sample_id_all = 1, cpu;
static char *kwlist[] = { "cpu", "sample_id_all", NULL };
+   struct perf_mmap *md;
+   u64 end, start;
int err;
 
if (!PyArg_ParseTupleAndKeywords(args, kwargs, "i|i", kwlist,
 &cpu, &sample_id_all))
return NULL;
 
-   event = perf_evlist__mmap_read(evlist, cpu);
+   md = &evlist->mmap[cpu];
+   if (perf_mmap__read_init(md, false, &start, &end) < 0)
+   goto end;
+
+   event = perf_mmap__read_event(md, false, &start, end);
if (event != NULL) {
PyObject *pyevent = pyrf_event__new(event);
struct pyrf_event *pevent = (struct pyrf_event *)pyevent;
@@ -1007,14 +1013,14 @@ static PyObject *pyrf_evlist__read_on_cpu(struct 
pyrf_evlist *pevlist,
err = perf_evsel__parse_sample(evsel, event, &pevent->sample);
 
/* Consume the even only after we parsed it out. */
-   perf_evlist__mmap_consume(evlist, cpu);
+   perf_mmap__consume(md, false);
 
if (err)
return PyErr_Format(PyExc_OSError,
"perf: can't parse sample, err=%d", 
err);
return pyevent;
}
-
+end:
Py_INCREF(Py_None);
return Py_None;
 }
-- 
2.14.3

[PATCH 12/28] perf record: Throttle user defined frequencies to the maximum allowed

[Arnaldo Carvalho de Melo]

From: Arnaldo Carvalho de Melo 

  # perf record -F 20 sleep 1
  warning: Maximum frequency rate (15,000 Hz) exceeded, throttling from 200,000 
Hz to 15,000 Hz.
   The limit can be raised via 
/proc/sys/kernel/perf_event_max_sample_rate.
   The kernel will lower it when perf's interrupts take too long.
   Use --strict-freq to disable this throttling, refusing to record.
  [ perf record: Woken up 1 times to write data ]
  [ perf record: Captured and wrote 0.019 MB perf.data (15 samples) ]
  # perf evlist -v
  cycles:ppp: size: 112, { sample_period, sample_freq }: 15000, sample_type: 
IP|TID|TIME|PERIOD, disabled: 1, inherit: 1, mmap: 1, comm: 1, freq: 1, 
enable_on_exec: 1, task: 1, precise_ip: 3, sample_id_all: 1, exclude_guest: 1, 
mmap2: 1, comm_exec: 1

For those wanting that it fails if the desired frequency can't be used:

  # perf record --strict-freq -F 20 sleep 1
  error: Maximum frequency rate (15,000 Hz) exceeded.
 Please use -F freq option with a lower value or consider
 tweaking /proc/sys/kernel/perf_event_max_sample_rate.
  #

Suggested-by: Ingo Molnar 
Cc: Adrian Hunter 
Cc: David Ahern 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Wang Nan 
Link: https://lkml.kernel.org/n/tip-oyebruc44nlja499nqkr1...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/Documentation/perf-record.txt |  7 ++-
 tools/perf/builtin-record.c  |  2 ++
 tools/perf/perf.h|  1 +
 tools/perf/util/record.c | 20 +++-
 4 files changed, 24 insertions(+), 6 deletions(-)

diff --git a/tools/perf/Documentation/perf-record.txt 
b/tools/perf/Documentation/perf-record.txt
index 94f2faebc7f0..cc37b3a4be76 100644
--- a/tools/perf/Documentation/perf-record.txt
+++ b/tools/perf/Documentation/perf-record.txt
@@ -191,11 +191,16 @@ OPTIONS
 -i::
 --no-inherit::
Child tasks do not inherit counters.
+
 -F::
 --freq=::
Profile at this frequency. Use 'max' to use the currently maximum
allowed frequency, i.e. the value in the 
kernel.perf_event_max_sample_rate
-   sysctl.
+   sysctl. Will throttle down to the currently maximum allowed frequency.
+   See --strict-freq.
+
+--strict-freq::
+   Fail if the specified frequency can't be used.
 
 -m::
 --mmap-pages=::
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index e1821eea14ef..62387942a1d5 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -1543,6 +1543,8 @@ static struct option __record_options[] = {
OPT_BOOLEAN(0, "tail-synthesize", &record.opts.tail_synthesize,
"synthesize non-sample events at the end of output"),
OPT_BOOLEAN(0, "overwrite", &record.opts.overwrite, "use overwrite 
mode"),
+   OPT_BOOLEAN(0, "strict-freq", &record.opts.strict_freq,
+   "Fail if the specified frequency can't be used"),
OPT_CALLBACK('F', "freq", &record.opts, "freq or 'max'",
 "profile at this frequency",
  record__parse_freq),
diff --git a/tools/perf/perf.h b/tools/perf/perf.h
index a5df8bf73a68..007e0dfd5ce3 100644
--- a/tools/perf/perf.h
+++ b/tools/perf/perf.h
@@ -61,6 +61,7 @@ struct record_opts {
bool tail_synthesize;
bool overwrite;
bool ignore_missing_thread;
+   bool strict_freq;
unsigned int freq;
unsigned int mmap_pages;
unsigned int auxtrace_mmap_pages;
diff --git a/tools/perf/util/record.c b/tools/perf/util/record.c
index acabf54ceccb..4f1a82e76d39 100644
--- a/tools/perf/util/record.c
+++ b/tools/perf/util/record.c
@@ -216,11 +216,21 @@ static int record_opts__config_freq(struct record_opts 
*opts)
 * User specified frequency is over current maximum.
 */
if (user_freq && (max_rate < opts->freq)) {
-   pr_err("Maximum frequency rate (%u) reached.\n"
-  "Please use -F freq option with lower value or consider\n"
-  "tweaking /proc/sys/kernel/perf_event_max_sample_rate.\n",
-  max_rate);
-   return -1;
+   if (opts->strict_freq) {
+   pr_err("error: Maximum frequency rate (%'u Hz) 
exceeded.\n"
+  "   Please use -F freq option with a lower 
value or consider\n"
+  "   tweaking 
/proc/sys/kernel/perf_event_max_sample_rate.\n",
+  max_rate);
+   return -1;
+   } else {
+   pr_warning("warning: Maximum frequency rate (%'u Hz) 
exceeded, throttling from %'u Hz to %'u Hz.\n"
+  " The limit can be raised via 
/proc/sys/kernel/perf_event_max_sample_rate.\n"
+  " The kernel will lower it when 
perf's interrupts take too long.\n"
+

[PATCH 16/28] perf trace: Switch to new perf_mmap__read_event() interface

[Arnaldo Carvalho de Melo]

From: Kan Liang 

The 'perf trace' utility still use the legacy interface.

Switch to the new perf_mmap__read_event() interface.

No functional change.

Signed-off-by: Kan Liang 
Tested-by: Arnaldo Carvalho de Melo 
Cc: Andi Kleen 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Wang Nan 
Link: 
http://lkml.kernel.org/r/1519945751-37786-2-git-send-email-kan.li...@linux.intel.com
[ Changed bool parameters from 0 to 'false', as per Jiri comment ]
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/builtin-trace.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
index e7f1b182fc15..1a93debc1e8d 100644
--- a/tools/perf/builtin-trace.c
+++ b/tools/perf/builtin-trace.c
@@ -2472,8 +2472,14 @@ static int trace__run(struct trace *trace, int argc, 
const char **argv)
 
for (i = 0; i < evlist->nr_mmaps; i++) {
union perf_event *event;
+   struct perf_mmap *md;
+   u64 end, start;
 
-   while ((event = perf_evlist__mmap_read(evlist, i)) != NULL) {
+   md = &evlist->mmap[i];
+   if (perf_mmap__read_init(md, false, &start, &end) < 0)
+   continue;
+
+   while ((event = perf_mmap__read_event(md, false, &start, end)) 
!= NULL) {
struct perf_sample sample;
 
++trace->nr_events;
@@ -2486,7 +2492,7 @@ static int trace__run(struct trace *trace, int argc, 
const char **argv)
 
trace__handle_event(trace, event, &sample);
 next_event:
-   perf_evlist__mmap_consume(evlist, i);
+   perf_mmap__consume(md, false);
 
if (interrupted)
goto out_disable;
@@ -2496,6 +2502,7 @@ static int trace__run(struct trace *trace, int argc, 
const char **argv)
draining = true;
}
}
+   perf_mmap__read_done(md);
}
 
if (trace->nr_events == before) {
-- 
2.14.3

Re: Simplifying our RCU models

[Eric W. Biederman]

Moving this discussion to a public list as discussing how to reduce the
number of rcu variants does not make sense in private.  We should have
an archive of such discussions.

Ingo Molnar  writes:

> * Paul E. McKenney  wrote:
>
>> > So if people really want that low-cost RCU, and some people really
>> > need the sleepable version, the only one that can _possibly_ be dumped
>> > is the preempt one.
>> > 
>> > But I may - again - be confused and/or missing something.
>> 
>> I am going to do something very stupid and say that I was instead thinking 
>> in 
>> terms of getting rid of RCU-bh, thus reminding you of its existence.  ;-)
>> 
>> The reason for believing that it is possible to get rid of RCU-bh is the 
>> work 
>> that has gone into improving the forward progress of RCU grace periods under 
>> heavy load and in corner-case workloads.
>>
>
> [...]
>
>> The other reason for RCU-sched is it has the side effect of waiting
>> for all in-flight hardware interrupt handlers, NMI handlers, and
>> preempt-disable regions of code to complete, and last I checked, this side
>> effect is relied on.  In contrast, RCU-preeempt is only guaranteed to wait
>> on regions of code protected by rcu_read_lock() and rcu_read_unlock().
>
> Instead of only trying to fix the documentation (which is never a bad idea 
> but it 
> is fighting the symptom in this case), I think the first step should be to 
> simplify the RCU read side APIs of RCU from 4 APIs:
>
>   rcu_read_lock()
>   srcu_read_lock()
>   rcu_read_lock_sched()
>   rcu_read_lock_bh()
>
> ... which have ~8 further sub-model variations depending on CONFIG_PREEMPT, 
> CONFIG_PREEMPT_RCU - which is really a crazy design!
>
> I think we could reduce this to just two APIs with no Kconfig dependencies:
>
>   rcu_read_lock()
>   rcu_read_lock_preempt_disable()
>
> Which would be much, much simpler.
>
> This is how we could do it I think:
>
> 1)
>
> Getting rid of the _bh() variant should be reasonably simple and involve a 
> treewide replacement of:
>
>   rcu_read_lock_bh()   -> local_bh_disable()
>   rcu_read_unlock_bh() -> local_bh_enable()
>
> Correct?
>
> 2)
>
> Further reducing the variants is harder, due to this main asymmetry:
>
>   !PREEMPT_RCU  PREEMPT_RCU=y
>   rcu_read_lock_sched():  atomicatomic
>   rcu_read_lock():atomicpreemptible
>
> ('atomic' here is meant in the scheduler, non-preemptible sense.)
>
> But if we look at the bigger API picture:
>
>   !PREEMPT_RCU  PREEMPT_RCU=y
>   rcu_read_lock():atomicpreemptiblep
>   rcu_read_lock_sched():  atomicatomic
>   srcu_read_lock():   preemptible   preemptible
>
> Then we could maintain full read side API flexibility by making PREEMPT_RCU=y 
> the 
> only model, merging it with SRCU and using these main read side APIs:
>
>   rcu_read_lock_preempt_disable(():   atomic
>   rcu_read_lock() preemptible
>
> It's a _really_ simple and straightforward RCU model, with very obvious 
> semantics 
> all around:
>
> - Note how the 'atomic' (non-preempt) variant uses the well-known 
>   preempt_disable() name as a postfix to signal its main property. (It's also 
> a 
>   bit of a mouthful, which should discourage over-use.)
>
> - The read side APIs are really as straightforward as possible: there's no 
> SRCU 
>   distinction on the read side, no _bh() distinction and no _sched() 
> distinction. 
>   (On -rt all of these would turn into preemptible sections,
>   obviously.)

And it looses the one advantage of srcu_read_lock.  That you don't have
to wait for the entire world.  If you actually allow sleeping that is an
important distinction to have.  Or are you proposing that we add the
equivalent of init_srcu_struct to all of the rcu users?

That rcu_read_lock would need to take an argument about which rcu region
we are talking about.

> rcu_read_lock_preempt_disable() would essentially be all the current 
> rcu_read_lock_sched() users (where the _sched() postfix was a confusing 
> misnomer 
> anyway).
>
> Wrt. merging SRCU and RCU: this can be done by making PREEMPT_RCU=y the one 
> and 
> only main RCU model and converting all SRCU users to main RCU. This is 
> relatively 
> straightforward to perform, as there are only ~170 SRCU critical sections, 
> versus 
> the 3000+ main RCU critical sections ...

It really sounds like you are talking about adding a requirement that
everyone update their rcu_read_lock() calls with information about which
region you are talking about.  That seems like quite a bit of work.

Doing something implicit when PREEMPT_RCU=y and converting
"rcu_read_lock()" to "srcu_read_lock(&kernel_srcu_region)" only in that
case I can see.

Except in very specific circustances I don't think I ever want to run a
kernel with PREEMPT_RCU the default.  All of that real time stuff trades
off predictability with performance.  Having lost enough performance to
spectre

[PATCH 10/28] perf top browser: Show sample_freq in browser title line

[Arnaldo Carvalho de Melo]

From: Arnaldo Carvalho de Melo 

The '--stdio' 'perf top' UI shows it, so lets remove this UI difference
and show it too in '--tui', will be useful for 'perf top --tui -F max'.

Cc: Adrian Hunter 
Cc: David Ahern 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Wang Nan 
Link: https://lkml.kernel.org/n/tip-n3wd8n395uo4y9irst29p...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/ui/browsers/hists.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index 6495ee55d9c3..de2bde232cb3 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -2223,7 +2223,7 @@ static int perf_evsel_browser_title(struct hist_browser 
*browser,
u64 nr_events = hists->stats.total_period;
struct perf_evsel *evsel = hists_to_evsel(hists);
const char *ev_name = perf_evsel__name(evsel);
-   char buf[512];
+   char buf[512], sample_freq_str[64] = "";
size_t buflen = sizeof(buf);
char ref[30] = " show reference callgraph, ";
bool enable_ref = false;
@@ -2255,10 +2255,14 @@ static int perf_evsel_browser_title(struct hist_browser 
*browser,
if (symbol_conf.show_ref_callgraph &&
strstr(ev_name, "call-graph=no"))
enable_ref = true;
+
+   if (!is_report_browser(hbt))
+   scnprintf(sample_freq_str, sizeof(sample_freq_str), " %d Hz,", 
evsel->attr.sample_freq);
+
nr_samples = convert_unit(nr_samples, &unit);
printed = scnprintf(bf, size,
-  "Samples: %lu%c of event '%s',%sEvent count 
(approx.): %" PRIu64,
-  nr_samples, unit, ev_name, enable_ref ? ref : " ", 
nr_events);
+  "Samples: %lu%c of event '%s',%s%sEvent count 
(approx.): %" PRIu64,
+  nr_samples, unit, ev_name, sample_freq_str, 
enable_ref ? ref : " ", nr_events);
 
 
if (hists->uid_filter_str)
-- 
2.14.3

[PATCH 15/28] perf kvm: Switch to new perf_mmap__read_event() interface

[Arnaldo Carvalho de Melo]

From: Kan Liang 

The perf kvm still use the legacy interface.

Switch to the new perf_mmap__read_event() interface for perf kvm.

No functional change.

Committer notes:

Tested before and after running:

  # perf kvm stat record

On a machine with a kvm guest, then used:

  # perf kvm stat report

Before/after results match and look like:

  # perf kvm stat record -a sleep 5
  [ perf record: Woken up 1 times to write data ]
  [ perf record: Captured and wrote 2.132 MB perf.data.guest (1828 samples) ]
  # perf kvm stat report

  Analyze events for all VMs, all VCPUs:

 VM-EXIT Samples Samples%  Time% Min TimeMax TimeAvg time

  IO_INSTRUCTION 258   40.06%  0.08%   3.51us122.54us 14.87us 
(+- 6.76%)
   MSR_WRITE 178   27.64%  0.01%   0.47us  6.34us  2.18us 
(+- 4.80%)
   EPT_MISCONFIG 148   22.98%  0.03%   3.76us 65.60us 11.22us 
(+- 8.14%)
 HLT  477.30% 99.88% 181.69us 249988.06us 102061.36us 
(+-13.49%)
   PAUSE_INSTRUCTION   50.78%  0.00%   0.38us  0.79us  0.47us 
(+-17.05%)
MSR_READ   40.62%  0.00%   1.14us  3.33us  2.67us 
(+-19.35%)
  EXTERNAL_INTERRUPT   20.31%  0.00%   2.15us  2.17us  2.16us 
(+- 0.30%)
   PENDING_INTERRUPT   10.16%  0.00%   2.56us  2.56us  2.56us 
(+- 0.00%)
PREEMPTION_TIMER   10.16%  0.00%   3.21us  3.21us  3.21us 
(+- 0.00%)

  Total Samples:644, Total events handled time:4802790.72us.

  #

Signed-off-by: Kan Liang 
Tested-by: Arnaldo Carvalho de Melo 
Cc: Andi Kleen 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Wang Nan 
Link: 
http://lkml.kernel.org/r/1519945751-37786-1-git-send-email-kan.li...@linux.intel.com
[ Changed bool parameters from 0 to 'false', as per Jiri comment ]
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/builtin-kvm.c | 17 +
 1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/tools/perf/builtin-kvm.c b/tools/perf/builtin-kvm.c
index 55d919dc5bc6..d2703d3b8366 100644
--- a/tools/perf/builtin-kvm.c
+++ b/tools/perf/builtin-kvm.c
@@ -743,16 +743,24 @@ static bool verify_vcpu(int vcpu)
 static s64 perf_kvm__mmap_read_idx(struct perf_kvm_stat *kvm, int idx,
   u64 *mmap_time)
 {
+   struct perf_evlist *evlist = kvm->evlist;
union perf_event *event;
+   struct perf_mmap *md;
+   u64 end, start;
u64 timestamp;
s64 n = 0;
int err;
 
*mmap_time = ULLONG_MAX;
-   while ((event = perf_evlist__mmap_read(kvm->evlist, idx)) != NULL) {
-   err = perf_evlist__parse_sample_timestamp(kvm->evlist, event, 
×tamp);
+   md = &evlist->mmap[idx];
+   err = perf_mmap__read_init(md, false, &start, &end);
+   if (err < 0)
+   return (err == -EAGAIN) ? 0 : -1;
+
+   while ((event = perf_mmap__read_event(md, false, &start, end)) != NULL) 
{
+   err = perf_evlist__parse_sample_timestamp(evlist, event, 
×tamp);
if (err) {
-   perf_evlist__mmap_consume(kvm->evlist, idx);
+   perf_mmap__consume(md, false);
pr_err("Failed to parse sample\n");
return -1;
}
@@ -762,7 +770,7 @@ static s64 perf_kvm__mmap_read_idx(struct perf_kvm_stat 
*kvm, int idx,
 * FIXME: Here we can't consume the event, as 
perf_session__queue_event will
 *point to it, and it'll get possibly overwritten by 
the kernel.
 */
-   perf_evlist__mmap_consume(kvm->evlist, idx);
+   perf_mmap__consume(md, false);
 
if (err) {
pr_err("Failed to enqueue sample: %d\n", err);
@@ -779,6 +787,7 @@ static s64 perf_kvm__mmap_read_idx(struct perf_kvm_stat 
*kvm, int idx,
break;
}
 
+   perf_mmap__read_done(md);
return n;
 }
 
-- 
2.14.3

[PATCH v3] arch/arm/Kconfig: default ARM_MODULE_PLTS to 'y'

[Anders Roxell]

While testing multi_v7_defconfig with config fragments that makes the
kernel size to grow. The kernel fails to load simple modules, as
reported by kselftest:

[   34.107620] test_printf: section 4 reloc 2 sym 'memset': relocation
28 out of range (0xbf046044 -> 0xc109f720)
selftests: printf.sh [FAIL]

The problem that is seen when enabling too much in the kernel without
enabling ARM_MODULE_PLTS, is that the top of the kernel gets out of
reach from the bottom of the module area.

Suggested-by: Arnd Bergmann 
Signed-off-by: Anders Roxell 
---
 arch/arm/Kconfig | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 7e3d53575486..6831f2d4ee75 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1701,6 +1701,7 @@ config ARCH_WANT_GENERAL_HUGETLB
 config ARM_MODULE_PLTS
bool "Use PLTs to allow module memory to spill over into vmalloc area"
depends on MODULES
+   default y
help
  Allocate PLTs when loading modules so that jumps and calls whose
  targets are too far away for their relative offsets to be encoded
@@ -1711,7 +1712,8 @@ config ARM_MODULE_PLTS
  rounding up to page size, the actual memory footprint is usually
  the same.
 
- Say y if you are getting out of memory errors while loading modules
+ Disabling this is usually safe for small single-platform
+ configurations. If unsure, say y.
 
 source "mm/Kconfig"
 
-- 
2.11.0

Re: [RESEND PATCH v6 13/14] iommu/rockchip: Add runtime PM support

[Tomasz Figa]

On Mon, Mar 5, 2018 at 11:13 PM, Robin Murphy  wrote:
> On 05/03/18 13:49, Tomasz Figa wrote:
> [...]
>>>
>>> @@ -518,7 +520,12 @@ static irqreturn_t rk_iommu_irq(int irq, void
>>> *dev_id)
>>>  u32 int_status;
>>>  dma_addr_t iova;
>>>  irqreturn_t ret = IRQ_NONE;
>>> -   int i;
>>> +   int i, err, need_runtime_put;
>>
>>
>> nit: need_runtime_put could be a bool.
>>
>>> +
>>> +   err = pm_runtime_get_if_in_use(iommu->dev);
>>> +   if (err <= 0 && err != -EINVAL)
>>> +   return ret;
>>> +   need_runtime_put = err > 0;
>>
>>
>> Generally something must be really wrong if we end up with err == 0
>> here, because the IOMMU must be powered on to signal an interrupt. The
>> only case this could happen would be if the IRQ signal was shared with
>> some device from another power domain. Is it possible on Rockchip
>> SoCs? If not, perhaps we should have a WARN_ON() here for such case.
>
>
> In general, there's almost certainly some time window between the interrupt
> level being latched at the GIC and the IRQ actually being taken by its
> target CPU, in which potentially the power could be removed and/or the
> clocks gated - especially if there are higher-priority IRQs pending at the
> same time and the racing PM call is on some other CPU. Sure, it's probably
> unlikely, but I wouldn't necessarily consider it completely erroneous.

Clocks are not a problem here, since the handler re-enables them and
clk_enable() is IRQ-safe. However, runtime PM might need sleeping, so
we can't just get_sync() from the handler. I guess, we should just
bail out in such case, since the power off would probably clear any
internal interrupt state anyway.

Also, the interrupt would be basically a page fault, during which the
master device would be stalled, so it's rather unlikely that we see
its driver putting the runtime PM, which would only happen after the
master device resumes and competes (or something times out). So
probably WARN_ON() isn't such bad idea still.

Re: [PATCH v6 03/20] firmware: arm_scmi: add basic driver infrastructure for SCMI

[Sudeep Holla]

On 05/03/18 13:52, Jonathan Cameron wrote:
> On Fri, 23 Feb 2018 16:23:33 +
> Sudeep Holla  wrote:
> 
>> The SCMI is intended to allow OSPM to manage various functions that are
>> provided by the hardware platform it is running on, including power and
>> performance functions. SCMI provides two levels of abstraction, protocols
>> and transports. Protocols define individual groups of system control and
>> management messages. A protocol specification describes the messages
>> that it supports. Transports describe the method by which protocol
>> messages are communicated between agents and the platform.
>>
>> This patch adds basic infrastructure to manage the message allocation,
>> initialisation, packing/unpacking and shared memory management.
>>
> Hi Sudeep,
> 
> A bit of a drive by review as I was curious and happen to have been looking
> at the spec.  Anyhow my main comments in here are about consistency of naming.
> In many ways it doesn't matter what naming convention you go with, but it is
> good to make sure you then use it consistently.
> 

Thanks for having a look at this. I just sent a pull request last
Friday. I will address all the issues here, but if it's not a fix, it
may need to wait a bit longer, I can try sending second PR but chances
of getting it in are more if there are fixes.

>> Cc: Arnd Bergmann 
>> Cc: Greg Kroah-Hartman 
>> Signed-off-by: Sudeep Holla 
> 
>> +
>> +#include 
>> +#include 
>> +#include 
>> +
>> +/**
>> + * struct scmi_msg_hdr - Message(Tx/Rx) header
>> + *
>> + * @id: The identifier of the command being sent
>> + * @protocol_id: The identifier of the protocol used to send @id command
>> + * @seq: The token to identify the message. when a message/command returns,
>> + *   the platform returns the whole message header unmodified including
>> + *   the token.
> Something looks odd with indenting here...
> 

Will check.

>> + */
>> +struct scmi_msg_hdr {
>> +u8 id;
> I think this is called message_id in the spec, would it be worth
> matching that here?
> 

I dropped message as the structure is named scmi_msg_hdr, I can change
if it needs to align with specification to that extent :)

>> +u8 protocol_id;
>> +u16 seq;
>> +u32 status;
>> +bool poll_completion;
>> +};
> status and poll completion could do with documenting.
> 

Sure

>> +
>> +/**
>> + * struct scmi_msg - Message(Tx/Rx) structure
>> + *
>> + * @buf: Buffer pointer
>> + * @len: Length of data in the Buffer
>> + */
>> +struct scmi_msg {
>> +void *buf;
>> +size_t len;
>> +};
>> +
>> +/**
>> + * struct scmi_xfer - Structure representing a message flow
>> + *
>> + * @hdr: Transmit message header
>> + * @tx: Transmit message
>> + * @rx: Receive message, the buffer should be pre-allocated to store
>> + *  message. If request-ACK protocol is used, we can reuse the same
>> + *  buffer for the rx path as we use for the tx path.
>> + * @done: completion event
>> + */
>> +
> No blank line here.

Will remove

>> +struct scmi_xfer {
>> +void *con_priv;
>> +struct scmi_msg_hdr hdr;
>> +struct scmi_msg tx;
>> +struct scmi_msg rx;
>> +struct completion done;
>> +};
>> +
>> +void scmi_one_xfer_put(const struct scmi_handle *h, struct scmi_xfer *xfer);
>> +int scmi_do_xfer(const struct scmi_handle *h, struct scmi_xfer *xfer);
>> +int scmi_one_xfer_init(const struct scmi_handle *h, u8 msg_id, u8 prot_id,
>> +   size_t tx_size, size_t rx_size, struct scmi_xfer **p);
>> +int scmi_handle_put(const struct scmi_handle *handle);
>> +struct scmi_handle *scmi_handle_get(struct device *dev);
>> diff --git a/drivers/firmware/arm_scmi/driver.c 
>> b/drivers/firmware/arm_scmi/driver.c
>> new file mode 100644
>> index ..fa0e9cf31f4c
>> --- /dev/null
>> +++ b/drivers/firmware/arm_scmi/driver.c
>> @@ -0,0 +1,689 @@
>> +/*
>> + * System Control and Management Interface (SCMI) Message Protocol driver
>> + *
>> + * SCMI Message Protocol is used between the System Control Processor(SCP)
>> + * and the Application Processors(AP). The Message Handling Unit(MHU)
>> + * provides a mechanism for inter-processor communication between SCP's
>> + * Cortex M3 and AP.
>> + *
>> + * SCP offers control and management of the core/cluster power states,
>> + * various power domain DVFS including the core/cluster, certain system
>> + * clocks configuration, thermal sensors and many others.
>> + *
>> + * Copyright (C) 2017 ARM Ltd.
>> + *
>> + * This program is free software; you can redistribute it and/or modify it
>> + * under the terms and conditions of the GNU General Public License,
>> + * version 2, as published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope 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.
>> + *
>> + * You should have received a copy of the GNU General Public Lic

[PATCH 13/28] perf annotate: Find 'call' instruction target symbol at parsing time

[Arnaldo Carvalho de Melo]

From: Arnaldo Carvalho de Melo 

So that we do it just once, not everytime we press enter or -> on a
'call' instruction line.

Cc: Adrian Hunter 
Cc: David Ahern 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Wang Nan 
Link: https://lkml.kernel.org/n/tip-uysyojl1e6nm94amzzzs0...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/ui/browsers/annotate.c | 17 +
 tools/perf/util/annotate.c| 38 +-
 tools/perf/util/annotate.h|  1 +
 3 files changed, 27 insertions(+), 29 deletions(-)

diff --git a/tools/perf/ui/browsers/annotate.c 
b/tools/perf/ui/browsers/annotate.c
index 6ff6839558b0..618edf96353c 100644
--- a/tools/perf/ui/browsers/annotate.c
+++ b/tools/perf/ui/browsers/annotate.c
@@ -568,35 +568,28 @@ static bool annotate_browser__callq(struct 
annotate_browser *browser,
struct map_symbol *ms = browser->b.priv;
struct disasm_line *dl = disasm_line(browser->selection);
struct annotation *notes;
-   struct addr_map_symbol target = {
-   .map = ms->map,
-   .addr = map__objdump_2mem(ms->map, dl->ops.target.addr),
-   };
char title[SYM_TITLE_MAX_SIZE];
 
if (!ins__is_call(&dl->ins))
return false;
 
-   if (map_groups__find_ams(&target) ||
-   map__rip_2objdump(target.map, target.map->map_ip(target.map,
-target.addr)) !=
-   dl->ops.target.addr) {
+   if (!dl->ops.target.sym) {
ui_helpline__puts("The called function was not found.");
return true;
}
 
-   notes = symbol__annotation(target.sym);
+   notes = symbol__annotation(dl->ops.target.sym);
pthread_mutex_lock(¬es->lock);
 
-   if (notes->src == NULL && symbol__alloc_hist(target.sym) < 0) {
+   if (notes->src == NULL && symbol__alloc_hist(dl->ops.target.sym) < 0) {
pthread_mutex_unlock(¬es->lock);
ui__warning("Not enough memory for annotating '%s' symbol!\n",
-   target.sym->name);
+   dl->ops.target.sym->name);
return true;
}
 
pthread_mutex_unlock(¬es->lock);
-   symbol__tui_annotate(target.sym, target.map, evsel, hbt);
+   symbol__tui_annotate(dl->ops.target.sym, ms->map, evsel, hbt);
sym_title(ms->sym, ms->map, title, sizeof(title));
ui_browser__show_title(&browser->b, title);
return true;
diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
index 28b233c3dcbe..49ff825f745c 100644
--- a/tools/perf/util/annotate.c
+++ b/tools/perf/util/annotate.c
@@ -187,6 +187,9 @@ bool ins__is_fused(struct arch *arch, const char *ins1, 
const char *ins2)
 static int call__parse(struct arch *arch, struct ins_operands *ops, struct map 
*map)
 {
char *endptr, *tok, *name;
+   struct addr_map_symbol target = {
+   .map = map,
+   };
 
ops->target.addr = strtoull(ops->raw, &endptr, 16);
 
@@ -208,28 +211,29 @@ static int call__parse(struct arch *arch, struct 
ins_operands *ops, struct map *
ops->target.name = strdup(name);
*tok = '>';
 
-   return ops->target.name == NULL ? -1 : 0;
+   if (ops->target.name == NULL)
+   return -1;
+find_target:
+   target.addr = map__objdump_2mem(map, ops->target.addr);
 
-indirect_call:
-   tok = strchr(endptr, '*');
-   if (tok == NULL) {
-   struct symbol *sym = map__find_symbol(map, map->map_ip(map, 
ops->target.addr));
-   if (sym != NULL)
-   ops->target.name = strdup(sym->name);
-   else
-   ops->target.addr = 0;
-   return 0;
-   }
+   if (map_groups__find_ams(&target) == 0 &&
+   map__rip_2objdump(target.map, map->map_ip(target.map, target.addr)) 
== ops->target.addr)
+   ops->target.sym = target.sym;
 
-   ops->target.addr = strtoull(tok + 1, NULL, 16);
return 0;
+
+indirect_call:
+   tok = strchr(endptr, '*');
+   if (tok != NULL)
+   ops->target.addr = strtoull(tok + 1, NULL, 16);
+   goto find_target;
 }
 
 static int call__scnprintf(struct ins *ins, char *bf, size_t size,
   struct ins_operands *ops)
 {
-   if (ops->target.name)
-   return scnprintf(bf, size, "%-6s %s", ins->name, 
ops->target.name);
+   if (ops->target.sym)
+   return scnprintf(bf, size, "%-6s %s", ins->name, 
ops->target.sym->name);
 
if (ops->target.addr == 0)
return ins__raw_scnprintf(ins, bf, size, ops);
@@ -1283,8 +1287,8 @@ static int symbol__parse_objdump_line(struct symbol *sym, 
FILE *file,
dl->ops.target.offset_avail = true;
}
 
-   /* kcore has no symbols, so add the call target name */
-   if (dl->ins.ops && ins__is_call(&dl->ins) && !dl->ops.

[PATCH 14/28] perf record: Fix crash in pipe mode

[Arnaldo Carvalho de Melo]

From: Jiri Olsa 

Currently we can crash perf record when running in pipe mode, like:

  $ perf record ls | perf report
  # To display the perf.data header info, please use --header/--header-only 
options.
  #
  perf: Segmentation fault
  Error:
  The - file has no samples!

The callstack of the crash is:

0x00515242 in perf_event__synthesize_event_update_name
  3513ev = event_update_event__new(len + 1, 
PERF_EVENT_UPDATE__NAME, evsel->id[0]);
  (gdb) bt
  #0  0x00515242 in perf_event__synthesize_event_update_name
  #1  0x005158a4 in perf_event__synthesize_extra_attr
  #2  0x00443347 in record__synthesize
  #3  0x004438e3 in __cmd_record
  #4  0x0044514e in cmd_record
  #5  0x004cbc95 in run_builtin
  #6  0x004cbf02 in handle_internal_command
  #7  0x004cc054 in run_argv
  #8  0x004cc422 in main

The reason of the crash is that the evsel does not have ids array
allocated and the pipe's synthesize code tries to access it.

We don't force evsel ids allocation when we have single event, because
it's not needed. However we need it when we are in pipe mode even for
single event as a key for evsel update event.

Fixing this by forcing evsel ids allocation event for single event, when
we are in pipe mode.

Signed-off-by: Jiri Olsa 
Cc: Alexander Shishkin 
Cc: David Ahern 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/20180302161354.30192-1-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/builtin-record.c | 9 +
 tools/perf/perf.h   | 1 +
 tools/perf/util/record.c| 8 ++--
 3 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 62387942a1d5..12230ddb6506 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -882,6 +882,15 @@ static int __cmd_record(struct record *rec, int argc, 
const char **argv)
}
}
 
+   /*
+* If we have just single event and are sending data
+* through pipe, we need to force the ids allocation,
+* because we synthesize event name through the pipe
+* and need the id for that.
+*/
+   if (data->is_pipe && rec->evlist->nr_entries == 1)
+   rec->opts.sample_id = true;
+
if (record__open(rec) != 0) {
err = -1;
goto out_child;
diff --git a/tools/perf/perf.h b/tools/perf/perf.h
index 007e0dfd5ce3..8fec1abd0f1f 100644
--- a/tools/perf/perf.h
+++ b/tools/perf/perf.h
@@ -62,6 +62,7 @@ struct record_opts {
bool overwrite;
bool ignore_missing_thread;
bool strict_freq;
+   bool sample_id;
unsigned int freq;
unsigned int mmap_pages;
unsigned int auxtrace_mmap_pages;
diff --git a/tools/perf/util/record.c b/tools/perf/util/record.c
index 4f1a82e76d39..9cfc7bf16531 100644
--- a/tools/perf/util/record.c
+++ b/tools/perf/util/record.c
@@ -138,6 +138,7 @@ void perf_evlist__config(struct perf_evlist *evlist, struct 
record_opts *opts,
struct perf_evsel *evsel;
bool use_sample_identifier = false;
bool use_comm_exec;
+   bool sample_id = opts->sample_id;
 
/*
 * Set the evsel leader links before we configure attributes,
@@ -164,8 +165,7 @@ void perf_evlist__config(struct perf_evlist *evlist, struct 
record_opts *opts,
 * match the id.
 */
use_sample_identifier = perf_can_sample_identifier();
-   evlist__for_each_entry(evlist, evsel)
-   perf_evsel__set_sample_id(evsel, use_sample_identifier);
+   sample_id = true;
} else if (evlist->nr_entries > 1) {
struct perf_evsel *first = perf_evlist__first(evlist);
 
@@ -175,6 +175,10 @@ void perf_evlist__config(struct perf_evlist *evlist, 
struct record_opts *opts,
use_sample_identifier = perf_can_sample_identifier();
break;
}
+   sample_id = true;
+   }
+
+   if (sample_id) {
evlist__for_each_entry(evlist, evsel)
perf_evsel__set_sample_id(evsel, use_sample_identifier);
}
-- 
2.14.3

[PATCH 6/6] dts: fsl-ls208x: updated DT with SMMU support for fsl-mc

[Nipun Gupta]

Signed-off-by: Nipun Gupta 
---
 arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
index f3a40af..1f15492 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
@@ -135,6 +135,7 @@
#address-cells = <2>;
#size-cells = <2>;
ranges;
+   dma-ranges = <0x0 0x0 0x0 0x0 0x1 0x>;
 
clockgen: clocking@130 {
compatible = "fsl,ls2080a-clockgen";
@@ -357,6 +358,8 @@
reg = <0x0008 0x0c00 0 0x40>,/* MC portal 
base */
  <0x 0x0834 0 0x4>; /* MC control 
reg */
msi-parent = <&its>;
+   iommu-parent = <&smmu>;
+   dma-coherent;
#address-cells = <3>;
#size-cells = <1>;
 
@@ -460,6 +463,8 @@
compatible = "arm,mmu-500";
reg = <0 0x500 0 0x80>;
#global-interrupts = <12>;
+   stream-match-mask = <0x7C00>;
+   dma-coherent;
interrupts = <0 13 4>, /* global secure fault */
 <0 14 4>, /* combined secure interrupt */
 <0 15 4>, /* global non-secure fault */
@@ -502,7 +507,6 @@
 <0 204 4>, <0 205 4>,
 <0 206 4>, <0 207 4>,
 <0 208 4>, <0 209 4>;
-   mmu-masters = <&fsl_mc 0x300 0>;
};
 
dspi: dspi@210 {
-- 
1.9.1

Re: [PATCH v6 13/20] firmware: arm_scmi: refactor in preparation to support per-protocol channels

[Jonathan Cameron]

On Fri, 23 Feb 2018 16:23:43 +
Sudeep Holla  wrote:

> In order to support per-protocol channels if available, we need to
> factor out all the mailbox channel information(Tx/Rx payload and
> channel handle) out of the main SCMI instance information structure.
> 
> This patch refactors the existing channel information into a separate
> chan_info structure.
> 
> Cc: Arnd Bergmann 
> Cc: Greg Kroah-Hartman 
> Signed-off-by: Sudeep Holla 
A little odd to present a series to mainline that does a fairly important
refactor mid way through.  Why not push this down to the start and always 
support
the separate chan_info structure?

> ---
>  drivers/firmware/arm_scmi/driver.c | 90 
> --
>  1 file changed, 56 insertions(+), 34 deletions(-)
> 
> diff --git a/drivers/firmware/arm_scmi/driver.c 
> b/drivers/firmware/arm_scmi/driver.c
> index e6698629e15a..a9e3f4c46b78 100644
> --- a/drivers/firmware/arm_scmi/driver.c
> +++ b/drivers/firmware/arm_scmi/driver.c
> @@ -102,6 +102,22 @@ struct scmi_desc {
>  };
>  
>  /**
> + * struct scmi_chan_info - Structure representing a SCMI channel informfation
> + *
> + * @cl: Mailbox Client
> + * @chan: Transmit/Receive mailbox channel
> + * @payload: Transmit/Receive mailbox channel payload area
> + * @dev: Reference to device in the SCMI hierarchy corresponding to this
> + *channel
> + */
> +struct scmi_chan_info {
> + struct mbox_client cl;
> + struct mbox_chan *chan;
> + void __iomem *payload;
> + struct device *dev;
> +};
> +
> +/**
>   * struct scmi_info - Structure representing a  SCMI instance
>   *
>   * @dev: Device pointer
> @@ -109,10 +125,8 @@ struct scmi_desc {
>   * @handle: Instance of SCMI handle to send to clients
>   * @version: SCMI revision information containing protocol version,
>   *   implementation version and (sub-)vendor identification.
> - * @cl: Mailbox Client
> - * @tx_chan: Transmit mailbox channel
> - * @tx_payload: Transmit mailbox channel payload area
>   * @minfo: Message info
> + * @tx_cinfo: Reference to SCMI channel information
>   * @protocols_imp: list of protocols implemented, currently maximum of
>   *   MAX_PROTOCOLS_IMP elements allocated by the base protocol
>   * @node: list head
> @@ -123,16 +137,14 @@ struct scmi_info {
>   const struct scmi_desc *desc;
>   struct scmi_revision_info version;
>   struct scmi_handle handle;
> - struct mbox_client cl;
> - struct mbox_chan *tx_chan;
> - void __iomem *tx_payload;
>   struct scmi_xfers_info minfo;
> + struct scmi_chan_info *tx_cinfo;
>   u8 *protocols_imp;
>   struct list_head node;
>   int users;
>  };
>  
> -#define client_to_scmi_info(c)   container_of(c, struct scmi_info, cl)
> +#define client_to_scmi_chan_info(c) container_of(c, struct scmi_chan_info, 
> cl)
>  #define handle_to_scmi_info(h)   container_of(h, struct scmi_info, 
> handle)
>  
>  /*
> @@ -215,10 +227,11 @@ static void scmi_rx_callback(struct mbox_client *cl, 
> void *m)
>  {
>   u16 xfer_id;
>   struct scmi_xfer *xfer;
> - struct scmi_info *info = client_to_scmi_info(cl);
> + struct scmi_chan_info *cinfo = client_to_scmi_chan_info(cl);
> + struct device *dev = cinfo->dev;
> + struct scmi_info *info = dev_get_drvdata(dev);
>   struct scmi_xfers_info *minfo = &info->minfo;
> - struct device *dev = info->dev;
> - struct scmi_shared_mem __iomem *mem = info->tx_payload;
> + struct scmi_shared_mem __iomem *mem = cinfo->payload;
>  
>   xfer_id = MSG_XTRACT_TOKEN(ioread32(&mem->msg_header));
>  
> @@ -269,8 +282,8 @@ static inline u32 pack_scmi_header(struct scmi_msg_hdr 
> *hdr)
>  static void scmi_tx_prepare(struct mbox_client *cl, void *m)
>  {
>   struct scmi_xfer *t = m;
> - struct scmi_info *info = client_to_scmi_info(cl);
> - struct scmi_shared_mem __iomem *mem = info->tx_payload;
> + struct scmi_chan_info *cinfo = client_to_scmi_chan_info(cl);
> + struct scmi_shared_mem __iomem *mem = cinfo->payload;
>  
>   /* Mark channel busy + clear error */
>   iowrite32(0x0, &mem->channel_status);
> @@ -349,27 +362,27 @@ void scmi_one_xfer_put(const struct scmi_handle 
> *handle, struct scmi_xfer *xfer)
>  }
>  
>  static bool
> -scmi_xfer_poll_done(const struct scmi_info *info, struct scmi_xfer *xfer)
> +scmi_xfer_poll_done(const struct scmi_chan_info *cinfo, struct scmi_xfer 
> *xfer)
>  {
> - struct scmi_shared_mem *mem = info->tx_payload;
> - u16 xfer_id = MSG_XTRACT_TOKEN(le32_to_cpu(mem->msg_header));
> + struct scmi_shared_mem __iomem *mem = cinfo->payload;
> + u16 xfer_id = MSG_XTRACT_TOKEN(ioread32(&mem->msg_header));
>  
>   if (xfer->hdr.seq != xfer_id)
>   return false;
>  
> - return le32_to_cpu(mem->channel_status) &
> + return ioread32(&mem->channel_status) &
>   (SCMI_SHMEM_CHAN_STAT_CHANNEL_ERROR |
>   SCMI_SHMEM_CHAN_STAT_CHANNEL_FREE);
>  }
>  
>  #define SCMI_MAX_POLL

[PATCH 11/28] perf top: Allow asking for the maximum allowed sample rate

[Arnaldo Carvalho de Melo]

From: Arnaldo Carvalho de Melo 

Add the handy '-F max' shortcut, just introduced to 'perf record', to
reading and using the kernel.perf_event_max_sample_rate value as the
user supplied sampling frequency:

Cc: Adrian Hunter 
Cc: David Ahern 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Wang Nan 
Link: https://lkml.kernel.org/n/tip-hz04f296zccknnb5at06a...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/Documentation/perf-top.txt | 4 +++-
 tools/perf/builtin-top.c  | 4 +++-
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/tools/perf/Documentation/perf-top.txt 
b/tools/perf/Documentation/perf-top.txt
index 8a32cc77bead..a039407d63b8 100644
--- a/tools/perf/Documentation/perf-top.txt
+++ b/tools/perf/Documentation/perf-top.txt
@@ -55,7 +55,9 @@ Default is to monitor all CPUS.
 
 -F ::
 --freq=::
-   Profile at this frequency.
+   Profile at this frequency. Use 'max' to use the currently maximum
+   allowed frequency, i.e. the value in the 
kernel.perf_event_max_sample_rate
+   sysctl.
 
 -i::
 --inherit::
diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index 35ac016fcb98..bb4f9fafd11d 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -1307,7 +1307,9 @@ int cmd_top(int argc, const char **argv)
OPT_STRING(0, "sym-annotate", &top.sym_filter, "symbol name",
"symbol to annotate"),
OPT_BOOLEAN('z', "zero", &top.zero, "zero history across updates"),
-   OPT_UINTEGER('F', "freq", &opts->user_freq, "profile at this 
frequency"),
+   OPT_CALLBACK('F', "freq", &top.record_opts, "freq or 'max'",
+"profile at this frequency",
+ record__parse_freq),
OPT_INTEGER('E', "entries", &top.print_entries,
"display this many functions"),
OPT_BOOLEAN('U', "hide_user_symbols", &top.hide_user_symbols,
-- 
2.14.3

[PATCH 09/28] perf record: Allow asking for the maximum allowed sample rate

[Arnaldo Carvalho de Melo]

From: Arnaldo Carvalho de Melo 

Add the handy '-F max' shortcut to reading and using the
kernel.perf_event_max_sample_rate value as the user supplied
sampling frequency:

  # perf record -F max sleep 1
  info: Using a maximum frequency rate of 15,000 Hz
  [ perf record: Woken up 1 times to write data ]
  [ perf record: Captured and wrote 0.019 MB perf.data (14 samples) ]
  # sysctl kernel.perf_event_max_sample_rate
  kernel.perf_event_max_sample_rate = 15000
  # perf evlist -v
  cycles:ppp: size: 112, { sample_period, sample_freq }: 15000, sample_type: 
IP|TID|TIME|PERIOD, disabled: 1, inherit: 1, mmap: 1, comm: 1, freq: 1, 
enable_on_exec: 1, task: 1, precise_ip: 3, sample_id_all: 1, exclude_guest: 1, 
mmap2: 1, comm_exec: 1

  # perf record -F 10 sleep 1
  [ perf record: Woken up 1 times to write data ]
  [ perf record: Captured and wrote 0.019 MB perf.data (4 samples) ]
  # perf evlist -v
  cycles:ppp: size: 112, { sample_period, sample_freq }: 10, sample_type: 
IP|TID|TIME|PERIOD, disabled: 1, inherit: 1, mmap: 1, comm: 1, freq: 1, 
enable_on_exec: 1, task: 1, precise_ip: 3, sample_id_all: 1, exclude_guest: 1, 
mmap2: 1, comm_exec: 1
  #

Suggested-by: Ingo Molnar 
Cc: Adrian Hunter 
Cc: David Ahern 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Wang Nan 
Link: https://lkml.kernel.org/n/tip-4y0tiuws62c64gp4cf0hm...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/Documentation/perf-record.txt |  4 +++-
 tools/perf/builtin-record.c  |  7 ++-
 tools/perf/perf.h|  2 ++
 tools/perf/util/record.c | 23 +++
 4 files changed, 34 insertions(+), 2 deletions(-)

diff --git a/tools/perf/Documentation/perf-record.txt 
b/tools/perf/Documentation/perf-record.txt
index 76bc2181d214..94f2faebc7f0 100644
--- a/tools/perf/Documentation/perf-record.txt
+++ b/tools/perf/Documentation/perf-record.txt
@@ -193,7 +193,9 @@ OPTIONS
Child tasks do not inherit counters.
 -F::
 --freq=::
-   Profile at this frequency.
+   Profile at this frequency. Use 'max' to use the currently maximum
+   allowed frequency, i.e. the value in the 
kernel.perf_event_max_sample_rate
+   sysctl.
 
 -m::
 --mmap-pages=::
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 907267206973..e1821eea14ef 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -45,6 +45,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1542,7 +1543,9 @@ static struct option __record_options[] = {
OPT_BOOLEAN(0, "tail-synthesize", &record.opts.tail_synthesize,
"synthesize non-sample events at the end of output"),
OPT_BOOLEAN(0, "overwrite", &record.opts.overwrite, "use overwrite 
mode"),
-   OPT_UINTEGER('F', "freq", &record.opts.user_freq, "profile at this 
frequency"),
+   OPT_CALLBACK('F', "freq", &record.opts, "freq or 'max'",
+"profile at this frequency",
+ record__parse_freq),
OPT_CALLBACK('m', "mmap-pages", &record.opts, "pages[,pages]",
 "number of mmap data pages and AUX area tracing mmap 
pages",
 record__parse_mmap_pages),
@@ -1651,6 +1654,8 @@ int cmd_record(int argc, const char **argv)
struct record *rec = &record;
char errbuf[BUFSIZ];
 
+   setlocale(LC_ALL, "");
+
 #ifndef HAVE_LIBBPF_SUPPORT
 # define set_nobuild(s, l, c) set_option_nobuild(record_options, s, l, 
"NO_LIBBPF=1", c)
set_nobuild('\0', "clang-path", true);
diff --git a/tools/perf/perf.h b/tools/perf/perf.h
index cfe46236a5e5..a5df8bf73a68 100644
--- a/tools/perf/perf.h
+++ b/tools/perf/perf.h
@@ -82,4 +82,6 @@ struct record_opts {
 struct option;
 extern const char * const *record_usage;
 extern struct option *record_options;
+
+int record__parse_freq(const struct option *opt, const char *str, int unset);
 #endif
diff --git a/tools/perf/util/record.c b/tools/perf/util/record.c
index 1e97937b03a9..acabf54ceccb 100644
--- a/tools/perf/util/record.c
+++ b/tools/perf/util/record.c
@@ -5,6 +5,7 @@
 #include "parse-events.h"
 #include 
 #include 
+#include 
 #include "util.h"
 #include "cloexec.h"
 
@@ -287,3 +288,25 @@ bool perf_evlist__can_select_event(struct perf_evlist 
*evlist, const char *str)
perf_evlist__delete(temp_evlist);
return ret;
 }
+
+int record__parse_freq(const struct option *opt, const char *str, int unset 
__maybe_unused)
+{
+   unsigned int freq;
+   struct record_opts *opts = opt->value;
+
+   if (!str)
+   return -EINVAL;
+
+   if (strcasecmp(str, "max") == 0) {
+   if (get_max_rate(&freq)) {
+   pr_err("couldn't read 
/proc/sys/kernel/perf_event_max_sample_rate\n");
+   return -1;
+   }
+   pr_info("info: Using a maximum frequency rate of %'d Hz\n", 
freq);
+   } else {
+   freq = atoi(str);
+   }
+

[PATCH 5/6] dma-mapping: support fsl-mc bus

[Nipun Gupta]

Signed-off-by: Nipun Gupta 
---
 drivers/base/dma-mapping.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/base/dma-mapping.c b/drivers/base/dma-mapping.c
index 3b11835..2279c4d 100644
--- a/drivers/base/dma-mapping.c
+++ b/drivers/base/dma-mapping.c
@@ -334,6 +334,7 @@ void dma_common_free_remap(void *cpu_addr, size_t size, 
unsigned long vm_flags)
  * Common configuration to enable DMA API use for a device
  */
 #include 
+#include 
 
 int dma_configure(struct device *dev)
 {
@@ -349,6 +350,12 @@ int dma_configure(struct device *dev)
dma_dev = dma_dev->parent;
}
 
+   if (dev_is_fsl_mc(dev)) {
+   dma_dev = dev;
+   while (dev_is_fsl_mc(dma_dev))
+   dma_dev = dma_dev->parent;
+   }
+
if (dma_dev->of_node) {
ret = of_dma_configure(dev, dma_dev->of_node);
} else if (has_acpi_companion(dma_dev)) {
-- 
1.9.1

[PATCH 07/28] perf tests: Switch trace+probe_libc_inet_pton to use record

[Arnaldo Carvalho de Melo]

From: Jiri Olsa 

There's a problem with relying on backtrace data from 'perf trace' the
way the trace+probe_libc_inet_pton does. This test inserts uprobe within
ping binary and checks that it gets its sample using 'perf trace'.

It also checks it gets proper backtrace from sample and that's where the
issue is.

The 'perf trace' does not sort events (by definition) so it can happen
that it processes the event sample before the ping binary memory map
event. This can (very rarely) happen as proved by this events dump
output (from custom added debug output):

  ...
  7680/7680: [0x7f4e29718000(0x204000) @ 0 fd:00 33611321 4230892504]: r-xp 
/usr/lib64/libdl-2.17.so
  7680/7680: [0x7f4e29502000(0x216000) @ 0 fd:00 33617257 2606846872]: r-xp 
/usr/lib64/libz.so.1.2.7
  (IP, 0x2): 7680/7680: 0x7f4e29c2ed60 period: 1 addr: 0
  7680/7680: [0x564842ef(0x233000) @ 0 fd:00 83 1989280200]: r-xp 
/usr/bin/ping
  7680/7680: [0x7f4e2aca2000(0x224000) @ 0 fd:00 33611308 1219144940]: r-xp 
/usr/lib64/ld-2.17.so
  ...

In this case 'perf trace' fails to resolve the last callchain IP (within
the ping binary) because it does not know about the ping binary memory
map yet and the test fails like this:

  PING ::1(::1) 56 data bytes
  64 bytes from ::1: icmp_seq=1 ttl=64 time=0.037 ms
  --- ::1 ping statistics ---
  1 packets transmitted, 1 received, 0% packet loss, time 0ms
  rtt min/avg/max/mdev = 0.037/0.037/0.037/0.000 ms
  0.000 probe_libc:inet_pton:(7f4e29c2ed60))
  __GI___inet_pton (/usr/lib64/libc-2.17.so)
  getaddrinfo (/usr/lib64/libc-2.17.so)
  [0] ([unknown])
  FAIL: expected backtrace entry 8 ".*\(.*/bin/ping.*\)$" got "[0] ([unknown])"

Switching the test to use 'perf record' and 'perf script' instead of
'perf trace'.

Signed-off-by: Jiri Olsa 
Tested-by: Arnaldo Carvalho de Melo 
Cc: Alexander Shishkin 
Cc: David Ahern 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/20180301165215.6780-1-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 .../perf/tests/shell/trace+probe_libc_inet_pton.sh | 30 +++---
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/tools/perf/tests/shell/trace+probe_libc_inet_pton.sh 
b/tools/perf/tests/shell/trace+probe_libc_inet_pton.sh
index 8c4ab0b390c0..52c3ee701a89 100755
--- a/tools/perf/tests/shell/trace+probe_libc_inet_pton.sh
+++ b/tools/perf/tests/shell/trace+probe_libc_inet_pton.sh
@@ -15,30 +15,28 @@ nm -g $libc 2>/dev/null | fgrep -q inet_pton || exit 254
 
 trace_libc_inet_pton_backtrace() {
idx=0
-   expected[0]="PING.*bytes"
-   expected[1]="64 bytes from ::1.*"
-   expected[2]=".*ping statistics.*"
-   expected[3]=".*packets transmitted.*"
-   expected[4]="rtt min.*"
-   
expected[5]="[0-9]+\.[0-9]+[[:space:]]+probe_libc:inet_pton:\([[:xdigit:]]+\)"
-   expected[6]=".*inet_pton[[:space:]]\($libc|inlined\)$"
+   expected[0]="ping[][0-9 \.:]+probe_libc:inet_pton: \([[:xdigit:]]+\)"
+   expected[1]=".*inet_pton[[:space:]]\($libc\)$"
case "$(uname -m)" in
s390x)
eventattr='call-graph=dwarf'
-   expected[7]="gaih_inet.*[[:space:]]\($libc|inlined\)$"
-   expected[8]="__GI_getaddrinfo[[:space:]]\($libc|inlined\)$"
-   expected[9]="main[[:space:]]\(.*/bin/ping.*\)$"
-   expected[10]="__libc_start_main[[:space:]]\($libc\)$"
-   expected[11]="_start[[:space:]]\(.*/bin/ping.*\)$"
+   expected[2]="gaih_inet.*[[:space:]]\($libc|inlined\)$"
+   expected[3]="__GI_getaddrinfo[[:space:]]\($libc|inlined\)$"
+   expected[4]="main[[:space:]]\(.*/bin/ping.*\)$"
+   expected[5]="__libc_start_main[[:space:]]\($libc\)$"
+   expected[6]="_start[[:space:]]\(.*/bin/ping.*\)$"
;;
*)
eventattr='max-stack=3'
-   expected[7]="getaddrinfo[[:space:]]\($libc\)$"
-   expected[8]=".*\(.*/bin/ping.*\)$"
+   expected[2]="getaddrinfo[[:space:]]\($libc\)$"
+   expected[3]=".*\(.*/bin/ping.*\)$"
;;
esac
 
-   perf trace --no-syscalls -e probe_libc:inet_pton/$eventattr/ ping -6 -c 
1 ::1 2>&1 | grep -v ^$ | while read line ; do
+   file=`mktemp -u /tmp/perf.data.XXX`
+
+   perf record -e probe_libc:inet_pton/$eventattr/ -o $file ping -6 -c 1 
::1 > /dev/null 2>&1
+   perf script -i $file | while read line ; do
echo $line
echo "$line" | egrep -q "${expected[$idx]}"
if [ $? -ne 0 ] ; then
@@ -48,6 +46,8 @@ trace_libc_inet_pton_backtrace() {
let idx+=1
[ -z "${expected[$idx]}" ] && break
done
+
+   rm -f $file
 }
 
 # Check for IPv6 interface existence
-- 
2.14.3

[PATCH 3/6] iommu: arm-smmu: Add support for the fsl-mc bus

[Nipun Gupta]

Implement bus specific support for the fsl-mc bus including
registering arm_smmu_ops and bus specific device add operations.

Signed-off-by: Nipun Gupta 
---
 drivers/iommu/arm-smmu.c |  7 +++
 drivers/iommu/iommu.c| 21 +
 include/linux/fsl/mc.h   |  8 
 include/linux/iommu.h|  2 ++
 4 files changed, 38 insertions(+)

diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 69e7c60..e1d5090 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -52,6 +52,7 @@
 #include 
 
 #include 
+#include 
 
 #include "io-pgtable.h"
 #include "arm-smmu-regs.h"
@@ -1459,6 +1460,8 @@ static struct iommu_group *arm_smmu_device_group(struct 
device *dev)
 
if (dev_is_pci(dev))
group = pci_device_group(dev);
+   else if (dev_is_fsl_mc(dev))
+   group = fsl_mc_device_group(dev);
else
group = generic_device_group(dev);
 
@@ -2037,6 +2040,10 @@ static void arm_smmu_bus_init(void)
bus_set_iommu(&pci_bus_type, &arm_smmu_ops);
}
 #endif
+#ifdef CONFIG_FSL_MC_BUS
+   if (!iommu_present(&fsl_mc_bus_type))
+   bus_set_iommu(&fsl_mc_bus_type, &arm_smmu_ops);
+#endif
 }
 
 static int arm_smmu_device_probe(struct platform_device *pdev)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 69fef99..fbeebb2 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 static struct kset *iommu_group_kset;
@@ -987,6 +988,26 @@ struct iommu_group *pci_device_group(struct device *dev)
return iommu_group_alloc();
 }
 
+/* Get the IOMMU group for device on fsl-mc bus */
+struct iommu_group *fsl_mc_device_group(struct device *dev)
+{
+   struct device *cont_dev = fsl_mc_cont_dev(dev);
+   struct iommu_group *group;
+
+   /* Container device is responsible for creating the iommu group */
+   if (fsl_mc_is_cont_dev(dev)) {
+   group = iommu_group_alloc();
+   if (IS_ERR(group))
+   return NULL;
+   } else {
+   get_device(cont_dev);
+   group = iommu_group_get(cont_dev);
+   put_device(cont_dev);
+   }
+
+   return group;
+}
+
 /**
  * iommu_group_get_for_dev - Find or create the IOMMU group for a device
  * @dev: target device
diff --git a/include/linux/fsl/mc.h b/include/linux/fsl/mc.h
index 765ba41..ae9382b 100644
--- a/include/linux/fsl/mc.h
+++ b/include/linux/fsl/mc.h
@@ -351,6 +351,14 @@ struct fsl_mc_io {
 #define dev_is_fsl_mc(_dev) (0)
 #endif
 
+/* Macro to check if a device is a container device */
+#define fsl_mc_is_cont_dev(_dev) (to_fsl_mc_device(_dev)->flags & \
+   FSL_MC_IS_DPRC)
+
+/* Macro to get the container device of a MC device */
+#define fsl_mc_cont_dev(_dev) (fsl_mc_is_cont_dev(_dev) ? \
+   (_dev) : (_dev)->parent)
+
 /*
  * module_fsl_mc_driver() - Helper macro for drivers that don't do
  * anything special in module init/exit.  This eliminates a lot of
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 41b8c57..00a460b 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -389,6 +389,8 @@ static inline size_t iommu_map_sg(struct iommu_domain 
*domain,
 extern struct iommu_group *pci_device_group(struct device *dev);
 /* Generic device grouping function */
 extern struct iommu_group *generic_device_group(struct device *dev);
+/* FSL-MC device grouping function */
+struct iommu_group *fsl_mc_device_group(struct device *dev);
 
 /**
  * struct iommu_fwspec - per-device IOMMU instance data
-- 
1.9.1

[PATCH] ARM: dts: BCM5301X: add missing LEDs for Buffalo WZR-900DHP

[musashino . open]

From: INAGAKI Hiroshi 

Buffalo WZR-900DHP has 8 LEDs, but there is not LED definitions in the
dts and cannot configure these LEDs.
I Added missing LED definitions for WZR-900DHP.

Signed-off-by: INAGAKI Hiroshi 
---
 arch/arm/boot/dts/bcm47081-buffalo-wzr-900dhp.dts | 73 +++
 1 file changed, 73 insertions(+)

diff --git a/arch/arm/boot/dts/bcm47081-buffalo-wzr-900dhp.dts 
b/arch/arm/boot/dts/bcm47081-buffalo-wzr-900dhp.dts
index 8bef642..fa8f917 100644
--- a/arch/arm/boot/dts/bcm47081-buffalo-wzr-900dhp.dts
+++ b/arch/arm/boot/dts/bcm47081-buffalo-wzr-900dhp.dts
@@ -35,6 +35,79 @@
   0x8800 0x0800>;
};
 
+   spi {
+   compatible = "spi-gpio";
+   num-chipselects = <1>;
+   gpio-sck = <&chipcommon 7 0>;
+   gpio-mosi = <&chipcommon 4 0>;
+   cs-gpios = <&chipcommon 6 0>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   hc595: gpio_spi@0 {
+   compatible = "fairchild,74hc595";
+   reg = <0>;
+   registers-number = <1>;
+   spi-max-frequency = <10>;
+
+   gpio-controller;
+   #gpio-cells = <2>;
+
+   };
+   };
+
+   leds {
+   compatible = "gpio-leds";
+
+   usb {
+   label = "bcm53xx:green:usb";
+   gpios = <&hc595 0 GPIO_ACTIVE_HIGH>;
+   linux,default-trigger = "default-off";
+   };
+
+   power0 {
+   label = "bcm53xx:green:power";
+   gpios = <&hc595 1 GPIO_ACTIVE_HIGH>;
+   linux,default-trigger = "default-on";
+   };
+
+   power1 {
+   label = "bcm53xx:red:power";
+   gpios = <&hc595 2 GPIO_ACTIVE_HIGH>;
+   linux,default-trigger = "default-off";
+   };
+
+   router0 {
+   label = "bcm53xx:green:router";
+   gpios = <&hc595 3 GPIO_ACTIVE_HIGH>;
+   linux,default-trigger = "default-on";
+   };
+
+   router1 {
+   label = "bcm53xx:amber:router";
+   gpios = <&hc595 4 GPIO_ACTIVE_HIGH>;
+   linux,default-trigger = "default-off";
+   };
+
+   wan {
+   label = "bcm53xx:green:wan";
+   gpios = <&hc595 5 GPIO_ACTIVE_HIGH>;
+   linux,default-trigger = "default-on";
+   };
+
+   wireless0 {
+   label = "bcm53xx:green:wireless";
+   gpios = <&hc595 6 GPIO_ACTIVE_HIGH>;
+   linux,default-trigger = "default-off";
+   };
+
+   wireless1 {
+   label = "bcm53xx:amber:wireless";
+   gpios = <&hc595 7 GPIO_ACTIVE_HIGH>;
+   linux,default-trigger = "default-off";
+   };
+   };
+
gpio-keys {
compatible = "gpio-keys";
#address-cells = <1>;
-- 
2.7.4

[PATCH 06/28] perf annotate browser: Be more robust when drawing jump arrows

[Arnaldo Carvalho de Melo]

From: Arnaldo Carvalho de Melo 

This first happened with a gcc function, _cpp_lex_token, that has the
usual jumps:

 │1159e6c: ↓ jne115aa32 <_cpp_lex_token@@Base+0xf92>

I.e. jumps to a label inside that function (_cpp_lex_token), and those
works, but also this kind:

 │1159e8b: ↓ jnec469be 

I.e. jumps to another function, outside _cpp_lex_token, which are not
being correctly handled generating as a side effect references to
ab->offset[] entries that are set to NULL, so to make this code more
robust, check that here.

A proper fix for will be put in place, looking at the function name
right after the '<' token and probably treating this like a 'call'
instruction.

For now just don't draw the arrow.

Reported-by: Ingo Molnar 
Reported-by: Linus Torvalds 
Cc: Adrian Hunter 
Cc: David Ahern 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Wang Nan 
Cc: Jin Yao 
Cc: Kan Liang 
Link: https://lkml.kernel.org/n/tip-5tzvb875ep2sel03aeefg...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/ui/browsers/annotate.c | 25 +
 1 file changed, 25 insertions(+)

diff --git a/tools/perf/ui/browsers/annotate.c 
b/tools/perf/ui/browsers/annotate.c
index e2f666391ac4..6ff6839558b0 100644
--- a/tools/perf/ui/browsers/annotate.c
+++ b/tools/perf/ui/browsers/annotate.c
@@ -328,7 +328,32 @@ static void annotate_browser__draw_current_jump(struct 
ui_browser *browser)
if (!disasm_line__is_valid_jump(cursor, sym))
return;
 
+   /*
+* This first was seen with a gcc function, _cpp_lex_token, that
+* has the usual jumps:
+*
+*  │1159e6c: ↓ jne115aa32 <_cpp_lex_token@@Base+0xf92>
+*
+* I.e. jumps to a label inside that function (_cpp_lex_token), and
+* those works, but also this kind:
+*
+*  │1159e8b: ↓ jnec469be 
+*
+*  I.e. jumps to another function, outside _cpp_lex_token, which
+*  are not being correctly handled generating as a side effect 
references
+*  to ab->offset[] entries that are set to NULL, so to make this code
+*  more robust, check that here.
+*
+*  A proper fix for will be put in place, looking at the function
+*  name right after the '<' token and probably treating this like a
+*  'call' instruction.
+*/
target = ab->offsets[cursor->ops.target.offset];
+   if (target == NULL) {
+   ui_helpline__printf("WARN: jump target inconsistency, press 
'o', ab->offsets[%#x] = NULL\n",
+   cursor->ops.target.offset);
+   return;
+   }
 
bcursor = browser_line(&cursor->al);
btarget = browser_line(target);
-- 
2.14.3

[PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding

[Nipun Gupta]

The existing IOMMU bindings cannot be used to specify the relationship
between fsl-mc devices and IOMMUs. This patch adds a binding for
mapping fsl-mc devices to IOMMUs, using a new iommu-parent property.

Signed-off-by: Nipun Gupta 
---
 .../devicetree/bindings/misc/fsl,qoriq-mc.txt  | 31 ++
 1 file changed, 31 insertions(+)

diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt 
b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
index 6611a7c..011c7d6 100644
--- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
+++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
@@ -9,6 +9,24 @@ blocks that can be used to create functional hardware 
objects/devices
 such as network interfaces, crypto accelerator instances, L2 switches,
 etc.
 
+For an overview of the DPAA2 architecture and fsl-mc bus see:
+drivers/staging/fsl-mc/README.txt
+
+As described in the above overview, all DPAA2 objects in a DPRC share the
+same hardware "isolation context" and a 10-bit value called an ICID
+(isolation context id) is expressed by the hardware to identify
+the requester.
+
+The generic 'iommus' property is cannot be used to describe the relationship
+between fsl-mc and IOMMUs, so an iommu-parent property is used to define
+the same.
+
+For generic IOMMU bindings, see
+Documentation/devicetree/bindings/iommu/iommu.txt.
+
+For arm-smmu binding, see:
+Documentation/devicetree/bindings/iommu/arm,smmu.txt.
+
 Required properties:
 
 - compatible
@@ -88,14 +106,27 @@ Sub-nodes:
   Value type: 
   Definition: Specifies the phandle to the PHY device node 
associated
   with the this dpmac.
+Optional properties:
+
+- iommu-parent: Maps the devices on fsl-mc bus to an IOMMU.
+  The property specifies the IOMMU behind which the devices on
+  fsl-mc bus are residing.
 
 Example:
 
+smmu: iommu@500 {
+   compatible = "arm,mmu-500";
+   #iommu-cells = <1>;
+   stream-match-mask = <0x7C00>;
+   ...
+};
+
 fsl_mc: fsl-mc@80c00 {
 compatible = "fsl,qoriq-mc";
 reg = <0x0008 0x0c00 0 0x40>,/* MC portal base */
   <0x 0x0834 0 0x4>; /* MC control reg */
 msi-parent = <&its>;
+iommu-parent = <&smmu>;
 #address-cells = <3>;
 #size-cells = <1>;
 
-- 
1.9.1

[PATCH 04/28] perf top: Fix annoying fallback message on older kernels

[Arnaldo Carvalho de Melo]

From: Kan Liang 

On older (e.g. v4.4) kernels, an annoying fallback message can be
observed in 'perf top':

┌─Warning:──┐
│fall back to non-overwrite mode│
│   │
│   │
│Press any key...   │
└───┘

The 'perf top' utility has been changed to overwrite mode since commit
ebebbf082357 ("perf top: Switch default mode to overwrite mode").

For older kernels which don't have overwrite mode support, 'perf top'
will fall back to non-overwrite mode and print out the fallback message
using ui__warning(), which needs user's input to close.

The fallback message is not critical for end users. Turning it to debug
message which is printed when running with -vv.

Reported-by: Ingo Molnar 
Signed-off-by: Kan Liang 
Cc: Kan Liang 
Fixes: ebebbf082357 ("perf top: Switch default mode to overwrite mode")
Link: 
http://lkml.kernel.org/r/1519669030-176549-1-git-send-email-kan.li...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/builtin-top.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index b7c823ba8374..35ac016fcb98 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -991,7 +991,7 @@ static int perf_top_overwrite_fallback(struct perf_top *top,
evlist__for_each_entry(evlist, counter)
counter->attr.write_backward = false;
opts->overwrite = false;
-   ui__warning("fall back to non-overwrite mode\n");
+   pr_debug2("fall back to non-overwrite mode\n");
return 1;
 }
 
-- 
2.14.3

[PATCH 05/28] perf stat: Ignore error thread when enabling system-wide --per-thread

[Arnaldo Carvalho de Melo]

From: Jin Yao 

If we execute 'perf stat --per-thread' with non-root account (even set
kernel.perf_event_paranoid = -1 yet), it reports the error:

  jinyao@skl:~$ perf stat --per-thread
  Error:
  You may not have permission to collect system-wide stats.

  Consider tweaking /proc/sys/kernel/perf_event_paranoid,
  which controls use of the performance events system by
  unprivileged users (without CAP_SYS_ADMIN).

  The current value is 2:

-1: Allow use of (almost) all events by all users
Ignore mlock limit after perf_event_mlock_kb without CAP_IPC_LOCK
  >= 0: Disallow ftrace function tracepoint by users without CAP_SYS_ADMIN
Disallow raw tracepoint access by users without CAP_SYS_ADMIN
  >= 1: Disallow CPU event access by users without CAP_SYS_ADMIN
  >= 2: Disallow kernel profiling by users without CAP_SYS_ADMIN

  To make this setting permanent, edit /etc/sysctl.conf too, e.g.:

  kernel.perf_event_paranoid = -1

Perhaps the ptrace rule doesn't allow to trace some processes. But anyway
the global --per-thread mode had better ignore such errors and continue
working on other threads.

This patch will record the index of error thread in perf_evsel__open()
and remove this thread before retrying.

For example (run with non-root, kernel.perf_event_paranoid isn't set):

  jinyao@skl:~$ perf stat --per-thread
  ^C
   Performance counter stats for 'system wide':

 vmstat-34586.171984   cpu-clock:u (msec) #  0.000 CPUs utilized
   perf-36700.515599   cpu-clock:u (msec) #  0.000 CPUs utilized
 vmstat-3458   1,163,643   cycles:u   #  0.189 GHz
   perf-3670  40,881   cycles:u   #  0.079 GHz
 vmstat-3458   1,410,238   instructions:u #  1.21  insn per cycle
   perf-3670   3,536   instructions:u #  0.09  insn per cycle
 vmstat-3458 288,937   branches:u # 46.814 M/sec
   perf-3670 936   branches:u #  1.815 M/sec
 vmstat-3458  15,195   branch-misses:u#  5.26% of all branches
   perf-3670  76   branch-misses:u#  8.12% of all branches

12.651675247 seconds time elapsed

Signed-off-by: Jin Yao 
Acked-by: Jiri Olsa 
Tested-by: Arnaldo Carvalho de Melo 
Cc: Alexander Shishkin 
Cc: Andi Kleen 
Cc: Kan Liang 
Cc: Peter Zijlstra 
Link: 
http://lkml.kernel.org/r/1516117388-10120-1-git-send-email-yao@linux.intel.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/builtin-stat.c| 14 +-
 tools/perf/util/evsel.c  |  3 +++
 tools/perf/util/thread_map.c |  1 +
 tools/perf/util/thread_map.h |  1 +
 4 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index fadcff52cd09..6214d2b220b2 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -637,7 +637,19 @@ static int __run_perf_stat(int argc, const char **argv)
 if (verbose > 0)
 ui__warning("%s\n", msg);
 goto try_again;
-}
+   } else if (target__has_per_thread(&target) &&
+  evsel_list->threads &&
+  evsel_list->threads->err_thread != -1) {
+   /*
+* For global --per-thread case, skip current
+* error thread.
+*/
+   if (!thread_map__remove(evsel_list->threads,
+   
evsel_list->threads->err_thread)) {
+   evsel_list->threads->err_thread = -1;
+   goto try_again;
+   }
+   }
 
perf_evsel__open_strerror(counter, &target,
  errno, msg, sizeof(msg));
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index ef351688b797..b56e1c2ddaee 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -1915,6 +1915,9 @@ int perf_evsel__open(struct perf_evsel *evsel, struct 
cpu_map *cpus,
goto fallback_missing_features;
}
 out_close:
+   if (err)
+   threads->err_thread = thread;
+
do {
while (--thread >= 0) {
close(FD(evsel, cpu, thread));
diff --git a/tools/perf/util/thread_map.c b/tools/perf/util/thread_map.c
index 729dad8f412d..5d467d8ae9ab 100644
--- a/tools/perf/util/thread_map.c
+++ b/tools/perf/util/thread_map.c
@@ -32,6 +32,7 @@ static void thread_map__reset(struct thread_map *map, int 
start, int nr)
size_t size = (nr - start) * sizeof(map->map[0]);
 
memset(&map->map[start], 0, size);
+   map->err_thread = -1;
 }
 
 static struct thread_map *thread_

[PATCH v2 0/5] Migrate all TPM 2.0 commands to use struct tpm_buf

[Jarkko Sakkinen]

v2:
* Fixed author information in the commit that fixes the self-test issue,
  removed '\n' from the log message and added the missing tested-by.
  (James: sincere apologies about this)
* Removed the redundant "out of memory" log message from tpm2_shutdown().
* tpm_buf_destroy() was called before using the response data in
  tpm2_probe().
* Added missing tpm_buf_destroy() to tpm2_get_random().

James Bottomley (1):
  tpm: fix intermittent failure with self tests

Jarkko Sakkinen (4):
  tpm: migrate tpm2_shutdown() to use struct tpm_buf
  tpm: migrate tpm2_probe() to use struct tpm_buf
  tpm: migrate tpm2_get_tpm_pt() to use struct tpm_buf
  tpm: migrate tpm2_get_random() to use struct tpm_buf

 drivers/char/tpm/tpm-interface.c |  20 ++-
 drivers/char/tpm/tpm.h   |  20 +--
 drivers/char/tpm/tpm2-cmd.c  | 281 ++-
 3 files changed, 128 insertions(+), 193 deletions(-)

-- 
2.15.1

[PATCH v2 4/5] tpm: migrate tpm2_get_tpm_pt() to use struct tpm_buf

[Jarkko Sakkinen]

In order to make struct tpm_buf the first class object for constructing TPM
commands, migrate tpm2_get_tpm_pt() to use it.

Signed-off-by: Jarkko Sakkinen 
---
 drivers/char/tpm/tpm2-cmd.c | 63 +
 1 file changed, 23 insertions(+), 40 deletions(-)

diff --git a/drivers/char/tpm/tpm2-cmd.c b/drivers/char/tpm/tpm2-cmd.c
index 890d83c5c78b..e02f7d46e9ac 100644
--- a/drivers/char/tpm/tpm2-cmd.c
+++ b/drivers/char/tpm/tpm2-cmd.c
@@ -27,20 +27,6 @@ enum tpm2_session_attributes {
TPM2_SA_CONTINUE_SESSION= BIT(0),
 };
 
-struct tpm2_get_tpm_pt_in {
-   __be32  cap_id;
-   __be32  property_id;
-   __be32  property_cnt;
-} __packed;
-
-struct tpm2_get_tpm_pt_out {
-   u8  more_data;
-   __be32  subcap_id;
-   __be32  property_cnt;
-   __be32  property_id;
-   __be32  value;
-} __packed;
-
 struct tpm2_get_random_in {
__be16  size;
 } __packed;
@@ -51,8 +37,6 @@ struct tpm2_get_random_out {
 } __packed;
 
 union tpm2_cmd_params {
-   struct  tpm2_get_tpm_pt_in  get_tpm_pt_in;
-   struct  tpm2_get_tpm_pt_out get_tpm_pt_out;
struct  tpm2_get_random_in  getrandom_in;
struct  tpm2_get_random_out getrandom_out;
 };
@@ -377,19 +361,6 @@ int tpm2_get_random(struct tpm_chip *chip, u8 *out, size_t 
max)
return total ? total : -EIO;
 }
 
-#define TPM2_GET_TPM_PT_IN_SIZE \
-   (sizeof(struct tpm_input_header) + \
-sizeof(struct tpm2_get_tpm_pt_in))
-
-#define TPM2_GET_TPM_PT_OUT_BODY_SIZE \
-sizeof(struct tpm2_get_tpm_pt_out)
-
-static const struct tpm_input_header tpm2_get_tpm_pt_header = {
-   .tag = cpu_to_be16(TPM2_ST_NO_SESSIONS),
-   .length = cpu_to_be32(TPM2_GET_TPM_PT_IN_SIZE),
-   .ordinal = cpu_to_be32(TPM2_CC_GET_CAPABILITY)
-};
-
 /**
  * tpm2_flush_context_cmd() - execute a TPM2_FlushContext command
  * @chip: TPM chip to use
@@ -723,6 +694,14 @@ int tpm2_unseal_trusted(struct tpm_chip *chip,
return rc;
 }
 
+struct tpm2_get_cap_out {
+   u8 more_data;
+   __be32 subcap_id;
+   __be32 property_cnt;
+   __be32 property_id;
+   __be32 value;
+} __packed;
+
 /**
  * tpm2_get_tpm_pt() - get value of a TPM_CAP_TPM_PROPERTIES type property
  * @chip:  TPM chip to use.
@@ -735,19 +714,23 @@ int tpm2_unseal_trusted(struct tpm_chip *chip,
 ssize_t tpm2_get_tpm_pt(struct tpm_chip *chip, u32 property_id,  u32 *value,
const char *desc)
 {
-   struct tpm2_cmd cmd;
+   struct tpm2_get_cap_out *out;
+   struct tpm_buf buf;
int rc;
 
-   cmd.header.in = tpm2_get_tpm_pt_header;
-   cmd.params.get_tpm_pt_in.cap_id = cpu_to_be32(TPM2_CAP_TPM_PROPERTIES);
-   cmd.params.get_tpm_pt_in.property_id = cpu_to_be32(property_id);
-   cmd.params.get_tpm_pt_in.property_cnt = cpu_to_be32(1);
-
-   rc = tpm_transmit_cmd(chip, NULL, &cmd, sizeof(cmd),
- TPM2_GET_TPM_PT_OUT_BODY_SIZE, 0, desc);
-   if (!rc)
-   *value = be32_to_cpu(cmd.params.get_tpm_pt_out.value);
-
+   rc = tpm_buf_init(&buf, TPM2_ST_NO_SESSIONS, TPM2_CC_GET_CAPABILITY);
+   if (rc)
+   return rc;
+   tpm_buf_append_u32(&buf, TPM2_CAP_TPM_PROPERTIES);
+   tpm_buf_append_u32(&buf, property_id);
+   tpm_buf_append_u32(&buf, 1);
+   rc = tpm_transmit_cmd(chip, NULL, buf.data, PAGE_SIZE, 0, 0, NULL);
+   if (!rc) {
+   out = (struct tpm2_get_cap_out *)
+   &buf.data[TPM_HEADER_SIZE];
+   *value = be32_to_cpu(out->value);
+   }
+   tpm_buf_destroy(&buf);
return rc;
 }
 EXPORT_SYMBOL_GPL(tpm2_get_tpm_pt);
-- 
2.15.1

[PATCH v2 2/5] tpm: migrate tpm2_shutdown() to use struct tpm_buf

[Jarkko Sakkinen]

In order to make struct tpm_buf the first class object for constructing TPM
commands, migrate tpm2_shutdown() to use it. In addition, removed the klog
entry when tpm_transmit_cmd() fails because tpm_tansmit_cmd() already
prints an error message.

Signed-off-by: Jarkko Sakkinen 
---
 drivers/char/tpm/tpm2-cmd.c | 44 
 1 file changed, 12 insertions(+), 32 deletions(-)

diff --git a/drivers/char/tpm/tpm2-cmd.c b/drivers/char/tpm/tpm2-cmd.c
index 89a5397b18d2..abe6ef4a7a0b 100644
--- a/drivers/char/tpm/tpm2-cmd.c
+++ b/drivers/char/tpm/tpm2-cmd.c
@@ -27,10 +27,6 @@ enum tpm2_session_attributes {
TPM2_SA_CONTINUE_SESSION= BIT(0),
 };
 
-struct tpm2_startup_in {
-   __be16  startup_type;
-} __packed;
-
 struct tpm2_get_tpm_pt_in {
__be32  cap_id;
__be32  property_id;
@@ -55,7 +51,6 @@ struct tpm2_get_random_out {
 } __packed;
 
 union tpm2_cmd_params {
-   struct  tpm2_startup_in startup_in;
struct  tpm2_get_tpm_pt_in  get_tpm_pt_in;
struct  tpm2_get_tpm_pt_out get_tpm_pt_out;
struct  tpm2_get_random_in  getrandom_in;
@@ -410,11 +405,8 @@ void tpm2_flush_context_cmd(struct tpm_chip *chip, u32 
handle,
int rc;
 
rc = tpm_buf_init(&buf, TPM2_ST_NO_SESSIONS, TPM2_CC_FLUSH_CONTEXT);
-   if (rc) {
-   dev_warn(&chip->dev, "0x%08x was not flushed, out of memory\n",
-handle);
+   if (rc)
return;
-   }
 
tpm_buf_append_u32(&buf, handle);
 
@@ -760,40 +752,28 @@ ssize_t tpm2_get_tpm_pt(struct tpm_chip *chip, u32 
property_id,  u32 *value,
 }
 EXPORT_SYMBOL_GPL(tpm2_get_tpm_pt);
 
-#define TPM2_SHUTDOWN_IN_SIZE \
-   (sizeof(struct tpm_input_header) + \
-sizeof(struct tpm2_startup_in))
-
-static const struct tpm_input_header tpm2_shutdown_header = {
-   .tag = cpu_to_be16(TPM2_ST_NO_SESSIONS),
-   .length = cpu_to_be32(TPM2_SHUTDOWN_IN_SIZE),
-   .ordinal = cpu_to_be32(TPM2_CC_SHUTDOWN)
-};
-
 /**
  * tpm2_shutdown() - send shutdown command to the TPM chip
  *
+ * In places where shutdown command is sent there's no much we can do except
+ * print the error code on a system failure.
+ *
  * @chip:  TPM chip to use.
  * @shutdown_type: shutdown type. The value is either
  * TPM_SU_CLEAR or TPM_SU_STATE.
  */
 void tpm2_shutdown(struct tpm_chip *chip, u16 shutdown_type)
 {
-   struct tpm2_cmd cmd;
+   struct tpm_buf buf;
int rc;
 
-   cmd.header.in = tpm2_shutdown_header;
-   cmd.params.startup_in.startup_type = cpu_to_be16(shutdown_type);
-
-   rc = tpm_transmit_cmd(chip, NULL, &cmd, sizeof(cmd), 0, 0,
- "stopping the TPM");
-
-   /* In places where shutdown command is sent there's no much we can do
-* except print the error code on a system failure.
-*/
-   if (rc < 0 && rc != -EPIPE)
-   dev_warn(&chip->dev, "transmit returned %d while stopping the 
TPM",
-rc);
+   rc = tpm_buf_init(&buf, TPM2_ST_NO_SESSIONS, TPM2_CC_SHUTDOWN);
+   if (rc)
+   return;
+   tpm_buf_append_u16(&buf, shutdown_type);
+   tpm_transmit_cmd(chip, NULL, buf.data, PAGE_SIZE, 0, 0,
+"stopping the TPM");
+   tpm_buf_destroy(&buf);
 }
 
 /*
-- 
2.15.1

[PATCH v2 5/5] tpm: migrate tpm2_get_random() to use struct tpm_buf

[Jarkko Sakkinen]

In order to make struct tpm_buf the first class object for constructing
TPM commands, migrate tpm2_get_random() to use it. In addition, removed
remaining references to struct tpm2_cmd. All of them use it to acquire
the length of the response, which can be achieved by using
tpm_buf_length().

Signed-off-by: Jarkko Sakkinen 
---
 drivers/char/tpm/tpm.h  | 19 -
 drivers/char/tpm/tpm2-cmd.c | 93 +
 2 files changed, 45 insertions(+), 67 deletions(-)

diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
index cccd5994a0e1..29c0717437bc 100644
--- a/drivers/char/tpm/tpm.h
+++ b/drivers/char/tpm/tpm.h
@@ -412,23 +412,24 @@ struct tpm_buf {
u8 *data;
 };
 
-static inline int tpm_buf_init(struct tpm_buf *buf, u16 tag, u32 ordinal)
+static inline void tpm_buf_reset(struct tpm_buf *buf, u16 tag, u32 ordinal)
 {
struct tpm_input_header *head;
+   head = (struct tpm_input_header *)buf->data;
+   head->tag = cpu_to_be16(tag);
+   head->length = cpu_to_be32(sizeof(*head));
+   head->ordinal = cpu_to_be32(ordinal);
+}
 
+static inline int tpm_buf_init(struct tpm_buf *buf, u16 tag, u32 ordinal)
+{
buf->data_page = alloc_page(GFP_HIGHUSER);
if (!buf->data_page)
return -ENOMEM;
 
buf->flags = 0;
buf->data = kmap(buf->data_page);
-
-   head = (struct tpm_input_header *) buf->data;
-
-   head->tag = cpu_to_be16(tag);
-   head->length = cpu_to_be32(sizeof(*head));
-   head->ordinal = cpu_to_be32(ordinal);
-
+   tpm_buf_reset(buf, tag, ordinal);
return 0;
 }
 
@@ -557,7 +558,7 @@ static inline u32 tpm2_rc_value(u32 rc)
 int tpm2_pcr_read(struct tpm_chip *chip, int pcr_idx, u8 *res_buf);
 int tpm2_pcr_extend(struct tpm_chip *chip, int pcr_idx, u32 count,
struct tpm2_digest *digests);
-int tpm2_get_random(struct tpm_chip *chip, u8 *out, size_t max);
+int tpm2_get_random(struct tpm_chip *chip, u8 *dest, size_t max);
 void tpm2_flush_context_cmd(struct tpm_chip *chip, u32 handle,
unsigned int flags);
 int tpm2_seal_trusted(struct tpm_chip *chip,
diff --git a/drivers/char/tpm/tpm2-cmd.c b/drivers/char/tpm/tpm2-cmd.c
index e02f7d46e9ac..36a58af6f5c7 100644
--- a/drivers/char/tpm/tpm2-cmd.c
+++ b/drivers/char/tpm/tpm2-cmd.c
@@ -27,25 +27,6 @@ enum tpm2_session_attributes {
TPM2_SA_CONTINUE_SESSION= BIT(0),
 };
 
-struct tpm2_get_random_in {
-   __be16  size;
-} __packed;
-
-struct tpm2_get_random_out {
-   __be16  size;
-   u8  buffer[TPM_MAX_RNG_DATA];
-} __packed;
-
-union tpm2_cmd_params {
-   struct  tpm2_get_random_in  getrandom_in;
-   struct  tpm2_get_random_out getrandom_out;
-};
-
-struct tpm2_cmd {
-   tpm_cmd_header  header;
-   union tpm2_cmd_params   params;
-} __packed;
-
 struct tpm2_hash {
unsigned int crypto_id;
unsigned int tpm_id;
@@ -298,66 +279,66 @@ int tpm2_pcr_extend(struct tpm_chip *chip, int pcr_idx, 
u32 count,
 }
 
 
-#define TPM2_GETRANDOM_IN_SIZE \
-   (sizeof(struct tpm_input_header) + \
-sizeof(struct tpm2_get_random_in))
-
-static const struct tpm_input_header tpm2_getrandom_header = {
-   .tag = cpu_to_be16(TPM2_ST_NO_SESSIONS),
-   .length = cpu_to_be32(TPM2_GETRANDOM_IN_SIZE),
-   .ordinal = cpu_to_be32(TPM2_CC_GET_RANDOM)
-};
+struct tpm2_get_random_out {
+   __be16 size;
+   u8 buffer[TPM_MAX_RNG_DATA];
+} __packed;
 
 /**
  * tpm2_get_random() - get random bytes from the TPM RNG
  *
  * @chip: TPM chip to use
- * @out: destination buffer for the random bytes
+ * @dest: destination buffer for the random bytes
  * @max: the max number of bytes to write to @out
  *
  * Return:
- *Size of the output buffer, or -EIO on error.
+ * size of the output buffer when the operation is successful.
+ * A negative number for system errors (errno).
  */
-int tpm2_get_random(struct tpm_chip *chip, u8 *out, size_t max)
+int tpm2_get_random(struct tpm_chip *chip, u8 *dest, size_t max)
 {
-   struct tpm2_cmd cmd;
-   u32 recd, rlength;
-   u32 num_bytes;
+   struct tpm2_get_random_out *out;
+   struct tpm_buf buf;
+   u32 recd;
+   u32 num_bytes = max;
int err;
int total = 0;
int retries = 5;
-   u8 *dest = out;
+   u8 *dest_ptr = dest;
 
-   num_bytes = min_t(u32, max, sizeof(cmd.params.getrandom_out.buffer));
-
-   if (!out || !num_bytes ||
-   max > sizeof(cmd.params.getrandom_out.buffer))
+   if (!num_bytes || max > TPM_MAX_RNG_DATA)
return -EINVAL;
 
-   do {
-   cmd.header.in = tpm2_getrandom_header;
-   cmd.params.getrandom_in.size = cpu_to_be16(num_bytes);
+   err = tpm_buf_init(&buf, 0, 0);
+   if (err)
+   return err;
 
-   err = tpm_transmit_cmd(chip, NULL, &cmd, sizeof(cmd),
+   do {
+   tpm_buf_reset(&buf, T

[PATCH v2 3/5] tpm: migrate tpm2_probe() to use struct tpm_buf

[Jarkko Sakkinen]

In order to make struct tpm_buf the first class object for constructing TPM
commands, migrate tpm2_probe() to use it.

Signed-off-by: Jarkko Sakkinen 
---
 drivers/char/tpm/tpm2-cmd.c | 27 +++
 1 file changed, 15 insertions(+), 12 deletions(-)

diff --git a/drivers/char/tpm/tpm2-cmd.c b/drivers/char/tpm/tpm2-cmd.c
index abe6ef4a7a0b..890d83c5c78b 100644
--- a/drivers/char/tpm/tpm2-cmd.c
+++ b/drivers/char/tpm/tpm2-cmd.c
@@ -851,22 +851,25 @@ static int tpm2_do_selftest(struct tpm_chip *chip)
  */
 int tpm2_probe(struct tpm_chip *chip)
 {
-   struct tpm2_cmd cmd;
+   struct tpm_output_header *out;
+   struct tpm_buf buf;
int rc;
 
-   cmd.header.in = tpm2_get_tpm_pt_header;
-   cmd.params.get_tpm_pt_in.cap_id = cpu_to_be32(TPM2_CAP_TPM_PROPERTIES);
-   cmd.params.get_tpm_pt_in.property_id = cpu_to_be32(0x100);
-   cmd.params.get_tpm_pt_in.property_cnt = cpu_to_be32(1);
-
-   rc = tpm_transmit_cmd(chip, NULL, &cmd, sizeof(cmd), 0, 0, NULL);
-   if (rc <  0)
+   rc = tpm_buf_init(&buf, TPM2_ST_NO_SESSIONS, TPM2_CC_GET_CAPABILITY);
+   if (rc)
return rc;
-
-   if (be16_to_cpu(cmd.header.out.tag) == TPM2_ST_NO_SESSIONS)
+   tpm_buf_append_u32(&buf, TPM2_CAP_TPM_PROPERTIES);
+   tpm_buf_append_u32(&buf, TPM_PT_TOTAL_COMMANDS);
+   tpm_buf_append_u32(&buf, 1);
+   rc = tpm_transmit_cmd(chip, NULL, buf.data, PAGE_SIZE, 0, 0, NULL);
+   if (rc <  0)
+   goto out;
+   out = (struct tpm_output_header *)buf.data;
+   if (be16_to_cpu(out->tag) == TPM2_ST_NO_SESSIONS)
chip->flags |= TPM_CHIP_FLAG_TPM2;
-
-   return 0;
+out:
+   tpm_buf_destroy(&buf);
+   return rc;
 }
 EXPORT_SYMBOL_GPL(tpm2_probe);
 
-- 
2.15.1

Re: [PATCH v5 0/5] Add coupled regulators mechanism

[Maciej Purski]

Hi Fabio,
thank you for your response.
Could you tell me on which board precisely (on which DTS) has this issue 
occurred?
Also, I don't understand, did you boot successfully and you got only a lockdep 
warning or you encountered an actual deadlock?


Best regards,
Maciej Purski


On 03/05/2018 01:34 PM, Fabio Estevam wrote:

Hi Maciej,

On Fri, Mar 2, 2018 at 5:42 AM, Maciej Purski  wrote:

Hi all,

this patchset adds a new mechanism to the framework - regulators' coupling.

On Odroid XU3/4 and other Exynos5422 based boards there is a case, that
different devices on the board are supplied by different regulators
with non-fixed voltages. If one of these devices temporarily requires
higher voltage, there might occur a situation that the spread between
devices' voltages is so high, that there is a risk of changing
'high' and 'low' states on the interconnection between devices powered
by those regulators.

Algorithmicaly the problem was solved by:
Inderpal Singh 
Doug Anderson 

The discussion on that subject can be found here:
https://lkml.org/lkml/2014/4/29/28

Therefore this patchset is an attempt to apply the idea to regulators core
as concluded in the discussion by Mark Brown and Doug Anderson.

This feature is required to enable support for generic CPUfreq
and devfreq drivers for the mentioned boards.

Note on the locking model:
When balancing voltage of a group of coupled regulators, we lock all
of them for the whole operation. When voltage of an individual regulator
is about to change, its suppliers are additionally locked.

The current assumption is that an uncoupled regulator is a special case
of a coupled one, so they should share a common voltage setting path.


This series breaks has reached linux-next 20180305 and it breaks
booting on imx6:

[0.269646] imx-pgc-pd imx-pgc-power-domain.0: Linked as a consumer
to 20dc000.gpc
[0.270348]
[0.270363] 
[0.270373] WARNING: possible recursive locking detected
[    0.270385] 4.16.0-rc3-next-20180305 #156 Not tainted
[0.270397] 
[0.270408] swapper/0/1 is trying to acquire lock:
[0.270419]  (&rdev->mutex){+.+.}, at: []
regulator_lock_supply+0x24/0x44
[0.270460]
[0.270460] but task is already holding lock:
[0.270471]  (&rdev->mutex){+.+.}, at: []
regulator_enable+0x78/0x298
[0.270502]
[0.270502] other info that might help us debug this:
[0.270513]  Possible unsafe locking scenario:
[0.270513]
[0.270523]CPU0
[0.270532]
[0.270540]   lock(&rdev->mutex);
[0.270555]   lock(&rdev->mutex);
[0.270572]
[0.270572]  *** DEADLOCK ***
[0.270572]
[0.270585]  May be due to missing lock nesting notation
[0.270585]
[0.270598] 3 locks held by swapper/0/1:
[0.270606]  #0:  (&dev->mutex){}, at: []
__driver_attach+0x58/0xcc
[0.270642]  #1:  (&dev->mutex){}, at: []
__driver_attach+0x68/0xcc
[0.270672]  #2:  (&rdev->mutex){+.+.}, at: []
regulator_enable+0x78/0x298
[0.270701]
[0.270701] stack backtrace:
[0.270719] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
4.16.0-rc3-next-20180305 #156
[0.270731] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[0.270741] Backtrace:
[0.270767] [] (dump_backtrace) from []
(show_stack+0x18/0x1c)
[0.270783]  r7: r6:6093 r5: r4:c1078360
[0.270805] [] (show_stack) from []
(dump_stack+0xb4/0xe8)
[0.270830] [] (dump_stack) from []
(__lock_acquire+0x13a4/0x199c)
[0.270848]  r9:c17d75fc r8:c11ae35c r7:c17c73b0 r6:ec06
r5:ec060570 r4:c11ae35c
[0.270867] [] (__lock_acquire) from []
(lock_acquire+0x70/0x90)
[0.270883]  r10: r9:ec195800 r8:0001 r7:0001
r6:6013 r5:
[0.270893]  r4:e000
[0.270914] [] (lock_acquire) from []
(__mutex_lock+0x64/0x978)
[0.270929]  r8:0001 r7:0001 r6: r5: r4:ec00b89c
[0.270947] [] (__mutex_lock) from []
(mutex_lock_nested+0x24/0x2c)
[0.270963]  r10: r9:ec195800 r8:0001 r7:0001
r6:ec195800 r5:
[0.270975]  r4:ec00b800
[0.270992] [] (mutex_lock_nested) from []
(regulator_lock_supply+0x24/0x44)
[0.271013] [] (regulator_lock_supply) from []
(regulator_balance_voltage+0x298/0x584)
[0.271024]  r5:000b1008 r4:ec195800
[0.271042] [] (regulator_balance_voltage) from
[] (regulator_enable+0xdc/0x298)
[0.271059]  r10: r9: r8:0001 r7:0001
r6:ec195800 r5:ec195824
[0.271069]  r4:0001
[0.271086] [] (regulator_enable) from []
(imx6_pm_domain_power_on+0x30/0x1b4)
[0.271102]  r9: r8:c102d114 r7:c1008908 r6:c102d114
r5:ec3d7a00 r4:ec3d7a00
[0.271119] [] (imx6_pm_domain_power_on) from
[] (imx_pgc_power_domain_probe+0x64/0xf4)
[0.271135]  r8:c102d114 r7:ec49c810 r6:c102d114 r5:ec49c800 r4:ec3d7a00

[PATCH v2 1/5] tpm: fix intermittent failure with self tests

[Jarkko Sakkinen]

From: James Bottomley 

My Nuvoton 6xx in a Dell XPS-13 has been intermittently failing to work
(necessitating a reboot). The problem seems to be that the TPM gets into a
state where the partial self-test doesn't return TPM_RC_SUCCESS (meaning
all tests have run to completion), but instead returns TPM_RC_TESTING
(meaning some tests are still running in the background).  There are
various theories that resending the self-test command actually causes the
tests to restart and thus triggers more TPM_RC_TESTING returns until the
timeout is exceeded.

There are several issues here: firstly being we shouldn't slow down the
boot sequence waiting for the self test to complete once the TPM
backgrounds them.  It will actually make available all functions that have
passed and if it gets a failure return TPM_RC_FAILURE to every subsequent
command.  So the fix is to kick off self tests once and if they return
TPM_RC_TESTING log that as a backgrounded self test and continue on.  In
order to prevent other tpm users from seeing any TPM_RC_TESTING returns
(which it might if they send a command that needs a TPM subsystem which is
still under test), we loop in tpm_transmit_cmd until either a timeout or we
don't get a TPM_RC_TESTING return.

Finally, there have been observations of strange returns from a partial
test. One Nuvoton is occasionally returning TPM_RC_COMMAND_CODE, so treat
any unexpected return from a partial self test as an indication we need to
run a full self test.

[jarkko.sakki...@linux.intel.com: cleaned up James' original commit and
 added a proper Fixes line]

Fixes: 2482b1bba5122 ("tpm: Trigger only missing TPM 2.0 self tests")
Cc: sta...@vger.kernel.org
Signed-off-by: James Bottomley 
Tested-by: Jarkko Sakkinen 
Signed-off-by: Jarkko Sakkinen 
---
 drivers/char/tpm/tpm-interface.c | 20 ---
 drivers/char/tpm/tpm.h   |  1 +
 drivers/char/tpm/tpm2-cmd.c  | 54 
 3 files changed, 33 insertions(+), 42 deletions(-)

diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
index 9e80a953d693..1adb976a2e37 100644
--- a/drivers/char/tpm/tpm-interface.c
+++ b/drivers/char/tpm/tpm-interface.c
@@ -537,14 +537,26 @@ ssize_t tpm_transmit_cmd(struct tpm_chip *chip, struct 
tpm_space *space,
 const char *desc)
 {
const struct tpm_output_header *header = buf;
+   unsigned int delay_msec = TPM2_DURATION_SHORT;
int err;
ssize_t len;
 
-   len = tpm_transmit(chip, space, (u8 *)buf, bufsiz, flags);
-   if (len <  0)
-   return len;
+   for (;;) {
+   len = tpm_transmit(chip, space, (u8 *)buf, bufsiz, flags);
+   if (len <  0)
+   return len;
+   err = be32_to_cpu(header->return_code);
+   if (err != TPM2_RC_TESTING)
+   break;
+
+   delay_msec *= 2;
+   if (delay_msec > TPM2_DURATION_LONG) {
+   dev_err(&chip->dev, "the self test is still running\n");
+   break;
+   }
+   tpm_msleep(delay_msec);
+   }
 
-   err = be32_to_cpu(header->return_code);
if (err != 0 && desc)
dev_err(&chip->dev, "A TPM error (%d) occurred %s\n", err,
desc);
diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
index f895fba4e20d..cccd5994a0e1 100644
--- a/drivers/char/tpm/tpm.h
+++ b/drivers/char/tpm/tpm.h
@@ -104,6 +104,7 @@ enum tpm2_return_codes {
TPM2_RC_HASH= 0x0083, /* RC_FMT1 */
TPM2_RC_HANDLE  = 0x008B,
TPM2_RC_INITIALIZE  = 0x0100, /* RC_VER1 */
+   TPM2_RC_FAILURE = 0x0101,
TPM2_RC_DISABLED= 0x0120,
TPM2_RC_COMMAND_CODE= 0x0143,
TPM2_RC_TESTING = 0x090A, /* RC_WARN */
diff --git a/drivers/char/tpm/tpm2-cmd.c b/drivers/char/tpm/tpm2-cmd.c
index a700f8f9ead7..89a5397b18d2 100644
--- a/drivers/char/tpm/tpm2-cmd.c
+++ b/drivers/char/tpm/tpm2-cmd.c
@@ -31,10 +31,6 @@ struct tpm2_startup_in {
__be16  startup_type;
 } __packed;
 
-struct tpm2_self_test_in {
-   u8  full_test;
-} __packed;
-
 struct tpm2_get_tpm_pt_in {
__be32  cap_id;
__be32  property_id;
@@ -60,7 +56,6 @@ struct tpm2_get_random_out {
 
 union tpm2_cmd_params {
struct  tpm2_startup_in startup_in;
-   struct  tpm2_self_test_in   selftest_in;
struct  tpm2_get_tpm_pt_in  get_tpm_pt_in;
struct  tpm2_get_tpm_pt_out get_tpm_pt_out;
struct  tpm2_get_random_in  getrandom_in;
@@ -827,16 +822,6 @@ unsigned long tpm2_calc_ordinal_duration(struct tpm_chip 
*chip, u32 ordinal)
 }
 EXPORT_SYMBOL_GPL(tpm2_calc_ordinal_duration);
 
-#define TPM2_SELF_TEST_IN_SIZE \
-   (sizeof(struct tpm_input_header) + \
-sizeof(struct tpm2_self_test_in))
-
-static const struct tpm_input_header tpm2_selftest_heade

RE: regression: SCSI/SATA failure

[David Laight]

From: Thorsten Leemhuis
> Hi! On 22.02.2018 15:57, Artem Bityutskiy wrote:
> > On Thu, 2018-02-22 at 16:54 +0200, Artem Bityutskiy wrote:
> >> one of our test box Skylake servers does not boot with v4.16-rcX.
> >> Bisection lead us to this commit:
> >> 84676c1f21e8 genirq/affinity: assign vectors to all possible CPUs
> >> Reverting this single commit fixes the problem.
> 
> Artem, is this issue still happening? I still have it in my list of
> regressions. Side note: I accidentally noticed people continue working
> in the area that 84676c1f21e8 touched;  see
> https://marc.info/?l=linux-block&m=152021971313902&w=2 ("[PATCH V2 5/5]
> genirq/affinity: irq vector spread among online CPUs as far as
> possible"). I wonder if that might be related in any way. Ciao, Thorsten

Hmmm I can think of some workloads where you really don't want some
cpu taking any interrupts at all (well as few as possible).
Think of workloads where process affinities are used to ensure that only
a few specific processes run on certain cpus.
The last thing you want then is interrupt load sharing and/or per cpu
ethernet rings.

David

Re: regression: SCSI/SATA failure

[Artem Bityutskiy]

Linux-Regression-ID: lr#15a115

On Thu, 2018-02-22 at 16:54 +0200, Artem Bityutskiy wrote:
> Hi Christoph,
> 
> one of our test box Skylake servers does not boot with v4.16-rcX.
> Bisection lead us to this commit:
> 
> 84676c1f21e8 genirq/affinity: assign vectors to all possible CPUs
> 
> Reverting this single commit fixes the problem.
> 
> The server is a Dell R640 machine with the latest Dell BIOS. It has a
> single SATA SSD and we do not use raid, even though the system does
> have a megaraid controller.

Correction: we have Raid0 with this single disk.

> Are you aware of this issue? Below is the failure message and the
> full
> dmesg with some debugging boot parameters is here:
> 
> https://pastebin.com/raw/tTYrTAEQ

FYI, the regression still exists and reverting this single patch fixes
it. But today Dell server

I did not have time to really debug this, but I think people who are
working with this should quickly see what is going on.

I think the platform reports way too large possible CPU count. Indeed,
in dmesg I see this:

[0.00] smpboot: Allowing 328 CPUs, 224 hotplug CPUs

224 is way too large for this system. It only has 2 sockets, it but the
number looks like if the system had 4 sockets.

The commit changes IRQ affinity logic from being per-present CPU to
being per-possible CPU:

-   for_each_present_cpu(cpu)
+   for_each_possible_cpu(cpu)

And it looks like this has an unexpected side-effect on this Dell
platform.

Artem.

Re: [PATCH v2 2/2] watchdog: Add Nuvoton NPCM watchdog driver

[Guenter Roeck]

Hi Joel,

On 03/05/2018 03:45 AM, Joel Stanley wrote:

The Nuvoton NPCM750 has a watchdog implemented as a single register
inside the timer peripheral.

This driver exposes that watchdog as a standard watchdog device with
coarse timeout intervals, limited by the combination of prescaler and
counter that is provided by the hardware. The calculation is taken from
the Nuvoton vendor tree.

There is a pre-timeout IRQ that is wired up. This timeout always occurs
1024 clocks before the timeout.

Signed-off-by: Joel Stanley 
---
v2:
  - Make MODULE_LICENCE gpl v2 to match SPDX
  - Remove unused struct device pointer
  - Remove unused setting of drvdata
  - Add linux/bitops.h
  - Sort includes
  - Remove unused fiq include
  - Update timeout with achieved value
---
  drivers/watchdog/Kconfig|  11 +++
  drivers/watchdog/Makefile   |   1 +
  drivers/watchdog/npcm_wdt.c | 230 
  3 files changed, 242 insertions(+)
  create mode 100644 drivers/watchdog/npcm_wdt.c

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index aff773bcebdb..0c1cc68894e6 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -513,6 +513,17 @@ config COH901327_WATCHDOG
  This watchdog is used to reset the system and thus cannot be
  compiled as a module.
  
+config NPCM7XX_WATCHDOG

+   bool "NPCM750 watchdog"
+   depends on ARCH_NPCM || COMPILE_TEST
+   default y if ARCH_NPCM750
+   select WATCHDOG_CORE
+   help
+ Say Y here to include Watchdog timer support for the
+ watchdog embedded into the NPCM7xx.
+ This watchdog is used to reset the system and thus cannot be
+ compiled as a module.
+
  config TWL4030_WATCHDOG
tristate "TWL4030 Watchdog"
depends on TWL4030_CORE
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 0474d38aa854..97a5afb5cad2 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -61,6 +61,7 @@ obj-$(CONFIG_ORION_WATCHDOG) += orion_wdt.o
  obj-$(CONFIG_SUNXI_WATCHDOG) += sunxi_wdt.o
  obj-$(CONFIG_RN5T618_WATCHDOG) += rn5t618_wdt.o
  obj-$(CONFIG_COH901327_WATCHDOG) += coh901327_wdt.o
+obj-$(CONFIG_NPCM7XX_WATCHDOG) += npcm_wdt.o
  obj-$(CONFIG_STMP3XXX_RTC_WATCHDOG) += stmp3xxx_rtc_wdt.o
  obj-$(CONFIG_NUC900_WATCHDOG) += nuc900_wdt.o
  obj-$(CONFIG_TS4800_WATCHDOG) += ts4800_wdt.o
diff --git a/drivers/watchdog/npcm_wdt.c b/drivers/watchdog/npcm_wdt.c
new file mode 100644
index ..2cfc58714d8d
--- /dev/null
+++ b/drivers/watchdog/npcm_wdt.c
@@ -0,0 +1,230 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2018 Nuvoton Technology corporation.
+// Copyright (c) 2018 IBM Corp.
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define NPCM_WTCR  0x1C
+
+#define NPCM_WTCLK (BIT(10) | BIT(11)) /* Clock divider */
+#define NPCM_WTE   BIT(7)  /* Enable */
+#define NPCM_WTIE  BIT(6)  /* Enable irq */
+#define NPCM_WTIS  (BIT(4) | BIT(5))   /* Interval selection */
+#define NPCM_WTIF  BIT(3)  /* Interrupt flag*/
+#define NPCM_WTRF  BIT(2)  /* Reset flag */
+#define NPCM_WTRE  BIT(1)  /* Reset enable */
+#define NPCM_WTR   BIT(0)  /* Reset counter */
+
+/*
+ * Watchdog timeouts
+ *
+ * 170 msec:WTCLK=01 WTIS=00 VAL= 0x400
+ * 670 msec:WTCLK=01 WTIS=01 VAL= 0x410
+ * 1360msec:WTCLK=10 WTIS=00 VAL= 0x800
+ * 2700msec:WTCLK=01 WTIS=10 VAL= 0x420
+ * 5360msec:WTCLK=10 WTIS=01 VAL= 0x810
+ * 10700   msec:WTCLK=01 WTIS=11 VAL= 0x430
+ * 21600   msec:WTCLK=10 WTIS=10 VAL= 0x820
+ * 43000   msec:WTCLK=11 WTIS=00 VAL= 0xC00
+ * 85600   msec:WTCLK=10 WTIS=11 VAL= 0x830
+ * 172000  msec:WTCLK=11 WTIS=01 VAL= 0xC10
+ * 687000  msec:WTCLK=11 WTIS=10 VAL= 0xC20
+ * 275 msec:WTCLK=11 WTIS=11 VAL= 0xC30
+ */
+
+struct npcm_wdt {
+   struct watchdog_device  wdd;
+   void __iomem*reg;
+};
+
+static inline struct npcm_wdt *to_npcm_wdt(struct watchdog_device *wdd)
+{
+   return container_of(wdd, struct npcm_wdt, wdd);
+}
+
+static int npcm_wdt_ping(struct watchdog_device *wdd)
+{
+   struct npcm_wdt *wdt = to_npcm_wdt(wdd);
+   u32 val;
+
+   val = readl(wdt->reg);
+   writel(val | NPCM_WTR, wdt->reg);
+
+   return 0;
+}
+
+static int npcm_wdt_start(struct watchdog_device *wdd)
+{
+   struct npcm_wdt *wdt = to_npcm_wdt(wdd);
+   u32 val;
+
+   val = NPCM_WTRE | NPCM_WTE | NPCM_WTR | NPCM_WTIE;
+
+   if (wdd->timeout < 2) {
+   val |= 0x800;
+   wdd->timeout = 1;
+   } else if (wdd->timeout < 3) {
+   val |= 0x420;
+   wdd->timeout = 2;
+   } else if (wdd->timeout < 6) {
+   val |= 0x810;
+  

Re: [PATCH v8 7/8] livepatch: Correctly handle atomic replace for not yet loaded modules

[Josh Poimboeuf]

On Mon, Mar 05, 2018 at 10:54:16AM +0100, Miroslav Benes wrote:
> > I think this problem is contained to only replacement patches that need
> > the nop-revert feature... if the replacement patch provides a new
> > function definition, then it shouldn't be affected.
> > 
> > Man, we need a regression test suite for all these cases :)
> 
> Any volunteer?

I'd strongly prefer that we get such selftests in place before merging
any more major features...

-- 
Josh

[GIT PULL 00/28] perf/core improvements and fixes

[Arnaldo Carvalho de Melo]

Hi Ingo,

Please consider pulling, I'll cherry pick some into a separate
perf/urgent pull request, like the jump-to-another-function one, after
the usual round of tests, but since I've been working on then in my
perf/core branch, lets flush them now.

- Arnaldo

Test results at the end of this message, as usual.
  
The following changes since commit ddc4becca1409541c2ebb7ecb99b5cef44cf17e4:

  Merge tag 'perf-core-for-mingo-4.17-20180220' of 
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core 
(2018-02-21 08:50:45 +0100)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git 
tags/perf-core-for-mingo-4.17-20180305

for you to fetch changes up to 6afad54d2f0ddebacfcf3b829147d7fed8dab298:

  perf mmap: Discard legacy interfaces for mmap read forward (2018-03-05 
10:51:10 -0300)


perf/core improvements and fixes:

- Be more robust when drawing arrows in the annotation TUI, avoiding a
  segfault when jump instructions have as a target addresses in functions
  other that the one currently being annotated. The full fix will come in
  the following days, when jumping to other functions will work as call
  instructions (Arnaldo Carvalho de Melo)

- Allow asking for the maximum allowed sample rate in 'top' and
  'record', i.e. 'perf record -F max' will read the
  kernel.perf_event_max_sample_rate sysctl and use it (Arnaldo Carvalho de Melo)

- When the user specifies a freq above kernel.perf_event_max_sample_rate,
  Throttle it down to that max freq, and warn the user about it, add as
  well --strict-freq so that the previous behaviour of not starting the
  session when the desired freq can't be used can be selected (Arnaldo Carvalho 
de Melo)

- Find 'call' instruction target symbol at parsing time, used so far in
  the TUI, part of the infrastructure changes that will end up allowing
  for jumps to navigate to other functions, just like 'call'
  instructions. (Arnaldo Carvalho de Melo)

- Use xyarray dimensions to iterate fds in 'perf stat' (Andi Kleen)

- Ignore threads for which the current user hasn't permissions when
  enabling system-wide --per-thread (Jin Yao)

- Fix some backtrace perf test cases to use 'perf record' + 'perf script'
  instead, till 'perf trace' starts using ordered_events or equivalent
  to avoid symbol resolving artifacts due to reordering of
  PERF_RECORD_MMAP events (Jiri Olsa)

- Fix crash in 'perf record' pipe mode, it needs to allocate the ID
  array even for a single event, unlike non-pipe mode (Jiri Olsa)

- Make annoying fallback message on older kernels with newer 'perf top'
  binaries trying to use overwrite mode and that not being present
  in the older kernels (Kan Liang)

- Switch last users of old APIs to the newer perf_mmap__read_event()
  one, then discard those old mmap read forward APIs (Kan Liang)

- Fix the usage on the 'perf kallsyms' man page (Sangwon Hong)

- Simplify cgroup arguments when tracking multiple events (weiping zhang)

Signed-off-by: Arnaldo Carvalho de Melo 


Andi Kleen (1):
  perf stat: Use xyarray dimensions to iterate fds

Arnaldo Carvalho de Melo (6):
  perf annotate browser: Be more robust when drawing jump arrows
  perf record: Allow asking for the maximum allowed sample rate
  perf top browser: Show sample_freq in browser title line
  perf top: Allow asking for the maximum allowed sample rate
  perf record: Throttle user defined frequencies to the maximum allowed
  perf annotate: Find 'call' instruction target symbol at parsing time

Jin Yao (1):
  perf stat: Ignore error thread when enabling system-wide --per-thread

Jiri Olsa (3):
  perf tests: Switch trace+probe_libc_inet_pton to use record
  perf tests: Rename trace+probe_libc_inet_pton to 
record+probe_libc_inet_pton
  perf record: Fix crash in pipe mode

Kan Liang (15):
  perf top: Fix annoying fallback message on older kernels
  perf kvm: Switch to new perf_mmap__read_event() interface
  perf trace: Switch to new perf_mmap__read_event() interface
  perf python: Switch to new perf_mmap__read_event() interface
  perf test: Switch to new perf_mmap__read_event() interface for bpf
  perf test: Switch to new perf_mmap__read_event() interface for 'code 
reading' test
  perf test: Switch to new perf_mmap__read_event() interface for "keep 
tracking" test
  perf test: Switch to new perf_mmap__read_event() interface for mmap-basic
  perf test: Switch to new perf_mmap__read_event() interface for tp fields
  perf test: Switch to new perf_mmap__read_event() interface for perf-record
  perf test: Switch to new perf_mmap__read_event() 

[PATCH 02/28] perf stat: Use xyarray dimensions to iterate fds

[Arnaldo Carvalho de Melo]

From: Andi Kleen 

Now that the xyarray stores the dimensions we can use those
to iterate over the FDs for a evsel.

Signed-off-by: Andi Kleen 
Acked-by: Jiri Olsa 
Link: http://lkml.kernel.org/r/20171006020029.13339-1-a...@firstfloor.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/builtin-stat.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 2d49eccf98f2..fadcff52cd09 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -508,14 +508,13 @@ static int perf_stat_synthesize_config(bool is_pipe)
 
 #define FD(e, x, y) (*(int *)xyarray__entry(e->fd, x, y))
 
-static int __store_counter_ids(struct perf_evsel *counter,
-  struct cpu_map *cpus,
-  struct thread_map *threads)
+static int __store_counter_ids(struct perf_evsel *counter)
 {
int cpu, thread;
 
-   for (cpu = 0; cpu < cpus->nr; cpu++) {
-   for (thread = 0; thread < threads->nr; thread++) {
+   for (cpu = 0; cpu < xyarray__max_x(counter->fd); cpu++) {
+   for (thread = 0; thread < xyarray__max_y(counter->fd);
+thread++) {
int fd = FD(counter, cpu, thread);
 
if (perf_evlist__id_add_fd(evsel_list, counter,
@@ -535,7 +534,7 @@ static int store_counter_ids(struct perf_evsel *counter)
if (perf_evsel__alloc_id(counter, cpus->nr, threads->nr))
return -ENOMEM;
 
-   return __store_counter_ids(counter, cpus, threads);
+   return __store_counter_ids(counter);
 }
 
 static bool perf_evsel__should_store_id(struct perf_evsel *counter)
-- 
2.14.3

Re: [PATCH v6 13/20] firmware: arm_scmi: refactor in preparation to support per-protocol channels

[Sudeep Holla]

On 05/03/18 14:35, Jonathan Cameron wrote:
> On Fri, 23 Feb 2018 16:23:43 +
> Sudeep Holla  wrote:
> 
>> In order to support per-protocol channels if available, we need to
>> factor out all the mailbox channel information(Tx/Rx payload and
>> channel handle) out of the main SCMI instance information structure.
>>
>> This patch refactors the existing channel information into a separate
>> chan_info structure.
>>
>> Cc: Arnd Bergmann 
>> Cc: Greg Kroah-Hartman 
>> Signed-off-by: Sudeep Holla 
> A little odd to present a series to mainline that does a fairly important
> refactor mid way through.  Why not push this down to the start and always 
> support
> the separate chan_info structure?
> 

Since the development started long back and this was added later, I
preferred to keep functionality working and didn't want to push change
down in the stack.

-- 
Regards,
Sudeep

Re: [PATCH v6 03/20] firmware: arm_scmi: add basic driver infrastructure for SCMI

[Jonathan Cameron]

> >> +/**
> >> + * scmi_one_xfer_get() - Allocate one message
> >> + *
> >> + * @handle: SCMI entity handle
> >> + *
> >> + * Helper function which is used by various command functions that are
> >> + * exposed to clients of this driver for allocating a message traffic 
> >> event.
> >> + *
> >> + * This function can sleep depending on pending requests already in the 
> >> system
> >> + * for the SCMI entity. Further, this also holds a spinlock to maintain
> >> + * integrity of internal data structures.
> >> + *
> >> + * Return: 0 if all went fine, else corresponding error.
> >> + */
> >> +static struct scmi_xfer *scmi_one_xfer_get(const struct scmi_handle 
> >> *handle)  
> > Maybe it's just me, but I think this would be more clearly named as
> > scmi_xfer_alloc.
> >   
> 
> Agreed to some extent. The reason I didn't have it as alloc as they are
> preallocated and this just returns a reference to free slot in that
> preallocated array.
> 
> > I'd assume we were dealing with one anyway as it's not called scmi_xfers_get
> > and the get to my mind implies a reference counter rather than allocating
> > an xfer for use...
> >   
> 
> Ah OK, I get your concerne with _get/_put but _alloc/_free is equally
> bad then in the contect of preallocated buffers.
Sure, this is always a fun question.  Lots of other options
_assign _deassign works but never feels nice.

> 
...
> 
> >> +  .max_msg = 20,  /* Limited by MBOX_TX_QUEUE_LEN */
> >> +  .max_msg_size = 128,
> >> +};
> >> +
> >> +/* Each compatible listed below must have descriptor associated with it */
> >> +static const struct of_device_id scmi_of_match[] = {
> >> +  { .compatible = "arm,scmi", .data = &scmi_generic_desc },
> >> +  { /* Sentinel */ },
> >> +};
> >> +
> >> +MODULE_DEVICE_TABLE(of, scmi_of_match);
> >> +
> >> +static int scmi_xfer_info_init(struct scmi_info *sinfo)
> >> +{
> >> +  int i;
> >> +  struct scmi_xfer *xfer;
> >> +  struct device *dev = sinfo->dev;
> >> +  const struct scmi_desc *desc = sinfo->desc;
> >> +  struct scmi_xfers_info *info = &sinfo->minfo;
> >> +
> >> +  /* Pre-allocated messages, no more than what hdr.seq can support */
> >> +  if (WARN_ON(desc->max_msg >= (MSG_TOKEN_ID_MASK + 1))) {
> >> +  dev_err(dev, "Maximum message of %d exceeds supported %d\n",
> >> +  desc->max_msg, MSG_TOKEN_ID_MASK + 1);
> >> +  return -EINVAL;
> >> +  }
> >> +
> >> +  info->xfer_block = devm_kcalloc(dev, desc->max_msg,
> >> +  sizeof(*info->xfer_block), GFP_KERNEL);
> >> +  if (!info->xfer_block)
> >> +  return -ENOMEM;
> >> +
> >> +  info->xfer_alloc_table = devm_kcalloc(dev, BITS_TO_LONGS(desc->max_msg),
> >> +sizeof(long), GFP_KERNEL);
> >> +  if (!info->xfer_alloc_table)
> >> +  return -ENOMEM;  
> > Hmm. I wonder if it is worth adding a devm_bitmap_alloc?
> >   
> 
> OK
> 
> >> +
> >> +  bitmap_zero(info->xfer_alloc_table, desc->max_msg);  
> > kcalloc zeros the memory.
> >   
> >> +
> >> +  /* Pre-initialize the buffer pointer to pre-allocated buffers */
> >> +  for (i = 0, xfer = info->xfer_block; i < desc->max_msg; i++, xfer++) {
> >> +  xfer->rx.buf = devm_kcalloc(dev, sizeof(u8), desc->max_msg_size,
> >> +  GFP_KERNEL);
> >> +  if (!xfer->rx.buf)
> >> +  return -ENOMEM;
> >> +
> >> +  xfer->tx.buf = xfer->rx.buf;
> >> +  init_completion(&xfer->done);
> >> +  }
> >> +
> >> +  spin_lock_init(&info->xfer_lock);
> >> +
> >> +  return 0;
> >> +}
> >> +
> >> +static int scmi_mailbox_check(struct device_node *np)
> >> +{
> >> +  struct of_phandle_args arg;
> >> +
> >> +  return of_parse_phandle_with_args(np, "mboxes", "#mbox-cells", 0, &arg);
> >> +}
> >> +
> >> +static int scmi_mbox_free_channel(struct scmi_info *info)  
> > Some of the naming in here could do with being adjusted to be obviously
> > 'balanced'.  The moment I see a free I expect a matched alloc but in this
> > case the alloc is done in scmi_mbox_chan_setup which at very least
> > should be scmi_mbox_setup_channel and should really imply that it is
> > doing allocation as well.
> >   
> 
> That's inline with mailbox APIs.

oh goody.  Fair enough if ugly
> 
...
> OK

Re: [PATCH] dump_stack: convert generic dump_stack into a weak symbol

[Petr Mladek]

On Mon 2018-03-05 14:37:42, Sergey Senozhatsky wrote:
> We want to move dump_stack related functions out of printk C
> code and consolidate them in lib/dump_stack file. The reason why
> dump_stack_print_info()/etc ended up in printk.c was a "generic"
> (dummy) lib dump_stack() function, which archs can override.
> For example, blackfin and nds32, define their own EXPORT_SYMBOL
> dump_stack() functions.
> 
> In case of blackfin that arch-specific dump_stack() symbol invokes
> a global dump_stack_print_info() function. So we can't easily move
> dump_stack_print_info() to lib/dump_stack, because this way we will
> link with lib/dump_stack.o file, which will bring in a generic
> dump_stack() symbol with it, causing a multiple definitions error:
>   - one dump_stack() from arch/blackfin/dumpstack
>   - the other one from lib/dump_stack
> 
> Convert generic dump_stack() into a weak symbol. So we will be
> able link with lib/dump_stack and at the same time archs will
> be able to override dump_stack(). It also opens up a way for us
> to move dump_stack_set_arch_desc(), dump_stack_print_info() and
> show_regs_print_info() to lib/dump_stack.
> 
> Signed-off-by: Sergey Senozhatsky 
> ---
>  arch/blackfin/kernel/dumpstack.c | 1 -
>  arch/nds32/kernel/traps.c| 2 --
>  lib/dump_stack.c | 4 ++--
>  3 files changed, 2 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/blackfin/kernel/dumpstack.c 
> b/arch/blackfin/kernel/dumpstack.c
> index 3c992c1f8ef2..61af017130cd 100644
> --- a/arch/blackfin/kernel/dumpstack.c
> +++ b/arch/blackfin/kernel/dumpstack.c
> @@ -174,4 +174,3 @@ void dump_stack(void)
>   show_stack(current, &stack);
>   trace_buffer_restore(tflags);
>  }
> -EXPORT_SYMBOL(dump_stack);

I was afraid that blackfin modules would not longer be able
to use arch-specific dump_stack symbol. But it seems that only
the symbol name is important. Alos the list of symbols look
promissing:

before:

$> objdump -x vmlinux | less | grep dump_stack
00248530 l O __ksymtab  0008 ___ksymtab_dump_stack
002500d4 l O __ksymtab_strings  000c ___kstrtab_dump_stack
00272bb6 l O .bss   0080 _dump_stack_arch_desc_str
51a8 g F .text  0042 _dump_stack
002ab05c g F .init.text 002a _dump_stack_set_arch_desc
0003051c g F .text  00a4 _dump_stack_print_info


after:

$> objdump -x vmlinux.patched | less | grep dump_stack
 ldf *ABS*   lib/dump_stack.c
0027c3e8 l O .bss   0080 _dump_stack_arch_desc_str
00248580 l O __ksymtab  0008 ___ksymtab_dump_stack
002653d4 l O __ksymtab_strings  000c ___kstrtab_dump_stack
51a8 g F .text  0042 _dump_stack
002b69dc g F .init.text 002a _dump_stack_set_arch_desc
001c2a90 g F .text  00a4 _dump_stack_print_info

I hope that I did not miss anything. I could not try this at
runtime. I could just cross-compile.

Anyway, from my side:

Reviewed-by: Petr Mladek 

I'll wait a bit and push it into printk.git for-4.17.


Greentime Hu, you tested this on nds32. Could I use your Tested-by,
please?

Best Regards,
Petr

Re: [PATCH v6] staging: typec: handle vendor defined part and modify drp toggling flow

[Guenter Roeck]

On 03/04/2018 08:16 PM, ShuFan Lee wrote:

From: ShuFan Lee 

Handle vendor defined behavior in tcpci_init, tcpci_set_vconn, 
tcpci_start_drp_toggling
and export tcpci_irq. More operations can be extended in tcpci_data if needed.
According to TCPCI specification, 4.4.5.2 ROLE_CONTROL,
TCPC shall not start DRP toggling until subsequently the TCPM
writes to the COMMAND register to start DRP toggling.
DRP toggling flow is chagned as following:


s/chagned/changed/


   - Write DRP = 1, Rp level and RC.CCx to Rd/Rd or Rp/Rp
   - Set LOOK4CONNECTION command

Signed-off-by: ShuFan Lee 
---
  drivers/staging/typec/tcpci.c | 134 ++
  drivers/staging/typec/tcpci.h |  15 +
  2 files changed, 123 insertions(+), 26 deletions(-)

  patch changelogs between v1 & v2
  - Remove unnecessary i2c_client in the structure of tcpci
  - Rename structure of tcpci_vendor_data to tcpci_data
  - Not exporting tcpci read/write wrappers but register i2c regmap in glue 
driver
  - Add set_vconn ops in tcpci_data
(It is necessary for RT1711H to enable/disable idle mode before 
disabling/enabling vconn)
  - Export tcpci_irq so that vendor can call it in their own IRQ handler

  patch changelogs between v2 & v3
  - Change the return type of tcpci_irq from int to irqreturn_t

  patch changelogs between v3 & v4
  - Directly return regmap_write at the end of drp_toggling function
  - Because tcpci_irq is called in _tcpci_irq, move _tcpci_irq to the place 
after tcpci_irq

  patch changelogs between v4 & v5
  - Add a space between my first & last name, from ShuFanLee to ShuFan Lee.

  patch changelogs between v5 & v6
  - Add start_drp_toggling in tcpci_data and call it at the beginning of 
tcpci_start_drp_toggling
  - Modify the flow of tcpci_start_drp_toggling as following
 - Set Rp level, RC.CCx to Rd/Rd or Rp/Rp and DRP = 1
 - Set LOOK4CONNECTION command

diff --git a/drivers/staging/typec/tcpci.c b/drivers/staging/typec/tcpci.c
index 9bd4412..9e600f7 100644
--- a/drivers/staging/typec/tcpci.c
+++ b/drivers/staging/typec/tcpci.c
@@ -21,7 +21,6 @@
  
  struct tcpci {

struct device *dev;
-   struct i2c_client *client;
  
  	struct tcpm_port *port;
  
@@ -30,6 +29,12 @@ struct tcpci {

bool controls_vbus;
  
  	struct tcpc_dev tcpc;

+   struct tcpci_data *data;
+};
+
+struct tcpci_chip {
+   struct tcpci *tcpci;
+   struct tcpci_data data;
  };
  
  static inline struct tcpci *tcpc_to_tcpci(struct tcpc_dev *tcpc)

@@ -37,8 +42,7 @@ static inline struct tcpci *tcpc_to_tcpci(struct tcpc_dev 
*tcpc)
return container_of(tcpc, struct tcpci, tcpc);
  }
  
-static int tcpci_read16(struct tcpci *tcpci, unsigned int reg,

-   u16 *val)
+static int tcpci_read16(struct tcpci *tcpci, unsigned int reg, u16 *val)
  {
return regmap_raw_read(tcpci->regmap, reg, val, sizeof(u16));
  }
@@ -98,9 +102,19 @@ static int tcpci_set_cc(struct tcpc_dev *tcpc, enum 
typec_cc_status cc)
  static int tcpci_start_drp_toggling(struct tcpc_dev *tcpc,
enum typec_cc_status cc)
  {
+   int ret;
struct tcpci *tcpci = tcpc_to_tcpci(tcpc);
unsigned int reg = TCPC_ROLE_CTRL_DRP;
  
+	if (tcpci->data) {

+   if (tcpci->data->start_drp_toggling) {


From the code flow it is guaranteed that ->data is set. It should therefore
be unnecessary to check for it (we don't check if ->reg is set either).


+   ret = tcpci->data->start_drp_toggling(tcpci,
+ tcpci->data, cc);
+   if (ret < 0)
+   return ret;
+   }
+   }
+
switch (cc) {
default:
case TYPEC_CC_RP_DEF:
@@ -117,7 +131,17 @@ static int tcpci_start_drp_toggling(struct tcpc_dev *tcpc,
break;
}
  
-	return regmap_write(tcpci->regmap, TCPC_ROLE_CTRL, reg);

+   if (cc == TYPEC_CC_RD)
+   reg |= (TCPC_ROLE_CTRL_CC_RD << TCPC_ROLE_CTRL_CC1_SHIFT) |
+  (TCPC_ROLE_CTRL_CC_RD << TCPC_ROLE_CTRL_CC2_SHIFT);
+   else
+   reg |= (TCPC_ROLE_CTRL_CC_RP << TCPC_ROLE_CTRL_CC1_SHIFT) |
+  (TCPC_ROLE_CTRL_CC_RP << TCPC_ROLE_CTRL_CC2_SHIFT);
+   ret = regmap_write(tcpci->regmap, TCPC_ROLE_CTRL, reg);
+   if (ret < 0)
+   return ret;
+   return regmap_write(tcpci->regmap, TCPC_COMMAND,
+   TCPC_CMD_LOOK4CONNECTION);
  }
  
  static enum typec_cc_status tcpci_to_typec_cc(unsigned int cc, bool sink)

@@ -178,6 +202,16 @@ static int tcpci_set_vconn(struct tcpc_dev *tcpc, bool 
enable)
struct tcpci *tcpci = tcpc_to_tcpci(tcpc);
int ret;
  
+	/* Handle vendor set vconn */

+   if (tcpci->data) {
+   if (tcpci->data->set_vconn) {
+   ret = tcpci->data->set_vconn(tcpci, tcpci->data,
+

[PATCH v3 2/8] scsi: hisi_sas: support the property of signal attenuation for v2 hw

[John Garry]

From: Xiaofei Tan 

The register SAS_PHY_CTRL is configured according to signal quality.
The signal quality is calculated by signal attenuation of hardware
physical link. It may be different for different PCB layout.

So, in order to give better support to new board, this patch add
support to reading the devicetree property, "hisilicon,signal-attenuation".
Of course, we still keep an default value in driver to adapt old
board.

Signed-off-by: Xiaofei Tan 
Signed-off-by: John Garry 
---
 drivers/scsi/hisi_sas/hisi_sas_v2_hw.c | 39 +-
 1 file changed, 38 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c 
b/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
index 4ccb61e..42b3fd6 100644
--- a/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
+++ b/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
@@ -406,6 +406,17 @@ struct hisi_sas_err_record_v2 {
__le32 dma_rx_err_type;
 };
 
+struct signal_attenuation_s {
+   u32 de_emphasis;
+   u32 preshoot;
+   u32 boost;
+};
+
+struct sig_atten_lu_s {
+   const struct signal_attenuation_s *att;
+   u32 sas_phy_ctrl;
+};
+
 static const struct hisi_sas_hw_error one_bit_ecc_errors[] = {
{
.irq_msk = BIT(SAS_ECC_INTR_DQE_ECC_1B_OFF),
@@ -1130,9 +1141,16 @@ static void phys_try_accept_stp_links_v2_hw(struct 
hisi_hba *hisi_hba)
}
 }
 
+static const struct signal_attenuation_s x6000 = {9200, 0, 10476};
+static const struct sig_atten_lu_s sig_atten_lu[] = {
+   { &x6000, 0x3016a68 },
+};
+
 static void init_reg_v2_hw(struct hisi_hba *hisi_hba)
 {
struct device *dev = hisi_hba->dev;
+   u32 sas_phy_ctrl = 0x30b9908;
+   u32 signal[3];
int i;
 
/* Global registers init */
@@ -1176,9 +1194,28 @@ static void init_reg_v2_hw(struct hisi_hba *hisi_hba)
hisi_sas_write32(hisi_hba, AXI_AHB_CLK_CFG, 1);
hisi_sas_write32(hisi_hba, HYPER_STREAM_ID_EN_CFG, 1);
 
+   /* Get sas_phy_ctrl value to deal with TX FFE issue. */
+   if (!device_property_read_u32_array(dev, "hisilicon,signal-attenuation",
+   signal, ARRAY_SIZE(signal))) {
+   for (i = 0; i < ARRAY_SIZE(sig_atten_lu); i++) {
+   const struct sig_atten_lu_s *lookup = &sig_atten_lu[i];
+   const struct signal_attenuation_s *att = lookup->att;
+
+   if ((signal[0] == att->de_emphasis) &&
+   (signal[1] == att->preshoot) &&
+   (signal[2] == att->boost)) {
+   sas_phy_ctrl = lookup->sas_phy_ctrl;
+   break;
+   }
+   }
+
+   if (i == ARRAY_SIZE(sig_atten_lu))
+   dev_warn(dev, "unknown signal attenuation values, using 
default PHY ctrl config\n");
+   }
+
for (i = 0; i < hisi_hba->n_phy; i++) {
hisi_sas_phy_write32(hisi_hba, i, PROG_PHY_LINK_RATE, 0x855);
-   hisi_sas_phy_write32(hisi_hba, i, SAS_PHY_CTRL, 0x30b9908);
+   hisi_sas_phy_write32(hisi_hba, i, SAS_PHY_CTRL, sas_phy_ctrl);
hisi_sas_phy_write32(hisi_hba, i, SL_TOUT_CFG, 0x7d7d7d7d);
hisi_sas_phy_write32(hisi_hba, i, SL_CONTROL, 0x0);
hisi_sas_phy_write32(hisi_hba, i, TXID_AUTO, 0x2);
-- 
1.9.1

Re: [PATCH 02/14] perf trace: Apply new perf_mmap__read_event() interface

[Liang, Kan]

On 3/5/2018 8:46 AM, Arnaldo Carvalho de Melo wrote:

Em Mon, Mar 05, 2018 at 10:03:39AM -0300, Arnaldo Carvalho de Melo escreveu:

Em Sat, Mar 03, 2018 at 12:30:22AM +0100, Jiri Olsa escreveu:

On Thu, Mar 01, 2018 at 06:08:59PM -0500, kan.li...@linux.intel.com wrote:

From: Kan Liang 
The perf trace still use the legacy interface.
+++ b/tools/perf/builtin-trace.c
@@ -2472,8 +2472,14 @@ static int trace__run(struct trace *trace, int argc, 
const char **argv)
  
  	for (i = 0; i < evlist->nr_mmaps; i++) {

union perf_event *event;
+   struct perf_mmap *md;
+   u64 end, start;
  
-		while ((event = perf_evlist__mmap_read(evlist, i)) != NULL) {

+   md = &evlist->mmap[i];
+   if (perf_mmap__read_init(md, 0, &start, &end) < 0)
+   continue;
+
+   while ((event = perf_mmap__read_event(md, 0, &start, end)) != 
NULL) {
struct perf_sample sample;
  
  			++trace->nr_events;

@@ -2486,7 +2492,7 @@ static int trace__run(struct trace *trace, int argc, 
const char **argv)
  
  			trace__handle_event(trace, event, &sample);

  next_event:
-   perf_evlist__mmap_consume(evlist, i);
+   perf_mmap__consume(md, 0);


could you call this with 'false' instead of 0, it's 'bool overwrite'
applies also to the rest of the patchset


I'm doing this, the argument is 'bool', so the value should be false or
true, even '0' being way shorter...


While doing that I wonder why is that we can't do it without those
explicit start/end variables in all the call sites and passing
overwrite, start and end as parameters...

Can't we just add 'overwrite, 'start' and 'end' to struct perf_mmap,
then have perf_mmap__read_init() with just 'md' and 'overwrite' as
parameters, initialize md->{start,end} and set md->overwrite to the
'overwrite' parameter in 'perf_mmap__read_init()' and then use just
md as parameters for both perf_mmap__read_event() and
perf_mmap__consume()?



I don't see any reason we cannot do this.
I will do some test. If it works well, I will submit the follow-up patch 
to clean up the interface.


Thanks,
Kan


What am I missing to have this much simpler without all this
boilerplate?

Anyway, finishing the s/0/false/g, will leave this for later, but please
comment on it.

- Arnaldo

[PATCH v3 1/8] dt-bindings: scsi: hisi_sas: add an property of signal attenuation

[John Garry]

From: Xiaofei Tan 

For some new boards with hip07 chipset we are required to
set PHY config registers differently. The hw property which
determines how to set these registers is in the PHY signal
attenuation readings.

This patch add an devicetree property, "hisilicon,signal-attenuation",
which is used to describe the signal attenuation of an board.

Cc: Rob Herring 
Cc: Mark Rutland 
Signed-off-by: Xiaofei Tan 
Signed-off-by: John Garry 
---
 Documentation/devicetree/bindings/scsi/hisilicon-sas.txt | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/devicetree/bindings/scsi/hisilicon-sas.txt 
b/Documentation/devicetree/bindings/scsi/hisilicon-sas.txt
index df3bef7..8c6659e 100644
--- a/Documentation/devicetree/bindings/scsi/hisilicon-sas.txt
+++ b/Documentation/devicetree/bindings/scsi/hisilicon-sas.txt
@@ -53,6 +53,13 @@ Main node required properties:
 Optional main node properties:
  - hip06-sas-v2-quirk-amt : when set, indicates that the v2 controller has the
"am-max-transmissions" limitation.
+ - hisilicon,signal-attenuation : array of 3 32-bit values, containing 
de-emphasis,
+   preshoot, and boost attenuation readings for the board. They
+   are used to describe the signal attenuation of the board. These
+   values' range is 7600 to 12400, and used to represent -24dB to
+   24dB.
+   The formula is "y = (x-1)/1". For example, 10478
+   means 4.78dB.
 
 Example:
sas0: sas@c100 {
-- 
1.9.1

Re: [PATCH 3/3] fixdep: do not ignore kconfig.h

[Masahiro Yamada]

2018-03-01 4:17 GMT+09:00 Rasmus Villemoes :
> kconfig.h was excluded from consideration by fixdep by
> 6a5be57f0f00 (fixdep: fix extraneous dependencies) to avoid some false
> positive hits
>
> (1) include/config/.h
> (2) include/config/h.h
> (3) include/config/foo.h
>
> (1) occurred because kconfig.h contains the string CONFIG_ in a
> comment. However, since dee81e988674 (fixdep: faster CONFIG_ search), we
> have a check that the part after CONFIG_ is non-empty, so this does not
> happen anymore (and CONFIG_ appears by itself elsewhere, so that check
> is worthwhile).
>
> (2) comes from the include guard, __LINUX_KCONFIG_H. But with the
> previous patch, we no longer match that either.
>
> That leaves (3), which amounts to one [1] false dependency (aka stat() call
> done by make), which I think we can live with:
>
> We've already had one case [2] where the lack of include/linux/kconfig.h in
> the .o.cmd file caused a missing rebuild, and while I originally thought
> we should just put kconfig.h in the dependency list without parsing it
> for the CONFIG_ pattern, we actually do have some real CONFIG_ symbols
> mentioned in it, and one can imagine some translation unit that just
> does '#ifdef __BIG_ENDIAN' but doesn't through some other header
> actually depend on CONFIG_CPU_BIG_ENDIAN - so changing the target
> endianness could end up rebuilding the world, minus that small
> TU. Quoting Linus,
>
>   ... when missing dependencies cause a missed re-compile, the resulting
>   bugs can be _really_ subtle.
>
> [1] well, two, we now also have CONFIG_BOOGER/booger.h - we could change
> that to FOO if we care
>
> [2] https://lkml.org/lkml/2018/2/22/838
>
> Cc: Linus Torvalds 
> Signed-off-by: Rasmus Villemoes 
> ---
>  scripts/basic/fixdep.c | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/scripts/basic/fixdep.c b/scripts/basic/fixdep.c
> index 1b21870d6e7f..449b68c4c90c 100644
> --- a/scripts/basic/fixdep.c
> +++ b/scripts/basic/fixdep.c
> @@ -283,7 +283,6 @@ static int is_ignored_file(const char *s, int len)
>  {
> return str_ends_with(s, len, "include/generated/autoconf.h") ||
>str_ends_with(s, len, "include/generated/autoksyms.h") ||
> -  str_ends_with(s, len, "include/linux/kconfig.h") ||
>str_ends_with(s, len, ".ver");
>  }
>
> --
> 2.15.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


The series, applied to linux-kbuild/fixes.  Thanks!


-- 
Best Regards
Masahiro Yamada

[PATCH v3 5/8] scsi: hisi_sas: increase timer expire of internal abort task

[John Garry]

From: Xiaofei Tan 

The current 110ms expiry time is not long enough for the internal
abort task.

The reason is that the internal abort task could be blocked in HW
if the HW is retrying to set up link. The internal abort task will
be executed only when the retry process finished.

The maximum time is 5s for the retry of setting up link. So, the timer
expire should be more than 5s. This patch increases it from 110ms to 6s.

Signed-off-by: Xiaofei Tan 
Signed-off-by: John Garry 
---
 drivers/scsi/hisi_sas/hisi_sas_main.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/hisi_sas/hisi_sas_main.c 
b/drivers/scsi/hisi_sas/hisi_sas_main.c
index 9d16372..9ff8790 100644
--- a/drivers/scsi/hisi_sas/hisi_sas_main.c
+++ b/drivers/scsi/hisi_sas/hisi_sas_main.c
@@ -871,6 +871,7 @@ static void hisi_sas_tmf_timedout(struct timer_list *t)
 
 #define TASK_TIMEOUT 20
 #define TASK_RETRY 3
+#define INTERNAL_ABORT_TIMEOUT 6
 static int hisi_sas_exec_internal_tmf_task(struct domain_device *device,
   void *parameter, u32 para_len,
   struct hisi_sas_tmf_task *tmf)
@@ -1574,7 +1575,7 @@ static int hisi_sas_query_task(struct sas_task *task)
task->task_proto = device->tproto;
task->task_done = hisi_sas_task_done;
task->slow_task->timer.function = hisi_sas_tmf_timedout;
-   task->slow_task->timer.expires = jiffies + msecs_to_jiffies(110);
+   task->slow_task->timer.expires = jiffies + INTERNAL_ABORT_TIMEOUT*HZ;
add_timer(&task->slow_task->timer);
 
res = hisi_sas_internal_abort_task_exec(hisi_hba, sas_dev->device_id,
-- 
1.9.1

Re: [PATCH 07/34] x86/entry/32: Restore segments before int registers

[Brian Gerst]

On Mon, Mar 5, 2018 at 8:12 AM, Joerg Roedel  wrote:
> On Mon, Mar 05, 2018 at 04:17:45AM -0800, Linus Torvalds wrote:
>> Restoring the segments can cause exceptions that need to be
>> handled. With PTI enabled, we still need to be on kernel cr3
>> when the exception happens. For the cr3-switch we need
>> at least one integer scratch register, so we can't switch
>> with the user integer registers already loaded.
>>
>>
>> This fundamentally seems wrong.
>
> Okay, right, with v3 it is wrong, in v2 I still thought I could get away
> without remembering the entry-cr3, but didn't think about the #DB case
> then.
>
> In v3 I added code which remembers the entry-cr3 and handles the
> entry-from-kernel-mode-with-user-cr3 case for all exceptions including
> #DB.
>
>> The things is, we *know* that we will restore two segment registers with the
>> user cr3 already loaded: CS and SS get restored with the final iret.
>
> Yeah, I know, but the iret-exception path is fine because it will
> deliver a SIGILL and doesn't return to the faulting iret.
>
> Anyway, I will remove these restore-reorderings, they are not needed
> anymore.
>
>> So has this been tested with
>>
>>  - single-stepping through sysenter
>>
>>This takes a DB fault in the first kernel instruction. We're in kernel 
>> mode,
>> but with user cr3.
>>
>>  - ptracing and setting CS/SS to something bad
>>
>>That should test the "exception on iret" case - again in kernel mode, but
>> with user cr3 restored for the return.
>
> The iret-exception case is tested by the ldt_gdt selftest (the
> do_multicpu_tests subtest). But I didn't actually tested single-stepping
> through sysenter yet. I just re-ran the same tests I did with v2 on this
> patch-set.
>
> Regards,
>
> Joerg
>

For the IRET fault case you will still need to catch it in the
exception code.  See the 64-bit code (.Lerror_bad_iret) for example.
For 32-bit, you could just expand that check to cover the whole exit
prologue after the CR3 switch, including the data segment loads.

I do wonder though, how expensive is a CR3 read?  The SDM implies that
only writes are serializing.  It may be simpler to just
unconditionally check it.

--
Brian Gerst

[PATCH v3 7/8] scsi: hisi_sas: fix return value of hisi_sas_task_prep()

[John Garry]

From: Xiaofei Tan 

It is an implicit regulation that error code that function returned
should be negative. But hisi_sas_task_prep() doesn't follow this.
This may cause problems in the upper layer code.

For example, in sas_expander.c of libsas, smp_execute_task_sg() may
return the number of bytes of underrun. It will be conflicted with
the scenaio lldd_execute_task() return an positive error code.

This patch change the return value from SAS_PHY_DOWN to -ECOMM in
hisi_sas_task_prep().

Signed-off-by: Xiaofei Tan 
Signed-off-by: John Garry 
---
 drivers/scsi/hisi_sas/hisi_sas_main.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/scsi/hisi_sas/hisi_sas_main.c 
b/drivers/scsi/hisi_sas/hisi_sas_main.c
index 88ad8d4..dff9723 100644
--- a/drivers/scsi/hisi_sas/hisi_sas_main.c
+++ b/drivers/scsi/hisi_sas/hisi_sas_main.c
@@ -316,7 +316,7 @@ static int hisi_sas_task_prep(struct sas_task *task, struct 
hisi_sas_dq
 */
if (device->dev_type != SAS_SATA_DEV)
task->task_done(task);
-   return SAS_PHY_DOWN;
+   return -ECOMM;
}
 
if (DEV_IS_GONE(sas_dev)) {
@@ -327,7 +327,7 @@ static int hisi_sas_task_prep(struct sas_task *task, struct 
hisi_sas_dq
dev_info(dev, "task prep: device %016llx not ready\n",
 SAS_ADDR(device->sas_addr));
 
-   return SAS_PHY_DOWN;
+   return -ECOMM;
}
 
port = to_hisi_sas_port(sas_port);
@@ -337,7 +337,7 @@ static int hisi_sas_task_prep(struct sas_task *task, struct 
hisi_sas_dq
 "SATA/STP" : "SAS",
 device->port->id);
 
-   return SAS_PHY_DOWN;
+   return -ECOMM;
}
 
if (!sas_protocol_ata(task->task_proto)) {
-- 
1.9.1

[PATCH v3 8/8] scsi: hisi_sas: Code cleanup and minor bug fixes

[John Garry]

From: Xiang Chen 

The patch does some code cleanup and fixes some small bugs:
- Correct return status of phy_up_v3_hw()
- Add static for function phy_get_max_linkrate_v3_hw()
- Change exception return status when no reset method
- Change magic value to ts->stat in slot_complete_vx_hw()
- Remove unnecessary check for dev_is_sata()
- Fix some issues of alignment and indents (Authored by
  Xiaofei Tan in another patch, but added here to be
  practical)

Signed-off-by: Xiaofei Tan 
Signed-off-by: Xiang Chen 
Signed-off-by: John Garry 
---
 drivers/scsi/hisi_sas/hisi_sas_main.c  | 14 +++---
 drivers/scsi/hisi_sas/hisi_sas_v1_hw.c |  4 +++-
 drivers/scsi/hisi_sas/hisi_sas_v2_hw.c | 10 ++
 drivers/scsi/hisi_sas/hisi_sas_v3_hw.c | 16 +---
 4 files changed, 25 insertions(+), 19 deletions(-)

diff --git a/drivers/scsi/hisi_sas/hisi_sas_main.c 
b/drivers/scsi/hisi_sas/hisi_sas_main.c
index dff9723..49c1fa6 100644
--- a/drivers/scsi/hisi_sas/hisi_sas_main.c
+++ b/drivers/scsi/hisi_sas/hisi_sas_main.c
@@ -33,7 +33,7 @@ u8 hisi_sas_get_ata_protocol(struct host_to_dev_fis *fis, int 
direction)
case ATA_CMD_FPDMA_RECV:
case ATA_CMD_FPDMA_SEND:
case ATA_CMD_NCQ_NON_DATA:
-   return HISI_SAS_SATA_PROTOCOL_FPDMA;
+   return HISI_SAS_SATA_PROTOCOL_FPDMA;
 
case ATA_CMD_DOWNLOAD_MICRO:
case ATA_CMD_ID_ATA:
@@ -45,7 +45,7 @@ u8 hisi_sas_get_ata_protocol(struct host_to_dev_fis *fis, int 
direction)
case ATA_CMD_WRITE_LOG_EXT:
case ATA_CMD_PIO_WRITE:
case ATA_CMD_PIO_WRITE_EXT:
-   return HISI_SAS_SATA_PROTOCOL_PIO;
+   return HISI_SAS_SATA_PROTOCOL_PIO;
 
case ATA_CMD_DSM:
case ATA_CMD_DOWNLOAD_MICRO_DMA:
@@ -64,7 +64,7 @@ u8 hisi_sas_get_ata_protocol(struct host_to_dev_fis *fis, int 
direction)
case ATA_CMD_WRITE_LOG_DMA_EXT:
case ATA_CMD_WRITE_STREAM_DMA_EXT:
case ATA_CMD_ZAC_MGMT_IN:
-   return HISI_SAS_SATA_PROTOCOL_DMA;
+   return HISI_SAS_SATA_PROTOCOL_DMA;
 
case ATA_CMD_CHK_POWER:
case ATA_CMD_DEV_RESET:
@@ -77,21 +77,21 @@ u8 hisi_sas_get_ata_protocol(struct host_to_dev_fis *fis, 
int direction)
case ATA_CMD_STANDBY:
case ATA_CMD_STANDBYNOW1:
case ATA_CMD_ZAC_MGMT_OUT:
-   return HISI_SAS_SATA_PROTOCOL_NONDATA;
+   return HISI_SAS_SATA_PROTOCOL_NONDATA;
default:
{
if (fis->command == ATA_CMD_SET_MAX) {
switch (fis->features) {
case ATA_SET_MAX_PASSWD:
case ATA_SET_MAX_LOCK:
-   return HISI_SAS_SATA_PROTOCOL_PIO;
+   return HISI_SAS_SATA_PROTOCOL_PIO;
 
case ATA_SET_MAX_PASSWD_DMA:
case ATA_SET_MAX_UNLOCK_DMA:
-   return HISI_SAS_SATA_PROTOCOL_DMA;
+   return HISI_SAS_SATA_PROTOCOL_DMA;
 
default:
-   return HISI_SAS_SATA_PROTOCOL_NONDATA;
+   return HISI_SAS_SATA_PROTOCOL_NONDATA;
}
}
if (direction == DMA_NONE)
diff --git a/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c 
b/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c
index 8dd0e6a6..520ba69 100644
--- a/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c
+++ b/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c
@@ -651,8 +651,10 @@ static int reset_hw_v1_hw(struct hisi_hba *hisi_hba)
dev_err(dev, "De-reset failed\n");
return -EIO;
}
-   } else
+   } else {
dev_warn(dev, "no reset method\n");
+   return -EIO;
+   }
 
return 0;
 }
diff --git a/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c 
b/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
index bd1a48a..69c4dd1 100644
--- a/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
+++ b/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
@@ -1095,8 +1095,10 @@ static int reset_hw_v2_hw(struct hisi_hba *hisi_hba)
dev_err(dev, "SAS de-reset fail.\n");
return -EIO;
}
-   } else
-   dev_warn(dev, "no reset method\n");
+   } else {
+   dev_err(dev, "no reset method\n");
+   return -EIO;
+   }
 
return 0;
 }
@@ -2408,7 +2410,7 @@ static void slot_err_v2_hw(struct hisi_hba *hisi_hba,
spin_lock_irqsave(&hisi_hba->lock, flags);
hisi_sas_slot_task_free(hisi_hba, task, slot);
spin_unlock_irqrestore(&hisi_hba->lock, flags);
-   return -1;
+   return ts->stat;
}
 
if (unlikely(!sas_dev)) {
@@ -2667,7 +2669,7 @@ static int prep_abort_v2_hw(struct hisi_hba *hisi_hba,
/* dw0 */
hdr->dw0 = cpu_to_le32((5 << CMD_HDR_CMD_OFF) | /*abort*/
   (port->id << CMD_HDR_PORT_OF

[PATCH v3 6/8] scsi: hisi_sas: remove unused variable hisi_sas_devices.running_req

[John Garry]

From: Xiang Chen 

The structure element hisi_sas_devices.running_req to count how
many commands are active is in effect only ever written in the
code, so remove it.

Signed-off-by: Xiang Chen 
Signed-off-by: John Garry 
---
 drivers/scsi/hisi_sas/hisi_sas.h   | 1 -
 drivers/scsi/hisi_sas/hisi_sas_main.c  | 9 -
 drivers/scsi/hisi_sas/hisi_sas_v1_hw.c | 3 ---
 3 files changed, 13 deletions(-)

diff --git a/drivers/scsi/hisi_sas/hisi_sas.h b/drivers/scsi/hisi_sas/hisi_sas.h
index e7fd287..d1153e8 100644
--- a/drivers/scsi/hisi_sas/hisi_sas.h
+++ b/drivers/scsi/hisi_sas/hisi_sas.h
@@ -175,7 +175,6 @@ struct hisi_sas_device {
struct hisi_sas_dq  *dq;
struct list_headlist;
u64 attached_phy;
-   atomic64_t running_req;
enum sas_device_typedev_type;
int device_id;
int sata_idx;
diff --git a/drivers/scsi/hisi_sas/hisi_sas_main.c 
b/drivers/scsi/hisi_sas/hisi_sas_main.c
index 9ff8790..88ad8d4 100644
--- a/drivers/scsi/hisi_sas/hisi_sas_main.c
+++ b/drivers/scsi/hisi_sas/hisi_sas_main.c
@@ -200,8 +200,6 @@ void hisi_sas_slot_task_free(struct hisi_hba *hisi_hba, 
struct sas_task *task,
 
if (task) {
struct device *dev = hisi_hba->dev;
-   struct domain_device *device = task->dev;
-   struct hisi_sas_device *sas_dev = device->lldd_dev;
 
if (!task->lldd_task)
return;
@@ -213,9 +211,6 @@ void hisi_sas_slot_task_free(struct hisi_hba *hisi_hba, 
struct sas_task *task,
dma_unmap_sg(dev, task->scatter,
 task->num_scatter,
 task->data_dir);
-
-   if (sas_dev)
-   atomic64_dec(&sas_dev->running_req);
}
 
if (slot->buf)
@@ -431,8 +426,6 @@ static int hisi_sas_task_prep(struct sas_task *task, struct 
hisi_sas_dq
spin_unlock_irqrestore(&task->task_state_lock, flags);
 
dq->slot_prep = slot;
-
-   atomic64_inc(&sas_dev->running_req);
++(*pass);
 
return 0;
@@ -1517,8 +1510,6 @@ static int hisi_sas_query_task(struct sas_task *task)
 
dq->slot_prep = slot;
 
-   atomic64_inc(&sas_dev->running_req);
-
/* send abort command to the chip */
hisi_hba->hw->start_delivery(dq);
spin_unlock_irqrestore(&dq->lock, flags_dq);
diff --git a/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c 
b/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c
index 2eb8980..8dd0e6a6 100644
--- a/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c
+++ b/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c
@@ -1407,9 +1407,6 @@ static int slot_complete_v1_hw(struct hisi_hba *hisi_hba,
}
 
 out:
-   if (sas_dev)
-   atomic64_dec(&sas_dev->running_req);
-
hisi_sas_slot_task_free(hisi_hba, task, slot);
sts = ts->stat;
 
-- 
1.9.1

[PATCH v3 4/8] scsi: hisi_sas: fix the issue of setting linkrate register

[John Garry]

From: Xiaofei Tan 

It is not right to set the register PROG_PHY_LINK_RATE while PHY
is still enabled. So if we want to change PHY linkrate, we need to
disable PHY before setting the register PROG_PHY_LINK_RATE, and then
start-up PHY. This patch is to fix this issue.

Signed-off-by: Xiaofei Tan 
Signed-off-by: John Garry 
---
 drivers/scsi/hisi_sas/hisi_sas_v1_hw.c | 5 +++--
 drivers/scsi/hisi_sas/hisi_sas_v2_hw.c | 5 +++--
 drivers/scsi/hisi_sas/hisi_sas_v3_hw.c | 5 +++--
 3 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c 
b/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c
index 38bbda9..2eb8980 100644
--- a/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c
+++ b/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c
@@ -881,10 +881,11 @@ static void phy_set_linkrate_v1_hw(struct hisi_hba 
*hisi_hba, int phy_no,
prog_phy_link_rate &= ~0xff;
prog_phy_link_rate |= rate_mask;
 
+   disable_phy_v1_hw(hisi_hba, phy_no);
+   msleep(100);
hisi_sas_phy_write32(hisi_hba, phy_no, PROG_PHY_LINK_RATE,
prog_phy_link_rate);
-
-   phy_hard_reset_v1_hw(hisi_hba, phy_no);
+   start_phy_v1_hw(hisi_hba, phy_no);
 }
 
 static int get_wideport_bitmap_v1_hw(struct hisi_hba *hisi_hba, int port_id)
diff --git a/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c 
b/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
index 67be346..bd1a48a 100644
--- a/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
+++ b/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
@@ -1611,10 +1611,11 @@ static void phy_set_linkrate_v2_hw(struct hisi_hba 
*hisi_hba, int phy_no,
prog_phy_link_rate &= ~0xff;
prog_phy_link_rate |= rate_mask;
 
+   disable_phy_v2_hw(hisi_hba, phy_no);
+   msleep(100);
hisi_sas_phy_write32(hisi_hba, phy_no, PROG_PHY_LINK_RATE,
prog_phy_link_rate);
-
-   phy_hard_reset_v2_hw(hisi_hba, phy_no);
+   start_phy_v2_hw(hisi_hba, phy_no);
 }
 
 static int get_wideport_bitmap_v2_hw(struct hisi_hba *hisi_hba, int port_id)
diff --git a/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c 
b/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c
index 1ee95ab..8da9de7 100644
--- a/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c
+++ b/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c
@@ -1862,10 +1862,11 @@ static void phy_set_linkrate_v3_hw(struct hisi_hba 
*hisi_hba, int phy_no,
prog_phy_link_rate &= ~0xff;
prog_phy_link_rate |= rate_mask;
 
+   disable_phy_v3_hw(hisi_hba, phy_no);
+   msleep(100);
hisi_sas_phy_write32(hisi_hba, phy_no, PROG_PHY_LINK_RATE,
prog_phy_link_rate);
-
-   phy_hard_reset_v3_hw(hisi_hba, phy_no);
+   start_phy_v3_hw(hisi_hba, phy_no);
 }
 
 static void interrupt_disable_v3_hw(struct hisi_hba *hisi_hba)
-- 
1.9.1

Re: [PATCH] vsprintf: Make "null" pointer dereference more robust

[Petr Mladek]

On Fri 2018-03-02 16:17:34, Andy Shevchenko wrote:
> On Fri, 2018-03-02 at 13:53 +0100, Petr Mladek wrote:
> > %p has many modifiers where the pointer is dereferenced. An invalid
> > pointer might cause kernel to crash silently.
> > 
> > Note that printk() formats the string under logbuf_lock. Any recursive
> > printks are redirected to the printk_safe implementation and the
> > messages
> > are stored into per-CPU buffers. These buffers might be eventually
> > flushed
> > in printk_safe_flush_on_panic() but it is not guaranteed.
> > 
> > In general, we should do our best to get useful message from printk().
> > All pointers to the first memory page must be invalid. Let's prevent
> > the dereference and print "(null)" in this case. This is already done
> > in many other situations, including "%s" format handling and many
> > page fault handlers.
> > 
> 
> 
> With such explanation it makes at least clear for the reader why it's
> done.
> 
> Thanks!
> 
> Would you be okay if I take this one as a first in my series and
> resubmit the series based on it?

Makes sense. Feel free to go on.

Best Regards,
Petr

[PATCH v3 3/8] scsi: hisi_sas: fix the issue of link rate inconsistency

[John Garry]

From: Xiaofei Tan 

In sysfs, there are two files about minimum linkrate, and also
two files for maximum linkrate. Take maximum linkrate example,
maximum_linkrate_hw is read-only and indicated by the register
HARD_PHY_LINKRATE, and maximum_linkrate is read-write and
corresponding to the register PROG_PHY_LINK_RATE.

But in the function phy_up_v*_hw(), we get *_linkrate value from
HARD_PHY_LINKRATE. It is not right. This patch is to fix this issue.

Unreferenced PHY-interrupt enum is also removed for v3 hw.

Signed-off-by: Xiaofei Tan 
Signed-off-by: John Garry 
---
 drivers/scsi/hisi_sas/hisi_sas_main.c  |  2 ++
 drivers/scsi/hisi_sas/hisi_sas_v1_hw.c |  1 -
 drivers/scsi/hisi_sas/hisi_sas_v2_hw.c |  8 +---
 drivers/scsi/hisi_sas/hisi_sas_v3_hw.c | 13 +
 4 files changed, 4 insertions(+), 20 deletions(-)

diff --git a/drivers/scsi/hisi_sas/hisi_sas_main.c 
b/drivers/scsi/hisi_sas/hisi_sas_main.c
index 2d4dbed..9d16372 100644
--- a/drivers/scsi/hisi_sas/hisi_sas_main.c
+++ b/drivers/scsi/hisi_sas/hisi_sas_main.c
@@ -683,6 +683,8 @@ static void hisi_sas_phy_init(struct hisi_hba *hisi_hba, 
int phy_no)
 
phy->hisi_hba = hisi_hba;
phy->port = NULL;
+   phy->minimum_linkrate = SAS_LINK_RATE_1_5_GBPS;
+   phy->maximum_linkrate = hisi_hba->hw->phy_get_max_linkrate();
sas_phy->enabled = (phy_no < hisi_hba->n_phy) ? 1 : 0;
sas_phy->class = SAS;
sas_phy->iproto = SAS_PROTOCOL_ALL;
diff --git a/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c 
b/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c
index 679e76f..38bbda9 100644
--- a/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c
+++ b/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c
@@ -873,7 +873,6 @@ static void phy_set_linkrate_v1_hw(struct hisi_hba 
*hisi_hba, int phy_no,
sas_phy->phy->maximum_linkrate = max;
sas_phy->phy->minimum_linkrate = min;
 
-   min -= SAS_LINK_RATE_1_5_GBPS;
max -= SAS_LINK_RATE_1_5_GBPS;
 
for (i = 0; i <= max; i++)
diff --git a/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c 
b/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
index 42b3fd6..67be346 100644
--- a/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
+++ b/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
@@ -1603,7 +1603,6 @@ static void phy_set_linkrate_v2_hw(struct hisi_hba 
*hisi_hba, int phy_no,
sas_phy->phy->maximum_linkrate = max;
sas_phy->phy->minimum_linkrate = min;
 
-   min -= SAS_LINK_RATE_1_5_GBPS;
max -= SAS_LINK_RATE_1_5_GBPS;
 
for (i = 0; i <= max; i++)
@@ -2684,7 +2683,7 @@ static int prep_abort_v2_hw(struct hisi_hba *hisi_hba,
 static int phy_up_v2_hw(int phy_no, struct hisi_hba *hisi_hba)
 {
int i, res = IRQ_HANDLED;
-   u32 port_id, link_rate, hard_phy_linkrate;
+   u32 port_id, link_rate;
struct hisi_sas_phy *phy = &hisi_hba->phy[phy_no];
struct asd_sas_phy *sas_phy = &phy->sas_phy;
struct device *dev = hisi_hba->dev;
@@ -2723,11 +2722,6 @@ static int phy_up_v2_hw(int phy_no, struct hisi_hba 
*hisi_hba)
}
 
sas_phy->linkrate = link_rate;
-   hard_phy_linkrate = hisi_sas_phy_read32(hisi_hba, phy_no,
-   HARD_PHY_LINKRATE);
-   phy->maximum_linkrate = hard_phy_linkrate & 0xf;
-   phy->minimum_linkrate = (hard_phy_linkrate >> 4) & 0xf;
-
sas_phy->oob_mode = SAS_OOB_MODE;
memcpy(sas_phy->attached_sas_addr, &id->sas_addr, SAS_ADDR_SIZE);
dev_info(dev, "phyup: phy%d link_rate=%d\n", phy_no, link_rate);
diff --git a/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c 
b/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c
index a1f1868..1ee95ab 100644
--- a/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c
+++ b/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c
@@ -340,12 +340,6 @@ struct hisi_sas_err_record_v3 {
 #define HISI_SAS_COMMAND_ENTRIES_V3_HW 4096
 #define HISI_SAS_MSI_COUNT_V3_HW 32
 
-enum {
-   HISI_SAS_PHY_PHY_UPDOWN,
-   HISI_SAS_PHY_CHNL_INT,
-   HISI_SAS_PHY_INT_NR
-};
-
 #define DIR_NO_DATA 0
 #define DIR_TO_INI 1
 #define DIR_TO_DEVICE 2
@@ -1121,7 +1115,7 @@ static int prep_abort_v3_hw(struct hisi_hba *hisi_hba,
 static int phy_up_v3_hw(int phy_no, struct hisi_hba *hisi_hba)
 {
int i, res = 0;
-   u32 context, port_id, link_rate, hard_phy_linkrate;
+   u32 context, port_id, link_rate;
struct hisi_sas_phy *phy = &hisi_hba->phy[phy_no];
struct asd_sas_phy *sas_phy = &phy->sas_phy;
struct device *dev = hisi_hba->dev;
@@ -1139,10 +1133,6 @@ static int phy_up_v3_hw(int phy_no, struct hisi_hba 
*hisi_hba)
goto end;
}
sas_phy->linkrate = link_rate;
-   hard_phy_linkrate = hisi_sas_phy_read32(hisi_hba, phy_no,
-   HARD_PHY_LINKRATE);
-   phy->maximum_linkrate = hard_phy_linkrate & 0xf;
-   phy->minimum_linkrate = (hard_phy_linkrate >> 4) & 0xf;
phy->phy_type &= ~(PORT_TYPE_SAS | PORT_TYPE_SATA);
 
/* Check for SATA dev */
@@ -1864,7 +1854,6 @@ static void phy_s

[PATCH v3 0/8] hisi_sas: support x6000 board and some misc changes

[John Garry]

This patchset primarily adds support for the Huawei x6000 board,
which includes hip07 chipset. Unfortunately, due to some board
layout differences with our development board, we need to set
a PHY-related register differently for optimal signal quality. As
such, a signal attenuation property is added to describe the
differences in the boards and allow the PHY register to be set
appropriately.

In addition to this above feature, some misc changes are added for:
- PHY linkrate sysfs interface
- linkrate set function
- internal abort timer timeout increase

Differences to v2:
- rename dt binding property name to "hisilicon,signal-attenuation"

Differences to v1:
- rename dt binding property name to include "hisi-" prefix

Xiang Chen (2):
  scsi: hisi_sas: remove unused variable hisi_sas_devices.running_req
  scsi: hisi_sas: Code cleanup and minor bug fixes

Xiaofei Tan (6):
  dt-bindings: scsi: hisi_sas: add an property of signal attenuation
  scsi: hisi_sas: support the property of signal attenuation for v2 hw
  scsi: hisi_sas: fix the issue of link rate inconsistency
  scsi: hisi_sas: fix the issue of setting linkrate register
  scsi: hisi_sas: increase timer expire of internal abort task
  scsi: hisi_sas: fix return value of hisi_sas_task_prep()

 .../devicetree/bindings/scsi/hisilicon-sas.txt |  7 +++
 drivers/scsi/hisi_sas/hisi_sas.h   |  1 -
 drivers/scsi/hisi_sas/hisi_sas_main.c  | 34 +---
 drivers/scsi/hisi_sas/hisi_sas_v1_hw.c | 13 +++--
 drivers/scsi/hisi_sas/hisi_sas_v2_hw.c | 62 +-
 drivers/scsi/hisi_sas/hisi_sas_v3_hw.c | 34 +---
 6 files changed, 88 insertions(+), 63 deletions(-)

-- 
1.9.1

Re: [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding

[Robin Murphy]

On 05/03/18 14:29, Nipun Gupta wrote:

The existing IOMMU bindings cannot be used to specify the relationship
between fsl-mc devices and IOMMUs. This patch adds a binding for
mapping fsl-mc devices to IOMMUs, using a new iommu-parent property.


Given that allowing "msi-parent" for #msi-cells > 1 is merely a 
backward-compatibility bodge full of hard-coded assumptions, why would 
we want to knowingly introduce a similarly unpleasant equivalent for 
IOMMUs? What's wrong with "iommu-map"?



Signed-off-by: Nipun Gupta 
---
  .../devicetree/bindings/misc/fsl,qoriq-mc.txt  | 31 ++
  1 file changed, 31 insertions(+)

diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt 
b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
index 6611a7c..011c7d6 100644
--- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
+++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
@@ -9,6 +9,24 @@ blocks that can be used to create functional hardware 
objects/devices
  such as network interfaces, crypto accelerator instances, L2 switches,
  etc.
  
+For an overview of the DPAA2 architecture and fsl-mc bus see:

+drivers/staging/fsl-mc/README.txt
+
+As described in the above overview, all DPAA2 objects in a DPRC share the
+same hardware "isolation context" and a 10-bit value called an ICID
+(isolation context id) is expressed by the hardware to identify
+the requester.


IOW, precisely the case for which "{msi,iommu}-map" exist. Yes, I know 
they're currently documented under bindings/pci, but they're not really 
intended to be absolutely PCI-specific.


Robin.


+The generic 'iommus' property is cannot be used to describe the relationship
+between fsl-mc and IOMMUs, so an iommu-parent property is used to define
+the same.
+
+For generic IOMMU bindings, see
+Documentation/devicetree/bindings/iommu/iommu.txt.
+
+For arm-smmu binding, see:
+Documentation/devicetree/bindings/iommu/arm,smmu.txt.
+
  Required properties:
  
  - compatible

@@ -88,14 +106,27 @@ Sub-nodes:
Value type: 
Definition: Specifies the phandle to the PHY device node 
associated
with the this dpmac.
+Optional properties:
+
+- iommu-parent: Maps the devices on fsl-mc bus to an IOMMU.
+  The property specifies the IOMMU behind which the devices on
+  fsl-mc bus are residing.
  
  Example:
  
+smmu: iommu@500 {

+   compatible = "arm,mmu-500";
+   #iommu-cells = <1>;
+   stream-match-mask = <0x7C00>;
+   ...
+};
+
  fsl_mc: fsl-mc@80c00 {
  compatible = "fsl,qoriq-mc";
  reg = <0x0008 0x0c00 0 0x40>,/* MC portal base */
<0x 0x0834 0 0x4>; /* MC control reg */
  msi-parent = <&its>;
+iommu-parent = <&smmu>;
  #address-cells = <3>;
  #size-cells = <1>;
  

[PATCH] mtdchar: fix usage of mtd_ooblayout_ecc()

[OuYang ZhiZhong]

Section was not properly computed. The value of OOB region definition is
always ECC section 0 information in the OOB area, but we want to get all
the ECC bytes information, so we should call
mtd_ooblayout_ecc(mtd, section++, &oobregion) until it returns -ERANGE.

This is fixed by using i instead of section.

Signed-off-by: OuYang ZhiZhong 
---
 drivers/mtd/mtdchar.c |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/mtd/mtdchar.c b/drivers/mtd/mtdchar.c
index de8c902..0cc929e 100644
--- a/drivers/mtd/mtdchar.c
+++ b/drivers/mtd/mtdchar.c
@@ -468,7 +468,7 @@ static int shrink_ecclayout(struct mtd_info *mtd,
struct nand_ecclayout_user *to)
 {
struct mtd_oob_region oobregion;
-   int i, section = 0, ret;
+   int i, ret;
 
if (!mtd || !to)
return -EINVAL;
@@ -479,7 +479,7 @@ static int shrink_ecclayout(struct mtd_info *mtd,
for (i = 0; i < MTD_MAX_ECCPOS_ENTRIES;) {
u32 eccpos;
 
-   ret = mtd_ooblayout_ecc(mtd, section, &oobregion);
+   ret = mtd_ooblayout_ecc(mtd, i, &oobregion);
if (ret < 0) {
if (ret != -ERANGE)
return ret;
@@ -515,7 +515,7 @@ static int shrink_ecclayout(struct mtd_info *mtd,
 static int get_oobinfo(struct mtd_info *mtd, struct nand_oobinfo *to)
 {
struct mtd_oob_region oobregion;
-   int i, section = 0, ret;
+   int i, ret;
 
if (!mtd || !to)
return -EINVAL;
@@ -526,7 +526,7 @@ static int get_oobinfo(struct mtd_info *mtd, struct 
nand_oobinfo *to)
for (i = 0; i < ARRAY_SIZE(to->eccpos);) {
u32 eccpos;
 
-   ret = mtd_ooblayout_ecc(mtd, section, &oobregion);
+   ret = mtd_ooblayout_ecc(mtd, i, &oobregion);
if (ret < 0) {
if (ret != -ERANGE)
return ret;
-- 
1.7.9.5

Re: [PATCH v2 8/9] lib/vsprintf: Remove useless NULL checks

[Petr Mladek]

On Fri 2018-03-02 16:15:06, Andy Shevchenko wrote:
> On Fri, 2018-03-02 at 13:51 +0100, Petr Mladek wrote:
> 
> > BTW: I am not sure who is going to pass this patchset to Linus.
> > If nobody is against, I could eventually do so via printk.git.
> 
> Usually Andrew Morton takes care.
> But perhaps it's a time to unload Andrew in this part at least?

I think that Andrew took these patches as the last resort.

> Would you agree to be a maintainer of lib/vsprinf.c and
> lib/test_printf.c ?

If nobody is against, I could do so.

Best Regards,
Petr

Re: [PATCHv3] iommu/intel: Ratelimit each dmar fault printing

[Dmitry Safonov]

Hi Joerg,

What do you think about v3?
It looks like, I can solve my softlookups with just a bit more proper
ratelimiting..

On Thu, 2018-02-15 at 19:17 +, Dmitry Safonov wrote:
> There is a ratelimit for printing, but it's incremented each time the
> cpu recives dmar fault interrupt. While one interrupt may signal
> about
> *many* faults.
> So, measuring the impact it turns out that reading/clearing one fault
> takes < 1 usec, and printing info about the fault takes ~170 msec.
> 
> Having in mind that maximum number of fault recording registers per
> remapping hardware unit is 256.. IRQ handler may run for (170*256)
> msec.
> And as fault-serving loop runs without a time limit, during servicing
> new faults may occur..
> 
> Ratelimit each fault printing rather than each irq printing.
> 
> Fixes: commit c43fce4eebae ("iommu/vt-d: Ratelimit fault handler")
> 
> BUG: spinlock lockup suspected on CPU#0, CliShell/9903
>  lock: 0x81a47440, .magic: dead4ead, .owner:
> kworker/u16:2/8915, .owner_cpu: 6
> CPU: 0 PID: 9903 Comm: CliShell
> Call Trace:$\n'
> [..] dump_stack+0x65/0x83$\n'
> [..] spin_dump+0x8f/0x94$\n'
> [..] do_raw_spin_lock+0x123/0x170$\n'
> [..] _raw_spin_lock_irqsave+0x32/0x3a$\n'
> [..] uart_chars_in_buffer+0x20/0x4d$\n'
> [..] tty_chars_in_buffer+0x18/0x1d$\n'
> [..] n_tty_poll+0x1cb/0x1f2$\n'
> [..] tty_poll+0x5e/0x76$\n'
> [..] do_select+0x363/0x629$\n'
> [..] compat_core_sys_select+0x19e/0x239$\n'
> [..] compat_SyS_select+0x98/0xc0$\n'
> [..] sysenter_dispatch+0x7/0x25$\n'
> [..]
> NMI backtrace for cpu 6
> CPU: 6 PID: 8915 Comm: kworker/u16:2
> Workqueue: dmar_fault dmar_fault_work
> Call Trace:$\n'
> [..] wait_for_xmitr+0x26/0x8f$\n'
> [..] serial8250_console_putchar+0x1c/0x2c$\n'
> [..] uart_console_write+0x40/0x4b$\n'
> [..] serial8250_console_write+0xe6/0x13f$\n'
> [..] call_console_drivers.constprop.13+0xce/0x103$\n'
> [..] console_unlock+0x1f8/0x39b$\n'
> [..] vprintk_emit+0x39e/0x3e6$\n'
> [..] printk+0x4d/0x4f$\n'
> [..] dmar_fault+0x1a8/0x1fc$\n'
> [..] dmar_fault_work+0x15/0x17$\n'
> [..] process_one_work+0x1e8/0x3a9$\n'
> [..] worker_thread+0x25d/0x345$\n'
> [..] kthread+0xea/0xf2$\n'
> [..] ret_from_fork+0x58/0x90$\n'
> 
> Cc: Alex Williamson 
> Cc: David Woodhouse 
> Cc: Ingo Molnar 
> Cc: Joerg Roedel 
> Cc: Lu Baolu 
> Cc: io...@lists.linux-foundation.org
> Signed-off-by: Dmitry Safonov 
> ---
> Maybe it's worth to limit while(1) cycle.
> If IOMMU generates faults with equal speed as irq handler cleans
> them, it may turn into long-irq-disabled region again.
> Not sure if it can happen anyway.
> 
>  drivers/iommu/dmar.c | 8 +++-
>  1 file changed, 3 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c
> index accf58388bdb..6c4ea32ee6a9 100644
> --- a/drivers/iommu/dmar.c
> +++ b/drivers/iommu/dmar.c
> @@ -1618,17 +1618,13 @@ irqreturn_t dmar_fault(int irq, void *dev_id)
>   int reg, fault_index;
>   u32 fault_status;
>   unsigned long flag;
> - bool ratelimited;
>   static DEFINE_RATELIMIT_STATE(rs,
> DEFAULT_RATELIMIT_INTERVAL,
> DEFAULT_RATELIMIT_BURST);
>  
> - /* Disable printing, simply clear the fault when ratelimited
> */
> - ratelimited = !__ratelimit(&rs);
> -
>   raw_spin_lock_irqsave(&iommu->register_lock, flag);
>   fault_status = readl(iommu->reg + DMAR_FSTS_REG);
> - if (fault_status && !ratelimited)
> + if (fault_status && __ratelimit(&rs))
>   pr_err("DRHD: handling fault status reg %x\n",
> fault_status);
>  
>   /* TBD: ignore advanced fault log currently */
> @@ -1638,6 +1634,8 @@ irqreturn_t dmar_fault(int irq, void *dev_id)
>   fault_index = dma_fsts_fault_record_index(fault_status);
>   reg = cap_fault_reg_offset(iommu->cap);
>   while (1) {
> + /* Disable printing, simply clear the fault when
> ratelimited */
> + bool ratelimited = !__ratelimit(&rs);
>   u8 fault_reason;
>   u16 source_id;
>   u64 guest_addr;

RE: [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding

[Nipun Gupta]

> -Original Message-
> From: Robin Murphy [mailto:robin.mur...@arm.com]
> Sent: Monday, March 05, 2018 20:23
> To: Nipun Gupta ; will.dea...@arm.com;
> mark.rutl...@arm.com; catalin.mari...@arm.com
> Cc: io...@lists.linux-foundation.org; robh...@kernel.org; h...@lst.de;
> m.szyprow...@samsung.com; gre...@linuxfoundation.org; j...@8bytes.org;
> Leo Li ; shawn...@kernel.org; linux-
> ker...@vger.kernel.org; devicet...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; linuxppc-...@lists.ozlabs.org; Bharat Bhushan
> ; stuyo...@gmail.com; Laurentiu Tudor
> 
> Subject: Re: [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding
> 
> On 05/03/18 14:29, Nipun Gupta wrote:
> > The existing IOMMU bindings cannot be used to specify the relationship
> > between fsl-mc devices and IOMMUs. This patch adds a binding for
> > mapping fsl-mc devices to IOMMUs, using a new iommu-parent property.
> 
> Given that allowing "msi-parent" for #msi-cells > 1 is merely a
> backward-compatibility bodge full of hard-coded assumptions, why would
> we want to knowingly introduce a similarly unpleasant equivalent for
> IOMMUs? What's wrong with "iommu-map"?

Hi Robin,

With 'msi-parent' the property is fixed up to have msi-map. In this case there 
is
no fixup required and simple 'iommu-parent' property can be used, with MC bus
itself providing the stream-id's (in the code execution via FW).

We can also use the iommu-map property similar to PCI, which will require u-boot
fixup. But then it leads to little bit complications of u-boot - kernel 
compatibility.

If you suggest we can re-use the iommu-map property. What is your opinion?

Thanks,
Nipun

> 
> > Signed-off-by: Nipun Gupta 
> > ---
> >   .../devicetree/bindings/misc/fsl,qoriq-mc.txt  | 31
> ++
> >   1 file changed, 31 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> > index 6611a7c..011c7d6 100644
> > --- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> > +++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> > @@ -9,6 +9,24 @@ blocks that can be used to create functional hardware
> objects/devices
> >   such as network interfaces, crypto accelerator instances, L2 switches,
> >   etc.
> >
> > +For an overview of the DPAA2 architecture and fsl-mc bus see:
> > +drivers/staging/fsl-mc/README.txt
> > +
> > +As described in the above overview, all DPAA2 objects in a DPRC share the
> > +same hardware "isolation context" and a 10-bit value called an ICID
> > +(isolation context id) is expressed by the hardware to identify
> > +the requester.
> 
> IOW, precisely the case for which "{msi,iommu}-map" exist. Yes, I know
> they're currently documented under bindings/pci, but they're not really
> intended to be absolutely PCI-specific.
> 
> Robin.
> 
> > +The generic 'iommus' property is cannot be used to describe the 
> > relationship
> > +between fsl-mc and IOMMUs, so an iommu-parent property is used to define
> > +the same.
> > +
> > +For generic IOMMU bindings, see
> > +Documentation/devicetree/bindings/iommu/iommu.txt.
> > +
> > +For arm-smmu binding, see:
> > +Documentation/devicetree/bindings/iommu/arm,smmu.txt.
> > +
> >   Required properties:
> >
> >   - compatible
> > @@ -88,14 +106,27 @@ Sub-nodes:
> > Value type: 
> > Definition: Specifies the phandle to the PHY device node 
> > associated
> > with the this dpmac.
> > +Optional properties:
> > +
> > +- iommu-parent: Maps the devices on fsl-mc bus to an IOMMU.
> > +  The property specifies the IOMMU behind which the devices on
> > +  fsl-mc bus are residing.
> >
> >   Example:
> >
> > +smmu: iommu@500 {
> > +   compatible = "arm,mmu-500";
> > +   #iommu-cells = <1>;
> > +   stream-match-mask = <0x7C00>;
> > +   ...
> > +};
> > +
> >   fsl_mc: fsl-mc@80c00 {
> >   compatible = "fsl,qoriq-mc";
> >   reg = <0x0008 0x0c00 0 0x40>,/* MC portal 
> > base */
> > <0x 0x0834 0 0x4>; /* MC control 
> > reg */
> >   msi-parent = <&its>;
> > +iommu-parent = <&smmu>;
> >   #address-cells = <3>;
> >   #size-cells = <1>;
> >
> >

[PATCH 0/2] Fix STi aliases property name

[patrice.chotard]

From: Patrice Chotard 

Since dtc v1.4.6-9-gaadd0b65c987, when compiling dtb with W=1 option,
the following warnings are triggered :

arch/arm/boot/dts/stih418-b2199.dtb: Warning (alias_paths): /aliases: aliases 
property name must include only lowercase and '-'
arch/arm/boot/dts/stih407-b2120.dtb: Warning (alias_paths): /aliases: aliases 
property name must include only lowercase and '-'
arch/arm/boot/dts/stih410-b2260.dtb: Warning (alias_paths): /aliases: aliases 
property name must include only lowercase and '-'
arch/arm/boot/dts/stih410-b2120.dtb: Warning (alias_paths): /aliases: aliases 
property name must include only lowercase and '-'

_ Patch 1, convert the aliases property name in lowercase in 
  all STi board dts files.

_ Patch 2, rework the tty driver st-asc accordingly, as aliases id is retrieved 
  using of_alias_get_id() with a defined string with is not lowercase only.


Patrice Chotard (2):
  ARM: dts: STi: Fix aliases property name for STi boards
  tty: st-asc: Convert tty alias in lowercase

 arch/arm/boot/dts/stih407-b2120.dts | 4 ++--
 arch/arm/boot/dts/stih410-b2120.dts | 4 ++--
 arch/arm/boot/dts/stih410-b2260.dts | 4 ++--
 arch/arm/boot/dts/stih418-b2199.dts | 4 ++--
 drivers/tty/serial/st-asc.c | 2 +-
 5 files changed, 9 insertions(+), 9 deletions(-)

-- 
1.9.1

Re: [PATCH 1/2] kbuild: remove command line interface LDFLAGS_MODULE from makefiles.txt

[Masahiro Yamada]

2018-02-28 19:14 GMT+09:00 Masahiro Yamada :
> Documentation/kbuild/makefiles.txt lists variables used in Makefile
> whereas Documentation/kbuild/kbuild.txt describes user assignable
> parameters given via environments or the command line.
>
> LDFLAGS_MODULE is a command line interface, so it should be dropped
> from makefiles.txt.
>
> Some lines below in this file, it is clearly explained that
> KBUILD_LDFLAGS_MODULE is the right one for the internal use:
>
> KBUILD_LDFLAGS_MODULE   Options for $(LD) when linking modules
>
> $(KBUILD_LDFLAGS_MODULE) is used to add arch-specific options
> used when linking modules. This is often a linker script.
> From commandline LDFLAGS_MODULE shall be used (see kbuild.txt).
>
> Then, kbuild.txt explains LDFLAGS_MODULE, like follows:
>
> LDFLAGS_MODULE
> --
> Additional options used for $(LD) when linking modules.
>
> Signed-off-by: Masahiro Yamada 
> ---
>
>  Documentation/kbuild/makefiles.txt | 6 --
>  1 file changed, 6 deletions(-)


Both applied to linux-kbuild/kbuild.






-- 
Best Regards
Masahiro Yamada

[PATCH 2/2] tty: st-asc: Convert tty alias in lowercase

[patrice.chotard]

From: Patrice Chotard 

Since dtc v1.4.6-9-gaadd0b65c987, aliases property name
must include only lowercase and '-'.

After having converted all STi boards serial aliases in lowercase,
st-asc driver need to be updated accordingly as tty aliases id is
retrieved using of_alias_get_id(np, ASC_SERIAL_NAME);

Signed-off-by: Patrice Chotard 
---
 drivers/tty/serial/st-asc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/tty/serial/st-asc.c b/drivers/tty/serial/st-asc.c
index c763253514e9..8d2167759258 100644
--- a/drivers/tty/serial/st-asc.c
+++ b/drivers/tty/serial/st-asc.c
@@ -29,7 +29,7 @@
 #include 
 
 #define DRIVER_NAME "st-asc"
-#define ASC_SERIAL_NAME "ttyAS"
+#define ASC_SERIAL_NAME "ttyas"
 #define ASC_FIFO_SIZE 16
 #define ASC_MAX_PORTS 8
 
-- 
1.9.1

[PATCH 1/2] ARM: dts: STi: Fix aliases property name for STi boards

[patrice.chotard]

From: Patrice Chotard 

Since dtc v1.4.6-9-gaadd0b65c987, aliases property name must
be lowercase only.
This allows to fix following warnings when compiling dtb
with W=1 option :

arch/arm/boot/dts/stih418-b2199.dtb: Warning (alias_paths): /aliases: aliases 
property name must include only lowercase and '-'
arch/arm/boot/dts/stih407-b2120.dtb: Warning (alias_paths): /aliases: aliases 
property name must include only lowercase and '-'
arch/arm/boot/dts/stih410-b2260.dtb: Warning (alias_paths): /aliases: aliases 
property name must include only lowercase and '-'
arch/arm/boot/dts/stih410-b2120.dtb: Warning (alias_paths): /aliases: aliases 
property name must include only lowercase and '-'

Signed-off-by: Patrice Chotard 
---
 arch/arm/boot/dts/stih407-b2120.dts | 4 ++--
 arch/arm/boot/dts/stih410-b2120.dts | 4 ++--
 arch/arm/boot/dts/stih410-b2260.dts | 4 ++--
 arch/arm/boot/dts/stih418-b2199.dts | 4 ++--
 4 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/arm/boot/dts/stih407-b2120.dts 
b/arch/arm/boot/dts/stih407-b2120.dts
index c8ad905d0309..fa1186af6574 100644
--- a/arch/arm/boot/dts/stih407-b2120.dts
+++ b/arch/arm/boot/dts/stih407-b2120.dts
@@ -14,7 +14,7 @@
compatible = "st,stih407-b2120", "st,stih407";
 
chosen {
-   bootargs = "console=ttyAS0,115200 clk_ignore_unused";
+   bootargs = "console=ttyas0,115200 clk_ignore_unused";
linux,stdout-path = &sbc_serial0;
};
 
@@ -24,7 +24,7 @@
};
 
aliases {
-   ttyAS0 = &sbc_serial0;
+   ttyas0 = &sbc_serial0;
ethernet0 = ðernet0;
};
 
diff --git a/arch/arm/boot/dts/stih410-b2120.dts 
b/arch/arm/boot/dts/stih410-b2120.dts
index 9830be577433..00258212b6fb 100644
--- a/arch/arm/boot/dts/stih410-b2120.dts
+++ b/arch/arm/boot/dts/stih410-b2120.dts
@@ -14,7 +14,7 @@
compatible = "st,stih410-b2120", "st,stih410";
 
chosen {
-   bootargs = "console=ttyAS0,115200 clk_ignore_unused";
+   bootargs = "console=ttyas0,115200 clk_ignore_unused";
linux,stdout-path = &sbc_serial0;
};
 
@@ -24,7 +24,7 @@
};
 
aliases {
-   ttyAS0 = &sbc_serial0;
+   ttyas0 = &sbc_serial0;
ethernet0 = ðernet0;
};
 
diff --git a/arch/arm/boot/dts/stih410-b2260.dts 
b/arch/arm/boot/dts/stih410-b2260.dts
index c663b70c43a7..3d122c3a1ad6 100644
--- a/arch/arm/boot/dts/stih410-b2260.dts
+++ b/arch/arm/boot/dts/stih410-b2260.dts
@@ -15,7 +15,7 @@
compatible = "st,stih410-b2260", "st,stih410";
 
chosen {
-   bootargs = "console=ttyAS1,115200 clk_ignore_unused";
+   bootargs = "console=ttyas1,115200 clk_ignore_unused";
linux,stdout-path = &uart1;
};
 
@@ -25,7 +25,7 @@
};
 
aliases {
-   ttyAS1 = &uart1;
+   ttyas1 = &uart1;
ethernet0 = ðernet0;
};
 
diff --git a/arch/arm/boot/dts/stih418-b2199.dts 
b/arch/arm/boot/dts/stih418-b2199.dts
index 4e6d915c85ff..8459a3766b7c 100644
--- a/arch/arm/boot/dts/stih418-b2199.dts
+++ b/arch/arm/boot/dts/stih418-b2199.dts
@@ -14,7 +14,7 @@
compatible = "st,stih418-b2199", "st,stih418";
 
chosen {
-   bootargs = "console=ttyAS0,115200 clk_ignore_unused";
+   bootargs = "console=ttyas0,115200 clk_ignore_unused";
linux,stdout-path = &sbc_serial0;
};
 
@@ -24,7 +24,7 @@
};
 
aliases {
-   ttyAS0 = &sbc_serial0;
+   ttyas0 = &sbc_serial0;
ethernet0 = ðernet0;
};
 
-- 
1.9.1

Re: [PATCH 02/14] perf trace: Apply new perf_mmap__read_event() interface

[Arnaldo Carvalho de Melo]

Em Mon, Mar 05, 2018 at 09:50:10AM -0500, Liang, Kan escreveu:
> 
> 
> On 3/5/2018 8:46 AM, Arnaldo Carvalho de Melo wrote:
> > Em Mon, Mar 05, 2018 at 10:03:39AM -0300, Arnaldo Carvalho de Melo escreveu:
> > > I'm doing this, the argument is 'bool', so the value should be false or
> > > true, even '0' being way shorter...

> > While doing that I wonder why is that we can't do it without those
> > explicit start/end variables in all the call sites and passing
> > overwrite, start and end as parameters...

> > Can't we just add 'overwrite, 'start' and 'end' to struct perf_mmap,
> > then have perf_mmap__read_init() with just 'md' and 'overwrite' as
> > parameters, initialize md->{start,end} and set md->overwrite to the
> > 'overwrite' parameter in 'perf_mmap__read_init()' and then use just
> > md as parameters for both perf_mmap__read_event() and
> > perf_mmap__consume()?
 
> I don't see any reason we cannot do this.
> I will do some test. If it works well, I will submit the follow-up patch to
> clean up the interface.

Thanks a lot! The less boilerplate we have in such functions, making
them easier to use for new people contributing to tools/perf/, the
better.

- Arnaldo

Re: [PATCH v1 0/3] perf: expose thread context switch out event type to user space

[Arnaldo Carvalho de Melo]

Em Mon, Mar 05, 2018 at 02:35:02PM +0300, Alexey Budankov escreveu:
> 
> Here is a series of small patches that implement exposing type of 
> context-switch-out event as a part of PERF_RECORD_SWITCH[_CPU_WIDE] record.
> 
> Introduced types of context-switch-out events assumed to be:
> a) preempt: task->state == TASK_RUNNING
>   misc &= PERF_RECORD_MISC_SWITCH_OUT
>   
> b) yield: !preempt - using new bit PERF_RECORD_MISC_SWITCH_OUT_YIELD:
misc &= PERF_RECORD_MISC_SWITCH_OUT|PERF_RECORD_MISC_SWITCH_OUT_YIELD
> 
> Perf tool report and script commands output has been extended to decode 
> new yield bit and the updated output looks like in the examples below.

I'm just waiting for the current reviewers to be satisfied with this,
but I think this is a great addition and 'perf trace' is another tool
that should jump into this, showing forced context switches together
with syscalls.

- Arnaldo
 
> The documentation has been updated to mention yield switch out events and its 
> decoding symbols in perf script output.
> 
> The changes have been manually tested on Fedora 27 with the patched kernel:
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git perf/core
> 
> perf report -D -i system-wide.perf: 
> 
> 0x1b9c50 [0x30]: event: 15
> .
> . ... raw event: size 48 bytes
> .  :  0f 00 00 00 00 20 30 00 01 1e 00 00 01 1e 00 00  . 0.
> .  0010:  00 00 00 00 00 00 00 00 85 ae d4 e3 3e 0e 00 00  >...
> .  0020:  54 00 00 00 00 00 00 00 05 00 00 00 00 00 00 00  T...
> 
> 5 15663273127557 0x1b9c50 [0x30]: PERF_RECORD_SWITCH_CPU_WIDE OUT  next 
> pid/tid:  7681/7681 
> 
> 0x2646c0 [0x30]: event: 15
> .
> . ... raw event: size 48 bytes
> .  :  0f 00 00 00 00 60 30 00 00 00 00 00 00 00 00 00  .`0.
> .  0010:  00 1e 00 00 00 1e 00 00 29 1e d5 e3 3e 0e 00 00  )...>...
> .  0020:  56 00 00 00 00 00 00 00 07 00 00 00 00 00 00 00  V...
> 
> 7 15663273156137 0x2646c0 [0x30]: PERF_RECORD_SWITCH_CPU_WIDE OUT yield  next 
> pid/tid: 0/0
> 
> perf script --show-switch-events -F +misc -I -i system-wide.perf:
> 
> amplxe-perf  7681 [005] S 15663.273151: PERF_RECORD_SWITCH_CPU_WIDE OUT  
> next pid/tid:39/39   
> migration/539 [005]   15663.273152: PERF_RECORD_SWITCH_CPU_WIDE IN   
> prev pid/tid:  7681/7681 
> amplxe-perf  7680 [007] K 15663.273153:  1
>   
>  context-switch: 
>   aaa488 schedule ([kernel.kallsyms])
>   1a9f50 __poll_nocancel (inlined)
> 
> amplxe-perf  7680 [007] Sy15663.273156: PERF_RECORD_SWITCH_CPU_WIDE OUT 
> yield  next pid/tid: 0/0
> migration/539 [005] K 15663.273157:
> 
> ---
>  Alexey Budankov (3):
>   perf/core: store context switch out type into Perf trace
>   perf report: extend raw dump (-D) out with switch out event type
>   perf script: extend misc field decoding with switch out event type
>   
>  include/uapi/linux/perf_event.h  |  5 +
>  kernel/events/core.c |  4 +++-
>  tools/include/uapi/linux/perf_event.h|  5 +
>  tools/perf/Documentation/perf-script.txt | 17 +
>  tools/perf/builtin-script.c  |  5 -
>  tools/perf/util/event.c  |  4 +++-
>  6 files changed, 29 insertions(+), 11 deletions(-)

Warning from swake_up_all in 4.14.15-rt13 non-RT

[Corey Minyard]

Starting with the change

8a64547a07980f9d25e962a78c2e10ee82bdb742 fs/dcache: use swait_queue 
instead of

waitqueue

we are getting the following warning when running with PREEMPT__LL when 
inserting
a USB drive.  This is on x86_64, 4.14.15-rt13.  It works fine with 
PREEMPT_RT.


# [  155.604042] usb 1-2: new high-speed USB device number 7 using xhci_hcd
[  155.736588] usb 1-2: New USB device found, idVendor=0781, idProduct=5567
[  155.743291] usb 1-2: New USB device strings: Mfr=1, Product=2, 
SerialNumber=3

[  155.750423] usb 1-2: Product: Cruzer Blade
[  155.754517] usb 1-2: Manufacturer: SanDisk
[  155.758616] usb 1-2: SerialNumber: 4C530302900731101541
[  155.764207] usb-storage 1-2:1.0: USB Mass Storage device detected
[  155.770457] scsi host7: usb-storage 1-2:1.0
[  156.831919] scsi 7:0:0:0: Direct-Access SanDisk  Cruzer Blade 
1.26 PQ: 0 ANSI: 6

[  156.840160] sd 7:0:0:0: Attached scsi generic sg1 type 0
[  156.845766] [ cut here ]
[  156.850387] WARNING: CPU: 0 PID: 36 at kernel/sched/swait.c:72 
swake_up_all+0xb4/0xc0

[  156.858208] Modules linked in:
[  156.861259] CPU: 0 PID: 36 Comm: kworker/0:1 Not tainted 4.14.15-rt13 #1
[  156.867950] Hardware name: Supermicro Super Server/To be filled by 
O.E.M., BIOS T20170302175436 03/02/2017

[  156.877590] Workqueue: events_freezable usb_stor_scan_dwork
[  156.883159] task: 8c7ead6c6a00 task.stack: b19dc19d
[  156.889072] RIP: 0010:swake_up_all+0xb4/0xc0
[  156.893334] RSP: :b19dc19d3be0 EFLAGS: 00010046
[  156.898550] RAX: 0046 RBX: 8c7eab451788 RCX: 

[  156.905673] RDX: 0001 RSI:  RDI: 
8c7eab451770
[  156.912798] RBP: 8c7eab451770 R08: 00023ca0 R09: 
8bb7663e
[  156.919920] R10: d80dd1a7dfc0 R11:  R12: 
b19dc19d3be0
[  156.927045] R13: 0003 R14: 8c7ea9e0e800 R15: 
8c7ea69e5000
[  156.934171] FS:  () GS:8c7ebfc0() 
knlGS:

[  156.942246] CS:  0010 DS:  ES:  CR0: 80050033
[  156.947983] CR2: fffd5000 CR3: 00046bb4e000 CR4: 
003406f0

[  156.955108] Call Trace:
[  156.957556]  percpu_ref_kill_and_confirm+0x93/0xa0
[  156.962345]  blk_freeze_queue_start+0x25/0x30
[  156.966696]  blk_set_queue_dying+0x2b/0x90
[  156.970786]  blk_cleanup_queue+0x28/0x110
[  156.974793]  __scsi_remove_device+0x66/0x130
[  156.979063]  scsi_probe_and_add_lun+0x878/0xbd0
[  156.983587]  ? scsi_probe_and_add_lun+0x9df/0xbd0
[  156.988285]  __scsi_scan_target+0x1e8/0x550
[  156.992462]  ? __wake_up_common_lock+0x79/0x90
[  156.996899]  scsi_scan_channel+0x5b/0x80
[  157.000815]  scsi_scan_host_selected+0xbe/0xf0
[  157.005252]  scsi_scan_host+0x15e/0x1a0
[  157.009083]  usb_stor_scan_dwork+0x1d/0x80
[  157.013177]  process_one_work+0x1dd/0x3e0
[  157.017189]  worker_thread+0x26/0x400
[  157.020844]  ? cancel_delayed_work+0x10/0x10
[  157.025107]  kthread+0x116/0x130
[  157.028333]  ? kthread_create_on_node+0x40/0x40
[  157.032858]  ret_from_fork+0x35/0x40
[  157.036435] Code: 49 39 c4 74 17 c6 45 00 00 fb 48 8d 7d 00 e8 c4 8a 
97 00 48 8b 04 24 49 39 c4 75 b9 c6 45 00 00 fb 48 8d 64 24 10 5b 5d 41 
5c c3

[  157.055292] ---[ end trace 86c20fd8d6c01794 ]---
[  157.060040] sd 7:0:0:0: [sdb] 15633408 512-byte logical blocks: (8.00 
GB/7.45 GiB)

[  157.070089] sd 7:0:0:0: [sdb] Write Protect is off
[  157.075183] sd 7:0:0:0: [sdb] Write cache: disabled, read cache: 
enabled, doesn't support DPO or FUA

[  157.100295]  sdb: sdb1
[  157.103778] sd 7:0:0:0: [sdb] Attached SCSI disk
[  157.379921] FAT-fs (sdb1): Volume was not properly unmounted. Some 
data may be corrupt. Please run fsck.



The following change is the obvious reason:

--- a/kernel/sched/swait.c
+++ b/kernel/sched/swait.c
@@ -69,6 +69,7 @@ void swake_up_all(struct swait_queue_head *q)
    struct swait_queue *curr;
    LIST_HEAD(tmp);

+   WARN_ON(irqs_disabled());
    raw_spin_lock_irq(&q->lock);
    list_splice_init(&q->task_list, &tmp);
    while (!list_empty(&tmp)) {

I've done a little bit of analysis here, percpu_ref_kill_and_confirm()
does spin_lock_irqsave() and then does a percpu_ref_put().  If the
refcount reaches zero, the release function of the refcount is
called.  In this case, the block code has set this to
blk_queue_usage_counter_release(), which calls swake_up_all().

It seems like a bad idea to call percpu_ref_put() with interrupts
disabled.  This problem actually doesn't appear to be RT-related,
there's just no warning call if the RT tree isn't used.

I'm not sure if it's best to just do the put outside the lock, or
have modified put function that returns a bool to know if a release
is required, then the release function can be called outside the
lock.  I can do patches and test, but I'm hoping for a little
guidance here.

I'm also wondering why we don't have a warning like this in the
*_spin_lock_irq() macr

Re: [RFC V2 1/3] perf, tools: Support wildcards on pmu name in dynamic pmu events

[Agustin Vega-Frias]

On 2018-03-04 13:10, Jiri Olsa wrote:

On Sun, Mar 04, 2018 at 09:12:45AM -0800, Andi Kleen wrote:

> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -241,7 +242,7 @@ PE_NAME opt_event_config
> >   if (!strncmp(name, "uncore_", 7) &&
> >   strncmp($1, "uncore_", 7))
> >   name += 7;
> > - if (!strncmp($1, name, strlen($1))) {
> > + if (!strncmp($1, name, strlen($1)) || !fnmatch($1, 
name, 0)) {
>
> could we now get rid of the strncmp in here and keep the
> glob matching only?

That would break existing command lines. Not a good idea.


I hoped that only you guys are using this and would rewrite your 
scripts ;-)


I had no idea there's fnmatch func before.. too bad, ok

jirka


An option to keep backward compatibility and consistency would be
to wrap the pattern/string passed in *'s, that way we can just use
fnmatch and have all the examples Jiri brought up work the same.
With that in place we can actually also drop the explicit ignoring
of the uncore_ prefix since the globbing would take care of that.

Thoughts?

Agustín

--
Qualcomm Datacenter Technologies, Inc. on behalf of the Qualcomm 
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a 
Linux Foundation Collaborative Project.

Re: [PATCH 5/6] dma-mapping: support fsl-mc bus

[Christoph Hellwig]

We should not add any new hardocded busses here.  Please mark them in
OF/ACPI.

Re: [PATCH v1 18/19] arm: dts: mt7623: add MT7623A reference boards

[Sean Wang]

On Mon, 2018-03-05 at 08:10 -0600, Rob Herring wrote:
> On Fri, Mar 2, 2018 at 8:15 PM, Sean Wang  wrote:
> > On Fri, 2018-03-02 at 09:45 -0600, Rob Herring wrote:
> >> On Fri, Feb 23, 2018 at 06:16:38PM +0800, sean.w...@mediatek.com wrote:
> >> > From: Sean Wang 
> >> >
> >> > Add mt7623a-rfb.dtsi where most nodes can be inherited from
> >> > mt7623n-rfb.dtsi and keep these distinctions from MT7623A boards in
> >> > mt7623a-rfb.dtsi for most definition can be reused among MT7623A board
> >> > variants.
> >> >
> >> > MT7623A has its specific definition of power domain and thus we need
> >> > to change related devices such as audio, ethernet, crypto, high-speed
> >> > DMA, NAND, and USB controller to the power domain they specifically
> >> > belong to. In addition, MT7530 exists as built-in module inside MT7623A
> >> > SoC and I2C2 and UART[0-1] get being removed and UART2 have distinct pin
> >> > usage. Those all differences can be totally seen in mt7623a-rfb.dtsi.
> >> >
> >> > Signed-off-by: Sean Wang 
> >> > ---
> >> >  arch/arm/boot/dts/Makefile |  2 +
> >> >  arch/arm/boot/dts/mt7623a-rfb-emmc.dts | 22 +
> >> >  arch/arm/boot/dts/mt7623a-rfb-nand.dts | 26 +++
> >> >  arch/arm/boot/dts/mt7623a-rfb.dtsi | 84 
> >> > ++
> >> >  arch/arm/boot/dts/mt7623n-rfb.dtsi | 15 ++
> >> >  5 files changed, 149 insertions(+)
> >> >  create mode 100644 arch/arm/boot/dts/mt7623a-rfb-emmc.dts
> >> >  create mode 100644 arch/arm/boot/dts/mt7623a-rfb-nand.dts
> >> >  create mode 100644 arch/arm/boot/dts/mt7623a-rfb.dtsi
> >> >
> >> > diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> >> > index 5af6fce..818817c 100644
> >> > --- a/arch/arm/boot/dts/Makefile
> >> > +++ b/arch/arm/boot/dts/Makefile
> >> > @@ -1122,6 +1122,8 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += \
> >> > mt6580-evbp1.dtb \
> >> > mt6589-aquaris5.dtb \
> >> > mt6592-evb.dtb \
> >> > +   mt7623a-rfb-emmc.dtb \
> >> > +   mt7623a-rfb-nand.dtb \
> >> > mt7623n-rfb-emmc.dtb \
> >> > mt7623n-rfb-nand.dtb \
> >> > mt7623n-bananapi-bpi-r2.dtb \
> >> > diff --git a/arch/arm/boot/dts/mt7623a-rfb-emmc.dts 
> >> > b/arch/arm/boot/dts/mt7623a-rfb-emmc.dts
> >> > new file mode 100644
> >> > index 000..ef6398e
> >> > --- /dev/null
> >> > +++ b/arch/arm/boot/dts/mt7623a-rfb-emmc.dts
> >> > @@ -0,0 +1,22 @@
> >> > +// SPDX-License-Identifier: GPL-2.0
> >> > +/*
> >> > + * Copyright (c) 2017-2018 MediaTek Inc.
> >> > + * Author: Sean Wang 
> >> > + *
> >> > + */
> >> > +
> >> > +/dts-v1/;
> >> > +#include "mt7623a-rfb.dtsi"
> >> > +
> >> > +/ {
> >> > +   model = "MediaTek MT7623A with eMMC reference board";
> >> > +   compatible = "mediatek,mt7623a-rfb-emmc", "mediatek,mt7623";
> >> > +
> >> > +   chosen {
> >> > +   bootargs = "console=ttyS0,115200n8 earlyprintk";
> >>
> >> Use stdout-path instead. earlyprintk option only works for a kernel
> >> built with a debug uart at a fixed address, so drop it.
> >>
> >
> > thanks, I will try and have stdout-path instead.
> >
> > But for earlyprintk, our kernel can support and be built with a debug
> > uart at a fixed address and it is greatly useful to know what's going
> > on when a system hang happens on certain device's initialization prior
> > to uart initialization such as PCI device.
> 
> These days, you only need earlyprintk for *really* early console like
> in the assembly boot entry code and before the DT is unflattened. For
> anything else, use earlycon instead because earlycon is a runtime
> option.
> 
> > Thus, I consider to keep it there in special on such kinds of
> > development boards for debugging purpose.
> 
> Then add this option when you are doing debug. But for what's
> "shipped" in mainline, you should not have this enabled.
> 
> Rob

Okay, for these reasons, I will remove earlyprintk usage here
and try to use earlycon instead in the future.

Really thanks for your detailed explanation!

Sean
> 
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek

Re: [PATCH v6] staging: typec: handle vendor defined part and modify drp toggling flow

[李書帆]

Hi,

2018-03-05 22:49 GMT+08:00 Guenter Roeck :
> On 03/04/2018 08:16 PM, ShuFan Lee wrote:
>>
>> From: ShuFan Lee 
>>
>> Handle vendor defined behavior in tcpci_init, tcpci_set_vconn,
>> tcpci_start_drp_toggling
>> and export tcpci_irq. More operations can be extended in tcpci_data if
>> needed.
>> According to TCPCI specification, 4.4.5.2 ROLE_CONTROL,
>> TCPC shall not start DRP toggling until subsequently the TCPM
>> writes to the COMMAND register to start DRP toggling.
>> DRP toggling flow is chagned as following:
>
>
> s/chagned/changed/
Sorry for the type error, I'll correct it in v7.
>
>
>>- Write DRP = 1, Rp level and RC.CCx to Rd/Rd or Rp/Rp
>>- Set LOOK4CONNECTION command
>>
>> Signed-off-by: ShuFan Lee 
>> ---
>>   drivers/staging/typec/tcpci.c | 134
>> ++
>>   drivers/staging/typec/tcpci.h |  15 +
>>   2 files changed, 123 insertions(+), 26 deletions(-)
>>
>>   patch changelogs between v1 & v2
>>   - Remove unnecessary i2c_client in the structure of tcpci
>>   - Rename structure of tcpci_vendor_data to tcpci_data
>>   - Not exporting tcpci read/write wrappers but register i2c regmap in
>> glue driver
>>   - Add set_vconn ops in tcpci_data
>> (It is necessary for RT1711H to enable/disable idle mode before
>> disabling/enabling vconn)
>>   - Export tcpci_irq so that vendor can call it in their own IRQ handler
>>
>>   patch changelogs between v2 & v3
>>   - Change the return type of tcpci_irq from int to irqreturn_t
>>
>>   patch changelogs between v3 & v4
>>   - Directly return regmap_write at the end of drp_toggling function
>>   - Because tcpci_irq is called in _tcpci_irq, move _tcpci_irq to the
>> place after tcpci_irq
>>
>>   patch changelogs between v4 & v5
>>   - Add a space between my first & last name, from ShuFanLee to ShuFan
>> Lee.
>>
>>   patch changelogs between v5 & v6
>>   - Add start_drp_toggling in tcpci_data and call it at the beginning of
>> tcpci_start_drp_toggling
>>   - Modify the flow of tcpci_start_drp_toggling as following
>>  - Set Rp level, RC.CCx to Rd/Rd or Rp/Rp and DRP = 1
>>  - Set LOOK4CONNECTION command
>>
>> diff --git a/drivers/staging/typec/tcpci.c b/drivers/staging/typec/tcpci.c
>> index 9bd4412..9e600f7 100644
>> --- a/drivers/staging/typec/tcpci.c
>> +++ b/drivers/staging/typec/tcpci.c
>> @@ -21,7 +21,6 @@
>> struct tcpci {
>> struct device *dev;
>> -   struct i2c_client *client;
>> struct tcpm_port *port;
>>   @@ -30,6 +29,12 @@ struct tcpci {
>> bool controls_vbus;
>> struct tcpc_dev tcpc;
>> +   struct tcpci_data *data;
>> +};
>> +
>> +struct tcpci_chip {
>> +   struct tcpci *tcpci;
>> +   struct tcpci_data data;
>>   };
>> static inline struct tcpci *tcpc_to_tcpci(struct tcpc_dev *tcpc)
>> @@ -37,8 +42,7 @@ static inline struct tcpci *tcpc_to_tcpci(struct
>> tcpc_dev *tcpc)
>> return container_of(tcpc, struct tcpci, tcpc);
>>   }
>>   -static int tcpci_read16(struct tcpci *tcpci, unsigned int reg,
>> -   u16 *val)
>> +static int tcpci_read16(struct tcpci *tcpci, unsigned int reg, u16 *val)
>>   {
>> return regmap_raw_read(tcpci->regmap, reg, val, sizeof(u16));
>>   }
>> @@ -98,9 +102,19 @@ static int tcpci_set_cc(struct tcpc_dev *tcpc, enum
>> typec_cc_status cc)
>>   static int tcpci_start_drp_toggling(struct tcpc_dev *tcpc,
>> enum typec_cc_status cc)
>>   {
>> +   int ret;
>> struct tcpci *tcpci = tcpc_to_tcpci(tcpc);
>> unsigned int reg = TCPC_ROLE_CTRL_DRP;
>>   + if (tcpci->data) {
>> +   if (tcpci->data->start_drp_toggling) {
>
>
> From the code flow it is guaranteed that ->data is set. It should therefore
> be unnecessary to check for it (we don't check if ->reg is set either).
Ok, I'll modify it in v7, thank you.
>
>
>> +   ret = tcpci->data->start_drp_toggling(tcpci,
>> + tcpci->data,
>> cc);
>> +   if (ret < 0)
>> +   return ret;
>> +   }
>> +   }
>> +
>> switch (cc) {
>> default:
>> case TYPEC_CC_RP_DEF:
>> @@ -117,7 +131,17 @@ static int tcpci_start_drp_toggling(struct tcpc_dev
>> *tcpc,
>> break;
>> }
>>   - return regmap_write(tcpci->regmap, TCPC_ROLE_CTRL, reg);
>> +   if (cc == TYPEC_CC_RD)
>> +   reg |= (TCPC_ROLE_CTRL_CC_RD << TCPC_ROLE_CTRL_CC1_SHIFT)
>> |
>> +  (TCPC_ROLE_CTRL_CC_RD <<
>> TCPC_ROLE_CTRL_CC2_SHIFT);
>> +   else
>> +   reg |= (TCPC_ROLE_CTRL_CC_RP << TCPC_ROLE_CTRL_CC1_SHIFT)
>> |
>> +  (TCPC_ROLE_CTRL_CC_RP <<
>> TCPC_ROLE_CTRL_CC2_SHIFT);
>> +   ret = regmap_write(tcpci->regmap, TCPC_ROLE_CTRL, reg);
>> +   if (ret < 0)
>> +   return ret;
>> +   return regmap_write(tcpci->regmap, TCPC_COMMAND,
>> 

Re: [PATCH] vsprintf: Make "null" pointer dereference more robust

[Rasmus Villemoes]

On 2 March 2018 at 13:53, Petr Mladek  wrote:
> %p has many modifiers where the pointer is dereferenced. An invalid
> pointer might cause kernel to crash silently.
>
> Note that printk() formats the string under logbuf_lock. Any recursive
> printks are redirected to the printk_safe implementation and the messages
> are stored into per-CPU buffers. These buffers might be eventually flushed
> in printk_safe_flush_on_panic() but it is not guaranteed.

Yeah, it's annoying that we can't reliably WARN for bogus vsprintf() uses.

> In general, we should do our best to get useful message from printk().
> All pointers to the first memory page must be invalid. Let's prevent
> the dereference and print "(null)" in this case. This is already done
> in many other situations, including "%s" format handling and many
> page fault handlers.
>
> Signed-off-by: Petr Mladek 
> ---
>  lib/vsprintf.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/vsprintf.c b/lib/vsprintf.c
> index d7a708f82559..5c2d1f44218a 100644
> --- a/lib/vsprintf.c
> +++ b/lib/vsprintf.c
> @@ -1849,7 +1849,7 @@ char *pointer(const char *fmt, char *buf, char *end, 
> void *ptr,
>  {
> const int default_width = 2 * sizeof(void *);
>
> -   if (!ptr && *fmt != 'K' && *fmt != 'x') {
> +   if ((unsigned long)ptr < PAGE_SIZE && *fmt != 'K' && *fmt != 'x') {

ISTM that accidentally passing an ERR_PTR would be just as likely as
passing a NULL pointer (or some small offset from one), so if we do
this, shouldn't the test also cover IS_ERR values?

Rasmus

Re: [PATCH v3] 8250-men-mcb: add support for 16z025 and 16z057

[Andy Shevchenko]

On Mon, Mar 5, 2018 at 10:22 AM, Michael Moese  wrote:
> Add support for two MEN UARTs (16z025 and 16z057) to the
> 8250_men_mcb driver.
> The 16z025 consists of up to four ports, the 16z057 has
> exactly four ports. Apart from that, all of them share the
> Port settings.

> Changes to v2:
> Added include of linux/io.h due to finding of kbuild robot.

Hmm... Is it there?

>  static int serial_8250_men_mcb_probe(struct mcb_device *mdev,
>  const struct mcb_device_id *id)
>  {

> mem = mcb_get_resource(mdev, IORESOURCE_MEM);

> if (mem == NULL)
> return -ENXIO;

Redundant.

> +   membase = devm_ioremap_resource(&mdev->dev, mem);
> +   if (IS_ERR(membase))
> +   return PTR_ERR_OR_ZERO(membase);

> +   for (i = 0; i < num_ports; i++) {

> +   /* ok, register the port */
> +   data[i].line = serial8250_register_8250_port(&data[i].uart);
> +   if (data[i].line < 0) {
> +   dev_err(&mdev->dev, "unable to register UART port\n");
> +   return data[i].line;
> +   }
> +   dev_info(&mdev->dev, "found MCB UART: ttyS%d\n", 
> data[i].line);

Consider to use  struct uart_port::name instead.

> +   }
>
> return 0;
>  }
>
>  static void serial_8250_men_mcb_remove(struct mcb_device *mdev)
>  {

> +   if (!data)
> +   return;

When it's possible?

>  }

-- 
With Best Regards,
Andy Shevchenko

Re: BUG: unable to handle kernel paging request in compat_copy_entries

[Paolo Abeni]

On Mon, 2018-03-05 at 00:21 -0800, syzbot wrote:
> Hello,
> 
> syzbot hit the following crash on upstream commit
> 5fbdefcf685defd8bc5a8f37b17538d25c58d77a (Fri Mar 2 21:05:20 2018 +)
> Merge branch 'parisc-4.16-1' of  
> git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux
> 
> So far this crash happened 5 times on upstream.
> syzkaller reproducer is attached.
> Raw console output is attached.
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached.
> user-space arch: i386
> 
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+5705ba91388d7bc30...@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for  
> details.
> If you forward the report, please keep this part and the footer.
> 
> audit: type=1400 audit(1520098078.492:8): avc:  denied  { map } for   
> pid=4239 comm="syz-execprog" path="/root/syzkaller-shm255959590" dev="sda1"  
> ino=16482 scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023  
> tcontext=unconfined_u:object_r:file_t:s0 tclass=file permissive=1
> IPVS: ftp: loaded support on port[0] = 21
> BUG: unable to handle kernel paging request at c90001819e4f
> IP: ebt_size_mwt net/bridge/netfilter/ebtables.c:2037 [inline]
> IP: size_entry_mwt net/bridge/netfilter/ebtables.c:2122 [inline]
> IP: compat_copy_entries+0x49f/0x1050 net/bridge/netfilter/ebtables.c:2160
> PGD 1dad2f067 P4D 1dad2f067 PUD 1dad30067 PMD 1b2408067 PTE 0
> Oops:  [#1] SMP KASAN
> Dumping ftrace buffer:
> (ftrace buffer empty)
> Modules linked in:
> CPU: 1 PID: 4249 Comm: syz-executor0 Not tainted 4.16.0-rc3+ #248
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
> Google 01/01/2011
> RIP: 0010:ebt_size_mwt net/bridge/netfilter/ebtables.c:2037 [inline]
> RIP: 0010:size_entry_mwt net/bridge/netfilter/ebtables.c:2122 [inline]
> RIP: 0010:compat_copy_entries+0x49f/0x1050  
> net/bridge/netfilter/ebtables.c:2160
> RSP: 0018:8801b34bf7e8 EFLAGS: 00010246
> RAX: 000a RBX: 8801b34bf9d4 RCX: c90001819e4f
> RDX:  RSI:  RDI: 8801b34bf9d8
> RBP: 8801b34bf968 R08:  R09: 
> R10: 88613340 R11: 0001 R12: ee5f
> R13: dc00 R14: 8801b34bf9c8 R15: c90001819e2f
> FS:  () GS:8801db30(0063) knlGS:085b9900
> CS:  0010 DS: 002b ES: 002b CR0: 80050033
> CR2: c90001819e4f CR3: 0001b2bd7003 CR4: 001606e0
> DR0:  DR1:  DR2: 
> DR3:  DR6: fffe0ff0 DR7: 0400
> Call Trace:
>   compat_do_replace+0x398/0x7c0 net/bridge/netfilter/ebtables.c:2249
>   compat_do_ebt_set_ctl+0x22a/0x2d0 net/bridge/netfilter/ebtables.c:2330
>   compat_nf_sockopt net/netfilter/nf_sockopt.c:144 [inline]
>   compat_nf_setsockopt+0x88/0x130 net/netfilter/nf_sockopt.c:156
>   compat_ip_setsockopt+0x8b/0xd0 net/ipv4/ip_sockglue.c:1285
>   inet_csk_compat_setsockopt+0x95/0x120 net/ipv4/inet_connection_sock.c:1041
>   compat_tcp_setsockopt+0x3d/0x70 net/ipv4/tcp.c:2916
>   compat_sock_common_setsockopt+0xb2/0x140 net/core/sock.c:2986
>   C_SYSC_setsockopt net/compat.c:403 [inline]
>   compat_SyS_setsockopt+0x17c/0x410 net/compat.c:386
>   do_syscall_32_irqs_on arch/x86/entry/common.c:330 [inline]
>   do_fast_syscall_32+0x3ec/0xf9f arch/x86/entry/common.c:392
>   entry_SYSENTER_compat+0x70/0x7f arch/x86/entry/entry_64_compat.S:139
> RIP: 0023:0xf7fbbc99
> RSP: 002b:ffd5ab8c EFLAGS: 0286 ORIG_RAX: 016e
> RAX: ffda RBX: 0003 RCX: 
> RDX: 0080 RSI: 2280 RDI: 0208
> RBP:  R08:  R09: 
> R10:  R11:  R12: 
> R13:  R14:  R15: 
> Code: 8d 4f 20 48 89 c8 48 89 8d c8 fe ff ff 48 c1 e8 03 42 0f b6 14 28 48  
> 89 c8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 b2 0a 00 00 <45> 8b 67 20  
> 44 39 a5 04 ff ff ff 0f 82 bd 08 00 00 e8 cb 52 56
> RIP: ebt_size_mwt net/bridge/netfilter/ebtables.c:2037 [inline] RSP:  
> 8801b34bf7e8
> RIP: size_entry_mwt net/bridge/netfilter/ebtables.c:2122 [inline] RSP:  
> 8801b34bf7e8
> RIP: compat_copy_entries+0x49f/0x1050 net/bridge/netfilter/ebtables.c:2160  
> RSP: 8801b34bf7e8
> CR2: c90001819e4f
> ---[ end trace cf111332eb971f16 ]---
> 
> 
> ---
> This bug is generated by a dumb bot. It may contain errors.
> See https://goo.gl/tpsmEJ for details.
> Direct all questions to syzkal...@googlegroups.com.
> 
> syzbot will keep track of this bug report.
> If you forgot to add the Reported-by tag, once the fix for this bug is  
> merged
> into any tree, please reply to this email with:
> #syz fix: exact-commit-title
> If you want to test a patch for this bug, please reply with:
> #syz tes

Re: [PATCH v2 1/1] HID: Logitech K290: Add driver for the Logitech K290 USB keyboard

[kbuild test robot]

Hi Florent,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on hid/for-next]
[also build test WARNING on v4.16-rc4 next-20180305]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Florent-Flament/Logitech-K290-Add-driver-for-the-Logitech-K290-USB-keyboard/20180305-153311
base:   https://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid.git for-next
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

>> drivers/hid/hid-logitech-k290.c:54:46: sparse: Using plain integer as NULL 
>> pointer

vim +54 drivers/hid/hid-logitech-k290.c

45  
46  static void k290_set_function(struct usb_device *dev, uint16_t 
function_mode)
47  {
48  int ret;
49  
50  ret = usb_control_msg(dev, usb_sndctrlpipe(dev, 0),
51K290_SET_FUNCTION_CMD,
52USB_DIR_OUT | USB_TYPE_VENDOR | 
USB_RECIP_DEVICE,
53K290_SET_FUNCTION_VAL,
  > 54function_mode, 0, 0, 
USB_CTRL_SET_TIMEOUT);
55  
56  if (ret < 0)
57  dev_err(&dev->dev,
58  "Failed to setup K290 function key, error 
%d\n", ret);
59  }
60  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation

Re: [PATCH v3] 8250-men-mcb: add support for 16z025 and 16z057

[Michael Moese]

Hi, sorry.. my bad. Not my day today. I forgot to commit :/

I'll resend.

On Mon, Mar 05, 2018 at 05:17:04PM +0200, Andy Shevchenko wrote:
> On Mon, Mar 5, 2018 at 10:22 AM, Michael Moese  wrote:
> > Add support for two MEN UARTs (16z025 and 16z057) to the
> > 8250_men_mcb driver.
> > The 16z025 consists of up to four ports, the 16z057 has
> > exactly four ports. Apart from that, all of them share the
> > Port settings.
> 
> > Changes to v2:
> > Added include of linux/io.h due to finding of kbuild robot.
> 
> Hmm... Is it there?
> 
> >  static int serial_8250_men_mcb_probe(struct mcb_device *mdev,
> >  const struct mcb_device_id *id)
> >  {
> 
> > mem = mcb_get_resource(mdev, IORESOURCE_MEM);
> 
> > if (mem == NULL)
> > return -ENXIO;
> 
> Redundant.
> 
> > +   membase = devm_ioremap_resource(&mdev->dev, mem);
> > +   if (IS_ERR(membase))
> > +   return PTR_ERR_OR_ZERO(membase);
> 
> > +   for (i = 0; i < num_ports; i++) {
> 
> > +   /* ok, register the port */
> > +   data[i].line = serial8250_register_8250_port(&data[i].uart);
> > +   if (data[i].line < 0) {
> > +   dev_err(&mdev->dev, "unable to register UART 
> > port\n");
> > +   return data[i].line;
> > +   }
> > +   dev_info(&mdev->dev, "found MCB UART: ttyS%d\n", 
> > data[i].line);
> 
> Consider to use  struct uart_port::name instead.
> 
> > +   }
> >
> > return 0;
> >  }
> >
> >  static void serial_8250_men_mcb_remove(struct mcb_device *mdev)
> >  {
> 
> > +   if (!data)
> > +   return;
> 
> When it's possible?
> 
> >  }
> 
> -- 
> With Best Regards,
> Andy Shevchenko


-- 
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)

[PATCH v3] 8250-men-mcb: add support for 16z025 and 16z057

[Michael Moese]

Add support for two MEN UARTs (16z025 and 16z057) to the
8250_men_mcb driver.
The 16z025 consists of up to four ports, the 16z057 has
exactly four ports. Apart from that, all of them share the
Port settings.

Signed-off-by: Michael Moese 
Reported-by: Ben Turner 
Tested-by: Ben Turner 

---
Sorry for the resend, I messed up the previoius patch..

Changes to v2:
Added include of linux/io.h due to finding of kbuild robot.

Changes to v1:
Deduplicated the two switch() blocks into a function returning
the number of ports.
Minor style corrections.
---
 drivers/tty/serial/8250/8250_men_mcb.c | 125 -
 drivers/tty/serial/8250/Kconfig|   5 +-
 2 files changed, 94 insertions(+), 36 deletions(-)

diff --git a/drivers/tty/serial/8250/8250_men_mcb.c 
b/drivers/tty/serial/8250/8250_men_mcb.c
index 308977807994..127017cc41d9 100644
--- a/drivers/tty/serial/8250/8250_men_mcb.c
+++ b/drivers/tty/serial/8250/8250_men_mcb.c
@@ -1,12 +1,19 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 
+#define MEN_UART_ID_Z025 0x19
+#define MEN_UART_ID_Z057 0x39
+#define MEN_UART_ID_Z125 0x7d
+
+#define MEN_UART_MEM_SIZE 0x10
+
 struct serial_8250_men_mcb_data {
struct uart_8250_port uart;
int line;
@@ -18,7 +25,7 @@ struct serial_8250_men_mcb_data {
  * parameter in order to really set the correct baudrate, and
  * do so if possible without user interaction
  */
-static u32 men_z125_lookup_uartclk(struct mcb_device *mdev)
+static u32 men_lookup_uartclk(struct mcb_device *mdev)
 {
/* use default value if board is not available below */
u32 clkval = 1041666;
@@ -28,10 +35,12 @@ static u32 men_z125_lookup_uartclk(struct mcb_device *mdev)
mdev->bus->name);
if  (strncmp(mdev->bus->name, "F075", 4) == 0)
clkval = 1041666;
-   else if  (strncmp(mdev->bus->name, "F216", 4) == 0)
+   else if (strncmp(mdev->bus->name, "F216", 4) == 0)
clkval = 1843200;
else if (strncmp(mdev->bus->name, "G215", 4) == 0)
clkval = 1843200;
+   else if (strncmp(mdev->bus->name, "F210", 4) == 0)
+   clkval = 115200;
else
dev_info(&mdev->dev,
 "board not detected, using default uartclk\n");
@@ -41,62 +50,108 @@ static u32 men_z125_lookup_uartclk(struct mcb_device *mdev)
return clkval;
 }
 
+static unsigned int get_num_ports(struct mcb_device *mdev,
+ void __iomem *membase)
+{
+   switch (mdev->id) {
+   case MEN_UART_ID_Z125:
+   return 1U;
+   case MEN_UART_ID_Z025:
+   return readb(membase) >> 4;
+   case MEN_UART_ID_Z057:
+   return 4U;
+   default:
+   dev_err(&mdev->dev, "no supported device!\n");
+   return -ENODEV;
+   }
+}
+
 static int serial_8250_men_mcb_probe(struct mcb_device *mdev,
 const struct mcb_device_id *id)
 {
struct serial_8250_men_mcb_data *data;
struct resource *mem;
-
-   data = devm_kzalloc(&mdev->dev,
-   sizeof(struct serial_8250_men_mcb_data),
-   GFP_KERNEL);
-   if (!data)
-   return -ENOMEM;
-
-   mcb_set_drvdata(mdev, data);
-   data->uart.port.dev = mdev->dma_dev;
-   spin_lock_init(&data->uart.port.lock);
-
-   data->uart.port.type = PORT_16550;
-   data->uart.port.flags = UPF_SKIP_TEST | UPF_SHARE_IRQ | UPF_FIXED_TYPE;
-   data->uart.port.iotype = UPIO_MEM;
-   data->uart.port.uartclk = men_z125_lookup_uartclk(mdev);
-   data->uart.port.regshift = 0;
-   data->uart.port.fifosize = 60;
+   unsigned int num_ports;
+   unsigned int i;
+   void __iomem *membase;
 
mem = mcb_get_resource(mdev, IORESOURCE_MEM);
if (mem == NULL)
return -ENXIO;
+   membase = devm_ioremap_resource(&mdev->dev, mem);
+   if (IS_ERR(membase))
+   return PTR_ERR_OR_ZERO(membase);
 
-   data->uart.port.irq = mcb_get_irq(mdev);
+   num_ports = get_num_ports(mdev, membase);
 
-   data->uart.port.membase = devm_ioremap_resource(&mdev->dev, mem);
-   if (IS_ERR(data->uart.port.membase))
-   return PTR_ERR_OR_ZERO(data->uart.port.membase);
+   dev_dbg(&mdev->dev, "found a 16z%03u with %u ports\n",
+   mdev->id, num_ports);
 
-   data->uart.port.mapbase = (unsigned long) mem->start;
-   data->uart.port.iobase = data->uart.port.mapbase;
+   if (num_ports == 0 || num_ports > 4) {
+   dev_err(&mdev->dev, "unexpected number of ports: %u\n",
+   num_ports);
+   return -ENODEV;
+   }
 
-   /* ok, register the port */
-   data->line = serial8250_register_8250_port(&data->uart);
-   if (data->line < 0)
-   return data->line;
+   data = devm

Re: [PATCH] vsprintf: Make "null" pointer dereference more robust

[Andy Shevchenko]

On Mon, 2018-03-05 at 16:16 +0100, Rasmus Villemoes wrote:
> On 2 March 2018 at 13:53, Petr Mladek  wrote:

> > -   if (!ptr && *fmt != 'K' && *fmt != 'x') {
> > +   if ((unsigned long)ptr < PAGE_SIZE && *fmt != 'K' && *fmt !=
> > 'x') {
> 
> ISTM that accidentally passing an ERR_PTR would be just as likely as
> passing a NULL pointer (or some small offset from one), so if we do
> this, shouldn't the test also cover IS_ERR values?

We (will) have such check in two places, perhaps a helper

static bool is_pointer_valid(void *ptr)
{
  return !IS_ERR(ptr) && (unsigned long)ptr >= PAGE_SIZE;
}

?

-- 
Andy Shevchenko 
Intel Finland Oy

Re: [PATCH] arm64: dts: stratix10: enable i2c, add i2c periperals

[Dinh Nguyen]

Hi Alan,

On 02/21/2018 02:25 PM, Alan Tull wrote:
> Add clock for i2c
> Enable i2c1
> Set the i2c bus speed to 100KHz
> Add the following i2c peripherals
> * ds1339 RTC
> * 24c32 EEPROM
> * max1619 temperature monitor
> * ltc2497 ADC
>   * Add a fixed regulator for the ADC's Vref.
> 
> This requires Dinh Nguyen's Stratix10 clock driver
> ("clk: socfpga: stratix10: add clock driver for Stratix10 platform")
> 

Thanks for the patch! I've staged this patch based on the clock driver
patch.

Dinh

Re: [PATCH v2 1/2] dmaengine: Introduce DW AXI DMAC driver

[Eugeniy Paltsev]

On Mon, 2018-02-26 at 18:42 +0200, Andy Shevchenko wrote:
> On Mon, Feb 26, 2018 at 4:56 PM, Eugeniy Paltsev
>  wrote:
> > +static int parse_device_properties(struct axi_dma_chip *chip)
> > +{
> > +   ret = device_property_read_u32(dev, "snps,dma-masters", &tmp);
> 
> Why it has prefix?
> 
> > +   ret = device_property_read_u32(dev, "snps,data-width", &tmp);
> 
> Ditto.
> 
> > +   ret = device_property_read_u32_array(dev, "snps,block-size", carr,
> > +chip->dw->hdata->nr_channels);
> 
> (perhaps this one can be moved outside of local namespace)
> 
> > +   ret = device_property_read_u32_array(dev, "snps,priority", carr,
> > +chip->dw->hdata->nr_channels);
> 
> Can you use just "priority"?
> 
> 

Rob Herring asked me to add vendor prefix to this properties.
See http://patchwork.ozlabs.org/patch/719708/

>8--
> > +Required properties:
> > +- compatible: "snps,axi-dma"
> 
> Too generic. This needs an IP version at least.
> 
> > +- reg: Address range of the DMAC registers. This should include
> > +  all of the per-channel registers.
> > +- interrupt: Should contain the DMAC interrupt number.
> > +- interrupt-parent: Should be the phandle for the interrupt controller
> > +  that services interrupts for this device.
> > +- dma-channels: Number of channels supported by hardware.
> > +- dma-masters: Number of AXI masters supported by the hardware.
> > +- data-width: Maximum AXI data width supported by hardware.
> > +  (0 - 8bits, 1 - 16bits, 2 - 32bits, ..., 6 - 512bits)
> 
> > +- priority: Priority of channel. Array property. Priority value must be
> > +  programmed within [0:dma-channels-1] range. (0 - minimum priority)
> > +- block-size: Maximum block size supported by the controller channel. Array
> > +  property.
> 
> Other than dma-channels, all these either need vendor prefix.
> 
>8--



On Fri, 2018-03-02 at 13:44 +0530, Vinod Koul wrote:
> On Mon, Feb 26, 2018 at 05:56:28PM +0300, Eugeniy Paltsev wrote:
> > +dmac: dma-controller@8 {
> > +   compatible = "snps,axi-dma-1.01a";
> 
> do we need "snps here..?
> 

Ditto.

-- 
 Eugeniy Paltsev