[PATCH v5 05/23] ASoC: qdsp6: dt-bindings: Add q6adm dt bindings

[srinivas . kandagatla]

From: Srinivas Kandagatla 

This patch add DT bindings for ADM (Audio Device Manager) DSP module.
This module implements mixer controls to setup the connections between
AFE ports and ASM streams.

Signed-off-by: Srinivas Kandagatla 
Reviewed-and-tested-by: Rohit kumar 
---
 .../devicetree/bindings/sound/qcom,q6adm.txt   | 33 ++
 1 file changed, 33 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/sound/qcom,q6adm.txt

diff --git a/Documentation/devicetree/bindings/sound/qcom,q6adm.txt 
b/Documentation/devicetree/bindings/sound/qcom,q6adm.txt
new file mode 100644
index ..f1e2df8d2ea8
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/qcom,q6adm.txt
@@ -0,0 +1,33 @@
+Qualcomm Audio Device Manager (Q6ADM) binding
+
+Q6ADM is one of the APR audio service on Q6DSP.
+Please refer to qcom,apr.txt for details of the coommon apr service bindings
+used by the apr service device.
+
+- but must contain the following property:
+
+- compatible:
+   Usage: required
+   Value type: 
+   Definition: must be "qcom,adm-v.".
+  Or "qcom,adm" where the version number can be queried
+  from DSP.
+  example "qcom,adm-v2.0"
+
+
+= ADM routing
+"routing" subnode of the ADM node represents adm routing specific configuration
+
+- #sound-dai-cells
+   Usage: required
+   Value type: 
+   Definition: Must be 0
+
+= EXAMPLE
+q6adm {
+   compatible = "qcom,q6adm";
+   reg = ;
+   q6routing: routing {
+   #sound-dai-cells = <0>;
+   };
+};
-- 
2.16.2

[__cpa_process_fault] CPA: called for zero pte.

[Fengguang Wu]

Hello,

FYI this happens in mainline kernel 4.17.0-rc1.
It's a new regression.

[0.00] Memory: 210548K/523752K available (16392K kernel code, 2355K 
rwdata, 5536K rodata, 2996K init, 21012K bss, 66128K reserved, 0K cma-reserved)
[0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[0.00] Kernel/User page tables isolation: enabled
[0.00] [ cut here ]
[0.00] CPA: called for zero pte. vaddr = b240 cpa->vaddr = 
b240
[0.00] WARNING: CPU: 0 PID: 0 at arch/x86/mm/pageattr.c:1189 
__cpa_process_fault+0x572/0x5a0:
__cpa_process_fault at 
arch/x86/mm/pageattr.c:1187 (discriminator 1)
[0.00] CPU: 0 PID: 0 Comm: swapper Tainted: GT 
4.17.0-rc1 #304
[0.00] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.10.2-1 04/01/2014
[0.00] RIP: 0010:__cpa_process_fault+0x572/0x5a0:
__cpa_process_fault at 
arch/x86/mm/pageattr.c:1187 (discriminator 1)
[0.00] RSP: :b0a03c40 EFLAGS: 00010086
[0.00] RAX:  RBX: b220 RCX: 0002
[0.00] RDX:  RSI: 0002 RDI: 0046
[0.00] RBP: b0a03ca0 R08: 0001 R09: 0001
[0.00] R10: b0a884f8 R11:  R12: b0a03df0
[0.00] R13: 00e3 R14: 8800 R15: b240
[0.00] FS:  () GS:88001f80() 
knlGS:
[0.00] CS:  0010 DS:  ES:  CR0: 80050033
[0.00] CR2: 88000bbe6000 CR3: 0a26a001 CR4: 000606b0
[0.00] DR0:  DR1:  DR2: 
[0.00] DR3:  DR6: fffe0ff0 DR7: 0400
[0.00] Call Trace:
[0.00]  __change_page_attr_set_clr+0x1a0/0xde0:
__change_page_attr at 
arch/x86/mm/pageattr.c:1218
 (inlined by) 
__change_page_attr_set_clr at arch/x86/mm/pageattr.c:1374
[0.00]  ? lock_release+0x350/0x380:
lock_release at 
kernel/locking/lockdep.c:3943
[0.00]  change_page_attr_set_clr+0x17c/0x3f0:
change_page_attr_set_clr at 
arch/x86/mm/pageattr.c:1475
[0.00]  ? 0xaf20
[0.00]  set_memory_nonglobal+0x24/0x30:
set_memory_nonglobal at 
arch/x86/mm/pageattr.c:1765
[0.00]  pti_set_kernel_image_nonglobal+0x73/0x80:
pti_set_kernel_image_nonglobal 
at arch/x86/mm/pti.c:464
[0.00]  pti_init+0x4b/0x1fb:
pti_clone_entry_text at 
arch/x86/mm/pti.c:385
 (inlined by) pti_init at 
arch/x86/mm/pti.c:481
[0.00]  start_kernel+0x2ee/0x4da:
start_kernel at init/main.c:601
[0.00]  x86_64_start_reservations+0x2a/0x2c:
x86_64_start_reservations at 
arch/x86/kernel/head64.c:446
[0.00]  x86_64_start_kernel+0x77/0x7a:
x86_64_start_kernel at 
arch/x86/kernel/head64.c:427
[0.00]  secondary_startup_64+0xa5/0xb0:
secondary_startup_64 at 
arch/x86/kernel/head_64.S:242
[0.00] Code: 48 89 f7 31 db e8 5f 44 00 00 48 c1 e8 0c 49 89 44 24 30 
eb 24 49 8b 04 24 4c 89 fe 48 c7 c7 f8 e8 80 b0 48 8b 10 e8 0e d9 07 00 <0f> 0b 
bb f2 ff ff ff eb 05 bb ff ff ff ff 48 83 c4 38 89 d8 5b
[0.00] ---[ end trace 9c220c3d1fdf6e76 ]---
[0.00] [ cut here ]
[0.00] [ cut here ]
[0.00] kernel BUG at arch/x86/mm/pageattr.c:175!
[0.00] invalid opcode:  [#1] SMP PTI
[0.00] CPU: 0 PID: 0 Comm: swapper Tainted: GW   T 
4.17.0-rc1 #304
[0.00] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.10.2-1 04/01/2014
[0.00] RIP: 0010:cpa_flush_all+0x10/0x30:
cpa_flush_all at 
arch/x86/mm/pageattr.c:175
[0.00] RSP: :b0a03db0 EFLAGS: 00010046
[0.00] RAX: 0082 RBX:  RCX: fff2
[0.00] RDX:  RSI:  RDI: 
[0.00] RBP: b0a03db0 R08: 0001 R09: 
[0.00] R10: 0001 R11:  R12: b0a03e80
[0.00] R13: 3400 R14:  R15: 
[

Re: [PATCH 2/6] rhashtable: remove incorrect comment on r{hl, hash}table_walk_enter()

[Herbert Xu]

On Wed, Apr 18, 2018 at 04:47:01PM +1000, NeilBrown wrote:
> Neither rhashtable_walk_enter() or rhltable_walk_enter() sleep, so
> remove the comments which suggest that they do.
> 
> Signed-off-by: NeilBrown 
> ---
>  include/linux/rhashtable.h |3 ---
>  lib/rhashtable.c   |3 ---
>  2 files changed, 6 deletions(-)
> 
> diff --git a/include/linux/rhashtable.h b/include/linux/rhashtable.h
> index 87d443a5b11d..b01d88e196c2 100644
> --- a/include/linux/rhashtable.h
> +++ b/include/linux/rhashtable.h
> @@ -1268,9 +1268,6 @@ static inline int rhashtable_walk_init(struct 
> rhashtable *ht,
>   * For a completely stable walk you should construct your own data
>   * structure outside the hash table.
>   *
> - * This function may sleep so you must not call it from interrupt
> - * context or with spin locks held.

It does a naked spin lock so even though we removed the memory
allocation you still mustn't call it from interrupt context.

Why do you need to do that anyway?

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

Re: [PATCH 1/6] rhashtable: remove outdated comments about grow_decision etc

[Herbert Xu]

On Wed, Apr 18, 2018 at 04:47:01PM +1000, NeilBrown wrote:
> grow_decision and shink_decision no longer exist, so remove
> the remaining references to them.
> 
> Signed-off-by: NeilBrown 

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

Re: [PATCH 2/2] printk: wake up klogd in vprintk_emit

[Steven Rostedt]

On Sat, 14 Apr 2018 12:01:45 +0900
Sergey Senozhatsky  wrote:

> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -1888,6 +1888,7 @@ asmlinkage int vprintk_emit(int facility, int level,
>  
>   printed_len = log_output(facility, level, lflags, dict, dictlen, text, 
> text_len);
>  
> + wake_up_klogd();
>   logbuf_unlock_irqrestore(flags);

You can't do this, because the scheduler can call printk_deferred()
with the rq lock held, and printk_deferred() will grab the logbuf lock.

Calling wake_up_klogd() will grab the rq lock and give us a A-B<->B-A
locking order.

-- Steve

Re: [PATCH net-next v4 0/3] kernel: add support to collect hardware logs in crash recovery kernel

[Eric W. Biederman]

Rahul Lakkireddy  writes:

> On Wednesday, April 04/18/18, 2018 at 11:45:46 +0530, Dave Young wrote:
>> Hi Rahul,
>> On 04/17/18 at 01:14pm, Rahul Lakkireddy wrote:
>> > On production servers running variety of workloads over time, kernel
>> > panic can happen sporadically after days or even months. It is
>> > important to collect as much debug logs as possible to root cause
>> > and fix the problem, that may not be easy to reproduce. Snapshot of
>> > underlying hardware/firmware state (like register dump, firmware
>> > logs, adapter memory, etc.), at the time of kernel panic will be very
>> > helpful while debugging the culprit device driver.
>> > 
>> > This series of patches add new generic framework that enable device
>> > drivers to collect device specific snapshot of the hardware/firmware
>> > state of the underlying device in the crash recovery kernel. In crash
>> > recovery kernel, the collected logs are added as elf notes to
>> > /proc/vmcore, which is copied by user space scripts for post-analysis.
>> > 
>> > The sequence of actions done by device drivers to append their device
>> > specific hardware/firmware logs to /proc/vmcore are as follows:
>> > 
>> > 1. During probe (before hardware is initialized), device drivers
>> > register to the vmcore module (via vmcore_add_device_dump()), with
>> > callback function, along with buffer size and log name needed for
>> > firmware/hardware log collection.
>> 
>> I assumed the elf notes info should be prepared while kexec_[file_]load
>> phase. But I did not read the old comment, not sure if it has been discussed
>> or not.
>> 
>
> We must not collect dumps in crashing kernel. Adding more things in
> crash dump path risks not collecting vmcore at all. Eric had
> discussed this in more detail at:
>
> https://lkml.org/lkml/2018/3/24/319
>
> We are safe to collect dumps in the second kernel. Each device dump
> will be exported as an elf note in /proc/vmcore.

It just occurred to me there is one variation that is worth
considering.

Is the area you are looking at dumping part of a huge mmio area?
I think someone said 2GB?

If that is the case it could be worth it to simply add the needed
addresses to the range of memory we need to dump, and simply having a
elf note saying that is what happened.

>> If do this in 2nd kernel a question is driver can be loaded later than 
>> vmcore init.
>
> Yes, drivers will add their device dumps after vmcore init.
>
>> How to guarantee the function works if vmcore reading happens before
>> the driver is loaded?
>> 
>> Also it is possible that kdump initramfs does not contains the driver
>> module.
>> 
>> Am I missing something?
>> 
>
> Yes, driver must be in initramfs if it wants to collect and add device
> dump to /proc/vmcore in second kernel.

Eric

Re: [PATCH v2 01/12] mm: Assign id to every memcg-aware shrinker

[Tetsuo Handa]

Kirill Tkhai wrote:
> On 18.04.2018 17:14, Tetsuo Handa wrote:
> > Kirill Tkhai wrote:
> >> The patch introduces shrinker::id number, which is used to enumerate
> >> memcg-aware shrinkers. The number start from 0, and the code tries
> >> to maintain it as small as possible.
> >>
> >> This will be used as to represent a memcg-aware shrinkers in memcg
> >> shrinkers map.
> > 
> > I'm not reading this thread. But is there reason "id" needs to be managed
> > using smallest numbers? Can't we use address of shrinker object as "id"
> > (which will be sparse bitmap, and would be managed using linked list for 
> > now)?
> 
> Yes, it's needed to have the smallest numbers, as next patches introduce
> per-memcg bitmap containing ids of shrinkers.

If you use sparse bitmap (xbitmap ?), I think you can do it.

Re: [PATCH 6/6] rhashtable: add rhashtable_walk_prev()

[Herbert Xu]

On Wed, Apr 18, 2018 at 04:47:02PM +1000, NeilBrown wrote:
> rhashtable_walk_prev() returns the object returned by
> the previous rhashtable_walk_next(), providing it is still in the
> table (or was during this grace period).
> This works even if rhashtable_walk_stop() and rhashtable_talk_start()
> have been called since the last rhashtable_walk_next().
> 
> If there have been no calls to rhashtable_walk_next(), or if the
> object is gone from the table, then NULL is returned.
> 
> This can usefully be used in a seq_file ->start() function.
> If the pos is the same as was returned by the last ->next() call,
> then rhashtable_walk_prev() can be used to re-establish the
> current location in the table.  If it returns NULL, then
> rhashtable_walk_next() should be used.
> 
> Signed-off-by: NeilBrown 

Can you explain the need for this function and its difference
from the existing rhashtable_walk_peek?

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

[PATCH] net: don't use kvzalloc for DMA memory

[Mikulas Patocka]

The patch 74d332c13b21 changes alloc_netdev_mqs to use vzalloc if kzalloc
fails (later patches change it to kvzalloc).

The problem with this is that if the vzalloc function is actually used, 
virtio_net doesn't work (because it expects that the extra memory should 
be accessible with DMA-API and memory allocated with vzalloc isn't).

This patch changes it back to kzalloc and adds a warning if the allocated
size is too large (the allocation is unreliable in this case).

Signed-off-by: Mikulas Patocka 
Fixes: 74d332c13b21 ("net: extend net_device allocation to vmalloc()")

---
 net/core/dev.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

Index: linux-2.6/net/core/dev.c
===
--- linux-2.6.orig/net/core/dev.c   2018-04-16 21:08:36.0 +0200
+++ linux-2.6/net/core/dev.c2018-04-18 16:24:43.0 +0200
@@ -8366,7 +8366,8 @@ struct net_device *alloc_netdev_mqs(int
/* ensure 32-byte alignment of whole construct */
alloc_size += NETDEV_ALIGN - 1;
 
-   p = kvzalloc(alloc_size, GFP_KERNEL | __GFP_RETRY_MAYFAIL);
+   WARN_ON(alloc_size > PAGE_SIZE << PAGE_ALLOC_COSTLY_ORDER);
+   p = kzalloc(alloc_size, GFP_KERNEL | __GFP_RETRY_MAYFAIL);
if (!p)
return NULL;
 

[PATCH v9 1/2] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

[Jacopo Mondi]

Document Thine THC63LVD1024 LVDS decoder device tree bindings.

Signed-off-by: Jacopo Mondi 
Reviewed-by: Andrzej Hajda 
Reviewed-by: Niklas Söderlund 
Reviewed-by: Laurent Pinchart 
Reviewed-by: Rob Herring 
---
 .../bindings/display/bridge/thine,thc63lvd1024.txt | 60 ++
 1 file changed, 60 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt

diff --git 
a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt 
b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
new file mode 100644
index 000..37f0c04
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
@@ -0,0 +1,60 @@
+Thine Electronics THC63LVD1024 LVDS decoder
+---
+
+The THC63LVD1024 is a dual link LVDS receiver designed to convert LVDS streams
+to parallel data outputs. The chip supports single/dual input/output modes,
+handling up to two LVDS input streams and up to two digital CMOS/TTL outputs.
+
+Single or dual operation mode, output data mapping and DDR output modes are
+configured through input signals and the chip does not expose any control bus.
+
+Required properties:
+- compatible: Shall be "thine,thc63lvd1024"
+- vcc-supply: Power supply for TTL output, TTL CLOCKOUT signal, LVDS input,
+  PPL and digital circuitry
+
+Optional properties:
+- powerdown-gpios: Power down GPIO signal, pin name "/PDWN". Active low
+- oe-gpios: Output enable GPIO signal, pin name "OE". Active high
+
+The THC63LVD1024 video port connections are modeled according
+to OF graph bindings specified by Documentation/devicetree/bindings/graph.txt
+
+Required video port nodes:
+- port@0: First LVDS input port
+- port@2: First digital CMOS/TTL parallel output
+
+Optional video port nodes:
+- port@1: Second LVDS input port
+- port@3: Second digital CMOS/TTL parallel output
+
+Example:
+
+
+   thc63lvd1024: lvds-decoder {
+   compatible = "thine,thc63lvd1024";
+
+   vcc-supply = <_lvds_vcc>;
+   powerdown-gpios = < 15 GPIO_ACTIVE_LOW>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+
+   lvds_dec_in_0: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+
+   port@2{
+   reg = <2>;
+
+   lvds_dec_out_2: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+   };
+   };
-- 
2.7.4

Re: [PATCH 1/2] tracing: fix bad use of igrab in trace_uprobe.c

[Miklos Szeredi]

On Wed, Apr 18, 2018 at 4:25 PM, Steven Rostedt  wrote:
> On Wed, 18 Apr 2018 16:03:42 +0200
> Miklos Szeredi  wrote:
>
>> > @@ -937,7 +928,8 @@ probe_event_enable(struct trace_uprobe *tu, struct 
>> > trace_event_file *file,
>> > goto err_flags;
>> >
>> > tu->consumer.filter = filter;
>> > -   ret = uprobe_register(tu->inode, tu->offset, >consumer);
>> > +   ret = uprobe_register(d_inode(tu->path.dentry), tu->offset,
>> > + >consumer);
>>
>> It is not entirely clear how the lifetime of uprobe relates to the
>> lifetime of trace_uprobe.  Is the uprobe object never going to survive
>> its creator trace_uprobe object?
>
> Not exactly sure what you mean here.
>
> The trace_uprobe (the probe event) is created, it doesn't do anything
> until it is enabled. This function is called when it is enabled. The
> trace_uprobe (probe event) can not be deleted while it is enabled
> (EBUSY).
>
> Are you asking what happens if the file is deleted while it has probe?
> That I don't know about (haven't tried it out). But I would hope that
> it keeps a reference to the inode, isn't that what the igrab is for?
> And is now being replaced by a reference on the path, or is that the
> problem?

No, that's not the problem.

What I don't see is how the uprobe object relates to the trace_uprobe object.

Because after the patch the uprobe object still only has a ref to the
inode, and that can lead to the same issue as with trace_uprobe.
OTOH if uprobe can't survive its creating trace_uprobe, then it
doesn't need to take a ref to the inode at all, since trace_uprobe
already holds it.   Taking an extra ref isn't incorrect, it's just
unnecessary and confusing.

So this needs to be cleared up in some way.

Thanks,
Miklos

Re: [PATCH] blkcg: not hold blkcg lock when deactivating policy.

[Jens Axboe]

On 4/18/18 3:18 AM, jiang.bi...@zte.com.cn wrote:
> Hi,
>>> Il giorno 17 apr 2018, alle ore 09:10, Jiang Biao  
>>> ha scritto:
>>>
>>> As described in the comment of blkcg_activate_policy(),
>>> *Update of each blkg is protected by both queue and blkcg locks so
>>> that holding either lock and testing blkcg_policy_enabled() is
>>> always enough for dereferencing policy data.*
>>> with queue lock held, there is no need to hold blkcg lock in
>>> blkcg_deactivate_policy(). Similar case is in
>>> blkcg_activate_policy(), which has removed holding of blkcg lock in
>>> commit 4c55f4f9ad3001ac1fefdd8d8ca7641d18558e23.
>>>
>>
>> Hi,
>> by chance, did you check whether this may cause problems with bfq,
>> being the latter not protected by the queue lock as cfq?
> Checked the bfq code, bfq seems never used blkcg lock derectly, and 
> update of blkg in the common code is protected by both queue and 
> blkcg locks, so IMHO this patch would not introduce any new problem
> with bfq, even though bfq is not protected by queue lock.
> On the other hand, the locks (queue lock/blkcg lock) used to protected
> the update of blkg seems a bit too heavyweight, especially the queue lock 
> which is used too widely may cause races with other contexts. I wonder
> if there is any way to ease the case? e.g. add a new lock for blkg's own.:) 

It might make sense to lock it separately, but I would not worry
about it unless it shows up as hot in your testing.

I've applied your patch, thanks.

-- 
Jens Axboe

Re: [GIT PULL V3] Thermal SoC management updates for v4.17-rc1

[Zhang Rui]

On 三, 2018-04-18 at 07:10 -0700, Eduardo Valentin wrote:
> Hello,
> 
> On Wed, Apr 18, 2018 at 03:51:29PM +0800, Zhang Rui wrote:
> > 
> > Hi, Eduardo,
> > 
> > On 六, 2018-04-14 at 11:30 -0700, Eduardo Valentin wrote:
> > > 
> > > Hello Linus,
> > > 
> > > Please find thermal-soc changes for v4.17-rc1.
> > > Rui asked me to send the pull request directly to you
> > > as we are close to the end of the merge window.
> > > Essentially this pull removes the series that caused
> > > warning regression. I will work with the developer
> > > to get that fixed later on, but I am still sending
> > > the other few patches that are unrelated to that.
> > > Let me know if this causes any issues and can still
> > > be pulled.
> > > 
> > > Changelog:
> > > - New i.MX7 thermal sensor
> > > - Mediatek driver now supports MT7622 SoC
> > > - Removal of min max cpu cooling DT property
> > > 
> > > Differences in V3:
> > > - Rebased on top current linus/master, to avoid and merge issues
> > > from previous pulled thermal code.
> > > 
> > > Differences in V2:
> > > - Reordered the patches to drop exynos changes for now until we
> > > get
> > > agreement on the fix on that driver for the compilation warns
> > > caused by the confusing conversion functions.
> > > 
> > > 
> > > The following changes since commit
> > > 48023102b7078a6674516b1fe0d639669336049d:
> > > 
> > >   Merge branch 'overlayfs-linus' of
> > > git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs (2018-
> > > 04-
> > > 13 16:55:41 -0700)
> > > 
> > > are available in the git repository at:
> > > 
> > >   git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-
> > > soc-
> > > thermal linus
> > > 
> > > for you to fetch changes up to
> > > 15a32df1918259be6c23fc36014fc26ee66c836c:
> > > 
> > >   dt-bindings: thermal: Remove "cooling-{min|max}-level"
> > > properties
> > > (2018-04-14 09:37:55 -0700)
> > > 
> > This pull request does not catch this merge window.
> > So do you want to split it into 2 separate pull requests, one for
> > 4.17-
> > rc and another for 4.18-rc1?
> OK. Yeah, I am fine with that.
> 
> > 
> > 
> > > 
> > > 
> > > Anson Huang (1):
> > >   thermal: imx: add i.MX7 thermal sensor support
> > > 
> > > Bartlomiej Zolnierkiewicz (1):
> > >   dt-bindings: thermal: remove no longer needed samsung
> > > thermal
> > > properties
> > > 
> > > Sean Wang (2):
> > >   dt-bindings: thermal: add binding for MT7622 SoC
> > >   thermal: mediatek: add support for MT7622 SoC
> > > 
> > > Viresh Kumar (1):
> > >   dt-bindings: thermal: Remove "cooling-{min|max}-level"
> > > properties
> > > 
> > IMO, together with the refreshed exynos fixes, the one from Viresh
> > and
> > the one from Bartlomiej can be queued for 4.17-rc, and the others
> > have
> > to wait until next merge window.
> > 
> Correct, the new chip support will need to wait for the next merge
> window. I have already split the patches into the two categories.
> The patches removing stuff are in my -fixes branch. All the other
> adding
> new chip support are in my -linus branch.
> 
> Now, Do you have anything for this -rc2 ? If not, I will send
> directly
> to Linus the stuff in my -fixes branch. Let me know.
> 
No, I don't have anything for -rc2. so please send pull request to
Linux directly.

thanks,
rui

Re: [PATCH] nvme: fix the suspicious RCU usage warning in nvme_mpath_clear_current_path

[Keith Busch]

On Wed, Apr 18, 2018 at 03:32:47PM +0800, Jianchao Wang wrote:
> With lockdep enabled, when trigger nvme_remove, suspicious RCU
> usage warning will be printed out.
> Fix it with adding srcu_read_lock/unlock in it.
> 
> Signed-off-by: Jianchao Wang 
> ---
>  drivers/nvme/host/nvme.h | 9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/nvme/host/nvme.h b/drivers/nvme/host/nvme.h
> index 061fecf..d326c23 100644
> --- a/drivers/nvme/host/nvme.h
> +++ b/drivers/nvme/host/nvme.h
> @@ -446,9 +446,14 @@ void nvme_mpath_remove_disk(struct nvme_ns_head *head);
>  static inline void nvme_mpath_clear_current_path(struct nvme_ns *ns)
>  {
>   struct nvme_ns_head *head = ns->head;
> + int srcu_idx;
>  
> - if (head && ns == srcu_dereference(head->current_path, >srcu))
> - rcu_assign_pointer(head->current_path, NULL);
> + if (head) {
> + srcu_idx = srcu_read_lock(>srcu);
> + if (ns == srcu_dereference(head->current_path, >srcu))
> + rcu_assign_pointer(head->current_path, NULL);
> + srcu_read_unlock(>srcu, srcu_idx);
> + }
>  }
>  struct nvme_ns *nvme_find_path(struct nvme_ns_head *head);

Nothing against this patch. This just doesn't look correct even from
before since nvme_find_path can set head->current_path right back to
this namespace that we're trying to clear.

Christoph, am I missing something here or does this need additional
checks/synchronization?

[PATCH v6 0/9] Designware EP support and code clean up

[Gustavo Pimentel]

The patch set was made against the Lorenzo's master branch.

Adds support Designware EP support.

Increases the maximum number of interrupts allowed for Designware IP
controller.

Does a code cleanup on Designware driver:
 - Replaces magic numbers without a easy meaning by a well known define
   that helps the human compreension.
 - Replaces a division by 2 by a simple right shift rotation of 1 bit.
 - Fixes all first letter characters on comments and debug messages to
   upper case to maintain coherency.

Gustavo Pimentel (9):
  bindings: PCI: designware: Example update
  PCI: dwc: Add support for endpoint mode
  PCI: endpoint: functions/pci-epf-test: Add second entry
  bindings: PCI: designware: Add support for the EP in Designware driver
  misc: pci_endpoint_test: Add designware EP entry
  PCI: dwc: Define maximum number of vectors
  PCI: dwc: Replace lower into upper case characters
  PCI: dwc: Small computation improvement
  PCI: dwc: Replace magic number by defines

 .../PCI/endpoint/function/binding/pci-test.txt |   2 +
 .../devicetree/bindings/pci/designware-pcie.txt|  24 +++-
 drivers/misc/pci_endpoint_test.c   |   1 +
 drivers/pci/dwc/Kconfig|  41 --
 drivers/pci/dwc/pcie-designware-ep.c   |  16 +--
 drivers/pci/dwc/pcie-designware-host.c |  77 +-
 drivers/pci/dwc/pcie-designware-plat.c | 155 +++--
 drivers/pci/dwc/pcie-designware.c  |  22 +--
 drivers/pci/dwc/pcie-designware.h  |   1 +
 drivers/pci/endpoint/functions/pci-epf-test.c  |   8 ++
 10 files changed, 267 insertions(+), 80 deletions(-)

-- 
2.7.4

[PATCH v6 7/9] PCI: dwc: Replace lower into upper case characters

[Gustavo Pimentel]

Replaces lower into upper case characters in comments and debug printks.

This is an attempt to keep the messages coherent within the designware
driver.

Also fixed code style on dw_pcie_irq_domain_free function.

Signed-off-by: Gustavo Pimentel 
Acked-by: Jingoo Han 
Acked-by: Joao Pinto 
---
Change v1->v2:
 - Added an extra log description line about code style following Fabio
Estevam suggestion.
Change v2->v3:
 - Nothing changed, just to follow the patch set version.
Changes v3->v4:
 - Nothing changed, just to follow the patch set version.
Changes v4->v5:
 - Nothing changed, just to follow the patch set version.
Changes v5->v6:
 - Nothing changed, just to follow the patch set version.

 drivers/pci/dwc/pcie-designware-ep.c   | 16 
 drivers/pci/dwc/pcie-designware-host.c | 35 ++
 drivers/pci/dwc/pcie-designware.c  | 22 ++---
 3 files changed, 38 insertions(+), 35 deletions(-)

diff --git a/drivers/pci/dwc/pcie-designware-ep.c 
b/drivers/pci/dwc/pcie-designware-ep.c
index f07678b..15b22a6 100644
--- a/drivers/pci/dwc/pcie-designware-ep.c
+++ b/drivers/pci/dwc/pcie-designware-ep.c
@@ -75,7 +75,7 @@ static int dw_pcie_ep_inbound_atu(struct dw_pcie_ep *ep, enum 
pci_barno bar,
 
free_win = find_first_zero_bit(ep->ib_window_map, ep->num_ib_windows);
if (free_win >= ep->num_ib_windows) {
-   dev_err(pci->dev, "no free inbound window\n");
+   dev_err(pci->dev, "No free inbound window\n");
return -EINVAL;
}
 
@@ -100,7 +100,7 @@ static int dw_pcie_ep_outbound_atu(struct dw_pcie_ep *ep, 
phys_addr_t phys_addr,
 
free_win = find_first_zero_bit(ep->ob_window_map, ep->num_ob_windows);
if (free_win >= ep->num_ob_windows) {
-   dev_err(pci->dev, "no free outbound window\n");
+   dev_err(pci->dev, "No free outbound window\n");
return -EINVAL;
}
 
@@ -204,7 +204,7 @@ static int dw_pcie_ep_map_addr(struct pci_epc *epc, u8 
func_no,
 
ret = dw_pcie_ep_outbound_atu(ep, addr, pci_addr, size);
if (ret) {
-   dev_err(pci->dev, "failed to enable address\n");
+   dev_err(pci->dev, "Failed to enable address\n");
return ret;
}
 
@@ -348,21 +348,21 @@ int dw_pcie_ep_init(struct dw_pcie_ep *ep)
 
ret = of_property_read_u32(np, "num-ib-windows", >num_ib_windows);
if (ret < 0) {
-   dev_err(dev, "unable to read *num-ib-windows* property\n");
+   dev_err(dev, "Unable to read *num-ib-windows* property\n");
return ret;
}
if (ep->num_ib_windows > MAX_IATU_IN) {
-   dev_err(dev, "invalid *num-ib-windows*\n");
+   dev_err(dev, "Invalid *num-ib-windows*\n");
return -EINVAL;
}
 
ret = of_property_read_u32(np, "num-ob-windows", >num_ob_windows);
if (ret < 0) {
-   dev_err(dev, "unable to read *num-ob-windows* property\n");
+   dev_err(dev, "Unable to read *num-ob-windows* property\n");
return ret;
}
if (ep->num_ob_windows > MAX_IATU_OUT) {
-   dev_err(dev, "invalid *num-ob-windows*\n");
+   dev_err(dev, "Invalid *num-ob-windows*\n");
return -EINVAL;
}
 
@@ -389,7 +389,7 @@ int dw_pcie_ep_init(struct dw_pcie_ep *ep)
 
epc = devm_pci_epc_create(dev, _ops);
if (IS_ERR(epc)) {
-   dev_err(dev, "failed to create epc device\n");
+   dev_err(dev, "Failed to create epc device\n");
return PTR_ERR(epc);
}
 
diff --git a/drivers/pci/dwc/pcie-designware-host.c 
b/drivers/pci/dwc/pcie-designware-host.c
index 6c409079..5a23f78 100644
--- a/drivers/pci/dwc/pcie-designware-host.c
+++ b/drivers/pci/dwc/pcie-designware-host.c
@@ -248,8 +248,10 @@ static void dw_pcie_irq_domain_free(struct irq_domain 
*domain,
unsigned long flags;
 
raw_spin_lock_irqsave(>lock, flags);
+
bitmap_release_region(pp->msi_irq_in_use, data->hwirq,
  order_base_2(nr_irqs));
+
raw_spin_unlock_irqrestore(>lock, flags);
 }
 
@@ -266,7 +268,7 @@ int dw_pcie_allocate_domains(struct pcie_port *pp)
pp->irq_domain = irq_domain_create_linear(fwnode, pp->num_vectors,
   _pcie_msi_domain_ops, pp);
if (!pp->irq_domain) {
-   dev_err(pci->dev, "failed to create IRQ domain\n");
+   dev_err(pci->dev, "Failed to create IRQ domain\n");
return -ENOMEM;
}
 
@@ -274,7 +276,7 @@ int dw_pcie_allocate_domains(struct pcie_port *pp)
   _pcie_msi_domain_info,
   pp->irq_domain);
if (!pp->msi_domain) {
-   

[PATCH v6 9/9] PCI: dwc: Replace magic number by defines

[Gustavo Pimentel]

Replace magic numbers by a well known define in order to make the code
human readable and also facilitate the code reusability.

Signed-off-by: Gustavo Pimentel 
Acked-by: Jingoo Han 
---
Change v1->v2:
 - Nothing changed, just to follow the patch set version.
Change v2->v3:
 - Nothing changed, just to follow the patch set version.
Changes v3->v4:
 - Nothing changed, just to follow the patch set version.
Changes v4->v5:
 - Nothing changed, just to follow the patch set version.
Changes v5->v6:
 - Nothing changed, just to follow the patch set version.

 drivers/pci/dwc/pcie-designware-host.c | 34 --
 drivers/pci/dwc/pcie-designware.h  |  1 +
 2 files changed, 21 insertions(+), 14 deletions(-)

diff --git a/drivers/pci/dwc/pcie-designware-host.c 
b/drivers/pci/dwc/pcie-designware-host.c
index fc55fde..a7657ab 100644
--- a/drivers/pci/dwc/pcie-designware-host.c
+++ b/drivers/pci/dwc/pcie-designware-host.c
@@ -83,18 +83,23 @@ irqreturn_t dw_handle_msi_irq(struct pcie_port *pp)
num_ctrls = pp->num_vectors / MAX_MSI_IRQS_PER_CTRL;
 
for (i = 0; i < num_ctrls; i++) {
-   dw_pcie_rd_own_conf(pp, PCIE_MSI_INTR0_STATUS + i * 12, 4,
-   );
+   dw_pcie_rd_own_conf(pp, PCIE_MSI_INTR0_STATUS +
+   (i * MSI_REG_CTRL_BLOCK_SIZE),
+   4, );
if (!val)
continue;
 
ret = IRQ_HANDLED;
pos = 0;
-   while ((pos = find_next_bit((unsigned long *) , 32,
-   pos)) != 32) {
-   irq = irq_find_mapping(pp->irq_domain, i * 32 + pos);
+   while ((pos = find_next_bit((unsigned long *) ,
+   MAX_MSI_IRQS_PER_CTRL,
+   pos)) != MAX_MSI_IRQS_PER_CTRL) {
+   irq = irq_find_mapping(pp->irq_domain,
+  (i * MAX_MSI_IRQS_PER_CTRL) +
+  pos);
generic_handle_irq(irq);
-   dw_pcie_wr_own_conf(pp, PCIE_MSI_INTR0_STATUS + i * 12,
+   dw_pcie_wr_own_conf(pp, PCIE_MSI_INTR0_STATUS +
+   (i * MSI_REG_CTRL_BLOCK_SIZE),
4, 1 << pos);
pos++;
}
@@ -157,9 +162,9 @@ static void dw_pci_bottom_mask(struct irq_data *data)
if (pp->ops->msi_clear_irq) {
pp->ops->msi_clear_irq(pp, data->hwirq);
} else {
-   ctrl = data->hwirq / 32;
-   res = ctrl * 12;
-   bit = data->hwirq % 32;
+   ctrl = data->hwirq / MAX_MSI_IRQS_PER_CTRL;
+   res = ctrl * MSI_REG_CTRL_BLOCK_SIZE;
+   bit = data->hwirq % MAX_MSI_IRQS_PER_CTRL;
 
pp->irq_status[ctrl] &= ~(1 << bit);
dw_pcie_wr_own_conf(pp, PCIE_MSI_INTR0_ENABLE + res, 4,
@@ -180,9 +185,9 @@ static void dw_pci_bottom_unmask(struct irq_data *data)
if (pp->ops->msi_set_irq) {
pp->ops->msi_set_irq(pp, data->hwirq);
} else {
-   ctrl = data->hwirq / 32;
-   res = ctrl * 12;
-   bit = data->hwirq % 32;
+   ctrl = data->hwirq / MAX_MSI_IRQS_PER_CTRL;
+   res = ctrl * MSI_REG_CTRL_BLOCK_SIZE;
+   bit = data->hwirq % MAX_MSI_IRQS_PER_CTRL;
 
pp->irq_status[ctrl] |= 1 << bit;
dw_pcie_wr_own_conf(pp, PCIE_MSI_INTR0_ENABLE + res, 4,
@@ -652,8 +657,9 @@ void dw_pcie_setup_rc(struct pcie_port *pp)
 
/* Initialize IRQ Status array */
for (ctrl = 0; ctrl < num_ctrls; ctrl++)
-   dw_pcie_rd_own_conf(pp, PCIE_MSI_INTR0_ENABLE + (ctrl * 12), 4,
-   >irq_status[ctrl]);
+   dw_pcie_rd_own_conf(pp, PCIE_MSI_INTR0_ENABLE +
+   (ctrl * MSI_REG_CTRL_BLOCK_SIZE),
+   4, >irq_status[ctrl]);
 
/* Setup RC BARs */
dw_pcie_writel_dbi(pci, PCI_BASE_ADDRESS_0, 0x0004);
diff --git a/drivers/pci/dwc/pcie-designware.h 
b/drivers/pci/dwc/pcie-designware.h
index fe811db..bee4e25 100644
--- a/drivers/pci/dwc/pcie-designware.h
+++ b/drivers/pci/dwc/pcie-designware.h
@@ -110,6 +110,7 @@
 #define MAX_MSI_IRQS   256
 #define MAX_MSI_IRQS_PER_CTRL  32
 #define MAX_MSI_CTRLS  (MAX_MSI_IRQS / MAX_MSI_IRQS_PER_CTRL)
+#define MSI_REG_CTRL_BLOCK_SIZE12
 #define MSI_DEF_NUM_VECTORS32
 
 /* Maximum number of inbound/outbound iATUs */
-- 
2.7.4

[PATCH v6 1/9] bindings: PCI: designware: Example update

[Gustavo Pimentel]

Replaces "ctrlreg" reg-name by "dbi" to be coherent with similar drivers,
however it still be compatible with any previous DT that uses the old
reg-name.

Replaces the PCIe base address example by a real PCIe base address in use.

Signed-off-by: Gustavo Pimentel 
Reviewed-by: Rob Herring 
---
Changes v1->v2:
 - Removed any iATU reference or changes to avoid confusion.
 - Add "snps,dw-pcie" compatible string following Kishon's suggestion.
Changes v2->v3:
 - Nothing changed, just to follow the patch set version.
Changes v3->v4:
 - Reverted "snps,dw-pcie-rc" compatible string requested by Rob Herring.
Changes v4->v5:
 - Nothing changed, just to follow the patch set version.
Changes v5->v6:
 - Nothing changed, just to follow the patch set version.

 Documentation/devicetree/bindings/pci/designware-pcie.txt | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/Documentation/devicetree/bindings/pci/designware-pcie.txt 
b/Documentation/devicetree/bindings/pci/designware-pcie.txt
index 1da7ade..7f9804d 100644
--- a/Documentation/devicetree/bindings/pci/designware-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/designware-pcie.txt
@@ -1,7 +1,8 @@
 * Synopsys DesignWare PCIe interface
 
 Required properties:
-- compatible: should contain "snps,dw-pcie" to identify the core.
+- compatible:
+   "snps,dw-pcie" for RC mode;
 - reg: Should contain the configuration address space.
 - reg-names: Must be "config" for the PCIe configuration space.
 (The old way of getting the configuration address space from "ranges"
@@ -41,11 +42,11 @@ EP mode:
 
 Example configuration:
 
-   pcie: pcie@d000 {
+   pcie: pcie@dfc0 {
compatible = "snps,dw-pcie";
-   reg = <0xd000 0x1000>, /* Controller registers */
- <0xd000 0x2000>; /* PCI config space */
-   reg-names = "ctrlreg", "config";
+   reg = <0xdfc0 0x0001000>, /* IP registers */
+ <0xd000 0x0002000>; /* Configuration space */
+   reg-names = "dbi", "config";
#address-cells = <3>;
#size-cells = <2>;
device_type = "pci";
@@ -54,5 +55,4 @@ Example configuration:
interrupts = <25>, <24>;
#interrupt-cells = <1>;
num-lanes = <1>;
-   num-viewport = <3>;
};
-- 
2.7.4

[PATCH v3 5/5] pinctrl: sunxi: Use of_clk_get_parent_count() instead of open coding

[Geert Uytterhoeven]

A new open coder has crept in since 470b73a38470e8ba ("pinctrl: sunxi:
Use of_clk_get_parent_count() instead of open coding"), replace it.

of_clk_get_parent_count() was moved to , so include that
instead of .

Signed-off-by: Geert Uytterhoeven 
Acked-by: Maxime Ripard 
---
This depends on "[PATCH v3 1/5] clk: Extract OF clock helpers in
".

v3:
  - Add Acked-by,

v2:
  - New.
---
 drivers/pinctrl/sunxi/pinctrl-sunxi.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.c 
b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
index 020d6d84639ca002..25e80a5370ca02f6 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
+++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
@@ -12,12 +12,12 @@
 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1361,7 +1361,7 @@ int sunxi_pinctrl_init_with_variant(struct 
platform_device *pdev,
goto gpiochip_error;
}
 
-   ret = of_count_phandle_with_args(node, "clocks", "#clock-cells");
+   ret = of_clk_get_parent_count(node);
clk = devm_clk_get(>dev, ret == 1 ? NULL : "apb");
if (IS_ERR(clk)) {
ret = PTR_ERR(clk);
-- 
2.7.4

[PATCH v3 3/5] soc: rockchip: power-domain: Use of_clk_get_parent_count() instead of open coding

[Geert Uytterhoeven]

As of_clk_get_parent_count() returns zero on failure, while
of_count_phandle_with_args() might return a negative error code, this
also fixes the issue of possibly using a negative number in the
allocation below.

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Heiko Stuebner 
---
This depends on "[PATCH v3 1/5] clk: Extract OF clock helpers in
".

v3:
  - Add Reviewed-by,

v2:
  - of_clk_get_parent_count() was moved to .
---
 drivers/soc/rockchip/pm_domains.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/soc/rockchip/pm_domains.c 
b/drivers/soc/rockchip/pm_domains.c
index 53efc386b1ada8cf..13913d40c8213e36 100644
--- a/drivers/soc/rockchip/pm_domains.c
+++ b/drivers/soc/rockchip/pm_domains.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -400,8 +401,7 @@ static int rockchip_pm_add_one_domain(struct rockchip_pmu 
*pmu,
pd->info = pd_info;
pd->pmu = pmu;
 
-   pd->num_clks = of_count_phandle_with_args(node, "clocks",
- "#clock-cells");
+   pd->num_clks = of_clk_get_parent_count(node);
if (pd->num_clks > 0) {
pd->clks = devm_kcalloc(pmu->dev, pd->num_clks,
sizeof(*pd->clks), GFP_KERNEL);
-- 
2.7.4

[PATCH v3 4/5] soc/tegra: pmc: Use of_clk_get_parent_count() instead of open coding

[Geert Uytterhoeven]

As of_clk_get_parent_count() returns zero on failure, while
of_count_phandle_with_args() might return a negative error code, this
also fixes the issue of possibly using a very big number in the
allocation below.

Signed-off-by: Geert Uytterhoeven 
Acked-by: Jon Hunter 
---
This depends on "[PATCH v3 1/5] clk: Extract OF clock helpers in
".

v3:
  - Add Acked-by,

v2:
  - of_clk_get_parent_count() was moved to .
---
 drivers/soc/tegra/pmc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/soc/tegra/pmc.c b/drivers/soc/tegra/pmc.c
index d9fcdb592b3966a5..d8cb48a4b8eb1b78 100644
--- a/drivers/soc/tegra/pmc.c
+++ b/drivers/soc/tegra/pmc.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -725,7 +726,7 @@ static int tegra_powergate_of_get_clks(struct 
tegra_powergate *pg,
unsigned int i, count;
int err;
 
-   count = of_count_phandle_with_args(np, "clocks", "#clock-cells");
+   count = of_clk_get_parent_count(np);
if (count == 0)
return -ENODEV;
 
-- 
2.7.4

Re: [PATCH RESEND] slab: introduce the flag SLAB_MINIMIZE_WASTE

[Christopher Lameter]

On Tue, 17 Apr 2018, Mikulas Patocka wrote:

> I can make a slub-only patch with no extra flag (on a freshly booted
> system it increases only the order of caches "TCPv6" and "sighand_cache"
> by one - so it should not have unexpected effects):
>
> Doing a generic solution for slab would be more comlpicated because slab
> assumes that all slabs have the same order, so it can't fall-back to
> lower-order allocations.

Well again SLAB uses compound pages and thus would be able to detect the
size of the page. It may be some work but it could be done.

>
> Index: linux-2.6/mm/slub.c
> ===
> --- linux-2.6.orig/mm/slub.c  2018-04-17 19:59:49.0 +0200
> +++ linux-2.6/mm/slub.c   2018-04-17 20:58:23.0 +0200
> @@ -3252,6 +3252,7 @@ static inline unsigned int slab_order(un
>  static inline int calculate_order(unsigned int size, unsigned int reserved)
>  {
>   unsigned int order;
> + unsigned int test_order;
>   unsigned int min_objects;
>   unsigned int max_objects;
>
> @@ -3277,7 +3278,7 @@ static inline int calculate_order(unsign
>   order = slab_order(size, min_objects,
>   slub_max_order, fraction, reserved);
>   if (order <= slub_max_order)
> - return order;
> + goto ret_order;
>   fraction /= 2;
>   }
>   min_objects--;
> @@ -3289,15 +3290,25 @@ static inline int calculate_order(unsign
>*/
>   order = slab_order(size, 1, slub_max_order, 1, reserved);

The slab order is determined in slab_order()

>   if (order <= slub_max_order)
> - return order;
> + goto ret_order;
>
>   /*
>* Doh this slab cannot be placed using slub_max_order.
>*/
>   order = slab_order(size, 1, MAX_ORDER, 1, reserved);
> - if (order < MAX_ORDER)
> - return order;
> - return -ENOSYS;
> + if (order >= MAX_ORDER)
> + return -ENOSYS;
> +
> +ret_order:
> + for (test_order = order + 1; test_order < MAX_ORDER; test_order++) {
> + unsigned long order_objects = ((PAGE_SIZE << order) - reserved) 
> / size;
> + unsigned long test_order_objects = ((PAGE_SIZE << test_order) - 
> reserved) / size;
> + if (test_order_objects > min(32, MAX_OBJS_PER_PAGE))
> + break;
> + if (test_order_objects > order_objects << (test_order - order))
> + order = test_order;
> + }
> + return order;

Could yo move that logic into slab_order()? It does something awfully
similar.

Re: [PATCH v2 2/2] tpm: reduce polling time to usecs for even finer granularity

[Mimi Zohar]

On Tue, 2018-04-17 at 09:12 -0400, Nayna Jain wrote:
> The TPM burstcount and status commands are supposed to return very
> quickly [1][2]. This patch further reduces the TPM poll sleep time to usecs
> in get_burstcount() and wait_for_tpm_stat() by calling usleep_range()
> directly.
> 
> After this change, performance on a TPM 1.2 with an 8 byte burstcount for
> 1000 extends improved from ~10.7 sec to ~7 sec.
> 
> [1] From TCG Specification "TCG PC Client Specific TPM Interface
> Specification (TIS), Family 1.2":
> 
> "NOTE : It takes roughly 330 ns per byte transfer on LPC. 256 bytes would
> take 84 us, which is a long time to stall the CPU. Chipsets may not be
> designed to post this much data to LPC; therefore, the CPU itself is
> stalled for much of this time. Sending 1 kB would take 350 μs. Therefore,
> even if the TPM_STS_x.burstCount field is a high value, software SHOULD
> be interruptible during this period."
> 
> [2] From TCG Specification 2.0, "TCG PC Client Platform TPM Profile
> (PTP) Specification":
> 
> "It takes roughly 330 ns per byte transfer on LPC. 256 bytes would take
> 84 us. Chipsets may not be designed to post this much data to LPC;
> therefore, the CPU itself is stalled for much of this time. Sending 1 kB
> would take 350 us. Therefore, even if the TPM_STS_x.burstCount field is a
> high value, software should be interruptible during this period. For SPI,
> assuming 20MHz clock and 64-byte transfers, it would take about 120 usec
> to move 256B of data. Sending 1kB would take about 500 usec. If the
> transactions are done using 4 bytes at a time, then it would take about
> 1 msec. to transfer 1kB of data."
> 
> Signed-off-by: Nayna Jain 

Reviewed-by: Mimi Zohar 


> ---
>  drivers/char/tpm/tpm.h  | 4 +++-
>  drivers/char/tpm/tpm_tis_core.c | 5 +++--
>  2 files changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
> index 7e797377e1eb..f0e4d290c347 100644
> --- a/drivers/char/tpm/tpm.h
> +++ b/drivers/char/tpm/tpm.h
> @@ -54,7 +54,9 @@ enum tpm_timeout {
>   TPM_TIMEOUT = 5,/* msecs */
>   TPM_TIMEOUT_RETRY = 100, /* msecs */
>   TPM_TIMEOUT_RANGE_US = 300, /* usecs */
> - TPM_TIMEOUT_POLL = 1/* msecs */
> + TPM_TIMEOUT_POLL = 1,   /* msecs */
> + TPM_TIMEOUT_USECS_MIN = 100,  /* usecs */
> + TPM_TIMEOUT_USECS_MAX = 500  /* usecs */
>  };
> 
>  /* TPM addresses */
> diff --git a/drivers/char/tpm/tpm_tis_core.c b/drivers/char/tpm/tpm_tis_core.c
> index 021e6b68f2db..5bba5c662423 100644
> --- a/drivers/char/tpm/tpm_tis_core.c
> +++ b/drivers/char/tpm/tpm_tis_core.c
> @@ -84,7 +84,8 @@ static int wait_for_tpm_stat(struct tpm_chip *chip, u8 mask,
>   }
>   } else {
>   do {
> - tpm_msleep(TPM_TIMEOUT_POLL);
> + usleep_range(TPM_TIMEOUT_USECS_MIN,
> + TPM_TIMEOUT_USECS_MAX);
>   status = chip->ops->status(chip);
>   if ((status & mask) == mask)
>   return 0;
> @@ -226,7 +227,7 @@ static int get_burstcount(struct tpm_chip *chip)
>   burstcnt = (value >> 8) & 0x;
>   if (burstcnt)
>   return burstcnt;
> - tpm_msleep(TPM_TIMEOUT_POLL);
> + usleep_range(TPM_TIMEOUT_USECS_MIN, TPM_TIMEOUT_USECS_MAX);
>   } while (time_before(jiffies, stop));
>   return -EBUSY;
>  }

[PATCH] Input: xen-kbdfront - allow better run-time configuration

[Oleksandr Andrushchenko]

From: Oleksandr Andrushchenko 

It is now only possible to control if multi-touch virtual device
is created or not (via the corresponding XenStore entries),
but keyboard and pointer devices are always created.
In some cases this is not desirable. For example, if virtual
keyboard device is exposed to Android then the latter won't
automatically show on-screen keyboard as it expects that a
physical keyboard device can be used for typing.

Make it possible to configure which virtual devices are created
with module parameters:
  - no_ptr_dev=1 if no pointer device needs to be created
  - no_kbd_dev=1 if no keyboard device needs to be created
Keep old behavior by default.

Signed-off-by: Oleksandr Andrushchenko 
Suggested-by: Andrii Chepurnyi 
Tested-by: Andrii Chepurnyi 
---
 drivers/input/misc/xen-kbdfront.c | 159 +-
 1 file changed, 92 insertions(+), 67 deletions(-)

diff --git a/drivers/input/misc/xen-kbdfront.c 
b/drivers/input/misc/xen-kbdfront.c
index d91f3b1c5375..a3306aad40b0 100644
--- a/drivers/input/misc/xen-kbdfront.c
+++ b/drivers/input/misc/xen-kbdfront.c
@@ -51,6 +51,16 @@ module_param_array(ptr_size, int, NULL, 0444);
 MODULE_PARM_DESC(ptr_size,
"Pointing device width, height in pixels (default 800,600)");
 
+static unsigned int no_ptr_dev;
+module_param(no_ptr_dev, uint, 0);
+MODULE_PARM_DESC(no_ptr_dev,
+   "If set then no virtual pointing device exposed to the guest");
+
+static unsigned int no_kbd_dev;
+module_param(no_kbd_dev, uint, 0);
+MODULE_PARM_DESC(no_kbd_dev,
+   "If set then no virtual keyboard device exposed to the guest");
+
 static int xenkbd_remove(struct xenbus_device *);
 static int xenkbd_connect_backend(struct xenbus_device *, struct xenkbd_info 
*);
 static void xenkbd_disconnect_backend(struct xenkbd_info *);
@@ -63,6 +73,9 @@ static void xenkbd_disconnect_backend(struct xenkbd_info *);
 static void xenkbd_handle_motion_event(struct xenkbd_info *info,
   struct xenkbd_motion *motion)
 {
+   if (unlikely(!info->ptr))
+   return;
+
input_report_rel(info->ptr, REL_X, motion->rel_x);
input_report_rel(info->ptr, REL_Y, motion->rel_y);
if (motion->rel_z)
@@ -73,6 +86,9 @@ static void xenkbd_handle_motion_event(struct xenkbd_info 
*info,
 static void xenkbd_handle_position_event(struct xenkbd_info *info,
 struct xenkbd_position *pos)
 {
+   if (unlikely(!info->ptr))
+   return;
+
input_report_abs(info->ptr, ABS_X, pos->abs_x);
input_report_abs(info->ptr, ABS_Y, pos->abs_y);
if (pos->rel_z)
@@ -97,6 +113,9 @@ static void xenkbd_handle_key_event(struct xenkbd_info *info,
return;
}
 
+   if (unlikely(!dev))
+   return;
+
input_event(dev, EV_KEY, key->keycode, value);
input_sync(dev);
 }
@@ -192,7 +211,7 @@ static int xenkbd_probe(struct xenbus_device *dev,
  const struct xenbus_device_id *id)
 {
int ret, i;
-   unsigned int abs, touch;
+   unsigned int touch;
struct xenkbd_info *info;
struct input_dev *kbd, *ptr, *mtouch;
 
@@ -211,24 +230,6 @@ static int xenkbd_probe(struct xenbus_device *dev,
if (!info->page)
goto error_nomem;
 
-   /* Set input abs params to match backend screen res */
-   abs = xenbus_read_unsigned(dev->otherend,
-  XENKBD_FIELD_FEAT_ABS_POINTER, 0);
-   ptr_size[KPARAM_X] = xenbus_read_unsigned(dev->otherend,
- XENKBD_FIELD_WIDTH,
- ptr_size[KPARAM_X]);
-   ptr_size[KPARAM_Y] = xenbus_read_unsigned(dev->otherend,
- XENKBD_FIELD_HEIGHT,
- ptr_size[KPARAM_Y]);
-   if (abs) {
-   ret = xenbus_write(XBT_NIL, dev->nodename,
-  XENKBD_FIELD_REQ_ABS_POINTER, "1");
-   if (ret) {
-   pr_warn("xenkbd: can't request abs-pointer\n");
-   abs = 0;
-   }
-   }
-
touch = xenbus_read_unsigned(dev->nodename,
 XENKBD_FIELD_FEAT_MTOUCH, 0);
if (touch) {
@@ -241,60 +242,84 @@ static int xenkbd_probe(struct xenbus_device *dev,
}
 
/* keyboard */
-   kbd = input_allocate_device();
-   if (!kbd)
-   goto error_nomem;
-   kbd->name = "Xen Virtual Keyboard";
-   kbd->phys = info->phys;
-   kbd->id.bustype = BUS_PCI;
-   kbd->id.vendor = 0x5853;
-   kbd->id.product = 0x;
-
-   __set_bit(EV_KEY, kbd->evbit);
-   for (i = KEY_ESC; i < KEY_UNKNOWN; i++)
-  

Re: [PATCH] SLUB: Do not fallback to mininum order if __GFP_NORETRY is set

[Mikulas Patocka]

On Wed, 18 Apr 2018, Christopher Lameter wrote:

> Mikulas Patoka wants to ensure that no fallback to lower order happens. I
> think __GFP_NORETRY should work correctly in that case too and not fall
> back.
> 
> 
> 
> Allocating at a smaller order is a retry operation and should not
> be attempted.
> 
> If the caller does not want retries then respect that.
> 
> GFP_NORETRY allows callers to ensure that only maximum order
> allocations are attempted.
> 
> Signed-off-by: Christoph Lameter 
> 
> Index: linux/mm/slub.c
> ===
> --- linux.orig/mm/slub.c
> +++ linux/mm/slub.c
> @@ -1598,7 +1598,7 @@ static struct page *allocate_slab(struct
>   alloc_gfp = (alloc_gfp | __GFP_NOMEMALLOC) & 
> ~(__GFP_RECLAIM|__GFP_NOFAIL);
> 
>   page = alloc_slab_page(s, alloc_gfp, node, oo);
> - if (unlikely(!page)) {
> + if (unlikely(!page) && !(flags & __GFP_NORETRY)) {
>   oo = s->min;
>   alloc_gfp = flags;
>   /*

No, this would hit NULL pointer dereference if page is NULL and 
__GFP_NORETRY is set. You want this:

---
 mm/slub.c |2 ++
 1 file changed, 2 insertions(+)

Index: linux-2.6/mm/slub.c
===
--- linux-2.6.orig/mm/slub.c2018-04-17 20:58:23.0 +0200
+++ linux-2.6/mm/slub.c 2018-04-18 17:04:01.0 +0200
@@ -1599,6 +1599,8 @@ static struct page *allocate_slab(struct
 
page = alloc_slab_page(s, alloc_gfp, node, oo);
if (unlikely(!page)) {
+   if (flags & __GFP_NORETRY)
+   goto out;
oo = s->min;
alloc_gfp = flags;
/*

Re: [PATCH net-next v4 0/3] kernel: add support to collect hardware logs in crash recovery kernel

[Rahul Lakkireddy]

On Wednesday, April 04/18/18, 2018 at 19:58:01 +0530, Eric W. Biederman wrote:
> Rahul Lakkireddy  writes:
> 
> > On Wednesday, April 04/18/18, 2018 at 11:45:46 +0530, Dave Young wrote:
> >> Hi Rahul,
> >> On 04/17/18 at 01:14pm, Rahul Lakkireddy wrote:
> >> > On production servers running variety of workloads over time, kernel
> >> > panic can happen sporadically after days or even months. It is
> >> > important to collect as much debug logs as possible to root cause
> >> > and fix the problem, that may not be easy to reproduce. Snapshot of
> >> > underlying hardware/firmware state (like register dump, firmware
> >> > logs, adapter memory, etc.), at the time of kernel panic will be very
> >> > helpful while debugging the culprit device driver.
> >> > 
> >> > This series of patches add new generic framework that enable device
> >> > drivers to collect device specific snapshot of the hardware/firmware
> >> > state of the underlying device in the crash recovery kernel. In crash
> >> > recovery kernel, the collected logs are added as elf notes to
> >> > /proc/vmcore, which is copied by user space scripts for post-analysis.
> >> > 
> >> > The sequence of actions done by device drivers to append their device
> >> > specific hardware/firmware logs to /proc/vmcore are as follows:
> >> > 
> >> > 1. During probe (before hardware is initialized), device drivers
> >> > register to the vmcore module (via vmcore_add_device_dump()), with
> >> > callback function, along with buffer size and log name needed for
> >> > firmware/hardware log collection.
> >> 
> >> I assumed the elf notes info should be prepared while kexec_[file_]load
> >> phase. But I did not read the old comment, not sure if it has been 
> >> discussed
> >> or not.
> >> 
> >
> > We must not collect dumps in crashing kernel. Adding more things in
> > crash dump path risks not collecting vmcore at all. Eric had
> > discussed this in more detail at:
> >
> > https://lkml.org/lkml/2018/3/24/319
> >
> > We are safe to collect dumps in the second kernel. Each device dump
> > will be exported as an elf note in /proc/vmcore.
> 
> It just occurred to me there is one variation that is worth
> considering.
> 
> Is the area you are looking at dumping part of a huge mmio area?
> I think someone said 2GB?
> 
> If that is the case it could be worth it to simply add the needed
> addresses to the range of memory we need to dump, and simply having a
> elf note saying that is what happened.
> 

We are _not_ dumping mmio area. However, one part of the dump
collection involves reading 2 GB on-chip memory via PIO access,
which is compressed and stored.

Thanks,
Rahul

Re: [PATCH] powerpc: Allow selection of CONFIG_LD_DEAD_CODE_DATA_ELIMINATION

[Michael Ellerman]

Mathieu Malaterre  writes:
> On Wed, Apr 18, 2018 at 8:34 AM, Christophe LEROY
...
>
>> Can you also provide a copy of the messages you can see (prom_init ...) when
>> boot is ok ?
>
> Hum. I've always been interested in seeing it also myself. Is there a
> way to setup env to see those message (netconsole, delayed boot
> messages ...) ? I never found a clear documentation on how to do that
> on (closed) Apple hardware.

If you see nothing after prom_init it usually indicates the kernel died
very early in boot before it could find the console.

The only option then is to enable one of the hard-coded EARLY_DEBUG
options.

I don't know which one works on a G4, maybe CONFIG_PPC_EARLY_DEBUG_BOOTX ?

I assume it doesn't have a serial port.

cheers

[PATCH net-next 1/2] netns: restrict uevents

[Christian Brauner]

commit 07e98962fa77 ("kobject: Send hotplug events in all network namespaces")

enabled sending hotplug events into all network namespaces back in 2010.
Over time the set of uevents that get sent into all network namespaces has
shrunk a little. We have now reached the point where hotplug events for all
devices that carry a namespace tag are filtered according to that
namespace. Specifically, they are filtered whenever the namespace tag of
the kobject does not match the namespace tag of the netlink socket. One
example are network devices. Uevents for network devices only show up in
the network namespaces these devices are moved to or created in.

However, any uevent for a kobject that does not have a namespace tag
associated with it will not be filtered and we will broadcast it into all
network namespaces. This behavior stopped making sense when user namespaces
were introduced.

This patch restricts uevents to the initial user namespace for a couple of
reasons that have been extensively discusses on the mailing list [1].
- Thundering herd:
  Broadcasting uevents into all network namespaces introduces significant
  overhead.
  All processes that listen to uevents running in non-initial user
  namespaces will end up responding to uevents that will be meaningless to
  them. Mainly, because non-initial user namespaces cannot easily manage
  devices unless they have a privileged host-process helping them out. This
  means that there will be a thundering herd of activity when there
  shouldn't be any.
- Uevents from non-root users are already filtered in userspace:
  Uevents are filtered by userspace in a user namespace because the
  received uid != 0. Instead the uid associated with the event will be
  65534 == "nobody" because the global root uid is not mapped.
  This means we can safely and without introducing regressions modify the
  kernel to not send uevents into all network namespaces whose owning user
  namespace is not the initial user namespace because we know that
  userspace will ignore the message because of the uid anyway. I have
  a) verified that is is true for every udev implementation out there b)
  that this behavior has been present in all udev implementations from the
  very beginning.
- Removing needless overhead/Increasing performance:
  Currently, the uevent socket for each network namespace is added to the
  global variable uevent_sock_list. The list itself needs to be protected
  by a mutex. So everytime a uevent is generated the mutex is taken on the
  list. The mutex is held *from the creation of the uevent (memory
  allocation, string creation etc. until all uevent sockets have been
  handled*. This is aggravated by the fact that for each uevent socket that
  has listeners the mc_list must be walked as well which means we're
  talking O(n^2) here. Given that a standard Linux workload usually has
  quite a lot of network namespaces and - in the face of containers - a lot
  of user namespaces this quickly becomes a performance problem (see
  "Thundering herd" above). By just recording uevent sockets of network
  namespaces that are owned by the initial user namespace we significantly
  increase performance in this codepath.
- Injecting uevents:
  There's a valid argument that containers might be interested in receiving
  device events especially if they are delegated to them by a privileged
  userspace process. One prime example are SR-IOV enabled devices that are
  explicitly designed to be handed of to other users such as VMs or
  containers.
  This use-case can now be correctly handled since
  commit 692ec06d7c92 ("netns: send uevent messages"). This commit
  introduced the ability to send uevents from userspace. As such we can let
  a sufficiently privileged (CAP_SYS_ADMIN in the owning user namespace of
  the network namespace of the netlink socket) userspace process make a
  decision what uevents should be sent. This removes the need to blindly
  broadcast uevents into all user namespaces and provides a performant and
  safe solution to this problem.
- Filtering logic:
  This patch filters by *owning user namespace of the network namespace a
  given task resides in* and not by user namespace of the task per se. This
  means if the user namespace of a given task is unshared but the network
  namespace is kept and is owned by the initial user namespace a listener
  that is opening the uevent socket in that network namespace can still
  listen to uevents.

[1]: https://lkml.org/lkml/2018/4/4/739
Signed-off-by: Christian Brauner 
---
 lib/kobject_uevent.c | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/lib/kobject_uevent.c b/lib/kobject_uevent.c
index 15ea216a67ce..f5f5038787ac 100644
--- a/lib/kobject_uevent.c
+++ b/lib/kobject_uevent.c
@@ -703,9 +703,13 @@ static int uevent_net_init(struct net *net)
 
net->uevent_sock = ue_sk;
 
-   mutex_lock(_sock_mutex);
-   list_add_tail(_sk->list, 

[PATCH v5 18/23] ASoC: qdsp6: q6routing: Add support to MI2S Mixers

[srinivas . kandagatla]

From: Srinivas Kandagatla 

This patch add support to MI2S mixers required to select path between
ASM stream and AFE ports.

Signed-off-by: Srinivas Kandagatla 
Reviewed-and-tested-by: Rohit kumar 
---
 sound/soc/qcom/qdsp6/q6routing.c | 329 +++
 1 file changed, 329 insertions(+)

diff --git a/sound/soc/qcom/qdsp6/q6routing.c b/sound/soc/qcom/qdsp6/q6routing.c
index c6be775167b8..710c2ae652c7 100644
--- a/sound/soc/qcom/qdsp6/q6routing.c
+++ b/sound/soc/qcom/qdsp6/q6routing.c
@@ -232,6 +232,103 @@ static const struct snd_kcontrol_new 
hdmi_mixer_controls[] = {
   msm_routing_put_audio_mixer),
 };
 
+static const struct snd_kcontrol_new primary_mi2s_rx_mixer_controls[] = {
+   SOC_SINGLE_EXT("MultiMedia1", PRIMARY_MI2S_RX,
+   MSM_FRONTEND_DAI_MULTIMEDIA1, 1, 0, msm_routing_get_audio_mixer,
+   msm_routing_put_audio_mixer),
+   SOC_SINGLE_EXT("MultiMedia2", PRIMARY_MI2S_RX,
+   MSM_FRONTEND_DAI_MULTIMEDIA2, 1, 0, msm_routing_get_audio_mixer,
+   msm_routing_put_audio_mixer),
+   SOC_SINGLE_EXT("MultiMedia3", PRIMARY_MI2S_RX,
+   MSM_FRONTEND_DAI_MULTIMEDIA3, 1, 0, msm_routing_get_audio_mixer,
+   msm_routing_put_audio_mixer),
+   SOC_SINGLE_EXT("MultiMedia4", PRIMARY_MI2S_RX,
+   MSM_FRONTEND_DAI_MULTIMEDIA4, 1, 0, msm_routing_get_audio_mixer,
+   msm_routing_put_audio_mixer),
+   SOC_SINGLE_EXT("MultiMedia5", PRIMARY_MI2S_RX,
+   MSM_FRONTEND_DAI_MULTIMEDIA5, 1, 0, msm_routing_get_audio_mixer,
+   msm_routing_put_audio_mixer),
+   SOC_SINGLE_EXT("MultiMedia6", PRIMARY_MI2S_RX,
+   MSM_FRONTEND_DAI_MULTIMEDIA6, 1, 0, msm_routing_get_audio_mixer,
+   msm_routing_put_audio_mixer),
+   SOC_SINGLE_EXT("MultiMedia7", PRIMARY_MI2S_RX,
+   MSM_FRONTEND_DAI_MULTIMEDIA7, 1, 0, msm_routing_get_audio_mixer,
+   msm_routing_put_audio_mixer),
+   SOC_SINGLE_EXT("MultiMedia8", PRIMARY_MI2S_RX,
+   MSM_FRONTEND_DAI_MULTIMEDIA8, 1, 0, msm_routing_get_audio_mixer,
+   msm_routing_put_audio_mixer),
+};
+
+static const struct snd_kcontrol_new secondary_mi2s_rx_mixer_controls[] = {
+   SOC_SINGLE_EXT("MultiMedia1", SECONDARY_MI2S_RX,
+   MSM_FRONTEND_DAI_MULTIMEDIA1, 1, 0, msm_routing_get_audio_mixer,
+   msm_routing_put_audio_mixer),
+   SOC_SINGLE_EXT("MultiMedia2", SECONDARY_MI2S_RX,
+   MSM_FRONTEND_DAI_MULTIMEDIA2, 1, 0, msm_routing_get_audio_mixer,
+   msm_routing_put_audio_mixer),
+   SOC_SINGLE_EXT("MultiMedia3", SECONDARY_MI2S_RX,
+   MSM_FRONTEND_DAI_MULTIMEDIA3, 1, 0, msm_routing_get_audio_mixer,
+   msm_routing_put_audio_mixer),
+   SOC_SINGLE_EXT("MultiMedia4", SECONDARY_MI2S_RX,
+   MSM_FRONTEND_DAI_MULTIMEDIA4, 1, 0, msm_routing_get_audio_mixer,
+   msm_routing_put_audio_mixer),
+   SOC_SINGLE_EXT("MultiMedia5", SECONDARY_MI2S_RX,
+   MSM_FRONTEND_DAI_MULTIMEDIA5, 1, 0, msm_routing_get_audio_mixer,
+   msm_routing_put_audio_mixer),
+   SOC_SINGLE_EXT("MultiMedia6", SECONDARY_MI2S_RX,
+   MSM_FRONTEND_DAI_MULTIMEDIA6, 1, 0, msm_routing_get_audio_mixer,
+   msm_routing_put_audio_mixer),
+   SOC_SINGLE_EXT("MultiMedia7", SECONDARY_MI2S_RX,
+   MSM_FRONTEND_DAI_MULTIMEDIA7, 1, 0, msm_routing_get_audio_mixer,
+   msm_routing_put_audio_mixer),
+   SOC_SINGLE_EXT("MultiMedia8", SECONDARY_MI2S_RX,
+   MSM_FRONTEND_DAI_MULTIMEDIA8, 1, 0, msm_routing_get_audio_mixer,
+   msm_routing_put_audio_mixer),
+};
+
+static const struct snd_kcontrol_new quaternary_mi2s_rx_mixer_controls[] = {
+   SOC_SINGLE_EXT("MultiMedia1", QUATERNARY_MI2S_RX,
+   MSM_FRONTEND_DAI_MULTIMEDIA1, 1, 0, msm_routing_get_audio_mixer,
+   msm_routing_put_audio_mixer),
+   SOC_SINGLE_EXT("MultiMedia2", QUATERNARY_MI2S_RX,
+   MSM_FRONTEND_DAI_MULTIMEDIA2, 1, 0, msm_routing_get_audio_mixer,
+   msm_routing_put_audio_mixer),
+   SOC_SINGLE_EXT("MultiMedia3", QUATERNARY_MI2S_RX,
+   MSM_FRONTEND_DAI_MULTIMEDIA3, 1, 0, msm_routing_get_audio_mixer,
+   msm_routing_put_audio_mixer),
+   SOC_SINGLE_EXT("MultiMedia4", QUATERNARY_MI2S_RX,
+   MSM_FRONTEND_DAI_MULTIMEDIA4, 1, 0, msm_routing_get_audio_mixer,
+   msm_routing_put_audio_mixer),
+   SOC_SINGLE_EXT("MultiMedia5", QUATERNARY_MI2S_RX,
+   MSM_FRONTEND_DAI_MULTIMEDIA5, 1, 0, msm_routing_get_audio_mixer,
+   msm_routing_put_audio_mixer),
+   SOC_SINGLE_EXT("MultiMedia6", QUATERNARY_MI2S_RX,
+   MSM_FRONTEND_DAI_MULTIMEDIA6, 1, 0, msm_routing_get_audio_mixer,
+   msm_routing_put_audio_mixer),
+   SOC_SINGLE_EXT("MultiMedia7", QUATERNARY_MI2S_RX,
+   MSM_FRONTEND_DAI_MULTIMEDIA7, 1, 0, msm_routing_get_audio_mixer,
+   msm_routing_put_audio_mixer),
+   SOC_SINGLE_EXT("MultiMedia8", QUATERNARY_MI2S_RX,
+   MSM_FRONTEND_DAI_MULTIMEDIA8, 1, 0, msm_routing_get_audio_mixer,
+   

Re: [PATCH 4.9 00/66] 4.9.95-stable review

[Guenter Roeck]

On Tue, Apr 17, 2018 at 05:58:33PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.95 release.
> There are 66 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 Apr 19 15:56:27 UTC 2018.
> Anything received after that time might be too late.
> 

Build results:
total: 145 pass: 145 fail: 0
Qemu test results:
total: 137 pass: 137 fail: 0

Details are available at http://kerneltests.org/builders.

Guenter

[PATCH v5 17/23] ASoC: qdsp6: q6routing: Add support to all SLIMBus Mixers

[srinivas . kandagatla]

From: Srinivas Kandagatla 

This patch adds support to SLIMBus related mixers to control mux between
ASM stream and AFE port.

Signed-off-by: Srinivas Kandagatla 
Reviewed-and-tested-by: Rohit kumar 
---
 sound/soc/qcom/qdsp6/q6routing.c | 261 +++
 1 file changed, 261 insertions(+)

diff --git a/sound/soc/qcom/qdsp6/q6routing.c b/sound/soc/qcom/qdsp6/q6routing.c
index b72bd9045fea..c6be775167b8 100644
--- a/sound/soc/qcom/qdsp6/q6routing.c
+++ b/sound/soc/qcom/qdsp6/q6routing.c
@@ -232,6 +232,180 @@ static const struct snd_kcontrol_new 
hdmi_mixer_controls[] = {
   msm_routing_put_audio_mixer),
 };
 
+static const struct snd_kcontrol_new slimbus_rx_mixer_controls[] = {
+   SOC_SINGLE_EXT("MultiMedia1", SLIMBUS_0_RX,
+   MSM_FRONTEND_DAI_MULTIMEDIA1, 1, 0, msm_routing_get_audio_mixer,
+   msm_routing_put_audio_mixer),
+   SOC_SINGLE_EXT("MultiMedia2", SLIMBUS_0_RX,
+   MSM_FRONTEND_DAI_MULTIMEDIA2, 1, 0, msm_routing_get_audio_mixer,
+   msm_routing_put_audio_mixer),
+   SOC_SINGLE_EXT("MultiMedia3", SLIMBUS_0_RX,
+   MSM_FRONTEND_DAI_MULTIMEDIA3, 1, 0, msm_routing_get_audio_mixer,
+   msm_routing_put_audio_mixer),
+   SOC_SINGLE_EXT("MultiMedia4", SLIMBUS_0_RX,
+   MSM_FRONTEND_DAI_MULTIMEDIA4, 1, 0, msm_routing_get_audio_mixer,
+   msm_routing_put_audio_mixer),
+   SOC_SINGLE_EXT("MultiMedia5", SLIMBUS_0_RX,
+   MSM_FRONTEND_DAI_MULTIMEDIA5, 1, 0, msm_routing_get_audio_mixer,
+   msm_routing_put_audio_mixer),
+   SOC_SINGLE_EXT("MultiMedia6", SLIMBUS_0_RX,
+   MSM_FRONTEND_DAI_MULTIMEDIA6, 1, 0, msm_routing_get_audio_mixer,
+   msm_routing_put_audio_mixer),
+   SOC_SINGLE_EXT("MultiMedia7", SLIMBUS_0_RX,
+   MSM_FRONTEND_DAI_MULTIMEDIA7, 1, 0, msm_routing_get_audio_mixer,
+   msm_routing_put_audio_mixer),
+   SOC_SINGLE_EXT("MultiMedia8", SLIMBUS_0_RX,
+   MSM_FRONTEND_DAI_MULTIMEDIA8, 1, 0, msm_routing_get_audio_mixer,
+   msm_routing_put_audio_mixer),
+};
+
+static const struct snd_kcontrol_new slimbus_1_rx_mixer_controls[] = {
+   SOC_SINGLE_EXT("MultiMedia1", SLIMBUS_1_RX,
+   MSM_FRONTEND_DAI_MULTIMEDIA1, 1, 0, msm_routing_get_audio_mixer,
+   msm_routing_put_audio_mixer),
+   SOC_SINGLE_EXT("MultiMedia2", SLIMBUS_1_RX,
+   MSM_FRONTEND_DAI_MULTIMEDIA2, 1, 0, msm_routing_get_audio_mixer,
+   msm_routing_put_audio_mixer),
+   SOC_SINGLE_EXT("MultiMedia3", SLIMBUS_1_RX,
+   MSM_FRONTEND_DAI_MULTIMEDIA3, 1, 0, msm_routing_get_audio_mixer,
+   msm_routing_put_audio_mixer),
+   SOC_SINGLE_EXT("MultiMedia4", SLIMBUS_1_RX,
+   MSM_FRONTEND_DAI_MULTIMEDIA4, 1, 0, msm_routing_get_audio_mixer,
+   msm_routing_put_audio_mixer),
+   SOC_SINGLE_EXT("MultiMedia5", SLIMBUS_1_RX,
+   MSM_FRONTEND_DAI_MULTIMEDIA5, 1, 0, msm_routing_get_audio_mixer,
+   msm_routing_put_audio_mixer),
+   SOC_SINGLE_EXT("MultiMedia6", SLIMBUS_1_RX,
+   MSM_FRONTEND_DAI_MULTIMEDIA6, 1, 0, msm_routing_get_audio_mixer,
+   msm_routing_put_audio_mixer),
+   SOC_SINGLE_EXT("MultiMedia7", SLIMBUS_1_RX,
+   MSM_FRONTEND_DAI_MULTIMEDIA7, 1, 0, msm_routing_get_audio_mixer,
+   msm_routing_put_audio_mixer),
+   SOC_SINGLE_EXT("MultiMedia8", SLIMBUS_1_RX,
+   MSM_FRONTEND_DAI_MULTIMEDIA8, 1, 0, msm_routing_get_audio_mixer,
+   msm_routing_put_audio_mixer),
+};
+
+static const struct snd_kcontrol_new slimbus_2_rx_mixer_controls[] = {
+   SOC_SINGLE_EXT("MultiMedia1", SLIMBUS_2_RX,
+   MSM_FRONTEND_DAI_MULTIMEDIA1, 1, 0, msm_routing_get_audio_mixer,
+   msm_routing_put_audio_mixer),
+   SOC_SINGLE_EXT("MultiMedia2", SLIMBUS_2_RX,
+   MSM_FRONTEND_DAI_MULTIMEDIA2, 1, 0, msm_routing_get_audio_mixer,
+   msm_routing_put_audio_mixer),
+   SOC_SINGLE_EXT("MultiMedia3", SLIMBUS_2_RX,
+   MSM_FRONTEND_DAI_MULTIMEDIA3, 1, 0, msm_routing_get_audio_mixer,
+   msm_routing_put_audio_mixer),
+   SOC_SINGLE_EXT("MultiMedia4", SLIMBUS_2_RX,
+   MSM_FRONTEND_DAI_MULTIMEDIA4, 1, 0, msm_routing_get_audio_mixer,
+   msm_routing_put_audio_mixer),
+   SOC_SINGLE_EXT("MultiMedia5", SLIMBUS_2_RX,
+   MSM_FRONTEND_DAI_MULTIMEDIA5, 1, 0, msm_routing_get_audio_mixer,
+   msm_routing_put_audio_mixer),
+   SOC_SINGLE_EXT("MultiMedia6", SLIMBUS_2_RX,
+   MSM_FRONTEND_DAI_MULTIMEDIA6, 1, 0, msm_routing_get_audio_mixer,
+   msm_routing_put_audio_mixer),
+   SOC_SINGLE_EXT("MultiMedia7", SLIMBUS_2_RX,
+   MSM_FRONTEND_DAI_MULTIMEDIA7, 1, 0, msm_routing_get_audio_mixer,
+   msm_routing_put_audio_mixer),
+   SOC_SINGLE_EXT("MultiMedia8", SLIMBUS_2_RX,
+   MSM_FRONTEND_DAI_MULTIMEDIA8, 1, 0, msm_routing_get_audio_mixer,
+   msm_routing_put_audio_mixer),
+};
+
+static const struct snd_kcontrol_new slimbus_3_rx_mixer_controls[] = {
+   

Re: [PATCH 4.14 00/49] 4.14.35-stable review

[Guenter Roeck]

On Tue, Apr 17, 2018 at 05:58:39PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.35 release.
> There are 49 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 Apr 19 15:56:59 UTC 2018.
> Anything received after that time might be too late.
> 

Build results:
total: 145 pass: 145 fail: 0
Qemu test results:
total: 141 pass: 141 fail: 0

Details are available at http://kerneltests.org/builders.

Guenter

Re: [PATCH 4.15 00/53] 4.15.18-stable review

[Guenter Roeck]

On Tue, Apr 17, 2018 at 05:58:25PM +0200, Greg Kroah-Hartman wrote:
> 
> NOTE, this is the last expected 4.15.y release.  After this one, the
> tree is end-of-life.  Please move to 4.16.y at this point in time.
> 
> 
> This is the start of the stable review cycle for the 4.15.18 release.
> There are 53 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 Apr 19 15:57:06 UTC 2018.
> Anything received after that time might be too late.
> 
Build results:
total: 147 pass: 147 fail: 0
Qemu test results:
total: 141 pass: 141 fail: 0

Details are available at http://kerneltests.org/builders.

Guenter

Re: [GIT PULL V3] Thermal SoC management updates for v4.17-rc1

[Eduardo Valentin]

Hello,

On Wed, Apr 18, 2018 at 03:51:29PM +0800, Zhang Rui wrote:
> Hi, Eduardo,
> 
> On 六, 2018-04-14 at 11:30 -0700, Eduardo Valentin wrote:
> > Hello Linus,
> > 
> > Please find thermal-soc changes for v4.17-rc1.
> > Rui asked me to send the pull request directly to you
> > as we are close to the end of the merge window.
> > Essentially this pull removes the series that caused
> > warning regression. I will work with the developer
> > to get that fixed later on, but I am still sending
> > the other few patches that are unrelated to that.
> > Let me know if this causes any issues and can still
> > be pulled.
> > 
> > Changelog:
> > - New i.MX7 thermal sensor
> > - Mediatek driver now supports MT7622 SoC
> > - Removal of min max cpu cooling DT property
> > 
> > Differences in V3:
> > - Rebased on top current linus/master, to avoid and merge issues
> > from previous pulled thermal code.
> > 
> > Differences in V2:
> > - Reordered the patches to drop exynos changes for now until we get
> > agreement on the fix on that driver for the compilation warns
> > caused by the confusing conversion functions.
> > 
> > 
> > The following changes since commit
> > 48023102b7078a6674516b1fe0d639669336049d:
> > 
> >   Merge branch 'overlayfs-linus' of
> > git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs (2018-04-
> > 13 16:55:41 -0700)
> > 
> > are available in the git repository at:
> > 
> >   git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-
> > thermal linus
> > 
> > for you to fetch changes up to
> > 15a32df1918259be6c23fc36014fc26ee66c836c:
> > 
> >   dt-bindings: thermal: Remove "cooling-{min|max}-level" properties
> > (2018-04-14 09:37:55 -0700)
> > 
> This pull request does not catch this merge window.
> So do you want to split it into 2 separate pull requests, one for 4.17-
> rc and another for 4.18-rc1?

OK. Yeah, I am fine with that.

> 
> > 
> > Anson Huang (1):
> >   thermal: imx: add i.MX7 thermal sensor support
> > 
> > Bartlomiej Zolnierkiewicz (1):
> >   dt-bindings: thermal: remove no longer needed samsung thermal
> > properties
> > 
> > Sean Wang (2):
> >   dt-bindings: thermal: add binding for MT7622 SoC
> >   thermal: mediatek: add support for MT7622 SoC
> > 
> > Viresh Kumar (1):
> >   dt-bindings: thermal: Remove "cooling-{min|max}-level"
> > properties
> > 
> IMO, together with the refreshed exynos fixes, the one from Viresh and
> the one from Bartlomiej can be queued for 4.17-rc, and the others have
> to wait until next merge window.
> 

Correct, the new chip support will need to wait for the next merge
window. I have already split the patches into the two categories.
The patches removing stuff are in my -fixes branch. All the other adding
new chip support are in my -linus branch.

Now, Do you have anything for this -rc2 ? If not, I will send directly
to Linus the stuff in my -fixes branch. Let me know.

Eduardo

[PATCH] kasan: modify the exception handling if kmalloc or krealloc return NULL

[jingwei . liuxi]

From: Victor Liu 

Both kmalloc and krealloc may return NULL(!ptr1 || !ptr2), and we do not
know which one is.

Signed-off-by: Victor Liu 
---
 lib/test_kasan.c | 25 ++---
 1 file changed, 18 insertions(+), 7 deletions(-)

diff --git a/lib/test_kasan.c b/lib/test_kasan.c
index ec65710..afa10bf 100644
--- a/lib/test_kasan.c
+++ b/lib/test_kasan.c
@@ -153,9 +153,13 @@ static noinline void __init kmalloc_oob_krealloc_more(void)
 
pr_info("out-of-bounds after krealloc more\n");
ptr1 = kmalloc(size1, GFP_KERNEL);
+   if (!ptr1) {
+   pr_err("Allocation ptr1 failed\n");
+   return;
+   }
ptr2 = krealloc(ptr1, size2, GFP_KERNEL);
-   if (!ptr1 || !ptr2) {
-   pr_err("Allocation failed\n");
+   if (!ptr2) {
+   pr_err("Allocation ptr2 failed\n");
kfree(ptr1);
return;
}
@@ -172,9 +176,13 @@ static noinline void __init kmalloc_oob_krealloc_less(void)
 
pr_info("out-of-bounds after krealloc less\n");
ptr1 = kmalloc(size1, GFP_KERNEL);
+   if (!ptr1) {
+   pr_err("Allocation ptr1 failed\n");
+   return;
+   }
ptr2 = krealloc(ptr1, size2, GFP_KERNEL);
-   if (!ptr1 || !ptr2) {
-   pr_err("Allocation failed\n");
+   if (!ptr2) {
+   pr_err("Allocation ptr2 failed\n");
kfree(ptr1);
return;
}
@@ -190,11 +198,14 @@ static noinline void __init kmalloc_oob_16(void)
 
pr_info("kmalloc out-of-bounds for 16-bytes access\n");
ptr1 = kmalloc(sizeof(*ptr1) - 3, GFP_KERNEL);
+   if (!ptr1) {
+   pr_err("Allocation ptr1 failed\n");
+   return;
+   }
ptr2 = kmalloc(sizeof(*ptr2), GFP_KERNEL);
-   if (!ptr1 || !ptr2) {
-   pr_err("Allocation failed\n");
+   if (!ptr2) {
+   pr_err("Allocation ptr2 failed\n");
kfree(ptr1);
-   kfree(ptr2);
return;
}
*ptr1 = *ptr2;
-- 
2.7.4

Re: [PATCH v2 01/12] mm: Assign id to every memcg-aware shrinker

[Tetsuo Handa]

Kirill Tkhai wrote:
> The patch introduces shrinker::id number, which is used to enumerate
> memcg-aware shrinkers. The number start from 0, and the code tries
> to maintain it as small as possible.
> 
> This will be used as to represent a memcg-aware shrinkers in memcg
> shrinkers map.

I'm not reading this thread. But is there reason "id" needs to be managed
using smallest numbers? Can't we use address of shrinker object as "id"
(which will be sparse bitmap, and would be managed using linked list for now)?

Re: [PATCH 1/2] tracing: fix bad use of igrab in trace_uprobe.c

[Steven Rostedt]

On Wed, 18 Apr 2018 16:03:42 +0200
Miklos Szeredi  wrote:

> > @@ -937,7 +928,8 @@ probe_event_enable(struct trace_uprobe *tu, struct 
> > trace_event_file *file,
> > goto err_flags;
> >
> > tu->consumer.filter = filter;
> > -   ret = uprobe_register(tu->inode, tu->offset, >consumer);
> > +   ret = uprobe_register(d_inode(tu->path.dentry), tu->offset,
> > + >consumer);  
> 
> It is not entirely clear how the lifetime of uprobe relates to the
> lifetime of trace_uprobe.  Is the uprobe object never going to survive
> its creator trace_uprobe object?

Not exactly sure what you mean here.

The trace_uprobe (the probe event) is created, it doesn't do anything
until it is enabled. This function is called when it is enabled. The
trace_uprobe (probe event) can not be deleted while it is enabled
(EBUSY).

Are you asking what happens if the file is deleted while it has probe?
That I don't know about (haven't tried it out). But I would hope that
it keeps a reference to the inode, isn't that what the igrab is for?
And is now being replaced by a reference on the path, or is that the
problem?

-- Steve


> 
> If that's the case, it warrants a comment.  If that's not the case,
> then the path would need to be passed to uprobe_resister() which would
> need to obtain its own reference.
> 
> > if (ret)
> > goto err_buffer;
> >

Re: [patch v2] mm, oom: fix concurrent munlock and oom reaper unmap

[Tetsuo Handa]

Michal Hocko wrote:
> > > > Then, I'm tempted to call __oom_reap_task_mm() before holding mmap_sem 
> > > > for write.
> > > > It would be OK to call __oom_reap_task_mm() at the beginning of 
> > > > __mmput()...
> > > 
> > > I am not sure I understand.
> > 
> > To reduce possibility of __oom_reap_task_mm() giving up reclaim and
> > setting MMF_OOM_SKIP.
> 
> Still do not understand. Do you want to call __oom_reap_task_mm from
> __mmput?

Yes.

>  If yes why would you do so when exit_mmap does a stronger
> version of it?

Because memory which can be reclaimed by the OOM reaper is guaranteed
to be reclaimed before setting MMF_OOM_SKIP when the OOM reaper and
exit_mmap() contended, because the OOM reaper (weak reclaim) sets
MMF_OOM_SKIP after one second for safety in case of exit_mmap()
(strong reclaim) failing to make forward progress.

Re: usercopy whitelist woe in scsi_sense_cache

[Jens Axboe]

On 4/18/18 3:08 AM, Paolo Valente wrote:
> 
> 
>> Il giorno 18 apr 2018, alle ore 00:57, Jens Axboe  ha 
>> scritto:
>>
>> On 4/17/18 3:48 PM, Jens Axboe wrote:
>>> On 4/17/18 3:47 PM, Kees Cook wrote:
 On Tue, Apr 17, 2018 at 2:39 PM, Jens Axboe  wrote:
> On 4/17/18 3:25 PM, Kees Cook wrote:
>> On Tue, Apr 17, 2018 at 1:46 PM, Kees Cook  wrote:
>>> I see elv.priv[1] assignments made in a few places -- is it possible
>>> there is some kind of uninitialized-but-not-NULL state that can leak
>>> in there?
>>
>> Got it. This fixes it for me:
>>
>> diff --git a/block/blk-mq.c b/block/blk-mq.c
>> index 0dc9e341c2a7..859df3160303 100644
>> --- a/block/blk-mq.c
>> +++ b/block/blk-mq.c
>> @@ -363,7 +363,7 @@ static struct request *blk_mq_get_request(struct
>> request_queue *q,
>>
>>rq = blk_mq_rq_ctx_init(data, tag, op);
>>if (!op_is_flush(op)) {
>> -   rq->elv.icq = NULL;
>> +   memset(>elv, 0, sizeof(rq->elv));
>>if (e && e->type->ops.mq.prepare_request) {
>>if (e->type->icq_cache && rq_ioc(bio))
>>blk_mq_sched_assign_ioc(rq, bio);
>> @@ -461,7 +461,7 @@ void blk_mq_free_request(struct request *rq)
>>e->type->ops.mq.finish_request(rq);
>>if (rq->elv.icq) {
>>put_io_context(rq->elv.icq->ioc);
>> -   rq->elv.icq = NULL;
>> +   memset(>elv, 0, sizeof(rq->elv));
>>}
>>}
>
> This looks like a BFQ problem, this should not be necessary. Paolo,
> you're calling your own prepare request handler from the insert
> as well, and your prepare request does nothing if rq->elv.icq == NULL.

 I sent the patch anyway, since it's kind of a robustness improvement,
 I'd hope. If you fix BFQ also, please add:
>>>
>>> It's also a memset() in the hot path, would prefer to avoid that...
>>> The issue here is really the convoluted bfq usage of insert/prepare,
>>> I'm sure Paolo can take it from here.
>>
> 
> Hi,
> I'm very sorry for tuning in very late, but, at the same time, very
> glad to find the problem probably already solved ;) (in this respect, I swear,
> my delay was not intentional)
> 
>> Does this fix it?
>>
>> diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
>> index f0ecd98509d8..d883469a1582 100644
>> --- a/block/bfq-iosched.c
>> +++ b/block/bfq-iosched.c
>> @@ -4934,8 +4934,11 @@ static void bfq_prepare_request(struct request *rq, 
>> struct bio *bio)
>>  bool new_queue = false;
>>  bool bfqq_already_existing = false, split = false;
>>
>> -if (!rq->elv.icq)
>> +if (!rq->elv.icq) {
>> +rq->elv.priv[0] = rq->elv.priv[1] = NULL;
>>  return;
>> +}
>> +
> 
> This does solve the problem at hand.  But it also arouses a question,
> related to a possible subtle bug.
> 
> For BFQ, !rq->elv.icq basically means "this request is not for me, as
> I am an icq-based scheduler".  But, IIUC the main points in this
> thread, then this assumption is false.  If it is actually false, then
> I hope that all requests with !rq->elv.icq that are sent to BFQ do
> verify the condition (at_head || blk_rq_is_passthrough(rq)).  In fact,
> requests that do not verify that condition are those that BFQ must put
> in a bfq_queue.  So, even if this patch makes the crash disappear, we
> drive BFQ completely crazy (and we may expect other strange failures)
> if we send BFQ a request with !((at_head || blk_rq_is_passthrough(rq))
> and !rq->elv.icq.  BFQ has to put that rq into a bfq_queue, but simply
> cannot.
> 
> Jens, or any other, could you please shed a light on this, and explain
> how things are exactly?

Your assumption is correct, however you set ->priv[0] and ->priv[1] for
requests, but only for ->elv.icq != NULL. So let's assume you get a
request and assign those two, request completes. Later on, you get
the same request, bypass insert it. BFQ doesn't clear the bic/bfqq
pointers in the request, since ->elv.icq == NULL. It gets inserted
into the dispatch list.

Then when __bfq_dispatch_request() is called, you do:

bfqq = RQ_BFQQ(rq);
if (bfqq)
bfqq->dispatched++;
[...]

which is wrong, since you don't know if you assigned a bfqq for this
request. The memory that bfqq points to could be long gone, if that
queue is freed. So you could either guard any bfqq/bic retrieval
with ->elv.icq != NULL, or you could just clear the pointers for
the case where the values aren't valid.

-- 
Jens Axboe

[PATCH] drm: omapdrm: silence unititialized variable warning

[Dan Carpenter]

Smatch complains that "area_free" could be used without being
initialized.  This code is several years old and premusably works fine
so this can't be a very serious bug.  But it's easy enough to silence
the warning.  If "area_free" is false at the end of the function then
we return -ENOMEM.

Signed-off-by: Dan Carpenter 

diff --git a/drivers/gpu/drm/omapdrm/tcm-sita.c 
b/drivers/gpu/drm/omapdrm/tcm-sita.c
index d7f7bc9f061a..817be3c41863 100644
--- a/drivers/gpu/drm/omapdrm/tcm-sita.c
+++ b/drivers/gpu/drm/omapdrm/tcm-sita.c
@@ -90,7 +90,7 @@ static int l2r_t2b(u16 w, u16 h, u16 a, s16 offset,
 {
int i;
unsigned long index;
-   bool area_free;
+   bool area_free = false;
unsigned long slots_per_band = PAGE_SIZE / slot_bytes;
unsigned long bit_offset = (offset > 0) ? offset / slot_bytes : 0;
unsigned long curr_bit = bit_offset;

[PATCH v9 0/2] drm: Add Thine THC63LVD1024 LVDS decoder bridge

[Jacopo Mondi]

As I have another series which is based on this one + Eagle board display
support, I'm re-sending this one to fix the small issue I pointed out in my
reply to v8.

Simon: no changes to Eagle DTS series, so the last one sent is still the good
one.

DRM: I have collected several reviewed-by tags both on driver and bindings.
Can I send out incremental patches on this series and consider this one to
be ready to be collected?

Thanks
   j

v8 -> v9:
- Put 'remote' OF node after usage not just in error path during device
  tree parsing routine
- Add Rob's Reviewed-by tag to the device tree bindings documentation

v7 -> b8:
- Make 'vcc' supply mandatory
- Use 'oe' property name to describe "OE" pin
- Minor fixes as suggested by Laurent on bindings and driver

v6 -> v7:
- Use semi-standard names for powerdown and output enable GPIOs as suggested
  by Rob and Vladimir
- Use 'regulator_get()' not the optional version, and list only 'vcc' as
  requested supply
- Addressed Laurent's review comments and removed Eagle display enablement patch
  to be sent separately

v5 -> v6:
- Drop check for CONFIG_OF as it is a Kconfig dependency
- Add Niklas Reviewed-by tags
- List [3/3] depenencies below commit message to ease integration

v4 -> v5:
- Fix punctuation in bindings documentation
- Add small statement to bindings document to clarify the chip has no
  control bus
- Print regulator name in enable/disable routines error path
- Add Andrzej Reviewed-by tag

v3 -> v4:
- Rename permutations of "pdwn" to just "pdwn" everywhere in the series
- Improve power enable/disable routines as suggested by Andrzej and Sergei
- Change "pdwn" gpio initialization to use the logical output level
- Change Kconfig description

v2 -> v3:
- Drop support for "lvds-decoder" and make the driver THC63LVD1024 specific
-- Rework bindings to describe multiple input/output ports
-- Rename driver and remove "lvds-decoder" references
-- Rework Eagle DTS to use new bindings

v1 -> v2:
- Drop support for THC63LVD1024

Jacopo Mondi (2):
  dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder
  drm: bridge: Add thc63lvd1024 LVDS decoder driver

 .../bindings/display/bridge/thine,thc63lvd1024.txt |  60 ++
 drivers/gpu/drm/bridge/Kconfig |   6 +
 drivers/gpu/drm/bridge/Makefile|   1 +
 drivers/gpu/drm/bridge/thc63lvd1024.c  | 205 +
 4 files changed, 272 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
 create mode 100644 drivers/gpu/drm/bridge/thc63lvd1024.c

--
2.7.4

[PATCH v9 2/2] drm: bridge: Add thc63lvd1024 LVDS decoder driver

[Jacopo Mondi]

Add DRM bridge driver for Thine THC63LVD1024 LVDS to digital parallel
output converter.

Signed-off-by: Jacopo Mondi 
Reviewed-by: Andrzej Hajda 
Reviewed-by: Niklas Söderlund 
Reviewed-by: Laurent Pinchart 
---
 drivers/gpu/drm/bridge/Kconfig|   6 +
 drivers/gpu/drm/bridge/Makefile   |   1 +
 drivers/gpu/drm/bridge/thc63lvd1024.c | 206 ++
 3 files changed, 213 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/thc63lvd1024.c

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 3aa65bd..42c9c2d 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -93,6 +93,12 @@ config DRM_SII9234
  It is an I2C driver, that detects connection of MHL bridge
  and starts encapsulation of HDMI signal.
 
+config DRM_THINE_THC63LVD1024
+   tristate "Thine THC63LVD1024 LVDS decoder bridge"
+   depends on OF
+   ---help---
+ Thine THC63LVD1024 LVDS/parallel converter driver.
+
 config DRM_TOSHIBA_TC358767
tristate "Toshiba TC358767 eDP bridge"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 373eb28..fd90b16 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
 obj-$(CONFIG_DRM_SIL_SII8620) += sil-sii8620.o
 obj-$(CONFIG_DRM_SII902X) += sii902x.o
 obj-$(CONFIG_DRM_SII9234) += sii9234.o
+obj-$(CONFIG_DRM_THINE_THC63LVD1024) += thc63lvd1024.o
 obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
 obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
 obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
diff --git a/drivers/gpu/drm/bridge/thc63lvd1024.c 
b/drivers/gpu/drm/bridge/thc63lvd1024.c
new file mode 100644
index 000..c8b9edd
--- /dev/null
+++ b/drivers/gpu/drm/bridge/thc63lvd1024.c
@@ -0,0 +1,206 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * THC63LVD1024 LVDS to parallel data DRM bridge driver.
+ *
+ * Copyright (C) 2018 Jacopo Mondi 
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+enum thc63_ports {
+   THC63_LVDS_IN0,
+   THC63_LVDS_IN1,
+   THC63_RGB_OUT0,
+   THC63_RGB_OUT1,
+};
+
+struct thc63_dev {
+   struct device *dev;
+
+   struct regulator *vcc;
+
+   struct gpio_desc *pdwn;
+   struct gpio_desc *oe;
+
+   struct drm_bridge bridge;
+   struct drm_bridge *next;
+};
+
+static inline struct thc63_dev *to_thc63(struct drm_bridge *bridge)
+{
+   return container_of(bridge, struct thc63_dev, bridge);
+}
+
+static int thc63_attach(struct drm_bridge *bridge)
+{
+   struct thc63_dev *thc63 = to_thc63(bridge);
+
+   return drm_bridge_attach(bridge->encoder, thc63->next, bridge);
+}
+
+static void thc63_enable(struct drm_bridge *bridge)
+{
+   struct thc63_dev *thc63 = to_thc63(bridge);
+   int ret;
+
+   ret = regulator_enable(thc63->vcc);
+   if (ret) {
+   dev_err(thc63->dev,
+   "Failed to enable regulator \"vcc\": %d\n", ret);
+   return;
+   }
+
+   gpiod_set_value(thc63->pdwn, 0);
+   gpiod_set_value(thc63->oe, 1);
+}
+
+static void thc63_disable(struct drm_bridge *bridge)
+{
+   struct thc63_dev *thc63 = to_thc63(bridge);
+   int ret;
+
+   gpiod_set_value(thc63->oe, 0);
+   gpiod_set_value(thc63->pdwn, 1);
+
+   ret = regulator_disable(thc63->vcc);
+   if (ret)
+   dev_err(thc63->dev,
+   "Failed to disable regulator \"vcc\": %d\n", ret);
+}
+
+static const struct drm_bridge_funcs thc63_bridge_func = {
+   .attach = thc63_attach,
+   .enable = thc63_enable,
+   .disable = thc63_disable,
+};
+
+static int thc63_parse_dt(struct thc63_dev *thc63)
+{
+   struct device_node *thc63_out;
+   struct device_node *remote;
+
+   thc63_out = of_graph_get_endpoint_by_regs(thc63->dev->of_node,
+ THC63_RGB_OUT0, -1);
+   if (!thc63_out) {
+   dev_err(thc63->dev, "Missing endpoint in port@%u\n",
+   THC63_RGB_OUT0);
+   return -ENODEV;
+   }
+
+   remote = of_graph_get_remote_port_parent(thc63_out);
+   of_node_put(thc63_out);
+   if (!remote) {
+   dev_err(thc63->dev, "Endpoint in port@%u unconnected\n",
+   THC63_RGB_OUT0);
+   return -ENODEV;
+   }
+
+   if (!of_device_is_available(remote)) {
+   dev_err(thc63->dev, "port@%u remote endpoint is disabled\n",
+   THC63_RGB_OUT0);
+   of_node_put(remote);
+   return -ENODEV;
+   }
+
+   thc63->next = of_drm_find_bridge(remote);
+   of_node_put(remote);
+   if (!thc63->next)
+   

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

[Mark Brown]

On Wed, Apr 18, 2018 at 09:51:13AM +1000, Stephen Rothwell wrote:

> Caused by commit

>   81e9b0a07889 ("ASoC: topology: Give more data to clients via callbacks")

> I have used the sound-aoc tree from next-20180416 again today.

Ugh, reverted that and the following commit which depends on it.


signature.asc
Description: PGP signature

Re: [PATCH] doc: dev-tools: kselftest.rst: update contributing new tests

[Shuah Khan]

On 04/17/2018 02:46 AM, Anders Roxell wrote:
> Add a description that the kernel headers should be used as far as it is
> possible and then the system headers.
> 
> Signed-off-by: Anders Roxell 
> ---
>  Documentation/dev-tools/kselftest.rst | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/Documentation/dev-tools/kselftest.rst 
> b/Documentation/dev-tools/kselftest.rst
> index e80850eefe13..27f08d6ba91c 100644
> --- a/Documentation/dev-tools/kselftest.rst
> +++ b/Documentation/dev-tools/kselftest.rst
> @@ -151,6 +151,9 @@ Contributing new tests (details)
> TEST_FILES, TEST_GEN_FILES mean it is the file which is used by
> test.
>  
> + * First use the headers inside the kernel, and then the system headers. The
> +   internal headers should be the primary focus to be able to find 
> regressions.

Clarifying the location of the headers might be helpful. This description uses
different terminology to describe kernel headers.

"First use the headers inside the kernel sources and/or git reo" would make this
clear. Instead of "internal headers" headers for the kernel release as opposed
to headers installed by the distro on the system would make a clear distinction.

thanks,
-- Shuah

Re: [PATCH v4 1/2] Documentation: Documentation for qcom, llcc

[Rob Herring]

On Tue, Apr 17, 2018 at 5:12 PM,   wrote:
> On 2018-04-17 10:43, risha...@codeaurora.org wrote:
>>
>> On 2018-04-16 07:59, Rob Herring wrote:
>>>
>>> On Tue, Apr 10, 2018 at 01:08:12PM -0700, Rishabh Bhatnagar wrote:

 Documentation for last level cache controller device tree bindings,
 client bindings usage examples.
>>>
>>>
>>> "Documentation: Documentation ..."? That wastes a lot of the subject
>>> line... The preferred prefix is "dt-bindings: ..."
>>>

 Signed-off-by: Channagoud Kadabi 
 Signed-off-by: Rishabh Bhatnagar 
 ---
  .../devicetree/bindings/arm/msm/qcom,llcc.txt  | 58
 ++
  1 file changed, 58 insertions(+)
  create mode 100644
 Documentation/devicetree/bindings/arm/msm/qcom,llcc.txt

 diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,llcc.txt
 b/Documentation/devicetree/bindings/arm/msm/qcom,llcc.txt
 new file mode 100644
 index 000..497cf0f
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/arm/msm/qcom,llcc.txt
 @@ -0,0 +1,58 @@
 +== Introduction==
 +
 +LLCC (Last Level Cache Controller) provides last level of cache memory
 in SOC,
 +that can be shared by multiple clients. Clients here are different
 cores in the
 +SOC, the idea is to minimize the local caches at the clients and
 migrate to
 +common pool of memory
 +
 +Properties:
 +- compatible:
 +Usage: required
 +Value type: 
 +Definition: must be "qcom,sdm845-llcc"
 +
 +- reg:
 +Usage: required
 +Value Type: 
 +Definition: must be addresses and sizes of the LLCC registers
>>>
>>>
>>> How many address ranges?
>>>
>> It consists of just one address range. I'll edit the definition to make
>> it more clear.

 +
 +- #cache-cells:
>>>
>>>
>>> This is all written as it is a common binding, but it is not one.
>>>
>>> You already have most of the configuration data for each client in the
>>> driver, I think I'd just put the client connection there too. Is there
>>> any variation of this for a given SoC?
>>>
>> #cache-cells and max-slices won't change for a given SOC. So you want me
>> to hard-code in the driver itself?
>>
> I can use of_parse_phandle_with_fixed_args function and fix the number of
> args as 1 instead of keeping #cache-cells here in DT. Does that look fine?

No, I'm saying why even put cache-slices properties in DT to begin
with? You could just define client id's within the kernel and clients
can use those instead of getting the id from the DT.

I have a couple of hesitations with putting this into the DT. First, I
think a cache is just one aspect of describing the interconnect
between masters and memory (and there's been discussions on
interconnect bindings too) and any binding needs to consider all of
the aspects of the interconnect. Second, I'd expect this cache
architecture will change SoC to SoC and the binding here is pretty
closely tied to the current cache implementation (e.g. slices). If
there were a bunch of SoCs with the same design and just different
client IDs (like interrupt IDs), then I'd feel differently.

Rob

Re: [PATCH v2] serial: imx: warn user when using unsupported configuration

[Uwe Kleine-König]

On Wed, Apr 18, 2018 at 04:06:38PM +0200, Stefan Agner wrote:
> When using half-duplex mode (which disables receiver during txing)
> the RTS signal cannot be driven low during transmission. This seems
> to be a limitation of the i.MX UART IP: The RTS (CTS_B) signal is
> controlled by the receiver. When the receiver is disabled, the
> signal stays in UART logic idle state which is high...
> 
> If SER_RS485_RTS_ON_SEND is used, RTS needs to be high active during
> transmission. Since this is the default state of the RTS (CTS_B)
> signal when the receiver is off, half-duplex mode in this
> configuration works fine.
> 
> However, a low-active RTS signal (flag SER_RS485_RTS_ON_SEND not set)
> cannot be generated when the receiver is turned off.
> 
> Print an error if the user selects this unsupported configuration
> (both SER_RS485_RTS_ON_SEND and SER_RS485_RX_DURING_TX unset) and
> configure the closest working configuration (set the
> SER_RS485_RX_DURING_TX flag).
> 
> Signed-off-by: Stefan Agner 
> ---
> Changes since v1:
> - Consistently check for sport->have_rtscts && !(rs485conf->flags &
>   SER_RS485_RTS_ON_SEND)
> - Don't break printed message
> 
>  drivers/tty/serial/imx.c | 15 +++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
> index 91f3a1a5cb7f..1c1080fc8084 100644
> --- a/drivers/tty/serial/imx.c
> +++ b/drivers/tty/serial/imx.c
> @@ -1833,6 +1833,11 @@ static int imx_uart_rs485_config(struct uart_port 
> *port,
>   rs485conf->flags &= ~SER_RS485_ENABLED;
>  
>   if (rs485conf->flags & SER_RS485_ENABLED) {
> + /* Enable receiver if low-active RTS signal is requested */
> + if (sport->have_rtscts &&
> + !(rs485conf->flags & SER_RS485_RTS_ON_SEND))
> + rs485conf->flags |= SER_RS485_RX_DURING_TX;
> +

I wonder what should happen, if the device tree has both

uart-has-rtscts;
rts-gpios = <...>;

. I think the right thing would be to check for

sport->have_rtscts && !sport->have_rtsgpio

.

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |

[GIT PULL] Ceph fixes for 4.17-rc2

[Ilya Dryomov]

Hi Linus,

The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:

  Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)

are available in the git repository at:

  https://github.com/ceph/ceph-client.git tags/ceph-for-4.17-rc2

for you to fetch changes up to d93605407af34eb0b7eb8aff6b1eae2cde3cdd22:

  rbd: notrim map option (2018-04-16 09:38:40 +0200)


A couple of follow-up patches for -rc1 changes in rbd, support for
a timeout on waiting for the acquisition of exclusive lock and a fix
for uninitialized memory access in CephFS, marked for stable.


Arnd Bergmann (1):
  rbd: avoid Wreturn-type warnings

Dongsheng Yang (1):
  rbd: support timeout in rbd_wait_state_locked()

Ilya Dryomov (3):
  rbd: refactor rbd_wait_state_locked()
  rbd: adjust queue limits for "fancy" striping
  rbd: notrim map option

Yan, Zheng (1):
  ceph: always update atime/mtime/ctime for new inode

 drivers/block/rbd.c | 101 +++-
 fs/ceph/inode.c |  10 --
 2 files changed, 76 insertions(+), 35 deletions(-)

Re: [PATCH v4 01/10] x86/microcode/AMD: Subtract SECTION_HDR_SIZE from file leftover length

[Borislav Petkov]

On Wed, Apr 18, 2018 at 03:57:23PM +0200, Maciej S. Szmigiero wrote:
> So, should this patch be included in a respin or not?

Yes please. Do them all ontop of tip/master.

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

Re: [PATCH] SLUB: Do not fallback to mininum order if __GFP_NORETRY is set

[Christopher Lameter]

On Wed, 18 Apr 2018, Mikulas Patocka wrote:

> No, this would hit NULL pointer dereference if page is NULL and
> __GFP_NORETRY is set. You want this:

You are right

Acked-by: Christoph Lameter 

Re: [PATCH v2 0/5] ALSA: xen-front: Add Xen para-virtualized frontend driver

[Oleksandr Andrushchenko]

On 04/16/2018 09:24 AM, Oleksandr Andrushchenko wrote:

From: Oleksandr Andrushchenko 

Please note: this patch series depends on [3].

The dependency is now merged into Xen kernel tree [4] for-linus-4.17


This patch series adds support for Xen [1] para-virtualized
sound frontend driver. It implements the protocol from
include/xen/interface/io/sndif.h with the following limitations:
- mute/unmute is not supported
- get/set volume is not supported
Volume control is not supported for the reason that most of the
use-cases (at the moment) are based on scenarious where
unprivileged OS (e.g. Android, AGL etc) use software mixers.

Both capture and playback are supported.

Corresponding backend, implemented as a user-space application, can be
found at [2].

Thank you,
Oleksandr

Changes since v1:
*

1. Moved driver from sound/drivers to sound/xen

2. Coding style changes to better meet Linux Kernel

3. Added explicit back and front synchronization
In order to provide explicit synchronization between backend and
frontend the following changes are introduced in the protocol:
 - add new ring buffer for sending asynchronous events from
   backend to frontend to report number of bytes played by the
   frontend (XENSND_EVT_CUR_POS)
 - introduce trigger events for playback control: start/stop/pause/resume
 - add "req-" prefix to event-channel and ring-ref to unify naming
   of the Xen event channels for requests and events

4. Added explicit back and front parameter negotiation
In order to provide explicit stream parameter negotiation between
backend and frontend the following changes are introduced in the protocol:
add XENSND_OP_HW_PARAM_QUERY request to read/update
configuration space for the parameters given: request passes
desired parameter's intervals/masks and the response to this request
returns allowed min/max intervals/masks to be used.

[1] https://xenproject.org/
[2] https://github.com/xen-troops/snd_be
[3] https://lkml.org/lkml/2018/4/12/522

Oleksandr Andrushchenko (5):
   ALSA: xen-front: Introduce Xen para-virtualized sound frontend driver
   ALSA: xen-front: Read sound driver configuration from Xen store
   ALSA: xen-front: Implement Xen event channel handling
   ALSA: xen-front: Implement handling of shared buffers
   ALSA: xen-front: Implement ALSA virtual sound driver

  sound/Kconfig |   2 +
  sound/Makefile|   2 +-
  sound/xen/Kconfig |  10 +
  sound/xen/Makefile|   9 +
  sound/xen/xen_snd_front.c | 410 +++
  sound/xen/xen_snd_front.h |  57 +++
  sound/xen/xen_snd_front_alsa.c| 830 ++
  sound/xen/xen_snd_front_alsa.h|  23 ++
  sound/xen/xen_snd_front_cfg.c | 517 
  sound/xen/xen_snd_front_cfg.h |  46 +++
  sound/xen/xen_snd_front_evtchnl.c | 478 ++
  sound/xen/xen_snd_front_evtchnl.h |  92 +
  sound/xen/xen_snd_front_shbuf.c   | 193 +
  sound/xen/xen_snd_front_shbuf.h   |  36 ++
  14 files changed, 2704 insertions(+), 1 deletion(-)
  create mode 100644 sound/xen/Kconfig
  create mode 100644 sound/xen/Makefile
  create mode 100644 sound/xen/xen_snd_front.c
  create mode 100644 sound/xen/xen_snd_front.h
  create mode 100644 sound/xen/xen_snd_front_alsa.c
  create mode 100644 sound/xen/xen_snd_front_alsa.h
  create mode 100644 sound/xen/xen_snd_front_cfg.c
  create mode 100644 sound/xen/xen_snd_front_cfg.h
  create mode 100644 sound/xen/xen_snd_front_evtchnl.c
  create mode 100644 sound/xen/xen_snd_front_evtchnl.h
  create mode 100644 sound/xen/xen_snd_front_shbuf.c
  create mode 100644 sound/xen/xen_snd_front_shbuf.h

[4] 
https://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git/commit/?h=for-linus-4.17=cd6e992b3aab072cc90839508aaf5573c8f7e066

Re: [PATCH v2] tracing/x86: Update syscall trace events to handle new x86 syscall func names

[Arnaldo Carvalho de Melo]

Em Wed, Apr 18, 2018 at 12:02:12PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Wed, Apr 18, 2018 at 10:36:06AM -0400, Steven Rostedt escreveu:
> > On Wed, 18 Apr 2018 09:53:22 -0300
> > Arnaldo Carvalho de Melo  wrote:
> > > Em Tue, Apr 17, 2018 at 05:41:28PM -0400, Steven Rostedt escreveu:
> > > > On Tue, 17 Apr 2018 15:13:04 -0300 Arnaldo Carvalho de Melo 
> > > >  wrote:  
> > > > > Yeah, failing:  
> 
> > > > > [root@jouet ~]# strace -e openat -e file perf test -F -v "mmap 
> > > > > interface" |& grep syscalls
> > > > > openat(AT_FDCWD, 
> > > > > "/sys/kernel/debug/tracing/events/syscalls/sys_enter_getsid/format", 
> > > > > O_RDONLY) = 3
> > > > > openat(AT_FDCWD, 
> > > > > "/sys/kernel/debug/tracing/events/syscalls/sys_enter_getppid/format", 
> > > > > O_RDONLY) = -1 ENOENT (No such file or directory)  
> > >  
> > > > It doesn't have to do with the number of parameters, not everything
> > > > has "__x64" on it.  
> 
> > > > Try this patch:  
> 
> > > Trying...
>  
> > You're keeping me in suspense!
> 
> I switched locations, had trouble reconnecting, those tests are ok now,
> there is just one case left, related to the syscall routines renames,
> but not related to the syscalls:sys_{enter,exit}_NAME tracepoints:
> 40: BPF filter:
> 40.1: Basic BPF filtering : FAILED!
> 40.2: BPF pinning : Skip
> 40.3: BPF prologue generation : Skip
> 40.4: BPF relocation checker  : Skip
> 
> If we use -v for that test we see the problem:
> 
> To the point:
> 
>   Probe point 'SyS_epoll_pwait' not found.
> 
> This is not there anymore, I'll change this test to first figure out
> what is the syscall routine for the epoll_pwait syscall so that it works
> with pre-syscall-routines-rename and after that.

This does the trick, by not using the main syscall routine, but one
called from it and not renamed, should work with older kernels.

This test should be improved to look if the desired routine is in place,
if not just skip the test and tell about the unavailability of the
wanted function, but that is for later.

- Arnaldo

diff --git a/tools/perf/tests/bpf-script-example.c 
b/tools/perf/tests/bpf-script-example.c
index e4123c1b0e88..1ca5106df5f1 100644
--- a/tools/perf/tests/bpf-script-example.c
+++ b/tools/perf/tests/bpf-script-example.c
@@ -31,7 +31,7 @@ struct bpf_map_def SEC("maps") flip_table = {
.max_entries = 1,
 };
 
-SEC("func=SyS_epoll_pwait")
+SEC("func=do_epoll_wait")
 int bpf_func__SyS_epoll_pwait(void *ctx)
 {
int ind =0;

Re: [PATCH 1/2] tracing: fix bad use of igrab in trace_uprobe.c

[Steven Rostedt]

On Wed, 18 Apr 2018 16:40:19 +0200
Miklos Szeredi  wrote:


> > The trace_uprobe (the probe event) is created, it doesn't do anything
> > until it is enabled. This function is called when it is enabled. The
> > trace_uprobe (probe event) can not be deleted while it is enabled
> > (EBUSY).
> >
> > Are you asking what happens if the file is deleted while it has probe?
> > That I don't know about (haven't tried it out). But I would hope that
> > it keeps a reference to the inode, isn't that what the igrab is for?
> > And is now being replaced by a reference on the path, or is that the
> > problem?  
> 
> No, that's not the problem.
> 
> What I don't see is how the uprobe object relates to the trace_uprobe object.
> 
> Because after the patch the uprobe object still only has a ref to the
> inode, and that can lead to the same issue as with trace_uprobe.
> OTOH if uprobe can't survive its creating trace_uprobe, then it
> doesn't need to take a ref to the inode at all, since trace_uprobe
> already holds it.   Taking an extra ref isn't incorrect, it's just
> unnecessary and confusing.
> 
> So this needs to be cleared up in some way.

The uprobe created by the trace_uprobe creation must be deleted before
the trace_uprobe can be deleted. Basically we have this:

 # cd /sys/kernel/tracing
 # echo "uprobe creation text" > uprobe_events

The trace_uprobe is created (but not the uprobe itself). This is what
calls create_trace_uprobe().

 # echo 1 > events/uprobes/enable

This enables all the trace uprobe events, which creates the uprobes.
This is the action that calls probe_event_enable(), which creates
uprobes.

At this point, any write to uprobe_events that would destroy the trace
uprobes would return with -EBUSY, and the trace uprobes will not be
deleted.

 # echo 0 > events/uprobes/enable

This will call the probe_event_disable() which will call
uprobe_unregister() which will destroy the uprobe.

Now we can delete the trace uprobe.

Does that answer your question? A uprobe created for trace uprobes can
not survive the trace uprobe itself.

-- Steve

Re: [PATCH] [media] include/media: fix missing | operator when setting cfg

[Sylwester Nawrocki]

On 04/18/2018 05:06 PM, Colin King wrote:
> From: Colin Ian King 
> 
> The value from a readl is being masked with ITE_REG_CIOCAN_MASK however
> this is not being used and cfg is being re-assigned.  I believe the
> assignment operator should actually be instead the |= operator.
> 
> Detected by CoverityScan, CID#1467987 ("Unused value")
> 
> Signed-off-by: Colin Ian King 

Thanks for the patch.

Acked-by: Sylwester Nawrocki 

Re: [PATCH v2] tracing/x86: Update syscall trace events to handle new x86 syscall func names

[Steven Rostedt]

On Wed, 18 Apr 2018 12:17:16 -0300
Arnaldo Carvalho de Melo  wrote:

> This does the trick, by not using the main syscall routine, but one
> called from it and not renamed, should work with older kernels.
> 
> This test should be improved to look if the desired routine is in place,
> if not just skip the test and tell about the unavailability of the
> wanted function, but that is for later.

Does this mean you can give me a "Tested-by" for that last patch?

-- Steve

[PATCH] media: cec: set ev rather than v with CEC_PIN_EVENT_FL_DROPPED bit

[Colin King]

From: Colin Ian King 

Setting v with the CEC_PIN_EVENT_FL_DROPPED is incorrect, instead
ev should be set with this bit. Fix this.

Detected by CoverityScan, CID#1467974 ("Extra high-order bits")

Fixes: 6ec1cbf6b125 ("media: cec: improve CEC pin event handling")
Signed-off-by: Colin Ian King 
---
 drivers/media/cec/cec-pin.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/cec/cec-pin.c b/drivers/media/cec/cec-pin.c
index 2a5df99735fa..6e311424f0dc 100644
--- a/drivers/media/cec/cec-pin.c
+++ b/drivers/media/cec/cec-pin.c
@@ -119,7 +119,7 @@ static void cec_pin_update(struct cec_pin *pin, bool v, 
bool force)
 
if (pin->work_pin_events_dropped) {
pin->work_pin_events_dropped = false;
-   v |= CEC_PIN_EVENT_FL_DROPPED;
+   ev |= CEC_PIN_EVENT_FL_DROPPED;
}
pin->work_pin_events[pin->work_pin_events_wr] = ev;
pin->work_pin_ts[pin->work_pin_events_wr] = ktime_get();
-- 
2.17.0

Re: [PATCH v2] tracing/x86: Update syscall trace events to handle new x86 syscall func names

[Arnaldo Carvalho de Melo]

Em Wed, Apr 18, 2018 at 11:20:33AM -0400, Steven Rostedt escreveu:
> On Wed, 18 Apr 2018 12:17:16 -0300
> Arnaldo Carvalho de Melo  wrote:
> 
> > This does the trick, by not using the main syscall routine, but one
> > called from it and not renamed, should work with older kernels.
> > 
> > This test should be improved to look if the desired routine is in place,
> > if not just skip the test and tell about the unavailability of the
> > wanted function, but that is for later.
> 
> Does this mean you can give me a "Tested-by" for that last patch?

Here it is, just written down:

Tested-by: Arnaldo Carvalho de Melo 

- Arnaldo

Re: [PATCH V4 2/2] mmc: sdhci-msm: support voltage pad switching

[Vijay Viswanath]

On 4/13/2018 10:38 PM, Doug Anderson wrote:

Hi,

On Fri, Apr 6, 2018 at 2:48 AM, Vijay Viswanath  wrote:



On 3/29/2018 4:23 AM, Doug Anderson wrote:


Hi,

On Wed, Mar 28, 2018 at 6:08 AM, Vijay Viswanath
 wrote:


From: Krishna Konda 

The PADs for SD card are dual-voltage that support 3v/1.8v. Those PADs
have a control signal  (io_pad_pwr_switch/mode18 ) that indicates
whether the PAD works in 3v or 1.8v.

SDHC core on msm platforms should have IO_PAD_PWR_SWITCH bit set/unset
based on actual voltage used for IO lines. So when power irq is
triggered for io high or io low, the driver should check the voltages
supported and set the pad accordingly.

Signed-off-by: Krishna Konda 
Signed-off-by: Venkat Gopalakrishnan 
Signed-off-by: Vijay Viswanath 
---
   drivers/mmc/host/sdhci-msm.c | 64
++--
   1 file changed, 62 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
index 2fcd9010..bbf9626 100644
--- a/drivers/mmc/host/sdhci-msm.c
+++ b/drivers/mmc/host/sdhci-msm.c
@@ -78,12 +78,15 @@
   #define CORE_HC_MCLK_SEL_DFLT  (2 << 8)
   #define CORE_HC_MCLK_SEL_HS400 (3 << 8)
   #define CORE_HC_MCLK_SEL_MASK  (3 << 8)
+#define CORE_IO_PAD_PWR_SWITCH_EN  (1 << 15)
+#define CORE_IO_PAD_PWR_SWITCH  (1 << 16)
   #define CORE_HC_SELECT_IN_EN   BIT(18)
   #define CORE_HC_SELECT_IN_HS400(6 << 19)
   #define CORE_HC_SELECT_IN_MASK (7 << 19)

   #define CORE_3_0V_SUPPORT  (1 << 25)
   #define CORE_1_8V_SUPPORT  (1 << 26)
+#define CORE_VOLT_SUPPORT  (CORE_3_0V_SUPPORT | CORE_1_8V_SUPPORT)

   #define CORE_CSR_CDC_CTLR_CFG0 0x130
   #define CORE_SW_TRIG_FULL_CALIBBIT(16)
@@ -1109,7 +1112,7 @@ static void sdhci_msm_handle_pwr_irq(struct
sdhci_host *host, int irq)
  u32 irq_status, irq_ack = 0;
  int retry = 10;
  u32 pwr_state = 0, io_level = 0;
-
+   u32 config;

  irq_status = readl_relaxed(msm_host->core_mem +
CORE_PWRCTL_STATUS);
  irq_status &= INT_MASK;
@@ -1166,6 +1169,45 @@ static void sdhci_msm_handle_pwr_irq(struct
sdhci_host *host, int irq)
   */
  writel_relaxed(irq_ack, msm_host->core_mem + CORE_PWRCTL_CTL);

+   /*
+* If we don't have info regarding the voltage levels supported
by
+* regulators, don't change the IO PAD PWR SWITCH.
+*/
+   if (msm_host->caps_0 & CORE_VOLT_SUPPORT) {
+   /* Ensure order between core_mem and hc_mem */
+   mb();



Like in v2, I don't understand why you need a mb() before the read
from CORE_VENDOR_SPEC.  No reads or writes to the core_mem will affect
the value you're reading here, so you need no barrier.

If you need a barrier before the _write_ to CORE_VENDOR_SPEC then add
it below.  Then in the case where the config doesn't change you have
no barriers.



+   /*
+* We should unset IO PAD PWR switch only if the register
write
+* can set IO lines high and the regulator also switches
to 3 V.
+* Else, we should keep the IO PAD PWR switch set.
+* This is applicable to certain targets where eMMC vccq
supply
+* is only 1.8V. In such targets, even during
REQ_IO_HIGH, the
+* IO PAD PWR switch must be kept set to reflect actual
+* regulator voltage. This way, during initialization of
+* controllers with only 1.8V, we will set the IO PAD bit
+* without waiting for a REQ_IO_LOW.
+*/



For the above comment, what about just:

new_config = config
if (msm_host->caps_0 == CORE_1_8V_SUPPORT) {
new_config |= CORE_IO_PAD_PWR_SWITCH;
} else if (msm_host->caps_0 == CORE_3_3V_SUPPORT) {
new_config &= ~CORE_IO_PAD_PWR_SWITCH;
} else if (msm_host->caps_0 & CORE_VOLT_SUPPORT) {
if (io_level & REQ_IO_HIGH)
  new_config &= ~CORE_IO_PAD_PWR_SWITCH;
else if (io_level & REQ_IO_LOW)
  new_config |= CORE_IO_PAD_PWR_SWITCH;
}



This looks a big mess of if/else. Does the above implementation have better
performance compared to having two if/else with bit operations inside ? The
latter looks much cleaner and faster.

If regulator only supports 3V and we get a io_low from BUS_OFF ( REQ_IO_LOW
should never come if we don't support 1.8V), it is ok to set io pad.


Yeah, I think it's ugly no matter what.  Personally I find the
if/then/else easier to follow than the complicated conditions split
across multiple lines.  I seem to remember there was something that my
version did differently than yours too (hence the "this might be more
important if you get rid of the initial setting"), let's see if I can
figure it out again.

Mine says:
- if it has exactly 1.8 or 3.3 support: set that.
- else if it supports both: set whatever is 

[PATCH 1/3] dt-bindings: iio: stm32-adc: add support for STM32MP1.

[Fabrice Gasnier]

Document support for STM32MP1 ADC. It's quite similar to STM32H7 ADC.
Introduce "st,stm32mp1-adc" compatible to handle variants of this
hardware such as vregready flag, interrupts, clock rate.

Signed-off-by: Fabrice Gasnier 
---
 Documentation/devicetree/bindings/iio/adc/st,stm32-adc.txt | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.txt 
b/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.txt
index e8bb824..9994384 100644
--- a/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.txt
+++ b/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.txt
@@ -24,8 +24,11 @@ Required properties:
 - compatible: Should be one of:
   "st,stm32f4-adc-core"
   "st,stm32h7-adc-core"
+  "st,stm32mp1-adc-core"
 - reg: Offset and length of the ADC block register set.
-- interrupts: Must contain the interrupt for ADC block.
+- interrupts: One or more interrupts for ADC block. Some parts like stm32f4
+  and stm32h7 share a common ADC interrupt line. stm32mp1 has separate
+  lines for each ADC within ADC block.
 - clocks: Core can use up to two clocks, depending on part used:
   - "adc" clock: for the analog circuitry, common to all ADCs.
 It's required on stm32f4.
@@ -53,6 +56,7 @@ Required properties:
 - compatible: Should be one of:
   "st,stm32f4-adc"
   "st,stm32h7-adc"
+  "st,stm32mp1-adc"
 - reg: Offset of ADC instance in ADC block (e.g. may be 0x0, 0x100, 0x200).
 - clocks: Input clock private to this ADC instance. It's required only on
   stm32f4, that has per instance clock input for registers access.
-- 
1.9.1

[PATCH 2/3] iio: adc: stm32-adc: add support for STM32MP1

[Fabrice Gasnier]

Add support for STM32MP1 ADC. It's quite similar to STM32H7 ADC.
Introduce new compatible to handle variants of this hardware such as
vregready flag, trigger list, interrupts, clock rate.

Signed-off-by: Fabrice Gasnier 
---
 drivers/iio/adc/stm32-adc-core.c | 66 +---
 drivers/iio/adc/stm32-adc.c  | 47 +---
 2 files changed, 91 insertions(+), 22 deletions(-)

diff --git a/drivers/iio/adc/stm32-adc-core.c b/drivers/iio/adc/stm32-adc-core.c
index 40be7d9..ca432e7 100644
--- a/drivers/iio/adc/stm32-adc-core.c
+++ b/drivers/iio/adc/stm32-adc-core.c
@@ -34,9 +34,6 @@
 #define STM32F4_ADC_ADCPRE_SHIFT   16
 #define STM32F4_ADC_ADCPRE_MASKGENMASK(17, 16)
 
-/* STM32 F4 maximum analog clock rate (from datasheet) */
-#define STM32F4_ADC_MAX_CLK_RATE   3600
-
 /* STM32H7 - common registers for all ADC instances */
 #define STM32H7_ADC_CSR(STM32_ADCX_COMN_OFFSET + 0x00)
 #define STM32H7_ADC_CCR(STM32_ADCX_COMN_OFFSET + 0x08)
@@ -51,9 +48,6 @@
 #define STM32H7_CKMODE_SHIFT   16
 #define STM32H7_CKMODE_MASKGENMASK(17, 16)
 
-/* STM32 H7 maximum analog clock rate (from datasheet) */
-#define STM32H7_ADC_MAX_CLK_RATE   3600
-
 /**
  * stm32_adc_common_regs - stm32 common registers, compatible dependent data
  * @csr:   common status register offset
@@ -74,15 +68,17 @@ struct stm32_adc_common_regs {
  * stm32_adc_priv_cfg - stm32 core compatible configuration data
  * @regs:  common registers for all instances
  * @clk_sel:   clock selection routine
+ * @max_clk_rate_hz: maximum analog clock rate (Hz, from datasheet)
  */
 struct stm32_adc_priv_cfg {
const struct stm32_adc_common_regs *regs;
int (*clk_sel)(struct platform_device *, struct stm32_adc_priv *);
+   u32 max_clk_rate_hz;
 };
 
 /**
  * struct stm32_adc_priv - stm32 ADC core private data
- * @irq:   irq for ADC block
+ * @irq:   irq(s) for ADC block
  * @domain:irq domain reference
  * @aclk:  clock reference for the analog circuitry
  * @bclk:  bus clock common for all ADCs, depends on part used
@@ -91,7 +87,7 @@ struct stm32_adc_priv_cfg {
  * @common:common data for all ADC instances
  */
 struct stm32_adc_priv {
-   int irq;
+   int irq[STM32_ADC_MAX_ADCS];
struct irq_domain   *domain;
struct clk  *aclk;
struct clk  *bclk;
@@ -133,7 +129,7 @@ static int stm32f4_adc_clk_sel(struct platform_device *pdev,
}
 
for (i = 0; i < ARRAY_SIZE(stm32f4_pclk_div); i++) {
-   if ((rate / stm32f4_pclk_div[i]) <= STM32F4_ADC_MAX_CLK_RATE)
+   if ((rate / stm32f4_pclk_div[i]) <= priv->cfg->max_clk_rate_hz)
break;
}
if (i >= ARRAY_SIZE(stm32f4_pclk_div)) {
@@ -222,7 +218,7 @@ static int stm32h7_adc_clk_sel(struct platform_device *pdev,
if (ckmode)
continue;
 
-   if ((rate / div) <= STM32H7_ADC_MAX_CLK_RATE)
+   if ((rate / div) <= priv->cfg->max_clk_rate_hz)
goto out;
}
}
@@ -242,7 +238,7 @@ static int stm32h7_adc_clk_sel(struct platform_device *pdev,
if (!ckmode)
continue;
 
-   if ((rate / div) <= STM32H7_ADC_MAX_CLK_RATE)
+   if ((rate / div) <= priv->cfg->max_clk_rate_hz)
goto out;
}
 
@@ -328,11 +324,24 @@ static int stm32_adc_irq_probe(struct platform_device 
*pdev,
   struct stm32_adc_priv *priv)
 {
struct device_node *np = pdev->dev.of_node;
+   unsigned int i;
+
+   for (i = 0; i < STM32_ADC_MAX_ADCS; i++) {
+   priv->irq[i] = platform_get_irq(pdev, i);
+   if (priv->irq[i] < 0) {
+   /*
+* At least one interrupt must be provided, make others
+* optional:
+* - stm32f4/h7 shares a common interrupt.
+* - stm32mp1, has one line per ADC (either for ADC1,
+*   ADC2 or both).
+*/
+   if (i && priv->irq[i] == -ENXIO)
+   continue;
+   dev_err(>dev, "failed to get irq\n");
 
-   priv->irq = platform_get_irq(pdev, 0);
-   if (priv->irq < 0) {
-   dev_err(>dev, "failed to get irq\n");
-   return priv->irq;
+   return priv->irq[i];
+   }
}
 
priv->domain = irq_domain_add_simple(np, STM32_ADC_MAX_ADCS, 0,
@@ -343,8 +352,12 @@ static int 

[PATCH 0/3] Add support for STM32MP1 ADC

[Fabrice Gasnier]

Add support for STM32MP1 Analog to Digital Converter variant.
It's quite similar to STM32H7 ADC and re-use most of existing driver.

Fabrice Gasnier (3):
  dt-bindings: iio: stm32-adc: add support for STM32MP1.
  iio: adc: stm32-adc: add support for STM32MP1
  ARM: dts: stm32: Add ADC support to stm32mp157c

 .../devicetree/bindings/iio/adc/st,stm32-adc.txt   |  6 +-
 arch/arm/boot/dts/stm32mp157c.dtsi | 32 +++
 drivers/iio/adc/stm32-adc-core.c   | 66 --
 drivers/iio/adc/stm32-adc.c| 47 +--
 4 files changed, 128 insertions(+), 23 deletions(-)

-- 
1.9.1

[PATCH 3/3] ARM: dts: stm32: Add ADC support to stm32mp157c

[Fabrice Gasnier]

stm32mp157c has an ADC block with two physical ADCs.

Signed-off-by: Fabrice Gasnier 
---
 arch/arm/boot/dts/stm32mp157c.dtsi | 32 
 1 file changed, 32 insertions(+)

diff --git a/arch/arm/boot/dts/stm32mp157c.dtsi 
b/arch/arm/boot/dts/stm32mp157c.dtsi
index bc3eddc..7758a90 100644
--- a/arch/arm/boot/dts/stm32mp157c.dtsi
+++ b/arch/arm/boot/dts/stm32mp157c.dtsi
@@ -160,6 +160,38 @@
status = "disabled";
};
 
+   adc: adc@48003000 {
+   compatible = "st,stm32mp1-adc-core";
+   reg = <0x48003000 0x400>;
+   interrupts = ,
+;
+   clocks = < ADC12>, < ADC12_K>;
+   clock-names = "bus", "adc";
+   interrupt-controller;
+   #interrupt-cells = <1>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+
+   adc1: adc@0 {
+   compatible = "st,stm32mp1-adc";
+   #io-channel-cells = <1>;
+   reg = <0x0>;
+   interrupt-parent = <>;
+   interrupts = <0>;
+   status = "disabled";
+   };
+
+   adc2: adc@100 {
+   compatible = "st,stm32mp1-adc";
+   #io-channel-cells = <1>;
+   reg = <0x100>;
+   interrupt-parent = <>;
+   interrupts = <1>;
+   status = "disabled";
+   };
+   };
+
rcc: rcc@5000 {
compatible = "st,stm32mp1-rcc", "syscon";
reg = <0x5000 0x1000>;
-- 
1.9.1

[PATCH v5 04/23] ASoC: qdsp6: dt-bindings: Add q6afe dt bindings

[srinivas . kandagatla]

From: Srinivas Kandagatla 

This patch add DT bindings for AFE (Audio Frontend) DSP module.

Signed-off-by: Srinivas Kandagatla 
Reviewed-and-tested-by: Rohit kumar 
---
 .../devicetree/bindings/sound/qcom,q6afe.txt   | 88 ++
 include/dt-bindings/sound/qcom,q6afe.h | 31 
 2 files changed, 119 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/sound/qcom,q6afe.txt
 create mode 100644 include/dt-bindings/sound/qcom,q6afe.h

diff --git a/Documentation/devicetree/bindings/sound/qcom,q6afe.txt 
b/Documentation/devicetree/bindings/sound/qcom,q6afe.txt
new file mode 100644
index ..3925726a3319
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/qcom,q6afe.txt
@@ -0,0 +1,88 @@
+Qualcomm Audio Front End (Q6AFE) binding
+
+AFE is one of the APR audio service on Q6DSP
+Please refer to qcom,apr.txt for details of the common apr service bindings
+used by all apr services.
+
+- but must contain the following property:
+
+- compatible:
+   Usage: required
+   Value type: 
+   Definition: must be "qcom,afe-v."
+ Or "qcom,afe" where the version number can be queried
+ from DSP.
+ example "qcom,afe-v2.0"
+
+= AFE DAIs (Digial Audio Interface)
+"dais" subnode of the AFE node represents dai specific configuration
+
+- #sound-dai-cells
+   Usage: required
+   Value type: 
+   Definition: Must be 1
+
+- reg
+   Usage: required
+   Value type: 
+   Definition: Must be dai id
+
+- qcom,sd-lines
+   Usage: required for mi2s interface
+   Value type: 
+   Definition: Must be list of serial data lines used by this dai.
+   should be one or more of the 1-4 sd lines.
+
+= EXAMPLE
+
+q6afe {
+   compatible = "qcom,q6afe";
+   reg = ;
+
+   dais {
+   #sound-dai-cells = <1>;
+   hdmi@1 {
+   reg = <1>;
+   };
+
+   prim-mi2s-rx@16 {
+   reg = <16>;
+   qcom,sd-lines = <1 3>;
+   };
+
+   prim-mi2s-tx@17 {
+   reg = <17>;
+   qcom,sd-lines = <2>;
+   };
+
+   sec-mi2s-rx@18 {
+   reg = <18>;
+   qcom,sd-lines = <1 4>;
+   };
+
+   sec-mi2s-tx@19 {
+   reg = <19>;
+   qcom,sd-lines = <2>;
+   };
+
+   tert-mi2s-rx@20 {
+   reg = <20>;
+   qcom,sd-lines = <2 4>;
+   };
+
+   tert-mi2s-tx@21 {
+   reg = <21>;
+   qcom,sd-lines = <1>;
+   };
+
+   quat-mi2s-rx@22 {
+   reg = <22>;
+   qcom,sd-lines = <1>;
+   };
+
+   quat-mi2s-tx@23 {
+   reg = <23>;
+   qcom,sd-lines = <2>;
+   };
+   };
+};
diff --git a/include/dt-bindings/sound/qcom,q6afe.h 
b/include/dt-bindings/sound/qcom,q6afe.h
new file mode 100644
index ..3c7868394889
--- /dev/null
+++ b/include/dt-bindings/sound/qcom,q6afe.h
@@ -0,0 +1,31 @@
+// SPDX-License-Identifier: GPL-2.0
+#ifndef __DT_BINDINGS_Q6_AFE_H__
+#define __DT_BINDINGS_Q6_AFE_H__
+
+/* Audio Front End (AFE) virtual ports IDs */
+#define HDMI_RX1
+#define SLIMBUS_0_RX2
+#define SLIMBUS_0_TX3
+#define SLIMBUS_1_RX4
+#define SLIMBUS_1_TX5
+#define SLIMBUS_2_RX6
+#define SLIMBUS_2_TX7
+#define SLIMBUS_3_RX8
+#define SLIMBUS_3_TX9
+#define SLIMBUS_4_RX10
+#define SLIMBUS_4_TX11
+#define SLIMBUS_5_RX12
+#define SLIMBUS_5_TX13
+#define SLIMBUS_6_RX14
+#define SLIMBUS_6_TX15
+#define PRIMARY_MI2S_RX16
+#define PRIMARY_MI2S_TX17
+#define SECONDARY_MI2S_RX  18
+#define SECONDARY_MI2S_TX  19
+#define TERTIARY_MI2S_RX   20
+#define TERTIARY_MI2S_TX   21
+#define QUATERNARY_MI2S_RX 22
+#define QUATERNARY_MI2S_TX 23
+
+#endif /* __DT_BINDINGS_Q6_AFE_H__ */
+
-- 
2.16.2

[PATCH v5 01/23] soc: qcom dt-bindings: Add APR bus bindings

[srinivas . kandagatla]

From: Srinivas Kandagatla 

This patch add dt bindings for Qualcomm APR (Asynchronous Packet Router)
bus driver. This bus is used for communicating with DSP which provides
audio and various other services to cpu.

Signed-off-by: Srinivas Kandagatla 
---
 .../devicetree/bindings/soc/qcom/qcom,apr.txt  | 85 ++
 include/dt-bindings/soc/qcom,apr.h | 27 +++
 2 files changed, 112 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,apr.txt
 create mode 100644 include/dt-bindings/soc/qcom,apr.h

diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,apr.txt 
b/Documentation/devicetree/bindings/soc/qcom/qcom,apr.txt
new file mode 100644
index ..85cc0433fb00
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,apr.txt
@@ -0,0 +1,85 @@
+Qualcomm APR (Asynchronous Packet Router) binding
+
+This binding describes the Qualcomm APR. APR is a IPC protocol for
+communication between Application processor and QDSP. APR is mainly
+used for audio/voice services on the QDSP.
+
+- compatible:
+   Usage: required
+   Value type: 
+   Definition: must be "qcom,apr-v", example "qcom,apr-v2"
+
+- qcom,dest-domain-id
+   Usage: required
+   Value type: 
+   Definition: Destination processor ID.
+   Possible values are :
+   1 - APR simulator
+   2 - PC
+   3 - MODEM
+   4 - ADSP
+   5 - APPS
+   6 - MODEM2
+   7 - APPS2
+
+= APR SERVICES
+Each subnode of the APR node represents service tied to this apr. The name
+of the nodes are not important. The properties of these nodes are defined
+by the individual bindings for the specific service
+- All APR services MUST contain the following property:
+
+- reg
+   Usage: required
+   Value type: 
+   Definition: APR Service ID
+   Possible values are :
+   3 - DSP Core Service
+   4 - Audio Front End Service.
+   5 - Voice Stream Manager Service.
+   6 - Voice processing manager.
+   7 - Audio Stream Manager Service.
+   8 - Audio Device Manager Service.
+   9 - Multimode voice manager.
+   10 - Core voice stream.
+   11 - Core voice processor.
+   12 - Ultrasound stream manager.
+   13 - Listen stream manager.
+
+= EXAMPLE
+The following example represents a QDSP based sound card on a MSM8996 device
+which uses apr as communication between Apps and QDSP.
+
+   apr {
+   compatible = "qcom,apr-v2";
+   qcom,smd-channels = "apr_audio_svc";
+   qcom,dest-domain-id = ;
+
+   q6core {
+   compatible = "qcom,q6core";
+   reg = ;
+   };
+
+   q6afe {
+   compatible = "qcom,q6afe";
+   reg = ;
+
+   dais {
+   #sound-dai-cells = <1>;
+   hdmi@1 {
+   reg = <1>;
+   };
+   };
+   };
+
+   q6asm {
+   compatible = "qcom,q6asm";
+   reg = ;
+   ...
+   };
+
+   q6adm {
+   compatible = "qcom,q6adm";
+   reg = ;
+   ...
+   };
+   };
diff --git a/include/dt-bindings/soc/qcom,apr.h 
b/include/dt-bindings/soc/qcom,apr.h
new file mode 100644
index ..905503f81885
--- /dev/null
+++ b/include/dt-bindings/soc/qcom,apr.h
@@ -0,0 +1,27 @@
+#ifndef __DT_BINDINGS_QCOM_APR_H
+#define __DT_BINDINGS_QCOM_APR_H
+
+/* Domain IDs */
+#define APR_DOMAIN_SIM 0x1
+#define APR_DOMAIN_PC  0x2
+#define APR_DOMAIN_MODEM   0x3
+#define APR_DOMAIN_ADSP0x4
+#define APR_DOMAIN_APPS0x5
+#define APR_DOMAIN_MAX 0x6
+
+/* ADSP service IDs */
+#define APR_SVC_ADSP_CORE  0x3
+#define APR_SVC_AFE0x4
+#define APR_SVC_VSM0x5
+#define APR_SVC_VPM0x6
+#define APR_SVC_ASM0x7
+#define APR_SVC_ADM0x8
+#define APR_SVC_ADSP_MVM   0x09
+#define APR_SVC_ADSP_CVS   0x0A
+#define APR_SVC_ADSP_CVP   0x0B
+#define APR_SVC_USM0x0C
+#define APR_SVC_LSM0x0D
+#define APR_SVC_VIDC   0x16
+#define APR_SVC_MAX0x17
+
+#endif /* __DT_BINDINGS_QCOM_APR_H */
-- 
2.16.2

[RESEND PATCH v5 4/7] mfd: cros_ec_dev: Register cros-ec-rtc driver as a subdevice.

[Enric Balletbo i Serra]

Check whether this EC instance has RTC host command support and instatiate
the RTC driver as a subdevice in such case.

Signed-off-by: Enric Balletbo i Serra 
Reviewed-by: Gwendal Grignou 
Reviewed-by: Andy Shevchenko 
---

Changes in v5:
- [4/8] For mfd_cell struct use one line and no need for the comma.

Changes in v4:
- [4/8] Nit: check -> Check (Lee Jones)
- [4/8] Use ARRAY_SIZE() instead of hardcoded number (Lee Jones)

Changes in v3:
- [4/8] Add the Reviewed-by Andy Shevchenko.

Changes in v2:
- [4/8] Add the Reviewed-by Gwendal.

 drivers/mfd/cros_ec_dev.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/drivers/mfd/cros_ec_dev.c b/drivers/mfd/cros_ec_dev.c
index 5a7d4e1dea70..a393b3c11aa0 100644
--- a/drivers/mfd/cros_ec_dev.c
+++ b/drivers/mfd/cros_ec_dev.c
@@ -383,6 +383,10 @@ static void cros_ec_sensors_register(struct cros_ec_dev 
*ec)
kfree(msg);
 }
 
+static const struct mfd_cell cros_ec_rtc_cells[] = {
+   { .name = "cros-ec-rtc" }
+};
+
 static int ec_device_probe(struct platform_device *pdev)
 {
int retval = -ENOMEM;
@@ -422,6 +426,18 @@ static int ec_device_probe(struct platform_device *pdev)
if (cros_ec_check_features(ec, EC_FEATURE_MOTION_SENSE))
cros_ec_sensors_register(ec);
 
+   /* Check whether this EC instance has RTC host command support */
+   if (cros_ec_check_features(ec, EC_FEATURE_RTC)) {
+   retval = mfd_add_devices(ec->dev, PLATFORM_DEVID_AUTO,
+cros_ec_rtc_cells,
+ARRAY_SIZE(cros_ec_rtc_cells),
+NULL, 0, NULL);
+   if (retval)
+   dev_err(ec->dev,
+   "failed to add cros-ec-rtc device: %d\n",
+   retval);
+   }
+
/* Take control of the lightbar from the EC. */
lb_manual_suspend_ctrl(ec, 1);
 
-- 
2.17.0

[PATCH v1 3/4] clk: mediatek: add g3dsys support for MT2701 and MT7623

[sean.wang]

From: Sean Wang 

Add clock driver support for g3dsys on MT2701 and MT7623, which is
providing essential clock gate and reset controller to Mali-450.

Signed-off-by: Sean Wang 
---
 drivers/clk/mediatek/Kconfig  |  6 ++
 drivers/clk/mediatek/Makefile |  1 +
 drivers/clk/mediatek/clk-mt2701-g3d.c | 95 +++
 include/dt-bindings/clock/mt2701-clk.h|  4 ++
 include/dt-bindings/reset/mt2701-resets.h |  3 +
 5 files changed, 109 insertions(+)
 create mode 100644 drivers/clk/mediatek/clk-mt2701-g3d.c

diff --git a/drivers/clk/mediatek/Kconfig b/drivers/clk/mediatek/Kconfig
index 92afe59..3dd1dab 100644
--- a/drivers/clk/mediatek/Kconfig
+++ b/drivers/clk/mediatek/Kconfig
@@ -60,6 +60,12 @@ config COMMON_CLK_MT2701_AUDSYS
---help---
  This driver supports Mediatek MT2701 audsys clocks.
 
+config COMMON_CLK_MT2701_G3DSYS
+   bool "Clock driver for MediaTek MT2701 g3dsys"
+   depends on COMMON_CLK_MT2701
+   ---help---
+ This driver supports MediaTek MT2701 g3dsys clocks.
+
 config COMMON_CLK_MT2712
bool "Clock driver for MediaTek MT2712"
depends on (ARCH_MEDIATEK && ARM64) || COMPILE_TEST
diff --git a/drivers/clk/mediatek/Makefile b/drivers/clk/mediatek/Makefile
index b80eff2..844b55d 100644
--- a/drivers/clk/mediatek/Makefile
+++ b/drivers/clk/mediatek/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_COMMON_CLK_MT2701) += clk-mt2701.o
 obj-$(CONFIG_COMMON_CLK_MT2701_AUDSYS) += clk-mt2701-aud.o
 obj-$(CONFIG_COMMON_CLK_MT2701_BDPSYS) += clk-mt2701-bdp.o
 obj-$(CONFIG_COMMON_CLK_MT2701_ETHSYS) += clk-mt2701-eth.o
+obj-$(CONFIG_COMMON_CLK_MT2701_G3DSYS) += clk-mt2701-g3d.o
 obj-$(CONFIG_COMMON_CLK_MT2701_HIFSYS) += clk-mt2701-hif.o
 obj-$(CONFIG_COMMON_CLK_MT2701_IMGSYS) += clk-mt2701-img.o
 obj-$(CONFIG_COMMON_CLK_MT2701_MMSYS) += clk-mt2701-mm.o
diff --git a/drivers/clk/mediatek/clk-mt2701-g3d.c 
b/drivers/clk/mediatek/clk-mt2701-g3d.c
new file mode 100644
index 000..1328c11
--- /dev/null
+++ b/drivers/clk/mediatek/clk-mt2701-g3d.c
@@ -0,0 +1,95 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018 MediaTek Inc.
+ * Author: Sean Wang 
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "clk-mtk.h"
+#include "clk-gate.h"
+
+#include 
+
+#define GATE_G3D(_id, _name, _parent, _shift) {\
+   .id = _id,  \
+   .name = _name,  \
+   .parent_name = _parent, \
+   .regs = _cg_regs,   \
+   .shift = _shift,\
+   .ops = _clk_gate_ops_setclr,\
+   }
+
+static const struct mtk_gate_regs g3d_cg_regs = {
+   .sta_ofs = 0x0,
+   .set_ofs = 0x4,
+   .clr_ofs = 0x8,
+};
+
+static const struct mtk_gate g3d_clks[] = {
+   GATE_G3D(CLK_G3DSYS_CORE, "g3d_core", "mfg_sel", 0),
+};
+
+static int clk_mt2701_g3dsys_init(struct platform_device *pdev)
+{
+   struct clk_onecell_data *clk_data;
+   struct device_node *node = pdev->dev.of_node;
+   int r;
+
+   clk_data = mtk_alloc_clk_data(CLK_G3DSYS_NR);
+
+   mtk_clk_register_gates(node, g3d_clks, ARRAY_SIZE(g3d_clks),
+  clk_data);
+
+   r = of_clk_add_provider(node, of_clk_src_onecell_get, clk_data);
+   if (r)
+   dev_err(>dev,
+   "could not register clock provider: %s: %d\n",
+   pdev->name, r);
+
+   mtk_register_reset_controller(node, 1, 0xc);
+
+   return r;
+}
+
+static const struct of_device_id of_match_clk_mt2701_g3d[] = {
+   {
+   .compatible = "mediatek,mt2701-g3dsys",
+   .data = clk_mt2701_g3dsys_init,
+   }, {
+   /* sentinel */
+   }
+};
+
+static int clk_mt2701_g3d_probe(struct platform_device *pdev)
+{
+   int (*clk_init)(struct platform_device *);
+   int r;
+
+   clk_init = of_device_get_match_data(>dev);
+   if (!clk_init)
+   return -EINVAL;
+
+   r = clk_init(pdev);
+   if (r)
+   dev_err(>dev,
+   "could not register clock provider: %s: %d\n",
+   pdev->name, r);
+
+   return r;
+}
+
+static struct platform_driver clk_mt2701_g3d_drv = {
+   .probe = clk_mt2701_g3d_probe,
+   .driver = {
+   .name = "clk-mt2701-g3d",
+   .of_match_table = of_match_clk_mt2701_g3d,
+   },
+};
+
+builtin_platform_driver(clk_mt2701_g3d_drv);
diff --git a/include/dt-bindings/clock/mt2701-clk.h 
b/include/dt-bindings/clock/mt2701-clk.h
index 24e93df..2ac62a6 100644
--- a/include/dt-bindings/clock/mt2701-clk.h
+++ b/include/dt-bindings/clock/mt2701-clk.h
@@ -431,6 +431,10 @@
 #define CLK_ETHSYS_CRYPTO  8
 #define CLK_ETHSYS_NR  9
 
+/* 

[PATCH v1 2/4] dt-bindings: clock: mediatek: add g3dsys bindings

[sean.wang]

From: Sean Wang 

Add bindings to g3dsys providing necessary clock and reset control to
Mali-450.

Signed-off-by: Sean Wang 
---
 .../bindings/arm/mediatek/mediatek,g3dsys.txt  | 30 ++
 1 file changed, 30 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/arm/mediatek/mediatek,g3dsys.txt

diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,g3dsys.txt 
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,g3dsys.txt
new file mode 100644
index 000..ff2d70c
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,g3dsys.txt
@@ -0,0 +1,30 @@
+MediaTek g3dsys controller
+
+
+The MediaTek g3dsys controller provides various clocks and reset controller to
+the GPU.
+
+Required Properties:
+
+- compatible: Should be:
+   - "mediatek,mt2701-g3dsys", "syscon":
+   for MT2701 SoC
+   - "mediatek,mt7623-ethsys", "mediatek,mt2701-g3dsys", "syscon":
+   for MT7623 SoC
+- #clock-cells: Must be 1
+- #reset-cells: Must be 1
+
+The ethsys controller uses the common clk binding from
+Documentation/devicetree/bindings/clock/clock-bindings.txt
+The available clocks are defined in dt-bindings/clock/mt*-clk.h.
+
+Example:
+
+g3dsys: clock-controller@1300 {
+   compatible = "mediatek,mt7623-g3dsys",
+"mediatek,mt2701-g3dsys",
+"syscon";
+   reg = <0 0x1300 0 0x200>;
+   #clock-cells = <1>;
+   #reset-cells = <1>;
+};
-- 
2.7.4

[PATCH v1 1/4] dt-bindings: gpu: mali-utgard: add mediatek,mt7623-mali compatible

[sean.wang]

From: Sean Wang 

The MediaTek MT7623 SoC contains a Mali-450, so add a compatible for it
and define its own vendor-specific properties.

Signed-off-by: Sean Wang 
---
 Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt | 9 +
 1 file changed, 9 insertions(+)

diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt 
b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt
index c1f65d1..e149995 100644
--- a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt
+++ b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt
@@ -20,6 +20,7 @@ Required properties:
   + rockchip,rk3228-mali
   + rockchip,rk3328-mali
   + stericsson,db8500-mali
+  + mediatek,mt7623-mali
 
   - reg: Physical base address and length of the GPU registers
 
@@ -86,6 +87,14 @@ to specify one more vendor-specific compatible, among:
   * interrupt-names and interrupts:
 + combined: combined interrupt of all of the above lines
 
+  - mediatek,mt7623-mali
+ Required properties:
+  * resets: phandle to the reset line for the GPU
+  * mediatek,larb: phandle pointed to the local arbiter used to control the
+   access to external memory on the SoC.
+   see 
Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
+   for details
+
 Example:
 
 mali: gpu@1c4 {
-- 
2.7.4

Re: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver

[Oleksandr Andrushchenko]

On 04/18/2018 01:23 PM, Paul Durrant wrote:

-Original Message-
From: Oleksandr Andrushchenko [mailto:andr2...@gmail.com]
Sent: 18 April 2018 11:21
To: Paul Durrant ; Roger Pau Monne

Cc: jgr...@suse.com; Artem Mygaiev ;
Dongwon Kim ; airl...@linux.ie;
oleksandr_andrushche...@epam.com; linux-kernel@vger.kernel.org; dri-
de...@lists.freedesktop.org; Potrola, MateuszX
; xen-de...@lists.xenproject.org;
daniel.vet...@intel.com; boris.ostrov...@oracle.com; Matt Roper

Subject: Re: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy
helper DRM driver

On 04/18/2018 01:18 PM, Paul Durrant wrote:

-Original Message-
From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On

Behalf

Of Roger Pau Monné
Sent: 18 April 2018 11:11
To: Oleksandr Andrushchenko 
Cc: jgr...@suse.com; Artem Mygaiev ;
Dongwon Kim ; airl...@linux.ie;
oleksandr_andrushche...@epam.com; linux-kernel@vger.kernel.org;

dri-

de...@lists.freedesktop.org; Potrola, MateuszX
; xen-de...@lists.xenproject.org;
daniel.vet...@intel.com; boris.ostrov...@oracle.com; Matt Roper

Subject: Re: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy
helper DRM driver

On Wed, Apr 18, 2018 at 11:01:12AM +0300, Oleksandr Andrushchenko
wrote:

On 04/18/2018 10:35 AM, Roger Pau Monné wrote:

On Wed, Apr 18, 2018 at 09:38:39AM +0300, Oleksandr Andrushchenko

wrote:

On 04/17/2018 11:57 PM, Dongwon Kim wrote:

On Tue, Apr 17, 2018 at 09:59:28AM +0200, Daniel Vetter wrote:

On Mon, Apr 16, 2018 at 12:29:05PM -0700, Dongwon Kim wrote:

3.2 Backend exports dma-buf to xen-front

In this case Dom0 pages are shared with DomU. As before, DomU can

only write

to these pages, not any other page from Dom0, so it can be still

considered

safe.
But, the following must be considered (highlighted in xen-front's

Kernel

documentation):
    - If guest domain dies then pages/grants received from the backend

cannot

      be claimed back - think of it as memory lost to Dom0 (won't be used

for

any
      other guest)
    - Misbehaving guest may send too many requests to the backend

exhausting

      its grant references and memory (consider this from security POV).

As the

      backend runs in the trusted domain we also assume that it is

trusted

as

well,
      e.g. must take measures to prevent DDoS attacks.

I cannot parse the above sentence:

"As the backend runs in the trusted domain we also assume that it is
trusted as well, e.g. must take measures to prevent DDoS attacks."

What's the relation between being trusted and protecting from DoS
attacks?

I mean that we trust the backend that it can prevent Dom0
from crashing in case DomU's frontend misbehaves, e.g.
if the frontend sends too many memory requests etc.

In any case, all? PV protocols are implemented with the frontend
sharing pages to the backend, and I think there's a reason why this
model is used, and it should continue to be used.

This is the first use-case above. But there are real-world
use-cases (embedded in my case) when physically contiguous memory
needs to be shared, one of the possible ways to achieve this is
to share contiguous memory from Dom0 to DomU (the second use-case

above)

Having to add logic in the backend to prevent such attacks means
that:

- We need more code in the backend, which increases complexity and
  chances of bugs.
- Such code/logic could be wrong, thus allowing DoS.

You can live without this code at all, but this is then up to
backend which may make Dom0 down because of DomU's frontend

doing

evil

things

IMO we should design protocols that do not allow such attacks instead
of having to defend against them.


4. xen-front/backend/xen-zcopy synchronization

4.1. As I already said in 2) all the inter VM communication happens

between

xen-front and the backend, xen-zcopy is NOT involved in that.
When xen-front wants to destroy a display buffer (dumb/dma-buf) it

issues a

XENDISPL_OP_DBUF_DESTROY command (opposite to

XENDISPL_OP_DBUF_CREATE).

This call is synchronous, so xen-front expects that backend does free

the

buffer pages on return.

4.2. Backend, on XENDISPL_OP_DBUF_DESTROY:
     - closes all dumb handles/fd's of the buffer according to [3]
     - issues DRM_IOCTL_XEN_ZCOPY_DUMB_WAIT_FREE IOCTL to xen-

zcopy to make

sure
       the buffer is freed (think of it as it waits for dma-buf->release
callback)

So this zcopy thing keeps some kind of track of the memory usage?

Why

can't the user-space backend keep track of the buffer usage?

Because there is no dma-buf UAPI which allows to track the buffer life

cycle

(e.g. wait until dma-buf's .release callback is called)

     - replies to xen-front that the buffer can be destroyed.
This way deletion of the 

Re: [PATCH] sh: mm: Fix unprotected access to struct device

[Christoph Hellwig]

On Tue, Apr 17, 2018 at 03:35:23PM +0200, Jacopo Mondi wrote:
> With commit ce88313069c36eef80f21fd7 ("arch/sh: make the DMA mapping
> operations observe dev->dma_pfn_offset") the generic DMA allocation
> function on which the SH 'dma_alloc_coherent()' function relies on,
> access the 'dma_pfn_offset' field of struct device.
> 
> Unfortunately the 'dma_generic_alloc_coherent()' function is called from
> several places with a NULL struct device argument, halting the CPU
> during the boot process.
> 
> This patch fixes the issue protecting access to dev->dma_pfn_offset,
> with a trivial check for validity. It also passes a valid 'struct device'
> in the 'platform_resource_setup_memory' function which is the main user
> of 'dma_alloc_coherent()', and inserting a WARN_ON() check to make future
> (and existing) bogus users of this function they're should provide a valid
> 'struct device' whenever possible.

Please fix those callers to not pass a NULL pointer instead.

[PATCH v2 2/3] ASoC: amd: dma driver changes for BT I2S instance

[Vijendar Mukunda]

With in ACP, There are three I2S controllers can be
configured/enabled ( I2S SP, I2S MICSP, I2S BT).
Default enabled I2S controller instance is I2S SP.
This patch provides required changes to support I2S BT
controller Instance.

Signed-off-by: Vijendar Mukunda 
---
v1->v2: defined i2s instance macros in acp header file
 sound/soc/amd/Kconfig   |   1 +
 sound/soc/amd/acp-pcm-dma.c | 388 +++-
 sound/soc/amd/acp.h |  67 +++-
 3 files changed, 298 insertions(+), 158 deletions(-)

diff --git a/sound/soc/amd/Kconfig b/sound/soc/amd/Kconfig
index 6cbf9cf..6b7c620 100644
--- a/sound/soc/amd/Kconfig
+++ b/sound/soc/amd/Kconfig
@@ -1,5 +1,6 @@
 config SND_SOC_AMD_ACP
tristate "AMD Audio Coprocessor support"
+   select SND_DESIGNWARE_PCM
help
 This option enables ACP DMA support on AMD platform.
 
diff --git a/sound/soc/amd/acp-pcm-dma.c b/sound/soc/amd/acp-pcm-dma.c
index 5ffe2ef..7c392fe 100644
--- a/sound/soc/amd/acp-pcm-dma.c
+++ b/sound/soc/amd/acp-pcm-dma.c
@@ -23,6 +23,8 @@
 #include 
 #include "acp.h"
 
+#include "../dwc/local.h"
+
 #define DRV_NAME "acp_audio_dma"
 
 #define PLAYBACK_MIN_NUM_PERIODS2
@@ -37,13 +39,14 @@
 #define MAX_BUFFER (PLAYBACK_MAX_PERIOD_SIZE * PLAYBACK_MAX_NUM_PERIODS)
 #define MIN_BUFFER MAX_BUFFER
 
-#define ST_PLAYBACK_MAX_PERIOD_SIZE 8192
+#define ST_PLAYBACK_MAX_PERIOD_SIZE 4096
 #define ST_CAPTURE_MAX_PERIOD_SIZE  ST_PLAYBACK_MAX_PERIOD_SIZE
 #define ST_MAX_BUFFER (ST_PLAYBACK_MAX_PERIOD_SIZE * PLAYBACK_MAX_NUM_PERIODS)
 #define ST_MIN_BUFFER ST_MAX_BUFFER
 
 #define DRV_NAME "acp_audio_dma"
 
+
 static const struct snd_pcm_hardware acp_pcm_hardware_playback = {
.info = SNDRV_PCM_INFO_INTERLEAVED |
SNDRV_PCM_INFO_BLOCK_TRANSFER | SNDRV_PCM_INFO_MMAP |
@@ -317,54 +320,21 @@ static void acp_pte_config(void __iomem *acp_mmio, struct 
page *pg,
 }
 
 static void config_acp_dma(void __iomem *acp_mmio,
-  struct audio_substream_data *audio_config,
+  struct audio_substream_data *rtd,
   u32 asic_type)
 {
-   u32 pte_offset, sram_bank;
-   u16 ch1, ch2, destination, dma_dscr_idx;
-
-   if (audio_config->direction == SNDRV_PCM_STREAM_PLAYBACK) {
-   pte_offset = ACP_PLAYBACK_PTE_OFFSET;
-   ch1 = SYSRAM_TO_ACP_CH_NUM;
-   ch2 = ACP_TO_I2S_DMA_CH_NUM;
-   sram_bank = ACP_SHARED_RAM_BANK_1_ADDRESS;
-   destination = TO_ACP_I2S_1;
-
-   } else {
-   pte_offset = ACP_CAPTURE_PTE_OFFSET;
-   ch1 = SYSRAM_TO_ACP_CH_NUM;
-   ch2 = ACP_TO_I2S_DMA_CH_NUM;
-   switch (asic_type) {
-   case CHIP_STONEY:
-   sram_bank = ACP_SHARED_RAM_BANK_3_ADDRESS;
-   break;
-   default:
-   sram_bank = ACP_SHARED_RAM_BANK_5_ADDRESS;
-   }
-   destination = FROM_ACP_I2S_1;
-   }
-
-   acp_pte_config(acp_mmio, audio_config->pg, audio_config->num_of_pages,
-  pte_offset);
-   if (audio_config->direction == SNDRV_PCM_STREAM_PLAYBACK)
-   dma_dscr_idx = PLAYBACK_START_DMA_DESCR_CH12;
-   else
-   dma_dscr_idx = CAPTURE_START_DMA_DESCR_CH14;
-
+   acp_pte_config(acp_mmio, rtd->pg, rtd->num_of_pages,
+  rtd->pte_offset);
/* Configure System memory <-> ACP SRAM DMA descriptors */
-   set_acp_sysmem_dma_descriptors(acp_mmio, audio_config->size,
-  audio_config->direction, pte_offset, ch1,
-  sram_bank, dma_dscr_idx, asic_type);
-
-   if (audio_config->direction == SNDRV_PCM_STREAM_PLAYBACK)
-   dma_dscr_idx = PLAYBACK_START_DMA_DESCR_CH13;
-   else
-   dma_dscr_idx = CAPTURE_START_DMA_DESCR_CH15;
+   set_acp_sysmem_dma_descriptors(acp_mmio, rtd->size,
+  rtd->direction, rtd->pte_offset,
+  rtd->ch1, rtd->sram_bank,
+  rtd->dma_dscr_idx_1, asic_type);
/* Configure ACP SRAM <-> I2S DMA descriptors */
-   set_acp_to_i2s_dma_descriptors(acp_mmio, audio_config->size,
-  audio_config->direction, sram_bank,
-  destination, ch2, dma_dscr_idx,
-  asic_type);
+   set_acp_to_i2s_dma_descriptors(acp_mmio, rtd->size,
+  rtd->direction, rtd->sram_bank,
+  rtd->destination, rtd->ch2,
+  rtd->dma_dscr_idx_2, asic_type);
 }
 
 /* Start a given DMA channel transfer */
@@ -390,6 +360,9 @@ static void acp_dma_start(void __iomem *acp_mmio,
case 

[PATCH v2 1/3] ASoC: dwc: I2S Controller instance param added

[Vijendar Mukunda]

When multiple I2S controller instances created,
i2s_instance parameter refers to i2s controller instance value.

Signed-off-by: Vijendar Mukunda 
---
 v1->v2: removed acp dma driver specific macros from dwc header file
 include/sound/designware_i2s.h | 4 
 sound/soc/dwc/dwc-i2s.c| 1 +
 sound/soc/dwc/local.h  | 1 +
 3 files changed, 6 insertions(+)

diff --git a/include/sound/designware_i2s.h b/include/sound/designware_i2s.h
index 830f5ca..2a94e7c 100644
--- a/include/sound/designware_i2s.h
+++ b/include/sound/designware_i2s.h
@@ -44,6 +44,10 @@ struct i2s_platform_data {
int channel;
u32 snd_fmts;
u32 snd_rates;
+   /* i2s_instance parameter returns I2S controller instance value
+* when multiple I2S controllers instantiated
+*/
+   u32 i2s_instance;
 
#define DW_I2S_QUIRK_COMP_REG_OFFSET(1 << 0)
#define DW_I2S_QUIRK_COMP_PARAM1(1 << 1)
diff --git a/sound/soc/dwc/dwc-i2s.c b/sound/soc/dwc/dwc-i2s.c
index 65112b9..58f81a4 100644
--- a/sound/soc/dwc/dwc-i2s.c
+++ b/sound/soc/dwc/dwc-i2s.c
@@ -553,6 +553,7 @@ static int dw_configure_dai_by_pd(struct dw_i2s_dev *dev,
 
if (dev->quirks & DW_I2S_QUIRK_16BIT_IDX_OVERRIDE)
idx = 1;
+   dev->i2s_instance = pdata->i2s_instance;
/* Set DMA slaves info */
dev->play_dma_data.pd.data = pdata->play_dma_data;
dev->capture_dma_data.pd.data = pdata->capture_dma_data;
diff --git a/sound/soc/dwc/local.h b/sound/soc/dwc/local.h
index 91dc70a..e89e464 100644
--- a/sound/soc/dwc/local.h
+++ b/sound/soc/dwc/local.h
@@ -98,6 +98,7 @@ struct dw_i2s_dev {
u32 ccr;
u32 xfer_resolution;
u32 fifo_th;
+   u32 i2s_instance;
 
/* data related to DMA transfers b/w i2s and DMAC */
union dw_i2s_snd_dma_data play_dma_data;
-- 
2.7.4

[PATCH v2 3/3] ASoC: amd: enabling bt i2s config after acp reset

[Vijendar Mukunda]

On ST/CZ based platforms, for specific platform bt uart
mux to be defined for bt i2s.
By default, these pins will be used for uart.
After acp reset , it requires to reprogram bt i2s config
mux pins to enable bt i2s instance.
added bt i2s enablement sequence during acp init.

Signed-off-by: Vijendar Mukunda 
Signed-off-by: Akshu Agrawal 
---
v1->v2: fixed kbuild errors
 sound/soc/amd/acp-da7219-max98357a.c | 2 ++
 sound/soc/amd/acp-pcm-dma.c  | 9 +
 sound/soc/amd/acp.h  | 1 +
 3 files changed, 12 insertions(+)

diff --git a/sound/soc/amd/acp-da7219-max98357a.c 
b/sound/soc/amd/acp-da7219-max98357a.c
index b205c78..9ff2138 100644
--- a/sound/soc/amd/acp-da7219-max98357a.c
+++ b/sound/soc/amd/acp-da7219-max98357a.c
@@ -44,6 +44,7 @@
 
 static struct snd_soc_jack cz_jack;
 struct clk *da7219_dai_clk;
+extern int bt_pad_enable;
 
 static int cz_da7219_init(struct snd_soc_pcm_runtime *rtd)
 {
@@ -251,6 +252,7 @@ static int cz_probe(struct platform_device *pdev)
cz_card.name, ret);
return ret;
}
+   bt_pad_enable = device_property_read_bool(>dev, "bt-pad-enable");
return 0;
 }
 
diff --git a/sound/soc/amd/acp-pcm-dma.c b/sound/soc/amd/acp-pcm-dma.c
index 7c392fe..b52c660 100644
--- a/sound/soc/amd/acp-pcm-dma.c
+++ b/sound/soc/amd/acp-pcm-dma.c
@@ -46,6 +46,8 @@
 
 #define DRV_NAME "acp_audio_dma"
 
+bool bt_pad_enable = false;
+EXPORT_SYMBOL(bt_pad_enable);
 
 static const struct snd_pcm_hardware acp_pcm_hardware_playback = {
.info = SNDRV_PCM_INFO_INTERLEAVED |
@@ -525,6 +527,13 @@ static int acp_init(void __iomem *acp_mmio, u32 asic_type)
val &= ~ACP_SOFT_RESET__SoftResetAud_MASK;
acp_reg_write(val, acp_mmio, mmACP_SOFT_RESET);
 
+   /* For BT instance change pins from UART to BT */
+   if (bt_pad_enable) {
+   val = acp_reg_read(acp_mmio, mmACP_BT_UART_PAD_SEL);
+   val |= ACP_BT_UART_PAD_SELECT_MASK;
+   acp_reg_write(val, acp_mmio, mmACP_BT_UART_PAD_SEL);
+   }
+
/* initiailize Onion control DAGB register */
acp_reg_write(ACP_ONION_CNTL_DEFAULT, acp_mmio,
  mmACP_AXI2DAGB_ONION_CNTL);
diff --git a/sound/soc/amd/acp.h b/sound/soc/amd/acp.h
index 95c39a3..520a08f 100644
--- a/sound/soc/amd/acp.h
+++ b/sound/soc/amd/acp.h
@@ -110,6 +110,7 @@
 #define ACP_I2S_MIC_16BIT_RESOLUTION_EN 0x01
 #define ACP_I2S_SP_16BIT_RESOLUTION_EN 0x02
 #define ACP_I2S_BT_16BIT_RESOLUTION_EN 0x04
+#define ACP_BT_UART_PAD_SELECT_MASK0x1
 
 enum acp_dma_priority_level {
/* 0x0 Specifies the DMA channel is given normal priority */
-- 
2.7.4

Re: [PATCH v6 01/16] initrd: Add weakly-linked generic free_initrd_mem.

[Shea Levy]

Hi all,

Shea Levy  writes:

> This function is effectively identical across 14 architectures, and
> the generic implementation is small enough to be negligible in the
> architectures that do override it. Many of the remaining divergent
> implementations can be included in the common code path in future,
> further reducing code duplication and sharing improvements between
> architectures.
>
> Series boot-tested on RISC-V (which now uses the generic
> implementation) and x86_64 (which doesn't).
>
> v6: Add information about build/run testing.
> v5: Add more complete commit messages.
> v4: Use weak symbols instead of Kconfig.
> v3: Make the generic path opt-out instead of opt-in.
> v2: Mark generic free_initrd_mem __init.
>
> Signed-off-by: Shea Levy 
> ---
>  init/initramfs.c | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/init/initramfs.c b/init/initramfs.c
> index 7e99a0038942..c8fe150f958a 100644
> --- a/init/initramfs.c
> +++ b/init/initramfs.c
> @@ -526,6 +526,11 @@ extern unsigned long __initramfs_size;
>  #include 
>  #include 
>  
> +void __init __weak free_initrd_mem(unsigned long start, unsigned long end)
> +{
> +   free_reserved_area((void *)start, (void *)end, -1, "initrd");
> +}
> +
>  static void __init free_initrd(void)
>  {
>  #ifdef CONFIG_KEXEC_CORE
> -- 
> 2.16.2

This series has been quiet for a few weeks other than picking up some
arch-specific acks. What is the next step here?

Thanks,
Shea


signature.asc
Description: PGP signature

[PATCH] tty: nozomi: fix spelling mistake in macro NOZOMI_STATE_UKNOWN

[Colin King]

From: Colin Ian King 

Rename NOZOMI_STATE_UKNOWN to NOZOMI_STATE_UNKNOWN (add missing N)

Signed-off-by: Colin Ian King 
---
 drivers/tty/nozomi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/tty/nozomi.c b/drivers/tty/nozomi.c
index b57b35066ebe..bf05946d80a1 100644
--- a/drivers/tty/nozomi.c
+++ b/drivers/tty/nozomi.c
@@ -155,7 +155,7 @@ enum card_type {
 
 /* Initialization states a card can be in */
 enum card_state {
-   NOZOMI_STATE_UKNOWN = 0,
+   NOZOMI_STATE_UNKNOWN= 0,
NOZOMI_STATE_ENABLED= 1,/* pci device enabled */
NOZOMI_STATE_ALLOCATED  = 2,/* config setup done */
NOZOMI_STATE_READY  = 3,/* flowcontrols received */
-- 
2.17.0

Re: [patch v2] mm, oom: fix concurrent munlock and oom reaper unmap

[Tetsuo Handa]

Michal Hocko wrote:
> On Tue 17-04-18 19:52:41, David Rientjes wrote:
> > Since exit_mmap() is done without the protection of mm->mmap_sem, it is
> > possible for the oom reaper to concurrently operate on an mm until
> > MMF_OOM_SKIP is set.
> > 
> > This allows munlock_vma_pages_all() to concurrently run while the oom
> > reaper is operating on a vma.  Since munlock_vma_pages_range() depends on
> > clearing VM_LOCKED from vm_flags before actually doing the munlock to
> > determine if any other vmas are locking the same memory, the check for
> > VM_LOCKED in the oom reaper is racy.
> > 
> > This is especially noticeable on architectures such as powerpc where
> > clearing a huge pmd requires serialize_against_pte_lookup().  If the pmd
> > is zapped by the oom reaper during follow_page_mask() after the check for
> > pmd_none() is bypassed, this ends up deferencing a NULL ptl.
> > 
> > Fix this by reusing MMF_UNSTABLE to specify that an mm should not be
> > reaped.  This prevents the concurrent munlock_vma_pages_range() and
> > unmap_page_range().  The oom reaper will simply not operate on an mm that
> > has the bit set and leave the unmapping to exit_mmap().
> 
> This will further complicate the protocol and actually theoretically
> restores the oom lockup issues because the oom reaper doesn't set
> MMF_OOM_SKIP when racing with exit_mmap so we fully rely that nothing
> blocks there... So the resulting code is more fragile and tricky.
> 
> Can we try a simpler way and get back to what I was suggesting before
> [1] and simply not play tricks with
>   down_write(>mmap_sem);
>   up_write(>mmap_sem);
> 
> and use the write lock in exit_mmap for oom_victims?

You mean something like this?
Then, I'm tempted to call __oom_reap_task_mm() before holding mmap_sem for 
write.
It would be OK to call __oom_reap_task_mm() at the beginning of __mmput()...

diff --git a/mm/mmap.c b/mm/mmap.c
index 188f195..ba7083b 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -3011,17 +3011,22 @@ void exit_mmap(struct mm_struct *mm)
struct mmu_gather tlb;
struct vm_area_struct *vma;
unsigned long nr_accounted = 0;
+   const bool is_oom_mm = mm_is_oom_victim(mm);
 
/* mm's last user has gone, and its about to be pulled down */
mmu_notifier_release(mm);
 
if (mm->locked_vm) {
+   if (is_oom_mm)
+   down_write(>mmap_sem);
vma = mm->mmap;
while (vma) {
if (vma->vm_flags & VM_LOCKED)
munlock_vma_pages_all(vma);
vma = vma->vm_next;
}
+   if (is_oom_mm)
+   up_write(>mmap_sem);
}
 
arch_exit_mmap(mm);
@@ -3037,7 +3042,7 @@ void exit_mmap(struct mm_struct *mm)
/* Use -1 here to ensure all VMAs in the mm are unmapped */
unmap_vmas(, vma, 0, -1);
 
-   if (unlikely(mm_is_oom_victim(mm))) {
+   if (unlikely(is_oom_mm)) {
/*
 * Wait for oom_reap_task() to stop working on this
 * mm. Because MMF_OOM_SKIP is already set before

Re: [PATCH] x86/ldt: Fix support_pte_mask filtering in map_ldt_struct()

[Borislav Petkov]

+ Rafael.

On Mon, Apr 16, 2018 at 08:39:37AM -0700, Dave Hansen wrote:
> On 04/16/2018 08:16 AM, Andy Lutomirski wrote:
> > On Mon, Apr 16, 2018 at 2:43 AM, Joerg Roedel  wrote:
> >> From: Joerg Roedel 
> >>
> >> The |= operator will let us end up with an invalid PTE. Use
> >> the correct &= instead.
> > D'oh!  Looks good.
> 
> Yes, agreed.  Thanks for finding that, Joerg!

Btw, even with Jörg's fix,

fb43d6cb91ef ("x86/mm: Do not auto-massage page protections")

is still broken. In my case

# CONFIG_MODIFY_LDT_SYSCALL is not set

so Jörg's patch doesn't have any effect.

I tried the patch before fb43d6cb91ef:

6baf4bec02db ("x86/espfix: Document use of _PAGE_GLOBAL")

and the machine's fine. But with fb43d6cb91ef I can't resume from disk
properly and I'm seeing is the below splat:

[5.417480] PM: Image loading progress:   0%
[5.631174] PM: Image loading progress:  10%
[5.716705] PM: Image loading progress:  20%
[5.805258] PM: Image loading progress:  30%
[5.884919] random: crng init done
[5.899245] PM: Image loading progress:  40%
[5.980752] PM: Image loading progress:  50%
[6.058269] PM: Image loading progress:  60%
[6.138994] PM: Image loading progress:  70%
[6.219384] PM: Image loading progress:  80%
[6.299277] PM: Image loading progress:  90%
[6.382403] PM: Image loading progress: 100%
[6.386971] PM: Image loading done
[6.390424] PM: Read 598112 kbytes in 1.03 seconds (580.69 MB/s)
[6.397450] PM: Image successfully loaded
[6.631431] ACPI: EC: interrupt blocked
[6.635383] Disabling non-boot CPUs ...
[6.821452] [ cut here ]
[6.826115] kernel BUG at arch/x86/mm/physaddr.c:27!
[6.831126] invalid opcode:  [#1] PREEMPT SMP
[6.835872] Modules linked in:
[6.838976] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.16.0+ #6
[6.845026] Hardware name: To be filled by O.E.M. To be filled by 
O.E.M./M5A97 EVO R2.0, BIOS 1503 01/16/2013
[6.854996] RIP: 0010:__phys_addr+0x38/0x50
[6.859220] RSP: 0018:c9017dc8 EFLAGS: 00010087
[6.864490] RAX: 7800 RBX: 880426f5b000 RCX: 0030
[6.871667] RDX: 8000 RSI: 1fe46a1b RDI: 
[6.878841] RBP: c9017e48 R08:  R09: 0002
[6.886018] R10: 5ad731e5 R11: 02de R12: 0063
[6.893221] R13:  R14: 016001e3 R15: 
[6.900396] FS:  () GS:88043dc0() 
knlGS:
[6.908544] CS:  0010 DS:  ES:  CR0: 80050033
[6.914333] CR2: 88043efff000 CR3: 02209000 CR4: 000406f0
[6.921507] Call Trace:
[6.924007]  swsusp_arch_resume+0x112/0x3c0
[6.928235]  ? hibernate_resume_nonboot_cpu_disable+0x30/0x30
[6.934024]  ? save_processor_state+0xc9/0x250
[6.938514]  ? set_debug_rodata+0x11/0x11
[6.942570]  hibernation_restore+0x8d/0x130
[6.946797]  ? hibernation_restore+0x130/0x130
[6.951286]  load_image_and_restore+0x5e/0x99
[6.955690]  software_resume+0x20f/0x2a0
[6.959661]  do_one_initcall+0x5c/0x1b0
[6.963544]  kernel_init_freeable+0x123/0x1a5
[6.967945]  ? rest_init+0xc0/0xc0
[6.971394]  kernel_init+0xa/0x100
[6.974869]  ret_from_fork+0x27/0x50
[6.978518] Code: 48 89 c2 72 28 48 b8 00 00 00 00 00 78 00 00 48 01 f8 48 
39 c2 72 14 0f b6 0d fe e6 22 01 48 89 c2 48 d3 ea 48 85 d2 75 02 f3 c3 <0f> 0b 
48 8b 05 0f 71 16 01 48 01 d0 48 81 fa ff ff ff 1f 76 e9 
[6.997454] RIP: __phys_addr+0x38/0x50 RSP: c9017dc8
[7.003159] ---[ end trace 4b9d4661c2110f43 ]---
[7.007820] note: swapper/0[1] exited with preempt_count 1
[7.013353] Kernel panic - not syncing: Attempted to kill init! 
exitcode=0x000b
[7.013353] 
[7.022563] Kernel Offset: disabled
[7.026098] ---[ end Kernel panic - not syncing: Attempted to kill init! 
exitcode=0x000b
[7.026098]  ]---

-- 
Regards/Gruss,
Boris.

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

Re: [PATCH 2/2] x86, pti: fix boot warning from Global-bit setting

[kbuild test robot]

Hi Dave,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on tip/x86/core]
[also build test ERROR on v4.17-rc1 next-20180418]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Dave-Hansen/x86-pti-fix-boot-problems-from-Global-bit-setting/20180418-181719
config: i386-randconfig-a0-201815 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   arch/x86/mm/pageattr.c: In function '__cpa_pfn_in_highmap':
   arch/x86/mm/pageattr.c:1161:2: error: implicit declaration of function 
'highmap_start_pfn' [-Werror=implicit-function-declaration]
 return within_inclusive(pfn, highmap_start_pfn(),
 ^
>> arch/x86/mm/pageattr.c:1162:4: error: implicit declaration of function 
>> 'highmap_end_pfn' [-Werror=implicit-function-declaration]
   highmap_end_pfn());
   ^
   cc1: some warnings being treated as errors

vim +/highmap_end_pfn +1162 arch/x86/mm/pageattr.c

  1154  
  1155  bool __cpa_pfn_in_highmap(unsigned long pfn)
  1156  {
  1157  /*
  1158   * Kernel text has an alias mapping at a high address, known
  1159   * here as "highmap".
  1160   */
> 1161  return within_inclusive(pfn, highmap_start_pfn(),
> 1162  highmap_end_pfn());
  1163  }
  1164  

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


.config.gz
Description: application/gzip

Re: [RFC PATCH 1/3] signal: Ensure every siginfo we send has all bits initialized

[Dave Martin]

On Tue, Apr 17, 2018 at 02:37:38PM -0500, Eric W. Biederman wrote:
> Dave Martin  writes:
> 
> > Hmmm
> >
> > memset()/clear_siginfo() may ensure that there are no uninitialised
> > explicit fields except for those in inactive union members, but I'm not
> > sure that this approach is guaranteed to sanitise the padding seen by
> > userspace.
> >
> > Rationale below, though it's a bit theoretical...
> >
> > With this in mind, I tend agree with Linus that hiding memset() calls
> > from the maintainer may be a bad idea unless they are also hidden from
> > the compiler.  If the compiler sees the memset() it may be able to
> > optimise it in ways that wouldn't be possible for some other random
> > external function call, including optimising all or part of the call
> > out.
> >
> > As a result, the breakdown into individual put_user()s etc. in
> > copy_siginfo_to_user() may still be valuable even if all paths have the
> > memset().
> 
> The breakdown into individual put_user()s is known to be problematically
> slow, and is actually wrong.

Slowness certainly looked like a potential problem.

> Even exclusing the SI_USER duplication in a small number of cases the
> fields filled out in siginfo by architecture code are not the fields
> that copy_siginfo_to_user is copying.  Which is much worse.  The code
> looks safe but is not.
> 
> My intention is to leave 0 instances of clear_siginfo in the
> architecture specific code.  Ideally struct siginfo will be limited to
> kernel/signal.c but I am not certain I can quite get that far.
> The function do_coredump appears to have a legit need for siginfo.

So, you mean we can't detect that the caller didn't initialise all the
members, or initialised the wrong union member?

What would be the alternative?  Have a separate interface for each SIL_
type, with only kernel/signal.c translating that into the siginfo_t that
userspace sees?

Either way, I don't see how we force the caller to initilise the whole
structure.

> > (Rationale for an arch/arm example:)
> >
> >> diff --git a/arch/arm/vfp/vfpmodule.c b/arch/arm/vfp/vfpmodule.c
> >> index 4c375e11ae95..adda3fc2dde8 100644
> >> --- a/arch/arm/vfp/vfpmodule.c
> >> +++ b/arch/arm/vfp/vfpmodule.c
> >> @@ -218,8 +218,7 @@ static void vfp_raise_sigfpe(unsigned int sicode, 
> >> struct pt_regs *regs)
> >>  {
> >>siginfo_t info;
> >>  
> >> -  memset(, 0, sizeof(info));
> >> -
> >> +  clear_siginfo();
> >>info.si_signo = SIGFPE;
> >
> > /* by c11 (n1570) 6.2.6.1 para 6 [1], all padding bytes in info now take
> >unspecified values */
> >
> >>info.si_code = sicode;
> >>info.si_addr = (void __user *)(instruction_pointer(regs) - 4);
> >
> > /* by c11 (n1570) 6.2.6.1 para 7 [2], all bytes of the union info._sifields
> >other than than those corresponding to _sigfault take unspecified
> >values */
> >
> > So I don't see why the compiler needs to ensure that any of the affected
> > bytes are zero: it could potentially skip a lot of the memset() as a
> > result, in theory.
> >
> > I've not seen a compiler actually take advantage of that, but I'm now
> > not sure what forbids it.
> 
> I took a quick look at gcc-4.9 which I have handy.
> 
> The passes -f-no-strict-aliasing which helps, and gcc actually
> documents that if you access things through the union it will
> not take advantage of c11.
> 
> gcc-4.9 Documents it this way:
> 
> > -fstrict-aliasing'
> >  Allow the compiler to assume the strictest aliasing rules
> >  applicable to the language being compiled.  For C (and C++), this
> >  activates optimizations based on the type of expressions.  In
> >  particular, an object of one type is assumed never to reside at the
> >  same address as an object of a different type, unless the types are
> >  almost the same.  For example, an 'unsigned int' can alias an
> >  'int', but not a 'void*' or a 'double'.  A character type may alias
> >  any other type.
> > 
> >  Pay special attention to code like this:
> >   union a_union {
> > int i;
> > double d;
> >   };
> > 
> >   int f() {
> > union a_union t;
> > t.d = 3.0;
> > return t.i;
> >   }
> >  The practice of reading from a different union member than the one
> >  most recently written to (called "type-punning") is common.  Even
> >  with '-fstrict-aliasing', type-punning is allowed, provided the
> >  memory is accessed through the union type.  So, the code above
> >  works as expected.

This makes the C standard look precise (I love the "works as expected"),
and says nothing about the cumulative effect of assigning to multiple
members of a union, or about the effects on padding bytes.

I'm not convinced that all of this falls under strict-aliasing, but
I'd have to do more digging to confirm it.

> > If this can happen, I only see two watertight workarounds:
> >
> > 1) Ensure that there is no 

Re: [PATCH v2 1/3] ASoC: dwc: I2S Controller instance param added

[Mukunda,Vijendar]

On Wednesday 18 April 2018 04:54 PM, Mark Brown wrote:

On Wed, Apr 18, 2018 at 04:34:52PM +0530, Vijendar Mukunda wrote:

When multiple I2S controller instances created,
i2s_instance parameter refers to i2s controller instance value.


You're missing the point here a bit - it's not just the defines for the
magic numbers that are the problem, it's the whole idea of passing
instance numbers around like this that's the big problem.  Whatever you
are trying to do here is most likely better accomplished at the machine
driver level.  If I'm missing something here and this is a useful
concept to have in the driver it really needs to be articulated much
more clearly than in your very brief changelog, and most likely done at
the subsystem level (though the fact that we've managed to get this far
without needing it is a bit of a red flag).



In Audio Coprocessor (ACP), There are three I2S controllers can be
configured/enabled.(I2S SP, I2S MICSP, BT I2S)
Default enabled I2S controller instance is I2S SP instance.
There is a requirement to enable BT I2S controller Instance along with
I2S SP controller instance in one of our platforms Which has multiple 
codecs connected to each instance.


AMD GPU ACP driver creates devices for Playback and capture devices for 
both the I2S Controller instances using MFD framework.

Designware driver probe call gets invoked for every device creation with
resource information and platform data provided by GPU driver.

We have added one more parameter i2s instance to dwc platform data.
So that AMDGPU ACP Driver will pass I2S controller instance value to dwc 
driver while creating device nodes for I2S Controllers.


In ACP DMA Driver  acp_dma_open () call, We are retrieving dwc 
controller dev data as mentioned below.

dw_i2s_dev *dev = snd_soc_dai_get_drvdata(prtd->cpu_dai);

From dev->i2s_instance , ACP DMA Driver gets to know current I2S 
controller instance value.
We want to make ACP DMA driver platform independent one so that it will 
work across all platforms.


This is a generic implementation. Any platform which uses Designware I2S
controller can use this implementation when multiple I2S controller
instances are created.
This patch stores the I2S controller instance value in platform data.
Please suggest us, if there is any better way to handle it.

[PATCH v3 2/4] mfd: bd9571mwv: Add DDR Backup Power register bit definitions

[Geert Uytterhoeven]

Add definitions for the KEEPON_* bits in the "BKUP Mode Cnt" register,
which control the DDR rails to be kept powered when backup mode is
enabled.

Signed-off-by: Geert Uytterhoeven 
Acked-by: Lee Jones 
---
v3:
  - No changes,

v2:
  - Add Acked-by.
---
 include/linux/mfd/bd9571mwv.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/include/linux/mfd/bd9571mwv.h b/include/linux/mfd/bd9571mwv.h
index f0708ba4cbbae2dc..eb05569f752bb089 100644
--- a/include/linux/mfd/bd9571mwv.h
+++ b/include/linux/mfd/bd9571mwv.h
@@ -33,6 +33,11 @@
 #define BD9571MWV_I2C_MD2_E1_BIT_2 0x12
 
 #define BD9571MWV_BKUP_MODE_CNT0x20
+#define BD9571MWV_BKUP_MODE_CNT_KEEPON_MASKGENMASK(3, 0)
+#define BD9571MWV_BKUP_MODE_CNT_KEEPON_DDR0BIT(0)
+#define BD9571MWV_BKUP_MODE_CNT_KEEPON_DDR1BIT(1)
+#define BD9571MWV_BKUP_MODE_CNT_KEEPON_DDR0C   BIT(2)
+#define BD9571MWV_BKUP_MODE_CNT_KEEPON_DDR1C   BIT(3)
 #define BD9571MWV_BKUP_MODE_STATUS 0x21
 #define BD9571MWV_BKUP_RECOVERY_CNT0x22
 #define BD9571MWV_BKUP_CTRL_TIM_CNT0x23
-- 
2.7.4

[PATCH v3 3/4] mfd: bd9571mwv: Allow DDR Backup Power register access

[Geert Uytterhoeven]

Enable read/write access to the BD9571MWV_BKUP_MODE_CNT register, which
is amongst others used to configure DDR Backup Power.

Signed-off-by: Geert Uytterhoeven 
---
Acked-for-MFD-by: Lee Jones 

v3:
  - No changes,

v2:
  - Expand "a.o.",
  - Add Acked-for-MFD-by.
---
 drivers/mfd/bd9571mwv.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/mfd/bd9571mwv.c b/drivers/mfd/bd9571mwv.c
index 64e088dfe7b05b5b..503979c81dae11bb 100644
--- a/drivers/mfd/bd9571mwv.c
+++ b/drivers/mfd/bd9571mwv.c
@@ -29,6 +29,7 @@ static const struct mfd_cell bd9571mwv_cells[] = {
 
 static const struct regmap_range bd9571mwv_readable_yes_ranges[] = {
regmap_reg_range(BD9571MWV_VENDOR_CODE, BD9571MWV_PRODUCT_REVISION),
+   regmap_reg_range(BD9571MWV_BKUP_MODE_CNT, BD9571MWV_BKUP_MODE_CNT),
regmap_reg_range(BD9571MWV_AVS_SET_MONI, BD9571MWV_AVS_DVFS_VID(3)),
regmap_reg_range(BD9571MWV_VD18_VID, BD9571MWV_VD33_VID),
regmap_reg_range(BD9571MWV_DVFS_VINIT, BD9571MWV_DVFS_VINIT),
@@ -44,6 +45,7 @@ static const struct regmap_access_table 
bd9571mwv_readable_table = {
 };
 
 static const struct regmap_range bd9571mwv_writable_yes_ranges[] = {
+   regmap_reg_range(BD9571MWV_BKUP_MODE_CNT, BD9571MWV_BKUP_MODE_CNT),
regmap_reg_range(BD9571MWV_AVS_VD09_VID(0), BD9571MWV_AVS_VD09_VID(3)),
regmap_reg_range(BD9571MWV_DVFS_SETVID, BD9571MWV_DVFS_SETVID),
regmap_reg_range(BD9571MWV_GPIO_DIR, BD9571MWV_GPIO_OUT),
-- 
2.7.4

[PATCH v3 0/4] regulator: bd9571mwv: Add support for DDR backup mode

[Geert Uytterhoeven]

Hi all,

The ROHM BD9571MWV PMIC on the Renesas Salvator-X(S) and ULCB
development boards supports DDR Backup Power, which means that the DDR
power rails can be kept powered while the main SoC is powered down.

Currently performing a system suspend/resume cycle involves several
manual steps:
  1. Configure the PMIC for Backup Mode, using
 "i2cset -f -y 7 0x30 0x20 0x0f", which changes the role of the
 power switch to a wake-up switch,
  2. Switch off SW23 (the ACC toggle switch) to prepare for suspend
 (only on Salvator-X(S)),
  3. Suspend to RAM, using "echo mem > /sys/power/state",
  4. Switch on SW23 (on Salvator-X(S)) or push momentary switch SW8 (on
 ULCB) to resume.
Note the need for step 2 on systems equipped with a toggle instead of
momentary power switch.

Especially the first and second steps are cumbersome, as they rely on
  1. Intimate knowledge about the PMIC and actual board design,
  2. Direct i2c access,
  3. Having the i2cset utility available,
  4. A manual toggle switch operation (on Salvator-X(S)).
In addition, all of this has to be redone after system resume.

This patch series integrates Backup Mode configuration into the PMIC
driver, using the "wakeup" sysfs virtual file.  I.e. it can be enabled
or disabled by writing "enabled" or "disabled" to e.g.


/sys/devices/platform/soc/e60b.i2c/i2c-7/7-0030/bd9571mwv-regulator.2.auto/power/wakeup

Which DDR rails are to be kept powered is board-specific, and controlled
using the optional "rohm,ddr-backup-power" property in the board DTS
file.

As the power switch type is board-specific, and cannot be determined
automatically, it is obtained from the presence of one of the
"rohm,rstbmode-{pulse,level}" properties in DT.

For now only momentary power switches are supported, and wake-up is
enabled by default, as it doesn't have any run-time side-effects.
Support for toggle switches is added in a follow-up series ("[PATCH/RFC
0/2] regulator: bd9571mwv: Add support for toggle power switches",
https://lkml.org/lkml/2018/3/14/324).

Changes compared to v2:
  - Add Reviewed-by, Acked-for-MFD-by (for Lee's own reference),
  - Use a hex value for the bit mask.

Changes compared to v1:
  - Improve DT property description,
  - Add DT properties for power switch type,
  - Add Acked-by,
  - Use normal "wakeup" sysfs virtual file instead of adding our own
"backup_mode" file,
  - Differentiate between momentary and toggle power switches:
  - Support for momentary switches is enabled automatically,
  - Toggle switches are not yet supported (but still work when
backup mode is enabled using i2set from userspace).
  - Split off DTS part into its own series.

This has been tested on M3ULCB (thanks Jacopo!), and on Salvator-X(S)
(still using i2set from userspace).

For testing, driver and DTS patches are available in the
topic/bd9571-ddr-backup-mode-driver-v3 and
topic/bd9571-ddr-backup-mode-dt-v3 branches of my renesas-drivers git
repository at
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git.

Thanks for applying!

Geert Uytterhoeven (4):
  dt-bindings: mfd: bd9571mwv: Document DDR Backup Mode properties
  mfd: bd9571mwv: Add DDR Backup Power register bit definitions
  mfd: bd9571mwv: Allow DDR Backup Power register access
  regulator: bd9571mwv: Add support for backup mode

 .../devicetree/bindings/mfd/bd9571mwv.txt  |  21 
 drivers/mfd/bd9571mwv.c|   2 +
 drivers/regulator/bd9571mwv-regulator.c| 127 -
 include/linux/mfd/bd9571mwv.h  |   5 +
 4 files changed, 154 insertions(+), 1 deletion(-)

-- 
2.7.4

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

[PATCH v3 1/4] dt-bindings: mfd: bd9571mwv: Document DDR Backup Mode properties

[Geert Uytterhoeven]

Document the new optional properties related to DDR Backup Mode and
toggle/momentary power switches.

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Rob Herring 
---
Acked-for-MFD-by: Lee Jones 

v3:
  - Add Reviewed-by, Acked-for-MFD-by (for Lee's own reference),
  - Use a hex value for the bit mask,

v2:
  - Improve property description,
  - Add properties for power switch type.
---
 Documentation/devicetree/bindings/mfd/bd9571mwv.txt | 21 +
 1 file changed, 21 insertions(+)

diff --git a/Documentation/devicetree/bindings/mfd/bd9571mwv.txt 
b/Documentation/devicetree/bindings/mfd/bd9571mwv.txt
index 9ab216a851d5619b..25d1f697eb25c67d 100644
--- a/Documentation/devicetree/bindings/mfd/bd9571mwv.txt
+++ b/Documentation/devicetree/bindings/mfd/bd9571mwv.txt
@@ -25,6 +25,25 @@ Required properties:
Each child node is defined using the standard
binding for regulators.
 
+Optional properties:
+  - rohm,ddr-backup-power : Value to use for DDR-Backup Power (default 0).
+   This is a bitmask that specifies which DDR power
+   rails need to be kept powered when backup mode is
+   entered, for system suspend:
+ - bit 0: DDR0
+ - bit 1: DDR1
+ - bit 2: DDR0C
+ - bit 3: DDR1C
+   These bits match the KEEPON_DDR* bits in the
+   documentation for the "BKUP Mode Cnt" register.
+  - rohm,rstbmode-level: The RSTB signal is configured for level mode, to
+accommodate a toggle power switch (the RSTBMODE pin is
+strapped low).
+  - rohm,rstbmode-pulse: The RSTB signal is configured for pulse mode, to
+accommodate a momentary power switch (the RSTBMODE pin
+is strapped high).
+The two properties above are mutually exclusive.
+
 Example:
 
pmic: pmic@30 {
@@ -36,6 +55,8 @@ Example:
#interrupt-cells = <2>;
gpio-controller;
#gpio-cells = <2>;
+   rohm,ddr-backup-power = <0xf>;
+   rohm,rstbmode-pulse;
 
regulators {
dvfs: dvfs {
-- 
2.7.4

Re: [patch v2] mm, oom: fix concurrent munlock and oom reaper unmap

[Tetsuo Handa]

Michal Hocko wrote:
> > > Can we try a simpler way and get back to what I was suggesting before
> > > [1] and simply not play tricks with
> > >   down_write(>mmap_sem);
> > >   up_write(>mmap_sem);
> > > 
> > > and use the write lock in exit_mmap for oom_victims?
> > 
> > You mean something like this?
> 
> or simply hold the write lock until we unmap and free page tables.

That increases possibility of __oom_reap_task_mm() giving up reclaim and
setting MMF_OOM_SKIP when exit_mmap() is making forward progress, doesn't it?
I think that it is better that __oom_reap_task_mm() does not give up when
exit_mmap() can make progress. In that aspect, the section protected by
mmap_sem held for write should be as short as possible.

> It would make the locking rules much more straightforward.
> What you are proposing is more focused on this particular fix and it
> would work as well but the subtle locking would still stay in place.

Yes, this change is focused on -stable patch.

> I am not sure we want the trickiness.

I don't like the trickiness too. I think we can even consider direct OOM
reaping suggested at https://patchwork.kernel.org/patch/10095661/ .

> 
> > Then, I'm tempted to call __oom_reap_task_mm() before holding mmap_sem for 
> > write.
> > It would be OK to call __oom_reap_task_mm() at the beginning of __mmput()...
> 
> I am not sure I understand.

To reduce possibility of __oom_reap_task_mm() giving up reclaim and
setting MMF_OOM_SKIP.

Re: [PATCH 0/9] x86/dumpstack: Cleanups and user opcode bytes Code: section, v2

[Josh Poimboeuf]

On Tue, Apr 17, 2018 at 11:06:50PM +0200, Borislav Petkov wrote:
> On Tue, Apr 17, 2018 at 03:16:55PM -0500, Josh Poimboeuf wrote:
> > I don't think the stack tracing code could do anything better here.  #3
> > and #4 seem like an issue with the scheduler, it doesn't realize the
> > rest of the CPUs have all been taken offline due to the panic().
> 
> So maybe teach the WARN code to check whether a panic() has happened?

I get the feeling that disabling warnings could be papering over a real
bug, but maybe we don't care about bugs in the post-panic state?

Ideally we could just leave interrupts disabled, but I don't know if
that's generally feasible since it looks like sparc is waiting for
keyboard interrupts to allow breaking out to the boot prom.

-- 
Josh

Re: [PATCH] mm:memcg: add __GFP_NOWARN in __memcg_schedule_kmem_cache_create

[Michal Hocko]

On Wed 18-04-18 22:23:28, Minchan Kim wrote:
> On Wed, Apr 18, 2018 at 09:54:37AM +0200, Michal Hocko wrote:
> > On Wed 18-04-18 16:41:17, Minchan Kim wrote:
> > > On Wed, Apr 18, 2018 at 09:20:02AM +0200, Michal Hocko wrote:
> > > > On Wed 18-04-18 11:29:12, Minchan Kim wrote:
> > [...]
> > > > > Let's not make user scared.
> > > > 
> > > > This is not a proper explanation. So what exactly happens when this
> > > > allocation fails? I would suggest something like the following
> > > > "
> > > > __memcg_schedule_kmem_cache_create tries to create a shadow slab cache
> > > > and the worker allocation failure is not really critical because we will
> > > > retry on the next kmem charge. We might miss some charges but that
> > > > shouldn't be critical. The excessive allocation failure report is not
> > > > very much helpful. Replace it with a rate limited single line output so
> > > > that we know that there is a lot of these failures and that we need to
> > > > do something about it in future.
> > > > "
> > > > 
> > > > With the last part to be implemented of course.
> > > 
> > > If you want to see warning and catch on it in future, I don't see any 
> > > reason
> > > to change it. Because I didn't see any excessive warning output that it 
> > > could
> > > make system slow unless we did ratelimiting.
> > 
> > Yeah, but a single line would be as much informative and less scary to
> > users.
> > 
> > > It was a just report from non-MM guys who have a concern that somethings
> > > might go wrong on the system. I just wanted them relax since it's not
> > > critical.
> > 
> > I do agree with __GFP_NOWARN but I think a single line warning is due
> > and helpful for further debugging.
> 
> Okay, no problem. However, I don't feel we need ratelimit at this moment.
> We can do when we got real report. Let's add just one line warning.
> However, I have no talent to write a poem to express with one line.
> Could you help me?

What about
pr_info("Failed to create memcg slab cache. Report if you see floods of 
these\n");
 
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 671d07e73a3b..e26f85cac63f 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -2201,8 +2201,11 @@ static void __memcg_schedule_kmem_cache_create(struct 
> mem_cgroup *memcg,
> struct memcg_kmem_cache_create_work *cw;
> 
> cw = kmalloc(sizeof(*cw), GFP_NOWAIT | __GFP_NOWARN);
> -   if (!cw)
> +   if (!cw) {
> +   pr_warn("Fail to create shadow slab cache for memcg but it's 
> not critical.\n");
> +   pr_warn("If you see lots of this message, send an email to 
> linux...@kvack.org\n");
> return;
> +   }
> 
> css_get(>css);

-- 
Michal Hocko
SUSE Labs

Re: [PATCH 2/6] tracing: Add trace event error log

[Steven Rostedt]

On Wed, 18 Apr 2018 18:34:34 +0900
Masami Hiramatsu  wrote:

> On Fri, 13 Apr 2018 10:44:32 -0400
> Steven Rostedt  wrote:
> 
> > On Fri, 13 Apr 2018 09:24:34 -0500
> > Tom Zanussi  wrote:
> >   
> > > Yeah, I agree - I'd rather get it right than get it in now.  I thought
> > > this made sense, and was based on input from Masami, which I may have
> > > misinterpreted, but I'll wait for some more ideas about the best way to
> > > do this.  
> > 
> > Too bad we are not closer to November, as this would actually be a good
> > Plumbers topic. Maybe it's not that important and we should wait until
> > then. I'd like to get some brain storming ideas out before we decide on
> > anything, and this is something I believe is better done face to face
> > than over email.  
> 
> OK, sounds good for me too :)
> My point was that printk buffer is not good place for the parser error
> of ftrace, nor each sub-features (like hist, trigger, probe_events etc.) 
> has different place to show it. I just want to unify the user experience
> over the ftrace UI.

I totally agree. I just want to make sure that whatever we come up with
will be well thought out. Perhaps we can wait till November to talk
about it.

-- Steve

[PATCH -next] m68k: fix return value check in mcf_pci_init()

[Wei Yongjun]

In case of error, the function ioremap() returns NULL pointer not
ERR_PTR(). The IS_ERR() test in the return value check should be
replaced with NULL test.

Fixes: bf114d773167 ("m68k: force use of __raw_read/__raw_write address to be 
iomem")
Signed-off-by: Wei Yongjun 
---
 arch/m68k/coldfire/pci.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/m68k/coldfire/pci.c b/arch/m68k/coldfire/pci.c
index 9d6342c..a7c2332 100644
--- a/arch/m68k/coldfire/pci.c
+++ b/arch/m68k/coldfire/pci.c
@@ -218,7 +218,7 @@ static int __init mcf_pci_init(void)
 
/* Keep a virtual mapping to IO/config space active */
iospace = ioremap(PCI_IO_PA, PCI_IO_SIZE);
-   if (IS_ERR(iospace))
+   if (!iospace)
return -ENODEV;
pr_info("Coldfire: PCI IO/config window mapped to 0x%p\n", iospace);

Re: [RFC PATCH 31/35] Revert "vfs: add d_real_inode() helper"

[Steven Rostedt]

On Wed, 18 Apr 2018 15:49:02 +0200
Miklos Szeredi  wrote:


> > I just received this patch:
> >
> >  http://lkml.kernel.org/r/20180418062907.3210386-1-songliubrav...@fb.com
> >
> > Which removes this code. Can you review it and I'll take it.  
> 
> It shouldn't remove d_real_inode(), because that part is correct and
> fixes a real bug in handling overlayfs files.
> 
> I'll review, but apparently I wasn't CC-d on that patch.   Weird.

Especially since you are on the "Reported-by".

My scripts know to add to the Cc "Reported-by" tags. Not all scripts do
though :-/

-- Steve

Re: [PATCH] sched/fair: Change sched_feat(x) in !CONFIG_SCHED_DEBUG case

[Nicholas Mc Guire]

On Mon, Apr 16, 2018 at 10:54:26AM +0200, Philipp Klocke wrote:
> Make sched_feat(x) return 1 or 0 instead of 2**x or 0 when
> sysctl_sched_features is constant, by changing the left shift of the
> mask-bit to a right shift of the bitmap. The behaviour of the code
> remains unchanged.
> We prove this by showing that the compiler can evaluate this shift
> during compile time, which results in generating the same
> machine code as before.
> 
> This patch is motivated by the clang warning Wconstant-logical-operand,
> issued when logically comparing a variable to a constant integer that is
> neither 1 nor 0.  It happens for sched_feat(x) when sysctl_sched_features
> is constant, i.e., CONFIG_SCHED_DEBUG is not set.
> 
> kernel/sched/fair.c:3927:14: warning: use of logical '&&' with constant 
> operand [-Wconstant-logical-operand]
> if (initial && sched_feat(START_DEBIT))
> ^  ~~~
> kernel/sched/fair.c:3927:14: note: use '&' for a bitwise operation
> if (initial && sched_feat(START_DEBIT))
> ^~
> &
> kernel/sched/fair.c:3927:14: note: remove constant to silence this warning
> if (initial && sched_feat(START_DEBIT))
>~^~
> 
> This resolves the warning, leaves the code base largely as is.
> 
> Tested with gcc 7.3.1 and clang 6.0.0 on x86_64, comparing resulting
> binaries with diff.
> Applicable to all modern compilers and architectures
> 
> Signed-off-by: Philipp Klocke 
> Suggested-by: Lukas Bulwahn 
Reviewed-by: Nicholas Mc Guire 

> ---
>  kernel/sched/sched.h | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
> index fb5fc458547f..d2aedee6ab0f 100644
> --- a/kernel/sched/sched.h
> +++ b/kernel/sched/sched.h
> @@ -1305,7 +1305,11 @@ static const_debug __maybe_unused unsigned int 
> sysctl_sched_features =
>   0;
>  #undef SCHED_FEAT
>  
> +#ifdef CONFIG_SCHED_DEBUG
>  #define sched_feat(x) (sysctl_sched_features & (1UL << __SCHED_FEAT_##x))
> +#else
> +#define sched_feat(x) ((sysctl_sched_features >> __SCHED_FEAT_##x) & 1UL)
> +#endif
>  

The changed sched_feat(y) line is fine but I do not get/like the 
of the ifdef - keeping the change minimal is ok if there is a
relevant impact but here there is no effective difference (you write
the object code is the same for the !CONFIG_SCHED_DEBUG case)
So I think the ifdef should be kicked here and the proposed change
seems fine to me.

>  #endif /* SCHED_DEBUG && HAVE_JUMP_LABEL */
>  
> -- 
> 2.17.0
> 

[RESEND PATCH v5 7/7] mfd: cros_ec_i2c: moving the system sleep pm ops to late

[Enric Balletbo i Serra]

From: Joseph Lo 

The cros_ec_i2c driver is still active after it had suspended or before it
resumes. Besides that, it also tried to transfer data even after the I2C
host had been suspended. This will lead the system to crash.

During the test, we also observe that the EC needs to be resumed earlier
due to some status polling from the EC FW (e.g. battery status). So we
move the PM ops to late stage to make it work normally.

Signed-off-by: Joseph Lo 
Signed-off-by: Enric Balletbo i Serra 
Reviewed-by: Andy Shevchenko 
Acked-by: Lee Jones 
---

Changes in v5: None
Changes in v4:
- [8/8] Add Acked-by Lee Jones.

Changes in v3:
- [8/8] Add static to cros_ec_i2c_pm_ops.
- [8/8] Add the Reviewed-by Andy Shevchenko.

Changes in v2:
- [8/8] This patch is new in this series replacing [5/6] of v1.

 drivers/mfd/cros_ec_i2c.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/mfd/cros_ec_i2c.c b/drivers/mfd/cros_ec_i2c.c
index 02a7bacdc056..ef9b4763356f 100644
--- a/drivers/mfd/cros_ec_i2c.c
+++ b/drivers/mfd/cros_ec_i2c.c
@@ -342,8 +342,9 @@ static int cros_ec_i2c_resume(struct device *dev)
 }
 #endif
 
-static SIMPLE_DEV_PM_OPS(cros_ec_i2c_pm_ops, cros_ec_i2c_suspend,
- cros_ec_i2c_resume);
+static const struct dev_pm_ops cros_ec_i2c_pm_ops = {
+   SET_LATE_SYSTEM_SLEEP_PM_OPS(cros_ec_i2c_suspend, cros_ec_i2c_resume)
+};
 
 #ifdef CONFIG_OF
 static const struct of_device_id cros_ec_i2c_of_match[] = {
-- 
2.17.0

[PATCH v1 4/4] arm: dts: mt7623: add Mali-450 and related device nodes

[sean.wang]

From: Sean Wang 

Add nodes for Mali-450 device, g3dsys device providing required clock
gate and reset control and larb3 offering an arbiter through iommu for
controlling access to external memory requested from Mali-450.

Signed-off-by: Sean Wang 
---
 arch/arm/boot/dts/mt7623.dtsi  | 70 ++
 arch/arm/boot/dts/mt7623a.dtsi |  4 +++
 2 files changed, 74 insertions(+)

diff --git a/arch/arm/boot/dts/mt7623.dtsi b/arch/arm/boot/dts/mt7623.dtsi
index d1eb123..ace92b3 100644
--- a/arch/arm/boot/dts/mt7623.dtsi
+++ b/arch/arm/boot/dts/mt7623.dtsi
@@ -274,6 +274,17 @@
clock-names = "system-clk", "rtc-clk";
};
 
+   smi_common: smi@1000c000 {
+   compatible = "mediatek,mt7623-smi-common",
+"mediatek,mt2701-smi-common";
+   reg = <0 0x1000c000 0 0x1000>;
+   clocks = < CLK_INFRA_SMI>,
+< CLK_MM_SMI_COMMON>,
+< CLK_INFRA_SMI>;
+   clock-names = "apb", "smi", "async";
+   power-domains = < MT2701_POWER_DOMAIN_DISP>;
+   };
+
pwrap: pwrap@1000d000 {
compatible = "mediatek,mt7623-pwrap",
 "mediatek,mt2701-pwrap";
@@ -305,6 +316,17 @@
reg = <0 0x10200100 0 0x1c>;
};
 
+   iommu: iommu@10205000 {
+   compatible = "mediatek,mt7623-m4u",
+"mediatek,mt2701-m4u";
+   reg = <0 0x10205000 0 0x1000>;
+   interrupts = ;
+   clocks = < CLK_INFRA_M4U>;
+   clock-names = "bclk";
+   mediatek,larbs = <>;
+   #iommu-cells = <1>;
+   };
+
efuse: efuse@10206000 {
compatible = "mediatek,mt7623-efuse",
 "mediatek,mt8173-efuse";
@@ -680,6 +702,54 @@
status = "disabled";
};
 
+   g3dsys: clock-controller@1300 {
+   compatible = "mediatek,mt7623-g3dsys",
+"mediatek,mt2701-g3dsys",
+"syscon";
+   reg = <0 0x1300 0 0x200>;
+   #clock-cells = <1>;
+   #reset-cells = <1>;
+   };
+
+   larb3: larb@1301 {
+   compatible = "mediatek,mt7623-smi-larb",
+"mediatek,mt2701-smi-larb";
+   reg = <0 0x1301 0 0x1000>;
+   mediatek,smi = <_common>;
+   mediatek,larb-id = <3>;
+   clocks = <>, <>;
+   clock-names = "apb", "smi";
+   power-domains = < MT2701_POWER_DOMAIN_MFG>;
+   };
+
+   mali: gpu@1304 {
+   compatible = "mediatek,mt7623-mali", "arm,mali-450";
+   reg = <0 0x1304 0 0x3>;
+   interrupts = ,
+,
+,
+,
+,
+,
+,
+,
+;
+   interrupt-names = "gp", "gpmmu", "pp0", "ppmmu0", "pp1",
+ "ppmmu1", "pp2", "ppmmu2", "pp";
+   clocks = < CLK_TOP_MMPLL>,
+< CLK_G3DSYS_CORE>;
+   clock-names = "bus", "core";
+   power-domains = < MT2701_POWER_DOMAIN_MFG>;
+   mediatek,larb = <>;
+   resets = < MT2701_G3DSYS_CORE_RST>;
+   };
+
+   mmsys: syscon@1400 {
+   compatible = "mediatek,mt2701-mmsys", "syscon";
+   reg = <0 0x1400 0 0x1000>;
+   #clock-cells = <1>;
+   };
+
hifsys: syscon@1a00 {
compatible = "mediatek,mt7623-hifsys",
 "mediatek,mt2701-hifsys",
diff --git a/arch/arm/boot/dts/mt7623a.dtsi b/arch/arm/boot/dts/mt7623a.dtsi
index 0735a1fb8..a42fd46 100644
--- a/arch/arm/boot/dts/mt7623a.dtsi
+++ b/arch/arm/boot/dts/mt7623a.dtsi
@@ -21,6 +21,10 @@
power-domains = < MT7623A_POWER_DOMAIN_ETH>;
 };
 
+ {
+   status = "disabled";
+};
+
  {
power-domains = < MT7623A_POWER_DOMAIN_IFR_MSC>;
 };
-- 
2.7.4

[RESEND PATCH v5 6/7] mfd: cros_ec_i2c: add ACPI module device table

[Enric Balletbo i Serra]

From: Wei-Ning Huang 

Add ACPI module device table for matching cros-ec devices to load the
cros_ec_i2c driver automatically.

Signed-off-by: Wei-Ning Huang 
Acked-by: Benson Leung 
Signed-off-by: Enric Balletbo i Serra 
Reviewed-by: Gwendal Grignou 
Reviewed-by: Andy Shevchenko 
Acked-by: Lee Jones 
---

Changes in v5: None
Changes in v4:
- [7/8] Add Acked-by Lee Jones
- [7/8] Remove comma in terminator.

Changes in v3:
- [7/8] Add the Reviewed-by Andy Shevchenko.
- [7/8] Avoid commas in terminator entries.

Changes in v2:
- [7/8] Add the Reviewed-by Gwendal.

 drivers/mfd/cros_ec_dev.c |  2 +-
 drivers/mfd/cros_ec_i2c.c | 12 
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/mfd/cros_ec_dev.c b/drivers/mfd/cros_ec_dev.c
index 1f889523885d..1d6dc5c7a19d 100644
--- a/drivers/mfd/cros_ec_dev.c
+++ b/drivers/mfd/cros_ec_dev.c
@@ -482,7 +482,7 @@ static void ec_device_shutdown(struct platform_device *pdev)
 
 static const struct platform_device_id cros_ec_id[] = {
{ DRV_NAME, 0 },
-   { /* sentinel */ },
+   { /* sentinel */ }
 };
 MODULE_DEVICE_TABLE(platform, cros_ec_id);
 
diff --git a/drivers/mfd/cros_ec_i2c.c b/drivers/mfd/cros_ec_i2c.c
index 9f70de1e4c70..02a7bacdc056 100644
--- a/drivers/mfd/cros_ec_i2c.c
+++ b/drivers/mfd/cros_ec_i2c.c
@@ -13,6 +13,7 @@
  * GNU General Public License for more details.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -344,11 +345,13 @@ static int cros_ec_i2c_resume(struct device *dev)
 static SIMPLE_DEV_PM_OPS(cros_ec_i2c_pm_ops, cros_ec_i2c_suspend,
  cros_ec_i2c_resume);
 
+#ifdef CONFIG_OF
 static const struct of_device_id cros_ec_i2c_of_match[] = {
{ .compatible = "google,cros-ec-i2c", },
{ /* sentinel */ },
 };
 MODULE_DEVICE_TABLE(of, cros_ec_i2c_of_match);
+#endif
 
 static const struct i2c_device_id cros_ec_i2c_id[] = {
{ "cros-ec-i2c", 0 },
@@ -356,9 +359,18 @@ static const struct i2c_device_id cros_ec_i2c_id[] = {
 };
 MODULE_DEVICE_TABLE(i2c, cros_ec_i2c_id);
 
+#ifdef CONFIG_ACPI
+static const struct acpi_device_id cros_ec_i2c_acpi_id[] = {
+   { "GOOG0008", 0 },
+   { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(acpi, cros_ec_i2c_acpi_id);
+#endif
+
 static struct i2c_driver cros_ec_driver = {
.driver = {
.name   = "cros-ec-i2c",
+   .acpi_match_table = ACPI_PTR(cros_ec_i2c_acpi_id),
.of_match_table = of_match_ptr(cros_ec_i2c_of_match),
.pm = _ec_i2c_pm_ops,
},
-- 
2.17.0

[RESEND PATCH v5 1/7] mfd: cros_ec: fail early if we cannot identify the EC

[Enric Balletbo i Serra]

From: Vincent Palatin 

If we cannot communicate with the EC chip to detect the protocol version
and its features, it's very likely useless to continue. Else we will
commit all kind of uninformed mistakes (using the wrong protocol, the
wrong buffer size, mixing the EC with other chips).

Signed-off-by: Vincent Palatin 
Acked-by: Benson Leung 
Signed-off-by: Enric Balletbo i Serra 
Reviewed-by: Gwendal Grignou 
Reviewed-by: Andy Shevchenko 
Acked-by: Lee Jones 
---

Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 drivers/mfd/cros_ec.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
index d61024141e2b..74780f2964a1 100644
--- a/drivers/mfd/cros_ec.c
+++ b/drivers/mfd/cros_ec.c
@@ -112,7 +112,11 @@ int cros_ec_register(struct cros_ec_device *ec_dev)
 
mutex_init(_dev->lock);
 
-   cros_ec_query_all(ec_dev);
+   err = cros_ec_query_all(ec_dev);
+   if (err) {
+   dev_err(dev, "Cannot identify the EC: error %d\n", err);
+   return err;
+   }
 
if (ec_dev->irq) {
err = request_threaded_irq(ec_dev->irq, NULL, ec_irq_thread,
-- 
2.17.0

[PATCH v1 0/4] add Mali-450 support to MT7623 SoC

[sean.wang]

From: Sean Wang 

Hi,

The series adds a required resource setup to allow Mali-450 to work on
MT7623. This also can benefits other MediaTek SoCs having Mali-450 device.

In order to prove the setup is proper, I also have added mediatek port to
linux-lima at [1] and make a few of tests along with off-screen rendering
[2][3][4][5][6][7] through mesa-lima [8]. All work correctly.

[1] https://github.com/objelf/linux-lima/tree/mediatek-lima-4.16-rc5
[2] simple triangle: https://github.com/yuq/gfx/tree/master/gbm-surface
[3] vertex shader uniform: 
https://github.com/yuq/gfx/tree/master/gbm-surface-move
[4] multi varying: https://github.com/yuq/gfx/tree/master/gbm-surface-color
[5] multi draw: https://github.com/yuq/gfx/tree/master/gbm-surface-draw
[6] FBO: https://github.com/yuq/gfx/tree/master/gbm-surface-fbo
[7] kmscube: https://github.com/yuq/kmscube
[8] https://github.com/yuq/mesa-lima

Hope these patches can help people working on BPI-R2.

Sean

Sean Wang (4):
  dt-bindings: gpu: mali-utgard: add mediatek,mt7623-mali compatible
  dt-bindings: clock: mediatek: add g3dsys bindings
  clk: mediatek: add g3dsys support for MT2701 and MT7623
  arm: dts: mt7623: add Mali-450 and related device nodes

 .../bindings/arm/mediatek/mediatek,g3dsys.txt  | 30 +++
 .../devicetree/bindings/gpu/arm,mali-utgard.txt|  9 ++
 arch/arm/boot/dts/mt7623.dtsi  | 70 
 arch/arm/boot/dts/mt7623a.dtsi |  4 +
 drivers/clk/mediatek/Kconfig   |  6 ++
 drivers/clk/mediatek/Makefile  |  1 +
 drivers/clk/mediatek/clk-mt2701-g3d.c  | 95 ++
 include/dt-bindings/clock/mt2701-clk.h |  4 +
 include/dt-bindings/reset/mt2701-resets.h  |  3 +
 9 files changed, 222 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/arm/mediatek/mediatek,g3dsys.txt
 create mode 100644 drivers/clk/mediatek/clk-mt2701-g3d.c

-- 
2.7.4

[RESEND PATCH v5 5/7] mfd: cros_ec_dev: register shutdown function for debugfs

[Enric Balletbo i Serra]

From: Daniel Hung-yu Wu 

Reboot or shutdown during delayed works could corrupt communication with
EC and certain I2C controller may not be able to recover from the error
state.

This patch registers a shutdown callback used to cancel the debugfs log
worker thread.

Signed-off-by: Daniel Hung-yu Wu 
Signed-off-by: Enric Balletbo i Serra 
Reviewed-by: Andy Shevchenko 
Acked-by: Lee Jones 
---

Changes in v5: None
Changes in v4:
- [6/8] Add Acked-by Lee Jones.

Changes in v3:
- [6/8] Add the Reviewed-by Andy Shevchenko.

Changes in v2:
- [6/8] This patch is new in this series.

 drivers/mfd/cros_ec_dev.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/mfd/cros_ec_dev.c b/drivers/mfd/cros_ec_dev.c
index a393b3c11aa0..1f889523885d 100644
--- a/drivers/mfd/cros_ec_dev.c
+++ b/drivers/mfd/cros_ec_dev.c
@@ -472,6 +472,14 @@ static int ec_device_remove(struct platform_device *pdev)
return 0;
 }
 
+static void ec_device_shutdown(struct platform_device *pdev)
+{
+   struct cros_ec_dev *ec = dev_get_drvdata(>dev);
+
+   /* Be sure to clear up debugfs delayed works */
+   cros_ec_debugfs_remove(ec);
+}
+
 static const struct platform_device_id cros_ec_id[] = {
{ DRV_NAME, 0 },
{ /* sentinel */ },
@@ -514,6 +522,7 @@ static struct platform_driver cros_ec_dev_driver = {
},
.probe = ec_device_probe,
.remove = ec_device_remove,
+   .shutdown = ec_device_shutdown,
 };
 
 static int __init cros_ec_dev_init(void)
-- 
2.17.0

[PATCH v2 2/3] perf tools powerpc: Fix crash if callchain is empty

[Sandipan Das]

For some cases, the callchain provided by the kernel may be
empty. So, the callchain ip filtering code will cause a crash
if we do not check whether the struct ip_callchain pointer is
NULL before accessing any members.

This can be observed on a powerpc64le system running Fedora 27
as shown below.

 # perf record -b -e cycles:u ls
 # perf report --branch-history
 perf: Segmentation fault
  backtrace 
 perf[0x1027615c]
 linux-vdso64.so.1(__kernel_sigtramp_rt64+0x0)[0x7fff856304d8]
 perf(arch_skip_callchain_idx+0x44)[0x10257c58]
 perf[0x1017f2e4]
 perf(thread__resolve_callchain+0x124)[0x1017ff5c]
 perf(sample__resolve_callchain+0xf0)[0x10172788]
 ...

Reported-by: Ravi Bangoria 
Signed-off-by: Sandipan Das 
---
 tools/perf/arch/powerpc/util/skip-callchain-idx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/arch/powerpc/util/skip-callchain-idx.c 
b/tools/perf/arch/powerpc/util/skip-callchain-idx.c
index d3a13f79d3ee..910db8762120 100644
--- a/tools/perf/arch/powerpc/util/skip-callchain-idx.c
+++ b/tools/perf/arch/powerpc/util/skip-callchain-idx.c
@@ -262,7 +262,7 @@ int arch_skip_callchain_idx(struct thread *thread, struct 
ip_callchain *chain)
int rc;
u64 skip_slot = -1;
 
-   if (chain->nr < 3)
+   if (!chain || chain->nr < 3)
return skip_slot;
 
rc = check_return_addr(thread, chain->ips[1]);
-- 
2.14.3

[PATCH] net: caif: fix spelling mistake "UKNOWN" -> "UNKNOWN"

[Colin King]

From: Colin Ian King 

Trivial fix to spelling mistake

Signed-off-by: Colin Ian King 
---
 net/caif/chnl_net.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/caif/chnl_net.c b/net/caif/chnl_net.c
index 53ecda10b790..13e2ae6be620 100644
--- a/net/caif/chnl_net.c
+++ b/net/caif/chnl_net.c
@@ -174,7 +174,7 @@ static void chnl_flowctrl_cb(struct cflayer *layr, enum 
caif_ctrlcmd flow,
flow == CAIF_CTRLCMD_DEINIT_RSP ? "CLOSE/DEINIT" :
flow == CAIF_CTRLCMD_INIT_FAIL_RSP ? "OPEN_FAIL" :
flow == CAIF_CTRLCMD_REMOTE_SHUTDOWN_IND ?
-"REMOTE_SHUTDOWN" : "UKNOWN CTRL COMMAND");
+"REMOTE_SHUTDOWN" : "UNKNOWN CTRL COMMAND");
 
 
 
-- 
2.17.0

Re: [PATCH] gpu: drm: tegra: Adding new typedef vm_fault_t

[Souptick Joarder]

> This new function returns VM_FAULT_NOPAGE only for 0 and -EBUSY, whereas
> we used to return VM_FAULT_NOPAGE for -EAGAIN, -ERESTARTSYS and -EINTR
> as well.

Previously vm_insert_page unable to return VM_FAULT_ type due to which
different drivers
have their own mapping from err to VM_FAULT_ type. With new
vmf_insert_page() introduce
in 4.17-rc1 we have a common mapping for err to VM_FAULT_ which remain
same for every
drivers/file systems.

Was this previously wrong?

I think Matthew is the right person to answer this.

Re: [PATCHv3 06/11] asm-generic: mm_hooks: allow hooks to be overridden individually

[Mark Rutland]

On Tue, Apr 17, 2018 at 09:56:02PM +0200, Arnd Bergmann wrote:
> On Tue, Apr 17, 2018 at 8:37 PM, Mark Rutland  wrote:
> > Currently, an architecture must either implement all of the mm hooks
> > itself, or use all of those provided by the asm-generic implementation.
> > When an architecture only needs to override a single hook, it must copy
> > the stub implementations from the asm-generic version.
> >
> > To avoid this repetition, allow each hook to be overridden indiviually,
> > by placing each under an #ifndef block. As architectures providing their
> > own hooks can't include this file today, this shouldn't adversely affect
> > any existing hooks.
> >
> > Signed-off-by: Mark Rutland 
> > Cc: Arnd Bergmann 
> > Cc: linux-a...@vger.kernel.org
> 
> Acked-by: Arnd Bergmann 

Cheers!

Mark.