Re: [PATCH 3/9] kexec_file: factor out crashdump elf header function from x86

2017-09-11 Thread Dave Young
Hi,
On 09/08/17 at 12:16pm, AKASHI Takahiro wrote:
[snip]
> --- a/include/linux/kexec.h
> +++ b/include/linux/kexec.h
> @@ -162,6 +162,25 @@ int __weak arch_kexec_walk_mem(struct kexec_buf *kbuf,
>  int (*func)(u64, u64, void *));
>  extern int kexec_add_buffer(struct kexec_buf *kbuf);
>  int kexec_locate_mem_hole(struct kexec_buf *kbuf);
> +#ifdef CONFIG_CRASH_CORE
> +extern int prepare_elf_headers(struct kimage *image, void **addr,
> + unsigned long *sz);
> +
> +/* This primarily represents number of split ranges due to exclusion */
> +#define CRASH_MAX_RANGES16
> +
> +struct crash_mem_range {
> + u64 start, end;
> +};
> +
> +struct crash_mem {
> + unsigned int nr_ranges;
> + struct crash_mem_range ranges[CRASH_MAX_RANGES];
> +};
> +
> +extern int exclude_mem_range(struct crash_mem *mem,
> + unsigned long long mstart, unsigned long long mend);
> +#endif /* CONFIG_CRASH_CORE */

Maybe I did not say it clear when reviewing the v1.

I suggested to move the code from to kexec_file.c because the
CONFIG_CRASH_CORE originally was introduced for the common code for
vmcoreinfo stuff when Hari worked on sharing code between powerpc
fadump and kdump.

I'm not sure we need the #ifdef CONFIG_CRASH_CORE here for these
kexec file load functions. Since they are already in kexec_file.c
so I think no need to add the #ifdef

>  #endif /* CONFIG_KEXEC_FILE */
Thanks
Dave


Re: [PATCH 3/9] kexec_file: factor out crashdump elf header function from x86

2017-09-11 Thread Dave Young
Hi,
On 09/08/17 at 12:16pm, AKASHI Takahiro wrote:
[snip]
> --- a/include/linux/kexec.h
> +++ b/include/linux/kexec.h
> @@ -162,6 +162,25 @@ int __weak arch_kexec_walk_mem(struct kexec_buf *kbuf,
>  int (*func)(u64, u64, void *));
>  extern int kexec_add_buffer(struct kexec_buf *kbuf);
>  int kexec_locate_mem_hole(struct kexec_buf *kbuf);
> +#ifdef CONFIG_CRASH_CORE
> +extern int prepare_elf_headers(struct kimage *image, void **addr,
> + unsigned long *sz);
> +
> +/* This primarily represents number of split ranges due to exclusion */
> +#define CRASH_MAX_RANGES16
> +
> +struct crash_mem_range {
> + u64 start, end;
> +};
> +
> +struct crash_mem {
> + unsigned int nr_ranges;
> + struct crash_mem_range ranges[CRASH_MAX_RANGES];
> +};
> +
> +extern int exclude_mem_range(struct crash_mem *mem,
> + unsigned long long mstart, unsigned long long mend);
> +#endif /* CONFIG_CRASH_CORE */

Maybe I did not say it clear when reviewing the v1.

I suggested to move the code from to kexec_file.c because the
CONFIG_CRASH_CORE originally was introduced for the common code for
vmcoreinfo stuff when Hari worked on sharing code between powerpc
fadump and kdump.

I'm not sure we need the #ifdef CONFIG_CRASH_CORE here for these
kexec file load functions. Since they are already in kexec_file.c
so I think no need to add the #ifdef

>  #endif /* CONFIG_KEXEC_FILE */
Thanks
Dave


[PATCH] video: fbdev: Fix an errro handling path in 'au1200fb_drv_probe()'

2017-09-11 Thread Christophe JAILLET
If 'dmam_alloc_attrs()' fails, we must go through the error handling code,
as done elsewhere in this function. Otherwise, there is a resource leak.

Signed-off-by: Christophe JAILLET 
---
I'm also puzzled by the 'framebuffer_alloc()' call a few lines above.
'ret' is known to be 0 at this point. I guess that -ENOMEM should also be
returned.
---
 drivers/video/fbdev/au1200fb.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/au1200fb.c b/drivers/video/fbdev/au1200fb.c
index 5f04b4096c42..99d6cfb168b5 100644
--- a/drivers/video/fbdev/au1200fb.c
+++ b/drivers/video/fbdev/au1200fb.c
@@ -1701,7 +1701,8 @@ static int au1200fb_drv_probe(struct platform_device *dev)
if (!fbdev->fb_mem) {
print_err("fail to allocate frambuffer (size: %dK))",
  fbdev->fb_len / 1024);
-   return -ENOMEM;
+   ret = -ENOMEM;
+   goto failed;
}
 
/*
-- 
2.11.0



[PATCH] video: fbdev: Fix an errro handling path in 'au1200fb_drv_probe()'

2017-09-11 Thread Christophe JAILLET
If 'dmam_alloc_attrs()' fails, we must go through the error handling code,
as done elsewhere in this function. Otherwise, there is a resource leak.

Signed-off-by: Christophe JAILLET 
---
I'm also puzzled by the 'framebuffer_alloc()' call a few lines above.
'ret' is known to be 0 at this point. I guess that -ENOMEM should also be
returned.
---
 drivers/video/fbdev/au1200fb.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/au1200fb.c b/drivers/video/fbdev/au1200fb.c
index 5f04b4096c42..99d6cfb168b5 100644
--- a/drivers/video/fbdev/au1200fb.c
+++ b/drivers/video/fbdev/au1200fb.c
@@ -1701,7 +1701,8 @@ static int au1200fb_drv_probe(struct platform_device *dev)
if (!fbdev->fb_mem) {
print_err("fail to allocate frambuffer (size: %dK))",
  fbdev->fb_len / 1024);
-   return -ENOMEM;
+   ret = -ENOMEM;
+   goto failed;
}
 
/*
-- 
2.11.0



Re: [PATCH -tip v2] kprobes: Use synchronize_rcu_tasks() for optprobe with CONFIG_PREEMPT

2017-09-11 Thread Paul E. McKenney
On Tue, Sep 12, 2017 at 10:10:51AM +0900, Masami Hiramatsu wrote:
> To enable jump optimized probe with CONFIG_PREEMPT, use
> synchronize_rcu_tasks() to wait for all tasks preempted
> on trampoline code back on track.
> 
> Since the jump optimized kprobes can replace multiple
> instructions, there can be tasks which are interrupted
> on the 2nd (or 3rd) instructions. If the kprobe
> replaces those instructions by a jump instruction,
> when those tasks back to the interrupted place, it is
> a middle of the jump instruction and causes a kernel
> panic.
> To avoid such tragedies in advance, kprobe optimizer
> prepare a detour route using normal kprobe (e.g.
> int3 breakpoint on x86), and wait for the tasks which
> is interrrupted on such place by synchronize_sched()
> when CONFIG_PREEMPT=n.
> If CONFIG_PREEMPT=y, things be more complicated, because
> such interrupted thread can be preempted (other thread
> can be scheduled in interrupt handler.) So, kprobes
> optimizer has to wait for those tasks scheduled normally.
> In this case we can use synchronize_rcu_tasks() which
> ensures that all preempted tasks back on track and
> schedule it.
> 
> Signed-off-by: Masami Hiramatsu 

Reviewed-by: Paul E. McKenney 

> ---
>  arch/Kconfig |2 +-
>  kernel/kprobes.c |   18 +-
>  2 files changed, 14 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/Kconfig b/arch/Kconfig
> index 2520ca5b42eb..d495c06ae961 100644
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@ -90,7 +90,7 @@ config STATIC_KEYS_SELFTEST
>  config OPTPROBES
>   def_bool y
>   depends on KPROBES && HAVE_OPTPROBES
> - depends on !PREEMPT
> + select TASKS_RCU if PREEMPT
> 
>  config KPROBES_ON_FTRACE
>   def_bool y
> diff --git a/kernel/kprobes.c b/kernel/kprobes.c
> index a1606a4224e1..6243b8b02511 100644
> --- a/kernel/kprobes.c
> +++ b/kernel/kprobes.c
> @@ -574,12 +574,20 @@ static void kprobe_optimizer(struct work_struct *work)
> 
>   /*
>* Step 2: Wait for quiesence period to ensure all running interrupts
> -  * are done. Because optprobe may modify multiple instructions
> -  * there is a chance that Nth instruction is interrupted. In that
> -  * case, running interrupt can return to 2nd-Nth byte of jump
> -  * instruction. This wait is for avoiding it.
> +  * are done. Because optprobe may modify multiple instructions,
> +  * there is a chance that the Nth instruction is interrupted. In that
> +  * case, running interrupt can return to the Nth byte of jump
> +  * instruction. This can be avoided by waiting for returning of
> +  * such interrupts, since (until here) the first byte of the optimized
> +  * probe is already replaced with normal kprobe (sw breakpoint) and
> +  * all threads which reach to the probed address will hit it and
> +  * bypass the copied instructions instead of executing the original.
> +  * With CONFIG_PREEMPT, such interrupts can be preepmted. To wait
> +  * for such thread, we will use synchronize_rcu_tasks() which ensures
> +  * all preeempted tasks are scheduled normally (= not preempted.)
> +  * So we can ensure there is no threads preempted at probed address.
>*/
> - synchronize_sched();
> + synchronize_rcu_tasks();
> 
>   /* Step 3: Optimize kprobes after quiesence period */
>   do_optimize_kprobes();
> 



Re: [PATCH -tip v2] kprobes: Use synchronize_rcu_tasks() for optprobe with CONFIG_PREEMPT

2017-09-11 Thread Paul E. McKenney
On Tue, Sep 12, 2017 at 10:10:51AM +0900, Masami Hiramatsu wrote:
> To enable jump optimized probe with CONFIG_PREEMPT, use
> synchronize_rcu_tasks() to wait for all tasks preempted
> on trampoline code back on track.
> 
> Since the jump optimized kprobes can replace multiple
> instructions, there can be tasks which are interrupted
> on the 2nd (or 3rd) instructions. If the kprobe
> replaces those instructions by a jump instruction,
> when those tasks back to the interrupted place, it is
> a middle of the jump instruction and causes a kernel
> panic.
> To avoid such tragedies in advance, kprobe optimizer
> prepare a detour route using normal kprobe (e.g.
> int3 breakpoint on x86), and wait for the tasks which
> is interrrupted on such place by synchronize_sched()
> when CONFIG_PREEMPT=n.
> If CONFIG_PREEMPT=y, things be more complicated, because
> such interrupted thread can be preempted (other thread
> can be scheduled in interrupt handler.) So, kprobes
> optimizer has to wait for those tasks scheduled normally.
> In this case we can use synchronize_rcu_tasks() which
> ensures that all preempted tasks back on track and
> schedule it.
> 
> Signed-off-by: Masami Hiramatsu 

Reviewed-by: Paul E. McKenney 

> ---
>  arch/Kconfig |2 +-
>  kernel/kprobes.c |   18 +-
>  2 files changed, 14 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/Kconfig b/arch/Kconfig
> index 2520ca5b42eb..d495c06ae961 100644
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@ -90,7 +90,7 @@ config STATIC_KEYS_SELFTEST
>  config OPTPROBES
>   def_bool y
>   depends on KPROBES && HAVE_OPTPROBES
> - depends on !PREEMPT
> + select TASKS_RCU if PREEMPT
> 
>  config KPROBES_ON_FTRACE
>   def_bool y
> diff --git a/kernel/kprobes.c b/kernel/kprobes.c
> index a1606a4224e1..6243b8b02511 100644
> --- a/kernel/kprobes.c
> +++ b/kernel/kprobes.c
> @@ -574,12 +574,20 @@ static void kprobe_optimizer(struct work_struct *work)
> 
>   /*
>* Step 2: Wait for quiesence period to ensure all running interrupts
> -  * are done. Because optprobe may modify multiple instructions
> -  * there is a chance that Nth instruction is interrupted. In that
> -  * case, running interrupt can return to 2nd-Nth byte of jump
> -  * instruction. This wait is for avoiding it.
> +  * are done. Because optprobe may modify multiple instructions,
> +  * there is a chance that the Nth instruction is interrupted. In that
> +  * case, running interrupt can return to the Nth byte of jump
> +  * instruction. This can be avoided by waiting for returning of
> +  * such interrupts, since (until here) the first byte of the optimized
> +  * probe is already replaced with normal kprobe (sw breakpoint) and
> +  * all threads which reach to the probed address will hit it and
> +  * bypass the copied instructions instead of executing the original.
> +  * With CONFIG_PREEMPT, such interrupts can be preepmted. To wait
> +  * for such thread, we will use synchronize_rcu_tasks() which ensures
> +  * all preeempted tasks are scheduled normally (= not preempted.)
> +  * So we can ensure there is no threads preempted at probed address.
>*/
> - synchronize_sched();
> + synchronize_rcu_tasks();
> 
>   /* Step 3: Optimize kprobes after quiesence period */
>   do_optimize_kprobes();
> 



Re: usb/joystick: warnings in xpad_start_input and xpad_try_sending_next_out_packet

2017-09-11 Thread Dmitry Vyukov
On Tue, Sep 12, 2017 at 5:42 AM, Cameron Gutman  wrote:
> On 09/11/2017 05:26 AM, Andrey Konovalov wrote:
>> Hi!
>>
>> I've got the following crashes while fuzzing the kernel with syzkaller.
>>
>> On commit 81a84ad3cb5711cec79f4dd53a4ce026b092c432 (Sep 3).
>>
>> usb 1-1: BOGUS urb xfer, pipe 1 != type 3
>> WARNING: CPU: 1 PID: 2574 at drivers/usb/core/urb.c:449
>> usb_submit_urb+0xf8a/0x11d0
>> Modules linked in:
>> CPU: 1 PID: 2574 Comm: kworker/1:2 Not tainted 4.13.0+ #88
>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>> Workqueue: usb_hub_wq hub_event
>> task: 880067ec9a00 task.stack: 880067988000
>> RIP: 0010:usb_submit_urb+0xf8a/0x11d0 drivers/usb/core/urb.c:448
>> RSP: 0018:88006798e0b0 EFLAGS: 00010082
>> RAX: 0029 RBX: 88006b9ca200 RCX: 
>> RDX: 0029 RSI: 88006c915c78 RDI: ed000cf31c08
>> RBP: 88006798e1b0 R08: fbfff0fe00ff R09: fbfff0fe00ff
>> R10: 0001 R11: fbfff0fe00fe R12: 11000cf31c1d
>> R13: 0003 R14: 0001 R15: 88006b164798
>> FS:  () GS:88006c90() knlGS:
>> CS:  0010 DS:  ES:  CR0: 80050033
>> CR2: 7fde04686518 CR3: 6a539000 CR4: 06e0
>> Call Trace:
>>  xpad_try_sending_next_out_packet+0xe1/0x1d0 
>> drivers/input/joystick/xpad.c:1000
>>  xpad_send_led_command drivers/input/joystick/xpad.c:1372
>>  xpad_led_set+0x465/0x6e0 drivers/input/joystick/xpad.c:1392
>>  __led_set_brightness drivers/leds/led-core.c:34
>>  led_set_brightness_nopm+0x53/0x100 drivers/leds/led-core.c:261
>>  led_set_brightness_nosleep+0x17f/0x220 drivers/leds/led-core.c:278
>>  led_set_brightness+0xfe/0x130 drivers/leds/led-core.c:253
>>  xpad_identify_controller drivers/input/joystick/xpad.c:1383
>>  xpad_led_probe drivers/input/joystick/xpad.c:1426
>>  xpad_init_input+0xd40/0xfe0 drivers/input/joystick/xpad.c:1667
>>  xpad_probe+0x13d4/0x1e00 drivers/input/joystick/xpad.c:1811
>>  usb_probe_interface+0x351/0x8d0 drivers/usb/core/driver.c:361
>>  really_probe drivers/base/dd.c:385
>>  driver_probe_device+0x610/0xa00 drivers/base/dd.c:529
>>  __device_attach_driver+0x230/0x290 drivers/base/dd.c:625
>>  bus_for_each_drv+0x15e/0x210 drivers/base/bus.c:463
>>  __device_attach+0x269/0x3c0 drivers/base/dd.c:682
>>  device_initial_probe+0x1f/0x30 drivers/base/dd.c:729
>>  bus_probe_device+0x1da/0x280 drivers/base/bus.c:523
>>  device_add+0xcf9/0x1640 drivers/base/core.c:1703
>>  usb_set_configuration+0x1064/0x1890 drivers/usb/core/message.c:1932
>>  generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174
>>  usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266
>>  really_probe drivers/base/dd.c:385
>>  driver_probe_device+0x610/0xa00 drivers/base/dd.c:529
>>  __device_attach_driver+0x230/0x290 drivers/base/dd.c:625
>>  bus_for_each_drv+0x15e/0x210 drivers/base/bus.c:463
>>  __device_attach+0x269/0x3c0 drivers/base/dd.c:682
>>  device_initial_probe+0x1f/0x30 drivers/base/dd.c:729
>>  bus_probe_device+0x1da/0x280 drivers/base/bus.c:523
>>  device_add+0xcf9/0x1640 drivers/base/core.c:1703
>>  usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2457
>>  hub_port_connect drivers/usb/core/hub.c:4890
>>  hub_port_connect_change drivers/usb/core/hub.c:4996
>>  port_event drivers/usb/core/hub.c:5102
>>  hub_event+0x23c8/0x37c0 drivers/usb/core/hub.c:5182
>>  process_one_work+0x9fb/0x1570 kernel/workqueue.c:2097
>>  worker_thread+0x1e4/0x1350 kernel/workqueue.c:2231
>>  kthread+0x324/0x3f0 kernel/kthread.c:231
>>  ret_from_fork+0x25/0x30 arch/x86/entry/entry_64.S:425
>> Code: 48 8b 85 30 ff ff ff 48 8d b8 98 00 00 00 e8 8e 93 07 ff 45 89
>> e8 44 89 f1 4c 89 fa 48 89 c6 48 c7 c7 a0 e5 55 86 e8 20 08 8f fd <0f>
>> ff e9 9b f7 ff ff e8 4a 04 d6 fd e9 80 f7 ff ff e8 60 11 a6
>> ---[ end trace 5b20fc700a17a457 ]---
>
> I assume you're doing some sort of USB emulation to fuzz these?

Yes.

> I don't
> think we'd get that far with any real device that wasn't explicitly designed
> to trick us.

Note there _are_ such devices, e.g. https://int3.cc/products/facedancer21

> In any case, this patch should take care of it.
>
> Regards,
> Cameron
>
> 
> diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
> index f8e34ef643c7..d86e59515b9c 100644
> --- a/drivers/input/joystick/xpad.c
> +++ b/drivers/input/joystick/xpad.c
> @@ -1764,10 +1764,12 @@ static int xpad_probe(struct usb_interface *intf, 
> const struct usb_device_id *id
> struct usb_endpoint_descriptor *ep =
> >cur_altsetting->endpoint[i].desc;
>
> -   if (usb_endpoint_dir_in(ep))
> -   ep_irq_in = ep;
> -   else
> -   ep_irq_out = ep;
> +   if (usb_endpoint_xfer_int(ep)) {
> +   if (usb_endpoint_dir_in(ep))
> +   ep_irq_in = ep;
> 

Re: usb/joystick: warnings in xpad_start_input and xpad_try_sending_next_out_packet

2017-09-11 Thread Dmitry Vyukov
On Tue, Sep 12, 2017 at 5:42 AM, Cameron Gutman  wrote:
> On 09/11/2017 05:26 AM, Andrey Konovalov wrote:
>> Hi!
>>
>> I've got the following crashes while fuzzing the kernel with syzkaller.
>>
>> On commit 81a84ad3cb5711cec79f4dd53a4ce026b092c432 (Sep 3).
>>
>> usb 1-1: BOGUS urb xfer, pipe 1 != type 3
>> WARNING: CPU: 1 PID: 2574 at drivers/usb/core/urb.c:449
>> usb_submit_urb+0xf8a/0x11d0
>> Modules linked in:
>> CPU: 1 PID: 2574 Comm: kworker/1:2 Not tainted 4.13.0+ #88
>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>> Workqueue: usb_hub_wq hub_event
>> task: 880067ec9a00 task.stack: 880067988000
>> RIP: 0010:usb_submit_urb+0xf8a/0x11d0 drivers/usb/core/urb.c:448
>> RSP: 0018:88006798e0b0 EFLAGS: 00010082
>> RAX: 0029 RBX: 88006b9ca200 RCX: 
>> RDX: 0029 RSI: 88006c915c78 RDI: ed000cf31c08
>> RBP: 88006798e1b0 R08: fbfff0fe00ff R09: fbfff0fe00ff
>> R10: 0001 R11: fbfff0fe00fe R12: 11000cf31c1d
>> R13: 0003 R14: 0001 R15: 88006b164798
>> FS:  () GS:88006c90() knlGS:
>> CS:  0010 DS:  ES:  CR0: 80050033
>> CR2: 7fde04686518 CR3: 6a539000 CR4: 06e0
>> Call Trace:
>>  xpad_try_sending_next_out_packet+0xe1/0x1d0 
>> drivers/input/joystick/xpad.c:1000
>>  xpad_send_led_command drivers/input/joystick/xpad.c:1372
>>  xpad_led_set+0x465/0x6e0 drivers/input/joystick/xpad.c:1392
>>  __led_set_brightness drivers/leds/led-core.c:34
>>  led_set_brightness_nopm+0x53/0x100 drivers/leds/led-core.c:261
>>  led_set_brightness_nosleep+0x17f/0x220 drivers/leds/led-core.c:278
>>  led_set_brightness+0xfe/0x130 drivers/leds/led-core.c:253
>>  xpad_identify_controller drivers/input/joystick/xpad.c:1383
>>  xpad_led_probe drivers/input/joystick/xpad.c:1426
>>  xpad_init_input+0xd40/0xfe0 drivers/input/joystick/xpad.c:1667
>>  xpad_probe+0x13d4/0x1e00 drivers/input/joystick/xpad.c:1811
>>  usb_probe_interface+0x351/0x8d0 drivers/usb/core/driver.c:361
>>  really_probe drivers/base/dd.c:385
>>  driver_probe_device+0x610/0xa00 drivers/base/dd.c:529
>>  __device_attach_driver+0x230/0x290 drivers/base/dd.c:625
>>  bus_for_each_drv+0x15e/0x210 drivers/base/bus.c:463
>>  __device_attach+0x269/0x3c0 drivers/base/dd.c:682
>>  device_initial_probe+0x1f/0x30 drivers/base/dd.c:729
>>  bus_probe_device+0x1da/0x280 drivers/base/bus.c:523
>>  device_add+0xcf9/0x1640 drivers/base/core.c:1703
>>  usb_set_configuration+0x1064/0x1890 drivers/usb/core/message.c:1932
>>  generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174
>>  usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266
>>  really_probe drivers/base/dd.c:385
>>  driver_probe_device+0x610/0xa00 drivers/base/dd.c:529
>>  __device_attach_driver+0x230/0x290 drivers/base/dd.c:625
>>  bus_for_each_drv+0x15e/0x210 drivers/base/bus.c:463
>>  __device_attach+0x269/0x3c0 drivers/base/dd.c:682
>>  device_initial_probe+0x1f/0x30 drivers/base/dd.c:729
>>  bus_probe_device+0x1da/0x280 drivers/base/bus.c:523
>>  device_add+0xcf9/0x1640 drivers/base/core.c:1703
>>  usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2457
>>  hub_port_connect drivers/usb/core/hub.c:4890
>>  hub_port_connect_change drivers/usb/core/hub.c:4996
>>  port_event drivers/usb/core/hub.c:5102
>>  hub_event+0x23c8/0x37c0 drivers/usb/core/hub.c:5182
>>  process_one_work+0x9fb/0x1570 kernel/workqueue.c:2097
>>  worker_thread+0x1e4/0x1350 kernel/workqueue.c:2231
>>  kthread+0x324/0x3f0 kernel/kthread.c:231
>>  ret_from_fork+0x25/0x30 arch/x86/entry/entry_64.S:425
>> Code: 48 8b 85 30 ff ff ff 48 8d b8 98 00 00 00 e8 8e 93 07 ff 45 89
>> e8 44 89 f1 4c 89 fa 48 89 c6 48 c7 c7 a0 e5 55 86 e8 20 08 8f fd <0f>
>> ff e9 9b f7 ff ff e8 4a 04 d6 fd e9 80 f7 ff ff e8 60 11 a6
>> ---[ end trace 5b20fc700a17a457 ]---
>
> I assume you're doing some sort of USB emulation to fuzz these?

Yes.

> I don't
> think we'd get that far with any real device that wasn't explicitly designed
> to trick us.

Note there _are_ such devices, e.g. https://int3.cc/products/facedancer21

> In any case, this patch should take care of it.
>
> Regards,
> Cameron
>
> 
> diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
> index f8e34ef643c7..d86e59515b9c 100644
> --- a/drivers/input/joystick/xpad.c
> +++ b/drivers/input/joystick/xpad.c
> @@ -1764,10 +1764,12 @@ static int xpad_probe(struct usb_interface *intf, 
> const struct usb_device_id *id
> struct usb_endpoint_descriptor *ep =
> >cur_altsetting->endpoint[i].desc;
>
> -   if (usb_endpoint_dir_in(ep))
> -   ep_irq_in = ep;
> -   else
> -   ep_irq_out = ep;
> +   if (usb_endpoint_xfer_int(ep)) {
> +   if (usb_endpoint_dir_in(ep))
> +   ep_irq_in = ep;
> +   

Re: [PATCH 4/5] mm:swap: respect page_cluster for readahead

2017-09-11 Thread Huang, Ying
Minchan Kim  writes:

> page_cluster 0 means "we don't want readahead" so in the case,
> let's skip the readahead detection logic.
>
> Cc: "Huang, Ying" 
> Signed-off-by: Minchan Kim 
> ---
>  include/linux/swap.h | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/swap.h b/include/linux/swap.h
> index 0f54b491e118..739d94397c47 100644
> --- a/include/linux/swap.h
> +++ b/include/linux/swap.h
> @@ -427,7 +427,8 @@ extern bool has_usable_swap(void);
>  
>  static inline bool swap_use_vma_readahead(void)
>  {
> - return READ_ONCE(swap_vma_readahead) && !atomic_read(_rotate_swap);
> + return page_cluster > 0 && READ_ONCE(swap_vma_readahead)
> + && !atomic_read(_rotate_swap);
>  }
>  
>  /* Swap 50% full? Release swapcache more aggressively.. */

Now the readahead window size of the VMA based swap readahead is
controlled by /sys/kernel/mm/swap/vma_ra_max_order, while that of the
original swap readahead is controlled by sysctl page_cluster.  It is
possible for anonymous memory to use VMA based swap readahead and tmpfs
to use original swap readahead algorithm at the same time.  So that, I
think it is necessary to use different control knob to control these two
algorithm.  So if we want to disable readahead for tmpfs, but keep it
for VMA based readahead, we can set 0 to page_cluster but non-zero to
/sys/kernel/mm/swap/vma_ra_max_order.  With your change, this will be
impossible.

Best Regards,
Huang, Ying


Re: [PATCH 4/5] mm:swap: respect page_cluster for readahead

2017-09-11 Thread Huang, Ying
Minchan Kim  writes:

> page_cluster 0 means "we don't want readahead" so in the case,
> let's skip the readahead detection logic.
>
> Cc: "Huang, Ying" 
> Signed-off-by: Minchan Kim 
> ---
>  include/linux/swap.h | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/swap.h b/include/linux/swap.h
> index 0f54b491e118..739d94397c47 100644
> --- a/include/linux/swap.h
> +++ b/include/linux/swap.h
> @@ -427,7 +427,8 @@ extern bool has_usable_swap(void);
>  
>  static inline bool swap_use_vma_readahead(void)
>  {
> - return READ_ONCE(swap_vma_readahead) && !atomic_read(_rotate_swap);
> + return page_cluster > 0 && READ_ONCE(swap_vma_readahead)
> + && !atomic_read(_rotate_swap);
>  }
>  
>  /* Swap 50% full? Release swapcache more aggressively.. */

Now the readahead window size of the VMA based swap readahead is
controlled by /sys/kernel/mm/swap/vma_ra_max_order, while that of the
original swap readahead is controlled by sysctl page_cluster.  It is
possible for anonymous memory to use VMA based swap readahead and tmpfs
to use original swap readahead algorithm at the same time.  So that, I
think it is necessary to use different control knob to control these two
algorithm.  So if we want to disable readahead for tmpfs, but keep it
for VMA based readahead, we can set 0 to page_cluster but non-zero to
/sys/kernel/mm/swap/vma_ra_max_order.  With your change, this will be
impossible.

Best Regards,
Huang, Ying


Re: btusb "firmware request while host is not available" at resume

2017-09-11 Thread Marcel Holtmann
Hi Luis,

 To confirm, reverting this fixes the problem I was seeing in 4.13.  I've
 queued it up for the next 4.13-stable release as well.
>>> 
>>> Commit 81f95076281f ("firmware: add sanity check on shutdown/suspend") may
>>> seem kludgy but the reason for it was to cleanup the horrible forced and
>>> required UMH lock even when the UMH lock was *not* even needed, which was 
>>> later
>>> removed via commit 06a45a93e7d34aa ("firmware: move umh try locks into the 
>>> umh
>>> code").
>> 
>> So what does this mean now that it is reverted?
> 
> We discuss what we should do about upkeeping a warning in the future, as
> I think technically the warning was still valid and it could help avoid
> racy lookups with the filesystem which otherwise could have gone unnoticed.
> 
>>> Removing the old UMH lock even when the UMH lock was *not* needed was the 
>>> right
>>> thing to do but commit 81f95076281f (("firmware: add sanity check on
>>> shutdown/suspend") was put in place as a safe guard as the lock was also
>>> placing an implicit sanity check on the API. It ensures the API with the 
>>> cache
>>> was used as designed, otherwise you do run the risk of *not getting the
>>> firmware you may need* -- Marcel seems to acknowledge this possibility.
>>> 
>>> It may be possible for us to already have in place safeguards so that upon
>>> resume we are ensuring the path to the firmware *is* available, so IMHO we
>>> should remove this *iff* we can provide this guarantee.  Otherwise the 
>>> check is
>>> valid. You see, although the UMH lock was bogus, it did implicitly ask the
>>> question: is it safe for *any* helper to run and make assumptions on the
>>> filesystem then?
>>> 
>>> In lieu of this question being answered the warning is valid given the 
>>> design
>>> of the firmware API and the having the cache available as a measure to 
>>> resolve
>>> this race.
>> 
>> I don't understand what you are trying to say here at all.
>> 
>> To be specific, what, if anything, is a problem with the current state
>> of Linus's tree (and the next 4.13-stable release)?
> 
> The warning is issued when drivers issue *new* firmware requests on resume. 
> The
> firmware API cache was designed to enable drivers to easily be able to request
> firmware on resume without concern about races against the filesystem, but in 
> order
> for this to work the drivers must have requested the firmware prior to 
> suspend.
> 
>> If something needs to be fixed, can you make a patch showing that?  Or
>> do we also need to revert anything else as well to get back to a "better
>> working" state?
> 
> I took a look at the driver and it seems that btusb_setup_intel_new() is
> not called after the driver is initialized, rather its called only when
> hci_dev_do_open() is called. Its not clear to me how you can end up calling
> this on resume but not prior to this on a running system. Feedback from
> someone more familiar with bt would be useful.
> 
> I'd have the call for firmware on probe, no processing would be needed, just
> a load to kick the cache into effect would suffice. This may require a bit
> of code shift so its best someone more familiar do this.
> 
> If it confirmed this information is helping avoid these races we can 
> reconsider
> re-instating the warn as a firmware dev debugging aid for developers.
> 
> If the race this warning complained about is indeed possible the same race is
> also possible for other usermode helpers. Its *why* the UMH lock was
> implemented, it however was never generalized.

we can not load firmware on probe() in most cases. The btusb.ko driver 
establishes the HCI transport. It is setup in probe() and then started in 
hci_dev_do_open() and if there is a vendor setup routine like 
btsub_setup_intel_new(), then it is executed. Most Bluetooth controllers (not 
all, but most) are doing firmware loading over the HCI transport with vendor 
specific commands.

And yes, if the firmware was already loaded, we would skip requesting it at 
all. Which means after suspend/resume cycle where the power to the controller 
is cut, then we are missing the firmware from the cache. Since we never loaded 
it in the first place.

So yes, we would have to redo parts of the vendor specific handling to always 
request the firmware, even if we do not need it right now. And frankly that is 
not obvious to anybody. We seem to have some patches for doing exactly that, 
but I have not gotten to review them in detail since they deal with vendor 
specific complex setup handling. Also this affects more than just Intel since 
all hardware where firmware loading is skipped if there is already firmware 
loaded are affected.

Regards

Marcel



Re: btusb "firmware request while host is not available" at resume

2017-09-11 Thread Marcel Holtmann
Hi Luis,

 To confirm, reverting this fixes the problem I was seeing in 4.13.  I've
 queued it up for the next 4.13-stable release as well.
>>> 
>>> Commit 81f95076281f ("firmware: add sanity check on shutdown/suspend") may
>>> seem kludgy but the reason for it was to cleanup the horrible forced and
>>> required UMH lock even when the UMH lock was *not* even needed, which was 
>>> later
>>> removed via commit 06a45a93e7d34aa ("firmware: move umh try locks into the 
>>> umh
>>> code").
>> 
>> So what does this mean now that it is reverted?
> 
> We discuss what we should do about upkeeping a warning in the future, as
> I think technically the warning was still valid and it could help avoid
> racy lookups with the filesystem which otherwise could have gone unnoticed.
> 
>>> Removing the old UMH lock even when the UMH lock was *not* needed was the 
>>> right
>>> thing to do but commit 81f95076281f (("firmware: add sanity check on
>>> shutdown/suspend") was put in place as a safe guard as the lock was also
>>> placing an implicit sanity check on the API. It ensures the API with the 
>>> cache
>>> was used as designed, otherwise you do run the risk of *not getting the
>>> firmware you may need* -- Marcel seems to acknowledge this possibility.
>>> 
>>> It may be possible for us to already have in place safeguards so that upon
>>> resume we are ensuring the path to the firmware *is* available, so IMHO we
>>> should remove this *iff* we can provide this guarantee.  Otherwise the 
>>> check is
>>> valid. You see, although the UMH lock was bogus, it did implicitly ask the
>>> question: is it safe for *any* helper to run and make assumptions on the
>>> filesystem then?
>>> 
>>> In lieu of this question being answered the warning is valid given the 
>>> design
>>> of the firmware API and the having the cache available as a measure to 
>>> resolve
>>> this race.
>> 
>> I don't understand what you are trying to say here at all.
>> 
>> To be specific, what, if anything, is a problem with the current state
>> of Linus's tree (and the next 4.13-stable release)?
> 
> The warning is issued when drivers issue *new* firmware requests on resume. 
> The
> firmware API cache was designed to enable drivers to easily be able to request
> firmware on resume without concern about races against the filesystem, but in 
> order
> for this to work the drivers must have requested the firmware prior to 
> suspend.
> 
>> If something needs to be fixed, can you make a patch showing that?  Or
>> do we also need to revert anything else as well to get back to a "better
>> working" state?
> 
> I took a look at the driver and it seems that btusb_setup_intel_new() is
> not called after the driver is initialized, rather its called only when
> hci_dev_do_open() is called. Its not clear to me how you can end up calling
> this on resume but not prior to this on a running system. Feedback from
> someone more familiar with bt would be useful.
> 
> I'd have the call for firmware on probe, no processing would be needed, just
> a load to kick the cache into effect would suffice. This may require a bit
> of code shift so its best someone more familiar do this.
> 
> If it confirmed this information is helping avoid these races we can 
> reconsider
> re-instating the warn as a firmware dev debugging aid for developers.
> 
> If the race this warning complained about is indeed possible the same race is
> also possible for other usermode helpers. Its *why* the UMH lock was
> implemented, it however was never generalized.

we can not load firmware on probe() in most cases. The btusb.ko driver 
establishes the HCI transport. It is setup in probe() and then started in 
hci_dev_do_open() and if there is a vendor setup routine like 
btsub_setup_intel_new(), then it is executed. Most Bluetooth controllers (not 
all, but most) are doing firmware loading over the HCI transport with vendor 
specific commands.

And yes, if the firmware was already loaded, we would skip requesting it at 
all. Which means after suspend/resume cycle where the power to the controller 
is cut, then we are missing the firmware from the cache. Since we never loaded 
it in the first place.

So yes, we would have to redo parts of the vendor specific handling to always 
request the firmware, even if we do not need it right now. And frankly that is 
not obvious to anybody. We seem to have some patches for doing exactly that, 
but I have not gotten to review them in detail since they deal with vendor 
specific complex setup handling. Also this affects more than just Intel since 
all hardware where firmware loading is skipped if there is already firmware 
loaded are affected.

Regards

Marcel



[PATCH v2 4/5] ext4: add ext4_should_use_dax()

2017-09-11 Thread Ross Zwisler
This helper, in the spirit of ext4_should_dioread_nolock() et al., replaces
the complex conditional in ext4_set_inode_flags().

Signed-off-by: Ross Zwisler 
---
 fs/ext4/inode.c | 19 ---
 1 file changed, 16 insertions(+), 3 deletions(-)

diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index 3207333..525dd63 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -4577,6 +4577,21 @@ int ext4_get_inode_loc(struct inode *inode, struct 
ext4_iloc *iloc)
!ext4_test_inode_state(inode, EXT4_STATE_XATTR));
 }
 
+static bool ext4_should_use_dax(struct inode *inode)
+{
+   if (!test_opt(inode->i_sb, DAX))
+   return false;
+   if (!S_ISREG(inode->i_mode))
+   return false;
+   if (ext4_should_journal_data(inode))
+   return false;
+   if (ext4_has_inline_data(inode))
+   return false;
+   if (ext4_encrypted_inode(inode))
+   return false;
+   return true;
+}
+
 void ext4_set_inode_flags(struct inode *inode)
 {
unsigned int flags = EXT4_I(inode)->i_flags;
@@ -4592,9 +4607,7 @@ void ext4_set_inode_flags(struct inode *inode)
new_fl |= S_NOATIME;
if (flags & EXT4_DIRSYNC_FL)
new_fl |= S_DIRSYNC;
-   if (test_opt(inode->i_sb, DAX) && S_ISREG(inode->i_mode) &&
-   !ext4_should_journal_data(inode) && !ext4_has_inline_data(inode) &&
-   !ext4_encrypted_inode(inode))
+   if (ext4_should_use_dax(inode))
new_fl |= S_DAX;
inode_set_flags(inode, new_fl,
S_SYNC|S_APPEND|S_IMMUTABLE|S_NOATIME|S_DIRSYNC|S_DAX);
-- 
2.9.5



[PATCH v2 4/5] ext4: add ext4_should_use_dax()

2017-09-11 Thread Ross Zwisler
This helper, in the spirit of ext4_should_dioread_nolock() et al., replaces
the complex conditional in ext4_set_inode_flags().

Signed-off-by: Ross Zwisler 
---
 fs/ext4/inode.c | 19 ---
 1 file changed, 16 insertions(+), 3 deletions(-)

diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index 3207333..525dd63 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -4577,6 +4577,21 @@ int ext4_get_inode_loc(struct inode *inode, struct 
ext4_iloc *iloc)
!ext4_test_inode_state(inode, EXT4_STATE_XATTR));
 }
 
+static bool ext4_should_use_dax(struct inode *inode)
+{
+   if (!test_opt(inode->i_sb, DAX))
+   return false;
+   if (!S_ISREG(inode->i_mode))
+   return false;
+   if (ext4_should_journal_data(inode))
+   return false;
+   if (ext4_has_inline_data(inode))
+   return false;
+   if (ext4_encrypted_inode(inode))
+   return false;
+   return true;
+}
+
 void ext4_set_inode_flags(struct inode *inode)
 {
unsigned int flags = EXT4_I(inode)->i_flags;
@@ -4592,9 +4607,7 @@ void ext4_set_inode_flags(struct inode *inode)
new_fl |= S_NOATIME;
if (flags & EXT4_DIRSYNC_FL)
new_fl |= S_DIRSYNC;
-   if (test_opt(inode->i_sb, DAX) && S_ISREG(inode->i_mode) &&
-   !ext4_should_journal_data(inode) && !ext4_has_inline_data(inode) &&
-   !ext4_encrypted_inode(inode))
+   if (ext4_should_use_dax(inode))
new_fl |= S_DAX;
inode_set_flags(inode, new_fl,
S_SYNC|S_APPEND|S_IMMUTABLE|S_NOATIME|S_DIRSYNC|S_DAX);
-- 
2.9.5



[PATCH v2 5/5] ext4: remove duplicate extended attributes defs

2017-09-11 Thread Ross Zwisler
The following commit:

commit 9b7365fc1c82 ("ext4: add FS_IOC_FSSETXATTR/FS_IOC_FSGETXATTR
interface support")

added several defines related to extended attributes to ext4.h.  They were
added within an #ifndef FS_IOC_FSGETXATTR block with the comment:

/* Until the uapi changes get merged for project quota... */

Those uapi changes were merged by this commit:

commit 334e580a6f97 ("fs: XFS_IOC_FS[SG]SETXATTR to FS_IOC_FS[SG]ETXATTR
promotion")

so all the definitions needed by ext4 are available in
include/uapi/linux/fs.h.  Remove the duplicates from ext4.h.

Signed-off-by: Ross Zwisler 
Reviewed-by: Jan Kara 
Cc: Li Xi 
Cc: Theodore Ts'o 
Cc: Andreas Dilger 
Cc: Jan Kara 
Cc: Dave Chinner 
---
 fs/ext4/ext4.h | 37 -
 1 file changed, 37 deletions(-)

diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
index 84b9da1..83a857f 100644
--- a/fs/ext4/ext4.h
+++ b/fs/ext4/ext4.h
@@ -644,43 +644,6 @@ enum {
 #define EXT4_IOC_GET_ENCRYPTION_PWSALT FS_IOC_GET_ENCRYPTION_PWSALT
 #define EXT4_IOC_GET_ENCRYPTION_POLICY FS_IOC_GET_ENCRYPTION_POLICY
 
-#ifndef FS_IOC_FSGETXATTR
-/* Until the uapi changes get merged for project quota... */
-
-#define FS_IOC_FSGETXATTR  _IOR('X', 31, struct fsxattr)
-#define FS_IOC_FSSETXATTR  _IOW('X', 32, struct fsxattr)
-
-/*
- * Structure for FS_IOC_FSGETXATTR and FS_IOC_FSSETXATTR.
- */
-struct fsxattr {
-   __u32   fsx_xflags; /* xflags field value (get/set) */
-   __u32   fsx_extsize;/* extsize field value (get/set)*/
-   __u32   fsx_nextents;   /* nextents field value (get)   */
-   __u32   fsx_projid; /* project identifier (get/set) */
-   unsigned char   fsx_pad[12];
-};
-
-/*
- * Flags for the fsx_xflags field
- */
-#define FS_XFLAG_REALTIME  0x0001  /* data in realtime volume */
-#define FS_XFLAG_PREALLOC  0x0002  /* preallocated file extents */
-#define FS_XFLAG_IMMUTABLE 0x0008  /* file cannot be modified */
-#define FS_XFLAG_APPEND0x0010  /* all writes append */
-#define FS_XFLAG_SYNC  0x0020  /* all writes synchronous */
-#define FS_XFLAG_NOATIME   0x0040  /* do not update access time */
-#define FS_XFLAG_NODUMP0x0080  /* do not include in 
backups */
-#define FS_XFLAG_RTINHERIT 0x0100  /* create with rt bit set */
-#define FS_XFLAG_PROJINHERIT   0x0200  /* create with parents projid */
-#define FS_XFLAG_NOSYMLINKS0x0400  /* disallow symlink creation */
-#define FS_XFLAG_EXTSIZE   0x0800  /* extent size allocator hint */
-#define FS_XFLAG_EXTSZINHERIT  0x1000  /* inherit inode extent size */
-#define FS_XFLAG_NODEFRAG  0x2000  /* do not defragment */
-#define FS_XFLAG_FILESTREAM0x4000  /* use filestream allocator */
-#define FS_XFLAG_HASATTR   0x8000  /* no DIFLAG for this */
-#endif /* !defined(FS_IOC_FSGETXATTR) */
-
 #define EXT4_IOC_FSGETXATTRFS_IOC_FSGETXATTR
 #define EXT4_IOC_FSSETXATTRFS_IOC_FSSETXATTR
 
-- 
2.9.5



[PATCH v2 1/5] ext4: prevent data corruption with inline data + DAX

2017-09-11 Thread Ross Zwisler
If an inode has inline data it is currently prevented from using DAX by a
check in ext4_set_inode_flags().  When the inode grows inline data via
ext4_create_inline_data() or removes its inline data via
ext4_destroy_inline_data_nolock(), the value of S_DAX can change.

Currently these changes are unsafe because we don't hold off page faults
and I/O, write back dirty radix tree entries and invalidate all mappings.
There are also issues with mm-level races when changing the value of S_DAX,
as well as issues with the VM_MIXEDMAP flag:

https://www.spinics.net/lists/linux-xfs/msg09859.html

The unsafe transition of S_DAX can reliably cause data corruption, as shown
by the following fstest:

https://patchwork.kernel.org/patch/9948381/

Fix this issue by preventing the DAX mount option from being used on
filesystems that were created to support inline data.  Inline data is an
option given to mkfs.ext4.

Signed-off-by: Ross Zwisler 
CC: sta...@vger.kernel.org
---
 fs/ext4/inline.c | 10 --
 fs/ext4/super.c  |  5 +
 2 files changed, 5 insertions(+), 10 deletions(-)

diff --git a/fs/ext4/inline.c b/fs/ext4/inline.c
index 28c5c3a..fd95019 100644
--- a/fs/ext4/inline.c
+++ b/fs/ext4/inline.c
@@ -302,11 +302,6 @@ static int ext4_create_inline_data(handle_t *handle,
EXT4_I(inode)->i_inline_size = len + EXT4_MIN_INLINE_DATA_SIZE;
ext4_clear_inode_flag(inode, EXT4_INODE_EXTENTS);
ext4_set_inode_flag(inode, EXT4_INODE_INLINE_DATA);
-   /*
-* Propagate changes to inode->i_flags as well - e.g. S_DAX may
-* get cleared
-*/
-   ext4_set_inode_flags(inode);
get_bh(is.iloc.bh);
error = ext4_mark_iloc_dirty(handle, inode, );
 
@@ -451,11 +446,6 @@ static int ext4_destroy_inline_data_nolock(handle_t 
*handle,
}
}
ext4_clear_inode_flag(inode, EXT4_INODE_INLINE_DATA);
-   /*
-* Propagate changes to inode->i_flags as well - e.g. S_DAX may
-* get set.
-*/
-   ext4_set_inode_flags(inode);
 
get_bh(is.iloc.bh);
error = ext4_mark_iloc_dirty(handle, inode, );
diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index c9e7be5..4251e50 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -3707,6 +3707,11 @@ static int ext4_fill_super(struct super_block *sb, void 
*data, int silent)
}
 
if (sbi->s_mount_opt & EXT4_MOUNT_DAX) {
+   if (ext4_has_feature_inline_data(sb)) {
+   ext4_msg(sb, KERN_ERR, "Cannot use DAX on a filesystem"
+   " that may contain inline data");
+   goto failed_mount;
+   }
err = bdev_dax_supported(sb, blocksize);
if (err)
goto failed_mount;
-- 
2.9.5



[PATCH v2 5/5] ext4: remove duplicate extended attributes defs

2017-09-11 Thread Ross Zwisler
The following commit:

commit 9b7365fc1c82 ("ext4: add FS_IOC_FSSETXATTR/FS_IOC_FSGETXATTR
interface support")

added several defines related to extended attributes to ext4.h.  They were
added within an #ifndef FS_IOC_FSGETXATTR block with the comment:

/* Until the uapi changes get merged for project quota... */

Those uapi changes were merged by this commit:

commit 334e580a6f97 ("fs: XFS_IOC_FS[SG]SETXATTR to FS_IOC_FS[SG]ETXATTR
promotion")

so all the definitions needed by ext4 are available in
include/uapi/linux/fs.h.  Remove the duplicates from ext4.h.

Signed-off-by: Ross Zwisler 
Reviewed-by: Jan Kara 
Cc: Li Xi 
Cc: Theodore Ts'o 
Cc: Andreas Dilger 
Cc: Jan Kara 
Cc: Dave Chinner 
---
 fs/ext4/ext4.h | 37 -
 1 file changed, 37 deletions(-)

diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
index 84b9da1..83a857f 100644
--- a/fs/ext4/ext4.h
+++ b/fs/ext4/ext4.h
@@ -644,43 +644,6 @@ enum {
 #define EXT4_IOC_GET_ENCRYPTION_PWSALT FS_IOC_GET_ENCRYPTION_PWSALT
 #define EXT4_IOC_GET_ENCRYPTION_POLICY FS_IOC_GET_ENCRYPTION_POLICY
 
-#ifndef FS_IOC_FSGETXATTR
-/* Until the uapi changes get merged for project quota... */
-
-#define FS_IOC_FSGETXATTR  _IOR('X', 31, struct fsxattr)
-#define FS_IOC_FSSETXATTR  _IOW('X', 32, struct fsxattr)
-
-/*
- * Structure for FS_IOC_FSGETXATTR and FS_IOC_FSSETXATTR.
- */
-struct fsxattr {
-   __u32   fsx_xflags; /* xflags field value (get/set) */
-   __u32   fsx_extsize;/* extsize field value (get/set)*/
-   __u32   fsx_nextents;   /* nextents field value (get)   */
-   __u32   fsx_projid; /* project identifier (get/set) */
-   unsigned char   fsx_pad[12];
-};
-
-/*
- * Flags for the fsx_xflags field
- */
-#define FS_XFLAG_REALTIME  0x0001  /* data in realtime volume */
-#define FS_XFLAG_PREALLOC  0x0002  /* preallocated file extents */
-#define FS_XFLAG_IMMUTABLE 0x0008  /* file cannot be modified */
-#define FS_XFLAG_APPEND0x0010  /* all writes append */
-#define FS_XFLAG_SYNC  0x0020  /* all writes synchronous */
-#define FS_XFLAG_NOATIME   0x0040  /* do not update access time */
-#define FS_XFLAG_NODUMP0x0080  /* do not include in 
backups */
-#define FS_XFLAG_RTINHERIT 0x0100  /* create with rt bit set */
-#define FS_XFLAG_PROJINHERIT   0x0200  /* create with parents projid */
-#define FS_XFLAG_NOSYMLINKS0x0400  /* disallow symlink creation */
-#define FS_XFLAG_EXTSIZE   0x0800  /* extent size allocator hint */
-#define FS_XFLAG_EXTSZINHERIT  0x1000  /* inherit inode extent size */
-#define FS_XFLAG_NODEFRAG  0x2000  /* do not defragment */
-#define FS_XFLAG_FILESTREAM0x4000  /* use filestream allocator */
-#define FS_XFLAG_HASATTR   0x8000  /* no DIFLAG for this */
-#endif /* !defined(FS_IOC_FSGETXATTR) */
-
 #define EXT4_IOC_FSGETXATTRFS_IOC_FSGETXATTR
 #define EXT4_IOC_FSSETXATTRFS_IOC_FSSETXATTR
 
-- 
2.9.5



[PATCH v2 1/5] ext4: prevent data corruption with inline data + DAX

2017-09-11 Thread Ross Zwisler
If an inode has inline data it is currently prevented from using DAX by a
check in ext4_set_inode_flags().  When the inode grows inline data via
ext4_create_inline_data() or removes its inline data via
ext4_destroy_inline_data_nolock(), the value of S_DAX can change.

Currently these changes are unsafe because we don't hold off page faults
and I/O, write back dirty radix tree entries and invalidate all mappings.
There are also issues with mm-level races when changing the value of S_DAX,
as well as issues with the VM_MIXEDMAP flag:

https://www.spinics.net/lists/linux-xfs/msg09859.html

The unsafe transition of S_DAX can reliably cause data corruption, as shown
by the following fstest:

https://patchwork.kernel.org/patch/9948381/

Fix this issue by preventing the DAX mount option from being used on
filesystems that were created to support inline data.  Inline data is an
option given to mkfs.ext4.

Signed-off-by: Ross Zwisler 
CC: sta...@vger.kernel.org
---
 fs/ext4/inline.c | 10 --
 fs/ext4/super.c  |  5 +
 2 files changed, 5 insertions(+), 10 deletions(-)

diff --git a/fs/ext4/inline.c b/fs/ext4/inline.c
index 28c5c3a..fd95019 100644
--- a/fs/ext4/inline.c
+++ b/fs/ext4/inline.c
@@ -302,11 +302,6 @@ static int ext4_create_inline_data(handle_t *handle,
EXT4_I(inode)->i_inline_size = len + EXT4_MIN_INLINE_DATA_SIZE;
ext4_clear_inode_flag(inode, EXT4_INODE_EXTENTS);
ext4_set_inode_flag(inode, EXT4_INODE_INLINE_DATA);
-   /*
-* Propagate changes to inode->i_flags as well - e.g. S_DAX may
-* get cleared
-*/
-   ext4_set_inode_flags(inode);
get_bh(is.iloc.bh);
error = ext4_mark_iloc_dirty(handle, inode, );
 
@@ -451,11 +446,6 @@ static int ext4_destroy_inline_data_nolock(handle_t 
*handle,
}
}
ext4_clear_inode_flag(inode, EXT4_INODE_INLINE_DATA);
-   /*
-* Propagate changes to inode->i_flags as well - e.g. S_DAX may
-* get set.
-*/
-   ext4_set_inode_flags(inode);
 
get_bh(is.iloc.bh);
error = ext4_mark_iloc_dirty(handle, inode, );
diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index c9e7be5..4251e50 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -3707,6 +3707,11 @@ static int ext4_fill_super(struct super_block *sb, void 
*data, int silent)
}
 
if (sbi->s_mount_opt & EXT4_MOUNT_DAX) {
+   if (ext4_has_feature_inline_data(sb)) {
+   ext4_msg(sb, KERN_ERR, "Cannot use DAX on a filesystem"
+   " that may contain inline data");
+   goto failed_mount;
+   }
err = bdev_dax_supported(sb, blocksize);
if (err)
goto failed_mount;
-- 
2.9.5



[PATCH v2 0/5] ext4: DAX data corruption fixes

2017-09-11 Thread Ross Zwisler
This series prevents a pair of data corruptions with ext4 + DAX.  The first
such corruption happens when combining the inline data feature with DAX,
and the second happens when combining data journaling with DAX.

Both can be reliably reproduced with the fstests that I have posted here:

https://patchwork.kernel.org/patch/9948377/
https://patchwork.kernel.org/patch/9948381/

My opinion is that the first three patches in this series should be applied
to the v4.14 RC series and backported to stable.  The last two patches in
this series are just cleanup and can probably wait until v4.15.

Ross Zwisler (5):
  ext4: prevent data corruption with inline data + DAX
  ext4: prevent data corruption with journaling + DAX
  ext4: add sanity check for encryption + DAX
  ext4: add ext4_should_use_dax()
  ext4: remove duplicate extended attributes defs

 fs/ext4/ext4.h   | 37 -
 fs/ext4/inline.c | 10 --
 fs/ext4/inode.c  | 24 
 fs/ext4/ioctl.c  | 16 +---
 fs/ext4/super.c  |  8 
 5 files changed, 37 insertions(+), 58 deletions(-)

-- 
2.9.5



[PATCH v2 0/5] ext4: DAX data corruption fixes

2017-09-11 Thread Ross Zwisler
This series prevents a pair of data corruptions with ext4 + DAX.  The first
such corruption happens when combining the inline data feature with DAX,
and the second happens when combining data journaling with DAX.

Both can be reliably reproduced with the fstests that I have posted here:

https://patchwork.kernel.org/patch/9948377/
https://patchwork.kernel.org/patch/9948381/

My opinion is that the first three patches in this series should be applied
to the v4.14 RC series and backported to stable.  The last two patches in
this series are just cleanup and can probably wait until v4.15.

Ross Zwisler (5):
  ext4: prevent data corruption with inline data + DAX
  ext4: prevent data corruption with journaling + DAX
  ext4: add sanity check for encryption + DAX
  ext4: add ext4_should_use_dax()
  ext4: remove duplicate extended attributes defs

 fs/ext4/ext4.h   | 37 -
 fs/ext4/inline.c | 10 --
 fs/ext4/inode.c  | 24 
 fs/ext4/ioctl.c  | 16 +---
 fs/ext4/super.c  |  8 
 5 files changed, 37 insertions(+), 58 deletions(-)

-- 
2.9.5



[PATCH v2 3/5] ext4: add sanity check for encryption + DAX

2017-09-11 Thread Ross Zwisler
We prevent DAX from being used on inodes which are using ext4's built in
encryption via a check in ext4_set_inode_flags().  We do have what appears
to be an unsafe transition of S_DAX in ext4_set_context(), though, where
S_DAX can get disabled without us doing a proper writeback + invalidate.

There are also issues with mm-level races when changing the value of S_DAX,
as well as issues with the VM_MIXEDMAP flag:

https://www.spinics.net/lists/linux-xfs/msg09859.html

I actually think we are safe in this case because of the following:

1) You can't encrypt an existing file.  Encryption can only be set on an
empty directory, with new inodes in that directory being created with
encryption turned on, so I don't think it's possible to turn encryption on
for a file that has open DAX mmaps or outstanding I/Os.

2) There is no way to turn encryption off on a given file.  Once an inode
is encrypted, it stays encrypted for the life of that inode, so we don't
have to worry about the case where we turn encryption off and S_DAX
suddenly turns on.

3) The only way we end up in ext4_set_context() to turn on encryption is
when we are creating a new file in the encrypted directory.  This happens
as part of ext4_create() before the inode has been allowed to do any I/O.
Here's the call tree:

 ext4_create()
   __ext4_new_inode()
 ext4_set_inode_flags() // sets S_DAX
 fscrypt_inherit_context()
fscrypt_get_encryption_info();
ext4_set_context() // sets EXT4_INODE_ENCRYPT, clears S_DAX

So, I actually think it's safe to transition S_DAX in ext4_set_context()
without any locking, writebacks or invalidations.  I've added a
WARN_ON_ONCE() sanity check to make sure that we are notified if we ever
encounter a case where we are encrypting an inode that already has data,
in which case we need to add code to safely transition S_DAX.

Signed-off-by: Ross Zwisler 
CC: sta...@vger.kernel.org
---
 fs/ext4/super.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index 4251e50..c090780 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -1159,6 +1159,9 @@ static int ext4_set_context(struct inode *inode, const 
void *ctx, size_t len,
if (inode->i_ino == EXT4_ROOT_INO)
return -EPERM;
 
+   if (WARN_ON_ONCE(IS_DAX(inode) && i_size_read(inode)))
+   return -EINVAL;
+
res = ext4_convert_inline_data(inode);
if (res)
return res;
-- 
2.9.5



[PATCH v2 3/5] ext4: add sanity check for encryption + DAX

2017-09-11 Thread Ross Zwisler
We prevent DAX from being used on inodes which are using ext4's built in
encryption via a check in ext4_set_inode_flags().  We do have what appears
to be an unsafe transition of S_DAX in ext4_set_context(), though, where
S_DAX can get disabled without us doing a proper writeback + invalidate.

There are also issues with mm-level races when changing the value of S_DAX,
as well as issues with the VM_MIXEDMAP flag:

https://www.spinics.net/lists/linux-xfs/msg09859.html

I actually think we are safe in this case because of the following:

1) You can't encrypt an existing file.  Encryption can only be set on an
empty directory, with new inodes in that directory being created with
encryption turned on, so I don't think it's possible to turn encryption on
for a file that has open DAX mmaps or outstanding I/Os.

2) There is no way to turn encryption off on a given file.  Once an inode
is encrypted, it stays encrypted for the life of that inode, so we don't
have to worry about the case where we turn encryption off and S_DAX
suddenly turns on.

3) The only way we end up in ext4_set_context() to turn on encryption is
when we are creating a new file in the encrypted directory.  This happens
as part of ext4_create() before the inode has been allowed to do any I/O.
Here's the call tree:

 ext4_create()
   __ext4_new_inode()
 ext4_set_inode_flags() // sets S_DAX
 fscrypt_inherit_context()
fscrypt_get_encryption_info();
ext4_set_context() // sets EXT4_INODE_ENCRYPT, clears S_DAX

So, I actually think it's safe to transition S_DAX in ext4_set_context()
without any locking, writebacks or invalidations.  I've added a
WARN_ON_ONCE() sanity check to make sure that we are notified if we ever
encounter a case where we are encrypting an inode that already has data,
in which case we need to add code to safely transition S_DAX.

Signed-off-by: Ross Zwisler 
CC: sta...@vger.kernel.org
---
 fs/ext4/super.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index 4251e50..c090780 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -1159,6 +1159,9 @@ static int ext4_set_context(struct inode *inode, const 
void *ctx, size_t len,
if (inode->i_ino == EXT4_ROOT_INO)
return -EPERM;
 
+   if (WARN_ON_ONCE(IS_DAX(inode) && i_size_read(inode)))
+   return -EINVAL;
+
res = ext4_convert_inline_data(inode);
if (res)
return res;
-- 
2.9.5



[PATCH v2 2/5] ext4: prevent data corruption with journaling + DAX

2017-09-11 Thread Ross Zwisler
The current code has the potential for data corruption when changing an
inode's journaling mode, as that can result in a subsequent unsafe change
in S_DAX.

I've captured an instance of this data corruption in the following fstest:

https://patchwork.kernel.org/patch/9948377/

Prevent this data corruption from happening by disallowing changes to the
journaling mode if the '-o dax' mount option was used.  This means that for
a given filesystem we could have a mix of inodes using either DAX or
data journaling, but whatever state the inodes are in will be held for the
duration of the mount.

Signed-off-by: Ross Zwisler 
Suggested-by: Jan Kara 
---
 fs/ext4/inode.c |  5 -
 fs/ext4/ioctl.c | 16 +---
 2 files changed, 13 insertions(+), 8 deletions(-)

diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index e963508..3207333 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -5971,11 +5971,6 @@ int ext4_change_inode_journal_flag(struct inode *inode, 
int val)
ext4_clear_inode_flag(inode, EXT4_INODE_JOURNAL_DATA);
}
ext4_set_aops(inode);
-   /*
-* Update inode->i_flags after EXT4_INODE_JOURNAL_DATA was updated.
-* E.g. S_DAX may get cleared / set.
-*/
-   ext4_set_inode_flags(inode);
 
jbd2_journal_unlock_updates(journal);
percpu_up_write(>s_journal_flag_rwsem);
diff --git a/fs/ext4/ioctl.c b/fs/ext4/ioctl.c
index afb66d4..b0b754b 100644
--- a/fs/ext4/ioctl.c
+++ b/fs/ext4/ioctl.c
@@ -290,10 +290,20 @@ static int ext4_ioctl_setflags(struct inode *inode,
if (err)
goto flags_out;
 
-   if ((jflag ^ oldflags) & (EXT4_JOURNAL_DATA_FL))
+   if ((jflag ^ oldflags) & (EXT4_JOURNAL_DATA_FL)) {
+   /*
+* Changes to the journaling mode can cause unsafe changes to
+* S_DAX if we are using the DAX mount option.
+*/
+   if (test_opt(inode->i_sb, DAX)) {
+   err = -EBUSY;
+   goto flags_out;
+   }
+
err = ext4_change_inode_journal_flag(inode, jflag);
-   if (err)
-   goto flags_out;
+   if (err)
+   goto flags_out;
+   }
if (migrate) {
if (flags & EXT4_EXTENTS_FL)
err = ext4_ext_migrate(inode);
-- 
2.9.5



[PATCH v2 2/5] ext4: prevent data corruption with journaling + DAX

2017-09-11 Thread Ross Zwisler
The current code has the potential for data corruption when changing an
inode's journaling mode, as that can result in a subsequent unsafe change
in S_DAX.

I've captured an instance of this data corruption in the following fstest:

https://patchwork.kernel.org/patch/9948377/

Prevent this data corruption from happening by disallowing changes to the
journaling mode if the '-o dax' mount option was used.  This means that for
a given filesystem we could have a mix of inodes using either DAX or
data journaling, but whatever state the inodes are in will be held for the
duration of the mount.

Signed-off-by: Ross Zwisler 
Suggested-by: Jan Kara 
---
 fs/ext4/inode.c |  5 -
 fs/ext4/ioctl.c | 16 +---
 2 files changed, 13 insertions(+), 8 deletions(-)

diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index e963508..3207333 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -5971,11 +5971,6 @@ int ext4_change_inode_journal_flag(struct inode *inode, 
int val)
ext4_clear_inode_flag(inode, EXT4_INODE_JOURNAL_DATA);
}
ext4_set_aops(inode);
-   /*
-* Update inode->i_flags after EXT4_INODE_JOURNAL_DATA was updated.
-* E.g. S_DAX may get cleared / set.
-*/
-   ext4_set_inode_flags(inode);
 
jbd2_journal_unlock_updates(journal);
percpu_up_write(>s_journal_flag_rwsem);
diff --git a/fs/ext4/ioctl.c b/fs/ext4/ioctl.c
index afb66d4..b0b754b 100644
--- a/fs/ext4/ioctl.c
+++ b/fs/ext4/ioctl.c
@@ -290,10 +290,20 @@ static int ext4_ioctl_setflags(struct inode *inode,
if (err)
goto flags_out;
 
-   if ((jflag ^ oldflags) & (EXT4_JOURNAL_DATA_FL))
+   if ((jflag ^ oldflags) & (EXT4_JOURNAL_DATA_FL)) {
+   /*
+* Changes to the journaling mode can cause unsafe changes to
+* S_DAX if we are using the DAX mount option.
+*/
+   if (test_opt(inode->i_sb, DAX)) {
+   err = -EBUSY;
+   goto flags_out;
+   }
+
err = ext4_change_inode_journal_flag(inode, jflag);
-   if (err)
-   goto flags_out;
+   if (err)
+   goto flags_out;
+   }
if (migrate) {
if (flags & EXT4_EXTENTS_FL)
err = ext4_ext_migrate(inode);
-- 
2.9.5



[PATCH 2/2] zram: remove zlib from the list of recommended algorithms

2017-09-11 Thread Sergey Senozhatsky
ZSTD tends to outperform deflate/inflate, thus we remove
zlib from the list of recommended algorithms and recommend
zstd instead.

Signed-off-by: Sergey Senozhatsky 
Suggested-by: Minchan Kim 
---
 drivers/block/zram/zcomp.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/block/zram/zcomp.c b/drivers/block/zram/zcomp.c
index cc66daec7bbc..4ed0a78fdc09 100644
--- a/drivers/block/zram/zcomp.c
+++ b/drivers/block/zram/zcomp.c
@@ -23,9 +23,6 @@ static const char * const backends[] = {
 #if IS_ENABLED(CONFIG_CRYPTO_LZ4)
"lz4",
 #endif
-#if IS_ENABLED(CONFIG_CRYPTO_DEFLATE)
-   "deflate",
-#endif
 #if IS_ENABLED(CONFIG_CRYPTO_LZ4HC)
"lz4hc",
 #endif
-- 
2.14.1



[PATCH 2/2] zram: remove zlib from the list of recommended algorithms

2017-09-11 Thread Sergey Senozhatsky
ZSTD tends to outperform deflate/inflate, thus we remove
zlib from the list of recommended algorithms and recommend
zstd instead.

Signed-off-by: Sergey Senozhatsky 
Suggested-by: Minchan Kim 
---
 drivers/block/zram/zcomp.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/block/zram/zcomp.c b/drivers/block/zram/zcomp.c
index cc66daec7bbc..4ed0a78fdc09 100644
--- a/drivers/block/zram/zcomp.c
+++ b/drivers/block/zram/zcomp.c
@@ -23,9 +23,6 @@ static const char * const backends[] = {
 #if IS_ENABLED(CONFIG_CRYPTO_LZ4)
"lz4",
 #endif
-#if IS_ENABLED(CONFIG_CRYPTO_DEFLATE)
-   "deflate",
-#endif
 #if IS_ENABLED(CONFIG_CRYPTO_LZ4HC)
"lz4hc",
 #endif
-- 
2.14.1



[PATCH 1/2] zram: add zstd to the supported algorithms list

2017-09-11 Thread Sergey Senozhatsky
Add ZSTD to the list of supported compression algorithms.

ZRAM fio perf test:

  LZO DEFLATE ZSTD

#jobs1
WRITE:  (2180MB/s)   (77.2MB/s)  (1429MB/s)
WRITE:  (1617MB/s)   (77.7MB/s)  (1202MB/s)
READ:(426MB/s)   (595MB/s)   (1181MB/s)
READ:(422MB/s)   (572MB/s)   (1020MB/s)
READ:(318MB/s)   (67.8MB/s)  (563MB/s)
WRITE:   (318MB/s)   (67.9MB/s)  (564MB/s)
READ:(336MB/s)   (68.3MB/s)  (583MB/s)
WRITE:   (335MB/s)   (68.2MB/s)  (582MB/s)
#jobs2
WRITE:  (3441MB/s)   (152MB/s)   (2141MB/s)
WRITE:  (2507MB/s)   (147MB/s)   (1888MB/s)
READ:(801MB/s)   (1146MB/s)  (1890MB/s)
READ:(767MB/s)   (1096MB/s)  (2073MB/s)
READ:(621MB/s)   (126MB/s)   (1009MB/s)
WRITE:   (621MB/s)   (126MB/s)   (1009MB/s)
READ:(656MB/s)   (125MB/s)   (1075MB/s)
WRITE:   (657MB/s)   (126MB/s)   (1077MB/s)
#jobs3
WRITE:  (4772MB/s)   (225MB/s)   (3394MB/s)
WRITE:  (3905MB/s)   (211MB/s)   (2939MB/s)
READ:   (1216MB/s)   (1608MB/s)  (3218MB/s)
READ:   (1159MB/s)   (1431MB/s)  (2981MB/s)
READ:(906MB/s)   (156MB/s)   (1457MB/s)
WRITE:   (907MB/s)   (156MB/s)   (1458MB/s)
READ:(953MB/s)   (158MB/s)   (1595MB/s)
WRITE:   (952MB/s)   (157MB/s)   (1593MB/s)
#jobs4
WRITE:  (6036MB/s)   (265MB/s)   (4469MB/s)
WRITE:  (5059MB/s)   (263MB/s)   (3951MB/s)
READ:   (1618MB/s)   (2066MB/s)  (4276MB/s)
READ:   (1573MB/s)   (1942MB/s)  (3830MB/s)
READ:   (1202MB/s)   (227MB/s)   (1971MB/s)
WRITE:  (1200MB/s)   (227MB/s)   (1968MB/s)
READ:   (1265MB/s)   (226MB/s)   (2116MB/s)
WRITE:  (1264MB/s)   (226MB/s)   (2114MB/s)
#jobs5
WRITE:  (5339MB/s)   (233MB/s)   (3781MB/s)
WRITE:  (4298MB/s)   (234MB/s)   (3276MB/s)
READ:   (1626MB/s)   (2048MB/s)  (4081MB/s)
READ:   (1567MB/s)   (1929MB/s)  (3758MB/s)
READ:   (1174MB/s)   (205MB/s)   (1747MB/s)
WRITE:  (1173MB/s)   (204MB/s)   (1746MB/s)
READ:   (1214MB/s)   (208MB/s)   (1890MB/s)
WRITE:  (1215MB/s)   (208MB/s)   (1892MB/s)
#jobs6
WRITE:  (5666MB/s)   (270MB/s)   (4338MB/s)
WRITE:  (4828MB/s)   (267MB/s)   (3772MB/s)
READ:   (1803MB/s)   (2058MB/s)  (4946MB/s)
READ:   (1805MB/s)   (2156MB/s)  (4711MB/s)
READ:   (1334MB/s)   (235MB/s)   (2135MB/s)
WRITE:  (1335MB/s)   (235MB/s)   (2137MB/s)
READ:   (1364MB/s)   (236MB/s)   (2268MB/s)
WRITE:  (1365MB/s)   (237MB/s)   (2270MB/s)
#jobs7
WRITE:  (5474MB/s)   (270MB/s)   (4300MB/s)
WRITE:  (4666MB/s)   (266MB/s)   (3817MB/s)
READ:   (2022MB/s)   (2319MB/s)  (5472MB/s)
READ:   (1924MB/s)   (2260MB/s)  (5031MB/s)
READ:   (1369MB/s)   (242MB/s)   (2153MB/s)
WRITE:  (1370MB/s)   (242MB/s)   (2155MB/s)
READ:   (1499MB/s)   (246MB/s)   (2310MB/s)
WRITE:  (1497MB/s)   (246MB/s)   (2307MB/s)
#jobs8
WRITE:  (5558MB/s)   (273MB/s)   (4439MB/s)
WRITE:  (4763MB/s)   (271MB/s)   (3918MB/s)
READ:   (2201MB/s)   (2599MB/s)  (6062MB/s)
READ:   (2105MB/s)   (2463MB/s)  (5413MB/s)
READ:   (1490MB/s)   (252MB/s)   (2238MB/s)
WRITE:  (1488MB/s)   (252MB/s)   (2236MB/s)
READ:   (1566MB/s)   (254MB/s)   (2434MB/s)
WRITE:  (1568MB/s)   (254MB/s)   (2437MB/s)
#jobs9
WRITE:  (5120MB/s)   (264MB/s)   (4035MB/s)
WRITE:  (4531MB/s)   (267MB/s)   (3740MB/s)
READ:   (1940MB/s)   (2258MB/s)  (4986MB/s)
READ:   (2024MB/s)   (2387MB/s)  (4871MB/s)
READ:   (1343MB/s)   (246MB/s)   (2038MB/s)
WRITE:  (1342MB/s)   (246MB/s)   (2037MB/s)
READ:   (1553MB/s)   (238MB/s)   (2243MB/s)
WRITE:  (1552MB/s)   (238MB/s)   (2242MB/s)
#jobs10
WRITE:  (5345MB/s)   (271MB/s)   (3988MB/s)
WRITE:  (4750MB/s)   (254MB/s)   (3668MB/s)
READ:   (1876MB/s)   (2363MB/s)  (5150MB/s)
READ:   (1990MB/s)   (2256MB/s)  (5080MB/s)
READ:   (1355MB/s)   (250MB/s)   (2019MB/s)
WRITE:  (1356MB/s)   (251MB/s)   (2020MB/s)
READ:   (1490MB/s)   (252MB/s)   (2202MB/s)
WRITE:  (1488MB/s)   (252MB/s)   

[PATCH 1/2] zram: add zstd to the supported algorithms list

2017-09-11 Thread Sergey Senozhatsky
Add ZSTD to the list of supported compression algorithms.

ZRAM fio perf test:

  LZO DEFLATE ZSTD

#jobs1
WRITE:  (2180MB/s)   (77.2MB/s)  (1429MB/s)
WRITE:  (1617MB/s)   (77.7MB/s)  (1202MB/s)
READ:(426MB/s)   (595MB/s)   (1181MB/s)
READ:(422MB/s)   (572MB/s)   (1020MB/s)
READ:(318MB/s)   (67.8MB/s)  (563MB/s)
WRITE:   (318MB/s)   (67.9MB/s)  (564MB/s)
READ:(336MB/s)   (68.3MB/s)  (583MB/s)
WRITE:   (335MB/s)   (68.2MB/s)  (582MB/s)
#jobs2
WRITE:  (3441MB/s)   (152MB/s)   (2141MB/s)
WRITE:  (2507MB/s)   (147MB/s)   (1888MB/s)
READ:(801MB/s)   (1146MB/s)  (1890MB/s)
READ:(767MB/s)   (1096MB/s)  (2073MB/s)
READ:(621MB/s)   (126MB/s)   (1009MB/s)
WRITE:   (621MB/s)   (126MB/s)   (1009MB/s)
READ:(656MB/s)   (125MB/s)   (1075MB/s)
WRITE:   (657MB/s)   (126MB/s)   (1077MB/s)
#jobs3
WRITE:  (4772MB/s)   (225MB/s)   (3394MB/s)
WRITE:  (3905MB/s)   (211MB/s)   (2939MB/s)
READ:   (1216MB/s)   (1608MB/s)  (3218MB/s)
READ:   (1159MB/s)   (1431MB/s)  (2981MB/s)
READ:(906MB/s)   (156MB/s)   (1457MB/s)
WRITE:   (907MB/s)   (156MB/s)   (1458MB/s)
READ:(953MB/s)   (158MB/s)   (1595MB/s)
WRITE:   (952MB/s)   (157MB/s)   (1593MB/s)
#jobs4
WRITE:  (6036MB/s)   (265MB/s)   (4469MB/s)
WRITE:  (5059MB/s)   (263MB/s)   (3951MB/s)
READ:   (1618MB/s)   (2066MB/s)  (4276MB/s)
READ:   (1573MB/s)   (1942MB/s)  (3830MB/s)
READ:   (1202MB/s)   (227MB/s)   (1971MB/s)
WRITE:  (1200MB/s)   (227MB/s)   (1968MB/s)
READ:   (1265MB/s)   (226MB/s)   (2116MB/s)
WRITE:  (1264MB/s)   (226MB/s)   (2114MB/s)
#jobs5
WRITE:  (5339MB/s)   (233MB/s)   (3781MB/s)
WRITE:  (4298MB/s)   (234MB/s)   (3276MB/s)
READ:   (1626MB/s)   (2048MB/s)  (4081MB/s)
READ:   (1567MB/s)   (1929MB/s)  (3758MB/s)
READ:   (1174MB/s)   (205MB/s)   (1747MB/s)
WRITE:  (1173MB/s)   (204MB/s)   (1746MB/s)
READ:   (1214MB/s)   (208MB/s)   (1890MB/s)
WRITE:  (1215MB/s)   (208MB/s)   (1892MB/s)
#jobs6
WRITE:  (5666MB/s)   (270MB/s)   (4338MB/s)
WRITE:  (4828MB/s)   (267MB/s)   (3772MB/s)
READ:   (1803MB/s)   (2058MB/s)  (4946MB/s)
READ:   (1805MB/s)   (2156MB/s)  (4711MB/s)
READ:   (1334MB/s)   (235MB/s)   (2135MB/s)
WRITE:  (1335MB/s)   (235MB/s)   (2137MB/s)
READ:   (1364MB/s)   (236MB/s)   (2268MB/s)
WRITE:  (1365MB/s)   (237MB/s)   (2270MB/s)
#jobs7
WRITE:  (5474MB/s)   (270MB/s)   (4300MB/s)
WRITE:  (4666MB/s)   (266MB/s)   (3817MB/s)
READ:   (2022MB/s)   (2319MB/s)  (5472MB/s)
READ:   (1924MB/s)   (2260MB/s)  (5031MB/s)
READ:   (1369MB/s)   (242MB/s)   (2153MB/s)
WRITE:  (1370MB/s)   (242MB/s)   (2155MB/s)
READ:   (1499MB/s)   (246MB/s)   (2310MB/s)
WRITE:  (1497MB/s)   (246MB/s)   (2307MB/s)
#jobs8
WRITE:  (5558MB/s)   (273MB/s)   (4439MB/s)
WRITE:  (4763MB/s)   (271MB/s)   (3918MB/s)
READ:   (2201MB/s)   (2599MB/s)  (6062MB/s)
READ:   (2105MB/s)   (2463MB/s)  (5413MB/s)
READ:   (1490MB/s)   (252MB/s)   (2238MB/s)
WRITE:  (1488MB/s)   (252MB/s)   (2236MB/s)
READ:   (1566MB/s)   (254MB/s)   (2434MB/s)
WRITE:  (1568MB/s)   (254MB/s)   (2437MB/s)
#jobs9
WRITE:  (5120MB/s)   (264MB/s)   (4035MB/s)
WRITE:  (4531MB/s)   (267MB/s)   (3740MB/s)
READ:   (1940MB/s)   (2258MB/s)  (4986MB/s)
READ:   (2024MB/s)   (2387MB/s)  (4871MB/s)
READ:   (1343MB/s)   (246MB/s)   (2038MB/s)
WRITE:  (1342MB/s)   (246MB/s)   (2037MB/s)
READ:   (1553MB/s)   (238MB/s)   (2243MB/s)
WRITE:  (1552MB/s)   (238MB/s)   (2242MB/s)
#jobs10
WRITE:  (5345MB/s)   (271MB/s)   (3988MB/s)
WRITE:  (4750MB/s)   (254MB/s)   (3668MB/s)
READ:   (1876MB/s)   (2363MB/s)  (5150MB/s)
READ:   (1990MB/s)   (2256MB/s)  (5080MB/s)
READ:   (1355MB/s)   (250MB/s)   (2019MB/s)
WRITE:  (1356MB/s)   (251MB/s)   (2020MB/s)
READ:   (1490MB/s)   (252MB/s)   (2202MB/s)
WRITE:  (1488MB/s)   (252MB/s)   

Re: [PATCH v2] openvswitch: Fix an error handling path in 'ovs_nla_init_match_and_action()'

2017-09-11 Thread Pravin Shelar
On Mon, Sep 11, 2017 at 12:56 PM, Christophe JAILLET
 wrote:
> All other error handling paths in this function go through the 'error'
> label. This one should do the same.
>
> Fixes: 9cc9a5cb176c ("datapath: Avoid using stack larger than 1024.")
> Signed-off-by: Christophe JAILLET 
> ---
> I think that the comment above the function could be improved. It looks
> like the commit log which has introduced this function.
>
> I'm also not sure that commit 9cc9a5cb176c is of any help. It is
> supposed to remove a warning, and I guess it does. But 
> 'ovs_nla_init_match_and_action()'
> is called unconditionnaly from 'ovs_flow_cmd_set()'. So even if the stack
> used by each function is reduced, the overall stack should be the same, if
> not larger.
>
It depends on which function stack depth are are looking at. for some
function it remains same. For nested function it goes down.

> So this commit sounds like adding a bug where the code was fine and states
> to fix an issue but, at the best, only hides it.
>
> Instead of fixing the code with the proposed patch, reverting the initial
> commit could also be considered.
>
> V2: update Subject line
> ---
>  net/openvswitch/datapath.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/net/openvswitch/datapath.c b/net/openvswitch/datapath.c
> index 76cf273a56c7..c3aec6227c91 100644
> --- a/net/openvswitch/datapath.c
> +++ b/net/openvswitch/datapath.c
> @@ -1112,7 +1112,8 @@ static int ovs_nla_init_match_and_action(struct net 
> *net,
> if (!a[OVS_FLOW_ATTR_KEY]) {
> OVS_NLERR(log,
>   "Flow key attribute not present in set 
> flow.");
> -   return -EINVAL;
> +   error = -EINVAL;
> +   goto error;
> }
>
Patch looks good to me.

Acked-by: Pravin B Shelar 


Re: [PATCH v2] openvswitch: Fix an error handling path in 'ovs_nla_init_match_and_action()'

2017-09-11 Thread Pravin Shelar
On Mon, Sep 11, 2017 at 12:56 PM, Christophe JAILLET
 wrote:
> All other error handling paths in this function go through the 'error'
> label. This one should do the same.
>
> Fixes: 9cc9a5cb176c ("datapath: Avoid using stack larger than 1024.")
> Signed-off-by: Christophe JAILLET 
> ---
> I think that the comment above the function could be improved. It looks
> like the commit log which has introduced this function.
>
> I'm also not sure that commit 9cc9a5cb176c is of any help. It is
> supposed to remove a warning, and I guess it does. But 
> 'ovs_nla_init_match_and_action()'
> is called unconditionnaly from 'ovs_flow_cmd_set()'. So even if the stack
> used by each function is reduced, the overall stack should be the same, if
> not larger.
>
It depends on which function stack depth are are looking at. for some
function it remains same. For nested function it goes down.

> So this commit sounds like adding a bug where the code was fine and states
> to fix an issue but, at the best, only hides it.
>
> Instead of fixing the code with the proposed patch, reverting the initial
> commit could also be considered.
>
> V2: update Subject line
> ---
>  net/openvswitch/datapath.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/net/openvswitch/datapath.c b/net/openvswitch/datapath.c
> index 76cf273a56c7..c3aec6227c91 100644
> --- a/net/openvswitch/datapath.c
> +++ b/net/openvswitch/datapath.c
> @@ -1112,7 +1112,8 @@ static int ovs_nla_init_match_and_action(struct net 
> *net,
> if (!a[OVS_FLOW_ATTR_KEY]) {
> OVS_NLERR(log,
>   "Flow key attribute not present in set 
> flow.");
> -   return -EINVAL;
> +   error = -EINVAL;
> +   goto error;
> }
>
Patch looks good to me.

Acked-by: Pravin B Shelar 


Re: [PATCH 3/5] mm:swap: introduce SWP_SYNCHRONOUS_IO

2017-09-11 Thread Sergey Senozhatsky
On (09/12/17 11:37), Minchan Kim wrote:
[..]
> If rw-page based fast storage is used for swap devices, we need to
> detect it to enhance swap IO operations.
> This patch is preparation for optimizing of swap-in operation with
> next patch.
> 
> Signed-off-by: Minchan Kim 
> ---
>  include/linux/swap.h | 3 ++-
>  mm/swapfile.c| 3 +++
>  2 files changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/include/linux/swap.h b/include/linux/swap.h
> index 8a807292037f..0f54b491e118 100644
> --- a/include/linux/swap.h
> +++ b/include/linux/swap.h
> @@ -170,8 +170,9 @@ enum {
>   SWP_AREA_DISCARD = (1 << 8),/* single-time swap area discards */
>   SWP_PAGE_DISCARD = (1 << 9),/* freed swap page-cluster discards */
>   SWP_STABLE_WRITES = (1 << 10),  /* no overwrite PG_writeback pages */
> + SWP_SYNCHRONOUS_IO = (1<<11),   /* synchronous IO is efficient */
a nitpick:  (1 << 11)

-ss

>   /* add others here before... */
> - SWP_SCANNING= (1 << 11),/* refcount in scan_swap_map */
> + SWP_SCANNING= (1 << 12),/* refcount in scan_swap_map */
>  };


Re: [PATCH 3/5] mm:swap: introduce SWP_SYNCHRONOUS_IO

2017-09-11 Thread Sergey Senozhatsky
On (09/12/17 11:37), Minchan Kim wrote:
[..]
> If rw-page based fast storage is used for swap devices, we need to
> detect it to enhance swap IO operations.
> This patch is preparation for optimizing of swap-in operation with
> next patch.
> 
> Signed-off-by: Minchan Kim 
> ---
>  include/linux/swap.h | 3 ++-
>  mm/swapfile.c| 3 +++
>  2 files changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/include/linux/swap.h b/include/linux/swap.h
> index 8a807292037f..0f54b491e118 100644
> --- a/include/linux/swap.h
> +++ b/include/linux/swap.h
> @@ -170,8 +170,9 @@ enum {
>   SWP_AREA_DISCARD = (1 << 8),/* single-time swap area discards */
>   SWP_PAGE_DISCARD = (1 << 9),/* freed swap page-cluster discards */
>   SWP_STABLE_WRITES = (1 << 10),  /* no overwrite PG_writeback pages */
> + SWP_SYNCHRONOUS_IO = (1<<11),   /* synchronous IO is efficient */
a nitpick:  (1 << 11)

-ss

>   /* add others here before... */
> - SWP_SCANNING= (1 << 11),/* refcount in scan_swap_map */
> + SWP_SCANNING= (1 << 12),/* refcount in scan_swap_map */
>  };


[PATCH 2/3] ext4: test for DAX + journaling corruption

2017-09-11 Thread Ross Zwisler
Add a regression test for the following kernel commit:

  ext4: prevent data corruption with journaling + DAX

The test passes if either we successfully compare the data between the mmap
with journaling turned on and the one with journaling turned off, or if we
fail the chattr command to turn on or off journaling.  The latter is how we
prevent this issue in the kernel.

Signed-off-by: Ross Zwisler 
---
 .gitignore  |  1 +
 src/Makefile|  2 +-
 src/t_ext4_dax_journal_corruption.c | 93 +
 tests/ext4/030  | 68 +++
 tests/ext4/030.out  |  2 +
 tests/ext4/group|  1 +
 6 files changed, 166 insertions(+), 1 deletion(-)
 create mode 100644 src/t_ext4_dax_journal_corruption.c
 create mode 100755 tests/ext4/030
 create mode 100644 tests/ext4/030.out

diff --git a/.gitignore b/.gitignore
index 2accc37..4bdc5bf 100644
--- a/.gitignore
+++ b/.gitignore
@@ -154,6 +154,7 @@
 /src/t_mmap_stale_pmd
 /src/t_mmap_cow_race
 /src/t_mmap_fallocate
+/src/t_ext4_dax_journal_corruption
 
 # dmapi/ binaries
 /dmapi/src/common/cmd/read_invis
diff --git a/src/Makefile b/src/Makefile
index b8aff49..e6558e2 100644
--- a/src/Makefile
+++ b/src/Makefile
@@ -13,7 +13,7 @@ TARGETS = dirstress fill fill2 getpagesize holes lstat64 \
multi_open_unlink dmiperf unwritten_sync genhashnames t_holes \
t_mmap_writev t_truncate_cmtime dirhash_collide t_rename_overwrite \
holetest t_truncate_self t_mmap_dio af_unix t_mmap_stale_pmd \
-   t_mmap_cow_race t_mmap_fallocate fsync-err
+   t_mmap_cow_race t_mmap_fallocate fsync-err t_ext4_dax_journal_corruption
 
 LINUX_TARGETS = xfsctl bstat t_mtab getdevicesize preallo_rw_pattern_reader \
preallo_rw_pattern_writer ftrunc trunc fs_perms testx looptest \
diff --git a/src/t_ext4_dax_journal_corruption.c 
b/src/t_ext4_dax_journal_corruption.c
new file mode 100644
index 000..e0d63f8
--- /dev/null
+++ b/src/t_ext4_dax_journal_corruption.c
@@ -0,0 +1,93 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define PAGE(a) ((a)*0x1000)
+#define STRLEN 256
+
+void err_exit(char *op)
+{
+   fprintf(stderr, "%s: %s\n", op, strerror(errno));
+   exit(1);
+}
+
+void chattr_cmd(char *chattr, char *cmd, char *file)
+{
+   int ret;
+   char command[STRLEN];
+
+   ret = snprintf(command, STRLEN, "%s %s %s 2>/dev/null", chattr, cmd, 
file);
+   if (ret < 0)
+   err_exit("snprintf");
+
+   ret = system(command);
+   if (ret) /* Success - the kernel fix is to have this chattr fail */
+   exit(77);
+}
+
+int main(int argc, char *argv[])
+{
+   int fd, err, len = PAGE(1);
+   char *data, *dax_data, *chattr, *file;
+   char string[STRLEN];
+
+   if (argc < 3) {
+   printf("Usage: %s  \n", 
basename(argv[0]));
+   exit(0);
+   }
+
+   chattr = argv[1];
+   file = argv[2];
+
+   srand(time(NULL));
+   snprintf(string, STRLEN, "random number %d\n", rand());
+
+   fd = open(file, O_RDWR|O_CREAT, S_IRUSR|S_IWUSR);
+   if (fd < 0)
+   err_exit("fd");
+
+   /* begin with journaling off and DAX on */
+   chattr_cmd(chattr, "-j", file);
+
+   ftruncate(fd, 0);
+   fallocate(fd, 0, 0, len);
+
+   dax_data = mmap(NULL, len, PROT_READ, MAP_SHARED, fd, 0);
+   if (!dax_data)
+   err_exit("mmap dax_data");
+
+   /* turns on journaling, and turns off DAX */
+   chattr_cmd(chattr, "+j", file);
+
+   data = mmap(NULL, len, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
+   if (!data)
+   err_exit("mmap data");
+
+   /*
+* Write the data using the non-DAX mapping, and try and read it back
+* using the DAX mapping.
+*/
+   strcpy(data, string);
+   if (strcmp(dax_data, string) != 0)
+   printf("Data miscompare\n");
+
+   err = munmap(data, len);
+   if (err < 0)
+   err_exit("munmap data");
+
+   err = munmap(dax_data, len);
+   if (err < 0)
+   err_exit("munmap dax_data");
+
+   err = close(fd);
+   if (err < 0)
+   err_exit("close");
+   return 0;
+}
diff --git a/tests/ext4/030 b/tests/ext4/030
new file mode 100755
index 000..3ac4952
--- /dev/null
+++ b/tests/ext4/030
@@ -0,0 +1,68 @@
+#! /bin/bash
+# FS QA Test ext4/030
+#
+# This is a regression test for kernel patch:
+#   ext4: prevent data corruption with journaling + DAX
+# created by Ross Zwisler 
+#
+#---
+# Copyright (c) 2017 Intel Corporation.  All Rights Reserved.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public 

[PATCH 2/3] ext4: test for DAX + journaling corruption

2017-09-11 Thread Ross Zwisler
Add a regression test for the following kernel commit:

  ext4: prevent data corruption with journaling + DAX

The test passes if either we successfully compare the data between the mmap
with journaling turned on and the one with journaling turned off, or if we
fail the chattr command to turn on or off journaling.  The latter is how we
prevent this issue in the kernel.

Signed-off-by: Ross Zwisler 
---
 .gitignore  |  1 +
 src/Makefile|  2 +-
 src/t_ext4_dax_journal_corruption.c | 93 +
 tests/ext4/030  | 68 +++
 tests/ext4/030.out  |  2 +
 tests/ext4/group|  1 +
 6 files changed, 166 insertions(+), 1 deletion(-)
 create mode 100644 src/t_ext4_dax_journal_corruption.c
 create mode 100755 tests/ext4/030
 create mode 100644 tests/ext4/030.out

diff --git a/.gitignore b/.gitignore
index 2accc37..4bdc5bf 100644
--- a/.gitignore
+++ b/.gitignore
@@ -154,6 +154,7 @@
 /src/t_mmap_stale_pmd
 /src/t_mmap_cow_race
 /src/t_mmap_fallocate
+/src/t_ext4_dax_journal_corruption
 
 # dmapi/ binaries
 /dmapi/src/common/cmd/read_invis
diff --git a/src/Makefile b/src/Makefile
index b8aff49..e6558e2 100644
--- a/src/Makefile
+++ b/src/Makefile
@@ -13,7 +13,7 @@ TARGETS = dirstress fill fill2 getpagesize holes lstat64 \
multi_open_unlink dmiperf unwritten_sync genhashnames t_holes \
t_mmap_writev t_truncate_cmtime dirhash_collide t_rename_overwrite \
holetest t_truncate_self t_mmap_dio af_unix t_mmap_stale_pmd \
-   t_mmap_cow_race t_mmap_fallocate fsync-err
+   t_mmap_cow_race t_mmap_fallocate fsync-err t_ext4_dax_journal_corruption
 
 LINUX_TARGETS = xfsctl bstat t_mtab getdevicesize preallo_rw_pattern_reader \
preallo_rw_pattern_writer ftrunc trunc fs_perms testx looptest \
diff --git a/src/t_ext4_dax_journal_corruption.c 
b/src/t_ext4_dax_journal_corruption.c
new file mode 100644
index 000..e0d63f8
--- /dev/null
+++ b/src/t_ext4_dax_journal_corruption.c
@@ -0,0 +1,93 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define PAGE(a) ((a)*0x1000)
+#define STRLEN 256
+
+void err_exit(char *op)
+{
+   fprintf(stderr, "%s: %s\n", op, strerror(errno));
+   exit(1);
+}
+
+void chattr_cmd(char *chattr, char *cmd, char *file)
+{
+   int ret;
+   char command[STRLEN];
+
+   ret = snprintf(command, STRLEN, "%s %s %s 2>/dev/null", chattr, cmd, 
file);
+   if (ret < 0)
+   err_exit("snprintf");
+
+   ret = system(command);
+   if (ret) /* Success - the kernel fix is to have this chattr fail */
+   exit(77);
+}
+
+int main(int argc, char *argv[])
+{
+   int fd, err, len = PAGE(1);
+   char *data, *dax_data, *chattr, *file;
+   char string[STRLEN];
+
+   if (argc < 3) {
+   printf("Usage: %s  \n", 
basename(argv[0]));
+   exit(0);
+   }
+
+   chattr = argv[1];
+   file = argv[2];
+
+   srand(time(NULL));
+   snprintf(string, STRLEN, "random number %d\n", rand());
+
+   fd = open(file, O_RDWR|O_CREAT, S_IRUSR|S_IWUSR);
+   if (fd < 0)
+   err_exit("fd");
+
+   /* begin with journaling off and DAX on */
+   chattr_cmd(chattr, "-j", file);
+
+   ftruncate(fd, 0);
+   fallocate(fd, 0, 0, len);
+
+   dax_data = mmap(NULL, len, PROT_READ, MAP_SHARED, fd, 0);
+   if (!dax_data)
+   err_exit("mmap dax_data");
+
+   /* turns on journaling, and turns off DAX */
+   chattr_cmd(chattr, "+j", file);
+
+   data = mmap(NULL, len, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
+   if (!data)
+   err_exit("mmap data");
+
+   /*
+* Write the data using the non-DAX mapping, and try and read it back
+* using the DAX mapping.
+*/
+   strcpy(data, string);
+   if (strcmp(dax_data, string) != 0)
+   printf("Data miscompare\n");
+
+   err = munmap(data, len);
+   if (err < 0)
+   err_exit("munmap data");
+
+   err = munmap(dax_data, len);
+   if (err < 0)
+   err_exit("munmap dax_data");
+
+   err = close(fd);
+   if (err < 0)
+   err_exit("close");
+   return 0;
+}
diff --git a/tests/ext4/030 b/tests/ext4/030
new file mode 100755
index 000..3ac4952
--- /dev/null
+++ b/tests/ext4/030
@@ -0,0 +1,68 @@
+#! /bin/bash
+# FS QA Test ext4/030
+#
+# This is a regression test for kernel patch:
+#   ext4: prevent data corruption with journaling + DAX
+# created by Ross Zwisler 
+#
+#---
+# Copyright (c) 2017 Intel Corporation.  All Rights Reserved.
+#
+# 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.
+#
+# 

[PATCH 1/3] .gitignore: ignore cscope files

2017-09-11 Thread Ross Zwisler
Signed-off-by: Ross Zwisler 
---
 .gitignore | 4 
 1 file changed, 4 insertions(+)

diff --git a/.gitignore b/.gitignore
index 28fe84d..2accc37 100644
--- a/.gitignore
+++ b/.gitignore
@@ -238,3 +238,7 @@
 /tests/xfs/033.out
 /tests/xfs/071.out
 /tests/xfs/096.out
+
+# cscope files
+cscope.*
+ncscope.*
-- 
2.9.5



[PATCH 1/3] .gitignore: ignore cscope files

2017-09-11 Thread Ross Zwisler
Signed-off-by: Ross Zwisler 
---
 .gitignore | 4 
 1 file changed, 4 insertions(+)

diff --git a/.gitignore b/.gitignore
index 28fe84d..2accc37 100644
--- a/.gitignore
+++ b/.gitignore
@@ -238,3 +238,7 @@
 /tests/xfs/033.out
 /tests/xfs/071.out
 /tests/xfs/096.out
+
+# cscope files
+cscope.*
+ncscope.*
-- 
2.9.5



[PATCH 3/3] ext4: test for inline data + DAX corruption

2017-09-11 Thread Ross Zwisler
Add a regression test for the following kernel commit:

  ext4: prevent data corruption with inline data + DAX

The test passes either if we don't encounter corruption, or if mounting
with DAX + inline data fails.  The latter is the way that we prevent this
issue in the kernel.

Signed-off-by: Ross Zwisler 
---
 .gitignore |  1 +
 src/Makefile   |  3 +-
 src/t_ext4_dax_inline_corruption.c | 70 +++
 tests/ext4/031 | 84 ++
 tests/ext4/031.out |  2 +
 tests/ext4/group   |  1 +
 6 files changed, 160 insertions(+), 1 deletion(-)
 create mode 100644 src/t_ext4_dax_inline_corruption.c
 create mode 100755 tests/ext4/031
 create mode 100644 tests/ext4/031.out

diff --git a/.gitignore b/.gitignore
index 4bdc5bf..37670e6 100644
--- a/.gitignore
+++ b/.gitignore
@@ -155,6 +155,7 @@
 /src/t_mmap_cow_race
 /src/t_mmap_fallocate
 /src/t_ext4_dax_journal_corruption
+/src/t_ext4_dax_inline_corruption
 
 # dmapi/ binaries
 /dmapi/src/common/cmd/read_invis
diff --git a/src/Makefile b/src/Makefile
index e6558e2..bcfae01 100644
--- a/src/Makefile
+++ b/src/Makefile
@@ -13,7 +13,8 @@ TARGETS = dirstress fill fill2 getpagesize holes lstat64 \
multi_open_unlink dmiperf unwritten_sync genhashnames t_holes \
t_mmap_writev t_truncate_cmtime dirhash_collide t_rename_overwrite \
holetest t_truncate_self t_mmap_dio af_unix t_mmap_stale_pmd \
-   t_mmap_cow_race t_mmap_fallocate fsync-err t_ext4_dax_journal_corruption
+   t_mmap_cow_race t_mmap_fallocate fsync-err 
t_ext4_dax_journal_corruption \
+   t_ext4_dax_inline_corruption
 
 LINUX_TARGETS = xfsctl bstat t_mtab getdevicesize preallo_rw_pattern_reader \
preallo_rw_pattern_writer ftrunc trunc fs_perms testx looptest \
diff --git a/src/t_ext4_dax_inline_corruption.c 
b/src/t_ext4_dax_inline_corruption.c
new file mode 100644
index 000..4b7d893
--- /dev/null
+++ b/src/t_ext4_dax_inline_corruption.c
@@ -0,0 +1,70 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define PAGE(a) ((a)*0x1000)
+#define STRLEN 256
+
+void err_exit(char *op)
+{
+   fprintf(stderr, "%s: %s\n", op, strerror(errno));
+   exit(1);
+}
+
+int main(int argc, char *argv[])
+{
+   int fd, err, len = PAGE(1);
+   char *dax_data, *data;
+   char string[STRLEN];
+
+   if (argc < 2) {
+   printf("Usage: %s \n", basename(argv[0]));
+   exit(0);
+   }
+
+   srand(time(NULL));
+   snprintf(string, STRLEN, "random number %d\n", rand());
+
+   fd = open(argv[1], O_RDWR);
+   if (fd < 0)
+   err_exit("fd");
+
+   data = mmap(NULL, len, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
+   if (!data)
+   err_exit("mmap data");
+
+   /* this fallocate turns off inline data and turns on DAX */
+   fallocate(fd, 0, 0, PAGE(2));
+
+   dax_data = mmap(NULL, len, PROT_READ, MAP_SHARED, fd, 0);
+   if (!dax_data)
+   err_exit("mmap dax_data");
+
+   /*
+* Write the data using the non-DAX mapping, and try and read it back
+* using the DAX mapping.
+*/
+   strcpy(data, string);
+   if (strcmp(dax_data, string) != 0)
+   printf("Data miscompare\n");
+
+   err = munmap(dax_data, len);
+   if (err < 0)
+   err_exit("munmap dax_data");
+
+   err = munmap(data, len);
+   if (err < 0)
+   err_exit("munmap data");
+
+   err = close(fd);
+   if (err < 0)
+   err_exit("close");
+   return 0;
+}
diff --git a/tests/ext4/031 b/tests/ext4/031
new file mode 100755
index 000..95a5c65
--- /dev/null
+++ b/tests/ext4/031
@@ -0,0 +1,84 @@
+#! /bin/bash
+# FS QA Test ext4/031
+#
+# This is a regression test for kernel patch:
+#   ext4: prevent data corruption with inline data + DAX
+# created by Ross Zwisler 
+#
+#---
+# Copyright (c) 2017 Intel Corporation.  All Rights Reserved.
+#
+# 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.
+#
+# This program is distributed in the hope that it would 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, write the Free Software Foundation,
+# Inc.,  51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+#---
+#
+
+seq=`basename $0`
+seqres=$RESULT_DIR/$seq

[PATCH 3/3] ext4: test for inline data + DAX corruption

2017-09-11 Thread Ross Zwisler
Add a regression test for the following kernel commit:

  ext4: prevent data corruption with inline data + DAX

The test passes either if we don't encounter corruption, or if mounting
with DAX + inline data fails.  The latter is the way that we prevent this
issue in the kernel.

Signed-off-by: Ross Zwisler 
---
 .gitignore |  1 +
 src/Makefile   |  3 +-
 src/t_ext4_dax_inline_corruption.c | 70 +++
 tests/ext4/031 | 84 ++
 tests/ext4/031.out |  2 +
 tests/ext4/group   |  1 +
 6 files changed, 160 insertions(+), 1 deletion(-)
 create mode 100644 src/t_ext4_dax_inline_corruption.c
 create mode 100755 tests/ext4/031
 create mode 100644 tests/ext4/031.out

diff --git a/.gitignore b/.gitignore
index 4bdc5bf..37670e6 100644
--- a/.gitignore
+++ b/.gitignore
@@ -155,6 +155,7 @@
 /src/t_mmap_cow_race
 /src/t_mmap_fallocate
 /src/t_ext4_dax_journal_corruption
+/src/t_ext4_dax_inline_corruption
 
 # dmapi/ binaries
 /dmapi/src/common/cmd/read_invis
diff --git a/src/Makefile b/src/Makefile
index e6558e2..bcfae01 100644
--- a/src/Makefile
+++ b/src/Makefile
@@ -13,7 +13,8 @@ TARGETS = dirstress fill fill2 getpagesize holes lstat64 \
multi_open_unlink dmiperf unwritten_sync genhashnames t_holes \
t_mmap_writev t_truncate_cmtime dirhash_collide t_rename_overwrite \
holetest t_truncate_self t_mmap_dio af_unix t_mmap_stale_pmd \
-   t_mmap_cow_race t_mmap_fallocate fsync-err t_ext4_dax_journal_corruption
+   t_mmap_cow_race t_mmap_fallocate fsync-err 
t_ext4_dax_journal_corruption \
+   t_ext4_dax_inline_corruption
 
 LINUX_TARGETS = xfsctl bstat t_mtab getdevicesize preallo_rw_pattern_reader \
preallo_rw_pattern_writer ftrunc trunc fs_perms testx looptest \
diff --git a/src/t_ext4_dax_inline_corruption.c 
b/src/t_ext4_dax_inline_corruption.c
new file mode 100644
index 000..4b7d893
--- /dev/null
+++ b/src/t_ext4_dax_inline_corruption.c
@@ -0,0 +1,70 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define PAGE(a) ((a)*0x1000)
+#define STRLEN 256
+
+void err_exit(char *op)
+{
+   fprintf(stderr, "%s: %s\n", op, strerror(errno));
+   exit(1);
+}
+
+int main(int argc, char *argv[])
+{
+   int fd, err, len = PAGE(1);
+   char *dax_data, *data;
+   char string[STRLEN];
+
+   if (argc < 2) {
+   printf("Usage: %s \n", basename(argv[0]));
+   exit(0);
+   }
+
+   srand(time(NULL));
+   snprintf(string, STRLEN, "random number %d\n", rand());
+
+   fd = open(argv[1], O_RDWR);
+   if (fd < 0)
+   err_exit("fd");
+
+   data = mmap(NULL, len, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
+   if (!data)
+   err_exit("mmap data");
+
+   /* this fallocate turns off inline data and turns on DAX */
+   fallocate(fd, 0, 0, PAGE(2));
+
+   dax_data = mmap(NULL, len, PROT_READ, MAP_SHARED, fd, 0);
+   if (!dax_data)
+   err_exit("mmap dax_data");
+
+   /*
+* Write the data using the non-DAX mapping, and try and read it back
+* using the DAX mapping.
+*/
+   strcpy(data, string);
+   if (strcmp(dax_data, string) != 0)
+   printf("Data miscompare\n");
+
+   err = munmap(dax_data, len);
+   if (err < 0)
+   err_exit("munmap dax_data");
+
+   err = munmap(data, len);
+   if (err < 0)
+   err_exit("munmap data");
+
+   err = close(fd);
+   if (err < 0)
+   err_exit("close");
+   return 0;
+}
diff --git a/tests/ext4/031 b/tests/ext4/031
new file mode 100755
index 000..95a5c65
--- /dev/null
+++ b/tests/ext4/031
@@ -0,0 +1,84 @@
+#! /bin/bash
+# FS QA Test ext4/031
+#
+# This is a regression test for kernel patch:
+#   ext4: prevent data corruption with inline data + DAX
+# created by Ross Zwisler 
+#
+#---
+# Copyright (c) 2017 Intel Corporation.  All Rights Reserved.
+#
+# 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.
+#
+# This program is distributed in the hope that it would 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, write the Free Software Foundation,
+# Inc.,  51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+#---
+#
+
+seq=`basename $0`
+seqres=$RESULT_DIR/$seq
+echo "QA output created by $seq"
+
+here=`pwd`
+tmp=/tmp/$$

Re: [PATCH 6/9] arm64: kexec_file: load initrd, device-tree and purgatory segments

2017-09-11 Thread AKASHI Takahiro
On Mon, Sep 11, 2017 at 02:47:54PM +0800, Dave Young wrote:
> Hi,
> 
> On 09/08/17 at 12:16pm, AKASHI Takahiro wrote:
> > load_other_segments() sets up and adds all the memory segments necessary
> > other than kernel, including initrd, device-tree blob and purgatory.
> > Most of the code was borrowed from kexec-tools' counterpart.
> > 
> > In addition, arch_kexec_image_probe(), arch_kexec_image_load() and
> > arch_kexec_kernel_verify_sig() are added as stubs for supporting multiple
> > types of kernel image formats.
> > 
> > Signed-off-by: AKASHI Takahiro 
> > Cc: Catalin Marinas 
> > Cc: Will Deacon 
> > ---
> >  arch/arm64/include/asm/kexec.h |  19 +++
> >  arch/arm64/kernel/machine_kexec_file.c | 264 
> > +
> >  2 files changed, 283 insertions(+)
> >  create mode 100644 arch/arm64/kernel/machine_kexec_file.c
> > 
> > diff --git a/arch/arm64/include/asm/kexec.h b/arch/arm64/include/asm/kexec.h
> > index e17f0529a882..d74dc49670ad 100644
> > --- a/arch/arm64/include/asm/kexec.h
> > +++ b/arch/arm64/include/asm/kexec.h
> > @@ -93,6 +93,25 @@ static inline void crash_prepare_suspend(void) {}
> >  static inline void crash_post_resume(void) {}
> >  #endif
> >  
> > +#ifdef CONFIG_KEXEC_FILE
> > +#define ARCH_HAS_KIMAGE_ARCH
> > +
> > +struct kimage_arch {
> > +   void *dtb_buf;
> > +};
> > +
> > +struct kimage;
> > +
> > +extern int setup_dtb(struct kimage *image,
> > +   unsigned long initrd_load_addr, unsigned long initrd_len,
> > +   char *cmdline, unsigned long cmdline_len,
> > +   char **dtb_buf, size_t *dtb_buf_len);
> > +extern int load_other_segments(struct kimage *image,
> > +   unsigned long kernel_load_addr,
> > +   char *initrd, unsigned long initrd_len,
> > +   char *cmdline, unsigned long cmdline_len);
> > +#endif
> > +
> >  #endif /* __ASSEMBLY__ */
> >  
> >  #endif
> > diff --git a/arch/arm64/kernel/machine_kexec_file.c 
> > b/arch/arm64/kernel/machine_kexec_file.c
> > new file mode 100644
> > index ..a6d2c006b4f7
> > --- /dev/null
> > +++ b/arch/arm64/kernel/machine_kexec_file.c
> > @@ -0,0 +1,264 @@
> > +/*
> > + * kexec_file for arm64
> > + *
> > + * Copyright (C) 2017 Linaro Limited
> > + * Author: AKASHI Takahiro 
> > + *
> > + * Most code is derived from arm64 port of kexec-tools
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + */
> > +
> > +#define pr_fmt(fmt) "kexec_file: " fmt
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +static int __dt_root_addr_cells;
> > +static int __dt_root_size_cells;
> > +
> > +static struct kexec_file_ops *kexec_file_loaders[0];
> > +
> > +int arch_kexec_kernel_image_probe(struct kimage *image, void *buf,
> > + unsigned long buf_len)
> > +{
> > +   struct kexec_file_ops *fops;
> > +   int i, ret;
> > +
> > +   for (i = 0; i < ARRAY_SIZE(kexec_file_loaders); i++) {
> > +   fops = kexec_file_loaders[i];
> > +   if (!fops || !fops->probe)
> > +   continue;
> > +
> > +   ret = fops->probe(buf, buf_len);
> > +   if (!ret) {
> > +   image->fops = fops;
> > +   return 0;
> > +   }
> > +   }
> > +
> > +   return -ENOEXEC;
> > +}
> > +
> > +void *arch_kexec_kernel_image_load(struct kimage *image)
> > +{
> > +   if (!image->fops || !image->fops->load)
> > +   return ERR_PTR(-ENOEXEC);
> > +
> > +   return image->fops->load(image, image->kernel_buf,
> > +image->kernel_buf_len, image->initrd_buf,
> > +image->initrd_buf_len, image->cmdline_buf,
> > +image->cmdline_buf_len);
> > +}
> > +
> > +int arch_kimage_file_post_load_cleanup(struct kimage *image)
> > +{
> > +   vfree(image->arch.dtb_buf);
> > +   image->arch.dtb_buf = NULL;
> > +
> > +   vfree(image->arch.elf_headers);
> > +   image->arch.elf_headers = NULL;
> > +   image->arch.elf_headers_sz = 0;
> > +
> > +   if (!image->fops || !image->fops->cleanup)
> > +   return 0;
> > +
> > +   return image->fops->cleanup(image->image_loader_data);
> > +}
> > +
> > +#ifdef CONFIG_KEXEC_VERIFY_SIG
> > +int arch_kexec_kernel_verify_sig(struct kimage *image, void *kernel,
> > +unsigned long kernel_len)
> > +{
> > +   if (!image->fops || !image->fops->verify_sig) {
> > +   pr_debug("kernel loader does not support signature 
> > verification.\n");
> > +   return -EKEYREJECTED;
> > +   }
> > +
> > +   return image->fops->verify_sig(kernel, kernel_len);
> > +}
> 
> 
> arch_kexec_kernel_verify_sig now be duplicated so it can be put in the
> 

Re: [PATCH 6/9] arm64: kexec_file: load initrd, device-tree and purgatory segments

2017-09-11 Thread AKASHI Takahiro
On Mon, Sep 11, 2017 at 02:47:54PM +0800, Dave Young wrote:
> Hi,
> 
> On 09/08/17 at 12:16pm, AKASHI Takahiro wrote:
> > load_other_segments() sets up and adds all the memory segments necessary
> > other than kernel, including initrd, device-tree blob and purgatory.
> > Most of the code was borrowed from kexec-tools' counterpart.
> > 
> > In addition, arch_kexec_image_probe(), arch_kexec_image_load() and
> > arch_kexec_kernel_verify_sig() are added as stubs for supporting multiple
> > types of kernel image formats.
> > 
> > Signed-off-by: AKASHI Takahiro 
> > Cc: Catalin Marinas 
> > Cc: Will Deacon 
> > ---
> >  arch/arm64/include/asm/kexec.h |  19 +++
> >  arch/arm64/kernel/machine_kexec_file.c | 264 
> > +
> >  2 files changed, 283 insertions(+)
> >  create mode 100644 arch/arm64/kernel/machine_kexec_file.c
> > 
> > diff --git a/arch/arm64/include/asm/kexec.h b/arch/arm64/include/asm/kexec.h
> > index e17f0529a882..d74dc49670ad 100644
> > --- a/arch/arm64/include/asm/kexec.h
> > +++ b/arch/arm64/include/asm/kexec.h
> > @@ -93,6 +93,25 @@ static inline void crash_prepare_suspend(void) {}
> >  static inline void crash_post_resume(void) {}
> >  #endif
> >  
> > +#ifdef CONFIG_KEXEC_FILE
> > +#define ARCH_HAS_KIMAGE_ARCH
> > +
> > +struct kimage_arch {
> > +   void *dtb_buf;
> > +};
> > +
> > +struct kimage;
> > +
> > +extern int setup_dtb(struct kimage *image,
> > +   unsigned long initrd_load_addr, unsigned long initrd_len,
> > +   char *cmdline, unsigned long cmdline_len,
> > +   char **dtb_buf, size_t *dtb_buf_len);
> > +extern int load_other_segments(struct kimage *image,
> > +   unsigned long kernel_load_addr,
> > +   char *initrd, unsigned long initrd_len,
> > +   char *cmdline, unsigned long cmdline_len);
> > +#endif
> > +
> >  #endif /* __ASSEMBLY__ */
> >  
> >  #endif
> > diff --git a/arch/arm64/kernel/machine_kexec_file.c 
> > b/arch/arm64/kernel/machine_kexec_file.c
> > new file mode 100644
> > index ..a6d2c006b4f7
> > --- /dev/null
> > +++ b/arch/arm64/kernel/machine_kexec_file.c
> > @@ -0,0 +1,264 @@
> > +/*
> > + * kexec_file for arm64
> > + *
> > + * Copyright (C) 2017 Linaro Limited
> > + * Author: AKASHI Takahiro 
> > + *
> > + * Most code is derived from arm64 port of kexec-tools
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + */
> > +
> > +#define pr_fmt(fmt) "kexec_file: " fmt
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +static int __dt_root_addr_cells;
> > +static int __dt_root_size_cells;
> > +
> > +static struct kexec_file_ops *kexec_file_loaders[0];
> > +
> > +int arch_kexec_kernel_image_probe(struct kimage *image, void *buf,
> > + unsigned long buf_len)
> > +{
> > +   struct kexec_file_ops *fops;
> > +   int i, ret;
> > +
> > +   for (i = 0; i < ARRAY_SIZE(kexec_file_loaders); i++) {
> > +   fops = kexec_file_loaders[i];
> > +   if (!fops || !fops->probe)
> > +   continue;
> > +
> > +   ret = fops->probe(buf, buf_len);
> > +   if (!ret) {
> > +   image->fops = fops;
> > +   return 0;
> > +   }
> > +   }
> > +
> > +   return -ENOEXEC;
> > +}
> > +
> > +void *arch_kexec_kernel_image_load(struct kimage *image)
> > +{
> > +   if (!image->fops || !image->fops->load)
> > +   return ERR_PTR(-ENOEXEC);
> > +
> > +   return image->fops->load(image, image->kernel_buf,
> > +image->kernel_buf_len, image->initrd_buf,
> > +image->initrd_buf_len, image->cmdline_buf,
> > +image->cmdline_buf_len);
> > +}
> > +
> > +int arch_kimage_file_post_load_cleanup(struct kimage *image)
> > +{
> > +   vfree(image->arch.dtb_buf);
> > +   image->arch.dtb_buf = NULL;
> > +
> > +   vfree(image->arch.elf_headers);
> > +   image->arch.elf_headers = NULL;
> > +   image->arch.elf_headers_sz = 0;
> > +
> > +   if (!image->fops || !image->fops->cleanup)
> > +   return 0;
> > +
> > +   return image->fops->cleanup(image->image_loader_data);
> > +}
> > +
> > +#ifdef CONFIG_KEXEC_VERIFY_SIG
> > +int arch_kexec_kernel_verify_sig(struct kimage *image, void *kernel,
> > +unsigned long kernel_len)
> > +{
> > +   if (!image->fops || !image->fops->verify_sig) {
> > +   pr_debug("kernel loader does not support signature 
> > verification.\n");
> > +   return -EKEYREJECTED;
> > +   }
> > +
> > +   return image->fops->verify_sig(kernel, kernel_len);
> > +}
> 
> 
> arch_kexec_kernel_verify_sig now be duplicated so it can be put in the
> general function in kexec_file.c
> 
> Also the probe and load function are also duplicated, they can 

Re: [PATCH 8/9] arm64: enable KEXEC_FILE config

2017-09-11 Thread AKASHI Takahiro
On Sun, Sep 10, 2017 at 11:41:47PM +0800, kbuild test robot wrote:
> Hi AKASHI,
> 
> [auto build test ERROR on arm64/for-next/core]
> [also build test ERROR on v4.13 next-20170908]
> [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/AKASHI-Takahiro/kexec-add-kexec_file_load-support/20170910-143930
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git 
> for-next/core
> config: arm64-allmodconfig (attached as .config)
> compiler: aarch64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
> 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 
> 
> Note: the 
> linux-review/AKASHI-Takahiro/kexec-add-kexec_file_load-support/20170910-143930
>  HEAD caf976acefa5a78ad88489581c66b98cbc8f91fa builds fine.
>   It only hurts bisectibility.
> 
> All errors (new ones prefixed by >>):
> 
> >> arch/arm64/kernel/machine_kexec_file.c:22:28: fatal error: 
> >> asm/kexec_file.h: No such file or directory
> #include 
>^

Will fix it in the next version, v3.

-Takahiro AKASHI

>compilation terminated.
> 
> vim +22 arch/arm64/kernel/machine_kexec_file.c
> 
> 423cf6dc9f AKASHI Takahiro 2017-09-08  15  
> 423cf6dc9f AKASHI Takahiro 2017-09-08  16  #include 
> 423cf6dc9f AKASHI Takahiro 2017-09-08  17  #include 
> 423cf6dc9f AKASHI Takahiro 2017-09-08  18  #include 
> 423cf6dc9f AKASHI Takahiro 2017-09-08  19  #include 
> 423cf6dc9f AKASHI Takahiro 2017-09-08  20  #include 
> 423cf6dc9f AKASHI Takahiro 2017-09-08  21  #include 
> 423cf6dc9f AKASHI Takahiro 2017-09-08 @22  #include 
> 423cf6dc9f AKASHI Takahiro 2017-09-08  23  
> 
> :: The code at line 22 was first introduced by commit
> :: 423cf6dc9f06d95907902b2b7f84161bdc98f752 arm64: kexec_file: load 
> initrd, device-tree and purgatory segments
> 
> :: TO: AKASHI Takahiro 
> :: CC: 0day robot 
> 
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all   Intel Corporation




Re: [PATCH 8/9] arm64: enable KEXEC_FILE config

2017-09-11 Thread AKASHI Takahiro
On Sun, Sep 10, 2017 at 11:41:47PM +0800, kbuild test robot wrote:
> Hi AKASHI,
> 
> [auto build test ERROR on arm64/for-next/core]
> [also build test ERROR on v4.13 next-20170908]
> [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/AKASHI-Takahiro/kexec-add-kexec_file_load-support/20170910-143930
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git 
> for-next/core
> config: arm64-allmodconfig (attached as .config)
> compiler: aarch64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
> 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 
> 
> Note: the 
> linux-review/AKASHI-Takahiro/kexec-add-kexec_file_load-support/20170910-143930
>  HEAD caf976acefa5a78ad88489581c66b98cbc8f91fa builds fine.
>   It only hurts bisectibility.
> 
> All errors (new ones prefixed by >>):
> 
> >> arch/arm64/kernel/machine_kexec_file.c:22:28: fatal error: 
> >> asm/kexec_file.h: No such file or directory
> #include 
>^

Will fix it in the next version, v3.

-Takahiro AKASHI

>compilation terminated.
> 
> vim +22 arch/arm64/kernel/machine_kexec_file.c
> 
> 423cf6dc9f AKASHI Takahiro 2017-09-08  15  
> 423cf6dc9f AKASHI Takahiro 2017-09-08  16  #include 
> 423cf6dc9f AKASHI Takahiro 2017-09-08  17  #include 
> 423cf6dc9f AKASHI Takahiro 2017-09-08  18  #include 
> 423cf6dc9f AKASHI Takahiro 2017-09-08  19  #include 
> 423cf6dc9f AKASHI Takahiro 2017-09-08  20  #include 
> 423cf6dc9f AKASHI Takahiro 2017-09-08  21  #include 
> 423cf6dc9f AKASHI Takahiro 2017-09-08 @22  #include 
> 423cf6dc9f AKASHI Takahiro 2017-09-08  23  
> 
> :: The code at line 22 was first introduced by commit
> :: 423cf6dc9f06d95907902b2b7f84161bdc98f752 arm64: kexec_file: load 
> initrd, device-tree and purgatory segments
> 
> :: TO: AKASHI Takahiro 
> :: CC: 0day robot 
> 
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all   Intel Corporation




Re: [PATCH] Fix: xtensa: add missing sync_core

2017-09-11 Thread Max Filippov
Hi Mathieu,

On Tue, Aug 29, 2017 at 11:55 AM, Mathieu Desnoyers
 wrote:
> - On Aug 28, 2017, at 1:12 PM, Max Filippov jcmvb...@gmail.com wrote:
>> On Mon, Aug 28, 2017 at 12:36 AM, Mathieu Desnoyers
>>  wrote:
>>> The membarrier system call now requires all architectures to implement
>>> sync_core(). On Xtensa, it is provided by the EXTW instruction.
>>>
>>> [ Completely untested! Can someone on the xtensa side confirm whether
>>>   EXTW is the right way to serialize core execution and try it out ? ]
>>
>> Thanks for the patch. I'm currently travelling, I'll give it a try next week
>> once I'm back at work.
>
> I think we may need to flush the icache to make it consistent with the dcache
> too on xtensa, in addition to the EXTW. The goal here is to allow JIT engines
> to reclaim and re-use memory after they discard dynamically generated code.
> This is similar to what we'd need to do on arm32, where they have inconsistent
> d/i-caches.

my understanding is that to support JIT engines on xtensa we need to do
icache/dcache synchronization, this procedure is covered in the ISYNC
instruction description in the ISA book, it involves MEMW and ISYNC,
but not EXTW. EXTW is meant to work as a CPU barrier that orders all
externally visible CPU signals, which seems unnecessary.

Interestingly, currently we don't have MEMW between dcache flush and
icache invalidation, so I need to add it to be consistent with the documented
procedure. Then I believe that sync_core implementation should invoke
flush_dcache_all followed by MEMW followed by invalidate_icache_all.
Does that sound right?

-- 
Thanks.
-- Max


Re: [PATCH] Fix: xtensa: add missing sync_core

2017-09-11 Thread Max Filippov
Hi Mathieu,

On Tue, Aug 29, 2017 at 11:55 AM, Mathieu Desnoyers
 wrote:
> - On Aug 28, 2017, at 1:12 PM, Max Filippov jcmvb...@gmail.com wrote:
>> On Mon, Aug 28, 2017 at 12:36 AM, Mathieu Desnoyers
>>  wrote:
>>> The membarrier system call now requires all architectures to implement
>>> sync_core(). On Xtensa, it is provided by the EXTW instruction.
>>>
>>> [ Completely untested! Can someone on the xtensa side confirm whether
>>>   EXTW is the right way to serialize core execution and try it out ? ]
>>
>> Thanks for the patch. I'm currently travelling, I'll give it a try next week
>> once I'm back at work.
>
> I think we may need to flush the icache to make it consistent with the dcache
> too on xtensa, in addition to the EXTW. The goal here is to allow JIT engines
> to reclaim and re-use memory after they discard dynamically generated code.
> This is similar to what we'd need to do on arm32, where they have inconsistent
> d/i-caches.

my understanding is that to support JIT engines on xtensa we need to do
icache/dcache synchronization, this procedure is covered in the ISYNC
instruction description in the ISA book, it involves MEMW and ISYNC,
but not EXTW. EXTW is meant to work as a CPU barrier that orders all
externally visible CPU signals, which seems unnecessary.

Interestingly, currently we don't have MEMW between dcache flush and
icache invalidation, so I need to add it to be consistent with the documented
procedure. Then I believe that sync_core implementation should invoke
flush_dcache_all followed by MEMW followed by invalidate_icache_all.
Does that sound right?

-- 
Thanks.
-- Max


Re: [f2fs-dev] [PATCH] f2fs: fix double count on issued discard commands

2017-09-11 Thread Daeho Jeong
> Yeah, that's exactly like what I made a mistake before.
> I should have mentioned that earlier. :)

Or I think the previous code which used "iter++" might be right.
You might just want to check the fixed number of small discards, 
DISCARD_ISSUE_RATE,
when issue_cond is "true".

Anyways, I have another question about this function.
How about just issuing, not checking whether it is idle, the fixed number of 
small
discards, DISCARD_ISSUE_RATE, when issue_cond is "true".
Actually, the discard commands will be issued as "asynchronous" requests,
which has a low priority in the I/O scheduler,
so the performance degradation of other threads by doing this will not be much 
severe,
but we can make the performance of the storage device better even if there is 
no idle.

I am just worried about the storage device I/O performance gets worse 
under I/O intensive senario where there is no idle

Thanks,


Re: [f2fs-dev] [PATCH] f2fs: fix double count on issued discard commands

2017-09-11 Thread Daeho Jeong
> Yeah, that's exactly like what I made a mistake before.
> I should have mentioned that earlier. :)

Or I think the previous code which used "iter++" might be right.
You might just want to check the fixed number of small discards, 
DISCARD_ISSUE_RATE,
when issue_cond is "true".

Anyways, I have another question about this function.
How about just issuing, not checking whether it is idle, the fixed number of 
small
discards, DISCARD_ISSUE_RATE, when issue_cond is "true".
Actually, the discard commands will be issued as "asynchronous" requests,
which has a low priority in the I/O scheduler,
so the performance degradation of other threads by doing this will not be much 
severe,
but we can make the performance of the storage device better even if there is 
no idle.

I am just worried about the storage device I/O performance gets worse 
under I/O intensive senario where there is no idle

Thanks,


Re: [f2fs-dev] [PATCH] f2fs: fix double count on issued discard commands

2017-09-11 Thread Jaegeuk Kim
On 09/12, Chao Yu wrote:
> On 2017/9/12 9:53, Chao Yu wrote:
> > On 2017/9/11 11:38, Jaegeuk Kim wrote:
> >> If issue_cond is true, it does double count for # of issued commands.
> >>
> >> Signed-off-by: Jaegeuk Kim 
> > 
> > Reviewed-by: Chao Yu 
> 
> As Daeho Jeong mentioned, the change makes 'iter > DISCARD_ISSUE_RATE' dead
> code, I just misread iter and issued variable, sorry. :(

Yeah, that's exactly like what I made a mistake before.
I should have mentioned that earlier. :)

> 
> Thanks,
> 
> > 
> >> ---
> >>  fs/f2fs/segment.c | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
> >> index 7fd742f747ce..25196ff5d587 100644
> >> --- a/fs/f2fs/segment.c
> >> +++ b/fs/f2fs/segment.c
> >> @@ -1087,7 +1087,7 @@ static int __issue_discard_cmd(struct f2fs_sb_info 
> >> *sbi, bool issue_cond)
> >>issued++;
> >>__submit_discard_cmd(sbi, dc);
> >>}
> >> -  if (issue_cond && iter++ > DISCARD_ISSUE_RATE)
> >> +  if (issue_cond && iter > DISCARD_ISSUE_RATE)
> >>goto out;
> >>}
> >>if (list_empty(pend_list) && dcc->pend_list_tag[i] & P_TRIM)
> >>
> > 
> > 
> > 


Re: [f2fs-dev] [PATCH] f2fs: fix double count on issued discard commands

2017-09-11 Thread Jaegeuk Kim
On 09/12, Chao Yu wrote:
> On 2017/9/12 9:53, Chao Yu wrote:
> > On 2017/9/11 11:38, Jaegeuk Kim wrote:
> >> If issue_cond is true, it does double count for # of issued commands.
> >>
> >> Signed-off-by: Jaegeuk Kim 
> > 
> > Reviewed-by: Chao Yu 
> 
> As Daeho Jeong mentioned, the change makes 'iter > DISCARD_ISSUE_RATE' dead
> code, I just misread iter and issued variable, sorry. :(

Yeah, that's exactly like what I made a mistake before.
I should have mentioned that earlier. :)

> 
> Thanks,
> 
> > 
> >> ---
> >>  fs/f2fs/segment.c | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
> >> index 7fd742f747ce..25196ff5d587 100644
> >> --- a/fs/f2fs/segment.c
> >> +++ b/fs/f2fs/segment.c
> >> @@ -1087,7 +1087,7 @@ static int __issue_discard_cmd(struct f2fs_sb_info 
> >> *sbi, bool issue_cond)
> >>issued++;
> >>__submit_discard_cmd(sbi, dc);
> >>}
> >> -  if (issue_cond && iter++ > DISCARD_ISSUE_RATE)
> >> +  if (issue_cond && iter > DISCARD_ISSUE_RATE)
> >>goto out;
> >>}
> >>if (list_empty(pend_list) && dcc->pend_list_tag[i] & P_TRIM)
> >>
> > 
> > 
> > 


linux-next: Tree for Sep 12

2017-09-11 Thread Stephen Rothwell
Hi all,

Please do not add any v4.15 related material to your linux-next
included branches until after v4.14-rc1 has been released.

Changes since 20170911:

Non-merge commits (relative to Linus' tree): 1124
 1423 files changed, 55946 insertions(+), 14234 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And
finally, a simple boot test of the powerpc pseries_le_defconfig kernel
in qemu.

Below is a summary of the state of the merge.

I am currently merging 267 trees (counting Linus' and 41 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (f007cad159e9 Revert "firmware: add sanity check on 
shutdown/suspend")
Merging fixes/master (b4b8cbf679c4 Cavium CNN55XX: fix broken default Kconfig 
entry)
Merging kbuild-current/fixes (64236e315955 kbuild: update comments of 
Makefile.asm-generic)
Merging arc-current/for-curr (1ee55a8f7f6b ARC: Re-enable MMU upon Machine 
Check exception)
Merging arm-current/fixes (746a272e4414 ARM: 8692/1: mm: abort uaccess retries 
upon fatal signal)
Merging m68k-current/for-linus (558d5ad276c9 m68k/mac: Avoid soft-lockup 
warning after mach_power_off)
Merging metag-fixes/fixes (b884a190afce metag/usercopy: Add missing fixups)
Merging powerpc-fixes/fixes (1a92a80ad386 powerpc/mm: Ensure cpumask update is 
ordered)
Merging sparc/master (6470812e2226 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc)
Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and 
linking special files)
Merging net/master (4400081b631a mlxsw: spectrum: Fix EEPROM access in case of 
SFP/SFP+)
Merging ipsec/master (1f4f554a72be net: qualcomm: rmnet: Fix a double free)
Merging netfilter/master (90c4ae4e2c1d netfilter: xt_hashlimit: fix build error 
caused by 64bit division)
Merging ipvs/master (f7fb77fc1235 netfilter: nft_compat: check extension hook 
mask only if set)
Merging wireless-drivers/master (f957dd3c8db2 brcmfmac: feature check for 
multi-scheduled scan fails on bcm4345 devices)
Merging mac80211/master (126f760ca94d rds: Fix incorrect statistics counting)
Merging sound-current/for-linus (2a0d85d9add7 ALSA: asihpi: Kill BUG_ON() 
usages)
Merging pci-current/for-linus (8e1101d25164 PCI/MSI: Don't warn when 
irq_create_affinity_masks() returns NULL)
Merging driver-core.current/driver-core-linus (d34fc1adf01f Merge branch 'akpm' 
(patches from Andrew))
Merging tty.current/tty-linus (d34fc1adf01f Merge branch 'akpm' (patches from 
Andrew))
Merging usb.current/usb-linus (d34fc1adf01f Merge branch 'akpm' (patches from 
Andrew))
Merging usb-gadget-fixes/fixes (b7d44c36a6f6 usb: renesas_usbhs: gadget: fix 
unused-but-set-variable warning)
Merging usb-serial-fixes/usb-linus (fd1b8668af59 USB: serial: option: add 
D-Link DWM-222 device ID)
Merging usb-chipidea-fixes/ci-for-usb-stable (cbb22ebcfb99 usb: chipidea: core: 
check before accessing ci_role in ci_role_show)
Merging phy/fixes (5771a8c08880 Linux v4.13-rc1)
Merging staging.current/staging-linus (f007cad159e9 Revert "firmware: add 
sanity check on shutdown/suspend")
Merging char-misc.current/char-misc-linus (d34fc1adf01f Merge branch 'akpm' 
(patches from Andrew))
Merging input-current/for-linus (a6cbfa1e6d38 Merge branch 'next' into 
for-linus)
Merging crypto-current/master (2d45a7e89833 crypto: af_alg - get_page upon 
reassignment to TX SGL)
Merging ide/master (b671e1703394 PNP: ide: constify pnp_device_id)
Merging vfio-fixes/for-linus (7

linux-next: Tree for Sep 12

2017-09-11 Thread Stephen Rothwell
Hi all,

Please do not add any v4.15 related material to your linux-next
included branches until after v4.14-rc1 has been released.

Changes since 20170911:

Non-merge commits (relative to Linus' tree): 1124
 1423 files changed, 55946 insertions(+), 14234 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And
finally, a simple boot test of the powerpc pseries_le_defconfig kernel
in qemu.

Below is a summary of the state of the merge.

I am currently merging 267 trees (counting Linus' and 41 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (f007cad159e9 Revert "firmware: add sanity check on 
shutdown/suspend")
Merging fixes/master (b4b8cbf679c4 Cavium CNN55XX: fix broken default Kconfig 
entry)
Merging kbuild-current/fixes (64236e315955 kbuild: update comments of 
Makefile.asm-generic)
Merging arc-current/for-curr (1ee55a8f7f6b ARC: Re-enable MMU upon Machine 
Check exception)
Merging arm-current/fixes (746a272e4414 ARM: 8692/1: mm: abort uaccess retries 
upon fatal signal)
Merging m68k-current/for-linus (558d5ad276c9 m68k/mac: Avoid soft-lockup 
warning after mach_power_off)
Merging metag-fixes/fixes (b884a190afce metag/usercopy: Add missing fixups)
Merging powerpc-fixes/fixes (1a92a80ad386 powerpc/mm: Ensure cpumask update is 
ordered)
Merging sparc/master (6470812e2226 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc)
Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and 
linking special files)
Merging net/master (4400081b631a mlxsw: spectrum: Fix EEPROM access in case of 
SFP/SFP+)
Merging ipsec/master (1f4f554a72be net: qualcomm: rmnet: Fix a double free)
Merging netfilter/master (90c4ae4e2c1d netfilter: xt_hashlimit: fix build error 
caused by 64bit division)
Merging ipvs/master (f7fb77fc1235 netfilter: nft_compat: check extension hook 
mask only if set)
Merging wireless-drivers/master (f957dd3c8db2 brcmfmac: feature check for 
multi-scheduled scan fails on bcm4345 devices)
Merging mac80211/master (126f760ca94d rds: Fix incorrect statistics counting)
Merging sound-current/for-linus (2a0d85d9add7 ALSA: asihpi: Kill BUG_ON() 
usages)
Merging pci-current/for-linus (8e1101d25164 PCI/MSI: Don't warn when 
irq_create_affinity_masks() returns NULL)
Merging driver-core.current/driver-core-linus (d34fc1adf01f Merge branch 'akpm' 
(patches from Andrew))
Merging tty.current/tty-linus (d34fc1adf01f Merge branch 'akpm' (patches from 
Andrew))
Merging usb.current/usb-linus (d34fc1adf01f Merge branch 'akpm' (patches from 
Andrew))
Merging usb-gadget-fixes/fixes (b7d44c36a6f6 usb: renesas_usbhs: gadget: fix 
unused-but-set-variable warning)
Merging usb-serial-fixes/usb-linus (fd1b8668af59 USB: serial: option: add 
D-Link DWM-222 device ID)
Merging usb-chipidea-fixes/ci-for-usb-stable (cbb22ebcfb99 usb: chipidea: core: 
check before accessing ci_role in ci_role_show)
Merging phy/fixes (5771a8c08880 Linux v4.13-rc1)
Merging staging.current/staging-linus (f007cad159e9 Revert "firmware: add 
sanity check on shutdown/suspend")
Merging char-misc.current/char-misc-linus (d34fc1adf01f Merge branch 'akpm' 
(patches from Andrew))
Merging input-current/for-linus (a6cbfa1e6d38 Merge branch 'next' into 
for-linus)
Merging crypto-current/master (2d45a7e89833 crypto: af_alg - get_page upon 
reassignment to TX SGL)
Merging ide/master (b671e1703394 PNP: ide: constify pnp_device_id)
Merging vfio-fixes/for-linus (7

Re: [f2fs-dev] [PATCH] f2fs: fix double count on issued discard commands

2017-09-11 Thread Chao Yu
On 2017/9/12 9:53, Chao Yu wrote:
> On 2017/9/11 11:38, Jaegeuk Kim wrote:
>> If issue_cond is true, it does double count for # of issued commands.
>>
>> Signed-off-by: Jaegeuk Kim 
> 
> Reviewed-by: Chao Yu 

As Daeho Jeong mentioned, the change makes 'iter > DISCARD_ISSUE_RATE' dead
code, I just misread iter and issued variable, sorry. :(

Thanks,

> 
>> ---
>>  fs/f2fs/segment.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
>> index 7fd742f747ce..25196ff5d587 100644
>> --- a/fs/f2fs/segment.c
>> +++ b/fs/f2fs/segment.c
>> @@ -1087,7 +1087,7 @@ static int __issue_discard_cmd(struct f2fs_sb_info 
>> *sbi, bool issue_cond)
>>  issued++;
>>  __submit_discard_cmd(sbi, dc);
>>  }
>> -if (issue_cond && iter++ > DISCARD_ISSUE_RATE)
>> +if (issue_cond && iter > DISCARD_ISSUE_RATE)
>>  goto out;
>>  }
>>  if (list_empty(pend_list) && dcc->pend_list_tag[i] & P_TRIM)
>>
> 
> 
> 



Re: [f2fs-dev] [PATCH] f2fs: fix double count on issued discard commands

2017-09-11 Thread Chao Yu
On 2017/9/12 9:53, Chao Yu wrote:
> On 2017/9/11 11:38, Jaegeuk Kim wrote:
>> If issue_cond is true, it does double count for # of issued commands.
>>
>> Signed-off-by: Jaegeuk Kim 
> 
> Reviewed-by: Chao Yu 

As Daeho Jeong mentioned, the change makes 'iter > DISCARD_ISSUE_RATE' dead
code, I just misread iter and issued variable, sorry. :(

Thanks,

> 
>> ---
>>  fs/f2fs/segment.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
>> index 7fd742f747ce..25196ff5d587 100644
>> --- a/fs/f2fs/segment.c
>> +++ b/fs/f2fs/segment.c
>> @@ -1087,7 +1087,7 @@ static int __issue_discard_cmd(struct f2fs_sb_info 
>> *sbi, bool issue_cond)
>>  issued++;
>>  __submit_discard_cmd(sbi, dc);
>>  }
>> -if (issue_cond && iter++ > DISCARD_ISSUE_RATE)
>> +if (issue_cond && iter > DISCARD_ISSUE_RATE)
>>  goto out;
>>  }
>>  if (list_empty(pend_list) && dcc->pend_list_tag[i] & P_TRIM)
>>
> 
> 
> 



[PATCH v2 2/4] ARM: dts: omap3-evm: Add OMAP3530 specific device tree processor data

2017-09-11 Thread Derald D. Woods
This commit allows OMAP3530 variants to use common data that is
available in 'omap3-evm-processor-common.dtsi'. It adds proper pinmux
macros for 'omap3_pmx_core2' on OMAP3430. The Micron NAND chip is also
added for the TMDSEVM3530 processor module.

Signed-off-by: Derald D. Woods 

---
 arch/arm/boot/dts/omap3-evm.dts | 76 ++---
 1 file changed, 72 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-evm.dts b/arch/arm/boot/dts/omap3-evm.dts
index 99b2bfcd1059..21a3b88aef0c 100644
--- a/arch/arm/boot/dts/omap3-evm.dts
+++ b/arch/arm/boot/dts/omap3-evm.dts
@@ -9,13 +9,81 @@
 
 #include "omap34xx.dtsi"
 #include "omap3-evm-common.dtsi"
+#include "omap3-evm-processor-common.dtsi"
 
 / {
model = "TI OMAP35XX EVM (TMDSEVM3530)";
-   compatible = "ti,omap3-evm", "ti,omap3";
+   compatible = "ti,omap3-evm", "ti,omap3430", "ti,omap3";
+};
+
+_pmx_core2 {
+   pinctrl-names = "default";
+   pinctrl-0 = <_2_pins>;
+
+   ehci_phy_pins: pinmux_ehci_phy_pins {
+   pinctrl-single,pins = <
+
+   /* EHCI PHY reset GPIO etk_d7.gpio_21 */
+   OMAP3430_CORE2_IOPAD(0x25ea, PIN_OUTPUT | MUX_MODE4)
+
+   /* EHCI VBUS etk_d8.gpio_22 */
+   OMAP3430_CORE2_IOPAD(0x25ec, PIN_OUTPUT | MUX_MODE4)
+   >;
+   };
+
+   /* Used by OHCI and EHCI. OHCI won't work without external phy */
+   hsusb2_2_pins: pinmux_hsusb2_2_pins {
+   pinctrl-single,pins = <
+
+   /* etk_d10.hsusb2_clk */
+   OMAP3430_CORE2_IOPAD(0x25f0, PIN_OUTPUT | MUX_MODE3)
+
+   /* etk_d11.hsusb2_stp */
+   OMAP3430_CORE2_IOPAD(0x25f2, PIN_OUTPUT | MUX_MODE3)
+
+   /* etk_d12.hsusb2_dir */
+   OMAP3430_CORE2_IOPAD(0x25f4, PIN_INPUT_PULLDOWN | MUX_MODE3)
+
+   /* etk_d13.hsusb2_nxt */
+   OMAP3430_CORE2_IOPAD(0x25f6, PIN_INPUT_PULLDOWN | MUX_MODE3)
+
+   /* etk_d14.hsusb2_data0 */
+   OMAP3430_CORE2_IOPAD(0x25f8, PIN_INPUT_PULLDOWN | MUX_MODE3)
+
+   /* etk_d15.hsusb2_data1 */
+   OMAP3430_CORE2_IOPAD(0x25fa, PIN_INPUT_PULLDOWN | MUX_MODE3)
+   >;
+   };
+};
+
+ {
+   nand@0,0 {
+   compatible = "ti,omap2-nand";
+   reg = <0 0 4>; /* CS0, offset 0, IO size 4 */
+   interrupt-parent = <>;
+   interrupts = <0 IRQ_TYPE_NONE>, /* fifoevent */
+<1 IRQ_TYPE_NONE>; /* termcount */
+   linux,mtd-name= "micron,mt29f2g16abdhc";
+   nand-bus-width = <16>;
+   gpmc,device-width = <2>;
+   ti,nand-ecc-opt = "bch8";
+
+   gpmc,sync-clk-ps = <0>;
+   gpmc,cs-on-ns = <0>;
+   gpmc,cs-rd-off-ns = <44>;
+   gpmc,cs-wr-off-ns = <44>;
+   gpmc,adv-on-ns = <6>;
+   gpmc,adv-rd-off-ns = <34>;
+   gpmc,adv-wr-off-ns = <44>;
+   gpmc,we-off-ns = <40>;
+   gpmc,oe-off-ns = <54>;
+   gpmc,access-ns = <64>;
+   gpmc,rd-cycle-ns = <82>;
+   gpmc,wr-cycle-ns = <82>;
+   gpmc,wr-access-ns = <40>;
+   gpmc,wr-data-mux-bus-ns = <0>;
 
-   memory@8000 {
-   device_type = "memory";
-   reg = <0x8000 0x1000>; /* 256 MB */
+   #address-cells = <1>;
+   #size-cells = <1>;
};
 };
-- 
2.14.1



[PATCH v2 2/4] ARM: dts: omap3-evm: Add OMAP3530 specific device tree processor data

2017-09-11 Thread Derald D. Woods
This commit allows OMAP3530 variants to use common data that is
available in 'omap3-evm-processor-common.dtsi'. It adds proper pinmux
macros for 'omap3_pmx_core2' on OMAP3430. The Micron NAND chip is also
added for the TMDSEVM3530 processor module.

Signed-off-by: Derald D. Woods 

---
 arch/arm/boot/dts/omap3-evm.dts | 76 ++---
 1 file changed, 72 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-evm.dts b/arch/arm/boot/dts/omap3-evm.dts
index 99b2bfcd1059..21a3b88aef0c 100644
--- a/arch/arm/boot/dts/omap3-evm.dts
+++ b/arch/arm/boot/dts/omap3-evm.dts
@@ -9,13 +9,81 @@
 
 #include "omap34xx.dtsi"
 #include "omap3-evm-common.dtsi"
+#include "omap3-evm-processor-common.dtsi"
 
 / {
model = "TI OMAP35XX EVM (TMDSEVM3530)";
-   compatible = "ti,omap3-evm", "ti,omap3";
+   compatible = "ti,omap3-evm", "ti,omap3430", "ti,omap3";
+};
+
+_pmx_core2 {
+   pinctrl-names = "default";
+   pinctrl-0 = <_2_pins>;
+
+   ehci_phy_pins: pinmux_ehci_phy_pins {
+   pinctrl-single,pins = <
+
+   /* EHCI PHY reset GPIO etk_d7.gpio_21 */
+   OMAP3430_CORE2_IOPAD(0x25ea, PIN_OUTPUT | MUX_MODE4)
+
+   /* EHCI VBUS etk_d8.gpio_22 */
+   OMAP3430_CORE2_IOPAD(0x25ec, PIN_OUTPUT | MUX_MODE4)
+   >;
+   };
+
+   /* Used by OHCI and EHCI. OHCI won't work without external phy */
+   hsusb2_2_pins: pinmux_hsusb2_2_pins {
+   pinctrl-single,pins = <
+
+   /* etk_d10.hsusb2_clk */
+   OMAP3430_CORE2_IOPAD(0x25f0, PIN_OUTPUT | MUX_MODE3)
+
+   /* etk_d11.hsusb2_stp */
+   OMAP3430_CORE2_IOPAD(0x25f2, PIN_OUTPUT | MUX_MODE3)
+
+   /* etk_d12.hsusb2_dir */
+   OMAP3430_CORE2_IOPAD(0x25f4, PIN_INPUT_PULLDOWN | MUX_MODE3)
+
+   /* etk_d13.hsusb2_nxt */
+   OMAP3430_CORE2_IOPAD(0x25f6, PIN_INPUT_PULLDOWN | MUX_MODE3)
+
+   /* etk_d14.hsusb2_data0 */
+   OMAP3430_CORE2_IOPAD(0x25f8, PIN_INPUT_PULLDOWN | MUX_MODE3)
+
+   /* etk_d15.hsusb2_data1 */
+   OMAP3430_CORE2_IOPAD(0x25fa, PIN_INPUT_PULLDOWN | MUX_MODE3)
+   >;
+   };
+};
+
+ {
+   nand@0,0 {
+   compatible = "ti,omap2-nand";
+   reg = <0 0 4>; /* CS0, offset 0, IO size 4 */
+   interrupt-parent = <>;
+   interrupts = <0 IRQ_TYPE_NONE>, /* fifoevent */
+<1 IRQ_TYPE_NONE>; /* termcount */
+   linux,mtd-name= "micron,mt29f2g16abdhc";
+   nand-bus-width = <16>;
+   gpmc,device-width = <2>;
+   ti,nand-ecc-opt = "bch8";
+
+   gpmc,sync-clk-ps = <0>;
+   gpmc,cs-on-ns = <0>;
+   gpmc,cs-rd-off-ns = <44>;
+   gpmc,cs-wr-off-ns = <44>;
+   gpmc,adv-on-ns = <6>;
+   gpmc,adv-rd-off-ns = <34>;
+   gpmc,adv-wr-off-ns = <44>;
+   gpmc,we-off-ns = <40>;
+   gpmc,oe-off-ns = <54>;
+   gpmc,access-ns = <64>;
+   gpmc,rd-cycle-ns = <82>;
+   gpmc,wr-cycle-ns = <82>;
+   gpmc,wr-access-ns = <40>;
+   gpmc,wr-data-mux-bus-ns = <0>;
 
-   memory@8000 {
-   device_type = "memory";
-   reg = <0x8000 0x1000>; /* 256 MB */
+   #address-cells = <1>;
+   #size-cells = <1>;
};
 };
-- 
2.14.1



[PATCH v2 1/4] ARM: dts: omap3-evm-37xx: Add common processor module support

2017-09-11 Thread Derald D. Woods
This commit moves common OMAP3-EVM processor module device tree data
to a separate include file. This will allow for 'omap3-evm.dts' to use
device tree data that is unique to the OMAP3530 version of the
processor module, while making use of the work already done for the
'omap3-evm-37xx.dts'.

Signed-off-by: Derald D. Woods 

---
 arch/arm/boot/dts/omap3-evm-37xx.dts  | 209 +
 arch/arm/boot/dts/omap3-evm-processor-common.dtsi | 214 ++
 2 files changed, 215 insertions(+), 208 deletions(-)
 create mode 100644 arch/arm/boot/dts/omap3-evm-processor-common.dtsi

diff --git a/arch/arm/boot/dts/omap3-evm-37xx.dts 
b/arch/arm/boot/dts/omap3-evm-37xx.dts
index c963b31ec3b3..5a4ba0aea447 100644
--- a/arch/arm/boot/dts/omap3-evm-37xx.dts
+++ b/arch/arm/boot/dts/omap3-evm-37xx.dts
@@ -9,146 +9,11 @@
 
 #include "omap36xx.dtsi"
 #include "omap3-evm-common.dtsi"
-
+#include "omap3-evm-processor-common.dtsi"
 
 / {
model = "TI OMAP37XX EVM (TMDSEVM3730)";
compatible = "ti,omap3-evm-37xx", "ti,omap3630", "ti,omap3";
-
-   memory@8000 {
-   device_type = "memory";
-   reg = <0x8000 0x1000>; /* 256 MB */
-   };
-
-   wl12xx_vmmc: wl12xx_vmmc {
-   pinctrl-names = "default";
-   pinctrl-0 = <_gpio>;
-   };
-};
-
- {
-   pinctrl-names = "default";
-   pinctrl-0 = <
-   _dpi_pins1
-   _dpi_pins2
-   >;
-};
-
-_phy {
-   pinctrl-names = "default";
-   pinctrl-0 = <_phy_pins>;
-};
-
-_pmx_core {
-   pinctrl-names = "default";
-   pinctrl-0 = <_board_gpio_61 _pins>;
-
-   dss_dpi_pins1: pinmux_dss_dpi_pins2 {
-   pinctrl-single,pins = <
-   OMAP3_CORE1_IOPAD(0x20d4, PIN_OUTPUT | MUX_MODE0)   /* 
dss_pclk.dss_pclk */
-   OMAP3_CORE1_IOPAD(0x20d6, PIN_OUTPUT | MUX_MODE0)   /* 
dss_hsync.dss_hsync */
-   OMAP3_CORE1_IOPAD(0x20d8, PIN_OUTPUT | MUX_MODE0)   /* 
dss_vsync.dss_vsync */
-   OMAP3_CORE1_IOPAD(0x20da, PIN_OUTPUT | MUX_MODE0)   /* 
dss_acbias.dss_acbias */
-
-   OMAP3_CORE1_IOPAD(0x20e8, PIN_OUTPUT | MUX_MODE0)   /* 
dss_data6.dss_data6 */
-   OMAP3_CORE1_IOPAD(0x20ea, PIN_OUTPUT | MUX_MODE0)   /* 
dss_data7.dss_data7 */
-   OMAP3_CORE1_IOPAD(0x20ec, PIN_OUTPUT | MUX_MODE0)   /* 
dss_data8.dss_data8 */
-   OMAP3_CORE1_IOPAD(0x20ee, PIN_OUTPUT | MUX_MODE0)   /* 
dss_data9.dss_data9 */
-   OMAP3_CORE1_IOPAD(0x20f0, PIN_OUTPUT | MUX_MODE0)   /* 
dss_data10.dss_data10 */
-   OMAP3_CORE1_IOPAD(0x20f2, PIN_OUTPUT | MUX_MODE0)   /* 
dss_data11.dss_data11 */
-   OMAP3_CORE1_IOPAD(0x20f4, PIN_OUTPUT | MUX_MODE0)   /* 
dss_data12.dss_data12 */
-   OMAP3_CORE1_IOPAD(0x20f6, PIN_OUTPUT | MUX_MODE0)   /* 
dss_data13.dss_data13 */
-   OMAP3_CORE1_IOPAD(0x20f8, PIN_OUTPUT | MUX_MODE0)   /* 
dss_data14.dss_data14 */
-   OMAP3_CORE1_IOPAD(0x20fa, PIN_OUTPUT | MUX_MODE0)   /* 
dss_data15.dss_data15 */
-   OMAP3_CORE1_IOPAD(0x20fc, PIN_OUTPUT | MUX_MODE0)   /* 
dss_data16.dss_data16 */
-   OMAP3_CORE1_IOPAD(0x20fe, PIN_OUTPUT | MUX_MODE0)   /* 
dss_data17.dss_data17 */
-
-   OMAP3_CORE1_IOPAD(0x2100, PIN_OUTPUT | MUX_MODE3)   /* 
dss_data18.dss_data0 */
-   OMAP3_CORE1_IOPAD(0x2102, PIN_OUTPUT | MUX_MODE3)   /* 
dss_data19.dss_data1 */
-   OMAP3_CORE1_IOPAD(0x2104, PIN_OUTPUT | MUX_MODE3)   /* 
dss_data20.dss_data2 */
-   OMAP3_CORE1_IOPAD(0x2106, PIN_OUTPUT | MUX_MODE3)   /* 
dss_data21.dss_data3 */
-   OMAP3_CORE1_IOPAD(0x2108, PIN_OUTPUT | MUX_MODE3)   /* 
dss_data22.dss_data4 */
-   OMAP3_CORE1_IOPAD(0x210a, PIN_OUTPUT | MUX_MODE3)   /* 
dss_data23.dss_data5 */
-   >;
-   };
-
-   mmc1_pins: pinmux_mmc1_pins {
-   pinctrl-single,pins = <
-   OMAP3_CORE1_IOPAD(0x2144, PIN_OUTPUT_PULLUP | 
MUX_MODE0)/* sdmmc1_clk.sdmmc1_clk */
-   OMAP3_CORE1_IOPAD(0x2146, PIN_INPUT_PULLUP | MUX_MODE0) 
/* sdmmc1_cmd.sdmmc1_cmd */
-   OMAP3_CORE1_IOPAD(0x2148, PIN_INPUT_PULLUP | MUX_MODE0) 
/* sdmmc1_dat0.sdmmc1_dat0 */
-   OMAP3_CORE1_IOPAD(0x214a, PIN_INPUT_PULLUP | MUX_MODE0) 
/* sdmmc1_dat1.sdmmc1_dat1 */
-   OMAP3_CORE1_IOPAD(0x214c, PIN_INPUT_PULLUP | MUX_MODE0) 
/* sdmmc1_dat2.sdmmc1_dat2 */
-   OMAP3_CORE1_IOPAD(0x214e, PIN_INPUT_PULLUP | MUX_MODE0) 
/* sdmmc1_dat3.sdmmc1_dat3 */
-   OMAP3_CORE1_IOPAD(0x2150, PIN_INPUT_PULLUP | MUX_MODE0) 
/* sdmmc1_dat4.sdmmc1_dat4 

[PATCH v2 3/4] ARM: dts: omap3: Fix Sharp LS037V7DW01 compatible string and envdd supply

2017-09-11 Thread Derald D. Woods
The Sharp panel driver and regulator are now selected properly. This
commit eliminates a dummy regulator assignment.

Signed-off-by: Derald D. Woods 

---
 arch/arm/boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi 
b/arch/arm/boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi
index 157345bb8e79..15f73e5adfdf 100644
--- a/arch/arm/boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi
+++ b/arch/arm/boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi
@@ -26,9 +26,10 @@
};
 
lcd0: display {
-   compatible = "sharp,ls037v7dw01";
+   compatible = "omapdss,sharp,ls037v7dw01";
label = "lcd";
power-supply = <_3v3>;
+   envdd-supply = <_3v3>;
 
port {
lcd_in: endpoint {
-- 
2.14.1



[PATCH v2 1/4] ARM: dts: omap3-evm-37xx: Add common processor module support

2017-09-11 Thread Derald D. Woods
This commit moves common OMAP3-EVM processor module device tree data
to a separate include file. This will allow for 'omap3-evm.dts' to use
device tree data that is unique to the OMAP3530 version of the
processor module, while making use of the work already done for the
'omap3-evm-37xx.dts'.

Signed-off-by: Derald D. Woods 

---
 arch/arm/boot/dts/omap3-evm-37xx.dts  | 209 +
 arch/arm/boot/dts/omap3-evm-processor-common.dtsi | 214 ++
 2 files changed, 215 insertions(+), 208 deletions(-)
 create mode 100644 arch/arm/boot/dts/omap3-evm-processor-common.dtsi

diff --git a/arch/arm/boot/dts/omap3-evm-37xx.dts 
b/arch/arm/boot/dts/omap3-evm-37xx.dts
index c963b31ec3b3..5a4ba0aea447 100644
--- a/arch/arm/boot/dts/omap3-evm-37xx.dts
+++ b/arch/arm/boot/dts/omap3-evm-37xx.dts
@@ -9,146 +9,11 @@
 
 #include "omap36xx.dtsi"
 #include "omap3-evm-common.dtsi"
-
+#include "omap3-evm-processor-common.dtsi"
 
 / {
model = "TI OMAP37XX EVM (TMDSEVM3730)";
compatible = "ti,omap3-evm-37xx", "ti,omap3630", "ti,omap3";
-
-   memory@8000 {
-   device_type = "memory";
-   reg = <0x8000 0x1000>; /* 256 MB */
-   };
-
-   wl12xx_vmmc: wl12xx_vmmc {
-   pinctrl-names = "default";
-   pinctrl-0 = <_gpio>;
-   };
-};
-
- {
-   pinctrl-names = "default";
-   pinctrl-0 = <
-   _dpi_pins1
-   _dpi_pins2
-   >;
-};
-
-_phy {
-   pinctrl-names = "default";
-   pinctrl-0 = <_phy_pins>;
-};
-
-_pmx_core {
-   pinctrl-names = "default";
-   pinctrl-0 = <_board_gpio_61 _pins>;
-
-   dss_dpi_pins1: pinmux_dss_dpi_pins2 {
-   pinctrl-single,pins = <
-   OMAP3_CORE1_IOPAD(0x20d4, PIN_OUTPUT | MUX_MODE0)   /* 
dss_pclk.dss_pclk */
-   OMAP3_CORE1_IOPAD(0x20d6, PIN_OUTPUT | MUX_MODE0)   /* 
dss_hsync.dss_hsync */
-   OMAP3_CORE1_IOPAD(0x20d8, PIN_OUTPUT | MUX_MODE0)   /* 
dss_vsync.dss_vsync */
-   OMAP3_CORE1_IOPAD(0x20da, PIN_OUTPUT | MUX_MODE0)   /* 
dss_acbias.dss_acbias */
-
-   OMAP3_CORE1_IOPAD(0x20e8, PIN_OUTPUT | MUX_MODE0)   /* 
dss_data6.dss_data6 */
-   OMAP3_CORE1_IOPAD(0x20ea, PIN_OUTPUT | MUX_MODE0)   /* 
dss_data7.dss_data7 */
-   OMAP3_CORE1_IOPAD(0x20ec, PIN_OUTPUT | MUX_MODE0)   /* 
dss_data8.dss_data8 */
-   OMAP3_CORE1_IOPAD(0x20ee, PIN_OUTPUT | MUX_MODE0)   /* 
dss_data9.dss_data9 */
-   OMAP3_CORE1_IOPAD(0x20f0, PIN_OUTPUT | MUX_MODE0)   /* 
dss_data10.dss_data10 */
-   OMAP3_CORE1_IOPAD(0x20f2, PIN_OUTPUT | MUX_MODE0)   /* 
dss_data11.dss_data11 */
-   OMAP3_CORE1_IOPAD(0x20f4, PIN_OUTPUT | MUX_MODE0)   /* 
dss_data12.dss_data12 */
-   OMAP3_CORE1_IOPAD(0x20f6, PIN_OUTPUT | MUX_MODE0)   /* 
dss_data13.dss_data13 */
-   OMAP3_CORE1_IOPAD(0x20f8, PIN_OUTPUT | MUX_MODE0)   /* 
dss_data14.dss_data14 */
-   OMAP3_CORE1_IOPAD(0x20fa, PIN_OUTPUT | MUX_MODE0)   /* 
dss_data15.dss_data15 */
-   OMAP3_CORE1_IOPAD(0x20fc, PIN_OUTPUT | MUX_MODE0)   /* 
dss_data16.dss_data16 */
-   OMAP3_CORE1_IOPAD(0x20fe, PIN_OUTPUT | MUX_MODE0)   /* 
dss_data17.dss_data17 */
-
-   OMAP3_CORE1_IOPAD(0x2100, PIN_OUTPUT | MUX_MODE3)   /* 
dss_data18.dss_data0 */
-   OMAP3_CORE1_IOPAD(0x2102, PIN_OUTPUT | MUX_MODE3)   /* 
dss_data19.dss_data1 */
-   OMAP3_CORE1_IOPAD(0x2104, PIN_OUTPUT | MUX_MODE3)   /* 
dss_data20.dss_data2 */
-   OMAP3_CORE1_IOPAD(0x2106, PIN_OUTPUT | MUX_MODE3)   /* 
dss_data21.dss_data3 */
-   OMAP3_CORE1_IOPAD(0x2108, PIN_OUTPUT | MUX_MODE3)   /* 
dss_data22.dss_data4 */
-   OMAP3_CORE1_IOPAD(0x210a, PIN_OUTPUT | MUX_MODE3)   /* 
dss_data23.dss_data5 */
-   >;
-   };
-
-   mmc1_pins: pinmux_mmc1_pins {
-   pinctrl-single,pins = <
-   OMAP3_CORE1_IOPAD(0x2144, PIN_OUTPUT_PULLUP | 
MUX_MODE0)/* sdmmc1_clk.sdmmc1_clk */
-   OMAP3_CORE1_IOPAD(0x2146, PIN_INPUT_PULLUP | MUX_MODE0) 
/* sdmmc1_cmd.sdmmc1_cmd */
-   OMAP3_CORE1_IOPAD(0x2148, PIN_INPUT_PULLUP | MUX_MODE0) 
/* sdmmc1_dat0.sdmmc1_dat0 */
-   OMAP3_CORE1_IOPAD(0x214a, PIN_INPUT_PULLUP | MUX_MODE0) 
/* sdmmc1_dat1.sdmmc1_dat1 */
-   OMAP3_CORE1_IOPAD(0x214c, PIN_INPUT_PULLUP | MUX_MODE0) 
/* sdmmc1_dat2.sdmmc1_dat2 */
-   OMAP3_CORE1_IOPAD(0x214e, PIN_INPUT_PULLUP | MUX_MODE0) 
/* sdmmc1_dat3.sdmmc1_dat3 */
-   OMAP3_CORE1_IOPAD(0x2150, PIN_INPUT_PULLUP | MUX_MODE0) 
/* sdmmc1_dat4.sdmmc1_dat4 */
-   

[PATCH v2 3/4] ARM: dts: omap3: Fix Sharp LS037V7DW01 compatible string and envdd supply

2017-09-11 Thread Derald D. Woods
The Sharp panel driver and regulator are now selected properly. This
commit eliminates a dummy regulator assignment.

Signed-off-by: Derald D. Woods 

---
 arch/arm/boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi 
b/arch/arm/boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi
index 157345bb8e79..15f73e5adfdf 100644
--- a/arch/arm/boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi
+++ b/arch/arm/boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi
@@ -26,9 +26,10 @@
};
 
lcd0: display {
-   compatible = "sharp,ls037v7dw01";
+   compatible = "omapdss,sharp,ls037v7dw01";
label = "lcd";
power-supply = <_3v3>;
+   envdd-supply = <_3v3>;
 
port {
lcd_in: endpoint {
-- 
2.14.1



[PATCH v2 0/4] Update TMDSEVM3530 support for omap3-evm

2017-09-11 Thread Derald D. Woods
This patch set allows TMDSEVM3530(omap3-evm.dts) to boot using common
processor module data that is shared with 'omap3-evm-37xx.dts'. A new
common file for processor module data is introduced to help facilitate
the updated OMAP3530 support.

Changes in v2
-
- Pull in change from linux-next
  (ARM: dts: omap*: Replace deprecated "vmmc_aux" with "vqmmc")
- Add compatible and supply fix for LCD panel
- Add supply references for DSS
- Add "Signed-off-by" for each patch

Derald D. Woods (4):
  ARM: dts: omap3-evm-37xx: Add common processor module support
  ARM: dts: omap3-evm: Add OMAP3530 specific device tree processor data
  ARM: dts: omap3: Fix Sharp LS037V7DW01 compatible string and envdd
supply
  ARM: dts: omap3-evm: Add DSS {vdds_dsi,vdda_video}-supply references

 arch/arm/boot/dts/omap3-evm-37xx.dts   | 209 +---
 arch/arm/boot/dts/omap3-evm-processor-common.dtsi  | 216 +
 arch/arm/boot/dts/omap3-evm.dts|  76 +++-
 .../boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi|   3 +-
 4 files changed, 291 insertions(+), 213 deletions(-)
 create mode 100644 arch/arm/boot/dts/omap3-evm-processor-common.dtsi

-- 
2.14.1



[PATCH v2 4/4] ARM: dts: omap3-evm: Add DSS {vdds_dsi,vdda_video}-supply references

2017-09-11 Thread Derald D. Woods
This commit eliminates two dummy regulator assignments.

Signed-off-by: Derald D. Woods 

---
 arch/arm/boot/dts/omap3-evm-processor-common.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/omap3-evm-processor-common.dtsi 
b/arch/arm/boot/dts/omap3-evm-processor-common.dtsi
index c1fb6ecd5aff..ce7f42f9448c 100644
--- a/arch/arm/boot/dts/omap3-evm-processor-common.dtsi
+++ b/arch/arm/boot/dts/omap3-evm-processor-common.dtsi
@@ -15,6 +15,8 @@
 };
 
  {
+   vdds_dsi-supply = <>;
+   vdda_video-supply = <_3v3>;
pinctrl-names = "default";
pinctrl-0 = <
_dpi_pins1
-- 
2.14.1



[PATCH v2 0/4] Update TMDSEVM3530 support for omap3-evm

2017-09-11 Thread Derald D. Woods
This patch set allows TMDSEVM3530(omap3-evm.dts) to boot using common
processor module data that is shared with 'omap3-evm-37xx.dts'. A new
common file for processor module data is introduced to help facilitate
the updated OMAP3530 support.

Changes in v2
-
- Pull in change from linux-next
  (ARM: dts: omap*: Replace deprecated "vmmc_aux" with "vqmmc")
- Add compatible and supply fix for LCD panel
- Add supply references for DSS
- Add "Signed-off-by" for each patch

Derald D. Woods (4):
  ARM: dts: omap3-evm-37xx: Add common processor module support
  ARM: dts: omap3-evm: Add OMAP3530 specific device tree processor data
  ARM: dts: omap3: Fix Sharp LS037V7DW01 compatible string and envdd
supply
  ARM: dts: omap3-evm: Add DSS {vdds_dsi,vdda_video}-supply references

 arch/arm/boot/dts/omap3-evm-37xx.dts   | 209 +---
 arch/arm/boot/dts/omap3-evm-processor-common.dtsi  | 216 +
 arch/arm/boot/dts/omap3-evm.dts|  76 +++-
 .../boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi|   3 +-
 4 files changed, 291 insertions(+), 213 deletions(-)
 create mode 100644 arch/arm/boot/dts/omap3-evm-processor-common.dtsi

-- 
2.14.1



[PATCH v2 4/4] ARM: dts: omap3-evm: Add DSS {vdds_dsi,vdda_video}-supply references

2017-09-11 Thread Derald D. Woods
This commit eliminates two dummy regulator assignments.

Signed-off-by: Derald D. Woods 

---
 arch/arm/boot/dts/omap3-evm-processor-common.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/omap3-evm-processor-common.dtsi 
b/arch/arm/boot/dts/omap3-evm-processor-common.dtsi
index c1fb6ecd5aff..ce7f42f9448c 100644
--- a/arch/arm/boot/dts/omap3-evm-processor-common.dtsi
+++ b/arch/arm/boot/dts/omap3-evm-processor-common.dtsi
@@ -15,6 +15,8 @@
 };
 
  {
+   vdds_dsi-supply = <>;
+   vdda_video-supply = <_3v3>;
pinctrl-names = "default";
pinctrl-0 = <
_dpi_pins1
-- 
2.14.1



Re: [PATCH v2 2/3] livepatch: add atomic replace

2017-09-11 Thread Jason Baron


On 09/11/2017 09:53 AM, Petr Mladek wrote:
> On Wed 2017-08-30 17:38:44, Jason Baron wrote:
>> When doing cumulative patches, if patch A introduces a change to function 1,
>> and patch B reverts the change to function 1 and introduces changes to say
>> function 2 and 3 as well, the change that patch A introduced to function 1
>> is still present.
> 
> This is a bit confusing. One might thing that the function 1 still
> uses the code added by the patch A. I would say something like:
> 
> 
> Sometimes we would like to revert a particular fix. This is not easy
> because we want to keep all other fixes active and we could revert
> only the last applied patch.
> 
> One solution would be to apply new patch that implemented all
> the reverted functions like in the original code. It would work
> as expected but there will be unnecessary redirections.
> 
> A better solution would be to say that a new patch replaces
> an older one. This might be complicated if we want to replace
> a particular patch. But it is rather easy when a new cummulative
> patch replaces all others.
> 
> For this, a new "replace" flag is added to the struct klp_patch.
> When it is enabled, 'no_op' klp_func will be dynamically
> created for all functions that are already being patched but
> that will not longer be modified by the new patch. They are
> temporarily used as a new target during the patch transition...
> 
>

ok. I will re-work the text here.

>> Introduce atomic replace, by first creating a 'no_op' klp_func for all
>> the functions that are reverted by patch B. The reason that 'no_op'
>> klp_funcs are created, instead of just unregistering directly from the ftrace
>> function hook, is to ensure that the consistency model is properly preserved.
>> By introducing the 'no_op' functions, 'atomic replace' leverages the existing
>> consistency model code. Then, after transition to the new code, 'atomic
>> replace' unregisters the ftrace handlers that are associated with the 'no_op'
>> klp_funcs, such that that we run the original un-patched function with no
>> additional no_op function overhead.
>>
>> Since 'atomic replace' has completely replaced all previous livepatch 
>> modules,
>> it explicitly disables all previous livepatch modules, in the example- patch 
>> A,
>> such that the livepatch module associated with patch A can be completely 
>> removed
>> (rmmod). Patch A is now in a permanently disabled state. But if it is removed
>> from the kernel with rmmod, it can be re-inserted (insmod), and act as an 
>> atomic
>> replace on top of patch A.
>>
>> diff --git a/include/linux/livepatch.h b/include/linux/livepatch.h
>> index 8d3df55..ee6d18b 100644
>> --- a/include/linux/livepatch.h
>> +++ b/include/linux/livepatch.h
>> @@ -119,10 +121,12 @@ struct klp_object {
>>   * @mod:reference to the live patch module
>>   * @objs:   object entries for kernel objects to be patched
>>   * @immediate:  patch all funcs immediately, bypassing safety mechanisms
>> + * @replace:replace all funcs, reverting functions that are no 
>> longer patched
>>   * @list:   list node for global list of registered patches
>>   * @kobj:   kobject for sysfs resources
>>   * @obj_list:   head of list for dynamically allocated struct klp_object
>>   * @enabled:the patch is enabled (but operation may be incomplete)
>> + * @replaced:   the patch has been replaced an can not be re-enabled
> 
> I finally understand why you do this. I forgot that even disabled
> patches are still in klp_patch list.
> 
> This makes some sense for patches that fix different bugs and
> touch the same function. They should be applied and enabled
> in the right order because a later patch for the same function
> must be based on the code from the previous one.
> 
> It makes less sense for cummulative patches that we use in kGraft.
> There basically every patch has the "replace" flag set. If
> we enable one patch it simply replaces any other one. Then
> ordering is not important. Each patch is standalone and
> consistent on its own.
> 
> 
> I see two problems with your approach. One is cosmetic.
> The names of the two flags replace/replaced are too similar.
> It is quite prone for mistakes ;-)
> 
> Second, we could not remove module where any function is patched
> usign the "immediate" flag. But people might want to revert
> to this patch if the last one does not work as expected.
> After all the main purpose of livepatching is to fix
> problems without a system reboot. Therefore we should
> allow to enable the replaced patches even without
> removing the module.
> 

If the livepatch has the 'replace' bit set and not the 'immediate' bit,
then I believe that we could remove *all* types of previous livepatches
even if they have the 'immediate' flag set. That is, because of the
consistency model, we are sure that we are running only functions from
the cumulative replace patch.

So I think it may be worth making a distinction between patches that
have 'replace' bit 

Re: [PATCH v2 2/3] livepatch: add atomic replace

2017-09-11 Thread Jason Baron


On 09/11/2017 09:53 AM, Petr Mladek wrote:
> On Wed 2017-08-30 17:38:44, Jason Baron wrote:
>> When doing cumulative patches, if patch A introduces a change to function 1,
>> and patch B reverts the change to function 1 and introduces changes to say
>> function 2 and 3 as well, the change that patch A introduced to function 1
>> is still present.
> 
> This is a bit confusing. One might thing that the function 1 still
> uses the code added by the patch A. I would say something like:
> 
> 
> Sometimes we would like to revert a particular fix. This is not easy
> because we want to keep all other fixes active and we could revert
> only the last applied patch.
> 
> One solution would be to apply new patch that implemented all
> the reverted functions like in the original code. It would work
> as expected but there will be unnecessary redirections.
> 
> A better solution would be to say that a new patch replaces
> an older one. This might be complicated if we want to replace
> a particular patch. But it is rather easy when a new cummulative
> patch replaces all others.
> 
> For this, a new "replace" flag is added to the struct klp_patch.
> When it is enabled, 'no_op' klp_func will be dynamically
> created for all functions that are already being patched but
> that will not longer be modified by the new patch. They are
> temporarily used as a new target during the patch transition...
> 
>

ok. I will re-work the text here.

>> Introduce atomic replace, by first creating a 'no_op' klp_func for all
>> the functions that are reverted by patch B. The reason that 'no_op'
>> klp_funcs are created, instead of just unregistering directly from the ftrace
>> function hook, is to ensure that the consistency model is properly preserved.
>> By introducing the 'no_op' functions, 'atomic replace' leverages the existing
>> consistency model code. Then, after transition to the new code, 'atomic
>> replace' unregisters the ftrace handlers that are associated with the 'no_op'
>> klp_funcs, such that that we run the original un-patched function with no
>> additional no_op function overhead.
>>
>> Since 'atomic replace' has completely replaced all previous livepatch 
>> modules,
>> it explicitly disables all previous livepatch modules, in the example- patch 
>> A,
>> such that the livepatch module associated with patch A can be completely 
>> removed
>> (rmmod). Patch A is now in a permanently disabled state. But if it is removed
>> from the kernel with rmmod, it can be re-inserted (insmod), and act as an 
>> atomic
>> replace on top of patch A.
>>
>> diff --git a/include/linux/livepatch.h b/include/linux/livepatch.h
>> index 8d3df55..ee6d18b 100644
>> --- a/include/linux/livepatch.h
>> +++ b/include/linux/livepatch.h
>> @@ -119,10 +121,12 @@ struct klp_object {
>>   * @mod:reference to the live patch module
>>   * @objs:   object entries for kernel objects to be patched
>>   * @immediate:  patch all funcs immediately, bypassing safety mechanisms
>> + * @replace:replace all funcs, reverting functions that are no 
>> longer patched
>>   * @list:   list node for global list of registered patches
>>   * @kobj:   kobject for sysfs resources
>>   * @obj_list:   head of list for dynamically allocated struct klp_object
>>   * @enabled:the patch is enabled (but operation may be incomplete)
>> + * @replaced:   the patch has been replaced an can not be re-enabled
> 
> I finally understand why you do this. I forgot that even disabled
> patches are still in klp_patch list.
> 
> This makes some sense for patches that fix different bugs and
> touch the same function. They should be applied and enabled
> in the right order because a later patch for the same function
> must be based on the code from the previous one.
> 
> It makes less sense for cummulative patches that we use in kGraft.
> There basically every patch has the "replace" flag set. If
> we enable one patch it simply replaces any other one. Then
> ordering is not important. Each patch is standalone and
> consistent on its own.
> 
> 
> I see two problems with your approach. One is cosmetic.
> The names of the two flags replace/replaced are too similar.
> It is quite prone for mistakes ;-)
> 
> Second, we could not remove module where any function is patched
> usign the "immediate" flag. But people might want to revert
> to this patch if the last one does not work as expected.
> After all the main purpose of livepatching is to fix
> problems without a system reboot. Therefore we should
> allow to enable the replaced patches even without
> removing the module.
> 

If the livepatch has the 'replace' bit set and not the 'immediate' bit,
then I believe that we could remove *all* types of previous livepatches
even if they have the 'immediate' flag set. That is, because of the
consistency model, we are sure that we are running only functions from
the cumulative replace patch.

So I think it may be worth making a distinction between patches that
have 'replace' bit 

[PATCH] nios2: time: Read timer in get_cycles only if initialized

2017-09-11 Thread Guenter Roeck
Mainline crashes as follows when running nios2 images.

On node 0 totalpages: 65536
free_area_init_node: node 0, pgdat c8408fa0, node_mem_map c8726000
  Normal zone: 512 pages used for memmap
  Normal zone: 0 pages reserved
  Normal zone: 65536 pages, LIFO batch:15
Unable to handle kernel NULL pointer dereference at virtual address 
ea = c8003cb0, ra = c81cbf40, cause = 15
Kernel panic - not syncing: Oops

Problem is seen because get_cycles() is called before the timer it depends
on is initialized. Returning 0 in that situation fixes the problem.

Fixes: 33d72f3822d7 ("init/main.c: extract early boot entropy from the ..")
Cc: Laura Abbott 
Cc: Kees Cook 
Cc: Daniel Micay 
Signed-off-by: Guenter Roeck 
---
Taking a stab at the problem. Fix works for my qemu test.

 arch/nios2/kernel/time.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/nios2/kernel/time.c b/arch/nios2/kernel/time.c
index 645129aaa9a0..20e86209ef2e 100644
--- a/arch/nios2/kernel/time.c
+++ b/arch/nios2/kernel/time.c
@@ -107,7 +107,10 @@ static struct nios2_clocksource nios2_cs = {
 
 cycles_t get_cycles(void)
 {
-   return nios2_timer_read(_cs.cs);
+   /* Only read timer if it has been initialized */
+   if (nios2_cs.timer.base)
+   return nios2_timer_read(_cs.cs);
+   return 0;
 }
 EXPORT_SYMBOL(get_cycles);
 
-- 
2.7.4



[PATCH] nios2: time: Read timer in get_cycles only if initialized

2017-09-11 Thread Guenter Roeck
Mainline crashes as follows when running nios2 images.

On node 0 totalpages: 65536
free_area_init_node: node 0, pgdat c8408fa0, node_mem_map c8726000
  Normal zone: 512 pages used for memmap
  Normal zone: 0 pages reserved
  Normal zone: 65536 pages, LIFO batch:15
Unable to handle kernel NULL pointer dereference at virtual address 
ea = c8003cb0, ra = c81cbf40, cause = 15
Kernel panic - not syncing: Oops

Problem is seen because get_cycles() is called before the timer it depends
on is initialized. Returning 0 in that situation fixes the problem.

Fixes: 33d72f3822d7 ("init/main.c: extract early boot entropy from the ..")
Cc: Laura Abbott 
Cc: Kees Cook 
Cc: Daniel Micay 
Signed-off-by: Guenter Roeck 
---
Taking a stab at the problem. Fix works for my qemu test.

 arch/nios2/kernel/time.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/nios2/kernel/time.c b/arch/nios2/kernel/time.c
index 645129aaa9a0..20e86209ef2e 100644
--- a/arch/nios2/kernel/time.c
+++ b/arch/nios2/kernel/time.c
@@ -107,7 +107,10 @@ static struct nios2_clocksource nios2_cs = {
 
 cycles_t get_cycles(void)
 {
-   return nios2_timer_read(_cs.cs);
+   /* Only read timer if it has been initialized */
+   if (nios2_cs.timer.base)
+   return nios2_timer_read(_cs.cs);
+   return 0;
 }
 EXPORT_SYMBOL(get_cycles);
 
-- 
2.7.4



Re: usb/joystick: warnings in xpad_start_input and xpad_try_sending_next_out_packet

2017-09-11 Thread Cameron Gutman
On 09/11/2017 05:26 AM, Andrey Konovalov wrote:
> Hi!
> 
> I've got the following crashes while fuzzing the kernel with syzkaller.
> 
> On commit 81a84ad3cb5711cec79f4dd53a4ce026b092c432 (Sep 3).
> 
> usb 1-1: BOGUS urb xfer, pipe 1 != type 3
> WARNING: CPU: 1 PID: 2574 at drivers/usb/core/urb.c:449
> usb_submit_urb+0xf8a/0x11d0
> Modules linked in:
> CPU: 1 PID: 2574 Comm: kworker/1:2 Not tainted 4.13.0+ #88
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> Workqueue: usb_hub_wq hub_event
> task: 880067ec9a00 task.stack: 880067988000
> RIP: 0010:usb_submit_urb+0xf8a/0x11d0 drivers/usb/core/urb.c:448
> RSP: 0018:88006798e0b0 EFLAGS: 00010082
> RAX: 0029 RBX: 88006b9ca200 RCX: 
> RDX: 0029 RSI: 88006c915c78 RDI: ed000cf31c08
> RBP: 88006798e1b0 R08: fbfff0fe00ff R09: fbfff0fe00ff
> R10: 0001 R11: fbfff0fe00fe R12: 11000cf31c1d
> R13: 0003 R14: 0001 R15: 88006b164798
> FS:  () GS:88006c90() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 7fde04686518 CR3: 6a539000 CR4: 06e0
> Call Trace:
>  xpad_try_sending_next_out_packet+0xe1/0x1d0 
> drivers/input/joystick/xpad.c:1000
>  xpad_send_led_command drivers/input/joystick/xpad.c:1372
>  xpad_led_set+0x465/0x6e0 drivers/input/joystick/xpad.c:1392
>  __led_set_brightness drivers/leds/led-core.c:34
>  led_set_brightness_nopm+0x53/0x100 drivers/leds/led-core.c:261
>  led_set_brightness_nosleep+0x17f/0x220 drivers/leds/led-core.c:278
>  led_set_brightness+0xfe/0x130 drivers/leds/led-core.c:253
>  xpad_identify_controller drivers/input/joystick/xpad.c:1383
>  xpad_led_probe drivers/input/joystick/xpad.c:1426
>  xpad_init_input+0xd40/0xfe0 drivers/input/joystick/xpad.c:1667
>  xpad_probe+0x13d4/0x1e00 drivers/input/joystick/xpad.c:1811
>  usb_probe_interface+0x351/0x8d0 drivers/usb/core/driver.c:361
>  really_probe drivers/base/dd.c:385
>  driver_probe_device+0x610/0xa00 drivers/base/dd.c:529
>  __device_attach_driver+0x230/0x290 drivers/base/dd.c:625
>  bus_for_each_drv+0x15e/0x210 drivers/base/bus.c:463
>  __device_attach+0x269/0x3c0 drivers/base/dd.c:682
>  device_initial_probe+0x1f/0x30 drivers/base/dd.c:729
>  bus_probe_device+0x1da/0x280 drivers/base/bus.c:523
>  device_add+0xcf9/0x1640 drivers/base/core.c:1703
>  usb_set_configuration+0x1064/0x1890 drivers/usb/core/message.c:1932
>  generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174
>  usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266
>  really_probe drivers/base/dd.c:385
>  driver_probe_device+0x610/0xa00 drivers/base/dd.c:529
>  __device_attach_driver+0x230/0x290 drivers/base/dd.c:625
>  bus_for_each_drv+0x15e/0x210 drivers/base/bus.c:463
>  __device_attach+0x269/0x3c0 drivers/base/dd.c:682
>  device_initial_probe+0x1f/0x30 drivers/base/dd.c:729
>  bus_probe_device+0x1da/0x280 drivers/base/bus.c:523
>  device_add+0xcf9/0x1640 drivers/base/core.c:1703
>  usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2457
>  hub_port_connect drivers/usb/core/hub.c:4890
>  hub_port_connect_change drivers/usb/core/hub.c:4996
>  port_event drivers/usb/core/hub.c:5102
>  hub_event+0x23c8/0x37c0 drivers/usb/core/hub.c:5182
>  process_one_work+0x9fb/0x1570 kernel/workqueue.c:2097
>  worker_thread+0x1e4/0x1350 kernel/workqueue.c:2231
>  kthread+0x324/0x3f0 kernel/kthread.c:231
>  ret_from_fork+0x25/0x30 arch/x86/entry/entry_64.S:425
> Code: 48 8b 85 30 ff ff ff 48 8d b8 98 00 00 00 e8 8e 93 07 ff 45 89
> e8 44 89 f1 4c 89 fa 48 89 c6 48 c7 c7 a0 e5 55 86 e8 20 08 8f fd <0f>
> ff e9 9b f7 ff ff e8 4a 04 d6 fd e9 80 f7 ff ff e8 60 11 a6
> ---[ end trace 5b20fc700a17a457 ]---

I assume you're doing some sort of USB emulation to fuzz these? I don't
think we'd get that far with any real device that wasn't explicitly designed
to trick us.

In any case, this patch should take care of it.

Regards,
Cameron


diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
index f8e34ef643c7..d86e59515b9c 100644
--- a/drivers/input/joystick/xpad.c
+++ b/drivers/input/joystick/xpad.c
@@ -1764,10 +1764,12 @@ static int xpad_probe(struct usb_interface *intf, const 
struct usb_device_id *id
struct usb_endpoint_descriptor *ep =
>cur_altsetting->endpoint[i].desc;
 
-   if (usb_endpoint_dir_in(ep))
-   ep_irq_in = ep;
-   else
-   ep_irq_out = ep;
+   if (usb_endpoint_xfer_int(ep)) {
+   if (usb_endpoint_dir_in(ep))
+   ep_irq_in = ep;
+   else
+   ep_irq_out = ep;
+   }
}
 
if (!ep_irq_in || !ep_irq_out) {






Re: usb/joystick: warnings in xpad_start_input and xpad_try_sending_next_out_packet

2017-09-11 Thread Cameron Gutman
On 09/11/2017 05:26 AM, Andrey Konovalov wrote:
> Hi!
> 
> I've got the following crashes while fuzzing the kernel with syzkaller.
> 
> On commit 81a84ad3cb5711cec79f4dd53a4ce026b092c432 (Sep 3).
> 
> usb 1-1: BOGUS urb xfer, pipe 1 != type 3
> WARNING: CPU: 1 PID: 2574 at drivers/usb/core/urb.c:449
> usb_submit_urb+0xf8a/0x11d0
> Modules linked in:
> CPU: 1 PID: 2574 Comm: kworker/1:2 Not tainted 4.13.0+ #88
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> Workqueue: usb_hub_wq hub_event
> task: 880067ec9a00 task.stack: 880067988000
> RIP: 0010:usb_submit_urb+0xf8a/0x11d0 drivers/usb/core/urb.c:448
> RSP: 0018:88006798e0b0 EFLAGS: 00010082
> RAX: 0029 RBX: 88006b9ca200 RCX: 
> RDX: 0029 RSI: 88006c915c78 RDI: ed000cf31c08
> RBP: 88006798e1b0 R08: fbfff0fe00ff R09: fbfff0fe00ff
> R10: 0001 R11: fbfff0fe00fe R12: 11000cf31c1d
> R13: 0003 R14: 0001 R15: 88006b164798
> FS:  () GS:88006c90() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 7fde04686518 CR3: 6a539000 CR4: 06e0
> Call Trace:
>  xpad_try_sending_next_out_packet+0xe1/0x1d0 
> drivers/input/joystick/xpad.c:1000
>  xpad_send_led_command drivers/input/joystick/xpad.c:1372
>  xpad_led_set+0x465/0x6e0 drivers/input/joystick/xpad.c:1392
>  __led_set_brightness drivers/leds/led-core.c:34
>  led_set_brightness_nopm+0x53/0x100 drivers/leds/led-core.c:261
>  led_set_brightness_nosleep+0x17f/0x220 drivers/leds/led-core.c:278
>  led_set_brightness+0xfe/0x130 drivers/leds/led-core.c:253
>  xpad_identify_controller drivers/input/joystick/xpad.c:1383
>  xpad_led_probe drivers/input/joystick/xpad.c:1426
>  xpad_init_input+0xd40/0xfe0 drivers/input/joystick/xpad.c:1667
>  xpad_probe+0x13d4/0x1e00 drivers/input/joystick/xpad.c:1811
>  usb_probe_interface+0x351/0x8d0 drivers/usb/core/driver.c:361
>  really_probe drivers/base/dd.c:385
>  driver_probe_device+0x610/0xa00 drivers/base/dd.c:529
>  __device_attach_driver+0x230/0x290 drivers/base/dd.c:625
>  bus_for_each_drv+0x15e/0x210 drivers/base/bus.c:463
>  __device_attach+0x269/0x3c0 drivers/base/dd.c:682
>  device_initial_probe+0x1f/0x30 drivers/base/dd.c:729
>  bus_probe_device+0x1da/0x280 drivers/base/bus.c:523
>  device_add+0xcf9/0x1640 drivers/base/core.c:1703
>  usb_set_configuration+0x1064/0x1890 drivers/usb/core/message.c:1932
>  generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174
>  usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266
>  really_probe drivers/base/dd.c:385
>  driver_probe_device+0x610/0xa00 drivers/base/dd.c:529
>  __device_attach_driver+0x230/0x290 drivers/base/dd.c:625
>  bus_for_each_drv+0x15e/0x210 drivers/base/bus.c:463
>  __device_attach+0x269/0x3c0 drivers/base/dd.c:682
>  device_initial_probe+0x1f/0x30 drivers/base/dd.c:729
>  bus_probe_device+0x1da/0x280 drivers/base/bus.c:523
>  device_add+0xcf9/0x1640 drivers/base/core.c:1703
>  usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2457
>  hub_port_connect drivers/usb/core/hub.c:4890
>  hub_port_connect_change drivers/usb/core/hub.c:4996
>  port_event drivers/usb/core/hub.c:5102
>  hub_event+0x23c8/0x37c0 drivers/usb/core/hub.c:5182
>  process_one_work+0x9fb/0x1570 kernel/workqueue.c:2097
>  worker_thread+0x1e4/0x1350 kernel/workqueue.c:2231
>  kthread+0x324/0x3f0 kernel/kthread.c:231
>  ret_from_fork+0x25/0x30 arch/x86/entry/entry_64.S:425
> Code: 48 8b 85 30 ff ff ff 48 8d b8 98 00 00 00 e8 8e 93 07 ff 45 89
> e8 44 89 f1 4c 89 fa 48 89 c6 48 c7 c7 a0 e5 55 86 e8 20 08 8f fd <0f>
> ff e9 9b f7 ff ff e8 4a 04 d6 fd e9 80 f7 ff ff e8 60 11 a6
> ---[ end trace 5b20fc700a17a457 ]---

I assume you're doing some sort of USB emulation to fuzz these? I don't
think we'd get that far with any real device that wasn't explicitly designed
to trick us.

In any case, this patch should take care of it.

Regards,
Cameron


diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
index f8e34ef643c7..d86e59515b9c 100644
--- a/drivers/input/joystick/xpad.c
+++ b/drivers/input/joystick/xpad.c
@@ -1764,10 +1764,12 @@ static int xpad_probe(struct usb_interface *intf, const 
struct usb_device_id *id
struct usb_endpoint_descriptor *ep =
>cur_altsetting->endpoint[i].desc;
 
-   if (usb_endpoint_dir_in(ep))
-   ep_irq_in = ep;
-   else
-   ep_irq_out = ep;
+   if (usb_endpoint_xfer_int(ep)) {
+   if (usb_endpoint_dir_in(ep))
+   ep_irq_in = ep;
+   else
+   ep_irq_out = ep;
+   }
}
 
if (!ep_irq_in || !ep_irq_out) {






[PATCH v3 2/5] staging: typec: tcpm: Document data structures

2017-09-11 Thread Guenter Roeck
Document struct tcpc_config and struct tcpc_dev.
Drop unused TCPC_USB_SWITCH_RESTORE.

Signed-off-by: Guenter Roeck 
---
v2, v3: No change

 drivers/staging/typec/tcpm.h | 57 ++--
 1 file changed, 50 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/typec/tcpm.h b/drivers/staging/typec/tcpm.h
index 7e9a6b7b5cd6..073197f0d2bb 100644
--- a/drivers/staging/typec/tcpm.h
+++ b/drivers/staging/typec/tcpm.h
@@ -54,6 +54,27 @@ enum tcpm_transmit_type {
TCPC_TX_BIST_MODE_2 = 7
 };
 
+/**
+ * struct tcpc_config - Port configuration
+ * @src_pdo:   PDO parameters sent to port partner as response to
+ * PD_CTRL_GET_SOURCE_CAP message
+ * @nr_src_pdo:Number of entries in @src_pdo
+ * @snk_pdo:   PDO parameters sent to partner as response to
+ * PD_CTRL_GET_SINK_CAP message
+ * @nr_snk_pdo:Number of entries in @snk_pdo
+ * @max_snk_mv:Maximum acceptable sink voltage in mV
+ * @max_snk_ma:Maximum sink current in mA
+ * @max_snk_mw:Maximum required sink power in mW
+ * @operating_snk_mw:
+ * Required operating sink power in mW
+ * @type:  Port type (TYPEC_PORT_DFP, TYPEC_PORT_UFP, or
+ * TYPEC_PORT_DRP)
+ * @default_role:
+ * Default port role (TYPEC_SINK or TYPEC_SOURCE).
+ * Set to TYPEC_NO_PREFERRED_ROLE if no default role.
+ * @try_role_hw:True if try.{Src,Snk} is implemented in hardware
+ * @alt_modes: List of supported alternate modes
+ */
 struct tcpc_config {
const u32 *src_pdo;
unsigned int nr_src_pdo;
@@ -79,7 +100,6 @@ struct tcpc_config {
 enum tcpc_usb_switch {
TCPC_USB_SWITCH_CONNECT,
TCPC_USB_SWITCH_DISCONNECT,
-   TCPC_USB_SWITCH_RESTORE,/* TODO FIXME */
 };
 
 /* Mux state attributes */
@@ -104,17 +124,40 @@ struct tcpc_mux_dev {
void *priv_data;
 };
 
+/**
+ * struct tcpc_dev - Port configuration and callback functions
+ * @config:Pointer to port configuration
+ * @get_vbus:  Called to read current VBUS state
+ * @get_current_limit:
+ * Optional; called by the tcpm core when configured as a snk
+ * and cc=Rp-def. This allows the tcpm to provide a fallback
+ * current-limit detection method for the cc=Rp-def case.
+ * For example, some tcpcs may include BC1.2 charger detection
+ * and use that in this case.
+ * @set_cc:Called to set value of CC pins
+ * @get_cc:Called to read current CC pin values
+ * @set_polarity:
+ * Called to set polarity
+ * @set_vconn: Called to enable or disable VCONN
+ * @set_vbus:  Called to enable or disable VBUS
+ * @set_current_limit:
+ * Optional; called to set current limit as negotiated
+ * with partner.
+ * @set_pd_rx: Called to enable or disable reception of PD messages
+ * @set_roles: Called to set power and data roles
+ * @start_drp_toggling:
+ * Optional; if supported by hardware, called to start DRP
+ * toggling. DRP toggling is stopped automatically if
+ * a connection is established.
+ * @try_role:  Optional; called to set a preferred role
+ * @pd_transmit:Called to transmit PD message
+ * @mux:   Pointer to multiplexer data
+ */
 struct tcpc_dev {
const struct tcpc_config *config;
 
int (*init)(struct tcpc_dev *dev);
int (*get_vbus)(struct tcpc_dev *dev);
-   /*
-* This optional callback gets called by the tcpm core when configured
-* as a snk and cc=Rp-def. This allows the tcpm to provide a fallback
-* current-limit detection method for the cc=Rp-def case. E.g. some
-* tcpcs may include BC1.2 charger detection and use that in this case.
-*/
int (*get_current_limit)(struct tcpc_dev *dev);
int (*set_cc)(struct tcpc_dev *dev, enum typec_cc_status cc);
int (*get_cc)(struct tcpc_dev *dev, enum typec_cc_status *cc1,
-- 
2.7.4



[PATCH v3 2/5] staging: typec: tcpm: Document data structures

2017-09-11 Thread Guenter Roeck
Document struct tcpc_config and struct tcpc_dev.
Drop unused TCPC_USB_SWITCH_RESTORE.

Signed-off-by: Guenter Roeck 
---
v2, v3: No change

 drivers/staging/typec/tcpm.h | 57 ++--
 1 file changed, 50 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/typec/tcpm.h b/drivers/staging/typec/tcpm.h
index 7e9a6b7b5cd6..073197f0d2bb 100644
--- a/drivers/staging/typec/tcpm.h
+++ b/drivers/staging/typec/tcpm.h
@@ -54,6 +54,27 @@ enum tcpm_transmit_type {
TCPC_TX_BIST_MODE_2 = 7
 };
 
+/**
+ * struct tcpc_config - Port configuration
+ * @src_pdo:   PDO parameters sent to port partner as response to
+ * PD_CTRL_GET_SOURCE_CAP message
+ * @nr_src_pdo:Number of entries in @src_pdo
+ * @snk_pdo:   PDO parameters sent to partner as response to
+ * PD_CTRL_GET_SINK_CAP message
+ * @nr_snk_pdo:Number of entries in @snk_pdo
+ * @max_snk_mv:Maximum acceptable sink voltage in mV
+ * @max_snk_ma:Maximum sink current in mA
+ * @max_snk_mw:Maximum required sink power in mW
+ * @operating_snk_mw:
+ * Required operating sink power in mW
+ * @type:  Port type (TYPEC_PORT_DFP, TYPEC_PORT_UFP, or
+ * TYPEC_PORT_DRP)
+ * @default_role:
+ * Default port role (TYPEC_SINK or TYPEC_SOURCE).
+ * Set to TYPEC_NO_PREFERRED_ROLE if no default role.
+ * @try_role_hw:True if try.{Src,Snk} is implemented in hardware
+ * @alt_modes: List of supported alternate modes
+ */
 struct tcpc_config {
const u32 *src_pdo;
unsigned int nr_src_pdo;
@@ -79,7 +100,6 @@ struct tcpc_config {
 enum tcpc_usb_switch {
TCPC_USB_SWITCH_CONNECT,
TCPC_USB_SWITCH_DISCONNECT,
-   TCPC_USB_SWITCH_RESTORE,/* TODO FIXME */
 };
 
 /* Mux state attributes */
@@ -104,17 +124,40 @@ struct tcpc_mux_dev {
void *priv_data;
 };
 
+/**
+ * struct tcpc_dev - Port configuration and callback functions
+ * @config:Pointer to port configuration
+ * @get_vbus:  Called to read current VBUS state
+ * @get_current_limit:
+ * Optional; called by the tcpm core when configured as a snk
+ * and cc=Rp-def. This allows the tcpm to provide a fallback
+ * current-limit detection method for the cc=Rp-def case.
+ * For example, some tcpcs may include BC1.2 charger detection
+ * and use that in this case.
+ * @set_cc:Called to set value of CC pins
+ * @get_cc:Called to read current CC pin values
+ * @set_polarity:
+ * Called to set polarity
+ * @set_vconn: Called to enable or disable VCONN
+ * @set_vbus:  Called to enable or disable VBUS
+ * @set_current_limit:
+ * Optional; called to set current limit as negotiated
+ * with partner.
+ * @set_pd_rx: Called to enable or disable reception of PD messages
+ * @set_roles: Called to set power and data roles
+ * @start_drp_toggling:
+ * Optional; if supported by hardware, called to start DRP
+ * toggling. DRP toggling is stopped automatically if
+ * a connection is established.
+ * @try_role:  Optional; called to set a preferred role
+ * @pd_transmit:Called to transmit PD message
+ * @mux:   Pointer to multiplexer data
+ */
 struct tcpc_dev {
const struct tcpc_config *config;
 
int (*init)(struct tcpc_dev *dev);
int (*get_vbus)(struct tcpc_dev *dev);
-   /*
-* This optional callback gets called by the tcpm core when configured
-* as a snk and cc=Rp-def. This allows the tcpm to provide a fallback
-* current-limit detection method for the cc=Rp-def case. E.g. some
-* tcpcs may include BC1.2 charger detection and use that in this case.
-*/
int (*get_current_limit)(struct tcpc_dev *dev);
int (*set_cc)(struct tcpc_dev *dev, enum typec_cc_status cc);
int (*get_cc)(struct tcpc_dev *dev, enum typec_cc_status *cc1,
-- 
2.7.4



[PATCH v3 5/5] usb: typec: fusb302: Move out of staging

2017-09-11 Thread Guenter Roeck
The driver is in good enough shape to be moved out of staging.
Do it.

Signed-off-by: Guenter Roeck 
---
v2: Use format-patch -M
v3: No change

 drivers/staging/typec/Kconfig|  2 --
 drivers/staging/typec/Makefile   |  1 -
 drivers/staging/typec/fusb302/TODO   | 10 --
 drivers/usb/typec/Kconfig|  6 ++
 drivers/usb/typec/Makefile   |  1 +
 drivers/{staging => usb}/typec/fusb302/Kconfig   |  0
 drivers/{staging => usb}/typec/fusb302/Makefile  |  0
 drivers/{staging => usb}/typec/fusb302/fusb302.c |  0
 drivers/{staging => usb}/typec/fusb302/fusb302_reg.h |  0
 9 files changed, 7 insertions(+), 13 deletions(-)
 delete mode 100644 drivers/staging/typec/fusb302/TODO
 rename drivers/{staging => usb}/typec/fusb302/Kconfig (100%)
 rename drivers/{staging => usb}/typec/fusb302/Makefile (100%)
 rename drivers/{staging => usb}/typec/fusb302/fusb302.c (100%)
 rename drivers/{staging => usb}/typec/fusb302/fusb302_reg.h (100%)

diff --git a/drivers/staging/typec/Kconfig b/drivers/staging/typec/Kconfig
index 31fad23c2553..5359f556d203 100644
--- a/drivers/staging/typec/Kconfig
+++ b/drivers/staging/typec/Kconfig
@@ -9,8 +9,6 @@ config TYPEC_TCPCI
help
  Type-C Port Controller driver for TCPCI-compliant controller.
 
-source "drivers/staging/typec/fusb302/Kconfig"
-
 endif
 
 endmenu
diff --git a/drivers/staging/typec/Makefile b/drivers/staging/typec/Makefile
index e1df3f0fde10..53d649abcb53 100644
--- a/drivers/staging/typec/Makefile
+++ b/drivers/staging/typec/Makefile
@@ -1,2 +1 @@
 obj-$(CONFIG_TYPEC_TCPCI)  += tcpci.o
-obj-y  += fusb302/
diff --git a/drivers/staging/typec/fusb302/TODO 
b/drivers/staging/typec/fusb302/TODO
deleted file mode 100644
index 19b466eb585d..
--- a/drivers/staging/typec/fusb302/TODO
+++ /dev/null
@@ -1,10 +0,0 @@
-fusb302:
-- Find a better logging scheme, at least not having the same debugging/logging
-  code replicated here and in tcpm
-- Find a non-hacky way to coordinate between PM and I2C access
-- Documentation? The FUSB302 datasheet provides information on the chip to help
-  understand the code. But it may still be helpful to have a documentation.
-- We may want to replace the  "fcs,max-snk-microvolt", "fcs,max-snk-microamp",
-  "fcs,max-snk-microwatt" and "fcs,operating-snk-microwatt" device(tree)
-  properties with properties which are part of a generic type-c controller
-  devicetree binding.
diff --git a/drivers/usb/typec/Kconfig b/drivers/usb/typec/Kconfig
index 888605860091..819c0ed2b200 100644
--- a/drivers/usb/typec/Kconfig
+++ b/drivers/usb/typec/Kconfig
@@ -12,6 +12,12 @@ config TYPEC_TCPM
  The Type-C Port Controller Manager provides a USB PD and USB Type-C
  state machine for use with Type-C Port Controllers.
 
+if TYPEC_TCPM
+
+source "drivers/usb/typec/fusb302/Kconfig"
+
+endif
+
 config TYPEC_WCOVE
tristate "Intel WhiskeyCove PMIC USB Type-C PHY driver"
depends on ACPI
diff --git a/drivers/usb/typec/Makefile b/drivers/usb/typec/Makefile
index eb883984724b..b77688ce1f16 100644
--- a/drivers/usb/typec/Makefile
+++ b/drivers/usb/typec/Makefile
@@ -1,4 +1,5 @@
 obj-$(CONFIG_TYPEC)+= typec.o
 obj-$(CONFIG_TYPEC_TCPM)   += tcpm.o
+obj-y  += fusb302/
 obj-$(CONFIG_TYPEC_WCOVE)  += typec_wcove.o
 obj-$(CONFIG_TYPEC_UCSI)   += ucsi/
diff --git a/drivers/staging/typec/fusb302/Kconfig 
b/drivers/usb/typec/fusb302/Kconfig
similarity index 100%
rename from drivers/staging/typec/fusb302/Kconfig
rename to drivers/usb/typec/fusb302/Kconfig
diff --git a/drivers/staging/typec/fusb302/Makefile 
b/drivers/usb/typec/fusb302/Makefile
similarity index 100%
rename from drivers/staging/typec/fusb302/Makefile
rename to drivers/usb/typec/fusb302/Makefile
diff --git a/drivers/staging/typec/fusb302/fusb302.c 
b/drivers/usb/typec/fusb302/fusb302.c
similarity index 100%
rename from drivers/staging/typec/fusb302/fusb302.c
rename to drivers/usb/typec/fusb302/fusb302.c
diff --git a/drivers/staging/typec/fusb302/fusb302_reg.h 
b/drivers/usb/typec/fusb302/fusb302_reg.h
similarity index 100%
rename from drivers/staging/typec/fusb302/fusb302_reg.h
rename to drivers/usb/typec/fusb302/fusb302_reg.h
-- 
2.7.4



[PATCH v3 5/5] usb: typec: fusb302: Move out of staging

2017-09-11 Thread Guenter Roeck
The driver is in good enough shape to be moved out of staging.
Do it.

Signed-off-by: Guenter Roeck 
---
v2: Use format-patch -M
v3: No change

 drivers/staging/typec/Kconfig|  2 --
 drivers/staging/typec/Makefile   |  1 -
 drivers/staging/typec/fusb302/TODO   | 10 --
 drivers/usb/typec/Kconfig|  6 ++
 drivers/usb/typec/Makefile   |  1 +
 drivers/{staging => usb}/typec/fusb302/Kconfig   |  0
 drivers/{staging => usb}/typec/fusb302/Makefile  |  0
 drivers/{staging => usb}/typec/fusb302/fusb302.c |  0
 drivers/{staging => usb}/typec/fusb302/fusb302_reg.h |  0
 9 files changed, 7 insertions(+), 13 deletions(-)
 delete mode 100644 drivers/staging/typec/fusb302/TODO
 rename drivers/{staging => usb}/typec/fusb302/Kconfig (100%)
 rename drivers/{staging => usb}/typec/fusb302/Makefile (100%)
 rename drivers/{staging => usb}/typec/fusb302/fusb302.c (100%)
 rename drivers/{staging => usb}/typec/fusb302/fusb302_reg.h (100%)

diff --git a/drivers/staging/typec/Kconfig b/drivers/staging/typec/Kconfig
index 31fad23c2553..5359f556d203 100644
--- a/drivers/staging/typec/Kconfig
+++ b/drivers/staging/typec/Kconfig
@@ -9,8 +9,6 @@ config TYPEC_TCPCI
help
  Type-C Port Controller driver for TCPCI-compliant controller.
 
-source "drivers/staging/typec/fusb302/Kconfig"
-
 endif
 
 endmenu
diff --git a/drivers/staging/typec/Makefile b/drivers/staging/typec/Makefile
index e1df3f0fde10..53d649abcb53 100644
--- a/drivers/staging/typec/Makefile
+++ b/drivers/staging/typec/Makefile
@@ -1,2 +1 @@
 obj-$(CONFIG_TYPEC_TCPCI)  += tcpci.o
-obj-y  += fusb302/
diff --git a/drivers/staging/typec/fusb302/TODO 
b/drivers/staging/typec/fusb302/TODO
deleted file mode 100644
index 19b466eb585d..
--- a/drivers/staging/typec/fusb302/TODO
+++ /dev/null
@@ -1,10 +0,0 @@
-fusb302:
-- Find a better logging scheme, at least not having the same debugging/logging
-  code replicated here and in tcpm
-- Find a non-hacky way to coordinate between PM and I2C access
-- Documentation? The FUSB302 datasheet provides information on the chip to help
-  understand the code. But it may still be helpful to have a documentation.
-- We may want to replace the  "fcs,max-snk-microvolt", "fcs,max-snk-microamp",
-  "fcs,max-snk-microwatt" and "fcs,operating-snk-microwatt" device(tree)
-  properties with properties which are part of a generic type-c controller
-  devicetree binding.
diff --git a/drivers/usb/typec/Kconfig b/drivers/usb/typec/Kconfig
index 888605860091..819c0ed2b200 100644
--- a/drivers/usb/typec/Kconfig
+++ b/drivers/usb/typec/Kconfig
@@ -12,6 +12,12 @@ config TYPEC_TCPM
  The Type-C Port Controller Manager provides a USB PD and USB Type-C
  state machine for use with Type-C Port Controllers.
 
+if TYPEC_TCPM
+
+source "drivers/usb/typec/fusb302/Kconfig"
+
+endif
+
 config TYPEC_WCOVE
tristate "Intel WhiskeyCove PMIC USB Type-C PHY driver"
depends on ACPI
diff --git a/drivers/usb/typec/Makefile b/drivers/usb/typec/Makefile
index eb883984724b..b77688ce1f16 100644
--- a/drivers/usb/typec/Makefile
+++ b/drivers/usb/typec/Makefile
@@ -1,4 +1,5 @@
 obj-$(CONFIG_TYPEC)+= typec.o
 obj-$(CONFIG_TYPEC_TCPM)   += tcpm.o
+obj-y  += fusb302/
 obj-$(CONFIG_TYPEC_WCOVE)  += typec_wcove.o
 obj-$(CONFIG_TYPEC_UCSI)   += ucsi/
diff --git a/drivers/staging/typec/fusb302/Kconfig 
b/drivers/usb/typec/fusb302/Kconfig
similarity index 100%
rename from drivers/staging/typec/fusb302/Kconfig
rename to drivers/usb/typec/fusb302/Kconfig
diff --git a/drivers/staging/typec/fusb302/Makefile 
b/drivers/usb/typec/fusb302/Makefile
similarity index 100%
rename from drivers/staging/typec/fusb302/Makefile
rename to drivers/usb/typec/fusb302/Makefile
diff --git a/drivers/staging/typec/fusb302/fusb302.c 
b/drivers/usb/typec/fusb302/fusb302.c
similarity index 100%
rename from drivers/staging/typec/fusb302/fusb302.c
rename to drivers/usb/typec/fusb302/fusb302.c
diff --git a/drivers/staging/typec/fusb302/fusb302_reg.h 
b/drivers/usb/typec/fusb302/fusb302_reg.h
similarity index 100%
rename from drivers/staging/typec/fusb302/fusb302_reg.h
rename to drivers/usb/typec/fusb302/fusb302_reg.h
-- 
2.7.4



[PATCH v3 4/5] typec: tcpm: Move out of staging

2017-09-11 Thread Guenter Roeck
Move tcpm (USB Type-C Port Manager) out of staging.

Signed-off-by: Guenter Roeck 
---
v2: Use format-patch -M
v3: No change

 drivers/staging/typec/Kconfig |  8 
 drivers/staging/typec/Makefile|  1 -
 drivers/staging/typec/TODO| 10 --
 drivers/staging/typec/fusb302/fusb302.c   |  4 ++--
 drivers/staging/typec/tcpci.c |  4 ++--
 drivers/usb/typec/Kconfig |  8 
 drivers/usb/typec/Makefile|  1 +
 drivers/{staging => usb}/typec/tcpm.c |  9 -
 {drivers/staging/typec => include/linux/usb}/pd.h |  0
 {drivers/staging/typec => include/linux/usb}/pd_bdo.h |  0
 {drivers/staging/typec => include/linux/usb}/pd_vdo.h |  0
 {drivers/staging/typec => include/linux/usb}/tcpm.h   |  0
 12 files changed, 17 insertions(+), 28 deletions(-)
 rename drivers/{staging => usb}/typec/tcpm.c (99%)
 rename {drivers/staging/typec => include/linux/usb}/pd.h (100%)
 rename {drivers/staging/typec => include/linux/usb}/pd_bdo.h (100%)
 rename {drivers/staging/typec => include/linux/usb}/pd_vdo.h (100%)
 rename {drivers/staging/typec => include/linux/usb}/tcpm.h (100%)

diff --git a/drivers/staging/typec/Kconfig b/drivers/staging/typec/Kconfig
index 37a0781b0d0c..31fad23c2553 100644
--- a/drivers/staging/typec/Kconfig
+++ b/drivers/staging/typec/Kconfig
@@ -1,13 +1,5 @@
 menu "USB Power Delivery and Type-C drivers"
 
-config TYPEC_TCPM
-   tristate "USB Type-C Port Controller Manager"
-   depends on USB
-   select TYPEC
-   help
- The Type-C Port Controller Manager provides a USB PD and USB Type-C
- state machine for use with Type-C Port Controllers.
-
 if TYPEC_TCPM
 
 config TYPEC_TCPCI
diff --git a/drivers/staging/typec/Makefile b/drivers/staging/typec/Makefile
index 30a7e29cbc9e..e1df3f0fde10 100644
--- a/drivers/staging/typec/Makefile
+++ b/drivers/staging/typec/Makefile
@@ -1,3 +1,2 @@
-obj-$(CONFIG_TYPEC_TCPM)   += tcpm.o
 obj-$(CONFIG_TYPEC_TCPCI)  += tcpci.o
 obj-y  += fusb302/
diff --git a/drivers/staging/typec/TODO b/drivers/staging/typec/TODO
index bc1f97a2d1bf..53fe2f726c88 100644
--- a/drivers/staging/typec/TODO
+++ b/drivers/staging/typec/TODO
@@ -1,13 +1,3 @@
-tcpm:
-- Add documentation (at the very least for the API to low level drivers)
-- Split PD code into separate file
-- Check if it makes sense to use tracepoints instead of debugfs for debug logs
-- Implement Alternate Mode handling
-- Address "#if 0" code if not addressed with the above
-- Validate all comments marked with "XXX"; either address or remove comments
-- Add support for USB PD 3.0. While not mandatory, at least fast role swap
-  as well as authentication support would be very desirable.
-
 tcpci:
 - Test with real hardware
 
diff --git a/drivers/staging/typec/fusb302/fusb302.c 
b/drivers/staging/typec/fusb302/fusb302.c
index fc6a3cf74eb3..e790b67d4953 100644
--- a/drivers/staging/typec/fusb302/fusb302.c
+++ b/drivers/staging/typec/fusb302/fusb302.c
@@ -37,11 +37,11 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 
 #include "fusb302_reg.h"
-#include "../tcpm.h"
-#include "../pd.h"
 
 /*
  * When the device is SNK, BC_LVL interrupt is used to monitor cc pins
diff --git a/drivers/staging/typec/tcpci.c b/drivers/staging/typec/tcpci.c
index df72d8b01e73..4636804ea1a4 100644
--- a/drivers/staging/typec/tcpci.c
+++ b/drivers/staging/typec/tcpci.c
@@ -20,11 +20,11 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 
-#include "pd.h"
 #include "tcpci.h"
-#include "tcpm.h"
 
 #define PD_RETRY_COUNT 3
 
diff --git a/drivers/usb/typec/Kconfig b/drivers/usb/typec/Kconfig
index bc1b7745f1d4..888605860091 100644
--- a/drivers/usb/typec/Kconfig
+++ b/drivers/usb/typec/Kconfig
@@ -4,6 +4,14 @@ menu "USB Power Delivery and Type-C drivers"
 config TYPEC
tristate
 
+config TYPEC_TCPM
+   tristate "USB Type-C Port Controller Manager"
+   depends on USB
+   select TYPEC
+   help
+ The Type-C Port Controller Manager provides a USB PD and USB Type-C
+ state machine for use with Type-C Port Controllers.
+
 config TYPEC_WCOVE
tristate "Intel WhiskeyCove PMIC USB Type-C PHY driver"
depends on ACPI
diff --git a/drivers/usb/typec/Makefile b/drivers/usb/typec/Makefile
index bc214f15f1b5..eb883984724b 100644
--- a/drivers/usb/typec/Makefile
+++ b/drivers/usb/typec/Makefile
@@ -1,3 +1,4 @@
 obj-$(CONFIG_TYPEC)+= typec.o
+obj-$(CONFIG_TYPEC_TCPM)   += tcpm.o
 obj-$(CONFIG_TYPEC_WCOVE)  += typec_wcove.o
 obj-$(CONFIG_TYPEC_UCSI)   += ucsi/
diff --git a/drivers/staging/typec/tcpm.c b/drivers/usb/typec/tcpm.c
similarity index 99%
rename from drivers/staging/typec/tcpm.c
rename to drivers/usb/typec/tcpm.c
index cb25ec8334b0..f557c479fdc2 100644
--- 

[PATCH v3 4/5] typec: tcpm: Move out of staging

2017-09-11 Thread Guenter Roeck
Move tcpm (USB Type-C Port Manager) out of staging.

Signed-off-by: Guenter Roeck 
---
v2: Use format-patch -M
v3: No change

 drivers/staging/typec/Kconfig |  8 
 drivers/staging/typec/Makefile|  1 -
 drivers/staging/typec/TODO| 10 --
 drivers/staging/typec/fusb302/fusb302.c   |  4 ++--
 drivers/staging/typec/tcpci.c |  4 ++--
 drivers/usb/typec/Kconfig |  8 
 drivers/usb/typec/Makefile|  1 +
 drivers/{staging => usb}/typec/tcpm.c |  9 -
 {drivers/staging/typec => include/linux/usb}/pd.h |  0
 {drivers/staging/typec => include/linux/usb}/pd_bdo.h |  0
 {drivers/staging/typec => include/linux/usb}/pd_vdo.h |  0
 {drivers/staging/typec => include/linux/usb}/tcpm.h   |  0
 12 files changed, 17 insertions(+), 28 deletions(-)
 rename drivers/{staging => usb}/typec/tcpm.c (99%)
 rename {drivers/staging/typec => include/linux/usb}/pd.h (100%)
 rename {drivers/staging/typec => include/linux/usb}/pd_bdo.h (100%)
 rename {drivers/staging/typec => include/linux/usb}/pd_vdo.h (100%)
 rename {drivers/staging/typec => include/linux/usb}/tcpm.h (100%)

diff --git a/drivers/staging/typec/Kconfig b/drivers/staging/typec/Kconfig
index 37a0781b0d0c..31fad23c2553 100644
--- a/drivers/staging/typec/Kconfig
+++ b/drivers/staging/typec/Kconfig
@@ -1,13 +1,5 @@
 menu "USB Power Delivery and Type-C drivers"
 
-config TYPEC_TCPM
-   tristate "USB Type-C Port Controller Manager"
-   depends on USB
-   select TYPEC
-   help
- The Type-C Port Controller Manager provides a USB PD and USB Type-C
- state machine for use with Type-C Port Controllers.
-
 if TYPEC_TCPM
 
 config TYPEC_TCPCI
diff --git a/drivers/staging/typec/Makefile b/drivers/staging/typec/Makefile
index 30a7e29cbc9e..e1df3f0fde10 100644
--- a/drivers/staging/typec/Makefile
+++ b/drivers/staging/typec/Makefile
@@ -1,3 +1,2 @@
-obj-$(CONFIG_TYPEC_TCPM)   += tcpm.o
 obj-$(CONFIG_TYPEC_TCPCI)  += tcpci.o
 obj-y  += fusb302/
diff --git a/drivers/staging/typec/TODO b/drivers/staging/typec/TODO
index bc1f97a2d1bf..53fe2f726c88 100644
--- a/drivers/staging/typec/TODO
+++ b/drivers/staging/typec/TODO
@@ -1,13 +1,3 @@
-tcpm:
-- Add documentation (at the very least for the API to low level drivers)
-- Split PD code into separate file
-- Check if it makes sense to use tracepoints instead of debugfs for debug logs
-- Implement Alternate Mode handling
-- Address "#if 0" code if not addressed with the above
-- Validate all comments marked with "XXX"; either address or remove comments
-- Add support for USB PD 3.0. While not mandatory, at least fast role swap
-  as well as authentication support would be very desirable.
-
 tcpci:
 - Test with real hardware
 
diff --git a/drivers/staging/typec/fusb302/fusb302.c 
b/drivers/staging/typec/fusb302/fusb302.c
index fc6a3cf74eb3..e790b67d4953 100644
--- a/drivers/staging/typec/fusb302/fusb302.c
+++ b/drivers/staging/typec/fusb302/fusb302.c
@@ -37,11 +37,11 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 
 #include "fusb302_reg.h"
-#include "../tcpm.h"
-#include "../pd.h"
 
 /*
  * When the device is SNK, BC_LVL interrupt is used to monitor cc pins
diff --git a/drivers/staging/typec/tcpci.c b/drivers/staging/typec/tcpci.c
index df72d8b01e73..4636804ea1a4 100644
--- a/drivers/staging/typec/tcpci.c
+++ b/drivers/staging/typec/tcpci.c
@@ -20,11 +20,11 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 
-#include "pd.h"
 #include "tcpci.h"
-#include "tcpm.h"
 
 #define PD_RETRY_COUNT 3
 
diff --git a/drivers/usb/typec/Kconfig b/drivers/usb/typec/Kconfig
index bc1b7745f1d4..888605860091 100644
--- a/drivers/usb/typec/Kconfig
+++ b/drivers/usb/typec/Kconfig
@@ -4,6 +4,14 @@ menu "USB Power Delivery and Type-C drivers"
 config TYPEC
tristate
 
+config TYPEC_TCPM
+   tristate "USB Type-C Port Controller Manager"
+   depends on USB
+   select TYPEC
+   help
+ The Type-C Port Controller Manager provides a USB PD and USB Type-C
+ state machine for use with Type-C Port Controllers.
+
 config TYPEC_WCOVE
tristate "Intel WhiskeyCove PMIC USB Type-C PHY driver"
depends on ACPI
diff --git a/drivers/usb/typec/Makefile b/drivers/usb/typec/Makefile
index bc214f15f1b5..eb883984724b 100644
--- a/drivers/usb/typec/Makefile
+++ b/drivers/usb/typec/Makefile
@@ -1,3 +1,4 @@
 obj-$(CONFIG_TYPEC)+= typec.o
+obj-$(CONFIG_TYPEC_TCPM)   += tcpm.o
 obj-$(CONFIG_TYPEC_WCOVE)  += typec_wcove.o
 obj-$(CONFIG_TYPEC_UCSI)   += ucsi/
diff --git a/drivers/staging/typec/tcpm.c b/drivers/usb/typec/tcpm.c
similarity index 99%
rename from drivers/staging/typec/tcpm.c
rename to drivers/usb/typec/tcpm.c
index cb25ec8334b0..f557c479fdc2 100644
--- a/drivers/staging/typec/tcpm.c
+++ 

[PATCH v3 1/5] staging: typec: tcpm: Drop commented out code

2017-09-11 Thread Guenter Roeck
Commented out code can be added as needed. Drop it.
Also drop TODO and an obsolete XXX comment.

Signed-off-by: Guenter Roeck 
---
v2, v3: No change

 drivers/staging/typec/tcpm.c | 37 +
 1 file changed, 1 insertion(+), 36 deletions(-)

diff --git a/drivers/staging/typec/tcpm.c b/drivers/staging/typec/tcpm.c
index 8af62e74d54c..cb25ec8334b0 100644
--- a/drivers/staging/typec/tcpm.c
+++ b/drivers/staging/typec/tcpm.c
@@ -908,27 +908,6 @@ static void svdm_consume_identity(struct tcpm_port *port, 
const __le32 *payload,
 
memset(>mode_data, 0, sizeof(port->mode_data));
 
-#if 0 /* Not really a match */
-   switch (PD_IDH_PTYPE(vdo)) {
-   case IDH_PTYPE_UNDEF:
-   port->partner.type = TYPEC_PARTNER_NONE; /* no longer exists */
-   break;
-   case IDH_PTYPE_HUB:
-   break;
-   case IDH_PTYPE_PERIPH:
-   break;
-   case IDH_PTYPE_PCABLE:
-   break;
-   case IDH_PTYPE_ACABLE:
-   break;
-   case IDH_PTYPE_AMA:
-   port->partner.type = TYPEC_PARTNER_ALTMODE;
-   break;
-   default:
-   break;
-   }
-#endif
-
port->partner_ident.id_header = vdo;
port->partner_ident.cert_stat = le32_to_cpu(payload[VDO_INDEX_CSTAT]);
port->partner_ident.product = product;
@@ -1103,11 +1082,7 @@ static int tcpm_pd_svdm(struct tcpm_port *port, const 
__le32 *payload, int cnt,
response[0] = VDO(svid, 1, CMD_DISCOVER_MODES);
rlen = 1;
} else {
-#if 0
-   response[0] = pd_dfp_enter_mode(port, 0, 0);
-   if (response[0])
-   rlen = 1;
-#endif
+   /* enter alternate mode if/when implemented */
}
break;
case CMD_ENTER_MODE:
@@ -1145,10 +1120,6 @@ static void tcpm_handle_vdm_request(struct tcpm_port 
*port,
 
if (PD_VDO_SVDM(p0))
rlen = tcpm_pd_svdm(port, payload, cnt, response);
-#if 0
-   else
-   rlen = tcpm_pd_custom_vdm(port, cnt, payload, response);
-#endif
 
if (rlen > 0) {
tcpm_queue_vdm(port, response[0], [1], rlen - 1);
@@ -2442,7 +2413,6 @@ static void run_state_machine(struct tcpm_port *port)
tcpm_set_state(port, SNK_STARTUP, 0);
break;
case SNK_STARTUP:
-   /* XXX: callback into infrastructure */
opmode =  tcpm_get_pwr_opmode(port->polarity ?
  port->cc2 : port->cc1);
typec_set_pwr_opmode(port->typec_port, opmode);
@@ -3589,11 +3559,6 @@ struct tcpm_port *tcpm_register_port(struct device *dev, 
struct tcpc_dev *tcpc)
 
port->partner_desc.identity = >partner_ident;
port->port_type = tcpc->config->type;
-   /*
-* TODO:
-*  - alt_modes, set_alt_mode
-*  - {debug,audio}_accessory
-*/
 
port->typec_port = typec_register_port(port->dev, >typec_caps);
if (!port->typec_port) {
-- 
2.7.4



[PATCH v3 1/5] staging: typec: tcpm: Drop commented out code

2017-09-11 Thread Guenter Roeck
Commented out code can be added as needed. Drop it.
Also drop TODO and an obsolete XXX comment.

Signed-off-by: Guenter Roeck 
---
v2, v3: No change

 drivers/staging/typec/tcpm.c | 37 +
 1 file changed, 1 insertion(+), 36 deletions(-)

diff --git a/drivers/staging/typec/tcpm.c b/drivers/staging/typec/tcpm.c
index 8af62e74d54c..cb25ec8334b0 100644
--- a/drivers/staging/typec/tcpm.c
+++ b/drivers/staging/typec/tcpm.c
@@ -908,27 +908,6 @@ static void svdm_consume_identity(struct tcpm_port *port, 
const __le32 *payload,
 
memset(>mode_data, 0, sizeof(port->mode_data));
 
-#if 0 /* Not really a match */
-   switch (PD_IDH_PTYPE(vdo)) {
-   case IDH_PTYPE_UNDEF:
-   port->partner.type = TYPEC_PARTNER_NONE; /* no longer exists */
-   break;
-   case IDH_PTYPE_HUB:
-   break;
-   case IDH_PTYPE_PERIPH:
-   break;
-   case IDH_PTYPE_PCABLE:
-   break;
-   case IDH_PTYPE_ACABLE:
-   break;
-   case IDH_PTYPE_AMA:
-   port->partner.type = TYPEC_PARTNER_ALTMODE;
-   break;
-   default:
-   break;
-   }
-#endif
-
port->partner_ident.id_header = vdo;
port->partner_ident.cert_stat = le32_to_cpu(payload[VDO_INDEX_CSTAT]);
port->partner_ident.product = product;
@@ -1103,11 +1082,7 @@ static int tcpm_pd_svdm(struct tcpm_port *port, const 
__le32 *payload, int cnt,
response[0] = VDO(svid, 1, CMD_DISCOVER_MODES);
rlen = 1;
} else {
-#if 0
-   response[0] = pd_dfp_enter_mode(port, 0, 0);
-   if (response[0])
-   rlen = 1;
-#endif
+   /* enter alternate mode if/when implemented */
}
break;
case CMD_ENTER_MODE:
@@ -1145,10 +1120,6 @@ static void tcpm_handle_vdm_request(struct tcpm_port 
*port,
 
if (PD_VDO_SVDM(p0))
rlen = tcpm_pd_svdm(port, payload, cnt, response);
-#if 0
-   else
-   rlen = tcpm_pd_custom_vdm(port, cnt, payload, response);
-#endif
 
if (rlen > 0) {
tcpm_queue_vdm(port, response[0], [1], rlen - 1);
@@ -2442,7 +2413,6 @@ static void run_state_machine(struct tcpm_port *port)
tcpm_set_state(port, SNK_STARTUP, 0);
break;
case SNK_STARTUP:
-   /* XXX: callback into infrastructure */
opmode =  tcpm_get_pwr_opmode(port->polarity ?
  port->cc2 : port->cc1);
typec_set_pwr_opmode(port->typec_port, opmode);
@@ -3589,11 +3559,6 @@ struct tcpm_port *tcpm_register_port(struct device *dev, 
struct tcpc_dev *tcpc)
 
port->partner_desc.identity = >partner_ident;
port->port_type = tcpc->config->type;
-   /*
-* TODO:
-*  - alt_modes, set_alt_mode
-*  - {debug,audio}_accessory
-*/
 
port->typec_port = typec_register_port(port->dev, >typec_caps);
if (!port->typec_port) {
-- 
2.7.4



[PATCH v3 3/5] staging: typec: pd: Document struct pd_message

2017-09-11 Thread Guenter Roeck
struct pd_message is the format of a PD message as seen on the wire.

Signed-off-by: Guenter Roeck 
---
v2: No change
v3: Fix document tag

 drivers/staging/typec/pd.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/staging/typec/pd.h b/drivers/staging/typec/pd.h
index 30b32ad72acd..42a10883a2cb 100644
--- a/drivers/staging/typec/pd.h
+++ b/drivers/staging/typec/pd.h
@@ -104,6 +104,11 @@ static inline unsigned int pd_header_msgid_le(__le16 
header)
 
 #define PD_MAX_PAYLOAD 7
 
+/**
+ * struct pd_message - PD message as seen on wire
+ * @header:PD message header
+ * @payload:   PD message payload
+ */
 struct pd_message {
__le16 header;
__le32 payload[PD_MAX_PAYLOAD];
-- 
2.7.4



[PATCH v3 3/5] staging: typec: pd: Document struct pd_message

2017-09-11 Thread Guenter Roeck
struct pd_message is the format of a PD message as seen on the wire.

Signed-off-by: Guenter Roeck 
---
v2: No change
v3: Fix document tag

 drivers/staging/typec/pd.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/staging/typec/pd.h b/drivers/staging/typec/pd.h
index 30b32ad72acd..42a10883a2cb 100644
--- a/drivers/staging/typec/pd.h
+++ b/drivers/staging/typec/pd.h
@@ -104,6 +104,11 @@ static inline unsigned int pd_header_msgid_le(__le16 
header)
 
 #define PD_MAX_PAYLOAD 7
 
+/**
+ * struct pd_message - PD message as seen on wire
+ * @header:PD message header
+ * @payload:   PD message payload
+ */
 struct pd_message {
__le16 header;
__le32 payload[PD_MAX_PAYLOAD];
-- 
2.7.4



Re: xtensa compiler error triggered by 'locking/lockdep: Implement the 'crossrelease' feature'

2017-09-11 Thread Max Filippov
On Sun, Sep 10, 2017 at 6:58 PM, Max Filippov  wrote:
> On Sun, Sep 10, 2017 at 11:31 AM, Guenter Roeck  wrote:
>> xtensa:allmodconfig fails to build in mainline with compiler errors
>> as follows.
>>
>> drivers/staging/rtl8723bs/core/rtw_ap.c: In function ‘expire_timeout_chk’:
>> drivers/staging/rtl8723bs/core/rtw_ap.c:442:1: internal compiler error:
>> in change_address_1, at emit-rtl.c:2126
>>
>> drivers/staging/rtl8188eu/core/rtw_ap.c: In function ‘expire_timeout_chk’:
>> drivers/staging/rtl8188eu/core/rtw_ap.c:445:1: internal compiler error:
>> in change_address_1, at emit-rtl.c:2150
>>
>> I tried gcc 6.3, 6.4, and 7.2; they all have the same problem.
>>
>> Bisect points to commit b09be676e0f ("locking/lockdep: Implement the
>> 'crossrelease' feature").
>>
>> The compile error is still seen if I disable CONFIG_LOCKDEP_CROSSRELEASE.
>> The image builds fine if I disable both CONFIG_RTL8723BS and CONFIG_R8188EU.
>
> Thanks for the report. I'll look at the compiler.

There was a bug in the xtensa gcc backend, now fixed. See
 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82181

-- 
Thanks.
-- Max


Re: xtensa compiler error triggered by 'locking/lockdep: Implement the 'crossrelease' feature'

2017-09-11 Thread Max Filippov
On Sun, Sep 10, 2017 at 6:58 PM, Max Filippov  wrote:
> On Sun, Sep 10, 2017 at 11:31 AM, Guenter Roeck  wrote:
>> xtensa:allmodconfig fails to build in mainline with compiler errors
>> as follows.
>>
>> drivers/staging/rtl8723bs/core/rtw_ap.c: In function ‘expire_timeout_chk’:
>> drivers/staging/rtl8723bs/core/rtw_ap.c:442:1: internal compiler error:
>> in change_address_1, at emit-rtl.c:2126
>>
>> drivers/staging/rtl8188eu/core/rtw_ap.c: In function ‘expire_timeout_chk’:
>> drivers/staging/rtl8188eu/core/rtw_ap.c:445:1: internal compiler error:
>> in change_address_1, at emit-rtl.c:2150
>>
>> I tried gcc 6.3, 6.4, and 7.2; they all have the same problem.
>>
>> Bisect points to commit b09be676e0f ("locking/lockdep: Implement the
>> 'crossrelease' feature").
>>
>> The compile error is still seen if I disable CONFIG_LOCKDEP_CROSSRELEASE.
>> The image builds fine if I disable both CONFIG_RTL8723BS and CONFIG_R8188EU.
>
> Thanks for the report. I'll look at the compiler.

There was a bug in the xtensa gcc backend, now fixed. See
 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82181

-- 
Thanks.
-- Max


[PATCH 2/7] Minor changes in hid-alps.c for support new Alps device(Separate U1 device code)

2017-09-11 Thread Masaki Ota
From: Masaki Ota 
-To support Alps T4 device, separate U1 device code

Signed-off-by: Masaki Ota 
---
 drivers/hid/hid-alps.c | 120 +++--
 1 file changed, 67 insertions(+), 53 deletions(-)

diff --git a/drivers/hid/hid-alps.c b/drivers/hid/hid-alps.c
index 519bfcf9eaf0..c4ea5c6c9be9 100644
--- a/drivers/hid/hid-alps.c
+++ b/drivers/hid/hid-alps.c
@@ -75,6 +75,7 @@
  * @y_max: maximum y coordinate value
  * @btn_cnt: number of buttons
  * @sp_btn_cnt: number of stick buttons
+ * @has_sp: boolean of sp existense
  */
 struct u1_dev {
struct input_dev *input;
@@ -96,6 +97,7 @@ struct u1_dev {
u32 y_max;
u32 btn_cnt;
u32 sp_btn_cnt;
+   u8  has_sp;
 };
 
 static int u1_read_write_register(struct hid_device *hdev, u32 address,
@@ -255,99 +257,130 @@ static int alps_post_resume(struct hid_device *hdev)
 }
 #endif /* CONFIG_PM */
 
-static int alps_input_configured(struct hid_device *hdev, struct hid_input *hi)
+static int u1_init(struct hid_device *hdev, struct u1_dev *pri_data)
 {
-   struct u1_dev *data = hid_get_drvdata(hdev);
-   struct input_dev *input = hi->input, *input2;
int ret;
-   int res_x, res_y, i;
-
-   data->input = input;
-
-   hid_dbg(hdev, "Opening low level driver\n");
-   ret = hid_hw_open(hdev);
-   if (ret)
-   return ret;
-
-   /* Allow incoming hid reports */
-   hid_device_io_start(hdev);
 
/* Device initialization */
ret = u1_read_write_register(hdev, ADDRESS_U1_DEV_CTRL_1,
-   >dev_ctrl, 0, true);
+   _data->dev_ctrl, 0, true);
if (ret < 0) {
dev_err(>dev, "failed U1_DEV_CTRL_1 (%d)\n", ret);
goto exit;
}
 
-   data->dev_ctrl &= ~U1_DISABLE_DEV;
-   data->dev_ctrl |= U1_TP_ABS_MODE;
+   pri_data->dev_ctrl &= ~U1_DISABLE_DEV;
+   pri_data->dev_ctrl |= U1_TP_ABS_MODE;
ret = u1_read_write_register(hdev, ADDRESS_U1_DEV_CTRL_1,
-   NULL, data->dev_ctrl, false);
+   NULL, pri_data->dev_ctrl, false);
if (ret < 0) {
dev_err(>dev, "failed to change TP mode (%d)\n", ret);
goto exit;
}
 
ret = u1_read_write_register(hdev, ADDRESS_U1_NUM_SENS_X,
-   >sen_line_num_x, 0, true);
+   _data->sen_line_num_x, 0, true);
if (ret < 0) {
dev_err(>dev, "failed U1_NUM_SENS_X (%d)\n", ret);
goto exit;
}
 
ret = u1_read_write_register(hdev, ADDRESS_U1_NUM_SENS_Y,
-   >sen_line_num_y, 0, true);
+   _data->sen_line_num_y, 0, true);
if (ret < 0) {
dev_err(>dev, "failed U1_NUM_SENS_Y (%d)\n", ret);
goto exit;
}
 
ret = u1_read_write_register(hdev, ADDRESS_U1_PITCH_SENS_X,
-   >pitch_x, 0, true);
+   _data->pitch_x, 0, true);
if (ret < 0) {
dev_err(>dev, "failed U1_PITCH_SENS_X (%d)\n", ret);
goto exit;
}
 
ret = u1_read_write_register(hdev, ADDRESS_U1_PITCH_SENS_Y,
-   >pitch_y, 0, true);
+   _data->pitch_y, 0, true);
if (ret < 0) {
dev_err(>dev, "failed U1_PITCH_SENS_Y (%d)\n", ret);
goto exit;
}
 
ret = u1_read_write_register(hdev, ADDRESS_U1_RESO_DWN_ABS,
-   >resolution, 0, true);
+   _data->resolution, 0, true);
if (ret < 0) {
dev_err(>dev, "failed U1_RESO_DWN_ABS (%d)\n", ret);
goto exit;
}
+   pri_data->x_active_len_mm =
+   (pri_data->pitch_x * (pri_data->sen_line_num_x - 1)) / 10;
+   pri_data->y_active_len_mm =
+   (pri_data->pitch_y * (pri_data->sen_line_num_y - 1)) / 10;
+
+   pri_data->x_max =
+   (pri_data->resolution << 2) * (pri_data->sen_line_num_x - 1);
+   pri_data->y_max =
+   (pri_data->resolution << 2) * (pri_data->sen_line_num_y - 1);
 
ret = u1_read_write_register(hdev, ADDRESS_U1_PAD_BTN,
-   >btn_info, 0, true);
+   _data->btn_info, 0, true);
if (ret < 0) {
dev_err(>dev, "failed U1_PAD_BTN (%d)\n", ret);
goto exit;
}
 
+   pri_data->has_sp = 0;
/* Check StickPointer device */
ret = u1_read_write_register(hdev, ADDRESS_U1_DEVICE_TYP,
-   >dev_type, 0, true);
+   _data->dev_type, 0, true);
if (ret < 0) {
dev_err(>dev, "failed U1_DEVICE_TYP (%d)\n", ret);
goto exit;
}
 
-   data->x_active_len_mm =
-   (data->pitch_x * (data->sen_line_num_x - 

[PATCH 2/7] Minor changes in hid-alps.c for support new Alps device(Separate U1 device code)

2017-09-11 Thread Masaki Ota
From: Masaki Ota 
-To support Alps T4 device, separate U1 device code

Signed-off-by: Masaki Ota 
---
 drivers/hid/hid-alps.c | 120 +++--
 1 file changed, 67 insertions(+), 53 deletions(-)

diff --git a/drivers/hid/hid-alps.c b/drivers/hid/hid-alps.c
index 519bfcf9eaf0..c4ea5c6c9be9 100644
--- a/drivers/hid/hid-alps.c
+++ b/drivers/hid/hid-alps.c
@@ -75,6 +75,7 @@
  * @y_max: maximum y coordinate value
  * @btn_cnt: number of buttons
  * @sp_btn_cnt: number of stick buttons
+ * @has_sp: boolean of sp existense
  */
 struct u1_dev {
struct input_dev *input;
@@ -96,6 +97,7 @@ struct u1_dev {
u32 y_max;
u32 btn_cnt;
u32 sp_btn_cnt;
+   u8  has_sp;
 };
 
 static int u1_read_write_register(struct hid_device *hdev, u32 address,
@@ -255,99 +257,130 @@ static int alps_post_resume(struct hid_device *hdev)
 }
 #endif /* CONFIG_PM */
 
-static int alps_input_configured(struct hid_device *hdev, struct hid_input *hi)
+static int u1_init(struct hid_device *hdev, struct u1_dev *pri_data)
 {
-   struct u1_dev *data = hid_get_drvdata(hdev);
-   struct input_dev *input = hi->input, *input2;
int ret;
-   int res_x, res_y, i;
-
-   data->input = input;
-
-   hid_dbg(hdev, "Opening low level driver\n");
-   ret = hid_hw_open(hdev);
-   if (ret)
-   return ret;
-
-   /* Allow incoming hid reports */
-   hid_device_io_start(hdev);
 
/* Device initialization */
ret = u1_read_write_register(hdev, ADDRESS_U1_DEV_CTRL_1,
-   >dev_ctrl, 0, true);
+   _data->dev_ctrl, 0, true);
if (ret < 0) {
dev_err(>dev, "failed U1_DEV_CTRL_1 (%d)\n", ret);
goto exit;
}
 
-   data->dev_ctrl &= ~U1_DISABLE_DEV;
-   data->dev_ctrl |= U1_TP_ABS_MODE;
+   pri_data->dev_ctrl &= ~U1_DISABLE_DEV;
+   pri_data->dev_ctrl |= U1_TP_ABS_MODE;
ret = u1_read_write_register(hdev, ADDRESS_U1_DEV_CTRL_1,
-   NULL, data->dev_ctrl, false);
+   NULL, pri_data->dev_ctrl, false);
if (ret < 0) {
dev_err(>dev, "failed to change TP mode (%d)\n", ret);
goto exit;
}
 
ret = u1_read_write_register(hdev, ADDRESS_U1_NUM_SENS_X,
-   >sen_line_num_x, 0, true);
+   _data->sen_line_num_x, 0, true);
if (ret < 0) {
dev_err(>dev, "failed U1_NUM_SENS_X (%d)\n", ret);
goto exit;
}
 
ret = u1_read_write_register(hdev, ADDRESS_U1_NUM_SENS_Y,
-   >sen_line_num_y, 0, true);
+   _data->sen_line_num_y, 0, true);
if (ret < 0) {
dev_err(>dev, "failed U1_NUM_SENS_Y (%d)\n", ret);
goto exit;
}
 
ret = u1_read_write_register(hdev, ADDRESS_U1_PITCH_SENS_X,
-   >pitch_x, 0, true);
+   _data->pitch_x, 0, true);
if (ret < 0) {
dev_err(>dev, "failed U1_PITCH_SENS_X (%d)\n", ret);
goto exit;
}
 
ret = u1_read_write_register(hdev, ADDRESS_U1_PITCH_SENS_Y,
-   >pitch_y, 0, true);
+   _data->pitch_y, 0, true);
if (ret < 0) {
dev_err(>dev, "failed U1_PITCH_SENS_Y (%d)\n", ret);
goto exit;
}
 
ret = u1_read_write_register(hdev, ADDRESS_U1_RESO_DWN_ABS,
-   >resolution, 0, true);
+   _data->resolution, 0, true);
if (ret < 0) {
dev_err(>dev, "failed U1_RESO_DWN_ABS (%d)\n", ret);
goto exit;
}
+   pri_data->x_active_len_mm =
+   (pri_data->pitch_x * (pri_data->sen_line_num_x - 1)) / 10;
+   pri_data->y_active_len_mm =
+   (pri_data->pitch_y * (pri_data->sen_line_num_y - 1)) / 10;
+
+   pri_data->x_max =
+   (pri_data->resolution << 2) * (pri_data->sen_line_num_x - 1);
+   pri_data->y_max =
+   (pri_data->resolution << 2) * (pri_data->sen_line_num_y - 1);
 
ret = u1_read_write_register(hdev, ADDRESS_U1_PAD_BTN,
-   >btn_info, 0, true);
+   _data->btn_info, 0, true);
if (ret < 0) {
dev_err(>dev, "failed U1_PAD_BTN (%d)\n", ret);
goto exit;
}
 
+   pri_data->has_sp = 0;
/* Check StickPointer device */
ret = u1_read_write_register(hdev, ADDRESS_U1_DEVICE_TYP,
-   >dev_type, 0, true);
+   _data->dev_type, 0, true);
if (ret < 0) {
dev_err(>dev, "failed U1_DEVICE_TYP (%d)\n", ret);
goto exit;
}
 
-   data->x_active_len_mm =
-   (data->pitch_x * (data->sen_line_num_x - 1)) / 10;
-   data->y_active_len_mm =
-  

[PATCH 1/7] Minor changes in hid-alps.c for support new Alps device(Delete unnecessary structure)

2017-09-11 Thread Masaki Ota
From: Masaki Ota 
-To support Alps T4 device, clean up the source code
-Delete unnecessary structure

Signed-off-by: Masaki Ota 
---
 drivers/hid/hid-alps.c | 69 +-
 1 file changed, 34 insertions(+), 35 deletions(-)

diff --git a/drivers/hid/hid-alps.c b/drivers/hid/hid-alps.c
index ed9c0ea5b026..519bfcf9eaf0 100644
--- a/drivers/hid/hid-alps.c
+++ b/drivers/hid/hid-alps.c
@@ -259,7 +259,6 @@ static int alps_input_configured(struct hid_device *hdev, 
struct hid_input *hi)
 {
struct u1_dev *data = hid_get_drvdata(hdev);
struct input_dev *input = hi->input, *input2;
-   struct u1_dev devInfo;
int ret;
int res_x, res_y, i;
 
@@ -275,58 +274,58 @@ static int alps_input_configured(struct hid_device *hdev, 
struct hid_input *hi)
 
/* Device initialization */
ret = u1_read_write_register(hdev, ADDRESS_U1_DEV_CTRL_1,
-   _ctrl, 0, true);
+   >dev_ctrl, 0, true);
if (ret < 0) {
dev_err(>dev, "failed U1_DEV_CTRL_1 (%d)\n", ret);
goto exit;
}
 
-   devInfo.dev_ctrl &= ~U1_DISABLE_DEV;
-   devInfo.dev_ctrl |= U1_TP_ABS_MODE;
+   data->dev_ctrl &= ~U1_DISABLE_DEV;
+   data->dev_ctrl |= U1_TP_ABS_MODE;
ret = u1_read_write_register(hdev, ADDRESS_U1_DEV_CTRL_1,
-   NULL, devInfo.dev_ctrl, false);
+   NULL, data->dev_ctrl, false);
if (ret < 0) {
dev_err(>dev, "failed to change TP mode (%d)\n", ret);
goto exit;
}
 
ret = u1_read_write_register(hdev, ADDRESS_U1_NUM_SENS_X,
-   _line_num_x, 0, true);
+   >sen_line_num_x, 0, true);
if (ret < 0) {
dev_err(>dev, "failed U1_NUM_SENS_X (%d)\n", ret);
goto exit;
}
 
ret = u1_read_write_register(hdev, ADDRESS_U1_NUM_SENS_Y,
-   _line_num_y, 0, true);
+   >sen_line_num_y, 0, true);
if (ret < 0) {
dev_err(>dev, "failed U1_NUM_SENS_Y (%d)\n", ret);
goto exit;
}
 
ret = u1_read_write_register(hdev, ADDRESS_U1_PITCH_SENS_X,
-   _x, 0, true);
+   >pitch_x, 0, true);
if (ret < 0) {
dev_err(>dev, "failed U1_PITCH_SENS_X (%d)\n", ret);
goto exit;
}
 
ret = u1_read_write_register(hdev, ADDRESS_U1_PITCH_SENS_Y,
-   _y, 0, true);
+   >pitch_y, 0, true);
if (ret < 0) {
dev_err(>dev, "failed U1_PITCH_SENS_Y (%d)\n", ret);
goto exit;
}
 
ret = u1_read_write_register(hdev, ADDRESS_U1_RESO_DWN_ABS,
-   , 0, true);
+   >resolution, 0, true);
if (ret < 0) {
dev_err(>dev, "failed U1_RESO_DWN_ABS (%d)\n", ret);
goto exit;
}
 
ret = u1_read_write_register(hdev, ADDRESS_U1_PAD_BTN,
-   _info, 0, true);
+   >btn_info, 0, true);
if (ret < 0) {
dev_err(>dev, "failed U1_PAD_BTN (%d)\n", ret);
goto exit;
@@ -334,29 +333,29 @@ static int alps_input_configured(struct hid_device *hdev, 
struct hid_input *hi)
 
/* Check StickPointer device */
ret = u1_read_write_register(hdev, ADDRESS_U1_DEVICE_TYP,
-   _type, 0, true);
+   >dev_type, 0, true);
if (ret < 0) {
dev_err(>dev, "failed U1_DEVICE_TYP (%d)\n", ret);
goto exit;
}
 
-   devInfo.x_active_len_mm =
-   (devInfo.pitch_x * (devInfo.sen_line_num_x - 1)) / 10;
-   devInfo.y_active_len_mm =
-   (devInfo.pitch_y * (devInfo.sen_line_num_y - 1)) / 10;
+   data->x_active_len_mm =
+   (data->pitch_x * (data->sen_line_num_x - 1)) / 10;
+   data->y_active_len_mm =
+   (data->pitch_y * (data->sen_line_num_y - 1)) / 10;
 
-   devInfo.x_max =
-   (devInfo.resolution << 2) * (devInfo.sen_line_num_x - 1);
-   devInfo.y_max =
-   (devInfo.resolution << 2) * (devInfo.sen_line_num_y - 1);
+   data->x_max =
+   (data->resolution << 2) * (data->sen_line_num_x - 1);
+   data->y_max =
+   (data->resolution << 2) * (data->sen_line_num_y - 1);
 
__set_bit(EV_ABS, input->evbit);
-   input_set_abs_params(input, ABS_MT_POSITION_X, 1, devInfo.x_max, 0, 0);
-   input_set_abs_params(input, ABS_MT_POSITION_Y, 1, devInfo.y_max, 0, 0);
+   input_set_abs_params(input, ABS_MT_POSITION_X, 1, data->x_max, 0, 0);
+   input_set_abs_params(input, ABS_MT_POSITION_Y, 1, data->y_max, 0, 0);
 
-   if (devInfo.x_active_len_mm && devInfo.y_active_len_mm) {
-   

[PATCH 1/7] Minor changes in hid-alps.c for support new Alps device(Delete unnecessary structure)

2017-09-11 Thread Masaki Ota
From: Masaki Ota 
-To support Alps T4 device, clean up the source code
-Delete unnecessary structure

Signed-off-by: Masaki Ota 
---
 drivers/hid/hid-alps.c | 69 +-
 1 file changed, 34 insertions(+), 35 deletions(-)

diff --git a/drivers/hid/hid-alps.c b/drivers/hid/hid-alps.c
index ed9c0ea5b026..519bfcf9eaf0 100644
--- a/drivers/hid/hid-alps.c
+++ b/drivers/hid/hid-alps.c
@@ -259,7 +259,6 @@ static int alps_input_configured(struct hid_device *hdev, 
struct hid_input *hi)
 {
struct u1_dev *data = hid_get_drvdata(hdev);
struct input_dev *input = hi->input, *input2;
-   struct u1_dev devInfo;
int ret;
int res_x, res_y, i;
 
@@ -275,58 +274,58 @@ static int alps_input_configured(struct hid_device *hdev, 
struct hid_input *hi)
 
/* Device initialization */
ret = u1_read_write_register(hdev, ADDRESS_U1_DEV_CTRL_1,
-   _ctrl, 0, true);
+   >dev_ctrl, 0, true);
if (ret < 0) {
dev_err(>dev, "failed U1_DEV_CTRL_1 (%d)\n", ret);
goto exit;
}
 
-   devInfo.dev_ctrl &= ~U1_DISABLE_DEV;
-   devInfo.dev_ctrl |= U1_TP_ABS_MODE;
+   data->dev_ctrl &= ~U1_DISABLE_DEV;
+   data->dev_ctrl |= U1_TP_ABS_MODE;
ret = u1_read_write_register(hdev, ADDRESS_U1_DEV_CTRL_1,
-   NULL, devInfo.dev_ctrl, false);
+   NULL, data->dev_ctrl, false);
if (ret < 0) {
dev_err(>dev, "failed to change TP mode (%d)\n", ret);
goto exit;
}
 
ret = u1_read_write_register(hdev, ADDRESS_U1_NUM_SENS_X,
-   _line_num_x, 0, true);
+   >sen_line_num_x, 0, true);
if (ret < 0) {
dev_err(>dev, "failed U1_NUM_SENS_X (%d)\n", ret);
goto exit;
}
 
ret = u1_read_write_register(hdev, ADDRESS_U1_NUM_SENS_Y,
-   _line_num_y, 0, true);
+   >sen_line_num_y, 0, true);
if (ret < 0) {
dev_err(>dev, "failed U1_NUM_SENS_Y (%d)\n", ret);
goto exit;
}
 
ret = u1_read_write_register(hdev, ADDRESS_U1_PITCH_SENS_X,
-   _x, 0, true);
+   >pitch_x, 0, true);
if (ret < 0) {
dev_err(>dev, "failed U1_PITCH_SENS_X (%d)\n", ret);
goto exit;
}
 
ret = u1_read_write_register(hdev, ADDRESS_U1_PITCH_SENS_Y,
-   _y, 0, true);
+   >pitch_y, 0, true);
if (ret < 0) {
dev_err(>dev, "failed U1_PITCH_SENS_Y (%d)\n", ret);
goto exit;
}
 
ret = u1_read_write_register(hdev, ADDRESS_U1_RESO_DWN_ABS,
-   , 0, true);
+   >resolution, 0, true);
if (ret < 0) {
dev_err(>dev, "failed U1_RESO_DWN_ABS (%d)\n", ret);
goto exit;
}
 
ret = u1_read_write_register(hdev, ADDRESS_U1_PAD_BTN,
-   _info, 0, true);
+   >btn_info, 0, true);
if (ret < 0) {
dev_err(>dev, "failed U1_PAD_BTN (%d)\n", ret);
goto exit;
@@ -334,29 +333,29 @@ static int alps_input_configured(struct hid_device *hdev, 
struct hid_input *hi)
 
/* Check StickPointer device */
ret = u1_read_write_register(hdev, ADDRESS_U1_DEVICE_TYP,
-   _type, 0, true);
+   >dev_type, 0, true);
if (ret < 0) {
dev_err(>dev, "failed U1_DEVICE_TYP (%d)\n", ret);
goto exit;
}
 
-   devInfo.x_active_len_mm =
-   (devInfo.pitch_x * (devInfo.sen_line_num_x - 1)) / 10;
-   devInfo.y_active_len_mm =
-   (devInfo.pitch_y * (devInfo.sen_line_num_y - 1)) / 10;
+   data->x_active_len_mm =
+   (data->pitch_x * (data->sen_line_num_x - 1)) / 10;
+   data->y_active_len_mm =
+   (data->pitch_y * (data->sen_line_num_y - 1)) / 10;
 
-   devInfo.x_max =
-   (devInfo.resolution << 2) * (devInfo.sen_line_num_x - 1);
-   devInfo.y_max =
-   (devInfo.resolution << 2) * (devInfo.sen_line_num_y - 1);
+   data->x_max =
+   (data->resolution << 2) * (data->sen_line_num_x - 1);
+   data->y_max =
+   (data->resolution << 2) * (data->sen_line_num_y - 1);
 
__set_bit(EV_ABS, input->evbit);
-   input_set_abs_params(input, ABS_MT_POSITION_X, 1, devInfo.x_max, 0, 0);
-   input_set_abs_params(input, ABS_MT_POSITION_Y, 1, devInfo.y_max, 0, 0);
+   input_set_abs_params(input, ABS_MT_POSITION_X, 1, data->x_max, 0, 0);
+   input_set_abs_params(input, ABS_MT_POSITION_Y, 1, data->y_max, 0, 0);
 
-   if (devInfo.x_active_len_mm && devInfo.y_active_len_mm) {
-   res_x = (devInfo.x_max - 1) / 

[PATCH 7/7] Support Alps U1 USB device

2017-09-11 Thread Masaki Ota
From: Masaki Ota 
-Add T4 USB device code and Product ID
-This device is used on HP Elite x2 series

Signed-off-by: Masaki Ota 
---
 drivers/hid/hid-alps.c | 35 +--
 drivers/hid/hid-core.c |  1 +
 drivers/hid/hid-ids.h  |  1 +
 3 files changed, 27 insertions(+), 10 deletions(-)

diff --git a/drivers/hid/hid-alps.c b/drivers/hid/hid-alps.c
index e7ae3a7b8e7d..e7a4e063597f 100644
--- a/drivers/hid/hid-alps.c
+++ b/drivers/hid/hid-alps.c
@@ -444,6 +444,7 @@ static int alps_raw_event(struct hid_device *hdev,
 
switch (hdev->product) {
case HID_PRODUCT_ID_T4_BTNLESS:
+   case HID_DEVICE_ID_ALPS_T4_USB:
ret = t4_raw_event(hdata, data, size);
break;
default:
@@ -598,13 +599,29 @@ static int T4_init(struct hid_device *hdev, struct 
alps_dev *pri_data)
int ret;
u8 tmp, sen_line_num_x, sen_line_num_y;
 
-   ret = t4_read_write_register(hdev, T4_PRM_ID_CONFIG_3, , 0, true);
-   if (ret < 0) {
-   dev_err(>dev, "failed T4_PRM_ID_CONFIG_3 (%d)\n", ret);
+   if (hdev->product == HID_DEVICE_ID_ALPS_T4_BTNLESS) {
+   ret = t4_read_write_register(hdev,
+   T4_PRM_ID_CONFIG_3, , 0, true);
+   if (ret < 0) {
+   dev_err(>dev,
+   "failed T4_PRM_ID_CONFIG_3 (%d)\n", ret);
goto exit;
+   }
+   sen_line_num_x = 16 + ((tmp & 0x0F)  | (tmp & 0x08 ? 0xF0 : 0));
+   sen_line_num_y =
+   12 + (((tmp & 0xF0) >> 4)  | (tmp & 0x80 ? 0xF0 : 0));
+
+   ret = t4_read_write_register(hdev,
+   PRM_SYS_CONFIG_1, , 0, true);
+   if (ret < 0) {
+   dev_err(>dev,
+   "failed PRM_SYS_CONFIG_1 (%d)\n", ret);
+   goto exit;
+   }
+   } else {
+   sen_line_num_x = 20;
+   sen_line_num_y = 12;
}
-   sen_line_num_x = 16 + ((tmp & 0x0F)  | (tmp & 0x08 ? 0xF0 : 0));
-   sen_line_num_y = 12 + (((tmp & 0xF0) >> 4)  | (tmp & 0x80 ? 0xF0 : 0));
 
pri_data->x_max = sen_line_num_x * T4_COUNT_PER_ELECTRODE;
pri_data->x_min = T4_COUNT_PER_ELECTRODE;
@@ -613,11 +630,6 @@ static int T4_init(struct hid_device *hdev, struct 
alps_dev *pri_data)
pri_data->x_active_len_mm = pri_data->y_active_len_mm = 0;
pri_data->btn_cnt = 1;
 
-   ret = t4_read_write_register(hdev, PRM_SYS_CONFIG_1, , 0, true);
-   if (ret < 0) {
-   dev_err(>dev, "failed PRM_SYS_CONFIG_1 (%d)\n", ret);
-   goto exit;
-   }
tmp |= 0x02;
ret = t4_read_write_register(hdev, PRM_SYS_CONFIG_1, NULL, tmp, false);
if (ret < 0) {
@@ -768,6 +780,7 @@ static int alps_probe(struct hid_device *hdev, const struct 
hid_device_id *id)
 
switch (hdev->product) {
case HID_DEVICE_ID_ALPS_T4_BTNLESS:
+   case HID_DEVICE_ID_ALPS_T4_USB:
data->dev_type = T4;
break;
case HID_DEVICE_ID_ALPS_U1_DUAL:
@@ -799,6 +812,8 @@ static const struct hid_device_id alps_id[] = {
USB_VENDOR_ID_ALPS_JP, HID_DEVICE_ID_ALPS_U1) },
{ HID_DEVICE(HID_BUS_ANY, HID_GROUP_ANY,
USB_VENDOR_ID_ALPS_JP, HID_DEVICE_ID_ALPS_T4_BTNLESS) },
+   { HID_DEVICE(HID_BUS_ANY, HID_GROUP_ANY,
+   USB_VENDOR_ID_ALPS_JP, HID_DEVICE_ID_ALPS_T4_USB) },
{ }
 };
 MODULE_DEVICE_TABLE(hid, alps_id);
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 779e26cb3ba9..13ded460885e 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1777,6 +1777,7 @@ static const struct hid_device_id 
hid_have_special_driver[] = {
{ HID_I2C_DEVICE(USB_VENDOR_ID_ALPS_JP, HID_DEVICE_ID_ALPS_U1_DUAL) },
{ HID_I2C_DEVICE(USB_VENDOR_ID_ALPS_JP, HID_DEVICE_ID_ALPS_U1) },
{ HID_I2C_DEVICE(USB_VENDOR_ID_ALPS_JP, HID_DEVICE_ID_ALPS_T4_BTNLESS) 
},
+   { HID_USB_DEVICE(USB_VENDOR_ID_ALPS_JP, HID_DEVICE_ID_ALPS_T4_USB) },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_MIGHTYMOUSE) 
},
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE, 
USB_DEVICE_ID_APPLE_MAGICMOUSE) },
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE, 
USB_DEVICE_ID_APPLE_MAGICTRACKPAD) },
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 2b50d12b993e..71c2a021e296 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -76,6 +76,7 @@
 #define USB_VENDOR_ID_ALPS_JP  0x044E
 #define HID_DEVICE_ID_ALPS_U1_DUAL 0x120B
 #define HID_DEVICE_ID_ALPS_U1  0x1215
+#define HID_DEVICE_ID_ALPS_T4_USB  0x1216
 #define HID_DEVICE_ID_ALPS_T4_BTNLESS  0x120C
 
 #define USB_VENDOR_ID_AMI  0x046b
-- 
2.11.0



[PATCH 7/7] Support Alps U1 USB device

2017-09-11 Thread Masaki Ota
From: Masaki Ota 
-Add T4 USB device code and Product ID
-This device is used on HP Elite x2 series

Signed-off-by: Masaki Ota 
---
 drivers/hid/hid-alps.c | 35 +--
 drivers/hid/hid-core.c |  1 +
 drivers/hid/hid-ids.h  |  1 +
 3 files changed, 27 insertions(+), 10 deletions(-)

diff --git a/drivers/hid/hid-alps.c b/drivers/hid/hid-alps.c
index e7ae3a7b8e7d..e7a4e063597f 100644
--- a/drivers/hid/hid-alps.c
+++ b/drivers/hid/hid-alps.c
@@ -444,6 +444,7 @@ static int alps_raw_event(struct hid_device *hdev,
 
switch (hdev->product) {
case HID_PRODUCT_ID_T4_BTNLESS:
+   case HID_DEVICE_ID_ALPS_T4_USB:
ret = t4_raw_event(hdata, data, size);
break;
default:
@@ -598,13 +599,29 @@ static int T4_init(struct hid_device *hdev, struct 
alps_dev *pri_data)
int ret;
u8 tmp, sen_line_num_x, sen_line_num_y;
 
-   ret = t4_read_write_register(hdev, T4_PRM_ID_CONFIG_3, , 0, true);
-   if (ret < 0) {
-   dev_err(>dev, "failed T4_PRM_ID_CONFIG_3 (%d)\n", ret);
+   if (hdev->product == HID_DEVICE_ID_ALPS_T4_BTNLESS) {
+   ret = t4_read_write_register(hdev,
+   T4_PRM_ID_CONFIG_3, , 0, true);
+   if (ret < 0) {
+   dev_err(>dev,
+   "failed T4_PRM_ID_CONFIG_3 (%d)\n", ret);
goto exit;
+   }
+   sen_line_num_x = 16 + ((tmp & 0x0F)  | (tmp & 0x08 ? 0xF0 : 0));
+   sen_line_num_y =
+   12 + (((tmp & 0xF0) >> 4)  | (tmp & 0x80 ? 0xF0 : 0));
+
+   ret = t4_read_write_register(hdev,
+   PRM_SYS_CONFIG_1, , 0, true);
+   if (ret < 0) {
+   dev_err(>dev,
+   "failed PRM_SYS_CONFIG_1 (%d)\n", ret);
+   goto exit;
+   }
+   } else {
+   sen_line_num_x = 20;
+   sen_line_num_y = 12;
}
-   sen_line_num_x = 16 + ((tmp & 0x0F)  | (tmp & 0x08 ? 0xF0 : 0));
-   sen_line_num_y = 12 + (((tmp & 0xF0) >> 4)  | (tmp & 0x80 ? 0xF0 : 0));
 
pri_data->x_max = sen_line_num_x * T4_COUNT_PER_ELECTRODE;
pri_data->x_min = T4_COUNT_PER_ELECTRODE;
@@ -613,11 +630,6 @@ static int T4_init(struct hid_device *hdev, struct 
alps_dev *pri_data)
pri_data->x_active_len_mm = pri_data->y_active_len_mm = 0;
pri_data->btn_cnt = 1;
 
-   ret = t4_read_write_register(hdev, PRM_SYS_CONFIG_1, , 0, true);
-   if (ret < 0) {
-   dev_err(>dev, "failed PRM_SYS_CONFIG_1 (%d)\n", ret);
-   goto exit;
-   }
tmp |= 0x02;
ret = t4_read_write_register(hdev, PRM_SYS_CONFIG_1, NULL, tmp, false);
if (ret < 0) {
@@ -768,6 +780,7 @@ static int alps_probe(struct hid_device *hdev, const struct 
hid_device_id *id)
 
switch (hdev->product) {
case HID_DEVICE_ID_ALPS_T4_BTNLESS:
+   case HID_DEVICE_ID_ALPS_T4_USB:
data->dev_type = T4;
break;
case HID_DEVICE_ID_ALPS_U1_DUAL:
@@ -799,6 +812,8 @@ static const struct hid_device_id alps_id[] = {
USB_VENDOR_ID_ALPS_JP, HID_DEVICE_ID_ALPS_U1) },
{ HID_DEVICE(HID_BUS_ANY, HID_GROUP_ANY,
USB_VENDOR_ID_ALPS_JP, HID_DEVICE_ID_ALPS_T4_BTNLESS) },
+   { HID_DEVICE(HID_BUS_ANY, HID_GROUP_ANY,
+   USB_VENDOR_ID_ALPS_JP, HID_DEVICE_ID_ALPS_T4_USB) },
{ }
 };
 MODULE_DEVICE_TABLE(hid, alps_id);
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 779e26cb3ba9..13ded460885e 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1777,6 +1777,7 @@ static const struct hid_device_id 
hid_have_special_driver[] = {
{ HID_I2C_DEVICE(USB_VENDOR_ID_ALPS_JP, HID_DEVICE_ID_ALPS_U1_DUAL) },
{ HID_I2C_DEVICE(USB_VENDOR_ID_ALPS_JP, HID_DEVICE_ID_ALPS_U1) },
{ HID_I2C_DEVICE(USB_VENDOR_ID_ALPS_JP, HID_DEVICE_ID_ALPS_T4_BTNLESS) 
},
+   { HID_USB_DEVICE(USB_VENDOR_ID_ALPS_JP, HID_DEVICE_ID_ALPS_T4_USB) },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_MIGHTYMOUSE) 
},
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE, 
USB_DEVICE_ID_APPLE_MAGICMOUSE) },
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE, 
USB_DEVICE_ID_APPLE_MAGICTRACKPAD) },
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 2b50d12b993e..71c2a021e296 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -76,6 +76,7 @@
 #define USB_VENDOR_ID_ALPS_JP  0x044E
 #define HID_DEVICE_ID_ALPS_U1_DUAL 0x120B
 #define HID_DEVICE_ID_ALPS_U1  0x1215
+#define HID_DEVICE_ID_ALPS_T4_USB  0x1216
 #define HID_DEVICE_ID_ALPS_T4_BTNLESS  0x120C
 
 #define USB_VENDOR_ID_AMI  0x046b
-- 
2.11.0



[PATCH 4/7] Minor changes in hid-alps.c for support new Alps device(replace some variables)

2017-09-11 Thread Masaki Ota
From: Masaki Ota 
-To support Alps T4 device, replace some variables

Signed-off-by: Masaki Ota 
---
 drivers/hid/hid-alps.c | 67 --
 1 file changed, 27 insertions(+), 40 deletions(-)

diff --git a/drivers/hid/hid-alps.c b/drivers/hid/hid-alps.c
index 201fe175cba3..4c323b58e009 100644
--- a/drivers/hid/hid-alps.c
+++ b/drivers/hid/hid-alps.c
@@ -61,14 +61,10 @@
  * @input2: pointer to the kernel input2 device
  * @hdev: pointer to the struct hid_device
  *
- * @dev_ctrl: device control parameter
  * @dev_type: device type
- * @sen_line_num_x: number of sensor line of X
- * @sen_line_num_y: number of sensor line of Y
- * @pitch_x: sensor pitch of X
- * @pitch_y: sensor pitch of Y
- * @resolution: resolution
- * @btn_info: button information
+ * @max_fingers: total number of fingers
+ * @has_sp: boolean of sp existense
+ * @sp_btn_info: button information
  * @x_active_len_mm: active area length of X (mm)
  * @y_active_len_mm: active area length of Y (mm)
  * @x_max: maximum x coordinate value
@@ -77,22 +73,14 @@
  * @y_min: minimum y coordinate value
  * @btn_cnt: number of buttons
  * @sp_btn_cnt: number of stick buttons
- * @has_sp: boolean of sp existense
- * @max_fingers: total number of fingers
  */
 struct u1_dev {
struct input_dev *input;
struct input_dev *input2;
struct hid_device *hdev;
 
-   u8  dev_ctrl;
-   u8  dev_type;
-   u8  sen_line_num_x;
-   u8  sen_line_num_y;
-   u8  pitch_x;
-   u8  pitch_y;
-   u8  resolution;
-   u8  btn_info;
+   u8  max_fingers;
+   u8  has_sp;
u8  sp_btn_info;
u32 x_active_len_mm;
u32 y_active_len_mm;
@@ -102,8 +90,6 @@ struct u1_dev {
u32 y_min;
u32 btn_cnt;
u32 sp_btn_cnt;
-   u8  has_sp;
-   u8  max_fingers;
 };
 
 static int u1_read_write_register(struct hid_device *hdev, u32 address,
@@ -266,78 +252,80 @@ static int alps_post_resume(struct hid_device *hdev)
 static int u1_init(struct hid_device *hdev, struct u1_dev *pri_data)
 {
int ret;
+   u8 tmp, dev_ctrl, sen_line_num_x, sen_line_num_y;
+   u8 pitch_x, pitch_y, resolution;
 
/* Device initialization */
ret = u1_read_write_register(hdev, ADDRESS_U1_DEV_CTRL_1,
-   _data->dev_ctrl, 0, true);
+   _ctrl, 0, true);
if (ret < 0) {
dev_err(>dev, "failed U1_DEV_CTRL_1 (%d)\n", ret);
goto exit;
}
 
-   pri_data->dev_ctrl &= ~U1_DISABLE_DEV;
-   pri_data->dev_ctrl |= U1_TP_ABS_MODE;
+   dev_ctrl &= ~U1_DISABLE_DEV;
+   dev_ctrl |= U1_TP_ABS_MODE;
ret = u1_read_write_register(hdev, ADDRESS_U1_DEV_CTRL_1,
-   NULL, pri_data->dev_ctrl, false);
+   NULL, dev_ctrl, false);
if (ret < 0) {
dev_err(>dev, "failed to change TP mode (%d)\n", ret);
goto exit;
}
 
ret = u1_read_write_register(hdev, ADDRESS_U1_NUM_SENS_X,
-   _data->sen_line_num_x, 0, true);
+   _line_num_x, 0, true);
if (ret < 0) {
dev_err(>dev, "failed U1_NUM_SENS_X (%d)\n", ret);
goto exit;
}
 
ret = u1_read_write_register(hdev, ADDRESS_U1_NUM_SENS_Y,
-   _data->sen_line_num_y, 0, true);
+   _line_num_y, 0, true);
if (ret < 0) {
dev_err(>dev, "failed U1_NUM_SENS_Y (%d)\n", ret);
goto exit;
}
 
ret = u1_read_write_register(hdev, ADDRESS_U1_PITCH_SENS_X,
-   _data->pitch_x, 0, true);
+   _x, 0, true);
if (ret < 0) {
dev_err(>dev, "failed U1_PITCH_SENS_X (%d)\n", ret);
goto exit;
}
 
ret = u1_read_write_register(hdev, ADDRESS_U1_PITCH_SENS_Y,
-   _data->pitch_y, 0, true);
+   _y, 0, true);
if (ret < 0) {
dev_err(>dev, "failed U1_PITCH_SENS_Y (%d)\n", ret);
goto exit;
}
 
ret = u1_read_write_register(hdev, ADDRESS_U1_RESO_DWN_ABS,
-   _data->resolution, 0, true);
+   , 0, true);
if (ret < 0) {
dev_err(>dev, "failed U1_RESO_DWN_ABS (%d)\n", ret);
goto exit;
}
pri_data->x_active_len_mm =
-   (pri_data->pitch_x * (pri_data->sen_line_num_x - 1)) / 10;
+   (pitch_x * (sen_line_num_x - 1)) / 10;
pri_data->y_active_len_mm =
-   (pri_data->pitch_y * (pri_data->sen_line_num_y - 1)) / 10;
+   (pitch_y * (sen_line_num_y - 1)) / 10;
 
pri_data->x_max =
-   (pri_data->resolution << 2) * (pri_data->sen_line_num_x - 1);
+ 

[PATCH 4/7] Minor changes in hid-alps.c for support new Alps device(replace some variables)

2017-09-11 Thread Masaki Ota
From: Masaki Ota 
-To support Alps T4 device, replace some variables

Signed-off-by: Masaki Ota 
---
 drivers/hid/hid-alps.c | 67 --
 1 file changed, 27 insertions(+), 40 deletions(-)

diff --git a/drivers/hid/hid-alps.c b/drivers/hid/hid-alps.c
index 201fe175cba3..4c323b58e009 100644
--- a/drivers/hid/hid-alps.c
+++ b/drivers/hid/hid-alps.c
@@ -61,14 +61,10 @@
  * @input2: pointer to the kernel input2 device
  * @hdev: pointer to the struct hid_device
  *
- * @dev_ctrl: device control parameter
  * @dev_type: device type
- * @sen_line_num_x: number of sensor line of X
- * @sen_line_num_y: number of sensor line of Y
- * @pitch_x: sensor pitch of X
- * @pitch_y: sensor pitch of Y
- * @resolution: resolution
- * @btn_info: button information
+ * @max_fingers: total number of fingers
+ * @has_sp: boolean of sp existense
+ * @sp_btn_info: button information
  * @x_active_len_mm: active area length of X (mm)
  * @y_active_len_mm: active area length of Y (mm)
  * @x_max: maximum x coordinate value
@@ -77,22 +73,14 @@
  * @y_min: minimum y coordinate value
  * @btn_cnt: number of buttons
  * @sp_btn_cnt: number of stick buttons
- * @has_sp: boolean of sp existense
- * @max_fingers: total number of fingers
  */
 struct u1_dev {
struct input_dev *input;
struct input_dev *input2;
struct hid_device *hdev;
 
-   u8  dev_ctrl;
-   u8  dev_type;
-   u8  sen_line_num_x;
-   u8  sen_line_num_y;
-   u8  pitch_x;
-   u8  pitch_y;
-   u8  resolution;
-   u8  btn_info;
+   u8  max_fingers;
+   u8  has_sp;
u8  sp_btn_info;
u32 x_active_len_mm;
u32 y_active_len_mm;
@@ -102,8 +90,6 @@ struct u1_dev {
u32 y_min;
u32 btn_cnt;
u32 sp_btn_cnt;
-   u8  has_sp;
-   u8  max_fingers;
 };
 
 static int u1_read_write_register(struct hid_device *hdev, u32 address,
@@ -266,78 +252,80 @@ static int alps_post_resume(struct hid_device *hdev)
 static int u1_init(struct hid_device *hdev, struct u1_dev *pri_data)
 {
int ret;
+   u8 tmp, dev_ctrl, sen_line_num_x, sen_line_num_y;
+   u8 pitch_x, pitch_y, resolution;
 
/* Device initialization */
ret = u1_read_write_register(hdev, ADDRESS_U1_DEV_CTRL_1,
-   _data->dev_ctrl, 0, true);
+   _ctrl, 0, true);
if (ret < 0) {
dev_err(>dev, "failed U1_DEV_CTRL_1 (%d)\n", ret);
goto exit;
}
 
-   pri_data->dev_ctrl &= ~U1_DISABLE_DEV;
-   pri_data->dev_ctrl |= U1_TP_ABS_MODE;
+   dev_ctrl &= ~U1_DISABLE_DEV;
+   dev_ctrl |= U1_TP_ABS_MODE;
ret = u1_read_write_register(hdev, ADDRESS_U1_DEV_CTRL_1,
-   NULL, pri_data->dev_ctrl, false);
+   NULL, dev_ctrl, false);
if (ret < 0) {
dev_err(>dev, "failed to change TP mode (%d)\n", ret);
goto exit;
}
 
ret = u1_read_write_register(hdev, ADDRESS_U1_NUM_SENS_X,
-   _data->sen_line_num_x, 0, true);
+   _line_num_x, 0, true);
if (ret < 0) {
dev_err(>dev, "failed U1_NUM_SENS_X (%d)\n", ret);
goto exit;
}
 
ret = u1_read_write_register(hdev, ADDRESS_U1_NUM_SENS_Y,
-   _data->sen_line_num_y, 0, true);
+   _line_num_y, 0, true);
if (ret < 0) {
dev_err(>dev, "failed U1_NUM_SENS_Y (%d)\n", ret);
goto exit;
}
 
ret = u1_read_write_register(hdev, ADDRESS_U1_PITCH_SENS_X,
-   _data->pitch_x, 0, true);
+   _x, 0, true);
if (ret < 0) {
dev_err(>dev, "failed U1_PITCH_SENS_X (%d)\n", ret);
goto exit;
}
 
ret = u1_read_write_register(hdev, ADDRESS_U1_PITCH_SENS_Y,
-   _data->pitch_y, 0, true);
+   _y, 0, true);
if (ret < 0) {
dev_err(>dev, "failed U1_PITCH_SENS_Y (%d)\n", ret);
goto exit;
}
 
ret = u1_read_write_register(hdev, ADDRESS_U1_RESO_DWN_ABS,
-   _data->resolution, 0, true);
+   , 0, true);
if (ret < 0) {
dev_err(>dev, "failed U1_RESO_DWN_ABS (%d)\n", ret);
goto exit;
}
pri_data->x_active_len_mm =
-   (pri_data->pitch_x * (pri_data->sen_line_num_x - 1)) / 10;
+   (pitch_x * (sen_line_num_x - 1)) / 10;
pri_data->y_active_len_mm =
-   (pri_data->pitch_y * (pri_data->sen_line_num_y - 1)) / 10;
+   (pitch_y * (sen_line_num_y - 1)) / 10;
 
pri_data->x_max =
-   (pri_data->resolution << 2) * (pri_data->sen_line_num_x - 1);
+   (resolution << 2) * (sen_line_num_x - 1);

[PATCH 3/7] Minor changes in hid-alps.c for support new Alps device(Add some variables)

2017-09-11 Thread Masaki Ota
From: Masaki Ota 
-To support Alps T4 device, add x_min, y_min, max_fingers variables

Signed-off-by: Masaki Ota 
---
 drivers/hid/hid-alps.c | 38 --
 1 file changed, 24 insertions(+), 14 deletions(-)

diff --git a/drivers/hid/hid-alps.c b/drivers/hid/hid-alps.c
index c4ea5c6c9be9..201fe175cba3 100644
--- a/drivers/hid/hid-alps.c
+++ b/drivers/hid/hid-alps.c
@@ -73,9 +73,12 @@
  * @y_active_len_mm: active area length of Y (mm)
  * @x_max: maximum x coordinate value
  * @y_max: maximum y coordinate value
+ * @x_min: minimum x coordinate value
+ * @y_min: minimum y coordinate value
  * @btn_cnt: number of buttons
  * @sp_btn_cnt: number of stick buttons
  * @has_sp: boolean of sp existense
+ * @max_fingers: total number of fingers
  */
 struct u1_dev {
struct input_dev *input;
@@ -95,9 +98,12 @@ struct u1_dev {
u32 y_active_len_mm;
u32 x_max;
u32 y_max;
+   u32 x_min;
+   u32 y_min;
u32 btn_cnt;
u32 sp_btn_cnt;
u8  has_sp;
+   u8  max_fingers;
 };
 
 static int u1_read_write_register(struct hid_device *hdev, u32 address,
@@ -319,8 +325,10 @@ static int u1_init(struct hid_device *hdev, struct u1_dev 
*pri_data)
 
pri_data->x_max =
(pri_data->resolution << 2) * (pri_data->sen_line_num_x - 1);
+   pri_data->x_min = 1;
pri_data->y_max =
(pri_data->resolution << 2) * (pri_data->sen_line_num_y - 1);
+   pri_data->y_min = 1;
 
ret = u1_read_write_register(hdev, ADDRESS_U1_PAD_BTN,
_data->btn_info, 0, true);
@@ -328,6 +336,12 @@ static int u1_init(struct hid_device *hdev, struct u1_dev 
*pri_data)
dev_err(>dev, "failed U1_PAD_BTN (%d)\n", ret);
goto exit;
}
+   if ((pri_data->btn_info & 0x0F) == (pri_data->btn_info & 0xF0) >> 4) {
+   pri_data->btn_cnt = (pri_data->btn_info & 0x0F);
+   } else {
+   /* Button pad */
+   pri_data->btn_cnt = 1;
+   }
 
pri_data->has_sp = 0;
/* Check StickPointer device */
@@ -355,7 +369,7 @@ static int u1_init(struct hid_device *hdev, struct u1_dev 
*pri_data)
}
pri_data->has_sp = 1;
}
-
+   pri_data->max_fingers = 5;
 exit:
return ret;
 }
@@ -383,8 +397,10 @@ static int alps_input_configured(struct hid_device *hdev, 
struct hid_input *hi)
goto exit;
 
__set_bit(EV_ABS, input->evbit);
-   input_set_abs_params(input, ABS_MT_POSITION_X, 1, data->x_max, 0, 0);
-   input_set_abs_params(input, ABS_MT_POSITION_Y, 1, data->y_max, 0, 0);
+   input_set_abs_params(input, ABS_MT_POSITION_X,
+   data->x_min, data->x_max, 0, 0);
+   input_set_abs_params(input, ABS_MT_POSITION_Y,
+   data->y_min, data->y_max, 0, 0);
 
if (data->x_active_len_mm && data->y_active_len_mm) {
res_x = (data->x_max - 1) / data->x_active_len_mm;
@@ -396,26 +412,21 @@ static int alps_input_configured(struct hid_device *hdev, 
struct hid_input *hi)
 
input_set_abs_params(input, ABS_MT_PRESSURE, 0, 64, 0, 0);
 
-   input_mt_init_slots(input, MAX_TOUCHES, INPUT_MT_POINTER);
+   input_mt_init_slots(input, data->max_fingers, INPUT_MT_POINTER);
 
__set_bit(EV_KEY, input->evbit);
-   if ((data->btn_info & 0x0F) == (data->btn_info & 0xF0) >> 4) {
-   data->btn_cnt = (data->btn_info & 0x0F);
-   } else {
-   /* Button pad */
-   data->btn_cnt = 1;
+
+   if (data->btn_cnt == 1)
__set_bit(INPUT_PROP_BUTTONPAD, input->propbit);
-   }
 
for (i = 0; i < data->btn_cnt; i++)
__set_bit(BTN_LEFT + i, input->keybit);
 
-
/* Stick device initialization */
if (data->has_sp) {
input2 = input_allocate_device();
if (!input2) {
-   ret = -ENOMEM;
+   input_free_device(input2);
goto exit;
}
 
@@ -439,8 +450,7 @@ static int alps_input_configured(struct hid_device *hdev, 
struct hid_input *hi)
__set_bit(INPUT_PROP_POINTER, input2->propbit);
__set_bit(INPUT_PROP_POINTING_STICK, input2->propbit);
 
-   ret = input_register_device(data->input2);
-   if (ret) {
+   if (input_register_device(data->input2)) {
input_free_device(input2);
goto exit;
}
-- 
2.11.0



[PATCH 3/7] Minor changes in hid-alps.c for support new Alps device(Add some variables)

2017-09-11 Thread Masaki Ota
From: Masaki Ota 
-To support Alps T4 device, add x_min, y_min, max_fingers variables

Signed-off-by: Masaki Ota 
---
 drivers/hid/hid-alps.c | 38 --
 1 file changed, 24 insertions(+), 14 deletions(-)

diff --git a/drivers/hid/hid-alps.c b/drivers/hid/hid-alps.c
index c4ea5c6c9be9..201fe175cba3 100644
--- a/drivers/hid/hid-alps.c
+++ b/drivers/hid/hid-alps.c
@@ -73,9 +73,12 @@
  * @y_active_len_mm: active area length of Y (mm)
  * @x_max: maximum x coordinate value
  * @y_max: maximum y coordinate value
+ * @x_min: minimum x coordinate value
+ * @y_min: minimum y coordinate value
  * @btn_cnt: number of buttons
  * @sp_btn_cnt: number of stick buttons
  * @has_sp: boolean of sp existense
+ * @max_fingers: total number of fingers
  */
 struct u1_dev {
struct input_dev *input;
@@ -95,9 +98,12 @@ struct u1_dev {
u32 y_active_len_mm;
u32 x_max;
u32 y_max;
+   u32 x_min;
+   u32 y_min;
u32 btn_cnt;
u32 sp_btn_cnt;
u8  has_sp;
+   u8  max_fingers;
 };
 
 static int u1_read_write_register(struct hid_device *hdev, u32 address,
@@ -319,8 +325,10 @@ static int u1_init(struct hid_device *hdev, struct u1_dev 
*pri_data)
 
pri_data->x_max =
(pri_data->resolution << 2) * (pri_data->sen_line_num_x - 1);
+   pri_data->x_min = 1;
pri_data->y_max =
(pri_data->resolution << 2) * (pri_data->sen_line_num_y - 1);
+   pri_data->y_min = 1;
 
ret = u1_read_write_register(hdev, ADDRESS_U1_PAD_BTN,
_data->btn_info, 0, true);
@@ -328,6 +336,12 @@ static int u1_init(struct hid_device *hdev, struct u1_dev 
*pri_data)
dev_err(>dev, "failed U1_PAD_BTN (%d)\n", ret);
goto exit;
}
+   if ((pri_data->btn_info & 0x0F) == (pri_data->btn_info & 0xF0) >> 4) {
+   pri_data->btn_cnt = (pri_data->btn_info & 0x0F);
+   } else {
+   /* Button pad */
+   pri_data->btn_cnt = 1;
+   }
 
pri_data->has_sp = 0;
/* Check StickPointer device */
@@ -355,7 +369,7 @@ static int u1_init(struct hid_device *hdev, struct u1_dev 
*pri_data)
}
pri_data->has_sp = 1;
}
-
+   pri_data->max_fingers = 5;
 exit:
return ret;
 }
@@ -383,8 +397,10 @@ static int alps_input_configured(struct hid_device *hdev, 
struct hid_input *hi)
goto exit;
 
__set_bit(EV_ABS, input->evbit);
-   input_set_abs_params(input, ABS_MT_POSITION_X, 1, data->x_max, 0, 0);
-   input_set_abs_params(input, ABS_MT_POSITION_Y, 1, data->y_max, 0, 0);
+   input_set_abs_params(input, ABS_MT_POSITION_X,
+   data->x_min, data->x_max, 0, 0);
+   input_set_abs_params(input, ABS_MT_POSITION_Y,
+   data->y_min, data->y_max, 0, 0);
 
if (data->x_active_len_mm && data->y_active_len_mm) {
res_x = (data->x_max - 1) / data->x_active_len_mm;
@@ -396,26 +412,21 @@ static int alps_input_configured(struct hid_device *hdev, 
struct hid_input *hi)
 
input_set_abs_params(input, ABS_MT_PRESSURE, 0, 64, 0, 0);
 
-   input_mt_init_slots(input, MAX_TOUCHES, INPUT_MT_POINTER);
+   input_mt_init_slots(input, data->max_fingers, INPUT_MT_POINTER);
 
__set_bit(EV_KEY, input->evbit);
-   if ((data->btn_info & 0x0F) == (data->btn_info & 0xF0) >> 4) {
-   data->btn_cnt = (data->btn_info & 0x0F);
-   } else {
-   /* Button pad */
-   data->btn_cnt = 1;
+
+   if (data->btn_cnt == 1)
__set_bit(INPUT_PROP_BUTTONPAD, input->propbit);
-   }
 
for (i = 0; i < data->btn_cnt; i++)
__set_bit(BTN_LEFT + i, input->keybit);
 
-
/* Stick device initialization */
if (data->has_sp) {
input2 = input_allocate_device();
if (!input2) {
-   ret = -ENOMEM;
+   input_free_device(input2);
goto exit;
}
 
@@ -439,8 +450,7 @@ static int alps_input_configured(struct hid_device *hdev, 
struct hid_input *hi)
__set_bit(INPUT_PROP_POINTER, input2->propbit);
__set_bit(INPUT_PROP_POINTING_STICK, input2->propbit);
 
-   ret = input_register_device(data->input2);
-   if (ret) {
+   if (input_register_device(data->input2)) {
input_free_device(input2);
goto exit;
}
-- 
2.11.0



[PATCH 6/7] Add new U1 device ID for supporting it

2017-09-11 Thread Masaki Ota
From: Masaki Ota 
-Add new U1 device Product ID
-This device is used on HP Elite book x360 series

Signed-off-by: Masaki Ota 
---
 drivers/hid/hid-alps.c | 3 +++
 drivers/hid/hid-core.c | 1 +
 drivers/hid/hid-ids.h  | 1 +
 3 files changed, 5 insertions(+)

diff --git a/drivers/hid/hid-alps.c b/drivers/hid/hid-alps.c
index 0a6c54fb47c8..e7ae3a7b8e7d 100644
--- a/drivers/hid/hid-alps.c
+++ b/drivers/hid/hid-alps.c
@@ -771,6 +771,7 @@ static int alps_probe(struct hid_device *hdev, const struct 
hid_device_id *id)
data->dev_type = T4;
break;
case HID_DEVICE_ID_ALPS_U1_DUAL:
+   case HID_DEVICE_ID_ALPS_U1:
data->dev_type = U1;
break;
default:
@@ -795,6 +796,8 @@ static const struct hid_device_id alps_id[] = {
{ HID_DEVICE(HID_BUS_ANY, HID_GROUP_ANY,
USB_VENDOR_ID_ALPS_JP, HID_DEVICE_ID_ALPS_U1_DUAL) },
{ HID_DEVICE(HID_BUS_ANY, HID_GROUP_ANY,
+   USB_VENDOR_ID_ALPS_JP, HID_DEVICE_ID_ALPS_U1) },
+   { HID_DEVICE(HID_BUS_ANY, HID_GROUP_ANY,
USB_VENDOR_ID_ALPS_JP, HID_DEVICE_ID_ALPS_T4_BTNLESS) },
{ }
 };
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 9c3cb2e467e9..779e26cb3ba9 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1775,6 +1775,7 @@ static const struct hid_device_id 
hid_have_special_driver[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_ACRUX, 0x0802) },
{ HID_USB_DEVICE(USB_VENDOR_ID_ACRUX, 0xf705) },
{ HID_I2C_DEVICE(USB_VENDOR_ID_ALPS_JP, HID_DEVICE_ID_ALPS_U1_DUAL) },
+   { HID_I2C_DEVICE(USB_VENDOR_ID_ALPS_JP, HID_DEVICE_ID_ALPS_U1) },
{ HID_I2C_DEVICE(USB_VENDOR_ID_ALPS_JP, HID_DEVICE_ID_ALPS_T4_BTNLESS) 
},
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_MIGHTYMOUSE) 
},
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE, 
USB_DEVICE_ID_APPLE_MAGICMOUSE) },
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 0b9726d321ee..2b50d12b993e 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -75,6 +75,7 @@
 
 #define USB_VENDOR_ID_ALPS_JP  0x044E
 #define HID_DEVICE_ID_ALPS_U1_DUAL 0x120B
+#define HID_DEVICE_ID_ALPS_U1  0x1215
 #define HID_DEVICE_ID_ALPS_T4_BTNLESS  0x120C
 
 #define USB_VENDOR_ID_AMI  0x046b
-- 
2.11.0



[PATCH 6/7] Add new U1 device ID for supporting it

2017-09-11 Thread Masaki Ota
From: Masaki Ota 
-Add new U1 device Product ID
-This device is used on HP Elite book x360 series

Signed-off-by: Masaki Ota 
---
 drivers/hid/hid-alps.c | 3 +++
 drivers/hid/hid-core.c | 1 +
 drivers/hid/hid-ids.h  | 1 +
 3 files changed, 5 insertions(+)

diff --git a/drivers/hid/hid-alps.c b/drivers/hid/hid-alps.c
index 0a6c54fb47c8..e7ae3a7b8e7d 100644
--- a/drivers/hid/hid-alps.c
+++ b/drivers/hid/hid-alps.c
@@ -771,6 +771,7 @@ static int alps_probe(struct hid_device *hdev, const struct 
hid_device_id *id)
data->dev_type = T4;
break;
case HID_DEVICE_ID_ALPS_U1_DUAL:
+   case HID_DEVICE_ID_ALPS_U1:
data->dev_type = U1;
break;
default:
@@ -795,6 +796,8 @@ static const struct hid_device_id alps_id[] = {
{ HID_DEVICE(HID_BUS_ANY, HID_GROUP_ANY,
USB_VENDOR_ID_ALPS_JP, HID_DEVICE_ID_ALPS_U1_DUAL) },
{ HID_DEVICE(HID_BUS_ANY, HID_GROUP_ANY,
+   USB_VENDOR_ID_ALPS_JP, HID_DEVICE_ID_ALPS_U1) },
+   { HID_DEVICE(HID_BUS_ANY, HID_GROUP_ANY,
USB_VENDOR_ID_ALPS_JP, HID_DEVICE_ID_ALPS_T4_BTNLESS) },
{ }
 };
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 9c3cb2e467e9..779e26cb3ba9 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1775,6 +1775,7 @@ static const struct hid_device_id 
hid_have_special_driver[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_ACRUX, 0x0802) },
{ HID_USB_DEVICE(USB_VENDOR_ID_ACRUX, 0xf705) },
{ HID_I2C_DEVICE(USB_VENDOR_ID_ALPS_JP, HID_DEVICE_ID_ALPS_U1_DUAL) },
+   { HID_I2C_DEVICE(USB_VENDOR_ID_ALPS_JP, HID_DEVICE_ID_ALPS_U1) },
{ HID_I2C_DEVICE(USB_VENDOR_ID_ALPS_JP, HID_DEVICE_ID_ALPS_T4_BTNLESS) 
},
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_MIGHTYMOUSE) 
},
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE, 
USB_DEVICE_ID_APPLE_MAGICMOUSE) },
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 0b9726d321ee..2b50d12b993e 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -75,6 +75,7 @@
 
 #define USB_VENDOR_ID_ALPS_JP  0x044E
 #define HID_DEVICE_ID_ALPS_U1_DUAL 0x120B
+#define HID_DEVICE_ID_ALPS_U1  0x1215
 #define HID_DEVICE_ID_ALPS_T4_BTNLESS  0x120C
 
 #define USB_VENDOR_ID_AMI  0x046b
-- 
2.11.0



[PATCH 5/7] Support new Alps device that name is T4

2017-09-11 Thread Masaki Ota
From: Masaki Ota 
-Add T4 device code and Product ID
-This device is used on HP EliteBook 1000 series and Zbook Stduio

Signed-off-by: Masaki Ota 
---
 drivers/hid/hid-alps.c | 343 ++---
 drivers/hid/hid-core.c |   3 +-
 drivers/hid/hid-ids.h  |   1 +
 3 files changed, 326 insertions(+), 21 deletions(-)

diff --git a/drivers/hid/hid-alps.c b/drivers/hid/hid-alps.c
index 4c323b58e009..0a6c54fb47c8 100644
--- a/drivers/hid/hid-alps.c
+++ b/drivers/hid/hid-alps.c
@@ -52,8 +52,30 @@
 #define ADDRESS_U1_PAD_BTN 0x00800052
 #define ADDRESS_U1_SP_BTN  0x0080009F
 
+#define T4_INPUT_REPORT_LENsizeof(struct t4_input_report)
+#define T4_FEATURE_REPORT_LEN  T4_INPUT_REPORT_LEN
+#define T4_FEATURE_REPORT_ID   7
+#define T4_CMD_REGISTER_READ   0x08
+#define T4_CMD_REGISTER_WRITE  0x07
+
+#define T4_ADDRESS_BASE0xC2C0
+#define PRM_SYS_CONFIG_1   (T4_ADDRESS_BASE + 0x0002)
+#define T4_PRM_FEED_CONFIG_1   (T4_ADDRESS_BASE + 0x0004)
+#define T4_PRM_FEED_CONFIG_4   (T4_ADDRESS_BASE + 0x001A)
+#define T4_PRM_ID_CONFIG_3 (T4_ADDRESS_BASE + 0x00B0)
+
+
+#define T4_FEEDCFG4_ADVANCED_ABS_ENABLE0x01
+#define T4_I2C_ABS 0x78
+
+#define T4_COUNT_PER_ELECTRODE 256
 #define MAX_TOUCHES5
 
+enum dev_num {
+   U1,
+   T4,
+   UNKNOWN,
+};
 /**
  * struct u1_data
  *
@@ -74,11 +96,12 @@
  * @btn_cnt: number of buttons
  * @sp_btn_cnt: number of stick buttons
  */
-struct u1_dev {
+struct alps_dev {
struct input_dev *input;
struct input_dev *input2;
struct hid_device *hdev;
 
+   enum dev_num dev_type;
u8  max_fingers;
u8  has_sp;
u8  sp_btn_info;
@@ -92,6 +115,145 @@ struct u1_dev {
u32 sp_btn_cnt;
 };
 
+struct t4_contact_data {
+   u8  palm;
+   u8  x_lo;
+   u8  x_hi;
+   u8  y_lo;
+   u8  y_hi;
+};
+
+struct t4_input_report {
+   u8  reportID;
+   u8  numContacts;
+   struct t4_contact_data contact[5];
+   u8  button;
+   u8  track[5];
+   u8  zx[5], zy[5];
+   u8  palmTime[5];
+   u8  kilroy;
+   u16 timeStamp;
+};
+
+static u16 t4_calc_check_sum(u8 *buffer,
+   unsigned long offset, unsigned long length)
+{
+   u16 sum1 = 0xFF, sum2 = 0xFF;
+   unsigned long i = 0;
+
+   if (offset + length >= 50)
+   return 0;
+
+   while (length > 0) {
+   u32 tlen = length > 20 ? 20 : length;
+
+   length -= tlen;
+
+   do {
+   sum1 += buffer[offset + i];
+   sum2 += sum1;
+   i++;
+   } while (--tlen > 0);
+
+   sum1 = (sum1 & 0xFF) + (sum1 >> 8);
+   sum2 = (sum2 & 0xFF) + (sum2 >> 8);
+   }
+
+   sum1 = (sum1 & 0xFF) + (sum1 >> 8);
+   sum2 = (sum2 & 0xFF) + (sum2 >> 8);
+
+   return(sum2 << 8 | sum1);
+}
+
+static int t4_read_write_register(struct hid_device *hdev, u32 address,
+   u8 *read_val, u8 write_val, bool read_flag)
+{
+   int ret;
+   u16 check_sum;
+   u8 *input;
+   u8 *readbuf;
+
+   input = kzalloc(T4_FEATURE_REPORT_LEN, GFP_KERNEL);
+   if (!input)
+   return -ENOMEM;
+
+   input[0] = T4_FEATURE_REPORT_ID;
+   if (read_flag) {
+   input[1] = T4_CMD_REGISTER_READ;
+   input[8] = 0x00;
+   } else {
+   input[1] = T4_CMD_REGISTER_WRITE;
+   input[8] = write_val;
+   }
+   put_unaligned_le32(address, input + 2);
+   input[6] = 1;
+   input[7] = 0;
+
+   /* Calculate the checksum */
+   check_sum = t4_calc_check_sum(input, 1, 8);
+   input[9] = (u8)check_sum;
+   input[10] = (u8)(check_sum >> 8);
+   input[11] = 0;
+
+   ret = hid_hw_raw_request(hdev, T4_FEATURE_REPORT_ID, input,
+   T4_FEATURE_REPORT_LEN,
+   HID_FEATURE_REPORT, HID_REQ_SET_REPORT);
+
+   if (ret < 0) {
+   dev_err(>dev, "failed to read command (%d)\n", ret);
+   goto exit;
+   }
+
+   if (read_flag) {
+   readbuf = kzalloc(T4_FEATURE_REPORT_LEN, GFP_KERNEL);
+   if (!readbuf) {
+   ret = -ENOMEM;
+   goto exit;
+   }
+
+   ret = hid_hw_raw_request(hdev, T4_FEATURE_REPORT_ID, readbuf,
+   T4_FEATURE_REPORT_LEN,
+   HID_FEATURE_REPORT, HID_REQ_GET_REPORT);
+   if (ret < 0) {
+   dev_err(>dev, "failed read register (%d)\n", ret);
+   kfree(readbuf);
+   goto exit;
+   }
+
+   

[PATCH 5/7] Support new Alps device that name is T4

2017-09-11 Thread Masaki Ota
From: Masaki Ota 
-Add T4 device code and Product ID
-This device is used on HP EliteBook 1000 series and Zbook Stduio

Signed-off-by: Masaki Ota 
---
 drivers/hid/hid-alps.c | 343 ++---
 drivers/hid/hid-core.c |   3 +-
 drivers/hid/hid-ids.h  |   1 +
 3 files changed, 326 insertions(+), 21 deletions(-)

diff --git a/drivers/hid/hid-alps.c b/drivers/hid/hid-alps.c
index 4c323b58e009..0a6c54fb47c8 100644
--- a/drivers/hid/hid-alps.c
+++ b/drivers/hid/hid-alps.c
@@ -52,8 +52,30 @@
 #define ADDRESS_U1_PAD_BTN 0x00800052
 #define ADDRESS_U1_SP_BTN  0x0080009F
 
+#define T4_INPUT_REPORT_LENsizeof(struct t4_input_report)
+#define T4_FEATURE_REPORT_LEN  T4_INPUT_REPORT_LEN
+#define T4_FEATURE_REPORT_ID   7
+#define T4_CMD_REGISTER_READ   0x08
+#define T4_CMD_REGISTER_WRITE  0x07
+
+#define T4_ADDRESS_BASE0xC2C0
+#define PRM_SYS_CONFIG_1   (T4_ADDRESS_BASE + 0x0002)
+#define T4_PRM_FEED_CONFIG_1   (T4_ADDRESS_BASE + 0x0004)
+#define T4_PRM_FEED_CONFIG_4   (T4_ADDRESS_BASE + 0x001A)
+#define T4_PRM_ID_CONFIG_3 (T4_ADDRESS_BASE + 0x00B0)
+
+
+#define T4_FEEDCFG4_ADVANCED_ABS_ENABLE0x01
+#define T4_I2C_ABS 0x78
+
+#define T4_COUNT_PER_ELECTRODE 256
 #define MAX_TOUCHES5
 
+enum dev_num {
+   U1,
+   T4,
+   UNKNOWN,
+};
 /**
  * struct u1_data
  *
@@ -74,11 +96,12 @@
  * @btn_cnt: number of buttons
  * @sp_btn_cnt: number of stick buttons
  */
-struct u1_dev {
+struct alps_dev {
struct input_dev *input;
struct input_dev *input2;
struct hid_device *hdev;
 
+   enum dev_num dev_type;
u8  max_fingers;
u8  has_sp;
u8  sp_btn_info;
@@ -92,6 +115,145 @@ struct u1_dev {
u32 sp_btn_cnt;
 };
 
+struct t4_contact_data {
+   u8  palm;
+   u8  x_lo;
+   u8  x_hi;
+   u8  y_lo;
+   u8  y_hi;
+};
+
+struct t4_input_report {
+   u8  reportID;
+   u8  numContacts;
+   struct t4_contact_data contact[5];
+   u8  button;
+   u8  track[5];
+   u8  zx[5], zy[5];
+   u8  palmTime[5];
+   u8  kilroy;
+   u16 timeStamp;
+};
+
+static u16 t4_calc_check_sum(u8 *buffer,
+   unsigned long offset, unsigned long length)
+{
+   u16 sum1 = 0xFF, sum2 = 0xFF;
+   unsigned long i = 0;
+
+   if (offset + length >= 50)
+   return 0;
+
+   while (length > 0) {
+   u32 tlen = length > 20 ? 20 : length;
+
+   length -= tlen;
+
+   do {
+   sum1 += buffer[offset + i];
+   sum2 += sum1;
+   i++;
+   } while (--tlen > 0);
+
+   sum1 = (sum1 & 0xFF) + (sum1 >> 8);
+   sum2 = (sum2 & 0xFF) + (sum2 >> 8);
+   }
+
+   sum1 = (sum1 & 0xFF) + (sum1 >> 8);
+   sum2 = (sum2 & 0xFF) + (sum2 >> 8);
+
+   return(sum2 << 8 | sum1);
+}
+
+static int t4_read_write_register(struct hid_device *hdev, u32 address,
+   u8 *read_val, u8 write_val, bool read_flag)
+{
+   int ret;
+   u16 check_sum;
+   u8 *input;
+   u8 *readbuf;
+
+   input = kzalloc(T4_FEATURE_REPORT_LEN, GFP_KERNEL);
+   if (!input)
+   return -ENOMEM;
+
+   input[0] = T4_FEATURE_REPORT_ID;
+   if (read_flag) {
+   input[1] = T4_CMD_REGISTER_READ;
+   input[8] = 0x00;
+   } else {
+   input[1] = T4_CMD_REGISTER_WRITE;
+   input[8] = write_val;
+   }
+   put_unaligned_le32(address, input + 2);
+   input[6] = 1;
+   input[7] = 0;
+
+   /* Calculate the checksum */
+   check_sum = t4_calc_check_sum(input, 1, 8);
+   input[9] = (u8)check_sum;
+   input[10] = (u8)(check_sum >> 8);
+   input[11] = 0;
+
+   ret = hid_hw_raw_request(hdev, T4_FEATURE_REPORT_ID, input,
+   T4_FEATURE_REPORT_LEN,
+   HID_FEATURE_REPORT, HID_REQ_SET_REPORT);
+
+   if (ret < 0) {
+   dev_err(>dev, "failed to read command (%d)\n", ret);
+   goto exit;
+   }
+
+   if (read_flag) {
+   readbuf = kzalloc(T4_FEATURE_REPORT_LEN, GFP_KERNEL);
+   if (!readbuf) {
+   ret = -ENOMEM;
+   goto exit;
+   }
+
+   ret = hid_hw_raw_request(hdev, T4_FEATURE_REPORT_ID, readbuf,
+   T4_FEATURE_REPORT_LEN,
+   HID_FEATURE_REPORT, HID_REQ_GET_REPORT);
+   if (ret < 0) {
+   dev_err(>dev, "failed read register (%d)\n", ret);
+   kfree(readbuf);
+   goto exit;
+   }
+
+   if (*(u32 *)[6] != address) {
+  

[GIT PULL] Thermal management updates for v4.14-rc1

2017-09-11 Thread Zhang Rui
Hi, Linus,

Please pull from
  git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git next

to receive the latest Thermal Management updates for v4.14-rc1 with
top-most commit b32b5e14b4e0d40e06f094d2593b447e00acdf37:

  Merge branches 'thermal-core', 'thermal-soc', 'thermal-intel' and
'const-thermal-zone-structure' into next (2017-09-08 11:20:04 +0800)

on top of commit 16f73eb02d7e1765ccab3d2018e0bd98eb93d973:

  Linux 4.13-rc3 (2017-07-30 12:40:36 -0700)

Specifics:

- Fix resources release in error paths when registering thermal zone.
(Christophe Jaillet)

- Introduce a new thermal driver for on-chip PVT (Process, Voltage and
Temperature) monitoring unit implemented on UniPhier SoCs. This driver
supports temperature monitoring and alert function. (Kunihiko Hayashi)

- Add support for mt2712 chip in the mtk_thermal driver. (Louis Yu)

- Add support for RK3328 SOC in rockchip_thermal driver. (Rocky Hao)

- cleanup a couple of platform thermal drivers to constify
thermal_zone_of_device_ops structures. (Julia Lawall)

- a couple of fixes in int340x and intel_pch_thermal thermal
driver.(Arvind Yadav, Sumeet Pawnikar, Brian Bian, Ed Swierk, Zhang
Rui)

thanks,
rui


Arnd Bergmann (1):
  thermal: fix INTEL_SOC_DTS_IOSF_CORE dependencies

Arvind Yadav (3):
  thermal: int340x: constify attribute_group structures.
  thermal: int340x_thermal: Constify attribute_group structures.
  thermal: intel_pch_thermal: constify pci_device_id.

Brian Bian (1):
  thermal: int3400_thermal: process "thermal table changed" event

Christophe Jaillet (3):
  thermal: core: Add some new helper functions to free resources
  thermal: core: Use the new 'thermal_zone_destroy_device_groups()'
helper function
  thermal: core: Fix resources release in error paths in
thermal_zone_device_register()

Ed Swierk (2):
  thermal: intel_pch_thermal: Read large temp values correctly
  thermal: intel_pch_thermal: Fix enable check on Broadwell-DE

Icenowy Zheng (1):
  thermal: core: fix some format issues on critical shutdown string

Julia Lawall (6):
  thermal: hisilicon: constify thermal_zone_of_device_ops
structures
  thermal: qoriq: constify thermal_zone_of_device_ops structures
  thermal: rcar_gen3_thermal: constify thermal_zone_of_device_ops
structures
  thermal: zx2967: constify thermal_zone_of_device_ops structures
  thermal: exynos: constify thermal_zone_of_device_ops structures
  thermal: bcm2835: constify thermal_zone_of_device_ops structures

Kunihiko Hayashi (2):
  dt-bindings: thermal: add binding documentation for UniPhier
thermal monitor
  thermal: uniphier: add UniPhier thermal driver

Louis Yu (4):
  dt-bindings: thermal: Add binding document for Mediatek thermal
controller
  thermal: mediatek: add Mediatek thermal driver for mt2712
  thermal: mediatek: extend calibration data for mt2712 chip
  thermal: mediatek: minor mtk_thermal.c cleanups

Rocky Hao (2):
  dt-bindings: rockchip-thermal: Support the RK3328 SoC compatible
  thermal: rockchip: Support the RK3328 SOC in thermal driver

Sumeet Pawnikar (1):
  Thermal/int340x: Fix few typos and kernel warn message

Zhang Rui (3):
  Thermal: int3406_thermal: fix thermal sysfs I/F
  Merge branches 'mediatek-mt2712', 'rockchip-rk3328' and
'uniphier-thermal' into thermal-soc
  Merge branches 'thermal-core', 'thermal-soc', 'thermal-intel' and
'const-thermal-zone-structure' into next

 .../bindings/thermal/mediatek-thermal.txt  |   1 +
 .../bindings/thermal/rockchip-thermal.txt  |   1 +
 .../bindings/thermal/uniphier-thermal.txt  |  64 
 drivers/thermal/Kconfig|  12 +-
 drivers/thermal/Makefile   |   1 +
 drivers/thermal/broadcom/bcm2835_thermal.c |   2 +-
 drivers/thermal/hisi_thermal.c |   2 +-
 drivers/thermal/int340x_thermal/acpi_thermal_rel.c |   2 +-
 drivers/thermal/int340x_thermal/acpi_thermal_rel.h |   8 +-
 drivers/thermal/int340x_thermal/int3400_thermal.c  |  43 ++-
 drivers/thermal/int340x_thermal/int3406_thermal.c  |  96 ++
 .../int340x_thermal/processor_thermal_device.c |   2 +-
 drivers/thermal/intel_pch_thermal.c|  12 +-
 drivers/thermal/mtk_thermal.c  |  88 -
 drivers/thermal/qoriq_thermal.c|   2 +-
 drivers/thermal/rcar_gen3_thermal.c|   2 +-
 drivers/thermal/rockchip_thermal.c |  65 
 drivers/thermal/samsung/exynos_tmu.c   |   2 +-
 drivers/thermal/thermal_core.c |  31 +-
 drivers/thermal/thermal_core.h |   1 +
 drivers/thermal/thermal_sysfs.c|  29 ++
 drivers/thermal/uniphier_thermal.c | 384
+
 drivers/thermal/zx2967_thermal.c   |   2 +-
 

[GIT PULL] Thermal management updates for v4.14-rc1

2017-09-11 Thread Zhang Rui
Hi, Linus,

Please pull from
  git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git next

to receive the latest Thermal Management updates for v4.14-rc1 with
top-most commit b32b5e14b4e0d40e06f094d2593b447e00acdf37:

  Merge branches 'thermal-core', 'thermal-soc', 'thermal-intel' and
'const-thermal-zone-structure' into next (2017-09-08 11:20:04 +0800)

on top of commit 16f73eb02d7e1765ccab3d2018e0bd98eb93d973:

  Linux 4.13-rc3 (2017-07-30 12:40:36 -0700)

Specifics:

- Fix resources release in error paths when registering thermal zone.
(Christophe Jaillet)

- Introduce a new thermal driver for on-chip PVT (Process, Voltage and
Temperature) monitoring unit implemented on UniPhier SoCs. This driver
supports temperature monitoring and alert function. (Kunihiko Hayashi)

- Add support for mt2712 chip in the mtk_thermal driver. (Louis Yu)

- Add support for RK3328 SOC in rockchip_thermal driver. (Rocky Hao)

- cleanup a couple of platform thermal drivers to constify
thermal_zone_of_device_ops structures. (Julia Lawall)

- a couple of fixes in int340x and intel_pch_thermal thermal
driver.(Arvind Yadav, Sumeet Pawnikar, Brian Bian, Ed Swierk, Zhang
Rui)

thanks,
rui


Arnd Bergmann (1):
  thermal: fix INTEL_SOC_DTS_IOSF_CORE dependencies

Arvind Yadav (3):
  thermal: int340x: constify attribute_group structures.
  thermal: int340x_thermal: Constify attribute_group structures.
  thermal: intel_pch_thermal: constify pci_device_id.

Brian Bian (1):
  thermal: int3400_thermal: process "thermal table changed" event

Christophe Jaillet (3):
  thermal: core: Add some new helper functions to free resources
  thermal: core: Use the new 'thermal_zone_destroy_device_groups()'
helper function
  thermal: core: Fix resources release in error paths in
thermal_zone_device_register()

Ed Swierk (2):
  thermal: intel_pch_thermal: Read large temp values correctly
  thermal: intel_pch_thermal: Fix enable check on Broadwell-DE

Icenowy Zheng (1):
  thermal: core: fix some format issues on critical shutdown string

Julia Lawall (6):
  thermal: hisilicon: constify thermal_zone_of_device_ops
structures
  thermal: qoriq: constify thermal_zone_of_device_ops structures
  thermal: rcar_gen3_thermal: constify thermal_zone_of_device_ops
structures
  thermal: zx2967: constify thermal_zone_of_device_ops structures
  thermal: exynos: constify thermal_zone_of_device_ops structures
  thermal: bcm2835: constify thermal_zone_of_device_ops structures

Kunihiko Hayashi (2):
  dt-bindings: thermal: add binding documentation for UniPhier
thermal monitor
  thermal: uniphier: add UniPhier thermal driver

Louis Yu (4):
  dt-bindings: thermal: Add binding document for Mediatek thermal
controller
  thermal: mediatek: add Mediatek thermal driver for mt2712
  thermal: mediatek: extend calibration data for mt2712 chip
  thermal: mediatek: minor mtk_thermal.c cleanups

Rocky Hao (2):
  dt-bindings: rockchip-thermal: Support the RK3328 SoC compatible
  thermal: rockchip: Support the RK3328 SOC in thermal driver

Sumeet Pawnikar (1):
  Thermal/int340x: Fix few typos and kernel warn message

Zhang Rui (3):
  Thermal: int3406_thermal: fix thermal sysfs I/F
  Merge branches 'mediatek-mt2712', 'rockchip-rk3328' and
'uniphier-thermal' into thermal-soc
  Merge branches 'thermal-core', 'thermal-soc', 'thermal-intel' and
'const-thermal-zone-structure' into next

 .../bindings/thermal/mediatek-thermal.txt  |   1 +
 .../bindings/thermal/rockchip-thermal.txt  |   1 +
 .../bindings/thermal/uniphier-thermal.txt  |  64 
 drivers/thermal/Kconfig|  12 +-
 drivers/thermal/Makefile   |   1 +
 drivers/thermal/broadcom/bcm2835_thermal.c |   2 +-
 drivers/thermal/hisi_thermal.c |   2 +-
 drivers/thermal/int340x_thermal/acpi_thermal_rel.c |   2 +-
 drivers/thermal/int340x_thermal/acpi_thermal_rel.h |   8 +-
 drivers/thermal/int340x_thermal/int3400_thermal.c  |  43 ++-
 drivers/thermal/int340x_thermal/int3406_thermal.c  |  96 ++
 .../int340x_thermal/processor_thermal_device.c |   2 +-
 drivers/thermal/intel_pch_thermal.c|  12 +-
 drivers/thermal/mtk_thermal.c  |  88 -
 drivers/thermal/qoriq_thermal.c|   2 +-
 drivers/thermal/rcar_gen3_thermal.c|   2 +-
 drivers/thermal/rockchip_thermal.c |  65 
 drivers/thermal/samsung/exynos_tmu.c   |   2 +-
 drivers/thermal/thermal_core.c |  31 +-
 drivers/thermal/thermal_core.h |   1 +
 drivers/thermal/thermal_sysfs.c|  29 ++
 drivers/thermal/uniphier_thermal.c | 384
+
 drivers/thermal/zx2967_thermal.c   |   2 +-
 

[PATCH] Support new Alps HID Touchpad device

2017-09-11 Thread Masaki Ota
Hi, Jiri, Benjamin,

This is the patch for support new Alps HID Touchpad device.
I submitted these patch before, but it was not completed.
So I separate the patch to some parts and release it again. 

Best Regards,
Masaki Ota



[PATCH] Support new Alps HID Touchpad device

2017-09-11 Thread Masaki Ota
Hi, Jiri, Benjamin,

This is the patch for support new Alps HID Touchpad device.
I submitted these patch before, but it was not completed.
So I separate the patch to some parts and release it again. 

Best Regards,
Masaki Ota



[PATCH 0/2] mtd: nand: introduce NAND_ROW_ADDR_3 flag and improve Denali driver

2017-09-11 Thread Masahiro Yamada
Currently, Denali NAND driver always expects 3 row address cycle
devices because the driver init code hard-code the register setting.
I will fix it in 2/2.

Many drivers check chip->chipsize if the third row address cycle
is needed or not.  This is not nice because 32MB, 128MB are
magic numbers.  nand_scan_ident can decide it and provide a
driver-friendly flag.

1/2 is touching verious drivers.
I hope Acked-by from driver maintainers if this change looks good.



Masahiro Yamada (2):
  mtd: nand: introduce NAND_ROW_ADDR_3 flag
  mtd: nand: denali: support two row address cycle devices

 drivers/mtd/nand/atmel/nand-controller.c | 3 +--
 drivers/mtd/nand/au1550nd.c  | 3 +--
 drivers/mtd/nand/denali.c| 4 ++--
 drivers/mtd/nand/diskonchip.c| 3 +--
 drivers/mtd/nand/hisi504_nand.c  | 3 +--
 drivers/mtd/nand/mxc_nand.c  | 3 +--
 drivers/mtd/nand/nand_base.c | 9 +
 drivers/mtd/nand/nuc900_nand.c   | 2 +-
 include/linux/mtd/rawnand.h  | 3 +++
 9 files changed, 16 insertions(+), 17 deletions(-)

-- 
2.7.4



[PATCH 0/2] mtd: nand: introduce NAND_ROW_ADDR_3 flag and improve Denali driver

2017-09-11 Thread Masahiro Yamada
Currently, Denali NAND driver always expects 3 row address cycle
devices because the driver init code hard-code the register setting.
I will fix it in 2/2.

Many drivers check chip->chipsize if the third row address cycle
is needed or not.  This is not nice because 32MB, 128MB are
magic numbers.  nand_scan_ident can decide it and provide a
driver-friendly flag.

1/2 is touching verious drivers.
I hope Acked-by from driver maintainers if this change looks good.



Masahiro Yamada (2):
  mtd: nand: introduce NAND_ROW_ADDR_3 flag
  mtd: nand: denali: support two row address cycle devices

 drivers/mtd/nand/atmel/nand-controller.c | 3 +--
 drivers/mtd/nand/au1550nd.c  | 3 +--
 drivers/mtd/nand/denali.c| 4 ++--
 drivers/mtd/nand/diskonchip.c| 3 +--
 drivers/mtd/nand/hisi504_nand.c  | 3 +--
 drivers/mtd/nand/mxc_nand.c  | 3 +--
 drivers/mtd/nand/nand_base.c | 9 +
 drivers/mtd/nand/nuc900_nand.c   | 2 +-
 include/linux/mtd/rawnand.h  | 3 +++
 9 files changed, 16 insertions(+), 17 deletions(-)

-- 
2.7.4



  1   2   3   4   5   6   7   8   9   10   >