Re: [PATCH] clocksource: ti-32k: Add CLOCK_SOURCE_SUSPEND_NONSTOP flag for non-am43 SoCs

[Tony Lindgren]

* Keerthy  [180807 09:29]:
> The 32k clocksource is NONSTOP for non-am43 SoCs. Hence
> add the flag for all the other SoCs.
> 
> Reported-by: Tony Lindgren 
> Signed-off-by: Keerthy  

Acked-by: Tony Lindgren 

> ---
>  drivers/clocksource/timer-ti-32k.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/clocksource/timer-ti-32k.c 
> b/drivers/clocksource/timer-ti-32k.c
> index 29e2e1a..dd09171 100644
> --- a/drivers/clocksource/timer-ti-32k.c
> +++ b/drivers/clocksource/timer-ti-32k.c
> @@ -97,6 +97,9 @@ static int __init ti_32k_timer_init(struct device_node *np)
>   return -ENXIO;
>   }
>  
> + if (!of_machine_is_compatible("ti,am4372"))
> + ti_32k_timer.cs.flags |= CLOCK_SOURCE_SUSPEND_NONSTOP;
> +
>   ti_32k_timer.counter = ti_32k_timer.base;
>  
>   /*
> -- 
> 1.9.1
> 

Re: [PATCH] fs/buffer.c: Optimize grow_buffer function.

[Sean Fu]

On Sat, Jul 21, 2018 at 07:21:16PM +0100, Al Viro wrote:
> On Sun, Jul 22, 2018 at 01:30:17AM +0800, Sean Fu wrote:
> > Use PAGE_SHIFT and i_blkbits of bd_inode directly to avoid ugly sizebits
> > calculation.
> > Remove ugly sizebits calculation.
> > Remove unnecessary sizebits parameter of grow_dev_page.
> > 
> > Reduces code size:
> > 
> > Before:
> > 
> > sean@linux-zmni:~/sda5/source/linus_repo/linux> size fs/buffer.o
> >textdata bss dec hex filename
> >   340371510  16   355638aeb fs/buffer.o
> > 
> > After:
> > 
> > sean@linux-zmni:~/sda5/source/linus_repo/linux> size fs/buffer.o
> >textdata bss dec hex filename
> >   340211510  16   355478adb fs/buffer.o
> 
> First of all, 16 bytes is pretty much noise.  What's more, the "remove ugly
> sizebits calculation" part really needs an explanation of the reasons why
> it's safe.  You assume that size == 1i_blkbits; where's
> the proof that it always holds?

Got it, Thanks
This size can be page size(4096) besides block size 
(1i_blkbits).

I have another question about __getblk_slow function in fs/buffer.c
Actually __find_get_block already was invoked before entering __getblk_slow.
Can we move __find_get_block after grow_buffers in for loop of __getblk_slow?

for (;;) {
...
ret = grow_buffers(bdev, block, size, gfp);
...
bh = __find_get_block(bdev, block, size);
...
}

Re: [RFC PATCH 2/3] mm/memory_hotplug: Create __shrink_pages and move it to offline_pages

[Michal Hocko]

On Tue 07-08-18 11:18:10, Jerome Glisse wrote:
> On Tue, Aug 07, 2018 at 04:59:00PM +0200, Michal Hocko wrote:
> > On Tue 07-08-18 09:52:21, Jerome Glisse wrote:
> > > On Tue, Aug 07, 2018 at 03:37:56PM +0200, osalva...@techadventures.net 
> > > wrote:
> > > > From: Oscar Salvador 
> > > 
> > > [...]
> > > 
> > > > diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> > > > index 9bd629944c91..e33555651e46 100644
> > > > --- a/mm/memory_hotplug.c
> > > > +++ b/mm/memory_hotplug.c
> > > 
> > > [...]
> > > 
> > > >  /**
> > > >   * __remove_pages() - remove sections of pages from a zone
> > > > - * @zone: zone from which pages need to be removed
> > > > + * @nid: node which pages belong to
> > > >   * @phys_start_pfn: starting pageframe (must be aligned to start of a 
> > > > section)
> > > >   * @nr_pages: number of pages to remove (must be multiple of section 
> > > > size)
> > > >   * @altmap: alternative device page map or %NULL if default memmap is 
> > > > used
> > > > @@ -548,7 +557,7 @@ static int __remove_section(struct zone *zone, 
> > > > struct mem_section *ms,
> > > >   * sure that pages are marked reserved and zones are adjust properly by
> > > >   * calling offline_pages().
> > > >   */
> > > > -int __remove_pages(struct zone *zone, unsigned long phys_start_pfn,
> > > > +int __remove_pages(int nid, unsigned long phys_start_pfn,
> > > >  unsigned long nr_pages, struct vmem_altmap *altmap)
> > > >  {
> > > > unsigned long i;
> > > > @@ -556,10 +565,9 @@ int __remove_pages(struct zone *zone, unsigned 
> > > > long phys_start_pfn,
> > > > int sections_to_remove, ret = 0;
> > > >  
> > > > /* In the ZONE_DEVICE case device driver owns the memory region 
> > > > */
> > > > -   if (is_dev_zone(zone)) {
> > > > -   if (altmap)
> > > > -   map_offset = vmem_altmap_offset(altmap);
> > > > -   } else {
> > > > +   if (altmap)
> > > > +   map_offset = vmem_altmap_offset(altmap);
> > > > +   else {
> > > 
> > > This will break ZONE_DEVICE at least for HMM. While i think that
> > > altmap -> ZONE_DEVICE (ie altmap imply ZONE_DEVICE) the reverse
> > > is not true ie ZONE_DEVICE does not necessarily imply altmap. So
> > > with the above changes you change the expected behavior.
> > 
> > Could you be more specific what is the expected behavior here?
> > Is this about calling release_mem_region_adjustable? Why does is it not
> > suitable for zone device ranges?
> 
> Correct, you should not call release_mem_region_adjustable() the device
> region is not part of regular iomem resource as it might not necessarily
> be enumerated through known ways to the kernel (ie only the device driver
> can discover the region and core kernel do not know about it).

If there is no region registered with the range then the call should be
mere nop, no? So why do we have to special case?

[...]

> Also in the case they do exist in iomem resource it is as PCIE BAR so
> as IORESOURCE_IO (iirc) and thus release_mem_region_adjustable() would
> return -EINVAL. Thought nothing bad happens because of that, only a
> warning message that might confuse the user.

I am not sure I have understood this correctly. Are you referring to the
current state when we would call release_mem_region_adjustable
unconditionally or the case that the resource would be added also for
zone device ranges?

If the former then I do not see any reason why we couldn't simply
refactor the code to expect a failure and drop the warning in that path.
-- 
Michal Hocko
SUSE Labs

Re: [PATCH] nds32: add NULL entry to the end of_device_id array

[Greentime Hu]

YueHaibing  於 2018年8月7日 週二 下午12:03寫道：
>
> Make sure of_device_id tables are NULL terminated.
> Found by coccinelle spatch "misc/of_table.cocci"
>
> Signed-off-by: YueHaibing 
> ---
>  arch/nds32/kernel/atl2c.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/nds32/kernel/atl2c.c b/arch/nds32/kernel/atl2c.c
> index 0c6d031..0c5386e 100644
> --- a/arch/nds32/kernel/atl2c.c
> +++ b/arch/nds32/kernel/atl2c.c
> @@ -9,7 +9,8 @@
>
>  void __iomem *atl2c_base;
>  static const struct of_device_id atl2c_ids[] __initconst = {
> -   {.compatible = "andestech,atl2c",}
> +   {.compatible = "andestech,atl2c",},
> +   {}
>  };
>
>  static int __init atl2c_of_init(void)

Hi Yuehaibing,

Thank you for your patch.
Acked-by: Greentime Hu 

Re: [PATCH 09/11] RISC-V: Support per-hart timebase-frequency

[Atish Patra]

On 8/6/18 1:34 PM, Palmer Dabbelt wrote:

On Fri, 03 Aug 2018 05:33:57 PDT (-0700), Christoph Hellwig wrote:

On Thu, Aug 02, 2018 at 03:19:49PM -0700, Atish Patra wrote:

On 8/2/18 4:50 AM, Christoph Hellwig wrote:

From: Palmer Dabbelt 

Follow the updated DT specs and read the timebase-frequency from the
CPU 0 node.



However, the DT in the HighFive Unleashed has the entry at the wrong place.

Even the example in github also at wrong place.
https://github.com/riscv/riscv-device-tree-doc/pull/8/commits/2461d481329c55005fcbe684f0d6bdb3b7f0a432

DT should be consistent between Documentation and the one in the hardware.
I can fix them in bbl & submit a bbl patch. But I am not sure if that's an
acceptable way to do it.


I'll need to have comments from Palmer and/or someone else at SiFive
here.  Personally I really don't care where we document the timebase,
as this patch supports both locations anywhere.  For now I'll just update
the commit log to state that more explicitly.


You're welcome to submit a BBL patch to make this all match, but from my
understanding of the device tree spec putting timebase-frequency in either
place should be legal so it's not a critical fix.  That said, it's better to
have them match than not match.



ok. I will add it my TODO list as a low priority task. Following DT 
entries can be fixed for now.


1. timebase-frequency
2. next-level-cache

Regards,
Atish

Re: [PATCH] memcg, oom: be careful about races when warning about no reclaimable task

[Michal Hocko]

On Tue 07-08-18 16:54:25, Johannes Weiner wrote:
> On Tue, Aug 07, 2018 at 10:23:32PM +0200, Michal Hocko wrote:
> > On Tue 07-08-18 16:02:47, Johannes Weiner wrote:
> > > On Tue, Aug 07, 2018 at 09:25:53AM +0200, Michal Hocko wrote:
> > > > From: Michal Hocko 
> > > > 
> > > > "memcg, oom: move out_of_memory back to the charge path" has added a
> > > > warning triggered when the oom killer cannot find any eligible task
> > > > and so there is no way to reclaim the oom memcg under its hard limit.
> > > > Further charges for such a memcg are forced and therefore the hard limit
> > > > isolation is weakened.
> > > > 
> > > > The current warning is however too eager to trigger  even when we are 
> > > > not
> > > > really hitting the above condition. Syzbot[1] and Greg Thelen have 
> > > > noticed
> > > > that we can hit this condition even when there is still oom victim
> > > > pending. E.g. the following race is possible:
> > > > 
> > > > memcg has two tasks taskA, taskB.
> > > > 
> > > > CPU1 (taskA)CPU2CPU3 (taskB)
> > > > try_charge
> > > >   mem_cgroup_out_of_memory  try_charge
> > > >   select_bad_process(taskB)
> > > >   oom_kill_process  oom_reap_task
> > > > # No real memory reaped
> > > >   
> > > > mem_cgroup_out_of_memory
> > > > # set taskB -> MMF_OOM_SKIP
> > > >   # retry charge
> > > >   mem_cgroup_out_of_memory
> > > > oom_lockoom_lock
> > > > select_bad_process(self)
> > > > oom_kill_process(self)
> > > > oom_unlock
> > > > # no 
> > > > eligible task
> > > > 
> > > > In fact syzbot test triggered this situation by placing multiple tasks
> > > > into a memcg with hard limit set to 0. So no task really had any memory
> > > > charged to the memcg
> > > > 
> > > > : Memory cgroup stats for /ile0: cache:0KB rss:0KB rss_huge:0KB 
> > > > shmem:0KB mapped_file:0KB dirty:0KB writeback:0KB swap:0KB 
> > > > inactive_anon:0KB active_anon:0KB inactive_file:0KB active_file:0KB 
> > > > unevictable:0KB
> > > > : Tasks state (memory values in pages):
> > > > : [  pid  ]   uid  tgid total_vm  rss pgtables_bytes swapents 
> > > > oom_score_adj name
> > > > : [   6569] 0  6562 94271532480 
> > > > 0 syz-executor0
> > > > : [   6576] 0  6576 94260614400 
> > > > 0 syz-executor6
> > > > : [   6578] 0  6578 9426  534614400 
> > > > 0 syz-executor4
> > > > : [   6579] 0  6579 94260573440 
> > > > 0 syz-executor5
> > > > : [   6582] 0  6582 94260614400 
> > > > 0 syz-executor7
> > > > : [   6584] 0  6584 94260573440 
> > > > 0 syz-executor1
> > > > 
> > > > so in principle there is indeed nothing reclaimable in this memcg and
> > > > this looks like a misconfiguration. On the other hand we can clearly
> > > > kill all those tasks so it is a bit early to warn and scare users. Do
> > > > that by checking that the current is the oom victim and bypass the
> > > > warning then. The victim is allowed to force charge and terminate to
> > > > release its temporal charge along the way.
> > > > 
> > > > [1] http://lkml.kernel.org/r/5e979605729c1...@google.com
> > > > Fixes: "memcg, oom: move out_of_memory back to the charge path"
> > > > Noticed-by: Greg Thelen 
> > > > Reported-and-tested-by: 
> > > > syzbot+bab151e82a4e973fa...@syzkaller.appspotmail.com
> > > > Signed-off-by: Michal Hocko 
> > > > ---
> > > >  mm/memcontrol.c | 3 ++-
> > > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> > > > index 4603ad75c9a9..1b6eed1bc404 100644
> > > > --- a/mm/memcontrol.c
> > > > +++ b/mm/memcontrol.c
> > > > @@ -1703,7 +1703,8 @@ static enum oom_status mem_cgroup_oom(struct 
> > > > mem_cgroup *memcg, gfp_t mask, int
> > > > return OOM_ASYNC;
> > > > }
> > > >  
> > > > -   if (mem_cgroup_out_of_memory(memcg, mask, order))
> > > > +   if (mem_cgroup_out_of_memory(memcg, mask, order) ||
> > > > +   tsk_is_oom_victim(current))
> > > > return OOM_SUCCESS;
> > > >  
> > > > WARN(1,"Memory cgroup charge failed because of no reclaimable 
> > > > memory! "
> > > 
> > > This is really ugly. :(
> > > 
> > > If that check is only there to suppress the warning when the limit is
> > > 0, this should really be a separate branch around the warning, with a
> > > fat comment that this is a ridiculous cornercase, and not look like it
> > > is an essential part of the memcg reclaim/oom process.
> > 
> > I do not mind having it in a sepa

Re: [PATCH 03/11] dt-bindings: interrupt-controller: RISC-V PLIC documentation

[Atish Patra]

On 8/7/18 7:17 PM, Palmer Dabbelt wrote:

On Mon, 06 Aug 2018 13:59:48 PDT (-0700), robh...@kernel.org wrote:

On Thu, Aug 2, 2018 at 4:08 PM Atish Patra  wrote:


On 8/2/18 4:50 AM, Christoph Hellwig wrote:

From: Palmer Dabbelt 

This patch adds documentation for the platform-level interrupt
controller (PLIC) found in all RISC-V systems.  This interrupt
controller routes interrupts from all the devices in the system to each
hart-local interrupt controller.

Note: the DTS bindings for the PLIC aren't set in stone yet, as we might
want to change how we're specifying holes in the hart list.

Signed-off-by: Palmer Dabbelt 
[hch: various fixes and updates]
Signed-off-by: Christoph Hellwig 
---
   .../interrupt-controller/sifive,plic0.txt | 57 +++
   1 file changed, 57 insertions(+)
   create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/sifive,plic0.txt

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/sifive,plic0.txt 
b/Documentation/devicetree/bindings/interrupt-controller/sifive,plic0.txt
new file mode 100644
index ..c756cd208a93
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/sifive,plic0.txt
@@ -0,0 +1,57 @@
+SiFive Platform-Level Interrupt Controller (PLIC)
+-
+
+SiFive SOCs include an implementation of the Platform-Level Interrupt 
Controller
+(PLIC) high-level specification in the RISC-V Privileged Architecture
+specification.  The PLIC connects all external interrupts in the system to all
+hart contexts in the system, via the external interrupt source in each hart.
+
+A hart context is a privilege mode in a hardware execution thread.  For 
example,
+in an 4 core system with 2-way SMT, you have 8 harts and probably at least two
+privilege modes per hart; machine mode and supervisor mode.
+
+Each interrupt can be enabled on per-context basis. Any context can claim
+a pending enabled interrupt and then release it once it has been handled.
+
+Each interrupt has a configurable priority. Higher priority interrupts are
+serviced first. Each context can specify a priority threshold. Interrupts
+with priority below this threshold will not cause the PLIC to raise its
+interrupt line leading to the context.
+
+While the PLIC supports both edge-triggered and level-triggered interrupts,
+interrupt handlers are oblivious to this distinction and therefore it is not
+specified in the PLIC device-tree binding.
+
+While the RISC-V ISA doesn't specify a memory layout for the PLIC, the
+"sifive,plic0" device is a concrete implementation of the PLIC that contains a
+specific memory layout, which is documented in chapter 8 of the SiFive U5
+Coreplex Series Manual .
+
+Required properties:
+- compatible : "sifive,plic0"


I think there was a thread bouncing around somewhere where decided to pick the
official name of the compatible string to be "sifive,plic-1.0".  The idea here
is that the PLIC is compatible across all of SiFive's current implementations,
but there's some limitations in the memory map that will probably cause us to
spin a version 2 at some point so we want major version number.  The minor
number is just in case we find some errata in the PLIC.


+- #address-cells : should be <0>
+- #interrupt-cells : should be <1>
+- interrupt-controller : Identifies the node as an interrupt controller
+- reg : Should contain 1 register range (address and length)


The one in the real device tree has two entries.
reg = <0x 0x0c00 0x 0x0400>;

Is it intentional or just incorrect entry left over from earlier days?



+ reg = <0xc00 0x400>;


Looks to me like one has #size-cells and #address-cells set to 2 and
the example is using 1.


Yes.  For some background on how this works: we have a hardware generator that
has a tree-of-busses abstraction, and each device is attached to some point on
that tree.  When a device gets attached to the bus, we also generate a device
tree entry.  For whatever system I generated the example PLIC device tree entry
from, it must have been attached to a bus with addresses of 32 bits or less,
which resulted in #address-cells and #size-cells being 1.



Thanks Palmer for the detailed explanation.


Christoph has a HiFive Unleashed, which has a fu540-c000 on it, which is
probably not what I generated as an example -- the fu540-c000 is a complicated
configuration, when I mess around with the hardware I tend to use simple ones
as I'm not really a hardware guy.  I suppose the bus that the PLIC is hanging
off on the fu540-c000 has addresses wider than 32 bits.  This makes sense, as
the machine has 8GiB of memory and the PLIC is on a bus that's closer to the
core than the DRAM is, so it'd need at least enough address bits to fit 8GiB.

Is the inconsistency a problem?  I generally write device tree handling code to
just respect whatever #*-fields says and don't con

Re: [PATCH 2/3] perf report: Add raw report support for s390 auxiliary trace

[Thomas-Mich Richter]

On 08/08/2018 05:37 AM, m...@ellerman.id.au wrote:
> Thomas Richter  writes:
>> Add support for s390 auxiliary trace support.
>> Use 'perf record -e rbd000' to create the perf.data file.
>> The event also has the symbolic name SF_CYCLES_BASIC_DIAG,
>> using 'perf record -e SF_CYCLES_BASIC_DIAG' is equivalent.
> ...
>>
>> Signed-off-by: Thomas Richter 
>> Reviewed-by: Hendrik Brueckner 
>> ---
>>  tools/perf/util/s390-cpumsf-kernel.h |  71 
>>  tools/perf/util/s390-cpumsf.c| 244 ++-
>>  2 files changed, 314 insertions(+), 1 deletion(-)
>>  create mode 100644 tools/perf/util/s390-cpumsf-kernel.h
> 
> 
> I'm seeing a build break on ppc64le which seems to be caused by this
> commit (I haven't bisected):
> 
>   util/s390-cpumsf.c: In function ‘trailer_timestamp’:
>   util/s390-cpumsf.c:222:2: error: dereferencing type-punned pointer will 
> break strict-aliasing rules [-Werror=strict-aliasing]
> return *((unsigned long long *) &te->timestamp[te->t]);
> ^
> 
> 
> And on powerpc big endian:
>   In file included from util/cpumap.h:10:0,
>from util/s390-cpumsf.c:150:
>   util/s390-cpumsf.c: In function ‘s390_cpumsf_basic_show’:
>   util/s390-cpumsf.c:187:10: error: format ‘%lx’ expects argument of type 
> ‘long unsigned int’, but argument 4 has type ‘size_t {aka unsigned int}’ 
> [-Werror=format=]
>  pr_err("Invalid AUX trace basic entry [%#08lx]\n", pos);
> ^
> 
> cheers
> 

Can you please try this patch. Thanks a lot

-- 
Thomas Richter, Dept 3303, IBM s390 Linux Development, Boeblingen, Germany
--
Vorsitzende des Aufsichtsrats: Martina Koederitz 
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, HRB 
243294
>From add6a709f79e20e8b4eaa6ded2bd1af043f8a235 Mon Sep 17 00:00:00 2001
From: Thomas Richter 
Date: Wed, 8 Aug 2018 07:11:23 +0100
Subject: [PATCH] perf report: Fix build error for s390 auxiliary trace support
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Commit 73a48b7e ("perf report: Add raw report support for s390 auxiliary trace")
introduced a compile errors on powerpc:
  util/s390-cpumsf.c: In function ‘trailer_timestamp’:
  util/s390-cpumsf.c:222:2: error: dereferencing type-punned pointer will
	break strict-aliasing rules [-Werror=strict-aliasing]
	return *((unsigned long long *) &te->timestamp[te->t]);
	^

  In file included from util/cpumap.h:10:0,
   from util/s390-cpumsf.c:150:
  util/s390-cpumsf.c: In function ‘s390_cpumsf_basic_show’:
  util/s390-cpumsf.c:187:10: error: format ‘%lx’ expects argument of type
	‘long unsigned int’, but argument 4 has type
	‘size_t {aka unsigned int}’ [-Werror=format=]
 pr_err("Invalid AUX trace basic entry [%#08lx]\n", pos);
^

Fix these errors:
1. Use memcpy to extract value from character array.
2. Use %zu as format string in pr_err

Fixes: 73a48b7e
Signed-off-by: Thomas Richter 
---
 tools/perf/util/s390-cpumsf.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/s390-cpumsf.c b/tools/perf/util/s390-cpumsf.c
index 1604ddb3..2bcb160a08f0 100644
--- a/tools/perf/util/s390-cpumsf.c
+++ b/tools/perf/util/s390-cpumsf.c
@@ -184,7 +184,7 @@ static bool s390_cpumsf_basic_show(const char *color, size_t pos,
    struct hws_basic_entry *basic)
 {
 	if (basic->def != 1) {
-		pr_err("Invalid AUX trace basic entry [%#08lx]\n", pos);
+		pr_err("Invalid AUX trace basic entry [%#08zx]\n", pos);
 		return false;
 	}
 	color_fprintf(stdout, color, "[%#08x] Basic   Def:%04x Inst:%#04x"
@@ -219,7 +219,10 @@ static unsigned long long trailer_timestamp(struct hws_trailer_entry *te)
 	/* te->t set: TOD in STCKE format, bytes 8-15
 	 * to->t not set: TOD in STCK format, bytes 0-7
 	 */
-	return *((unsigned long long *) &te->timestamp[te->t]);
+	unsigned long long ts;
+
+	memcpy(&ts, &te->timestamp[te->t], sizeof(ts));
+	return ts;
 }
 
 /* Display s390 CPU measurement facility trailer entry */
-- 
2.14.3

Re: [GIT PULL] FSI fixes for 4.19

[Greg Kroah-Hartman]

On Wed, Aug 08, 2018 at 03:50:53PM +1000, Benjamin Herrenschmidt wrote:
> Hi Greg !
> 
> This adds two FSI fixes to what you already have in your tree
> 
>   - Fix a NULL dereference in the scom driver
> 
>   - Fix a command buffer size issue in the sbefifo driver that
> breaks some operations with POWER system debugger (cronus)
> 
> Cheers,
> Ben.
> 
> The following changes since tag fsi-updates-2018-07-27:
> 
>   fsi: Prevent multiple concurrent rescans (2018-07-27 09:58:12 +1000)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/benh/linux-fsi.git 
> tags/fsi-updates-2018-08-08

PUlled and pushed out, thanks.
greg k-h

Re: [PATCH 4.17 00/18] 4.17.14-stable review

[Greg Kroah-Hartman]

On Wed, Aug 08, 2018 at 10:50:20AM +0530, Naresh Kamboju wrote:
> On 8 August 2018 at 00:21, Greg Kroah-Hartman
>  wrote:
> > This is the start of the stable review cycle for the 4.17.14 release.
> > There are 18 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Thu Aug  9 17:23:05 UTC 2018.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > 
> > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.17.14-rc1.gz
> > or in the git tree and branch at:
> > 
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> > linux-4.17.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
> 
> 
> Results from Linaro’s test farm.
> No regressions on arm64, arm and x86_64.

Great!  Thanks for testing these and letting me know.

greg k-h

Re: [PATCH 3.18 00/85] 3.18.118-stable review

[Greg Kroah-Hartman]

On Tue, Aug 07, 2018 at 03:33:29PM -0700, Nathan Chancellor wrote:
> On Tue, Aug 07, 2018 at 08:51:02PM +0200, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 3.18.118 release.
> > There are 85 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Thu Aug  9 17:23:43 UTC 2018.
> > Anything received after that time might be too late.
> > 
> > The whole patch series can be found in one patch at:
> > 
> > https://www.kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.18.118-rc1.gz
> > or in the git tree and branch at:
> > 
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> > linux-3.18.y
> > and the diffstat can be found below.
> > 
> > thanks,
> > 
> > greg k-h
> > 
> 
> Merged, compiled with -Werror, and installed onto my Pixel XL.
> 
> No initial issues noticed in dmesg or general usage.

Thanks for testing three of these and letting me know.

greg k-h

Re: Re: [RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC

[Kishon Vijay Abraham I]

Hi Rob,

On Tuesday 05 June 2018 07:35 PM, Rob Herring wrote:
> On Tue, Jun 5, 2018 at 1:05 AM, Nishanth Menon  wrote:
>> The AM654 SoC is a lead device of the K3 Multicore SoC architecture
>> platform, targeted for broad market and industrial control with aim to
>> meet the complex processing needs of modern embedded products.
>>
>> Some highlights of this SoC are:
>> * Quad ARMv8 A53 cores split over two clusters
>> * GICv3 compliant GIC500
>> * Configurable L3 Cache and IO-coherent architecture
>> * Dual lock-step capable R5F uC for safety-critical applications
>> * High data throughput capable distributed DMA architecture under NAVSS
>> * Three Gigabit Industrial Communication Subsystems (ICSSG), each with dual
>>   PRUs and dual RTUs
>> * Hardware accelerator block containing AES/DES/SHA/MD5 called SA2UL
>> * Centralized System Controller for Security, Power, and Resource
>>   management.
>> * Dual ADCSS, eQEP/eCAP, eHRPWM, dual CAN-FD
>> * Flash subystem with OSPI and Hyperbus interfaces
>> * Multimedia capability with CAL, DSS7-UL, SGX544, McASP
>> * Peripheral connectivity including USB3, PCIE, MMC/SD, GPMC, I2C, SPI,
>>   GPIO
>>
>> See AM65x Technical Reference Manual (SPRUID7, April 2018)
>> for further details: http://www.ti.com/lit/pdf/spruid7
>>
>> We introduce the Kconfig symbol for the SoC along with this patch since
>> it is logically relevant point, however the usage is in subsequent
>> patches.
>>
>> NOTE: AM654 is the first of the device variants, hence we introduce a
>> generic am6.dtsi.
>>
>> Signed-off-by: Benjamin Fair 
>> Signed-off-by: Nishanth Menon 
>> ---
>>  MAINTAINERS  |   1 +
>>  arch/arm64/boot/dts/ti/k3-am6.dtsi   | 144 
>> +++
>>  arch/arm64/boot/dts/ti/k3-am654.dtsi | 117 
>>  drivers/soc/ti/Kconfig   |  14 
>>  4 files changed, 276 insertions(+)
>>  create mode 100644 arch/arm64/boot/dts/ti/k3-am6.dtsi
>>  create mode 100644 arch/arm64/boot/dts/ti/k3-am654.dtsi
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index cfb35b252ac7..5f5c4eddec7a 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -2092,6 +2092,7 @@ M:Nishanth Menon 
>>  L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
>>  S: Supported
>>  F: Documentation/devicetree/bindings/arm/ti/k3.txt
>> +F: arch/arm64/boot/dts/ti/k3-*
>>
>>  ARM/TEXAS INSTRUMENT KEYSTONE ARCHITECTURE
>>  M: Santosh Shilimkar 
>> diff --git a/arch/arm64/boot/dts/ti/k3-am6.dtsi 
>> b/arch/arm64/boot/dts/ti/k3-am6.dtsi
>> new file mode 100644
>> index ..cdfa12173aac
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/ti/k3-am6.dtsi
>> @@ -0,0 +1,144 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Device Tree Source for AM6 SoC Family
>> + *
>> + * Copyright (C) 2016-2018 Texas Instruments Incorporated - 
>> http://www.ti.com/
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +
>> +/ {
>> +   model = "Texas Instruments K3 AM654 SoC";
>> +   compatible = "ti,am654";
>> +   interrupt-parent = <&gic>;
>> +   #address-cells = <2>;
>> +   #size-cells = <2>;
>> +
>> +   aliases {
>> +   serial0 = &wkup_uart0;
>> +   serial1 = &mcu_uart0;
>> +   serial2 = &main_uart0;
>> +   serial3 = &main_uart1;
>> +   serial4 = &main_uart2;
>> +   };
>> +
>> +   chosen { };
>> +
>> +   firmware {
>> +   optee {
>> +   compatible = "linaro,optee-tz";
>> +   method = "smc";
>> +   };
>> +
>> +   psci: psci {
>> +   compatible = "arm,psci-1.0";
>> +   method = "smc";
>> +   };
>> +   };
>> +
>> +   soc0: soc0 {
>> +   compatible = "simple-bus";
>> +   #address-cells = <2>;
>> +   #size-cells = <2>;
>> +   ranges;
> 
> Really need 64-bit addresses and sizes? Use ranges to limit the
> address space if possible.

We now have address-cells as <1>,
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm64/boot/dts/ti/k3-am65.dtsi#n49

However each PCIe instance has 2 data regions and one of the regions
(PCIE0_CORE_CORE_DAT_SLV_PCIE_DAT1/PCIE1_CORE_CORE_DAT_SLV_PCIE_DAT1 specified
in the "MAIN Domain Memory Map" table of TRM http://www.ti.com/lit/pdf/spruid7)
is above the 32bit region and requires 2 cells to specify the start address.
This region is used to access MEM_SPACE of PCIe endpoint when operating in root
complex mode and access memory of PCI root complex when operating in endpoint 
mode.

In order to describe this, should we change the address-cells back to <2> or do
you suggest any other alternatives?

Thanks
Kishon

Re: [PATCH RESEND RFC 1/4] drivers: pinctrl: qcom: add wakeup capability to GPIO

[Marc Zyngier]

On Tue, 07 Aug 2018 23:05:07 -0700
Stephen Boyd  wrote:

> Quoting Lina Iyer (2018-08-02 05:58:27)
> > On Thu, Aug 02 2018 at 01:27 -0600, Marc Zyngier wrote:  
> > >
> > >Sure. But once woken up (GIC *and* TLMM), the gpio line (which I
> > >assume is level) is still high at the TLMM input. So why isn't it
> > >registering that state once it has been woken up?
> > >
> > >I can understand that it would be missing an edge. But that doesn't
> > >hold for level signalling.
> > >  
> > Sure, yes. Sorry for not registering your point in my response.
> > Once woken up we should see the level interrupt in TLMM.  
> 
> And the level type gpio interrupt will trigger the TLMM summary
> interrupt line after the wakeup? So then the only thing that needs to be
> replayed is edge interrupts? How are edge interrupts going to be
> replayed?

Level interrupts should be taken care of without doing anything, by the
very nature of being a level signal.

Edge interrupts should be replayed using check_irq_resend() after
taking the right locks and making the interrupt pending. Or, if there
is a way for SW to make the interrupt pending at the TLMM level, to use
that as a way to reinject the interrupt (which would be the preferred
way, as it avoids all kind of ugly locking considerations).

Thanks,

M.
-- 
Without deviation from the norm, progress is not possible.

Re: [PATCH v7 2/2] cpufreq: qcom-hw: Add support for QCOM cpufreq HW driver

[Stephen Boyd]

Quoting skan...@codeaurora.org (2018-08-06 13:46:05)
> On 2018-08-03 15:24, Stephen Boyd wrote:
> > Quoting skan...@codeaurora.org (2018-08-03 12:52:48)
> >> On 2018-08-03 12:40, Evan Green wrote:
> >> > Hi Taniya,
> >> >
> >> > On Tue, Jul 24, 2018 at 3:44 AM Taniya Das  wrote:
> >> >>
> >> >> +   if (src)
> >> >> +   c->table[i].frequency = c->xo_rate * lval /
> >> >> 1000;
> >> >> +   else
> >> >> +   c->table[i].frequency = INIT_RATE / 1000;
> >> >
> >> > I don't know much about how this hardware works, but based on the
> >> > mask, src has 4 possible values. So does 0 mean INIT_RATE, and 1, 2,
> >> > and 3 all mean xo_rate?
> >> >
> >> > Also, is INIT_RATE really constant? It sounds like gpll0 (or
> >> > gpll0_out_even?). You're already getting the xo clock, why not get
> >> > gpll0's real rate as well?
> >> 
> >> Actually I was about to comment and say NOT to get clocks just to get
> >> their rate. The XO_RATE is just a multiplication factor. This HW/FW 
> >> can
> >> change in the future and make the multiplication factor to 1KHz.
> > 
> > So future changes to this hardware are going to make this register
> > return the final frequency that we should use? Sounds great! But that
> > isn't how it's working right now. We need to have XO in the binding 
> > here
> > so the driver can work with different XO frequencies in case that ever
> > happens. Same story for GPLL0. Hardcoding this stuff in the driver just
> > means we'll have to swizzle things in the driver when it changes.
> 
> XO being a different frequency in a Qualcomm chip is way way less likely 
> than anything else we are discussing here. In the 10+years I've been 
> there this has never changed.
> 
> So, how about making this binding optional? If it's not present we can 
> make assumptions for XO rate and init rate. That'll handle your 
> hypothetical use case while also being optimized.

Optional properties are almost never correct for clks. Either the clk
goes there or it doesn't go there. The only time it's optional is if the
HW has the choice of generating the clk itself internally or to use an
external clk as input.

In this case, it's not optional, it's actually used so marking it
optional is highly confusing.

> 
> >> We also
> >> can't really control any of the clocks going to this block from Linux
> >> (it's all locked down).
> > 
> > This shouldn't matter. The clocks going to this hardware block are
> > described by the firmware to the OS by means of the DT node. If the
> > firmware or the hardware decides to change the input clks then the
> > binding can have different clk nodes used.
> 
> There are tons of clocks that are input to blocks in an SoC that are 
> never controlled by Linux. Or are expose in DT because they are set up 
> ahead of time and can't change. So, why make an exception here?

Because the driver doesn't have to hard-code some frequency that can
easily come from the DT, making it more flexible for frequency plan
changes. It doesn't matter about control of clks at all here, so this
comparison is just plain wrong.

> 
> >> The INIT_RATE will
> >> always be 300 MHz independent of what source it's coming from (as in, 
> >> if
> >> GPLL0 can't give 300, the HW design will be so that we'll find a
> >> different source).
> >> 
> >> So, I'd like to remove any clock bindings for this driver.
> > 
> > No. Bindings describe how the hardware is connected. Please don't 
> > remove
> > clocks from the binding just because probe defer is a concern.
> 
> Binding describes hardware controllable by the OS. That's the reality. 
> Let's not add mandatory clock bindings for clocks that the OS can't do 
> anything about.
> 

It seems that you believe clks should only be used to turn on/off and
control rates. That is not the whole truth. Sometimes clks are there
just to express the clk frequencies that are present in the design so
that drivers can figure out what to do.

Re: simplified RISC-V interrupt and clocksource handling v3

[Christoph Hellwig]

[attention Rob: Palmer said he is going to pull it in, and I'd really
 like to have your ACK on the DT bindings, can you chime in if
 everything is ok for you?]

On Tue, Aug 07, 2018 at 07:23:19PM -0700, Palmer Dabbelt wrote:
> Thanks!  Modulo the one device tree issue I replied to in patch 3 this 
> looks great!  We've already gotten the ACKs to take this through the RISC-V 
> tree, so I'm going to put this along with the queued RISC-V patches on our 
> for-next branch, including my proposed change for "sifive,plic-1.0" but 
> leaving the device tree bindings with #{address,size}-cells=1.

Note that I saw a branch that only has the actual driver patch, this
needs to be in the documentation as well of couse.  I don't really
care which name we settle on as long we agree on it, and document it
properly.

Re: [PATCH v7 1/2] dt-bindings: cpufreq: Introduce QCOM CPUFREQ Firmware bindings

[Stephen Boyd]

Quoting Taniya Das (2018-08-07 19:46:01)
> 
> 
> On 8/8/2018 12:54 AM, skan...@codeaurora.org wrote:
> > On 2018-08-07 04:12, Sudeep Holla wrote:
> >> On Mon, Aug 06, 2018 at 01:54:24PM -0700, skan...@codeaurora.org wrote:
> >>> On 2018-08-03 16:46, Stephen Boyd wrote:
> >>> >Quoting Taniya Das (2018-07-24 03:42:49)
> >>> >>diff --git
> >>> >>a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt
> >>> >>b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt
> >>> >>new file mode 100644
> >>> >>index 000..22d4355
> >>> >>--- /dev/null
> >>> >>+++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt
> >>> >>@@ -0,0 +1,172 @@
> >>> >[...]
> >>> >>+
> >>> >>+   CPU7: cpu@700 {
> >>> >>+   device_type = "cpu";
> >>> >>+   compatible = "qcom,kryo385";
> >>> >>+   reg = <0x0 0x700>;
> >>> >>+   enable-method = "psci";
> >>> >>+   next-level-cache = <&L2_700>;
> >>> >>+   qcom,freq-domain = <&freq_domain_table1>;
> >>> >>+   L2_700: l2-cache {
> >>> >>+   compatible = "cache";
> >>> >>+   next-level-cache = <&L3_0>;
> >>> >>+   };
> >>> >>+   };
> >>> >>+   };
> >>> >>+
> >>> >>+   qcom,cpufreq-hw {
> >>> >>+   compatible = "qcom,cpufreq-hw";
> >>> >>+
> >>> >>+   clocks = <&rpmhcc RPMH_CXO_CLK>;
> >>> >>+   clock-names = "xo";
> >>> >>+
> >>> >>+   #address-cells = <2>;
> >>> >>+   #size-cells = <2>;
> >>> >>+   ranges;
> >>> >>+   freq_domain_table0: freq_table0 {
> >>> >>+   reg = <0 0x17d43000 0 0x1400>;
> >>> >>+   };
> >>> >>+
> >>> >>+   freq_domain_table1: freq_table1 {
> >>> >>+   reg = <0 0x17d45800 0 0x1400>;
> >>> >>+   };
> >>> >
> >>> >Sorry, this is just not proper DT design. The whole node should have a
> >>> >reg property, and it should contain two (or three if we're handling the
> >>> >L3 clk domain?) different offsets for the different power clusters. The
> >>> >problem seems to still be that we don't have a way to map the CPUs to
> >>> >the clk domains they're in provided by this hardware block. Making
> >>> >subnodes is not the solution.
> >>>
> >>> The problem is mapping clock domains to logical CPUs that CPUfreq 
> >>> uses. The
> >>> physical CPU to logical CPU mapping can be changed by the kernel (even
> >>> through DT if I'm not mistaken). So we need to have a way to tell in DT
> >>> which physical CPUs are connected to which CPU freq clock domain.
> >>>
> >>
> >> How about passing CPU freq clock domain id as along with phandle in
> >> qcom,freq-domain ?
> > 
> > Now sure what you mean here. There's no such this as CPUfreq clock 
> > domain id. It has policies that are made up of logical CPU numbers. 
> > Logical CPU is not something that you can fix in DT.
> > 
> > -Saravana
> 
> Sudeep,
> 
> Earlier the design was the freq_domain would take the CPU phandles
> 
> freq_domain:
>cpus = <&cpu0 &cpu1>;
> 

I believe Sudeep is recommending something I recommended earlier. It
would look like:

   cpu7 {
   qcom,freq-domain = <&cpufreq_hw 1>;
   }

to indicate that cpu7 is in cpufreq_hw's frequency domain #1. That
should probably be called clk domain BTW.

If that was done with a phandle and a single cell, then we should have
something similar on the cpufreq_hw node side indicating how to parse
the cells in qcom,freq-domain. A property like #qcom,freq-domain-cells =
<1> to indicate that one u32 follows the phandle.

Re: [PATCH RESEND RFC 1/4] drivers: pinctrl: qcom: add wakeup capability to GPIO

[Stephen Boyd]

Quoting Lina Iyer (2018-08-02 05:58:27)
> On Thu, Aug 02 2018 at 01:27 -0600, Marc Zyngier wrote:
> >
> >Sure. But once woken up (GIC *and* TLMM), the gpio line (which I
> >assume is level) is still high at the TLMM input. So why isn't it
> >registering that state once it has been woken up?
> >
> >I can understand that it would be missing an edge. But that doesn't
> >hold for level signalling.
> >
> Sure, yes. Sorry for not registering your point in my response.
> Once woken up we should see the level interrupt in TLMM.

And the level type gpio interrupt will trigger the TLMM summary
interrupt line after the wakeup? So then the only thing that needs to be
replayed is edge interrupts? How are edge interrupts going to be
replayed?

Re: [PATCH v5 1/2] leds: core: Introduce LED pattern trigger

[Baolin Wang]

Hi Jacek,

On 8 August 2018 at 05:54, Jacek Anaszewski  wrote:
> Hi Baolin,
>
> Thank you for addressing the review remarks.
> Since the patch set is targeted for 4.19, then we have three weeks
> before it will be merged to the for-next anyway. That said, I propose
> one more modification, please take a look below.

Sure.

>
> On 08/06/2018 02:05 PM, Baolin Wang wrote:
>> Some LED controllers have support for autonomously controlling
>> brightness over time, according to some preprogrammed pattern or
>> function.
>>
>> This patch adds pattern trigger that LED device can configure the
>> pattern and trigger it.
>>
>> Signed-off-by: Raphael Teysseyre 
>> Signed-off-by: Baolin Wang 
>> ---
>> Changes from v4:
>>  - Change the repeat file to return the originally written number.
>>  - Improve comments.
>>  - Fix some build warnings.
>>
>> Changes from v3:
>>  - Reset pattern number to 0 if user provides incorrect pattern string.
>>  - Support one pattern.
>>
>> Changes from v2:
>>  - Remove hardware_pattern boolen.
>>  - Chnage the pattern string format.
>>
>> Changes from v1:
>>  - Use ATTRIBUTE_GROUPS() to define attributes.
>>  - Introduce hardware_pattern flag to determine if software pattern
>>  or hardware pattern.
>>  - Re-implement pattern_trig_store_pattern() function.
>>  - Remove pattern_get() interface.
>>  - Improve comments.
>>  - Other small optimization.
>> ---
>>  .../ABI/testing/sysfs-class-led-trigger-pattern|   24 ++
>>  drivers/leds/trigger/Kconfig   |7 +
>>  drivers/leds/trigger/Makefile  |1 +
>>  drivers/leds/trigger/ledtrig-pattern.c |  266 
>> 
>>  include/linux/leds.h   |   16 ++
>>  5 files changed, 314 insertions(+)
>>  create mode 100644 Documentation/ABI/testing/sysfs-class-led-trigger-pattern
>>  create mode 100644 drivers/leds/trigger/ledtrig-pattern.c
>>
>> diff --git a/Documentation/ABI/testing/sysfs-class-led-trigger-pattern 
>> b/Documentation/ABI/testing/sysfs-class-led-trigger-pattern
>> new file mode 100644
>> index 000..bc7475f
>> --- /dev/null
>> +++ b/Documentation/ABI/testing/sysfs-class-led-trigger-pattern
>> @@ -0,0 +1,24 @@
>> +What:/sys/class/leds//pattern
>> +Date:August 2018
>> +KernelVersion:   4.19
>> +Description:
>> + Specify a pattern for the LED, for LED hardware that support
>> + altering the brightness as a function of time.
>> +
>> + The pattern is given by a series of tuples, of brightness and
>> + duration (ms). The LED is expected to traverse the series and
>> + each brightness value for the specified duration. Duration of
>> + 0 means brightness should immediately change to new value.
>> +
>> + The format of the pattern values should be:
>> + "brightness_1 duration_1 brightness_2 duration_2 brightness_3
>> + duration_3 ...".
>> +
>> +What:/sys/class/leds//repeat
>> +Date:August 2018
>> +KernelVersion:   4.19
>> +Description:
>> + Specify a pattern repeat number. 0 means repeat indefinitely.
>> +
>> + This file will always return the originally written repeat
>> + number.
>> diff --git a/drivers/leds/trigger/Kconfig b/drivers/leds/trigger/Kconfig
>> index 4018af7..b76fc3c 100644
>> --- a/drivers/leds/trigger/Kconfig
>> +++ b/drivers/leds/trigger/Kconfig
>> @@ -129,4 +129,11 @@ config LEDS_TRIGGER_NETDEV
>> This allows LEDs to be controlled by network device activity.
>> If unsure, say Y.
>>
>> +config LEDS_TRIGGER_PATTERN
>> + tristate "LED Pattern Trigger"
>> + help
>> +   This allows LEDs to be controlled by a software or hardware pattern
>> +   which is a series of tuples, of brightness and duration (ms).
>> +   If unsure, say N
>> +
>>  endif # LEDS_TRIGGERS
>> diff --git a/drivers/leds/trigger/Makefile b/drivers/leds/trigger/Makefile
>> index f3cfe19..9bcb64e 100644
>> --- a/drivers/leds/trigger/Makefile
>> +++ b/drivers/leds/trigger/Makefile
>> @@ -13,3 +13,4 @@ obj-$(CONFIG_LEDS_TRIGGER_TRANSIENT)+= 
>> ledtrig-transient.o
>>  obj-$(CONFIG_LEDS_TRIGGER_CAMERA)+= ledtrig-camera.o
>>  obj-$(CONFIG_LEDS_TRIGGER_PANIC) += ledtrig-panic.o
>>  obj-$(CONFIG_LEDS_TRIGGER_NETDEV)+= ledtrig-netdev.o
>> +obj-$(CONFIG_LEDS_TRIGGER_PATTERN)   += ledtrig-pattern.o
>> diff --git a/drivers/leds/trigger/ledtrig-pattern.c 
>> b/drivers/leds/trigger/ledtrig-pattern.c
>> new file mode 100644
>> index 000..63b94a2
>> --- /dev/null
>> +++ b/drivers/leds/trigger/ledtrig-pattern.c
>> @@ -0,0 +1,266 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +
>> +/*
>> + * LED pattern trigger
>> + *
>> + * Idea discussed with Pavel Machek. Raphael Teysseyre implemented
>> + * the first version, Baolin Wang simplified and improved the approach.
>> + */
>> +
>> +#include 
>> +#include 
>> +#include

Re: [PATCH] firmware: coreboot: Let OF core populate platform device

[Stephen Boyd]

Quoting Brian Norris (2018-08-07 14:41:04)
> On Mon, Aug 06, 2018 at 10:10:47AM -0700, Stephen Boyd wrote:
> > diff --git a/drivers/firmware/google/coreboot_table-of.c 
> > b/drivers/firmware/google/coreboot_table-of.c
> > index f15bf404c579..270f112bdc54 100644
> > --- a/drivers/firmware/google/coreboot_table-of.c
> > +++ b/drivers/firmware/google/coreboot_table-of.c
> > @@ -18,21 +18,20 @@
> >  #include 
> >  #include 
> >  #include 
> > -#include 
> > -#include 
> > +#include 
> >  #include 
> >  
> >  #include "coreboot_table.h"
> >  
> >  static int coreboot_table_of_probe(struct platform_device *pdev)
> >  {
> > - struct device_node *fw_dn = pdev->dev.of_node;
> >   void __iomem *ptr;
> > + struct resource *res;
> >  
> > - ptr = of_iomap(fw_dn, 0);
> > - of_node_put(fw_dn);
> > - if (!ptr)
> > - return -ENOMEM;
> > + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > + ptr = devm_ioremap_resource(&pdev->dev, res);
> 
> You're making this a devm_* ioremap, but coreboot_table_exit() will
> handle unmapping this for you already. So you're introducing a potential
> double-unmap.

Thanks! I'll split this patch into essential and non-essential pieces
then and layer shortening patches on top.

> 
> > + if (IS_ERR(ptr))
> > + return PTR_ERR(ptr);
> >  
> >   return coreboot_table_init(&pdev->dev, ptr);
> >  }
> > @@ -44,8 +43,9 @@ static int coreboot_table_of_remove(struct 
> > platform_device *pdev)
> >  
> >  static const struct of_device_id coreboot_of_match[] = {
> >   { .compatible = "coreboot" },
> > - {},
> > + {}
> 
> ...and since I had a *real* comment, I'll mention this bit I noticed
> previously...this diff seems a bit superfluous. I understand we don't
> really want to extend this list beyond the NULL terminator, but
> normally, I'd expect we leave it alone.
> 

I was adding MODULE_DEVICE_TABLE nearby. I'll leave the removal here
unless you really hate the style cleanup.

> >  };
> > +MODULE_DEVICE_TABLE(of, coreboot_of_match);
> >  

Re: [PATCH 2/4] clk: qcom: Add clk_rcg2_gfx3d_ops for SDM845

[Stephen Boyd]

Quoting Jordan Crouse (2018-08-06 08:04:37)
> On Mon, Aug 06, 2018 at 02:37:18PM +0530, Amit Nischal wrote:
> > On 2018-08-03 04:14, Stephen Boyd wrote:
> > >Quoting Amit Nischal (2018-07-30 04:28:56)
> > >>On 2018-07-25 12:28, Stephen Boyd wrote:
> > >>>
> > >>> Ok. Sounds good! Is the rate range call really needed? It can't be
> > >>> determined in the PLL code with some table or avoided by making sure
> > >>> GPU
> > >>> uses OPP table with only approved frequencies?
> > >>>
> > >>
> > >>Currently fabia PLL code does not have any table to check this and
> > >>intention
> > >>was to avoid relying on the client to call set_rate with only approved
> > >>frequencies so we have added the set_rate_range() call in the GPUCC
> > >>driver
> > >>in order to set the rate range.
> > >>
> > >
> > >But GPU will use OPP so it doesn't seem like it really buys us anything
> > >here. And it really doesn't matter when the clk driver implementation
> > >doesn't use the min/max to clamp the values of the round_rate()
> > >call. Is
> > >that being done here? I need to double check. I would be more convinced
> > >if the implementation was looking at min/max to constrain the rate
> > >requested.
> > >
> > 
> > So our understanding is that GPU(client) driver will always call the
> > set_rate with approved frequencies only and we can completely rely
> > on the
> > client. Is our understanding is correct?
> 
> 
> First: on sdm845 the software doesn't set the GPU clocks - we rely on the GMU
> firmware to do that on our behalf but for the GPU at least this is an academic
> exercise.

So what is this GPU clk driver for then?

> 
> But that said: traditionally we've expected that the clock driver correctly
> clamp the requested rate to the correct values. In the past we have taken
> advantage of this and we may in the future. I don't think it is reasonable
> to require the leaf driver to only pass "approved" frequencies especially
> since we depend on our own OPP table that may or may not be similar to the
> one used by the clock driver.
> 

Ok. Sounds like things can't be kept in sync between the clk driver and
the OPP tables. Why is that hard to do?

Either way, I'd be fine if the code actually used the frequency limits
to round the rate to something within range, but I don't recall seeing
that being done here. So if the min/max limits stay, the clk driver
should round to within that range.

Re: [PATCH v3] locking/rwsem: Exit read lock slowpath if queue empty & no writer

[Waiman Long]

On 07/24/2018 03:10 PM, Waiman Long wrote:
> It was discovered that a constant stream of readers with occassional
> writers pounding on a rwsem may cause many of the readers to enter the
> slowpath unnecessarily thus increasing latency and lowering performance.
>
> In the current code, a reader entering the slowpath critical section
> will unconditionally set the WAITING_BIAS, if not set yet, and clear
> its active count even if no one is in the wait queue and no writer
> is present. This causes some incoming readers to observe the presence
> of waiters in the wait queue and hence have to go into the slowpath
> themselves.
>
> With sufficient numbers of readers and a relatively short lock hold time,
> the WAITING_BIAS may be repeatedly turned on and off and a substantial
> portion of the readers will go into the slowpath sustaining a rather
> long queue in the wait queue spinlock and repeated WAITING_BIAS on/off
> cycle until the logjam is broken opportunistically.
>
> To avoid this situation from happening, an additional check is added to
> detect the special case that the reader in the critical section is the
> only one in the wait queue and no writer is present. When that happens,
> it can just exit the slowpath and return immediately as its active count
> has already been set in the lock.  Other incoming readers won't observe
> the presence of waiters and so will not be forced into the slowpath.
>
> The issue was found in a customer site where they had an application
> that pounded on the pread64 syscalls heavily on an XFS filesystem. The
> application was run in a recent 4-socket boxes with a lot of CPUs. They
> saw significant spinlock contention in the rwsem_down_read_failed() call.
> With this patch applied, the system CPU usage went down from 85% to 57%,
> and the spinlock contention in the pread64 syscalls was gone.
>
> v3: Revise the commit log and comment again.
> v2: Add customer testing results and remove wording that may cause
> confusion.
>
> Signed-off-by: Waiman Long 
> ---
>  kernel/locking/rwsem-xadd.c | 13 -
>  1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/locking/rwsem-xadd.c b/kernel/locking/rwsem-xadd.c
> index 3064c50..01fcb80 100644
> --- a/kernel/locking/rwsem-xadd.c
> +++ b/kernel/locking/rwsem-xadd.c
> @@ -233,8 +233,19 @@ static void __rwsem_mark_wake(struct rw_semaphore *sem,
>   waiter.type = RWSEM_WAITING_FOR_READ;
>  
>   raw_spin_lock_irq(&sem->wait_lock);
> - if (list_empty(&sem->wait_list))
> + if (list_empty(&sem->wait_list)) {
> + /*
> +  * In case the wait queue is empty and the lock isn't owned
> +  * by a writer, this reader can exit the slowpath and return
> +  * immediately as its RWSEM_ACTIVE_READ_BIAS has already
> +  * been set in the count.
> +  */
> + if (atomic_long_read(&sem->count) >= 0) {
> + raw_spin_unlock_irq(&sem->wait_lock);
> + return sem;
> + }
>   adjustment += RWSEM_WAITING_BIAS;
> + }
>   list_add_tail(&waiter.list, &sem->wait_list);
>  
>   /* we're now waiting on the lock, but no longer actively locking */

Will this patch be eligible to go into 4.19 or 4.20?

Thanks,
Longman

Re: [PATCH 4.4 00/12] 4.4.147-stable review

[Naresh Kamboju]

On 8 August 2018 at 00:22, Greg Kroah-Hartman
 wrote:
> This is the start of the stable review cycle for the 4.4.147 release.
> There are 12 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Thu Aug  9 17:23:34 UTC 2018.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> 
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.147-rc1.gz
> or in the git tree and branch at:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.4.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

Results from Linaro’s test farm.
No regressions on arm64, arm and x86_64.

Summary


kernel: 4.4.147-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.4.y
git commit: ed5153769cba52b60a0c6210cb1ac41843f37200
git describe: v4.4.146-13-ged5153769cba
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.146-13-ged5153769cba


No regressions (compared to build v4.4.146-12-gdb3e08ea00d0)


Ran 12163 total tests in the following environments and test suites.

Environments
--
- juno-r2 - arm64
- qemu_arm
- qemu_x86_64
- x15 - arm
- x86_64

Test Suites
---
* boot
* kselftest
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-containers-tests
* ltp-cve-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-nptl-tests
* ltp-open-posix-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-timers-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none

Summary


kernel: 4.4.147-rc1
git repo: https://git.linaro.org/lkft/arm64-stable-rc.git
git branch: 4.4.147-rc1-hikey-20180807-254
git commit: a7af4a3cb7756f8a159f54cb757f30764f3d5166
git describe: 4.4.147-rc1-hikey-20180807-254
Test details: 
https://qa-reports.linaro.org/lkft/linaro-hikey-stable-rc-4.4-oe/build/4.4.147-rc1-hikey-20180807-254


No regressions (compared to build 4.4.147-rc1-hikey-20180807-253)


Ran 2705 total tests in the following environments and test suites.

Environments
--
- hi6220-hikey - arm64
- qemu_arm64

Test Suites
---
* boot
* kselftest
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-containers-tests
* ltp-cve-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-timers-tests

-- 
Linaro LKFT
https://lkft.linaro.org

[GIT PULL] FSI fixes for 4.19

[Benjamin Herrenschmidt]

Hi Greg !

This adds two FSI fixes to what you already have in your tree

  - Fix a NULL dereference in the scom driver

  - Fix a command buffer size issue in the sbefifo driver that
breaks some operations with POWER system debugger (cronus)

Cheers,
Ben.

The following changes since tag fsi-updates-2018-07-27:

  fsi: Prevent multiple concurrent rescans (2018-07-27 09:58:12 +1000)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/benh/linux-fsi.git 
tags/fsi-updates-2018-08-08

for you to fetch changes up to 15e2a7218c2788d79c566d17cb9428c221e7:

  fsi: sbefifo: Bump max command length (2018-08-08 15:44:47 +1000)


Benjamin Herrenschmidt (2):
  fsi: scom: Fix NULL dereference
  fsi: sbefifo: Bump max command length

 drivers/fsi/fsi-sbefifo.c | 39 ---
 drivers/fsi/fsi-scom.c|  1 +
 2 files changed, 33 insertions(+), 7 deletions(-)

Re: [PATCH v2 02/18] clk: intel: Add clock driver for Intel MIPS SoCs

[Stephen Boyd]

Quoting Songjun Wu (2018-08-02 20:02:21)
> From: Yixin Zhu 
> 
> This driver provides PLL clock registration as well as various clock
> branches, e.g. MUX clock, gate clock, divider clock and so on.
> 
> PLLs that provide clock to DDR, CPU and peripherals are shown below:
> 
>  +-+
> |--->| LCPLL3 0|--PCIe clk-->
>XO   |+-+
> +---|
> |+-+
> ||3|--PAE clk-->
> |--->| PLL0B  2|--GSWIP clk-->
> ||1|--DDR clk-->DDR PHY clk-->
> ||0|--CPU1 clk--+   +-+
> |+-+|--->0|
> |   | MUX |--CPU clk-->
> |+-+|--->1|
> ||0|--CPU0 clk--+   +-+
> |--->| PLLOA  1|--SSX4 clk-->
>  |2|--NGI clk-->
>  |3|--CBM clk-->
>  +-+

Thanks for the picture!

> 
> Signed-off-by: Yixin Zhu 
> Signed-off-by: Songjun Wu 
> diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
> index 0bb25dd009d1..d929ca4607cf 100644
> --- a/drivers/clk/Makefile
> +++ b/drivers/clk/Makefile
> @@ -72,6 +72,9 @@ obj-$(CONFIG_ARCH_HISI)   += hisilicon/
>  obj-y  += imgtec/
>  obj-$(CONFIG_ARCH_MXC) += imx/
>  obj-$(CONFIG_MACH_INGENIC) += ingenic/
> +ifeq ($(CONFIG_COMMON_CLK), y)
> +obj-y  +=intel/
> +endif

Why not obj-$(CONFIG_INTEL_CCF) or something like that?

>  obj-$(CONFIG_ARCH_KEYSTONE)+= keystone/
>  obj-$(CONFIG_MACH_LOONGSON32)  += loongson1/
>  obj-y  += mediatek/
> diff --git a/drivers/clk/intel/Kconfig b/drivers/clk/intel/Kconfig
> new file mode 100644
> index ..c7d3fb1721fa
> --- /dev/null
> +++ b/drivers/clk/intel/Kconfig
> @@ -0,0 +1,20 @@
> +# SPDX-License-Identifier: GPL-2.0
> +config INTEL_CGU_CLK
> +   depends on COMMON_CLK
> +   depends on INTEL_MIPS || COMPILE_TEST
> +   select MFD_SYSCON
> +   bool "Intel clock controller support"
> +   help
> + This driver support Intel CGU (Clock Generation Unit).

Is it really called a clock generation unit? Or that's just copied from
sunxi driver?

> +
> +choice
> +   prompt "SoC platform selection"
> +   depends on INTEL_CGU_CLK
> +   default INTEL_GRX500_CGU_CLK
> +
> +config INTEL_GRX500_CGU_CLK
> +   bool "GRX500 CLK"
> +   help
> + Clock driver of GRX500 platform.
> +
> +endchoice
> diff --git a/drivers/clk/intel/Makefile b/drivers/clk/intel/Makefile
> new file mode 100644
> index ..16a0138e52c2
> --- /dev/null
> +++ b/drivers/clk/intel/Makefile
> @@ -0,0 +1,7 @@
> +# SPDX-License-Identifier: GPL-2.0
> +# Makefile for intel specific clk
> +
> +obj-$(CONFIG_INTEL_CGU_CLK) += clk-cgu.o clk-cgu-pll.o
> +ifneq ($(CONFIG_INTEL_GRX500_CGU_CLK),)
> +   obj-y += clk-grx500.o
> +endif
> diff --git a/drivers/clk/intel/clk-cgu-pll.c b/drivers/clk/intel/clk-cgu-pll.c
> new file mode 100644
> index ..20759bc27e95
> --- /dev/null
> +++ b/drivers/clk/intel/clk-cgu-pll.c
> @@ -0,0 +1,166 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + *  Copyright (C) 2018 Intel Corporation.
> + *  Zhu YiXin 
> + */
> +
> +#include 

Is this include used?

> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "clk-cgu-pll.h"
> +#include "clk-cgu.h"
> +
> +#define to_intel_clk_pll(_hw)  container_of(_hw, struct intel_clk_pll, hw)
> +
> +/*
> + * Calculate formula:
> + * rate = (prate * mult + (prate * frac) / frac_div) / div
> + */
> +static unsigned long
> +intel_pll_calc_rate(unsigned long prate, unsigned int mult,
> +   unsigned int div, unsigned int frac,
> +   unsigned int frac_div)
> +{
> +   u64 crate, frate, rate64;
> +
> +   rate64 = prate;
> +   crate = rate64 * mult;
> +
> +   if (frac) {
> +   frate = rate64 * frac;
> +   do_div(frate, frac_div);
> +   crate += frate;
> +   }
> +   do_div(crate, div);
> +
> +   return (unsigned long)crate;
> +}
> +
> +static void
> +grx500_pll_get_params(struct intel_clk_pll *pll, unsigned int *mult,
> + unsigned int *frac)
> +{
> +   *mult = intel_get_clk_val(pll->map, pll->reg, 2, 7);
> +   *frac = intel_get_clk_val(pll->map, pll->reg, 9, 21);
> +}
> +
> +static int intel_wait_pll_lock(struct intel_clk_pll *pll, int bit_idx)
> +{
> +   unsigned int val;
> +
> +   return regmap_read_poll_timeout(pll->map, pll->reg, val,
> +   val & BIT(bit_idx), 10, 1000);
> +}
> +
> +static unsigned long
> +intel_grx500_pll_recalc_rate(struct clk_hw *hw, unsigned long prate)
> +{
> +   struct intel_

[PATCH] PCI: Fix calculation of bridge window's size

[AceLan Kao]

There are some 0 resource size pci devices, and it leads to the
accumulator fails to maintain the correct value.
It results in a strange issue on my machine that xhci_hcd failed to init.
   [2.437278] xhci_hcd :05:00.0: init :05:00.0 fail, -16
   [2.437300] xhci_hcd: probe of :05:00.0 failed with error -16

To fix this, check if the resource size equals to 0, doesn't increase size.

Fixes: c9c75143a596 ("PCI: Fix calculation of bridge window's size and 
alignment")
CC: sta...@vger.kernel.org # 4.14+

Signed-off-by: AceLan Kao 
---
 drivers/pci/setup-bus.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index 79b1824e83b4..ae05dde8c6e3 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -1061,7 +1061,8 @@ static int pbus_size_mem(struct pci_bus *bus, unsigned 
long mask,
r->flags = 0;
continue;
}
-   size += max(r_size, align);
+   if (r_size != 0)
+   size += max(r_size, align);
/* Exclude ranges with size > align from
   calculation of the alignment. */
if (r_size <= align)
-- 
2.17.1

Re: [PATCH 0/2] x86/intel_rdt and perf/x86: Fix lack of coordination with perf

[Reinette Chatre]

Hi Tony,

On 8/7/2018 6:28 PM, Luck, Tony wrote:
> Would it help to call routines to read the "before" values of the counter
> twice. The first time to preload the cache with anything needed to execute
> the perf code path.

>>> In an attempt to improve the accuracy of the above I modified it to the
>>> following:
>>>
>>> /* create the two events as before in "enabled" state */
>>> l2_hit_pmcnum = l2_hit_event->hw.event_base_rdpmc;
>>> l2_miss_pmcnum = l2_miss_event->hw.event_base_rdpmc;
>>> local_irq_disable();
>>> /* disable hw prefetchers */
>>> /* init local vars to loop through pseudo-locked mem
>   * may take some misses in the perf code
>   */
>  l2_hits_before = native_read_pmc(l2_hit_pmcnum);
>  l2_miss_before = native_read_pmc(l2_miss_pmcnum);
>  /* Read counters again, hope no new misses here */
>>> l2_hits_before = native_read_pmc(l2_hit_pmcnum);
>>> l2_miss_before = native_read_pmc(l2_miss_pmcnum);
>>> /* loop through pseudo-locked mem */
>>> l2_hits_after = native_read_pmc(l2_hit_pmcnum);
>>> l2_miss_after = native_read_pmc(l2_miss_pmcnum);
>>> /* enable hw prefetchers */
>>> local_irq_enable();
>

The end of my previous email to Peter contains a solution that does
address all the feedback received up to this point while also able to
obtain (what I thought to be ... more below) accurate results. The code
you comment on below is not this latest version but your suggestion is
valuable and I do try it out on two different ways from what you quote
below to read the perf data.

So, instead of reading data with native_read_pmc() as in the code you
quoted I first test when reading data twice using the original
recommendation of "perf_event_read_local()" and second when reading data
twice using "rdpmcl()" chosen instead of native_read_pmc().

First, reading data using perf_event_read_local() called twice.
When testing as follows:
/* create perf events */
/* disable irq */
/* disable hw prefetchers */
/* init local vars */
/* read before data twice as follows: */
perf_event_read_local(l2_hit_event, &l2_hits_before, NULL, NULL);
perf_event_read_local(l2_miss_event, &l2_miss_before, NULL, NULL);
perf_event_read_local(l2_hit_event, &l2_hits_before, NULL, NULL);
perf_event_read_local(l2_miss_event, &l2_miss_before, NULL, NULL);
/* read through pseudo-locked memory */
perf_event_read_local(l2_hit_event, &l2_hits_after, NULL, NULL);
perf_event_read_local(l2_miss_event, &l2_miss_after, NULL, NULL);
/* re enable hw prefetchers */
/* enable irq */
/* write data to tracepoint */

With the above I am not able to obtain accurate data:
pseudo_lock_mea-351   [002] 61.859147: pseudo_lock_l2: hits=4109
miss=0
pseudo_lock_mea-354   [002] 63.045734: pseudo_lock_l2: hits=4103
miss=6
pseudo_lock_mea-357   [002] 64.104673: pseudo_lock_l2: hits=4106
miss=3
pseudo_lock_mea-360   [002] 65.174775: pseudo_lock_l2: hits=4105
miss=5
pseudo_lock_mea-367   [002] 66.232308: pseudo_lock_l2: hits=4104
miss=5
pseudo_lock_mea-370   [002] 67.291844: pseudo_lock_l2: hits=4103
miss=6
pseudo_lock_mea-373   [002] 68.348725: pseudo_lock_l2: hits=4105
miss=5
pseudo_lock_mea-376   [002] 69.409738: pseudo_lock_l2: hits=4105
miss=5
pseudo_lock_mea-379   [002] 70.466763: pseudo_lock_l2: hits=4105
miss=5


Second, reading data using rdpmcl() called twice.
This is the same solution as documented in my previous email, with the
two extra rdpmcl() calls added. An overview of the flow:

/* create perf events */
/* disable irq */
/* check perf event error state */
/* disable hw prefetchers */
/* init local vars */
/* read before data twice as follows: */
rdpmcl(l2_hit_pmcnum, l2_hits_before);
rdpmcl(l2_miss_pmcnum, l2_miss_before);
rdpmcl(l2_hit_pmcnum, l2_hits_before);
rdpmcl(l2_miss_pmcnum, l2_miss_before);
/* read through pseudo-locked memory */
rdpmcl(l2_hit_pmcnum, l2_hits_after);
rdpmcl(l2_miss_pmcnum, l2_miss_after);
/* re enable hw prefetchers */
/* enable irq */
/* write data to tracepoint */

Here as expected a simple test showed that the data was accurate
(hits=4096 miss=0) so I repeated the creation and measurement of
pseudo-locked region at different sizes under different loads. Each
possible pseudo-lock region size is created and measured 100 times on an
idle system and 100 times on a system with a noisy neighbor - this
resulted in a total of 2800 pseudo-lock region creations each followed
by a measurement of that region.

The results of these tests are the best I have yet seen. In this total
of 2800 measurements the number of cache hits were miscounted only in
eight measurements - each miscount was under(?) counted with one.
Specifically, a memory region consisting of 8192 cache lines was
measured as "hits=8191 miss=0", three memory regions with 12288 cache
lines were measured as "hits=12287 miss=0", two memory regions with
10240 cache lines were measured as "hits=10239 miss=0", and two memory
regions with 14336 cache lines were measured as "hits=1

Re: [PATCH v2] resource: Merge resources on a node when hot-adding memory

[Rashmica Gupta]

On Tue, Aug 7, 2018 at 9:52 PM, Vlastimil Babka  wrote:
> On 08/06/2018 08:52 AM, Rashmica Gupta wrote:
>> When hot-removing memory release_mem_region_adjustable() splits
>> iomem resources if they are not the exact size of the memory being
>> hot-deleted. Adding this memory back to the kernel adds a new
>> resource.
>>
>> Eg a node has memory 0x0 - 0xf. Offlining and hot-removing
>> 1GB from 0xf4000 results in the single resource 0x0-0xf being
>> split into two resources: 0x0-0xf3fff and 0xf8000-0xf.
>>
>> When we hot-add the memory back we now have three resources:
>> 0x0-0xf3fff, 0xf4000-0xf7fff, and 0xf8000-0xf.
>>
>> Now if we try to remove a section of memory that overlaps these resources,
>> like 2GB from 0xf4000, release_mem_region_adjustable() fails as it
>> expects the chunk of memory to be within the boundaries of a single
>> resource.
>
> Hi,
>
> it's the first time I see the resource code, so I might be easily wrong.
> How can it happen that the second remove is section aligned but the
> first one not?
>

I probably shouldn't have used that word... When I said "a section of memory"
I really meant "a chunk of memory" or "some memory".


>> This patch adds a function request_resource_and_merge(). This is called
>> instead of request_resource_conflict() when registering a resource in
>> add_memory(). It calls request_resource_conflict() and if hot-removing is
>> enabled (if it isn't we won't get resource fragmentation) we attempt to
>> merge contiguous resources on the node.
>>
>> Signed-off-by: Rashmica Gupta 
> ...
>> --- a/kernel/resource.c
>> +++ b/kernel/resource.c
> ...
>> +/*
>> + * Attempt to merge resources on the node
>> + */
>> +static void merge_node_resources(int nid, struct resource *parent)
>> +{
>> + struct resource *res;
>> + uint64_t start_addr;
>> + uint64_t end_addr;
>> + int ret;
>> +
>> + start_addr = node_start_pfn(nid) << PAGE_SHIFT;
>> + end_addr = node_end_pfn(nid) << PAGE_SHIFT;
>> +
>> + write_lock(&resource_lock);
>> +
>> + /* Get the first resource */
>> + res = parent->child;
>> +
>> + while (res) {
>> + /* Check that the resource is within the node */
>> + if (res->start < start_addr) {
>> + res = res->sibling;
>> + continue;
>> + }
>> + /* Exit if resource is past end of node */
>> + if (res->sibling->end > end_addr)
>> + break;
>
> IIUC, resource end is closed, so adjacent resources's start is end+1.
> But node_end_pfn is open, so the comparison above should use '>='
> instead of '>'?

You are right. Thanks for spotting that.

>
>> +
>> + ret = merge_resources(res);
>> + if (!ret)
>> + continue;
>> + res = res->sibling;
>
> Should this rather use next_resource() to merge at all levels of the
> hierarchy? Although memory seems to be flat under &iomem_resource so it
> would be just future-proofing.

I don't know enough about the hierarchy and layout of resources to comment on
this.

>
> Thanks,
> Vlastimil

Re: [PATCH RFC 00/10] Introduce lockless shrink_slab()

[Shakeel Butt]

On Tue, Aug 7, 2018 at 6:12 PM Stephen Rothwell  wrote:
>
> Hi Kirill,
>
> On Tue, 07 Aug 2018 18:37:19 +0300 Kirill Tkhai  wrote:
> >
> > After bitmaps of not-empty memcg shrinkers were implemented
> > (see "[PATCH v9 00/17] Improve shrink_slab() scalability..."
> > series, which is already in mm tree), all the evil in perf
> > trace has moved from shrink_slab() to down_read_trylock().
> > As reported by Shakeel Butt:
> >
> >  > I created 255 memcgs, 255 ext4 mounts and made each memcg create a
> >  > file containing few KiBs on corresponding mount. Then in a separate
> >  > memcg of 200 MiB limit ran a fork-bomb.
> >  >
> >  > I ran the "perf record -ag -- sleep 60" and below are the results:
> >  > +  47.49%fb.sh  [kernel.kallsyms][k] 
> > down_read_trylock
> >  > +  30.72%fb.sh  [kernel.kallsyms][k] up_read
> >  > +   9.51%fb.sh  [kernel.kallsyms][k] mem_cgroup_iter
> >  > +   1.69%fb.sh  [kernel.kallsyms][k] 
> > shrink_node_memcg
> >  > +   1.35%fb.sh  [kernel.kallsyms][k] 
> > mem_cgroup_protected
> >  > +   1.05%fb.sh  [kernel.kallsyms][k] 
> > queued_spin_lock_slowpath
> >  > +   0.85%fb.sh  [kernel.kallsyms][k] _raw_spin_lock
> >  > +   0.78%fb.sh  [kernel.kallsyms][k] lruvec_lru_size
> >  > +   0.57%fb.sh  [kernel.kallsyms][k] shrink_node
> >  > +   0.54%fb.sh  [kernel.kallsyms][k] queue_work_on
> >  > +   0.46%fb.sh  [kernel.kallsyms][k] 
> > shrink_slab_memcg
> >
> > The patchset continues to improve shrink_slab() scalability and makes
> > it lockless completely. Here are several steps for that:
>
> So do you have any numbers for after theses changes?
>

I will do the same experiment as before with these patches sometime
this or next week.

BTW Kirill, thanks for pushing this.

regards,
Shakeel

Re: [PATCH 3.18 00/85] 3.18.118-stable review

[Greg Kroah-Hartman]

On Tue, Aug 07, 2018 at 08:52:59PM -0600, Shuah Khan wrote:
> On 08/07/2018 12:51 PM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 3.18.118 release.
> > There are 85 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Thu Aug  9 17:23:43 UTC 2018.
> > Anything received after that time might be too late.
> > 
> > The whole patch series can be found in one patch at:
> > 
> > https://www.kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.18.118-rc1.gz
> > or in the git tree and branch at:
> > 
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> > linux-3.18.y
> > and the diffstat can be found below.
> > 
> > thanks,
> > 
> > greg k-h
> > 
> 
> Compiled and booted on my test system. No dmesg regressions.

Thanks for testing all of these and letting me know.

greg k-h

Re: [PATCH 4.14 222/246] ext4: fix check to prevent initializing reserved inodes

[Greg Kroah-Hartman]

On Wed, Aug 08, 2018 at 12:17:30AM +0200, Matthias Schiffer wrote:
> On 08/01/2018 06:52 PM, Greg Kroah-Hartman wrote:
> > 4.14-stable review patch.  If anyone has any objections, please let me know.
> 
> It seems this patch is still missing from the 4.4.y and 4.9.y branches.

Maybe because no one has provided a working backport?  :)

Re: [PATCH 4.9 00/17] 4.9.119-stable review

[Naresh Kamboju]

On 8 August 2018 at 00:21, Greg Kroah-Hartman
 wrote:
> This is the start of the stable review cycle for the 4.9.119 release.
> There are 17 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Thu Aug  9 17:23:30 UTC 2018.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> 
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.119-rc1.gz
> or in the git tree and branch at:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.9.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

Results from Linaro’s test farm.
No regressions on arm64, arm and x86_64.

Summary


kernel: 4.9.119-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.9.y
git commit: 1e9cd04e077b33f5dbecb2ddbc53695724b0cf97
git describe: v4.9.118-18-g1e9cd04e077b
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.118-18-g1e9cd04e077b

No regressions (compared to build v4.9.118-17-g575cd33d16af)


Ran 15539 total tests in the following environments and test suites.

Environments
--
- dragonboard-410c - arm64
- hi6220-hikey - arm64
- juno-r2 - arm64
- qemu_arm
- qemu_arm64
- qemu_x86_64
- x15 - arm
- x86_64

Test Suites
---
* boot
* kselftest
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-containers-tests
* ltp-cve-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-timers-tests
* ltp-open-posix-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none

-- 
Linaro LKFT
https://lkft.linaro.org

Re: [PATCH 4.14 00/21] 4.14.62-stable review

[Naresh Kamboju]

On 8 August 2018 at 00:21, Greg Kroah-Hartman
 wrote:
> This is the start of the stable review cycle for the 4.14.62 release.
> There are 21 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Thu Aug  9 17:23:22 UTC 2018.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> 
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.62-rc1.gz
> or in the git tree and branch at:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.14.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

Results from Linaro’s test farm.
No regressions on arm64, arm and x86_64.

Summary


kernel: 4.14.62-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.14.y
git commit: 5a43290b0403cc685cb30f8b65843e03980e9499
git describe: v4.14.61-22-g5a43290b0403
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.14-oe/build/v4.14.61-22-g5a43290b0403

No regressions (compared to build v4.14.61-21-g24cbd55fcf52)


Ran 16631 total tests in the following environments and test suites.

Environments
--
- dragonboard-410c - arm64
- hi6220-hikey - arm64
- juno-r2 - arm64
- qemu_arm
- qemu_arm64
- qemu_x86_64
- x15 - arm
- x86_64

Test Suites
---
* boot
* kselftest
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-containers-tests
* ltp-cve-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-syscalls-tests
* ltp-timers-tests
* ltp-securebits-tests
* ltp-open-posix-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none

-- 
Linaro LKFT
https://lkft.linaro.org

Re: [PATCH 4.17 00/18] 4.17.14-stable review

[Naresh Kamboju]

On 8 August 2018 at 00:21, Greg Kroah-Hartman
 wrote:
> This is the start of the stable review cycle for the 4.17.14 release.
> There are 18 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Thu Aug  9 17:23:05 UTC 2018.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> 
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.17.14-rc1.gz
> or in the git tree and branch at:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.17.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h


Results from Linaro’s test farm.
No regressions on arm64, arm and x86_64.


Summary


kernel: 4.17.14-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.17.y
git commit: 53b91e019709af31eaf31b16123585f05c00a411
git describe: v4.17.13-19-g53b91e019709
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.17-oe/build/v4.17.13-19-g53b91e019709

No regressions (compared to build v4.17.13)


Ran 13918 total tests in the following environments and test suites.

Environments
--
- dragonboard-410c - arm64
- hi6220-hikey - arm64
- juno-r2 - arm64
- qemu_arm
- qemu_arm64
- qemu_x86_64
- x15 - arm
- x86_64

Test Suites
---
* boot
* kselftest
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-containers-tests
* ltp-cve-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-timers-tests
* ltp-open-posix-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none

-- 
Linaro LKFT
https://lkft.linaro.org

Re: [PATCH] x86/cpu: Rename Denverton and Gemini Lake

[Thomas Gleixner]

On Tue, 7 Aug 2018, Andi Kleen wrote:

> > Which simply does not work. Look at Goldmont Fam 6 Model 5C. The SoCs
> > with that Fam/Model combination are:
> > 
> >  - Apollo Lake
> >  - Broxton (has two platforms: Morganfield and Willowtrail)
> 
> Right pick one. The others are the same for software purposes
> and can be handled in the same way.

Pick one is really not a good choice. 

> > It's even worse with Silvermont.
> > 
> > So no, the interesting information is the UARCH and the variant of that,
> 
> With Uarch you mean the core uarch?  That doesn't really work for
> something like Silvermont or Goldmont.
> 
> > e.g. UARCH_CLIENT, UARCH_SERVER, UARCH_WHATEVER. All the magic Code Names
> 
> Right your scheme totally doesn't work on Silvermont because there
> are multiple client variants.

We have that for the big cores as well:

#define INTEL_FAM6_HASWELL_CORE 0x3C
#define INTEL_FAM6_HASWELL_X0x3F
#define INTEL_FAM6_HASWELL_ULT  0x45
#define INTEL_FAM6_HASWELL_GT3E 0x46

Why would we treat ATOM differently? It's all the same scheme:

SILVERMONT_CLIENT   0x37 Baytrail, Valleyview
SILVERMONT_SERVER   0x40 Avaton, Rangely

and on goldmont it's not any different.

We really want one scheme for both Core and ATOM and not randomly picked
different ones. For the kernel (aside of some peripheral stuff) the most
interesting information is the UARCH plus the extra features which are
enabled on a particular SoC.

The current naming scheme e.g. for SILVERMONT is utter crap because the 1/2
variants are in fact CLIENT/SERVER and the comment in the header file, that
there is no better name, is just silly.

Thanks,

tglx

Re: [PATCH v12 3/3] tracing: Centralize preemptirq tracepoints and unify their usage

[Joel Fernandes]

On Tue, Aug 7, 2018 at 8:53 PM, Joel Fernandes  wrote:
> On Tue, Aug 7, 2018 at 8:44 PM, Joel Fernandes  wrote:
>> Hi Steve,
>>
>> On Tue, Aug 7, 2018 at 7:28 PM, Steven Rostedt  wrote:
> [...]
 @@ -171,8 +174,7 @@ extern void syscall_unregfunc(void);
   } while ((++it_func_ptr)->func);\
   }   \
   \
 - if (rcuidle)\
 - srcu_read_unlock_notrace(&tracepoint_srcu, idx);\
 + srcu_read_unlock_notrace(ss, idx);  \
>>>
>>> Hmm, why do we have the two different srcu handles?
>>
>> Because if the memory operations happening on the normal SRCU handle
>> (during srcu_read_lock) is interrupted by NMI, then the other handle
>> (devoted to NMI) could be used instead and not bother the interrupted
>> handle. Does that makes sense?
>>
>> When I talked to Paul few months ago about SRCU from NMI context, he
>> mentioned the per-cpu memory operations during srcu_read_lock can be
>> NMI interrupted, that's why we added that warning.
>
> So I looked more closely, __srcu_read_lock on 2 different handles may
> still be doing a this_cpu_inc on the same location..
> (sp->sda->srcu_lock_count). :-(
>
> Paul any ideas on how to solve this?
>
> It does start to seem like a show stopper :-(

Steve, another thing we could do is drop "tracepoint: Make rcuidle
tracepoint callers use SRCU" and just call into irqsoff and preemptoff
tracer hooks directly.

The reason I added "tracepoint: Make rcuidle tracepoint callers use
SRCU" is because lockdep's performance dropped with existing
tracepoint code and SRCU improved that. But now that you're calling
directly into lockdep that shouldn't be an issue.

That should resolve your NMI issues and keep my macro and other clean
ups from the original patch. What do you think?

I am out in the morning, but I could write this up in the evening when
I get some time (unless you do it before me).

thanks,

 - Joel

did you recieve

[Roy Robinson]

Did you receive my email yesterday?

Just want to check if you have needs for photo editing for our studio?
We normally edit 300 images within 12-24 hours.

We take care of different kinds of e-commerce photos, jewelry images, and
portrait model images.

Including cutting out and clipping path and others, we also give retouching
for your images.

You may drop us a photo if you want to check our quality, we will provide
testing.

Thanks,
Roy

Re: [PATCH] Input: cros_ec_keyb: Remove check before calling pm_wakeup_event.

[Marek Szyprowski]

Hi Ravi,

On 2018-08-07 23:59, Ravi Chandra Sadineni wrote:
> hi Merek,
>
> I tried booting a snow device and could not get it to boot it to the
> console. I assume i don't have right kernel config. Can you share your
> config if possible.

I use standard exynos_defconfig bundled with Linux kernel. I've followed
this instruction to boot in on Snow:

https://s-opensource.org/2016/03/24/use-mainline-u-boot-non-signed-kernels-exynos-chromebooks/

>
> Thanks,
> RaviOn Mon, Aug 6, 2018 at 4:05 PM Ravi Chandra Sadineni
>  wrote:
>> Hi Merek,
>>
>> Thanks for the info. Lemme understand what's going on. Will update the
>> thread once I have more info.
>>
>> Thanks,
>> Ravi
>> On Mon, Aug 6, 2018 at 12:15 AM Marek Szyprowski
>>  wrote:
>>> Hi Dmitry
>>>
>>> On 2018-08-06 08:16, Dmitry Torokhov wrote:
 On Sun, Aug 5, 2018 at 10:29 PM Marek Szyprowski
  wrote:
> Hi Ravi,
>
> On 2018-08-03 18:53, Ravi Chandra Sadineni wrote:
>> Understood. I am trying to reproduce this issue locally. Wanted to
>> know the version of the kernel so I can give a try. Marek, can you
>> please confirm the kernel version.
>>
> Yes, sorry for the missing context, I was in hurry writing the report and
> I wanted to send it before leaving the office. I'm testing mainline on 
> Snow
> with exynos_defconfig.
>
> Suspend/resume is partially broken already with mainline, but if you 
> disable
> CPUfreq support, it works fine on Linux v4.17.
>
> I've posted CPUfreq related fixes here if you are interested:
> https://patchwork.kernel.org/patch/10554607/
> https://patchwork.kernel.org/patch/10554603/
>
> The issue with cros_ec_keyb patch appears first on Linux v4.18-rc1, which 
> is
> the first release with that patch.
 Marek, this patch should only be in -next, I do not believe I sent it
 to Linus just yet. If mainline is broken for you it can't be caused by
 this patch.
>>> Aaahh. My fault then. The suspend/resume issue is cause by commit
>>> 38ba34a43dbc ("Input: cros_ec_keyb - mark cros_ec_keyb driver as wake
>>> enabled device."), which has been merged to v4.18-rc1.
>>>
>>> It looks that I've downloaded wrong patch from the patchwork to reply it
>>> with a a bug report. :( I'm really sorry for the noise in the wrong thread.
>>>
>>> Ravi: please let me know how can I help you to debug this issue.
>>>
> Linux -next from 20180803, which has a few
> more patches for cros_ec_keyb suffers from the same issue.
 Just to confirm, if you revert only this patch from -next you get
 suspend/resume back?

 Thanks.
>>> Best regards
>>> --
>>> Marek Szyprowski, PhD
>>> Samsung R&D Institute Poland
>>>
>

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

[PATCH 2/2] clk: imx: imx7d: remove clks_init_on array

[Anson Huang]

Clock framework will enable those clocks registered
with CLK_IS_CRITICAL flag, so no need to have
clks_init_on array during clock initialization now.

Signed-off-by: Anson Huang 
---
 drivers/clk/imx/clk-imx7d.c | 27 ---
 drivers/clk/imx/clk.h   |  7 +++
 2 files changed, 15 insertions(+), 19 deletions(-)

diff --git a/drivers/clk/imx/clk-imx7d.c b/drivers/clk/imx/clk-imx7d.c
index c4518d7..076460b 100644
--- a/drivers/clk/imx/clk-imx7d.c
+++ b/drivers/clk/imx/clk-imx7d.c
@@ -379,13 +379,6 @@ static const char *pll_enet_bypass_sel[] = { 
"pll_enet_main", "pll_enet_main_src
 static const char *pll_audio_bypass_sel[] = { "pll_audio_main", 
"pll_audio_main_src", };
 static const char *pll_video_bypass_sel[] = { "pll_video_main", 
"pll_video_main_src", };
 
-static int const clks_init_on[] __initconst = {
-   IMX7D_ARM_A7_ROOT_CLK, IMX7D_MAIN_AXI_ROOT_CLK,
-   IMX7D_PLL_SYS_MAIN_480M_CLK, IMX7D_IPG_ROOT_CLK,
-   IMX7D_DRAM_PHYM_ROOT_CLK, IMX7D_DRAM_ROOT_CLK,
-   IMX7D_DRAM_PHYM_ALT_ROOT_CLK, IMX7D_DRAM_ALT_ROOT_CLK,
-};
-
 static struct clk_onecell_data clk_data;
 
 static struct clk ** const uart_clks[] __initconst = {
@@ -403,7 +396,6 @@ static void __init imx7d_clocks_init(struct device_node 
*ccm_node)
 {
struct device_node *np;
void __iomem *base;
-   int i;
 
clks[IMX7D_CLK_DUMMY] = imx_clk_fixed("dummy", 0);
clks[IMX7D_OSC_24M_CLK] = of_clk_get_by_name(ccm_node, "osc");
@@ -466,7 +458,7 @@ static void __init imx7d_clocks_init(struct device_node 
*ccm_node)
clks[IMX7D_PLL_SYS_MAIN_120M] = 
imx_clk_fixed_factor("pll_sys_main_120m", "pll_sys_main_clk", 1, 4);
clks[IMX7D_PLL_DRAM_MAIN_533M] = imx_clk_fixed_factor("pll_dram_533m", 
"pll_dram_main_clk", 1, 2);
 
-   clks[IMX7D_PLL_SYS_MAIN_480M_CLK] = 
imx_clk_gate_dis("pll_sys_main_480m_clk", "pll_sys_main_480m", base + 0xb0, 4);
+   clks[IMX7D_PLL_SYS_MAIN_480M_CLK] = 
imx_clk_gate_dis_flags("pll_sys_main_480m_clk", "pll_sys_main_480m", base + 
0xb0, 4, CLK_IS_CRITICAL);
clks[IMX7D_PLL_SYS_MAIN_240M_CLK] = 
imx_clk_gate_dis("pll_sys_main_240m_clk", "pll_sys_main_240m", base + 0xb0, 5);
clks[IMX7D_PLL_SYS_MAIN_120M_CLK] = 
imx_clk_gate_dis("pll_sys_main_120m_clk", "pll_sys_main_120m", base + 0xb0, 6);
clks[IMX7D_PLL_DRAM_MAIN_533M_CLK] = imx_clk_gate("pll_dram_533m_clk", 
"pll_dram_533m", base + 0x70, 12);
@@ -719,7 +711,7 @@ static void __init imx7d_clocks_init(struct device_node 
*ccm_node)
clks[IMX7D_ENET_AXI_ROOT_DIV] = imx_clk_divider2("enet_axi_post_div", 
"enet_axi_pre_div", base + 0x8900, 0, 6);
clks[IMX7D_NAND_USDHC_BUS_ROOT_CLK] = 
imx_clk_divider2("nand_usdhc_root_clk", "nand_usdhc_pre_div", base + 0x8980, 0, 
6);
clks[IMX7D_AHB_CHANNEL_ROOT_DIV] = imx_clk_divider2("ahb_root_clk", 
"ahb_pre_div", base + 0x9000, 0, 6);
-   clks[IMX7D_IPG_ROOT_CLK] = imx_clk_divider2("ipg_root_clk", 
"ahb_root_clk", base + 0x9080, 0, 2);
+   clks[IMX7D_IPG_ROOT_CLK] = imx_clk_divider_flags("ipg_root_clk", 
"ahb_root_clk", base + 0x9080, 0, 2, CLK_IS_CRITICAL | CLK_OPS_PARENT_ENABLE | 
CLK_SET_RATE_PARENT);
clks[IMX7D_DRAM_ROOT_DIV] = imx_clk_divider2("dram_post_div", 
"dram_cg", base + 0x9880, 0, 3);
clks[IMX7D_DRAM_PHYM_ALT_ROOT_DIV] = 
imx_clk_divider2("dram_phym_alt_post_div", "dram_phym_alt_pre_div", base + 
0xa000, 0, 3);
clks[IMX7D_DRAM_ALT_ROOT_DIV] = imx_clk_divider2("dram_alt_post_div", 
"dram_alt_pre_div", base + 0xa080, 0, 3);
@@ -783,17 +775,17 @@ static void __init imx7d_clocks_init(struct device_node 
*ccm_node)
clks[IMX7D_CLKO1_ROOT_DIV] = imx_clk_divider2("clko1_post_div", 
"clko1_pre_div", base + 0xbd80, 0, 6);
clks[IMX7D_CLKO2_ROOT_DIV] = imx_clk_divider2("clko2_post_div", 
"clko2_pre_div", base + 0xbe00, 0, 6);
 
-   clks[IMX7D_ARM_A7_ROOT_CLK] = imx_clk_gate4("arm_a7_root_clk", 
"arm_a7_div", base + 0x4000, 0);
+   clks[IMX7D_ARM_A7_ROOT_CLK] = imx_clk_gate2_flags("arm_a7_root_clk", 
"arm_a7_div", base + 0x4000, 0, CLK_IS_CRITICAL | CLK_OPS_PARENT_ENABLE);
clks[IMX7D_ARM_M4_ROOT_CLK] = imx_clk_gate4("arm_m4_root_clk", 
"arm_m4_div", base + 0x4010, 0);
-   clks[IMX7D_MAIN_AXI_ROOT_CLK] = imx_clk_gate4("main_axi_root_clk", 
"axi_post_div", base + 0x4040, 0);
+   clks[IMX7D_MAIN_AXI_ROOT_CLK] = 
imx_clk_gate2_flags("main_axi_root_clk", "axi_post_div", base + 0x4040, 0, 
CLK_IS_CRITICAL | CLK_OPS_PARENT_ENABLE);
clks[IMX7D_DISP_AXI_ROOT_CLK] = imx_clk_gate4("disp_axi_root_clk", 
"disp_axi_post_div", base + 0x4050, 0);
clks[IMX7D_ENET_AXI_ROOT_CLK] = imx_clk_gate4("enet_axi_root_clk", 
"enet_axi_post_div", base + 0x4060, 0);
clks[IMX7D_OCRAM_CLK] = imx_clk_gate4("ocram_clk", "main_axi_root_clk", 
base + 0x4110, 0);
clks[IMX7D_OCRAM_S_CLK] = imx_clk_gate4("ocram_s_clk", "ahb_root_clk", 
base + 0x4120, 0);
-   clks[IMX7D_DRAM_ROOT_CLK] = imx_clk_gate4("dram_root_clk", 
"dram_post_div", base + 0

[PATCH 1/2] clk: imx: imx7d: remove unnecessary clocks from clks_init_on array

[Anson Huang]

On i.MX7D, IMX7D_NAND_USDHC_BUS_ROOT_CLK is NOT necessary
for system, and IMX7D_AHB_CHANNEL_ROOT_CLK is NOT existing
at all, remove them from clks_init_on array.

Signed-off-by: Anson Huang 
---
 drivers/clk/imx/clk-imx7d.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/clk/imx/clk-imx7d.c b/drivers/clk/imx/clk-imx7d.c
index 881b772..c4518d7 100644
--- a/drivers/clk/imx/clk-imx7d.c
+++ b/drivers/clk/imx/clk-imx7d.c
@@ -381,10 +381,9 @@ static const char *pll_video_bypass_sel[] = { 
"pll_video_main", "pll_video_main_
 
 static int const clks_init_on[] __initconst = {
IMX7D_ARM_A7_ROOT_CLK, IMX7D_MAIN_AXI_ROOT_CLK,
-   IMX7D_PLL_SYS_MAIN_480M_CLK, IMX7D_NAND_USDHC_BUS_ROOT_CLK,
+   IMX7D_PLL_SYS_MAIN_480M_CLK, IMX7D_IPG_ROOT_CLK,
IMX7D_DRAM_PHYM_ROOT_CLK, IMX7D_DRAM_ROOT_CLK,
IMX7D_DRAM_PHYM_ALT_ROOT_CLK, IMX7D_DRAM_ALT_ROOT_CLK,
-   IMX7D_AHB_CHANNEL_ROOT_CLK, IMX7D_IPG_ROOT_CLK,
 };
 
 static struct clk_onecell_data clk_data;
-- 
2.7.4

[RESEND PATCH] init/Kconfig: Use short unix-style option instead of --longname

[Masahiro Yamada]

From: Rob Landley 

Avoids warning messages with the latest release of toybox, which never
bothered to implement the --longopts nothing was using.

Signed-off-by: Rob Landley 
Signed-off-by: Masahiro Yamada 
---

This was sent to the trivial ML some time ago,
but not applied yet.

I will apply this to kbuild tree for v4.19

[yamada.masah...@socionext.com
 Move the patch description under '---'
 to the commit log body.
]


 init/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/init/Kconfig b/init/Kconfig
index 794a1b1..944b1fd 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -2,9 +2,9 @@ config DEFCONFIG_LIST
string
depends on !UML
option defconfig_list
-   default "/lib/modules/$(shell,uname --release)/.config"
+   default "/lib/modules/$(shell,uname -r)/.config"
default "/etc/kernel-config"
-   default "/boot/config-$(shell,uname --release)"
+   default "/boot/config-$(shell,uname -r)"
default ARCH_DEFCONFIG
default "arch/$(ARCH)/defconfig"
 
-- 
2.7.4

Re: [PATCH v2 08/18] serial: intel: Get serial id from dts

[Wu, Songjun]

On 8/7/2018 3:33 PM, Geert Uytterhoeven wrote:

Hi Songjun,

On Fri, Aug 3, 2018 at 5:04 AM Songjun Wu  wrote:

Get serial id from dts.

"#ifdef CONFIG_LANTIQ" preprocessor is used because LTQ_EARLY_ASC
macro is defined in lantiq_soc.h.
lantiq_soc.h is in arch path for legacy product support.

arch/mips/include/asm/mach-lantiq/xway/lantiq_soc.h

If "#ifdef preprocessor" is changed to
"if (IS_ENABLED(CONFIG_LANTIQ))", when CONFIG_LANTIQ is not enabled,
code using LTQ_EARLY_ASC is compiled.
Compilation will fail for no LTQ_EARLY_ASC defined.

Signed-off-by: Songjun Wu 

Thanks for your patch!


@@ -699,9 +700,19 @@ lqasc_probe(struct platform_device *pdev)
 return -ENODEV;
 }

-   /* check if this is the console port */
-   if (mmres->start != CPHYSADDR(LTQ_EARLY_ASC))
-   line = 1;
+   /* get serial id */
+   line = of_alias_get_id(node, "serial");
+   if (line < 0) {
+#ifdef CONFIG_LANTIQ
+   if (mmres->start == CPHYSADDR(LTQ_EARLY_ASC))
+   line = 0;
+   else
+   line = 1;
+#else
+   dev_err(&pdev->dev, "failed to get alias id, errno %d\n", line);
+   return line;

Please note that not providing a fallback here makes life harder when using
DT overlays.
See the description of commit 7678f4c20fa7670f ("serial: sh-sci: Add support
for dynamic instances") for background info.

Thanks for your comment.
The logic in commit 7678f4c20fa7670f is not suitable here.
We need to know which serial instance is used for console.
We cannot use dynamic serial instance here.

linux-next: manual merge of the kvm tree with the tip tree

[Stephen Rothwell]

Hi all,

Paolo pointed out a semantic conflict between the kvm tree and the tip
tree in

  arch/x86/kernel/kvm.c

between commit:

  368a540e0232 ("x86/kvmclock: Remove memblock dependency")

from the tip tree and commit:

  d63bae079b64 ("KVM: X86: Add kvm hypervisor init time platform setup 
callback")

from the kvm tree.

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

I applied the following (as suggested) after the automatic merge:

From: Stephen Rothwell 
Date: Wed, 8 Aug 2018 13:48:34 +1000
Subject: [PATCH] kvm: x86: fix semantic conflict in platform init

Signed-off-by: Stephen Rothwell 
---
 arch/x86/kernel/kvm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index 0906b8731393..e2499bad3209 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -714,13 +714,13 @@ static void __init kvm_apic_init(void)
 static void __init kvm_init_platform(void)
 {
x86_platform.apic_post_init = kvm_apic_init;
+   kvmclock_init();
 }
 
 const __initconst struct hypervisor_x86 x86_hyper_kvm = {
.name   = "KVM",
.detect = kvm_detect,
.type   = X86_HYPER_KVM,
-   .init.init_platform = kvmclock_init,
.init.guest_late_init   = kvm_guest_init,
.init.x2apic_available  = kvm_para_available,
.init.init_platform = kvm_init_platform,
-- 
2.18.0

-- 
Cheers,
Stephen Rothwell


pgpCy0p8GIxnH.pgp
Description: OpenPGP digital signature

Re: [PATCH v12 3/3] tracing: Centralize preemptirq tracepoints and unify their usage

[Joel Fernandes]

On Tue, Aug 7, 2018 at 8:44 PM, Joel Fernandes  wrote:
> Hi Steve,
>
> On Tue, Aug 7, 2018 at 7:28 PM, Steven Rostedt  wrote:
[...]
>>> @@ -171,8 +174,7 @@ extern void syscall_unregfunc(void);
>>>   } while ((++it_func_ptr)->func);\
>>>   }   \
>>>   \
>>> - if (rcuidle)\
>>> - srcu_read_unlock_notrace(&tracepoint_srcu, idx);\
>>> + srcu_read_unlock_notrace(ss, idx);  \
>>
>> Hmm, why do we have the two different srcu handles?
>
> Because if the memory operations happening on the normal SRCU handle
> (during srcu_read_lock) is interrupted by NMI, then the other handle
> (devoted to NMI) could be used instead and not bother the interrupted
> handle. Does that makes sense?
>
> When I talked to Paul few months ago about SRCU from NMI context, he
> mentioned the per-cpu memory operations during srcu_read_lock can be
> NMI interrupted, that's why we added that warning.

So I looked more closely, __srcu_read_lock on 2 different handles may
still be doing a this_cpu_inc on the same location..
(sp->sda->srcu_lock_count). :-(

Paul any ideas on how to solve this?

It does start to seem like a show stopper :-(

Re: [PATCH v3] PCI/AER: Do not clear AER bits if we don't own AER

[Alex G.]

On 08/07/2018 08:14 PM, Bjorn Helgaas wrote:

On Mon, Jul 30, 2018 at 06:35:31PM -0500, Alexandru Gagniuc wrote:

When we don't own AER, we shouldn't touch the AER error bits. Clearing
error bits willy-nilly might cause firmware to miss some errors. In
theory, these bits get cleared by FFS, or via ACPI _HPX method. These
mechanisms are not subject to the problem.


What's FFS?


Firmware-first. Nobody likes spelling it out, and all other proposed 
acronyms are insanely tong-twisting. So, FFS.



I guess you mean FFS and _HPX are not subject to the problem because
they're supplied by firmware, so firmware would be responsible for
looking at the bits before clearing them?


Exactly.


This race is mostly of theoretical significance, since I can't
reasonably demonstrate this race in the lab.

On a side-note, pcie_aer_is_kernel_first() is created to alleviate the
need for two checks: aer_cap and get_firmware_first().

Signed-off-by: Alexandru Gagniuc 
---

Changes since v2:
   - Added missing negation in pci_cleanup_aer_error_status_regs()

  drivers/pci/pcie/aer.c | 17 ++---
  1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c
index a2e88386af28..40e5c86271d1 100644
--- a/drivers/pci/pcie/aer.c
+++ b/drivers/pci/pcie/aer.c
@@ -307,6 +307,12 @@ int pcie_aer_get_firmware_first(struct pci_dev *dev)
aer_set_firmware_first(dev);
return dev->__aer_firmware_first;
  }
+
+static bool pcie_aer_is_kernel_first(struct pci_dev *dev)
+{
+   return !!dev->aer_cap && !pcie_aer_get_firmware_first(dev);
+}


I think it complicates things to have both "firmware_first" and
"kernel_first" interfaces, so I would prefer to stick with the
existing "firmware_first" style.


  #define   PCI_EXP_AER_FLAGS   (PCI_EXP_DEVCTL_CERE | 
PCI_EXP_DEVCTL_NFERE | \
 PCI_EXP_DEVCTL_FERE | PCI_EXP_DEVCTL_URRE)
  
@@ -337,10 +343,7 @@ bool aer_acpi_firmware_first(void)
  
  int pci_enable_pcie_error_reporting(struct pci_dev *dev)

  {
-   if (pcie_aer_get_firmware_first(dev))
-   return -EIO;
-
-   if (!dev->aer_cap)
+   if (!pcie_aer_is_kernel_first(dev))
return -EIO;
  
  	return pcie_capability_set_word(dev, PCI_EXP_DEVCTL, PCI_EXP_AER_FLAGS);


This change doesn't actually fix anything, does it?  It looks like a
cleanup that doesn't change the behavior.


Initially (v1), this was a one-liner, but someone had a complaint about 
having pcie_aer_get_firmware_first() boilerplate all over the place. 
That's why I added the "kernel_first" function (previous comment), and 
then updated this here for completeness. I'm also fine with v1.



@@ -349,7 +352,7 @@ EXPORT_SYMBOL_GPL(pci_enable_pcie_error_reporting);
  
  int pci_disable_pcie_error_reporting(struct pci_dev *dev)

  {
-   if (pcie_aer_get_firmware_first(dev))
+   if (!pcie_aer_is_kernel_first(dev))
return -EIO;


This change does effectively add a test for dev->aer_cap.  That makes
sense in terms of symmetry with pci_enable_pcie_error_reporting(),
but I think it should be a separate patch because it's conceptually
separate from the change below.

We should keep the existing behavior (but add the symmetry) here for
now, but it's not clear to me that these paths should care about AER
or firmware-first at all.  PCI_EXP_DEVCTL is not an AER register and
we have the _HPX mechanism for firmware to influence it (which these
paths currently ignore).  I suspect we should program these reporting
enable bits in the core enumeration path instead of having drivers
call these interfaces.


The headache is that FFS needs the reporting bit to stay enabled in 
order to get AER notifications. Disabling things here could really break 
firmware. Of course, that's a cyclical argument, since FW is broken by 
definition.



If/when we make changes along these lines, the history will be easier
to follow if *this* change is not connected with the change below to
pci_cleanup_aer_error_status_regs().


I agree. I think it might be preferred then to go with v1, and leave the 
refactoring to a later time, since the extra changes are cosmetical and 
social.



return pcie_capability_clear_word(dev, PCI_EXP_DEVCTL,
@@ -383,10 +386,10 @@ int pci_cleanup_aer_error_status_regs(struct pci_dev *dev)
if (!pci_is_pcie(dev))
return -ENODEV;
  
-	pos = dev->aer_cap;

-   if (!pos)
+   if (!pcie_aer_is_kernel_first(dev))
return -EIO;


This part makes sense to me, but I think I would rather have it match
the existing style in pci_enable_pcie_error_reporting(), i.e., keep
the test for dev->aer_cap and add a test for
pcie_aer_get_firmware_first().


Had it that way in v1.

Alex


+   pos = dev->aer_cap;
port_type = pci_pcie_type(dev);
if (port_type == PCI_EXP_TYPE_ROOT_PORT) {
pci_read_config_dword(dev, pos + PCI_ERR_ROOT_STATUS, &status);

Re: [PATCH v12 3/3] tracing: Centralize preemptirq tracepoints and unify their usage

[Joel Fernandes]

Hi Steve,

On Tue, Aug 7, 2018 at 7:28 PM, Steven Rostedt  wrote:
> On Tue, 7 Aug 2018 19:13:32 -0700
> Joel Fernandes  wrote:
>> >
>> >> From 6986af946ceb04fc9ddc6d5b45fc559b6807e465 Mon Sep 17 00:00:00 2001
>> >> From: "Joel Fernandes (Google)" 
>> >> Date: Sun, 5 Aug 2018 20:17:41 -0700
>> >> Subject: [PATCH] tracepoint: Run tracepoints even after CPU is offline
>> >>
>> >> Commit f37755490fe9 ("tracepoints: Do not trace when cpu is offline")
>> >> causes a problem for lockdep using tracepoint code. Once a CPU is
>> >> offline, tracepoints donot get called, however this causes a big problem
>> >> for lockdep probes that need to run so that IRQ annotations are marked
>> >> correctly.
>> >>
>> >> A race is possible where while the CPU is going offline, an interrupt
>> >> can come in and then a lockdep assert causes an annotation warning:
>> >>
>> >> [  106.551354] IRQs not enabled as expected
>> >> [  106.551785] WARNING: CPU: 1 PID: 0 at kernel/time/tick-sched.c:982
>> >>  tick_nohz_idle_enter+0x99/0xb0
>> >> [  106.552964] Modules linked in:
>> >> [  106.553299] CPU: 1 PID: 0 Comm: swapper/1 Tainted: GW
>> >>
>> >> We need tracepoints to run as late as possible. This commit fixes the
>> >> issue by removing the cpu_online check in tracepoint code that was
>> >> introduced in the mentioned commit, however we now switch to using SRCU
>> >> for all tracepoints and special handle calling tracepoints from NMI so
>> >> that we don't run into issues that result from using sched-RCU when the
>> >> CPUs are marked to be offline.
>> >>
>> >> Fixes: c3bc8fd637a9 ("tracing: Centralize preemptirq tracepoints and
>> >>   unify their usage")
>> >> Reported-by: Masami Hiramatsu 
>> >> Signed-off-by: Joel Fernandes (Google) 
>> >
>> >
>> > The above change log doesn't look like it matches the NMI patch.
>> >
>> > Can you resend with just the NMI changes? I already handled the cpu
>> > offline ones.
>>
>> Ok, sent with "cpu offline" changes dropped, here it is:
>> https://lore.kernel.org/patchwork/patch/972657/
>>
>> If you could add your Reported-by to it, that would be great as well.
>>
>> >
>> > But I may still have concerns with this patch.
>>
>> Ok let me know what you think.
>>
>
> Not sure you saw this part of my reply:

I missed the part on the srcu handles, sorry.

>
>> @@ -171,8 +174,7 @@ extern void syscall_unregfunc(void);
>>   } while ((++it_func_ptr)->func);\
>>   }   \
>>   \
>> - if (rcuidle)\
>> - srcu_read_unlock_notrace(&tracepoint_srcu, idx);\
>> + srcu_read_unlock_notrace(ss, idx);  \
>
> Hmm, why do we have the two different srcu handles?

Because if the memory operations happening on the normal SRCU handle
(during srcu_read_lock) is interrupted by NMI, then the other handle
(devoted to NMI) could be used instead and not bother the interrupted
handle. Does that makes sense?

When I talked to Paul few months ago about SRCU from NMI context, he
mentioned the per-cpu memory operations during srcu_read_lock can be
NMI interrupted, that's why we added that warning.

> Thinking about this, if this can be called by the "thunk" code, then
> there might be an issue. I think the "thunk" code can be called before
> in_nmi() is set, so we don't know if we are in an NMI or not. I need to
> look at that code to make sure. If in_nmi() still works, then we should
> use the _nmi srcu handle (if that's required).
>
> But I'm not sure using SRCU for all tracepoints is needed at this
> moment. I'll have to look deeper into this tomorrow. But it's getting
> close to the merge window, and this needs to be settled quick. Another
> "partial revert" may be needed until this gets settled.

I did read this part, yes I'm not sure either. You mentioned you would
confirm that in the morning, I look forward to it. I hope the in_nmi()
function is reliable to use from here.

RE: [RFC 5/5] powerpc/fsl: Add supported-irq-ranges for P2020

[Bharat Bhushan]

> -Original Message-
> From: Scott Wood [mailto:o...@buserror.net]
> Sent: Wednesday, August 8, 2018 2:44 AM
> To: Bharat Bhushan ;
> b...@kernel.crashing.org; pau...@samba.org; m...@ellerman.id.au;
> ga...@kernel.crashing.org; mark.rutl...@arm.com;
> kstew...@linuxfoundation.org; gre...@linuxfoundation.org;
> devicet...@vger.kernel.org; linuxppc-...@lists.ozlabs.org; linux-
> ker...@vger.kernel.org
> Cc: r...@kernel.org; keesc...@chromium.org; tyr...@linux.vnet.ibm.com;
> j...@perches.com
> Subject: Re: [RFC 5/5] powerpc/fsl: Add supported-irq-ranges for P2020
> 
> On Fri, 2018-07-27 at 15:18 +0530, Bharat Bhushan wrote:
> > MPIC on NXP (Freescale) P2020 supports following irq
> > ranges:
> >   > 0 - 11  (External interrupt)
> >   > 16 - 79 (Internal interrupt)
> >   > 176 - 183   (Messaging interrupt)
> >   > 224 - 231   (Shared message signaled interrupt)
> 
> Why don't you convert to the 4-cell interrupt specifiers that make dealing
> with these ranges less error-prone?

Ok , will do if we agree to have this series as per comment on other patch.

> 
> > diff --git a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
> > b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
> > index 1006950..49ff348 100644
> > --- a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
> > +++ b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
> > @@ -57,6 +57,11 @@ void __init mpc85xx_rdb_pic_init(void)
> > MPIC_BIG_ENDIAN |
> > MPIC_SINGLE_DEST_CPU,
> > 0, 256, " OpenPIC  ");
> > +   } else if (of_machine_is_compatible("fsl,P2020RDB-PC")) {
> > +   mpic = mpic_alloc(NULL, 0,
> > + MPIC_BIG_ENDIAN |
> > + MPIC_SINGLE_DEST_CPU,
> > + 0, 0, " OpenPIC  ");
> > } else {
> > mpic = mpic_alloc(NULL, 0,
> >   MPIC_BIG_ENDIAN |
> 
> I don't think we want to grow a list of every single revision of every board 
> in
> these platform files.

One other confusing observation I have is that "irq_count" from platform code 
is given precedence over "last-interrupt-source" in device-tree.
Should not device-tree should have precedence otherwise there is no point using 
" last-interrupt-source" if platform code passes "irq_count" in mpic_alloc().

Thanks
-Bharat

> 
> -Scott

Re: [PATCH 2/3] perf report: Add raw report support for s390 auxiliary trace

[mpe]

Thomas Richter  writes:
> Add support for s390 auxiliary trace support.
> Use 'perf record -e rbd000' to create the perf.data file.
> The event also has the symbolic name SF_CYCLES_BASIC_DIAG,
> using 'perf record -e SF_CYCLES_BASIC_DIAG' is equivalent.
...
>
> Signed-off-by: Thomas Richter 
> Reviewed-by: Hendrik Brueckner 
> ---
>  tools/perf/util/s390-cpumsf-kernel.h |  71 
>  tools/perf/util/s390-cpumsf.c| 244 ++-
>  2 files changed, 314 insertions(+), 1 deletion(-)
>  create mode 100644 tools/perf/util/s390-cpumsf-kernel.h


I'm seeing a build break on ppc64le which seems to be caused by this
commit (I haven't bisected):

  util/s390-cpumsf.c: In function ‘trailer_timestamp’:
  util/s390-cpumsf.c:222:2: error: dereferencing type-punned pointer will break 
strict-aliasing rules [-Werror=strict-aliasing]
return *((unsigned long long *) &te->timestamp[te->t]);
^


And on powerpc big endian:
  In file included from util/cpumap.h:10:0,
   from util/s390-cpumsf.c:150:
  util/s390-cpumsf.c: In function ‘s390_cpumsf_basic_show’:
  util/s390-cpumsf.c:187:10: error: format ‘%lx’ expects argument of type ‘long 
unsigned int’, but argument 4 has type ‘size_t {aka unsigned int}’ 
[-Werror=format=]
 pr_err("Invalid AUX trace basic entry [%#08lx]\n", pos);
^

cheers

RE: [RFC 3/5] powerpc/mpic: Add support for non-contiguous irq ranges

[Bharat Bhushan]

> -Original Message-
> From: Scott Wood [mailto:o...@buserror.net]
> Sent: Wednesday, August 8, 2018 2:34 AM
> To: Rob Herring ; Bharat Bhushan
> 
> Cc: b...@kernel.crashing.org; pau...@samba.org; m...@ellerman.id.au;
> ga...@kernel.crashing.org; mark.rutl...@arm.com;
> kstew...@linuxfoundation.org; gre...@linuxfoundation.org;
> devicet...@vger.kernel.org; linuxppc-...@lists.ozlabs.org; linux-
> ker...@vger.kernel.org; keesc...@chromium.org;
> tyr...@linux.vnet.ibm.com; j...@perches.com
> Subject: Re: [RFC 3/5] powerpc/mpic: Add support for non-contiguous irq
> ranges
> 
> On Tue, 2018-08-07 at 12:09 -0600, Rob Herring wrote:
> > On Fri, Jul 27, 2018 at 03:17:59PM +0530, Bharat Bhushan wrote:
> > > Freescale MPIC h/w may not support all interrupt sources reported by
> > > hardware, "last-interrupt-source" or platform. On these platforms a
> > > misconfigured device tree that assigns one of the reserved
> > > interrupts leaves a non-functioning system without warning.
> >
> > There are lots of ways to misconfigure DTs. I don't think this is
> > special and needs a property.
> 
> Yeah, the system will be just as non-functioning if you specify a valid-but-
> wrong-for-the-device interrupt number.

Some is one additional benefits of this changes, MPIC have reserved regions for 
un-supported interrupts and read/writes to these reserved regions seams have no 
effect.
MPIC driver reads/writes to the reserved regions during init/uninit and 
save/restore state.

Let me know if it make sense to have these changes for mentioned reasons.

Thanks
-Bharat

> 
> >  We've had some interrupt mask or valid properties in the past, but
> > generally don't accept those.
> 
> FWIW, some of them like protected-sources and mpic-msgr-receive-mask
> aren't for detecting errors, but are for partitioning (though the former is
> obsolete with pic-no-reset).
> 
> -Scott

[PATCH v4 4/5] Allow to disable FPU support

[Alan Kao]

FPU codes have been separated from common part in previous patches.
This patch add the CONFIG_FPU option and some stubs, so that a no-FPU
configuration is allowed.

Signed-off-by: Alan Kao 
Cc: Greentime Hu 
Cc: Vincent Chen 
Cc: Zong Li 
Cc: Nick Hu 
---
 arch/riscv/Kconfig |  9 +
 arch/riscv/include/asm/switch_to.h | 10 ++
 arch/riscv/kernel/Makefile |  2 +-
 arch/riscv/kernel/process.c|  4 +++-
 arch/riscv/kernel/signal.c |  5 +
 5 files changed, 28 insertions(+), 2 deletions(-)

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 6debcc4afc72..6069597ba73f 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -232,6 +232,15 @@ config RISCV_BASE_PMU
 
 endmenu
 
+config FPU
+   bool "FPU support"
+   default y
+   help
+ Say N here if you want to disable all floating-point related procedure
+ in the kernel.
+
+ If you don't know what to do here, say Y.
+
 endmenu
 
 menu "Kernel type"
diff --git a/arch/riscv/include/asm/switch_to.h 
b/arch/riscv/include/asm/switch_to.h
index dd6b05bff75b..093050b03543 100644
--- a/arch/riscv/include/asm/switch_to.h
+++ b/arch/riscv/include/asm/switch_to.h
@@ -18,6 +18,7 @@
 #include 
 #include 
 
+#ifdef CONFIG_FPU
 extern void __fstate_save(struct task_struct *save_to);
 extern void __fstate_restore(struct task_struct *restore_from);
 
@@ -55,6 +56,15 @@ static inline void __switch_to_aux(struct task_struct *prev,
fstate_restore(next, task_pt_regs(next));
 }
 
+#define DEFAULT_SSTATUS (SR_SPIE | SR_FS_INITIAL)
+
+#else
+#define fstate_save(task, regs) do { } while (0)
+#define fstate_restore(task, regs) do { } while (0)
+#define __switch_to_aux(__prev, __next) do { } while (0)
+#define DEFAULT_SSTATUS (SR_SPIE | SR_FS_OFF)
+#endif
+
 extern struct task_struct *__switch_to(struct task_struct *,
   struct task_struct *);
 
diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
index bd433efd915e..f13f7f276639 100644
--- a/arch/riscv/kernel/Makefile
+++ b/arch/riscv/kernel/Makefile
@@ -13,7 +13,6 @@ extra-y += vmlinux.lds
 obj-y  += cpu.o
 obj-y  += cpufeature.o
 obj-y  += entry.o
-obj-y  += fpu.o
 obj-y  += irq.o
 obj-y  += process.o
 obj-y  += ptrace.o
@@ -32,6 +31,7 @@ obj-y += vdso/
 
 CFLAGS_setup.o := -mcmodel=medany
 
+obj-$(CONFIG_FPU)  += fpu.o
 obj-$(CONFIG_SMP)  += smpboot.o
 obj-$(CONFIG_SMP)  += smp.o
 obj-$(CONFIG_MODULES)  += module.o
diff --git a/arch/riscv/kernel/process.c b/arch/riscv/kernel/process.c
index cb209139ba53..3820d89e2db9 100644
--- a/arch/riscv/kernel/process.c
+++ b/arch/riscv/kernel/process.c
@@ -83,7 +83,7 @@ void show_regs(struct pt_regs *regs)
 void start_thread(struct pt_regs *regs, unsigned long pc,
unsigned long sp)
 {
-   regs->sstatus = SR_SPIE /* User mode, irqs on */ | SR_FS_INITIAL;
+   regs->sstatus = DEFAULT_SSTATUS;
regs->sepc = pc;
regs->sp = sp;
set_fs(USER_DS);
@@ -91,12 +91,14 @@ void start_thread(struct pt_regs *regs, unsigned long pc,
 
 void flush_thread(void)
 {
+#ifdef CONFIG_FPU
/*
 * Reset FPU context
 *  frm: round to nearest, ties to even (IEEE default)
 *  fflags: accrued exceptions cleared
 */
memset(¤t->thread.fstate, 0, sizeof(current->thread.fstate));
+#endif
 }
 
 int arch_dup_task_struct(struct task_struct *dst, struct task_struct *src)
diff --git a/arch/riscv/kernel/signal.c b/arch/riscv/kernel/signal.c
index 6a18b9819ead..2450b824d799 100644
--- a/arch/riscv/kernel/signal.c
+++ b/arch/riscv/kernel/signal.c
@@ -37,6 +37,7 @@ struct rt_sigframe {
struct ucontext uc;
 };
 
+#ifdef CONFIG_FPU
 static long restore_fp_state(struct pt_regs *regs,
 union __riscv_fp_state *sc_fpregs)
 {
@@ -85,6 +86,10 @@ static long save_fp_state(struct pt_regs *regs,
 
return err;
 }
+#else
+#define save_fp_state(task, regs) (0)
+#define restore_fp_state(task, regs) (0)
+#endif
 
 static long restore_sigcontext(struct pt_regs *regs,
struct sigcontext __user *sc)
-- 
2.18.0

[PATCH v4 1/5] Extract FPU context operations from entry.S

[Alan Kao]

We move __fstate_save and __fstate_restore to a new source
file, fpu.S.

Signed-off-by: Alan Kao 
Cc: Greentime Hu 
Cc: Vincent Chen 
Cc: Zong Li 
Cc: Nick Hu 
Reviewed-by: Christoph Hellwig 
---
 arch/riscv/kernel/Makefile |   1 +
 arch/riscv/kernel/entry.S  |  87 --
 arch/riscv/kernel/fpu.S| 106 +
 3 files changed, 107 insertions(+), 87 deletions(-)
 create mode 100644 arch/riscv/kernel/fpu.S

diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
index e1274fc03af4..bd433efd915e 100644
--- a/arch/riscv/kernel/Makefile
+++ b/arch/riscv/kernel/Makefile
@@ -13,6 +13,7 @@ extra-y += vmlinux.lds
 obj-y  += cpu.o
 obj-y  += cpufeature.o
 obj-y  += entry.o
+obj-y  += fpu.o
 obj-y  += irq.o
 obj-y  += process.o
 obj-y  += ptrace.o
diff --git a/arch/riscv/kernel/entry.S b/arch/riscv/kernel/entry.S
index 9aaf6c986771..edcd5920ee4e 100644
--- a/arch/riscv/kernel/entry.S
+++ b/arch/riscv/kernel/entry.S
@@ -357,93 +357,6 @@ ENTRY(__switch_to)
ret
 ENDPROC(__switch_to)
 
-ENTRY(__fstate_save)
-   li  a2,  TASK_THREAD_F0
-   add a0, a0, a2
-   li t1, SR_FS
-   csrs sstatus, t1
-   frcsr t0
-   fsd f0,  TASK_THREAD_F0_F0(a0)
-   fsd f1,  TASK_THREAD_F1_F0(a0)
-   fsd f2,  TASK_THREAD_F2_F0(a0)
-   fsd f3,  TASK_THREAD_F3_F0(a0)
-   fsd f4,  TASK_THREAD_F4_F0(a0)
-   fsd f5,  TASK_THREAD_F5_F0(a0)
-   fsd f6,  TASK_THREAD_F6_F0(a0)
-   fsd f7,  TASK_THREAD_F7_F0(a0)
-   fsd f8,  TASK_THREAD_F8_F0(a0)
-   fsd f9,  TASK_THREAD_F9_F0(a0)
-   fsd f10, TASK_THREAD_F10_F0(a0)
-   fsd f11, TASK_THREAD_F11_F0(a0)
-   fsd f12, TASK_THREAD_F12_F0(a0)
-   fsd f13, TASK_THREAD_F13_F0(a0)
-   fsd f14, TASK_THREAD_F14_F0(a0)
-   fsd f15, TASK_THREAD_F15_F0(a0)
-   fsd f16, TASK_THREAD_F16_F0(a0)
-   fsd f17, TASK_THREAD_F17_F0(a0)
-   fsd f18, TASK_THREAD_F18_F0(a0)
-   fsd f19, TASK_THREAD_F19_F0(a0)
-   fsd f20, TASK_THREAD_F20_F0(a0)
-   fsd f21, TASK_THREAD_F21_F0(a0)
-   fsd f22, TASK_THREAD_F22_F0(a0)
-   fsd f23, TASK_THREAD_F23_F0(a0)
-   fsd f24, TASK_THREAD_F24_F0(a0)
-   fsd f25, TASK_THREAD_F25_F0(a0)
-   fsd f26, TASK_THREAD_F26_F0(a0)
-   fsd f27, TASK_THREAD_F27_F0(a0)
-   fsd f28, TASK_THREAD_F28_F0(a0)
-   fsd f29, TASK_THREAD_F29_F0(a0)
-   fsd f30, TASK_THREAD_F30_F0(a0)
-   fsd f31, TASK_THREAD_F31_F0(a0)
-   sw t0, TASK_THREAD_FCSR_F0(a0)
-   csrc sstatus, t1
-   ret
-ENDPROC(__fstate_save)
-
-ENTRY(__fstate_restore)
-   li  a2,  TASK_THREAD_F0
-   add a0, a0, a2
-   li t1, SR_FS
-   lw t0, TASK_THREAD_FCSR_F0(a0)
-   csrs sstatus, t1
-   fld f0,  TASK_THREAD_F0_F0(a0)
-   fld f1,  TASK_THREAD_F1_F0(a0)
-   fld f2,  TASK_THREAD_F2_F0(a0)
-   fld f3,  TASK_THREAD_F3_F0(a0)
-   fld f4,  TASK_THREAD_F4_F0(a0)
-   fld f5,  TASK_THREAD_F5_F0(a0)
-   fld f6,  TASK_THREAD_F6_F0(a0)
-   fld f7,  TASK_THREAD_F7_F0(a0)
-   fld f8,  TASK_THREAD_F8_F0(a0)
-   fld f9,  TASK_THREAD_F9_F0(a0)
-   fld f10, TASK_THREAD_F10_F0(a0)
-   fld f11, TASK_THREAD_F11_F0(a0)
-   fld f12, TASK_THREAD_F12_F0(a0)
-   fld f13, TASK_THREAD_F13_F0(a0)
-   fld f14, TASK_THREAD_F14_F0(a0)
-   fld f15, TASK_THREAD_F15_F0(a0)
-   fld f16, TASK_THREAD_F16_F0(a0)
-   fld f17, TASK_THREAD_F17_F0(a0)
-   fld f18, TASK_THREAD_F18_F0(a0)
-   fld f19, TASK_THREAD_F19_F0(a0)
-   fld f20, TASK_THREAD_F20_F0(a0)
-   fld f21, TASK_THREAD_F21_F0(a0)
-   fld f22, TASK_THREAD_F22_F0(a0)
-   fld f23, TASK_THREAD_F23_F0(a0)
-   fld f24, TASK_THREAD_F24_F0(a0)
-   fld f25, TASK_THREAD_F25_F0(a0)
-   fld f26, TASK_THREAD_F26_F0(a0)
-   fld f27, TASK_THREAD_F27_F0(a0)
-   fld f28, TASK_THREAD_F28_F0(a0)
-   fld f29, TASK_THREAD_F29_F0(a0)
-   fld f30, TASK_THREAD_F30_F0(a0)
-   fld f31, TASK_THREAD_F31_F0(a0)
-   fscsr t0
-   csrc sstatus, t1
-   ret
-ENDPROC(__fstate_restore)
-
-
.section ".rodata"
/* Exception vector table */
 ENTRY(excp_vect_table)
diff --git a/arch/riscv/kernel/fpu.S b/arch/riscv/kernel/fpu.S
new file mode 100644
index ..1defb0618aff
--- /dev/null
+++ b/arch/riscv/kernel/fpu.S
@@ -0,0 +1,106 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2012 Regents of the University of California
+ * Copyright (C) 2017 SiFive
+ *
+ *   This program is free software; you can redistribute it and/or
+ *   modify it under the terms of the GNU General Public License
+ *   as published by the Free Software Foundation, version 2.
+ *
+ *   This program is distributed in the hope that it will be useful,
+ *   but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *   GNU General Public License for more details.
+ */
+
+#include 
+
+#include 
+#in

[PATCH v4 5/5] Auto-detect whether a FPU exists

[Alan Kao]

We expect that a kernel with CONFIG_FPU=y can still support no-FPU machines.
To do so, the kernel should first examine the existence of a FPU, then
do nothing if a FPU does exist; otherwise, it should disable/bypass all
FPU-related functions.

In this patch, a new global variable, no_fpu, is created and determined
when parsing the hardware capability from device tree during booting.
This variable is used in those FPU-related functions.

Signed-off-by: Alan Kao 
Cc: Greentime Hu 
Cc: Vincent Chen 
Cc: Zong Li 
Cc: Nick Hu 
---
 arch/riscv/include/asm/hwcap.h |  3 +++
 arch/riscv/include/asm/switch_to.h | 13 -
 arch/riscv/kernel/cpufeature.c | 11 +++
 arch/riscv/kernel/signal.c |  6 ++
 4 files changed, 32 insertions(+), 1 deletion(-)

diff --git a/arch/riscv/include/asm/hwcap.h b/arch/riscv/include/asm/hwcap.h
index 8a4ed7bbcbea..1b870086a869 100644
--- a/arch/riscv/include/asm/hwcap.h
+++ b/arch/riscv/include/asm/hwcap.h
@@ -33,5 +33,8 @@ enum {
 };
 
 extern unsigned long elf_hwcap;
+#ifdef CONFIG_FPU
+extern bool no_fpu;
+#endif
 #endif
 #endif
diff --git a/arch/riscv/include/asm/switch_to.h 
b/arch/riscv/include/asm/switch_to.h
index 093050b03543..7278e3eb7a70 100644
--- a/arch/riscv/include/asm/switch_to.h
+++ b/arch/riscv/include/asm/switch_to.h
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #ifdef CONFIG_FPU
 extern void __fstate_save(struct task_struct *save_to);
@@ -30,6 +31,9 @@ static inline void __fstate_clean(struct pt_regs *regs)
 static inline void fstate_save(struct task_struct *task,
   struct pt_regs *regs)
 {
+   if (unlikely(no_fpu))
+   return;
+
if ((regs->sstatus & SR_FS) == SR_FS_DIRTY) {
__fstate_save(task);
__fstate_clean(regs);
@@ -39,6 +43,9 @@ static inline void fstate_save(struct task_struct *task,
 static inline void fstate_restore(struct task_struct *task,
  struct pt_regs *regs)
 {
+   if (unlikely(no_fpu))
+   return;
+
if ((regs->sstatus & SR_FS) != SR_FS_OFF) {
__fstate_restore(task);
__fstate_clean(regs);
@@ -50,13 +57,17 @@ static inline void __switch_to_aux(struct task_struct *prev,
 {
struct pt_regs *regs;
 
+   if (unlikely(no_fpu))
+   return;
+
regs = task_pt_regs(prev);
if (unlikely(regs->sstatus & SR_SD))
fstate_save(prev, regs);
fstate_restore(next, task_pt_regs(next));
 }
 
-#define DEFAULT_SSTATUS (SR_SPIE | SR_FS_INITIAL)
+#define DEFAULT_SSTATUS \
+   ((unlikely(no_fpu)) ? (SR_SPIE | SR_FS_OFF) : (SR_SPIE | SR_FS_INITIAL))
 
 #else
 #define fstate_save(task, regs) do { } while (0)
diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c
index 17011a870044..bc269c1e0b1a 100644
--- a/arch/riscv/kernel/cpufeature.c
+++ b/arch/riscv/kernel/cpufeature.c
@@ -22,6 +22,9 @@
 #include 
 
 unsigned long elf_hwcap __read_mostly;
+#ifdef CONFIG_FPU
+bool no_fpu __read_mostly;
+#endif
 
 void riscv_fill_hwcap(void)
 {
@@ -58,4 +61,12 @@ void riscv_fill_hwcap(void)
elf_hwcap |= isa2hwcap[(unsigned char)(isa[i])];
 
pr_info("elf_hwcap is 0x%lx", elf_hwcap);
+
+#ifdef CONFIG_FPU
+   no_fpu = 0;
+   if (!(elf_hwcap & (COMPAT_HWCAP_ISA_F | COMPAT_HWCAP_ISA_D))) {
+   pr_info("Bypass FPU code.");
+   no_fpu = 1;
+   }
+#endif
 }
diff --git a/arch/riscv/kernel/signal.c b/arch/riscv/kernel/signal.c
index 2450b824d799..9714e4fccb69 100644
--- a/arch/riscv/kernel/signal.c
+++ b/arch/riscv/kernel/signal.c
@@ -45,6 +45,9 @@ static long restore_fp_state(struct pt_regs *regs,
struct __riscv_d_ext_state __user *state = &sc_fpregs->d;
size_t i;
 
+   if (unlikely(no_fpu))
+   return 0;
+
err = __copy_from_user(¤t->thread.fstate, state, sizeof(*state));
if (unlikely(err))
return err;
@@ -72,6 +75,9 @@ static long save_fp_state(struct pt_regs *regs,
struct __riscv_d_ext_state __user *state = &sc_fpregs->d;
size_t i;
 
+   if (unlikely(no_fpu))
+   return 0;
+
fstate_save(current, regs);
err = __copy_to_user(state, ¤t->thread.fstate, sizeof(*state));
if (unlikely(err))
-- 
2.18.0

[PATCH v4 2/5] Refactor FPU code in signal setup/return procedures

[Alan Kao]

FPU-related logic is separated from normal signal handling path in
this patch.  Kernel can easily be configured to exclude those procedures
for no-FPU systems.

Signed-off-by: Alan Kao 
Cc: Greentime Hu 
Cc: Vincent Chen 
Cc: Zong Li 
Cc: Nick Hu 
Reviewed-by: Christoph Hellwig 
---
 arch/riscv/kernel/signal.c | 68 +++---
 1 file changed, 41 insertions(+), 27 deletions(-)

diff --git a/arch/riscv/kernel/signal.c b/arch/riscv/kernel/signal.c
index 718d0c984ef0..6a18b9819ead 100644
--- a/arch/riscv/kernel/signal.c
+++ b/arch/riscv/kernel/signal.c
@@ -37,45 +37,63 @@ struct rt_sigframe {
struct ucontext uc;
 };
 
-static long restore_d_state(struct pt_regs *regs,
-   struct __riscv_d_ext_state __user *state)
+static long restore_fp_state(struct pt_regs *regs,
+union __riscv_fp_state *sc_fpregs)
 {
long err;
+   struct __riscv_d_ext_state __user *state = &sc_fpregs->d;
+   size_t i;
+
err = __copy_from_user(¤t->thread.fstate, state, sizeof(*state));
-   if (likely(!err))
-   fstate_restore(current, regs);
+   if (unlikely(err))
+   return err;
+
+   fstate_restore(current, regs);
+
+   /* We support no other extension state at this time. */
+   for (i = 0; i < ARRAY_SIZE(sc_fpregs->q.reserved); i++) {
+   u32 value;
+
+   err = __get_user(value, &sc_fpregs->q.reserved[i]);
+   if (unlikely(err))
+   break;
+   if (value != 0)
+   return -EINVAL;
+   }
+
return err;
 }
 
-static long save_d_state(struct pt_regs *regs,
-   struct __riscv_d_ext_state __user *state)
+static long save_fp_state(struct pt_regs *regs,
+ union __riscv_fp_state *sc_fpregs)
 {
+   long err;
+   struct __riscv_d_ext_state __user *state = &sc_fpregs->d;
+   size_t i;
+
fstate_save(current, regs);
-   return __copy_to_user(state, ¤t->thread.fstate, sizeof(*state));
+   err = __copy_to_user(state, ¤t->thread.fstate, sizeof(*state));
+   if (unlikely(err))
+   return err;
+
+   /* We support no other extension state at this time. */
+   for (i = 0; i < ARRAY_SIZE(sc_fpregs->q.reserved); i++) {
+   err = __put_user(0, &sc_fpregs->q.reserved[i]);
+   if (unlikely(err))
+   break;
+   }
+
+   return err;
 }
 
 static long restore_sigcontext(struct pt_regs *regs,
struct sigcontext __user *sc)
 {
long err;
-   size_t i;
/* sc_regs is structured the same as the start of pt_regs */
err = __copy_from_user(regs, &sc->sc_regs, sizeof(sc->sc_regs));
-   if (unlikely(err))
-   return err;
/* Restore the floating-point state. */
-   err = restore_d_state(regs, &sc->sc_fpregs.d);
-   if (unlikely(err))
-   return err;
-   /* We support no other extension state at this time. */
-   for (i = 0; i < ARRAY_SIZE(sc->sc_fpregs.q.reserved); i++) {
-   u32 value;
-   err = __get_user(value, &sc->sc_fpregs.q.reserved[i]);
-   if (unlikely(err))
-   break;
-   if (value != 0)
-   return -EINVAL;
-   }
+   err |= restore_fp_state(regs, &sc->sc_fpregs);
return err;
 }
 
@@ -124,14 +142,10 @@ static long setup_sigcontext(struct rt_sigframe __user 
*frame,
 {
struct sigcontext __user *sc = &frame->uc.uc_mcontext;
long err;
-   size_t i;
/* sc_regs is structured the same as the start of pt_regs */
err = __copy_to_user(&sc->sc_regs, regs, sizeof(sc->sc_regs));
/* Save the floating-point state. */
-   err |= save_d_state(regs, &sc->sc_fpregs.d);
-   /* We support no other extension state at this time. */
-   for (i = 0; i < ARRAY_SIZE(sc->sc_fpregs.q.reserved); i++)
-   err |= __put_user(0, &sc->sc_fpregs.q.reserved[i]);
+   err |= save_fp_state(regs, &sc->sc_fpregs);
return err;
 }
 
-- 
2.18.0

[PATCH v4 3/5] Cleanup ISA string setting

[Alan Kao]

Just a side note: (Assume that atomic and compressed is on)

Before this patch, assembler was always given the riscv64imafdc
MARCH string because there are fld/fsd's in entry.S; compiler was
always given riscv64imac because kernel doesn't need floating point
code generation.  After this, the MARCH string in AFLAGS and CFLAGS
become the same.

Signed-off-by: Alan Kao 
Cc: Greentime Hu 
Cc: Vincent Chen 
Cc: Zong Li 
Cc: Nick Hu 
Reviewed-by: Christoph Hellwig 
---
 arch/riscv/Makefile | 19 ---
 1 file changed, 8 insertions(+), 11 deletions(-)

diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile
index 6d4a5f6c3f4f..e0fe6790624f 100644
--- a/arch/riscv/Makefile
+++ b/arch/riscv/Makefile
@@ -26,7 +26,6 @@ ifeq ($(CONFIG_ARCH_RV64I),y)
 
KBUILD_CFLAGS += -mabi=lp64
KBUILD_AFLAGS += -mabi=lp64
-   KBUILD_MARCH = rv64im
LDFLAGS += -melf64lriscv
 else
BITS := 32
@@ -34,22 +33,20 @@ else
 
KBUILD_CFLAGS += -mabi=ilp32
KBUILD_AFLAGS += -mabi=ilp32
-   KBUILD_MARCH = rv32im
LDFLAGS += -melf32lriscv
 endif
 
 KBUILD_CFLAGS += -Wall
 
-ifeq ($(CONFIG_RISCV_ISA_A),y)
-   KBUILD_ARCH_A = a
-endif
-ifeq ($(CONFIG_RISCV_ISA_C),y)
-   KBUILD_ARCH_C = c
-endif
-
-KBUILD_AFLAGS += -march=$(KBUILD_MARCH)$(KBUILD_ARCH_A)fd$(KBUILD_ARCH_C)
+# ISA string setting
+riscv-march-$(CONFIG_ARCH_RV32I)   := rv32im
+riscv-march-$(CONFIG_ARCH_RV64I)   := rv64im
+riscv-march-$(CONFIG_RISCV_ISA_A)  := $(riscv-march-y)a
+riscv-march-y  := $(riscv-march-y)fd
+riscv-march-$(CONFIG_RISCV_ISA_C)  := $(riscv-march-y)c
+KBUILD_CFLAGS += -march=$(riscv-march-y)
+KBUILD_AFLAGS += -march=$(riscv-march-y)
 
-KBUILD_CFLAGS += -march=$(KBUILD_MARCH)$(KBUILD_ARCH_A)$(KBUILD_ARCH_C)
 KBUILD_CFLAGS += -mno-save-restore
 KBUILD_CFLAGS += -DCONFIG_PAGE_OFFSET=$(CONFIG_PAGE_OFFSET)
 
-- 
2.18.0

[PATCH v4 0/5] riscv: Add support to no-FPU systems

[Alan Kao]

This patchset adds an option, CONFIG_FPU, to enable/disable floating-
point procedures.

Kernel's new behavior will be as follows:

* with CONFIG_FPU=y
  All FPU codes are reserved.  If no FPU is found during booting, a
  global flag will be set, and those functions will be bypassed with
  condition check to that flag.

* with CONFIG_FPU=n
  No floating-point instructions in kernel and all related settings
  are excluded.

Changes in v4:
 - Append a new patch to detect existence of FPU and followups.
 - Add SPDX header to newly created fpu.S.
 - Fix a build error, sorry for that.
 - Fix wording, style, etc.

Changes in v3:
 - Refactor the whole patch into independent ones.

Changes in v2:
 - Various code cleanups and style fixes.

Alan Kao (5):
  Extract FPU context operations from entry.S
  Refactor FPU code in signal setup/return procedures
  Cleanup ISA string setting
  Allow to disable FPU support
  Auto-detect whether a FPU exists

 arch/riscv/Kconfig |   9 +++
 arch/riscv/Makefile|  19 +++---
 arch/riscv/include/asm/hwcap.h |   3 +
 arch/riscv/include/asm/switch_to.h |  21 ++
 arch/riscv/kernel/Makefile |   1 +
 arch/riscv/kernel/cpufeature.c |  11 +++
 arch/riscv/kernel/entry.S  |  87 ---
 arch/riscv/kernel/fpu.S| 106 +
 arch/riscv/kernel/process.c|   4 +-
 arch/riscv/kernel/signal.c |  79 +
 10 files changed, 214 insertions(+), 126 deletions(-)
 create mode 100644 arch/riscv/kernel/fpu.S

-- 
2.18.0

Re: [PATCH 2/2] spi: sprd: Add SPI driver for Spreadtrum SC9860

[Baolin Wang]

Hi Trent,

On 8 August 2018 at 01:10, Trent Piepho  wrote:
> On Tue, 2018-08-07 at 18:43 +0800, Baolin Wang wrote:
>>
>> +static u32 sprd_spi_transfer_max_timeout(struct sprd_spi *ss,
>> +  struct spi_transfer *t)
>> +{
>> + /*
>> +  * The time spent on transmission of the full FIFO data is the maximum
>> +  * SPI transmission time.
>> +  */
>> + u32 size = t->bits_per_word * SPRD_SPI_FIFO_SIZE;
>> + u32 bit_time_us = SPRD_SPI_HZ / t->speed_hz + 1;
>> + u32 total_time_us = size * bit_time_us;
>> + /*
>> +  * There is an interval between data and the data in our SPI hardware,
>> +  * so the total transmission time need add the interval time.
>> +  *
>> +  * The inteval calculation formula:
>> +  * interval time (source clock cycles) = interval * 4 + 10.
>> +  */
>> + u32 interval_cycle = SPRD_SPI_FIFO_SIZE * ((ss->interval << 2) + 10);
>> + u32 interval_time_us = interval_cycle * SPRD_SPI_HZ / ss->src_clk + 1;
>
> If interval is greater than 31, this will overflow.

Usually we will not set such a big value for interval,  but this is a
risk like you said. So we will check and limit the interval value to
make sure the formula will not overflow.

>
> Also SPRD_SPI_HZ is not the speed anything runs at, as one might think
> from the name.  It's the number of microseconds in a second.  The is
> already a Linux macro for that, USEC_PER_SEC, that you should use
> instead.

Right, will use USEC_PER_SEC instead.

>
>> +
>> + return total_time_us + interval_time_us;
>> +}
>> +
>
>
>> +static void sprd_spi_set_speed(struct sprd_spi *ss, u32 speed_hz)
>> +{
>> + /*
>> +  * From SPI datasheet, the prescale calculation formula:
>> +  * prescale = SPI source clock / (2 * SPI_freq) - 1;
>> +  */
>> + u32 clk_div = ss->src_clk / (speed_hz << 1) - 1;
>
> You should probably round up here.  The convention is to use the
> closest speed less than equal to the requested speed, but since this is
> a divider, rounding it down will select the next highest speed.

Per the datasheet, we do not need round up/down the speed. Since our
hardware can handle the clock calculated by the above formula if the
requested speed is in the normal region (less than ->max_speed_hz).

>> +
>> + writel_relaxed(clk_div, ss->base + SPRD_SPI_CLKD);
>> +}
>> +
>
>> +
>> +static int sprd_spi_probe(struct platform_device *pdev)
>> +{
>> + struct device_node *np = pdev->dev.of_node;
>> + struct spi_controller *sctlr;
>> + struct resource *res;
>> + struct sprd_spi *ss;
>> + int ret;
>> +
>> + pdev->id = of_alias_get_id(pdev->dev.of_node, "spi");
>> + sctlr = spi_alloc_master(&pdev->dev, sizeof(*ss));
>> + if (!sctlr)
>> + return -ENOMEM;
>> +
>> + ss = spi_controller_get_devdata(sctlr);
>> + if (of_property_read_u32(np, "sprd,spi-interval", &ss->interval))
>> + ss->interval = SPRD_SPI_ITVL_NUM;
>> +
>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> + ss->base = devm_ioremap_resource(&pdev->dev, res);
>> + if (IS_ERR(ss->base)) {
>> + ret = PTR_ERR(ss->base);
>> + goto free_controller;
>> + }
>> +
>> + ss->dev = &pdev->dev;
>> + sctlr->dev.of_node = pdev->dev.of_node;
>> + sctlr->mode_bits = SPI_CPOL | SPI_CPHA | SPI_3WIRE | SPI_TX_DUAL;
>> + sctlr->bus_num = pdev->id;
>> + sctlr->setup = sprd_spi_setup;
>> + sctlr->set_cs = sprd_spi_chipselect;
>> + sctlr->transfer_one = sprd_spi_transfer_one;
>> + sctlr->max_speed_hz = (ss->src_clk / 2) < SPRD_SPI_MAX_SPEED_HZ ?
>> + ss->src_clk / 2 : SPRD_SPI_MAX_SPEED_HZ;
>
> You can write this as:
> sctlr->max_speed_hz = min(ss->src_clk / 2, SPRD_SPI_MAX_SPEED_HZ);

Right. Thanks for your comments.

-- 
Baolin Wang
Best Regards

Re: [PATCH v2 03/18] dt-bindings: clk: Add documentation of grx500 clock controller

[yixin zhu]

On 8/6/2018 11:18 PM, Rob Herring wrote:

On Thu, Aug 2, 2018 at 9:03 PM Songjun Wu  wrote:

From: Yixin Zhu 

This patch adds binding documentation for grx500 clock controller.

Signed-off-by: YiXin Zhu 
Signed-off-by: Songjun Wu 
---

Changes in v2:
- Rewrite clock driver's dt-binding document according to Rob Herring's
   comments.
- Simplify device tree docoment, remove some clock description.

  .../devicetree/bindings/clock/intel,grx500-clk.txt | 39 ++

Please match the compatible string: intel,grx500-cgu.txt

Will update to use same name.




  1 file changed, 39 insertions(+)
  create mode 100644 
Documentation/devicetree/bindings/clock/intel,grx500-clk.txt

diff --git a/Documentation/devicetree/bindings/clock/intel,grx500-clk.txt 
b/Documentation/devicetree/bindings/clock/intel,grx500-clk.txt
new file mode 100644
index ..e54e1dad9196
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/intel,grx500-clk.txt
@@ -0,0 +1,39 @@
+Device Tree Clock bindings for grx500 PLL controller.
+
+This binding uses the common clock binding:
+   Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+The grx500 clock controller supplies clock to various controllers within the
+SoC.
+
+Required properties for clock node
+- compatible: Should be "intel,grx500-cgu".
+- reg: physical base address of the controller and length of memory range.
+- #clock-cells: should be 1.
+
+Optional Propteries:
+- intel,osc-frequency: frequency of the osc clock.
+if missing, driver will use clock rate defined in the driver.

This should use a fixed-clock node instead.

Yes, This is a fixed clock node registered in driver code.
The frequency of the fixed clock is designed to be overwritten by device 
tree in case some one verify
clock driver in the emulation platform or in some cases frequency other 
than driver defined one is preferred.
These kinds of cases are very rare. But I feel it would be better to 
have a way to use customized frequency.
The frequency defined in device tree will overwritten driver defined 
frequency before registering fixed-clock node.



+
+Example: Clock controller node:
+
+   cgu: cgu@1620 {
+compatible = "intel,grx500-cgu", "syscon";
+   reg = <0x1620 0x200>;
+   #clock-cells = <1>;
+   };
+
+
+Example: UART controller node that consumes the clock generated by clock
+   controller.
+
+   asc0: serial@1660 {
+   compatible = "lantiq,asc";
+   reg = <0x1660 0x10>;
+   interrupt-parent = <&gic>;
+   interrupts = ,
+   ,
+   ;
+   clocks = <&cgu CLK_SSX4>, <&cgu GCLK_UART>;
+   clock-names = "freq", "asc";
+   };
--
2.11.0

[PATCH] ASoC: max98373: Added software reset register to readable registers

[Ryan Lee]

Signed-off-by: Ryan Lee 
---
 Changes : Added 'MAX98373_R2000_SW_RESET' register to 
'max98373_readable_register'
   Software reset didn't work properly after suspend/resume.
 sound/soc/codecs/max98373.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/soc/codecs/max98373.c b/sound/soc/codecs/max98373.c
index a925861..92b7125 100644
--- a/sound/soc/codecs/max98373.c
+++ b/sound/soc/codecs/max98373.c
@@ -488,6 +488,7 @@ static const DECLARE_TLV_DB_RANGE(max98373_bde_gain_tlv,
 static bool max98373_readable_register(struct device *dev, unsigned int reg)
 {
switch (reg) {
+   case MAX98373_R2000_SW_RESET:
case MAX98373_R2001_INT_RAW1 ... MAX98373_R200C_INT_EN3:
case MAX98373_R2010_IRQ_CTRL:
case MAX98373_R2014_THERM_WARN_THRESH
-- 
2.7.4

Re: [PATCH 4.4 00/12] 4.4.147-stable review

[Shuah Khan]

On 08/07/2018 12:52 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.147 release.
> There are 12 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Thu Aug  9 17:23:34 UTC 2018.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.147-rc1.gz
> or in the git tree and branch at:
>   
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.4.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

Re: [PATCH 4.9 00/17] 4.9.119-stable review

[Shuah Khan]

On 08/07/2018 12:51 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.119 release.
> There are 17 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Thu Aug  9 17:23:30 UTC 2018.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.119-rc1.gz
> or in the git tree and branch at:
>   
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.9.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

Re: [PATCH 4.14 00/21] 4.14.62-stable review

[Shuah Khan]

On 08/07/2018 12:51 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.62 release.
> There are 21 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Thu Aug  9 17:23:22 UTC 2018.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.62-rc1.gz
> or in the git tree and branch at:
>   
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.14.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

Re: [PATCH 4.17 00/18] 4.17.14-stable review

[Shuah Khan]

On 08/07/2018 12:51 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.17.14 release.
> There are 18 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Thu Aug  9 17:23:05 UTC 2018.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.17.14-rc1.gz
> or in the git tree and branch at:
>   
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.17.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

Re: [PATCH 3.18 00/85] 3.18.118-stable review

[Shuah Khan]

On 08/07/2018 12:51 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.18.118 release.
> There are 85 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Thu Aug  9 17:23:43 UTC 2018.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   
> https://www.kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.18.118-rc1.gz
> or in the git tree and branch at:
>   
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-3.18.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

Re: [PATCH v2 02/18] clk: intel: Add clock driver for Intel MIPS SoCs

[yixin zhu]

On 8/6/2018 11:19 PM, Rob Herring wrote:

On Thu, Aug 2, 2018 at 9:03 PM Songjun Wu  wrote:

From: Yixin Zhu 

This driver provides PLL clock registration as well as various clock
branches, e.g. MUX clock, gate clock, divider clock and so on.

PLLs that provide clock to DDR, CPU and peripherals are shown below:

  +-+
 |--->| LCPLL3 0|--PCIe clk-->
XO   |+-+
+---|
 |+-+
 ||3|--PAE clk-->
 |--->| PLL0B  2|--GSWIP clk-->
 ||1|--DDR clk-->DDR PHY clk-->
 ||0|--CPU1 clk--+   +-+
 |+-+|--->0|
 |   | MUX |--CPU clk-->
 |+-+|--->1|
 ||0|--CPU0 clk--+   +-+
 |--->| PLLOA  1|--SSX4 clk-->
  |2|--NGI clk-->
  |3|--CBM clk-->
  +-+

Signed-off-by: Yixin Zhu 
Signed-off-by: Songjun Wu 
---

Changes in v2:
- Rewrite clock driver, add platform clock description details in
   clock driver.

  drivers/clk/Kconfig  |   1 +
  drivers/clk/Makefile |   3 +
  drivers/clk/intel/Kconfig|  20 ++
  drivers/clk/intel/Makefile   |   7 +
  drivers/clk/intel/clk-cgu-pll.c  | 166 ++
  drivers/clk/intel/clk-cgu-pll.h  |  34 ++
  drivers/clk/intel/clk-cgu.c  | 470 +++
  drivers/clk/intel/clk-cgu.h  | 259 +++
  drivers/clk/intel/clk-grx500.c   | 168 ++
  include/dt-bindings/clock/intel,grx500-clk.h |  69 

This belongs with the clk binding patch.

Rob

Thanks for review.
Will move it to clock binding patch.

Re: [PATCH v7 1/2] dt-bindings: cpufreq: Introduce QCOM CPUFREQ Firmware bindings

[Taniya Das]

On 8/8/2018 12:54 AM, skan...@codeaurora.org wrote:

On 2018-08-07 04:12, Sudeep Holla wrote:

On Mon, Aug 06, 2018 at 01:54:24PM -0700, skan...@codeaurora.org wrote:

On 2018-08-03 16:46, Stephen Boyd wrote:
>Quoting Taniya Das (2018-07-24 03:42:49)
>>diff --git
>>a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt
>>b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt
>>new file mode 100644
>>index 000..22d4355
>>--- /dev/null
>>+++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt
>>@@ -0,0 +1,172 @@
>[...]
>>+
>>+   CPU7: cpu@700 {
>>+   device_type = "cpu";
>>+   compatible = "qcom,kryo385";
>>+   reg = <0x0 0x700>;
>>+   enable-method = "psci";
>>+   next-level-cache = <&L2_700>;
>>+   qcom,freq-domain = <&freq_domain_table1>;
>>+   L2_700: l2-cache {
>>+   compatible = "cache";
>>+   next-level-cache = <&L3_0>;
>>+   };
>>+   };
>>+   };
>>+
>>+   qcom,cpufreq-hw {
>>+   compatible = "qcom,cpufreq-hw";
>>+
>>+   clocks = <&rpmhcc RPMH_CXO_CLK>;
>>+   clock-names = "xo";
>>+
>>+   #address-cells = <2>;
>>+   #size-cells = <2>;
>>+   ranges;
>>+   freq_domain_table0: freq_table0 {
>>+   reg = <0 0x17d43000 0 0x1400>;
>>+   };
>>+
>>+   freq_domain_table1: freq_table1 {
>>+   reg = <0 0x17d45800 0 0x1400>;
>>+   };
>
>Sorry, this is just not proper DT design. The whole node should have a
>reg property, and it should contain two (or three if we're handling the
>L3 clk domain?) different offsets for the different power clusters. The
>problem seems to still be that we don't have a way to map the CPUs to
>the clk domains they're in provided by this hardware block. Making
>subnodes is not the solution.

The problem is mapping clock domains to logical CPUs that CPUfreq 
uses. The

physical CPU to logical CPU mapping can be changed by the kernel (even
through DT if I'm not mistaken). So we need to have a way to tell in DT
which physical CPUs are connected to which CPU freq clock domain.



How about passing CPU freq clock domain id as along with phandle in
qcom,freq-domain ?


Now sure what you mean here. There's no such this as CPUfreq clock 
domain id. It has policies that are made up of logical CPU numbers. 
Logical CPU is not something that you can fix in DT.


-Saravana


Sudeep,

Earlier the design was the freq_domain would take the CPU phandles

freq_domain:
  cpus = <&cpu0 &cpu1>;

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

--

Re: [PATCH 2/2] spi: sprd: Add SPI driver for Spreadtrum SC9860

[Baolin Wang]

Hi Mark,

On 7 August 2018 at 22:24, Mark Brown  wrote:
> On Tue, Aug 07, 2018 at 06:43:38PM +0800, Baolin Wang wrote:
>> From: Lanqing Liu 
>>
>> This patch adds the SPI controller driver for Spreadtrum SC9860 platform.
>
> This all looks pretty clean, a few comments below but nothing too major:
>
>> +static void sprd_spi_chipselect(struct spi_device *sdev, bool cs)
>> +{
>> + struct spi_controller *sctlr = sdev->controller;
>> + struct sprd_spi *ss = spi_controller_get_devdata(sctlr);
>> + u32 val;
>> + int ret;
>> +
>> + ret = pm_runtime_get_sync(ss->dev);
>> + if (ret < 0) {
>> + dev_err(ss->dev, "failed to resume SPI controller\n");
>> + return;
>> + }
>
> Something else further up the stack should probably have runtime PM
> enabled already - we should only be changing chip select as part of a
> bigger operation.  If you use the core auto_runtime_pm feature this will
> definitely happen.

Indeed, will use auto_runtime_pm.

>
>> + bits_per_word = bits_per_word > 16 ? round_up(bits_per_word, 16) :
>> + round_up(bits_per_word, 8);
>
> Please

Sorry I did not get your points here, could you elaborate on?

>
>> + switch (bits_per_word) {
>> + case 8:
>> + case 16:
>> + case 32:
>
> It'd be nice to have a default case, the core should check for you but
> it's nice to have defensive programming here.

Sure.

>
>> +static int sprd_spi_transfer_one(struct spi_controller *sctlr,
>> +  struct spi_device *sdev,
>> +  struct spi_transfer *t)
>> +{
>> + struct sprd_spi *ss = spi_controller_get_devdata(sctlr);
>> + int ret;
>> +
>> + ret = pm_runtime_get_sync(ss->dev);
>> + if (ret < 0) {
>> + dev_err(ss->dev, "failed to resume SPI controller\n");
>> + goto rpm_err;
>> + }
>
> Same thing with runtime PM here - the core can do this for you.

Yes.

>
>> +static int sprd_spi_setup(struct spi_device *spi_dev)
>> +{
>> + struct spi_controller *sctlr = spi_dev->controller;
>> + struct sprd_spi *ss = spi_controller_get_devdata(sctlr);
>> + int ret;
>> +
>> + ret = pm_runtime_get_sync(ss->dev);
>> + if (ret < 0) {
>> + dev_err(ss->dev, "failed to resume SPI controller\n");
>> + return ret;
>> + }
>> +
>> + ss->hw_mode = spi_dev->mode;
>> + sprd_spi_init_hw(ss);
>
> This can be called for one chip select while another is in progress so
> it's not good to actually configure the hardware here unless the
> configuration is in a chip select specific set of registers.  Instead
> you should defer to when the transfer is being set up.

You are right, will move these into transfer setup.

>
>> +static int sprd_spi_clk_init(struct platform_device *pdev, struct sprd_spi 
>> *ss)
>> +{
>> + struct clk *clk_spi, *clk_parent;
>> +
>> + clk_spi = devm_clk_get(&pdev->dev, "spi");
>> + if (IS_ERR(clk_spi)) {
>> + dev_warn(&pdev->dev, "can't get the spi clock\n");
>> + clk_spi = NULL;
>> + }
>
> I suspect some of these clocks are essential and you should probably
> return an error if you can't get them (especially if probe deferral
> becomes a factor).

The 'spi' and 'source' clock can be optional, and the SPI can work at
default source clock without setting 'spi' and 'source' clock. This is
used on our FPGA board which has not set the spi source clock, but
still make the SPI can work. So here we just give a warning.

>> + if (!clk_set_parent(clk_spi, clk_parent))
>> + ss->src_clk = clk_get_rate(clk_spi);
>> + else
>> + ss->src_clk = SPRD_SPI_DEFAULT_SOURCE;
>
> Are upstream DTs going to be missing the clock setup needed here?

Right. DTs can not set 'spi' and 'source' clock to make SPI work at
default clock. Thanks for your useful comments.

-- 
Baolin Wang
Best Regards

Re: [PATCH v12 3/3] tracing: Centralize preemptirq tracepoints and unify their usage

[Steven Rostedt]

On Tue, 7 Aug 2018 19:13:32 -0700
Joel Fernandes  wrote:

> On Tue, Aug 7, 2018 at 6:55 PM, Steven Rostedt  wrote:
> > On Tue, 7 Aug 2018 18:17:42 -0700
> > Joel Fernandes  wrote:
> >  
> >> From 6986af946ceb04fc9ddc6d5b45fc559b6807e465 Mon Sep 17 00:00:00 2001
> >> From: "Joel Fernandes (Google)" 
> >> Date: Sun, 5 Aug 2018 20:17:41 -0700
> >> Subject: [PATCH] tracepoint: Run tracepoints even after CPU is offline
> >>
> >> Commit f37755490fe9 ("tracepoints: Do not trace when cpu is offline")
> >> causes a problem for lockdep using tracepoint code. Once a CPU is
> >> offline, tracepoints donot get called, however this causes a big problem
> >> for lockdep probes that need to run so that IRQ annotations are marked
> >> correctly.
> >>
> >> A race is possible where while the CPU is going offline, an interrupt
> >> can come in and then a lockdep assert causes an annotation warning:
> >>
> >> [  106.551354] IRQs not enabled as expected
> >> [  106.551785] WARNING: CPU: 1 PID: 0 at kernel/time/tick-sched.c:982
> >>  tick_nohz_idle_enter+0x99/0xb0
> >> [  106.552964] Modules linked in:
> >> [  106.553299] CPU: 1 PID: 0 Comm: swapper/1 Tainted: GW
> >>
> >> We need tracepoints to run as late as possible. This commit fixes the
> >> issue by removing the cpu_online check in tracepoint code that was
> >> introduced in the mentioned commit, however we now switch to using SRCU
> >> for all tracepoints and special handle calling tracepoints from NMI so
> >> that we don't run into issues that result from using sched-RCU when the
> >> CPUs are marked to be offline.
> >>
> >> Fixes: c3bc8fd637a9 ("tracing: Centralize preemptirq tracepoints and
> >>   unify their usage")
> >> Reported-by: Masami Hiramatsu 
> >> Signed-off-by: Joel Fernandes (Google)   
> >
> >
> > The above change log doesn't look like it matches the NMI patch.
> >
> > Can you resend with just the NMI changes? I already handled the cpu
> > offline ones.  
> 
> Ok, sent with "cpu offline" changes dropped, here it is:
> https://lore.kernel.org/patchwork/patch/972657/
> 
> If you could add your Reported-by to it, that would be great as well.
> 
> >
> > But I may still have concerns with this patch.  
> 
> Ok let me know what you think.
> 

Not sure you saw this part of my reply:

> @@ -171,8 +174,7 @@ extern void syscall_unregfunc(void);
>   } while ((++it_func_ptr)->func);\
>   }   \
>   \
> - if (rcuidle)\
> - srcu_read_unlock_notrace(&tracepoint_srcu, idx);\
> + srcu_read_unlock_notrace(ss, idx);  \  

Hmm, why do we have the two different srcu handles?

Thinking about this, if this can be called by the "thunk" code, then
there might be an issue. I think the "thunk" code can be called before
in_nmi() is set, so we don't know if we are in an NMI or not. I need to
look at that code to make sure. If in_nmi() still works, then we should
use the _nmi srcu handle (if that's required).

But I'm not sure using SRCU for all tracepoints is needed at this
moment. I'll have to look deeper into this tomorrow. But it's getting
close to the merge window, and this needs to be settled quick. Another
"partial revert" may be needed until this gets settled.


-- Steve

Re: [PATCH 1/2] dt-bindings: spi: Add Spreadtrum SPI controller documentation

[Baolin Wang]

Hi Mark,

On 7 August 2018 at 21:41, Mark Brown  wrote:
> On Tue, Aug 07, 2018 at 06:43:37PM +0800, Baolin Wang wrote:
>
>> +Optional properties:
>> +- sprd,spi-interval: Specify the intervals of two SPI frames, which can be
>> + converted to the delay clock cycles = interval number * 4 + 10.
>
> What's a frame here, and does it overlap with any of the existing delay
> configuration we have?  In general it's better for this stuff to be
> configured at runtime by the device rather than at DT time by the
> controller since that way if the device needs the delays we always do
> them if we can and if they are only needed some of the time (eg, for
> only one device on the bus or for only some operations) then we don't
> take the performance hit when we don't need to.

Sorry for confusing. Let me try to explain it explicitly.
We can set the word size (bits_per_word) for each transmission, for
our SPI controller,  after every word size transmission, we need one
interval time (hardware automatically) to make sure the slave has
enough time to receive the whole data.

Yes, I agree we should configure it at runtime by the device, but we
did not find one member to use in 'struct spi_transfer', we just find
one similar 'delay_usecs' member in 'struct spi_transfer' but not
same. We can use  'delay_usecs' to set our hardware interval value,
but we should clean it when transfer is done, since we do not need to
delay after the transfer in spi_transfer_one _message(). Or can we add
one new member maybe named 'word_interval' to indicate the interval
time between word size transmission?

What do you prefer or other better solution? Thanks.

-- 
Baolin Wang
Best Regards

Re: [PATCH v2] kbuild: make samples really depend on headers_install

[Masahiro Yamada]

2018-08-08 11:14 GMT+09:00 Masahiro Yamada :
> Kernel headers must be installed into $(objtree)/usr/include to avoid
> the build failure of samples.
>
> Commit ddea05fa148b ("kbuild: make samples depend on headers_install")
> addressed this, but "samples/" is only used for the single target build.
>
> "make samples/" properly installs kernel headers, but it does not work
> for general building because a phony target "sample" (no trailing slash)
> is used.
>
> Reported-by: David Howells 
> Signed-off-by: Masahiro Yamada 
> ---


David,
Could you check this patch, please?

Will you apply this to your tree
to fix the vfs sample issue?

Please let me know your thought.

Thanks.





> Changes in v2:
>   - Correct commit log (backslash -> slash)
>   - Fix a typo
>
>  Makefile | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/Makefile b/Makefile
> index 7a3c454..1e47d13 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1009,9 +1009,10 @@ ifdef CONFIG_GDB_SCRIPTS
>  endif
> +$(call if_changed,link-vmlinux)
>
> -# Build samples along the rest of the kernel
> +# Build samples along the rest of the kernel. This needs headers_install.
>  ifdef CONFIG_SAMPLES
>  vmlinux-dirs += samples
> +samples: headers_install
>  endif
>
>  # The actual objects are generated when descending,
> --
> 2.7.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Best Regards
Masahiro Yamada

Re: simplified RISC-V interrupt and clocksource handling v3

[Palmer Dabbelt]

On Sat, 04 Aug 2018 01:23:11 PDT (-0700), Christoph Hellwig wrote:

This series tries adds support for interrupt handling and timers
for the RISC-V architecture.

The basic per-hart interrupt handling implemented by the scause
and sie CSRs is extremely simple and implemented directly in
arch/riscv/kernel/irq.c.  In addition there is a irqchip driver
for the PLIC external interrupt controller, which is called through
the set_handle_irq API, and a clocksource driver that gets its
timer interrupt directly from the low-level interrupt handling.

Compared to previous iterations this version does not try to use an
irqchip driver for the low-level interrupt handling.  This saves
a couple indirect calls and an additional read of the scause CSR
in the hot path, makes the code much simpler and last but not least
avoid the dependency on a device tree for a mandatory architectural
feature.

A git tree is available here (contains a few more patches before
the ones in this series)

git://git.infradead.org/users/hch/riscv.git riscv-irq-simple.3

Gitweb:


http://git.infradead.org/users/hch/riscv.git/shortlog/refs/heads/riscv-irq-simple.3

Changes since v2:
 - actually use SEIE instead of STIE in the plic driver
 - rename the default compat string for the plic to sifive,u5-plic
 - various spelling fixes
 - drop a superflous derefence in the plic driver that is taken care of
   by the following loop
 - drop the patch to document the enable method - not relevant for the
   rest of the series
 - drop the patches for the per-hart timebase frequency - not relevant
   for the rest of the series.
 - use riscv_of_processor_hart in the timer driver

Changes since v1:
 - rename the plic driver to irq-sifive-plic
 - switch to a default compatible of sifive,plic0 (still supporting the
   riscv,plic0 name for compatibility)
 - add a reference for the SiFive PLIC register layout
 - fix plic_toggle addressing for large numbers of hwirqs
 - remove the call to ack_bad_irq
 - use a raw spinlock for plic_toggle_lock
 - use the irq_desc cpumask in the plic enable/disable methods
 - add back OF contexid parsing in the plic driver
 - don't allow COMPILE_TEST builds of the clocksource driver, as it
   depends on 
 - default the clocksource driver to y
 - clean up naming in the clocksource driver
 - remove the MINDELTA and MAXDELTA #defines
 - various DT binding fixes


Thanks!  Modulo the one device tree issue I replied to in patch 3 this looks 
great!  We've already gotten the ACKs to take this through the RISC-V tree, so 
I'm going to put this along with the queued RISC-V patches on our for-next 
branch, including my proposed change for "sifive,plic-1.0" but leaving the 
device tree bindings with #{address,size}-cells=1.


We can always change this, but I'd like to get this out so people can start 
playing with it earlier rather than later.


Thanks to everyone for all the help!

Re: [PATCH 03/11] dt-bindings: interrupt-controller: RISC-V PLIC documentation

[Palmer Dabbelt]

On Mon, 06 Aug 2018 13:59:48 PDT (-0700), robh...@kernel.org wrote:

On Thu, Aug 2, 2018 at 4:08 PM Atish Patra  wrote:


On 8/2/18 4:50 AM, Christoph Hellwig wrote:
> From: Palmer Dabbelt 
>
> This patch adds documentation for the platform-level interrupt
> controller (PLIC) found in all RISC-V systems.  This interrupt
> controller routes interrupts from all the devices in the system to each
> hart-local interrupt controller.
>
> Note: the DTS bindings for the PLIC aren't set in stone yet, as we might
> want to change how we're specifying holes in the hart list.
>
> Signed-off-by: Palmer Dabbelt 
> [hch: various fixes and updates]
> Signed-off-by: Christoph Hellwig 
> ---
>   .../interrupt-controller/sifive,plic0.txt | 57 +++
>   1 file changed, 57 insertions(+)
>   create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/sifive,plic0.txt
>
> diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/sifive,plic0.txt 
b/Documentation/devicetree/bindings/interrupt-controller/sifive,plic0.txt
> new file mode 100644
> index ..c756cd208a93
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/interrupt-controller/sifive,plic0.txt
> @@ -0,0 +1,57 @@
> +SiFive Platform-Level Interrupt Controller (PLIC)
> +-
> +
> +SiFive SOCs include an implementation of the Platform-Level Interrupt 
Controller
> +(PLIC) high-level specification in the RISC-V Privileged Architecture
> +specification.  The PLIC connects all external interrupts in the system to 
all
> +hart contexts in the system, via the external interrupt source in each hart.
> +
> +A hart context is a privilege mode in a hardware execution thread.  For 
example,
> +in an 4 core system with 2-way SMT, you have 8 harts and probably at least 
two
> +privilege modes per hart; machine mode and supervisor mode.
> +
> +Each interrupt can be enabled on per-context basis. Any context can claim
> +a pending enabled interrupt and then release it once it has been handled.
> +
> +Each interrupt has a configurable priority. Higher priority interrupts are
> +serviced first. Each context can specify a priority threshold. Interrupts
> +with priority below this threshold will not cause the PLIC to raise its
> +interrupt line leading to the context.
> +
> +While the PLIC supports both edge-triggered and level-triggered interrupts,
> +interrupt handlers are oblivious to this distinction and therefore it is not
> +specified in the PLIC device-tree binding.
> +
> +While the RISC-V ISA doesn't specify a memory layout for the PLIC, the
> +"sifive,plic0" device is a concrete implementation of the PLIC that contains 
a
> +specific memory layout, which is documented in chapter 8 of the SiFive U5
> +Coreplex Series Manual .
> +
> +Required properties:
> +- compatible : "sifive,plic0"


I think there was a thread bouncing around somewhere where decided to pick the 
official name of the compatible string to be "sifive,plic-1.0".  The idea here 
is that the PLIC is compatible across all of SiFive's current implementations, 
but there's some limitations in the memory map that will probably cause us to 
spin a version 2 at some point so we want major version number.  The minor 
number is just in case we find some errata in the PLIC.



> +- #address-cells : should be <0>
> +- #interrupt-cells : should be <1>
> +- interrupt-controller : Identifies the node as an interrupt controller
> +- reg : Should contain 1 register range (address and length)

The one in the real device tree has two entries.
reg = <0x 0x0c00 0x 0x0400>;

Is it intentional or just incorrect entry left over from earlier days?



> + reg = <0xc00 0x400>;


Looks to me like one has #size-cells and #address-cells set to 2 and
the example is using 1.


Yes.  For some background on how this works: we have a hardware generator that 
has a tree-of-busses abstraction, and each device is attached to some point on 
that tree.  When a device gets attached to the bus, we also generate a device 
tree entry.  For whatever system I generated the example PLIC device tree entry 
from, it must have been attached to a bus with addresses of 32 bits or less, 
which resulted in #address-cells and #size-cells being 1.


Christoph has a HiFive Unleashed, which has a fu540-c000 on it, which is 
probably not what I generated as an example -- the fu540-c000 is a complicated 
configuration, when I mess around with the hardware I tend to use simple ones 
as I'm not really a hardware guy.  I suppose the bus that the PLIC is hanging 
off on the fu540-c000 has addresses wider than 32 bits.  This makes sense, as 
the machine has 8GiB of memory and the PLIC is on a bus that's closer to the 
core than the DRAM is, so it'd need at least enough address bits to fit 8GiB.


Is the inconsistency a problem?  I generally write device tree handling code to 
just r

[PATCH v2] kbuild: make samples really depend on headers_install

[Masahiro Yamada]

Kernel headers must be installed into $(objtree)/usr/include to avoid
the build failure of samples.

Commit ddea05fa148b ("kbuild: make samples depend on headers_install")
addressed this, but "samples/" is only used for the single target build.

"make samples/" properly installs kernel headers, but it does not work
for general building because a phony target "sample" (no trailing slash)
is used.

Reported-by: David Howells 
Signed-off-by: Masahiro Yamada 
---

Changes in v2:
  - Correct commit log (backslash -> slash)
  - Fix a typo

 Makefile | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 7a3c454..1e47d13 100644
--- a/Makefile
+++ b/Makefile
@@ -1009,9 +1009,10 @@ ifdef CONFIG_GDB_SCRIPTS
 endif
+$(call if_changed,link-vmlinux)
 
-# Build samples along the rest of the kernel
+# Build samples along the rest of the kernel. This needs headers_install.
 ifdef CONFIG_SAMPLES
 vmlinux-dirs += samples
+samples: headers_install
 endif
 
 # The actual objects are generated when descending,
-- 
2.7.4

[PATCH] f2fs: fix use-after-free of dicard command entry

[Chao Yu]

As Dan Carpenter reported:

The patch 20ee4382322c: "f2fs: issue small discard by LBA order" from
Jul 8, 2018, leads to the following Smatch warning:

fs/f2fs/segment.c:1277 __issue_discard_cmd_orderly()
warn: 'dc' was already freed.

See also:
fs/f2fs/segment.c:2550 __issue_discard_cmd_range() warn: 'dc' was already freed.

In order to fix this issue, let's get error from __submit_discard_cmd(),
and release current discard command after we referenced next one.

Reported-by: Dan Carpenter 
Signed-off-by: Chao Yu 
---
 fs/f2fs/segment.c | 79 +++
 1 file changed, 45 insertions(+), 34 deletions(-)

diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index be1bf38400ca..8826ea683804 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -998,7 +998,7 @@ static void __update_discard_tree_range(struct f2fs_sb_info 
*sbi,
struct block_device *bdev, block_t lstart,
block_t start, block_t len);
 /* this function is copied from blkdev_issue_discard from block/blk-lib.c */
-static void __submit_discard_cmd(struct f2fs_sb_info *sbi,
+static int __submit_discard_cmd(struct f2fs_sb_info *sbi,
struct discard_policy *dpolicy,
struct discard_cmd *dc,
unsigned int *issued)
@@ -1015,10 +1015,10 @@ static void __submit_discard_cmd(struct f2fs_sb_info 
*sbi,
int err = 0;
 
if (dc->state != D_PREP)
-   return;
+   return 0;
 
if (is_sbi_flag_set(sbi, SBI_NEED_FSCK))
-   return;
+   return 0;
 
trace_f2fs_issue_discard(bdev, dc->start, dc->len);
 
@@ -1057,43 +1057,44 @@ static void __submit_discard_cmd(struct f2fs_sb_info 
*sbi,
SECTOR_FROM_BLOCK(len),
GFP_NOFS, 0, &bio);
 submit:
-   if (!err && bio) {
-   /*
-* should keep before submission to avoid D_DONE
-* right away
-*/
+   if (err) {
spin_lock_irqsave(&dc->lock, flags);
-   if (last)
+   if (dc->state == D_PARTIAL)
dc->state = D_SUBMIT;
-   else
-   dc->state = D_PARTIAL;
-   dc->bio_ref++;
spin_unlock_irqrestore(&dc->lock, flags);
 
-   atomic_inc(&dcc->issing_discard);
-   dc->issuing++;
-   list_move_tail(&dc->list, wait_list);
+   break;
+   }
 
-   /* sanity check on discard range */
-   __check_sit_bitmap(sbi, start, start + len);
+   f2fs_bug_on(sbi, !bio);
 
-   bio->bi_private = dc;
-   bio->bi_end_io = f2fs_submit_discard_endio;
-   bio->bi_opf |= flag;
-   submit_bio(bio);
+   /*
+* should keep before submission to avoid D_DONE
+* right away
+*/
+   spin_lock_irqsave(&dc->lock, flags);
+   if (last)
+   dc->state = D_SUBMIT;
+   else
+   dc->state = D_PARTIAL;
+   dc->bio_ref++;
+   spin_unlock_irqrestore(&dc->lock, flags);
 
-   atomic_inc(&dcc->issued_discard);
+   atomic_inc(&dcc->issing_discard);
+   dc->issuing++;
+   list_move_tail(&dc->list, wait_list);
 
-   f2fs_update_iostat(sbi, FS_DISCARD, 1);
-   } else {
-   spin_lock_irqsave(&dc->lock, flags);
-   if (dc->state == D_PARTIAL)
-   dc->state = D_SUBMIT;
-   spin_unlock_irqrestore(&dc->lock, flags);
+   /* sanity check on discard range */
+   __check_sit_bitmap(sbi, start, start + len);
 
-   __remove_discard_cmd(sbi, dc);
-   err = -EIO;
-   }
+   bio->bi_private = dc;
+   bio->bi_end_io = f2fs_submit_discard_endio;
+   bio->bi_opf |= flag;
+   submit_bio(bio);
+
+   atomic_inc(&dcc->issued_discard);
+
+   f2fs_update_iostat(sbi, FS_DISCARD, 1);
 
lstart += len;
start += len;
@@ -1101,8 +1102,9 @@ static void __submit_discard_cmd(struct f2fs_sb_info *sbi,
len = total_len;
}
 
-   if (len)
+   if (!err && len)
__update_discard_tree_range(sbi, bdev, lstart, start, len);
+   return err;
 }
 
 static struc

Re: [PATCH v12 3/3] tracing: Centralize preemptirq tracepoints and unify their usage

[Joel Fernandes]

On Tue, Aug 7, 2018 at 6:55 PM, Steven Rostedt  wrote:
> On Tue, 7 Aug 2018 18:17:42 -0700
> Joel Fernandes  wrote:
>
>> From 6986af946ceb04fc9ddc6d5b45fc559b6807e465 Mon Sep 17 00:00:00 2001
>> From: "Joel Fernandes (Google)" 
>> Date: Sun, 5 Aug 2018 20:17:41 -0700
>> Subject: [PATCH] tracepoint: Run tracepoints even after CPU is offline
>>
>> Commit f37755490fe9 ("tracepoints: Do not trace when cpu is offline")
>> causes a problem for lockdep using tracepoint code. Once a CPU is
>> offline, tracepoints donot get called, however this causes a big problem
>> for lockdep probes that need to run so that IRQ annotations are marked
>> correctly.
>>
>> A race is possible where while the CPU is going offline, an interrupt
>> can come in and then a lockdep assert causes an annotation warning:
>>
>> [  106.551354] IRQs not enabled as expected
>> [  106.551785] WARNING: CPU: 1 PID: 0 at kernel/time/tick-sched.c:982
>>  tick_nohz_idle_enter+0x99/0xb0
>> [  106.552964] Modules linked in:
>> [  106.553299] CPU: 1 PID: 0 Comm: swapper/1 Tainted: GW
>>
>> We need tracepoints to run as late as possible. This commit fixes the
>> issue by removing the cpu_online check in tracepoint code that was
>> introduced in the mentioned commit, however we now switch to using SRCU
>> for all tracepoints and special handle calling tracepoints from NMI so
>> that we don't run into issues that result from using sched-RCU when the
>> CPUs are marked to be offline.
>>
>> Fixes: c3bc8fd637a9 ("tracing: Centralize preemptirq tracepoints and
>>   unify their usage")
>> Reported-by: Masami Hiramatsu 
>> Signed-off-by: Joel Fernandes (Google) 
>
>
> The above change log doesn't look like it matches the NMI patch.
>
> Can you resend with just the NMI changes? I already handled the cpu
> offline ones.

Ok, sent with "cpu offline" changes dropped, here it is:
https://lore.kernel.org/patchwork/patch/972657/

If you could add your Reported-by to it, that would be great as well.

>
> But I may still have concerns with this patch.

Ok let me know what you think.

Thanks!

 - Joel

[PATCH RFC] tracepoint: Use SRCU for all tracepoint invocations

[Joel Fernandes (Google)]

Steven reported that rcuidle && in_nmi() condition can occur which
creates a problem for SRCU usage, since we can't use the SRCU node from
both NMI context and other contexts (NMI can come in while the SRCU read
lock is in the process of being held).

This patch switches to using a separate SRCU node for tracepoints called
from in_nmi(). This is needed to also make tracepoints work while CPU is
offline.

Fixes: c3bc8fd637a9 ("tracing: Centralize preemptirq tracepoints and
  unify their usage")
Reported-by: Masami Hiramatsu 
Signed-off-by: Joel Fernandes (Google) 
---
Dropped the "CPU offline" changes, and only keeping the SRCU changes.

 include/linux/tracepoint.h | 19 ---
 kernel/tracepoint.c| 10 ++
 2 files changed, 14 insertions(+), 15 deletions(-)

diff --git a/include/linux/tracepoint.h b/include/linux/tracepoint.h
index d9a084c72541..1ceee17a38dc 100644
--- a/include/linux/tracepoint.h
+++ b/include/linux/tracepoint.h
@@ -35,6 +35,7 @@ struct trace_eval_map {
 #define TRACEPOINT_DEFAULT_PRIO10
 
 extern struct srcu_struct tracepoint_srcu;
+extern struct srcu_struct tracepoint_srcu_nmi;
 
 extern int
 tracepoint_probe_register(struct tracepoint *tp, void *probe, void *data);
@@ -144,13 +145,11 @@ extern void syscall_unregfunc(void);
void *it_func;  \
void *__data;   \
int __maybe_unused idx = 0; \
+   struct srcu_struct *ss; \
\
if (!(cond))\
return; \
\
-   /* srcu can't be used from NMI */   \
-   WARN_ON_ONCE(rcuidle && in_nmi());  \
-   \
/* keep srcu and sched-rcu usage consistent */  \
preempt_disable_notrace();  \
\
@@ -159,7 +158,11 @@ extern void syscall_unregfunc(void);
 * doesn't work from the idle path. \
 */ \
if (rcuidle)\
-   idx = srcu_read_lock_notrace(&tracepoint_srcu); \
+   ss = &tracepoint_srcu_nmi;  \
+   else\
+   ss = &tracepoint_srcu;  \
+   \
+   idx = srcu_read_lock_notrace(ss);   \
\
it_func_ptr = rcu_dereference_raw((tp)->funcs); \
\
@@ -171,8 +174,7 @@ extern void syscall_unregfunc(void);
} while ((++it_func_ptr)->func);\
}   \
\
-   if (rcuidle)\
-   srcu_read_unlock_notrace(&tracepoint_srcu, idx);\
+   srcu_read_unlock_notrace(ss, idx);  \
\
preempt_enable_notrace();   \
} while (0)
@@ -212,11 +214,6 @@ extern void syscall_unregfunc(void);
TP_PROTO(data_proto),   \
TP_ARGS(data_args), \
TP_CONDITION(cond), 0); \
-   if (IS_ENABLED(CONFIG_LOCKDEP) && (cond)) { \
-   rcu_read_lock_sched_notrace();  \
-   rcu_dereference_sched(__tracepoint_##name.funcs);\
-   rcu_read_unlock_sched_notrace();\
-   }   \
}   \
__DECLARE_TRACE_RCU(name, PARAMS(proto), PARAMS(args),  \
PARAMS(cond), PARAMS(data_proto), PARAMS(data_args))\
diff --git a/kernel/tracepoint.c b/kernel/tracepoint.c
index 955148d91b74..769d74b2f90e 100644
--- a/kernel/tracepoint.c
+++ b/kernel/tracepoint.c
@@ -32,7 +

[PATCH] kbuild: make samples depend on headers_install really

[Masahiro Yamada]

Kernel headers must be installed into $(objtree)/usr/include to avoid
the build failure of samples.

Commit ddea05fa148b ("kbuild: make samples depend on headers_install")
addressed this, but "samples/" is only used for the single target build.

"make samples/" correctly installs kernel headers, but it does not
work for general building because a phony target "sample" (no tailing
backslash) is used.

Reported-by: David Howells 
Signed-off-by: Masahiro Yamada 
---

 Makefile | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 7a3c454..1e47d13 100644
--- a/Makefile
+++ b/Makefile
@@ -1009,9 +1009,10 @@ ifdef CONFIG_GDB_SCRIPTS
 endif
+$(call if_changed,link-vmlinux)
 
-# Build samples along the rest of the kernel
+# Build samples along the rest of the kernel. This needs headers_install.
 ifdef CONFIG_SAMPLES
 vmlinux-dirs += samples
+samples: headers_install
 endif
 
 # The actual objects are generated when descending,
-- 
2.7.4

Re: [PATCH v12 3/3] tracing: Centralize preemptirq tracepoints and unify their usage

[Steven Rostedt]

On Tue, 7 Aug 2018 18:17:42 -0700
Joel Fernandes  wrote:

> From 6986af946ceb04fc9ddc6d5b45fc559b6807e465 Mon Sep 17 00:00:00 2001
> From: "Joel Fernandes (Google)" 
> Date: Sun, 5 Aug 2018 20:17:41 -0700
> Subject: [PATCH] tracepoint: Run tracepoints even after CPU is offline
> 
> Commit f37755490fe9 ("tracepoints: Do not trace when cpu is offline")
> causes a problem for lockdep using tracepoint code. Once a CPU is
> offline, tracepoints donot get called, however this causes a big problem
> for lockdep probes that need to run so that IRQ annotations are marked
> correctly.
> 
> A race is possible where while the CPU is going offline, an interrupt
> can come in and then a lockdep assert causes an annotation warning:
> 
> [  106.551354] IRQs not enabled as expected
> [  106.551785] WARNING: CPU: 1 PID: 0 at kernel/time/tick-sched.c:982
>  tick_nohz_idle_enter+0x99/0xb0
> [  106.552964] Modules linked in:
> [  106.553299] CPU: 1 PID: 0 Comm: swapper/1 Tainted: GW
> 
> We need tracepoints to run as late as possible. This commit fixes the
> issue by removing the cpu_online check in tracepoint code that was
> introduced in the mentioned commit, however we now switch to using SRCU
> for all tracepoints and special handle calling tracepoints from NMI so
> that we don't run into issues that result from using sched-RCU when the
> CPUs are marked to be offline.
> 
> Fixes: c3bc8fd637a9 ("tracing: Centralize preemptirq tracepoints and
>   unify their usage")
> Reported-by: Masami Hiramatsu 
> Signed-off-by: Joel Fernandes (Google) 


The above change log doesn't look like it matches the NMI patch.

Can you resend with just the NMI changes? I already handled the cpu
offline ones.

But I may still have concerns with this patch.

---
>  include/linux/tracepoint.h | 27 +++
>  kernel/tracepoint.c| 10 ++
>  2 files changed, 17 insertions(+), 20 deletions(-)
> 
> diff --git a/include/linux/tracepoint.h b/include/linux/tracepoint.h
> index d9a084c72541..5733502bb3ce 100644
> --- a/include/linux/tracepoint.h
> +++ b/include/linux/tracepoint.h
> @@ -35,6 +35,7 @@ struct trace_eval_map {
>  #define TRACEPOINT_DEFAULT_PRIO  10
>  
>  extern struct srcu_struct tracepoint_srcu;
> +extern struct srcu_struct tracepoint_srcu_nmi;
>  
>  extern int
>  tracepoint_probe_register(struct tracepoint *tp, void *probe, void *data);
> @@ -144,13 +145,11 @@ extern void syscall_unregfunc(void);
>   void *it_func;  \
>   void *__data;   \
>   int __maybe_unused idx = 0; \
> + struct srcu_struct *ss; \
>   \
>   if (!(cond))\
>   return; \
>   \
> - /* srcu can't be used from NMI */   \
> - WARN_ON_ONCE(rcuidle && in_nmi());  \
> - \
>   /* keep srcu and sched-rcu usage consistent */  \
>   preempt_disable_notrace();  \
>   \
> @@ -159,7 +158,11 @@ extern void syscall_unregfunc(void);
>* doesn't work from the idle path. \
>*/ \
>   if (rcuidle)\
> - idx = srcu_read_lock_notrace(&tracepoint_srcu); \
> + ss = &tracepoint_srcu_nmi;  \
> + else\
> + ss = &tracepoint_srcu;  \
> + \
> + idx = srcu_read_lock_notrace(ss);   \
>   \
>   it_func_ptr = rcu_dereference_raw((tp)->funcs); \
>   \
> @@ -171,8 +174,7 @@ extern void syscall_unregfunc(void);
>   } while ((++it_func_ptr)->func);\
>   }   \
>   \
> - if (rcuidle)\
> - srcu_read_unlock_notrace(&tracepoint_srcu, idx);\
> + srcu_read_unlock_notrace(ss, idx);  \

[PATCH 2/4] fs/locks: allow a lock request to block other requests.

[NeilBrown]

Currently, a lock can block pending requests, but all pending
requests are equal.  If lots of pending requests are
mutually exclusive, this means they will all be woken up
and all but one will fail.  This can hurt performance.

So we will allow pending requests to block other requests.
Only the first request will be woken, and it will wake the others.

This patch doesn't implement this fully, but prepares the way.

- It acknowledges that a request might be blocking other requests,
  and when the request is converted to a lock, those blocked
  requests are moved across.
- When a request is removed, all blocked requests are woken.
- When deadlock-detection looks for the lock which blocks a
  given request, we follow the chain of ->fl_blocker all
  the way to the top.

Signed-off-by: NeilBrown 
---
 fs/locks.c |   58 --
 1 file changed, 40 insertions(+), 18 deletions(-)

diff --git a/fs/locks.c b/fs/locks.c
index 322491e70e41..b4812da2a374 100644
--- a/fs/locks.c
+++ b/fs/locks.c
@@ -408,9 +408,19 @@ void locks_copy_lock(struct file_lock *new, struct 
file_lock *fl)
fl->fl_ops->fl_copy_lock(new, fl);
}
 }
-
 EXPORT_SYMBOL(locks_copy_lock);
 
+static void locks_move_blocks(struct file_lock *new, struct file_lock *fl)
+{
+   struct file_lock *f;
+
+   spin_lock(&blocked_lock_lock);
+   list_splice_init(&fl->fl_blocked, &new->fl_blocked);
+   list_for_each_entry(f, &fl->fl_blocked, fl_block)
+   f->fl_blocker = new;
+   spin_unlock(&blocked_lock_lock);
+}
+
 static inline int flock_translate_cmd(int cmd) {
if (cmd & LOCK_MAND)
return cmd & (LOCK_MAND | LOCK_RW);
@@ -681,9 +691,25 @@ static void __locks_delete_block(struct file_lock *waiter)
waiter->fl_blocker = NULL;
 }
 
+static void __locks_wake_up_blocks(struct file_lock *blocker)
+{
+   while (!list_empty(&blocker->fl_blocked)) {
+   struct file_lock *waiter;
+
+   waiter = list_first_entry(&blocker->fl_blocked,
+   struct file_lock, fl_block);
+   __locks_delete_block(waiter);
+   if (waiter->fl_lmops && waiter->fl_lmops->lm_notify)
+   waiter->fl_lmops->lm_notify(waiter);
+   else
+   wake_up(&waiter->fl_wait);
+   }
+}
+
 static void locks_delete_block(struct file_lock *waiter)
 {
spin_lock(&blocked_lock_lock);
+   __locks_wake_up_blocks(waiter);
__locks_delete_block(waiter);
spin_unlock(&blocked_lock_lock);
 }
@@ -735,17 +761,7 @@ static void locks_wake_up_blocks(struct file_lock *blocker)
return;
 
spin_lock(&blocked_lock_lock);
-   while (!list_empty(&blocker->fl_blocked)) {
-   struct file_lock *waiter;
-
-   waiter = list_first_entry(&blocker->fl_blocked,
-   struct file_lock, fl_block);
-   __locks_delete_block(waiter);
-   if (waiter->fl_lmops && waiter->fl_lmops->lm_notify)
-   waiter->fl_lmops->lm_notify(waiter);
-   else
-   wake_up(&waiter->fl_wait);
-   }
+   __locks_wake_up_blocks(blocker);
spin_unlock(&blocked_lock_lock);
 }
 
@@ -888,8 +904,11 @@ static struct file_lock *what_owner_is_waiting_for(struct 
file_lock *block_fl)
struct file_lock *fl;
 
hash_for_each_possible(blocked_hash, fl, fl_link, 
posix_owner_key(block_fl)) {
-   if (posix_same_owner(fl, block_fl))
-   return fl->fl_blocker;
+   if (posix_same_owner(fl, block_fl)) {
+   while (fl->fl_blocker)
+   fl = fl->fl_blocker;
+   return fl;
+   }
}
return NULL;
 }
@@ -982,6 +1001,7 @@ static int flock_lock_inode(struct inode *inode, struct 
file_lock *request)
if (request->fl_flags & FL_ACCESS)
goto out;
locks_copy_lock(new_fl, request);
+   locks_move_blocks(new_fl, request);
locks_insert_lock_ctx(new_fl, &ctx->flc_flock);
new_fl = NULL;
error = 0;
@@ -1174,6 +1194,7 @@ static int posix_lock_inode(struct inode *inode, struct 
file_lock *request,
goto out;
}
locks_copy_lock(new_fl, request);
+   locks_move_blocks(new_fl, request);
locks_insert_lock_ctx(new_fl, &fl->fl_list);
fl = new_fl;
new_fl = NULL;
@@ -2582,13 +2603,14 @@ void locks_remove_file(struct file *filp)
 int
 posix_unblock_lock(struct file_lock *waiter)
 {
-   int status = 0;
+   int status = -ENOENT;
 
spin_lock(&blocked_lock_lock);
-   if (waiter->fl_blocker)
+   if (waiter->fl_blocker) {
+   __locks_wake_up_blocks(waiter);
__locks_delete_block(waiter);
-  

[PATCH 3/4] fs/locks: change all *_conflict() functions to return bool.

[NeilBrown]

posix_locks_conflict() and flock_locks_conflict() both return int.
leases_conflict() returns bool.

This inconsistency will cause problems for the next patch if not
fixed.

So change posix_locks_conflict() and flock_locks_conflict() to return
bool.
Also change the locks_conflict() helper.

And convert some
   return (foo);
to
   return foo;

Signed-off-by: NeilBrown 
---
 fs/locks.c |   24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/fs/locks.c b/fs/locks.c
index b4812da2a374..aaa55925c788 100644
--- a/fs/locks.c
+++ b/fs/locks.c
@@ -793,47 +793,47 @@ locks_delete_lock_ctx(struct file_lock *fl, struct 
list_head *dispose)
 /* Determine if lock sys_fl blocks lock caller_fl. Common functionality
  * checks for shared/exclusive status of overlapping locks.
  */
-static int locks_conflict(struct file_lock *caller_fl, struct file_lock 
*sys_fl)
+static bool locks_conflict(struct file_lock *caller_fl, struct file_lock 
*sys_fl)
 {
if (sys_fl->fl_type == F_WRLCK)
-   return 1;
+   return true;
if (caller_fl->fl_type == F_WRLCK)
-   return 1;
-   return 0;
+   return true;
+   return false;
 }
 
 /* Determine if lock sys_fl blocks lock caller_fl. POSIX specific
  * checking before calling the locks_conflict().
  */
-static int posix_locks_conflict(struct file_lock *caller_fl, struct file_lock 
*sys_fl)
+static bool posix_locks_conflict(struct file_lock *caller_fl, struct file_lock 
*sys_fl)
 {
/* POSIX locks owned by the same process do not conflict with
 * each other.
 */
if (posix_same_owner(caller_fl, sys_fl))
-   return (0);
+   return false;
 
/* Check whether they overlap */
if (!locks_overlap(caller_fl, sys_fl))
-   return 0;
+   return false;
 
-   return (locks_conflict(caller_fl, sys_fl));
+   return locks_conflict(caller_fl, sys_fl);
 }
 
 /* Determine if lock sys_fl blocks lock caller_fl. FLOCK specific
  * checking before calling the locks_conflict().
  */
-static int flock_locks_conflict(struct file_lock *caller_fl, struct file_lock 
*sys_fl)
+static bool flock_locks_conflict(struct file_lock *caller_fl, struct file_lock 
*sys_fl)
 {
/* FLOCK locks referring to the same filp do not conflict with
 * each other.
 */
if (caller_fl->fl_file == sys_fl->fl_file)
-   return (0);
+   return false;
if ((caller_fl->fl_type & LOCK_MAND) || (sys_fl->fl_type & LOCK_MAND))
-   return 0;
+   return false;
 
-   return (locks_conflict(caller_fl, sys_fl));
+   return locks_conflict(caller_fl, sys_fl);
 }
 
 void

Re: [RFC v6 PATCH 2/2] mm: mmap: zap pages with read mmap_sem in munmap

[Yang Shi]

On 8/6/18 10:45 PM, Michal Hocko wrote:

On Mon 06-08-18 15:19:06, Yang Shi wrote:


On 8/6/18 1:52 PM, Michal Hocko wrote:

On Mon 06-08-18 13:48:35, Yang Shi wrote:

On 8/6/18 1:41 PM, Michal Hocko wrote:

On Mon 06-08-18 09:46:30, Yang Shi wrote:

On 8/6/18 2:40 AM, Michal Hocko wrote:

On Fri 03-08-18 14:01:58, Yang Shi wrote:

On 8/3/18 2:07 AM, Michal Hocko wrote:

On Fri 27-07-18 02:10:14, Yang Shi wrote:

[...]

If the vma has VM_LOCKED | VM_HUGETLB | VM_PFNMAP or uprobe, they are
considered as special mappings. They will be dealt with before zapping
pages with write mmap_sem held. Basically, just update vm_flags.

Well, I think it would be safer to simply fallback to the current
implementation with these mappings and deal with them on top. This would
make potential issues easier to bisect and partial reverts as well.

Do you mean just call do_munmap()? It sounds ok. Although we may waste some
cycles to repeat what has done, it sounds not too bad since those special
mappings should be not very common.

VM_HUGETLB is quite spread. Especially for DB workloads.

Wait a minute. In this way, it sounds we go back to my old implementation
with special handling for those mappings with write mmap_sem held, right?

Yes, I would really start simple and add further enhacements on top.

If updating vm_flags with read lock is safe in this case, we don't have to
do this. The only reason for this special handling is about vm_flags update.

Yes, maybe you are right that this is safe. I would still argue to have
it in a separate patch for easier review, bisectability etc...

Sorry, I'm a little bit confused. Do you mean I should have the patch
*without* handling the special case (just like to assume it is safe to
update vm_flags with read lock), then have the other patch on top of it,
which simply calls do_munmap() to deal with the special cases?

Just skip those special cases in the initial implementation and handle
each special case in its own patch on top.


Thanks. VM_LOCKED area will not be handled specially since it is easy to 
handle it, just follow what do_munmap does. The special cases will just 
handle VM_HUGETLB, VM_PFNMAP and uprobe mappings.

[PATCH 0/4] locks: avoid thundering-herd wake-ups

[NeilBrown]

If you have a many-core machine, and have many threads all wanting to
briefly lock a give file (udev is known to do this), you can get quite
poor performance.

When one thread releases a lock, it wakes up all other threads that
are waiting (classic thundering-herd) - one will get the lock and the
others go to sleep.
When you have few cores, this is not very noticeable: by the time the
4th or 5th thread gets enough CPU time to try to claim the lock, the
earlier threads have claimed it, done what was needed, and released.
With 50+ cores, the contention can easily be measured.

This patchset creates a tree of pending lock request in which siblings
don't conflict and each lock request does conflict with its parent.
When a lock is released, only requests which don't conflict with each
other a woken.

Testing shows that lock-acquisitions-per-second is now fairly stable even
as number of contending process goes to 1000.  Without this patch,
locks-per-second drops off steeply after a few 10s of processes.

There is a small cost to this extra complexity.
At 20 processes running a particular test on 72 cores, the lock
acquisitions per second drops from 1.8 million to 1.4 million with
this patch.  For 100 processes, this patch still provides 1.4 million
while without this patch there are about 700,000.

NeilBrown

---

NeilBrown (4):
  fs/locks: rename some lists and pointers.
  fs/locks: allow a lock request to block other requests.
  fs/locks: change all *_conflict() functions to return bool.
  fs/locks: create a tree of dependent requests.


 fs/cifs/file.c  |2 -
 fs/locks.c  |  142 +--
 include/linux/fs.h  |5 +
 include/trace/events/filelock.h |   16 ++--
 4 files changed, 103 insertions(+), 62 deletions(-)

--
Signature

[PATCH 4/4] fs/locks: create a tree of dependent requests.

[NeilBrown]

When we find an existing lock which conflicts with a request,
and the request wants to wait, we currently add the request
to a list.  When the lock is removed, the whole list is woken.
This can cause the thundering-herd problem.
To reduce the problem, we make use of the (new) fact that
a pending request can itself have a list of blocked requests.
When we find a conflict, we look through the existing blocked requests.
If any one of them blocks the new request, the new request is attached
below that request.
This way, when the lock is released, only a set of non-conflicting
locks will be woken.  The rest of the herd can stay asleep.

Reported-and-tested-by: Martin Wilck 
Signed-off-by: NeilBrown 
---
 fs/locks.c |   28 ++--
 1 file changed, 22 insertions(+), 6 deletions(-)

diff --git a/fs/locks.c b/fs/locks.c
index aaa55925c788..69a30421218b 100644
--- a/fs/locks.c
+++ b/fs/locks.c
@@ -723,11 +723,24 @@ static void locks_delete_block(struct file_lock *waiter)
  * fl_blocked list itself is protected by the blocked_lock_lock, but by 
ensuring
  * that the flc_lock is also held on insertions we can avoid taking the
  * blocked_lock_lock in some cases when we see that the fl_blocked list is 
empty.
+ *
+ * Rather than just adding to the list, we check for conflicts with any 
existing
+ * waiter, and add to that waiter instead.
+ * Thus wakeups don't happen until needed.
  */
 static void __locks_insert_block(struct file_lock *blocker,
-   struct file_lock *waiter)
+struct file_lock *waiter,
+bool conflict(struct file_lock *,
+  struct file_lock *))
 {
+   struct file_lock *fl;
BUG_ON(!list_empty(&waiter->fl_block));
+new_blocker:
+   list_for_each_entry(fl, &blocker->fl_blocked, fl_block)
+   if (conflict(fl, waiter)) {
+   blocker =  fl;
+   goto new_blocker;
+   }
waiter->fl_blocker = blocker;
list_add_tail(&waiter->fl_block, &blocker->fl_blocked);
if (IS_POSIX(blocker) && !IS_OFDLCK(blocker))
@@ -736,10 +749,12 @@ static void __locks_insert_block(struct file_lock 
*blocker,
 
 /* Must be called with flc_lock held. */
 static void locks_insert_block(struct file_lock *blocker,
-   struct file_lock *waiter)
+  struct file_lock *waiter,
+  bool conflict(struct file_lock *,
+struct file_lock *))
 {
spin_lock(&blocked_lock_lock);
-   __locks_insert_block(blocker, waiter);
+   __locks_insert_block(blocker, waiter, conflict);
spin_unlock(&blocked_lock_lock);
 }
 
@@ -995,7 +1010,7 @@ static int flock_lock_inode(struct inode *inode, struct 
file_lock *request)
if (!(request->fl_flags & FL_SLEEP))
goto out;
error = FILE_LOCK_DEFERRED;
-   locks_insert_block(fl, request);
+   locks_insert_block(fl, request, flock_locks_conflict);
goto out;
}
if (request->fl_flags & FL_ACCESS)
@@ -1069,7 +1084,8 @@ static int posix_lock_inode(struct inode *inode, struct 
file_lock *request,
spin_lock(&blocked_lock_lock);
if (likely(!posix_locks_deadlock(request, fl))) {
error = FILE_LOCK_DEFERRED;
-   __locks_insert_block(fl, request);
+   __locks_insert_block(fl, request,
+posix_locks_conflict);
}
spin_unlock(&blocked_lock_lock);
goto out;
@@ -1542,7 +1558,7 @@ int __break_lease(struct inode *inode, unsigned int mode, 
unsigned int type)
break_time -= jiffies;
if (break_time == 0)
break_time++;
-   locks_insert_block(fl, new_fl);
+   locks_insert_block(fl, new_fl, leases_conflict);
trace_break_lease_block(inode, new_fl);
spin_unlock(&ctx->flc_lock);
percpu_up_read_preempt_enable(&file_rwsem);

[PATCH 1/4] fs/locks: rename some lists and pointers.

[NeilBrown]

struct file lock contains an 'fl_next' pointer which
is used to point to the lock that this request is blocked
waiting for.  So rename it to fl_blocker.

The fl_blocked list_head in an active lock is the head of a list of
blocked requests.  In a request it is a node in that list.
These are two distinct uses, so replace with two list_heads
with different names.
fl_blocked is the head of a list of blocked requests
fl_block is a node on that list.

This separation will be used in the next patch.

Note that a tracepoint is changed to report fl_blocker instead
of fl_next.  Might this be an ABI breakage?

Signed-off-by: NeilBrown 
---
 fs/cifs/file.c  |2 +-
 fs/locks.c  |   40 ---
 include/linux/fs.h  |5 +++--
 include/trace/events/filelock.h |   16 
 4 files changed, 33 insertions(+), 30 deletions(-)

diff --git a/fs/cifs/file.c b/fs/cifs/file.c
index 8d41ca7bfcf1..066ed2e4ba96 100644
--- a/fs/cifs/file.c
+++ b/fs/cifs/file.c
@@ -1092,7 +1092,7 @@ cifs_posix_lock_set(struct file *file, struct file_lock 
*flock)
rc = posix_lock_file(file, flock, NULL);
up_write(&cinode->lock_sem);
if (rc == FILE_LOCK_DEFERRED) {
-   rc = wait_event_interruptible(flock->fl_wait, !flock->fl_next);
+   rc = wait_event_interruptible(flock->fl_wait, 
!flock->fl_blocker);
if (!rc)
goto try_again;
posix_unblock_lock(flock);
diff --git a/fs/locks.c b/fs/locks.c
index db7b6917d9c5..322491e70e41 100644
--- a/fs/locks.c
+++ b/fs/locks.c
@@ -194,7 +194,7 @@ static DEFINE_HASHTABLE(blocked_hash, BLOCKED_HASH_BITS);
  * This lock protects the blocked_hash. Generally, if you're accessing it, you
  * want to be holding this lock.
  *
- * In addition, it also protects the fl->fl_block list, and the fl->fl_next
+ * In addition, it also protects the fl->fl_blocked list, and the 
fl->fl_blocker
  * pointer for file_lock structures that are acting as lock requests (in
  * contrast to those that are acting as records of acquired locks).
  *
@@ -203,7 +203,7 @@ static DEFINE_HASHTABLE(blocked_hash, BLOCKED_HASH_BITS);
  * protected by this lock, we can skip acquiring it iff we already hold the
  * flc_lock.
  *
- * In particular, adding an entry to the fl_block list requires that you hold
+ * In particular, adding an entry to the fl_blocked list requires that you hold
  * both the flc_lock and the blocked_lock_lock (acquired in that order).
  * Deleting an entry from the list however only requires the file_lock_lock.
  */
@@ -302,6 +302,7 @@ static void locks_init_lock_heads(struct file_lock *fl)
 {
INIT_HLIST_NODE(&fl->fl_link);
INIT_LIST_HEAD(&fl->fl_list);
+   INIT_LIST_HEAD(&fl->fl_blocked);
INIT_LIST_HEAD(&fl->fl_block);
init_waitqueue_head(&fl->fl_wait);
 }
@@ -341,6 +342,7 @@ void locks_free_lock(struct file_lock *fl)
 {
BUG_ON(waitqueue_active(&fl->fl_wait));
BUG_ON(!list_empty(&fl->fl_list));
+   BUG_ON(!list_empty(&fl->fl_blocked));
BUG_ON(!list_empty(&fl->fl_block));
BUG_ON(!hlist_unhashed(&fl->fl_link));
 
@@ -676,7 +678,7 @@ static void __locks_delete_block(struct file_lock *waiter)
 {
locks_delete_global_blocked(waiter);
list_del_init(&waiter->fl_block);
-   waiter->fl_next = NULL;
+   waiter->fl_blocker = NULL;
 }
 
 static void locks_delete_block(struct file_lock *waiter)
@@ -692,16 +694,16 @@ static void locks_delete_block(struct file_lock *waiter)
  * it seems like the reasonable thing to do.
  *
  * Must be called with both the flc_lock and blocked_lock_lock held. The
- * fl_block list itself is protected by the blocked_lock_lock, but by ensuring
+ * fl_blocked list itself is protected by the blocked_lock_lock, but by 
ensuring
  * that the flc_lock is also held on insertions we can avoid taking the
- * blocked_lock_lock in some cases when we see that the fl_block list is empty.
+ * blocked_lock_lock in some cases when we see that the fl_blocked list is 
empty.
  */
 static void __locks_insert_block(struct file_lock *blocker,
struct file_lock *waiter)
 {
BUG_ON(!list_empty(&waiter->fl_block));
-   waiter->fl_next = blocker;
-   list_add_tail(&waiter->fl_block, &blocker->fl_block);
+   waiter->fl_blocker = blocker;
+   list_add_tail(&waiter->fl_block, &blocker->fl_blocked);
if (IS_POSIX(blocker) && !IS_OFDLCK(blocker))
locks_insert_global_blocked(waiter);
 }
@@ -725,18 +727,18 @@ static void locks_wake_up_blocks(struct file_lock 
*blocker)
/*
 * Avoid taking global lock if list is empty. This is safe since new
 * blocked requests are only added to the list under the flc_lock, and
-* the flc_lock is always held here. Note that removal from the fl_block
+* the flc_lock is always held here. Note that removal 

[PATCH v2] staging/bcm2835-audio: Fix alignment of function arguments - Style

[Greg Gallagher]

Fix warnings generated by checkpatch.pl for alignment should match open
parenthesis.  This is a coding style change only.

Signed-off-by: Greg Gallagher 
---
Changes in v2:
- Clean up all the alignment warnings in the file
---
 .../staging/vc04_services/bcm2835-audio/bcm2835-ctl.c  | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/staging/vc04_services/bcm2835-audio/bcm2835-ctl.c 
b/drivers/staging/vc04_services/bcm2835-audio/bcm2835-ctl.c
index ec468d5719b1..8af303e25036 100644
--- a/drivers/staging/vc04_services/bcm2835-audio/bcm2835-ctl.c
+++ b/drivers/staging/vc04_services/bcm2835-audio/bcm2835-ctl.c
@@ -94,7 +94,7 @@ static int snd_bcm2835_ctl_get(struct snd_kcontrol *kcontrol,
 }
 
 static int snd_bcm2835_ctl_put(struct snd_kcontrol *kcontrol,
-   struct snd_ctl_elem_value *ucontrol)
+  struct snd_ctl_elem_value *ucontrol)
 {
struct bcm2835_chip *chip = snd_kcontrol_chip(kcontrol);
int changed = 0;
@@ -174,7 +174,7 @@ static struct snd_kcontrol_new snd_bcm2835_ctl[] = {
 };
 
 static int snd_bcm2835_spdif_default_info(struct snd_kcontrol *kcontrol,
-   struct snd_ctl_elem_info *uinfo)
+ struct snd_ctl_elem_info *uinfo)
 {
uinfo->type = SNDRV_CTL_ELEM_TYPE_IEC958;
uinfo->count = 1;
@@ -182,7 +182,7 @@ static int snd_bcm2835_spdif_default_info(struct 
snd_kcontrol *kcontrol,
 }
 
 static int snd_bcm2835_spdif_default_get(struct snd_kcontrol *kcontrol,
-   struct snd_ctl_elem_value *ucontrol)
+struct snd_ctl_elem_value *ucontrol)
 {
struct bcm2835_chip *chip = snd_kcontrol_chip(kcontrol);
int i;
@@ -199,7 +199,7 @@ static int snd_bcm2835_spdif_default_get(struct 
snd_kcontrol *kcontrol,
 }
 
 static int snd_bcm2835_spdif_default_put(struct snd_kcontrol *kcontrol,
-   struct snd_ctl_elem_value *ucontrol)
+struct snd_ctl_elem_value *ucontrol)
 {
struct bcm2835_chip *chip = snd_kcontrol_chip(kcontrol);
unsigned int val = 0;
@@ -219,7 +219,7 @@ static int snd_bcm2835_spdif_default_put(struct 
snd_kcontrol *kcontrol,
 }
 
 static int snd_bcm2835_spdif_mask_info(struct snd_kcontrol *kcontrol,
-   struct snd_ctl_elem_info *uinfo)
+  struct snd_ctl_elem_info *uinfo)
 {
uinfo->type = SNDRV_CTL_ELEM_TYPE_IEC958;
uinfo->count = 1;
@@ -227,7 +227,7 @@ static int snd_bcm2835_spdif_mask_info(struct snd_kcontrol 
*kcontrol,
 }
 
 static int snd_bcm2835_spdif_mask_get(struct snd_kcontrol *kcontrol,
-   struct snd_ctl_elem_value *ucontrol)
+ struct snd_ctl_elem_value *ucontrol)
 {
/*
 * bcm2835 supports only consumer mode and sets all other format flags
@@ -238,7 +238,7 @@ static int snd_bcm2835_spdif_mask_get(struct snd_kcontrol 
*kcontrol,
 }
 
 static int snd_bcm2835_spdif_stream_info(struct snd_kcontrol *kcontrol,
-   struct snd_ctl_elem_info *uinfo)
+struct snd_ctl_elem_info *uinfo)
 {
uinfo->type = SNDRV_CTL_ELEM_TYPE_IEC958;
uinfo->count = 1;
@@ -246,7 +246,7 @@ static int snd_bcm2835_spdif_stream_info(struct 
snd_kcontrol *kcontrol,
 }
 
 static int snd_bcm2835_spdif_stream_get(struct snd_kcontrol *kcontrol,
-   struct snd_ctl_elem_value *ucontrol)
+   struct snd_ctl_elem_value *ucontrol)
 {
struct bcm2835_chip *chip = snd_kcontrol_chip(kcontrol);
int i;
@@ -263,7 +263,7 @@ static int snd_bcm2835_spdif_stream_get(struct snd_kcontrol 
*kcontrol,
 }
 
 static int snd_bcm2835_spdif_stream_put(struct snd_kcontrol *kcontrol,
-   struct snd_ctl_elem_value *ucontrol)
+   struct snd_ctl_elem_value *ucontrol)
 {
struct bcm2835_chip *chip = snd_kcontrol_chip(kcontrol);
unsigned int val = 0;
-- 
2.14.1

[PATCH v2] staging/vc04_services: Fix alignment of function arguments

[Greg Gallagher]

Fix warnings generated by checkpatch.pl for alignment should match open
parenthesis.  This is a coding style change only.

Signed-off-by: Greg Gallagher 
---
 .../staging/vc04_services/bcm2835-audio/bcm2835-ctl.c  | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/staging/vc04_services/bcm2835-audio/bcm2835-ctl.c 
b/drivers/staging/vc04_services/bcm2835-audio/bcm2835-ctl.c
index ec468d5719b1..8af303e25036 100644
--- a/drivers/staging/vc04_services/bcm2835-audio/bcm2835-ctl.c
+++ b/drivers/staging/vc04_services/bcm2835-audio/bcm2835-ctl.c
@@ -94,7 +94,7 @@ static int snd_bcm2835_ctl_get(struct snd_kcontrol *kcontrol,
 }
 
 static int snd_bcm2835_ctl_put(struct snd_kcontrol *kcontrol,
-   struct snd_ctl_elem_value *ucontrol)
+  struct snd_ctl_elem_value *ucontrol)
 {
struct bcm2835_chip *chip = snd_kcontrol_chip(kcontrol);
int changed = 0;
@@ -174,7 +174,7 @@ static struct snd_kcontrol_new snd_bcm2835_ctl[] = {
 };
 
 static int snd_bcm2835_spdif_default_info(struct snd_kcontrol *kcontrol,
-   struct snd_ctl_elem_info *uinfo)
+ struct snd_ctl_elem_info *uinfo)
 {
uinfo->type = SNDRV_CTL_ELEM_TYPE_IEC958;
uinfo->count = 1;
@@ -182,7 +182,7 @@ static int snd_bcm2835_spdif_default_info(struct 
snd_kcontrol *kcontrol,
 }
 
 static int snd_bcm2835_spdif_default_get(struct snd_kcontrol *kcontrol,
-   struct snd_ctl_elem_value *ucontrol)
+struct snd_ctl_elem_value *ucontrol)
 {
struct bcm2835_chip *chip = snd_kcontrol_chip(kcontrol);
int i;
@@ -199,7 +199,7 @@ static int snd_bcm2835_spdif_default_get(struct 
snd_kcontrol *kcontrol,
 }
 
 static int snd_bcm2835_spdif_default_put(struct snd_kcontrol *kcontrol,
-   struct snd_ctl_elem_value *ucontrol)
+struct snd_ctl_elem_value *ucontrol)
 {
struct bcm2835_chip *chip = snd_kcontrol_chip(kcontrol);
unsigned int val = 0;
@@ -219,7 +219,7 @@ static int snd_bcm2835_spdif_default_put(struct 
snd_kcontrol *kcontrol,
 }
 
 static int snd_bcm2835_spdif_mask_info(struct snd_kcontrol *kcontrol,
-   struct snd_ctl_elem_info *uinfo)
+  struct snd_ctl_elem_info *uinfo)
 {
uinfo->type = SNDRV_CTL_ELEM_TYPE_IEC958;
uinfo->count = 1;
@@ -227,7 +227,7 @@ static int snd_bcm2835_spdif_mask_info(struct snd_kcontrol 
*kcontrol,
 }
 
 static int snd_bcm2835_spdif_mask_get(struct snd_kcontrol *kcontrol,
-   struct snd_ctl_elem_value *ucontrol)
+ struct snd_ctl_elem_value *ucontrol)
 {
/*
 * bcm2835 supports only consumer mode and sets all other format flags
@@ -238,7 +238,7 @@ static int snd_bcm2835_spdif_mask_get(struct snd_kcontrol 
*kcontrol,
 }
 
 static int snd_bcm2835_spdif_stream_info(struct snd_kcontrol *kcontrol,
-   struct snd_ctl_elem_info *uinfo)
+struct snd_ctl_elem_info *uinfo)
 {
uinfo->type = SNDRV_CTL_ELEM_TYPE_IEC958;
uinfo->count = 1;
@@ -246,7 +246,7 @@ static int snd_bcm2835_spdif_stream_info(struct 
snd_kcontrol *kcontrol,
 }
 
 static int snd_bcm2835_spdif_stream_get(struct snd_kcontrol *kcontrol,
-   struct snd_ctl_elem_value *ucontrol)
+   struct snd_ctl_elem_value *ucontrol)
 {
struct bcm2835_chip *chip = snd_kcontrol_chip(kcontrol);
int i;
@@ -263,7 +263,7 @@ static int snd_bcm2835_spdif_stream_get(struct snd_kcontrol 
*kcontrol,
 }
 
 static int snd_bcm2835_spdif_stream_put(struct snd_kcontrol *kcontrol,
-   struct snd_ctl_elem_value *ucontrol)
+   struct snd_ctl_elem_value *ucontrol)
 {
struct bcm2835_chip *chip = snd_kcontrol_chip(kcontrol);
unsigned int val = 0;
-- 
2.14.1

RE: [PATCH 0/2] x86/intel_rdt and perf/x86: Fix lack of coordination with perf

[Luck, Tony]

Would it help to call routines to read the "before" values of the counter
twice. The first time to preload the cache with anything needed to execute
the perf code path.

>> In an attempt to improve the accuracy of the above I modified it to the
>> following:
>>
>> /* create the two events as before in "enabled" state */
>> l2_hit_pmcnum = l2_hit_event->hw.event_base_rdpmc;
>> l2_miss_pmcnum = l2_miss_event->hw.event_base_rdpmc;
>> local_irq_disable();
>> /* disable hw prefetchers */
>> /* init local vars to loop through pseudo-locked mem
  * may take some misses in the perf code
  */
 l2_hits_before = native_read_pmc(l2_hit_pmcnum);
 l2_miss_before = native_read_pmc(l2_miss_pmcnum);
 /* Read counters again, hope no new misses here */
>> l2_hits_before = native_read_pmc(l2_hit_pmcnum);
>> l2_miss_before = native_read_pmc(l2_miss_pmcnum);
>> /* loop through pseudo-locked mem */
>> l2_hits_after = native_read_pmc(l2_hit_pmcnum);
>> l2_miss_after = native_read_pmc(l2_miss_pmcnum);
>> /* enable hw prefetchers */
>> local_irq_enable();

Re: [PATCH 0/3] Kbuild: fix and clean-up arch/um/Makefile

[Masahiro Yamada]

2018-08-07 5:54 GMT+09:00 Richard Weinberger :
> Am Samstag, 4. August 2018, 06:47:00 CEST schrieb Masahiro Yamada:
>>
>> 1/3 fixes the build failure reported by Randy.
>> (I may have seen a similar report before, but I cannot recall it.)
>>
>> 2/3 and 3/3 clean-up the Makefile a bit more.
>>
>> I'd like to apply this series to kbuild tree.
>> Ack from UML folks are appreciated.
>
> Nice to see this fixed, Masahiro! :-)
>
> Acked-by: Richard Weinberger 
>


Applied to linux-kbuild.


-- 
Best Regards
Masahiro Yamada

Re: [PATCH v12 3/3] tracing: Centralize preemptirq tracepoints and unify their usage

[Joel Fernandes]

On Tue, Aug 7, 2018 at 5:48 PM, Steven Rostedt  wrote:
> On Tue, 07 Aug 2018 19:54:13 -0400
> Joel Fernandes  wrote:
>
>
>> >OK, I hit this bug, but it's not because of the partial revert. This
>> >bug seems it needs to be another partial revert. I like you movement of
>> >the code, but I'm starting to doubt that we can use a trace event as a
>> >hook for critical areas yet. Well, not until we can use srcu in NMI.
>> >
>>
>> I sent a patch to use srcu for all tracepoints including nmi. That
>> patch also removes this warning and fixes the one other issue masami
>> reported (hot plug causing a warning).
>
> Is it one I can take, or does Paul have it? I'll need it to continue
> with this as is, because I can't pass my tests without triggering that
> warning (and that fails the test).

I think you could take it if you're Ok with it, its purely in the
tracing code and I tested it yesterday morning. Its attached to this
email. I tested that it fixes the mmio trace (hotplug related) issue..

>>
>> If Paul and Mathieu can confirm SRCU works on offline CPUs that would
>> be great.
>
> Yes please.
>

BTW I found this in Paul's docs RCU Requirements docs, "SRCU is insensitive
to whether or not a CPU is online" so I think it will work.

The paragraph was..
Also unlike other RCU flavors, SRCU's callbacks-wait function
srcu_barrier() may be invoked from CPU-hotplug notifiers,
though this is not necessarily a good idea.
The reason that this is possible is that SRCU is insensitive
to whether or not a CPU is online, which means that srcu_barrier()
need not exclude CPU-hotplug operations.

>>
>> It's just this one warning or anything else that makes you feel
>> tracepoints for critical paths isn't feasible?
>
> Currently I'm down to this, but I can't get past my first test in my
> ktest suite, because it fails here.

Ok hopefully this will get you past that. Sorry for the frustration.
From 6986af946ceb04fc9ddc6d5b45fc559b6807e465 Mon Sep 17 00:00:00 2001
From: "Joel Fernandes (Google)" 
Date: Sun, 5 Aug 2018 20:17:41 -0700
Subject: [PATCH] tracepoint: Run tracepoints even after CPU is offline

Commit f37755490fe9 ("tracepoints: Do not trace when cpu is offline")
causes a problem for lockdep using tracepoint code. Once a CPU is
offline, tracepoints donot get called, however this causes a big problem
for lockdep probes that need to run so that IRQ annotations are marked
correctly.

A race is possible where while the CPU is going offline, an interrupt
can come in and then a lockdep assert causes an annotation warning:

[  106.551354] IRQs not enabled as expected
[  106.551785] WARNING: CPU: 1 PID: 0 at kernel/time/tick-sched.c:982
 tick_nohz_idle_enter+0x99/0xb0
[  106.552964] Modules linked in:
[  106.553299] CPU: 1 PID: 0 Comm: swapper/1 Tainted: GW

We need tracepoints to run as late as possible. This commit fixes the
issue by removing the cpu_online check in tracepoint code that was
introduced in the mentioned commit, however we now switch to using SRCU
for all tracepoints and special handle calling tracepoints from NMI so
that we don't run into issues that result from using sched-RCU when the
CPUs are marked to be offline.

Fixes: c3bc8fd637a9 ("tracing: Centralize preemptirq tracepoints and
  unify their usage")
Reported-by: Masami Hiramatsu 
Signed-off-by: Joel Fernandes (Google) 
---
 include/linux/tracepoint.h | 27 +++
 kernel/tracepoint.c| 10 ++
 2 files changed, 17 insertions(+), 20 deletions(-)

diff --git a/include/linux/tracepoint.h b/include/linux/tracepoint.h
index d9a084c72541..5733502bb3ce 100644
--- a/include/linux/tracepoint.h
+++ b/include/linux/tracepoint.h
@@ -35,6 +35,7 @@ struct trace_eval_map {
 #define TRACEPOINT_DEFAULT_PRIO	10
 
 extern struct srcu_struct tracepoint_srcu;
+extern struct srcu_struct tracepoint_srcu_nmi;
 
 extern int
 tracepoint_probe_register(struct tracepoint *tp, void *probe, void *data);
@@ -144,13 +145,11 @@ extern void syscall_unregfunc(void);
 		void *it_func;		\
 		void *__data;		\
 		int __maybe_unused idx = 0;\
+		struct srcu_struct *ss;	\
 	\
 		if (!(cond))		\
 			return;		\
 	\
-		/* srcu can't be used from NMI */			\
-		WARN_ON_ONCE(rcuidle && in_nmi());			\
-	\
 		/* keep srcu and sched-rcu usage consistent */		\
 		preempt_disable_notrace();\
 	\
@@ -159,7 +158,11 @@ extern void syscall_unregfunc(void);
 		 * doesn't work from the idle path.			\
 		 */			\
 		if (rcuidle)		\
-			idx = srcu_read_lock_notrace(&tracepoint_srcu);	\
+			ss = &tracepoint_srcu_nmi;			\
+		else			\
+			ss = &tracepoint_srcu;\
+	\
+		idx = srcu_read_lock_notrace(ss);			\
 	\
 		it_func_ptr = rcu_dereference_raw((tp)->funcs);		\
 	\
@@ -171,8 +174,7 @@ extern void syscall_unregfunc(void);
 			} while ((++it_func_ptr)->func);		\
 		}			\
 	\
-		if (rcuidle)		\
-			srcu_read

Re: [PATCH v3] PCI/AER: Do not clear AER bits if we don't own AER

[Bjorn Helgaas]

On Mon, Jul 30, 2018 at 06:35:31PM -0500, Alexandru Gagniuc wrote:
> When we don't own AER, we shouldn't touch the AER error bits. Clearing
> error bits willy-nilly might cause firmware to miss some errors. In
> theory, these bits get cleared by FFS, or via ACPI _HPX method. These
> mechanisms are not subject to the problem.

What's FFS?

I guess you mean FFS and _HPX are not subject to the problem because
they're supplied by firmware, so firmware would be responsible for
looking at the bits before clearing them?

> This race is mostly of theoretical significance, since I can't
> reasonably demonstrate this race in the lab.
> 
> On a side-note, pcie_aer_is_kernel_first() is created to alleviate the
> need for two checks: aer_cap and get_firmware_first().
> 
> Signed-off-by: Alexandru Gagniuc 
> ---
> 
> Changes since v2:
>   - Added missing negation in pci_cleanup_aer_error_status_regs()
> 
>  drivers/pci/pcie/aer.c | 17 ++---
>  1 file changed, 10 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c
> index a2e88386af28..40e5c86271d1 100644
> --- a/drivers/pci/pcie/aer.c
> +++ b/drivers/pci/pcie/aer.c
> @@ -307,6 +307,12 @@ int pcie_aer_get_firmware_first(struct pci_dev *dev)
>   aer_set_firmware_first(dev);
>   return dev->__aer_firmware_first;
>  }
> +
> +static bool pcie_aer_is_kernel_first(struct pci_dev *dev)
> +{
> + return !!dev->aer_cap && !pcie_aer_get_firmware_first(dev);
> +}

I think it complicates things to have both "firmware_first" and
"kernel_first" interfaces, so I would prefer to stick with the
existing "firmware_first" style.

>  #define  PCI_EXP_AER_FLAGS   (PCI_EXP_DEVCTL_CERE | 
> PCI_EXP_DEVCTL_NFERE | \
>PCI_EXP_DEVCTL_FERE | PCI_EXP_DEVCTL_URRE)
>  
> @@ -337,10 +343,7 @@ bool aer_acpi_firmware_first(void)
>  
>  int pci_enable_pcie_error_reporting(struct pci_dev *dev)
>  {
> - if (pcie_aer_get_firmware_first(dev))
> - return -EIO;
> -
> - if (!dev->aer_cap)
> + if (!pcie_aer_is_kernel_first(dev))
>   return -EIO;
>  
>   return pcie_capability_set_word(dev, PCI_EXP_DEVCTL, PCI_EXP_AER_FLAGS);

This change doesn't actually fix anything, does it?  It looks like a
cleanup that doesn't change the behavior.

> @@ -349,7 +352,7 @@ EXPORT_SYMBOL_GPL(pci_enable_pcie_error_reporting);
>  
>  int pci_disable_pcie_error_reporting(struct pci_dev *dev)
>  {
> - if (pcie_aer_get_firmware_first(dev))
> + if (!pcie_aer_is_kernel_first(dev))
>   return -EIO;

This change does effectively add a test for dev->aer_cap.  That makes
sense in terms of symmetry with pci_enable_pcie_error_reporting(),
but I think it should be a separate patch because it's conceptually
separate from the change below.

We should keep the existing behavior (but add the symmetry) here for
now, but it's not clear to me that these paths should care about AER
or firmware-first at all.  PCI_EXP_DEVCTL is not an AER register and
we have the _HPX mechanism for firmware to influence it (which these
paths currently ignore).  I suspect we should program these reporting
enable bits in the core enumeration path instead of having drivers
call these interfaces.

If/when we make changes along these lines, the history will be easier
to follow if *this* change is not connected with the change below to
pci_cleanup_aer_error_status_regs().

>   return pcie_capability_clear_word(dev, PCI_EXP_DEVCTL,
> @@ -383,10 +386,10 @@ int pci_cleanup_aer_error_status_regs(struct pci_dev 
> *dev)
>   if (!pci_is_pcie(dev))
>   return -ENODEV;
>  
> - pos = dev->aer_cap;
> - if (!pos)
> + if (!pcie_aer_is_kernel_first(dev))
>   return -EIO;

This part makes sense to me, but I think I would rather have it match
the existing style in pci_enable_pcie_error_reporting(), i.e., keep
the test for dev->aer_cap and add a test for
pcie_aer_get_firmware_first().

> + pos = dev->aer_cap;
>   port_type = pci_pcie_type(dev);
>   if (port_type == PCI_EXP_TYPE_ROOT_PORT) {
>   pci_read_config_dword(dev, pos + PCI_ERR_ROOT_STATUS, &status);
> -- 
> 2.17.1
> 

Vienkaršs aizdevuma piedavajums 3% gada !!!

[MR. SANDRO FERAGO]

Üdvözlet neked,

Mi az A-E hitelek on-line szolgáltatásai biztosítékkal és fedezetlen hitelekkel 
rendelkeznek, nagyon alacsony kamatlábon 3%. Személyi hiteleket, 
adósságkonszolidációs kölcsönöket, kockázati toke, üzleti kölcsön, oktatási 
kölcsön, háztartási kölcsön vagy "hitelt bármilyen okból kínálunk!

Megjegyzés: A Személyi Hitelösszeg minimum 5 000 euró és legfeljebb 500 000 
euró, míg az üzleti / befektetési kölcsönösszeg minimum 100 000 euró és 
legfeljebb 50 000 000 euró.

Lépjen kapcsolatba velünk még ma!

hogy válaszoljon erre az e-mailre, vagy lépjen kapcsolatba velünk honlapunkon: 
www.a-eloans.webs.com

Meleg üdvözlettel,

Mr. Ferago .LM. Sandro
Loan Services Controller,
A-E LOANS
Branch Tel: +306992471605
www.a-eloans.webs.com

Re: [PATCH RFC 00/10] Introduce lockless shrink_slab()

[Stephen Rothwell]

Hi Kirill,

On Tue, 07 Aug 2018 18:37:19 +0300 Kirill Tkhai  wrote:
>
> After bitmaps of not-empty memcg shrinkers were implemented
> (see "[PATCH v9 00/17] Improve shrink_slab() scalability..."
> series, which is already in mm tree), all the evil in perf
> trace has moved from shrink_slab() to down_read_trylock().
> As reported by Shakeel Butt:
> 
>  > I created 255 memcgs, 255 ext4 mounts and made each memcg create a
>  > file containing few KiBs on corresponding mount. Then in a separate
>  > memcg of 200 MiB limit ran a fork-bomb.
>  >
>  > I ran the "perf record -ag -- sleep 60" and below are the results:
>  > +  47.49%fb.sh  [kernel.kallsyms][k] down_read_trylock
>  > +  30.72%fb.sh  [kernel.kallsyms][k] up_read
>  > +   9.51%fb.sh  [kernel.kallsyms][k] mem_cgroup_iter
>  > +   1.69%fb.sh  [kernel.kallsyms][k] shrink_node_memcg
>  > +   1.35%fb.sh  [kernel.kallsyms][k] 
> mem_cgroup_protected
>  > +   1.05%fb.sh  [kernel.kallsyms][k] 
> queued_spin_lock_slowpath
>  > +   0.85%fb.sh  [kernel.kallsyms][k] _raw_spin_lock
>  > +   0.78%fb.sh  [kernel.kallsyms][k] lruvec_lru_size
>  > +   0.57%fb.sh  [kernel.kallsyms][k] shrink_node
>  > +   0.54%fb.sh  [kernel.kallsyms][k] queue_work_on
>  > +   0.46%fb.sh  [kernel.kallsyms][k] shrink_slab_memcg 
>  
> 
> The patchset continues to improve shrink_slab() scalability and makes
> it lockless completely. Here are several steps for that:

So do you have any numbers for after theses changes?

-- 
Cheers,
Stephen Rothwell


pgpTfqqSQYZUe.pgp
Description: OpenPGP digital signature

Re: [PATCH RFC 01/10] rcu: Make CONFIG_SRCU unconditionally enabled

[Stephen Rothwell]

Hi Kirill,

On Tue, 07 Aug 2018 18:37:36 +0300 Kirill Tkhai  wrote:
>
> This patch kills all CONFIG_SRCU defines and
> the code under !CONFIG_SRCU.
> 
> Signed-off-by: Kirill Tkhai 

So what sort of overheads (in terms of code size and performance) are
we adding by having SRCU enabled where it used not to be?

-- 
Cheers,
Stephen Rothwell


pgpmgfAMS12n9.pgp
Description: OpenPGP digital signature

Re: [PATCH RFC 01/10] rcu: Make CONFIG_SRCU unconditionally enabled

[Stephen Rothwell]

Hi Kirill,

On Tue, 07 Aug 2018 18:37:36 +0300 Kirill Tkhai  wrote:
>
> This patch kills all CONFIG_SRCU defines and
> the code under !CONFIG_SRCU.
> 
> Signed-off-by: Kirill Tkhai 
> ---
>  drivers/base/core.c|   42 
> 
>  include/linux/device.h |2 -
>  include/linux/rcutiny.h|4 --
>  include/linux/srcu.h   |5 --
>  kernel/notifier.c  |3 -
>  kernel/rcu/Kconfig |   12 +-
>  kernel/rcu/tree.h  |5 --
>  kernel/rcu/update.c|4 --
>  .../selftests/rcutorture/doc/TREE_RCU-kconfig.txt  |5 --
>  9 files changed, 3 insertions(+), 79 deletions(-)

You left quite a few "select SRCU" statements scattered across Kconfig
files:

$ git grep -l 'select SRCU' '*Kconfig*'
arch/arm/kvm/Kconfig
arch/arm64/kvm/Kconfig
arch/mips/kvm/Kconfig
arch/powerpc/kvm/Kconfig
arch/s390/kvm/Kconfig
arch/x86/Kconfig
arch/x86/kvm/Kconfig
block/Kconfig
drivers/clk/Kconfig
drivers/cpufreq/Kconfig
drivers/dax/Kconfig
drivers/devfreq/Kconfig
drivers/hwtracing/stm/Kconfig
drivers/md/Kconfig
drivers/net/Kconfig
drivers/opp/Kconfig
fs/btrfs/Kconfig
fs/notify/Kconfig
fs/quota/Kconfig
init/Kconfig
kernel/rcu/Kconfig
kernel/rcu/Kconfig.debug
mm/Kconfig
security/tomoyo/Kconfig

-- 
Cheers,
Stephen Rothwell


pgpCG1XaJwJMj.pgp
Description: OpenPGP digital signature

Re: [PATCH] mm: adjust max read count in generic_file_buffered_read()

[cgxu519]

On 08/07/2018 09:54 PM, Jan Kara wrote:

On Mon 06-08-18 15:59:27, Andrew Morton wrote:

On Mon, 6 Aug 2018 12:22:03 +0200 Jan Kara  wrote:


On Fri 20-07-18 16:14:29, Andrew Morton wrote:

On Thu, 19 Jul 2018 10:58:12 +0200 Jan Kara  wrote:


On Thu 19-07-18 16:17:26, Chengguang Xu wrote:

When we try to truncate read count in generic_file_buffered_read(),
should deliver (sb->s_maxbytes - offset) as maximum count not
sb->s_maxbytes itself.

Signed-off-by: Chengguang Xu 

Looks good to me. You can add:

Reviewed-by: Jan Kara 

Yup.

What are the runtime effects of this bug?

Good question. I think ->readpage() could be called for index beyond
maximum file size supported by the filesystem leading to weird filesystem
behavior due to overflows in internal calculations.


Sure.  But is it possible for userspace to trigger this behaviour?
Possibly all callers have already sanitized the arguments by this stage
in which case the statement is arguably redundant.

So I don't think there's any sanitization going on before
generic_file_buffered_read(). E.g. I don't see any s_maxbytes check on
ksys_read() -> vfs_read() -> __vfs_read() -> new_sync_read() ->
call_read_iter() -> generic_file_read_iter() ->
generic_file_buffered_read() path... However now thinking about this again:
We are guaranteed i_size is within s_maxbytes (places modifying i_size
are checking for this) and generic_file_buffered_read() stops when it
should read beyond i_size. So in the end I don't think there's any breakage
possible and the patch is not necessary?


I think most of time i_size is within s_maxbytes in local filesystem,
but consider network filesystem, write big file in 64bit client and
read in 32bit client, in this case maybe generic_file_buffered_read()
can read more than s_maxbytes, right?


Thanks,
Chengguang

Re: [PATCH RFC 01/10] rcu: Make CONFIG_SRCU unconditionally enabled

[Steven Rostedt]

On Tue, 07 Aug 2018 18:37:36 +0300
Kirill Tkhai  wrote:

> This patch kills all CONFIG_SRCU defines and
> the code under !CONFIG_SRCU.

Can you add the rationale for removing the SRCU config in the change log
please.

Thanks!

-- Steve

> 
> Signed-off-by: Kirill Tkhai 
> ---
>  drivers/base/core.c|   42 
> 
>  include/linux/device.h |2 -
>  include/linux/rcutiny.h|4 --
>  include/linux/srcu.h   |5 --
>  kernel/notifier.c  |3 -
>  kernel/rcu/Kconfig |   12 +-
>  kernel/rcu/tree.h  |5 --
>  kernel/rcu/update.c|4 --
>  .../selftests/rcutorture/doc/TREE_RCU-kconfig.txt  |5 --
>  9 files changed, 3 insertions(+), 79 deletions(-)
> 
>

[PATCH] acpi: bus: Fixed a pointer coding style issue

[Tom Todd]

Fixed a coding style issue.

Signed-off-by: Tom Todd 
---
 drivers/acpi/bus.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index 84b4a62018eb..73e43d81ec63 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -962,7 +962,7 @@ static int acpi_device_probe(struct device *dev)
return 0;
 }
 
-static int acpi_device_remove(struct device * dev)
+static int acpi_device_remove(struct device *dev)
 {
struct acpi_device *acpi_dev = to_acpi_device(dev);
struct acpi_driver *acpi_drv = acpi_dev->driver;
-- 
2.18.0

Re: [PATCH v12 3/3] tracing: Centralize preemptirq tracepoints and unify their usage

[Steven Rostedt]

On Tue, 07 Aug 2018 19:54:13 -0400
Joel Fernandes  wrote:


> >OK, I hit this bug, but it's not because of the partial revert. This
> >bug seems it needs to be another partial revert. I like you movement of
> >the code, but I'm starting to doubt that we can use a trace event as a
> >hook for critical areas yet. Well, not until we can use srcu in NMI.
> >  
> 
> I sent a patch to use srcu for all tracepoints including nmi. That
> patch also removes this warning and fixes the one other issue masami
> reported (hot plug causing a warning).

Is it one I can take, or does Paul have it? I'll need it to continue
with this as is, because I can't pass my tests without triggering that
warning (and that fails the test).

> 
> If Paul and Mathieu can confirm SRCU works on offline CPUs that would
> be great.

Yes please.

> 
> It's just this one warning or anything else that makes you feel
> tracepoints for critical paths isn't feasible?

Currently I'm down to this, but I can't get past my first test in my
ktest suite, because it fails here.

-- Steve

Re: [PATCH v2 2/4] phy: socionext: add USB3 PHY driver for UniPhier SoC

[Kunihiko Hayashi]

On Fri, 3 Aug 2018 18:54:03 +0900  wrote:

> Add a driver for PHY interface built into USB3 controller
> implemented in UniPhier SoCs.
> This driver supports High-Speed PHY and Super-Speed PHY.
> 
> Signed-off-by: Kunihiko Hayashi 
> Signed-off-by: Motoya Tanigawa 
> Signed-off-by: Masami Hiramatsu 
> ---
>  drivers/phy/Kconfig |   1 +
>  drivers/phy/Makefile|   1 +
>  drivers/phy/socionext/Kconfig   |  12 +
>  drivers/phy/socionext/Makefile  |   6 +
>  drivers/phy/socionext/phy-uniphier-usb3hs.c | 423 
> 
>  drivers/phy/socionext/phy-uniphier-usb3ss.c | 350 +++
>  6 files changed, 793 insertions(+)
>  create mode 100644 drivers/phy/socionext/Kconfig
>  create mode 100644 drivers/phy/socionext/Makefile
>  create mode 100644 drivers/phy/socionext/phy-uniphier-usb3hs.c
>  create mode 100644 drivers/phy/socionext/phy-uniphier-usb3ss.c

[snip]

> +static void uniphier_u3ssphy_testio_write(struct uniphier_u3ssphy_priv *priv,
> +   u32 data)
> +{
> + /* need to read TESTO twice after accessing TESTI */
> + writel(data, priv->base + SSPHY_TESTI);
> + readl(priv->base + SSPHY_TESTI);
> + readl(priv->base + SSPHY_TESTI);

I made a mistake here. The comment and the code are inconsistent.
I'll fix it next.

Thanks,

---
Best Regards,
Kunihiko Hayashi

[PATCH v2 13/15] staging: fbtft: Corrects long index line - Style

[Leonardo Brás]

Avoids a very long line of index, improving readability.

Signed-off-by: Leonardo Brás 
---
 drivers/staging/fbtft/fbtft-sysfs.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/fbtft/fbtft-sysfs.c 
b/drivers/staging/fbtft/fbtft-sysfs.c
index 2a5c630dab87..9caeb9ceb008 100644
--- a/drivers/staging/fbtft/fbtft-sysfs.c
+++ b/drivers/staging/fbtft/fbtft-sysfs.c
@@ -25,6 +25,7 @@ int fbtft_gamma_parse_str(struct fbtft_par *par, u32 *curves,
unsigned long val = 0;
int ret = 0;
int curve_counter, value_counter;
+   unsigned long idx;
 
fbtft_par_dbg(DEBUG_SYSFS, par, "%s() str=\n", __func__);
 
@@ -68,7 +69,10 @@ int fbtft_gamma_parse_str(struct fbtft_par *par, u32 *curves,
ret = get_next_ulong(&curve_p, &val, " ", 16);
if (ret)
goto out;
-   curves[curve_counter * par->gamma.num_values + 
value_counter] = val;
+   idx = curve_counter * par->gamma.num_values +
+ value_counter;
+   curves[idx] = val;
value_counter++;
}
if (value_counter != par->gamma.num_values) {
-- 
2.18.0

[PATCH v2 14/15] staging: fbtft: Replaces (1 << n) for macro BIT(n) - Style

[Leonardo Brás]

Uses default macro BIT(n) instead (1 << n)

Signed-off-by: Leonardo Brás 
---
 drivers/staging/fbtft/fbtft.h | 56 +--
 1 file changed, 28 insertions(+), 28 deletions(-)

diff --git a/drivers/staging/fbtft/fbtft.h b/drivers/staging/fbtft/fbtft.h
index f771271d497a..2b2988d2f73e 100644
--- a/drivers/staging/fbtft/fbtft.h
+++ b/drivers/staging/fbtft/fbtft.h
@@ -373,39 +373,39 @@ module_exit(fbtft_driver_module_exit)
 DEBUG_LEVEL_5)
 #define DEBUG_LEVEL_7  0x
 
-#define DEBUG_DRIVER_INIT_FUNCTIONS (1<<3)
-#define DEBUG_TIME_FIRST_UPDATE (1<<4)
-#define DEBUG_TIME_EACH_UPDATE  (1<<5)
-#define DEBUG_DEFERRED_IO   (1<<6)
-#define DEBUG_FBTFT_INIT_FUNCTIONS  (1<<7)
+#define DEBUG_DRIVER_INIT_FUNCTIONSBIT(3)
+#define DEBUG_TIME_FIRST_UPDATEBIT(4)
+#define DEBUG_TIME_EACH_UPDATE BIT(5)
+#define DEBUG_DEFERRED_IO  BIT(6)
+#define DEBUG_FBTFT_INIT_FUNCTIONS BIT(7)
 
 /* fbops */
-#define DEBUG_FB_READ   (1<<8)
-#define DEBUG_FB_WRITE  (1<<9)
-#define DEBUG_FB_FILLRECT   (1<<10)
-#define DEBUG_FB_COPYAREA   (1<<11)
-#define DEBUG_FB_IMAGEBLIT  (1<<12)
-#define DEBUG_FB_SETCOLREG  (1<<13)
-#define DEBUG_FB_BLANK  (1<<14)
+#define DEBUG_FB_READ  BIT(8)
+#define DEBUG_FB_WRITE BIT(9)
+#define DEBUG_FB_FILLRECT  BIT(10)
+#define DEBUG_FB_COPYAREA  BIT(11)
+#define DEBUG_FB_IMAGEBLIT BIT(12)
+#define DEBUG_FB_SETCOLREG BIT(13)
+#define DEBUG_FB_BLANK BIT(14)
 
-#define DEBUG_SYSFS (1<<16)
+#define DEBUG_SYSFSBIT(16)
 
 /* fbtftops */
-#define DEBUG_BACKLIGHT (1<<17)
-#define DEBUG_READ  (1<<18)
-#define DEBUG_WRITE (1<<19)
-#define DEBUG_WRITE_VMEM(1<<20)
-#define DEBUG_WRITE_REGISTER(1<<21)
-#define DEBUG_SET_ADDR_WIN  (1<<22)
-#define DEBUG_RESET (1<<23)
-#define DEBUG_MKDIRTY   (1<<24)
-#define DEBUG_UPDATE_DISPLAY(1<<25)
-#define DEBUG_INIT_DISPLAY  (1<<26)
-#define DEBUG_BLANK (1<<27)
-#define DEBUG_REQUEST_GPIOS (1<<28)
-#define DEBUG_FREE_GPIOS(1<<29)
-#define DEBUG_REQUEST_GPIOS_MATCH   (1<<30)
-#define DEBUG_VERIFY_GPIOS  (1<<31)
+#define DEBUG_BACKLIGHTBIT(17)
+#define DEBUG_READ BIT(18)
+#define DEBUG_WRITEBIT(19)
+#define DEBUG_WRITE_VMEM   BIT(20)
+#define DEBUG_WRITE_REGISTER   BIT(21)
+#define DEBUG_SET_ADDR_WIN BIT(22)
+#define DEBUG_RESETBIT(23)
+#define DEBUG_MKDIRTY  BIT(24)
+#define DEBUG_UPDATE_DISPLAY   BIT(25)
+#define DEBUG_INIT_DISPLAY BIT(26)
+#define DEBUG_BLANKBIT(27)
+#define DEBUG_REQUEST_GPIOSBIT(28)
+#define DEBUG_FREE_GPIOS   BIT(29)
+#define DEBUG_REQUEST_GPIOS_MATCH  BIT(30)
+#define DEBUG_VERIFY_GPIOS BIT(31)
 
 #define fbtft_init_dbg(dev, format, arg...)  \
 do { \
-- 
2.18.0

[PATCH v2 15/15] staging: fbtft: Replaces custom debug macro with dev_dbg().

[Leonardo Brás]

Changes custom macro to dev_dbg to avoid parameter multiple usage and use of 
typeof().

Signed-off-by: Leonardo Brás 
---
 drivers/staging/fbtft/fbtft.h | 17 +
 1 file changed, 5 insertions(+), 12 deletions(-)

diff --git a/drivers/staging/fbtft/fbtft.h b/drivers/staging/fbtft/fbtft.h
index 2b2988d2f73e..0699c164b0d4 100644
--- a/drivers/staging/fbtft/fbtft.h
+++ b/drivers/staging/fbtft/fbtft.h
@@ -407,22 +407,15 @@ module_exit(fbtft_driver_module_exit)
 #define DEBUG_REQUEST_GPIOS_MATCH  BIT(30)
 #define DEBUG_VERIFY_GPIOS BIT(31)
 
-#define fbtft_init_dbg(dev, format, arg...)  \
-do { \
-   if (unlikely((dev)->platform_data && \
-   (((struct fbtft_platform_data 
*)(dev)->platform_data)->display.debug & DEBUG_DRIVER_INIT_FUNCTIONS))) \
-   dev_info(dev, format, ##arg);\
-} while (0)
+#define fbtft_init_dbg(dev, format, arg...)\
+   dev_dbg(dev, format, ##arg)
 
-#define fbtft_par_dbg(level, par, format, arg...)\
-do { \
-   if (unlikely(par->debug & level))\
-   dev_info(par->info->device, format, ##arg);  \
-} while (0)
+#define fbtft_par_dbg(level, par, format, arg...)  \
+   dev_dbg(par->info->device, format, ##arg)
 
 #define fbtft_par_dbg_hex(level, par, dev, type, buf, num, format, arg...) \
 do {   \
-   if (unlikely((par)->debug & (level)))  \
+   if (unlikely((par)->debug & (level)))  \
fbtft_dbg_hex(dev, sizeof(type), buf,\
  (num) * sizeof(type), format, ##arg); \
 } while (0)
-- 
2.18.0