Re: Linux 4.15-rc2: Regression in resume from ACPI S3

[Michal Hocko]

On Wed 06-12-17 13:14:52, Michal Hocko wrote:
> On Mon 04-12-17 14:36:20, Linus Torvalds wrote:
> > On Mon, Dec 4, 2017 at 2:25 PM, Rafael J. Wysocki  
> > wrote:
> > >
> > > So far, resume from suspend-to-RAM (ACPI S3) is broken on all of the
> > > systems I have tested, so it is probably safe to assume it to be
> > > broken everywhere.
> > 
> > Oh, it's definitely not broken everywhere, because I use it myself,
> > and was traveling last week due to my mom's bday.
> > 
> > HOWEVER.
> > 
> > Some of the x86 work seems to have broken it for some configurations.
> > In particular, do you have a big "everything enabled" kernel config -
> > particularly lockdep and irqflags tracing enabled?
> > 
> > Andy has a patch, but it hasn't made it to me yet (probably because
> > the x86 people are very busy with the kaiser work):
> > 
> > https://lkml.org/lkml/2017/11/30/546
> > 
> > (also note his follow-up "fix the commit message" note, but that one
> > doesn't actually affect the code itself).
> 
> merging tip/x86/urgent on top of your tree fixed this problem for me,
> but I am seeing something else
> [  131.711412] ACPI: Preparing to enter system sleep state S3
> [  131.755328] ACPI: EC: event blocked
> [  131.755328] ACPI: EC: EC stopped
> [  131.755328] PM: Saving platform NVS memory
> [  131.755344] Disabling non-boot CPUs ...
> [  131.779330] IRQ 124: no longer affine to CPU1
> [  131.780334] smpboot: CPU 1 is now offline
> [  131.804465] smpboot: CPU 2 is now offline
> [  131.827291] IRQ 122: no longer affine to CPU3
> [  131.827292] IRQ 123: no longer affine to CPU3
> [  131.828293] smpboot: CPU 3 is now offline
> [  131.830991] ACPI: Low-level resume complete
> [  131.831092] ACPI: EC: EC started
> [  131.831093] PM: Restoring platform NVS memory
> [  131.831864] do_IRQ: 0.55 No irq handler for vector
> [  131.831884] Enabling non-boot CPUs ...
> [  131.831909] x86: Booting SMP configuration:
> [  131.831910] smpboot: Booting Node 0 Processor 1 APIC 0x2
> [  131.832913]  cache: parent cpu1 should not be sleeping
> [  131.833058] CPU1 is up
> [  131.833067] smpboot: Booting Node 0 Processor 2 APIC 0x1
> [  131.833864]  cache: parent cpu2 should not be sleeping
> [  131.833983] CPU2 is up
> [  131.833995] smpboot: Booting Node 0 Processor 3 APIC 0x3
> [  131.834776]  cache: parent cpu3 should not be sleeping
> [  131.834923] CPU3 is up
> 
> "No irq handler" part looks a bit scary (maybe related to lost affinity
> messages?) but the following messages look quite as well. Is this
> something known? The system seems to be up and running without any
> visible issues.

Hmm, there is still something bad going on during resume. My laptop
haven't woken up from s2ram this morning. The screen was powered on
but the system hasn't come up.

The last thing that made it into the kernel log on fs is this

Dec  6 19:32:29 tiehlicka kernel: [21898.084685] PM: suspend entry (deep)

which won't tell us much I suspect. I've tried dozen s2ram cycles and it
hasn't reproduced so it smells like a timing issue.
-- 
Michal Hocko
SUSE Labs

Re: Linux 4.15-rc2: Regression in resume from ACPI S3

[Michal Hocko]

On Wed 06-12-17 13:14:52, Michal Hocko wrote:
> On Mon 04-12-17 14:36:20, Linus Torvalds wrote:
> > On Mon, Dec 4, 2017 at 2:25 PM, Rafael J. Wysocki  
> > wrote:
> > >
> > > So far, resume from suspend-to-RAM (ACPI S3) is broken on all of the
> > > systems I have tested, so it is probably safe to assume it to be
> > > broken everywhere.
> > 
> > Oh, it's definitely not broken everywhere, because I use it myself,
> > and was traveling last week due to my mom's bday.
> > 
> > HOWEVER.
> > 
> > Some of the x86 work seems to have broken it for some configurations.
> > In particular, do you have a big "everything enabled" kernel config -
> > particularly lockdep and irqflags tracing enabled?
> > 
> > Andy has a patch, but it hasn't made it to me yet (probably because
> > the x86 people are very busy with the kaiser work):
> > 
> > https://lkml.org/lkml/2017/11/30/546
> > 
> > (also note his follow-up "fix the commit message" note, but that one
> > doesn't actually affect the code itself).
> 
> merging tip/x86/urgent on top of your tree fixed this problem for me,
> but I am seeing something else
> [  131.711412] ACPI: Preparing to enter system sleep state S3
> [  131.755328] ACPI: EC: event blocked
> [  131.755328] ACPI: EC: EC stopped
> [  131.755328] PM: Saving platform NVS memory
> [  131.755344] Disabling non-boot CPUs ...
> [  131.779330] IRQ 124: no longer affine to CPU1
> [  131.780334] smpboot: CPU 1 is now offline
> [  131.804465] smpboot: CPU 2 is now offline
> [  131.827291] IRQ 122: no longer affine to CPU3
> [  131.827292] IRQ 123: no longer affine to CPU3
> [  131.828293] smpboot: CPU 3 is now offline
> [  131.830991] ACPI: Low-level resume complete
> [  131.831092] ACPI: EC: EC started
> [  131.831093] PM: Restoring platform NVS memory
> [  131.831864] do_IRQ: 0.55 No irq handler for vector
> [  131.831884] Enabling non-boot CPUs ...
> [  131.831909] x86: Booting SMP configuration:
> [  131.831910] smpboot: Booting Node 0 Processor 1 APIC 0x2
> [  131.832913]  cache: parent cpu1 should not be sleeping
> [  131.833058] CPU1 is up
> [  131.833067] smpboot: Booting Node 0 Processor 2 APIC 0x1
> [  131.833864]  cache: parent cpu2 should not be sleeping
> [  131.833983] CPU2 is up
> [  131.833995] smpboot: Booting Node 0 Processor 3 APIC 0x3
> [  131.834776]  cache: parent cpu3 should not be sleeping
> [  131.834923] CPU3 is up
> 
> "No irq handler" part looks a bit scary (maybe related to lost affinity
> messages?) but the following messages look quite as well. Is this
> something known? The system seems to be up and running without any
> visible issues.

Hmm, there is still something bad going on during resume. My laptop
haven't woken up from s2ram this morning. The screen was powered on
but the system hasn't come up.

The last thing that made it into the kernel log on fs is this

Dec  6 19:32:29 tiehlicka kernel: [21898.084685] PM: suspend entry (deep)

which won't tell us much I suspect. I've tried dozen s2ram cycles and it
hasn't reproduced so it smells like a timing issue.
-- 
Michal Hocko
SUSE Labs

Re: [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub

[Gary Lin]

On Thu, Dec 07, 2017 at 07:09:27AM +0100, Ingo Molnar wrote:
> 
> * Gary Lin  wrote:
> 
> > On Wed, Dec 06, 2017 at 07:37:34PM +0100, Ingo Molnar wrote:
> > > 
> > > * Gary Lin  wrote:
> > > 
> > > > On Tue, Dec 05, 2017 at 04:14:26PM -0500, Josh Boyer wrote:
> > > > > On Tue, Dec 5, 2017 at 5:01 AM, Gary Lin  wrote:
> > > > > > The series of patches introduce Security Version to EFI stub.
> > > > > >
> > > > > > Security Version is a monotonically increasing number and designed 
> > > > > > to
> > > > > > prevent the user from loading an insecure kernel accidentally. The
> > > > > > bootloader maintains a list of security versions corresponding to
> > > > > > different distributions. After fixing a critical vulnerability, the
> > > > > > distribution kernel maintainer bumps the "version", and the 
> > > > > > bootloader
> > > > > > updates the list automatically. When the user tries to load a kernel
> > > > > > with a lower security version, the bootloader shows a warning prompt
> > > > > > to notify the user the potential risk.
> > > > > 
> > > > > If a distribution releases a kernel with a higher security version and
> > > > > that it automatically updated on boot, what happens if that kernel
> > > > > contains a different bug that causes it to fail to boot or break
> > > > > critical functionality?  At that point, the user's machine would be in
> > > > > a state where the higher security version is enforced but the only
> > > > > kernel that provides that is broken.  Wouldn't that make a bad
> > > > > situation even worse by now requiring manual acceptance of the older
> > > > > SV kernel boot physically at the machine?
> > > > > 
> > > > > I feel like I'm missing a detail here or something.
> > > > > 
> > > > If the new kernel fails to boot, then the user has to choose the kernel
> > > > manually anyway, and there will be an option in the warning prompt to
> > > > lower SV.
> > > 
> > > And what if the firmware does not support a lowering of the SV?
> > > 
> > The SV list is manipulated by the bootloader, and the firmware only
> > provides the interface to the storage, i.e. non-volatile flash.
> 
> What about systems where the bootloader is part of the system and users only 
> have 
> the ability to provide kernel images, but no ability to change the boot 
> loader?
> 
It depends on how the bootloader works. If the system uses my
implementation of shim loader, it surely has the ability to lower SV,
but it requires physical access on purpose.

The Security Version check is a warning rather than a hard block like the
signature check. The current plan is to add an extra check in the shim
verify protocol, so that we can check SV right after the signature check.
I'm thinking about adding a UEFI variable to control the timeout of the
warning prompt, e.g. 30 for 30 seconds and 0 for waiting indefinitely,
so that the warning prompt won't block the system boot unless the system
administrator wants so.

As for other bootloaders, SV is just a few extra bytes in the kernel
image and means nothing to them.

Cheers,

Gary Lin

Re: [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub

[Gary Lin]

On Thu, Dec 07, 2017 at 07:09:27AM +0100, Ingo Molnar wrote:
> 
> * Gary Lin  wrote:
> 
> > On Wed, Dec 06, 2017 at 07:37:34PM +0100, Ingo Molnar wrote:
> > > 
> > > * Gary Lin  wrote:
> > > 
> > > > On Tue, Dec 05, 2017 at 04:14:26PM -0500, Josh Boyer wrote:
> > > > > On Tue, Dec 5, 2017 at 5:01 AM, Gary Lin  wrote:
> > > > > > The series of patches introduce Security Version to EFI stub.
> > > > > >
> > > > > > Security Version is a monotonically increasing number and designed 
> > > > > > to
> > > > > > prevent the user from loading an insecure kernel accidentally. The
> > > > > > bootloader maintains a list of security versions corresponding to
> > > > > > different distributions. After fixing a critical vulnerability, the
> > > > > > distribution kernel maintainer bumps the "version", and the 
> > > > > > bootloader
> > > > > > updates the list automatically. When the user tries to load a kernel
> > > > > > with a lower security version, the bootloader shows a warning prompt
> > > > > > to notify the user the potential risk.
> > > > > 
> > > > > If a distribution releases a kernel with a higher security version and
> > > > > that it automatically updated on boot, what happens if that kernel
> > > > > contains a different bug that causes it to fail to boot or break
> > > > > critical functionality?  At that point, the user's machine would be in
> > > > > a state where the higher security version is enforced but the only
> > > > > kernel that provides that is broken.  Wouldn't that make a bad
> > > > > situation even worse by now requiring manual acceptance of the older
> > > > > SV kernel boot physically at the machine?
> > > > > 
> > > > > I feel like I'm missing a detail here or something.
> > > > > 
> > > > If the new kernel fails to boot, then the user has to choose the kernel
> > > > manually anyway, and there will be an option in the warning prompt to
> > > > lower SV.
> > > 
> > > And what if the firmware does not support a lowering of the SV?
> > > 
> > The SV list is manipulated by the bootloader, and the firmware only
> > provides the interface to the storage, i.e. non-volatile flash.
> 
> What about systems where the bootloader is part of the system and users only 
> have 
> the ability to provide kernel images, but no ability to change the boot 
> loader?
> 
It depends on how the bootloader works. If the system uses my
implementation of shim loader, it surely has the ability to lower SV,
but it requires physical access on purpose.

The Security Version check is a warning rather than a hard block like the
signature check. The current plan is to add an extra check in the shim
verify protocol, so that we can check SV right after the signature check.
I'm thinking about adding a UEFI variable to control the timeout of the
warning prompt, e.g. 30 for 30 seconds and 0 for waiting indefinitely,
so that the warning prompt won't block the system boot unless the system
administrator wants so.

As for other bootloaders, SV is just a few extra bytes in the kernel
image and means nothing to them.

Cheers,

Gary Lin

Re: WARNING in x86_emulate_insn

[Wanpeng Li]

2017-12-07 15:49 GMT+08:00 蓝天宇 :
> Hi Dmitry:
>  I tried to reproduce the issue via syz-execprog with attached
> reproducer on latest linux-next but it causes VM-entry failure due to
> invalid guest state...

Because rflags is 0 in his program. You can set ept=0 and retry.

Regards,
Wanpeng Li

>
> 2017-12-07 14:25 GMT+08:00 Dmitry Vyukov :
>> On Thu, Dec 7, 2017 at 1:44 AM, Wanpeng Li  wrote:
>>> 2017-12-06 4:07 GMT+08:00 syzbot
>>> :
 Hello,

 syzkaller hit the following crash on
 fb20eb9d798d2f4c1a75b7fe981d72dfa8d7270d
 git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
 compiler: gcc (GCC) 7.1.1 20170620
 .config is attached
 Raw console output is attached.

 syzkaller reproducer is attached. See https://goo.gl/kgGztJ
 for information about syzkaller reproducers

>>>
>>> Is there a c program to reproduce?
>>
>> No, syzbot does not hide reproducers. See the referenced doc for
>> details: 
>> https://github.com/google/syzkaller/blob/master/docs/syzbot.md#syzkaller-reproducers
>>
>>
>>> Regards,
>>> Wanpeng Li
>>>

 kvm: KVM_SET_TSS_ADDR need to be called before entering vcpu
 WARNING: CPU: 1 PID: 3526 at arch/x86/kvm/emulate.c:5654
 x86_emulate_insn+0xd01/0x3cf0 arch/x86/kvm/emulate.c:5654
 Kernel panic - not syncing: panic_on_warn set ...

 CPU: 1 PID: 3526 Comm: syz-executor4 Not tainted 4.15.0-rc1-next-20171201+
 #57
 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
 Google 01/01/2011
 Call Trace:
  __dump_stack lib/dump_stack.c:17 [inline]
  dump_stack+0x194/0x257 lib/dump_stack.c:53
  panic+0x1e4/0x41c kernel/panic.c:183
  __warn+0x1dc/0x200 kernel/panic.c:547
  report_bug+0x211/0x2d0 lib/bug.c:184
  fixup_bug.part.11+0x37/0x80 arch/x86/kernel/traps.c:177
  fixup_bug arch/x86/kernel/traps.c:246 [inline]
  do_error_trap+0x2d7/0x3e0 arch/x86/kernel/traps.c:295
  do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:314
  invalid_op+0x22/0x40 arch/x86/entry/entry_64.S:1066
 RIP: 0010:x86_emulate_insn+0xd01/0x3cf0 arch/x86/kvm/emulate.c:5654
 RSP: 0018:8801d0fff3e8 EFLAGS: 00010293
 RAX: 8801d17b60c0 RBX: 11003a1ffe86 RCX: 81154351
 RDX:  RSI:  RDI: 8801d0b5b5c8
 RBP: 8801d0fff4f8 R08: 8801d0b58d80 R09: 85224da0
 R10: 0001 R11: ed003a16b6d4 R12: 00ff
 R13: 8801d0b5b5a0 R14: 0002 R15: 8801d0b5b6c3
  x86_emulate_instruction+0x411/0x1ad0 arch/x86/kvm/x86.c:5771
  emulate_instruction arch/x86/include/asm/kvm_host.h:1164 [inline]
  complete_emulated_io arch/x86/kvm/x86.c:7190 [inline]
  complete_emulated_pio+0xdd/0x1b0 arch/x86/kvm/x86.c:7201
  kvm_arch_vcpu_ioctl_run+0x2db2/0x5c60 arch/x86/kvm/x86.c:7305
  kvm_vcpu_ioctl+0x64c/0x1010 arch/x86/kvm/../../../virt/kvm/kvm_main.c:2574
  vfs_ioctl fs/ioctl.c:46 [inline]
  do_vfs_ioctl+0x1b1/0x1530 fs/ioctl.c:686
  SYSC_ioctl fs/ioctl.c:701 [inline]
  SyS_ioctl+0x8f/0xc0 fs/ioctl.c:692
  entry_SYSCALL_64_fastpath+0x1f/0x96
 RIP: 0033:0x4529d9
 RSP: 002b:7f6b6b2d5c58 EFLAGS: 0212 ORIG_RAX: 0010
 RAX: ffda RBX: 00758020 RCX: 004529d9
 RDX:  RSI: ae80 RDI: 0004
 RBP: 039b R08:  R09: 
 R10:  R11: 0212 R12: 006f2728
 R13:  R14: 7f6b6b2d66d4 R15: 
 Dumping ftrace buffer:
(ftrace buffer empty)
 Kernel Offset: disabled
 Rebooting in 86400 seconds..


 ---
 This bug is generated by a dumb bot. It may contain errors.
 See https://goo.gl/tpsmEJ for details.
 Direct all questions to syzkal...@googlegroups.com.
 Please credit me with: Reported-by: syzbot 

 syzbot will keep track of this bug report.
 Once a fix for this bug is committed, please reply to this email with:
 #syz fix: exact-commit-title
 If you want to test a patch for this bug, please reply with:
 #syz test: git://repo/address.git branch
 and provide the patch inline or as an attachment.
 To mark this as a duplicate of another syzbot report, please reply with:
 #syz dup: exact-subject-of-another-report
 If it's a one-off invalid bug report, please reply with:
 #syz invalid
 Note: if the crash happens again, it will cause creation of a new bug
 report.
 Note: all commands must start from beginning of the line in the email body.
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups 
>>> "syzkaller-bugs" group.
>>> To 

Re: WARNING in x86_emulate_insn

[Wanpeng Li]

2017-12-07 15:49 GMT+08:00 蓝天宇 :
> Hi Dmitry:
>  I tried to reproduce the issue via syz-execprog with attached
> reproducer on latest linux-next but it causes VM-entry failure due to
> invalid guest state...

Because rflags is 0 in his program. You can set ept=0 and retry.

Regards,
Wanpeng Li

>
> 2017-12-07 14:25 GMT+08:00 Dmitry Vyukov :
>> On Thu, Dec 7, 2017 at 1:44 AM, Wanpeng Li  wrote:
>>> 2017-12-06 4:07 GMT+08:00 syzbot
>>> :
 Hello,

 syzkaller hit the following crash on
 fb20eb9d798d2f4c1a75b7fe981d72dfa8d7270d
 git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
 compiler: gcc (GCC) 7.1.1 20170620
 .config is attached
 Raw console output is attached.

 syzkaller reproducer is attached. See https://goo.gl/kgGztJ
 for information about syzkaller reproducers

>>>
>>> Is there a c program to reproduce?
>>
>> No, syzbot does not hide reproducers. See the referenced doc for
>> details: 
>> https://github.com/google/syzkaller/blob/master/docs/syzbot.md#syzkaller-reproducers
>>
>>
>>> Regards,
>>> Wanpeng Li
>>>

 kvm: KVM_SET_TSS_ADDR need to be called before entering vcpu
 WARNING: CPU: 1 PID: 3526 at arch/x86/kvm/emulate.c:5654
 x86_emulate_insn+0xd01/0x3cf0 arch/x86/kvm/emulate.c:5654
 Kernel panic - not syncing: panic_on_warn set ...

 CPU: 1 PID: 3526 Comm: syz-executor4 Not tainted 4.15.0-rc1-next-20171201+
 #57
 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
 Google 01/01/2011
 Call Trace:
  __dump_stack lib/dump_stack.c:17 [inline]
  dump_stack+0x194/0x257 lib/dump_stack.c:53
  panic+0x1e4/0x41c kernel/panic.c:183
  __warn+0x1dc/0x200 kernel/panic.c:547
  report_bug+0x211/0x2d0 lib/bug.c:184
  fixup_bug.part.11+0x37/0x80 arch/x86/kernel/traps.c:177
  fixup_bug arch/x86/kernel/traps.c:246 [inline]
  do_error_trap+0x2d7/0x3e0 arch/x86/kernel/traps.c:295
  do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:314
  invalid_op+0x22/0x40 arch/x86/entry/entry_64.S:1066
 RIP: 0010:x86_emulate_insn+0xd01/0x3cf0 arch/x86/kvm/emulate.c:5654
 RSP: 0018:8801d0fff3e8 EFLAGS: 00010293
 RAX: 8801d17b60c0 RBX: 11003a1ffe86 RCX: 81154351
 RDX:  RSI:  RDI: 8801d0b5b5c8
 RBP: 8801d0fff4f8 R08: 8801d0b58d80 R09: 85224da0
 R10: 0001 R11: ed003a16b6d4 R12: 00ff
 R13: 8801d0b5b5a0 R14: 0002 R15: 8801d0b5b6c3
  x86_emulate_instruction+0x411/0x1ad0 arch/x86/kvm/x86.c:5771
  emulate_instruction arch/x86/include/asm/kvm_host.h:1164 [inline]
  complete_emulated_io arch/x86/kvm/x86.c:7190 [inline]
  complete_emulated_pio+0xdd/0x1b0 arch/x86/kvm/x86.c:7201
  kvm_arch_vcpu_ioctl_run+0x2db2/0x5c60 arch/x86/kvm/x86.c:7305
  kvm_vcpu_ioctl+0x64c/0x1010 arch/x86/kvm/../../../virt/kvm/kvm_main.c:2574
  vfs_ioctl fs/ioctl.c:46 [inline]
  do_vfs_ioctl+0x1b1/0x1530 fs/ioctl.c:686
  SYSC_ioctl fs/ioctl.c:701 [inline]
  SyS_ioctl+0x8f/0xc0 fs/ioctl.c:692
  entry_SYSCALL_64_fastpath+0x1f/0x96
 RIP: 0033:0x4529d9
 RSP: 002b:7f6b6b2d5c58 EFLAGS: 0212 ORIG_RAX: 0010
 RAX: ffda RBX: 00758020 RCX: 004529d9
 RDX:  RSI: ae80 RDI: 0004
 RBP: 039b R08:  R09: 
 R10:  R11: 0212 R12: 006f2728
 R13:  R14: 7f6b6b2d66d4 R15: 
 Dumping ftrace buffer:
(ftrace buffer empty)
 Kernel Offset: disabled
 Rebooting in 86400 seconds..


 ---
 This bug is generated by a dumb bot. It may contain errors.
 See https://goo.gl/tpsmEJ for details.
 Direct all questions to syzkal...@googlegroups.com.
 Please credit me with: Reported-by: syzbot 

 syzbot will keep track of this bug report.
 Once a fix for this bug is committed, please reply to this email with:
 #syz fix: exact-commit-title
 If you want to test a patch for this bug, please reply with:
 #syz test: git://repo/address.git branch
 and provide the patch inline or as an attachment.
 To mark this as a duplicate of another syzbot report, please reply with:
 #syz dup: exact-subject-of-another-report
 If it's a one-off invalid bug report, please reply with:
 #syz invalid
 Note: if the crash happens again, it will cause creation of a new bug
 report.
 Note: all commands must start from beginning of the line in the email body.
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups 
>>> "syzkaller-bugs" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an 
>>> email to syzkaller-bugs+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit 

Re: WARNING in x86_emulate_insn

[蓝天宇]

Hi Dmitry:
 I tried to reproduce the issue via syz-execprog with attached
reproducer on latest linux-next but it causes VM-entry failure due to
invalid guest state...

2017-12-07 14:25 GMT+08:00 Dmitry Vyukov :
> On Thu, Dec 7, 2017 at 1:44 AM, Wanpeng Li  wrote:
>> 2017-12-06 4:07 GMT+08:00 syzbot
>> :
>>> Hello,
>>>
>>> syzkaller hit the following crash on
>>> fb20eb9d798d2f4c1a75b7fe981d72dfa8d7270d
>>> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
>>> compiler: gcc (GCC) 7.1.1 20170620
>>> .config is attached
>>> Raw console output is attached.
>>>
>>> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
>>> for information about syzkaller reproducers
>>>
>>
>> Is there a c program to reproduce?
>
> No, syzbot does not hide reproducers. See the referenced doc for
> details: 
> https://github.com/google/syzkaller/blob/master/docs/syzbot.md#syzkaller-reproducers
>
>
>> Regards,
>> Wanpeng Li
>>
>>>
>>> kvm: KVM_SET_TSS_ADDR need to be called before entering vcpu
>>> WARNING: CPU: 1 PID: 3526 at arch/x86/kvm/emulate.c:5654
>>> x86_emulate_insn+0xd01/0x3cf0 arch/x86/kvm/emulate.c:5654
>>> Kernel panic - not syncing: panic_on_warn set ...
>>>
>>> CPU: 1 PID: 3526 Comm: syz-executor4 Not tainted 4.15.0-rc1-next-20171201+
>>> #57
>>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
>>> Google 01/01/2011
>>> Call Trace:
>>>  __dump_stack lib/dump_stack.c:17 [inline]
>>>  dump_stack+0x194/0x257 lib/dump_stack.c:53
>>>  panic+0x1e4/0x41c kernel/panic.c:183
>>>  __warn+0x1dc/0x200 kernel/panic.c:547
>>>  report_bug+0x211/0x2d0 lib/bug.c:184
>>>  fixup_bug.part.11+0x37/0x80 arch/x86/kernel/traps.c:177
>>>  fixup_bug arch/x86/kernel/traps.c:246 [inline]
>>>  do_error_trap+0x2d7/0x3e0 arch/x86/kernel/traps.c:295
>>>  do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:314
>>>  invalid_op+0x22/0x40 arch/x86/entry/entry_64.S:1066
>>> RIP: 0010:x86_emulate_insn+0xd01/0x3cf0 arch/x86/kvm/emulate.c:5654
>>> RSP: 0018:8801d0fff3e8 EFLAGS: 00010293
>>> RAX: 8801d17b60c0 RBX: 11003a1ffe86 RCX: 81154351
>>> RDX:  RSI:  RDI: 8801d0b5b5c8
>>> RBP: 8801d0fff4f8 R08: 8801d0b58d80 R09: 85224da0
>>> R10: 0001 R11: ed003a16b6d4 R12: 00ff
>>> R13: 8801d0b5b5a0 R14: 0002 R15: 8801d0b5b6c3
>>>  x86_emulate_instruction+0x411/0x1ad0 arch/x86/kvm/x86.c:5771
>>>  emulate_instruction arch/x86/include/asm/kvm_host.h:1164 [inline]
>>>  complete_emulated_io arch/x86/kvm/x86.c:7190 [inline]
>>>  complete_emulated_pio+0xdd/0x1b0 arch/x86/kvm/x86.c:7201
>>>  kvm_arch_vcpu_ioctl_run+0x2db2/0x5c60 arch/x86/kvm/x86.c:7305
>>>  kvm_vcpu_ioctl+0x64c/0x1010 arch/x86/kvm/../../../virt/kvm/kvm_main.c:2574
>>>  vfs_ioctl fs/ioctl.c:46 [inline]
>>>  do_vfs_ioctl+0x1b1/0x1530 fs/ioctl.c:686
>>>  SYSC_ioctl fs/ioctl.c:701 [inline]
>>>  SyS_ioctl+0x8f/0xc0 fs/ioctl.c:692
>>>  entry_SYSCALL_64_fastpath+0x1f/0x96
>>> RIP: 0033:0x4529d9
>>> RSP: 002b:7f6b6b2d5c58 EFLAGS: 0212 ORIG_RAX: 0010
>>> RAX: ffda RBX: 00758020 RCX: 004529d9
>>> RDX:  RSI: ae80 RDI: 0004
>>> RBP: 039b R08:  R09: 
>>> R10:  R11: 0212 R12: 006f2728
>>> R13:  R14: 7f6b6b2d66d4 R15: 
>>> Dumping ftrace buffer:
>>>(ftrace buffer empty)
>>> Kernel Offset: disabled
>>> Rebooting in 86400 seconds..
>>>
>>>
>>> ---
>>> This bug is generated by a dumb bot. It may contain errors.
>>> See https://goo.gl/tpsmEJ for details.
>>> Direct all questions to syzkal...@googlegroups.com.
>>> Please credit me with: Reported-by: syzbot 
>>>
>>> syzbot will keep track of this bug report.
>>> Once a fix for this bug is committed, please reply to this email with:
>>> #syz fix: exact-commit-title
>>> If you want to test a patch for this bug, please reply with:
>>> #syz test: git://repo/address.git branch
>>> and provide the patch inline or as an attachment.
>>> To mark this as a duplicate of another syzbot report, please reply with:
>>> #syz dup: exact-subject-of-another-report
>>> If it's a one-off invalid bug report, please reply with:
>>> #syz invalid
>>> Note: if the crash happens again, it will cause creation of a new bug
>>> report.
>>> Note: all commands must start from beginning of the line in the email body.
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "syzkaller-bugs" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to syzkaller-bugs+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit 
>> 

Re: [PATCH 4.14 00/95] 4.14.4-stable review

[Greg Kroah-Hartman]

On Wed, Dec 06, 2017 at 12:01:04PM -0600, Tom Gall wrote:
> 
> 
> > On Dec 6, 2017, at 12:49 AM, Greg Kroah-Hartman 
> >  wrote:
> > 
> > On Tue, Dec 05, 2017 at 03:45:07PM -0600, Tom Gall wrote:
> >> 
> >> 
> >>> On Dec 5, 2017, at 12:24 AM, Greg Kroah-Hartman 
> >>>  wrote:
> >>> 
> >>> On Mon, Dec 04, 2017 at 03:12:45PM -0600, Tom Gall wrote:
>  
>  
> > On Dec 4, 2017, at 9:59 AM, Greg Kroah-Hartman 
> >  wrote:
> > 
> > This is the start of the stable review cycle for the 4.14.4 release.
> > There are 95 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Wed Dec  6 16:00:27 UTC 2017.
> > Anything received after that time might be too late.
> > 
> > The whole patch series can be found in one patch at:
> > 
> > kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.4-rc1.gz
> > or in the git tree and branch at:
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> >  linux-4.14.y
> > and the diffstat can be found below.
> > 
> > thanks,
> > 
> > greg k-h
> > 
>  
>  Compiled, booted and ran the following package unit tests without 
>  regressions on x86_64
>  
>  boringssl : 
>   go test target:0/0/5764/5764/5764 PASS
>   ssl_test : 10 pass
>   crypto_test : 28 pass
>  e2fsprogs:
>   make check : 340 pass
>  sqlite
>   make test : 143914 pass
>  drm
>   make check : 15 pass
>   modetest, drmdevice : pass
>  alsa-lib
>   make check : 2 pass
>  bluez
>   make check : 25 pass
>  libusb
>   stress : 4 pass
> >>> 
> >>> How do the above tests stress the kernel?
> >> 
> >> Depends entirely on the package in question.
> >> 
> >> Sure, of completely no surprise a lot of package unit tests don’t really 
> >> do much that’s particularly interesting save to the package itself.
> > 
> > Then why run those tests?  Like sqlite, what kernel functionality does
> > that exercise that ltp does not?
> 
> Simply it beats on the system. 

There are "real" stress tests you could run if you want to do that.  But
I thought you all had a hard time keeping your boards alive, are you
sure you want to stress them?  :)

> >> There are sometimes an interesting subset that drives some amount of work 
> >> in kernel. 
> >> That’s the useful stuff.
> > 
> > Is that true with the above list?  If so, why are those types of tests
> > not part of any kernel test suite that I have seen before?
> 
> Dunno. Can’t comment on the non-action by others. What we can do is either
> harvest (by adding to say LTP) or improve in the 

I can not parse this sentence :(

> > You are testing past regressions of the userspace code, not the kernel
> > here.  Why do I care about that?  :)
> 
> Like you, I only care things that are testing the kernel. I’m lazy.  I’m not
> chopping out the things that go far afield, besides it’s not broken nor is it
> hurting anything.

Are you sure these are "testing" the kernel in any other way than the
existing tests you are running are?  Randomly running various userspace
programs is not really a good judge of kernel functionality coverage.

> > Don't fall down the trap of running code for the sake of running code
> > (i.e. like that web site that starts with a P) that doesn't actually
> > test anything that actually matters.
> 
> Yup entirely agree. No emerge world going on here. 8-b

'emerge world' is a wonderful test for a compiler, don't knock it, it's
found loads of bugs in the past.

But we aren't testing the compiler, we want to test the kernel, and
really, I don't think the things you ran (with maybe the exception of
the bluez test), do anything more than 'emerge world' would do :)

Why not work to incorporate one of the many tests that we already know
_do_ test different kernel functionality that you are not running before
adding random tests that no one really knows do anything at all?

thanks,

greg k-h

Re: WARNING in x86_emulate_insn

[蓝天宇]

Hi Dmitry:
 I tried to reproduce the issue via syz-execprog with attached
reproducer on latest linux-next but it causes VM-entry failure due to
invalid guest state...

2017-12-07 14:25 GMT+08:00 Dmitry Vyukov :
> On Thu, Dec 7, 2017 at 1:44 AM, Wanpeng Li  wrote:
>> 2017-12-06 4:07 GMT+08:00 syzbot
>> :
>>> Hello,
>>>
>>> syzkaller hit the following crash on
>>> fb20eb9d798d2f4c1a75b7fe981d72dfa8d7270d
>>> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
>>> compiler: gcc (GCC) 7.1.1 20170620
>>> .config is attached
>>> Raw console output is attached.
>>>
>>> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
>>> for information about syzkaller reproducers
>>>
>>
>> Is there a c program to reproduce?
>
> No, syzbot does not hide reproducers. See the referenced doc for
> details: 
> https://github.com/google/syzkaller/blob/master/docs/syzbot.md#syzkaller-reproducers
>
>
>> Regards,
>> Wanpeng Li
>>
>>>
>>> kvm: KVM_SET_TSS_ADDR need to be called before entering vcpu
>>> WARNING: CPU: 1 PID: 3526 at arch/x86/kvm/emulate.c:5654
>>> x86_emulate_insn+0xd01/0x3cf0 arch/x86/kvm/emulate.c:5654
>>> Kernel panic - not syncing: panic_on_warn set ...
>>>
>>> CPU: 1 PID: 3526 Comm: syz-executor4 Not tainted 4.15.0-rc1-next-20171201+
>>> #57
>>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
>>> Google 01/01/2011
>>> Call Trace:
>>>  __dump_stack lib/dump_stack.c:17 [inline]
>>>  dump_stack+0x194/0x257 lib/dump_stack.c:53
>>>  panic+0x1e4/0x41c kernel/panic.c:183
>>>  __warn+0x1dc/0x200 kernel/panic.c:547
>>>  report_bug+0x211/0x2d0 lib/bug.c:184
>>>  fixup_bug.part.11+0x37/0x80 arch/x86/kernel/traps.c:177
>>>  fixup_bug arch/x86/kernel/traps.c:246 [inline]
>>>  do_error_trap+0x2d7/0x3e0 arch/x86/kernel/traps.c:295
>>>  do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:314
>>>  invalid_op+0x22/0x40 arch/x86/entry/entry_64.S:1066
>>> RIP: 0010:x86_emulate_insn+0xd01/0x3cf0 arch/x86/kvm/emulate.c:5654
>>> RSP: 0018:8801d0fff3e8 EFLAGS: 00010293
>>> RAX: 8801d17b60c0 RBX: 11003a1ffe86 RCX: 81154351
>>> RDX:  RSI:  RDI: 8801d0b5b5c8
>>> RBP: 8801d0fff4f8 R08: 8801d0b58d80 R09: 85224da0
>>> R10: 0001 R11: ed003a16b6d4 R12: 00ff
>>> R13: 8801d0b5b5a0 R14: 0002 R15: 8801d0b5b6c3
>>>  x86_emulate_instruction+0x411/0x1ad0 arch/x86/kvm/x86.c:5771
>>>  emulate_instruction arch/x86/include/asm/kvm_host.h:1164 [inline]
>>>  complete_emulated_io arch/x86/kvm/x86.c:7190 [inline]
>>>  complete_emulated_pio+0xdd/0x1b0 arch/x86/kvm/x86.c:7201
>>>  kvm_arch_vcpu_ioctl_run+0x2db2/0x5c60 arch/x86/kvm/x86.c:7305
>>>  kvm_vcpu_ioctl+0x64c/0x1010 arch/x86/kvm/../../../virt/kvm/kvm_main.c:2574
>>>  vfs_ioctl fs/ioctl.c:46 [inline]
>>>  do_vfs_ioctl+0x1b1/0x1530 fs/ioctl.c:686
>>>  SYSC_ioctl fs/ioctl.c:701 [inline]
>>>  SyS_ioctl+0x8f/0xc0 fs/ioctl.c:692
>>>  entry_SYSCALL_64_fastpath+0x1f/0x96
>>> RIP: 0033:0x4529d9
>>> RSP: 002b:7f6b6b2d5c58 EFLAGS: 0212 ORIG_RAX: 0010
>>> RAX: ffda RBX: 00758020 RCX: 004529d9
>>> RDX:  RSI: ae80 RDI: 0004
>>> RBP: 039b R08:  R09: 
>>> R10:  R11: 0212 R12: 006f2728
>>> R13:  R14: 7f6b6b2d66d4 R15: 
>>> Dumping ftrace buffer:
>>>(ftrace buffer empty)
>>> Kernel Offset: disabled
>>> Rebooting in 86400 seconds..
>>>
>>>
>>> ---
>>> This bug is generated by a dumb bot. It may contain errors.
>>> See https://goo.gl/tpsmEJ for details.
>>> Direct all questions to syzkal...@googlegroups.com.
>>> Please credit me with: Reported-by: syzbot 
>>>
>>> syzbot will keep track of this bug report.
>>> Once a fix for this bug is committed, please reply to this email with:
>>> #syz fix: exact-commit-title
>>> If you want to test a patch for this bug, please reply with:
>>> #syz test: git://repo/address.git branch
>>> and provide the patch inline or as an attachment.
>>> To mark this as a duplicate of another syzbot report, please reply with:
>>> #syz dup: exact-subject-of-another-report
>>> If it's a one-off invalid bug report, please reply with:
>>> #syz invalid
>>> Note: if the crash happens again, it will cause creation of a new bug
>>> report.
>>> Note: all commands must start from beginning of the line in the email body.
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "syzkaller-bugs" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to syzkaller-bugs+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/syzkaller-bugs/CANRm%2BCw6u-Tvq6M%2B8hFm9UmxyTWsqvrm5L9bzfoTAvEsaeC1-w%40mail.gmail.com.
>> For more options, visit https://groups.google.com/d/optout.



-- 
Best regards
Tianyu Lan

Re: [PATCH 4.14 00/95] 4.14.4-stable review

[Greg Kroah-Hartman]

On Wed, Dec 06, 2017 at 12:01:04PM -0600, Tom Gall wrote:
> 
> 
> > On Dec 6, 2017, at 12:49 AM, Greg Kroah-Hartman 
> >  wrote:
> > 
> > On Tue, Dec 05, 2017 at 03:45:07PM -0600, Tom Gall wrote:
> >> 
> >> 
> >>> On Dec 5, 2017, at 12:24 AM, Greg Kroah-Hartman 
> >>>  wrote:
> >>> 
> >>> On Mon, Dec 04, 2017 at 03:12:45PM -0600, Tom Gall wrote:
>  
>  
> > On Dec 4, 2017, at 9:59 AM, Greg Kroah-Hartman 
> >  wrote:
> > 
> > This is the start of the stable review cycle for the 4.14.4 release.
> > There are 95 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Wed Dec  6 16:00:27 UTC 2017.
> > Anything received after that time might be too late.
> > 
> > The whole patch series can be found in one patch at:
> > 
> > kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.4-rc1.gz
> > or in the git tree and branch at:
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> >  linux-4.14.y
> > and the diffstat can be found below.
> > 
> > thanks,
> > 
> > greg k-h
> > 
>  
>  Compiled, booted and ran the following package unit tests without 
>  regressions on x86_64
>  
>  boringssl : 
>   go test target:0/0/5764/5764/5764 PASS
>   ssl_test : 10 pass
>   crypto_test : 28 pass
>  e2fsprogs:
>   make check : 340 pass
>  sqlite
>   make test : 143914 pass
>  drm
>   make check : 15 pass
>   modetest, drmdevice : pass
>  alsa-lib
>   make check : 2 pass
>  bluez
>   make check : 25 pass
>  libusb
>   stress : 4 pass
> >>> 
> >>> How do the above tests stress the kernel?
> >> 
> >> Depends entirely on the package in question.
> >> 
> >> Sure, of completely no surprise a lot of package unit tests don’t really 
> >> do much that’s particularly interesting save to the package itself.
> > 
> > Then why run those tests?  Like sqlite, what kernel functionality does
> > that exercise that ltp does not?
> 
> Simply it beats on the system. 

There are "real" stress tests you could run if you want to do that.  But
I thought you all had a hard time keeping your boards alive, are you
sure you want to stress them?  :)

> >> There are sometimes an interesting subset that drives some amount of work 
> >> in kernel. 
> >> That’s the useful stuff.
> > 
> > Is that true with the above list?  If so, why are those types of tests
> > not part of any kernel test suite that I have seen before?
> 
> Dunno. Can’t comment on the non-action by others. What we can do is either
> harvest (by adding to say LTP) or improve in the 

I can not parse this sentence :(

> > You are testing past regressions of the userspace code, not the kernel
> > here.  Why do I care about that?  :)
> 
> Like you, I only care things that are testing the kernel. I’m lazy.  I’m not
> chopping out the things that go far afield, besides it’s not broken nor is it
> hurting anything.

Are you sure these are "testing" the kernel in any other way than the
existing tests you are running are?  Randomly running various userspace
programs is not really a good judge of kernel functionality coverage.

> > Don't fall down the trap of running code for the sake of running code
> > (i.e. like that web site that starts with a P) that doesn't actually
> > test anything that actually matters.
> 
> Yup entirely agree. No emerge world going on here. 8-b

'emerge world' is a wonderful test for a compiler, don't knock it, it's
found loads of bugs in the past.

But we aren't testing the compiler, we want to test the kernel, and
really, I don't think the things you ran (with maybe the exception of
the bluez test), do anything more than 'emerge world' would do :)

Why not work to incorporate one of the many tests that we already know
_do_ test different kernel functionality that you are not running before
adding random tests that no one really knows do anything at all?

thanks,

greg k-h

[PATCH 1/1] codestyle issue fixed drivers/staging/vc04_services

[Mikhail Shvetsov]

From: Mike 

Signed-off-by: Mike 
---
 .../interface/vchiq_arm/vchiq_kern_lib.c   | 64 --
 1 file changed, 35 insertions(+), 29 deletions(-)

diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_kern_lib.c 
b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_kern_lib.c
index 34f746db19cd..d21bb154f78c 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_kern_lib.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_kern_lib.c
@@ -65,10 +65,10 @@ vchiq_blocking_bulk_transfer(VCHIQ_SERVICE_HANDLE_T handle, 
void *data,
unsigned int size, VCHIQ_BULK_DIR_T dir);
 
 /
-*
-*   vchiq_initialise
-*
-***/
+ *
+ *   vchiq_initialise
+ *
+ ***/
 #define VCHIQ_INIT_RETRIES 10
 VCHIQ_STATUS_T vchiq_initialise(VCHIQ_INSTANCE_T *instance_out)
 {
@@ -80,7 +80,9 @@ VCHIQ_STATUS_T vchiq_initialise(VCHIQ_INSTANCE_T 
*instance_out)
vchiq_log_trace(vchiq_core_log_level, "%s called", __func__);
 
/* VideoCore may not be ready due to boot up timing.
-  It may never be ready if kernel and firmware are mismatched, so 
don't block forever. */
+* It may never be ready if kernel and firmware are mismatched, so don't
+* block forever.
+*/
for (i = 0; i < VCHIQ_INIT_RETRIES; i++) {
state = vchiq_get_state();
if (state)
@@ -93,7 +95,8 @@ VCHIQ_STATUS_T vchiq_initialise(VCHIQ_INSTANCE_T 
*instance_out)
goto failed;
} else if (i > 0) {
vchiq_log_warning(vchiq_core_log_level,
-   "%s: videocore initialized after %d retries\n", 
__func__, i);
+   "%s: videocore initialized after %d retries\n",
+   __func__, i);
}
 
instance = kzalloc(sizeof(*instance), GFP_KERNEL);
@@ -121,10 +124,10 @@ VCHIQ_STATUS_T vchiq_initialise(VCHIQ_INSTANCE_T 
*instance_out)
 EXPORT_SYMBOL(vchiq_initialise);
 
 /
-*
-*   vchiq_shutdown
-*
-***/
+ *
+ *   vchiq_shutdown
+ *
+ ***/
 
 VCHIQ_STATUS_T vchiq_shutdown(VCHIQ_INSTANCE_T instance)
 {
@@ -169,10 +172,10 @@ VCHIQ_STATUS_T vchiq_shutdown(VCHIQ_INSTANCE_T instance)
 EXPORT_SYMBOL(vchiq_shutdown);
 
 /
-*
-*   vchiq_is_connected
-*
-***/
+ *
+ *   vchiq_is_connected
+ *
+ ***/
 
 static int vchiq_is_connected(VCHIQ_INSTANCE_T instance)
 {
@@ -180,10 +183,10 @@ static int vchiq_is_connected(VCHIQ_INSTANCE_T instance)
 }
 
 /
-*
-*   vchiq_connect
-*
-***/
+ *
+ *   vchiq_connect
+ *
+ ***/
 
 VCHIQ_STATUS_T vchiq_connect(VCHIQ_INSTANCE_T instance)
 {
@@ -215,10 +218,10 @@ VCHIQ_STATUS_T vchiq_connect(VCHIQ_INSTANCE_T instance)
 EXPORT_SYMBOL(vchiq_connect);
 
 /
-*
-*   vchiq_add_service
-*
-***/
+ *
+ *   vchiq_add_service
+ *
+ ***/
 
 VCHIQ_STATUS_T vchiq_add_service(
VCHIQ_INSTANCE_T  instance,
@@ -260,10 +263,10 @@ VCHIQ_STATUS_T vchiq_add_service(
 EXPORT_SYMBOL(vchiq_add_service);
 
 /
-*
-*   vchiq_open_service
-*
-***/
+ *
+ *   vchiq_open_service
+ *
+ ***/
 
 VCHIQ_STATUS_T vchiq_open_service(
VCHIQ_INSTANCE_T  instance,
@@ -414,8 +417,9 @@ vchiq_blocking_bulk_transfer(VCHIQ_SERVICE_HANDLE_T handle, 
void *data,
if ((bulk->data != data) ||
(bulk->size != size)) {
/* This is not a retry of the previous one.
-   ** Cancel the signal when the transfer
-   ** completes. */
+* Cancel the signal when the transfer
+* completes.
+ 

[PATCH 1/1] codestyle issue fixed drivers/staging/vc04_services

[Mikhail Shvetsov]

From: Mike 

Signed-off-by: Mike 
---
 .../interface/vchiq_arm/vchiq_kern_lib.c   | 64 --
 1 file changed, 35 insertions(+), 29 deletions(-)

diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_kern_lib.c 
b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_kern_lib.c
index 34f746db19cd..d21bb154f78c 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_kern_lib.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_kern_lib.c
@@ -65,10 +65,10 @@ vchiq_blocking_bulk_transfer(VCHIQ_SERVICE_HANDLE_T handle, 
void *data,
unsigned int size, VCHIQ_BULK_DIR_T dir);
 
 /
-*
-*   vchiq_initialise
-*
-***/
+ *
+ *   vchiq_initialise
+ *
+ ***/
 #define VCHIQ_INIT_RETRIES 10
 VCHIQ_STATUS_T vchiq_initialise(VCHIQ_INSTANCE_T *instance_out)
 {
@@ -80,7 +80,9 @@ VCHIQ_STATUS_T vchiq_initialise(VCHIQ_INSTANCE_T 
*instance_out)
vchiq_log_trace(vchiq_core_log_level, "%s called", __func__);
 
/* VideoCore may not be ready due to boot up timing.
-  It may never be ready if kernel and firmware are mismatched, so 
don't block forever. */
+* It may never be ready if kernel and firmware are mismatched, so don't
+* block forever.
+*/
for (i = 0; i < VCHIQ_INIT_RETRIES; i++) {
state = vchiq_get_state();
if (state)
@@ -93,7 +95,8 @@ VCHIQ_STATUS_T vchiq_initialise(VCHIQ_INSTANCE_T 
*instance_out)
goto failed;
} else if (i > 0) {
vchiq_log_warning(vchiq_core_log_level,
-   "%s: videocore initialized after %d retries\n", 
__func__, i);
+   "%s: videocore initialized after %d retries\n",
+   __func__, i);
}
 
instance = kzalloc(sizeof(*instance), GFP_KERNEL);
@@ -121,10 +124,10 @@ VCHIQ_STATUS_T vchiq_initialise(VCHIQ_INSTANCE_T 
*instance_out)
 EXPORT_SYMBOL(vchiq_initialise);
 
 /
-*
-*   vchiq_shutdown
-*
-***/
+ *
+ *   vchiq_shutdown
+ *
+ ***/
 
 VCHIQ_STATUS_T vchiq_shutdown(VCHIQ_INSTANCE_T instance)
 {
@@ -169,10 +172,10 @@ VCHIQ_STATUS_T vchiq_shutdown(VCHIQ_INSTANCE_T instance)
 EXPORT_SYMBOL(vchiq_shutdown);
 
 /
-*
-*   vchiq_is_connected
-*
-***/
+ *
+ *   vchiq_is_connected
+ *
+ ***/
 
 static int vchiq_is_connected(VCHIQ_INSTANCE_T instance)
 {
@@ -180,10 +183,10 @@ static int vchiq_is_connected(VCHIQ_INSTANCE_T instance)
 }
 
 /
-*
-*   vchiq_connect
-*
-***/
+ *
+ *   vchiq_connect
+ *
+ ***/
 
 VCHIQ_STATUS_T vchiq_connect(VCHIQ_INSTANCE_T instance)
 {
@@ -215,10 +218,10 @@ VCHIQ_STATUS_T vchiq_connect(VCHIQ_INSTANCE_T instance)
 EXPORT_SYMBOL(vchiq_connect);
 
 /
-*
-*   vchiq_add_service
-*
-***/
+ *
+ *   vchiq_add_service
+ *
+ ***/
 
 VCHIQ_STATUS_T vchiq_add_service(
VCHIQ_INSTANCE_T  instance,
@@ -260,10 +263,10 @@ VCHIQ_STATUS_T vchiq_add_service(
 EXPORT_SYMBOL(vchiq_add_service);
 
 /
-*
-*   vchiq_open_service
-*
-***/
+ *
+ *   vchiq_open_service
+ *
+ ***/
 
 VCHIQ_STATUS_T vchiq_open_service(
VCHIQ_INSTANCE_T  instance,
@@ -414,8 +417,9 @@ vchiq_blocking_bulk_transfer(VCHIQ_SERVICE_HANDLE_T handle, 
void *data,
if ((bulk->data != data) ||
(bulk->size != size)) {
/* This is not a retry of the previous one.
-   ** Cancel the signal when the transfer
-   ** completes. */
+* Cancel the signal when the transfer
+* completes.
+*/
  

Re: [PATCH v2] doc: convert printk-formats.txt to rst

[Markus Heiser]

> Am 07.12.2017 um 06:49 schrieb Tobin C. Harding :
> 
> Documentation/printk-formats.txt is a candidate for conversion to
> ReStructuredText format. Some effort has already been made to do this
> conversion even thought the suffix is currently .txt
> 
[...]
> 
> Signed-off-by: Tobin C. Harding 
> ---
> 
> v2:
> - Revert to use ASCII table.
> - Implement (or revert) changes as suggested by Randy Dunlap.
> - Change file location to core-api/ (inc required index changes) 
> - Remove some of the double back ticks.
> 
> Last two suggested by Jonathan Corbet.
> 

Hm, can't apply v2 on Jon's docs-next .. is the v2 patch on top of your v1?

If so, please take a look at our fabulously ;) documentation ..

 https://www.kernel.org/doc/html/latest/process/submitting-patches.html

"""
When you submit or resubmit a patch or patch series, include the complete patch 
description and justification for it. Don’t just say that this is version N of 
the patch (series). Don’t expect the subsystem maintainer to refer back to 
earlier patch versions or referenced URLs to find the patch description and put 
that into the patch. I.e., the patch (series) and its description should be 
self-contained. This benefits both the maintainers and reviewers. Some 
reviewers probably didn’t even receive earlier versions of the patch.

"""

-- Markus --

Re: [PATCH v2] doc: convert printk-formats.txt to rst

[Markus Heiser]

> Am 07.12.2017 um 06:49 schrieb Tobin C. Harding :
> 
> Documentation/printk-formats.txt is a candidate for conversion to
> ReStructuredText format. Some effort has already been made to do this
> conversion even thought the suffix is currently .txt
> 
[...]
> 
> Signed-off-by: Tobin C. Harding 
> ---
> 
> v2:
> - Revert to use ASCII table.
> - Implement (or revert) changes as suggested by Randy Dunlap.
> - Change file location to core-api/ (inc required index changes) 
> - Remove some of the double back ticks.
> 
> Last two suggested by Jonathan Corbet.
> 

Hm, can't apply v2 on Jon's docs-next .. is the v2 patch on top of your v1?

If so, please take a look at our fabulously ;) documentation ..

 https://www.kernel.org/doc/html/latest/process/submitting-patches.html

"""
When you submit or resubmit a patch or patch series, include the complete patch 
description and justification for it. Don’t just say that this is version N of 
the patch (series). Don’t expect the subsystem maintainer to refer back to 
earlier patch versions or referenced URLs to find the patch description and put 
that into the patch. I.e., the patch (series) and its description should be 
self-contained. This benefits both the maintainers and reviewers. Some 
reviewers probably didn’t even receive earlier versions of the patch.

"""

-- Markus --

Re: USB: hub: Delete an error message for a failed memory allocation in usb_hub_clear_tt_buffer()

[Geert Uytterhoeven]

Hi Alan,

On Wed, Dec 6, 2017 at 11:02 PM, Alan Stern  wrote:
> On Wed, 6 Dec 2017, SF Markus Elfring wrote:
>> >>> Does the existing memory allocation error message include the
>> >>> >dev device name and driver name?  If it doesn't, there will be
>> >>> no way for the user to tell that the error message is related to the
>> >>> device failure.
>> >>
>> >> No, but the effect is similar.
>> >>
>> >> OOM does a dump_stack() so this function's call tree is shown.
>> >
>> > A call stack doesn't tell you which device was being handled.
>>
>> Do you find a default Linux allocation failure report insufficient then?
>>
>> Would you like to to achieve that the requested information can be determined
>> from a backtrace?
>
> It is not practical to do this.  The memory allocation routines do not
> for what purpose the memory is being allocated; hence when a failure
> occurs they cannot tell what device (or other part of the system) will
> be affected.

If even allocation of 24 bytes fails, lots of other devices and other parts of
the system will start failing really soon...

> That's why we have a secondary error message.

... and the secondary error message would still be useless.

Gr{oetje,eeting}s,

Geert

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

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

Re: USB: hub: Delete an error message for a failed memory allocation in usb_hub_clear_tt_buffer()

[Geert Uytterhoeven]

Hi Alan,

On Wed, Dec 6, 2017 at 11:02 PM, Alan Stern  wrote:
> On Wed, 6 Dec 2017, SF Markus Elfring wrote:
>> >>> Does the existing memory allocation error message include the
>> >>> >dev device name and driver name?  If it doesn't, there will be
>> >>> no way for the user to tell that the error message is related to the
>> >>> device failure.
>> >>
>> >> No, but the effect is similar.
>> >>
>> >> OOM does a dump_stack() so this function's call tree is shown.
>> >
>> > A call stack doesn't tell you which device was being handled.
>>
>> Do you find a default Linux allocation failure report insufficient then?
>>
>> Would you like to to achieve that the requested information can be determined
>> from a backtrace?
>
> It is not practical to do this.  The memory allocation routines do not
> for what purpose the memory is being allocated; hence when a failure
> occurs they cannot tell what device (or other part of the system) will
> be affected.

If even allocation of 24 bytes fails, lots of other devices and other parts of
the system will start failing really soon...

> That's why we have a secondary error message.

... and the secondary error message would still be useless.

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH v3] ARM: da850: Fix LEGO EV3 battery voltage gpio

[Sekhar Nori]

On Monday 04 December 2017 03:34 AM, David Lechner wrote:
> This fixes the battery voltage monitoring gpio-hog settings.
> 
> When the gpio is low, it turns off the battery voltage to the ADC chip.
> However, this needs to be on all of the time so that we can monitor
> battery voltage.
> 
> Also, there was a typo that prevented pinmuxing from working correctly.
> 
> Signed-off-by: David Lechner 

Applied to fixes with subject line changed to:

ARM: dts: da850-lego-ev3: Fix battery voltage gpio

Please follow this style for future patches.

Thanks,
Sekhar

Re: [PATCH v3] ARM: da850: Fix LEGO EV3 battery voltage gpio

[Sekhar Nori]

On Monday 04 December 2017 03:34 AM, David Lechner wrote:
> This fixes the battery voltage monitoring gpio-hog settings.
> 
> When the gpio is low, it turns off the battery voltage to the ADC chip.
> However, this needs to be on all of the time so that we can monitor
> battery voltage.
> 
> Also, there was a typo that prevented pinmuxing from working correctly.
> 
> Signed-off-by: David Lechner 

Applied to fixes with subject line changed to:

ARM: dts: da850-lego-ev3: Fix battery voltage gpio

Please follow this style for future patches.

Thanks,
Sekhar

Re: [tip:x86/mpx] x86/insn-eval: Add utility function to get segment descriptor

[Ricardo Neri]

On Tue, Dec 05, 2017 at 10:29:33PM +0100, Borislav Petkov wrote:
> On Tue, Dec 05, 2017 at 07:38:45PM +0100, Peter Zijlstra wrote:
> > Sorry what? So either this code is broken because it has IRQs enabled,
> > or its broken because its trying to acquire a mutex with IRQs disabled.
> > Which is it?
> 
> Well, lemme try to sum up what Peter, Thomas and I discussed on IRC:
> 
> The problem is that there's no guarantee userspace won't change the LDT
> from under us while the UMIP code runs in the insn decoder.

Yes, I see the problem now.
> 
> So, we need a way to be able to query the desc fields the insn decoder
> needs *and* when the LDT changes through the syscall, to detect that
> case and handle it gracefully in the decoder.
> 
> So Thomas' idea is to keep a mm->context.ldt_seq sequence number which
> gets incremented (and wraps around) everytime a LDT changes.
> 
> That sequence number, i.e., cookie, gets handed down into the decoder
> and it uses it during desc lookup. If the sequence number changes, the
> decoder and the UMIP code must abort the emulation.

In UMIP emulation we can potentially access the LDT twice. Once when
determining the base address of the code segment and again when determining
the base address and limit of the segment in which the result of the
emulation is written. I guess that mm->context.ldt_seq needs to not change
not only while decoding a particular linear address but across these two
linear address decodings.
> 
> The lookup code needs to do that with IRQs disabled, of course, to
> protect itself from IPIs which could change the LDT.
> 
> I *think* this is the gist of what we talked about, tglx, please correct
> me if I missed something.
> 
> So, Ricardo, please take a look at fixing that as otherwise the UMIP
> code would choke and possibly rely on wrong data. If there are any
> questions, don't hesitate to ask.

Sure, I will look into implementing this idea and post patches for it.

Thanks and BR,
Ricardo

Re: [tip:x86/mpx] x86/insn-eval: Add utility function to get segment descriptor

[Ricardo Neri]

On Tue, Dec 05, 2017 at 10:29:33PM +0100, Borislav Petkov wrote:
> On Tue, Dec 05, 2017 at 07:38:45PM +0100, Peter Zijlstra wrote:
> > Sorry what? So either this code is broken because it has IRQs enabled,
> > or its broken because its trying to acquire a mutex with IRQs disabled.
> > Which is it?
> 
> Well, lemme try to sum up what Peter, Thomas and I discussed on IRC:
> 
> The problem is that there's no guarantee userspace won't change the LDT
> from under us while the UMIP code runs in the insn decoder.

Yes, I see the problem now.
> 
> So, we need a way to be able to query the desc fields the insn decoder
> needs *and* when the LDT changes through the syscall, to detect that
> case and handle it gracefully in the decoder.
> 
> So Thomas' idea is to keep a mm->context.ldt_seq sequence number which
> gets incremented (and wraps around) everytime a LDT changes.
> 
> That sequence number, i.e., cookie, gets handed down into the decoder
> and it uses it during desc lookup. If the sequence number changes, the
> decoder and the UMIP code must abort the emulation.

In UMIP emulation we can potentially access the LDT twice. Once when
determining the base address of the code segment and again when determining
the base address and limit of the segment in which the result of the
emulation is written. I guess that mm->context.ldt_seq needs to not change
not only while decoding a particular linear address but across these two
linear address decodings.
> 
> The lookup code needs to do that with IRQs disabled, of course, to
> protect itself from IPIs which could change the LDT.
> 
> I *think* this is the gist of what we talked about, tglx, please correct
> me if I missed something.
> 
> So, Ricardo, please take a look at fixing that as otherwise the UMIP
> code would choke and possibly rely on wrong data. If there are any
> questions, don't hesitate to ask.

Sure, I will look into implementing this idea and post patches for it.

Thanks and BR,
Ricardo

Re: [PATCH v3 35/36] usb/gadget/NCM: Replace tasklet with softirq hrtimer

[Anna-Maria Gleixner]

On Mon, 4 Dec 2017, Felipe Balbi wrote:

> Anna-Maria Gleixner  writes:
> 
> > From: Thomas Gleixner 
> >
> > The tx_tasklet tasklet is used in invoke the hrtimer (task_timer) in
> > softirq context. This can be also achieved without the tasklet but
> > with HRTIMER_MODE_SOFT as hrtimer mode.
> >
> > Signed-off-by: Thomas Gleixner 
> > Signed-off-by: Anna-Maria Gleixner 
> > Cc: Felipe Balbi 
> > Cc: linux-...@vger.kernel.org
> 
> This doesn't compile, so I'm assuming it depends on previous patches on
> this series?

Yes, you are right. It depends on the patches for the softirq context
hrtimer rework.

> 
> In that case:
> 
> Acked-by: Felipe Balbi 
> 
> -- 
> balbi
> 

Re: [PATCH v3 35/36] usb/gadget/NCM: Replace tasklet with softirq hrtimer

[Anna-Maria Gleixner]

On Mon, 4 Dec 2017, Felipe Balbi wrote:

> Anna-Maria Gleixner  writes:
> 
> > From: Thomas Gleixner 
> >
> > The tx_tasklet tasklet is used in invoke the hrtimer (task_timer) in
> > softirq context. This can be also achieved without the tasklet but
> > with HRTIMER_MODE_SOFT as hrtimer mode.
> >
> > Signed-off-by: Thomas Gleixner 
> > Signed-off-by: Anna-Maria Gleixner 
> > Cc: Felipe Balbi 
> > Cc: linux-...@vger.kernel.org
> 
> This doesn't compile, so I'm assuming it depends on previous patches on
> this series?

Yes, you are right. It depends on the patches for the softirq context
hrtimer rework.

> 
> In that case:
> 
> Acked-by: Felipe Balbi 
> 
> -- 
> balbi
> 

RE: [PATCH v2] arm64: dts: ls1088a: Add USB support

[Yinbo Zhu]

Hi shawn guo,

If my patch has no other issue, 
Can you help me push it to upstream.

Thanks.
BRs.

-Original Message-
From: Yinbo Zhu 
Sent: Wednesday, November 22, 2017 9:32 AM
To: 'Shawn Guo' 
Cc: 'Rob Herring' ; 'Mark Rutland' ; 
'Catalin Marinas )' ; 'Will Deacon )' 
; Harninder Rai ; 'Raghav Dogra' 
; Ashish Kumar ; Andy Tang 
; 'open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE 
BINDINGS' ; 'linux-arm-ker...@lists.infradead.org' 
; 'open list' 

Subject: RE: [PATCH v2] arm64: dts: ls1088a: Add USB support

Hi

-Original Message-
From: Yinbo Zhu 
Sent: Tuesday, November 14, 2017 4:00 PM
To: 'Shawn Guo' 
Cc: 'Rob Herring' ; 'Mark Rutland' ; 
'Catalin Marinas )' ; 'Will Deacon )' 
; Harninder Rai ; 'Raghav Dogra' 
; Ashish Kumar ; Andy Tang 
; 'open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE 
BINDINGS' ; 'linux-arm-ker...@lists.infradead.org' 
; 'open list' 

Subject: RE: [PATCH v2] arm64: dts: ls1088a: Add USB support



-Original Message-
From: Yinbo Zhu 
Sent: Tuesday, October 24, 2017 5:15 PM
To: Shawn Guo 
Cc: Rob Herring ; Mark Rutland ; 
Catalin Marinas ) ; Will Deacon ) 
; Harninder Rai ; Raghav Dogra 
; Ashish Kumar ; Andy Tang 
; open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS 
; linux-arm-ker...@lists.infradead.org; open list 

Subject: RE: [PATCH v2] arm64: dts: ls1088a: Add USB support


-Original Message-
From: Shawn Guo [mailto:shawn...@kernel.org] 
Sent: Friday, September 22, 2017 2:55 PM
To: Yinbo Zhu 
Cc: Rob Herring ; Mark Rutland ; 
Catalin Marinas ) ; Will Deacon ) 
; Harninder Rai ; Raghav Dogra 
; Ashish Kumar ; Andy Tang 
; open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS 
; linux-arm-ker...@lists.infradead.org; open list 

Subject: Re: [PATCH v2] arm64: dts: ls1088a: Add USB support

On Wed, Sep 13, 2017 at 05:10:09PM +0800, yinbo@nxp.com wrote:
> From: "yinbo.zhu" 
> 
> Fix the issue that usb is not detected on ls1088ardb

>It's not really about fixing issue but adding support.

The patch had been tested on upstream 4.14 code, it can fix the issue. 
> 
> Signed-off-by: yinbo.zhu 
> Signed-off-by: Ran Wang 
> ---

>You should better have a version history here to tell what's changed between 
>version.

>I will add a version history on next v3 patch
Hi,

I had modified the code as v4 version, 
https://patchwork.kernel.org/patch/10027393/
please check.

Thanks,
BRs
>  arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts |  8 
>  arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi| 20 
>  2 files changed, 28 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts 
> b/arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts
> index 213abb72de93..6c3c3bc4b681 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts
> @@ -118,6 +118,14 @@
>   status = "okay";
>  };
>  
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
>   {

>Please sort these labeled nodes alphabetically.

>Shawn

>   status = "okay";
>  };
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi 
> b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> index c144d06a6e33..c23fede8cf5d 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> @@ -359,6 +359,26 @@
>   status = "disabled";
>   };
>  
> + usb0: usb3@310 {
> + compatible = "snps,dwc3";
> + reg = <0x0 0x310 0x0 0x1>;
> + interrupts = <0 80 IRQ_TYPE_LEVEL_HIGH>;
> + dr_mode = "host";
> + snps,quirk-frame-length-adjustment = <0x20>;
> + snps,dis_rxdet_inp3_quirk;
> + status = 

RE: [PATCH v2] arm64: dts: ls1088a: Add USB support

[Yinbo Zhu]

Hi shawn guo,

If my patch has no other issue, 
Can you help me push it to upstream.

Thanks.
BRs.

-Original Message-
From: Yinbo Zhu 
Sent: Wednesday, November 22, 2017 9:32 AM
To: 'Shawn Guo' 
Cc: 'Rob Herring' ; 'Mark Rutland' ; 
'Catalin Marinas )' ; 'Will Deacon )' 
; Harninder Rai ; 'Raghav Dogra' 
; Ashish Kumar ; Andy Tang 
; 'open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE 
BINDINGS' ; 'linux-arm-ker...@lists.infradead.org' 
; 'open list' 

Subject: RE: [PATCH v2] arm64: dts: ls1088a: Add USB support

Hi

-Original Message-
From: Yinbo Zhu 
Sent: Tuesday, November 14, 2017 4:00 PM
To: 'Shawn Guo' 
Cc: 'Rob Herring' ; 'Mark Rutland' ; 
'Catalin Marinas )' ; 'Will Deacon )' 
; Harninder Rai ; 'Raghav Dogra' 
; Ashish Kumar ; Andy Tang 
; 'open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE 
BINDINGS' ; 'linux-arm-ker...@lists.infradead.org' 
; 'open list' 

Subject: RE: [PATCH v2] arm64: dts: ls1088a: Add USB support



-Original Message-
From: Yinbo Zhu 
Sent: Tuesday, October 24, 2017 5:15 PM
To: Shawn Guo 
Cc: Rob Herring ; Mark Rutland ; 
Catalin Marinas ) ; Will Deacon ) 
; Harninder Rai ; Raghav Dogra 
; Ashish Kumar ; Andy Tang 
; open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS 
; linux-arm-ker...@lists.infradead.org; open list 

Subject: RE: [PATCH v2] arm64: dts: ls1088a: Add USB support


-Original Message-
From: Shawn Guo [mailto:shawn...@kernel.org] 
Sent: Friday, September 22, 2017 2:55 PM
To: Yinbo Zhu 
Cc: Rob Herring ; Mark Rutland ; 
Catalin Marinas ) ; Will Deacon ) 
; Harninder Rai ; Raghav Dogra 
; Ashish Kumar ; Andy Tang 
; open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS 
; linux-arm-ker...@lists.infradead.org; open list 

Subject: Re: [PATCH v2] arm64: dts: ls1088a: Add USB support

On Wed, Sep 13, 2017 at 05:10:09PM +0800, yinbo@nxp.com wrote:
> From: "yinbo.zhu" 
> 
> Fix the issue that usb is not detected on ls1088ardb

>It's not really about fixing issue but adding support.

The patch had been tested on upstream 4.14 code, it can fix the issue. 
> 
> Signed-off-by: yinbo.zhu 
> Signed-off-by: Ran Wang 
> ---

>You should better have a version history here to tell what's changed between 
>version.

>I will add a version history on next v3 patch
Hi,

I had modified the code as v4 version, 
https://patchwork.kernel.org/patch/10027393/
please check.

Thanks,
BRs
>  arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts |  8 
>  arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi| 20 
>  2 files changed, 28 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts 
> b/arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts
> index 213abb72de93..6c3c3bc4b681 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts
> @@ -118,6 +118,14 @@
>   status = "okay";
>  };
>  
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
>   {

>Please sort these labeled nodes alphabetically.

>Shawn

>   status = "okay";
>  };
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi 
> b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> index c144d06a6e33..c23fede8cf5d 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> @@ -359,6 +359,26 @@
>   status = "disabled";
>   };
>  
> + usb0: usb3@310 {
> + compatible = "snps,dwc3";
> + reg = <0x0 0x310 0x0 0x1>;
> + interrupts = <0 80 IRQ_TYPE_LEVEL_HIGH>;
> + dr_mode = "host";
> + snps,quirk-frame-length-adjustment = <0x20>;
> + snps,dis_rxdet_inp3_quirk;
> + status = "disabled";
> + };
> +
> + usb1: usb3@311 {
> + compatible = "snps,dwc3";
> + reg = <0x0 0x311 0x0 0x1>;
> + interrupts = <0 81 IRQ_TYPE_LEVEL_HIGH>;
> + dr_mode = "host";
> + snps,quirk-frame-length-adjustment = <0x20>;
> + snps,dis_rxdet_inp3_quirk;
> + status = "disabled";
> + };
> +
>   sata: sata@320 {
>   compatible = "fsl,ls1088a-ahci";
>   reg = <0x0 0x320 0x0 0x1>,
> --
> 2.14.1
> 

Re: [tip:x86/mpx] x86/insn-eval: Add utility function to get segment descriptor

[Ricardo Neri]

On Tue, Dec 05, 2017 at 07:14:56PM +0100, Borislav Petkov wrote:
> 
> But, if other code is going to use those functions - and I believe
> that's the idea - otherwise they wouldn't be in arch/x86/lib/ 

At the moment MPX and UMIP are using the insn-eval decoder to determine
linear addresses.

Thanks and BR,
Ricardo

Re: [tip:x86/mpx] x86/insn-eval: Add utility function to get segment descriptor

[Ricardo Neri]

On Tue, Dec 05, 2017 at 07:14:56PM +0100, Borislav Petkov wrote:
> 
> But, if other code is going to use those functions - and I believe
> that's the idea - otherwise they wouldn't be in arch/x86/lib/ 

At the moment MPX and UMIP are using the insn-eval decoder to determine
linear addresses.

Thanks and BR,
Ricardo

Re: [PATCH] cpufreq: longhaul: Set transition_delay_us to 20 ms

[Meelis Roos]

> On 06-12-17, 20:21, Meelis Roos wrote:
> > 3 was not reliable.
> > 
> > I created root cron job
> > @reboot sleep 120; /sbin/reboot
> > 
> > and by the evening it was dead again.
> > 
> > Will try 5 tomorrow.
> 
> Lets make it similar to what it was before my original patch modified
> it, to avoid all corner cases.
> 
> Please test against 200 ms, 20 value here.

Sorry, I confused 20 vs 2, will test 20.

But 20 was the value before. Shall I test 20 with or without 
the other limiting patch?

-- 
Meelis Roos (mr...@linux.ee)

Re: [PATCH] cpufreq: longhaul: Set transition_delay_us to 20 ms

[Meelis Roos]

> On 06-12-17, 20:21, Meelis Roos wrote:
> > 3 was not reliable.
> > 
> > I created root cron job
> > @reboot sleep 120; /sbin/reboot
> > 
> > and by the evening it was dead again.
> > 
> > Will try 5 tomorrow.
> 
> Lets make it similar to what it was before my original patch modified
> it, to avoid all corner cases.
> 
> Please test against 200 ms, 20 value here.

Sorry, I confused 20 vs 2, will test 20.

But 20 was the value before. Shall I test 20 with or without 
the other limiting patch?

-- 
Meelis Roos (mr...@linux.ee)

[PATCH] LDT improvements

[Andy Lutomirski]

I think I like this approach.  I also think it might be nice to move the
whole cpu_entry_area into this new pgd range so that we can stop mucking
around with the fixmap.

TODO:
 - It crashes in ldt_gdt_64.  Not sure why.
 - 5-level docs aren't updated and the code is untested.

Signed-off-by: Andy Lutomirski 
---
 Documentation/x86/x86_64/mm.txt |  11 ++--
 arch/x86/include/asm/mmu_context.h  |  33 +-
 arch/x86/include/asm/pgtable_64_types.h |   2 +
 arch/x86/include/asm/processor.h|  23 +--
 arch/x86/kernel/ldt.c   | 109 +++-
 5 files changed, 161 insertions(+), 17 deletions(-)

diff --git a/Documentation/x86/x86_64/mm.txt b/Documentation/x86/x86_64/mm.txt
index 2d7d6590ade8..bfa44e1cb293 100644
--- a/Documentation/x86/x86_64/mm.txt
+++ b/Documentation/x86/x86_64/mm.txt
@@ -12,13 +12,15 @@ ea00 - eaff (=40 bits) virtual 
memory map (1TB)
 ... unused hole ...
 ec00 - fbff (=44 bits) kasan shadow memory (16TB)
 ... unused hole ...
+fe80 - feff (=39 bits) LDT range
 ff00 - ff7f (=39 bits) %esp fixup stacks
 ... unused hole ...
 ffef - fffe (=64 GB) EFI region mapping space
 ... unused hole ...
 8000 - 9fff (=512 MB)  kernel text mapping, from phys 0
-a000 - ff5f (=1526 MB) module mapping space (variable)
-ff60 - ffdf (=8 MB) vsyscalls
+a000 - [fixmap start]   (~1526 MB) module mapping space (variable)
+[fixmap start]   - ff5f kernel-internal fixmap range
+ff60 - ff600fff (=4 kB) legacy vsyscall ABI
 ffe0 -  (=2 MB) unused hole
 
 Virtual memory map with 5 level page tables:
@@ -39,8 +41,9 @@ ff00 - ff7f (=39 bits) %esp fixup 
stacks
 ffef - fffe (=64 GB) EFI region mapping space
 ... unused hole ...
 8000 - 9fff (=512 MB)  kernel text mapping, from phys 0
-a000 - ff5f (=1526 MB) module mapping space
-ff60 - ffdf (=8 MB) vsyscalls
+a000 - [fixmap start]   (~1526 MB) module mapping space
+[fixmap start]   - ff5f kernel-internal fixmap range
+ff60 - ff600fff (=4 kB) legacy vsyscall ABI
 ffe0 -  (=2 MB) unused hole
 
 Architecture defines a 64-bit virtual address. Implementations can support
diff --git a/arch/x86/include/asm/mmu_context.h 
b/arch/x86/include/asm/mmu_context.h
index 5e1a1ecb65c6..eb87bbeddacc 100644
--- a/arch/x86/include/asm/mmu_context.h
+++ b/arch/x86/include/asm/mmu_context.h
@@ -52,13 +52,29 @@ struct ldt_struct {
 */
struct desc_struct *entries;
unsigned int nr_entries;
+
+   /*
+* If PTI is in use, then the entries array is not mapped while we're
+* in user mode.  The whole array will be aliased at the addressed
+* given by ldt_slot_va(slot).
+*/
+   int slot;
 };
 
+/* This is a multiple of PAGE_SIZE. */
+#define LDT_SLOT_STRIDE (LDT_ENTRIES * LDT_ENTRY_SIZE)
+
+static void *ldt_slot_va(int slot)
+{
+   return (void *)(LDT_BASE_ADDR + LDT_SLOT_STRIDE * slot);
+}
+
 /*
  * Used for LDT copy/destruction.
  */
 int init_new_context_ldt(struct task_struct *tsk, struct mm_struct *mm);
 void destroy_context_ldt(struct mm_struct *mm);
+void ldt_arch_exit_mmap(struct mm_struct *mm);
 #else  /* CONFIG_MODIFY_LDT_SYSCALL */
 static inline int init_new_context_ldt(struct task_struct *tsk,
   struct mm_struct *mm)
@@ -90,10 +106,20 @@ static inline void load_mm_ldt(struct mm_struct *mm)
 * that we can see.
 */
 
-   if (unlikely(ldt))
-   set_ldt(ldt->entries, ldt->nr_entries);
-   else
+   if (unlikely(ldt)) {
+   if (static_cpu_has_bug(X86_BUG_CPU_SECURE_MODE_PTI)) {
+   if (WARN_ON_ONCE((unsigned long)ldt->slot > 1)) {
+   clear_LDT();
+   return;
+   }
+
+   set_ldt(ldt_slot_va(ldt->slot), ldt->nr_entries);
+   } else {
+   set_ldt(ldt->entries, ldt->nr_entries);
+   }
+   } else {
clear_LDT();
+   }
 #else
clear_LDT();
 #endif
@@ -185,6 +211,7 @@ static inline void arch_dup_mmap(struct mm_struct *oldmm,
 static inline void arch_exit_mmap(struct mm_struct *mm)
 {
paravirt_arch_exit_mmap(mm);
+   ldt_arch_exit_mmap(mm);
 }
 
 #ifdef CONFIG_X86_64
diff --git a/arch/x86/include/asm/pgtable_64_types.h 
b/arch/x86/include/asm/pgtable_64_types.h
index 6d5f45dcd4a1..130f575f8d1e 100644
--- a/arch/x86/include/asm/pgtable_64_types.h
+++ b/arch/x86/include/asm/pgtable_64_types.h
@@ -100,6 +100,8 @@ typedef struct 

[PATCH] LDT improvements

[Andy Lutomirski]

I think I like this approach.  I also think it might be nice to move the
whole cpu_entry_area into this new pgd range so that we can stop mucking
around with the fixmap.

TODO:
 - It crashes in ldt_gdt_64.  Not sure why.
 - 5-level docs aren't updated and the code is untested.

Signed-off-by: Andy Lutomirski 
---
 Documentation/x86/x86_64/mm.txt |  11 ++--
 arch/x86/include/asm/mmu_context.h  |  33 +-
 arch/x86/include/asm/pgtable_64_types.h |   2 +
 arch/x86/include/asm/processor.h|  23 +--
 arch/x86/kernel/ldt.c   | 109 +++-
 5 files changed, 161 insertions(+), 17 deletions(-)

diff --git a/Documentation/x86/x86_64/mm.txt b/Documentation/x86/x86_64/mm.txt
index 2d7d6590ade8..bfa44e1cb293 100644
--- a/Documentation/x86/x86_64/mm.txt
+++ b/Documentation/x86/x86_64/mm.txt
@@ -12,13 +12,15 @@ ea00 - eaff (=40 bits) virtual 
memory map (1TB)
 ... unused hole ...
 ec00 - fbff (=44 bits) kasan shadow memory (16TB)
 ... unused hole ...
+fe80 - feff (=39 bits) LDT range
 ff00 - ff7f (=39 bits) %esp fixup stacks
 ... unused hole ...
 ffef - fffe (=64 GB) EFI region mapping space
 ... unused hole ...
 8000 - 9fff (=512 MB)  kernel text mapping, from phys 0
-a000 - ff5f (=1526 MB) module mapping space (variable)
-ff60 - ffdf (=8 MB) vsyscalls
+a000 - [fixmap start]   (~1526 MB) module mapping space (variable)
+[fixmap start]   - ff5f kernel-internal fixmap range
+ff60 - ff600fff (=4 kB) legacy vsyscall ABI
 ffe0 -  (=2 MB) unused hole
 
 Virtual memory map with 5 level page tables:
@@ -39,8 +41,9 @@ ff00 - ff7f (=39 bits) %esp fixup 
stacks
 ffef - fffe (=64 GB) EFI region mapping space
 ... unused hole ...
 8000 - 9fff (=512 MB)  kernel text mapping, from phys 0
-a000 - ff5f (=1526 MB) module mapping space
-ff60 - ffdf (=8 MB) vsyscalls
+a000 - [fixmap start]   (~1526 MB) module mapping space
+[fixmap start]   - ff5f kernel-internal fixmap range
+ff60 - ff600fff (=4 kB) legacy vsyscall ABI
 ffe0 -  (=2 MB) unused hole
 
 Architecture defines a 64-bit virtual address. Implementations can support
diff --git a/arch/x86/include/asm/mmu_context.h 
b/arch/x86/include/asm/mmu_context.h
index 5e1a1ecb65c6..eb87bbeddacc 100644
--- a/arch/x86/include/asm/mmu_context.h
+++ b/arch/x86/include/asm/mmu_context.h
@@ -52,13 +52,29 @@ struct ldt_struct {
 */
struct desc_struct *entries;
unsigned int nr_entries;
+
+   /*
+* If PTI is in use, then the entries array is not mapped while we're
+* in user mode.  The whole array will be aliased at the addressed
+* given by ldt_slot_va(slot).
+*/
+   int slot;
 };
 
+/* This is a multiple of PAGE_SIZE. */
+#define LDT_SLOT_STRIDE (LDT_ENTRIES * LDT_ENTRY_SIZE)
+
+static void *ldt_slot_va(int slot)
+{
+   return (void *)(LDT_BASE_ADDR + LDT_SLOT_STRIDE * slot);
+}
+
 /*
  * Used for LDT copy/destruction.
  */
 int init_new_context_ldt(struct task_struct *tsk, struct mm_struct *mm);
 void destroy_context_ldt(struct mm_struct *mm);
+void ldt_arch_exit_mmap(struct mm_struct *mm);
 #else  /* CONFIG_MODIFY_LDT_SYSCALL */
 static inline int init_new_context_ldt(struct task_struct *tsk,
   struct mm_struct *mm)
@@ -90,10 +106,20 @@ static inline void load_mm_ldt(struct mm_struct *mm)
 * that we can see.
 */
 
-   if (unlikely(ldt))
-   set_ldt(ldt->entries, ldt->nr_entries);
-   else
+   if (unlikely(ldt)) {
+   if (static_cpu_has_bug(X86_BUG_CPU_SECURE_MODE_PTI)) {
+   if (WARN_ON_ONCE((unsigned long)ldt->slot > 1)) {
+   clear_LDT();
+   return;
+   }
+
+   set_ldt(ldt_slot_va(ldt->slot), ldt->nr_entries);
+   } else {
+   set_ldt(ldt->entries, ldt->nr_entries);
+   }
+   } else {
clear_LDT();
+   }
 #else
clear_LDT();
 #endif
@@ -185,6 +211,7 @@ static inline void arch_dup_mmap(struct mm_struct *oldmm,
 static inline void arch_exit_mmap(struct mm_struct *mm)
 {
paravirt_arch_exit_mmap(mm);
+   ldt_arch_exit_mmap(mm);
 }
 
 #ifdef CONFIG_X86_64
diff --git a/arch/x86/include/asm/pgtable_64_types.h 
b/arch/x86/include/asm/pgtable_64_types.h
index 6d5f45dcd4a1..130f575f8d1e 100644
--- a/arch/x86/include/asm/pgtable_64_types.h
+++ b/arch/x86/include/asm/pgtable_64_types.h
@@ -100,6 +100,8 @@ typedef struct { pteval_t pte; } 

[PATCH v2 5/5] perf-probe: Support escaped character in parser

[Masami Hiramatsu]

Support the special characters escaped by '\' in parser.
This allows user to specify versions directly like below.

  =
  # ./perf probe -x /lib64/libc-2.25.so malloc_get_state\\@GLIBC_2.2.5
  Added new event:
probe_libc:malloc_get_state (on malloc_get_state@GLIBC_2.2.5 in 
/usr/lib64/libc-2.25.so)

  You can now use it in all perf tools, such as:

  perf record -e probe_libc:malloc_get_state -aR sleep 1

  =

Or, you can use separators in source filename, e.g.

  =
  # ./perf probe -x /opt/test/a.out foo+bar.c:3
  Semantic error :There is non-digit character in offset.
Error: Command Parse Error.
  =

Usually "+" in source file cause parser error, but

  =
  # ./perf probe -x /opt/test/a.out foo\\+bar.c:4
  Added new event:
probe_a:main (on @foo+bar.c:4 in /opt/test/a.out)

  You can now use it in all perf tools, such as:

  perf record -e probe_a:main -aR sleep 1
  =

escaped "\+" allows you to specify that.

Signed-off-by: Masami Hiramatsu 
---
 Changes in v2:
  - Add a description and samples in Documentation/perf-probe.txt
---
 tools/perf/Documentation/perf-probe.txt |   16 +
 tools/perf/util/probe-event.c   |   54 +++
 tools/perf/util/string.c|   46 ++
 tools/perf/util/string2.h   |2 +
 4 files changed, 97 insertions(+), 21 deletions(-)

diff --git a/tools/perf/Documentation/perf-probe.txt 
b/tools/perf/Documentation/perf-probe.txt
index f96382692f42..b6866a05edd2 100644
--- a/tools/perf/Documentation/perf-probe.txt
+++ b/tools/perf/Documentation/perf-probe.txt
@@ -182,6 +182,14 @@ Note that before using the SDT event, the target binary 
(on which SDT events are
 For details of the SDT, see below.
 https://sourceware.org/gdb/onlinedocs/gdb/Static-Probe-Points.html
 
+ESCAPED CHARACTER
+-
+
+In the probe syntax, '=', '@', '+', ':' and ';' are treated as a special 
character. You can use a backslash ('\') to escape the special characters.
+This is useful if you need to probe on a specific versioned symbols, like 
@GLIBC_... suffixes, or also you need to specify a source file which includes 
the special characters.
+Note that usually single backslash is consumed by shell, so you might need to 
pass double backslash (\\) or wrapping with single quotes (\'AAA\@BBB').
+See EXAMPLES how it is used.
+
 PROBE ARGUMENT
 --
 Each probe argument follows below syntax.
@@ -277,6 +285,14 @@ Add a USDT probe to a target process running in a 
different mount namespace
 
  ./perf probe --target-ns  -x 
/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.121-0.b13.el7_3.x86_64/jre/lib/amd64/server/libjvm.so
 %sdt_hotspot:thread__sleep__end
 
+Add a probe on specific versioned symbol by backslash escape
+
+ ./perf probe -x /lib64/libc-2.25.so 'malloc_get_state\@GLIBC_2.2.5'
+
+Add a probe in a source file using special characters by backslash escape
+
+ ./perf probe -x /opt/test/a.out 'foo\+bar.c:4'
+
 
 SEE ALSO
 
diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index 94acc5846e2a..c082a27982e5 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -1325,27 +1325,30 @@ static int parse_perf_probe_event_name(char **arg, 
struct perf_probe_event *pev)
 {
char *ptr;
 
-   ptr = strchr(*arg, ':');
+   ptr = strpbrk_esc(*arg, ":");
if (ptr) {
*ptr = '\0';
if (!pev->sdt && !is_c_func_name(*arg))
goto ng_name;
-   pev->group = strdup(*arg);
+   pev->group = strdup_esc(*arg);
if (!pev->group)
return -ENOMEM;
*arg = ptr + 1;
} else
pev->group = NULL;
-   if (!pev->sdt && !is_c_func_name(*arg)) {
+
+   pev->event = strdup_esc(*arg);
+   if (pev->event == NULL)
+   return -ENOMEM;
+
+   if (!pev->sdt && !is_c_func_name(pev->event)) {
+   zfree(>event);
 ng_name:
+   zfree(>group);
semantic_error("%s is bad for event name -it must "
   "follow C symbol-naming rule.\n", *arg);
return -EINVAL;
}
-   pev->event = strdup(*arg);
-   if (pev->event == NULL)
-   return -ENOMEM;
-
return 0;
 }
 
@@ -1373,7 +1376,7 @@ static int parse_perf_probe_point(char *arg, struct 
perf_probe_event *pev)
arg++;
}
 
-   ptr = strpbrk(arg, ";=@+%");
+   ptr = strpbrk_esc(arg, ";=@+%");
if (pev->sdt) {
if (ptr) {
if (*ptr != '@') {
@@ -1387,7 +1390,7 @@ static int parse_perf_probe_point(char *arg, struct 
perf_probe_event *pev)
pev->target = build_id_cache__origname(tmp);
free(tmp);
} else
-  

[PATCH v2 5/5] perf-probe: Support escaped character in parser

[Masami Hiramatsu]

Support the special characters escaped by '\' in parser.
This allows user to specify versions directly like below.

  =
  # ./perf probe -x /lib64/libc-2.25.so malloc_get_state\\@GLIBC_2.2.5
  Added new event:
probe_libc:malloc_get_state (on malloc_get_state@GLIBC_2.2.5 in 
/usr/lib64/libc-2.25.so)

  You can now use it in all perf tools, such as:

  perf record -e probe_libc:malloc_get_state -aR sleep 1

  =

Or, you can use separators in source filename, e.g.

  =
  # ./perf probe -x /opt/test/a.out foo+bar.c:3
  Semantic error :There is non-digit character in offset.
Error: Command Parse Error.
  =

Usually "+" in source file cause parser error, but

  =
  # ./perf probe -x /opt/test/a.out foo\\+bar.c:4
  Added new event:
probe_a:main (on @foo+bar.c:4 in /opt/test/a.out)

  You can now use it in all perf tools, such as:

  perf record -e probe_a:main -aR sleep 1
  =

escaped "\+" allows you to specify that.

Signed-off-by: Masami Hiramatsu 
---
 Changes in v2:
  - Add a description and samples in Documentation/perf-probe.txt
---
 tools/perf/Documentation/perf-probe.txt |   16 +
 tools/perf/util/probe-event.c   |   54 +++
 tools/perf/util/string.c|   46 ++
 tools/perf/util/string2.h   |2 +
 4 files changed, 97 insertions(+), 21 deletions(-)

diff --git a/tools/perf/Documentation/perf-probe.txt 
b/tools/perf/Documentation/perf-probe.txt
index f96382692f42..b6866a05edd2 100644
--- a/tools/perf/Documentation/perf-probe.txt
+++ b/tools/perf/Documentation/perf-probe.txt
@@ -182,6 +182,14 @@ Note that before using the SDT event, the target binary 
(on which SDT events are
 For details of the SDT, see below.
 https://sourceware.org/gdb/onlinedocs/gdb/Static-Probe-Points.html
 
+ESCAPED CHARACTER
+-
+
+In the probe syntax, '=', '@', '+', ':' and ';' are treated as a special 
character. You can use a backslash ('\') to escape the special characters.
+This is useful if you need to probe on a specific versioned symbols, like 
@GLIBC_... suffixes, or also you need to specify a source file which includes 
the special characters.
+Note that usually single backslash is consumed by shell, so you might need to 
pass double backslash (\\) or wrapping with single quotes (\'AAA\@BBB').
+See EXAMPLES how it is used.
+
 PROBE ARGUMENT
 --
 Each probe argument follows below syntax.
@@ -277,6 +285,14 @@ Add a USDT probe to a target process running in a 
different mount namespace
 
  ./perf probe --target-ns  -x 
/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.121-0.b13.el7_3.x86_64/jre/lib/amd64/server/libjvm.so
 %sdt_hotspot:thread__sleep__end
 
+Add a probe on specific versioned symbol by backslash escape
+
+ ./perf probe -x /lib64/libc-2.25.so 'malloc_get_state\@GLIBC_2.2.5'
+
+Add a probe in a source file using special characters by backslash escape
+
+ ./perf probe -x /opt/test/a.out 'foo\+bar.c:4'
+
 
 SEE ALSO
 
diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index 94acc5846e2a..c082a27982e5 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -1325,27 +1325,30 @@ static int parse_perf_probe_event_name(char **arg, 
struct perf_probe_event *pev)
 {
char *ptr;
 
-   ptr = strchr(*arg, ':');
+   ptr = strpbrk_esc(*arg, ":");
if (ptr) {
*ptr = '\0';
if (!pev->sdt && !is_c_func_name(*arg))
goto ng_name;
-   pev->group = strdup(*arg);
+   pev->group = strdup_esc(*arg);
if (!pev->group)
return -ENOMEM;
*arg = ptr + 1;
} else
pev->group = NULL;
-   if (!pev->sdt && !is_c_func_name(*arg)) {
+
+   pev->event = strdup_esc(*arg);
+   if (pev->event == NULL)
+   return -ENOMEM;
+
+   if (!pev->sdt && !is_c_func_name(pev->event)) {
+   zfree(>event);
 ng_name:
+   zfree(>group);
semantic_error("%s is bad for event name -it must "
   "follow C symbol-naming rule.\n", *arg);
return -EINVAL;
}
-   pev->event = strdup(*arg);
-   if (pev->event == NULL)
-   return -ENOMEM;
-
return 0;
 }
 
@@ -1373,7 +1376,7 @@ static int parse_perf_probe_point(char *arg, struct 
perf_probe_event *pev)
arg++;
}
 
-   ptr = strpbrk(arg, ";=@+%");
+   ptr = strpbrk_esc(arg, ";=@+%");
if (pev->sdt) {
if (ptr) {
if (*ptr != '@') {
@@ -1387,7 +1390,7 @@ static int parse_perf_probe_point(char *arg, struct 
perf_probe_event *pev)
pev->target = build_id_cache__origname(tmp);
free(tmp);
} else
-   

[PATCH v2 3/5] perf-probe: Add __return suffix for return events

[Masami Hiramatsu]

Add __return suffix for function return events
automatically. Without this, user have to give --force
option and will see the number suffix for each event
like "function_1", which is not easy to recognize.
Instead, this adds __return suffix to it automatically.
E.g.

  =
  # ./perf probe -x /lib64/libc-2.25.so 'malloc*%return'
  Added new events:
probe_libc:malloc_printerr__return (on malloc*%return in 
/usr/lib64/libc-2.25.so)
probe_libc:malloc_consolidate__return (on malloc*%return in 
/usr/lib64/libc-2.25.so)
probe_libc:malloc_check__return (on malloc*%return in 
/usr/lib64/libc-2.25.so)
probe_libc:malloc_hook_ini__return (on malloc*%return in 
/usr/lib64/libc-2.25.so)
probe_libc:malloc__return (on malloc*%return in /usr/lib64/libc-2.25.so)
probe_libc:malloc_trim__return (on malloc*%return in 
/usr/lib64/libc-2.25.so)
probe_libc:malloc_usable_size__return (on malloc*%return in 
/usr/lib64/libc-2.25.so)
probe_libc:malloc_stats__return (on malloc*%return in 
/usr/lib64/libc-2.25.so)
probe_libc:malloc_info__return (on malloc*%return in 
/usr/lib64/libc-2.25.so)
probe_libc:mallochook__return (on malloc*%return in /usr/lib64/libc-2.25.so)
probe_libc:malloc_get_state__return (on malloc*%return in 
/usr/lib64/libc-2.25.so)
probe_libc:malloc_set_state__return (on malloc*%return in 
/usr/lib64/libc-2.25.so)

  You can now use it in all perf tools, such as:

  perf record -e probe_libc:malloc_set_state__return -aR sleep 1

  =

Signed-off-by: Masami Hiramatsu 
Reported-by: Arnaldo Carvalho de Melo 
---
  Changes in v2:
   - Add a description in Documentation/perf-probe.txt.
---
 tools/perf/Documentation/perf-probe.txt |2 +-
 tools/perf/util/probe-event.c   |9 +
 2 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/tools/perf/Documentation/perf-probe.txt 
b/tools/perf/Documentation/perf-probe.txt
index d7e4869905f1..f96382692f42 100644
--- a/tools/perf/Documentation/perf-probe.txt
+++ b/tools/perf/Documentation/perf-probe.txt
@@ -170,7 +170,7 @@ Probe points are defined by following syntax.
  or,
  sdt_PROVIDER:SDTEVENT
 
-'EVENT' specifies the name of new event, if omitted, it will be set the name 
of the probed function. You can also specify a group name by 'GROUP', if 
omitted, set 'probe' is used for kprobe and 'probe_' is used for uprobe.
+'EVENT' specifies the name of new event, if omitted, it will be set the name 
of the probed function, and for return probes, a "\_\_return" suffix is 
automatically added to the function name. You can also specify a group name by 
'GROUP', if omitted, set 'probe' is used for kprobe and 'probe_' is used 
for uprobe.
 Note that using existing group name can conflict with other events. 
Especially, using the group name reserved for kernel modules can hide embedded 
events in the
 modules.
 'FUNC' specifies a probed function name, and it may have one of the following 
options; '+OFFS' is the offset from function entry address in bytes, ':RLN' is 
the relative-line number from function entry line, and '%return' means that it 
probes function return. And ';PTN' means lazy matching pattern (see LAZY 
MATCHING). Note that ';PTN' must be the end of the probe point definition.  In 
addition, '@SRC' specifies a source file which has that function.
diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index 74435fb7ab7f..959c4d2ef455 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -2573,7 +2573,8 @@ int show_perf_probe_events(struct strfilter *filter)
 }
 
 static int get_new_event_name(char *buf, size_t len, const char *base,
- struct strlist *namelist, bool allow_suffix)
+ struct strlist *namelist, bool ret_event,
+ bool allow_suffix)
 {
int i, ret;
char *p, *nbase;
@@ -2590,7 +2591,7 @@ static int get_new_event_name(char *buf, size_t len, 
const char *base,
*p = '\0';
 
/* Try no suffix number */
-   ret = e_snprintf(buf, len, "%s", nbase);
+   ret = e_snprintf(buf, len, "%s%s", nbase, ret_event ? "__return" : "");
if (ret < 0) {
pr_debug("snprintf() failed: %d\n", ret);
goto out;
@@ -2689,8 +2690,8 @@ static int probe_trace_event__set_name(struct 
probe_trace_event *tev,
group = PERFPROBE_GROUP;
 
/* Get an unused new event name */
-   ret = get_new_event_name(buf, 64, event,
-namelist, allow_suffix);
+   ret = get_new_event_name(buf, 64, event, namelist,
+tev->point.retprobe, allow_suffix);
if (ret < 0)
return ret;
 

[PATCH v2 4/5] perf-probe: Find versioned symbols from map

[Masami Hiramatsu]

Find versioned symbols correctly from map.
Commit d80406453ad4 ("perf symbols: Allow user probes on
versioned symbols") allows user to find default versioned
symbols (with "@@") in map. However, it did not enable
normal versioned symbol (with "@") for perf-probe.
E.g.

  =
  # ./perf probe -x /lib64/libc-2.25.so malloc_get_state
  Failed to find symbol malloc_get_state in /usr/lib64/libc-2.25.so
Error: Failed to add events.
  =

This solves above issue by improving perf-probe symbol
search function, as below.

  =
  # ./perf probe -x /lib64/libc-2.25.so malloc_get_state
  Added new event:
probe_libc:malloc_get_state (on malloc_get_state in /usr/lib64/libc-2.25.so)

  You can now use it in all perf tools, such as:

  perf record -e probe_libc:malloc_get_state -aR sleep 1

  # ./perf probe -l
probe_libc:malloc_get_state (on malloc_get_state@GLIBC_2.2.5 in 
/usr/lib64/libc-2.25.so)
  =

Signed-off-by: Masami Hiramatsu 
---
 tools/perf/arch/powerpc/util/sym-handling.c |8 
 tools/perf/util/probe-event.c   |   16 +++-
 tools/perf/util/symbol.c|5 +
 tools/perf/util/symbol.h|1 +
 4 files changed, 29 insertions(+), 1 deletion(-)

diff --git a/tools/perf/arch/powerpc/util/sym-handling.c 
b/tools/perf/arch/powerpc/util/sym-handling.c
index 9c4e23d8c8ce..a3613c8d97b6 100644
--- a/tools/perf/arch/powerpc/util/sym-handling.c
+++ b/tools/perf/arch/powerpc/util/sym-handling.c
@@ -64,6 +64,14 @@ int arch__compare_symbol_names_n(const char *namea, const 
char *nameb,
 
return strncmp(namea, nameb, n);
 }
+
+const char *arch__normalize_symbol_name(const char *name)
+{
+   /* Skip over initial dot */
+   if (*name == '.')
+   name++;
+   return name;
+}
 #endif
 
 #if defined(_CALL_ELF) && _CALL_ELF == 2
diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index 959c4d2ef455..94acc5846e2a 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -2801,16 +2801,30 @@ static int find_probe_functions(struct map *map, char 
*name,
int found = 0;
struct symbol *sym;
struct rb_node *tmp;
+   const char *norm, *ver;
+   char *buf = NULL;
 
if (map__load(map) < 0)
return 0;
 
map__for_each_symbol(map, sym, tmp) {
-   if (strglobmatch(sym->name, name)) {
+   norm = arch__normalize_symbol_name(sym->name);
+   if (!norm)
+   continue;
+
+   /* We don't care about default symbol or not */
+   ver = strchr(norm, '@');
+   if (ver) {
+   buf = strndup(norm, ver - norm);
+   norm = buf;
+   }
+   if (strglobmatch(norm, name)) {
found++;
if (syms && found < probe_conf.max_probes)
syms[found - 1] = sym;
}
+   if (buf)
+   zfree();
}
 
return found;
diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index 1b67a8639dfe..cc065d4bfafc 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -94,6 +94,11 @@ static int prefix_underscores_count(const char *str)
return tail - str;
 }
 
+const char * __weak arch__normalize_symbol_name(const char *name)
+{
+   return name;
+}
+
 int __weak arch__compare_symbol_names(const char *namea, const char *nameb)
 {
return strcmp(namea, nameb);
diff --git a/tools/perf/util/symbol.h b/tools/perf/util/symbol.h
index a4f0075b4e5c..0563f33c1eb3 100644
--- a/tools/perf/util/symbol.h
+++ b/tools/perf/util/symbol.h
@@ -349,6 +349,7 @@ bool elf__needs_adjust_symbols(GElf_Ehdr ehdr);
 void arch__sym_update(struct symbol *s, GElf_Sym *sym);
 #endif
 
+const char *arch__normalize_symbol_name(const char *name);
 #define SYMBOL_A 0
 #define SYMBOL_B 1
 

[PATCH v2 3/5] perf-probe: Add __return suffix for return events

[Masami Hiramatsu]

Add __return suffix for function return events
automatically. Without this, user have to give --force
option and will see the number suffix for each event
like "function_1", which is not easy to recognize.
Instead, this adds __return suffix to it automatically.
E.g.

  =
  # ./perf probe -x /lib64/libc-2.25.so 'malloc*%return'
  Added new events:
probe_libc:malloc_printerr__return (on malloc*%return in 
/usr/lib64/libc-2.25.so)
probe_libc:malloc_consolidate__return (on malloc*%return in 
/usr/lib64/libc-2.25.so)
probe_libc:malloc_check__return (on malloc*%return in 
/usr/lib64/libc-2.25.so)
probe_libc:malloc_hook_ini__return (on malloc*%return in 
/usr/lib64/libc-2.25.so)
probe_libc:malloc__return (on malloc*%return in /usr/lib64/libc-2.25.so)
probe_libc:malloc_trim__return (on malloc*%return in 
/usr/lib64/libc-2.25.so)
probe_libc:malloc_usable_size__return (on malloc*%return in 
/usr/lib64/libc-2.25.so)
probe_libc:malloc_stats__return (on malloc*%return in 
/usr/lib64/libc-2.25.so)
probe_libc:malloc_info__return (on malloc*%return in 
/usr/lib64/libc-2.25.so)
probe_libc:mallochook__return (on malloc*%return in /usr/lib64/libc-2.25.so)
probe_libc:malloc_get_state__return (on malloc*%return in 
/usr/lib64/libc-2.25.so)
probe_libc:malloc_set_state__return (on malloc*%return in 
/usr/lib64/libc-2.25.so)

  You can now use it in all perf tools, such as:

  perf record -e probe_libc:malloc_set_state__return -aR sleep 1

  =

Signed-off-by: Masami Hiramatsu 
Reported-by: Arnaldo Carvalho de Melo 
---
  Changes in v2:
   - Add a description in Documentation/perf-probe.txt.
---
 tools/perf/Documentation/perf-probe.txt |2 +-
 tools/perf/util/probe-event.c   |9 +
 2 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/tools/perf/Documentation/perf-probe.txt 
b/tools/perf/Documentation/perf-probe.txt
index d7e4869905f1..f96382692f42 100644
--- a/tools/perf/Documentation/perf-probe.txt
+++ b/tools/perf/Documentation/perf-probe.txt
@@ -170,7 +170,7 @@ Probe points are defined by following syntax.
  or,
  sdt_PROVIDER:SDTEVENT
 
-'EVENT' specifies the name of new event, if omitted, it will be set the name 
of the probed function. You can also specify a group name by 'GROUP', if 
omitted, set 'probe' is used for kprobe and 'probe_' is used for uprobe.
+'EVENT' specifies the name of new event, if omitted, it will be set the name 
of the probed function, and for return probes, a "\_\_return" suffix is 
automatically added to the function name. You can also specify a group name by 
'GROUP', if omitted, set 'probe' is used for kprobe and 'probe_' is used 
for uprobe.
 Note that using existing group name can conflict with other events. 
Especially, using the group name reserved for kernel modules can hide embedded 
events in the
 modules.
 'FUNC' specifies a probed function name, and it may have one of the following 
options; '+OFFS' is the offset from function entry address in bytes, ':RLN' is 
the relative-line number from function entry line, and '%return' means that it 
probes function return. And ';PTN' means lazy matching pattern (see LAZY 
MATCHING). Note that ';PTN' must be the end of the probe point definition.  In 
addition, '@SRC' specifies a source file which has that function.
diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index 74435fb7ab7f..959c4d2ef455 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -2573,7 +2573,8 @@ int show_perf_probe_events(struct strfilter *filter)
 }
 
 static int get_new_event_name(char *buf, size_t len, const char *base,
- struct strlist *namelist, bool allow_suffix)
+ struct strlist *namelist, bool ret_event,
+ bool allow_suffix)
 {
int i, ret;
char *p, *nbase;
@@ -2590,7 +2591,7 @@ static int get_new_event_name(char *buf, size_t len, 
const char *base,
*p = '\0';
 
/* Try no suffix number */
-   ret = e_snprintf(buf, len, "%s", nbase);
+   ret = e_snprintf(buf, len, "%s%s", nbase, ret_event ? "__return" : "");
if (ret < 0) {
pr_debug("snprintf() failed: %d\n", ret);
goto out;
@@ -2689,8 +2690,8 @@ static int probe_trace_event__set_name(struct 
probe_trace_event *tev,
group = PERFPROBE_GROUP;
 
/* Get an unused new event name */
-   ret = get_new_event_name(buf, 64, event,
-namelist, allow_suffix);
+   ret = get_new_event_name(buf, 64, event, namelist,
+tev->point.retprobe, allow_suffix);
if (ret < 0)
return ret;
 

[PATCH v2 4/5] perf-probe: Find versioned symbols from map

[Masami Hiramatsu]

Find versioned symbols correctly from map.
Commit d80406453ad4 ("perf symbols: Allow user probes on
versioned symbols") allows user to find default versioned
symbols (with "@@") in map. However, it did not enable
normal versioned symbol (with "@") for perf-probe.
E.g.

  =
  # ./perf probe -x /lib64/libc-2.25.so malloc_get_state
  Failed to find symbol malloc_get_state in /usr/lib64/libc-2.25.so
Error: Failed to add events.
  =

This solves above issue by improving perf-probe symbol
search function, as below.

  =
  # ./perf probe -x /lib64/libc-2.25.so malloc_get_state
  Added new event:
probe_libc:malloc_get_state (on malloc_get_state in /usr/lib64/libc-2.25.so)

  You can now use it in all perf tools, such as:

  perf record -e probe_libc:malloc_get_state -aR sleep 1

  # ./perf probe -l
probe_libc:malloc_get_state (on malloc_get_state@GLIBC_2.2.5 in 
/usr/lib64/libc-2.25.so)
  =

Signed-off-by: Masami Hiramatsu 
---
 tools/perf/arch/powerpc/util/sym-handling.c |8 
 tools/perf/util/probe-event.c   |   16 +++-
 tools/perf/util/symbol.c|5 +
 tools/perf/util/symbol.h|1 +
 4 files changed, 29 insertions(+), 1 deletion(-)

diff --git a/tools/perf/arch/powerpc/util/sym-handling.c 
b/tools/perf/arch/powerpc/util/sym-handling.c
index 9c4e23d8c8ce..a3613c8d97b6 100644
--- a/tools/perf/arch/powerpc/util/sym-handling.c
+++ b/tools/perf/arch/powerpc/util/sym-handling.c
@@ -64,6 +64,14 @@ int arch__compare_symbol_names_n(const char *namea, const 
char *nameb,
 
return strncmp(namea, nameb, n);
 }
+
+const char *arch__normalize_symbol_name(const char *name)
+{
+   /* Skip over initial dot */
+   if (*name == '.')
+   name++;
+   return name;
+}
 #endif
 
 #if defined(_CALL_ELF) && _CALL_ELF == 2
diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index 959c4d2ef455..94acc5846e2a 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -2801,16 +2801,30 @@ static int find_probe_functions(struct map *map, char 
*name,
int found = 0;
struct symbol *sym;
struct rb_node *tmp;
+   const char *norm, *ver;
+   char *buf = NULL;
 
if (map__load(map) < 0)
return 0;
 
map__for_each_symbol(map, sym, tmp) {
-   if (strglobmatch(sym->name, name)) {
+   norm = arch__normalize_symbol_name(sym->name);
+   if (!norm)
+   continue;
+
+   /* We don't care about default symbol or not */
+   ver = strchr(norm, '@');
+   if (ver) {
+   buf = strndup(norm, ver - norm);
+   norm = buf;
+   }
+   if (strglobmatch(norm, name)) {
found++;
if (syms && found < probe_conf.max_probes)
syms[found - 1] = sym;
}
+   if (buf)
+   zfree();
}
 
return found;
diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index 1b67a8639dfe..cc065d4bfafc 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -94,6 +94,11 @@ static int prefix_underscores_count(const char *str)
return tail - str;
 }
 
+const char * __weak arch__normalize_symbol_name(const char *name)
+{
+   return name;
+}
+
 int __weak arch__compare_symbol_names(const char *namea, const char *nameb)
 {
return strcmp(namea, nameb);
diff --git a/tools/perf/util/symbol.h b/tools/perf/util/symbol.h
index a4f0075b4e5c..0563f33c1eb3 100644
--- a/tools/perf/util/symbol.h
+++ b/tools/perf/util/symbol.h
@@ -349,6 +349,7 @@ bool elf__needs_adjust_symbols(GElf_Ehdr ehdr);
 void arch__sym_update(struct symbol *s, GElf_Sym *sym);
 #endif
 
+const char *arch__normalize_symbol_name(const char *name);
 #define SYMBOL_A 0
 #define SYMBOL_B 1
 

[PATCH v2 2/5] perf-probe: Cut off the version suffix from event name

[Masami Hiramatsu]

Cut off the version suffix (e.g. @GLIBC_2.2.5 etc.) from
automatic generated event name. This fixes wildcard event
adding like below case;

  =
  # perf probe -x /lib64/libc-2.25.so malloc*
  Internal error: "malloc_get_state@GLIBC_2" is wrong event name.
Error: Failed to add events.
  =

This failure was caused by a versioned suffix symbol.
With this fix, perf probe automatically cuts the
suffix after @ as below.

  =
  # ./perf probe -x /lib64/libc-2.25.so malloc*
  Added new events:
probe_libc:malloc_printerr (on malloc* in /usr/lib64/libc-2.25.so)
probe_libc:malloc_consolidate (on malloc* in /usr/lib64/libc-2.25.so)
probe_libc:malloc_check (on malloc* in /usr/lib64/libc-2.25.so)
probe_libc:malloc_hook_ini (on malloc* in /usr/lib64/libc-2.25.so)
probe_libc:malloc(on malloc* in /usr/lib64/libc-2.25.so)
probe_libc:malloc_trim (on malloc* in /usr/lib64/libc-2.25.so)
probe_libc:malloc_usable_size (on malloc* in /usr/lib64/libc-2.25.so)
probe_libc:malloc_stats (on malloc* in /usr/lib64/libc-2.25.so)
probe_libc:malloc_info (on malloc* in /usr/lib64/libc-2.25.so)
probe_libc:mallochook (on malloc* in /usr/lib64/libc-2.25.so)
probe_libc:malloc_get_state (on malloc* in /usr/lib64/libc-2.25.so)
probe_libc:malloc_set_state (on malloc* in /usr/lib64/libc-2.25.so)

  You can now use it in all perf tools, such as:

  perf record -e probe_libc:malloc_set_state -aR sleep 1

  =

Signed-off-by: Masami Hiramatsu 
Reported-by: Arnaldo Carvalho de Melo 
Reported-by: bhargavb 
---
 tools/perf/util/probe-event.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index c0067950e56f..74435fb7ab7f 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -2584,8 +2584,8 @@ static int get_new_event_name(char *buf, size_t len, 
const char *base,
if (!nbase)
return -ENOMEM;
 
-   /* Cut off the dot suffixes (e.g. .const, .isra)*/
-   p = strchr(nbase, '.');
+   /* Cut off the dot suffixes (e.g. .const, .isra) and version suffixes */
+   p = strpbrk(nbase, ".@");
if (p && p != nbase)
*p = '\0';
 

[PATCH v2 2/5] perf-probe: Cut off the version suffix from event name

[Masami Hiramatsu]

Cut off the version suffix (e.g. @GLIBC_2.2.5 etc.) from
automatic generated event name. This fixes wildcard event
adding like below case;

  =
  # perf probe -x /lib64/libc-2.25.so malloc*
  Internal error: "malloc_get_state@GLIBC_2" is wrong event name.
Error: Failed to add events.
  =

This failure was caused by a versioned suffix symbol.
With this fix, perf probe automatically cuts the
suffix after @ as below.

  =
  # ./perf probe -x /lib64/libc-2.25.so malloc*
  Added new events:
probe_libc:malloc_printerr (on malloc* in /usr/lib64/libc-2.25.so)
probe_libc:malloc_consolidate (on malloc* in /usr/lib64/libc-2.25.so)
probe_libc:malloc_check (on malloc* in /usr/lib64/libc-2.25.so)
probe_libc:malloc_hook_ini (on malloc* in /usr/lib64/libc-2.25.so)
probe_libc:malloc(on malloc* in /usr/lib64/libc-2.25.so)
probe_libc:malloc_trim (on malloc* in /usr/lib64/libc-2.25.so)
probe_libc:malloc_usable_size (on malloc* in /usr/lib64/libc-2.25.so)
probe_libc:malloc_stats (on malloc* in /usr/lib64/libc-2.25.so)
probe_libc:malloc_info (on malloc* in /usr/lib64/libc-2.25.so)
probe_libc:mallochook (on malloc* in /usr/lib64/libc-2.25.so)
probe_libc:malloc_get_state (on malloc* in /usr/lib64/libc-2.25.so)
probe_libc:malloc_set_state (on malloc* in /usr/lib64/libc-2.25.so)

  You can now use it in all perf tools, such as:

  perf record -e probe_libc:malloc_set_state -aR sleep 1

  =

Signed-off-by: Masami Hiramatsu 
Reported-by: Arnaldo Carvalho de Melo 
Reported-by: bhargavb 
---
 tools/perf/util/probe-event.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index c0067950e56f..74435fb7ab7f 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -2584,8 +2584,8 @@ static int get_new_event_name(char *buf, size_t len, 
const char *base,
if (!nbase)
return -ENOMEM;
 
-   /* Cut off the dot suffixes (e.g. .const, .isra)*/
-   p = strchr(nbase, '.');
+   /* Cut off the dot suffixes (e.g. .const, .isra) and version suffixes */
+   p = strpbrk(nbase, ".@");
if (p && p != nbase)
*p = '\0';
 

[PATCH v2 1/5] perf-probe: Add warning message if there is unexpected event name

[Masami Hiramatsu]

This improve the error message so that user can know
event-name error before writing new events to
kprobe-events interface.

E.g.
   ==
   #./perf probe -x /lib64/libc-2.25.so malloc_get_state*
   Internal error: "malloc_get_state@GLIBC_2" is wrong event name.
 Error: Failed to add events.
   ==

Signed-off-by: Masami Hiramatsu 
---
 tools/perf/util/probe-event.c |8 
 1 file changed, 8 insertions(+)

diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index b7aaf9b2294d..c0067950e56f 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -2625,6 +2625,14 @@ static int get_new_event_name(char *buf, size_t len, 
const char *base,
 
 out:
free(nbase);
+
+   /* Final validation */
+   if (ret >= 0 && !is_c_func_name(buf)) {
+   pr_warning("Internal error: \"%s\" is wrong event name.\n",
+  buf);
+   ret = -EINVAL;
+   }
+
return ret;
 }
 

[PATCH v2 1/5] perf-probe: Add warning message if there is unexpected event name

[Masami Hiramatsu]

This improve the error message so that user can know
event-name error before writing new events to
kprobe-events interface.

E.g.
   ==
   #./perf probe -x /lib64/libc-2.25.so malloc_get_state*
   Internal error: "malloc_get_state@GLIBC_2" is wrong event name.
 Error: Failed to add events.
   ==

Signed-off-by: Masami Hiramatsu 
---
 tools/perf/util/probe-event.c |8 
 1 file changed, 8 insertions(+)

diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index b7aaf9b2294d..c0067950e56f 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -2625,6 +2625,14 @@ static int get_new_event_name(char *buf, size_t len, 
const char *base,
 
 out:
free(nbase);
+
+   /* Final validation */
+   if (ret >= 0 && !is_c_func_name(buf)) {
+   pr_warning("Internal error: \"%s\" is wrong event name.\n",
+  buf);
+   ret = -EINVAL;
+   }
+
return ret;
 }
 

[PATCH v2 0/5] perf-probe: Improve probing on versioned symbols

[Masami Hiramatsu]

Hi,

Here is the 2nd version of the series for probing on
versioned symbols in libraries. This includes 5 patches
to fix the issues discussed on perf-users ML 
(https://www.spinics.net/lists/linux-perf-users/msg04637.html)

The first version is here; https://lkml.org/lkml/2017/12/5/1124

Here is the updates;

[3/5] Add a description in Documentation/perf-probe.txt
[5/5] Add a description and examples in Documentation/perf-probe.txt

Thank you,
---

Masami Hiramatsu (5):
  perf-probe: Add warning message if there is unexpected event name
  perf-probe: Cut off the version suffix from event name
  perf-probe: Add __return suffix for return events
  perf-probe: Find versioned symbols from map
  perf-probe: Support escaped character in parser


 tools/perf/Documentation/perf-probe.txt |   18 ++
 tools/perf/arch/powerpc/util/sym-handling.c |8 +++
 tools/perf/util/probe-event.c   |   81 +++
 tools/perf/util/string.c|   46 +++
 tools/perf/util/string2.h   |2 +
 tools/perf/util/symbol.c|5 ++
 tools/perf/util/symbol.h|1 
 7 files changed, 137 insertions(+), 24 deletions(-)

--
Masami Hiramatsu (Linaro Ltd.) 

[PATCH v2 0/5] perf-probe: Improve probing on versioned symbols

[Masami Hiramatsu]

Hi,

Here is the 2nd version of the series for probing on
versioned symbols in libraries. This includes 5 patches
to fix the issues discussed on perf-users ML 
(https://www.spinics.net/lists/linux-perf-users/msg04637.html)

The first version is here; https://lkml.org/lkml/2017/12/5/1124

Here is the updates;

[3/5] Add a description in Documentation/perf-probe.txt
[5/5] Add a description and examples in Documentation/perf-probe.txt

Thank you,
---

Masami Hiramatsu (5):
  perf-probe: Add warning message if there is unexpected event name
  perf-probe: Cut off the version suffix from event name
  perf-probe: Add __return suffix for return events
  perf-probe: Find versioned symbols from map
  perf-probe: Support escaped character in parser


 tools/perf/Documentation/perf-probe.txt |   18 ++
 tools/perf/arch/powerpc/util/sym-handling.c |8 +++
 tools/perf/util/probe-event.c   |   81 +++
 tools/perf/util/string.c|   46 +++
 tools/perf/util/string2.h   |2 +
 tools/perf/util/symbol.c|5 ++
 tools/perf/util/symbol.h|1 
 7 files changed, 137 insertions(+), 24 deletions(-)

--
Masami Hiramatsu (Linaro Ltd.) 

Re: Use-after-free with deferred driver probing and __initconst

[Frank Rowand]

adding /me

On 12/04/17 04:24, Greg Kroah-Hartman wrote:
> On Sun, Dec 03, 2017 at 07:19:53PM +0200, Dan Aloni wrote:
>> Hi all,
>>
>> [[ CC'ed: folks relating to the original __*_refok family of attributes,
>> deferred probing, Open Firmware maintainer, drivers/base/ maintainer,
>> kernel harderning, LKML ]]
>>
>> It seems that it is possible to cause a use-after-free in the base driver
>> platform code using a set of combined circumstances which I describe below.
>> The instance of the issue happens on a patched 4.4 kernel at a client of
>> mine.
>>
>> [6.173692] Process kworker/u12:3 (pid: 173, stack limit = 
>> 0xfc3ea92b8000)
>> [6.180902] Call trace:
>> [6.183345] [] __of_match_node+0x48/0x8c
>> [6.188820] [] of_match_node+0x44/0x68
>> [6.194125] [] of_match_device+0x34/0x48
>> [6.199603] [] platform_match+0x34/0xa8
>> [6.204991] [] __device_attach_driver+0x60/0xc8
>> [6.211077] [] bus_for_each_drv+0x60/0xac
>> [6.216640] [] __device_attach+0x98/0x124
>> [6.03] [] device_initial_probe+0x24/0x30
>> [6.228111] [] bus_probe_device+0x38/0xa0
>> [6.233677] [] deferred_probe_work_func+0x108/0x128
>> [6.240111] [] process_one_work+0x268/0x444
>> [6.245849] [] worker_thread+0x274/0x404
>> [6.251329] [] kthread+0xe0/0xe8
>> [6.256114] [] ret_from_fork+0x10/0x50
>> [6.261415] ---[ end trace fccad0f7d2c2142a ]---
>> [6.271293] note: kworker/u12:3[173] exited with preempt_count 1
>> [6.277342] Unable to handle kernel paging request at virtual address 
>> ffd8
>>
>> It happens while booting, and among other things it requires having platform
>> OF drivers marking their `of_driver_id` arrays as `__initconst`, e.g:
>>
>> static const struct of_device_id some_driver_of[] __initconst = {
>> ...
>> {},
>> };
>>
>> Given a platform driver that uses deferred probing, these arrays marked as
>> `__initconst` could be accessed from a deferred probe path after the init
>> section of the kernel has been freed. I have not seen anything in the API
>> related deferred probing that can guard from this scenario.
>>
>> On kernels prior to KASLR the access is not detected, but it can still 
>> happen,
>> potentially accessing memory that was returned to the page allocator.
>>
>> On 4.15-rc1, the following shows the ratio between instances of 
>> `of_device_id`
>> arrays and the number of them which are declared`__initconst`:
>>
>> $ git grep 'struct of_device_id.*\[\]' | wc -l
>> 3089
>>
>> $ git grep 'struct of_device_id.*\[\]' | grep __initconst  | wc -l
>> 117
>>
>> Not all of these instances are platform drivers, but perhaps deferred
>> probing with other types of drivers may cause similar issues.
>>
>> Perhaps it is worthwhile patching stable kernels for the removal of
>> `__initconst` on these arrays?
> 
> Yes, if those patches are in Linus's tree, that fixes a bug.
> 
>> And for the larger question -
>>
>> Freeing of init sections poses an exploitable vulnerability if that memory
>> is not unmapped, _and_ if there are still accesses taking place due to bugs
>> of this kind. Linux's build process is supposed to detect references from
>> non-freed sections to the freed sections, but clearly this instance has
>> not been detected during build, particularly because we have the `__ref`,
>> `__refdata`, and `__refconst` attributes which suppress those checks.
>>
>> Perhaps as a harderning measure, older kernels should be patched with a
>> config option for not freeing init sections?
> 
> Older kernels should just get the fixes that are in newer kernels :)
> 
> If you have specific pointers to commits that resolve these issues, I'll
> be glad to queue them up in the stable kernels.
> 
> Yes, it is a whack-a-mole fixup, a much better option would be what you
> suggest.  Perhaps we need to fix the build to properly mark these
> section references as errors like other ones are?
> 
> thanks,
> 
> greg k-h
> 

Re: Use-after-free with deferred driver probing and __initconst

[Frank Rowand]

adding /me

On 12/04/17 04:24, Greg Kroah-Hartman wrote:
> On Sun, Dec 03, 2017 at 07:19:53PM +0200, Dan Aloni wrote:
>> Hi all,
>>
>> [[ CC'ed: folks relating to the original __*_refok family of attributes,
>> deferred probing, Open Firmware maintainer, drivers/base/ maintainer,
>> kernel harderning, LKML ]]
>>
>> It seems that it is possible to cause a use-after-free in the base driver
>> platform code using a set of combined circumstances which I describe below.
>> The instance of the issue happens on a patched 4.4 kernel at a client of
>> mine.
>>
>> [6.173692] Process kworker/u12:3 (pid: 173, stack limit = 
>> 0xfc3ea92b8000)
>> [6.180902] Call trace:
>> [6.183345] [] __of_match_node+0x48/0x8c
>> [6.188820] [] of_match_node+0x44/0x68
>> [6.194125] [] of_match_device+0x34/0x48
>> [6.199603] [] platform_match+0x34/0xa8
>> [6.204991] [] __device_attach_driver+0x60/0xc8
>> [6.211077] [] bus_for_each_drv+0x60/0xac
>> [6.216640] [] __device_attach+0x98/0x124
>> [6.03] [] device_initial_probe+0x24/0x30
>> [6.228111] [] bus_probe_device+0x38/0xa0
>> [6.233677] [] deferred_probe_work_func+0x108/0x128
>> [6.240111] [] process_one_work+0x268/0x444
>> [6.245849] [] worker_thread+0x274/0x404
>> [6.251329] [] kthread+0xe0/0xe8
>> [6.256114] [] ret_from_fork+0x10/0x50
>> [6.261415] ---[ end trace fccad0f7d2c2142a ]---
>> [6.271293] note: kworker/u12:3[173] exited with preempt_count 1
>> [6.277342] Unable to handle kernel paging request at virtual address 
>> ffd8
>>
>> It happens while booting, and among other things it requires having platform
>> OF drivers marking their `of_driver_id` arrays as `__initconst`, e.g:
>>
>> static const struct of_device_id some_driver_of[] __initconst = {
>> ...
>> {},
>> };
>>
>> Given a platform driver that uses deferred probing, these arrays marked as
>> `__initconst` could be accessed from a deferred probe path after the init
>> section of the kernel has been freed. I have not seen anything in the API
>> related deferred probing that can guard from this scenario.
>>
>> On kernels prior to KASLR the access is not detected, but it can still 
>> happen,
>> potentially accessing memory that was returned to the page allocator.
>>
>> On 4.15-rc1, the following shows the ratio between instances of 
>> `of_device_id`
>> arrays and the number of them which are declared`__initconst`:
>>
>> $ git grep 'struct of_device_id.*\[\]' | wc -l
>> 3089
>>
>> $ git grep 'struct of_device_id.*\[\]' | grep __initconst  | wc -l
>> 117
>>
>> Not all of these instances are platform drivers, but perhaps deferred
>> probing with other types of drivers may cause similar issues.
>>
>> Perhaps it is worthwhile patching stable kernels for the removal of
>> `__initconst` on these arrays?
> 
> Yes, if those patches are in Linus's tree, that fixes a bug.
> 
>> And for the larger question -
>>
>> Freeing of init sections poses an exploitable vulnerability if that memory
>> is not unmapped, _and_ if there are still accesses taking place due to bugs
>> of this kind. Linux's build process is supposed to detect references from
>> non-freed sections to the freed sections, but clearly this instance has
>> not been detected during build, particularly because we have the `__ref`,
>> `__refdata`, and `__refconst` attributes which suppress those checks.
>>
>> Perhaps as a harderning measure, older kernels should be patched with a
>> config option for not freeing init sections?
> 
> Older kernels should just get the fixes that are in newer kernels :)
> 
> If you have specific pointers to commits that resolve these issues, I'll
> be glad to queue them up in the stable kernels.
> 
> Yes, it is a whack-a-mole fixup, a much better option would be what you
> suggest.  Perhaps we need to fix the build to properly mark these
> section references as errors like other ones are?
> 
> thanks,
> 
> greg k-h
> 

Re: Use-after-free with deferred driver probing and __initconst

[Frank Rowand]

adding /me

On 12/03/17 12:19, Dan Aloni wrote:
> Hi all,
> 
> [[ CC'ed: folks relating to the original __*_refok family of attributes,
> deferred probing, Open Firmware maintainer, drivers/base/ maintainer,
> kernel harderning, LKML ]]
> 
> It seems that it is possible to cause a use-after-free in the base driver
> platform code using a set of combined circumstances which I describe below.
> The instance of the issue happens on a patched 4.4 kernel at a client of
> mine.
> 
> [6.173692] Process kworker/u12:3 (pid: 173, stack limit = 
> 0xfc3ea92b8000)
> [6.180902] Call trace:
> [6.183345] [] __of_match_node+0x48/0x8c
> [6.188820] [] of_match_node+0x44/0x68
> [6.194125] [] of_match_device+0x34/0x48
> [6.199603] [] platform_match+0x34/0xa8
> [6.204991] [] __device_attach_driver+0x60/0xc8
> [6.211077] [] bus_for_each_drv+0x60/0xac
> [6.216640] [] __device_attach+0x98/0x124
> [6.03] [] device_initial_probe+0x24/0x30
> [6.228111] [] bus_probe_device+0x38/0xa0
> [6.233677] [] deferred_probe_work_func+0x108/0x128
> [6.240111] [] process_one_work+0x268/0x444
> [6.245849] [] worker_thread+0x274/0x404
> [6.251329] [] kthread+0xe0/0xe8
> [6.256114] [] ret_from_fork+0x10/0x50
> [6.261415] ---[ end trace fccad0f7d2c2142a ]---
> [6.271293] note: kworker/u12:3[173] exited with preempt_count 1
> [6.277342] Unable to handle kernel paging request at virtual address 
> ffd8
> 
> It happens while booting, and among other things it requires having platform
> OF drivers marking their `of_driver_id` arrays as `__initconst`, e.g:
> 
> static const struct of_device_id some_driver_of[] __initconst = {
> ...
> {},
> };
> 
> Given a platform driver that uses deferred probing, these arrays marked as
> `__initconst` could be accessed from a deferred probe path after the init
> section of the kernel has been freed. I have not seen anything in the API
> related deferred probing that can guard from this scenario.
> 
> On kernels prior to KASLR the access is not detected, but it can still happen,
> potentially accessing memory that was returned to the page allocator.
> 
> On 4.15-rc1, the following shows the ratio between instances of `of_device_id`
> arrays and the number of them which are declared`__initconst`:
> 
> $ git grep 'struct of_device_id.*\[\]' | wc -l
> 3089
> 
> $ git grep 'struct of_device_id.*\[\]' | grep __initconst  | wc -l
> 117
> 
> Not all of these instances are platform drivers, but perhaps deferred
> probing with other types of drivers may cause similar issues.
> 
> Perhaps it is worthwhile patching stable kernels for the removal of
> `__initconst` on these arrays?
> 
> 
> And for the larger question -
> 
> Freeing of init sections poses an exploitable vulnerability if that memory
> is not unmapped, _and_ if there are still accesses taking place due to bugs
> of this kind. Linux's build process is supposed to detect references from
> non-freed sections to the freed sections, but clearly this instance has
> not been detected during build, particularly because we have the `__ref`,
> `__refdata`, and `__refconst` attributes which suppress those checks.
> 
> Perhaps as a harderning measure, older kernels should be patched with a
> config option for not freeing init sections?
> 
> --
> Dan Aloni
> 

Re: Use-after-free with deferred driver probing and __initconst

[Frank Rowand]

adding /me

On 12/03/17 12:19, Dan Aloni wrote:
> Hi all,
> 
> [[ CC'ed: folks relating to the original __*_refok family of attributes,
> deferred probing, Open Firmware maintainer, drivers/base/ maintainer,
> kernel harderning, LKML ]]
> 
> It seems that it is possible to cause a use-after-free in the base driver
> platform code using a set of combined circumstances which I describe below.
> The instance of the issue happens on a patched 4.4 kernel at a client of
> mine.
> 
> [6.173692] Process kworker/u12:3 (pid: 173, stack limit = 
> 0xfc3ea92b8000)
> [6.180902] Call trace:
> [6.183345] [] __of_match_node+0x48/0x8c
> [6.188820] [] of_match_node+0x44/0x68
> [6.194125] [] of_match_device+0x34/0x48
> [6.199603] [] platform_match+0x34/0xa8
> [6.204991] [] __device_attach_driver+0x60/0xc8
> [6.211077] [] bus_for_each_drv+0x60/0xac
> [6.216640] [] __device_attach+0x98/0x124
> [6.03] [] device_initial_probe+0x24/0x30
> [6.228111] [] bus_probe_device+0x38/0xa0
> [6.233677] [] deferred_probe_work_func+0x108/0x128
> [6.240111] [] process_one_work+0x268/0x444
> [6.245849] [] worker_thread+0x274/0x404
> [6.251329] [] kthread+0xe0/0xe8
> [6.256114] [] ret_from_fork+0x10/0x50
> [6.261415] ---[ end trace fccad0f7d2c2142a ]---
> [6.271293] note: kworker/u12:3[173] exited with preempt_count 1
> [6.277342] Unable to handle kernel paging request at virtual address 
> ffd8
> 
> It happens while booting, and among other things it requires having platform
> OF drivers marking their `of_driver_id` arrays as `__initconst`, e.g:
> 
> static const struct of_device_id some_driver_of[] __initconst = {
> ...
> {},
> };
> 
> Given a platform driver that uses deferred probing, these arrays marked as
> `__initconst` could be accessed from a deferred probe path after the init
> section of the kernel has been freed. I have not seen anything in the API
> related deferred probing that can guard from this scenario.
> 
> On kernels prior to KASLR the access is not detected, but it can still happen,
> potentially accessing memory that was returned to the page allocator.
> 
> On 4.15-rc1, the following shows the ratio between instances of `of_device_id`
> arrays and the number of them which are declared`__initconst`:
> 
> $ git grep 'struct of_device_id.*\[\]' | wc -l
> 3089
> 
> $ git grep 'struct of_device_id.*\[\]' | grep __initconst  | wc -l
> 117
> 
> Not all of these instances are platform drivers, but perhaps deferred
> probing with other types of drivers may cause similar issues.
> 
> Perhaps it is worthwhile patching stable kernels for the removal of
> `__initconst` on these arrays?
> 
> 
> And for the larger question -
> 
> Freeing of init sections poses an exploitable vulnerability if that memory
> is not unmapped, _and_ if there are still accesses taking place due to bugs
> of this kind. Linux's build process is supposed to detect references from
> non-freed sections to the freed sections, but clearly this instance has
> not been detected during build, particularly because we have the `__ref`,
> `__refdata`, and `__refconst` attributes which suppress those checks.
> 
> Perhaps as a harderning measure, older kernels should be patched with a
> config option for not freeing init sections?
> 
> --
> Dan Aloni
> 

Re: [PATCH 2/2] arm64: allwinner: a64: bananapi-m64: add usb otg

[Jagan Teki]

On Thu, Dec 7, 2017 at 12:31 PM, Chen-Yu Tsai  wrote:
> On Thu, Dec 7, 2017 at 2:54 PM, Jagan Teki  wrote:
>> On Thu, Dec 7, 2017 at 11:56 AM, Chen-Yu Tsai  wrote:
>>> On Thu, Dec 7, 2017 at 2:18 PM, Jagan Teki  wrote:
 On Thu, Dec 7, 2017 at 8:54 AM, Chen-Yu Tsai  wrote:
> On Thu, Dec 7, 2017 at 1:51 AM, Jagan Teki  
> wrote:
>> usb otg on bananapi-m64 has configured with USB-ID with PH9
>> and USB-DRVVBUS attached with dcdc1 regulatort.
>
> That is not how you read the schematic...
>
> Intersecting lines that are tied together will have a dot representing
> the connection. The DCDC1 line is a pull-up for the ID pin. This is very
> clear because it has a resistor connected in series.
>
> VBUS for OTG is controlled by the IC displayed to the right in the
> schematic, which is powered from 5V, and controlled by the DRVVBUS
> pin from the PMIC. Please take a look at how the A31/A33/A83T board
> dts files represent this.

 This is where I confused, USB-DRVVBUS is connected to pin 51 of PMIC
 if we add 5v regulator how can configure gpio number for this? I saw
>>>
>>> From the axp20x bindings:
>>>
>>> - x-powers,drive-vbus-en: boolean, set this when the N_VBUSEN pin is
>>>   used as an output pin to control an external
>>>   regulator to drive the OTG VBus, rather then
>>>   as an input pin which signals whether the
>>>   board is driving OTG VBus or not.
>>>   (axp221 / axp223 / axp813 only)
>>>
>>> Setting this allows you to use the "drivevbus" regulator under the PMIC.
>>> As I said, look at how other boards are doing it.
>>>
 sun8i-a33-olinuxino.dts which is also similar but it has gpio = <
 1 9 GPIO_ACTIVE_HIGH>;
>>>
>>> I have no idea where you saw this. It does not exist in my tree.
>>>
>>> Why don't you just trace backwards from the usb0_vbus-supply property
>>> under the usbphy node, and see where it all leads.
>>
>> This what exactly I did, usb0_vbus-supply = <_drivevbus>; on
>
> This is not what you did in your patch.
>
>> sun8i-a33-olinuxino.dts is using usb0-vbus from
>> sunxi-common-regulators.dtsi. reg_usb0_vbus regulator using gpio9
>> which I couldn't find it on schematics.
>
> And I'm telling you that in mainline a33-olinuxino.dts it is:
>
> usb0_vbus-supply = <_drivevbus>;
>
> It has been that way since the initial commit adding the file.
> What tree are you looking at exactly? Take a good look at everything,
> including your patch, and stop arguing.

Sorry, you miss understand. I've seen a33-olinuxino and bananapi-m64
has similar connection in otg. Just trying to compare both and
understand what I did different in my patch. Anyway thanks for your
time I will send next version it will be worth discussing the same
there.

thanks!
-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.

Re: [PATCH 2/2] arm64: allwinner: a64: bananapi-m64: add usb otg

[Jagan Teki]

On Thu, Dec 7, 2017 at 12:31 PM, Chen-Yu Tsai  wrote:
> On Thu, Dec 7, 2017 at 2:54 PM, Jagan Teki  wrote:
>> On Thu, Dec 7, 2017 at 11:56 AM, Chen-Yu Tsai  wrote:
>>> On Thu, Dec 7, 2017 at 2:18 PM, Jagan Teki  wrote:
 On Thu, Dec 7, 2017 at 8:54 AM, Chen-Yu Tsai  wrote:
> On Thu, Dec 7, 2017 at 1:51 AM, Jagan Teki  
> wrote:
>> usb otg on bananapi-m64 has configured with USB-ID with PH9
>> and USB-DRVVBUS attached with dcdc1 regulatort.
>
> That is not how you read the schematic...
>
> Intersecting lines that are tied together will have a dot representing
> the connection. The DCDC1 line is a pull-up for the ID pin. This is very
> clear because it has a resistor connected in series.
>
> VBUS for OTG is controlled by the IC displayed to the right in the
> schematic, which is powered from 5V, and controlled by the DRVVBUS
> pin from the PMIC. Please take a look at how the A31/A33/A83T board
> dts files represent this.

 This is where I confused, USB-DRVVBUS is connected to pin 51 of PMIC
 if we add 5v regulator how can configure gpio number for this? I saw
>>>
>>> From the axp20x bindings:
>>>
>>> - x-powers,drive-vbus-en: boolean, set this when the N_VBUSEN pin is
>>>   used as an output pin to control an external
>>>   regulator to drive the OTG VBus, rather then
>>>   as an input pin which signals whether the
>>>   board is driving OTG VBus or not.
>>>   (axp221 / axp223 / axp813 only)
>>>
>>> Setting this allows you to use the "drivevbus" regulator under the PMIC.
>>> As I said, look at how other boards are doing it.
>>>
 sun8i-a33-olinuxino.dts which is also similar but it has gpio = <
 1 9 GPIO_ACTIVE_HIGH>;
>>>
>>> I have no idea where you saw this. It does not exist in my tree.
>>>
>>> Why don't you just trace backwards from the usb0_vbus-supply property
>>> under the usbphy node, and see where it all leads.
>>
>> This what exactly I did, usb0_vbus-supply = <_drivevbus>; on
>
> This is not what you did in your patch.
>
>> sun8i-a33-olinuxino.dts is using usb0-vbus from
>> sunxi-common-regulators.dtsi. reg_usb0_vbus regulator using gpio9
>> which I couldn't find it on schematics.
>
> And I'm telling you that in mainline a33-olinuxino.dts it is:
>
> usb0_vbus-supply = <_drivevbus>;
>
> It has been that way since the initial commit adding the file.
> What tree are you looking at exactly? Take a good look at everything,
> including your patch, and stop arguing.

Sorry, you miss understand. I've seen a33-olinuxino and bananapi-m64
has similar connection in otg. Just trying to compare both and
understand what I did different in my patch. Anyway thanks for your
time I will send next version it will be worth discussing the same
there.

thanks!
-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.

Re: [PATCH v2] clk: stm32-h7: fix copyright

[Stephen Boyd]

On 11/30, Benjamin Gaignard wrote:
> Uniformize STMicroelectronics copyrights header
> Add SPDX identifier
> 
> Signed-off-by: Benjamin Gaignard 
> Acked-by: Alexandre TORGUE 
> CC: Gabriel Fernandez 
> ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v2] clk: stm32-h7: fix copyright

[Stephen Boyd]

On 11/30, Benjamin Gaignard wrote:
> Uniformize STMicroelectronics copyrights header
> Add SPDX identifier
> 
> Signed-off-by: Benjamin Gaignard 
> Acked-by: Alexandre TORGUE 
> CC: Gabriel Fernandez 
> ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v2] usb: core: Add "quirks" parameter for usbcore

[Kai Heng Feng]

> On 6 Dec 2017, at 10:10 PM, Greg KH  wrote:
> 
> On Wed, Dec 06, 2017 at 06:26:21PM +0800, Kai-Heng Feng wrote:
>> Trying quirks in usbcore needs to rebuild the driver or the entire
>> kernel if it's builtin. It can save a lot of time if usbcore has similar
>> ability like "usbhid.quirks=" and "usb-storage.quirks=".
>> 
>> Rename the original quirk detection function to "static" as we introduce
>> this new "dynamic" function.
>> 
>> Now users can use "usbcore.quirks=" as short term workaround before the
>> next kernel release.
>> 
>> This is inspired by usbhid and usb-storage.
>> 
>> Signed-off-by: Kai-Heng Feng 
>> ---
>> v2: use in-kernel tolower() function.
>> 
>> Documentation/admin-guide/kernel-parameters.txt |  55 +
>> drivers/usb/core/quirks.c   | 100 
>> ++--
>> include/linux/usb/quirks.h  |   2 +
>> 3 files changed, 151 insertions(+), 6 deletions(-)
>> 
>> diff --git a/Documentation/admin-guide/kernel-parameters.txt 
>> b/Documentation/admin-guide/kernel-parameters.txt
>> index 6571fbfdb2a1..d42fb278320b 100644
>> --- a/Documentation/admin-guide/kernel-parameters.txt
>> +++ b/Documentation/admin-guide/kernel-parameters.txt
>> @@ -4302,6 +4302,61 @@
>> 
>>  usbcore.nousb   [USB] Disable the USB subsystem
>> 
>> +usbcore.quirks=
>> +[USB] A list of quirks entries to supplement or
>> +override the built-in usb core quirk list.  List
>> +entries are separated by commas.  Each entry has
>> +the form VID:PID:Flags where VID and PID are Vendor
>> +and Product ID values (4-digit hex numbers) and
>> +Flags is a set of characters, each corresponding
>> +to a common usb core quirk flag as follows:
>> +a = USB_QUIRK_STRING_FETCH_255 (string
>> +descriptors must not be fetched using
>> +a 255-byte read);
>> +b = USB_QUIRK_RESET_RESUME (device can't resume
>> +correctly so reset it instead);
>> +c = USB_QUIRK_NO_SET_INTF (device can't handle
>> +Set-Interface requests);
>> +d = USB_QUIRK_CONFIG_INTF_STRINGS (device can't
>> +handle its Configuration or Interface
>> +strings);
>> +e = USB_QUIRK_RESET (device can't be reset
>> +(e.g morph devices), don't use reset);
>> +f = USB_QUIRK_HONOR_BNUMINTERFACES (device has
>> +more interface descriptions than the
>> +bNumInterfaces count, and can't handle
>> +talking to these interfaces);
>> +g = USB_QUIRK_DELAY_INIT (device needs a pause
>> +during initialization, after we read
>> +the device descriptor);
>> +h = USB_QUIRK_LINEAR_UFRAME_INTR_BINTERVAL (For
>> +high speed and super speed interrupt
>> +endpoints, the USB 2.0 and USB 3.0 spec
>> +require the interval in microframes (1
>> +microframe = 125 microseconds) to be
>> +calculated as interval = 2 ^
>> +(bInterval-1).
>> +Devices with this quirk report their
>> +bInterval as the result of this
>> +calculation instead of the exponent
>> +variable used in the calculation);
>> +i = USB_QUIRK_DEVICE_QUALIFIER (device can't
>> +handle device_qualifier descriptor
>> +requests);
>> +j = USB_QUIRK_IGNORE_REMOTE_WAKEUP (device
>> +generates spurious wakeup, ignore
>> +remote wakeup capability);
>> +k = USB_QUIRK_NO_LPM (device can't handle Link
>> +Power Management);
>> +l = USB_QUIRK_LINEAR_FRAME_INTR_BINTERVAL
>> +(Device reports its bInterval as linear
>> +frames instead of the USB 2.0
>> +calculation);
>> +m = 

Re: [PATCH v2] usb: core: Add "quirks" parameter for usbcore

[Kai Heng Feng]

> On 6 Dec 2017, at 10:10 PM, Greg KH  wrote:
> 
> On Wed, Dec 06, 2017 at 06:26:21PM +0800, Kai-Heng Feng wrote:
>> Trying quirks in usbcore needs to rebuild the driver or the entire
>> kernel if it's builtin. It can save a lot of time if usbcore has similar
>> ability like "usbhid.quirks=" and "usb-storage.quirks=".
>> 
>> Rename the original quirk detection function to "static" as we introduce
>> this new "dynamic" function.
>> 
>> Now users can use "usbcore.quirks=" as short term workaround before the
>> next kernel release.
>> 
>> This is inspired by usbhid and usb-storage.
>> 
>> Signed-off-by: Kai-Heng Feng 
>> ---
>> v2: use in-kernel tolower() function.
>> 
>> Documentation/admin-guide/kernel-parameters.txt |  55 +
>> drivers/usb/core/quirks.c   | 100 
>> ++--
>> include/linux/usb/quirks.h  |   2 +
>> 3 files changed, 151 insertions(+), 6 deletions(-)
>> 
>> diff --git a/Documentation/admin-guide/kernel-parameters.txt 
>> b/Documentation/admin-guide/kernel-parameters.txt
>> index 6571fbfdb2a1..d42fb278320b 100644
>> --- a/Documentation/admin-guide/kernel-parameters.txt
>> +++ b/Documentation/admin-guide/kernel-parameters.txt
>> @@ -4302,6 +4302,61 @@
>> 
>>  usbcore.nousb   [USB] Disable the USB subsystem
>> 
>> +usbcore.quirks=
>> +[USB] A list of quirks entries to supplement or
>> +override the built-in usb core quirk list.  List
>> +entries are separated by commas.  Each entry has
>> +the form VID:PID:Flags where VID and PID are Vendor
>> +and Product ID values (4-digit hex numbers) and
>> +Flags is a set of characters, each corresponding
>> +to a common usb core quirk flag as follows:
>> +a = USB_QUIRK_STRING_FETCH_255 (string
>> +descriptors must not be fetched using
>> +a 255-byte read);
>> +b = USB_QUIRK_RESET_RESUME (device can't resume
>> +correctly so reset it instead);
>> +c = USB_QUIRK_NO_SET_INTF (device can't handle
>> +Set-Interface requests);
>> +d = USB_QUIRK_CONFIG_INTF_STRINGS (device can't
>> +handle its Configuration or Interface
>> +strings);
>> +e = USB_QUIRK_RESET (device can't be reset
>> +(e.g morph devices), don't use reset);
>> +f = USB_QUIRK_HONOR_BNUMINTERFACES (device has
>> +more interface descriptions than the
>> +bNumInterfaces count, and can't handle
>> +talking to these interfaces);
>> +g = USB_QUIRK_DELAY_INIT (device needs a pause
>> +during initialization, after we read
>> +the device descriptor);
>> +h = USB_QUIRK_LINEAR_UFRAME_INTR_BINTERVAL (For
>> +high speed and super speed interrupt
>> +endpoints, the USB 2.0 and USB 3.0 spec
>> +require the interval in microframes (1
>> +microframe = 125 microseconds) to be
>> +calculated as interval = 2 ^
>> +(bInterval-1).
>> +Devices with this quirk report their
>> +bInterval as the result of this
>> +calculation instead of the exponent
>> +variable used in the calculation);
>> +i = USB_QUIRK_DEVICE_QUALIFIER (device can't
>> +handle device_qualifier descriptor
>> +requests);
>> +j = USB_QUIRK_IGNORE_REMOTE_WAKEUP (device
>> +generates spurious wakeup, ignore
>> +remote wakeup capability);
>> +k = USB_QUIRK_NO_LPM (device can't handle Link
>> +Power Management);
>> +l = USB_QUIRK_LINEAR_FRAME_INTR_BINTERVAL
>> +(Device reports its bInterval as linear
>> +frames instead of the USB 2.0
>> +calculation);
>> +m = USB_QUIRK_DISCONNECT_SUSPEND (Device needs
>> +

Re: [PATCH v3 2/3] clk: hisilicon: Add support for Hi3660 stub clocks

[Stephen Boyd]

On 11/17, Xu YiPing wrote:
> From: Kaihua Zhong 
> +
> +static struct clk_hw *hi3660_stub_clk_hw_get(struct of_phandle_args *clkspec,
> +  void *data)
> +{
> + unsigned int idx = clkspec->args[0];
> +
> + if (idx > HI3660_CLK_STUB_NUM) {

This should be >=

> + }
> +
> + return _stub_clks[idx].hw;
> +}
> +
> +static int hi3660_stub_clk_probe(struct platform_device *pdev)
> +{
> + struct device *dev = >dev;
> + struct resource *res;
> + unsigned int i;
> + int ret;
> +
> + /* Use mailbox client without blocking */
> + stub_clk_chan.cl.dev = dev;
> + stub_clk_chan.cl.tx_done = NULL;
> + stub_clk_chan.cl.tx_block = false;
> + stub_clk_chan.cl.knows_txdone = false;
> +
> + /* Allocate mailbox channel */
> + stub_clk_chan.mbox = mbox_request_channel(_clk_chan.cl, 0);
> + if (IS_ERR(stub_clk_chan.mbox))
> + return PTR_ERR(stub_clk_chan.mbox);
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + freq_reg = devm_ioremap(dev, res->start, resource_size(res));
> + if (IS_ERR(freq_reg))

Pretty sure this returns NULL on failure, not an error pointer.

> + return -ENOMEM;
> +
> + freq_reg += HI3660_STUB_CLOCK_DATA;
> +
> + for (i = 0; i < HI3660_CLK_STUB_NUM; i++) {
> + ret = devm_clk_hw_register(>dev, _stub_clks[i].hw);
> + if (ret)
> + return ret;
> + }
> +
> + ret = of_clk_add_hw_provider(pdev->dev.of_node, hi3660_stub_clk_hw_get,
> +  hi3660_stub_clks);

This can use devm

> + return ret;
> +}
> +

I fixed it all and merged into clk-next.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v3 2/3] clk: hisilicon: Add support for Hi3660 stub clocks

[Stephen Boyd]

On 11/17, Xu YiPing wrote:
> From: Kaihua Zhong 
> +
> +static struct clk_hw *hi3660_stub_clk_hw_get(struct of_phandle_args *clkspec,
> +  void *data)
> +{
> + unsigned int idx = clkspec->args[0];
> +
> + if (idx > HI3660_CLK_STUB_NUM) {

This should be >=

> + }
> +
> + return _stub_clks[idx].hw;
> +}
> +
> +static int hi3660_stub_clk_probe(struct platform_device *pdev)
> +{
> + struct device *dev = >dev;
> + struct resource *res;
> + unsigned int i;
> + int ret;
> +
> + /* Use mailbox client without blocking */
> + stub_clk_chan.cl.dev = dev;
> + stub_clk_chan.cl.tx_done = NULL;
> + stub_clk_chan.cl.tx_block = false;
> + stub_clk_chan.cl.knows_txdone = false;
> +
> + /* Allocate mailbox channel */
> + stub_clk_chan.mbox = mbox_request_channel(_clk_chan.cl, 0);
> + if (IS_ERR(stub_clk_chan.mbox))
> + return PTR_ERR(stub_clk_chan.mbox);
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + freq_reg = devm_ioremap(dev, res->start, resource_size(res));
> + if (IS_ERR(freq_reg))

Pretty sure this returns NULL on failure, not an error pointer.

> + return -ENOMEM;
> +
> + freq_reg += HI3660_STUB_CLOCK_DATA;
> +
> + for (i = 0; i < HI3660_CLK_STUB_NUM; i++) {
> + ret = devm_clk_hw_register(>dev, _stub_clks[i].hw);
> + if (ret)
> + return ret;
> + }
> +
> + ret = of_clk_add_hw_provider(pdev->dev.of_node, hi3660_stub_clk_hw_get,
> +  hi3660_stub_clks);

This can use devm

> + return ret;
> +}
> +

I fixed it all and merged into clk-next.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCHv4 4/4] x86/boot/compressed/64: Handle 5-level paging boot if kernel is above 4G

[Ingo Molnar]

* Kirill A. Shutemov  wrote:

> This patch addresses a shortcoming in current boot process on machines
> that supports 5-level paging.

s/in current boot process
 /in the current boot process

> If a bootloader enables 64-bit mode with 4-level paging, we might need to
> switch over to 5-level paging. The switching requires disabling paging.
> It works fine if kernel itself is loaded below 4G.

s/The switching requires disabling paging.
 /The switching requires the disabling of paging.

> But if the bootloader put the kernel above 4G (not sure if anybody does
> this), we would loose control as soon as paging is disabled as code
> becomes unreachable.

Same suggestion for this paragraph as for the previous patch.

> This patch implements a trampoline in lower memory to handle this
> situation.
> 
> We only need the memory for very short time, until main kernel image
> would setup its own page tables.

s/We only need the memory for very short time
 /We only need this memory for a very short time

s/until main kernel image would setup its own page tables.
 /until the main kernel image sets up its own page tables.

> We go through trampoline even if we don't have to: if we're already in
> 5-level paging mode or if we don't need to switch to it. This way the
> trampoline gets tested on every boot.

s/We go through trampoline
 /We go through the trampoline

>   /*
>* At this point we are in long mode with 4-level paging enabled,
> +  * but we might want to enable 5-level paging.
>*
> +  * The problem is that we cannot do it directly. Setting CR.LA57
> +  * in the long mode would trigger #GP. So we need to switch off
> +  * long mode and paging first.

s/Setting CR.LA57 in the long mode
 /Setting CR.LA57 in long mode

Also, why only say 'CR', why not 'CR4'?

> +  *
> +  * We also need a trampoline in lower memory to switch over from
> +  * 4- to 5-level paging for cases when bootloader put kernel above
> +  * 4G, but didn't enable 5-level paging for us.

s/for cases when bootloader put kernel above 4G
 /for cases when the bootloader puts the kernel above 4G

> +  *
> +  * For the trampoline, we need top page table in lower memory as
> +  * we don't have a way to load 64-bit value into CR3 from 32-bit
> +  * mode.

s/we need top page table in lower memory
 /we need the top page table to reside in lower memory

s/load 64-bit value into CR3 from 32-bit mode
 /load 64-bit values into CR3 in 32-bit mode

> +  *
> +  * We go though the trampoline even if we don't have to: if we're
> +  * already in 5-level paging mode or if we don't need to switch to
> +  * it. This way the trampoline code gets tested on every boot.

>   /*
> +  * Load address of trampoline_return into RDI.
> +  * It will be used by trampoline to return to main code.

s/Load address of trampoline_return
 /Load the address of trampoline_return

s/It will be used by trampoline to return to main code
 /It will be used by the trampoline to return to the main code

> +trampoline_return:
> + /* Restore stack, 32-bit trampoline uses own stack */
> + leaqboot_stack_end(%rbx), %rsp

This phrasing would be a bit clearer:

/* Restore the stack, the 32-bit trampoline uses its own stack */

> +/*
> + * This is 32-bit trampoline that will be copied over to low memory.

s/This is 32-bit trampoline that will be
 /This is the 32-bit trampoline that will be

> + *
> + * RDI contains return address (might be above 4G).

s/RDI contains return address (might be above 4G)
 /RDI contains the return address (might be above 4G)

> + * ECX contains the base address of trampoline memory.

s/of trampoline memory
 /of the trampoline memory

> + /* For 5-level paging, point CR3 to trampoline's new top level page 
> table */

s/point CR3 to trampoline's new top level page table
 /point CR3 to the trampoline's new top level page table

> + testl   $1, %ecx
> + jz  1f
> + lealTRAMPOLINE_32BIT_PGTABLE_OFF (%edx), %eax

BTW., could you please spell out 'OFFSET'? 'OFF' reminds me of the ON/OFF 
pattern. 
The constant is hopelessly long anyway ;-)

Also:

s/TRAMPOLINE_32BIT_PGTABLE_OFF (%edx)
 /TRAMPOLINE_32BIT_PGTABLE_OFF(%edx)

(This applies to the rest of the patch as well.)

> - /* Enable PAE and LA57 mode */
> + /* Enable PAE and LA57 (if required) modes */

A bit more clarity:

s/modes
 /paging modes

> + /* Calculate address of paging_enabled once we are in trampoline */

Please use the same function name reference as I suggested for the previous 
patch.

s/once we are in trampoline
 /once we are executing in the trampoline

>   /* Prepare stack for far return to Long Mode */

s/Prepare stack
 /Prepare the stack

>   /* Enable paging back */

s/Enable paging back
 /Enable paging again

> + .code64
> +paging_enabled:
> + /* Return from the trampoline */
> + jmp *%rdi
> +
> +   

Re: [PATCHv4 4/4] x86/boot/compressed/64: Handle 5-level paging boot if kernel is above 4G

[Ingo Molnar]

* Kirill A. Shutemov  wrote:

> This patch addresses a shortcoming in current boot process on machines
> that supports 5-level paging.

s/in current boot process
 /in the current boot process

> If a bootloader enables 64-bit mode with 4-level paging, we might need to
> switch over to 5-level paging. The switching requires disabling paging.
> It works fine if kernel itself is loaded below 4G.

s/The switching requires disabling paging.
 /The switching requires the disabling of paging.

> But if the bootloader put the kernel above 4G (not sure if anybody does
> this), we would loose control as soon as paging is disabled as code
> becomes unreachable.

Same suggestion for this paragraph as for the previous patch.

> This patch implements a trampoline in lower memory to handle this
> situation.
> 
> We only need the memory for very short time, until main kernel image
> would setup its own page tables.

s/We only need the memory for very short time
 /We only need this memory for a very short time

s/until main kernel image would setup its own page tables.
 /until the main kernel image sets up its own page tables.

> We go through trampoline even if we don't have to: if we're already in
> 5-level paging mode or if we don't need to switch to it. This way the
> trampoline gets tested on every boot.

s/We go through trampoline
 /We go through the trampoline

>   /*
>* At this point we are in long mode with 4-level paging enabled,
> +  * but we might want to enable 5-level paging.
>*
> +  * The problem is that we cannot do it directly. Setting CR.LA57
> +  * in the long mode would trigger #GP. So we need to switch off
> +  * long mode and paging first.

s/Setting CR.LA57 in the long mode
 /Setting CR.LA57 in long mode

Also, why only say 'CR', why not 'CR4'?

> +  *
> +  * We also need a trampoline in lower memory to switch over from
> +  * 4- to 5-level paging for cases when bootloader put kernel above
> +  * 4G, but didn't enable 5-level paging for us.

s/for cases when bootloader put kernel above 4G
 /for cases when the bootloader puts the kernel above 4G

> +  *
> +  * For the trampoline, we need top page table in lower memory as
> +  * we don't have a way to load 64-bit value into CR3 from 32-bit
> +  * mode.

s/we need top page table in lower memory
 /we need the top page table to reside in lower memory

s/load 64-bit value into CR3 from 32-bit mode
 /load 64-bit values into CR3 in 32-bit mode

> +  *
> +  * We go though the trampoline even if we don't have to: if we're
> +  * already in 5-level paging mode or if we don't need to switch to
> +  * it. This way the trampoline code gets tested on every boot.

>   /*
> +  * Load address of trampoline_return into RDI.
> +  * It will be used by trampoline to return to main code.

s/Load address of trampoline_return
 /Load the address of trampoline_return

s/It will be used by trampoline to return to main code
 /It will be used by the trampoline to return to the main code

> +trampoline_return:
> + /* Restore stack, 32-bit trampoline uses own stack */
> + leaqboot_stack_end(%rbx), %rsp

This phrasing would be a bit clearer:

/* Restore the stack, the 32-bit trampoline uses its own stack */

> +/*
> + * This is 32-bit trampoline that will be copied over to low memory.

s/This is 32-bit trampoline that will be
 /This is the 32-bit trampoline that will be

> + *
> + * RDI contains return address (might be above 4G).

s/RDI contains return address (might be above 4G)
 /RDI contains the return address (might be above 4G)

> + * ECX contains the base address of trampoline memory.

s/of trampoline memory
 /of the trampoline memory

> + /* For 5-level paging, point CR3 to trampoline's new top level page 
> table */

s/point CR3 to trampoline's new top level page table
 /point CR3 to the trampoline's new top level page table

> + testl   $1, %ecx
> + jz  1f
> + lealTRAMPOLINE_32BIT_PGTABLE_OFF (%edx), %eax

BTW., could you please spell out 'OFFSET'? 'OFF' reminds me of the ON/OFF 
pattern. 
The constant is hopelessly long anyway ;-)

Also:

s/TRAMPOLINE_32BIT_PGTABLE_OFF (%edx)
 /TRAMPOLINE_32BIT_PGTABLE_OFF(%edx)

(This applies to the rest of the patch as well.)

> - /* Enable PAE and LA57 mode */
> + /* Enable PAE and LA57 (if required) modes */

A bit more clarity:

s/modes
 /paging modes

> + /* Calculate address of paging_enabled once we are in trampoline */

Please use the same function name reference as I suggested for the previous 
patch.

s/once we are in trampoline
 /once we are executing in the trampoline

>   /* Prepare stack for far return to Long Mode */

s/Prepare stack
 /Prepare the stack

>   /* Enable paging back */

s/Enable paging back
 /Enable paging again

> + .code64
> +paging_enabled:
> + /* Return from the trampoline */
> + jmp *%rdi
> +
> + /*
> +  * Bound size of 

Re: [PATCH 2/2] arm64: allwinner: a64: bananapi-m64: add usb otg

[Chen-Yu Tsai]

On Thu, Dec 7, 2017 at 2:54 PM, Jagan Teki  wrote:
> On Thu, Dec 7, 2017 at 11:56 AM, Chen-Yu Tsai  wrote:
>> On Thu, Dec 7, 2017 at 2:18 PM, Jagan Teki  wrote:
>>> On Thu, Dec 7, 2017 at 8:54 AM, Chen-Yu Tsai  wrote:
 On Thu, Dec 7, 2017 at 1:51 AM, Jagan Teki  
 wrote:
> usb otg on bananapi-m64 has configured with USB-ID with PH9
> and USB-DRVVBUS attached with dcdc1 regulatort.

 That is not how you read the schematic...

 Intersecting lines that are tied together will have a dot representing
 the connection. The DCDC1 line is a pull-up for the ID pin. This is very
 clear because it has a resistor connected in series.

 VBUS for OTG is controlled by the IC displayed to the right in the
 schematic, which is powered from 5V, and controlled by the DRVVBUS
 pin from the PMIC. Please take a look at how the A31/A33/A83T board
 dts files represent this.
>>>
>>> This is where I confused, USB-DRVVBUS is connected to pin 51 of PMIC
>>> if we add 5v regulator how can configure gpio number for this? I saw
>>
>> From the axp20x bindings:
>>
>> - x-powers,drive-vbus-en: boolean, set this when the N_VBUSEN pin is
>>   used as an output pin to control an external
>>   regulator to drive the OTG VBus, rather then
>>   as an input pin which signals whether the
>>   board is driving OTG VBus or not.
>>   (axp221 / axp223 / axp813 only)
>>
>> Setting this allows you to use the "drivevbus" regulator under the PMIC.
>> As I said, look at how other boards are doing it.
>>
>>> sun8i-a33-olinuxino.dts which is also similar but it has gpio = <
>>> 1 9 GPIO_ACTIVE_HIGH>;
>>
>> I have no idea where you saw this. It does not exist in my tree.
>>
>> Why don't you just trace backwards from the usb0_vbus-supply property
>> under the usbphy node, and see where it all leads.
>
> This what exactly I did, usb0_vbus-supply = <_drivevbus>; on

This is not what you did in your patch.

> sun8i-a33-olinuxino.dts is using usb0-vbus from
> sunxi-common-regulators.dtsi. reg_usb0_vbus regulator using gpio9
> which I couldn't find it on schematics.

And I'm telling you that in mainline a33-olinuxino.dts it is:

usb0_vbus-supply = <_drivevbus>;

It has been that way since the initial commit adding the file.
What tree are you looking at exactly? Take a good look at everything,
including your patch, and stop arguing.

ChenYu

Re: [PATCH 2/2] arm64: allwinner: a64: bananapi-m64: add usb otg

[Chen-Yu Tsai]

On Thu, Dec 7, 2017 at 2:54 PM, Jagan Teki  wrote:
> On Thu, Dec 7, 2017 at 11:56 AM, Chen-Yu Tsai  wrote:
>> On Thu, Dec 7, 2017 at 2:18 PM, Jagan Teki  wrote:
>>> On Thu, Dec 7, 2017 at 8:54 AM, Chen-Yu Tsai  wrote:
 On Thu, Dec 7, 2017 at 1:51 AM, Jagan Teki  
 wrote:
> usb otg on bananapi-m64 has configured with USB-ID with PH9
> and USB-DRVVBUS attached with dcdc1 regulatort.

 That is not how you read the schematic...

 Intersecting lines that are tied together will have a dot representing
 the connection. The DCDC1 line is a pull-up for the ID pin. This is very
 clear because it has a resistor connected in series.

 VBUS for OTG is controlled by the IC displayed to the right in the
 schematic, which is powered from 5V, and controlled by the DRVVBUS
 pin from the PMIC. Please take a look at how the A31/A33/A83T board
 dts files represent this.
>>>
>>> This is where I confused, USB-DRVVBUS is connected to pin 51 of PMIC
>>> if we add 5v regulator how can configure gpio number for this? I saw
>>
>> From the axp20x bindings:
>>
>> - x-powers,drive-vbus-en: boolean, set this when the N_VBUSEN pin is
>>   used as an output pin to control an external
>>   regulator to drive the OTG VBus, rather then
>>   as an input pin which signals whether the
>>   board is driving OTG VBus or not.
>>   (axp221 / axp223 / axp813 only)
>>
>> Setting this allows you to use the "drivevbus" regulator under the PMIC.
>> As I said, look at how other boards are doing it.
>>
>>> sun8i-a33-olinuxino.dts which is also similar but it has gpio = <
>>> 1 9 GPIO_ACTIVE_HIGH>;
>>
>> I have no idea where you saw this. It does not exist in my tree.
>>
>> Why don't you just trace backwards from the usb0_vbus-supply property
>> under the usbphy node, and see where it all leads.
>
> This what exactly I did, usb0_vbus-supply = <_drivevbus>; on

This is not what you did in your patch.

> sun8i-a33-olinuxino.dts is using usb0-vbus from
> sunxi-common-regulators.dtsi. reg_usb0_vbus regulator using gpio9
> which I couldn't find it on schematics.

And I'm telling you that in mainline a33-olinuxino.dts it is:

usb0_vbus-supply = <_drivevbus>;

It has been that way since the initial commit adding the file.
What tree are you looking at exactly? Take a good look at everything,
including your patch, and stop arguing.

ChenYu

Re: Timer refuses to expire

[Boqun Feng]

Hi Paul,

On Wed, Dec 06, 2017 at 02:04:21PM -0800, Paul E. McKenney wrote:
> On Tue, Dec 05, 2017 at 03:37:44PM -0800, Paul E. McKenney wrote:
> > On Mon, Dec 04, 2017 at 09:42:08AM -0800, Paul E. McKenney wrote:
> > > On Fri, Dec 01, 2017 at 10:25:29AM -0800, Paul E. McKenney wrote:
> > > > Hello, Anna-Maria,
> > > > 
> > > > It turned out that one set of problems was due to NO_HZ_FULL issues,
> > > > which are addressed with a pair of patches.  However, there is still one
> > > > case of a timer refusing to expire in rcutorture's TREE01 test scenario.
> > > > The takes from two to four hours to trigger, and the most recent one
> > > > gives the following diagnostic (see patch at the very end of this 
> > > > email):
> > > > 
> > > > [13166.127458] schedule_timeout: Waylayed timer base->clk: 0x100c40004 
> > > > jiffies: 0x100c4524e base->next_expiry: 0x100c40004 timer->flags: 
> > > > 0x103 timer->expires 0x100c40003 idx: 4 idx_now: ea 
> > > > base->pending_map 
> > > > 0010001080040204
> > > > 
> > > > The message appears any time a timer for less than five jiffies takes
> > > > more than eight seconds to expire.  In all cases, this expiry did not
> > > > happen naturally, but rather via an unsolicited wakeup from the RCU CPU
> > > > stall code.  If I am interpreting this message correctly, base->clk
> > > > has advanced past this timer, and the timer is correctly flagged in
> > > > base->pending_map.  This seems like part of the problem because the
> > > > timer's timeout was only three jiffies.  However, base->clk has not
> > > > advanced for more than 20 seconds, which seems like another problem.
> > > > 
> > > > What additional diagnostics would be helpful?  I can capture data
> > > > at the beginning of the schedule_timeout in the timer_list structure,
> > > > and of course can print more information at the time of the wakeup.
> > > 
> > > And on the off-chance that the following messages from this weekend's
> > > runs are at all helpful.  One interesting point is that starting at
> > > time 4731.872311, there are repeated enqueues to CPU 5's timer wheel,
> > > but CPU 5's ->clk does not advance.  Things seem to advance at
> > > time 4891.721190.
> > 
> > Another layer on the onion...  For at least some of the failures, there
> > is a stalled CPU-hotplug operation.  This of course can mean that the
> > timers are stuck on the partially offlined CPU.  So I dumped the stack
> > of the task that is taking the CPU offline.  Please see below for console
> > output and patch.
> > 
> > I am considering doing an unsolicited wakeup of the task doing the
> > hotplug operation, but I am not convinced that the entirely of the CPU
> > hotplug code is willing to put up with that sort of thing.
> 
> What I did instead was to dump out the state of the task that
> __cpuhp_kick_ap() waits on, please see the patch at the very end of this
> email.  This triggered as shown below, and you guessed it, that task is
> waiting on a grace period.  Which I am guessing won't happen until the
> outgoing CPU reaches CPUHP_TIMERS_DEAD state and calls timers_dead_cpu().
> Which will prevent RCU's grace-period kthread from ever awakening, which
> will prevent the task that __cpuhp_kick_ap() waits on from ever awakening,
> which will prevent the outgoing CPU from reaching CPUHP_TIMERS_DEAD state.
> 
> Deadlock.
> 

There is one thing I'm confused here. Sure, this is a deadlock, but the
timer should still work in such a deadlock, right? I mean, the timer of
schedule_timeout() should be able to wake up rcu_gp_kthread() even in
this case? And yes, the gp kthread will continue to wait due to the
deadlock, but the deadlock can not explain the "Waylayed timer", right?

Regards,
Boqun

> Does that make sense, or am I missing a trick here?
> 
> I tried invoking timers_dead_cpu() from sched_cpu_deactivate(), but
> that triggered the BUG_ON(cpu_online(cpu)).  I removed this BUG_ON(),
> and appear to have deadlocked on the timer ->lock.
> 
> Any thoughts on what else to try?
> 
>   Thanx, Paul
> 
> 
> 
> [ 2939.381210] schedule_timeout: Waylayed timer base->clk: 0x1002709c3 
> jiffies: 0x100284614 base->next_expiry: 0x1002709c3 timer->flags: 0x4007 
> timer->expires 0x10027f3a2 idx: 100 idx_now: 105 base->pending_map 
> 0008000202008042000868010100
> [ 2939.381219] Torture onoff task state:
> [ 2939.381221] torture_onoff   D14584   842  2 0x8000
> [ 2939.381239] Call Trace:
> [ 2939.381245]  ? __schedule+0x33c/0x6f0
> [ 2939.381248]  ? preempt_count_add+0x51/0x90
> [ 2939.381250]  schedule+0x37/0x90
> [ 2939.381270]  schedule_timeout+0x20d/0x4c0
> [ 2939.381276]  

Re: Timer refuses to expire

[Boqun Feng]

Hi Paul,

On Wed, Dec 06, 2017 at 02:04:21PM -0800, Paul E. McKenney wrote:
> On Tue, Dec 05, 2017 at 03:37:44PM -0800, Paul E. McKenney wrote:
> > On Mon, Dec 04, 2017 at 09:42:08AM -0800, Paul E. McKenney wrote:
> > > On Fri, Dec 01, 2017 at 10:25:29AM -0800, Paul E. McKenney wrote:
> > > > Hello, Anna-Maria,
> > > > 
> > > > It turned out that one set of problems was due to NO_HZ_FULL issues,
> > > > which are addressed with a pair of patches.  However, there is still one
> > > > case of a timer refusing to expire in rcutorture's TREE01 test scenario.
> > > > The takes from two to four hours to trigger, and the most recent one
> > > > gives the following diagnostic (see patch at the very end of this 
> > > > email):
> > > > 
> > > > [13166.127458] schedule_timeout: Waylayed timer base->clk: 0x100c40004 
> > > > jiffies: 0x100c4524e base->next_expiry: 0x100c40004 timer->flags: 
> > > > 0x103 timer->expires 0x100c40003 idx: 4 idx_now: ea 
> > > > base->pending_map 
> > > > 0010001080040204
> > > > 
> > > > The message appears any time a timer for less than five jiffies takes
> > > > more than eight seconds to expire.  In all cases, this expiry did not
> > > > happen naturally, but rather via an unsolicited wakeup from the RCU CPU
> > > > stall code.  If I am interpreting this message correctly, base->clk
> > > > has advanced past this timer, and the timer is correctly flagged in
> > > > base->pending_map.  This seems like part of the problem because the
> > > > timer's timeout was only three jiffies.  However, base->clk has not
> > > > advanced for more than 20 seconds, which seems like another problem.
> > > > 
> > > > What additional diagnostics would be helpful?  I can capture data
> > > > at the beginning of the schedule_timeout in the timer_list structure,
> > > > and of course can print more information at the time of the wakeup.
> > > 
> > > And on the off-chance that the following messages from this weekend's
> > > runs are at all helpful.  One interesting point is that starting at
> > > time 4731.872311, there are repeated enqueues to CPU 5's timer wheel,
> > > but CPU 5's ->clk does not advance.  Things seem to advance at
> > > time 4891.721190.
> > 
> > Another layer on the onion...  For at least some of the failures, there
> > is a stalled CPU-hotplug operation.  This of course can mean that the
> > timers are stuck on the partially offlined CPU.  So I dumped the stack
> > of the task that is taking the CPU offline.  Please see below for console
> > output and patch.
> > 
> > I am considering doing an unsolicited wakeup of the task doing the
> > hotplug operation, but I am not convinced that the entirely of the CPU
> > hotplug code is willing to put up with that sort of thing.
> 
> What I did instead was to dump out the state of the task that
> __cpuhp_kick_ap() waits on, please see the patch at the very end of this
> email.  This triggered as shown below, and you guessed it, that task is
> waiting on a grace period.  Which I am guessing won't happen until the
> outgoing CPU reaches CPUHP_TIMERS_DEAD state and calls timers_dead_cpu().
> Which will prevent RCU's grace-period kthread from ever awakening, which
> will prevent the task that __cpuhp_kick_ap() waits on from ever awakening,
> which will prevent the outgoing CPU from reaching CPUHP_TIMERS_DEAD state.
> 
> Deadlock.
> 

There is one thing I'm confused here. Sure, this is a deadlock, but the
timer should still work in such a deadlock, right? I mean, the timer of
schedule_timeout() should be able to wake up rcu_gp_kthread() even in
this case? And yes, the gp kthread will continue to wait due to the
deadlock, but the deadlock can not explain the "Waylayed timer", right?

Regards,
Boqun

> Does that make sense, or am I missing a trick here?
> 
> I tried invoking timers_dead_cpu() from sched_cpu_deactivate(), but
> that triggered the BUG_ON(cpu_online(cpu)).  I removed this BUG_ON(),
> and appear to have deadlocked on the timer ->lock.
> 
> Any thoughts on what else to try?
> 
>   Thanx, Paul
> 
> 
> 
> [ 2939.381210] schedule_timeout: Waylayed timer base->clk: 0x1002709c3 
> jiffies: 0x100284614 base->next_expiry: 0x1002709c3 timer->flags: 0x4007 
> timer->expires 0x10027f3a2 idx: 100 idx_now: 105 base->pending_map 
> 0008000202008042000868010100
> [ 2939.381219] Torture onoff task state:
> [ 2939.381221] torture_onoff   D14584   842  2 0x8000
> [ 2939.381239] Call Trace:
> [ 2939.381245]  ? __schedule+0x33c/0x6f0
> [ 2939.381248]  ? preempt_count_add+0x51/0x90
> [ 2939.381250]  schedule+0x37/0x90
> [ 2939.381270]  schedule_timeout+0x20d/0x4c0
> [ 2939.381276]  

Re: [PATCH v3 1/3] dt-bindings: clk: Hi3660: Document stub clock

[Stephen Boyd]

On 11/17, Xu YiPing wrote:
> From: Leo Yan 
> 
> Document the DT binding for stub clock which is used for CPU,
> GPU and DDR frequency scaling.
> 
> Acked-by: Rob Herring 
> Signed-off-by: Leo Yan 
> ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v3 1/3] dt-bindings: clk: Hi3660: Document stub clock

[Stephen Boyd]

On 11/17, Xu YiPing wrote:
> From: Leo Yan 
> 
> Document the DT binding for stub clock which is used for CPU,
> GPU and DDR frequency scaling.
> 
> Acked-by: Rob Herring 
> Signed-off-by: Leo Yan 
> ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 01/10] staging: ccree: remove inline qualifiers

[Gilad Ben-Yossef]

On Mon, Dec 4, 2017 at 11:36 AM, Dan Carpenter  wrote:
> On Sun, Dec 03, 2017 at 01:58:12PM +, Gilad Ben-Yossef wrote:
>> The ccree drivers was marking a lot of big functions in C file as
>> static inline for no good reason. Remove the inline qualifier from
>> any but the few truly single line functions.
>>
>
> The compiler is free to ignore inline hints...  It probably would make
> single line functions inline anyway.
>

Yes. I think of it more as a note to the reader: "don't add stuff to
this function. it is meant to be short and simple".


-- 
Gilad Ben-Yossef
Chief Coffee Drinker

"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
 -- Jean-Baptiste Queru

Re: [PATCH 01/10] staging: ccree: remove inline qualifiers

[Gilad Ben-Yossef]

On Mon, Dec 4, 2017 at 11:36 AM, Dan Carpenter  wrote:
> On Sun, Dec 03, 2017 at 01:58:12PM +, Gilad Ben-Yossef wrote:
>> The ccree drivers was marking a lot of big functions in C file as
>> static inline for no good reason. Remove the inline qualifier from
>> any but the few truly single line functions.
>>
>
> The compiler is free to ignore inline hints...  It probably would make
> single line functions inline anyway.
>

Yes. I think of it more as a note to the reader: "don't add stuff to
this function. it is meant to be short and simple".


-- 
Gilad Ben-Yossef
Chief Coffee Drinker

"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
 -- Jean-Baptiste Queru

Re: [PATCH] checkpatch: add check for tag Co-Developed-by

[Joe Perches]

On Thu, 2017-12-07 at 07:55 +0100, Greg Kroah-Hartman wrote:
> On Wed, Dec 06, 2017 at 10:34:26PM -0800, Joe Perches wrote:
> > On Thu, 2017-12-07 at 11:59 +1100, Tobin C. Harding wrote:
> > > Recently signature tag Co-Developed-by was added to the
> > > kernel (Documentation/process/5.Posting.rst). checkpatch.pl doesn't know
> > > about it yet. All prior tags used all lowercase characters except for 
> > > first
> > > character. Checks for this format had to be re-worked to allow for the
> > > new tag.
> > > 
> > > Add checkpatch checks for Co-Developed-by tag.
> > 
> > []
> > > +++ b/scripts/checkpatch.pl
> > > @@ -468,6 +468,7 @@ our $signature_tags = qr{(?xi:
> > >   Reviewed-by:|
> > >   Reported-by:|
> > >   Suggested-by:|
> > > + Co-Developed-by:|
> > 
> > I think the extra hyphenate form is poor at best.
> > Codeveloped-by: should be the only form.
> 
> That's not what Documentation/process/5.Posting.rst says, sorry.

So what? That's easy to change.

> So Tobin's patch is correct.

Not to me.

Re: [PATCH] checkpatch: add check for tag Co-Developed-by

[Joe Perches]

On Thu, 2017-12-07 at 07:55 +0100, Greg Kroah-Hartman wrote:
> On Wed, Dec 06, 2017 at 10:34:26PM -0800, Joe Perches wrote:
> > On Thu, 2017-12-07 at 11:59 +1100, Tobin C. Harding wrote:
> > > Recently signature tag Co-Developed-by was added to the
> > > kernel (Documentation/process/5.Posting.rst). checkpatch.pl doesn't know
> > > about it yet. All prior tags used all lowercase characters except for 
> > > first
> > > character. Checks for this format had to be re-worked to allow for the
> > > new tag.
> > > 
> > > Add checkpatch checks for Co-Developed-by tag.
> > 
> > []
> > > +++ b/scripts/checkpatch.pl
> > > @@ -468,6 +468,7 @@ our $signature_tags = qr{(?xi:
> > >   Reviewed-by:|
> > >   Reported-by:|
> > >   Suggested-by:|
> > > + Co-Developed-by:|
> > 
> > I think the extra hyphenate form is poor at best.
> > Codeveloped-by: should be the only form.
> 
> That's not what Documentation/process/5.Posting.rst says, sorry.

So what? That's easy to change.

> So Tobin's patch is correct.

Not to me.

Re: [PATCH 0/1] About MIPS/Loongson maintainance

[Greg Kroah-Hartman]

On Thu, Dec 07, 2017 at 02:31:07PM +0800, Huacai Chen wrote:
> Hi, Linus, Stephen, Greg, Ralf and James,
> 
> We are kernel developers from Lemote Inc. and Loongson community. We
> have already made some contributions in Linux kernel, but we hope we
> can do more works.
> 
> Of course Loongson is a sub-arch in MIPS, but linux-mips community is
> so inactive (Maybe maintainers are too busy?) that too many patches (
> Not only for Loongson, but also for other sub-archs) were delayed for
> a long time. So we are seeking a more efficient way to make Loongson
> patches be merged in upstream.
> 
> Now we have a github organization for collaboration:
> https://github.com/linux-loongson/linux-loongson.git

Ick, why not get a kernel.org account for your git tree?

> We don't want to replace linux-mips, we just want to find a way to co-
> operate with linux-mips. So we will still use the maillist and patchwork
> of linux-mips, but we hope we can send pull requests from our github to
> linux-next and linux-mainline by ourselves (if there is no objections
> to our patches from linux-mips community).

What does the mips maintainers think about this?

Odds are a linux-next tree is fine, but they probably want to merge the
trees into their larger mips one for the pulls to Linus, much like the
arm-core tree works, right?

thanks,

greg k-h

Re: [PATCH 0/1] About MIPS/Loongson maintainance

[Greg Kroah-Hartman]

On Thu, Dec 07, 2017 at 02:31:07PM +0800, Huacai Chen wrote:
> Hi, Linus, Stephen, Greg, Ralf and James,
> 
> We are kernel developers from Lemote Inc. and Loongson community. We
> have already made some contributions in Linux kernel, but we hope we
> can do more works.
> 
> Of course Loongson is a sub-arch in MIPS, but linux-mips community is
> so inactive (Maybe maintainers are too busy?) that too many patches (
> Not only for Loongson, but also for other sub-archs) were delayed for
> a long time. So we are seeking a more efficient way to make Loongson
> patches be merged in upstream.
> 
> Now we have a github organization for collaboration:
> https://github.com/linux-loongson/linux-loongson.git

Ick, why not get a kernel.org account for your git tree?

> We don't want to replace linux-mips, we just want to find a way to co-
> operate with linux-mips. So we will still use the maillist and patchwork
> of linux-mips, but we hope we can send pull requests from our github to
> linux-next and linux-mainline by ourselves (if there is no objections
> to our patches from linux-mips community).

What does the mips maintainers think about this?

Odds are a linux-next tree is fine, but they probably want to merge the
trees into their larger mips one for the pulls to Linus, much like the
arm-core tree works, right?

thanks,

greg k-h

Re: [PATCH] checkpatch: add check for tag Co-Developed-by

[Greg Kroah-Hartman]

On Thu, Dec 07, 2017 at 11:59:36AM +1100, Tobin C. Harding wrote:
> Recently signature tag Co-Developed-by was added to the
> kernel (Documentation/process/5.Posting.rst). checkpatch.pl doesn't know
> about it yet. All prior tags used all lowercase characters except for first
> character. Checks for this format had to be re-worked to allow for the
> new tag.
> 
> Add checkpatch checks for Co-Developed-by tag.
> 
> Cc: Greg Kroah-Hartman 
> Signed-off-by: Tobin C. Harding 

Reviewed-by: Greg Kroah-Hartman 

Re: [PATCH] checkpatch: add check for tag Co-Developed-by

[Greg Kroah-Hartman]

On Thu, Dec 07, 2017 at 11:59:36AM +1100, Tobin C. Harding wrote:
> Recently signature tag Co-Developed-by was added to the
> kernel (Documentation/process/5.Posting.rst). checkpatch.pl doesn't know
> about it yet. All prior tags used all lowercase characters except for first
> character. Checks for this format had to be re-worked to allow for the
> new tag.
> 
> Add checkpatch checks for Co-Developed-by tag.
> 
> Cc: Greg Kroah-Hartman 
> Signed-off-by: Tobin C. Harding 

Reviewed-by: Greg Kroah-Hartman 

Re: [PATCH] checkpatch: add check for tag Co-Developed-by

[Greg Kroah-Hartman]

On Wed, Dec 06, 2017 at 10:34:26PM -0800, Joe Perches wrote:
> On Thu, 2017-12-07 at 11:59 +1100, Tobin C. Harding wrote:
> > Recently signature tag Co-Developed-by was added to the
> > kernel (Documentation/process/5.Posting.rst). checkpatch.pl doesn't know
> > about it yet. All prior tags used all lowercase characters except for first
> > character. Checks for this format had to be re-worked to allow for the
> > new tag.
> > 
> > Add checkpatch checks for Co-Developed-by tag.
> []
> > +++ b/scripts/checkpatch.pl
> > @@ -468,6 +468,7 @@ our $signature_tags = qr{(?xi:
> > Reviewed-by:|
> > Reported-by:|
> > Suggested-by:|
> > +   Co-Developed-by:|
> 
> I think the extra hyphenate form is poor at best.
> Codeveloped-by: should be the only form.

That's not what Documentation/process/5.Posting.rst says, sorry.

So Tobin's patch is correct.

thanks,

greg k-h

Re: [PATCH] checkpatch: add check for tag Co-Developed-by

[Greg Kroah-Hartman]

On Wed, Dec 06, 2017 at 10:34:26PM -0800, Joe Perches wrote:
> On Thu, 2017-12-07 at 11:59 +1100, Tobin C. Harding wrote:
> > Recently signature tag Co-Developed-by was added to the
> > kernel (Documentation/process/5.Posting.rst). checkpatch.pl doesn't know
> > about it yet. All prior tags used all lowercase characters except for first
> > character. Checks for this format had to be re-worked to allow for the
> > new tag.
> > 
> > Add checkpatch checks for Co-Developed-by tag.
> []
> > +++ b/scripts/checkpatch.pl
> > @@ -468,6 +468,7 @@ our $signature_tags = qr{(?xi:
> > Reviewed-by:|
> > Reported-by:|
> > Suggested-by:|
> > +   Co-Developed-by:|
> 
> I think the extra hyphenate form is poor at best.
> Codeveloped-by: should be the only form.

That's not what Documentation/process/5.Posting.rst says, sorry.

So Tobin's patch is correct.

thanks,

greg k-h

Re: [PATCH] usb: xhci: fix TDS for MTK xHCI1.1

[Mathias Nyman]

On 06.12.2017 08:42, Chunfeng Yun wrote:

For MTK's xHCI 1.0 or latter, TD size is the number of max
packet sized packets remaining in the TD, not including
this TRB (following spec).

For MTK's xHCI 0.96 and older, TD size is the number of max
packet sized packets remaining in the TD, including this TRB
(not following spec).

Signed-off-by: Chunfeng Yun 
---
  drivers/usb/host/xhci-ring.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index c239c68..0619869 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -3108,7 +3108,7 @@ static u32 xhci_td_remainder(struct xhci_hcd *xhci, int 
transferred,
  {
u32 maxp, total_packet_count;
  
-	/* MTK xHCI is mostly 0.97 but contains some features from 1.0 */

+   /* MTK xHCI 0.96 contains some features from 1.0 */
if (xhci->hci_version < 0x100 && !(xhci->quirks & XHCI_MTK_HOST))
return ((td_total_len - transferred) >> 10);
  
@@ -3117,8 +3117,8 @@ static u32 xhci_td_remainder(struct xhci_hcd *xhci, int transferred,

trb_buff_len == td_total_len)
return 0;
  
-	/* for MTK xHCI, TD size doesn't include this TRB */

-   if (xhci->quirks & XHCI_MTK_HOST)
+   /* for MTK xHCI 0.96, TD size include this TRB, but not in 1.x */
+   if ((xhci->quirks & XHCI_MTK_HOST) && (xhci->hci_version < 0x100))
trb_buff_len = 0;
  
  	maxp = usb_endpoint_maxp(>ep->desc);




Thanks, adding.
Adding stable tag as well

-Mathias

Re: [PATCH] usb: xhci: fix TDS for MTK xHCI1.1

[Mathias Nyman]

On 06.12.2017 08:42, Chunfeng Yun wrote:

For MTK's xHCI 1.0 or latter, TD size is the number of max
packet sized packets remaining in the TD, not including
this TRB (following spec).

For MTK's xHCI 0.96 and older, TD size is the number of max
packet sized packets remaining in the TD, including this TRB
(not following spec).

Signed-off-by: Chunfeng Yun 
---
  drivers/usb/host/xhci-ring.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index c239c68..0619869 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -3108,7 +3108,7 @@ static u32 xhci_td_remainder(struct xhci_hcd *xhci, int 
transferred,
  {
u32 maxp, total_packet_count;
  
-	/* MTK xHCI is mostly 0.97 but contains some features from 1.0 */

+   /* MTK xHCI 0.96 contains some features from 1.0 */
if (xhci->hci_version < 0x100 && !(xhci->quirks & XHCI_MTK_HOST))
return ((td_total_len - transferred) >> 10);
  
@@ -3117,8 +3117,8 @@ static u32 xhci_td_remainder(struct xhci_hcd *xhci, int transferred,

trb_buff_len == td_total_len)
return 0;
  
-	/* for MTK xHCI, TD size doesn't include this TRB */

-   if (xhci->quirks & XHCI_MTK_HOST)
+   /* for MTK xHCI 0.96, TD size include this TRB, but not in 1.x */
+   if ((xhci->quirks & XHCI_MTK_HOST) && (xhci->hci_version < 0x100))
trb_buff_len = 0;
  
  	maxp = usb_endpoint_maxp(>ep->desc);




Thanks, adding.
Adding stable tag as well

-Mathias

Re: [PATCH V6 02/12] clk: sprd: Add common infrastructure

[Stephen Boyd]

On 11/27, Chunyan Zhang wrote:
> +
> + sprd_clk_set_regmap(desc, regmap);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(sprd_clk_regmap_init);
> +
> +int sprd_clk_probe(struct device *dev, struct clk_hw_onecell_data *clkhw)
> +{
> + int i, ret = 0;

ret shouldn't need to be initialized here.

> + struct clk_hw *hw;
> +
> + for (i = 0; i < clkhw->num; i++) {
> +
> + hw = clkhw->hws[i];
> +
> + if (!hw)
> + continue;
> +
> + ret = devm_clk_hw_register(dev, hw);
> + if (ret) {
> + dev_err(dev, "Couldn't register clock %d - %s\n",
> + i, hw->init->name);
> + return ret;
> + }
> + }
> +
> + ret = of_clk_add_hw_provider(dev->of_node, of_clk_hw_onecell_get,
> +  clkhw);

You can use devm_ now for this.

> + if (ret)
> + dev_err(dev, "Failed to add clock provider.\n");

Please remove the full stop on error messages.

> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(sprd_clk_probe);
> +
> +MODULE_LICENSE("GPL v2");
> diff --git a/drivers/clk/sprd/common.h b/drivers/clk/sprd/common.h
> new file mode 100644
> index 000..8cd774e
> --- /dev/null
> +++ b/drivers/clk/sprd/common.h
> @@ -0,0 +1,52 @@
> +/*
> + * Spreadtrum clock infrastructure
> + *
> + * Copyright (C) 2017 Spreadtrum, Inc.
> + * Author: Chunyan Zhang 
> + *
> + * SPDX-License-Identifier: GPL-2.0
> + */
> +
> +#ifndef _SPRD_CLK_COMMON_H_
> +#define _SPRD_CLK_COMMON_H_
> +
> +#include 
> +#include 
> +#include 
> +
> +#include "../clk_common.h"
> +
> +struct device_node;
> +
> +struct sprd_clk_common {
> + struct regmap   *regmap;
> + u32 reg;
> + struct clk_hw   hw;
> +};
> +
> +struct sprd_clk_desc {
> + struct sprd_clk_common  **clk_clks;
> + unsigned long   num_clk_clks;
> + struct clk_hw_onecell_data  *hw_clks;
> +};
> +
> +#define sprd_regmap_read(map, reg, val)  \
> +({   \
> + (map) ? regmap_read((map), (reg), (val)) : (-EINVAL);   \

Do we sometimes not have a map? This seems overly cautious.

> +})
> +
> +#define sprd_regmap_write(map, reg, val) \
> +({   \

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH V6 02/12] clk: sprd: Add common infrastructure

[Stephen Boyd]

On 11/27, Chunyan Zhang wrote:
> +
> + sprd_clk_set_regmap(desc, regmap);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(sprd_clk_regmap_init);
> +
> +int sprd_clk_probe(struct device *dev, struct clk_hw_onecell_data *clkhw)
> +{
> + int i, ret = 0;

ret shouldn't need to be initialized here.

> + struct clk_hw *hw;
> +
> + for (i = 0; i < clkhw->num; i++) {
> +
> + hw = clkhw->hws[i];
> +
> + if (!hw)
> + continue;
> +
> + ret = devm_clk_hw_register(dev, hw);
> + if (ret) {
> + dev_err(dev, "Couldn't register clock %d - %s\n",
> + i, hw->init->name);
> + return ret;
> + }
> + }
> +
> + ret = of_clk_add_hw_provider(dev->of_node, of_clk_hw_onecell_get,
> +  clkhw);

You can use devm_ now for this.

> + if (ret)
> + dev_err(dev, "Failed to add clock provider.\n");

Please remove the full stop on error messages.

> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(sprd_clk_probe);
> +
> +MODULE_LICENSE("GPL v2");
> diff --git a/drivers/clk/sprd/common.h b/drivers/clk/sprd/common.h
> new file mode 100644
> index 000..8cd774e
> --- /dev/null
> +++ b/drivers/clk/sprd/common.h
> @@ -0,0 +1,52 @@
> +/*
> + * Spreadtrum clock infrastructure
> + *
> + * Copyright (C) 2017 Spreadtrum, Inc.
> + * Author: Chunyan Zhang 
> + *
> + * SPDX-License-Identifier: GPL-2.0
> + */
> +
> +#ifndef _SPRD_CLK_COMMON_H_
> +#define _SPRD_CLK_COMMON_H_
> +
> +#include 
> +#include 
> +#include 
> +
> +#include "../clk_common.h"
> +
> +struct device_node;
> +
> +struct sprd_clk_common {
> + struct regmap   *regmap;
> + u32 reg;
> + struct clk_hw   hw;
> +};
> +
> +struct sprd_clk_desc {
> + struct sprd_clk_common  **clk_clks;
> + unsigned long   num_clk_clks;
> + struct clk_hw_onecell_data  *hw_clks;
> +};
> +
> +#define sprd_regmap_read(map, reg, val)  \
> +({   \
> + (map) ? regmap_read((map), (reg), (val)) : (-EINVAL);   \

Do we sometimes not have a map? This seems overly cautious.

> +})
> +
> +#define sprd_regmap_write(map, reg, val) \
> +({   \

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH V6 01/12] drivers: move clock common macros out from vendor directories

[Stephen Boyd]

On 11/27, Chunyan Zhang wrote:
> These macros are used by more than one SoC vendor platforms, avoid to
> have many copies of these code, this patch moves them to the common
> clock directory which every clock drivers can access to.
> 
> Signed-off-by: Chunyan Zhang 
> ---
>  drivers/clk/clk_common.h | 60 
> 
>  1 file changed, 60 insertions(+)
>  create mode 100644 drivers/clk/clk_common.h
> 
> diff --git a/drivers/clk/clk_common.h b/drivers/clk/clk_common.h
> new file mode 100644
> index 000..21e93d2
> --- /dev/null
> +++ b/drivers/clk/clk_common.h
> @@ -0,0 +1,60 @@
> +/*
> + * drivers/clk/clk_common.h

We don't need this in the file too. Please remove this line.

> + *
> + * SPDX-License-Identifier: GPL-2.0
> + */
> +
> +#ifndef _CLK_COMMON_H_
> +#define _CLK_COMMON_H_
> +
> +#include 

Maybe these macros should just go into clk-provider.h?

> +
> +#define CLK_HW_INIT(_name, _parent, _ops, _flags)\
> + (&(struct clk_init_data) {  \
> + .flags  = _flags,   \
> + .name   = _name,\
> + .parent_names   = (const char *[]) { _parent }, \
> + .num_parents= 1,\
> + .ops= _ops, \
> + })

Hopefully we don't extend the init structure anymore to have
something else. I guess we'll do something if that happens.

> +
> +#define CLK_HW_INIT_PARENTS(_name, _parents, _ops, _flags)   \
> + (&(struct clk_init_data) {  \
> + .flags  = _flags,   \
> + .name   = _name,\
> + .parent_names   = _parents, \
> + .num_parents= ARRAY_SIZE(_parents), \
> + .ops= _ops, \
> + })
> +
> +#define CLK_HW_INIT_NO_PARENT(_name, _ops, _flags) \
> + (&(struct clk_init_data) {  \
> + .flags  = _flags,   \
> + .name   = _name,\
> + .parent_names   = NULL, \
> + .num_parents= 0,\
> + .ops= _ops, \
> + })
> +
> +#define CLK_FIXED_FACTOR(_struct, _name, _parent,\
> + _div, _mult, _flags)\
> + struct clk_fixed_factor _struct = { \
> + .div= _div, \
> + .mult   = _mult,\
> + .hw.init= CLK_HW_INIT(_name,\
> +   _parent,  \
> +   _fixed_factor_ops,\
> +   _flags),  \
> + }
> +
> +#define CLK_FIXED_RATE(_struct, _name, _flags,   
> \
> +_fixed_rate, _fixed_accuracy)\
> + struct clk_fixed_rate _struct = {   \
> + .fixed_rate = _fixed_rate,  \
> + .fixed_accuracy = _fixed_accuracy,  \
> + .hw.init= CLK_HW_INIT_NO_PARENT(_name,  \
> +   _fixed_rate_ops,  \
> + _flags),\
> + }

Maybe don't add this one? Usually fixed rate clks come from DT.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH V6 01/12] drivers: move clock common macros out from vendor directories

[Stephen Boyd]

On 11/27, Chunyan Zhang wrote:
> These macros are used by more than one SoC vendor platforms, avoid to
> have many copies of these code, this patch moves them to the common
> clock directory which every clock drivers can access to.
> 
> Signed-off-by: Chunyan Zhang 
> ---
>  drivers/clk/clk_common.h | 60 
> 
>  1 file changed, 60 insertions(+)
>  create mode 100644 drivers/clk/clk_common.h
> 
> diff --git a/drivers/clk/clk_common.h b/drivers/clk/clk_common.h
> new file mode 100644
> index 000..21e93d2
> --- /dev/null
> +++ b/drivers/clk/clk_common.h
> @@ -0,0 +1,60 @@
> +/*
> + * drivers/clk/clk_common.h

We don't need this in the file too. Please remove this line.

> + *
> + * SPDX-License-Identifier: GPL-2.0
> + */
> +
> +#ifndef _CLK_COMMON_H_
> +#define _CLK_COMMON_H_
> +
> +#include 

Maybe these macros should just go into clk-provider.h?

> +
> +#define CLK_HW_INIT(_name, _parent, _ops, _flags)\
> + (&(struct clk_init_data) {  \
> + .flags  = _flags,   \
> + .name   = _name,\
> + .parent_names   = (const char *[]) { _parent }, \
> + .num_parents= 1,\
> + .ops= _ops, \
> + })

Hopefully we don't extend the init structure anymore to have
something else. I guess we'll do something if that happens.

> +
> +#define CLK_HW_INIT_PARENTS(_name, _parents, _ops, _flags)   \
> + (&(struct clk_init_data) {  \
> + .flags  = _flags,   \
> + .name   = _name,\
> + .parent_names   = _parents, \
> + .num_parents= ARRAY_SIZE(_parents), \
> + .ops= _ops, \
> + })
> +
> +#define CLK_HW_INIT_NO_PARENT(_name, _ops, _flags) \
> + (&(struct clk_init_data) {  \
> + .flags  = _flags,   \
> + .name   = _name,\
> + .parent_names   = NULL, \
> + .num_parents= 0,\
> + .ops= _ops, \
> + })
> +
> +#define CLK_FIXED_FACTOR(_struct, _name, _parent,\
> + _div, _mult, _flags)\
> + struct clk_fixed_factor _struct = { \
> + .div= _div, \
> + .mult   = _mult,\
> + .hw.init= CLK_HW_INIT(_name,\
> +   _parent,  \
> +   _fixed_factor_ops,\
> +   _flags),  \
> + }
> +
> +#define CLK_FIXED_RATE(_struct, _name, _flags,   
> \
> +_fixed_rate, _fixed_accuracy)\
> + struct clk_fixed_rate _struct = {   \
> + .fixed_rate = _fixed_rate,  \
> + .fixed_accuracy = _fixed_accuracy,  \
> + .hw.init= CLK_HW_INIT_NO_PARENT(_name,  \
> +   _fixed_rate_ops,  \
> + _flags),\
> + }

Maybe don't add this one? Usually fixed rate clks come from DT.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v2 1/3] mmc: dt-bindings: add mmc support to MT7623 SoC

[sean.wang]

From: Sean Wang 

Add the devicetree binding for MT7623 SoC using MT2701 as the fallback.

Cc: devicet...@vger.kernel.org
Signed-off-by: Sean Wang 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/mmc/mtk-sd.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/mmc/mtk-sd.txt 
b/Documentation/devicetree/bindings/mmc/mtk-sd.txt
index 72d2a73..9b80176 100644
--- a/Documentation/devicetree/bindings/mmc/mtk-sd.txt
+++ b/Documentation/devicetree/bindings/mmc/mtk-sd.txt
@@ -12,6 +12,8 @@ Required properties:
"mediatek,mt8173-mmc": for mmc host ip compatible with mt8173
"mediatek,mt2701-mmc": for mmc host ip compatible with mt2701
"mediatek,mt2712-mmc": for mmc host ip compatible with mt2712
+   "mediatek,mt7623-mmc", "mediatek,mt2701-mmc": for MT7623 SoC
+
 - reg: physical base address of the controller and length
 - interrupts: Should contain MSDC interrupt number
 - clocks: Should contain phandle for the clock feeding the MMC controller
-- 
2.7.4

[lkp-robot] [lib/rbtree,drm/mm] 3e6e51217d: WARNING:at_lib/stackdepot.c:#depot_save_stack

[kernel test robot]

FYI, we noticed the following commit (built with gcc-7):

commit: 3e6e51217dd14dcda10d4bc9a38b1440e2d42c14 ("lib/rbtree,drm/mm: Add 
rbtree_replace_node_cached()")
git://anongit.freedesktop.org/drm-intel topic/core-for-CI

in testcase: trinity
with following parameters:

runtime: 300s

test-description: Trinity is a linux system call fuzz tester.
test-url: http://codemonkey.org.uk/projects/trinity/


on test machine: qemu-system-x86_64 -enable-kvm -m 512M

caused below changes (please refer to attached dmesg/kmsg for entire 
log/backtrace):


+---+++
|   | 978de04a3c | 3e6e51217d |
+---+++
| boot_successes| 46 | 0  |
| boot_failures | 0  | 8  |
| WARNING:at_lib/stackdepot.c:#depot_save_stack | 0  | 8  |
| RIP:depot_save_stack  | 0  | 8  |
| BUG:kernel_hang_in_test_stage | 0  | 4  |
+---+++



[  278.198833] WARNING: CPU: 0 PID: 1 at lib/stackdepot.c:119 
depot_save_stack+0x22e/0x353
[  278.10] CPU: 0 PID: 1 Comm: swapper Not tainted 
4.15.0-rc2-5-g3e6e512 #1
[  278.10] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.10.2-1 04/01/2014
[  278.10] task: 9f2da405 task.stack: 18ee505d
[  278.10] RIP: 0010:depot_save_stack+0x22e/0x353
[  278.10] RSP: :88001f5bb9d8 EFLAGS: 00010086
[  278.10] RAX: 0022 RBX: ae4fc5be RCX: 88001f5a8000
[  278.10] RDX: 00221f5a8000 RSI: 810eb77c RDI: 0093
[  278.10] RBP: 0020 R08: e272d5c3 R09: 0004
[  278.10] R10:  R11: 65e7cb07 R12: 000fc5be
[  278.10] R13: 88001f5bba30 R14:  R15: 0286
[  278.10] FS:  () GS:81e36000() 
knlGS:
[  278.10] CS:  0010 DS:  ES:  CR0: 80050033
[  278.10] CR2:  CR3: 01e11000 CR4: 06b0
[  278.10] Call Trace:
[  278.10]  ? save_stack+0x7c/0x89
[  278.10]  ? drm_mm_interval_tree_add_node+0xf6/0x137
[  278.10]  ? drm_mm_interval_tree_add_node+0xf6/0x137
[  278.10]  ? add_hole+0x12d/0x155
[  278.10]  ? add_hole+0x12d/0x155
[  278.10]  ? drm_mm_interval_tree_add_node+0xf6/0x137
[  278.10]  ? add_hole+0x12d/0x155
[  278.10]  ? drm_mm_interval_tree_compute_subtree_last+0x54/0x5c
[  278.10]  ? drm_mm_interval_tree_augment_copy+0x18/0x18
[  278.10]  ? add_hole+0x12d/0x155
[  278.10]  ? drm_mm_reserve_node+0x13f/0x155
[  278.10]  ? evict_something+0x244/0x2d1
[  278.10]  ? drm_mm_interval_tree_add_node+0xf6/0x137
[  278.10]  ? drm_mm_interval_tree_compute_subtree_last+0x54/0x5c
[  278.10]  ? drm_mm_interval_tree_augment_copy+0x18/0x18
[  278.10]  ? add_hole+0x12d/0x155
[  278.10]  ? drm_mm_reserve_node+0x13f/0x155
[  278.10]  ? drm_mm_interval_tree_compute_subtree_last+0x54/0x5c
[  278.10]  ? drm_mm_interval_tree_augment_copy+0x18/0x18
[  278.10]  ? drm_mm_interval_tree_augment_rotate+0x23/0x2a
[  278.10]  ? drm_mm_interval_tree_compute_subtree_last+0x54/0x5c
[  278.10]  ? rb_erase+0x146/0x270
[  278.10]  ? drm_mm_interval_tree_add_node+0xf6/0x137
[  278.10]  ? add_hole+0x12d/0x155
[  278.10]  ? drm_mm_interval_tree_add_node+0xf6/0x137
[  278.10]  ? drm_mm_interval_tree_add_node+0xf6/0x137
[  278.10]  ? add_hole+0x12d/0x155
[  278.10]  ? drm_mm_reserve_node+0x13f/0x155
[  278.10]  ? evict_something+0x244/0x2d1
[  278.10]  ? igt_evict+0x63d/0x75f
[  278.10]  ? test_drm_mm_init+0xb5/0x111
[  278.10]  ? drm_fb_helper_modinit+0xd/0xd
[  278.10]  ? do_early_param+0xbe/0xbe
[  278.10]  ? drm_mm_reserve_node+0x13f/0x155
[  278.10]  ? evict_something+0x244/0x2d1
[  278.10]  ? igt_evict+0x63d/0x75f
[  278.10]  ? test_drm_mm_init+0xb5/0x111
[  278.10]  ? drm_fb_helper_modinit+0xd/0xd
[  278.10]  ? do_early_param+0xbe/0xbe
[  278.10]  ? do_one_initcall+0x9d/0x158
[  278.10]  ? do_early_param+0xbe/0xbe
[  278.10]  ? do_early_param+0xbe/0xbe
[  278.10]  ? kernel_init_freeable+0x11c/0x1cc
[  278.10]  ? rest_init+0xbb/0xbb
[  278.10]  ? kernel_init+0x10/0x13d
[  278.10]  ? rest_init+0xbb/0xbb
[  278.10]  ? ret_from_fork+0x24/0x30
[  278.10] Code: 8d 50 01 81 fa ff 1f 00 00 7e 27 80 3d 52 04 c0 00 00 0f 
85 fd 00 00 00 48 c7 c7 e2 9e d0 81 c6 05 3e 04 c0 00 01 e8 f1 53 d7 ff <0f> ff 
e9 e3 00 00 00 83 c0 02 89 15 64 7c 6d 01 48 c7 05 4d 7c 
[  278.10] ---[ end trace 4dd271b4182c6be2 ]---


To reproduce:

git 

[PATCH v2 1/3] mmc: dt-bindings: add mmc support to MT7623 SoC

[sean.wang]

From: Sean Wang 

Add the devicetree binding for MT7623 SoC using MT2701 as the fallback.

Cc: devicet...@vger.kernel.org
Signed-off-by: Sean Wang 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/mmc/mtk-sd.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/mmc/mtk-sd.txt 
b/Documentation/devicetree/bindings/mmc/mtk-sd.txt
index 72d2a73..9b80176 100644
--- a/Documentation/devicetree/bindings/mmc/mtk-sd.txt
+++ b/Documentation/devicetree/bindings/mmc/mtk-sd.txt
@@ -12,6 +12,8 @@ Required properties:
"mediatek,mt8173-mmc": for mmc host ip compatible with mt8173
"mediatek,mt2701-mmc": for mmc host ip compatible with mt2701
"mediatek,mt2712-mmc": for mmc host ip compatible with mt2712
+   "mediatek,mt7623-mmc", "mediatek,mt2701-mmc": for MT7623 SoC
+
 - reg: physical base address of the controller and length
 - interrupts: Should contain MSDC interrupt number
 - clocks: Should contain phandle for the clock feeding the MMC controller
-- 
2.7.4

[lkp-robot] [lib/rbtree,drm/mm] 3e6e51217d: WARNING:at_lib/stackdepot.c:#depot_save_stack

[kernel test robot]

FYI, we noticed the following commit (built with gcc-7):

commit: 3e6e51217dd14dcda10d4bc9a38b1440e2d42c14 ("lib/rbtree,drm/mm: Add 
rbtree_replace_node_cached()")
git://anongit.freedesktop.org/drm-intel topic/core-for-CI

in testcase: trinity
with following parameters:

runtime: 300s

test-description: Trinity is a linux system call fuzz tester.
test-url: http://codemonkey.org.uk/projects/trinity/


on test machine: qemu-system-x86_64 -enable-kvm -m 512M

caused below changes (please refer to attached dmesg/kmsg for entire 
log/backtrace):


+---+++
|   | 978de04a3c | 3e6e51217d |
+---+++
| boot_successes| 46 | 0  |
| boot_failures | 0  | 8  |
| WARNING:at_lib/stackdepot.c:#depot_save_stack | 0  | 8  |
| RIP:depot_save_stack  | 0  | 8  |
| BUG:kernel_hang_in_test_stage | 0  | 4  |
+---+++



[  278.198833] WARNING: CPU: 0 PID: 1 at lib/stackdepot.c:119 
depot_save_stack+0x22e/0x353
[  278.10] CPU: 0 PID: 1 Comm: swapper Not tainted 
4.15.0-rc2-5-g3e6e512 #1
[  278.10] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.10.2-1 04/01/2014
[  278.10] task: 9f2da405 task.stack: 18ee505d
[  278.10] RIP: 0010:depot_save_stack+0x22e/0x353
[  278.10] RSP: :88001f5bb9d8 EFLAGS: 00010086
[  278.10] RAX: 0022 RBX: ae4fc5be RCX: 88001f5a8000
[  278.10] RDX: 00221f5a8000 RSI: 810eb77c RDI: 0093
[  278.10] RBP: 0020 R08: e272d5c3 R09: 0004
[  278.10] R10:  R11: 65e7cb07 R12: 000fc5be
[  278.10] R13: 88001f5bba30 R14:  R15: 0286
[  278.10] FS:  () GS:81e36000() 
knlGS:
[  278.10] CS:  0010 DS:  ES:  CR0: 80050033
[  278.10] CR2:  CR3: 01e11000 CR4: 06b0
[  278.10] Call Trace:
[  278.10]  ? save_stack+0x7c/0x89
[  278.10]  ? drm_mm_interval_tree_add_node+0xf6/0x137
[  278.10]  ? drm_mm_interval_tree_add_node+0xf6/0x137
[  278.10]  ? add_hole+0x12d/0x155
[  278.10]  ? add_hole+0x12d/0x155
[  278.10]  ? drm_mm_interval_tree_add_node+0xf6/0x137
[  278.10]  ? add_hole+0x12d/0x155
[  278.10]  ? drm_mm_interval_tree_compute_subtree_last+0x54/0x5c
[  278.10]  ? drm_mm_interval_tree_augment_copy+0x18/0x18
[  278.10]  ? add_hole+0x12d/0x155
[  278.10]  ? drm_mm_reserve_node+0x13f/0x155
[  278.10]  ? evict_something+0x244/0x2d1
[  278.10]  ? drm_mm_interval_tree_add_node+0xf6/0x137
[  278.10]  ? drm_mm_interval_tree_compute_subtree_last+0x54/0x5c
[  278.10]  ? drm_mm_interval_tree_augment_copy+0x18/0x18
[  278.10]  ? add_hole+0x12d/0x155
[  278.10]  ? drm_mm_reserve_node+0x13f/0x155
[  278.10]  ? drm_mm_interval_tree_compute_subtree_last+0x54/0x5c
[  278.10]  ? drm_mm_interval_tree_augment_copy+0x18/0x18
[  278.10]  ? drm_mm_interval_tree_augment_rotate+0x23/0x2a
[  278.10]  ? drm_mm_interval_tree_compute_subtree_last+0x54/0x5c
[  278.10]  ? rb_erase+0x146/0x270
[  278.10]  ? drm_mm_interval_tree_add_node+0xf6/0x137
[  278.10]  ? add_hole+0x12d/0x155
[  278.10]  ? drm_mm_interval_tree_add_node+0xf6/0x137
[  278.10]  ? drm_mm_interval_tree_add_node+0xf6/0x137
[  278.10]  ? add_hole+0x12d/0x155
[  278.10]  ? drm_mm_reserve_node+0x13f/0x155
[  278.10]  ? evict_something+0x244/0x2d1
[  278.10]  ? igt_evict+0x63d/0x75f
[  278.10]  ? test_drm_mm_init+0xb5/0x111
[  278.10]  ? drm_fb_helper_modinit+0xd/0xd
[  278.10]  ? do_early_param+0xbe/0xbe
[  278.10]  ? drm_mm_reserve_node+0x13f/0x155
[  278.10]  ? evict_something+0x244/0x2d1
[  278.10]  ? igt_evict+0x63d/0x75f
[  278.10]  ? test_drm_mm_init+0xb5/0x111
[  278.10]  ? drm_fb_helper_modinit+0xd/0xd
[  278.10]  ? do_early_param+0xbe/0xbe
[  278.10]  ? do_one_initcall+0x9d/0x158
[  278.10]  ? do_early_param+0xbe/0xbe
[  278.10]  ? do_early_param+0xbe/0xbe
[  278.10]  ? kernel_init_freeable+0x11c/0x1cc
[  278.10]  ? rest_init+0xbb/0xbb
[  278.10]  ? kernel_init+0x10/0x13d
[  278.10]  ? rest_init+0xbb/0xbb
[  278.10]  ? ret_from_fork+0x24/0x30
[  278.10] Code: 8d 50 01 81 fa ff 1f 00 00 7e 27 80 3d 52 04 c0 00 00 0f 
85 fd 00 00 00 48 c7 c7 e2 9e d0 81 c6 05 3e 04 c0 00 01 e8 f1 53 d7 ff <0f> ff 
e9 e3 00 00 00 83 c0 02 89 15 64 7c 6d 01 48 c7 05 4d 7c 
[  278.10] ---[ end trace 4dd271b4182c6be2 ]---


To reproduce:

git 

[PATCH v2 0/3] Misc fixes up for MT7623 mmc

[sean.wang]

From: Sean Wang 

Changes since v1:
- add tag from the feedback of v1
- enhance dt-binding documentation

Just add some fixes up for the current MT7623 support

Patch 1) complement the missing dt-bindings definitions
Patch 2) pick up the proper falling back as patch 1 defines.
Patch 3) SD-card detection issue caused by the wrong polarity is being fixed up

Sean Wang (3):
  mmc: dt-bindings: add mmc support to MT7623 SoC
  arm: dts: mt7623: update mmc related nodes with the appropriate
fallback
  arm: dts: mt7623: fix card detection issue on bananapi-r2

 Documentation/devicetree/bindings/mmc/mtk-sd.txt | 2 ++
 arch/arm/boot/dts/mt7623.dtsi| 4 ++--
 arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts| 2 +-
 3 files changed, 5 insertions(+), 3 deletions(-)

-- 
2.7.4

[PATCH v2 0/3] Misc fixes up for MT7623 mmc

[sean.wang]

From: Sean Wang 

Changes since v1:
- add tag from the feedback of v1
- enhance dt-binding documentation

Just add some fixes up for the current MT7623 support

Patch 1) complement the missing dt-bindings definitions
Patch 2) pick up the proper falling back as patch 1 defines.
Patch 3) SD-card detection issue caused by the wrong polarity is being fixed up

Sean Wang (3):
  mmc: dt-bindings: add mmc support to MT7623 SoC
  arm: dts: mt7623: update mmc related nodes with the appropriate
fallback
  arm: dts: mt7623: fix card detection issue on bananapi-r2

 Documentation/devicetree/bindings/mmc/mtk-sd.txt | 2 ++
 arch/arm/boot/dts/mt7623.dtsi| 4 ++--
 arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts| 2 +-
 3 files changed, 5 insertions(+), 3 deletions(-)

-- 
2.7.4

[PATCH v2 3/3] arm: dts: mt7623: fix card detection issue on bananapi-r2

[sean.wang]

From: Sean Wang 

Fix that bananapi-r2 booting from SD-card would fail since incorrect
polarity is applied to the previous setup with GPIO_ACTIVE_HIGH.

Cc: sta...@vger.kernel.org
Fixes: 0eed8d097612 ("arm: dts: mt7623: Add SD-card and EMMC to bananapi-r2")
Signed-off-by: Sean Wang 
Tested-by: Matthias Brugger 
---
 arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts 
b/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
index 688a863..7bf5aa2 100644
--- a/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
+++ b/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
@@ -204,7 +204,7 @@
bus-width = <4>;
max-frequency = <5000>;
cap-sd-highspeed;
-   cd-gpios = < 261 0>;
+   cd-gpios = < 261 GPIO_ACTIVE_LOW>;
vmmc-supply = <_vmch_reg>;
vqmmc-supply = <_vio18_reg>;
 };
-- 
2.7.4

[PATCH v2 3/3] arm: dts: mt7623: fix card detection issue on bananapi-r2

[sean.wang]

From: Sean Wang 

Fix that bananapi-r2 booting from SD-card would fail since incorrect
polarity is applied to the previous setup with GPIO_ACTIVE_HIGH.

Cc: sta...@vger.kernel.org
Fixes: 0eed8d097612 ("arm: dts: mt7623: Add SD-card and EMMC to bananapi-r2")
Signed-off-by: Sean Wang 
Tested-by: Matthias Brugger 
---
 arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts 
b/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
index 688a863..7bf5aa2 100644
--- a/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
+++ b/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
@@ -204,7 +204,7 @@
bus-width = <4>;
max-frequency = <5000>;
cap-sd-highspeed;
-   cd-gpios = < 261 0>;
+   cd-gpios = < 261 GPIO_ACTIVE_LOW>;
vmmc-supply = <_vmch_reg>;
vqmmc-supply = <_vio18_reg>;
 };
-- 
2.7.4

[PATCH v2 2/3] arm: dts: mt7623: update mmc related nodes with the appropriate fallback

[sean.wang]

From: Sean Wang 

The current mmc related nodes should be falling back to MT2701
as the dt-binding defines and which has more appropriate setup
for MT7623.

Signed-off-by: Sean Wang 
---
 arch/arm/boot/dts/mt7623.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/mt7623.dtsi b/arch/arm/boot/dts/mt7623.dtsi
index 0640fb7..343d3b1 100644
--- a/arch/arm/boot/dts/mt7623.dtsi
+++ b/arch/arm/boot/dts/mt7623.dtsi
@@ -641,7 +641,7 @@
 
mmc0: mmc@1123 {
compatible = "mediatek,mt7623-mmc",
-"mediatek,mt8135-mmc";
+"mediatek,mt2701-mmc";
reg = <0 0x1123 0 0x1000>;
interrupts = ;
clocks = < CLK_PERI_MSDC30_0>,
@@ -652,7 +652,7 @@
 
mmc1: mmc@1124 {
compatible = "mediatek,mt7623-mmc",
-"mediatek,mt8135-mmc";
+"mediatek,mt2701-mmc";
reg = <0 0x1124 0 0x1000>;
interrupts = ;
clocks = < CLK_PERI_MSDC30_1>,
-- 
2.7.4

[PATCH V3] spi: sun4i: disable clocks in the remove function

[Takuo Koguchi]

mclk and hclk need to be disabled. Since pm_runtime_disable does
not disable the clocks, use pm_runtime_force_suspend instead.

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Takuo Koguchi 
---
 V3: remove redundant pm_runtime_disable call.
 Compile test only, no runtime test done.
 drivers/spi/spi-sun4i.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/spi/spi-sun4i.c b/drivers/spi/spi-sun4i.c
index c5cd635..4141003 100644
--- a/drivers/spi/spi-sun4i.c
+++ b/drivers/spi/spi-sun4i.c
@@ -525,7 +525,7 @@ static int sun4i_spi_probe(struct platform_device *pdev)
 
 static int sun4i_spi_remove(struct platform_device *pdev)
 {
-   pm_runtime_disable(>dev);
+   pm_runtime_force_suspend(>dev);
 
return 0;
 }
-- 
2.7.4

[PATCH v2 2/3] arm: dts: mt7623: update mmc related nodes with the appropriate fallback

[sean.wang]

From: Sean Wang 

The current mmc related nodes should be falling back to MT2701
as the dt-binding defines and which has more appropriate setup
for MT7623.

Signed-off-by: Sean Wang 
---
 arch/arm/boot/dts/mt7623.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/mt7623.dtsi b/arch/arm/boot/dts/mt7623.dtsi
index 0640fb7..343d3b1 100644
--- a/arch/arm/boot/dts/mt7623.dtsi
+++ b/arch/arm/boot/dts/mt7623.dtsi
@@ -641,7 +641,7 @@
 
mmc0: mmc@1123 {
compatible = "mediatek,mt7623-mmc",
-"mediatek,mt8135-mmc";
+"mediatek,mt2701-mmc";
reg = <0 0x1123 0 0x1000>;
interrupts = ;
clocks = < CLK_PERI_MSDC30_0>,
@@ -652,7 +652,7 @@
 
mmc1: mmc@1124 {
compatible = "mediatek,mt7623-mmc",
-"mediatek,mt8135-mmc";
+"mediatek,mt2701-mmc";
reg = <0 0x1124 0 0x1000>;
interrupts = ;
clocks = < CLK_PERI_MSDC30_1>,
-- 
2.7.4

[PATCH V3] spi: sun4i: disable clocks in the remove function

[Takuo Koguchi]

mclk and hclk need to be disabled. Since pm_runtime_disable does
not disable the clocks, use pm_runtime_force_suspend instead.

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Takuo Koguchi 
---
 V3: remove redundant pm_runtime_disable call.
 Compile test only, no runtime test done.
 drivers/spi/spi-sun4i.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/spi/spi-sun4i.c b/drivers/spi/spi-sun4i.c
index c5cd635..4141003 100644
--- a/drivers/spi/spi-sun4i.c
+++ b/drivers/spi/spi-sun4i.c
@@ -525,7 +525,7 @@ static int sun4i_spi_probe(struct platform_device *pdev)
 
 static int sun4i_spi_remove(struct platform_device *pdev)
 {
-   pm_runtime_disable(>dev);
+   pm_runtime_force_suspend(>dev);
 
return 0;
 }
-- 
2.7.4

[PATCH 1/2] mtd: spi-nor: cadence-quadspi: Refactor indirect read/write sequence.

[Vignesh R]

Move configuring of indirect read/write start address to
cqspi_indirect_*_execute() function and rename cqspi_indirect_*_setup()
function. This will help to reuse cqspi_indirect_*_setup() function for
supporting direct access mode.

Signed-off-by: Vignesh R 
---
 drivers/mtd/spi-nor/cadence-quadspi.c | 27 ---
 1 file changed, 12 insertions(+), 15 deletions(-)

diff --git a/drivers/mtd/spi-nor/cadence-quadspi.c 
b/drivers/mtd/spi-nor/cadence-quadspi.c
index 75a2bc447a99..becc7d714ab8 100644
--- a/drivers/mtd/spi-nor/cadence-quadspi.c
+++ b/drivers/mtd/spi-nor/cadence-quadspi.c
@@ -450,8 +450,7 @@ static int cqspi_command_write_addr(struct spi_nor *nor,
return cqspi_exec_flash_cmd(cqspi, reg);
 }
 
-static int cqspi_indirect_read_setup(struct spi_nor *nor,
-const unsigned int from_addr)
+static int cqspi_read_setup(struct spi_nor *nor)
 {
struct cqspi_flash_pdata *f_pdata = nor->priv;
struct cqspi_st *cqspi = f_pdata->cqspi;
@@ -459,7 +458,6 @@ static int cqspi_indirect_read_setup(struct spi_nor *nor,
unsigned int dummy_clk = 0;
unsigned int reg;
 
-   writel(from_addr, reg_base + CQSPI_REG_INDIRECTRDSTARTADDR);
 
reg = nor->read_opcode << CQSPI_REG_RD_INSTR_OPCODE_LSB;
reg |= cqspi_calc_rdreg(nor, nor->read_opcode);
@@ -493,8 +491,8 @@ static int cqspi_indirect_read_setup(struct spi_nor *nor,
return 0;
 }
 
-static int cqspi_indirect_read_execute(struct spi_nor *nor,
-  u8 *rxbuf, const unsigned n_rx)
+static int cqspi_indirect_read_execute(struct spi_nor *nor, u8 *rxbuf,
+  loff_t from_addr, const size_t n_rx)
 {
struct cqspi_flash_pdata *f_pdata = nor->priv;
struct cqspi_st *cqspi = f_pdata->cqspi;
@@ -504,6 +502,7 @@ static int cqspi_indirect_read_execute(struct spi_nor *nor,
unsigned int bytes_to_read = 0;
int ret = 0;
 
+   writel(from_addr, reg_base + CQSPI_REG_INDIRECTRDSTARTADDR);
writel(remaining, reg_base + CQSPI_REG_INDIRECTRDBYTES);
 
/* Clear all interrupts. */
@@ -570,8 +569,7 @@ static int cqspi_indirect_read_execute(struct spi_nor *nor,
return ret;
 }
 
-static int cqspi_indirect_write_setup(struct spi_nor *nor,
- const unsigned int to_addr)
+static int cqspi_write_setup(struct spi_nor *nor)
 {
unsigned int reg;
struct cqspi_flash_pdata *f_pdata = nor->priv;
@@ -584,8 +582,6 @@ static int cqspi_indirect_write_setup(struct spi_nor *nor,
reg = cqspi_calc_rdreg(nor, nor->program_opcode);
writel(reg, reg_base + CQSPI_REG_RD_INSTR);
 
-   writel(to_addr, reg_base + CQSPI_REG_INDIRECTWRSTARTADDR);
-
reg = readl(reg_base + CQSPI_REG_SIZE);
reg &= ~CQSPI_REG_SIZE_ADDRESS_MASK;
reg |= (nor->addr_width - 1);
@@ -593,8 +589,8 @@ static int cqspi_indirect_write_setup(struct spi_nor *nor,
return 0;
 }
 
-static int cqspi_indirect_write_execute(struct spi_nor *nor,
-   const u8 *txbuf, const unsigned n_tx)
+static int cqspi_indirect_write_execute(struct spi_nor *nor, loff_t to_addr,
+   const u8 *txbuf, const size_t n_tx)
 {
const unsigned int page_size = nor->page_size;
struct cqspi_flash_pdata *f_pdata = nor->priv;
@@ -604,6 +600,7 @@ static int cqspi_indirect_write_execute(struct spi_nor *nor,
unsigned int write_bytes;
int ret;
 
+   writel(to_addr, reg_base + CQSPI_REG_INDIRECTWRSTARTADDR);
writel(remaining, reg_base + CQSPI_REG_INDIRECTWRBYTES);
 
/* Clear all interrupts. */
@@ -900,11 +897,11 @@ static ssize_t cqspi_write(struct spi_nor *nor, loff_t to,
if (ret)
return ret;
 
-   ret = cqspi_indirect_write_setup(nor, to);
+   ret = cqspi_write_setup(nor);
if (ret)
return ret;
 
-   ret = cqspi_indirect_write_execute(nor, buf, len);
+   ret = cqspi_indirect_write_execute(nor, to, buf, len);
if (ret)
return ret;
 
@@ -920,11 +917,11 @@ static ssize_t cqspi_read(struct spi_nor *nor, loff_t 
from,
if (ret)
return ret;
 
-   ret = cqspi_indirect_read_setup(nor, from);
+   ret = cqspi_read_setup(nor);
if (ret)
return ret;
 
-   ret = cqspi_indirect_read_execute(nor, buf, len);
+   ret = cqspi_indirect_read_execute(nor, buf, from, len);
if (ret)
return ret;
 
-- 
2.15.1

[PATCH 1/2] mtd: spi-nor: cadence-quadspi: Refactor indirect read/write sequence.

[Vignesh R]

Move configuring of indirect read/write start address to
cqspi_indirect_*_execute() function and rename cqspi_indirect_*_setup()
function. This will help to reuse cqspi_indirect_*_setup() function for
supporting direct access mode.

Signed-off-by: Vignesh R 
---
 drivers/mtd/spi-nor/cadence-quadspi.c | 27 ---
 1 file changed, 12 insertions(+), 15 deletions(-)

diff --git a/drivers/mtd/spi-nor/cadence-quadspi.c 
b/drivers/mtd/spi-nor/cadence-quadspi.c
index 75a2bc447a99..becc7d714ab8 100644
--- a/drivers/mtd/spi-nor/cadence-quadspi.c
+++ b/drivers/mtd/spi-nor/cadence-quadspi.c
@@ -450,8 +450,7 @@ static int cqspi_command_write_addr(struct spi_nor *nor,
return cqspi_exec_flash_cmd(cqspi, reg);
 }
 
-static int cqspi_indirect_read_setup(struct spi_nor *nor,
-const unsigned int from_addr)
+static int cqspi_read_setup(struct spi_nor *nor)
 {
struct cqspi_flash_pdata *f_pdata = nor->priv;
struct cqspi_st *cqspi = f_pdata->cqspi;
@@ -459,7 +458,6 @@ static int cqspi_indirect_read_setup(struct spi_nor *nor,
unsigned int dummy_clk = 0;
unsigned int reg;
 
-   writel(from_addr, reg_base + CQSPI_REG_INDIRECTRDSTARTADDR);
 
reg = nor->read_opcode << CQSPI_REG_RD_INSTR_OPCODE_LSB;
reg |= cqspi_calc_rdreg(nor, nor->read_opcode);
@@ -493,8 +491,8 @@ static int cqspi_indirect_read_setup(struct spi_nor *nor,
return 0;
 }
 
-static int cqspi_indirect_read_execute(struct spi_nor *nor,
-  u8 *rxbuf, const unsigned n_rx)
+static int cqspi_indirect_read_execute(struct spi_nor *nor, u8 *rxbuf,
+  loff_t from_addr, const size_t n_rx)
 {
struct cqspi_flash_pdata *f_pdata = nor->priv;
struct cqspi_st *cqspi = f_pdata->cqspi;
@@ -504,6 +502,7 @@ static int cqspi_indirect_read_execute(struct spi_nor *nor,
unsigned int bytes_to_read = 0;
int ret = 0;
 
+   writel(from_addr, reg_base + CQSPI_REG_INDIRECTRDSTARTADDR);
writel(remaining, reg_base + CQSPI_REG_INDIRECTRDBYTES);
 
/* Clear all interrupts. */
@@ -570,8 +569,7 @@ static int cqspi_indirect_read_execute(struct spi_nor *nor,
return ret;
 }
 
-static int cqspi_indirect_write_setup(struct spi_nor *nor,
- const unsigned int to_addr)
+static int cqspi_write_setup(struct spi_nor *nor)
 {
unsigned int reg;
struct cqspi_flash_pdata *f_pdata = nor->priv;
@@ -584,8 +582,6 @@ static int cqspi_indirect_write_setup(struct spi_nor *nor,
reg = cqspi_calc_rdreg(nor, nor->program_opcode);
writel(reg, reg_base + CQSPI_REG_RD_INSTR);
 
-   writel(to_addr, reg_base + CQSPI_REG_INDIRECTWRSTARTADDR);
-
reg = readl(reg_base + CQSPI_REG_SIZE);
reg &= ~CQSPI_REG_SIZE_ADDRESS_MASK;
reg |= (nor->addr_width - 1);
@@ -593,8 +589,8 @@ static int cqspi_indirect_write_setup(struct spi_nor *nor,
return 0;
 }
 
-static int cqspi_indirect_write_execute(struct spi_nor *nor,
-   const u8 *txbuf, const unsigned n_tx)
+static int cqspi_indirect_write_execute(struct spi_nor *nor, loff_t to_addr,
+   const u8 *txbuf, const size_t n_tx)
 {
const unsigned int page_size = nor->page_size;
struct cqspi_flash_pdata *f_pdata = nor->priv;
@@ -604,6 +600,7 @@ static int cqspi_indirect_write_execute(struct spi_nor *nor,
unsigned int write_bytes;
int ret;
 
+   writel(to_addr, reg_base + CQSPI_REG_INDIRECTWRSTARTADDR);
writel(remaining, reg_base + CQSPI_REG_INDIRECTWRBYTES);
 
/* Clear all interrupts. */
@@ -900,11 +897,11 @@ static ssize_t cqspi_write(struct spi_nor *nor, loff_t to,
if (ret)
return ret;
 
-   ret = cqspi_indirect_write_setup(nor, to);
+   ret = cqspi_write_setup(nor);
if (ret)
return ret;
 
-   ret = cqspi_indirect_write_execute(nor, buf, len);
+   ret = cqspi_indirect_write_execute(nor, to, buf, len);
if (ret)
return ret;
 
@@ -920,11 +917,11 @@ static ssize_t cqspi_read(struct spi_nor *nor, loff_t 
from,
if (ret)
return ret;
 
-   ret = cqspi_indirect_read_setup(nor, from);
+   ret = cqspi_read_setup(nor);
if (ret)
return ret;
 
-   ret = cqspi_indirect_read_execute(nor, buf, len);
+   ret = cqspi_indirect_read_execute(nor, buf, from, len);
if (ret)
return ret;
 
-- 
2.15.1

[PATCH 0/2] CQSPI: Add direct mode support

[Vignesh R]

This patch series enables use Direct access controller on Cadence QSPI
which helps in accessing QSPI flash in memory mapped mode.

On TI platforms, this mode has higher throughput compared to indirect
access mode.

Tested on TI's 66AK2G GP EVM.

It would be great if this patch series could be tested SoCFPGA as well.
Although, this patch should have no effect on SoCFPGA platforms as driver
continues to use indirect mode when direct access memory window is less
than size of connected flash.

Vignesh R (2):
  mtd: spi-nor: cadence-quadspi: Refactor indirect read/write sequence.
  mtd: spi-nor: cadence-quadspi: Add support for direct access mode

 drivers/mtd/spi-nor/cadence-quadspi.c | 75 ---
 1 file changed, 60 insertions(+), 15 deletions(-)

-- 
2.15.1

Re: [PATCH 6/6] clk: h8300: pr_err() strings should end with newlines

[Stephen Boyd]

On 11/24, Arvind Yadav wrote:
> pr_err() messages should end with a new-line to avoid other messages
> being concatenated.
> 
> Signed-off-by: Arvind Yadav 
> ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH 0/2] CQSPI: Add direct mode support

[Vignesh R]

This patch series enables use Direct access controller on Cadence QSPI
which helps in accessing QSPI flash in memory mapped mode.

On TI platforms, this mode has higher throughput compared to indirect
access mode.

Tested on TI's 66AK2G GP EVM.

It would be great if this patch series could be tested SoCFPGA as well.
Although, this patch should have no effect on SoCFPGA platforms as driver
continues to use indirect mode when direct access memory window is less
than size of connected flash.

Vignesh R (2):
  mtd: spi-nor: cadence-quadspi: Refactor indirect read/write sequence.
  mtd: spi-nor: cadence-quadspi: Add support for direct access mode

 drivers/mtd/spi-nor/cadence-quadspi.c | 75 ---
 1 file changed, 60 insertions(+), 15 deletions(-)

-- 
2.15.1

Re: [PATCH 6/6] clk: h8300: pr_err() strings should end with newlines

[Stephen Boyd]

On 11/24, Arvind Yadav wrote:
> pr_err() messages should end with a new-line to avoid other messages
> being concatenated.
> 
> Signed-off-by: Arvind Yadav 
> ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 5/6] clk: h8s2678: pr_err() strings should end with newlines

[Stephen Boyd]

On 11/24, Arvind Yadav wrote:
> pr_err() messages should end with a new-line to avoid other messages
> being concatenated.
> 
> Signed-off-by: Arvind Yadav 
> ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 4/6] SPEAr: clk: pr_err() strings should end with newlines

[Stephen Boyd]

On 11/24, Arvind Yadav wrote:
> pr_err() messages should end with a new-line to avoid other messages
> being concatenated.
> 
> Signed-off-by: Arvind Yadav 
> ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 5/6] clk: h8s2678: pr_err() strings should end with newlines

[Stephen Boyd]

On 11/24, Arvind Yadav wrote:
> pr_err() messages should end with a new-line to avoid other messages
> being concatenated.
> 
> Signed-off-by: Arvind Yadav 
> ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 4/6] SPEAr: clk: pr_err() strings should end with newlines

[Stephen Boyd]

On 11/24, Arvind Yadav wrote:
> pr_err() messages should end with a new-line to avoid other messages
> being concatenated.
> 
> Signed-off-by: Arvind Yadav 
> ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project