Re: [PATCH] HID: i2c-hid: Add a small delay after powering on/off the device

[Benjamin Tissoires]

On Mon, Oct 1, 2018 at 5:53 AM Kai-Heng Feng
 wrote:
>
> Raydium touchpanel (2386:4B33) sometimes does not workin desktop session
> although it works in display manager.
>
> During user logging, the display manager exits, close the HID device,
> then the device gets runtime suspended and powered off. The desktop
> session begins shortly after, opens the HID device, then the device gets
> runtime resumed and powered on.
>
> If the trasition from display manager to desktop sesesion is fast, the
> touchpanel cannot switch from powered off to powered on in short
> timeframe. So add a small delay to workaround the issue.

I think you want something similar to
https://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid.git/commit/?h=for-next&id=807588ac92018bde88a1958f546438e840eb0158

>
> Signed-off-by: Kai-Heng Feng 
> ---
>  drivers/hid/i2c-hid/i2c-hid.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/hid/i2c-hid/i2c-hid.c b/drivers/hid/i2c-hid/i2c-hid.c
> index f3076659361a..ff5682cc1bce 100644
> --- a/drivers/hid/i2c-hid/i2c-hid.c
> +++ b/drivers/hid/i2c-hid/i2c-hid.c
> @@ -409,6 +409,8 @@ static int i2c_hid_set_power(struct i2c_client *client, 
> int power_state)
>
> if (ret)
> dev_err(&client->dev, "failed to change power setting.\n");
> +   else
> +   msleep(20);

We shouldn't have this error in the first place, so adding a timeout
will just add a band-aid on top of an other issue.

I really think the solution from Anisse would work in your case and
will be nicer.

Cheers,
Benjamin

>
>  set_pwr_exit:
> return ret;
> --
> 2.17.1
>

Re: [RFC 1/2] ns: introduce binfmt_misc namespace

[Laurent Vivier]

Le 01/10/2018 à 03:21, Greg KH a écrit :
> On Mon, Oct 01, 2018 at 01:46:27AM +0200, Laurent Vivier wrote:
>> Signed-off-by: Laurent Vivier 
>> ---
> 
> I don't take patches without any changelog text, I don't know if other
> maintainers are as nice.  But for a new feature, you really should write
> something...

Yes, I know. But it's an RFC and all the explanations are in the cover
letter for now. I will fill the changelog once I know if the feature is
interesting or not.

Thank you for your comment.

Laurent

Re: [PATCH 2/2] Staging: rts5208: rtsx_chip: Fixed multiple coding style issues

[Dan Carpenter]

You can't have two patches with the same subject.

On Sat, Sep 29, 2018 at 12:43:54AM -0400, Maxime Desroches wrote:
> Fixed multiple braces issues
> Signed-off-by: Maxime Desroches 

Put a blank line between the patch description and the Signed-off-by

regards,
dan careptner

Re: [PATCH 1/2] Staging: rts5208: rtsx_card: Fixed multiple coding style issues

[Dan Carpenter]

On Sat, Sep 29, 2018 at 12:44:31AM -0400, Maxime Desroches wrote:
> Fixed multiple coding style issues
> 

Too vague.  Also inaccurate.

regards,
dan carpenter

Re: [PATCH 4/4] Staging: rts5208: sd: Fixed multiple coding style issues Fixed multiple braces issues

[Dan Carpenter]

Don't just add a 4/4 after a 3/3.  Send it as a new series instead.
Also the patch discription and sign off are missing.

regards,
dan carpenter

Re: [PATCH] HID: i2c-hid: Add a small delay after powering on/off the device

[Kai Heng Feng]

On Oct 1, 2018, at 3:00 PM, Benjamin Tissoires  
 wrote:


On Mon, Oct 1, 2018 at 5:53 AM Kai-Heng Feng
 wrote:

Raydium touchpanel (2386:4B33) sometimes does not workin desktop session
although it works in display manager.

During user logging, the display manager exits, close the HID device,
then the device gets runtime suspended and powered off. The desktop
session begins shortly after, opens the HID device, then the device gets
runtime resumed and powered on.

If the trasition from display manager to desktop sesesion is fast, the
touchpanel cannot switch from powered off to powered on in short
timeframe. So add a small delay to workaround the issue.


I think you want something similar to
https://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid.git/commit/?h=for-next&id=807588ac92018bde88a1958f546438e840eb0158


Signed-off-by: Kai-Heng Feng 
---
 drivers/hid/i2c-hid/i2c-hid.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/hid/i2c-hid/i2c-hid.c b/drivers/hid/i2c-hid/i2c-hid.c
index f3076659361a..ff5682cc1bce 100644
--- a/drivers/hid/i2c-hid/i2c-hid.c
+++ b/drivers/hid/i2c-hid/i2c-hid.c
@@ -409,6 +409,8 @@ static int i2c_hid_set_power(struct i2c_client  
*client, int power_state)


if (ret)
dev_err(&client->dev, "failed to change power setting.\n");
+   else
+   msleep(20);


We shouldn't have this error in the first place, so adding a timeout
will just add a band-aid on top of an other issue.

I really think the solution from Anisse would work in your case and
will be nicer.


The Hantick one requires 2.5 seconds delay, the Raydium one requires much  
less.

Also it doesn't have the input shift issue.

So disabling runtime PM entirely is a little overkill in this case.

Maybe there's a better approach?

Kai-Heng



Cheers,
Benjamin


 set_pwr_exit:
return ret;
--
2.17.1

Re: [RFC 0/2] ns: introduce binfmt_misc namespace

[Laurent Vivier]

Le 01/10/2018 à 06:45, Andy Lutomirski a écrit :
> On Sun, Sep 30, 2018 at 4:47 PM Laurent Vivier  wrote:
>>
>> This series introduces a new namespace for binfmt_misc.
>>
> 
> This seems conceptually quite reasonable, but I'm wondering if the
> number of namespace types is getting out of hand given the current
> API.  Should we be considering whether we need a new set of namespace
> creation APIs that scale better to larger numbers of namespace types?
> 

Yes, we need something to increase the maximum number of namespace types
because this is the last bit in the clone() flags and the time namespace
has already preempted it.

Thanks,
Laurent

Re: [RFC 0/2] ns: introduce binfmt_misc namespace

[Eric W. Biederman]

Andy Lutomirski  writes:

> On Sun, Sep 30, 2018 at 4:47 PM Laurent Vivier  wrote:
>>
>> This series introduces a new namespace for binfmt_misc.
>>
>
> This seems conceptually quite reasonable, but I'm wondering if the
> number of namespace types is getting out of hand given the current
> API.  Should we be considering whether we need a new set of namespace
> creation APIs that scale better to larger numbers of namespace types?

I would rather encourage a way to make this part of an existing
namespace or find a way to make a mount of binfmt_misc control this.

Hmm.  This looks like something that can be very straight forwardly be
made part of the user namespace.  If you ever mount binfmt_misc in the
user namespace you get the new behavior.  Otherwise you get the existing
behavior.

A user namespace will definitely be required, as otherwise you run the
risk of confusing root (and suid root exectuables0 by being able to
change the behavior of executables.

What is the motivation for this?  My impression is that very few people
tweak binfmt_misc.

I also don't think this raises to the level where it makes sense to
create a new namespace for this.

Eric

Re: [PATCH] regulator: core: Pass max_uV value to regulator_set_voltage_rdev

[Maciej Purski]

Hi all,
unfortunately, I don't work at kernel anymore. That would be great, if you 
could take over those patches and finish the 
work.
Best regards,
Maciej

On 09/29/2018 02:44 AM, Dmitry Osipenko wrote:
> On 9/29/18 3:27 AM, Tony Lindgren wrote:
>> * Dmitry Osipenko  [180928 23:55]:
>>> On 9/29/18 2:17 AM, Dmitry Osipenko wrote:
 On 9/29/18 1:41 AM, Tony Lindgren wrote:
> I'm still getting these errors after init:

 Thank you very much again, seems I got what's wrong with your case. The 
 ti-abb-regulator driver sets the "abb->current_info_idx = -EINVAL" on 
 probe and that value is getting updated only after the first voltage 
 change, hence _regulator_get_voltage() returns -22.
>>
>> OK that's starting to make some sense now thanks.
>>
 Please try this patch:
>>>
>>> I've revised the patch and here is the current final version.
>>
>> Hey cool this one works now :) I suggest you rework the whole series
>> with these fixes. I recall the series had a problem with git bisect
>> too between the patches. It will make life easier for other people
>> who may need to git bisect these patches.
> 
> Awesome! There are few other things in this patchset that also need fixing. 
> I've asked Maciej if he's going to continue working on the patches, waiting 
> for the answer. I can pick up the patches and try to finish the work if 
> necessary.
> 
> 

KASAN: use-after-free Read in snd_seq_ioctl_get_subscription

[syzbot]

Hello,

syzbot found the following crash on:

HEAD commit:e704966c45e4 Merge branch 'for-linus' of git://git.kernel...
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1277814e40
kernel config:  https://syzkaller.appspot.com/x/.config?x=a8212f992609a887
dashboard link: https://syzkaller.appspot.com/bug?extid=9437020c82413d00222d
compiler:   gcc (GCC) 8.0.1 20180413 (experimental)
userspace arch: i386

Unfortunately, I don't have any reproducer for this crash yet.

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+9437020c82413d002...@syzkaller.appspotmail.com

==
BUG: KASAN: use-after-free in snd_seq_ioctl_get_subscription+0x241/0x250  
sound/core/seq/seq_clientmgr.c:1913

Read of size 80 at addr 880198190300 by task syz-executor1/22402

CPU: 0 PID: 22402 Comm: syz-executor1 Not tainted 4.19.0-rc5+ #162
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011

Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x1c4/0x2b4 lib/dump_stack.c:113
 print_address_description.cold.8+0x9/0x1ff mm/kasan/report.c:256
 kasan_report_error mm/kasan/report.c:354 [inline]
 kasan_report.cold.9+0x242/0x309 mm/kasan/report.c:412
 __asan_report_load_n_noabort+0xf/0x20 mm/kasan/report.c:443
 snd_seq_ioctl_get_subscription+0x241/0x250  
sound/core/seq/seq_clientmgr.c:1913

 snd_seq_ioctl+0x253/0x440 sound/core/seq/seq_clientmgr.c:2138
 snd_seq_ioctl_compat+0x16c/0x2d0 sound/core/seq/seq_compat.c:123
 __do_compat_sys_ioctl fs/compat_ioctl.c:1419 [inline]
 __se_compat_sys_ioctl fs/compat_ioctl.c:1365 [inline]
 __ia32_compat_sys_ioctl+0x20e/0x630 fs/compat_ioctl.c:1365
 do_syscall_32_irqs_on arch/x86/entry/common.c:326 [inline]
 do_fast_syscall_32+0x34d/0xfb2 arch/x86/entry/common.c:397
 entry_SYSENTER_compat+0x70/0x7f arch/x86/entry/entry_64_compat.S:139
RIP: 0023:0xf7f2bca9
Code: 85 d2 74 02 89 0a 5b 5d c3 8b 04 24 c3 8b 0c 24 c3 8b 1c 24 c3 90 90  
90 90 90 90 90 90 90 90 90 90 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90  
90 90 90 eb 0d 90 90 90 90 90 90 90 90 90 90 90 90

RSP: 002b:f5f270cc EFLAGS: 0296 ORIG_RAX: 0036
RAX: ffda RBX: 0004 RCX: c0505350
RDX: 2140 RSI:  RDI: 
RBP:  R08:  R09: 
R10:  R11:  R12: 
R13:  R14:  R15: 

Allocated by task 22402:
 save_stack+0x43/0xd0 mm/kasan/kasan.c:448
 set_track mm/kasan/kasan.c:460 [inline]
 kasan_kmalloc+0xc7/0xe0 mm/kasan/kasan.c:553
 kmem_cache_alloc_trace+0x152/0x750 mm/slab.c:3620
 kmalloc include/linux/slab.h:513 [inline]
 kzalloc include/linux/slab.h:707 [inline]
 snd_seq_port_connect+0xe4/0x730 sound/core/seq/seq_ports.c:571
 snd_seq_ioctl_subscribe_port+0x1d8/0x310  
sound/core/seq/seq_clientmgr.c:1458

 snd_seq_ioctl+0x253/0x440 sound/core/seq/seq_clientmgr.c:2138
 snd_seq_ioctl_compat+0x16c/0x2d0 sound/core/seq/seq_compat.c:123
 __do_compat_sys_ioctl fs/compat_ioctl.c:1419 [inline]
 __se_compat_sys_ioctl fs/compat_ioctl.c:1365 [inline]
 __ia32_compat_sys_ioctl+0x20e/0x630 fs/compat_ioctl.c:1365
 do_syscall_32_irqs_on arch/x86/entry/common.c:326 [inline]
 do_fast_syscall_32+0x34d/0xfb2 arch/x86/entry/common.c:397
 entry_SYSENTER_compat+0x70/0x7f arch/x86/entry/entry_64_compat.S:139

Freed by task 22399:
 save_stack+0x43/0xd0 mm/kasan/kasan.c:448
 set_track mm/kasan/kasan.c:460 [inline]
 __kasan_slab_free+0x102/0x150 mm/kasan/kasan.c:521
 kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528
 __cache_free mm/slab.c:3498 [inline]
 kfree+0xcf/0x230 mm/slab.c:3813
 clear_subscriber_list+0x1ba/0x390 sound/core/seq/seq_ports.c:254
 port_delete+0x7c/0x1b0 sound/core/seq/seq_ports.c:270
 snd_seq_delete_all_ports+0x5fb/0x940 sound/core/seq/seq_ports.c:333
 seq_free_client1.part.9+0xcb/0x270 sound/core/seq/seq_clientmgr.c:262
 seq_free_client1 sound/core/seq/seq_clientmgr.c:256 [inline]
 seq_free_client+0x82/0x100 sound/core/seq/seq_clientmgr.c:285
 snd_seq_release+0x51/0xe0 sound/core/seq/seq_clientmgr.c:366
 __fput+0x385/0xa30 fs/file_table.c:278
 fput+0x15/0x20 fs/file_table.c:309
 task_work_run+0x1e8/0x2a0 kernel/task_work.c:113
 tracehook_notify_resume include/linux/tracehook.h:193 [inline]
 exit_to_usermode_loop+0x318/0x380 arch/x86/entry/common.c:166
 prepare_exit_to_usermode arch/x86/entry/common.c:197 [inline]
 syscall_return_slowpath arch/x86/entry/common.c:268 [inline]
 do_syscall_32_irqs_on arch/x86/entry/common.c:341 [inline]
 do_fast_syscall_32+0xcd5/0xfb2 arch/x86/entry/common.c:397
 entry_SYSENTER_compat+0x70/0x7f arch/x86/entry/entry_64_compat.S:139

The buggy address belongs to the object at 880198190300
 which belongs to the cache kmalloc-128 of size 128
The buggy address is located 0 bytes inside of
 128-byte region

[PATCH] MAINTAINERS: fix reference to STI CEC driver

[Benjamin Gaignard]

STI CEC driver has move from staging directory to media/platform/sti/cec/

Signed-off-by: Benjamin Gaignard 
---
 MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index b22e7fdfd2ea..8aa973410e2f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -13870,7 +13870,7 @@ F:  sound/soc/sti/
 STI CEC DRIVER
 M: Benjamin Gaignard 
 S: Maintained
-F: drivers/staging/media/st-cec/
+F: drivers/media/platform/sti/cec/
 F: Documentation/devicetree/bindings/media/stih-cec.txt
 
 STK1160 USB VIDEO CAPTURE DRIVER
-- 
2.15.0

Re: [PATCH v3 0/7] Remove errors building drivers/DRIVERNAME

[Robert Richter]

On 27.09.18 23:08:09, Leonardo Brás wrote:
> This Patchset changes some driver's Makefile to allow them building
> using the command 'make drivers/DRIVERNAME', if compatible.
> 
> The changed drivers would return error if the above command was run
> on them, after an x86 allyesconfig.

I don't see what you are trying to achieve here. Why shouldn't the
command fail if it is not the intended way to call it? There are a
couple of use cases where drivers/ is used to share common code over
different archs and it is not always the intention to build them in
drivers/ directly.

> 
> The main reason of this patchset is to allow building lists of
> drivers looking for warnings and errors to be fixed.

If a list is the intention here, aren't there other ways to create it
other than using drivers/*?

-Robert

> 
> I see this change as a new feature, not a bugfix. I understand
> the default bahavior may be building with a simple 'make', but I
> believe adding this new possibility will not be harmful.
> 
> My main objective is to allow developers with low processing power
> to do changes in the kernel and look bugs using free services like
> GiltabCI, before submitting to community.
> 
> If there is any interest helping/using this, I have a prototype in:
> https://gitlab.com/LeoBras/linux-next

Re: [linux-sunxi] Re: [PATCH 08/12] drm/sun4i: sun6i_mipi_dsi: Refactor vertical video start delay

[Jagan Teki]

On Saturday 29 September 2018 08:57 PM, Maxime Ripard wrote:

On Thu, Sep 27, 2018 at 11:03:19PM +0530, Jagan Teki wrote:

On Thu, Sep 27, 2018 at 10:44 PM Maxime Ripard
 wrote:


On Thu, Sep 27, 2018 at 05:18:46PM +0530, Jagan Teki wrote:

Accordingly to BPI-M64-bsp DE DSI code Video start delay
can be computed by subtracting total vertical timing with
front porch timing and with adding 1 delay line for TCON.


This is what the current code is doing as well.


The current code
return mode->vtotal - (mode->vsync_end - mode->vdisplay) + 1;

(mode->vsync_end - mode->vdisplay) = front porch + sync

but I'm updating here only front porch.




This patch simply add the start_delay logic from BPI-M64-bsp,
w/o this new computation, the DSI on A64 encounter vblank time out.

[CRTC:36:crtc-0] vblank wait timed out

Signed-off-by: Jagan Teki 
---
  drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 12 +++-
  1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c 
b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
index 9918fdb990ff..217db74c6dc3 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
@@ -358,7 +358,17 @@ static void sun6i_dsi_inst_init(struct sun6i_dsi *dsi,
  static u16 sun6i_dsi_get_video_start_delay(struct sun6i_dsi *dsi,
  struct drm_display_mode *mode)
  {
- return mode->vtotal - (mode->vsync_end - mode->vdisplay) + 1;
+ u32 vfp = mode->vsync_start - mode->vdisplay;


let me explain this.

Actual code from Allwinner
u32 vfp = panel->lcd_vt - panel->lcd_y - panel->lcd_vbp;

So,

=> (panel->lcd_vt - panel->lcd_y) - (panel->lcd_vbp)
=> (front porch + sync + back porch) - (back porch + sync)


Unless Allwinner is doing something fishy, in which case that should
be mentionned, the back porch doesn't contain the sync pulse.


As per as I understand panel->lcd_vbp is not back porch timings value 
which i used by drm. It is BSP DTS property value and actual back porch 
is calculated as "panel->lcd_vbp - panel->sync"


timmings->ver_sync_time= panel_info->lcd_vspw;
timmings->ver_back_porch= panel_info->lcd_vbp-panel_info->lcd_vspw;

INFO: task hung in process_measurement

[syzbot]

Hello,

syzbot found the following crash on:

HEAD commit:291d0e5d81e1 Merge tag 'for-linus-20180929' of git://git.k..
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=15232dc640
kernel config:  https://syzkaller.appspot.com/x/.config?x=a8212f992609a887
dashboard link: https://syzkaller.appspot.com/bug?extid=cdc562bc26a2b2b0a94f
compiler:   gcc (GCC) 8.0.1 20180413 (experimental)
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=140e285e40
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=1237fe8140

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+cdc562bc26a2b2b0a...@syzkaller.appspotmail.com

audit: type=1400 audit(1538324226.449:37): avc:  denied  { map } for   
pid=5529 comm="sh" path="/bin/dash" dev="sda1" ino=1473  
scontext=system_u:system_r:insmod_t:s0-s0:c0.c1023  
tcontext=system_u:object_r:file_t:s0 tclass=file permissive=1

INFO: task syz-executor101:5522 blocked for more than 140 seconds.
  Not tainted 4.19.0-rc5+ #40
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
syz-executor101 D23752  5522   5521 0x0004
Call Trace:
 context_switch kernel/sched/core.c:2825 [inline]
 __schedule+0x86c/0x1ed0 kernel/sched/core.c:3473
 schedule+0xfe/0x460 kernel/sched/core.c:3517
 __rwsem_down_write_failed_common+0xbb9/0x1670  
kernel/locking/rwsem-xadd.c:566

 rwsem_down_write_failed+0xe/0x10 kernel/locking/rwsem-xadd.c:595
 call_rwsem_down_write_failed+0x17/0x30 arch/x86/lib/rwsem.S:117
 __down_write arch/x86/include/asm/rwsem.h:142 [inline]
 down_write+0xa5/0x130 kernel/locking/rwsem.c:72
 inode_lock include/linux/fs.h:738 [inline]
 process_measurement+0xc3e/0x1bf0 security/integrity/ima/ima_main.c:205
 ima_file_check+0xe5/0x130 security/integrity/ima/ima_main.c:391
 do_last fs/namei.c:3422 [inline]
 path_openat+0x134d/0x5160 fs/namei.c:3534
 do_filp_open+0x255/0x380 fs/namei.c:3564
 do_sys_open+0x568/0x700 fs/open.c:1063
 ksys_open include/linux/syscalls.h:1276 [inline]
 __do_sys_creat fs/open.c:1121 [inline]
 __se_sys_creat fs/open.c:1119 [inline]
 __x64_sys_creat+0x61/0x80 fs/open.c:1119
 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
 entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x440ef9
Code: 67 00 00 00 00 00 00 00 00 49 6e 76 61 6c 69 64 20 22 24 4d 61 69 6e  
4d 73 67 51 75 65 75 65 44 65 71 75 65 75 65 54 69 6d 65 <45> 6e 64 22 2c  
20 65 72 72 6f 72 20 25 64 2e 20 49 67 6e 6f 72 65

RSP: 002b:7ffe712a3838 EFLAGS: 0213 ORIG_RAX: 0055
RAX: ffda RBX:  RCX: 00440ef9
RDX: 00440ef9 RSI:  RDI: 2000
RBP:  R08: 004002c8 R09: 004002c8
R10: 01e42880 R11: 0213 R12: 00401d90
R13: 00401e20 R14:  R15: 
INFO: task syz-executor101:5524 blocked for more than 140 seconds.
  Not tainted 4.19.0-rc5+ #40
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
syz-executor101 D23736  5524   5517 0x0004
Call Trace:
 context_switch kernel/sched/core.c:2825 [inline]
 __schedule+0x86c/0x1ed0 kernel/sched/core.c:3473
 schedule+0xfe/0x460 kernel/sched/core.c:3517
 __rwsem_down_write_failed_common+0xbb9/0x1670  
kernel/locking/rwsem-xadd.c:566

 rwsem_down_write_failed+0xe/0x10 kernel/locking/rwsem-xadd.c:595
 call_rwsem_down_write_failed+0x17/0x30 arch/x86/lib/rwsem.S:117
 __down_write arch/x86/include/asm/rwsem.h:142 [inline]
 down_write+0xa5/0x130 kernel/locking/rwsem.c:72
 inode_lock include/linux/fs.h:738 [inline]
 process_measurement+0x190f/0x1bf0 security/integrity/ima/ima_main.c:205
 ima_file_check+0xe5/0x130 security/integrity/ima/ima_main.c:391
 do_last fs/namei.c:3422 [inline]
 path_openat+0x134d/0x5160 fs/namei.c:3534
 do_filp_open+0x255/0x380 fs/namei.c:3564
 do_sys_open+0x568/0x700 fs/open.c:1063
 __do_sys_openat fs/open.c:1090 [inline]
 __se_sys_openat fs/open.c:1084 [inline]
 __x64_sys_openat+0x9d/0x100 fs/open.c:1084
 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
 entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x440ef9
Code: 67 00 00 00 00 00 00 00 00 49 6e 76 61 6c 69 64 20 22 24 4d 61 69 6e  
4d 73 67 51 75 65 75 65 44 65 71 75 65 75 65 54 69 6d 65 <45> 6e 64 22 2c  
20 65 72 72 6f 72 20 25 64 2e 20 49 67 6e 6f 72 65

RSP: 002b:7ffe712a3838 EFLAGS: 0207 ORIG_RAX: 0101
RAX: ffda RBX:  RCX: 00440ef9
RDX: 275a RSI: 2080 RDI: ff9c
RBP:  R08: 01e42880 R09: 004002c8
R10:  R11: 0207 R12: 00401d90
R13: 00401e20 R14:  R15: 
INFO: task syz-executor101:5525 blocked for more than 140 seconds.
  Not tainted 4.19.0-rc5+ #40
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
syz-executor101 D22824  5525   5520 0

Re: Bad MAINTAINERS pattern in section 'SAMSUNG EXYNOS TRUE RANDOM NUMBER GENERATOR (TRNG) DRIVER'

[Łukasz Stelmach]

It was <2018-09-29 sob 00:03>, when Joe Perches wrote:
> Please fix this defect appropriately.
>
> linux-next MAINTAINERS section:
>
>   12851   SAMSUNG EXYNOS TRUE RANDOM NUMBER GENERATOR (TRNG) DRIVER
>   12852   M:  Łukasz Stelmach 
>   12853   L:  linux-samsung-...@vger.kernel.org
>   12854   S:  Maintained
>   12855   F:  drivers/char/hw_random/exynos-trng.c
> -->   12856   F:  
> Documentation/devicetree/bindings/rng/samsung,exynos5250-trng.txt
>
> Commit that introduced this:
>
> commit 6cd225cc5d8a6526b2bea41955882be55d4f109e
>  Author: Łukasz Stelmach 
>  Date:   Fri Dec 22 17:48:35 2017 +0100
>  
>  hwrng: exynos - add Samsung Exynos True RNG driver
>  
>  Add support for True Random Number Generator found in Samsung Exynos
>  5250+ SoCs.
>  
>  Signed-off-by: Łukasz Stelmach 
>  Reviewed-by: Krzysztof Kozlowski 
>  Acked-by: Philippe Ombredanne 
>  Signed-off-by: Herbert Xu 
>  
>   MAINTAINERS  |   7 ++
>   drivers/char/hw_random/Kconfig   |  12 ++
>   drivers/char/hw_random/Makefile  |   1 +
>   drivers/char/hw_random/exynos-trng.c | 237 
> +++
>   4 files changed, 257 insertions(+)
>
> No commit with 
> Documentation/devicetree/bindings/rng/samsung,exynos5250-trng.txt found

Please merge the version 3[1] of the patch you've acked[2].

[1] https://www.spinics.net/lists/linux-samsung-soc/msg61372.html
[2] https://www.spinics.net/lists/linux-samsung-soc/msg61272.html
-- 
Łukasz Stelmach
Samsung R&D Institute Poland
Samsung Electronics


signature.asc
Description: PGP signature

[PATCH] kernel: jump_label: fix NULL dereference bug in __jump_label_mod_update()

[Ard Biesheuvel]

Commit 19483677684b ("jump_label: Annotate entries that operate on
__init code earlier") refactored the code that manages runtime
patching of jump labels in modules that are tied to static keys
defined in other modules or in the core kernel.

In the latter case, we may iterate over the static_key_mod linked
list until we hit the entry for the core kernel, whose 'mod' field
will be NULL, and attempt to dereference it to get at its 'state'
member.

So let's add a non-NULL check: this forces the 'init' argument of
__jump_label_update() to false for static keys that are defined in
the core kernel, which is appropriate given that __init annotated
jump_label entries in the core kernel should no longer be active
at this point (i.e., when loading modules).

Fixes: 19483677684b ("jump_label: Annotate entries that operate on ...")
Reported-by: Dan Carpenter 
Cc: Kees Cook 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Jessica Yu 
Cc: Peter Zijlstra 
Signed-off-by: Ard Biesheuvel 
---
 kernel/jump_label.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/jump_label.c b/kernel/jump_label.c
index e8cf3ff3149c..14a7f9881745 100644
--- a/kernel/jump_label.c
+++ b/kernel/jump_label.c
@@ -516,7 +516,7 @@ static void __jump_label_mod_update(struct static_key *key)
else
stop = m->jump_entries + m->num_jump_entries;
__jump_label_update(key, mod->entries, stop,
-   m->state == MODULE_STATE_COMING);
+   m && m->state == MODULE_STATE_COMING);
}
 }
 
-- 
2.17.1

Re: [RFC 5/5] MIPS: Add Realtek RTL8186 SoC support

[Marc Zyngier]

Hi Yasha,

On 30/09/18 15:15, Yasha Cherikovsky wrote:

The Realtek RTL8186 SoC is a MIPS based SoC
used in some home routers [1][2].

The hardware includes Lexra LX5280 CPU with a TLB,
two Ethernet controllers, a WLAN controller and more.

With this patch, it is possible to successfully boot
the kernel and load userspace on the Edimax BR-6204Wg
router.
Network drivers support will come in future patches.

This patch includes:
- New MIPS rtl8186 platform
 - Core platform setup code (mostly DT based)
 - New Kconfig option
 - defconfig file
 - MIPS zboot UART support
- RTL8186 interrupt controller driver
- RTL8186 timer driver
- Device tree files for the RTL8186 SoC and Edimax BR-6204Wg
   router

[1] https://www.linux-mips.org/wiki/Realtek_SOC#Realtek_RTL8186
[2] https://wikidevi.com/wiki/Realtek_RTL8186

Signed-off-by: Yasha Cherikovsky 
Cc: Ralf Baechle 
Cc: Paul Burton 
Cc: James Hogan 
Cc: Thomas Gleixner 
Cc: Jason Cooper 
Cc: Marc Zyngier 
Cc: Daniel Lezcano 
Cc: Rob Herring 
Cc: Mark Rutland 
Cc: linux-m...@linux-mips.org
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
  arch/mips/Kbuild.platforms|   1 +
  arch/mips/Kconfig |  17 ++
  arch/mips/boot/compressed/uart-16550.c|   5 +
  arch/mips/boot/dts/Makefile   |   1 +
  arch/mips/boot/dts/realtek/Makefile   |   4 +
  arch/mips/boot/dts/realtek/rtl8186.dtsi   |  86 +++
  .../dts/realtek/rtl8186_edimax_br_6204wg.dts  |  45 
  arch/mips/configs/rtl8186_defconfig   | 112 +
  arch/mips/include/asm/mach-rtl8186/rtl8186.h  |  37 +++
  arch/mips/rtl8186/Makefile|   2 +
  arch/mips/rtl8186/Platform|   7 +
  arch/mips/rtl8186/irq.c   |   8 +
  arch/mips/rtl8186/prom.c  |  15 ++
  arch/mips/rtl8186/setup.c |  80 +++
  arch/mips/rtl8186/time.c  |  10 +
  drivers/clocksource/Kconfig   |   9 +
  drivers/clocksource/Makefile  |   1 +
  drivers/clocksource/timer-rtl8186.c   | 220 ++
  drivers/irqchip/Kconfig   |   5 +
  drivers/irqchip/Makefile  |   1 +
  drivers/irqchip/irq-rtl8186.c | 107 +


Could you please split this into at least three patches (arch code, 
clocksource, irqchip) to ease the review?


Thanks,

M.
--
Jazz is not dead. It just smells funny...

Re: [PATCH] drivers: hid: Remove dead storage

[Benjamin Tissoires]

On Sat, Sep 29, 2018 at 6:06 PM Tapasweni Pathak
 wrote:
>
> Remove storing of return value of ntrig_version_string function
> to ret as it is a dead storage and not used afterwards.
>
> Found using Facebook's Infer. Build tested it.
>
> Signed-off-by: Tapasweni Pathak 
> ---
> There is another option to instead check for non zero return
> value for ntrig_version_string() as a successful completion
> of the function. ntrig_version_string() returns the length
> of output printed by sprintf() after converting the raw firmware
> code into a 5 comma separated numbers.

If you really want to fix this, I would prefer the alternative above.

Just one nitpick: please make sure ntrig_version_string() returns
either 0 (success) or a negative error.
Then in ntrig_report_version(), if the returned value is non null,
output a hid_warn() instead of leaking a non allocated buffer.

Cheers,
Benjamin

>
>  drivers/hid/hid-ntrig.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/hid/hid-ntrig.c b/drivers/hid/hid-ntrig.c
> index 43b1c72..22aebf4 100644
> --- a/drivers/hid/hid-ntrig.c
> +++ b/drivers/hid/hid-ntrig.c
> @@ -159,7 +159,7 @@ static void ntrig_report_version(struct hid_device *hdev)
>   USB_CTRL_SET_TIMEOUT);
>
> if (ret == 8) {
> -   ret = ntrig_version_string(&data[2], buf);
> +   ntrig_version_string(&data[2], buf);
>
> hid_info(hdev, "Firmware version: %s (%02x%02x %02x%02x)\n",
>  buf, data[2], data[3], data[4], data[5]);
> --
> 2.7.4

Build regressions/improvements in v4.19-rc6

[Geert Uytterhoeven]

Below is the list of build error/warning regressions/improvements in
v4.19-rc6[1] compared to v4.18[2].

Summarized:
  - build errors: +5/-3
  - build warnings: +14651/-253

JFYI, when comparing v4.19-rc6[1] to v4.19-rc5[3], the summaries are:
  - build errors: +0/-0
  - build warnings: +342/-387

Note that there may be false regressions, as some logs are incomplete.
Still, they're build errors/warnings.

Happy fixing! ;-)

Thanks to the linux-next team for providing the build service.

[1] 
http://kisskb.ellerman.id.au/kisskb/branch/linus/head/17b57b1883c1285f3d0dc2266e8f79286a7bef38/
 (all 240 configs)
[2] 
http://kisskb.ellerman.id.au/kisskb/branch/linus/head/94710cac0ef4ee177a63b5227664b38c95bbf703/
 (239 out of 240 configs)
[3] 
http://kisskb.ellerman.id.au/kisskb/branch/linus/head/6bf4ca7fbc85d80446ac01c0d1d77db4d91a6d84/
 (all 240 configs)


*** ERRORS ***

5 error regressions:
  + error: arch/sparc/kernel/.tmp_head_32.o: relocation truncated to fit: 
R_SPARC_WDISP22 against `.init.text':  => (.head.text+0x5040), 
(.head.text+0x5100)
  + error: arch/sparc/kernel/.tmp_head_32.o: relocation truncated to fit: 
R_SPARC_WDISP22 against symbol `leon_smp_cpu_startup' defined in .text section 
in arch/sparc/kernel/trampoline_32.o:  => (.init.text+0xa4)
  + error: arch/sparc/kernel/process_32.o: relocation truncated to fit: 
R_SPARC_WDISP22 against `.text':  => (.fixup+0xc), (.fixup+0x4)
  + error: arch/sparc/kernel/signal_32.o: relocation truncated to fit: 
R_SPARC_WDISP22 against `.text':  => (.fixup+0x0), (.fixup+0x18), 
(.fixup+0x10), (.fixup+0x8), (.fixup+0x20)
  + error: ene_ub6250.c: relocation truncated to fit: R_NDS32_9_PCREL_RELA 
against `.text':  => (.text+0x284)

3 error improvements:
  - error: "__sanitizer_cov_trace_cmpd" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] 
undefined!: N/A => 
  - error: "__sanitizer_cov_trace_cmpf" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] 
undefined!: N/A => 
  - error: "__sync_icache_dcache" [drivers/xen/xen-privcmd.ko] undefined!: N/A 
=> 


*** WARNINGS ***

[Deleted 14510 lines about "warning: -ffunction-sections disabled; it makes 
profiling impossible [enabled by default]" on powerpc-all{mod,yes}config*]

14651 warning regressions:
  + /kisskb/src/arch/alpha/kernel/osf_sys.c: warning: unused variable 'err' 
[-Wunused-variable]:  => 563:11
  + /kisskb/src/arch/alpha/kernel/osf_sys.c: warning: unused variable 'error' 
[-Wunused-variable]:  => 532:6
  + /kisskb/src/arch/arc/include/asm/cmpxchg.h: warning: value computed is not 
used [-Wunused-value]:  => 95:29
  + /kisskb/src/arch/mips/include/asm/sibyte/bcm1480_scd.h: warning: 
"M_SPC_CFG_CLEAR" redefined: 274:0 => 274, 274:0
  + /kisskb/src/arch/mips/include/asm/sibyte/bcm1480_scd.h: warning: 
"M_SPC_CFG_ENABLE" redefined: 275:0 => 275, 275:0
  + /kisskb/src/arch/powerpc/include/asm/io.h: warning: 'px_cmd' may be used 
uninitialized in this function [-Wmaybe-uninitialized]:  => 160:2
  + /kisskb/src/arch/powerpc/include/asm/io.h: warning: 'px_is' may be used 
uninitialized in this function [-Wmaybe-uninitialized]:  => 160:2
  + /kisskb/src/arch/s390/mm/pgtable.c: warning: 'pmd_alloc_map' defined but 
not used [-Wunused-function]:  => 413:15
  + 
/kisskb/src/drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_hw_sequencer.c:
 warning: (near initialization for 'blnd_cfg.black_color') [-Wmissing-braces]:  
=> 1903:9
  + 
/kisskb/src/drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_hw_sequencer.c:
 warning: missing braces around initializer [-Wmissing-braces]:  => 1903:9
  + /kisskb/src/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c: warning: (near 
initialization for 'task_info.process_name') [-Wmissing-braces]:  => 1447:10
  + /kisskb/src/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c: warning: missing braces 
around initializer [-Wmissing-braces]:  => 1447:10
  + /kisskb/src/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c: warning: (near 
initialization for 'task_info.process_name') [-Wmissing-braces]:  => 262:10
  + /kisskb/src/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c: warning: missing braces 
around initializer [-Wmissing-braces]:  => 262:10
  + /kisskb/src/drivers/gpu/drm/drm_atomic.c: warning: 'crtc_state' may be used 
uninitialized in this function [-Wuninitialized]:  => 760:38
  + /kisskb/src/drivers/gpu/drm/drm_atomic.c: warning: format '%zu' expects 
argument of type 'size_t', but argument 5 has type 'unsigned int' [-Wformat=]:  
=> 436:21
  + /kisskb/src/drivers/gpu/drm/i915/i915_irq.c: warning: 'gu_misc_iir' may be 
used uninitialized in this function [-Wuninitialized]:  => 3120:10
  + /kisskb/src/drivers/i2c/i2c-core-base.c: warning: 'ret' may be used 
uninitialized in this function [-Wmaybe-uninitialized]:  => 235:5
  + /kisskb/src/drivers/i2c/i2c-core-base.c: warning: 'ret' may be used 
uninitialized in this function [-Wuninitialized]:  => 235:5
  + /kisskb/src/drivers/iio/proximity/isl29501.c: warning: 'msb' may be used 
uninitialized in this function [-Wuninitialized]:  => 253:34, 253:7
  + /kisskb/src/drivers/md/dm-crypt.c: warni

Re: [PATCH] printk: inject caller information into the body of message

[Sergey Senozhatsky]

On (10/01/18 14:52), Sergey Senozhatsky wrote:
> On (09/29/18 20:13), Sergey Senozhatsky wrote:
> > We used to flush "incomplete" cont lines (fragments) from console_unlock().
> > 
> > void console_unlock(void)
> > {
> > ...
> > /* flush buffered message fragment immediately to console */
> > console_cont_flush(text, sizeof(text));
> > again:
> > for (;;) {
> > ...
> > }
> > ...
> > }
> > 
> > Unless I'm missing something, we don't anymore.
> > Since 5c2992ee7fd8a29d04125dc0aa3522784c5fa5eb.
> > Now we print only log_buf entries. So we either wait for a \n to flush
> > a complete cont buffer, or for a race to preliminary flush cont buffer.
> 
> BTW, it just crossed my mind:

One more thing.

Since we don't print cont fragments to the consoles anymore, do we still
need the "extended consoles disable kernel cont support" thing?

cont lines are proper log_buf entries now, there is nothing to reassemble
according to "consecutive continuation flags". Or am I wrong?

---

diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 308497194bd4..e72cb793aff1 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -192,16 +192,7 @@ int devkmsg_sysctl_set_loglvl(struct ctl_table *table, int 
write,
return 0;
 }
 
-/*
- * Number of registered extended console drivers.
- *
- * If extended consoles are present, in-kernel cont reassembly is disabled
- * and each fragment is stored as a separate log entry with proper
- * continuation flag so that every emitted message has full metadata.  This
- * doesn't change the result for regular consoles or /proc/kmsg.  For
- * /dev/kmsg, as long as the reader concatenates messages according to
- * consecutive continuation flags, the end result should be the same too.
- */
+/* Number of registered extended console drivers. */
 static int nr_ext_console_drivers;
 
 /*
@@ -1806,12 +1797,8 @@ static void cont_flush(void)
 
 static bool cont_add(int facility, int level, enum log_flags flags, const char 
*text, size_t len)
 {
-   /*
-* If ext consoles are present, flush and skip in-kernel
-* continuation.  See nr_ext_console_drivers definition.  Also, if
-* the line gets too long, split it up in separate records.
-*/
-   if (nr_ext_console_drivers || cont.len + len > sizeof(cont.buf)) {
+   /* If the line gets too long, split it up in separate records. */
+   if (cont.len + len > sizeof(cont.buf)) {
cont_flush();
return false;
}
@@ -2731,8 +2718,7 @@ void register_console(struct console *newcon)
}
 
if (newcon->flags & CON_EXTENDED)
-   if (!nr_ext_console_drivers++)
-   pr_info("printk: continuation disabled due to ext 
consoles, expect more fragments in /dev/kmsg\n");
+   nr_ext_console_drivers++;
 
if (newcon->flags & CON_PRINTBUFFER) {
/*
---

-ss

[PATCH] scripts: spdxcheck: resovle decode warning for python3

[Shubham Singh]

From: shubhsherl 

Resolve a warning issue by spdxcheck in Python3
FAIL: 'str' object has no attribute 'decode'

Signed-off-by: Shubham Singh 
---
 scripts/spdxcheck.py | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/scripts/spdxcheck.py b/scripts/spdxcheck.py
index 839e190bbd7a..6eea4073f28a 100755
--- a/scripts/spdxcheck.py
+++ b/scripts/spdxcheck.py
@@ -168,7 +168,8 @@ class id_parser(object):
 self.curline = 0
 try:
 for line in fd:
-line = line.decode(locale.getpreferredencoding(False), 
errors='ignore')
+if type(line) != str:
+line = line.decode(locale.getpreferredencoding(False), 
errors='ignore')
 self.curline += 1
 if self.curline > maxlines:
 break
-- 
2.18.0

Re: [PATCH] [v3] HID: add support for Apple Magic Trackpad 2

[Benjamin Tissoires]

[adding Peter, for the libinput question]

On Fri, Sep 21, 2018 at 1:13 AM Sean O'Brien  wrote:
>
> USB device
> Vendor 05ac (Apple)
> Device 0265 (Magic Trackpad 2)
> Bluetooth device
> Vendor 004c (Apple)
> Device 0265 (Magic Trackpad 2)
>
> Add support for Apple Magic Trackpad 2 over USB and bluetooth, putting
> the device in multi-touch mode.
>
> Signed-off-by: Claudio Mettler 
> Signed-off-by: Marek Wyborski 
> Signed-off-by: Sean O'Brien 
> ---
>

a few nitpcks:

>  drivers/hid/hid-ids.h|   1 +
>  drivers/hid/hid-magicmouse.c | 149 +++
>  2 files changed, 134 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
> index 5146ee029db4..bb0cd212c7cc 100644
> --- a/drivers/hid/hid-ids.h
> +++ b/drivers/hid/hid-ids.h
> @@ -92,6 +92,7 @@
>  #define USB_DEVICE_ID_APPLE_MIGHTYMOUSE0x0304
>  #define USB_DEVICE_ID_APPLE_MAGICMOUSE 0x030d
>  #define USB_DEVICE_ID_APPLE_MAGICTRACKPAD  0x030e
> +#define USB_DEVICE_ID_APPLE_MAGICTRACKPAD2 0x0265
>  #define USB_DEVICE_ID_APPLE_FOUNTAIN_ANSI  0x020e
>  #define USB_DEVICE_ID_APPLE_FOUNTAIN_ISO   0x020f
>  #define USB_DEVICE_ID_APPLE_GEYSER_ANSI0x0214
> diff --git a/drivers/hid/hid-magicmouse.c b/drivers/hid/hid-magicmouse.c
> index b454c4386157..6a3a6c83e509 100644
> --- a/drivers/hid/hid-magicmouse.c
> +++ b/drivers/hid/hid-magicmouse.c
> @@ -54,6 +54,8 @@ module_param(report_undeciphered, bool, 0644);
>  MODULE_PARM_DESC(report_undeciphered, "Report undeciphered multi-touch state 
> field using a MSC_RAW event");
>
>  #define TRACKPAD_REPORT_ID 0x28
> +#define TRACKPAD2_USB_REPORT_ID 0x02
> +#define TRACKPAD2_BT_REPORT_ID 0x31
>  #define MOUSE_REPORT_ID0x29
>  #define DOUBLE_REPORT_ID   0xf7
>  /* These definitions are not precise, but they're close enough.  (Bits
> @@ -91,6 +93,17 @@ MODULE_PARM_DESC(report_undeciphered, "Report undeciphered 
> multi-touch state fie
>  #define TRACKPAD_RES_Y \
> ((TRACKPAD_MAX_Y - TRACKPAD_MIN_Y) / (TRACKPAD_DIMENSION_Y / 100))
>
> +#define TRACKPAD2_DIMENSION_X (float)16000
> +#define TRACKPAD2_MIN_X -3678
> +#define TRACKPAD2_MAX_X 3934
> +#define TRACKPAD2_RES_X \
> +   ((TRACKPAD2_MAX_X - TRACKPAD2_MIN_X) / (TRACKPAD2_DIMENSION_X / 100))
> +#define TRACKPAD2_DIMENSION_Y (float)11490
> +#define TRACKPAD2_MIN_Y -2478
> +#define TRACKPAD2_MAX_Y 2587
> +#define TRACKPAD2_RES_Y \
> +   ((TRACKPAD2_MAX_Y - TRACKPAD2_MIN_Y) / (TRACKPAD2_DIMENSION_Y / 100))
> +
>  /**
>   * struct magicmouse_sc - Tracks Magic Mouse-specific data.
>   * @input: Input device through which we report events.
> @@ -183,6 +196,7 @@ static void magicmouse_emit_touch(struct magicmouse_sc 
> *msc, int raw_id, u8 *tda
>  {
> struct input_dev *input = msc->input;
> int id, x, y, size, orientation, touch_major, touch_minor, state, 
> down;
> +   int pressure = 0;
>
> if (input->id.product == USB_DEVICE_ID_APPLE_MAGICMOUSE) {
> id = (tdata[6] << 2 | tdata[5] >> 6) & 0xf;
> @@ -194,6 +208,20 @@ static void magicmouse_emit_touch(struct magicmouse_sc 
> *msc, int raw_id, u8 *tda
> touch_minor = tdata[4];
> state = tdata[7] & TOUCH_STATE_MASK;
> down = state != TOUCH_STATE_NONE;
> +   } else if (input->id.product == USB_DEVICE_ID_APPLE_MAGICTRACKPAD2) {
> +   id = tdata[8] & 0xf;
> +   x = (tdata[1] << 27 | tdata[0] << 19) >> 19;
> +   y = -((tdata[3] << 30 | tdata[2] << 22 | tdata[1] << 14) >> 
> 19);
> +   size = tdata[6];
> +   orientation = (tdata[8] >> 5) - 4;
> +   touch_major = tdata[4];
> +   touch_minor = tdata[5];
> +   /* Add to pressure to prevent libraries such as libinput
> +* from ignoring low pressure touches
> +*/
> +   pressure = tdata[7] + 30;

Peter, can you have a look?

To me, while adding this threshold, you are basically fooling
userspace, and we might want to come back to the raw values at some
point.
If there is a userspace problem, it has to be solved in userspace.

> +   state = tdata[3] & 0xC0;
> +   down = state == 0x80;
> } else { /* USB_DEVICE_ID_APPLE_MAGICTRACKPAD */
> id = (tdata[7] << 2 | tdata[6] >> 6) & 0xf;
> x = (tdata[1] << 27 | tdata[0] << 19) >> 19;
> @@ -215,7 +243,8 @@ static void magicmouse_emit_touch(struct magicmouse_sc 
> *msc, int raw_id, u8 *tda
> /* If requested, emulate a scroll wheel by detecting small
>  * vertical touch motions.
>  */
> -   if (emulate_scroll_wheel) {
> +   if (emulate_scroll_wheel && (input->id.product !=
> +   USB_DEVICE_ID_APPLE_MAGICTRACKPAD2)) {
> unsigned long now = jiffies;
> int step_x = msc->touches[id].scroll_x - x;
> int step_y = ms

Re: [RFC 0/2] ns: introduce binfmt_misc namespace

[Laurent Vivier]

Le 01/10/2018 à 09:21, Eric W. Biederman a écrit :
> Andy Lutomirski  writes:
> 
>> On Sun, Sep 30, 2018 at 4:47 PM Laurent Vivier  wrote:
>>>
>>> This series introduces a new namespace for binfmt_misc.
>>>
>>
>> This seems conceptually quite reasonable, but I'm wondering if the
>> number of namespace types is getting out of hand given the current
>> API.  Should we be considering whether we need a new set of namespace
>> creation APIs that scale better to larger numbers of namespace types?
> 
> I would rather encourage a way to make this part of an existing
> namespace or find a way to make a mount of binfmt_misc control this.
> 
> Hmm.  This looks like something that can be very straight forwardly be
> made part of the user namespace.  If you ever mount binfmt_misc in the
> user namespace you get the new behavior.  Otherwise you get the existing
> behavior.

Thank you. I'll do that.

> A user namespace will definitely be required, as otherwise you run the
> risk of confusing root (and suid root exectuables0 by being able to
> change the behavior of executables.
> 
> What is the motivation for this?  My impression is that very few people
> tweak binfmt_misc.

I think more and more people are using an interpreter like qemu
linux-usermode to have a cross-compilation environment: they bootstrap a
distro filesystems (with something like debootstrap), and then use
binfmt_misc to run the compiler inside this environment (see for
instance [1] [2] [3] or [4] [5]). This is interesting because you have
more than a cross-compiler with that: you have also all the libraries of
the target system, you can select exactly which target release you want
to build to, with the exact same compiler and libraries versions (and
you can re-use it you want to do maintenance on your project 10 years
later...)

The problem with this is you need to be root:
1- to chroot
2- to configure binfmt_misc

We already can use "unshare --map-root-user chroot" to address the point
1, and this series tries to address the point 2.

I think it's also interesting to have a per container configuration for
binfmt_misc when the server administrator configures it and don't want
to share each user configuration with all the other user ones (in
something like docker or a cloud application).

> I also don't think this raises to the level where it makes sense to
> create a new namespace for this.

OK.

Thanks,
Laurent

[1] https://wiki.debian.org/Arm64Qemu
[2] https://wiki.debian.org/M68k/sbuildQEMU
[3] https://wiki.debian.org/RISC-V#Manual_qemu-user_installation
[4] https://kbeckmann.github.io/2017/05/26/QEMU-instead-of-cross-compiling/
[5] https://wiki.gentoo.org/wiki/Crossdev_qemu-static-user-chroot

Re: [RFC 5/5] MIPS: Add Realtek RTL8186 SoC support

[Yasha Cherikovsky]

Hi Marc,

On Mon, 2018-10-01 at 09:19 +0100, Marc Zyngier wrote:
> Hi Yasha,
> 
> On 30/09/18 15:15, Yasha Cherikovsky wrote:
> > The Realtek RTL8186 SoC is a MIPS based SoC
> > used in some home routers [1][2].
> > 
> > The hardware includes Lexra LX5280 CPU with a TLB,
> > two Ethernet controllers, a WLAN controller and more.
> > 
> > With this patch, it is possible to successfully boot
> > the kernel and load userspace on the Edimax BR-6204Wg
> > router.
> > Network drivers support will come in future patches.
> > 
> > This patch includes:
> > - New MIPS rtl8186 platform
> >  - Core platform setup code (mostly DT based)
> >  - New Kconfig option
> >  - defconfig file
> >  - MIPS zboot UART support
> > - RTL8186 interrupt controller driver
> > - RTL8186 timer driver
> > - Device tree files for the RTL8186 SoC and Edimax BR-6204Wg
> >router
> > 
> > [1] https://www.linux-mips.org/wiki/Realtek_SOC#Realtek_RTL8186
> > [2] https://wikidevi.com/wiki/Realtek_RTL8186
> > 
> > Signed-off-by: Yasha Cherikovsky 
> > Cc: Ralf Baechle 
> > Cc: Paul Burton 
> > Cc: James Hogan 
> > Cc: Thomas Gleixner 
> > Cc: Jason Cooper 
> > Cc: Marc Zyngier 
> > Cc: Daniel Lezcano 
> > Cc: Rob Herring 
> > Cc: Mark Rutland 
> > Cc: linux-m...@linux-mips.org
> > Cc: devicet...@vger.kernel.org
> > Cc: linux-kernel@vger.kernel.org
> > ---
> >   arch/mips/Kbuild.platforms|   1 +
> >   arch/mips/Kconfig |  17 ++
> >   arch/mips/boot/compressed/uart-16550.c|   5 +
> >   arch/mips/boot/dts/Makefile   |   1 +
> >   arch/mips/boot/dts/realtek/Makefile   |   4 +
> >   arch/mips/boot/dts/realtek/rtl8186.dtsi   |  86 +++
> >   .../dts/realtek/rtl8186_edimax_br_6204wg.dts  |  45 
> >   arch/mips/configs/rtl8186_defconfig   | 112 +
> >   arch/mips/include/asm/mach-rtl8186/rtl8186.h  |  37 +++
> >   arch/mips/rtl8186/Makefile|   2 +
> >   arch/mips/rtl8186/Platform|   7 +
> >   arch/mips/rtl8186/irq.c   |   8 +
> >   arch/mips/rtl8186/prom.c  |  15 ++
> >   arch/mips/rtl8186/setup.c |  80 +++
> >   arch/mips/rtl8186/time.c  |  10 +
> >   drivers/clocksource/Kconfig   |   9 +
> >   drivers/clocksource/Makefile  |   1 +
> >   drivers/clocksource/timer-rtl8186.c   | 220
> > ++
> >   drivers/irqchip/Kconfig   |   5 +
> >   drivers/irqchip/Makefile  |   1 +
> >   drivers/irqchip/irq-rtl8186.c | 107 +
> 
> Could you please split this into at least three patches (arch code, 
> clocksource, irqchip) to ease the review?
> 
> Thanks,
> 
>   M.

Currently the RTL8186_IRQ and the RTL8186_TIMER Kconfig entries depend on
MACH_RTL8186 (which is added in the MIPS portion of the same patch).
Also, MACH_RTL8186 in MIPS selects these two options.

What is the best way to split that?

Thanks,
Yasha

Re: [PATCH] tty:serial:imx: use spin_lock instead of spin_lock_irqsave in isr

[Uwe Kleine-König]

Hello,

On Mon, Aug 27, 2018 at 07:49:04AM -0700, jun qian wrote:
> Before the program enters the uart ISR, the local interrupt has been
> disabled by the system, so it's not appropriate to use spin_lock_irqsave
> interface in the ISR.

"not appropriate" is a bit strong. It's not as optimal as it could be
though, yes.

The change is fine,

Acked-by: Uwe Kleine-König 

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

Re: [RFC 2/2] binfmt_misc: move data to binfmt_namespace

[Jann Horn]

On Mon, Oct 1, 2018 at 1:47 AM Laurent Vivier  wrote:
> @@ -716,7 +711,8 @@ static ssize_t bm_register_write(struct file *file, const 
> char __user *buffer,
> if (!inode)
> goto out2;
>
> -   err = simple_pin_fs(&bm_fs_type, &bm_mnt, &entry_count);
> +   err = simple_pin_fs(&bm_fs_type, &binfmt_ns(bm_mnt),
> +   &binfmt_ns(entry_count));
> if (err) {
> iput(inode);
> inode = NULL;
> @@ -730,7 +726,8 @@ static ssize_t bm_register_write(struct file *file, const 
> char __user *buffer,
> if (IS_ERR(f)) {
> err = PTR_ERR(f);
> pr_notice("register: failed to install interpreter 
> file %s\n", e->interpreter);
> -   simple_release_fs(&bm_mnt, &entry_count);
> +   simple_release_fs(&binfmt_ns(bm_mnt),
> + &binfmt_ns(entry_count));
> iput(inode);
> inode = NULL;
> goto out2;
> @@ -743,9 +740,9 @@ static ssize_t bm_register_write(struct file *file, const 
> char __user *buffer,
> inode->i_fop = &bm_entry_operations;
>
> d_instantiate(dentry, inode);
> -   write_lock(&entries_lock);
> -   list_add(&e->list, &entries);
> -   write_unlock(&entries_lock);
> +   write_lock(&binfmt_ns(entries_lock));
> +   list_add(&e->list, &binfmt_ns(entries));
> +   write_unlock(&binfmt_ns(entries_lock));

This looks wrong. A write handler's behavior should not depend on the
namespace of the process that is using it.

Ideally, the affected namespace should depend on the file you're writing to.
If that's not possible, the affected namespace should at least be the
namespace of the process that opened the file.

Re: [RFC 0/2] ns: introduce binfmt_misc namespace

[Eric W. Biederman]

Laurent Vivier  writes:

> Le 01/10/2018 à 09:21, Eric W. Biederman a écrit :
>> Andy Lutomirski  writes:
>> 
>>> On Sun, Sep 30, 2018 at 4:47 PM Laurent Vivier  wrote:

 This series introduces a new namespace for binfmt_misc.

>>>
>>> This seems conceptually quite reasonable, but I'm wondering if the
>>> number of namespace types is getting out of hand given the current
>>> API.  Should we be considering whether we need a new set of namespace
>>> creation APIs that scale better to larger numbers of namespace types?
>> 
>> I would rather encourage a way to make this part of an existing
>> namespace or find a way to make a mount of binfmt_misc control this.
>> 
>> Hmm.  This looks like something that can be very straight forwardly be
>> made part of the user namespace.  If you ever mount binfmt_misc in the
>> user namespace you get the new behavior.  Otherwise you get the existing
>> behavior.
>
> Thank you. I'll do that.
>
>> A user namespace will definitely be required, as otherwise you run the
>> risk of confusing root (and suid root exectuables0 by being able to
>> change the behavior of executables.
>> 
>> What is the motivation for this?  My impression is that very few people
>> tweak binfmt_misc.
>
> I think more and more people are using an interpreter like qemu
> linux-usermode to have a cross-compilation environment: they bootstrap a
> distro filesystems (with something like debootstrap), and then use
> binfmt_misc to run the compiler inside this environment (see for
> instance [1] [2] [3] or [4] [5]). This is interesting because you have
> more than a cross-compiler with that: you have also all the libraries of
> the target system, you can select exactly which target release you want
> to build to, with the exact same compiler and libraries versions (and
> you can re-use it you want to do maintenance on your project 10 years
> later...)
>
> The problem with this is you need to be root:
> 1- to chroot
> 2- to configure binfmt_misc
>
> We already can use "unshare --map-root-user chroot" to address the point
> 1, and this series tries to address the point 2.
>
> I think it's also interesting to have a per container configuration for
> binfmt_misc when the server administrator configures it and don't want
> to share each user configuration with all the other user ones (in
> something like docker or a cloud application).

OK.  So it sounds like you are already needing a user namespace for
this.   If this is your use case then my proposed method above seems to
fit rather well.  James Bottomley was doing something similar that
connected to personality(2).  That might be worth a look to see if there
is some synergy there.

>> I also don't think this raises to the level where it makes sense to
>> create a new namespace for this.
>
> OK.
>
> Thanks,
> Laurent
>
> [1] https://wiki.debian.org/Arm64Qemu
> [2] https://wiki.debian.org/M68k/sbuildQEMU
> [3] https://wiki.debian.org/RISC-V#Manual_qemu-user_installation
> [4] https://kbeckmann.github.io/2017/05/26/QEMU-instead-of-cross-compiling/
> [5] https://wiki.gentoo.org/wiki/Crossdev_qemu-static-user-chroot

Re: [PATCH] staging: rtlwifi: Removed unused define and code efuse_re_pg* from wifi.h

[Pkshih]

On Mon, 2018-10-01 at 07:15 +0300, Kalle Valo wrote:
> Joe Perches  writes:
> 
> > On Sun, 2018-09-30 at 20:29 +0200, Rick Veens wrote:
> >> The following:
> >>  bool efuse_re_pg_sec1flag;
> >>  u8 efuse_re_pg_data[8];
> >> are not referenced anywhere in the rtlwifi code.
> >> 
> >> Signed-off-by: Rick Veens 
> >> ---
> >>  drivers/staging/rtlwifi/wifi.h | 4 
> >
> > Presumably the equivalent uses in
> > drivers/net/wireless/realtek/rtlwifi/wifi.h
> > should be removed as well.
> 
> But if it's needed, just do it in separate patch as the patches go via
> different trees.
> 

I can send this patch.

--
PK

Re: [PATCH 5/7] MIPS: mscc: ocelot: add GPIO4 pinmuxing DT node

[Quentin Schulz]

Hi Andrew,

On Fri, Sep 14, 2018 at 07:02:21PM +0200, Andrew Lunn wrote:
> On Fri, Sep 14, 2018 at 06:26:38PM +0200, Quentin Schulz wrote:
> > Hi Alexandre,
> > 
> > On Fri, Sep 14, 2018 at 04:54:46PM +0200, Alexandre Belloni wrote:
> > > Hi,
> > > 
> > > On 14/09/2018 11:44:26+0200, Quentin Schulz wrote:
> > > > In order to use GPIO4 as a GPIO, we need to mux it in this mode so let's
> > > > declare a new pinctrl DT node for it.
> > > > 
> > > > Signed-off-by: Quentin Schulz 
> > > > ---
> > > >  arch/mips/boot/dts/mscc/ocelot.dtsi | 5 +
> > > >  1 file changed, 5 insertions(+)
> > > > 
> > > > diff --git a/arch/mips/boot/dts/mscc/ocelot.dtsi 
> > > > b/arch/mips/boot/dts/mscc/ocelot.dtsi
> > > > index 8ce317c..b5c4c74 100644
> > > > --- a/arch/mips/boot/dts/mscc/ocelot.dtsi
> > > > +++ b/arch/mips/boot/dts/mscc/ocelot.dtsi
> > > > @@ -182,6 +182,11 @@
> > > > interrupts = <13>;
> > > > #interrupt-cells = <2>;
> > > >  
> > > > +   gpio4: gpio4 {
> > > > +   pins = "GPIO_4";
> > > > +   function = "gpio";
> > > > +   };
> > > > +
> > > 
> > > For a GPIO, I would do that in the board dts because it is not used
> > > directly in the dtsi.
> > > 
> > 
> > And the day we've two boards using this pinctrl we move it to a dtsi. Is
> > that the plan?
> 
> Hi Quentin
> 
> gpio4 appears to be pretty arbitrary. Could a different design use a
> different gpio? It me, this seems like a board property.
> 

Right now, I don't see why it couldn't be.

Quentin


signature.asc
Description: PGP signature

RE: [PATCH v3 1/5] spi: spi-mem: Add driver for NXP FlexSPI controller

[Yogesh Narayan Gaur]

Hi Boris,

> -Original Message-
> From: Frieder Schrempf [mailto:frieder.schre...@exceet.de]
> Sent: Monday, October 1, 2018 11:48 AM
> To: Boris Brezillon ; Yogesh Narayan Gaur
> 
> Cc: linux-...@lists.infradead.org; marek.va...@gmail.com; linux-
> s...@vger.kernel.org; devicet...@vger.kernel.org; r...@kernel.org;
> mark.rutl...@arm.com; shawn...@kernel.org; linux-arm-
> ker...@lists.infradead.org; computersforpe...@gmail.com; linux-
> ker...@vger.kernel.org
> Subject: Re: [PATCH v3 1/5] spi: spi-mem: Add driver for NXP FlexSPI 
> controller
> 
> Hi Boris,
> 
> On 29.09.2018 17:40, Boris Brezillon wrote:
> > Hi Yogesh,
> >
> > On Fri, 21 Sep 2018 15:51:59 +0530
> > Yogesh Gaur  wrote:
> >
> >> +/* Registers used by the driver */
> >> +#define FSPI_MCR0 0x00
> >> +#define FSPI_MCR0_AHB_TIMEOUT_SHIFT   24
> >> +#define FSPI_MCR0_AHB_TIMEOUT_MASK(0xFF <<
> FSPI_MCR0_AHB_TIMEOUT_SHIFT)
> >> +#define FSPI_MCR0_IP_TIMEOUT_SHIFT16
> >> +#define FSPI_MCR0_IP_TIMEOUT_MASK (0xFF <<
> FSPI_MCR0_IP_TIMEOUT_SHIFT)
> >> +#define FSPI_MCR0_LEARN_EN_SHIFT  15
> >> +#define FSPI_MCR0_LEARN_EN_MASK   (1 <<
> FSPI_MCR0_LEARN_EN_SHIFT)
> >> +#define FSPI_MCR0_SCRFRUN_EN_SHIFT14
> >> +#define FSPI_MCR0_SCRFRUN_EN_MASK (1 <<
> FSPI_MCR0_SCRFRUN_EN_SHIFT)
> >> +#define FSPI_MCR0_OCTCOMB_EN_SHIFT13
> >> +#define FSPI_MCR0_OCTCOMB_EN_MASK (1 <<
> FSPI_MCR0_OCTCOMB_EN_SHIFT)
> >> +#define FSPI_MCR0_DOZE_EN_SHIFT   12
> >> +#define FSPI_MCR0_DOZE_EN_MASK(1 <<
> FSPI_MCR0_DOZE_EN_SHIFT)
> >> +#define FSPI_MCR0_HSEN_SHIFT  11
> >> +#define FSPI_MCR0_HSEN_MASK   (1 << FSPI_MCR0_HSEN_SHIFT)
> >> +#define FSPI_MCR0_SERCLKDIV_SHIFT 8
> >> +#define FSPI_MCR0_SERCLKDIV_MASK  (7 <<
> FSPI_MCR0_SERCLKDIV_SHIFT)
> >> +#define FSPI_MCR0_ATDF_EN_SHIFT   7
> >> +#define FSPI_MCR0_ATDF_EN_MASK(1 <<
> FSPI_MCR0_ATDF_EN_SHIFT)
> >> +#define FSPI_MCR0_ARDF_EN_SHIFT   6
> >> +#define FSPI_MCR0_ARDF_EN_MASK(1 <<
> FSPI_MCR0_ARDF_EN_SHIFT)
> >> +#define FSPI_MCR0_RXCLKSRC_SHIFT  4
> >> +#define FSPI_MCR0_RXCLKSRC_MASK   (3 <<
> FSPI_MCR0_RXCLKSRC_SHIFT)
> >> +#define FSPI_MCR0_END_CFG_SHIFT   2
> >> +#define FSPI_MCR0_END_CFG_MASK(3 <<
> FSPI_MCR0_END_CFG_SHIFT)
> >> +#define FSPI_MCR0_MDIS_SHIFT  1
> >> +#define FSPI_MCR0_MDIS_MASK   (1 << FSPI_MCR0_MDIS_SHIFT)
> >> +#define FSPI_MCR0_SWRST_SHIFT 0
> >> +#define FSPI_MCR0_SWRST_MASK  (1 <<
> FSPI_MCR0_SWRST_SHIFT)
> >
> > Do we really need all those _SHIFT/_MASK defs? I mean
> >
> > #define FSPI_MCR0_SWRST BIT(0)
> >
> > or
> >
> > #define FSPI_MCR0_AHB_TIMEOUT(x)((x) << 24)
> > #define FSPI_MCR0_AHB_TIMEOUT_MASK  GENMASK(31, 24)
> >
> > are just fine.
> >
> >> +
> >> +enum nxp_fspi_devtype {
> >> +  NXP_FSPI_LX2160A,
> >> +};
> >
> > I'm pretty sure you don't need this enum if you describe all dev caps
> > in the nxp_fspi_devtype_data struct.
> >
> >> +
> >> +struct nxp_fspi_devtype_data {
> >> +  enum nxp_fspi_devtype devtype;
> >> +  unsigned int rxfifo;
> >> +  unsigned int txfifo;
> >> +  unsigned int ahb_buf_size;
> >> +  unsigned int quirks;
> >> +  bool endianness;
> >
> > How about renaming this variable big_endian and dropping the
> > {L,B}_ENDIAN macros?
> >
> >> +};
> >
> > [...]
> >
> >> +struct nxp_fspi {
> >> +  void __iomem *iobase;
> >> +  void __iomem *ahb_addr;
> >> +  u32 memmap_phy;
> >> +  u32 memmap_phy_size;
> >> +  struct clk *clk, *clk_en;
> >> +  struct device *dev;
> >> +  struct completion c;
> >> +  const struct nxp_fspi_devtype_data *devtype_data;
> >> +  struct mutex lock;
> >> +  struct pm_qos_request pm_qos_req;
> >> +  int selected;
> >> +  void (*write)(u32 val, void __iomem *addr);
> >> +  u32 (*read)(void __iomem *addr);
> >> +};
> >> +
> >> +static void fspi_writel_be(u32 val, void __iomem *addr) {
> >> +  iowrite32be(val, addr);
> >> +}
> >> +
> >> +static void fspi_writel(u32 val, void __iomem *addr) {
> >> +  iowrite32(val, addr);
> >> +}
> >> +
> >> +static u32 fspi_readl_be(void __iomem *addr) {
> >> +  return ioread32be(addr);
> >> +}
> >> +
> >> +static u32 fspi_readl(void __iomem *addr) {
> >> +  return ioread32(addr);
> >> +}
> >
> > Hm, I'd recommend dropping the ->read/write() hooks and providing the
> > following functions:
> >
> > static void fspi_writel(struct nxp_fspi *f, u32 val, void __iomem
> > *addr) {
> > if (f->big_endian)
> > iowrite32be(val, addr);
> > else
> > iowrite32(val, addr);
> > }
> >
> >
> > static u32 fspi_readl(struct nxp_fspi *f, void __iomem *addr) {
> > if (f->big_endian)
> > return ioread32be(addr);
> > else
> > return ioread32(addr);
> > }
> 
> I introduced the ->read/write() hooks in the QSPI driver because I was told to
> remove the conditional in the read/write path, but I can't really tell if 
> this really
> makes any

Re: [PATCH] clk: ti: fix OF child-node lookup

[Tero Kristo]

On 28/09/18 18:57, Stephen Boyd wrote:

Quoting Tero Kristo (2018-09-20 00:11:08)

On 31/08/18 00:46, Stephen Boyd wrote:

Quoting Johan Hovold (2018-08-22 02:03:19)

Fix child-node lookup which by using the wrong OF helper was searching
the whole tree depth-first, something which could end up matching an
unrelated node.

Also fix the related node-reference leaks.

Fixes: 5b385a45e001 ("clk: ti: add support for clkctrl aliases")
Signed-off-by: Johan Hovold 
---


Applied to clk-next



Stephen, this patch causes a merge conflict with some of the code I am
planning to send a pull-req against (the clkctrl work series:
https://patchwork.kernel.org/project/linux-clk/list/?series=13841)

Would it be possible to drop this from clk-next, and for me to
pick-it-up via my own branch? I can get this setup either today or tomorrow.

Alternatively I need an immutable branch against which I can work.



clk-ti-of-node is immutable. You can base on top of that and send a PR.
Does that work for you?


That should work just fine for me.

I'll work on top of this and send a pull-req, thanks.

-Tero


--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

U.S Ambassador / Tag NO.:XXXX.

[William S. Symington]

>From United States Ambassador To Nigeria
Plot 1075 Diplomatic Drive Central
District Area, Abuja Nigeria


Dear Fund Receiver,


We want to let you know that the sum of $15.8million being a 
contract/inheritans/compensation and winning fund payment.

I have make an arrangement of coming to your country with your consignment 
winning box as a united state agent i have the power to pass customs and 
security agencies without any blockage if the consignment is completely 
registered.

You are to confirm the tracking of some person  that receive their  consignment 
box through DHL delivery company

https://www.dhl.com
Tracking no: 41609916xx


You are instructed to provide the below particulars:

Names:
Address:
Telephone:
Nearest Airport:


My trip will be upon the receipt of your above particulars so that delivery can 
commence with your consignment Tag NO.:.

My Biography :https://www.state.gov/r/pa/ei/biog/227407.htm

God bless America

William S. Symington
U.S Ambassador

Re: [PATCH] nvmem: Convert to using %pOFn instead of device_node.name

[Srinivas Kandagatla]

On 28/09/18 23:06, Rob Herring wrote:

On Mon, Aug 27, 2018 at 8:55 PM Rob Herring  wrote:


In preparation to remove the node name pointer from struct device_node,
convert printf users to use the %pOFn format specifier.

Cc: Srinivas Kandagatla 
Signed-off-by: Rob Herring 
---
  drivers/nvmem/core.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)


Ping. This has no dependencies, so please apply.


Sorry, Looks like I missed this one!
I already re-based it. I will send it with other fixes to Greg KH soon!

thanks,
--srini


Rob



diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
index aa1657831b70..6988ee9f11ba 100644
--- a/drivers/nvmem/core.c
+++ b/drivers/nvmem/core.c
@@ -304,6 +304,7 @@ static void nvmem_cell_drop(struct nvmem_cell *cell)
 mutex_lock(&nvmem_cells_mutex);
 list_del(&cell->node);
 mutex_unlock(&nvmem_cells_mutex);
+   kfree(cell->name);
 kfree(cell);
  }

@@ -879,7 +880,7 @@ struct nvmem_cell *of_nvmem_cell_get(struct device_node *np,
 cell->nvmem = nvmem;
 cell->offset = be32_to_cpup(addr++);
 cell->bytes = be32_to_cpup(addr);
-   cell->name = cell_np->name;
+   cell->name = kasprintf(GFP_KERNEL, "%pOFn", cell_np);

 addr = of_get_property(cell_np, "bits", &len);
 if (addr && len == (2 * sizeof(u32))) {
@@ -904,6 +905,7 @@ struct nvmem_cell *of_nvmem_cell_get(struct device_node *np,
 return cell;

  err_sanity:
+   kfree(cell->name);
 kfree(cell);

  err_mem:
--
2.17.1

Re: [RFC 00/20] ns: Introduce Time Namespace

[Eric W. Biederman]

Thomas Gleixner  writes:

> Eric,
>
> On Fri, 28 Sep 2018, Eric W. Biederman wrote:
>> Thomas Gleixner  writes:
>> > On Wed, 26 Sep 2018, Eric W. Biederman wrote:
>> >> At the same time using the techniques from the nohz work and a little
>> >> smarts I expect we could get the code to scale.
>> >
>> > You'd need to invoke the update when the namespace is switched in and
>> > hasn't been updated since the last tick happened. That might be doable, but
>> > you also need to take the wraparound constraints of the underlying
>> > clocksources into account, which again can cause walking all name spaces
>> > when they are all idle long enough.
>> 
>> The wrap around constraints being how long before the time sources wrap
>> around so you have to read them once per wrap around?  I have not dug
>> deeply enough into the code to see that yet.
>
> It's done by limiting the NOHZ idle time when all CPUs are going into deep
> sleep for a long time, i.e. we make sure that at least one CPU comes back
> sufficiently _before_ the wraparound happens and invokes the update
> function.
>
> It's not so much a problem for TSC, but not every clocksource the kernel
> supports has wraparound times in the range of hundreds of years.
>
> But yes, your idea of keeping track of wraparounds might work. Tricky, but
> looks feasible on first sight, but we should be aware of the dragons.

Oh.  Yes.  Definitely.  A key enabler of any namespace implementation is
figuring out how to tame the dragons.

>> Please pardon me for thinking out load.
>> 
>> There are one or more time sources that we use to compute the time
>> and for each time source we have a conversion from ticks of the
>> time source to nanoseconds.
>> 
>> Each time source needs to be sampled at least once per wrap-around
>> and something incremented so that we don't loose time when looking
>> at that time source.
>> 
>> There are several clocks presented to userspace and they all share the
>> same length of second and are all fundamentally offsets from
>> CLOCK_MONOTONIC.
>
> Yes. That's the readout side. This one is doable. But now look at timers.
>
> If you arm the timer from a name space, then it needs to be converted to
> host time in order to sort it into the hrtimer queue and at some point arm
> the clockevent device for it. This works as long as host and name space
> time have a constant offset and the same skew.
>
> Once the name space time has a different skew this falls apart because the
> armed timer will either expire late or early.
>
> Late might be acceptable, early violates the spec. You could do an extra
> check for rescheduling it, if it's early, but that requires to store the
> name space time accessor in the hrtimer itself because not every timer
> expiry happens so that it can be checked in the name space context (think
> signal based timers). We need to add this extra magic right into
> __hrtimer_run_queues() which is called from the hard and soft interrupt. We
> really don't want to touch all relevant callbacks or syscalls. The latter
> is not sufficient anyway for signal based timer delivery.
>
> That's going to be interesting in terms of synchronization and might also
> cause substantial overhead at least for the timers which belong to name
> spaces.
>
> But that also means that anything which is early can and probably will
> cause rearming of the timer hardware possibly for a very short delta. We
> need to think about whether this can be abused to create interrupt storms.
>
> Now if you accept a bit late, which I'm not really happy about, then you
> surely won't accept very late, i.e. hours, days. But that can happen when
> settimeofday() comes into play. Right now with a single time domain, this
> is easy. When settimeofday() or adjtimex() makes time jump, we just go and
> reprogramm the hardware timers accordingly, which might also result in
> immediate expiry of timers.
>
> But this does not help for time jumps in name spaces because the timer is
> enqueued on the host time base.
>
> And no, we should not think about creating per name space hrtimer queues
> and then have to walk through all of them for finding the first expiring
> timer in order to arm the hardware. That cannot scale.
>
> Walking all hrtimer bases on all CPUs and check all queued timers whether
> they belong to the affected name space does not scale either.
>
> So we'd need to keep track of queued timers belonging to a name space and
> then just handle them. Interesting locking problem and also a scalability
> issue because this might need to be done on all online CPUs. Haven't
> thought it through, but it makes me shudder.

Yes.  I can see how this is a dragon that we need to figure out how to
tame.  It already exist somewhat for CLOCK_MONOTONIC vs CLOCK_REALTIME
but still.

>> I see two fundamental driving cases for a time namespace.
>
> 
>
> I completely understand the problem you are trying to solve and yes, the
> read out of time should be a solvable problem.

There is simplified

Re: [PATCH v3 1/5] spi: spi-mem: Add driver for NXP FlexSPI controller

[Boris Brezillon]

On Mon, 1 Oct 2018 09:02:32 +
Yogesh Narayan Gaur  wrote:

> > > static void fspi_writel(struct nxp_fspi *f, u32 val, void __iomem
> > > *addr) {
> > >   if (f->big_endian)
> > >   iowrite32be(val, addr);
> > >   else
> > >   iowrite32(val, addr);
> > > }
> > >
> > >
> > > static u32 fspi_readl(struct nxp_fspi *f, void __iomem *addr) {
> > >   if (f->big_endian)
> > >   return ioread32be(addr);
> > >   else
> > >   return ioread32(addr);
> > > }  
> > 
> > I introduced the ->read/write() hooks in the QSPI driver because I
> > was told to remove the conditional in the read/write path, but I
> > can't really tell if this really makes any difference.
> >   
> Yes, I have taken these hooks by looking into the comments received
> for Frieder's QSPI patch series. For me this looks more clean and can
> be decided in the controller initialization sequence which hook would
> going to be invoked.


Well, depending on your CPU, the indirect branch (caused by the
function pointer call) might have an higher cost than the conditional
branch. Not sure we care about such micro-optimizations though.
Regarding the readability aspect, I still prefer my version, but I
guess that's a matter of taste.

Re: [PATCH] firmware: Convert to using %pOFn instead of device_node.name

[Sudeep Holla]

On Fri, Sep 28, 2018 at 04:47:41PM -0500, Rob Herring wrote:
> On Mon, Aug 27, 2018 at 8:53 PM Rob Herring  wrote:
> >
> > In preparation to remove the node name pointer from struct device_node,
> > convert printf users to use the %pOFn format specifier.
> >
> > Signed-off-by: Rob Herring 
> > ---
> >  drivers/firmware/scpi_pm_domain.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
>
> Sudeep, looks like I missed Cc'ing you (or anyone) on this. Can you
> please ack or apply this.
>
I prefer you to take it via your tree as that may be easier.

Acked-by: Sudeep Holla 

--
Regards,
Sudeep

Re: [RFC 61/60] cosched: Accumulated fixes and improvements

[Jan H. Schönherr]

On 09/26/2018 11:05 PM, Nishanth Aravamudan wrote:
> On 26.09.2018 [10:25:19 -0700], Nishanth Aravamudan wrote:
>>
>> I found another issue today, while attempting to test (with 61/60
>> applied) separate coscheduling cgroups for vcpus and emulator threads
>> [the default configuration with libvirt].
> 
> 
> 
> [  764.132461] BUG: unable to handle kernel NULL pointer dereference at 
> 0040
> [  764.141001] PGD 0 P4D 0 
> [  764.144020] Oops:  [#1] SMP PTI
> [  764.147988] CPU: 70 PID: 0 Comm: swapper/70 Tainted: G   OE 
> 4.19-0rc3.ag-generic #4+1536951040do~8680a1b
> [  764.159086] Hardware name: Dell Inc. PowerEdge R640/0W23H8, BIOS 1.2.11 
> 10/19/2017
> [  764.166968] RIP: 0010:set_next_entity+0x15/0x1d0

I got it reproduced.

I will send a fix, when I have one.

Regards
Jan

Re: [PATCH V9 3/8] clocksource: add C-SKY SMP timer

[Daniel Lezcano]

On 01/10/2018 03:35, Guo Ren wrote:
> This timer is used by SMP system and use mfcr/mtcr instruction
> to access the regs.
> 
> Changelog:
>  - Remove #define CPUHP_AP_CSKY_TIMER_STARTING
>  - Add CPUHP_AP_CSKY_TIMER_STARTING in cpuhotplug.h
>  - Support csky mp timer alpha version.
>  - Just use low-counter with 32bit width as clocksource.
>  - Coding convention with upstream feed-back.
> 
> Signed-off-by: Guo Ren 
> ---
>  drivers/clocksource/Kconfig|   8 ++
>  drivers/clocksource/Makefile   |   1 +
>  drivers/clocksource/csky_mptimer.c | 176 
> +
>  include/linux/cpuhotplug.h |   1 +
>  4 files changed, 186 insertions(+)
>  create mode 100644 drivers/clocksource/csky_mptimer.c
> 
> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
> index a11f4ba..a28043f 100644
> --- a/drivers/clocksource/Kconfig
> +++ b/drivers/clocksource/Kconfig
> @@ -620,4 +620,12 @@ config RISCV_TIMER
> is accessed via both the SBI and the rdcycle instruction.  This is
> required for all RISC-V systems.
>  
> +config CSKY_MPTIMER
> + bool "C-SKY Multi Processor Timer"
> + depends on CSKY
> + select TIMER_OF
> + help
> +   Say yes here to enable C-SKY SMP timer driver used for C-SKY SMP
> +   system.
> +
>  endmenu

The same rule applies here for COMPILE_TEST.

And please rename the file: timer-mp-csky.c

> diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
> index db51b24..848c676 100644
> --- a/drivers/clocksource/Makefile
> +++ b/drivers/clocksource/Makefile
> @@ -79,3 +79,4 @@ obj-$(CONFIG_CLKSRC_ST_LPC) += clksrc_st_lpc.o
>  obj-$(CONFIG_X86_NUMACHIP)   += numachip.o
>  obj-$(CONFIG_ATCPIT100_TIMER)+= timer-atcpit100.o
>  obj-$(CONFIG_RISCV_TIMER)+= riscv_timer.o
> +obj-$(CONFIG_CSKY_MPTIMER)   += csky_mptimer.o
> diff --git a/drivers/clocksource/csky_mptimer.c 
> b/drivers/clocksource/csky_mptimer.c
> new file mode 100644
> index 000..9dc3cfb
> --- /dev/null
> +++ b/drivers/clocksource/csky_mptimer.c
> @@ -0,0 +1,176 @@
> +// SPDX-License-Identifier: GPL-2.0
> +// Copyright (C) 2018 Hangzhou C-SKY Microsystems co.,ltd.
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "timer-of.h"
> +
> +#define PTIM_CCVR"cr<3, 14>"
> +#define PTIM_CTLR"cr<0, 14>"
> +#define PTIM_LVR "cr<6, 14>"
> +#define PTIM_TSR "cr<1, 14>"
> +
> +static int csky_mptimer_set_next_event(unsigned long delta, struct 
> clock_event_device *ce)
> +{
> + mtcr(PTIM_LVR, delta);
> +
> + return 0;
> +}
> +
> +static int csky_mptimer_shutdown(struct clock_event_device *ce)
> +{
> + mtcr(PTIM_CTLR, 0);
> +
> + return 0;
> +}
> +
> +static int csky_mptimer_oneshot(struct clock_event_device *ce)
> +{
> + mtcr(PTIM_CTLR, 1);
> +
> + return 0;
> +}
> +
> +static int csky_mptimer_oneshot_stopped(struct clock_event_device *ce)
> +{
> + mtcr(PTIM_CTLR, 0);
> +
> + return 0;
> +}
> +
> +static DEFINE_PER_CPU(struct timer_of, csky_to) = {
> + .flags  = TIMER_OF_CLOCK,
> + .clkevt = {
> + .rating = 300,
> + .features   = CLOCK_EVT_FEAT_PERCPU |
> +   CLOCK_EVT_FEAT_ONESHOT,
> + .set_state_shutdown = csky_mptimer_shutdown,
> + .set_state_oneshot  = csky_mptimer_oneshot,
> + .set_state_oneshot_stopped  = csky_mptimer_oneshot_stopped,
> + .set_next_event = csky_mptimer_set_next_event,
> + },
> + .of_irq = {
> + .flags  = IRQF_TIMER,
> + .percpu = 1,
> + },

See comment in the init function.

> +};
> +
> +static irqreturn_t timer_interrupt(int irq, void *dev)
> +{
> + struct timer_of *to = this_cpu_ptr(&csky_to);
> +
> + mtcr(PTIM_TSR, 0);
> +
> + to->clkevt.event_handler(&to->clkevt);
> +
> + return IRQ_HANDLED;
> +}
> +
> +/*
> + * clock event for percpu
> + */
> +static int csky_mptimer_starting_cpu(unsigned int cpu)
> +{
> + struct timer_of *to = per_cpu_ptr(&csky_to, cpu);
> +
> + to->clkevt.cpumask = cpumask_of(cpu);
> +
> + clockevents_config_and_register(&to->clkevt, timer_of_rate(to), 2, 
> ULONG_MAX);
> +
> + enable_percpu_irq(timer_of_irq(to), 0);
> +
> + return 0;
> +}
> +
> +static int csky_mptimer_dying_cpu(unsigned int cpu)
> +{
> + struct timer_of *to = per_cpu_ptr(&csky_to, cpu);
> +
> + disable_percpu_irq(timer_of_irq(to));
> +
> + return 0;
> +}
> +
> +/*
> + * clock source
> + */
> +static u64 sched_clock_read(void)
> +{
> + return (u64) mfcr(PTIM_CCVR);

extra space

> +}
> +
> +static u64 clksrc_read(struct clocksource *c)
> +{
> + return (u64) mfcr(PTIM_CCVR);

extra space

> +}
> +
> +struct clocksource csky

Re: [RFC 5/5] MIPS: Add Realtek RTL8186 SoC support

[Marc Zyngier]

On 01/10/18 09:48, Yasha Cherikovsky wrote:

Hi Marc,

On Mon, 2018-10-01 at 09:19 +0100, Marc Zyngier wrote:

Hi Yasha,

On 30/09/18 15:15, Yasha Cherikovsky wrote:

The Realtek RTL8186 SoC is a MIPS based SoC
used in some home routers [1][2].

The hardware includes Lexra LX5280 CPU with a TLB,
two Ethernet controllers, a WLAN controller and more.

With this patch, it is possible to successfully boot
the kernel and load userspace on the Edimax BR-6204Wg
router.
Network drivers support will come in future patches.

This patch includes:
- New MIPS rtl8186 platform
  - Core platform setup code (mostly DT based)
  - New Kconfig option
  - defconfig file
  - MIPS zboot UART support
- RTL8186 interrupt controller driver
- RTL8186 timer driver
- Device tree files for the RTL8186 SoC and Edimax BR-6204Wg
router

[1] https://www.linux-mips.org/wiki/Realtek_SOC#Realtek_RTL8186
[2] https://wikidevi.com/wiki/Realtek_RTL8186

Signed-off-by: Yasha Cherikovsky 
Cc: Ralf Baechle 
Cc: Paul Burton 
Cc: James Hogan 
Cc: Thomas Gleixner 
Cc: Jason Cooper 
Cc: Marc Zyngier 
Cc: Daniel Lezcano 
Cc: Rob Herring 
Cc: Mark Rutland 
Cc: linux-m...@linux-mips.org
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
   arch/mips/Kbuild.platforms|   1 +
   arch/mips/Kconfig |  17 ++
   arch/mips/boot/compressed/uart-16550.c|   5 +
   arch/mips/boot/dts/Makefile   |   1 +
   arch/mips/boot/dts/realtek/Makefile   |   4 +
   arch/mips/boot/dts/realtek/rtl8186.dtsi   |  86 +++
   .../dts/realtek/rtl8186_edimax_br_6204wg.dts  |  45 
   arch/mips/configs/rtl8186_defconfig   | 112 +
   arch/mips/include/asm/mach-rtl8186/rtl8186.h  |  37 +++
   arch/mips/rtl8186/Makefile|   2 +
   arch/mips/rtl8186/Platform|   7 +
   arch/mips/rtl8186/irq.c   |   8 +
   arch/mips/rtl8186/prom.c  |  15 ++
   arch/mips/rtl8186/setup.c |  80 +++
   arch/mips/rtl8186/time.c  |  10 +
   drivers/clocksource/Kconfig   |   9 +
   drivers/clocksource/Makefile  |   1 +
   drivers/clocksource/timer-rtl8186.c   | 220
++
   drivers/irqchip/Kconfig   |   5 +
   drivers/irqchip/Makefile  |   1 +
   drivers/irqchip/irq-rtl8186.c | 107 +


Could you please split this into at least three patches (arch code,
clocksource, irqchip) to ease the review?

Thanks,

M.


Currently the RTL8186_IRQ and the RTL8186_TIMER Kconfig entries depend on
MACH_RTL8186 (which is added in the MIPS portion of the same patch).
Also, MACH_RTL8186 in MIPS selects these two options.

What is the best way to split that?


It is absolutely fine to have something depending on a non-selectable 
config option, which would allow you to split things up as finely as you 
want. Just have the patch enabling the config option last.


Thanks,

M.
--
Jazz is not dead. It just smells funny...

Setting monotonic time?

[Eric W. Biederman]

In the context of process migration there is a simpler subproblem that I
think it is worth exploring if we can do something about.

For a cluster of machines all running with synchronized
clocks. CLOCK_REALTIME matches. CLOCK_MONOTNIC does not match between
machines.   Not having a matching CLOCK_MONOTONIC prevents successful
process migration between nodes in that cluster.

Would it be possible to allow setting CLOCK_MONOTONIC at the very
beginning of time?  So that all of the nodes in a cluster can be in
sync?

No change in skew just in offset for CLOCK_MONOTONIC.

There are also dragons involved in coordinating things so that
CLOCK_MONOTONIC gets set before CLOCK_MONOTONIC gets used.  So I don't
know if allowing CLOCK_MONOTONIC to be set would be practical but it
seems work exploring all on it's own.

Dmitry would setting CLOCK_MONOTONIC exactly once at boot time solve
your problem that is you are looking at a time namespace to solve?

Eric

Re: [PATCH net-next 2/7] net: phy: mscc: add support for VSC8584 PHY

[Quentin Schulz]

Hi Andrew,

On Fri, Sep 14, 2018 at 07:27:54PM +0200, Andrew Lunn wrote:
> 
> >  struct vsc8531_private {
> > int rate_magic;
> > u16 supp_led_modes;
> > @@ -181,6 +354,7 @@ struct vsc8531_private {
> > struct vsc85xx_hw_stat *hw_stats;
> > u64 *stats;
> > int nstats;
> > +   bool pkg_init;
> 
> > +/* bus->mdio_lock should be locked when using this function */
> > +static int vsc8584_cmd(struct mii_bus *bus, int phy, u16 val)
> > +{
> > +   unsigned long deadline;
> > +   u16 reg_val;
> > +
> > +   __mdiobus_write(bus, phy, MSCC_EXT_PAGE_ACCESS,
> > +   MSCC_PHY_PAGE_EXTENDED_GPIO);
> > +
> > +   __mdiobus_write(bus, phy, MSCC_PHY_PROC_CMD, PROC_CMD_NCOMPLETED | val);
> 
> Hi Quentin
> 
> All the __mdiobus_write() look a bit ugly.

I agree :)

> Maybe add bus and base_addr
> to the vsc8531_private structure. Then add helpers
> phy_write_base_phy(priv, reg, val) and phy_read_base_phy(priv, reg).
> 

ACK.

> You could also add in:
> 
> if (unlikely(!mutex_is_locked(&priv->bus->mdio_lock))) {
> dev_err(bus->dev, "MDIO bus lock not held!\n");
> dump_stack();
> }
> 
> Having such code in the mv88e6xxx driver has found a few bugs for me.
> 

ACK.

Thanks,
Quentin


signature.asc
Description: PGP signature

Re: [PATCH] perf: Convert to using %pOFn instead of device_node.name

[Will Deacon]

On Fri, Sep 28, 2018 at 04:19:07PM -0500, Rob Herring wrote:
> On Tue, Aug 28, 2018 at 12:02 PM Will Deacon  wrote:
> >
> > On Mon, Aug 27, 2018 at 08:52:39PM -0500, Rob Herring wrote:
> > > In preparation to remove the node name pointer from struct device_node,
> > > convert printf users to use the %pOFn format specifier.
> > >
> > > Cc: Will Deacon 
> > > Cc: Mark Rutland 
> > > Cc: linux-arm-ker...@lists.infradead.org
> > > Signed-off-by: Rob Herring 
> > > ---
> > >  drivers/perf/arm_pmu_platform.c | 6 +++---
> > >  1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > Cheers, I can queue this up for 4.20. Let me know if you'd rather take it
> > along with the name pointer removal instead.
> 
> I assumed you were going to take this since I didn't say otherwise,
> but looks like it is not in linux-next. Please take thru your tree.

Sorry, slipped through the cracks. I'll get it queued asap for the merge
window.

Will

Re: [PATCH v4] fuse: add support for copy_file_range()

[Miklos Szeredi]

On Tue, Aug 21, 2018 at 2:36 PM, Niels de Vos  wrote:
> There are several FUSE filesystems that can implement server-side copy
> or other efficient copy/duplication/clone methods. The copy_file_range()
> syscall is the standard interface that users have access to while not
> depending on external libraries that bypass FUSE.
>
> Signed-off-by: Niels de Vos 

Applied and pushed to

  git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse.git#for-next

Thanks,
Miklos

Re: [RFC 5/5] MIPS: Add Realtek RTL8186 SoC support

[Yasha Cherikovsky]

On Mon, 2018-10-01 at 10:15 +0100, Marc Zyngier wrote:
> On 01/10/18 09:48, Yasha Cherikovsky wrote:
> > Hi Marc,
> > 
> > On Mon, 2018-10-01 at 09:19 +0100, Marc Zyngier wrote:
> > > Hi Yasha,
> > > 
> > > On 30/09/18 15:15, Yasha Cherikovsky wrote:
> > > > The Realtek RTL8186 SoC is a MIPS based SoC
> > > > used in some home routers [1][2].
> > > > 
> > > > The hardware includes Lexra LX5280 CPU with a TLB,
> > > > two Ethernet controllers, a WLAN controller and more.
> > > > 
> > > > With this patch, it is possible to successfully boot
> > > > the kernel and load userspace on the Edimax BR-6204Wg
> > > > router.
> > > > Network drivers support will come in future patches.
> > > > 
> > > > This patch includes:
> > > > - New MIPS rtl8186 platform
> > > >   - Core platform setup code (mostly DT based)
> > > >   - New Kconfig option
> > > >   - defconfig file
> > > >   - MIPS zboot UART support
> > > > - RTL8186 interrupt controller driver
> > > > - RTL8186 timer driver
> > > > - Device tree files for the RTL8186 SoC and Edimax BR-6204Wg
> > > > router
> > > > 
> > > > [1] https://www.linux-mips.org/wiki/Realtek_SOC#Realtek_RTL8186
> > > > [2] https://wikidevi.com/wiki/Realtek_RTL8186
> > > > 
> > > > Signed-off-by: Yasha Cherikovsky 
> > > > Cc: Ralf Baechle 
> > > > Cc: Paul Burton 
> > > > Cc: James Hogan 
> > > > Cc: Thomas Gleixner 
> > > > Cc: Jason Cooper 
> > > > Cc: Marc Zyngier 
> > > > Cc: Daniel Lezcano 
> > > > Cc: Rob Herring 
> > > > Cc: Mark Rutland 
> > > > Cc: linux-m...@linux-mips.org
> > > > Cc: devicet...@vger.kernel.org
> > > > Cc: linux-kernel@vger.kernel.org
> > > > ---
> > > >arch/mips/Kbuild.platforms|   1 +
> > > >arch/mips/Kconfig |  17 ++
> > > >arch/mips/boot/compressed/uart-16550.c|   5 +
> > > >arch/mips/boot/dts/Makefile   |   1 +
> > > >arch/mips/boot/dts/realtek/Makefile   |   4 +
> > > >arch/mips/boot/dts/realtek/rtl8186.dtsi   |  86 +++
> > > >.../dts/realtek/rtl8186_edimax_br_6204wg.dts  |  45 
> > > >arch/mips/configs/rtl8186_defconfig   | 112 +
> > > >arch/mips/include/asm/mach-rtl8186/rtl8186.h  |  37 +++
> > > >arch/mips/rtl8186/Makefile|   2 +
> > > >arch/mips/rtl8186/Platform|   7 +
> > > >arch/mips/rtl8186/irq.c   |   8 +
> > > >arch/mips/rtl8186/prom.c  |  15 ++
> > > >arch/mips/rtl8186/setup.c |  80 +++
> > > >arch/mips/rtl8186/time.c  |  10 +
> > > >drivers/clocksource/Kconfig   |   9 +
> > > >drivers/clocksource/Makefile  |   1 +
> > > >drivers/clocksource/timer-rtl8186.c   | 220
> > > > ++
> > > >drivers/irqchip/Kconfig   |   5 +
> > > >drivers/irqchip/Makefile  |   1 +
> > > >drivers/irqchip/irq-rtl8186.c | 107 +
> > > 
> > > Could you please split this into at least three patches (arch code,
> > > clocksource, irqchip) to ease the review?
> > > 
> > > Thanks,
> > > 
> > >   M.
> > 
> > Currently the RTL8186_IRQ and the RTL8186_TIMER Kconfig entries depend
> > on
> > MACH_RTL8186 (which is added in the MIPS portion of the same patch).
> > Also, MACH_RTL8186 in MIPS selects these two options.
> > 
> > What is the best way to split that?
> 
> It is absolutely fine to have something depending on a non-selectable 
> config option, which would allow you to split things up as finely as you 
> want. Just have the patch enabling the config option last.
> 
> Thanks,
> 
>   M.

Good to know, thanks.
I'll send a v2 soon.

Yasha

Re: [LKP] [fsnotify] 60f7ed8c7c: will-it-scale.per_thread_ops -5.9% regression

[Jan Kara]

On Sun 30-09-18 12:16:45, Amir Goldstein wrote:
> On Sun, Sep 30, 2018 at 12:00 PM Amir Goldstein  wrote:
> >
> > On Sun, Sep 30, 2018 at 9:50 AM kernel test robot  
> > wrote:
> > >
> > > Greeting,
> > >
> > > FYI, we noticed a -5.9% regression of will-it-scale.per_thread_ops due to 
> > > commit:
> > >
> > >
> > > commit: 60f7ed8c7c4d06aeda448c6da74621552ee739aa ("fsnotify: send path 
> > > type events to group with super block marks")
> > > https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master
> > >
> > > in testcase: will-it-scale
> > > on test machine: 88 threads Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz 
> > > with 64G memory
> > > with following parameters:
> > >
> > > nr_task: 16
> > > mode: thread
> > > test: unlink2
> > > cpufreq_governor: performance
> > >
> > > test-description: Will It Scale takes a testcase and runs it from 1 
> > > through to n parallel copies to see if the testcase will scale. It builds 
> > > both a process and threads based test in order to see any differences 
> > > between the two.
> > > test-url: https://github.com/antonblanchard/will-it-scale
> > >
> > >
> > >
> > > Details are as below:
> > > -->
> > >
> > >
> > > To reproduce:
> > >
> > > git clone https://github.com/intel/lkp-tests.git
> > > cd lkp-tests
> > > bin/lkp install job.yaml  # job file is attached in this email
> > > bin/lkp run job.yaml
> > >
> > > =
> > > compiler/cpufreq_governor/kconfig/mode/nr_task/rootfs/tbox_group/test/testcase:
> > >   
> > > gcc-7/performance/x86_64-rhel-7.2/thread/16/debian-x86_64-2018-04-03.cgz/lkp-bdw-ep3d/unlink2/will-it-scale
> > >
> > > commit:
> > >   1e6cb72399 ("fsnotify: add super block object type")
> > >   60f7ed8c7c ("fsnotify: send path type events to group with super block 
> > > marks")
> > >
> >
> > I have to admit this looks strange.
> > All this commit does is dereference mnt->mnt.mnt_sb and then
> > sb->s_fsnotify_mask/sb->s_fsnotify_marks to find that they are zero.
> > AFAICT there should be no extra contention added by this commit and it's
> > hard to believe that parallel unlink workload would suffer from this change.
> >
> > I will try to install lkp-tests to verify this on my own system, but
> > until proven
> > otherwise I will regard this as false positive.
> >
> 
> Actually, is it possible to ask for a private test with the following patch
> to optimize out an unneeded srcu_derefence().
> This optimization (assuming it is correct) could in fact improve scaling
> compared to upstream, because there are already 2 calls to
> fsnotify_first_mark in the code. The blamed commit just adds a 3rd one.

I'd be surprised if your patch actually changed anything. On x86,
srcu_dereference(foo) is just READ_ONCE(foo) and that is just a syntactic
suggar around foo to make sure compiler really fetches the value from
memory to a register only once... But it's probably worth a try.

> I am assuming that() in the test there is an fsnotify mount mark (maybe setup
> by systemd) otherwise, the optimization in line 351 would have not reached
> the extra fsnotify_first_mark() call.
> Can you confirm or disprove the assumption that an fanotify mount mark
> is present during the test?

This would be good to know.

Honza

> 
> diff --git a/fs/notify/fsnotify.c b/fs/notify/fsnotify.c
> index 422fbc6dffde..8d45d82e09ff 100644
> --- a/fs/notify/fsnotify.c
> +++ b/fs/notify/fsnotify.c
> @@ -246,6 +246,9 @@ static struct fsnotify_mark
> *fsnotify_first_mark(struct fsnotify_mark_connector
> struct fsnotify_mark_connector *conn;
> struct hlist_node *node = NULL;
> 
> +   if (!*connp)
> +   return NULL;
> +
> conn = srcu_dereference(*connp, &fsnotify_mark_srcu);
> if (conn)
> node = srcu_dereference(conn->list.first, 
> &fsnotify_mark_srcu);
-- 
Jan Kara 
SUSE Labs, CR

Re: [PATCH] fuse: Fix use-after-free in fuse_dev_do_write()

[Miklos Szeredi]

On Tue, Sep 25, 2018 at 11:52 AM, Kirill Tkhai  wrote:
> After we found req in request_find() and released the lock,
> everything may happen with the req in parallel.
>
> Keep it alive till we finish touch its memory.
>
> Signed-off-by: Kirill Tkhai 

Applied.

Thanks,
Miklos

Re: [PATCH] fuse: Fix use-after-free in fuse_dev_do_read()

[Miklos Szeredi]

On Tue, Sep 25, 2018 at 11:28 AM, Kirill Tkhai  wrote:
> We may pick freed req in this way:
>
> [cpu0]  [cpu1]
> fuse_dev_do_read()  fuse_dev_do_write()
>list_move_tail(&req->list, &fpq->processing);  ...
>spin_unlock(&fpq->lock);   ...
>...request_end(fc, req);
>...  fuse_put_request(fc, 
> req);
>if (test_bit(FR_INTERRUPTED, &req->flags))
>  queue_interrupt(fiq, req);
>
> Fix that by keeping req alive till we finish all manipulations.
>
> Reported-by: syzbot+4e975615ca01f2277...@syzkaller.appspotmail.com
> Signed-off-by: Kirill Tkhai 

Applied.

Thanks,
Miklos

[PATCH 1/5] thunderbolt: Remove a meaningless NULL pointer check before dma_pool_destroy

[Mika Westerberg]

From: zhong jiang 

dma_pool_destroy() already takes NULL pointer into account so there is
no need to check that again in tb_ctl_free().

Signed-off-by: zhong jiang 
[mw: reword commit log a bit]
Signed-off-by: Mika Westerberg 
---
 drivers/thunderbolt/ctl.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/thunderbolt/ctl.c b/drivers/thunderbolt/ctl.c
index 37a7f4c735d0..e54e84e43ede 100644
--- a/drivers/thunderbolt/ctl.c
+++ b/drivers/thunderbolt/ctl.c
@@ -662,8 +662,7 @@ void tb_ctl_free(struct tb_ctl *ctl)
tb_ctl_pkg_free(ctl->rx_packets[i]);
 
 
-   if (ctl->frame_pool)
-   dma_pool_destroy(ctl->frame_pool);
+   dma_pool_destroy(ctl->frame_pool);
kfree(ctl);
 }
 
-- 
2.19.0

[PATCH 3/5] thunderbolt: Print connected devices

[Mika Westerberg]

The previous patch made the driver less verbose meanining that all the
switch structures and ports are now logged as debug level. However, we
have been missing similar output that USB for intance prints when a new
USB device is connected and disconnected. This information is useful for
end users as well as developers because it immediately shows the actual
device that was connected.

This patch adds printing of the actual connected devices to the driver.

Signed-off-by: Mika Westerberg 
Acked-by: Yehezkel Bernat 
---
 drivers/thunderbolt/switch.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/thunderbolt/switch.c b/drivers/thunderbolt/switch.c
index 81134ee29578..9f44a2924dac 100644
--- a/drivers/thunderbolt/switch.c
+++ b/drivers/thunderbolt/switch.c
@@ -1402,6 +1402,14 @@ int tb_switch_add(struct tb_switch *sw)
if (ret)
return ret;
 
+   if (tb_route(sw)) {
+   dev_info(&sw->dev, "new device found, vendor=%#x device=%#x\n",
+sw->vendor, sw->device);
+   if (sw->vendor_name && sw->device_name)
+   dev_info(&sw->dev, "%s %s\n", sw->vendor_name,
+sw->device_name);
+   }
+
ret = tb_switch_nvm_add(sw);
if (ret) {
device_del(&sw->dev);
@@ -1453,6 +1461,9 @@ void tb_switch_remove(struct tb_switch *sw)
tb_plug_events_active(sw, false);
 
tb_switch_nvm_remove(sw);
+
+   if (tb_route(sw))
+   dev_info(&sw->dev, "device disconnected\n");
device_unregister(&sw->dev);
 }
 
-- 
2.19.0

[PATCH 0/5] thunderbolt: Changes for v4.20 merge window

[Mika Westerberg]

Hi Greg,

Here are Thunderbolt changes I've queued for v4.20 merge window. I guess
the most notable change is that now the driver is not as verbose it used to
be and it now prints out the connected devices in the same way USB stack
does. In addition there are removal of meaningless NULL pointer check, some
conversions to use SPDX identifies and copyright update.

I've also included all the patches in case you prefer to take them directly
instead of pulling the signed tag.

Thanks!

The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3:

  Linux 4.19-rc1 (2018-08-26 14:11:59 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt.git 
tags/thunderbolt-for-v4.20

for you to fetch changes up to 7086a65c7634d3c9c4d48fcc06b7e35f9dd0ee43:

  thunderbolt: Add Intel as copyright holder (2018-09-21 11:21:24 +0300)


thunderbolt: Changes for v4.20 merge window



Mika Westerberg (4):
  thunderbolt: Make the driver less verbose
  thunderbolt: Print connected devices
  thunderbolt: Convert rest of the driver files to use SPDX identifier
  thunderbolt: Add Intel as copyright holder

zhong jiang (1):
  thunderbolt: Remove a meaningless NULL pointer check before dma_pool_destroy

 drivers/thunderbolt/cap.c  |  3 +-
 drivers/thunderbolt/ctl.c  | 12 +++---
 drivers/thunderbolt/ctl.h  |  3 +-
 drivers/thunderbolt/dma_port.c |  5 +--
 drivers/thunderbolt/dma_port.h |  5 +--
 drivers/thunderbolt/domain.c   |  7 +---
 drivers/thunderbolt/eeprom.c   |  5 ++-
 drivers/thunderbolt/icm.c  |  5 +--
 drivers/thunderbolt/nhi.c  | 33 
 drivers/thunderbolt/nhi.h  |  3 +-
 drivers/thunderbolt/nhi_regs.h |  1 +
 drivers/thunderbolt/path.c | 26 ++---
 drivers/thunderbolt/property.c |  5 +--
 drivers/thunderbolt/switch.c   | 71 +++---
 drivers/thunderbolt/tb.c   | 10 ++---
 drivers/thunderbolt/tb.h   |  9 +++--
 drivers/thunderbolt/tb_msgs.h  |  5 +--
 drivers/thunderbolt/tb_regs.h  |  3 +-
 drivers/thunderbolt/xdomain.c  |  5 +--
 include/linux/thunderbolt.h|  5 +--
 20 files changed, 108 insertions(+), 113 deletions(-)

-- 
2.19.0

Re: [PATCH V2 09/27] mmc: mmci: modify dma_setup callback

[Ulf Hansson]

On 21 September 2018 at 11:46, Ludovic Barre  wrote:
> From: Ludovic Barre 
>
> This patch creates a generic mmci_dma_setup which calls
> dma_setup callback and manages common next_cookie.
> This patch is needed for sdmmc variant which has a different
> dma settings.
>
> Signed-off-by: Ludovic Barre 
>
> # Conflicts:
> #   drivers/mmc/host/mmci.h
>

Please remove this. Looks like some of the other patches in the series
have this in their changelogs as well, please have a look and fix them
all.

[...]

Kind regards
Uffe

Re: [PATCH V2 23/27] mmc: mmci: add variant property to request a reset

[Ulf Hansson]

On 21 September 2018 at 11:46, Ludovic Barre  wrote:
> From: Ludovic Barre 
>
> Some variants could require a reset.
> STM32 sdmmc variant needs to reset hardware block
> during the power cycle procedure (for re-initialization)
>
> Signed-off-by: Ludovic Barre 
> ---
>  Documentation/devicetree/bindings/mmc/mmci.txt | 2 ++
>  drivers/mmc/host/mmci.c| 9 +
>  drivers/mmc/host/mmci.h| 4 
>  3 files changed, 15 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mmc/mmci.txt 
> b/Documentation/devicetree/bindings/mmc/mmci.txt
> index 03796cf..e952707 100644
> --- a/Documentation/devicetree/bindings/mmc/mmci.txt
> +++ b/Documentation/devicetree/bindings/mmc/mmci.txt
> @@ -11,6 +11,8 @@ Required properties:
>  - compatible : contains "arm,pl18x", "arm,primecell".
>  - vmmc-supply: phandle to the regulator device tree node, 
> mentioned
> as the VCC/VDD supply in the eMMC/SD specs.
> +depend of variant:
> +- resets : phandle to internal reset line.
>

This looks like a thing depending on the SoC, rather than on the
variant. Therefore, I suggest you move this to be an optional DT
property.

Also, please move the DT doc update into a separate patch.

>  Optional properties:
>  - arm,primecell-periphid : contains the PrimeCell Peripheral ID, it overrides
> diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
> index b1d5bc5..6b3c33f 100644
> --- a/drivers/mmc/host/mmci.c
> +++ b/drivers/mmc/host/mmci.c
> @@ -37,6 +37,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include 
>  #include 
> @@ -1854,6 +1855,14 @@ static int mmci_probe(struct amba_device *dev,
>
> dev_dbg(mmc_dev(mmc), "clocking block at %u Hz\n", mmc->f_max);
>
> +   if (variant->reset) {
> +   host->rst = devm_reset_control_get_exclusive(&dev->dev, NULL);

As suggested, let's make this optional and not depending on the variant.

> +   if (IS_ERR(host->rst)) {
> +   ret = PTR_ERR(host->rst);
> +   goto clk_disable;
> +   }
> +   }
> +
> /* Get regulators and the supported OCR mask */
> ret = mmc_regulator_get_supply(mmc);
> if (ret)
> diff --git a/drivers/mmc/host/mmci.h b/drivers/mmc/host/mmci.h
> index e130689..f0fa185 100644
> --- a/drivers/mmc/host/mmci.h
> +++ b/drivers/mmc/host/mmci.h
> @@ -247,6 +247,7 @@ struct mmci_host;
>   * @start_err: bitmask identifying the STARTBITERR bit inside MMCISTATUS
>   *register.
>   * @opendrain: bitmask identifying the OPENDRAIN bit inside MMCIPOWER 
> register
> + * @reset: true if variant has need reset signal.
>   */
>  struct variant_data {
> unsigned intclkreg;
> @@ -285,6 +286,7 @@ struct variant_data {
> boolqcom_dml;
> boolreversed_irq_handling;
> boolmmcimask1;
> +   boolreset;
> unsigned intirq_pio_mask;
> u32 start_err;
> u32 opendrain;
> @@ -318,6 +320,8 @@ struct mmci_host {
> struct clk  *clk;
> boolsingleirq;
>
> +   struct reset_control*rst;
> +
> spinlock_t  lock;
>
> unsigned intmclk;
> --
> 2.7.4
>

Kind regards
Uffe

Re: [PATCH V2 26/27] mmc: mmci: add DT bindings for STM32 sdmmc

[Ulf Hansson]

On 21 September 2018 at 11:46, Ludovic Barre  wrote:
> From: Ludovic Barre 
>
> STM32 sdmmc variant has support to:
> -Indicate signal directions (only one property
> for d0dir, d123dir, cmd_dir)
> -Select command and data phase relation.
> -Select "clock in" from an external driver.
>
> Signed-off-by: Ludovic Barre 
> ---
> change v3:
> -remove space at end of "st,use-ckin "
>
>  Documentation/devicetree/bindings/mmc/mmci.txt | 9 +

Please split this. DT doc changes should be separate patches.

>  drivers/mmc/host/mmci.c| 6 ++
>  drivers/mmc/host/mmci.h| 1 +
>  3 files changed, 16 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mmc/mmci.txt 
> b/Documentation/devicetree/bindings/mmc/mmci.txt
> index e952707..d678933 100644
> --- a/Documentation/devicetree/bindings/mmc/mmci.txt
> +++ b/Documentation/devicetree/bindings/mmc/mmci.txt
> @@ -19,6 +19,7 @@ Optional properties:
> the ID provided by the HW
>  - vqmmc-supply   : phandle to the regulator device tree node, 
> mentioned
> as the VCCQ/VDD_IO supply in the eMMC/SD specs.
> +specific for ux500 variant:
>  - st,sig-dir-dat0: bus signal direction pin used for DAT[0].
>  - st,sig-dir-dat2: bus signal direction pin used for DAT[2].
>  - st,sig-dir-dat31   : bus signal direction pin used for DAT[3] and 
> DAT[1].
> @@ -26,6 +27,14 @@ Optional properties:
>  - st,sig-dir-cmd : cmd signal direction pin used for CMD.
>  - st,sig-pin-fbclk   : feedback clock signal pin used.
>
> +specific for sdmmc variant:
> +- st,sig-dir : signal direction polarity used for cmd, dat0 
> dat123.
> +- st,neg-edge: data & command phase relation, generated on
> +   sd clock falling edge.
> +- st,use-ckin: use ckin pin from an external driver to sample
> +   the receive data (example: with voltage
> +  switch transceiver).

[...]

Kind regards
Uffe

[PATCH 4/5] thunderbolt: Convert rest of the driver files to use SPDX identifier

[Mika Westerberg]

This gets rid of the licence boilerplate duplicated in each file. While
there fix doubled space in domain.c author line.

No functional changes intended.

Signed-off-by: Mika Westerberg 
Acked-by: Yehezkel Bernat 
---
 drivers/thunderbolt/dma_port.c | 5 +
 drivers/thunderbolt/dma_port.h | 5 +
 drivers/thunderbolt/domain.c   | 7 ++-
 drivers/thunderbolt/icm.c  | 5 +
 drivers/thunderbolt/property.c | 5 +
 drivers/thunderbolt/tb_msgs.h  | 5 +
 drivers/thunderbolt/xdomain.c  | 5 +
 include/linux/thunderbolt.h| 5 +
 8 files changed, 9 insertions(+), 33 deletions(-)

diff --git a/drivers/thunderbolt/dma_port.c b/drivers/thunderbolt/dma_port.c
index f2701194f810..847dd07a7b17 100644
--- a/drivers/thunderbolt/dma_port.c
+++ b/drivers/thunderbolt/dma_port.c
@@ -1,13 +1,10 @@
+// SPDX-License-Identifier: GPL-2.0
 /*
  * Thunderbolt DMA configuration based mailbox support
  *
  * Copyright (C) 2017, Intel Corporation
  * Authors: Michael Jamet 
  *  Mika Westerberg 
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
  */
 
 #include 
diff --git a/drivers/thunderbolt/dma_port.h b/drivers/thunderbolt/dma_port.h
index c4a69e0fbff7..7deadd97ce31 100644
--- a/drivers/thunderbolt/dma_port.h
+++ b/drivers/thunderbolt/dma_port.h
@@ -1,13 +1,10 @@
+/* SPDX-License-Identifier: GPL-2.0 */
 /*
  * Thunderbolt DMA configuration based mailbox support
  *
  * Copyright (C) 2017, Intel Corporation
  * Authors: Michael Jamet 
  *  Mika Westerberg 
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
  */
 
 #ifndef DMA_PORT_H_
diff --git a/drivers/thunderbolt/domain.c b/drivers/thunderbolt/domain.c
index 092381e2accf..93e562f18d40 100644
--- a/drivers/thunderbolt/domain.c
+++ b/drivers/thunderbolt/domain.c
@@ -1,12 +1,9 @@
+// SPDX-License-Identifier: GPL-2.0
 /*
  * Thunderbolt bus support
  *
  * Copyright (C) 2017, Intel Corporation
- * Author:  Mika Westerberg 
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
+ * Author: Mika Westerberg 
  */
 
 #include 
diff --git a/drivers/thunderbolt/icm.c b/drivers/thunderbolt/icm.c
index e1e264a9a4c7..533068651f90 100644
--- a/drivers/thunderbolt/icm.c
+++ b/drivers/thunderbolt/icm.c
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0
 /*
  * Internal Thunderbolt Connection Manager. This is a firmware running on
  * the Thunderbolt host controller performing most of the low-level
@@ -6,10 +7,6 @@
  * Copyright (C) 2017, Intel Corporation
  * Authors: Michael Jamet 
  *  Mika Westerberg 
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
  */
 
 #include 
diff --git a/drivers/thunderbolt/property.c b/drivers/thunderbolt/property.c
index 8fe913a95b4a..b2f0d6386cee 100644
--- a/drivers/thunderbolt/property.c
+++ b/drivers/thunderbolt/property.c
@@ -1,13 +1,10 @@
+// SPDX-License-Identifier: GPL-2.0
 /*
  * Thunderbolt XDomain property support
  *
  * Copyright (C) 2017, Intel Corporation
  * Authors: Michael Jamet 
  *  Mika Westerberg 
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
  */
 
 #include 
diff --git a/drivers/thunderbolt/tb_msgs.h b/drivers/thunderbolt/tb_msgs.h
index 2487e162c885..02c84aa3d018 100644
--- a/drivers/thunderbolt/tb_msgs.h
+++ b/drivers/thunderbolt/tb_msgs.h
@@ -1,12 +1,9 @@
+/* SPDX-License-Identifier: GPL-2.0 */
 /*
  * Thunderbolt control channel messages
  *
  * Copyright (C) 2014 Andreas Noever 
  * Copyright (C) 2017, Intel Corporation
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
  */
 
 #ifndef _TB_MSGS
diff --git a/drivers/thunderbolt/xdomain.c b/drivers/thunderbolt/xdomain.c
index db8bece63327..e27dd8beb94b 100644
--- a/drivers/thunderbolt/xdomain.c
+++ b/drivers/thunderbolt/xdomain.c
@@ -1,13 +1,10 @@
+// SPDX-License-Identifier: GPL-2.0
 /*
  * Thunderbolt XDomain discovery protocol support
  *
  * Copyright (C) 2017, Intel Corporation
  * Authors: Michael Jamet 
  *  Mika Westerberg 
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
  */
 
 #include 
diff --git a/include/linux/thunder

[PATCH 2/5] thunderbolt: Make the driver less verbose

[Mika Westerberg]

Currently the driver logs quite a lot to the system message buffer even
when doing normal operations. This information is not useful for
ordinary users and might even annoy some.

For this reason convert most of the logs at info level to happen at
debug level instead. The nice output formatting is untouched.

Logging can be easily re-enabled by passing "thunderbolt.dyndbg" in the
kernel command line (or using the corresponding control file runtime).

Signed-off-by: Mika Westerberg 
Acked-by: Yehezkel Bernat 
---
 drivers/thunderbolt/ctl.c|  6 ++--
 drivers/thunderbolt/eeprom.c |  2 +-
 drivers/thunderbolt/nhi.c| 30 +--
 drivers/thunderbolt/path.c   | 26 
 drivers/thunderbolt/switch.c | 57 +---
 drivers/thunderbolt/tb.c | 10 +++
 drivers/thunderbolt/tb.h |  6 ++--
 7 files changed, 68 insertions(+), 69 deletions(-)

diff --git a/drivers/thunderbolt/ctl.c b/drivers/thunderbolt/ctl.c
index e54e84e43ede..7456c094e232 100644
--- a/drivers/thunderbolt/ctl.c
+++ b/drivers/thunderbolt/ctl.c
@@ -631,7 +631,7 @@ struct tb_ctl *tb_ctl_alloc(struct tb_nhi *nhi, event_cb 
cb, void *cb_data)
ctl->rx_packets[i]->frame.callback = tb_ctl_rx_callback;
}
 
-   tb_ctl_info(ctl, "control channel created\n");
+   tb_ctl_dbg(ctl, "control channel created\n");
return ctl;
 err:
tb_ctl_free(ctl);
@@ -672,7 +672,7 @@ void tb_ctl_free(struct tb_ctl *ctl)
 void tb_ctl_start(struct tb_ctl *ctl)
 {
int i;
-   tb_ctl_info(ctl, "control channel starting...\n");
+   tb_ctl_dbg(ctl, "control channel starting...\n");
tb_ring_start(ctl->tx); /* is used to ack hotplug packets, start first 
*/
tb_ring_start(ctl->rx);
for (i = 0; i < TB_CTL_RX_PKG_COUNT; i++)
@@ -701,7 +701,7 @@ void tb_ctl_stop(struct tb_ctl *ctl)
if (!list_empty(&ctl->request_queue))
tb_ctl_WARN(ctl, "dangling request in request_queue\n");
INIT_LIST_HEAD(&ctl->request_queue);
-   tb_ctl_info(ctl, "control channel stopped\n");
+   tb_ctl_dbg(ctl, "control channel stopped\n");
 }
 
 /* public interface, commands */
diff --git a/drivers/thunderbolt/eeprom.c b/drivers/thunderbolt/eeprom.c
index 3e8caf22c294..d2dd40390783 100644
--- a/drivers/thunderbolt/eeprom.c
+++ b/drivers/thunderbolt/eeprom.c
@@ -540,7 +540,7 @@ int tb_drom_read(struct tb_switch *sw)
return res;
size &= 0x3ff;
size += TB_DROM_DATA_START;
-   tb_sw_info(sw, "reading drom (length: %#x)\n", size);
+   tb_sw_dbg(sw, "reading drom (length: %#x)\n", size);
if (size < sizeof(*header)) {
tb_sw_warn(sw, "drom too small, aborting\n");
return -EIO;
diff --git a/drivers/thunderbolt/nhi.c b/drivers/thunderbolt/nhi.c
index 88cff05a1808..02379aa27120 100644
--- a/drivers/thunderbolt/nhi.c
+++ b/drivers/thunderbolt/nhi.c
@@ -95,9 +95,9 @@ static void ring_interrupt_active(struct tb_ring *ring, bool 
active)
else
new = old & ~mask;
 
-   dev_info(&ring->nhi->pdev->dev,
-"%s interrupt at register %#x bit %d (%#x -> %#x)\n",
-active ? "enabling" : "disabling", reg, bit, old, new);
+   dev_dbg(&ring->nhi->pdev->dev,
+   "%s interrupt at register %#x bit %d (%#x -> %#x)\n",
+   active ? "enabling" : "disabling", reg, bit, old, new);
 
if (new == old)
dev_WARN(&ring->nhi->pdev->dev,
@@ -476,8 +476,9 @@ static struct tb_ring *tb_ring_alloc(struct tb_nhi *nhi, 
u32 hop, int size,
 void *poll_data)
 {
struct tb_ring *ring = NULL;
-   dev_info(&nhi->pdev->dev, "allocating %s ring %d of size %d\n",
-transmit ? "TX" : "RX", hop, size);
+
+   dev_dbg(&nhi->pdev->dev, "allocating %s ring %d of size %d\n",
+   transmit ? "TX" : "RX", hop, size);
 
/* Tx Ring 2 is reserved for E2E workaround */
if (transmit && hop == RING_E2E_UNUSED_HOPID)
@@ -585,8 +586,8 @@ void tb_ring_start(struct tb_ring *ring)
dev_WARN(&ring->nhi->pdev->dev, "ring already started\n");
goto err;
}
-   dev_info(&ring->nhi->pdev->dev, "starting %s %d\n",
-RING_TYPE(ring), ring->hop);
+   dev_dbg(&ring->nhi->pdev->dev, "starting %s %d\n",
+   RING_TYPE(ring), ring->hop);
 
if (ring->flags & RING_FLAG_FRAME) {
/* Means 4096 */
@@ -647,8 +648,8 @@ void tb_ring_stop(struct tb_ring *ring)
 {
spin_lock_irq(&ring->nhi->lock);
spin_lock(&ring->lock);
-   dev_info(&ring->nhi->pdev->dev, "stopping %s %d\n",
-RING_TYPE(ring), ring->hop);
+   dev_dbg(&ring->nhi->pdev->dev, "stopping %s %d\n",
+   RING_TYPE(ring), ring->hop);
if (ring->nhi->going_away)
goto err;
if (!ring->running) {
@@ -716,10 +717,8 @@ void tb_

Re: [PATCH V2 27/27] mmc: mmci: add stm32 sdmmc variant

[Ulf Hansson]

On 21 September 2018 at 11:46, Ludovic Barre  wrote:
> From: Ludovic Barre 
>
> This patch adds a stm32 sdmmc variant, rev 1.1.
> Introduces a new Manufacturer id "0x53, ascii 'S' to define
> new stm32 sdmmc family with clean range of amba
> revision/configurations bits (corresponding to sdmmc_ver
> register with major/minor fields).
>
> Signed-off-by: Ludovic Barre 
> ---
>  drivers/mmc/host/Kconfig|  10 ++
>  drivers/mmc/host/Makefile   |   1 +
>  drivers/mmc/host/mmci.c |  25 
>  drivers/mmc/host/mmci.h |   5 +
>  drivers/mmc/host/mmci_stm32_sdmmc.c | 282 
> 
>  5 files changed, 323 insertions(+)
>  create mode 100644 drivers/mmc/host/mmci_stm32_sdmmc.c
>
> diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
> index 5ab2eb0..e59671a 100644
> --- a/drivers/mmc/host/Kconfig
> +++ b/drivers/mmc/host/Kconfig
> @@ -34,6 +34,16 @@ config MMC_QCOM_DML
>
>   if unsure, say N.
>
> +config MMC_STM32_SDMMC
> +   bool "STMicroelectronics STM32 SDMMC Controller"
> +   depends on MMC_ARMMMCI
> +   default y
> +   help
> + This selects the STMicroelectronics STM32 SDMMC host controller.
> + If you have a STM32 sdmmc host with internal dma say Y or M here.
> +
> + If unsure, say N.
> +
>  config MMC_PXA
> tristate "Intel PXA25x/26x/27x Multimedia Card Interface support"
> depends on ARCH_PXA
> diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
> index ce8398e..f14410f 100644
> --- a/drivers/mmc/host/Makefile
> +++ b/drivers/mmc/host/Makefile
> @@ -6,6 +6,7 @@
>  obj-$(CONFIG_MMC_ARMMMCI) += armmmci.o
>  armmmci-y := mmci.o
>  armmmci-$(CONFIG_MMC_QCOM_DML) += mmci_qcom_dml.o
> +armmmci-$(CONFIG_MMC_STM32_SDMMC) += mmci_stm32_sdmmc.o
>  obj-$(CONFIG_MMC_PXA)  += pxamci.o
>  obj-$(CONFIG_MMC_MXC)  += mxcmmc.o
>  obj-$(CONFIG_MMC_MXS)  += mxs-mmc.o
> diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
> index 4057456..ca2e483 100644
> --- a/drivers/mmc/host/mmci.c
> +++ b/drivers/mmc/host/mmci.c
> @@ -254,6 +254,26 @@ static struct variant_data variant_stm32 = {
> .init   = mmci_variant_init,
>  };
>
> +static struct variant_data variant_stm32_sdmmc = {
> +   .fifosize   = 16 * 4,
> +   .fifohalfsize   = 8 * 4,
> +   .f_max  = 20800,
> +   .stm32_clkdiv   = true,
> +   .reset  = true,
> +   .cmdreg_cpsm_enable = MCI_CPSM_STM32_ENABLE,
> +   .cmdreg_lrsp_crc= MCI_CPSM_STM32_LRSP_CRC,
> +   .cmdreg_srsp_crc= MCI_CPSM_STM32_SRSP_CRC,
> +   .cmdreg_srsp= MCI_CPSM_STM32_SRSP,
> +   .data_cmd_enable= MCI_CPSM_STM32_CMDTRANS,
> +   .irq_pio_mask   = MCI_IRQ_PIO_STM32_MASK,
> +   .datactrl_first = true,
> +   .datacnt_useless= true,
> +   .datalength_bits= 25,
> +   .datactrl_blocksz   = 14,
> +   .stm32_idmabsize_mask   = GENMASK(12, 5),
> +   .init   = sdmmc_variant_init,
> +};
> +
>  static struct variant_data variant_qcom = {
> .fifosize   = 16 * 4,
> .fifohalfsize   = 8 * 4,
> @@ -2180,6 +2200,11 @@ static const struct amba_id mmci_ids[] = {
> .mask   = 0x00ff,
> .data   = &variant_stm32,
> },
> +   {
> +   .id = 0x10153180,
> +   .mask   = 0xf0ff,
> +   .data   = &variant_stm32_sdmmc,
> +   },
> /* Qualcomm variants */
> {
> .id = 0x00051180,
> diff --git a/drivers/mmc/host/mmci.h b/drivers/mmc/host/mmci.h
> index 017d9b8..581b9b1 100644
> --- a/drivers/mmc/host/mmci.h
> +++ b/drivers/mmc/host/mmci.h
> @@ -305,6 +305,8 @@ struct mmci_host;
>   *register.
>   * @opendrain: bitmask identifying the OPENDRAIN bit inside MMCIPOWER 
> register
>   * @reset: true if variant has need reset signal.
> + * @dma_lli: true if variant has dma link list feature.
> + * @stm32_idmabsize_mask: stm32 sdmmc idma buffer size.
>   */
>  struct variant_data {
> unsigned intclkreg;
> @@ -348,6 +350,8 @@ struct variant_data {
> unsigned intirq_pio_mask;
> u32 start_err;
> u32 opendrain;
> +   booldma_lli;
> +   u32 stm32_idmabsize_mask;

What are these?

> void (*init)(struct mmci_host *host);
>  };
>
> @@ -421,6 +425,7 @@ void mmci_write_clkreg(struct mmci_host *host, u32 clk);
>  void mmci_write_pwrreg(struct mmci_host *host, u32 pwr);
>
>  void mmci_variant_init(struct mmci_host *host);
> +void sdmmc_variant_init(struct mmci_host *host);
>
>  int mmci_dmae_prep_data(struct mmci_host *host, struct mmc_data *data,
> bool next);
> diff --git a/driv

[PATCH 5/5] thunderbolt: Add Intel as copyright holder

[Mika Westerberg]

Intel has done pretty major changes to the driver and we continue to do
so in the future as well. Add Intel as copyright holder of the files we
have done changes.

While there drop "Cactus Ridge" from the headers because this driver
works also with other Thunderbolt controllers.

No functional changes intended.

Signed-off-by: Mika Westerberg 
Acked-by: Yehezkel Bernat 
---
 drivers/thunderbolt/cap.c  | 3 ++-
 drivers/thunderbolt/ctl.c  | 3 ++-
 drivers/thunderbolt/ctl.h  | 3 ++-
 drivers/thunderbolt/eeprom.c   | 3 ++-
 drivers/thunderbolt/nhi.c  | 3 ++-
 drivers/thunderbolt/nhi.h  | 3 ++-
 drivers/thunderbolt/nhi_regs.h | 1 +
 drivers/thunderbolt/switch.c   | 3 ++-
 drivers/thunderbolt/tb.h   | 3 ++-
 drivers/thunderbolt/tb_regs.h  | 3 ++-
 10 files changed, 19 insertions(+), 9 deletions(-)

diff --git a/drivers/thunderbolt/cap.c b/drivers/thunderbolt/cap.c
index c2277b8ee88d..9553305c63ea 100644
--- a/drivers/thunderbolt/cap.c
+++ b/drivers/thunderbolt/cap.c
@@ -1,8 +1,9 @@
 // SPDX-License-Identifier: GPL-2.0
 /*
- * Thunderbolt Cactus Ridge driver - capabilities lookup
+ * Thunderbolt driver - capabilities lookup
  *
  * Copyright (c) 2014 Andreas Noever 
+ * Copyright (C) 2018, Intel Corporation
  */
 
 #include 
diff --git a/drivers/thunderbolt/ctl.c b/drivers/thunderbolt/ctl.c
index 7456c094e232..73b386de4d15 100644
--- a/drivers/thunderbolt/ctl.c
+++ b/drivers/thunderbolt/ctl.c
@@ -1,8 +1,9 @@
 // SPDX-License-Identifier: GPL-2.0
 /*
- * Thunderbolt Cactus Ridge driver - control channel and configuration commands
+ * Thunderbolt driver - control channel and configuration commands
  *
  * Copyright (c) 2014 Andreas Noever 
+ * Copyright (C) 2018, Intel Corporation
  */
 
 #include 
diff --git a/drivers/thunderbolt/ctl.h b/drivers/thunderbolt/ctl.h
index 3062e0b5f71e..2f1a1e10 100644
--- a/drivers/thunderbolt/ctl.h
+++ b/drivers/thunderbolt/ctl.h
@@ -1,8 +1,9 @@
 /* SPDX-License-Identifier: GPL-2.0 */
 /*
- * Thunderbolt Cactus Ridge driver - control channel and configuration commands
+ * Thunderbolt driver - control channel and configuration commands
  *
  * Copyright (c) 2014 Andreas Noever 
+ * Copyright (C) 2018, Intel Corporation
  */
 
 #ifndef _TB_CFG
diff --git a/drivers/thunderbolt/eeprom.c b/drivers/thunderbolt/eeprom.c
index d2dd40390783..81e8ac4c5805 100644
--- a/drivers/thunderbolt/eeprom.c
+++ b/drivers/thunderbolt/eeprom.c
@@ -1,8 +1,9 @@
 // SPDX-License-Identifier: GPL-2.0
 /*
- * Thunderbolt Cactus Ridge driver - eeprom access
+ * Thunderbolt driver - eeprom access
  *
  * Copyright (c) 2014 Andreas Noever 
+ * Copyright (C) 2018, Intel Corporation
  */
 
 #include 
diff --git a/drivers/thunderbolt/nhi.c b/drivers/thunderbolt/nhi.c
index 02379aa27120..2874f9400123 100644
--- a/drivers/thunderbolt/nhi.c
+++ b/drivers/thunderbolt/nhi.c
@@ -1,10 +1,11 @@
 /*
- * Thunderbolt Cactus Ridge driver - NHI driver
+ * Thunderbolt driver - NHI driver
  *
  * The NHI (native host interface) is the pci device that allows us to send and
  * receive frames from the thunderbolt bus.
  *
  * Copyright (c) 2014 Andreas Noever 
+ * Copyright (C) 2018, Intel Corporation
  */
 
 #include 
diff --git a/drivers/thunderbolt/nhi.h b/drivers/thunderbolt/nhi.h
index 1696a4560948..1b5d47ecd3ed 100644
--- a/drivers/thunderbolt/nhi.h
+++ b/drivers/thunderbolt/nhi.h
@@ -1,8 +1,9 @@
 /* SPDX-License-Identifier: GPL-2.0 */
 /*
- * Thunderbolt Cactus Ridge driver - NHI driver
+ * Thunderbolt driver - NHI driver
  *
  * Copyright (c) 2014 Andreas Noever 
+ * Copyright (C) 2018, Intel Corporation
  */
 
 #ifndef DSL3510_H_
diff --git a/drivers/thunderbolt/nhi_regs.h b/drivers/thunderbolt/nhi_regs.h
index b3e49d19c01e..a60bd98c1d04 100644
--- a/drivers/thunderbolt/nhi_regs.h
+++ b/drivers/thunderbolt/nhi_regs.h
@@ -3,6 +3,7 @@
  * Thunderbolt driver - NHI registers
  *
  * Copyright (c) 2014 Andreas Noever 
+ * Copyright (C) 2018, Intel Corporation
  */
 
 #ifndef NHI_REGS_H_
diff --git a/drivers/thunderbolt/switch.c b/drivers/thunderbolt/switch.c
index 9f44a2924dac..52ff854f0d6c 100644
--- a/drivers/thunderbolt/switch.c
+++ b/drivers/thunderbolt/switch.c
@@ -1,8 +1,9 @@
 // SPDX-License-Identifier: GPL-2.0
 /*
- * Thunderbolt Cactus Ridge driver - switch/port utility functions
+ * Thunderbolt driver - switch/port utility functions
  *
  * Copyright (c) 2014 Andreas Noever 
+ * Copyright (C) 2018, Intel Corporation
  */
 
 #include 
diff --git a/drivers/thunderbolt/tb.h b/drivers/thunderbolt/tb.h
index 5a99245573c0..52584c4003e3 100644
--- a/drivers/thunderbolt/tb.h
+++ b/drivers/thunderbolt/tb.h
@@ -1,8 +1,9 @@
 /* SPDX-License-Identifier: GPL-2.0 */
 /*
- * Thunderbolt Cactus Ridge driver - bus logic (NHI independent)
+ * Thunderbolt driver - bus logic (NHI independent)
  *
  * Copyright (c) 2014 Andreas Noever 
+ * Copyright (C) 2018, Intel Corporation
  */
 
 #ifndef TB_H_
diff --git a/drivers/thunderbolt/tb_regs.h b/drivers/thunderbolt/tb_regs.h
index 693b0353c3fe..6f1ff04ee195 100644
--

Re: [LKP] [fsnotify] 60f7ed8c7c: will-it-scale.per_thread_ops -5.9% regression

[Jan Kara]

On Sun 30-09-18 12:00:46, Amir Goldstein wrote:
> On Sun, Sep 30, 2018 at 9:50 AM kernel test robot  
> wrote:
> >
> > Greeting,
> >
> > FYI, we noticed a -5.9% regression of will-it-scale.per_thread_ops due to 
> > commit:
> >
> >
> > commit: 60f7ed8c7c4d06aeda448c6da74621552ee739aa ("fsnotify: send path type 
> > events to group with super block marks")
> > https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master
> >
> > in testcase: will-it-scale
> > on test machine: 88 threads Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz with 
> > 64G memory
> > with following parameters:
> >
> > nr_task: 16
> > mode: thread
> > test: unlink2
> > cpufreq_governor: performance
> >
> > test-description: Will It Scale takes a testcase and runs it from 1 through 
> > to n parallel copies to see if the testcase will scale. It builds both a 
> > process and threads based test in order to see any differences between the 
> > two.
> > test-url: https://github.com/antonblanchard/will-it-scale
> >
> >
> >
> > Details are as below:
> > -->
> >
> >
> > To reproduce:
> >
> > git clone https://github.com/intel/lkp-tests.git
> > cd lkp-tests
> > bin/lkp install job.yaml  # job file is attached in this email
> > bin/lkp run job.yaml
> >
> > =
> > compiler/cpufreq_governor/kconfig/mode/nr_task/rootfs/tbox_group/test/testcase:
> >   
> > gcc-7/performance/x86_64-rhel-7.2/thread/16/debian-x86_64-2018-04-03.cgz/lkp-bdw-ep3d/unlink2/will-it-scale
> >
> > commit:
> >   1e6cb72399 ("fsnotify: add super block object type")
> >   60f7ed8c7c ("fsnotify: send path type events to group with super block 
> > marks")
> >
> 
> I have to admit this looks strange.
> All this commit does is dereference mnt->mnt.mnt_sb and then
> sb->s_fsnotify_mask/sb->s_fsnotify_marks to find that they are zero.
> AFAICT there should be no extra contention added by this commit and it's
> hard to believe that parallel unlink workload would suffer from this change.

Well, it could be those additional fetches of
sb->s_fsnotify_mask/sb->s_fsnotify_marks if they happen to be cache cold.
Or it could be just code layout differences (i.e., compiler is not able to
optimize resulting code as good or the code layout just happens to align
with cache lines in a wrong way or something like that). Anyway, without
being able to reproduce this and do detailed comparison of perf profiles I
don't think we'll be able to tell.

Honza
-- 
Jan Kara 
SUSE Labs, CR

Re: [PATCH V2 09/27] mmc: mmci: modify dma_setup callback

[Ludovic BARRE]

hi Ulf

On 10/01/2018 11:30 AM, Ulf Hansson wrote:

On 21 September 2018 at 11:46, Ludovic Barre  wrote:

From: Ludovic Barre 

This patch creates a generic mmci_dma_setup which calls
dma_setup callback and manages common next_cookie.
This patch is needed for sdmmc variant which has a different
dma settings.

Signed-off-by: Ludovic Barre 

# Conflicts:
#   drivers/mmc/host/mmci.h



Please remove this. Looks like some of the other patches in the series
have this in their changelogs as well, please have a look and fix them
all.



yes, it's a mistake due to rush work (like Version of cover letter).
sorry

BR
Ludo


[...]

Kind regards
Uffe

[PATCH 3/3] kbuild: add -Wno-unused-but-set-variable compiler flag unconditionally

[Masahiro Yamada]

We have raised the compiler requirement from time to time.
With commit cafa0010cd51 ("Raise the minimum required gcc version
to 4.6"), the minimum for GCC is 4.6 now.

This flag was added by GCC 4.6, and it is recognized by Clang and
ICC as well.

Let's rip off the cc-disable-warning switch, and see if somebody
complains about it.

Signed-off-by: Masahiro Yamada 
---

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

diff --git a/Makefile b/Makefile
index 8a23fee..2627266 100644
--- a/Makefile
+++ b/Makefile
@@ -716,7 +716,7 @@ else
 
 # These warnings generated too much noise in a regular build.
 # Use make W=1 to enable them (see scripts/Makefile.extrawarn)
-KBUILD_CFLAGS += $(call cc-disable-warning, unused-but-set-variable)
+KBUILD_CFLAGS += -Wno-unused-but-set-variable
 endif
 
 KBUILD_CFLAGS += $(call cc-disable-warning, unused-const-variable)
-- 
2.7.4

[PATCH 2/3] kbuild: add -Wdeclaration-after-statement flag unconditionally

[Masahiro Yamada]

We have raised the compiler requirement from time to time.
With commit cafa0010cd51 ("Raise the minimum required gcc version
to 4.6"), the minimum for GCC is 4.6 now.

This flag has been here since the pre-git era.  It is documented in
the GCC 4.6 manual, and it is recognized by Clang and ICC as well.

Let's rip off the cc-option switch, and see if somebody complains
about it.

Signed-off-by: Masahiro Yamada 
---

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

diff --git a/Makefile b/Makefile
index 505a324..8a23fee 100644
--- a/Makefile
+++ b/Makefile
@@ -797,7 +797,7 @@ endif
 NOSTDINC_FLAGS += -nostdinc -isystem $(shell $(CC) -print-file-name=include)
 
 # warn about C99 declaration after statement
-KBUILD_CFLAGS += $(call cc-option,-Wdeclaration-after-statement,)
+KBUILD_CFLAGS += -Wdeclaration-after-statement
 
 # disable pointer signed / unsigned warnings in gcc 4.0
 KBUILD_CFLAGS += -Wno-pointer-sign
-- 
2.7.4

[PATCH 1/3] kbuild: add -Wno-pointer-sign flag unconditionally

[Masahiro Yamada]

We have raised the compiler requirement from time to time.
With commit cafa0010cd51 ("Raise the minimum required gcc version
to 4.6"), the minimum for GCC is 4.6 now.

The -Wno-pointer-sign has been here since the pre-git era.  It is
documented in the GCC 4.6 manual, and it is recognized by Clang
and ICC as well.

Let's rip off the cc-disable-warning switch, and see if somebody
complains about it.

Signed-off-by: Masahiro Yamada 
---

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

diff --git a/Makefile b/Makefile
index c6d1f2f..505a324 100644
--- a/Makefile
+++ b/Makefile
@@ -800,7 +800,7 @@ NOSTDINC_FLAGS += -nostdinc -isystem $(shell $(CC) 
-print-file-name=include)
 KBUILD_CFLAGS += $(call cc-option,-Wdeclaration-after-statement,)
 
 # disable pointer signed / unsigned warnings in gcc 4.0
-KBUILD_CFLAGS += $(call cc-disable-warning, pointer-sign)
+KBUILD_CFLAGS += -Wno-pointer-sign
 
 # disable stringop warnings in gcc 8+
 KBUILD_CFLAGS += $(call cc-disable-warning, stringop-truncation)
-- 
2.7.4

Re: [PATCH 2/3] namei: implement AT_THIS_ROOT chroot-like path resolution

[Aleksa Sarai]

On 2018-09-29, Andy Lutomirski  wrote:
> >> On Sat, Sep 29, 2018 at 4:29 PM Aleksa Sarai  wrote:
> >> The primary motivation for the need for this flag is container runtimes
> >> which have to interact with malicious root filesystems in the host
> >> namespaces. One of the first requirements for a container runtime to be
> >> secure against a malicious rootfs is that they correctly scope symlinks
> >> (that is, they should be scoped as though they are chroot(2)ed into the
> >> container's rootfs) and ".."-style paths. The already-existing AT_XDEV
> >> and AT_NO_PROCLINKS help defend against other potential attacks in a
> >> malicious rootfs scenario.
> > 
> > So, I really like the concept for patch 1 of this series (but haven't
> > read the code yet); but I dislike this patch because of its footgun
> > potential.
> > 
> 
> The code could do it differently: do the path walk and then, before
> accepting the result, walk back up and make sure the result is under
> the starting point.
> 
> This is *not* a full solution, though, since a walk above the root gas
> side effects on timing, various caches, and possibly network traffic,
> so it’s open to Spectre-like attacks in which a malicious container
> could use a runtime-initiated AT_THIS_ROOT to infer the existence of
> directories outside the container.

I think that one way to solve this problem might be to have more strict
checks on nd->root in follow_dotdot(). The problem here (as far as I can
tell) is that ".." could end up skipping past the root because of a
rename, however walking *down* into a path shouldn't be a problem (even
absolute symlinks shouldn't be a problem because they will nd_jump_root
and will land back in the root).

However, I'm not entirely sure what happens to nd->root if it gets
renamed -- can you still safely do checks against it (we'd need to do
some sort of is_descendant() check on the current path before we handle
".." in follow_dotdot).

That way, we wouldn't shouldn't have the spectre-like attack problem
(since the attack would be halted at the ".." stage -- before the path
walk can proceed into host paths). Would this be sufficient or is there
a more serious issue I'm missing?

> But what’s the container usecase?  Any sane container is based on
> pivot_root or similar, so the runtime can just do the walk in the
> container context. IOW I’m a bit confused as to the exact intended use
> of the whole series. Can you elaborate?

I went into this in my response to Jann.

-- 
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH



signature.asc
Description: PGP signature

Re: [PATCH] mm/filemap.c: Use vmf_error()

[Jan Kara]

On Thu 27-09-18 22:44:12, Souptick Joarder wrote:
> These codes can be replaced with new inline vmf_error().
> 
> Signed-off-by: Souptick Joarder 

Looks good. You can add:

Reviewed-by: Jan Kara 

Honza

> ---
>  mm/filemap.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/mm/filemap.c b/mm/filemap.c
> index 52517f2..7d04d7c 100644
> --- a/mm/filemap.c
> +++ b/mm/filemap.c
> @@ -2581,9 +2581,7 @@ vm_fault_t filemap_fault(struct vm_fault *vmf)
>* system is low on memory, or a problem occurs while trying
>* to schedule I/O.
>*/
> - if (error == -ENOMEM)
> - return VM_FAULT_OOM;
> - return VM_FAULT_SIGBUS;
> + return vmf_error(error);
>  
>  page_not_uptodate:
>   /*
> -- 
> 1.9.1
> 
-- 
Jan Kara 
SUSE Labs, CR

Re: [LKP] [fsnotify] 60f7ed8c7c: will-it-scale.per_thread_ops -5.9% regression

[Amir Goldstein]

On Mon, Oct 1, 2018 at 12:32 PM Jan Kara  wrote:
>
> On Sun 30-09-18 12:00:46, Amir Goldstein wrote:
[...]
> > > commit:
> > >   1e6cb72399 ("fsnotify: add super block object type")
> > >   60f7ed8c7c ("fsnotify: send path type events to group with super block 
> > > marks")
> > >
> >
> > I have to admit this looks strange.
> > All this commit does is dereference mnt->mnt.mnt_sb and then
> > sb->s_fsnotify_mask/sb->s_fsnotify_marks to find that they are zero.
> > AFAICT there should be no extra contention added by this commit and it's
> > hard to believe that parallel unlink workload would suffer from this change.
>
> Well, it could be those additional fetches of
> sb->s_fsnotify_mask/sb->s_fsnotify_marks if they happen to be cache cold.
> Or it could be just code layout differences (i.e., compiler is not able to
> optimize resulting code as good or the code layout just happens to align
> with cache lines in a wrong way or something like that). Anyway, without
> being able to reproduce this and do detailed comparison of perf profiles I
> don't think we'll be able to tell.
>

Indeed, I am still trying to figure out how to run lkp in my test env.

Thanks,
Amir.

[RFC/PATCH] mm/shmem: add a NULL pointer test to shmem_free_inode

[miles.chen]

From: Miles Chen 

We noticed a kernel panic when unmounting tmpfs. It looks like a
race condition in the following scenario:

shmem_put_super() set sb->s_fs_info to NULL and shmem_evict_inode() tries
to access sb->s_fs_info right after the sb->s_fs_info becomes NULL.

CPU1CPU2

work_pendingwork_pending
do_notify_resumedo_notify_resume
fputtask_work_run
__fput  __cleanup_mnt
inotify_release cleanup_mnt
fsnotify_destroy_group  deactivate_super
fsnotify_detach_group_marks deactivate_locked_super
fsnotify_detach_markkill_litter_super /* sb->s_fs_info = NULL */
iput
evict /* use sb->s_fs_info */

Add a NULL pointer test in shmem_evict_inode(). We have stress-tested
the patch for 5 days with no panic.

Please note that this patch is a band-aid patch.

VFS: Busy inodes after unmount of tmpfs. Self-destruct in 5 seconds.
Have a nice day...
[name:traps&]Internal error: Accessing user space memory outside uaccess.h
routines:
[name:aee&]disable aee kernel api
[name:mrdump&]Kernel Offset: 0x132600 from 0xff800800
[name:mrdump&]Non-crashing CPUs did not react to IPI
CPU: 7 PID: 552 Comm: HwBinder:426_1 Tainted: GW  O4.9.117+ #2
Hardware name: MT6765 (DT)
task: ffc62d34 task.stack: ffc62d2b4000
PC is at shmem_evict_inode+0x150/0x19c
LR is at evict+0xa4/0x1f4
[] el1_da+0x24/0x40
[] evict+0xa4/0x1f4
[] iput+0x338/0x384
[] fsnotify_detach_mark+0xac/0xe0
[] fsnotify_detach_group_marks+0x78/0xdc
[] fsnotify_destroy_group+0x34/0x98
[] inotify_release+0x28/0x5c
[] __fput+0xcc/0x1c8
[] fput+0xc/0x14
[] task_work_run+0x88/0x11c
[] do_notify_resume+0x5c/0x165c
[] work_pending+0x8/0x14

If we put a BUG() after after "VFS: Busy inodes after unmount of tmpfs.
Self-destruct in 5 seconds.  Have a nice day...", we can get another
backtrace:
[] el1_dbg+0x18/0xb8
[] kill_litter_super+0x28/0x74
[] deactivate_locked_super+0x58/0x110
[] deactivate_super+0x6c/0x78
[] cleanup_mnt+0xb4/0x130
[] __cleanup_mnt+0x10/0x18
[] task_work_run+0x88/0x11c
[] do_notify_resume+0x5c/0x1664
[] work_pending+0x8/0x14

Signed-off-by: Miles Chen 
---
 mm/shmem.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/shmem.c b/mm/shmem.c
index 4469426..a50a2c8 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -257,7 +257,7 @@ static int shmem_reserve_inode(struct super_block *sb)
 static void shmem_free_inode(struct super_block *sb)
 {
struct shmem_sb_info *sbinfo = SHMEM_SB(sb);
-   if (sbinfo->max_inodes) {
+   if (sbinfo && sbinfo->max_inodes) {
spin_lock(&sbinfo->stat_lock);
sbinfo->free_inodes++;
spin_unlock(&sbinfo->stat_lock);
-- 
1.9.1

[PATCH] soc: qcom: Drop help text for QCOM_QMI_HELPERS

[Niklas Cassel]

The help text is visible in menuconfig, however QCOM_QMI_HELPERS is a
hidden kconfig, so it is not selectable in menuconfig.

Remove the help text so that it is more clear that this is intentionally
a hidden kconfig.

Signed-off-by: Niklas Cassel 
---
 drivers/soc/qcom/Kconfig | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
index 684cb51694d1..fcbf8a2e4080 100644
--- a/drivers/soc/qcom/Kconfig
+++ b/drivers/soc/qcom/Kconfig
@@ -75,11 +75,6 @@ config QCOM_QMI_HELPERS
tristate
depends on ARCH_QCOM || COMPILE_TEST
depends on NET
-   help
- Helper library for handling QMI encoded messages.  QMI encoded
- messages are used in communication between the majority of QRTR
- clients and this helpers provide the common functionality needed for
- doing this from a kernel driver.
 
 config QCOM_RMTFS_MEM
tristate "Qualcomm Remote Filesystem memory driver"
-- 
2.17.1

[PATCH] cpuidle: menu: Replace data->predicted_us with local variable

[Rafael J. Wysocki]

From: Rafael J. Wysocki 

The predicted_us field in struct menu_device is only accessed in
menu_select(), so replace it with a local variable in that function.

With that, stop using expected_interval instead of predicted_us to
store the new predicted idle duration value if it is set to the
selected state's target residency which is quite confusing.

Signed-off-by: Rafael J. Wysocki 
---
 drivers/cpuidle/governors/menu.c |   23 +++
 1 file changed, 11 insertions(+), 12 deletions(-)

Index: linux-pm/drivers/cpuidle/governors/menu.c
===
--- linux-pm.orig/drivers/cpuidle/governors/menu.c
+++ linux-pm/drivers/cpuidle/governors/menu.c
@@ -124,7 +124,6 @@ struct menu_device {
int tick_wakeup;
 
unsigned intnext_timer_us;
-   unsigned intpredicted_us;
unsigned intbucket;
unsigned intcorrection_factor[BUCKETS];
unsigned intintervals[INTERVALS];
@@ -290,6 +289,7 @@ static int menu_select(struct cpuidle_dr
int idx;
unsigned int interactivity_req;
unsigned int expected_interval;
+   unsigned int predicted_us;
unsigned long nr_iowaiters, cpu_load;
ktime_t delta_next;
 
@@ -315,7 +315,7 @@ static int menu_select(struct cpuidle_dr
 * operands are 32 bits.
 * Make sure to round up for half microseconds.
 */
-   data->predicted_us = 
DIV_ROUND_CLOSEST_ULL((uint64_t)data->next_timer_us *
+   predicted_us = DIV_ROUND_CLOSEST_ULL((uint64_t)data->next_timer_us *
 data->correction_factor[data->bucket],
 RESOLUTION * DECAY);
 
@@ -341,7 +341,7 @@ static int menu_select(struct cpuidle_dr
/*
 * Use the lowest expected idle interval to pick the idle state.
 */
-   data->predicted_us = min(data->predicted_us, expected_interval);
+   predicted_us = min(predicted_us, expected_interval);
 
if (tick_nohz_tick_stopped()) {
/*
@@ -352,19 +352,18 @@ static int menu_select(struct cpuidle_dr
 * the known time till the closest timer event for the idle
 * state selection.
 */
-   if (data->predicted_us < TICK_USEC)
-   data->predicted_us = ktime_to_us(delta_next);
+   if (predicted_us < TICK_USEC)
+   predicted_us = ktime_to_us(delta_next);
} else {
/*
 * Use the performance multiplier and the user-configurable
 * latency_req to determine the maximum exit latency.
 */
-   interactivity_req = data->predicted_us / 
performance_multiplier(nr_iowaiters, cpu_load);
+   interactivity_req = predicted_us / 
performance_multiplier(nr_iowaiters, cpu_load);
if (latency_req > interactivity_req)
latency_req = interactivity_req;
}
 
-   expected_interval = data->predicted_us;
/*
 * Find the idle state with the lowest power while satisfying
 * our constraints.
@@ -378,8 +377,8 @@ static int menu_select(struct cpuidle_dr
continue;
if (idx == -1)
idx = i; /* first enabled state */
-   if (s->target_residency > data->predicted_us) {
-   if (data->predicted_us < TICK_USEC)
+   if (s->target_residency > predicted_us) {
+   if (predicted_us < TICK_USEC)
break;
 
if (!tick_nohz_tick_stopped()) {
@@ -389,7 +388,7 @@ static int menu_select(struct cpuidle_dr
 * tick in that case and let the governor run
 * again in the next iteration of the loop.
 */
-   expected_interval = 
drv->states[idx].target_residency;
+   predicted_us = 
drv->states[idx].target_residency;
break;
}
 
@@ -412,7 +411,7 @@ static int menu_select(struct cpuidle_dr
 * expected idle duration so that the tick is retained
 * as long as that target residency is low enough.
 */
-   expected_interval = drv->states[idx].target_residency;
+   predicted_us = drv->states[idx].target_residency;
break;
}
idx = i;
@@ -426,7 +425,7 @@ static int menu_select(struct cpuidle_dr
 * expected idle duration is shorter than the tick period length.
 */
if (((drv->states[idx].flags & CPUIDLE_FLAG_POLLING) ||
-expected_interval < TICK_USEC) && !tick_nohz_tick_stopped()) {
+predicted_

[PATCH net-next] net: mscc: allow extracting the FCS into the skb

[Antoine Tenart]

This patch adds support for the NETIF_F_RXFCS feature in the Mscc
Ethernet driver. This feature is disabled by default and allow an user
to request the driver not to drop the FCS and to extract it into the skb
for debugging purposes.

Signed-off-by: Antoine Tenart 
---
 drivers/net/ethernet/mscc/ocelot.c   | 2 +-
 drivers/net/ethernet/mscc/ocelot_board.c | 7 ++-
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/mscc/ocelot.c 
b/drivers/net/ethernet/mscc/ocelot.c
index 1a4f2bb48ead..eb5119e7e60b 100644
--- a/drivers/net/ethernet/mscc/ocelot.c
+++ b/drivers/net/ethernet/mscc/ocelot.c
@@ -1606,7 +1606,7 @@ int ocelot_probe_port(struct ocelot *ocelot, u8 port,
dev->ethtool_ops = &ocelot_ethtool_ops;
dev->switchdev_ops = &ocelot_port_switchdev_ops;
 
-   dev->hw_features |= NETIF_F_HW_VLAN_CTAG_FILTER;
+   dev->hw_features |= NETIF_F_HW_VLAN_CTAG_FILTER | NETIF_F_RXFCS;
dev->features |= NETIF_F_HW_VLAN_CTAG_FILTER;
 
memcpy(dev->dev_addr, ocelot->base_mac, ETH_ALEN);
diff --git a/drivers/net/ethernet/mscc/ocelot_board.c 
b/drivers/net/ethernet/mscc/ocelot_board.c
index 3cdf63e35b53..245452a0f244 100644
--- a/drivers/net/ethernet/mscc/ocelot_board.c
+++ b/drivers/net/ethernet/mscc/ocelot_board.c
@@ -126,11 +126,16 @@ static irqreturn_t ocelot_xtr_irq_handler(int irq, void 
*arg)
len += sz;
} while (len < buf_len);
 
-   /* Read the FCS and discard it */
+   /* Read the FCS */
sz = ocelot_rx_frame_word(ocelot, grp, false, &val);
/* Update the statistics if part of the FCS was read before */
len -= ETH_FCS_LEN - sz;
 
+   if (unlikely(dev->features & NETIF_F_RXFCS)) {
+   buf = (u32 *)skb_put(skb, ETH_FCS_LEN);
+   *buf = val;
+   }
+
if (sz < 0) {
err = sz;
break;
-- 
2.17.1

Re: [PATCH v2 6/8] mtd: maps: gpio-addr-flash: Split allocation in two

[Ricardo Ribalda Delgado]

Hi Boris

PLEASE do not apply this one!

There is a bug, value from gpio->addr is lost.
On Wed, Sep 5, 2018 at 4:37 PM Ricardo Ribalda Delgado
 wrote:
>
> Instead of making one allocation and then calculating the addresses of
> those two pointers in that area make two allocations. This simplifies
> the code.
>
> Signed-off-by: Ricardo Ribalda Delgado 
> ---
>  drivers/mtd/maps/gpio-addr-flash.c | 12 
>  1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/mtd/maps/gpio-addr-flash.c 
> b/drivers/mtd/maps/gpio-addr-flash.c
> index 8f5e3dce9be3..9455a8448064 100644
> --- a/drivers/mtd/maps/gpio-addr-flash.c
> +++ b/drivers/mtd/maps/gpio-addr-flash.c
> @@ -205,7 +205,7 @@ static const char * const part_probe_types[] = {
>   */
>  static int gpio_flash_probe(struct platform_device *pdev)
>  {
> -   size_t i, arr_size;
> +   size_t i;
> struct physmap_flash_data *pdata;
> struct resource *memory;
> struct resource *gpios;
> @@ -218,8 +218,7 @@ static int gpio_flash_probe(struct platform_device *pdev)
> if (!memory || !gpios || !gpios->end)
> return -EINVAL;
>
> -   arr_size = sizeof(state->gpio_addrs[0]) * gpios->end;
> -   state = devm_kzalloc(&pdev->dev, sizeof(*state) + arr_size, 
> GFP_KERNEL);
> +   state = devm_kzalloc(&pdev->dev, sizeof(*state), GFP_KERNEL);
> if (!state)
> return -ENOMEM;
>
> @@ -228,7 +227,12 @@ static int gpio_flash_probe(struct platform_device *pdev)
>  * away their pointer types here to the known types (gpios->xxx).
>  */
> state->gpio_count = gpios->end;
> -   state->gpio_addrs = (void *)(unsigned long)gpios->start;
> +   state->gpio_addrs = devm_kzalloc(&pdev->dev,
> +sizeof(state->gpio_addrs[0]) *
> +   gpios->end,
> +GFP_KERNEL);
> +   if (!state->gpio_addrs)
> +   return -ENOMEM;
> state->win_order  = get_bitmask_order(resource_size(memory)) - 1;
>
> state->map.name   = DRIVER_NAME;
> --
> 2.18.0
>


-- 
Ricardo Ribalda

[PATCH 2/2] genirq/debugfs: Reinstate full OF path for domain name

[Marc Zyngier]

On a DT based system, we use the of_node full name to name the
corresponding irq domain. We expect that name to be unique, so
so that domains with the same base name won't clash (this
happens on multi-node topologies, for example).

Since a7e4cfb0a7ca ("of/fdt: only store the device node basename
in full_name"), of_node_full_name() lies and only returns the
basename. This breaks the above requirement, and we end-up with
only a subset of the domains in /sys/kernel/debug/irq/domains.

Let's reinstate the feature by using the fancy new %pOF format
specifier, which happens to do the right thing.

Fixes: a7e4cfb0a7ca ("of/fdt: only store the device node basename in full_name")
Signed-off-by: Marc Zyngier 
---
 kernel/irq/irqdomain.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index 95a0acbdd4e6..3b30a4aeb0db 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -183,7 +183,7 @@ struct irq_domain *__irq_domain_add(struct fwnode_handle 
*fwnode, int size,
 * unhappy about. Replace them with ':', which does
 * the trick and is not as offensive as '\'...
 */
-   name = kstrdup(of_node_full_name(of_node), GFP_KERNEL);
+   name = kasprintf(GFP_KERNEL, "%pOF", of_node);
if (!name) {
kfree(domain);
return NULL;
-- 
2.19.0

[PATCH 0/2] irqdomain debufs fixes for 4.20

[Marc Zyngier]

Here's a couple of fixes for the irqdomain debugfs feature that I
wrote while working on some unrelated irqchip over the weekend.

If nobody screams, I'll queue them for 4.20.

Thanks,

M.

Marc Zyngier (2):
  genirq/debugfs: Reset domain debugfs_file on removal of the debugfs
file
  genirq/debugfs: Reinstate full OF path for domain name

 kernel/irq/irqdomain.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

-- 
2.19.0

[PATCH 1/2] genirq/debugfs: Reset domain debugfs_file on removal of the debugfs file

[Marc Zyngier]

When removing a debugfs file for a given irq domain, we fail
to clear the corresponding field, meaning that the corresponding
domain won't be created again if we need to do so.

It turns out that this is exactly what irq_domain_update_bus_token
does (delete old file, update domain name, recreate file).

This doesn't have any impact other than making debug more
difficult, but we do value ease of debugging... So let's
clear the debugfs_file field.

Signed-off-by: Marc Zyngier 
---
 kernel/irq/irqdomain.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index 5d9fc01b60a6..95a0acbdd4e6 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -1741,6 +1741,7 @@ static void debugfs_add_domain_dir(struct irq_domain *d)
 static void debugfs_remove_domain_dir(struct irq_domain *d)
 {
debugfs_remove(d->debugfs_file);
+   d->debugfs_file = NULL;
 }
 
 void __init irq_domain_debugfs_init(struct dentry *root)
-- 
2.19.0

[PATCH 1/2] mm, numa: Remove rate-limiting of automatic numa balancing migration

[Mel Gorman]

Rate limiting of page migrations due to automatic NUMA balancing was
introduced to mitigate the worst-case scenario of migrating at high
frequency due to false sharing or slowly ping-ponging between nodes.
Since then, a lot of effort was spent on correctly identifying these
pages and avoiding unnecessary migrations and the safety net may no longer
be required.

Jirka Hladky reported a regression in 4.17 due to a scheduler patch that
avoids spreading STREAM tasks wide prematurely. However, once the task
was properly placed, it delayed migrating the memory due to rate limiting.
Increasing the limit fixed the problem for him.

Currently, the limit is hard-coded and does not account for the real
capabilities of the hardware. Even if an estimate was attempted, it would
not properly account for the number of memory controllers and it could
not account for the amount of bandwidth used for normal accesses. Rather
than fudging, this patch simply eliminates the rate limiting.

However, Jirka reports that a STREAM configuration using multiple
processes achieved similar performance to 4.16. In local tests, this patch
improved performance of STREAM relative to the baseline but it is somewhat
machine-dependent. Most workloads show little or not performance difference
implying that there is not a heavily reliance on the throttling mechanism
and it is safe to remove.

STREAM on 2-socket machine
 4.19.0-rc5 4.19.0-rc5
 numab-v1r1   noratelimit-v1r1
MB/sec copy 43298.52 (   0.00%)44673.38 (   3.18%)
MB/sec scale30115.06 (   0.00%)31293.06 (   3.91%)
MB/sec add  32825.12 (   0.00%)34883.62 (   6.27%)
MB/sec triad32549.52 (   0.00%)34906.60 (   7.24%

Signed-off-by: Mel Gorman 
---
 include/linux/mmzone.h |  6 
 include/trace/events/migrate.h | 27 --
 mm/migrate.c   | 65 --
 mm/page_alloc.c|  2 --
 4 files changed, 100 deletions(-)

diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 1e22d96734e0..3f4c0b167333 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -671,12 +671,6 @@ typedef struct pglist_data {
 #ifdef CONFIG_NUMA_BALANCING
/* Lock serializing the migrate rate limiting window */
spinlock_t numabalancing_migrate_lock;
-
-   /* Rate limiting time interval */
-   unsigned long numabalancing_migrate_next_window;
-
-   /* Number of pages migrated during the rate limiting time interval */
-   unsigned long numabalancing_migrate_nr_pages;
 #endif
/*
 * This is a per-node reserve of pages that are not available
diff --git a/include/trace/events/migrate.h b/include/trace/events/migrate.h
index 711372845945..705b33d1e395 100644
--- a/include/trace/events/migrate.h
+++ b/include/trace/events/migrate.h
@@ -70,33 +70,6 @@ TRACE_EVENT(mm_migrate_pages,
__print_symbolic(__entry->mode, MIGRATE_MODE),
__print_symbolic(__entry->reason, MIGRATE_REASON))
 );
-
-TRACE_EVENT(mm_numa_migrate_ratelimit,
-
-   TP_PROTO(struct task_struct *p, int dst_nid, unsigned long nr_pages),
-
-   TP_ARGS(p, dst_nid, nr_pages),
-
-   TP_STRUCT__entry(
-   __array(char,   comm,   TASK_COMM_LEN)
-   __field(pid_t,  pid)
-   __field(int,dst_nid)
-   __field(unsigned long,  nr_pages)
-   ),
-
-   TP_fast_assign(
-   memcpy(__entry->comm, p->comm, TASK_COMM_LEN);
-   __entry->pid= p->pid;
-   __entry->dst_nid= dst_nid;
-   __entry->nr_pages   = nr_pages;
-   ),
-
-   TP_printk("comm=%s pid=%d dst_nid=%d nr_pages=%lu",
-   __entry->comm,
-   __entry->pid,
-   __entry->dst_nid,
-   __entry->nr_pages)
-);
 #endif /* _TRACE_MIGRATE_H */
 
 /* This part must be outside protection */
diff --git a/mm/migrate.c b/mm/migrate.c
index 4f1d894835b5..5e285c1249a0 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -1855,54 +1855,6 @@ static struct page *alloc_misplaced_dst_page(struct page 
*page,
return newpage;
 }
 
-/*
- * page migration rate limiting control.
- * Do not migrate more than @pages_to_migrate in a @migrate_interval_millisecs
- * window of time. Default here says do not migrate more than 1280M per second.
- */
-static unsigned int migrate_interval_millisecs __read_mostly = 100;
-static unsigned int ratelimit_pages __read_mostly = 128 << (20 - PAGE_SHIFT);
-
-/* Returns true if the node is migrate rate-limited after the update */
-static bool numamigrate_update_ratelimit(pg_data_t *pgdat,
-   unsigned long nr_pages)
-{
-   unsigned long next_window, interval;
-
-   next_window = READ_ONCE(pgdat->numabalancing_migrate_next_window);
-   interval = msec

[PATCH 0/2] Faster migration for automatic NUMA balancing

[Mel Gorman]

These two patches are based on top of Srikar Dronamraju's recent work
on automatic NUMA balancing and are motivated by a bug report from Jirka
Hladky that STREAM performance has regressed.

The STREAM workload is mildly interesting in that it only works as a valid
benchmark if tasks are pinned to memory channels. Otherwise it is very
sensitive to the starting conditions of the benchmark. Recent scheduler
changes prevent prematurely spreading a workload across multiple sockets
which benefits many workloads but not STREAM. This series restores STREAM
performance without reintroducing other regressions.

The first patch removes migration rate limiting as it's expected that
automatic NUMA balancing decisions are mature enough that we do not
need the safety net. The second patch migrates pages faster early in the
lifetime of the process which has an impact if the load balancer spreads
a workload to remote nodes.

 include/linux/mmzone.h |  6 
 include/trace/events/migrate.h | 27 --
 kernel/sched/fair.c| 12 +++-
 mm/migrate.c   | 65 --
 mm/page_alloc.c|  2 --
 5 files changed, 11 insertions(+), 101 deletions(-)

-- 
2.16.4

[PATCH 2/2] mm, numa: Migrate pages to local nodes quicker early in the lifetime of a task

[Mel Gorman]

Automatic NUMA Balancing uses a multi-stage pass to decide whether a page
should migrate to a local node. This filter avoids excessive ping-ponging
if a page is shared or used by threads that migrate cross-node frequently.

Threads inherit both page tables and the preferred node ID from the
parent. This means that threads can trigger hinting faults earlier than
a new task which delays scanning for a number of seconds. As it can be
load balanced very early in its lifetime there can be an unnecessary delay
before it starts migrating thread-local data. This patch migrates private
pages faster early in the lifetime of a thread using the sequence counter
as an identifier of new tasks.

With this patch applied, STREAM performance is the same as 4.17 even though
processes are not spread cross-node prematurely. Other workloads showed
a mix of minor gains and losses. This is somewhat expected most workloads
are not very sensitive to the starting conditions of a process.

 4.19.0-rc5 4.19.0-rc5 
4.17.0
 numab-v1r1   fastmigrate-v1r1
vanilla
MB/sec copy 43298.52 (   0.00%)47335.46 (   9.32%)47219.24 (   
9.06%)
MB/sec scale30115.06 (   0.00%)32568.12 (   8.15%)32527.56 (   
8.01%)
MB/sec add  32825.12 (   0.00%)36078.94 (   9.91%)35928.02 (   
9.45%)
MB/sec triad32549.52 (   0.00%)35935.94 (  10.40%)35969.88 (  
10.51%)

Signed-off-by: Mel Gorman 
---
 kernel/sched/fair.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 25c7c7e09cbd..7fc4a371bdd2 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -1392,6 +1392,17 @@ bool should_numa_migrate_memory(struct task_struct *p, 
struct page * page,
int last_cpupid, this_cpupid;
 
this_cpupid = cpu_pid_to_cpupid(dst_cpu, current->pid);
+   last_cpupid = page_cpupid_xchg_last(page, this_cpupid);
+
+   /*
+* Allow first faults or private faults to migrate immediately early in
+* the lifetime of a task. The magic number 4 is based on waiting for
+* two full passes of the "multi-stage node selection" test that is
+* executed below.
+*/
+   if ((p->numa_preferred_nid == -1 || p->numa_scan_seq <= 4) &&
+   (cpupid_pid_unset(last_cpupid) || cpupid_match_pid(p, last_cpupid)))
+   return true;
 
/*
 * Multi-stage node selection is used in conjunction with a periodic
@@ -1410,7 +1421,6 @@ bool should_numa_migrate_memory(struct task_struct *p, 
struct page * page,
 * This quadric squishes small probabilities, making it less likely we
 * act on an unlikely task<->page relation.
 */
-   last_cpupid = page_cpupid_xchg_last(page, this_cpupid);
if (!cpupid_pid_unset(last_cpupid) &&
cpupid_to_nid(last_cpupid) != dst_nid)
return false;
-- 
2.16.4

Re: [PATCH v2 2/2] PCI: controller: dwc: add UniPhier PCIe host controller support

[Lorenzo Pieralisi]

On Fri, Sep 28, 2018 at 02:17:16PM +0100, Marc Zyngier wrote:
> On 28/09/18 12:06, Lorenzo Pieralisi wrote:
> >[+Murali, Marc]
> >
> >On Thu, Sep 27, 2018 at 04:44:26PM +0900, Kunihiko Hayashi wrote:
> >>Hi Lorenzo, Gustavo,
> >>
> >>On Wed, 26 Sep 2018 21:31:36 +0900  wrote:
> >>
> >>>Hi Lorenzo, Gustavo,
> >>>
> >>>Thank you for reviewing.
> >>>
> >>>On Tue, 25 Sep 2018 18:53:01 +0100
> >>>Gustavo Pimentel  wrote:
> >>>
> On 25/09/2018 17:14, Lorenzo Pieralisi wrote:
> >[+Gustavo, please have a look at INTX/MSI management]
> >
> >On Thu, Sep 06, 2018 at 06:40:32PM +0900, Kunihiko Hayashi wrote:
> >>This introduces specific glue layer for UniPhier platform to support
> >>PCIe host controller that is based on the DesignWare PCIe core, and
> >>this driver supports Root Complex (host) mode.
> >
> >Please read this thread and apply it to next versions:
> >
> >https://urldefense.proofpoint.com/v2/url?u=https-3A__marc.info_-3Fl-3Dlinux-2Dpci-26m-3D150905742808166-26w-3D2&d=DwIBAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=bkWxpLoW-f-E3EdiDCCa0_h0PicsViasSlvIpzZvPxs&m=H8UNDDUGQnQnqfWr4CBios689dJcjxu4qeTTRGulLmU&s=CgcXc_2LThyOpW-4bCriJNo9H1lzROEdy_cG9p-Y5hU&e=
> >>>
> >>>I also found this thread in previous linux-pci, and I think it's helpful 
> >>>for me.
> >>>I'll check it carefully.
> >>
> >>[snip]
> >>
> >>+   ret = devm_request_irq(dev, pp->irq, uniphier_pcie_irq_handler,
> >>+  IRQF_SHARED, "pcie", priv);
> >
> >This is wrong, you should set-up a chained IRQ for INTX.
> >
> >I *think* that
> >
> >ks_pcie_setup_interrupts()
> >
> >is a good example to start with but I wonder whether it is worth
> >generalizing the INTX approach to designware as a whole as it was
> >done for MSIs.
> >
> >Thoughts ?
> 
>  From what I understood this is for legacy IRQ, right?
> >>>
> >>>Yes. For legacy IRQ.
> >>>
> Like you (Lorenzo) said there is 2 drivers (pci-keystone-dw.c and 
> pci-dra7xx.c)
> that uses it and can be use as a template for handling this type of 
> interrupts.
> 
> We can try to pass some kind of generic INTX function to the DesignWare 
> host
> library to handling this, but this will require some help from keystone 
> and
> dra7xx maintainers, since my setup doesn't have legacy IRQ HW support.
> >>>
> >>>Now I think it's difficult to make a template for INTX function,
> >>>and at first, I'll try to re-write this part with reference to 
> >>>pci-keystone-dw.c.
> >>
> >>I understand that there are 2 types of interrupt and the drivers.
> >>
> >>One like pci-keystone-dw.c is:
> >>
> >>  - there are 4 interrupts for legacy,
> >>  - invoke handlers for each interrupt, and handle the interrupt,
> >>  - call irq_set_chained_handler_and_data() to make a chain of the 
> >> interrupts
> >>   when initializing
> >>
> >>The other like pci-dra7xx.c is:
> >>
> >>  - there is 1 IRQ for legacy as a parent,
> >>  - check an interrupt factor register, and handle the interrupt correspond
> >>to the factor,
> >>  - call request_irq() for the parent IRQ and irq_domain_add_linear() for
> >>the factor when initializing
> >>
> >>The pcie-uniphier.c is the same type as the latter (like pci-dra7xx.c).
> >>
> >>However, in pci-dra7xx.c, MSI and legacy IRQ share the same interrupt 
> >>number,
> >>so the same handler is called and the handler divides these IRQs.
> >>(found in dra7xx_pcie_msi_irq_handler())
> >>
> >>In pcie-uniphier.c, MSI and legacy IRQ are independent.
> >>Therefore it's necessary to prepare the handler for the legacy IRQ.
> >>
> >>I think that it's difficult to apply the way of pci-keystone-dw.c, and
> >>uniphier_pcie_irq_handler() and calling devm_request_irq() are still
> >>necessary to handle legacy IRQ.
> >
> >I do not think it is difficult, the difference is that keystone has
> >1 GIC irq line allocated per legacy IRQ, your set-up has one for
> >all INTX.
> >
> >*However*, I would like some clarifications from Murali on this code
> >in drivers/pci/controller/dwc/pci-keystone.c:
> >
> >static void ks_pcie_legacy_irq_handler(struct irq_desc *desc)
> >{
> > unsigned int irq = irq_desc_get_irq(desc);
> > struct keystone_pcie *ks_pcie = irq_desc_get_handler_data(desc);
> > struct dw_pcie *pci = ks_pcie->pci;
> > struct device *dev = pci->dev;
> > u32 irq_offset = irq - ks_pcie->legacy_host_irqs[0];
> >
> >Here the IRQ numbers are virtual IRQs, is it correct to consider
> >the virq numbers as sequential values ? The "offset" is used to
> >handle the PCI controller interrupt registers, so it must be a value
> >between 0-3 IIUC.
> 
> There is absolutely no reason why virtual interrupt numbers should be
> contiguous. Shake the allocator hard enough, and you'll see gaps appearing.
> 
> In general, the only thing that makes sense is to compute this offset based
> on the hwirq which is HW-specific.

More to it, AFAIK the list of HW irq

[PATCH] arm_pmu: Delete incorrect cache event mapping for some armv8_pmuv3 events.

[Kulkarni, Ganapatrao]

Perf events L1-dcache-load-misses, L1-dcache-store-misses are mapped to
armv8_pmuv3 (both DT and ACPI) event L1D_CACHE_REFILL. This is incorrect,
since L1D_CACHE_REFILL counts both load and store misses.
Similarly the events L1-dcache-loads, L1-dcache-stores, dTLB-load-misses
and dTLB-loads are wrongly mapped. Hence Deleting all these cache events
from armv8_pmuv3 cache mapping.

Signed-off-by: Ganapatrao Kulkarni 
---
 arch/arm64/kernel/perf_event.c | 8 
 1 file changed, 8 deletions(-)

diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
index 33147aacdafd..6a67ad22d1eb 100644
--- a/arch/arm64/kernel/perf_event.c
+++ b/arch/arm64/kernel/perf_event.c
@@ -207,17 +207,9 @@ static const unsigned 
armv8_pmuv3_perf_cache_map[PERF_COUNT_HW_CACHE_MAX]

[PERF_COUNT_HW_CACHE_RESULT_MAX] = {
PERF_CACHE_MAP_ALL_UNSUPPORTED,
 
-   [C(L1D)][C(OP_READ)][C(RESULT_ACCESS)]  = ARMV8_PMUV3_PERFCTR_L1D_CACHE,
-   [C(L1D)][C(OP_READ)][C(RESULT_MISS)]= 
ARMV8_PMUV3_PERFCTR_L1D_CACHE_REFILL,
-   [C(L1D)][C(OP_WRITE)][C(RESULT_ACCESS)] = ARMV8_PMUV3_PERFCTR_L1D_CACHE,
-   [C(L1D)][C(OP_WRITE)][C(RESULT_MISS)]   = 
ARMV8_PMUV3_PERFCTR_L1D_CACHE_REFILL,
-
[C(L1I)][C(OP_READ)][C(RESULT_ACCESS)]  = ARMV8_PMUV3_PERFCTR_L1I_CACHE,
[C(L1I)][C(OP_READ)][C(RESULT_MISS)]= 
ARMV8_PMUV3_PERFCTR_L1I_CACHE_REFILL,
 
-   [C(DTLB)][C(OP_READ)][C(RESULT_MISS)]   = 
ARMV8_PMUV3_PERFCTR_L1D_TLB_REFILL,
-   [C(DTLB)][C(OP_READ)][C(RESULT_ACCESS)] = ARMV8_PMUV3_PERFCTR_L1D_TLB,
-
[C(ITLB)][C(OP_READ)][C(RESULT_MISS)]   = 
ARMV8_PMUV3_PERFCTR_L1I_TLB_REFILL,
[C(ITLB)][C(OP_READ)][C(RESULT_ACCESS)] = ARMV8_PMUV3_PERFCTR_L1I_TLB,
 
-- 
2.18.0

Re: [PATCH] zram: fix missing zero pages for memory tracking

[Sergey Senozhatsky]

On (09/22/18 12:11), Minchan Kim wrote:
> On Wed, Sep 19, 2018 at 04:29:16PM +0900, Sergey Senozhatsky wrote:
> > On (09/19/18 14:18), Minchan Kim wrote:
> > > We need to count zero filled pages as well as other pages in zram.
> > 
> > A nit,
> > 
> > 'ZRAM_FLAG_SHIFT + 1' covers all ZRAM_SAME pages, not only
> > zero filled pages.
> 
> I was brainfart.

No, never :) And I totally didn't mean it.

-ss

[PATCH] slimbus: ngd: QCOM_QMI_HELPERS has to be selected

[Niklas Cassel]

QCOM_QMI_HELPERS is a hidden kconfig, so the proper usage is
to select it, not depend upon it.

Signed-off-by: Niklas Cassel 
---
 drivers/slimbus/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/slimbus/Kconfig b/drivers/slimbus/Kconfig
index 9d73ad806698..9cca2c3559f2 100644
--- a/drivers/slimbus/Kconfig
+++ b/drivers/slimbus/Kconfig
@@ -22,8 +22,8 @@ config SLIM_QCOM_CTRL
 
 config SLIM_QCOM_NGD_CTRL
tristate "Qualcomm SLIMbus Satellite Non-Generic Device Component"
-   depends on QCOM_QMI_HELPERS
depends on HAS_IOMEM && DMA_ENGINE
+   select QCOM_QMI_HELPERS
help
  Select driver if Qualcomm's SLIMbus Satellite Non-Generic Device
  Component is programmed using Linux kernel.
-- 
2.17.1

Re: [PATCH 2/3] namei: implement AT_THIS_ROOT chroot-like path resolution

[Jann Horn]

On Mon, Oct 1, 2018 at 7:44 AM Aleksa Sarai  wrote:
> On 2018-09-29, Jann Horn  wrote:
> > The problem is what happens if a folder you are walking through is
> > concurrently moved out of the chroot. Consider the following scenario:
> >
> > You attempt to open "C/../../etc/passwd" under the root "/A/B".
> > Something else concurrently moves /A/B/C to /A/C. This can result in
> > the following:
> >
> > 1. You start the path walk and reach /A/B/C.
> > 2. The other process moves /A/B/C to /A/C. Your path walk is now at /A/C.
> > 3. Your path walk follows the first ".." up into /A. This is outside
> > the process root, but you never actually encountered the process root,
> > so you don't notice.
> > 4. Your path walk follows the second ".." up to /. Again, this is
> > outside the process root, but you don't notice.
> > 5. Your path walk walks down to /etc/passwd, and the open completes
> > successfully. You now have an fd pointing outside your chroot.
> >
> > If the root of your walk is below an attacker-controlled directory,
> > this of course means that you lose instantly. If you point the root of
> > the walk at a directory out of which a process in the container
> > wouldn't be able to move the file, you're probably kinda mostly fine -
> > as long as you know, for certain, that nothing else on the system
> > would ever do that. But I still wouldn't feel good about that.
>
> Please correct me if I'm wrong here (this is the first patch I've
> written for VFS). Isn't the retry/LOOKUP_REVAL code meant to handle this
> -- or does that only handle if a particular path component changes
> *while* it's being walked through?

Eric Biederman should be able to talk about all this much better than
me, but as far as I know, the LOOKUP_REVAL path is only for dealing
with some special filesystems like procfs.

> Is it possible for a path walk to
> succeed after a path component was unmounted (obviously you can't delete
> a directory path component since you'd get -ENOTEMPTY)?

I don't think so, but I'm not exactly a VFS expert.

> If this is an issue for AT_THIS_ROOT, I believe this might also be an
> issue for AT_BENEATH since they are effectively both using the same
> nd->root trick (so you could similarly trick AT_BENEATH to not error
> out). So we'd need to figure out how to solve this problem in order for
> AT_BENEATH to be safe.

Oh, wait, what? I think I didn't notice that the semantics of
AT_BENEATH changed like that since the original posting of David
Drysdale's O_BENEATH_ONLY patch
(https://lore.kernel.org/lkml/1439458366-8223-2-git-send-email-drysd...@google.com/).
David's patch had nice, straightforward semantics, blocking any form
of upwards traversal. Why was that changed? Does anyone actually want
to use paths that contain ".." with AT_BENEATH? I would strongly
prefer something that blocks any use of "..".

@Al: It looks like this already changed back when you posted
https://lore.kernel.org/lkml/20170429220414.gt29...@zeniv.linux.org.uk/
?

> Speaking naively, doesn't it make sense to invalidate the walk if a path
> component was modified? Or is this something that would be far too
> costly with little benefit? What if we do more aggressive nd->root
> checks when resolving with AT_BENEATH or AT_THIS_ROOT (or if nd->root !=
> current->mnt_ns->root)?

It seems to me like doing that would basically require looking at each
node in the path walk twice? And it'd be difficult to guarantee
forward progress unless you're willing to do some fairly heavy
locking.

> Regarding chroot attacks, I was aware of the trivial
> chroot-open-chroot-fchdir attack but I was not aware that there was a
> rename attack for chroot. Thanks for bringing this up!
>
> > I believe that the only way to robustly use this would be to point the
> > dirfd at a mount point, such that you know that being moved out of the
> > chroot is impossible because the mount point limits movement of
> > directories under it. (Well, technically, it doesn't, but it ensures
> > that if a directory does dangerously move away, the syscall fails.) It
> > might make sense to hardcode this constraint in the implementation of
> > AT_THIS_ROOT, to keep people from shooting themselves in the foot.
>
> Unless I'm missing something, would this not also affect using a
> mountpoint as a dirfd-root (with MS_MOVE of an already-walked-through
> path component) -- or does MS_MOVE cause a rewalk in a way that rename
> does not?

Hmm. Good point.

It looks to me like you probably wouldn't be able to walk up through a
mountpoint in RCU mode after the mount hierarchy has changed (see
follow_dotdot_rcu()), but it might work in refwalk mode.

Eric?

> I wouldn't mind tying AT_THIS_ROOT to only work on mountpoints (I
> thought that bind-mounts would be an issue but you also get -EXDEV when
> trying to rename across bind-mounts even if they are on the same
> underlying filesystem). But AT_BENEATH might be a more bitter pill to
> swallow. I'm not sure.

Which is part of why I strongl

[GIT PULL] extcon next for v4.20

[Chanwoo Choi]

Dear Greg,

This is extcon-next pull request for v4.20. I add detailed description of
this pull request on below. Please pull extcon with following updates.

Best Regards,
Chanwoo Choi


The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3:

  Linux 4.19-rc1 (2018-08-26 14:11:59 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git 
tags/extcon-next-for-4.20

for you to fetch changes up to 2e464ff0a9b1ab0fbb56e2ca8b1f5ff8c9f4e02f:

  extcon: int3496: Convert to use SPDX identifier (2018-08-28 11:21:15 +0900)


Update extcon for 4.20

Detailed description for this pull request:
1. Add SPDX license identifiers for Maxim and Intel extcon drivers
2. Clean-up extcon-intel-cht-wc.c driver without operation changes
3. Fix build warning of extcon core and use kasprintf instead of snprintf


Andy Shevchenko (7):
  extcon: Make static analyzer happy about union assignment
  extcon: Switch to use kasprintf() instead of open coded
  extcon: cht-wc: Return from default case to avoid warnings
  extcon: cht-wc: Fix definition names according to spec
  extcon: cht-wc: Correct USBID bit field handling
  extcon: cht-wc: Convert to use SPDX identifier
  extcon: int3496: Convert to use SPDX identifier

Krzysztof Kozlowski (1):
  extcon: maxim: Add SPDX license identifiers

 drivers/extcon/extcon-intel-cht-wc.c  | 60 +--
 drivers/extcon/extcon-intel-int3496.c | 12 ++-
 drivers/extcon/extcon-max14577.c  | 24 --
 drivers/extcon/extcon-max77693.c  | 22 -
 drivers/extcon/extcon-max77843.c  | 19 ---
 drivers/extcon/extcon-max8997.c   | 22 -
 drivers/extcon/extcon.c   | 15 +++--
 7 files changed, 61 insertions(+), 113 deletions(-)

[GIT PULL] PHY: for 4.20

[Kishon Vijay Abraham I]

Hi Greg,

Please find the pull request for 4.20 merge window below. It adds PHY
drivers for Socionext's PCIe PHY, USB2 PHY and USB3 PHY, Rockchip HDMI PHY
and Cadence display port PHY. Patches to add Qualcomm UFS PHY support and
Broadcom's BCM63138 PHY support is also included in this pull request. For
the complete list of changes, please see the tag message below.

For one of the Qualcomm PHY driver cleanup, a patch in SCSI layer is
modified. I've included that here after getting Ack from SCSI SUBSYSTEM
MAINTAINER Martin K. Petersen.

Consider merging it for the next merge window and let me know if I have
to make any changes.

Thanks
Kishon

The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3:

  Linux 4.19-rc1 (2018-08-26 14:11:59 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git 
tags/phy-for-4.20

for you to fetch changes up to 566b388440bb61447df7cdf5f4508a0fce493e00:

  phy: renesas: convert to SPDX identifiers (2018-09-26 13:09:41 +0530)


phy: for 4.20

 *) Add new PHY driver for Socionext PCIe, USB2 and USB3 PHY
 *) Add new PHY driver for Rockchip HDMI PHY
 *) Add new PHY driver for Cadence display port PHY
 *) Add support for UFS PHY in Qualcomm's SDM845 SoC
 *) Add correct PHY init sequence for BCM63138 SATA PHY
 *) Add support for bringing the uart2 out through the usb dm+dp pin in
Rockchips's rk3188
 *) Re-design R-Car Gen3 USB PHY w.r.t support for OTG
 *) Cleanup Qualcomm's UFS PHY, QMP PHY (for PCIe and USB3) and QUSB2 PHY
 *) A preparation patch to remove the node name pointer from struct device_node
 *) Minor cleanups in some of the other PHY drivers.

Signed-off-by: Kishon Vijay Abraham I 


Andreas Kemnade (1):
  phy: phy-twl4030-usb: fix denied runtime access

Can Guo (4):
  phy: Update PHY power control sequence
  phy: General struct and field cleanup
  phy: Add QMP phy based UFS phy support for sdm845
  dt-bindings: phy-qcom-qmp: Add UFS phy compatible string for sdm845

Douglas Anderson (3):
  dt-bindings: phy: qcom-qmp: Cleanup the 'reg' documentation as per review
  phy: qcom-qmp: Quiet -EPROBE_DEFER from qcom_qmp_phy_probe()
  phy: qcom-qusb2: Quiet -EPROBE_DEFER from qusb2_phy_probe()

Fabrizio Castro (2):
  dt-bindings: rcar-gen3-phy-usb2: Add r8a774a1 support
  dt-bindings: rcar-gen3-phy-usb3: Add r8a774a1 support

Florian Fainelli (3):
  dt-bindings: phy: Document BCM63138 compatible string
  phy: brcm-sata: allow PHY_BRCM_SATA driver to be built for DSL SoCs
  phy: brcm-sata: Add BCM63138 (DSL) PHY init sequence

Hauke Mehrtens (1):
  phy: lantiq: Fix compile warning

Heiko Stuebner (1):
  phy: rockchip-usb: add usb-uart setup for rk3188

Kunihiko Hayashi (6):
  dt-bindings: phy: add DT bindings for UniPhier USB3 PHY driver
  phy: socionext: add USB3 PHY driver for UniPhier SoC
  dt-bindings: phy: add DT bindings for UniPhier USB2 PHY driver
  phy: socionext: add USB2 PHY driver for UniPhier SoC
  dt-bindings: phy: add UniPhier PCIe PHY description
  phy: socionext: add PCIe PHY driver support

Kuninori Morimoto (1):
  phy: renesas: convert to SPDX identifiers

Rob Herring (1):
  phy: Convert to using %pOFn instead of device_node.name

Scott Telford (2):
  dt-bindings: phy: Document Cadence MHDP DisplayPort PHY bindings
  phy: Add driver for Cadence MHDP DisplayPort SD0801 PHY

Vivek Gautam (3):
  phy: qcom-ufs: Remove stale methods that handle ref clk
  scsi/ufs: qcom: Remove ufs_qcom_phy_*() calls from host
  phy: qcom-ufs: Declare 20nm qcom ufs qmp phy as Broken

Wolfram Sang (1):
  phy: renesas: use SPDX identifier for Renesas drivers

Yoshihiro Shimoda (8):
  dt-bindings: rcar-gen3-phy-usb2: add no-otg-pins property
  phy: renesas: rcar-gen3-usb2: fix vbus_ctrl for role sysfs
  phy: renesas: rcar-gen3-usb2: Rename has_otg_pins to uses_otg_pins
  phy: renesas: rcar-gen3-usb2: Check a property to use otg pins
  phy: renesas: rcar-gen3-usb2: unify OBINTEN handling
  phy: renesas: rcar-gen3-usb2: change a condition "dr_mode"
  phy: renesas: rcar-gen3-usb2: add conditions for uses_otg_pins == false
  phy: renesas: rcar-gen3-usb2: add is_otg_channel to use "role" sysfs

Zheng Yang (2):
  dt-bindings: add binding for Rockchip hdmi phy using an Innosilicon IP
  phy: add Rockchip Innosilicon hdmi phy

zhong jiang (2):
  phy:phy-brcm-usb: Use PTR_ERR_OR_ZERO to replace the open coded version
  phy:phy-lantiq-rcu-usb2: Use PTR_ERR_OR_ZERO to replace the open coded 
version

 Documentation/devicetree/bindings/phy/brcm-sata-phy.txt  |1 +
 Documentation/devicetree/bindings/phy/phy-cadence-dp.txt |   30 
 Documentation/devicetree/bindings/phy/phy-rockchip-inno-hdmi.txt |   43 

[PATCH] x86/build: remove unused CONFIG_AS_CRC32

[Masahiro Yamada]

CONFIG_AS_CRC32 is not used anywhere.

Signed-off-by: Masahiro Yamada 
---

 arch/x86/Makefile | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index bbdb780..bf0265f 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -189,7 +189,6 @@ cfi-sections := $(call as-instr,.cfi_sections 
.debug_frame,-DCONFIG_AS_CFI_SECTI
 # does binutils support specific instructions?
 asinstr := $(call as-instr,fxsaveq (%rax),-DCONFIG_AS_FXSAVEQ=1)
 asinstr += $(call as-instr,pshufb %xmm0$(comma)%xmm0,-DCONFIG_AS_SSSE3=1)
-asinstr += $(call as-instr,crc32l %eax$(comma)%eax,-DCONFIG_AS_CRC32=1)
 avx_instr := $(call as-instr,vxorps 
%ymm0$(comma)%ymm1$(comma)%ymm2,-DCONFIG_AS_AVX=1)
 avx2_instr :=$(call as-instr,vpbroadcastb 
%xmm0$(comma)%ymm1,-DCONFIG_AS_AVX2=1)
 avx512_instr :=$(call as-instr,vpmovm2b %k1$(comma)%zmm5,-DCONFIG_AS_AVX512=1)
-- 
2.7.4

Re: [PATCH resend] x86, asm: Use CC_SET()/CC_OUT() for __cmpxchg_double

[Borislav Petkov]

On Fri, Sep 28, 2018 at 10:33:05AM +0200, Uros Bizjak wrote:
> Remove open-coded uses of set instructions to use CC_SET()/CC_OUT()
> for __cmpxchg_double.
> 
> Signed-off-by: Uros Bizjak 
> ---
>  arch/x86/include/asm/cmpxchg.h | 10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/x86/include/asm/cmpxchg.h b/arch/x86/include/asm/cmpxchg.h
> index a55d79b233d3..bfb85e5844ab 100644
> --- a/arch/x86/include/asm/cmpxchg.h
> +++ b/arch/x86/include/asm/cmpxchg.h
> @@ -242,10 +242,12 @@ extern void __add_wrong_size(void)
> BUILD_BUG_ON(sizeof(*(p2)) != sizeof(long));\
> VM_BUG_ON((unsigned long)(p1) % (2 * sizeof(long)));\
> VM_BUG_ON((unsigned long)((p1) + 1) != (unsigned long)(p2));\
> -   asm volatile(pfx "cmpxchg%c4b %2; sete %0"  \
> -: "=a" (__ret), "+d" (__old2), \
> -  "+m" (*(p1)), "+m" (*(p2))   \
> -: "i" (2 * sizeof(long)), "a" (__old1),\
> +   asm volatile(pfx "cmpxchg%c5b %1"   \
> +CC_SET(e)  \
> +: CC_OUT(e) (__ret),   \
> +  "+m" (*(p1)), "+m" (*(p2)),  \
> +  "+a" (__old1), "+d" (__old2) \
> +: "i" (2 * sizeof(long)),  \

To quote checkpatch:

WARNING: please, no spaces at the start of a line
#34: FILE: arch/x86/include/asm/cmpxchg.h:245:
+   asm volatile(pfx "cmpxchg%c5b %1"   \$

ERROR: code indent should use tabs where possible
#35: FILE: arch/x86/include/asm/cmpxchg.h:246:
+CC_SET(e)  \$

WARNING: please, no spaces at the start of a line
#35: FILE: arch/x86/include/asm/cmpxchg.h:246:
+CC_SET(e)  \$

ERROR: code indent should use tabs where possible
#36: FILE: arch/x86/include/asm/cmpxchg.h:247:
+: CC_OUT(e) (__ret),   \$


...

-- 
Regards/Gruss,
Boris.

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

[tip:irq/core] genirq/debugfs: Reset domain debugfs_file on removal of the debugfs file

[tip-bot for Marc Zyngier]

Commit-ID:  513145ea66af95f1a5c744d7b5a4f4a97625e669
Gitweb: https://git.kernel.org/tip/513145ea66af95f1a5c744d7b5a4f4a97625e669
Author: Marc Zyngier 
AuthorDate: Mon, 1 Oct 2018 11:05:21 +0100
Committer:  Thomas Gleixner 
CommitDate: Mon, 1 Oct 2018 12:24:53 +0200

genirq/debugfs: Reset domain debugfs_file on removal of the debugfs file

When removing a debugfs file for a given irq domain, we fail to clear the
corresponding field, meaning that the corresponding domain won't be created
again if we need to do so.

It turns out that this is exactly what irq_domain_update_bus_token does
(delete old file, update domain name, recreate file).

This doesn't have any impact other than making debug more difficult, but we
do value ease of debugging... So clear the debugfs_file field.

Signed-off-by: Marc Zyngier 
Signed-off-by: Thomas Gleixner 
Link: https://lkml.kernel.org/r/20181001100522.180054-2-marc.zyng...@arm.com

---
 kernel/irq/irqdomain.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index 5d9fc01b60a6..95a0acbdd4e6 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -1741,6 +1741,7 @@ static void debugfs_add_domain_dir(struct irq_domain *d)
 static void debugfs_remove_domain_dir(struct irq_domain *d)
 {
debugfs_remove(d->debugfs_file);
+   d->debugfs_file = NULL;
 }
 
 void __init irq_domain_debugfs_init(struct dentry *root)

[tip:irq/core] genirq/debugfs: Reinstate full OF path for domain name

[tip-bot for Marc Zyngier]

Commit-ID:  94967b55ebf3b603f2fe750ecedd896042585a1c
Gitweb: https://git.kernel.org/tip/94967b55ebf3b603f2fe750ecedd896042585a1c
Author: Marc Zyngier 
AuthorDate: Mon, 1 Oct 2018 11:05:22 +0100
Committer:  Thomas Gleixner 
CommitDate: Mon, 1 Oct 2018 12:24:53 +0200

genirq/debugfs: Reinstate full OF path for domain name

On a DT based system, we use the of_node full name to name the
corresponding irq domain. We expect that name to be unique, so so that
domains with the same base name won't clash (this happens on multi-node
topologies, for example).

Since a7e4cfb0a7ca ("of/fdt: only store the device node basename in
full_name"), of_node_full_name() lies and only returns the basename. This
breaks the above requirement, and we end-up with only a subset of the
domains in /sys/kernel/debug/irq/domains.

Let's reinstate the feature by using the fancy new %pOF format specifier,
which happens to do the right thing.

Fixes: a7e4cfb0a7ca ("of/fdt: only store the device node basename in full_name")
Signed-off-by: Marc Zyngier 
Signed-off-by: Thomas Gleixner 
Link: https://lkml.kernel.org/r/20181001100522.180054-3-marc.zyng...@arm.com

---
 kernel/irq/irqdomain.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index 95a0acbdd4e6..3b30a4aeb0db 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -183,7 +183,7 @@ struct irq_domain *__irq_domain_add(struct fwnode_handle 
*fwnode, int size,
 * unhappy about. Replace them with ':', which does
 * the trick and is not as offensive as '\'...
 */
-   name = kstrdup(of_node_full_name(of_node), GFP_KERNEL);
+   name = kasprintf(GFP_KERNEL, "%pOF", of_node);
if (!name) {
kfree(domain);
return NULL;

Re: [PATCH] gpio: omap: get rid of the conditional PM runtime calls

[Linus Walleij]

On Fri, Sep 28, 2018 at 11:39 PM Grygorii Strashko
 wrote:

> OMAP GPIO driver is checking !BANK_USED() used condition before calling PM
> runtime API, because of PM runtime calls in
> omap2_gpio_prepare/resume_for_idle(). It's not required any more since
> "omap gpio add level idle, cpu_pm and drop runtime_irq_safe" series [1]
> from Tony Lindgren was accepted and PM runtime management was enabled in
> IRQ chip core by commit be45beb2df69 ("genirq: Add runtime power management
> support for IRQ chips") .
>
> As result safely drop !BANK_USED() checks from omap_gpio_request/free(),
> omap_gpio_irq_bus_lock/unlock() and enable PM runtime management for OMAP
> GPIO IRQ chip.
>
> [1] https://www.spinics.net/lists/arm-kernel/msg677583.html
> Tested-by: Tony Lindgren 
> Signed-off-by: Grygorii Strashko 

Patch applied.

Yours,
Linus Walleij

[RFC v2 7/7] MIPS: Add Realtek RTL8186 SoC support

[Yasha Cherikovsky]

The Realtek RTL8186 SoC is a MIPS based SoC
used in some home routers [1][2].

The hardware includes Lexra LX5280 CPU with a TLB,
two Ethernet controllers, a WLAN controller and more.

With this patch, it is possible to successfully boot
the kernel and load userspace on the Edimax BR-6204Wg
router.
Network drivers support will come in future patches.

This patch includes:
- New MIPS rtl8186 platform (mostly DT based)
- defconfig file
- MIPS zboot UART support
- Device tree files for the RTL8186 SoC and Edimax BR-6204Wg
router

[1] https://www.linux-mips.org/wiki/Realtek_SOC#Realtek_RTL8186
[2] https://wikidevi.com/wiki/Realtek_RTL8186

Signed-off-by: Yasha Cherikovsky 
Cc: Ralf Baechle 
Cc: Paul Burton 
Cc: James Hogan 
Cc: Rob Herring 
Cc: Mark Rutland 
Cc: linux-m...@linux-mips.org
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
 arch/mips/Kbuild.platforms|   1 +
 arch/mips/Kconfig |  17 +++
 arch/mips/boot/compressed/uart-16550.c|   5 +
 arch/mips/boot/dts/Makefile   |   1 +
 arch/mips/boot/dts/realtek/Makefile   |   4 +
 arch/mips/boot/dts/realtek/rtl8186.dtsi   |  86 ++
 .../dts/realtek/rtl8186_edimax_br_6204wg.dts  |  45 +++
 arch/mips/configs/rtl8186_defconfig   | 112 ++
 arch/mips/include/asm/mach-rtl8186/rtl8186.h  |  37 ++
 arch/mips/rtl8186/Makefile|   2 +
 arch/mips/rtl8186/Platform|   7 ++
 arch/mips/rtl8186/irq.c   |   8 ++
 arch/mips/rtl8186/prom.c  |  15 +++
 arch/mips/rtl8186/setup.c |  80 +
 arch/mips/rtl8186/time.c  |  10 ++
 15 files changed, 430 insertions(+)
 create mode 100644 arch/mips/boot/dts/realtek/Makefile
 create mode 100644 arch/mips/boot/dts/realtek/rtl8186.dtsi
 create mode 100644 arch/mips/boot/dts/realtek/rtl8186_edimax_br_6204wg.dts
 create mode 100644 arch/mips/configs/rtl8186_defconfig
 create mode 100644 arch/mips/include/asm/mach-rtl8186/rtl8186.h
 create mode 100644 arch/mips/rtl8186/Makefile
 create mode 100644 arch/mips/rtl8186/Platform
 create mode 100644 arch/mips/rtl8186/irq.c
 create mode 100644 arch/mips/rtl8186/prom.c
 create mode 100644 arch/mips/rtl8186/setup.c
 create mode 100644 arch/mips/rtl8186/time.c

diff --git a/arch/mips/Kbuild.platforms b/arch/mips/Kbuild.platforms
index ac7ad54f984f..2793741f05e5 100644
--- a/arch/mips/Kbuild.platforms
+++ b/arch/mips/Kbuild.platforms
@@ -27,6 +27,7 @@ platforms += pmcs-msp71xx
 platforms += pnx833x
 platforms += ralink
 platforms += rb532
+platforms += rtl8186
 platforms += sgi-ip22
 platforms += sgi-ip27
 platforms += sgi-ip32
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index bbeabd6b0a80..2f2ef09a1961 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -344,6 +344,23 @@ config MACH_DECSTATION
 
  otherwise choose R3000.
 
+config MACH_RTL8186
+   bool "Realtek RTL8186 SoC"
+   select SYS_SUPPORTS_BIG_ENDIAN
+   select SYS_SUPPORTS_32BIT_KERNEL
+   select SYS_HAS_CPU_LX5280
+   select DMA_NONCOHERENT
+   select SYS_SUPPORTS_ZBOOT_UART16550
+   select SYS_HAS_EARLY_PRINTK
+   select USE_GENERIC_EARLY_PRINTK_8250
+   select USE_OF
+   select COMMON_CLK
+   select RTL8186_IRQ
+   select RTL8186_TIMER
+   select BUILTIN_DTB
+   help
+ Realtek RTL8186 SoC support.
+
 config MACH_JAZZ
bool "Jazz family of machines"
select ARCH_MIGHT_HAVE_PC_PARPORT
diff --git a/arch/mips/boot/compressed/uart-16550.c 
b/arch/mips/boot/compressed/uart-16550.c
index aee8d7b8f091..99314df48718 100644
--- a/arch/mips/boot/compressed/uart-16550.c
+++ b/arch/mips/boot/compressed/uart-16550.c
@@ -35,6 +35,11 @@
 #define IOTYPE unsigned int
 #endif
 
+#ifdef CONFIG_MACH_RTL8186
+#define UART0_BASE 0xbd0100c3
+#define PORT(offset) (UART0_BASE + (4 * offset))
+#endif
+
 #ifndef IOTYPE
 #define IOTYPE char
 #endif
diff --git a/arch/mips/boot/dts/Makefile b/arch/mips/boot/dts/Makefile
index 1e79cab8e269..50dc192bbde5 100644
--- a/arch/mips/boot/dts/Makefile
+++ b/arch/mips/boot/dts/Makefile
@@ -11,6 +11,7 @@ subdir-y  += ni
 subdir-y   += pic32
 subdir-y   += qca
 subdir-y   += ralink
+subdir-y   += realtek
 subdir-y   += xilfpga
 
 obj-$(CONFIG_BUILTIN_DTB)  := $(addsuffix /, $(subdir-y))
diff --git a/arch/mips/boot/dts/realtek/Makefile 
b/arch/mips/boot/dts/realtek/Makefile
new file mode 100644
index ..654c3a8da574
--- /dev/null
+++ b/arch/mips/boot/dts/realtek/Makefile
@@ -0,0 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0
+dtb-$(CONFIG_MACH_RTL8186) += rtl8186_edimax_br_6204wg.dtb
+
+obj-$(CONFIG_BUILTIN_DTB)  += $(addsuffix .o, $(dtb-y))
diff --git a/arch/mips/boot/dts/realtek/rtl8186.dtsi 
b/arch/mips/boot/dts/realtek/rtl8186.dtsi
new file mode 100644
index ..d172999a42a6
--- /dev/null
+++ b/arch/mips/boot/dts/

[RFC v2 4/7] dt-binding: timer: Document RTL8186 SoC DT bindings

[Yasha Cherikovsky]

This patch adds device tree binding doc for the
Realtek RTL8186 SoC timer controller.

Signed-off-by: Yasha Cherikovsky 
Cc: Rob Herring 
Cc: Mark Rutland 
Cc: Daniel Lezcano 
Cc: Thomas Gleixner 
Cc: Ralf Baechle 
Cc: Paul Burton 
Cc: James Hogan 
Cc: devicet...@vger.kernel.org
Cc: linux-m...@linux-mips.org
Cc: linux-kernel@vger.kernel.org
---
 .../bindings/timer/realtek,rtl8186-timer.txt| 17 +
 1 file changed, 17 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/timer/realtek,rtl8186-timer.txt

diff --git a/Documentation/devicetree/bindings/timer/realtek,rtl8186-timer.txt 
b/Documentation/devicetree/bindings/timer/realtek,rtl8186-timer.txt
new file mode 100644
index ..eaa6292c16e0
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/realtek,rtl8186-timer.txt
@@ -0,0 +1,17 @@
+Realtek RTL8186 SoC timer
+
+Required properties:
+
+- compatible : Should be "realtek,rtl8186-timer".
+- reg : Specifies base physical address and size of the registers.
+- interrupts : The interrupt number of the timer.
+- clocks: phandle to the source clock (usually a 22 MHz fixed clock)
+
+Example:
+
+timer {
+   compatible = "realtek,rtl8186-timer";
+   reg = <0x1d010050 0x30>;
+   interrupts = <0>;
+   clocks = <&sysclk>;
+};
-- 
2.19.0

[RFC v2 5/7] clocksource/drivers/rtl8186: Add RTL8186 timer driver

[Yasha Cherikovsky]

The Realtek RTL8186 SoC is a MIPS based SoC
used in some home routers [1][2].

This adds a driver to handle the built-in timers
on this SoC.

Timers 0 and 1 are 24bit timers.
Timers 2 and 3 are 32bit timers.

Use Timer2 as clocksource and Timer3 for clockevents.
Timer2 is also used for sched_clock.

[1] https://www.linux-mips.org/wiki/Realtek_SOC#Realtek_RTL8186
[2] https://wikidevi.com/wiki/Realtek_RTL8186

Signed-off-by: Yasha Cherikovsky 
Cc: Ralf Baechle 
Cc: Paul Burton 
Cc: James Hogan 
Cc: Daniel Lezcano 
Cc: Thomas Gleixner 
Cc: Rob Herring 
Cc: Mark Rutland 
Cc: linux-m...@linux-mips.org
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
 drivers/clocksource/Kconfig |   9 ++
 drivers/clocksource/Makefile|   1 +
 drivers/clocksource/timer-rtl8186.c | 220 
 3 files changed, 230 insertions(+)
 create mode 100644 drivers/clocksource/timer-rtl8186.c

diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index dec0dd88ec15..da87f73d0631 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -609,4 +609,13 @@ config ATCPIT100_TIMER
help
  This option enables support for the Andestech ATCPIT100 timers.
 
+config RTL8186_TIMER
+   bool "RTL8186 timer driver"
+   depends on MACH_RTL8186
+   depends on COMMON_CLK
+   select TIMER_OF
+   select CLKSRC_MMIO
+   help
+ Enables support for the RTL8186 timer driver.
+
 endmenu
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index 00caf37e52f9..734e8566e1b6 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -78,3 +78,4 @@ obj-$(CONFIG_H8300_TPU)   += h8300_tpu.o
 obj-$(CONFIG_CLKSRC_ST_LPC)+= clksrc_st_lpc.o
 obj-$(CONFIG_X86_NUMACHIP) += numachip.o
 obj-$(CONFIG_ATCPIT100_TIMER)  += timer-atcpit100.o
+obj-$(CONFIG_RTL8186_TIMER)+= timer-rtl8186.o
diff --git a/drivers/clocksource/timer-rtl8186.c 
b/drivers/clocksource/timer-rtl8186.c
new file mode 100644
index ..47ef4b09ad27
--- /dev/null
+++ b/drivers/clocksource/timer-rtl8186.c
@@ -0,0 +1,220 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Realtek RTL8186 SoC timer driver.
+ *
+ * Timer0 (24bit): Unused
+ * Timer1 (24bit): Unused
+ * Timer2 (32bit): Used as clocksource
+ * Timer3 (32bit): Used as clock event device
+ *
+ * Copyright (C) 2018 Yasha Cherikovsky
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include "timer-of.h"
+
+/* Timer registers */
+#define TCCNR  0x0
+#define TCIR   0x4
+#define TC_DATA(t) (0x10 + 4 * (t))
+#define TC_CNT(t)  (0x20 + 4 * (t))
+
+/* TCCNR register bits */
+#define TCCNR_TC_EN_BIT(t) BIT((t) * 2)
+#define TCCNR_TC_MODE_BIT(t)   BIT((t) * 2 + 1)
+#define TCCNR_TC_SRC_BIT(t)BIT((t) + 8)
+
+/* TCIR register bits */
+#define TCIR_TC_IE_BIT(t)  BIT(t)
+#define TCIR_TC_IP_BIT(t)  BIT((t) + 4)
+
+
+/* Forward declaration */
+static struct timer_of to;
+
+static void __iomem *base;
+
+
+#define RTL8186_TIMER_MODE_COUNTER 0
+#define RTL8186_TIMER_MODE_TIMER   1
+
+static void rtl8186_set_enable_bit(int timer, int enabled)
+{
+   u16 tccnr;
+
+   tccnr = readl(base + TCCNR);
+   tccnr &= ~(TCCNR_TC_EN_BIT(timer));
+
+   if (enabled)
+   tccnr |= TCCNR_TC_EN_BIT(timer);
+
+   writel(tccnr, base + TCCNR);
+}
+
+static void rtl8186_set_mode_bit(int timer, int mode)
+{
+   u16 tccnr;
+
+   tccnr = readl(base + TCCNR);
+   tccnr &= ~(TCCNR_TC_MODE_BIT(timer));
+
+   if (mode)
+   tccnr |= TCCNR_TC_MODE_BIT(timer);
+
+   writel(tccnr, base + TCCNR);
+}
+
+
+static irqreturn_t rtl8186_timer_interrupt(int irq, void *dev_id)
+{
+   struct clock_event_device *cd = dev_id;
+   int status;
+
+   status = readl(base + TCIR);
+   writel(status, base + TCIR); /* Clear all interrupts */
+
+   cd->event_handler(cd);
+
+   return IRQ_HANDLED;
+}
+
+static int rtl8186_clockevent_set_next(unsigned long evt,
+  struct clock_event_device *cd)
+{
+   rtl8186_set_enable_bit(3, 0);
+   writel(evt, base + TC_DATA(3));
+   writel(evt, base + TC_CNT(3));
+   rtl8186_set_enable_bit(3, 1);
+   return 0;
+}
+
+static int rtl8186_set_state_periodic(struct clock_event_device *cd)
+{
+   unsigned long period = timer_of_period(to_timer_of(cd));
+
+   rtl8186_set_enable_bit(3, 0);
+   rtl8186_set_mode_bit(3, RTL8186_TIMER_MODE_TIMER);
+
+   /* This timer should reach zero each jiffy */
+   writel(period, base + TC_DATA(3));
+   writel(period, base + TC_CNT(3));
+
+   rtl8186_set_enable_bit(3, 1);
+   return 0;
+}
+
+static int rtl8186_set_state_oneshot(struct clock_event_device *cd)
+

[RFC v2 1/7] MIPS: Add support for the Lexra LX5280 CPU

[Yasha Cherikovsky]

The Lexra LX5280 CPU [1][2] implements the MIPS-I ISA,
without unaligned load/store instructions (lwl, lwr, swl, swr).
The programming model of this CPU is very similar
to the R3000 programming model, with a few differences.

The Realtek RTL8186 SoC has this CPU, so this patch is required
for future RTL8186 SoC support.

The LX5280 CPU has no documented TLB unit (only SMMU, a simple MMU unit
which is not enough for usual Linux).
However, the RTL8186 SoC does include a TLB unit with the CPU
(programmed like R3000 TLB).

So this patch adds support *only* for LX5280s that have a TLB unit.

This patch includes:
- Adding Kconfig entries for LX5280
- Adding CPU_LX5280 to the cpu_type_enum
- Passing -march=lx5280 to the compiler
- Using existing R3000 code/behavior where possible
- Wait instruction support (for better idle power consuption)
- RDHWR instruction emulation from the page fault handler
  (more details in a code comment)

[1] https://www.linux-mips.org/wiki/Lexra
[2] https://wikidevi.com/wiki/Lexra_LX5280

Signed-off-by: Yasha Cherikovsky 
Cc: Ralf Baechle 
Cc: Paul Burton 
Cc: James Hogan 
Cc: linux-m...@linux-mips.org
Cc: linux-kernel@vger.kernel.org
---
 arch/mips/Kconfig|  30 +++-
 arch/mips/Makefile   |   1 +
 arch/mips/include/asm/cpu-features.h |   3 +
 arch/mips/include/asm/cpu-type.h |   4 +
 arch/mips/include/asm/cpu.h  |   9 +
 arch/mips/include/asm/isadep.h   |   3 +-
 arch/mips/include/asm/mipsregs.h |  10 ++
 arch/mips/include/asm/module.h   |   2 +
 arch/mips/include/asm/pgtable-32.h   |   7 +-
 arch/mips/include/asm/pgtable-bits.h |   9 +-
 arch/mips/include/asm/pgtable.h  |   6 +-
 arch/mips/include/asm/stackframe.h   |   9 +-
 arch/mips/include/asm/traps.h|   2 +
 arch/mips/kernel/Makefile|   2 +
 arch/mips/kernel/cpu-probe.c |   6 +
 arch/mips/kernel/entry.S |   3 +-
 arch/mips/kernel/genex.S |   6 +-
 arch/mips/kernel/idle.c  |  10 ++
 arch/mips/kernel/process.c   |   3 +-
 arch/mips/kernel/traps.c |  42 +
 arch/mips/lib/Makefile   |   1 +
 arch/mips/mm/Makefile|   1 +
 arch/mips/mm/c-lx5280.c  | 251 +++
 arch/mips/mm/cache.c |   6 +
 arch/mips/mm/fault.c |   4 +
 arch/mips/mm/tlbex.c |   1 +
 26 files changed, 408 insertions(+), 23 deletions(-)
 create mode 100644 arch/mips/mm/c-lx5280.c

diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index a6b0391996ea..bbeabd6b0a80 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -1558,6 +1558,17 @@ config CPU_R3000
  might be a safe bet.  If the resulting kernel does not work,
  try to recompile with R3000.
 
+config CPU_LX5280
+   bool "LX5280"
+   depends on SYS_HAS_CPU_LX5280
+   select CPU_SUPPORTS_32BIT_KERNEL
+   help
+ Choose this option to build a kernel for the Lexra LX5280 CPU.
+ Lexra LX5280 implements the MIPS-I instruction set, without
+ unaligned load and store instructions (lwl, lwr, swl, swr).
+ Only LX5280 CPUs with a TLB unit are supported.
+
+
 config CPU_TX39XX
bool "R39XX"
depends on SYS_HAS_CPU_TX39XX
@@ -1939,6 +1950,9 @@ config SYS_HAS_CPU_R3000
 config SYS_HAS_CPU_TX39XX
bool
 
+config SYS_HAS_CPU_LX5280
+   bool
+
 config SYS_HAS_CPU_VR41XX
bool
 
@@ -2169,7 +2183,7 @@ config PAGE_SIZE_8KB
 
 config PAGE_SIZE_16KB
bool "16kB"
-   depends on !CPU_R3000 && !CPU_TX39XX
+   depends on !CPU_R3000 && !CPU_TX39XX && !CPU_LX5280
help
  Using 16kB page size will result in higher performance kernel at
  the price of higher memory consumption.  This option is available on
@@ -2188,7 +2202,7 @@ config PAGE_SIZE_32KB
 
 config PAGE_SIZE_64KB
bool "64kB"
-   depends on !CPU_R3000 && !CPU_TX39XX
+   depends on !CPU_R3000 && !CPU_TX39XX && !CPU_LX5280
help
  Using 64kB page size will result in higher performance kernel at
  the price of higher memory consumption.  This option is available on
@@ -2256,15 +2270,15 @@ config CPU_HAS_PREFETCH
 
 config CPU_GENERIC_DUMP_TLB
bool
-   default y if !(CPU_R3000 || CPU_R8000 || CPU_TX39XX)
+   default y if !(CPU_R3000 || CPU_R8000 || CPU_TX39XX || CPU_LX5280)
 
 config CPU_R4K_FPU
bool
-   default y if !(CPU_R3000 || CPU_TX39XX)
+   default y if !(CPU_R3000 || CPU_TX39XX || CPU_LX5280)
 
 config CPU_R4K_CACHE_TLB
bool
-   default y if !(CPU_R3000 || CPU_R8000 || CPU_SB1 || CPU_TX39XX || 
CPU_CAVIUM_OCTEON)
+   default y if !(CPU_R3000 || CPU_R8000 || CPU_SB1 || CPU_TX39XX || 
CPU_CAVIUM_OCTEON || CPU_LX5280)
 
 config MIPS_MT_SMP
bool "MIPS MT SMP support (1 TC on each available VPE)"
@@ -2501,7 +2515,7 @@ config CPU_MIPSR2_IRQ_EI
 
 config CPU_HAS_SYNC
bool
-   depends on !CPU_R3

Re: [PATCH v3 0/3] Add Amlogic video decoder driver

[Hans Verkuil]

On 09/28/2018 04:28 PM, Maxime Jourdan wrote:
> Hi everyone,
> 
> This patch series adds support for the Amlogic video decoder,
> as well as the corresponding dt bindings for GXBB/GXL/GXM chips.
> 
> It features decoding for the following formats:
> - MPEG 1
> - MPEG 2
> 
> The following formats will be added in future patches:
> - MJPEG
> - MPEG 4 (incl. Xvid, H.263)
> - H.264
> - HEVC (incl. 10-bit)
> 
> The following formats' development has still not started, but they are
> supported by the hardware:
> - VC1
> - VP9
> 
> The code was made in such a way to allow easy inclusion of those formats
> in the future.
> 
> The decoder is single instance.
> 
> Files:
>  - vdec.c handles the V4L2 M2M logic
>  - esparser.c manages the hardware bitstream parser
>  - vdec_helpers.c provides helpers to DONE the dst buffers as well as
>  various common code used by the codecs
>  - vdec_1.c manages the VDEC_1 block of the vdec IP
>  - codec_mpeg12.c enables decoding for MPEG 1/2.
>  - vdec_platform.c links codec units with vdec units
>  (e.g vdec_1 with codec_mpeg12) and lists all the available
>  src/dst formats and requirements (max width/height, etc.),
>  per compatible chip.
> 
> Firmwares are necessary to run the vdec. They can currently be found at:
> https://github.com/chewitt/meson-firmware

Are you trying to get this into the linux-firmware repository?

I believe that Mauro requires that before he will merge this driver.

So I think this driver will be ready to be merged once v4 is posted,
dt-bindings is Acked and the firmware is merged to the linux-firmware repo.

Regards,

Hans

[RFC v2 0/7] MIPS: Lexra LX5280 CPU + Realtek RTL8186 SoC support

[Yasha Cherikovsky]

Hi,

Changelog:

v2:
- Patch 5 in v1 added irqchip, timer and arch code for the SoC all in one patch.
  Split this patch into 3 patches:
- Patch 3 for irqchip (depends on MACH_RTL8186 in Kconfig)
- Patch 5 for timer (depends on MACH_RTL8186 in Kconfig)
- Patch 7 for SoC code in arch/mips (adds MACH_RTL8186 in mips and selects 
irqchip+timer drivers)
  Also, reorder the patches in a way that each DT binding patch comes before
  the respective driver patch.

- No code changes from v1

--

This RFC patch series adds all the necessary code
to successfully boot Linux on the Realtek RTL8186 SoC.

Boot log with the v1 series applied (+one DT patch that adds partitions) is 
available here:
https://gist.github.com/yashac3/483decfa8db014edfb055ba5a1f9996e

Network drivers and other misc drivers are not included
in this patch set, but are being worked on.


This patch series includes:
- Patch 1: Lexra LX5280 CPU support (MIPS)

- Patch 2: Device tree bindings for the RTL8186 interrupt controller
- Patch 3: RTL8186 interrupt controller driver

- Patch 4: Device tree bindings for the RTL8186 timer
- Patch 5: RTL8186 timer driver

- Patch 6: Device tree bindings for Realtek MIPS SoCs
- Patch 7: RTL8186 SoC support (MIPS, device tree)


What's still missing:
1) Upstream toolchain support for the Lexra LX5280 CPU.
   (Still WIP) GCC and binutils patches are available at [1][2].
   Buildroot with these patches applied is available at [3].

   The toolchain work is still WIP and I'm planning to send it
   for review when it will be ready.

   Still, feel free to comment on this work too.

2) Reading the TLB size from device tree:
   (The reason there's no DT bindings for the LX5280 in this series)

   As there's no way to get the TLB size from the hardware,
   is must be passed in the DT.

   Currently in arch/mips, the FDT is not available in the cpu_probe()
   stage, where the 'tlbsize' field of the cpu data is set.

   Any ideas/suggestions on how to solve that?


This patch series is on top of v4.18 + 5 prerequisite patches that
are in mips-next for 4.20. [4][5].

This patch series is also available at:
https://github.com/yashac3/linux-rtl8186/commits/rtl8186-porting-for-upstream-4.18-v2


Please review.

Thanks,
Yasha


[1] https://github.com/yashac3/gcc/commits/lx5280-gcc-8_2_0
[2] https://github.com/yashac3/binutils-gdb/commits/lx5280-porting-master
[3] https://github.com/yashac3/buildroot/commits/lx5280_master
[4] https://www.linux-mips.org/archives/linux-mips/2018-09/msg00769.html
[5] https://www.linux-mips.org/archives/linux-mips/2018-09/msg00775.html


Cc: linux-kernel@vger.kernel.org


Yasha Cherikovsky (7):
  MIPS: Add support for the Lexra LX5280 CPU
  dt-binding: interrupt-controller: Document RTL8186 SoC DT bindings
  irqchip/rtl8186: Add RTL8186 interrupt controller driver
  dt-binding: timer: Document RTL8186 SoC DT bindings
  clocksource/drivers/rtl8186: Add RTL8186 timer driver
  dt-binding: mips: Document Realtek SoC DT bindings
  MIPS: Add Realtek RTL8186 SoC support

 .../interrupt-controller/realtek,rtl8186-intc |  18 ++
 .../devicetree/bindings/mips/realtek.txt  |   9 +
 .../bindings/timer/realtek,rtl8186-timer.txt  |  17 ++
 arch/mips/Kbuild.platforms|   1 +
 arch/mips/Kconfig |  47 +++-
 arch/mips/Makefile|   1 +
 arch/mips/boot/compressed/uart-16550.c|   5 +
 arch/mips/boot/dts/Makefile   |   1 +
 arch/mips/boot/dts/realtek/Makefile   |   4 +
 arch/mips/boot/dts/realtek/rtl8186.dtsi   |  86 ++
 .../dts/realtek/rtl8186_edimax_br_6204wg.dts  |  45 
 arch/mips/configs/rtl8186_defconfig   | 112 
 arch/mips/include/asm/cpu-features.h  |   3 +
 arch/mips/include/asm/cpu-type.h  |   4 +
 arch/mips/include/asm/cpu.h   |   9 +
 arch/mips/include/asm/isadep.h|   3 +-
 arch/mips/include/asm/mach-rtl8186/rtl8186.h  |  37 +++
 arch/mips/include/asm/mipsregs.h  |  10 +
 arch/mips/include/asm/module.h|   2 +
 arch/mips/include/asm/pgtable-32.h|   7 +-
 arch/mips/include/asm/pgtable-bits.h  |   9 +-
 arch/mips/include/asm/pgtable.h   |   6 +-
 arch/mips/include/asm/stackframe.h|   9 +-
 arch/mips/include/asm/traps.h |   2 +
 arch/mips/kernel/Makefile |   2 +
 arch/mips/kernel/cpu-probe.c  |   6 +
 arch/mips/kernel/entry.S  |   3 +-
 arch/mips/kernel/genex.S  |   6 +-
 arch/mips/kernel/idle.c   |  10 +
 arch/mips/kernel/process.c|   3 +-
 arch/mips/kernel/traps.c  |  42 +++
 arch/mips/lib/Makefile|   1 +
 arch/mips/mm/Makefile |   1 +
 arch/mips/mm/c-lx5280.c   | 251 ++
 arch/mips/mm/cache.c

[RFC v2 2/7] dt-binding: interrupt-controller: Document RTL8186 SoC DT bindings

[Yasha Cherikovsky]

This patch adds device tree binding doc for the
Realtek RTL8186 SoC interrupt controller.

Signed-off-by: Yasha Cherikovsky 
Cc: Rob Herring 
Cc: Mark Rutland 
Cc: Thomas Gleixner 
Cc: Jason Cooper 
Cc: Marc Zyngier 
Cc: Ralf Baechle 
Cc: Paul Burton 
Cc: James Hogan 
Cc: devicet...@vger.kernel.org
Cc: linux-m...@linux-mips.org
Cc: linux-kernel@vger.kernel.org
---
 .../interrupt-controller/realtek,rtl8186-intc  | 18 ++
 1 file changed, 18 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/realtek,rtl8186-intc

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/realtek,rtl8186-intc 
b/Documentation/devicetree/bindings/interrupt-controller/realtek,rtl8186-intc
new file mode 100644
index ..21956d210021
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/interrupt-controller/realtek,rtl8186-intc
@@ -0,0 +1,18 @@
+Realtek RTL8186 SoC interrupt controller
+
+Required properties:
+
+- compatible : should be "realtek,rtl8186-intc"
+- interrupt-controller : Identifies the node as an interrupt controller.
+- #interrupt-cells : Specifies the number of cells needed to encode an
+  interrupt source. The value shall be 1.
+- reg : Specifies base physical address and size of the registers.
+
+Example:
+
+intc: interrupt-controller@1d01 {
+   compatible = "realtek,rtl8186-intc";
+   interrupt-controller;
+   #interrupt-cells = <1>;
+   reg = <0x1d01 0x8>;
+};
-- 
2.19.0

[RFC v2 6/7] dt-binding: mips: Document Realtek SoC DT bindings

[Yasha Cherikovsky]

This patch adds device tree binding doc for Realtek MIPS SoCs.

It includes a compatible string for the Realtek RTL8186 SoC.

Signed-off-by: Yasha Cherikovsky 
Cc: Rob Herring 
Cc: Mark Rutland 
Cc: Ralf Baechle 
Cc: Paul Burton 
Cc: James Hogan 
Cc: devicet...@vger.kernel.org
Cc: linux-m...@linux-mips.org
Cc: linux-kernel@vger.kernel.org
---
 Documentation/devicetree/bindings/mips/realtek.txt | 9 +
 1 file changed, 9 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mips/realtek.txt

diff --git a/Documentation/devicetree/bindings/mips/realtek.txt 
b/Documentation/devicetree/bindings/mips/realtek.txt
new file mode 100644
index ..09d19758168a
--- /dev/null
+++ b/Documentation/devicetree/bindings/mips/realtek.txt
@@ -0,0 +1,9 @@
+Realtek MIPS SoC device tree bindings
+
+1. SoCs
+
+Each device tree must specify a compatible value for the Realtek SoC
+it uses in the compatible property of the root node. The compatible
+value must be one of the following values:
+
+  realtek,rtl8186-soc
-- 
2.19.0

[RFC v2 3/7] irqchip/rtl8186: Add RTL8186 interrupt controller driver

[Yasha Cherikovsky]

The Realtek RTL8186 SoC is a MIPS based SoC
used in some home routers [1][2].

This adds a driver to handle the interrupt controller
on this SoC.

[1] https://www.linux-mips.org/wiki/Realtek_SOC#Realtek_RTL8186
[2] https://wikidevi.com/wiki/Realtek_RTL8186

Signed-off-by: Yasha Cherikovsky 
Cc: Ralf Baechle 
Cc: Paul Burton 
Cc: James Hogan 
Cc: Thomas Gleixner 
Cc: Jason Cooper 
Cc: Marc Zyngier 
Cc: Rob Herring 
Cc: Mark Rutland 
Cc: linux-m...@linux-mips.org
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
 drivers/irqchip/Kconfig   |   5 ++
 drivers/irqchip/Makefile  |   1 +
 drivers/irqchip/irq-rtl8186.c | 107 ++
 3 files changed, 113 insertions(+)
 create mode 100644 drivers/irqchip/irq-rtl8186.c

diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index e9233db16e03..83099905a871 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -371,4 +371,9 @@ config QCOM_PDC
  Power Domain Controller driver to manage and configure wakeup
  IRQs for Qualcomm Technologies Inc (QTI) mobile chips.
 
+config RTL8186_IRQ
+   bool
+   depends on MACH_RTL8186
+   select IRQ_DOMAIN
+
 endmenu
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 15f268f646bf..2e0bb859a8f4 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -87,3 +87,4 @@ obj-$(CONFIG_MESON_IRQ_GPIO)  += irq-meson-gpio.o
 obj-$(CONFIG_GOLDFISH_PIC) += irq-goldfish-pic.o
 obj-$(CONFIG_NDS32)+= irq-ativic32.o
 obj-$(CONFIG_QCOM_PDC) += qcom-pdc.o
+obj-$(CONFIG_RTL8186_IRQ)  += irq-rtl8186.o
diff --git a/drivers/irqchip/irq-rtl8186.c b/drivers/irqchip/irq-rtl8186.c
new file mode 100644
index ..3eb6b947d5a0
--- /dev/null
+++ b/drivers/irqchip/irq-rtl8186.c
@@ -0,0 +1,107 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Realtek RTL8186 SoC interrupt controller driver.
+ *
+ * Copyright (C) 2018 Yasha Cherikovsky
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define RTL8186_NR_IRQS 11
+
+#define GIMR 0x00
+#define GISR 0x04
+
+static struct {
+   void __iomem *base;
+   struct irq_domain *domain;
+} intc;
+
+
+asmlinkage void plat_irq_dispatch(void)
+{
+   u32 hwirq, virq;
+   u32 gimr = readl(intc.base + GIMR);
+   u32 gisr = readl(intc.base + GISR);
+   u32 pending = gimr & gisr & ((1 << RTL8186_NR_IRQS) - 1);
+
+   if (!pending) {
+   spurious_interrupt();
+   return;
+   }
+
+   while (pending) {
+   hwirq = fls(pending) - 1;
+   virq = irq_linear_revmap(intc.domain, hwirq);
+   do_IRQ(virq);
+   pending &= ~BIT(hwirq);
+   }
+}
+
+static void rtl8186_irq_mask(struct irq_data *data)
+{
+   unsigned long irq = data->hwirq;
+
+   writel(readl(intc.base + GIMR) & (~(BIT(irq))), intc.base + GIMR);
+}
+
+static void rtl8186_irq_unmask(struct irq_data *data)
+{
+   unsigned long irq = data->hwirq;
+
+   writel((readl(intc.base + GIMR) | (BIT(irq))), intc.base + GIMR);
+}
+
+static struct irq_chip rtl8186_irq_chip = {
+   .name = "RTL8186",
+   .irq_mask = rtl8186_irq_mask,
+   .irq_unmask = rtl8186_irq_unmask,
+};
+
+static int rtl8186_intc_irq_domain_map(struct irq_domain *d, unsigned int virq,
+  irq_hw_number_t hw)
+{
+   irq_set_chip_and_handler(virq, &rtl8186_irq_chip, handle_level_irq);
+   return 0;
+}
+
+static const struct irq_domain_ops rtl8186_irq_ops = {
+   .map = rtl8186_intc_irq_domain_map,
+   .xlate = irq_domain_xlate_onecell,
+};
+
+static int __init rtl8186_intc_of_init(struct device_node *node,
+  struct device_node *parent)
+{
+   intc.base = of_io_request_and_map(node, 0, of_node_full_name(node));
+
+   if (IS_ERR(intc.base))
+   panic("%pOF: unable to map resource", node);
+
+   intc.domain = irq_domain_add_linear(node, RTL8186_NR_IRQS,
+   &rtl8186_irq_ops, NULL);
+
+   if (!intc.domain)
+   panic("%pOF: unable to create IRQ domain\n", node);
+
+   /* Start with all interrupts disabled */
+   writel(0, intc.base + GIMR);
+
+   /*
+* Enable all hardware interrupts in CP0 status register.
+* Software interrupts are disabled.
+*/
+   set_c0_status(ST0_IM);
+   clear_c0_status(STATUSF_IP0 | STATUSF_IP1);
+   clear_c0_cause(CAUSEF_IP);
+
+   return 0;
+}
+
+IRQCHIP_DECLARE(rtl8186_intc, "realtek,rtl8186-intc", rtl8186_intc_of_init);
-- 
2.19.0

Re: [PATCH v5 5/6] arm64/mm: Populate the swapper_pg_dir by fixmap.

[James Morse]

Hi Mark,

On 24/09/18 17:36, Mark Rutland wrote:
> On Mon, Sep 17, 2018 at 12:43:32PM +0800, Jun Yao wrote:
>> Since we will move the swapper_pg_dir to rodata section, we need a
>> way to update it. The fixmap can handle it. When the swapper_pg_dir
>> needs to be updated, we map it dynamically. The map will be
>> canceled after the update is complete. In this way, we can defend
>> against KSMA(Kernel Space Mirror Attack).

>> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
>> index 71532bcd76c1..a8a60927f716 100644
>> --- a/arch/arm64/mm/mmu.c
>> +++ b/arch/arm64/mm/mmu.c
>> @@ -67,6 +67,24 @@ static pte_t bm_pte[PTRS_PER_PTE] __page_aligned_bss;
>>  static pmd_t bm_pmd[PTRS_PER_PMD] __page_aligned_bss __maybe_unused;
>>  static pud_t bm_pud[PTRS_PER_PUD] __page_aligned_bss __maybe_unused;
>>  
>> +static DEFINE_SPINLOCK(swapper_pgdir_lock);
>> +
>> +void set_swapper_pgd(pgd_t *pgdp, pgd_t pgd)
>> +{
>> +pgd_t *fixmap_pgdp;
>> +
>> +spin_lock(&swapper_pgdir_lock);
>> +fixmap_pgdp = pgd_set_fixmap(__pa(pgdp));
>> +WRITE_ONCE(*fixmap_pgdp, pgd);
>> +/*
>> + * We need dsb(ishst) here to ensure the page-table-walker sees
>> + * our new entry before set_p?d() returns. The fixmap's
>> + * flush_tlb_kernel_range() via clear_fixmap() does this for us.
>> + */
>> +pgd_clear_fixmap();
>> +spin_unlock(&swapper_pgdir_lock);
>> +}
> 
> I'm rather worried that we could deadlock here.

We can use the irqsave versions if you're worried, but I think any code doing
this is already broken.

(I'd like to eventually depend on the init_mm.page_table_lock for this, but it
isn't held when the vmemmap is being populated.)


> Are we certain we never poke the kernel page tables in IRQ context?

The RAS code was doing this, but was deemed unsafe, and changed to use the
fixmap: https://lkml.org/lkml/2017/10/30/500
The fixmap only ever touches the last level, so can't hit this.

x86 can't do its IPI tlb-maintenance from IRQ context, so anything trying to
unmap from irq context is already broken: https://lkml.org/lkml/2018/9/6/324

vunmap()/vfree() is allowed from irq context, but it defers its work.

I can't find any way to pass GFP_ATOMIC into ioremap(),
I didn't think vmalloc() could either, ...  but now I spot __vmalloc() does...

This __vmalloc() path is used by the percpu allocator, which starting from
pcpu_alloc() can be passed something other than GFP_KERNEL, and uses
spin_lock_irqsave(), so it is expecting to be called in irq context.

... so yes it looks like this can happen.

I'll post a fix


Thanks!

James

Re: [PATCH 2/3] namei: implement AT_THIS_ROOT chroot-like path resolution

[Christian Brauner]

On Mon, Oct 01, 2018 at 03:44:28PM +1000, Aleksa Sarai wrote:
> On 2018-09-29, Jann Horn  wrote:
> > The problem is what happens if a folder you are walking through is
> > concurrently moved out of the chroot. Consider the following scenario:
> > 
> > You attempt to open "C/../../etc/passwd" under the root "/A/B".
> > Something else concurrently moves /A/B/C to /A/C. This can result in
> > the following:
> > 
> > 1. You start the path walk and reach /A/B/C.
> > 2. The other process moves /A/B/C to /A/C. Your path walk is now at /A/C.
> > 3. Your path walk follows the first ".." up into /A. This is outside
> > the process root, but you never actually encountered the process root,
> > so you don't notice.
> > 4. Your path walk follows the second ".." up to /. Again, this is
> > outside the process root, but you don't notice.
> > 5. Your path walk walks down to /etc/passwd, and the open completes
> > successfully. You now have an fd pointing outside your chroot.
> > 
> > If the root of your walk is below an attacker-controlled directory,
> > this of course means that you lose instantly. If you point the root of
> > the walk at a directory out of which a process in the container
> > wouldn't be able to move the file, you're probably kinda mostly fine -
> > as long as you know, for certain, that nothing else on the system
> > would ever do that. But I still wouldn't feel good about that.
> 
> Please correct me if I'm wrong here (this is the first patch I've
> written for VFS). Isn't the retry/LOOKUP_REVAL code meant to handle this
> -- or does that only handle if a particular path component changes
> *while* it's being walked through? Is it possible for a path walk to
> succeed after a path component was unmounted (obviously you can't delete
> a directory path component since you'd get -ENOTEMPTY)?
> 
> If this is an issue for AT_THIS_ROOT, I believe this might also be an
> issue for AT_BENEATH since they are effectively both using the same
> nd->root trick (so you could similarly trick AT_BENEATH to not error
> out). So we'd need to figure out how to solve this problem in order for
> AT_BENEATH to be safe.
> 
> Speaking naively, doesn't it make sense to invalidate the walk if a path
> component was modified? Or is this something that would be far too
> costly with little benefit? What if we do more aggressive nd->root
> checks when resolving with AT_BENEATH or AT_THIS_ROOT (or if nd->root !=
> current->mnt_ns->root)?
> 
> Regarding chroot attacks, I was aware of the trivial
> chroot-open-chroot-fchdir attack but I was not aware that there was a
> rename attack for chroot. Thanks for bringing this up!
> 
> > I believe that the only way to robustly use this would be to point the
> > dirfd at a mount point, such that you know that being moved out of the
> > chroot is impossible because the mount point limits movement of
> > directories under it. (Well, technically, it doesn't, but it ensures
> > that if a directory does dangerously move away, the syscall fails.) It
> > might make sense to hardcode this constraint in the implementation of
> > AT_THIS_ROOT, to keep people from shooting themselves in the foot.
> 
> Unless I'm missing something, would this not also affect using a
> mountpoint as a dirfd-root (with MS_MOVE of an already-walked-through
> path component) -- or does MS_MOVE cause a rewalk in a way that rename
> does not?
> 
> I wouldn't mind tying AT_THIS_ROOT to only work on mountpoints (I
> thought that bind-mounts would be an issue but you also get -EXDEV when
> trying to rename across bind-mounts even if they are on the same
> underlying filesystem). But AT_BENEATH might be a more bitter pill to
> swallow. I'm not sure.
> 
> In the usecase of container runtimes, we wouldn't generally be doing
> resolution of attacker-controlled paths but it still definitely doesn't
> hurt to consider this part of the threat model -- to avoid foot-gunning
> as you've said. (There also might be some nested-container cases where
> you might want to do that.)
> 
> > > Currently most container runtimes try to do this resolution in
> > > userspace[1], causing many potential race conditions. In addition, the
> > > "obvious" alternative (actually performing a {ch,pivot_}root(2))
> > > requires a fork+exec which is *very* costly if necessary for every
> > > filesystem operation involving a container.
> > 
> > Wait. fork() I understand, but why exec? And actually, you don't need
> > a full fork() either, clone() lets you do this with some process parts
> > shared. And then you also shouldn't need to use SCM_RIGHTS, just keep
> > the file descriptor table shared. And why chroot()/pivot_root(),
> > wouldn't you want to use setns()?
> 
> You're right about this -- for C runtimes. In Go we cannot do a raw
> clone() or fork() (if you do it manually with RawSyscall you'll end with
> broken runtime state). So you're forced to do fork+exec (which then
> means that you can't use CLONE_FILES and must use SCM_RIGHTS). Same goes
> for CLO

Re: [RESEND PATCH 0/2] Don't use SIGMINSTKSZ when enforcing alternative signal stack size for compat tasks

[Catalin Marinas]

On Fri, Sep 28, 2018 at 02:18:11PM +0100, Steve McIntyre wrote:
> On Wed, Sep 05, 2018 at 03:34:41PM +0100, Will Deacon wrote:
> >Hi all,
> >
> >This is a resend of:
> >
> >  http://lists.infradead.org/pipermail/linux-arm-kernel/2018-July/593559.html
> >
> >now based on 4.19-rc2.
> >
> >The Debian folks have observed a failure in the 32-bit arm glibc testsuite
> >when running under a 64-bit kernel. They tracked this down to sigaltstack(2)
> >enforcing the alternative signal stack to be at least SIGMINSTKSZ bytes,
> >which is higher for native arm64 tasks than compat 32-bit tasks.
> >
> >These patches resolve the issue by allowing an architecture to define
> >COMPAT_SIGMINSTKSZ for compat tasks, which is then used by the sigaltstack
> >checking code.
> >
> >Feedback welcome,
> 
> Apologies for the delayed response here - conference travel etc . got
> in the way... I've just tested and I can confirm that this patchset
> fixes our reported bug (as in https://bugs.debian.org/904385). Thanks
> Will!
> 
> Tested-by: Steve McIntyre <93...@debian.org>

Thanks for confirming Steve.

As there is no functional change for other architectures, I'll queue
both patches through the arm64 tree. If anyone objects, please let me
know before the merging window.

-- 
Catalin