Re: linux-next: manual merge of the mlx5-next tree with the rdma tree

2020-05-13 Thread Leon Romanovsky
On Thu, May 14, 2020 at 12:59:20PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the mlx5-next tree got a conflict in:
>
>   drivers/infiniband/hw/mlx5/main.c
>
> between commit:
>
>   2be08c308f10 ("RDMA/mlx5: Delete create QP flags obfuscation")
>
> from the rdma tree and commit:
>
>   14c129e30152 ("{IB/net}/mlx5: Simplify don't trap code")
>
> from the mlx5-next tree.
>
> I fixed it up (the latter change included the former) and can carry the
> fix as necessary. This is now fixed as far as linux-next is concerned,
> but any non trivial conflicts should be mentioned to your upstream
> maintainer when your tree is submitted for merging.  You may also want
> to consider cooperating with the maintainer of the conflicting tree to
> minimise any particularly complex conflicts.

Thanks Stephen,

The mlx5-next branch was merged to rdma-next tonight and this conflict
will disappear in next the linux-next.

Thanks

>
> --
> Cheers,
> Stephen Rothwell




signature.asc
Description: PGP signature


Re: [PATCH v13 3/8] iommu/vt-d: Add nested translation helper function

2020-05-13 Thread Christoph Hellwig
> +  * 1. CPU vs. IOMMU
> +  * 2. Guest vs. Host.
> +  */
> + switch (addr_width) {
> +#ifdef CONFIG_X86
> + case ADDR_WIDTH_5LEVEL:
> + if (cpu_feature_enabled(X86_FEATURE_LA57) &&
> + cap_5lp_support(iommu->cap)) {
> + pasid_set_flpm(pte, 1);
> + } else {
> + dev_err_ratelimited(dev, "5-level paging not 
> supported\n");
> + return -EINVAL;
> + }
> + break;

The normal style would be to handle the early error return first:

if (!cpu_feature_enabled(X86_FEATURE_LA57) ||
!cap_5lp_support(iommu->cap)) {
dev_err_ratelimited(dev,
"5-level paging not supported\n");
return -EINVAL;
}

pasid_set_flpm(pte, 1);
break;



Re: [PATCH v13 2/8] iommu/vt-d: Use a helper function to skip agaw for SL

2020-05-13 Thread Christoph Hellwig
On Wed, May 13, 2020 at 04:01:43PM -0700, Jacob Pan wrote:
> An Intel iommu domain uses 5-level page table by default. If the
> iommu that the domain tries to attach supports less page levels,
> the top level page tables should be skipped. Add a helper to do
> this so that it could be used in other places.

Please use up all 73 chars for the commit log.


Re: [PATCH] Revert "mmc: sdhci-xenon: add runtime pm support and reimplement standby"

2020-05-13 Thread Jisheng Zhang
On Wed, 13 May 2020 14:15:21 +0200 Ulf Hansson wrote:

> 
> 
> On Wed, 13 May 2020 at 11:47, Jisheng Zhang  
> wrote:
> >
> > This reverts commit a027b2c5fed78851e69fab395b02d127a7759fc7.
> >
> > The HW supports auto clock gating, so it's useless to do runtime pm
> > in software.  
> 
> Runtime PM isn't soley about clock gating. Moreover it manages the

Per my understanding, current xenon rpm implementation is just clock gating.

> "pltfm_host->clk", which means even if the controller supports auto
> clock gating, gating/ungating the externally provided clock still
> makes sense.

   clock ---  xenon IP
  |___ rpm   |__ HW Auto clock gate

Per my understanding, with rpm, both clock and IP is clock gated; while with
Auto clock gate, the IP is clock gated. So the only difference is clock itself.
Considering the gain(suspect we have power consumption gain, see below), the
pay -- 56 LoCs and latency doesn't deserve gain.

Even if considering from power consumption POV, sdhci_runtime_suspend_host(),
sdhci_runtime_resume_host(), and the retune process could be more than the clock
itself.


> 
> Kind regards
> Uffe
> 
> >
> > Signed-off-by: Jisheng Zhang 
> > ---
> >  drivers/mmc/host/sdhci-xenon.c | 87 +++---
> >  drivers/mmc/host/sdhci-xenon.h |  1 -
> >  2 files changed, 16 insertions(+), 72 deletions(-)
> >
> > diff --git a/drivers/mmc/host/sdhci-xenon.c b/drivers/mmc/host/sdhci-xenon.c
> > index 4703cd540c7f..85414e13e7ea 100644
> > --- a/drivers/mmc/host/sdhci-xenon.c
> > +++ b/drivers/mmc/host/sdhci-xenon.c
> > @@ -15,8 +15,6 @@
> >  #include 
> >  #include 
> >  #include 
> > -#include 
> > -#include 
> >
> >  #include "sdhci-pltfm.h"
> >  #include "sdhci-xenon.h"
> > @@ -539,24 +537,13 @@ static int xenon_probe(struct platform_device *pdev)
> > if (err)
> > goto err_clk_axi;
> >
> > -   pm_runtime_get_noresume(>dev);
> > -   pm_runtime_set_active(>dev);
> > -   pm_runtime_set_autosuspend_delay(>dev, 50);
> > -   pm_runtime_use_autosuspend(>dev);
> > -   pm_runtime_enable(>dev);
> > -   pm_suspend_ignore_children(>dev, 1);
> > -
> > err = sdhci_add_host(host);
> > if (err)
> > goto remove_sdhc;
> >
> > -   pm_runtime_put_autosuspend(>dev);
> > -
> > return 0;
> >
> >  remove_sdhc:
> > -   pm_runtime_disable(>dev);
> > -   pm_runtime_put_noidle(>dev);
> > xenon_sdhc_unprepare(host);
> >  err_clk_axi:
> > clk_disable_unprepare(priv->axi_clk);
> > @@ -573,10 +560,6 @@ static int xenon_remove(struct platform_device *pdev)
> > struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> > struct xenon_priv *priv = sdhci_pltfm_priv(pltfm_host);
> >
> > -   pm_runtime_get_sync(>dev);
> > -   pm_runtime_disable(>dev);
> > -   pm_runtime_put_noidle(>dev);
> > -
> > sdhci_remove_host(host, 0);
> >
> > xenon_sdhc_unprepare(host);
> > @@ -593,78 +576,40 @@ static int xenon_suspend(struct device *dev)
> >  {
> > struct sdhci_host *host = dev_get_drvdata(dev);
> > struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> > -   struct xenon_priv *priv = sdhci_pltfm_priv(pltfm_host);
> > int ret;
> >
> > -   ret = pm_runtime_force_suspend(dev);
> > +   ret = sdhci_suspend_host(host);
> > +   if (ret)
> > +   return ret;
> >
> > -   priv->restore_needed = true;
> > +   clk_disable_unprepare(pltfm_host->clk);
> > return ret;
> >  }
> > -#endif
> >
> > -#ifdef CONFIG_PM
> > -static int xenon_runtime_suspend(struct device *dev)
> > +static int xenon_resume(struct device *dev)
> >  {
> > struct sdhci_host *host = dev_get_drvdata(dev);
> > struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> > -   struct xenon_priv *priv = sdhci_pltfm_priv(pltfm_host);
> > int ret;
> >
> > -   ret = sdhci_runtime_suspend_host(host);
> > +   ret = clk_prepare_enable(pltfm_host->clk);
> > if (ret)
> > return ret;
> >
> > -   if (host->tuning_mode != SDHCI_TUNING_MODE_3)
> > -   mmc_retune_needed(host->mmc);
> > -
> > -   clk_disable_unprepare(pltfm_host->clk);
> > /*
> > -* Need to update the priv->clock here, or when runtime resume
> > -* back, phy don't aware the clock change and won't adjust phy
> > -* which will cause cmd err
> > +* If SoCs power off the entire Xenon, registers setting will
> > +* be lost.
> > +* Re-configure Xenon specific register to enable current SDHC
> >  */
> > -   priv->clock = 0;
> > -   return 0;
> > -}
> > -
> > -static int xenon_runtime_resume(struct device *dev)
> > -{
> > -   struct sdhci_host *host = dev_get_drvdata(dev);
> > -   struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> > -   struct xenon_priv *priv = sdhci_pltfm_priv(pltfm_host);
> > -   int ret;
> > 

Re: [PATCH v4 3/4] perf stat: Copy counts from prev_raw_counts to evsel->counts

2020-05-13 Thread Jin, Yao

Hi Jiri,

On 5/13/2020 11:31 PM, Jiri Olsa wrote:

On Fri, May 08, 2020 at 03:58:16PM +0800, Jin Yao wrote:

It would be useful to support the overall statistics for perf-stat
interval mode. For example, report the summary at the end of
"perf-stat -I" output.

But since perf-stat can support many aggregation modes, such as
--per-thread, --per-socket, -M and etc, we need a solution which
doesn't bring much complexity.

The idea is to use 'evsel->prev_raw_counts' which is updated in
each interval and it's saved with the latest counts. Before reporting
the summary, we copy the counts from evsel->prev_raw_counts to
evsel->counts, and next we just follow non-interval processing.

In evsel__compute_deltas, this patch saves counts to the member
[cpu0,thread0] of perf_counts for AGGR_GLOBAL.

That's because after copying evsel->prev_raw_counts to evsel->counts,
perf_counts(evsel->counts, cpu, thread) are all 0 for AGGR_GLOBAL.
Once we go to process_counter_maps again, all members of perf_counts
are 0.

So this patch uses a trick that saves the previous aggr value to
the member [cpu0,thread0] of perf_counts, then aggr calculation
in process_counter_values can work correctly.

  v4:
  ---
  Change the commit message.
  No functional change.

Signed-off-by: Jin Yao 
---
  tools/perf/util/evsel.c |  1 +
  tools/perf/util/stat.c  | 24 
  tools/perf/util/stat.h  |  1 +
  3 files changed, 26 insertions(+)

diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index 28683b0eb738..6fae1ec28886 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -1283,6 +1283,7 @@ void evsel__compute_deltas(struct evsel *evsel, int cpu, 
int thread,
if (cpu == -1) {
tmp = evsel->prev_raw_counts->aggr;
evsel->prev_raw_counts->aggr = *count;
+   *perf_counts(evsel->prev_raw_counts, 0, 0) = *count;


ok, I think I understand that now.. it's only for AGGR_GLOBAL mode,
because the perf_stat_process_counter will create aggr values from
per cpu values

but why do we need to do that all the time? can't we just set it up
before you zero prev_raw_counts in next patch?


 if (interval) {
 stat_config.interval = 0;
 stat_config.summary = true;
 perf_evlist__copy_prev_raw_counts(evsel_list);

-> for AGGR_GLOBAL set the counts[0,0] to prev_raw_counts->aggr

 perf_evlist__reset_prev_raw_counts(evsel_list);
 runtime_stat_reset(_config);
 perf_stat__reset_shadow_per_stat(_stat);
 }




Yes, I think that's a good idea.

Now in v5, I create a new patch "perf stat: Save aggr value to first member of 
prev_raw_counts" to save aggr value to first member of prev_raw_counts for 
AGGR_GLOBAL. Then next, perf_stat_process_counter can create aggr values from 
per cpu values successfully.


Thanks
Jin Yao



thanks,
jirka



Re: [PATCH v5 2/6] spi: spi-geni-qcom: Use OPP API to set clk/perf state

2020-05-13 Thread Bjorn Andersson
On Wed 13 May 22:03 PDT 2020, Rajendra Nayak wrote:

> 
> []..
> 
> > >   spi->bus_num = -1;
> > >   spi->dev.of_node = dev->of_node;
> > > @@ -596,6 +607,9 @@ static int spi_geni_probe(struct platform_device 
> > > *pdev)
> > >   spi_geni_probe_runtime_disable:
> > >   pm_runtime_disable(dev);
> > >   spi_master_put(spi);
> > > + if (mas->se.has_opp_table)
> > 
> > Why do you need has_opp_table?
> > 
> > Afaict if dev_pm_opp_of_add_table() returns -ENODEV there's no attached
> > opp-table and dev_pm_opp_of_remove_table() is a nop.
> 
> Apparently its not. Calling dev_pm_opp_of_remove_table() when 
> dev_pm_opp_of_add_table()
> failed causes use-count mismatch.
> You can see https://lkml.org/lkml/2020/4/15/18 for more details.
> 

Must have missed that when I glanced at the code, thanks for clarifying.

Regards,
Bjorn

> -- 
> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
> of Code Aurora Forum, hosted by The Linux Foundation


[PATCH v5 2/5] perf counts: Reset prev_raw_counts counts

2020-05-13 Thread Jin Yao
When we want to reset the evsel->prev_raw_counts, zeroing the aggr
is not enough, we need to reset the perf_counts too.

The perf_counts__reset zeros the perf_counts, and it should zero
the aggr too. This patch changes perf_counts__reset to non-static,
and calls it in evsel__reset_prev_raw_counts to reset the
prev_raw_counts.

 v4:
 ---
 Zeroing the aggr in perf_counts__reset and use it to reset
 prev_raw_counts.

Signed-off-by: Jin Yao 
---
 tools/perf/util/counts.c | 4 +++-
 tools/perf/util/counts.h | 1 +
 tools/perf/util/stat.c   | 7 ++-
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/tools/perf/util/counts.c b/tools/perf/util/counts.c
index 615c9f3e95cb..582f3aeaf5e4 100644
--- a/tools/perf/util/counts.c
+++ b/tools/perf/util/counts.c
@@ -1,6 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0
 #include 
 #include 
+#include 
 #include "evsel.h"
 #include "counts.h"
 #include 
@@ -42,10 +43,11 @@ void perf_counts__delete(struct perf_counts *counts)
}
 }
 
-static void perf_counts__reset(struct perf_counts *counts)
+void perf_counts__reset(struct perf_counts *counts)
 {
xyarray__reset(counts->loaded);
xyarray__reset(counts->values);
+   memset(>aggr, 0, sizeof(struct perf_counts_values));
 }
 
 void evsel__reset_counts(struct evsel *evsel)
diff --git a/tools/perf/util/counts.h b/tools/perf/util/counts.h
index 8f556c6d98fa..7ff36bf6d644 100644
--- a/tools/perf/util/counts.h
+++ b/tools/perf/util/counts.h
@@ -37,6 +37,7 @@ perf_counts__set_loaded(struct perf_counts *counts, int cpu, 
int thread, bool lo
 
 struct perf_counts *perf_counts__new(int ncpus, int nthreads);
 void perf_counts__delete(struct perf_counts *counts);
+void perf_counts__reset(struct perf_counts *counts);
 
 void evsel__reset_counts(struct evsel *evsel);
 int evsel__alloc_counts(struct evsel *evsel, int ncpus, int nthreads);
diff --git a/tools/perf/util/stat.c b/tools/perf/util/stat.c
index f4a44df9b221..e397815f0dfb 100644
--- a/tools/perf/util/stat.c
+++ b/tools/perf/util/stat.c
@@ -163,11 +163,8 @@ static void evsel__free_prev_raw_counts(struct evsel 
*evsel)
 
 static void evsel__reset_prev_raw_counts(struct evsel *evsel)
 {
-   if (evsel->prev_raw_counts) {
-   evsel->prev_raw_counts->aggr.val = 0;
-   evsel->prev_raw_counts->aggr.ena = 0;
-   evsel->prev_raw_counts->aggr.run = 0;
-   }
+   if (evsel->prev_raw_counts)
+   perf_counts__reset(evsel->prev_raw_counts);
 }
 
 static int evsel__alloc_stats(struct evsel *evsel, bool alloc_raw)
-- 
2.17.1



[PATCH v5 1/5] perf stat: Fix wrong per-thread runtime stat for interval mode

2020-05-13 Thread Jin Yao
root@kbl-ppc:~# perf stat --per-thread -e cycles,instructions -I1000 
--interval-count 2
 1.004171683 perf-3696  8,747,311  cycles
...
 1.004171683 perf-3696691,730  instructions 
 #0.08  insn per cycle
...
 2.006490373 perf-3696  1,749,936  cycles
...
 2.006490373 perf-3696  1,484,582  instructions 
 #0.28  insn per cycle
...

Let's see interval 2.006490373

perf-3696  1,749,936  cycles
perf-3696  1,484,582  instructions  #0.28  insn 
per cycle

insn per cycle = 1,484,582 / 1,749,936 = 0.85.
But now it's 0.28, that's not correct.

stat_config.stats[] records the per-thread runtime stat. But for interval
mode, it should be reset for each interval.

So now, with this patch,

root@kbl-ppc:~# perf stat --per-thread -e cycles,instructions -I1000 
--interval-count 2
 1.005818121 perf-8633  9,898,045  cycles
...
 1.005818121 perf-8633693,298  instructions 
 #0.07  insn per cycle
...
 2.007863743 perf-8633  1,551,619  cycles
...
 2.007863743 perf-8633  1,317,514  instructions 
 #0.85  insn per cycle
...

Let's check interval 2.007863743.

insn per cycle = 1,317,514 / 1,551,619 = 0.85. It's correct.

This patch creates runtime_stat_reset, places it next to
untime_stat_new/runtime_stat_delete and moves all runtime_stat
functions before process_interval.

 v4:
 ---
 Create runtime_stat_reset.

Fixes: commit 14e72a21c783 ("perf stat: Update or print per-thread stats")
Signed-off-by: Jin Yao 
---
 tools/perf/builtin-stat.c | 70 +++
 1 file changed, 41 insertions(+), 29 deletions(-)

diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index e0c1ad23c768..f3b3a59ac7d2 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -351,6 +351,46 @@ static void read_counters(struct timespec *rs)
}
 }
 
+static int runtime_stat_new(struct perf_stat_config *config, int nthreads)
+{
+   int i;
+
+   config->stats = calloc(nthreads, sizeof(struct runtime_stat));
+   if (!config->stats)
+   return -1;
+
+   config->stats_num = nthreads;
+
+   for (i = 0; i < nthreads; i++)
+   runtime_stat__init(>stats[i]);
+
+   return 0;
+}
+
+static void runtime_stat_delete(struct perf_stat_config *config)
+{
+   int i;
+
+   if (!config->stats)
+   return;
+
+   for (i = 0; i < config->stats_num; i++)
+   runtime_stat__exit(>stats[i]);
+
+   zfree(>stats);
+}
+
+static void runtime_stat_reset(struct perf_stat_config *config)
+{
+   int i;
+
+   if (!config->stats)
+   return;
+
+   for (i = 0; i < config->stats_num; i++)
+   perf_stat__reset_shadow_per_stat(>stats[i]);
+}
+
 static void process_interval(void)
 {
struct timespec ts, rs;
@@ -359,6 +399,7 @@ static void process_interval(void)
diff_timespec(, , _time);
 
perf_stat__reset_shadow_per_stat(_stat);
+   runtime_stat_reset(_config);
read_counters();
 
if (STAT_RECORD) {
@@ -1737,35 +1778,6 @@ int process_cpu_map_event(struct perf_session *session,
return set_maps(st);
 }
 
-static int runtime_stat_new(struct perf_stat_config *config, int nthreads)
-{
-   int i;
-
-   config->stats = calloc(nthreads, sizeof(struct runtime_stat));
-   if (!config->stats)
-   return -1;
-
-   config->stats_num = nthreads;
-
-   for (i = 0; i < nthreads; i++)
-   runtime_stat__init(>stats[i]);
-
-   return 0;
-}
-
-static void runtime_stat_delete(struct perf_stat_config *config)
-{
-   int i;
-
-   if (!config->stats)
-   return;
-
-   for (i = 0; i < config->stats_num; i++)
-   runtime_stat__exit(>stats[i]);
-
-   zfree(>stats);
-}
-
 static const char * const stat_report_usage[] = {
"perf stat report []",
NULL,
-- 
2.17.1



[PATCH v5 3/5] perf stat: Copy counts from prev_raw_counts to evsel->counts

2020-05-13 Thread Jin Yao
It would be useful to support the overall statistics for perf-stat
interval mode. For example, report the summary at the end of
"perf-stat -I" output.

But since perf-stat can support many aggregation modes, such as
--per-thread, --per-socket, -M and etc, we need a solution which
doesn't bring much complexity.

The idea is to use 'evsel->prev_raw_counts' which is updated in
each interval and it's saved with the latest counts. Before reporting
the summary, we copy the counts from evsel->prev_raw_counts to
evsel->counts, and next we just follow non-interval processing.

 v5:
 ---
 Don't save the previous aggr value to the member of [cpu0,thread0]
 in perf_counts. Originally that was a trick because the
 perf_stat_process_counter would create aggr values from per cpu
 values. But we don't need to do that all the time. We will
 handle it in next patch.

 v4:
 ---
 Change the commit message.
 No functional change.

Signed-off-by: Jin Yao 
---
 tools/perf/util/stat.c | 24 
 tools/perf/util/stat.h |  1 +
 2 files changed, 25 insertions(+)

diff --git a/tools/perf/util/stat.c b/tools/perf/util/stat.c
index e397815f0dfb..aadc723ce871 100644
--- a/tools/perf/util/stat.c
+++ b/tools/perf/util/stat.c
@@ -225,6 +225,30 @@ void perf_evlist__reset_prev_raw_counts(struct evlist 
*evlist)
evsel__reset_prev_raw_counts(evsel);
 }
 
+static void perf_evsel__copy_prev_raw_counts(struct evsel *evsel)
+{
+   int ncpus = evsel__nr_cpus(evsel);
+   int nthreads = perf_thread_map__nr(evsel->core.threads);
+
+   for (int thread = 0; thread < nthreads; thread++) {
+   for (int cpu = 0; cpu < ncpus; cpu++) {
+   *perf_counts(evsel->counts, cpu, thread) =
+   *perf_counts(evsel->prev_raw_counts, cpu,
+thread);
+   }
+   }
+
+   evsel->counts->aggr = evsel->prev_raw_counts->aggr;
+}
+
+void perf_evlist__copy_prev_raw_counts(struct evlist *evlist)
+{
+   struct evsel *evsel;
+
+   evlist__for_each_entry(evlist, evsel)
+   perf_evsel__copy_prev_raw_counts(evsel);
+}
+
 static void zero_per_pkg(struct evsel *counter)
 {
if (counter->per_pkg_mask)
diff --git a/tools/perf/util/stat.h b/tools/perf/util/stat.h
index b4fdfaa7f2c0..62cf72c71869 100644
--- a/tools/perf/util/stat.h
+++ b/tools/perf/util/stat.h
@@ -198,6 +198,7 @@ int perf_evlist__alloc_stats(struct evlist *evlist, bool 
alloc_raw);
 void perf_evlist__free_stats(struct evlist *evlist);
 void perf_evlist__reset_stats(struct evlist *evlist);
 void perf_evlist__reset_prev_raw_counts(struct evlist *evlist);
+void perf_evlist__copy_prev_raw_counts(struct evlist *evlist);
 
 int perf_stat_process_counter(struct perf_stat_config *config,
  struct evsel *counter);
-- 
2.17.1



[PATCH v5 4/5] perf stat: Save aggr value to first member of prev_raw_counts

2020-05-13 Thread Jin Yao
To collect the overall statistics for interval mode, we copy the
counts from evsel->prev_raw_counts to evsel->counts.

For AGGR_GLOBAL mode, because the perf_stat_process_counter creates
aggr values from per cpu values, but the per cpu values are 0,
so the calculated aggr values will be always 0.

This patch uses a trick that saves the previous aggr value to
the first member of perf_counts, then aggr calculation in
process_counter_values can work correctly for AGGR_GLOBAL.

Signed-off-by: Jin Yao 
---
 tools/perf/util/stat.c | 10 ++
 tools/perf/util/stat.h |  1 +
 2 files changed, 11 insertions(+)

diff --git a/tools/perf/util/stat.c b/tools/perf/util/stat.c
index aadc723ce871..fbabdd5b9b62 100644
--- a/tools/perf/util/stat.c
+++ b/tools/perf/util/stat.c
@@ -249,6 +249,16 @@ void perf_evlist__copy_prev_raw_counts(struct evlist 
*evlist)
perf_evsel__copy_prev_raw_counts(evsel);
 }
 
+void perf_evlist__save_aggr_prev_raw_counts(struct evlist *evlist)
+{
+   struct evsel *evsel;
+
+   evlist__for_each_entry(evlist, evsel) {
+   *perf_counts(evsel->prev_raw_counts, 0, 0) =
+   evsel->prev_raw_counts->aggr;
+   }
+}
+
 static void zero_per_pkg(struct evsel *counter)
 {
if (counter->per_pkg_mask)
diff --git a/tools/perf/util/stat.h b/tools/perf/util/stat.h
index 62cf72c71869..18ead55756cc 100644
--- a/tools/perf/util/stat.h
+++ b/tools/perf/util/stat.h
@@ -199,6 +199,7 @@ void perf_evlist__free_stats(struct evlist *evlist);
 void perf_evlist__reset_stats(struct evlist *evlist);
 void perf_evlist__reset_prev_raw_counts(struct evlist *evlist);
 void perf_evlist__copy_prev_raw_counts(struct evlist *evlist);
+void perf_evlist__save_aggr_prev_raw_counts(struct evlist *evlist);
 
 int perf_stat_process_counter(struct perf_stat_config *config,
  struct evsel *counter);
-- 
2.17.1



[PATCH v5 0/5] perf stat: Support overall statistics for interval mode

2020-05-13 Thread Jin Yao
Currently perf-stat supports to print counts at regular interval (-I),
but it's not very easy for user to get the overall statistics.

With this patchset, it supports to report the summary at the end of
interval output.

For example,

 root@kbl-ppc:~# perf stat -e cycles -I1000 --interval-count 2
 #   time counts unit events
  1.000412064  2,281,114  cycles
  2.001383658  2,547,880  cycles

  Performance counter stats for 'system wide':

  4,828,994  cycles

2.002860349 seconds time elapsed

 root@kbl-ppc:~# perf stat -e cycles,instructions -I1000 --interval-count 2
 #   time counts unit events
  1.000389902  1,536,093  cycles
  1.000389902420,226  instructions  #0.27  
insn per cycle
  2.001433453  2,213,952  cycles
  2.001433453735,465  instructions  #0.33  
insn per cycle

  Performance counter stats for 'system wide':

  3,750,045  cycles
  1,155,691  instructions  #0.31  insn per cycle

2.003023361 seconds time elapsed

 root@kbl-ppc:~# perf stat -M CPI,IPC -I1000 --interval-count 2
 #   time counts unit events
  1.000435121905,303  inst_retired.any  #  2.9 
CPI
  1.000435121  2,663,333  cycles
  1.000435121914,702  inst_retired.any  #  0.3 
IPC
  1.000435121  2,676,559  cpu_clk_unhalted.thread
  2.001615941  1,951,092  inst_retired.any  #  1.8 
CPI
  2.001615941  3,551,357  cycles
  2.001615941  1,950,837  inst_retired.any  #  0.5 
IPC
  2.001615941  3,551,044  cpu_clk_unhalted.thread

  Performance counter stats for 'system wide':

  2,856,395  inst_retired.any  #  2.2 CPI
  6,214,690  cycles
  2,865,539  inst_retired.any  #  0.5 IPC
  6,227,603  cpu_clk_unhalted.thread

2.003403078 seconds time elapsed

 v5:
 ---
 1. Create new patch "perf stat: Save aggr value to first member
of prev_raw_counts".

 2. Call perf_evlist__save_aggr_prev_raw_counts to save aggr value
to first member of prev_raw_counts for AGGR_GLOBAL. Then next,
perf_stat_process_counter can create aggr values from per cpu
values.

 Following patches are impacted in v5:
perf stat: Copy counts from prev_raw_counts to evsel->counts
perf stat: Save aggr value to first member of prev_raw_counts
perf stat: Report summary for interval mode

 v4:
 ---
 1. Create runtime_stat_reset.

 2. Zero the aggr in perf_counts__reset and use it to reset
prev_raw_counts.

 3. Move affinity setup and read_counter_cpu to a new function
read_affinity_counters. It's only called when stat_config.summary
is not set.

 v3:
 ---
 1. 'perf stat: Fix wrong per-thread runtime stat for interval mode'
is a new patch which fixes an existing issue found in test.

 2. We use the prev_raw_counts for summary counts. Drop the summary_counts in 
v2.

 3. Fix some issues.

 v2:
 ---
 Rebase to perf/core branch

Jin Yao (5):
  perf stat: Fix wrong per-thread runtime stat for interval mode
  perf counts: Reset prev_raw_counts counts
  perf stat: Copy counts from prev_raw_counts to evsel->counts
  perf stat: Save aggr value to first member of prev_raw_counts
  perf stat: Report summary for interval mode

 tools/perf/builtin-stat.c | 101 ++
 tools/perf/util/counts.c  |   4 +-
 tools/perf/util/counts.h  |   1 +
 tools/perf/util/stat.c|  43 +---
 tools/perf/util/stat.h|   3 ++
 5 files changed, 113 insertions(+), 39 deletions(-)

-- 
2.17.1



Re: [PATCH] optee: don't fail on unsuccessful device enumeration

2020-05-13 Thread Sumit Garg
Hi Volodymyr,

On Thu, 14 May 2020 at 06:48, Volodymyr Babchuk  wrote:
>
> Hi Sumit,
>
> On Wed, 13 May 2020 at 11:24, Sumit Garg  wrote:
> >
> > Hi Volodymyr,
> >
> > On Wed, 13 May 2020 at 13:30, Jens Wiklander  
> > wrote:
> > >
> > > Hi Volodymyr,
> > >
> > > On Wed, May 13, 2020 at 2:36 AM Volodymyr Babchuk
> > >  wrote:
> > > >
> > > > optee_enumerate_devices() can fail for multiple of reasons. For
> > > > example, I encountered issue when Xen OP-TEE mediator NACKed
> > > > PTA_CMD_GET_DEVICES call.
> >
> > Could you share a detailed description of the issue which you are
> > facing? optee_enumerate_devices() is a simple invocation of pseudo TA
> > and cases where OP-TEE doesn't provide corresponding pseudo TA are
> > handled very well.
>
> Yes, I did some research and looks like issue is broader, than I
> expected.  It is my fault, that I wasn't paying attention to the tee
> client support in the kernel.  Basically, it is incompatible with the
> virtualization feature. You see, the main issue with virtual machines
> is the second stage MMU. Intermediate physical address, that appear to
> be contiguous for the kernel may be not contiguous in the real
> physical memory due to 2nd stage MMU mappings. This is the reason I
> introduced OPTEE_MSG_ATTR_NONCONTIG in the kernel driver.
>
> But, looks like kernel-side optee client does not use this feature. It
> tries to provide SHM buffer as a simple contiguous span of memory. Xen
> blocks calls with OPTEE_MSG_ATTR_TYPE_TMEM_*   but without
> OPTEE_MSG_ATTR_NONCONTIG , because it can't translate IPAs to PAs for
> such buffers. This is why call to  PTA_CMD_GET_DEVICES fails.
>
> Valid fix would be to use OPTEE_MSG_ATTR_NONCONTIG whenever possible.
>

Thanks for the detailed analysis. It looks like you are missing the
following fix patch in your tree which basically fixed broken
tee_shm_alloc() in case dynamic shared memory is enabled (IIRC
virtualization only supports dynamic shared memory).

commit a249dd200d03791cab23e47571f3e13d9c72af6c
Author: Sumit Garg 
Date:   Fri Nov 8 16:57:14 2019 +0530

tee: optee: Fix dynamic shm pool allocations

In case of dynamic shared memory pool, kernel memory allocated using
dmabuf_mgr pool needs to be registered with OP-TEE prior to its usage
during optee_open_session() or optee_invoke_func().

So fix dmabuf_mgr pool allocations via an additional call to
optee_shm_register().

Also, allow kernel pages to be registered as shared memory with OP-TEE.

Fixes: 9733b072a12a ("optee: allow to work without static shared memory")
Signed-off-by: Sumit Garg 
Signed-off-by: Jens Wiklander 

After this fix, your issue should be resolved as it uses
OPTEE_MSG_ATTR_NONCONTIG attribute for kernel memory allocated via
tee_shm_alloc().

> >
> > > > This should not result in driver
> > > > initialization error because this is an optional feature.
> >
> > I wouldn't call it an optional feature as there might be real kernel
> > drivers dependent on this enumeration. Also, it is a simple example to
> > self test OP-TEE functionality too. So I am not sure how much
> > functional OP-TEE would be if this basic TA invocation fails.
>
> Well, it fixed case when Xen is involved. I think, this is valid
> combination, when platform have the newest OP-TEE, but slightly older
> kernel. So, imagine that OP-TEE provides PTA_CMD_GET_DEVICES, but
> kernel can't use because it uses plain TMEM arguments,which are not
> supported in virtualized environment.
>
> If there are kernel drivers, that depend on this PTA, they would not
> work in any case. But at least userspace clients still be able to use
> OP-TEE. This is why I call this feature "optional".

As you can see above, tee_shm_alloc() being broken in your case was
detected via this simple pseudo TA invocation. So IMO, it would be
better to keep the existing behaviour as it provides a kind of basic
OP-TEE driver runtime self test too. Also, I think it would be a
better user experience to have every OP-TEE interface working rather
than a partially broken interface.

-Sumit

>
> --
> WBR Volodymyr Babchuk aka lorc [+380976646013]
> mailto: vlad.babc...@gmail.com


[PATCH v5 5/5] perf stat: Report summary for interval mode

2020-05-13 Thread Jin Yao
Currently perf-stat supports to print counts at regular interval (-I),
but it's not very easy for user to get the overall statistics.

The patch uses 'evsel->prev_raw_counts' to get counts for summary.
Copy the counts to 'evsel->counts' after printing the interval results.
Next, we just follow the non-interval processing.

Let's see some examples,

 root@kbl-ppc:~# perf stat -e cycles -I1000 --interval-count 2
 #   time counts unit events
  1.000412064  2,281,114  cycles
  2.001383658  2,547,880  cycles

  Performance counter stats for 'system wide':

  4,828,994  cycles

2.002860349 seconds time elapsed

 root@kbl-ppc:~# perf stat -e cycles,instructions -I1000 --interval-count 2
 #   time counts unit events
  1.000389902  1,536,093  cycles
  1.000389902420,226  instructions  #0.27  
insn per cycle
  2.001433453  2,213,952  cycles
  2.001433453735,465  instructions  #0.33  
insn per cycle

  Performance counter stats for 'system wide':

  3,750,045  cycles
  1,155,691  instructions  #0.31  insn per cycle

2.003023361 seconds time elapsed

 root@kbl-ppc:~# perf stat -M CPI,IPC -I1000 --interval-count 2
 #   time counts unit events
  1.000435121905,303  inst_retired.any  #  2.9 
CPI
  1.000435121  2,663,333  cycles
  1.000435121914,702  inst_retired.any  #  0.3 
IPC
  1.000435121  2,676,559  cpu_clk_unhalted.thread
  2.001615941  1,951,092  inst_retired.any  #  1.8 
CPI
  2.001615941  3,551,357  cycles
  2.001615941  1,950,837  inst_retired.any  #  0.5 
IPC
  2.001615941  3,551,044  cpu_clk_unhalted.thread

  Performance counter stats for 'system wide':

  2,856,395  inst_retired.any  #  2.2 CPI
  6,214,690  cycles
  2,865,539  inst_retired.any  #  0.5 IPC
  6,227,603  cpu_clk_unhalted.thread

2.003403078 seconds time elapsed

 v5:
 ---
 Call perf_evlist__save_aggr_prev_raw_counts to save aggr value
 to first member of prev_raw_counts for AGGR_GLOBAL. Then next,
 perf_stat_process_counter can create aggr values from per cpu
 values.

 v4:
 ---
 Move affinity setup and read_counter_cpu to a new function
 read_affinity_counters. It's only called when stat_config.summary
 is not set.

 v3:
 ---
 Use evsel->prev_raw_counts for summary counts

 v2:
 ---
 Rebase to perf/core branch

Signed-off-by: Jin Yao 
---
 tools/perf/builtin-stat.c | 31 ---
 tools/perf/util/stat.c|  2 +-
 tools/perf/util/stat.h|  1 +
 3 files changed, 30 insertions(+), 4 deletions(-)

diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index f3b3a59ac7d2..24deed746325 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -314,14 +314,14 @@ static int read_counter_cpu(struct evsel *counter, struct 
timespec *rs, int cpu)
return 0;
 }
 
-static void read_counters(struct timespec *rs)
+static int read_affinity_counters(struct timespec *rs)
 {
struct evsel *counter;
struct affinity affinity;
int i, ncpus, cpu;
 
if (affinity__setup() < 0)
-   return;
+   return -1;
 
ncpus = perf_cpu_map__nr(evsel_list->core.all_cpus);
if (!target__has_cpu() || target__has_per_thread())
@@ -341,6 +341,15 @@ static void read_counters(struct timespec *rs)
}
}
affinity__cleanup();
+   return 0;
+}
+
+static void read_counters(struct timespec *rs)
+{
+   struct evsel *counter;
+
+   if (!stat_config.summary && (read_affinity_counters(rs) < 0))
+   return;
 
evlist__for_each_entry(evsel_list, counter) {
if (counter->err)
@@ -394,6 +403,7 @@ static void runtime_stat_reset(struct perf_stat_config 
*config)
 static void process_interval(void)
 {
struct timespec ts, rs;
+   struct stats walltime_nsecs_stats_bak;
 
clock_gettime(CLOCK_MONOTONIC, );
diff_timespec(, , _time);
@@ -407,9 +417,11 @@ static void process_interval(void)
pr_err("failed to write stat round event\n");
}
 
+   walltime_nsecs_stats_bak = walltime_nsecs_stats;
init_stats(_nsecs_stats);
update_stats(_nsecs_stats, stat_config.interval * 100);
print_counters(, 0, NULL);
+   walltime_nsecs_stats = walltime_nsecs_stats_bak;
 }
 
 static void enable_counters(void)
@@ -765,6 +777,19 @@ static int __run_perf_stat(int argc, const char **argv, 
int run_idx)
 
update_stats(_nsecs_stats, t1 - t0);
 
+   if (interval) {
+   stat_config.interval = 0;
+   

Re: [PATCH v4] bus: mhi: core: Handle syserr during power_up

2020-05-13 Thread Manivannan Sadhasivam
On Thu, May 07, 2020 at 10:19:31AM -0600, Jeffrey Hugo wrote:
> The MHI device may be in the syserr state when we attempt to init it in
> power_up().  Since we have no local state, the handling is simple -
> reset the device and wait for it to transition out of the reset state.
> 
> Signed-off-by: Jeffrey Hugo 

Reviewed-by: Manivannan Sadhasivam 

Will apply this patch to mhi-next and include in the 5.8 series.

Thanks,
Mani

> ---
> 
> v4:
> -Implemented Hemant's suggested solution from v2.  The spec will be amended
> to indicate the intvec interrupt will be triggered for the reset state change
> which matches the current implementations and enables Hemant's solution to
> be used, which is cleaner.
> 
>  drivers/bus/mhi/core/pm.c | 27 +++
>  1 file changed, 27 insertions(+)
> 
> diff --git a/drivers/bus/mhi/core/pm.c b/drivers/bus/mhi/core/pm.c
> index dc83d65..ddef693 100644
> --- a/drivers/bus/mhi/core/pm.c
> +++ b/drivers/bus/mhi/core/pm.c
> @@ -760,6 +760,7 @@ static void mhi_deassert_dev_wake(struct mhi_controller 
> *mhi_cntrl,
>  
>  int mhi_async_power_up(struct mhi_controller *mhi_cntrl)
>  {
> + enum mhi_state state;
>   enum mhi_ee_type current_ee;
>   enum dev_st_transition next_state;
>   struct device *dev = _cntrl->mhi_dev->dev;
> @@ -829,6 +830,32 @@ int mhi_async_power_up(struct mhi_controller *mhi_cntrl)
>   goto error_bhi_offset;
>   }
>  
> + state = mhi_get_mhi_state(mhi_cntrl);
> + if (state == MHI_STATE_SYS_ERR) {
> + mhi_set_mhi_state(mhi_cntrl, MHI_STATE_RESET);
> + ret = wait_event_timeout(mhi_cntrl->state_event,
> + MHI_PM_IN_FATAL_STATE(mhi_cntrl->pm_state) ||
> + mhi_read_reg_field(mhi_cntrl,
> +mhi_cntrl->regs,
> +MHICTRL,
> +MHICTRL_RESET_MASK,
> +MHICTRL_RESET_SHIFT,
> +) ||
> + !val,
> + msecs_to_jiffies(mhi_cntrl->timeout_ms));
> + if (ret) {
> + ret = -EIO;
> + dev_info(dev, "Failed to reset MHI due to syserr 
> state\n");
> + goto error_bhi_offset;
> + }
> +
> + /*
> +  * device cleares INTVEC as part of RESET processing,
> +  * re-program it
> +  */
> + mhi_write_reg(mhi_cntrl, mhi_cntrl->bhi, BHI_INTVEC, 0);
> + }
> +
>   /* Transition to next state */
>   next_state = MHI_IN_PBL(current_ee) ?
>   DEV_ST_TRANSITION_PBL : DEV_ST_TRANSITION_READY;
> -- 
> Qualcomm Technologies, Inc. is a member of the
> Code Aurora Forum, a Linux Foundation Collaborative Project.


Re: gcc-10: kernel stack is corrupted and fails to boot

2020-05-13 Thread Arvind Sankar
On Wed, May 13, 2020 at 09:52:07PM -0700, Linus Torvalds wrote:
> On Wed, May 13, 2020, 20:50 Andy Lutomirski  wrote:
> 
> >
> > LTO isn’t a linker taking regular .o files full of regular machine
> > code and optimizing it. That’s nuts.
> >
> 
> Yeah, you're right. I wear originally thinking just an optimizing
> assembler, and then started thinking about link-time optimizations in that
> sense, but it was wrong to then go from that to LTO which has a very
> specific meaning.
> 
> We do have assemblers that do some optimizations, but they tend to all be
> at the single instruction level (eg things like turning "add $128" into
> "sub $-128" which fits in a byte constant).
> 
> Linus
> 
> >

The gcc docs [1,2] at least don't inspire much confidence that this will
continue working with plain asm("") though:

"Note that GCC’s optimizers can move asm statements relative to other
code, including across jumps."
...
"Note that the compiler can move even volatile asm instructions relative
to other code, including across jump instructions."

Even if we don't include an instruction in it I think it should at least
have a memory clobber, to stop the compiler from deciding that it can be
moved before the call so it can do the tail-call optimization.

[1] https://gcc.gnu.org/onlinedocs/gcc/Basic-Asm.html#Basic-Asm
[2] https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Volatile


Re: [PATCH v2 11/12] remoteproc: stm32: Introduce new loaded rsc ops for synchronisation

2020-05-13 Thread Bjorn Andersson
On Fri 24 Apr 13:25 PDT 2020, Mathieu Poirier wrote:

> Introduce new elf find loaded resource table rproc_ops functions to be
> used when synchonising with an MCU.
> 
> Mainly based on the work published by Arnaud Pouliquen [1].
> 
> [1]. https://patchwork.kernel.org/project/linux-remoteproc/list/?series=239877
> 
> Signed-off-by: Mathieu Poirier 
> Reviewed-by: Loic Pallardy 

Reviewed-by: Bjorn Andersson 


But I would have preferred if we during probe (when we discover rsc_va)
could just set it on the rproc.

Regards,
Bjorn

> ---
>  drivers/remoteproc/stm32_rproc.c | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/drivers/remoteproc/stm32_rproc.c 
> b/drivers/remoteproc/stm32_rproc.c
> index b8ae8aed5585..dcae6103e3df 100644
> --- a/drivers/remoteproc/stm32_rproc.c
> +++ b/drivers/remoteproc/stm32_rproc.c
> @@ -319,6 +319,15 @@ static int stm32_rproc_sync_parse_fw(struct rproc *rproc,
>   return stm32_rproc_sync_elf_load_rsc_table(rproc, fw);
>  }
>  
> +static struct resource_table *
> +stm32_rproc_sync_elf_find_loaded_rsc_table(struct rproc *rproc,
> +const struct firmware *fw)
> +{
> + struct stm32_rproc *ddata = rproc->priv;
> +
> + return (struct resource_table *)ddata->rsc_va;
> +}
> +
>  static irqreturn_t stm32_rproc_wdg(int irq, void *data)
>  {
>   struct platform_device *pdev = data;
> @@ -593,6 +602,7 @@ static __maybe_unused struct rproc_ops st_rproc_sync_ops 
> = {
>   .start  = stm32_rproc_sync_start,
>   .stop   = stm32_rproc_stop,
>   .parse_fw   = stm32_rproc_sync_parse_fw,
> + .find_loaded_rsc_table = stm32_rproc_sync_elf_find_loaded_rsc_table,
>  };
>  
>  static const struct of_device_id stm32_rproc_match[] = {
> -- 
> 2.20.1
> 


Re: [PATCH v2 10/12] remoteproc: stm32: Introduce new parse fw ops for synchronisation

2020-05-13 Thread Bjorn Andersson
On Fri 24 Apr 13:25 PDT 2020, Mathieu Poirier wrote:

> Introduce new parse firmware rproc_ops functions to be used when
> synchonising with an MCU.
> 
> Mainly based on the work published by Arnaud Pouliquen [1].
> 
> [1]. https://patchwork.kernel.org/project/linux-remoteproc/list/?series=239877
> 
> Signed-off-by: Mathieu Poirier 
> Reviewed-by: Loic Pallardy 
> ---
>  drivers/remoteproc/stm32_rproc.c | 51 +++-
>  1 file changed, 50 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/remoteproc/stm32_rproc.c 
> b/drivers/remoteproc/stm32_rproc.c
> index 86d23c35d805..b8ae8aed5585 100644
> --- a/drivers/remoteproc/stm32_rproc.c
> +++ b/drivers/remoteproc/stm32_rproc.c
> @@ -215,7 +215,34 @@ static int stm32_rproc_elf_load_rsc_table(struct rproc 
> *rproc,
>   return 0;
>  }
>  
> -static int stm32_rproc_parse_fw(struct rproc *rproc, const struct firmware 
> *fw)
> +static int stm32_rproc_sync_elf_load_rsc_table(struct rproc *rproc,
> +const struct firmware *fw)
> +{
> + struct resource_table *table = NULL;
> + struct stm32_rproc *ddata = rproc->priv;
> +
> + if (ddata->rsc_va) {

Does it really make sense to try to sync with a remote that doesn't have
a resource table?

> + table = (struct resource_table *)ddata->rsc_va;
> + /* Assuming that the resource table fits in 1kB is fair */
> + rproc->cached_table = kmemdup(table, RSC_TBL_SIZE, GFP_KERNEL);

It's unfortunate that we need to create a clone of the resource table
that we found in ram, and then return the original memory when the core
ask for the loaded table...

I wonder if we somehow can avoid this in the core (i.e. skip overwriting
table_ptr with the cached_table during stop)

> + if (!rproc->cached_table)
> + return -ENOMEM;
> +
> + rproc->table_ptr = rproc->cached_table;
> + rproc->table_sz = RSC_TBL_SIZE;
> + return 0;
> + }
> +
> + rproc->cached_table = NULL;
> + rproc->table_ptr = NULL;
> + rproc->table_sz = 0;
> +
> + dev_warn(>dev, "no resource table found for this firmware\n");
> + return 0;
> +}
> +
> +static int stm32_rproc_parse_memory_regions(struct rproc *rproc,
> + const struct firmware *fw)
>  {
>   struct device *dev = rproc->dev.parent;
>   struct device_node *np = dev->of_node;
> @@ -268,9 +295,30 @@ static int stm32_rproc_parse_fw(struct rproc *rproc, 
> const struct firmware *fw)
>   index++;
>   }
>  
> + return 0;
> +}
> +
> +static int stm32_rproc_parse_fw(struct rproc *rproc, const struct firmware 
> *fw)
> +{
> + int ret = stm32_rproc_parse_memory_regions(rproc, fw);
> +
> + if (ret)
> + return ret;
> +
>   return stm32_rproc_elf_load_rsc_table(rproc, fw);
>  }
>  
> +static int stm32_rproc_sync_parse_fw(struct rproc *rproc,
> +  const struct firmware *fw)

Rather than having a function parse_fw that is passed no fw and return
some state that was setup in probe, how about just do this during probe?

Regards,
Bjorn

> +{
> + int ret = stm32_rproc_parse_memory_regions(rproc, fw);
> +
> + if (ret)
> + return ret;
> +
> + return stm32_rproc_sync_elf_load_rsc_table(rproc, fw);
> +}
> +
>  static irqreturn_t stm32_rproc_wdg(int irq, void *data)
>  {
>   struct platform_device *pdev = data;
> @@ -544,6 +592,7 @@ static struct rproc_ops st_rproc_ops = {
>  static __maybe_unused struct rproc_ops st_rproc_sync_ops = {
>   .start  = stm32_rproc_sync_start,
>   .stop   = stm32_rproc_stop,
> + .parse_fw   = stm32_rproc_sync_parse_fw,
>  };
>  
>  static const struct of_device_id stm32_rproc_match[] = {
> -- 
> 2.20.1
> 


Re: [Jfs-discussion] [fs] 05c5a0273b: netperf.Throughput_total_tps -71.8% regression

2020-05-13 Thread Rong Chen




On 5/14/20 12:27 PM, Christian Kujau wrote:

On Tue, 12 May 2020, kernel test robot wrote:

FYI, we noticed a -71.8% regression of netperf.Throughput_total_tps due to 
commit:

As noted in this report, netperf is used to "measure various aspect of
networking performance". Are we sure the bisect is correct? JFS is a
filesystem and is not touching net/ in any way. So, having not attempted
to reproduce this, maybe the JFS commit is a red herring?

C.


Hi,

The commit also causes -74.6% regression of will-it-scale.per_thread_ops:

in testcase: will-it-scale
on test machine: 8 threads Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz with 16G 
memory
with following parameters:

nr_task: 100%
mode: thread
test: unlink2
cpufreq_governor: performance
ucode: 0x21

I'll send another report for this regression.

Best Regards,
Rong Chen



Re: [PATCH v1] ASoC: rsnd: add interrupt support for SSI BUSIF buffer

2020-05-13 Thread kbuild test robot
Hi Yongbo,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on asoc/for-next]
[also build test WARNING on v5.7-rc5 next-20200511]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

url:
https://github.com/0day-ci/linux/commits/Yongbo-Zhang/ASoC-rsnd-add-interrupt-support-for-SSI-BUSIF-buffer/20200511-184903
base:   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 
for-next
reproduce:
# apt-get install sparse
# sparse version: v0.6.1-191-gc51a0382-dirty
make ARCH=x86_64 allmodconfig
make C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'
:: branch date: 8 hours ago
:: commit date: 8 hours ago

If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot 


sparse warnings: (new ones prefixed by >>)

   sound/soc/sh/rcar/ssi.c:596:1: sparse: sparse: mixing declarations and code
   include/sound/pcm_params.h:377:0: sparse: sparse: Expected } at end of 
function
   include/sound/pcm_params.h:377:0: sparse: sparse: got end-of-input
>> sound/soc/sh/rcar/ssi.c:798:56: sparse: sparse: not enough arguments for 
>> function rsnd_mod_write

# 
https://github.com/0day-ci/linux/commit/23aaae15fe2b41fd05caf5e0773d41021bc03e27
git remote add linux-review https://github.com/0day-ci/linux
git remote update linux-review
git checkout 23aaae15fe2b41fd05caf5e0773d41021bc03e27
vim +798 sound/soc/sh/rcar/ssi.c

615fb6c7b13b7f Kuninori Morimoto 2016-02-18  733  
d8d9b9730cd62c Kuninori Morimoto 2017-12-11  734  static bool 
rsnd_ssi_pio_interrupt(struct rsnd_mod *mod,
d8d9b9730cd62c Kuninori Morimoto 2017-12-11  735
   struct rsnd_dai_stream *io);
bfc0cfe6b7acb1 Kuninori Morimoto 2015-06-15  736  static void 
__rsnd_ssi_interrupt(struct rsnd_mod *mod,
bfc0cfe6b7acb1 Kuninori Morimoto 2015-06-15  737
 struct rsnd_dai_stream *io)
ae5c322303fff5 Kuninori Morimoto 2013-07-21  738  {
690602fcd85385 Kuninori Morimoto 2015-01-15  739struct rsnd_priv *priv 
= rsnd_mod_to_priv(mod);
2b62786951ca38 Kuninori Morimoto 2018-02-13  740struct device *dev = 
rsnd_priv_to_dev(priv);
765ae7c8dda7d0 Kuninori Morimoto 2015-01-15  741int is_dma = 
rsnd_ssi_is_dma_mode(mod);
02299d9875bab5 Kuninori Morimoto 2015-05-21  742u32 status;
75defee0f1b3fc Kuninori Morimoto 2015-06-15  743bool elapsed = false;
6a25c8da00284f Kuninori Morimoto 2016-01-26  744bool stop = false;
23aaae15fe2b41 Yongbo Zhang  2020-05-11  745int is_tdm, 
is_tdm_split;
23aaae15fe2b41 Yongbo Zhang  2020-05-11  746  
23aaae15fe2b41 Yongbo Zhang  2020-05-11  747is_tdm  = 
rsnd_runtime_is_tdm(io);
23aaae15fe2b41 Yongbo Zhang  2020-05-11  748is_tdm_split= 
rsnd_runtime_is_tdm_split(io);
02299d9875bab5 Kuninori Morimoto 2015-05-21  749  
02299d9875bab5 Kuninori Morimoto 2015-05-21  750spin_lock(>lock);
ae5c322303fff5 Kuninori Morimoto 2013-07-21  751  
02299d9875bab5 Kuninori Morimoto 2015-05-21  752/* ignore all cases if 
not working */
d5bbe7de563ccc Kuninori Morimoto 2015-06-15  753if 
(!rsnd_io_is_working(io))
02299d9875bab5 Kuninori Morimoto 2015-05-21  754goto 
rsnd_ssi_interrupt_out;
02299d9875bab5 Kuninori Morimoto 2015-05-21  755  
6a25c8da00284f Kuninori Morimoto 2016-01-26  756status = 
rsnd_ssi_status_get(mod);
4e7d606cd52aa8 Kuninori Morimoto 2014-11-27  757  
4e7d606cd52aa8 Kuninori Morimoto 2014-11-27  758/* PIO only */
d8d9b9730cd62c Kuninori Morimoto 2017-12-11  759if (!is_dma && (status 
& DIRQ))
d8d9b9730cd62c Kuninori Morimoto 2017-12-11  760elapsed = 
rsnd_ssi_pio_interrupt(mod, io);
ae5c322303fff5 Kuninori Morimoto 2013-07-21  761  
12927a8f802642 Kuninori Morimoto 2015-06-15  762/* DMA only */
2b62786951ca38 Kuninori Morimoto 2018-02-13  763if (is_dma && (status & 
(UIRQ | OIRQ))) {
c0ea089dbad47a Kuninori Morimoto 2018-10-30  764
rsnd_dbg_irq_status(dev, "%s err status : 0x%08x\n",
c0ea089dbad47a Kuninori Morimoto 2018-10-30  765
rsnd_mod_name(mod), status);
2b62786951ca38 Kuninori Morimoto 2018-02-13  766  
6a25c8da00284f Kuninori Morimoto 2016-01-26  767stop = true;
2b62786951ca38 Kuninori Morimoto 2018-02-13  768}
69e32a58bde674 Kuninori Morimoto 2015-10-26  769  
23aaae15fe2b41 Yongbo Zhang  2020-05-11  770status = 0;
23aaae15fe2b41 Yongbo Zhang  2020-05-11  771  
23aaae15fe2b41 Yongbo Zhang  2020-05-11  772if (is_tdm || 
is_tdm_split) {
23aaae15fe2b41 Yongbo Zhang  2020-05-11  773switch (id) {
23aaae15fe2b41 Yongbo Zhang  2020-05-11  774case 0:
23aaae15fe2b41 Yongbo 

Re: [PATCH v2 05/12] remoteproc: stm32: Parse syscon that will manage M4 synchronisation

2020-05-13 Thread Bjorn Andersson
On Fri 24 Apr 13:24 PDT 2020, Mathieu Poirier wrote:

> Get from the DT the syncon to probe the state of the remote processor
> and the location of the resource table.
> 
> Mainly based on the work published by Arnaud Pouliquen [1].
> 
> [1]. https://patchwork.kernel.org/project/linux-remoteproc/list/?series=239877
> 
> Signed-off-by: Mathieu Poirier 
> Reviewed-by: Loic Pallardy 

Reviewed-by: Bjorn Andersson 

> ---
>  drivers/remoteproc/stm32_rproc.c | 26 ++
>  1 file changed, 26 insertions(+)
> 
> diff --git a/drivers/remoteproc/stm32_rproc.c 
> b/drivers/remoteproc/stm32_rproc.c
> index 658439d4b00a..a285f338bed8 100644
> --- a/drivers/remoteproc/stm32_rproc.c
> +++ b/drivers/remoteproc/stm32_rproc.c
> @@ -70,6 +70,8 @@ struct stm32_rproc {
>   struct reset_control *rst;
>   struct stm32_syscon hold_boot;
>   struct stm32_syscon pdds;
> + struct stm32_syscon m4_state;
> + struct stm32_syscon rsctbl;
>   int wdg_irq;
>   u32 nb_rmems;
>   struct stm32_rproc_mem *rmems;
> @@ -606,6 +608,30 @@ static int stm32_rproc_parse_dt(struct platform_device 
> *pdev,
>  
>   *auto_boot = of_property_read_bool(np, "st,auto-boot");
>  
> + /*
> +  * See if we can check the M4 status, i.e if it was started
> +  * from the boot loader or not.
> +  */
> + err = stm32_rproc_get_syscon(np, "st,syscfg-m4-state",
> +  >m4_state);
> + if (err) {
> + /* remember this */
> + ddata->m4_state.map = NULL;
> + /* no coprocessor state syscon (optional) */
> + dev_warn(dev, "m4 state not supported\n");
> +
> + /* no need to go further */
> + return 0;
> + }
> +
> + /* See if we can get the resource table */
> + err = stm32_rproc_get_syscon(np, "st,syscfg-rsc-tbl",
> +  >rsctbl);
> + if (err) {
> + /* no rsc table syscon (optional) */
> + dev_warn(dev, "rsc tbl syscon not supported\n");
> + }
> +
>   return 0;
>  }
>  
> -- 
> 2.20.1
> 


Re: [PATCH v2 04/12] remoteproc: stm32: Remove memory translation from DT parsing

2020-05-13 Thread Bjorn Andersson
On Fri 24 Apr 13:24 PDT 2020, Mathieu Poirier wrote:

> Other than one has to be done after the other, there is no correlation
> between memory translation and DT parsing.  As move function
> stm32_rproc_of_memory_translations() to stm32_rproc_probe() so that
> stm32_rproc_parse_dt() can be extended to look for synchronisation
> related binding in a clean way.
> 
> Signed-off-by: Mathieu Poirier 
> Reviewed-by: Loic Pallardy 

Reviewed-by: Bjorn Andersson 

> ---
>  drivers/remoteproc/stm32_rproc.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/remoteproc/stm32_rproc.c 
> b/drivers/remoteproc/stm32_rproc.c
> index 57a426ea620b..658439d4b00a 100644
> --- a/drivers/remoteproc/stm32_rproc.c
> +++ b/drivers/remoteproc/stm32_rproc.c
> @@ -606,7 +606,7 @@ static int stm32_rproc_parse_dt(struct platform_device 
> *pdev,
>  
>   *auto_boot = of_property_read_bool(np, "st,auto-boot");
>  
> - return stm32_rproc_of_memory_translations(pdev, ddata);
> + return 0;
>  }
>  
>  static int stm32_rproc_probe(struct platform_device *pdev)
> @@ -634,6 +634,10 @@ static int stm32_rproc_probe(struct platform_device 
> *pdev)
>   if (ret)
>   goto free_rproc;
>  
> + ret = stm32_rproc_of_memory_translations(pdev, ddata);
> + if (ret)
> + goto free_rproc;
> +
>   rproc->auto_boot = auto_boot;
>   rproc->has_iommu = false;
>   ddata->workqueue = create_workqueue(dev_name(dev));
> -- 
> 2.20.1
> 


[PATCH 10/16] ARM: dts: at91: sama5d2: Add DMA bindings for the flx1 I2C function

2020-05-13 Thread Tudor.Ambarus
From: Tudor Ambarus 

Spare boards of duplicating the DMA bindings. Describe the flx1
DMA bindings in the SoC dtsi. Users that don't want to use DMA
for their flexcom functions have to overwrite the flexcom DMA
bindings in their board device tree.

Signed-off-by: Tudor Ambarus 
---
 arch/arm/boot/dts/at91-sama5d27_som1_ek.dts | 1 -
 arch/arm/boot/dts/sama5d2.dtsi  | 9 +
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts 
b/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts
index 1aa8b79d618b..0e159f879c15 100644
--- a/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts
+++ b/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts
@@ -127,7 +127,6 @@
 
i2c3: i2c@600 {
dmas = <0>, <0>;
-   dma-names = "tx", "rx";
i2c-analog-filter;
i2c-digital-filter;
i2c-digital-filter-width-ns = <35>;
diff --git a/arch/arm/boot/dts/sama5d2.dtsi b/arch/arm/boot/dts/sama5d2.dtsi
index 5a0162915ae7..855846c74a32 100644
--- a/arch/arm/boot/dts/sama5d2.dtsi
+++ b/arch/arm/boot/dts/sama5d2.dtsi
@@ -712,6 +712,15 @@
#address-cells = <1>;
#size-cells = <0>;
clocks = < PMC_TYPE_PERIPHERAL 20>;
+   dmas = <
+   (AT91_XDMAC_DT_MEM_IF(0) |
+AT91_XDMAC_DT_PER_IF(1) |
+AT91_XDMAC_DT_PERID(13))>,
+  <
+   (AT91_XDMAC_DT_MEM_IF(0) |
+AT91_XDMAC_DT_PER_IF(1) |
+AT91_XDMAC_DT_PERID(14))>;
+   dma-names = "tx", "rx";
atmel,fifo-size = <16>;
status = "disabled";
};
-- 
2.23.0


[PATCH 06/16] ARM: dts: at91: sama5d2: Move flx0 definitions in the SoC dtsi

2020-05-13 Thread Tudor.Ambarus
From: Tudor Ambarus 

The Flexcom IP is part of the sama5d2 SoC. Move the flx0 node together
with its function definitions in sama5d2.dtsi. Boards will just fill
the pins and enable the desired functions.

There is a single functional change in this patch. With the move of the
flx0 uart5 definition in the SoC dtsi, the uart5 from
at91-sama5d27_wlsom1_ek.dts inherits the following optional property:
atmel,fifo-size = <32>;
This particular change was tested by Codrin.

Signed-off-by: Tudor Ambarus 
Tested-by: Codrin Ciubotariu 
---
 arch/arm/boot/dts/at91-kizbox3_common.dtsi| 13 --
 arch/arm/boot/dts/at91-sama5d27_wlsom1_ek.dts | 12 --
 arch/arm/boot/dts/at91-sama5d2_icp.dts|  6 ---
 arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts |  7 
 arch/arm/boot/dts/at91-sama5d2_xplained.dts   |  7 +---
 arch/arm/boot/dts/sama5d2.dtsi| 40 +++
 6 files changed, 41 insertions(+), 44 deletions(-)

diff --git a/arch/arm/boot/dts/at91-kizbox3_common.dtsi 
b/arch/arm/boot/dts/at91-kizbox3_common.dtsi
index 4351a8d32225..7c3076e245ef 100644
--- a/arch/arm/boot/dts/at91-kizbox3_common.dtsi
+++ b/arch/arm/boot/dts/at91-kizbox3_common.dtsi
@@ -299,21 +299,8 @@
status = "disabled";
 
uart5: serial@200  {
-   compatible = "atmel,at91sam9260-usart";
-   reg = <0x200 0x400>;
-   interrupts = <19 IRQ_TYPE_LEVEL_HIGH 7>;
-   dmas = <
-   (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1)
-   | AT91_XDMAC_DT_PERID(11))>,
-  <
-   (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1)
-   | AT91_XDMAC_DT_PERID(12))>;
-   dma-names = "tx", "rx";
-   clocks = < PMC_TYPE_PERIPHERAL 19>;
-   clock-names = "usart";
pinctrl-names = "default";
pinctrl-0 = <_flx0_default>;
-   atmel,fifo-size = <32>;
atmel,use-dma-rx;
atmel,use-dma-tx;
status = "disabled";
diff --git a/arch/arm/boot/dts/at91-sama5d27_wlsom1_ek.dts 
b/arch/arm/boot/dts/at91-sama5d27_wlsom1_ek.dts
index 6b8461278950..6b38fa3f5568 100644
--- a/arch/arm/boot/dts/at91-sama5d27_wlsom1_ek.dts
+++ b/arch/arm/boot/dts/at91-sama5d27_wlsom1_ek.dts
@@ -77,18 +77,6 @@
status = "okay";
 
uart5: serial@200 {
-   compatible = "atmel,at91sam9260-usart";
-   reg = <0x200 0x200>;
-   interrupts = <19 IRQ_TYPE_LEVEL_HIGH 7>;
-   dmas = <
-   (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) |
-AT91_XDMAC_DT_PERID(11))>,
-  <
-   (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) |
-AT91_XDMAC_DT_PERID(12))>;
-   dma-names = "tx", "rx";
-   clocks = < PMC_TYPE_PERIPHERAL 19>;
-   clock-names = "usart";
pinctrl-0 = <_flx0_default>;
pinctrl-names = "default";
atmel,use-dma-rx;
diff --git a/arch/arm/boot/dts/at91-sama5d2_icp.dts 
b/arch/arm/boot/dts/at91-sama5d2_icp.dts
index 23f413afb333..4a01ab8e7e70 100644
--- a/arch/arm/boot/dts/at91-sama5d2_icp.dts
+++ b/arch/arm/boot/dts/at91-sama5d2_icp.dts
@@ -105,15 +105,9 @@
status = "okay";
 
spi2: spi@400 {
-   compatible = "atmel,at91rm9200-spi";
-   reg = <0x400 0x200>;
-   interrupts = <19 IRQ_TYPE_LEVEL_HIGH 7>;
-   clocks = < PMC_TYPE_PERIPHERAL 19>;
-   clock-names = "spi_clk";
cs-gpios = < PIN_PC0 GPIO_ACTIVE_LOW>;
pinctrl-names = "default";
pinctrl-0 = <_mikrobus2_spi _ksz_spi_cs>;
-   atmel,fifo-size = <16>;
status = "okay";
#address-cells = <1>;
#size-cells = <0>;
diff --git a/arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts 
b/arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts
index 32435ce1dab2..8ad3a9c6c536 100644
--- a/arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts
+++ b/arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts
@@ -191,20 +191,13 @@
status = "okay";
 
i2c2: i2c@600 {
-   compatible = "atmel,sama5d2-i2c";
-   reg = <0x600 0x200>;
-   interrupts = <19 IRQ_TYPE_LEVEL_HIGH 7>;
dmas = <0>, <0>;
dma-names = "tx", "rx";
-   #address-cells = <1>;
-   #size-cells = <0>;
-   clocks = < PMC_TYPE_PERIPHERAL 19>;
pinctrl-names = "default", "gpio";
pinctrl-0 = 

Re: [PATCH v5 2/6] spi: spi-geni-qcom: Use OPP API to set clk/perf state

2020-05-13 Thread Rajendra Nayak



[]..

  
  	spi->bus_num = -1;

spi->dev.of_node = dev->of_node;
@@ -596,6 +607,9 @@ static int spi_geni_probe(struct platform_device *pdev)
  spi_geni_probe_runtime_disable:
pm_runtime_disable(dev);
spi_master_put(spi);
+   if (mas->se.has_opp_table)


Why do you need has_opp_table?

Afaict if dev_pm_opp_of_add_table() returns -ENODEV there's no attached
opp-table and dev_pm_opp_of_remove_table() is a nop.


Apparently its not. Calling dev_pm_opp_of_remove_table() when 
dev_pm_opp_of_add_table()
failed causes use-count mismatch.
You can see https://lkml.org/lkml/2020/4/15/18 for more details.

--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation


[PATCH 00/16] ARM: dts: at91: sama5d2: Rework Flexcom definitions

2020-05-13 Thread Tudor.Ambarus
From: Tudor Ambarus 

Rework the sama5d2 SoC flexcom definitions. The Flexcom IPs are
in the SoC. Move all the flexcom nodes together with their function
definitions in the SoC dtsi. Boards will just fill the pins and enable
the desired functions. With this we remove the duplication of the
flexcom definitions across the sama5d2 boards.

Round the flexcom support and add the missing flexcom definitions.
All the flexcom functions are now defined.

Apart of the aliases and the new flx0 i2c function on sama5d2_xplained,
the only functional change that this patch set adds, is that it uart5,
uart6 and uart7 inherit the atmel,fifo-size = <32>; optional property.
These nodes have both the FIFO size described and the DMA enabled.
uart5 was tested on sama5d27-wlsom1-ek. On uart6 and uart7 a
Bluetooth module can be connected. Tested BT uart7 on sama5d2-icp.

Tudor Ambarus (16):
  ARM: dts: at91: sama5d2: Fix the label numbering for flexcom functions
  ARM: dts: at91: sama5d2: Move flx4 definitions in the SoC dtsi
  ARM: dts: at91: sama5d2: Move flx3 definitions in the SoC dtsi
  ARM: dts: at91: sama5d2: Move flx2 definitions in the SoC dtsi
  ARM: dts: at91: sama5d2: Move flx1 definitions in the SoC dtsi
  ARM: dts: at91: sama5d2: Move flx0 definitions in the SoC dtsi
  ARM: dts: at91: sama5d2: Specify the FIFO size for the Flexcom UART
  ARM: dts: at91: sama5d2: Add DMA bindings for the SPI and UART flx4
functions
  ARM: dts: at91: sama5d2: Add DMA bindings for the flx3 SPI function
  ARM: dts: at91: sama5d2: Add DMA bindings for the flx1 I2C function
  ARM: dts: at91: sama5d2: Add DMA bindings for the SPI and I2C flx0
functions
  ARM: dts: at91: sama5d2: Add missing flexcom definitions
  ARM: dts: at91: sama5d2: Remove i2s and tcb aliases from SoC dtsi
  ARM: dts: at91: sama5d2_xplained: Add alias for DBGU
  ARM: dts: at91: sama5d2_xplained: Describe the flx0 I2C function
  ARM: dts: at91: sama5d2_ptc_ek: Add comments to describe the aliases

 arch/arm/boot/dts/at91-kizbox3-hs.dts |   4 +-
 arch/arm/boot/dts/at91-kizbox3_common.dtsi|  48 +--
 arch/arm/boot/dts/at91-sama5d27_som1_ek.dts   |  64 +---
 arch/arm/boot/dts/at91-sama5d27_wlsom1.dtsi   |  12 -
 arch/arm/boot/dts/at91-sama5d27_wlsom1_ek.dts |  12 -
 arch/arm/boot/dts/at91-sama5d2_icp.dts|  42 +--
 arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts |  14 +-
 arch/arm/boot/dts/at91-sama5d2_xplained.dts   |  42 ++-
 arch/arm/boot/dts/sama5d2.dtsi| 295 +-
 9 files changed, 347 insertions(+), 186 deletions(-)

-- 
2.23.0


[PATCH 05/16] ARM: dts: at91: sama5d2: Move flx1 definitions in the SoC dtsi

2020-05-13 Thread Tudor.Ambarus
From: Tudor Ambarus 

The Flexcom IP is part of the sama5d2 SoC. Move the flx0 node together
with its function definitions in sama5d2.dtsi. Boards will just fill
the pins and enable the desired functions.

Signed-off-by: Tudor Ambarus 
---
 arch/arm/boot/dts/at91-sama5d27_som1_ek.dts |  7 -
 arch/arm/boot/dts/at91-sama5d27_wlsom1.dtsi | 12 -
 arch/arm/boot/dts/sama5d2.dtsi  | 29 +
 3 files changed, 29 insertions(+), 19 deletions(-)

diff --git a/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts 
b/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts
index abbf14e29d85..a0deff15fb9a 100644
--- a/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts
+++ b/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts
@@ -126,20 +126,13 @@
status = "okay";
 
i2c3: i2c@600 {
-   compatible = "atmel,sama5d2-i2c";
-   reg = <0x600 0x200>;
-   interrupts = <20 IRQ_TYPE_LEVEL_HIGH 7>;
dmas = <0>, <0>;
dma-names = "tx", "rx";
i2c-analog-filter;
i2c-digital-filter;
i2c-digital-filter-width-ns = <35>;
-   #address-cells = <1>;
-   #size-cells = <0>;
-   clocks = < PMC_TYPE_PERIPHERAL 20>;
pinctrl-names = "default";
pinctrl-0 = <_mikrobus_i2c>;
-   atmel,fifo-size = <16>;
status = "okay";
};
};
diff --git a/arch/arm/boot/dts/at91-sama5d27_wlsom1.dtsi 
b/arch/arm/boot/dts/at91-sama5d27_wlsom1.dtsi
index bea3d60b9722..a06700e53e4c 100644
--- a/arch/arm/boot/dts/at91-sama5d27_wlsom1.dtsi
+++ b/arch/arm/boot/dts/at91-sama5d27_wlsom1.dtsi
@@ -36,18 +36,6 @@
atmel,flexcom-mode = ;
 
uart6: serial@200 {
-   compatible = "atmel,at91sam9260-usart";
-   reg = <0x200 0x200>;
-   interrupts = <20 IRQ_TYPE_LEVEL_HIGH 7>;
-   dmas = <
-   (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) |
-AT91_XDMAC_DT_PERID(13))>,
-  <
-   (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) |
-AT91_XDMAC_DT_PERID(14))>;
-   dma-names = "tx", "rx";
-   clocks = < PMC_TYPE_PERIPHERAL 20>;
-   clock-names = "usart";
pinctrl-0 = <_flx1_default>;
pinctrl-names = "default";
};
diff --git a/arch/arm/boot/dts/sama5d2.dtsi b/arch/arm/boot/dts/sama5d2.dtsi
index 89064225e9aa..79ed7bd02df6 100644
--- a/arch/arm/boot/dts/sama5d2.dtsi
+++ b/arch/arm/boot/dts/sama5d2.dtsi
@@ -645,6 +645,35 @@
#size-cells = <1>;
ranges = <0x0 0xf8038000 0x800>;
status = "disabled";
+
+   uart6: serial@200 {
+   compatible = "atmel,at91sam9260-usart";
+   reg = <0x200 0x200>;
+   interrupts = <20 IRQ_TYPE_LEVEL_HIGH 7>;
+   clocks = < PMC_TYPE_PERIPHERAL 20>;
+   clock-names = "usart";
+   dmas = <
+   (AT91_XDMAC_DT_MEM_IF(0) |
+AT91_XDMAC_DT_PER_IF(1) |
+AT91_XDMAC_DT_PERID(13))>,
+  <
+   (AT91_XDMAC_DT_MEM_IF(0) |
+AT91_XDMAC_DT_PER_IF(1) |
+AT91_XDMAC_DT_PERID(14))>;
+   dma-names = "tx", "rx";
+   status = "disabled";
+   };
+
+   i2c3: i2c@600 {
+   compatible = "atmel,sama5d2-i2c";
+   reg = <0x600 0x200>;
+   interrupts = <20 IRQ_TYPE_LEVEL_HIGH 7>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   clocks = < PMC_TYPE_PERIPHERAL 20>;
+   atmel,fifo-size = <16>;
+   status = 

[PATCH 08/16] ARM: dts: at91: sama5d2: Add DMA bindings for the SPI and UART flx4 functions

2020-05-13 Thread Tudor.Ambarus
From: Tudor Ambarus 

Spare boards of duplicating the DMA bindings. Describe the flx4
DMA bindings in the SoC dtsi. Users that don't want to use DMA
for their flexcom functions have to overwrite the flexcom DMA
bindings in their board device tree.

Signed-off-by: Tudor Ambarus 
---
 arch/arm/boot/dts/at91-sama5d27_som1_ek.dts |  2 ++
 arch/arm/boot/dts/sama5d2.dtsi  | 18 ++
 2 files changed, 20 insertions(+)

diff --git a/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts 
b/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts
index a0deff15fb9a..6ad66d034305 100644
--- a/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts
+++ b/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts
@@ -190,12 +190,14 @@
status = "okay";
 
uart9: serial@200 {
+   dmas = <0>, <0>;
pinctrl-names = "default";
pinctrl-0 = <_flx4_default>;
status = "disabled"; /* Conflict with 
spi6 and i2c6. */
};
 
spi6: spi@400 {
+   dmas = <0>, <0>;
pinctrl-names = "default";
pinctrl-0 = <_mikrobus_spi 
_mikrobus1_spi_cs _mikrobus2_spi_cs>;
status = "okay"; /* Conflict with uart5 
and i2c6. */
diff --git a/arch/arm/boot/dts/sama5d2.dtsi b/arch/arm/boot/dts/sama5d2.dtsi
index dde969a140b4..66aa8d6502d3 100644
--- a/arch/arm/boot/dts/sama5d2.dtsi
+++ b/arch/arm/boot/dts/sama5d2.dtsi
@@ -939,6 +939,15 @@
interrupts = <23 IRQ_TYPE_LEVEL_HIGH 7>;
clocks = < PMC_TYPE_PERIPHERAL 23>;
clock-names = "usart";
+   dmas = <
+   (AT91_XDMAC_DT_MEM_IF(0) |
+AT91_XDMAC_DT_PER_IF(1) |
+AT91_XDMAC_DT_PERID(19))>,
+  <
+   (AT91_XDMAC_DT_MEM_IF(0) |
+AT91_XDMAC_DT_PER_IF(1) |
+AT91_XDMAC_DT_PERID(20))>;
+   dma-names = "tx", "rx";
atmel,fifo-size = <32>;
status = "disabled";
};
@@ -949,6 +958,15 @@
interrupts = <23 IRQ_TYPE_LEVEL_HIGH 7>;
clocks = < PMC_TYPE_PERIPHERAL 23>;
clock-names = "spi_clk";
+   dmas = <
+   (AT91_XDMAC_DT_MEM_IF(0) |
+AT91_XDMAC_DT_PER_IF(1) |
+AT91_XDMAC_DT_PERID(19))>,
+  <
+   (AT91_XDMAC_DT_MEM_IF(0) |
+AT91_XDMAC_DT_PER_IF(1) |
+AT91_XDMAC_DT_PERID(20))>;
+   dma-names = "tx", "rx";
atmel,fifo-size = <16>;
status = "disabled";
};
-- 
2.23.0


[PATCH 13/16] ARM: dts: at91: sama5d2: Remove i2s and tcb aliases from SoC dtsi

2020-05-13 Thread Tudor.Ambarus
From: Tudor Ambarus 

Device aliases are board-specific, if needed one should define them
in board dts rather than in the SoC dtsi. If an alias from the SoC
dtsi is addressed by a driver that does not use any of the of_alias*()
methods, we can drop it. This is the case for the i2s aliases, drop
them. tcb aliases point to nodes that are not enabled in any of the
sama5d2 based platforms. atmel_tclib.c is scheduled to go away, any
board using that alias is already broken, so get rid of the tcb aliases
too.

Signed-off-by: Tudor Ambarus 
---
 arch/arm/boot/dts/sama5d2.dtsi | 4 
 1 file changed, 4 deletions(-)

diff --git a/arch/arm/boot/dts/sama5d2.dtsi b/arch/arm/boot/dts/sama5d2.dtsi
index b8cdeedee6bc..c0a3ca8f9bf7 100644
--- a/arch/arm/boot/dts/sama5d2.dtsi
+++ b/arch/arm/boot/dts/sama5d2.dtsi
@@ -21,10 +21,6 @@
aliases {
serial0 = 
serial1 = 
-   tcb0 = 
-   tcb1 = 
-   i2s0 = 
-   i2s1 = 
};
 
cpus {
-- 
2.23.0


[PATCH 16/16] ARM: dts: at91: sama5d2_ptc_ek: Add comments to describe the aliases

2020-05-13 Thread Tudor.Ambarus
From: Tudor Ambarus 

Indicate which i2c alias is for which connector on the board.
Specify that serial0 is for DBGU. This eases tester's life.

Signed-off-by: Tudor Ambarus 
---
 arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts 
b/arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts
index 0e0341c83aa5..45c671a2bcf2 100644
--- a/arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts
+++ b/arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts
@@ -18,9 +18,9 @@
compatible = "atmel,sama5d2-ptc_ek", "atmel,sama5d2", "atmel,sama5";
 
aliases {
-   serial0 = 
-   i2c0= 
-   i2c1= 
+   serial0 =/* DBGU */
+   i2c0= /* mikroBUS 1 */
+   i2c1= /* XPRO EXT1 */
i2c2= 
};
 
-- 
2.23.0


[PATCH 07/16] ARM: dts: at91: sama5d2: Specify the FIFO size for the Flexcom UART

2020-05-13 Thread Tudor.Ambarus
From: Tudor Ambarus 

The UART submodule in Flexcom has 32-byte Transmit and Receive FIFOs.
Tested uart7 on sama5d2-icp, which has both DMA and FIFO enabled.

Signed-off-by: Tudor Ambarus 
---
 arch/arm/boot/dts/sama5d2.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/sama5d2.dtsi b/arch/arm/boot/dts/sama5d2.dtsi
index acb91908bd74..dde969a140b4 100644
--- a/arch/arm/boot/dts/sama5d2.dtsi
+++ b/arch/arm/boot/dts/sama5d2.dtsi
@@ -701,6 +701,7 @@
 AT91_XDMAC_DT_PER_IF(1) |
 AT91_XDMAC_DT_PERID(14))>;
dma-names = "tx", "rx";
+   atmel,fifo-size = <32>;
status = "disabled";
};
 
@@ -879,6 +880,7 @@
 AT91_XDMAC_DT_PER_IF(1) |
 AT91_XDMAC_DT_PERID(16))>;
dma-names = "tx", "rx";
+   atmel,fifo-size = <32>;
status = "disabled";
};
};
-- 
2.23.0


[PATCH 04/16] ARM: dts: at91: sama5d2: Move flx2 definitions in the SoC dtsi

2020-05-13 Thread Tudor.Ambarus
From: Tudor Ambarus 

The Flexcom IP is part of the sama5d2 SoC. Move the flx2 node together
with its function definitions in sama5d2.dtsi. Boards will just fill
the pins and enable the desired functions.

Signed-off-by: Tudor Ambarus 
---
 arch/arm/boot/dts/at91-sama5d2_icp.dts | 12 
 arch/arm/boot/dts/sama5d2.dtsi | 18 ++
 2 files changed, 18 insertions(+), 12 deletions(-)

diff --git a/arch/arm/boot/dts/at91-sama5d2_icp.dts 
b/arch/arm/boot/dts/at91-sama5d2_icp.dts
index 8a4336e12a60..23f413afb333 100644
--- a/arch/arm/boot/dts/at91-sama5d2_icp.dts
+++ b/arch/arm/boot/dts/at91-sama5d2_icp.dts
@@ -160,18 +160,6 @@
status = "okay";
 
uart7: serial@200 {
-   compatible = "atmel,at91sam9260-usart";
-   reg = <0x200 0x200>;
-   interrupts = <21 IRQ_TYPE_LEVEL_HIGH 7>;
-   dmas = <
-   (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) |
-   AT91_XDMAC_DT_PERID(15))>,
-   <
-   (AT91_XDMAC_DT_MEM_IF(0) | 
AT91_XDMAC_DT_PER_IF(1) |
-   AT91_XDMAC_DT_PERID(16))>;
-   dma-names = "tx", "rx";
-   clocks = < PMC_TYPE_PERIPHERAL 21>;
-   clock-names = "usart";
pinctrl-0 = <_flx2_default>;
pinctrl-names = "default";
atmel,use-dma-rx;
diff --git a/arch/arm/boot/dts/sama5d2.dtsi b/arch/arm/boot/dts/sama5d2.dtsi
index 5e84cde8226a..89064225e9aa 100644
--- a/arch/arm/boot/dts/sama5d2.dtsi
+++ b/arch/arm/boot/dts/sama5d2.dtsi
@@ -794,6 +794,24 @@
#size-cells = <1>;
ranges = <0x0 0xfc01 0x800>;
status = "disabled";
+
+   uart7: serial@200 {
+   compatible = "atmel,at91sam9260-usart";
+   reg = <0x200 0x200>;
+   interrupts = <21 IRQ_TYPE_LEVEL_HIGH 7>;
+   clocks = < PMC_TYPE_PERIPHERAL 21>;
+   clock-names = "usart";
+   dmas = <
+   (AT91_XDMAC_DT_MEM_IF(0) |
+AT91_XDMAC_DT_PER_IF(1) |
+AT91_XDMAC_DT_PERID(15))>,
+   <
+   (AT91_XDMAC_DT_MEM_IF(0) |
+AT91_XDMAC_DT_PER_IF(1) |
+AT91_XDMAC_DT_PERID(16))>;
+   dma-names = "tx", "rx";
+   status = "disabled";
+   };
};
 
flx3: flexcom@fc014000 {
-- 
2.23.0


[PATCH 09/16] ARM: dts: at91: sama5d2: Add DMA bindings for the flx3 SPI function

2020-05-13 Thread Tudor.Ambarus
From: Tudor Ambarus 

Spare boards of duplicating the DMA bindings. Describe the flx3
DMA bindings in the SoC dtsi. Users that don't want to use DMA
for their flexcom functions have to overwrite the flexcom DMA
bindings in their board device tree.

Signed-off-by: Tudor Ambarus 
---
 arch/arm/boot/dts/at91-sama5d27_som1_ek.dts | 1 +
 arch/arm/boot/dts/at91-sama5d2_icp.dts  | 1 +
 arch/arm/boot/dts/sama5d2.dtsi  | 9 +
 3 files changed, 11 insertions(+)

diff --git a/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts 
b/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts
index 6ad66d034305..1aa8b79d618b 100644
--- a/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts
+++ b/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts
@@ -179,6 +179,7 @@
};
 
spi5: spi@400 {
+   dmas = <0>, <0>;
pinctrl-names = "default";
pinctrl-0 = <_flx3_default>;
status = "disabled"; /* Conflict with 
isc. */
diff --git a/arch/arm/boot/dts/at91-sama5d2_icp.dts 
b/arch/arm/boot/dts/at91-sama5d2_icp.dts
index 4a01ab8e7e70..559d8ae93af9 100644
--- a/arch/arm/boot/dts/at91-sama5d2_icp.dts
+++ b/arch/arm/boot/dts/at91-sama5d2_icp.dts
@@ -167,6 +167,7 @@
status = "okay";
 
spi5: spi@400 {
+   dmas = <0>, <0>;
pinctrl-names = "default";
pinctrl-0 = <_mikrobus1_spi _mikrobus1_spi_cs>;
status = "okay";
diff --git a/arch/arm/boot/dts/sama5d2.dtsi b/arch/arm/boot/dts/sama5d2.dtsi
index 66aa8d6502d3..5a0162915ae7 100644
--- a/arch/arm/boot/dts/sama5d2.dtsi
+++ b/arch/arm/boot/dts/sama5d2.dtsi
@@ -919,6 +919,15 @@
interrupts = <22 IRQ_TYPE_LEVEL_HIGH 7>;
clocks = < PMC_TYPE_PERIPHERAL 22>;
clock-names = "spi_clk";
+   dmas = <
+   (AT91_XDMAC_DT_MEM_IF(0) |
+AT91_XDMAC_DT_PER_IF(1) |
+AT91_XDMAC_DT_PERID(17))>,
+  <
+   (AT91_XDMAC_DT_MEM_IF(0) |
+AT91_XDMAC_DT_PER_IF(1) |
+AT91_XDMAC_DT_PERID(18))>;
+   dma-names = "tx", "rx";
atmel,fifo-size = <16>;
status = "disabled";
};
-- 
2.23.0


[PATCH 14/16] ARM: dts: at91: sama5d2_xplained: Add alias for DBGU

2020-05-13 Thread Tudor.Ambarus
From: Tudor Ambarus 

The aliases should be defined in the board dts rather than in the
SoC dtsi. Don't rely on the aliases defined in the SoC dtsi and define
the alias for the Serial DBGU in the board dts file. sama5d2 boards use
the "serial0" alias for the Serial DBGU, do the same for sama5d2_xplained.

Signed-off-by: Tudor Ambarus 
---
 arch/arm/boot/dts/at91-sama5d2_xplained.dts | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/at91-sama5d2_xplained.dts 
b/arch/arm/boot/dts/at91-sama5d2_xplained.dts
index da4442715ea5..01ffbddd4ab8 100644
--- a/arch/arm/boot/dts/at91-sama5d2_xplained.dts
+++ b/arch/arm/boot/dts/at91-sama5d2_xplained.dts
@@ -16,6 +16,10 @@
model = "Atmel SAMA5D2 Xplained";
compatible = "atmel,sama5d2-xplained", "atmel,sama5d2", "atmel,sama5";
 
+   aliases {
+   serial0 =/* DBGU */
+   };
+
chosen {
stdout-path = "serial0:115200n8";
};
-- 
2.23.0


[PATCH 12/16] ARM: dts: at91: sama5d2: Add missing flexcom definitions

2020-05-13 Thread Tudor.Ambarus
From: Tudor Ambarus 

Describe all the flexcom functions for all the flexcom nodes.

Signed-off-by: Tudor Ambarus 
---
 arch/arm/boot/dts/sama5d2.dtsi | 79 ++
 1 file changed, 79 insertions(+)

diff --git a/arch/arm/boot/dts/sama5d2.dtsi b/arch/arm/boot/dts/sama5d2.dtsi
index 5bba8024f485..b8cdeedee6bc 100644
--- a/arch/arm/boot/dts/sama5d2.dtsi
+++ b/arch/arm/boot/dts/sama5d2.dtsi
@@ -723,6 +723,25 @@
status = "disabled";
};
 
+   spi3: spi@400 {
+   compatible = "atmel,at91rm9200-spi";
+   reg = <0x400 0x200>;
+   interrupts = <20 IRQ_TYPE_LEVEL_HIGH 7>;
+   clocks = < PMC_TYPE_PERIPHERAL 20>;
+   clock-names = "spi_clk";
+   dmas = <
+   (AT91_XDMAC_DT_MEM_IF(0) |
+AT91_XDMAC_DT_PER_IF(1) |
+AT91_XDMAC_DT_PERID(13))>,
+  <
+   (AT91_XDMAC_DT_MEM_IF(0) |
+AT91_XDMAC_DT_PER_IF(1) |
+AT91_XDMAC_DT_PERID(14))>;
+   dma-names = "tx", "rx";
+   atmel,fifo-size = <16>;
+   status = "disabled";
+   };
+
i2c3: i2c@600 {
compatible = "atmel,sama5d2-i2c";
reg = <0x600 0x200>;
@@ -910,6 +929,45 @@
atmel,fifo-size = <32>;
status = "disabled";
};
+
+   spi4: spi@400 {
+   compatible = "atmel,at91rm9200-spi";
+   reg = <0x400 0x200>;
+   interrupts = <21 IRQ_TYPE_LEVEL_HIGH 7>;
+   clocks = < PMC_TYPE_PERIPHERAL 21>;
+   clock-names = "spi_clk";
+   dmas = <
+   (AT91_XDMAC_DT_MEM_IF(0) |
+AT91_XDMAC_DT_PER_IF(1) |
+AT91_XDMAC_DT_PERID(15))>,
+   <
+   (AT91_XDMAC_DT_MEM_IF(0) |
+AT91_XDMAC_DT_PER_IF(1) |
+AT91_XDMAC_DT_PERID(16))>;
+   dma-names = "tx", "rx";
+   atmel,fifo-size = <16>;
+   status = "disabled";
+   };
+
+   i2c4: i2c@600 {
+   compatible = "atmel,sama5d2-i2c";
+   reg = <0x600 0x200>;
+   interrupts = <21 IRQ_TYPE_LEVEL_HIGH 7>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   clocks = < PMC_TYPE_PERIPHERAL 21>;
+   dmas = <
+   (AT91_XDMAC_DT_MEM_IF(0) |
+AT91_XDMAC_DT_PER_IF(1) |
+AT91_XDMAC_DT_PERID(15))>,
+   <
+   (AT91_XDMAC_DT_MEM_IF(0) |
+AT91_XDMAC_DT_PER_IF(1) |
+AT91_XDMAC_DT_PERID(16))>;
+   dma-names = "tx", "rx";
+   atmel,fifo-size = <16>;
+   status = "disabled";
+   };
};
 
flx3: flexcom@fc014000 {
@@ -958,6 +1016,27 @@
atmel,fifo-size = <16>;
status = "disabled";
};
+
+   i2c5: i2c@600 {
+   compatible = "atmel,sama5d2-i2c";
+   reg = <0x600 0x200>;
+   

[PATCH 15/16] ARM: dts: at91: sama5d2_xplained: Describe the flx0 I2C function

2020-05-13 Thread Tudor.Ambarus
From: Tudor Ambarus 

Users can choose which flexcom function to use. Describe the I2C
Flexcom0 function. Add alias for the i2c2 node in order to not rely
on probe order for the i2c device numbering. The sama5d2 SoC has
two dedicated i2c buses and five flexcoms that can function as i2c.
The i2c0 and i2c1 aliases are kept for the dedicated i2c buses,
the i2c flexcom functions can be numbered in order starting from i2c2.

Signed-off-by: Tudor Ambarus 
---
 arch/arm/boot/dts/at91-sama5d2_xplained.dts | 21 +
 1 file changed, 21 insertions(+)

diff --git a/arch/arm/boot/dts/at91-sama5d2_xplained.dts 
b/arch/arm/boot/dts/at91-sama5d2_xplained.dts
index 01ffbddd4ab8..77e5d4f5a102 100644
--- a/arch/arm/boot/dts/at91-sama5d2_xplained.dts
+++ b/arch/arm/boot/dts/at91-sama5d2_xplained.dts
@@ -18,6 +18,7 @@
 
aliases {
serial0 =/* DBGU */
+   i2c2 =/* XPRO EXT2 */
};
 
chosen {
@@ -336,6 +337,20 @@
pinctrl-0 = <_flx0_default>;
status = "okay";
};
+
+   i2c2: i2c@600 {
+   dmas = <0>, <0>;
+   pinctrl-names = "default", "gpio";
+   pinctrl-0 = <_flx0_default>;
+   pinctrl-1 = <_i2c2_gpio>;
+   sda-gpios = < PIN_PB28 
GPIO_ACTIVE_HIGH>;
+   scl-gpios = < PIN_PB29 
GPIO_ACTIVE_HIGH>;
+   i2c-sda-hold-time-ns = <350>;
+   i2c-analog-filter;
+   i2c-digital-filter;
+   i2c-digital-filter-width-ns = <35>;
+   status = "disabled"; /* conflict with 
ISC_D2 & ISC_D3 data pins */
+   };
};
 
shdwc@f8048010 {
@@ -523,6 +538,12 @@
bias-disable;
};
 
+   pinctrl_i2c2_gpio: i2c2_gpio {
+   pinmux = ,
+;
+   bias-disable;
+   };
+
pinctrl_i2s0_default: i2s0_default {
pinmux = ,
 ,
-- 
2.23.0


[PATCH 11/16] ARM: dts: at91: sama5d2: Add DMA bindings for the SPI and I2C flx0 functions

2020-05-13 Thread Tudor.Ambarus
From: Tudor Ambarus 

Spare boards of duplicating the DMA bindings. Describe the flx0
DMA bindings in the SoC dtsi. Users that don't want to use DMA
for their flexcom functions have to overwrite the flexcom DMA
bindings in their board device tree.

Signed-off-by: Tudor Ambarus 
---
 arch/arm/boot/dts/at91-sama5d2_icp.dts|  1 +
 arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts |  1 -
 arch/arm/boot/dts/sama5d2.dtsi| 18 ++
 3 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/at91-sama5d2_icp.dts 
b/arch/arm/boot/dts/at91-sama5d2_icp.dts
index 559d8ae93af9..8d19925fc09e 100644
--- a/arch/arm/boot/dts/at91-sama5d2_icp.dts
+++ b/arch/arm/boot/dts/at91-sama5d2_icp.dts
@@ -105,6 +105,7 @@
status = "okay";
 
spi2: spi@400 {
+   dmas = <0>, <0>;
cs-gpios = < PIN_PC0 GPIO_ACTIVE_LOW>;
pinctrl-names = "default";
pinctrl-0 = <_mikrobus2_spi _ksz_spi_cs>;
diff --git a/arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts 
b/arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts
index 8ad3a9c6c536..0e0341c83aa5 100644
--- a/arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts
+++ b/arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts
@@ -192,7 +192,6 @@
 
i2c2: i2c@600 {
dmas = <0>, <0>;
-   dma-names = "tx", "rx";
pinctrl-names = "default", "gpio";
pinctrl-0 = <_flx0_default>;
pinctrl-1 = <_flx0_gpio>;
diff --git a/arch/arm/boot/dts/sama5d2.dtsi b/arch/arm/boot/dts/sama5d2.dtsi
index 855846c74a32..5bba8024f485 100644
--- a/arch/arm/boot/dts/sama5d2.dtsi
+++ b/arch/arm/boot/dts/sama5d2.dtsi
@@ -661,6 +661,15 @@
interrupts = <19 IRQ_TYPE_LEVEL_HIGH 7>;
clocks = < PMC_TYPE_PERIPHERAL 19>;
clock-names = "spi_clk";
+   dmas = <
+   (AT91_XDMAC_DT_MEM_IF(0) |
+AT91_XDMAC_DT_PER_IF(1) |
+AT91_XDMAC_DT_PERID(11))>,
+  <
+   (AT91_XDMAC_DT_MEM_IF(0) |
+AT91_XDMAC_DT_PER_IF(1) |
+AT91_XDMAC_DT_PERID(12))>;
+   dma-names = "tx", "rx";
atmel,fifo-size = <16>;
status = "disabled";
};
@@ -672,6 +681,15 @@
#address-cells = <1>;
#size-cells = <0>;
clocks = < PMC_TYPE_PERIPHERAL 19>;
+   dmas = <
+   (AT91_XDMAC_DT_MEM_IF(0) |
+AT91_XDMAC_DT_PER_IF(1) |
+AT91_XDMAC_DT_PERID(11))>,
+  <
+   (AT91_XDMAC_DT_MEM_IF(0) |
+AT91_XDMAC_DT_PER_IF(1) |
+AT91_XDMAC_DT_PERID(12))>;
+   dma-names = "tx", "rx";
atmel,fifo-size = <16>;
status = "disabled";
};
-- 
2.23.0


Re: [patch V4 part 4 07/24] x86/traps: Split int3 handler up

2020-05-13 Thread Andy Lutomirski
On Tue, May 5, 2020 at 7:16 AM Thomas Gleixner  wrote:
>
> For code simplicity split up the int3 handler into a kernel and user part
> which makes the code flow simpler to understand.
>
> Signed-off-by: Peter Zijlstra (Intel) 
> Signed-off-by: Thomas Gleixner 
> ---
>  arch/x86/kernel/traps.c |   67 
> +++-
>  1 file changed, 39 insertions(+), 28 deletions(-)
>
> --- a/arch/x86/kernel/traps.c
> +++ b/arch/x86/kernel/traps.c
> @@ -564,6 +564,35 @@ DEFINE_IDTENTRY_ERRORCODE(exc_general_pr
> cond_local_irq_disable(regs);
>  }
>
> +static bool do_int3(struct pt_regs *regs)
> +{
> +   int res;
> +
> +#ifdef CONFIG_KGDB_LOW_LEVEL_TRAP
> +   if (kgdb_ll_trap(DIE_INT3, "int3", regs, 0, X86_TRAP_BP,
> +SIGTRAP) == NOTIFY_STOP)
> +   return true;
> +#endif /* CONFIG_KGDB_LOW_LEVEL_TRAP */
> +
> +#ifdef CONFIG_KPROBES
> +   if (kprobe_int3_handler(regs))
> +   return true;
> +#endif
> +   res = notify_die(DIE_INT3, "int3", regs, 0, X86_TRAP_BP, SIGTRAP);
> +
> +   return res == NOTIFY_STOP;
> +}
> +
> +static void do_int3_user(struct pt_regs *regs)
> +{
> +   if (do_int3(regs))
> +   return;
> +
> +   cond_local_irq_enable(regs);
> +   do_trap(X86_TRAP_BP, SIGTRAP, "int3", regs, 0, 0, NULL);
> +   cond_local_irq_disable(regs);
> +}
> +
>  DEFINE_IDTENTRY_RAW(exc_int3)
>  {
> /*
> @@ -581,37 +610,19 @@ DEFINE_IDTENTRY_RAW(exc_int3)
>  * because the INT3 could have been hit in any context including
>  * NMI.
>  */
> -   if (user_mode(regs))
> +   if (user_mode(regs)) {
> idtentry_enter(regs);
> -   else
> -   nmi_enter();
> -
> -   instr_begin();
> -#ifdef CONFIG_KGDB_LOW_LEVEL_TRAP
> -   if (kgdb_ll_trap(DIE_INT3, "int3", regs, 0, X86_TRAP_BP,
> -   SIGTRAP) == NOTIFY_STOP)
> -   goto exit;
> -#endif /* CONFIG_KGDB_LOW_LEVEL_TRAP */
> -
> -#ifdef CONFIG_KPROBES
> -   if (kprobe_int3_handler(regs))
> -   goto exit;
> -#endif
> -
> -   if (notify_die(DIE_INT3, "int3", regs, 0, X86_TRAP_BP,
> -   SIGTRAP) == NOTIFY_STOP)
> -   goto exit;
> -
> -   cond_local_irq_enable(regs);
> -   do_trap(X86_TRAP_BP, SIGTRAP, "int3", regs, 0, 0, NULL);
> -   cond_local_irq_disable(regs);
> -
> -exit:
> -   instr_end();
> -   if (user_mode(regs))
> +   instr_begin();
> +   do_int3_user(regs);
> +   instr_end();
> idtentry_exit(regs);
> -   else
> +   } else {
> +   nmi_enter();
> +   instr_begin();
> +   do_int3(regs);

I think you should be checking the return value here.  Presumably this
should die() if it's not handled, since otherwise it will just
infinite loop.

> +   instr_end();
> nmi_exit();
> +   }
>  }
>
>  #ifdef CONFIG_X86_64
>


[PATCH 01/16] ARM: dts: at91: sama5d2: Fix the label numbering for flexcom functions

2020-05-13 Thread Tudor.Ambarus
From: Tudor Ambarus 

The sama5d2 SoC has the following IPs: [uart0, uart4], {spi0, spi1}, {i2c0, 
i2c1}.
Label the flexcom functions in order:
flx0: uart5, spi2, i2c2
flx1: uart6, spi3, i2c3
flx2: uart7, spi4, i2c4
flx3: uart8, spi5, i2c5
flx4: uart9, spi6, i2c6

Some boards respected this scheme, others not. Fix the ones that didn't.

Signed-off-by: Tudor Ambarus 
---
 arch/arm/boot/dts/at91-kizbox3-hs.dts   |  4 ++--
 arch/arm/boot/dts/at91-kizbox3_common.dtsi  |  8 
 arch/arm/boot/dts/at91-sama5d27_som1_ek.dts | 20 ++--
 arch/arm/boot/dts/at91-sama5d2_icp.dts  |  8 
 arch/arm/boot/dts/at91-sama5d2_xplained.dts |  2 +-
 5 files changed, 21 insertions(+), 21 deletions(-)

diff --git a/arch/arm/boot/dts/at91-kizbox3-hs.dts 
b/arch/arm/boot/dts/at91-kizbox3-hs.dts
index 8734e7f8939e..0da1f0557eaf 100644
--- a/arch/arm/boot/dts/at91-kizbox3-hs.dts
+++ b/arch/arm/boot/dts/at91-kizbox3-hs.dts
@@ -283,7 +283,7 @@
 
  {
status = "okay";
-   uart6: serial@200 {
+   uart8: serial@200 {
status = "okay";
};
 };
@@ -291,7 +291,7 @@
  {
status = "okay";
 
-   i2c2: i2c@600 {
+   i2c6: i2c@600 {
status = "okay";
};
 };
diff --git a/arch/arm/boot/dts/at91-kizbox3_common.dtsi 
b/arch/arm/boot/dts/at91-kizbox3_common.dtsi
index 299e74d23184..d7a6c972bdac 100644
--- a/arch/arm/boot/dts/at91-kizbox3_common.dtsi
+++ b/arch/arm/boot/dts/at91-kizbox3_common.dtsi
@@ -28,7 +28,7 @@
serial3 = 
serial4 = 
serial5 = 
-   serial6 = 
+   serial6 = 
};
 
chosen {
@@ -207,7 +207,7 @@
};
};
 
-   pinctrl_flx4_default: flx4_i2c2_default {
+   pinctrl_flx4_default: flx4_i2c6_default {
pinmux = , //DATA
; //CLK
bias-disable;
@@ -324,7 +324,7 @@
atmel,flexcom-mode = ;
status = "disabled";
 
-   uart6: serial@200 {
+   uart8: serial@200 {
compatible = "atmel,at91sam9260-usart";
reg = <0x200 0x400>;
interrupts = <22 IRQ_TYPE_LEVEL_HIGH 7>;
@@ -350,7 +350,7 @@
atmel,flexcom-mode = ;
status = "disabled";
 
-   i2c2: i2c@600 {
+   i2c6: i2c@600 {
compatible = "atmel,sama5d2-i2c";
reg = <0x600 0x200>;
interrupts = <23 IRQ_TYPE_LEVEL_HIGH 7>;
diff --git a/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts 
b/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts
index b0853bf7901c..d215243fe163 100644
--- a/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts
+++ b/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts
@@ -21,7 +21,7 @@
serial1 =/* mikro BUS 1 */
serial2 =/* mikro BUS 2 */
i2c1= 
-   i2c2= 
+   i2c2= 
};
 
chosen {
@@ -125,7 +125,7 @@
atmel,flexcom-mode = ;
status = "okay";
 
-   i2c2: i2c@600 {
+   i2c3: i2c@600 {
compatible = "atmel,sama5d2-i2c";
reg = <0x600 0x200>;
interrupts = <20 IRQ_TYPE_LEVEL_HIGH 7>;
@@ -178,7 +178,7 @@
atmel,flexcom-mode = ;
status = "disabled";
 
-   uart7: serial@200 {
+   uart8: serial@200 {
compatible = "atmel,at91sam9260-usart";
reg = <0x200 0x200>;
interrupts = <22 IRQ_TYPE_LEVEL_HIGH 7>;
@@ -190,7 +190,7 @@
status = "disabled"; /* Conflict with 
isc. */
};
 
-   spi2: spi@400 {
+   spi5: spi@400 {
compatible = "atmel,at91rm9200-spi";
reg = <0x400 0x200>;
interrupts = <22 IRQ_TYPE_LEVEL_HIGH 7>;
@@ -207,7 +207,7 @@
atmel,flexcom-mode = ;
status = "okay";
 
-   uart6: serial@200 {
+   uart9: serial@200 {
compatible = "atmel,at91sam9260-usart";
reg = <0x200 0x200>;
interrupts = <23 IRQ_TYPE_LEVEL_HIGH 7>;
@@ -216,10 +216,10 @@
pinctrl-names = "default";
pinctrl-0 = <_flx4_default>;
atmel,fifo-size = <32>;
-  

[PATCH 03/16] ARM: dts: at91: sama5d2: Move flx3 definitions in the SoC dtsi

2020-05-13 Thread Tudor.Ambarus
From: Tudor Ambarus 

The Flexcom IP is part of the sama5d2 SoC. Move the flx3 node together
with its function definitions in sama5d2.dtsi. Boards will just fill
the pins and enable the desired functions.

Signed-off-by: Tudor Ambarus 
---
 arch/arm/boot/dts/at91-kizbox3_common.dtsi  | 13 -
 arch/arm/boot/dts/at91-sama5d27_som1_ek.dts | 13 +
 arch/arm/boot/dts/at91-sama5d2_icp.dts  |  6 -
 arch/arm/boot/dts/sama5d2.dtsi  | 29 +
 4 files changed, 30 insertions(+), 31 deletions(-)

diff --git a/arch/arm/boot/dts/at91-kizbox3_common.dtsi 
b/arch/arm/boot/dts/at91-kizbox3_common.dtsi
index ee6f036aa008..4351a8d32225 100644
--- a/arch/arm/boot/dts/at91-kizbox3_common.dtsi
+++ b/arch/arm/boot/dts/at91-kizbox3_common.dtsi
@@ -325,21 +325,8 @@
status = "disabled";
 
uart8: serial@200 {
-   compatible = "atmel,at91sam9260-usart";
-   reg = <0x200 0x400>;
-   interrupts = <22 IRQ_TYPE_LEVEL_HIGH 7>;
-   dmas = <
-   (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1)
-   | AT91_XDMAC_DT_PERID(17))>,
-  <
-   (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1)
-   | AT91_XDMAC_DT_PERID(18))>;
-   dma-names = "tx", "rx";
-   clocks = < PMC_TYPE_PERIPHERAL 22>;
-   clock-names = "usart";
pinctrl-names = "default";
pinctrl-0 = <_flx3_default>;
-   atmel,fifo-size = <32>;
atmel,use-dma-rx;
atmel,use-dma-tx;
status = "disabled";
diff --git a/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts 
b/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts
index 5f4a7c8725f3..abbf14e29d85 100644
--- a/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts
+++ b/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts
@@ -179,26 +179,15 @@
status = "disabled";
 
uart8: serial@200 {
-   compatible = "atmel,at91sam9260-usart";
-   reg = <0x200 0x200>;
-   interrupts = <22 IRQ_TYPE_LEVEL_HIGH 7>;
-   clocks = < PMC_TYPE_PERIPHERAL 22>;
-   clock-names = "usart";
+   dmas = <0>, <0>;
pinctrl-names = "default";
pinctrl-0 = <_flx3_default>;
-   atmel,fifo-size = <32>;
status = "disabled"; /* Conflict with 
isc. */
};
 
spi5: spi@400 {
-   compatible = "atmel,at91rm9200-spi";
-   reg = <0x400 0x200>;
-   interrupts = <22 IRQ_TYPE_LEVEL_HIGH 7>;
-   clocks = < PMC_TYPE_PERIPHERAL 22>;
-   clock-names = "spi_clk";
pinctrl-names = "default";
pinctrl-0 = <_flx3_default>;
-   atmel,fifo-size = <16>;
status = "disabled"; /* Conflict with 
isc. */
};
};
diff --git a/arch/arm/boot/dts/at91-sama5d2_icp.dts 
b/arch/arm/boot/dts/at91-sama5d2_icp.dts
index 7216a794f4f6..8a4336e12a60 100644
--- a/arch/arm/boot/dts/at91-sama5d2_icp.dts
+++ b/arch/arm/boot/dts/at91-sama5d2_icp.dts
@@ -185,14 +185,8 @@
status = "okay";
 
spi5: spi@400 {
-   compatible = "atmel,at91rm9200-spi";
-   reg = <0x400 0x200>;
-   interrupts = <22 IRQ_TYPE_LEVEL_HIGH 7>;
-   clocks = < PMC_TYPE_PERIPHERAL 22>;
-   clock-names = "spi_clk";
pinctrl-names = "default";
pinctrl-0 = <_mikrobus1_spi _mikrobus1_spi_cs>;
-   atmel,fifo-size = <16>;
status = "okay";
};
 };
diff --git a/arch/arm/boot/dts/sama5d2.dtsi b/arch/arm/boot/dts/sama5d2.dtsi
index 5c31e4068eb5..5e84cde8226a 100644
--- a/arch/arm/boot/dts/sama5d2.dtsi
+++ b/arch/arm/boot/dts/sama5d2.dtsi
@@ -804,6 +804,35 @@
#size-cells = <1>;
ranges = <0x0 0xfc014000 0x800>;
status = "disabled";
+
+   uart8: serial@200 {
+   compatible = "atmel,at91sam9260-usart";
+   reg = <0x200 0x200>;
+   interrupts = <22 IRQ_TYPE_LEVEL_HIGH 7>;
+   clocks = < 

[PATCH 02/16] ARM: dts: at91: sama5d2: Move flx4 definitions in the SoC dtsi

2020-05-13 Thread Tudor.Ambarus
From: Tudor Ambarus 

The Flexcom IP is part of the sama5d2 SoC. Move the flx0 node together
with its function definitions in sama5d2.dtsi. Boards will just fill
the pins and enable the desired functions.

Signed-off-by: Tudor Ambarus 
---
 arch/arm/boot/dts/at91-kizbox3_common.dtsi  | 14 
 arch/arm/boot/dts/at91-sama5d27_som1_ek.dts | 20 ---
 arch/arm/boot/dts/at91-sama5d2_icp.dts  |  8 -
 arch/arm/boot/dts/at91-sama5d2_xplained.dts |  8 -
 arch/arm/boot/dts/sama5d2.dtsi  | 40 +
 5 files changed, 40 insertions(+), 50 deletions(-)

diff --git a/arch/arm/boot/dts/at91-kizbox3_common.dtsi 
b/arch/arm/boot/dts/at91-kizbox3_common.dtsi
index d7a6c972bdac..ee6f036aa008 100644
--- a/arch/arm/boot/dts/at91-kizbox3_common.dtsi
+++ b/arch/arm/boot/dts/at91-kizbox3_common.dtsi
@@ -351,22 +351,8 @@
status = "disabled";
 
i2c6: i2c@600 {
-   compatible = "atmel,sama5d2-i2c";
-   reg = <0x600 0x200>;
-   interrupts = <23 IRQ_TYPE_LEVEL_HIGH 7>;
-   dmas = <
-   (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1)
-   | AT91_XDMAC_DT_PERID(19))>,
-  <
-   (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1)
-   | AT91_XDMAC_DT_PERID(20))>;
-   dma-names = "tx", "rx";
-   #address-cells = <1>;
-   #size-cells = <0>;
-   clocks = < PMC_TYPE_PERIPHERAL 23>;
pinctrl-names = "default";
pinctrl-0 = <_flx4_default>;
-   atmel,fifo-size = <16>;
status = "disabled";
};
 };
diff --git a/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts 
b/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts
index d215243fe163..5f4a7c8725f3 100644
--- a/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts
+++ b/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts
@@ -208,41 +208,21 @@
status = "okay";
 
uart9: serial@200 {
-   compatible = "atmel,at91sam9260-usart";
-   reg = <0x200 0x200>;
-   interrupts = <23 IRQ_TYPE_LEVEL_HIGH 7>;
-   clocks = < PMC_TYPE_PERIPHERAL 23>;
-   clock-names = "usart";
pinctrl-names = "default";
pinctrl-0 = <_flx4_default>;
-   atmel,fifo-size = <32>;
status = "disabled"; /* Conflict with 
spi6 and i2c6. */
};
 
spi6: spi@400 {
-   compatible = "atmel,at91rm9200-spi";
-   reg = <0x400 0x200>;
-   interrupts = <23 IRQ_TYPE_LEVEL_HIGH 7>;
-   clocks = < PMC_TYPE_PERIPHERAL 23>;
-   clock-names = "spi_clk";
pinctrl-names = "default";
pinctrl-0 = <_mikrobus_spi 
_mikrobus1_spi_cs _mikrobus2_spi_cs>;
-   atmel,fifo-size = <16>;
status = "okay"; /* Conflict with uart5 
and i2c6. */
};
 
i2c6: i2c@600 {
-   compatible = "atmel,sama5d2-i2c";
-   reg = <0x600 0x200>;
-   interrupts = <23 IRQ_TYPE_LEVEL_HIGH 7>;
dmas = <0>, <0>;
-   dma-names = "tx", "rx";
-   #address-cells = <1>;
-   #size-cells = <0>;
-   clocks = < PMC_TYPE_PERIPHERAL 23>;
pinctrl-names = "default";
pinctrl-0 = <_flx4_default>;
-   atmel,fifo-size = <16>;
status = "disabled"; /* Conflict with 
uart5 and spi6. */
};
};
diff --git a/arch/arm/boot/dts/at91-sama5d2_icp.dts 
b/arch/arm/boot/dts/at91-sama5d2_icp.dts
index 1d9556dbbd63..7216a794f4f6 100644
--- a/arch/arm/boot/dts/at91-sama5d2_icp.dts
+++ b/arch/arm/boot/dts/at91-sama5d2_icp.dts
@@ -202,17 +202,9 @@
status = "okay";
 
i2c6: i2c@600 {
-   compatible = "atmel,sama5d2-i2c";
-   reg = <0x600 0x200>;
-   interrupts = <23 IRQ_TYPE_LEVEL_HIGH 7>;
dmas = <0>, <0>;
-   dma-names = "tx", 

Re: [PATCH v2 03/12] remoteproc: stm32: Decouple rproc from DT parsing

2020-05-13 Thread Bjorn Andersson
On Fri 24 Apr 13:24 PDT 2020, Mathieu Poirier wrote:

> Remove the remote processor from the process of parsing the device tree
> since (1) there is no correlation between them and (2) to use the
> information that was gathered to make a decision on whether to
> synchronise with the M4 or not.
> 
> Signed-off-by: Mathieu Poirier 

Reviewed-by: Bjorn Andersson 

> ---
>  drivers/remoteproc/stm32_rproc.c | 25 ++---
>  1 file changed, 14 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/remoteproc/stm32_rproc.c 
> b/drivers/remoteproc/stm32_rproc.c
> index 1ac90adba9b1..57a426ea620b 100644
> --- a/drivers/remoteproc/stm32_rproc.c
> +++ b/drivers/remoteproc/stm32_rproc.c
> @@ -538,12 +538,11 @@ static int stm32_rproc_get_syscon(struct device_node 
> *np, const char *prop,
>   return err;
>  }
>  
> -static int stm32_rproc_parse_dt(struct platform_device *pdev)
> +static int stm32_rproc_parse_dt(struct platform_device *pdev,
> + struct stm32_rproc *ddata, bool *auto_boot)
>  {
>   struct device *dev = >dev;
>   struct device_node *np = dev->of_node;
> - struct rproc *rproc = platform_get_drvdata(pdev);
> - struct stm32_rproc *ddata = rproc->priv;
>   struct stm32_syscon tz;
>   unsigned int tzen;
>   int err, irq;
> @@ -589,7 +588,7 @@ static int stm32_rproc_parse_dt(struct platform_device 
> *pdev)
>  
>   err = regmap_read(tz.map, tz.reg, );
>   if (err) {
> - dev_err(>dev, "failed to read tzen\n");
> + dev_err(dev, "failed to read tzen\n");
>   return err;
>   }
>   ddata->secured_soc = tzen & tz.mask;
> @@ -605,7 +604,7 @@ static int stm32_rproc_parse_dt(struct platform_device 
> *pdev)
>   if (err)
>   dev_info(dev, "failed to get pdds\n");
>  
> - rproc->auto_boot = of_property_read_bool(np, "st,auto-boot");
> + *auto_boot = of_property_read_bool(np, "st,auto-boot");
>  
>   return stm32_rproc_of_memory_translations(pdev, ddata);
>  }
> @@ -616,6 +615,7 @@ static int stm32_rproc_probe(struct platform_device *pdev)
>   struct stm32_rproc *ddata;
>   struct device_node *np = dev->of_node;
>   struct rproc *rproc;
> + bool auto_boot = false;
>   int ret;
>  
>   ret = dma_coerce_mask_and_coherent(dev, DMA_BIT_MASK(32));
> @@ -626,9 +626,16 @@ static int stm32_rproc_probe(struct platform_device 
> *pdev)
>   if (!rproc)
>   return -ENOMEM;
>  
> + ddata = rproc->priv;
> +
>   rproc_coredump_set_elf_info(rproc, ELFCLASS32, EM_NONE);
> +
> + ret = stm32_rproc_parse_dt(pdev, ddata, _boot);
> + if (ret)
> + goto free_rproc;
> +
> + rproc->auto_boot = auto_boot;
>   rproc->has_iommu = false;
> - ddata = rproc->priv;
>   ddata->workqueue = create_workqueue(dev_name(dev));
>   if (!ddata->workqueue) {
>   dev_err(dev, "cannot create workqueue\n");
> @@ -638,13 +645,9 @@ static int stm32_rproc_probe(struct platform_device 
> *pdev)
>  
>   platform_set_drvdata(pdev, rproc);
>  
> - ret = stm32_rproc_parse_dt(pdev);
> - if (ret)
> - goto free_wkq;
> -
>   ret = stm32_rproc_request_mbox(rproc);
>   if (ret)
> - goto free_rproc;
> + goto free_wkq;
>  
>   ret = rproc_add(rproc);
>   if (ret)
> -- 
> 2.20.1
> 


Re: [patch V4 part 4 06/24] x86/entry: Convert INT3 exception to IDTENTRY_RAW

2020-05-13 Thread Andy Lutomirski
On Tue, May 5, 2020 at 7:15 AM Thomas Gleixner  wrote:
>
> Convert #BP to IDTENTRY_RAW:
>   - Implement the C entry point with DEFINE_IDTENTRY_RAW
>   - Invoke idtentry_enter/exit() from the function body
>   - Emit the ASM stub with DECLARE_IDTENTRY_RAW
>   - Remove the ASM idtentry in 64bit
>   - Remove the open coded ASM entry code in 32bit
>   - Fixup the XEN/PV code
>   - Remove the old prototypes

Gmail is so amused by your prototypo that it fixes it sometimes in the
quoted text.  See just above :)


Acked-by: Andy Lutomirski 


Re: [patch V4 part 4 05/24] x86/entry: Provide IDTENTRY_RAW

2020-05-13 Thread Andy Lutomirski
On Tue, May 5, 2020 at 7:15 AM Thomas Gleixner  wrote:
>
> Some exception handlers need to do extra work before any of the entry
> helpers are invoked. Provide IDTENTRY_RAW for this.


Acked-by: Andy Lutomirski 


Re: [patch V4 part 4 04/24] x86/int3: Inline bsearch()

2020-05-13 Thread Andy Lutomirski
On Tue, May 5, 2020 at 7:15 AM Thomas Gleixner  wrote:
>
> From: Peter Zijlstra 
>
> Avoid calling out to bsearch() by inlining it, for normal kernel configs
> this was the last external call and poke_int3_handler() is now fully self
> sufficient -- no calls to external code.
>


Acked-by: Andy Lutomirski 


Re: [PATCH v2 02/12] remoteproc: stm32: Request IRQ with platform device

2020-05-13 Thread Bjorn Andersson
On Fri 24 Apr 13:24 PDT 2020, Mathieu Poirier wrote:

> Request IRQ with platform device rather than remote proc in order to
> call stm32_rproc_parse_dt() before rproc_alloc().  That way we can
> know whether we need to synchronise with the MCU or not.
> 
> Signed-off-by: Mathieu Poirier 
> Reviewed-by: Loic Pallardy 

Reviewed-by: Bjorn Andersson 

> ---
>  drivers/remoteproc/stm32_rproc.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/remoteproc/stm32_rproc.c 
> b/drivers/remoteproc/stm32_rproc.c
> index 91fd59af0ffe..1ac90adba9b1 100644
> --- a/drivers/remoteproc/stm32_rproc.c
> +++ b/drivers/remoteproc/stm32_rproc.c
> @@ -261,7 +261,8 @@ static int stm32_rproc_parse_fw(struct rproc *rproc, 
> const struct firmware *fw)
>  
>  static irqreturn_t stm32_rproc_wdg(int irq, void *data)
>  {
> - struct rproc *rproc = data;
> + struct platform_device *pdev = data;
> + struct rproc *rproc = platform_get_drvdata(pdev);
>  
>   rproc_report_crash(rproc, RPROC_WATCHDOG);
>  
> @@ -553,7 +554,7 @@ static int stm32_rproc_parse_dt(struct platform_device 
> *pdev)
>  
>   if (irq > 0) {
>   err = devm_request_irq(dev, irq, stm32_rproc_wdg, 0,
> -dev_name(dev), rproc);
> +dev_name(dev), pdev);
>   if (err) {
>   dev_err(dev, "failed to request wdg irq\n");
>   return err;
> -- 
> 2.20.1
> 


Re: [PATCH v2 01/12] remoteproc: stm32: Decouple rproc from memory translation

2020-05-13 Thread Bjorn Andersson
On Fri 24 Apr 13:24 PDT 2020, Mathieu Poirier wrote:

> Remove the remote processor from the process of parsing the memory
> ranges since there is no correlation between them.
> 
> Signed-off-by: Mathieu Poirier 
> Reviewed-by: Loic Pallardy 

Reviewed-by: Bjorn Andersson 

> ---
>  drivers/remoteproc/stm32_rproc.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/remoteproc/stm32_rproc.c 
> b/drivers/remoteproc/stm32_rproc.c
> index 0f9d02ca4f5a..91fd59af0ffe 100644
> --- a/drivers/remoteproc/stm32_rproc.c
> +++ b/drivers/remoteproc/stm32_rproc.c
> @@ -127,10 +127,10 @@ static int stm32_rproc_mem_release(struct rproc *rproc,
>   return 0;
>  }
>  
> -static int stm32_rproc_of_memory_translations(struct rproc *rproc)
> +static int stm32_rproc_of_memory_translations(struct platform_device *pdev,
> +   struct stm32_rproc *ddata)
>  {
> - struct device *parent, *dev = rproc->dev.parent;
> - struct stm32_rproc *ddata = rproc->priv;
> + struct device *parent, *dev = >dev;
>   struct device_node *np;
>   struct stm32_rproc_mem *p_mems;
>   struct stm32_rproc_mem_ranges *mem_range;
> @@ -606,7 +606,7 @@ static int stm32_rproc_parse_dt(struct platform_device 
> *pdev)
>  
>   rproc->auto_boot = of_property_read_bool(np, "st,auto-boot");
>  
> - return stm32_rproc_of_memory_translations(rproc);
> + return stm32_rproc_of_memory_translations(pdev, ddata);
>  }
>  
>  static int stm32_rproc_probe(struct platform_device *pdev)
> -- 
> 2.20.1
> 


Re: [patch V4 part 4 03/24] lib/bsearch: Provide __always_inline variant

2020-05-13 Thread Andy Lutomirski
On Tue, May 5, 2020 at 7:15 AM Thomas Gleixner  wrote:
>
> From: Peter Zijlstra 
>
> For code that needs the ultimate performance (it can inline the @cmp
> function too) or simply needs to avoid calling external functions for
> whatever reason, provide an __always_inline variant of bsearch().


Acked-by: Andy Lutomirski 

Although maybe a more explicit name (e.g. __inlined_bsearch()) would
be more clear?


Re: [patch V4 part 4 02/24] x86/int3: Avoid atomic instrumentation

2020-05-13 Thread Andy Lutomirski
On Tue, May 5, 2020 at 7:15 AM Thomas Gleixner  wrote:
>
> From: Peter Zijlstra 
>
> Use arch_atomic_*() and READ_ONCE_NOCHECK() to ensure nothing untoward
> creeps in and ruins things.
>
> That is; this is the INT3 text poke handler, strictly limit the code
> that runs in it, lest it inadvertenly hits yet another INT3.


Acked-by: Andy Lutomirski 

Does objtool catch this error?


Re: [patch V4 part 4 01/24] x86/int3: Ensure that poke_int3_handler() is not traced

2020-05-13 Thread Andy Lutomirski
On Tue, May 5, 2020 at 7:15 AM Thomas Gleixner  wrote:
>
> From: Thomas Gleixner 
>
> In order to ensure poke_int3_handler() is completely self contained -- this
> is called while modifying other text, imagine the fun of hitting another
> INT3 -- ensure that everything it uses is not traced.
>
> The primary means here is to force inlining; bsearch() is notrace because
> all of lib/ is.


Acked-by: Andy Lutomirski 


Re: [patch V4 part 3 28/29] x86/entry: Convert SIMD coprocessor error exception to IDTENTRY

2020-05-13 Thread Andy Lutomirski
On Tue, May 5, 2020 at 7:15 AM Thomas Gleixner  wrote:
>
> From: Thomas Gleixner 
>
> Convert #XF to IDTENTRY_ERRORCODE:
>   - Implement the C entry point with DEFINE_IDTENTRY
>   - Emit the ASM stub with DECLARE_IDTENTRY
>   - Handle INVD_BUG in C
>   - Remove the ASM idtentry in 64bit
>   - Remove the open coded ASM entry code in 32bit
>   - Fixup the XEN/PV code
>   - Remove the old prototyoes
>   - Remove the RCU warning as the new entry macro ensures correctness
>
> No functional change.


Acked-by: Andy Lutomirski 


Re: [PATCH v11 33/56] Input: atmel_mxt_ts - delay enabling IRQ when not using regulators

2020-05-13 Thread Dmitry Osipenko
13.05.2020 08:07, Wang, Jiada пишет:
> Hello Dmitry
> 
> On 2020/05/12 8:13, Dmitry Osipenko wrote:
>> 11.05.2020 05:05, Wang, Jiada пишет:
>>> Hello Dmitry
>>>
>>> Thanks for your comment and test,
>>>
>>> can you let me know which platform (board) you are using for test,
>>> and DTS changes if you have added any.
>>
>> That's this device-tree [1] without any extra changes.
>>
> I am using Samsung Chromebook Pro for testing,
> but obviously some of the use cases it can't cover.
> 
> I also would like to test on same device you are using,
> would you please let me know how to boot Acer Iconia Tab A500
> with custom images. Are you booting Linux or Android on it?

I'm using Ubuntu 20.04 on it at the moment. In order to boot custom
images you'll need at least to install a custom recovery, which will
allow to flash boot.img on eMMC storage.

Ideally, you'll need to install an unlocked bootloader that will enable
Android's fastboot, and thus, allow to easily boot kernel zImage without
messing with flashing boot images.

Could you please tell what is the current state of yours device: does it
have a stock Android installed? is it rooted? is custom recovery installed?

My device was unlocked about 8+ years ago, so I'm not sure what's the
best way to do it nowadays. The XDA forums [1] could be a good starting
point, I may give you some advises once you'll tell what's the current
status of yours device.

[1] https://forum.xda-developers.com/iconia-a500


Re: [patch V4 part 3 29/29] x86/entry/32: Convert IRET exception to IDTENTRY_SW

2020-05-13 Thread Andy Lutomirski
On Tue, May 5, 2020 at 7:15 AM Thomas Gleixner  wrote:
>
> From: Thomas Gleixner 
>
> Convert the IRET exception handler to IDTENTRY_SW. This is slightly
> different than the conversions of hardware exceptions as the IRET exception
> is invoked via an exception table when IRET faults. So it just uses the
> IDTENTRY_SW mechanism for consistency. It does not emit ASM code as it does
> not fit the other idtentry exceptions.

Blech.  I should redo the 32-bit code to handle this the way the
64-bit code does and this can all be deleted.  But, for now:


Acked-by: Andy Lutomirski 

However, maybe rename asm_exc_iret_error to avoid confusion?  It's not
really an exception entry.


Re: [patch V4 part 3 27/29] x86/entry: Convert Alignment check exception to IDTENTRY

2020-05-13 Thread Andy Lutomirski
On Tue, May 5, 2020 at 7:15 AM Thomas Gleixner  wrote:
>
> From: Thomas Gleixner 
>
> Convert #AC to IDTENTRY_ERRORCODE:
>   - Implement the C entry point with DEFINE_IDTENTRY
>   - Emit the ASM stub with DECLARE_IDTENTRY
>   - Remove the ASM idtentry in 64bit
>   - Remove the open coded ASM entry code in 32bit
>   - Fixup the XEN/PV code
>   - Remove the old prototyoes
>   - Remove the RCU warning as the new entry macro ensures correctness
>
> No functional change.


Acked-by: Andy Lutomirski 


Re: [patch V4 part 3 24/29] x86/entry: Convert General protection exception to IDTENTRY

2020-05-13 Thread Andy Lutomirski
On Tue, May 5, 2020 at 7:15 AM Thomas Gleixner  wrote:
>
> From: Thomas Gleixner 
>
> Convert #GP to IDTENTRY_ERRORCODE:
>   - Implement the C entry point with DEFINE_IDTENTRY
>   - Emit the ASM stub with DECLARE_IDTENTRY
>   - Remove the ASM idtentry in 64bit
>   - Remove the open coded ASM entry code in 32bit
>   - Fixup the XEN/PV code
>   - Remove the old prototyoes
>   - Remove the RCU warning as the new entry macro ensures correctness
>
> No functional change.


Acked-by: Andy Lutomirski 


Re: [patch V4 part 3 26/29] x86/entry: Convert Coprocessor error exception to IDTENTRY

2020-05-13 Thread Andy Lutomirski
On Tue, May 5, 2020 at 7:15 AM Thomas Gleixner  wrote:
>
> From: Thomas Gleixner 
>
> Convert #MF to IDTENTRY_ERRORCODE:
>   - Implement the C entry point with DEFINE_IDTENTRY
>   - Emit the ASM stub with DECLARE_IDTENTRY
>   - Remove the ASM idtentry in 64bit
>   - Remove the open coded ASM entry code in 32bit
>   - Fixup the XEN/PV code
>   - Remove the old prototyoes
>   - Remove the RCU warning as the new entry macro ensures correctness
>
> No functional change.


Acked-by: Andy Lutomirski 


Re: [patch V4 part 3 23/29] x86/entry: Convert Stack segment exception to IDTENTRY

2020-05-13 Thread Andy Lutomirski
On Tue, May 5, 2020 at 7:15 AM Thomas Gleixner  wrote:
>
> From: Thomas Gleixner 
>
> Convert #SS to IDTENTRY_ERRORCODE:
>   - Implement the C entry point with DEFINE_IDTENTRY
>   - Emit the ASM stub with DECLARE_IDTENTRY
>   - Remove the ASM idtentry in 64bit
>   - Remove the open coded ASM entry code in 32bit
>   - Fixup the XEN/PV code
>   - Remove the old prototyoes
>
> No functional change.


Acked-by: Andy Lutomirski 


Re: [patch V4 part 3 21/29] x86/entry: Convert Invalid TSS exception to IDTENTRY

2020-05-13 Thread Andy Lutomirski
On Tue, May 5, 2020 at 7:15 AM Thomas Gleixner  wrote:
>
> From: Thomas Gleixner 
>
> Convert #TS to IDTENTRY_ERRORCODE:
>   - Implement the C entry point with DEFINE_IDTENTRY
>   - Emit the ASM stub with DECLARE_IDTENTRY
>   - Remove the ASM idtentry in 64bit
>   - Remove the open coded ASM entry code in 32bit
>   - Fixup the XEN/PV code
>   - Remove the old prototyoes
>
> No functional change.

I confess that I'm a bit mystified as to why we have all the machinery
in place to send a signal if #TS happens.  Whatever.

Acked-by: Andy Lutomirski 


Re: [patch V4 part 3 25/29] x86/entry: Convert Spurious interrupt bug exception to IDTENTRY

2020-05-13 Thread Andy Lutomirski
On Tue, May 5, 2020 at 7:15 AM Thomas Gleixner  wrote:
>
> From: Thomas Gleixner 
>
> Convert #SPURIOUS to IDTENTRY_ERRORCODE:
>   - Implement the C entry point with DEFINE_IDTENTRY
>   - Emit the ASM stub with DECLARE_IDTENTRY
>   - Remove the ASM idtentry in 64bit
>   - Remove the open coded ASM entry code in 32bit
>   - Fixup the XEN/PV code
>   - Remove the old prototyoes
>
> No functional change.


Acked-by: Andy Lutomirski 


Re: [patch V4 part 3 22/29] x86/entry: Convert Segment not present exception to IDTENTRY

2020-05-13 Thread Andy Lutomirski
On Tue, May 5, 2020 at 7:15 AM Thomas Gleixner  wrote:
>
> From: Thomas Gleixner 
>
> Convert #NP to IDTENTRY_ERRORCODE:
>   - Implement the C entry point with DEFINE_IDTENTRY
>   - Emit the ASM stub with DECLARE_IDTENTRY
>   - Remove the ASM idtentry in 64bit
>   - Remove the open coded ASM entry code in 32bit
>   - Fixup the XEN/PV code
>   - Remove the old prototyoes
>
> No functional change.


Acked-by: Andy Lutomirski 


Re: [patch V4 part 3 20/29] x86/entry: Provide IDTENTRY_ERRORCODE

2020-05-13 Thread Andy Lutomirski
On Tue, May 5, 2020 at 7:15 AM Thomas Gleixner  wrote:
>
> From: Thomas Gleixner 
>
> Same as IDTENTRY but the C entry point has an error code argument.
>


Acked-by: Andy Lutomirski 


Re: [patch V4 part 3 19/29] x86/entry: Convert Coprocessor segment overrun exception to IDTENTRY

2020-05-13 Thread Andy Lutomirski
On Tue, May 5, 2020 at 7:15 AM Thomas Gleixner  wrote:
>
> From: Thomas Gleixner 
>
> Convert #OLD_MF to IDTENTRY:
>   - Implement the C entry point with DEFINE_IDTENTRY
>   - Emit the ASM stub with DECLARE_IDTENTRY
>   - Remove the ASM idtentry in 64bit
>   - Remove the open coded ASM entry code in 32bit
>   - Fixup the XEN/PV code
>   - Remove the old prototyoes
>
> No functional change.


Acked-by: Andy Lutomirski 


Re: linux-next: build failure after merge of the keys tree

2020-05-13 Thread Jason A. Donenfeld
Hey Masahiro,

Your touch might be helpful here. CRYPTO_LIB_CHACHA20POLY1305 is a
tristate and depends on as well as selects other things that are
tristates.

Meanwhile BIG_KEYS is a bool, which needs to select
CRYPTO_LIB_CHACHA20POLY1305. However, it gets antsy if the the symbol
its selecting has =m items in its hierarchy.

Any suggestions? The ideal thing to happen would be that the select of
CRYPTO_LIB_CHACHA20POLY1305 in BIG_KEYS causes all of the descendants
to become =y too.

Jason


On Wed, May 13, 2020 at 10:31 PM Stephen Rothwell  wrote:
>
> Hi all,
>
> After merging the keys tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> WARNING: unmet direct dependencies detected for CRYPTO_LIB_CHACHA20POLY1305
>   Depends on [m]: CRYPTO [=y] && (CRYPTO_ARCH_HAVE_LIB_CHACHA [=m] || 
> !CRYPTO_ARCH_HAVE_LIB_CHACHA [=m]) && (CRYPTO_ARCH_HAVE_LIB_POLY1305 [=m] || 
> !CRYPTO_ARCH_HAVE_LIB_POLY1305 [=m])
>   Selected by [y]:
>   - BIG_KEYS [=y] && KEYS [=y] && TMPFS [=y]
>   Selected by [m]:
>   - WIREGUARD [=m] && NETDEVICES [=y] && NET_CORE [=y] && NET [=y] && INET 
> [=y] && (IPV6 [=y] || !IPV6 [=y])
>
> WARNING: unmet direct dependencies detected for CRYPTO_LIB_CHACHA20POLY1305
>   Depends on [m]: CRYPTO [=y] && (CRYPTO_ARCH_HAVE_LIB_CHACHA [=m] || 
> !CRYPTO_ARCH_HAVE_LIB_CHACHA [=m]) && (CRYPTO_ARCH_HAVE_LIB_POLY1305 [=m] || 
> !CRYPTO_ARCH_HAVE_LIB_POLY1305 [=m])
>   Selected by [y]:
>   - BIG_KEYS [=y] && KEYS [=y] && TMPFS [=y]
>   Selected by [m]:
>   - WIREGUARD [=m] && NETDEVICES [=y] && NET_CORE [=y] && NET [=y] && INET 
> [=y] && (IPV6 [=y] || !IPV6 [=y])
>
> WARNING: unmet direct dependencies detected for CRYPTO_LIB_CHACHA20POLY1305
>   Depends on [m]: CRYPTO [=y] && (CRYPTO_ARCH_HAVE_LIB_CHACHA [=m] || 
> !CRYPTO_ARCH_HAVE_LIB_CHACHA [=m]) && (CRYPTO_ARCH_HAVE_LIB_POLY1305 [=m] || 
> !CRYPTO_ARCH_HAVE_LIB_POLY1305 [=m])
>   Selected by [y]:
>   - BIG_KEYS [=y] && KEYS [=y] && TMPFS [=y]
>   Selected by [m]:
>   - WIREGUARD [=m] && NETDEVICES [=y] && NET_CORE [=y] && NET [=y] && INET 
> [=y] && (IPV6 [=y] || !IPV6 [=y])
> x86_64-linux-gnu-ld: lib/crypto/chacha20poly1305.o: in function 
> `xchacha_init':
> chacha20poly1305.c:(.text+0x12d): undefined reference to `chacha_init_arch'
> x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x13d): undefined reference to 
> `hchacha_block_arch'
> x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x14b): undefined reference to 
> `chacha_init_arch'
> x86_64-linux-gnu-ld: lib/crypto/chacha20poly1305.o: in function 
> `__chacha20poly1305_encrypt':
> chacha20poly1305.c:(.text+0x2ab): undefined reference to `chacha_crypt_arch'
> x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x2bd): undefined reference to 
> `poly1305_init_arch'
> x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x2d6): undefined reference to 
> `poly1305_update_arch'
> x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x317): undefined reference to 
> `chacha_crypt_arch'
> x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x32d): undefined reference to 
> `poly1305_update_arch'
> x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x379): undefined reference to 
> `poly1305_update_arch'
> x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x385): undefined reference to 
> `poly1305_final_arch'
> x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x413): undefined reference to 
> `poly1305_update_arch'
> x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x434): undefined reference to 
> `poly1305_update_arch'
> x86_64-linux-gnu-ld: lib/crypto/chacha20poly1305.o: in function 
> `chacha20poly1305_encrypt':
> (.text+0x59d): undefined reference to `chacha_init_arch'
> x86_64-linux-gnu-ld: lib/crypto/chacha20poly1305.o: in function 
> `__chacha20poly1305_decrypt':
> chacha20poly1305.c:(.text+0x847): undefined reference to `chacha_crypt_arch'
> x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x859): undefined reference to 
> `poly1305_init_arch'
> x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x86d): undefined reference to 
> `poly1305_update_arch'
> x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x8a7): undefined reference to 
> `poly1305_update_arch'
> x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x8f1): undefined reference to 
> `poly1305_update_arch'
> x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x8fc): undefined reference to 
> `poly1305_final_arch'
> x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x94f): undefined reference to 
> `chacha_crypt_arch'
> x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x9d9): undefined reference to 
> `poly1305_update_arch'
> x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x9f9): undefined reference to 
> `poly1305_update_arch'
> x86_64-linux-gnu-ld: lib/crypto/chacha20poly1305.o: in function 
> `chacha20poly1305_decrypt':
> (.text+0xb78): undefined reference to `chacha_init_arch'
> x86_64-linux-gnu-ld: lib/crypto/chacha20poly1305.o: in function 
> `chacha20poly1305_crypt_sg_inplace':
> chacha20poly1305.c:(.text+0xf16): undefined reference to `chacha_init_arch'
> 

Re: [patch V4 part 3 18/29] x86/entry: Convert Device not available exception to IDTENTRY

2020-05-13 Thread Andy Lutomirski
On Tue, May 5, 2020 at 7:15 AM Thomas Gleixner  wrote:
>
> From: Thomas Gleixner 
>
> Convert #NM to IDTENTRY:
>   - Implement the C entry point with DEFINE_IDTENTRY
>   - Emit the ASM stub with DECLARE_IDTENTRY
>   - Remove the ASM idtentry in 64bit
>   - Remove the open coded ASM entry code in 32bit
>   - Fixup the XEN/PV code
>   - Remove the old prototyoes
>   - Remove the RCU warning as the new entry macro ensures correctness
>
> No functional change.


Acked-by: Andy Lutomirski 


Re: [patch V4 part 3 17/29] x86/entry: Convert Invalid Opcode exception to IDTENTRY

2020-05-13 Thread Andy Lutomirski
On Tue, May 5, 2020 at 7:15 AM Thomas Gleixner  wrote:
>
> From: Thomas Gleixner 
>
> Convert #UD to IDTENTRY:
>   - Implement the C entry point with DEFINE_IDTENTRY
>   - Emit the ASM stub with DECLARE_IDTENTRY
>   - Remove the ASM idtentry in 64bit
>   - Remove the open coded ASM entry code in 32bit
>   - Fixup the XEN/PV code
>   - Fixup the FOOF bug call in fault.c
>   - Remove the old prototyoes
>
> No functional change.

I think there *is* a functional change:


> --- a/arch/x86/mm/fault.c
> +++ b/arch/x86/mm/fault.c
> @@ -567,7 +567,7 @@ static int is_f00f_bug(struct pt_regs *r
> nr = (address - idt_descr.address) >> 3;
>
> if (nr == 6) {
> -   do_invalid_op(regs, 0);
> +   handle_invalid_op(regs);

I suspect the old code was wrong and no one noticed because no one has
a F00F-buggy machine any more.

So maybe document that you fixed up the F00F bug, too.  Otherwise:


Acked-by: Andy Lutomirski 


Re: [patch V4 part 3 16/29] x86/entry: Convert Bounds exception to IDTENTRY

2020-05-13 Thread Andy Lutomirski
On Tue, May 5, 2020 at 7:15 AM Thomas Gleixner  wrote:
>
> From: Thomas Gleixner 
>
> Convert #BR to IDTENTRY:
>   - Implement the C entry point with DEFINE_IDTENTRY
>   - Emit the ASM stub with DECLARE_IDTENTRY
>   - Remove the ASM idtentry in 64bit
>   - Remove the open coded ASM entry code in 32bit
>   - Fixup the XEN/PV code
>   - Remove the old prototyoes

prototypoes?

Acked-by: Andy Lutomirski 


Re: [patch V4 part 3 15/29] x86/entry: Convert Overflow exception to IDTENTRY

2020-05-13 Thread Andy Lutomirski
On Tue, May 5, 2020 at 7:15 AM Thomas Gleixner  wrote:
>
> From: Thomas Gleixner 
>
> Convert #OF to IDTENTRY:
>   - Implement the C entry point with DEFINE_IDTENTRY
>   - Emit the ASM stub with DECLARE_IDTENTRY
>   - Remove the ASM idtentry in 64bit
>   - Remove the open coded ASM entry code in 32bit
>   - Fixup the XEN/PV code
>   - Remove the old prototyoes
>
> No functional change.

Acked-by: Andy Lutomirski 


Re: [patch V4 part 3 14/29] x86/entry: Convert Divide Error to IDTENTRY

2020-05-13 Thread Andy Lutomirski
On Tue, May 5, 2020 at 7:15 AM Thomas Gleixner  wrote:
>
> From: Thomas Gleixner 
>
> Convert #DE to IDTENTRY:
>   - Implement the C entry point with DEFINE_IDTENTRY
>   - Emit the ASM stub with DECLARE_IDTENTRY
>   - Remove the ASM idtentry in 64bit
>   - Remove the open coded ASM entry code in 32bit
>   - Fixup the XEN/PV code
>
> No functional change.
>

Acked-by: Andy Lutomirski 


Re: [patch V4 part 3 13/29] x86/traps: Prepare for using DEFINE_IDTENTRY

2020-05-13 Thread Andy Lutomirski
On Tue, May 5, 2020 at 7:15 AM Thomas Gleixner  wrote:
>
> From: Thomas Gleixner 
>
> Prepare for using IDTENTRY to define the C exception/trap entry points. It
> would be possible to glue this into the existing macro maze, but it's
> simpler and better to read at the end to just make them distinct. Provide
> a trivial inline helper to read the trap address.
>
> The existing macros will be removed once all instances are converted.
>
> Signed-off-by: Thomas Gleixner 
> Reviewed-by: Alexandre Chartre 
>
> ---
>  arch/x86/kernel/traps.c |5 +
>  1 file changed, 5 insertions(+)
>
> --- a/arch/x86/kernel/traps.c
> +++ b/arch/x86/kernel/traps.c
> @@ -205,6 +205,11 @@ static void do_error_trap(struct pt_regs
> }
>  }
>
> +static __always_inline void __user *error_get_trap_addr(struct pt_regs *regs)
> +{
> +   return (void __user *)uprobe_get_trap_addr(regs);
> +}

My mind boggles.  WTF is this?

Perhaps this should have a comment like:

/*
 * Returns the address from which a user trap originated.  This would
be the same as regs->ip,
 * except for frhgnieawfn nvlrkvklsrvs and mfkealwf, and this lets the
thingummy pass a
 * modified value to the signal frame, but only for #DE and #UD,
because 

Re: [Jfs-discussion] [fs] 05c5a0273b: netperf.Throughput_total_tps -71.8% regression

2020-05-13 Thread Christian Kujau
On Tue, 12 May 2020, kernel test robot wrote:
> FYI, we noticed a -71.8% regression of netperf.Throughput_total_tps due to 
> commit:

As noted in this report, netperf is used to "measure various aspect of 
networking performance". Are we sure the bisect is correct? JFS is a 
filesystem and is not touching net/ in any way. So, having not attempted 
to reproduce this, maybe the JFS commit is a red herring?

C.
-- 
BOFH excuse #50:

Change in Earth's rotational speed


Re: [patch V4 part 3 09/29] x86/entry/32: Provide macro to emit IDT entry stubs

2020-05-13 Thread Andy Lutomirski
On Wed, May 13, 2020 at 6:44 PM Mathieu Desnoyers
 wrote:
>
> - On May 5, 2020, at 9:44 AM, Thomas Gleixner t...@linutronix.de wrote:
>
> [...]
>
> > +.macro idtentry vector asmsym cfunc has_error_code:req sane=0
> > +SYM_CODE_START(\asmsym)
> > + ASM_CLAC
> > + cld
>
> Looking at the various interrupt and trap entry points for 32 and 64-bit
> x86, I notice a lack of consistency in use of the following instruction
> sequence at the asm entry point:
>
> - ASM_CLAC,
> - cld (clear direction flag).
>
> Are they always needed, or only for interrupt handlers ?

They're needed for all entries except SYSCALL, but they're hidden
inside helpers in many cases.


linux-next: build failure after merge of the keys tree

2020-05-13 Thread Stephen Rothwell
Hi all,

After merging the keys tree, today's linux-next build (x86_64
allmodconfig) failed like this:

WARNING: unmet direct dependencies detected for CRYPTO_LIB_CHACHA20POLY1305
  Depends on [m]: CRYPTO [=y] && (CRYPTO_ARCH_HAVE_LIB_CHACHA [=m] || 
!CRYPTO_ARCH_HAVE_LIB_CHACHA [=m]) && (CRYPTO_ARCH_HAVE_LIB_POLY1305 [=m] || 
!CRYPTO_ARCH_HAVE_LIB_POLY1305 [=m])
  Selected by [y]:
  - BIG_KEYS [=y] && KEYS [=y] && TMPFS [=y]
  Selected by [m]:
  - WIREGUARD [=m] && NETDEVICES [=y] && NET_CORE [=y] && NET [=y] && INET [=y] 
&& (IPV6 [=y] || !IPV6 [=y])

WARNING: unmet direct dependencies detected for CRYPTO_LIB_CHACHA20POLY1305
  Depends on [m]: CRYPTO [=y] && (CRYPTO_ARCH_HAVE_LIB_CHACHA [=m] || 
!CRYPTO_ARCH_HAVE_LIB_CHACHA [=m]) && (CRYPTO_ARCH_HAVE_LIB_POLY1305 [=m] || 
!CRYPTO_ARCH_HAVE_LIB_POLY1305 [=m])
  Selected by [y]:
  - BIG_KEYS [=y] && KEYS [=y] && TMPFS [=y]
  Selected by [m]:
  - WIREGUARD [=m] && NETDEVICES [=y] && NET_CORE [=y] && NET [=y] && INET [=y] 
&& (IPV6 [=y] || !IPV6 [=y])

WARNING: unmet direct dependencies detected for CRYPTO_LIB_CHACHA20POLY1305
  Depends on [m]: CRYPTO [=y] && (CRYPTO_ARCH_HAVE_LIB_CHACHA [=m] || 
!CRYPTO_ARCH_HAVE_LIB_CHACHA [=m]) && (CRYPTO_ARCH_HAVE_LIB_POLY1305 [=m] || 
!CRYPTO_ARCH_HAVE_LIB_POLY1305 [=m])
  Selected by [y]:
  - BIG_KEYS [=y] && KEYS [=y] && TMPFS [=y]
  Selected by [m]:
  - WIREGUARD [=m] && NETDEVICES [=y] && NET_CORE [=y] && NET [=y] && INET [=y] 
&& (IPV6 [=y] || !IPV6 [=y])
x86_64-linux-gnu-ld: lib/crypto/chacha20poly1305.o: in function `xchacha_init':
chacha20poly1305.c:(.text+0x12d): undefined reference to `chacha_init_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x13d): undefined reference to 
`hchacha_block_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x14b): undefined reference to 
`chacha_init_arch'
x86_64-linux-gnu-ld: lib/crypto/chacha20poly1305.o: in function 
`__chacha20poly1305_encrypt':
chacha20poly1305.c:(.text+0x2ab): undefined reference to `chacha_crypt_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x2bd): undefined reference to 
`poly1305_init_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x2d6): undefined reference to 
`poly1305_update_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x317): undefined reference to 
`chacha_crypt_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x32d): undefined reference to 
`poly1305_update_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x379): undefined reference to 
`poly1305_update_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x385): undefined reference to 
`poly1305_final_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x413): undefined reference to 
`poly1305_update_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x434): undefined reference to 
`poly1305_update_arch'
x86_64-linux-gnu-ld: lib/crypto/chacha20poly1305.o: in function 
`chacha20poly1305_encrypt':
(.text+0x59d): undefined reference to `chacha_init_arch'
x86_64-linux-gnu-ld: lib/crypto/chacha20poly1305.o: in function 
`__chacha20poly1305_decrypt':
chacha20poly1305.c:(.text+0x847): undefined reference to `chacha_crypt_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x859): undefined reference to 
`poly1305_init_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x86d): undefined reference to 
`poly1305_update_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x8a7): undefined reference to 
`poly1305_update_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x8f1): undefined reference to 
`poly1305_update_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x8fc): undefined reference to 
`poly1305_final_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x94f): undefined reference to 
`chacha_crypt_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x9d9): undefined reference to 
`poly1305_update_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x9f9): undefined reference to 
`poly1305_update_arch'
x86_64-linux-gnu-ld: lib/crypto/chacha20poly1305.o: in function 
`chacha20poly1305_decrypt':
(.text+0xb78): undefined reference to `chacha_init_arch'
x86_64-linux-gnu-ld: lib/crypto/chacha20poly1305.o: in function 
`chacha20poly1305_crypt_sg_inplace':
chacha20poly1305.c:(.text+0xf16): undefined reference to `chacha_init_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0xf3b): undefined reference to 
`chacha_crypt_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0xf50): undefined reference to 
`poly1305_init_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x1094): undefined reference to 
`chacha_crypt_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x1155): undefined reference to 
`poly1305_update_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x117b): undefined reference to 
`poly1305_update_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x11da): undefined reference to 
`poly1305_update_arch'
x86_64-linux-gnu-ld: chacha20poly1305.c:(.text+0x1223): undefined reference to 
`poly1305_final_arch'
x86_64-linux-gnu-ld: 

[PATCH target] target: Add initiatorname to NON_EXISTENT_LUN error

2020-05-13 Thread Lance Digby
The NON_EXISTENT_LUN error can be written without an error condition
 on the initiator responsible. Adding the initiatorname to this message
 will reduce the effort required to fix this when many initiators are
supported by a target.

Signed-off-by: Lance Digby 
---
 drivers/target/target_core_device.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/target/target_core_device.c 
b/drivers/target/target_core_device.c
index 4cee113..604dea0 100644
--- a/drivers/target/target_core_device.c
+++ b/drivers/target/target_core_device.c
@@ -100,9 +100,10 @@
 */
if (unpacked_lun != 0) {
pr_err("TARGET_CORE[%s]: Detected NON_EXISTENT_LUN"
-   " Access for 0x%08llx\n",
+   " Access for 0x%08llx from %s\n",
se_cmd->se_tfo->fabric_name,
-   unpacked_lun);
+   unpacked_lun,
+   se_sess->se_node_acl->initiatorname);
return TCM_NON_EXISTENT_LUN;
}
 
-- 
1.8.3.1



[PATCH] usb: musb: mediatek: add reset FADDR to zero in reset interrupt handle

2020-05-13 Thread Macpaul Lin
When receiving reset interrupt, FADDR need to be reset to zero in
periphearl mode. Otherwise ep0 cannot do enumeration when re-pluging USB
cable.

Signed-off-by: Macpaul Lin 
---
 drivers/usb/musb/mediatek.c |6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/usb/musb/mediatek.c b/drivers/usb/musb/mediatek.c
index 6196b0e..eebeadd 100644
--- a/drivers/usb/musb/mediatek.c
+++ b/drivers/usb/musb/mediatek.c
@@ -208,6 +208,12 @@ static irqreturn_t generic_interrupt(int irq, void *__hci)
musb->int_rx = musb_clearw(musb->mregs, MUSB_INTRRX);
musb->int_tx = musb_clearw(musb->mregs, MUSB_INTRTX);
 
+   if ((musb->int_usb & MUSB_INTR_RESET) && !is_host_active(musb)) {
+   /* ep0 FADDR must be 0 when (re)entering peripheral mode */
+   musb_ep_select(musb->mregs, 0);
+   musb_writeb(musb->mregs, MUSB_FADDR, 0);
+   }
+
if (musb->int_usb || musb->int_tx || musb->int_rx)
retval = musb_interrupt(musb);
 
-- 
1.7.9.5


Fwd: Possible null pointer dereference caused by vmstat_start()

2020-05-13 Thread Dongyang Zhan
发件人: Dongyang Zhan 
Date: 2020年5月3日周日 下午1:45
Subject: Possible null pointer dereference caused by vmstat_start()
To: 
Cc: 


In Linux 4.10.17, vmstat_start() stores the results of v =
kmalloc(stat_items_size, GFP_KERNEL) in m->private = v before security
check. If m->private is accessed, it may cause null pointer
dereference.

Source code link:
https://elixir.bootlin.com/linux/v4.10.17/source/mm/vmstat.c#L1465

Source code;
v = kmalloc(stat_items_size, GFP_KERNEL);
m->private = v; //stores v before check;
if (!v)
 return ERR_PTR(-ENOMEM);

Function rdtgroup_seqfile_show() in
arch/x86/kernel/cpu/intel_rdt_rdtgroup.c access this pointer without
check, which is a possible bug.

Link:
https://elixir.bootlin.com/linux/v4.10.17/source/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c#150
Source Code
static int rdtgroup_seqfile_show(struct seq_file *m, void *arg)
{
struct kernfs_open_file *of = m->private;
struct rftype *rft = of->kn->priv; // without check;

if (rft->seq_show)
return rft->seq_show(of, m, arg);
return 0;
}


[PATCH] drivers: ipa: use devm_kzalloc for simplicity

2020-05-13 Thread Wang Wenhu
Make a substitution of kzalloc with devm_kzalloc to simplify the
ipa_probe() process.

Signed-off-by: Wang Wenhu 
Cc: Alex Elder 
---
 drivers/net/ipa/ipa_clock.c | 7 ++-
 drivers/net/ipa/ipa_main.c  | 7 ++-
 2 files changed, 4 insertions(+), 10 deletions(-)

diff --git a/drivers/net/ipa/ipa_clock.c b/drivers/net/ipa/ipa_clock.c
index 374491ea11cf..ddbd687fe64b 100644
--- a/drivers/net/ipa/ipa_clock.c
+++ b/drivers/net/ipa/ipa_clock.c
@@ -276,7 +276,7 @@ struct ipa_clock *ipa_clock_init(struct device *dev)
goto err_clk_put;
}
 
-   clock = kzalloc(sizeof(*clock), GFP_KERNEL);
+   clock = devm_kzalloc(dev, sizeof(*clock), GFP_KERNEL);
if (!clock) {
ret = -ENOMEM;
goto err_clk_put;
@@ -285,15 +285,13 @@ struct ipa_clock *ipa_clock_init(struct device *dev)
 
ret = ipa_interconnect_init(clock, dev);
if (ret)
-   goto err_kfree;
+   goto err_clk_put;
 
mutex_init(>mutex);
atomic_set(>count, 0);
 
return clock;
 
-err_kfree:
-   kfree(clock);
 err_clk_put:
clk_put(clk);
 
@@ -308,6 +306,5 @@ void ipa_clock_exit(struct ipa_clock *clock)
WARN_ON(atomic_read(>count) != 0);
mutex_destroy(>mutex);
ipa_interconnect_exit(clock);
-   kfree(clock);
clk_put(clk);
 }
diff --git a/drivers/net/ipa/ipa_main.c b/drivers/net/ipa/ipa_main.c
index 28998dcce3d2..b7b348b863f7 100644
--- a/drivers/net/ipa/ipa_main.c
+++ b/drivers/net/ipa/ipa_main.c
@@ -760,7 +760,7 @@ static int ipa_probe(struct platform_device *pdev)
}
 
/* Allocate and initialize the IPA structure */
-   ipa = kzalloc(sizeof(*ipa), GFP_KERNEL);
+   ipa = devm_kzalloc(dev, sizeof(*ipa), GFP_KERNEL);
if (!ipa) {
ret = -ENOMEM;
goto err_wakeup_source_unregister;
@@ -776,7 +776,7 @@ static int ipa_probe(struct platform_device *pdev)
 
ret = ipa_reg_init(ipa);
if (ret)
-   goto err_kfree_ipa;
+   goto err_wakeup_source_unregister;
 
ret = ipa_mem_init(ipa, data->mem_count, data->mem_data);
if (ret)
@@ -848,8 +848,6 @@ static int ipa_probe(struct platform_device *pdev)
ipa_mem_exit(ipa);
 err_reg_exit:
ipa_reg_exit(ipa);
-err_kfree_ipa:
-   kfree(ipa);
 err_wakeup_source_unregister:
wakeup_source_unregister(wakeup_source);
 err_clock_exit:
@@ -885,7 +883,6 @@ static int ipa_remove(struct platform_device *pdev)
gsi_exit(>gsi);
ipa_mem_exit(ipa);
ipa_reg_exit(ipa);
-   kfree(ipa);
wakeup_source_unregister(wakeup_source);
ipa_clock_exit(clock);
rproc_put(rproc);
-- 
2.17.1



Re: [PATCH 06/11] powerpc/xmon: constify sysrq_key_op

2020-05-13 Thread Michael Ellerman
Emil Velikov  writes:
> With earlier commits, the API no longer discards the const-ness of the
> sysrq_key_op. As such we can add the notation.
>
> Cc: Greg Kroah-Hartman 
> Cc: Jiri Slaby 
> Cc: linux-kernel@vger.kernel.org
> Cc: Michael Ellerman 
> Cc: Benjamin Herrenschmidt 
> Cc: Paul Mackerras 
> Cc: linuxppc-...@lists.ozlabs.org
> Signed-off-by: Emil Velikov 
> ---
> Please keep me in the CC list, as I'm not subscribed to the list.
>
> IMHO it would be better if this gets merged this via the tty tree.

Fine by me.

Acked-by: Michael Ellerman 

cheers

> diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
> index 7af840c0fc93..0d8ca5c9f131 100644
> --- a/arch/powerpc/xmon/xmon.c
> +++ b/arch/powerpc/xmon/xmon.c
> @@ -3842,7 +3842,7 @@ static void sysrq_handle_xmon(int key)
>   xmon_init(0);
>  }
>  
> -static struct sysrq_key_op sysrq_xmon_op = {
> +static const struct sysrq_key_op sysrq_xmon_op = {
>   .handler =  sysrq_handle_xmon,
>   .help_msg = "xmon(x)",
>   .action_msg =   "Entering xmon",
> -- 
> 2.25.1


Re: gcc-10: kernel stack is corrupted and fails to boot

2020-05-13 Thread Andy Lutomirski
> On May 13, 2020, at 7:20 PM, Linus Torvalds  
> wrote:
>
> On Wed, May 13, 2020 at 5:51 PM Nick Desaulniers
>  wrote:
>>
>> Are you sure LTO treats empty asm statements differently than full
>> memory barriers in regards to preventing tail calls?
>
> It had better.
>
> At link-time, there is nothing left of an empty asm statement. So by
> the time the linker runs, it only sees
>
>call xyz
>ret
>
> in the object code. At that point, it's somewhat reasonable for any
> link-time optimizer (or an optimizing assembler, for that matter) to
> say "I'll just turn that sequence into a simple 'jmp xyz' instead".
>

What, what?

LTO isn’t a linker taking regular .o files full of regular machine
code and optimizing it. That’s nuts.  LTO takes an intermediate
representation and optimizes *that*. This will contain actual
indications that something is inline asm.  If LTO starts rewriting
inline asm, then I bet all kinds of things will go wrong and this is
the least of our worries.  Also, trying to do the kinds of stuff LTO
does by looking at just machine code isn't going to work.

So the difference between:

asm volatile ("nop");

and

asm volatile ("");

will be, literally, the absence of the nop.  (And alignment changes, etc.)


My Dear in the lord

2020-05-13 Thread Mina A. Brunel



My Dear in the lord


My name is Mrs. Mina A. Brunel I am a Norway Citizen who is living in Burkina 
Faso, I am married to Mr. Brunel Patrice, a politicians who owns a small gold 
company in Burkina Faso; He died of Leprosy and Radesyge, in year February 
2010, During his lifetime he deposited the sum of € 8.5 Million Euro) Eight 
million, Five hundred thousand Euros in a bank in Ouagadougou the capital city 
of of Burkina in West Africa. The money was from the sale of his company and 
death benefits payment and entitlements of my deceased husband by his company.

I am sending you this message with heavy tears in my eyes and great sorrow in 
my heart, and also praying that it will reach you in good health because I am 
not in good health, I sleep every night without knowing if I may be alive to 
see the next day. I am suffering from long time cancer and presently I am 
partially suffering from Leprosy, which has become difficult for me to move 
around. I was married to my late husband for more than 6 years without having a 
child and my doctor confided that I have less chance to live, having to know 
when the cup of death will come, I decided to contact you to claim the fund 
since I don't have any relation I grew up from an orphanage home.

I have decided to donate this money for the support of helping Motherless 
babies/Less privileged/Widows and churches also to build the house of God 
because I am dying and diagnosed with cancer for about 3 years ago. I have 
decided to donate from what I have inherited from my late husband to you for 
the good work of Almighty God; I will be going in for an operation surgery soon.

Now I want you to stand as my next of kin to claim the funds for charity 
purposes. Because of this money remains unclaimed after my death, the bank 
executives or the government will take the money as unclaimed fund and maybe 
use it for selfishness and worthless ventures, I need a very honest person who 
can claim this money and use it for Charity works, for orphanages, widows and 
also build schools and churches for less privilege that will be named after my 
late husband and my name.

I need your urgent answer to know if you will be able to execute this project, 
and I will give you more information on how the fund will be transferred to 
your bank account or online banking.

Thanks
Mrs. Mina A. Brunel


[PATCH] Bluetooth: hci_qca: Enable WBS support for wcn3991

2020-05-13 Thread Abhishek Pandit-Subedi
WCN3991 supports transparent WBS (host encoded mSBC). Add a flag to the
device match data to show WBS is supported.

This requires the matching firmware for WCN3991 in linux-firmware:
1a8b0dc00f77 (qca: Enable transparent WBS for WCN3991)

Signed-off-by: Abhishek Pandit-Subedi 
---

 drivers/bluetooth/hci_qca.c | 23 +--
 1 file changed, 17 insertions(+), 6 deletions(-)

diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
index b3fd07a6f8127..305976c4dcf42 100644
--- a/drivers/bluetooth/hci_qca.c
+++ b/drivers/bluetooth/hci_qca.c
@@ -75,6 +75,9 @@ enum qca_flags {
QCA_HW_ERROR_EVENT
 };
 
+enum qca_driver_flags {
+   QCA_DRV_WIDEBAND_SPEECH_SUPPORTED = 0x1,
+};
 
 /* HCI_IBS transmit side sleep protocol states */
 enum tx_ibs_states {
@@ -187,10 +190,11 @@ struct qca_vreg {
unsigned int load_uA;
 };
 
-struct qca_vreg_data {
+struct qca_device_data {
enum qca_btsoc_type soc_type;
struct qca_vreg *vregs;
size_t num_vregs;
+   uint32_t flags;
 };
 
 /*
@@ -1691,7 +1695,7 @@ static const struct hci_uart_proto qca_proto = {
.dequeue= qca_dequeue,
 };
 
-static const struct qca_vreg_data qca_soc_data_wcn3990 = {
+static const struct qca_device_data qca_soc_data_wcn3990 = {
.soc_type = QCA_WCN3990,
.vregs = (struct qca_vreg []) {
{ "vddio", 15000  },
@@ -1702,7 +1706,7 @@ static const struct qca_vreg_data qca_soc_data_wcn3990 = {
.num_vregs = 4,
 };
 
-static const struct qca_vreg_data qca_soc_data_wcn3991 = {
+static const struct qca_device_data qca_soc_data_wcn3991 = {
.soc_type = QCA_WCN3991,
.vregs = (struct qca_vreg []) {
{ "vddio", 15000  },
@@ -1711,9 +1715,10 @@ static const struct qca_vreg_data qca_soc_data_wcn3991 = 
{
{ "vddch0", 45 },
},
.num_vregs = 4,
+   .flags = QCA_DRV_WIDEBAND_SPEECH_SUPPORTED,
 };
 
-static const struct qca_vreg_data qca_soc_data_wcn3998 = {
+static const struct qca_device_data qca_soc_data_wcn3998 = {
.soc_type = QCA_WCN3998,
.vregs = (struct qca_vreg []) {
{ "vddio", 1  },
@@ -1724,7 +1729,7 @@ static const struct qca_vreg_data qca_soc_data_wcn3998 = {
.num_vregs = 4,
 };
 
-static const struct qca_vreg_data qca_soc_data_qca6390 = {
+static const struct qca_device_data qca_soc_data_qca6390 = {
.soc_type = QCA_QCA6390,
.num_vregs = 0,
 };
@@ -1860,7 +1865,7 @@ static int qca_serdev_probe(struct serdev_device *serdev)
 {
struct qca_serdev *qcadev;
struct hci_dev *hdev;
-   const struct qca_vreg_data *data;
+   const struct qca_device_data *data;
int err;
bool power_ctrl_enabled = true;
 
@@ -1948,6 +1953,12 @@ static int qca_serdev_probe(struct serdev_device *serdev)
hdev->shutdown = qca_power_off;
}
 
+   /* Wideband speech support must be set per driver since it can't be
+* queried via hci.
+*/
+   if (data && (data->flags & QCA_DRV_WIDEBAND_SPEECH_SUPPORTED))
+   set_bit(HCI_QUIRK_WIDEBAND_SPEECH_SUPPORTED, >quirks);
+
return 0;
 }
 
-- 
2.26.2.761.g0e0b3e54be-goog



Re: [PATCH 3/4] perf stat: Add --metrics-file option

2020-05-13 Thread Ian Rogers
On Wed, May 13, 2020 at 4:33 AM Jiri Olsa  wrote:
>
> On Wed, May 13, 2020 at 12:04:55AM -0700, Ian Rogers wrote:
>
> SNIP
>
> > > +METRICS FILE
> > > +
> > > +The file with metrics has following syntax:
> > > +
> > > +  NAME = EXPRESSION ;
> > > +  NAME = EXPRESSION ;
> > > +  ...
> > > +
> > > +where NAME is unique identifier of the metric, which is later used in
> > > +perf stat as -M option argument (see below).
> > > +
> > > +The EXPRESSION is the metric's formula with following grammar:
> > > +
> > > +  EXPR: EVENT
> > > +  EXPR: EXPR if EXPR else EXPR
> >
> > Not introduced by this patch, but this patch is exposing it as an API.
>
> yea, I was thinking about this and I think we will put a disclaimer in
> here that this is not an API and the interface can change.. it's really
> mostly intended to help out with running a custom metric which is not
> compiled in ... I don't want to be commited to support old API
>
> > This notion of if-else is really weird. For one thing there are no
> > comparison operators. The unit test doesn't really help:
> > ret |= test(, "1+1 if 3*4 else 0", 2);
> > What kind of comparison is "3*4"? If 0.0 causes the else clause then will 
> > -0.0?
> > A typical expression I see written in C is to give a ratio such:
> >   value = denom == 0 ? 0 : nom / denom;
> > I've worked around encoding this by extending expr.y locally.
>
> AFAICS it's used only with #SMT_on in the condition, aybe we could limit
> the condition only for #SMT_on term?
>
>
> >
> > > +  EXPR: NUMBER
> > > +  EXPR: EXPR | EXPR
> > > +  EXPR: EXPR & EXPR
> > > +  EXPR: EXPR ^ EXPR
> >
> > Again, it's odd that these cast the double to a long and then assign
> > the result back to a double.
>
> is this even used anywhere? perhaps it was added just to be complete

I don't believe they are used and checked with the pmu parsing test
that removing them doesn't cause any x86 expressions to break. I'd
prefer it if we could remove the unused operators and avoid
advertising here.

Thanks,
Ian

> SNIP
>
> > > +   2.002460174 0.8623.37 
> > > 0.86
> > > +   3.003969795 1.0323.93 
> > > 1.03
> > > +  ...
> >
> > A feature request would be to allow metrics in terms of other metrics,
> > not just events :-) For example, it is common to sum all cache
> > hit/miss events. It is laborious to copy that expression for hit rate,
> > miss rate, etc.
> >
> > Perhaps the expression parsing code should be folded into the event
> > parsing code.
>
> nice idea, but let's finish straighten up what we have first ;-)
>
> I'll try to go through all the fixes/tests you posted and let's
> get it in first
>
> thanks,
> jirka
>


Re: [PATCH v17 05/10] fs,landlock: Support filesystem access-control

2020-05-13 Thread James Morris
On Mon, 11 May 2020, Mickaël Salaün wrote:


> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index 45cc10cdf6dd..2276642f8e05 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -1517,6 +1517,11 @@ struct super_block {
>   /* Pending fsnotify inode refs */
>   atomic_long_t s_fsnotify_inode_refs;
>  
> +#ifdef CONFIG_SECURITY_LANDLOCK
> + /* References to Landlock underlying objects */
> + atomic_long_t s_landlock_inode_refs;
> +#endif
> +

This needs to be converted to the LSM API via superblock blob stacking.

See Casey's old patch: 
https://lore.kernel.org/linux-security-module/20190829232935.7099-2-ca...@schaufler-ca.com/



-- 
James Morris



mmotm 2020-05-13-20-30 uploaded

2020-05-13 Thread Andrew Morton
The mm-of-the-moment snapshot 2020-05-13-20-30 has been uploaded to

   http://www.ozlabs.org/~akpm/mmotm/

mmotm-readme.txt says

README for mm-of-the-moment:

http://www.ozlabs.org/~akpm/mmotm/

This is a snapshot of my -mm patch queue.  Uploaded at random hopefully
more than once a week.

You will need quilt to apply these patches to the latest Linus release (5.x
or 5.x-rcY).  The series file is in broken-out.tar.gz and is duplicated in
http://ozlabs.org/~akpm/mmotm/series

The file broken-out.tar.gz contains two datestamp files: .DATE and
.DATE--mm-dd-hh-mm-ss.  Both contain the string -mm-dd-hh-mm-ss,
followed by the base kernel version against which this patch series is to
be applied.

This tree is partially included in linux-next.  To see which patches are
included in linux-next, consult the `series' file.  Only the patches
within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in
linux-next.


A full copy of the full kernel tree with the linux-next and mmotm patches
already applied is available through git within an hour of the mmotm
release.  Individual mmotm releases are tagged.  The master branch always
points to the latest release, so it's constantly rebasing.

https://github.com/hnaz/linux-mm

The directory http://www.ozlabs.org/~akpm/mmots/ (mm-of-the-second)
contains daily snapshots of the -mm tree.  It is updated more frequently
than mmotm, and is untested.

A git copy of this tree is also available at

https://github.com/hnaz/linux-mm



This mmotm tree contains the following patches against 5.7-rc5:
(patches marked "*" will be included in linux-next)

  origin.patch
* mm-memcg-fix-inconsistent-oom-event-behavior.patch
* epoll-call-final-ep_events_available-check-under-the-lock.patch
* mm-gup-fix-fixup_user_fault-on-multiple-retries.patch
* userfaultfd-fix-remap-event-with-mremap_dontunmap.patch
* ipc-utilc-sysvipc_find_ipc-incorrectly-updates-position-index.patch
* kasan-consistently-disable-debugging-features.patch
* kasan-add-missing-functions-declarations-to-kasanh.patch
* checkpatch-test-git_dir-changes.patch
* proc-kpageflags-prevent-an-integer-overflow-in-stable_page_flags.patch
* proc-kpageflags-do-not-use-uninitialized-struct-pages.patch
* kcov-cleanup-debug-messages.patch
* kcov-fix-potential-use-after-free-in-kcov_remote_start.patch
* kcov-move-t-kcov-assignments-into-kcov_start-stop.patch
* kcov-move-t-kcov_sequence-assignment.patch
* kcov-use-t-kcov_mode-as-enabled-indicator.patch
* kcov-collect-coverage-from-interrupts.patch
* usb-core-kcov-collect-coverage-from-usb-complete-callback.patch
* memcg-optimize-memorynuma_stat-like-memorystat.patch
* lib-lzo-fix-ambiguous-encoding-bug-in-lzo-rle.patch
* device-dax-dont-leak-kernel-memory-to-user-space-after-unloading-kmem.patch
* mm-compaction-avoid-vm_bug_onpageslab-in-page_mapcount.patch
* scripts-support-compiled-source-improved-precise.patch
* scripts-add-a-intermediate-file-for-make-gtags.patch
* squashfs-migrate-from-ll_rw_block-usage-to-bio.patch
* squashfs-migrate-from-ll_rw_block-usage-to-bio-fix.patch
* ocfs2-add-missing-annotation-for-dlm_empty_lockres.patch
* ocfs2-mount-shared-volume-without-ha-stack.patch
* drivers-tty-serial-sh-scic-suppress-uninitialized-var-warning.patch
* ramfs-support-o_tmpfile.patch
* vfs-track-per-sb-writeback-errors-and-report-them-to-syncfs.patch
* buffer-record-blockdev-write-errors-in-super_block-that-it-backs.patch
* kernel-watchdog-flush-all-printk-nmi-buffers-when-hardlockup-detected.patch
  mm.patch
* usercopy-mark-dma-kmalloc-caches-as-usercopy-caches.patch
* mm-slub-fix-corrupted-freechain-in-deactivate_slab.patch
* mm-slub-fix-corrupted-freechain-in-deactivate_slab-fix.patch
* slub-remove-userspace-notifier-for-cache-add-remove.patch
* slub-remove-kmalloc-under-list_lock-from-list_slab_objects.patch
* mm-slub-fix-stack-overruns-with-slub_stats.patch
* mm-slub-add-panic_on_error-to-the-debug-facilities.patch
* mm-slub-add-panic_on_error-to-the-debug-facilities-fix.patch
* mm-dump_page-do-not-crash-with-invalid-mapping-pointer.patch
* mm-move-readahead-prototypes-from-mmh.patch
* mm-return-void-from-various-readahead-functions.patch
* mm-ignore-return-value-of-readpages.patch
* mm-move-readahead-nr_pages-check-into-read_pages.patch
* mm-add-new-readahead_control-api.patch
* mm-use-readahead_control-to-pass-arguments.patch
* mm-rename-various-offset-parameters-to-index.patch
* mm-rename-readahead-loop-variable-to-i.patch
* mm-remove-page_offset-from-readahead-loop.patch
* mm-put-readahead-pages-in-cache-earlier.patch
* mm-add-readahead-address-space-operation.patch
* mm-move-end_index-check-out-of-readahead-loop.patch
* mm-add-page_cache_readahead_unbounded.patch
* mm-document-why-we-dont-set-pagereadahead.patch
* mm-use-memalloc_nofs_save-in-readahead-path.patch
* fs-convert-mpage_readpages-to-mpage_readahead.patch
* btrfs-convert-from-readpages-to-readahead.patch
* erofs-convert-uncompressed-files-from-readpages-to-readahead.patch
* 

[tip:x86/entry] BUILD SUCCESS 82ff351052bcc4bf49dc966960f563d25f54d22b

2020-05-13 Thread kbuild test robot
 defconfig
arc  allyesconfig
shallnoconfig
microblazeallnoconfig
mips allyesconfig
mips  allnoconfig
mips allmodconfig
pariscallnoconfig
parisc   allyesconfig
parisc   allmodconfig
powerpc defconfig
powerpc  allyesconfig
powerpc  rhel-kconfig
powerpc  allmodconfig
powerpc   allnoconfig
i386 randconfig-a006-20200513
i386 randconfig-a005-20200513
i386 randconfig-a003-20200513
i386 randconfig-a001-20200513
i386 randconfig-a004-20200513
i386 randconfig-a002-20200513
x86_64   randconfig-a005-20200513
x86_64   randconfig-a003-20200513
x86_64   randconfig-a006-20200513
x86_64   randconfig-a004-20200513
x86_64   randconfig-a001-20200513
x86_64   randconfig-a002-20200513
i386 randconfig-a012-20200513
i386 randconfig-a016-20200513
i386 randconfig-a014-20200513
i386 randconfig-a011-20200513
i386 randconfig-a013-20200513
i386 randconfig-a015-20200513
riscvallyesconfig
riscv allnoconfig
riscv   defconfig
riscvallmodconfig
s390 allyesconfig
s390  allnoconfig
s390 allmodconfig
s390defconfig
x86_64  defconfig
sparc   defconfig
sparc64 defconfig
sparc64   allnoconfig
sparc64  allyesconfig
sparc64  allmodconfig
um   allmodconfig
umallnoconfig
um   allyesconfig
um  defconfig
x86_64   rhel
x86_64   rhel-7.6
x86_64rhel-7.6-kselftests
x86_64 rhel-7.2-clear
x86_64lkp
x86_64  fedora-25
x86_64  kexec

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


amd kdump failure with iommu=nopt

2020-05-13 Thread Jerry Snitselaar

We've seen kdump failures with recent kernels (5.5, 5.6, 5.7-rc1) on
amd systems when iommu is enabled in translation mode. In the cases so
far there has been mpt3sas involved, but I'm also seeing io page
faults for ahci right before mpt3sas has an io page fault:

[   15.156620] ahci :63:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT 
domain=0x0042 address=0xfff9b300 flags=0x0020]
[   15.166889] ahci :63:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT 
domain=0x0042 address=0xfff9b320 flags=0x0020]
[   15.177169] ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[   15.186100] ata4.00: failed to IDENTIFY (device reports invalid type, 
err_mask=0x0)
[   15.193786] ahci :63:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT 
domain=0x0042 address=0xf1f730c0 flags=0x0020]
[   15.204059] ahci :63:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT 
domain=0x0042 address=0xf1f732c0 flags=0x0020]
[   15.214327] ahci :63:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT 
domain=0x0042 address=0xf1f734c0 flags=0x0020]
[   15.224597] ahci :63:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT 
domain=0x0042 address=0xf1f736c0 flags=0x0020]
[   15.234867] ahci :63:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT 
domain=0x0042 address=0xf1f738c0 flags=0x0020]
[   15.245138] ahci :63:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT 
domain=0x0042 address=0xf1f73ac0 flags=0x0020]
[   15.255407] ahci :63:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT 
domain=0x0042 address=0xf1f73cc0 flags=0x0020]
[   15.265677] ahci :63:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT 
domain=0x0042 address=0xf1f73ec0 flags=0x0020]
[   20.599101] ata2.00: failed to IDENTIFY (INIT_DEV_PARAMS failed, 
err_mask=0x80)
[   20.916172] ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[   20.922429] ahci :63:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT 
domain=0x0042 address=0xfff9b300 flags=0x0020]
[   20.932703] ahci :63:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT 
domain=0x0042 address=0xfff9b320 flags=0x0020]
[   20.943234] ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[   20.949430] ata4.00: failed to IDENTIFY (device reports invalid type, 
err_mask=0x0)
[   20.957115] ahci :63:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT 
domain=0x0042 address=0xf1f730c0 flags=0x0020]
[   20.967384] ahci :63:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT 
domain=0x0042 address=0xf1f732c0 flags=0x0020]
[   20.977654] ahci :63:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT 
domain=0x0042 address=0xf1f734c0 flags=0x0020]
[   20.987923] ahci :63:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT 
domain=0x0042 address=0xf1f736c0 flags=0x0020]
[   20.998193] ahci :63:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT 
domain=0x0042 address=0xf1f738c0 flags=0x0020]
[   21.008464] ahci :63:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT 
domain=0x0042 address=0xf1f73ac0 flags=0x0020]
[   21.018733] ahci :63:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT 
domain=0x0042 address=0xf1f73cc0 flags=0x0020]
[   21.029005] ahci :63:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT 
domain=0x0042 address=0xf1f73ec0 flags=0x0020]
[   26.231097] ata2.00: failed to IDENTIFY (INIT_DEV_PARAMS failed, 
err_mask=0x80)
[   26.238415] ata2: limiting SATA link speed to 3.0 Gbps
[   26.548169] ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[   26.564483] ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 320)
[   26.571026] ahci :63:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT 
domain=0x0042 address=0xf1f730c0 flags=0x0020]
[   26.581301] ahci :63:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT 
domain=0x0042 address=0xf1f732c0 flags=0x0020]
[   26.591568] ahci :63:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT 
domain=0x0042 address=0xf1f734c0 flags=0x0020]
[   26.601839] ahci :63:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT 
domain=0x0042 address=0xf1f736c0 flags=0x0020]
[   26.612109] ahci :63:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT 
domain=0x0042 address=0xf1f738c0 flags=0x0020]
[   26.622377] ahci :63:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT 
domain=0x0042 address=0xf1f73ac0 flags=0x0020]
[   26.632647] ahci :63:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT 
domain=0x0042 address=0xf1f73cc0 flags=0x0020]
[   26.642917] ahci :63:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT 
domain=0x0042 address=0xf1f73ec0 flags=0x0020]
[   26.654047] ata2.00: failed to IDENTIFY (INIT_DEV_PARAMS failed, 
err_mask=0x80)
[   26.743097] xhci_hcd :05:00.3: Error while assigning device slot ID
[   26.749718] xhci_hcd :05:00.3: Max number of devices this xHCI host 
supports is 64.
[   26.757730] usb usb1-port2: couldn't allocate usb_device
[   26.987555] mpt3sas version 33.100.00.00 loaded
[   26.994668] mpt3sas_cm0: 63 BIT PCI BUS DMA ADDRESSING SUPPORTED, total mem 
(226256 kB)
[   27.060443] mpt3sas_cm0: CurrentHostPageSize is 0: Setting default host page 
size to 4k
[   27.068469] mpt3sas_cm0: MSI-X vectors supported: 96
[   27.073444]   no of cores: 1, max_msix_vectors: -1
[   27.078244] 

Re: [PATCH 1/1] Updated negative return values for documentation update.

2020-05-13 Thread CJ Lee
Dear Tiwai san,

First of all, thank you very much all those years you contributed on ALSA.

Couple of days ago I emailed you over updating remark fields.
The purpose of edit was providing more error and meaning to application 
engineers.

For example, when snd_pcm_writei returned -EIO, application engineer didn’t 
understand what it means because the documentation didn’t include -EIO comment.

Would you please let me know if I need to do something to apply these changes?
I’m very new to linux community, and I thought create a patch and email to 
relevant recipients.
However, it looks like I’m missing something here. :)

FYI, I have not changed any code. 

Thank you.

Best regards,
CJ Lee


> 2020. 5. 12. 오후 6:05, changjoon@lge.com 작성:
> 
> From: ChangJoon Lee 
> 
> Signed-off-by: ChangJoon Lee 
> ---
> src/pcm/pcm.c | 57 ---
> 1 file changed, 54 insertions(+), 3 deletions(-)
> 
> diff --git a/src/pcm/pcm.c b/src/pcm/pcm.c
> index 1064044c..b53797a6 100644
> --- a/src/pcm/pcm.c
> +++ b/src/pcm/pcm.c
> @@ -820,6 +820,7 @@ int snd_pcm_nonblock(snd_pcm_t *pcm, int nonblock)
>  * \param sig Signal to raise: < 0 disable, 0 default (SIGIO)
>  * \param pid Process ID to signal: 0 current
>  * \return 0 on success otherwise a negative error code
> + * \return -ENOSYS Async is not supported on this PCM
>  *
>  * A signal is raised every period.
>  */
> @@ -850,6 +851,7 @@ int snd_pcm_async(snd_pcm_t *pcm, int sig, pid_t pid)
>  * \param pcm PCM handle
>  * \param info Information container
>  * \return 0 on success otherwise a negative error code
> + * \return -ENOSYS Info is not supported on this PCM
>  */
> int snd_pcm_info(snd_pcm_t *pcm, snd_pcm_info_t *info)
> {
> @@ -867,6 +869,7 @@ int snd_pcm_info(snd_pcm_t *pcm, snd_pcm_info_t *info)
>  * \param pcm PCM handle
>  * \param params Configuration space definition container
>  * \return 0 on success otherwise a negative error code
> + * \return -EBADFD PCM has not been setup (PCM isn't configured yet, or 
> lifecycle of PCM has been ended)
>  */
> int snd_pcm_hw_params_current(snd_pcm_t *pcm, snd_pcm_hw_params_t *params)
> {
> @@ -933,6 +936,7 @@ int snd_pcm_hw_params(snd_pcm_t *pcm, snd_pcm_hw_params_t 
> *params)
> /** \brief Remove PCM hardware configuration and free associated resources
>  * \param pcm PCM handle
>  * \return 0 on success otherwise a negative error code
> + * \return -ENOSYS Hw_free is not supported on this PCM
>  */
> int snd_pcm_hw_free(snd_pcm_t *pcm)
> {
> @@ -960,7 +964,9 @@ int snd_pcm_hw_free(snd_pcm_t *pcm)
>  * \param pcm PCM handle
>  * \param params Configuration container
>  * \return 0 on success otherwise a negative error code
> - *
> + * \retval -EIO PCM has not been setup (PCM isn't configured yet, or 
> lifecycle of PCM has been ended)
> + * \retval -EINVAL Incorrect parameter, avail_min cannot be 0
> + * 
>  * The software parameters can be changed at any time.
>  * The hardware parameters cannot be changed when the stream is
>  * running (active).
> @@ -1017,6 +1023,7 @@ int snd_pcm_sw_params(snd_pcm_t *pcm, 
> snd_pcm_sw_params_t *params)
>  * \param pcm PCM handle
>  * \param status Status container
>  * \return 0 on success otherwise a negative error code
> + * \return -ENOSYS Status is not supported on this PCM
>  *
>  * The function is thread-safe when built with the proper option.
>  */
> @@ -1060,7 +1067,8 @@ snd_pcm_state_t snd_pcm_state(snd_pcm_t *pcm)
>  * \brief (DEPRECATED) Synchronize stream position with hardware
>  * \param pcm PCM handle
>  * \return 0 on success otherwise a negative error code
> - *
> + * \retval -EIO PCM has not been setup (PCM isn't configured yet, or 
> lifecycle of PCM has been ended)
> + * 
>  * Note this function does not update the actual r/w pointer
>  * for applications. The function #snd_pcm_avail_update()
>  * have to be called before any mmap begin+commit operation.
> @@ -1089,6 +1097,7 @@ int snd_pcm_hwsync(snd_pcm_t *pcm)
>  * \param pcm PCM handle
>  * \param delayp Returned delay in frames
>  * \return 0 on success otherwise a negative error code
> + * \retval -EIO PCM has not been setup (PCM isn't configured yet, or 
> lifecycle of PCM has been ended)
>  *
>  * For playback the delay is defined as the time that a frame that is written
>  * to the PCM stream shortly after this call will take to be actually
> @@ -1133,6 +1142,7 @@ int snd_pcm_delay(snd_pcm_t *pcm, snd_pcm_sframes_t 
> *delayp)
>  * \brief Resume from suspend, no samples are lost
>  * \param pcm PCM handle
>  * \return 0 on success otherwise a negative error code
> + * \retval -EIOPCM has not been setup (PCM isn't configured yet, or 
> lifecycle of PCM has been ended)
>  * \retval -EAGAIN resume can't be proceed immediately (audio hardware is 
> probably still suspended)
>  * \retval -ENOSYS hardware doesn't support this feature
>  *
> @@ -1166,6 +1176,8 @@ int snd_pcm_resume(snd_pcm_t *pcm)
>  * \param avail Number of available frames when timestamp 

Re: [PATCH v17 02/10] landlock: Add ruleset and domain management

2020-05-13 Thread James Morris
On Mon, 11 May 2020, Mickaël Salaün wrote:

> + * .. warning::
> + *
> + *   It is currently not possible to restrict some file-related actions
> + *   accessible through these syscall families: :manpage:`chdir(2)`,
> + *   :manpage:`truncate(2)`, :manpage:`stat(2)`, :manpage:`flock(2)`,
> + *   :manpage:`chmod(2)`, :manpage:`chown(2)`, :manpage:`setxattr(2)`,
> + *   :manpage:`ioctl(2)`, :manpage:`fcntl(2)`.
> + *   Future Landlock evolutions will enable to restrict them.

I have to wonder how useful Landlock will be without more coverage per 
the above.

It would be helpful if you could outline a threat model for this initial 
version, so people can get an idea of what kind of useful protection may
be gained from it.

Are there any distros or other major users who are planning on enabling or 
at least investigating Landlock?

Do you have any examples of a practical application of this scheme?



-- 
James Morris



Re: [PATCH v5 3/6] fs: Enable to enforce noexec mounts or file exec through O_MAYEXEC

2020-05-13 Thread Kees Cook
On Wed, May 13, 2020 at 04:27:39PM -0700, Kees Cook wrote:
> Like, couldn't just the entire thing just be:
> 
> diff --git a/fs/namei.c b/fs/namei.c
> index a320371899cf..0ab18e19f5da 100644
> --- a/fs/namei.c
> +++ b/fs/namei.c
> @@ -2849,6 +2849,13 @@ static int may_open(const struct path *path, int 
> acc_mode, int flag)
>   break;
>   }
>  
> + if (unlikely(mask & MAY_OPENEXEC)) {
> + if (sysctl_omayexec_enforce & OMAYEXEC_ENFORCE_MOUNT &&
> + path_noexec(path))
> + return -EACCES;
> + if (sysctl_omayexec_enforce & OMAYEXEC_ENFORCE_FILE)
> + acc_mode |= MAY_EXEC;
> + }
>   error = inode_permission(inode, MAY_OPEN | acc_mode);
>   if (error)
>   return error;
> 

FYI, I've confirmed this now. Effectively with patch 2 dropped, patch 3
reduced to this plus the Kconfig and sysctl changes, the self tests
pass.

I think this makes things much cleaner and correct.

-- 
Kees Cook


Re: ld.lld: error: undefined symbol: kb_cs

2020-05-13 Thread Nathan Chancellor
On Thu, May 14, 2020 at 08:13:48AM +0800, kbuild test robot wrote:
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
> master
> head:   24085f70a6e1b0cb647ec92623284641d8270637
> commit: 5990cdee689c6885b27c6d969a3d58b09002b0bc lib/mpi: Fix building for 
> powerpc with clang

I am certain that this patch did nothing to cause this... Maybe exposed
it but not the root cause.

> date:   3 weeks ago
> config: powerpc-randconfig-r034-20200514 (attached as .config)
> compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project 
> 310d32cb80a611e6384a921e85607fea05841f26)
> reproduce:
> wget 
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # install powerpc cross compiling tool for clang build
> # apt-get install binutils-powerpc-linux-gnu
> git checkout 5990cdee689c6885b27c6d969a3d58b09002b0bc
> # save the attached .config to linux build tree
> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross 
> ARCH=powerpc 
> 
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kbuild test robot 
> 
> All errors (new ones prefixed by >>):
> 
> >> ld.lld: error: undefined symbol: kb_cs
> >>> referenced by i8042-ppcio.h:28 (drivers/input/serio/i8042-ppcio.h:28)
> >>> input/serio/i8042.o:(__i8042_command) in archive drivers/built-in.a
> >>> referenced by i8042-ppcio.h:28 (drivers/input/serio/i8042-ppcio.h:28)
> >>> input/serio/i8042.o:(__i8042_command) in archive drivers/built-in.a
> >>> referenced by i8042-ppcio.h:28 (drivers/input/serio/i8042-ppcio.h:28)
> >>> input/serio/i8042.o:(__i8042_command) in archive drivers/built-in.a
> >>> referenced 45 more times
> --
> >> ld.lld: error: undefined symbol: kb_data
> >>> referenced by i8042.c:309 (drivers/input/serio/i8042.c:309)
> >>> input/serio/i8042.o:(__i8042_command) in archive drivers/built-in.a
> >>> referenced by i8042-ppcio.h:33 (drivers/input/serio/i8042-ppcio.h:33)
> >>> input/serio/i8042.o:(__i8042_command) in archive drivers/built-in.a
> >>> referenced by i8042.c:319 (drivers/input/serio/i8042.c:319)
> >>> input/serio/i8042.o:(__i8042_command) in archive drivers/built-in.a
> >>> referenced 15 more times

kb_cs and kb_data are declared as extern void pointers when
CONFIG_WALNUT is set, which this config does. However, it looks like
the definitions of these variables were removed in
commit  917f0af9e5a9 ("powerpc: Remove arch/ppc and include/asm-ppc"),
way back in 2.6.27-rc1... So presumably, this has been broken for 12
years and nobody noticed? Probably means there is a good amount of dead
code that can be removed, or we could just avoid ever selecting this
driver with CONFIG_WALNUT (if it does not actually work without the
special handling from i8042-ppcio.h) while removing the dead code.

Cheers,
Nathan

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 924c541a9260..59b2f655e39e 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -138,7 +138,7 @@ config PPC
select ARCH_HAVE_NMI_SAFE_CMPXCHG
select ARCH_KEEP_MEMBLOCK
select ARCH_MIGHT_HAVE_PC_PARPORT
-   select ARCH_MIGHT_HAVE_PC_SERIO
+   select ARCH_MIGHT_HAVE_PC_SERIO if !WALNUT
select ARCH_OPTIONAL_KERNEL_RWX if ARCH_HAS_STRICT_KERNEL_RWX
select ARCH_SUPPORTS_ATOMIC_RMW
select ARCH_USE_BUILTIN_BSWAP
diff --git a/drivers/input/serio/i8042-ppcio.h 
b/drivers/input/serio/i8042-ppcio.h
deleted file mode 100644
index 391f94d9e47d..
--- a/drivers/input/serio/i8042-ppcio.h
+++ /dev/null
@@ -1,57 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0-only */
-#ifndef _I8042_PPCIO_H
-#define _I8042_PPCIO_H
-
-
-#if defined(CONFIG_WALNUT)
-
-#define I8042_KBD_IRQ 25
-#define I8042_AUX_IRQ 26
-
-#define I8042_KBD_PHYS_DESC "walnutps2/serio0"
-#define I8042_AUX_PHYS_DESC "walnutps2/serio1"
-#define I8042_MUX_PHYS_DESC "walnutps2/serio%d"
-
-extern void *kb_cs;
-extern void *kb_data;
-
-#define I8042_COMMAND_REG (*(int *)kb_cs)
-#define I8042_DATA_REG (*(int *)kb_data)
-
-static inline int i8042_read_data(void)
-{
-   return readb(kb_data);
-}
-
-static inline int i8042_read_status(void)
-{
-   return readb(kb_cs);
-}
-
-static inline void i8042_write_data(int val)
-{
-   writeb(val, kb_data);
-}
-
-static inline void i8042_write_command(int val)
-{
-   writeb(val, kb_cs);
-}
-
-static inline int i8042_platform_init(void)
-{
-   i8042_reset = I8042_RESET_ALWAYS;
-   return 0;
-}
-
-static inline void i8042_platform_exit(void)
-{
-}
-
-#else
-
-#include "i8042-io.h"
-
-#endif
-
-#endif /* _I8042_PPCIO_H */
diff --git a/drivers/input/serio/i8042.h b/drivers/input/serio/i8042.h
index 38dc27ad3c18..eb376700dfff 100644
--- a/drivers/input/serio/i8042.h
+++ b/drivers/input/serio/i8042.h
@@ -17,8 +17,6 @@
 #include "i8042-ip22io.h"
 #elif defined(CONFIG_SNI_RM)
 #include "i8042-snirm.h"
-#elif defined(CONFIG_PPC)

linux-next: manual merge of the mlx5-next tree with the rdma tree

2020-05-13 Thread Stephen Rothwell
Hi all,

Today's linux-next merge of the mlx5-next tree got a conflict in:

  drivers/infiniband/hw/mlx5/main.c

between commit:

  2be08c308f10 ("RDMA/mlx5: Delete create QP flags obfuscation")

from the rdma tree and commit:

  14c129e30152 ("{IB/net}/mlx5: Simplify don't trap code")

from the mlx5-next tree.

I fixed it up (the latter change included the former) and can carry the
fix as necessary. This is now fixed as far as linux-next is concerned,
but any non trivial conflicts should be mentioned to your upstream
maintainer when your tree is submitted for merging.  You may also want
to consider cooperating with the maintainer of the conflicting tree to
minimise any particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell


pgpY7lJCkuM8f.pgp
Description: OpenPGP digital signature


Re: [patch V4 part 1 05/36] x86/entry: Flip _TIF_SIGPENDING and _TIF_NOTIFY_RESUME handling

2020-05-13 Thread Mathieu Desnoyers
- On May 13, 2020, at 8:12 PM, Thomas Gleixner t...@linutronix.de wrote:
[...]
> 
>>> Mathieu Desnoyers  wrote:
> 
>>> Also, color me confused: is "do_signal()" actually running any user-space,
>>> or just setting up the user-space stack for eventual return to signal
>>> handler ?
> 
> I'm surprised that you can't answer that question yourself. How did you
> ever make rseq work and how did rseq_signal_deliver() end up in
> setup_rt_frame()?
> 
> Hint: Tracing might answer that question
> 
> And to cut it short:
> 
>Exit to user space happnes only through ONE channel, i.e. leaving
>prepare_exit_to usermode().
> 

[...]

Yes, I'm very well aware of this. But the patch commit message states:

"Make sure task_work runs before any kind of userspace -- very much
including signals -- is invoked."

which seems to imply that "userspace" can be "invoked" before the task_work
runs. Which makes no sense whatsoever. Hence my confused state.

>>> Also, it might be OK, but we're changing the order of two things which
>>> have effects on each other: restartable sequences abort fixup for preemption
>>> and do_signal(), which also have effects on rseq abort.
>>> 
>>> Because those two will cause the abort to trigger, I suspect changing
>>> the order might be OK, but we really need to think this through.
> 
> That's a purely academic problem. The order is completely
> irrelevant. You have to handle any order anyway:

Yes indeed, whether either a signal handler frame fixup or return IP
fixup fires first (clearing the rseq_cs pointer in the process) is
irrelevant, because they will have the effect on the user-space program's
flow. And as you say, given it is run in a loop and can be preempted,
any order can happen here, so we have to be prepared for it. This loop
has caused me tons of headaches when stress-testing on NUMA machines by
the way.

> That said, even for the case Andy and Peter were looking at (MCE) the
> ordering is completely irrelevant.

Not sure about that, see Andy's follow up.

Thanks,

Mathieu


-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com


Re: [PATCH v2] USB: host: ehci-mxc: Add error handling in ehci_mxc_drv_probe()

2020-05-13 Thread Peter Chen
On 20-05-13 21:26:47, Tang Bin wrote:
> The function ehci_mxc_drv_probe() does not perform sufficient error
> checking after executing platform_get_irq(), thus fix it.
> 
> Fixes: 7e8d5cd93fa ("USB: Add EHCI support for MX27 and MX31 based boards")
> Signed-off-by: Zhang Shengju 
> Signed-off-by: Tang Bin 
> ---
> Changes from v1
>  - fix the subject.
> ---
>  drivers/usb/host/ehci-mxc.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/usb/host/ehci-mxc.c b/drivers/usb/host/ehci-mxc.c
> index c9f91e6c7..7f65c8604 100644
> --- a/drivers/usb/host/ehci-mxc.c
> +++ b/drivers/usb/host/ehci-mxc.c
> @@ -50,6 +50,8 @@ static int ehci_mxc_drv_probe(struct platform_device *pdev)
>   }
>  
>   irq = platform_get_irq(pdev, 0);
> + if (irq < 0)
> + return irq;
>  
>   hcd = usb_create_hcd(_mxc_hc_driver, dev, dev_name(dev));
>   if (!hcd)
> -- 

Reviewed-by: Peter Chen 

-- 

Thanks,
Peter Chen

Re: [patch V4 part 3 11/29] rcu: Provide rcu_irq_exit_preempt()

2020-05-13 Thread Joel Fernandes
On Wed, May 13, 2020 at 10:41:16PM -0400, Joel Fernandes wrote:
> Hi Thomas,
> 
> On Tue, May 05, 2020 at 03:44:05PM +0200, Thomas Gleixner wrote:
> 
> Thank you for CC'ing me.
> 
> > Interrupts and exceptions invoke rcu_irq_enter() on entry and need to
> > invoke rcu_irq_exit() before they either return to the interrupted code or
> > invoke the scheduler due to preemption.
> > 
> > The general assumption is that RCU idle code has to have preemption
> > disabled so that a return from interrupt cannot schedule. So the return
> > from interrupt code invokes rcu_irq_exit() and preempt_schedule_irq().
> > 
> > If there is any imbalance in the rcu_irq/nmi* invocations or RCU idle code
> > had preemption enabled then this goes unnoticed until the CPU goes idle or
> > some other RCU check is executed.
> > 
> > Provide rcu_irq_exit_preempt() which can be invoked from the
> > interrupt/exception return code in case that preemption is enabled. It
> > invokes rcu_irq_exit() and contains a few sanity checks in case that
> > CONFIG_PROVE_RCU is enabled to catch such issues directly.
> 
> Could you let me know which patch or part in the multi-part series is using 
> it?

Ah I see its "x86/entry/common: Provide idtentry_enter/exit()" patch. I'll go
read that tomorrow. Thanks!

 - Joel



Re: [PATCH] lockdown: Allow unprivileged users to see lockdown status

2020-05-13 Thread James Morris
On Mon, 11 May 2020, Jeremy Cline wrote:

> On Sat, Feb 22, 2020 at 03:51:24AM +1100, James Morris wrote:
> > On Thu, 20 Feb 2020, Jeremy Cline wrote:
> > 
> > > A number of userspace tools, such as systemtap, need a way to see the
> > > current lockdown state so they can gracefully deal with the kernel being
> > > locked down. The state is already exposed in
> > > /sys/kernel/security/lockdown, but is only readable by root. Adjust the
> > > permissions so unprivileged users can read the state.
> > > 
> > > Fixes: 000d388ed3bb ("security: Add a static lockdown policy LSM")
> > > Cc: Frank Ch. Eigler 
> > > Signed-off-by: Jeremy Cline 
> > 
> > Looks fine to me, any objection from Matthew or others?
> > 
> 
> Can we take resounding silence as no objections?

Please resend and I'll apply it to my tree.

> 
> - Jeremy
> 
> > > ---
> > >  security/lockdown/lockdown.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/security/lockdown/lockdown.c b/security/lockdown/lockdown.c
> > > index 5a952617a0eb..87cbdc64d272 100644
> > > --- a/security/lockdown/lockdown.c
> > > +++ b/security/lockdown/lockdown.c
> > > @@ -150,7 +150,7 @@ static int __init lockdown_secfs_init(void)
> > >  {
> > >   struct dentry *dentry;
> > >  
> > > - dentry = securityfs_create_file("lockdown", 0600, NULL, NULL,
> > > + dentry = securityfs_create_file("lockdown", 0644, NULL, NULL,
> > >   _ops);
> > >   return PTR_ERR_OR_ZERO(dentry);
> > >  }
> > > 
> > 
> > -- 
> > James Morris
> > 
> > 
> 

-- 
James Morris




Re: [PATCH 11/18] maccess: remove strncpy_from_unsafe

2020-05-13 Thread Linus Torvalds
On Wed, May 13, 2020 at 6:00 PM Masami Hiramatsu  wrote:
>
> > But we should likely at least disallow it entirely on platforms where
> > we really can't - or pick one hardcoded choice. On sparc, you really
> > _have_ to specify one or the other.
>
> OK. BTW, is there any way to detect the kernel/user space overlap on
> memory layout statically? If there, I can do it. (I don't like
> "if (CONFIG_X86)" thing)
> Or, maybe we need CONFIG_ARCH_OVERLAP_ADDRESS_SPACE?

I think it would be better to have a CONFIG variable that
architectures can just 'select' to show that they are ok with separate
kernel and user addresses.

Because I don't think we have any way to say that right now as-is. You
can probably come up with hacky ways to approximate it, ie something
like

if (TASK_SIZE_MAX > PAGE_OFFSET)
 they overlap ..

which would almost work, but..

 Linus


Re: [patch V4 part 3 11/29] rcu: Provide rcu_irq_exit_preempt()

2020-05-13 Thread Joel Fernandes
Hi Thomas,

On Tue, May 05, 2020 at 03:44:05PM +0200, Thomas Gleixner wrote:

Thank you for CC'ing me.

> Interrupts and exceptions invoke rcu_irq_enter() on entry and need to
> invoke rcu_irq_exit() before they either return to the interrupted code or
> invoke the scheduler due to preemption.
> 
> The general assumption is that RCU idle code has to have preemption
> disabled so that a return from interrupt cannot schedule. So the return
> from interrupt code invokes rcu_irq_exit() and preempt_schedule_irq().
> 
> If there is any imbalance in the rcu_irq/nmi* invocations or RCU idle code
> had preemption enabled then this goes unnoticed until the CPU goes idle or
> some other RCU check is executed.
> 
> Provide rcu_irq_exit_preempt() which can be invoked from the
> interrupt/exception return code in case that preemption is enabled. It
> invokes rcu_irq_exit() and contains a few sanity checks in case that
> CONFIG_PROVE_RCU is enabled to catch such issues directly.

Could you let me know which patch or part in the multi-part series is using it?

> 
> Signed-off-by: Thomas Gleixner 
> Cc: "Paul E. McKenney" 
> Cc: Joel Fernandes 
> ---
>  include/linux/rcutiny.h |1 +
>  include/linux/rcutree.h |1 +
>  kernel/rcu/tree.c   |   21 +
>  3 files changed, 23 insertions(+)
> 
> --- a/include/linux/rcutiny.h
> +++ b/include/linux/rcutiny.h
> @@ -71,6 +71,7 @@ static inline void rcu_irq_enter(void) {
>  static inline void rcu_irq_exit_irqson(void) { }
>  static inline void rcu_irq_enter_irqson(void) { }
>  static inline void rcu_irq_exit(void) { }
> +static inline void rcu_irq_exit_preempt(void) { }
>  static inline void exit_rcu(void) { }
>  static inline bool rcu_preempt_need_deferred_qs(struct task_struct *t)
>  {
> --- a/include/linux/rcutree.h
> +++ b/include/linux/rcutree.h
> @@ -46,6 +46,7 @@ void rcu_idle_enter(void);
>  void rcu_idle_exit(void);
>  void rcu_irq_enter(void);
>  void rcu_irq_exit(void);
> +void rcu_irq_exit_preempt(void);
>  void rcu_irq_enter_irqson(void);
>  void rcu_irq_exit_irqson(void);
>  
> --- a/kernel/rcu/tree.c
> +++ b/kernel/rcu/tree.c
> @@ -706,6 +706,27 @@ void noinstr rcu_irq_exit(void)
>   rcu_nmi_exit();
>  }
>  
> +/**
> + * rcu_irq_exit_preempt - Inform RCU that current CPU is exiting irq
> + * towards in kernel preemption
> + *
> + * Same as rcu_irq_exit() but has a sanity check that scheduling is safe
> + * from RCU point of view. Invoked from return from interrupt before kernel
> + * preemption.
> + */
> +void rcu_irq_exit_preempt(void)
> +{
> + lockdep_assert_irqs_disabled();
> + rcu_nmi_exit();
> +
> + RCU_LOCKDEP_WARN(__this_cpu_read(rcu_data.dynticks_nesting) <= 0,
> +  "RCU dynticks_nesting counter underflow/zero!");

Makes sense.

> + RCU_LOCKDEP_WARN(__this_cpu_read(rcu_data.dynticks_nmi_nesting) <= 0,
> +  "RCU dynticks_nmi_nesting counter underflow/zero!");

This new function will be called only from the outer-most IRQ that
interrupted kernel mode (process context). Right? If so, a better (more
specific) check for the second RCU_LOCKDEP_WARN above is:

RCU_LOCKDEP_WARN(__this_cpu_read(rcu_data.dynticks_nmi_nesting) != 
DYNTICK_IRQ_NONIDLE,
 "Bad RCU dynticks_nmi_nesting counter\n");

That will make sure, it is only called from outer-most rcu_irq_exit() and
interrupting kernel mode.

Or, if [1] is merged, then we could just combine the checks into one check.
RCU_LOCKDEP_WARN(__this_cpu_read(rcu_data.dynticks_nesting) != 1,
 "Bad RCU dynticks_nmi_nesting counter\n");

> + RCU_LOCKDEP_WARN(rcu_dynticks_curr_cpu_in_eqs(),
> +  "RCU in extended quiescent state!");

Makes sense.

BTW, I wonder if a better place to do this "don't enter scheduler while RCU
is not watching" is rcu_note_context_switch()...

thanks,

 - Joel
[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/jfern/linux.git/commit/?h=rcu-dynticks-may4-rebased=b48863c234295d8ec956b50f6cf5ae0a0269f48d

> +}
> +
>  /*
>   * Wrapper for rcu_irq_exit() where interrupts are enabled.
>   *
> 


Re: [PATCH 2/3] drm/etnaviv: Don't ignore errors on getting clocks

2020-05-13 Thread Fabio Estevam
On Wed, May 13, 2020 at 2:09 PM Fabio Estevam  wrote:

> The binding doc Documentation/devicetree/bindings/gpu/vivante,gc.yaml
> says that only the 'reg' clock could be optional, the others are
> required.

arch/arm/boot/dts/dove.dtsi only uses the 'core' clock.
arch/arm/boot/dts/stm32mp157.dtsi uses 'bus' and 'core'

Maybe the binding needs to be updated and it seems that using
devm_clk_get_optional() like you propose is safe.


[tip:locking/kcsan] BUILD SUCCESS ffed638b6a2180da8fd002a46632d746af72b299

2020-05-13 Thread kbuild test robot
-20200513
x86_64   randconfig-a003-20200513
x86_64   randconfig-a006-20200513
x86_64   randconfig-a004-20200513
x86_64   randconfig-a001-20200513
x86_64   randconfig-a002-20200513
riscvallyesconfig
riscv   defconfig
riscvallmodconfig
s390 allyesconfig
s390  allnoconfig
s390 allmodconfig
s390defconfig
x86_64  defconfig
sparc   defconfig
sparc64 defconfig
sparc64   allnoconfig
sparc64  allyesconfig
sparc64  allmodconfig
um   allmodconfig
umallnoconfig
um   allyesconfig
um  defconfig
x86_64   rhel
x86_64   rhel-7.6
x86_64rhel-7.6-kselftests
x86_64 rhel-7.2-clear
x86_64lkp
x86_64  fedora-25
x86_64  kexec

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


Re: [PATCH] fpga: dfl: afu: Corrected error handling levels

2020-05-13 Thread Xu Yilun
The patch looks good to me.

Maybe we could add the Fixes tag:
  Fixes: fa8dda1edef9 (fpga: dfl: afu: add DFL_FPGA_PORT_DMA_MAP/UNMAP ioctls 
support)

Thanks,
Yilun

On Thu, May 14, 2020 at 12:52:05AM +0530, Souptick Joarder wrote:
> Corrected error handling goto sequnece. Level put_pages should
> be called when pinned pages >= 0 && pinned != npages. Level
> free_pages should be called when pinned pages < 0.
> 
> Signed-off-by: Souptick Joarder 
> ---
>  drivers/fpga/dfl-afu-dma-region.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/fpga/dfl-afu-dma-region.c 
> b/drivers/fpga/dfl-afu-dma-region.c
> index 62f9244..5942343 100644
> --- a/drivers/fpga/dfl-afu-dma-region.c
> +++ b/drivers/fpga/dfl-afu-dma-region.c
> @@ -61,10 +61,10 @@ static int afu_dma_pin_pages(struct 
> dfl_feature_platform_data *pdata,
>region->pages);
>   if (pinned < 0) {
>   ret = pinned;
> - goto put_pages;
> + goto free_pages;
>   } else if (pinned != npages) {
>   ret = -EFAULT;
> - goto free_pages;
> + goto put_pages;
>   }
>  
>   dev_dbg(dev, "%d pages pinned\n", pinned);
> -- 
> 1.9.1


Re: [patch V4 part 4 15/24] x86/db: Split out dr6/7 handling

2020-05-13 Thread Mathieu Desnoyers
- On May 5, 2020, at 9:49 AM, Thomas Gleixner t...@linutronix.de wrote:

> From: Peter Zijlstra 
> 
> DR6/7 should be handled before nmi_enter() is invoked and restore after
> nmi_exit() to minimize the exposure.
> 
> Split it out into helper inlines and bring it into the correct order.
> 
[...]
> 
> +static __always_inline void debug_enter(unsigned long *dr6, unsigned long 
> *dr7)
> +{
> + /*
> +  * Disable breakpoints during exception handling; recursive exceptions
> +  * are exceedingly 'fun'.
> +  *
> +  * Since this function is NOKPROBE, and that also applies to
> +  * HW_BREAKPOINT_X, we can't hit a breakpoint before this (XXX except a
> +  * HW_BREAKPOINT_W on our stack)
> +  *
> +  * Entry text is excluded for HW_BP_X and cpu_entry_area, which
> +  * includes the entry stack is excluded for everything.
> +  */
> + get_debugreg(*dr7, 6);
> + set_debugreg(0, 7);
> +
> + /*
> +  * The Intel SDM says:
> +  *
> +  *   Certain debug exceptions may clear bits 0-3. The remaining
> +  *   contents of the DR6 register are never cleared by the
> +  *   processor. To avoid confusion in identifying debug
> +  *   exceptions, debug handlers should clear the register before
> +  *   returning to the interrupted task.
> +  *
> +  * Keep it simple: clear DR6 immediately.
> +  */
> + get_debugreg(*dr6, 6);
> + set_debugreg(0, 6);
> + /* Filter out all the reserved bits which are preset to 1 */
> + *dr6 &= ~DR6_RESERVED;
> +}
> +
> +static __always_inline void debug_exit(unsigned long dr7)
> +{
> + set_debugreg(dr7, 7);
> +}

Out of curiosity, what prevents the compiler from moving instructions
outside of the code regions surrounded by entry/exit ? This is an always
inline, which invokes set_debugreg which is inline for CONFIG_PARAVIRT_XXL=n,
which in turn uses an asm() (not volatile), without any memory clobber.

Also, considering that "inline" is not sufficient to ensure the compiler
does not emit a traceable function, I suspect you'll also want to mark
"native_get_debugreg" and "native_set_debugreg" always inline as well.

Thanks,

Mathieu

> +
> /*
>  * Our handling of the processor debug registers is non-trivial.
>  * We do not clear them on entry and exit from the kernel. Therefore
> @@ -718,28 +756,13 @@ static bool is_sysenter_singlestep(struc
> dotraplinkage void do_debug(struct pt_regs *regs, long error_code)
> {
>   struct task_struct *tsk = current;
> + unsigned long dr6, dr7;
>   int user_icebp = 0;
> - unsigned long dr6;
>   int si_code;
> 
> - nmi_enter();
> -
> - get_debugreg(dr6, 6);
> - /*
> -  * The Intel SDM says:
> -  *
> -  *   Certain debug exceptions may clear bits 0-3. The remaining
> -  *   contents of the DR6 register are never cleared by the
> -  *   processor. To avoid confusion in identifying debug
> -  *   exceptions, debug handlers should clear the register before
> -  *   returning to the interrupted task.
> -  *
> -  * Keep it simple: clear DR6 immediately.
> -  */
> - set_debugreg(0, 6);
> + debug_enter(, );
> 
> - /* Filter out all the reserved bits which are preset to 1 */
> - dr6 &= ~DR6_RESERVED;
> + nmi_enter();
> 
>   /*
>* The SDM says "The processor clears the BTF flag when it
> @@ -777,7 +800,7 @@ dotraplinkage void do_debug(struct pt_re
> #endif
> 
>   if (notify_die(DIE_DEBUG, "debug", regs, (long), error_code,
> - SIGTRAP) == NOTIFY_STOP)
> +SIGTRAP) == NOTIFY_STOP)
>   goto exit;
> 
>   /*
> @@ -816,6 +839,7 @@ dotraplinkage void do_debug(struct pt_re
> 
> exit:
>   nmi_exit();
> + debug_exit(dr7);
> }
>  NOKPROBE_SYMBOL(do_debug);

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com


Re: [PATCH v1 4/4] scsi: ufs: Fix WriteBooster flush during runtime suspend

2020-05-13 Thread Stanley Chu
Hi Asutosh,

On Wed, 2020-05-13 at 12:31 -0700, Asutosh Das (asd) wrote:
> On 5/12/2020 3:47 AM, Stanley Chu wrote:
> > Currently UFS host driver promises VCC supply if UFS device
> > needs to do WriteBooster flush during runtime suspend.
> > 
> > However the UFS specification mentions,
> > 
> > "While the flushing operation is in progress, the device is
> > in Active power mode."
> > 
> > Therefore UFS host driver needs to promise more: Keep UFS
> > device as "Active power mode", otherwise UFS device shall not
> > do any flush if device enters Sleep or PowerDown power mode.
> > 
> > Fix this by not changing device power mode if WriteBooster
> > flush is required in ufshcd_suspend().
> > 
> > Signed-off-by: Stanley Chu 
> > ---
> >   drivers/scsi/ufs/ufs.h|  1 -
> >   drivers/scsi/ufs/ufshcd.c | 39 +++
> >   2 files changed, 19 insertions(+), 21 deletions(-)
> > 
> > diff --git a/drivers/scsi/ufs/ufs.h b/drivers/scsi/ufs/ufs.h
> > index b3135344ab3f..9e4bc2e97ada 100644
> > --- a/drivers/scsi/ufs/ufs.h
> > +++ b/drivers/scsi/ufs/ufs.h
> > @@ -577,7 +577,6 @@ struct ufs_dev_info {
> > u32 d_ext_ufs_feature_sup;
> > u8 b_wb_buffer_type;
> > u32 d_wb_alloc_units;
> > -   bool keep_vcc_on;
> > u8 b_presrv_uspc_en;
> >   };
> >   
> > diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
> > index 169a3379e468..2d0aff8ac260 100644
> > --- a/drivers/scsi/ufs/ufshcd.c
> > +++ b/drivers/scsi/ufs/ufshcd.c
> > @@ -8101,8 +8101,7 @@ static void ufshcd_vreg_set_lpm(struct ufs_hba *hba)
> > !hba->dev_info.is_lu_power_on_wp) {
> > ufshcd_setup_vreg(hba, false);
> > } else if (!ufshcd_is_ufs_dev_active(hba)) {
> > -   if (!hba->dev_info.keep_vcc_on)
> > -   ufshcd_toggle_vreg(hba->dev, hba->vreg_info.vcc, false);
> > +   ufshcd_toggle_vreg(hba->dev, hba->vreg_info.vcc, false);
> > if (!ufshcd_is_link_active(hba)) {
> > ufshcd_config_vreg_lpm(hba, hba->vreg_info.vccq);
> > ufshcd_config_vreg_lpm(hba, hba->vreg_info.vccq2);
> > @@ -8172,6 +8171,7 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum 
> > ufs_pm_op pm_op)
> > enum ufs_pm_level pm_lvl;
> > enum ufs_dev_pwr_mode req_dev_pwr_mode;
> > enum uic_link_state req_link_state;
> > +   bool keep_curr_dev_pwr_mode = false;
> >   
> > hba->pm_op_in_progress = 1;
> > if (!ufshcd_is_shutdown_pm(pm_op)) {
> > @@ -8226,28 +8226,27 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum 
> > ufs_pm_op pm_op)
> > /* make sure that auto bkops is disabled */
> > ufshcd_disable_auto_bkops(hba);
> > }
> > +
> Unnecessary newline, perhaps?

Yap, I will remove it in next version.

> > /*
> > -* With wb enabled, if the bkops is enabled or if the
> > -* configured WB type is 70% full, keep vcc ON
> > -* for the device to flush the wb buffer
> > +* If device needs to do BKOP or WB buffer flush, keep device
> > +* power mode as "active power mode" and its VCC supply.
> >  */
> > -   if ((hba->auto_bkops_enabled && ufshcd_is_wb_allowed(hba)) ||
> > -   ufshcd_wb_keep_vcc_on(hba))
> > -   hba->dev_info.keep_vcc_on = true;
> > -   else
> > -   hba->dev_info.keep_vcc_on = false;
> > -   } else {
> > -   hba->dev_info.keep_vcc_on = false;
> > +   keep_curr_dev_pwr_mode = hba->auto_bkops_enabled ||
> > +   ufshcd_wb_keep_vcc_on(hba);
> Should the device be in UFS_ACTIVE_PWR_MODE to perform auto-bkops?
> 
> Also, is it needed to keep the device in UFS_ACTIVE_PWR_MODE , if flush 
> on hibern8 is enabled and the link is being put to hibern8 mode during 
> runtime-suspend? Perhaps that should also be factored in here?

Both auto-bkops and WriteBooster flush during Hibern8 need device power
mode to be "Active Power Mode".

For auto-bkops, the spec mentions,

"If the background operations enable bit is set and the device is in
Active power mode or Idle power mode, then the device is allowed to
execute any internal operations."

For WriteBooster flush during Hibern8, the spec mentions,

"While the flushing operation is in progress, the device is in Active
power mode."

Therefore here we can use an unified "keep_curr_dev_pwr_mode" to
indicate the same requirements of above both features.

Besides, both operations may access flash array inside UFS device thus
VCC supply shall be also kept.

Before this patch, the original code will keep device power mode (stay
in Active Power Mode) if hba->auto_bkops_enabled is set as true during
runtime-suspend with UFSHCD_CAP_AUTO_BKOPS_SUSPEND capability is
enabled. This patch will not change this decision, just add
"WriteBooster flush during Hibern8" feature as another condition to do
so.

Thank you so much to remind me that "Link shall be put 

  1   2   3   4   5   6   7   8   9   10   >