Re: [PATCH v2 4/4] pinctrl: mediatek: update MAINTAINERS entry with MediaTek pinctrl driver

[Linus Walleij]

On Tue, Dec 12, 2017 at 7:24 AM,   wrote:

> From: Sean Wang 
>
> I work for MediaTek on maintaining the existing MediaTek SoC whose target
> to home gateway such as MT7622 and MT7623 that is reusing MT2701 related
> files and will keep adding support for the following such kinds of SoCs
> in the future.
>
> Signed-off-by: Sean Wang 
> Reviewed-by: Biao Huang 

Patch applied.

Yours,
Linus Walleij

Re: [PATCH v2 4/4] pinctrl: mediatek: update MAINTAINERS entry with MediaTek pinctrl driver

[Linus Walleij]

On Tue, Dec 12, 2017 at 7:24 AM,   wrote:

> From: Sean Wang 
>
> I work for MediaTek on maintaining the existing MediaTek SoC whose target
> to home gateway such as MT7622 and MT7623 that is reusing MT2701 related
> files and will keep adding support for the following such kinds of SoCs
> in the future.
>
> Signed-off-by: Sean Wang 
> Reviewed-by: Biao Huang 

Patch applied.

Yours,
Linus Walleij

Re: [PATCH v2 3/4] pinctrl: mediatek: add pinctrl driver for MT7622 SoC

[Linus Walleij]

On Tue, Dec 12, 2017 at 7:24 AM,   wrote:

> From: Sean Wang 
>
> Add support for pinctrl on MT7622 SoC. The IO core found on the SoC has
> the registers for pinctrl, pinconf and gpio mixed up in the same register
> range. However, the IO core for the MT7622 SoC is completely distinct from
> anyone of previous MediaTek SoCs which already had support, such as
> the hardware internal, register address map and register detailed
> definition for each pin.
>
> Therefore, instead, the driver is being newly implemented by reusing
> generic methods provided from the core layer with GENERIC_PINCONF,
> GENERIC_PINCTRL_GROUPS, and GENERIC_PINMUX_FUNCTIONS for the sake of code
> simplicity and rid of superfluous code. Where the function of pins
> determined by groups is utilized in this driver which can help developers
> less confused with what combinations of pins effective on the SoC and even
> reducing the mistakes during the integration of those relevant boards.
>
> As the gpio_chip handling is also only a few lines, the driver also
> implements the gpio functionality directly through GPIOLIB.
>
> Signed-off-by: Sean Wang 
> Reviewed-by: Biao Huang 

Patch applied. Very nice work!

As I've seen visiting Asia how popular MTK chips are for all kinds
of devices it's really nice to have proper upstream support directly from
Mediatek on these chips. You guys are awesome.

Some suggestions for improvements:

> +static void mtk_w32(struct mtk_pinctrl *pctl, u32 reg, u32 val)
> +{
> +   writel_relaxed(val, pctl->base + reg);
> +}
> +
> +static u32 mtk_r32(struct mtk_pinctrl *pctl, u32 reg)
> +{
> +   return readl_relaxed(pctl->base + reg);
> +}
> +
> +static void mtk_rmw(struct mtk_pinctrl *pctl, u32 reg, u32 mask, u32 set)
> +{
> +   u32 val;
> +
> +   val = mtk_r32(pctl, reg);
> +   val &= ~mask;
> +   val |= set;
> +   mtk_w32(pctl, reg, val);
> +}

Have you considered replacing this with regmap-mmio? It does pretty much
the same thing. It could be an improvemet reducing code a bit and making
it more generic. The error codes from eg regmap_update_bits() can be
safely ignored on MMIO maps.

> +static int mtk_build_gpiochip(struct mtk_pinctrl *hw, struct device_node *np)
> +{
> +   struct gpio_chip *chip = >chip;
> +   int ret;
> +
> +   chip->label = PINCTRL_PINCTRL_DEV;
> +   chip->parent= hw->dev;
> +   chip->request   = gpiochip_generic_request;
> +   chip->free  = gpiochip_generic_free;
> +   chip->direction_input   = mtk_gpio_direction_input;
> +   chip->direction_output  = mtk_gpio_direction_output;

Please submit a patch implementing chip->get_direction(), it
is really helpful, especially for debugging.

If your pin controller later adds support for things that can be
used from the GPIO side, like open drain or debounce, then
please consider at that point to also implement
chip->set_config() in the gpio_chip. That way your GPIO consumers
can use e.g. open drain through pin control as back-end.
See drivers/pinctrl/intel/pinctrl-intel.c for an example.

Yours,
Linus Walleij

Re: [PATCH v2 3/4] pinctrl: mediatek: add pinctrl driver for MT7622 SoC

[Linus Walleij]

On Tue, Dec 12, 2017 at 7:24 AM,   wrote:

> From: Sean Wang 
>
> Add support for pinctrl on MT7622 SoC. The IO core found on the SoC has
> the registers for pinctrl, pinconf and gpio mixed up in the same register
> range. However, the IO core for the MT7622 SoC is completely distinct from
> anyone of previous MediaTek SoCs which already had support, such as
> the hardware internal, register address map and register detailed
> definition for each pin.
>
> Therefore, instead, the driver is being newly implemented by reusing
> generic methods provided from the core layer with GENERIC_PINCONF,
> GENERIC_PINCTRL_GROUPS, and GENERIC_PINMUX_FUNCTIONS for the sake of code
> simplicity and rid of superfluous code. Where the function of pins
> determined by groups is utilized in this driver which can help developers
> less confused with what combinations of pins effective on the SoC and even
> reducing the mistakes during the integration of those relevant boards.
>
> As the gpio_chip handling is also only a few lines, the driver also
> implements the gpio functionality directly through GPIOLIB.
>
> Signed-off-by: Sean Wang 
> Reviewed-by: Biao Huang 

Patch applied. Very nice work!

As I've seen visiting Asia how popular MTK chips are for all kinds
of devices it's really nice to have proper upstream support directly from
Mediatek on these chips. You guys are awesome.

Some suggestions for improvements:

> +static void mtk_w32(struct mtk_pinctrl *pctl, u32 reg, u32 val)
> +{
> +   writel_relaxed(val, pctl->base + reg);
> +}
> +
> +static u32 mtk_r32(struct mtk_pinctrl *pctl, u32 reg)
> +{
> +   return readl_relaxed(pctl->base + reg);
> +}
> +
> +static void mtk_rmw(struct mtk_pinctrl *pctl, u32 reg, u32 mask, u32 set)
> +{
> +   u32 val;
> +
> +   val = mtk_r32(pctl, reg);
> +   val &= ~mask;
> +   val |= set;
> +   mtk_w32(pctl, reg, val);
> +}

Have you considered replacing this with regmap-mmio? It does pretty much
the same thing. It could be an improvemet reducing code a bit and making
it more generic. The error codes from eg regmap_update_bits() can be
safely ignored on MMIO maps.

> +static int mtk_build_gpiochip(struct mtk_pinctrl *hw, struct device_node *np)
> +{
> +   struct gpio_chip *chip = >chip;
> +   int ret;
> +
> +   chip->label = PINCTRL_PINCTRL_DEV;
> +   chip->parent= hw->dev;
> +   chip->request   = gpiochip_generic_request;
> +   chip->free  = gpiochip_generic_free;
> +   chip->direction_input   = mtk_gpio_direction_input;
> +   chip->direction_output  = mtk_gpio_direction_output;

Please submit a patch implementing chip->get_direction(), it
is really helpful, especially for debugging.

If your pin controller later adds support for things that can be
used from the GPIO side, like open drain or debounce, then
please consider at that point to also implement
chip->set_config() in the gpio_chip. That way your GPIO consumers
can use e.g. open drain through pin control as back-end.
See drivers/pinctrl/intel/pinctrl-intel.c for an example.

Yours,
Linus Walleij

Re: Maintainer docs for patch merging

[Greg Kroah-Hartman]

On Wed, Dec 20, 2017 at 11:25:41AM +1100, Tobin C. Harding wrote:
> Hi,
> 
> Recently we started a maintainer book (merged into Jonathan's docs-next
> branch).
> 
> Would any current maintainers please be willing to explain how they go
> about generating the automated emails one often receives when a patch
> [set] is applied.
> 
> This may also be related to tree/branch management for maintainers
> kernel.org shows some people like to use multiple trees and some use
> branches? 
> 
> If deemed relevant we could add a section to the new book (and I'd also
> like to know how to do it for my own tree please so I can copy ;)
> 
> I have CC'd Greg and Andrew because they seem to have a system in place
> for this.

I "stole" Andrew's scripts for this a long time ago.  I guess I can
write up something "real" for the documentation so that others can see
the shell mess that drives those emails :)

> No rush on this, I know Christmas is soon.

Yeah, this will have to wait until mid January at the earliest...

thanks,

greg k-h

Re: Maintainer docs for patch merging

[Greg Kroah-Hartman]

On Wed, Dec 20, 2017 at 11:25:41AM +1100, Tobin C. Harding wrote:
> Hi,
> 
> Recently we started a maintainer book (merged into Jonathan's docs-next
> branch).
> 
> Would any current maintainers please be willing to explain how they go
> about generating the automated emails one often receives when a patch
> [set] is applied.
> 
> This may also be related to tree/branch management for maintainers
> kernel.org shows some people like to use multiple trees and some use
> branches? 
> 
> If deemed relevant we could add a section to the new book (and I'd also
> like to know how to do it for my own tree please so I can copy ;)
> 
> I have CC'd Greg and Andrew because they seem to have a system in place
> for this.

I "stole" Andrew's scripts for this a long time ago.  I guess I can
write up something "real" for the documentation so that others can see
the shell mess that drives those emails :)

> No rush on this, I know Christmas is soon.

Yeah, this will have to wait until mid January at the earliest...

thanks,

greg k-h

Re: general protection fault in native_write_cr4

[Wanpeng Li]

2017-12-20 15:49 GMT+08:00 syzbot
:
> Hello,
>
> syzkaller hit the following crash on
> f6f3732162b5ae3c771b9285a5a32d72b8586920
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> C reproducer is attached
> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> for information about syzkaller reproducers
>
>

I will have a look again, you continue to run it in kvm guest, right?

Regards,
Wanpeng Li

> kvm: KVM_SET_TSS_ADDR need to be called before entering vcpu
> kasan: CONFIG_KASAN_INLINE enabled
> kasan: GPF could be caused by NULL-ptr deref or user memory access
> general protection fault:  [#1] SMP KASAN
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Modules linked in:
> CPU: 1 PID: 3142 Comm: syzkaller429302 Not tainted 4.15.0-rc3+ #224
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> RIP: 0010:native_write_cr4+0x4/0x10 arch/x86/include/asm/special_insns.h:76
> RSP: 0018:8801ca6f75a0 EFLAGS: 00010093
> RAX: 8801ca1c8700 RBX: 001606e0 RCX: 811a2a92
> RDX:  RSI:  RDI: 001606e0
> RBP: 8801ca6f75a0 R08: 1100394dee0f R09: 0004
> R10: 8801ca6f7510 R11: 0004 R12: 0093
> R13: 8801ca1c8700 R14: 8801db514850 R15: 8801db514850
> FS:  01031880() GS:8801db50() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2:  CR3: 05e22006 CR4: 001626e0
> Call Trace:
>  __write_cr4 arch/x86/include/asm/paravirt.h:76 [inline]
>  __cr4_set arch/x86/include/asm/tlbflush.h:180 [inline]
>  cr4_clear_bits arch/x86/include/asm/tlbflush.h:203 [inline]
>  kvm_cpu_vmxoff arch/x86/kvm/vmx.c:3582 [inline]
>  hardware_disable+0x34a/0x4b0 arch/x86/kvm/vmx.c:3588
>  kvm_arch_hardware_disable+0x35/0xd0 arch/x86/kvm/x86.c:7982
>  hardware_disable_nolock+0x30/0x40
> arch/x86/kvm/../../../virt/kvm/kvm_main.c:3310
>  on_each_cpu+0xca/0x1b0 kernel/smp.c:604
>  hardware_disable_all_nolock+0x3e/0x50
> arch/x86/kvm/../../../virt/kvm/kvm_main.c:3328
>  hardware_disable_all arch/x86/kvm/../../../virt/kvm/kvm_main.c:3334
> [inline]
>  kvm_destroy_vm arch/x86/kvm/../../../virt/kvm/kvm_main.c:742 [inline]
>  kvm_put_kvm+0x956/0xdf0 arch/x86/kvm/../../../virt/kvm/kvm_main.c:755
>  kvm_vm_release+0x42/0x50 arch/x86/kvm/../../../virt/kvm/kvm_main.c:766
>  __fput+0x327/0x7e0 fs/file_table.c:210
>  fput+0x15/0x20 fs/file_table.c:244
>  task_work_run+0x199/0x270 kernel/task_work.c:113
>  exit_task_work include/linux/task_work.h:22 [inline]
>  do_exit+0x9bb/0x1ad0 kernel/exit.c:865
>  do_group_exit+0x149/0x400 kernel/exit.c:968
>  SYSC_exit_group kernel/exit.c:979 [inline]
>  SyS_exit_group+0x1d/0x20 kernel/exit.c:977
>  entry_SYSCALL_64_fastpath+0x1f/0x96
> RIP: 0033:0x441c78
> RSP: 002b:7ffe68e20f68 EFLAGS: 0246 ORIG_RAX: 00e7
> RAX: ffda RBX: 004002c8 RCX: 00441c78
> RDX:  RSI: 003c RDI: 
> RBP: 006cd018 R08: 00e7 R09: ffd0
> R10: 0012 R11: 0246 R12: 00404080
> R13: 00404110 R14:  R15: 
> Code: 0f 1f 80 00 00 00 00 55 48 89 e5 0f 20 d8 5d c3 0f 1f 80 00 00 00 00
> 55 48 89 e5 0f 22 df 5d c3 0f 1f 80 00 00 00 00 55 48 89 e5 <0f> 22 e7 5d c3
> 0f 1f 80 00 00 00 00 55 48 89 e5 44 0f 20 c0 5d
> RIP: native_write_cr4+0x4/0x10 arch/x86/include/asm/special_insns.h:76 RSP:
> 8801ca6f75a0
> ---[ end trace ca14f0c15b26c251 ]---
>
>
> ---
> 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 merged into any tree, 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.

Re: general protection fault in native_write_cr4

[Wanpeng Li]

2017-12-20 15:49 GMT+08:00 syzbot
:
> Hello,
>
> syzkaller hit the following crash on
> f6f3732162b5ae3c771b9285a5a32d72b8586920
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> C reproducer is attached
> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> for information about syzkaller reproducers
>
>

I will have a look again, you continue to run it in kvm guest, right?

Regards,
Wanpeng Li

> kvm: KVM_SET_TSS_ADDR need to be called before entering vcpu
> kasan: CONFIG_KASAN_INLINE enabled
> kasan: GPF could be caused by NULL-ptr deref or user memory access
> general protection fault:  [#1] SMP KASAN
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Modules linked in:
> CPU: 1 PID: 3142 Comm: syzkaller429302 Not tainted 4.15.0-rc3+ #224
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> RIP: 0010:native_write_cr4+0x4/0x10 arch/x86/include/asm/special_insns.h:76
> RSP: 0018:8801ca6f75a0 EFLAGS: 00010093
> RAX: 8801ca1c8700 RBX: 001606e0 RCX: 811a2a92
> RDX:  RSI:  RDI: 001606e0
> RBP: 8801ca6f75a0 R08: 1100394dee0f R09: 0004
> R10: 8801ca6f7510 R11: 0004 R12: 0093
> R13: 8801ca1c8700 R14: 8801db514850 R15: 8801db514850
> FS:  01031880() GS:8801db50() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2:  CR3: 05e22006 CR4: 001626e0
> Call Trace:
>  __write_cr4 arch/x86/include/asm/paravirt.h:76 [inline]
>  __cr4_set arch/x86/include/asm/tlbflush.h:180 [inline]
>  cr4_clear_bits arch/x86/include/asm/tlbflush.h:203 [inline]
>  kvm_cpu_vmxoff arch/x86/kvm/vmx.c:3582 [inline]
>  hardware_disable+0x34a/0x4b0 arch/x86/kvm/vmx.c:3588
>  kvm_arch_hardware_disable+0x35/0xd0 arch/x86/kvm/x86.c:7982
>  hardware_disable_nolock+0x30/0x40
> arch/x86/kvm/../../../virt/kvm/kvm_main.c:3310
>  on_each_cpu+0xca/0x1b0 kernel/smp.c:604
>  hardware_disable_all_nolock+0x3e/0x50
> arch/x86/kvm/../../../virt/kvm/kvm_main.c:3328
>  hardware_disable_all arch/x86/kvm/../../../virt/kvm/kvm_main.c:3334
> [inline]
>  kvm_destroy_vm arch/x86/kvm/../../../virt/kvm/kvm_main.c:742 [inline]
>  kvm_put_kvm+0x956/0xdf0 arch/x86/kvm/../../../virt/kvm/kvm_main.c:755
>  kvm_vm_release+0x42/0x50 arch/x86/kvm/../../../virt/kvm/kvm_main.c:766
>  __fput+0x327/0x7e0 fs/file_table.c:210
>  fput+0x15/0x20 fs/file_table.c:244
>  task_work_run+0x199/0x270 kernel/task_work.c:113
>  exit_task_work include/linux/task_work.h:22 [inline]
>  do_exit+0x9bb/0x1ad0 kernel/exit.c:865
>  do_group_exit+0x149/0x400 kernel/exit.c:968
>  SYSC_exit_group kernel/exit.c:979 [inline]
>  SyS_exit_group+0x1d/0x20 kernel/exit.c:977
>  entry_SYSCALL_64_fastpath+0x1f/0x96
> RIP: 0033:0x441c78
> RSP: 002b:7ffe68e20f68 EFLAGS: 0246 ORIG_RAX: 00e7
> RAX: ffda RBX: 004002c8 RCX: 00441c78
> RDX:  RSI: 003c RDI: 
> RBP: 006cd018 R08: 00e7 R09: ffd0
> R10: 0012 R11: 0246 R12: 00404080
> R13: 00404110 R14:  R15: 
> Code: 0f 1f 80 00 00 00 00 55 48 89 e5 0f 20 d8 5d c3 0f 1f 80 00 00 00 00
> 55 48 89 e5 0f 22 df 5d c3 0f 1f 80 00 00 00 00 55 48 89 e5 <0f> 22 e7 5d c3
> 0f 1f 80 00 00 00 00 55 48 89 e5 44 0f 20 c0 5d
> RIP: native_write_cr4+0x4/0x10 arch/x86/include/asm/special_insns.h:76 RSP:
> 8801ca6f75a0
> ---[ end trace ca14f0c15b26c251 ]---
>
>
> ---
> 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 merged into any tree, 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.

Re: BUG: unable to handle kernel NULL pointer dereference in rb_insert_color

[Dmitry Vyukov]

On Tue, Dec 19, 2017 at 10:59 PM, Eric Biggers  wrote:
> On Tue, Dec 19, 2017 at 12:41:01AM -0800, syzbot wrote:
>> Hello,
>>
>> syzkaller hit the following crash on
>> 6084b576dca2e898f5c101baef151f7bfdbb606d
>> 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.
>>
>> Unfortunately, I don't have any reproducer for this bug yet.
>>
>>
>> sctp: [Deprecated]: syz-executor6 (pid 4202) Use of int in max_burst
>> socket option.
>> Use struct sctp_assoc_value instead
>> BUG: unable to handle kernel NULL pointer dereference at 0008
>> sctp: [Deprecated]: syz-executor4 (pid 4240) Use of int in max_burst
>> socket option.
>> Use struct sctp_assoc_value instead
>> sctp: [Deprecated]: syz-executor4 (pid 4240) Use of int in max_burst
>> socket option.
>> Use struct sctp_assoc_value instead
>> IP: __rb_insert lib/rbtree.c:126 [inline]
>> IP: rb_insert_color+0x17/0x190 lib/rbtree.c:452
>> PGD 0 P4D 0
>> Oops:  [#1] SMP
>> Dumping ftrace buffer:
>>(ftrace buffer empty)
>> Modules linked in:
>> CPU: 0 PID: 4244 Comm: modprobe Not tainted 4.15.0-rc3-next-20171214+ #67
>> Hardware name: Google Google Compute Engine/Google Compute Engine,
>> BIOS Google 01/01/2011
>> RIP: 0010:__rb_insert lib/rbtree.c:126 [inline]
>> RIP: 0010:rb_insert_color+0x17/0x190 lib/rbtree.c:452
>> RSP: 0018:c900010a7c08 EFLAGS: 00010246
>> RAX:  RBX:  RCX: 814ddcb9
>> RDX: 8801ebedf988 RSI: 8801ebfd6400 RDI: 88021413a408
>> RBP: c900010a7c08 R08: 0002bcf8 R09: 88021413a400
>> R10:  R11:  R12: 88021413a400
>> R13: 8801ebedf990 R14: a34fc52a R15: 8801ebedf988
>> FS:  7f85a5155700() GS:88021fc0() knlGS:
>> CS:  0010 DS:  ES:  CR0: 80050033
>> CR2: 0008 CR3: 0001eaccd006 CR4: 001606f0
>> DR0: 2000 DR1: 2000 DR2: 
>> DR3:  DR6: 0ff0 DR7: 0600
>> Call Trace:
>>  ext4_htree_store_dirent+0x122/0x160 fs/ext4/dir.c:488
>>  htree_dirblock_to_tree+0x112/0x300 fs/ext4/namei.c:1019
>>  ext4_htree_fill_tree+0xdf/0x410 fs/ext4/namei.c:1096
>>  ext4_dx_readdir fs/ext4/dir.c:575 [inline]
>>  ext4_readdir+0x8cf/0xd70 fs/ext4/dir.c:122
>>  iterate_dir+0xb8/0x200 fs/readdir.c:51
>>  SYSC_getdents fs/readdir.c:231 [inline]
>>  SyS_getdents+0xcc/0x1b0 fs/readdir.c:212
>>  entry_SYSCALL_64_fastpath+0x1f/0x96
>> RIP: 0033:0x7f85a4a45575
>> RSP: 002b:7ffc9b5be120 EFLAGS: 0246 ORIG_RAX: 004e
>> RAX: ffda RBX: 7f85a4d23e98 RCX: 7f85a4a45575
>> RDX: 8000 RSI: 5633094701e0 RDI: 
>> RBP: 7f85a4d23e40 R08: 5633094701e0 R09: 7f85a4d23e90
>> R10:  R11: 0246 R12: 5633094701b0
>> R13: 00018e21 R14:  R15: 0004
>> Code: 48 85 d2 75 eb 5d c3 31 c0 5d c3 66 0f 1f 84 00 00 00 00 00 55
>> 48 8b 17 48 89 e5 48 85 d2 0f 84 4c 01 00 00 48 8b 02 a8 01 75 5e
>> <48> 8b 48 08 49 89 c0 48 39 d1 74 54 48 85 c9 74 09 f6 01 01 0f
>> RIP: __rb_insert lib/rbtree.c:126 [inline] RSP: c900010a7c08
>> RIP: rb_insert_color+0x17/0x190 lib/rbtree.c:452 RSP: c900010a7c08
>> CR2: 0008
>> BUG: unable to handle kernel paging request at 00010001
>> ---[ end trace c403bd3ebad2ccb0 ]---
>
> The line number in lib/rbtree.c seems to be slightly off.  Looking at the
> disassembly:
>
> 825b5ea0 :
> 825b5ea0:   55  push   %rbp
> 825b5ea1:   48 8b 17mov(%rdi),%rdx
> 825b5ea4:   48 89 e5mov%rsp,%rbp
> 825b5ea7:   48 85 d2test   %rdx,%rdx
> 825b5eaa:   0f 84 4c 01 00 00   je 
> 825b5ffc 
> 825b5eb0:   48 8b 02mov(%rdx),%rax
> 825b5eb3:   a8 01   test   $0x1,%al
> 825b5eb5:   75 5e   jne
> 825b5f15 
> 825b5eb7:   48 8b 48 08 mov0x8(%rax),%rcx
>
> It crashed on 'mov 0x8(%rax),%rcx' which corresponds to
> 'tmp = gparent->rb_right;' at lib/rbtree.c:131.  So 'parent' was the root 
> node,
> but its color was red, while it is supposed to be black.
>
> No idea how that happened, but it's almost certainly not an ext4 bug.  In fact
> there is another report of this same crash that has a different call trace:
>
> Call Trace:
>  key_alloc_serial security/keys/key.c:170 [inline]
>  key_alloc+0x54c/0x5b0 security/keys/key.c:319
>  keyring_alloc+0x4d/0xb0 security/keys/keyring.c:503
>  

Re: BUG: unable to handle kernel NULL pointer dereference in rb_insert_color

[Dmitry Vyukov]

On Tue, Dec 19, 2017 at 10:59 PM, Eric Biggers  wrote:
> On Tue, Dec 19, 2017 at 12:41:01AM -0800, syzbot wrote:
>> Hello,
>>
>> syzkaller hit the following crash on
>> 6084b576dca2e898f5c101baef151f7bfdbb606d
>> 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.
>>
>> Unfortunately, I don't have any reproducer for this bug yet.
>>
>>
>> sctp: [Deprecated]: syz-executor6 (pid 4202) Use of int in max_burst
>> socket option.
>> Use struct sctp_assoc_value instead
>> BUG: unable to handle kernel NULL pointer dereference at 0008
>> sctp: [Deprecated]: syz-executor4 (pid 4240) Use of int in max_burst
>> socket option.
>> Use struct sctp_assoc_value instead
>> sctp: [Deprecated]: syz-executor4 (pid 4240) Use of int in max_burst
>> socket option.
>> Use struct sctp_assoc_value instead
>> IP: __rb_insert lib/rbtree.c:126 [inline]
>> IP: rb_insert_color+0x17/0x190 lib/rbtree.c:452
>> PGD 0 P4D 0
>> Oops:  [#1] SMP
>> Dumping ftrace buffer:
>>(ftrace buffer empty)
>> Modules linked in:
>> CPU: 0 PID: 4244 Comm: modprobe Not tainted 4.15.0-rc3-next-20171214+ #67
>> Hardware name: Google Google Compute Engine/Google Compute Engine,
>> BIOS Google 01/01/2011
>> RIP: 0010:__rb_insert lib/rbtree.c:126 [inline]
>> RIP: 0010:rb_insert_color+0x17/0x190 lib/rbtree.c:452
>> RSP: 0018:c900010a7c08 EFLAGS: 00010246
>> RAX:  RBX:  RCX: 814ddcb9
>> RDX: 8801ebedf988 RSI: 8801ebfd6400 RDI: 88021413a408
>> RBP: c900010a7c08 R08: 0002bcf8 R09: 88021413a400
>> R10:  R11:  R12: 88021413a400
>> R13: 8801ebedf990 R14: a34fc52a R15: 8801ebedf988
>> FS:  7f85a5155700() GS:88021fc0() knlGS:
>> CS:  0010 DS:  ES:  CR0: 80050033
>> CR2: 0008 CR3: 0001eaccd006 CR4: 001606f0
>> DR0: 2000 DR1: 2000 DR2: 
>> DR3:  DR6: 0ff0 DR7: 0600
>> Call Trace:
>>  ext4_htree_store_dirent+0x122/0x160 fs/ext4/dir.c:488
>>  htree_dirblock_to_tree+0x112/0x300 fs/ext4/namei.c:1019
>>  ext4_htree_fill_tree+0xdf/0x410 fs/ext4/namei.c:1096
>>  ext4_dx_readdir fs/ext4/dir.c:575 [inline]
>>  ext4_readdir+0x8cf/0xd70 fs/ext4/dir.c:122
>>  iterate_dir+0xb8/0x200 fs/readdir.c:51
>>  SYSC_getdents fs/readdir.c:231 [inline]
>>  SyS_getdents+0xcc/0x1b0 fs/readdir.c:212
>>  entry_SYSCALL_64_fastpath+0x1f/0x96
>> RIP: 0033:0x7f85a4a45575
>> RSP: 002b:7ffc9b5be120 EFLAGS: 0246 ORIG_RAX: 004e
>> RAX: ffda RBX: 7f85a4d23e98 RCX: 7f85a4a45575
>> RDX: 8000 RSI: 5633094701e0 RDI: 
>> RBP: 7f85a4d23e40 R08: 5633094701e0 R09: 7f85a4d23e90
>> R10:  R11: 0246 R12: 5633094701b0
>> R13: 00018e21 R14:  R15: 0004
>> Code: 48 85 d2 75 eb 5d c3 31 c0 5d c3 66 0f 1f 84 00 00 00 00 00 55
>> 48 8b 17 48 89 e5 48 85 d2 0f 84 4c 01 00 00 48 8b 02 a8 01 75 5e
>> <48> 8b 48 08 49 89 c0 48 39 d1 74 54 48 85 c9 74 09 f6 01 01 0f
>> RIP: __rb_insert lib/rbtree.c:126 [inline] RSP: c900010a7c08
>> RIP: rb_insert_color+0x17/0x190 lib/rbtree.c:452 RSP: c900010a7c08
>> CR2: 0008
>> BUG: unable to handle kernel paging request at 00010001
>> ---[ end trace c403bd3ebad2ccb0 ]---
>
> The line number in lib/rbtree.c seems to be slightly off.  Looking at the
> disassembly:
>
> 825b5ea0 :
> 825b5ea0:   55  push   %rbp
> 825b5ea1:   48 8b 17mov(%rdi),%rdx
> 825b5ea4:   48 89 e5mov%rsp,%rbp
> 825b5ea7:   48 85 d2test   %rdx,%rdx
> 825b5eaa:   0f 84 4c 01 00 00   je 
> 825b5ffc 
> 825b5eb0:   48 8b 02mov(%rdx),%rax
> 825b5eb3:   a8 01   test   $0x1,%al
> 825b5eb5:   75 5e   jne
> 825b5f15 
> 825b5eb7:   48 8b 48 08 mov0x8(%rax),%rcx
>
> It crashed on 'mov 0x8(%rax),%rcx' which corresponds to
> 'tmp = gparent->rb_right;' at lib/rbtree.c:131.  So 'parent' was the root 
> node,
> but its color was red, while it is supposed to be black.
>
> No idea how that happened, but it's almost certainly not an ext4 bug.  In fact
> there is another report of this same crash that has a different call trace:
>
> Call Trace:
>  key_alloc_serial security/keys/key.c:170 [inline]
>  key_alloc+0x54c/0x5b0 security/keys/key.c:319
>  keyring_alloc+0x4d/0xb0 security/keys/keyring.c:503
>  install_process_keyring_to_cred.part.3+0x38/0x80 
> 

Re: [PATCH v2 2/4] pinctrl: mediatek: cleanup for placing all drivers under the menu

[Linus Walleij]

On Tue, Dec 12, 2017 at 7:24 AM,   wrote:

> From: Sean Wang 
>
> Since lots of MediaTek drivers had been added, it seems slightly better
> for that adding cleanup for placing MediaTek pinctrl drivers under the
> independent menu as other kinds of drivers usually was done.
>
> Signed-off-by: Sean Wang 
> Reviewed-by: Biao Huang 

Patch applied. Also very nice!

Yours,
Linus Walleij

Re: [PATCH v2 2/4] pinctrl: mediatek: cleanup for placing all drivers under the menu

[Linus Walleij]

On Tue, Dec 12, 2017 at 7:24 AM,   wrote:

> From: Sean Wang 
>
> Since lots of MediaTek drivers had been added, it seems slightly better
> for that adding cleanup for placing MediaTek pinctrl drivers under the
> independent menu as other kinds of drivers usually was done.
>
> Signed-off-by: Sean Wang 
> Reviewed-by: Biao Huang 

Patch applied. Also very nice!

Yours,
Linus Walleij

Re: [PATCH v2 1/4] dt-bindings: pinctrl: add bindings for MediaTek MT7622 SoC

[Linus Walleij]

On Tue, Dec 12, 2017 at 7:24 AM,   wrote:

> From: Sean Wang 
>
> Add devicetree bindings for MediaTek MT7622 pinctrl driver.
>
> Signed-off-by: Sean Wang 
> Reviewed-by: Biao Huang 

Patch applied with Rob's ACK.

Yours,
Linus Walleij

Re: [PATCH v2 1/4] dt-bindings: pinctrl: add bindings for MediaTek MT7622 SoC

[Linus Walleij]

On Tue, Dec 12, 2017 at 7:24 AM,   wrote:

> From: Sean Wang 
>
> Add devicetree bindings for MediaTek MT7622 pinctrl driver.
>
> Signed-off-by: Sean Wang 
> Reviewed-by: Biao Huang 

Patch applied with Rob's ACK.

Yours,
Linus Walleij

Re: [RFC][PATCHv6 00/12] printk: introduce printing kernel thread

[Sergey Senozhatsky]

On (12/19/17 09:40), Steven Rostedt wrote:
> On Tue, 19 Dec 2017 13:58:46 +0900
> Sergey Senozhatsky  wrote:
> 
> > so you are not convinced that my scenarios real/matter; I'm not
> 
> Well, not with the test module. I'm looking for actual code in the
> upstream kernel.
> 
> > convinced that I have stable and functional boards with this patch ;)
> > seems that we are coming to a dead end.
> 
> Can I ask, is it any worse than what we have today?

that's a really hard question. both the existing printk() and the
tweaked printk() have the same thing in common - a) preemption from
console_unlock() and b) printk() being way to fast compared to anything
else (call_console_drivers() and to preemption latency of console_sem
owner). your patch puts some requirements that my workload simply cannot
fulfill. so may be if I'll start pushing it towards OOM and so on, then
I'll see some difference (but both (a) and (b) still gonna stay true).

the thing that really changes everything is offloading to printk_kthread.
given that I can't have a tiny logbuf, and that I can't have fast console,
and that I can't have tons of printks to chose from and to get advantage
of hand off algorithm in any reliable way; I need something more to
guarantee that the current console_sem will not be forced to evict all
logbuf messages.

> > for the record,
> > I'm not going to block the patch if you want it to be merged.
> 
> Thanks,

I mean it :)

-ss

Re: [RFC][PATCHv6 00/12] printk: introduce printing kernel thread

[Sergey Senozhatsky]

On (12/19/17 09:40), Steven Rostedt wrote:
> On Tue, 19 Dec 2017 13:58:46 +0900
> Sergey Senozhatsky  wrote:
> 
> > so you are not convinced that my scenarios real/matter; I'm not
> 
> Well, not with the test module. I'm looking for actual code in the
> upstream kernel.
> 
> > convinced that I have stable and functional boards with this patch ;)
> > seems that we are coming to a dead end.
> 
> Can I ask, is it any worse than what we have today?

that's a really hard question. both the existing printk() and the
tweaked printk() have the same thing in common - a) preemption from
console_unlock() and b) printk() being way to fast compared to anything
else (call_console_drivers() and to preemption latency of console_sem
owner). your patch puts some requirements that my workload simply cannot
fulfill. so may be if I'll start pushing it towards OOM and so on, then
I'll see some difference (but both (a) and (b) still gonna stay true).

the thing that really changes everything is offloading to printk_kthread.
given that I can't have a tiny logbuf, and that I can't have fast console,
and that I can't have tons of printks to chose from and to get advantage
of hand off algorithm in any reliable way; I need something more to
guarantee that the current console_sem will not be forced to evict all
logbuf messages.

> > for the record,
> > I'm not going to block the patch if you want it to be merged.
> 
> Thanks,

I mean it :)

-ss

Re: [PATCH V2 9/9] ARM: dts: stm32: add initial support of stm32mp157c eval board

[Linus Walleij]

On Mon, Dec 18, 2017 at 4:17 PM, Ludovic Barre  wrote:

> From: Ludovic Barre 
>
> Add support of stm32mp157c evaluation board (part number: STM32MP157C-EV1)
> split in 2 elements:
> -Daughter board (part number: STM32MP157C-ED1)
>  which includes CPU, memory and power supply
> -Mother board (part number: STM32MP157C-EM1)
>  which includes external peripherals (like display, camera,...)
>  and extension connectors.
>
> The daughter board can run alone, this is why the device tree files
> are split in two layers, for the complete evaluation board (ev1)
> and for the daughter board alone (ed1).
>
> Signed-off-by: Ludovic Barre 
> Signed-off-by: Alexandre Torgue 
(...)
> diff --git a/arch/arm/boot/dts/stm32mp157c-ev1.dts 
> b/arch/arm/boot/dts/stm32mp157c-ev1.dts

Evaluation boards are important because they set a pattern that customers
will use.

Please consider to include nodes for all GPIO blocks used in this
evaluation board, and add:

gpio-line-names = "foo", "bar" ...;

See for example
arch/arm/boot/dts/bcm2835-rpi-a.dts
arch/arm/boot/dts/ste-snowball.dts

It's good to have because probably you guys have proper schematics and
know rail names of the stuff connected to those GPIO lines and so on,
so you can give the lines proper names.

It will be helpful for people using the reference design, especially with the
new character device, and also sets a pattern for people doing devices
based on the reference design and we really want to do that.

Yours,
Linus Walleij

Re: [PATCH V2 9/9] ARM: dts: stm32: add initial support of stm32mp157c eval board

[Linus Walleij]

On Mon, Dec 18, 2017 at 4:17 PM, Ludovic Barre  wrote:

> From: Ludovic Barre 
>
> Add support of stm32mp157c evaluation board (part number: STM32MP157C-EV1)
> split in 2 elements:
> -Daughter board (part number: STM32MP157C-ED1)
>  which includes CPU, memory and power supply
> -Mother board (part number: STM32MP157C-EM1)
>  which includes external peripherals (like display, camera,...)
>  and extension connectors.
>
> The daughter board can run alone, this is why the device tree files
> are split in two layers, for the complete evaluation board (ev1)
> and for the daughter board alone (ed1).
>
> Signed-off-by: Ludovic Barre 
> Signed-off-by: Alexandre Torgue 
(...)
> diff --git a/arch/arm/boot/dts/stm32mp157c-ev1.dts 
> b/arch/arm/boot/dts/stm32mp157c-ev1.dts

Evaluation boards are important because they set a pattern that customers
will use.

Please consider to include nodes for all GPIO blocks used in this
evaluation board, and add:

gpio-line-names = "foo", "bar" ...;

See for example
arch/arm/boot/dts/bcm2835-rpi-a.dts
arch/arm/boot/dts/ste-snowball.dts

It's good to have because probably you guys have proper schematics and
know rail names of the stuff connected to those GPIO lines and so on,
so you can give the lines proper names.

It will be helpful for people using the reference design, especially with the
new character device, and also sets a pattern for people doing devices
based on the reference design and we really want to do that.

Yours,
Linus Walleij

Re: [PATCH] staging: ccree: use size_t consistently

[Greg Kroah-Hartman]

On Wed, Dec 20, 2017 at 07:23:31AM +, Gilad Ben-Yossef wrote:
> Fix declaration, implementation and wrapper function to use
> the same size_t type we actually define the parameter to be.
> 
> Fixes: 3f268f5d6669 ("staging: ccree: turn compile time debug log to params")
> Signed-off-by: Gilad Ben-Yossef 

You forgot the reported-by: tag :(

I'll go add it...

Re: [PATCH] staging: ccree: use size_t consistently

[Greg Kroah-Hartman]

On Wed, Dec 20, 2017 at 07:23:31AM +, Gilad Ben-Yossef wrote:
> Fix declaration, implementation and wrapper function to use
> the same size_t type we actually define the parameter to be.
> 
> Fixes: 3f268f5d6669 ("staging: ccree: turn compile time debug log to params")
> Signed-off-by: Gilad Ben-Yossef 

You forgot the reported-by: tag :(

I'll go add it...

Re: [PATCH V2 6/9] pinctrl: stm32: Add STM32MP157 MPU support

[Linus Walleij]

On Mon, Dec 18, 2017 at 4:17 PM, Ludovic Barre  wrote:

> From: Ludovic Barre 
>
> This driver consists of 2 controllers due to a hole in mapping:
> -1 controller for GPIO bankA to K.
> -1 controller for GPIO bankZ.
>
> Signed-off-by: Alexandre Torgue 
> Signed-off-by: Ludovic Barre 
> Reviewed-by: Rob Herring 

Patch applied.

Yours,
Linus Walleij

Re: [PATCH V2 6/9] pinctrl: stm32: Add STM32MP157 MPU support

[Linus Walleij]

On Mon, Dec 18, 2017 at 4:17 PM, Ludovic Barre  wrote:

> From: Ludovic Barre 
>
> This driver consists of 2 controllers due to a hole in mapping:
> -1 controller for GPIO bankA to K.
> -1 controller for GPIO bankZ.
>
> Signed-off-by: Alexandre Torgue 
> Signed-off-by: Ludovic Barre 
> Reviewed-by: Rob Herring 

Patch applied.

Yours,
Linus Walleij

Re: [PATCH V2 1/9] devicetree: bindings: Document supported STM32 SoC family

[Linus Walleij]

On Mon, Dec 18, 2017 at 4:17 PM, Ludovic Barre  wrote:

> From: Ludovic Barre 
>
> This adds a list of supported STM32 SoC bindings.
>
> Signed-off-by: Gwenael Treuveur 
> Signed-off-by: Ludovic Barre 
> Reviewed-by: Rob Herring 

Patch applied.

Yours,
Linus Walleij

Re: [PATCH V2 1/9] devicetree: bindings: Document supported STM32 SoC family

[Linus Walleij]

On Mon, Dec 18, 2017 at 4:17 PM, Ludovic Barre  wrote:

> From: Ludovic Barre 
>
> This adds a list of supported STM32 SoC bindings.
>
> Signed-off-by: Gwenael Treuveur 
> Signed-off-by: Ludovic Barre 
> Reviewed-by: Rob Herring 

Patch applied.

Yours,
Linus Walleij

Re: [PATCH] kfree_rcu() should use the new kfree_bulk() interface for freeing rcu structures

[Jesper Dangaard Brouer]

On Tue, 19 Dec 2017 13:20:43 -0800 Rao Shoaib  wrote:

> On 12/19/2017 12:41 PM, Jesper Dangaard Brouer wrote:
> > On Tue, 19 Dec 2017 09:52:27 -0800 rao.sho...@oracle.com wrote:
> >  
> >> +/* Main RCU function that is called to free RCU structures */
> >> +static void
> >> +__rcu_bulk_free(struct rcu_head *head, rcu_callback_t func, int cpu, bool 
> >> lazy)
> >> +{
> >> +  unsigned long offset;
> >> +  void *ptr;
> >> +  struct rcu_bulk_free *rbf;
> >> +  struct rcu_bulk_free_container *rbfc = NULL;
> >> +
> >> +  rbf = this_cpu_ptr(_rbf);
> >> +
> >> +  if (unlikely(!rbf->rbf_init)) {
> >> +  spin_lock_init(>rbf_lock);
> >> +  rbf->rbf_cpu = smp_processor_id();
> >> +  rbf->rbf_init = true;
> >> +  }
> >> +
> >> +  /* hold lock to protect against other cpu's */
> >> +  spin_lock_bh(>rbf_lock);  
> >
> > I'm not sure this will be faster.  Having to take a cross CPU lock here
> > (+ BH-disable) could cause scaling issues.   Hopefully this lock will
> > not be used intensively by other CPUs, right?
> >
[...]
> 
> As Paul has pointed out the lock is a per-cpu lock, the only reason for 
> another CPU to access this lock is if the rcu callbacks run on a 
> different CPU and there is nothing the code can do to avoid that but 
> that should be rare anyways.

(loop in Paul's comment)
On Tue, 19 Dec 2017 12:56:29 -0800
"Paul E. McKenney"  wrote:

> Isn't this lock in a per-CPU object?  It -might- go cross-CPU in response
> to CPU-hotplug operations, but that should be rare.

Point taken.  If this lock is very unlikely to be taken on another CPU
then I withdraw my performance concerns (the cacheline can hopefully
stay in Modified(M) state on this CPU, and all other CPUs will have in
in Invalid(I) state based on MESI cache coherence protocol view[1]).

The lock's atomic operation does have some overhead, and _later_ if we
could get fancy and use seqlock (include/linux/seqlock.h) to remove
that.

[1] https://en.wikipedia.org/wiki/MESI_protocol
-- 
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Principal Kernel Engineer at Red Hat
  LinkedIn: http://www.linkedin.com/in/brouer

[PATCH v6 0/2] KVM: MMU: fix kvm_is_mmio_pfn()

[Haozhong Zhang]

Some reserved pages, such as those from NVDIMM DAX devices, are not
for MMIO, and can be mapped with cached memory type for better
performance. However, the above check misconceives those pages as
MMIO.  Because KVM maps MMIO pages with UC memory type, the
performance of guest accesses to those pages would be harmed.
Therefore, we check the host memory type in addition and only treat
UC/UC-/WC pages as MMIO.

Changes in v6:
 * Rename the function in patch 1 to pat_immune_to_uc_mtrr().
 * Consider WC memory type in patch 1.

Changes in v5:
 * Rename pat_pfn_is_uc() into pat_pfn_is_uc_or_uc_minus() to avoid
   confusion.
 * Drop converters between kvm_pfn_t and pfn_t, because they are not
   necessary. pat_pfn_is_uc_or_uc_minus() does not need flags in
   pfn_t, so we can only pass a raw unsigned long to it.

Changes in v4:
 * Mask pfn_t and kvm_pfn_t specific flags in conversion.

Changes in v3:
 * Move cache mode check to pat.c as pat_pfn_is_uc()
 * Reintroduce converters between kvm_pfn_t and pfn_t.

Changes in v2:
 * Switch to lookup_memtype() to get host memory type.
 * Rewrite the comment in KVM MMU patch.
 * Remove v1 patch 2, which is not necessary in v2.

Haozhong Zhang (2):
  x86/mm: add a function to check if a pfn is UC/UC-/WC
  KVM: MMU: consider host cache mode in MMIO page check

 arch/x86/include/asm/pat.h |  2 ++
 arch/x86/kvm/mmu.c | 13 -
 arch/x86/mm/pat.c  | 19 +++
 3 files changed, 33 insertions(+), 1 deletion(-)

-- 
2.14.1

Re: [PATCH] kfree_rcu() should use the new kfree_bulk() interface for freeing rcu structures

[Jesper Dangaard Brouer]

On Tue, 19 Dec 2017 13:20:43 -0800 Rao Shoaib  wrote:

> On 12/19/2017 12:41 PM, Jesper Dangaard Brouer wrote:
> > On Tue, 19 Dec 2017 09:52:27 -0800 rao.sho...@oracle.com wrote:
> >  
> >> +/* Main RCU function that is called to free RCU structures */
> >> +static void
> >> +__rcu_bulk_free(struct rcu_head *head, rcu_callback_t func, int cpu, bool 
> >> lazy)
> >> +{
> >> +  unsigned long offset;
> >> +  void *ptr;
> >> +  struct rcu_bulk_free *rbf;
> >> +  struct rcu_bulk_free_container *rbfc = NULL;
> >> +
> >> +  rbf = this_cpu_ptr(_rbf);
> >> +
> >> +  if (unlikely(!rbf->rbf_init)) {
> >> +  spin_lock_init(>rbf_lock);
> >> +  rbf->rbf_cpu = smp_processor_id();
> >> +  rbf->rbf_init = true;
> >> +  }
> >> +
> >> +  /* hold lock to protect against other cpu's */
> >> +  spin_lock_bh(>rbf_lock);  
> >
> > I'm not sure this will be faster.  Having to take a cross CPU lock here
> > (+ BH-disable) could cause scaling issues.   Hopefully this lock will
> > not be used intensively by other CPUs, right?
> >
[...]
> 
> As Paul has pointed out the lock is a per-cpu lock, the only reason for 
> another CPU to access this lock is if the rcu callbacks run on a 
> different CPU and there is nothing the code can do to avoid that but 
> that should be rare anyways.

(loop in Paul's comment)
On Tue, 19 Dec 2017 12:56:29 -0800
"Paul E. McKenney"  wrote:

> Isn't this lock in a per-CPU object?  It -might- go cross-CPU in response
> to CPU-hotplug operations, but that should be rare.

Point taken.  If this lock is very unlikely to be taken on another CPU
then I withdraw my performance concerns (the cacheline can hopefully
stay in Modified(M) state on this CPU, and all other CPUs will have in
in Invalid(I) state based on MESI cache coherence protocol view[1]).

The lock's atomic operation does have some overhead, and _later_ if we
could get fancy and use seqlock (include/linux/seqlock.h) to remove
that.

[1] https://en.wikipedia.org/wiki/MESI_protocol
-- 
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Principal Kernel Engineer at Red Hat
  LinkedIn: http://www.linkedin.com/in/brouer

[PATCH v6 0/2] KVM: MMU: fix kvm_is_mmio_pfn()

[Haozhong Zhang]

Some reserved pages, such as those from NVDIMM DAX devices, are not
for MMIO, and can be mapped with cached memory type for better
performance. However, the above check misconceives those pages as
MMIO.  Because KVM maps MMIO pages with UC memory type, the
performance of guest accesses to those pages would be harmed.
Therefore, we check the host memory type in addition and only treat
UC/UC-/WC pages as MMIO.

Changes in v6:
 * Rename the function in patch 1 to pat_immune_to_uc_mtrr().
 * Consider WC memory type in patch 1.

Changes in v5:
 * Rename pat_pfn_is_uc() into pat_pfn_is_uc_or_uc_minus() to avoid
   confusion.
 * Drop converters between kvm_pfn_t and pfn_t, because they are not
   necessary. pat_pfn_is_uc_or_uc_minus() does not need flags in
   pfn_t, so we can only pass a raw unsigned long to it.

Changes in v4:
 * Mask pfn_t and kvm_pfn_t specific flags in conversion.

Changes in v3:
 * Move cache mode check to pat.c as pat_pfn_is_uc()
 * Reintroduce converters between kvm_pfn_t and pfn_t.

Changes in v2:
 * Switch to lookup_memtype() to get host memory type.
 * Rewrite the comment in KVM MMU patch.
 * Remove v1 patch 2, which is not necessary in v2.

Haozhong Zhang (2):
  x86/mm: add a function to check if a pfn is UC/UC-/WC
  KVM: MMU: consider host cache mode in MMIO page check

 arch/x86/include/asm/pat.h |  2 ++
 arch/x86/kvm/mmu.c | 13 -
 arch/x86/mm/pat.c  | 19 +++
 3 files changed, 33 insertions(+), 1 deletion(-)

-- 
2.14.1

[PATCH v6 2/2] KVM: MMU: consider host cache mode in MMIO page check

[Haozhong Zhang]

Some reserved pages, such as those from NVDIMM DAX devices, are not
for MMIO, and can be mapped with cached memory type for better
performance. However, the above check misconceives those pages as
MMIO.  Because KVM maps MMIO pages with UC memory type, the
performance of guest accesses to those pages would be harmed.
Therefore, we check the host memory type in addition and only treat
UC/UC-/WC pages as MMIO.

Signed-off-by: Haozhong Zhang 
Reported-by: Cuevas Escareno, Ivan D 
Reported-by: Kumar, Karthik 
Reviewed-by: Xiao Guangrong 
---
 arch/x86/kvm/mmu.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 89da688784fa..e3b9998b3355 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -2708,7 +2708,18 @@ static bool mmu_need_write_protect(struct kvm_vcpu 
*vcpu, gfn_t gfn,
 static bool kvm_is_mmio_pfn(kvm_pfn_t pfn)
 {
if (pfn_valid(pfn))
-   return !is_zero_pfn(pfn) && PageReserved(pfn_to_page(pfn));
+   return !is_zero_pfn(pfn) && PageReserved(pfn_to_page(pfn)) &&
+   /*
+* Some reserved pages, such as those from NVDIMM
+* DAX devices, are not for MMIO, and can be mapped
+* with cached memory type for better performance.
+* However, the above check misconceives those pages
+* as MMIO, and results in KVM mapping them with UC
+* memory type, which would hurt the performance.
+* Therefore, we check the host memory type in addition
+* and only treat UC/UC-/WC pages as MMIO.
+*/
+   (!pat_enabled() || pat_immune_to_uc_mtrr(pfn));
 
return true;
 }
-- 
2.14.1

[PATCH v6 2/2] KVM: MMU: consider host cache mode in MMIO page check

[Haozhong Zhang]

Some reserved pages, such as those from NVDIMM DAX devices, are not
for MMIO, and can be mapped with cached memory type for better
performance. However, the above check misconceives those pages as
MMIO.  Because KVM maps MMIO pages with UC memory type, the
performance of guest accesses to those pages would be harmed.
Therefore, we check the host memory type in addition and only treat
UC/UC-/WC pages as MMIO.

Signed-off-by: Haozhong Zhang 
Reported-by: Cuevas Escareno, Ivan D 
Reported-by: Kumar, Karthik 
Reviewed-by: Xiao Guangrong 
---
 arch/x86/kvm/mmu.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 89da688784fa..e3b9998b3355 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -2708,7 +2708,18 @@ static bool mmu_need_write_protect(struct kvm_vcpu 
*vcpu, gfn_t gfn,
 static bool kvm_is_mmio_pfn(kvm_pfn_t pfn)
 {
if (pfn_valid(pfn))
-   return !is_zero_pfn(pfn) && PageReserved(pfn_to_page(pfn));
+   return !is_zero_pfn(pfn) && PageReserved(pfn_to_page(pfn)) &&
+   /*
+* Some reserved pages, such as those from NVDIMM
+* DAX devices, are not for MMIO, and can be mapped
+* with cached memory type for better performance.
+* However, the above check misconceives those pages
+* as MMIO, and results in KVM mapping them with UC
+* memory type, which would hurt the performance.
+* Therefore, we check the host memory type in addition
+* and only treat UC/UC-/WC pages as MMIO.
+*/
+   (!pat_enabled() || pat_immune_to_uc_mtrr(pfn));
 
return true;
 }
-- 
2.14.1

Re: [ANNOUNCE] autofs 5.1.2 release

[Ian Kent]

On 20/12/17 13:52, Ian Kent wrote:
> On 20/12/17 11:29, NeilBrown wrote:
>>
>> Hi Ian,
>>  I've been looking at:
>>
>>> - add configuration option to use fqdn in mounts.
>>
>> (commit 9aeef772604) because using this new option causes a regression.
>> If you are using the "replicated server" functionality, then
>>   use_hostname_for_mounts = yes
>> completely disables it.
> 
> Yes, that's not quite right.
> 
> It disables the probe and proximity check for each distinct host
> name used.
> 
> Each of the entries in the list of hosts should still be
> attempted and given that NFS ping is also now used in the NFS
> mount module what's lost is the preferred ordering of the hosts
> list.

Mmm  that's also not right.

An NFS ping is only done on failed local bind mount to check
the NFS server is running on the local machine.

So that availability check needs to be done at mount time if
the proximity check is not done 

Ian

[PATCH v6 1/2] x86/mm: add a function to check if a pfn is UC/UC-/WCee

[Haozhong Zhang]

Check whether the PAT memory type of a pfn cannot be overridden by
MTRR UC memory type, i.e. the PAT memory type is UC, UC- or WC. This
function will be used by KVM to determine whether it needs to map a
host pfn to guest with UC memory type.

Signed-off-by: Haozhong Zhang 
Reviewed-by: Xiao Guangrong 
---
 arch/x86/include/asm/pat.h |  2 ++
 arch/x86/mm/pat.c  | 19 +++
 2 files changed, 21 insertions(+)

diff --git a/arch/x86/include/asm/pat.h b/arch/x86/include/asm/pat.h
index 8a3ee355b422..9a217a18523b 100644
--- a/arch/x86/include/asm/pat.h
+++ b/arch/x86/include/asm/pat.h
@@ -22,4 +22,6 @@ int io_reserve_memtype(resource_size_t start, resource_size_t 
end,
 
 void io_free_memtype(resource_size_t start, resource_size_t end);
 
+bool pat_immune_to_uc_mtrr(unsigned long pfn);
+
 #endif /* _ASM_X86_PAT_H */
diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
index fe7d57a8fb60..2231a84c3d34 100644
--- a/arch/x86/mm/pat.c
+++ b/arch/x86/mm/pat.c
@@ -677,6 +677,25 @@ static enum page_cache_mode lookup_memtype(u64 paddr)
return rettype;
 }
 
+/**
+ * Check whether the PAT memory type of @pfn cannot be overridden by
+ * UC MTRR memory type.
+ *
+ * Only to be called when PAT is enabled.
+ *
+ * Returns true, if the PAT memory type of @pfn is UC, UC-, or WC.
+ * Returns false in other cases.
+ */
+bool pat_immune_to_uc_mtrr(unsigned long pfn)
+{
+   enum page_cache_mode cm = lookup_memtype(PFN_PHYS(pfn));
+
+   return cm == _PAGE_CACHE_MODE_UC ||
+  cm == _PAGE_CACHE_MODE_UC_MINUS ||
+  cm == _PAGE_CACHE_MODE_WC;
+}
+EXPORT_SYMBOL_GPL(pat_immune_to_uc_mtrr);
+
 /**
  * io_reserve_memtype - Request a memory type mapping for a region of memory
  * @start: start (physical address) of the region
-- 
2.14.1

Re: [ANNOUNCE] autofs 5.1.2 release

[Ian Kent]

On 20/12/17 13:52, Ian Kent wrote:
> On 20/12/17 11:29, NeilBrown wrote:
>>
>> Hi Ian,
>>  I've been looking at:
>>
>>> - add configuration option to use fqdn in mounts.
>>
>> (commit 9aeef772604) because using this new option causes a regression.
>> If you are using the "replicated server" functionality, then
>>   use_hostname_for_mounts = yes
>> completely disables it.
> 
> Yes, that's not quite right.
> 
> It disables the probe and proximity check for each distinct host
> name used.
> 
> Each of the entries in the list of hosts should still be
> attempted and given that NFS ping is also now used in the NFS
> mount module what's lost is the preferred ordering of the hosts
> list.

Mmm  that's also not right.

An NFS ping is only done on failed local bind mount to check
the NFS server is running on the local machine.

So that availability check needs to be done at mount time if
the proximity check is not done 

Ian

[PATCH v6 1/2] x86/mm: add a function to check if a pfn is UC/UC-/WCee

[Haozhong Zhang]

Check whether the PAT memory type of a pfn cannot be overridden by
MTRR UC memory type, i.e. the PAT memory type is UC, UC- or WC. This
function will be used by KVM to determine whether it needs to map a
host pfn to guest with UC memory type.

Signed-off-by: Haozhong Zhang 
Reviewed-by: Xiao Guangrong 
---
 arch/x86/include/asm/pat.h |  2 ++
 arch/x86/mm/pat.c  | 19 +++
 2 files changed, 21 insertions(+)

diff --git a/arch/x86/include/asm/pat.h b/arch/x86/include/asm/pat.h
index 8a3ee355b422..9a217a18523b 100644
--- a/arch/x86/include/asm/pat.h
+++ b/arch/x86/include/asm/pat.h
@@ -22,4 +22,6 @@ int io_reserve_memtype(resource_size_t start, resource_size_t 
end,
 
 void io_free_memtype(resource_size_t start, resource_size_t end);
 
+bool pat_immune_to_uc_mtrr(unsigned long pfn);
+
 #endif /* _ASM_X86_PAT_H */
diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
index fe7d57a8fb60..2231a84c3d34 100644
--- a/arch/x86/mm/pat.c
+++ b/arch/x86/mm/pat.c
@@ -677,6 +677,25 @@ static enum page_cache_mode lookup_memtype(u64 paddr)
return rettype;
 }
 
+/**
+ * Check whether the PAT memory type of @pfn cannot be overridden by
+ * UC MTRR memory type.
+ *
+ * Only to be called when PAT is enabled.
+ *
+ * Returns true, if the PAT memory type of @pfn is UC, UC-, or WC.
+ * Returns false in other cases.
+ */
+bool pat_immune_to_uc_mtrr(unsigned long pfn)
+{
+   enum page_cache_mode cm = lookup_memtype(PFN_PHYS(pfn));
+
+   return cm == _PAGE_CACHE_MODE_UC ||
+  cm == _PAGE_CACHE_MODE_UC_MINUS ||
+  cm == _PAGE_CACHE_MODE_WC;
+}
+EXPORT_SYMBOL_GPL(pat_immune_to_uc_mtrr);
+
 /**
  * io_reserve_memtype - Request a memory type mapping for a region of memory
  * @start: start (physical address) of the region
-- 
2.14.1

GOOD DAY FROM MOHAMMED AHMED .

[Mr Mohamad Ahmed]

My Dear  Friend.

I am Mr. Mohammed Ahmed, I work with Bank Of Africa Burkina Faso West
Africa as their Auditing Manager.  My Dear I am sending you this
business proposal in regards to release and transfer of $13.5 M USD
into a foreign account.

Everything about the transaction shall be done legal and official on
your behalf without any problem for all I require from you is to
provide foreign account to receive the fund, Please you shouldn’t be
embarrassed how I came across your email ID for I got your contact
address from internet Directory and I decided to get in touch with you
with the proposal.

If you are interested to execute the business with me and also provide
foreign account to receive the fund then get back to me for more
details about the business deal and as soon as I receive your positive
response along with your personal information, I will not hesitate to
feed you with more details on how we are to achieve our goal.

You will be entitle  to have 50% as your own share from the fund and
50% will for me,  If you are willing to execute the business  then
send me immediately your personal  information needed to enable us
proceed ahead with the business.


1. Full name:.
2. Current Address:.
3. Phone.
4. Occupation:.
5. Age:
6. Country:
7. Sex
8. Your Passport or ID card or Driving License

Waiting For Your Urgent Response

Thanks

Mr. Mohammed Ahmed.

GOOD DAY FROM MOHAMMED AHMED .

[Mr Mohamad Ahmed]

My Dear  Friend.

I am Mr. Mohammed Ahmed, I work with Bank Of Africa Burkina Faso West
Africa as their Auditing Manager.  My Dear I am sending you this
business proposal in regards to release and transfer of $13.5 M USD
into a foreign account.

Everything about the transaction shall be done legal and official on
your behalf without any problem for all I require from you is to
provide foreign account to receive the fund, Please you shouldn’t be
embarrassed how I came across your email ID for I got your contact
address from internet Directory and I decided to get in touch with you
with the proposal.

If you are interested to execute the business with me and also provide
foreign account to receive the fund then get back to me for more
details about the business deal and as soon as I receive your positive
response along with your personal information, I will not hesitate to
feed you with more details on how we are to achieve our goal.

You will be entitle  to have 50% as your own share from the fund and
50% will for me,  If you are willing to execute the business  then
send me immediately your personal  information needed to enable us
proceed ahead with the business.


1. Full name:.
2. Current Address:.
3. Phone.
4. Occupation:.
5. Age:
6. Country:
7. Sex
8. Your Passport or ID card or Driving License

Waiting For Your Urgent Response

Thanks

Mr. Mohammed Ahmed.

[PATCH] staging: ccree: use size_t consistently

[Gilad Ben-Yossef]

Fix declaration, implementation and wrapper function to use
the same size_t type we actually define the parameter to be.

Fixes: 3f268f5d6669 ("staging: ccree: turn compile time debug log to params")
Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/ssi_driver.c | 2 +-
 drivers/staging/ccree/ssi_driver.h | 5 ++---
 2 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/ccree/ssi_driver.c 
b/drivers/staging/ccree/ssi_driver.c
index 56b5d45..1254c69 100644
--- a/drivers/staging/ccree/ssi_driver.c
+++ b/drivers/staging/ccree/ssi_driver.c
@@ -86,7 +86,7 @@ void __dump_byte_array(const char *name, const u8 *buf, 
size_t len)
if (!buf)
return;
 
-   snprintf(prefix, sizeof(prefix), "%s[%lu]: ", name, len);
+   snprintf(prefix, sizeof(prefix), "%s[%zu]: ", name, len);
 
print_hex_dump(KERN_DEBUG, prefix, DUMP_PREFIX_ADDRESS, 16, 1, buf,
   len, false);
diff --git a/drivers/staging/ccree/ssi_driver.h 
b/drivers/staging/ccree/ssi_driver.h
index 5a56f7a..bf83f3e 100644
--- a/drivers/staging/ccree/ssi_driver.h
+++ b/drivers/staging/ccree/ssi_driver.h
@@ -174,10 +174,9 @@ static inline struct device *drvdata_to_dev(struct 
cc_drvdata *drvdata)
return >plat_dev->dev;
 }
 
-void __dump_byte_array(const char *name, const u8 *the_array,
-  unsigned long size);
+void __dump_byte_array(const char *name, const u8 *buf, size_t len);
 static inline void dump_byte_array(const char *name, const u8 *the_array,
-  unsigned long size)
+  size_t size)
 {
if (cc_dump_bytes)
__dump_byte_array(name, the_array, size);
-- 
2.7.4

Re: [PATCH v2 2/2] pinctrl: Allow indicating loss of pin states during low-power

[Linus Walleij]

On Mon, Dec 11, 2017 at 12:38 AM, Florian Fainelli  wrote:
> On 12/02/2017 04:48 AM, Linus Walleij wrote:

>> This should solve your problem without having to alter the semantics
>> of pinctrl_select_state() for everyone.
>
> This was exactly what I proposed initially here:
>
> http://patchwork.ozlabs.org/patch/734326/
>
> I really want to get this fixed, but I can't do that if we keep losing
> the context of the discussion (pun intended) :).

Oh sorry man. I am clearly too stupid for this job...

In accordance with things needing to be intuitive, something named
*force_* should of course force the setting into the hardware.

The original patch didn't mention the fact that it was hogs
and hogs only that was causing the trouble and that is why I
got lost. (I guess.) I have been going about this as if it was
something generic that affect all states in all devices, and to
me hogs is just an abscure corner of pin controlling...

I applied the patchwork patch from above, and elaborated
a bit on that it pertains to hogs, let's see what
happens.

For the case where a driver (not hog) needs to handle
suspend/resume transitions, proper states can hopefully
be used.

Yours,
Linus Walleij

[PATCH] staging: ccree: use size_t consistently

[Gilad Ben-Yossef]

Fix declaration, implementation and wrapper function to use
the same size_t type we actually define the parameter to be.

Fixes: 3f268f5d6669 ("staging: ccree: turn compile time debug log to params")
Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/ssi_driver.c | 2 +-
 drivers/staging/ccree/ssi_driver.h | 5 ++---
 2 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/ccree/ssi_driver.c 
b/drivers/staging/ccree/ssi_driver.c
index 56b5d45..1254c69 100644
--- a/drivers/staging/ccree/ssi_driver.c
+++ b/drivers/staging/ccree/ssi_driver.c
@@ -86,7 +86,7 @@ void __dump_byte_array(const char *name, const u8 *buf, 
size_t len)
if (!buf)
return;
 
-   snprintf(prefix, sizeof(prefix), "%s[%lu]: ", name, len);
+   snprintf(prefix, sizeof(prefix), "%s[%zu]: ", name, len);
 
print_hex_dump(KERN_DEBUG, prefix, DUMP_PREFIX_ADDRESS, 16, 1, buf,
   len, false);
diff --git a/drivers/staging/ccree/ssi_driver.h 
b/drivers/staging/ccree/ssi_driver.h
index 5a56f7a..bf83f3e 100644
--- a/drivers/staging/ccree/ssi_driver.h
+++ b/drivers/staging/ccree/ssi_driver.h
@@ -174,10 +174,9 @@ static inline struct device *drvdata_to_dev(struct 
cc_drvdata *drvdata)
return >plat_dev->dev;
 }
 
-void __dump_byte_array(const char *name, const u8 *the_array,
-  unsigned long size);
+void __dump_byte_array(const char *name, const u8 *buf, size_t len);
 static inline void dump_byte_array(const char *name, const u8 *the_array,
-  unsigned long size)
+  size_t size)
 {
if (cc_dump_bytes)
__dump_byte_array(name, the_array, size);
-- 
2.7.4

Re: [PATCH v2 2/2] pinctrl: Allow indicating loss of pin states during low-power

[Linus Walleij]

On Mon, Dec 11, 2017 at 12:38 AM, Florian Fainelli  wrote:
> On 12/02/2017 04:48 AM, Linus Walleij wrote:

>> This should solve your problem without having to alter the semantics
>> of pinctrl_select_state() for everyone.
>
> This was exactly what I proposed initially here:
>
> http://patchwork.ozlabs.org/patch/734326/
>
> I really want to get this fixed, but I can't do that if we keep losing
> the context of the discussion (pun intended) :).

Oh sorry man. I am clearly too stupid for this job...

In accordance with things needing to be intuitive, something named
*force_* should of course force the setting into the hardware.

The original patch didn't mention the fact that it was hogs
and hogs only that was causing the trouble and that is why I
got lost. (I guess.) I have been going about this as if it was
something generic that affect all states in all devices, and to
me hogs is just an abscure corner of pin controlling...

I applied the patchwork patch from above, and elaborated
a bit on that it pertains to hogs, let's see what
happens.

For the case where a driver (not hog) needs to handle
suspend/resume transitions, proper states can hopefully
be used.

Yours,
Linus Walleij

Re: [PATCH v3 14/16] phy: Add notify_speed callback

[Kishon Vijay Abraham I]

Hi,

On Wednesday 20 December 2017 11:59 AM, Manu Gautam wrote:
> Hi,
> 
> 
> On 12/20/2017 11:19 AM, Kishon Vijay Abraham I wrote:
>> Hi,
>>
>> On Tuesday 12 December 2017 08:54 PM, Manu Gautam wrote:
>>> Hi,
>>>
>>>
>>> On 12/12/2017 5:13 PM, Kishon Vijay Abraham I wrote:
 Hi,

 On Tuesday 21 November 2017 02:53 PM, Manu Gautam wrote:
> QCOM USB PHYs can monitor resume/remote-wakeup event in
> suspended state. However PHY driver must know current
> operational speed of PHY in order to set correct polarity of
> wakeup events for detection. E.g. QUSB2 PHY monitors DP/DM
> signals depending on speed is LS or FS/HS to detect resume.
> Similarly QMP USB3 PHY in SS mode should monitor RX
> terminations attach/detach and LFPS events depending on
> SSPHY is active or not.
>> Why not use a notification mechanism instead of adding new APIs in phy-core.
>> This will only bloat phy-core with APIs for a particular platform.
> 
> Do you mean notifier_chains ?
> When we have multiple instances of USB PHYs then notifier chains are not
> of much help. For any platform glue or PHY driver it will be very difficult to
> figure out if notification received for speed was for same phy/bus or a
> different one.
> Using PHY callbacks looked more elegant to me. Additionally PHY drivers
> can also use this info decide power management policy e.g. if speed is
> INVALID then it means PHY is not in a session and it can enter deepest
> low power state.
> Additionally if you prefer set_speed name over notify_speed then I am
> ok with that as well so that it sounds more generic.

I'd prefer adding modes in enum phy_mode according to speed and using 
phy_set_mode.

Thanks
Kishon

Re: [PATCH v3 14/16] phy: Add notify_speed callback

[Kishon Vijay Abraham I]

Hi,

On Wednesday 20 December 2017 11:59 AM, Manu Gautam wrote:
> Hi,
> 
> 
> On 12/20/2017 11:19 AM, Kishon Vijay Abraham I wrote:
>> Hi,
>>
>> On Tuesday 12 December 2017 08:54 PM, Manu Gautam wrote:
>>> Hi,
>>>
>>>
>>> On 12/12/2017 5:13 PM, Kishon Vijay Abraham I wrote:
 Hi,

 On Tuesday 21 November 2017 02:53 PM, Manu Gautam wrote:
> QCOM USB PHYs can monitor resume/remote-wakeup event in
> suspended state. However PHY driver must know current
> operational speed of PHY in order to set correct polarity of
> wakeup events for detection. E.g. QUSB2 PHY monitors DP/DM
> signals depending on speed is LS or FS/HS to detect resume.
> Similarly QMP USB3 PHY in SS mode should monitor RX
> terminations attach/detach and LFPS events depending on
> SSPHY is active or not.
>> Why not use a notification mechanism instead of adding new APIs in phy-core.
>> This will only bloat phy-core with APIs for a particular platform.
> 
> Do you mean notifier_chains ?
> When we have multiple instances of USB PHYs then notifier chains are not
> of much help. For any platform glue or PHY driver it will be very difficult to
> figure out if notification received for speed was for same phy/bus or a
> different one.
> Using PHY callbacks looked more elegant to me. Additionally PHY drivers
> can also use this info decide power management policy e.g. if speed is
> INVALID then it means PHY is not in a session and it can enter deepest
> low power state.
> Additionally if you prefer set_speed name over notify_speed then I am
> ok with that as well so that it sounds more generic.

I'd prefer adding modes in enum phy_mode according to speed and using 
phy_set_mode.

Thanks
Kishon

Re: [PATCH 03/15] staging: lustre: replace simple cases of LIBCFS_ALLOC with kzalloc.

[kbuild test robot]

Hi NeilBrown,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on staging/staging-testing]
[also build test ERROR on next-20171220]
[cannot apply to v4.15-rc4]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/NeilBrown/staging-lustre-convert-most-LIBCFS-ALLOC-to-k-malloc/20171220-113029
config: x86_64-randconfig-r0-12200451 (attached as .config)
compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c: In function 
'kiblnd_dev_failover':
>> drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c:2395:2: error: 'kdev' 
>> undeclared (first use in this function)
 kdev = kzalloc(sizeof(*hdev), GFP_NOFS);
 ^~~~
   drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c:2395:2: note: each 
undeclared identifier is reported only once for each function it appears in

vim +/kdev +2395 drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c

  2329  
  2330  int kiblnd_dev_failover(struct kib_dev *dev)
  2331  {
  2332  LIST_HEAD(zombie_tpo);
  2333  LIST_HEAD(zombie_ppo);
  2334  LIST_HEAD(zombie_fpo);
  2335  struct rdma_cm_id *cmid  = NULL;
  2336  struct kib_hca_dev *hdev  = NULL;
  2337  struct ib_pd *pd;
  2338  struct kib_net *net;
  2339  struct sockaddr_in addr;
  2340  unsigned long flags;
  2341  int rc = 0;
  2342  int i;
  2343  
  2344  LASSERT(*kiblnd_tunables.kib_dev_failover > 1 ||
  2345  dev->ibd_can_failover || !dev->ibd_hdev);
  2346  
  2347  rc = kiblnd_dev_need_failover(dev);
  2348  if (rc <= 0)
  2349  goto out;
  2350  
  2351  if (dev->ibd_hdev &&
  2352  dev->ibd_hdev->ibh_cmid) {
  2353  /*
  2354   * XXX it's not good to close old listener at here,
  2355   * because we can fail to create new listener.
  2356   * But we have to close it now, otherwise rdma_bind_addr
  2357   * will return EADDRINUSE... How crap!
  2358   */
  2359  write_lock_irqsave(_data.kib_global_lock, flags);
  2360  
  2361  cmid = dev->ibd_hdev->ibh_cmid;
  2362  /*
  2363   * make next schedule of kiblnd_dev_need_failover()
  2364   * return 1 for me
  2365   */
  2366  dev->ibd_hdev->ibh_cmid  = NULL;
  2367  write_unlock_irqrestore(_data.kib_global_lock, 
flags);
  2368  
  2369  rdma_destroy_id(cmid);
  2370  }
  2371  
  2372  cmid = kiblnd_rdma_create_id(kiblnd_cm_callback, dev, 
RDMA_PS_TCP,
  2373   IB_QPT_RC);
  2374  if (IS_ERR(cmid)) {
  2375  rc = PTR_ERR(cmid);
  2376  CERROR("Failed to create cmid for failover: %d\n", rc);
  2377  goto out;
  2378  }
  2379  
  2380  memset(, 0, sizeof(addr));
  2381  addr.sin_family  = AF_INET;
  2382  addr.sin_addr.s_addr = htonl(dev->ibd_ifip);
  2383  addr.sin_port   = htons(*kiblnd_tunables.kib_service);
  2384  
  2385  /* Bind to failover device or port */
  2386  rc = rdma_bind_addr(cmid, (struct sockaddr *));
  2387  if (rc || !cmid->device) {
  2388  CERROR("Failed to bind %s:%pI4h to device(%p): %d\n",
  2389 dev->ibd_ifname, >ibd_ifip,
  2390 cmid->device, rc);
  2391  rdma_destroy_id(cmid);
  2392  goto out;
  2393  }
  2394  
> 2395  kdev = kzalloc(sizeof(*hdev), GFP_NOFS);
  2396  if (!hdev) {
  2397  CERROR("Failed to allocate kib_hca_dev\n");
  2398  rdma_destroy_id(cmid);
  2399  rc = -ENOMEM;
  2400  goto out;
  2401  }
  2402  
  2403  atomic_set(>ibh_ref, 1);
  2404  hdev->ibh_dev   = dev;
  2405  hdev->ibh_cmid  = cmid;
  2406  hdev->ibh_ibdev = cmid->device;
  2407  
  2408  pd = ib_alloc_pd(cmid->device, 0);
  2409  if (IS_ERR(pd)) {
  2410  rc = PTR_ERR(pd);
  2411  CERROR("Can't allocate PD: %d\n", rc);
  2412  goto out;
  2413  }
  2414  
  2415  hdev->ibh_pd = pd;
  2416  
  2417  rc = rdma_listen(cmid, 0);
  2418  if (rc) {
  2419  CERROR("Can't start new listener: %d\n", rc);
  2420  goto out;
  2421  }
  2422  
  2423  rc = kiblnd_hdev_get_attr(hdev);
  2424  if (rc) {
  2425  

Re: [PATCH 03/15] staging: lustre: replace simple cases of LIBCFS_ALLOC with kzalloc.

[kbuild test robot]

Hi NeilBrown,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on staging/staging-testing]
[also build test ERROR on next-20171220]
[cannot apply to v4.15-rc4]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/NeilBrown/staging-lustre-convert-most-LIBCFS-ALLOC-to-k-malloc/20171220-113029
config: x86_64-randconfig-r0-12200451 (attached as .config)
compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c: In function 
'kiblnd_dev_failover':
>> drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c:2395:2: error: 'kdev' 
>> undeclared (first use in this function)
 kdev = kzalloc(sizeof(*hdev), GFP_NOFS);
 ^~~~
   drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c:2395:2: note: each 
undeclared identifier is reported only once for each function it appears in

vim +/kdev +2395 drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c

  2329  
  2330  int kiblnd_dev_failover(struct kib_dev *dev)
  2331  {
  2332  LIST_HEAD(zombie_tpo);
  2333  LIST_HEAD(zombie_ppo);
  2334  LIST_HEAD(zombie_fpo);
  2335  struct rdma_cm_id *cmid  = NULL;
  2336  struct kib_hca_dev *hdev  = NULL;
  2337  struct ib_pd *pd;
  2338  struct kib_net *net;
  2339  struct sockaddr_in addr;
  2340  unsigned long flags;
  2341  int rc = 0;
  2342  int i;
  2343  
  2344  LASSERT(*kiblnd_tunables.kib_dev_failover > 1 ||
  2345  dev->ibd_can_failover || !dev->ibd_hdev);
  2346  
  2347  rc = kiblnd_dev_need_failover(dev);
  2348  if (rc <= 0)
  2349  goto out;
  2350  
  2351  if (dev->ibd_hdev &&
  2352  dev->ibd_hdev->ibh_cmid) {
  2353  /*
  2354   * XXX it's not good to close old listener at here,
  2355   * because we can fail to create new listener.
  2356   * But we have to close it now, otherwise rdma_bind_addr
  2357   * will return EADDRINUSE... How crap!
  2358   */
  2359  write_lock_irqsave(_data.kib_global_lock, flags);
  2360  
  2361  cmid = dev->ibd_hdev->ibh_cmid;
  2362  /*
  2363   * make next schedule of kiblnd_dev_need_failover()
  2364   * return 1 for me
  2365   */
  2366  dev->ibd_hdev->ibh_cmid  = NULL;
  2367  write_unlock_irqrestore(_data.kib_global_lock, 
flags);
  2368  
  2369  rdma_destroy_id(cmid);
  2370  }
  2371  
  2372  cmid = kiblnd_rdma_create_id(kiblnd_cm_callback, dev, 
RDMA_PS_TCP,
  2373   IB_QPT_RC);
  2374  if (IS_ERR(cmid)) {
  2375  rc = PTR_ERR(cmid);
  2376  CERROR("Failed to create cmid for failover: %d\n", rc);
  2377  goto out;
  2378  }
  2379  
  2380  memset(, 0, sizeof(addr));
  2381  addr.sin_family  = AF_INET;
  2382  addr.sin_addr.s_addr = htonl(dev->ibd_ifip);
  2383  addr.sin_port   = htons(*kiblnd_tunables.kib_service);
  2384  
  2385  /* Bind to failover device or port */
  2386  rc = rdma_bind_addr(cmid, (struct sockaddr *));
  2387  if (rc || !cmid->device) {
  2388  CERROR("Failed to bind %s:%pI4h to device(%p): %d\n",
  2389 dev->ibd_ifname, >ibd_ifip,
  2390 cmid->device, rc);
  2391  rdma_destroy_id(cmid);
  2392  goto out;
  2393  }
  2394  
> 2395  kdev = kzalloc(sizeof(*hdev), GFP_NOFS);
  2396  if (!hdev) {
  2397  CERROR("Failed to allocate kib_hca_dev\n");
  2398  rdma_destroy_id(cmid);
  2399  rc = -ENOMEM;
  2400  goto out;
  2401  }
  2402  
  2403  atomic_set(>ibh_ref, 1);
  2404  hdev->ibh_dev   = dev;
  2405  hdev->ibh_cmid  = cmid;
  2406  hdev->ibh_ibdev = cmid->device;
  2407  
  2408  pd = ib_alloc_pd(cmid->device, 0);
  2409  if (IS_ERR(pd)) {
  2410  rc = PTR_ERR(pd);
  2411  CERROR("Can't allocate PD: %d\n", rc);
  2412  goto out;
  2413  }
  2414  
  2415  hdev->ibh_pd = pd;
  2416  
  2417  rc = rdma_listen(cmid, 0);
  2418  if (rc) {
  2419  CERROR("Can't start new listener: %d\n", rc);
  2420  goto out;
  2421  }
  2422  
  2423  rc = kiblnd_hdev_get_attr(hdev);
  2424  if (rc) {
  2425  

Re: [PATCH v10 1/5] add infrastructure for tagging functions as error injectable

[Masami Hiramatsu]

On Tue, 19 Dec 2017 18:14:17 -0800
Alexei Starovoitov  wrote:

> On 12/18/17 10:29 PM, Masami Hiramatsu wrote:
> >>
> >> +#if defined(__KERNEL__) && !defined(__ASSEMBLY__)
> >> +#ifdef CONFIG_BPF_KPROBE_OVERRIDE
> >
> > BTW, CONFIG_BPF_KPROBE_OVERRIDE is also confusable name.
> > Since this feature override a function to just return with
> > some return value (as far as I understand, or would you
> > also plan to modify execution path inside a function?),
> > I think it should be better CONFIG_BPF_FUNCTION_OVERRIDE or
> > CONFIG_BPF_EXECUTION_OVERRIDE.
> 
> I don't think such renaming makes sense.
> The feature is overriding kprobe by changing how kprobe returns.
> It doesn't override BPF_FUNCTION or BPF_EXECUTION.

No, I meant this is BPF's feature which override FUNCTION, so
BPF is a kind of namespace. (Is that only for a function entry
because it can not tweak stackframe at this morment?)

> The kernel enters and exists bpf program as normal.

Yeah, but that bpf program modifies instruction pointer, am I correct?

> 
> > Indeed, BPF is based on kprobes, but it seems you are limiting it
> > with ftrace (function-call trace) (I'm not sure the reason why),
> > so using "kprobes" for this feature seems strange for me.
> 
> do you have an idea how kprobe override can happen when kprobe
> placed in the middle of the function?

For example, if you know a basic block in the function, maybe
you can skip a block or something like that. But nowadays
it is somewhat hard because optimizer mixed it up.

> 
> Please make your suggestion as patches based on top of bpf-next.

bpf-next seems already pick this series. Would you mean I revert it and
write new patch?

Thank you,

> 
> Thanks
> 


-- 
Masami Hiramatsu 

Re: [PATCH v10 1/5] add infrastructure for tagging functions as error injectable

[Masami Hiramatsu]

On Tue, 19 Dec 2017 18:14:17 -0800
Alexei Starovoitov  wrote:

> On 12/18/17 10:29 PM, Masami Hiramatsu wrote:
> >>
> >> +#if defined(__KERNEL__) && !defined(__ASSEMBLY__)
> >> +#ifdef CONFIG_BPF_KPROBE_OVERRIDE
> >
> > BTW, CONFIG_BPF_KPROBE_OVERRIDE is also confusable name.
> > Since this feature override a function to just return with
> > some return value (as far as I understand, or would you
> > also plan to modify execution path inside a function?),
> > I think it should be better CONFIG_BPF_FUNCTION_OVERRIDE or
> > CONFIG_BPF_EXECUTION_OVERRIDE.
> 
> I don't think such renaming makes sense.
> The feature is overriding kprobe by changing how kprobe returns.
> It doesn't override BPF_FUNCTION or BPF_EXECUTION.

No, I meant this is BPF's feature which override FUNCTION, so
BPF is a kind of namespace. (Is that only for a function entry
because it can not tweak stackframe at this morment?)

> The kernel enters and exists bpf program as normal.

Yeah, but that bpf program modifies instruction pointer, am I correct?

> 
> > Indeed, BPF is based on kprobes, but it seems you are limiting it
> > with ftrace (function-call trace) (I'm not sure the reason why),
> > so using "kprobes" for this feature seems strange for me.
> 
> do you have an idea how kprobe override can happen when kprobe
> placed in the middle of the function?

For example, if you know a basic block in the function, maybe
you can skip a block or something like that. But nowadays
it is somewhat hard because optimizer mixed it up.

> 
> Please make your suggestion as patches based on top of bpf-next.

bpf-next seems already pick this series. Would you mean I revert it and
write new patch?

Thank you,

> 
> Thanks
> 


-- 
Masami Hiramatsu 

Re: [RFC][PATCHv6 00/12] printk: introduce printing kernel thread

[Sergey Senozhatsky]

Hello,

not sure if you've been following the whole thread, so I'll try
to summarize it here. apologies if it'll massively repeat the things
that have already been said or will be too long.

On (12/19/17 15:31), Michal Hocko wrote:
> On Tue 19-12-17 10:24:55, Sergey Senozhatsky wrote:
> > On (12/18/17 20:08), Steven Rostedt wrote:
> > > > ... do you guys read my emails? which part of the traces I have provided
> > > > suggests that there is any improvement?
> > > 
> > > The traces I've seen from you were from non-realistic scenarios.
> > > But I have hit issues with printk()s happening that cause one CPU to do 
> > > all
> > > the work, where my patch would fix that. Those are the scenarios I'm
> > > talking about.
> > 
> > any hints about what makes your scenario more realistic than mine?
> 
> Well, Tetsuo had some semi-realistic scenario where alloc stall messages
> managed to stall other printk callers (namely oom handler). I am saying
> sem-realistic because he is testing OOM throughput with an unrealistic
> workload which itself is not very real on production systems. The
> essential thing here is that many processes might be in the allocation
> path and any printk there could just swamp some unrelated printk caller
> and cause hard to debug problems. Steven's patch should address that
> with a relatively simple lock handover. I was pessimistic this would
> work sufficiently well but it survived Tetsuo's testing IIRC so it
> sounds good enough to me.

sure, no denial. Tetsuo indeed said that Steven's patch passed his
test. and for the note, the most recent printk_kthread patch set passed
Tetsuo's test as well; I asked him privately to run the tests before I
published it. but this is not the point. and to make it clear - this is
not a "Steven's patch" vs. "my patch set + Steven's patch atop of it"
type of thing. not at all.


IMPORTANT DISCLAIMER
   I SPEAK FOR MYSELF ONLY. ABOUT MY OBSERVATION ONLY. THIS IS AN
   ATTEMPT TO ANALYSE WHY THE PATCH DIDN'T WORK ON MY SETUP AND WHY
   MY SETUP NEEDS ANOTHER APPROACH. THIS IS NOT TO WARN ANYONE THAT
   THE PATCH WON'T WORK ON THEIR SETUPS. I MEAN NO OFFENSE AND AM
   NOT TRYING TO LOOK/SOUND SMART. AND, LIKE I SAID, IF STEVEN OR
   PETR WANT TO PUSH THE PATCH, I'M NOT GOING TO BLOCK IT.

so why Steven's patch has not succeeded on my boards?... partly because
of the fact that printk is "multidimensional" in its complexity and
Steven's patch just doesn't touch some of those problematic parts; partly
because the patch has the requirements which can't be 100% true on my
boards.

to begin with,
so the patch works only when the console_sem is contended. IOW, when
multiple sites perform printk-s concurrently frequent enough for the
hand off logic to detect it and to pass the control to another CPU.
but this turned out to be a bit hard to count on. why? several problems.

(1) the really big one:
   console_sem owner can be preempted under console_sem, removing any
   console_sem competition, it's already locked - its owner is preempted.
   this removes any possibility of hand off. and this unleashes CPUs that
   do printk-s, because when console_sem is locked, printk-s from other
   CPUs become, basically, as fast as sprintf+memcpy.

(1.1) the really big one, part two. more on this later. see @PART2

(2) another big one:
   printk() fast path - sprintf+memcpy - can be significantly faster than
   call to console drivers. on my board I see that printk CPU can add 1140
   new messages to the logbuf, while active console_sem owner prints a
   single message to the serial console. not to mention console_sem owner
   preemption.

(1) and (2) combined can do magical things. on my extremely trivial
test -- not insanely huge number of printks (much less than 2000 lines)
from a preemptible context, not so much printk-s from other CPUs - I
can see, and I confirmed that with the traces, that when console_sem is
getting handed over to another CPU and that new console_sem owner is
getting preempted or when it begins to print messages to serial console,
the CPU that actually does most of printk-s finishes its job in almost no
time, because all it has to do is sprintf+memcpy. which basically means
that console_sem is not contended anymore, and thus its either current
console_sem owner or _maybe_ some other task that has to print all of
the pending messages.

and to make it worse, the hand off logic does not distinguish between
contexts it's passing the console_sem ownership to. it will be equally
happy to hand off console_sem to atomic context from a non atomic one,
or from atomic to another atomic (and vice versa), regardless the number
of pending messages in the logbuf. more on this later [see @LATER].

now, Steven and Petr said that my test was non realistic and thus the
observations were invalid. OK, let's take a closer look on OOM. and
let's start with the question - what is so special about OOM that
makes (1) or (1.1) or (2) invalid?
i
can we get preempted when we call 

Re: [RFC][PATCHv6 00/12] printk: introduce printing kernel thread

[Sergey Senozhatsky]

Hello,

not sure if you've been following the whole thread, so I'll try
to summarize it here. apologies if it'll massively repeat the things
that have already been said or will be too long.

On (12/19/17 15:31), Michal Hocko wrote:
> On Tue 19-12-17 10:24:55, Sergey Senozhatsky wrote:
> > On (12/18/17 20:08), Steven Rostedt wrote:
> > > > ... do you guys read my emails? which part of the traces I have provided
> > > > suggests that there is any improvement?
> > > 
> > > The traces I've seen from you were from non-realistic scenarios.
> > > But I have hit issues with printk()s happening that cause one CPU to do 
> > > all
> > > the work, where my patch would fix that. Those are the scenarios I'm
> > > talking about.
> > 
> > any hints about what makes your scenario more realistic than mine?
> 
> Well, Tetsuo had some semi-realistic scenario where alloc stall messages
> managed to stall other printk callers (namely oom handler). I am saying
> sem-realistic because he is testing OOM throughput with an unrealistic
> workload which itself is not very real on production systems. The
> essential thing here is that many processes might be in the allocation
> path and any printk there could just swamp some unrelated printk caller
> and cause hard to debug problems. Steven's patch should address that
> with a relatively simple lock handover. I was pessimistic this would
> work sufficiently well but it survived Tetsuo's testing IIRC so it
> sounds good enough to me.

sure, no denial. Tetsuo indeed said that Steven's patch passed his
test. and for the note, the most recent printk_kthread patch set passed
Tetsuo's test as well; I asked him privately to run the tests before I
published it. but this is not the point. and to make it clear - this is
not a "Steven's patch" vs. "my patch set + Steven's patch atop of it"
type of thing. not at all.


IMPORTANT DISCLAIMER
   I SPEAK FOR MYSELF ONLY. ABOUT MY OBSERVATION ONLY. THIS IS AN
   ATTEMPT TO ANALYSE WHY THE PATCH DIDN'T WORK ON MY SETUP AND WHY
   MY SETUP NEEDS ANOTHER APPROACH. THIS IS NOT TO WARN ANYONE THAT
   THE PATCH WON'T WORK ON THEIR SETUPS. I MEAN NO OFFENSE AND AM
   NOT TRYING TO LOOK/SOUND SMART. AND, LIKE I SAID, IF STEVEN OR
   PETR WANT TO PUSH THE PATCH, I'M NOT GOING TO BLOCK IT.

so why Steven's patch has not succeeded on my boards?... partly because
of the fact that printk is "multidimensional" in its complexity and
Steven's patch just doesn't touch some of those problematic parts; partly
because the patch has the requirements which can't be 100% true on my
boards.

to begin with,
so the patch works only when the console_sem is contended. IOW, when
multiple sites perform printk-s concurrently frequent enough for the
hand off logic to detect it and to pass the control to another CPU.
but this turned out to be a bit hard to count on. why? several problems.

(1) the really big one:
   console_sem owner can be preempted under console_sem, removing any
   console_sem competition, it's already locked - its owner is preempted.
   this removes any possibility of hand off. and this unleashes CPUs that
   do printk-s, because when console_sem is locked, printk-s from other
   CPUs become, basically, as fast as sprintf+memcpy.

(1.1) the really big one, part two. more on this later. see @PART2

(2) another big one:
   printk() fast path - sprintf+memcpy - can be significantly faster than
   call to console drivers. on my board I see that printk CPU can add 1140
   new messages to the logbuf, while active console_sem owner prints a
   single message to the serial console. not to mention console_sem owner
   preemption.

(1) and (2) combined can do magical things. on my extremely trivial
test -- not insanely huge number of printks (much less than 2000 lines)
from a preemptible context, not so much printk-s from other CPUs - I
can see, and I confirmed that with the traces, that when console_sem is
getting handed over to another CPU and that new console_sem owner is
getting preempted or when it begins to print messages to serial console,
the CPU that actually does most of printk-s finishes its job in almost no
time, because all it has to do is sprintf+memcpy. which basically means
that console_sem is not contended anymore, and thus its either current
console_sem owner or _maybe_ some other task that has to print all of
the pending messages.

and to make it worse, the hand off logic does not distinguish between
contexts it's passing the console_sem ownership to. it will be equally
happy to hand off console_sem to atomic context from a non atomic one,
or from atomic to another atomic (and vice versa), regardless the number
of pending messages in the logbuf. more on this later [see @LATER].

now, Steven and Petr said that my test was non realistic and thus the
observations were invalid. OK, let's take a closer look on OOM. and
let's start with the question - what is so special about OOM that
makes (1) or (1.1) or (2) invalid?
i
can we get preempted when we call 

[PATCH] gitignore: add *.gcda files

[Jaejoong Kim]

Ignore the *.gcda files generated by gcov

Signed-off-by: Jaejoong Kim 
---
 .gitignore | 1 +
 1 file changed, 1 insertion(+)

diff --git a/.gitignore b/.gitignore
index 0c39aa2..580ef7c 100644
--- a/.gitignore
+++ b/.gitignore
@@ -39,6 +39,7 @@ Module.symvers
 *.dwo
 *.su
 *.c.[012]*.*
+*.gcda
 
 #
 # Top-level generic files
-- 
2.7.4

[PATCH] gitignore: add *.gcda files

[Jaejoong Kim]

Ignore the *.gcda files generated by gcov

Signed-off-by: Jaejoong Kim 
---
 .gitignore | 1 +
 1 file changed, 1 insertion(+)

diff --git a/.gitignore b/.gitignore
index 0c39aa2..580ef7c 100644
--- a/.gitignore
+++ b/.gitignore
@@ -39,6 +39,7 @@ Module.symvers
 *.dwo
 *.su
 *.c.[012]*.*
+*.gcda
 
 #
 # Top-level generic files
-- 
2.7.4

Re: [PATCH] kfree_rcu() should use the new kfree_bulk() interface for freeing rcu structures

[Jesper Dangaard Brouer]

On Tue, 19 Dec 2017 16:20:51 -0800
"Paul E. McKenney"  wrote:

> On Tue, Dec 19, 2017 at 02:12:06PM -0800, Matthew Wilcox wrote:
> > On Tue, Dec 19, 2017 at 09:41:58PM +0100, Jesper Dangaard Brouer wrote:  
> > > If I had to implement this: I would choose to do the optimization in
> > > __rcu_process_callbacks() create small on-call-stack ptr-array for
> > > kfree_bulk().  I would only optimize the case that call kfree()
> > > directly.  In the while(list) loop I would defer calling
> > > __rcu_reclaim() for __is_kfree_rcu_offset(head->func), and instead add
> > > them to the ptr-array (and flush if the array is full in loop, and
> > > kfree_bulk flush after loop).
> > > 
> > > The real advantage of kfree_bulk() comes from amortizing the per kfree
> > > (behind-the-scenes) sync cost.  There is an additional benefit, because
> > > objects comes from RCU and will hit a slower path in SLUB.   The SLUB
> > > allocator is very fast for objects that gets recycled quickly (short
> > > lifetime), non-locked (cpu-local) double-cmpxchg.  But slower for
> > > longer-lived/more-outstanding objects, as this hits a slower code-path,
> > > fully locked (cross-cpu) double-cmpxchg.
> > 
> > Something like this ...  (compile tested only)

Yes, exactly.

> > Considerably less code; Rao, what do you think?  
> 
> I am sorry, but I am not at all fan of this approach.
> 
> If we are going to make this sort of change, we should do so in a way
> that allows the slab code to actually do the optimizations that might
> make this sort of thing worthwhile.  After all, if the main goal was small
> code size, the best approach is to drop kfree_bulk() and get on with life
> in the usual fashion.
> 
> I would prefer to believe that something like kfree_bulk() can help,
> and if that is the case, we should give it a chance to do things like
> group kfree_rcu() requests by destination slab and soforth, allowing
> batching optimizations that might provide more significant increases
> in performance.  Furthermore, having this in slab opens the door to
> slab taking emergency action when memory is low.

I agree with your argument. Although in the (slub) code I do handle
different destination slab's, but only do a limited look-ahead to find
same dest-slab's which gives the speedup (see build_detached_freelist).

We do have a larger and more consistent speedup potential, if adding
infrastructure that allow us to pre-sort by destination slab, before
invoking kfree_bulk().  In that respect, Rao's patch is a better
approach.

> But for the patch below, NAK.
> 
>   Thanx, Paul
> 
> > diff --git a/kernel/rcu/rcu.h b/kernel/rcu/rcu.h
> > index 59c471de342a..5ac4ed077233 100644
> > --- a/kernel/rcu/rcu.h
> > +++ b/kernel/rcu/rcu.h
> > @@ -174,20 +174,19 @@ static inline void debug_rcu_head_unqueue(struct 
> > rcu_head *head)
> >  }
> >  #endif /* #else !CONFIG_DEBUG_OBJECTS_RCU_HEAD */
> > 
> > -void kfree(const void *);
> > -
> >  /*
> >   * Reclaim the specified callback, either by invoking it (non-lazy case)
> >   * or freeing it directly (lazy case).  Return true if lazy, false 
> > otherwise.
> >   */
> > -static inline bool __rcu_reclaim(const char *rn, struct rcu_head *head)
> > +static inline bool __rcu_reclaim(const char *rn, struct rcu_head *head, 
> > void **kfree,
> > +   unsigned int *idx)
> >  {
> > unsigned long offset = (unsigned long)head->func;
> > 
> > rcu_lock_acquire(_callback_map);
> > if (__is_kfree_rcu_offset(offset)) {
> > RCU_TRACE(trace_rcu_invoke_kfree_callback(rn, head, offset);)
> > -   kfree((void *)head - offset);
> > +   kfree[*idx++] = (void *)head - offset;
> > rcu_lock_release(_callback_map);
> > return true;
> > } else {
> > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> > index f9c0ca2ccf0c..7e13979b4697 100644
> > --- a/kernel/rcu/tree.c
> > +++ b/kernel/rcu/tree.c
> > @@ -2725,6 +2725,8 @@ static void rcu_do_batch(struct rcu_state *rsp, 
> > struct rcu_data *rdp)
> > struct rcu_head *rhp;
> > struct rcu_cblist rcl = RCU_CBLIST_INITIALIZER(rcl);
> > long bl, count;
> > +   void *to_free[16];
> > +   unsigned int to_free_idx = 0;
> > 
> > /* If no callbacks are ready, just return. */
> > if (!rcu_segcblist_ready_cbs(>cblist)) {
> > @@ -2755,8 +2757,10 @@ static void rcu_do_batch(struct rcu_state *rsp, 
> > struct rcu_data *rdp)
> > rhp = rcu_cblist_dequeue();
> > for (; rhp; rhp = rcu_cblist_dequeue()) {
> > debug_rcu_head_unqueue(rhp);
> > -   if (__rcu_reclaim(rsp->name, rhp))
> > +   if (__rcu_reclaim(rsp->name, rhp, to_free, _free_idx))
> > rcu_cblist_dequeued_lazy();
> > +   if (to_free_idx == 16)
> > +   kfree_bulk(16, to_free);
> > /*
> >  * Stop only if limit reached and CPU has something to do.
> >

Re: [PATCH] kfree_rcu() should use the new kfree_bulk() interface for freeing rcu structures

[Jesper Dangaard Brouer]

On Tue, 19 Dec 2017 16:20:51 -0800
"Paul E. McKenney"  wrote:

> On Tue, Dec 19, 2017 at 02:12:06PM -0800, Matthew Wilcox wrote:
> > On Tue, Dec 19, 2017 at 09:41:58PM +0100, Jesper Dangaard Brouer wrote:  
> > > If I had to implement this: I would choose to do the optimization in
> > > __rcu_process_callbacks() create small on-call-stack ptr-array for
> > > kfree_bulk().  I would only optimize the case that call kfree()
> > > directly.  In the while(list) loop I would defer calling
> > > __rcu_reclaim() for __is_kfree_rcu_offset(head->func), and instead add
> > > them to the ptr-array (and flush if the array is full in loop, and
> > > kfree_bulk flush after loop).
> > > 
> > > The real advantage of kfree_bulk() comes from amortizing the per kfree
> > > (behind-the-scenes) sync cost.  There is an additional benefit, because
> > > objects comes from RCU and will hit a slower path in SLUB.   The SLUB
> > > allocator is very fast for objects that gets recycled quickly (short
> > > lifetime), non-locked (cpu-local) double-cmpxchg.  But slower for
> > > longer-lived/more-outstanding objects, as this hits a slower code-path,
> > > fully locked (cross-cpu) double-cmpxchg.
> > 
> > Something like this ...  (compile tested only)

Yes, exactly.

> > Considerably less code; Rao, what do you think?  
> 
> I am sorry, but I am not at all fan of this approach.
> 
> If we are going to make this sort of change, we should do so in a way
> that allows the slab code to actually do the optimizations that might
> make this sort of thing worthwhile.  After all, if the main goal was small
> code size, the best approach is to drop kfree_bulk() and get on with life
> in the usual fashion.
> 
> I would prefer to believe that something like kfree_bulk() can help,
> and if that is the case, we should give it a chance to do things like
> group kfree_rcu() requests by destination slab and soforth, allowing
> batching optimizations that might provide more significant increases
> in performance.  Furthermore, having this in slab opens the door to
> slab taking emergency action when memory is low.

I agree with your argument. Although in the (slub) code I do handle
different destination slab's, but only do a limited look-ahead to find
same dest-slab's which gives the speedup (see build_detached_freelist).

We do have a larger and more consistent speedup potential, if adding
infrastructure that allow us to pre-sort by destination slab, before
invoking kfree_bulk().  In that respect, Rao's patch is a better
approach.

> But for the patch below, NAK.
> 
>   Thanx, Paul
> 
> > diff --git a/kernel/rcu/rcu.h b/kernel/rcu/rcu.h
> > index 59c471de342a..5ac4ed077233 100644
> > --- a/kernel/rcu/rcu.h
> > +++ b/kernel/rcu/rcu.h
> > @@ -174,20 +174,19 @@ static inline void debug_rcu_head_unqueue(struct 
> > rcu_head *head)
> >  }
> >  #endif /* #else !CONFIG_DEBUG_OBJECTS_RCU_HEAD */
> > 
> > -void kfree(const void *);
> > -
> >  /*
> >   * Reclaim the specified callback, either by invoking it (non-lazy case)
> >   * or freeing it directly (lazy case).  Return true if lazy, false 
> > otherwise.
> >   */
> > -static inline bool __rcu_reclaim(const char *rn, struct rcu_head *head)
> > +static inline bool __rcu_reclaim(const char *rn, struct rcu_head *head, 
> > void **kfree,
> > +   unsigned int *idx)
> >  {
> > unsigned long offset = (unsigned long)head->func;
> > 
> > rcu_lock_acquire(_callback_map);
> > if (__is_kfree_rcu_offset(offset)) {
> > RCU_TRACE(trace_rcu_invoke_kfree_callback(rn, head, offset);)
> > -   kfree((void *)head - offset);
> > +   kfree[*idx++] = (void *)head - offset;
> > rcu_lock_release(_callback_map);
> > return true;
> > } else {
> > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> > index f9c0ca2ccf0c..7e13979b4697 100644
> > --- a/kernel/rcu/tree.c
> > +++ b/kernel/rcu/tree.c
> > @@ -2725,6 +2725,8 @@ static void rcu_do_batch(struct rcu_state *rsp, 
> > struct rcu_data *rdp)
> > struct rcu_head *rhp;
> > struct rcu_cblist rcl = RCU_CBLIST_INITIALIZER(rcl);
> > long bl, count;
> > +   void *to_free[16];
> > +   unsigned int to_free_idx = 0;
> > 
> > /* If no callbacks are ready, just return. */
> > if (!rcu_segcblist_ready_cbs(>cblist)) {
> > @@ -2755,8 +2757,10 @@ static void rcu_do_batch(struct rcu_state *rsp, 
> > struct rcu_data *rdp)
> > rhp = rcu_cblist_dequeue();
> > for (; rhp; rhp = rcu_cblist_dequeue()) {
> > debug_rcu_head_unqueue(rhp);
> > -   if (__rcu_reclaim(rsp->name, rhp))
> > +   if (__rcu_reclaim(rsp->name, rhp, to_free, _free_idx))
> > rcu_cblist_dequeued_lazy();
> > +   if (to_free_idx == 16)
> > +   kfree_bulk(16, to_free);
> > /*
> >  * Stop only if limit reached and CPU has something to do.
> >  * Note: The rcl 

Re: [PATCH v15 3/5] mfd: Add driver for RAVE Supervisory Processor

[Philippe Ombredanne]

Andrey,

On Wed, Dec 20, 2017 at 5:00 AM, Andrey Smirnov
 wrote:
> Add a driver for RAVE Supervisory Processor, an MCU implementing
> various bits of housekeeping functionality (watchdoging, backlight
> control, LED control, etc) on RAVE family of products by Zodiac
> Inflight Innovations.



> --- /dev/null
> +++ b/drivers/mfd/rave-sp.c
> @@ -0,0 +1,720 @@
> +/*
> + * Multifunction core driver for Zodiac Inflight Innovations
> + * SP MCU that is connected via dedicated UART port
> + *
> + * Copyright (C) 2017 Zodiac Inflight Innovations
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, see .
> + */

Would you mind using the new SPDX tags documented in Thomas patch set
[1] rather than this fine but longer legalese?
Thank you!

[1] https://lkml.org/lkml/2017/12/4/934

-- 
Cordially
Philippe Ombredanne

Re: [PATCH v15 3/5] mfd: Add driver for RAVE Supervisory Processor

[Philippe Ombredanne]

Andrey,

On Wed, Dec 20, 2017 at 5:00 AM, Andrey Smirnov
 wrote:
> Add a driver for RAVE Supervisory Processor, an MCU implementing
> various bits of housekeeping functionality (watchdoging, backlight
> control, LED control, etc) on RAVE family of products by Zodiac
> Inflight Innovations.



> --- /dev/null
> +++ b/drivers/mfd/rave-sp.c
> @@ -0,0 +1,720 @@
> +/*
> + * Multifunction core driver for Zodiac Inflight Innovations
> + * SP MCU that is connected via dedicated UART port
> + *
> + * Copyright (C) 2017 Zodiac Inflight Innovations
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, see .
> + */

Would you mind using the new SPDX tags documented in Thomas patch set
[1] rather than this fine but longer legalese?
Thank you!

[1] https://lkml.org/lkml/2017/12/4/934

-- 
Cordially
Philippe Ombredanne

Re: [ANNOUNCE] autofs 5.1.2 release

[Ian Kent]

On 20/12/17 14:10, Ian Kent wrote:
> On 20/12/17 13:52, Ian Kent wrote:
>> On 20/12/17 11:29, NeilBrown wrote:
>>>
>>> Hi Ian,
>>>  I've been looking at:
>>>
 - add configuration option to use fqdn in mounts.
>>>
>>> (commit 9aeef772604) because using this new option causes a regression.
>>> If you are using the "replicated server" functionality, then
>>>   use_hostname_for_mounts = yes
>>> completely disables it.
>>
>> Yes, that's not quite right.
>>
>> It disables the probe and proximity check for each distinct host
>> name used.
>>
>> Each of the entries in the list of hosts should still be
>> attempted and given that NFS ping is also now used in the NFS
>> mount module what's lost is the preferred ordering of the hosts
>> list.
>>
>>>
>>> This is caused by:
>>>
>>> diff --git a/modules/replicated.c b/modules/replicated.c
>>> index 32860d5fe245..8437f5f3d5b2 100644
>>> --- a/modules/replicated.c
>>> +++ b/modules/replicated.c
>>> @@ -667,6 +667,12 @@ int prune_host_list(unsigned logopt, struct host 
>>> **list,
>>> if (!*list)
>>> return 0;
>>>  
>>> +   /* If we're using the host name then there's no point probing
>>> +* avialability and respose time.
>>> +*/
>>> +   if (defaults_use_hostname_for_mounts())
>>> +   return 1;
>>> +
>>> /* Use closest hosts to choose NFS version */
>>>
>>> My question is: why what this particular change made.
>>
>> It was a while ago but there were complains about using the IP
>> address for mounts. It was requested to provide a way to prevent
>> that and force the use of the host name in mounts.
>>
>>> Why can't prune_host_list() be allowed to do it's thing
>>> when use_hostname_for_mounts is set.
>>
>> We could if each host name resolved to a single IP address.
>>
>> I'd need to check that use_hostname_for_mounts doesn't get
>> in the road but the host struct should have ->rr set to true
>> if it has multiple addresses so changing it to work the way
>> your recommending shouldn't be hard. I think there's a couple
>> of places that would need to be checked.
>>
>> If the host does resolve to multiple addresses the situation
>> is different. There's no way to stop the actual mount from
>> trying an IP address that's not responding and proximity
>> doesn't make sense either again because every time a lookup
>> is done on the host name (eg. at mount time) the next address
>> in its list will be returned which can and usually is different
>> from what would have been checked.
>>
>>> I understand that it would be pointless choosing between
>>> the different interfaces of a multi-homed host, but there is still value
>>> in choosing between multiple distinct hosts.
>>>
>>> What, if anything, might go wrong if I simply reverse this chunk of the
>>> patch?
>>
>> You'll get IP addresses in the logs in certain cases but that
>> should be all.
>>
>> It would probably be better to ensure that the checks are done
>> if the host name resolves to a single IP address.
> 
> I think that should be "if the host names in the list each resolve
> to a single IP address", otherwise the round robin behavior would
> probably still get in the road.

I think maybe this is sufficient 

autofs-5.1.4 - use proximity check if all host names are simple

From: Ian Kent 

Currently if the configuration option use_hostname_for_mounts is
set then the proximity calcualtion is not done for the list of
hosts.

But if each host name in the host list resolves to a single IP
address then performing the proximity check still makes sense.

Signed-off-by: Ian Kent 
---
 modules/replicated.c |   32 ++--
 1 file changed, 26 insertions(+), 6 deletions(-)

diff --git a/modules/replicated.c b/modules/replicated.c
index 3ac4c70f..e5c2276d 100644
--- a/modules/replicated.c
+++ b/modules/replicated.c
@@ -711,6 +711,24 @@ done:
return 0;
 }
 
+static unsigned int is_hosts_list_simple(struct host *list)
+{
+   struct host *this = list;
+   unsigned int ret = 1;
+
+   while (this) {
+   struct host *next = this->next;
+
+   if (this->rr) {
+   ret = 0;
+   break;
+   }
+   this = next;
+   }
+
+   return ret;
+}
+
 int prune_host_list(unsigned logopt, struct host **list,
unsigned int vers, int port)
 {
@@ -726,12 +744,6 @@ int prune_host_list(unsigned logopt, struct host **list,
if (!*list)
return 0;
 
-   /* If we're using the host name then there's no point probing
-* avialability and respose time.
-*/
-   if (defaults_use_hostname_for_mounts())
-   return 1;
-
/* Use closest hosts to choose NFS version */
 
first = *list;
@@ -767,6 +779,14 @@ int prune_host_list(unsigned logopt, struct host **list,
return 1;
}
 
+   /* If we're using the host 

Re: [ANNOUNCE] autofs 5.1.2 release

[Ian Kent]

On 20/12/17 14:10, Ian Kent wrote:
> On 20/12/17 13:52, Ian Kent wrote:
>> On 20/12/17 11:29, NeilBrown wrote:
>>>
>>> Hi Ian,
>>>  I've been looking at:
>>>
 - add configuration option to use fqdn in mounts.
>>>
>>> (commit 9aeef772604) because using this new option causes a regression.
>>> If you are using the "replicated server" functionality, then
>>>   use_hostname_for_mounts = yes
>>> completely disables it.
>>
>> Yes, that's not quite right.
>>
>> It disables the probe and proximity check for each distinct host
>> name used.
>>
>> Each of the entries in the list of hosts should still be
>> attempted and given that NFS ping is also now used in the NFS
>> mount module what's lost is the preferred ordering of the hosts
>> list.
>>
>>>
>>> This is caused by:
>>>
>>> diff --git a/modules/replicated.c b/modules/replicated.c
>>> index 32860d5fe245..8437f5f3d5b2 100644
>>> --- a/modules/replicated.c
>>> +++ b/modules/replicated.c
>>> @@ -667,6 +667,12 @@ int prune_host_list(unsigned logopt, struct host 
>>> **list,
>>> if (!*list)
>>> return 0;
>>>  
>>> +   /* If we're using the host name then there's no point probing
>>> +* avialability and respose time.
>>> +*/
>>> +   if (defaults_use_hostname_for_mounts())
>>> +   return 1;
>>> +
>>> /* Use closest hosts to choose NFS version */
>>>
>>> My question is: why what this particular change made.
>>
>> It was a while ago but there were complains about using the IP
>> address for mounts. It was requested to provide a way to prevent
>> that and force the use of the host name in mounts.
>>
>>> Why can't prune_host_list() be allowed to do it's thing
>>> when use_hostname_for_mounts is set.
>>
>> We could if each host name resolved to a single IP address.
>>
>> I'd need to check that use_hostname_for_mounts doesn't get
>> in the road but the host struct should have ->rr set to true
>> if it has multiple addresses so changing it to work the way
>> your recommending shouldn't be hard. I think there's a couple
>> of places that would need to be checked.
>>
>> If the host does resolve to multiple addresses the situation
>> is different. There's no way to stop the actual mount from
>> trying an IP address that's not responding and proximity
>> doesn't make sense either again because every time a lookup
>> is done on the host name (eg. at mount time) the next address
>> in its list will be returned which can and usually is different
>> from what would have been checked.
>>
>>> I understand that it would be pointless choosing between
>>> the different interfaces of a multi-homed host, but there is still value
>>> in choosing between multiple distinct hosts.
>>>
>>> What, if anything, might go wrong if I simply reverse this chunk of the
>>> patch?
>>
>> You'll get IP addresses in the logs in certain cases but that
>> should be all.
>>
>> It would probably be better to ensure that the checks are done
>> if the host name resolves to a single IP address.
> 
> I think that should be "if the host names in the list each resolve
> to a single IP address", otherwise the round robin behavior would
> probably still get in the road.

I think maybe this is sufficient 

autofs-5.1.4 - use proximity check if all host names are simple

From: Ian Kent 

Currently if the configuration option use_hostname_for_mounts is
set then the proximity calcualtion is not done for the list of
hosts.

But if each host name in the host list resolves to a single IP
address then performing the proximity check still makes sense.

Signed-off-by: Ian Kent 
---
 modules/replicated.c |   32 ++--
 1 file changed, 26 insertions(+), 6 deletions(-)

diff --git a/modules/replicated.c b/modules/replicated.c
index 3ac4c70f..e5c2276d 100644
--- a/modules/replicated.c
+++ b/modules/replicated.c
@@ -711,6 +711,24 @@ done:
return 0;
 }
 
+static unsigned int is_hosts_list_simple(struct host *list)
+{
+   struct host *this = list;
+   unsigned int ret = 1;
+
+   while (this) {
+   struct host *next = this->next;
+
+   if (this->rr) {
+   ret = 0;
+   break;
+   }
+   this = next;
+   }
+
+   return ret;
+}
+
 int prune_host_list(unsigned logopt, struct host **list,
unsigned int vers, int port)
 {
@@ -726,12 +744,6 @@ int prune_host_list(unsigned logopt, struct host **list,
if (!*list)
return 0;
 
-   /* If we're using the host name then there's no point probing
-* avialability and respose time.
-*/
-   if (defaults_use_hostname_for_mounts())
-   return 1;
-
/* Use closest hosts to choose NFS version */
 
first = *list;
@@ -767,6 +779,14 @@ int prune_host_list(unsigned logopt, struct host **list,
return 1;
}
 
+   /* If we're using the host name then there's no point probing
+ 

Re: [PATCH v2] cpufreq: powernv: Add support of frequency domain

[Viresh Kumar]

On 20-12-17, 12:12, Abhishek Goel wrote:
> diff --git a/drivers/cpufreq/powernv-cpufreq.c 
> b/drivers/cpufreq/powernv-cpufreq.c
> index b6d7c4c..fd642bc 100644
> --- a/drivers/cpufreq/powernv-cpufreq.c
> +++ b/drivers/cpufreq/powernv-cpufreq.c
> @@ -37,6 +37,7 @@
>  #include  /* Required for cpu_sibling_mask() in UP configs */
>  #include 
>  #include 
> +#include 
>  
>  #define POWERNV_MAX_PSTATES  256
>  #define PMSR_PSAFE_ENABLE(1UL << 30)
> @@ -130,6 +131,9 @@ static struct chip {
>  static int nr_chips;
>  static DEFINE_PER_CPU(struct chip *, chip_info);
>  
> +static u32 freq_domain_indicator;
> +static u32 flag;

I wouldn't name it as flag, its unreadable. Maybe its better to name
it based on the quirk you are trying to workaround with ?

> +
>  /*
>   * Note:
>   * The set of pstates consists of contiguous integers.
> @@ -194,6 +198,38 @@ static inline void reset_gpstates(struct cpufreq_policy 
> *policy)
>   gpstates->last_gpstate_idx = 0;
>  }
>  
> +#define SIZE NR_CPUS
> +#define ORDER_FREQ_MAP ilog2(SIZE)
> +
> +static DEFINE_HASHTABLE(freq_domain_map, ORDER_FREQ_MAP);
> +
> +struct hashmap {
> + cpumask_t mask;
> + int chip_id;
> + u32 pir_key;
> + struct hlist_node hash_node;
> +};
> +
> +static void insert(u32 key, int cpu)
> +{
> + struct hashmap *data;
> +
> + hash_for_each_possible(freq_domain_map, data, hash_node, key%SIZE) {
> + if (data->chip_id == cpu_to_chip_id(cpu) &&
> + data->pir_key == key) {
> + cpumask_set_cpu(cpu, >mask);
> + return;
> + }
> + }
> +
> + data = kzalloc(sizeof(*data), GFP_KERNEL);
> + hash_add(freq_domain_map, >hash_node, key%SIZE);
> + cpumask_set_cpu(cpu, >mask);
> + data->chip_id = cpu_to_chip_id(cpu);
> + data->pir_key = key;
> +
> +}
> +
>  /*
>   * Initialize the freq table based on data obtained
>   * from the firmware passed via device-tree
> @@ -206,7 +242,9 @@ static int init_powernv_pstates(void)
>   u32 len_ids, len_freqs;
>   u32 pstate_min, pstate_max, pstate_nominal;
>   u32 pstate_turbo, pstate_ultra_turbo;
> + u32 key;
>  
> + flag = 0;

Isn't flag already 0 (global-uninitialized) ?

>   power_mgt = of_find_node_by_path("/ibm,opal/power-mgt");
>   if (!power_mgt) {
>   pr_warn("power-mgt node not found\n");
> @@ -229,6 +267,17 @@ static int init_powernv_pstates(void)
>   return -ENODEV;
>   }
>  
> + if (of_device_is_compatible(power_mgt, "freq-domain-v1") &&
> + of_property_read_u32(power_mgt, "ibm,freq-domain-indicator",
> +  _domain_indicator)) {
> + pr_warn("ibm,freq-domain-indicator not found\n");
> + freq_domain_indicator = 0;

You shouldn't be required to set it to 0 here.

> + }
> +
> + if (of_device_is_compatible(power_mgt, "P9-occ-quirk")) {
> + flag = 1;
> + }

Remove {} and a better name like p9_occ_quirk would be good for flag.
Also making it a bool may be better ?

> +
>   if (of_property_read_u32(power_mgt, "ibm,pstate-ultra-turbo",
>_ultra_turbo)) {
>   powernv_pstate_info.wof_enabled = false;
> @@ -249,6 +298,7 @@ static int init_powernv_pstates(void)
>  next:
>   pr_info("cpufreq pstate min %d nominal %d max %d\n", pstate_min,
>   pstate_nominal, pstate_max);
> + pr_info("frequency domain indicator %d", freq_domain_indicator);
>   pr_info("Workload Optimized Frequency is %s in the platform\n",
>   (powernv_pstate_info.wof_enabled) ? "enabled" : "disabled");
>  
> @@ -276,6 +326,15 @@ static int init_powernv_pstates(void)
>   return -ENODEV;
>   }
>  
> + if (freq_domain_indicator) {
> + hash_init(freq_domain_map);
> + for_each_possible_cpu(i) {
> + key = ((u32) get_hard_smp_processor_id(i) &
> + freq_domain_indicator);

Maybe break it like:

key = (u32) get_hard_smp_processor_id(i);
key &= freq_domain_indicator;

to make it easily readable ?

> + insert(key, i);
> + }
> + }
> +
>   powernv_pstate_info.nr_pstates = nr_pstates;
>   pr_debug("NR PStates %d\n", nr_pstates);
>   for (i = 0; i < nr_pstates; i++) {
> @@ -693,6 +752,7 @@ static int powernv_cpufreq_target_index(struct 
> cpufreq_policy *policy,
>  {
>   struct powernv_smp_call_data freq_data;
>   unsigned int cur_msec, gpstate_idx;
> +

:(

>   struct global_pstate_info *gpstates = policy->driver_data;
>  
>   if (unlikely(rebooting) && new_index != get_nominal_index())
> @@ -760,25 +820,55 @@ static int powernv_cpufreq_target_index(struct 
> cpufreq_policy *policy,
>  
>   spin_unlock(>gpstate_lock);
>  
> - /*
> -  * Use smp_call_function to send IPI and execute the
> -  * mtspr on 

Re: [PATCH v2] cpufreq: powernv: Add support of frequency domain

[Viresh Kumar]

On 20-12-17, 12:12, Abhishek Goel wrote:
> diff --git a/drivers/cpufreq/powernv-cpufreq.c 
> b/drivers/cpufreq/powernv-cpufreq.c
> index b6d7c4c..fd642bc 100644
> --- a/drivers/cpufreq/powernv-cpufreq.c
> +++ b/drivers/cpufreq/powernv-cpufreq.c
> @@ -37,6 +37,7 @@
>  #include  /* Required for cpu_sibling_mask() in UP configs */
>  #include 
>  #include 
> +#include 
>  
>  #define POWERNV_MAX_PSTATES  256
>  #define PMSR_PSAFE_ENABLE(1UL << 30)
> @@ -130,6 +131,9 @@ static struct chip {
>  static int nr_chips;
>  static DEFINE_PER_CPU(struct chip *, chip_info);
>  
> +static u32 freq_domain_indicator;
> +static u32 flag;

I wouldn't name it as flag, its unreadable. Maybe its better to name
it based on the quirk you are trying to workaround with ?

> +
>  /*
>   * Note:
>   * The set of pstates consists of contiguous integers.
> @@ -194,6 +198,38 @@ static inline void reset_gpstates(struct cpufreq_policy 
> *policy)
>   gpstates->last_gpstate_idx = 0;
>  }
>  
> +#define SIZE NR_CPUS
> +#define ORDER_FREQ_MAP ilog2(SIZE)
> +
> +static DEFINE_HASHTABLE(freq_domain_map, ORDER_FREQ_MAP);
> +
> +struct hashmap {
> + cpumask_t mask;
> + int chip_id;
> + u32 pir_key;
> + struct hlist_node hash_node;
> +};
> +
> +static void insert(u32 key, int cpu)
> +{
> + struct hashmap *data;
> +
> + hash_for_each_possible(freq_domain_map, data, hash_node, key%SIZE) {
> + if (data->chip_id == cpu_to_chip_id(cpu) &&
> + data->pir_key == key) {
> + cpumask_set_cpu(cpu, >mask);
> + return;
> + }
> + }
> +
> + data = kzalloc(sizeof(*data), GFP_KERNEL);
> + hash_add(freq_domain_map, >hash_node, key%SIZE);
> + cpumask_set_cpu(cpu, >mask);
> + data->chip_id = cpu_to_chip_id(cpu);
> + data->pir_key = key;
> +
> +}
> +
>  /*
>   * Initialize the freq table based on data obtained
>   * from the firmware passed via device-tree
> @@ -206,7 +242,9 @@ static int init_powernv_pstates(void)
>   u32 len_ids, len_freqs;
>   u32 pstate_min, pstate_max, pstate_nominal;
>   u32 pstate_turbo, pstate_ultra_turbo;
> + u32 key;
>  
> + flag = 0;

Isn't flag already 0 (global-uninitialized) ?

>   power_mgt = of_find_node_by_path("/ibm,opal/power-mgt");
>   if (!power_mgt) {
>   pr_warn("power-mgt node not found\n");
> @@ -229,6 +267,17 @@ static int init_powernv_pstates(void)
>   return -ENODEV;
>   }
>  
> + if (of_device_is_compatible(power_mgt, "freq-domain-v1") &&
> + of_property_read_u32(power_mgt, "ibm,freq-domain-indicator",
> +  _domain_indicator)) {
> + pr_warn("ibm,freq-domain-indicator not found\n");
> + freq_domain_indicator = 0;

You shouldn't be required to set it to 0 here.

> + }
> +
> + if (of_device_is_compatible(power_mgt, "P9-occ-quirk")) {
> + flag = 1;
> + }

Remove {} and a better name like p9_occ_quirk would be good for flag.
Also making it a bool may be better ?

> +
>   if (of_property_read_u32(power_mgt, "ibm,pstate-ultra-turbo",
>_ultra_turbo)) {
>   powernv_pstate_info.wof_enabled = false;
> @@ -249,6 +298,7 @@ static int init_powernv_pstates(void)
>  next:
>   pr_info("cpufreq pstate min %d nominal %d max %d\n", pstate_min,
>   pstate_nominal, pstate_max);
> + pr_info("frequency domain indicator %d", freq_domain_indicator);
>   pr_info("Workload Optimized Frequency is %s in the platform\n",
>   (powernv_pstate_info.wof_enabled) ? "enabled" : "disabled");
>  
> @@ -276,6 +326,15 @@ static int init_powernv_pstates(void)
>   return -ENODEV;
>   }
>  
> + if (freq_domain_indicator) {
> + hash_init(freq_domain_map);
> + for_each_possible_cpu(i) {
> + key = ((u32) get_hard_smp_processor_id(i) &
> + freq_domain_indicator);

Maybe break it like:

key = (u32) get_hard_smp_processor_id(i);
key &= freq_domain_indicator;

to make it easily readable ?

> + insert(key, i);
> + }
> + }
> +
>   powernv_pstate_info.nr_pstates = nr_pstates;
>   pr_debug("NR PStates %d\n", nr_pstates);
>   for (i = 0; i < nr_pstates; i++) {
> @@ -693,6 +752,7 @@ static int powernv_cpufreq_target_index(struct 
> cpufreq_policy *policy,
>  {
>   struct powernv_smp_call_data freq_data;
>   unsigned int cur_msec, gpstate_idx;
> +

:(

>   struct global_pstate_info *gpstates = policy->driver_data;
>  
>   if (unlikely(rebooting) && new_index != get_nominal_index())
> @@ -760,25 +820,55 @@ static int powernv_cpufreq_target_index(struct 
> cpufreq_policy *policy,
>  
>   spin_unlock(>gpstate_lock);
>  
> - /*
> -  * Use smp_call_function to send IPI and execute the
> -  * mtspr on 

Re: [PATCH] arm64: dts: Remove leading 0x and 0s from bindings notation

[Andy Gross]

On Thu, Dec 14, 2017 at 05:53:52PM +0100, Mathieu Malaterre wrote:
> Improve the DTS files by removing all the leading "0x" and zeros to fix the
> following dtc warnings:
> 
> Warning (unit_address_format): Node /XXX unit name should not have leading 
> "0x"
> 
> and
> 
> Warning (unit_address_format): Node /XXX unit name should not have leading 0s
> 
> Converted using the following command:
> 
> find . -type f \( -iname *.dts -o -iname *.dtsi \) -exec sed -E -i -e 
> "s/@0x([0-9a-fA-F\.]+)\s?\{/@\L\1 \{/g" -e "s/@0+([0-9a-fA-F\.]+)\s?\{/@\L\1 
> \{/g" {} +
> 
> For simplicity, two sed expressions were used to solve each warnings 
> separately.
> 
> To make the regex expression more robust a few other issues were resolved,
> namely setting unit-address to lower case, and adding a whitespace before the
> the opening curly brace:
> 
> https://elinux.org/Device_Tree_Linux#Linux_conventions
> 
> This is a follow up to commit 4c9847b7375a ("dt-bindings: Remove leading 0x 
> from bindings notation")
> 
> Reported-by: David Daney 
> Suggested-by: Rob Herring 
> Signed-off-by: Mathieu Malaterre 

Acked-by: Andy Gross 

Re: [PATCH] arm64: dts: Remove leading 0x and 0s from bindings notation

[Andy Gross]

On Thu, Dec 14, 2017 at 05:53:52PM +0100, Mathieu Malaterre wrote:
> Improve the DTS files by removing all the leading "0x" and zeros to fix the
> following dtc warnings:
> 
> Warning (unit_address_format): Node /XXX unit name should not have leading 
> "0x"
> 
> and
> 
> Warning (unit_address_format): Node /XXX unit name should not have leading 0s
> 
> Converted using the following command:
> 
> find . -type f \( -iname *.dts -o -iname *.dtsi \) -exec sed -E -i -e 
> "s/@0x([0-9a-fA-F\.]+)\s?\{/@\L\1 \{/g" -e "s/@0+([0-9a-fA-F\.]+)\s?\{/@\L\1 
> \{/g" {} +
> 
> For simplicity, two sed expressions were used to solve each warnings 
> separately.
> 
> To make the regex expression more robust a few other issues were resolved,
> namely setting unit-address to lower case, and adding a whitespace before the
> the opening curly brace:
> 
> https://elinux.org/Device_Tree_Linux#Linux_conventions
> 
> This is a follow up to commit 4c9847b7375a ("dt-bindings: Remove leading 0x 
> from bindings notation")
> 
> Reported-by: David Daney 
> Suggested-by: Rob Herring 
> Signed-off-by: Mathieu Malaterre 

Acked-by: Andy Gross 

Re: [PATCH v2 2/5] mm: Extends local cpu counter vm_diff_nodestat from s8 to s16

[kemi]

On 2017年12月20日 01:21, Christopher Lameter wrote:
> On Tue, 19 Dec 2017, Michal Hocko wrote:
> 
>>> Well the reason for s8 was to keep the data structures small so that they
>>> fit in the higher level cpu caches. The large these structures become the
>>> more cachelines are used by the counters and the larger the performance
>>> influence on the code that should not be impacted by the overhead.
>>
>> I am not sure I understand. We usually do not access more counters in
>> the single code path (well, PGALLOC and NUMA counteres is more of an
>> exception). So it is rarely an advantage that the whole array is in the
>> same cache line. Besides that this is allocated by the percpu allocator
>> aligns to the type size rather than cache lines AFAICS.
> 
> I thought we are talking about NUMA counters here?
> 
> Regardless: A typical fault, system call or OS action will access multiple
> zone and node counters when allocating or freeing memory. Enlarging the
> fields will increase the number of cachelines touched.
> 

Yes, we add one more cache line footprint access theoretically.
But I don't think it would be a problem.
1) Not all the counters need to be accessed in fast path of page allocation,
the counters covered in a single cache line usually is enough for that, we
probably don't need to access one more cache line. I tend to agree Michal's
argument.
Besides, in some slow path in which code is protected by zone lock or lru lock,
access one more cache line would be a big problem since many other cache lines 
are also be accessed.

2) Enlarging vm_node_stat_diff from s8 to s16 gives an opportunity to keep
more number in local cpus that provides the possibility of reducing the global
counter update frequency. Thus, we can gain the benefit by reducing expensive 
cache bouncing.  

Well, if you still have some concerns, I can post some data for 
will-it-scale.page_fault1.
What the benchmark does is: it forks nr_cpu processes and then each
process does the following:
1 mmap() 128M anonymous space;
2 writes to each page there to trigger actual page allocation;
3 munmap() it.
in a loop.
https://github.com/antonblanchard/will-it-scale/blob/master/tests/page_fault1.c

Or you can provide some other benchmarks on which you want to see performance 
impact.

>> Maybe it used to be all different back then when the code has been added
>> but arguing about cache lines seems to be a bit problematic here. Maybe
>> you have some specific workloads which can prove me wrong?
> 
> Run a workload that does some page faults? Heavy allocation and freeing of
> memory?
> 
> Maybe that is no longer relevant since the number of the counters is
> large that the accesses are so sparse that each action pulls in a whole
> cacheline. That would be something we tried to avoid when implementing
> the differentials.
> 
> 

Re: [PATCH v2 2/5] mm: Extends local cpu counter vm_diff_nodestat from s8 to s16

[kemi]

On 2017年12月20日 01:21, Christopher Lameter wrote:
> On Tue, 19 Dec 2017, Michal Hocko wrote:
> 
>>> Well the reason for s8 was to keep the data structures small so that they
>>> fit in the higher level cpu caches. The large these structures become the
>>> more cachelines are used by the counters and the larger the performance
>>> influence on the code that should not be impacted by the overhead.
>>
>> I am not sure I understand. We usually do not access more counters in
>> the single code path (well, PGALLOC and NUMA counteres is more of an
>> exception). So it is rarely an advantage that the whole array is in the
>> same cache line. Besides that this is allocated by the percpu allocator
>> aligns to the type size rather than cache lines AFAICS.
> 
> I thought we are talking about NUMA counters here?
> 
> Regardless: A typical fault, system call or OS action will access multiple
> zone and node counters when allocating or freeing memory. Enlarging the
> fields will increase the number of cachelines touched.
> 

Yes, we add one more cache line footprint access theoretically.
But I don't think it would be a problem.
1) Not all the counters need to be accessed in fast path of page allocation,
the counters covered in a single cache line usually is enough for that, we
probably don't need to access one more cache line. I tend to agree Michal's
argument.
Besides, in some slow path in which code is protected by zone lock or lru lock,
access one more cache line would be a big problem since many other cache lines 
are also be accessed.

2) Enlarging vm_node_stat_diff from s8 to s16 gives an opportunity to keep
more number in local cpus that provides the possibility of reducing the global
counter update frequency. Thus, we can gain the benefit by reducing expensive 
cache bouncing.  

Well, if you still have some concerns, I can post some data for 
will-it-scale.page_fault1.
What the benchmark does is: it forks nr_cpu processes and then each
process does the following:
1 mmap() 128M anonymous space;
2 writes to each page there to trigger actual page allocation;
3 munmap() it.
in a loop.
https://github.com/antonblanchard/will-it-scale/blob/master/tests/page_fault1.c

Or you can provide some other benchmarks on which you want to see performance 
impact.

>> Maybe it used to be all different back then when the code has been added
>> but arguing about cache lines seems to be a bit problematic here. Maybe
>> you have some specific workloads which can prove me wrong?
> 
> Run a workload that does some page faults? Heavy allocation and freeing of
> memory?
> 
> Maybe that is no longer relevant since the number of the counters is
> large that the accesses are so sparse that each action pulls in a whole
> cacheline. That would be something we tried to avoid when implementing
> the differentials.
> 
> 

Re: [PATCH v2] IPI performance benchmark

[Wanpeng Li]

Hi Yury,
2017-12-19 16:50 GMT+08:00 Yury Norov :
> This benchmark sends many IPIs in different modes and measures
> time for IPI delivery (first column), and total time, ie including
> time to acknowledge the receive by sender (second column).
>
> The scenarios are:
> Dry-run:do everything except actually sending IPI. Useful
> to estimate system overhead.
> Self-IPI:   Send IPI to self CPU.
> Normal IPI: Send IPI to some other CPU.
> Broadcast IPI:  Send broadcast IPI to all online CPUs.
> Broadcast lock: Send broadcast IPI to all online CPUs and force them
> acquire/release spinlock.
>
> The raw output looks like this:
> [  155.363374] Dry-run: 0,2999696 ns
> [  155.429162] Self-IPI: 30385328,   65589392 ns
> [  156.060821] Normal IPI:  566914128,  631453008 ns
> [  158.384427] Broadcast IPI:   0, 2323368720 ns
> [  160.831850] Broadcast lock:  0, 2447000544 ns
>
> For virtualized guests, sending and reveiving IPIs causes guest exit.
> I used this test to measure performance impact on KVM subsystem of
> Christoffer Dall's series "Optimize KVM/ARM for VHE systems" [1].
>
> Test machine is ThunderX2, 112 online CPUs. Below the results normalized
> to host dry-run time, broadcast lock results omitted. Smaller - better.

Could you test on a x86 box? I see a lot of calltraces on my haswell
client host, there is no calltrace in the guest, however, I can still
observe "Invalid parameters" warning when insmod this module. In
addition, the x86 box fails to boot when ipi_benchmark is buildin.

Regards,
Wanpeng Li

Re: [PATCH v2] IPI performance benchmark

[Wanpeng Li]

Hi Yury,
2017-12-19 16:50 GMT+08:00 Yury Norov :
> This benchmark sends many IPIs in different modes and measures
> time for IPI delivery (first column), and total time, ie including
> time to acknowledge the receive by sender (second column).
>
> The scenarios are:
> Dry-run:do everything except actually sending IPI. Useful
> to estimate system overhead.
> Self-IPI:   Send IPI to self CPU.
> Normal IPI: Send IPI to some other CPU.
> Broadcast IPI:  Send broadcast IPI to all online CPUs.
> Broadcast lock: Send broadcast IPI to all online CPUs and force them
> acquire/release spinlock.
>
> The raw output looks like this:
> [  155.363374] Dry-run: 0,2999696 ns
> [  155.429162] Self-IPI: 30385328,   65589392 ns
> [  156.060821] Normal IPI:  566914128,  631453008 ns
> [  158.384427] Broadcast IPI:   0, 2323368720 ns
> [  160.831850] Broadcast lock:  0, 2447000544 ns
>
> For virtualized guests, sending and reveiving IPIs causes guest exit.
> I used this test to measure performance impact on KVM subsystem of
> Christoffer Dall's series "Optimize KVM/ARM for VHE systems" [1].
>
> Test machine is ThunderX2, 112 online CPUs. Below the results normalized
> to host dry-run time, broadcast lock results omitted. Smaller - better.

Could you test on a x86 box? I see a lot of calltraces on my haswell
client host, there is no calltrace in the guest, however, I can still
observe "Invalid parameters" warning when insmod this module. In
addition, the x86 box fails to boot when ipi_benchmark is buildin.

Regards,
Wanpeng Li

[PATCH v2] cpufreq: powernv: Add support of frequency domain

[Abhishek Goel]

Frequency-domain indicates group of CPUs that would share same frequency.
It is detected using device-tree node "frequency-domain-indicator".
frequency-domain-indicator is a bitmask which will have different value
depending upon the generation of the processor.

CPUs of the same chip for which the result of a bitwise AND between
their PIR and the frequency-domain-indicator is the same share the same
frequency.

In this patch, we define hash-table indexed by the aforementioned
bitwise ANDed value to store the cpumask of the CPUs sharing the same
frequency domain. Further, the cpufreq policy will be created per
frequency-domain

So for POWER9, a cpufreq policy is created per quad while for POWER8 it
is created per core. Governor decides frequency for each policy but
multiple cores may come under same policy. In such case frequency needs
to be set on each core sharing that policy.

Signed-off-by: Abhishek Goel 
---
 drivers/cpufreq/powernv-cpufreq.c | 110 ++
 1 file changed, 100 insertions(+), 10 deletions(-)

diff --git a/drivers/cpufreq/powernv-cpufreq.c 
b/drivers/cpufreq/powernv-cpufreq.c
index b6d7c4c..fd642bc 100644
--- a/drivers/cpufreq/powernv-cpufreq.c
+++ b/drivers/cpufreq/powernv-cpufreq.c
@@ -37,6 +37,7 @@
 #include  /* Required for cpu_sibling_mask() in UP configs */
 #include 
 #include 
+#include 
 
 #define POWERNV_MAX_PSTATES256
 #define PMSR_PSAFE_ENABLE  (1UL << 30)
@@ -130,6 +131,9 @@ static struct chip {
 static int nr_chips;
 static DEFINE_PER_CPU(struct chip *, chip_info);
 
+static u32 freq_domain_indicator;
+static u32 flag;
+
 /*
  * Note:
  * The set of pstates consists of contiguous integers.
@@ -194,6 +198,38 @@ static inline void reset_gpstates(struct cpufreq_policy 
*policy)
gpstates->last_gpstate_idx = 0;
 }
 
+#define SIZE NR_CPUS
+#define ORDER_FREQ_MAP ilog2(SIZE)
+
+static DEFINE_HASHTABLE(freq_domain_map, ORDER_FREQ_MAP);
+
+struct hashmap {
+   cpumask_t mask;
+   int chip_id;
+   u32 pir_key;
+   struct hlist_node hash_node;
+};
+
+static void insert(u32 key, int cpu)
+{
+   struct hashmap *data;
+
+   hash_for_each_possible(freq_domain_map, data, hash_node, key%SIZE) {
+   if (data->chip_id == cpu_to_chip_id(cpu) &&
+   data->pir_key == key) {
+   cpumask_set_cpu(cpu, >mask);
+   return;
+   }
+   }
+
+   data = kzalloc(sizeof(*data), GFP_KERNEL);
+   hash_add(freq_domain_map, >hash_node, key%SIZE);
+   cpumask_set_cpu(cpu, >mask);
+   data->chip_id = cpu_to_chip_id(cpu);
+   data->pir_key = key;
+
+}
+
 /*
  * Initialize the freq table based on data obtained
  * from the firmware passed via device-tree
@@ -206,7 +242,9 @@ static int init_powernv_pstates(void)
u32 len_ids, len_freqs;
u32 pstate_min, pstate_max, pstate_nominal;
u32 pstate_turbo, pstate_ultra_turbo;
+   u32 key;
 
+   flag = 0;
power_mgt = of_find_node_by_path("/ibm,opal/power-mgt");
if (!power_mgt) {
pr_warn("power-mgt node not found\n");
@@ -229,6 +267,17 @@ static int init_powernv_pstates(void)
return -ENODEV;
}
 
+   if (of_device_is_compatible(power_mgt, "freq-domain-v1") &&
+   of_property_read_u32(power_mgt, "ibm,freq-domain-indicator",
+_domain_indicator)) {
+   pr_warn("ibm,freq-domain-indicator not found\n");
+   freq_domain_indicator = 0;
+   }
+
+   if (of_device_is_compatible(power_mgt, "P9-occ-quirk")) {
+   flag = 1;
+   }
+
if (of_property_read_u32(power_mgt, "ibm,pstate-ultra-turbo",
 _ultra_turbo)) {
powernv_pstate_info.wof_enabled = false;
@@ -249,6 +298,7 @@ static int init_powernv_pstates(void)
 next:
pr_info("cpufreq pstate min %d nominal %d max %d\n", pstate_min,
pstate_nominal, pstate_max);
+   pr_info("frequency domain indicator %d", freq_domain_indicator);
pr_info("Workload Optimized Frequency is %s in the platform\n",
(powernv_pstate_info.wof_enabled) ? "enabled" : "disabled");
 
@@ -276,6 +326,15 @@ static int init_powernv_pstates(void)
return -ENODEV;
}
 
+   if (freq_domain_indicator) {
+   hash_init(freq_domain_map);
+   for_each_possible_cpu(i) {
+   key = ((u32) get_hard_smp_processor_id(i) &
+   freq_domain_indicator);
+   insert(key, i);
+   }
+   }
+
powernv_pstate_info.nr_pstates = nr_pstates;
pr_debug("NR PStates %d\n", nr_pstates);
for (i = 0; i < nr_pstates; i++) {
@@ -693,6 +752,7 @@ static int powernv_cpufreq_target_index(struct 
cpufreq_policy *policy,
 {
struct powernv_smp_call_data freq_data;

[PATCH 1/2] clk: mediatek: group drivers under indpendent menu

[sean.wang]

From: Sean Wang 

Getting much MediaTek clock driver have been added to CCF, so it's
better adding the cleanup for grouping drivers under the independent
menu to simplify configuration selection. In addition, really trivial
fixups for typos are added in the same patch.

Signed-off-by: Sean Wang 
---
 drivers/clk/mediatek/Kconfig | 96 +++-
 1 file changed, 50 insertions(+), 46 deletions(-)

diff --git a/drivers/clk/mediatek/Kconfig b/drivers/clk/mediatek/Kconfig
index 59dc0aa..7338f81 100644
--- a/drivers/clk/mediatek/Kconfig
+++ b/drivers/clk/mediatek/Kconfig
@@ -1,136 +1,139 @@
 #
-# MediaTek SoC drivers
+# MediaTek Clock Drivers
 #
+menu "Clock driver for MediaTek SoC"
+   depends on ARCH_MEDIATEK || COMPILE_TEST
+
 config COMMON_CLK_MEDIATEK
bool
---help---
- Mediatek SoCs' clock support.
+ MediaTek SoCs' clock support.
 
 config COMMON_CLK_MT2701
-   bool "Clock driver for Mediatek MT2701"
+   bool "Clock driver for MediaTek MT2701"
depends on (ARCH_MEDIATEK && ARM) || COMPILE_TEST
select COMMON_CLK_MEDIATEK
default ARCH_MEDIATEK && ARM
---help---
- This driver supports Mediatek MT2701 basic clocks.
+ This driver supports MediaTek MT2701 basic clocks.
 
 config COMMON_CLK_MT2701_MMSYS
-   bool "Clock driver for Mediatek MT2701 mmsys"
+   bool "Clock driver for MediaTek MT2701 mmsys"
depends on COMMON_CLK_MT2701
---help---
- This driver supports Mediatek MT2701 mmsys clocks.
+ This driver supports MediaTek MT2701 mmsys clocks.
 
 config COMMON_CLK_MT2701_IMGSYS
-   bool "Clock driver for Mediatek MT2701 imgsys"
+   bool "Clock driver for MediaTek MT2701 imgsys"
depends on COMMON_CLK_MT2701
---help---
- This driver supports Mediatek MT2701 imgsys clocks.
+ This driver supports MediaTek MT2701 imgsys clocks.
 
 config COMMON_CLK_MT2701_VDECSYS
-   bool "Clock driver for Mediatek MT2701 vdecsys"
+   bool "Clock driver for MediaTek MT2701 vdecsys"
depends on COMMON_CLK_MT2701
---help---
- This driver supports Mediatek MT2701 vdecsys clocks.
+ This driver supports MediaTek MT2701 vdecsys clocks.
 
 config COMMON_CLK_MT2701_HIFSYS
-   bool "Clock driver for Mediatek MT2701 hifsys"
+   bool "Clock driver for MediaTek MT2701 hifsys"
depends on COMMON_CLK_MT2701
---help---
- This driver supports Mediatek MT2701 hifsys clocks.
+ This driver supports MediaTek MT2701 hifsys clocks.
 
 config COMMON_CLK_MT2701_ETHSYS
-   bool "Clock driver for Mediatek MT2701 ethsys"
+   bool "Clock driver for MediaTek MT2701 ethsys"
depends on COMMON_CLK_MT2701
---help---
- This driver supports Mediatek MT2701 ethsys clocks.
+ This driver supports MediaTek MT2701 ethsys clocks.
 
 config COMMON_CLK_MT2701_BDPSYS
-   bool "Clock driver for Mediatek MT2701 bdpsys"
+   bool "Clock driver for MediaTek MT2701 bdpsys"
depends on COMMON_CLK_MT2701
---help---
- This driver supports Mediatek MT2701 bdpsys clocks.
+ This driver supports MediaTek MT2701 bdpsys clocks.
 
 config COMMON_CLK_MT2712
-   bool "Clock driver for Mediatek MT2712"
+   bool "Clock driver for MediaTek MT2712"
depends on (ARCH_MEDIATEK && ARM64) || COMPILE_TEST
select COMMON_CLK_MEDIATEK
default ARCH_MEDIATEK && ARM64
---help---
- This driver supports Mediatek MT2712 basic clocks.
+ This driver supports MediaTek MT2712 basic clocks.
 
 config COMMON_CLK_MT2712_BDPSYS
-   bool "Clock driver for Mediatek MT2712 bdpsys"
+   bool "Clock driver for MediaTek MT2712 bdpsys"
depends on COMMON_CLK_MT2712
---help---
- This driver supports Mediatek MT2712 bdpsys clocks.
+ This driver supports MediaTek MT2712 bdpsys clocks.
 
 config COMMON_CLK_MT2712_IMGSYS
-   bool "Clock driver for Mediatek MT2712 imgsys"
+   bool "Clock driver for MediaTek MT2712 imgsys"
depends on COMMON_CLK_MT2712
---help---
- This driver supports Mediatek MT2712 imgsys clocks.
+ This driver supports MediaTek MT2712 imgsys clocks.
 
 config COMMON_CLK_MT2712_JPGDECSYS
-   bool "Clock driver for Mediatek MT2712 jpgdecsys"
+   bool "Clock driver for MediaTek MT2712 jpgdecsys"
depends on COMMON_CLK_MT2712
---help---
- This driver supports Mediatek MT2712 jpgdecsys clocks.
+ This driver supports MediaTek MT2712 jpgdecsys clocks.
 
 config COMMON_CLK_MT2712_MFGCFG
-   bool "Clock driver for Mediatek MT2712 mfgcfg"
+   bool "Clock driver for MediaTek MT2712 mfgcfg"
depends on COMMON_CLK_MT2712
---help---
- This driver supports Mediatek MT2712 mfgcfg clocks.
+ This driver supports MediaTek 

[PATCH v2] cpufreq: powernv: Add support of frequency domain

[Abhishek Goel]

Frequency-domain indicates group of CPUs that would share same frequency.
It is detected using device-tree node "frequency-domain-indicator".
frequency-domain-indicator is a bitmask which will have different value
depending upon the generation of the processor.

CPUs of the same chip for which the result of a bitwise AND between
their PIR and the frequency-domain-indicator is the same share the same
frequency.

In this patch, we define hash-table indexed by the aforementioned
bitwise ANDed value to store the cpumask of the CPUs sharing the same
frequency domain. Further, the cpufreq policy will be created per
frequency-domain

So for POWER9, a cpufreq policy is created per quad while for POWER8 it
is created per core. Governor decides frequency for each policy but
multiple cores may come under same policy. In such case frequency needs
to be set on each core sharing that policy.

Signed-off-by: Abhishek Goel 
---
 drivers/cpufreq/powernv-cpufreq.c | 110 ++
 1 file changed, 100 insertions(+), 10 deletions(-)

diff --git a/drivers/cpufreq/powernv-cpufreq.c 
b/drivers/cpufreq/powernv-cpufreq.c
index b6d7c4c..fd642bc 100644
--- a/drivers/cpufreq/powernv-cpufreq.c
+++ b/drivers/cpufreq/powernv-cpufreq.c
@@ -37,6 +37,7 @@
 #include  /* Required for cpu_sibling_mask() in UP configs */
 #include 
 #include 
+#include 
 
 #define POWERNV_MAX_PSTATES256
 #define PMSR_PSAFE_ENABLE  (1UL << 30)
@@ -130,6 +131,9 @@ static struct chip {
 static int nr_chips;
 static DEFINE_PER_CPU(struct chip *, chip_info);
 
+static u32 freq_domain_indicator;
+static u32 flag;
+
 /*
  * Note:
  * The set of pstates consists of contiguous integers.
@@ -194,6 +198,38 @@ static inline void reset_gpstates(struct cpufreq_policy 
*policy)
gpstates->last_gpstate_idx = 0;
 }
 
+#define SIZE NR_CPUS
+#define ORDER_FREQ_MAP ilog2(SIZE)
+
+static DEFINE_HASHTABLE(freq_domain_map, ORDER_FREQ_MAP);
+
+struct hashmap {
+   cpumask_t mask;
+   int chip_id;
+   u32 pir_key;
+   struct hlist_node hash_node;
+};
+
+static void insert(u32 key, int cpu)
+{
+   struct hashmap *data;
+
+   hash_for_each_possible(freq_domain_map, data, hash_node, key%SIZE) {
+   if (data->chip_id == cpu_to_chip_id(cpu) &&
+   data->pir_key == key) {
+   cpumask_set_cpu(cpu, >mask);
+   return;
+   }
+   }
+
+   data = kzalloc(sizeof(*data), GFP_KERNEL);
+   hash_add(freq_domain_map, >hash_node, key%SIZE);
+   cpumask_set_cpu(cpu, >mask);
+   data->chip_id = cpu_to_chip_id(cpu);
+   data->pir_key = key;
+
+}
+
 /*
  * Initialize the freq table based on data obtained
  * from the firmware passed via device-tree
@@ -206,7 +242,9 @@ static int init_powernv_pstates(void)
u32 len_ids, len_freqs;
u32 pstate_min, pstate_max, pstate_nominal;
u32 pstate_turbo, pstate_ultra_turbo;
+   u32 key;
 
+   flag = 0;
power_mgt = of_find_node_by_path("/ibm,opal/power-mgt");
if (!power_mgt) {
pr_warn("power-mgt node not found\n");
@@ -229,6 +267,17 @@ static int init_powernv_pstates(void)
return -ENODEV;
}
 
+   if (of_device_is_compatible(power_mgt, "freq-domain-v1") &&
+   of_property_read_u32(power_mgt, "ibm,freq-domain-indicator",
+_domain_indicator)) {
+   pr_warn("ibm,freq-domain-indicator not found\n");
+   freq_domain_indicator = 0;
+   }
+
+   if (of_device_is_compatible(power_mgt, "P9-occ-quirk")) {
+   flag = 1;
+   }
+
if (of_property_read_u32(power_mgt, "ibm,pstate-ultra-turbo",
 _ultra_turbo)) {
powernv_pstate_info.wof_enabled = false;
@@ -249,6 +298,7 @@ static int init_powernv_pstates(void)
 next:
pr_info("cpufreq pstate min %d nominal %d max %d\n", pstate_min,
pstate_nominal, pstate_max);
+   pr_info("frequency domain indicator %d", freq_domain_indicator);
pr_info("Workload Optimized Frequency is %s in the platform\n",
(powernv_pstate_info.wof_enabled) ? "enabled" : "disabled");
 
@@ -276,6 +326,15 @@ static int init_powernv_pstates(void)
return -ENODEV;
}
 
+   if (freq_domain_indicator) {
+   hash_init(freq_domain_map);
+   for_each_possible_cpu(i) {
+   key = ((u32) get_hard_smp_processor_id(i) &
+   freq_domain_indicator);
+   insert(key, i);
+   }
+   }
+
powernv_pstate_info.nr_pstates = nr_pstates;
pr_debug("NR PStates %d\n", nr_pstates);
for (i = 0; i < nr_pstates; i++) {
@@ -693,6 +752,7 @@ static int powernv_cpufreq_target_index(struct 
cpufreq_policy *policy,
 {
struct powernv_smp_call_data freq_data;
unsigned int cur_msec, 

[PATCH 1/2] clk: mediatek: group drivers under indpendent menu

[sean.wang]

From: Sean Wang 

Getting much MediaTek clock driver have been added to CCF, so it's
better adding the cleanup for grouping drivers under the independent
menu to simplify configuration selection. In addition, really trivial
fixups for typos are added in the same patch.

Signed-off-by: Sean Wang 
---
 drivers/clk/mediatek/Kconfig | 96 +++-
 1 file changed, 50 insertions(+), 46 deletions(-)

diff --git a/drivers/clk/mediatek/Kconfig b/drivers/clk/mediatek/Kconfig
index 59dc0aa..7338f81 100644
--- a/drivers/clk/mediatek/Kconfig
+++ b/drivers/clk/mediatek/Kconfig
@@ -1,136 +1,139 @@
 #
-# MediaTek SoC drivers
+# MediaTek Clock Drivers
 #
+menu "Clock driver for MediaTek SoC"
+   depends on ARCH_MEDIATEK || COMPILE_TEST
+
 config COMMON_CLK_MEDIATEK
bool
---help---
- Mediatek SoCs' clock support.
+ MediaTek SoCs' clock support.
 
 config COMMON_CLK_MT2701
-   bool "Clock driver for Mediatek MT2701"
+   bool "Clock driver for MediaTek MT2701"
depends on (ARCH_MEDIATEK && ARM) || COMPILE_TEST
select COMMON_CLK_MEDIATEK
default ARCH_MEDIATEK && ARM
---help---
- This driver supports Mediatek MT2701 basic clocks.
+ This driver supports MediaTek MT2701 basic clocks.
 
 config COMMON_CLK_MT2701_MMSYS
-   bool "Clock driver for Mediatek MT2701 mmsys"
+   bool "Clock driver for MediaTek MT2701 mmsys"
depends on COMMON_CLK_MT2701
---help---
- This driver supports Mediatek MT2701 mmsys clocks.
+ This driver supports MediaTek MT2701 mmsys clocks.
 
 config COMMON_CLK_MT2701_IMGSYS
-   bool "Clock driver for Mediatek MT2701 imgsys"
+   bool "Clock driver for MediaTek MT2701 imgsys"
depends on COMMON_CLK_MT2701
---help---
- This driver supports Mediatek MT2701 imgsys clocks.
+ This driver supports MediaTek MT2701 imgsys clocks.
 
 config COMMON_CLK_MT2701_VDECSYS
-   bool "Clock driver for Mediatek MT2701 vdecsys"
+   bool "Clock driver for MediaTek MT2701 vdecsys"
depends on COMMON_CLK_MT2701
---help---
- This driver supports Mediatek MT2701 vdecsys clocks.
+ This driver supports MediaTek MT2701 vdecsys clocks.
 
 config COMMON_CLK_MT2701_HIFSYS
-   bool "Clock driver for Mediatek MT2701 hifsys"
+   bool "Clock driver for MediaTek MT2701 hifsys"
depends on COMMON_CLK_MT2701
---help---
- This driver supports Mediatek MT2701 hifsys clocks.
+ This driver supports MediaTek MT2701 hifsys clocks.
 
 config COMMON_CLK_MT2701_ETHSYS
-   bool "Clock driver for Mediatek MT2701 ethsys"
+   bool "Clock driver for MediaTek MT2701 ethsys"
depends on COMMON_CLK_MT2701
---help---
- This driver supports Mediatek MT2701 ethsys clocks.
+ This driver supports MediaTek MT2701 ethsys clocks.
 
 config COMMON_CLK_MT2701_BDPSYS
-   bool "Clock driver for Mediatek MT2701 bdpsys"
+   bool "Clock driver for MediaTek MT2701 bdpsys"
depends on COMMON_CLK_MT2701
---help---
- This driver supports Mediatek MT2701 bdpsys clocks.
+ This driver supports MediaTek MT2701 bdpsys clocks.
 
 config COMMON_CLK_MT2712
-   bool "Clock driver for Mediatek MT2712"
+   bool "Clock driver for MediaTek MT2712"
depends on (ARCH_MEDIATEK && ARM64) || COMPILE_TEST
select COMMON_CLK_MEDIATEK
default ARCH_MEDIATEK && ARM64
---help---
- This driver supports Mediatek MT2712 basic clocks.
+ This driver supports MediaTek MT2712 basic clocks.
 
 config COMMON_CLK_MT2712_BDPSYS
-   bool "Clock driver for Mediatek MT2712 bdpsys"
+   bool "Clock driver for MediaTek MT2712 bdpsys"
depends on COMMON_CLK_MT2712
---help---
- This driver supports Mediatek MT2712 bdpsys clocks.
+ This driver supports MediaTek MT2712 bdpsys clocks.
 
 config COMMON_CLK_MT2712_IMGSYS
-   bool "Clock driver for Mediatek MT2712 imgsys"
+   bool "Clock driver for MediaTek MT2712 imgsys"
depends on COMMON_CLK_MT2712
---help---
- This driver supports Mediatek MT2712 imgsys clocks.
+ This driver supports MediaTek MT2712 imgsys clocks.
 
 config COMMON_CLK_MT2712_JPGDECSYS
-   bool "Clock driver for Mediatek MT2712 jpgdecsys"
+   bool "Clock driver for MediaTek MT2712 jpgdecsys"
depends on COMMON_CLK_MT2712
---help---
- This driver supports Mediatek MT2712 jpgdecsys clocks.
+ This driver supports MediaTek MT2712 jpgdecsys clocks.
 
 config COMMON_CLK_MT2712_MFGCFG
-   bool "Clock driver for Mediatek MT2712 mfgcfg"
+   bool "Clock driver for MediaTek MT2712 mfgcfg"
depends on COMMON_CLK_MT2712
---help---
- This driver supports Mediatek MT2712 mfgcfg clocks.
+ This driver supports MediaTek MT2712 mfgcfg clocks.
 
 config 

[PATCH 2/2] clk: mediatek: fixup test-building of MediaTek clock drivers

[sean.wang]

From: Sean Wang 

Let the build system looking into the directiory where the clock drivers
resides for the COMPILE_TEST alternative dependency allows test-building
the drivers.

Signed-off-by: Sean Wang 
---
 drivers/clk/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index f7f761b..2e3fb08 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -67,7 +67,7 @@ obj-$(CONFIG_ARCH_MXC)+= imx/
 obj-$(CONFIG_MACH_INGENIC) += ingenic/
 obj-$(CONFIG_ARCH_KEYSTONE)+= keystone/
 obj-$(CONFIG_MACH_LOONGSON32)  += loongson1/
-obj-$(CONFIG_ARCH_MEDIATEK)+= mediatek/
+obj-y  += mediatek/
 obj-$(CONFIG_COMMON_CLK_AMLOGIC)   += meson/
 obj-$(CONFIG_MACH_PIC32)   += microchip/
 ifeq ($(CONFIG_COMMON_CLK), y)
-- 
2.7.4

[PATCH 2/2] clk: mediatek: fixup test-building of MediaTek clock drivers

[sean.wang]

From: Sean Wang 

Let the build system looking into the directiory where the clock drivers
resides for the COMPILE_TEST alternative dependency allows test-building
the drivers.

Signed-off-by: Sean Wang 
---
 drivers/clk/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index f7f761b..2e3fb08 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -67,7 +67,7 @@ obj-$(CONFIG_ARCH_MXC)+= imx/
 obj-$(CONFIG_MACH_INGENIC) += ingenic/
 obj-$(CONFIG_ARCH_KEYSTONE)+= keystone/
 obj-$(CONFIG_MACH_LOONGSON32)  += loongson1/
-obj-$(CONFIG_ARCH_MEDIATEK)+= mediatek/
+obj-y  += mediatek/
 obj-$(CONFIG_COMMON_CLK_AMLOGIC)   += meson/
 obj-$(CONFIG_MACH_PIC32)   += microchip/
 ifeq ($(CONFIG_COMMON_CLK), y)
-- 
2.7.4

Re: [PATCH 1/3] phy: core: Move runtime PM reference counting to the parent device

[Kishon Vijay Abraham I]

Hi Ulf,

On Wednesday 20 December 2017 02:52 AM, Ulf Hansson wrote:
> The runtime PM deployment in the phy core is a bit unnecessary complicated
> and the main reason is because it operates on the phy device, which is
> created by the phy core and assigned as a child device of the phy provider
> device.
> 
> Let's simplify the code, by replacing the existing calls to
> phy_pm_runtime_get_sync() and phy_pm_runtime_put(), with regular calls to
> pm_runtime_get_sync() and pm_runtime_put(). While doing that, let's also
> change to give the phy provider device as the parameter to the runtime PM
> calls. This together with adding error paths, that allows the phy
> provider device to be runtime PM disabled, enables further clean up the
> code. More precisely, we can simply avoid to enable runtime PM for the phy
> device altogether, so let's do that as well.
> 
> More importantly, this change also fixes an issue for system suspend.
> Especially in those cases when the phy provider device gets put into a low
> power state via calling the pm_runtime_force_suspend() helper, as is the
> case for a Renesas SoC, which has the phy provider device attached to the
> generic PM domain.
> 
> The problem in this case, is that pm_runtime_force_suspend() expects the
> child device of the provider device to be runtime suspended, else this will
> trigger a WARN splat (correctly) when runtime PM gets re-enabled at system
> resume.
> 
> In the current case, even if phy_power_off() triggers a pm_runtime_put()
> during system suspend the phy device (child) doesn't get runtime suspended,
> because that is prevented in the system suspend phases. However, by
> avoiding to enable runtime PM, this problem goes away.
> 
> Signed-off-by: Ulf Hansson 
> ---
>  drivers/phy/phy-core.c | 33 +
>  1 file changed, 13 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
> index b4964b0..9fa3f13 100644
> --- a/drivers/phy/phy-core.c
> +++ b/drivers/phy/phy-core.c
> @@ -222,10 +222,10 @@ int phy_init(struct phy *phy)
>   if (!phy)
>   return 0;
>  
> - ret = phy_pm_runtime_get_sync(phy);
> - if (ret < 0 && ret != -ENOTSUPP)
> + ret = pm_runtime_get_sync(phy->dev.parent);

Won't this make phy-core manage pm_runtime of phy_provider even though the
phy_provider might not intend it?

Thanks
Kishon

Re: [PATCH 1/3] phy: core: Move runtime PM reference counting to the parent device

[Kishon Vijay Abraham I]

Hi Ulf,

On Wednesday 20 December 2017 02:52 AM, Ulf Hansson wrote:
> The runtime PM deployment in the phy core is a bit unnecessary complicated
> and the main reason is because it operates on the phy device, which is
> created by the phy core and assigned as a child device of the phy provider
> device.
> 
> Let's simplify the code, by replacing the existing calls to
> phy_pm_runtime_get_sync() and phy_pm_runtime_put(), with regular calls to
> pm_runtime_get_sync() and pm_runtime_put(). While doing that, let's also
> change to give the phy provider device as the parameter to the runtime PM
> calls. This together with adding error paths, that allows the phy
> provider device to be runtime PM disabled, enables further clean up the
> code. More precisely, we can simply avoid to enable runtime PM for the phy
> device altogether, so let's do that as well.
> 
> More importantly, this change also fixes an issue for system suspend.
> Especially in those cases when the phy provider device gets put into a low
> power state via calling the pm_runtime_force_suspend() helper, as is the
> case for a Renesas SoC, which has the phy provider device attached to the
> generic PM domain.
> 
> The problem in this case, is that pm_runtime_force_suspend() expects the
> child device of the provider device to be runtime suspended, else this will
> trigger a WARN splat (correctly) when runtime PM gets re-enabled at system
> resume.
> 
> In the current case, even if phy_power_off() triggers a pm_runtime_put()
> during system suspend the phy device (child) doesn't get runtime suspended,
> because that is prevented in the system suspend phases. However, by
> avoiding to enable runtime PM, this problem goes away.
> 
> Signed-off-by: Ulf Hansson 
> ---
>  drivers/phy/phy-core.c | 33 +
>  1 file changed, 13 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
> index b4964b0..9fa3f13 100644
> --- a/drivers/phy/phy-core.c
> +++ b/drivers/phy/phy-core.c
> @@ -222,10 +222,10 @@ int phy_init(struct phy *phy)
>   if (!phy)
>   return 0;
>  
> - ret = phy_pm_runtime_get_sync(phy);
> - if (ret < 0 && ret != -ENOTSUPP)
> + ret = pm_runtime_get_sync(phy->dev.parent);

Won't this make phy-core manage pm_runtime of phy_provider even though the
phy_provider might not intend it?

Thanks
Kishon

Re: [PATCH v5 15/15] devicetree: bindings: Document qcom,pvs

[Sricharan R]

Hi Viresh,

On 12/20/2017 11:57 AM, Viresh Kumar wrote:
> On 20-12-17, 11:55, Sricharan R wrote:
 +  opp-14 {
 +  opp-hz = /bits/ 64 <14>;
 +  opp-microvolt-speed0-pvs0-v0 = <125>;
>>>
>>> Why speed0 and v0 in all the names ?
>>>
>>
>>  Ya, all the three (speed, pvs and version) are read from efuse. So all the 
>> three
>>  can vary.
> 
> Okay, so may be in the example you should have a mix of all the
> combinations to show how these things work ? You only showed values
> for a single efuse configuration currently.
> 

 Ha ok. Will add other examples as well.

Regards,
 Sricharan

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

Re: [PATCH v5 15/15] devicetree: bindings: Document qcom,pvs

[Sricharan R]

Hi Viresh,

On 12/20/2017 11:57 AM, Viresh Kumar wrote:
> On 20-12-17, 11:55, Sricharan R wrote:
 +  opp-14 {
 +  opp-hz = /bits/ 64 <14>;
 +  opp-microvolt-speed0-pvs0-v0 = <125>;
>>>
>>> Why speed0 and v0 in all the names ?
>>>
>>
>>  Ya, all the three (speed, pvs and version) are read from efuse. So all the 
>> three
>>  can vary.
> 
> Okay, so may be in the example you should have a mix of all the
> combinations to show how these things work ? You only showed values
> for a single efuse configuration currently.
> 

 Ha ok. Will add other examples as well.

Regards,
 Sricharan

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

Re: [PATCH 1/3] x86/entry: Fix idtentry unwind hint

[Josh Poimboeuf]

On Wed, Dec 20, 2017 at 05:41:44AM +, Andrey Vagin wrote:
> Hi Josh,
> 
> 
> Now I see these two warnings on Linus' tree:
> 
> [1.902454] WARNING: stack recursion on stack type 1
> [1.902466] WARNING: can't dereference iret registers at cd089a12 
> for ip entry_SYSCALL_64_fastpath+0x5/0x86

This still looks like the same issue where ORC is getting confused by
paravirt patching.  Unfortunately the patches which fix this got
preempted by other work again.  I haven't forgotten about it.

2017 is out the window, but hopefully in January I'll get a chance to
revive the patches.

-- 
Josh

Re: [PATCH 1/3] x86/entry: Fix idtentry unwind hint

[Josh Poimboeuf]

On Wed, Dec 20, 2017 at 05:41:44AM +, Andrey Vagin wrote:
> Hi Josh,
> 
> 
> Now I see these two warnings on Linus' tree:
> 
> [1.902454] WARNING: stack recursion on stack type 1
> [1.902466] WARNING: can't dereference iret registers at cd089a12 
> for ip entry_SYSCALL_64_fastpath+0x5/0x86

This still looks like the same issue where ORC is getting confused by
paravirt patching.  Unfortunately the patches which fix this got
preempted by other work again.  I haven't forgotten about it.

2017 is out the window, but hopefully in January I'll get a chance to
revive the patches.

-- 
Josh

Re: [PATCH] CIFS: SMBD: fix configurations with INFINIBAND=m

[Stefan Metzmacher]

Am 19.12.2017 um 22:21 schrieb Long Li via samba-technical:
>>  depends on CIFS && INFINIBAND
>> +depends on CIFS=m || INFINIBAND=y
> 
> How about we change them to
> 
> depends on CIFS=m && INFINIBAND || CIFS=y && INFINIBAND=y
> 
> This makes it easy to read.

I like it :-)

metze




signature.asc
Description: OpenPGP digital signature

Re: [PATCH] CIFS: SMBD: fix configurations with INFINIBAND=m

[Stefan Metzmacher]

Am 19.12.2017 um 22:21 schrieb Long Li via samba-technical:
>>  depends on CIFS && INFINIBAND
>> +depends on CIFS=m || INFINIBAND=y
> 
> How about we change them to
> 
> depends on CIFS=m && INFINIBAND || CIFS=y && INFINIBAND=y
> 
> This makes it easy to read.

I like it :-)

metze




signature.asc
Description: OpenPGP digital signature

Re: [PATCH v3 14/16] phy: Add notify_speed callback

[Manu Gautam]

Hi,


On 12/20/2017 11:19 AM, Kishon Vijay Abraham I wrote:
> Hi,
>
> On Tuesday 12 December 2017 08:54 PM, Manu Gautam wrote:
>> Hi,
>>
>>
>> On 12/12/2017 5:13 PM, Kishon Vijay Abraham I wrote:
>>> Hi,
>>>
>>> On Tuesday 21 November 2017 02:53 PM, Manu Gautam wrote:
 QCOM USB PHYs can monitor resume/remote-wakeup event in
 suspended state. However PHY driver must know current
 operational speed of PHY in order to set correct polarity of
 wakeup events for detection. E.g. QUSB2 PHY monitors DP/DM
 signals depending on speed is LS or FS/HS to detect resume.
 Similarly QMP USB3 PHY in SS mode should monitor RX
 terminations attach/detach and LFPS events depending on
 SSPHY is active or not.
> Why not use a notification mechanism instead of adding new APIs in phy-core.
> This will only bloat phy-core with APIs for a particular platform.

Do you mean notifier_chains ?
When we have multiple instances of USB PHYs then notifier chains are not
of much help. For any platform glue or PHY driver it will be very difficult to
figure out if notification received for speed was for same phy/bus or a
different one.
Using PHY callbacks looked more elegant to me. Additionally PHY drivers
can also use this info decide power management policy e.g. if speed is
INVALID then it means PHY is not in a session and it can enter deepest
low power state.
Additionally if you prefer set_speed name over notify_speed then I am
ok with that as well so that it sounds more generic.

>
> Thanks
> Kishon
>

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

Re: [PATCH v3 14/16] phy: Add notify_speed callback

[Manu Gautam]

Hi,


On 12/20/2017 11:19 AM, Kishon Vijay Abraham I wrote:
> Hi,
>
> On Tuesday 12 December 2017 08:54 PM, Manu Gautam wrote:
>> Hi,
>>
>>
>> On 12/12/2017 5:13 PM, Kishon Vijay Abraham I wrote:
>>> Hi,
>>>
>>> On Tuesday 21 November 2017 02:53 PM, Manu Gautam wrote:
 QCOM USB PHYs can monitor resume/remote-wakeup event in
 suspended state. However PHY driver must know current
 operational speed of PHY in order to set correct polarity of
 wakeup events for detection. E.g. QUSB2 PHY monitors DP/DM
 signals depending on speed is LS or FS/HS to detect resume.
 Similarly QMP USB3 PHY in SS mode should monitor RX
 terminations attach/detach and LFPS events depending on
 SSPHY is active or not.
> Why not use a notification mechanism instead of adding new APIs in phy-core.
> This will only bloat phy-core with APIs for a particular platform.

Do you mean notifier_chains ?
When we have multiple instances of USB PHYs then notifier chains are not
of much help. For any platform glue or PHY driver it will be very difficult to
figure out if notification received for speed was for same phy/bus or a
different one.
Using PHY callbacks looked more elegant to me. Additionally PHY drivers
can also use this info decide power management policy e.g. if speed is
INVALID then it means PHY is not in a session and it can enter deepest
low power state.
Additionally if you prefer set_speed name over notify_speed then I am
ok with that as well so that it sounds more generic.

>
> Thanks
> Kishon
>

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

Re: [PATCH v5 15/15] devicetree: bindings: Document qcom,pvs

[Viresh Kumar]

On 20-12-17, 11:55, Sricharan R wrote:
> >> +  opp-14 {
> >> +  opp-hz = /bits/ 64 <14>;
> >> +  opp-microvolt-speed0-pvs0-v0 = <125>;
> > 
> > Why speed0 and v0 in all the names ?
> > 
> 
>  Ya, all the three (speed, pvs and version) are read from efuse. So all the 
> three
>  can vary.

Okay, so may be in the example you should have a mix of all the
combinations to show how these things work ? You only showed values
for a single efuse configuration currently.

-- 
viresh

Re: [PATCH v5 15/15] devicetree: bindings: Document qcom,pvs

[Viresh Kumar]

On 20-12-17, 11:55, Sricharan R wrote:
> >> +  opp-14 {
> >> +  opp-hz = /bits/ 64 <14>;
> >> +  opp-microvolt-speed0-pvs0-v0 = <125>;
> > 
> > Why speed0 and v0 in all the names ?
> > 
> 
>  Ya, all the three (speed, pvs and version) are read from efuse. So all the 
> three
>  can vary.

Okay, so may be in the example you should have a mix of all the
combinations to show how these things work ? You only showed values
for a single efuse configuration currently.

-- 
viresh

Re: [PATCH v5 15/15] devicetree: bindings: Document qcom,pvs

[Sricharan R]

Hi Viresh,

On 12/20/2017 8:56 AM, Viresh Kumar wrote:
> On 19-12-17, 21:25, Sricharan R wrote:
>> +cpu@0 {
>> +compatible = "qcom,krait";
>> +enable-method = "qcom,kpss-acc-v1";
>> +device_type = "cpu";
>> +reg = <0>;
>> +qcom,acc = <>;
>> +qcom,saw = <>;
>> +clocks = < 0>;
>> +clock-names = "cpu";
>> +cpu-supply = <_s2a>;
>> +operating-points-v2 = <_opp_table>;
>> +};
>> +
>> +qcom,pvs {
>> +qcom,pvs-format-a;
>> +};
> 
> Not sure what Rob is going to say on that :)
> 

 Yes. Would be good to know the best way.

>> +
>> +
>> +cpu_opp_table: opp_table {
>> +compatible = "operating-points-v2";
>> +
>> +/*
>> + * Missing opp-shared property means CPUs switch DVFS states
>> + * independently.
>> + */
>> +
>> +opp-14 {
>> +opp-hz = /bits/ 64 <14>;
>> +opp-microvolt-speed0-pvs0-v0 = <125>;
> 
> Why speed0 and v0 in all the names ?
> 

 Ya, all the three (speed, pvs and version) are read from efuse. So all the 
three
 can vary.

Regards,
 Sricharan

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

Re: [PATCH v5 15/15] devicetree: bindings: Document qcom,pvs

[Sricharan R]

Hi Viresh,

On 12/20/2017 8:56 AM, Viresh Kumar wrote:
> On 19-12-17, 21:25, Sricharan R wrote:
>> +cpu@0 {
>> +compatible = "qcom,krait";
>> +enable-method = "qcom,kpss-acc-v1";
>> +device_type = "cpu";
>> +reg = <0>;
>> +qcom,acc = <>;
>> +qcom,saw = <>;
>> +clocks = < 0>;
>> +clock-names = "cpu";
>> +cpu-supply = <_s2a>;
>> +operating-points-v2 = <_opp_table>;
>> +};
>> +
>> +qcom,pvs {
>> +qcom,pvs-format-a;
>> +};
> 
> Not sure what Rob is going to say on that :)
> 

 Yes. Would be good to know the best way.

>> +
>> +
>> +cpu_opp_table: opp_table {
>> +compatible = "operating-points-v2";
>> +
>> +/*
>> + * Missing opp-shared property means CPUs switch DVFS states
>> + * independently.
>> + */
>> +
>> +opp-14 {
>> +opp-hz = /bits/ 64 <14>;
>> +opp-microvolt-speed0-pvs0-v0 = <125>;
> 
> Why speed0 and v0 in all the names ?
> 

 Ya, all the three (speed, pvs and version) are read from efuse. So all the 
three
 can vary.

Regards,
 Sricharan

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

[PATCH v6 3/3] eeprom: at24: switch to device-managed version of i2c_new_dummy

[Heiner Kallweit]

Make use of recently introduced device-managed version of
i2c_new_dummy to simplify the code.

Signed-off-by: Heiner Kallweit 
---
v2:
- small improvements regarding code readability
v3:
- no changes
v4:
- no changes
v5:
- no changes
v6:
- rebased
---
 drivers/misc/eeprom/at24.c | 32 +++-
 1 file changed, 11 insertions(+), 21 deletions(-)

diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c
index b44a3d2b2..6232765bb 100644
--- a/drivers/misc/eeprom/at24.c
+++ b/drivers/misc/eeprom/at24.c
@@ -626,21 +626,19 @@ static int at24_probe(struct i2c_client *client, const 
struct i2c_device_id *id)
 
/* use dummy devices for multiple-address chips */
for (i = 1; i < num_addresses; i++) {
-   at24->client[i].client = i2c_new_dummy(client->adapter,
-  client->addr + i);
-   if (!at24->client[i].client) {
+   struct at24_client *cl;
+
+   cl = >client[i];
+   cl->client = devm_i2c_new_dummy(>dev, client->adapter,
+   client->addr + i);
+   if (IS_ERR(cl->client)) {
dev_err(>dev, "address 0x%02x unavailable\n",
-   client->addr + i);
-   err = -EADDRINUSE;
-   goto err_clients;
-   }
-   at24->client[i].regmap = devm_regmap_init_i2c(
-   at24->client[i].client,
-   _config);
-   if (IS_ERR(at24->client[i].regmap)) {
-   err = PTR_ERR(at24->client[i].regmap);
-   goto err_clients;
+   client->addr + i);
+   return PTR_ERR(cl->client);
}
+   cl->regmap = devm_regmap_init_i2c(cl->client, _config);
+   if (IS_ERR(cl->regmap))
+   return PTR_ERR(cl->regmap);
}
 
i2c_set_clientdata(client, at24);
@@ -692,10 +690,6 @@ static int at24_probe(struct i2c_client *client, const 
struct i2c_device_id *id)
return 0;
 
 err_clients:
-   for (i = 1; i < num_addresses; i++)
-   if (at24->client[i].client)
-   i2c_unregister_device(at24->client[i].client);
-
pm_runtime_disable(>dev);
 
return err;
@@ -704,15 +698,11 @@ static int at24_probe(struct i2c_client *client, const 
struct i2c_device_id *id)
 static int at24_remove(struct i2c_client *client)
 {
struct at24_data *at24;
-   int i;
 
at24 = i2c_get_clientdata(client);
 
nvmem_unregister(at24->nvmem);
 
-   for (i = 1; i < at24->num_addresses; i++)
-   i2c_unregister_device(at24->client[i].client);
-
pm_runtime_disable(>dev);
pm_runtime_set_suspended(>dev);
 
-- 
2.15.1

[PATCH v6 3/3] eeprom: at24: switch to device-managed version of i2c_new_dummy

[Heiner Kallweit]

Make use of recently introduced device-managed version of
i2c_new_dummy to simplify the code.

Signed-off-by: Heiner Kallweit 
---
v2:
- small improvements regarding code readability
v3:
- no changes
v4:
- no changes
v5:
- no changes
v6:
- rebased
---
 drivers/misc/eeprom/at24.c | 32 +++-
 1 file changed, 11 insertions(+), 21 deletions(-)

diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c
index b44a3d2b2..6232765bb 100644
--- a/drivers/misc/eeprom/at24.c
+++ b/drivers/misc/eeprom/at24.c
@@ -626,21 +626,19 @@ static int at24_probe(struct i2c_client *client, const 
struct i2c_device_id *id)
 
/* use dummy devices for multiple-address chips */
for (i = 1; i < num_addresses; i++) {
-   at24->client[i].client = i2c_new_dummy(client->adapter,
-  client->addr + i);
-   if (!at24->client[i].client) {
+   struct at24_client *cl;
+
+   cl = >client[i];
+   cl->client = devm_i2c_new_dummy(>dev, client->adapter,
+   client->addr + i);
+   if (IS_ERR(cl->client)) {
dev_err(>dev, "address 0x%02x unavailable\n",
-   client->addr + i);
-   err = -EADDRINUSE;
-   goto err_clients;
-   }
-   at24->client[i].regmap = devm_regmap_init_i2c(
-   at24->client[i].client,
-   _config);
-   if (IS_ERR(at24->client[i].regmap)) {
-   err = PTR_ERR(at24->client[i].regmap);
-   goto err_clients;
+   client->addr + i);
+   return PTR_ERR(cl->client);
}
+   cl->regmap = devm_regmap_init_i2c(cl->client, _config);
+   if (IS_ERR(cl->regmap))
+   return PTR_ERR(cl->regmap);
}
 
i2c_set_clientdata(client, at24);
@@ -692,10 +690,6 @@ static int at24_probe(struct i2c_client *client, const 
struct i2c_device_id *id)
return 0;
 
 err_clients:
-   for (i = 1; i < num_addresses; i++)
-   if (at24->client[i].client)
-   i2c_unregister_device(at24->client[i].client);
-
pm_runtime_disable(>dev);
 
return err;
@@ -704,15 +698,11 @@ static int at24_probe(struct i2c_client *client, const 
struct i2c_device_id *id)
 static int at24_remove(struct i2c_client *client)
 {
struct at24_data *at24;
-   int i;
 
at24 = i2c_get_clientdata(client);
 
nvmem_unregister(at24->nvmem);
 
-   for (i = 1; i < at24->num_addresses; i++)
-   i2c_unregister_device(at24->client[i].client);
-
pm_runtime_disable(>dev);
pm_runtime_set_suspended(>dev);
 
-- 
2.15.1

[PATCH v6 1/3] i2c: core: improve return value handling of i2c_new_device and i2c_new_dummy

[Heiner Kallweit]

Currently i2c_new_device and i2c_new_dummy return just NULL in error
case although they have more error details internally. Therefore move
the functionality into new functions returning detailed errors and
add wrappers for compatibilty with the current API.

This allows to use these functions with detailed error codes within
the i2c core or for API extensions.

Signed-off-by: Heiner Kallweit 
Reviewed-by: Bartosz Golaszewski 
---
v3:
- prefix i2c_new_device and i2c_new_dummy with two underscores
  instead one
v4:
- add missing kernel doc
- add reviewed-by
v5:
- fix a copy & paste error in a kernel doc comment
v6:
- no changes
---
 drivers/i2c/i2c-core-base.c | 70 -
 1 file changed, 57 insertions(+), 13 deletions(-)

diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
index bb34a5d41..cb3f29fb8 100644
--- a/drivers/i2c/i2c-core-base.c
+++ b/drivers/i2c/i2c-core-base.c
@@ -656,7 +656,7 @@ static int i2c_dev_irq_from_resources(const struct resource 
*resources,
 }
 
 /**
- * i2c_new_device - instantiate an i2c device
+ * __i2c_new_device - instantiate an i2c device
  * @adap: the adapter managing the device
  * @info: describes one I2C device; bus_num is ignored
  * Context: can sleep
@@ -669,17 +669,17 @@ static int i2c_dev_irq_from_resources(const struct 
resource *resources,
  * before any i2c_adapter could exist.
  *
  * This returns the new i2c client, which may be saved for later use with
- * i2c_unregister_device(); or NULL to indicate an error.
+ * i2c_unregister_device(); or an ERR_PTR to indicate an error.
  */
-struct i2c_client *
-i2c_new_device(struct i2c_adapter *adap, struct i2c_board_info const *info)
+static struct i2c_client *
+__i2c_new_device(struct i2c_adapter *adap, struct i2c_board_info const *info)
 {
struct i2c_client   *client;
int status;
 
client = kzalloc(sizeof *client, GFP_KERNEL);
if (!client)
-   return NULL;
+   return ERR_PTR(-ENOMEM);
 
client->adapter = adap;
 
@@ -746,7 +746,29 @@ i2c_new_device(struct i2c_adapter *adap, struct 
i2c_board_info const *info)
client->name, client->addr, status);
 out_err_silent:
kfree(client);
-   return NULL;
+   return ERR_PTR(status);
+}
+
+/**
+ * i2c_new_device - instantiate an i2c device
+ * @adap: the adapter managing the device
+ * @info: describes one I2C device; bus_num is ignored
+ * Context: can sleep
+ *
+ * This function has the same functionality like __i2_new_device, it just
+ * returns NULL instead of an ERR_PTR in case of an error for compatibility
+ * with current I2C API.
+ *
+ * This returns the new i2c client, which may be saved for later use with
+ * i2c_unregister_device(); or NULL to indicate an error.
+ */
+struct i2c_client *
+i2c_new_device(struct i2c_adapter *adap, struct i2c_board_info const *info)
+{
+   struct i2c_client *ret;
+
+   ret = __i2c_new_device(adap, info);
+   return IS_ERR(ret) ? NULL : ret;
 }
 EXPORT_SYMBOL_GPL(i2c_new_device);
 
@@ -793,7 +815,7 @@ static struct i2c_driver dummy_driver = {
 };
 
 /**
- * i2c_new_dummy - return a new i2c device bound to a dummy driver
+ * __i2c_new_dummy - return a new i2c device bound to a dummy driver
  * @adapter: the adapter managing the device
  * @address: seven bit address to be used
  * Context: can sleep
@@ -808,15 +830,37 @@ static struct i2c_driver dummy_driver = {
  * different driver.
  *
  * This returns the new i2c client, which should be saved for later use with
- * i2c_unregister_device(); or NULL to indicate an error.
+ * i2c_unregister_device(); or an ERR_PTR to indicate an error.
  */
-struct i2c_client *i2c_new_dummy(struct i2c_adapter *adapter, u16 address)
+static struct i2c_client *
+__i2c_new_dummy(struct i2c_adapter *adapter, u16 address)
 {
struct i2c_board_info info = {
I2C_BOARD_INFO("dummy", address),
};
 
-   return i2c_new_device(adapter, );
+   return __i2c_new_device(adapter, );
+}
+
+/**
+ * i2c_new_dummy - return a new i2c device bound to a dummy driver
+ * @adapter: the adapter managing the device
+ * @address: seven bit address to be used
+ * Context: can sleep
+ *
+ * This function has the same functionality like __i2_new_dummy, it just
+ * returns NULL instead of an ERR_PTR in case of an error for compatibility
+ * with current I2C API.
+ *
+ * This returns the new i2c client, which should be saved for later use with
+ * i2c_unregister_device(); or NULL to indicate an error.
+ */
+struct i2c_client *i2c_new_dummy(struct i2c_adapter *adapter, u16 address)
+{
+   struct i2c_client *ret;
+
+   ret = __i2c_new_dummy(adapter, address);
+   return IS_ERR(ret) ? NULL : ret;
 }
 EXPORT_SYMBOL_GPL(i2c_new_dummy);
 
@@ -939,9 +983,9 @@ i2c_sysfs_new_device(struct device *dev, struct 
device_attribute *attr,
info.flags |= 

[PATCH v6 1/3] i2c: core: improve return value handling of i2c_new_device and i2c_new_dummy

[Heiner Kallweit]

Currently i2c_new_device and i2c_new_dummy return just NULL in error
case although they have more error details internally. Therefore move
the functionality into new functions returning detailed errors and
add wrappers for compatibilty with the current API.

This allows to use these functions with detailed error codes within
the i2c core or for API extensions.

Signed-off-by: Heiner Kallweit 
Reviewed-by: Bartosz Golaszewski 
---
v3:
- prefix i2c_new_device and i2c_new_dummy with two underscores
  instead one
v4:
- add missing kernel doc
- add reviewed-by
v5:
- fix a copy & paste error in a kernel doc comment
v6:
- no changes
---
 drivers/i2c/i2c-core-base.c | 70 -
 1 file changed, 57 insertions(+), 13 deletions(-)

diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
index bb34a5d41..cb3f29fb8 100644
--- a/drivers/i2c/i2c-core-base.c
+++ b/drivers/i2c/i2c-core-base.c
@@ -656,7 +656,7 @@ static int i2c_dev_irq_from_resources(const struct resource 
*resources,
 }
 
 /**
- * i2c_new_device - instantiate an i2c device
+ * __i2c_new_device - instantiate an i2c device
  * @adap: the adapter managing the device
  * @info: describes one I2C device; bus_num is ignored
  * Context: can sleep
@@ -669,17 +669,17 @@ static int i2c_dev_irq_from_resources(const struct 
resource *resources,
  * before any i2c_adapter could exist.
  *
  * This returns the new i2c client, which may be saved for later use with
- * i2c_unregister_device(); or NULL to indicate an error.
+ * i2c_unregister_device(); or an ERR_PTR to indicate an error.
  */
-struct i2c_client *
-i2c_new_device(struct i2c_adapter *adap, struct i2c_board_info const *info)
+static struct i2c_client *
+__i2c_new_device(struct i2c_adapter *adap, struct i2c_board_info const *info)
 {
struct i2c_client   *client;
int status;
 
client = kzalloc(sizeof *client, GFP_KERNEL);
if (!client)
-   return NULL;
+   return ERR_PTR(-ENOMEM);
 
client->adapter = adap;
 
@@ -746,7 +746,29 @@ i2c_new_device(struct i2c_adapter *adap, struct 
i2c_board_info const *info)
client->name, client->addr, status);
 out_err_silent:
kfree(client);
-   return NULL;
+   return ERR_PTR(status);
+}
+
+/**
+ * i2c_new_device - instantiate an i2c device
+ * @adap: the adapter managing the device
+ * @info: describes one I2C device; bus_num is ignored
+ * Context: can sleep
+ *
+ * This function has the same functionality like __i2_new_device, it just
+ * returns NULL instead of an ERR_PTR in case of an error for compatibility
+ * with current I2C API.
+ *
+ * This returns the new i2c client, which may be saved for later use with
+ * i2c_unregister_device(); or NULL to indicate an error.
+ */
+struct i2c_client *
+i2c_new_device(struct i2c_adapter *adap, struct i2c_board_info const *info)
+{
+   struct i2c_client *ret;
+
+   ret = __i2c_new_device(adap, info);
+   return IS_ERR(ret) ? NULL : ret;
 }
 EXPORT_SYMBOL_GPL(i2c_new_device);
 
@@ -793,7 +815,7 @@ static struct i2c_driver dummy_driver = {
 };
 
 /**
- * i2c_new_dummy - return a new i2c device bound to a dummy driver
+ * __i2c_new_dummy - return a new i2c device bound to a dummy driver
  * @adapter: the adapter managing the device
  * @address: seven bit address to be used
  * Context: can sleep
@@ -808,15 +830,37 @@ static struct i2c_driver dummy_driver = {
  * different driver.
  *
  * This returns the new i2c client, which should be saved for later use with
- * i2c_unregister_device(); or NULL to indicate an error.
+ * i2c_unregister_device(); or an ERR_PTR to indicate an error.
  */
-struct i2c_client *i2c_new_dummy(struct i2c_adapter *adapter, u16 address)
+static struct i2c_client *
+__i2c_new_dummy(struct i2c_adapter *adapter, u16 address)
 {
struct i2c_board_info info = {
I2C_BOARD_INFO("dummy", address),
};
 
-   return i2c_new_device(adapter, );
+   return __i2c_new_device(adapter, );
+}
+
+/**
+ * i2c_new_dummy - return a new i2c device bound to a dummy driver
+ * @adapter: the adapter managing the device
+ * @address: seven bit address to be used
+ * Context: can sleep
+ *
+ * This function has the same functionality like __i2_new_dummy, it just
+ * returns NULL instead of an ERR_PTR in case of an error for compatibility
+ * with current I2C API.
+ *
+ * This returns the new i2c client, which should be saved for later use with
+ * i2c_unregister_device(); or NULL to indicate an error.
+ */
+struct i2c_client *i2c_new_dummy(struct i2c_adapter *adapter, u16 address)
+{
+   struct i2c_client *ret;
+
+   ret = __i2c_new_dummy(adapter, address);
+   return IS_ERR(ret) ? NULL : ret;
 }
 EXPORT_SYMBOL_GPL(i2c_new_dummy);
 
@@ -939,9 +983,9 @@ i2c_sysfs_new_device(struct device *dev, struct 
device_attribute *attr,
info.flags |= I2C_CLIENT_SLAVE;
}
 
-   client = 

[PATCH v6 2/3] i2c: core: add device-managed version of i2c_new_dummy

[Heiner Kallweit]

i2c_new_dummy is typically called from the probe function of the
driver for the primary i2c client. It requires calls to
i2c_unregister_device in the error path of the probe function and
in the remove function.
This can be simplified by introducing a device-managed version.

Note the changed error case return value type:
i2c_new_dummy returns NULL whilst devm_new_i2c_dummy returns an ERR_PTR.

Signed-off-by: Heiner Kallweit 
---
v2:
- use new function _i2c_new_dummy with detailed error codes
v3:
- no changes
v4:
- reflect renaming to __i2c_new_dummy
v5:
- improve readability by adding struct i2c_dummy_devres
v6:
- add braces to function name in documentation
---
 Documentation/driver-model/devres.txt |  3 +++
 drivers/i2c/i2c-core-base.c   | 45 +++
 include/linux/i2c.h   |  3 +++
 3 files changed, 51 insertions(+)

diff --git a/Documentation/driver-model/devres.txt 
b/Documentation/driver-model/devres.txt
index c180045eb..22a40deed 100644
--- a/Documentation/driver-model/devres.txt
+++ b/Documentation/driver-model/devres.txt
@@ -259,6 +259,9 @@ GPIO
   devm_gpio_request_one()
   devm_gpio_free()
 
+I2C
+  devm_i2c_new_dummy()
+
 IIO
   devm_iio_device_alloc()
   devm_iio_device_free()
diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
index cb3f29fb8..4b05abbfa 100644
--- a/drivers/i2c/i2c-core-base.c
+++ b/drivers/i2c/i2c-core-base.c
@@ -864,6 +864,51 @@ struct i2c_client *i2c_new_dummy(struct i2c_adapter 
*adapter, u16 address)
 }
 EXPORT_SYMBOL_GPL(i2c_new_dummy);
 
+struct i2c_dummy_devres {
+   struct i2c_client *client;
+};
+
+static void devm_i2c_release_dummy(struct device *dev, void *res)
+{
+   struct i2c_dummy_devres *this = res;
+
+   i2c_unregister_device(this->client);
+}
+
+/**
+ * devm_i2c_new_dummy - return a new i2c device bound to a dummy driver
+ * @dev: device the managed resource is bound to
+ * @adapter: the adapter managing the device
+ * @address: seven bit address to be used
+ * Context: can sleep
+ *
+ * This is the device-managed version of i2c_new_dummy.
+ * Note the changed return value type: It returns the new i2c client
+ * or an ERR_PTR in case of an error.
+ */
+struct i2c_client *devm_i2c_new_dummy(struct device *dev,
+ struct i2c_adapter *adapter,
+ u16 address)
+{
+   struct i2c_dummy_devres *dr;
+   struct i2c_client *client;
+
+   dr = devres_alloc(devm_i2c_release_dummy, sizeof(*dr), GFP_KERNEL);
+   if (!dr)
+   return ERR_PTR(-ENOMEM);
+
+   client = __i2c_new_dummy(adapter, address);
+   if (IS_ERR(client)) {
+   devres_free(dr);
+   } else {
+   dr->client = client;
+   devres_add(dev, dr);
+   }
+
+   return client;
+}
+EXPORT_SYMBOL_GPL(devm_i2c_new_dummy);
+
 /**
  * i2c_new_secondary_device - Helper to get the instantiated secondary address
  * and create the associated device
diff --git a/include/linux/i2c.h b/include/linux/i2c.h
index 5d7f3c185..aca6ebbb8 100644
--- a/include/linux/i2c.h
+++ b/include/linux/i2c.h
@@ -441,6 +441,9 @@ extern int i2c_probe_func_quick_read(struct i2c_adapter *, 
unsigned short addr);
 extern struct i2c_client *
 i2c_new_dummy(struct i2c_adapter *adap, u16 address);
 
+extern struct i2c_client *
+devm_i2c_new_dummy(struct device *dev, struct i2c_adapter *adap, u16 address);
+
 extern struct i2c_client *
 i2c_new_secondary_device(struct i2c_client *client,
const char *name,
-- 
2.15.1

[PATCH v6 2/3] i2c: core: add device-managed version of i2c_new_dummy

[Heiner Kallweit]

i2c_new_dummy is typically called from the probe function of the
driver for the primary i2c client. It requires calls to
i2c_unregister_device in the error path of the probe function and
in the remove function.
This can be simplified by introducing a device-managed version.

Note the changed error case return value type:
i2c_new_dummy returns NULL whilst devm_new_i2c_dummy returns an ERR_PTR.

Signed-off-by: Heiner Kallweit 
---
v2:
- use new function _i2c_new_dummy with detailed error codes
v3:
- no changes
v4:
- reflect renaming to __i2c_new_dummy
v5:
- improve readability by adding struct i2c_dummy_devres
v6:
- add braces to function name in documentation
---
 Documentation/driver-model/devres.txt |  3 +++
 drivers/i2c/i2c-core-base.c   | 45 +++
 include/linux/i2c.h   |  3 +++
 3 files changed, 51 insertions(+)

diff --git a/Documentation/driver-model/devres.txt 
b/Documentation/driver-model/devres.txt
index c180045eb..22a40deed 100644
--- a/Documentation/driver-model/devres.txt
+++ b/Documentation/driver-model/devres.txt
@@ -259,6 +259,9 @@ GPIO
   devm_gpio_request_one()
   devm_gpio_free()
 
+I2C
+  devm_i2c_new_dummy()
+
 IIO
   devm_iio_device_alloc()
   devm_iio_device_free()
diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
index cb3f29fb8..4b05abbfa 100644
--- a/drivers/i2c/i2c-core-base.c
+++ b/drivers/i2c/i2c-core-base.c
@@ -864,6 +864,51 @@ struct i2c_client *i2c_new_dummy(struct i2c_adapter 
*adapter, u16 address)
 }
 EXPORT_SYMBOL_GPL(i2c_new_dummy);
 
+struct i2c_dummy_devres {
+   struct i2c_client *client;
+};
+
+static void devm_i2c_release_dummy(struct device *dev, void *res)
+{
+   struct i2c_dummy_devres *this = res;
+
+   i2c_unregister_device(this->client);
+}
+
+/**
+ * devm_i2c_new_dummy - return a new i2c device bound to a dummy driver
+ * @dev: device the managed resource is bound to
+ * @adapter: the adapter managing the device
+ * @address: seven bit address to be used
+ * Context: can sleep
+ *
+ * This is the device-managed version of i2c_new_dummy.
+ * Note the changed return value type: It returns the new i2c client
+ * or an ERR_PTR in case of an error.
+ */
+struct i2c_client *devm_i2c_new_dummy(struct device *dev,
+ struct i2c_adapter *adapter,
+ u16 address)
+{
+   struct i2c_dummy_devres *dr;
+   struct i2c_client *client;
+
+   dr = devres_alloc(devm_i2c_release_dummy, sizeof(*dr), GFP_KERNEL);
+   if (!dr)
+   return ERR_PTR(-ENOMEM);
+
+   client = __i2c_new_dummy(adapter, address);
+   if (IS_ERR(client)) {
+   devres_free(dr);
+   } else {
+   dr->client = client;
+   devres_add(dev, dr);
+   }
+
+   return client;
+}
+EXPORT_SYMBOL_GPL(devm_i2c_new_dummy);
+
 /**
  * i2c_new_secondary_device - Helper to get the instantiated secondary address
  * and create the associated device
diff --git a/include/linux/i2c.h b/include/linux/i2c.h
index 5d7f3c185..aca6ebbb8 100644
--- a/include/linux/i2c.h
+++ b/include/linux/i2c.h
@@ -441,6 +441,9 @@ extern int i2c_probe_func_quick_read(struct i2c_adapter *, 
unsigned short addr);
 extern struct i2c_client *
 i2c_new_dummy(struct i2c_adapter *adap, u16 address);
 
+extern struct i2c_client *
+devm_i2c_new_dummy(struct device *dev, struct i2c_adapter *adap, u16 address);
+
 extern struct i2c_client *
 i2c_new_secondary_device(struct i2c_client *client,
const char *name,
-- 
2.15.1

Re: [Intel-wired-lan] v4.15-rc2 on thinkpad x60: ethernet stopped working

[Neftin, Sasha]

On 12/18/2017 17:50, Neftin, Sasha wrote:

On 12/18/2017 13:58, Pavel Machek wrote:

On Mon 2017-12-18 13:24:40, Neftin, Sasha wrote:

On 12/18/2017 12:26, Pavel Machek wrote:

Hi!


In v4.15-rc2+, network manager can not see my ethernet card, and
manual attempts to ifconfig it up did not really help, either.

Card is:

02:00.0 Ethernet controller: Intel Corporation 82573L Gigabit 
Ethernet

Controller



Any ideas ?

Yes , 19110cfbb34d4af0cdfe14cd243f3b09dc95b013 broke it.

See:
https://bugzilla.kernel.org/show_bug.cgi?id=198047

Fix there :
https://marc.info/?l=linux-kernel=151272209903675=2

I don't see the patch in latest mainline. Not having ethernet
is... somehow annoying. What is going on there?
Generally speaking, e1000 maintainence has been handled very 
poorly over

the past few years, I have to say.

Fixes take forever to propagate even when someone other than the
maintainer provides a working and tested fix, just like this case.

Jeff, please take e1000 maintainence seriously and get these critical
bug fixes propagated.

No response AFAICT. I guess I should test reverting
19110cfbb34d4af0cdfe14cd243f3b09dc95b013, then ask you for revert?

Hello Pavel,

Before ask for reverting 19110cfbb..., please, check if follow patch of
Benjamin work for you http://patchwork.ozlabs.org/patch/846825/

Jacob said, in another email:

# Digging into this, the problem is complicated. The original bug
# assumed behavior of the .check_for_link call, which is universally not
# implemented.
#
# I think the correct fix is to revert 19110cfbb34d ("e1000e: Separate
# signaling for link check/link up", 2017-10-10) and find a more 
proper solution.


...which makes me think that revert is preffered?

    Pavel

Pavel, before ask for revert - let's check Benjamin's patch following 
to his previous patch. Previous patch was not competed and latest one 
come to complete changes.


___
Intel-wired-lan mailing list
intel-wired-...@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan


Pavel, any update? Is Benjamin's last patch solved your network problem?

Re: [Intel-wired-lan] v4.15-rc2 on thinkpad x60: ethernet stopped working

[Neftin, Sasha]

On 12/18/2017 17:50, Neftin, Sasha wrote:

On 12/18/2017 13:58, Pavel Machek wrote:

On Mon 2017-12-18 13:24:40, Neftin, Sasha wrote:

On 12/18/2017 12:26, Pavel Machek wrote:

Hi!


In v4.15-rc2+, network manager can not see my ethernet card, and
manual attempts to ifconfig it up did not really help, either.

Card is:

02:00.0 Ethernet controller: Intel Corporation 82573L Gigabit 
Ethernet

Controller



Any ideas ?

Yes , 19110cfbb34d4af0cdfe14cd243f3b09dc95b013 broke it.

See:
https://bugzilla.kernel.org/show_bug.cgi?id=198047

Fix there :
https://marc.info/?l=linux-kernel=151272209903675=2

I don't see the patch in latest mainline. Not having ethernet
is... somehow annoying. What is going on there?
Generally speaking, e1000 maintainence has been handled very 
poorly over

the past few years, I have to say.

Fixes take forever to propagate even when someone other than the
maintainer provides a working and tested fix, just like this case.

Jeff, please take e1000 maintainence seriously and get these critical
bug fixes propagated.

No response AFAICT. I guess I should test reverting
19110cfbb34d4af0cdfe14cd243f3b09dc95b013, then ask you for revert?

Hello Pavel,

Before ask for reverting 19110cfbb..., please, check if follow patch of
Benjamin work for you http://patchwork.ozlabs.org/patch/846825/

Jacob said, in another email:

# Digging into this, the problem is complicated. The original bug
# assumed behavior of the .check_for_link call, which is universally not
# implemented.
#
# I think the correct fix is to revert 19110cfbb34d ("e1000e: Separate
# signaling for link check/link up", 2017-10-10) and find a more 
proper solution.


...which makes me think that revert is preffered?

    Pavel

Pavel, before ask for revert - let's check Benjamin's patch following 
to his previous patch. Previous patch was not competed and latest one 
come to complete changes.


___
Intel-wired-lan mailing list
intel-wired-...@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan


Pavel, any update? Is Benjamin's last patch solved your network problem?

Re: [PATCH v1] drm/tegra: gem: Correct iommu_map_sg() error checking

[kbuild test robot]

Hi Dmitry,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on tegra/for-next]
[also build test WARNING on v4.15-rc4 next-20171220]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Dmitry-Osipenko/drm-tegra-gem-Correct-iommu_map_sg-error-checking/20171220-123700
base:   https://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git for-next
config: arm64-allmodconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm64 

All warnings (new ones prefixed by >>):

   drivers/gpu/drm/tegra/gem.c: In function 'tegra_bo_iommu_map':
>> drivers/gpu/drm/tegra/gem.c:131:58: warning: format '%zd' expects argument 
>> of type 'signed size_t', but argument 3 has type 'int' [-Wformat=]
  dev_err(tegra->drm->dev, "out of I/O virtual memory: %zd\n",
   ~~^
   %d

vim +131 drivers/gpu/drm/tegra/gem.c

de2ba664c drivers/gpu/host1x/drm/gem.c Arto Merilainen 2013-03-22  113  
df06b759f drivers/gpu/drm/tegra/gem.c  Thierry Reding  2014-06-26  114  static 
int tegra_bo_iommu_map(struct tegra_drm *tegra, struct tegra_bo *bo)
df06b759f drivers/gpu/drm/tegra/gem.c  Thierry Reding  2014-06-26  115  {
df06b759f drivers/gpu/drm/tegra/gem.c  Thierry Reding  2014-06-26  116  
int prot = IOMMU_READ | IOMMU_WRITE;
e1ad592fa drivers/gpu/drm/tegra/gem.c  Dmitry Osipenko 2017-12-17  117  
int err;
df06b759f drivers/gpu/drm/tegra/gem.c  Thierry Reding  2014-06-26  118  
df06b759f drivers/gpu/drm/tegra/gem.c  Thierry Reding  2014-06-26  119  
if (bo->mm)
df06b759f drivers/gpu/drm/tegra/gem.c  Thierry Reding  2014-06-26  120  
return -EBUSY;
df06b759f drivers/gpu/drm/tegra/gem.c  Thierry Reding  2014-06-26  121  
df06b759f drivers/gpu/drm/tegra/gem.c  Thierry Reding  2014-06-26  122  
bo->mm = kzalloc(sizeof(*bo->mm), GFP_KERNEL);
df06b759f drivers/gpu/drm/tegra/gem.c  Thierry Reding  2014-06-26  123  
if (!bo->mm)
df06b759f drivers/gpu/drm/tegra/gem.c  Thierry Reding  2014-06-26  124  
return -ENOMEM;
df06b759f drivers/gpu/drm/tegra/gem.c  Thierry Reding  2014-06-26  125  
347ad49d3 drivers/gpu/drm/tegra/gem.c  Thierry Reding  2017-03-09  126  
mutex_lock(>mm_lock);
347ad49d3 drivers/gpu/drm/tegra/gem.c  Thierry Reding  2017-03-09  127  
4e64e5539 drivers/gpu/drm/tegra/gem.c  Chris Wilson2017-02-02  128  
err = drm_mm_insert_node_generic(>mm,
4e64e5539 drivers/gpu/drm/tegra/gem.c  Chris Wilson2017-02-02  129  
 bo->mm, bo->gem.size, PAGE_SIZE, 0, 0);
df06b759f drivers/gpu/drm/tegra/gem.c  Thierry Reding  2014-06-26  130  
if (err < 0) {
df06b759f drivers/gpu/drm/tegra/gem.c  Thierry Reding  2014-06-26 @131  
dev_err(tegra->drm->dev, "out of I/O virtual memory: %zd\n",
df06b759f drivers/gpu/drm/tegra/gem.c  Thierry Reding  2014-06-26  132  
err);
347ad49d3 drivers/gpu/drm/tegra/gem.c  Thierry Reding  2017-03-09  133  
goto unlock;
df06b759f drivers/gpu/drm/tegra/gem.c  Thierry Reding  2014-06-26  134  
}
df06b759f drivers/gpu/drm/tegra/gem.c  Thierry Reding  2014-06-26  135  
df06b759f drivers/gpu/drm/tegra/gem.c  Thierry Reding  2014-06-26  136  
bo->paddr = bo->mm->start;
df06b759f drivers/gpu/drm/tegra/gem.c  Thierry Reding  2014-06-26  137  
e1ad592fa drivers/gpu/drm/tegra/gem.c  Dmitry Osipenko 2017-12-17  138  
bo->size = iommu_map_sg(tegra->domain, bo->paddr, bo->sgt->sgl,
df06b759f drivers/gpu/drm/tegra/gem.c  Thierry Reding  2014-06-26  139  
bo->sgt->nents, prot);
e1ad592fa drivers/gpu/drm/tegra/gem.c  Dmitry Osipenko 2017-12-17  140  
if (!bo->size) {
e1ad592fa drivers/gpu/drm/tegra/gem.c  Dmitry Osipenko 2017-12-17  141  
dev_err(tegra->drm->dev, "failed to map buffer\n");
e1ad592fa drivers/gpu/drm/tegra/gem.c  Dmitry Osipenko 2017-12-17  142  
err = -ENOMEM;
df06b759f drivers/gpu/drm/tegra/gem.c  Thierry Reding  2014-06-26  143  
goto remove;
df06b759f drivers/gpu/drm/tegra/gem.c  Thierry Reding  2014-06-26  144  
}
df06b759f drivers/gpu/drm/tegra/gem.c  Thierry Reding  2014-06-26  145  
347ad49d3 drivers/gpu/drm/tegra/gem.c  Thierry Reding  2017-03-09  146  
mutex_unlock(>mm_lock);
347ad49d3 drivers/gpu/drm/tegra/gem.c  Thierry Reding  2017-03-09  147  
df06b759f drivers/gpu/drm/tegra/gem.c  Thierry Reding  2014-06-26  148  
return 0;
df06b759f drivers/gpu/drm/tegra/gem.c  Thierry Reding  

Re: [PATCH v1] drm/tegra: gem: Correct iommu_map_sg() error checking

[kbuild test robot]

Hi Dmitry,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on tegra/for-next]
[also build test WARNING on v4.15-rc4 next-20171220]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Dmitry-Osipenko/drm-tegra-gem-Correct-iommu_map_sg-error-checking/20171220-123700
base:   https://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git for-next
config: arm64-allmodconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm64 

All warnings (new ones prefixed by >>):

   drivers/gpu/drm/tegra/gem.c: In function 'tegra_bo_iommu_map':
>> drivers/gpu/drm/tegra/gem.c:131:58: warning: format '%zd' expects argument 
>> of type 'signed size_t', but argument 3 has type 'int' [-Wformat=]
  dev_err(tegra->drm->dev, "out of I/O virtual memory: %zd\n",
   ~~^
   %d

vim +131 drivers/gpu/drm/tegra/gem.c

de2ba664c drivers/gpu/host1x/drm/gem.c Arto Merilainen 2013-03-22  113  
df06b759f drivers/gpu/drm/tegra/gem.c  Thierry Reding  2014-06-26  114  static 
int tegra_bo_iommu_map(struct tegra_drm *tegra, struct tegra_bo *bo)
df06b759f drivers/gpu/drm/tegra/gem.c  Thierry Reding  2014-06-26  115  {
df06b759f drivers/gpu/drm/tegra/gem.c  Thierry Reding  2014-06-26  116  
int prot = IOMMU_READ | IOMMU_WRITE;
e1ad592fa drivers/gpu/drm/tegra/gem.c  Dmitry Osipenko 2017-12-17  117  
int err;
df06b759f drivers/gpu/drm/tegra/gem.c  Thierry Reding  2014-06-26  118  
df06b759f drivers/gpu/drm/tegra/gem.c  Thierry Reding  2014-06-26  119  
if (bo->mm)
df06b759f drivers/gpu/drm/tegra/gem.c  Thierry Reding  2014-06-26  120  
return -EBUSY;
df06b759f drivers/gpu/drm/tegra/gem.c  Thierry Reding  2014-06-26  121  
df06b759f drivers/gpu/drm/tegra/gem.c  Thierry Reding  2014-06-26  122  
bo->mm = kzalloc(sizeof(*bo->mm), GFP_KERNEL);
df06b759f drivers/gpu/drm/tegra/gem.c  Thierry Reding  2014-06-26  123  
if (!bo->mm)
df06b759f drivers/gpu/drm/tegra/gem.c  Thierry Reding  2014-06-26  124  
return -ENOMEM;
df06b759f drivers/gpu/drm/tegra/gem.c  Thierry Reding  2014-06-26  125  
347ad49d3 drivers/gpu/drm/tegra/gem.c  Thierry Reding  2017-03-09  126  
mutex_lock(>mm_lock);
347ad49d3 drivers/gpu/drm/tegra/gem.c  Thierry Reding  2017-03-09  127  
4e64e5539 drivers/gpu/drm/tegra/gem.c  Chris Wilson2017-02-02  128  
err = drm_mm_insert_node_generic(>mm,
4e64e5539 drivers/gpu/drm/tegra/gem.c  Chris Wilson2017-02-02  129  
 bo->mm, bo->gem.size, PAGE_SIZE, 0, 0);
df06b759f drivers/gpu/drm/tegra/gem.c  Thierry Reding  2014-06-26  130  
if (err < 0) {
df06b759f drivers/gpu/drm/tegra/gem.c  Thierry Reding  2014-06-26 @131  
dev_err(tegra->drm->dev, "out of I/O virtual memory: %zd\n",
df06b759f drivers/gpu/drm/tegra/gem.c  Thierry Reding  2014-06-26  132  
err);
347ad49d3 drivers/gpu/drm/tegra/gem.c  Thierry Reding  2017-03-09  133  
goto unlock;
df06b759f drivers/gpu/drm/tegra/gem.c  Thierry Reding  2014-06-26  134  
}
df06b759f drivers/gpu/drm/tegra/gem.c  Thierry Reding  2014-06-26  135  
df06b759f drivers/gpu/drm/tegra/gem.c  Thierry Reding  2014-06-26  136  
bo->paddr = bo->mm->start;
df06b759f drivers/gpu/drm/tegra/gem.c  Thierry Reding  2014-06-26  137  
e1ad592fa drivers/gpu/drm/tegra/gem.c  Dmitry Osipenko 2017-12-17  138  
bo->size = iommu_map_sg(tegra->domain, bo->paddr, bo->sgt->sgl,
df06b759f drivers/gpu/drm/tegra/gem.c  Thierry Reding  2014-06-26  139  
bo->sgt->nents, prot);
e1ad592fa drivers/gpu/drm/tegra/gem.c  Dmitry Osipenko 2017-12-17  140  
if (!bo->size) {
e1ad592fa drivers/gpu/drm/tegra/gem.c  Dmitry Osipenko 2017-12-17  141  
dev_err(tegra->drm->dev, "failed to map buffer\n");
e1ad592fa drivers/gpu/drm/tegra/gem.c  Dmitry Osipenko 2017-12-17  142  
err = -ENOMEM;
df06b759f drivers/gpu/drm/tegra/gem.c  Thierry Reding  2014-06-26  143  
goto remove;
df06b759f drivers/gpu/drm/tegra/gem.c  Thierry Reding  2014-06-26  144  
}
df06b759f drivers/gpu/drm/tegra/gem.c  Thierry Reding  2014-06-26  145  
347ad49d3 drivers/gpu/drm/tegra/gem.c  Thierry Reding  2017-03-09  146  
mutex_unlock(>mm_lock);
347ad49d3 drivers/gpu/drm/tegra/gem.c  Thierry Reding  2017-03-09  147  
df06b759f drivers/gpu/drm/tegra/gem.c  Thierry Reding  2014-06-26  148  
return 0;
df06b759f drivers/gpu/drm/tegra/gem.c  Thierry Reding  

Re: [PATCH v5 14/15] cpufreq: Add module to register cpufreq on Krait CPUs

[Sricharan R]

Hi Viresh,

On 12/20/2017 9:06 AM, Viresh Kumar wrote:
> On 19-12-17, 21:24, Sricharan R wrote:
>> From: Stephen Boyd 
>>
>> Register a cpufreq-generic device whenever we detect that a
>> "qcom,krait" compatible CPU is present in DT.
>>
>> Cc: 
>> [Sricharan: updated to use dev_pm_opp_set_prop_name]
>> Signed-off-by: Sricharan R 
>> Signed-off-by: Stephen Boyd 
>> ---
>>  drivers/cpufreq/Kconfig.arm  |   9 ++
>>  drivers/cpufreq/Makefile |   1 +
>>  drivers/cpufreq/cpufreq-dt-platdev.c |   3 +-
>>  drivers/cpufreq/qcom-cpufreq.c   | 171 
>> +++
>>  4 files changed, 183 insertions(+), 1 deletion(-)
>>  create mode 100644 drivers/cpufreq/qcom-cpufreq.c
>>
>> diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
>> index bdce448..60f28e7 100644
>> --- a/drivers/cpufreq/Kconfig.arm
>> +++ b/drivers/cpufreq/Kconfig.arm
>> @@ -100,6 +100,15 @@ config ARM_OMAP2PLUS_CPUFREQ
>>  depends on ARCH_OMAP2PLUS
>>  default ARCH_OMAP2PLUS
>>  
>> +config ARM_QCOM_CPUFREQ
>> +tristate "Qualcomm based"
> 
> Qualcomm based ... ? You want to add something after this ?
> 

 Hmm, got truncated. Will add a proper one.

> And why tristate ? Do you really want to build a module for this ?
> 

 Given that cpufreq-dt that registers the driver already supports module,
 don't think this needs to be a module. So will make it a bool.

>> +depends on ARCH_QCOM
>> +select PM_OPP
>> +help
>> +  This adds the CPUFreq driver for Qualcomm SoC based boards.
>> +
>> +  If in doubt, say N.
>> +
>>  config ARM_S3C_CPUFREQ
>>  bool
>>  help
>> diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
>> index 812f9e0..1496464 100644
>> --- a/drivers/cpufreq/Makefile
>> +++ b/drivers/cpufreq/Makefile
>> @@ -62,6 +62,7 @@ obj-$(CONFIG_ARM_MEDIATEK_CPUFREQ) += mediatek-cpufreq.o
>>  obj-$(CONFIG_ARM_OMAP2PLUS_CPUFREQ) += omap-cpufreq.o
>>  obj-$(CONFIG_ARM_PXA2xx_CPUFREQ)+= pxa2xx-cpufreq.o
>>  obj-$(CONFIG_PXA3xx)+= pxa3xx-cpufreq.o
>> +obj-$(CONFIG_ARM_QCOM_CPUFREQ)  += qcom-cpufreq.o
>>  obj-$(CONFIG_ARM_S3C24XX_CPUFREQ)   += s3c24xx-cpufreq.o
>>  obj-$(CONFIG_ARM_S3C24XX_CPUFREQ_DEBUGFS) += s3c24xx-cpufreq-debugfs.o
>>  obj-$(CONFIG_ARM_S3C2410_CPUFREQ)   += s3c2410-cpufreq.o
>> diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c 
>> b/drivers/cpufreq/cpufreq-dt-platdev.c
>> index ecc56e2..032ac4f 100644
>> --- a/drivers/cpufreq/cpufreq-dt-platdev.c
>> +++ b/drivers/cpufreq/cpufreq-dt-platdev.c
>> @@ -118,7 +118,7 @@
>>  { .compatible = "ti,am33xx", },
>>  { .compatible = "ti,am43", },
>>  { .compatible = "ti,dra7", },
>> -
> 
> Keep this blank line as is..
> 

 ok

>> +{ .compatible = "qcom,ipq8064", },
> 
> And add another one here.
> 

 ok

>>  { }
>>  };
>>  
>> @@ -157,6 +157,7 @@ static int __init cpufreq_dt_platdev_init(void)
>>  
>>  create_pdev:
>>  of_node_put(np);
>> +
> 
> Remove this.
> 

 ok

>>  return PTR_ERR_OR_ZERO(platform_device_register_data(NULL, "cpufreq-dt",
>> -1, data,
>> sizeof(struct cpufreq_dt_platform_data)));
>> diff --git a/drivers/cpufreq/qcom-cpufreq.c b/drivers/cpufreq/qcom-cpufreq.c
>> new file mode 100644
>> index 000..3e5583d
>> --- /dev/null
>> +++ b/drivers/cpufreq/qcom-cpufreq.c
>> @@ -0,0 +1,171 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +// Copyright (c) 2013-2015, The Linux Foundation. All rights reserved.
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include "cpufreq-dt.h"
>> +
>> +static void __init get_krait_bin_format_a(int *speed, int *pvs, int 
>> *pvs_ver)
>> +{
>> +void __iomem *base;
>> +u32 pte_efuse;
>> +
>> +*speed = *pvs = *pvs_ver = 0;
>> +
>> +base = ioremap(0x007000c0, 4);
>> +if (!base) {
>> +pr_warn("Unable to read efuse data. Defaulting to 0!\n");
>> +return;
>> +}
>> +
>> +pte_efuse = readl_relaxed(base);
>> +iounmap(base);
>> +
>> +*speed = pte_efuse & 0xf;
>> +if (*speed == 0xf)
>> +*speed = (pte_efuse >> 4) & 0xf;
>> +
>> +if (*speed == 0xf) {
>> +*speed = 0;
>> +pr_warn("Speed bin: Defaulting to %d\n", *speed);
>> +} else {
>> +pr_info("Speed bin: %d\n", *speed);
>> +}
>> +
>> +*pvs = (pte_efuse >> 10) & 0x7;
>> +if (*pvs == 0x7)
>> +*pvs = (pte_efuse >> 13) & 0x7;
>> +
>> +if (*pvs == 0x7) {
>> +*pvs = 0;
>> +pr_warn("PVS bin: Defaulting to %d\n", *pvs);
>> +} else {
>> +pr_info("PVS bin: %d\n", *pvs);
>> +}
>> +}
>> +
>> +static void __init get_krait_bin_format_b(int *speed, int *pvs, int 
>> *pvs_ver)
>> +{
>> +u32 pte_efuse, redundant_sel;

Re: [PATCH v5 14/15] cpufreq: Add module to register cpufreq on Krait CPUs

[Sricharan R]

Hi Viresh,

On 12/20/2017 9:06 AM, Viresh Kumar wrote:
> On 19-12-17, 21:24, Sricharan R wrote:
>> From: Stephen Boyd 
>>
>> Register a cpufreq-generic device whenever we detect that a
>> "qcom,krait" compatible CPU is present in DT.
>>
>> Cc: 
>> [Sricharan: updated to use dev_pm_opp_set_prop_name]
>> Signed-off-by: Sricharan R 
>> Signed-off-by: Stephen Boyd 
>> ---
>>  drivers/cpufreq/Kconfig.arm  |   9 ++
>>  drivers/cpufreq/Makefile |   1 +
>>  drivers/cpufreq/cpufreq-dt-platdev.c |   3 +-
>>  drivers/cpufreq/qcom-cpufreq.c   | 171 
>> +++
>>  4 files changed, 183 insertions(+), 1 deletion(-)
>>  create mode 100644 drivers/cpufreq/qcom-cpufreq.c
>>
>> diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
>> index bdce448..60f28e7 100644
>> --- a/drivers/cpufreq/Kconfig.arm
>> +++ b/drivers/cpufreq/Kconfig.arm
>> @@ -100,6 +100,15 @@ config ARM_OMAP2PLUS_CPUFREQ
>>  depends on ARCH_OMAP2PLUS
>>  default ARCH_OMAP2PLUS
>>  
>> +config ARM_QCOM_CPUFREQ
>> +tristate "Qualcomm based"
> 
> Qualcomm based ... ? You want to add something after this ?
> 

 Hmm, got truncated. Will add a proper one.

> And why tristate ? Do you really want to build a module for this ?
> 

 Given that cpufreq-dt that registers the driver already supports module,
 don't think this needs to be a module. So will make it a bool.

>> +depends on ARCH_QCOM
>> +select PM_OPP
>> +help
>> +  This adds the CPUFreq driver for Qualcomm SoC based boards.
>> +
>> +  If in doubt, say N.
>> +
>>  config ARM_S3C_CPUFREQ
>>  bool
>>  help
>> diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
>> index 812f9e0..1496464 100644
>> --- a/drivers/cpufreq/Makefile
>> +++ b/drivers/cpufreq/Makefile
>> @@ -62,6 +62,7 @@ obj-$(CONFIG_ARM_MEDIATEK_CPUFREQ) += mediatek-cpufreq.o
>>  obj-$(CONFIG_ARM_OMAP2PLUS_CPUFREQ) += omap-cpufreq.o
>>  obj-$(CONFIG_ARM_PXA2xx_CPUFREQ)+= pxa2xx-cpufreq.o
>>  obj-$(CONFIG_PXA3xx)+= pxa3xx-cpufreq.o
>> +obj-$(CONFIG_ARM_QCOM_CPUFREQ)  += qcom-cpufreq.o
>>  obj-$(CONFIG_ARM_S3C24XX_CPUFREQ)   += s3c24xx-cpufreq.o
>>  obj-$(CONFIG_ARM_S3C24XX_CPUFREQ_DEBUGFS) += s3c24xx-cpufreq-debugfs.o
>>  obj-$(CONFIG_ARM_S3C2410_CPUFREQ)   += s3c2410-cpufreq.o
>> diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c 
>> b/drivers/cpufreq/cpufreq-dt-platdev.c
>> index ecc56e2..032ac4f 100644
>> --- a/drivers/cpufreq/cpufreq-dt-platdev.c
>> +++ b/drivers/cpufreq/cpufreq-dt-platdev.c
>> @@ -118,7 +118,7 @@
>>  { .compatible = "ti,am33xx", },
>>  { .compatible = "ti,am43", },
>>  { .compatible = "ti,dra7", },
>> -
> 
> Keep this blank line as is..
> 

 ok

>> +{ .compatible = "qcom,ipq8064", },
> 
> And add another one here.
> 

 ok

>>  { }
>>  };
>>  
>> @@ -157,6 +157,7 @@ static int __init cpufreq_dt_platdev_init(void)
>>  
>>  create_pdev:
>>  of_node_put(np);
>> +
> 
> Remove this.
> 

 ok

>>  return PTR_ERR_OR_ZERO(platform_device_register_data(NULL, "cpufreq-dt",
>> -1, data,
>> sizeof(struct cpufreq_dt_platform_data)));
>> diff --git a/drivers/cpufreq/qcom-cpufreq.c b/drivers/cpufreq/qcom-cpufreq.c
>> new file mode 100644
>> index 000..3e5583d
>> --- /dev/null
>> +++ b/drivers/cpufreq/qcom-cpufreq.c
>> @@ -0,0 +1,171 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +// Copyright (c) 2013-2015, The Linux Foundation. All rights reserved.
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include "cpufreq-dt.h"
>> +
>> +static void __init get_krait_bin_format_a(int *speed, int *pvs, int 
>> *pvs_ver)
>> +{
>> +void __iomem *base;
>> +u32 pte_efuse;
>> +
>> +*speed = *pvs = *pvs_ver = 0;
>> +
>> +base = ioremap(0x007000c0, 4);
>> +if (!base) {
>> +pr_warn("Unable to read efuse data. Defaulting to 0!\n");
>> +return;
>> +}
>> +
>> +pte_efuse = readl_relaxed(base);
>> +iounmap(base);
>> +
>> +*speed = pte_efuse & 0xf;
>> +if (*speed == 0xf)
>> +*speed = (pte_efuse >> 4) & 0xf;
>> +
>> +if (*speed == 0xf) {
>> +*speed = 0;
>> +pr_warn("Speed bin: Defaulting to %d\n", *speed);
>> +} else {
>> +pr_info("Speed bin: %d\n", *speed);
>> +}
>> +
>> +*pvs = (pte_efuse >> 10) & 0x7;
>> +if (*pvs == 0x7)
>> +*pvs = (pte_efuse >> 13) & 0x7;
>> +
>> +if (*pvs == 0x7) {
>> +*pvs = 0;
>> +pr_warn("PVS bin: Defaulting to %d\n", *pvs);
>> +} else {
>> +pr_info("PVS bin: %d\n", *pvs);
>> +}
>> +}
>> +
>> +static void __init get_krait_bin_format_b(int *speed, int *pvs, int 
>> *pvs_ver)
>> +{
>> +u32 pte_efuse, redundant_sel;
>> +void __iomem *base;
>> +
>> +*speed = 0;
>> +*pvs = 0;
>> +*pvs_ver = 0;
>> +

[PATCH v6 0/3] i2c: introduce devm_i2c_new_dummy and use it in at24 driver

[Heiner Kallweit]

i2c_new_dummy is typically called from the probe function of the
driver for the primary i2c client. It requires calls to
i2c_unregister_device in the error path of the probe function and
in the remove function.
This can be simplified by introducing a device-managed version.

Make at24 driver the first user of the new function.

Changes in v2:
- add change to i2c core to make a version of i2c_new_device
  available which returns an ERR_PTR instead of NULL in error case
- few minor improvements

Changes in v3:
- rename _i2c_new_device to __i2c_new_device

Changes in v4:
- add missing kernel doc comments
- add Reviewed-by

Changes in v5:
- fix a copy & paste error in patch 1
- improve readability in patch 2

Changes in v5:
- cosmetic change in patch 1
- patch 3 rebased on top of latest at24/for-next

Heiner Kallweit (3):
  i2c: core: improve return value handling of i2c_new_device and i2c_new_dummy
  i2c: core: add device-managed version of i2c_new_dummy
  eeprom: at24: switch to device-managed version of i2c_new_dummy

 Documentation/driver-model/devres.txt |   3 +
 drivers/i2c/i2c-core-base.c   | 115 ++
 drivers/misc/eeprom/at24.c|  32 --
 include/linux/i2c.h   |   3 +
 4 files changed, 119 insertions(+), 34 deletions(-)

-- 
2.15.1

[PATCH v6 0/3] i2c: introduce devm_i2c_new_dummy and use it in at24 driver

[Heiner Kallweit]

i2c_new_dummy is typically called from the probe function of the
driver for the primary i2c client. It requires calls to
i2c_unregister_device in the error path of the probe function and
in the remove function.
This can be simplified by introducing a device-managed version.

Make at24 driver the first user of the new function.

Changes in v2:
- add change to i2c core to make a version of i2c_new_device
  available which returns an ERR_PTR instead of NULL in error case
- few minor improvements

Changes in v3:
- rename _i2c_new_device to __i2c_new_device

Changes in v4:
- add missing kernel doc comments
- add Reviewed-by

Changes in v5:
- fix a copy & paste error in patch 1
- improve readability in patch 2

Changes in v5:
- cosmetic change in patch 1
- patch 3 rebased on top of latest at24/for-next

Heiner Kallweit (3):
  i2c: core: improve return value handling of i2c_new_device and i2c_new_dummy
  i2c: core: add device-managed version of i2c_new_dummy
  eeprom: at24: switch to device-managed version of i2c_new_dummy

 Documentation/driver-model/devres.txt |   3 +
 drivers/i2c/i2c-core-base.c   | 115 ++
 drivers/misc/eeprom/at24.c|  32 --
 include/linux/i2c.h   |   3 +
 4 files changed, 119 insertions(+), 34 deletions(-)

-- 
2.15.1

Re: [PATCH V2 net-next 02/17] net: hns3: add support to modify tqps number

[lipeng (Y)]

On 2017/12/20 3:18, David Miller wrote:

From: Lipeng 
Date: Tue, 19 Dec 2017 12:02:24 +0800


@@ -2651,6 +2651,19 @@ static int hns3_get_ring_config(struct hns3_nic_priv 
*priv)
return ret;
  }
  
+static void hns3_put_ring_config(struct hns3_nic_priv *priv)

+{
+   struct hnae3_handle *h = priv->ae_handle;
+   u16 i;
+
+   for (i = 0; i < h->kinfo.num_tqps; i++) {

Please use a plain "int" for index iteration loops like this since
that is the canonical type to use.

will check and fix this , Thanks.

+static void hclge_release_tqp(struct hclge_vport *vport)
+{
+   struct hnae3_knic_private_info *kinfo = >nic.kinfo;
+   struct hclge_dev *hdev = vport->back;
+   u16 i;
+
+   for (i = 0; i < kinfo->num_tqps; i++) {

Likewise.

.

Re: [PATCH V2 net-next 02/17] net: hns3: add support to modify tqps number

[lipeng (Y)]

On 2017/12/20 3:18, David Miller wrote:

From: Lipeng 
Date: Tue, 19 Dec 2017 12:02:24 +0800


@@ -2651,6 +2651,19 @@ static int hns3_get_ring_config(struct hns3_nic_priv 
*priv)
return ret;
  }
  
+static void hns3_put_ring_config(struct hns3_nic_priv *priv)

+{
+   struct hnae3_handle *h = priv->ae_handle;
+   u16 i;
+
+   for (i = 0; i < h->kinfo.num_tqps; i++) {

Please use a plain "int" for index iteration loops like this since
that is the canonical type to use.

will check and fix this , Thanks.

+static void hclge_release_tqp(struct hclge_vport *vport)
+{
+   struct hnae3_knic_private_info *kinfo = >nic.kinfo;
+   struct hclge_dev *hdev = vport->back;
+   u16 i;
+
+   for (i = 0; i < kinfo->num_tqps; i++) {

Likewise.

.