Re: [PATCH 1/1] gpn: drm: fsl_tcon: add missing of_node_put after calling of_parse_phandle

[Stefan Agner]

On 2016-07-04 00:40, Peter Chen wrote:
> of_node_put needs to be called when the device node which is got
> from of_parse_phandle has finished using, but current code only
> calls it at error path, fix it by adding it at correct code path.
> 
> Signed-off-by: Peter Chen 
> ---
>  drivers/gpu/drm/fsl-dcu/fsl_tcon.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/fsl-dcu/fsl_tcon.c
> b/drivers/gpu/drm/fsl-dcu/fsl_tcon.c
> index bbe34f1..bca09ea 100644
> --- a/drivers/gpu/drm/fsl-dcu/fsl_tcon.c
> +++ b/drivers/gpu/drm/fsl-dcu/fsl_tcon.c
> @@ -92,6 +92,7 @@ struct fsl_tcon *fsl_tcon_init(struct device *dev)
>   goto err_node_put;
>   }
>  
> + of_node_put(np);
>   clk_prepare_enable(tcon->ipg_clk);
>  
>   dev_info(dev, "Using TCON in bypass mode\n");

Thanks, applied!

Changed subject prefix using the usual drm/fsl-dcu:...

--
Stefan

Re: [PATCH 1/1] gpn: drm: fsl_tcon: add missing of_node_put after calling of_parse_phandle

[Stefan Agner]

On 2016-07-04 00:40, Peter Chen wrote:
> of_node_put needs to be called when the device node which is got
> from of_parse_phandle has finished using, but current code only
> calls it at error path, fix it by adding it at correct code path.
> 
> Signed-off-by: Peter Chen 
> ---
>  drivers/gpu/drm/fsl-dcu/fsl_tcon.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/fsl-dcu/fsl_tcon.c
> b/drivers/gpu/drm/fsl-dcu/fsl_tcon.c
> index bbe34f1..bca09ea 100644
> --- a/drivers/gpu/drm/fsl-dcu/fsl_tcon.c
> +++ b/drivers/gpu/drm/fsl-dcu/fsl_tcon.c
> @@ -92,6 +92,7 @@ struct fsl_tcon *fsl_tcon_init(struct device *dev)
>   goto err_node_put;
>   }
>  
> + of_node_put(np);
>   clk_prepare_enable(tcon->ipg_clk);
>  
>   dev_info(dev, "Using TCON in bypass mode\n");

Thanks, applied!

Changed subject prefix using the usual drm/fsl-dcu:...

--
Stefan

Re: [PATCH v2 01/11] mm: Implement stack frame object validation

[Josh Poimboeuf]

On Wed, Jul 13, 2016 at 03:04:26PM -0700, Kees Cook wrote:
> On Wed, Jul 13, 2016 at 3:01 PM, Andy Lutomirski  wrote:
> > On Wed, Jul 13, 2016 at 2:55 PM, Kees Cook  wrote:
> >> This creates per-architecture function arch_within_stack_frames() that
> >> should validate if a given object is contained by a kernel stack frame.
> >> Initial implementation is on x86.
> >>
> >> This is based on code from PaX.
> >>
> >
> > This, along with Josh's livepatch work, are two examples of unwinders
> > that matter for correctness instead of just debugging.  ISTM this
> > should just use Josh's code directly once it's been written.
> 
> Do you have URL for Josh's code? I'd love to see what happening there.

The code is actually going to be 100% different next time around, but
FWIW, here's the last attempt:

  
https://lkml.kernel.org/r/4d34d452bf8f85c7d6d5f93db1d3eeb4cba335c7.1461875890.git.jpoim...@redhat.com

In the meantime I've realized the need to rewrite the x86 core stack
walking code to something much more manageable so we don't need all
these unwinders everywhere.  I'll probably post the patches in the next
week or so.  I'll add you to the CC list.

With the new interface I think you'll be able to do something like:

struct unwind_state;

unwind_start(, current, NULL, NULL);
unwind_next_frame();
oldframe = unwind_get_stack_pointer();

unwind_next_frame();
frame = unwind_get_stack_pointer();

do {
if (obj + len <= frame)
return blah;
oldframe = frame;
frame = unwind_get_stack_pointer();

} while (unwind_next_frame();

And then at the end there'll be some (still TBD) way to query whether it
reached the last syscall pt_regs frame, or if it instead encountered a
bogus frame pointer along the way and had to bail early.

-- 
Josh

Re: [PATCH v2 01/11] mm: Implement stack frame object validation

[Josh Poimboeuf]

On Wed, Jul 13, 2016 at 03:04:26PM -0700, Kees Cook wrote:
> On Wed, Jul 13, 2016 at 3:01 PM, Andy Lutomirski  wrote:
> > On Wed, Jul 13, 2016 at 2:55 PM, Kees Cook  wrote:
> >> This creates per-architecture function arch_within_stack_frames() that
> >> should validate if a given object is contained by a kernel stack frame.
> >> Initial implementation is on x86.
> >>
> >> This is based on code from PaX.
> >>
> >
> > This, along with Josh's livepatch work, are two examples of unwinders
> > that matter for correctness instead of just debugging.  ISTM this
> > should just use Josh's code directly once it's been written.
> 
> Do you have URL for Josh's code? I'd love to see what happening there.

The code is actually going to be 100% different next time around, but
FWIW, here's the last attempt:

  
https://lkml.kernel.org/r/4d34d452bf8f85c7d6d5f93db1d3eeb4cba335c7.1461875890.git.jpoim...@redhat.com

In the meantime I've realized the need to rewrite the x86 core stack
walking code to something much more manageable so we don't need all
these unwinders everywhere.  I'll probably post the patches in the next
week or so.  I'll add you to the CC list.

With the new interface I think you'll be able to do something like:

struct unwind_state;

unwind_start(, current, NULL, NULL);
unwind_next_frame();
oldframe = unwind_get_stack_pointer();

unwind_next_frame();
frame = unwind_get_stack_pointer();

do {
if (obj + len <= frame)
return blah;
oldframe = frame;
frame = unwind_get_stack_pointer();

} while (unwind_next_frame();

And then at the end there'll be some (still TBD) way to query whether it
reached the last syscall pt_regs frame, or if it instead encountered a
bogus frame pointer along the way and had to bail early.

-- 
Josh

Re: [PATCH v4 3/5]nbd: make nbd device wait for its users

[Pranay Srivastava]

On Wed, Jul 13, 2016 at 1:24 PM, Markus Pargmann  wrote:
> On Sunday 10 July 2016 21:32:07 Pranay Srivastava wrote:
>> On Sun, Jul 10, 2016 at 6:32 PM, Markus Pargmann  wrote:
>> > On 2016 M06 30, Thu 14:02:03 CEST Pranay Kr. Srivastava wrote:
>> >> When a timeout occurs or a recv fails, then
>> >> instead of abruplty killing nbd block device
>> >> wait for its users to finish.
>> >>
>> >> This is more required when filesystem(s) like
>> >> ext2 or ext3 don't expect their buffer heads to
>> >> disappear while the filesystem is mounted.
>> >>
>> >> Each open of a nbd device is refcounted, while
>> >> the userland program [nbd-client] doing the
>> >> NBD_DO_IT ioctl would now wait for any other users
>> >> of this device before invalidating the nbd device.
>> >>
>> >> A timedout or a disconnected device, if in use, can't
>> >> be used until it has been resetted. The reset happens
>> >> when all tasks having this bdev open closes this bdev.
>> >>
>> >> Signed-off-by: Pranay Kr. Srivastava 
>> >> ---
>> >>  drivers/block/nbd.c | 106
>> >> ++-- 1 file changed, 87
>> >> insertions(+), 19 deletions(-)
>> >>
>> >> diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
>> >> index e362d44..fb56dd2 100644
>> >> --- a/drivers/block/nbd.c
>> >> +++ b/drivers/block/nbd.c
>> >> @@ -72,6 +72,8 @@ struct nbd_device {
>> >>  #endif
>> >>   /* This is specifically for calling sock_shutdown, for now. */
>> >>   struct work_struct ws_shutdown;
>> >> + struct kref users;
>> >> + struct completion user_completion;
>> >>  };
>> >>
>> >>  #if IS_ENABLED(CONFIG_DEBUG_FS)
>> >> @@ -99,6 +101,8 @@ static int max_part;
>> >>  static DEFINE_SPINLOCK(nbd_lock);
>> >>
>> >>  static void nbd_ws_func_shutdown(struct work_struct *);
>> >> +static void nbd_kref_release(struct kref *);
>> >> +static int nbd_size_clear(struct nbd_device *, struct block_device *);
>> >
>> > More function signatures. Why?
>>
>> To avoid code move. But do let me know why is code signature(s)
>> like this are bad , just asking to avoid such things.
>>
>> >
>> >>
>> >>  static inline struct device *nbd_to_dev(struct nbd_device *nbd)
>> >>  {
>> >> @@ -145,11 +149,9 @@ static int nbd_size_set(struct nbd_device *nbd, 
>> >> struct
>> >> block_device *bdev, int blocksize, int nr_blocks)
>> >>  {
>> >>   int ret;
>> >> -
>> >>   ret = set_blocksize(bdev, blocksize);
>> >>   if (ret)
>> >>   return ret;
>> >> -
>> >
>> > Unrelated.
>> >
>> >>   nbd->blksize = blocksize;
>> >>   nbd->bytesize = (loff_t)blocksize * (loff_t)nr_blocks;
>> >>
>> >> @@ -197,6 +199,9 @@ static void nbd_xmit_timeout(unsigned long arg)
>> >>  {
>> >>   struct nbd_device *nbd = (struct nbd_device *)arg;
>> >>
>> >> + if (nbd->timedout)
>> >> + return;
>> >> +
>> >
>> > What does this have to do with the patch?
>>
>> to avoid re-scheduling the work function. Apparently that did
>> cause some trouble with ext4 and 10K dd processes.
>
> Ah interesting. What was the timeout in this scenario?

Not much about 5 or 6 secs. The client was on a VM though on my laptop.
I think it was due to disconnect being set and then kill_bdev called multiple
times. I didn't explored this much as doing the check for this solved the
problem.

I also sent a patch for ext4 as well as that also caused a BUG to be triggered
in fs/buffer.c while the buffer was being marked dirty and in parallel the same
buffer reported an EIO.

>
>>
>> >
>> >>   if (list_empty(>queue_head))
>> >>   return;
>> >>
>> >> @@ -472,8 +477,6 @@ static int nbd_thread_recv(struct nbd_device *nbd,
>> >> struct block_device *bdev) nbd_end_request(nbd, req);
>> >>   }
>> >>
>> >> - nbd_size_clear(nbd, bdev);
>> >> -
>> >>   device_remove_file(disk_to_dev(nbd->disk), _attr_pid);
>> >>
>> >>   nbd->task_recv = NULL;
>> >> @@ -650,12 +653,13 @@ static int nbd_set_socket(struct nbd_device *nbd,
>> >> struct socket *sock) int ret = 0;
>> >>
>> >>   spin_lock(>sock_lock);
>> >> - if (nbd->sock)
>> >> +
>> >> + if (nbd->sock || nbd->timedout)
>> >>   ret = -EBUSY;
>> >
>> > nbd->timedout is already checked in __nbd_ioctl(), no need to check it 
>> > twice.
>> >
>> >>   else
>> >>   nbd->sock = sock;
>> >> - spin_unlock(>sock_lock);
>> >>
>> >> + spin_unlock(>sock_lock);
>> >
>> > random modification.
>> >
>> >>   return ret;
>> >>  }
>> >>
>> >> @@ -670,6 +674,7 @@ static void nbd_reset(struct nbd_device *nbd)
>> >>   nbd->flags = 0;
>> >>   nbd->xmit_timeout = 0;
>> >>   INIT_WORK(>ws_shutdown, nbd_ws_func_shutdown);
>> >> + init_completion(>user_completion);
>> >>   queue_flag_clear_unlocked(QUEUE_FLAG_DISCARD, nbd->disk->queue);
>> >>   del_timer_sync(>timeout_timer);
>> >>  }
>> >> @@ -704,6 +709,9 @@ static void nbd_dev_dbg_close(struct nbd_device *nbd);
>> >>  static int 

Re: [PATCH v4 3/5]nbd: make nbd device wait for its users

[Pranay Srivastava]

On Wed, Jul 13, 2016 at 1:24 PM, Markus Pargmann  wrote:
> On Sunday 10 July 2016 21:32:07 Pranay Srivastava wrote:
>> On Sun, Jul 10, 2016 at 6:32 PM, Markus Pargmann  wrote:
>> > On 2016 M06 30, Thu 14:02:03 CEST Pranay Kr. Srivastava wrote:
>> >> When a timeout occurs or a recv fails, then
>> >> instead of abruplty killing nbd block device
>> >> wait for its users to finish.
>> >>
>> >> This is more required when filesystem(s) like
>> >> ext2 or ext3 don't expect their buffer heads to
>> >> disappear while the filesystem is mounted.
>> >>
>> >> Each open of a nbd device is refcounted, while
>> >> the userland program [nbd-client] doing the
>> >> NBD_DO_IT ioctl would now wait for any other users
>> >> of this device before invalidating the nbd device.
>> >>
>> >> A timedout or a disconnected device, if in use, can't
>> >> be used until it has been resetted. The reset happens
>> >> when all tasks having this bdev open closes this bdev.
>> >>
>> >> Signed-off-by: Pranay Kr. Srivastava 
>> >> ---
>> >>  drivers/block/nbd.c | 106
>> >> ++-- 1 file changed, 87
>> >> insertions(+), 19 deletions(-)
>> >>
>> >> diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
>> >> index e362d44..fb56dd2 100644
>> >> --- a/drivers/block/nbd.c
>> >> +++ b/drivers/block/nbd.c
>> >> @@ -72,6 +72,8 @@ struct nbd_device {
>> >>  #endif
>> >>   /* This is specifically for calling sock_shutdown, for now. */
>> >>   struct work_struct ws_shutdown;
>> >> + struct kref users;
>> >> + struct completion user_completion;
>> >>  };
>> >>
>> >>  #if IS_ENABLED(CONFIG_DEBUG_FS)
>> >> @@ -99,6 +101,8 @@ static int max_part;
>> >>  static DEFINE_SPINLOCK(nbd_lock);
>> >>
>> >>  static void nbd_ws_func_shutdown(struct work_struct *);
>> >> +static void nbd_kref_release(struct kref *);
>> >> +static int nbd_size_clear(struct nbd_device *, struct block_device *);
>> >
>> > More function signatures. Why?
>>
>> To avoid code move. But do let me know why is code signature(s)
>> like this are bad , just asking to avoid such things.
>>
>> >
>> >>
>> >>  static inline struct device *nbd_to_dev(struct nbd_device *nbd)
>> >>  {
>> >> @@ -145,11 +149,9 @@ static int nbd_size_set(struct nbd_device *nbd, 
>> >> struct
>> >> block_device *bdev, int blocksize, int nr_blocks)
>> >>  {
>> >>   int ret;
>> >> -
>> >>   ret = set_blocksize(bdev, blocksize);
>> >>   if (ret)
>> >>   return ret;
>> >> -
>> >
>> > Unrelated.
>> >
>> >>   nbd->blksize = blocksize;
>> >>   nbd->bytesize = (loff_t)blocksize * (loff_t)nr_blocks;
>> >>
>> >> @@ -197,6 +199,9 @@ static void nbd_xmit_timeout(unsigned long arg)
>> >>  {
>> >>   struct nbd_device *nbd = (struct nbd_device *)arg;
>> >>
>> >> + if (nbd->timedout)
>> >> + return;
>> >> +
>> >
>> > What does this have to do with the patch?
>>
>> to avoid re-scheduling the work function. Apparently that did
>> cause some trouble with ext4 and 10K dd processes.
>
> Ah interesting. What was the timeout in this scenario?

Not much about 5 or 6 secs. The client was on a VM though on my laptop.
I think it was due to disconnect being set and then kill_bdev called multiple
times. I didn't explored this much as doing the check for this solved the
problem.

I also sent a patch for ext4 as well as that also caused a BUG to be triggered
in fs/buffer.c while the buffer was being marked dirty and in parallel the same
buffer reported an EIO.

>
>>
>> >
>> >>   if (list_empty(>queue_head))
>> >>   return;
>> >>
>> >> @@ -472,8 +477,6 @@ static int nbd_thread_recv(struct nbd_device *nbd,
>> >> struct block_device *bdev) nbd_end_request(nbd, req);
>> >>   }
>> >>
>> >> - nbd_size_clear(nbd, bdev);
>> >> -
>> >>   device_remove_file(disk_to_dev(nbd->disk), _attr_pid);
>> >>
>> >>   nbd->task_recv = NULL;
>> >> @@ -650,12 +653,13 @@ static int nbd_set_socket(struct nbd_device *nbd,
>> >> struct socket *sock) int ret = 0;
>> >>
>> >>   spin_lock(>sock_lock);
>> >> - if (nbd->sock)
>> >> +
>> >> + if (nbd->sock || nbd->timedout)
>> >>   ret = -EBUSY;
>> >
>> > nbd->timedout is already checked in __nbd_ioctl(), no need to check it 
>> > twice.
>> >
>> >>   else
>> >>   nbd->sock = sock;
>> >> - spin_unlock(>sock_lock);
>> >>
>> >> + spin_unlock(>sock_lock);
>> >
>> > random modification.
>> >
>> >>   return ret;
>> >>  }
>> >>
>> >> @@ -670,6 +674,7 @@ static void nbd_reset(struct nbd_device *nbd)
>> >>   nbd->flags = 0;
>> >>   nbd->xmit_timeout = 0;
>> >>   INIT_WORK(>ws_shutdown, nbd_ws_func_shutdown);
>> >> + init_completion(>user_completion);
>> >>   queue_flag_clear_unlocked(QUEUE_FLAG_DISCARD, nbd->disk->queue);
>> >>   del_timer_sync(>timeout_timer);
>> >>  }
>> >> @@ -704,6 +709,9 @@ static void nbd_dev_dbg_close(struct nbd_device *nbd);
>> >>  static int __nbd_ioctl(struct block_device *bdev, struct nbd_device *nbd,

Re: [PATCH v11 21/22] IB/hns: Kconfig and Makefile for RoCE module

[Leon Romanovsky]

On Sat, Jul 02, 2016 at 05:39:23PM +0800, Lijun Ou wrote:
> This patch added Kconfig and Makefile for building RoCE module.
> 
> Signed-off-by: Wei Hu 
> Signed-off-by: Nenglong Zhao 
> Signed-off-by: Lijun Ou 
> ---
> PATCH v11:
> hns_roce_icm.o -> hns_roce_hem.o
> 
> PATCH v10/v9/v8/v7/v6/v5:
> - No change over the PATCH v4
> 
> PATCH v4:
> This fixes the comments given by Christoph Hellwig over the PATCH v3:
>   Link: https://lkml.org/lkml/2016/3/22/609
> 
> PATCH V3:
> This fixes the comments given by Leon Romanovsky over the PATCH v2:
>   Link: https://lkml.org/lkml/2016/3/20/5
> 
> PATCH v2:
> This fixes the comments given by Leon Romanovsky over the PATCH v1:
>   Link: https://lkml.org/lkml/2016/3/6/94
> Fixes the error tested by kbuild test robot over the PATCH v1:
>   Link: https://lkml.org/lkml/2016/3/4/343
> 
> PATCH v1:
> - The initial patch
> ---
> ---
>  drivers/infiniband/Kconfig |  1 +
>  drivers/infiniband/hw/Makefile |  1 +
>  drivers/infiniband/hw/hns/Kconfig  | 10 ++
>  drivers/infiniband/hw/hns/Makefile |  8 
>  4 files changed, 20 insertions(+)
>  create mode 100644 drivers/infiniband/hw/hns/Kconfig
>  create mode 100644 drivers/infiniband/hw/hns/Makefile
> 
> diff --git a/drivers/infiniband/Kconfig b/drivers/infiniband/Kconfig
> index 2137adf..767f92b 100644
> --- a/drivers/infiniband/Kconfig
> +++ b/drivers/infiniband/Kconfig
> @@ -74,6 +74,7 @@ source "drivers/infiniband/hw/mlx5/Kconfig"
>  source "drivers/infiniband/hw/nes/Kconfig"
>  source "drivers/infiniband/hw/ocrdma/Kconfig"
>  source "drivers/infiniband/hw/usnic/Kconfig"
> +source "drivers/infiniband/hw/hns/Kconfig"
>  
>  source "drivers/infiniband/ulp/ipoib/Kconfig"
>  
> diff --git a/drivers/infiniband/hw/Makefile b/drivers/infiniband/hw/Makefile
> index c0c7cf8..2ad851d 100644
> --- a/drivers/infiniband/hw/Makefile
> +++ b/drivers/infiniband/hw/Makefile
> @@ -9,3 +9,4 @@ obj-$(CONFIG_INFINIBAND_NES)  += nes/
>  obj-$(CONFIG_INFINIBAND_OCRDMA)  += ocrdma/
>  obj-$(CONFIG_INFINIBAND_USNIC)   += usnic/
>  obj-$(CONFIG_INFINIBAND_HFI1)+= hfi1/
> +obj-$(CONFIG_INFINIBAND_HISILICON_HNS)   += hns/

--^^^--
There is no need in HISILICON word here.

> diff --git a/drivers/infiniband/hw/hns/Kconfig 
> b/drivers/infiniband/hw/hns/Kconfig
> new file mode 100644
> index 000..c47c168
> --- /dev/null
> +++ b/drivers/infiniband/hw/hns/Kconfig
> @@ -0,0 +1,10 @@
> +config INFINIBAND_HISILICON_HNS
> + tristate "Hisilicon Hns ROCE Driver"

And you are still inconsistent with the names
Hisilicon/HiSilicon/hisilicon/HISILICON/e.t.c., ROCE/roce/RoCE/e.t.c.


signature.asc
Description: Digital signature

Re: [PATCH v11 21/22] IB/hns: Kconfig and Makefile for RoCE module

[Leon Romanovsky]

On Sat, Jul 02, 2016 at 05:39:23PM +0800, Lijun Ou wrote:
> This patch added Kconfig and Makefile for building RoCE module.
> 
> Signed-off-by: Wei Hu 
> Signed-off-by: Nenglong Zhao 
> Signed-off-by: Lijun Ou 
> ---
> PATCH v11:
> hns_roce_icm.o -> hns_roce_hem.o
> 
> PATCH v10/v9/v8/v7/v6/v5:
> - No change over the PATCH v4
> 
> PATCH v4:
> This fixes the comments given by Christoph Hellwig over the PATCH v3:
>   Link: https://lkml.org/lkml/2016/3/22/609
> 
> PATCH V3:
> This fixes the comments given by Leon Romanovsky over the PATCH v2:
>   Link: https://lkml.org/lkml/2016/3/20/5
> 
> PATCH v2:
> This fixes the comments given by Leon Romanovsky over the PATCH v1:
>   Link: https://lkml.org/lkml/2016/3/6/94
> Fixes the error tested by kbuild test robot over the PATCH v1:
>   Link: https://lkml.org/lkml/2016/3/4/343
> 
> PATCH v1:
> - The initial patch
> ---
> ---
>  drivers/infiniband/Kconfig |  1 +
>  drivers/infiniband/hw/Makefile |  1 +
>  drivers/infiniband/hw/hns/Kconfig  | 10 ++
>  drivers/infiniband/hw/hns/Makefile |  8 
>  4 files changed, 20 insertions(+)
>  create mode 100644 drivers/infiniband/hw/hns/Kconfig
>  create mode 100644 drivers/infiniband/hw/hns/Makefile
> 
> diff --git a/drivers/infiniband/Kconfig b/drivers/infiniband/Kconfig
> index 2137adf..767f92b 100644
> --- a/drivers/infiniband/Kconfig
> +++ b/drivers/infiniband/Kconfig
> @@ -74,6 +74,7 @@ source "drivers/infiniband/hw/mlx5/Kconfig"
>  source "drivers/infiniband/hw/nes/Kconfig"
>  source "drivers/infiniband/hw/ocrdma/Kconfig"
>  source "drivers/infiniband/hw/usnic/Kconfig"
> +source "drivers/infiniband/hw/hns/Kconfig"
>  
>  source "drivers/infiniband/ulp/ipoib/Kconfig"
>  
> diff --git a/drivers/infiniband/hw/Makefile b/drivers/infiniband/hw/Makefile
> index c0c7cf8..2ad851d 100644
> --- a/drivers/infiniband/hw/Makefile
> +++ b/drivers/infiniband/hw/Makefile
> @@ -9,3 +9,4 @@ obj-$(CONFIG_INFINIBAND_NES)  += nes/
>  obj-$(CONFIG_INFINIBAND_OCRDMA)  += ocrdma/
>  obj-$(CONFIG_INFINIBAND_USNIC)   += usnic/
>  obj-$(CONFIG_INFINIBAND_HFI1)+= hfi1/
> +obj-$(CONFIG_INFINIBAND_HISILICON_HNS)   += hns/

--^^^--
There is no need in HISILICON word here.

> diff --git a/drivers/infiniband/hw/hns/Kconfig 
> b/drivers/infiniband/hw/hns/Kconfig
> new file mode 100644
> index 000..c47c168
> --- /dev/null
> +++ b/drivers/infiniband/hw/hns/Kconfig
> @@ -0,0 +1,10 @@
> +config INFINIBAND_HISILICON_HNS
> + tristate "Hisilicon Hns ROCE Driver"

And you are still inconsistent with the names
Hisilicon/HiSilicon/hisilicon/HISILICON/e.t.c., ROCE/roce/RoCE/e.t.c.


signature.asc
Description: Digital signature

Re: [PATCH v4 3/5] nvmem: core: Add consumer API to get nvmem cell from node

[Stefan Agner]

On 2016-07-08 10:23, Srinivas Kandagatla wrote:
> On 08/07/16 17:42, Stefan Agner wrote:
>> On 2016-07-08 08:41, Srinivas Kandagatla wrote:
>>> On 07/07/16 14:48, maitysancha...@gmail.com wrote:
 Hello Srinivas,

 On 16-07-07 1
> 
> ...
> 
>>
>> Our requirement is to be able to pass the soc node pointer and then
>> be able to get a nvmem cell by specifying it's name. So for our case
>
> Why?

 Sorry for not providing the background directly. The patches before this
 series used that approach. In the previous discussions it has been pointed
 out that it is not acceptable to have additional device tree bindings for
 providing data that the driver wants at the SoC node level or to have 
 bindings
 just for the SoC bus driver alone since we aren't really describing the
 hardware.

>>> SOC driver seems to search for an arbitrary node by its name, which is
>>> not a binding and can break anytime in cases If the scope of nvmem
>>> provider is out of soc node or if the nvmem cells are not named as
>>> expected. That looks very fragile.
>>
>> In that case, that just "won't happen" because the soc driver is a very
>> soc specific driver only used for this device tree. We it will always
>> bind to that high level soc node.
>>
>>>
>>> If the soc node is actual consumer of nvmem cells, I see no reason why
>>> we should not use proper nvmem bindings?
>>
>> There is a reason: We don't describe the hardware with it...
>>
>> The cfg0/cfg1 register which Sanchayan needs to read in the soc bus
>> driver are just two register with a unique ID of the SoC. In whatever
> 
> "Unique ID of the SOC" doesn't this mean that its a part of soc hw
> description/configuration/setup?
> 
> Am still not clear why this setup any different to other use cases
> like mac address/calibration data?
> 
> I still feel that this should be described in the DT.
> 
> Rob,
>  What do you think?

[added Rob to "To"]

Rob, can you comment?

--
Stefan

> 
> 
>> driver throughout the system we use that ID (e.g. in a random generator
>> for initialization) we never describe an actual hardware relation... Its
>> just software and how we use that unique ID. The device tree is ment to
>> describe hardware. Hence the NVMEM consumer binding is not suited for
>> such NVMEM cells...
>>
>> By describing the NVMEM cells location in device tree (producer API, the
>> NVMEM cells are in hardware at that location, so using the device tree
>> for that part is fine) and hard coding the NVMEM cell we need in the
>> driver code we don't violate the device tree matra "describe the
>> hardware"...
> 
> IMHO, We should indeed describe the SOC hardware and its relationship
> w.r.t to nvmem provider in device tree. Reasoning being these both are
> some form of IP blocks/hw which depend on each other.
> 
>>
>> Looking-up the nodes direcly is what Rob suggested here:
>> https://lkml.org/lkml/2016/5/23/573
> 
> I did read this, I was not convinced that we should do a direct lookup
> for nvmem cells.
> 
> thanks,
> srini
>>
>>>
>>> Given the fact that the patch is potentially bypassing the nvmem
>>> bindings, am not happy to take it!
>>
>> If you can provide a solution acceptable by the device tree folks and
>> works without this patch, I am happy to do it...
> 
> 
>>
>> Btw, I am not entirely happy with the API name, but did not had a better
>> idea... And we we should probably add a note that the device tree
>> consumer binding is the preferred way to do it.
>>
>> --
>> Stefan
>>
>>
>>>
>>> thanks,
>>> srini
>>>
 For the discussion,
 https://lkml.org/lkml/2016/5/23/573
 https://lkml.org/lkml/2016/5/2/71

 Regards,
 Sanchayan.


>
>> ocotp node has cfg0 and cfg1 which we want but we cannot use existing
>> nvmem consumer API since that requires having the nvmem consumer 
>> properties
>> in the node we are binding to viz. is a direct nvmem consumer.
>>
>> Regards,
>> Sanchayan.
>>
>>>
>>> thanks,
>>> srini

 Parent node can also be the of_node of the main SoC device
 node.

 Signed-off-by: Sanchayan Maity 
 ---
  drivers/nvmem/core.c   | 44 
 +-
  include/linux/nvmem-consumer.h |  1 +
  2 files changed, 32 insertions(+), 13 deletions(-)

 diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
 index 965911d..470abee 100644
 --- a/drivers/nvmem/core.c
 +++ b/drivers/nvmem/core.c
 @@ -743,29 +743,21 @@ static struct nvmem_cell 
 *nvmem_cell_get_from_list(const char *cell_id)

  #if IS_ENABLED(CONFIG_NVMEM) && IS_ENABLED(CONFIG_OF)
  /**
 - * of_nvmem_cell_get() - Get a nvmem cell from given device node and 
 cell id
 + * of_nvmem_cell_get_direct() - Get a nvmem 

Re: [PATCH v4 3/5] nvmem: core: Add consumer API to get nvmem cell from node

[Stefan Agner]

On 2016-07-08 10:23, Srinivas Kandagatla wrote:
> On 08/07/16 17:42, Stefan Agner wrote:
>> On 2016-07-08 08:41, Srinivas Kandagatla wrote:
>>> On 07/07/16 14:48, maitysancha...@gmail.com wrote:
 Hello Srinivas,

 On 16-07-07 1
> 
> ...
> 
>>
>> Our requirement is to be able to pass the soc node pointer and then
>> be able to get a nvmem cell by specifying it's name. So for our case
>
> Why?

 Sorry for not providing the background directly. The patches before this
 series used that approach. In the previous discussions it has been pointed
 out that it is not acceptable to have additional device tree bindings for
 providing data that the driver wants at the SoC node level or to have 
 bindings
 just for the SoC bus driver alone since we aren't really describing the
 hardware.

>>> SOC driver seems to search for an arbitrary node by its name, which is
>>> not a binding and can break anytime in cases If the scope of nvmem
>>> provider is out of soc node or if the nvmem cells are not named as
>>> expected. That looks very fragile.
>>
>> In that case, that just "won't happen" because the soc driver is a very
>> soc specific driver only used for this device tree. We it will always
>> bind to that high level soc node.
>>
>>>
>>> If the soc node is actual consumer of nvmem cells, I see no reason why
>>> we should not use proper nvmem bindings?
>>
>> There is a reason: We don't describe the hardware with it...
>>
>> The cfg0/cfg1 register which Sanchayan needs to read in the soc bus
>> driver are just two register with a unique ID of the SoC. In whatever
> 
> "Unique ID of the SOC" doesn't this mean that its a part of soc hw
> description/configuration/setup?
> 
> Am still not clear why this setup any different to other use cases
> like mac address/calibration data?
> 
> I still feel that this should be described in the DT.
> 
> Rob,
>  What do you think?

[added Rob to "To"]

Rob, can you comment?

--
Stefan

> 
> 
>> driver throughout the system we use that ID (e.g. in a random generator
>> for initialization) we never describe an actual hardware relation... Its
>> just software and how we use that unique ID. The device tree is ment to
>> describe hardware. Hence the NVMEM consumer binding is not suited for
>> such NVMEM cells...
>>
>> By describing the NVMEM cells location in device tree (producer API, the
>> NVMEM cells are in hardware at that location, so using the device tree
>> for that part is fine) and hard coding the NVMEM cell we need in the
>> driver code we don't violate the device tree matra "describe the
>> hardware"...
> 
> IMHO, We should indeed describe the SOC hardware and its relationship
> w.r.t to nvmem provider in device tree. Reasoning being these both are
> some form of IP blocks/hw which depend on each other.
> 
>>
>> Looking-up the nodes direcly is what Rob suggested here:
>> https://lkml.org/lkml/2016/5/23/573
> 
> I did read this, I was not convinced that we should do a direct lookup
> for nvmem cells.
> 
> thanks,
> srini
>>
>>>
>>> Given the fact that the patch is potentially bypassing the nvmem
>>> bindings, am not happy to take it!
>>
>> If you can provide a solution acceptable by the device tree folks and
>> works without this patch, I am happy to do it...
> 
> 
>>
>> Btw, I am not entirely happy with the API name, but did not had a better
>> idea... And we we should probably add a note that the device tree
>> consumer binding is the preferred way to do it.
>>
>> --
>> Stefan
>>
>>
>>>
>>> thanks,
>>> srini
>>>
 For the discussion,
 https://lkml.org/lkml/2016/5/23/573
 https://lkml.org/lkml/2016/5/2/71

 Regards,
 Sanchayan.


>
>> ocotp node has cfg0 and cfg1 which we want but we cannot use existing
>> nvmem consumer API since that requires having the nvmem consumer 
>> properties
>> in the node we are binding to viz. is a direct nvmem consumer.
>>
>> Regards,
>> Sanchayan.
>>
>>>
>>> thanks,
>>> srini

 Parent node can also be the of_node of the main SoC device
 node.

 Signed-off-by: Sanchayan Maity 
 ---
  drivers/nvmem/core.c   | 44 
 +-
  include/linux/nvmem-consumer.h |  1 +
  2 files changed, 32 insertions(+), 13 deletions(-)

 diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
 index 965911d..470abee 100644
 --- a/drivers/nvmem/core.c
 +++ b/drivers/nvmem/core.c
 @@ -743,29 +743,21 @@ static struct nvmem_cell 
 *nvmem_cell_get_from_list(const char *cell_id)

  #if IS_ENABLED(CONFIG_NVMEM) && IS_ENABLED(CONFIG_OF)
  /**
 - * of_nvmem_cell_get() - Get a nvmem cell from given device node and 
 cell id
 + * of_nvmem_cell_get_direct() - Get a nvmem cell from given device 

Re: [PATCH 2/2] proc: Add /proc//timerslack_ns interface

[Arjan van de Ven]

On 7/13/2016 8:39 PM, Kees Cook wrote:


So I worry I'm a bit stuck here. For general systems, CAP_SYS_NICE is
too low a level of privilege  to set a tasks timerslack, but
apparently CAP_SYS_PTRACE is too high a privilege for Android's
system_server to require just to set a tasks timerslack value.

So I wanted to ask again if we might consider backing this down to
CAP_SYS_NICE, or if we can instead introduce a new CAP_SYS_TIMERSLACK
or something to provide the needed in-between capability level.


Adding new capabilities appears to not really be viable (lots of
threads about this...)

I think the original CAP_SYS_NICE should be fine. A malicious
CAP_SYS_NICE process can do plenty of insane things, I don't feel like
the timer slack adds to any realistic risks.


if the result is really as bad as you describe, then that is worse than
the impact of this being CAP_SYS_NICE, and thus SYS_TRACE is maybe the
purist answer, but not the pragmatic best answer; certainly I don't want
to make the overall system security worse.

I wonder how much you want to set the slack; one of the options (and I don't
know how this will work in the code, if it's horrible don't do it)
is to limit how much slack CAP_SYS_NICE can set (say, 50 or 100 msec, e.g. in 
the order
of a "time slice" or two if Linux had time slices, similar to what nice would 
do)
while CAP_SYS_TRACE  can set the full 4 seconds.
If it makes the code horrible, don't do it and just do SYS_NICE.

Re: [PATCH 2/2] proc: Add /proc//timerslack_ns interface

[Arjan van de Ven]

On 7/13/2016 8:39 PM, Kees Cook wrote:


So I worry I'm a bit stuck here. For general systems, CAP_SYS_NICE is
too low a level of privilege  to set a tasks timerslack, but
apparently CAP_SYS_PTRACE is too high a privilege for Android's
system_server to require just to set a tasks timerslack value.

So I wanted to ask again if we might consider backing this down to
CAP_SYS_NICE, or if we can instead introduce a new CAP_SYS_TIMERSLACK
or something to provide the needed in-between capability level.


Adding new capabilities appears to not really be viable (lots of
threads about this...)

I think the original CAP_SYS_NICE should be fine. A malicious
CAP_SYS_NICE process can do plenty of insane things, I don't feel like
the timer slack adds to any realistic risks.


if the result is really as bad as you describe, then that is worse than
the impact of this being CAP_SYS_NICE, and thus SYS_TRACE is maybe the
purist answer, but not the pragmatic best answer; certainly I don't want
to make the overall system security worse.

I wonder how much you want to set the slack; one of the options (and I don't
know how this will work in the code, if it's horrible don't do it)
is to limit how much slack CAP_SYS_NICE can set (say, 50 or 100 msec, e.g. in 
the order
of a "time slice" or two if Linux had time slices, similar to what nice would 
do)
while CAP_SYS_TRACE  can set the full 4 seconds.
If it makes the code horrible, don't do it and just do SYS_NICE.

[PATCH kernel] powerpc/mm/iommu: Put pages on process exit

[Alexey Kardashevskiy]

At the moment VFIO IOMMU SPAPR v2 driver pins all guest RAM pages when
the userspace starts using VFIO. When the userspace process finishes,
all the pinned pages need to be put; this is done as a part of
the userspace memory context (MM) destruction which happens on
the very last mmdrop().

This approach has a problem that a MM of the userspace process
may live longer than the userspace process itself as kernel threads
usually execute on a MM of a userspace process which was runnning
on a CPU where the kernel thread was scheduled to. If this happened,
the MM remains referenced until this exact kernel thread wakes up again
and releases the very last reference to the MM, on an idle system this
can take even hours.

This fixes the issue by moving mm_iommu_cleanup() (the helper which puts
pages) from destroy_context() (called on the last mmdrop()) to
the arch-specific arch_exit_mmap() hook (called on the last mmput()).
mmdrop() decrements the mm->mm_count which is a total reference number;
mmput() decrements the mm->mm_users which is a number of user spaces and
this is actually the counter we want to watch for here.

Cc: David Gibson 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Balbir Singh 
Cc: Nick Piggin 
Signed-off-by: Alexey Kardashevskiy 
---
 arch/powerpc/include/asm/mmu_context.h | 3 +++
 arch/powerpc/mm/mmu_context_book3s64.c | 4 
 2 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/include/asm/mmu_context.h 
b/arch/powerpc/include/asm/mmu_context.h
index 9d2cd0c..24b590d 100644
--- a/arch/powerpc/include/asm/mmu_context.h
+++ b/arch/powerpc/include/asm/mmu_context.h
@@ -138,6 +138,9 @@ static inline void arch_dup_mmap(struct mm_struct *oldmm,
 
 static inline void arch_exit_mmap(struct mm_struct *mm)
 {
+#ifdef CONFIG_SPAPR_TCE_IOMMU
+   mm_iommu_cleanup(>context);
+#endif
 }
 
 static inline void arch_unmap(struct mm_struct *mm,
diff --git a/arch/powerpc/mm/mmu_context_book3s64.c 
b/arch/powerpc/mm/mmu_context_book3s64.c
index 1962..aaeba74 100644
--- a/arch/powerpc/mm/mmu_context_book3s64.c
+++ b/arch/powerpc/mm/mmu_context_book3s64.c
@@ -159,10 +159,6 @@ static inline void destroy_pagetable_page(struct mm_struct 
*mm)
 
 void destroy_context(struct mm_struct *mm)
 {
-#ifdef CONFIG_SPAPR_TCE_IOMMU
-   mm_iommu_cleanup(>context);
-#endif
-
 #ifdef CONFIG_PPC_ICSWX
drop_cop(mm->context.acop, mm);
kfree(mm->context.cop_lockp);
-- 
2.5.0.rc3

[PATCH kernel] powerpc/mm/iommu: Put pages on process exit

[Alexey Kardashevskiy]

At the moment VFIO IOMMU SPAPR v2 driver pins all guest RAM pages when
the userspace starts using VFIO. When the userspace process finishes,
all the pinned pages need to be put; this is done as a part of
the userspace memory context (MM) destruction which happens on
the very last mmdrop().

This approach has a problem that a MM of the userspace process
may live longer than the userspace process itself as kernel threads
usually execute on a MM of a userspace process which was runnning
on a CPU where the kernel thread was scheduled to. If this happened,
the MM remains referenced until this exact kernel thread wakes up again
and releases the very last reference to the MM, on an idle system this
can take even hours.

This fixes the issue by moving mm_iommu_cleanup() (the helper which puts
pages) from destroy_context() (called on the last mmdrop()) to
the arch-specific arch_exit_mmap() hook (called on the last mmput()).
mmdrop() decrements the mm->mm_count which is a total reference number;
mmput() decrements the mm->mm_users which is a number of user spaces and
this is actually the counter we want to watch for here.

Cc: David Gibson 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Balbir Singh 
Cc: Nick Piggin 
Signed-off-by: Alexey Kardashevskiy 
---
 arch/powerpc/include/asm/mmu_context.h | 3 +++
 arch/powerpc/mm/mmu_context_book3s64.c | 4 
 2 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/include/asm/mmu_context.h 
b/arch/powerpc/include/asm/mmu_context.h
index 9d2cd0c..24b590d 100644
--- a/arch/powerpc/include/asm/mmu_context.h
+++ b/arch/powerpc/include/asm/mmu_context.h
@@ -138,6 +138,9 @@ static inline void arch_dup_mmap(struct mm_struct *oldmm,
 
 static inline void arch_exit_mmap(struct mm_struct *mm)
 {
+#ifdef CONFIG_SPAPR_TCE_IOMMU
+   mm_iommu_cleanup(>context);
+#endif
 }
 
 static inline void arch_unmap(struct mm_struct *mm,
diff --git a/arch/powerpc/mm/mmu_context_book3s64.c 
b/arch/powerpc/mm/mmu_context_book3s64.c
index 1962..aaeba74 100644
--- a/arch/powerpc/mm/mmu_context_book3s64.c
+++ b/arch/powerpc/mm/mmu_context_book3s64.c
@@ -159,10 +159,6 @@ static inline void destroy_pagetable_page(struct mm_struct 
*mm)
 
 void destroy_context(struct mm_struct *mm)
 {
-#ifdef CONFIG_SPAPR_TCE_IOMMU
-   mm_iommu_cleanup(>context);
-#endif
-
 #ifdef CONFIG_PPC_ICSWX
drop_cop(mm->context.acop, mm);
kfree(mm->context.cop_lockp);
-- 
2.5.0.rc3

Re: [PATCH v11 00/22] Add HiSilicon RoCE driver

[Leon Romanovsky]

On Thu, Jul 14, 2016 at 11:43:59AM +0800, oulijun wrote:
> 在 2016/7/2 17:39, Lijun Ou 写道:
> > 
> Hi, Doug & Sean Hefty & Hal Rosenstock
> "Hello, I understand that maintainer is dealing with lots of patches not just 
> mine. Also, I could not see any further review comments from the community.
>  I also understand that I should not resend the patch-set again unless I am 
> sure my patch-set is lost.
>  I was just wondering what should I do in the current circumstance where my 
> PATCH" has not activity.
>  I am not sure if this has been accepted or how much I need to wait to resend 
> it (if ever). Please guide, I am new to open-source and learning from people 
> like you. Thanks a lot :)

You was asked numerous times to clean the mess in your TO/CC fields.
Most of the people have nothing to do with your submission.
Understanding who is the RDMA maintainer will help you a lot (hint: it
is one of three in your opening sentence). Another request from you which
you successfully ignored, was to stop reply with whole email,
but reply with relevant part only.

Ignoring community rules is a good way to be ignored back.

BTW, you don't need to resend patches, please follow after patchwork status
https://patchwork.kernel.org/project/linux-rdma/list/?submitter=157841=1

> 
> Thanks
> Lijun Ou
> 
> 
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


signature.asc
Description: Digital signature

Re: [PATCH v11 00/22] Add HiSilicon RoCE driver

[Leon Romanovsky]

On Thu, Jul 14, 2016 at 11:43:59AM +0800, oulijun wrote:
> 在 2016/7/2 17:39, Lijun Ou 写道:
> > 
> Hi, Doug & Sean Hefty & Hal Rosenstock
> "Hello, I understand that maintainer is dealing with lots of patches not just 
> mine. Also, I could not see any further review comments from the community.
>  I also understand that I should not resend the patch-set again unless I am 
> sure my patch-set is lost.
>  I was just wondering what should I do in the current circumstance where my 
> PATCH" has not activity.
>  I am not sure if this has been accepted or how much I need to wait to resend 
> it (if ever). Please guide, I am new to open-source and learning from people 
> like you. Thanks a lot :)

You was asked numerous times to clean the mess in your TO/CC fields.
Most of the people have nothing to do with your submission.
Understanding who is the RDMA maintainer will help you a lot (hint: it
is one of three in your opening sentence). Another request from you which
you successfully ignored, was to stop reply with whole email,
but reply with relevant part only.

Ignoring community rules is a good way to be ignored back.

BTW, you don't need to resend patches, please follow after patchwork status
https://patchwork.kernel.org/project/linux-rdma/list/?submitter=157841=1

> 
> Thanks
> Lijun Ou
> 
> 
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


signature.asc
Description: Digital signature

Re: [PATCH 08/31] mm, vmscan: simplify the logic deciding whether kswapd sleeps

[Joonsoo Kim]

On Fri, Jul 08, 2016 at 11:11:47AM +0100, Mel Gorman wrote:
> On Fri, Jul 08, 2016 at 11:44:47AM +0900, Joonsoo Kim wrote:
> > > > > @@ -3390,12 +3386,24 @@ static int kswapd(void *p)
> > > > >* We can speed up thawing tasks if we don't call 
> > > > > balance_pgdat
> > > > >* after returning from the refrigerator
> > > > >*/
> > > > > - if (!ret) {
> > > > > - trace_mm_vmscan_kswapd_wake(pgdat->node_id, 
> > > > > order);
> > > > > + if (ret)
> > > > > + continue;
> > > > >  
> > > > > - /* return value ignored until next patch */
> > > > > - balance_pgdat(pgdat, order, classzone_idx);
> > > > > - }
> > > > > + /*
> > > > > +  * Reclaim begins at the requested order but if a 
> > > > > high-order
> > > > > +  * reclaim fails then kswapd falls back to reclaiming 
> > > > > for
> > > > > +  * order-0. If that happens, kswapd will consider 
> > > > > sleeping
> > > > > +  * for the order it finished reclaiming at 
> > > > > (reclaim_order)
> > > > > +  * but kcompactd is woken to compact for the original
> > > > > +  * request (alloc_order).
> > > > > +  */
> > > > > + trace_mm_vmscan_kswapd_wake(pgdat->node_id, 
> > > > > alloc_order);
> > > > > + reclaim_order = balance_pgdat(pgdat, alloc_order, 
> > > > > classzone_idx);
> > > > > + if (reclaim_order < alloc_order)
> > > > > + goto kswapd_try_sleep;
> > > > 
> > > > This 'goto' would cause kswapd to sleep prematurely. We need to check
> > > > *new* pgdat->kswapd_order and classzone_idx even in this case.
> > > > 
> > > 
> > > It only matters if the next request coming is also high-order requests but
> > > one thing that needs to be avoided is kswapd staying awake periods of time
> > > constantly reclaiming for high-order pages. This is why the check means
> > > "If we reclaimed for high-order and failed, then consider sleeping now".
> > > If allocations still require it, they direct reclaim instead.
> > 
> > But, assume that next request is zone-constrained allocation. We need
> > to balance memory for it but kswapd would skip it.
> > 
> 
> Then it'll also be woken up again in the very near future as the
> zone-constrained allocation. If the zone is at the min watermark, then
> it'll have direct reclaimed but between min and low, it'll be a simple
> wakeup.
> 
> The premature sleep, wakeup with new requests logic was a complete mess.
> However, what I did do is remove the -1 handling of kswapd_classzone_idx
> handling and the goto full-sleep. In the event of a premature wakeup,
> it'll recheck for wakeups and if none has occured, it'll use the old
> classzone information.
> 
> Note that it will *not* use the original allocation order if it's a
> premature sleep. This is because it's known that high-order reclaim
> failed in the near past and restarting it has a high risk of
> overreclaiming.
> 
> > > > And, I'd like to know why max() is used for classzone_idx rather than
> > > > min()? I think that kswapd should balance the lowest zone requested.
> > > > 
> > > 
> > > If there are two allocation requests -- one zone-constraned and the other
> > > zone-unconstrained, it does not make sense to have kswapd skip the pages
> > > usable for the zone-unconstrained and waste a load of CPU. You could
> > 
> > I agree that, in this case, it's not good to skip the pages usable
> > for the zone-unconstrained request. But, what I am concerned is that
> > kswapd stop reclaim prematurely in the view of zone-constrained
> > requestor.
> 
> It doesn't stop reclaiming for the lower zones. It's reclaiming the LRU
> for the whole node that may or may not have lower zone pages at the end
> of the LRU. If it does, then the allocation request will be satisfied.
> If it does not, then kswapd will think the node is balanced and get
> rewoken to do a zone-constrained reclaim pass.

If zone-constrained request could go direct reclaim pass, there would
be no problem. But, please assume that request is zone-constrained
without __GFP_DIRECT_RECLAIM which is common for some device driver
implementation. And, please assume one more thing that this request
always comes with zone-unconstrained allocation request. In this case,
your max() logic will set kswapd_classzone_idx to highest zone index
and re-worken kswapd would not balance for low zone again. In the end,
zone-constrained allocation request without __GFP_DIRECT_RECLAIM could
fail.

Thanks.

Re: [PATCH 08/31] mm, vmscan: simplify the logic deciding whether kswapd sleeps

[Joonsoo Kim]

On Fri, Jul 08, 2016 at 11:11:47AM +0100, Mel Gorman wrote:
> On Fri, Jul 08, 2016 at 11:44:47AM +0900, Joonsoo Kim wrote:
> > > > > @@ -3390,12 +3386,24 @@ static int kswapd(void *p)
> > > > >* We can speed up thawing tasks if we don't call 
> > > > > balance_pgdat
> > > > >* after returning from the refrigerator
> > > > >*/
> > > > > - if (!ret) {
> > > > > - trace_mm_vmscan_kswapd_wake(pgdat->node_id, 
> > > > > order);
> > > > > + if (ret)
> > > > > + continue;
> > > > >  
> > > > > - /* return value ignored until next patch */
> > > > > - balance_pgdat(pgdat, order, classzone_idx);
> > > > > - }
> > > > > + /*
> > > > > +  * Reclaim begins at the requested order but if a 
> > > > > high-order
> > > > > +  * reclaim fails then kswapd falls back to reclaiming 
> > > > > for
> > > > > +  * order-0. If that happens, kswapd will consider 
> > > > > sleeping
> > > > > +  * for the order it finished reclaiming at 
> > > > > (reclaim_order)
> > > > > +  * but kcompactd is woken to compact for the original
> > > > > +  * request (alloc_order).
> > > > > +  */
> > > > > + trace_mm_vmscan_kswapd_wake(pgdat->node_id, 
> > > > > alloc_order);
> > > > > + reclaim_order = balance_pgdat(pgdat, alloc_order, 
> > > > > classzone_idx);
> > > > > + if (reclaim_order < alloc_order)
> > > > > + goto kswapd_try_sleep;
> > > > 
> > > > This 'goto' would cause kswapd to sleep prematurely. We need to check
> > > > *new* pgdat->kswapd_order and classzone_idx even in this case.
> > > > 
> > > 
> > > It only matters if the next request coming is also high-order requests but
> > > one thing that needs to be avoided is kswapd staying awake periods of time
> > > constantly reclaiming for high-order pages. This is why the check means
> > > "If we reclaimed for high-order and failed, then consider sleeping now".
> > > If allocations still require it, they direct reclaim instead.
> > 
> > But, assume that next request is zone-constrained allocation. We need
> > to balance memory for it but kswapd would skip it.
> > 
> 
> Then it'll also be woken up again in the very near future as the
> zone-constrained allocation. If the zone is at the min watermark, then
> it'll have direct reclaimed but between min and low, it'll be a simple
> wakeup.
> 
> The premature sleep, wakeup with new requests logic was a complete mess.
> However, what I did do is remove the -1 handling of kswapd_classzone_idx
> handling and the goto full-sleep. In the event of a premature wakeup,
> it'll recheck for wakeups and if none has occured, it'll use the old
> classzone information.
> 
> Note that it will *not* use the original allocation order if it's a
> premature sleep. This is because it's known that high-order reclaim
> failed in the near past and restarting it has a high risk of
> overreclaiming.
> 
> > > > And, I'd like to know why max() is used for classzone_idx rather than
> > > > min()? I think that kswapd should balance the lowest zone requested.
> > > > 
> > > 
> > > If there are two allocation requests -- one zone-constraned and the other
> > > zone-unconstrained, it does not make sense to have kswapd skip the pages
> > > usable for the zone-unconstrained and waste a load of CPU. You could
> > 
> > I agree that, in this case, it's not good to skip the pages usable
> > for the zone-unconstrained request. But, what I am concerned is that
> > kswapd stop reclaim prematurely in the view of zone-constrained
> > requestor.
> 
> It doesn't stop reclaiming for the lower zones. It's reclaiming the LRU
> for the whole node that may or may not have lower zone pages at the end
> of the LRU. If it does, then the allocation request will be satisfied.
> If it does not, then kswapd will think the node is balanced and get
> rewoken to do a zone-constrained reclaim pass.

If zone-constrained request could go direct reclaim pass, there would
be no problem. But, please assume that request is zone-constrained
without __GFP_DIRECT_RECLAIM which is common for some device driver
implementation. And, please assume one more thing that this request
always comes with zone-unconstrained allocation request. In this case,
your max() logic will set kswapd_classzone_idx to highest zone index
and re-worken kswapd would not balance for low zone again. In the end,
zone-constrained allocation request without __GFP_DIRECT_RECLAIM could
fail.

Thanks.

Re: [RFC PATCH v2] clk: move check of CLK_SET_RATE_GATE flag to clk_propagate_rate_change()

[Jiada Wang]

Hello Michael

On 07/13/2016 07:29 AM, Michael Turquette wrote:

Quoting jiada_w...@mentor.com (2016-07-10 22:33:28)

From: Jiada Wang 

Previously CLK_SET_RATE_GATE flag is only checked in clk_set_rate()
which only ensures the clock being called by clk_set_rate() won't
change rate when it has been prepared if CLK_SET_RATE_GATE flag is set.
But a clk_set_rate() request may propagate rate change to these clocks
from the requested clock's topmost parent clock to all its offsprings,
when any one of these clocks has CLK_SET_RATE_GATE flag set
and it has been prepared, the clk_set_rate() request should fail.

This patch moves check of CLK_SET_RATE_GATE flag to
clk_propagate_rate_change() to ensure all affected clocks will
be checked if their rate will be changed after clk_set_rate().

Signed-off-by: Jiada Wang 
---


What's different in version 2? It's tradition to put a little version
changelog here, below the "---" line and above the "diff --git a/..."
line.


version 2 resolves the following kernel warning
"
   drivers/clk/clk.c: In function 'clk_propagate_rate_change':
>> drivers/clk/clk.c:1441:3: warning: return makes pointer from integer 
without a cast

  return -EBUSY;
  ^
"
I forgot to add a changelog in v2 patch, sorry for the confusion caused.

Thanks,
Jiada

Regards,
Mike


  drivers/clk/clk.c |6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 820a939..2f930c8 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -1437,6 +1437,9 @@ static struct clk_core *clk_propagate_rate_change(struct 
clk_core *core,
 if (core->rate == core->new_rate)
 return NULL;

+   if ((core->flags & CLK_SET_RATE_GATE) && core->prepare_count)
+   return core;
+
 if (core->notifier_count) {
 ret = __clk_notify(core, event, core->rate, core->new_rate);
 if (ret & NOTIFY_STOP_MASK)
@@ -1571,9 +1574,6 @@ static int clk_core_set_rate_nolock(struct clk_core *core,
 if (rate == clk_core_get_rate_nolock(core))
 return 0;

-   if ((core->flags & CLK_SET_RATE_GATE) && core->prepare_count)
-   return -EBUSY;
-
 /* calculate new rates and get the topmost changed clock */
 top = clk_calc_new_rates(core, rate);
 if (!top)
--
1.7.9.5

Re: [RFC PATCH v2] clk: move check of CLK_SET_RATE_GATE flag to clk_propagate_rate_change()

[Jiada Wang]

Hello Michael

On 07/13/2016 07:29 AM, Michael Turquette wrote:

Quoting jiada_w...@mentor.com (2016-07-10 22:33:28)

From: Jiada Wang 

Previously CLK_SET_RATE_GATE flag is only checked in clk_set_rate()
which only ensures the clock being called by clk_set_rate() won't
change rate when it has been prepared if CLK_SET_RATE_GATE flag is set.
But a clk_set_rate() request may propagate rate change to these clocks
from the requested clock's topmost parent clock to all its offsprings,
when any one of these clocks has CLK_SET_RATE_GATE flag set
and it has been prepared, the clk_set_rate() request should fail.

This patch moves check of CLK_SET_RATE_GATE flag to
clk_propagate_rate_change() to ensure all affected clocks will
be checked if their rate will be changed after clk_set_rate().

Signed-off-by: Jiada Wang 
---


What's different in version 2? It's tradition to put a little version
changelog here, below the "---" line and above the "diff --git a/..."
line.


version 2 resolves the following kernel warning
"
   drivers/clk/clk.c: In function 'clk_propagate_rate_change':
>> drivers/clk/clk.c:1441:3: warning: return makes pointer from integer 
without a cast

  return -EBUSY;
  ^
"
I forgot to add a changelog in v2 patch, sorry for the confusion caused.

Thanks,
Jiada

Regards,
Mike


  drivers/clk/clk.c |6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 820a939..2f930c8 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -1437,6 +1437,9 @@ static struct clk_core *clk_propagate_rate_change(struct 
clk_core *core,
 if (core->rate == core->new_rate)
 return NULL;

+   if ((core->flags & CLK_SET_RATE_GATE) && core->prepare_count)
+   return core;
+
 if (core->notifier_count) {
 ret = __clk_notify(core, event, core->rate, core->new_rate);
 if (ret & NOTIFY_STOP_MASK)
@@ -1571,9 +1574,6 @@ static int clk_core_set_rate_nolock(struct clk_core *core,
 if (rate == clk_core_get_rate_nolock(core))
 return 0;

-   if ((core->flags & CLK_SET_RATE_GATE) && core->prepare_count)
-   return -EBUSY;
-
 /* calculate new rates and get the topmost changed clock */
 top = clk_calc_new_rates(core, rate);
 if (!top)
--
1.7.9.5

Re: [PATCH] qla2xxx: setup data needed in ISR before setting up the ISR

[Martin K. Petersen]

> "Johannes" == Johannes Thumshirn  writes:

Johannes> qla2xxx first calls request_irq() and then does the setup of
Johannes> the queue entry data needed in the interrupt handlers in when
Johannes> using MSI-X. This could lead to a NULL pointer dereference
Johannes> when an IRQ fires between the request_irq() call and the
Johannes> assignment of the qentry data structure to the
rsp-> msix field. A possible case for such a race would be in the kdump
Johannes> case when the HBA's IRQs are still enabled but the driver is
Johannes> undergoing a new initialisation and thus is not aware of
Johannes> already activated IRQs in the HBA.

Qlogic folks: Please review!

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH] qla2xxx: setup data needed in ISR before setting up the ISR

[Martin K. Petersen]

> "Johannes" == Johannes Thumshirn  writes:

Johannes> qla2xxx first calls request_irq() and then does the setup of
Johannes> the queue entry data needed in the interrupt handlers in when
Johannes> using MSI-X. This could lead to a NULL pointer dereference
Johannes> when an IRQ fires between the request_irq() call and the
Johannes> assignment of the qentry data structure to the
rsp-> msix field. A possible case for such a race would be in the kdump
Johannes> case when the HBA's IRQs are still enabled but the driver is
Johannes> undergoing a new initialisation and thus is not aware of
Johannes> already activated IRQs in the HBA.

Qlogic folks: Please review!

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: linux-next: build warnings after merge of the tip tree

[Stephen Rothwell]

Hi all,

On Thu, 14 Jul 2016 13:37:29 +1000 Stephen Rothwell  
wrote:
>
> After merging the tip tree, today's linux-next build (powerpc64le perf)
> produced these warnings:
> 
> Warning: tools/include/uapi/linux/bpf.h differs from kernel
> Warning: tools/arch/x86/include/asm/disabled-features.h differs from kernel
> Warning: tools/arch/x86/include/asm/required-features.h differs from kernel
> Warning: tools/arch/x86/include/asm/cpufeatures.h differs from kernel
> 
> Introduced by commits
> 
>   7d7d1bf1d1da ("perf bench: Copy kernel files needed to build mem{cpy,set} 
> x86_64 benchmarks")
>   971e827bffef ("tools lib bpf: Copy bpf.h and bpf_common.h from the kernel")

The kvm tree has introduced a few more:

Warning: tools/arch/s390/include/uapi/asm/kvm.h
Warning: tools/arch/s390/include/uapi/asm/sie.h

-- 
Cheers,
Stephen Rothwell

Re: linux-next: build warnings after merge of the tip tree

[Stephen Rothwell]

Hi all,

On Thu, 14 Jul 2016 13:37:29 +1000 Stephen Rothwell  
wrote:
>
> After merging the tip tree, today's linux-next build (powerpc64le perf)
> produced these warnings:
> 
> Warning: tools/include/uapi/linux/bpf.h differs from kernel
> Warning: tools/arch/x86/include/asm/disabled-features.h differs from kernel
> Warning: tools/arch/x86/include/asm/required-features.h differs from kernel
> Warning: tools/arch/x86/include/asm/cpufeatures.h differs from kernel
> 
> Introduced by commits
> 
>   7d7d1bf1d1da ("perf bench: Copy kernel files needed to build mem{cpy,set} 
> x86_64 benchmarks")
>   971e827bffef ("tools lib bpf: Copy bpf.h and bpf_common.h from the kernel")

The kvm tree has introduced a few more:

Warning: tools/arch/s390/include/uapi/asm/kvm.h
Warning: tools/arch/s390/include/uapi/asm/sie.h

-- 
Cheers,
Stephen Rothwell

[PATCH v4 4/4] drm/rockchip: analogix_dp: implement PSR function

[Yakir Yang]

Alway enable the PSR function for Rockchip analogix_dp driver. If panel
don't support PSR, then the core analogix_dp would ignore this setting.

Signed-off-by: Yakir Yang 
---
Changes in v4:
- Return 'void' instead of 'int' in analogix_dp_psr_set(). (Sean)
- Pull the 10ms delay time out into a #define. (Sean)
- Improved the code of analogix_dp_psr_work(). (Sean)
- Indented with spaces for new numbers in rockchip_dp_device struct. (Stéphane, 
reviewed at Google gerrit)

[https://chromium-review.googlesource.com/#/c/349085/33/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c@83]

Changes in v3:
- split the common psr logic into a seperate driver, make this to a
  simple sub-psr device driver.

Changes in v2:
- remove vblank notify out (Daniel)
- create a psr_active() callback in vop data struct.

 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 57 +
 1 file changed, 57 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c 
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index e81e19a..aa916f4 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -32,6 +32,7 @@
 #include 
 
 #include "rockchip_drm_drv.h"
+#include "rockchip_drm_psr.h"
 #include "rockchip_drm_vop.h"
 
 #define RK3288_GRF_SOC_CON60x25c
@@ -41,6 +42,9 @@
 
 #define HIWORD_UPDATE(val, mask)   (val | (mask) << 16)
 
+#define PSR_SET_DELAY_TIME msecs_to_jiffies(10)
+#define PSR_WAIT_LINE_FLAG_TIMEOUT_MS  100
+
 #define to_dp(nm)  container_of(nm, struct rockchip_dp_device, nm)
 
 /**
@@ -68,11 +72,55 @@ struct rockchip_dp_device {
struct regmap*grf;
struct reset_control *rst;
 
+   struct delayed_work  psr_work;
+   unsigned int psr_state;
+
const struct rockchip_dp_chip_data *data;
 
struct analogix_dp_plat_data plat_data;
 };
 
+static void analogix_dp_psr_set(struct drm_encoder *encoder, bool enabled)
+{
+   struct rockchip_dp_device *dp = to_dp(encoder);
+
+   dev_dbg(dp->dev, "%s PSR...\n", enabled ? "Entry" : "Exit");
+
+   if (enabled)
+   dp->psr_state = EDP_VSC_PSR_STATE_ACTIVE;
+   else
+   dp->psr_state = ~EDP_VSC_PSR_STATE_ACTIVE;
+
+   schedule_delayed_work(>psr_work, PSR_SET_DELAY_TIME);
+}
+
+static void analogix_dp_psr_work(struct work_struct *work)
+{
+   struct rockchip_dp_device *dp =
+   container_of(work, typeof(*dp), psr_work.work);
+   struct drm_crtc *crtc = dp->encoder.crtc;
+   int psr_state = dp->psr_state;
+   int vact_end;
+   int ret;
+
+   if (!crtc)
+   return;
+
+   vact_end = crtc->mode.vtotal - crtc->mode.vsync_start + 
crtc->mode.vdisplay;
+
+   ret = rockchip_drm_wait_line_flag(dp->encoder.crtc, vact_end,
+ PSR_WAIT_LINE_FLAG_TIMEOUT_MS);
+   if (ret) {
+   dev_err(dp->dev, "line flag interrupt did not arrive\n");
+   return;
+   }
+
+   if (psr_state == EDP_VSC_PSR_STATE_ACTIVE)
+   analogix_dp_enable_psr(dp->dev);
+   else
+   analogix_dp_disable_psr(dp->dev);
+}
+
 static int rockchip_dp_pre_init(struct rockchip_dp_device *dp)
 {
reset_control_assert(dp->rst);
@@ -340,12 +388,21 @@ static int rockchip_dp_bind(struct device *dev, struct 
device *master,
dp->plat_data.power_off = rockchip_dp_powerdown;
dp->plat_data.get_modes = rockchip_dp_get_modes;
 
+   dp->psr_state = ~EDP_VSC_PSR_STATE_ACTIVE;
+   INIT_DELAYED_WORK(>psr_work, analogix_dp_psr_work);
+
+   rockchip_drm_psr_register(>encoder, analogix_dp_psr_set);
+
return analogix_dp_bind(dev, dp->drm_dev, >plat_data);
 }
 
 static void rockchip_dp_unbind(struct device *dev, struct device *master,
   void *data)
 {
+   struct rockchip_dp_device *dp = dev_get_drvdata(dev);
+
+   rockchip_drm_psr_unregister(>encoder);
+
return analogix_dp_unbind(dev, master, data);
 }
 
-- 
1.9.1

[PATCH v4 2/4] drm/rockchip: add an common abstracted PSR driver

[Yakir Yang]

The PSR driver have exported four symbols for specific device driver:
- rockchip_drm_psr_register()
- rockchip_drm_psr_unregister()
- rockchip_drm_psr_enable()
- rockchip_drm_psr_disable()
- rockchip_drm_psr_flush()

Encoder driver should call the register/unregister interfaces to hook
itself into common PSR driver, encoder have implement the 'psr_set'
callback which use the set PSR state in hardware side.

Crtc driver would call the enable/disable interfaces when vblank is
enable/disable, after that the common PSR driver would call the encoder
registered callback to set the PSR state.

Fb driver would call the flush interface in 'fb->dirty' callback, this
helper function would force all PSR enabled encoders to exit from PSR
for 3 seconds.

Signed-off-by: Yakir Yang 
---
Changes in v4:
- Tuck the global "psr_list" & "psr_list_mutex" in struct rockchip_drm_private. 
(Sean)
- Move the access of "psr->state" under "psr->state_mutex"'s protect. (Sean)
- Let "psr->state = PSR_FLUSH" under "psr->state_mutex"'s protect. (Sean)
- Collect psr_enable() and psr_disable() into psr_set_state()
- s/5\ second/PSR_FLUSH_TIMEOUT/ (Sean)
- Flush the psr callback in vop_crtc_disable(). (Stéphane, reviewed in Google 
gerrit)

[https://chromium-review.googlesource.com/#/c/349084/6/drivers/gpu/drm/rockchip/rockchip_drm_vop.c@475]
- Add the missing file head with license. (Stéphane, reviewed in Google gerrit)

[https://chromium-review.googlesource.com/#/c/357563/1/drivers/gpu/drm/rockchip/rockchip_drm_psr.h@3]

Changes in v3:
- split the psr flow into an common abstracted PSR driver
- implement the 'fb->dirty' callback function (Daniel)
- avoid to use notify to acqiure for vact event (Daniel)
- remove psr_active() callback which introduce in v2

Changes in v2: None

 drivers/gpu/drm/rockchip/Makefile   |   2 +-
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c |   4 +
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h |   3 +
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c  |  12 ++
 drivers/gpu/drm/rockchip/rockchip_drm_psr.c | 223 
 drivers/gpu/drm/rockchip/rockchip_drm_psr.h |  26 
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  29 
 7 files changed, 298 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_psr.c
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_psr.h

diff --git a/drivers/gpu/drm/rockchip/Makefile 
b/drivers/gpu/drm/rockchip/Makefile
index 05d0713..9746365 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -3,7 +3,7 @@
 # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
 
 rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o \
-   rockchip_drm_gem.o rockchip_drm_vop.o
+   rockchip_drm_gem.o rockchip_drm_psr.o rockchip_drm_vop.o
 rockchipdrm-$(CONFIG_DRM_FBDEV_EMULATION) += rockchip_drm_fbdev.o
 
 obj-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index d665fb0..26c12b3 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -156,6 +156,9 @@ static int rockchip_drm_bind(struct device *dev)
 
drm_dev->dev_private = private;
 
+   INIT_LIST_HEAD(>psr_list);
+   mutex_init(>psr_list_mutex);
+
drm_mode_config_init(drm_dev);
 
rockchip_drm_mode_config_init(drm_dev);
@@ -218,6 +221,7 @@ static int rockchip_drm_bind(struct device *dev)
 
if (is_support_iommu)
arm_iommu_release_mapping(mapping);
+
return 0;
 err_fbdev_fini:
rockchip_drm_fbdev_fini(drm_dev);
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
index 239b830..9c34c9e 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
@@ -61,6 +61,9 @@ struct rockchip_drm_private {
struct drm_gem_object *fbdev_bo;
const struct rockchip_crtc_funcs *crtc_funcs[ROCKCHIP_MAX_CRTC];
struct drm_atomic_state *state;
+
+   struct list_head psr_list;
+   struct mutex psr_list_mutex;
 };
 
 int rockchip_register_crtc_funcs(struct drm_crtc *crtc,
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
index 20f12bc..36afd9c 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
@@ -21,6 +21,7 @@
 
 #include "rockchip_drm_drv.h"
 #include "rockchip_drm_gem.h"
+#include "rockchip_drm_psr.h"
 
 #define to_rockchip_fb(x) container_of(x, struct rockchip_drm_fb, fb)
 
@@ -66,9 +67,20 @@ static int rockchip_drm_fb_create_handle(struct 
drm_framebuffer *fb,
 rockchip_fb->obj[0], handle);
 }
 
+static int rockchip_drm_fb_dirty(struct drm_framebuffer *fb,
+struct drm_file *file,

[PATCH v4 4/4] drm/rockchip: analogix_dp: implement PSR function

[Yakir Yang]

Alway enable the PSR function for Rockchip analogix_dp driver. If panel
don't support PSR, then the core analogix_dp would ignore this setting.

Signed-off-by: Yakir Yang 
---
Changes in v4:
- Return 'void' instead of 'int' in analogix_dp_psr_set(). (Sean)
- Pull the 10ms delay time out into a #define. (Sean)
- Improved the code of analogix_dp_psr_work(). (Sean)
- Indented with spaces for new numbers in rockchip_dp_device struct. (Stéphane, 
reviewed at Google gerrit)

[https://chromium-review.googlesource.com/#/c/349085/33/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c@83]

Changes in v3:
- split the common psr logic into a seperate driver, make this to a
  simple sub-psr device driver.

Changes in v2:
- remove vblank notify out (Daniel)
- create a psr_active() callback in vop data struct.

 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 57 +
 1 file changed, 57 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c 
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index e81e19a..aa916f4 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -32,6 +32,7 @@
 #include 
 
 #include "rockchip_drm_drv.h"
+#include "rockchip_drm_psr.h"
 #include "rockchip_drm_vop.h"
 
 #define RK3288_GRF_SOC_CON60x25c
@@ -41,6 +42,9 @@
 
 #define HIWORD_UPDATE(val, mask)   (val | (mask) << 16)
 
+#define PSR_SET_DELAY_TIME msecs_to_jiffies(10)
+#define PSR_WAIT_LINE_FLAG_TIMEOUT_MS  100
+
 #define to_dp(nm)  container_of(nm, struct rockchip_dp_device, nm)
 
 /**
@@ -68,11 +72,55 @@ struct rockchip_dp_device {
struct regmap*grf;
struct reset_control *rst;
 
+   struct delayed_work  psr_work;
+   unsigned int psr_state;
+
const struct rockchip_dp_chip_data *data;
 
struct analogix_dp_plat_data plat_data;
 };
 
+static void analogix_dp_psr_set(struct drm_encoder *encoder, bool enabled)
+{
+   struct rockchip_dp_device *dp = to_dp(encoder);
+
+   dev_dbg(dp->dev, "%s PSR...\n", enabled ? "Entry" : "Exit");
+
+   if (enabled)
+   dp->psr_state = EDP_VSC_PSR_STATE_ACTIVE;
+   else
+   dp->psr_state = ~EDP_VSC_PSR_STATE_ACTIVE;
+
+   schedule_delayed_work(>psr_work, PSR_SET_DELAY_TIME);
+}
+
+static void analogix_dp_psr_work(struct work_struct *work)
+{
+   struct rockchip_dp_device *dp =
+   container_of(work, typeof(*dp), psr_work.work);
+   struct drm_crtc *crtc = dp->encoder.crtc;
+   int psr_state = dp->psr_state;
+   int vact_end;
+   int ret;
+
+   if (!crtc)
+   return;
+
+   vact_end = crtc->mode.vtotal - crtc->mode.vsync_start + 
crtc->mode.vdisplay;
+
+   ret = rockchip_drm_wait_line_flag(dp->encoder.crtc, vact_end,
+ PSR_WAIT_LINE_FLAG_TIMEOUT_MS);
+   if (ret) {
+   dev_err(dp->dev, "line flag interrupt did not arrive\n");
+   return;
+   }
+
+   if (psr_state == EDP_VSC_PSR_STATE_ACTIVE)
+   analogix_dp_enable_psr(dp->dev);
+   else
+   analogix_dp_disable_psr(dp->dev);
+}
+
 static int rockchip_dp_pre_init(struct rockchip_dp_device *dp)
 {
reset_control_assert(dp->rst);
@@ -340,12 +388,21 @@ static int rockchip_dp_bind(struct device *dev, struct 
device *master,
dp->plat_data.power_off = rockchip_dp_powerdown;
dp->plat_data.get_modes = rockchip_dp_get_modes;
 
+   dp->psr_state = ~EDP_VSC_PSR_STATE_ACTIVE;
+   INIT_DELAYED_WORK(>psr_work, analogix_dp_psr_work);
+
+   rockchip_drm_psr_register(>encoder, analogix_dp_psr_set);
+
return analogix_dp_bind(dev, dp->drm_dev, >plat_data);
 }
 
 static void rockchip_dp_unbind(struct device *dev, struct device *master,
   void *data)
 {
+   struct rockchip_dp_device *dp = dev_get_drvdata(dev);
+
+   rockchip_drm_psr_unregister(>encoder);
+
return analogix_dp_unbind(dev, master, data);
 }
 
-- 
1.9.1

[PATCH v4 2/4] drm/rockchip: add an common abstracted PSR driver

[Yakir Yang]

The PSR driver have exported four symbols for specific device driver:
- rockchip_drm_psr_register()
- rockchip_drm_psr_unregister()
- rockchip_drm_psr_enable()
- rockchip_drm_psr_disable()
- rockchip_drm_psr_flush()

Encoder driver should call the register/unregister interfaces to hook
itself into common PSR driver, encoder have implement the 'psr_set'
callback which use the set PSR state in hardware side.

Crtc driver would call the enable/disable interfaces when vblank is
enable/disable, after that the common PSR driver would call the encoder
registered callback to set the PSR state.

Fb driver would call the flush interface in 'fb->dirty' callback, this
helper function would force all PSR enabled encoders to exit from PSR
for 3 seconds.

Signed-off-by: Yakir Yang 
---
Changes in v4:
- Tuck the global "psr_list" & "psr_list_mutex" in struct rockchip_drm_private. 
(Sean)
- Move the access of "psr->state" under "psr->state_mutex"'s protect. (Sean)
- Let "psr->state = PSR_FLUSH" under "psr->state_mutex"'s protect. (Sean)
- Collect psr_enable() and psr_disable() into psr_set_state()
- s/5\ second/PSR_FLUSH_TIMEOUT/ (Sean)
- Flush the psr callback in vop_crtc_disable(). (Stéphane, reviewed in Google 
gerrit)

[https://chromium-review.googlesource.com/#/c/349084/6/drivers/gpu/drm/rockchip/rockchip_drm_vop.c@475]
- Add the missing file head with license. (Stéphane, reviewed in Google gerrit)

[https://chromium-review.googlesource.com/#/c/357563/1/drivers/gpu/drm/rockchip/rockchip_drm_psr.h@3]

Changes in v3:
- split the psr flow into an common abstracted PSR driver
- implement the 'fb->dirty' callback function (Daniel)
- avoid to use notify to acqiure for vact event (Daniel)
- remove psr_active() callback which introduce in v2

Changes in v2: None

 drivers/gpu/drm/rockchip/Makefile   |   2 +-
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c |   4 +
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h |   3 +
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c  |  12 ++
 drivers/gpu/drm/rockchip/rockchip_drm_psr.c | 223 
 drivers/gpu/drm/rockchip/rockchip_drm_psr.h |  26 
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  29 
 7 files changed, 298 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_psr.c
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_psr.h

diff --git a/drivers/gpu/drm/rockchip/Makefile 
b/drivers/gpu/drm/rockchip/Makefile
index 05d0713..9746365 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -3,7 +3,7 @@
 # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
 
 rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o \
-   rockchip_drm_gem.o rockchip_drm_vop.o
+   rockchip_drm_gem.o rockchip_drm_psr.o rockchip_drm_vop.o
 rockchipdrm-$(CONFIG_DRM_FBDEV_EMULATION) += rockchip_drm_fbdev.o
 
 obj-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index d665fb0..26c12b3 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -156,6 +156,9 @@ static int rockchip_drm_bind(struct device *dev)
 
drm_dev->dev_private = private;
 
+   INIT_LIST_HEAD(>psr_list);
+   mutex_init(>psr_list_mutex);
+
drm_mode_config_init(drm_dev);
 
rockchip_drm_mode_config_init(drm_dev);
@@ -218,6 +221,7 @@ static int rockchip_drm_bind(struct device *dev)
 
if (is_support_iommu)
arm_iommu_release_mapping(mapping);
+
return 0;
 err_fbdev_fini:
rockchip_drm_fbdev_fini(drm_dev);
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
index 239b830..9c34c9e 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
@@ -61,6 +61,9 @@ struct rockchip_drm_private {
struct drm_gem_object *fbdev_bo;
const struct rockchip_crtc_funcs *crtc_funcs[ROCKCHIP_MAX_CRTC];
struct drm_atomic_state *state;
+
+   struct list_head psr_list;
+   struct mutex psr_list_mutex;
 };
 
 int rockchip_register_crtc_funcs(struct drm_crtc *crtc,
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
index 20f12bc..36afd9c 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
@@ -21,6 +21,7 @@
 
 #include "rockchip_drm_drv.h"
 #include "rockchip_drm_gem.h"
+#include "rockchip_drm_psr.h"
 
 #define to_rockchip_fb(x) container_of(x, struct rockchip_drm_fb, fb)
 
@@ -66,9 +67,20 @@ static int rockchip_drm_fb_create_handle(struct 
drm_framebuffer *fb,
 rockchip_fb->obj[0], handle);
 }
 
+static int rockchip_drm_fb_dirty(struct drm_framebuffer *fb,
+struct drm_file *file,
+ 

[PATCH v4 3/4] drm/bridge: analogix_dp: add the PSR function support

[Yakir Yang]

The full name of PSR is Panel Self Refresh, panel device could refresh
itself with the hardware framebuffer in panel, this would make lots of
sense to save the power consumption.

This patch have exported two symbols for platform driver to implement
the PSR function in hardware side:
- analogix_dp_active_psr()
- analogix_dp_inactive_psr()

Signed-off-by: Yakir Yang 
---
Changes in v4:
- Downgrade the PSR version print message to debug level. (Sean)
- Return 'void' instead of 'int' in analogix_dp_enable_sink_psr(). (Sean)
- Delete the unused read dpcd operations in analogix_dp_enable_sink_psr(). 
(Sean)
- Delete the arbitrary usleep_range in analogix_dp_enable_psr_crc. (Sean).
- Clean up the hardcoded values in analogix_dp_send_psr_spd(). (Sean)
- Rename "active/inactive" to "enable/disable". (Sean, Dominik)
- Keep set the PSR_VID_CRC_FLUSH gate in analogix_dp_enable_psr_crc().

Changes in v3:
- split analogix_dp_enable_psr(), make it more clearly
analogix_dp_detect_sink_psr()
analogix_dp_enable_sink_psr()
- remove some nosie register setting comments

Changes in v2:
- introduce in v2, splite the common Analogix DP changes out

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 60 ++
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |  4 ++
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  | 49 ++
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h  | 28 ++
 include/drm/bridge/analogix_dp.h   |  3 ++
 5 files changed, 144 insertions(+)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 32715da..1fec91a 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -97,6 +97,62 @@ static int analogix_dp_detect_hpd(struct analogix_dp_device 
*dp)
return 0;
 }
 
+int analogix_dp_enable_psr(struct device *dev)
+{
+   struct analogix_dp_device *dp = dev_get_drvdata(dev);
+
+   if (!dp->psr_support)
+   return -EINVAL;
+
+   analogix_dp_send_psr_spd(dp, EDP_VSC_PSR_STATE_ACTIVE |
+EDP_VSC_PSR_CRC_VALUES_VALID);
+   return 0;
+}
+EXPORT_SYMBOL_GPL(analogix_dp_enable_psr);
+
+int analogix_dp_disable_psr(struct device *dev)
+{
+   struct analogix_dp_device *dp = dev_get_drvdata(dev);
+
+   if (!dp->psr_support)
+   return -EINVAL;
+
+   analogix_dp_send_psr_spd(dp, 0);
+   return 0;
+}
+EXPORT_SYMBOL_GPL(analogix_dp_disable_psr);
+
+static bool analogix_dp_detect_sink_psr(struct analogix_dp_device *dp)
+{
+   unsigned char psr_version;
+
+   analogix_dp_read_byte_from_dpcd(dp, DP_PSR_SUPPORT, _version);
+   dev_dbg(dp->dev, "Panel PSR version : %x\n", psr_version);
+
+   return (psr_version & DP_PSR_IS_SUPPORTED) ? true : false;
+}
+
+static void analogix_dp_enable_sink_psr(struct analogix_dp_device *dp)
+{
+   unsigned char psr_en;
+
+   /* Disable psr function */
+   analogix_dp_read_byte_from_dpcd(dp, DP_PSR_EN_CFG, _en);
+   psr_en &= ~DP_PSR_ENABLE;
+   analogix_dp_write_byte_to_dpcd(dp, DP_PSR_EN_CFG, psr_en);
+
+   /* Main-Link transmitter remains active during PSR active states */
+   psr_en = DP_PSR_MAIN_LINK_ACTIVE | DP_PSR_CRC_VERIFICATION;
+   analogix_dp_write_byte_to_dpcd(dp, DP_PSR_EN_CFG, psr_en);
+
+   /* Enable psr function */
+   psr_en = DP_PSR_ENABLE | DP_PSR_MAIN_LINK_ACTIVE |
+DP_PSR_CRC_VERIFICATION;
+   analogix_dp_write_byte_to_dpcd(dp, DP_PSR_EN_CFG, psr_en);
+
+   analogix_dp_enable_psr_crc(dp);
+}
+
 static unsigned char analogix_dp_calc_edid_check_sum(unsigned char *edid_data)
 {
int i;
@@ -921,6 +977,10 @@ static void analogix_dp_commit(struct analogix_dp_device 
*dp)
 
/* Enable video */
analogix_dp_start_video(dp);
+
+   dp->psr_support = analogix_dp_detect_sink_psr(dp);
+   if (dp->psr_support)
+   analogix_dp_enable_sink_psr(dp);
 }
 
 int analogix_dp_get_modes(struct drm_connector *connector)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
index b456380..6ca5dde 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -177,6 +177,7 @@ struct analogix_dp_device {
int hpd_gpio;
boolforce_hpd;
unsigned char   edid[EDID_BLOCK_LENGTH * 2];
+   boolpsr_support;
 
struct analogix_dp_plat_data *plat_data;
 };
@@ -278,4 +279,7 @@ int analogix_dp_is_video_stream_on(struct 
analogix_dp_device *dp);
 void analogix_dp_config_video_slave_mode(struct analogix_dp_device *dp);
 void analogix_dp_enable_scrambling(struct analogix_dp_device *dp);
 void analogix_dp_disable_scrambling(struct analogix_dp_device *dp);
+void 

[PATCH v4 3/4] drm/bridge: analogix_dp: add the PSR function support

[Yakir Yang]

The full name of PSR is Panel Self Refresh, panel device could refresh
itself with the hardware framebuffer in panel, this would make lots of
sense to save the power consumption.

This patch have exported two symbols for platform driver to implement
the PSR function in hardware side:
- analogix_dp_active_psr()
- analogix_dp_inactive_psr()

Signed-off-by: Yakir Yang 
---
Changes in v4:
- Downgrade the PSR version print message to debug level. (Sean)
- Return 'void' instead of 'int' in analogix_dp_enable_sink_psr(). (Sean)
- Delete the unused read dpcd operations in analogix_dp_enable_sink_psr(). 
(Sean)
- Delete the arbitrary usleep_range in analogix_dp_enable_psr_crc. (Sean).
- Clean up the hardcoded values in analogix_dp_send_psr_spd(). (Sean)
- Rename "active/inactive" to "enable/disable". (Sean, Dominik)
- Keep set the PSR_VID_CRC_FLUSH gate in analogix_dp_enable_psr_crc().

Changes in v3:
- split analogix_dp_enable_psr(), make it more clearly
analogix_dp_detect_sink_psr()
analogix_dp_enable_sink_psr()
- remove some nosie register setting comments

Changes in v2:
- introduce in v2, splite the common Analogix DP changes out

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 60 ++
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |  4 ++
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  | 49 ++
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h  | 28 ++
 include/drm/bridge/analogix_dp.h   |  3 ++
 5 files changed, 144 insertions(+)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 32715da..1fec91a 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -97,6 +97,62 @@ static int analogix_dp_detect_hpd(struct analogix_dp_device 
*dp)
return 0;
 }
 
+int analogix_dp_enable_psr(struct device *dev)
+{
+   struct analogix_dp_device *dp = dev_get_drvdata(dev);
+
+   if (!dp->psr_support)
+   return -EINVAL;
+
+   analogix_dp_send_psr_spd(dp, EDP_VSC_PSR_STATE_ACTIVE |
+EDP_VSC_PSR_CRC_VALUES_VALID);
+   return 0;
+}
+EXPORT_SYMBOL_GPL(analogix_dp_enable_psr);
+
+int analogix_dp_disable_psr(struct device *dev)
+{
+   struct analogix_dp_device *dp = dev_get_drvdata(dev);
+
+   if (!dp->psr_support)
+   return -EINVAL;
+
+   analogix_dp_send_psr_spd(dp, 0);
+   return 0;
+}
+EXPORT_SYMBOL_GPL(analogix_dp_disable_psr);
+
+static bool analogix_dp_detect_sink_psr(struct analogix_dp_device *dp)
+{
+   unsigned char psr_version;
+
+   analogix_dp_read_byte_from_dpcd(dp, DP_PSR_SUPPORT, _version);
+   dev_dbg(dp->dev, "Panel PSR version : %x\n", psr_version);
+
+   return (psr_version & DP_PSR_IS_SUPPORTED) ? true : false;
+}
+
+static void analogix_dp_enable_sink_psr(struct analogix_dp_device *dp)
+{
+   unsigned char psr_en;
+
+   /* Disable psr function */
+   analogix_dp_read_byte_from_dpcd(dp, DP_PSR_EN_CFG, _en);
+   psr_en &= ~DP_PSR_ENABLE;
+   analogix_dp_write_byte_to_dpcd(dp, DP_PSR_EN_CFG, psr_en);
+
+   /* Main-Link transmitter remains active during PSR active states */
+   psr_en = DP_PSR_MAIN_LINK_ACTIVE | DP_PSR_CRC_VERIFICATION;
+   analogix_dp_write_byte_to_dpcd(dp, DP_PSR_EN_CFG, psr_en);
+
+   /* Enable psr function */
+   psr_en = DP_PSR_ENABLE | DP_PSR_MAIN_LINK_ACTIVE |
+DP_PSR_CRC_VERIFICATION;
+   analogix_dp_write_byte_to_dpcd(dp, DP_PSR_EN_CFG, psr_en);
+
+   analogix_dp_enable_psr_crc(dp);
+}
+
 static unsigned char analogix_dp_calc_edid_check_sum(unsigned char *edid_data)
 {
int i;
@@ -921,6 +977,10 @@ static void analogix_dp_commit(struct analogix_dp_device 
*dp)
 
/* Enable video */
analogix_dp_start_video(dp);
+
+   dp->psr_support = analogix_dp_detect_sink_psr(dp);
+   if (dp->psr_support)
+   analogix_dp_enable_sink_psr(dp);
 }
 
 int analogix_dp_get_modes(struct drm_connector *connector)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
index b456380..6ca5dde 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -177,6 +177,7 @@ struct analogix_dp_device {
int hpd_gpio;
boolforce_hpd;
unsigned char   edid[EDID_BLOCK_LENGTH * 2];
+   boolpsr_support;
 
struct analogix_dp_plat_data *plat_data;
 };
@@ -278,4 +279,7 @@ int analogix_dp_is_video_stream_on(struct 
analogix_dp_device *dp);
 void analogix_dp_config_video_slave_mode(struct analogix_dp_device *dp);
 void analogix_dp_enable_scrambling(struct analogix_dp_device *dp);
 void analogix_dp_disable_scrambling(struct analogix_dp_device *dp);
+void 

[PATCH v4 0/4] Add PSR function support for Analogix/Rockchip DP

[Yakir Yang]

The full name of PSR is Panel Self Refresh, panel device could refresh
itself with the hardware framebuffer in panel, this would make a lots
of sense to save the power consumption.

This v3 version have splited an common PSR driver for Rockchip, which is
biggest changes from v2.

This thread is based on Mark's RK3399 VOP thread[0] and my RK3399 eDP
thread[1].

[0]: https://patchwork.kernel.org/patch/8886041/
[1]: https://patchwork.kernel.org/patch/9204497/


Changes in v4:
- Avoid the weird behavior in rockchip_drm_wait_line_flag(). (Sean)
- Make line_flag_num_x to an array. (Sean)
- Remove the unused vop_cfg_done() in vop_line_flag_irq_enable(). (Stephane, 
reviewed in Google gerrit)

[https://chromium-review.googlesource.com/#/c/349084/33/drivers/gpu/drm/rockchip/rockchip_drm_vop.c@466]
- Tuck the global "psr_list" & "psr_list_mutex" in struct rockchip_drm_private. 
(Sean)
- Move the access of "psr->state" under "psr->state_mutex"'s protect. (Sean)
- Let "psr->state = PSR_FLUSH" under "psr->state_mutex"'s protect. (Sean)
- Collect psr_enable() and psr_disable() into psr_set_state()
- s/5\ second/PSR_FLUSH_TIMEOUT/ (Sean)
- Flush the psr callback in vop_crtc_disable(). (Stéphane, reviewed in Google 
gerrit)

[https://chromium-review.googlesource.com/#/c/349084/6/drivers/gpu/drm/rockchip/rockchip_drm_vop.c@475]
- Add the missing file head with license. (Stéphane, reviewed in Google gerrit)

[https://chromium-review.googlesource.com/#/c/357563/1/drivers/gpu/drm/rockchip/rockchip_drm_psr.h@3]
- Downgrade the PSR version print message to debug level. (Sean)
- Return 'void' instead of 'int' in analogix_dp_enable_sink_psr(). (Sean)
- Delete the unused read dpcd operations in analogix_dp_enable_sink_psr(). 
(Sean)
- Delete the arbitrary usleep_range in analogix_dp_enable_psr_crc. (Sean).
- Clean up the hardcoded values in analogix_dp_send_psr_spd(). (Sean)
- Rename "active/inactive" to "enable/disable". (Sean, Dominik)
- Keep set the PSR_VID_CRC_FLUSH gate in analogix_dp_enable_psr_crc().
- Return 'void' instead of 'int' in analogix_dp_psr_set(). (Sean)
- Pull the 10ms delay time out into a #define. (Sean)
- Improved the code of analogix_dp_psr_work(). (Sean)
- Indented with spaces for new numbers in rockchip_dp_device struct. (Stéphane, 
reviewed at Google gerrit)

[https://chromium-review.googlesource.com/#/c/349085/33/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c@83]

Changes in v3:
- Export the 'rockchip_drm_wait_line_flag' symbol, and document it.
- Add 'line_flag_num_0' for RK3288/RK3036
- Remove the notify for waiting line_flag event (Daniel)
- split the psr flow into an common abstracted PSR driver
- implement the 'fb->dirty' callback function (Daniel)
- avoid to use notify to acqiure for vact event (Daniel)
- remove psr_active() callback which introduce in v2
- split analogix_dp_enable_psr(), make it more clearly
analogix_dp_detect_sink_psr()
analogix_dp_enable_sink_psr()
- remove some nosie register setting comments
- split the common psr logic into a seperate driver, make this to a
  simple sub-psr device driver.

Changes in v2:
- Introduce in v2, split VOP line flag changes out
- introduce in v2, splite the common Analogix DP changes out
- remove vblank notify out (Daniel)
- create a psr_active() callback in vop data struct.

Yakir Yang (4):
  drm/rockchip: vop: export line flag function
  drm/rockchip: add an common abstracted PSR driver
  drm/bridge: analogix_dp: add the PSR function support
  drm/rockchip: analogix_dp: implement PSR function

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c |  60 ++
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |   4 +
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  |  49 +
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h  |  28 +++
 drivers/gpu/drm/rockchip/Makefile  |   2 +-
 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c|  57 ++
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c|   4 +
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h|   6 +
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c |  12 ++
 drivers/gpu/drm/rockchip/rockchip_drm_psr.c| 223 +
 drivers/gpu/drm/rockchip/rockchip_drm_psr.h|  26 +++
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c| 147 ++
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h|   2 +
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c|   4 +
 include/drm/bridge/analogix_dp.h   |   3 +
 15 files changed, 626 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_psr.c
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_psr.h

-- 
1.9.1

[PATCH v4 1/4] drm/rockchip: vop: export line flag function

[Yakir Yang]

VOP have integrated a hardware counter which indicate the exact display
line that vop is scanning. And if we're interested in a specific line,
we can set the line number to vop line_flag register, and then vop would
generate a line_flag interrupt for it.

For example eDP PSR function is interested in the vertical blanking
period, then driver could set the line number to zero.

This patch have exported a symbol that allow other driver to listen the
line flag event with given timeout limit:
-  rockchip_drm_wait_line_flag()

Signed-off-by: Yakir Yang 
---
Changes in v4:
- Avoid the weird behavior in rockchip_drm_wait_line_flag(). (Sean)
- Make line_flag_num_x to an array. (Sean)
- Remove the unused vop_cfg_done() in vop_line_flag_irq_enable(). (Stephane, 
reviewed in Google gerrit)

[https://chromium-review.googlesource.com/#/c/349084/33/drivers/gpu/drm/rockchip/rockchip_drm_vop.c@466]

Changes in v3:
- Export the 'rockchip_drm_wait_line_flag' symbol, and document it.
- Add 'line_flag_num_0' for RK3288/RK3036
- Remove the notify for waiting line_flag event (Daniel)

Changes in v2:
- Introduce in v2, split VOP line flag changes out

 drivers/gpu/drm/rockchip/rockchip_drm_drv.h |   3 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 118 
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h |   2 +
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c |   4 +
 4 files changed, 127 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
index ea39329..239b830 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
@@ -70,4 +70,7 @@ int rockchip_drm_dma_attach_device(struct drm_device *drm_dev,
   struct device *dev);
 void rockchip_drm_dma_detach_device(struct drm_device *drm_dev,
struct device *dev);
+int rockchip_drm_wait_line_flag(struct drm_crtc *crtc, unsigned int line_num,
+   unsigned int mstimeout);
+
 #endif /* _ROCKCHIP_DRM_DRV_H_ */
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index c8a62a8..69d32f1 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -121,6 +121,8 @@ struct vop {
/* protected by dev->event_lock */
struct drm_pending_vblank_event *event;
 
+   struct completion line_flag_completion;
+
const struct vop_data *data;
 
uint32_t *regsbak;
@@ -431,6 +433,71 @@ static void vop_dsp_hold_valid_irq_disable(struct vop *vop)
spin_unlock_irqrestore(>irq_lock, flags);
 }
 
+/*
+ * (1) each frame starts at the start of the Vsync pulse which is signaled by
+ * the "FRAME_SYNC" interrupt.
+ * (2) the active data region of each frame ends at dsp_vact_end
+ * (3) we should program this same number (dsp_vact_end) into 
dsp_line_frag_num,
+ *  to get "LINE_FLAG" interrupt at the end of the active on screen data.
+ *
+ * VOP_INTR_CTRL0.dsp_line_frag_num = VOP_DSP_VACT_ST_END.dsp_vact_end
+ * Interrupts
+ * LINE_FLAG ---+
+ * FRAME_SYNC + |
+ *| |
+ *v v
+ *| Vsync | Vbp |  Vactive  | Vfp |
+ *^ ^   ^ ^
+ *| |   | |
+ *| |   | |
+ * dsp_vs_end + |   | |   VOP_DSP_VTOTAL_VS_END
+ * dsp_vact_start --+   | |   VOP_DSP_VACT_ST_END
+ * dsp_vact_end + |   VOP_DSP_VACT_ST_END
+ * dsp_total -+   VOP_DSP_VTOTAL_VS_END
+ */
+static bool vop_line_flag_irq_is_enabled(struct vop *vop)
+{
+   uint32_t line_flag_irq;
+   unsigned long flags;
+
+   spin_lock_irqsave(>irq_lock, flags);
+
+   line_flag_irq = VOP_INTR_GET_TYPE(vop, enable, LINE_FLAG_INTR);
+
+   spin_unlock_irqrestore(>irq_lock, flags);
+
+   return !!line_flag_irq;
+}
+
+static void vop_line_flag_irq_enable(struct vop *vop, int line_num)
+{
+   unsigned long flags;
+
+   if (WARN_ON(!vop->is_enabled))
+   return;
+
+   spin_lock_irqsave(>irq_lock, flags);
+
+   VOP_CTRL_SET(vop, line_flag_num[0], line_num);
+   VOP_INTR_SET_TYPE(vop, enable, LINE_FLAG_INTR, 1);
+
+   spin_unlock_irqrestore(>irq_lock, flags);
+}
+
+static void vop_line_flag_irq_disable(struct vop *vop)
+{
+   unsigned long flags;
+
+   if (WARN_ON(!vop->is_enabled))
+   return;
+
+   spin_lock_irqsave(>irq_lock, flags);
+
+   VOP_INTR_SET_TYPE(vop, enable, LINE_FLAG_INTR, 0);
+
+   spin_unlock_irqrestore(>irq_lock, flags);
+}
+
 static void vop_enable(struct drm_crtc *crtc)
 {
struct vop *vop = 

[PATCH v4 0/4] Add PSR function support for Analogix/Rockchip DP

[Yakir Yang]

The full name of PSR is Panel Self Refresh, panel device could refresh
itself with the hardware framebuffer in panel, this would make a lots
of sense to save the power consumption.

This v3 version have splited an common PSR driver for Rockchip, which is
biggest changes from v2.

This thread is based on Mark's RK3399 VOP thread[0] and my RK3399 eDP
thread[1].

[0]: https://patchwork.kernel.org/patch/8886041/
[1]: https://patchwork.kernel.org/patch/9204497/


Changes in v4:
- Avoid the weird behavior in rockchip_drm_wait_line_flag(). (Sean)
- Make line_flag_num_x to an array. (Sean)
- Remove the unused vop_cfg_done() in vop_line_flag_irq_enable(). (Stephane, 
reviewed in Google gerrit)

[https://chromium-review.googlesource.com/#/c/349084/33/drivers/gpu/drm/rockchip/rockchip_drm_vop.c@466]
- Tuck the global "psr_list" & "psr_list_mutex" in struct rockchip_drm_private. 
(Sean)
- Move the access of "psr->state" under "psr->state_mutex"'s protect. (Sean)
- Let "psr->state = PSR_FLUSH" under "psr->state_mutex"'s protect. (Sean)
- Collect psr_enable() and psr_disable() into psr_set_state()
- s/5\ second/PSR_FLUSH_TIMEOUT/ (Sean)
- Flush the psr callback in vop_crtc_disable(). (Stéphane, reviewed in Google 
gerrit)

[https://chromium-review.googlesource.com/#/c/349084/6/drivers/gpu/drm/rockchip/rockchip_drm_vop.c@475]
- Add the missing file head with license. (Stéphane, reviewed in Google gerrit)

[https://chromium-review.googlesource.com/#/c/357563/1/drivers/gpu/drm/rockchip/rockchip_drm_psr.h@3]
- Downgrade the PSR version print message to debug level. (Sean)
- Return 'void' instead of 'int' in analogix_dp_enable_sink_psr(). (Sean)
- Delete the unused read dpcd operations in analogix_dp_enable_sink_psr(). 
(Sean)
- Delete the arbitrary usleep_range in analogix_dp_enable_psr_crc. (Sean).
- Clean up the hardcoded values in analogix_dp_send_psr_spd(). (Sean)
- Rename "active/inactive" to "enable/disable". (Sean, Dominik)
- Keep set the PSR_VID_CRC_FLUSH gate in analogix_dp_enable_psr_crc().
- Return 'void' instead of 'int' in analogix_dp_psr_set(). (Sean)
- Pull the 10ms delay time out into a #define. (Sean)
- Improved the code of analogix_dp_psr_work(). (Sean)
- Indented with spaces for new numbers in rockchip_dp_device struct. (Stéphane, 
reviewed at Google gerrit)

[https://chromium-review.googlesource.com/#/c/349085/33/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c@83]

Changes in v3:
- Export the 'rockchip_drm_wait_line_flag' symbol, and document it.
- Add 'line_flag_num_0' for RK3288/RK3036
- Remove the notify for waiting line_flag event (Daniel)
- split the psr flow into an common abstracted PSR driver
- implement the 'fb->dirty' callback function (Daniel)
- avoid to use notify to acqiure for vact event (Daniel)
- remove psr_active() callback which introduce in v2
- split analogix_dp_enable_psr(), make it more clearly
analogix_dp_detect_sink_psr()
analogix_dp_enable_sink_psr()
- remove some nosie register setting comments
- split the common psr logic into a seperate driver, make this to a
  simple sub-psr device driver.

Changes in v2:
- Introduce in v2, split VOP line flag changes out
- introduce in v2, splite the common Analogix DP changes out
- remove vblank notify out (Daniel)
- create a psr_active() callback in vop data struct.

Yakir Yang (4):
  drm/rockchip: vop: export line flag function
  drm/rockchip: add an common abstracted PSR driver
  drm/bridge: analogix_dp: add the PSR function support
  drm/rockchip: analogix_dp: implement PSR function

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c |  60 ++
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |   4 +
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  |  49 +
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h  |  28 +++
 drivers/gpu/drm/rockchip/Makefile  |   2 +-
 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c|  57 ++
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c|   4 +
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h|   6 +
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c |  12 ++
 drivers/gpu/drm/rockchip/rockchip_drm_psr.c| 223 +
 drivers/gpu/drm/rockchip/rockchip_drm_psr.h|  26 +++
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c| 147 ++
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h|   2 +
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c|   4 +
 include/drm/bridge/analogix_dp.h   |   3 +
 15 files changed, 626 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_psr.c
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_psr.h

-- 
1.9.1

[PATCH v4 1/4] drm/rockchip: vop: export line flag function

[Yakir Yang]

VOP have integrated a hardware counter which indicate the exact display
line that vop is scanning. And if we're interested in a specific line,
we can set the line number to vop line_flag register, and then vop would
generate a line_flag interrupt for it.

For example eDP PSR function is interested in the vertical blanking
period, then driver could set the line number to zero.

This patch have exported a symbol that allow other driver to listen the
line flag event with given timeout limit:
-  rockchip_drm_wait_line_flag()

Signed-off-by: Yakir Yang 
---
Changes in v4:
- Avoid the weird behavior in rockchip_drm_wait_line_flag(). (Sean)
- Make line_flag_num_x to an array. (Sean)
- Remove the unused vop_cfg_done() in vop_line_flag_irq_enable(). (Stephane, 
reviewed in Google gerrit)

[https://chromium-review.googlesource.com/#/c/349084/33/drivers/gpu/drm/rockchip/rockchip_drm_vop.c@466]

Changes in v3:
- Export the 'rockchip_drm_wait_line_flag' symbol, and document it.
- Add 'line_flag_num_0' for RK3288/RK3036
- Remove the notify for waiting line_flag event (Daniel)

Changes in v2:
- Introduce in v2, split VOP line flag changes out

 drivers/gpu/drm/rockchip/rockchip_drm_drv.h |   3 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 118 
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h |   2 +
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c |   4 +
 4 files changed, 127 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
index ea39329..239b830 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
@@ -70,4 +70,7 @@ int rockchip_drm_dma_attach_device(struct drm_device *drm_dev,
   struct device *dev);
 void rockchip_drm_dma_detach_device(struct drm_device *drm_dev,
struct device *dev);
+int rockchip_drm_wait_line_flag(struct drm_crtc *crtc, unsigned int line_num,
+   unsigned int mstimeout);
+
 #endif /* _ROCKCHIP_DRM_DRV_H_ */
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index c8a62a8..69d32f1 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -121,6 +121,8 @@ struct vop {
/* protected by dev->event_lock */
struct drm_pending_vblank_event *event;
 
+   struct completion line_flag_completion;
+
const struct vop_data *data;
 
uint32_t *regsbak;
@@ -431,6 +433,71 @@ static void vop_dsp_hold_valid_irq_disable(struct vop *vop)
spin_unlock_irqrestore(>irq_lock, flags);
 }
 
+/*
+ * (1) each frame starts at the start of the Vsync pulse which is signaled by
+ * the "FRAME_SYNC" interrupt.
+ * (2) the active data region of each frame ends at dsp_vact_end
+ * (3) we should program this same number (dsp_vact_end) into 
dsp_line_frag_num,
+ *  to get "LINE_FLAG" interrupt at the end of the active on screen data.
+ *
+ * VOP_INTR_CTRL0.dsp_line_frag_num = VOP_DSP_VACT_ST_END.dsp_vact_end
+ * Interrupts
+ * LINE_FLAG ---+
+ * FRAME_SYNC + |
+ *| |
+ *v v
+ *| Vsync | Vbp |  Vactive  | Vfp |
+ *^ ^   ^ ^
+ *| |   | |
+ *| |   | |
+ * dsp_vs_end + |   | |   VOP_DSP_VTOTAL_VS_END
+ * dsp_vact_start --+   | |   VOP_DSP_VACT_ST_END
+ * dsp_vact_end + |   VOP_DSP_VACT_ST_END
+ * dsp_total -+   VOP_DSP_VTOTAL_VS_END
+ */
+static bool vop_line_flag_irq_is_enabled(struct vop *vop)
+{
+   uint32_t line_flag_irq;
+   unsigned long flags;
+
+   spin_lock_irqsave(>irq_lock, flags);
+
+   line_flag_irq = VOP_INTR_GET_TYPE(vop, enable, LINE_FLAG_INTR);
+
+   spin_unlock_irqrestore(>irq_lock, flags);
+
+   return !!line_flag_irq;
+}
+
+static void vop_line_flag_irq_enable(struct vop *vop, int line_num)
+{
+   unsigned long flags;
+
+   if (WARN_ON(!vop->is_enabled))
+   return;
+
+   spin_lock_irqsave(>irq_lock, flags);
+
+   VOP_CTRL_SET(vop, line_flag_num[0], line_num);
+   VOP_INTR_SET_TYPE(vop, enable, LINE_FLAG_INTR, 1);
+
+   spin_unlock_irqrestore(>irq_lock, flags);
+}
+
+static void vop_line_flag_irq_disable(struct vop *vop)
+{
+   unsigned long flags;
+
+   if (WARN_ON(!vop->is_enabled))
+   return;
+
+   spin_lock_irqsave(>irq_lock, flags);
+
+   VOP_INTR_SET_TYPE(vop, enable, LINE_FLAG_INTR, 0);
+
+   spin_unlock_irqrestore(>irq_lock, flags);
+}
+
 static void vop_enable(struct drm_crtc *crtc)
 {
struct vop *vop = to_vop(crtc);
@@ -1157,6 

linux-next: manual merge of the kvm tree with the s390 tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the kvm tree got a conflict in:

  arch/s390/mm/gmap.c

between commit:

  f04540298440 ("s390/mm: fix gmap tlb flush issues")

from the s390 tree and commit:

  6ea427bbbd40 ("s390/mm: add reference counter to gmap structure")

from the kvm tree.

I fixed it up (I just assumed that the update to gmap_free is no longer
needed) and can carry the fix as necessary. This is now fixed as far as
linux-next is concerned, but any non trivial conflicts should be mentioned
to your upstream maintainer when your tree is submitted for merging.
You may also want to consider cooperating with the maintainer of the
conflicting tree to minimise any particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

linux-next: manual merge of the kvm tree with the s390 tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the kvm tree got a conflict in:

  arch/s390/mm/gmap.c

between commit:

  f04540298440 ("s390/mm: fix gmap tlb flush issues")

from the s390 tree and commit:

  6ea427bbbd40 ("s390/mm: add reference counter to gmap structure")

from the kvm tree.

I fixed it up (I just assumed that the update to gmap_free is no longer
needed) and can carry the fix as necessary. This is now fixed as far as
linux-next is concerned, but any non trivial conflicts should be mentioned
to your upstream maintainer when your tree is submitted for merging.
You may also want to consider cooperating with the maintainer of the
conflicting tree to minimise any particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

Re: [PATCH 0/2] Code style fixes

[David Miller]

From: Elad Kanfi 
Date: Wed, 13 Jul 2016 16:58:05 +0300

> Fix all checkpatch warnings and errors, and reuse code

Series applied to net-next, thanks.

Re: [PATCH 6/8] x86: xen: audit and remove any unnecessary uses of module.h

[Juergen Gross]

On 14/07/16 02:18, Paul Gortmaker wrote:
> Historically a lot of these existed because we did not have
> a distinction between what was modular code and what was providing
> support to modules via EXPORT_SYMBOL and friends.  That changed
> when we forked out support for the latter into the export.h file.
> 
> This means we should be able to reduce the usage of module.h
> in code that is obj-y Makefile or bool Kconfig.  The advantage
> in doing so is that module.h itself sources about 15 other headers;
> adding significantly to what we feed cpp, and it can obscure what
> headers we are effectively using.
> 
> Since module.h was the source for init.h (for __init) and for
> export.h (for EXPORT_SYMBOL) we consider each obj-y/bool instance
> for the presence of either and replace as needed.
> 
> Cc: Boris Ostrovsky 
> Cc: David Vrabel 
> Cc: Juergen Gross 
> Cc: Thomas Gleixner 
> Cc: Ingo Molnar 
> Cc: "H. Peter Anvin" 
> Cc: x...@kernel.org
> Cc: xen-de...@lists.xenproject.org
> Signed-off-by: Paul Gortmaker 

Acked-by: Juergen Gross 

Juergen

Re: [PATCH 0/2] Code style fixes

[David Miller]

From: Elad Kanfi 
Date: Wed, 13 Jul 2016 16:58:05 +0300

> Fix all checkpatch warnings and errors, and reuse code

Series applied to net-next, thanks.

Re: [PATCH 6/8] x86: xen: audit and remove any unnecessary uses of module.h

[Juergen Gross]

On 14/07/16 02:18, Paul Gortmaker wrote:
> Historically a lot of these existed because we did not have
> a distinction between what was modular code and what was providing
> support to modules via EXPORT_SYMBOL and friends.  That changed
> when we forked out support for the latter into the export.h file.
> 
> This means we should be able to reduce the usage of module.h
> in code that is obj-y Makefile or bool Kconfig.  The advantage
> in doing so is that module.h itself sources about 15 other headers;
> adding significantly to what we feed cpp, and it can obscure what
> headers we are effectively using.
> 
> Since module.h was the source for init.h (for __init) and for
> export.h (for EXPORT_SYMBOL) we consider each obj-y/bool instance
> for the presence of either and replace as needed.
> 
> Cc: Boris Ostrovsky 
> Cc: David Vrabel 
> Cc: Juergen Gross 
> Cc: Thomas Gleixner 
> Cc: Ingo Molnar 
> Cc: "H. Peter Anvin" 
> Cc: x...@kernel.org
> Cc: xen-de...@lists.xenproject.org
> Signed-off-by: Paul Gortmaker 

Acked-by: Juergen Gross 

Juergen

linux-next: build warnings after merge of the tip tree

[Stephen Rothwell]

Hi all,

After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
produced these warnings:

In file included from tools/include/linux/hashtable.h:12:0,
 from elf.h:24,
 from builtin-check.c:33:
tools/include/linux/bitops.h:12:0: error: "BITS_PER_LONG" redefined [-Werror]
 #define BITS_PER_LONG __WORDSIZE
 ^
In file included from /usr/include/powerpc64le-linux-gnu/asm/bitsperlong.h:10:0,
 from /usr/include/asm-generic/int-ll64.h:11,
 from /usr/include/powerpc64le-linux-gnu/asm/types.h:27,
 from tools/include/linux/types.h:9,
 from tools/include/linux/list.h:4,
 from elf.h:23,
 from builtin-check.c:33:
tools/include/asm-generic/bitsperlong.h:10:0: note: this is the location of the 
previous definition
 #define BITS_PER_LONG 32
 ^
In file included from tools/include/linux/hashtable.h:12:0,
 from elf.h:24,
 from special.h:22,
 from special.c:26:
tools/include/linux/bitops.h:12:0: error: "BITS_PER_LONG" redefined [-Werror]
 #define BITS_PER_LONG __WORDSIZE
 ^
In file included from /usr/include/powerpc64le-linux-gnu/asm/bitsperlong.h:10:0,
 from /usr/include/asm-generic/int-ll64.h:11,
 from /usr/include/powerpc64le-linux-gnu/asm/types.h:27,
 from tools/include/linux/types.h:9,
 from tools/include/linux/list.h:4,
 from elf.h:23,
 from special.h:22,
 from special.c:26:
tools/include/asm-generic/bitsperlong.h:10:0: note: this is the location of the 
previous definition
 #define BITS_PER_LONG 32
 ^
In file included from tools/include/linux/hashtable.h:12:0,
 from elf.h:24,
 from elf.c:30:
tools/include/linux/bitops.h:12:0: error: "BITS_PER_LONG" redefined [-Werror]
 #define BITS_PER_LONG __WORDSIZE
 ^
In file included from /usr/include/powerpc64le-linux-gnu/asm/bitsperlong.h:10:0,
 from /usr/include/asm-generic/int-ll64.h:11,
 from /usr/include/powerpc64le-linux-gnu/asm/types.h:27,
 from tools/include/linux/types.h:9,
 from tools/include/linux/list.h:4,
 from elf.h:23,
 from elf.c:30:
tools/include/asm-generic/bitsperlong.h:10:0: note: this is the location of the 
previous definition
 #define BITS_PER_LONG 32
 ^
cc1: all warnings being treated as errors
In file included from tools/include/linux/hashtable.h:12:0,
 from arch/x86/../../elf.h:24,
 from arch/x86/decode.c:26:
tools/include/linux/bitops.h:12:0: error: "BITS_PER_LONG" redefined [-Werror]
 #define BITS_PER_LONG __WORDSIZE
 ^
In file included from /usr/include/powerpc64le-linux-gnu/asm/bitsperlong.h:10:0,
 from /usr/include/asm-generic/int-ll64.h:11,
 from /usr/include/powerpc64le-linux-gnu/asm/types.h:27,
 from tools/include/linux/types.h:9,
 from tools/include/linux/list.h:4,
 from arch/x86/../../elf.h:23,
 from arch/x86/decode.c:26:
tools/include/asm-generic/bitsperlong.h:10:0: note: this is the location of the 
previous definition
 #define BITS_PER_LONG 32
 ^

Introduced (I think) by commit

  bb9707077b4e ("tools: Copy the bitsperlong.h files from the kernel")

I saw some discussion of this, so I assume ti will be fixed soon.

-- 
Cheers,
Stephen Rothwell

linux-next: build warnings after merge of the tip tree

[Stephen Rothwell]

Hi all,

After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
produced these warnings:

In file included from tools/include/linux/hashtable.h:12:0,
 from elf.h:24,
 from builtin-check.c:33:
tools/include/linux/bitops.h:12:0: error: "BITS_PER_LONG" redefined [-Werror]
 #define BITS_PER_LONG __WORDSIZE
 ^
In file included from /usr/include/powerpc64le-linux-gnu/asm/bitsperlong.h:10:0,
 from /usr/include/asm-generic/int-ll64.h:11,
 from /usr/include/powerpc64le-linux-gnu/asm/types.h:27,
 from tools/include/linux/types.h:9,
 from tools/include/linux/list.h:4,
 from elf.h:23,
 from builtin-check.c:33:
tools/include/asm-generic/bitsperlong.h:10:0: note: this is the location of the 
previous definition
 #define BITS_PER_LONG 32
 ^
In file included from tools/include/linux/hashtable.h:12:0,
 from elf.h:24,
 from special.h:22,
 from special.c:26:
tools/include/linux/bitops.h:12:0: error: "BITS_PER_LONG" redefined [-Werror]
 #define BITS_PER_LONG __WORDSIZE
 ^
In file included from /usr/include/powerpc64le-linux-gnu/asm/bitsperlong.h:10:0,
 from /usr/include/asm-generic/int-ll64.h:11,
 from /usr/include/powerpc64le-linux-gnu/asm/types.h:27,
 from tools/include/linux/types.h:9,
 from tools/include/linux/list.h:4,
 from elf.h:23,
 from special.h:22,
 from special.c:26:
tools/include/asm-generic/bitsperlong.h:10:0: note: this is the location of the 
previous definition
 #define BITS_PER_LONG 32
 ^
In file included from tools/include/linux/hashtable.h:12:0,
 from elf.h:24,
 from elf.c:30:
tools/include/linux/bitops.h:12:0: error: "BITS_PER_LONG" redefined [-Werror]
 #define BITS_PER_LONG __WORDSIZE
 ^
In file included from /usr/include/powerpc64le-linux-gnu/asm/bitsperlong.h:10:0,
 from /usr/include/asm-generic/int-ll64.h:11,
 from /usr/include/powerpc64le-linux-gnu/asm/types.h:27,
 from tools/include/linux/types.h:9,
 from tools/include/linux/list.h:4,
 from elf.h:23,
 from elf.c:30:
tools/include/asm-generic/bitsperlong.h:10:0: note: this is the location of the 
previous definition
 #define BITS_PER_LONG 32
 ^
cc1: all warnings being treated as errors
In file included from tools/include/linux/hashtable.h:12:0,
 from arch/x86/../../elf.h:24,
 from arch/x86/decode.c:26:
tools/include/linux/bitops.h:12:0: error: "BITS_PER_LONG" redefined [-Werror]
 #define BITS_PER_LONG __WORDSIZE
 ^
In file included from /usr/include/powerpc64le-linux-gnu/asm/bitsperlong.h:10:0,
 from /usr/include/asm-generic/int-ll64.h:11,
 from /usr/include/powerpc64le-linux-gnu/asm/types.h:27,
 from tools/include/linux/types.h:9,
 from tools/include/linux/list.h:4,
 from arch/x86/../../elf.h:23,
 from arch/x86/decode.c:26:
tools/include/asm-generic/bitsperlong.h:10:0: note: this is the location of the 
previous definition
 #define BITS_PER_LONG 32
 ^

Introduced (I think) by commit

  bb9707077b4e ("tools: Copy the bitsperlong.h files from the kernel")

I saw some discussion of this, so I assume ti will be fixed soon.

-- 
Cheers,
Stephen Rothwell

Re: [PATCH v11 00/22] Add HiSilicon RoCE driver

[oulijun]

在 2016/7/2 17:39, Lijun Ou 写道:
> The HiSilicon Network Substem is a long term evolution IP which is
> supposed to be used in HiSilicon ICT SoCs. HNS (HiSilicon Network
> Sybsystem) also has a hardware support of performing RDMA with
> RoCEE.
> The driver for HiSilicon RoCEE(RoCE Engine) is a platform driver and
> will support mulitple versions of SOCs in future. This version of driver
> is meant to support Hip06 SoC(which confirms to RoCEv1 hardware
> specifications).
> 
> Changes v10 -> v11:
> [1/22]:
> 1. modify the print description of chip don't support roce
> 2. remove explicit values for enums for patch series
> [3/22]:
> 3. remove non-essential headers for patch series
> 4. add judgement for port_cnt is zero
> 5. Keep unified print style for "set mask..." vs. "No usable
>..."
> 6. modify the MODULE_LICENSE
> 7. remove MODULE_ALIAS
> [4/22]:
> 8. Move this line out of if-else and leave "if (enable)" part only
> 9. renaming the meaningful definition to 20 for patch series
> 10. delete extern keyword for hns_dsaf_roce_reset function
> 11. delete void keyword for hr_dev->hw->reset when driver removed
> [5/22]:
> 12. remove few unnecessary variables and some lines.
> 13. remove the function for one line of code which will be called
> once only for patch series
> [6/22]:
> 14. redesign the method for calculating token_mask' value
> [7/22]:
> 15. delete hns_roce_status_to_errno
> 16. modify the one enum only for all patches
> 17. remove the spin_lock in hns_roce_cq_event function
> 18. add comment here that 0x10 and 0x11 in hns_roce_event struct
> 19. refactor hns_roce_aeq_int function and It has switch in switch
> and it is almost 200 LOCs
> 20. simplify the lines for err_out_free_pages branch
> [8/22]:
> 21. remove icm and redesign it for patch series
> 
> Changes v9 -> v10:
> 1. delete redundant lines which it is netdevice.h in hns_roce_main.c
> 2. adjust the indentation for HNS_ROCE_V1_NUM_ASYNC_EQE
> 3. simplify the lines in hns_roce_init_qp_table function
> 4. add static type for hns_roce_unregister_device
> 5. move the call with hns_roce_unregister_device from the tenth patch to
>the eleventh patch in hns_roce_remove function
> 6. readjuest the alphabetic order in MAINTAINERS
> 7. redesigned the way for getting irq names
> 8. avoid the memory leakage because mr->pbl is not free in
>hns_roce_mr function
> 9. avoid the memory leakage because not kfree table->icm when exception
> 10. add the link from LKML as well whose comment in all
> 
> Changes v8 -> v9:
> 1. delete the definition of ADDR_SHIFT_n, use literal 12, 32 and 44 and
>add comments
> 2. use roce_read/roce_write/readl/write instead of roce_readl/roce_writel
> 3. delete the print error/debug messages for memory allocation errors
> 4. use exit instead of uninit, for example hw->uninit -> hw->exit
> 5. use roce_raw_write instead of _raw_writel in eq_set_cons_index
> 6. modify the label with underscore
> 7. adjust the indentation for the macro definitions in hns_roce_hw_v1.c
> 8. simplify some lines in few functions and structures
> 9. adjust the alphabetic order in MAINTAINERS
> 
> Changes v7 -> v8:
> 1. add a verbs operation named get_port_immutable. It is an 
>independent patch
> 2. add a comment for the definition of ADDR_SHIFT_n, n are 12,32
>and 44
> 3. restructures the code to align with naming convention of the Linux
>according to the review of Doug Ledford
> 4. modify the state for all .c and .h files
> 
> Changes v6 -> v7:
> 1. modify some type of parameter, use bool replace the original type
> 2. add the Signed-off-by signatures in the first patch
> 3. delete the improper print sentence in hns_roce_create_eq.
> 
> Changes v5 -> v6:
> 1. modify the type of obj for unsigned long according the reviews, and
>modify the same questions in RoCE module
> 2. fix the spelling error
> 3. fix the Signed-off-by signatures
> 
> Changes v4 -> v5:
> 1. redesign the patchset for RoCE modules in order to split the huge
>patch into small patches
> 2. fix the directory path for RoCE module. Delete the hisilicon level.
> 3. modify the name of roce_v1_hw into roce_hw_v1
> 
> Changes v3 -> v4:
> 1. modify roce.o into hns-roce.o in Makefile and Kconfig file
> 
> Changes v2 -> v3:
> 1. modify the formats of RoCE driver code base v2 by the experts 
>reviewing. also, it used kmalloc_array instead of kmalloc, kcalloc
>instead of kzalloc, when refer to memory allocation for array
> 2. remove some functions without use and unconnected macros
> 3. modify the binding document with RoCE DT base v2 which added
>interrupt-names
> 4. redesign the port_map and si_map in hns_dsaf_roce_reset
> 5. add HiSilicon RoCE driver maintainers introduction in MAINTAINERS
>document
> 
> Changes v1 -> v2:
> 1. modify the formats of roce driver code by the experts reviewing
> 2. modify the bindings file with roce dts. add the attribute named 
>interrput-names.
> 3. modify the way of defining port mode in hns_dsaf_main.c
> 

Re: [PATCH v11 00/22] Add HiSilicon RoCE driver

[oulijun]

在 2016/7/2 17:39, Lijun Ou 写道:
> The HiSilicon Network Substem is a long term evolution IP which is
> supposed to be used in HiSilicon ICT SoCs. HNS (HiSilicon Network
> Sybsystem) also has a hardware support of performing RDMA with
> RoCEE.
> The driver for HiSilicon RoCEE(RoCE Engine) is a platform driver and
> will support mulitple versions of SOCs in future. This version of driver
> is meant to support Hip06 SoC(which confirms to RoCEv1 hardware
> specifications).
> 
> Changes v10 -> v11:
> [1/22]:
> 1. modify the print description of chip don't support roce
> 2. remove explicit values for enums for patch series
> [3/22]:
> 3. remove non-essential headers for patch series
> 4. add judgement for port_cnt is zero
> 5. Keep unified print style for "set mask..." vs. "No usable
>..."
> 6. modify the MODULE_LICENSE
> 7. remove MODULE_ALIAS
> [4/22]:
> 8. Move this line out of if-else and leave "if (enable)" part only
> 9. renaming the meaningful definition to 20 for patch series
> 10. delete extern keyword for hns_dsaf_roce_reset function
> 11. delete void keyword for hr_dev->hw->reset when driver removed
> [5/22]:
> 12. remove few unnecessary variables and some lines.
> 13. remove the function for one line of code which will be called
> once only for patch series
> [6/22]:
> 14. redesign the method for calculating token_mask' value
> [7/22]:
> 15. delete hns_roce_status_to_errno
> 16. modify the one enum only for all patches
> 17. remove the spin_lock in hns_roce_cq_event function
> 18. add comment here that 0x10 and 0x11 in hns_roce_event struct
> 19. refactor hns_roce_aeq_int function and It has switch in switch
> and it is almost 200 LOCs
> 20. simplify the lines for err_out_free_pages branch
> [8/22]:
> 21. remove icm and redesign it for patch series
> 
> Changes v9 -> v10:
> 1. delete redundant lines which it is netdevice.h in hns_roce_main.c
> 2. adjust the indentation for HNS_ROCE_V1_NUM_ASYNC_EQE
> 3. simplify the lines in hns_roce_init_qp_table function
> 4. add static type for hns_roce_unregister_device
> 5. move the call with hns_roce_unregister_device from the tenth patch to
>the eleventh patch in hns_roce_remove function
> 6. readjuest the alphabetic order in MAINTAINERS
> 7. redesigned the way for getting irq names
> 8. avoid the memory leakage because mr->pbl is not free in
>hns_roce_mr function
> 9. avoid the memory leakage because not kfree table->icm when exception
> 10. add the link from LKML as well whose comment in all
> 
> Changes v8 -> v9:
> 1. delete the definition of ADDR_SHIFT_n, use literal 12, 32 and 44 and
>add comments
> 2. use roce_read/roce_write/readl/write instead of roce_readl/roce_writel
> 3. delete the print error/debug messages for memory allocation errors
> 4. use exit instead of uninit, for example hw->uninit -> hw->exit
> 5. use roce_raw_write instead of _raw_writel in eq_set_cons_index
> 6. modify the label with underscore
> 7. adjust the indentation for the macro definitions in hns_roce_hw_v1.c
> 8. simplify some lines in few functions and structures
> 9. adjust the alphabetic order in MAINTAINERS
> 
> Changes v7 -> v8:
> 1. add a verbs operation named get_port_immutable. It is an 
>independent patch
> 2. add a comment for the definition of ADDR_SHIFT_n, n are 12,32
>and 44
> 3. restructures the code to align with naming convention of the Linux
>according to the review of Doug Ledford
> 4. modify the state for all .c and .h files
> 
> Changes v6 -> v7:
> 1. modify some type of parameter, use bool replace the original type
> 2. add the Signed-off-by signatures in the first patch
> 3. delete the improper print sentence in hns_roce_create_eq.
> 
> Changes v5 -> v6:
> 1. modify the type of obj for unsigned long according the reviews, and
>modify the same questions in RoCE module
> 2. fix the spelling error
> 3. fix the Signed-off-by signatures
> 
> Changes v4 -> v5:
> 1. redesign the patchset for RoCE modules in order to split the huge
>patch into small patches
> 2. fix the directory path for RoCE module. Delete the hisilicon level.
> 3. modify the name of roce_v1_hw into roce_hw_v1
> 
> Changes v3 -> v4:
> 1. modify roce.o into hns-roce.o in Makefile and Kconfig file
> 
> Changes v2 -> v3:
> 1. modify the formats of RoCE driver code base v2 by the experts 
>reviewing. also, it used kmalloc_array instead of kmalloc, kcalloc
>instead of kzalloc, when refer to memory allocation for array
> 2. remove some functions without use and unconnected macros
> 3. modify the binding document with RoCE DT base v2 which added
>interrupt-names
> 4. redesign the port_map and si_map in hns_dsaf_roce_reset
> 5. add HiSilicon RoCE driver maintainers introduction in MAINTAINERS
>document
> 
> Changes v1 -> v2:
> 1. modify the formats of roce driver code by the experts reviewing
> 2. modify the bindings file with roce dts. add the attribute named 
>interrput-names.
> 3. modify the way of defining port mode in hns_dsaf_main.c
> 

Re: [PATCH 2/2] proc: Add /proc//timerslack_ns interface

[Kees Cook]

On Wed, Jul 13, 2016 at 4:47 PM, John Stultz  wrote:
> On Tue, Feb 16, 2016 at 5:06 PM, John Stultz  wrote:
>> This patch provides a proc/PID/timerslack_ns interface which
>> exposes a task's timerslack value in nanoseconds and allows it
>> to be changed.
>>
>> This allows power/performance management software to set timer
>> slack for other threads according to its policy for the thread
>> (such as when the thread is designated foreground vs. background
>> activity)
>>
>> If the value written is non-zero, slack is set to that value.
>> Otherwise sets it to the default for the thread.
>>
>> This interface checks that the calling task has permissions to
>> to use PTRACE_MODE_ATTACH_FSCREDS on the target task, so that we
>> can ensure arbitrary apps do not change the timer slack for other
>> apps.
>
> Sigh.
>
> So I wanted to pull this thread up again, because when I originally
> proposed upstreaming the PR_SET_TIMERSLACK_PID feature from the AOSP
> common.git tree, the first objection from Arjan was that it only
> required CAP_SYS_NICE:
>http://lkml.iu.edu/hypermail/linux/kernel/1506.3/01491.html
>
> And reasonably, setting timerslack to very large values does have the
> potential to effect applications much further then what a task could
> do previously with CAP_SYS_NICE.
>
> CAP_SYS_PTRACE was suggested instead, as that allows applications to
> manipulate other tasks more drastically.
>
> (At the time, I checked with some of the Android developers, and got
> no objection to changing to use this capability.)
>
> However, after submitting the changes to Android required to support
> the upstreamed /proc//timerslack_ns interface, I've gotten some
> objections with adding CAP_SYS_PTRACE to the system_server, as this
> would allow the system_server to be able to inspect and modify memory
> on any task in the system. This gives the system_server privileged to
> effect applications much further then what it could do previously.
>
> So I worry I'm a bit stuck here. For general systems, CAP_SYS_NICE is
> too low a level of privilege  to set a tasks timerslack, but
> apparently CAP_SYS_PTRACE is too high a privilege for Android's
> system_server to require just to set a tasks timerslack value.
>
> So I wanted to ask again if we might consider backing this down to
> CAP_SYS_NICE, or if we can instead introduce a new CAP_SYS_TIMERSLACK
> or something to provide the needed in-between capability level.

Adding new capabilities appears to not really be viable (lots of
threads about this...)

I think the original CAP_SYS_NICE should be fine. A malicious
CAP_SYS_NICE process can do plenty of insane things, I don't feel like
the timer slack adds to any realistic risks.

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

Re: [PATCH 2/2] proc: Add /proc//timerslack_ns interface

[Kees Cook]

On Wed, Jul 13, 2016 at 4:47 PM, John Stultz  wrote:
> On Tue, Feb 16, 2016 at 5:06 PM, John Stultz  wrote:
>> This patch provides a proc/PID/timerslack_ns interface which
>> exposes a task's timerslack value in nanoseconds and allows it
>> to be changed.
>>
>> This allows power/performance management software to set timer
>> slack for other threads according to its policy for the thread
>> (such as when the thread is designated foreground vs. background
>> activity)
>>
>> If the value written is non-zero, slack is set to that value.
>> Otherwise sets it to the default for the thread.
>>
>> This interface checks that the calling task has permissions to
>> to use PTRACE_MODE_ATTACH_FSCREDS on the target task, so that we
>> can ensure arbitrary apps do not change the timer slack for other
>> apps.
>
> Sigh.
>
> So I wanted to pull this thread up again, because when I originally
> proposed upstreaming the PR_SET_TIMERSLACK_PID feature from the AOSP
> common.git tree, the first objection from Arjan was that it only
> required CAP_SYS_NICE:
>http://lkml.iu.edu/hypermail/linux/kernel/1506.3/01491.html
>
> And reasonably, setting timerslack to very large values does have the
> potential to effect applications much further then what a task could
> do previously with CAP_SYS_NICE.
>
> CAP_SYS_PTRACE was suggested instead, as that allows applications to
> manipulate other tasks more drastically.
>
> (At the time, I checked with some of the Android developers, and got
> no objection to changing to use this capability.)
>
> However, after submitting the changes to Android required to support
> the upstreamed /proc//timerslack_ns interface, I've gotten some
> objections with adding CAP_SYS_PTRACE to the system_server, as this
> would allow the system_server to be able to inspect and modify memory
> on any task in the system. This gives the system_server privileged to
> effect applications much further then what it could do previously.
>
> So I worry I'm a bit stuck here. For general systems, CAP_SYS_NICE is
> too low a level of privilege  to set a tasks timerslack, but
> apparently CAP_SYS_PTRACE is too high a privilege for Android's
> system_server to require just to set a tasks timerslack value.
>
> So I wanted to ask again if we might consider backing this down to
> CAP_SYS_NICE, or if we can instead introduce a new CAP_SYS_TIMERSLACK
> or something to provide the needed in-between capability level.

Adding new capabilities appears to not really be viable (lots of
threads about this...)

I think the original CAP_SYS_NICE should be fine. A malicious
CAP_SYS_NICE process can do plenty of insane things, I don't feel like
the timer slack adds to any realistic risks.

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

Re: [PATCH v2 02/10] irqchip: add irqchip driver for nuc900

[Wan Zongshun]

On 2016年07月14日 04:09, Jason Cooper wrote:

Hi Wan Zongshun,

On Sun, Jul 10, 2016 at 03:27:22PM +0800, Wan Zongshun wrote:

This patch is to add irqchip driver support for nuc900 plat,
current this driver only supports nuc970 SoC.

Signed-off-by: Wan Zongshun 
---
  arch/arm/mach-w90x900/include/mach/irqs.h |   5 +
  drivers/irqchip/Makefile  |   1 +
  drivers/irqchip/irq-nuc900.c  | 150 ++
  3 files changed, 156 insertions(+)
  create mode 100644 drivers/irqchip/irq-nuc900.c

diff --git a/arch/arm/mach-w90x900/include/mach/irqs.h 
b/arch/arm/mach-w90x900/include/mach/irqs.h
index 9d5cba3..3b035c6 100644
--- a/arch/arm/mach-w90x900/include/mach/irqs.h
+++ b/arch/arm/mach-w90x900/include/mach/irqs.h
@@ -59,7 +59,12 @@
  #define IRQ_KPI   W90X900_IRQ(29)
  #define IRQ_P2SGROUP  W90X900_IRQ(30)
  #define IRQ_ADC   W90X900_IRQ(31)
+
+#if !defined(CONFIG_SOC_NUC900)
  #define NR_IRQS   (IRQ_ADC+1)
+#else
+#define NR_IRQS62
+#endif


Arnd already covered this...



  /*for irq group*/

diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 38853a1..9ccd5af8a 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -69,3 +69,4 @@ obj-$(CONFIG_PIC32_EVIC)  += irq-pic32-evic.o
  obj-$(CONFIG_MVEBU_ODMI)  += irq-mvebu-odmi.o
  obj-$(CONFIG_LS_SCFG_MSI) += irq-ls-scfg-msi.o
  obj-$(CONFIG_EZNPS_GIC)   += irq-eznps.o
+obj-$(CONFIG_SOC_NUC970)   += irq-nuc900.o
diff --git a/drivers/irqchip/irq-nuc900.c b/drivers/irqchip/irq-nuc900.c
new file mode 100644
index 000..c4b2e39
--- /dev/null
+++ b/drivers/irqchip/irq-nuc900.c
@@ -0,0 +1,150 @@
+/*
+ * Copyright 2016 Wan Zongshun 
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#defineREG_AIC_SCR10x00
+#defineREG_AIC_SCR20x04
+#defineREG_AIC_SCR30x08
+#defineREG_AIC_SCR40x0C
+#defineREG_AIC_SCR50x10
+#defineREG_AIC_SCR60x14
+#defineREG_AIC_SCR70x18
+#defineREG_AIC_SCR80x1C
+#defineREG_AIC_SCR90x20
+#defineREG_AIC_SCR10   0x24
+#defineREG_AIC_SCR11   0x28
+#defineREG_AIC_SCR12   0x2C
+#defineREG_AIC_SCR13   0x30
+#defineREG_AIC_SCR14   0x34
+#defineREG_AIC_SCR15   0x38
+#defineREG_AIC_IRSR0x100
+#defineREG_AIC_IRSRH   0x104
+#defineREG_AIC_IASR0x108
+#defineREG_AIC_IASRH   0x10C
+#defineREG_AIC_ISR 0x110
+#defineREG_AIC_ISRH0x114
+#defineREG_AIC_IPER0x118
+#defineREG_AIC_ISNR0x120
+#defineREG_AIC_OISR0x124
+#defineREG_AIC_IMR 0x128
+#defineREG_AIC_IMRH0x12C
+#defineREG_AIC_MECR0x130
+#defineREG_AIC_MECRH   0x134
+#defineREG_AIC_MDCR0x138
+#defineREG_AIC_MDCRH   0x13C
+#defineREG_AIC_SSCR0x140
+#defineREG_AIC_SSCRH   0x144
+#defineREG_AIC_SCCR0x148
+#defineREG_AIC_SCCRH   0x14C
+#defineREG_AIC_EOSCR   0x150


Please remove unused defines.


Okay.




+
+static void __iomem *aic_base;
+static struct irq_domain *aic_domain;
+
+static void nuc900_irq_mask(struct irq_data *d)
+{
+   if (d->irq < 32)
+   writel(1 << (d->irq), aic_base + REG_AIC_MDCR);
+   else
+   writel(1 << (d->irq - 32), aic_base + REG_AIC_MDCRH);
+}
+
+static void nuc900_irq_ack(struct irq_data *d)
+{
+   writel(0x01, aic_base + REG_AIC_EOSCR);
+}
+
+static void nuc900_irq_unmask(struct irq_data *d)
+{
+   if (d->irq < 32)
+   writel(1 << (d->irq), aic_base + REG_AIC_MECR);
+   else
+   writel(1 << (d->irq - 32), aic_base + REG_AIC_MECRH);
+}
+
+static struct irq_chip nuc900_irq_chip = {
+   .irq_ack= nuc900_irq_ack,
+   .irq_mask   = nuc900_irq_mask,
+   .irq_unmask = nuc900_irq_unmask,
+};
+
+void __exception_irq_entry aic_handle_irq(struct pt_regs *regs)
+{
+   u32 hwirq;
+
+   hwirq = readl(aic_base + REG_AIC_IPER);
+   hwirq = readl(aic_base + REG_AIC_ISNR);
+   if (!hwirq)
+   writel(0x01, aic_base + REG_AIC_EOSCR);


Could you explain what's going on here?


AIC_IPER, When the AIC generates the interrupt, VECTOR represents the 
interrupt channel number that is active, enabled, and has the highest 
priority.


The value of VECTOR is copied to the register AIC_ISNR thereafter by the 
AIC. This 

linux-next: build warnings after merge of the tip tree

[Stephen Rothwell]

Hi all,

After merging the tip tree, today's linux-next build (powerpc64le perf)
produced these warnings:

Warning: tools/include/uapi/linux/bpf.h differs from kernel
Warning: tools/arch/x86/include/asm/disabled-features.h differs from kernel
Warning: tools/arch/x86/include/asm/required-features.h differs from kernel
Warning: tools/arch/x86/include/asm/cpufeatures.h differs from kernel

Introduced by commits

  7d7d1bf1d1da ("perf bench: Copy kernel files needed to build mem{cpy,set} 
x86_64 benchmarks")
  971e827bffef ("tools lib bpf: Copy bpf.h and bpf_common.h from the kernel")

-- 
Cheers,
Stephen Rothwell

Re: [PATCH v2 02/10] irqchip: add irqchip driver for nuc900

[Wan Zongshun]

On 2016年07月14日 04:09, Jason Cooper wrote:

Hi Wan Zongshun,

On Sun, Jul 10, 2016 at 03:27:22PM +0800, Wan Zongshun wrote:

This patch is to add irqchip driver support for nuc900 plat,
current this driver only supports nuc970 SoC.

Signed-off-by: Wan Zongshun 
---
  arch/arm/mach-w90x900/include/mach/irqs.h |   5 +
  drivers/irqchip/Makefile  |   1 +
  drivers/irqchip/irq-nuc900.c  | 150 ++
  3 files changed, 156 insertions(+)
  create mode 100644 drivers/irqchip/irq-nuc900.c

diff --git a/arch/arm/mach-w90x900/include/mach/irqs.h 
b/arch/arm/mach-w90x900/include/mach/irqs.h
index 9d5cba3..3b035c6 100644
--- a/arch/arm/mach-w90x900/include/mach/irqs.h
+++ b/arch/arm/mach-w90x900/include/mach/irqs.h
@@ -59,7 +59,12 @@
  #define IRQ_KPI   W90X900_IRQ(29)
  #define IRQ_P2SGROUP  W90X900_IRQ(30)
  #define IRQ_ADC   W90X900_IRQ(31)
+
+#if !defined(CONFIG_SOC_NUC900)
  #define NR_IRQS   (IRQ_ADC+1)
+#else
+#define NR_IRQS62
+#endif


Arnd already covered this...



  /*for irq group*/

diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 38853a1..9ccd5af8a 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -69,3 +69,4 @@ obj-$(CONFIG_PIC32_EVIC)  += irq-pic32-evic.o
  obj-$(CONFIG_MVEBU_ODMI)  += irq-mvebu-odmi.o
  obj-$(CONFIG_LS_SCFG_MSI) += irq-ls-scfg-msi.o
  obj-$(CONFIG_EZNPS_GIC)   += irq-eznps.o
+obj-$(CONFIG_SOC_NUC970)   += irq-nuc900.o
diff --git a/drivers/irqchip/irq-nuc900.c b/drivers/irqchip/irq-nuc900.c
new file mode 100644
index 000..c4b2e39
--- /dev/null
+++ b/drivers/irqchip/irq-nuc900.c
@@ -0,0 +1,150 @@
+/*
+ * Copyright 2016 Wan Zongshun 
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#defineREG_AIC_SCR10x00
+#defineREG_AIC_SCR20x04
+#defineREG_AIC_SCR30x08
+#defineREG_AIC_SCR40x0C
+#defineREG_AIC_SCR50x10
+#defineREG_AIC_SCR60x14
+#defineREG_AIC_SCR70x18
+#defineREG_AIC_SCR80x1C
+#defineREG_AIC_SCR90x20
+#defineREG_AIC_SCR10   0x24
+#defineREG_AIC_SCR11   0x28
+#defineREG_AIC_SCR12   0x2C
+#defineREG_AIC_SCR13   0x30
+#defineREG_AIC_SCR14   0x34
+#defineREG_AIC_SCR15   0x38
+#defineREG_AIC_IRSR0x100
+#defineREG_AIC_IRSRH   0x104
+#defineREG_AIC_IASR0x108
+#defineREG_AIC_IASRH   0x10C
+#defineREG_AIC_ISR 0x110
+#defineREG_AIC_ISRH0x114
+#defineREG_AIC_IPER0x118
+#defineREG_AIC_ISNR0x120
+#defineREG_AIC_OISR0x124
+#defineREG_AIC_IMR 0x128
+#defineREG_AIC_IMRH0x12C
+#defineREG_AIC_MECR0x130
+#defineREG_AIC_MECRH   0x134
+#defineREG_AIC_MDCR0x138
+#defineREG_AIC_MDCRH   0x13C
+#defineREG_AIC_SSCR0x140
+#defineREG_AIC_SSCRH   0x144
+#defineREG_AIC_SCCR0x148
+#defineREG_AIC_SCCRH   0x14C
+#defineREG_AIC_EOSCR   0x150


Please remove unused defines.


Okay.




+
+static void __iomem *aic_base;
+static struct irq_domain *aic_domain;
+
+static void nuc900_irq_mask(struct irq_data *d)
+{
+   if (d->irq < 32)
+   writel(1 << (d->irq), aic_base + REG_AIC_MDCR);
+   else
+   writel(1 << (d->irq - 32), aic_base + REG_AIC_MDCRH);
+}
+
+static void nuc900_irq_ack(struct irq_data *d)
+{
+   writel(0x01, aic_base + REG_AIC_EOSCR);
+}
+
+static void nuc900_irq_unmask(struct irq_data *d)
+{
+   if (d->irq < 32)
+   writel(1 << (d->irq), aic_base + REG_AIC_MECR);
+   else
+   writel(1 << (d->irq - 32), aic_base + REG_AIC_MECRH);
+}
+
+static struct irq_chip nuc900_irq_chip = {
+   .irq_ack= nuc900_irq_ack,
+   .irq_mask   = nuc900_irq_mask,
+   .irq_unmask = nuc900_irq_unmask,
+};
+
+void __exception_irq_entry aic_handle_irq(struct pt_regs *regs)
+{
+   u32 hwirq;
+
+   hwirq = readl(aic_base + REG_AIC_IPER);
+   hwirq = readl(aic_base + REG_AIC_ISNR);
+   if (!hwirq)
+   writel(0x01, aic_base + REG_AIC_EOSCR);


Could you explain what's going on here?


AIC_IPER, When the AIC generates the interrupt, VECTOR represents the 
interrupt channel number that is active, enabled, and has the highest 
priority.


The value of VECTOR is copied to the register AIC_ISNR thereafter by the 
AIC. This register was restored a value 0 after it was 

linux-next: build warnings after merge of the tip tree

[Stephen Rothwell]

Hi all,

After merging the tip tree, today's linux-next build (powerpc64le perf)
produced these warnings:

Warning: tools/include/uapi/linux/bpf.h differs from kernel
Warning: tools/arch/x86/include/asm/disabled-features.h differs from kernel
Warning: tools/arch/x86/include/asm/required-features.h differs from kernel
Warning: tools/arch/x86/include/asm/cpufeatures.h differs from kernel

Introduced by commits

  7d7d1bf1d1da ("perf bench: Copy kernel files needed to build mem{cpy,set} 
x86_64 benchmarks")
  971e827bffef ("tools lib bpf: Copy bpf.h and bpf_common.h from the kernel")

-- 
Cheers,
Stephen Rothwell

[PATCH 2/2] net: nps_enet: code reuse

[Elad Kanfi]

From: Elad Kanfi 

Add inline function that checks if there is a pending tx packet.

Signed-off-by: Elad Kanfi 
---
 drivers/net/ethernet/ezchip/nps_enet.c |   21 +++--
 1 files changed, 11 insertions(+), 10 deletions(-)

diff --git a/drivers/net/ethernet/ezchip/nps_enet.c 
b/drivers/net/ethernet/ezchip/nps_enet.c
index b182e2a..25faa3d 100644
--- a/drivers/net/ethernet/ezchip/nps_enet.c
+++ b/drivers/net/ethernet/ezchip/nps_enet.c
@@ -24,6 +24,14 @@
 
 #define DRV_NAME   "nps_mgt_enet"
 
+static inline bool nps_enet_is_tx_pending(struct nps_enet_priv *priv)
+{
+   u32 tx_ctrl_value = nps_enet_reg_get(priv, NPS_ENET_REG_TX_CTL);
+   u32 tx_ctrl_ct = (tx_ctrl_value & TX_CTL_CT_MASK) >> TX_CTL_CT_SHIFT;
+
+   return (!tx_ctrl_ct && priv->tx_skb);
+}
+
 static void nps_enet_clean_rx_fifo(struct net_device *ndev, u32 frame_len)
 {
struct nps_enet_priv *priv = netdev_priv(ndev);
@@ -141,12 +149,11 @@ static void nps_enet_tx_handler(struct net_device *ndev)
 {
struct nps_enet_priv *priv = netdev_priv(ndev);
u32 tx_ctrl_value = nps_enet_reg_get(priv, NPS_ENET_REG_TX_CTL);
-   u32 tx_ctrl_ct = (tx_ctrl_value & TX_CTL_CT_MASK) >> TX_CTL_CT_SHIFT;
u32 tx_ctrl_et = (tx_ctrl_value & TX_CTL_ET_MASK) >> TX_CTL_ET_SHIFT;
u32 tx_ctrl_nt = (tx_ctrl_value & TX_CTL_NT_MASK) >> TX_CTL_NT_SHIFT;
 
/* Check if we got TX */
-   if (!priv->tx_skb || tx_ctrl_ct)
+   if (!nps_enet_is_tx_pending(priv))
return;
 
/* Ack Tx ctrl register */
@@ -184,9 +191,6 @@ static int nps_enet_poll(struct napi_struct *napi, int 
budget)
work_done = nps_enet_rx_handler(ndev);
if (work_done < budget) {
u32 buf_int_enable_value = 0;
-   u32 tx_ctrl_value = nps_enet_reg_get(priv, NPS_ENET_REG_TX_CTL);
-   u32 tx_ctrl_ct =
-   (tx_ctrl_value & TX_CTL_CT_MASK) >> TX_CTL_CT_SHIFT;
 
napi_complete(napi);
 
@@ -205,8 +209,7 @@ static int nps_enet_poll(struct napi_struct *napi, int 
budget)
 * the two code lines below will solve this situation by
 * re-adding ourselves to the poll list.
 */
-
-   if (priv->tx_skb && !tx_ctrl_ct) {
+   if (nps_enet_is_tx_pending(priv)) {
nps_enet_reg_set(priv, NPS_ENET_REG_BUF_INT_ENABLE, 0);
napi_reschedule(napi);
}
@@ -231,11 +234,9 @@ static irqreturn_t nps_enet_irq_handler(s32 irq, void 
*dev_instance)
struct net_device *ndev = dev_instance;
struct nps_enet_priv *priv = netdev_priv(ndev);
u32 rx_ctrl_value = nps_enet_reg_get(priv, NPS_ENET_REG_RX_CTL);
-   u32 tx_ctrl_value = nps_enet_reg_get(priv, NPS_ENET_REG_TX_CTL);
-   u32 tx_ctrl_ct = (tx_ctrl_value & TX_CTL_CT_MASK) >> TX_CTL_CT_SHIFT;
u32 rx_ctrl_cr = (rx_ctrl_value & RX_CTL_CR_MASK) >> RX_CTL_CR_SHIFT;
 
-   if ((!tx_ctrl_ct && priv->tx_skb) || rx_ctrl_cr)
+   if (nps_enet_is_tx_pending(priv) || rx_ctrl_cr)
if (likely(napi_schedule_prep(>napi))) {
nps_enet_reg_set(priv, NPS_ENET_REG_BUF_INT_ENABLE, 0);
__napi_schedule(>napi);
-- 
1.7.1

[PATCH 2/2] net: nps_enet: code reuse

[Elad Kanfi]

From: Elad Kanfi 

Add inline function that checks if there is a pending tx packet.

Signed-off-by: Elad Kanfi 
---
 drivers/net/ethernet/ezchip/nps_enet.c |   21 +++--
 1 files changed, 11 insertions(+), 10 deletions(-)

diff --git a/drivers/net/ethernet/ezchip/nps_enet.c 
b/drivers/net/ethernet/ezchip/nps_enet.c
index b182e2a..25faa3d 100644
--- a/drivers/net/ethernet/ezchip/nps_enet.c
+++ b/drivers/net/ethernet/ezchip/nps_enet.c
@@ -24,6 +24,14 @@
 
 #define DRV_NAME   "nps_mgt_enet"
 
+static inline bool nps_enet_is_tx_pending(struct nps_enet_priv *priv)
+{
+   u32 tx_ctrl_value = nps_enet_reg_get(priv, NPS_ENET_REG_TX_CTL);
+   u32 tx_ctrl_ct = (tx_ctrl_value & TX_CTL_CT_MASK) >> TX_CTL_CT_SHIFT;
+
+   return (!tx_ctrl_ct && priv->tx_skb);
+}
+
 static void nps_enet_clean_rx_fifo(struct net_device *ndev, u32 frame_len)
 {
struct nps_enet_priv *priv = netdev_priv(ndev);
@@ -141,12 +149,11 @@ static void nps_enet_tx_handler(struct net_device *ndev)
 {
struct nps_enet_priv *priv = netdev_priv(ndev);
u32 tx_ctrl_value = nps_enet_reg_get(priv, NPS_ENET_REG_TX_CTL);
-   u32 tx_ctrl_ct = (tx_ctrl_value & TX_CTL_CT_MASK) >> TX_CTL_CT_SHIFT;
u32 tx_ctrl_et = (tx_ctrl_value & TX_CTL_ET_MASK) >> TX_CTL_ET_SHIFT;
u32 tx_ctrl_nt = (tx_ctrl_value & TX_CTL_NT_MASK) >> TX_CTL_NT_SHIFT;
 
/* Check if we got TX */
-   if (!priv->tx_skb || tx_ctrl_ct)
+   if (!nps_enet_is_tx_pending(priv))
return;
 
/* Ack Tx ctrl register */
@@ -184,9 +191,6 @@ static int nps_enet_poll(struct napi_struct *napi, int 
budget)
work_done = nps_enet_rx_handler(ndev);
if (work_done < budget) {
u32 buf_int_enable_value = 0;
-   u32 tx_ctrl_value = nps_enet_reg_get(priv, NPS_ENET_REG_TX_CTL);
-   u32 tx_ctrl_ct =
-   (tx_ctrl_value & TX_CTL_CT_MASK) >> TX_CTL_CT_SHIFT;
 
napi_complete(napi);
 
@@ -205,8 +209,7 @@ static int nps_enet_poll(struct napi_struct *napi, int 
budget)
 * the two code lines below will solve this situation by
 * re-adding ourselves to the poll list.
 */
-
-   if (priv->tx_skb && !tx_ctrl_ct) {
+   if (nps_enet_is_tx_pending(priv)) {
nps_enet_reg_set(priv, NPS_ENET_REG_BUF_INT_ENABLE, 0);
napi_reschedule(napi);
}
@@ -231,11 +234,9 @@ static irqreturn_t nps_enet_irq_handler(s32 irq, void 
*dev_instance)
struct net_device *ndev = dev_instance;
struct nps_enet_priv *priv = netdev_priv(ndev);
u32 rx_ctrl_value = nps_enet_reg_get(priv, NPS_ENET_REG_RX_CTL);
-   u32 tx_ctrl_value = nps_enet_reg_get(priv, NPS_ENET_REG_TX_CTL);
-   u32 tx_ctrl_ct = (tx_ctrl_value & TX_CTL_CT_MASK) >> TX_CTL_CT_SHIFT;
u32 rx_ctrl_cr = (rx_ctrl_value & RX_CTL_CR_MASK) >> RX_CTL_CR_SHIFT;
 
-   if ((!tx_ctrl_ct && priv->tx_skb) || rx_ctrl_cr)
+   if (nps_enet_is_tx_pending(priv) || rx_ctrl_cr)
if (likely(napi_schedule_prep(>napi))) {
nps_enet_reg_set(priv, NPS_ENET_REG_BUF_INT_ENABLE, 0);
__napi_schedule(>napi);
-- 
1.7.1

Re: [PATCH v2 0/5] firmware: add SmPL grammar to avoid issues

[Fengguang Wu]

On Thu, Jul 14, 2016 at 05:08:12AM +0200, Luis R. Rodriguez wrote:

On Thu, Jul 14, 2016 at 10:23:36AM +0800, Fengguang Wu wrote:

On Thu, Jul 14, 2016 at 04:15:01AM +0200, Luis R. Rodriguez wrote:
>On Thu, Jul 14, 2016 at 07:52:07AM +0800, Fengguang Wu wrote:
>>Hi Luis,
>>
>>On Thu, Jul 07, 2016 at 02:56:44AM +0200, Luis R. Rodriguez wrote:
>>>On Thu, Jun 16, 2016 at 03:54:16PM -0700, Luis R. Rodriguez wrote:
The firmware API has had some issues a while ago, some of this is
not well documented, and its still hard to grasp. This documents
some of these issues, adds SmPL grammar rules to enable us to hunt
for issues, and annotations to help us with our effort to finally
compartamentalize that pesky usermode helper.

Previously this was just one patch, the grammar rule to help
find request firmware API users on init or probe, this series
extends that effort with usermode helper grammar rules, and some
annotations and documentation on the firmware_class driver to
avoid further issues. Documenting the usermode helper and making
it clear why we cannot remove it is important for analysis for
the next series which adds the new flexible sysdata firmware API.

This series depends on the coccicheck series which enables
annotations on coccinelle patches to require a specific
version of coccinelle [0], as such coordination with Michal is
in order.
>>>
>>>Michal is out until July 11, and upon further thought such coordination
>>>is not need, the annotation is in place as comments and as such
>>>merging this now won't have any negative effects other than the version
>>>check. Also the patches in question for the coccicheck change are all
>>>acked now and I expect them to be merged anyway.
>>>
>>>Which tree should firmware changes go through ?
>>
This series is also further extended next with the new sydata
API, the full set of changes is available on my linux-next tree [1].

Perhaps now a good time to discuss -- if 0-day should enable the rule
scripts/coccinelle/api/request_firmware-usermode.cocci to be called on
every 0-day iteration, it runs rather fast and it should help police
against avoiding futher explicit users of the usermode helper.
>>>
>>>And if we are going to merge this anyone oppose enabling hunting
>>>for further explicit users of the usermode helper using grammar through
>>>0-day ?
>>
>>When *.cocci scripts lands upstream they'll be auto picked up by the
>>0-day bot to guard new patches/commits.
>
>Great thanks!
>
>>Are there further steps 0-day should do for request_firmware-upstream.cocci?
>
>It just requires coccinelle >= 1.0.5.

That looks easy.


Nice!


When do you estimate the script will land upstream?


Well, this series has gone by a while now without any complaints, so
I was poking to see if they can be merged now.


OK.


So we can make sure upgrade coccinelle before that time.


There is another series which modernizes coccicheck [0] for which I just poked
at as a well [1], one change which may be of importance to you is groks the
Requires: tag on top of an SmPL patch, with that we simply just skip an SmPL
patch if the version of coccinelle is older than the one specified, with that
in place you can just upgrade when you want -- you'd just gain support for more
SmPL patches when you do. Without that coccinelle would not work (fail) on the
SmPL patch when tried. For this reason I originally had suggested perhaps
this series should be carried by Michal.

[0] 
https://lkml.kernel.org/r/1467238499-10889-1-git-send-email-mcg...@kernel.org
[1] https://lkml.kernel.org/r/20160713214539.ge6...@wotan.suse.de


It's glad to know these improvements. We'll watch their progress and
keep up in time. :)

Thanks,
Fengguang

Re: [PATCH v2 0/5] firmware: add SmPL grammar to avoid issues

[Fengguang Wu]

On Thu, Jul 14, 2016 at 05:08:12AM +0200, Luis R. Rodriguez wrote:

On Thu, Jul 14, 2016 at 10:23:36AM +0800, Fengguang Wu wrote:

On Thu, Jul 14, 2016 at 04:15:01AM +0200, Luis R. Rodriguez wrote:
>On Thu, Jul 14, 2016 at 07:52:07AM +0800, Fengguang Wu wrote:
>>Hi Luis,
>>
>>On Thu, Jul 07, 2016 at 02:56:44AM +0200, Luis R. Rodriguez wrote:
>>>On Thu, Jun 16, 2016 at 03:54:16PM -0700, Luis R. Rodriguez wrote:
The firmware API has had some issues a while ago, some of this is
not well documented, and its still hard to grasp. This documents
some of these issues, adds SmPL grammar rules to enable us to hunt
for issues, and annotations to help us with our effort to finally
compartamentalize that pesky usermode helper.

Previously this was just one patch, the grammar rule to help
find request firmware API users on init or probe, this series
extends that effort with usermode helper grammar rules, and some
annotations and documentation on the firmware_class driver to
avoid further issues. Documenting the usermode helper and making
it clear why we cannot remove it is important for analysis for
the next series which adds the new flexible sysdata firmware API.

This series depends on the coccicheck series which enables
annotations on coccinelle patches to require a specific
version of coccinelle [0], as such coordination with Michal is
in order.
>>>
>>>Michal is out until July 11, and upon further thought such coordination
>>>is not need, the annotation is in place as comments and as such
>>>merging this now won't have any negative effects other than the version
>>>check. Also the patches in question for the coccicheck change are all
>>>acked now and I expect them to be merged anyway.
>>>
>>>Which tree should firmware changes go through ?
>>
This series is also further extended next with the new sydata
API, the full set of changes is available on my linux-next tree [1].

Perhaps now a good time to discuss -- if 0-day should enable the rule
scripts/coccinelle/api/request_firmware-usermode.cocci to be called on
every 0-day iteration, it runs rather fast and it should help police
against avoiding futher explicit users of the usermode helper.
>>>
>>>And if we are going to merge this anyone oppose enabling hunting
>>>for further explicit users of the usermode helper using grammar through
>>>0-day ?
>>
>>When *.cocci scripts lands upstream they'll be auto picked up by the
>>0-day bot to guard new patches/commits.
>
>Great thanks!
>
>>Are there further steps 0-day should do for request_firmware-upstream.cocci?
>
>It just requires coccinelle >= 1.0.5.

That looks easy.


Nice!


When do you estimate the script will land upstream?


Well, this series has gone by a while now without any complaints, so
I was poking to see if they can be merged now.


OK.


So we can make sure upgrade coccinelle before that time.


There is another series which modernizes coccicheck [0] for which I just poked
at as a well [1], one change which may be of importance to you is groks the
Requires: tag on top of an SmPL patch, with that we simply just skip an SmPL
patch if the version of coccinelle is older than the one specified, with that
in place you can just upgrade when you want -- you'd just gain support for more
SmPL patches when you do. Without that coccinelle would not work (fail) on the
SmPL patch when tried. For this reason I originally had suggested perhaps
this series should be carried by Michal.

[0] 
https://lkml.kernel.org/r/1467238499-10889-1-git-send-email-mcg...@kernel.org
[1] https://lkml.kernel.org/r/20160713214539.ge6...@wotan.suse.de


It's glad to know these improvements. We'll watch their progress and
keep up in time. :)

Thanks,
Fengguang

Re: [PATCH 0/2] Automatically load the vmx_crypto module if supported

[Balbir Singh]

On Wed, Jul 13, 2016 at 03:54:59PM +1000, Alastair D'Silva wrote:
> On Wed, 2016-07-13 at 15:47 +1000, alast...@au1.ibm.com wrote:
> > From: Alastair D'Silva 
> > > This series allows the vmx_crypto module to be detected and
> > automatically
> > loaded via UDEV if the CPU supports the vector crypto feature.
> > > Alastair D'Silva (2):
> >   powerpc: Add module autoloading based on CPU features
> >   crypto: vmx - Convert to CPU feature based module autoloading
> > >  arch/powerpc/Kconfig  |  1 +
> >  arch/powerpc/include/asm/cpufeature.h | 70
> > +++
> >  drivers/crypto/vmx/Kconfig|  2 +-
> >  drivers/crypto/vmx/vmx.c  |  6 +--
> >  4 files changed, 74 insertions(+), 5 deletions(-)
> >  create mode 100644 arch/powerpc/include/asm/cpufeature.h
> 
> Please ignore the following:
>   [PATCH 1/2] Allow drivers to be autoloaded.
>   [PATCH 2/2] Automatically load the vmx_crypto module if supported.
>

Do you want to repost the series?

Balbir 

Re: [PATCH 0/2] Automatically load the vmx_crypto module if supported

[Balbir Singh]

On Wed, Jul 13, 2016 at 03:54:59PM +1000, Alastair D'Silva wrote:
> On Wed, 2016-07-13 at 15:47 +1000, alast...@au1.ibm.com wrote:
> > From: Alastair D'Silva 
> > > This series allows the vmx_crypto module to be detected and
> > automatically
> > loaded via UDEV if the CPU supports the vector crypto feature.
> > > Alastair D'Silva (2):
> >   powerpc: Add module autoloading based on CPU features
> >   crypto: vmx - Convert to CPU feature based module autoloading
> > >  arch/powerpc/Kconfig  |  1 +
> >  arch/powerpc/include/asm/cpufeature.h | 70
> > +++
> >  drivers/crypto/vmx/Kconfig|  2 +-
> >  drivers/crypto/vmx/vmx.c  |  6 +--
> >  4 files changed, 74 insertions(+), 5 deletions(-)
> >  create mode 100644 arch/powerpc/include/asm/cpufeature.h
> 
> Please ignore the following:
>   [PATCH 1/2] Allow drivers to be autoloaded.
>   [PATCH 2/2] Automatically load the vmx_crypto module if supported.
>

Do you want to repost the series?

Balbir 

Re: [PATCH v4 4/7] rtc: ac100: Add clk output support

[Chen-Yu Tsai]

On Sat, Jul 9, 2016 at 2:36 AM, Michael Turquette
 wrote:
> Quoting Chen-Yu Tsai (2016-06-30 08:58:48)
>> +static long ac100_clkout_round_rate(struct clk_hw *hw, unsigned long rate,
>> +   unsigned long prate)
>> +{
>> +   unsigned long best_rate = 0, tmp_rate, tmp_prate;
>> +   int i;
>> +
>> +   if (prate == AC100_RTC_32K_RATE)
>> +   return divider_round_rate(hw, rate, , NULL,
>> + AC100_CLKOUT_DIV_WIDTH,
>> + CLK_DIVIDER_POWER_OF_TWO);
>> +
>> +   for (i = 0; ac100_clkout_prediv[i].div; i++) {
>> +   tmp_prate = DIV_ROUND_UP(prate, ac100_clkout_prediv[i].val);
>> +   tmp_rate = divider_round_rate(hw, rate, _prate, NULL,
>> + AC100_CLKOUT_DIV_WIDTH,
>> + CLK_DIVIDER_POWER_OF_TWO);
>> +
>> +   if (tmp_rate > rate)
>> +   continue;
>> +   if (rate - tmp_rate < best_rate - tmp_rate)
>> +   best_rate = tmp_rate;
>> +   }
>> +
>> +   return best_rate;
>> +}
>> +
>> +static int ac100_clkout_determine_rate(struct clk_hw *hw,
>> +  struct clk_rate_request *req)
>> +{
>> +   struct clk_hw *best_parent;
>> +   unsigned long best = 0;
>> +   int i, num_parents = clk_hw_get_num_parents(hw);
>> +
>> +   for (i = 0; i < num_parents; i++) {
>> +   struct clk_hw *parent = clk_hw_get_parent_by_index(hw, i);
>> +   unsigned long tmp, prate = clk_hw_get_rate(parent);
>> +
>> +   tmp = ac100_clkout_round_rate(hw, req->rate, prate);
>> +
>> +   if (tmp > req->rate)
>> +   continue;
>> +   if (req->rate - tmp < req->rate - best) {
>> +   best = tmp;
>> +   best_parent = parent;
>> +   }
>> +   }
>> +
>> +   if (!best)
>> +   return -EINVAL;
>> +
>> +   req->best_parent_hw = best_parent;
>> +   req->best_parent_rate = best;
>> +   req->rate = best;
>> +
>> +   return 0;
>> +}
>
> You only need one of the two functions above. Keep the .determine_rate
> callback and drop .round_rate.

Only .round_rate is set in the clk_ops. ac100_clkout_round_rate just
serves to split out some of the calculations done per parent.

> Otherwise the rest of the clk support looks great to me. Feel free to
> add:
>
> Reviewed-by: Michael Turquette 

Thanks!

ChenYu

Re: [PATCH v4 4/7] rtc: ac100: Add clk output support

[Chen-Yu Tsai]

On Sat, Jul 9, 2016 at 2:36 AM, Michael Turquette
 wrote:
> Quoting Chen-Yu Tsai (2016-06-30 08:58:48)
>> +static long ac100_clkout_round_rate(struct clk_hw *hw, unsigned long rate,
>> +   unsigned long prate)
>> +{
>> +   unsigned long best_rate = 0, tmp_rate, tmp_prate;
>> +   int i;
>> +
>> +   if (prate == AC100_RTC_32K_RATE)
>> +   return divider_round_rate(hw, rate, , NULL,
>> + AC100_CLKOUT_DIV_WIDTH,
>> + CLK_DIVIDER_POWER_OF_TWO);
>> +
>> +   for (i = 0; ac100_clkout_prediv[i].div; i++) {
>> +   tmp_prate = DIV_ROUND_UP(prate, ac100_clkout_prediv[i].val);
>> +   tmp_rate = divider_round_rate(hw, rate, _prate, NULL,
>> + AC100_CLKOUT_DIV_WIDTH,
>> + CLK_DIVIDER_POWER_OF_TWO);
>> +
>> +   if (tmp_rate > rate)
>> +   continue;
>> +   if (rate - tmp_rate < best_rate - tmp_rate)
>> +   best_rate = tmp_rate;
>> +   }
>> +
>> +   return best_rate;
>> +}
>> +
>> +static int ac100_clkout_determine_rate(struct clk_hw *hw,
>> +  struct clk_rate_request *req)
>> +{
>> +   struct clk_hw *best_parent;
>> +   unsigned long best = 0;
>> +   int i, num_parents = clk_hw_get_num_parents(hw);
>> +
>> +   for (i = 0; i < num_parents; i++) {
>> +   struct clk_hw *parent = clk_hw_get_parent_by_index(hw, i);
>> +   unsigned long tmp, prate = clk_hw_get_rate(parent);
>> +
>> +   tmp = ac100_clkout_round_rate(hw, req->rate, prate);
>> +
>> +   if (tmp > req->rate)
>> +   continue;
>> +   if (req->rate - tmp < req->rate - best) {
>> +   best = tmp;
>> +   best_parent = parent;
>> +   }
>> +   }
>> +
>> +   if (!best)
>> +   return -EINVAL;
>> +
>> +   req->best_parent_hw = best_parent;
>> +   req->best_parent_rate = best;
>> +   req->rate = best;
>> +
>> +   return 0;
>> +}
>
> You only need one of the two functions above. Keep the .determine_rate
> callback and drop .round_rate.

Only .round_rate is set in the clk_ops. ac100_clkout_round_rate just
serves to split out some of the calculations done per parent.

> Otherwise the rest of the clk support looks great to me. Feel free to
> add:
>
> Reviewed-by: Michael Turquette 

Thanks!

ChenYu

[PATCH 5/6] drm/rockchip: vop: correct the source size of uv scale factor setting

[Mark Yao]

When the input color format is YUV, we need to do some external scale
for CBCR. Like,
 * In YUV420 data format:
 cbcr_xscale = dst_w / src_w * 2;
 cbcr_yscale = dst_h / src_h * 2;
 * In YUV422 data format:
 cbcr_xscale = dst_w / src_w * 2;
 cbcr_yscale = dst_h / src_h;
 * In YUV444 data format
 cbcr_xscale = dst_w / src_w;
 cbcr_yscale = dst_h / src_h;

Signed-off-by: Yakir Yang 
Signed-off-by: Mark Yao 
---
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index e01c435..aad105b 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -328,9 +328,9 @@ static void scl_vop_cal_scl_fac(struct vop *vop, const 
struct vop_win_data *win,
scl_cal_scale2(src_h, dst_h));
if (is_yuv) {
VOP_SCL_SET(vop, win, scale_cbcr_x,
-   scl_cal_scale2(src_w, dst_w));
+   scl_cal_scale2(cbcr_src_w, dst_w));
VOP_SCL_SET(vop, win, scale_cbcr_y,
-   scl_cal_scale2(src_h, dst_h));
+   scl_cal_scale2(cbcr_src_h, dst_h));
}
return;
}
-- 
1.9.1

[PATCH 5/6] drm/rockchip: vop: correct the source size of uv scale factor setting

[Mark Yao]

When the input color format is YUV, we need to do some external scale
for CBCR. Like,
 * In YUV420 data format:
 cbcr_xscale = dst_w / src_w * 2;
 cbcr_yscale = dst_h / src_h * 2;
 * In YUV422 data format:
 cbcr_xscale = dst_w / src_w * 2;
 cbcr_yscale = dst_h / src_h;
 * In YUV444 data format
 cbcr_xscale = dst_w / src_w;
 cbcr_yscale = dst_h / src_h;

Signed-off-by: Yakir Yang 
Signed-off-by: Mark Yao 
---
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index e01c435..aad105b 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -328,9 +328,9 @@ static void scl_vop_cal_scl_fac(struct vop *vop, const 
struct vop_win_data *win,
scl_cal_scale2(src_h, dst_h));
if (is_yuv) {
VOP_SCL_SET(vop, win, scale_cbcr_x,
-   scl_cal_scale2(src_w, dst_w));
+   scl_cal_scale2(cbcr_src_w, dst_w));
VOP_SCL_SET(vop, win, scale_cbcr_y,
-   scl_cal_scale2(src_h, dst_h));
+   scl_cal_scale2(cbcr_src_h, dst_h));
}
return;
}
-- 
1.9.1

[PATCH 6/6] drm/rockchip: vop: correct rk3036 register define

[Mark Yao]

Signed-off-by: Mark Yao 
Reported-by: Tomasz Figa 
---
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c 
b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index a348a7a..919992c 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -190,7 +190,7 @@ static const struct vop_data rk3288_vop = {
.win_size = ARRAY_SIZE(rk3288_vop_win_data),
 };
 
-static const struct vop_scl_regs rk3066_win_scl = {
+static const struct vop_scl_regs rk3036_win_scl = {
.scale_yrgb_x = VOP_REG(RK3036_WIN0_SCL_FACTOR_YRGB, 0x, 0x0),
.scale_yrgb_y = VOP_REG(RK3036_WIN0_SCL_FACTOR_YRGB, 0x, 16),
.scale_cbcr_x = VOP_REG(RK3036_WIN0_SCL_FACTOR_CBR, 0x, 0x0),
@@ -198,7 +198,7 @@ static const struct vop_scl_regs rk3066_win_scl = {
 };
 
 static const struct vop_win_phy rk3036_win0_data = {
-   .scl = _win_scl,
+   .scl = _win_scl,
.data_formats = formats_win_full,
.nformats = ARRAY_SIZE(formats_win_full),
.enable = VOP_REG(RK3036_SYS_CTRL, 0x1, 0),
-- 
1.9.1

[PATCH 6/6] drm/rockchip: vop: correct rk3036 register define

[Mark Yao]

Signed-off-by: Mark Yao 
Reported-by: Tomasz Figa 
---
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c 
b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index a348a7a..919992c 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -190,7 +190,7 @@ static const struct vop_data rk3288_vop = {
.win_size = ARRAY_SIZE(rk3288_vop_win_data),
 };
 
-static const struct vop_scl_regs rk3066_win_scl = {
+static const struct vop_scl_regs rk3036_win_scl = {
.scale_yrgb_x = VOP_REG(RK3036_WIN0_SCL_FACTOR_YRGB, 0x, 0x0),
.scale_yrgb_y = VOP_REG(RK3036_WIN0_SCL_FACTOR_YRGB, 0x, 16),
.scale_cbcr_x = VOP_REG(RK3036_WIN0_SCL_FACTOR_CBR, 0x, 0x0),
@@ -198,7 +198,7 @@ static const struct vop_scl_regs rk3066_win_scl = {
 };
 
 static const struct vop_win_phy rk3036_win0_data = {
-   .scl = _win_scl,
+   .scl = _win_scl,
.data_formats = formats_win_full,
.nformats = ARRAY_SIZE(formats_win_full),
.enable = VOP_REG(RK3036_SYS_CTRL, 0x1, 0),
-- 
1.9.1

[PATCH 1/6] drm/rockchip: dw_hdmi: remove unused #include

[Mark Yao]

From: John Keeping 

drm_encoder_slave is not used in this file.

Signed-off-by: John Keeping 
Signed-off-by: Mark Yao 
---
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c 
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 801110f..0665fb9 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -15,7 +15,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #include "rockchip_drm_drv.h"
-- 
1.9.1

[PATCH 2/6] drm/rockchip: fb: add missing header

[Mark Yao]

From: John Keeping 

This fixes the following sparse warnings:

drivers/gpu/drm/rockchip/rockchip_drm_fb.c:32:23: warning: symbol 
'rockchip_fb_get_gem_obj' was not declared. Should it be static?
drivers/gpu/drm/rockchip/rockchip_drm_fb.c:315:24: warning: symbol 
'rockchip_drm_framebuffer_init' was not declared. Should it be static?
drivers/gpu/drm/rockchip/rockchip_drm_fb.c:329:6: warning: symbol 
'rockchip_drm_mode_config_init' was not declared. Should it be static?

Signed-off-by: John Keeping 
Signed-off-by: Mark Yao 
---
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
index 20f12bc..4fe2ab3 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
@@ -20,6 +20,7 @@
 #include 
 
 #include "rockchip_drm_drv.h"
+#include "rockchip_drm_fb.h"
 #include "rockchip_drm_gem.h"
 
 #define to_rockchip_fb(x) container_of(x, struct rockchip_drm_fb, fb)
-- 
1.9.1

[PATCH 1/6] drm/rockchip: dw_hdmi: remove unused #include

[Mark Yao]

From: John Keeping 

drm_encoder_slave is not used in this file.

Signed-off-by: John Keeping 
Signed-off-by: Mark Yao 
---
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c 
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 801110f..0665fb9 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -15,7 +15,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #include "rockchip_drm_drv.h"
-- 
1.9.1

[PATCH 2/6] drm/rockchip: fb: add missing header

[Mark Yao]

From: John Keeping 

This fixes the following sparse warnings:

drivers/gpu/drm/rockchip/rockchip_drm_fb.c:32:23: warning: symbol 
'rockchip_fb_get_gem_obj' was not declared. Should it be static?
drivers/gpu/drm/rockchip/rockchip_drm_fb.c:315:24: warning: symbol 
'rockchip_drm_framebuffer_init' was not declared. Should it be static?
drivers/gpu/drm/rockchip/rockchip_drm_fb.c:329:6: warning: symbol 
'rockchip_drm_mode_config_init' was not declared. Should it be static?

Signed-off-by: John Keeping 
Signed-off-by: Mark Yao 
---
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
index 20f12bc..4fe2ab3 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
@@ -20,6 +20,7 @@
 #include 
 
 #include "rockchip_drm_drv.h"
+#include "rockchip_drm_fb.h"
 #include "rockchip_drm_gem.h"
 
 #define to_rockchip_fb(x) container_of(x, struct rockchip_drm_fb, fb)
-- 
1.9.1

[PATCH 0/6] drm/rockchip: some fixes

[Mark Yao]

Here are some fixes for drm/rockchip:

These following patches were sent to upstream, seems no doubt about them,
I just rebase them to newest Dave's branch and resent.
  drm/rockchip: vop: correct the source size of uv scale factor setting
  drm/rockchip: vop: add uv_vir register field for RK3036 VOP
  drm/rockchip: fix "should it be static?" warnings
  drm/rockchip: fb: add missing header
  drm/rockchip: dw_hdmi: remove unused #include

This patch is new one, only register rename
  drm/rockchip: vop: correct rk3036 register define

John Keeping (3):
  drm/rockchip: dw_hdmi: remove unused #include
  drm/rockchip: fb: add missing header
  drm/rockchip: fix "should it be static?" warnings

Mark Yao (2):
  drm/rockchip: vop: correct the source size of uv scale factor setting
  drm/rockchip: vop: correct rk3036 register define

Yakir Yang (1):
  drm/rockchip: vop: add uv_vir register field for RK3036 VOP

 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 1 -
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 2 +-
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c  | 3 ++-
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 8 
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 7 ---
 5 files changed, 11 insertions(+), 10 deletions(-)

-- 
1.9.1

[PATCH 4/6] drm/rockchip: vop: add uv_vir register field for RK3036 VOP

[Mark Yao]

From: Yakir Yang 

The WIN0 of RK3036 VOP could support YUV data format, but driver
forget to add the uv_vir register field for it.

Signed-off-by: Yakir Yang 
Signed-off-by: Mark Yao 
---
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c 
b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index 52661d1..a348a7a 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -210,6 +210,7 @@ static const struct vop_win_phy rk3036_win0_data = {
.yrgb_mst = VOP_REG(RK3036_WIN0_YRGB_MST, 0x, 0),
.uv_mst = VOP_REG(RK3036_WIN0_CBR_MST, 0x, 0),
.yrgb_vir = VOP_REG(RK3036_WIN0_VIR, 0x, 0),
+   .uv_vir = VOP_REG(RK3036_WIN0_VIR, 0x1fff, 16),
 };
 
 static const struct vop_win_phy rk3036_win1_data = {
-- 
1.9.1

[PATCH 3/6] drm/rockchip: fix "should it be static?" warnings

[Mark Yao]

From: John Keeping 

Combined with the previous commit, this fixes all of the sparse warnings
in drm/rockchip.

Signed-off-by: John Keeping 
Signed-off-by: Mark Yao 
---
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 2 +-
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c  | 2 +-
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 4 ++--
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 2 +-
 4 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index d665fb0..7216180 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -257,7 +257,7 @@ static void rockchip_drm_unbind(struct device *dev)
dev_set_drvdata(dev, NULL);
 }
 
-void rockchip_drm_lastclose(struct drm_device *dev)
+static void rockchip_drm_lastclose(struct drm_device *dev)
 {
struct rockchip_drm_private *priv = dev->dev_private;
 
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
index 4fe2ab3..b33debc 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
@@ -246,7 +246,7 @@ rockchip_atomic_commit_tail(struct drm_atomic_state *state)
drm_atomic_helper_cleanup_planes(dev, state);
 }
 
-struct drm_mode_config_helper_funcs rockchip_mode_config_helpers = {
+static struct drm_mode_config_helper_funcs rockchip_mode_config_helpers = {
.atomic_commit_tail = rockchip_atomic_commit_tail,
 };
 
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 6255e5b..e01c435 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -798,7 +798,7 @@ static const struct drm_plane_helper_funcs 
plane_helper_funcs = {
.atomic_disable = vop_plane_atomic_disable,
 };
 
-void vop_atomic_plane_reset(struct drm_plane *plane)
+static void vop_atomic_plane_reset(struct drm_plane *plane)
 {
struct vop_plane_state *vop_plane_state =
to_vop_plane_state(plane->state);
@@ -815,7 +815,7 @@ void vop_atomic_plane_reset(struct drm_plane *plane)
plane->state->plane = plane;
 }
 
-struct drm_plane_state *
+static struct drm_plane_state *
 vop_atomic_plane_duplicate_state(struct drm_plane *plane)
 {
struct vop_plane_state *old_vop_plane_state;
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c 
b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index 3166b46..52661d1 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -299,7 +299,7 @@ static int vop_remove(struct platform_device *pdev)
return 0;
 }
 
-struct platform_driver vop_platform_driver = {
+static struct platform_driver vop_platform_driver = {
.probe = vop_probe,
.remove = vop_remove,
.driver = {
-- 
1.9.1

[PATCH 0/6] drm/rockchip: some fixes

[Mark Yao]

Here are some fixes for drm/rockchip:

These following patches were sent to upstream, seems no doubt about them,
I just rebase them to newest Dave's branch and resent.
  drm/rockchip: vop: correct the source size of uv scale factor setting
  drm/rockchip: vop: add uv_vir register field for RK3036 VOP
  drm/rockchip: fix "should it be static?" warnings
  drm/rockchip: fb: add missing header
  drm/rockchip: dw_hdmi: remove unused #include

This patch is new one, only register rename
  drm/rockchip: vop: correct rk3036 register define

John Keeping (3):
  drm/rockchip: dw_hdmi: remove unused #include
  drm/rockchip: fb: add missing header
  drm/rockchip: fix "should it be static?" warnings

Mark Yao (2):
  drm/rockchip: vop: correct the source size of uv scale factor setting
  drm/rockchip: vop: correct rk3036 register define

Yakir Yang (1):
  drm/rockchip: vop: add uv_vir register field for RK3036 VOP

 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 1 -
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 2 +-
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c  | 3 ++-
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 8 
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 7 ---
 5 files changed, 11 insertions(+), 10 deletions(-)

-- 
1.9.1

[PATCH 4/6] drm/rockchip: vop: add uv_vir register field for RK3036 VOP

[Mark Yao]

From: Yakir Yang 

The WIN0 of RK3036 VOP could support YUV data format, but driver
forget to add the uv_vir register field for it.

Signed-off-by: Yakir Yang 
Signed-off-by: Mark Yao 
---
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c 
b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index 52661d1..a348a7a 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -210,6 +210,7 @@ static const struct vop_win_phy rk3036_win0_data = {
.yrgb_mst = VOP_REG(RK3036_WIN0_YRGB_MST, 0x, 0),
.uv_mst = VOP_REG(RK3036_WIN0_CBR_MST, 0x, 0),
.yrgb_vir = VOP_REG(RK3036_WIN0_VIR, 0x, 0),
+   .uv_vir = VOP_REG(RK3036_WIN0_VIR, 0x1fff, 16),
 };
 
 static const struct vop_win_phy rk3036_win1_data = {
-- 
1.9.1

[PATCH 3/6] drm/rockchip: fix "should it be static?" warnings

[Mark Yao]

From: John Keeping 

Combined with the previous commit, this fixes all of the sparse warnings
in drm/rockchip.

Signed-off-by: John Keeping 
Signed-off-by: Mark Yao 
---
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 2 +-
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c  | 2 +-
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 4 ++--
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 2 +-
 4 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index d665fb0..7216180 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -257,7 +257,7 @@ static void rockchip_drm_unbind(struct device *dev)
dev_set_drvdata(dev, NULL);
 }
 
-void rockchip_drm_lastclose(struct drm_device *dev)
+static void rockchip_drm_lastclose(struct drm_device *dev)
 {
struct rockchip_drm_private *priv = dev->dev_private;
 
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
index 4fe2ab3..b33debc 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
@@ -246,7 +246,7 @@ rockchip_atomic_commit_tail(struct drm_atomic_state *state)
drm_atomic_helper_cleanup_planes(dev, state);
 }
 
-struct drm_mode_config_helper_funcs rockchip_mode_config_helpers = {
+static struct drm_mode_config_helper_funcs rockchip_mode_config_helpers = {
.atomic_commit_tail = rockchip_atomic_commit_tail,
 };
 
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 6255e5b..e01c435 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -798,7 +798,7 @@ static const struct drm_plane_helper_funcs 
plane_helper_funcs = {
.atomic_disable = vop_plane_atomic_disable,
 };
 
-void vop_atomic_plane_reset(struct drm_plane *plane)
+static void vop_atomic_plane_reset(struct drm_plane *plane)
 {
struct vop_plane_state *vop_plane_state =
to_vop_plane_state(plane->state);
@@ -815,7 +815,7 @@ void vop_atomic_plane_reset(struct drm_plane *plane)
plane->state->plane = plane;
 }
 
-struct drm_plane_state *
+static struct drm_plane_state *
 vop_atomic_plane_duplicate_state(struct drm_plane *plane)
 {
struct vop_plane_state *old_vop_plane_state;
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c 
b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index 3166b46..52661d1 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -299,7 +299,7 @@ static int vop_remove(struct platform_device *pdev)
return 0;
 }
 
-struct platform_driver vop_platform_driver = {
+static struct platform_driver vop_platform_driver = {
.probe = vop_probe,
.remove = vop_remove,
.driver = {
-- 
1.9.1

Re: [PATCH 1/2] scsi: lpfc: avoid harmless comparison warning

[Martin K. Petersen]

> "Arnd" == Arnd Bergmann  writes:

Arnd> When building with -Wextra, we get a lot of warnings for the lpfc
Arnd> driver concerning expressions that are always true, starting with:

Arnd> drivers/scsi/lpfc/lpfc_attr.c: In function
Arnd> 'lpfc_enable_npiv_init': drivers/scsi/lpfc/lpfc_attr.c:2786:77:
Arnd> error: comparison of unsigned expression >= 0 is always true
Arnd> [-Werror=type-limits] drivers/scsi/lpfc/lpfc_attr.c: In function
Arnd> 'lpfc_enable_rrq_init': drivers/scsi/lpfc/lpfc_attr.c:2802:76:
Arnd> error: comparison of unsigned expression >= 0 is always true
Arnd> [-Werror=type-limits] drivers/scsi/lpfc/lpfc_attr.c: In function
Arnd> 'lpfc_suppress_link_up_init':
Arnd> drivers/scsi/lpfc/lpfc_attr.c:2812:2050: error: comparison of
Arnd> unsigned expression >= 0 is always true [-Werror=type-limits]
Arnd> drivers/scsi/lpfc/lpfc_attr.c: In function
Arnd> 'lpfc_log_verbose_init': drivers/scsi/lpfc/lpfc_attr.c:3064:1930:
Arnd> error: comparison of unsigned expression >= 0 is always true
Arnd> [-Werror=type-limits]

James, Dick: Please review!

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH 1/2] scsi: lpfc: avoid harmless comparison warning

[Martin K. Petersen]

> "Arnd" == Arnd Bergmann  writes:

Arnd> When building with -Wextra, we get a lot of warnings for the lpfc
Arnd> driver concerning expressions that are always true, starting with:

Arnd> drivers/scsi/lpfc/lpfc_attr.c: In function
Arnd> 'lpfc_enable_npiv_init': drivers/scsi/lpfc/lpfc_attr.c:2786:77:
Arnd> error: comparison of unsigned expression >= 0 is always true
Arnd> [-Werror=type-limits] drivers/scsi/lpfc/lpfc_attr.c: In function
Arnd> 'lpfc_enable_rrq_init': drivers/scsi/lpfc/lpfc_attr.c:2802:76:
Arnd> error: comparison of unsigned expression >= 0 is always true
Arnd> [-Werror=type-limits] drivers/scsi/lpfc/lpfc_attr.c: In function
Arnd> 'lpfc_suppress_link_up_init':
Arnd> drivers/scsi/lpfc/lpfc_attr.c:2812:2050: error: comparison of
Arnd> unsigned expression >= 0 is always true [-Werror=type-limits]
Arnd> drivers/scsi/lpfc/lpfc_attr.c: In function
Arnd> 'lpfc_log_verbose_init': drivers/scsi/lpfc/lpfc_attr.c:3064:1930:
Arnd> error: comparison of unsigned expression >= 0 is always true
Arnd> [-Werror=type-limits]

James, Dick: Please review!

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [v5 PATCH 5/5] drm/rockchip: cdn-dp: add cdn DP support for rk3399

[Chris Zhong]

Hi Sean

Thanks for your detailed review. I'm working to modify most of code 
according to comment.

And there is reply for some comment

On 07/13/2016 09:59 PM, Sean Paul wrote:

On Tue, Jul 12, 2016 at 8:09 AM, Chris Zhong  wrote:

Add support for cdn DP controller which is embedded in the rk3399
SoCs. The DP is compliant with DisplayPort Specification,
Version 1.3, This IP is compatible with the rockchip type-c PHY IP.
There is a uCPU in DP controller, it need a firmware to work,
please put the firmware file to /lib/firmware/cdn/dptx.bin. The
uCPU in charge of aux communication and link training, the host use
mailbox to communicate with the ucpu.
The dclk pin_pol of vop must not be invert for DP.

Signed-off-by: Chris Zhong 

---

Changes in v5:
- alphabetical order
- do not use long, use u32 or u64
- return MODE_CLOCK_HIGH when requested > actual
- Optimized Coding Style
- add a formula to get better tu size and symbol value.

Changes in v4:
- use phy framework to control DP phy
- support 2 phys

Changes in v3:
- use EXTCON_DISP_DP and EXTCON_DISP_DP_ALT cable to get dp port state.
- reset spdif before config it
- modify the firmware clk to 100Mhz
- retry load firmware if fw file is requested too early

Changes in v2:
- Alphabetic order
- remove excess error message
- use define clk_rate
- check all return value
- remove dev_set_name(dp->dev, "cdn-dp");
- use schedule_delayed_work
- remove never-called functions
- remove some unnecessary ()

Changes in v1:
- use extcon API
- use hdmi-codec for the DP Asoc
- do not initialize the "ret"
- printk a err log when drm_of_encoder_active_endpoint_id
- modify the dclk pin_pol to a single line

  drivers/gpu/drm/rockchip/Kconfig|   9 +
  drivers/gpu/drm/rockchip/Makefile   |   1 +
  drivers/gpu/drm/rockchip/cdn-dp-core.c  | 761 
  drivers/gpu/drm/rockchip/cdn-dp-core.h  | 113 +
  drivers/gpu/drm/rockchip/cdn-dp-reg.c   | 740 +++
  drivers/gpu/drm/rockchip/cdn-dp-reg.h   | 409 +++

Could you explain the file naming convention in the rk driver? We've
got analogix_dp-rockchip.c, dw_hdmi-rockchip.c, dw-mipi-dsi.c, and now
cdn-dp-(core|reg).[ch]. I'm honestly not sure whether these filenames
are consistent with the rest, but bleh.


cdn is the IP vendor's name
dp is the controller's name.


  drivers/gpu/drm/rockchip/rockchip_drm_vop.c |   6 +-
  drivers/gpu/drm/rockchip/rockchip_drm_vop.h |   2 +
  drivers/gpu/drm/rockchip/rockchip_vop_reg.c |   2 +
  9 files changed, 2042 insertions(+), 1 deletion(-)
  create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-core.c
  create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-core.h
  create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-reg.c
  create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-reg.h

diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index d30bdc3..20da9a8 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -25,6 +25,15 @@ config ROCKCHIP_ANALOGIX_DP
   for the Analogix Core DP driver. If you want to enable DP
   on RK3288 based SoC, you should selet this option.

+config ROCKCHIP_CDN_DP
+tristate "Rockchip cdn DP"
+depends on DRM_ROCKCHIP
+help
+ This selects support for Rockchip SoC specific extensions
+ for the cdn Dp driver. If you want to enable Dp on

s/Dp/DP/


+ RK3399 based SoC, you should selet this

s/selet/select/


+ option.
+
  config ROCKCHIP_DW_HDMI
  tristate "Rockchip specific extensions for Synopsys DW HDMI"
  depends on DRM_ROCKCHIP
diff --git a/drivers/gpu/drm/rockchip/Makefile 
b/drivers/gpu/drm/rockchip/Makefile
index 05d0713..abdecd5 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -7,6 +7,7 @@ rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o \
  rockchipdrm-$(CONFIG_DRM_FBDEV_EMULATION) += rockchip_drm_fbdev.o

  obj-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o
+obj-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o cdn-dp-reg.o
  obj-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
  obj-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
  obj-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c 
b/drivers/gpu/drm/rockchip/cdn-dp-core.c
new file mode 100644
index 000..5b8a15e
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
@@ -0,0 +1,761 @@
+/*
+ * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
+ * Author: Chris Zhong 
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ 

Re: [v5 PATCH 5/5] drm/rockchip: cdn-dp: add cdn DP support for rk3399

[Chris Zhong]

Hi Sean

Thanks for your detailed review. I'm working to modify most of code 
according to comment.

And there is reply for some comment

On 07/13/2016 09:59 PM, Sean Paul wrote:

On Tue, Jul 12, 2016 at 8:09 AM, Chris Zhong  wrote:

Add support for cdn DP controller which is embedded in the rk3399
SoCs. The DP is compliant with DisplayPort Specification,
Version 1.3, This IP is compatible with the rockchip type-c PHY IP.
There is a uCPU in DP controller, it need a firmware to work,
please put the firmware file to /lib/firmware/cdn/dptx.bin. The
uCPU in charge of aux communication and link training, the host use
mailbox to communicate with the ucpu.
The dclk pin_pol of vop must not be invert for DP.

Signed-off-by: Chris Zhong 

---

Changes in v5:
- alphabetical order
- do not use long, use u32 or u64
- return MODE_CLOCK_HIGH when requested > actual
- Optimized Coding Style
- add a formula to get better tu size and symbol value.

Changes in v4:
- use phy framework to control DP phy
- support 2 phys

Changes in v3:
- use EXTCON_DISP_DP and EXTCON_DISP_DP_ALT cable to get dp port state.
- reset spdif before config it
- modify the firmware clk to 100Mhz
- retry load firmware if fw file is requested too early

Changes in v2:
- Alphabetic order
- remove excess error message
- use define clk_rate
- check all return value
- remove dev_set_name(dp->dev, "cdn-dp");
- use schedule_delayed_work
- remove never-called functions
- remove some unnecessary ()

Changes in v1:
- use extcon API
- use hdmi-codec for the DP Asoc
- do not initialize the "ret"
- printk a err log when drm_of_encoder_active_endpoint_id
- modify the dclk pin_pol to a single line

  drivers/gpu/drm/rockchip/Kconfig|   9 +
  drivers/gpu/drm/rockchip/Makefile   |   1 +
  drivers/gpu/drm/rockchip/cdn-dp-core.c  | 761 
  drivers/gpu/drm/rockchip/cdn-dp-core.h  | 113 +
  drivers/gpu/drm/rockchip/cdn-dp-reg.c   | 740 +++
  drivers/gpu/drm/rockchip/cdn-dp-reg.h   | 409 +++

Could you explain the file naming convention in the rk driver? We've
got analogix_dp-rockchip.c, dw_hdmi-rockchip.c, dw-mipi-dsi.c, and now
cdn-dp-(core|reg).[ch]. I'm honestly not sure whether these filenames
are consistent with the rest, but bleh.


cdn is the IP vendor's name
dp is the controller's name.


  drivers/gpu/drm/rockchip/rockchip_drm_vop.c |   6 +-
  drivers/gpu/drm/rockchip/rockchip_drm_vop.h |   2 +
  drivers/gpu/drm/rockchip/rockchip_vop_reg.c |   2 +
  9 files changed, 2042 insertions(+), 1 deletion(-)
  create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-core.c
  create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-core.h
  create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-reg.c
  create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-reg.h

diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index d30bdc3..20da9a8 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -25,6 +25,15 @@ config ROCKCHIP_ANALOGIX_DP
   for the Analogix Core DP driver. If you want to enable DP
   on RK3288 based SoC, you should selet this option.

+config ROCKCHIP_CDN_DP
+tristate "Rockchip cdn DP"
+depends on DRM_ROCKCHIP
+help
+ This selects support for Rockchip SoC specific extensions
+ for the cdn Dp driver. If you want to enable Dp on

s/Dp/DP/


+ RK3399 based SoC, you should selet this

s/selet/select/


+ option.
+
  config ROCKCHIP_DW_HDMI
  tristate "Rockchip specific extensions for Synopsys DW HDMI"
  depends on DRM_ROCKCHIP
diff --git a/drivers/gpu/drm/rockchip/Makefile 
b/drivers/gpu/drm/rockchip/Makefile
index 05d0713..abdecd5 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -7,6 +7,7 @@ rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o \
  rockchipdrm-$(CONFIG_DRM_FBDEV_EMULATION) += rockchip_drm_fbdev.o

  obj-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o
+obj-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o cdn-dp-reg.o
  obj-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
  obj-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
  obj-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c 
b/drivers/gpu/drm/rockchip/cdn-dp-core.c
new file mode 100644
index 000..5b8a15e
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
@@ -0,0 +1,761 @@
+/*
+ * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
+ * Author: Chris Zhong 
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the

Request for discussion

[Bun Sam]

Good day,

I am Bun Sam. I work with one of the major banks in Cambodia as the director of 
audit. I have a proposal for you, a very urgent and quick business that will be 
completed in 12 working days. I have just discovered documents relating to 
funds belonging to a deceased client of our bank,

I went through all the related documents to the funds and I discovered no 
listed next of kin to inherit the funds which has been in our bank for more 
than 7 years now. I need your cooperation in getting the funds, I have the 
power to list you as the beneficiary of the funds and have the funds 
transferred to you.

If you are interested, do get back to me so I can provide you with the full 
details.

Regards
Bun Sam.

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Request for discussion

[Bun Sam]

Good day,

I am Bun Sam. I work with one of the major banks in Cambodia as the director of 
audit. I have a proposal for you, a very urgent and quick business that will be 
completed in 12 working days. I have just discovered documents relating to 
funds belonging to a deceased client of our bank,

I went through all the related documents to the funds and I discovered no 
listed next of kin to inherit the funds which has been in our bank for more 
than 7 years now. I need your cooperation in getting the funds, I have the 
power to list you as the beneficiary of the funds and have the funds 
transferred to you.

If you are interested, do get back to me so I can provide you with the full 
details.

Regards
Bun Sam.

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: [PATCH v2 0/5] firmware: add SmPL grammar to avoid issues

[Luis R. Rodriguez]

On Thu, Jul 14, 2016 at 10:23:36AM +0800, Fengguang Wu wrote:
> On Thu, Jul 14, 2016 at 04:15:01AM +0200, Luis R. Rodriguez wrote:
> >On Thu, Jul 14, 2016 at 07:52:07AM +0800, Fengguang Wu wrote:
> >>Hi Luis,
> >>
> >>On Thu, Jul 07, 2016 at 02:56:44AM +0200, Luis R. Rodriguez wrote:
> >>>On Thu, Jun 16, 2016 at 03:54:16PM -0700, Luis R. Rodriguez wrote:
> The firmware API has had some issues a while ago, some of this is
> not well documented, and its still hard to grasp. This documents
> some of these issues, adds SmPL grammar rules to enable us to hunt
> for issues, and annotations to help us with our effort to finally
> compartamentalize that pesky usermode helper.
> 
> Previously this was just one patch, the grammar rule to help
> find request firmware API users on init or probe, this series
> extends that effort with usermode helper grammar rules, and some
> annotations and documentation on the firmware_class driver to
> avoid further issues. Documenting the usermode helper and making
> it clear why we cannot remove it is important for analysis for
> the next series which adds the new flexible sysdata firmware API.
> 
> This series depends on the coccicheck series which enables
> annotations on coccinelle patches to require a specific
> version of coccinelle [0], as such coordination with Michal is
> in order.
> >>>
> >>>Michal is out until July 11, and upon further thought such coordination
> >>>is not need, the annotation is in place as comments and as such
> >>>merging this now won't have any negative effects other than the version
> >>>check. Also the patches in question for the coccicheck change are all
> >>>acked now and I expect them to be merged anyway.
> >>>
> >>>Which tree should firmware changes go through ?
> >>
> This series is also further extended next with the new sydata
> API, the full set of changes is available on my linux-next tree [1].
> 
> Perhaps now a good time to discuss -- if 0-day should enable the rule
> scripts/coccinelle/api/request_firmware-usermode.cocci to be called on
> every 0-day iteration, it runs rather fast and it should help police
> against avoiding futher explicit users of the usermode helper.
> >>>
> >>>And if we are going to merge this anyone oppose enabling hunting
> >>>for further explicit users of the usermode helper using grammar through
> >>>0-day ?
> >>
> >>When *.cocci scripts lands upstream they'll be auto picked up by the
> >>0-day bot to guard new patches/commits.
> >
> >Great thanks!
> >
> >>Are there further steps 0-day should do for request_firmware-upstream.cocci?
> >
> >It just requires coccinelle >= 1.0.5.
> 
> That looks easy. 

Nice!

> When do you estimate the script will land upstream?

Well, this series has gone by a while now without any complaints, so
I was poking to see if they can be merged now.

> So we can make sure upgrade coccinelle before that time.

There is another series which modernizes coccicheck [0] for which I just poked
at as a well [1], one change which may be of importance to you is groks the
Requires: tag on top of an SmPL patch, with that we simply just skip an SmPL
patch if the version of coccinelle is older than the one specified, with that
in place you can just upgrade when you want -- you'd just gain support for more
SmPL patches when you do. Without that coccinelle would not work (fail) on the
SmPL patch when tried. For this reason I originally had suggested perhaps
this series should be carried by Michal.

[0] 
https://lkml.kernel.org/r/1467238499-10889-1-git-send-email-mcg...@kernel.org
[1] https://lkml.kernel.org/r/20160713214539.ge6...@wotan.suse.de

  Luis

Re: [PATCH v2 0/5] firmware: add SmPL grammar to avoid issues

[Luis R. Rodriguez]

On Thu, Jul 14, 2016 at 10:23:36AM +0800, Fengguang Wu wrote:
> On Thu, Jul 14, 2016 at 04:15:01AM +0200, Luis R. Rodriguez wrote:
> >On Thu, Jul 14, 2016 at 07:52:07AM +0800, Fengguang Wu wrote:
> >>Hi Luis,
> >>
> >>On Thu, Jul 07, 2016 at 02:56:44AM +0200, Luis R. Rodriguez wrote:
> >>>On Thu, Jun 16, 2016 at 03:54:16PM -0700, Luis R. Rodriguez wrote:
> The firmware API has had some issues a while ago, some of this is
> not well documented, and its still hard to grasp. This documents
> some of these issues, adds SmPL grammar rules to enable us to hunt
> for issues, and annotations to help us with our effort to finally
> compartamentalize that pesky usermode helper.
> 
> Previously this was just one patch, the grammar rule to help
> find request firmware API users on init or probe, this series
> extends that effort with usermode helper grammar rules, and some
> annotations and documentation on the firmware_class driver to
> avoid further issues. Documenting the usermode helper and making
> it clear why we cannot remove it is important for analysis for
> the next series which adds the new flexible sysdata firmware API.
> 
> This series depends on the coccicheck series which enables
> annotations on coccinelle patches to require a specific
> version of coccinelle [0], as such coordination with Michal is
> in order.
> >>>
> >>>Michal is out until July 11, and upon further thought such coordination
> >>>is not need, the annotation is in place as comments and as such
> >>>merging this now won't have any negative effects other than the version
> >>>check. Also the patches in question for the coccicheck change are all
> >>>acked now and I expect them to be merged anyway.
> >>>
> >>>Which tree should firmware changes go through ?
> >>
> This series is also further extended next with the new sydata
> API, the full set of changes is available on my linux-next tree [1].
> 
> Perhaps now a good time to discuss -- if 0-day should enable the rule
> scripts/coccinelle/api/request_firmware-usermode.cocci to be called on
> every 0-day iteration, it runs rather fast and it should help police
> against avoiding futher explicit users of the usermode helper.
> >>>
> >>>And if we are going to merge this anyone oppose enabling hunting
> >>>for further explicit users of the usermode helper using grammar through
> >>>0-day ?
> >>
> >>When *.cocci scripts lands upstream they'll be auto picked up by the
> >>0-day bot to guard new patches/commits.
> >
> >Great thanks!
> >
> >>Are there further steps 0-day should do for request_firmware-upstream.cocci?
> >
> >It just requires coccinelle >= 1.0.5.
> 
> That looks easy. 

Nice!

> When do you estimate the script will land upstream?

Well, this series has gone by a while now without any complaints, so
I was poking to see if they can be merged now.

> So we can make sure upgrade coccinelle before that time.

There is another series which modernizes coccicheck [0] for which I just poked
at as a well [1], one change which may be of importance to you is groks the
Requires: tag on top of an SmPL patch, with that we simply just skip an SmPL
patch if the version of coccinelle is older than the one specified, with that
in place you can just upgrade when you want -- you'd just gain support for more
SmPL patches when you do. Without that coccinelle would not work (fail) on the
SmPL patch when tried. For this reason I originally had suggested perhaps
this series should be carried by Michal.

[0] 
https://lkml.kernel.org/r/1467238499-10889-1-git-send-email-mcg...@kernel.org
[1] https://lkml.kernel.org/r/20160713214539.ge6...@wotan.suse.de

  Luis

Re: [GIT PULL] phy: for 4.8 merge window

[Greg KH]

On Tue, Jul 05, 2016 at 10:53:47AM +0530, Kishon Vijay Abraham I wrote:
> Hi Greg,
> 
> Please find the pull request for 4.8 merge window below.
> 
> Now the controller can configure the mode in which the PHY should
> work using the new phy_set_mode API. This was added by David Lechner
> required for da8xx-usb phy (used by MUSB). For this I created a signed
> tag 'phy-set-mode-v2' since the phy_set_mode API is called from musb
> driver which is not part of this pull request. This also adds a new
> phy driver for USB PHY in DA8xx SoC and includes other minor cleanups
> and fixes.
> 
> Consider merging this for the next merge window. Let me know if I have
> to change something.
> 
> The following changes since commit 04e59a0211ff012ba60c00baca673482570784e9:
> 
>   phy-sun4i-usb: Fix irq free conditions to match request conditions 
> (2016-06-22 11:33:46 +0530)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git 
> tags/phy-for-4.8-rc1

Now pulled, thanks.

greg k-h

Re: [GIT PULL] phy: for 4.8 merge window

[Greg KH]

On Tue, Jul 05, 2016 at 10:53:47AM +0530, Kishon Vijay Abraham I wrote:
> Hi Greg,
> 
> Please find the pull request for 4.8 merge window below.
> 
> Now the controller can configure the mode in which the PHY should
> work using the new phy_set_mode API. This was added by David Lechner
> required for da8xx-usb phy (used by MUSB). For this I created a signed
> tag 'phy-set-mode-v2' since the phy_set_mode API is called from musb
> driver which is not part of this pull request. This also adds a new
> phy driver for USB PHY in DA8xx SoC and includes other minor cleanups
> and fixes.
> 
> Consider merging this for the next merge window. Let me know if I have
> to change something.
> 
> The following changes since commit 04e59a0211ff012ba60c00baca673482570784e9:
> 
>   phy-sun4i-usb: Fix irq free conditions to match request conditions 
> (2016-06-22 11:33:46 +0530)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git 
> tags/phy-for-4.8-rc1

Now pulled, thanks.

greg k-h

Re: [git pull] stm class/intel_th: Updates for char-misc-linus

[Greg KH]

On Fri, Jul 01, 2016 at 12:15:37PM +0300, Alexander Shishkin wrote:
> Hi Greg,
> 
> These are fixes I have queued for the v4.7. Please consider pulling into
> char-misc-linus.
> 
> The following changes since commit 60cef77f9ba419fec6c41bc4e3fecb9bf426f664:
> 
>   intel_th: pci: Add Kaby Lake PCH-H support (2016-06-30 15:39:15 +0300)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/ash/stm.git 
> tags/stm-fixes-for-greg-20160630

It's too late for 4.7, can you resend these with stable@ tags so it gets
into a 4.7-stable release?

thanks,

greg k-h

Re: [git pull] stm class/intel_th: Updates for char-misc-linus

[Greg KH]

On Fri, Jul 01, 2016 at 12:15:37PM +0300, Alexander Shishkin wrote:
> Hi Greg,
> 
> These are fixes I have queued for the v4.7. Please consider pulling into
> char-misc-linus.
> 
> The following changes since commit 60cef77f9ba419fec6c41bc4e3fecb9bf426f664:
> 
>   intel_th: pci: Add Kaby Lake PCH-H support (2016-06-30 15:39:15 +0300)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/ash/stm.git 
> tags/stm-fixes-for-greg-20160630

It's too late for 4.7, can you resend these with stable@ tags so it gets
into a 4.7-stable release?

thanks,

greg k-h

Re: [git pull] stm class/intel_th: Updates for char-misc-next

[Greg KH]

On Fri, Jul 01, 2016 at 02:46:11PM +0300, Alexander Shishkin wrote:
> Hi Greg,
> 
> These are updates I have queued for the v4.8 merge window. Apologies for
> late request. Please consider pulling.
> 
> The following changes since commit af8c34ce6ae32addda3788d54a7e340cad22516b:
> 
>   Linux 4.7-rc2 (2016-06-05 14:31:26 -0700)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/ash/stm.git 
> tags/stm-for-greg-20160701

Pulled and pushed out, thanks.

greg k-h

Re: [git pull] stm class/intel_th: Updates for char-misc-next

[Greg KH]

On Fri, Jul 01, 2016 at 02:46:11PM +0300, Alexander Shishkin wrote:
> Hi Greg,
> 
> These are updates I have queued for the v4.8 merge window. Apologies for
> late request. Please consider pulling.
> 
> The following changes since commit af8c34ce6ae32addda3788d54a7e340cad22516b:
> 
>   Linux 4.7-rc2 (2016-06-05 14:31:26 -0700)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/ash/stm.git 
> tags/stm-for-greg-20160701

Pulled and pushed out, thanks.

greg k-h

Re: [GIT PULL] extcon next for 4.8

[Greg KH]

On Tue, Jul 05, 2016 at 08:04:08PM +0900, Chanwoo Choi wrote:
> Dear Greg,
> 
> This is extcon-next pull request for v4.8. I add detailed description of
> this pull request on below. Please pull extcon with following updates.
> 
> Best Regards,
> Chanwoo Choi
> 
> The following changes since commit 33688abb2802ff3a230bd2441f765477b94cc89e:
> 
>   Linux 4.7-rc4 (2016-06-19 21:30:02 -0700)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git 
> tags/extcon-next-for-4.8

Pulled and pushed out, thanks.

greg k-h

Re: [GIT PULL] extcon next for 4.8

[Greg KH]

On Tue, Jul 05, 2016 at 08:04:08PM +0900, Chanwoo Choi wrote:
> Dear Greg,
> 
> This is extcon-next pull request for v4.8. I add detailed description of
> this pull request on below. Please pull extcon with following updates.
> 
> Best Regards,
> Chanwoo Choi
> 
> The following changes since commit 33688abb2802ff3a230bd2441f765477b94cc89e:
> 
>   Linux 4.7-rc4 (2016-06-19 21:30:02 -0700)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git 
> tags/extcon-next-for-4.8

Pulled and pushed out, thanks.

greg k-h

Re: [PULL] lkdtm update (next)

[Greg KH]

On Thu, Jul 07, 2016 at 11:14:35AM -0700, Kees Cook wrote:
> Hi,
> 
> Please pull these lkdtm changes for next.
> 
> Thanks!
> 
> -Kees
> 
> The following changes since commit e2402b1d214e5d50e807773563d590115a161f45:
> 
>   nvmem: imx-ocotp: Fix assignment warning. (2016-06-25 07:42:55 -0700)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/lkdtm-next

Pulled and pushed out, sorry for the delay.

greg k-h

Re: [PULL] lkdtm update (next)

[Greg KH]

On Thu, Jul 07, 2016 at 11:14:35AM -0700, Kees Cook wrote:
> Hi,
> 
> Please pull these lkdtm changes for next.
> 
> Thanks!
> 
> -Kees
> 
> The following changes since commit e2402b1d214e5d50e807773563d590115a161f45:
> 
>   nvmem: imx-ocotp: Fix assignment warning. (2016-06-25 07:42:55 -0700)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/lkdtm-next

Pulled and pushed out, sorry for the delay.

greg k-h

[PATCH] dmaengine: qcom_hidma: release the descriptor before the callback

[Sinan Kaya]

There is a race condition between data transfer callback and descriptor
free code. The callback routine may decide to clear the resources even
though the descriptor has not yet been freed.

Instead of calling the callback first and then releasing the memory,
this code is changing the order to return the descriptor back to the
free pool and then call the user provided callback.

Signed-off-by: Sinan Kaya 
---
 drivers/dma/qcom/hidma.c | 26 +++---
 1 file changed, 15 insertions(+), 11 deletions(-)

diff --git a/drivers/dma/qcom/hidma.c b/drivers/dma/qcom/hidma.c
index 41b5c6d..c41696e 100644
--- a/drivers/dma/qcom/hidma.c
+++ b/drivers/dma/qcom/hidma.c
@@ -111,6 +111,7 @@ static void hidma_process_completed(struct hidma_chan 
*mchan)
struct dma_async_tx_descriptor *desc;
dma_cookie_t last_cookie;
struct hidma_desc *mdesc;
+   struct hidma_desc *next;
unsigned long irqflags;
struct list_head list;
 
@@ -122,28 +123,31 @@ static void hidma_process_completed(struct hidma_chan 
*mchan)
spin_unlock_irqrestore(>lock, irqflags);
 
/* Execute callbacks and run dependencies */
-   list_for_each_entry(mdesc, , node) {
-   enum dma_status llstat;
+   list_for_each_entry_safe(mdesc, next, , node) {
+   dma_async_tx_callback callback;
+   void *param;
 
desc = >desc;
 
spin_lock_irqsave(>lock, irqflags);
-   dma_cookie_complete(desc);
+   if (hidma_ll_status(mdma->lldev, mdesc->tre_ch)
+   == DMA_COMPLETE)
+   dma_cookie_complete(desc);
spin_unlock_irqrestore(>lock, irqflags);
 
-   llstat = hidma_ll_status(mdma->lldev, mdesc->tre_ch);
-   if (desc->callback && (llstat == DMA_COMPLETE))
-   desc->callback(desc->callback_param);
+   callback = desc->callback;
+   param = desc->callback_param;
 
last_cookie = desc->cookie;
dma_run_dependencies(desc);
-   }
 
-   /* Free descriptors */
-   spin_lock_irqsave(>lock, irqflags);
-   list_splice_tail_init(, >free);
-   spin_unlock_irqrestore(>lock, irqflags);
+   spin_lock_irqsave(>lock, irqflags);
+   list_move(>node, >free);
+   spin_unlock_irqrestore(>lock, irqflags);
 
+   if (callback)
+   callback(param);
+   }
 }
 
 /*
-- 
1.8.2.1

[PATCH] dmaengine: qcom_hidma: release the descriptor before the callback

[Sinan Kaya]

There is a race condition between data transfer callback and descriptor
free code. The callback routine may decide to clear the resources even
though the descriptor has not yet been freed.

Instead of calling the callback first and then releasing the memory,
this code is changing the order to return the descriptor back to the
free pool and then call the user provided callback.

Signed-off-by: Sinan Kaya 
---
 drivers/dma/qcom/hidma.c | 26 +++---
 1 file changed, 15 insertions(+), 11 deletions(-)

diff --git a/drivers/dma/qcom/hidma.c b/drivers/dma/qcom/hidma.c
index 41b5c6d..c41696e 100644
--- a/drivers/dma/qcom/hidma.c
+++ b/drivers/dma/qcom/hidma.c
@@ -111,6 +111,7 @@ static void hidma_process_completed(struct hidma_chan 
*mchan)
struct dma_async_tx_descriptor *desc;
dma_cookie_t last_cookie;
struct hidma_desc *mdesc;
+   struct hidma_desc *next;
unsigned long irqflags;
struct list_head list;
 
@@ -122,28 +123,31 @@ static void hidma_process_completed(struct hidma_chan 
*mchan)
spin_unlock_irqrestore(>lock, irqflags);
 
/* Execute callbacks and run dependencies */
-   list_for_each_entry(mdesc, , node) {
-   enum dma_status llstat;
+   list_for_each_entry_safe(mdesc, next, , node) {
+   dma_async_tx_callback callback;
+   void *param;
 
desc = >desc;
 
spin_lock_irqsave(>lock, irqflags);
-   dma_cookie_complete(desc);
+   if (hidma_ll_status(mdma->lldev, mdesc->tre_ch)
+   == DMA_COMPLETE)
+   dma_cookie_complete(desc);
spin_unlock_irqrestore(>lock, irqflags);
 
-   llstat = hidma_ll_status(mdma->lldev, mdesc->tre_ch);
-   if (desc->callback && (llstat == DMA_COMPLETE))
-   desc->callback(desc->callback_param);
+   callback = desc->callback;
+   param = desc->callback_param;
 
last_cookie = desc->cookie;
dma_run_dependencies(desc);
-   }
 
-   /* Free descriptors */
-   spin_lock_irqsave(>lock, irqflags);
-   list_splice_tail_init(, >free);
-   spin_unlock_irqrestore(>lock, irqflags);
+   spin_lock_irqsave(>lock, irqflags);
+   list_move(>node, >free);
+   spin_unlock_irqrestore(>lock, irqflags);
 
+   if (callback)
+   callback(param);
+   }
 }
 
 /*
-- 
1.8.2.1

[lkp] [x86/hpet] a28b41ab00: RIP: 0010:[] [] __lock_acquire+0xce/0x649

[kernel test robot]

FYI, we noticed the following commit:

https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git tmp.smp/hotplug
commit a28b41ab00dc93b9b16deda9d9b4b26601444f6d ("x86/hpet: Convert to hotplug 
state machine")

in testcase: boot

on test machine: 2 threads qemu-system-x86_64 -enable-kvm -cpu Nehalem with 
320M memory

caused below changes:


++++
|| e6c408103b | 
a28b41ab00 |
++++
| boot_successes | 0  | 0   
   |
| boot_failures  | 16 | 16  
   |
| genirq:Flags_mismatch_irq##(serial)vs.#(goldfish_pdev_bus) | 16 | 2   
   |
| genirq:Flags_mismatch_irq  | 3  | 
   |
| genirq:Flags_mismatch_irq##(serial)vs.#(gold   | 1  | 
   |
| genirq:Flags_mismatch_irq##(serial)vs  | 1  | 
   |
| RIP:__lock_acquire | 0  | 14  
   |
| Kernel_panic-not_syncing:Fatal_exception_in_interrupt  | 0  | 5   
   |
| backtrace:populate_rootfs  | 0  | 14  
   |
| backtrace:kernel_init_freeable | 0  | 14  
   |
| Kernel_panic-not_syncing:Fatal_exception   | 0  | 9   
   |
| backtrace:vfs_write| 0  | 12  
   |
| backtrace:SyS_write| 0  | 12  
   |
| genirq:Flags_mismatch_irq##(serial)vs.#(goldfis| 0  | 1   
   |
++++



[1.659021] Unpacking initramfs...
[1.696928] workqueue: round-robin CPU selection forced, expect performance 
impact
[1.702995] general protection fault:  [#1]
[1.704143] Modules linked in:
[1.704950] CPU: 0 PID: 1 Comm: swapper Not tainted 4.7.0-rc7-00193-ga28b41a 
#1
[1.709158] task: 880012052000 ti: 880012054000 task.ti: 
880012054000
[1.713142] RIP: 0010:[]  [] 
__lock_acquire+0xce/0x649
[1.718980] RSP: :880012057958  EFLAGS: 00010086
[1.720283] RAX: 8d009545e5358b48 RBX: 880012052000 RCX: 
[1.723761] RDX:  RSI:  RDI: 8482509c
[1.732066] RBP: 880012057990 R08: 0001 R09: 0001
[1.735294] R10:  R11: 024c R12: 8482509c
[1.742172] R13: 8482509c R14: 0001 R15: 
[1.745787] FS:  () GS:85022000() 
knlGS:
[1.758843] CS:  0010 DS:  ES:  CR0: 80050033
[1.760295] CR2:  CR3: 0500c000 CR4: 06f0
[1.762067] Stack:
[1.762570]  0001 8800 0046 
880012052000
[1.765942]  8482509c   
8800120579f0
[1.767859]  84885938  84876eac 

[1.771214] Call Trace:
[1.775343]  [] ? hpet_disable+0x6c/0xaf
[1.777641]  [] lock_acquire+0x7e/0xa3
[1.778951]  [] ? try_to_wake_up+0x2c/0x166
[1.785446]  [] ? hpet_disable+0x54/0xaf
[1.786934]  [] ? hpet_disable+0x54/0xaf
[1.789200]  [] _raw_spin_lock_irqsave+0x3d/0x4f
[1.790751]  [] ? try_to_wake_up+0x2c/0x166
[1.795845]  [] ? hpet_msi_set_periodic+0x11/0x11
[1.804788]  [] try_to_wake_up+0x2c/0x166
[1.806206]  [] ? __add_to_page_cache_locked+0x1e2/0x222
[1.807936]  [] wake_up_process+0x10/0x12
[1.809329]  [] wakeup_softirqd+0x1d/0x1f
[1.812342]  [] raise_softirq_irqoff+0x27/0x29
[1.813837]  [] raise_softirq+0x23/0x49
[1.815192]  [] rcu_sched_qs+0x80/0xa7
[1.822906]  [] __schedule+0x11b/0x51a
[1.824266]  [] preempt_schedule_common+0x1d/0x31
[1.826627]  [] _cond_resched+0x13/0x1f
[1.832048]  [] generic_perform_write+0x100/0x19d
[1.835279]  [] __generic_file_write_iter+0xfd/0x164
[1.845691]  [] generic_file_write_iter+0x48/0x92
[1.847286]  [] __vfs_write+0x77/0xa0
[1.848452]  [] vfs_write+0xa2/0xc8
[1.849698]  [] ? initrd_load+0x3f/0x3f
[1.852370]  [] SyS_write+0x4b/0x7b
[1.853642]  [] xwrite+0x26/0x5c
[1.855805]  [] do_copy+0x89/0xb6
[1.860184]  [] write_buffer+0x23/0x34
[1.861541]  [] flush_buffer+0x71/0x8e
[1.862916]  [] __gunzip+0x266/0x306
[1.873568]  [] ? bunzip2+0x3c7/0x3c7
[1.878009]  [] ? write_buffer+0x34/0x34
[1.881612]  [] ? do_early_param+0x8f/0x8f
[1.883092]  [] gunzip+0x11/0x13
[1.884173]  [] ? initrd_load+0x3f/0x3f
[

[lkp] [x86/hpet] a28b41ab00: RIP: 0010:[] [] __lock_acquire+0xce/0x649

[kernel test robot]

FYI, we noticed the following commit:

https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git tmp.smp/hotplug
commit a28b41ab00dc93b9b16deda9d9b4b26601444f6d ("x86/hpet: Convert to hotplug 
state machine")

in testcase: boot

on test machine: 2 threads qemu-system-x86_64 -enable-kvm -cpu Nehalem with 
320M memory

caused below changes:


++++
|| e6c408103b | 
a28b41ab00 |
++++
| boot_successes | 0  | 0   
   |
| boot_failures  | 16 | 16  
   |
| genirq:Flags_mismatch_irq##(serial)vs.#(goldfish_pdev_bus) | 16 | 2   
   |
| genirq:Flags_mismatch_irq  | 3  | 
   |
| genirq:Flags_mismatch_irq##(serial)vs.#(gold   | 1  | 
   |
| genirq:Flags_mismatch_irq##(serial)vs  | 1  | 
   |
| RIP:__lock_acquire | 0  | 14  
   |
| Kernel_panic-not_syncing:Fatal_exception_in_interrupt  | 0  | 5   
   |
| backtrace:populate_rootfs  | 0  | 14  
   |
| backtrace:kernel_init_freeable | 0  | 14  
   |
| Kernel_panic-not_syncing:Fatal_exception   | 0  | 9   
   |
| backtrace:vfs_write| 0  | 12  
   |
| backtrace:SyS_write| 0  | 12  
   |
| genirq:Flags_mismatch_irq##(serial)vs.#(goldfis| 0  | 1   
   |
++++



[1.659021] Unpacking initramfs...
[1.696928] workqueue: round-robin CPU selection forced, expect performance 
impact
[1.702995] general protection fault:  [#1]
[1.704143] Modules linked in:
[1.704950] CPU: 0 PID: 1 Comm: swapper Not tainted 4.7.0-rc7-00193-ga28b41a 
#1
[1.709158] task: 880012052000 ti: 880012054000 task.ti: 
880012054000
[1.713142] RIP: 0010:[]  [] 
__lock_acquire+0xce/0x649
[1.718980] RSP: :880012057958  EFLAGS: 00010086
[1.720283] RAX: 8d009545e5358b48 RBX: 880012052000 RCX: 
[1.723761] RDX:  RSI:  RDI: 8482509c
[1.732066] RBP: 880012057990 R08: 0001 R09: 0001
[1.735294] R10:  R11: 024c R12: 8482509c
[1.742172] R13: 8482509c R14: 0001 R15: 
[1.745787] FS:  () GS:85022000() 
knlGS:
[1.758843] CS:  0010 DS:  ES:  CR0: 80050033
[1.760295] CR2:  CR3: 0500c000 CR4: 06f0
[1.762067] Stack:
[1.762570]  0001 8800 0046 
880012052000
[1.765942]  8482509c   
8800120579f0
[1.767859]  84885938  84876eac 

[1.771214] Call Trace:
[1.775343]  [] ? hpet_disable+0x6c/0xaf
[1.777641]  [] lock_acquire+0x7e/0xa3
[1.778951]  [] ? try_to_wake_up+0x2c/0x166
[1.785446]  [] ? hpet_disable+0x54/0xaf
[1.786934]  [] ? hpet_disable+0x54/0xaf
[1.789200]  [] _raw_spin_lock_irqsave+0x3d/0x4f
[1.790751]  [] ? try_to_wake_up+0x2c/0x166
[1.795845]  [] ? hpet_msi_set_periodic+0x11/0x11
[1.804788]  [] try_to_wake_up+0x2c/0x166
[1.806206]  [] ? __add_to_page_cache_locked+0x1e2/0x222
[1.807936]  [] wake_up_process+0x10/0x12
[1.809329]  [] wakeup_softirqd+0x1d/0x1f
[1.812342]  [] raise_softirq_irqoff+0x27/0x29
[1.813837]  [] raise_softirq+0x23/0x49
[1.815192]  [] rcu_sched_qs+0x80/0xa7
[1.822906]  [] __schedule+0x11b/0x51a
[1.824266]  [] preempt_schedule_common+0x1d/0x31
[1.826627]  [] _cond_resched+0x13/0x1f
[1.832048]  [] generic_perform_write+0x100/0x19d
[1.835279]  [] __generic_file_write_iter+0xfd/0x164
[1.845691]  [] generic_file_write_iter+0x48/0x92
[1.847286]  [] __vfs_write+0x77/0xa0
[1.848452]  [] vfs_write+0xa2/0xc8
[1.849698]  [] ? initrd_load+0x3f/0x3f
[1.852370]  [] SyS_write+0x4b/0x7b
[1.853642]  [] xwrite+0x26/0x5c
[1.855805]  [] do_copy+0x89/0xb6
[1.860184]  [] write_buffer+0x23/0x34
[1.861541]  [] flush_buffer+0x71/0x8e
[1.862916]  [] __gunzip+0x266/0x306
[1.873568]  [] ? bunzip2+0x3c7/0x3c7
[1.878009]  [] ? write_buffer+0x34/0x34
[1.881612]  [] ? do_early_param+0x8f/0x8f
[1.883092]  [] gunzip+0x11/0x13
[1.884173]  [] ? initrd_load+0x3f/0x3f
[

Re: [PATCH v2 2/7] lib/dlock-list: Add __percpu modifier for parameters

[Waiman Long]

On 07/13/2016 12:08 PM, Tejun Heo wrote:

On Mon, Jul 11, 2016 at 01:32:07PM -0400, Waiman Long wrote:

From: Boqun Feng

Add __percpu modifier properly to help:

1.  Differ pointers to actual structures with those to percpu
structures, which could improve readability.

2.  Prevent sparse from complaining about "different address spaces"

Signed-off-by: Boqun Feng
Signed-off-by: Waiman Long

Please do this in the same patch.

Thanks.



Will merge it into patch 1.

Cheers,
Longman

Re: [PATCH v2 2/7] lib/dlock-list: Add __percpu modifier for parameters

[Waiman Long]

On 07/13/2016 12:08 PM, Tejun Heo wrote:

On Mon, Jul 11, 2016 at 01:32:07PM -0400, Waiman Long wrote:

From: Boqun Feng

Add __percpu modifier properly to help:

1.  Differ pointers to actual structures with those to percpu
structures, which could improve readability.

2.  Prevent sparse from complaining about "different address spaces"

Signed-off-by: Boqun Feng
Signed-off-by: Waiman Long

Please do this in the same patch.

Thanks.



Will merge it into patch 1.

Cheers,
Longman

Re: [PATCH v2 1/7] lib/dlock-list: Distributed and lock-protected lists

[Waiman Long]

On 07/13/2016 12:08 PM, Tejun Heo wrote:

Hello,

On Mon, Jul 11, 2016 at 01:32:06PM -0400, Waiman Long wrote:
...

A new header file include/linux/dlock-list.h will be added with the

Heh, I think perpcu_list was the better name but suppose I'm too late.


Given the fact that we may change the level of lock granularity in the 
future, it is too late to change it back to percpu_list.



associated dlock_list_head and dlock_list_node structures. The following
functions are provided to manage the per-cpu list:

  1. int init_dlock_list_head(struct dlock_list_head **pdlock_head)
  2. void dlock_list_add(struct dlock_list_node *node,
struct dlock_list_head *head)
  3. void dlock_list_del(struct dlock_list *node)

Iteration of all the list entries within a group of per-cpu
lists is done by calling either the dlock_list_iterate() or
dlock_list_iterate_safe() functions in a while loop. They correspond
to the list_for_each_entry() and list_for_each_entry_safe() macros
respectively. The iteration states are keep in a dlock_list_state
structure that is passed to the iteration functions.

Why do we need two variants of this?  We need a state variable to walk
the list anyway.  Why not make dlock_list_iterate() safe against
removal and get rid of the second variant?  Also, dlock_list_next()
probably is a better name.


The two variants are the equivalent of list_for_each_entry() and 
list_for_each_entry_safe(). There are scenarios where 
list_for_each_entry_safe() isn't really safe when the next pointer of 
the current node is modified, for example. In this particular use case, 
the safe version isn't needed as all the list_for_each_entry_safe() call 
sites were modified to use list_for_each_entry() instead. I keep the 
dlock_list_iterate_safe() for future use cases that may need the safe 
version.


As it is a macro, it won't consume any resource if it is not used. 
However, I can remove it if you think we shouldn't carry any code that 
is not currently used.


Yes, I can change the name to dlock_list_next().


+/*
+ * include/linux/dlock-list.h
+ *
+ * A distributed (per-cpu) set of lists each of which is protected by its
+ * own spinlock, but acts like a single consolidated list to the callers.
+ *
+ * The dlock_list_head structure contains the spinlock, the other
+ * dlock_list_node structures only contains a pointer to the spinlock in
+ * dlock_list_head.
+ */
+struct dlock_list_head {
+   struct list_head list;
+   spinlock_t lock;
+};
+
+#define DLOCK_LIST_HEAD_INIT(name) \
+   {   \
+   .list.prev =, \
+   .list.next =, \
+   .list.lock = __SPIN_LOCK_UNLOCKED(name),\
+   }

This is confusing.  It looks like dlock_list_head and
DLOCK_LIST_HEAD_INIT() can be used to define and initialize static
dlock_lists but that isn't true.  It's weird to require the user to
deal with percpu declaration of the data type.  Shouldn't it be more
like the following?

struct dlock_list_head_cpu {
struct list_head list;
spinlock_t lock;
};

struct dlock_list_head {
struct dlock_list_head_percpu *head_cpu;
};


I think I know what you want. I will update the code accordingly.


+/*
+ * Per-cpu list iteration state
+ */
+struct dlock_list_state {
+   int  cpu;
+   spinlock_t  *lock;
+   struct list_head*head;  /* List head of current per-cpu list */
+   struct dlock_list_node  *curr;
+   struct dlock_list_node  *next;
+};

Maybe dlock_list_iter[ator] is a better name?


Sure, I can rename it.




+#define DLOCK_LIST_STATE_INIT()\
+   {   \
+   .cpu  = -1, \
+   .lock = NULL,   \
+   .head = NULL,   \
+   .curr = NULL,   \
+   .next = NULL,   \
+   }

The NULL inits are unnecessary and prone to being left behind.


Will remove those NULL inits.




+#define DEFINE_DLOCK_LIST_STATE(s) \
+   struct dlock_list_state s = DLOCK_LIST_STATE_INIT()
+
+static inline void init_dlock_list_state(struct dlock_list_state *state)
+{
+   state->cpu  = -1;
+   state->lock = NULL;
+   state->head = NULL;
+   state->curr = NULL;
+   state->next = NULL;
+}

Why not "state = (struct dlock_list_state)DLOCK_LIST_STATE_INIT;"?


Yes, that should work too.




+#ifdef CONFIG_DEBUG_SPINLOCK
+#define DLOCK_LIST_WARN_ON(x)  WARN_ON(x)
+#else
+#define DLOCK_LIST_WARN_ON(x)
+#endif

I'd just use WARN_ON_ONCE() without the CONFIG guard.


I'd do so if it is used in a real function. However, it is used in the 
dlock_list_iterate() macro which will duplicate the WARN_ON call on all 
the call sites. That is why I am hesitant to do that.

Re: [PATCH v2 1/7] lib/dlock-list: Distributed and lock-protected lists

[Waiman Long]

On 07/13/2016 12:08 PM, Tejun Heo wrote:

Hello,

On Mon, Jul 11, 2016 at 01:32:06PM -0400, Waiman Long wrote:
...

A new header file include/linux/dlock-list.h will be added with the

Heh, I think perpcu_list was the better name but suppose I'm too late.


Given the fact that we may change the level of lock granularity in the 
future, it is too late to change it back to percpu_list.



associated dlock_list_head and dlock_list_node structures. The following
functions are provided to manage the per-cpu list:

  1. int init_dlock_list_head(struct dlock_list_head **pdlock_head)
  2. void dlock_list_add(struct dlock_list_node *node,
struct dlock_list_head *head)
  3. void dlock_list_del(struct dlock_list *node)

Iteration of all the list entries within a group of per-cpu
lists is done by calling either the dlock_list_iterate() or
dlock_list_iterate_safe() functions in a while loop. They correspond
to the list_for_each_entry() and list_for_each_entry_safe() macros
respectively. The iteration states are keep in a dlock_list_state
structure that is passed to the iteration functions.

Why do we need two variants of this?  We need a state variable to walk
the list anyway.  Why not make dlock_list_iterate() safe against
removal and get rid of the second variant?  Also, dlock_list_next()
probably is a better name.


The two variants are the equivalent of list_for_each_entry() and 
list_for_each_entry_safe(). There are scenarios where 
list_for_each_entry_safe() isn't really safe when the next pointer of 
the current node is modified, for example. In this particular use case, 
the safe version isn't needed as all the list_for_each_entry_safe() call 
sites were modified to use list_for_each_entry() instead. I keep the 
dlock_list_iterate_safe() for future use cases that may need the safe 
version.


As it is a macro, it won't consume any resource if it is not used. 
However, I can remove it if you think we shouldn't carry any code that 
is not currently used.


Yes, I can change the name to dlock_list_next().


+/*
+ * include/linux/dlock-list.h
+ *
+ * A distributed (per-cpu) set of lists each of which is protected by its
+ * own spinlock, but acts like a single consolidated list to the callers.
+ *
+ * The dlock_list_head structure contains the spinlock, the other
+ * dlock_list_node structures only contains a pointer to the spinlock in
+ * dlock_list_head.
+ */
+struct dlock_list_head {
+   struct list_head list;
+   spinlock_t lock;
+};
+
+#define DLOCK_LIST_HEAD_INIT(name) \
+   {   \
+   .list.prev =, \
+   .list.next =, \
+   .list.lock = __SPIN_LOCK_UNLOCKED(name),\
+   }

This is confusing.  It looks like dlock_list_head and
DLOCK_LIST_HEAD_INIT() can be used to define and initialize static
dlock_lists but that isn't true.  It's weird to require the user to
deal with percpu declaration of the data type.  Shouldn't it be more
like the following?

struct dlock_list_head_cpu {
struct list_head list;
spinlock_t lock;
};

struct dlock_list_head {
struct dlock_list_head_percpu *head_cpu;
};


I think I know what you want. I will update the code accordingly.


+/*
+ * Per-cpu list iteration state
+ */
+struct dlock_list_state {
+   int  cpu;
+   spinlock_t  *lock;
+   struct list_head*head;  /* List head of current per-cpu list */
+   struct dlock_list_node  *curr;
+   struct dlock_list_node  *next;
+};

Maybe dlock_list_iter[ator] is a better name?


Sure, I can rename it.




+#define DLOCK_LIST_STATE_INIT()\
+   {   \
+   .cpu  = -1, \
+   .lock = NULL,   \
+   .head = NULL,   \
+   .curr = NULL,   \
+   .next = NULL,   \
+   }

The NULL inits are unnecessary and prone to being left behind.


Will remove those NULL inits.




+#define DEFINE_DLOCK_LIST_STATE(s) \
+   struct dlock_list_state s = DLOCK_LIST_STATE_INIT()
+
+static inline void init_dlock_list_state(struct dlock_list_state *state)
+{
+   state->cpu  = -1;
+   state->lock = NULL;
+   state->head = NULL;
+   state->curr = NULL;
+   state->next = NULL;
+}

Why not "state = (struct dlock_list_state)DLOCK_LIST_STATE_INIT;"?


Yes, that should work too.




+#ifdef CONFIG_DEBUG_SPINLOCK
+#define DLOCK_LIST_WARN_ON(x)  WARN_ON(x)
+#else
+#define DLOCK_LIST_WARN_ON(x)
+#endif

I'd just use WARN_ON_ONCE() without the CONFIG guard.


I'd do so if it is used in a real function. However, it is used in the 
dlock_list_iterate() macro which will duplicate the WARN_ON call on all 
the call sites. That is why I am hesitant to do that.

[PATCH 3/3] tools/power/acpi/acpidbg: Use new flushing mechanism

[Lv Zheng]

This patch converts tools/power/acpi/tools/acpidbg/acpidbg to use the new
flushing mechanism.

Signed-off-by: Lv Zheng 
---
 tools/power/acpi/tools/acpidbg/acpidbg.c |   49 +++---
 1 file changed, 5 insertions(+), 44 deletions(-)

diff --git a/tools/power/acpi/tools/acpidbg/acpidbg.c 
b/tools/power/acpi/tools/acpidbg/acpidbg.c
index a88ac45..770b556 100644
--- a/tools/power/acpi/tools/acpidbg/acpidbg.c
+++ b/tools/power/acpi/tools/acpidbg/acpidbg.c
@@ -83,7 +83,6 @@ static const char *acpi_aml_file_path = ACPI_AML_FILE;
 static unsigned long acpi_aml_mode = ACPI_AML_INTERACTIVE;
 static bool acpi_aml_exit;
 
-static bool acpi_aml_batch_drain;
 static unsigned long acpi_aml_batch_state;
 static char acpi_aml_batch_prompt;
 static char acpi_aml_batch_roll;
@@ -239,11 +238,9 @@ static int acpi_aml_write_batch_log(int fd, struct 
circ_buf *crc)
 
p = >buf[crc->tail];
len = circ_count_to_end(crc);
-   if (!acpi_aml_batch_drain) {
-   len = write(fd, p, len);
-   if (len < 0)
-   perror("write");
-   }
+   len = write(fd, p, len);
+   if (len < 0)
+   perror("write");
if (len > 0)
crc->tail = (crc->tail + len) & (ACPI_AML_BUF_SIZE - 1);
return len;
@@ -270,10 +267,7 @@ static void acpi_aml_loop(int fd)
if (acpi_aml_mode == ACPI_AML_BATCH) {
acpi_aml_log_state = ACPI_AML_LOG_START;
acpi_aml_batch_pos = acpi_aml_batch_cmd;
-   if (acpi_aml_batch_drain)
-   acpi_aml_batch_state = ACPI_AML_BATCH_READ_LOG;
-   else
-   acpi_aml_batch_state = ACPI_AML_BATCH_WRITE_CMD;
+   acpi_aml_batch_state = ACPI_AML_BATCH_WRITE_CMD;
}
acpi_aml_exit = false;
while (!acpi_aml_exit) {
@@ -330,39 +324,6 @@ static void acpi_aml_loop(int fd)
}
 }
 
-static bool acpi_aml_readable(int fd)
-{
-   fd_set rfds;
-   struct timeval tv;
-   int ret;
-   int maxfd = 0;
-
-   tv.tv_sec = 0;
-   tv.tv_usec = ACPI_AML_USEC_PEEK;
-   FD_ZERO();
-   maxfd = acpi_aml_set_fd(fd, maxfd, );
-   ret = select(maxfd+1, , NULL, NULL, );
-   if (ret < 0)
-   perror("select");
-   if (ret > 0 && FD_ISSET(fd, ))
-   return true;
-   return false;
-}
-
-/*
- * This is a userspace IO flush implementation, replying on the prompt
- * characters and can be turned into a flush() call after kernel implements
- * .flush() filesystem operation.
- */
-static void acpi_aml_flush(int fd)
-{
-   while (acpi_aml_readable(fd)) {
-   acpi_aml_batch_drain = true;
-   acpi_aml_loop(fd);
-   acpi_aml_batch_drain = false;
-   }
-}
-
 void usage(FILE *file, char *progname)
 {
fprintf(file, "usage: %s [-b cmd] [-f file] [-h]\n", progname);
@@ -426,7 +387,7 @@ int main(int argc, char **argv)
acpi_aml_set_fl(STDOUT_FILENO, O_NONBLOCK);
 
if (acpi_aml_mode == ACPI_AML_BATCH)
-   acpi_aml_flush(fd);
+   fsync(fd);
acpi_aml_loop(fd);
 
 exit:
-- 
1.7.10

[PATCH 3/3] tools/power/acpi/acpidbg: Use new flushing mechanism

[Lv Zheng]

This patch converts tools/power/acpi/tools/acpidbg/acpidbg to use the new
flushing mechanism.

Signed-off-by: Lv Zheng 
---
 tools/power/acpi/tools/acpidbg/acpidbg.c |   49 +++---
 1 file changed, 5 insertions(+), 44 deletions(-)

diff --git a/tools/power/acpi/tools/acpidbg/acpidbg.c 
b/tools/power/acpi/tools/acpidbg/acpidbg.c
index a88ac45..770b556 100644
--- a/tools/power/acpi/tools/acpidbg/acpidbg.c
+++ b/tools/power/acpi/tools/acpidbg/acpidbg.c
@@ -83,7 +83,6 @@ static const char *acpi_aml_file_path = ACPI_AML_FILE;
 static unsigned long acpi_aml_mode = ACPI_AML_INTERACTIVE;
 static bool acpi_aml_exit;
 
-static bool acpi_aml_batch_drain;
 static unsigned long acpi_aml_batch_state;
 static char acpi_aml_batch_prompt;
 static char acpi_aml_batch_roll;
@@ -239,11 +238,9 @@ static int acpi_aml_write_batch_log(int fd, struct 
circ_buf *crc)
 
p = >buf[crc->tail];
len = circ_count_to_end(crc);
-   if (!acpi_aml_batch_drain) {
-   len = write(fd, p, len);
-   if (len < 0)
-   perror("write");
-   }
+   len = write(fd, p, len);
+   if (len < 0)
+   perror("write");
if (len > 0)
crc->tail = (crc->tail + len) & (ACPI_AML_BUF_SIZE - 1);
return len;
@@ -270,10 +267,7 @@ static void acpi_aml_loop(int fd)
if (acpi_aml_mode == ACPI_AML_BATCH) {
acpi_aml_log_state = ACPI_AML_LOG_START;
acpi_aml_batch_pos = acpi_aml_batch_cmd;
-   if (acpi_aml_batch_drain)
-   acpi_aml_batch_state = ACPI_AML_BATCH_READ_LOG;
-   else
-   acpi_aml_batch_state = ACPI_AML_BATCH_WRITE_CMD;
+   acpi_aml_batch_state = ACPI_AML_BATCH_WRITE_CMD;
}
acpi_aml_exit = false;
while (!acpi_aml_exit) {
@@ -330,39 +324,6 @@ static void acpi_aml_loop(int fd)
}
 }
 
-static bool acpi_aml_readable(int fd)
-{
-   fd_set rfds;
-   struct timeval tv;
-   int ret;
-   int maxfd = 0;
-
-   tv.tv_sec = 0;
-   tv.tv_usec = ACPI_AML_USEC_PEEK;
-   FD_ZERO();
-   maxfd = acpi_aml_set_fd(fd, maxfd, );
-   ret = select(maxfd+1, , NULL, NULL, );
-   if (ret < 0)
-   perror("select");
-   if (ret > 0 && FD_ISSET(fd, ))
-   return true;
-   return false;
-}
-
-/*
- * This is a userspace IO flush implementation, replying on the prompt
- * characters and can be turned into a flush() call after kernel implements
- * .flush() filesystem operation.
- */
-static void acpi_aml_flush(int fd)
-{
-   while (acpi_aml_readable(fd)) {
-   acpi_aml_batch_drain = true;
-   acpi_aml_loop(fd);
-   acpi_aml_batch_drain = false;
-   }
-}
-
 void usage(FILE *file, char *progname)
 {
fprintf(file, "usage: %s [-b cmd] [-f file] [-h]\n", progname);
@@ -426,7 +387,7 @@ int main(int argc, char **argv)
acpi_aml_set_fl(STDOUT_FILENO, O_NONBLOCK);
 
if (acpi_aml_mode == ACPI_AML_BATCH)
-   acpi_aml_flush(fd);
+   fsync(fd);
acpi_aml_loop(fd);
 
 exit:
-- 
1.7.10