date:20200914


On 07:19 Tue 15 Sep 2020, Greg KH wrote:

On Tue, Sep 15, 2020 at 10:42:19AM +0530, Bhaskar Chowdhury wrote:

This patch removed the scrollback related lines from this file : vesafb.rst

In the effect of this commit hashes : 50145474f6ef4a9c19205b173da6264a644c7489
and 973c096f6a85e5b5f2a295126ba6928d9a6afd45


When referencing git commits, please follow the documented way of doing
this:
50145474f6ef ("fbcon: remove soft scrollback code")

Can you fix this up and resend?

And you have a few too many ' ' in your subject :)



Oops! fixing ...thanks Greg :)

thanks,

greg k-h


signature.asc
Description: PGP signature

Re: [PATCH] idr: remove WARN_ON_ONCE() when trying to check id

2020-09-14 Thread Eric Biggers

On Tue, Sep 15, 2020 at 10:43:31AM +0530, Anmol Karn wrote:
> On Mon, Sep 14, 2020 at 08:26:55PM +0100, Matthew Wilcox wrote:
> > On Tue, Sep 15, 2020 at 12:17:55AM +0530, Anmol Karn wrote:
> > > On Mon, Sep 14, 2020 at 12:08:03PM +0100, Matthew Wilcox wrote:
> > > > On Mon, Sep 14, 2020 at 12:47:24PM +0530, Anmol Karn wrote:
> > > > > idr_get_next() gives WARN_ON_ONCE() when it gets (id > INT_MAX) true
> > > > > and this happens when syzbot does fuzzing, and that warning is
> > > > > expected, but WARN_ON_ONCE() is not required here and, cecking
> > > > > the condition and returning NULL value would be suffice.
> > > > > 
> > > > > Reference: commit b9959c7a347 ("filldir[64]: remove WARN_ON_ONCE() 
> > > > > for bad directory entries")
> > > > > Reported-and-tested-by: 
> > > > > syzbot+f7204dcf3df4bb4ce...@syzkaller.appspotmail.com
> > > > > Link: https://syzkaller.appspot.com/bug?extid=f7204dcf3df4bb4ce42c 
> > > > > Signed-off-by: Anmol Karn 
> > > > 
> > > > https://lore.kernel.org/netdev/20200605120037.17427-1-wi...@infradead.org/
> > > 
> > > Hello sir,
> > > 
> > > I have looked into the patch, and it seems the problem is fixed to the 
> > > root cause
> > > in this patch, but not yet merged due to some backport issues, so, please 
> > > ignore 
> > > this patch(sent by me), and please let me know if i can contribute to 
> > > fixing this 
> > > bug's root cause.
> > 
> > The root cause is that the network maintainers believe I have a far
> > greater interest in the qrtr code than I actually do, and the maintainer
> > of the qrtr code is not doing anything.
> 
> Hello sir,
> 
> I hope the patch will get merged soon.

No need to "hope"; you could split up Matthew's patch yourself, and test and
send the resulting patches.  From the above thread, it looks like the networking
developers want one patch to fix the improper use of GFP_ATOMIC (which is the
bug reported by syzbot), and a separate patch to convert qrtr to use the XArray.

> also, i have tried a patch for this bug
> 
> Link: https://syzkaller.appspot.com/bug?extid=3b14b2ed9b3d06dcaa07
> 
> can you please guide me little how should i proceede with it, and 
> also syzbot tested it.  

Looks like something timer-related.  You'll need to investigate more, write and
test a fix, and send it to the appropriate kernel mailing lists and developers
(which will probably be different from the ones receiving this current thread).

- Eric

Re: [PATCHv4 1/2] soc: qcom: llcc: Move attribute config to its own function

2020-09-14 Thread Sai Prakash Ranjan


On 2020-09-15 00:14, Stephen Boyd wrote:

Quoting Sai Prakash Ranjan (2020-09-14 04:12:59)

Cleanup qcom_llcc_cfg_program() by moving llcc attribute
configuration to a separate function of its own. Also
correct misspelled 'instance' caught by checkpatch.

Suggested-by: Stephen Boyd 
Signed-off-by: Sai Prakash Ranjan 
---
 drivers/soc/qcom/llcc-qcom.c | 75 


 1 file changed, 41 insertions(+), 34 deletions(-)

diff --git a/drivers/soc/qcom/llcc-qcom.c 
b/drivers/soc/qcom/llcc-qcom.c

index 429b5a60a1ba..60ee31842dea 100644
--- a/drivers/soc/qcom/llcc-qcom.c
+++ b/drivers/soc/qcom/llcc-qcom.c
@@ -318,14 +318,50 @@ size_t llcc_get_slice_size(struct 
llcc_slice_desc *desc)

 }
 EXPORT_SYMBOL_GPL(llcc_get_slice_size);

-static int qcom_llcc_cfg_program(struct platform_device *pdev)
+static int qcom_llcc_attr_cfg(const struct llcc_slice_config *table)


Call it config? It's certainly not a table.



Yes, will do.


 {
-   int i;
u32 attr1_cfg;
u32 attr0_cfg;
u32 attr1_val;
u32 attr0_val;
u32 max_cap_cacheline;
+   int ret;
+
+   attr1_cfg = LLCC_TRP_ATTR1_CFGn(table->slice_id);
+   attr0_cfg = LLCC_TRP_ATTR0_CFGn(table->slice_id);


Can this move down to near where it is used?



Sure.


+
+   attr1_val = table->cache_mode;
+   attr1_val |= table->probe_target_ways << 
ATTR1_PROBE_TARGET_WAYS_SHIFT;

+   attr1_val |= table->fixed_size << ATTR1_FIXED_SIZE_SHIFT;
+   attr1_val |= table->priority << ATTR1_PRIORITY_SHIFT;
+
+   max_cap_cacheline = MAX_CAP_TO_BYTES(table->max_cap);
+
+   /* LLCC instances can vary for each target.


The /* should be on a line by itself.



This was there before I moved this hunk but I will fix it.


+* The SW writes to broadcast register which gets propagated
+* to each llcc instance (llcc0,.. llccN).
+* Since the size of the memory is divided equally amongst the
+* llcc instances, we need to configure the max cap 
accordingly.

+*/
+   max_cap_cacheline = max_cap_cacheline / drv_data->num_banks;
+   max_cap_cacheline >>= CACHE_LINE_SIZE_SHIFT;
+   attr1_val |= max_cap_cacheline << ATTR1_MAX_CAP_SHIFT;
+
+   attr0_val = table->res_ways & ATTR0_RES_WAYS_MASK;
+   attr0_val |= table->bonus_ways << ATTR0_BONUS_WAYS_SHIFT;
+
+   ret = regmap_write(drv_data->bcast_regmap, attr1_cfg, 
attr1_val);

+   if (ret)
+   return ret;
+
+   ret = regmap_write(drv_data->bcast_regmap, attr0_cfg, 
attr0_val);

+
+   return ret;


return regmap_write(...)



Ok done.

Thanks,
Sai

--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
member

of Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH v2 2/4] dfl: add dfl bus support to MODULE_DEVICE_TABLE()

On Tue, Sep 15, 2020 at 12:08:38PM +0800, Wu, Hao wrote:
> > On Tue, Sep 15, 2020 at 11:27:51AM +0800, Xu Yilun wrote:
> > > Device Feature List (DFL) is a linked list of feature headers within the
> > > device MMIO space. It is used by FPGA to enumerate multiple sub features
> > > within it. Each feature can be uniquely identified by DFL type and
> > > feature id, which can be read out from feature headers.
> > >
> > > A dfl bus helps DFL framework modularize DFL device drivers for different
> > > sub features. The dfl bus matches its devices and drivers by DFL type and
> > > feature id.
> > >
> > > This patch add dfl bus support to MODULE_DEVICE_TABLE() by adding info
> > > about struct dfl_device_id in devicetable-offsets.c and add a dfl entry
> > > point in file2alias.c.
> > >
> > > Signed-off-by: Xu Yilun 
> > > Signed-off-by: Wu Hao 
> > > Signed-off-by: Matthew Gerlach 
> > > Signed-off-by: Russ Weight 
> > > Acked-by: Wu Hao 
> 
> Yilun,
> 
> I haven't acked-by this patch as it doesn't modify any dfl files, ideally you

Sorry, I misunderstood your comments "Acked-by: xxx for DFL related changes 
after
this fix".

> need acked-by from real maintainer of scripts/mod code, right?

Ideally yes. From the MAINTAINERS it is Masahiro Yamada, I added him on the "to"
list. But I see some other patches (also for devtable entries) in kernel
don't have his acked-by.

Hi Moritz:

Do you have any ideas on that?

Thanks,
Yilun.

> 
> Thanks
> Hao
> 
> > > ---
> > > v2: add comments for the format of modalias
> > > ---
> > >  scripts/mod/devicetable-offsets.c |  4 
> > >  scripts/mod/file2alias.c  | 17 +
> > >  2 files changed, 21 insertions(+)
> > >
> > > diff --git a/scripts/mod/devicetable-offsets.c b/scripts/mod/devicetable-
> > offsets.c
> > > index 27007c1..d8350ee 100644
> > > --- a/scripts/mod/devicetable-offsets.c
> > > +++ b/scripts/mod/devicetable-offsets.c
> > > @@ -243,5 +243,9 @@ int main(void)
> > >  DEVID(mhi_device_id);
> > >  DEVID_FIELD(mhi_device_id, chan);
> > >
> > > +DEVID(dfl_device_id);
> > > +DEVID_FIELD(dfl_device_id, type);
> > > +DEVID_FIELD(dfl_device_id, feature_id);
> > > +
> > >  return 0;
> > >  }
> > > diff --git a/scripts/mod/file2alias.c b/scripts/mod/file2alias.c
> > > index 2417dd1..9fd2e60 100644
> > > --- a/scripts/mod/file2alias.c
> > > +++ b/scripts/mod/file2alias.c
> > > @@ -1368,6 +1368,22 @@ static int do_mhi_entry(const char *filename,
> > void *symval, char *alias)
> > >  return 1;
> > >  }
> > >
> > > +/* Looks like: dfl:tNfN */
> > > +static int do_dfl_entry(const char *filename, void *symval, char *alias)
> > > +{
> > > +DEF_FIELD(symval, dfl_device_id, type);
> > > +DEF_FIELD(symval, dfl_device_id, feature_id);
> > > +
> > > +/*
> > > + * type contains 4 valid bits and feature_id contains 12 valid bits
> > > + * according to DFL specification.
> > > + */
> > > +sprintf(alias, "dfl:t%01Xf%03X", type, feature_id);
> > > +
> > > +add_wildcard(alias);
> > > +return 1;
> > > +}
> > > +
> > >  /* Does namelen bytes of name exactly match the symbol? */
> > >  static bool sym_is(const char *name, unsigned namelen, const char
> > *symbol)
> > >  {
> > > @@ -1442,6 +1458,7 @@ static const struct devtable devtable[] = {
> > >  {"tee", SIZE_tee_client_device_id, do_tee_entry},
> > >  {"wmi", SIZE_wmi_device_id, do_wmi_entry},
> > >  {"mhi", SIZE_mhi_device_id, do_mhi_entry},
> > > +{"dfl", SIZE_dfl_device_id, do_dfl_entry},
> > >  };
> > >
> > >  /* Create MODULE_ALIAS() statements.
> > > --
> > > 2.7.4
> > >
> > Applied to for-next,
> >
> > Thanks

Re: [PATCHv4 2/2] soc: qcom: llcc: Support chipsets that can write to llcc regs

2020-09-14 Thread Sai Prakash Ranjan


On 2020-09-15 00:16, Stephen Boyd wrote:

Quoting Sai Prakash Ranjan (2020-09-14 04:13:00)

From: "Isaac J. Manjarres" 

Older chipsets may not be allowed to configure certain LLCC registers
as that is handled by the secure side software. However, this is not
the case for newer chipsets and they must configure these registers
according to the contents of the SCT table, while keeping in mind that
older targets may not have these capabilities. So add support to allow
such configuration of registers to enable capacity based allocation
and power collapse retention for capable chipsets.

Reason for choosing capacity based allocation rather than the default
way based allocation is because capacity based allocation allows more
finer grain partition and provides more flexibility in configuration.
As for the retention through power collapse, it has an advantage where
the cache hits are more when we wake up from power collapse although
it does burn more power but the exact power numbers are not known at
the moment.

Signed-off-by: Isaac J. Manjarres 
Reviewed-by: Douglas Anderson 
(saiprakash.ran...@codeaurora.org: use existing config and reword 
commit msg)


Should be [ not (



Ok


Signed-off-by: Sai Prakash Ranjan 
---
 drivers/soc/qcom/llcc-qcom.c | 27 +--
 1 file changed, 25 insertions(+), 2 deletions(-)

diff --git a/drivers/soc/qcom/llcc-qcom.c 
b/drivers/soc/qcom/llcc-qcom.c

index 60ee31842dea..6aedccff49bb 100644
--- a/drivers/soc/qcom/llcc-qcom.c
+++ b/drivers/soc/qcom/llcc-qcom.c
@@ -375,6 +382,22 @@ static int qcom_llcc_cfg_program(struct 
platform_device *pdev)

if (ret)
return ret;

+   if (cfg->need_llcc_cfg) {
+   u32 disable_cap_alloc, retain_pc;
+
+   disable_cap_alloc = 
llcc_table[i].dis_cap_alloc << llcc_table[i].slice_id;

+   ret = regmap_write(drv_data->bcast_regmap,
+   LLCC_TRP_SCID_DIS_CAP_ALLOC, 
disable_cap_alloc);

+   if (ret)
+   return ret;
+
+   retain_pc = llcc_table[i].retain_on_pc << 
llcc_table[i].slice_id;

+   ret = regmap_write(drv_data->bcast_regmap,
+   LLCC_TRP_PCB_ACT, retain_pc);
+   if (ret)
+   return ret;
+   }
+
if (llcc_table[i].activate_on_init) {
desc.slice_id = llcc_table[i].slice_id;
ret = llcc_slice_activate();


I thought all of this stuff would move into the config function. So the
for loop is simplified to a function call and return if failure.


The config function was specifically for attribute config
not for other llcc configs like these, so I will rename
qcom_llcc_attr_cfg() to _qcom_llcc_cfg_program() and move
everything there.

As a side note, I have your mails in my inbox but these
messages are not appearing in the list [1]. For Patch 2,
its on the list [2]. I have noticed same thing on your
messages for previous patches, where your reply for one
patch was on the list but the other one was missing, you
might have to check that.

[1] https://lore.kernel.org/patchwork/patch/1305132/
[2] https://lore.kernel.org/patchwork/patch/1305133/

Same with lore.kernel.org/lkml/ links but since url was big, I gave the
above patchwork links.

Thanks,
Sai

--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
member

of Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH] docs : fb : vesafb.rst : Removed scrollback related lines

2020-09-14 Thread Greg KH

On Tue, Sep 15, 2020 at 10:42:19AM +0530, Bhaskar Chowdhury wrote:
> This patch removed the scrollback related lines from this file : vesafb.rst
> 
> In the effect of this commit hashes : 50145474f6ef4a9c19205b173da6264a644c7489
> and 973c096f6a85e5b5f2a295126ba6928d9a6afd45

When referencing git commits, please follow the documented way of doing
this:
50145474f6ef ("fbcon: remove soft scrollback code")

Can you fix this up and resend?

And you have a few too many ' ' in your subject :)

thanks,

greg k-h

Re: 回复: RCU: Question on force_qs_rnp

2020-09-14 Thread Zhang,Qiang





On 9/15/20 11:41 AM, Paul E. McKenney wrote:

On Tue, Sep 15, 2020 at 03:18:23AM +, Zhang, Qiang wrote:




发件人: Paul E. McKenney 
发送时间: 2020年9月15日 4:56
收件人: Joel Fernandes
抄送: Zhang, Qiang; Uladzislau Rezki; j...@joshtriplett.org; rost...@goodmis.org; 
mathieu.desnoy...@efficios.com; Lai Jiangshan; r...@vger.kernel.org; LKML
主题: Re: RCU: Question on force_qs_rnp

On Mon, Sep 14, 2020 at 03:42:08PM -0400, Joel Fernandes wrote:

On Mon, Sep 14, 2020 at 07:55:18AM +, Zhang, Qiang wrote:

Hello Paul

I have some questions for you .
in force_qs_rnp func ,  if  "f(rdp)" func return true we will call 
rcu_report_qs_rnp func
report a quiescent state for this rnp node, and clear grpmask form rnp->qsmask.
after that ,  can we make a check for this rnp->qsmask,  if  rnp->qsmask == 0,
we will check blocked readers in this rnp node,  instead of jumping directly to 
the next node .


Could you clarify what good is this going to do? What problem are you trying to
address?

You could have a task that is blocked in an RCU leaf node, but the
force_qs_rnp() decided to call rcu_report_qs_rnp(). This is perfectly Ok. The
CPU could be dyntick-idle and a quiescent state is reported. However, the GP
must not end and the rcu leaf node should still be present in its parent
intermediate nodes ->qsmask. In this case, the ->qsmask == 0 does not have
any relevance.

Or am I missing the point of the question?



Hello, Qiang,



Another way of making Joel's point is to say that the additional check
you are asking for is already being done, but by rcu_report_qs_rnp().



Thanx, Paul


Hello Pual,  Joel

What I want to express is as follows :

diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 7623128d0020..beb554539f01 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -2622,6 +2622,11 @@ static void force_qs_rnp(int (*f)(struct rcu_data *rdp))
 if (mask != 0) {
 /* Idle/offline CPUs, report (releases rnp->lock). */
 rcu_report_qs_rnp(mask, rnp, rnp->gp_seq, flags);
+   raw_spin_lock_irqsave_rcu_node(rnp, flags);
+   if (rnp->qsmask == 0 && 
rcu_preempt_blocked_readers_cgp(rnp))
+   rcu_initiate_boost(rnp, flags);
+   else
+   raw_spin_unlock_irqrestore_rcu_node(rnp, flags);
 } else {
 /* Nothing to do here, so just drop the lock. */
 raw_spin_unlock_irqrestore_rcu_node(rnp, flags);


But in that case, why duplicate the code from rcu_initiate_boost()?

Thanx, Paul



Hello Paul

When we force a qs for rnp, we first check the leaf node "rnp->qsmask" 
if it is reached zero, will check if there are some blocked readers in 
this leaf rnp node, if so we need to priority-boost blocked readers.
if not we will check cpu dyntick-idle and report leaf node qs, after 
this leaf rnp node report qs, there is may be some blocked readers in 
this node, should we also need to priority-boost blocked readers?


Thanks

Qiang

Re: [PATCHSET v2 00/11] perf tools: Fix various memory leaks

2020-09-14 Thread Ian Rogers

On Mon, Sep 14, 2020 at 8:18 PM Namhyung Kim  wrote:
>
> Hello,
>
> I've found and fixed a bunch of memory leaks during perf pmu and
> metric tests with address sanitizer.  Before this, the tests were
> mostly failed due to the leaks since ASAN makes it return non-zero.
>
> Now I'm seeing no error with ASAN like below:
>
>   $ ./perf test pmu metric
>9: Parse perf pmu format : Ok
>   10: PMU events:
>   10.1: PMU event table sanity  : Ok
>   10.2: PMU event map aliases   : Ok
>   10.3: Parsing of PMU event table metrics  : Skip (some 
> metrics failed)
>   10.4: Parsing of PMU event table metrics with fake PMUs   : Ok
>   67: Parse and process metrics : Ok
>
> The failure in 10.3 seems due to parse errors like below:
>
>   Multiple errors dropping message: unknown term 'filter_opc' for pmu 
> 'uncore_cbox_0'
>   (valid terms: 
> event,edge,inv,umask,cmask,config,config1,config2,name,period,freq,
> 
> branch_type,time,call-graph,stack-size,no-inherit,inherit,max-stack,
> 
> nr,no-overwrite,overwrite,driver-config,percore,aux-output,aux-sample-size)
>
>
>   Parse event failed metric 'DRAM_Parallel_Reads' id 
> 'arb/event=0x80,umask=0x2,thresh=1/'
> expr 'arb@event\=0x80\,umask\=0x2@ / 
> arb@event\=0x80\,umask\=0x2\,thresh\=1@'
>   Error string 'unknown term 'thresh' for pmu 'uncore_arb'' help
> 'valid terms: 
> event,edge,inv,umask,cmask,config,config1,config2,name,period,freq,
>   
> branch_type,time,call-graph,stack-size,no-inherit,inherit,max-stack,
>   
> nr,no-overwrite,overwrite,driver-config,percore,aux-output,aux-sample-size'

The 10.3 failure seems to be a problem in the skl metric DRAM_Parallel_Reads:
https://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git/tree/tools/perf/pmu-events/arch/x86/skylake/skl-metrics.json?h=perf/core#n319
arb@event\\=0x80\\,umask\\=0x2@ / arb@event\\=0x80\\,umask\\=0x2\\,thresh\\=1@

The test failure message is:
Parse event failed metric 'DRAM_Parallel_Reads' id
'arb/event=0x80,umask=0x2,thresh=1/' expr
'arb@event\=0x80\,umask\=0x2@ /
arb@event\=0x80\,umask\=0x2\,thresh\=1@'
Error string 'unknown term 'thresh' for pmu 'uncore_arb'' help 'valid
terms: 
event,edge,inv,umask,cmask,config,config1,config2,name,period,freq,branch_type,time,call-graph,stack-size,no-inherit,inherit,max-stack,nr,no-overwrite,overwrite,driver-config,percore,aux-output,aux-sample-size'

The 01.org version of this from:
https://download.01.org/perfmon/TMA_Metrics.xlsx
is:
UNC_ARB_TRK_OCCUPANCY.DATA_READ / UNC_ARB_TRK_OCCUPANCY.DATA_READ:c1

It seems that :c1 has been translated into thresh=1 but that thresh
doesn't exist as a format option (just "cmask edge event inv umask"
are present). I wonder if Andi or Jin you could look into this broken
metric?

Thanks,
Ian

> * Changes from v1:
>  - Add 'Acked-by: Jiri'
>
>
> The patches are also available at 'perf/metric-fix-v2' branch on
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/namhyung/linux-perf.git
>
> Thanks
> Namhyung
>
>
> Namhyung Kim (11):
>   perf metric: Fix some memory leaks
>   perf metric: Fix some memory leaks - part 2
>   perf evlist: Fix cpu/thread map leak
>   perf parse-event: Fix cpu map leaks
>   perf parse-event: Fix memory leak in evsel->unit
>   perf test: Fix memory leaks in parse-metric test
>   perf metric: Release expr_parse_ctx after testing
>   perf metric: Free metric when it failed to resolve
>   perf metric: Do not free metric when failed to resolve
>   perf test: Free aliases for PMU event map aliases test
>   perf test: Free formats for perf pmu parse test
>
>  tools/perf/tests/parse-metric.c | 14 -
>  tools/perf/tests/pmu-events.c   |  5 +
>  tools/perf/tests/pmu.c  |  1 +
>  tools/perf/util/evlist.c| 11 ---
>  tools/perf/util/metricgroup.c   | 35 +++--
>  tools/perf/util/parse-events.c  |  9 +++--
>  tools/perf/util/pmu.c   | 13 +++-
>  tools/perf/util/pmu.h   |  2 ++
>  tools/perf/util/stat-shadow.c   |  8 +---
>  9 files changed, 74 insertions(+), 24 deletions(-)
>
> --
> 2.28.0.618.gf4bc123cb7-goog
>

[PATCH] docs : fb : vesafb.rst : Removed scrollback related lines

This patch removed the scrollback related lines from this file : vesafb.rst

In the effect of this commit hashes : 50145474f6ef4a9c19205b173da6264a644c7489
and 973c096f6a85e5b5f2a295126ba6928d9a6afd45
 

Signed-off-by: Bhaskar Chowdhury 
---
 Documentation/fb/vesafb.rst | 2 --
 1 file changed, 2 deletions(-)

diff --git a/Documentation/fb/vesafb.rst b/Documentation/fb/vesafb.rst
index 6821c87b7893..f890a4f5623b 100644
--- a/Documentation/fb/vesafb.rst
+++ b/Documentation/fb/vesafb.rst
@@ -135,8 +135,6 @@ ypan  enable display panning using the VESA 
protected mode
 
 * scrolling (fullscreen) is fast, because there is
  no need to copy around data.
-   * You'll get scrollback (the Shift-PgUp thing),
- the video memory can be used as scrollback buffer
 
   kontra:
 
-- 
2.26.2

Re: [Linux-kernel-mentees] [PATCH] idr: remove WARN_ON_ONCE() when trying to check id

2020-09-14 Thread Anmol Karn

On Mon, Sep 14, 2020 at 08:26:55PM +0100, Matthew Wilcox wrote:
> On Tue, Sep 15, 2020 at 12:17:55AM +0530, Anmol Karn wrote:
> > On Mon, Sep 14, 2020 at 12:08:03PM +0100, Matthew Wilcox wrote:
> > > On Mon, Sep 14, 2020 at 12:47:24PM +0530, Anmol Karn wrote:
> > > > idr_get_next() gives WARN_ON_ONCE() when it gets (id > INT_MAX) true
> > > > and this happens when syzbot does fuzzing, and that warning is
> > > > expected, but WARN_ON_ONCE() is not required here and, cecking
> > > > the condition and returning NULL value would be suffice.
> > > > 
> > > > Reference: commit b9959c7a347 ("filldir[64]: remove WARN_ON_ONCE() for 
> > > > bad directory entries")
> > > > Reported-and-tested-by: 
> > > > syzbot+f7204dcf3df4bb4ce...@syzkaller.appspotmail.com
> > > > Link: https://syzkaller.appspot.com/bug?extid=f7204dcf3df4bb4ce42c 
> > > > Signed-off-by: Anmol Karn 
> > > 
> > > https://lore.kernel.org/netdev/20200605120037.17427-1-wi...@infradead.org/
> > 
> > Hello sir,
> > 
> > I have looked into the patch, and it seems the problem is fixed to the root 
> > cause
> > in this patch, but not yet merged due to some backport issues, so, please 
> > ignore 
> > this patch(sent by me), and please let me know if i can contribute to 
> > fixing this 
> > bug's root cause.
> 
> The root cause is that the network maintainers believe I have a far
> greater interest in the qrtr code than I actually do, and the maintainer
> of the qrtr code is not doing anything.

Hello sir,

I hope the patch will get merged soon.

also, i have tried a patch for this bug

Link: https://syzkaller.appspot.com/bug?extid=3b14b2ed9b3d06dcaa07

can you please guide me little how should i proceede with it, and 
also syzbot tested it.  


Thanks,
Anmol

Re: [PATCH] trace: Fix race in trace_open and buffer resize call

2020-09-14 Thread Gaurav Kohli





Hi Steven,
thanks for reply.

On 9/14/2020 9:49 PM, Steven Rostedt wrote:
> On Mon, 14 Sep 2020 10:00:50 +0530
> Gaurav Kohli  wrote:
>
>> Hi Steven,
>>
>> Please let us know, if below change looks good.
>> Or let us know some other way to solve this.
>>
>> Thanks,
>> Gaurav
>>
>>
>
> Hmm, for some reason, I don't see this in my INBOX, but it shows up in my
> LKML folder. :-/
>
>


>>> +void ring_buffer_mutex_release(struct trace_buffer *buffer)
>>> +{
>>> +mutex_unlock(>mutex);
>>> +}
>>> +EXPORT_SYMBOL_GPL(ring_buffer_mutex_release);
>
> I really do not like to export these.
>

Actually available reader lock is not helping 
here(_buffer->reader_lock), So i took ring buffer mutex lock to 
resolve this(this came on 4.19/5.4), in latest tip it is trace buffer 
lock. Due to this i have exported api.

>>> +/**
>>> * ring_buffer_record_off - stop all writes into the buffer
>>> * @buffer: The ring buffer to stop writes to.
>>> *
>>> @@ -4918,6 +4937,8 @@ void ring_buffer_reset(struct trace_buffer 
*buffer)

>>>struct ring_buffer_per_cpu *cpu_buffer;
>>>int cpu;
>>>+/* prevent another thread from changing buffer sizes */
>>> +mutex_lock(>mutex);
>>>for_each_buffer_cpu(buffer, cpu) {
>>>cpu_buffer = buffer->buffers[cpu];
>>>@@ -4936,6 +4957,7 @@ void ring_buffer_reset(struct trace_buffer 
*buffer)

>>>atomic_dec(_buffer->record_disabled);
>>>atomic_dec(_buffer->resize_disabled);
>>>}
>>> +mutex_unlock(>mutex);
>>>}
>>>EXPORT_SYMBOL_GPL(ring_buffer_reset);
>>>diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
>>> index f40d850..392e9aa 100644
>>> --- a/kernel/trace/trace.c
>>> +++ b/kernel/trace/trace.c
>>> @@ -2006,6 +2006,8 @@ void tracing_reset_online_cpus(struct 
array_buffer *buf)

>>>if (!buffer)
>>>return;
>>>+ring_buffer_mutex_acquire(buffer);
>>> +
>>>ring_buffer_record_disable(buffer);
>
> Hmm, why do we disable here as it gets disabled again in the call to
> ring_buffer_reset_online_cpus()? Perhaps we don't need to disable the
You mean cpu_buffer->reader_lock in reset_disabled_cpu_buffer?
Actually reader lock is already there but this is not helping if 
tracing_open and ring_buffer_resize are running parallel on different cpus.


We are seeing below race mainly during removal of extra pages:

ring_buffer_resize
   //Below portion of code
   //not under any lock
nr_pages_to_update < 0
   init_list_head(new_pages)
   rb_update_pages


ring_buffer_resize
tracing_open
tracing_reset_online_cpus
ring_buffer_reset_cpu
  cpu_buffer_reset done
  //now lock started

  warning(nr_removed)

We are seeing cases like cpu buffer got reset due to tracing open in 
other call, and then seeing issue in  rb_remove_pages.


Similar case can come during rb_insert_pages as well:

rb_insert_pages(struct ring_buffer_per_cpu *cpu_buffer)
{
struct list_head *pages = _buffer->new_pages;
int retries, success;
//before lock cpu buffer may get reset in another cpu, due to which we 
are seeing infinite loop cases as new_pages pointer got reset in 
rb_reset_cpu.


raw_spin_lock_irq(_buffer->reader_lock);

> buffer here. The only difference is that we have:
>
>   buf->time_start = buffer_ftrace_now(buf, buf->cpu);
>
> And that the above disables the entire buffer, whereas the reset only
> resets individual ones.
>
> But I don't think that will make any difference.
>
> -- Steve
>


--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center,
Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.

Re: [PATCH net-next 6/6] net: hns3: use napi_consume_skb() when cleaning tx desc

2020-09-14 Thread Saeed Mahameed

On Mon, 2020-09-14 at 20:06 +0800, Huazhong Tan wrote:
> From: Yunsheng Lin 
> 
> Use napi_consume_skb() to batch consuming skb when cleaning
> tx desc in NAPI polling.
> 
> Signed-off-by: Yunsheng Lin 
> Signed-off-by: Huazhong Tan 
> ---
>  drivers/net/ethernet/hisilicon/hns3/hns3_enet.c| 27 +++-
> --
>  drivers/net/ethernet/hisilicon/hns3/hns3_enet.h|  2 +-
>  drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c |  4 ++--
>  3 files changed, 17 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
> b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
> index 4a49a76..feeaf75 100644
> --- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
> +++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
> @@ -2333,10 +2333,10 @@ static int hns3_alloc_buffer(struct
> hns3_enet_ring *ring,
>  }
>  
>  static void hns3_free_buffer(struct hns3_enet_ring *ring,
> -  struct hns3_desc_cb *cb)
> +  struct hns3_desc_cb *cb, int budget)
>  {
>   if (cb->type == DESC_TYPE_SKB)
> - dev_kfree_skb_any((struct sk_buff *)cb->priv);
> + napi_consume_skb(cb->priv, budget);

This code can be reached from hns3_lb_clear_tx_ring() below which is
your loopback test and called with non-zero budget, I am not sure you
are allowed to call napi_consume_skb() with non-zero budget outside
napi context, perhaps the cb->type for loopback test is different in lb
test case ? Idk.. , please double check other code paths.

[...]

>  static void hns3_lb_clear_tx_ring(struct hns3_nic_priv *priv, u32
> start_ringid,
> -   u32 end_ringid, u32 budget)
> +   u32 end_ringid, int budget)
>  {
>   u32 i;
>  
>   for (i = start_ringid; i <= end_ringid; i++) {
>   struct hns3_enet_ring *ring = >ring[i];
>  
> - hns3_clean_tx_ring(ring);
> + hns3_clean_tx_ring(ring, budget);
>   }
>  }
>

Re: [[PATCH]] mm: khugepaged: recalculate min_free_kbytes after memory hotplug as expected by khugepaged

2020-09-14 Thread Vijay Balakrishna





On 9/10/2020 3:01 PM, Kirill A. Shutemov wrote:

On Thu, Sep 10, 2020 at 01:47:39PM -0700, Vijay Balakrishna wrote:

When memory is hotplug added or removed the min_free_kbytes must be
recalculated based on what is expected by khugepaged.  Currently
after hotplug, min_free_kbytes will be set to a lower default and higher
default set when THP enabled is lost. This leaves the system with small
min_free_kbytes which isn't suitable for systems especially with network
intensive loads.  Typical failure symptoms include HW WATCHDOG reset,
soft lockup hang notices, NETDEVICE WATCHDOG timeouts, and OOM process
kills.

Fixes: f000565adb77 ("thp: set recommended min free kbytes")

Signed-off-by: Vijay Balakrishna 
Cc: sta...@vger.kernel.org


NAK. It would override min_free_kbytes set by user.


Hi Kirill,

To fix the issue you raised I just submitted
https://lore.kernel.org/lkml/1600145748-26518-1-git-send-email-vij...@linux.microsoft.com/

Thanks,
Vijay

Re: [PATCH 2/2] USB: misc: Add onboard_usb_hub driver

2020-09-14 Thread Matthias Kaehlcke

Hi Peter,

thanks for your comments!

On Tue, Sep 15, 2020 at 02:55:06AM +, Peter Chen wrote:
> On 20-09-14 11:27:49, Matthias Kaehlcke wrote:
> > The main issue this driver addresses is that a USB hub needs to be
> > powered before it can be discovered. For onboard hubs this is often
> > solved by supplying the hub with an 'always-on' regulator, which is
> > kind of a hack. Some onboard hubs may require further initialization
> > steps, like changing the state of a GPIO or enabling a clock, which
> > requires further hacks. This driver creates a platform device
> > representing the hub which performs the necessary initialization.
> > Currently it only supports switching on a single regulator, support
> > for multiple regulators or other actions can be added as needed.
> > Different initialization sequences can be supported based on the
> > compatible string.
> > 
> > Besides performing the initialization the driver can be configured
> > to power the hub off during system suspend. This can help to extend
> > battery life on battery powered devices, which have no requirements
> > to keep the hub powered during suspend. The driver can also be
> > configured to leave the hub powered when a wakeup capable USB device
> > is connected when suspending, and keeping it powered otherwise.
> > 
> > Technically the driver consists of two drivers, the platform driver
> > described above and a very thin USB driver that subclasses the
> > generic hub driver. The purpose of this driver is to provide the
> > platform driver with the USB devices corresponding to the hub(s)
> > (a hub controller may provide multiple 'logical' hubs, e.g. one
> > to support USB 2.0 and another for USB 3.x).
> 
> I agree with Alan, you may change this driver to apply for generic
> onboard USB devices.

I interpreted that Alan only corrected my terminology and didn't
suggest to extend the driver to generic onboard devices. Actually I
like that we now have a abstraction for a specific physical 'device',
rather than the initial usb_hub_pwr/usb_hub_psupply split, which seemed
a bit contrived (thanks Doug!).

> > +static int onboard_hub_probe(struct platform_device *pdev)
> > +{
> > +   struct device *dev = >dev;
> > +   struct onboard_hub *hub;
> > +
> > +   hub = devm_kzalloc(dev, sizeof(*hub), GFP_KERNEL);
> > +   if (!hub)
> > +   return -ENOMEM;
> > +
> > +   hub->vdd = devm_regulator_get(dev, "vdd");
> > +   if (IS_ERR(hub->vdd))
> > +   return PTR_ERR(hub->vdd);
> > +
> > +   hub->dev = dev;
> > +   mutex_init(>lock);
> > +   INIT_LIST_HEAD(>udev_list);
> > +
> > +   hub->cfg.power_off_in_suspend = of_property_read_bool(dev->of_node, 
> > "power-off-in-suspend");
> > +   hub->cfg.wakeup_source = of_property_read_bool(dev->of_node, 
> > "wakeup-source");
> 
> Do you really need these two properties? If the device (and its children
> if existed) has wakeup enabled, you keep power in suspend, otherwise,
> you could close it, any exceptions?

That would work for my use case, but I'm not sure it's a universally
good configuration.

I don't have a specific USB device in mind, but you could have a device
that shouldn't lose it's context during suspend or keep operating
autonomously (e.g. a sensor with a large buffer collecting samples). Not
sure if something like this exists in the real though.

I'm not an expert, but it seems there are USB controllers with wakeup
support which is always enabled. A board with such a controller then
couldn't have a policy to power down the hub regardless of wakeup
capable devices being connected.

Thanks

Matthias

INFO: task hung in vfs_setxattr (3)

2020-09-14 Thread syzbot

Hello,

syzbot found the following issue on:

HEAD commit:7fe10096 Merge branch 'linus' of git://git.kernel.org/pub/..
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=140b085390
kernel config:  https://syzkaller.appspot.com/x/.config?x=a9075b36a6ae26c9
dashboard link: https://syzkaller.appspot.com/bug?extid=738cca7d7d9754493513
compiler:   gcc (GCC) 10.1.0-syz 20200507
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=108d45a590

The issue was bisected to:

commit 6a3c7f5c87854e948c3c234e5f5e745c7c553722
Author: Nikolay Borisov 
Date:   Thu May 28 08:05:13 2020 +

btrfs: don't balance btree inode pages from buffered write path

bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=14884d2190
final oops: https://syzkaller.appspot.com/x/report.txt?x=16884d2190
console output: https://syzkaller.appspot.com/x/log.txt?x=12884d2190

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+738cca7d7d9754493...@syzkaller.appspotmail.com
Fixes: 6a3c7f5c8785 ("btrfs: don't balance btree inode pages from buffered 
write path")

INFO: task syz-executor.2:9042 blocked for more than 143 seconds.
  Not tainted 5.9.0-rc4-syzkaller #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:syz-executor.2  state:D stack:29136 pid: 9042 ppid:  6892 flags:0x
Call Trace:
 context_switch kernel/sched/core.c:3778 [inline]
 __schedule+0xea9/0x2230 kernel/sched/core.c:4527
 schedule+0xd0/0x2a0 kernel/sched/core.c:4602
 rwsem_down_write_slowpath+0x603/0xc60 kernel/locking/rwsem.c:1235
 __down_write kernel/locking/rwsem.c:1389 [inline]
 down_write+0x137/0x150 kernel/locking/rwsem.c:1532
 inode_lock include/linux/fs.h:779 [inline]
 vfs_setxattr+0xc7/0x270 fs/xattr.c:282
 setxattr+0x23d/0x330 fs/xattr.c:548
 path_setxattr+0x170/0x190 fs/xattr.c:567
 __do_sys_setxattr fs/xattr.c:582 [inline]
 __se_sys_setxattr fs/xattr.c:578 [inline]
 __x64_sys_setxattr+0xc0/0x160 fs/xattr.c:578
 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
 entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x45d5b9
Code: Bad RIP value.
RSP: 002b:7f37140efc78 EFLAGS: 0246 ORIG_RAX: 00bc
RAX: ffda RBX: 000324c0 RCX: 0045d5b9
RDX:  RSI: 2100 RDI: 20c0
RBP: 0118d0d0 R08:  R09: 
R10:  R11: 0246 R12: 0118d08c
R13: 7ffda389b2af R14: 7f37140f09c0 R15: 0118d08c

Showing all locks held in the system:
1 lock held by khungtaskd/1170:
 #0: 89bd6a40 (rcu_read_lock){}-{1:2}, at: 
debug_show_all_locks+0x53/0x260 kernel/locking/lockdep.c:5829
1 lock held by in:imklog/6526:
 #0: 88809a802630 (>f_pos_lock){+.+.}-{3:3}, at: __fdget_pos+0xe9/0x100 
fs/file.c:930
1 lock held by syz-executor.2/6892:
 #0: 8880ae735e18 (>lock){-.-.}-{2:2}, at: rq_lock 
kernel/sched/sched.h:1292 [inline]
 #0: 8880ae735e18 (>lock){-.-.}-{2:2}, at: __schedule+0x270/0x2230 
kernel/sched/core.c:4445
2 locks held by syz-executor.3/8619:
 #0: 88809d79a450 (sb_writers#16){.+.+}-{0:0}, at: sb_start_write 
include/linux/fs.h:1643 [inline]
 #0: 88809d79a450 (sb_writers#16){.+.+}-{0:0}, at: mnt_want_write+0x3a/0xb0 
fs/namespace.c:354
 #1: 888088e4b2d0 (>s_type->i_mutex_key#21){+.+.}-{3:3}, at: inode_lock 
include/linux/fs.h:779 [inline]
 #1: 888088e4b2d0 (>s_type->i_mutex_key#21){+.+.}-{3:3}, at: 
vfs_setxattr+0xc7/0x270 fs/xattr.c:282
2 locks held by syz-executor.2/9017:
 #0: 88808fbaa450 (sb_writers#16){.+.+}-{0:0}, at: sb_start_write 
include/linux/fs.h:1643 [inline]
 #0: 88808fbaa450 (sb_writers#16){.+.+}-{0:0}, at: mnt_want_write+0x3a/0xb0 
fs/namespace.c:354
 #1: 888078d40790 (>s_type->i_mutex_key#21){+.+.}-{3:3}, at: inode_lock 
include/linux/fs.h:779 [inline]
 #1: 888078d40790 (>s_type->i_mutex_key#21){+.+.}-{3:3}, at: 
vfs_setxattr+0xc7/0x270 fs/xattr.c:282
2 locks held by syz-executor.2/9042:
 #0: 88808fbaa450 (sb_writers#16){.+.+}-{0:0}, at: sb_start_write 
include/linux/fs.h:1643 [inline]
 #0: 88808fbaa450 (sb_writers#16){.+.+}-{0:0}, at: mnt_want_write+0x3a/0xb0 
fs/namespace.c:354
 #1: 888078d40790 (>s_type->i_mutex_key#21){+.+.}-{3:3}, at: inode_lock 
include/linux/fs.h:779 [inline]
 #1: 888078d40790 (>s_type->i_mutex_key#21){+.+.}-{3:3}, at: 
vfs_setxattr+0xc7/0x270 fs/xattr.c:282
2 locks held by syz-executor.0/9486:
 #0: 888076092450 (sb_writers#16){.+.+}-{0:0}, at: sb_start_write 
include/linux/fs.h:1643 [inline]
 #0: 888076092450 (sb_writers#16){.+.+}-{0:0}, at: mnt_want_write+0x3a/0xb0 
fs/namespace.c:354
 #1: 888078d2b450 (>s_type->i_mutex_key#21){+.+.}-{3:3}, at: inode_lock 
include/linux/fs.h:779 [inline]
 #1: 888078d2b450 (>s_type->i_mutex_key#21){+.+.}-{3:3}, at: 
vfs_setxattr+0xc7/0x270 fs/xattr.c:282
2 locks held by syz-executor.3/9622:
 #0: 88809e782450

[v1] mm: khugepaged: avoid overriding min_free_kbytes set by user

2020-09-14 Thread Vijay Balakrishna

set_recommended_min_free_kbytes need to honor min_free_kbytes set by the
user.  Post start-of-day THP enable or memory hotplug operations can
lose user specified min_free_kbytes, in particular when it is higher than
calculated recommended value.

Signed-off-by: Vijay Balakrishna 
Cc: sta...@vger.kernel.org
---
 mm/khugepaged.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/mm/khugepaged.c b/mm/khugepaged.c
index 4f7107476a6f..b4b753ba411a 100644
--- a/mm/khugepaged.c
+++ b/mm/khugepaged.c
@@ -2253,7 +2253,7 @@ static void set_recommended_min_free_kbytes(void)
 {
struct zone *zone;
int nr_zones = 0;
-   unsigned long recommended_min;
+   int recommended_min;
 
for_each_populated_zone(zone) {
/*
@@ -2280,12 +2280,12 @@ static void set_recommended_min_free_kbytes(void)
 
/* don't ever allow to reserve more than 5% of the lowmem */
recommended_min = min(recommended_min,
- (unsigned long) nr_free_buffer_pages() / 20);
+ (int) nr_free_buffer_pages() / 20);
recommended_min <<= (PAGE_SHIFT-10);
 
-   if (recommended_min > min_free_kbytes) {
+   if (recommended_min > user_min_free_kbytes) {
if (user_min_free_kbytes >= 0)
-   pr_info("raising min_free_kbytes from %d to %lu to help 
transparent hugepage allocations\n",
+   pr_info("raising min_free_kbytes from %d to %d to help 
transparent hugepage allocations\n",
min_free_kbytes, recommended_min);
 
min_free_kbytes = recommended_min;
-- 
2.28.0

[PATCH] docs : fb: sstfb.rst : Remove the scrollback related stanza

This patch remove the stanza related to framebuffer scrollback effect.

It is the the effect of commit hashes : 
50145474f6ef4a9c19205b173da6264a644c7489 
and 973c096f6a85e5b5f2a295126ba6928d9a6afd45


Signed-off-by: Bhaskar Chowdhury 
---
 Documentation/fb/sstfb.rst | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/Documentation/fb/sstfb.rst b/Documentation/fb/sstfb.rst
index 8e8c1b940359..42466ff49c58 100644
--- a/Documentation/fb/sstfb.rst
+++ b/Documentation/fb/sstfb.rst
@@ -185,9 +185,6 @@ Bugs
   contact me.
 - The 24/32 is not likely to work anytime soon, knowing that the
   hardware does ... unusual things in 24/32 bpp.
-- When used with another video board, current limitations of the linux
-  console subsystem can cause some troubles, specifically, you should
-  disable software scrollback, as it can oops badly ...
 
 Todo
 
-- 
2.26.2

REGRESSION: 37f4a24c2469: blk-mq: centralise related handling into blk_mq_get_driver_tag

2020-09-14 Thread Theodore Y. Ts'o

On Thu, Sep 03, 2020 at 11:55:28PM -0400, Theodore Y. Ts'o wrote:
> Worse, right now, -rc1 and -rc2 is causing random crashes in my
> gce-xfstests framework.  Sometimes it happens before we've run even a
> single xfstests; sometimes it happens after we have successfully
> completed all of the tests, and we're doing a shutdown of the VM under
> test.  Other times it happens in the middle of a test run.  Given that
> I'm seeing this at -rc1, which is before my late ext4 pull request to
> Linus, it's probably not an ext4 related bug.  But it also means that
> I'm partially blind in terms of my kernel testing at the moment.  So I
> can't even tell Linus that I've run lots of tests and I'm 100%
> confident your one-line change is 100% safe.

I was finally able to bisect it down to the commit:

37f4a24c2469: blk-mq: centralise related handling into blk_mq_get_driver_tag

(See below for [1] Bisect log.)

The previous commit allows the tests to run to completion.  With
commit 37f4a24c2469 and later all 11 test scenarios (4k blocks, 1k
blocks, ext3 compat, ext4 w/ fscrypt, nojournal mode, data=journal,
bigalloc, etc.) the VM will get stuck.

The symptom is that while running xfstests in a Google Compute Engine
(GCE) VM, the tests just hang.  There are a number of tests where this
is more likely, but it's not unique to a single test.

In most cases, there is nothing; just the test stops running until the
test framework times out after an hour (tests usually complete in
seconds or at most a few tens of minutes or so in the worst case) and
kills the VM.  In one case, I did get a report like this.  (See below
for [2] stack trace from 37f4a24c2469.)

I attempted to revert the commit in question against -rc1 and -rc4;
that result can be found at the branches manual-revert-of-blk-mq-patch
and manual-revert-of-blk-mq-patch-rc4 at https://github.com/tytso/ext4.

I don't think I got the revert quite right; with the revert, most of
the test VM's successfully complete, but 2 out of the 11 fail, with a
different stack trace.  (See below for [3] stack trace from my
attempted manual revert of 37f4a24c2469).  But it does seem to confirm
that the primary cause of the test VM hangs is caused by commit
37f4a24c2469.

Does this make any sense as to what might be going on?  I hope it does
for you, since I'm pretty confused what might be going on.

Thanks,

   - Ted

[1] Bisect log

git bisect start
# bad: [9123e3a74ec7b934a4a099e98af6a61c2f80bbf5] Linux 5.9-rc1
git bisect bad 9123e3a74ec7b934a4a099e98af6a61c2f80bbf5
# good: [bcf876870b95592b52519ed4aafcf9d95999bc9c] Linux 5.8
git bisect good bcf876870b95592b52519ed4aafcf9d95999bc9c
# bad: [8186749621ed6b8fc42644c399e8c755a2b6f630] Merge tag 
'drm-next-2020-08-06' of git://anongit.freedesktop.org/drm/drm
git bisect bad 8186749621ed6b8fc42644c399e8c755a2b6f630
# bad: [2324d50d051ec0f14a548e78554fb02513d6dcef] Merge tag 'docs-5.9' of 
git://git.lwn.net/linux
git bisect bad 2324d50d051ec0f14a548e78554fb02513d6dcef
# bad: [92c59e126b21fd212195358a0d296e787e444087] Merge tag 'arm-defconfig-5.9' 
of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc
git bisect bad 92c59e126b21fd212195358a0d296e787e444087
# bad: [cdc8fcb49905c0b67e355e027cb462ee168ffaa3] Merge tag 
'for-5.9/io_uring-20200802' of git://git.kernel.dk/linux-block
git bisect bad cdc8fcb49905c0b67e355e027cb462ee168ffaa3
# good: [ab5c60b79ab6cc50b39bbb21b2f9fb55af900b84] Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6
git bisect good ab5c60b79ab6cc50b39bbb21b2f9fb55af900b84
# bad: [d958e343bdc3de2643ce25225bed082dc222858d] block: blk-timeout: delete 
duplicated word
git bisect bad d958e343bdc3de2643ce25225bed082dc222858d
# bad: [53042f3cc411adc79811ba3cfbca5d7a42a7b806] ps3vram: stop using 
->queuedata
git bisect bad 53042f3cc411adc79811ba3cfbca5d7a42a7b806
# good: [621c1f42945e76015c3a585e7a9fe6e71665eba0] block: move struct 
block_device to blk_types.h
git bisect good 621c1f42945e76015c3a585e7a9fe6e71665eba0
# good: [36a3df5a4574d5ddf59804fcd0c4e9654c514d9a] blk-mq: put driver tag when 
this request is completed
git bisect good 36a3df5a4574d5ddf59804fcd0c4e9654c514d9a
# good: [570e9b73b0af2e5381ca5343759779b8c1ed20e3] blk-mq: move 
blk_mq_get_driver_tag into blk-mq.c
git bisect good 570e9b73b0af2e5381ca5343759779b8c1ed20e3
# bad: [b5fc1e8bedf8ad2c6381e0df6331ad5686aca425] blk-mq: remove pointless call 
of list_entry_rq() in hctx_show_busy_rq()
git bisect bad b5fc1e8bedf8ad2c6381e0df6331ad5686aca425
# bad: [37f4a24c2469a10a4c16c641671bd766e276cf9f] blk-mq: centralise related 
handling into blk_mq_get_driver_tag
git bisect bad 37f4a24c2469a10a4c16c641671bd766e276cf9f
# good: [723bf178f158abd1ce6069cb049581b3cb003aab] blk-mq: move 
blk_mq_put_driver_tag() into blk-mq.c
git bisect good 723bf178f158abd1ce6069cb049581b3cb003aab
# first bad commit: [37f4a24c2469a10a4c16c641671bd766e276cf9f] blk-mq: 
centralise related handling into

Re: [PATCH v1 1/2] scsi: dt-bindings: ufs: Add vcc-voltage-level for UFS

2020-09-14 Thread Bjorn Andersson

On Tue 01 Sep 01:00 CDT 2020, Bao D. Nguyen wrote:

> UFS's specifications supports a range of Vcc operating
> voltage levels. Add documentation for the UFS's Vcc voltage
> levels setting.
> 
> Signed-off-by: Can Guo 
> Signed-off-by: Asutosh Das 
> Signed-off-by: Bao D. Nguyen 
> ---
>  Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt 
> b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
> index 415ccdd..7257b32 100644
> --- a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
> +++ b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
> @@ -23,6 +23,8 @@ Optional properties:
>with "phys" attribute, provides phandle to UFS PHY 
> node
>  - vdd-hba-supply: phandle to UFS host controller supply regulator 
> node
>  - vcc-supply: phandle to VCC supply regulator node
> +- vcc-voltage-level : specifies voltage levels for VCC supply.
> +  Should be specified in pairs (min, max), units uV.

What exactly are these pairs representing?

Is this supposed to be 3 pairs of (min,max) for vcc, vcc and vccq2 to be
passed into a regulator_set_voltage() for each regulator?

Or are these some sort of "operating points" for the vcc-supply?

Regards,
Bjorn

>  - vccq-supply   : phandle to VCCQ supply regulator node
>  - vccq2-supply  : phandle to VCCQ2 supply regulator node
>  - vcc-supply-1p8: For embedded UFS devices, valid VCC range is 
> 1.7-1.95V
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>

RE: [PATCH v2 3/4] fpga: dfl: fix the comments of type & feature_id fields

2020-09-14 Thread Wu, Hao

> On Tue, Sep 15, 2020 at 11:27:52AM +0800, Xu Yilun wrote:
> > The description of feature_id in struct dfl_device is not accurate. In
> > DFL specification the feature_id is the 12 bits field. The description
> > in struct dfl_device_id is more clear so we make them aligned. We also
> > made the similar fix for the type field.
> >
> > Signed-off-by: Xu Yilun 

Acked-by: Wu Hao 

Thanks
Hao

> > ---
> >  drivers/fpga/dfl.h | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/fpga/dfl.h b/drivers/fpga/dfl.h
> > index 3c69596..d5e050a 100644
> > --- a/drivers/fpga/dfl.h
> > +++ b/drivers/fpga/dfl.h
> > @@ -531,8 +531,8 @@ enum dfl_id_type {
> >   *
> >   * @dev: generic device interface.
> >   * @id: id of the dfl device.
> > - * @type: type of DFL FIU of the device. See enum dfl_id_type.
> > - * @feature_id: 16 bits feature identifier local to its DFL FIU type.
> > + * @type: contains 4 bits DFL FIU type of the device. See enum dfl_id_type.
> > + * @feature_id: contains 12 bits feature identifier local to its DFL FIU 
> > type.
> >   * @mmio_res: mmio resource of this dfl device.
> >   * @irqs: list of Linux IRQ numbers of this dfl device.
> >   * @num_irqs: number of IRQs supported by this dfl device.
> > --
> > 2.7.4
> >
> 
> Applied to for-next,
> 
> Thanks

[PATCH] docs : fb : matroxfb.rst : Remove the stale information lines i.e framebuffer scrollback

This patch remove stale information lines from this file :  matroxfb.rst

In effect of the the commit hashes : 50145474f6ef4a9c19205b173da6264a644c7489  
and
973c096f6a85e5b5f2a295126ba6928d9a6afd45


Signed-off-by: Bhaskar Chowdhury 
---
 Documentation/fb/matroxfb.rst | 2 --
 1 file changed, 2 deletions(-)

diff --git a/Documentation/fb/matroxfb.rst b/Documentation/fb/matroxfb.rst
index f1859d98606e..6158c49c8571 100644
--- a/Documentation/fb/matroxfb.rst
+++ b/Documentation/fb/matroxfb.rst
@@ -317,8 +317,6 @@ Currently there are following known bugs:
  - interlaced text mode is not supported; it looks like hardware limitation,
but I'm not sure.
  - Gxx0 SGRAM/SDRAM is not autodetected.
- - If you are using more than one framebuffer device, you must boot kernel
-   with 'video=scrollback:0'.
  - maybe more...
 
 And following misfeatures:
-- 
2.26.2

Re: [PATCH v5] lib/string.c: implement stpcpy

2020-09-14 Thread Joe Perches

On Mon, 2020-09-14 at 21:22 -0700, Nathan Chancellor wrote:
> It would be nice to get this into mainline sooner rather than later so
> that it can start filtering into the stable trees. ToT LLVM builds have
> been broken for a month now.

People that build stable trees with new compilers
unsupported at the time the of the base version
release are just asking for trouble.

Re: WARNING: can't access registers at asm_sysvec_call_function_single

2020-09-14 Thread Dmitry Vyukov

On Mon, Sep 14, 2020 at 6:51 PM Josh Poimboeuf  wrote:
> > > On Tue, Sep 08 2020 at 13:16, syzbot wrote:
> > >
> > > > Hello,
> > > >
> > > > syzbot found the following issue on:
> > > >
> > > > HEAD commit:f4d51dff Linux 5.9-rc4
> > > > git tree:   upstream
> > > > console output: https://syzkaller.appspot.com/x/log.txt?x=1455d4f990
> > > > kernel config:  
> > > > https://syzkaller.appspot.com/x/.config?x=a9075b36a6ae26c9
> > > > dashboard link: 
> > > > https://syzkaller.appspot.com/bug?extid=bc9dbf05dcc151e9b972
> > > > compiler:   gcc (GCC) 10.1.0-syz 20200507
> > > >
> > > > Unfortunately, I don't have any reproducer for this issue yet.
> > > >
> > > > IMPORTANT: if you fix the issue, please add the following tag to the 
> > > > commit:
> > > > Reported-by: syzbot+bc9dbf05dcc151e9b...@syzkaller.appspotmail.com
> > > >
> > > > WARNING: can't access registers at 
> > > > asm_sysvec_call_function_single+0x12/0x20 
> > > > arch/x86/include/asm/idtentry.h:589
> > >
> > > That's the ORC unwinder complaining, but I have no idea why...
> >
> > 0cd0 :
> >  cd0: 90  nop
> >  cd1: 90  nop
> >  cd2: 90  nop
> >  cd3: 6a ff   pushq  $0x
> >  cd5: e8 b6 03 00 00  callq  1090 
> >  cda: 48 89 e7mov%rsp,%rdi
> >  cdd: e8 00 00 00 00  callq  ce2 
> > 
> >   cde: R_X86_64_PLT32 
> > sysvec_call_function_single-0x4
> >  ce2: e9 69 04 00 00  jmpq   1150 
> >  ce7: 66 0f 1f 84 00 00 00nopw   0x0(%rax,%rax,1)
> >  cee: 00 00
> >
> > This is a head scratcher.  The ORC data looks ok, at least when I build
> > it on my system.  It's expecting to find pt_regs at the top of the stack
> > after returning from sysvec_call_function_single().  But it can't
> > dereference the regs for some reason.
> >
> > So either it's a bug in ORC data or unwinder (not likely) or the stack
> > pointer got corrupted somehow (also seems unlikely)...
>
> The true bug may be revealed elsewhere on the stack... I probably need
> to start enabling ORC stack dumps like I did for FP.

Hi Josh,

Is there a config for this? We could enable it on syzbot. More
informative kernel diagnostics are always better.

[PATCH net-next v2 3/3] net: dec: tulip: de2104x: Replace kmemdup() with devm_kmempdup()

Replace an instance of kmemdup() with the devres counted version
instead.

Signed-off-by: Moritz Fischer 
---
 drivers/net/ethernet/dec/tulip/de2104x.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/dec/tulip/de2104x.c 
b/drivers/net/ethernet/dec/tulip/de2104x.c
index 698d79bc4784..a3a002c8e9ac 100644
--- a/drivers/net/ethernet/dec/tulip/de2104x.c
+++ b/drivers/net/ethernet/dec/tulip/de2104x.c
@@ -1940,7 +1940,8 @@ static void de21041_get_srom_info(struct de_private *de)
de->media[i].csr15 = t21041_csr15[i];
}
 
-   de->ee_data = kmemdup(_data[0], DE_EEPROM_SIZE, GFP_KERNEL);
+   de->ee_data = devm_kmemdup(>pdev->dev, _data[0], DE_EEPROM_SIZE,
+  GFP_KERNEL);
 
return;
 
@@ -2092,7 +2093,6 @@ static int de_init_one(struct pci_dev *pdev, const struct 
pci_device_id *ent)
return 0;
 
 err_out_iomap:
-   kfree(de->ee_data);
iounmap(regs);
 err_out_res:
pci_release_regions(pdev);
@@ -2106,7 +2106,6 @@ static void de_remove_one(struct pci_dev *pdev)
 
BUG_ON(!dev);
unregister_netdev(dev);
-   kfree(de->ee_data);
iounmap(de->regs);
pci_release_regions(pdev);
 }
-- 
2.28.0

[PATCH net-next v2 2/3] net: dec: tulip: de2104x: Replace pci_enable_device with devres version

Replace pci_enable_device() with its devres counterpart
pcim_enable_device().

Signed-off-by: Moritz Fischer 
---

Note: Please check my logic on this, it would seem to me
calling pci_disable_device() on devices enabled with
pcim_enable_device() *should* be fine.

Changes from v1:
- Fixed missing replace for resume function
---
 drivers/net/ethernet/dec/tulip/de2104x.c | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/net/ethernet/dec/tulip/de2104x.c 
b/drivers/net/ethernet/dec/tulip/de2104x.c
index 9bcfc82b71d1..698d79bc4784 100644
--- a/drivers/net/ethernet/dec/tulip/de2104x.c
+++ b/drivers/net/ethernet/dec/tulip/de2104x.c
@@ -2009,14 +2009,14 @@ static int de_init_one(struct pci_dev *pdev, const 
struct pci_device_id *ent)
netif_carrier_off(dev);
 
/* wake up device, assign resources */
-   rc = pci_enable_device(pdev);
+   rc = pcim_enable_device(pdev);
if (rc)
return rc;
 
/* reserve PCI resources to ensure driver atomicity */
rc = pci_request_regions(pdev, DRV_NAME);
if (rc)
-   goto err_out_disable;
+   return rc;
 
/* check for invalid IRQ value */
if (pdev->irq < 2) {
@@ -2096,8 +2096,6 @@ static int de_init_one(struct pci_dev *pdev, const struct 
pci_device_id *ent)
iounmap(regs);
 err_out_res:
pci_release_regions(pdev);
-err_out_disable:
-   pci_disable_device(pdev);
return rc;
 }
 
@@ -2111,7 +2109,6 @@ static void de_remove_one(struct pci_dev *pdev)
kfree(de->ee_data);
iounmap(de->regs);
pci_release_regions(pdev);
-   pci_disable_device(pdev);
 }
 
 #ifdef CONFIG_PM
@@ -2164,7 +2161,7 @@ static int de_resume (struct pci_dev *pdev)
goto out;
if (!netif_running(dev))
goto out_attach;
-   if ((retval = pci_enable_device(pdev))) {
+   if ((retval = pcim_enable_device(pdev))) {
netdev_err(dev, "pci_enable_device failed in resume\n");
goto out;
}
-- 
2.28.0

[PATCH net-next v2 1/3] net: dec: tulip: de2104x: Replace alloc_etherdev by devm_alloc_etherdev

Replace devm_alloc_etherdev() with its devres version.

Signed-off-by: Moritz Fischer 
---
 drivers/net/ethernet/dec/tulip/de2104x.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/net/ethernet/dec/tulip/de2104x.c 
b/drivers/net/ethernet/dec/tulip/de2104x.c
index 42b798a3fad4..9bcfc82b71d1 100644
--- a/drivers/net/ethernet/dec/tulip/de2104x.c
+++ b/drivers/net/ethernet/dec/tulip/de2104x.c
@@ -1986,7 +1986,7 @@ static int de_init_one(struct pci_dev *pdev, const struct 
pci_device_id *ent)
 #endif
 
/* allocate a new ethernet device structure, and fill in defaults */
-   dev = alloc_etherdev(sizeof(struct de_private));
+   dev = devm_alloc_etherdev(>dev, sizeof(struct de_private));
if (!dev)
return -ENOMEM;
 
@@ -2011,7 +2011,7 @@ static int de_init_one(struct pci_dev *pdev, const struct 
pci_device_id *ent)
/* wake up device, assign resources */
rc = pci_enable_device(pdev);
if (rc)
-   goto err_out_free;
+   return rc;
 
/* reserve PCI resources to ensure driver atomicity */
rc = pci_request_regions(pdev, DRV_NAME);
@@ -2098,8 +2098,6 @@ static int de_init_one(struct pci_dev *pdev, const struct 
pci_device_id *ent)
pci_release_regions(pdev);
 err_out_disable:
pci_disable_device(pdev);
-err_out_free:
-   free_netdev(dev);
return rc;
 }
 
@@ -2114,7 +2112,6 @@ static void de_remove_one(struct pci_dev *pdev)
iounmap(de->regs);
pci_release_regions(pdev);
pci_disable_device(pdev);
-   free_netdev(dev);
 }
 
 #ifdef CONFIG_PM
-- 
2.28.0

[PATCH net-next v2 0/3] First bunch of Tulip cleanups

This series is the first bunch of minor cleanups for the de2104x driver
to make it look and behave more like a modern driver.

These changes replace some of the non-devres versions with devres
versions of functions to simplify the error paths.

Next up after this will be the ioremap part.

Changes from v1:
- Fix issue with the pci_enable_device patch.

Moritz Fischer (3):
  net: dec: tulip: de2104x: Replace alloc_etherdev by
devm_alloc_etherdev
  net: dec: tulip: de2104x: Replace pci_enable_device with devres
version
  net: dec: tulip: de2104x: Replace kmemdup() with devm_kmempdup()

 drivers/net/ethernet/dec/tulip/de2104x.c | 21 +++--
 1 file changed, 7 insertions(+), 14 deletions(-)

-- 
2.28.0

Re: [External] Re: [PATCH v2] mm/vmscan: fix infinite loop in drop_slab_node

2020-09-14 Thread Chunxin Zang

On Mon, Sep 14, 2020 at 11:17 PM Michal Hocko  wrote:
>
> On Mon 14-09-20 23:02:15, Chunxin Zang wrote:
> > On Mon, Sep 14, 2020 at 9:47 PM Michal Hocko  wrote:
> >
> > > On Mon 14-09-20 21:25:59, Chunxin Zang wrote:
> > > > On Mon, Sep 14, 2020 at 5:30 PM Michal Hocko  wrote:
> > > >
> > > > > The subject is misleading because this patch doesn't fix an infinite
> > > > > loop, right? It just allows the userspace to interrupt the operation.
> > > > >
> > > > >
> > > > Yes,  so we are making a separate patch follow Vlastimil's
> > > recommendations.
> > > > Use double of threshold to end the loop.
> > >
> > > That still means the changelog needs an update
> > >
> >
> > The patch is already merged in Linux-next branch.  Can I update the
> > changelog now?
>
> Yes. Andrew will refresh it. He doesn't have a git tree which would
> prevent rewriting the patch.
>
> > This is my first patch, please forgive me :)
>
> No worries. The mm patch workflow is rather different from others.
>
> > > > On Thu, Sep 10, 2020 at 1:59 AM Vlastimil Babka  wrote:
> > > > > > From: Chunxin Zang 
> > > > > >
> > > > > ...
> > > > > - IMHO it's still worth to bail out in your scenario even without a
> > > > > signal, e.g.
> > > > > by the doubling of threshold. But it can be a separate patch.
> > > > > Thanks!
> > > > > ...
> > > >
> > > >
> > > >
> > > > On Wed 09-09-20 23:20:47, zangchun...@bytedance.com wrote:
> > > > > > From: Chunxin Zang 
> > > > > >
> > > > > > On our server, there are about 10k memcg in one machine. They use
> > > memory
> > > > > > very frequently. When I tigger drop caches，the process will infinite
> > > loop
> > > > > > in drop_slab_node.
> > > > >
> > > > > Is this really an infinite loop, or it just takes a lot of time to
> > > > > process all the metadata in that setup? If this is really an infinite
> > > > > loop then we should look at it. My current understanding is that the
> > > > > operation would finish at some time it just takes painfully long to 
> > > > > get
> > > > > there.
> > > > >
> > > >
> > > > Yes,  it's really an infinite loop.  Every loop spends a lot of time. In
> > > > this time,
> > > > memcg will alloc/free memory,  so the next loop, the total of  'freed'
> > > > always bigger than 10.
> > >
> > > I am still not sure I follow. Do you mean that there is somebody
> > > constantly generating more objects to reclaim?
> > >
> >
> > Yes, this is my meaning. :)
> >
> >
> > > Maybe we are just not agreeing on the definition of an infinite loop but
> > > in my book that means that the final condition can never be met. While a
> > > busy adding new object might indeed cause drop caches to loop for a long
> > > time this is to be expected from that interface as it is supposed to
> > > drop all the cache and that can grow during the operation.
> > > --
> > >
> >
> > Because I have 10k memcg , all of them are heavy users of memory.
> > During each loop, there are always more than 10 reclaimable objects
> > generating, so the
> > condition is never met.
>
> 10k or any number of memcgs shouldn't really make much of a difference.
> Except for the time the scan adds. Fundamentally we are talking about
> freed objects and whether they are on the global or per memcg lists
> should result in a similar behavior.
>
> > The drop cache process has no chance to exit the
> > loop.
> > Although the purpose of the 'drop cache' interface is to release all
> > caches, we still need a
> > way to terminate it, e.g. in this case, the process took too long to run .
>
> Yes, this is perfectly understandable. Having a bail out on fatal signal
> is a completely reasonable thing to do. I am mostly confused by your
> infinite loop claims and what the relation of this patch to it. I would
> propose this wording instead
>
> "
> We have observed that drop_caches can take a considerable amount of
> time (). Especially when there are many memcgs involved
> because they are adding an additional overhead.
>
> It is quite unfortunate that the operation cannot be interrupted by a
> signal currently. Add a check for fatal signals into the main loop
> so that userspace can control early bailout.
> "

I understand what you mean. Yes, you are right, The patch only
provides a way for
users to terminate the process, not to reduce time consumption, not improve
the situation about loops.
I will update the description of the patch in v3.
Thanks so much :)

> or something along those lines.
>
> >
> >   root  357956 ... RAug25 21119854:55 echo 3 > /proc/sys/vm/drop_caches
>
> --
> Michal Hocko
> SUSE Labs

Best wishes
Chunxin

[PATCH v4 15/17] NTB: tool: Enable the NTB/PCIe link on the local or remote side of bridge

Invoke ntb_link_enable() to enable the NTB/PCIe link on the local
or remote side of the bridge.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/ntb/test/ntb_tool.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/ntb/test/ntb_tool.c b/drivers/ntb/test/ntb_tool.c
index b7bf3f863d79..8230ced503e3 100644
--- a/drivers/ntb/test/ntb_tool.c
+++ b/drivers/ntb/test/ntb_tool.c
@@ -1638,6 +1638,7 @@ static int tool_probe(struct ntb_client *self, struct 
ntb_dev *ntb)
 
tool_setup_dbgfs(tc);
 
+   ntb_link_enable(ntb, NTB_SPEED_AUTO, NTB_WIDTH_AUTO);
return 0;
 
 err_clear_mws:
-- 
2.17.1

[PATCH v4 16/17] Documentation: PCI: Add binding documentation for pci-ntb endpoint function

Add binding documentation for pci-ntb endpoint function that helps in
adding and configuring pci-ntb endpoint function.

Signed-off-by: Kishon Vijay Abraham I 
---
 .../PCI/endpoint/function/binding/pci-ntb.rst | 38 +++
 Documentation/PCI/endpoint/index.rst  |  1 +
 2 files changed, 39 insertions(+)
 create mode 100644 Documentation/PCI/endpoint/function/binding/pci-ntb.rst

diff --git a/Documentation/PCI/endpoint/function/binding/pci-ntb.rst 
b/Documentation/PCI/endpoint/function/binding/pci-ntb.rst
new file mode 100644
index ..40253d3d5163
--- /dev/null
+++ b/Documentation/PCI/endpoint/function/binding/pci-ntb.rst
@@ -0,0 +1,38 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+==
+PCI NTB Endpoint Function
+==
+
+1) Create a subdirectory to pci_epf_ntb directory in configfs.
+
+Standard EPF Configurable Fields:
+
+   ===
+vendorid  should be 0x104c
+deviceid  should be 0xb00d for TI's J721E SoC
+revid don't care
+progif_code   don't care
+subclass_code should be 0x00
+baseclass_codeshould be 0x5
+cache_line_size   don't care
+subsys_vendor_id   don't care
+subsys_id don't care
+interrupt_pin don't care
+msi_interruptsdon't care
+msix_interrupts   don't care
+   ===
+
+2) Create a subdirectory to directory created in 1
+
+NTB EPF specific configurable fields:
+
+   ===
+db_count  Number of doorbells; default = 4
+mw1   size of memory window1
+mw2   size of memory window2
+mw3   size of memory window3
+mw4   size of memory window4
+num_mws   Number of memory windows; max = 4
+spad_countNumber of scratchpad registers; default = 64
+   ===
diff --git a/Documentation/PCI/endpoint/index.rst 
b/Documentation/PCI/endpoint/index.rst
index ef6861128506..9cb6e5f3c4d5 100644
--- a/Documentation/PCI/endpoint/index.rst
+++ b/Documentation/PCI/endpoint/index.rst
@@ -14,3 +14,4 @@ PCI Endpoint Framework
pci-ntb-function
 
function/binding/pci-test
+   function/binding/pci-ntb
-- 
2.17.1

[PATCH v4 09/17] PCI: endpoint: Add pci_epf_ops for epf drivers to expose function specific attrs

In addition to the attributes that are generic across function drivers
documented in Documentation/PCI/endpoint/pci-endpoint-cfs.rst, there
could be function specific attributes that has to be exposed by the
function driver to be configured by the user. Add ->add_cfs()
in pci_epf_ops to be populated by the function driver if it has to
expose any function specific attributes and pci_epf_type_add_cfs() to
be invoked by pci-ep-cfs.c when sub-directory to main function directory
is created.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/pci/endpoint/pci-epf-core.c | 32 +
 include/linux/pci-epf.h |  5 +
 2 files changed, 37 insertions(+)

diff --git a/drivers/pci/endpoint/pci-epf-core.c 
b/drivers/pci/endpoint/pci-epf-core.c
index 79329ec6373c..7646c8660d42 100644
--- a/drivers/pci/endpoint/pci-epf-core.c
+++ b/drivers/pci/endpoint/pci-epf-core.c
@@ -20,6 +20,38 @@ static DEFINE_MUTEX(pci_epf_mutex);
 static struct bus_type pci_epf_bus_type;
 static const struct device_type pci_epf_type;
 
+/**
+ * pci_epf_type_add_cfs() - Help function drivers to expose function specific
+ *  attributes in configfs
+ * @epf: the EPF device that has to be configured using configfs
+ * @group: the parent configfs group (corresponding to entries in
+ * pci_epf_device_id)
+ *
+ * Invoke to expose function specific attributes in configfs. If the function
+ * driver does not have anything to expose (attributes configured by user),
+ * return NULL.
+ */
+struct config_group *pci_epf_type_add_cfs(struct pci_epf *epf,
+ struct config_group *group)
+{
+   struct config_group *epf_type_group;
+
+   if (!epf->driver) {
+   dev_err(>dev, "epf device not bound to driver\n");
+   return NULL;
+   }
+
+   if (!epf->driver->ops->add_cfs)
+   return NULL;
+
+   mutex_lock(>lock);
+   epf_type_group = epf->driver->ops->add_cfs(epf, group);
+   mutex_unlock(>lock);
+
+   return epf_type_group;
+}
+EXPORT_SYMBOL_GPL(pci_epf_type_add_cfs);
+
 /**
  * pci_epf_unbind() - Notify the function driver that the binding between the
  *   EPF device and EPC device has been lost
diff --git a/include/linux/pci-epf.h b/include/linux/pci-epf.h
index 1dc66824f5a8..b241e7dd171f 100644
--- a/include/linux/pci-epf.h
+++ b/include/linux/pci-epf.h
@@ -62,10 +62,13 @@ struct pci_epf_header {
  * @bind: ops to perform when a EPC device has been bound to EPF device
  * @unbind: ops to perform when a binding has been lost between a EPC device
  * and EPF device
+ * @add_cfs: ops to initialize function specific configfs attributes
  */
 struct pci_epf_ops {
int (*bind)(struct pci_epf *epf);
void(*unbind)(struct pci_epf *epf);
+   struct config_group *(*add_cfs)(struct pci_epf *epf,
+   struct config_group *group);
 };
 
 /**
@@ -188,4 +191,6 @@ void pci_epf_free_space(struct pci_epf *epf, void *addr, 
enum pci_barno bar,
enum pci_epc_interface_type type);
 int pci_epf_bind(struct pci_epf *epf);
 void pci_epf_unbind(struct pci_epf *epf);
+struct config_group *pci_epf_type_add_cfs(struct pci_epf *epf,
+ struct config_group *group);
 #endif /* __LINUX_PCI_EPF_H */
-- 
2.17.1

[PATCH v4 17/17] Documentation: PCI: Add userguide for PCI endpoint NTB function

Add documentation to help users use pci-epf-ntb function driver and
existing host side NTB infrastructure for NTB functionality.

Signed-off-by: Kishon Vijay Abraham I 
---
 Documentation/PCI/endpoint/index.rst |   1 +
 Documentation/PCI/endpoint/pci-ntb-howto.rst | 160 +++
 2 files changed, 161 insertions(+)
 create mode 100644 Documentation/PCI/endpoint/pci-ntb-howto.rst

diff --git a/Documentation/PCI/endpoint/index.rst 
b/Documentation/PCI/endpoint/index.rst
index 9cb6e5f3c4d5..38ea1f604b6d 100644
--- a/Documentation/PCI/endpoint/index.rst
+++ b/Documentation/PCI/endpoint/index.rst
@@ -12,6 +12,7 @@ PCI Endpoint Framework
pci-test-function
pci-test-howto
pci-ntb-function
+   pci-ntb-howto
 
function/binding/pci-test
function/binding/pci-ntb
diff --git a/Documentation/PCI/endpoint/pci-ntb-howto.rst 
b/Documentation/PCI/endpoint/pci-ntb-howto.rst
new file mode 100644
index ..e5194573f1a8
--- /dev/null
+++ b/Documentation/PCI/endpoint/pci-ntb-howto.rst
@@ -0,0 +1,160 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+==
+PCI NTB EPF User Guide
+==
+
+:Author: Kishon Vijay Abraham I 
+
+This document is a guide to help users use pci-epf-ntb function driver
+and ntb_hw_epf host driver for NTB functionality. The list of steps to
+be followed in the host side and EP side is given below. For the hardware
+configuration and internals of NTB using configurable endpoints see
+Documentation/PCI/endpoint/pci-ntb-function.rst
+
+Endpoint Device
+===
+
+Endpoint Controller Devices
+---
+
+For implementing NTB functionality at least two endpoint controller devices
+are required.
+To find the list of endpoint controller devices in the system::
+
+# ls /sys/class/pci_epc/
+  290.pcie-ep  291.pcie-ep
+
+If PCI_ENDPOINT_CONFIGFS is enabled::
+
+   # ls /sys/kernel/config/pci_ep/controllers
+ 290.pcie-ep  291.pcie-ep
+
+
+Endpoint Function Drivers
+-
+
+To find the list of endpoint function drivers in the system::
+
+   # ls /sys/bus/pci-epf/drivers
+ pci_epf_ntb   pci_epf_ntb
+
+If PCI_ENDPOINT_CONFIGFS is enabled::
+
+   # ls /sys/kernel/config/pci_ep/functions
+ pci_epf_ntb   pci_epf_ntb
+
+
+Creating pci-epf-ntb Device
+
+
+PCI endpoint function device can be created using the configfs. To create
+pci-epf-ntb device, the following commands can be used::
+
+   # mount -t configfs none /sys/kernel/config
+   # cd /sys/kernel/config/pci_ep/
+   # mkdir functions/pci_epf_ntb/func1
+
+The "mkdir func1" above creates the pci-epf-ntb function device that will
+be probed by pci_epf_ntb driver.
+
+The PCI endpoint framework populates the directory with the following
+configurable fields::
+
+   # ls functions/pci_epf_ntb/func1
+  baseclass_codedeviceid  msi_interruptspci-epf-ntb.0
+  progif_code   secondary subsys_id vendorid
+  cache_line_size   interrupt_pin msix_interrupts   primary
+  revid subclass_code subsys_vendor_id
+
+The PCI endpoint function driver populates these entries with default values
+when the device is bound to the driver. The pci-epf-ntb driver populates
+vendorid with 0x and interrupt_pin with 0x0001::
+
+   # cat functions/pci_epf_ntb/func1/vendorid
+ 0x
+   # cat functions/pci_epf_ntb/func1/interrupt_pin
+ 0x0001
+
+
+Configuring pci-epf-ntb Device
+---
+
+The user can configure the pci-epf-ntb device using its configfs entry. In 
order
+to change the vendorid and the deviceid, the following
+commands can be used::
+
+   # echo 0x104c > functions/pci_epf_ntb/func1/vendorid
+   # echo 0xb00d > functions/pci_epf_ntb/func1/deviceid
+
+In order to configure NTB specific attributes, a new sub-directory to func1
+should be created::
+
+   # mkdir functions/pci_epf_ntb/func1/pci_epf_ntb.0/
+
+The NTB function driver will populate this directory with various attributes
+that can be configured by the user::
+
+   # ls functions/pci_epf_ntb/func1/pci_epf_ntb.0/
+  db_countmw1 mw2 mw3 mw4 num_mws
+  spad_count
+
+A sample configuration for NTB function is given below::
+
+   # echo 4 > functions/pci_epf_ntb/func1/pci_epf_ntb.0/db_count
+   # echo 128 > functions/pci_epf_ntb/func1/pci_epf_ntb.0/spad_count
+   # echo 2 > functions/pci_epf_ntb/func1/pci_epf_ntb.0/num_mws
+   # echo 0x10 > functions/pci_epf_ntb/func1/pci_epf_ntb.0/mw1
+   # echo 0x10 > functions/pci_epf_ntb/func1/pci_epf_ntb.0/mw2
+
+Binding pci-epf-ntb Device to EP Controller
+
+
+NTB function device should be attached to two PCIe endpoint controllers
+connected to the two hosts. Use the 'primary' and

[PATCH v4 11/17] PCI: cadence: Implement ->msi_map_irq() ops

Implement ->msi_map_irq() ops in order to map physical address to
MSI address and return MSI data.

Signed-off-by: Kishon Vijay Abraham I 
---
 .../pci/controller/cadence/pcie-cadence-ep.c  | 50 +++
 drivers/pci/endpoint/pci-epc-core.c   |  7 ++-
 include/linux/pci-epc.h   |  2 +-
 3 files changed, 54 insertions(+), 5 deletions(-)

diff --git a/drivers/pci/controller/cadence/pcie-cadence-ep.c 
b/drivers/pci/controller/cadence/pcie-cadence-ep.c
index 254a3e1eff50..b9aacd6ce816 100644
--- a/drivers/pci/controller/cadence/pcie-cadence-ep.c
+++ b/drivers/pci/controller/cadence/pcie-cadence-ep.c
@@ -383,6 +383,54 @@ static int cdns_pcie_ep_send_msi_irq(struct cdns_pcie_ep 
*ep, u8 fn,
return 0;
 }
 
+static int cdns_pcie_ep_map_msi_irq(struct pci_epc *epc, u8 fn,
+   phys_addr_t addr, u8 interrupt_num,
+   u32 entry_size, u32 *msi_data)
+{
+   struct cdns_pcie_ep *ep = epc_get_drvdata(epc);
+   u32 cap = CDNS_PCIE_EP_FUNC_MSI_CAP_OFFSET;
+   struct cdns_pcie *pcie = >pcie;
+   u16 flags, mme, data, data_mask;
+   u8 msi_count;
+   u64 pci_addr;
+   int ret;
+   int i;
+
+   /* Check whether the MSI feature has been enabled by the PCI host. */
+   flags = cdns_pcie_ep_fn_readw(pcie, fn, cap + PCI_MSI_FLAGS);
+   if (!(flags & PCI_MSI_FLAGS_ENABLE))
+   return -EINVAL;
+
+   /* Get the number of enabled MSIs */
+   mme = (flags & PCI_MSI_FLAGS_QSIZE) >> 4;
+   msi_count = 1 << mme;
+   if (!interrupt_num || interrupt_num > msi_count)
+   return -EINVAL;
+
+   /* Compute the data value to be written. */
+   data_mask = msi_count - 1;
+   data = cdns_pcie_ep_fn_readw(pcie, fn, cap + PCI_MSI_DATA_64);
+   data = data & ~data_mask;
+
+   /* Get the PCI address where to write the data into. */
+   pci_addr = cdns_pcie_ep_fn_readl(pcie, fn, cap + PCI_MSI_ADDRESS_HI);
+   pci_addr <<= 32;
+   pci_addr |= cdns_pcie_ep_fn_readl(pcie, fn, cap + PCI_MSI_ADDRESS_LO);
+   pci_addr &= GENMASK_ULL(63, 2);
+
+   for (i = 0; i < interrupt_num; i++) {
+   ret = cdns_pcie_ep_map_addr(epc, fn, addr, pci_addr,
+   entry_size);
+   if (ret)
+   return ret;
+   addr = addr + entry_size;
+   }
+
+   *msi_data = data;
+
+   return 0;
+}
+
 static int cdns_pcie_ep_send_msix_irq(struct cdns_pcie_ep *ep, u8 fn,
  u16 interrupt_num)
 {
@@ -482,6 +530,7 @@ static const struct pci_epc_features cdns_pcie_epc_features 
= {
.linkup_notifier = false,
.msi_capable = true,
.msix_capable = true,
+   .align = 256,
 };
 
 static const struct pci_epc_features*
@@ -501,6 +550,7 @@ static const struct pci_epc_ops cdns_pcie_epc_ops = {
.set_msix   = cdns_pcie_ep_set_msix,
.get_msix   = cdns_pcie_ep_get_msix,
.raise_irq  = cdns_pcie_ep_raise_irq,
+   .map_msi_irq= cdns_pcie_ep_map_msi_irq,
.start  = cdns_pcie_ep_start,
.get_features   = cdns_pcie_ep_get_features,
 };
diff --git a/drivers/pci/endpoint/pci-epc-core.c 
b/drivers/pci/endpoint/pci-epc-core.c
index 73f9ff425824..d1e25be74665 100644
--- a/drivers/pci/endpoint/pci-epc-core.c
+++ b/drivers/pci/endpoint/pci-epc-core.c
@@ -235,7 +235,6 @@ EXPORT_SYMBOL_GPL(pci_epc_raise_irq);
  * MSI data
  * @epc: the EPC device which has the MSI capability
  * @func_no: the physical endpoint function number in the EPC device
- * @vfunc_no: the virtual endpoint function number in the physical function
  * @phys_addr: the physical address of the outbound region
  * @interrupt_num: the MSI interrupt number
  * @entry_size: Size of Outbound address region for each interrupt
@@ -249,7 +248,7 @@ EXPORT_SYMBOL_GPL(pci_epc_raise_irq);
  * physical address (in outbound region) of the other interface to ring
  * doorbell.
  */
-int pci_epc_map_msi_irq(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
+int pci_epc_map_msi_irq(struct pci_epc *epc, u8 func_no,
phys_addr_t phys_addr, u8 interrupt_num, u32 entry_size,
u32 *msi_data)
 {
@@ -262,8 +261,8 @@ int pci_epc_map_msi_irq(struct pci_epc *epc, u8 func_no, u8 
vfunc_no,
return -EINVAL;
 
mutex_lock(>lock);
-   ret = epc->ops->map_msi_irq(epc, func_no, vfunc_no, phys_addr,
-   interrupt_num, entry_size, msi_data);
+   ret = epc->ops->map_msi_irq(epc, func_no, phys_addr, interrupt_num,
+   entry_size, msi_data);
mutex_unlock(>lock);
 
return ret;
diff --git a/include/linux/pci-epc.h b/include/linux/pci-epc.h
index 88284f3a0698..61f2cebcd272 100644
--- a/include/linux/pci-epc.h
+++ b/include/linux/pci-epc.h
@@ -78,7 +78,7 @@

[PATCH v4 14/17] NTB: Add support for EPF PCI-Express Non-Transparent Bridge

Add support for EPF PCI-Express Non-Transparent Bridge (NTB) device.
This driver is platform independent and could be used by any platform
which have multiple PCIe endpoint instances configured using the
pci-epf-ntb driver. The driver connnects to the standard NTB sub-system
interface. The EPF NTB device has configurable number of memory windows
(Max 4), configurable number of doorbell (Max 32), and configurable
number of scratch-pad registers.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/ntb/hw/Kconfig  |   1 +
 drivers/ntb/hw/Makefile |   1 +
 drivers/ntb/hw/epf/Kconfig  |   6 +
 drivers/ntb/hw/epf/Makefile |   1 +
 drivers/ntb/hw/epf/ntb_hw_epf.c | 751 
 5 files changed, 760 insertions(+)
 create mode 100644 drivers/ntb/hw/epf/Kconfig
 create mode 100644 drivers/ntb/hw/epf/Makefile
 create mode 100644 drivers/ntb/hw/epf/ntb_hw_epf.c

diff --git a/drivers/ntb/hw/Kconfig b/drivers/ntb/hw/Kconfig
index e77c587060ff..c325be526b80 100644
--- a/drivers/ntb/hw/Kconfig
+++ b/drivers/ntb/hw/Kconfig
@@ -2,4 +2,5 @@
 source "drivers/ntb/hw/amd/Kconfig"
 source "drivers/ntb/hw/idt/Kconfig"
 source "drivers/ntb/hw/intel/Kconfig"
+source "drivers/ntb/hw/epf/Kconfig"
 source "drivers/ntb/hw/mscc/Kconfig"
diff --git a/drivers/ntb/hw/Makefile b/drivers/ntb/hw/Makefile
index 4714d6238845..223ca592b5f9 100644
--- a/drivers/ntb/hw/Makefile
+++ b/drivers/ntb/hw/Makefile
@@ -2,4 +2,5 @@
 obj-$(CONFIG_NTB_AMD)  += amd/
 obj-$(CONFIG_NTB_IDT)  += idt/
 obj-$(CONFIG_NTB_INTEL)+= intel/
+obj-$(CONFIG_NTB_EPF)  += epf/
 obj-$(CONFIG_NTB_SWITCHTEC) += mscc/
diff --git a/drivers/ntb/hw/epf/Kconfig b/drivers/ntb/hw/epf/Kconfig
new file mode 100644
index ..6197d1aab344
--- /dev/null
+++ b/drivers/ntb/hw/epf/Kconfig
@@ -0,0 +1,6 @@
+config NTB_EPF
+   tristate "Generic EPF Non-Transparent Bridge support"
+   depends on m
+   help
+ This driver supports EPF NTB on configurable endpoint.
+ If unsure, say N.
diff --git a/drivers/ntb/hw/epf/Makefile b/drivers/ntb/hw/epf/Makefile
new file mode 100644
index ..2f560a422bc6
--- /dev/null
+++ b/drivers/ntb/hw/epf/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_NTB_EPF) += ntb_hw_epf.o
diff --git a/drivers/ntb/hw/epf/ntb_hw_epf.c b/drivers/ntb/hw/epf/ntb_hw_epf.c
new file mode 100644
index ..2989f2b41fda
--- /dev/null
+++ b/drivers/ntb/hw/epf/ntb_hw_epf.c
@@ -0,0 +1,751 @@
+// SPDX-License-Identifier: GPL-2.0
+/**
+ * Host side endpoint driver to implement Non-Transparent Bridge functionality
+ *
+ * Copyright (C) 2020 Texas Instruments
+ * Author: Kishon Vijay Abraham I 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define NTB_EPF_COMMAND0x0
+#define CMD_CONFIGURE_DOORBELL 1
+#define CMD_TEARDOWN_DOORBELL  2
+#define CMD_CONFIGURE_MW   3
+#define CMD_TEARDOWN_MW4
+#define CMD_LINK_UP5
+#define CMD_LINK_DOWN  6
+
+#define NTB_EPF_ARGUMENT   0x4
+#define MSIX_ENABLEBIT(16)
+
+#define NTB_EPF_CMD_STATUS 0x8
+#define COMMAND_STATUS_OK  1
+#define COMMAND_STATUS_ERROR   2
+
+#define NTB_EPF_LINK_STATUS0x0A
+#define LINK_STATUS_UP BIT(0)
+
+#define NTB_EPF_TOPOLOGY   0x0C
+#define NTB_EPF_LOWER_ADDR 0x10
+#define NTB_EPF_UPPER_ADDR 0x14
+#define NTB_EPF_LOWER_SIZE 0x18
+#define NTB_EPF_UPPER_SIZE 0x1C
+#define NTB_EPF_MW_COUNT   0x20
+#define NTB_EPF_MW1_OFFSET 0x24
+#define NTB_EPF_SPAD_OFFSET0x28
+#define NTB_EPF_SPAD_COUNT 0x2C
+#define NTB_EPF_DB_ENTRY_SIZE  0x30
+#define NTB_EPF_DB_DATA(n) (0x34 + (n) * 4)
+
+#define NTB_EPF_MIN_DB_COUNT   3
+#define NTB_EPF_MAX_DB_COUNT   31
+#define NTB_EPF_MW_OFFSET  2
+
+#define NTB_EPF_COMMAND_TIMEOUT1000 /* 1 Sec */
+
+enum pci_barno {
+   BAR_0,
+   BAR_1,
+   BAR_2,
+   BAR_3,
+   BAR_4,
+   BAR_5,
+};
+
+struct ntb_epf_dev {
+   struct ntb_dev ntb;
+   struct device *dev;
+   /* Mutex to protect providing commands to NTB EPF */
+   struct mutex cmd_lock;
+
+   enum pci_barno ctrl_reg_bar;
+   enum pci_barno peer_spad_reg_bar;
+   enum pci_barno db_reg_bar;
+
+   unsigned int mw_count;
+   unsigned int spad_count;
+   unsigned int db_count;
+
+   void __iomem *ctrl_reg;
+   void __iomem *db_reg;
+   void __iomem *peer_spad_reg;
+
+   unsigned int self_spad;
+   unsigned int peer_spad;
+
+   int db_val;
+   u64 db_valid_mask;
+};
+
+#define ntb_ndev(__ntb) container_of(__ntb, struct ntb_epf_dev, ntb)
+
+struct ntb_epf_data {
+   /* BAR that contains both control region and self spad region */
+   enum pci_barno ctrl_reg_bar;
+   /* BAR that contains peer spad region */
+   enum pci_barno peer_spad_reg_bar;
+   /* BAR that contains Doorbell region and Memory window '1' */
+   enum pci_barno db_reg_bar;
+};
+
+static int ntb_epf_send_command(struct

Re: [PATCH v5] lib/string.c: implement stpcpy

2020-09-14 Thread Nathan Chancellor

On Mon, Sep 14, 2020 at 09:16:43AM -0700, Nick Desaulniers wrote:
> LLVM implemented a recent "libcall optimization" that lowers calls to
> `sprintf(dest, "%s", str)` where the return value is used to
> `stpcpy(dest, str) - dest`. This generally avoids the machinery involved
> in parsing format strings.  `stpcpy` is just like `strcpy` except it
> returns the pointer to the new tail of `dest`.  This optimization was
> introduced into clang-12.
> 
> Implement this so that we don't observe linkage failures due to missing
> symbol definitions for `stpcpy`.
> 
> Similar to last year's fire drill with:
> commit 5f074f3e192f ("lib/string.c: implement a basic bcmp")
> 
> The kernel is somewhere between a "freestanding" environment (no full libc)
> and "hosted" environment (many symbols from libc exist with the same
> type, function signature, and semantics).
> 
> As H. Peter Anvin notes, there's not really a great way to inform the
> compiler that you're targeting a freestanding environment but would like
> to opt-in to some libcall optimizations (see pr/47280 below), rather than
> opt-out.
> 
> Arvind notes, -fno-builtin-* behaves slightly differently between GCC
> and Clang, and Clang is missing many __builtin_* definitions, which I
> consider a bug in Clang and am working on fixing.
> 
> Masahiro summarizes the subtle distinction between compilers justly:
>   To prevent transformation from foo() into bar(), there are two ways in
>   Clang to do that; -fno-builtin-foo, and -fno-builtin-bar.  There is
>   only one in GCC; -fno-buitin-foo.
> 
> (Any difference in that behavior in Clang is likely a bug from a missing
> __builtin_* definition.)
> 
> Masahiro also notes:
>   We want to disable optimization from foo() to bar(),
>   but we may still benefit from the optimization from
>   foo() into something else. If GCC implements the same transform, we
>   would run into a problem because it is not -fno-builtin-bar, but
>   -fno-builtin-foo that disables that optimization.
> 
>   In this regard, -fno-builtin-foo would be more future-proof than
>   -fno-built-bar, but -fno-builtin-foo is still potentially overkill. We
>   may want to prevent calls from foo() being optimized into calls to
>   bar(), but we still may want other optimization on calls to foo().
> 
> It seems that compilers today don't quite provide the fine grain control
> over which libcall optimizations pseudo-freestanding environments would
> prefer.
> 
> Finally, Kees notes that this interface is unsafe, so we should not
> encourage its use.  As such, I've removed the declaration from any
> header, but it still needs to be exported to avoid linkage errors in
> modules.
> 
> Reported-by: Sami Tolvanen 
> Suggested-by: Andy Lavr 
> Suggested-by: Arvind Sankar 
> Suggested-by: Joe Perches 
> Suggested-by: Kees Cook 
> Suggested-by: Masahiro Yamada 
> Suggested-by: Rasmus Villemoes 
> Signed-off-by: Nick Desaulniers 
> Tested-by: Nathan Chancellor 

Reviewed-by: Nathan Chancellor 

It would be nice to get this into mainline sooner rather than later so
that it can start filtering into the stable trees. ToT LLVM builds have
been broken for a month now.

> Cc: sta...@vger.kernel.org
> Link: https://bugs.llvm.org/show_bug.cgi?id=47162
> Link: https://bugs.llvm.org/show_bug.cgi?id=47280
> Link: https://github.com/ClangBuiltLinux/linux/issues/1126
> Link: https://man7.org/linux/man-pages/man3/stpcpy.3.html
> Link: https://pubs.opengroup.org/onlinepubs/9699919799/functions/stpcpy.html
> Link: https://reviews.llvm.org/D85963
> ---
> Changes V5:
> * fix missing parens in comment.
> 
> Changes V4:
> * Roll up Kees' comment fixup from
>   https://lore.kernel.org/lkml/202009060302.4574D8D0E0@keescook/#t.
> * Keep Nathan's tested by tag.
> * Add Kees' reviewed by tag from
>   https://lore.kernel.org/lkml/202009031446.3865FE82B@keescook/.

For the record, I don't see Kees' review tag on this.

> 
> Changes V3:
> * Drop Sami's Tested by tag; newer patch.
> * Add EXPORT_SYMBOL as per Andy.
> * Rewrite commit message, rewrote part of what Masahiro said to be
>   generic in terms of foo() and bar().
> * Prefer %NUL-terminated to NULL terminated. NUL is the ASCII character
>   '\0', as per Arvind and Rasmus.
> 
> Changes V2:
> * Added Sami's Tested by; though the patch changed implementation, the
>   missing symbol at link time was the problem Sami was observing.
> * Fix __restrict -> __restrict__ typo as per Joe.
> * Drop note about restrict from commit message as per Arvind.
> * Fix NULL -> NUL as per Arvind; NUL is ASCII '\0'. TIL
> * Fix off by one error as per Arvind; I had another off by one error in
>   my test program that was masking this.
> 
>  lib/string.c | 24 
>  1 file changed, 24 insertions(+)
> 
> diff --git a/lib/string.c b/lib/string.c
> index 6012c385fb31..4288e0158d47 100644
> --- a/lib/string.c
> +++ b/lib/string.c
> @@ -272,6 +272,30 @@ ssize_t strscpy_pad(char *dest, const char *src, size_t 
> count)
>  }
>

[PATCH v4 13/17] PCI: Add TI J721E device to pci ids

Add TI J721E device to the pci id database. Since this device has
a configurable PCIe endpoint, it could be used with different
drivers.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/misc/pci_endpoint_test.c | 1 -
 include/linux/pci_ids.h  | 1 +
 2 files changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/misc/pci_endpoint_test.c b/drivers/misc/pci_endpoint_test.c
index e060796f9caa..03fade34aeac 100644
--- a/drivers/misc/pci_endpoint_test.c
+++ b/drivers/misc/pci_endpoint_test.c
@@ -68,7 +68,6 @@
 #define PCI_ENDPOINT_TEST_FLAGS0x2c
 #define FLAG_USE_DMA   BIT(0)
 
-#define PCI_DEVICE_ID_TI_J721E 0xb00d
 #define PCI_DEVICE_ID_TI_AM654 0xb00c
 
 #define is_am654_pci_dev(pdev) \
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index 1ab1e24bcbce..6ddeb64049b5 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -880,6 +880,7 @@
 #define PCI_DEVICE_ID_TI_X620  0xac8d
 #define PCI_DEVICE_ID_TI_X420  0xac8e
 #define PCI_DEVICE_ID_TI_XX20_FM   0xac8f
+#define PCI_DEVICE_ID_TI_J721E 0xb00d
 #define PCI_DEVICE_ID_TI_DRA74x0xb500
 #define PCI_DEVICE_ID_TI_DRA72x0xb501
 
-- 
2.17.1

[PATCH v4 08/17] PCI: endpoint: Add pci_epc_ops to map MSI irq

Add pci_epc_ops to map physical address to MSI address and return MSI
data. The physical address is an address in the outbound region. This is
required to implement doorbell functionality of NTB (non transparent
bridge) wherein EPC on either side of the interface (primary and
secondary) can directly write to the physical address (in outbound
region) of the other interface to ring doorbell using MSI.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/pci/endpoint/pci-epc-core.c | 40 +
 include/linux/pci-epc.h |  7 +
 2 files changed, 47 insertions(+)

diff --git a/drivers/pci/endpoint/pci-epc-core.c 
b/drivers/pci/endpoint/pci-epc-core.c
index 0f6e2364ae6f..73f9ff425824 100644
--- a/drivers/pci/endpoint/pci-epc-core.c
+++ b/drivers/pci/endpoint/pci-epc-core.c
@@ -230,6 +230,46 @@ int pci_epc_raise_irq(struct pci_epc *epc, u8 func_no,
 }
 EXPORT_SYMBOL_GPL(pci_epc_raise_irq);
 
+/**
+ * pci_epc_map_msi_irq() - Map physical address to MSI address and return
+ * MSI data
+ * @epc: the EPC device which has the MSI capability
+ * @func_no: the physical endpoint function number in the EPC device
+ * @vfunc_no: the virtual endpoint function number in the physical function
+ * @phys_addr: the physical address of the outbound region
+ * @interrupt_num: the MSI interrupt number
+ * @entry_size: Size of Outbound address region for each interrupt
+ * @msi_data: the data that should be written in order to raise MSI interrupt
+ *with interrupt number as 'interrupt num'
+ *
+ * Invoke to map physical address to MSI address and return MSI data. The
+ * physical address should be an address in the outbound region. This is
+ * required to implement doorbell functionality of NTB wherein EPC on either
+ * side of the interface (primary and secondary) can directly write to the
+ * physical address (in outbound region) of the other interface to ring
+ * doorbell.
+ */
+int pci_epc_map_msi_irq(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
+   phys_addr_t phys_addr, u8 interrupt_num, u32 entry_size,
+   u32 *msi_data)
+{
+   int ret;
+
+   if (IS_ERR_OR_NULL(epc))
+   return -EINVAL;
+
+   if (!epc->ops->map_msi_irq)
+   return -EINVAL;
+
+   mutex_lock(>lock);
+   ret = epc->ops->map_msi_irq(epc, func_no, vfunc_no, phys_addr,
+   interrupt_num, entry_size, msi_data);
+   mutex_unlock(>lock);
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(pci_epc_map_msi_irq);
+
 /**
  * pci_epc_get_msi() - get the number of MSI interrupt numbers allocated
  * @epc: the EPC device to which MSI interrupts was requested
diff --git a/include/linux/pci-epc.h b/include/linux/pci-epc.h
index d9cb3944fb87..88284f3a0698 100644
--- a/include/linux/pci-epc.h
+++ b/include/linux/pci-epc.h
@@ -55,6 +55,7 @@ pci_epc_interface_string(enum pci_epc_interface_type type)
  * @get_msix: ops to get the number of MSI-X interrupts allocated by the RC
  *  from the MSI-X capability register
  * @raise_irq: ops to raise a legacy, MSI or MSI-X interrupt
+ * @map_msi_irq: ops to map physical address to MSI address and return MSI data
  * @start: ops to start the PCI link
  * @stop: ops to stop the PCI link
  * @owner: the module owner containing the ops
@@ -77,6 +78,9 @@ struct pci_epc_ops {
int (*get_msix)(struct pci_epc *epc, u8 func_no);
int (*raise_irq)(struct pci_epc *epc, u8 func_no,
 enum pci_epc_irq_type type, u16 interrupt_num);
+   int (*map_msi_irq)(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
+  phys_addr_t phys_addr, u8 interrupt_num,
+  u32 entry_size, u32 *msi_data);
int (*start)(struct pci_epc *epc);
void(*stop)(struct pci_epc *epc);
const struct pci_epc_features* (*get_features)(struct pci_epc *epc,
@@ -216,6 +220,9 @@ int pci_epc_get_msi(struct pci_epc *epc, u8 func_no);
 int pci_epc_set_msix(struct pci_epc *epc, u8 func_no, u16 interrupts,
 enum pci_barno, u32 offset);
 int pci_epc_get_msix(struct pci_epc *epc, u8 func_no);
+int pci_epc_map_msi_irq(struct pci_epc *epc, u8 func_no,
+   phys_addr_t phys_addr, u8 interrupt_num,
+   u32 entry_size, u32 *msi_data);
 int pci_epc_raise_irq(struct pci_epc *epc, u8 func_no,
  enum pci_epc_irq_type type, u16 interrupt_num);
 int pci_epc_start(struct pci_epc *epc);
-- 
2.17.1

[PATCH v4 07/17] PCI: endpoint: Add support in configfs to associate two EPCs with EPF

Now that PCI endpoint core supports to add secondary endpoint
controller (EPC) with endpoint function (EPF), Add support in configfs
to associate two EPCs with EPF. This creates "primary" and "secondary"
directory inside the directory created by users for EPF device. Users
have to add a symlink of endpoint controller (pci_ep/controllers/) to
"primary" or "secondary" directory to bind EPF to primary and secondary
EPF interfaces respectively. Existing method of linking directory
representing EPF device to directory representing EPC device to
associate a single EPC device with a EPF device will continue to work.

Signed-off-by: Kishon Vijay Abraham I 
---
 .../PCI/endpoint/pci-endpoint-cfs.rst |  10 ++
 drivers/pci/endpoint/pci-ep-cfs.c | 147 ++
 2 files changed, 157 insertions(+)

diff --git a/Documentation/PCI/endpoint/pci-endpoint-cfs.rst 
b/Documentation/PCI/endpoint/pci-endpoint-cfs.rst
index 1bbd81ed06c8..696f8eeb4738 100644
--- a/Documentation/PCI/endpoint/pci-endpoint-cfs.rst
+++ b/Documentation/PCI/endpoint/pci-endpoint-cfs.rst
@@ -68,6 +68,16 @@ created)
... subsys_vendor_id
... subsys_id
... interrupt_pin
+... primary/
+   ... /
+... secondary/
+   ... /
+
+If an EPF device has to be associated with 2 EPCs (like in the case of
+Non-transparent bridge), symlink of endpoint controller connected to primary
+interface should be added in 'primary' directory and symlink of endpoint
+controller connected to secondary interface should be added in 'secondary'
+directory.
 
 EPC Device
 ==
diff --git a/drivers/pci/endpoint/pci-ep-cfs.c 
b/drivers/pci/endpoint/pci-ep-cfs.c
index 6ca9e2f92460..8f750961d6ab 100644
--- a/drivers/pci/endpoint/pci-ep-cfs.c
+++ b/drivers/pci/endpoint/pci-ep-cfs.c
@@ -21,6 +21,9 @@ static struct config_group *controllers_group;
 
 struct pci_epf_group {
struct config_group group;
+   struct config_group primary_epc_group;
+   struct config_group secondary_epc_group;
+   struct delayed_work cfs_work;
struct pci_epf *epf;
int index;
 };
@@ -41,6 +44,127 @@ static inline struct pci_epc_group *to_pci_epc_group(struct 
config_item *item)
return container_of(to_config_group(item), struct pci_epc_group, group);
 }
 
+static int pci_secondary_epc_epf_link(struct config_item *epf_item,
+ struct config_item *epc_item)
+{
+   int ret;
+   struct pci_epf_group *epf_group = to_pci_epf_group(epf_item->ci_parent);
+   struct pci_epc_group *epc_group = to_pci_epc_group(epc_item);
+   struct pci_epc *epc = epc_group->epc;
+   struct pci_epf *epf = epf_group->epf;
+
+   ret = pci_epc_add_epf(epc, epf, SECONDARY_INTERFACE);
+   if (ret)
+   return ret;
+
+   ret = pci_epf_bind(epf);
+   if (ret) {
+   pci_epc_remove_epf(epc, epf, SECONDARY_INTERFACE);
+   return ret;
+   }
+
+   return 0;
+}
+
+static void pci_secondary_epc_epf_unlink(struct config_item *epc_item,
+struct config_item *epf_item)
+{
+   struct pci_epf_group *epf_group = to_pci_epf_group(epf_item->ci_parent);
+   struct pci_epc_group *epc_group = to_pci_epc_group(epc_item);
+   struct pci_epc *epc;
+   struct pci_epf *epf;
+
+   WARN_ON_ONCE(epc_group->start);
+
+   epc = epc_group->epc;
+   epf = epf_group->epf;
+   pci_epf_unbind(epf);
+   pci_epc_remove_epf(epc, epf, SECONDARY_INTERFACE);
+}
+
+static struct configfs_item_operations pci_secondary_epc_item_ops = {
+   .allow_link = pci_secondary_epc_epf_link,
+   .drop_link  = pci_secondary_epc_epf_unlink,
+};
+
+static const struct config_item_type pci_secondary_epc_type = {
+   .ct_item_ops= _secondary_epc_item_ops,
+   .ct_owner   = THIS_MODULE,
+};
+
+static struct config_group
+*pci_ep_cfs_add_secondary_group(struct pci_epf_group *epf_group)
+{
+   struct config_group *secondary_epc_group;
+
+   secondary_epc_group = _group->secondary_epc_group;
+   config_group_init_type_name(secondary_epc_group, "secondary",
+   _secondary_epc_type);
+   configfs_register_group(_group->group, secondary_epc_group);
+
+   return secondary_epc_group;
+}
+
+static int pci_primary_epc_epf_link(struct config_item *epf_item,
+   struct config_item *epc_item)
+{
+   int ret;
+   struct pci_epf_group *epf_group = to_pci_epf_group(epf_item->ci_parent);
+   struct pci_epc_group *epc_group = to_pci_epc_group(epc_item);
+   struct pci_epc *epc = epc_group->epc;
+   struct pci_epf *epf = epf_group->epf;
+
+   ret = pci_epc_add_epf(epc, epf, PRIMARY_INTERFACE);
+

[PATCH v4 12/17] PCI: endpoint: Add EP function driver to provide NTB functionality

Add a new endpoint function driver to provide NTB functionality
using multiple PCIe endpoint instances.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/pci/endpoint/functions/Kconfig   |   12 +
 drivers/pci/endpoint/functions/Makefile  |1 +
 drivers/pci/endpoint/functions/pci-epf-ntb.c | 2106 ++
 3 files changed, 2119 insertions(+)
 create mode 100644 drivers/pci/endpoint/functions/pci-epf-ntb.c

diff --git a/drivers/pci/endpoint/functions/Kconfig 
b/drivers/pci/endpoint/functions/Kconfig
index 8820d0f7ec77..55ac7bb2d469 100644
--- a/drivers/pci/endpoint/functions/Kconfig
+++ b/drivers/pci/endpoint/functions/Kconfig
@@ -12,3 +12,15 @@ config PCI_EPF_TEST
   for PCI Endpoint.
 
   If in doubt, say "N" to disable Endpoint test driver.
+
+config PCI_EPF_NTB
+   tristate "PCI Endpoint NTB driver"
+   depends on PCI_ENDPOINT
+   help
+  Select this configuration option to enable the NTB driver
+  for PCI Endpoint. NTB driver implements NTB controller
+  functionality using multiple PCIe endpoint instances. It
+  can support NTB endpoint function devices created using
+  device tree.
+
+  If in doubt, say "N" to disable Endpoint NTB driver.
diff --git a/drivers/pci/endpoint/functions/Makefile 
b/drivers/pci/endpoint/functions/Makefile
index d6fafff080e2..96ab932a537a 100644
--- a/drivers/pci/endpoint/functions/Makefile
+++ b/drivers/pci/endpoint/functions/Makefile
@@ -4,3 +4,4 @@
 #
 
 obj-$(CONFIG_PCI_EPF_TEST) += pci-epf-test.o
+obj-$(CONFIG_PCI_EPF_NTB)  += pci-epf-ntb.o
diff --git a/drivers/pci/endpoint/functions/pci-epf-ntb.c 
b/drivers/pci/endpoint/functions/pci-epf-ntb.c
new file mode 100644
index ..e4778b782cd4
--- /dev/null
+++ b/drivers/pci/endpoint/functions/pci-epf-ntb.c
@@ -0,0 +1,2106 @@
+// SPDX-License-Identifier: GPL-2.0
+/**
+ * Endpoint Function Driver to implement Non-Transparent Bridge functionality
+ *
+ * Copyright (C) 2020 Texas Instruments
+ * Author: Kishon Vijay Abraham I 
+ */
+
+/*
+ *The PCI NTB function driver configures the SoC with multiple PCIe 
Endpoint(EP)
+ *controller instances (see diagram below) in such a way that transaction from
+ *one EP controller is routed to the other EP controller. Once PCI NTB function
+ *driver configures the SoC with multiple EP instances, HOST1 and HOST2 can
+ *communicate with each other using SoC as a bridge.
+ *
+ *   +-+   +-+
+ *   | |   | |
+ *   |HOST1|   |HOST2|
+ *   | |   | |
+ *   +--^--+   +--^--+
+ *  | |
+ *  | |
+ *+-|-|-+
+ *|  +--v--+   +--v--+  |
+ *|  | |   | |  |
+ *|  | EP  |   | EP  |  |
+ *|  | CONTROLLER1 |   | CONTROLLER2 |  |
+ *|  | <---> |  |
+ *|  | |   | |  |
+ *|  | |   | |  |
+ *|  | |  SoC With Multiple EP Instances   | |  |
+ *|  | |  (Configured using NTB Function)  | |  |
+ *|  +-+   +-+  |
+ *+-+
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+static struct workqueue_struct *kpcintb_workqueue;
+
+#define COMMAND_CONFIGURE_DOORBELL 1
+#define COMMAND_TEARDOWN_DOORBELL  2
+#define COMMAND_CONFIGURE_MW   3
+#define COMMAND_TEARDOWN_MW4
+#define COMMAND_LINK_UP5
+#define COMMAND_LINK_DOWN  6
+
+#define COMMAND_STATUS_OK  1
+#define COMMAND_STATUS_ERROR   2
+
+#define LINK_STATUS_UP BIT(0)
+
+#define SPAD_COUNT 64
+#define DB_COUNT   4
+#define NTB_MW_OFFSET  2
+#define DB_COUNT_MASK  GENMASK(15, 0)
+#define MSIX_ENABLEBIT(16)
+#define MAX_DB_COUNT   32
+#define MAX_MW 4
+
+enum epf_ntb_bar {
+   BAR_CONFIG,
+   BAR_PEER_SPAD,
+   BAR_DB_MW1,
+   BAR_MW2,
+   BAR_MW3,
+   BAR_MW4,
+};
+
+struct epf_ntb {
+   u32 num_mws;
+   u32 db_count;
+   u32 spad_count;
+   struct pci_epf *epf;
+   u64 mws_size[MAX_MW];
+   struct

[PATCH v4 10/17] PCI: endpoint: Allow user to create sub-directory of 'EPF Device' directory

Documentation/PCI/endpoint/pci-endpoint-cfs.rst explains how a user
has to create a directory in-order to create a 'EPF Device' that
can be configured/probed by 'EPF Driver'.

Allow user to create a sub-directory of 'EPF Device' directory for
any function specific attributes that has to be exposed to the user.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/pci/endpoint/pci-ep-cfs.c | 23 +++
 include/linux/pci-epf.h   |  3 +++
 2 files changed, 26 insertions(+)

diff --git a/drivers/pci/endpoint/pci-ep-cfs.c 
b/drivers/pci/endpoint/pci-ep-cfs.c
index 8f750961d6ab..f3a8b833b479 100644
--- a/drivers/pci/endpoint/pci-ep-cfs.c
+++ b/drivers/pci/endpoint/pci-ep-cfs.c
@@ -490,7 +490,29 @@ static struct configfs_item_operations pci_epf_ops = {
.release= pci_epf_release,
 };
 
+static struct config_group *pci_epf_type_make(struct config_group *group,
+ const char *name)
+{
+   struct pci_epf_group *epf_group = to_pci_epf_group(>cg_item);
+   struct config_group *epf_type_group;
+
+   epf_type_group = pci_epf_type_add_cfs(epf_group->epf, group);
+   return epf_type_group;
+}
+
+static void pci_epf_type_drop(struct config_group *group,
+ struct config_item *item)
+{
+   config_item_put(item);
+}
+
+static struct configfs_group_operations pci_epf_type_group_ops = {
+   .make_group = _epf_type_make,
+   .drop_item  = _epf_type_drop,
+};
+
 static const struct config_item_type pci_epf_type = {
+   .ct_group_ops   = _epf_type_group_ops,
.ct_item_ops= _epf_ops,
.ct_attrs   = pci_epf_attrs,
.ct_owner   = THIS_MODULE,
@@ -553,6 +575,7 @@ static struct config_group *pci_epf_make(struct 
config_group *group,
goto free_name;
}
 
+   epf->group = _group->group;
epf_group->epf = epf;
 
kfree(epf_name);
diff --git a/include/linux/pci-epf.h b/include/linux/pci-epf.h
index b241e7dd171f..6833e2160ef1 100644
--- a/include/linux/pci-epf.h
+++ b/include/linux/pci-epf.h
@@ -9,6 +9,7 @@
 #ifndef __LINUX_PCI_EPF_H
 #define __LINUX_PCI_EPF_H
 
+#include 
 #include 
 #include 
 #include 
@@ -128,6 +129,7 @@ struct pci_epf_bar {
  *   EPC device
  * @sec_epc_bar: represents the BAR of EPF device associated with secondary EPC
  * @sec_epc_func_no: unique (physical) function number within the secondary EPC
+ * @group: configfs group associated with the EPF device
  */
 struct pci_epf {
struct device   dev;
@@ -150,6 +152,7 @@ struct pci_epf {
struct list_headsec_epc_list;
struct pci_epf_bar  sec_epc_bar[6];
u8  sec_epc_func_no;
+   struct config_group *group;
 };
 
 /**
-- 
2.17.1

[PATCH v4 04/17] PCI: endpoint: Make *_free_bar() to return error codes on failure

Modify pci_epc_get_next_free_bar() and pci_epc_get_first_free_bar() to
return error values if there are no free BARs available.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/pci/endpoint/functions/pci-epf-test.c |  2 ++
 drivers/pci/endpoint/pci-epc-core.c   | 12 ++--
 include/linux/pci-epc.h   |  8 
 include/linux/pci-epf.h   |  1 +
 4 files changed, 13 insertions(+), 10 deletions(-)

diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c 
b/drivers/pci/endpoint/functions/pci-epf-test.c
index e4e51d884553..7a1f3abfde48 100644
--- a/drivers/pci/endpoint/functions/pci-epf-test.c
+++ b/drivers/pci/endpoint/functions/pci-epf-test.c
@@ -834,6 +834,8 @@ static int pci_epf_test_bind(struct pci_epf *epf)
linkup_notifier = epc_features->linkup_notifier;
core_init_notifier = epc_features->core_init_notifier;
test_reg_bar = pci_epc_get_first_free_bar(epc_features);
+   if (test_reg_bar < 0)
+   return -EINVAL;
pci_epf_configure_bar(epf, epc_features);
}
 
diff --git a/drivers/pci/endpoint/pci-epc-core.c 
b/drivers/pci/endpoint/pci-epc-core.c
index 1afe5d9afb0d..ea7e7465ce7a 100644
--- a/drivers/pci/endpoint/pci-epc-core.c
+++ b/drivers/pci/endpoint/pci-epc-core.c
@@ -90,8 +90,8 @@ EXPORT_SYMBOL_GPL(pci_epc_get);
  * Invoke to get the first unreserved BAR that can be used by the endpoint
  * function. For any incorrect value in reserved_bar return '0'.
  */
-unsigned int pci_epc_get_first_free_bar(const struct pci_epc_features
-   *epc_features)
+enum pci_barno
+pci_epc_get_first_free_bar(const struct pci_epc_features *epc_features)
 {
return pci_epc_get_next_free_bar(epc_features, BAR_0);
 }
@@ -105,13 +105,13 @@ EXPORT_SYMBOL_GPL(pci_epc_get_first_free_bar);
  * Invoke to get the next unreserved BAR starting from @bar that can be used
  * for endpoint function. For any incorrect value in reserved_bar return '0'.
  */
-unsigned int pci_epc_get_next_free_bar(const struct pci_epc_features
-  *epc_features, enum pci_barno bar)
+enum pci_barno pci_epc_get_next_free_bar(const struct pci_epc_features
+*epc_features, enum pci_barno bar)
 {
unsigned long free_bar;
 
if (!epc_features)
-   return 0;
+   return BAR_0;
 
/* If 'bar - 1' is a 64-bit BAR, move to the next BAR */
if ((epc_features->bar_fixed_64bit << 1) & 1 << bar)
@@ -126,7 +126,7 @@ unsigned int pci_epc_get_next_free_bar(const struct 
pci_epc_features
 
free_bar = find_next_zero_bit(_bar, 6, bar);
if (free_bar > 5)
-   return 0;
+   return NO_BAR;
 
return free_bar;
 }
diff --git a/include/linux/pci-epc.h b/include/linux/pci-epc.h
index cfe9b427e6b7..88d311bad984 100644
--- a/include/linux/pci-epc.h
+++ b/include/linux/pci-epc.h
@@ -201,10 +201,10 @@ int pci_epc_start(struct pci_epc *epc);
 void pci_epc_stop(struct pci_epc *epc);
 const struct pci_epc_features *pci_epc_get_features(struct pci_epc *epc,
u8 func_no);
-unsigned int pci_epc_get_first_free_bar(const struct pci_epc_features
-   *epc_features);
-unsigned int pci_epc_get_next_free_bar(const struct pci_epc_features
-  *epc_features, enum pci_barno bar);
+enum pci_barno
+pci_epc_get_first_free_bar(const struct pci_epc_features *epc_features);
+enum pci_barno pci_epc_get_next_free_bar(const struct pci_epc_features
+*epc_features, enum pci_barno bar);
 struct pci_epc *pci_epc_get(const char *epc_name);
 void pci_epc_put(struct pci_epc *epc);
 
diff --git a/include/linux/pci-epf.h b/include/linux/pci-epf.h
index 6644ff3b0702..fa3aca43eb19 100644
--- a/include/linux/pci-epf.h
+++ b/include/linux/pci-epf.h
@@ -21,6 +21,7 @@ enum pci_notify_event {
 };
 
 enum pci_barno {
+   NO_BAR = -1,
BAR_0,
BAR_1,
BAR_2,
-- 
2.17.1

[PATCH v4 00/17] Implement NTB Controller using multiple PCI EP

This series is about implementing SW defined NTB using
multiple endpoint instances. This series has been tested using
2 endpoint instances in J7 connected to J7 board on one end and DRA7 board
on the other end. However there is nothing platform specific for the NTB
functionality.

This was presented in Linux Plumbers Conference. The presentation
can be found @ [1]

RFC patch series can be found @ [2]
v1 patch series can be found @ [3]
v2 patch series can be found @ [4]
v3 patch series can be found @ [5]

Changes from v3:
1) Fixed Documentation edits suggested by Randy Dunlap 

Changes from v2:
1) Add support for the user to create sub-directory of 'EPF Device'
   directory (for endpoint function specific configuration using
   configfs).
2) Add documentation for NTB specific attributes in configfs
3) Check for PCI_CLASS_MEMORY_RAM (PCIe class) before binding ntb_hw_epf
   driver
4) Other documentation fixes

Changes from v1:
1) As per Rob's comment, removed support for creating NTB function
   device from DT
2) Add support to create NTB EPF device using configfs (added support in
   configfs to associate primary and secondary EPC with EPF.

Changes from RFC:
1) Converted the DT binding patches to YAML schema and merged the
   DT binding patches together
2) NTB documentation is converted to .rst
3) One HOST can now interrupt the other HOST using MSI-X interrupts
4) Added support for teardown of memory window and doorbell
   configuration
5) Add support to provide support 64-bit memory window size from
   DT

[1] -> 
https://www.linuxplumbersconf.org/event/4/contributions/395/attachments/284/481/Implementing_NTB_Controller_Using_PCIe_Endpoint_-_final.pdf
[2] -> http://lore.kernel.org/r/20190926112933.8922-1-kis...@ti.com
[3] -> http://lore.kernel.org/r/20200514145927.17555-1-kis...@ti.com
[4] -> http://lore.kernel.org/r/20200611130525.22746-1-kis...@ti.com
[5] -> http://lore.kernel.org/r/20200904075052.8911-1-kis...@ti.com

Kishon Vijay Abraham I (17):
  Documentation: PCI: Add specification for the *PCI NTB* function
device
  PCI: endpoint: Make *_get_first_free_bar() take into account 64 bit
BAR
  PCI: endpoint: Add helper API to get the 'next' unreserved BAR
  PCI: endpoint: Make *_free_bar() to return error codes on failure
  PCI: endpoint: Remove unused pci_epf_match_device()
  PCI: endpoint: Add support to associate secondary EPC with EPF
  PCI: endpoint: Add support in configfs to associate two EPCs with EPF
  PCI: endpoint: Add pci_epc_ops to map MSI irq
  PCI: endpoint: Add pci_epf_ops for epf drivers to expose function
specific attrs
  PCI: endpoint: Allow user to create sub-directory of 'EPF Device'
directory
  PCI: cadence: Implement ->msi_map_irq() ops
  PCI: endpoint: Add EP function driver to provide NTB functionality
  PCI: Add TI J721E device to pci ids
  NTB: Add support for EPF PCI-Express Non-Transparent Bridge
  NTB: tool: Enable the NTB/PCIe link on the local or remote side of
bridge
  Documentation: PCI: Add binding documentation for pci-ntb endpoint
function
  Documentation: PCI: Add userguide for PCI endpoint NTB function

 .../PCI/endpoint/function/binding/pci-ntb.rst |   38 +
 Documentation/PCI/endpoint/index.rst  |3 +
 .../PCI/endpoint/pci-endpoint-cfs.rst |   10 +
 .../PCI/endpoint/pci-ntb-function.rst |  351 +++
 Documentation/PCI/endpoint/pci-ntb-howto.rst  |  160 ++
 drivers/misc/pci_endpoint_test.c  |1 -
 drivers/ntb/hw/Kconfig|1 +
 drivers/ntb/hw/Makefile   |1 +
 drivers/ntb/hw/epf/Kconfig|6 +
 drivers/ntb/hw/epf/Makefile   |1 +
 drivers/ntb/hw/epf/ntb_hw_epf.c   |  751 ++
 drivers/ntb/test/ntb_tool.c   |1 +
 .../pci/controller/cadence/pcie-cadence-ep.c  |   50 +
 drivers/pci/endpoint/functions/Kconfig|   12 +
 drivers/pci/endpoint/functions/Makefile   |1 +
 drivers/pci/endpoint/functions/pci-epf-ntb.c  | 2106 +
 drivers/pci/endpoint/functions/pci-epf-test.c |   13 +-
 drivers/pci/endpoint/pci-ep-cfs.c |  176 +-
 drivers/pci/endpoint/pci-epc-core.c   |  131 +-
 drivers/pci/endpoint/pci-epf-core.c   |  105 +-
 include/linux/pci-epc.h   |   38 +-
 include/linux/pci-epf.h   |   28 +-
 include/linux/pci_ids.h   |1 +
 23 files changed, 3918 insertions(+), 67 deletions(-)
 create mode 100644 Documentation/PCI/endpoint/function/binding/pci-ntb.rst
 create mode 100644 Documentation/PCI/endpoint/pci-ntb-function.rst
 create mode 100644 Documentation/PCI/endpoint/pci-ntb-howto.rst
 create mode 100644 drivers/ntb/hw/epf/Kconfig
 create mode 100644 drivers/ntb/hw/epf/Makefile
 create mode 100644 drivers/ntb/hw/epf/ntb_hw_epf.c
 create mode 100644 drivers/pci/endpoint/functions/pci-epf-ntb.c

-- 
2.17.1

[PATCH v4 01/17] Documentation: PCI: Add specification for the PCI NTB function device

Add specification for the *PCI NTB* function device. The endpoint function
driver and the host PCI driver should be created based on this
specification.

Signed-off-by: Kishon Vijay Abraham I 
---
 Documentation/PCI/endpoint/index.rst  |   1 +
 .../PCI/endpoint/pci-ntb-function.rst | 351 ++
 2 files changed, 352 insertions(+)
 create mode 100644 Documentation/PCI/endpoint/pci-ntb-function.rst

diff --git a/Documentation/PCI/endpoint/index.rst 
b/Documentation/PCI/endpoint/index.rst
index 4ca7439fbfc9..ef6861128506 100644
--- a/Documentation/PCI/endpoint/index.rst
+++ b/Documentation/PCI/endpoint/index.rst
@@ -11,5 +11,6 @@ PCI Endpoint Framework
pci-endpoint-cfs
pci-test-function
pci-test-howto
+   pci-ntb-function
 
function/binding/pci-test
diff --git a/Documentation/PCI/endpoint/pci-ntb-function.rst 
b/Documentation/PCI/endpoint/pci-ntb-function.rst
new file mode 100644
index ..f7246c812801
--- /dev/null
+++ b/Documentation/PCI/endpoint/pci-ntb-function.rst
@@ -0,0 +1,351 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=
+PCI NTB Function
+=
+
+:Author: Kishon Vijay Abraham I 
+
+PCI Non Transparent Bridges (NTB) allow two host systems to communicate
+with each other by exposing each host as a device to the other host.
+NTBs typically support the ability to generate interrupts on the remote
+machine, expose memory ranges as BARs and perform DMA.  They also support
+scratchpads which are areas of memory within the NTB that are accessible
+from both machines.
+
+PCI NTB Function allows two different systems (or hosts) to communicate
+with each other by configurig the endpoint instances in such a way that
+transactions from one system is routed to the other system.
+
+In the below diagram, PCI NTB function configures the SoC with multiple
+PCIe Endpoint (EP) instances in such a way that transaction from one EP
+controller is routed to the other EP controller. Once PCI NTB function
+configures the SoC with multiple EP instances, HOST1 and HOST2 can
+communicate with each other using SoC as a bridge.
+
+.. code-block:: text
+
++-+   +-+
+| |   | |
+|HOST1|   |HOST2|
+| |   | |
++--^--+   +--^--+
+   | |
+   | |
+ +-|-|-+
+ |  +--v--+   +--v--+  |
+ |  | |   | |  |
+ |  | EP  |   | EP  |  |
+ |  | CONTROLLER1 |   | CONTROLLER2 |  |
+ |  | <---> |  |
+ |  | |   | |  |
+ |  | |   | |  |
+ |  | |  SoC With Multiple EP Instances   | |  |
+ |  | |  (Configured using NTB Function)  | |  |
+ |  +-+   +-+  |
+ +-+
+
+Constructs used for Implementing NTB
+
+
+   1) Config Region
+   2) Self Scratchpad Registers
+   3) Peer Scratchpad Registers
+   4) Doorbell Registers
+   5) Memory Window
+
+
+Config Region:
+--
+
+Config Region is a construct that is specific to NTB implemented using NTB
+Endpoint Function Driver. The host and endpoint side NTB function driver will
+exchange information with each other using this region. Config Region has
+Control/Status Registers for configuring the Endpoint Controller. Host can
+write into this region for configuring the outbound ATU and to indicate the
+link status. Endpoint can indicate the status of commands issued be host in
+this region. Endpoint can also indicate the scratchpad offset, number of
+memory windows to the host using this region.
+
+The format of Config Region is given below. Each of the fields here are 32
+bits.
+
+.. code-block:: text
+
+   ++
+   | COMMAND|
+   ++
+   | ARGUMENT   |
+   ++
+   | STATUS |
+   ++
+   | TOPOLOGY   |
+   ++
+   |ADDRESS (LOWER 32)  |
+   ++
+   |ADDRESS (UPPER 32)  |
+   ++
+   |   SIZE |
+

[PATCH v4 06/17] PCI: endpoint: Add support to associate secondary EPC with EPF

In the case of standard endpoint functions, only one endpoint
controller (EPC) will be associated with an endpoint function
(EPF). However for providing NTB (non transparent bridge)
functionality, two EPCs should be associated with a single EPF.
Add support to associate secondary EPC with EPF. This is in
preparation for adding NTB endpoint function driver.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/pci/endpoint/functions/pci-epf-test.c | 11 ++--
 drivers/pci/endpoint/pci-ep-cfs.c |  6 +-
 drivers/pci/endpoint/pci-epc-core.c   | 50 
 drivers/pci/endpoint/pci-epf-core.c   | 57 +--
 include/linux/pci-epc.h   | 25 +++-
 include/linux/pci-epf.h   | 17 +-
 6 files changed, 128 insertions(+), 38 deletions(-)

diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c 
b/drivers/pci/endpoint/functions/pci-epf-test.c
index 7a1f3abfde48..c0ac4e9cbe72 100644
--- a/drivers/pci/endpoint/functions/pci-epf-test.c
+++ b/drivers/pci/endpoint/functions/pci-epf-test.c
@@ -619,7 +619,8 @@ static void pci_epf_test_unbind(struct pci_epf *epf)
 
if (epf_test->reg[bar]) {
pci_epc_clear_bar(epc, epf->func_no, epf_bar);
-   pci_epf_free_space(epf, epf_test->reg[bar], bar);
+   pci_epf_free_space(epf, epf_test->reg[bar], bar,
+  PRIMARY_INTERFACE);
}
}
 }
@@ -651,7 +652,8 @@ static int pci_epf_test_set_bar(struct pci_epf *epf)
 
ret = pci_epc_set_bar(epc, epf->func_no, epf_bar);
if (ret) {
-   pci_epf_free_space(epf, epf_test->reg[bar], bar);
+   pci_epf_free_space(epf, epf_test->reg[bar], bar,
+  PRIMARY_INTERFACE);
dev_err(dev, "Failed to set BAR%d\n", bar);
if (bar == test_reg_bar)
return ret;
@@ -771,7 +773,7 @@ static int pci_epf_test_alloc_space(struct pci_epf *epf)
}
 
base = pci_epf_alloc_space(epf, test_reg_size, test_reg_bar,
-  epc_features->align);
+  epc_features->align, PRIMARY_INTERFACE);
if (!base) {
dev_err(dev, "Failed to allocated register space\n");
return -ENOMEM;
@@ -789,7 +791,8 @@ static int pci_epf_test_alloc_space(struct pci_epf *epf)
continue;
 
base = pci_epf_alloc_space(epf, bar_size[bar], bar,
-  epc_features->align);
+  epc_features->align,
+  PRIMARY_INTERFACE);
if (!base)
dev_err(dev, "Failed to allocate space for BAR%d\n",
bar);
diff --git a/drivers/pci/endpoint/pci-ep-cfs.c 
b/drivers/pci/endpoint/pci-ep-cfs.c
index 3710adf51912..6ca9e2f92460 100644
--- a/drivers/pci/endpoint/pci-ep-cfs.c
+++ b/drivers/pci/endpoint/pci-ep-cfs.c
@@ -94,13 +94,13 @@ static int pci_epc_epf_link(struct config_item *epc_item,
struct pci_epc *epc = epc_group->epc;
struct pci_epf *epf = epf_group->epf;
 
-   ret = pci_epc_add_epf(epc, epf);
+   ret = pci_epc_add_epf(epc, epf, PRIMARY_INTERFACE);
if (ret)
return ret;
 
ret = pci_epf_bind(epf);
if (ret) {
-   pci_epc_remove_epf(epc, epf);
+   pci_epc_remove_epf(epc, epf, PRIMARY_INTERFACE);
return ret;
}
 
@@ -120,7 +120,7 @@ static void pci_epc_epf_unlink(struct config_item *epc_item,
epc = epc_group->epc;
epf = epf_group->epf;
pci_epf_unbind(epf);
-   pci_epc_remove_epf(epc, epf);
+   pci_epc_remove_epf(epc, epf, PRIMARY_INTERFACE);
 }
 
 static struct configfs_item_operations pci_epc_item_ops = {
diff --git a/drivers/pci/endpoint/pci-epc-core.c 
b/drivers/pci/endpoint/pci-epc-core.c
index ea7e7465ce7a..0f6e2364ae6f 100644
--- a/drivers/pci/endpoint/pci-epc-core.c
+++ b/drivers/pci/endpoint/pci-epc-core.c
@@ -493,22 +493,32 @@ EXPORT_SYMBOL_GPL(pci_epc_write_header);
  * pci_epc_add_epf() - bind PCI endpoint function to an endpoint controller
  * @epc: the EPC device to which the endpoint function should be added
  * @epf: the endpoint function to be added
+ * @type: Identifies if the EPC is connected to the primary or secondary
+ *interface of EPF
  *
  * A PCI endpoint device can have one or more functions. In the case of PCIe,
  * the specification allows up to 8 PCIe endpoint functions. Invoke
  * pci_epc_add_epf() to add a PCI endpoint function to an endpoint controller.
  */
-int pci_epc_add_epf(struct pci_epc *epc, struct pci_epf *epf)
+int pci_epc_add_epf(struct pci_epc *epc, struct pci_epf *epf,
+   enum

[PATCH v4 03/17] PCI: endpoint: Add helper API to get the 'next' unreserved BAR

Add an API to get the next unreserved BAR starting from a given BAR
number that can be used by the endpoint function.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/pci/endpoint/pci-epc-core.c | 26 ++
 include/linux/pci-epc.h |  2 ++
 2 files changed, 24 insertions(+), 4 deletions(-)

diff --git a/drivers/pci/endpoint/pci-epc-core.c 
b/drivers/pci/endpoint/pci-epc-core.c
index 25e57672e1a1..1afe5d9afb0d 100644
--- a/drivers/pci/endpoint/pci-epc-core.c
+++ b/drivers/pci/endpoint/pci-epc-core.c
@@ -87,17 +87,36 @@ EXPORT_SYMBOL_GPL(pci_epc_get);
  * pci_epc_get_first_free_bar() - helper to get first unreserved BAR
  * @epc_features: pci_epc_features structure that holds the reserved bar bitmap
  *
- * Invoke to get the first unreserved BAR that can be used for endpoint
+ * Invoke to get the first unreserved BAR that can be used by the endpoint
  * function. For any incorrect value in reserved_bar return '0'.
  */
 unsigned int pci_epc_get_first_free_bar(const struct pci_epc_features
*epc_features)
+{
+   return pci_epc_get_next_free_bar(epc_features, BAR_0);
+}
+EXPORT_SYMBOL_GPL(pci_epc_get_first_free_bar);
+
+/**
+ * pci_epc_get_next_free_bar() - helper to get unreserved BAR starting from 
@bar
+ * @epc_features: pci_epc_features structure that holds the reserved bar bitmap
+ * @bar: the starting BAR number from where unreserved BAR should be searched
+ *
+ * Invoke to get the next unreserved BAR starting from @bar that can be used
+ * for endpoint function. For any incorrect value in reserved_bar return '0'.
+ */
+unsigned int pci_epc_get_next_free_bar(const struct pci_epc_features
+  *epc_features, enum pci_barno bar)
 {
unsigned long free_bar;
 
if (!epc_features)
return 0;
 
+   /* If 'bar - 1' is a 64-bit BAR, move to the next BAR */
+   if ((epc_features->bar_fixed_64bit << 1) & 1 << bar)
+   bar++;
+
/* Find if the reserved BAR is also a 64-bit BAR */
free_bar = epc_features->reserved_bar & epc_features->bar_fixed_64bit;
 
@@ -105,14 +124,13 @@ unsigned int pci_epc_get_first_free_bar(const struct 
pci_epc_features
free_bar <<= 1;
free_bar |= epc_features->reserved_bar;
 
-   /* Now find the free BAR */
-   free_bar = ffz(free_bar);
+   free_bar = find_next_zero_bit(_bar, 6, bar);
if (free_bar > 5)
return 0;
 
return free_bar;
 }
-EXPORT_SYMBOL_GPL(pci_epc_get_first_free_bar);
+EXPORT_SYMBOL_GPL(pci_epc_get_next_free_bar);
 
 /**
  * pci_epc_get_features() - get the features supported by EPC
diff --git a/include/linux/pci-epc.h b/include/linux/pci-epc.h
index cc66bec8be90..cfe9b427e6b7 100644
--- a/include/linux/pci-epc.h
+++ b/include/linux/pci-epc.h
@@ -203,6 +203,8 @@ const struct pci_epc_features *pci_epc_get_features(struct 
pci_epc *epc,
u8 func_no);
 unsigned int pci_epc_get_first_free_bar(const struct pci_epc_features
*epc_features);
+unsigned int pci_epc_get_next_free_bar(const struct pci_epc_features
+  *epc_features, enum pci_barno bar);
 struct pci_epc *pci_epc_get(const char *epc_name);
 void pci_epc_put(struct pci_epc *epc);
 
-- 
2.17.1

[PATCH v4 05/17] PCI: endpoint: Remove unused pci_epf_match_device()

Remove unused pci_epf_match_device() function added in pci-epf-core.c

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/pci/endpoint/pci-epf-core.c | 16 
 include/linux/pci-epf.h |  2 --
 2 files changed, 18 deletions(-)

diff --git a/drivers/pci/endpoint/pci-epf-core.c 
b/drivers/pci/endpoint/pci-epf-core.c
index c977cf9dce56..e44a317a2a2a 100644
--- a/drivers/pci/endpoint/pci-epf-core.c
+++ b/drivers/pci/endpoint/pci-epf-core.c
@@ -282,22 +282,6 @@ struct pci_epf *pci_epf_create(const char *name)
 }
 EXPORT_SYMBOL_GPL(pci_epf_create);
 
-const struct pci_epf_device_id *
-pci_epf_match_device(const struct pci_epf_device_id *id, struct pci_epf *epf)
-{
-   if (!id || !epf)
-   return NULL;
-
-   while (*id->name) {
-   if (strcmp(epf->name, id->name) == 0)
-   return id;
-   id++;
-   }
-
-   return NULL;
-}
-EXPORT_SYMBOL_GPL(pci_epf_match_device);
-
 static void pci_epf_dev_release(struct device *dev)
 {
struct pci_epf *epf = to_pci_epf(dev);
diff --git a/include/linux/pci-epf.h b/include/linux/pci-epf.h
index fa3aca43eb19..f373a134ac04 100644
--- a/include/linux/pci-epf.h
+++ b/include/linux/pci-epf.h
@@ -165,8 +165,6 @@ static inline void *epf_get_drvdata(struct pci_epf *epf)
return dev_get_drvdata(>dev);
 }
 
-const struct pci_epf_device_id *
-pci_epf_match_device(const struct pci_epf_device_id *id, struct pci_epf *epf);
 struct pci_epf *pci_epf_create(const char *name);
 void pci_epf_destroy(struct pci_epf *epf);
 int __pci_epf_register_driver(struct pci_epf_driver *driver,
-- 
2.17.1

[PATCH v4 02/17] PCI: endpoint: Make *_get_first_free_bar() take into account 64 bit BAR

pci_epc_get_first_free_bar() uses only "reserved_bar" member in
epc_features to get the first unreserved BAR. However if the
reserved BAR is also a 64-bit BAR, then the next BAR shouldn't be
returned (since 64-bit BAR uses two BARs).

Make pci_epc_get_first_free_bar() take into account 64 bit BAR while
returning the first free unreserved BAR.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/pci/endpoint/pci-epc-core.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/endpoint/pci-epc-core.c 
b/drivers/pci/endpoint/pci-epc-core.c
index cadd3db0cbb0..25e57672e1a1 100644
--- a/drivers/pci/endpoint/pci-epc-core.c
+++ b/drivers/pci/endpoint/pci-epc-core.c
@@ -93,12 +93,20 @@ EXPORT_SYMBOL_GPL(pci_epc_get);
 unsigned int pci_epc_get_first_free_bar(const struct pci_epc_features
*epc_features)
 {
-   int free_bar;
+   unsigned long free_bar;
 
if (!epc_features)
return 0;
 
-   free_bar = ffz(epc_features->reserved_bar);
+   /* Find if the reserved BAR is also a 64-bit BAR */
+   free_bar = epc_features->reserved_bar & epc_features->bar_fixed_64bit;
+
+   /* Set the adjacent bit if the reserved BAR is also a 64-bit BAR */
+   free_bar <<= 1;
+   free_bar |= epc_features->reserved_bar;
+
+   /* Now find the free BAR */
+   free_bar = ffz(free_bar);
if (free_bar > 5)
return 0;
 
-- 
2.17.1

Re: linux-next: build warning after merge of the akpm-current tree

2020-09-14 Thread Stephen Rothwell

Hi David,

On Tue, 15 Sep 2020 12:03:08 +0800 David Gow  wrote:
>
> > drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c: In function 
> > 'common_nfc_set_geometry':
> > drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c:514:3: warning: initialization 
> > discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
> >   514 |   nanddev_get_ecc_requirements(>base);
> >   |   ^~~~
> >  
> 
> I was unable to reproduce this warning: it looks unrelated, so I'm
> assuming it was attributed.

Yeah, sorry, that was included by accident.

-- 
Cheers,
Stephen Rothwell


pgp69D8trCJ15.pgp
Description: OpenPGP digital signature

Re: linux-next: build warning after merge of the akpm-current tree

[+kasan-dev, +kunit-dev]

On Mon, Sep 14, 2020 at 3:01 PM Stephen Rothwell  wrote:
>
> Hi all,
>
> After merging the akpm-current tree, today's linux-next build (x86_64
> allmodconfig) produced this warning:
>
> In file included from lib/test_kasan_module.c:16:
> lib/../mm/kasan/kasan.h:232:6: warning: conflicting types for built-in 
> function '__asan_register_globals'; expected 'void(void *, long int)' 
> [-Wbuiltin-declaration-mismatch]
>   232 | void __asan_register_globals(struct kasan_global *globals, size_t 
> size);
>   |  ^~~
> lib/../mm/kasan/kasan.h:233:6: warning: conflicting types for built-in 
> function '__asan_unregister_globals'; expected 'void(void *, long int)' 
> [-Wbuiltin-declaration-mismatch]
>   233 | void __asan_unregister_globals(struct kasan_global *globals, size_t 
> size);
>   |  ^
> lib/../mm/kasan/kasan.h:235:6: warning: conflicting types for built-in 
> function '__asan_alloca_poison'; expected 'void(void *, long int)' 
> [-Wbuiltin-declaration-mismatch]
>   235 | void __asan_alloca_poison(unsigned long addr, size_t size);
>   |  ^~~~
> lib/../mm/kasan/kasan.h:236:6: warning: conflicting types for built-in 
> function '__asan_allocas_unpoison'; expected 'void(void *, long int)' 
> [-Wbuiltin-declaration-mismatch]
>   236 | void __asan_allocas_unpoison(const void *stack_top, const void 
> *stack_bottom);
>   |  ^~~
> lib/../mm/kasan/kasan.h:238:6: warning: conflicting types for built-in 
> function '__asan_load1'; expected 'void(void *)' 
> [-Wbuiltin-declaration-mismatch]
>   238 | void __asan_load1(unsigned long addr);
>   |  ^~~~
[...some more similar warnings truncated...]

Whoops -- these are an issue with the patch: the test_kasan_module.c
file should be built with -fno-builtin. I've out a new version of the
series which fixes this:
https://lore.kernel.org/linux-mm/20200915035828.570483-1-david...@google.com/T/#t

Basically, the fix is just:

diff --git a/lib/Makefile b/lib/Makefile
index 8c94cad26db7..d4af75136c54 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -69,6 +69,7 @@ obj-$(CONFIG_KASAN_KUNIT_TEST) += test_kasan.o
 CFLAGS_test_kasan.o += -fno-builtin
 CFLAGS_test_kasan.o += $(call cc-disable-warning, vla)
 obj-$(CONFIG_TEST_KASAN_MODULE) += test_kasan_module.o
+CFLAGS_test_kasan_module.o += -fno-builtin
 obj-$(CONFIG_TEST_UBSAN) += test_ubsan.o
 CFLAGS_test_ubsan.o += $(call cc-disable-warning, vla)
 UBSAN_SANITIZE_test_ubsan.o := y
-- 
2.28.0.618.gf4bc123cb7-goog


> drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c: In function 
> 'common_nfc_set_geometry':
> drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c:514:3: warning: initialization 
> discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
>   514 |   nanddev_get_ecc_requirements(>base);
>   |   ^~~~
>

I was unable to reproduce this warning: it looks unrelated, so I'm
assuming it was attributed.

> Introduced by commit
>
>   77e7d1c8c356 ("KASAN: Port KASAN Tests to KUnit")
>
> --
> Cheers,
> Stephen Rothwell

Sorry for the mess,
-- David

[PATCH v14 2/5] KUnit: KASAN Integration

From: Patricia Alfonso 

Integrate KASAN into KUnit testing framework.
- Fail tests when KASAN reports an error that is not expected
- Use KUNIT_EXPECT_KASAN_FAIL to expect a KASAN error in KASAN
tests
- Expected KASAN reports pass tests and are still printed when run
without kunit_tool (kunit_tool still bypasses the report due to the
test passing)
- KUnit struct in current task used to keep track of the current
test from KASAN code

Make use of "[PATCH v3 kunit-next 1/2] kunit: generalize
kunit_resource API beyond allocated resources" and "[PATCH v3
kunit-next 2/2] kunit: add support for named resources" from Alan
Maguire [1]
- A named resource is added to a test when a KASAN report is
 expected
- This resource contains a struct for kasan_data containing
booleans representing if a KASAN report is expected and if a
KASAN report is found

[1] 
(https://lore.kernel.org/linux-kselftest/1583251361-12748-1-git-send-email-alan.magu...@oracle.com/T/#t)

Signed-off-by: Patricia Alfonso 
Signed-off-by: David Gow 
Reviewed-by: Andrey Konovalov 
Reviewed-by: Dmitry Vyukov 
Acked-by: Brendan Higgins 
Tested-by: Andrey Konovalov 
---
 include/kunit/test.h  |  5 +
 include/linux/kasan.h |  6 ++
 lib/kunit/test.c  | 13 +++-
 lib/test_kasan.c  | 47 +--
 mm/kasan/report.c | 32 +
 5 files changed, 96 insertions(+), 7 deletions(-)

diff --git a/include/kunit/test.h b/include/kunit/test.h
index 59f3144f009a..3391f38389f8 100644
--- a/include/kunit/test.h
+++ b/include/kunit/test.h
@@ -224,6 +224,11 @@ struct kunit {
struct list_head resources; /* Protected by lock. */
 };
 
+static inline void kunit_set_failure(struct kunit *test)
+{
+   WRITE_ONCE(test->success, false);
+}
+
 void kunit_init_test(struct kunit *test, const char *name, char *log);
 
 int kunit_run_tests(struct kunit_suite *suite);
diff --git a/include/linux/kasan.h b/include/linux/kasan.h
index 087fba34b209..30d343b4a40a 100644
--- a/include/linux/kasan.h
+++ b/include/linux/kasan.h
@@ -14,6 +14,12 @@ struct task_struct;
 #include 
 #include 
 
+/* kasan_data struct is used in KUnit tests for KASAN expected failures */
+struct kunit_kasan_expectation {
+   bool report_expected;
+   bool report_found;
+};
+
 extern unsigned char kasan_early_shadow_page[PAGE_SIZE];
 extern pte_t kasan_early_shadow_pte[PTRS_PER_PTE];
 extern pmd_t kasan_early_shadow_pmd[PTRS_PER_PMD];
diff --git a/lib/kunit/test.c b/lib/kunit/test.c
index c36037200310..dcc35fd30d95 100644
--- a/lib/kunit/test.c
+++ b/lib/kunit/test.c
@@ -10,16 +10,12 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "debugfs.h"
 #include "string-stream.h"
 #include "try-catch-impl.h"
 
-static void kunit_set_failure(struct kunit *test)
-{
-   WRITE_ONCE(test->success, false);
-}
-
 static void kunit_print_tap_version(void)
 {
static bool kunit_has_printed_tap_version;
@@ -288,6 +284,10 @@ static void kunit_try_run_case(void *data)
struct kunit_suite *suite = ctx->suite;
struct kunit_case *test_case = ctx->test_case;
 
+#if (IS_ENABLED(CONFIG_KASAN) && IS_ENABLED(CONFIG_KUNIT))
+   current->kunit_test = test;
+#endif /* IS_ENABLED(CONFIG_KASAN) && IS_ENABLED(CONFIG_KUNIT) */
+
/*
 * kunit_run_case_internal may encounter a fatal error; if it does,
 * abort will be called, this thread will exit, and finally the parent
@@ -602,6 +602,9 @@ void kunit_cleanup(struct kunit *test)
spin_unlock(>lock);
kunit_remove_resource(test, res);
}
+#if (IS_ENABLED(CONFIG_KASAN) && IS_ENABLED(CONFIG_KUNIT))
+   current->kunit_test = NULL;
+#endif /* IS_ENABLED(CONFIG_KASAN) && IS_ENABLED(CONFIG_KUNIT)*/
 }
 EXPORT_SYMBOL_GPL(kunit_cleanup);
 
diff --git a/lib/test_kasan.c b/lib/test_kasan.c
index 53e953bb1d1d..58bffadd8367 100644
--- a/lib/test_kasan.c
+++ b/lib/test_kasan.c
@@ -23,6 +23,8 @@
 
 #include 
 
+#include 
+
 #include "../mm/kasan/kasan.h"
 
 #define OOB_TAG_OFF (IS_ENABLED(CONFIG_KASAN_GENERIC) ? 0 : 
KASAN_SHADOW_SCALE_SIZE)
@@ -32,14 +34,55 @@
  * are not eliminated as dead code.
  */
 
-int kasan_int_result;
 void *kasan_ptr_result;
+int kasan_int_result;
+
+static struct kunit_resource resource;
+static struct kunit_kasan_expectation fail_data;
+static bool multishot;
+
+static int kasan_test_init(struct kunit *test)
+{
+   /*
+* Temporarily enable multi-shot mode and set panic_on_warn=0.
+* Otherwise, we'd only get a report for the first case.
+*/
+   multishot = kasan_save_enable_multi_shot();
+
+   return 0;
+}
+
+static void kasan_test_exit(struct kunit *test)
+{
+   kasan_restore_multi_shot(multishot);
+}
+
+/**
+ * KUNIT_EXPECT_KASAN_FAIL() - Causes a test failure when the expression does
+ * not cause a KASAN error. This uses a KUnit resource

Re: [PATCH v2 3/4] fpga: dfl: fix the comments of type & feature_id fields

On Tue, Sep 15, 2020 at 11:27:52AM +0800, Xu Yilun wrote:
> The description of feature_id in struct dfl_device is not accurate. In
> DFL specification the feature_id is the 12 bits field. The description
> in struct dfl_device_id is more clear so we make them aligned. We also
> made the similar fix for the type field.
> 
> Signed-off-by: Xu Yilun 
> ---
>  drivers/fpga/dfl.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/fpga/dfl.h b/drivers/fpga/dfl.h
> index 3c69596..d5e050a 100644
> --- a/drivers/fpga/dfl.h
> +++ b/drivers/fpga/dfl.h
> @@ -531,8 +531,8 @@ enum dfl_id_type {
>   *
>   * @dev: generic device interface.
>   * @id: id of the dfl device.
> - * @type: type of DFL FIU of the device. See enum dfl_id_type.
> - * @feature_id: 16 bits feature identifier local to its DFL FIU type.
> + * @type: contains 4 bits DFL FIU type of the device. See enum dfl_id_type.
> + * @feature_id: contains 12 bits feature identifier local to its DFL FIU 
> type.
>   * @mmio_res: mmio resource of this dfl device.
>   * @irqs: list of Linux IRQ numbers of this dfl device.
>   * @num_irqs: number of IRQs supported by this dfl device.
> -- 
> 2.7.4
> 

Applied to for-next,

Thanks

Re: [PATCH v2 2/4] dfl: add dfl bus support to MODULE_DEVICE_TABLE()

On Tue, Sep 15, 2020 at 11:27:51AM +0800, Xu Yilun wrote:
> Device Feature List (DFL) is a linked list of feature headers within the
> device MMIO space. It is used by FPGA to enumerate multiple sub features
> within it. Each feature can be uniquely identified by DFL type and
> feature id, which can be read out from feature headers.
> 
> A dfl bus helps DFL framework modularize DFL device drivers for different
> sub features. The dfl bus matches its devices and drivers by DFL type and
> feature id.
> 
> This patch add dfl bus support to MODULE_DEVICE_TABLE() by adding info
> about struct dfl_device_id in devicetable-offsets.c and add a dfl entry
> point in file2alias.c.
> 
> Signed-off-by: Xu Yilun 
> Signed-off-by: Wu Hao 
> Signed-off-by: Matthew Gerlach 
> Signed-off-by: Russ Weight 
> Acked-by: Wu Hao 
> ---
> v2: add comments for the format of modalias
> ---
>  scripts/mod/devicetable-offsets.c |  4 
>  scripts/mod/file2alias.c  | 17 +
>  2 files changed, 21 insertions(+)
> 
> diff --git a/scripts/mod/devicetable-offsets.c 
> b/scripts/mod/devicetable-offsets.c
> index 27007c1..d8350ee 100644
> --- a/scripts/mod/devicetable-offsets.c
> +++ b/scripts/mod/devicetable-offsets.c
> @@ -243,5 +243,9 @@ int main(void)
>   DEVID(mhi_device_id);
>   DEVID_FIELD(mhi_device_id, chan);
>  
> + DEVID(dfl_device_id);
> + DEVID_FIELD(dfl_device_id, type);
> + DEVID_FIELD(dfl_device_id, feature_id);
> +
>   return 0;
>  }
> diff --git a/scripts/mod/file2alias.c b/scripts/mod/file2alias.c
> index 2417dd1..9fd2e60 100644
> --- a/scripts/mod/file2alias.c
> +++ b/scripts/mod/file2alias.c
> @@ -1368,6 +1368,22 @@ static int do_mhi_entry(const char *filename, void 
> *symval, char *alias)
>   return 1;
>  }
>  
> +/* Looks like: dfl:tNfN */
> +static int do_dfl_entry(const char *filename, void *symval, char *alias)
> +{
> + DEF_FIELD(symval, dfl_device_id, type);
> + DEF_FIELD(symval, dfl_device_id, feature_id);
> +
> + /*
> +  * type contains 4 valid bits and feature_id contains 12 valid bits
> +  * according to DFL specification.
> +  */
> + sprintf(alias, "dfl:t%01Xf%03X", type, feature_id);
> +
> + add_wildcard(alias);
> + return 1;
> +}
> +
>  /* Does namelen bytes of name exactly match the symbol? */
>  static bool sym_is(const char *name, unsigned namelen, const char *symbol)
>  {
> @@ -1442,6 +1458,7 @@ static const struct devtable devtable[] = {
>   {"tee", SIZE_tee_client_device_id, do_tee_entry},
>   {"wmi", SIZE_wmi_device_id, do_wmi_entry},
>   {"mhi", SIZE_mhi_device_id, do_mhi_entry},
> + {"dfl", SIZE_dfl_device_id, do_dfl_entry},
>  };
>  
>  /* Create MODULE_ALIAS() statements.
> -- 
> 2.7.4
> 
Applied to for-next,

Thanks

[PATCH v14 3/5] KASAN: Port KASAN Tests to KUnit

From: Patricia Alfonso 

Transfer all previous tests for KASAN to KUnit so they can be run
more easily. Using kunit_tool, developers can run these tests with their
other KUnit tests and see "pass" or "fail" with the appropriate KASAN
report instead of needing to parse each KASAN report to test KASAN
functionalities. All KASAN reports are still printed to dmesg.

Stack tests do not work properly when KASAN_STACK is enabled so
those tests use a check for "if IS_ENABLED(CONFIG_KASAN_STACK)" so they
only run if stack instrumentation is enabled. If KASAN_STACK is not
enabled, KUnit will print a statement to let the user know this test
was not run with KASAN_STACK enabled.

copy_user_test and kasan_rcu_uaf cannot be run in KUnit so there is a
separate test file for those tests, which can be run as before as a
module.

Signed-off-by: Patricia Alfonso 
Signed-off-by: David Gow 
Reviewed-by: Brendan Higgins 
Reviewed-by: Andrey Konovalov 
Reviewed-by: Dmitry Vyukov 
Tested-by: Andrey Konovalov 
---
 lib/Kconfig.kasan   |  22 +-
 lib/Makefile|   4 +-
 lib/test_kasan.c| 687 +++-
 lib/test_kasan_module.c | 111 +++
 4 files changed, 386 insertions(+), 438 deletions(-)
 create mode 100644 lib/test_kasan_module.c

diff --git a/lib/Kconfig.kasan b/lib/Kconfig.kasan
index 047b53dbfd58..9a237887e52e 100644
--- a/lib/Kconfig.kasan
+++ b/lib/Kconfig.kasan
@@ -167,12 +167,24 @@ config KASAN_VMALLOC
  for KASAN to detect more sorts of errors (and to support vmapped
  stacks), but at the cost of higher memory usage.
 
-config TEST_KASAN
-   tristate "Module for testing KASAN for bug detection"
-   depends on m
+config KASAN_KUNIT_TEST
+   tristate "KUnit-compatible tests of KASAN bug detection capabilities" 
if !KUNIT_ALL_TESTS
+   depends on KASAN && KUNIT
+   default KUNIT_ALL_TESTS
help
- This is a test module doing various nasty things like
- out of bounds accesses, use after free. It is useful for testing
+ This is a KUnit test suite doing various nasty things like
+ out of bounds and use after free accesses. It is useful for testing
  kernel debugging features like KASAN.
 
+ For more information on KUnit and unit tests in general, please refer
+ to the KUnit documentation in Documentation/dev-tools/kunit
+
+config TEST_KASAN_MODULE
+   tristate "KUnit-incompatible tests of KASAN bug detection capabilities"
+   depends on m && KASAN
+   help
+ This is a part of the KASAN test suite that is incompatible with
+ KUnit. Currently includes tests that do bad copy_from/to_user
+ accesses.
+
 endif # KASAN
diff --git a/lib/Makefile b/lib/Makefile
index a4a4c6864f51..d4af75136c54 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -65,9 +65,11 @@ CFLAGS_test_bitops.o += -Werror
 obj-$(CONFIG_TEST_SYSCTL) += test_sysctl.o
 obj-$(CONFIG_TEST_HASH) += test_hash.o test_siphash.o
 obj-$(CONFIG_TEST_IDA) += test_ida.o
-obj-$(CONFIG_TEST_KASAN) += test_kasan.o
+obj-$(CONFIG_KASAN_KUNIT_TEST) += test_kasan.o
 CFLAGS_test_kasan.o += -fno-builtin
 CFLAGS_test_kasan.o += $(call cc-disable-warning, vla)
+obj-$(CONFIG_TEST_KASAN_MODULE) += test_kasan_module.o
+CFLAGS_test_kasan_module.o += -fno-builtin
 obj-$(CONFIG_TEST_UBSAN) += test_ubsan.o
 CFLAGS_test_ubsan.o += $(call cc-disable-warning, vla)
 UBSAN_SANITIZE_test_ubsan.o := y
diff --git a/lib/test_kasan.c b/lib/test_kasan.c
index 58bffadd8367..63c26171a791 100644
--- a/lib/test_kasan.c
+++ b/lib/test_kasan.c
@@ -5,8 +5,6 @@
  * Author: Andrey Ryabinin 
  */
 
-#define pr_fmt(fmt) "kasan test: %s " fmt, __func__
-
 #include 
 #include 
 #include 
@@ -77,416 +75,327 @@ static void kasan_test_exit(struct kunit *test)
fail_data.report_found); \
 } while (0)
 
-
-
-/*
- * Note: test functions are marked noinline so that their names appear in
- * reports.
- */
-static noinline void __init kmalloc_oob_right(void)
+static void kmalloc_oob_right(struct kunit *test)
 {
char *ptr;
size_t size = 123;
 
-   pr_info("out-of-bounds to right\n");
ptr = kmalloc(size, GFP_KERNEL);
-   if (!ptr) {
-   pr_err("Allocation failed\n");
-   return;
-   }
-
-   ptr[size + OOB_TAG_OFF] = 'x';
+   KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ptr);
 
+   KUNIT_EXPECT_KASAN_FAIL(test, ptr[size + OOB_TAG_OFF] = 'x');
kfree(ptr);
 }
 
-static noinline void __init kmalloc_oob_left(void)
+static void kmalloc_oob_left(struct kunit *test)
 {
char *ptr;
size_t size = 15;
 
-   pr_info("out-of-bounds to left\n");
ptr = kmalloc(size, GFP_KERNEL);
-   if (!ptr) {
-   pr_err("Allocation failed\n");
-   return;
-   }
+   KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ptr);
 
-   *ptr = *(ptr - 1);
+   KUNIT_EXPECT_KASAN_FAIL(test, *ptr = *(ptr - 1));
kfree(ptr);
 }
 
-static

Re: [PATCH v2 1/4] fpga: dfl: move dfl_device_id to mod_devicetable.h

On Tue, Sep 15, 2020 at 11:27:50AM +0800, Xu Yilun wrote:
> In order to support MODULE_DEVICE_TABLE() for dfl device driver, this
> patch moves struct dfl_device_id to mod_devicetable.h
> 
> Signed-off-by: Xu Yilun 
> Signed-off-by: Wu Hao 
> Signed-off-by: Matthew Gerlach 
> Signed-off-by: Russ Weight 
> Reviewed-by: Tom Rix 
> Acked-by: Wu Hao 
> ---
> v2: fix the order for the header file
> ---
>  drivers/fpga/dfl.h  | 13 +
>  include/linux/mod_devicetable.h | 12 
>  2 files changed, 13 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/fpga/dfl.h b/drivers/fpga/dfl.h
> index 5dc758f..3c69596 100644
> --- a/drivers/fpga/dfl.h
> +++ b/drivers/fpga/dfl.h
> @@ -22,6 +22,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -526,18 +527,6 @@ enum dfl_id_type {
>  };
>  
>  /**
> - * struct dfl_device_id -  dfl device identifier
> - * @type: contains 4 bits DFL FIU type of the device. See enum dfl_id_type.
> - * @feature_id: contains 12 bits feature identifier local to its DFL FIU 
> type.
> - * @driver_data: driver specific data.
> - */
> -struct dfl_device_id {
> - u8 type;
> - u16 feature_id;
> - unsigned long driver_data;
> -};
> -
> -/**
>   * struct dfl_device - represent an dfl device on dfl bus
>   *
>   * @dev: generic device interface.
> diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
> index 5b08a47..407d8dc 100644
> --- a/include/linux/mod_devicetable.h
> +++ b/include/linux/mod_devicetable.h
> @@ -838,4 +838,16 @@ struct mhi_device_id {
>   kernel_ulong_t driver_data;
>  };
>  
> +/**
> + * struct dfl_device_id -  dfl device identifier
> + * @type: contains 4 bits DFL FIU type of the device. See enum dfl_id_type.
> + * @feature_id: contains 12 bits feature identifier local to its DFL FIU 
> type.
> + * @driver_data: driver specific data.
> + */
> +struct dfl_device_id {
> + __u8 type;
> + __u16 feature_id;
> + kernel_ulong_t driver_data;
> +};
> +
>  #endif /* LINUX_MOD_DEVICETABLE_H */
> -- 
> 2.7.4
> 

Applied to for-next,

Thanks

[PATCH v14 0/5] KASAN-KUnit Integration

This patchset contains everything needed to integrate KASAN and KUnit.

KUnit will be able to:
(1) Fail tests when an unexpected KASAN error occurs
(2) Pass tests when an expected KASAN error occurs

Convert KASAN tests to KUnit with the exception of copy_user_test
because KUnit is unable to test those.

Add documentation on how to run the KASAN tests with KUnit and what to
expect when running these tests.

The dependencies for this patchset are all present in 5.9-rc1+.

Changes from v13:
- Fix some compile warnings in test_kasan_module[9]

Changes from v12:
- Rebased on top of mainline (ab29a807)
- Updated to match latest KUnit guidelines (no longer rename the test)
- Fix some small issues with the documentation to match the correct
test name and mention the module name.

Changes from v11:
- Rebased on top of latest -next (20200810)
- Fixed a redundant memchr() call in kasan_memchr()
- Added Andrey's "Tested-by" to everything.

Changes from v10:
- Fixed some whitespace issues in patch 2.
- Split out the renaming of the KUnit test suite into a separate patch.

Changes from v9:
- Rebased on top of linux-next (20200731) + kselftest/kunit and [7]
- Note that the kasan_rcu_uaf test has not been ported to KUnit, and
remains in test_kasan_module. This is because:
(a) KUnit's expect failure will not check if the RCU stacktraces
show.
(b) KUnit is unable to link the failure to the test, as it occurs in
an RCU callback.

Changes from v8:
- Rebased on top of kselftest/kunit
- (Which, with this patchset, should rebase cleanly on 5.8-rc7)
- Renamed the KUnit test suite, config name to patch the proposed
naming guidelines for KUnit tests[6]

Changes from v7:
- Rebased on top of kselftest/kunit
- Rebased on top of v4 of the kunit resources API[1]
- Rebased on top of v4 of the FORTIFY_SOURCE fix[2,3,4]
- Updated the Kconfig entry to support KUNIT_ALL_TESTS

Changes from v6:
- Rebased on top of kselftest/kunit
- Rebased on top of Daniel Axtens' fix for FORTIFY_SOURCE
incompatibilites [2]
- Removed a redundant report_enabled() check.
- Fixed some places with out of date Kconfig names in the
documentation.

Changes from v5:
- Split out the panic_on_warn changes to a separate patch.
- Fix documentation to fewer to the new Kconfig names.
- Fix some changes which were in the wrong patch.
- Rebase on top of kselftest/kunit (currently identical to 5.7-rc1)

Changes from v4:
- KASAN no longer will panic on errors if both panic_on_warn and
kasan_multishot are enabled.
- As a result, the KASAN tests will no-longer disable panic_on_warn.
- This also means panic_on_warn no-longer needs to be exported.
- The use of temporary "kasan_data" variables has been cleaned up
somewhat.
- A potential refcount/resource leak should multiple KASAN errors
appear during an assertion was fixed.
- Some wording changes to the KASAN test Kconfig entries.

Changes from v3:
- KUNIT_SET_KASAN_DATA and KUNIT_DO_EXPECT_KASAN_FAIL have been
combined and included in KUNIT_DO_EXPECT_KASAN_FAIL() instead.
- Reordered logic in kasan_update_kunit_status() in report.c to be
easier to read.
- Added comment to not use the name "kasan_data" for any kunit tests
outside of KUNIT_EXPECT_KASAN_FAIL().

Changes since v2:
- Due to Alan's changes in [1], KUnit can be built as a module.
- The name of the tests that could not be run with KUnit has been
changed to be more generic: test_kasan_module.
- Documentation on how to run the new KASAN tests and what to expect
when running them has been added.
- Some variables and functions are now static.
- Now save/restore panic_on_warn in a similar way to kasan_multi_shot
and renamed the init/exit functions to be more generic to accommodate.
- Due to [4] in kasan_strings, kasan_memchr, and
kasan_memcmp will fail if CONFIG_AMD_MEM_ENCRYPT is enabled so return
early and print message explaining this circumstance.
- Changed preprocessor checks to C checks where applicable.

Changes since v1:
- Make use of Alan Maguire's suggestion to use his patch that allows
static resources for integration instead of adding a new attribute to
the kunit struct
- All KUNIT_EXPECT_KASAN_FAIL statements are local to each test
- The definition of KUNIT_EXPECT_KASAN_FAIL is local to the
test_kasan.c file since it seems this is the only place this will
be used.
- Integration relies on KUnit being builtin
- copy_user_test has been separated into its own file since KUnit
is unable to test these. This can be run as a module just as before,
using CONFIG_TEST_KASAN_USER
- The addition to the current task has been separated into its own
patch as this is a significant enough change to be on its own.

[1]
https://lore.kernel.org/linux-kselftest/cafd5g46uu_5tg89uom0dj5cmq+11cwjbnsd-k_cvy6bqueu...@mail.gmail.com/T/#t
[2] https://lore.kernel.org/linux-mm/20200424145521.8203-1-...@axtens.net/
[3]

[PATCH v14 5/5] mm: kasan: Do not panic if both panic_on_warn and kasan_multishot set

KASAN errors will currently trigger a panic when panic_on_warn is set.
This renders kasan_multishot useless, as further KASAN errors won't be
reported if the kernel has already paniced. By making kasan_multishot
disable this behaviour for KASAN errors, we can still have the benefits
of panic_on_warn for non-KASAN warnings, yet be able to use
kasan_multishot.

This is particularly important when running KASAN tests, which need to
trigger multiple KASAN errors: previously these would panic the system
if panic_on_warn was set, now they can run (and will panic the system
should non-KASAN warnings show up).

Signed-off-by: David Gow 
Reviewed-by: Andrey Konovalov 
Reviewed-by: Brendan Higgins 
Tested-by: Andrey Konovalov 
---
 mm/kasan/report.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/kasan/report.c b/mm/kasan/report.c
index e2c14b10bc81..00a53f1355ae 100644
--- a/mm/kasan/report.c
+++ b/mm/kasan/report.c
@@ -95,7 +95,7 @@ static void end_report(unsigned long *flags)

pr_err("==\n");
add_taint(TAINT_BAD_PAGE, LOCKDEP_NOW_UNRELIABLE);
spin_unlock_irqrestore(_lock, *flags);
-   if (panic_on_warn) {
+   if (panic_on_warn && !test_bit(KASAN_BIT_MULTI_SHOT, _flags)) {
/*
 * This thread may hit another WARN() in the panic path.
 * Resetting this prevents additional WARN() from panicking the
-- 
2.28.0.618.gf4bc123cb7-goog

[PATCH v14 1/5] Add KUnit Struct to Current Task

From: Patricia Alfonso 

In order to integrate debugging tools like KASAN into the KUnit
framework, add KUnit struct to the current task to keep track of the
current KUnit test.

Signed-off-by: Patricia Alfonso 
Reviewed-by: Brendan Higgins 
Tested-by: Andrey Konovalov 
Signed-off-by: David Gow 
---
 include/linux/sched.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/include/linux/sched.h b/include/linux/sched.h
index afe01e232935..9df9416c5a40 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1203,6 +1203,10 @@ struct task_struct {
 #endif
 #endif
 
+#if IS_ENABLED(CONFIG_KUNIT)
+   struct kunit*kunit_test;
+#endif
+
 #ifdef CONFIG_FUNCTION_GRAPH_TRACER
/* Index of current stored address in ret_stack: */
int curr_ret_stack;
-- 
2.28.0.618.gf4bc123cb7-goog

[PATCH v14 4/5] KASAN: Testing Documentation

From: Patricia Alfonso 

Include documentation on how to test KASAN using CONFIG_TEST_KASAN_KUNIT
and CONFIG_TEST_KASAN_MODULE.

Signed-off-by: Patricia Alfonso 
Signed-off-by: David Gow 
Reviewed-by: Andrey Konovalov 
Reviewed-by: Dmitry Vyukov 
Acked-by: Brendan Higgins 
Tested-by: Andrey Konovalov 
---
 Documentation/dev-tools/kasan.rst | 70 +++
 1 file changed, 70 insertions(+)

diff --git a/Documentation/dev-tools/kasan.rst 
b/Documentation/dev-tools/kasan.rst
index 38fd5681fade..072ecdadba07 100644
--- a/Documentation/dev-tools/kasan.rst
+++ b/Documentation/dev-tools/kasan.rst
@@ -281,3 +281,73 @@ unmapped. This will require changes in arch-specific code.
 
 This allows ``VMAP_STACK`` support on x86, and can simplify support of
 architectures that do not have a fixed module region.
+
+CONFIG_KASAN_KUNIT_TEST & CONFIG_TEST_KASAN_MODULE
+--
+
+``CONFIG_KASAN_KUNIT_TEST`` utilizes the KUnit Test Framework for testing.
+This means each test focuses on a small unit of functionality and
+there are a few ways these tests can be run.
+
+Each test will print the KASAN report if an error is detected and then
+print the number of the test and the status of the test:
+
+pass::
+
+ok 28 - kmalloc_double_kzfree
+or, if kmalloc failed::
+
+# kmalloc_large_oob_right: ASSERTION FAILED at lib/test_kasan.c:163
+Expected ptr is not null, but is
+not ok 4 - kmalloc_large_oob_right
+or, if a KASAN report was expected, but not found::
+
+# kmalloc_double_kzfree: EXPECTATION FAILED at lib/test_kasan.c:629
+Expected kasan_data->report_expected == kasan_data->report_found, but
+kasan_data->report_expected == 1
+kasan_data->report_found == 0
+not ok 28 - kmalloc_double_kzfree
+
+All test statuses are tracked as they run and an overall status will
+be printed at the end::
+
+ok 1 - kasan
+
+or::
+
+not ok 1 - kasan
+
+(1) Loadable Module
+
+
+With ``CONFIG_KUNIT`` enabled, ``CONFIG_KASAN_KUNIT_TEST`` can be built as
+a loadable module and run on any architecture that supports KASAN
+using something like insmod or modprobe. The module is called ``test_kasan``.
+
+(2) Built-In
+~
+
+With ``CONFIG_KUNIT`` built-in, ``CONFIG_KASAN_KUNIT_TEST`` can be built-in
+on any architecure that supports KASAN. These and any other KUnit
+tests enabled will run and print the results at boot as a late-init
+call.
+
+(3) Using kunit_tool
+~
+
+With ``CONFIG_KUNIT`` and ``CONFIG_KASAN_KUNIT_TEST`` built-in, we can also
+use kunit_tool to see the results of these along with other KUnit
+tests in a more readable way. This will not print the KASAN reports
+of tests that passed. Use `KUnit documentation 
`_ for more 
up-to-date
+information on kunit_tool.
+
+.. _KUnit: https://www.kernel.org/doc/html/latest/dev-tools/kunit/index.html
+
+``CONFIG_TEST_KASAN_MODULE`` is a set of KASAN tests that could not be
+converted to KUnit. These tests can be run only as a module with
+``CONFIG_TEST_KASAN_MODULE`` built as a loadable module and
+``CONFIG_KASAN`` built-in. The type of error expected and the
+function being run is printed before the expression expected to give
+an error. Then the error is printed, if found, and that test
+should be interpretted to pass only if the error was the one expected
+by the test.
-- 
2.28.0.618.gf4bc123cb7-goog

Re: [PATCH] riscv: Add sfence.vma after page table changed

2020-09-14 Thread Greentime Hu

Palmer Dabbelt  於 2020年8月5日 週三 上午10:03寫道：
>
> On Mon, 03 Aug 2020 20:29:32 PDT (-0700), a...@brainfault.org wrote:
> > On Tue, Aug 4, 2020 at 8:32 AM Greentime Hu  wrote:
> >>
> >> This patch addes local_flush_tlb_page(addr) to use sfence.vma after the
> >
> > s/addes/adds
> >
> >> page table changed. That address will be used immediately in
> >> memset(nextp, 0, PAGE_SIZE) to cause this issue so we should add the
> >> sfence.vma before we use it.
> >
> > Alternate version of this commit description can be:
> >
> > Invalidate local TLB after both set_pet() and clear_pte() because the
> > address can be used immediately after page table change.
> >
> >> Fixes: f2c17aabc917 ("RISC-V: Implement compile-time fixed mappings")
> >>
> >> Reported-by: Syven Wang 
> >> Signed-off-by: Syven Wang 
> >> Signed-off-by: Greentime Hu 
> >> ---
> >>  arch/riscv/mm/init.c | 7 +++
> >>  1 file changed, 3 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
> >> index f4adb3684f3d..29b0f7108054 100644
> >> --- a/arch/riscv/mm/init.c
> >> +++ b/arch/riscv/mm/init.c
> >> @@ -202,12 +202,11 @@ void __set_fixmap(enum fixed_addresses idx, 
> >> phys_addr_t phys, pgprot_t prot)
> >>
> >> ptep = _pte[pte_index(addr)];
> >>
> >> -   if (pgprot_val(prot)) {
> >> +   if (pgprot_val(prot))
> >> set_pte(ptep, pfn_pte(phys >> PAGE_SHIFT, prot));
> >> -   } else {
> >> +   else
> >> pte_clear(_mm, addr, ptep);
> >> -   local_flush_tlb_page(addr);
> >> -   }
> >> +   local_flush_tlb_page(addr);
> >>  }
>
> arm64 appears to be upgrading all set_pte()s on valid kernel mappings to
> include the fence.  It looks like the message from 7f0b1bf04511 ("arm64: Fix
> barriers used for page table modifications") is out of date, as I can't find
> create_mapping() any more.  If that was some generic kernel thing then we
> should probably upgrade ours as well, but if it was arch/arm64/ code then this
> approach seems fine as __set_fixmap() isn't on the hot path -- I guess this is
> fine either way, but there may be other issues that the arm64 approach fixes.
>
> Do you guys happen to remember what was going on here?

Hi Palmer,

Some architectures add cache writeback in set_pte(), just like nds32, csky.

https://github.com/torvalds/linux/blob/master/arch/nds32/include/asm/pgtable.h#L213
https://github.com/torvalds/linux/blob/master/arch/csky/include/asm/pgtable.h#L104

Would you like to pick this patch or should I send another patch to
implement it in set_pte()?

[PATCH] docs:fb:fbcon.rst:Remove the stale boot option for framebuffer i.e scrollback

This patch is the effect of commit hashes: 
50145474f6ef4a9c19205b173da6264a644c7489 and
973c096f6a85e5b5f2a295126ba6928d9a6afd45 

fbcon: remove soft scrollback code 

And adjusted the numbering for boot options too.

Signed-off-by: Bhaskar Chowdhury 
---
 Documentation/fb/fbcon.rst | 21 +++--
 1 file changed, 7 insertions(+), 14 deletions(-)

diff --git a/Documentation/fb/fbcon.rst b/Documentation/fb/fbcon.rst
index e57a3d1d085a..328f6980698c 100644
--- a/Documentation/fb/fbcon.rst
+++ b/Documentation/fb/fbcon.rst
@@ -87,15 +87,8 @@ C. Boot options
Note, not all drivers can handle font with widths not divisible by 8,
such as vga16fb.
 
-2. fbcon=scrollback:[k]
 
-   The scrollback buffer is memory that is used to preserve display
-   contents that has already scrolled past your view.  This is accessed
-   by using the Shift-PageUp key combination.  The value 'value' is any
-   integer. It defaults to 32KB.  The 'k' suffix is optional, and will
-   multiply the 'value' by 1024.
-
-3. fbcon=map:<0123>
+2. fbcon=map:<0123>
 
This is an interesting option. It tells which driver gets mapped to
which console. The value '0123' is a sequence that gets repeated until
@@ -116,7 +109,7 @@ C. Boot options
Later on, when you want to map the console the to the framebuffer
device, you can use the con2fbmap utility.
 
-4. fbcon=vc:-
+3. fbcon=vc:-
 
This option tells fbcon to take over only a range of consoles as
specified by the values 'n1' and 'n2'. The rest of the consoles
@@ -127,7 +120,7 @@ C. Boot options
is typically located on the same video card.  Thus, the consoles that
are controlled by the VGA console will be garbled.
 
-5. fbcon=rotate:
+4. fbcon=rotate:
 
This option changes the orientation angle of the console display. The
value 'n' accepts the following:
@@ -152,21 +145,21 @@ C. Boot options
Actually, the underlying fb driver is totally ignorant of console
rotation.
 
-6. fbcon=margin:
+5. fbcon=margin:
 
This option specifies the color of the margins. The margins are the
leftover area at the right and the bottom of the screen that are not
used by text. By default, this area will be black. The 'color' value
is an integer number that depends on the framebuffer driver being used.
 
-7. fbcon=nodefer
+6. fbcon=nodefer
 
If the kernel is compiled with deferred fbcon takeover support, normally
the framebuffer contents, left in place by the firmware/bootloader, will
be preserved until there actually is some text is output to the console.
This option causes fbcon to bind immediately to the fbdev device.
 
-8. fbcon=logo-pos:
+7. fbcon=logo-pos:
 
The only possible 'location' is 'center' (without quotes), and when
given, the bootup logo is moved from the default top-left corner
@@ -174,7 +167,7 @@ C. Boot options
displayed due to multiple CPUs, the collected line of logos is moved
as a whole.
 
-9. fbcon=logo-count:
+8. fbcon=logo-count:
 
The value 'n' overrides the number of bootup logos. 0 disables the
logo, and -1 gives the default which is the number of online CPUs.
-- 
2.26.2

[PATCH v6] mfd: intel-m10-bmc: add Intel MAX 10 BMC chip support for Intel FPGA PAC

This patch implements the basic functions of the BMC chip for some Intel
FPGA PCIe Acceleration Cards (PAC). The BMC is implemented using the
Intel MAX 10 CPLD.

This BMC chip is connected to the FPGA by a SPI bus. To provide direct
register access from the FPGA, the "SPI slave to Avalon Master Bridge"
(spi-avmm) IP is integrated in the chip. It converts encoded streams of
bytes from the host to the internal register read/write on the Avalon
bus. So This driver uses the regmap-spi-avmm for register accessing.

Signed-off-by: Xu Yilun 
Signed-off-by: Wu Hao 
Signed-off-by: Matthew Gerlach 
Signed-off-by: Russ Weight 
Reviewed-by: Tom Rix 
---
v2: Split out the regmap-spi-avmm part.
Rename the file intel-m10-bmc-main.c to intel-m10-bmc.c, cause
 there is only one source file left for this module now.
v3: Add the sub devices in mfd_cell.
Some minor fixes.
v4: No change.
v5: Changes the names of mfd_cell.
Use ATTRIBUTE_GROUPS() to simplify the code.
Use the generic 'ddata' for the instance of struct intel_m10bmc.
More comments to clarify the function check_m10bmc_version().
Some minor fixes.
v6: Defines macro for invalid legacy bmc version value to make the
 version check more clear.
Add comments for the purpose of abstraction of the regmap ops.
---
 .../ABI/testing/sysfs-driver-intel-m10-bmc |  15 ++
 drivers/mfd/Kconfig|  13 ++
 drivers/mfd/Makefile   |   2 +
 drivers/mfd/intel-m10-bmc.c| 164 +
 include/linux/mfd/intel-m10-bmc.h  |  65 
 5 files changed, 259 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-driver-intel-m10-bmc
 create mode 100644 drivers/mfd/intel-m10-bmc.c
 create mode 100644 include/linux/mfd/intel-m10-bmc.h

diff --git a/Documentation/ABI/testing/sysfs-driver-intel-m10-bmc 
b/Documentation/ABI/testing/sysfs-driver-intel-m10-bmc
new file mode 100644
index 000..979a2d6
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-driver-intel-m10-bmc
@@ -0,0 +1,15 @@
+What:  /sys/bus/spi/devices/.../bmc_version
+Date:  June 2020
+KernelVersion: 5.10
+Contact:   Xu Yilun 
+Description:   Read only. Returns the hardware build version of Intel
+   MAX10 BMC chip.
+   Format: "0x%x".
+
+What:  /sys/bus/spi/devices/.../bmcfw_version
+Date:  June 2020
+KernelVersion: 5.10
+Contact:   Xu Yilun 
+Description:   Read only. Returns the firmware version of Intel MAX10
+   BMC chip.
+   Format: "0x%x".
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 2bc3073..56558fe 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -2129,5 +2129,18 @@ config SGI_MFD_IOC3
  If you have an SGI Origin, Octane, or a PCI IOC3 card,
  then say Y. Otherwise say N.
 
+config MFD_INTEL_M10_BMC
+   tristate "Intel MAX 10 Board Management Controller"
+   depends on SPI_MASTER
+   select REGMAP_SPI_AVMM
+   select MFD_CORE
+   help
+ Support for the Intel MAX 10 board management controller using the
+ SPI interface.
+
+ This driver provides common support for accessing the device,
+ additional drivers must be enabled in order to use the functionality
+ of the device.
+
 endmenu
 endif
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index d660be7..344653c 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -265,3 +265,5 @@ obj-$(CONFIG_MFD_STMFX) += stmfx.o
 obj-$(CONFIG_MFD_KHADAS_MCU)   += khadas-mcu.o
 
 obj-$(CONFIG_SGI_MFD_IOC3) += ioc3.o
+
+obj-$(CONFIG_MFD_INTEL_M10_BMC)   += intel-m10-bmc.o
diff --git a/drivers/mfd/intel-m10-bmc.c b/drivers/mfd/intel-m10-bmc.c
new file mode 100644
index 000..b84579b
--- /dev/null
+++ b/drivers/mfd/intel-m10-bmc.c
@@ -0,0 +1,164 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Intel MAX 10 Board Management Controller chip
+ *
+ * Copyright (C) 2018-2020 Intel Corporation. All rights reserved.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+enum m10bmc_type {
+   M10_N3000,
+};
+
+static struct mfd_cell m10bmc_pacn3000_subdevs[] = {
+   { .name = "n3000bmc-hwmon" },
+   { .name = "n3000bmc-retimer" },
+   { .name = "n3000bmc-secure" },
+};
+
+static struct regmap_config intel_m10bmc_regmap_config = {
+   .reg_bits = 32,
+   .val_bits = 32,
+   .reg_stride = 4,
+   .max_register = M10BMC_MEM_END,
+};
+
+static ssize_t bmc_version_show(struct device *dev,
+   struct device_attribute *attr, char *buf)
+{
+   struct intel_m10bmc *ddata = dev_get_drvdata(dev);
+   unsigned int val;
+   int ret;
+
+   ret = m10bmc_sys_read(ddata, M10BMC_BUILD_VER, );
+   if (ret)
+   return ret;
+
+   return sprintf(buf, "0x%x\n", val);
+}
+static DEVICE_ATTR_RO(bmc_version);

Re: linux-next: build warning after merge of the pci tree

2020-09-14 Thread Stephen Rothwell

Hi all,

On Wed, 9 Sep 2020 10:06:20 -0600 Rob Herring  wrote:
>
> On Tue, Sep 8, 2020 at 8:37 PM Stephen Rothwell  wrote:
> >
> > After merging the pci tree, today's linux-next build (arm
> > multi_v7_defconfig) produced this warning:  
> 
> Uggg. I guess 0-day just doesn't do arm32 builds anymore as it caught
> more obscure build issues, but not this one (and some others I've had
> recently).
> 
> > drivers/pci/controller/dwc/pci-dra7xx.c: In function 
> > 'dra7xx_pcie_establish_link':
> > drivers/pci/controller/dwc/pci-dra7xx.c:142:6: warning: unused variable 
> > 'exp_cap_off' [-Wunused-variable]
> >   142 |  u32 exp_cap_off = dw_pcie_find_capability(pci, PCI_CAP_ID_EXP);
> >   |  ^~~
> >
> > Introduced by commit
> >
> >   3af45d34d30c ("PCI: dwc: Centralize link gen setting")

I am still getting this warning.

-- 
Cheers,
Stephen Rothwell


pgpQYF5HsCK6x.pgp
Description: OpenPGP digital signature

Re: [PATCH RESEND RESEND] remoteproc: scp: add COMPILE_TEST dependency

2020-09-14 Thread Alexandre Courbot

On Tue, Sep 15, 2020 at 12:25 PM Bjorn Andersson
 wrote:
>
> On Tue 15 Sep 01:29 UTC 2020, Alexandre Courbot wrote:
>
> > This will improve this driver's build coverage.
> >
> > Reported-by: Ezequiel Garcia 
> > Signed-off-by: Alexandre Courbot 
> > ---
> > Hi remoteproc maintainers,
> >
> > Second resend as I got no reaction for almost 1 month on this one-liner.
>
> Sorry about that. I fell behind on my inbox and have missed your
> previous attempts.
>
> This has now been applied.

No worries, thanks for the quick response.

Mauro, the patch is applied on
https://git.kernel.org/pub/scm/linux/kernel/git/andersson/remoteproc.git/commit/?id=5185e3a9dc2d68bb52e3e12400428aa060b87733,
will it work for you to merge this into the media tree and apply the
pull request on top?

>
> Regards,
> Bjorn
>
> > Pretty please?
> >
> > As explained in
> > https://www.spinics.net/lists/linux-media/msg175991.html, we need this
> > patch in order to merge a driver series in the media tree. If that
> > looks ok to you, can we pull it in the media tree along with the series
> > that depends on it?
> >
> >  drivers/remoteproc/Kconfig | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> > index c6659dfea7c7..d1fcada71017 100644
> > --- a/drivers/remoteproc/Kconfig
> > +++ b/drivers/remoteproc/Kconfig
> > @@ -43,7 +43,7 @@ config INGENIC_VPU_RPROC
> >
> >  config MTK_SCP
> >   tristate "Mediatek SCP support"
> > - depends on ARCH_MEDIATEK
> > + depends on ARCH_MEDIATEK || COMPILE_TEST
> >   select RPMSG_MTK_SCP
> >   help
> > Say y here to support Mediatek's System Companion Processor (SCP) 
> > via
> > --
> > 2.28.0.526.ge36021eeef-goog
> >

Re: linux-next: build warning after merge of the pci tree

2020-09-14 Thread Stephen Rothwell

Hi All,

On Wed, 9 Sep 2020 12:38:43 +1000 Stephen Rothwell  
wrote:
>
> After merging the pci tree, today's linux-next build (arm
> multi_v7_defconfig) produced this warning:
> 
> WARNING: modpost: "dw_pcie_link_set_max_speed" [vmlinux] is a static 
> EXPORT_SYMBOL_GPL
> 
> Introduced by commit
> 
>   3af45d34d30c ("PCI: dwc: Centralize link gen setting")

I am still getting this warning.

-- 
Cheers,
Stephen Rothwell


pgpwonQ61opxA.pgp
Description: OpenPGP digital signature

Re: 回复: RCU: Question on force_qs_rnp

2020-09-14 Thread Paul E. McKenney

On Tue, Sep 15, 2020 at 03:18:23AM +, Zhang, Qiang wrote:
> 
> 
> 
> 发件人: Paul E. McKenney 
> 发送时间: 2020年9月15日 4:56
> 收件人: Joel Fernandes
> 抄送: Zhang, Qiang; Uladzislau Rezki; j...@joshtriplett.org; 
> rost...@goodmis.org; mathieu.desnoy...@efficios.com; Lai Jiangshan; 
> r...@vger.kernel.org; LKML
> 主题: Re: RCU: Question on force_qs_rnp
> 
> On Mon, Sep 14, 2020 at 03:42:08PM -0400, Joel Fernandes wrote:
> > On Mon, Sep 14, 2020 at 07:55:18AM +, Zhang, Qiang wrote:
> > > Hello Paul
> > >
> > > I have some questions for you .
> > > in force_qs_rnp func ,  if  "f(rdp)" func return true we will call 
> > > rcu_report_qs_rnp func
> > > report a quiescent state for this rnp node, and clear grpmask form 
> > > rnp->qsmask.
> > > after that ,  can we make a check for this rnp->qsmask,  if  rnp->qsmask 
> > > == 0,
> > > we will check blocked readers in this rnp node,  instead of jumping 
> > > directly to the next node .
> >
> > Could you clarify what good is this going to do? What problem are you 
> > trying to
> > address?
> >
> > You could have a task that is blocked in an RCU leaf node, but the
> > force_qs_rnp() decided to call rcu_report_qs_rnp(). This is perfectly Ok. 
> > The
> > CPU could be dyntick-idle and a quiescent state is reported. However, the GP
> > must not end and the rcu leaf node should still be present in its parent
> > intermediate nodes ->qsmask. In this case, the ->qsmask == 0 does not have
> > any relevance.
> >
> > Or am I missing the point of the question?
> 
> >Hello, Qiang,
> 
> >Another way of making Joel's point is to say that the additional check
> >you are asking for is already being done, but by rcu_report_qs_rnp().
> 
> >Thanx, Paul
> 
> Hello Pual,  Joel
> 
> What I want to express is as follows :
> 
> diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> index 7623128d0020..beb554539f01 100644
> --- a/kernel/rcu/tree.c
> +++ b/kernel/rcu/tree.c
> @@ -2622,6 +2622,11 @@ static void force_qs_rnp(int (*f)(struct rcu_data 
> *rdp))
> if (mask != 0) {
> /* Idle/offline CPUs, report (releases rnp->lock). */
> rcu_report_qs_rnp(mask, rnp, rnp->gp_seq, flags);
> +   raw_spin_lock_irqsave_rcu_node(rnp, flags);
> +   if (rnp->qsmask == 0 && 
> rcu_preempt_blocked_readers_cgp(rnp))
> +   rcu_initiate_boost(rnp, flags);
> +   else
> +   raw_spin_unlock_irqrestore_rcu_node(rnp, 
> flags);
> } else {
> /* Nothing to do here, so just drop the lock. */
> raw_spin_unlock_irqrestore_rcu_node(rnp, flags);

But in that case, why duplicate the code from rcu_initiate_boost()?

Thanx, Paul

RE: [PATCH 5/7] dt-bindings: pci: layerscape-pci: Update the description of SCFG property

2020-09-14 Thread Z.q. Hou

Hi Rob,

Thanks a lot for your review and ack!

Regards,
Zhiqiang

> -Original Message-
> From: Rob Herring 
> Sent: 2020年9月15日 9:31
> To: Z.q. Hou 
> Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; M.h. Lian
> ; devicet...@vger.kernel.org;
> gustavo.pimen...@synopsys.com; robh...@kernel.org; Mingkai Hu
> ; Roy Zang ;
> shawn...@kernel.org; Leo Li ;
> bhelg...@google.com; lorenzo.pieral...@arm.com
> Subject: Re: [PATCH 5/7] dt-bindings: pci: layerscape-pci: Update the
> description of SCFG property
> 
> On Mon, 07 Sep 2020 13:37:59 +0800, Zhiqiang Hou wrote:
> > From: Hou Zhiqiang 
> >
> > Update the description of the second entry of 'fsl,pcie-scfg'
> > property, as the LS1043A PCIe controller also has some control
> > registers in SCFG block, while it has 3 controllers.
> >
> > Signed-off-by: Hou Zhiqiang 
> > ---
> >  Documentation/devicetree/bindings/pci/layerscape-pci.txt | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> 
> Acked-by: Rob Herring

RE: [PATCH 3/7] dt-bindings: pci: layerscape-pci: Add a optional property big-endian

2020-09-14 Thread Z.q. Hou

Hi Rob,

Thanks a lot for your review and ack!

Regards,
Zhiqiang

> -Original Message-
> From: Rob Herring 
> Sent: 2020年9月15日 9:31
> To: Z.q. Hou 
> Cc: bhelg...@google.com; linux-kernel@vger.kernel.org;
> shawn...@kernel.org; Leo Li ;
> linux-...@vger.kernel.org; M.h. Lian ;
> robh...@kernel.org; gustavo.pimen...@synopsys.com;
> lorenzo.pieral...@arm.com; Roy Zang ; Mingkai Hu
> ; devicet...@vger.kernel.org
> Subject: Re: [PATCH 3/7] dt-bindings: pci: layerscape-pci: Add a optional
> property big-endian
> 
> On Mon, 07 Sep 2020 13:37:57 +0800, Zhiqiang Hou wrote:
> > From: Hou Zhiqiang 
> >
> > This property is to indicate the endianness when accessing the PEX_LUT
> > and PF register block, so if these registers are implemented in
> > big-endian, specify this property.
> >
> > Signed-off-by: Hou Zhiqiang 
> > ---
> >  Documentation/devicetree/bindings/pci/layerscape-pci.txt | 4 
> >  1 file changed, 4 insertions(+)
> >
> 
> Acked-by: Rob Herring

RE: [PATCH 1/7] PCI: dwc: Fix a bug of the case dw_pci->ops is NULL

2020-09-14 Thread Z.q. Hou

Hi Rob,

Thanks a lot for your review!

Regards,
Zhiqiang

> -Original Message-
> From: Rob Herring 
> Sent: 2020年9月15日 9:16
> To: Z.q. Hou 
> Cc: linux-...@vger.kernel.org; devicet...@vger.kernel.org;
> linux-kernel@vger.kernel.org; bhelg...@google.com;
> shawn...@kernel.org; Leo Li ;
> lorenzo.pieral...@arm.com; gustavo.pimen...@synopsys.com; M.h. Lian
> ; Mingkai Hu ; Roy Zang
> 
> Subject: Re: [PATCH 1/7] PCI: dwc: Fix a bug of the case dw_pci->ops is NULL
> 
> On Mon, Sep 07, 2020 at 01:37:55PM +0800, Zhiqiang Hou wrote:
> > From: Hou Zhiqiang 
> >
> > The dw_pci->ops may be a NULL, and fix it by adding one more check.
> >
> > Signed-off-by: Hou Zhiqiang 
> > ---
> >  drivers/pci/controller/dwc/pcie-designware.c | 12 ++--
> >  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> Reviewed-by: Rob Herring 
> 
> Note that this may conflict with my 40 patch clean-up series.
> 
> Rob

[PATCH v2 3/4] fpga: dfl: fix the comments of type & feature_id fields

The description of feature_id in struct dfl_device is not accurate. In
DFL specification the feature_id is the 12 bits field. The description
in struct dfl_device_id is more clear so we make them aligned. We also
made the similar fix for the type field.

Signed-off-by: Xu Yilun 
---
 drivers/fpga/dfl.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/fpga/dfl.h b/drivers/fpga/dfl.h
index 3c69596..d5e050a 100644
--- a/drivers/fpga/dfl.h
+++ b/drivers/fpga/dfl.h
@@ -531,8 +531,8 @@ enum dfl_id_type {
  *
  * @dev: generic device interface.
  * @id: id of the dfl device.
- * @type: type of DFL FIU of the device. See enum dfl_id_type.
- * @feature_id: 16 bits feature identifier local to its DFL FIU type.
+ * @type: contains 4 bits DFL FIU type of the device. See enum dfl_id_type.
+ * @feature_id: contains 12 bits feature identifier local to its DFL FIU type.
  * @mmio_res: mmio resource of this dfl device.
  * @irqs: list of Linux IRQ numbers of this dfl device.
  * @num_irqs: number of IRQs supported by this dfl device.
-- 
2.7.4

[PATCH v2 4/4] fpga: dfl: move dfl bus related APIs to include/linux/fpga/dfl.h

The patch moves dfl-bus related APIs to include/linux/fpga/dfl.h

Now the DFL device drivers could be made as independent modules and put
in different folders according to their functionality. In order for
scattered DFL device drivers to include dfl bus APIs, move the dfl bus
APIs to a new header file in the public folder.

Signed-off-by: Xu Yilun 
Reviewed-by: Tom Rix 
Acked-by: Wu Hao 
---
v2: updated the MAINTAINERS under FPGA DFL DRIVERS
improve the comments
rename the dfl-bus.h to dfl.h
---
 MAINTAINERS   |  1 +
 drivers/fpga/dfl-n3000-nios.c |  3 +-
 drivers/fpga/dfl.c|  1 +
 drivers/fpga/dfl.h| 72 
 include/linux/fpga/dfl.h  | 86 +++
 5 files changed, 89 insertions(+), 74 deletions(-)
 create mode 100644 include/linux/fpga/dfl.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 31c5165..fa46592 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6883,6 +6883,7 @@ S:Maintained
 F: Documentation/ABI/testing/sysfs-bus-dfl
 F: Documentation/fpga/dfl.rst
 F: drivers/fpga/dfl*
+F: include/linux/fpga/dfl.h
 F: include/uapi/linux/fpga-dfl.h
 
 FPGA MANAGER FRAMEWORK
diff --git a/drivers/fpga/dfl-n3000-nios.c b/drivers/fpga/dfl-n3000-nios.c
index 70b44c3..5088f8f 100644
--- a/drivers/fpga/dfl-n3000-nios.c
+++ b/drivers/fpga/dfl-n3000-nios.c
@@ -11,6 +11,7 @@
  */
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -22,8 +23,6 @@
 #include 
 #include 
 
-#include "dfl.h"
-
 static char *fec_mode = "rs";
 module_param(fec_mode, charp, 0444);
 MODULE_PARM_DESC(fec_mode, "FEC mode of the ethernet retimer on Intel PAC 
N3000");
diff --git a/drivers/fpga/dfl.c b/drivers/fpga/dfl.c
index b450870..8bf6e99 100644
--- a/drivers/fpga/dfl.c
+++ b/drivers/fpga/dfl.c
@@ -11,6 +11,7 @@
  *   Xiao Guangrong 
  */
 #include 
+#include 
 #include 
 #include 
 
diff --git a/drivers/fpga/dfl.h b/drivers/fpga/dfl.h
index d5e050a..2b82c96 100644
--- a/drivers/fpga/dfl.h
+++ b/drivers/fpga/dfl.h
@@ -517,76 +517,4 @@ long dfl_feature_ioctl_set_irq(struct platform_device 
*pdev,
   struct dfl_feature *feature,
   unsigned long arg);
 
-/**
- * enum dfl_id_type - define the DFL FIU types
- */
-enum dfl_id_type {
-   FME_ID,
-   PORT_ID,
-   DFL_ID_MAX,
-};
-
-/**
- * struct dfl_device - represent an dfl device on dfl bus
- *
- * @dev: generic device interface.
- * @id: id of the dfl device.
- * @type: contains 4 bits DFL FIU type of the device. See enum dfl_id_type.
- * @feature_id: contains 12 bits feature identifier local to its DFL FIU type.
- * @mmio_res: mmio resource of this dfl device.
- * @irqs: list of Linux IRQ numbers of this dfl device.
- * @num_irqs: number of IRQs supported by this dfl device.
- * @cdev: pointer to DFL FPGA container device this dfl device belongs to.
- * @id_entry: matched id entry in dfl driver's id table.
- */
-struct dfl_device {
-   struct device dev;
-   int id;
-   u8 type;
-   u16 feature_id;
-   struct resource mmio_res;
-   int *irqs;
-   unsigned int num_irqs;
-   struct dfl_fpga_cdev *cdev;
-   const struct dfl_device_id *id_entry;
-};
-
-/**
- * struct dfl_driver - represent an dfl device driver
- *
- * @drv: driver model structure.
- * @id_table: pointer to table of device IDs the driver is interested in.
- *   { } member terminated.
- * @probe: mandatory callback for device binding.
- * @remove: callback for device unbinding.
- */
-struct dfl_driver {
-   struct device_driver drv;
-   const struct dfl_device_id *id_table;
-
-   int (*probe)(struct dfl_device *dfl_dev);
-   void (*remove)(struct dfl_device *dfl_dev);
-};
-
-#define to_dfl_dev(d) container_of(d, struct dfl_device, dev)
-#define to_dfl_drv(d) container_of(d, struct dfl_driver, drv)
-
-/*
- * use a macro to avoid include chaining to get THIS_MODULE.
- */
-#define dfl_driver_register(drv) \
-   __dfl_driver_register(drv, THIS_MODULE)
-int __dfl_driver_register(struct dfl_driver *dfl_drv, struct module *owner);
-void dfl_driver_unregister(struct dfl_driver *dfl_drv);
-
-/*
- * module_dfl_driver() - Helper macro for drivers that don't do
- * anything special in module init/exit.  This eliminates a lot of
- * boilerplate.  Each module may only use this macro once, and
- * calling it replaces module_init() and module_exit().
- */
-#define module_dfl_driver(__dfl_driver) \
-   module_driver(__dfl_driver, dfl_driver_register, \
- dfl_driver_unregister)
-
 #endif /* __FPGA_DFL_H */
diff --git a/include/linux/fpga/dfl.h b/include/linux/fpga/dfl.h
new file mode 100644
index 000..0d7806f
--- /dev/null
+++ b/include/linux/fpga/dfl.h
@@ -0,0 +1,86 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Header file for DFL driver and device API
+ *
+ * Copyright (C) 2020 Intel Corporation, Inc.
+ */
+
+#ifndef

[PATCH v2 2/4] dfl: add dfl bus support to MODULE_DEVICE_TABLE()

Device Feature List (DFL) is a linked list of feature headers within the
device MMIO space. It is used by FPGA to enumerate multiple sub features
within it. Each feature can be uniquely identified by DFL type and
feature id, which can be read out from feature headers.

A dfl bus helps DFL framework modularize DFL device drivers for different
sub features. The dfl bus matches its devices and drivers by DFL type and
feature id.

This patch add dfl bus support to MODULE_DEVICE_TABLE() by adding info
about struct dfl_device_id in devicetable-offsets.c and add a dfl entry
point in file2alias.c.

Signed-off-by: Xu Yilun 
Signed-off-by: Wu Hao 
Signed-off-by: Matthew Gerlach 
Signed-off-by: Russ Weight 
Acked-by: Wu Hao 
---
v2: add comments for the format of modalias
---
 scripts/mod/devicetable-offsets.c |  4 
 scripts/mod/file2alias.c  | 17 +
 2 files changed, 21 insertions(+)

diff --git a/scripts/mod/devicetable-offsets.c 
b/scripts/mod/devicetable-offsets.c
index 27007c1..d8350ee 100644
--- a/scripts/mod/devicetable-offsets.c
+++ b/scripts/mod/devicetable-offsets.c
@@ -243,5 +243,9 @@ int main(void)
DEVID(mhi_device_id);
DEVID_FIELD(mhi_device_id, chan);
 
+   DEVID(dfl_device_id);
+   DEVID_FIELD(dfl_device_id, type);
+   DEVID_FIELD(dfl_device_id, feature_id);
+
return 0;
 }
diff --git a/scripts/mod/file2alias.c b/scripts/mod/file2alias.c
index 2417dd1..9fd2e60 100644
--- a/scripts/mod/file2alias.c
+++ b/scripts/mod/file2alias.c
@@ -1368,6 +1368,22 @@ static int do_mhi_entry(const char *filename, void 
*symval, char *alias)
return 1;
 }
 
+/* Looks like: dfl:tNfN */
+static int do_dfl_entry(const char *filename, void *symval, char *alias)
+{
+   DEF_FIELD(symval, dfl_device_id, type);
+   DEF_FIELD(symval, dfl_device_id, feature_id);
+
+   /*
+* type contains 4 valid bits and feature_id contains 12 valid bits
+* according to DFL specification.
+*/
+   sprintf(alias, "dfl:t%01Xf%03X", type, feature_id);
+
+   add_wildcard(alias);
+   return 1;
+}
+
 /* Does namelen bytes of name exactly match the symbol? */
 static bool sym_is(const char *name, unsigned namelen, const char *symbol)
 {
@@ -1442,6 +1458,7 @@ static const struct devtable devtable[] = {
{"tee", SIZE_tee_client_device_id, do_tee_entry},
{"wmi", SIZE_wmi_device_id, do_wmi_entry},
{"mhi", SIZE_mhi_device_id, do_mhi_entry},
+   {"dfl", SIZE_dfl_device_id, do_dfl_entry},
 };
 
 /* Create MODULE_ALIAS() statements.
-- 
2.7.4

[PATCH v2 1/4] fpga: dfl: move dfl_device_id to mod_devicetable.h

In order to support MODULE_DEVICE_TABLE() for dfl device driver, this
patch moves struct dfl_device_id to mod_devicetable.h

Signed-off-by: Xu Yilun 
Signed-off-by: Wu Hao 
Signed-off-by: Matthew Gerlach 
Signed-off-by: Russ Weight 
Reviewed-by: Tom Rix 
Acked-by: Wu Hao 
---
v2: fix the order for the header file
---
 drivers/fpga/dfl.h  | 13 +
 include/linux/mod_devicetable.h | 12 
 2 files changed, 13 insertions(+), 12 deletions(-)

diff --git a/drivers/fpga/dfl.h b/drivers/fpga/dfl.h
index 5dc758f..3c69596 100644
--- a/drivers/fpga/dfl.h
+++ b/drivers/fpga/dfl.h
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -526,18 +527,6 @@ enum dfl_id_type {
 };
 
 /**
- * struct dfl_device_id -  dfl device identifier
- * @type: contains 4 bits DFL FIU type of the device. See enum dfl_id_type.
- * @feature_id: contains 12 bits feature identifier local to its DFL FIU type.
- * @driver_data: driver specific data.
- */
-struct dfl_device_id {
-   u8 type;
-   u16 feature_id;
-   unsigned long driver_data;
-};
-
-/**
  * struct dfl_device - represent an dfl device on dfl bus
  *
  * @dev: generic device interface.
diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
index 5b08a47..407d8dc 100644
--- a/include/linux/mod_devicetable.h
+++ b/include/linux/mod_devicetable.h
@@ -838,4 +838,16 @@ struct mhi_device_id {
kernel_ulong_t driver_data;
 };
 
+/**
+ * struct dfl_device_id -  dfl device identifier
+ * @type: contains 4 bits DFL FIU type of the device. See enum dfl_id_type.
+ * @feature_id: contains 12 bits feature identifier local to its DFL FIU type.
+ * @driver_data: driver specific data.
+ */
+struct dfl_device_id {
+   __u8 type;
+   __u16 feature_id;
+   kernel_ulong_t driver_data;
+};
+
 #endif /* LINUX_MOD_DEVICETABLE_H */
-- 
2.7.4

[PATCH v2 0/4] add DFL bus support to MODULE_DEVICE_TABLE()

Patch #1 and #2 add dfl bus support to MODULE_DEVICE_TABLE(), so that
dfl driver modules could be auto-loaded when dfl devices are added.

Patch #3 is a fix of the description of fields in struct dfl_device.

Patch #4 moves the dfl bus APIs to a new header file in the public
folder so that scattered dfl device drivers could include the common
dfl bus APIs.

Main changes from v1:
- A new patch (Patch #3) to fix the description.
- Rename the dfl-bus.h to dfl.h
- Updated the MAINTAINERS under FPGA DFL DRIVERS.
- Improve comments and minor fixes.

Xu Yilun (4):
  fpga: dfl: move dfl_device_id to mod_devicetable.h
  dfl: add dfl bus support to MODULE_DEVICE_TABLE()
  fpga: dfl: fix the comments of type & feature_id fields
  fpga: dfl: move dfl bus related APIs to include/linux/fpga/dfl.h

 MAINTAINERS   |  1 +
 drivers/fpga/dfl-n3000-nios.c |  3 +-
 drivers/fpga/dfl.c|  1 +
 drivers/fpga/dfl.h| 85 +-
 include/linux/fpga/dfl.h  | 86 +++
 include/linux/mod_devicetable.h   | 12 ++
 scripts/mod/devicetable-offsets.c |  4 ++
 scripts/mod/file2alias.c  | 17 
 8 files changed, 123 insertions(+), 86 deletions(-)
 create mode 100644 include/linux/fpga/dfl.h

-- 
2.7.4

[PATCH] crypto: lib/chacha20poly1305 - Set SG_MITER_ATOMIC unconditionally

2020-09-14 Thread Herbert Xu

I trimmed the cc as the mailing lists appear to be blocking this
email because of it.

On Mon, Sep 14, 2020 at 03:37:49PM -0700, Linus Torvalds wrote:
>
> So it _looks_ like this code started using kmap() - probably back when
> kmap_atomic() was so cumbersome to use - and was then converted
> (conditionally) to kmap_atomic() rather than just changed whole-sale.
> Is there actually something that wants to use those sg_miter functions
> and sleep?

I dug up the old zinc patch submissions and this wasn't present at
all in the original.  The original zinc code used blkcipher_walk
which unconditinoally does kmap_atomic.

So it's only the SG miter conversion that introduced this change,
which appears to be a simple oversight (I think Ard was working on
latency issues at that time, perhaps he was worried about keeping
preemption off unnecessarily).

---8<---
There is no reason for the chacha20poly1305 SG miter code to use
kmap instead of kmap_atomic as the critical section doesn't sleep
anyway.  So we can simply get rid of the preemptible check and
set SG_MITER_ATOMIC unconditionally.

Even if we need to reenable preemption to lower latency we should
be doing that by interrupting the SG miter walk rather than using
kmap.

Reported-by: Linus Torvalds 
Signed-off-by: Herbert Xu 

diff --git a/lib/crypto/chacha20poly1305.c b/lib/crypto/chacha20poly1305.c
index 431e04280332..5850f3b87359 100644
--- a/lib/crypto/chacha20poly1305.c
+++ b/lib/crypto/chacha20poly1305.c
@@ -251,9 +251,7 @@ bool chacha20poly1305_crypt_sg_inplace(struct scatterlist 
*src,
poly1305_update(_state, pad0, 0x10 - (ad_len & 
0xf));
}

-   flags = SG_MITER_TO_SG;
-   if (!preemptible())
-   flags |= SG_MITER_ATOMIC;
+   flags = SG_MITER_TO_SG | SG_MITER_ATOMIC;

sg_miter_start(, src, sg_nents(src), flags);

-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

RE: [PATCH 1/3] dt-bindings: rtc-2127: Add bindings for nxp,rtc-2127.txt

2020-09-14 Thread Qiang Zhao

On Thu, Sep 14, 2020 at 22:36, Rob Herring  wrote:

> -Original Message-
> From: Rob Herring 
> Sent: 2020年9月14日 22:36
> To: Qiang Zhao 
> Cc: a.zu...@towertech.it; alexandre.bell...@bootlin.com;
> linux-...@vger.kernel.org; devicet...@vger.kernel.org;
> linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 1/3] dt-bindings: rtc-2127: Add bindings for
> nxp,rtc-2127.txt
> 
> > > > > >
> >
> > Please help to review as below, if it is ok, I will send the new version 
> > patch.
> Thank you!
> >
> > diff --git a/Documentation/devicetree/bindings/rtc/nxp,pcf2127.yaml
> > b/Documentation/devicetree/bindings/rtc/nxp,pcf2127.yaml
> > new file mode 100644
> > index 000..809dd59
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/rtc/nxp,pcf2127.yaml
> > @@ -0,0 +1,38 @@
> > +# SPDX-License-Identifier: GPL-2.0
> 
> Dual license new bindings please:
> > +
> > +title: PCF RTCs
> > +
> > +maintainers:
> > +  - Qiang Zhao 
> > +
> > +
> > +  no-watchdog:
> > +maxItems: 1
> 
> maxItems is for arrays. What's the type here? It should have a description 
> too.

Is it ok as below?
  no-watchdog:
$ref: /schemas/types.yaml#/definitions/flag
description:
  With this property, the device will not registered as a watchdog device.

> > >
> > > Documentation/devicetree/writing-schema.rst and about 1000 examples
> > > in the kernel tree.
> > >
> > > Rob
Best Regards
Qiang Zhao

Re: [PATCH RESEND RESEND] remoteproc: scp: add COMPILE_TEST dependency

2020-09-14 Thread Bjorn Andersson

On Tue 15 Sep 01:29 UTC 2020, Alexandre Courbot wrote:

> This will improve this driver's build coverage.
> 
> Reported-by: Ezequiel Garcia 
> Signed-off-by: Alexandre Courbot 
> ---
> Hi remoteproc maintainers,
> 
> Second resend as I got no reaction for almost 1 month on this one-liner.

Sorry about that. I fell behind on my inbox and have missed your
previous attempts.

This has now been applied.

Regards,
Bjorn

> Pretty please?
> 
> As explained in
> https://www.spinics.net/lists/linux-media/msg175991.html, we need this
> patch in order to merge a driver series in the media tree. If that
> looks ok to you, can we pull it in the media tree along with the series
> that depends on it?
> 
>  drivers/remoteproc/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> index c6659dfea7c7..d1fcada71017 100644
> --- a/drivers/remoteproc/Kconfig
> +++ b/drivers/remoteproc/Kconfig
> @@ -43,7 +43,7 @@ config INGENIC_VPU_RPROC
>  
>  config MTK_SCP
>   tristate "Mediatek SCP support"
> - depends on ARCH_MEDIATEK
> + depends on ARCH_MEDIATEK || COMPILE_TEST
>   select RPMSG_MTK_SCP
>   help
> Say y here to support Mediatek's System Companion Processor (SCP) via
> -- 
> 2.28.0.526.ge36021eeef-goog
>

Re: [PATCH v2 3/4] sparc64: remove mm_cpumask clearing to fix kthread_use_mm race

2020-09-14 Thread Nicholas Piggin

Excerpts from David Miller's message of September 15, 2020 5:59 am:
> From: Nicholas Piggin 
> Date: Mon, 14 Sep 2020 14:52:18 +1000
> 
>  ...
>> The basic fix for sparc64 is to remove its mm_cpumask clearing code. The
>> optimisation could be effectively restored by sending IPIs to mm_cpumask
>> members and having them remove themselves from mm_cpumask. This is more
>> tricky so I leave it as an exercise for someone with a sparc64 SMP.
>> powerpc has a (currently similarly broken) example.
>> 
>> Signed-off-by: Nicholas Piggin 
> 
> Sad to see this optimization go away, but what can I do:
> 
> Acked-by: David S. Miller 
> 

Thanks Dave, any objection if we merge this via the powerpc tree
to keep the commits together?

Thanks,
Nick

[PATCH 10/11] perf test: Free aliases for PMU event map aliases test

The aliases were never released causing the following leaks:

  Indirect leak of 1224 byte(s) in 9 object(s) allocated from:
#0 0x7feefb830628 in malloc (/lib/x86_64-linux-gnu/libasan.so.5+0x107628)
#1 0x56332c8f1b62 in __perf_pmu__new_alias util/pmu.c:322
#2 0x56332c8f401f in pmu_add_cpu_aliases_map util/pmu.c:778
#3 0x56332c792ce9 in __test__pmu_event_aliases tests/pmu-events.c:295
#4 0x56332c792ce9 in test_aliases tests/pmu-events.c:367
#5 0x56332c76a09b in run_test tests/builtin-test.c:410
#6 0x56332c76a09b in test_and_print tests/builtin-test.c:440
#7 0x56332c76ce69 in __cmd_test tests/builtin-test.c:695
#8 0x56332c76ce69 in cmd_test tests/builtin-test.c:807
#9 0x56332c7d2214 in run_builtin 
/home/namhyung/project/linux/tools/perf/perf.c:312
#10 0x56332c6701a8 in handle_internal_command 
/home/namhyung/project/linux/tools/perf/perf.c:364
#11 0x56332c6701a8 in run_argv 
/home/namhyung/project/linux/tools/perf/perf.c:408
#12 0x56332c6701a8 in main 
/home/namhyung/project/linux/tools/perf/perf.c:538
#13 0x7feefb359cc9 in __libc_start_main ../csu/libc-start.c:308

Cc: John Garry 
Acked-by: Jiri Olsa 
Fixes: 956a78356c24c ("perf test: Test pmu-events aliases")
Signed-off-by: Namhyung Kim 
---
 tools/perf/tests/pmu-events.c | 5 +
 tools/perf/util/pmu.c | 2 +-
 tools/perf/util/pmu.h | 1 +
 3 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/tools/perf/tests/pmu-events.c b/tools/perf/tests/pmu-events.c
index eb19f9a0bc15..d3517a74d95e 100644
--- a/tools/perf/tests/pmu-events.c
+++ b/tools/perf/tests/pmu-events.c
@@ -274,6 +274,7 @@ static int __test__pmu_event_aliases(char *pmu_name, int 
*count)
int res = 0;
bool use_uncore_table;
struct pmu_events_map *map = __test_pmu_get_events_map();
+   struct perf_pmu_alias *a, *tmp;
 
if (!map)
return -1;
@@ -347,6 +348,10 @@ static int __test__pmu_event_aliases(char *pmu_name, int 
*count)
  pmu_name, alias->name);
}
 
+   list_for_each_entry_safe(a, tmp, , list) {
+   list_del(>list);
+   perf_pmu_free_alias(a);
+   }
free(pmu);
return res;
 }
diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
index f1688e1f6ed7..555cb3524c25 100644
--- a/tools/perf/util/pmu.c
+++ b/tools/perf/util/pmu.c
@@ -274,7 +274,7 @@ static void perf_pmu_update_alias(struct perf_pmu_alias 
*old,
 }
 
 /* Delete an alias entry. */
-static void perf_pmu_free_alias(struct perf_pmu_alias *newalias)
+void perf_pmu_free_alias(struct perf_pmu_alias *newalias)
 {
zfree(>name);
zfree(>desc);
diff --git a/tools/perf/util/pmu.h b/tools/perf/util/pmu.h
index 44ccbdbb1c37..b63c4c5e335e 100644
--- a/tools/perf/util/pmu.h
+++ b/tools/perf/util/pmu.h
@@ -113,6 +113,7 @@ void pmu_add_cpu_aliases_map(struct list_head *head, struct 
perf_pmu *pmu,
 
 struct pmu_events_map *perf_pmu__find_map(struct perf_pmu *pmu);
 bool pmu_uncore_alias_match(const char *pmu_name, const char *name);
+void perf_pmu_free_alias(struct perf_pmu_alias *alias);
 
 int perf_pmu__convert_scale(const char *scale, char **end, double *sval);
 
-- 
2.28.0.618.gf4bc123cb7-goog

[PATCH 11/11] perf test: Free formats for perf pmu parse test

The following leaks were detected by ASAN:

  Indirect leak of 360 byte(s) in 9 object(s) allocated from:
#0 0x7fecc305180e in calloc (/lib/x86_64-linux-gnu/libasan.so.5+0x10780e)
#1 0x560578f6dce5 in perf_pmu__new_format util/pmu.c:1333
#2 0x560578f752fc in perf_pmu_parse util/pmu.y:59
#3 0x560578f6a8b7 in perf_pmu__format_parse util/pmu.c:73
#4 0x560578e07045 in test__pmu tests/pmu.c:155
#5 0x560578de109b in run_test tests/builtin-test.c:410
#6 0x560578de109b in test_and_print tests/builtin-test.c:440
#7 0x560578de401a in __cmd_test tests/builtin-test.c:661
#8 0x560578de401a in cmd_test tests/builtin-test.c:807
#9 0x560578e49354 in run_builtin 
/home/namhyung/project/linux/tools/perf/perf.c:312
#10 0x560578ce71a8 in handle_internal_command 
/home/namhyung/project/linux/tools/perf/perf.c:364
#11 0x560578ce71a8 in run_argv 
/home/namhyung/project/linux/tools/perf/perf.c:408
#12 0x560578ce71a8 in main 
/home/namhyung/project/linux/tools/perf/perf.c:538
#13 0x7fecc2b7acc9 in __libc_start_main ../csu/libc-start.c:308

Acked-by: Jiri Olsa 
Fixes: cff7f956ec4a1 ("perf tests: Move pmu tests into separate object")
Signed-off-by: Namhyung Kim 
---
 tools/perf/tests/pmu.c |  1 +
 tools/perf/util/pmu.c  | 11 +++
 tools/perf/util/pmu.h  |  1 +
 3 files changed, 13 insertions(+)

diff --git a/tools/perf/tests/pmu.c b/tools/perf/tests/pmu.c
index 5c11fe2b3040..714e6830a758 100644
--- a/tools/perf/tests/pmu.c
+++ b/tools/perf/tests/pmu.c
@@ -173,6 +173,7 @@ int test__pmu(struct test *test __maybe_unused, int subtest 
__maybe_unused)
ret = 0;
} while (0);
 
+   perf_pmu__del_formats();
test_format_dir_put(format);
return ret;
 }
diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
index 555cb3524c25..d41caeb35cf6 100644
--- a/tools/perf/util/pmu.c
+++ b/tools/perf/util/pmu.c
@@ -1354,6 +1354,17 @@ void perf_pmu__set_format(unsigned long *bits, long 
from, long to)
set_bit(b, bits);
 }
 
+void perf_pmu__del_formats(struct list_head *formats)
+{
+   struct perf_pmu_format *fmt, *tmp;
+
+   list_for_each_entry_safe(fmt, tmp, formats, list) {
+   list_del(>list);
+   free(fmt->name);
+   free(fmt);
+   }
+}
+
 static int sub_non_neg(int a, int b)
 {
if (b > a)
diff --git a/tools/perf/util/pmu.h b/tools/perf/util/pmu.h
index b63c4c5e335e..a64e9c9ce731 100644
--- a/tools/perf/util/pmu.h
+++ b/tools/perf/util/pmu.h
@@ -94,6 +94,7 @@ int perf_pmu__new_format(struct list_head *list, char *name,
 int config, unsigned long *bits);
 void perf_pmu__set_format(unsigned long *bits, long from, long to);
 int perf_pmu__format_parse(char *dir, struct list_head *head);
+void perf_pmu__del_formats(struct list_head *formats);
 
 struct perf_pmu *perf_pmu__scan(struct perf_pmu *pmu);
 
-- 
2.28.0.618.gf4bc123cb7-goog

[PATCH 07/11] perf metric: Release expr_parse_ctx after testing

The test_generic_metric() missed to release entries in the pctx.
Asan reported following leak (and more):

  Direct leak of 128 byte(s) in 1 object(s) allocated from:
#0 0x7f4c9396980e in calloc (/lib/x86_64-linux-gnu/libasan.so.5+0x10780e)
#1 0x55f7e748cc14 in hashmap_grow 
(/home/namhyung/project/linux/tools/perf/perf+0x90cc14)
#2 0x55f7e748d497 in hashmap__insert 
(/home/namhyung/project/linux/tools/perf/perf+0x90d497)
#3 0x55f7e7341667 in hashmap__set 
/home/namhyung/project/linux/tools/perf/util/hashmap.h:111
#4 0x55f7e7341667 in expr__add_ref util/expr.c:120
#5 0x55f7e7292436 in prepare_metric util/stat-shadow.c:783
#6 0x55f7e729556d in test_generic_metric util/stat-shadow.c:858
#7 0x55f7e712390b in compute_single tests/parse-metric.c:128
#8 0x55f7e712390b in __compute_metric tests/parse-metric.c:180
#9 0x55f7e712446d in compute_metric tests/parse-metric.c:196
#10 0x55f7e712446d in test_dcache_l2 tests/parse-metric.c:295
#11 0x55f7e712446d in test__parse_metric tests/parse-metric.c:355
#12 0x55f7e70be09b in run_test tests/builtin-test.c:410
#13 0x55f7e70be09b in test_and_print tests/builtin-test.c:440
#14 0x55f7e70c101a in __cmd_test tests/builtin-test.c:661
#15 0x55f7e70c101a in cmd_test tests/builtin-test.c:807
#16 0x55f7e7126214 in run_builtin 
/home/namhyung/project/linux/tools/perf/perf.c:312
#17 0x55f7e6fc41a8 in handle_internal_command 
/home/namhyung/project/linux/tools/perf/perf.c:364
#18 0x55f7e6fc41a8 in run_argv 
/home/namhyung/project/linux/tools/perf/perf.c:408
#19 0x55f7e6fc41a8 in main 
/home/namhyung/project/linux/tools/perf/perf.c:538
#20 0x7f4c93492cc9 in __libc_start_main ../csu/libc-start.c:308

Acked-by: Jiri Olsa 
Fixes: 6d432c4c8aa56 ("perf tools: Add test_generic_metric function")
Signed-off-by: Namhyung Kim 
---
 tools/perf/util/stat-shadow.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/tools/perf/util/stat-shadow.c b/tools/perf/util/stat-shadow.c
index e1ba6c1b916a..a5f42c22c484 100644
--- a/tools/perf/util/stat-shadow.c
+++ b/tools/perf/util/stat-shadow.c
@@ -853,14 +853,16 @@ static void generic_metric(struct perf_stat_config 
*config,
 double test_generic_metric(struct metric_expr *mexp, int cpu, struct 
runtime_stat *st)
 {
struct expr_parse_ctx pctx;
-   double ratio;
+   double ratio = 0.0;
 
if (prepare_metric(mexp->metric_events, mexp->metric_refs, , cpu, 
st) < 0)
-   return 0.;
+   goto out;
 
if (expr__parse(, , mexp->metric_expr, 1))
-   return 0.;
+   ratio = 0.0;
 
+out:
+   expr__ctx_clear();
return ratio;
 }
 
-- 
2.28.0.618.gf4bc123cb7-goog

[PATCH 08/11] perf metric: Free metric when it failed to resolve

The metricgroup__add_metric() can find multiple match for a metric
group and it's possible to fail.  Also it can fail in the middle like
in resolve_metric() even for single metric.

In those cases, the intermediate list and ids will be leaked like:

  Direct leak of 3 byte(s) in 1 object(s) allocated from:
#0 0x7f4c938f40b5 in strdup (/lib/x86_64-linux-gnu/libasan.so.5+0x920b5)
#1 0x55f7e71c1bef in __add_metric util/metricgroup.c:683
#2 0x55f7e71c31d0 in add_metric util/metricgroup.c:906
#3 0x55f7e71c3844 in metricgroup__add_metric util/metricgroup.c:940
#4 0x55f7e71c488d in metricgroup__add_metric_list util/metricgroup.c:993
#5 0x55f7e71c488d in parse_groups util/metricgroup.c:1045
#6 0x55f7e71c60a4 in metricgroup__parse_groups_test util/metricgroup.c:1087
#7 0x55f7e71235ae in __compute_metric tests/parse-metric.c:164
#8 0x55f7e7124650 in compute_metric tests/parse-metric.c:196
#9 0x55f7e7124650 in test_recursion_fail tests/parse-metric.c:318
#10 0x55f7e7124650 in test__parse_metric tests/parse-metric.c:356
#11 0x55f7e70be09b in run_test tests/builtin-test.c:410
#12 0x55f7e70be09b in test_and_print tests/builtin-test.c:440
#13 0x55f7e70c101a in __cmd_test tests/builtin-test.c:661
#14 0x55f7e70c101a in cmd_test tests/builtin-test.c:807
#15 0x55f7e7126214 in run_builtin 
/home/namhyung/project/linux/tools/perf/perf.c:312
#16 0x55f7e6fc41a8 in handle_internal_command 
/home/namhyung/project/linux/tools/perf/perf.c:364
#17 0x55f7e6fc41a8 in run_argv 
/home/namhyung/project/linux/tools/perf/perf.c:408
#18 0x55f7e6fc41a8 in main 
/home/namhyung/project/linux/tools/perf/perf.c:538
#19 0x7f4c93492cc9 in __libc_start_main ../csu/libc-start.c:308

Acked-by: Jiri Olsa 
Fixes: 83de0b7d535de ("perf metric: Collect referenced metrics in struct 
metric_ref_node")
Signed-off-by: Namhyung Kim 
---
 tools/perf/util/metricgroup.c | 17 -
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/tools/perf/util/metricgroup.c b/tools/perf/util/metricgroup.c
index 53747df601fa..35bcaa8d11e9 100644
--- a/tools/perf/util/metricgroup.c
+++ b/tools/perf/util/metricgroup.c
@@ -940,7 +940,7 @@ static int metricgroup__add_metric(const char *metric, bool 
metric_no_group,
 
ret = add_metric(, pe, metric_no_group, , NULL, );
if (ret)
-   return ret;
+   goto out;
 
/*
 * Process any possible referenced metrics
@@ -949,12 +949,14 @@ static int metricgroup__add_metric(const char *metric, 
bool metric_no_group,
ret = resolve_metric(metric_no_group,
 , map, );
if (ret)
-   return ret;
+   goto out;
}
 
/* End of pmu events. */
-   if (!has_match)
-   return -EINVAL;
+   if (!has_match) {
+   ret = -EINVAL;
+   goto out;
+   }
 
list_for_each_entry(m, , nd) {
if (events->len > 0)
@@ -969,9 +971,14 @@ static int metricgroup__add_metric(const char *metric, 
bool metric_no_group,
}
}
 
+out:
+   /*
+* add to metric_list so that they can be released
+* even if it's failed
+*/
list_splice(, metric_list);
expr_ids__exit();
-   return 0;
+   return ret;
 }
 
 static int metricgroup__add_metric_list(const char *list, bool metric_no_group,
-- 
2.28.0.618.gf4bc123cb7-goog

[PATCH 05/11] perf parse-event: Fix memory leak in evsel->unit

The evsel->unit borrows a pointer of pmu event or alias instead of
owns a string.  But tool event (duration_time) passes a result of
strdup() caused a leak.

It was found by ASAN during metric test:

  Direct leak of 210 byte(s) in 70 object(s) allocated from:
#0 0x7fe366fca0b5 in strdup (/lib/x86_64-linux-gnu/libasan.so.5+0x920b5)
#1 0x559fbbcc6ea3 in add_event_tool util/parse-events.c:414
#2 0x559fbbcc6ea3 in parse_events_add_tool util/parse-events.c:1414
#3 0x559fbbd8474d in parse_events_parse util/parse-events.y:439
#4 0x559fbbcc95da in parse_events__scanner util/parse-events.c:2096
#5 0x559fbbcc95da in __parse_events util/parse-events.c:2141
#6 0x559fbbc28555 in check_parse_id tests/pmu-events.c:406
#7 0x559fbbc28555 in check_parse_id tests/pmu-events.c:393
#8 0x559fbbc28555 in check_parse_cpu tests/pmu-events.c:415
#9 0x559fbbc28555 in test_parsing tests/pmu-events.c:498
#10 0x559fbbc0109b in run_test tests/builtin-test.c:410
#11 0x559fbbc0109b in test_and_print tests/builtin-test.c:440
#12 0x559fbbc03e69 in __cmd_test tests/builtin-test.c:695
#13 0x559fbbc03e69 in cmd_test tests/builtin-test.c:807
#14 0x559fbbc691f4 in run_builtin 
/home/namhyung/project/linux/tools/perf/perf.c:312
#15 0x559fbbb071a8 in handle_internal_command 
/home/namhyung/project/linux/tools/perf/perf.c:364
#16 0x559fbbb071a8 in run_argv 
/home/namhyung/project/linux/tools/perf/perf.c:408
#17 0x559fbbb071a8 in main 
/home/namhyung/project/linux/tools/perf/perf.c:538
#18 0x7fe366b68cc9 in __libc_start_main ../csu/libc-start.c:308

Acked-by: Jiri Olsa 
Fixes: f0fbb114e3025 ("perf stat: Implement duration_time as a proper event")
Signed-off-by: Namhyung Kim 
---
 tools/perf/util/parse-events.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
index b35e4bb1cecb..ece321ccf599 100644
--- a/tools/perf/util/parse-events.c
+++ b/tools/perf/util/parse-events.c
@@ -416,7 +416,7 @@ static int add_event_tool(struct list_head *list, int *idx,
return -ENOMEM;
evsel->tool_event = tool_event;
if (tool_event == PERF_TOOL_DURATION_TIME)
-   evsel->unit = strdup("ns");
+   evsel->unit = "ns";
return 0;
 }
 
-- 
2.28.0.618.gf4bc123cb7-goog

[PATCH 09/11] perf metric: Do not free metric when failed to resolve

It's dangerous to free the original metric when it's called from
resolve_metric() as it's already in the metric_list and might have
other resources too.  Instead, it'd better let them bail out and be
released properly at the later stage.

So add a check when it's called from metricgroup__add_metric() and
release it.  Also make sure that mp is set properly.

Acked-by: Jiri Olsa 
Fixes: 83de0b7d535de ("perf metric: Collect referenced metrics in struct 
metric_ref_node")
Signed-off-by: Namhyung Kim 
---
 tools/perf/util/metricgroup.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/tools/perf/util/metricgroup.c b/tools/perf/util/metricgroup.c
index 35bcaa8d11e9..941702cb6a79 100644
--- a/tools/perf/util/metricgroup.c
+++ b/tools/perf/util/metricgroup.c
@@ -673,7 +673,6 @@ static int __add_metric(struct list_head *metric_list,
m->has_constraint = metric_no_group || 
metricgroup__has_constraint(pe);
INIT_LIST_HEAD(>metric_refs);
m->metric_refs_cnt = 0;
-   *mp = m;
 
parent = expr_ids__alloc(ids);
if (!parent) {
@@ -686,6 +685,7 @@ static int __add_metric(struct list_head *metric_list,
free(m);
return -ENOMEM;
}
+   *mp = m;
} else {
/*
 * We got here for the referenced metric, via the
@@ -720,8 +720,11 @@ static int __add_metric(struct list_head *metric_list,
 * all the metric's IDs and add it to the parent context.
 */
if (expr__find_other(pe->metric_expr, NULL, >pctx, runtime) < 0) {
-   expr__ctx_clear(>pctx);
-   free(m);
+   if (m->metric_refs_cnt == 0) {
+   expr__ctx_clear(>pctx);
+   free(m);
+   *mp = NULL;
+   }
return -EINVAL;
}
 
-- 
2.28.0.618.gf4bc123cb7-goog

回复: RCU: Question on force_qs_rnp

2020-09-14 Thread Zhang, Qiang




发件人: Paul E. McKenney 
发送时间: 2020年9月15日 4:56
收件人: Joel Fernandes
抄送: Zhang, Qiang; Uladzislau Rezki; j...@joshtriplett.org; rost...@goodmis.org; 
mathieu.desnoy...@efficios.com; Lai Jiangshan; r...@vger.kernel.org; LKML
主题: Re: RCU: Question on force_qs_rnp

On Mon, Sep 14, 2020 at 03:42:08PM -0400, Joel Fernandes wrote:
> On Mon, Sep 14, 2020 at 07:55:18AM +, Zhang, Qiang wrote:
> > Hello Paul
> >
> > I have some questions for you .
> > in force_qs_rnp func ,  if  "f(rdp)" func return true we will call 
> > rcu_report_qs_rnp func
> > report a quiescent state for this rnp node, and clear grpmask form 
> > rnp->qsmask.
> > after that ,  can we make a check for this rnp->qsmask,  if  rnp->qsmask == 
> > 0,
> > we will check blocked readers in this rnp node,  instead of jumping 
> > directly to the next node .
>
> Could you clarify what good is this going to do? What problem are you trying 
> to
> address?
>
> You could have a task that is blocked in an RCU leaf node, but the
> force_qs_rnp() decided to call rcu_report_qs_rnp(). This is perfectly Ok. The
> CPU could be dyntick-idle and a quiescent state is reported. However, the GP
> must not end and the rcu leaf node should still be present in its parent
> intermediate nodes ->qsmask. In this case, the ->qsmask == 0 does not have
> any relevance.
>
> Or am I missing the point of the question?

>Hello, Qiang,

>Another way of making Joel's point is to say that the additional check
>you are asking for is already being done, but by rcu_report_qs_rnp().

>Thanx, Paul

Hello Pual,  Joel

What I want to express is as follows :

diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 7623128d0020..beb554539f01 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -2622,6 +2622,11 @@ static void force_qs_rnp(int (*f)(struct rcu_data *rdp))
if (mask != 0) {
/* Idle/offline CPUs, report (releases rnp->lock). */
rcu_report_qs_rnp(mask, rnp, rnp->gp_seq, flags);
+   raw_spin_lock_irqsave_rcu_node(rnp, flags);
+   if (rnp->qsmask == 0 && 
rcu_preempt_blocked_readers_cgp(rnp))
+   rcu_initiate_boost(rnp, flags);
+   else
+   raw_spin_unlock_irqrestore_rcu_node(rnp, flags);
} else {
/* Nothing to do here, so just drop the lock. */
raw_spin_unlock_irqrestore_rcu_node(rnp, flags);


Thanks

Qiang

[PATCH 04/11] perf parse-event: Fix cpu map leaks