Re: [PATCH v2 1/9] llist: Provide a safe version for llist_for_each

[Byungchul Park]

On Mon, Feb 13, 2017 at 03:52:44PM +0800, Huang, Ying wrote:
> Byungchul Park  writes:
> 
> > On Mon, Feb 13, 2017 at 03:36:33PM +0800, Huang, Ying wrote:
> >> Byungchul Park  writes:
> >> 
> >> > Sometimes we have to dereference next field of llist node before entering
> >> > loop becasue the node might be deleted or the next field might be
> >> > modified within the loop. So this adds the safe version of 
> >> > llist_for_each,
> >> > that is, llist_for_each_safe.
> >> >
> >> > Signed-off-by: Byungchul Park 
> >> > ---
> >> >  include/linux/llist.h | 19 +++
> >> >  1 file changed, 19 insertions(+)
> >> >
> >> > diff --git a/include/linux/llist.h b/include/linux/llist.h
> >> > index fd4ca0b..4c508a5 100644
> >> > --- a/include/linux/llist.h
> >> > +++ b/include/linux/llist.h
> >> > @@ -105,6 +105,25 @@ static inline void init_llist_head(struct 
> >> > llist_head *list)
> >> >  for ((pos) = (node); pos; (pos) = (pos)->next)
> >> >  
> >> >  /**
> >> > + * llist_for_each_safe - iterate over some deleted entries of a 
> >> > lock-less list
> >> > + *   safe against removal of list entry
> >> > + * @pos:the  llist_node to use as a loop cursor
> >> > + * @n:  another type * to use as temporary storage
> >> 
> >> s/type */ llist_node/
> >
> > Yes.
> >
> >> 
> >> > + * @node:   the first entry of deleted list entries
> >> > + *
> >> > + * In general, some entries of the lock-less list can be traversed
> >> > + * safely only after being deleted from list, so start with an entry
> >> > + * instead of list head.
> >> > + *
> >> > + * If being used on entries deleted from lock-less list directly, the
> >> > + * traverse order is from the newest to the oldest added entry.  If
> >> > + * you want to traverse from the oldest to the newest, you must
> >> > + * reverse the order by yourself before traversing.
> >> > + */
> >> > +#define llist_for_each_safe(pos, n, node)   \
> >> > +for ((pos) = (node); (pos) && ((n) = (pos)->next, true); (pos) 
> >> > = (n))
> >> > +
> >> 
> >> Following the style of other xxx_for_each_safe,
> >> 
> >> #define llist_for_each_safe(pos, n, node)  \
> >>for (pos = (node), (pos && (n = pos->next)); pos; pos = n, n = 
> >> pos->next)
> >
> > Do you think it should be modified? I think mine is simpler. No?
> 
> Personally I prefer the style of other xxx_for_each_safe().

Yes, I will modify it as you recommand.

Thank you very much.

> 
> Best Regards,
> Huang, Ying
> 
> >> 
> >> Best Regards,
> >> Huang, Ying
> >> 
> >> > +/**
> >> >   * llist_for_each_entry - iterate over some deleted entries of 
> >> > lock-less list of given type
> >> >   * @pos:the type * to use as a loop cursor.
> >> >   * @node:   the fist entry of deleted list entries.

Re: [PATCH v2 1/9] llist: Provide a safe version for llist_for_each

[Byungchul Park]

On Mon, Feb 13, 2017 at 03:52:44PM +0800, Huang, Ying wrote:
> Byungchul Park  writes:
> 
> > On Mon, Feb 13, 2017 at 03:36:33PM +0800, Huang, Ying wrote:
> >> Byungchul Park  writes:
> >> 
> >> > Sometimes we have to dereference next field of llist node before entering
> >> > loop becasue the node might be deleted or the next field might be
> >> > modified within the loop. So this adds the safe version of 
> >> > llist_for_each,
> >> > that is, llist_for_each_safe.
> >> >
> >> > Signed-off-by: Byungchul Park 
> >> > ---
> >> >  include/linux/llist.h | 19 +++
> >> >  1 file changed, 19 insertions(+)
> >> >
> >> > diff --git a/include/linux/llist.h b/include/linux/llist.h
> >> > index fd4ca0b..4c508a5 100644
> >> > --- a/include/linux/llist.h
> >> > +++ b/include/linux/llist.h
> >> > @@ -105,6 +105,25 @@ static inline void init_llist_head(struct 
> >> > llist_head *list)
> >> >  for ((pos) = (node); pos; (pos) = (pos)->next)
> >> >  
> >> >  /**
> >> > + * llist_for_each_safe - iterate over some deleted entries of a 
> >> > lock-less list
> >> > + *   safe against removal of list entry
> >> > + * @pos:the  llist_node to use as a loop cursor
> >> > + * @n:  another type * to use as temporary storage
> >> 
> >> s/type */ llist_node/
> >
> > Yes.
> >
> >> 
> >> > + * @node:   the first entry of deleted list entries
> >> > + *
> >> > + * In general, some entries of the lock-less list can be traversed
> >> > + * safely only after being deleted from list, so start with an entry
> >> > + * instead of list head.
> >> > + *
> >> > + * If being used on entries deleted from lock-less list directly, the
> >> > + * traverse order is from the newest to the oldest added entry.  If
> >> > + * you want to traverse from the oldest to the newest, you must
> >> > + * reverse the order by yourself before traversing.
> >> > + */
> >> > +#define llist_for_each_safe(pos, n, node)   \
> >> > +for ((pos) = (node); (pos) && ((n) = (pos)->next, true); (pos) 
> >> > = (n))
> >> > +
> >> 
> >> Following the style of other xxx_for_each_safe,
> >> 
> >> #define llist_for_each_safe(pos, n, node)  \
> >>for (pos = (node), (pos && (n = pos->next)); pos; pos = n, n = 
> >> pos->next)
> >
> > Do you think it should be modified? I think mine is simpler. No?
> 
> Personally I prefer the style of other xxx_for_each_safe().

Yes, I will modify it as you recommand.

Thank you very much.

> 
> Best Regards,
> Huang, Ying
> 
> >> 
> >> Best Regards,
> >> Huang, Ying
> >> 
> >> > +/**
> >> >   * llist_for_each_entry - iterate over some deleted entries of 
> >> > lock-less list of given type
> >> >   * @pos:the type * to use as a loop cursor.
> >> >   * @node:   the fist entry of deleted list entries.

Re: [PATCH v3 1/2] mtd: ifc: Update dependency of IFC for LS1021A

[Boris Brezillon]

On Mon, 13 Feb 2017 07:39:41 +
Alison Wang  wrote:

> Hi, Boris,
> 
>   Sorry, I forgot to change them. Should I resend them or you help to fix 
> that when applying?

I can fix that when applying, no need to resend.
Note that you missed 4.11 (already sent my PR to Brian), I'll queue it
for 4.12.

Regards,

Boris

> 
> 
> Best Regards,
> Alison Wang
> 
> > 
> > Hi Alison,
> > 
> > The subject prefix is still wrong, should be 'memory: ifc: '.
> > 
> > On Mon, 13 Feb 2017 14:46:55 +0800
> > Alison Wang  wrote:
> >   
> > > As Freescale/NXP IFC controller is available on LS1021A, the
> > > dependency for LS1021A is added.
> > >
> > > LS1021A is an earlier product and is not compatible with later
> > > LayerScape architecture. So ARCH_LAYERSCAPE can't cover LS1021A.
> > >
> > > Signed-off-by: Alison Wang 
> > > ---
> > > Changes in v3:
> > > - Update the commit message.
> > >
> > > Changes in v2:
> > > - New patch
> > >
> > >  drivers/memory/Kconfig | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig index
> > > ec80e35..fff8345 100644
> > > --- a/drivers/memory/Kconfig
> > > +++ b/drivers/memory/Kconfig
> > > @@ -115,7 +115,7 @@ config FSL_CORENET_CF
> > >
> > >  config FSL_IFC
> > >   bool
> > > - depends on FSL_SOC || ARCH_LAYERSCAPE
> > > + depends on FSL_SOC || ARCH_LAYERSCAPE || SOC_LS1021A
> > >
> > >  config JZ4780_NEMC
> > >   bool "Ingenic JZ4780 SoC NEMC driver"  
> 

Re: [PATCH v3 1/2] mtd: ifc: Update dependency of IFC for LS1021A

[Boris Brezillon]

On Mon, 13 Feb 2017 07:39:41 +
Alison Wang  wrote:

> Hi, Boris,
> 
>   Sorry, I forgot to change them. Should I resend them or you help to fix 
> that when applying?

I can fix that when applying, no need to resend.
Note that you missed 4.11 (already sent my PR to Brian), I'll queue it
for 4.12.

Regards,

Boris

> 
> 
> Best Regards,
> Alison Wang
> 
> > 
> > Hi Alison,
> > 
> > The subject prefix is still wrong, should be 'memory: ifc: '.
> > 
> > On Mon, 13 Feb 2017 14:46:55 +0800
> > Alison Wang  wrote:
> >   
> > > As Freescale/NXP IFC controller is available on LS1021A, the
> > > dependency for LS1021A is added.
> > >
> > > LS1021A is an earlier product and is not compatible with later
> > > LayerScape architecture. So ARCH_LAYERSCAPE can't cover LS1021A.
> > >
> > > Signed-off-by: Alison Wang 
> > > ---
> > > Changes in v3:
> > > - Update the commit message.
> > >
> > > Changes in v2:
> > > - New patch
> > >
> > >  drivers/memory/Kconfig | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig index
> > > ec80e35..fff8345 100644
> > > --- a/drivers/memory/Kconfig
> > > +++ b/drivers/memory/Kconfig
> > > @@ -115,7 +115,7 @@ config FSL_CORENET_CF
> > >
> > >  config FSL_IFC
> > >   bool
> > > - depends on FSL_SOC || ARCH_LAYERSCAPE
> > > + depends on FSL_SOC || ARCH_LAYERSCAPE || SOC_LS1021A
> > >
> > >  config JZ4780_NEMC
> > >   bool "Ingenic JZ4780 SoC NEMC driver"  
> 

Re: [PATCH V4 2/2] Move stack parameters for sed_ioctl to prevent oversized stack with CONFIG_KASAN

[Christoph Hellwig]

>  int sed_ioctl(struct opal_dev *dev, unsigned int cmd, unsigned long ptr)
>  {
> + void *ioctl_ptr;
> + int ret = -ENOTTY;
>   void __user *arg = (void __user *)ptr;

Can we use this opportunity to clean up the usual ioctl argument mess.
Id say pass the "void __user *argp" argument already (nvme_ioctl should
have a local variable for it anyway), and then just rename ioctl_ptr
variable to the usual short p.

> + unsigned int cmd_size = _IOC_SIZE(cmd);
>  

> + ioctl_ptr = memdup_user(arg, cmd_size);

cmd_size is only used once, so why not opencode the expression in the
argument to memdup_user.

Re: [PATCH V4 2/2] Move stack parameters for sed_ioctl to prevent oversized stack with CONFIG_KASAN

[Christoph Hellwig]

>  int sed_ioctl(struct opal_dev *dev, unsigned int cmd, unsigned long ptr)
>  {
> + void *ioctl_ptr;
> + int ret = -ENOTTY;
>   void __user *arg = (void __user *)ptr;

Can we use this opportunity to clean up the usual ioctl argument mess.
Id say pass the "void __user *argp" argument already (nvme_ioctl should
have a local variable for it anyway), and then just rename ioctl_ptr
variable to the usual short p.

> + unsigned int cmd_size = _IOC_SIZE(cmd);
>  

> + ioctl_ptr = memdup_user(arg, cmd_size);

cmd_size is only used once, so why not opencode the expression in the
argument to memdup_user.

Re: [PATCH] spi-nor: use ERR_CAST in return

[Boris Brezillon]

On Mon, 13 Feb 2017 07:35:52 +
Nicholas Mc Guire  wrote:

> On Sun, Feb 12, 2017 at 11:04:10PM +0100, Boris Brezillon wrote:
> > +Mika
> > 
> > On Sun, 12 Feb 2017 22:45:43 +0100
> > Boris Brezillon  wrote:
> >   
> > > On Sun, 12 Feb 2017 17:43:43 +0100
> > > Nicholas Mc Guire  wrote:
> > >   
> > > > This fixes a sparse warning about 
> > > 
> > > Your commit message seems to be incomplete.  
> > 
> > And here too, please change the prefix to "mtd: spi-nor: intel: ".
> >  
> 
> What Im doing for checking prefix is:
> hofrat@debian:~/git/linux-next$ git log --oneline 
> drivers/mtd/spi-nor/intel-spi.c
> 8afda8b spi-nor: Add support for Intel SPI serial flash controller
> 
> is the method of checking the commit prefix with git log --oneline 
> inapropriate ?

It's appropriate, except in this case. You're referring to the commit
introducing a new driver, so this is expected to not find the
'intel:' suffix, but you have 'Add support for Intel SPI serial flash
controller' to clarify the scope.

Regarding the "mtd: " prefix, I think it's better to have it, but
apparently Cyrille is not enforcing that.

> How would I have found the "mtd: spi-nor: intel:" in this case ?

Well, it's a mix of common sense and 'git log --oneline' use :-). Here
you're only modifying the intel driver, but nothing in your subject
mentions it.

Re: [PATCH] spi-nor: use ERR_CAST in return

[Boris Brezillon]

On Mon, 13 Feb 2017 07:35:52 +
Nicholas Mc Guire  wrote:

> On Sun, Feb 12, 2017 at 11:04:10PM +0100, Boris Brezillon wrote:
> > +Mika
> > 
> > On Sun, 12 Feb 2017 22:45:43 +0100
> > Boris Brezillon  wrote:
> >   
> > > On Sun, 12 Feb 2017 17:43:43 +0100
> > > Nicholas Mc Guire  wrote:
> > >   
> > > > This fixes a sparse warning about 
> > > 
> > > Your commit message seems to be incomplete.  
> > 
> > And here too, please change the prefix to "mtd: spi-nor: intel: ".
> >  
> 
> What Im doing for checking prefix is:
> hofrat@debian:~/git/linux-next$ git log --oneline 
> drivers/mtd/spi-nor/intel-spi.c
> 8afda8b spi-nor: Add support for Intel SPI serial flash controller
> 
> is the method of checking the commit prefix with git log --oneline 
> inapropriate ?

It's appropriate, except in this case. You're referring to the commit
introducing a new driver, so this is expected to not find the
'intel:' suffix, but you have 'Add support for Intel SPI serial flash
controller' to clarify the scope.

Regarding the "mtd: " prefix, I think it's better to have it, but
apparently Cyrille is not enforcing that.

> How would I have found the "mtd: spi-nor: intel:" in this case ?

Well, it's a mix of common sense and 'git log --oneline' use :-). Here
you're only modifying the intel driver, but nothing in your subject
mentions it.

Re: [PATCH v2 1/9] llist: Provide a safe version for llist_for_each

[Huang, Ying]

Byungchul Park  writes:

> On Mon, Feb 13, 2017 at 03:36:33PM +0800, Huang, Ying wrote:
>> Byungchul Park  writes:
>> 
>> > Sometimes we have to dereference next field of llist node before entering
>> > loop becasue the node might be deleted or the next field might be
>> > modified within the loop. So this adds the safe version of llist_for_each,
>> > that is, llist_for_each_safe.
>> >
>> > Signed-off-by: Byungchul Park 
>> > ---
>> >  include/linux/llist.h | 19 +++
>> >  1 file changed, 19 insertions(+)
>> >
>> > diff --git a/include/linux/llist.h b/include/linux/llist.h
>> > index fd4ca0b..4c508a5 100644
>> > --- a/include/linux/llist.h
>> > +++ b/include/linux/llist.h
>> > @@ -105,6 +105,25 @@ static inline void init_llist_head(struct llist_head 
>> > *list)
>> >for ((pos) = (node); pos; (pos) = (pos)->next)
>> >  
>> >  /**
>> > + * llist_for_each_safe - iterate over some deleted entries of a lock-less 
>> > list
>> > + * safe against removal of list entry
>> > + * @pos:  the  llist_node to use as a loop cursor
>> > + * @n:another type * to use as temporary storage
>> 
>> s/type */ llist_node/
>
> Yes.
>
>> 
>> > + * @node: the first entry of deleted list entries
>> > + *
>> > + * In general, some entries of the lock-less list can be traversed
>> > + * safely only after being deleted from list, so start with an entry
>> > + * instead of list head.
>> > + *
>> > + * If being used on entries deleted from lock-less list directly, the
>> > + * traverse order is from the newest to the oldest added entry.  If
>> > + * you want to traverse from the oldest to the newest, you must
>> > + * reverse the order by yourself before traversing.
>> > + */
>> > +#define llist_for_each_safe(pos, n, node) \
>> > +  for ((pos) = (node); (pos) && ((n) = (pos)->next, true); (pos) = (n))
>> > +
>> 
>> Following the style of other xxx_for_each_safe,
>> 
>> #define llist_for_each_safe(pos, n, node)\
>>  for (pos = (node), (pos && (n = pos->next)); pos; pos = n, n = 
>> pos->next)
>
> Do you think it should be modified? I think mine is simpler. No?

Personally I prefer the style of other xxx_for_each_safe().

Best Regards,
Huang, Ying

>> 
>> Best Regards,
>> Huang, Ying
>> 
>> > +/**
>> >   * llist_for_each_entry - iterate over some deleted entries of lock-less 
>> > list of given type
>> >   * @pos:  the type * to use as a loop cursor.
>> >   * @node: the fist entry of deleted list entries.

Re: [PATCH v2 1/9] llist: Provide a safe version for llist_for_each

[Huang, Ying]

Byungchul Park  writes:

> On Mon, Feb 13, 2017 at 03:36:33PM +0800, Huang, Ying wrote:
>> Byungchul Park  writes:
>> 
>> > Sometimes we have to dereference next field of llist node before entering
>> > loop becasue the node might be deleted or the next field might be
>> > modified within the loop. So this adds the safe version of llist_for_each,
>> > that is, llist_for_each_safe.
>> >
>> > Signed-off-by: Byungchul Park 
>> > ---
>> >  include/linux/llist.h | 19 +++
>> >  1 file changed, 19 insertions(+)
>> >
>> > diff --git a/include/linux/llist.h b/include/linux/llist.h
>> > index fd4ca0b..4c508a5 100644
>> > --- a/include/linux/llist.h
>> > +++ b/include/linux/llist.h
>> > @@ -105,6 +105,25 @@ static inline void init_llist_head(struct llist_head 
>> > *list)
>> >for ((pos) = (node); pos; (pos) = (pos)->next)
>> >  
>> >  /**
>> > + * llist_for_each_safe - iterate over some deleted entries of a lock-less 
>> > list
>> > + * safe against removal of list entry
>> > + * @pos:  the  llist_node to use as a loop cursor
>> > + * @n:another type * to use as temporary storage
>> 
>> s/type */ llist_node/
>
> Yes.
>
>> 
>> > + * @node: the first entry of deleted list entries
>> > + *
>> > + * In general, some entries of the lock-less list can be traversed
>> > + * safely only after being deleted from list, so start with an entry
>> > + * instead of list head.
>> > + *
>> > + * If being used on entries deleted from lock-less list directly, the
>> > + * traverse order is from the newest to the oldest added entry.  If
>> > + * you want to traverse from the oldest to the newest, you must
>> > + * reverse the order by yourself before traversing.
>> > + */
>> > +#define llist_for_each_safe(pos, n, node) \
>> > +  for ((pos) = (node); (pos) && ((n) = (pos)->next, true); (pos) = (n))
>> > +
>> 
>> Following the style of other xxx_for_each_safe,
>> 
>> #define llist_for_each_safe(pos, n, node)\
>>  for (pos = (node), (pos && (n = pos->next)); pos; pos = n, n = 
>> pos->next)
>
> Do you think it should be modified? I think mine is simpler. No?

Personally I prefer the style of other xxx_for_each_safe().

Best Regards,
Huang, Ying

>> 
>> Best Regards,
>> Huang, Ying
>> 
>> > +/**
>> >   * llist_for_each_entry - iterate over some deleted entries of lock-less 
>> > list of given type
>> >   * @pos:  the type * to use as a loop cursor.
>> >   * @node: the fist entry of deleted list entries.

Re: [PATCH V4 1/2] uapi: sed-opal fix IOW for activate lsp to use correct struct

[Christoph Hellwig]

Looks fine,

Reviewed-by: Christoph Hellwig 

Re: [PATCH V4 1/2] uapi: sed-opal fix IOW for activate lsp to use correct struct

[Christoph Hellwig]

Looks fine,

Reviewed-by: Christoph Hellwig 

Re: [PATCH v6 7/8] uapi: export all headers under uapi directories

[Christoph Hellwig]

> linux/genwqe/..install.cmd
> linux/genwqe/.install

Third time:  NAK on exporting internal kbuild metadata.

Re: [PATCH v6 7/8] uapi: export all headers under uapi directories

[Christoph Hellwig]

> linux/genwqe/..install.cmd
> linux/genwqe/.install

Third time:  NAK on exporting internal kbuild metadata.

RE: [PATCH 2/2] x86/vdso: Add VCLOCK_HVCLOCK vDSO clock read method

[Dexuan Cui]

> From: Thomas Gleixner [mailto:t...@linutronix.de]
> Sent: Saturday, February 11, 2017 02:02
>  ...
> That's important if the stuff happens cross CPU. If the update happens on
> the same CPU then this is a different story and as there are VMexits
> involved they might provide the required ordering already. But I can't tell
> as I have no idea how that host side thing is done.
> 
>   tglx

IMO Hyper-V TSC page clocksource here seems pretty similar to KVM's pvclock,
So I would guess "the structure is only updated just before reentering the guest
after some VM event" (https://rwmj.wordpress.com/2010/10/15/kvm-pvclock/),
that is, the update should happen on the same CPU, I guess.

Thanks,
-- Dexuan

RE: [PATCH 2/2] x86/vdso: Add VCLOCK_HVCLOCK vDSO clock read method

[Dexuan Cui]

> From: Thomas Gleixner [mailto:t...@linutronix.de]
> Sent: Saturday, February 11, 2017 02:02
>  ...
> That's important if the stuff happens cross CPU. If the update happens on
> the same CPU then this is a different story and as there are VMexits
> involved they might provide the required ordering already. But I can't tell
> as I have no idea how that host side thing is done.
> 
>   tglx

IMO Hyper-V TSC page clocksource here seems pretty similar to KVM's pvclock,
So I would guess "the structure is only updated just before reentering the guest
after some VM event" (https://rwmj.wordpress.com/2010/10/15/kvm-pvclock/),
that is, the update should happen on the same CPU, I guess.

Thanks,
-- Dexuan

Re: [PATCH v2 5/6] drm: convert drivers to use drm_of_find_panel_or_bridge

[Boris Brezillon]

On Thu,  9 Feb 2017 13:05:57 -0600
Rob Herring  wrote:

> Similar to the previous commit, convert drivers open coding OF graph
> parsing to use drm_of_find_panel_or_bridge instead.
> 
> This changes some error messages to debug messages (in the graph core).
> Graph connections are often "no connects" depending on the particular
> board, so we want to avoid spurious messages. Plus the kernel is not a
> DT validator.
> 
> Signed-off-by: Rob Herring 
> ---
> v2:
> - fix wrong node ptr in imx-ldb
> - build fixes in kirin and imx drivers
> 
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 64 -
>  drivers/gpu/drm/bridge/nxp-ptn3460.c | 16 ++---
>  drivers/gpu/drm/bridge/parade-ps8622.c   | 16 ++---
>  drivers/gpu/drm/bridge/tc358767.c| 27 +--
>  drivers/gpu/drm/exynos/exynos_dp.c   | 35 -
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c| 49 -
>  drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 27 ++-
>  drivers/gpu/drm/imx/imx-ldb.c| 27 ++-
>  drivers/gpu/drm/imx/parallel-display.c   | 36 ++
>  drivers/gpu/drm/mediatek/mtk_dsi.c   | 23 ++
>  drivers/gpu/drm/mxsfb/mxsfb_out.c| 36 ++
>  drivers/gpu/drm/rockchip/analogix_dp-rockchip.c  | 26 ++-
>  drivers/gpu/drm/sun4i/sun4i_rgb.c| 13 ++--
>  drivers/gpu/drm/sun4i/sun4i_tcon.c   | 90 
> ++--
>  14 files changed, 88 insertions(+), 397 deletions(-)
> 
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c 
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
> index 6119b5085501..4614048a4935 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
> @@ -22,7 +22,7 @@
>  #include 
> 
>  #include 
> -#include 
> +#include 
> 
>  #include "atmel_hlcdc_dc.h"
> 
> @@ -152,29 +152,11 @@ static const struct drm_connector_funcs 
> atmel_hlcdc_panel_connector_funcs = {
>   .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
>  };
> 
> -static int atmel_hlcdc_check_endpoint(struct drm_device *dev,
> -   const struct of_endpoint *ep)
> -{
> - struct device_node *np;
> - void *obj;
> -
> - np = of_graph_get_remote_port_parent(ep->local_node);
> -
> - obj = of_drm_find_panel(np);
> - if (!obj)
> - obj = of_drm_find_bridge(np);
> -
> - of_node_put(np);
> -
> - return obj ? 0 : -EPROBE_DEFER;
> -}
> -
>  static int atmel_hlcdc_attach_endpoint(struct drm_device *dev,
> -const struct of_endpoint *ep)
> +const struct device_node *np)
>  {
>   struct atmel_hlcdc_dc *dc = dev->dev_private;
>   struct atmel_hlcdc_rgb_output *output;
> - struct device_node *np;
>   struct drm_panel *panel;
>   struct drm_bridge *bridge;
>   int ret;
> @@ -195,13 +177,11 @@ static int atmel_hlcdc_attach_endpoint(struct 
> drm_device *dev,
> 
>   output->encoder.possible_crtcs = 0x1;
> 
> - np = of_graph_get_remote_port_parent(ep->local_node);
> -
> - ret = -EPROBE_DEFER;
> + ret = drm_of_find_panel_or_bridge(np, 0, 0, , );
> + if (ret)
> + return ret;
> 
> - panel = of_drm_find_panel(np);
>   if (panel) {
> - of_node_put(np);
>   output->connector.dpms = DRM_MODE_DPMS_OFF;
>   output->connector.polled = DRM_CONNECTOR_POLL_CONNECT;
>   drm_connector_helper_add(>connector,
> @@ -226,9 +206,6 @@ static int atmel_hlcdc_attach_endpoint(struct drm_device 
> *dev,
>   return 0;
>   }
> 
> - bridge = of_drm_find_bridge(np);
> - of_node_put(np);
> -
>   if (bridge) {
>   output->encoder.bridge = bridge;
>   bridge->encoder = >encoder;
> @@ -245,31 +222,14 @@ static int atmel_hlcdc_attach_endpoint(struct 
> drm_device *dev,
> 
>  int atmel_hlcdc_create_outputs(struct drm_device *dev)
>  {
> - struct device_node *ep_np = NULL;
> - struct of_endpoint ep;
> + struct device_node *remote;
>   int ret;
> 
> - for_each_endpoint_of_node(dev->dev->of_node, ep_np) {
> - ret = of_graph_parse_endpoint(ep_np, );
> - if (!ret)
> - ret = atmel_hlcdc_check_endpoint(dev, );
> -
> - if (ret) {
> - of_node_put(ep_np);
> - return ret;
> - }
> - }
> -
> - for_each_endpoint_of_node(dev->dev->of_node, ep_np) {
> - ret = of_graph_parse_endpoint(ep_np, );
> - if (!ret)
> - ret = atmel_hlcdc_attach_endpoint(dev, );
> -
> - if (ret) {
> - of_node_put(ep_np);
> - return ret;
> - }
> - }
> + remote = 

Re: [PATCH v2 5/6] drm: convert drivers to use drm_of_find_panel_or_bridge

[Boris Brezillon]

On Thu,  9 Feb 2017 13:05:57 -0600
Rob Herring  wrote:

> Similar to the previous commit, convert drivers open coding OF graph
> parsing to use drm_of_find_panel_or_bridge instead.
> 
> This changes some error messages to debug messages (in the graph core).
> Graph connections are often "no connects" depending on the particular
> board, so we want to avoid spurious messages. Plus the kernel is not a
> DT validator.
> 
> Signed-off-by: Rob Herring 
> ---
> v2:
> - fix wrong node ptr in imx-ldb
> - build fixes in kirin and imx drivers
> 
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 64 -
>  drivers/gpu/drm/bridge/nxp-ptn3460.c | 16 ++---
>  drivers/gpu/drm/bridge/parade-ps8622.c   | 16 ++---
>  drivers/gpu/drm/bridge/tc358767.c| 27 +--
>  drivers/gpu/drm/exynos/exynos_dp.c   | 35 -
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c| 49 -
>  drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 27 ++-
>  drivers/gpu/drm/imx/imx-ldb.c| 27 ++-
>  drivers/gpu/drm/imx/parallel-display.c   | 36 ++
>  drivers/gpu/drm/mediatek/mtk_dsi.c   | 23 ++
>  drivers/gpu/drm/mxsfb/mxsfb_out.c| 36 ++
>  drivers/gpu/drm/rockchip/analogix_dp-rockchip.c  | 26 ++-
>  drivers/gpu/drm/sun4i/sun4i_rgb.c| 13 ++--
>  drivers/gpu/drm/sun4i/sun4i_tcon.c   | 90 
> ++--
>  14 files changed, 88 insertions(+), 397 deletions(-)
> 
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c 
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
> index 6119b5085501..4614048a4935 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
> @@ -22,7 +22,7 @@
>  #include 
> 
>  #include 
> -#include 
> +#include 
> 
>  #include "atmel_hlcdc_dc.h"
> 
> @@ -152,29 +152,11 @@ static const struct drm_connector_funcs 
> atmel_hlcdc_panel_connector_funcs = {
>   .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
>  };
> 
> -static int atmel_hlcdc_check_endpoint(struct drm_device *dev,
> -   const struct of_endpoint *ep)
> -{
> - struct device_node *np;
> - void *obj;
> -
> - np = of_graph_get_remote_port_parent(ep->local_node);
> -
> - obj = of_drm_find_panel(np);
> - if (!obj)
> - obj = of_drm_find_bridge(np);
> -
> - of_node_put(np);
> -
> - return obj ? 0 : -EPROBE_DEFER;
> -}
> -
>  static int atmel_hlcdc_attach_endpoint(struct drm_device *dev,
> -const struct of_endpoint *ep)
> +const struct device_node *np)
>  {
>   struct atmel_hlcdc_dc *dc = dev->dev_private;
>   struct atmel_hlcdc_rgb_output *output;
> - struct device_node *np;
>   struct drm_panel *panel;
>   struct drm_bridge *bridge;
>   int ret;
> @@ -195,13 +177,11 @@ static int atmel_hlcdc_attach_endpoint(struct 
> drm_device *dev,
> 
>   output->encoder.possible_crtcs = 0x1;
> 
> - np = of_graph_get_remote_port_parent(ep->local_node);
> -
> - ret = -EPROBE_DEFER;
> + ret = drm_of_find_panel_or_bridge(np, 0, 0, , );
> + if (ret)
> + return ret;
> 
> - panel = of_drm_find_panel(np);
>   if (panel) {
> - of_node_put(np);
>   output->connector.dpms = DRM_MODE_DPMS_OFF;
>   output->connector.polled = DRM_CONNECTOR_POLL_CONNECT;
>   drm_connector_helper_add(>connector,
> @@ -226,9 +206,6 @@ static int atmel_hlcdc_attach_endpoint(struct drm_device 
> *dev,
>   return 0;
>   }
> 
> - bridge = of_drm_find_bridge(np);
> - of_node_put(np);
> -
>   if (bridge) {
>   output->encoder.bridge = bridge;
>   bridge->encoder = >encoder;
> @@ -245,31 +222,14 @@ static int atmel_hlcdc_attach_endpoint(struct 
> drm_device *dev,
> 
>  int atmel_hlcdc_create_outputs(struct drm_device *dev)
>  {
> - struct device_node *ep_np = NULL;
> - struct of_endpoint ep;
> + struct device_node *remote;
>   int ret;
> 
> - for_each_endpoint_of_node(dev->dev->of_node, ep_np) {
> - ret = of_graph_parse_endpoint(ep_np, );
> - if (!ret)
> - ret = atmel_hlcdc_check_endpoint(dev, );
> -
> - if (ret) {
> - of_node_put(ep_np);
> - return ret;
> - }
> - }
> -
> - for_each_endpoint_of_node(dev->dev->of_node, ep_np) {
> - ret = of_graph_parse_endpoint(ep_np, );
> - if (!ret)
> - ret = atmel_hlcdc_attach_endpoint(dev, );
> -
> - if (ret) {
> - of_node_put(ep_np);
> - return ret;
> - }
> - }
> + remote = of_graph_get_remote_node(dev->dev->of_node, 0, 0);
> + if (!remote)
> 

Re: [PATCH v2] gpio: return NULL from gpiod_get_optional when GPIOLIB is disabled

[Uwe Kleine-König]

Hello,

On Sun, Feb 12, 2017 at 05:15:01PM -0800, Dmitry Torokhov wrote:
> On Sun, Feb 12, 2017 at 05:13:55PM -0800, Dmitry Torokhov wrote:
> > Given the intent behind gpiod_get_optional() and friends it does not make
> > sense to return -ENOSYS when GPIOLIB is disabled: the driver is expected to
> > work just fine without gpio so let's behave as if gpio was not found.
> > Otherwise we have to special-case -ENOSYS in drivers.
> > 
> > Note that there was objection that someone might forget to enable GPIOLIB
> > when dealing with a platform that has device that actually specifies
> > optional gpio and we'll break it. I find this unconvincing as that would
> > have to be the *only GPIO* in the system, which is extremely unlikely.
> > 
> > Suggested-by: Uwe Kleine-König 

I don't like this patch and so I wonder what I wrote that could be
interpreted as suggesting this patch. For now I'd say only

Nacked-by: Uwe Kleine-König 

is justified.

My concern is still there. This might break some setups. IMHO it's not
ok to request that a device in a certain configuration only works when
the (optional) Kconfig option GPIOLIB is enabled and silently breaks if
it's not. And you cannot rely on the person who configured the kernel.

When accepting this you will burn debug time of others who see their
device breaking with no or unrelated error messages.

The only reliable way out here is to enable enough of GPIOLIB to only
return NULL in ..._optional when there is no gpio required. You can have
a suggested-by for that.

The semantic of gpiod_get_optional is:

if there is a gpio:
give it to me
else:
give me a dummy

If the kernel is configured to be unable to answer the question "is
there a gpio?" that is worth a -ENOSYS.

Best regards
Uwe

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

Re: [PATCH v2] gpio: return NULL from gpiod_get_optional when GPIOLIB is disabled

[Uwe Kleine-König]

Hello,

On Sun, Feb 12, 2017 at 05:15:01PM -0800, Dmitry Torokhov wrote:
> On Sun, Feb 12, 2017 at 05:13:55PM -0800, Dmitry Torokhov wrote:
> > Given the intent behind gpiod_get_optional() and friends it does not make
> > sense to return -ENOSYS when GPIOLIB is disabled: the driver is expected to
> > work just fine without gpio so let's behave as if gpio was not found.
> > Otherwise we have to special-case -ENOSYS in drivers.
> > 
> > Note that there was objection that someone might forget to enable GPIOLIB
> > when dealing with a platform that has device that actually specifies
> > optional gpio and we'll break it. I find this unconvincing as that would
> > have to be the *only GPIO* in the system, which is extremely unlikely.
> > 
> > Suggested-by: Uwe Kleine-König 

I don't like this patch and so I wonder what I wrote that could be
interpreted as suggesting this patch. For now I'd say only

Nacked-by: Uwe Kleine-König 

is justified.

My concern is still there. This might break some setups. IMHO it's not
ok to request that a device in a certain configuration only works when
the (optional) Kconfig option GPIOLIB is enabled and silently breaks if
it's not. And you cannot rely on the person who configured the kernel.

When accepting this you will burn debug time of others who see their
device breaking with no or unrelated error messages.

The only reliable way out here is to enable enough of GPIOLIB to only
return NULL in ..._optional when there is no gpio required. You can have
a suggested-by for that.

The semantic of gpiod_get_optional is:

if there is a gpio:
give it to me
else:
give me a dummy

If the kernel is configured to be unable to answer the question "is
there a gpio?" that is worth a -ENOSYS.

Best regards
Uwe

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

Re: [PATCH v2 1/9] llist: Provide a safe version for llist_for_each

[Byungchul Park]

On Mon, Feb 13, 2017 at 03:36:33PM +0800, Huang, Ying wrote:
> Byungchul Park  writes:
> 
> > Sometimes we have to dereference next field of llist node before entering
> > loop becasue the node might be deleted or the next field might be
> > modified within the loop. So this adds the safe version of llist_for_each,
> > that is, llist_for_each_safe.
> >
> > Signed-off-by: Byungchul Park 
> > ---
> >  include/linux/llist.h | 19 +++
> >  1 file changed, 19 insertions(+)
> >
> > diff --git a/include/linux/llist.h b/include/linux/llist.h
> > index fd4ca0b..4c508a5 100644
> > --- a/include/linux/llist.h
> > +++ b/include/linux/llist.h
> > @@ -105,6 +105,25 @@ static inline void init_llist_head(struct llist_head 
> > *list)
> > for ((pos) = (node); pos; (pos) = (pos)->next)
> >  
> >  /**
> > + * llist_for_each_safe - iterate over some deleted entries of a lock-less 
> > list
> > + *  safe against removal of list entry
> > + * @pos:   the  llist_node to use as a loop cursor
> > + * @n: another type * to use as temporary storage
> 
> s/type */ llist_node/

Yes.

> 
> > + * @node:  the first entry of deleted list entries
> > + *
> > + * In general, some entries of the lock-less list can be traversed
> > + * safely only after being deleted from list, so start with an entry
> > + * instead of list head.
> > + *
> > + * If being used on entries deleted from lock-less list directly, the
> > + * traverse order is from the newest to the oldest added entry.  If
> > + * you want to traverse from the oldest to the newest, you must
> > + * reverse the order by yourself before traversing.
> > + */
> > +#define llist_for_each_safe(pos, n, node)  \
> > +   for ((pos) = (node); (pos) && ((n) = (pos)->next, true); (pos) = (n))
> > +
> 
> Following the style of other xxx_for_each_safe,
> 
> #define llist_for_each_safe(pos, n, node) \
>   for (pos = (node), (pos && (n = pos->next)); pos; pos = n, n = 
> pos->next)

Do you think it should be modified? I think mine is simpler. No?

> 
> Best Regards,
> Huang, Ying
> 
> > +/**
> >   * llist_for_each_entry - iterate over some deleted entries of lock-less 
> > list of given type
> >   * @pos:   the type * to use as a loop cursor.
> >   * @node:  the fist entry of deleted list entries.

Re: [PATCH v2 1/9] llist: Provide a safe version for llist_for_each

[Byungchul Park]

On Mon, Feb 13, 2017 at 03:36:33PM +0800, Huang, Ying wrote:
> Byungchul Park  writes:
> 
> > Sometimes we have to dereference next field of llist node before entering
> > loop becasue the node might be deleted or the next field might be
> > modified within the loop. So this adds the safe version of llist_for_each,
> > that is, llist_for_each_safe.
> >
> > Signed-off-by: Byungchul Park 
> > ---
> >  include/linux/llist.h | 19 +++
> >  1 file changed, 19 insertions(+)
> >
> > diff --git a/include/linux/llist.h b/include/linux/llist.h
> > index fd4ca0b..4c508a5 100644
> > --- a/include/linux/llist.h
> > +++ b/include/linux/llist.h
> > @@ -105,6 +105,25 @@ static inline void init_llist_head(struct llist_head 
> > *list)
> > for ((pos) = (node); pos; (pos) = (pos)->next)
> >  
> >  /**
> > + * llist_for_each_safe - iterate over some deleted entries of a lock-less 
> > list
> > + *  safe against removal of list entry
> > + * @pos:   the  llist_node to use as a loop cursor
> > + * @n: another type * to use as temporary storage
> 
> s/type */ llist_node/

Yes.

> 
> > + * @node:  the first entry of deleted list entries
> > + *
> > + * In general, some entries of the lock-less list can be traversed
> > + * safely only after being deleted from list, so start with an entry
> > + * instead of list head.
> > + *
> > + * If being used on entries deleted from lock-less list directly, the
> > + * traverse order is from the newest to the oldest added entry.  If
> > + * you want to traverse from the oldest to the newest, you must
> > + * reverse the order by yourself before traversing.
> > + */
> > +#define llist_for_each_safe(pos, n, node)  \
> > +   for ((pos) = (node); (pos) && ((n) = (pos)->next, true); (pos) = (n))
> > +
> 
> Following the style of other xxx_for_each_safe,
> 
> #define llist_for_each_safe(pos, n, node) \
>   for (pos = (node), (pos && (n = pos->next)); pos; pos = n, n = 
> pos->next)

Do you think it should be modified? I think mine is simpler. No?

> 
> Best Regards,
> Huang, Ying
> 
> > +/**
> >   * llist_for_each_entry - iterate over some deleted entries of lock-less 
> > list of given type
> >   * @pos:   the type * to use as a loop cursor.
> >   * @node:  the fist entry of deleted list entries.

Re: [PATCH RFC] spi-nor: provide a range for poll_timout

[Nicholas Mc Guire]

On Sun, Feb 12, 2017 at 10:59:23PM +0100, Boris Brezillon wrote:
> +Mika
> 
> On Sun, 12 Feb 2017 17:42:57 +0100
> Nicholas Mc Guire  wrote:
> 
> > The overall poll time here is INTEL_SPI_TIMEOUT * 1000 which is 
> > 5000 * 1000 - so 5seconds and it is coded as a tight loop here delay_us
> > to readl_poll_timeout() is set to 0. As this is never called in an atomic
> > context sleeping should be no issue and there is no reasons for the
> > tight-loop here.
> 
> Hm, let's wait for Mika's feedback on this one. BTW, can you please Cc
> him on you other spi-nor/intel patches and prefix your patches with the
> driver name ('mtd: spi-nor: intel: ') so that we know where the changes
> are made (without this prefix it looks like you're touching core files)?
>

will do - just saw that his email shows up in git plame which I normally also 
include along with what scripts/get_maintainer.pl -f shows - sorry for the 
ommision.

thx!
hofrat
 
> 
> > 
> > Signed-off-by: Nicholas Mc Guire 
> > ---
> > 
> > Problem located by experimental coccinelle script:
> > ./drivers/mtd/spi-nor/intel-spi.c:265:8-26: WARNING: usleep_range min=0 for 
> > delay INTEL_SPI_TIMEOUT * 1000
> > ./drivers/mtd/spi-nor/intel-spi.c:274:8-26: WARNING: usleep_range min=0 for 
> > delay INTEL_SPI_TIMEOUT * 1000
> > 
> > The rational for setting the delay_us here to 40 is that 
> > readx_poll_timeout()
> > will take delay_us >> 2 + 1 as min value and that should be at least 10us 
> > (see
> > Documentation/timers/timers-howto.txt). Ideally the delay would be made
> > even larger to keep the load on the hrtimer subsystem low as these delays
> > here do not seem to be critical. Someone that knows the details of this 
> > device
> > would need to check if a larger delay would be ok here.
> > 
> > Patch was compile tested with: multi_v7_defconfig (implies 
> > CONFIG_MTD_SPI_NOR=y)
> > one coccicheck finding reported and one spars finding (in separate patches)
> > 
> > Patch is against 4.10-rc6 (localversion-next is next-20170210)
> > 
> >  drivers/mtd/spi-nor/intel-spi.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/mtd/spi-nor/intel-spi.c 
> > b/drivers/mtd/spi-nor/intel-spi.c
> > index a10f602..371bcf9 100644
> > --- a/drivers/mtd/spi-nor/intel-spi.c
> > +++ b/drivers/mtd/spi-nor/intel-spi.c
> > @@ -263,7 +263,7 @@ static int intel_spi_wait_hw_busy(struct intel_spi 
> > *ispi)
> > u32 val;
> >  
> > return readl_poll_timeout(ispi->base + HSFSTS_CTL, val,
> > - !(val & HSFSTS_CTL_SCIP), 0,
> > + !(val & HSFSTS_CTL_SCIP), 40,
> >   INTEL_SPI_TIMEOUT * 1000);
> >  }
> >  
> > @@ -272,7 +272,7 @@ static int intel_spi_wait_sw_busy(struct intel_spi 
> > *ispi)
> > u32 val;
> >  
> > return readl_poll_timeout(ispi->sregs + SSFSTS_CTL, val,
> > - !(val & SSFSTS_CTL_SCIP), 0,
> > + !(val & SSFSTS_CTL_SCIP), 40,
> >   INTEL_SPI_TIMEOUT * 1000);
> >  }
> >  
> 

RE: [PATCH v3 1/2] mtd: ifc: Update dependency of IFC for LS1021A

[Alison Wang]

Hi, Boris,

Sorry, I forgot to change them. Should I resend them or you help to fix 
that when applying?


Best Regards,
Alison Wang

> 
> Hi Alison,
> 
> The subject prefix is still wrong, should be 'memory: ifc: '.
> 
> On Mon, 13 Feb 2017 14:46:55 +0800
> Alison Wang  wrote:
> 
> > As Freescale/NXP IFC controller is available on LS1021A, the
> > dependency for LS1021A is added.
> >
> > LS1021A is an earlier product and is not compatible with later
> > LayerScape architecture. So ARCH_LAYERSCAPE can't cover LS1021A.
> >
> > Signed-off-by: Alison Wang 
> > ---
> > Changes in v3:
> > - Update the commit message.
> >
> > Changes in v2:
> > - New patch
> >
> >  drivers/memory/Kconfig | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig index
> > ec80e35..fff8345 100644
> > --- a/drivers/memory/Kconfig
> > +++ b/drivers/memory/Kconfig
> > @@ -115,7 +115,7 @@ config FSL_CORENET_CF
> >
> >  config FSL_IFC
> > bool
> > -   depends on FSL_SOC || ARCH_LAYERSCAPE
> > +   depends on FSL_SOC || ARCH_LAYERSCAPE || SOC_LS1021A
> >
> >  config JZ4780_NEMC
> > bool "Ingenic JZ4780 SoC NEMC driver"

Re: [PATCH RFC] spi-nor: provide a range for poll_timout

[Nicholas Mc Guire]

On Sun, Feb 12, 2017 at 10:59:23PM +0100, Boris Brezillon wrote:
> +Mika
> 
> On Sun, 12 Feb 2017 17:42:57 +0100
> Nicholas Mc Guire  wrote:
> 
> > The overall poll time here is INTEL_SPI_TIMEOUT * 1000 which is 
> > 5000 * 1000 - so 5seconds and it is coded as a tight loop here delay_us
> > to readl_poll_timeout() is set to 0. As this is never called in an atomic
> > context sleeping should be no issue and there is no reasons for the
> > tight-loop here.
> 
> Hm, let's wait for Mika's feedback on this one. BTW, can you please Cc
> him on you other spi-nor/intel patches and prefix your patches with the
> driver name ('mtd: spi-nor: intel: ') so that we know where the changes
> are made (without this prefix it looks like you're touching core files)?
>

will do - just saw that his email shows up in git plame which I normally also 
include along with what scripts/get_maintainer.pl -f shows - sorry for the 
ommision.

thx!
hofrat
 
> 
> > 
> > Signed-off-by: Nicholas Mc Guire 
> > ---
> > 
> > Problem located by experimental coccinelle script:
> > ./drivers/mtd/spi-nor/intel-spi.c:265:8-26: WARNING: usleep_range min=0 for 
> > delay INTEL_SPI_TIMEOUT * 1000
> > ./drivers/mtd/spi-nor/intel-spi.c:274:8-26: WARNING: usleep_range min=0 for 
> > delay INTEL_SPI_TIMEOUT * 1000
> > 
> > The rational for setting the delay_us here to 40 is that 
> > readx_poll_timeout()
> > will take delay_us >> 2 + 1 as min value and that should be at least 10us 
> > (see
> > Documentation/timers/timers-howto.txt). Ideally the delay would be made
> > even larger to keep the load on the hrtimer subsystem low as these delays
> > here do not seem to be critical. Someone that knows the details of this 
> > device
> > would need to check if a larger delay would be ok here.
> > 
> > Patch was compile tested with: multi_v7_defconfig (implies 
> > CONFIG_MTD_SPI_NOR=y)
> > one coccicheck finding reported and one spars finding (in separate patches)
> > 
> > Patch is against 4.10-rc6 (localversion-next is next-20170210)
> > 
> >  drivers/mtd/spi-nor/intel-spi.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/mtd/spi-nor/intel-spi.c 
> > b/drivers/mtd/spi-nor/intel-spi.c
> > index a10f602..371bcf9 100644
> > --- a/drivers/mtd/spi-nor/intel-spi.c
> > +++ b/drivers/mtd/spi-nor/intel-spi.c
> > @@ -263,7 +263,7 @@ static int intel_spi_wait_hw_busy(struct intel_spi 
> > *ispi)
> > u32 val;
> >  
> > return readl_poll_timeout(ispi->base + HSFSTS_CTL, val,
> > - !(val & HSFSTS_CTL_SCIP), 0,
> > + !(val & HSFSTS_CTL_SCIP), 40,
> >   INTEL_SPI_TIMEOUT * 1000);
> >  }
> >  
> > @@ -272,7 +272,7 @@ static int intel_spi_wait_sw_busy(struct intel_spi 
> > *ispi)
> > u32 val;
> >  
> > return readl_poll_timeout(ispi->sregs + SSFSTS_CTL, val,
> > - !(val & SSFSTS_CTL_SCIP), 0,
> > + !(val & SSFSTS_CTL_SCIP), 40,
> >   INTEL_SPI_TIMEOUT * 1000);
> >  }
> >  
> 

RE: [PATCH v3 1/2] mtd: ifc: Update dependency of IFC for LS1021A

[Alison Wang]

Hi, Boris,

Sorry, I forgot to change them. Should I resend them or you help to fix 
that when applying?


Best Regards,
Alison Wang

> 
> Hi Alison,
> 
> The subject prefix is still wrong, should be 'memory: ifc: '.
> 
> On Mon, 13 Feb 2017 14:46:55 +0800
> Alison Wang  wrote:
> 
> > As Freescale/NXP IFC controller is available on LS1021A, the
> > dependency for LS1021A is added.
> >
> > LS1021A is an earlier product and is not compatible with later
> > LayerScape architecture. So ARCH_LAYERSCAPE can't cover LS1021A.
> >
> > Signed-off-by: Alison Wang 
> > ---
> > Changes in v3:
> > - Update the commit message.
> >
> > Changes in v2:
> > - New patch
> >
> >  drivers/memory/Kconfig | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig index
> > ec80e35..fff8345 100644
> > --- a/drivers/memory/Kconfig
> > +++ b/drivers/memory/Kconfig
> > @@ -115,7 +115,7 @@ config FSL_CORENET_CF
> >
> >  config FSL_IFC
> > bool
> > -   depends on FSL_SOC || ARCH_LAYERSCAPE
> > +   depends on FSL_SOC || ARCH_LAYERSCAPE || SOC_LS1021A
> >
> >  config JZ4780_NEMC
> > bool "Ingenic JZ4780 SoC NEMC driver"

Re: [PATCH v3 2/2] gpio: mockup: implement event injecting over debugfs

[Linus Walleij]

On Mon, Feb 6, 2017 at 3:11 PM, Bartosz Golaszewski
 wrote:

> Create a debugfs directory for every mockup chip and a single file
> for every line. Writing (0 or 1) to these files allows the user to
> inject line events (falling or rising edge respectively).
>
> Signed-off-by: Bartosz Golaszewski 

Patch applied.

Yours,
Linus Walleij

Re: [PATCH v3 2/2] gpio: mockup: implement event injecting over debugfs

[Linus Walleij]

On Mon, Feb 6, 2017 at 3:11 PM, Bartosz Golaszewski
 wrote:

> Create a debugfs directory for every mockup chip and a single file
> for every line. Writing (0 or 1) to these files allows the user to
> inject line events (falling or rising edge respectively).
>
> Signed-off-by: Bartosz Golaszewski 

Patch applied.

Yours,
Linus Walleij

Re: [PATCH] spi-nor: use true/false for bool

[Nicholas Mc Guire]

On Sun, Feb 12, 2017 at 11:01:44PM +0100, Boris Brezillon wrote:
> +Mika
> 
> On Sun, 12 Feb 2017 22:50:44 +0100
> Boris Brezillon  wrote:
> 
> > On Sun, 12 Feb 2017 17:43:31 +0100
> > Nicholas Mc Guire  wrote:
> > 
> > > writeable in struct intel_spi is a boolean and assignment should be to 
> > > true/false not 1/0 as recommended by boolinit.cocci.
> > > 
> > > Signed-off-by: Nicholas Mc Guire   
> > 
> > Acked-by: Boris Brezillon 
> 
> As asked in my other review, please use the 'mtd: spi-nor: intel'
> prefix (or anything that would clarify the scope of this patch, like
> 'mtd: spi-nor/intel: ').
>

yup - will fix it up - just not yet clear how
to find the proper prefix next time - the method I
had been using seems insufficient.

thx!
hofrat
 
> 
> > 
> > > ---
> > > 
> > > make coccicheck complained with:
> > >  ./drivers/mtd/spi-nor/intel-spi.c:707:3-18: WARNING: Assignment of bool 
> > > to 0/1
> > > 
> > > Patch was compile tested with: multi_v7_defconfig (implies 
> > > CONFIG_MTD_SPI_NOR=y)
> > > 
> > > Patch is against 4.10-rc6 (localversion-next is next-20170210)
> > > 
> > >  drivers/mtd/spi-nor/intel-spi.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/mtd/spi-nor/intel-spi.c 
> > > b/drivers/mtd/spi-nor/intel-spi.c
> > > index a10f602..e43ce63 100644
> > > --- a/drivers/mtd/spi-nor/intel-spi.c
> > > +++ b/drivers/mtd/spi-nor/intel-spi.c
> > > @@ -704,7 +704,7 @@ static void intel_spi_fill_partition(struct intel_spi 
> > > *ispi,
> > >* whole partition read-only to be on the safe side.
> > >*/
> > >   if (intel_spi_is_protected(ispi, base, limit))
> > > - ispi->writeable = 0;
> > > + ispi->writeable = false;
> > >  
> > >   end = (limit << 12) + 4096;
> > >   if (end > part->size)  
> > 
> 

Re: [PATCH] spi-nor: use true/false for bool

[Nicholas Mc Guire]

On Sun, Feb 12, 2017 at 11:01:44PM +0100, Boris Brezillon wrote:
> +Mika
> 
> On Sun, 12 Feb 2017 22:50:44 +0100
> Boris Brezillon  wrote:
> 
> > On Sun, 12 Feb 2017 17:43:31 +0100
> > Nicholas Mc Guire  wrote:
> > 
> > > writeable in struct intel_spi is a boolean and assignment should be to 
> > > true/false not 1/0 as recommended by boolinit.cocci.
> > > 
> > > Signed-off-by: Nicholas Mc Guire   
> > 
> > Acked-by: Boris Brezillon 
> 
> As asked in my other review, please use the 'mtd: spi-nor: intel'
> prefix (or anything that would clarify the scope of this patch, like
> 'mtd: spi-nor/intel: ').
>

yup - will fix it up - just not yet clear how
to find the proper prefix next time - the method I
had been using seems insufficient.

thx!
hofrat
 
> 
> > 
> > > ---
> > > 
> > > make coccicheck complained with:
> > >  ./drivers/mtd/spi-nor/intel-spi.c:707:3-18: WARNING: Assignment of bool 
> > > to 0/1
> > > 
> > > Patch was compile tested with: multi_v7_defconfig (implies 
> > > CONFIG_MTD_SPI_NOR=y)
> > > 
> > > Patch is against 4.10-rc6 (localversion-next is next-20170210)
> > > 
> > >  drivers/mtd/spi-nor/intel-spi.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/mtd/spi-nor/intel-spi.c 
> > > b/drivers/mtd/spi-nor/intel-spi.c
> > > index a10f602..e43ce63 100644
> > > --- a/drivers/mtd/spi-nor/intel-spi.c
> > > +++ b/drivers/mtd/spi-nor/intel-spi.c
> > > @@ -704,7 +704,7 @@ static void intel_spi_fill_partition(struct intel_spi 
> > > *ispi,
> > >* whole partition read-only to be on the safe side.
> > >*/
> > >   if (intel_spi_is_protected(ispi, base, limit))
> > > - ispi->writeable = 0;
> > > + ispi->writeable = false;
> > >  
> > >   end = (limit << 12) + 4096;
> > >   if (end > part->size)  
> > 
> 

Re: [PATCH v3 1/2] gpio: mockup: add a dummy irqchip

[Linus Walleij]

On Mon, Feb 6, 2017 at 3:11 PM, Bartosz Golaszewski
 wrote:

> Setup a dummy irqchip that will allow us to inject line events for
> testing purposes.
>
> Signed-off-by: Bartosz Golaszewski 

Patch applied.

Yours,
Linus Walleij

Re: [PATCH] spi-nor: use ERR_CAST in return

[Nicholas Mc Guire]

On Sun, Feb 12, 2017 at 11:04:10PM +0100, Boris Brezillon wrote:
> +Mika
> 
> On Sun, 12 Feb 2017 22:45:43 +0100
> Boris Brezillon  wrote:
> 
> > On Sun, 12 Feb 2017 17:43:43 +0100
> > Nicholas Mc Guire  wrote:
> > 
> > > This fixes a sparse warning about   
> > 
> > Your commit message seems to be incomplete.
> 
> And here too, please change the prefix to "mtd: spi-nor: intel: ".
>

What Im doing for checking prefix is:
hofrat@debian:~/git/linux-next$ git log --oneline 
drivers/mtd/spi-nor/intel-spi.c
8afda8b spi-nor: Add support for Intel SPI serial flash controller

is the method of checking the commit prefix with git log --oneline inapropriate 
? How would I have found the "mtd: spi-nor: intel:" in this case ?

thx!
ohfrat
 
> > 
> > Once fixed,
> > 
> > Acked-by: Boris Brezillon 
> > 
> > > 
> > > Signed-off-by: Nicholas Mc Guire 
> > > ---
> > > 
> > > sparse complained about:
> > > drivers/mtd/spi-nor/intel-spi.c:731:28: warning: incorrect type in return 
> > > expression (different address spaces)
> > > drivers/mtd/spi-nor/intel-spi.c:731:28:expected struct intel_spi *
> > > drivers/mtd/spi-nor/intel-spi.c:731:28:got void [noderef] *base
> > > 
> > > Patch was compile tested with: multi_v7_defconfig (implies 
> > > CONFIG_MTD_SPI_NOR=y)
> > > 
> > > Patch is against 4.10-rc6 (localversion-next is next-20170210)
> > > 
> > >  drivers/mtd/spi-nor/intel-spi.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/mtd/spi-nor/intel-spi.c 
> > > b/drivers/mtd/spi-nor/intel-spi.c
> > > index e43ce63..986a3d0 100644
> > > --- a/drivers/mtd/spi-nor/intel-spi.c
> > > +++ b/drivers/mtd/spi-nor/intel-spi.c
> > > @@ -728,7 +728,7 @@ struct intel_spi *intel_spi_probe(struct device *dev,
> > >  
> > >   ispi->base = devm_ioremap_resource(dev, mem);
> > >   if (IS_ERR(ispi->base))
> > > - return ispi->base;
> > > + return ERR_CAST(ispi->base);
> > >  
> > >   ispi->dev = dev;
> > >   ispi->info = info;  
> > 
> 

Re: [PATCH v2 1/9] llist: Provide a safe version for llist_for_each

[Huang, Ying]

Byungchul Park  writes:

> Sometimes we have to dereference next field of llist node before entering
> loop becasue the node might be deleted or the next field might be
> modified within the loop. So this adds the safe version of llist_for_each,
> that is, llist_for_each_safe.
>
> Signed-off-by: Byungchul Park 
> ---
>  include/linux/llist.h | 19 +++
>  1 file changed, 19 insertions(+)
>
> diff --git a/include/linux/llist.h b/include/linux/llist.h
> index fd4ca0b..4c508a5 100644
> --- a/include/linux/llist.h
> +++ b/include/linux/llist.h
> @@ -105,6 +105,25 @@ static inline void init_llist_head(struct llist_head 
> *list)
>   for ((pos) = (node); pos; (pos) = (pos)->next)
>  
>  /**
> + * llist_for_each_safe - iterate over some deleted entries of a lock-less 
> list
> + *safe against removal of list entry
> + * @pos: the  llist_node to use as a loop cursor
> + * @n:   another type * to use as temporary storage

s/type */ llist_node/

> + * @node:the first entry of deleted list entries
> + *
> + * In general, some entries of the lock-less list can be traversed
> + * safely only after being deleted from list, so start with an entry
> + * instead of list head.
> + *
> + * If being used on entries deleted from lock-less list directly, the
> + * traverse order is from the newest to the oldest added entry.  If
> + * you want to traverse from the oldest to the newest, you must
> + * reverse the order by yourself before traversing.
> + */
> +#define llist_for_each_safe(pos, n, node)\
> + for ((pos) = (node); (pos) && ((n) = (pos)->next, true); (pos) = (n))
> +

Following the style of other xxx_for_each_safe,

#define llist_for_each_safe(pos, n, node)   \
for (pos = (node), (pos && (n = pos->next)); pos; pos = n, n = 
pos->next)

Best Regards,
Huang, Ying

> +/**
>   * llist_for_each_entry - iterate over some deleted entries of lock-less 
> list of given type
>   * @pos: the type * to use as a loop cursor.
>   * @node:the fist entry of deleted list entries.

Re: [PATCH v3 1/2] gpio: mockup: add a dummy irqchip

[Linus Walleij]

On Mon, Feb 6, 2017 at 3:11 PM, Bartosz Golaszewski
 wrote:

> Setup a dummy irqchip that will allow us to inject line events for
> testing purposes.
>
> Signed-off-by: Bartosz Golaszewski 

Patch applied.

Yours,
Linus Walleij

Re: [PATCH] spi-nor: use ERR_CAST in return

[Nicholas Mc Guire]

On Sun, Feb 12, 2017 at 11:04:10PM +0100, Boris Brezillon wrote:
> +Mika
> 
> On Sun, 12 Feb 2017 22:45:43 +0100
> Boris Brezillon  wrote:
> 
> > On Sun, 12 Feb 2017 17:43:43 +0100
> > Nicholas Mc Guire  wrote:
> > 
> > > This fixes a sparse warning about   
> > 
> > Your commit message seems to be incomplete.
> 
> And here too, please change the prefix to "mtd: spi-nor: intel: ".
>

What Im doing for checking prefix is:
hofrat@debian:~/git/linux-next$ git log --oneline 
drivers/mtd/spi-nor/intel-spi.c
8afda8b spi-nor: Add support for Intel SPI serial flash controller

is the method of checking the commit prefix with git log --oneline inapropriate 
? How would I have found the "mtd: spi-nor: intel:" in this case ?

thx!
ohfrat
 
> > 
> > Once fixed,
> > 
> > Acked-by: Boris Brezillon 
> > 
> > > 
> > > Signed-off-by: Nicholas Mc Guire 
> > > ---
> > > 
> > > sparse complained about:
> > > drivers/mtd/spi-nor/intel-spi.c:731:28: warning: incorrect type in return 
> > > expression (different address spaces)
> > > drivers/mtd/spi-nor/intel-spi.c:731:28:expected struct intel_spi *
> > > drivers/mtd/spi-nor/intel-spi.c:731:28:got void [noderef] *base
> > > 
> > > Patch was compile tested with: multi_v7_defconfig (implies 
> > > CONFIG_MTD_SPI_NOR=y)
> > > 
> > > Patch is against 4.10-rc6 (localversion-next is next-20170210)
> > > 
> > >  drivers/mtd/spi-nor/intel-spi.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/mtd/spi-nor/intel-spi.c 
> > > b/drivers/mtd/spi-nor/intel-spi.c
> > > index e43ce63..986a3d0 100644
> > > --- a/drivers/mtd/spi-nor/intel-spi.c
> > > +++ b/drivers/mtd/spi-nor/intel-spi.c
> > > @@ -728,7 +728,7 @@ struct intel_spi *intel_spi_probe(struct device *dev,
> > >  
> > >   ispi->base = devm_ioremap_resource(dev, mem);
> > >   if (IS_ERR(ispi->base))
> > > - return ispi->base;
> > > + return ERR_CAST(ispi->base);
> > >  
> > >   ispi->dev = dev;
> > >   ispi->info = info;  
> > 
> 

Re: [PATCH v2 1/9] llist: Provide a safe version for llist_for_each

[Huang, Ying]

Byungchul Park  writes:

> Sometimes we have to dereference next field of llist node before entering
> loop becasue the node might be deleted or the next field might be
> modified within the loop. So this adds the safe version of llist_for_each,
> that is, llist_for_each_safe.
>
> Signed-off-by: Byungchul Park 
> ---
>  include/linux/llist.h | 19 +++
>  1 file changed, 19 insertions(+)
>
> diff --git a/include/linux/llist.h b/include/linux/llist.h
> index fd4ca0b..4c508a5 100644
> --- a/include/linux/llist.h
> +++ b/include/linux/llist.h
> @@ -105,6 +105,25 @@ static inline void init_llist_head(struct llist_head 
> *list)
>   for ((pos) = (node); pos; (pos) = (pos)->next)
>  
>  /**
> + * llist_for_each_safe - iterate over some deleted entries of a lock-less 
> list
> + *safe against removal of list entry
> + * @pos: the  llist_node to use as a loop cursor
> + * @n:   another type * to use as temporary storage

s/type */ llist_node/

> + * @node:the first entry of deleted list entries
> + *
> + * In general, some entries of the lock-less list can be traversed
> + * safely only after being deleted from list, so start with an entry
> + * instead of list head.
> + *
> + * If being used on entries deleted from lock-less list directly, the
> + * traverse order is from the newest to the oldest added entry.  If
> + * you want to traverse from the oldest to the newest, you must
> + * reverse the order by yourself before traversing.
> + */
> +#define llist_for_each_safe(pos, n, node)\
> + for ((pos) = (node); (pos) && ((n) = (pos)->next, true); (pos) = (n))
> +

Following the style of other xxx_for_each_safe,

#define llist_for_each_safe(pos, n, node)   \
for (pos = (node), (pos && (n = pos->next)); pos; pos = n, n = 
pos->next)

Best Regards,
Huang, Ying

> +/**
>   * llist_for_each_entry - iterate over some deleted entries of lock-less 
> list of given type
>   * @pos: the type * to use as a loop cursor.
>   * @node:the fist entry of deleted list entries.

Re: [PATCH v3 1/2] mtd: ifc: Update dependency of IFC for LS1021A

[Boris Brezillon]

Hi Alison,

The subject prefix is still wrong, should be 'memory: ifc: '.

On Mon, 13 Feb 2017 14:46:55 +0800
Alison Wang  wrote:

> As Freescale/NXP IFC controller is available on LS1021A, the dependency
> for LS1021A is added.
> 
> LS1021A is an earlier product and is not compatible with later
> LayerScape architecture. So ARCH_LAYERSCAPE can't cover LS1021A.
> 
> Signed-off-by: Alison Wang 
> ---
> Changes in v3:
> - Update the commit message.
> 
> Changes in v2:
> - New patch
> 
>  drivers/memory/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig
> index ec80e35..fff8345 100644
> --- a/drivers/memory/Kconfig
> +++ b/drivers/memory/Kconfig
> @@ -115,7 +115,7 @@ config FSL_CORENET_CF
>  
>  config FSL_IFC
>   bool
> - depends on FSL_SOC || ARCH_LAYERSCAPE
> + depends on FSL_SOC || ARCH_LAYERSCAPE || SOC_LS1021A
>  
>  config JZ4780_NEMC
>   bool "Ingenic JZ4780 SoC NEMC driver"

Re: [PATCH v3 1/2] mtd: ifc: Update dependency of IFC for LS1021A

[Boris Brezillon]

Hi Alison,

The subject prefix is still wrong, should be 'memory: ifc: '.

On Mon, 13 Feb 2017 14:46:55 +0800
Alison Wang  wrote:

> As Freescale/NXP IFC controller is available on LS1021A, the dependency
> for LS1021A is added.
> 
> LS1021A is an earlier product and is not compatible with later
> LayerScape architecture. So ARCH_LAYERSCAPE can't cover LS1021A.
> 
> Signed-off-by: Alison Wang 
> ---
> Changes in v3:
> - Update the commit message.
> 
> Changes in v2:
> - New patch
> 
>  drivers/memory/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig
> index ec80e35..fff8345 100644
> --- a/drivers/memory/Kconfig
> +++ b/drivers/memory/Kconfig
> @@ -115,7 +115,7 @@ config FSL_CORENET_CF
>  
>  config FSL_IFC
>   bool
> - depends on FSL_SOC || ARCH_LAYERSCAPE
> + depends on FSL_SOC || ARCH_LAYERSCAPE || SOC_LS1021A
>  
>  config JZ4780_NEMC
>   bool "Ingenic JZ4780 SoC NEMC driver"

[PATCH v2 1/9] llist: Provide a safe version for llist_for_each

[Byungchul Park]

Sometimes we have to dereference next field of llist node before entering
loop becasue the node might be deleted or the next field might be
modified within the loop. So this adds the safe version of llist_for_each,
that is, llist_for_each_safe.

Signed-off-by: Byungchul Park 
---
 include/linux/llist.h | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/include/linux/llist.h b/include/linux/llist.h
index fd4ca0b..4c508a5 100644
--- a/include/linux/llist.h
+++ b/include/linux/llist.h
@@ -105,6 +105,25 @@ static inline void init_llist_head(struct llist_head *list)
for ((pos) = (node); pos; (pos) = (pos)->next)
 
 /**
+ * llist_for_each_safe - iterate over some deleted entries of a lock-less list
+ *  safe against removal of list entry
+ * @pos:   the  llist_node to use as a loop cursor
+ * @n: another type * to use as temporary storage
+ * @node:  the first entry of deleted list entries
+ *
+ * In general, some entries of the lock-less list can be traversed
+ * safely only after being deleted from list, so start with an entry
+ * instead of list head.
+ *
+ * If being used on entries deleted from lock-less list directly, the
+ * traverse order is from the newest to the oldest added entry.  If
+ * you want to traverse from the oldest to the newest, you must
+ * reverse the order by yourself before traversing.
+ */
+#define llist_for_each_safe(pos, n, node)  \
+   for ((pos) = (node); (pos) && ((n) = (pos)->next, true); (pos) = (n))
+
+/**
  * llist_for_each_entry - iterate over some deleted entries of lock-less list 
of given type
  * @pos:   the type * to use as a loop cursor.
  * @node:  the fist entry of deleted list entries.
-- 
1.9.1

[PATCH v2 1/9] llist: Provide a safe version for llist_for_each

[Byungchul Park]

Sometimes we have to dereference next field of llist node before entering
loop becasue the node might be deleted or the next field might be
modified within the loop. So this adds the safe version of llist_for_each,
that is, llist_for_each_safe.

Signed-off-by: Byungchul Park 
---
 include/linux/llist.h | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/include/linux/llist.h b/include/linux/llist.h
index fd4ca0b..4c508a5 100644
--- a/include/linux/llist.h
+++ b/include/linux/llist.h
@@ -105,6 +105,25 @@ static inline void init_llist_head(struct llist_head *list)
for ((pos) = (node); pos; (pos) = (pos)->next)
 
 /**
+ * llist_for_each_safe - iterate over some deleted entries of a lock-less list
+ *  safe against removal of list entry
+ * @pos:   the  llist_node to use as a loop cursor
+ * @n: another type * to use as temporary storage
+ * @node:  the first entry of deleted list entries
+ *
+ * In general, some entries of the lock-less list can be traversed
+ * safely only after being deleted from list, so start with an entry
+ * instead of list head.
+ *
+ * If being used on entries deleted from lock-less list directly, the
+ * traverse order is from the newest to the oldest added entry.  If
+ * you want to traverse from the oldest to the newest, you must
+ * reverse the order by yourself before traversing.
+ */
+#define llist_for_each_safe(pos, n, node)  \
+   for ((pos) = (node); (pos) && ((n) = (pos)->next, true); (pos) = (n))
+
+/**
  * llist_for_each_entry - iterate over some deleted entries of lock-less list 
of given type
  * @pos:   the type * to use as a loop cursor.
  * @node:  the fist entry of deleted list entries.
-- 
1.9.1

[PATCH v2 6/9] namespace.c: Don't reinvent the wheel but use existing llist API

[Byungchul Park]

Although llist provides proper APIs, they are not used. Make them used.

Signed-off-by: Byungchul Park 
---
 fs/namespace.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/fs/namespace.c b/fs/namespace.c
index b5b1259..5cb2229 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -1082,12 +1082,10 @@ static void __cleanup_mnt(struct rcu_head *head)
 static void delayed_mntput(struct work_struct *unused)
 {
struct llist_node *node = llist_del_all(_mntput_list);
-   struct llist_node *next;
+   struct mount *m, *t;
 
-   for (; node; node = next) {
-   next = llist_next(node);
-   cleanup_mnt(llist_entry(node, struct mount, mnt_llist));
-   }
+   llist_for_each_entry_safe(m, t, node, mnt_llist)
+   cleanup_mnt(m);
 }
 static DECLARE_DELAYED_WORK(delayed_mntput_work, delayed_mntput);
 
@@ -1615,7 +1613,7 @@ void __detach_mounts(struct dentry *dentry)
namespace_unlock();
 }
 
-/* 
+/*
  * Is the caller allowed to modify his namespace?
  */
 static inline bool may_mount(void)
@@ -2159,7 +2157,7 @@ static int do_loopback(struct path *path, const char 
*old_name,
 
err = -EINVAL;
if (mnt_ns_loop(old_path.dentry))
-   goto out; 
+   goto out;
 
mp = lock_mount(path);
err = PTR_ERR(mp);
-- 
1.9.1

[PATCH v2 0/9] Don't reinvent the wheel but use existing llist API

[Byungchul Park]

Change from v1
- split one patch to several ones, one for each subsystem.
- replace for_each with the safe version where it's necessary.

Byungchul Park (9):
  llist: Provide a safe version for llist_for_each
  bcache: Don't reinvent the wheel but use existing llist API
  raid5: Don't reinvent the wheel but use existing llist API
  vhost/scsi: Don't reinvent the wheel but use existing llist API
  fput: Don't reinvent the wheel but use existing llist API
  namespace.c: Don't reinvent the wheel but use existing llist API
  irq_work: Don't reinvent the wheel but use existing llist API
  sched: Don't reinvent the wheel but use existing llist API
  mm: Don't reinvent the wheel but use existing llist API

 drivers/md/bcache/closure.c | 17 +++--
 drivers/md/raid5.c  |  6 ++
 drivers/vhost/scsi.c| 11 +++
 fs/file_table.c | 12 +---
 fs/namespace.c  | 12 +---
 include/linux/llist.h   | 19 +++
 kernel/irq_work.c   |  6 +-
 kernel/sched/core.c | 13 ++---
 mm/vmalloc.c| 10 --
 9 files changed, 44 insertions(+), 62 deletions(-)

-- 
1.9.1

[PATCH v2 6/9] namespace.c: Don't reinvent the wheel but use existing llist API

[Byungchul Park]

Although llist provides proper APIs, they are not used. Make them used.

Signed-off-by: Byungchul Park 
---
 fs/namespace.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/fs/namespace.c b/fs/namespace.c
index b5b1259..5cb2229 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -1082,12 +1082,10 @@ static void __cleanup_mnt(struct rcu_head *head)
 static void delayed_mntput(struct work_struct *unused)
 {
struct llist_node *node = llist_del_all(_mntput_list);
-   struct llist_node *next;
+   struct mount *m, *t;
 
-   for (; node; node = next) {
-   next = llist_next(node);
-   cleanup_mnt(llist_entry(node, struct mount, mnt_llist));
-   }
+   llist_for_each_entry_safe(m, t, node, mnt_llist)
+   cleanup_mnt(m);
 }
 static DECLARE_DELAYED_WORK(delayed_mntput_work, delayed_mntput);
 
@@ -1615,7 +1613,7 @@ void __detach_mounts(struct dentry *dentry)
namespace_unlock();
 }
 
-/* 
+/*
  * Is the caller allowed to modify his namespace?
  */
 static inline bool may_mount(void)
@@ -2159,7 +2157,7 @@ static int do_loopback(struct path *path, const char 
*old_name,
 
err = -EINVAL;
if (mnt_ns_loop(old_path.dentry))
-   goto out; 
+   goto out;
 
mp = lock_mount(path);
err = PTR_ERR(mp);
-- 
1.9.1

[PATCH v2 0/9] Don't reinvent the wheel but use existing llist API

[Byungchul Park]

Change from v1
- split one patch to several ones, one for each subsystem.
- replace for_each with the safe version where it's necessary.

Byungchul Park (9):
  llist: Provide a safe version for llist_for_each
  bcache: Don't reinvent the wheel but use existing llist API
  raid5: Don't reinvent the wheel but use existing llist API
  vhost/scsi: Don't reinvent the wheel but use existing llist API
  fput: Don't reinvent the wheel but use existing llist API
  namespace.c: Don't reinvent the wheel but use existing llist API
  irq_work: Don't reinvent the wheel but use existing llist API
  sched: Don't reinvent the wheel but use existing llist API
  mm: Don't reinvent the wheel but use existing llist API

 drivers/md/bcache/closure.c | 17 +++--
 drivers/md/raid5.c  |  6 ++
 drivers/vhost/scsi.c| 11 +++
 fs/file_table.c | 12 +---
 fs/namespace.c  | 12 +---
 include/linux/llist.h   | 19 +++
 kernel/irq_work.c   |  6 +-
 kernel/sched/core.c | 13 ++---
 mm/vmalloc.c| 10 --
 9 files changed, 44 insertions(+), 62 deletions(-)

-- 
1.9.1

[PATCH v2 9/9] mm: Don't reinvent the wheel but use existing llist API

[Byungchul Park]

Although llist provides proper APIs, they are not used. Make them used.

Signed-off-by: Byungchul Park 
---
 mm/vmalloc.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 3ca82d4..8c0eb45 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -49,12 +49,10 @@ struct vfree_deferred {
 static void free_work(struct work_struct *w)
 {
struct vfree_deferred *p = container_of(w, struct vfree_deferred, wq);
-   struct llist_node *llnode = llist_del_all(>list);
-   while (llnode) {
-   void *p = llnode;
-   llnode = llist_next(llnode);
-   __vunmap(p, 1);
-   }
+   struct llist_node *t, *llnode;
+
+   llist_for_each_safe(llnode, t, llist_del_all(>list))
+   __vunmap((void *)llnode, 1);
 }
 
 /*** Page table manipulation functions ***/
-- 
1.9.1

[PATCH v2 7/9] irq_work: Don't reinvent the wheel but use existing llist API

[Byungchul Park]

Although llist provides proper APIs, they are not used. Make them used.

Signed-off-by: Byungchul Park 
---
 kernel/irq_work.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/kernel/irq_work.c b/kernel/irq_work.c
index bcf107c..e2ebe8c 100644
--- a/kernel/irq_work.c
+++ b/kernel/irq_work.c
@@ -138,11 +138,7 @@ static void irq_work_run_list(struct llist_head *list)
return;
 
llnode = llist_del_all(list);
-   while (llnode != NULL) {
-   work = llist_entry(llnode, struct irq_work, llnode);
-
-   llnode = llist_next(llnode);
-
+   llist_for_each_entry(work, llnode, llnode) {
/*
 * Clear the PENDING bit, after this point the @work
 * can be re-used.
-- 
1.9.1

[PATCH v2 9/9] mm: Don't reinvent the wheel but use existing llist API

[Byungchul Park]

Although llist provides proper APIs, they are not used. Make them used.

Signed-off-by: Byungchul Park 
---
 mm/vmalloc.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 3ca82d4..8c0eb45 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -49,12 +49,10 @@ struct vfree_deferred {
 static void free_work(struct work_struct *w)
 {
struct vfree_deferred *p = container_of(w, struct vfree_deferred, wq);
-   struct llist_node *llnode = llist_del_all(>list);
-   while (llnode) {
-   void *p = llnode;
-   llnode = llist_next(llnode);
-   __vunmap(p, 1);
-   }
+   struct llist_node *t, *llnode;
+
+   llist_for_each_safe(llnode, t, llist_del_all(>list))
+   __vunmap((void *)llnode, 1);
 }
 
 /*** Page table manipulation functions ***/
-- 
1.9.1

[PATCH v2 7/9] irq_work: Don't reinvent the wheel but use existing llist API

[Byungchul Park]

Although llist provides proper APIs, they are not used. Make them used.

Signed-off-by: Byungchul Park 
---
 kernel/irq_work.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/kernel/irq_work.c b/kernel/irq_work.c
index bcf107c..e2ebe8c 100644
--- a/kernel/irq_work.c
+++ b/kernel/irq_work.c
@@ -138,11 +138,7 @@ static void irq_work_run_list(struct llist_head *list)
return;
 
llnode = llist_del_all(list);
-   while (llnode != NULL) {
-   work = llist_entry(llnode, struct irq_work, llnode);
-
-   llnode = llist_next(llnode);
-
+   llist_for_each_entry(work, llnode, llnode) {
/*
 * Clear the PENDING bit, after this point the @work
 * can be re-used.
-- 
1.9.1

[PATCH v2 2/9] bcache: Don't reinvent the wheel but use existing llist API

[Byungchul Park]

Although llist provides proper APIs, they are not used. Make them used.

Signed-off-by: Byungchul Park 
---
 drivers/md/bcache/closure.c | 17 +++--
 1 file changed, 3 insertions(+), 14 deletions(-)

diff --git a/drivers/md/bcache/closure.c b/drivers/md/bcache/closure.c
index 864e673..1841d03 100644
--- a/drivers/md/bcache/closure.c
+++ b/drivers/md/bcache/closure.c
@@ -64,27 +64,16 @@ void closure_put(struct closure *cl)
 void __closure_wake_up(struct closure_waitlist *wait_list)
 {
struct llist_node *list;
-   struct closure *cl;
+   struct closure *cl, *t;
struct llist_node *reverse = NULL;
 
list = llist_del_all(_list->list);
 
/* We first reverse the list to preserve FIFO ordering and fairness */
-
-   while (list) {
-   struct llist_node *t = list;
-   list = llist_next(list);
-
-   t->next = reverse;
-   reverse = t;
-   }
+   reverse = llist_reverse_order(list);
 
/* Then do the wakeups */
-
-   while (reverse) {
-   cl = container_of(reverse, struct closure, list);
-   reverse = llist_next(reverse);
-
+   llist_for_each_entry_safe(cl, t, reverse, list) {
closure_set_waiting(cl, 0);
closure_sub(cl, CLOSURE_WAITING + 1);
}
-- 
1.9.1

[PATCH v2 2/9] bcache: Don't reinvent the wheel but use existing llist API

[Byungchul Park]

Although llist provides proper APIs, they are not used. Make them used.

Signed-off-by: Byungchul Park 
---
 drivers/md/bcache/closure.c | 17 +++--
 1 file changed, 3 insertions(+), 14 deletions(-)

diff --git a/drivers/md/bcache/closure.c b/drivers/md/bcache/closure.c
index 864e673..1841d03 100644
--- a/drivers/md/bcache/closure.c
+++ b/drivers/md/bcache/closure.c
@@ -64,27 +64,16 @@ void closure_put(struct closure *cl)
 void __closure_wake_up(struct closure_waitlist *wait_list)
 {
struct llist_node *list;
-   struct closure *cl;
+   struct closure *cl, *t;
struct llist_node *reverse = NULL;
 
list = llist_del_all(_list->list);
 
/* We first reverse the list to preserve FIFO ordering and fairness */
-
-   while (list) {
-   struct llist_node *t = list;
-   list = llist_next(list);
-
-   t->next = reverse;
-   reverse = t;
-   }
+   reverse = llist_reverse_order(list);
 
/* Then do the wakeups */
-
-   while (reverse) {
-   cl = container_of(reverse, struct closure, list);
-   reverse = llist_next(reverse);
-
+   llist_for_each_entry_safe(cl, t, reverse, list) {
closure_set_waiting(cl, 0);
closure_sub(cl, CLOSURE_WAITING + 1);
}
-- 
1.9.1

[PATCH v2 3/9] raid5: Don't reinvent the wheel but use existing llist API

[Byungchul Park]

Although llist provides proper APIs, they are not used. Make them used.

Signed-off-by: Byungchul Park 
---
 drivers/md/raid5.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
index 36c13e4..22a0326 100644
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -353,17 +353,15 @@ static void release_inactive_stripe_list(struct r5conf 
*conf,
 static int release_stripe_list(struct r5conf *conf,
   struct list_head *temp_inactive_list)
 {
-   struct stripe_head *sh;
+   struct stripe_head *sh, *t;
int count = 0;
struct llist_node *head;
 
head = llist_del_all(>released_stripes);
head = llist_reverse_order(head);
-   while (head) {
+   llist_for_each_entry_safe(sh, t, head, release_list) {
int hash;
 
-   sh = llist_entry(head, struct stripe_head, release_list);
-   head = llist_next(head);
/* sh could be readded after STRIPE_ON_RELEASE_LIST is cleard */
smp_mb();
clear_bit(STRIPE_ON_RELEASE_LIST, >state);
-- 
1.9.1

[PATCH v2 8/9] sched: Don't reinvent the wheel but use existing llist API

[Byungchul Park]

Although llist provides proper APIs, they are not used. Make them used.

Signed-off-by: Byungchul Park 
---
 kernel/sched/core.c | 13 ++---
 1 file changed, 2 insertions(+), 11 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index d01f9d0..417060b 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -1783,17 +1783,8 @@ void sched_ttwu_pending(void)
raw_spin_lock_irqsave(>lock, flags);
rq_pin_lock(rq, );
 
-   while (llist) {
-   int wake_flags = 0;
-
-   p = llist_entry(llist, struct task_struct, wake_entry);
-   llist = llist_next(llist);
-
-   if (p->sched_remote_wakeup)
-   wake_flags = WF_MIGRATED;
-
-   ttwu_do_activate(rq, p, wake_flags, );
-   }
+   llist_for_each_entry(p, llist, wake_entry)
+   ttwu_do_activate(rq, p, p->sched_remote_wakeup ? WF_MIGRATED : 
0, );
 
rq_unpin_lock(rq, );
raw_spin_unlock_irqrestore(>lock, flags);
-- 
1.9.1

[PATCH v2 5/9] fput: Don't reinvent the wheel but use existing llist API

[Byungchul Park]

Although llist provides proper APIs, they are not used. Make them used.

Signed-off-by: Byungchul Park 
---
 fs/file_table.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/fs/file_table.c b/fs/file_table.c
index 6d982b5..3209da2 100644
--- a/fs/file_table.c
+++ b/fs/file_table.c
@@ -231,12 +231,10 @@ static void __fput(struct file *file)
 static void delayed_fput(struct work_struct *unused)
 {
struct llist_node *node = llist_del_all(_fput_list);
-   struct llist_node *next;
+   struct file *f, *t;
 
-   for (; node; node = next) {
-   next = llist_next(node);
-   __fput(llist_entry(node, struct file, f_u.fu_llist));
-   }
+   llist_for_each_entry_safe(f, t, node, f_u.fu_llist)
+   __fput(f);
 }
 
 static void fput(struct callback_head *work)
@@ -310,7 +308,7 @@ void put_filp(struct file *file)
 }
 
 void __init files_init(void)
-{ 
+{
filp_cachep = kmem_cache_create("filp", sizeof(struct file), 0,
SLAB_HWCACHE_ALIGN | SLAB_PANIC, NULL);
percpu_counter_init(_files, 0, GFP_KERNEL);
@@ -329,4 +327,4 @@ void __init files_maxfiles_init(void)
n = ((totalram_pages - memreserve) * (PAGE_SIZE / 1024)) / 10;
 
files_stat.max_files = max_t(unsigned long, n, NR_FILE);
-} 
+}
-- 
1.9.1

[PATCH v2 8/9] sched: Don't reinvent the wheel but use existing llist API

[Byungchul Park]

Although llist provides proper APIs, they are not used. Make them used.

Signed-off-by: Byungchul Park 
---
 kernel/sched/core.c | 13 ++---
 1 file changed, 2 insertions(+), 11 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index d01f9d0..417060b 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -1783,17 +1783,8 @@ void sched_ttwu_pending(void)
raw_spin_lock_irqsave(>lock, flags);
rq_pin_lock(rq, );
 
-   while (llist) {
-   int wake_flags = 0;
-
-   p = llist_entry(llist, struct task_struct, wake_entry);
-   llist = llist_next(llist);
-
-   if (p->sched_remote_wakeup)
-   wake_flags = WF_MIGRATED;
-
-   ttwu_do_activate(rq, p, wake_flags, );
-   }
+   llist_for_each_entry(p, llist, wake_entry)
+   ttwu_do_activate(rq, p, p->sched_remote_wakeup ? WF_MIGRATED : 
0, );
 
rq_unpin_lock(rq, );
raw_spin_unlock_irqrestore(>lock, flags);
-- 
1.9.1

[PATCH v2 5/9] fput: Don't reinvent the wheel but use existing llist API

[Byungchul Park]

Although llist provides proper APIs, they are not used. Make them used.

Signed-off-by: Byungchul Park 
---
 fs/file_table.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/fs/file_table.c b/fs/file_table.c
index 6d982b5..3209da2 100644
--- a/fs/file_table.c
+++ b/fs/file_table.c
@@ -231,12 +231,10 @@ static void __fput(struct file *file)
 static void delayed_fput(struct work_struct *unused)
 {
struct llist_node *node = llist_del_all(_fput_list);
-   struct llist_node *next;
+   struct file *f, *t;
 
-   for (; node; node = next) {
-   next = llist_next(node);
-   __fput(llist_entry(node, struct file, f_u.fu_llist));
-   }
+   llist_for_each_entry_safe(f, t, node, f_u.fu_llist)
+   __fput(f);
 }
 
 static void fput(struct callback_head *work)
@@ -310,7 +308,7 @@ void put_filp(struct file *file)
 }
 
 void __init files_init(void)
-{ 
+{
filp_cachep = kmem_cache_create("filp", sizeof(struct file), 0,
SLAB_HWCACHE_ALIGN | SLAB_PANIC, NULL);
percpu_counter_init(_files, 0, GFP_KERNEL);
@@ -329,4 +327,4 @@ void __init files_maxfiles_init(void)
n = ((totalram_pages - memreserve) * (PAGE_SIZE / 1024)) / 10;
 
files_stat.max_files = max_t(unsigned long, n, NR_FILE);
-} 
+}
-- 
1.9.1

[PATCH v2 3/9] raid5: Don't reinvent the wheel but use existing llist API

[Byungchul Park]

Although llist provides proper APIs, they are not used. Make them used.

Signed-off-by: Byungchul Park 
---
 drivers/md/raid5.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
index 36c13e4..22a0326 100644
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -353,17 +353,15 @@ static void release_inactive_stripe_list(struct r5conf 
*conf,
 static int release_stripe_list(struct r5conf *conf,
   struct list_head *temp_inactive_list)
 {
-   struct stripe_head *sh;
+   struct stripe_head *sh, *t;
int count = 0;
struct llist_node *head;
 
head = llist_del_all(>released_stripes);
head = llist_reverse_order(head);
-   while (head) {
+   llist_for_each_entry_safe(sh, t, head, release_list) {
int hash;
 
-   sh = llist_entry(head, struct stripe_head, release_list);
-   head = llist_next(head);
/* sh could be readded after STRIPE_ON_RELEASE_LIST is cleard */
smp_mb();
clear_bit(STRIPE_ON_RELEASE_LIST, >state);
-- 
1.9.1

[PATCH v2 4/9] vhost/scsi: Don't reinvent the wheel but use existing llist API

[Byungchul Park]

Although llist provides proper APIs, they are not used. Make them used.

Signed-off-by: Byungchul Park 
---
 drivers/vhost/scsi.c | 11 +++
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c
index 253310c..a4cb966 100644
--- a/drivers/vhost/scsi.c
+++ b/drivers/vhost/scsi.c
@@ -496,14 +496,12 @@ static void vhost_scsi_evt_work(struct vhost_work *work)
struct vhost_scsi *vs = container_of(work, struct vhost_scsi,
vs_event_work);
struct vhost_virtqueue *vq = >vqs[VHOST_SCSI_VQ_EVT].vq;
-   struct vhost_scsi_evt *evt;
+   struct vhost_scsi_evt *evt, *t;
struct llist_node *llnode;
 
mutex_lock(>mutex);
llnode = llist_del_all(>vs_event_list);
-   while (llnode) {
-   evt = llist_entry(llnode, struct vhost_scsi_evt, list);
-   llnode = llist_next(llnode);
+   llist_for_each_entry_safe(evt, t, llnode, list) {
vhost_scsi_do_evt_work(vs, evt);
vhost_scsi_free_evt(vs, evt);
}
@@ -529,10 +527,7 @@ static void vhost_scsi_complete_cmd_work(struct vhost_work 
*work)
 
bitmap_zero(signal, VHOST_SCSI_MAX_VQ);
llnode = llist_del_all(>vs_completion_list);
-   while (llnode) {
-   cmd = llist_entry(llnode, struct vhost_scsi_cmd,
-tvc_completion_list);
-   llnode = llist_next(llnode);
+   llist_for_each_entry(cmd, llnode, tvc_completion_list) {
se_cmd = >tvc_se_cmd;
 
pr_debug("%s tv_cmd %p resid %u status %#02x\n", __func__,
-- 
1.9.1

[PATCH v2 4/9] vhost/scsi: Don't reinvent the wheel but use existing llist API

[Byungchul Park]

Although llist provides proper APIs, they are not used. Make them used.

Signed-off-by: Byungchul Park 
---
 drivers/vhost/scsi.c | 11 +++
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c
index 253310c..a4cb966 100644
--- a/drivers/vhost/scsi.c
+++ b/drivers/vhost/scsi.c
@@ -496,14 +496,12 @@ static void vhost_scsi_evt_work(struct vhost_work *work)
struct vhost_scsi *vs = container_of(work, struct vhost_scsi,
vs_event_work);
struct vhost_virtqueue *vq = >vqs[VHOST_SCSI_VQ_EVT].vq;
-   struct vhost_scsi_evt *evt;
+   struct vhost_scsi_evt *evt, *t;
struct llist_node *llnode;
 
mutex_lock(>mutex);
llnode = llist_del_all(>vs_event_list);
-   while (llnode) {
-   evt = llist_entry(llnode, struct vhost_scsi_evt, list);
-   llnode = llist_next(llnode);
+   llist_for_each_entry_safe(evt, t, llnode, list) {
vhost_scsi_do_evt_work(vs, evt);
vhost_scsi_free_evt(vs, evt);
}
@@ -529,10 +527,7 @@ static void vhost_scsi_complete_cmd_work(struct vhost_work 
*work)
 
bitmap_zero(signal, VHOST_SCSI_MAX_VQ);
llnode = llist_del_all(>vs_completion_list);
-   while (llnode) {
-   cmd = llist_entry(llnode, struct vhost_scsi_cmd,
-tvc_completion_list);
-   llnode = llist_next(llnode);
+   llist_for_each_entry(cmd, llnode, tvc_completion_list) {
se_cmd = >tvc_se_cmd;
 
pr_debug("%s tv_cmd %p resid %u status %#02x\n", __func__,
-- 
1.9.1

[PATCH v3 2/2] mtd: nand: Update dependency of IFC for LS1021A

[Alison Wang]

As NAND support for Freescale/NXP IFC controller is available on
LS1021A, the dependency for LS1021A is added.

LS1021A is an earlier product and is not compatible with later
LayerScape architecture. So ARCH_LAYERSCAPE can't cover LS1021A.

Signed-off-by: Alison Wang 
---
Changes in v3:
- Update the commit message.

Changes in v2:
- None

 drivers/mtd/nand/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 353a9dd..85e3860 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -441,7 +441,7 @@ config MTD_NAND_FSL_ELBC
 
 config MTD_NAND_FSL_IFC
tristate "NAND support for Freescale IFC controller"
-   depends on FSL_SOC || ARCH_LAYERSCAPE
+   depends on FSL_SOC || ARCH_LAYERSCAPE || SOC_LS1021A
select FSL_IFC
select MEMORY
help
-- 
2.1.0.27.g96db324

[PATCH v3 2/2] mtd: nand: Update dependency of IFC for LS1021A

[Alison Wang]

As NAND support for Freescale/NXP IFC controller is available on
LS1021A, the dependency for LS1021A is added.

LS1021A is an earlier product and is not compatible with later
LayerScape architecture. So ARCH_LAYERSCAPE can't cover LS1021A.

Signed-off-by: Alison Wang 
---
Changes in v3:
- Update the commit message.

Changes in v2:
- None

 drivers/mtd/nand/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 353a9dd..85e3860 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -441,7 +441,7 @@ config MTD_NAND_FSL_ELBC
 
 config MTD_NAND_FSL_IFC
tristate "NAND support for Freescale IFC controller"
-   depends on FSL_SOC || ARCH_LAYERSCAPE
+   depends on FSL_SOC || ARCH_LAYERSCAPE || SOC_LS1021A
select FSL_IFC
select MEMORY
help
-- 
2.1.0.27.g96db324

RE: [PATCH v2 2/2] mtd: nand: Update dependency of IFC for LS1021A

[Alison Wang]

Hi, Boris,

> On Thu, 5 Jan 2017 02:02:30 +
> Alison Wang  wrote:
> 
> > > On 01/04/2017 02:46 AM, Alison Wang wrote:
> > > >> On 01/03/2017 03:41 AM, Alison Wang wrote:
> > > >>> As NAND support for Freescale/NXP IFC controller is available
> on
> > > >>> LS1021A, the dependency for LS1021A is added.
> > > >>
> > > >> Does LS stand for LayerScape ? Yes it does. So why does
> > > >> ARCH_LAYERSCAPE not cover LS1021 ?
> > > > [Alison Wang] LS1021A is an earlier product and is not compatible
> > > with later Layerscape architecture. So ARCH_LAYERSCAPE can't cover
> > > LS1021A.
> > >
> > > Ah ok, I see. That information would be useful in the commit
> message
> > > ;-)
> > >
> > [Alison Wang] Ok. :)
> 
> Would you mind sending a v3 with the updated commit message?
> 
[Alison Wang] I will send the v3 patches at once. :)


Best Regards,
Alison Wang

RE: [PATCH v2 2/2] mtd: nand: Update dependency of IFC for LS1021A

[Alison Wang]

Hi, Boris,

> On Thu, 5 Jan 2017 02:02:30 +
> Alison Wang  wrote:
> 
> > > On 01/04/2017 02:46 AM, Alison Wang wrote:
> > > >> On 01/03/2017 03:41 AM, Alison Wang wrote:
> > > >>> As NAND support for Freescale/NXP IFC controller is available
> on
> > > >>> LS1021A, the dependency for LS1021A is added.
> > > >>
> > > >> Does LS stand for LayerScape ? Yes it does. So why does
> > > >> ARCH_LAYERSCAPE not cover LS1021 ?
> > > > [Alison Wang] LS1021A is an earlier product and is not compatible
> > > with later Layerscape architecture. So ARCH_LAYERSCAPE can't cover
> > > LS1021A.
> > >
> > > Ah ok, I see. That information would be useful in the commit
> message
> > > ;-)
> > >
> > [Alison Wang] Ok. :)
> 
> Would you mind sending a v3 with the updated commit message?
> 
[Alison Wang] I will send the v3 patches at once. :)


Best Regards,
Alison Wang

[PATCH v3 1/2] mtd: ifc: Update dependency of IFC for LS1021A

[Alison Wang]

As Freescale/NXP IFC controller is available on LS1021A, the dependency
for LS1021A is added.

LS1021A is an earlier product and is not compatible with later
LayerScape architecture. So ARCH_LAYERSCAPE can't cover LS1021A.

Signed-off-by: Alison Wang 
---
Changes in v3:
- Update the commit message.

Changes in v2:
- New patch

 drivers/memory/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig
index ec80e35..fff8345 100644
--- a/drivers/memory/Kconfig
+++ b/drivers/memory/Kconfig
@@ -115,7 +115,7 @@ config FSL_CORENET_CF
 
 config FSL_IFC
bool
-   depends on FSL_SOC || ARCH_LAYERSCAPE
+   depends on FSL_SOC || ARCH_LAYERSCAPE || SOC_LS1021A
 
 config JZ4780_NEMC
bool "Ingenic JZ4780 SoC NEMC driver"
-- 
2.1.0.27.g96db324

[PATCH v3 1/2] mtd: ifc: Update dependency of IFC for LS1021A

[Alison Wang]

As Freescale/NXP IFC controller is available on LS1021A, the dependency
for LS1021A is added.

LS1021A is an earlier product and is not compatible with later
LayerScape architecture. So ARCH_LAYERSCAPE can't cover LS1021A.

Signed-off-by: Alison Wang 
---
Changes in v3:
- Update the commit message.

Changes in v2:
- New patch

 drivers/memory/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig
index ec80e35..fff8345 100644
--- a/drivers/memory/Kconfig
+++ b/drivers/memory/Kconfig
@@ -115,7 +115,7 @@ config FSL_CORENET_CF
 
 config FSL_IFC
bool
-   depends on FSL_SOC || ARCH_LAYERSCAPE
+   depends on FSL_SOC || ARCH_LAYERSCAPE || SOC_LS1021A
 
 config JZ4780_NEMC
bool "Ingenic JZ4780 SoC NEMC driver"
-- 
2.1.0.27.g96db324

Re: [PATCH 0/3] s390: audit and remove needless module.h includes

[Heiko Carstens]

On Thu, Feb 09, 2017 at 03:20:22PM -0500, Paul Gortmaker wrote:
> Paul Gortmaker (3):
>   s390: kernel: Audit and remove any unnecessary uses of module.h
>   s390: mm: Audit and remove any unnecessary uses of module.h
>   s390: Audit and remove any remaining unnecessary uses of module.h

Applied, thanks!

Re: [PATCH 0/3] s390: audit and remove needless module.h includes

[Heiko Carstens]

On Thu, Feb 09, 2017 at 03:20:22PM -0500, Paul Gortmaker wrote:
> Paul Gortmaker (3):
>   s390: kernel: Audit and remove any unnecessary uses of module.h
>   s390: mm: Audit and remove any unnecessary uses of module.h
>   s390: Audit and remove any remaining unnecessary uses of module.h

Applied, thanks!

Re: [PATCH] perf: Fix CONFIG_KPROBE_EVENTS and CONFIG_UPROBE_EVENTS typos

[Ingo Molnar]

* Anton Blanchard  wrote:

> From: Anton Blanchard 
> 
> Fix some incorrect Kconfig options, they should be CONFIG_KPROBE_EVENT
> and CONFIG_UPROBE_EVENT.
> 
> Signed-off-by: Anton Blanchard 
> ---
>  arch/sparc/configs/sparc64_defconfig | 2 +-
>  tools/perf/util/probe-file.c | 8 
>  2 files changed, 5 insertions(+), 5 deletions(-)

So the names should be fixed, it should be CONFIG_UPROBE_EVENTS and 
CONFIG_KPROBE_EVENTS throughout the code. It's CONFIG_PERF_EVENTS and 
CONFIG_PROBE_EVENTS after all and lives in kernel/events/ - all plural.

I didn't notice the misnomer when merging these bits.

Thanks,

Ingo

Re: [PATCH] perf: Fix CONFIG_KPROBE_EVENTS and CONFIG_UPROBE_EVENTS typos

[Ingo Molnar]

* Anton Blanchard  wrote:

> From: Anton Blanchard 
> 
> Fix some incorrect Kconfig options, they should be CONFIG_KPROBE_EVENT
> and CONFIG_UPROBE_EVENT.
> 
> Signed-off-by: Anton Blanchard 
> ---
>  arch/sparc/configs/sparc64_defconfig | 2 +-
>  tools/perf/util/probe-file.c | 8 
>  2 files changed, 5 insertions(+), 5 deletions(-)

So the names should be fixed, it should be CONFIG_UPROBE_EVENTS and 
CONFIG_KPROBE_EVENTS throughout the code. It's CONFIG_PERF_EVENTS and 
CONFIG_PROBE_EVENTS after all and lives in kernel/events/ - all plural.

I didn't notice the misnomer when merging these bits.

Thanks,

Ingo

Re: linux-next: build failure after merge of the rcu tree

[Stephen Rothwell]

Hi Paul,

On Sun, 12 Feb 2017 20:37:48 -0800 "Paul E. McKenney" 
 wrote:
>
> I chickened out on that commit for this merge window, so it will come
> back at -rc1.  But I will cover that when I rebase to -rc1.

OK, thanks.

-- 
Cheers,
Stephen Rothwell

Re: linux-next: build failure after merge of the rcu tree

[Stephen Rothwell]

Hi Paul,

On Sun, 12 Feb 2017 20:37:48 -0800 "Paul E. McKenney" 
 wrote:
>
> I chickened out on that commit for this merge window, so it will come
> back at -rc1.  But I will cover that when I rebase to -rc1.

OK, thanks.

-- 
Cheers,
Stephen Rothwell

Re: [PATCH] Make EN2 pin optional in the TRF7970A driver

[Heiko Schocher]

Hello Rob,

Am 10.02.2017 um 16:51 schrieb Rob Herring:

On Tue, Feb 07, 2017 at 06:22:04AM +0100, Heiko Schocher wrote:

From: Guan Ben 

Make the EN2 pin optional. This is useful for boards,
which have this pin fix wired, for example to ground.

Signed-off-by: Guan Ben 
Signed-off-by: Mark Jonas 
Signed-off-by: Heiko Schocher 

---

  .../devicetree/bindings/net/nfc/trf7970a.txt   |  4 ++--
  drivers/nfc/trf7970a.c | 26 --
  2 files changed, 16 insertions(+), 14 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt 
b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
index 32b35a0..5889a3d 100644
--- a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
+++ b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
@@ -5,8 +5,8 @@ Required properties:
  - spi-max-frequency: Maximum SPI frequency (<= 200).
  - interrupt-parent: phandle of parent interrupt handler.
  - interrupts: A single interrupt specifier.
-- ti,enable-gpios: Two GPIO entries used for 'EN' and 'EN2' pins on the
-  TRF7970A.
+- ti,enable-gpios: One or two GPIO entries used for 'EN' and 'EN2' pins on the
+  TRF7970A. EN2 is optional.


Could EN ever be optional/fixed? If so, perhaps deprecate this property
and do 2 properties, one for each pin.


The hardware I have has the EN2 pin fix connected to ground. Looking
into http://www.ti.com/lit/ds/slos743k/slos743k.pdf page 19 table 6-3
and 6-4 the EN2 pin is a don;t core if EN = 1. If EN = 0 EN2 pin
selects between Power Down and Sleep Mode ... I see no reason why
this is not possible/allowed ...

Hmm.. I do not like the idea of deprecating the "ti,enable-gpios"
property into 2 seperate properties ... but if this would be a reason
for not accepting this patch, I can do this ... How should I name
the 2 new properties?

"ti,pin-enable"  and "ti,pin-enable2" ?

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

Re: [PATCH] Make EN2 pin optional in the TRF7970A driver

[Heiko Schocher]

Hello Rob,

Am 10.02.2017 um 16:51 schrieb Rob Herring:

On Tue, Feb 07, 2017 at 06:22:04AM +0100, Heiko Schocher wrote:

From: Guan Ben 

Make the EN2 pin optional. This is useful for boards,
which have this pin fix wired, for example to ground.

Signed-off-by: Guan Ben 
Signed-off-by: Mark Jonas 
Signed-off-by: Heiko Schocher 

---

  .../devicetree/bindings/net/nfc/trf7970a.txt   |  4 ++--
  drivers/nfc/trf7970a.c | 26 --
  2 files changed, 16 insertions(+), 14 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt 
b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
index 32b35a0..5889a3d 100644
--- a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
+++ b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
@@ -5,8 +5,8 @@ Required properties:
  - spi-max-frequency: Maximum SPI frequency (<= 200).
  - interrupt-parent: phandle of parent interrupt handler.
  - interrupts: A single interrupt specifier.
-- ti,enable-gpios: Two GPIO entries used for 'EN' and 'EN2' pins on the
-  TRF7970A.
+- ti,enable-gpios: One or two GPIO entries used for 'EN' and 'EN2' pins on the
+  TRF7970A. EN2 is optional.


Could EN ever be optional/fixed? If so, perhaps deprecate this property
and do 2 properties, one for each pin.


The hardware I have has the EN2 pin fix connected to ground. Looking
into http://www.ti.com/lit/ds/slos743k/slos743k.pdf page 19 table 6-3
and 6-4 the EN2 pin is a don;t core if EN = 1. If EN = 0 EN2 pin
selects between Power Down and Sleep Mode ... I see no reason why
this is not possible/allowed ...

Hmm.. I do not like the idea of deprecating the "ti,enable-gpios"
property into 2 seperate properties ... but if this would be a reason
for not accepting this patch, I can do this ... How should I name
the 2 new properties?

"ti,pin-enable"  and "ti,pin-enable2" ?

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

linux-next: Tree for Feb 13

[Stephen Rothwell]

Hi all,

Changes since 20170210:

The ipsec-next tree gained a conflict against the net-next tree.

The rdma-leon gained a conflict against Linus' tree.

The l2mtd-tree lost its build failure.

Non-merge commits (relative to Linus' tree): 8646
 9682 files changed, 388711 insertions(+), 182504 deletions(-)



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

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

Below is a summary of the state of the merge.

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

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

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

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

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (1ce42845f987 Merge branch 'x86-urgent-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip)
Merging fixes/master (30066ce675d3 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging kbuild-current/rc-fixes (c7858bf16c0b asm-prototypes: Clear any CPP 
defines before declaring the functions)
Merging arc-current/for-curr (8ba605b607b7 ARC: [plat-*] ARC_HAS_COH_CACHES no 
longer relevant)
Merging arm-current/fixes (228dbbfb5d77 ARM: 8643/3: arm/ptrace: Preserve 
previous registers for short regset write)
Merging m68k-current/for-linus (ad595b77c4a8 m68k/atari: Use seq_puts() in 
atari_get_hardware_list())
Merging metag-fixes/fixes (35d04077ad96 metag: Only define 
atomic_dec_if_positive conditionally)
Merging powerpc-fixes/fixes (f83e6862047e powerpc/powernv: Properly set 
"host-ipi" on IPIs)
Merging sparc/master (f9a42e0d58cf Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc)
Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and 
linking special files)
Merging net/master (e722af639194 ibmvnic: Call napi_disable instead of 
napi_enable in failure path)
Merging ipsec/master (c28a45cb xfrm: policy: init locks early)
Merging netfilter/master (f95d7a46bc57 netfilter: ctnetlink: Fix regression in 
CTA_HELP processing)
Merging ipvs/master (045169816b31 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging wireless-drivers/master (52f5631a4c05 rtlwifi: rtl8192ce: Fix loading 
of incorrect firmware)
Merging mac80211/master (fd551bac4795 nl80211: Fix mesh HT operation check)
Merging sound-current/for-linus (af677166cf63 ALSA: hda - adding a new NV 
HDMI/DP codec ID in the driver)
Merging pci-current/for-linus (d98e0929071e Revert "PCI: pciehp: Add runtime PM 
support for PCIe hotplug ports")
Merging driver-core.current/driver-core-linus (49def1853334 Linux 4.10-rc4)
Merging tty.current/tty-linus (49def1853334 Linux 4.10-rc4)
Merging usb.current/usb-linus (d5adbfcd5f7b Linux 4.10-rc7)
Merging usb-gadget-fixes/fixes (efe357f4633a usb: dwc2: host: fix 
Wmaybe-uninitialized warning)
Merging usb-serial-fixes/usb-linus (d07830db1bdb USB: serial: pl2303: add ATEN 
device ID)
Merging usb-chipidea-fixes/ci-for-usb-stable (c7fbb09b2ea1 usb: chipidea: move 
the lock initialization to core file)
Merging phy/fixes (7ce7d89f4883 Linux 4.10-rc1)
Merging staging.current/staging-linus (d5adbfcd5f7b Linux 4.10-rc7)
Merging char-misc.current/char-misc-linus (d5adbfcd5f7b Linux 4.10-rc7)
Merging input-current/for-linus (413d37326700 Input: synaptics-rmi4 - select 
'SERIO' when needed)
Merging crypto-current/master (7c2cf1c4615c crypto: chcr - Fix key length for 
RFC4106)
Merging ide/master (da095587e6be Revert "ide: Fix interface autodetection in 
legacy IDE driver (trial #2)")
Merging vfio-fixes/for-linus (930a42ded3fe vfio/spapr_tce: Set window when 
adding 

linux-next: Tree for Feb 13

[Stephen Rothwell]

Hi all,

Changes since 20170210:

The ipsec-next tree gained a conflict against the net-next tree.

The rdma-leon gained a conflict against Linus' tree.

The l2mtd-tree lost its build failure.

Non-merge commits (relative to Linus' tree): 8646
 9682 files changed, 388711 insertions(+), 182504 deletions(-)



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

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

Below is a summary of the state of the merge.

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

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

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

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

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (1ce42845f987 Merge branch 'x86-urgent-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip)
Merging fixes/master (30066ce675d3 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging kbuild-current/rc-fixes (c7858bf16c0b asm-prototypes: Clear any CPP 
defines before declaring the functions)
Merging arc-current/for-curr (8ba605b607b7 ARC: [plat-*] ARC_HAS_COH_CACHES no 
longer relevant)
Merging arm-current/fixes (228dbbfb5d77 ARM: 8643/3: arm/ptrace: Preserve 
previous registers for short regset write)
Merging m68k-current/for-linus (ad595b77c4a8 m68k/atari: Use seq_puts() in 
atari_get_hardware_list())
Merging metag-fixes/fixes (35d04077ad96 metag: Only define 
atomic_dec_if_positive conditionally)
Merging powerpc-fixes/fixes (f83e6862047e powerpc/powernv: Properly set 
"host-ipi" on IPIs)
Merging sparc/master (f9a42e0d58cf Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc)
Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and 
linking special files)
Merging net/master (e722af639194 ibmvnic: Call napi_disable instead of 
napi_enable in failure path)
Merging ipsec/master (c28a45cb xfrm: policy: init locks early)
Merging netfilter/master (f95d7a46bc57 netfilter: ctnetlink: Fix regression in 
CTA_HELP processing)
Merging ipvs/master (045169816b31 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging wireless-drivers/master (52f5631a4c05 rtlwifi: rtl8192ce: Fix loading 
of incorrect firmware)
Merging mac80211/master (fd551bac4795 nl80211: Fix mesh HT operation check)
Merging sound-current/for-linus (af677166cf63 ALSA: hda - adding a new NV 
HDMI/DP codec ID in the driver)
Merging pci-current/for-linus (d98e0929071e Revert "PCI: pciehp: Add runtime PM 
support for PCIe hotplug ports")
Merging driver-core.current/driver-core-linus (49def1853334 Linux 4.10-rc4)
Merging tty.current/tty-linus (49def1853334 Linux 4.10-rc4)
Merging usb.current/usb-linus (d5adbfcd5f7b Linux 4.10-rc7)
Merging usb-gadget-fixes/fixes (efe357f4633a usb: dwc2: host: fix 
Wmaybe-uninitialized warning)
Merging usb-serial-fixes/usb-linus (d07830db1bdb USB: serial: pl2303: add ATEN 
device ID)
Merging usb-chipidea-fixes/ci-for-usb-stable (c7fbb09b2ea1 usb: chipidea: move 
the lock initialization to core file)
Merging phy/fixes (7ce7d89f4883 Linux 4.10-rc1)
Merging staging.current/staging-linus (d5adbfcd5f7b Linux 4.10-rc7)
Merging char-misc.current/char-misc-linus (d5adbfcd5f7b Linux 4.10-rc7)
Merging input-current/for-linus (413d37326700 Input: synaptics-rmi4 - select 
'SERIO' when needed)
Merging crypto-current/master (7c2cf1c4615c crypto: chcr - Fix key length for 
RFC4106)
Merging ide/master (da095587e6be Revert "ide: Fix interface autodetection in 
legacy IDE driver (trial #2)")
Merging vfio-fixes/for-linus (930a42ded3fe vfio/spapr_tce: Set window when 
adding 

Re: [PATCH 1/1] dma: imx-sdma: add 1ms delay to ensure SDMA channel is stopped

[Jiada Wang]

Hello Vinod

On 02/13/2017 11:05 AM, Vinod Koul wrote:

On Fri, Feb 10, 2017 at 06:46:45AM -0800, jiada_w...@mentor.com wrote:

From: Jiada Wang 

sdma_disable_channel() cannot ensure dma is stopped to access
module's FIFOs. Maybe SDMA core is running and accessing BD when
disable of corresponding channel, this may cause sometimes even
after call of .sdma_disable_channel(), SDMA core still be running
and accessing module's FIFOs.

We should add delay of one BD SDMA cost time, the maximum is 1ms.
So that SDMA clients by calling .device_terminate_all can
ensure SDMA core has really been stopped.

Signed-off-by: Jiada Wang 
---
 drivers/dma/imx-sdma.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index d1651a5..7332c40 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -937,6 +937,14 @@ static int sdma_disable_channel(struct dma_chan *chan)
return 0;
 }

+static int sdma_disable_channel_with_delay(struct dma_chan *chan)
+{
+   sdma_disable_channel(chan);
+   mdelay(1);


what is the gaurantee that 1ms is fine? Shouldn't you poll the bit to see
channel is disabled properly..


I got the information from NXP (freescale) R team,
according to them, by write '1' to SDMA_H_STATSTOP, only disables
the related sdma channel (so poll HE bit will indicates the channel has 
been disabled),

but it cannot ensure SDMA core stop to access modules' FIFO,
SDMA core may still is running, this is a bug in HW.

regarding if the '1ms' is enough to ensure SDMA core has stopped,
NXP R team mentioned:
"we should add some delay of one BD SDMA cost time after disable the 
channel bit, the maximum is 1ms"

so I assume 1ms should work for all cases

Thanks,
Jiada

+
+   return 0;
+}
+
 static void sdma_set_watermarklevel_for_p2p(struct sdma_channel *sdmac)
 {
struct sdma_engine *sdma = sdmac->sdma;
@@ -1828,7 +1836,7 @@ static int sdma_probe(struct platform_device *pdev)
sdma->dma_device.device_prep_slave_sg = sdma_prep_slave_sg;
sdma->dma_device.device_prep_dma_cyclic = sdma_prep_dma_cyclic;
sdma->dma_device.device_config = sdma_config;
-   sdma->dma_device.device_terminate_all = sdma_disable_channel;
+   sdma->dma_device.device_terminate_all = sdma_disable_channel_with_delay;
sdma->dma_device.src_addr_widths = BIT(DMA_SLAVE_BUSWIDTH_4_BYTES);
sdma->dma_device.dst_addr_widths = BIT(DMA_SLAVE_BUSWIDTH_4_BYTES);
sdma->dma_device.directions = BIT(DMA_DEV_TO_MEM) | BIT(DMA_MEM_TO_DEV);
--
2.7.4

Re: [PATCH 1/1] dma: imx-sdma: add 1ms delay to ensure SDMA channel is stopped

[Jiada Wang]

Hello Vinod

On 02/13/2017 11:05 AM, Vinod Koul wrote:

On Fri, Feb 10, 2017 at 06:46:45AM -0800, jiada_w...@mentor.com wrote:

From: Jiada Wang 

sdma_disable_channel() cannot ensure dma is stopped to access
module's FIFOs. Maybe SDMA core is running and accessing BD when
disable of corresponding channel, this may cause sometimes even
after call of .sdma_disable_channel(), SDMA core still be running
and accessing module's FIFOs.

We should add delay of one BD SDMA cost time, the maximum is 1ms.
So that SDMA clients by calling .device_terminate_all can
ensure SDMA core has really been stopped.

Signed-off-by: Jiada Wang 
---
 drivers/dma/imx-sdma.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index d1651a5..7332c40 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -937,6 +937,14 @@ static int sdma_disable_channel(struct dma_chan *chan)
return 0;
 }

+static int sdma_disable_channel_with_delay(struct dma_chan *chan)
+{
+   sdma_disable_channel(chan);
+   mdelay(1);


what is the gaurantee that 1ms is fine? Shouldn't you poll the bit to see
channel is disabled properly..


I got the information from NXP (freescale) R team,
according to them, by write '1' to SDMA_H_STATSTOP, only disables
the related sdma channel (so poll HE bit will indicates the channel has 
been disabled),

but it cannot ensure SDMA core stop to access modules' FIFO,
SDMA core may still is running, this is a bug in HW.

regarding if the '1ms' is enough to ensure SDMA core has stopped,
NXP R team mentioned:
"we should add some delay of one BD SDMA cost time after disable the 
channel bit, the maximum is 1ms"

so I assume 1ms should work for all cases

Thanks,
Jiada

+
+   return 0;
+}
+
 static void sdma_set_watermarklevel_for_p2p(struct sdma_channel *sdmac)
 {
struct sdma_engine *sdma = sdmac->sdma;
@@ -1828,7 +1836,7 @@ static int sdma_probe(struct platform_device *pdev)
sdma->dma_device.device_prep_slave_sg = sdma_prep_slave_sg;
sdma->dma_device.device_prep_dma_cyclic = sdma_prep_dma_cyclic;
sdma->dma_device.device_config = sdma_config;
-   sdma->dma_device.device_terminate_all = sdma_disable_channel;
+   sdma->dma_device.device_terminate_all = sdma_disable_channel_with_delay;
sdma->dma_device.src_addr_widths = BIT(DMA_SLAVE_BUSWIDTH_4_BYTES);
sdma->dma_device.dst_addr_widths = BIT(DMA_SLAVE_BUSWIDTH_4_BYTES);
sdma->dma_device.directions = BIT(DMA_DEV_TO_MEM) | BIT(DMA_MEM_TO_DEV);
--
2.7.4

Re: [PATCH] Input: tsc2004/5 - do not use irq_set_irq_wake() directly

[Sebastian Reichel]

Hi,

On Sun, Feb 12, 2017 at 03:43:33PM -0800, Dmitry Torokhov wrote:
> Instead of setting irq_set_irq_wake() directly in probe(), mark the device
> as wakeup-capable, and use enable_irq_wake() and disable_irq_wake() in
> suspend/resume path.
> 
> Signed-off-by: Dmitry Torokhov 

Reviewed-By: Sebastian Reichel 

I suggest to add a paragraph in the patch description, why the
change was done. E.g.:

This adds support for changing the wakeup setting dynamically at
runtime using /sys/devices/.../tsc2005/power/wakeup.

Also I wonder if the default should be 'off' (by using
device_set_wakeup_capable() instead of device_init_wakeup()

-- Sebastian

>  drivers/input/touchscreen/tsc200x-core.c | 13 -
>  1 file changed, 12 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/input/touchscreen/tsc200x-core.c 
> b/drivers/input/touchscreen/tsc200x-core.c
> index 88ea5e1b72ae..d1c40c803d61 100644
> --- a/drivers/input/touchscreen/tsc200x-core.c
> +++ b/drivers/input/touchscreen/tsc200x-core.c
> @@ -114,7 +114,9 @@ struct tsc200x {
>  
>   struct gpio_desc*reset_gpio;
>   int (*tsc200x_cmd)(struct device *dev, u8 cmd);
> +
>   int irq;
> + boolwake_irq_enabled;
>  };
>  
>  static void tsc200x_update_pen_state(struct tsc200x *ts,
> @@ -573,7 +575,8 @@ int tsc200x_probe(struct device *dev, int irq, const 
> struct input_id *tsc_id,
>   goto err_remove_sysfs;
>   }
>  
> - irq_set_irq_wake(irq, 1);
> + device_init_wakeup(dev, true);
> +
>   return 0;
>  
>  err_remove_sysfs:
> @@ -607,6 +610,9 @@ static int __maybe_unused tsc200x_suspend(struct device 
> *dev)
>  
>   ts->suspended = true;
>  
> + if (device_may_wakeup(dev))
> + ts->wake_irq_enabled = enable_irq_wake(ts->irq) == 0;
> +
>   mutex_unlock(>mutex);
>  
>   return 0;
> @@ -618,6 +624,11 @@ static int __maybe_unused tsc200x_resume(struct device 
> *dev)
>  
>   mutex_lock(>mutex);
>  
> + if (ts->wake_irq_enabled) {
> + disable_irq_wake(ts->irq);
> + ts->wake_irq_enabled = false;
> + }
> +
>   if (ts->suspended && ts->opened)
>   __tsc200x_enable(ts);
>  
> -- 
> 2.11.0.483.g087da7b7c-goog
> 
> 
> -- 
> Dmitry


signature.asc
Description: PGP signature

Re: [PATCH] Input: tsc2004/5 - do not use irq_set_irq_wake() directly

[Sebastian Reichel]

Hi,

On Sun, Feb 12, 2017 at 03:43:33PM -0800, Dmitry Torokhov wrote:
> Instead of setting irq_set_irq_wake() directly in probe(), mark the device
> as wakeup-capable, and use enable_irq_wake() and disable_irq_wake() in
> suspend/resume path.
> 
> Signed-off-by: Dmitry Torokhov 

Reviewed-By: Sebastian Reichel 

I suggest to add a paragraph in the patch description, why the
change was done. E.g.:

This adds support for changing the wakeup setting dynamically at
runtime using /sys/devices/.../tsc2005/power/wakeup.

Also I wonder if the default should be 'off' (by using
device_set_wakeup_capable() instead of device_init_wakeup()

-- Sebastian

>  drivers/input/touchscreen/tsc200x-core.c | 13 -
>  1 file changed, 12 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/input/touchscreen/tsc200x-core.c 
> b/drivers/input/touchscreen/tsc200x-core.c
> index 88ea5e1b72ae..d1c40c803d61 100644
> --- a/drivers/input/touchscreen/tsc200x-core.c
> +++ b/drivers/input/touchscreen/tsc200x-core.c
> @@ -114,7 +114,9 @@ struct tsc200x {
>  
>   struct gpio_desc*reset_gpio;
>   int (*tsc200x_cmd)(struct device *dev, u8 cmd);
> +
>   int irq;
> + boolwake_irq_enabled;
>  };
>  
>  static void tsc200x_update_pen_state(struct tsc200x *ts,
> @@ -573,7 +575,8 @@ int tsc200x_probe(struct device *dev, int irq, const 
> struct input_id *tsc_id,
>   goto err_remove_sysfs;
>   }
>  
> - irq_set_irq_wake(irq, 1);
> + device_init_wakeup(dev, true);
> +
>   return 0;
>  
>  err_remove_sysfs:
> @@ -607,6 +610,9 @@ static int __maybe_unused tsc200x_suspend(struct device 
> *dev)
>  
>   ts->suspended = true;
>  
> + if (device_may_wakeup(dev))
> + ts->wake_irq_enabled = enable_irq_wake(ts->irq) == 0;
> +
>   mutex_unlock(>mutex);
>  
>   return 0;
> @@ -618,6 +624,11 @@ static int __maybe_unused tsc200x_resume(struct device 
> *dev)
>  
>   mutex_lock(>mutex);
>  
> + if (ts->wake_irq_enabled) {
> + disable_irq_wake(ts->irq);
> + ts->wake_irq_enabled = false;
> + }
> +
>   if (ts->suspended && ts->opened)
>   __tsc200x_enable(ts);
>  
> -- 
> 2.11.0.483.g087da7b7c-goog
> 
> 
> -- 
> Dmitry


signature.asc
Description: PGP signature

[PATCH RFC 2/3] coresight: add support for debug module

[Leo Yan]

Coresight includes debug module and usually the module connects with CPU
debug logic. ARMv8 architecture reference manual (ARMv8-ARM) has defined
the debug registers in the chapter "H9: External Debug Register
Descriptions".

After enable the debug module we can check CPU state and PC value, etc.
So this is helpful for some CPU lockup bugs, e.g. if one CPU has run
into infinite loop with IRQ disabled. So the CPU cannot switch context
and handle any interrupt, so it cannot handle SMP call for stack dump,
etc. Furthermore, now ARMv8 introduces some other runtime firmwares like
ARM trusted firmware BL31, so sometime CPU hard lock may happen in the
firmware and cannot return back to kernel.

This patch is to enable coresight debug module and register callback
notifier for panic; so when system detect the CPU lockup we can utilize
debug module registers to get to know PC value for all CPUs; so we can
quickly know the hang address for CPUs.

This is initial driver for coresight debug module and could enhance it
later according to debugging requirement.

Signed-off-by: Leo Yan 
---
 drivers/hwtracing/coresight/Kconfig   |   8 ++
 drivers/hwtracing/coresight/Makefile  |   1 +
 drivers/hwtracing/coresight/coresight-debug.c | 169 ++
 3 files changed, 178 insertions(+)
 create mode 100644 drivers/hwtracing/coresight/coresight-debug.c

diff --git a/drivers/hwtracing/coresight/Kconfig 
b/drivers/hwtracing/coresight/Kconfig
index 130cb21..dcf59cc 100644
--- a/drivers/hwtracing/coresight/Kconfig
+++ b/drivers/hwtracing/coresight/Kconfig
@@ -89,4 +89,12 @@ config CORESIGHT_STM
  logging useful software events or data coming from various entities
  in the system, possibly running different OSs
 
+config CORESIGHT_DEBUG
+   bool "CoreSight debug driver"
+   depends on ARM || ARM64
+   help
+ This driver provides support for coresight debugging module. This
+ is primarily used for printing out debug registers for panic and
+ soft and hard lockup.
+
 endif
diff --git a/drivers/hwtracing/coresight/Makefile 
b/drivers/hwtracing/coresight/Makefile
index af480d9..d540d45 100644
--- a/drivers/hwtracing/coresight/Makefile
+++ b/drivers/hwtracing/coresight/Makefile
@@ -16,3 +16,4 @@ obj-$(CONFIG_CORESIGHT_SOURCE_ETM4X) += coresight-etm4x.o \
coresight-etm4x-sysfs.o
 obj-$(CONFIG_CORESIGHT_QCOM_REPLICATOR) += coresight-replicator-qcom.o
 obj-$(CONFIG_CORESIGHT_STM) += coresight-stm.o
+obj-$(CONFIG_CORESIGHT_DEBUG) += coresight-debug.o
diff --git a/drivers/hwtracing/coresight/coresight-debug.c 
b/drivers/hwtracing/coresight/coresight-debug.c
new file mode 100644
index 000..28206a83
--- /dev/null
+++ b/drivers/hwtracing/coresight/coresight-debug.c
@@ -0,0 +1,169 @@
+/*
+ * Copyright(C) 2017 Linaro Limited. All rights reserved.
+ * Author: Leo Yan 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "coresight-priv.h"
+
+#define EDPCSR_LO  0x0A0
+#define EDPCSR_HI  0x0AC
+#define EDOSLAR0x300
+#define EDOSLSR0x304
+#define EDPDCR 0x310
+#define EDPDSR 0x314
+
+struct debug_drvdata {
+   void __iomem*base;
+   struct device   *dev;
+   int cpu;
+};
+
+static struct debug_drvdata *debug_drvdata[NR_CPUS];
+
+static void debug_os_unlock(struct debug_drvdata *drvdata)
+{
+   /* Unlocks the debug registers */
+   writel_relaxed(0x0, drvdata->base + EDOSLAR);
+   isb();
+}
+
+static void debug_read_pcsr(struct debug_drvdata *drvdata)
+{
+   u32 pcsr_hi, pcsr_lo;
+
+   CS_UNLOCK(drvdata->base);
+
+   debug_os_unlock(drvdata);
+
+#ifdef CONFIG_64BIT
+   pcsr_lo = readl_relaxed(drvdata->base + EDPCSR_LO);
+   pcsr_hi = readl_relaxed(drvdata->base + EDPCSR_HI);
+
+   pr_emerg("CPU[%d]: PSCR=0x%lx\n", drvdata->cpu,
+((unsigned long)pcsr_hi << 32 | (unsigned long)pcsr_lo));
+#else
+   pcsr_lo = readl_relaxed(drvdata->base + EDPCSR_LO);
+
+   pr_emerg("CPU[%d]: PSCR=0x%lx\n", drvdata->cpu, pcsr_lo);
+#endif
+
+   CS_LOCK(drvdata->base);
+}
+
+/*
+ * Dump out memory limit information on 

[PATCH RFC 3/3] arm64: dts: register Hi6220's coresight debug module

[Leo Yan]

Bind coresight debug driver for Hi6220.

Signed-off-by: Leo Yan 
---
 .../boot/dts/hisilicon/hikey_6220_coresight.dtsi   | 73 ++
 1 file changed, 73 insertions(+)

diff --git a/arch/arm64/boot/dts/hisilicon/hikey_6220_coresight.dtsi 
b/arch/arm64/boot/dts/hisilicon/hikey_6220_coresight.dtsi
index 77c2aab..e14d75c 100644
--- a/arch/arm64/boot/dts/hisilicon/hikey_6220_coresight.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hikey_6220_coresight.dtsi
@@ -15,6 +15,79 @@
#size-cells = <2>;
compatible = "arm,amba-bus";
ranges;
+
+   debug@0,f659 {
+   compatible = "arm,coresight-debug","arm,primecell";
+   reg = <0 0xf659 0 0x1000>;
+   default_enable;
+   clocks = <_ctrl HI6220_CS_ATB>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
+
+   debug@1,f6592000 {
+   compatible = "arm,coresight-debug","arm,primecell";
+   reg = <0 0xf6592000 0 0x1000>;
+   default_enable;
+   clocks = <_ctrl HI6220_CS_ATB>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
+
+   debug@2,f6594000 {
+   compatible = "arm,coresight-debug","arm,primecell";
+   reg = <0 0xf6594000 0 0x1000>;
+   default_enable;
+   clocks = <_ctrl HI6220_CS_ATB>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
+
+   debug@3,f6596000 {
+   compatible = "arm,coresight-debug","arm,primecell";
+   reg = <0 0xf6596000 0 0x1000>;
+   default_enable;
+   clocks = <_ctrl HI6220_CS_ATB>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
+
+   debug@4,f65d {
+   compatible = "arm,coresight-debug","arm,primecell";
+   reg = <0 0xf65d 0 0x1000>;
+   default_enable;
+   clocks = <_ctrl HI6220_CS_ATB>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
+
+   debug@5,f65d2000 {
+   compatible = "arm,coresight-debug","arm,primecell";
+   reg = <0 0xf65d2000 0 0x1000>;
+   default_enable;
+   clocks = <_ctrl HI6220_CS_ATB>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
+
+   debug@6,f65d4000 {
+   compatible = "arm,coresight-debug","arm,primecell";
+   reg = <0 0xf65d4000 0 0x1000>;
+   default_enable;
+   clocks = <_ctrl HI6220_CS_ATB>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
+
+   debug@7,f65d6000 {
+   compatible = "arm,coresight-debug","arm,primecell";
+   reg = <0 0xf65d6000 0 0x1000>;
+   default_enable;
+   clocks = <_ctrl HI6220_CS_ATB>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
+
etm@0,f659c000 {
compatible = "arm,coresight-etm4x","arm,primecell";
reg = <0 0xf659c000 0 0x1000>;
-- 
2.7.4

[PATCH RFC 3/3] arm64: dts: register Hi6220's coresight debug module

[Leo Yan]

Bind coresight debug driver for Hi6220.

Signed-off-by: Leo Yan 
---
 .../boot/dts/hisilicon/hikey_6220_coresight.dtsi   | 73 ++
 1 file changed, 73 insertions(+)

diff --git a/arch/arm64/boot/dts/hisilicon/hikey_6220_coresight.dtsi 
b/arch/arm64/boot/dts/hisilicon/hikey_6220_coresight.dtsi
index 77c2aab..e14d75c 100644
--- a/arch/arm64/boot/dts/hisilicon/hikey_6220_coresight.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hikey_6220_coresight.dtsi
@@ -15,6 +15,79 @@
#size-cells = <2>;
compatible = "arm,amba-bus";
ranges;
+
+   debug@0,f659 {
+   compatible = "arm,coresight-debug","arm,primecell";
+   reg = <0 0xf659 0 0x1000>;
+   default_enable;
+   clocks = <_ctrl HI6220_CS_ATB>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
+
+   debug@1,f6592000 {
+   compatible = "arm,coresight-debug","arm,primecell";
+   reg = <0 0xf6592000 0 0x1000>;
+   default_enable;
+   clocks = <_ctrl HI6220_CS_ATB>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
+
+   debug@2,f6594000 {
+   compatible = "arm,coresight-debug","arm,primecell";
+   reg = <0 0xf6594000 0 0x1000>;
+   default_enable;
+   clocks = <_ctrl HI6220_CS_ATB>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
+
+   debug@3,f6596000 {
+   compatible = "arm,coresight-debug","arm,primecell";
+   reg = <0 0xf6596000 0 0x1000>;
+   default_enable;
+   clocks = <_ctrl HI6220_CS_ATB>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
+
+   debug@4,f65d {
+   compatible = "arm,coresight-debug","arm,primecell";
+   reg = <0 0xf65d 0 0x1000>;
+   default_enable;
+   clocks = <_ctrl HI6220_CS_ATB>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
+
+   debug@5,f65d2000 {
+   compatible = "arm,coresight-debug","arm,primecell";
+   reg = <0 0xf65d2000 0 0x1000>;
+   default_enable;
+   clocks = <_ctrl HI6220_CS_ATB>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
+
+   debug@6,f65d4000 {
+   compatible = "arm,coresight-debug","arm,primecell";
+   reg = <0 0xf65d4000 0 0x1000>;
+   default_enable;
+   clocks = <_ctrl HI6220_CS_ATB>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
+
+   debug@7,f65d6000 {
+   compatible = "arm,coresight-debug","arm,primecell";
+   reg = <0 0xf65d6000 0 0x1000>;
+   default_enable;
+   clocks = <_ctrl HI6220_CS_ATB>;
+   clock-names = "apb_pclk";
+   cpu = <>;
+   };
+
etm@0,f659c000 {
compatible = "arm,coresight-etm4x","arm,primecell";
reg = <0 0xf659c000 0 0x1000>;
-- 
2.7.4

[PATCH RFC 2/3] coresight: add support for debug module

[Leo Yan]

Coresight includes debug module and usually the module connects with CPU
debug logic. ARMv8 architecture reference manual (ARMv8-ARM) has defined
the debug registers in the chapter "H9: External Debug Register
Descriptions".

After enable the debug module we can check CPU state and PC value, etc.
So this is helpful for some CPU lockup bugs, e.g. if one CPU has run
into infinite loop with IRQ disabled. So the CPU cannot switch context
and handle any interrupt, so it cannot handle SMP call for stack dump,
etc. Furthermore, now ARMv8 introduces some other runtime firmwares like
ARM trusted firmware BL31, so sometime CPU hard lock may happen in the
firmware and cannot return back to kernel.

This patch is to enable coresight debug module and register callback
notifier for panic; so when system detect the CPU lockup we can utilize
debug module registers to get to know PC value for all CPUs; so we can
quickly know the hang address for CPUs.

This is initial driver for coresight debug module and could enhance it
later according to debugging requirement.

Signed-off-by: Leo Yan 
---
 drivers/hwtracing/coresight/Kconfig   |   8 ++
 drivers/hwtracing/coresight/Makefile  |   1 +
 drivers/hwtracing/coresight/coresight-debug.c | 169 ++
 3 files changed, 178 insertions(+)
 create mode 100644 drivers/hwtracing/coresight/coresight-debug.c

diff --git a/drivers/hwtracing/coresight/Kconfig 
b/drivers/hwtracing/coresight/Kconfig
index 130cb21..dcf59cc 100644
--- a/drivers/hwtracing/coresight/Kconfig
+++ b/drivers/hwtracing/coresight/Kconfig
@@ -89,4 +89,12 @@ config CORESIGHT_STM
  logging useful software events or data coming from various entities
  in the system, possibly running different OSs
 
+config CORESIGHT_DEBUG
+   bool "CoreSight debug driver"
+   depends on ARM || ARM64
+   help
+ This driver provides support for coresight debugging module. This
+ is primarily used for printing out debug registers for panic and
+ soft and hard lockup.
+
 endif
diff --git a/drivers/hwtracing/coresight/Makefile 
b/drivers/hwtracing/coresight/Makefile
index af480d9..d540d45 100644
--- a/drivers/hwtracing/coresight/Makefile
+++ b/drivers/hwtracing/coresight/Makefile
@@ -16,3 +16,4 @@ obj-$(CONFIG_CORESIGHT_SOURCE_ETM4X) += coresight-etm4x.o \
coresight-etm4x-sysfs.o
 obj-$(CONFIG_CORESIGHT_QCOM_REPLICATOR) += coresight-replicator-qcom.o
 obj-$(CONFIG_CORESIGHT_STM) += coresight-stm.o
+obj-$(CONFIG_CORESIGHT_DEBUG) += coresight-debug.o
diff --git a/drivers/hwtracing/coresight/coresight-debug.c 
b/drivers/hwtracing/coresight/coresight-debug.c
new file mode 100644
index 000..28206a83
--- /dev/null
+++ b/drivers/hwtracing/coresight/coresight-debug.c
@@ -0,0 +1,169 @@
+/*
+ * Copyright(C) 2017 Linaro Limited. All rights reserved.
+ * Author: Leo Yan 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "coresight-priv.h"
+
+#define EDPCSR_LO  0x0A0
+#define EDPCSR_HI  0x0AC
+#define EDOSLAR0x300
+#define EDOSLSR0x304
+#define EDPDCR 0x310
+#define EDPDSR 0x314
+
+struct debug_drvdata {
+   void __iomem*base;
+   struct device   *dev;
+   int cpu;
+};
+
+static struct debug_drvdata *debug_drvdata[NR_CPUS];
+
+static void debug_os_unlock(struct debug_drvdata *drvdata)
+{
+   /* Unlocks the debug registers */
+   writel_relaxed(0x0, drvdata->base + EDOSLAR);
+   isb();
+}
+
+static void debug_read_pcsr(struct debug_drvdata *drvdata)
+{
+   u32 pcsr_hi, pcsr_lo;
+
+   CS_UNLOCK(drvdata->base);
+
+   debug_os_unlock(drvdata);
+
+#ifdef CONFIG_64BIT
+   pcsr_lo = readl_relaxed(drvdata->base + EDPCSR_LO);
+   pcsr_hi = readl_relaxed(drvdata->base + EDPCSR_HI);
+
+   pr_emerg("CPU[%d]: PSCR=0x%lx\n", drvdata->cpu,
+((unsigned long)pcsr_hi << 32 | (unsigned long)pcsr_lo));
+#else
+   pcsr_lo = readl_relaxed(drvdata->base + EDPCSR_LO);
+
+   pr_emerg("CPU[%d]: PSCR=0x%lx\n", drvdata->cpu, pcsr_lo);
+#endif
+
+   CS_LOCK(drvdata->base);
+}
+
+/*
+ * Dump out memory limit information on panic.
+ */
+static int 

Re: [PATCH] Input: pwm-beeper: support customized freq for SND_BELL

[Heiko Schocher]

Hello Rob,

Am 10.02.2017 um 16:48 schrieb Rob Herring:

On Tue, Feb 07, 2017 at 06:21:34AM +0100, Heiko Schocher wrote:

From: Guan Ben 

extend the pwm-beeper driver to support customized frequency
for SND_BELL from device tree.

Signed-off-by: Guan Ben 
Signed-off-by: Mark Jonas 
[h...@denx.de: adapted to 4.10-rc7]
Signed-off-by: Heiko Schocher 

---

  .../devicetree/bindings/input/pwm-beeper.txt   |  3 ++
  drivers/input/misc/pwm-beeper.c| 36 --
  2 files changed, 30 insertions(+), 9 deletions(-)

diff --git a/Documentation/devicetree/bindings/input/pwm-beeper.txt 
b/Documentation/devicetree/bindings/input/pwm-beeper.txt
index be332ae..438c6e0 100644
--- a/Documentation/devicetree/bindings/input/pwm-beeper.txt
+++ b/Documentation/devicetree/bindings/input/pwm-beeper.txt
@@ -5,3 +5,6 @@ Registers a PWM device as beeper.
  Required properties:
  - compatible: should be "pwm-beeper"
  - pwms: phandle to the physical PWM device
+
+optional properties:
+- bell-frequency:  bell frequency in Hz


Needs a unit suffix:
bell-frequency-hz or just bell-hz as hz implies frequency.

Or maybe beeper-hz would be more consistant.


Ok, I change it to "beeper-hz". Are this all issues with this patch?

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

[PATCH RFC 1/3] coresight: binding for coresight debug driver

[Leo Yan]

Adding compatible string for new coresight debug driver.

Signed-off-by: Leo Yan 
---
 Documentation/devicetree/bindings/arm/coresight.txt | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/coresight.txt 
b/Documentation/devicetree/bindings/arm/coresight.txt
index fcbae6a..3ff15fd 100644
--- a/Documentation/devicetree/bindings/arm/coresight.txt
+++ b/Documentation/devicetree/bindings/arm/coresight.txt
@@ -40,6 +40,9 @@ its hardware characteristcs.
- System Trace Macrocell:
"arm,coresight-stm", "arm,primecell"; [1]
 
+   - Debug Unit:
+   "arm,coresight-debug", "arm,primecell";
+
* reg: physical base address and length of the register
  set(s) of the component.
 
@@ -78,8 +81,10 @@ its hardware characteristcs.
* arm,cp14: must be present if the system accesses ETM/PTM management
  registers via co-processor 14.
 
-   * cpu: the cpu phandle this ETM/PTM is affined to. When omitted the
- source is considered to belong to CPU0.
+* Optional properties for ETM/PTM/Debugs:
+
+   * cpu: the cpu phandle this ETM/PTM/Debug is affined to. When omitted
+ the source is considered to belong to CPU0.
 
 * Optional property for TMC:
 
-- 
2.7.4

Re: [PATCH] Input: pwm-beeper: support customized freq for SND_BELL

[Heiko Schocher]

Hello Rob,

Am 10.02.2017 um 16:48 schrieb Rob Herring:

On Tue, Feb 07, 2017 at 06:21:34AM +0100, Heiko Schocher wrote:

From: Guan Ben 

extend the pwm-beeper driver to support customized frequency
for SND_BELL from device tree.

Signed-off-by: Guan Ben 
Signed-off-by: Mark Jonas 
[h...@denx.de: adapted to 4.10-rc7]
Signed-off-by: Heiko Schocher 

---

  .../devicetree/bindings/input/pwm-beeper.txt   |  3 ++
  drivers/input/misc/pwm-beeper.c| 36 --
  2 files changed, 30 insertions(+), 9 deletions(-)

diff --git a/Documentation/devicetree/bindings/input/pwm-beeper.txt 
b/Documentation/devicetree/bindings/input/pwm-beeper.txt
index be332ae..438c6e0 100644
--- a/Documentation/devicetree/bindings/input/pwm-beeper.txt
+++ b/Documentation/devicetree/bindings/input/pwm-beeper.txt
@@ -5,3 +5,6 @@ Registers a PWM device as beeper.
  Required properties:
  - compatible: should be "pwm-beeper"
  - pwms: phandle to the physical PWM device
+
+optional properties:
+- bell-frequency:  bell frequency in Hz


Needs a unit suffix:
bell-frequency-hz or just bell-hz as hz implies frequency.

Or maybe beeper-hz would be more consistant.


Ok, I change it to "beeper-hz". Are this all issues with this patch?

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

[PATCH RFC 1/3] coresight: binding for coresight debug driver

[Leo Yan]

Adding compatible string for new coresight debug driver.

Signed-off-by: Leo Yan 
---
 Documentation/devicetree/bindings/arm/coresight.txt | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/coresight.txt 
b/Documentation/devicetree/bindings/arm/coresight.txt
index fcbae6a..3ff15fd 100644
--- a/Documentation/devicetree/bindings/arm/coresight.txt
+++ b/Documentation/devicetree/bindings/arm/coresight.txt
@@ -40,6 +40,9 @@ its hardware characteristcs.
- System Trace Macrocell:
"arm,coresight-stm", "arm,primecell"; [1]
 
+   - Debug Unit:
+   "arm,coresight-debug", "arm,primecell";
+
* reg: physical base address and length of the register
  set(s) of the component.
 
@@ -78,8 +81,10 @@ its hardware characteristcs.
* arm,cp14: must be present if the system accesses ETM/PTM management
  registers via co-processor 14.
 
-   * cpu: the cpu phandle this ETM/PTM is affined to. When omitted the
- source is considered to belong to CPU0.
+* Optional properties for ETM/PTM/Debugs:
+
+   * cpu: the cpu phandle this ETM/PTM/Debug is affined to. When omitted
+ the source is considered to belong to CPU0.
 
 * Optional property for TMC:
 
-- 
2.7.4

[PATCH RFC 0/3] coresight: enable debug module

[Leo Yan]

This patch series is to enable coresight debug module. With debug
module we can check CPU state and PC value, etc. So this is helpful for
CPU lockup bugs, e.g. if one CPU has run into infinite loop with IRQ
disabled. The hang CPU cannot switch context and handle any interrupt,
so it cannot handle SMP call for stack dump, etc.

Furthermore, now ARMv8 introduces some runtime firmwares like ARM
trusted firmware BL31, so sometime CPU lockup may happen in the
firmware and cannot return back to kernel.

This initial patch series enable debug module and registers call back
notifier for PCSR register dumping when panic happens, so we can see
below dumping info for panic:

[   13.751777] Coresight debug module:
[   13.755275] CPU[0]: PSCR=0x08090cbc
[   13.759469] CPU[1]: PSCR=0x088bf9e4
[   13.763662] CPU[2]: PSCR=0x08090cc0
[   13.767856] CPU[3]: PSCR=0x08090cb8
[   13.772049] CPU[4]: PSCR=0x08090cc0
[   13.776243] CPU[5]: PSCR=0x08090cbc
[   13.780436] CPU[6]: PSCR=0x08090cc0
[   13.784630] CPU[7]: PSCR=0x08090cbc

This patch series has been verified on 96boards Hikey.


Leo Yan (3):
  coresight: binding for coresight debug driver
  coresight: add support for debug module
  arm64: dts: register Hi6220's coresight debug module

 .../devicetree/bindings/arm/coresight.txt  |   9 +-
 .../boot/dts/hisilicon/hikey_6220_coresight.dtsi   |  73 +
 drivers/hwtracing/coresight/Kconfig|   8 +
 drivers/hwtracing/coresight/Makefile   |   1 +
 drivers/hwtracing/coresight/coresight-debug.c  | 169 +
 5 files changed, 258 insertions(+), 2 deletions(-)
 create mode 100644 drivers/hwtracing/coresight/coresight-debug.c

-- 
2.7.4

[PATCH RFC 0/3] coresight: enable debug module

[Leo Yan]

This patch series is to enable coresight debug module. With debug
module we can check CPU state and PC value, etc. So this is helpful for
CPU lockup bugs, e.g. if one CPU has run into infinite loop with IRQ
disabled. The hang CPU cannot switch context and handle any interrupt,
so it cannot handle SMP call for stack dump, etc.

Furthermore, now ARMv8 introduces some runtime firmwares like ARM
trusted firmware BL31, so sometime CPU lockup may happen in the
firmware and cannot return back to kernel.

This initial patch series enable debug module and registers call back
notifier for PCSR register dumping when panic happens, so we can see
below dumping info for panic:

[   13.751777] Coresight debug module:
[   13.755275] CPU[0]: PSCR=0x08090cbc
[   13.759469] CPU[1]: PSCR=0x088bf9e4
[   13.763662] CPU[2]: PSCR=0x08090cc0
[   13.767856] CPU[3]: PSCR=0x08090cb8
[   13.772049] CPU[4]: PSCR=0x08090cc0
[   13.776243] CPU[5]: PSCR=0x08090cbc
[   13.780436] CPU[6]: PSCR=0x08090cc0
[   13.784630] CPU[7]: PSCR=0x08090cbc

This patch series has been verified on 96boards Hikey.


Leo Yan (3):
  coresight: binding for coresight debug driver
  coresight: add support for debug module
  arm64: dts: register Hi6220's coresight debug module

 .../devicetree/bindings/arm/coresight.txt  |   9 +-
 .../boot/dts/hisilicon/hikey_6220_coresight.dtsi   |  73 +
 drivers/hwtracing/coresight/Kconfig|   8 +
 drivers/hwtracing/coresight/Makefile   |   1 +
 drivers/hwtracing/coresight/coresight-debug.c  | 169 +
 5 files changed, 258 insertions(+), 2 deletions(-)
 create mode 100644 drivers/hwtracing/coresight/coresight-debug.c

-- 
2.7.4

[PATCH] x86: kernel: fix unused variable warning in vm86_32.c

[Seunghun Han]

If CONFIG_TRANSPARENT_HUGEPAGE is not set in kernel config, a warning is shown
in vm86_32.c.

The warning is as follows:
>arch/x86/kernel/vm86_32.c: In function ‘mark_screen_rdonly’:
>arch/x86/kernel/vm86_32.c:180:26: warning: unused variable ‘vma’ 
>[-Wunused-variable]
> struct vm_area_struct *vma = find_vma(mm, 0xA);

The vma variable is used to call split_huge_pmd() macro function, but
split_huge_pmd() is defined as a null macro when CONFIG_TRANSPARENT_HUGEPAGE is
not set in kernel config. Therefore, the compiler shows an unused variable
warning.

To remove this warning, I change the split_huge_pmd() macro function to static
inline function and static inline null function.
Inline function works like a macro function, therefore there is no impact on
Linux kernel working.

Signed-off-by: Seunghun Han 
---
 include/linux/huge_mm.h | 20 
 1 file changed, 8 insertions(+), 12 deletions(-)

diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
index a3762d4..912a763 100644
--- a/include/linux/huge_mm.h
+++ b/include/linux/huge_mm.h
@@ -123,15 +123,12 @@ void deferred_split_huge_page(struct page *page);
 void __split_huge_pmd(struct vm_area_struct *vma, pmd_t *pmd,
unsigned long address, bool freeze, struct page *page);
 
-#define split_huge_pmd(__vma, __pmd, __address)
\
-   do {\
-   pmd_t *pmd = (__pmd);   \
-   if (pmd_trans_huge(*pmd)\
-   || pmd_devmap(*pmd))\
-   __split_huge_pmd(__vma, __pmd, __address,   \
-   false, NULL);   \
-   }  while (0)
-
+static inline void split_huge_pmd(struct vm_area_struct *vma, pmd_t *pmd,
+   unsigned long address)
+{
+   if (pmd_trans_huge(*pmd) || pmd_devmap(*pmd))
+   __split_huge_pmd(vma, pmd, address, false, NULL);
+}
 
 void split_huge_pmd_address(struct vm_area_struct *vma, unsigned long address,
bool freeze, struct page *page);
@@ -241,9 +238,8 @@ static inline int split_huge_page(struct page *page)
return 0;
 }
 static inline void deferred_split_huge_page(struct page *page) {}
-#define split_huge_pmd(__vma, __pmd, __address)\
-   do { } while (0)
-
+static inline void split_huge_pmd(struct vm_area_struct *vma, pmd_t *pmd,
+   unsigned long address) {}
 static inline void __split_huge_pmd(struct vm_area_struct *vma, pmd_t *pmd,
unsigned long address, bool freeze, struct page *page) {}
 static inline void split_huge_pmd_address(struct vm_area_struct *vma,
-- 
2.1.4

[PATCH] x86: kernel: fix unused variable warning in vm86_32.c

[Seunghun Han]

If CONFIG_TRANSPARENT_HUGEPAGE is not set in kernel config, a warning is shown
in vm86_32.c.

The warning is as follows:
>arch/x86/kernel/vm86_32.c: In function ‘mark_screen_rdonly’:
>arch/x86/kernel/vm86_32.c:180:26: warning: unused variable ‘vma’ 
>[-Wunused-variable]
> struct vm_area_struct *vma = find_vma(mm, 0xA);

The vma variable is used to call split_huge_pmd() macro function, but
split_huge_pmd() is defined as a null macro when CONFIG_TRANSPARENT_HUGEPAGE is
not set in kernel config. Therefore, the compiler shows an unused variable
warning.

To remove this warning, I change the split_huge_pmd() macro function to static
inline function and static inline null function.
Inline function works like a macro function, therefore there is no impact on
Linux kernel working.

Signed-off-by: Seunghun Han 
---
 include/linux/huge_mm.h | 20 
 1 file changed, 8 insertions(+), 12 deletions(-)

diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
index a3762d4..912a763 100644
--- a/include/linux/huge_mm.h
+++ b/include/linux/huge_mm.h
@@ -123,15 +123,12 @@ void deferred_split_huge_page(struct page *page);
 void __split_huge_pmd(struct vm_area_struct *vma, pmd_t *pmd,
unsigned long address, bool freeze, struct page *page);
 
-#define split_huge_pmd(__vma, __pmd, __address)
\
-   do {\
-   pmd_t *pmd = (__pmd);   \
-   if (pmd_trans_huge(*pmd)\
-   || pmd_devmap(*pmd))\
-   __split_huge_pmd(__vma, __pmd, __address,   \
-   false, NULL);   \
-   }  while (0)
-
+static inline void split_huge_pmd(struct vm_area_struct *vma, pmd_t *pmd,
+   unsigned long address)
+{
+   if (pmd_trans_huge(*pmd) || pmd_devmap(*pmd))
+   __split_huge_pmd(vma, pmd, address, false, NULL);
+}
 
 void split_huge_pmd_address(struct vm_area_struct *vma, unsigned long address,
bool freeze, struct page *page);
@@ -241,9 +238,8 @@ static inline int split_huge_page(struct page *page)
return 0;
 }
 static inline void deferred_split_huge_page(struct page *page) {}
-#define split_huge_pmd(__vma, __pmd, __address)\
-   do { } while (0)
-
+static inline void split_huge_pmd(struct vm_area_struct *vma, pmd_t *pmd,
+   unsigned long address) {}
 static inline void __split_huge_pmd(struct vm_area_struct *vma, pmd_t *pmd,
unsigned long address, bool freeze, struct page *page) {}
 static inline void split_huge_pmd_address(struct vm_area_struct *vma,
-- 
2.1.4

Re: [lkp] [x86/acpi] dc6db24d24: BUG: unable to handle kernel paging request at 0000116007090008

[Ye Xiaolong]

Hi, liyang

On 02/13, Dou Liyang wrote:
>Hi, Xiaolong
>
>At 02/13/2017 09:37 AM, Ye Xiaolong wrote:
>>On 11/21, Dou Liyang wrote:
>>>Hi, Xiaolong,
>>>
>>>At 11/21/2016 09:31 AM, Ye Xiaolong wrote:
On 11/18, Dou Liyang wrote:
>Hi xiaolong
>
>At 11/18/2016 02:16 PM, Ye Xiaolong wrote:
>>Hi, liyang
>>
>>Sorry for the late.
>>
>>On 10/31, Dou Liyang wrote:
>>>Hi, Xiaolong,
>>>
>>>I research the ACPI table for a long time, and I found that:
>>>The reason for this bug is the duplicate IDs "0xFF" in DSDT.
>>>it has already been fixed in the committed id
>>>8e089eaa1999def4bb954caa91941f29b0672b6a and
>>>fd74da217df7d4bd25e95411da64e0b92762842e which is after the
>>>dc6db24d2476cd09c0ecf2b8d80313539f737a89 .
>>>
>>>could you help me to Verify my thoughts in the LKP.
>>>
>>
>>I've queued the same test jobs for commit fd74da217d, I'll notify you
>>once I get the results.
>

Hi, Liyang,

Results show that the reported error is gone with commit 
fd74da217df7d4bd25e95411da64e0b92762842e
below is the comparison.

>>>
>>>thanks a lot. that means it has been fixed.
>>
>>Sorry for my neglect, the result for fd74da217df7d4bd25e95411da showed no 
>>dmesg
>>because it's incomplete run and has no demsg stat at all.
>
>Is that means:
>
>you have already tested the Linux branch which contains the commit
>fd74da217df7d. and it doesn't work well.
>
>Btw, Why the test is incomplete run ?

Yes, We've got plenty test results for kernel that contains fd74da217df7d such 
as v4.9,
v4.10-rc1, v4.10-rc2, they all have the same dmesg errors.
For the incomplete run, it may happen sometimes due to kernel panic during boot 
time and
0day failed to capture its dmesg stat.

>
>>The bug still persists in v4.9, v4.10-rcx, the lastest kernel head,
>
>If the dmesg and stat of the test is NULL, How do you prove that the
>bug still exists?

This "dmesg stat is empty" refer to test for kernel image which head commit is 
fd74da217df7d,
not for all test results.

>
>>could you help to check?
>>
>
>Yes, I think we first should make the test with commit fd74da217df7d
>work in the specific test machine.
>
>test machine: 72 threads Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz
>with 128G memory
>
>Am I right? waiting your response.

Yes, currently we just found this issue on a specific machine, and I've queued 
the
same jobs to other machines to see whether they have the same issue.

Thanks,
Xiaolong
>
>Thanks,
>Liyang
>
>>Thanks,
>>Xiaolong
>>
>>>

compare -at dc6db24d2476cd09c0ecf2b8d80313539f737a89 
fd74da217df7d4bd25e95411da64e0b92762842e
tests: 1
testcase/path_params/tbox_group/run: 
vm-scalability/300-never-never-1-1-swap-w-rand-performance/lkp-hsw-ep2

dc6db24d2476cd09  fd74da217df7d4bd25e95411da
  --
  fail:runs  %reproductionfail:runs
  | | |
12:12-100%:3 
 dmesg.BUG:unable_to_handle_kernel
12:12-100%:3 dmesg.Oops
12:12-100%:3 dmesg.RIP:get_partial_node
 9:12 -75%:3 
 dmesg.RIP:_raw_spin_lock_irqsave
 3:12 -25%:3 
 dmesg.general_protection_fault:#[##]SMP
 3:12 -25%:3 
 dmesg.RIP:native_queued_spin_lock_slowpath
 3:12 -25%:3 
 dmesg.Kernel_panic-not_syncing:Hard_LOCKUP
 2:12 -17%:3 dmesg.RIP:load_balance
 2:12 -17%:3 
 dmesg.Kernel_panic-not_syncing:Fatal_exception_in_interrupt
 1:12  -8%:3 dmesg.RIP:resched_curr
 1:12  -8%:3 
 dmesg.Kernel_panic-not_syncing:Fatal_exception
 5:12 -42%:3 
 dmesg.WARNING:at_include/linux/uaccess.h:#__probe_kernel_read
 1:12  -8%:3 
 dmesg.WARNING:at_lib/list_debug.c:#__list_add


>>>
>>>2. About the LKP-tests, I want run the tests in my own pc.
>>>I use the debain sid as an OS. the .yaml file can be installed and
>>>job splited, but it can't be run correctly.
>>>
>>>Is the linux source code must be in /tmp/?
>>>And if I need to modify the .yaml file to fit my pc.
>>>
>>
>>Could you paste the error log for me to analyze?
>
>Yes.  let me tidy up it ah. :)
>
>>>
>>>And, I am very interesting in LKP-Test. when I built it, I met some
>>>problems.
>>>
>>>here is the error log:
>>>
>>>root@debian:/home/douly/lkp-tests# lkp run 
>>>./job-unlink2-performance-04c197c080f2ed7a022f79701455c6837f4b9573-debian-x86_64-2016-08-31.cgz.yaml
>>>
>>>IPMI BMC is not supported on this machine, skip bmc-watchdog setup!
>>>2016-11-21 15:21:01 

Re: [lkp] [x86/acpi] dc6db24d24: BUG: unable to handle kernel paging request at 0000116007090008

[Ye Xiaolong]

Hi, liyang

On 02/13, Dou Liyang wrote:
>Hi, Xiaolong
>
>At 02/13/2017 09:37 AM, Ye Xiaolong wrote:
>>On 11/21, Dou Liyang wrote:
>>>Hi, Xiaolong,
>>>
>>>At 11/21/2016 09:31 AM, Ye Xiaolong wrote:
On 11/18, Dou Liyang wrote:
>Hi xiaolong
>
>At 11/18/2016 02:16 PM, Ye Xiaolong wrote:
>>Hi, liyang
>>
>>Sorry for the late.
>>
>>On 10/31, Dou Liyang wrote:
>>>Hi, Xiaolong,
>>>
>>>I research the ACPI table for a long time, and I found that:
>>>The reason for this bug is the duplicate IDs "0xFF" in DSDT.
>>>it has already been fixed in the committed id
>>>8e089eaa1999def4bb954caa91941f29b0672b6a and
>>>fd74da217df7d4bd25e95411da64e0b92762842e which is after the
>>>dc6db24d2476cd09c0ecf2b8d80313539f737a89 .
>>>
>>>could you help me to Verify my thoughts in the LKP.
>>>
>>
>>I've queued the same test jobs for commit fd74da217d, I'll notify you
>>once I get the results.
>

Hi, Liyang,

Results show that the reported error is gone with commit 
fd74da217df7d4bd25e95411da64e0b92762842e
below is the comparison.

>>>
>>>thanks a lot. that means it has been fixed.
>>
>>Sorry for my neglect, the result for fd74da217df7d4bd25e95411da showed no 
>>dmesg
>>because it's incomplete run and has no demsg stat at all.
>
>Is that means:
>
>you have already tested the Linux branch which contains the commit
>fd74da217df7d. and it doesn't work well.
>
>Btw, Why the test is incomplete run ?

Yes, We've got plenty test results for kernel that contains fd74da217df7d such 
as v4.9,
v4.10-rc1, v4.10-rc2, they all have the same dmesg errors.
For the incomplete run, it may happen sometimes due to kernel panic during boot 
time and
0day failed to capture its dmesg stat.

>
>>The bug still persists in v4.9, v4.10-rcx, the lastest kernel head,
>
>If the dmesg and stat of the test is NULL, How do you prove that the
>bug still exists?

This "dmesg stat is empty" refer to test for kernel image which head commit is 
fd74da217df7d,
not for all test results.

>
>>could you help to check?
>>
>
>Yes, I think we first should make the test with commit fd74da217df7d
>work in the specific test machine.
>
>test machine: 72 threads Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz
>with 128G memory
>
>Am I right? waiting your response.

Yes, currently we just found this issue on a specific machine, and I've queued 
the
same jobs to other machines to see whether they have the same issue.

Thanks,
Xiaolong
>
>Thanks,
>Liyang
>
>>Thanks,
>>Xiaolong
>>
>>>

compare -at dc6db24d2476cd09c0ecf2b8d80313539f737a89 
fd74da217df7d4bd25e95411da64e0b92762842e
tests: 1
testcase/path_params/tbox_group/run: 
vm-scalability/300-never-never-1-1-swap-w-rand-performance/lkp-hsw-ep2

dc6db24d2476cd09  fd74da217df7d4bd25e95411da
  --
  fail:runs  %reproductionfail:runs
  | | |
12:12-100%:3 
 dmesg.BUG:unable_to_handle_kernel
12:12-100%:3 dmesg.Oops
12:12-100%:3 dmesg.RIP:get_partial_node
 9:12 -75%:3 
 dmesg.RIP:_raw_spin_lock_irqsave
 3:12 -25%:3 
 dmesg.general_protection_fault:#[##]SMP
 3:12 -25%:3 
 dmesg.RIP:native_queued_spin_lock_slowpath
 3:12 -25%:3 
 dmesg.Kernel_panic-not_syncing:Hard_LOCKUP
 2:12 -17%:3 dmesg.RIP:load_balance
 2:12 -17%:3 
 dmesg.Kernel_panic-not_syncing:Fatal_exception_in_interrupt
 1:12  -8%:3 dmesg.RIP:resched_curr
 1:12  -8%:3 
 dmesg.Kernel_panic-not_syncing:Fatal_exception
 5:12 -42%:3 
 dmesg.WARNING:at_include/linux/uaccess.h:#__probe_kernel_read
 1:12  -8%:3 
 dmesg.WARNING:at_lib/list_debug.c:#__list_add


>>>
>>>2. About the LKP-tests, I want run the tests in my own pc.
>>>I use the debain sid as an OS. the .yaml file can be installed and
>>>job splited, but it can't be run correctly.
>>>
>>>Is the linux source code must be in /tmp/?
>>>And if I need to modify the .yaml file to fit my pc.
>>>
>>
>>Could you paste the error log for me to analyze?
>
>Yes.  let me tidy up it ah. :)
>
>>>
>>>And, I am very interesting in LKP-Test. when I built it, I met some
>>>problems.
>>>
>>>here is the error log:
>>>
>>>root@debian:/home/douly/lkp-tests# lkp run 
>>>./job-unlink2-performance-04c197c080f2ed7a022f79701455c6837f4b9573-debian-x86_64-2016-08-31.cgz.yaml
>>>
>>>IPMI BMC is not supported on this machine, skip bmc-watchdog setup!
>>>2016-11-21 15:21:01 

Re: [RFC][PATCH 12/21] tracing: Account for variables in named trigger compatibility

[Namhyung Kim]

On Wed, Feb 08, 2017 at 11:25:08AM -0600, Tom Zanussi wrote:
> Named triggers must also have the same set of variables in order to be
> considered compatible - update the trigger match test to account for
> that.
> 
> The reason for this requirement is that named triggers with variables
> are meant to allow one or more events to set the same variable.
> 
> Signed-off-by: Tom Zanussi 
> ---
>  kernel/trace/trace_events_hist.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/kernel/trace/trace_events_hist.c 
> b/kernel/trace/trace_events_hist.c
> index e707577..889455e 100644
> --- a/kernel/trace/trace_events_hist.c
> +++ b/kernel/trace/trace_events_hist.c
> @@ -1576,6 +1576,10 @@ static bool hist_trigger_match(struct 
> event_trigger_data *data,
>   return false;
>   if (key_field->is_signed != key_field_test->is_signed)
>   return false;
> + if ((key_field->var_name && !key_field_test->var_name) ||
> + (!key_field->var_name && key_field_test->var_name) ||
> + strcmp(key_field->var_name, key_field_test->var_name) != 0)
> + return false;

What if key_field->var_name and key_field_test->var_name are both
NULL?

Thanks,
Namhyung

>   }
>  
>   for (i = 0; i < hist_data->n_sort_keys; i++) {
> -- 
> 1.9.3
> 

Re: [RFC][PATCH 12/21] tracing: Account for variables in named trigger compatibility

[Namhyung Kim]

On Wed, Feb 08, 2017 at 11:25:08AM -0600, Tom Zanussi wrote:
> Named triggers must also have the same set of variables in order to be
> considered compatible - update the trigger match test to account for
> that.
> 
> The reason for this requirement is that named triggers with variables
> are meant to allow one or more events to set the same variable.
> 
> Signed-off-by: Tom Zanussi 
> ---
>  kernel/trace/trace_events_hist.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/kernel/trace/trace_events_hist.c 
> b/kernel/trace/trace_events_hist.c
> index e707577..889455e 100644
> --- a/kernel/trace/trace_events_hist.c
> +++ b/kernel/trace/trace_events_hist.c
> @@ -1576,6 +1576,10 @@ static bool hist_trigger_match(struct 
> event_trigger_data *data,
>   return false;
>   if (key_field->is_signed != key_field_test->is_signed)
>   return false;
> + if ((key_field->var_name && !key_field_test->var_name) ||
> + (!key_field->var_name && key_field_test->var_name) ||
> + strcmp(key_field->var_name, key_field_test->var_name) != 0)
> + return false;

What if key_field->var_name and key_field_test->var_name are both
NULL?

Thanks,
Namhyung

>   }
>  
>   for (i = 0; i < hist_data->n_sort_keys; i++) {
> -- 
> 1.9.3
> 

Re: [RFC][PATCH 11/21] tracing: Add variable support to hist triggers

[Namhyung Kim]

On Wed, Feb 08, 2017 at 11:25:07AM -0600, Tom Zanussi wrote:
> Add support for saving the value of a current event's event field by
> assigning it to a variable that can be read by a subsequent event.
> 
> The basic syntax for saving a variable is to simply prefix a unique
> variable name not corresponding to any keyword along with an '=' sign
> to any event field.
> 
> Both keys and values can be saved and retrieved in this way:
> 
> # echo 'hist:keys=next_pid:vals=ts0=common_timestamp ...
> # echo 'hist:key=timer_pid=common_pid ...'
> 
> If a variable isn't a key variable or prefixed with 'vals=', the
> associated event field will be saved in a variable but won't be summed
> as a value:
> 
> # echo 'hist:keys=next_pid:ts1=common_timestamp:...
> 
> Multiple variables can be assigned at the same time:
> 
> # echo 'hist:keys=pid:vals=ts0=common_timestamp,b=field1,field2 ...
> 
> Variables set as above can be used by being referenced from another
> event, as described in a subsequent patch.
> 
> Signed-off-by: Tom Zanussi 
> ---
>  kernel/trace/trace_events_hist.c | 160 
> ---
>  1 file changed, 131 insertions(+), 29 deletions(-)
> 
> diff --git a/kernel/trace/trace_events_hist.c 
> b/kernel/trace/trace_events_hist.c
> index 8d7f7dd..e707577 100644
> --- a/kernel/trace/trace_events_hist.c
> +++ b/kernel/trace/trace_events_hist.c
> @@ -29,6 +29,7 @@ typedef u64 (*hist_field_fn_t) (struct hist_field *field, 
> void *event,
>   struct ring_buffer_event *rbe);
>  
>  #define HIST_FIELD_OPERANDS_MAX  2
> +#define HIST_ASSIGNMENT_MAX  4
>  
>  struct hist_field {
>   struct ftrace_event_field   *field;
> @@ -36,8 +37,10 @@ struct hist_field {
>   hist_field_fn_t fn;
>   unsigned intsize;
>   unsigned intoffset;
> - unsigned intis_signed;
> + unsigned intis_signed;

It seems like an unnecessary change.

>   struct hist_field   *operands[HIST_FIELD_OPERANDS_MAX];
> + u64 var_val;
> + char*var_name;
>  };
>  
>  static u64 hist_field_none(struct hist_field *field, void *event,
> @@ -140,12 +143,16 @@ enum hist_field_flags {
>   HIST_FIELD_FL_SYSCALL   = 128,
>   HIST_FIELD_FL_STACKTRACE= 256,
>   HIST_FIELD_FL_LOG2  = 512,
> - HIST_FIELD_FL_TIMESTAMP = 1024,
> + HIST_FIELD_FL_VAR   = 1024,
> + HIST_FIELD_FL_VAR_ONLY  = 2048,
> + HIST_FIELD_FL_TIMESTAMP = 4096,

Why did you move the timestamp?

>  };
>  
>  struct hist_trigger_attrs {
>   char*keys_str;
>   char*vals_str;
> + char*assignment_str[HIST_ASSIGNMENT_MAX];
> + unsigned intn_assignments;
>   char*sort_key_str;
>   char*name;
>   boolpause;
> @@ -241,9 +248,14 @@ static int parse_map_size(char *str)
>  
>  static void destroy_hist_trigger_attrs(struct hist_trigger_attrs *attrs)
>  {
> + unsigned int i;
> +
>   if (!attrs)
>   return;
>  
> + for (i = 0; i < attrs->n_assignments; i++)
> + kfree(attrs->assignment_str[i]);
> +
>   kfree(attrs->name);
>   kfree(attrs->sort_key_str);
>   kfree(attrs->keys_str);
> @@ -258,9 +270,9 @@ static int parse_assignment(char *str, struct 
> hist_trigger_attrs *attrs)
>   if ((strncmp(str, "key=", strlen("key=")) == 0) ||
>   (strncmp(str, "keys=", strlen("keys=")) == 0))
>   attrs->keys_str = kstrdup(str, GFP_KERNEL);
> - else if ((strncmp(str, "val=", strlen("val=")) == 0) ||
> -  (strncmp(str, "vals=", strlen("vals=")) == 0) ||
> -  (strncmp(str, "values=", strlen("values=")) == 0))
> + else if (((strncmp(str, "val=", strlen("val=")) == 0) ||
> +   (strncmp(str, "vals=", strlen("vals=")) == 0) ||
> +   (strncmp(str, "values=", strlen("values=")) == 0)))

Looks unnecessary too.

>   attrs->vals_str = kstrdup(str, GFP_KERNEL);
>   else if (strncmp(str, "sort=", strlen("sort=")) == 0)
>   attrs->sort_key_str = kstrdup(str, GFP_KERNEL);
> @@ -274,8 +286,22 @@ static int parse_assignment(char *str, struct 
> hist_trigger_attrs *attrs)
>   goto out;
>   }
>   attrs->map_bits = map_bits;
> - } else
> - ret = -EINVAL;
> + } else {
> + char *assignment;
> +
> + if (attrs->n_assignments == HIST_ASSIGNMENT_MAX) {
> + ret = -EINVAL;
> + goto out;
> + }
> +
> + assignment = kstrdup(str, GFP_KERNEL);
> + if (!assignment) {
> + ret = -ENOMEM;
> + goto out;
> + }
> +
> 

Re: [RFC][PATCH 11/21] tracing: Add variable support to hist triggers

[Namhyung Kim]

On Wed, Feb 08, 2017 at 11:25:07AM -0600, Tom Zanussi wrote:
> Add support for saving the value of a current event's event field by
> assigning it to a variable that can be read by a subsequent event.
> 
> The basic syntax for saving a variable is to simply prefix a unique
> variable name not corresponding to any keyword along with an '=' sign
> to any event field.
> 
> Both keys and values can be saved and retrieved in this way:
> 
> # echo 'hist:keys=next_pid:vals=ts0=common_timestamp ...
> # echo 'hist:key=timer_pid=common_pid ...'
> 
> If a variable isn't a key variable or prefixed with 'vals=', the
> associated event field will be saved in a variable but won't be summed
> as a value:
> 
> # echo 'hist:keys=next_pid:ts1=common_timestamp:...
> 
> Multiple variables can be assigned at the same time:
> 
> # echo 'hist:keys=pid:vals=ts0=common_timestamp,b=field1,field2 ...
> 
> Variables set as above can be used by being referenced from another
> event, as described in a subsequent patch.
> 
> Signed-off-by: Tom Zanussi 
> ---
>  kernel/trace/trace_events_hist.c | 160 
> ---
>  1 file changed, 131 insertions(+), 29 deletions(-)
> 
> diff --git a/kernel/trace/trace_events_hist.c 
> b/kernel/trace/trace_events_hist.c
> index 8d7f7dd..e707577 100644
> --- a/kernel/trace/trace_events_hist.c
> +++ b/kernel/trace/trace_events_hist.c
> @@ -29,6 +29,7 @@ typedef u64 (*hist_field_fn_t) (struct hist_field *field, 
> void *event,
>   struct ring_buffer_event *rbe);
>  
>  #define HIST_FIELD_OPERANDS_MAX  2
> +#define HIST_ASSIGNMENT_MAX  4
>  
>  struct hist_field {
>   struct ftrace_event_field   *field;
> @@ -36,8 +37,10 @@ struct hist_field {
>   hist_field_fn_t fn;
>   unsigned intsize;
>   unsigned intoffset;
> - unsigned intis_signed;
> + unsigned intis_signed;

It seems like an unnecessary change.

>   struct hist_field   *operands[HIST_FIELD_OPERANDS_MAX];
> + u64 var_val;
> + char*var_name;
>  };
>  
>  static u64 hist_field_none(struct hist_field *field, void *event,
> @@ -140,12 +143,16 @@ enum hist_field_flags {
>   HIST_FIELD_FL_SYSCALL   = 128,
>   HIST_FIELD_FL_STACKTRACE= 256,
>   HIST_FIELD_FL_LOG2  = 512,
> - HIST_FIELD_FL_TIMESTAMP = 1024,
> + HIST_FIELD_FL_VAR   = 1024,
> + HIST_FIELD_FL_VAR_ONLY  = 2048,
> + HIST_FIELD_FL_TIMESTAMP = 4096,

Why did you move the timestamp?

>  };
>  
>  struct hist_trigger_attrs {
>   char*keys_str;
>   char*vals_str;
> + char*assignment_str[HIST_ASSIGNMENT_MAX];
> + unsigned intn_assignments;
>   char*sort_key_str;
>   char*name;
>   boolpause;
> @@ -241,9 +248,14 @@ static int parse_map_size(char *str)
>  
>  static void destroy_hist_trigger_attrs(struct hist_trigger_attrs *attrs)
>  {
> + unsigned int i;
> +
>   if (!attrs)
>   return;
>  
> + for (i = 0; i < attrs->n_assignments; i++)
> + kfree(attrs->assignment_str[i]);
> +
>   kfree(attrs->name);
>   kfree(attrs->sort_key_str);
>   kfree(attrs->keys_str);
> @@ -258,9 +270,9 @@ static int parse_assignment(char *str, struct 
> hist_trigger_attrs *attrs)
>   if ((strncmp(str, "key=", strlen("key=")) == 0) ||
>   (strncmp(str, "keys=", strlen("keys=")) == 0))
>   attrs->keys_str = kstrdup(str, GFP_KERNEL);
> - else if ((strncmp(str, "val=", strlen("val=")) == 0) ||
> -  (strncmp(str, "vals=", strlen("vals=")) == 0) ||
> -  (strncmp(str, "values=", strlen("values=")) == 0))
> + else if (((strncmp(str, "val=", strlen("val=")) == 0) ||
> +   (strncmp(str, "vals=", strlen("vals=")) == 0) ||
> +   (strncmp(str, "values=", strlen("values=")) == 0)))

Looks unnecessary too.

>   attrs->vals_str = kstrdup(str, GFP_KERNEL);
>   else if (strncmp(str, "sort=", strlen("sort=")) == 0)
>   attrs->sort_key_str = kstrdup(str, GFP_KERNEL);
> @@ -274,8 +286,22 @@ static int parse_assignment(char *str, struct 
> hist_trigger_attrs *attrs)
>   goto out;
>   }
>   attrs->map_bits = map_bits;
> - } else
> - ret = -EINVAL;
> + } else {
> + char *assignment;
> +
> + if (attrs->n_assignments == HIST_ASSIGNMENT_MAX) {
> + ret = -EINVAL;
> + goto out;
> + }
> +
> + assignment = kstrdup(str, GFP_KERNEL);
> + if (!assignment) {
> + ret = -ENOMEM;
> + goto out;
> + }
> +
> + 

Re: [PATCH] llist: Don't reinvent the wheel but use existing llist API

[Byungchul Park]

On Mon, Feb 13, 2017 at 05:43:26AM +, Al Viro wrote:
> On Mon, Feb 13, 2017 at 01:10:13PM +0900, Byungchul Park wrote:
> > Although llist provides proper APIs, they are not used. Make them used.
> 
> > @@ -231,12 +231,10 @@ static void __fput(struct file *file)
> >  static void delayed_fput(struct work_struct *unused)
> >  {
> > struct llist_node *node = llist_del_all(_fput_list);
> > -   struct llist_node *next;
> > +   struct file *f;
> >  
> > -   for (; node; node = next) {
> > -   next = llist_next(node);
> > -   __fput(llist_entry(node, struct file, f_u.fu_llist));
> > -   }
> > +   llist_for_each_entry(f, node, f_u.fu_llist)
> > +   __fput(f);
> >  }
> 
> #define llist_for_each_entry(pos, node, member) \
> for ((pos) = llist_entry((node), typeof(*(pos)), member);   \
>  &(pos)->member != NULL;\
>  (pos) = llist_entry((pos)->member.next, typeof(*(pos)), member))
> 
> Now, think what happens after __fput() frees the damn thing.  In the
> step of that loop, that is.
> 
> That kind of pattern (find next, do something with the current, proceed to
> the next we'd found before) is a strong hint that this "do something"
> might remove the thing from the list, or outright destroy it.  Both
> file_table.c and namespace.c chunks are breaking exactly that kind of
> places.
> 
> Please, don't do this kind of conversions blindly.  There _is_ another
> iterating primitive for such places, but figuring out which one is right
> is not something you can do without understanding what the code is doing.

I'm really sorry. I made a mistake. I should have used the safe version in
the case.

> And no, blind replacement of all such loops with llist_for_each_entry_safe,
> just in case, is not a good idea either.

Re: [PATCH] llist: Don't reinvent the wheel but use existing llist API

[Byungchul Park]

On Mon, Feb 13, 2017 at 05:43:26AM +, Al Viro wrote:
> On Mon, Feb 13, 2017 at 01:10:13PM +0900, Byungchul Park wrote:
> > Although llist provides proper APIs, they are not used. Make them used.
> 
> > @@ -231,12 +231,10 @@ static void __fput(struct file *file)
> >  static void delayed_fput(struct work_struct *unused)
> >  {
> > struct llist_node *node = llist_del_all(_fput_list);
> > -   struct llist_node *next;
> > +   struct file *f;
> >  
> > -   for (; node; node = next) {
> > -   next = llist_next(node);
> > -   __fput(llist_entry(node, struct file, f_u.fu_llist));
> > -   }
> > +   llist_for_each_entry(f, node, f_u.fu_llist)
> > +   __fput(f);
> >  }
> 
> #define llist_for_each_entry(pos, node, member) \
> for ((pos) = llist_entry((node), typeof(*(pos)), member);   \
>  &(pos)->member != NULL;\
>  (pos) = llist_entry((pos)->member.next, typeof(*(pos)), member))
> 
> Now, think what happens after __fput() frees the damn thing.  In the
> step of that loop, that is.
> 
> That kind of pattern (find next, do something with the current, proceed to
> the next we'd found before) is a strong hint that this "do something"
> might remove the thing from the list, or outright destroy it.  Both
> file_table.c and namespace.c chunks are breaking exactly that kind of
> places.
> 
> Please, don't do this kind of conversions blindly.  There _is_ another
> iterating primitive for such places, but figuring out which one is right
> is not something you can do without understanding what the code is doing.

I'm really sorry. I made a mistake. I should have used the safe version in
the case.

> And no, blind replacement of all such loops with llist_for_each_entry_safe,
> just in case, is not a good idea either.

Re: [PATCH] llist: Don't reinvent the wheel but use existing llist API

[Byungchul Park]

On Mon, Feb 13, 2017 at 01:38:36PM +0800, Huang, Ying wrote:
> Hi, Byungchul,
> 
> Byungchul Park  writes:
> 
> > Although llist provides proper APIs, they are not used. Make them used.
> >
> > Signed-off-by: Byungchul Park 
> > ---
> >  drivers/md/bcache/closure.c | 15 ++-
> >  drivers/md/raid5.c  |  4 +---
> >  drivers/vhost/scsi.c|  9 ++---
> >  fs/file_table.c | 12 +---
> >  fs/namespace.c  | 12 +---
> >  include/linux/llist.h   |  3 +++
> >  kernel/irq_work.c   |  6 +-
> >  kernel/sched/core.c | 13 ++---
> >  mm/vmalloc.c|  8 +++-
> 
> I think you need to split the patch.  One for each subsystem, this makes
> it easier to be reviewed and merged.

Thank you. I will do it.

> 
> Best Regards,
> Huang, Ying
> 
> [snip]

Re: [PATCH] llist: Don't reinvent the wheel but use existing llist API

[Byungchul Park]

On Mon, Feb 13, 2017 at 01:38:36PM +0800, Huang, Ying wrote:
> Hi, Byungchul,
> 
> Byungchul Park  writes:
> 
> > Although llist provides proper APIs, they are not used. Make them used.
> >
> > Signed-off-by: Byungchul Park 
> > ---
> >  drivers/md/bcache/closure.c | 15 ++-
> >  drivers/md/raid5.c  |  4 +---
> >  drivers/vhost/scsi.c|  9 ++---
> >  fs/file_table.c | 12 +---
> >  fs/namespace.c  | 12 +---
> >  include/linux/llist.h   |  3 +++
> >  kernel/irq_work.c   |  6 +-
> >  kernel/sched/core.c | 13 ++---
> >  mm/vmalloc.c|  8 +++-
> 
> I think you need to split the patch.  One for each subsystem, this makes
> it easier to be reviewed and merged.

Thank you. I will do it.

> 
> Best Regards,
> Huang, Ying
> 
> [snip]