Re: Mistake in include IS_ENABLED(CONFIG_LIVEPATCH)

[Jiri Kosina]

On Sat, 11 Feb 2017, Denys Fedoryshchenko wrote:

> I noticed that sample of livepatch is not working in 4.9.9, because in
> include,
> linux/livepatch.h
> it is:
> #if IS_ENABLED(CONFIG_LIVEPATCH)
> 
> while config option is:
> CONFIG_HAVE_LIVEPATCH=y
> 
> After editing livepatch.h sample module compiles fine
> 
> Probably that's just a typo?

There are two config variables. CONFIG_HAVE_LIVEPATCH is set by those 
architectures for which livepatching implementation exists.

CONFIG_LIVEPATCH is the actual config option turning the support in kernel 
on/off.

What you are seeing is that if you have kernel configuration that has 
livepatching (CONFIG_LIVEPATCH) turned off, the sample module doesn't 
compile for it either. I'd say it's not unexpected behavior.

-- 
Jiri Kosina
SUSE Labs

Re: Mistake in include IS_ENABLED(CONFIG_LIVEPATCH)

[Jiri Kosina]

On Sat, 11 Feb 2017, Denys Fedoryshchenko wrote:

> I noticed that sample of livepatch is not working in 4.9.9, because in
> include,
> linux/livepatch.h
> it is:
> #if IS_ENABLED(CONFIG_LIVEPATCH)
> 
> while config option is:
> CONFIG_HAVE_LIVEPATCH=y
> 
> After editing livepatch.h sample module compiles fine
> 
> Probably that's just a typo?

There are two config variables. CONFIG_HAVE_LIVEPATCH is set by those 
architectures for which livepatching implementation exists.

CONFIG_LIVEPATCH is the actual config option turning the support in kernel 
on/off.

What you are seeing is that if you have kernel configuration that has 
livepatching (CONFIG_LIVEPATCH) turned off, the sample module doesn't 
compile for it either. I'd say it's not unexpected behavior.

-- 
Jiri Kosina
SUSE Labs

Re: [PATCH] ASoC: fsl_sai: support more than 2 channels

[Nicolin Chen]

On Fri, Feb 10, 2017 at 07:42:43PM +0100, Alexandre Belloni wrote:
> The FSL SAI can support up to 32 channels using TDM. Report that value so
> they can actually be used.
> 
> Tested using 8 channels.
> 
> Signed-off-by: Alexandre Belloni 

Acked-by: Nicolin Chen 

> ---
>  sound/soc/fsl/fsl_sai.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c
> index 9fadf7e31c5f..18e5ce81527d 100644
> --- a/sound/soc/fsl/fsl_sai.c
> +++ b/sound/soc/fsl/fsl_sai.c
> @@ -668,7 +668,7 @@ static struct snd_soc_dai_driver fsl_sai_dai = {
>   .playback = {
>   .stream_name = "CPU-Playback",
>   .channels_min = 1,
> - .channels_max = 2,
> + .channels_max = 32,
>   .rate_min = 8000,
>   .rate_max = 192000,
>   .rates = SNDRV_PCM_RATE_KNOT,
> @@ -677,7 +677,7 @@ static struct snd_soc_dai_driver fsl_sai_dai = {
>   .capture = {
>   .stream_name = "CPU-Capture",
>   .channels_min = 1,
> - .channels_max = 2,
> + .channels_max = 32,
>   .rate_min = 8000,
>   .rate_max = 192000,
>   .rates = SNDRV_PCM_RATE_KNOT,
> -- 
> 2.11.0
> 

Re: [PATCH] ASoC: fsl_sai: support more than 2 channels

[Nicolin Chen]

On Fri, Feb 10, 2017 at 07:42:43PM +0100, Alexandre Belloni wrote:
> The FSL SAI can support up to 32 channels using TDM. Report that value so
> they can actually be used.
> 
> Tested using 8 channels.
> 
> Signed-off-by: Alexandre Belloni 

Acked-by: Nicolin Chen 

> ---
>  sound/soc/fsl/fsl_sai.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c
> index 9fadf7e31c5f..18e5ce81527d 100644
> --- a/sound/soc/fsl/fsl_sai.c
> +++ b/sound/soc/fsl/fsl_sai.c
> @@ -668,7 +668,7 @@ static struct snd_soc_dai_driver fsl_sai_dai = {
>   .playback = {
>   .stream_name = "CPU-Playback",
>   .channels_min = 1,
> - .channels_max = 2,
> + .channels_max = 32,
>   .rate_min = 8000,
>   .rate_max = 192000,
>   .rates = SNDRV_PCM_RATE_KNOT,
> @@ -677,7 +677,7 @@ static struct snd_soc_dai_driver fsl_sai_dai = {
>   .capture = {
>   .stream_name = "CPU-Capture",
>   .channels_min = 1,
> - .channels_max = 2,
> + .channels_max = 32,
>   .rate_min = 8000,
>   .rate_max = 192000,
>   .rates = SNDRV_PCM_RATE_KNOT,
> -- 
> 2.11.0
> 

Re: [PULL] IIO fixes for 4.10 set 3 - a couple of regression fixes.

[Greg Kroah-Hartman]

On Fri, Feb 10, 2017 at 11:35:35PM +0100, Peter Rosin wrote:
> > On Sun, Feb 05, 2017 at 10:35:02AM +, Jonathan Cameron wrote:
> >> The following changes since commit 
> >> 5c113b5e0082e90d2e1c7b12e96a7b8cf0623e27:
> >> 
> >>   iio: dht11: Use usleep_range instead of msleep for start signal 
> >> (2017-01-22 13:35:40 +)
> >> 
> >> are available in the git repository at:
> >> 
> >>   git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git 
> >> tags/iio-fixes-for-4.10c
> > 
> > It's a bit late for 4.10 for me, can I just pull this into my -next
> > branch and will they get to 4.10.1 properly?  Meaning, do that have cc:
> > stable markings on them?  Or do you want to fix that up and resend this
> > request?
> 
> Hi Greg,
> 
> You should ask Ken Lin who has the HW and who is apparently affected.
> I think it's bad that you are willing to have a known regression hit
> v4.10 when all was fine in v4.9. Or perhaps you didn't realize that
> the regression was from this cycle?
> 
> The fixes are obvious. I don't understand your hesitation.

My "hesitation" is that I'm about to get on a plane for a day or so and
don't have the time to get this to Linus before 4.10-final is out this
Sunday.  Getting it in a week later should be ok, we all make mistakes,
as long as we fix them it's all good, and for 4.10.1 should be ok.

thanks,

greg k-h

Re: [PULL] IIO fixes for 4.10 set 3 - a couple of regression fixes.

[Greg Kroah-Hartman]

On Fri, Feb 10, 2017 at 11:35:35PM +0100, Peter Rosin wrote:
> > On Sun, Feb 05, 2017 at 10:35:02AM +, Jonathan Cameron wrote:
> >> The following changes since commit 
> >> 5c113b5e0082e90d2e1c7b12e96a7b8cf0623e27:
> >> 
> >>   iio: dht11: Use usleep_range instead of msleep for start signal 
> >> (2017-01-22 13:35:40 +)
> >> 
> >> are available in the git repository at:
> >> 
> >>   git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git 
> >> tags/iio-fixes-for-4.10c
> > 
> > It's a bit late for 4.10 for me, can I just pull this into my -next
> > branch and will they get to 4.10.1 properly?  Meaning, do that have cc:
> > stable markings on them?  Or do you want to fix that up and resend this
> > request?
> 
> Hi Greg,
> 
> You should ask Ken Lin who has the HW and who is apparently affected.
> I think it's bad that you are willing to have a known regression hit
> v4.10 when all was fine in v4.9. Or perhaps you didn't realize that
> the regression was from this cycle?
> 
> The fixes are obvious. I don't understand your hesitation.

My "hesitation" is that I'm about to get on a plane for a day or so and
don't have the time to get this to Linus before 4.10-final is out this
Sunday.  Getting it in a week later should be ok, we all make mistakes,
as long as we fix them it's all good, and for 4.10.1 should be ok.

thanks,

greg k-h

Re: [PATCH] device-dax: don't set kobj parent during cdev init

[Greg Kroah-Hartman]

On Fri, Feb 10, 2017 at 02:25:35PM -0800, Dan Williams wrote:
> On Fri, Feb 10, 2017 at 12:17 PM, Greg Kroah-Hartman
>  wrote:
> > On Fri, Feb 10, 2017 at 11:41:20AM -0800, Dan Williams wrote:
> >> On Fri, Feb 10, 2017 at 11:19 AM, Logan Gunthorpe  
> >> wrote:
> >> > I copied this code and per feedback from Greg Kroah-Hartman [1] the
> >> > cdev's kobject's parent should not be set to the related device.
> >> > This should have minor consequences but isn't doing what anyone
> >> > expects it to.
> >> >
> >> > This patch then fixes device-dax so it doesn't make the same mistake.
> >> >
> >> > [1] https://lkml.org/lkml/2017/2/10/370
> >> >
> >> > Signed-off-by: Logan Gunthorpe 
> >>
> >> Thanks for following up with this fix, but this causes a
> >> use-after-free regression:
> >>
> >>  general protection fault:  [#1] SMP DEBUG_PAGEALLOC
> >>  [..]
> >>  Call Trace:
> >>   vsnprintf+0x2d7/0x500
> >>   snprintf+0x49/0x60
> >>   dev_vprintk_emit+0x68/0x230
> >>   ? debug_lockdep_rcu_enabled+0x1d/0x20
> >>   ? trace_hardirqs_off+0xd/0x10
> >>   ? cmpxchg_double_slab.isra.70+0x15a/0x1c0
> >>   ? __slab_free+0x134/0x290
> >>   dev_printk_emit+0x4e/0x70
> >>   __dynamic_dev_dbg+0xc8/0x110
> >>   ? __lock_acquire+0x33d/0x1290
> >>   dax_dev_huge_fault+0xee/0x570 [dax]
> >>   __handle_mm_fault+0x5aa/0x10a0
> >>   handle_mm_fault+0x154/0x350
> >>   ? handle_mm_fault+0x3c/0x350
> >>   __do_page_fault+0x26b/0x4c0
> >>   trace_do_page_fault+0x58/0x270
> >>   do_async_page_fault+0x1a/0xa0
> >>   async_page_fault+0x28/0x30
> >>
> >> I added this reference explicitly so the parent struct device has the
> >> correct lifetime after this feedback from Al.
> >>
> >>https://lists.01.org/pipermail/linux-nvdimm/2016-August/006563.html
> >>
> >> ...so I'm wondering what the actual problem is with setting cdev->parent?
> >
> > It shouldn't do anything at all.  The kobject in a cdev isn't a "normal"
> > kobject, it doesn't show up in sysfs, or anywhere else.  It's used for
> > an internal representation to the cdev code (a kmap) to look up the
> > object to call when userspace opens the device node in a quick manner.
> >
> > Now changing from initialize/add to just register, does do different
> > things, perhaps that is the issue here.  Just try removing the
> > cdev->kobject parent stuff and see if that causes a problem or not.
> >
> 
>  That doesn't help.  I rely on the "kobject_get(p->kobj.parent);" in
> cdev_add() to pin my device and cdev_default_release() to free it.

"pin it" where?  Why do you need this?  That feels really "odd" to me...

Re: [PATCH] device-dax: don't set kobj parent during cdev init

[Greg Kroah-Hartman]

On Fri, Feb 10, 2017 at 02:25:35PM -0800, Dan Williams wrote:
> On Fri, Feb 10, 2017 at 12:17 PM, Greg Kroah-Hartman
>  wrote:
> > On Fri, Feb 10, 2017 at 11:41:20AM -0800, Dan Williams wrote:
> >> On Fri, Feb 10, 2017 at 11:19 AM, Logan Gunthorpe  
> >> wrote:
> >> > I copied this code and per feedback from Greg Kroah-Hartman [1] the
> >> > cdev's kobject's parent should not be set to the related device.
> >> > This should have minor consequences but isn't doing what anyone
> >> > expects it to.
> >> >
> >> > This patch then fixes device-dax so it doesn't make the same mistake.
> >> >
> >> > [1] https://lkml.org/lkml/2017/2/10/370
> >> >
> >> > Signed-off-by: Logan Gunthorpe 
> >>
> >> Thanks for following up with this fix, but this causes a
> >> use-after-free regression:
> >>
> >>  general protection fault:  [#1] SMP DEBUG_PAGEALLOC
> >>  [..]
> >>  Call Trace:
> >>   vsnprintf+0x2d7/0x500
> >>   snprintf+0x49/0x60
> >>   dev_vprintk_emit+0x68/0x230
> >>   ? debug_lockdep_rcu_enabled+0x1d/0x20
> >>   ? trace_hardirqs_off+0xd/0x10
> >>   ? cmpxchg_double_slab.isra.70+0x15a/0x1c0
> >>   ? __slab_free+0x134/0x290
> >>   dev_printk_emit+0x4e/0x70
> >>   __dynamic_dev_dbg+0xc8/0x110
> >>   ? __lock_acquire+0x33d/0x1290
> >>   dax_dev_huge_fault+0xee/0x570 [dax]
> >>   __handle_mm_fault+0x5aa/0x10a0
> >>   handle_mm_fault+0x154/0x350
> >>   ? handle_mm_fault+0x3c/0x350
> >>   __do_page_fault+0x26b/0x4c0
> >>   trace_do_page_fault+0x58/0x270
> >>   do_async_page_fault+0x1a/0xa0
> >>   async_page_fault+0x28/0x30
> >>
> >> I added this reference explicitly so the parent struct device has the
> >> correct lifetime after this feedback from Al.
> >>
> >>https://lists.01.org/pipermail/linux-nvdimm/2016-August/006563.html
> >>
> >> ...so I'm wondering what the actual problem is with setting cdev->parent?
> >
> > It shouldn't do anything at all.  The kobject in a cdev isn't a "normal"
> > kobject, it doesn't show up in sysfs, or anywhere else.  It's used for
> > an internal representation to the cdev code (a kmap) to look up the
> > object to call when userspace opens the device node in a quick manner.
> >
> > Now changing from initialize/add to just register, does do different
> > things, perhaps that is the issue here.  Just try removing the
> > cdev->kobject parent stuff and see if that causes a problem or not.
> >
> 
>  That doesn't help.  I rely on the "kobject_get(p->kobj.parent);" in
> cdev_add() to pin my device and cdev_default_release() to free it.

"pin it" where?  Why do you need this?  That feels really "odd" to me...

Re: [PATCH 2/2] sched/deadline: Throttle a constrained deadline task activated after the deadline

[luca abeni]

Hi Daniel,

On Fri, 10 Feb 2017 20:48:11 +0100
Daniel Bristot de Oliveira  wrote:

> During the activation, CBS checks if it can reuse the current task's
> runtime and period. If the deadline of the task is in the past, CBS
> cannot use the runtime, and so it replenishes the task. This rule
> works fine for implicit deadline tasks (deadline == period), and the
> CBS was designed for implicit deadline tasks. However, a task with
> constrained deadline (deadine < period) might be awakened after the
> deadline, but before the next period. In this case, replenishing the
> task would allow it to run for runtime / deadline. As in this case
> deadline < period, CBS enables a task to run for more than the
> runtime/period. In a very load system, this can cause the domino
> effect, making other tasks to miss their deadlines.

I think you are right: SCHED_DEADLINE implements the original CBS
algorithm here, but uses relative deadlines different from periods in
other places (while the original algorithm only considered relative
deadlines equal to periods).
An this mix is dangerous... I think your fix is correct, and cures a
real problem.



Thanks,
Luca


> 
> To avoid this problem, in the activation of a constrained deadline
> task after the deadline but before the next period, throttle the
> task and set the replenishing timer to the begin of the next period,
> unless it is boosted.
> 
> Reproducer:
> 
>  --- %< ---
>   int main (int argc, char **argv)
>   {
>   int ret;
>   int flags = 0;
>   unsigned long l = 0;
>   struct timespec ts;
>   struct sched_attr attr;
> 
>   memset(, 0, sizeof(attr));
>   attr.size = sizeof(attr);
> 
>   attr.sched_policy   = SCHED_DEADLINE;
>   attr.sched_runtime  = 2 * 1000 * 1000;  /* 2 ms
> */ attr.sched_deadline = 2 * 1000 * 1000; /* 2 ms */
>   attr.sched_period   = 2 * 1000 * 1000 * 1000;   /* 2 s */
> 
>   ts.tv_sec = 0;
>   ts.tv_nsec = 2000 * 1000;   /* 2 ms */
> 
>   ret = sched_setattr(0, , flags);
> 
>   if (ret < 0) {
>   perror("sched_setattr");
>   exit(-1);
>   }
> 
>   for(;;) {
>   /* XXX: you may need to adjust the loop */
>   for (l = 0; l < 15; l++);
>   /*
>* The ideia is to go to sleep right before the
> deadline
>* and then wake up before the next period to receive
>* a new replenishment.
>*/
>   nanosleep(, NULL);
>   }
> 
>   exit(0);
>   }
>   --- >% ---  
> 
> On my box, this reproducer uses almost 50% of the CPU time, which is
> obviously wrong for a task with 2/2000 reservation.
> 
> Signed-off-by: Daniel Bristot de Oliveira 
> Cc: Ingo Molnar 
> Cc: Peter Zijlstra 
> Cc: Juri Lelli 
> Cc: Tommaso Cucinotta 
> Cc: Luca Abeni 
> Cc: Steven Rostedt 
> Cc: linux-kernel@vger.kernel.org
> ---
>  kernel/sched/deadline.c | 44
>  1 file changed, 44
> insertions(+)
> 
> diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
> index 3c94d85..b74d40e 100644
> --- a/kernel/sched/deadline.c
> +++ b/kernel/sched/deadline.c
> @@ -694,6 +694,36 @@ void init_dl_task_timer(struct sched_dl_entity
> *dl_se) timer->function = dl_task_timer;
>  }
>  
> +/* During the activation, CBS checks if it can reuse the current
> task's
> + * runtime and period. If the deadline of the task is in the past,
> CBS
> + * cannot use the runtime, and so it replenishes the task. This rule
> + * works fine for implicit deadline tasks (deadline == period), and
> the
> + * CBS was designed for implicit deadline tasks. However, a task with
> + * constrained deadline (deadine < period) might be awakened after
> the
> + * deadline, but before the next period. In this case, replenishing
> the
> + * task would allow it to run for runtime / deadline. As in this case
> + * deadline < period, CBS enables a task to run for more than the
> + * runtime / period. In a very load system, this can cause the domino
> + * effect, making other tasks to miss their deadlines.
> + *
> + * To avoid this problem, in the activation of a constrained deadline
> + * task after the deadline but before the next period, throttle the
> + * task and set the replenishing timer to the begin of the next
> period,
> + * unless it is boosted.
> + */
> +static inline void dl_check_constrained_dl(struct sched_dl_entity
> *dl_se) +{
> + struct task_struct *p = dl_task_of(dl_se);
> + struct rq *rq = rq_of_dl_rq(dl_rq_of_se(dl_se));
> +
> + if (dl_time_before(dl_se->deadline, rq_clock(rq)) &&
> + dl_time_before(rq_clock(rq), 

Re: [PATCH 2/2] sched/deadline: Throttle a constrained deadline task activated after the deadline

[luca abeni]

Hi Daniel,

On Fri, 10 Feb 2017 20:48:11 +0100
Daniel Bristot de Oliveira  wrote:

> During the activation, CBS checks if it can reuse the current task's
> runtime and period. If the deadline of the task is in the past, CBS
> cannot use the runtime, and so it replenishes the task. This rule
> works fine for implicit deadline tasks (deadline == period), and the
> CBS was designed for implicit deadline tasks. However, a task with
> constrained deadline (deadine < period) might be awakened after the
> deadline, but before the next period. In this case, replenishing the
> task would allow it to run for runtime / deadline. As in this case
> deadline < period, CBS enables a task to run for more than the
> runtime/period. In a very load system, this can cause the domino
> effect, making other tasks to miss their deadlines.

I think you are right: SCHED_DEADLINE implements the original CBS
algorithm here, but uses relative deadlines different from periods in
other places (while the original algorithm only considered relative
deadlines equal to periods).
An this mix is dangerous... I think your fix is correct, and cures a
real problem.



Thanks,
Luca


> 
> To avoid this problem, in the activation of a constrained deadline
> task after the deadline but before the next period, throttle the
> task and set the replenishing timer to the begin of the next period,
> unless it is boosted.
> 
> Reproducer:
> 
>  --- %< ---
>   int main (int argc, char **argv)
>   {
>   int ret;
>   int flags = 0;
>   unsigned long l = 0;
>   struct timespec ts;
>   struct sched_attr attr;
> 
>   memset(, 0, sizeof(attr));
>   attr.size = sizeof(attr);
> 
>   attr.sched_policy   = SCHED_DEADLINE;
>   attr.sched_runtime  = 2 * 1000 * 1000;  /* 2 ms
> */ attr.sched_deadline = 2 * 1000 * 1000; /* 2 ms */
>   attr.sched_period   = 2 * 1000 * 1000 * 1000;   /* 2 s */
> 
>   ts.tv_sec = 0;
>   ts.tv_nsec = 2000 * 1000;   /* 2 ms */
> 
>   ret = sched_setattr(0, , flags);
> 
>   if (ret < 0) {
>   perror("sched_setattr");
>   exit(-1);
>   }
> 
>   for(;;) {
>   /* XXX: you may need to adjust the loop */
>   for (l = 0; l < 15; l++);
>   /*
>* The ideia is to go to sleep right before the
> deadline
>* and then wake up before the next period to receive
>* a new replenishment.
>*/
>   nanosleep(, NULL);
>   }
> 
>   exit(0);
>   }
>   --- >% ---  
> 
> On my box, this reproducer uses almost 50% of the CPU time, which is
> obviously wrong for a task with 2/2000 reservation.
> 
> Signed-off-by: Daniel Bristot de Oliveira 
> Cc: Ingo Molnar 
> Cc: Peter Zijlstra 
> Cc: Juri Lelli 
> Cc: Tommaso Cucinotta 
> Cc: Luca Abeni 
> Cc: Steven Rostedt 
> Cc: linux-kernel@vger.kernel.org
> ---
>  kernel/sched/deadline.c | 44
>  1 file changed, 44
> insertions(+)
> 
> diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
> index 3c94d85..b74d40e 100644
> --- a/kernel/sched/deadline.c
> +++ b/kernel/sched/deadline.c
> @@ -694,6 +694,36 @@ void init_dl_task_timer(struct sched_dl_entity
> *dl_se) timer->function = dl_task_timer;
>  }
>  
> +/* During the activation, CBS checks if it can reuse the current
> task's
> + * runtime and period. If the deadline of the task is in the past,
> CBS
> + * cannot use the runtime, and so it replenishes the task. This rule
> + * works fine for implicit deadline tasks (deadline == period), and
> the
> + * CBS was designed for implicit deadline tasks. However, a task with
> + * constrained deadline (deadine < period) might be awakened after
> the
> + * deadline, but before the next period. In this case, replenishing
> the
> + * task would allow it to run for runtime / deadline. As in this case
> + * deadline < period, CBS enables a task to run for more than the
> + * runtime / period. In a very load system, this can cause the domino
> + * effect, making other tasks to miss their deadlines.
> + *
> + * To avoid this problem, in the activation of a constrained deadline
> + * task after the deadline but before the next period, throttle the
> + * task and set the replenishing timer to the begin of the next
> period,
> + * unless it is boosted.
> + */
> +static inline void dl_check_constrained_dl(struct sched_dl_entity
> *dl_se) +{
> + struct task_struct *p = dl_task_of(dl_se);
> + struct rq *rq = rq_of_dl_rq(dl_rq_of_se(dl_se));
> +
> + if (dl_time_before(dl_se->deadline, rq_clock(rq)) &&
> + dl_time_before(rq_clock(rq), dl_next_period(dl_se))) {
> + if (unlikely(dl_se->dl_boosted
> || !start_dl_timer(p)))
> + return;
> + dl_se->dl_throttled = 1;
> + }
> +}
> +
>  

Re: [PATCH 1/2] sched/deadline: Replenishment timer should fire in the next period

[luca abeni]

Hi Daniel,

On Fri, 10 Feb 2017 20:48:10 +0100
Daniel Bristot de Oliveira  wrote:

[...]
> diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
> index 70ef2b1..3c94d85 100644
> --- a/kernel/sched/deadline.c
> +++ b/kernel/sched/deadline.c
> @@ -505,10 +505,15 @@ static void update_dl_entity(struct
> sched_dl_entity *dl_se, }
>  }
>  
> +static inline u64 dl_next_period(struct sched_dl_entity *dl_se)
> +{
> + return dl_se->deadline - dl_se->dl_deadline +
> dl_se->dl_period; +}
> +
>  /*
>   * If the entity depleted all its runtime, and if we want it to sleep
>   * while waiting for some new execution time to become available, we
> - * set the bandwidth enforcement timer to the replenishment instant
> + * set the bandwidth replenishment timer to the replenishment instant
>   * and try to activate it.
>   *
>   * Notice that it is important for the caller to know if the timer
> @@ -530,7 +535,7 @@ static int start_dl_timer(struct task_struct *p)
>* that it is actually coming from rq->clock and not from
>* hrtimer's time base reading.
>*/
> - act = ns_to_ktime(dl_se->deadline);
> + act = ns_to_ktime(dl_next_period(dl_se));

Looks like there is a real bug in the code, and your fix looks correct
to me. I think it should be committed.


Thanks,
Luca


>   now = hrtimer_cb_get_time(timer);
>   delta = ktime_to_ns(now) - rq_clock(rq);
>   act = ktime_add_ns(act, delta);

Re: [GIT PULL] PCI fixes for v4.10

[Yinghai Lu]

On Fri, Feb 10, 2017 at 6:39 PM, Yinghai Lu  wrote:
> Ashok,
>
> Can ask your QA guys check only attached patch and commit 68db9bc ?

more clean patches: split that into two small patches.

Thanks

Yinghai
From 68db9bc814362e7f24371c27d12a4f34477d9356 Mon Sep 17 00:00:00 2001
From: Lukas Wunner 
Date: Fri, 28 Oct 2016 10:52:06 +0200
Subject: PCI: pciehp: Add runtime PM support for PCIe hotplug ports

Linux 4.8 added support for runtime suspending PCIe ports to D3hot with
commit 006d44e49a25 ("PCI: Add runtime PM support for PCIe ports"), but
excluded hotplug ports.  Those are now afforded runtime PM by the present
commit.

Hotplug ports require a few extra considerations:

- The configuration space of the port remains accessible in D3hot, so all
  the functions to read or modify the Slot Status and Slot Control
  registers need not be modified.  Even turning on slot power doesn't seem
  to require the port to be in D0, at least the PCIe spec doesn't say so
  and I confirmed that by testing with a Thunderbolt controller.

- However D0 is required to access devices on the secondary bus.  This
  happens in pciehp_check_link_status() and pciehp_configure_device() (both
  called from board_added()) and in pciehp_unconfigure_device() (called
  from remove_board()), so acquire a runtime PM ref for their invocation.

- The hotplug port stays active as long as it has active children.  If all
  hotplugged devices below the port runtime suspend, the port is allowed to
  runtime suspend as well.  Plug and unplug detection continues to work in
  D3hot.

- Hotplug interrupts are delivered in-band, so while the hotplug port
  itself is allowed to go to D3hot, its parent ports must stay in D0 for
  interrupts to come through.  Add a corresponding restriction to
  pci_dev_check_d3cold().

- Runtime PM may only be allowed if the hotplug port is handled natively by
  the OS.  On ACPI systems, the port may alternatively be handled by the
  firmware and things break if the OS puts the port into D3 behind the
  firmware's back:  E.g. Thunderbolt hotplug ports on non-Macs are handled
  by Intel's firmware in System Management Mode and the firmware is known
  to access devices on the port's secondary bus without checking first if
  the port is in D0: https://bugzilla.kernel.org/show_bug.cgi?id=53811

Signed-off-by: Lukas Wunner 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Rafael J. Wysocki 
CC: Mika Westerberg 

diff --git a/drivers/pci/hotplug/pciehp_ctrl.c b/drivers/pci/hotplug/pciehp_ctrl.c
index efe69e8..ffd3fe6 100644
--- a/drivers/pci/hotplug/pciehp_ctrl.c
+++ b/drivers/pci/hotplug/pciehp_ctrl.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include "../pci.h"
 #include "pciehp.h"
@@ -98,6 +99,7 @@ static int board_added(struct slot *p_slot)
 	pciehp_green_led_blink(p_slot);
 
 	/* Check link training status */
+	pm_runtime_get_sync(>pcie->port->dev);
 	retval = pciehp_check_link_status(ctrl);
 	if (retval) {
 		ctrl_err(ctrl, "Failed to check link status\n");
@@ -118,12 +120,14 @@ static int board_added(struct slot *p_slot)
 		if (retval != -EEXIST)
 			goto err_exit;
 	}
+	pm_runtime_put(>pcie->port->dev);
 
 	pciehp_green_led_on(p_slot);
 	pciehp_set_attention_status(p_slot, 0);
 	return 0;
 
 err_exit:
+	pm_runtime_put(>pcie->port->dev);
 	set_slot_off(ctrl, p_slot);
 	return retval;
 }
@@ -137,7 +141,9 @@ static int remove_board(struct slot *p_slot)
 	int retval;
 	struct controller *ctrl = p_slot->ctrl;
 
+	pm_runtime_get_sync(>pcie->port->dev);
 	retval = pciehp_unconfigure_device(p_slot);
+	pm_runtime_put(>pcie->port->dev);
 	if (retval)
 		return retval;
 
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index d86351a..1eb622c 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -2245,13 +2245,10 @@ bool pci_bridge_d3_possible(struct pci_dev *bridge)
 			return false;
 
 		/*
-		 * Hotplug interrupts cannot be delivered if the link is down,
-		 * so parents of a hotplug port must stay awake. In addition,
-		 * hotplug ports handled by firmware in System Management Mode
+		 * Hotplug ports handled by firmware in System Management Mode
 		 * may not be put into D3 by the OS (Thunderbolt on non-Macs).
-		 * For simplicity, disallow in general for now.
 		 */
-		if (bridge->is_hotplug_bridge)
+		if (bridge->is_hotplug_bridge && !pciehp_is_native(bridge))
 			return false;
 
 		if (pci_bridge_d3_force)
@@ -2283,7 +2280,10 @@ static int pci_dev_check_d3cold(struct pci_dev *dev, void *data)
 	 !pci_pme_capable(dev, PCI_D3cold)) ||
 
 	/* If it is a bridge it must be allowed to go to D3. */
-	!pci_power_manageable(dev))
+	!pci_power_manageable(dev) ||
+
+	/* Hotplug interrupts cannot be delivered if the link is down. */
+	dev->is_hotplug_bridge)
 
 		*d3cold_ok = false;
 
Subject: [PATCH] PCI, pciehp: clean and reuse set_slot_off

Re: [PATCH 1/2] sched/deadline: Replenishment timer should fire in the next period

[luca abeni]

Hi Daniel,

On Fri, 10 Feb 2017 20:48:10 +0100
Daniel Bristot de Oliveira  wrote:

[...]
> diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
> index 70ef2b1..3c94d85 100644
> --- a/kernel/sched/deadline.c
> +++ b/kernel/sched/deadline.c
> @@ -505,10 +505,15 @@ static void update_dl_entity(struct
> sched_dl_entity *dl_se, }
>  }
>  
> +static inline u64 dl_next_period(struct sched_dl_entity *dl_se)
> +{
> + return dl_se->deadline - dl_se->dl_deadline +
> dl_se->dl_period; +}
> +
>  /*
>   * If the entity depleted all its runtime, and if we want it to sleep
>   * while waiting for some new execution time to become available, we
> - * set the bandwidth enforcement timer to the replenishment instant
> + * set the bandwidth replenishment timer to the replenishment instant
>   * and try to activate it.
>   *
>   * Notice that it is important for the caller to know if the timer
> @@ -530,7 +535,7 @@ static int start_dl_timer(struct task_struct *p)
>* that it is actually coming from rq->clock and not from
>* hrtimer's time base reading.
>*/
> - act = ns_to_ktime(dl_se->deadline);
> + act = ns_to_ktime(dl_next_period(dl_se));

Looks like there is a real bug in the code, and your fix looks correct
to me. I think it should be committed.


Thanks,
Luca


>   now = hrtimer_cb_get_time(timer);
>   delta = ktime_to_ns(now) - rq_clock(rq);
>   act = ktime_add_ns(act, delta);

Re: [GIT PULL] PCI fixes for v4.10

[Yinghai Lu]

On Fri, Feb 10, 2017 at 6:39 PM, Yinghai Lu  wrote:
> Ashok,
>
> Can ask your QA guys check only attached patch and commit 68db9bc ?

more clean patches: split that into two small patches.

Thanks

Yinghai
From 68db9bc814362e7f24371c27d12a4f34477d9356 Mon Sep 17 00:00:00 2001
From: Lukas Wunner 
Date: Fri, 28 Oct 2016 10:52:06 +0200
Subject: PCI: pciehp: Add runtime PM support for PCIe hotplug ports

Linux 4.8 added support for runtime suspending PCIe ports to D3hot with
commit 006d44e49a25 ("PCI: Add runtime PM support for PCIe ports"), but
excluded hotplug ports.  Those are now afforded runtime PM by the present
commit.

Hotplug ports require a few extra considerations:

- The configuration space of the port remains accessible in D3hot, so all
  the functions to read or modify the Slot Status and Slot Control
  registers need not be modified.  Even turning on slot power doesn't seem
  to require the port to be in D0, at least the PCIe spec doesn't say so
  and I confirmed that by testing with a Thunderbolt controller.

- However D0 is required to access devices on the secondary bus.  This
  happens in pciehp_check_link_status() and pciehp_configure_device() (both
  called from board_added()) and in pciehp_unconfigure_device() (called
  from remove_board()), so acquire a runtime PM ref for their invocation.

- The hotplug port stays active as long as it has active children.  If all
  hotplugged devices below the port runtime suspend, the port is allowed to
  runtime suspend as well.  Plug and unplug detection continues to work in
  D3hot.

- Hotplug interrupts are delivered in-band, so while the hotplug port
  itself is allowed to go to D3hot, its parent ports must stay in D0 for
  interrupts to come through.  Add a corresponding restriction to
  pci_dev_check_d3cold().

- Runtime PM may only be allowed if the hotplug port is handled natively by
  the OS.  On ACPI systems, the port may alternatively be handled by the
  firmware and things break if the OS puts the port into D3 behind the
  firmware's back:  E.g. Thunderbolt hotplug ports on non-Macs are handled
  by Intel's firmware in System Management Mode and the firmware is known
  to access devices on the port's secondary bus without checking first if
  the port is in D0: https://bugzilla.kernel.org/show_bug.cgi?id=53811

Signed-off-by: Lukas Wunner 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Rafael J. Wysocki 
CC: Mika Westerberg 

diff --git a/drivers/pci/hotplug/pciehp_ctrl.c b/drivers/pci/hotplug/pciehp_ctrl.c
index efe69e8..ffd3fe6 100644
--- a/drivers/pci/hotplug/pciehp_ctrl.c
+++ b/drivers/pci/hotplug/pciehp_ctrl.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include "../pci.h"
 #include "pciehp.h"
@@ -98,6 +99,7 @@ static int board_added(struct slot *p_slot)
 	pciehp_green_led_blink(p_slot);
 
 	/* Check link training status */
+	pm_runtime_get_sync(>pcie->port->dev);
 	retval = pciehp_check_link_status(ctrl);
 	if (retval) {
 		ctrl_err(ctrl, "Failed to check link status\n");
@@ -118,12 +120,14 @@ static int board_added(struct slot *p_slot)
 		if (retval != -EEXIST)
 			goto err_exit;
 	}
+	pm_runtime_put(>pcie->port->dev);
 
 	pciehp_green_led_on(p_slot);
 	pciehp_set_attention_status(p_slot, 0);
 	return 0;
 
 err_exit:
+	pm_runtime_put(>pcie->port->dev);
 	set_slot_off(ctrl, p_slot);
 	return retval;
 }
@@ -137,7 +141,9 @@ static int remove_board(struct slot *p_slot)
 	int retval;
 	struct controller *ctrl = p_slot->ctrl;
 
+	pm_runtime_get_sync(>pcie->port->dev);
 	retval = pciehp_unconfigure_device(p_slot);
+	pm_runtime_put(>pcie->port->dev);
 	if (retval)
 		return retval;
 
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index d86351a..1eb622c 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -2245,13 +2245,10 @@ bool pci_bridge_d3_possible(struct pci_dev *bridge)
 			return false;
 
 		/*
-		 * Hotplug interrupts cannot be delivered if the link is down,
-		 * so parents of a hotplug port must stay awake. In addition,
-		 * hotplug ports handled by firmware in System Management Mode
+		 * Hotplug ports handled by firmware in System Management Mode
 		 * may not be put into D3 by the OS (Thunderbolt on non-Macs).
-		 * For simplicity, disallow in general for now.
 		 */
-		if (bridge->is_hotplug_bridge)
+		if (bridge->is_hotplug_bridge && !pciehp_is_native(bridge))
 			return false;
 
 		if (pci_bridge_d3_force)
@@ -2283,7 +2280,10 @@ static int pci_dev_check_d3cold(struct pci_dev *dev, void *data)
 	 !pci_pme_capable(dev, PCI_D3cold)) ||
 
 	/* If it is a bridge it must be allowed to go to D3. */
-	!pci_power_manageable(dev))
+	!pci_power_manageable(dev) ||
+
+	/* Hotplug interrupts cannot be delivered if the link is down. */
+	dev->is_hotplug_bridge)
 
 		*d3cold_ok = false;
 
Subject: [PATCH] PCI, pciehp: clean and reuse set_slot_off

Move out led setting, and reuse it in remove_board.

Signed-off-by: Yinghai Lu 

---
 drivers/pci/hotplug/pciehp_ctrl.c |   19 

[PATCH] HID: intel-ish-hid: constify device_type structure

[Bhumika Goyal]

Declare device_type structure as const as it is only stored in the
type field of a device structure. This field is of type const, so add
const to the declaration of device_type structure.

File size before: drivers/hid/intel-ish-hid/ishtp/bus.o
   textdata bss dec hex filename
   4260 336  1646121204 hid/intel-ish-hid/ishtp/bus.o

File size after: drivers/hid/intel-ish-hid/ishtp/bus.o
   textdata bss dec hex filename
   4324 272  1646121204 hid/intel-ish-hid/ishtp/bus.o

Signed-off-by: Bhumika Goyal 
---
 drivers/hid/intel-ish-hid/ishtp/bus.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hid/intel-ish-hid/ishtp/bus.c 
b/drivers/hid/intel-ish-hid/ishtp/bus.c
index f4cbc74..5f382fe 100644
--- a/drivers/hid/intel-ish-hid/ishtp/bus.c
+++ b/drivers/hid/intel-ish-hid/ishtp/bus.c
@@ -358,7 +358,7 @@ static void ishtp_cl_dev_release(struct device *dev)
kfree(to_ishtp_cl_device(dev));
 }
 
-static struct device_type ishtp_cl_device_type = {
+static const struct device_type ishtp_cl_device_type = {
.release= ishtp_cl_dev_release,
 };
 
-- 
1.9.1

[PATCH] HID: intel-ish-hid: constify device_type structure

[Bhumika Goyal]

Declare device_type structure as const as it is only stored in the
type field of a device structure. This field is of type const, so add
const to the declaration of device_type structure.

File size before: drivers/hid/intel-ish-hid/ishtp/bus.o
   textdata bss dec hex filename
   4260 336  1646121204 hid/intel-ish-hid/ishtp/bus.o

File size after: drivers/hid/intel-ish-hid/ishtp/bus.o
   textdata bss dec hex filename
   4324 272  1646121204 hid/intel-ish-hid/ishtp/bus.o

Signed-off-by: Bhumika Goyal 
---
 drivers/hid/intel-ish-hid/ishtp/bus.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hid/intel-ish-hid/ishtp/bus.c 
b/drivers/hid/intel-ish-hid/ishtp/bus.c
index f4cbc74..5f382fe 100644
--- a/drivers/hid/intel-ish-hid/ishtp/bus.c
+++ b/drivers/hid/intel-ish-hid/ishtp/bus.c
@@ -358,7 +358,7 @@ static void ishtp_cl_dev_release(struct device *dev)
kfree(to_ishtp_cl_device(dev));
 }
 
-static struct device_type ishtp_cl_device_type = {
+static const struct device_type ishtp_cl_device_type = {
.release= ishtp_cl_dev_release,
 };
 
-- 
1.9.1

Re: [PATCH] staging: rtl8192u: Fix brace placement

[Greg KH]

On Sat, Feb 11, 2017 at 10:46:27AM +0530, simran singhal wrote:
> Fix brace placement errors caught by checkpatch.pl ERROR: that open
> brace { should be on the previous line
> 
> Signed-off-by: simran singhal 
> ---
>  .../staging/rtl8192u/ieee80211/rtl819x_BAProc.c| 90 
> --
>  1 file changed, 30 insertions(+), 60 deletions(-)

Hi,

This is the friendly patch-bot of Greg Kroah-Hartman.  You have sent him
a patch that has triggered this response.  He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created.  Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.

You are receiving this message because of the following common error(s)
as indicated below:

- You sent multiple patches, yet no indication of which ones should be
  applied in which order.  Greg could just guess, but if you are
  receiving this email, he guessed wrong and the patches didn't apply.
  Please read the section entitled "The canonical patch format" in the
  kernel file, Documentation/SubmittingPatches for a description of how
  to do this so that Greg has a chance to apply these correctly.

If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.

thanks,

greg k-h's patch email bot

Re: [PATCH] staging: rtl8192u: Fix brace placement

[Greg KH]

On Sat, Feb 11, 2017 at 10:46:27AM +0530, simran singhal wrote:
> Fix brace placement errors caught by checkpatch.pl ERROR: that open
> brace { should be on the previous line
> 
> Signed-off-by: simran singhal 
> ---
>  .../staging/rtl8192u/ieee80211/rtl819x_BAProc.c| 90 
> --
>  1 file changed, 30 insertions(+), 60 deletions(-)

Hi,

This is the friendly patch-bot of Greg Kroah-Hartman.  You have sent him
a patch that has triggered this response.  He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created.  Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.

You are receiving this message because of the following common error(s)
as indicated below:

- You sent multiple patches, yet no indication of which ones should be
  applied in which order.  Greg could just guess, but if you are
  receiving this email, he guessed wrong and the patches didn't apply.
  Please read the section entitled "The canonical patch format" in the
  kernel file, Documentation/SubmittingPatches for a description of how
  to do this so that Greg has a chance to apply these correctly.

If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.

thanks,

greg k-h's patch email bot

Re: [PATCH] staging: rtl8192u: Removing multiple blank lines

[Greg KH]

On Sat, Feb 11, 2017 at 09:34:12AM +0530, SIMRAN SINGHAL wrote:
> Multiple patches ...?

You sent me lots of patches, how am I supposed to know which one to
apply in what order?

> Can you please clarify what all patches you are including in "Multiple 
> Patches".

Everything you have sent me.

> And the Order you should go for is the order in which I submitted them.

Email does not guarantee "in order" delivery at all.  And how do you
know how my emails are sorted?  That is why you are supposed to number
your patches.  Please read Documentation/SubmittingPatches for how to do
this properly.

thanks,

greg k-h

Re: [PATCH] staging: rtl8192u: Removing multiple blank lines

[Greg KH]

On Sat, Feb 11, 2017 at 09:34:12AM +0530, SIMRAN SINGHAL wrote:
> Multiple patches ...?

You sent me lots of patches, how am I supposed to know which one to
apply in what order?

> Can you please clarify what all patches you are including in "Multiple 
> Patches".

Everything you have sent me.

> And the Order you should go for is the order in which I submitted them.

Email does not guarantee "in order" delivery at all.  And how do you
know how my emails are sorted?  That is why you are supposed to number
your patches.  Please read Documentation/SubmittingPatches for how to do
this properly.

thanks,

greg k-h

Re: [PATCH] staging:vt6656:channel.h: fix function definition argument without identifier name issue

[Greg KH]

On Sat, Feb 11, 2017 at 07:48:35AM +0530, Arushi Singhal wrote:
> Hi
> Sorry Greg but how this not applying to your mailing list.

Your patch did not apply to my staging-next git tree.  Probably because
soemone else already did this same work before you did.  Try rebasing
your patch on my staging-next branch of staging.git on git.kernel.org
and see for yourself.

thanks,

greg k-h

Re: [PATCH] staging:vt6656:channel.h: fix function definition argument without identifier name issue

[Greg KH]

On Sat, Feb 11, 2017 at 07:48:35AM +0530, Arushi Singhal wrote:
> Hi
> Sorry Greg but how this not applying to your mailing list.

Your patch did not apply to my staging-next git tree.  Probably because
soemone else already did this same work before you did.  Try rebasing
your patch on my staging-next branch of staging.git on git.kernel.org
and see for yourself.

thanks,

greg k-h

[PATCH] rbd: constify device_type structure

[Bhumika Goyal]

Declare device_type structure as const as it is only stored in the
type field of a device structure. This field is of type const, so add
const to the declaration of device_type structure.

File size before:
   textdata bss dec hex filename
  61546   11610 208   73364   11e94 drivers/block/rbd.o

File size after:
   textdata bss dec hex filename
  61610   11578 208   73396   11eb4 drivers/block/rbd.o

Signed-off-by: Bhumika Goyal 
---
 drivers/block/rbd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/block/rbd.c b/drivers/block/rbd.c
index 36d2b9f..dfc708b 100644
--- a/drivers/block/rbd.c
+++ b/drivers/block/rbd.c
@@ -4779,7 +4779,7 @@ static ssize_t rbd_image_refresh(struct device *dev,
 
 static void rbd_dev_release(struct device *dev);
 
-static struct device_type rbd_device_type = {
+static const struct device_type rbd_device_type = {
.name   = "rbd",
.groups = rbd_attr_groups,
.release= rbd_dev_release,
-- 
1.9.1

[PATCH] rbd: constify device_type structure

[Bhumika Goyal]

Declare device_type structure as const as it is only stored in the
type field of a device structure. This field is of type const, so add
const to the declaration of device_type structure.

File size before:
   textdata bss dec hex filename
  61546   11610 208   73364   11e94 drivers/block/rbd.o

File size after:
   textdata bss dec hex filename
  61610   11578 208   73396   11eb4 drivers/block/rbd.o

Signed-off-by: Bhumika Goyal 
---
 drivers/block/rbd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/block/rbd.c b/drivers/block/rbd.c
index 36d2b9f..dfc708b 100644
--- a/drivers/block/rbd.c
+++ b/drivers/block/rbd.c
@@ -4779,7 +4779,7 @@ static ssize_t rbd_image_refresh(struct device *dev,
 
 static void rbd_dev_release(struct device *dev);
 
-static struct device_type rbd_device_type = {
+static const struct device_type rbd_device_type = {
.name   = "rbd",
.groups = rbd_attr_groups,
.release= rbd_dev_release,
-- 
1.9.1

Re: [PATCH v4] fork: free vmapped stacks in cache when cpus are offline

[Michal Hocko]

On Sat 11-02-17 08:40:38, Hoeun Ryu wrote:
>  Using virtually mapped stack, kernel stacks are allocated via vmalloc.
> In the current implementation, two stacks per cpu can be cached when
> tasks are freed and the cached stacks are used again in task duplications.
> but the cached stacks may remain unfreed even when cpu are offline.
>  By adding a cpu hotplug callback to free the cached stacks when a cpu
> goes offline, the pages of the cached stacks are not wasted.
> 
> Signed-off-by: Hoeun Ryu 

Acked-by: Michal Hocko 

> ---
> v4:
>  use CPUHP_BP_PREPARE_DYN state for cpuhp setup
>  fix minor coding style
> v3:
>  fix misuse of per-cpu api
>  fix location of function definition within CONFIG_VMAP_STACK
> v2:
>  remove cpuhp callback for `startup`, only `teardown` callback is installed.
> 
>  kernel/fork.c | 23 +++
>  1 file changed, 23 insertions(+)
> 
> diff --git a/kernel/fork.c b/kernel/fork.c
> index 937ba59..61634d7 100644
> --- a/kernel/fork.c
> +++ b/kernel/fork.c
> @@ -168,6 +168,24 @@ void __weak arch_release_thread_stack(unsigned long 
> *stack)
>   */
>  #define NR_CACHED_STACKS 2
>  static DEFINE_PER_CPU(struct vm_struct *, cached_stacks[NR_CACHED_STACKS]);
> +
> +static int free_vm_stack_cache(unsigned int cpu)
> +{
> + struct vm_struct **cached_vm_stacks = per_cpu_ptr(cached_stacks, cpu);
> + int i;
> +
> + for (i = 0; i < NR_CACHED_STACKS; i++) {
> + struct vm_struct *vm_stack = cached_vm_stacks[i];
> +
> + if (!vm_stack)
> + continue;
> +
> + vfree(vm_stack->addr);
> + cached_vm_stacks[i] = NULL;
> + }
> +
> + return 0;
> +}
>  #endif
>  
>  static unsigned long *alloc_thread_stack_node(struct task_struct *tsk, int 
> node)
> @@ -456,6 +474,11 @@ void __init fork_init(void)
>   for (i = 0; i < UCOUNT_COUNTS; i++) {
>   init_user_ns.ucount_max[i] = max_threads/2;
>   }
> +
> +#ifdef CONFIG_VMAP_STACK
> + cpuhp_setup_state(CPUHP_BP_PREPARE_DYN, "fork:vmstack_cache",
> +   NULL, free_vm_stack_cache);
> +#endif
>  }
>  
>  int __weak arch_dup_task_struct(struct task_struct *dst,
> -- 
> 2.7.4
> 

-- 
Michal Hocko
SUSE Labs

Re: [PATCH v4] fork: free vmapped stacks in cache when cpus are offline

[Michal Hocko]

On Sat 11-02-17 08:40:38, Hoeun Ryu wrote:
>  Using virtually mapped stack, kernel stacks are allocated via vmalloc.
> In the current implementation, two stacks per cpu can be cached when
> tasks are freed and the cached stacks are used again in task duplications.
> but the cached stacks may remain unfreed even when cpu are offline.
>  By adding a cpu hotplug callback to free the cached stacks when a cpu
> goes offline, the pages of the cached stacks are not wasted.
> 
> Signed-off-by: Hoeun Ryu 

Acked-by: Michal Hocko 

> ---
> v4:
>  use CPUHP_BP_PREPARE_DYN state for cpuhp setup
>  fix minor coding style
> v3:
>  fix misuse of per-cpu api
>  fix location of function definition within CONFIG_VMAP_STACK
> v2:
>  remove cpuhp callback for `startup`, only `teardown` callback is installed.
> 
>  kernel/fork.c | 23 +++
>  1 file changed, 23 insertions(+)
> 
> diff --git a/kernel/fork.c b/kernel/fork.c
> index 937ba59..61634d7 100644
> --- a/kernel/fork.c
> +++ b/kernel/fork.c
> @@ -168,6 +168,24 @@ void __weak arch_release_thread_stack(unsigned long 
> *stack)
>   */
>  #define NR_CACHED_STACKS 2
>  static DEFINE_PER_CPU(struct vm_struct *, cached_stacks[NR_CACHED_STACKS]);
> +
> +static int free_vm_stack_cache(unsigned int cpu)
> +{
> + struct vm_struct **cached_vm_stacks = per_cpu_ptr(cached_stacks, cpu);
> + int i;
> +
> + for (i = 0; i < NR_CACHED_STACKS; i++) {
> + struct vm_struct *vm_stack = cached_vm_stacks[i];
> +
> + if (!vm_stack)
> + continue;
> +
> + vfree(vm_stack->addr);
> + cached_vm_stacks[i] = NULL;
> + }
> +
> + return 0;
> +}
>  #endif
>  
>  static unsigned long *alloc_thread_stack_node(struct task_struct *tsk, int 
> node)
> @@ -456,6 +474,11 @@ void __init fork_init(void)
>   for (i = 0; i < UCOUNT_COUNTS; i++) {
>   init_user_ns.ucount_max[i] = max_threads/2;
>   }
> +
> +#ifdef CONFIG_VMAP_STACK
> + cpuhp_setup_state(CPUHP_BP_PREPARE_DYN, "fork:vmstack_cache",
> +   NULL, free_vm_stack_cache);
> +#endif
>  }
>  
>  int __weak arch_dup_task_struct(struct task_struct *dst,
> -- 
> 2.7.4
> 

-- 
Michal Hocko
SUSE Labs

[GIT PULL] SCSI fixes for 4.10-rc7

[James Bottomley]

Six fairly small fixes.  None is a real show stopper, two automation
detected problems: one memory leak, one use after free and four others
each of which fixes something that has been a significant source of
annoyance to someone.

The patch is available here:

git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes

The short changelog is:

Bart Van Assche (1):
  scsi: qla2xxx: Fix a recently introduced memory leak

Dave Carroll (1):
  scsi: aacraid: Fix INTx/MSI-x issue with older controllers

Mauricio Faria de Oliveira (1):
  scsi: qla2xxx: Avoid that issuing a LIP triggers a kernel crash

Ram Pai (1):
  scsi: mpt3sas: Force request partial completion alignment

Steffen Maier (1):
  scsi: zfcp: fix use-after-free by not tracing WKA port open/close on 
failed send

ojab (1):
  scsi: mpt3sas: disable ASPM for MPI2 controllers

And the diffstat:

 drivers/s390/scsi/zfcp_fsf.c |  8 
 drivers/scsi/aacraid/comminit.c  |  8 ++--
 drivers/scsi/mpt3sas/mpt3sas_scsih.c | 18 ++
 drivers/scsi/qla2xxx/qla_isr.c   |  3 ++-
 drivers/scsi/qla2xxx/qla_os.c|  2 +-
 5 files changed, 31 insertions(+), 8 deletions(-)

With full diff below.

James

---

diff --git a/drivers/s390/scsi/zfcp_fsf.c b/drivers/s390/scsi/zfcp_fsf.c
index 75f820ca..27ff38f 100644
--- a/drivers/s390/scsi/zfcp_fsf.c
+++ b/drivers/s390/scsi/zfcp_fsf.c
@@ -1583,7 +1583,7 @@ static void zfcp_fsf_open_wka_port_handler(struct 
zfcp_fsf_req *req)
 int zfcp_fsf_open_wka_port(struct zfcp_fc_wka_port *wka_port)
 {
struct zfcp_qdio *qdio = wka_port->adapter->qdio;
-   struct zfcp_fsf_req *req = NULL;
+   struct zfcp_fsf_req *req;
int retval = -EIO;
 
spin_lock_irq(>req_q_lock);
@@ -1612,7 +1612,7 @@ int zfcp_fsf_open_wka_port(struct zfcp_fc_wka_port 
*wka_port)
zfcp_fsf_req_free(req);
 out:
spin_unlock_irq(>req_q_lock);
-   if (req && !IS_ERR(req))
+   if (!retval)
zfcp_dbf_rec_run_wka("fsowp_1", wka_port, req->req_id);
return retval;
 }
@@ -1638,7 +1638,7 @@ static void zfcp_fsf_close_wka_port_handler(struct 
zfcp_fsf_req *req)
 int zfcp_fsf_close_wka_port(struct zfcp_fc_wka_port *wka_port)
 {
struct zfcp_qdio *qdio = wka_port->adapter->qdio;
-   struct zfcp_fsf_req *req = NULL;
+   struct zfcp_fsf_req *req;
int retval = -EIO;
 
spin_lock_irq(>req_q_lock);
@@ -1667,7 +1667,7 @@ int zfcp_fsf_close_wka_port(struct zfcp_fc_wka_port 
*wka_port)
zfcp_fsf_req_free(req);
 out:
spin_unlock_irq(>req_q_lock);
-   if (req && !IS_ERR(req))
+   if (!retval)
zfcp_dbf_rec_run_wka("fscwp_1", wka_port, req->req_id);
return retval;
 }
diff --git a/drivers/scsi/aacraid/comminit.c b/drivers/scsi/aacraid/comminit.c
index 4f56b10..5b48bed 100644
--- a/drivers/scsi/aacraid/comminit.c
+++ b/drivers/scsi/aacraid/comminit.c
@@ -50,9 +50,13 @@ struct aac_common aac_config = {
 
 static inline int aac_is_msix_mode(struct aac_dev *dev)
 {
-   u32 status;
+   u32 status = 0;
 
-   status = src_readl(dev, MUnit.OMR);
+   if (dev->pdev->device == PMC_DEVICE_S6 ||
+   dev->pdev->device == PMC_DEVICE_S7 ||
+   dev->pdev->device == PMC_DEVICE_S8) {
+   status = src_readl(dev, MUnit.OMR);
+   }
return (status & AAC_INT_MODE_MSIX);
 }
 
diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c 
b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
index 75f3fce..0b5b423 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
@@ -51,6 +51,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -4657,6 +4658,7 @@ _scsih_io_done(struct MPT3SAS_ADAPTER *ioc, u16 smid, u8 
msix_index, u32 reply)
struct MPT3SAS_DEVICE *sas_device_priv_data;
u32 response_code = 0;
unsigned long flags;
+   unsigned int sector_sz;
 
mpi_reply = mpt3sas_base_get_reply_virt_addr(ioc, reply);
scmd = _scsih_scsi_lookup_get_clear(ioc, smid);
@@ -4715,6 +4717,20 @@ _scsih_io_done(struct MPT3SAS_ADAPTER *ioc, u16 smid, u8 
msix_index, u32 reply)
}
 
xfer_cnt = le32_to_cpu(mpi_reply->TransferCount);
+
+   /* In case of bogus fw or device, we could end up having
+* unaligned partial completion. We can force alignment here,
+* then scsi-ml does not need to handle this misbehavior.
+*/
+   sector_sz = scmd->device->sector_size;
+   if (unlikely(scmd->request->cmd_type == REQ_TYPE_FS && sector_sz &&
+xfer_cnt % sector_sz)) {
+   sdev_printk(KERN_INFO, scmd->device,
+   "unaligned partial completion avoided (xfer_cnt=%u, 
sector_sz=%u)\n",
+   xfer_cnt, sector_sz);
+   xfer_cnt = round_down(xfer_cnt, sector_sz);
+   }
+
scsi_set_resid(scmd, scsi_bufflen(scmd) - xfer_cnt);

[GIT PULL] SCSI fixes for 4.10-rc7

[James Bottomley]

Six fairly small fixes.  None is a real show stopper, two automation
detected problems: one memory leak, one use after free and four others
each of which fixes something that has been a significant source of
annoyance to someone.

The patch is available here:

git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes

The short changelog is:

Bart Van Assche (1):
  scsi: qla2xxx: Fix a recently introduced memory leak

Dave Carroll (1):
  scsi: aacraid: Fix INTx/MSI-x issue with older controllers

Mauricio Faria de Oliveira (1):
  scsi: qla2xxx: Avoid that issuing a LIP triggers a kernel crash

Ram Pai (1):
  scsi: mpt3sas: Force request partial completion alignment

Steffen Maier (1):
  scsi: zfcp: fix use-after-free by not tracing WKA port open/close on 
failed send

ojab (1):
  scsi: mpt3sas: disable ASPM for MPI2 controllers

And the diffstat:

 drivers/s390/scsi/zfcp_fsf.c |  8 
 drivers/scsi/aacraid/comminit.c  |  8 ++--
 drivers/scsi/mpt3sas/mpt3sas_scsih.c | 18 ++
 drivers/scsi/qla2xxx/qla_isr.c   |  3 ++-
 drivers/scsi/qla2xxx/qla_os.c|  2 +-
 5 files changed, 31 insertions(+), 8 deletions(-)

With full diff below.

James

---

diff --git a/drivers/s390/scsi/zfcp_fsf.c b/drivers/s390/scsi/zfcp_fsf.c
index 75f820ca..27ff38f 100644
--- a/drivers/s390/scsi/zfcp_fsf.c
+++ b/drivers/s390/scsi/zfcp_fsf.c
@@ -1583,7 +1583,7 @@ static void zfcp_fsf_open_wka_port_handler(struct 
zfcp_fsf_req *req)
 int zfcp_fsf_open_wka_port(struct zfcp_fc_wka_port *wka_port)
 {
struct zfcp_qdio *qdio = wka_port->adapter->qdio;
-   struct zfcp_fsf_req *req = NULL;
+   struct zfcp_fsf_req *req;
int retval = -EIO;
 
spin_lock_irq(>req_q_lock);
@@ -1612,7 +1612,7 @@ int zfcp_fsf_open_wka_port(struct zfcp_fc_wka_port 
*wka_port)
zfcp_fsf_req_free(req);
 out:
spin_unlock_irq(>req_q_lock);
-   if (req && !IS_ERR(req))
+   if (!retval)
zfcp_dbf_rec_run_wka("fsowp_1", wka_port, req->req_id);
return retval;
 }
@@ -1638,7 +1638,7 @@ static void zfcp_fsf_close_wka_port_handler(struct 
zfcp_fsf_req *req)
 int zfcp_fsf_close_wka_port(struct zfcp_fc_wka_port *wka_port)
 {
struct zfcp_qdio *qdio = wka_port->adapter->qdio;
-   struct zfcp_fsf_req *req = NULL;
+   struct zfcp_fsf_req *req;
int retval = -EIO;
 
spin_lock_irq(>req_q_lock);
@@ -1667,7 +1667,7 @@ int zfcp_fsf_close_wka_port(struct zfcp_fc_wka_port 
*wka_port)
zfcp_fsf_req_free(req);
 out:
spin_unlock_irq(>req_q_lock);
-   if (req && !IS_ERR(req))
+   if (!retval)
zfcp_dbf_rec_run_wka("fscwp_1", wka_port, req->req_id);
return retval;
 }
diff --git a/drivers/scsi/aacraid/comminit.c b/drivers/scsi/aacraid/comminit.c
index 4f56b10..5b48bed 100644
--- a/drivers/scsi/aacraid/comminit.c
+++ b/drivers/scsi/aacraid/comminit.c
@@ -50,9 +50,13 @@ struct aac_common aac_config = {
 
 static inline int aac_is_msix_mode(struct aac_dev *dev)
 {
-   u32 status;
+   u32 status = 0;
 
-   status = src_readl(dev, MUnit.OMR);
+   if (dev->pdev->device == PMC_DEVICE_S6 ||
+   dev->pdev->device == PMC_DEVICE_S7 ||
+   dev->pdev->device == PMC_DEVICE_S8) {
+   status = src_readl(dev, MUnit.OMR);
+   }
return (status & AAC_INT_MODE_MSIX);
 }
 
diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c 
b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
index 75f3fce..0b5b423 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
@@ -51,6 +51,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -4657,6 +4658,7 @@ _scsih_io_done(struct MPT3SAS_ADAPTER *ioc, u16 smid, u8 
msix_index, u32 reply)
struct MPT3SAS_DEVICE *sas_device_priv_data;
u32 response_code = 0;
unsigned long flags;
+   unsigned int sector_sz;
 
mpi_reply = mpt3sas_base_get_reply_virt_addr(ioc, reply);
scmd = _scsih_scsi_lookup_get_clear(ioc, smid);
@@ -4715,6 +4717,20 @@ _scsih_io_done(struct MPT3SAS_ADAPTER *ioc, u16 smid, u8 
msix_index, u32 reply)
}
 
xfer_cnt = le32_to_cpu(mpi_reply->TransferCount);
+
+   /* In case of bogus fw or device, we could end up having
+* unaligned partial completion. We can force alignment here,
+* then scsi-ml does not need to handle this misbehavior.
+*/
+   sector_sz = scmd->device->sector_size;
+   if (unlikely(scmd->request->cmd_type == REQ_TYPE_FS && sector_sz &&
+xfer_cnt % sector_sz)) {
+   sdev_printk(KERN_INFO, scmd->device,
+   "unaligned partial completion avoided (xfer_cnt=%u, 
sector_sz=%u)\n",
+   xfer_cnt, sector_sz);
+   xfer_cnt = round_down(xfer_cnt, sector_sz);
+   }
+
scsi_set_resid(scmd, scsi_bufflen(scmd) - xfer_cnt);

Re: [PATCH] f2fs: introduce nid cache

[Chao Yu]

On 2017/2/9 9:28, Jaegeuk Kim wrote:
> On 02/08, Chao Yu wrote:
>> On 2017/2/7 15:24, Chao Yu wrote:
>>> Hi Jaegeuk,
>>>
>>> Happy Chinese New Year! :)
>>>
>>> On 2017/1/24 12:35, Jaegeuk Kim wrote:
 Hi Chao,

 On 01/22, Chao Yu wrote:
> In scenario of intensively node allocation, free nids will be ran out
> soon, then it needs to stop to load free nids by traversing NAT blocks,
> in worse case, if NAT blocks does not be cached in memory, it generates
> IOs which slows down our foreground operations.
>
> In order to speed up node allocation, in this patch we introduce a new
> option named "nid cache", when turns on this option, it will load all
> nat entries in NAT blocks when doing mount, and organize all free nids
> in a bitmap, for any operations related to free nid, we will query and
> set the new prebuilded bitmap instead of reading and lookuping NAT
> blocks, so performance of node allocation can be improved.
>

 How does this affect mount time and memory consumption?
>>>
>>> Sorry for the delay.
>>>
>>> Let me figure out some numbers later.
>>
>> a. mount time
>>
>> I choose slow device (Kingston 16GB SD card) to see how this option affect 
>> mount
>> time when there is not enough bandwidth in low level,
>>
>> Before the test, I change readahead window size of NAT pages from 
>> FREE_NID_PAGES
>> * 8 to sbi->blocks_per_seg for better ra performance, so the result is:
>>
>> time mount -t f2fs -o nid_cache /dev/sde /mnt/f2fs/
>>
>> before:
>> real 0m0.204s
>> user 0m0.004s
>> sys  0m0.020s
>>
>> after:
>> real 0m3.792s
> 
> Oops, we can't accept this even only for 16GB, right? :(

Pengyang Hou help testing this patch in 64GB UFS, the result of mount time is:

Before: 110 ms
After:  770 ms

So these test results shows that we'd better not set nid_cache option by default
in upstream since anyway it slows down mount procedure obviously, but still
users can decide whether use it or not depending on their requirement. e.g.:
a. For readonly case, this option is complete no needed.
b. For in batch node allocation/deletion case, this option is recommended.

> 
>> user 0m0.000s
>> sys  0m0.140s
>>
>> b. memory consumption
>>
>> For 16GB size image, there is total 34 NAT pages, so memory footprint is:
>> 34 / 2 * 512 * 455 / 8 = 495040 bytes = 483.4 KB
>>
>> Increasing of memory footprint is liner with total user valid blocks in 
>> image,
>> and at most it will eat 3900 * 8 * 455 / 8 = 1774500 bytes = 1732.9 KB
> 
> How about adding two bitmaps for whole NAT pages and storing the bitmaps in
> checkpoint pack, which needs at most two blocks additionally?
> 
> 1. full-assigned NAT bitmap, where 1 means there is no free nids.
> 2. empty NAT bitmap, where 1 means whole there-in nids are free.
> 
> With these bitmaps, build_free_nids() can scan from 0'th NAT block by:
> 
>   if (full-assigned NAT)
>   skip;
>   else if (empty NAT)
>   add_free_nid(all);
>   else
>   read NAT page and add_free_nid();
> 
> The flush_nat_entries() has to change its bitmaps accordingly.
> 
> With this approach, I expect we can reuse nids as much as possible while
> getting cached NAT pages more effectively.

Good idea! :)

And there is another approach which do not need to change disk layout is:

We can allocate free_nid_bitmap[NAT_BLOCKS_COUNT][455] array, each bitmap
indicates usage of free nids in one NAT block, and we introduce another
nat_block_bitmap[NAT_BLOCKS_COUNT] to indicate each NAT block is loaded or not,
if it is loaded and we can do lookup in free_nid_bitmap correspondingly. So I
expect that we will load one NAT block from disk one time at most, it will:
- not increase mount latency
- after loading NAT blocks from disk, we will build its bitmap inside memory to
reduce lookup time for second time

Thoughts? Which one is preferred?

Thanks,

> 
> Thanks,
> 
>>
>> Thanks,
>>
>>>
 IMO, if those do not
 raise huge concerns, we would be able to consider just replacing current 
 free
 nid list with this bitmap.
>>>
>>> Yup, I agree with you.
>>>
>>> Thanks,
>>>
> 
> .
> 

Re: [PATCH] f2fs: introduce nid cache

[Chao Yu]

On 2017/2/9 9:28, Jaegeuk Kim wrote:
> On 02/08, Chao Yu wrote:
>> On 2017/2/7 15:24, Chao Yu wrote:
>>> Hi Jaegeuk,
>>>
>>> Happy Chinese New Year! :)
>>>
>>> On 2017/1/24 12:35, Jaegeuk Kim wrote:
 Hi Chao,

 On 01/22, Chao Yu wrote:
> In scenario of intensively node allocation, free nids will be ran out
> soon, then it needs to stop to load free nids by traversing NAT blocks,
> in worse case, if NAT blocks does not be cached in memory, it generates
> IOs which slows down our foreground operations.
>
> In order to speed up node allocation, in this patch we introduce a new
> option named "nid cache", when turns on this option, it will load all
> nat entries in NAT blocks when doing mount, and organize all free nids
> in a bitmap, for any operations related to free nid, we will query and
> set the new prebuilded bitmap instead of reading and lookuping NAT
> blocks, so performance of node allocation can be improved.
>

 How does this affect mount time and memory consumption?
>>>
>>> Sorry for the delay.
>>>
>>> Let me figure out some numbers later.
>>
>> a. mount time
>>
>> I choose slow device (Kingston 16GB SD card) to see how this option affect 
>> mount
>> time when there is not enough bandwidth in low level,
>>
>> Before the test, I change readahead window size of NAT pages from 
>> FREE_NID_PAGES
>> * 8 to sbi->blocks_per_seg for better ra performance, so the result is:
>>
>> time mount -t f2fs -o nid_cache /dev/sde /mnt/f2fs/
>>
>> before:
>> real 0m0.204s
>> user 0m0.004s
>> sys  0m0.020s
>>
>> after:
>> real 0m3.792s
> 
> Oops, we can't accept this even only for 16GB, right? :(

Pengyang Hou help testing this patch in 64GB UFS, the result of mount time is:

Before: 110 ms
After:  770 ms

So these test results shows that we'd better not set nid_cache option by default
in upstream since anyway it slows down mount procedure obviously, but still
users can decide whether use it or not depending on their requirement. e.g.:
a. For readonly case, this option is complete no needed.
b. For in batch node allocation/deletion case, this option is recommended.

> 
>> user 0m0.000s
>> sys  0m0.140s
>>
>> b. memory consumption
>>
>> For 16GB size image, there is total 34 NAT pages, so memory footprint is:
>> 34 / 2 * 512 * 455 / 8 = 495040 bytes = 483.4 KB
>>
>> Increasing of memory footprint is liner with total user valid blocks in 
>> image,
>> and at most it will eat 3900 * 8 * 455 / 8 = 1774500 bytes = 1732.9 KB
> 
> How about adding two bitmaps for whole NAT pages and storing the bitmaps in
> checkpoint pack, which needs at most two blocks additionally?
> 
> 1. full-assigned NAT bitmap, where 1 means there is no free nids.
> 2. empty NAT bitmap, where 1 means whole there-in nids are free.
> 
> With these bitmaps, build_free_nids() can scan from 0'th NAT block by:
> 
>   if (full-assigned NAT)
>   skip;
>   else if (empty NAT)
>   add_free_nid(all);
>   else
>   read NAT page and add_free_nid();
> 
> The flush_nat_entries() has to change its bitmaps accordingly.
> 
> With this approach, I expect we can reuse nids as much as possible while
> getting cached NAT pages more effectively.

Good idea! :)

And there is another approach which do not need to change disk layout is:

We can allocate free_nid_bitmap[NAT_BLOCKS_COUNT][455] array, each bitmap
indicates usage of free nids in one NAT block, and we introduce another
nat_block_bitmap[NAT_BLOCKS_COUNT] to indicate each NAT block is loaded or not,
if it is loaded and we can do lookup in free_nid_bitmap correspondingly. So I
expect that we will load one NAT block from disk one time at most, it will:
- not increase mount latency
- after loading NAT blocks from disk, we will build its bitmap inside memory to
reduce lookup time for second time

Thoughts? Which one is preferred?

Thanks,

> 
> Thanks,
> 
>>
>> Thanks,
>>
>>>
 IMO, if those do not
 raise huge concerns, we would be able to consider just replacing current 
 free
 nid list with this bitmap.
>>>
>>> Yup, I agree with you.
>>>
>>> Thanks,
>>>
> 
> .
> 

[PATCH] staging: rtl8192u: Fix RETURN_VOID warnings

[simran singhal]

Fix 'void function return statements are not generally useful'
checkpatch.pl warnings.

Signed-off-by: simran singhal 
---
 drivers/staging/rtl8192u/ieee80211/rtl819x_BAProc.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/staging/rtl8192u/ieee80211/rtl819x_BAProc.c 
b/drivers/staging/rtl8192u/ieee80211/rtl819x_BAProc.c
index c09f3ad..f02eb8e 100644
--- a/drivers/staging/rtl8192u/ieee80211/rtl819x_BAProc.c
+++ b/drivers/staging/rtl8192u/ieee80211/rtl819x_BAProc.c
@@ -258,7 +258,6 @@ static void ieee80211_send_ADDBAReq(struct ieee80211_device 
*ieee,
else {
IEEE80211_DEBUG(IEEE80211_DL_ERR, "alloc skb error in function 
%s()\n", __func__);
}
-   return;
 }
 
 
/
@@ -308,7 +307,6 @@ static void ieee80211_send_DELBA(struct ieee80211_device 
*ieee, u8 *dst,
else {
IEEE80211_DEBUG(IEEE80211_DL_ERR, "alloc skb error in function 
%s()\n", __func__);
}
-   return ;
 }
 
 
/
@@ -708,5 +706,4 @@ void RxBaInactTimeout(unsigned long data)
>RxAdmittedBARecord,
RX_DIR,
DELBA_REASON_TIMEOUT);
-   return ;
 }
-- 
2.7.4

[PATCH] staging: rtl8192u: Fix RETURN_VOID warnings

[simran singhal]

Fix 'void function return statements are not generally useful'
checkpatch.pl warnings.

Signed-off-by: simran singhal 
---
 drivers/staging/rtl8192u/ieee80211/rtl819x_BAProc.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/staging/rtl8192u/ieee80211/rtl819x_BAProc.c 
b/drivers/staging/rtl8192u/ieee80211/rtl819x_BAProc.c
index c09f3ad..f02eb8e 100644
--- a/drivers/staging/rtl8192u/ieee80211/rtl819x_BAProc.c
+++ b/drivers/staging/rtl8192u/ieee80211/rtl819x_BAProc.c
@@ -258,7 +258,6 @@ static void ieee80211_send_ADDBAReq(struct ieee80211_device 
*ieee,
else {
IEEE80211_DEBUG(IEEE80211_DL_ERR, "alloc skb error in function 
%s()\n", __func__);
}
-   return;
 }
 
 
/
@@ -308,7 +307,6 @@ static void ieee80211_send_DELBA(struct ieee80211_device 
*ieee, u8 *dst,
else {
IEEE80211_DEBUG(IEEE80211_DL_ERR, "alloc skb error in function 
%s()\n", __func__);
}
-   return ;
 }
 
 
/
@@ -708,5 +706,4 @@ void RxBaInactTimeout(unsigned long data)
>RxAdmittedBARecord,
RX_DIR,
DELBA_REASON_TIMEOUT);
-   return ;
 }
-- 
2.7.4

[PATCH] staging: rtl8192u: Fix brace placement

[simran singhal]

Fix brace placement errors caught by checkpatch.pl ERROR: that open
brace { should be on the previous line

Signed-off-by: simran singhal 
---
 .../staging/rtl8192u/ieee80211/rtl819x_BAProc.c| 90 --
 1 file changed, 30 insertions(+), 60 deletions(-)

diff --git a/drivers/staging/rtl8192u/ieee80211/rtl819x_BAProc.c 
b/drivers/staging/rtl8192u/ieee80211/rtl819x_BAProc.c
index 91ea77d..c09f3ad 100644
--- a/drivers/staging/rtl8192u/ieee80211/rtl819x_BAProc.c
+++ b/drivers/staging/rtl8192u/ieee80211/rtl819x_BAProc.c
@@ -46,15 +46,13 @@ static u8 TxTsDeleteBA(struct ieee80211_device *ieee, 
PTX_TS_RECORD pTxTs)
u8  bSendDELBA = false;
 
// Delete pending BA
-   if (pPendingBa->bValid)
-   {
+   if (pPendingBa->bValid) {
DeActivateBAEntry(ieee, pPendingBa);
bSendDELBA = true;
}
 
// Delete admitted BA
-   if (pAdmittedBa->bValid)
-   {
+   if (pAdmittedBa->bValid) {
DeActivateBAEntry(ieee, pAdmittedBa);
bSendDELBA = true;
}
@@ -74,8 +72,7 @@ static u8 RxTsDeleteBA(struct ieee80211_device *ieee, 
PRX_TS_RECORD pRxTs)
PBA_RECORD  pBa = >RxAdmittedBARecord;
u8  bSendDELBA = false;
 
-   if (pBa->bValid)
-   {
+   if (pBa->bValid) {
DeActivateBAEntry(ieee, pBa);
bSendDELBA = true;
}
@@ -115,14 +112,12 @@ static struct sk_buff *ieee80211_ADDBA(struct 
ieee80211_device *ieee, u8 *Dst, P
u16 len = ieee->tx_headroom + 9;
//category(1) + action field(1) + Dialog Token(1) + BA Parameter Set(2) 
+  BA Timeout Value(2) +  BA Start SeqCtrl(2)(or StatusCode(2))
IEEE80211_DEBUG(IEEE80211_DL_TRACE | IEEE80211_DL_BA, ">%s(), 
frame(%d) sentd to:%pM, ieee->dev:%p\n", __func__, type, Dst, ieee->dev);
-   if (pBA == NULL)
-   {
+   if (pBA == NULL) {
IEEE80211_DEBUG(IEEE80211_DL_ERR, "pBA is NULL\n");
return NULL;
}
skb = dev_alloc_skb(len + sizeof( struct rtl_80211_hdr_3addr)); //need 
to add something others? FIXME
-   if (skb == NULL)
-   {
+   if (skb == NULL) {
IEEE80211_DEBUG(IEEE80211_DL_ERR, "can't alloc skb for 
ADDBA_REQ\n");
return NULL;
}
@@ -146,8 +141,7 @@ static struct sk_buff *ieee80211_ADDBA(struct 
ieee80211_device *ieee, u8 *Dst, P
// Dialog Token
*tag ++= pBA->DialogToken;
 
-   if (ACT_ADDBARSP == type)
-   {
+   if (ACT_ADDBARSP == type) {
// Status Code
printk("=>to send ADDBARSP\n");
 
@@ -163,8 +157,7 @@ static struct sk_buff *ieee80211_ADDBA(struct 
ieee80211_device *ieee, u8 *Dst, P
put_unaligned_le16(pBA->BaTimeoutValue, tag);
tag += 2;
 
-   if (ACT_ADDBAREQ == type)
-   {
+   if (ACT_ADDBAREQ == type) {
// BA Start SeqCtrl
memcpy(tag, (u8 *)&(pBA->BaStartSeqCtrl), 2);
tag += 2;
@@ -209,8 +202,7 @@ static struct sk_buff *ieee80211_DELBA(
DelbaParamSet.field.TID = pBA->BaParamSet.field.TID;
 
skb = dev_alloc_skb(len + sizeof( struct rtl_80211_hdr_3addr)); //need 
to add something others? FIXME
-   if (skb == NULL)
-   {
+   if (skb == NULL) {
IEEE80211_DEBUG(IEEE80211_DL_ERR, "can't alloc skb for 
ADDBA_REQ\n");
return NULL;
}
@@ -257,15 +249,13 @@ static void ieee80211_send_ADDBAReq(struct 
ieee80211_device *ieee,
struct sk_buff *skb;
skb = ieee80211_ADDBA(ieee, dst, pBA, 0, ACT_ADDBAREQ); //construct 
ACT_ADDBAREQ frames so set statuscode zero.
 
-   if (skb)
-   {
+   if (skb) {
softmac_mgmt_xmit(skb, ieee);
//add statistic needed here.
//and skb will be freed in softmac_mgmt_xmit(), so omit all 
dev_kfree_skb_any() outside softmac_mgmt_xmit()
//WB
}
-   else
-   {
+   else {
IEEE80211_DEBUG(IEEE80211_DL_ERR, "alloc skb error in function 
%s()\n", __func__);
}
return;
@@ -284,13 +274,11 @@ static void ieee80211_send_ADDBARsp(struct 
ieee80211_device *ieee, u8 *dst,
 {
struct sk_buff *skb;
skb = ieee80211_ADDBA(ieee, dst, pBA, StatusCode, ACT_ADDBARSP); 
//construct ACT_ADDBARSP frames
-   if (skb)
-   {
+   if (skb) {
softmac_mgmt_xmit(skb, ieee);
//same above
}
-   else
-   {
+   else {
IEEE80211_DEBUG(IEEE80211_DL_ERR, "alloc skb error in function 
%s()\n", __func__);
}
 
@@ -313,13 +301,11 @@ static void ieee80211_send_DELBA(struct ieee80211_device 
*ieee, u8 *dst,
 {
struct sk_buff *skb;
skb = ieee80211_DELBA(ieee, dst, pBA, TxRxSelect, ReasonCode); 
//construct ACT_ADDBARSP frames
-   if (skb)
-   {

[PATCH] staging: rtl8192u: Fix brace placement

[simran singhal]

Fix brace placement errors caught by checkpatch.pl ERROR: that open
brace { should be on the previous line

Signed-off-by: simran singhal 
---
 .../staging/rtl8192u/ieee80211/rtl819x_BAProc.c| 90 --
 1 file changed, 30 insertions(+), 60 deletions(-)

diff --git a/drivers/staging/rtl8192u/ieee80211/rtl819x_BAProc.c 
b/drivers/staging/rtl8192u/ieee80211/rtl819x_BAProc.c
index 91ea77d..c09f3ad 100644
--- a/drivers/staging/rtl8192u/ieee80211/rtl819x_BAProc.c
+++ b/drivers/staging/rtl8192u/ieee80211/rtl819x_BAProc.c
@@ -46,15 +46,13 @@ static u8 TxTsDeleteBA(struct ieee80211_device *ieee, 
PTX_TS_RECORD pTxTs)
u8  bSendDELBA = false;
 
// Delete pending BA
-   if (pPendingBa->bValid)
-   {
+   if (pPendingBa->bValid) {
DeActivateBAEntry(ieee, pPendingBa);
bSendDELBA = true;
}
 
// Delete admitted BA
-   if (pAdmittedBa->bValid)
-   {
+   if (pAdmittedBa->bValid) {
DeActivateBAEntry(ieee, pAdmittedBa);
bSendDELBA = true;
}
@@ -74,8 +72,7 @@ static u8 RxTsDeleteBA(struct ieee80211_device *ieee, 
PRX_TS_RECORD pRxTs)
PBA_RECORD  pBa = >RxAdmittedBARecord;
u8  bSendDELBA = false;
 
-   if (pBa->bValid)
-   {
+   if (pBa->bValid) {
DeActivateBAEntry(ieee, pBa);
bSendDELBA = true;
}
@@ -115,14 +112,12 @@ static struct sk_buff *ieee80211_ADDBA(struct 
ieee80211_device *ieee, u8 *Dst, P
u16 len = ieee->tx_headroom + 9;
//category(1) + action field(1) + Dialog Token(1) + BA Parameter Set(2) 
+  BA Timeout Value(2) +  BA Start SeqCtrl(2)(or StatusCode(2))
IEEE80211_DEBUG(IEEE80211_DL_TRACE | IEEE80211_DL_BA, ">%s(), 
frame(%d) sentd to:%pM, ieee->dev:%p\n", __func__, type, Dst, ieee->dev);
-   if (pBA == NULL)
-   {
+   if (pBA == NULL) {
IEEE80211_DEBUG(IEEE80211_DL_ERR, "pBA is NULL\n");
return NULL;
}
skb = dev_alloc_skb(len + sizeof( struct rtl_80211_hdr_3addr)); //need 
to add something others? FIXME
-   if (skb == NULL)
-   {
+   if (skb == NULL) {
IEEE80211_DEBUG(IEEE80211_DL_ERR, "can't alloc skb for 
ADDBA_REQ\n");
return NULL;
}
@@ -146,8 +141,7 @@ static struct sk_buff *ieee80211_ADDBA(struct 
ieee80211_device *ieee, u8 *Dst, P
// Dialog Token
*tag ++= pBA->DialogToken;
 
-   if (ACT_ADDBARSP == type)
-   {
+   if (ACT_ADDBARSP == type) {
// Status Code
printk("=>to send ADDBARSP\n");
 
@@ -163,8 +157,7 @@ static struct sk_buff *ieee80211_ADDBA(struct 
ieee80211_device *ieee, u8 *Dst, P
put_unaligned_le16(pBA->BaTimeoutValue, tag);
tag += 2;
 
-   if (ACT_ADDBAREQ == type)
-   {
+   if (ACT_ADDBAREQ == type) {
// BA Start SeqCtrl
memcpy(tag, (u8 *)&(pBA->BaStartSeqCtrl), 2);
tag += 2;
@@ -209,8 +202,7 @@ static struct sk_buff *ieee80211_DELBA(
DelbaParamSet.field.TID = pBA->BaParamSet.field.TID;
 
skb = dev_alloc_skb(len + sizeof( struct rtl_80211_hdr_3addr)); //need 
to add something others? FIXME
-   if (skb == NULL)
-   {
+   if (skb == NULL) {
IEEE80211_DEBUG(IEEE80211_DL_ERR, "can't alloc skb for 
ADDBA_REQ\n");
return NULL;
}
@@ -257,15 +249,13 @@ static void ieee80211_send_ADDBAReq(struct 
ieee80211_device *ieee,
struct sk_buff *skb;
skb = ieee80211_ADDBA(ieee, dst, pBA, 0, ACT_ADDBAREQ); //construct 
ACT_ADDBAREQ frames so set statuscode zero.
 
-   if (skb)
-   {
+   if (skb) {
softmac_mgmt_xmit(skb, ieee);
//add statistic needed here.
//and skb will be freed in softmac_mgmt_xmit(), so omit all 
dev_kfree_skb_any() outside softmac_mgmt_xmit()
//WB
}
-   else
-   {
+   else {
IEEE80211_DEBUG(IEEE80211_DL_ERR, "alloc skb error in function 
%s()\n", __func__);
}
return;
@@ -284,13 +274,11 @@ static void ieee80211_send_ADDBARsp(struct 
ieee80211_device *ieee, u8 *dst,
 {
struct sk_buff *skb;
skb = ieee80211_ADDBA(ieee, dst, pBA, StatusCode, ACT_ADDBARSP); 
//construct ACT_ADDBARSP frames
-   if (skb)
-   {
+   if (skb) {
softmac_mgmt_xmit(skb, ieee);
//same above
}
-   else
-   {
+   else {
IEEE80211_DEBUG(IEEE80211_DL_ERR, "alloc skb error in function 
%s()\n", __func__);
}
 
@@ -313,13 +301,11 @@ static void ieee80211_send_DELBA(struct ieee80211_device 
*ieee, u8 *dst,
 {
struct sk_buff *skb;
skb = ieee80211_DELBA(ieee, dst, pBA, TxRxSelect, ReasonCode); 
//construct ACT_ADDBARSP frames
-   if (skb)
-   {
+   if (skb) {

Mistake in include IS_ENABLED(CONFIG_LIVEPATCH)

[Denys Fedoryshchenko]

Hello,

I noticed that sample of livepatch is not working in 4.9.9, because in 
include,

linux/livepatch.h
it is:
#if IS_ENABLED(CONFIG_LIVEPATCH)

while config option is:
CONFIG_HAVE_LIVEPATCH=y

After editing livepatch.h sample module compiles fine

Probably that's just a typo?

Mistake in include IS_ENABLED(CONFIG_LIVEPATCH)

[Denys Fedoryshchenko]

Hello,

I noticed that sample of livepatch is not working in 4.9.9, because in 
include,

linux/livepatch.h
it is:
#if IS_ENABLED(CONFIG_LIVEPATCH)

while config option is:
CONFIG_HAVE_LIVEPATCH=y

After editing livepatch.h sample module compiles fine

Probably that's just a typo?

[PATCH] staging: dgnc: dgnc_tty.c: fix argument list alignment issue.

[Nathan Howard]

Fix checkpatch.pl issue of the form:
"CHECK: Alignment should match open parenthesis".

Signed-off-by: Nathan Howard 
---
 drivers/staging/dgnc/dgnc_tty.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/dgnc/dgnc_tty.c b/drivers/staging/dgnc/dgnc_tty.c
index 1e10c0f..c63e591 100644
--- a/drivers/staging/dgnc/dgnc_tty.c
+++ b/drivers/staging/dgnc/dgnc_tty.c
@@ -971,9 +971,10 @@ static int dgnc_tty_open(struct tty_struct *tty, struct 
file *file)
 * touched safely, the close routine will signal the
 * ch_flags_wait to wake us back up.
 */
-   rc = wait_event_interruptible(ch->ch_flags_wait,
-   (((ch->ch_tun.un_flags |
-  ch->ch_pun.un_flags) & UN_CLOSING) == 0));
+   rc = wait_event_interruptible(
+   ch->ch_flags_wait,
+   (((ch->ch_tun.un_flags |
+   ch->ch_pun.un_flags) & UN_CLOSING) == 0));
 
/* If ret is non-zero, user ctrl-c'ed us */
if (rc)
@@ -1193,7 +1194,8 @@ static int dgnc_block_til_ready(struct tty_struct *tty,
 (old_flags != (ch->ch_tun.un_flags |
ch->ch_pun.un_flags)));
else
-   retval = wait_event_interruptible(ch->ch_flags_wait,
+   retval = wait_event_interruptible(
+   ch->ch_flags_wait,
(old_flags != ch->ch_flags));
 
/*
-- 
2.7.4

[PATCH] staging: dgnc: dgnc_tty.c: fix argument list alignment issue.

[Nathan Howard]

Fix checkpatch.pl issue of the form:
"CHECK: Alignment should match open parenthesis".

Signed-off-by: Nathan Howard 
---
 drivers/staging/dgnc/dgnc_tty.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/dgnc/dgnc_tty.c b/drivers/staging/dgnc/dgnc_tty.c
index 1e10c0f..c63e591 100644
--- a/drivers/staging/dgnc/dgnc_tty.c
+++ b/drivers/staging/dgnc/dgnc_tty.c
@@ -971,9 +971,10 @@ static int dgnc_tty_open(struct tty_struct *tty, struct 
file *file)
 * touched safely, the close routine will signal the
 * ch_flags_wait to wake us back up.
 */
-   rc = wait_event_interruptible(ch->ch_flags_wait,
-   (((ch->ch_tun.un_flags |
-  ch->ch_pun.un_flags) & UN_CLOSING) == 0));
+   rc = wait_event_interruptible(
+   ch->ch_flags_wait,
+   (((ch->ch_tun.un_flags |
+   ch->ch_pun.un_flags) & UN_CLOSING) == 0));
 
/* If ret is non-zero, user ctrl-c'ed us */
if (rc)
@@ -1193,7 +1194,8 @@ static int dgnc_block_til_ready(struct tty_struct *tty,
 (old_flags != (ch->ch_tun.un_flags |
ch->ch_pun.un_flags)));
else
-   retval = wait_event_interruptible(ch->ch_flags_wait,
+   retval = wait_event_interruptible(
+   ch->ch_flags_wait,
(old_flags != ch->ch_flags));
 
/*
-- 
2.7.4

Re: [PATCH v2] arm64: dts: Enable ir-spi in the tm2 and tm2e boards

[Andi Shyti]

Hi Javier,

On Fri, Feb 10, 2017 at 11:04:50AM -0300, Javier Martinez Canillas wrote:
> On 02/09/2017 11:22 PM, Andi Shyti wrote:
...
> > +   irda_regulator: irda-regulator {
> > +   compatible = "regulator-fixed";
> > +   enable-active-high;
> > +   gpio = < 3 GPIO_ACTIVE_HIGH>;
> > +   regulator-name = "irda_regulator";
> 
> How is this regulator named in the board schematics? My
> understanding is that regulator-name should match this.
> 
> I don't have access to this so it may be "irda_regulator"
> although I was expecting something more like "VDD_IRDA".

This is not a real regulator.

This is an external regulator which is enabled with a gpio
(GPR3[3]). The regulator-fixed allows me to use the regulator API
even though I would only need to control a gpio (with the gpio
API). I prefer using regulator to keep the same interface no
matter how the irda is connected.

About the name, I have full freedom to chose as of course it's
not documented in the exynos5433 datasheet. Perhaps I could call
it irda-gpio-regulator to make it more clear?

> Patch looks good to me though:
> 
> Reviewed-by: Javier Martinez Canillas 

Thanks,
Andi

Re: [PATCH v2] arm64: dts: Enable ir-spi in the tm2 and tm2e boards

[Andi Shyti]

Hi Javier,

On Fri, Feb 10, 2017 at 11:04:50AM -0300, Javier Martinez Canillas wrote:
> On 02/09/2017 11:22 PM, Andi Shyti wrote:
...
> > +   irda_regulator: irda-regulator {
> > +   compatible = "regulator-fixed";
> > +   enable-active-high;
> > +   gpio = < 3 GPIO_ACTIVE_HIGH>;
> > +   regulator-name = "irda_regulator";
> 
> How is this regulator named in the board schematics? My
> understanding is that regulator-name should match this.
> 
> I don't have access to this so it may be "irda_regulator"
> although I was expecting something more like "VDD_IRDA".

This is not a real regulator.

This is an external regulator which is enabled with a gpio
(GPR3[3]). The regulator-fixed allows me to use the regulator API
even though I would only need to control a gpio (with the gpio
API). I prefer using regulator to keep the same interface no
matter how the irda is connected.

About the name, I have full freedom to chose as of course it's
not documented in the exynos5433 datasheet. Perhaps I could call
it irda-gpio-regulator to make it more clear?

> Patch looks good to me though:
> 
> Reviewed-by: Javier Martinez Canillas 

Thanks,
Andi

Re: module: Optimize search_module_extables()

[Jessica Yu]

+++ Peter Zijlstra [08/02/17 15:48 +0100]:


While looking through the __ex_table stuff I found that we do a linear
lookup of the module. Also fix up a comment.

Signed-off-by: Peter Zijlstra (Intel) 


Applied, thanks.

Hm. A quick scan through module.c still shows a couple of places that use
similar linear lookups, and may benefit from the same __module_address
optimization. But I'll save that for a separate patch..

Jessica


---
kernel/module.c | 27 ++-
1 file changed, 14 insertions(+), 13 deletions(-)

diff --git a/kernel/module.c b/kernel/module.c
index 3d8f126208e3..7bcdc35dbf95 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -4165,22 +4165,23 @@ const struct exception_table_entry 
*search_module_extables(unsigned long addr)
struct module *mod;

preempt_disable();
-   list_for_each_entry_rcu(mod, , list) {
-   if (mod->state == MODULE_STATE_UNFORMED)
-   continue;
-   if (mod->num_exentries == 0)
-   continue;
+   mod = __module_address(addr);
+   if (!mod)
+   goto out;

-   e = search_extable(mod->extable,
-  mod->extable + mod->num_exentries - 1,
-  addr);
-   if (e)
-   break;
-   }
+   if (!mod->num_exentries)
+   goto out;
+
+   e = search_extable(mod->extable,
+  mod->extable + mod->num_exentries - 1,
+  addr);
+out:
preempt_enable();

-   /* Now, if we found one, we are running inside it now, hence
-  we cannot unload the module, hence no refcnt needed. */
+   /*
+* Now, if we found one, we are running inside it now, hence
+* we cannot unload the module, hence no refcnt needed.
+*/
return e;
}

Re: module: Optimize search_module_extables()

[Jessica Yu]

+++ Peter Zijlstra [08/02/17 15:48 +0100]:


While looking through the __ex_table stuff I found that we do a linear
lookup of the module. Also fix up a comment.

Signed-off-by: Peter Zijlstra (Intel) 


Applied, thanks.

Hm. A quick scan through module.c still shows a couple of places that use
similar linear lookups, and may benefit from the same __module_address
optimization. But I'll save that for a separate patch..

Jessica


---
kernel/module.c | 27 ++-
1 file changed, 14 insertions(+), 13 deletions(-)

diff --git a/kernel/module.c b/kernel/module.c
index 3d8f126208e3..7bcdc35dbf95 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -4165,22 +4165,23 @@ const struct exception_table_entry 
*search_module_extables(unsigned long addr)
struct module *mod;

preempt_disable();
-   list_for_each_entry_rcu(mod, , list) {
-   if (mod->state == MODULE_STATE_UNFORMED)
-   continue;
-   if (mod->num_exentries == 0)
-   continue;
+   mod = __module_address(addr);
+   if (!mod)
+   goto out;

-   e = search_extable(mod->extable,
-  mod->extable + mod->num_exentries - 1,
-  addr);
-   if (e)
-   break;
-   }
+   if (!mod->num_exentries)
+   goto out;
+
+   e = search_extable(mod->extable,
+  mod->extable + mod->num_exentries - 1,
+  addr);
+out:
preempt_enable();

-   /* Now, if we found one, we are running inside it now, hence
-  we cannot unload the module, hence no refcnt needed. */
+   /*
+* Now, if we found one, we are running inside it now, hence
+* we cannot unload the module, hence no refcnt needed.
+*/
return e;
}

[PATCH] staging: greybus: arpc.h: remove duplicate line.

[Nathan Howard]

Fix checkpatch.pl issue of the form:
"CHECK: Please don't use multiple blank lines".

Signed-off-by: Nathan Howard 
---
 drivers/staging/greybus/arpc.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/greybus/arpc.h b/drivers/staging/greybus/arpc.h
index 7fbddfc..c0b63c0 100644
--- a/drivers/staging/greybus/arpc.h
+++ b/drivers/staging/greybus/arpc.h
@@ -74,7 +74,6 @@ struct arpc_response_message {
__u8result; /* Result of RPC */
 } __packed;
 
-
 /* ARPC requests */
 #define ARPC_TYPE_CPORT_CONNECTED  0x01
 #define ARPC_TYPE_CPORT_QUIESCE0x02
-- 
2.7.4

[PATCH] staging: greybus: arpc.h: remove duplicate line.

[Nathan Howard]

Fix checkpatch.pl issue of the form:
"CHECK: Please don't use multiple blank lines".

Signed-off-by: Nathan Howard 
---
 drivers/staging/greybus/arpc.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/greybus/arpc.h b/drivers/staging/greybus/arpc.h
index 7fbddfc..c0b63c0 100644
--- a/drivers/staging/greybus/arpc.h
+++ b/drivers/staging/greybus/arpc.h
@@ -74,7 +74,6 @@ struct arpc_response_message {
__u8result; /* Result of RPC */
 } __packed;
 
-
 /* ARPC requests */
 #define ARPC_TYPE_CPORT_CONNECTED  0x01
 #define ARPC_TYPE_CPORT_QUIESCE0x02
-- 
2.7.4

Re: [PATCH] staging: rtl8192u: Removing multiple blank lines

[SIMRAN SINGHAL]

Multiple patches ...?
Can you please clarify what all patches you are including in "Multiple Patches".

And the Order you should go for is the order in which I submitted them.

On Sat, Feb 11, 2017 at 7:48 AM, SIMRAN SINGHAL
 wrote:
> Multiple patches ...?
> Can you please clarify what all patches you are including in "Multiple
> Patches".
>
> And the Order you should go for is the order in which I submitted them.
>
> On Feb 10, 2017 19:34, "Greg KH"  wrote:
>
> On Thu, Feb 09, 2017 at 06:02:12PM +0530, simran singhal wrote:
>> This patch fixes the checkpatch warning by removing multiple blank
>> lines.
>> CHECK: Please don't use multiple blank lines
>>
>> Signed-off-by: simran singhal 
>> ---
>>  drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_ccmp.c | 12
>> 
>>  1 file changed, 12 deletions(-)
>
> Hi,
>
> This is the friendly patch-bot of Greg Kroah-Hartman.  You have sent him
> a patch that has triggered this response.  He used to manually respond
> to these common problems, but in order to save his sanity (he kept
> writing the same thing over and over, yet to different people), I was
> created.  Hopefully you will not take offence and will fix the problem
> in your patch and resubmit it so that it can be accepted into the Linux
> kernel tree.
>
> You are receiving this message because of the following common error(s)
> as indicated below:
>
> - You sent multiple patches, yet no indication of which ones should be
>   applied in which order.  Greg could just guess, but if you are
>   receiving this email, he guessed wrong and the patches didn't apply.
>   Please read the section entitled "The canonical patch format" in the
>   kernel file, Documentation/SubmittingPatches for a description of how
>   to do this so that Greg has a chance to apply these correctly.
>
> If you wish to discuss this problem further, or you have questions about
> how to resolve this issue, please feel free to respond to this email and
> Greg will reply once he has dug out from the pending patches received
> from other developers.
>
> thanks,
>
> greg k-h's patch email bot
>
>

Re: [PATCH] staging: rtl8192u: Removing multiple blank lines

[SIMRAN SINGHAL]

Multiple patches ...?
Can you please clarify what all patches you are including in "Multiple Patches".

And the Order you should go for is the order in which I submitted them.

On Sat, Feb 11, 2017 at 7:48 AM, SIMRAN SINGHAL
 wrote:
> Multiple patches ...?
> Can you please clarify what all patches you are including in "Multiple
> Patches".
>
> And the Order you should go for is the order in which I submitted them.
>
> On Feb 10, 2017 19:34, "Greg KH"  wrote:
>
> On Thu, Feb 09, 2017 at 06:02:12PM +0530, simran singhal wrote:
>> This patch fixes the checkpatch warning by removing multiple blank
>> lines.
>> CHECK: Please don't use multiple blank lines
>>
>> Signed-off-by: simran singhal 
>> ---
>>  drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_ccmp.c | 12
>> 
>>  1 file changed, 12 deletions(-)
>
> Hi,
>
> This is the friendly patch-bot of Greg Kroah-Hartman.  You have sent him
> a patch that has triggered this response.  He used to manually respond
> to these common problems, but in order to save his sanity (he kept
> writing the same thing over and over, yet to different people), I was
> created.  Hopefully you will not take offence and will fix the problem
> in your patch and resubmit it so that it can be accepted into the Linux
> kernel tree.
>
> You are receiving this message because of the following common error(s)
> as indicated below:
>
> - You sent multiple patches, yet no indication of which ones should be
>   applied in which order.  Greg could just guess, but if you are
>   receiving this email, he guessed wrong and the patches didn't apply.
>   Please read the section entitled "The canonical patch format" in the
>   kernel file, Documentation/SubmittingPatches for a description of how
>   to do this so that Greg has a chance to apply these correctly.
>
> If you wish to discuss this problem further, or you have questions about
> how to resolve this issue, please feel free to respond to this email and
> Greg will reply once he has dug out from the pending patches received
> from other developers.
>
> thanks,
>
> greg k-h's patch email bot
>
>

[PATCH] block/loop: fix race between I/O and set_status

[Ming Lei]

Inside set_status, transfer need to setup again, so
we have to drain IO before the transition, otherwise
oops may be triggered like the following:

divide error:  [#1] SMP KASAN
CPU: 0 PID: 2935 Comm: loop7 Not tainted 4.10.0-rc7+ #213
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs
01/01/2011
task: 88006ba1e840 task.stack: 880067338000
RIP: 0010:transfer_xor+0x1d1/0x440 drivers/block/loop.c:110
RSP: 0018:88006733f108 EFLAGS: 00010246
RAX:  RBX: 8800688d7000 RCX: 0059
RDX:  RSI: 11000d743f43 RDI: 880068891c08
RBP: 88006733f160 R08: 8800688d7001 R09: 
R10:  R11:  R12: 8800688d7000
R13: 880067b7d000 R14: dc00 R15: 
FS:  () GS:88006d00()
knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 006c17e0 CR3: 66e3b000 CR4: 001406f0
Call Trace:
 lo_do_transfer drivers/block/loop.c:251 [inline]
 lo_read_transfer drivers/block/loop.c:392 [inline]
 do_req_filebacked drivers/block/loop.c:541 [inline]
 loop_handle_cmd drivers/block/loop.c:1677 [inline]
 loop_queue_work+0xda0/0x49b0 drivers/block/loop.c:1689
 kthread_worker_fn+0x4c3/0xa30 kernel/kthread.c:630
 kthread+0x326/0x3f0 kernel/kthread.c:227
 ret_from_fork+0x31/0x40 arch/x86/entry/entry_64.S:430
Code: 03 83 e2 07 41 29 df 42 0f b6 04 30 4d 8d 44 24 01 38 d0 7f 08
84 c0 0f 85 62 02 00 00 44 89 f8 41 0f b6 48 ff 25 ff 01 00 00 99 
7d c8 48 63 d2 48 03 55 d0 48 89 d0 48 89 d7 48 c1 e8 03 83
RIP: transfer_xor+0x1d1/0x440 drivers/block/loop.c:110 RSP:
88006733f108
---[ end trace 0166f7bd3b0c0933 ]---

Reported-by: Dmitry Vyukov 
Cc: sta...@vger.kernel.org
Signed-off-by: Ming Lei 
---
 drivers/block/loop.c | 17 -
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index ed5259510857..4b52a1690329 100644
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -1097,9 +1097,12 @@ loop_set_status(struct loop_device *lo, const struct 
loop_info64 *info)
if ((unsigned int) info->lo_encrypt_key_size > LO_KEY_SIZE)
return -EINVAL;
 
+   /* I/O need to be drained during transfer transition */
+   blk_mq_freeze_queue(lo->lo_queue);
+
err = loop_release_xfer(lo);
if (err)
-   return err;
+   goto exit;
 
if (info->lo_encrypt_type) {
unsigned int type = info->lo_encrypt_type;
@@ -1114,12 +1117,14 @@ loop_set_status(struct loop_device *lo, const struct 
loop_info64 *info)
 
err = loop_init_xfer(lo, xfer, info);
if (err)
-   return err;
+   goto exit;
 
if (lo->lo_offset != info->lo_offset ||
lo->lo_sizelimit != info->lo_sizelimit)
-   if (figure_loop_size(lo, info->lo_offset, info->lo_sizelimit))
-   return -EFBIG;
+   if (figure_loop_size(lo, info->lo_offset, info->lo_sizelimit)) {
+   err = -EFBIG;
+   goto exit;
+   }
 
loop_config_discard(lo);
 
@@ -1156,7 +1161,9 @@ loop_set_status(struct loop_device *lo, const struct 
loop_info64 *info)
/* update dio if lo_offset or transfer is changed */
__loop_update_dio(lo, lo->use_dio);
 
-   return 0;
+ exit:
+   blk_mq_unfreeze_queue(lo->lo_queue);
+   return err;
 }
 
 static int
-- 
2.7.4

[PATCH] block/loop: fix race between I/O and set_status

[Ming Lei]

Inside set_status, transfer need to setup again, so
we have to drain IO before the transition, otherwise
oops may be triggered like the following:

divide error:  [#1] SMP KASAN
CPU: 0 PID: 2935 Comm: loop7 Not tainted 4.10.0-rc7+ #213
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs
01/01/2011
task: 88006ba1e840 task.stack: 880067338000
RIP: 0010:transfer_xor+0x1d1/0x440 drivers/block/loop.c:110
RSP: 0018:88006733f108 EFLAGS: 00010246
RAX:  RBX: 8800688d7000 RCX: 0059
RDX:  RSI: 11000d743f43 RDI: 880068891c08
RBP: 88006733f160 R08: 8800688d7001 R09: 
R10:  R11:  R12: 8800688d7000
R13: 880067b7d000 R14: dc00 R15: 
FS:  () GS:88006d00()
knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 006c17e0 CR3: 66e3b000 CR4: 001406f0
Call Trace:
 lo_do_transfer drivers/block/loop.c:251 [inline]
 lo_read_transfer drivers/block/loop.c:392 [inline]
 do_req_filebacked drivers/block/loop.c:541 [inline]
 loop_handle_cmd drivers/block/loop.c:1677 [inline]
 loop_queue_work+0xda0/0x49b0 drivers/block/loop.c:1689
 kthread_worker_fn+0x4c3/0xa30 kernel/kthread.c:630
 kthread+0x326/0x3f0 kernel/kthread.c:227
 ret_from_fork+0x31/0x40 arch/x86/entry/entry_64.S:430
Code: 03 83 e2 07 41 29 df 42 0f b6 04 30 4d 8d 44 24 01 38 d0 7f 08
84 c0 0f 85 62 02 00 00 44 89 f8 41 0f b6 48 ff 25 ff 01 00 00 99 
7d c8 48 63 d2 48 03 55 d0 48 89 d0 48 89 d7 48 c1 e8 03 83
RIP: transfer_xor+0x1d1/0x440 drivers/block/loop.c:110 RSP:
88006733f108
---[ end trace 0166f7bd3b0c0933 ]---

Reported-by: Dmitry Vyukov 
Cc: sta...@vger.kernel.org
Signed-off-by: Ming Lei 
---
 drivers/block/loop.c | 17 -
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index ed5259510857..4b52a1690329 100644
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -1097,9 +1097,12 @@ loop_set_status(struct loop_device *lo, const struct 
loop_info64 *info)
if ((unsigned int) info->lo_encrypt_key_size > LO_KEY_SIZE)
return -EINVAL;
 
+   /* I/O need to be drained during transfer transition */
+   blk_mq_freeze_queue(lo->lo_queue);
+
err = loop_release_xfer(lo);
if (err)
-   return err;
+   goto exit;
 
if (info->lo_encrypt_type) {
unsigned int type = info->lo_encrypt_type;
@@ -1114,12 +1117,14 @@ loop_set_status(struct loop_device *lo, const struct 
loop_info64 *info)
 
err = loop_init_xfer(lo, xfer, info);
if (err)
-   return err;
+   goto exit;
 
if (lo->lo_offset != info->lo_offset ||
lo->lo_sizelimit != info->lo_sizelimit)
-   if (figure_loop_size(lo, info->lo_offset, info->lo_sizelimit))
-   return -EFBIG;
+   if (figure_loop_size(lo, info->lo_offset, info->lo_sizelimit)) {
+   err = -EFBIG;
+   goto exit;
+   }
 
loop_config_discard(lo);
 
@@ -1156,7 +1161,9 @@ loop_set_status(struct loop_device *lo, const struct 
loop_info64 *info)
/* update dio if lo_offset or transfer is changed */
__loop_update_dio(lo, lo->use_dio);
 
-   return 0;
+ exit:
+   blk_mq_unfreeze_queue(lo->lo_queue);
+   return err;
 }
 
 static int
-- 
2.7.4

Re: [PATCH] checkpatch: add warning on %pk instead of %pK usage

[Joe Perches]

On Sat, 2017-02-11 at 01:32 +, Roberts, William C wrote:
> 
> > > By "normal" I'm referring to things that call into pointer(), just
> > > casually looking I see bstr_printf vsnprintf kvasprintf, which would
> > > be easy enough to add
> > > 
> > > > What do you think is missing?  sn?printf ? That's easy to add.
> > > 
> > > The problem starts to get hairy when we think of how often folks roll
> > > their own logging macros (see some small sampling at the end).
> > > 
> > > I think we would want to add DEBUG DBG and sn?printf and maybe
> > > consider dropping the \b on the regex so it's a bit more matchy but
> > > still shouldn't end up matching on any ASM as you pointed out in the V2 
> > > nack.
> > > 
> > > Ill break this down into:
> > > 1. the patch as I know you'll take it, as you wrote it :-P 2. Adding
> > > to the logging macros 3. exploring making it less matchy
> 
> -Kees and Andrew they likely don't care about the rest of this...
> 
> I have been working up a regex (I suck at these) to match C functions that 
> have an invalid
> %p format string and take arguments:
> http://www.regexr.com/3f92k
> 
> This could be a way to get better coverage in a more generic approach, 
> thoughts?

Maybe this: (attached too because Evolution is a bad email client)

It's still kind of hacky, but it does find multiple line
statements like:

+   printf(KERN_INFO
+  "a %pX",
+  foo);

---
Subject: [PATCH] checkpatch: Add ability to find bad uses of vsprintf %p 
extensions

%pK was at least once misused at %pk in an out-of-tree module.
This lead to some security concerns.  Add the ability to track
single and multiple line statements for misuses of %p.

Signed-off-by: Joe Perches 
---
 scripts/checkpatch.pl | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index ad5ea5c545b2..0eaf6b8580d6 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -5676,6 +5676,32 @@ sub process {
}
}
 
+   # check for vsprintf extension %p misuses
+   if ($^V && $^V ge 5.10.0 &&
+   defined $stat &&
+   $stat =~ /^\+(?![^\{]*\{\s*).*\b(\w+)\s*\(.*$String\s*,/s &&
+   $1 !~ /^_*volatile_*$/) {
+   my $bad_extension = "";
+   my $lc = $stat =~ tr@\n@@;
+   $lc = $lc + $linenr;
+   for (my $count = $linenr; $count <= $lc; $count++) {
+   my $fmt = get_quoted_string($lines[$count - 1], 
raw_line($count, 0));
+   $fmt =~ s/%%//g;
+   if ($fmt =~ 
/(\%[\*\d\.]*p(?![\WFfSsBKRraEhMmIiUDdgVCbGN]).)/) {
+   $bad_extension = $1;
+   last;
+   }
+   }
+   if ($bad_extension ne "") {
+   my $stat_real = raw_line($linenr, 0);
+   for (my $count = $linenr + 1; $count <= $lc; 
$count++) {
+   $stat_real = $stat_real . "\n" . 
raw_line($count, 0);
+   }
+   WARN("VSPRINTF_POINTER_EXTENSION",
+"Invalid vsprintf pointer extension 
'$bad_extension'\n" . "$here\n$stat_real\n");
+   }
+   }
+
 # Check for misused memsets
if ($^V && $^V ge 5.10.0 &&
defined $stat &&
-- 
From 3bd6868711efeb587c5c48e060c415a150fccaca Mon Sep 17 00:00:00 2001
Message-Id: <3bd6868711efeb587c5c48e060c415a150fccaca.1486783224.git@perches.com>
From: Joe Perches 
Date: Fri, 10 Feb 2017 19:17:42 -0800
Subject: [PATCH] checkpatch: Add ability to find bad uses of vsprintf %p
 extensions

%pK was at least once misused at %pk in an out-of-tree module.
This lead to some security concerns.  Add the ability to track
single and multiple line statements for misuses of %p.

Signed-off-by: Joe Perches 
---
 scripts/checkpatch.pl | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index ad5ea5c545b2..0eaf6b8580d6 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -5676,7 +5676,32 @@ sub process {
 			}
 		}
 
+		# check for vsprintf extension %p misuses
+		if ($^V && $^V ge 5.10.0 &&
+		defined $stat &&
+		$stat =~ /^\+(?![^\{]*\{\s*).*\b(\w+)\s*\(.*$String\s*,/s &&
+		$1 !~ /^_*volatile_*$/) {
+			my $bad_extension = "";
+			my $lc = $stat =~ tr@\n@@;
+			$lc = $lc + $linenr;
+		for (my $count = $linenr; $count <= $lc; $count++) {
+my $fmt = get_quoted_string($lines[$count - 1], raw_line($count, 0));
+$fmt =~ s/%%//g;
+if ($fmt =~ 

Re: [PATCH] checkpatch: add warning on %pk instead of %pK usage

[Joe Perches]

On Sat, 2017-02-11 at 01:32 +, Roberts, William C wrote:
> 
> > > By "normal" I'm referring to things that call into pointer(), just
> > > casually looking I see bstr_printf vsnprintf kvasprintf, which would
> > > be easy enough to add
> > > 
> > > > What do you think is missing?  sn?printf ? That's easy to add.
> > > 
> > > The problem starts to get hairy when we think of how often folks roll
> > > their own logging macros (see some small sampling at the end).
> > > 
> > > I think we would want to add DEBUG DBG and sn?printf and maybe
> > > consider dropping the \b on the regex so it's a bit more matchy but
> > > still shouldn't end up matching on any ASM as you pointed out in the V2 
> > > nack.
> > > 
> > > Ill break this down into:
> > > 1. the patch as I know you'll take it, as you wrote it :-P 2. Adding
> > > to the logging macros 3. exploring making it less matchy
> 
> -Kees and Andrew they likely don't care about the rest of this...
> 
> I have been working up a regex (I suck at these) to match C functions that 
> have an invalid
> %p format string and take arguments:
> http://www.regexr.com/3f92k
> 
> This could be a way to get better coverage in a more generic approach, 
> thoughts?

Maybe this: (attached too because Evolution is a bad email client)

It's still kind of hacky, but it does find multiple line
statements like:

+   printf(KERN_INFO
+  "a %pX",
+  foo);

---
Subject: [PATCH] checkpatch: Add ability to find bad uses of vsprintf %p 
extensions

%pK was at least once misused at %pk in an out-of-tree module.
This lead to some security concerns.  Add the ability to track
single and multiple line statements for misuses of %p.

Signed-off-by: Joe Perches 
---
 scripts/checkpatch.pl | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index ad5ea5c545b2..0eaf6b8580d6 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -5676,6 +5676,32 @@ sub process {
}
}
 
+   # check for vsprintf extension %p misuses
+   if ($^V && $^V ge 5.10.0 &&
+   defined $stat &&
+   $stat =~ /^\+(?![^\{]*\{\s*).*\b(\w+)\s*\(.*$String\s*,/s &&
+   $1 !~ /^_*volatile_*$/) {
+   my $bad_extension = "";
+   my $lc = $stat =~ tr@\n@@;
+   $lc = $lc + $linenr;
+   for (my $count = $linenr; $count <= $lc; $count++) {
+   my $fmt = get_quoted_string($lines[$count - 1], 
raw_line($count, 0));
+   $fmt =~ s/%%//g;
+   if ($fmt =~ 
/(\%[\*\d\.]*p(?![\WFfSsBKRraEhMmIiUDdgVCbGN]).)/) {
+   $bad_extension = $1;
+   last;
+   }
+   }
+   if ($bad_extension ne "") {
+   my $stat_real = raw_line($linenr, 0);
+   for (my $count = $linenr + 1; $count <= $lc; 
$count++) {
+   $stat_real = $stat_real . "\n" . 
raw_line($count, 0);
+   }
+   WARN("VSPRINTF_POINTER_EXTENSION",
+"Invalid vsprintf pointer extension 
'$bad_extension'\n" . "$here\n$stat_real\n");
+   }
+   }
+
 # Check for misused memsets
if ($^V && $^V ge 5.10.0 &&
defined $stat &&
-- 
From 3bd6868711efeb587c5c48e060c415a150fccaca Mon Sep 17 00:00:00 2001
Message-Id: <3bd6868711efeb587c5c48e060c415a150fccaca.1486783224.git@perches.com>
From: Joe Perches 
Date: Fri, 10 Feb 2017 19:17:42 -0800
Subject: [PATCH] checkpatch: Add ability to find bad uses of vsprintf %p
 extensions

%pK was at least once misused at %pk in an out-of-tree module.
This lead to some security concerns.  Add the ability to track
single and multiple line statements for misuses of %p.

Signed-off-by: Joe Perches 
---
 scripts/checkpatch.pl | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index ad5ea5c545b2..0eaf6b8580d6 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -5676,7 +5676,32 @@ sub process {
 			}
 		}
 
+		# check for vsprintf extension %p misuses
+		if ($^V && $^V ge 5.10.0 &&
+		defined $stat &&
+		$stat =~ /^\+(?![^\{]*\{\s*).*\b(\w+)\s*\(.*$String\s*,/s &&
+		$1 !~ /^_*volatile_*$/) {
+			my $bad_extension = "";
+			my $lc = $stat =~ tr@\n@@;
+			$lc = $lc + $linenr;
+		for (my $count = $linenr; $count <= $lc; $count++) {
+my $fmt = get_quoted_string($lines[$count - 1], raw_line($count, 0));
+$fmt =~ s/%%//g;
+if ($fmt =~ 

Re: [PATCH 3/3] DT: add Faraday Tec. as vendor

[Joel Stanley]

On Fri, Feb 10, 2017 at 11:46 PM, Linus Walleij
 wrote:
> On Wed, Feb 8, 2017 at 9:00 PM, Hans Ulli Kroll
>  wrote:
>
>> add Faraday Technology Corporation as vendor faraday for DT
>>
>> Signed-off-by: Hans Ulli Kroll 
>
> Reviewed-by: Linus Walleij 
>
> I think I should use this for the PCI block as well, looking over some
> code and the root hub is using Faraday's PCI ID.

Acked-by: Joel Stanley 

This string is already used by the ftgmac100 Ethernet driver. Thanks
for adding it in.

Cheers,

Joel

Re: [PATCH 3/3] DT: add Faraday Tec. as vendor

[Joel Stanley]

On Fri, Feb 10, 2017 at 11:46 PM, Linus Walleij
 wrote:
> On Wed, Feb 8, 2017 at 9:00 PM, Hans Ulli Kroll
>  wrote:
>
>> add Faraday Technology Corporation as vendor faraday for DT
>>
>> Signed-off-by: Hans Ulli Kroll 
>
> Reviewed-by: Linus Walleij 
>
> I think I should use this for the PCI block as well, looking over some
> code and the root hub is using Faraday's PCI ID.

Acked-by: Joel Stanley 

This string is already used by the ftgmac100 Ethernet driver. Thanks
for adding it in.

Cheers,

Joel

Re: [PATCH v4] drivers/misc: Add Aspeed LPC control driver

[Joel Stanley]

Hey Greg,

On Sat, Feb 11, 2017 at 1:00 AM, Greg KH  wrote:
> On Wed, Feb 08, 2017 at 10:42:47AM +1100, Cyril Bur wrote:
>> In order to manage server systems, there is typically another processor
>> known as a BMC (Baseboard Management Controller) which is responsible
>> for powering the server and other various elements, sometimes fans,
>> often the system flash.
>
> Without some other reviewed-by: or at least tested-by lines here, I'm
> not going to take this.  Go poke your fellow ppc people to do some work
> here, it shouldn't be up to me to do it for them :(

We're on it. Thanks for your review so far.

By the way, this is a driver for an ARM SoC, not a PPC chip.
Nevertheless I'm sure those PPC people will still give us a review or
two.

Cheers,

Joel

Re: [PATCH v4] drivers/misc: Add Aspeed LPC control driver

[Joel Stanley]

Hey Greg,

On Sat, Feb 11, 2017 at 1:00 AM, Greg KH  wrote:
> On Wed, Feb 08, 2017 at 10:42:47AM +1100, Cyril Bur wrote:
>> In order to manage server systems, there is typically another processor
>> known as a BMC (Baseboard Management Controller) which is responsible
>> for powering the server and other various elements, sometimes fans,
>> often the system flash.
>
> Without some other reviewed-by: or at least tested-by lines here, I'm
> not going to take this.  Go poke your fellow ppc people to do some work
> here, it shouldn't be up to me to do it for them :(

We're on it. Thanks for your review so far.

By the way, this is a driver for an ARM SoC, not a PPC chip.
Nevertheless I'm sure those PPC people will still give us a review or
two.

Cheers,

Joel

Re: [GIT PULL] PCI fixes for v4.10

[Yinghai Lu]

On Thu, Feb 9, 2017 at 12:11 PM, Bjorn Helgaas  wrote:
> On Thu, Feb 09, 2017 at 09:09:50AM -0600, Bjorn Helgaas wrote:
>> [+cc Ashok, Keith]
>>
>> On Thu, Feb 09, 2017 at 05:06:48AM +0100, Lukas Wunner wrote:
>> > On Wed, Feb 08, 2017 at 01:22:56PM -0600, Bjorn Helgaas wrote:
>> > > Bjorn Helgaas (1):
>> > >   Revert "PCI: pciehp: Add runtime PM support for PCIe hotplug ports"
>> >
>> > What's the rationale for reverting this?
>> >
>> > You've received patches to fix the issue on both affected machines,
>> > so a revert seems unnecessary:
>> >
>> > https://patchwork.kernel.org/patch/9557113/
>> > https://patchwork.kernel.org/patch/9562007/
>>
>> I don't think we've gotten to the root cause of the problem yet,
>> and I don't want to throw in fixes at the last minute without a better
>> understanding of it.
>>
>> PCIe hotplug hardware is not very complicated, it hasn't changed in
>> many years, and at least for the Intel hardware in question, is
>> generally pretty well-tested with Windows.  So I want to be careful
>> about asserting that this new piece of hardware is broken.
>
> I apologize: I had quirks on the brain, but neither of the patches
> above is device-specific.  So neither is claiming broken hardware.
>
> However, 9557113 claims we get unwanted PME interrupts if the slot is
> occupied when we suspend to D3hot.  This is what I want to explore
> further, because that hardware behavior doesn't really make sense to
> me.
>
> 9562007 apparently fixes something, but at this point it's a debugging
> patch (no changelog or signed-off-by) so not a candidate for tossing
> into v4.10 at this late date.

Agreed. It should need more test coverage.

Found more problems.

Actually we don't need 9557113.
as even with that, we still saw link up when power off slots with some cards.

please check updated version of 9562007, that fix power on/off link up problem.

Ashok,

Can ask your QA guys check only attached patch and commit 68db9bc ?

Thanks

Yinghai
Subject:[PATCH v2] PCI, pciechp: Only power on/off slots when it is D0
Found power on via /sys has problem.
sca05-0a81fd7f:~ # echo 1 > /sys/bus/pci/slots/7/power
[  300.949937] pci_hotplug: power_write_file: power = 1
[  300.955502] pciehp :73:00.0:pcie004: pciehp_get_power_status: SLOTCTRL a8 value read 17f1
[  300.982557] pciehp :73:00.0:pcie004: pending interrupts 0x0010 from Slot Status
[  300.991171] pciehp :73:00.0:pcie004: pciehp_power_on_slot: SLOTCTRL a8 write cmd 0
[  301.33] pciehp :73:00.0:pcie004: pciehp_green_led_blink: SLOTCTRL a8 write cmd 200
[  301.009274] pciehp :73:00.0:pcie004: pending interrupts 0x0010 from Slot Status
[  301.662172] pciehp :73:00.0:pcie004: pciehp_check_link_active: lnk_status = f083
[  301.670827] pciehp :73:00.0:pcie004: pending interrupts 0x0108 from Slot Status
[  301.679376] pciehp :73:00.0:pcie004: Slot(7): Link Up
[  301.685463] pciehp :73:00.0:pcie004: Slot(7): Link Up event ignored; already powering on
[  301.685508] pciehp :73:00.0:pcie004: pciehp_check_link_active: lnk_status = f083
[  302.005967] pciehp :73:00.0:pcie004: pciehp_check_link_status: lnk_status = f083
[  302.014859] pci :74:00.0: [15b3:1003] type 00 class 0x0c0600

also find other slot with other card still have extra link up problem on power off
even has can_wake patch.

sca05-0a81fd7f:~ # echo 0 > /sys/bus/pci/slots/1/power 
[ 6116.873632] pci_hotplug: power_write_file: power = 0
[ 6116.879198] pciehp :16:00.0:pcie004: pciehp_get_power_status: SLOTCTRL a8 value read 11f1
[ 6116.888730] pciehp :16:00.0:pcie004: pciehp_unconfigure_device: domain:bus:dev = :17:00
[ 6116.898464] pci :17:00.0: PME# disabled
[ 6116.903541] pci :17:00.0: freeing pci_dev info
[ 6116.909662] pciehp :16:00.0:pcie004: pending interrupts 0x0010 from Slot Status
[ 6116.918277] pciehp :16:00.0:pcie004: pciehp_power_off_slot: SLOTCTRL a8 write cmd 400
[ 6116.982048] pciehp :16:00.0:pcie004: pending interrupts 0x0108 from Slot Status
[ 6116.990608] pciehp :16:00.0:pcie004: Slot(1): Link Down
[ 6116.996876] pciehp :16:00.0:pcie004: Slot(1): Link Down event ignored; already powering off
[ 6117.961521] pciehp :16:00.0:pcie004: pciehp_green_led_off: SLOTCTRL a8 write cmd 300
[ 6117.970575] pciehp :16:00.0:pcie004: pending interrupts 0x0018 from Slot Status
[ 6117.970581] pciehp :16:00.0:pcie004: Slot(1): Card present
[ 6117.985660] pciehp :16:00.0:pcie004: pciehp_get_power_status: SLOTCTRL a8 value read 17f1
[ 6117.995825] pciehp :16:00.0:pcie004: pending interrupts 0x0010 from Slot Status
[ 6118.005489] pciehp :16:00.0:pcie004: pciehp_power_on_slot: SLOTCTRL a8 write cmd 0
[ 6118.014628] pciehp :16:00.0:pcie004: pciehp_green_led_blink: SLOTCTRL a8 write cmd 200
[ 6118.023880] pciehp :16:00.0:pcie004: pending interrupts 0x0010 from Slot Status
[ 6118.602855] pciehp :16:00.0:pcie004: pciehp_check_link_active: lnk_status = f103
[ 

Re: [GIT PULL] PCI fixes for v4.10

[Yinghai Lu]

On Thu, Feb 9, 2017 at 12:11 PM, Bjorn Helgaas  wrote:
> On Thu, Feb 09, 2017 at 09:09:50AM -0600, Bjorn Helgaas wrote:
>> [+cc Ashok, Keith]
>>
>> On Thu, Feb 09, 2017 at 05:06:48AM +0100, Lukas Wunner wrote:
>> > On Wed, Feb 08, 2017 at 01:22:56PM -0600, Bjorn Helgaas wrote:
>> > > Bjorn Helgaas (1):
>> > >   Revert "PCI: pciehp: Add runtime PM support for PCIe hotplug ports"
>> >
>> > What's the rationale for reverting this?
>> >
>> > You've received patches to fix the issue on both affected machines,
>> > so a revert seems unnecessary:
>> >
>> > https://patchwork.kernel.org/patch/9557113/
>> > https://patchwork.kernel.org/patch/9562007/
>>
>> I don't think we've gotten to the root cause of the problem yet,
>> and I don't want to throw in fixes at the last minute without a better
>> understanding of it.
>>
>> PCIe hotplug hardware is not very complicated, it hasn't changed in
>> many years, and at least for the Intel hardware in question, is
>> generally pretty well-tested with Windows.  So I want to be careful
>> about asserting that this new piece of hardware is broken.
>
> I apologize: I had quirks on the brain, but neither of the patches
> above is device-specific.  So neither is claiming broken hardware.
>
> However, 9557113 claims we get unwanted PME interrupts if the slot is
> occupied when we suspend to D3hot.  This is what I want to explore
> further, because that hardware behavior doesn't really make sense to
> me.
>
> 9562007 apparently fixes something, but at this point it's a debugging
> patch (no changelog or signed-off-by) so not a candidate for tossing
> into v4.10 at this late date.

Agreed. It should need more test coverage.

Found more problems.

Actually we don't need 9557113.
as even with that, we still saw link up when power off slots with some cards.

please check updated version of 9562007, that fix power on/off link up problem.

Ashok,

Can ask your QA guys check only attached patch and commit 68db9bc ?

Thanks

Yinghai
Subject:[PATCH v2] PCI, pciechp: Only power on/off slots when it is D0
Found power on via /sys has problem.
sca05-0a81fd7f:~ # echo 1 > /sys/bus/pci/slots/7/power
[  300.949937] pci_hotplug: power_write_file: power = 1
[  300.955502] pciehp :73:00.0:pcie004: pciehp_get_power_status: SLOTCTRL a8 value read 17f1
[  300.982557] pciehp :73:00.0:pcie004: pending interrupts 0x0010 from Slot Status
[  300.991171] pciehp :73:00.0:pcie004: pciehp_power_on_slot: SLOTCTRL a8 write cmd 0
[  301.33] pciehp :73:00.0:pcie004: pciehp_green_led_blink: SLOTCTRL a8 write cmd 200
[  301.009274] pciehp :73:00.0:pcie004: pending interrupts 0x0010 from Slot Status
[  301.662172] pciehp :73:00.0:pcie004: pciehp_check_link_active: lnk_status = f083
[  301.670827] pciehp :73:00.0:pcie004: pending interrupts 0x0108 from Slot Status
[  301.679376] pciehp :73:00.0:pcie004: Slot(7): Link Up
[  301.685463] pciehp :73:00.0:pcie004: Slot(7): Link Up event ignored; already powering on
[  301.685508] pciehp :73:00.0:pcie004: pciehp_check_link_active: lnk_status = f083
[  302.005967] pciehp :73:00.0:pcie004: pciehp_check_link_status: lnk_status = f083
[  302.014859] pci :74:00.0: [15b3:1003] type 00 class 0x0c0600

also find other slot with other card still have extra link up problem on power off
even has can_wake patch.

sca05-0a81fd7f:~ # echo 0 > /sys/bus/pci/slots/1/power 
[ 6116.873632] pci_hotplug: power_write_file: power = 0
[ 6116.879198] pciehp :16:00.0:pcie004: pciehp_get_power_status: SLOTCTRL a8 value read 11f1
[ 6116.888730] pciehp :16:00.0:pcie004: pciehp_unconfigure_device: domain:bus:dev = :17:00
[ 6116.898464] pci :17:00.0: PME# disabled
[ 6116.903541] pci :17:00.0: freeing pci_dev info
[ 6116.909662] pciehp :16:00.0:pcie004: pending interrupts 0x0010 from Slot Status
[ 6116.918277] pciehp :16:00.0:pcie004: pciehp_power_off_slot: SLOTCTRL a8 write cmd 400
[ 6116.982048] pciehp :16:00.0:pcie004: pending interrupts 0x0108 from Slot Status
[ 6116.990608] pciehp :16:00.0:pcie004: Slot(1): Link Down
[ 6116.996876] pciehp :16:00.0:pcie004: Slot(1): Link Down event ignored; already powering off
[ 6117.961521] pciehp :16:00.0:pcie004: pciehp_green_led_off: SLOTCTRL a8 write cmd 300
[ 6117.970575] pciehp :16:00.0:pcie004: pending interrupts 0x0018 from Slot Status
[ 6117.970581] pciehp :16:00.0:pcie004: Slot(1): Card present
[ 6117.985660] pciehp :16:00.0:pcie004: pciehp_get_power_status: SLOTCTRL a8 value read 17f1
[ 6117.995825] pciehp :16:00.0:pcie004: pending interrupts 0x0010 from Slot Status
[ 6118.005489] pciehp :16:00.0:pcie004: pciehp_power_on_slot: SLOTCTRL a8 write cmd 0
[ 6118.014628] pciehp :16:00.0:pcie004: pciehp_green_led_blink: SLOTCTRL a8 write cmd 200
[ 6118.023880] pciehp :16:00.0:pcie004: pending interrupts 0x0010 from Slot Status
[ 6118.602855] pciehp :16:00.0:pcie004: pciehp_check_link_active: lnk_status = f103
[ 6118.611507] pciehp 

[PATCH v6 2/8] devicetree: property-units: Add uWh and uAh units

[Liam Breck]

From: Matt Ranostay 

Add entries for microwatt-hours and microamp-hours.

Cc: Rob Herring 
Cc: Mark Rutland 
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Matt Ranostay 
Signed-off-by: Liam Breck 
Acked-by: Sebastian Reichel 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/property-units.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/property-units.txt 
b/Documentation/devicetree/bindings/property-units.txt
index 12278d7..0849618 100644
--- a/Documentation/devicetree/bindings/property-units.txt
+++ b/Documentation/devicetree/bindings/property-units.txt
@@ -25,8 +25,10 @@ Distance
 Electricity
 
 -microamp  : micro amps
+-microamp-hours : micro amp-hours
 -ohms  : Ohms
 -micro-ohms: micro Ohms
+-microwatt-hours: micro Watt-hours
 -microvolt : micro volts
 
 Temperature
-- 
2.9.3

[PATCH v6 2/8] devicetree: property-units: Add uWh and uAh units

[Liam Breck]

From: Matt Ranostay 

Add entries for microwatt-hours and microamp-hours.

Cc: Rob Herring 
Cc: Mark Rutland 
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Matt Ranostay 
Signed-off-by: Liam Breck 
Acked-by: Sebastian Reichel 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/property-units.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/property-units.txt 
b/Documentation/devicetree/bindings/property-units.txt
index 12278d7..0849618 100644
--- a/Documentation/devicetree/bindings/property-units.txt
+++ b/Documentation/devicetree/bindings/property-units.txt
@@ -25,8 +25,10 @@ Distance
 Electricity
 
 -microamp  : micro amps
+-microamp-hours : micro amp-hours
 -ohms  : Ohms
 -micro-ohms: micro Ohms
+-microwatt-hours: micro Watt-hours
 -microvolt : micro volts
 
 Temperature
-- 
2.9.3

Re: Is it really safe to use workqueues to drive expedited grace periods?

[Tejun Heo]

Hello, Paul.

On Fri, Feb 10, 2017 at 01:21:58PM -0800, Paul E. McKenney wrote:
> So RCU's expedited grace periods have been using workqueues for a
> little while, and things seem to be working.  But as usual, I worry...
> Is this use subject to some sort of deadlock where RCU's workqueue cannot
> start running until after a grace period completes, but that grace
> period is the one needing the workqueue?  Note that there are ways to
> set up your kernel so that all RCU grace periods are expedited.
> 
> Should I be worried?  If not, what prevents this from being a problem,
> especially given that workqueue handlers are allowed to wait for RCU
> grace periods to complete?

A per-cpu (normal) workqueue's concurrency is regulated automatically
so that there are at least one worker running for the worker pool on a
given CPU.

Let's say there are two work items queued on a workqueue.  The first
one is something which will do synchronize_rcu() and the second is the
expedited grace period work item.  When the first one runs
synchronize_rcu(), it'd block.  If there are no other work items
running at the time, workqueue will dispatch another worker so that
there's at least one actively running, which in this case will be the
expedited rcu grace period work item.

The dispatching of a new worker can be delayed by two things - memory
pressure preventing creation of a new worker and the workqueue hitting
maximum concurrency limit.

If expedited RCU grace period is something that memory reclaim path
may depend on, the workqueue that it executes on should have
WQ_MEM_RECLAIM set, which will guarantee that there's at least one
worker (across all CPUs) which is ready to serve the work items on
that workqueue regardless of memory pressure.

The latter, concurrency limit, would only matter if the RCU work items
use system_wq.  system_wq's concurrency limit is very high (512 per
CPU), but it is theoretically possible to fill all up with work items
doing synchronize_rcu() with the expedited RCU work item scheduled
behind it.  The system would already be in a very messed up state
outside the RCU situation tho.

Thanks.

-- 
tejun

Re: Is it really safe to use workqueues to drive expedited grace periods?

[Tejun Heo]

Hello, Paul.

On Fri, Feb 10, 2017 at 01:21:58PM -0800, Paul E. McKenney wrote:
> So RCU's expedited grace periods have been using workqueues for a
> little while, and things seem to be working.  But as usual, I worry...
> Is this use subject to some sort of deadlock where RCU's workqueue cannot
> start running until after a grace period completes, but that grace
> period is the one needing the workqueue?  Note that there are ways to
> set up your kernel so that all RCU grace periods are expedited.
> 
> Should I be worried?  If not, what prevents this from being a problem,
> especially given that workqueue handlers are allowed to wait for RCU
> grace periods to complete?

A per-cpu (normal) workqueue's concurrency is regulated automatically
so that there are at least one worker running for the worker pool on a
given CPU.

Let's say there are two work items queued on a workqueue.  The first
one is something which will do synchronize_rcu() and the second is the
expedited grace period work item.  When the first one runs
synchronize_rcu(), it'd block.  If there are no other work items
running at the time, workqueue will dispatch another worker so that
there's at least one actively running, which in this case will be the
expedited rcu grace period work item.

The dispatching of a new worker can be delayed by two things - memory
pressure preventing creation of a new worker and the workqueue hitting
maximum concurrency limit.

If expedited RCU grace period is something that memory reclaim path
may depend on, the workqueue that it executes on should have
WQ_MEM_RECLAIM set, which will guarantee that there's at least one
worker (across all CPUs) which is ready to serve the work items on
that workqueue regardless of memory pressure.

The latter, concurrency limit, would only matter if the RCU work items
use system_wq.  system_wq's concurrency limit is very high (512 per
CPU), but it is theoretically possible to fill all up with work items
doing synchronize_rcu() with the expedited RCU work item scheduled
behind it.  The system would already be in a very messed up state
outside the RCU situation tho.

Thanks.

-- 
tejun

Re: [RFC PATCH 2/2] mm/sparse: add last_section_nr in sparse_init() to reduce some iteration cycle

[Tejun Heo]

Hello,

On Sat, Feb 11, 2017 at 10:18:29AM +0800, Wei Yang wrote:
> During the sparse_init(), it iterate on each possible section. On x86_64,
> it would always be (2^19) even there is not much memory. For example, on a
> typical 4G machine, it has only (2^5) to (2^6) present sections. This
> benefits more on a system with smaller memory.
> 
> This patch calculates the last section number from the highest pfn and use
> this as the boundary of iteration.

* How much does this actually matter?  Can you measure the impact?

* Do we really need to add full reverse iterator to just get the
  highest section number?

Thanks.

-- 
tejun

Re: [RFC PATCH 2/2] mm/sparse: add last_section_nr in sparse_init() to reduce some iteration cycle

[Tejun Heo]

Hello,

On Sat, Feb 11, 2017 at 10:18:29AM +0800, Wei Yang wrote:
> During the sparse_init(), it iterate on each possible section. On x86_64,
> it would always be (2^19) even there is not much memory. For example, on a
> typical 4G machine, it has only (2^5) to (2^6) present sections. This
> benefits more on a system with smaller memory.
> 
> This patch calculates the last section number from the highest pfn and use
> this as the boundary of iteration.

* How much does this actually matter?  Can you measure the impact?

* Do we really need to add full reverse iterator to just get the
  highest section number?

Thanks.

-- 
tejun

[RFC PATCH 2/2] mm/sparse: add last_section_nr in sparse_init() to reduce some iteration cycle

[Wei Yang]

During the sparse_init(), it iterate on each possible section. On x86_64,
it would always be (2^19) even there is not much memory. For example, on a
typical 4G machine, it has only (2^5) to (2^6) present sections. This
benefits more on a system with smaller memory.

This patch calculates the last section number from the highest pfn and use
this as the boundary of iteration.

Signed-off-by: Wei Yang 
---
 mm/sparse.c | 32 +---
 1 file changed, 21 insertions(+), 11 deletions(-)

diff --git a/mm/sparse.c b/mm/sparse.c
index 1e168bf2779a..d72f390d9e61 100644
--- a/mm/sparse.c
+++ b/mm/sparse.c
@@ -468,18 +468,20 @@ void __weak __meminit vmemmap_populate_print_last(void)
 
 /**
  *  alloc_usemap_and_memmap - memory alloction for pageblock flags and vmemmap
- *  @map: usemap_map for pageblock flags or mmap_map for vmemmap
+ *  @data: usemap_map for pageblock flags or mmap_map for vmemmap
  */
 static void __init alloc_usemap_and_memmap(void (*alloc_func)
(void *, unsigned long, unsigned long,
-   unsigned long, int), void *data)
+   unsigned long, int),
+   void *data,
+   unsigned long last_section_nr)
 {
unsigned long pnum;
unsigned long map_count;
int nodeid_begin = 0;
unsigned long pnum_begin = 0;
 
-   for (pnum = 0; pnum < NR_MEM_SECTIONS; pnum++) {
+   for (pnum = 0; pnum <= last_section_nr; pnum++) {
struct mem_section *ms;
 
if (!present_section_nr(pnum))
@@ -490,7 +492,7 @@ static void __init alloc_usemap_and_memmap(void 
(*alloc_func)
break;
}
map_count = 1;
-   for (pnum = pnum_begin + 1; pnum < NR_MEM_SECTIONS; pnum++) {
+   for (pnum = pnum_begin + 1; pnum <= last_section_nr; pnum++) {
struct mem_section *ms;
int nodeid;
 
@@ -503,16 +505,14 @@ static void __init alloc_usemap_and_memmap(void 
(*alloc_func)
continue;
}
/* ok, we need to take cake of from pnum_begin to pnum - 1*/
-   alloc_func(data, pnum_begin, pnum,
-   map_count, nodeid_begin);
+   alloc_func(data, pnum_begin, pnum, map_count, nodeid_begin);
/* new start, update count etc*/
nodeid_begin = nodeid;
pnum_begin = pnum;
map_count = 1;
}
/* ok, last chunk */
-   alloc_func(data, pnum_begin, NR_MEM_SECTIONS,
-   map_count, nodeid_begin);
+   alloc_func(data, pnum_begin, pnum, map_count, nodeid_begin);
 }
 
 /*
@@ -526,6 +526,9 @@ void __init sparse_init(void)
unsigned long *usemap;
unsigned long **usemap_map;
int size;
+   unsigned long last_section_nr;
+   int i;
+   unsigned long last_pfn = 0;
 #ifdef CONFIG_SPARSEMEM_ALLOC_MEM_MAP_TOGETHER
int size2;
struct page **map_map;
@@ -537,6 +540,11 @@ void __init sparse_init(void)
/* Setup pageblock_order for HUGETLB_PAGE_SIZE_VARIABLE */
set_pageblock_order();
 
+   for_each_mem_pfn_range_rev(i, NUMA_NO_NODE, NULL,
+   _pfn, NULL)
+   break;
+   last_section_nr = pfn_to_section_nr(last_pfn);
+
/*
 * map is using big page (aka 2M in x86 64 bit)
 * usemap is less one page (aka 24 bytes)
@@ -553,7 +561,8 @@ void __init sparse_init(void)
if (!usemap_map)
panic("can not allocate usemap_map\n");
alloc_usemap_and_memmap(sparse_early_usemaps_alloc_node,
-   (void *)usemap_map);
+   (void *)usemap_map,
+   last_section_nr);
 
 #ifdef CONFIG_SPARSEMEM_ALLOC_MEM_MAP_TOGETHER
size2 = sizeof(struct page *) * NR_MEM_SECTIONS;
@@ -561,10 +570,11 @@ void __init sparse_init(void)
if (!map_map)
panic("can not allocate map_map\n");
alloc_usemap_and_memmap(sparse_early_mem_maps_alloc_node,
-   (void *)map_map);
+   (void *)map_map,
+   last_section_nr);
 #endif
 
-   for (pnum = 0; pnum < NR_MEM_SECTIONS; pnum++) {
+   for (pnum = 0; pnum <= last_section_nr; pnum++) {
if (!present_section_nr(pnum))
continue;
 
-- 
2.11.0

[RFC PATCH 2/2] mm/sparse: add last_section_nr in sparse_init() to reduce some iteration cycle

[Wei Yang]

During the sparse_init(), it iterate on each possible section. On x86_64,
it would always be (2^19) even there is not much memory. For example, on a
typical 4G machine, it has only (2^5) to (2^6) present sections. This
benefits more on a system with smaller memory.

This patch calculates the last section number from the highest pfn and use
this as the boundary of iteration.

Signed-off-by: Wei Yang 
---
 mm/sparse.c | 32 +---
 1 file changed, 21 insertions(+), 11 deletions(-)

diff --git a/mm/sparse.c b/mm/sparse.c
index 1e168bf2779a..d72f390d9e61 100644
--- a/mm/sparse.c
+++ b/mm/sparse.c
@@ -468,18 +468,20 @@ void __weak __meminit vmemmap_populate_print_last(void)
 
 /**
  *  alloc_usemap_and_memmap - memory alloction for pageblock flags and vmemmap
- *  @map: usemap_map for pageblock flags or mmap_map for vmemmap
+ *  @data: usemap_map for pageblock flags or mmap_map for vmemmap
  */
 static void __init alloc_usemap_and_memmap(void (*alloc_func)
(void *, unsigned long, unsigned long,
-   unsigned long, int), void *data)
+   unsigned long, int),
+   void *data,
+   unsigned long last_section_nr)
 {
unsigned long pnum;
unsigned long map_count;
int nodeid_begin = 0;
unsigned long pnum_begin = 0;
 
-   for (pnum = 0; pnum < NR_MEM_SECTIONS; pnum++) {
+   for (pnum = 0; pnum <= last_section_nr; pnum++) {
struct mem_section *ms;
 
if (!present_section_nr(pnum))
@@ -490,7 +492,7 @@ static void __init alloc_usemap_and_memmap(void 
(*alloc_func)
break;
}
map_count = 1;
-   for (pnum = pnum_begin + 1; pnum < NR_MEM_SECTIONS; pnum++) {
+   for (pnum = pnum_begin + 1; pnum <= last_section_nr; pnum++) {
struct mem_section *ms;
int nodeid;
 
@@ -503,16 +505,14 @@ static void __init alloc_usemap_and_memmap(void 
(*alloc_func)
continue;
}
/* ok, we need to take cake of from pnum_begin to pnum - 1*/
-   alloc_func(data, pnum_begin, pnum,
-   map_count, nodeid_begin);
+   alloc_func(data, pnum_begin, pnum, map_count, nodeid_begin);
/* new start, update count etc*/
nodeid_begin = nodeid;
pnum_begin = pnum;
map_count = 1;
}
/* ok, last chunk */
-   alloc_func(data, pnum_begin, NR_MEM_SECTIONS,
-   map_count, nodeid_begin);
+   alloc_func(data, pnum_begin, pnum, map_count, nodeid_begin);
 }
 
 /*
@@ -526,6 +526,9 @@ void __init sparse_init(void)
unsigned long *usemap;
unsigned long **usemap_map;
int size;
+   unsigned long last_section_nr;
+   int i;
+   unsigned long last_pfn = 0;
 #ifdef CONFIG_SPARSEMEM_ALLOC_MEM_MAP_TOGETHER
int size2;
struct page **map_map;
@@ -537,6 +540,11 @@ void __init sparse_init(void)
/* Setup pageblock_order for HUGETLB_PAGE_SIZE_VARIABLE */
set_pageblock_order();
 
+   for_each_mem_pfn_range_rev(i, NUMA_NO_NODE, NULL,
+   _pfn, NULL)
+   break;
+   last_section_nr = pfn_to_section_nr(last_pfn);
+
/*
 * map is using big page (aka 2M in x86 64 bit)
 * usemap is less one page (aka 24 bytes)
@@ -553,7 +561,8 @@ void __init sparse_init(void)
if (!usemap_map)
panic("can not allocate usemap_map\n");
alloc_usemap_and_memmap(sparse_early_usemaps_alloc_node,
-   (void *)usemap_map);
+   (void *)usemap_map,
+   last_section_nr);
 
 #ifdef CONFIG_SPARSEMEM_ALLOC_MEM_MAP_TOGETHER
size2 = sizeof(struct page *) * NR_MEM_SECTIONS;
@@ -561,10 +570,11 @@ void __init sparse_init(void)
if (!map_map)
panic("can not allocate map_map\n");
alloc_usemap_and_memmap(sparse_early_mem_maps_alloc_node,
-   (void *)map_map);
+   (void *)map_map,
+   last_section_nr);
 #endif
 
-   for (pnum = 0; pnum < NR_MEM_SECTIONS; pnum++) {
+   for (pnum = 0; pnum <= last_section_nr; pnum++) {
if (!present_section_nr(pnum))
continue;
 
-- 
2.11.0

[RFC PATCH 1/2] mm/memblock: introduce for_each_mem_pfn_range_rev()

[Wei Yang]

This patch introduces the helper function for_each_mem_pfn_range_rev() for
later use.

Signed-off-by: Wei Yang 
---
 include/linux/memblock.h | 18 ++
 mm/memblock.c| 39 ++-
 2 files changed, 56 insertions(+), 1 deletion(-)

diff --git a/include/linux/memblock.h b/include/linux/memblock.h
index 5b759c9acf97..87a0ebe18606 100644
--- a/include/linux/memblock.h
+++ b/include/linux/memblock.h
@@ -203,6 +203,8 @@ int memblock_search_pfn_nid(unsigned long pfn, unsigned 
long *start_pfn,
unsigned long  *end_pfn);
 void __next_mem_pfn_range(int *idx, int nid, unsigned long *out_start_pfn,
  unsigned long *out_end_pfn, int *out_nid);
+void __next_mem_pfn_range_rev(int *idx, int nid, unsigned long *out_start_pfn,
+ unsigned long *out_end_pfn, int *out_nid);
 
 /**
  * for_each_mem_pfn_range - early memory pfn range iterator
@@ -217,6 +219,22 @@ void __next_mem_pfn_range(int *idx, int nid, unsigned long 
*out_start_pfn,
 #define for_each_mem_pfn_range(i, nid, p_start, p_end, p_nid)  \
for (i = -1, __next_mem_pfn_range(, nid, p_start, p_end, p_nid); \
 i >= 0; __next_mem_pfn_range(, nid, p_start, p_end, p_nid))
+
+/**
+ * for_each_mem_pfn_range_rev - early memory pfn range rev-iterator
+ * @i: an integer used as loop variable
+ * @nid: node selector, %NUMA_NO_NODE for all nodes
+ * @p_start: ptr to ulong for start pfn of the range, can be %NULL
+ * @p_end: ptr to ulong for end pfn of the range, can be %NULL
+ * @p_nid: ptr to int for nid of the range, can be %NULL
+ *
+ * Walks over configured memory ranges in reverse order.
+ */
+#define for_each_mem_pfn_range_rev(i, nid, p_start, p_end, p_nid)  \
+   for (i = (int)INT_MAX,  \
+ __next_mem_pfn_range_rev(, nid, p_start, p_end, p_nid); \
+i != (int)INT_MAX; \
+ __next_mem_pfn_range_rev(, nid, p_start, p_end, p_nid))
 #endif /* CONFIG_HAVE_MEMBLOCK_NODE_MAP */
 
 /**
diff --git a/mm/memblock.c b/mm/memblock.c
index 7608bc305936..79490005ecd6 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -1075,7 +1075,7 @@ void __init_memblock __next_mem_range_rev(u64 *idx, int 
nid, ulong flags,
 
 #ifdef CONFIG_HAVE_MEMBLOCK_NODE_MAP
 /*
- * Common iterator interface used to define for_each_mem_range().
+ * Common iterator interface used to define for_each_mem_pfn_range().
  */
 void __init_memblock __next_mem_pfn_range(int *idx, int nid,
unsigned long *out_start_pfn,
@@ -1105,6 +1105,43 @@ void __init_memblock __next_mem_pfn_range(int *idx, int 
nid,
*out_nid = r->nid;
 }
 
+/*
+ * Common rev-iterator interface used to define for_each_mem_pfn_range_rev().
+ */
+void __init_memblock __next_mem_pfn_range_rev(int *idx, int nid,
+   unsigned long *out_start_pfn,
+   unsigned long *out_end_pfn, int *out_nid)
+{
+   struct memblock_type *type = 
+   struct memblock_region *r;
+
+   if (WARN_ONCE(nid == MAX_NUMNODES, "Usage of MAX_NUMNODES is 
deprecated. Use NUMA_NO_NODE instead\n"))
+   nid = NUMA_NO_NODE;
+
+   if (*idx == (int)INT_MAX)
+   *idx = type->cnt;
+
+   while (--*idx >= 0) {
+   r = >regions[*idx];
+
+   if (PFN_UP(r->base) >= PFN_DOWN(r->base + r->size))
+   continue;
+   if (nid == NUMA_NO_NODE || nid == r->nid)
+   break;
+   }
+   if (*idx < 0) {
+   *idx = (int)INT_MAX;
+   return;
+   }
+
+   if (out_start_pfn)
+   *out_start_pfn = PFN_UP(r->base);
+   if (out_end_pfn)
+   *out_end_pfn = PFN_DOWN(r->base + r->size);
+   if (out_nid)
+   *out_nid = r->nid;
+}
+
 /**
  * memblock_set_node - set node ID on memblock regions
  * @base: base of area to set node ID for
-- 
2.11.0

[RFC PATCH 1/2] mm/memblock: introduce for_each_mem_pfn_range_rev()

[Wei Yang]

This patch introduces the helper function for_each_mem_pfn_range_rev() for
later use.

Signed-off-by: Wei Yang 
---
 include/linux/memblock.h | 18 ++
 mm/memblock.c| 39 ++-
 2 files changed, 56 insertions(+), 1 deletion(-)

diff --git a/include/linux/memblock.h b/include/linux/memblock.h
index 5b759c9acf97..87a0ebe18606 100644
--- a/include/linux/memblock.h
+++ b/include/linux/memblock.h
@@ -203,6 +203,8 @@ int memblock_search_pfn_nid(unsigned long pfn, unsigned 
long *start_pfn,
unsigned long  *end_pfn);
 void __next_mem_pfn_range(int *idx, int nid, unsigned long *out_start_pfn,
  unsigned long *out_end_pfn, int *out_nid);
+void __next_mem_pfn_range_rev(int *idx, int nid, unsigned long *out_start_pfn,
+ unsigned long *out_end_pfn, int *out_nid);
 
 /**
  * for_each_mem_pfn_range - early memory pfn range iterator
@@ -217,6 +219,22 @@ void __next_mem_pfn_range(int *idx, int nid, unsigned long 
*out_start_pfn,
 #define for_each_mem_pfn_range(i, nid, p_start, p_end, p_nid)  \
for (i = -1, __next_mem_pfn_range(, nid, p_start, p_end, p_nid); \
 i >= 0; __next_mem_pfn_range(, nid, p_start, p_end, p_nid))
+
+/**
+ * for_each_mem_pfn_range_rev - early memory pfn range rev-iterator
+ * @i: an integer used as loop variable
+ * @nid: node selector, %NUMA_NO_NODE for all nodes
+ * @p_start: ptr to ulong for start pfn of the range, can be %NULL
+ * @p_end: ptr to ulong for end pfn of the range, can be %NULL
+ * @p_nid: ptr to int for nid of the range, can be %NULL
+ *
+ * Walks over configured memory ranges in reverse order.
+ */
+#define for_each_mem_pfn_range_rev(i, nid, p_start, p_end, p_nid)  \
+   for (i = (int)INT_MAX,  \
+ __next_mem_pfn_range_rev(, nid, p_start, p_end, p_nid); \
+i != (int)INT_MAX; \
+ __next_mem_pfn_range_rev(, nid, p_start, p_end, p_nid))
 #endif /* CONFIG_HAVE_MEMBLOCK_NODE_MAP */
 
 /**
diff --git a/mm/memblock.c b/mm/memblock.c
index 7608bc305936..79490005ecd6 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -1075,7 +1075,7 @@ void __init_memblock __next_mem_range_rev(u64 *idx, int 
nid, ulong flags,
 
 #ifdef CONFIG_HAVE_MEMBLOCK_NODE_MAP
 /*
- * Common iterator interface used to define for_each_mem_range().
+ * Common iterator interface used to define for_each_mem_pfn_range().
  */
 void __init_memblock __next_mem_pfn_range(int *idx, int nid,
unsigned long *out_start_pfn,
@@ -1105,6 +1105,43 @@ void __init_memblock __next_mem_pfn_range(int *idx, int 
nid,
*out_nid = r->nid;
 }
 
+/*
+ * Common rev-iterator interface used to define for_each_mem_pfn_range_rev().
+ */
+void __init_memblock __next_mem_pfn_range_rev(int *idx, int nid,
+   unsigned long *out_start_pfn,
+   unsigned long *out_end_pfn, int *out_nid)
+{
+   struct memblock_type *type = 
+   struct memblock_region *r;
+
+   if (WARN_ONCE(nid == MAX_NUMNODES, "Usage of MAX_NUMNODES is 
deprecated. Use NUMA_NO_NODE instead\n"))
+   nid = NUMA_NO_NODE;
+
+   if (*idx == (int)INT_MAX)
+   *idx = type->cnt;
+
+   while (--*idx >= 0) {
+   r = >regions[*idx];
+
+   if (PFN_UP(r->base) >= PFN_DOWN(r->base + r->size))
+   continue;
+   if (nid == NUMA_NO_NODE || nid == r->nid)
+   break;
+   }
+   if (*idx < 0) {
+   *idx = (int)INT_MAX;
+   return;
+   }
+
+   if (out_start_pfn)
+   *out_start_pfn = PFN_UP(r->base);
+   if (out_end_pfn)
+   *out_end_pfn = PFN_DOWN(r->base + r->size);
+   if (out_nid)
+   *out_nid = r->nid;
+}
+
 /**
  * memblock_set_node - set node ID on memblock regions
  * @base: base of area to set node ID for
-- 
2.11.0

Re: [PATCH v2 2/5] time: mark syscore_ops as __ro_after_init

[John Stultz]

On Fri, Feb 10, 2017 at 5:37 PM, Jess Frazelle  wrote:
> Marked syscore_ops structs as __ro_after_init when register_syscore_ops was
> called only during init. Most of the caller functions were already annotated 
> as
> __init.
> unregister_syscore_ops() was never called on these ops.
> This protects the data structure from accidental corruption.
>
> Suggested-by: Kees Cook 
> Signed-off-by: Jess Frazelle 
> Acked-by: Rik van Riel 

Thanks for sending this out. Looks reasonable to me. I'll queue it for
testing, targeting for 4.12.

thanks
-john

Re: [PATCH v2 2/5] time: mark syscore_ops as __ro_after_init

[John Stultz]

On Fri, Feb 10, 2017 at 5:37 PM, Jess Frazelle  wrote:
> Marked syscore_ops structs as __ro_after_init when register_syscore_ops was
> called only during init. Most of the caller functions were already annotated 
> as
> __init.
> unregister_syscore_ops() was never called on these ops.
> This protects the data structure from accidental corruption.
>
> Suggested-by: Kees Cook 
> Signed-off-by: Jess Frazelle 
> Acked-by: Rik van Riel 

Thanks for sending this out. Looks reasonable to me. I'll queue it for
testing, targeting for 4.12.

thanks
-john

[PATCH v13 07/12] usb: ehci: use bus->sysdev for DMA configuration

[Peter Chen]

Set the dma for ehci from sysdev. The sysdev is pointing to device that
is known to the system firmware or hardware.

Cc: Arnd Bergmann 
Cc: Sriram Dash 
Signed-off-by: Peter Chen 
Acked-by: Alan Stern 
---
 drivers/usb/host/ehci-mem.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/host/ehci-mem.c b/drivers/usb/host/ehci-mem.c
index 4de4301..9b7e639 100644
--- a/drivers/usb/host/ehci-mem.c
+++ b/drivers/usb/host/ehci-mem.c
@@ -138,7 +138,7 @@ static void ehci_mem_cleanup (struct ehci_hcd *ehci)
ehci->sitd_pool = NULL;
 
if (ehci->periodic)
-   dma_free_coherent (ehci_to_hcd(ehci)->self.controller,
+   dma_free_coherent(ehci_to_hcd(ehci)->self.sysdev,
ehci->periodic_size * sizeof (u32),
ehci->periodic, ehci->periodic_dma);
ehci->periodic = NULL;
@@ -155,7 +155,7 @@ static int ehci_mem_init (struct ehci_hcd *ehci, gfp_t 
flags)
 
/* QTDs for control/bulk/intr transfers */
ehci->qtd_pool = dma_pool_create ("ehci_qtd",
-   ehci_to_hcd(ehci)->self.controller,
+   ehci_to_hcd(ehci)->self.sysdev,
sizeof (struct ehci_qtd),
32 /* byte alignment (for hw parts) */,
4096 /* can't cross 4K */);
@@ -165,7 +165,7 @@ static int ehci_mem_init (struct ehci_hcd *ehci, gfp_t 
flags)
 
/* QHs for control/bulk/intr transfers */
ehci->qh_pool = dma_pool_create ("ehci_qh",
-   ehci_to_hcd(ehci)->self.controller,
+   ehci_to_hcd(ehci)->self.sysdev,
sizeof(struct ehci_qh_hw),
32 /* byte alignment (for hw parts) */,
4096 /* can't cross 4K */);
@@ -179,7 +179,7 @@ static int ehci_mem_init (struct ehci_hcd *ehci, gfp_t 
flags)
 
/* ITD for high speed ISO transfers */
ehci->itd_pool = dma_pool_create ("ehci_itd",
-   ehci_to_hcd(ehci)->self.controller,
+   ehci_to_hcd(ehci)->self.sysdev,
sizeof (struct ehci_itd),
32 /* byte alignment (for hw parts) */,
4096 /* can't cross 4K */);
@@ -189,7 +189,7 @@ static int ehci_mem_init (struct ehci_hcd *ehci, gfp_t 
flags)
 
/* SITD for full/low speed split ISO transfers */
ehci->sitd_pool = dma_pool_create ("ehci_sitd",
-   ehci_to_hcd(ehci)->self.controller,
+   ehci_to_hcd(ehci)->self.sysdev,
sizeof (struct ehci_sitd),
32 /* byte alignment (for hw parts) */,
4096 /* can't cross 4K */);
@@ -199,7 +199,7 @@ static int ehci_mem_init (struct ehci_hcd *ehci, gfp_t 
flags)
 
/* Hardware periodic table */
ehci->periodic = (__le32 *)
-   dma_alloc_coherent (ehci_to_hcd(ehci)->self.controller,
+   dma_alloc_coherent(ehci_to_hcd(ehci)->self.sysdev,
ehci->periodic_size * sizeof(__le32),
>periodic_dma, flags);
if (ehci->periodic == NULL) {
-- 
2.7.4

[PATCH v13 07/12] usb: ehci: use bus->sysdev for DMA configuration

[Peter Chen]

Set the dma for ehci from sysdev. The sysdev is pointing to device that
is known to the system firmware or hardware.

Cc: Arnd Bergmann 
Cc: Sriram Dash 
Signed-off-by: Peter Chen 
Acked-by: Alan Stern 
---
 drivers/usb/host/ehci-mem.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/host/ehci-mem.c b/drivers/usb/host/ehci-mem.c
index 4de4301..9b7e639 100644
--- a/drivers/usb/host/ehci-mem.c
+++ b/drivers/usb/host/ehci-mem.c
@@ -138,7 +138,7 @@ static void ehci_mem_cleanup (struct ehci_hcd *ehci)
ehci->sitd_pool = NULL;
 
if (ehci->periodic)
-   dma_free_coherent (ehci_to_hcd(ehci)->self.controller,
+   dma_free_coherent(ehci_to_hcd(ehci)->self.sysdev,
ehci->periodic_size * sizeof (u32),
ehci->periodic, ehci->periodic_dma);
ehci->periodic = NULL;
@@ -155,7 +155,7 @@ static int ehci_mem_init (struct ehci_hcd *ehci, gfp_t 
flags)
 
/* QTDs for control/bulk/intr transfers */
ehci->qtd_pool = dma_pool_create ("ehci_qtd",
-   ehci_to_hcd(ehci)->self.controller,
+   ehci_to_hcd(ehci)->self.sysdev,
sizeof (struct ehci_qtd),
32 /* byte alignment (for hw parts) */,
4096 /* can't cross 4K */);
@@ -165,7 +165,7 @@ static int ehci_mem_init (struct ehci_hcd *ehci, gfp_t 
flags)
 
/* QHs for control/bulk/intr transfers */
ehci->qh_pool = dma_pool_create ("ehci_qh",
-   ehci_to_hcd(ehci)->self.controller,
+   ehci_to_hcd(ehci)->self.sysdev,
sizeof(struct ehci_qh_hw),
32 /* byte alignment (for hw parts) */,
4096 /* can't cross 4K */);
@@ -179,7 +179,7 @@ static int ehci_mem_init (struct ehci_hcd *ehci, gfp_t 
flags)
 
/* ITD for high speed ISO transfers */
ehci->itd_pool = dma_pool_create ("ehci_itd",
-   ehci_to_hcd(ehci)->self.controller,
+   ehci_to_hcd(ehci)->self.sysdev,
sizeof (struct ehci_itd),
32 /* byte alignment (for hw parts) */,
4096 /* can't cross 4K */);
@@ -189,7 +189,7 @@ static int ehci_mem_init (struct ehci_hcd *ehci, gfp_t 
flags)
 
/* SITD for full/low speed split ISO transfers */
ehci->sitd_pool = dma_pool_create ("ehci_sitd",
-   ehci_to_hcd(ehci)->self.controller,
+   ehci_to_hcd(ehci)->self.sysdev,
sizeof (struct ehci_sitd),
32 /* byte alignment (for hw parts) */,
4096 /* can't cross 4K */);
@@ -199,7 +199,7 @@ static int ehci_mem_init (struct ehci_hcd *ehci, gfp_t 
flags)
 
/* Hardware periodic table */
ehci->periodic = (__le32 *)
-   dma_alloc_coherent (ehci_to_hcd(ehci)->self.controller,
+   dma_alloc_coherent(ehci_to_hcd(ehci)->self.sysdev,
ehci->periodic_size * sizeof(__le32),
>periodic_dma, flags);
if (ehci->periodic == NULL) {
-- 
2.7.4

[PATCH v13 06/12] usb: xhci: use bus->sysdev for DMA configuration

[Peter Chen]

From: Arnd Bergmann 

For xhci-hcd platform device, all the DMA parameters are not
configured properly, notably dma ops for dwc3 devices. So, set
the dma for xhci from sysdev. sysdev is pointing to device that
is known to the system firmware or hardware.

Cc: Baolin Wang 
Cc: Vivek Gautam 
Cc: Alexander Sverdlin 
Cc: Mathias Nyman 

Signed-off-by: Arnd Bergmann 
Signed-off-by: Sriram Dash 
---
Hi, Baolin, Vivek and Alexander,
I removed your tested-by tag due to add one change that adding sysdev
for shared hcd too, if your test shows this change works for you or
has no effect for you, please consider adding tested-by tag again,
thanks.

 drivers/usb/host/xhci-mem.c  | 12 ++--
 drivers/usb/host/xhci-plat.c | 35 +++
 drivers/usb/host/xhci.c  | 15 +++
 3 files changed, 44 insertions(+), 18 deletions(-)

diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index ba1853f4..032a702 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -586,7 +586,7 @@ static void xhci_free_stream_ctx(struct xhci_hcd *xhci,
unsigned int num_stream_ctxs,
struct xhci_stream_ctx *stream_ctx, dma_addr_t dma)
 {
-   struct device *dev = xhci_to_hcd(xhci)->self.controller;
+   struct device *dev = xhci_to_hcd(xhci)->self.sysdev;
size_t size = sizeof(struct xhci_stream_ctx) * num_stream_ctxs;
 
if (size > MEDIUM_STREAM_ARRAY_SIZE)
@@ -614,7 +614,7 @@ static struct xhci_stream_ctx *xhci_alloc_stream_ctx(struct 
xhci_hcd *xhci,
unsigned int num_stream_ctxs, dma_addr_t *dma,
gfp_t mem_flags)
 {
-   struct device *dev = xhci_to_hcd(xhci)->self.controller;
+   struct device *dev = xhci_to_hcd(xhci)->self.sysdev;
size_t size = sizeof(struct xhci_stream_ctx) * num_stream_ctxs;
 
if (size > MEDIUM_STREAM_ARRAY_SIZE)
@@ -1686,7 +1686,7 @@ void xhci_slot_copy(struct xhci_hcd *xhci,
 static int scratchpad_alloc(struct xhci_hcd *xhci, gfp_t flags)
 {
int i;
-   struct device *dev = xhci_to_hcd(xhci)->self.controller;
+   struct device *dev = xhci_to_hcd(xhci)->self.sysdev;
int num_sp = HCS_MAX_SCRATCHPAD(xhci->hcs_params2);
 
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
@@ -1758,7 +1758,7 @@ static void scratchpad_free(struct xhci_hcd *xhci)
 {
int num_sp;
int i;
-   struct device *dev = xhci_to_hcd(xhci)->self.controller;
+   struct device *dev = xhci_to_hcd(xhci)->self.sysdev;
 
if (!xhci->scratchpad)
return;
@@ -1831,7 +1831,7 @@ void xhci_free_command(struct xhci_hcd *xhci,
 
 void xhci_mem_cleanup(struct xhci_hcd *xhci)
 {
-   struct device   *dev = xhci_to_hcd(xhci)->self.controller;
+   struct device   *dev = xhci_to_hcd(xhci)->self.sysdev;
int size;
int i, j, num_ports;
 
@@ -2373,7 +2373,7 @@ static int xhci_setup_port_arrays(struct xhci_hcd *xhci, 
gfp_t flags)
 int xhci_mem_init(struct xhci_hcd *xhci, gfp_t flags)
 {
dma_addr_t  dma;
-   struct device   *dev = xhci_to_hcd(xhci)->self.controller;
+   struct device   *dev = xhci_to_hcd(xhci)->self.sysdev;
unsigned intval, val2;
u64 val_64;
struct xhci_segment *seg;
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 6d33b42..4ecb3fd 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -148,6 +149,7 @@ static int xhci_plat_probe(struct platform_device *pdev)
 {
const struct of_device_id *match;
const struct hc_driver  *driver;
+   struct device   *sysdev;
struct xhci_hcd *xhci;
struct resource *res;
struct usb_hcd  *hcd;
@@ -164,22 +166,39 @@ static int xhci_plat_probe(struct platform_device *pdev)
if (irq < 0)
return -ENODEV;
 
+   /*
+* sysdev must point to a device that is known to the system firmware
+* or PCI hardware. We handle these three cases here:
+* 1. xhci_plat comes from firmware
+* 2. xhci_plat is child of a device from firmware (dwc3-plat)
+* 3. xhci_plat is grandchild of a pci device (dwc3-pci)
+*/
+   sysdev = >dev;
+   if (sysdev->parent && !sysdev->of_node && sysdev->parent->of_node)
+   sysdev = sysdev->parent;
+#ifdef CONFIG_PCI
+   else if (sysdev->parent && sysdev->parent->parent &&
+sysdev->parent->parent->bus == _bus_type)
+   sysdev = sysdev->parent->parent;
+#endif
+
/* Try to set 64-bit DMA first */
-   if (!pdev->dev.dma_mask)
+   if (WARN_ON(!sysdev->dma_mask))
 

[PATCH v13 06/12] usb: xhci: use bus->sysdev for DMA configuration

[Peter Chen]

From: Arnd Bergmann 

For xhci-hcd platform device, all the DMA parameters are not
configured properly, notably dma ops for dwc3 devices. So, set
the dma for xhci from sysdev. sysdev is pointing to device that
is known to the system firmware or hardware.

Cc: Baolin Wang 
Cc: Vivek Gautam 
Cc: Alexander Sverdlin 
Cc: Mathias Nyman 

Signed-off-by: Arnd Bergmann 
Signed-off-by: Sriram Dash 
---
Hi, Baolin, Vivek and Alexander,
I removed your tested-by tag due to add one change that adding sysdev
for shared hcd too, if your test shows this change works for you or
has no effect for you, please consider adding tested-by tag again,
thanks.

 drivers/usb/host/xhci-mem.c  | 12 ++--
 drivers/usb/host/xhci-plat.c | 35 +++
 drivers/usb/host/xhci.c  | 15 +++
 3 files changed, 44 insertions(+), 18 deletions(-)

diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index ba1853f4..032a702 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -586,7 +586,7 @@ static void xhci_free_stream_ctx(struct xhci_hcd *xhci,
unsigned int num_stream_ctxs,
struct xhci_stream_ctx *stream_ctx, dma_addr_t dma)
 {
-   struct device *dev = xhci_to_hcd(xhci)->self.controller;
+   struct device *dev = xhci_to_hcd(xhci)->self.sysdev;
size_t size = sizeof(struct xhci_stream_ctx) * num_stream_ctxs;
 
if (size > MEDIUM_STREAM_ARRAY_SIZE)
@@ -614,7 +614,7 @@ static struct xhci_stream_ctx *xhci_alloc_stream_ctx(struct 
xhci_hcd *xhci,
unsigned int num_stream_ctxs, dma_addr_t *dma,
gfp_t mem_flags)
 {
-   struct device *dev = xhci_to_hcd(xhci)->self.controller;
+   struct device *dev = xhci_to_hcd(xhci)->self.sysdev;
size_t size = sizeof(struct xhci_stream_ctx) * num_stream_ctxs;
 
if (size > MEDIUM_STREAM_ARRAY_SIZE)
@@ -1686,7 +1686,7 @@ void xhci_slot_copy(struct xhci_hcd *xhci,
 static int scratchpad_alloc(struct xhci_hcd *xhci, gfp_t flags)
 {
int i;
-   struct device *dev = xhci_to_hcd(xhci)->self.controller;
+   struct device *dev = xhci_to_hcd(xhci)->self.sysdev;
int num_sp = HCS_MAX_SCRATCHPAD(xhci->hcs_params2);
 
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
@@ -1758,7 +1758,7 @@ static void scratchpad_free(struct xhci_hcd *xhci)
 {
int num_sp;
int i;
-   struct device *dev = xhci_to_hcd(xhci)->self.controller;
+   struct device *dev = xhci_to_hcd(xhci)->self.sysdev;
 
if (!xhci->scratchpad)
return;
@@ -1831,7 +1831,7 @@ void xhci_free_command(struct xhci_hcd *xhci,
 
 void xhci_mem_cleanup(struct xhci_hcd *xhci)
 {
-   struct device   *dev = xhci_to_hcd(xhci)->self.controller;
+   struct device   *dev = xhci_to_hcd(xhci)->self.sysdev;
int size;
int i, j, num_ports;
 
@@ -2373,7 +2373,7 @@ static int xhci_setup_port_arrays(struct xhci_hcd *xhci, 
gfp_t flags)
 int xhci_mem_init(struct xhci_hcd *xhci, gfp_t flags)
 {
dma_addr_t  dma;
-   struct device   *dev = xhci_to_hcd(xhci)->self.controller;
+   struct device   *dev = xhci_to_hcd(xhci)->self.sysdev;
unsigned intval, val2;
u64 val_64;
struct xhci_segment *seg;
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 6d33b42..4ecb3fd 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -148,6 +149,7 @@ static int xhci_plat_probe(struct platform_device *pdev)
 {
const struct of_device_id *match;
const struct hc_driver  *driver;
+   struct device   *sysdev;
struct xhci_hcd *xhci;
struct resource *res;
struct usb_hcd  *hcd;
@@ -164,22 +166,39 @@ static int xhci_plat_probe(struct platform_device *pdev)
if (irq < 0)
return -ENODEV;
 
+   /*
+* sysdev must point to a device that is known to the system firmware
+* or PCI hardware. We handle these three cases here:
+* 1. xhci_plat comes from firmware
+* 2. xhci_plat is child of a device from firmware (dwc3-plat)
+* 3. xhci_plat is grandchild of a pci device (dwc3-pci)
+*/
+   sysdev = >dev;
+   if (sysdev->parent && !sysdev->of_node && sysdev->parent->of_node)
+   sysdev = sysdev->parent;
+#ifdef CONFIG_PCI
+   else if (sysdev->parent && sysdev->parent->parent &&
+sysdev->parent->parent->bus == _bus_type)
+   sysdev = sysdev->parent->parent;
+#endif
+
/* Try to set 64-bit DMA first */
-   if (!pdev->dev.dma_mask)
+   if (WARN_ON(!sysdev->dma_mask))
/* Platform did not initialize dma_mask */
-   ret = dma_coerce_mask_and_coherent(>dev,
+   ret = 

[PATCH v13 10/12] ARM: dts: imx6qdl: Enable usb node children with

[Peter Chen]

From: Joshua Clayton 

Give usb nodes #address and #size attributes, so that a child node
representing a permanently connected device such as an onboard hub may
be addressed with a  attribute

Signed-off-by: Joshua Clayton 
Signed-off-by: Peter Chen 
---
 arch/arm/boot/dts/imx6qdl.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 89b834f..a00de77 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -936,6 +936,8 @@
 
usbh1: usb@02184200 {
compatible = "fsl,imx6q-usb", "fsl,imx27-usb";
+   #address-cells = <1>;
+   #size-cells = <0>;
reg = <0x02184200 0x200>;
interrupts = <0 40 IRQ_TYPE_LEVEL_HIGH>;
clocks = < IMX6QDL_CLK_USBOH3>;
@@ -950,6 +952,8 @@
 
usbh2: usb@02184400 {
compatible = "fsl,imx6q-usb", "fsl,imx27-usb";
+   #address-cells = <1>;
+   #size-cells = <0>;
reg = <0x02184400 0x200>;
interrupts = <0 41 IRQ_TYPE_LEVEL_HIGH>;
clocks = < IMX6QDL_CLK_USBOH3>;
@@ -963,6 +967,8 @@
 
usbh3: usb@02184600 {
compatible = "fsl,imx6q-usb", "fsl,imx27-usb";
+   #address-cells = <1>;
+   #size-cells = <0>;
reg = <0x02184600 0x200>;
interrupts = <0 42 IRQ_TYPE_LEVEL_HIGH>;
clocks = < IMX6QDL_CLK_USBOH3>;
-- 
2.7.4

[PATCH v13 10/12] ARM: dts: imx6qdl: Enable usb node children with

[Peter Chen]

From: Joshua Clayton 

Give usb nodes #address and #size attributes, so that a child node
representing a permanently connected device such as an onboard hub may
be addressed with a  attribute

Signed-off-by: Joshua Clayton 
Signed-off-by: Peter Chen 
---
 arch/arm/boot/dts/imx6qdl.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 89b834f..a00de77 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -936,6 +936,8 @@
 
usbh1: usb@02184200 {
compatible = "fsl,imx6q-usb", "fsl,imx27-usb";
+   #address-cells = <1>;
+   #size-cells = <0>;
reg = <0x02184200 0x200>;
interrupts = <0 40 IRQ_TYPE_LEVEL_HIGH>;
clocks = < IMX6QDL_CLK_USBOH3>;
@@ -950,6 +952,8 @@
 
usbh2: usb@02184400 {
compatible = "fsl,imx6q-usb", "fsl,imx27-usb";
+   #address-cells = <1>;
+   #size-cells = <0>;
reg = <0x02184400 0x200>;
interrupts = <0 41 IRQ_TYPE_LEVEL_HIGH>;
clocks = < IMX6QDL_CLK_USBOH3>;
@@ -963,6 +967,8 @@
 
usbh3: usb@02184600 {
compatible = "fsl,imx6q-usb", "fsl,imx27-usb";
+   #address-cells = <1>;
+   #size-cells = <0>;
reg = <0x02184600 0x200>;
interrupts = <0 42 IRQ_TYPE_LEVEL_HIGH>;
clocks = < IMX6QDL_CLK_USBOH3>;
-- 
2.7.4

[PATCH v13 02/12] power: add power sequence library

[Peter Chen]

We have an well-known problem that the device needs to do some power
sequence before it can be recognized by related host, the typical
example like hard-wired mmc devices and usb devices.

This power sequence is hard to be described at device tree and handled by
related host driver, so we have created a common power sequence
library to cover this requirement. The core code has supplied
some common helpers for host driver, and individual power sequence
libraries handle kinds of power sequence for devices. The pwrseq
librares always need to allocate extra instance for compatible
string match.

pwrseq_generic is intended for general purpose of power sequence, which
handles gpios and clocks currently, and can cover other controls in
future. The host driver just needs to call of_pwrseq_on/of_pwrseq_off
if only one power sequence is needed, else call of_pwrseq_on_list
/of_pwrseq_off_list instead (eg, USB hub driver).

For new power sequence library, it can add its compatible string
to pwrseq_of_match_table, then the pwrseq core will match it with
DT's, and choose this library at runtime.

Signed-off-by: Peter Chen 
Tested-by: Maciej S. Szmigiero 
Tested-by Joshua Clayton 
Reviewed-by: Matthias Kaehlcke 
Tested-by: Matthias Kaehlcke 
---
 Documentation/power/power-sequence/design.rst |  54 +
 MAINTAINERS   |   9 +
 drivers/power/Kconfig |   1 +
 drivers/power/Makefile|   1 +
 drivers/power/pwrseq/Kconfig  |  20 ++
 drivers/power/pwrseq/Makefile |   2 +
 drivers/power/pwrseq/core.c   | 335 ++
 drivers/power/pwrseq/pwrseq_generic.c | 234 ++
 include/linux/power/pwrseq.h  |  81 +++
 9 files changed, 737 insertions(+)
 create mode 100644 Documentation/power/power-sequence/design.rst
 create mode 100644 drivers/power/pwrseq/Kconfig
 create mode 100644 drivers/power/pwrseq/Makefile
 create mode 100644 drivers/power/pwrseq/core.c
 create mode 100644 drivers/power/pwrseq/pwrseq_generic.c
 create mode 100644 include/linux/power/pwrseq.h

diff --git a/Documentation/power/power-sequence/design.rst 
b/Documentation/power/power-sequence/design.rst
new file mode 100644
index 000..554608e
--- /dev/null
+++ b/Documentation/power/power-sequence/design.rst
@@ -0,0 +1,54 @@
+
+Power Sequence Library
+
+
+:Date: Feb, 2017
+:Author: Peter Chen 
+
+
+Introduction
+
+
+We have an well-known problem that the device needs to do a power
+sequence before it can be recognized by related host, the typical
+examples are hard-wired mmc devices and usb devices. The host controller
+can't know what kinds of this device is in its bus if the power
+sequence has not done, since the related devices driver's probe calling
+is determined by runtime according to eunumeration results. Besides,
+the devices may have custom power sequence, so the power sequence library
+which is independent with the devices is needed.
+
+Design
+
+
+The power sequence library includes the core file and customer power
+sequence library. The core file exports interfaces are called by
+host controller driver for power sequence and customer power sequence
+library files to register its power sequence instance to global
+power sequence list. The custom power sequence library creates power
+sequence instance and implement custom power sequence.
+
+Since the power sequence describes hardware design, the description is
+located at board description file, eg, device tree dts file. And
+a specific power sequence belongs to device, so its description
+is under the device node, please refer to:
+Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
+
+Custom power sequence library allocates one power sequence instance at
+bootup periods using postcore_initcall, this static allocated instance is
+used to compare with device-tree (DT) node to see if this library can be
+used for the node or not. When the result is matched, the core API will
+try to get resourses (->get, implemented at each library) for power
+sequence, if all resources are got, it will try to allocate another
+instance for next possible request from host driver.
+
+Then, the host controller driver can carry out power sequence on for this
+DT node, the library will do corresponding operations, like open clocks,
+toggle gpio, etc. The power sequence off routine will close and free the
+resources, and is called when the parent is removed. And the power
+sequence suspend and resume routine can be called at host driver's
+suspend and resume routine if needed.
+
+The exported interfaces
+.. kernel-doc:: drivers/power/pwrseq/core.c
+   :export:
diff --git a/MAINTAINERS b/MAINTAINERS
index 

[PATCH v13 02/12] power: add power sequence library

[Peter Chen]

We have an well-known problem that the device needs to do some power
sequence before it can be recognized by related host, the typical
example like hard-wired mmc devices and usb devices.

This power sequence is hard to be described at device tree and handled by
related host driver, so we have created a common power sequence
library to cover this requirement. The core code has supplied
some common helpers for host driver, and individual power sequence
libraries handle kinds of power sequence for devices. The pwrseq
librares always need to allocate extra instance for compatible
string match.

pwrseq_generic is intended for general purpose of power sequence, which
handles gpios and clocks currently, and can cover other controls in
future. The host driver just needs to call of_pwrseq_on/of_pwrseq_off
if only one power sequence is needed, else call of_pwrseq_on_list
/of_pwrseq_off_list instead (eg, USB hub driver).

For new power sequence library, it can add its compatible string
to pwrseq_of_match_table, then the pwrseq core will match it with
DT's, and choose this library at runtime.

Signed-off-by: Peter Chen 
Tested-by: Maciej S. Szmigiero 
Tested-by Joshua Clayton 
Reviewed-by: Matthias Kaehlcke 
Tested-by: Matthias Kaehlcke 
---
 Documentation/power/power-sequence/design.rst |  54 +
 MAINTAINERS   |   9 +
 drivers/power/Kconfig |   1 +
 drivers/power/Makefile|   1 +
 drivers/power/pwrseq/Kconfig  |  20 ++
 drivers/power/pwrseq/Makefile |   2 +
 drivers/power/pwrseq/core.c   | 335 ++
 drivers/power/pwrseq/pwrseq_generic.c | 234 ++
 include/linux/power/pwrseq.h  |  81 +++
 9 files changed, 737 insertions(+)
 create mode 100644 Documentation/power/power-sequence/design.rst
 create mode 100644 drivers/power/pwrseq/Kconfig
 create mode 100644 drivers/power/pwrseq/Makefile
 create mode 100644 drivers/power/pwrseq/core.c
 create mode 100644 drivers/power/pwrseq/pwrseq_generic.c
 create mode 100644 include/linux/power/pwrseq.h

diff --git a/Documentation/power/power-sequence/design.rst 
b/Documentation/power/power-sequence/design.rst
new file mode 100644
index 000..554608e
--- /dev/null
+++ b/Documentation/power/power-sequence/design.rst
@@ -0,0 +1,54 @@
+
+Power Sequence Library
+
+
+:Date: Feb, 2017
+:Author: Peter Chen 
+
+
+Introduction
+
+
+We have an well-known problem that the device needs to do a power
+sequence before it can be recognized by related host, the typical
+examples are hard-wired mmc devices and usb devices. The host controller
+can't know what kinds of this device is in its bus if the power
+sequence has not done, since the related devices driver's probe calling
+is determined by runtime according to eunumeration results. Besides,
+the devices may have custom power sequence, so the power sequence library
+which is independent with the devices is needed.
+
+Design
+
+
+The power sequence library includes the core file and customer power
+sequence library. The core file exports interfaces are called by
+host controller driver for power sequence and customer power sequence
+library files to register its power sequence instance to global
+power sequence list. The custom power sequence library creates power
+sequence instance and implement custom power sequence.
+
+Since the power sequence describes hardware design, the description is
+located at board description file, eg, device tree dts file. And
+a specific power sequence belongs to device, so its description
+is under the device node, please refer to:
+Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
+
+Custom power sequence library allocates one power sequence instance at
+bootup periods using postcore_initcall, this static allocated instance is
+used to compare with device-tree (DT) node to see if this library can be
+used for the node or not. When the result is matched, the core API will
+try to get resourses (->get, implemented at each library) for power
+sequence, if all resources are got, it will try to allocate another
+instance for next possible request from host driver.
+
+Then, the host controller driver can carry out power sequence on for this
+DT node, the library will do corresponding operations, like open clocks,
+toggle gpio, etc. The power sequence off routine will close and free the
+resources, and is called when the parent is removed. And the power
+sequence suspend and resume routine can be called at host driver's
+suspend and resume routine if needed.
+
+The exported interfaces
+.. kernel-doc:: drivers/power/pwrseq/core.c
+   :export:
diff --git a/MAINTAINERS b/MAINTAINERS
index 187b961..e5cbf7d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9854,6 +9854,15 @@ F:   include/linux/pm_*
 F: 

[PATCH v13 00/12] power: add power sequence library

[Peter Chen]

Hi all,

This is a follow-up for my last power sequence framework patch set [1].
According to Rob Herring and Ulf Hansson's comments[2]. The kinds of
power sequence instances will be added at postcore_initcall, the match
criteria is compatible string first, if the compatible string is not
matched between dts and library, it will try to use generic power sequence.
 
The host driver just needs to call of_pwrseq_on/of_pwrseq_off
if only one power sequence instance is needed, for more power sequences
are used, using of_pwrseq_on_list/of_pwrseq_off_list instead (eg, USB hub 
driver).

In future, if there are special power sequence requirements, the special
power sequence library can be created.

This patch set is tested on i.mx6 sabresx evk using a dts change, I use
two hot-plug devices to simulate this use case, the related binding
change is updated at patch [1/6], The udoo board changes were tested
using my last power sequence patch set.[3]

Except for hard-wired MMC and USB devices, I find the USB ULPI PHY also
need to power on itself before it can be found by ULPI bus.

Changes for v13:
- Add more design descriptions at design doc and fix one build error
  introduced by v12 wrongly [Patch 2/12]
- Add the last three dts patches which were forgotten at last series
- Move the comment for usb_create_shared_hcd to correct place [Patch 3/12]
- Add sysdev for shared hcd too for xhci-plat.c [Patch 6/12]

Rafael, if the first two power sequence patches are ok for you, would you 
consider
accept these first, the other USB patches can go through USB tree at v4.12-rc1?

Changes for v12:
- Add design doc and more comments at generic power sequence source file [Patch 
2/9]
- Introduce four Arnd Bergmann patches and one my ehci related patches, these 
patches
  are used to get property DT/firmware information at USB code, and these 
information
  are needed for power sequence operation at USB. With these five patches, my 
chipidea
  hack patch in previous patch set can be removed. [Patch 3-7/9]
- Add -ENOENT judgement to avoid USB error if no power sequence library is 
chosen [9/9]

Changes for v11:
- Fix warning: (USB) selects POWER_SEQUENCE which has unmet direct dependencies 
(OF)
- Delete redundant copyright statement.
- Change pr_warn to pr_debug at wrseq_find_available_instance
- Refine kerneldoc
- %s/ENONET/ENOENT 
- Allocate pwrseq list node before than carry out power sequence on 
- Add mutex_lock/mutex_lock for pwrseq node browse at 
pwrseq_find_available_instance
- Add pwrseq_suspend/resume for API both single instance and list 
- Add .pwrseq_suspend/resume for pwrseq_generic.c
- Add pwrseq_suspend_list and pwrseq_resume_list for USB hub suspend
  and resume routine

Changes for v10:
- Improve the kernel-doc for power sequence core, including exported APIs and
  main structure. [Patch 2/8]
- Change Kconfig, and let the user choose power sequence. [Patch 2/8]
- Delete EXPORT_SYMBOL and change related APIs as local, these APIs do not
  be intended to export currently. [Patch 2/8]
- Selete POWER_SEQUENCE at USB core's Kconfig. [Patch 4/8]

Changes for v9:
- Add Vaibhav Hiremath's reviewed-by [Patch 4/8]
- Rebase to v4.9-rc1

Changes for v8:
- Allocate one extra pwrseq instance if pwrseq_get has succeed, it can avoid
  preallocate instances problem which the number of instance is decided at
  compile time, thanks for Heiko Stuebner's suggestion [Patch 2/8]
- Delete pwrseq_compatible_sample.c which is the demo purpose to show compatible
  match method. [Patch 2/8]
- Add Maciej S. Szmigiero's tested-by. [Patch 7/8]

Changes for v7:
- Create kinds of power sequence instance at postcore_initcall, and match
  the instance with node using compatible string, the beneit of this is
  the host driver doesn't need to consider which pwrseq instance needs
  to be used, and pwrseq core will match it, however, it eats some memories
  if less power sequence instances are used. [Patch 2/8]
- Add pwrseq_compatible_sample.c to test match pwrseq using device_id. [Patch 
2/8]
- Fix the comments Vaibhav Hiremath adds for error path for clock and do not
  use device_node for parameters at pwrseq_on. [Patch 2/8]
- Simplify the caller to use power sequence, follows Alan's commnets [Patch 4/8]
- Tested three pwrseq instances together using both specific compatible string 
and
  generic libraries.

Changes for v6:
- Add Matthias Kaehlcke's Reviewed-by and Tested-by. (patch [2/6])
- Change chipidea core of_node assignment for coming user. (patch [5/6])
- Applies Joshua Clayton's three dts changes for two boards,
  the USB device's reg has only #address-cells, but without #size-cells.

Changes for v5:
- Delete pwrseq_register/pwrseq_unregister, which is useless currently
- Fix the linker error when the pwrseq user is compiled as module

Changes for v4:
- Create the patch on next-20160722 
- Fix the of_node is not NULL after chipidea driver is unbinded [Patch 5/6]
- Using more friendly wait method for reset gpio [Patch 2/6]
- Support 

[PATCH v13 00/12] power: add power sequence library

[Peter Chen]

Hi all,

This is a follow-up for my last power sequence framework patch set [1].
According to Rob Herring and Ulf Hansson's comments[2]. The kinds of
power sequence instances will be added at postcore_initcall, the match
criteria is compatible string first, if the compatible string is not
matched between dts and library, it will try to use generic power sequence.
 
The host driver just needs to call of_pwrseq_on/of_pwrseq_off
if only one power sequence instance is needed, for more power sequences
are used, using of_pwrseq_on_list/of_pwrseq_off_list instead (eg, USB hub 
driver).

In future, if there are special power sequence requirements, the special
power sequence library can be created.

This patch set is tested on i.mx6 sabresx evk using a dts change, I use
two hot-plug devices to simulate this use case, the related binding
change is updated at patch [1/6], The udoo board changes were tested
using my last power sequence patch set.[3]

Except for hard-wired MMC and USB devices, I find the USB ULPI PHY also
need to power on itself before it can be found by ULPI bus.

Changes for v13:
- Add more design descriptions at design doc and fix one build error
  introduced by v12 wrongly [Patch 2/12]
- Add the last three dts patches which were forgotten at last series
- Move the comment for usb_create_shared_hcd to correct place [Patch 3/12]
- Add sysdev for shared hcd too for xhci-plat.c [Patch 6/12]

Rafael, if the first two power sequence patches are ok for you, would you 
consider
accept these first, the other USB patches can go through USB tree at v4.12-rc1?

Changes for v12:
- Add design doc and more comments at generic power sequence source file [Patch 
2/9]
- Introduce four Arnd Bergmann patches and one my ehci related patches, these 
patches
  are used to get property DT/firmware information at USB code, and these 
information
  are needed for power sequence operation at USB. With these five patches, my 
chipidea
  hack patch in previous patch set can be removed. [Patch 3-7/9]
- Add -ENOENT judgement to avoid USB error if no power sequence library is 
chosen [9/9]

Changes for v11:
- Fix warning: (USB) selects POWER_SEQUENCE which has unmet direct dependencies 
(OF)
- Delete redundant copyright statement.
- Change pr_warn to pr_debug at wrseq_find_available_instance
- Refine kerneldoc
- %s/ENONET/ENOENT 
- Allocate pwrseq list node before than carry out power sequence on 
- Add mutex_lock/mutex_lock for pwrseq node browse at 
pwrseq_find_available_instance
- Add pwrseq_suspend/resume for API both single instance and list 
- Add .pwrseq_suspend/resume for pwrseq_generic.c
- Add pwrseq_suspend_list and pwrseq_resume_list for USB hub suspend
  and resume routine

Changes for v10:
- Improve the kernel-doc for power sequence core, including exported APIs and
  main structure. [Patch 2/8]
- Change Kconfig, and let the user choose power sequence. [Patch 2/8]
- Delete EXPORT_SYMBOL and change related APIs as local, these APIs do not
  be intended to export currently. [Patch 2/8]
- Selete POWER_SEQUENCE at USB core's Kconfig. [Patch 4/8]

Changes for v9:
- Add Vaibhav Hiremath's reviewed-by [Patch 4/8]
- Rebase to v4.9-rc1

Changes for v8:
- Allocate one extra pwrseq instance if pwrseq_get has succeed, it can avoid
  preallocate instances problem which the number of instance is decided at
  compile time, thanks for Heiko Stuebner's suggestion [Patch 2/8]
- Delete pwrseq_compatible_sample.c which is the demo purpose to show compatible
  match method. [Patch 2/8]
- Add Maciej S. Szmigiero's tested-by. [Patch 7/8]

Changes for v7:
- Create kinds of power sequence instance at postcore_initcall, and match
  the instance with node using compatible string, the beneit of this is
  the host driver doesn't need to consider which pwrseq instance needs
  to be used, and pwrseq core will match it, however, it eats some memories
  if less power sequence instances are used. [Patch 2/8]
- Add pwrseq_compatible_sample.c to test match pwrseq using device_id. [Patch 
2/8]
- Fix the comments Vaibhav Hiremath adds for error path for clock and do not
  use device_node for parameters at pwrseq_on. [Patch 2/8]
- Simplify the caller to use power sequence, follows Alan's commnets [Patch 4/8]
- Tested three pwrseq instances together using both specific compatible string 
and
  generic libraries.

Changes for v6:
- Add Matthias Kaehlcke's Reviewed-by and Tested-by. (patch [2/6])
- Change chipidea core of_node assignment for coming user. (patch [5/6])
- Applies Joshua Clayton's three dts changes for two boards,
  the USB device's reg has only #address-cells, but without #size-cells.

Changes for v5:
- Delete pwrseq_register/pwrseq_unregister, which is useless currently
- Fix the linker error when the pwrseq user is compiled as module

Changes for v4:
- Create the patch on next-20160722 
- Fix the of_node is not NULL after chipidea driver is unbinded [Patch 5/6]
- Using more friendly wait method for reset gpio [Patch 2/6]
- Support 

[PATCH v13 12/12] ARM: dts: imx6q-evi: Fix onboard hub reset line

[Peter Chen]

From: Joshua Clayton 

Previously the onboard hub was made to work by treating its
reset gpio as a regulator enable.
Get rid of that kludge now that pwseq has added reset gpio support
Move pin muxing the hub reset pin into the usbh1 group

Signed-off-by: Joshua Clayton 
Signed-off-by: Peter Chen 
---
 arch/arm/boot/dts/imx6q-evi.dts | 25 +++--
 1 file changed, 7 insertions(+), 18 deletions(-)

diff --git a/arch/arm/boot/dts/imx6q-evi.dts b/arch/arm/boot/dts/imx6q-evi.dts
index 7c7c1a8..79a0bd5 100644
--- a/arch/arm/boot/dts/imx6q-evi.dts
+++ b/arch/arm/boot/dts/imx6q-evi.dts
@@ -54,18 +54,6 @@
reg = <0x1000 0x4000>;
};
 
-   reg_usbh1_vbus: regulator-usbhubreset {
-   compatible = "regulator-fixed";
-   regulator-name = "usbh1_vbus";
-   regulator-min-microvolt = <500>;
-   regulator-max-microvolt = <500>;
-   enable-active-high;
-   startup-delay-us = <2>;
-   pinctrl-names = "default";
-   pinctrl-0 = <_usbh1_hubreset>;
-   gpio = < 12 GPIO_ACTIVE_HIGH>;
-   };
-
reg_usb_otg_vbus: regulator-usbotgvbus {
compatible = "regulator-fixed";
regulator-name = "usb_otg_vbus";
@@ -207,12 +195,18 @@
 };
 
  {
-   vbus-supply = <_usbh1_vbus>;
pinctrl-names = "default";
pinctrl-0 = <_usbh1>;
dr_mode = "host";
disable-over-current;
status = "okay";
+
+   usb2415host: hub@1 {
+   compatible = "usb424,2513";
+   reg = <1>;
+   reset-gpios = < 12 GPIO_ACTIVE_LOW>;
+   reset-duration-us = <3000>;
+   };
 };
 
  {
@@ -468,11 +462,6 @@
MX6QDL_PAD_GPIO_3__USB_H1_OC 0x1b0b0
/* usbh1_b OC */
MX6QDL_PAD_GPIO_0__GPIO1_IO00 0x1b0b0
-   >;
-   };
-
-   pinctrl_usbh1_hubreset: usbh1hubresetgrp {
-   fsl,pins = <
MX6QDL_PAD_GPIO_17__GPIO7_IO12 0x1b0b0
>;
};
-- 
2.7.4

[PATCH v13 12/12] ARM: dts: imx6q-evi: Fix onboard hub reset line

[Peter Chen]

From: Joshua Clayton 

Previously the onboard hub was made to work by treating its
reset gpio as a regulator enable.
Get rid of that kludge now that pwseq has added reset gpio support
Move pin muxing the hub reset pin into the usbh1 group

Signed-off-by: Joshua Clayton 
Signed-off-by: Peter Chen 
---
 arch/arm/boot/dts/imx6q-evi.dts | 25 +++--
 1 file changed, 7 insertions(+), 18 deletions(-)

diff --git a/arch/arm/boot/dts/imx6q-evi.dts b/arch/arm/boot/dts/imx6q-evi.dts
index 7c7c1a8..79a0bd5 100644
--- a/arch/arm/boot/dts/imx6q-evi.dts
+++ b/arch/arm/boot/dts/imx6q-evi.dts
@@ -54,18 +54,6 @@
reg = <0x1000 0x4000>;
};
 
-   reg_usbh1_vbus: regulator-usbhubreset {
-   compatible = "regulator-fixed";
-   regulator-name = "usbh1_vbus";
-   regulator-min-microvolt = <500>;
-   regulator-max-microvolt = <500>;
-   enable-active-high;
-   startup-delay-us = <2>;
-   pinctrl-names = "default";
-   pinctrl-0 = <_usbh1_hubreset>;
-   gpio = < 12 GPIO_ACTIVE_HIGH>;
-   };
-
reg_usb_otg_vbus: regulator-usbotgvbus {
compatible = "regulator-fixed";
regulator-name = "usb_otg_vbus";
@@ -207,12 +195,18 @@
 };
 
  {
-   vbus-supply = <_usbh1_vbus>;
pinctrl-names = "default";
pinctrl-0 = <_usbh1>;
dr_mode = "host";
disable-over-current;
status = "okay";
+
+   usb2415host: hub@1 {
+   compatible = "usb424,2513";
+   reg = <1>;
+   reset-gpios = < 12 GPIO_ACTIVE_LOW>;
+   reset-duration-us = <3000>;
+   };
 };
 
  {
@@ -468,11 +462,6 @@
MX6QDL_PAD_GPIO_3__USB_H1_OC 0x1b0b0
/* usbh1_b OC */
MX6QDL_PAD_GPIO_0__GPIO1_IO00 0x1b0b0
-   >;
-   };
-
-   pinctrl_usbh1_hubreset: usbh1hubresetgrp {
-   fsl,pins = <
MX6QDL_PAD_GPIO_17__GPIO7_IO12 0x1b0b0
>;
};
-- 
2.7.4

[PATCH v13 03/12] usb: separate out sysdev pointer from usb_bus

[Peter Chen]

From: Arnd Bergmann 

For xhci-hcd platform device, all the DMA parameters are not
configured properly, notably dma ops for dwc3 devices.

The idea here is that you pass in the parent of_node along with
the child device pointer, so it would behave exactly like the
parent already does. The difference is that it also handles all
the other attributes besides the mask.

sysdev will represent the physical device, as seen from firmware
or bus.Splitting the usb_bus->controller field into the
Linux-internal device (used for the sysfs hierarchy, for printks
and for power management) and a new pointer (used for DMA,
DT enumeration and phy lookup) probably covers all that we really
need.

Signed-off-by: Arnd Bergmann 
Signed-off-by: Sriram Dash 
Tested-by: Baolin Wang 
Tested-by: Brian Norris 
Tested-by: Alexander Sverdlin 
Tested-by: Vivek Gautam 
Signed-off-by: Mathias Nyman 
Cc: Felipe Balbi 
Cc: Grygorii Strashko 
Cc: Sinjan Kumar 
Cc: David Fisher 
Cc: Catalin Marinas 
Cc: "Thang Q. Nguyen" 
Cc: Yoshihiro Shimoda 
Cc: Stephen Boyd 
Cc: Bjorn Andersson 
Cc: Ming Lei 
Cc: Jon Masters 
Cc: Dann Frazier 
Cc: Peter Chen 
Cc: Leo Li 
---
 drivers/usb/core/buffer.c | 12 +++
 drivers/usb/core/hcd.c| 80 ++-
 drivers/usb/core/usb.c| 18 +--
 include/linux/usb.h   |  1 +
 include/linux/usb/hcd.h   |  3 ++
 5 files changed, 64 insertions(+), 50 deletions(-)

diff --git a/drivers/usb/core/buffer.c b/drivers/usb/core/buffer.c
index b9bf6e2..b64568c 100644
--- a/drivers/usb/core/buffer.c
+++ b/drivers/usb/core/buffer.c
@@ -66,7 +66,7 @@ int hcd_buffer_create(struct usb_hcd *hcd)
int i, size;
 
if (!IS_ENABLED(CONFIG_HAS_DMA) ||
-   (!hcd->self.controller->dma_mask &&
+   (!is_device_dma_capable(hcd->self.sysdev) &&
 !(hcd->driver->flags & HCD_LOCAL_MEM)))
return 0;
 
@@ -75,7 +75,7 @@ int hcd_buffer_create(struct usb_hcd *hcd)
if (!size)
continue;
snprintf(name, sizeof(name), "buffer-%d", size);
-   hcd->pool[i] = dma_pool_create(name, hcd->self.controller,
+   hcd->pool[i] = dma_pool_create(name, hcd->self.sysdev,
size, size, 0);
if (!hcd->pool[i]) {
hcd_buffer_destroy(hcd);
@@ -130,7 +130,7 @@ void *hcd_buffer_alloc(
 
/* some USB hosts just use PIO */
if (!IS_ENABLED(CONFIG_HAS_DMA) ||
-   (!bus->controller->dma_mask &&
+   (!is_device_dma_capable(bus->sysdev) &&
 !(hcd->driver->flags & HCD_LOCAL_MEM))) {
*dma = ~(dma_addr_t) 0;
return kmalloc(size, mem_flags);
@@ -140,7 +140,7 @@ void *hcd_buffer_alloc(
if (size <= pool_max[i])
return dma_pool_alloc(hcd->pool[i], mem_flags, dma);
}
-   return dma_alloc_coherent(hcd->self.controller, size, dma, mem_flags);
+   return dma_alloc_coherent(hcd->self.sysdev, size, dma, mem_flags);
 }
 
 void hcd_buffer_free(
@@ -157,7 +157,7 @@ void hcd_buffer_free(
return;
 
if (!IS_ENABLED(CONFIG_HAS_DMA) ||
-   (!bus->controller->dma_mask &&
+   (!is_device_dma_capable(bus->sysdev) &&
 !(hcd->driver->flags & HCD_LOCAL_MEM))) {
kfree(addr);
return;
@@ -169,5 +169,5 @@ void hcd_buffer_free(
return;
}
}
-   dma_free_coherent(hcd->self.controller, size, addr, dma);
+   dma_free_coherent(hcd->self.sysdev, size, addr, dma);
 }
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index 612fab6..2342c1f 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -1073,6 +1073,7 @@ static void usb_deregister_bus (struct usb_bus *bus)
 static int register_root_hub(struct usb_hcd *hcd)
 {
struct device *parent_dev = hcd->self.controller;
+   struct device *sysdev = hcd->self.sysdev;
struct usb_device *usb_dev = hcd->self.root_hub;
const int devnum = 1;
int retval;
@@ -1119,7 +1120,7 @@ static int register_root_hub(struct usb_hcd *hcd)
/* Did the HC die before the root hub was registered? */
if (HCD_DEAD(hcd))
usb_hc_died (hcd);  /* This time clean up */
-   usb_dev->dev.of_node = parent_dev->of_node;
+ 

[PATCH v13 03/12] usb: separate out sysdev pointer from usb_bus

[Peter Chen]

From: Arnd Bergmann 

For xhci-hcd platform device, all the DMA parameters are not
configured properly, notably dma ops for dwc3 devices.

The idea here is that you pass in the parent of_node along with
the child device pointer, so it would behave exactly like the
parent already does. The difference is that it also handles all
the other attributes besides the mask.

sysdev will represent the physical device, as seen from firmware
or bus.Splitting the usb_bus->controller field into the
Linux-internal device (used for the sysfs hierarchy, for printks
and for power management) and a new pointer (used for DMA,
DT enumeration and phy lookup) probably covers all that we really
need.

Signed-off-by: Arnd Bergmann 
Signed-off-by: Sriram Dash 
Tested-by: Baolin Wang 
Tested-by: Brian Norris 
Tested-by: Alexander Sverdlin 
Tested-by: Vivek Gautam 
Signed-off-by: Mathias Nyman 
Cc: Felipe Balbi 
Cc: Grygorii Strashko 
Cc: Sinjan Kumar 
Cc: David Fisher 
Cc: Catalin Marinas 
Cc: "Thang Q. Nguyen" 
Cc: Yoshihiro Shimoda 
Cc: Stephen Boyd 
Cc: Bjorn Andersson 
Cc: Ming Lei 
Cc: Jon Masters 
Cc: Dann Frazier 
Cc: Peter Chen 
Cc: Leo Li 
---
 drivers/usb/core/buffer.c | 12 +++
 drivers/usb/core/hcd.c| 80 ++-
 drivers/usb/core/usb.c| 18 +--
 include/linux/usb.h   |  1 +
 include/linux/usb/hcd.h   |  3 ++
 5 files changed, 64 insertions(+), 50 deletions(-)

diff --git a/drivers/usb/core/buffer.c b/drivers/usb/core/buffer.c
index b9bf6e2..b64568c 100644
--- a/drivers/usb/core/buffer.c
+++ b/drivers/usb/core/buffer.c
@@ -66,7 +66,7 @@ int hcd_buffer_create(struct usb_hcd *hcd)
int i, size;
 
if (!IS_ENABLED(CONFIG_HAS_DMA) ||
-   (!hcd->self.controller->dma_mask &&
+   (!is_device_dma_capable(hcd->self.sysdev) &&
 !(hcd->driver->flags & HCD_LOCAL_MEM)))
return 0;
 
@@ -75,7 +75,7 @@ int hcd_buffer_create(struct usb_hcd *hcd)
if (!size)
continue;
snprintf(name, sizeof(name), "buffer-%d", size);
-   hcd->pool[i] = dma_pool_create(name, hcd->self.controller,
+   hcd->pool[i] = dma_pool_create(name, hcd->self.sysdev,
size, size, 0);
if (!hcd->pool[i]) {
hcd_buffer_destroy(hcd);
@@ -130,7 +130,7 @@ void *hcd_buffer_alloc(
 
/* some USB hosts just use PIO */
if (!IS_ENABLED(CONFIG_HAS_DMA) ||
-   (!bus->controller->dma_mask &&
+   (!is_device_dma_capable(bus->sysdev) &&
 !(hcd->driver->flags & HCD_LOCAL_MEM))) {
*dma = ~(dma_addr_t) 0;
return kmalloc(size, mem_flags);
@@ -140,7 +140,7 @@ void *hcd_buffer_alloc(
if (size <= pool_max[i])
return dma_pool_alloc(hcd->pool[i], mem_flags, dma);
}
-   return dma_alloc_coherent(hcd->self.controller, size, dma, mem_flags);
+   return dma_alloc_coherent(hcd->self.sysdev, size, dma, mem_flags);
 }
 
 void hcd_buffer_free(
@@ -157,7 +157,7 @@ void hcd_buffer_free(
return;
 
if (!IS_ENABLED(CONFIG_HAS_DMA) ||
-   (!bus->controller->dma_mask &&
+   (!is_device_dma_capable(bus->sysdev) &&
 !(hcd->driver->flags & HCD_LOCAL_MEM))) {
kfree(addr);
return;
@@ -169,5 +169,5 @@ void hcd_buffer_free(
return;
}
}
-   dma_free_coherent(hcd->self.controller, size, addr, dma);
+   dma_free_coherent(hcd->self.sysdev, size, addr, dma);
 }
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index 612fab6..2342c1f 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -1073,6 +1073,7 @@ static void usb_deregister_bus (struct usb_bus *bus)
 static int register_root_hub(struct usb_hcd *hcd)
 {
struct device *parent_dev = hcd->self.controller;
+   struct device *sysdev = hcd->self.sysdev;
struct usb_device *usb_dev = hcd->self.root_hub;
const int devnum = 1;
int retval;
@@ -1119,7 +1120,7 @@ static int register_root_hub(struct usb_hcd *hcd)
/* Did the HC die before the root hub was registered? */
if (HCD_DEAD(hcd))
usb_hc_died (hcd);  /* This time clean up */
-   usb_dev->dev.of_node = parent_dev->of_node;
+   usb_dev->dev.of_node = sysdev->of_node;
}
mutex_unlock(_bus_idr_lock);
 
@@ -1465,19 +1466,19 @@ void usb_hcd_unmap_urb_for_dma(struct usb_hcd *hcd, 
struct urb *urb)
dir = usb_urb_dir_in(urb) ? DMA_FROM_DEVICE : DMA_TO_DEVICE;
if (IS_ENABLED(CONFIG_HAS_DMA) &&
(urb->transfer_flags & URB_DMA_MAP_SG))
-   dma_unmap_sg(hcd->self.controller,
+   dma_unmap_sg(hcd->self.sysdev,
urb->sg,

[PATCH v13 04/12] usb: chipidea: use bus->sysdev for DMA configuration

[Peter Chen]

From: Arnd Bergmann 

Set the dma for chipidea from sysdev. This is inherited from its
parent node. Also, do not set dma mask for child as it is not required
now.

Signed-off-by: Arnd Bergmann 
Signed-off-by: Sriram Dash 
Acked-by: Peter Chen 
Signed-off-by: Mathias Nyman 
---
 drivers/usb/chipidea/core.c |  3 ---
 drivers/usb/chipidea/host.c |  3 ++-
 drivers/usb/chipidea/udc.c  | 10 ++
 3 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 79ad8e9..b4a78b2 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -783,9 +783,6 @@ struct platform_device *ci_hdrc_add_device(struct device 
*dev,
}
 
pdev->dev.parent = dev;
-   pdev->dev.dma_mask = dev->dma_mask;
-   pdev->dev.dma_parms = dev->dma_parms;
-   dma_set_coherent_mask(>dev, dev->coherent_dma_mask);
 
ret = platform_device_add_resources(pdev, res, nres);
if (ret)
diff --git a/drivers/usb/chipidea/host.c b/drivers/usb/chipidea/host.c
index 915f3e9..18cb8e4 100644
--- a/drivers/usb/chipidea/host.c
+++ b/drivers/usb/chipidea/host.c
@@ -123,7 +123,8 @@ static int host_start(struct ci_hdrc *ci)
if (usb_disabled())
return -ENODEV;
 
-   hcd = usb_create_hcd(_ehci_hc_driver, ci->dev, dev_name(ci->dev));
+   hcd = __usb_create_hcd(_ehci_hc_driver, ci->dev->parent,
+  ci->dev, dev_name(ci->dev), NULL);
if (!hcd)
return -ENOMEM;
 
diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index f88e915..1fb5235 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -423,7 +423,8 @@ static int _hardware_enqueue(struct ci_hw_ep *hwep, struct 
ci_hw_req *hwreq)
 
hwreq->req.status = -EALREADY;
 
-   ret = usb_gadget_map_request(>gadget, >req, hwep->dir);
+   ret = usb_gadget_map_request_by_dev(ci->dev->parent,
+   >req, hwep->dir);
if (ret)
return ret;
 
@@ -603,7 +604,8 @@ static int _hardware_dequeue(struct ci_hw_ep *hwep, struct 
ci_hw_req *hwreq)
list_del_init(>td);
}
 
-   usb_gadget_unmap_request(>ci->gadget, >req, hwep->dir);
+   usb_gadget_unmap_request_by_dev(hwep->ci->dev->parent,
+   >req, hwep->dir);
 
hwreq->req.actual += actual;
 
@@ -1899,13 +1901,13 @@ static int udc_start(struct ci_hdrc *ci)
INIT_LIST_HEAD(>gadget.ep_list);
 
/* alloc resources */
-   ci->qh_pool = dma_pool_create("ci_hw_qh", dev,
+   ci->qh_pool = dma_pool_create("ci_hw_qh", dev->parent,
   sizeof(struct ci_hw_qh),
   64, CI_HDRC_PAGE_SIZE);
if (ci->qh_pool == NULL)
return -ENOMEM;
 
-   ci->td_pool = dma_pool_create("ci_hw_td", dev,
+   ci->td_pool = dma_pool_create("ci_hw_td", dev->parent,
   sizeof(struct ci_hw_td),
   64, CI_HDRC_PAGE_SIZE);
if (ci->td_pool == NULL) {
-- 
2.7.4

[PATCH v13 11/12] ARM: dts: imx6qdl-udoo.dtsi: fix onboard USB HUB property

[Peter Chen]

The current dts describes USB HUB's property at USB controller's
entry, it is improper. The USB HUB should be the child node
under USB controller, and power sequence properties are under
it. Besides, using gpio pinctrl setting for USB2415's reset pin.

Signed-off-by: Peter Chen 
Signed-off-by: Joshua Clayton 
Tested-by: Maciej S. Szmigiero 
---
 arch/arm/boot/dts/imx6qdl-udoo.dtsi | 26 --
 1 file changed, 12 insertions(+), 14 deletions(-)

diff --git a/arch/arm/boot/dts/imx6qdl-udoo.dtsi 
b/arch/arm/boot/dts/imx6qdl-udoo.dtsi
index c96c91d..a173de2 100644
--- a/arch/arm/boot/dts/imx6qdl-udoo.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-udoo.dtsi
@@ -9,6 +9,8 @@
  *
  */
 
+#include 
+
 / {
aliases {
backlight = 
@@ -58,17 +60,6 @@
#address-cells = <1>;
#size-cells = <0>;
 
-   reg_usb_h1_vbus: regulator@0 {
-   compatible = "regulator-fixed";
-   reg = <0>;
-   regulator-name = "usb_h1_vbus";
-   regulator-min-microvolt = <500>;
-   regulator-max-microvolt = <500>;
-   enable-active-high;
-   startup-delay-us = <2>; /* USB2415 requires a POR of 1 
us minimum */
-   gpio = < 12 0>;
-   };
-
reg_panel: regulator@1 {
compatible = "regulator-fixed";
reg = <1>;
@@ -188,7 +179,7 @@
 
pinctrl_usbh: usbhgrp {
fsl,pins = <
-   MX6QDL_PAD_GPIO_17__GPIO7_IO12 0x8000
+   MX6QDL_PAD_GPIO_17__GPIO7_IO12  0x1b0b0
MX6QDL_PAD_NANDF_CS2__CCM_CLKO2 0x130b0
>;
};
@@ -259,9 +250,16 @@
  {
pinctrl-names = "default";
pinctrl-0 = <_usbh>;
-   vbus-supply = <_usb_h1_vbus>;
-   clocks = < IMX6QDL_CLK_CKO>;
status = "okay";
+
+   usb2415: hub@1 {
+   compatible = "usb424,2514";
+   reg = <1>;
+
+   clocks = < IMX6QDL_CLK_CKO>;
+   reset-gpios = < 12 GPIO_ACTIVE_LOW>;
+   reset-duration-us = <3000>;
+   };
 };
 
  {
-- 
2.7.4

[PATCH v13 09/12] usb: core: add power sequence handling for USB devices

[Peter Chen]

Some hard-wired USB devices need to do power sequence to let the
device work normally, the typical power sequence like: enable USB
PHY clock, toggle reset pin, etc. But current Linux USB driver
lacks of such code to do it, it may cause some hard-wired USB devices
works abnormal or can't be recognized by controller at all.

In this patch, it calls power sequence library APIs to finish
the power sequence events. It will do power on sequence at hub's
probe for all devices under this hub (includes root hub).
At hub_disconnect, it will do power off sequence which is at powered
on list.

Signed-off-by: Peter Chen 
Tested-by Joshua Clayton 
Tested-by: Maciej S. Szmigiero 
Reviewed-by: Vaibhav Hiremath 
---
 drivers/usb/Kconfig|  1 +
 drivers/usb/core/hub.c | 49 +
 drivers/usb/core/hub.h |  1 +
 3 files changed, 47 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
index fbe493d..706f261 100644
--- a/drivers/usb/Kconfig
+++ b/drivers/usb/Kconfig
@@ -40,6 +40,7 @@ config USB
tristate "Support for Host-side USB"
depends on USB_ARCH_HAS_HCD
select USB_COMMON
+   select POWER_SEQUENCE
select NLS  # for UTF-8 strings
---help---
  Universal Serial Bus (USB) is a specification for a serial bus
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index a56c75e..5b40c48 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -1616,6 +1617,7 @@ static void hub_disconnect(struct usb_interface *intf)
hub->error = 0;
hub_quiesce(hub, HUB_DISCONNECT);
 
+   of_pwrseq_off_list(>pwrseq_on_list);
mutex_lock(_port_peer_mutex);
 
/* Avoid races with recursively_mark_NOTATTACHED() */
@@ -1643,12 +1645,42 @@ static void hub_disconnect(struct usb_interface *intf)
kref_put(>kref, hub_release);
 }
 
+#ifdef CONFIG_OF
+static int hub_of_pwrseq_on(struct usb_hub *hub)
+{
+   struct device *parent;
+   struct usb_device *hdev = hub->hdev;
+   struct device_node *np;
+   int ret;
+
+   if (hdev->parent)
+   parent = >dev;
+   else
+   parent = bus_to_hcd(hdev->bus)->self.sysdev;
+
+   for_each_child_of_node(parent->of_node, np) {
+   ret = of_pwrseq_on_list(np, >pwrseq_on_list);
+   /* Maybe no power sequence library is chosen */
+   if (ret && ret != -ENOENT)
+   return ret;
+   }
+
+   return 0;
+}
+#else
+static int hub_of_pwrseq_on(struct usb_hub *hub)
+{
+   return 0;
+}
+#endif
+
 static int hub_probe(struct usb_interface *intf, const struct usb_device_id 
*id)
 {
struct usb_host_interface *desc;
struct usb_endpoint_descriptor *endpoint;
struct usb_device *hdev;
struct usb_hub *hub;
+   int ret = -ENODEV;
 
desc = intf->cur_altsetting;
hdev = interface_to_usbdev(intf);
@@ -1753,6 +1785,7 @@ static int hub_probe(struct usb_interface *intf, const 
struct usb_device_id *id)
INIT_DELAYED_WORK(>leds, led_work);
INIT_DELAYED_WORK(>init_work, NULL);
INIT_WORK(>events, hub_event);
+   INIT_LIST_HEAD(>pwrseq_on_list);
usb_get_intf(intf);
usb_get_dev(hdev);
 
@@ -1766,11 +1799,14 @@ static int hub_probe(struct usb_interface *intf, const 
struct usb_device_id *id)
if (id->driver_info & HUB_QUIRK_CHECK_PORT_AUTOSUSPEND)
hub->quirk_check_port_auto_suspend = 1;
 
-   if (hub_configure(hub, endpoint) >= 0)
-   return 0;
+   if (hub_configure(hub, endpoint) >= 0) {
+   ret = hub_of_pwrseq_on(hub);
+   if (!ret)
+   return 0;
+   }
 
hub_disconnect(intf);
-   return -ENODEV;
+   return ret;
 }
 
 static int
@@ -3584,14 +3620,19 @@ static int hub_suspend(struct usb_interface *intf, 
pm_message_t msg)
 
/* stop hub_wq and related activity */
hub_quiesce(hub, HUB_SUSPEND);
-   return 0;
+   return pwrseq_suspend_list(>pwrseq_on_list);
 }
 
 static int hub_resume(struct usb_interface *intf)
 {
struct usb_hub *hub = usb_get_intfdata(intf);
+   int ret;
 
dev_dbg(>dev, "%s\n", __func__);
+   ret = pwrseq_resume_list(>pwrseq_on_list);
+   if (ret)
+   return ret;
+
hub_activate(hub, HUB_RESUME);
return 0;
 }
diff --git a/drivers/usb/core/hub.h b/drivers/usb/core/hub.h
index 34c1a7e..cd86f91 100644
--- a/drivers/usb/core/hub.h
+++ b/drivers/usb/core/hub.h
@@ -78,6 +78,7 @@ struct usb_hub {
struct delayed_work init_work;
struct work_struct  events;
struct usb_port **ports;
+   struct list_headpwrseq_on_list; /* powered pwrseq node 

[PATCH v13 04/12] usb: chipidea: use bus->sysdev for DMA configuration

[Peter Chen]

From: Arnd Bergmann 

Set the dma for chipidea from sysdev. This is inherited from its
parent node. Also, do not set dma mask for child as it is not required
now.

Signed-off-by: Arnd Bergmann 
Signed-off-by: Sriram Dash 
Acked-by: Peter Chen 
Signed-off-by: Mathias Nyman 
---
 drivers/usb/chipidea/core.c |  3 ---
 drivers/usb/chipidea/host.c |  3 ++-
 drivers/usb/chipidea/udc.c  | 10 ++
 3 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 79ad8e9..b4a78b2 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -783,9 +783,6 @@ struct platform_device *ci_hdrc_add_device(struct device 
*dev,
}
 
pdev->dev.parent = dev;
-   pdev->dev.dma_mask = dev->dma_mask;
-   pdev->dev.dma_parms = dev->dma_parms;
-   dma_set_coherent_mask(>dev, dev->coherent_dma_mask);
 
ret = platform_device_add_resources(pdev, res, nres);
if (ret)
diff --git a/drivers/usb/chipidea/host.c b/drivers/usb/chipidea/host.c
index 915f3e9..18cb8e4 100644
--- a/drivers/usb/chipidea/host.c
+++ b/drivers/usb/chipidea/host.c
@@ -123,7 +123,8 @@ static int host_start(struct ci_hdrc *ci)
if (usb_disabled())
return -ENODEV;
 
-   hcd = usb_create_hcd(_ehci_hc_driver, ci->dev, dev_name(ci->dev));
+   hcd = __usb_create_hcd(_ehci_hc_driver, ci->dev->parent,
+  ci->dev, dev_name(ci->dev), NULL);
if (!hcd)
return -ENOMEM;
 
diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index f88e915..1fb5235 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -423,7 +423,8 @@ static int _hardware_enqueue(struct ci_hw_ep *hwep, struct 
ci_hw_req *hwreq)
 
hwreq->req.status = -EALREADY;
 
-   ret = usb_gadget_map_request(>gadget, >req, hwep->dir);
+   ret = usb_gadget_map_request_by_dev(ci->dev->parent,
+   >req, hwep->dir);
if (ret)
return ret;
 
@@ -603,7 +604,8 @@ static int _hardware_dequeue(struct ci_hw_ep *hwep, struct 
ci_hw_req *hwreq)
list_del_init(>td);
}
 
-   usb_gadget_unmap_request(>ci->gadget, >req, hwep->dir);
+   usb_gadget_unmap_request_by_dev(hwep->ci->dev->parent,
+   >req, hwep->dir);
 
hwreq->req.actual += actual;
 
@@ -1899,13 +1901,13 @@ static int udc_start(struct ci_hdrc *ci)
INIT_LIST_HEAD(>gadget.ep_list);
 
/* alloc resources */
-   ci->qh_pool = dma_pool_create("ci_hw_qh", dev,
+   ci->qh_pool = dma_pool_create("ci_hw_qh", dev->parent,
   sizeof(struct ci_hw_qh),
   64, CI_HDRC_PAGE_SIZE);
if (ci->qh_pool == NULL)
return -ENOMEM;
 
-   ci->td_pool = dma_pool_create("ci_hw_td", dev,
+   ci->td_pool = dma_pool_create("ci_hw_td", dev->parent,
   sizeof(struct ci_hw_td),
   64, CI_HDRC_PAGE_SIZE);
if (ci->td_pool == NULL) {
-- 
2.7.4

[PATCH v13 11/12] ARM: dts: imx6qdl-udoo.dtsi: fix onboard USB HUB property

[Peter Chen]

The current dts describes USB HUB's property at USB controller's
entry, it is improper. The USB HUB should be the child node
under USB controller, and power sequence properties are under
it. Besides, using gpio pinctrl setting for USB2415's reset pin.

Signed-off-by: Peter Chen 
Signed-off-by: Joshua Clayton 
Tested-by: Maciej S. Szmigiero 
---
 arch/arm/boot/dts/imx6qdl-udoo.dtsi | 26 --
 1 file changed, 12 insertions(+), 14 deletions(-)

diff --git a/arch/arm/boot/dts/imx6qdl-udoo.dtsi 
b/arch/arm/boot/dts/imx6qdl-udoo.dtsi
index c96c91d..a173de2 100644
--- a/arch/arm/boot/dts/imx6qdl-udoo.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-udoo.dtsi
@@ -9,6 +9,8 @@
  *
  */
 
+#include 
+
 / {
aliases {
backlight = 
@@ -58,17 +60,6 @@
#address-cells = <1>;
#size-cells = <0>;
 
-   reg_usb_h1_vbus: regulator@0 {
-   compatible = "regulator-fixed";
-   reg = <0>;
-   regulator-name = "usb_h1_vbus";
-   regulator-min-microvolt = <500>;
-   regulator-max-microvolt = <500>;
-   enable-active-high;
-   startup-delay-us = <2>; /* USB2415 requires a POR of 1 
us minimum */
-   gpio = < 12 0>;
-   };
-
reg_panel: regulator@1 {
compatible = "regulator-fixed";
reg = <1>;
@@ -188,7 +179,7 @@
 
pinctrl_usbh: usbhgrp {
fsl,pins = <
-   MX6QDL_PAD_GPIO_17__GPIO7_IO12 0x8000
+   MX6QDL_PAD_GPIO_17__GPIO7_IO12  0x1b0b0
MX6QDL_PAD_NANDF_CS2__CCM_CLKO2 0x130b0
>;
};
@@ -259,9 +250,16 @@
  {
pinctrl-names = "default";
pinctrl-0 = <_usbh>;
-   vbus-supply = <_usb_h1_vbus>;
-   clocks = < IMX6QDL_CLK_CKO>;
status = "okay";
+
+   usb2415: hub@1 {
+   compatible = "usb424,2514";
+   reg = <1>;
+
+   clocks = < IMX6QDL_CLK_CKO>;
+   reset-gpios = < 12 GPIO_ACTIVE_LOW>;
+   reset-duration-us = <3000>;
+   };
 };
 
  {
-- 
2.7.4

[PATCH v13 09/12] usb: core: add power sequence handling for USB devices

[Peter Chen]

Some hard-wired USB devices need to do power sequence to let the
device work normally, the typical power sequence like: enable USB
PHY clock, toggle reset pin, etc. But current Linux USB driver
lacks of such code to do it, it may cause some hard-wired USB devices
works abnormal or can't be recognized by controller at all.

In this patch, it calls power sequence library APIs to finish
the power sequence events. It will do power on sequence at hub's
probe for all devices under this hub (includes root hub).
At hub_disconnect, it will do power off sequence which is at powered
on list.

Signed-off-by: Peter Chen 
Tested-by Joshua Clayton 
Tested-by: Maciej S. Szmigiero 
Reviewed-by: Vaibhav Hiremath 
---
 drivers/usb/Kconfig|  1 +
 drivers/usb/core/hub.c | 49 +
 drivers/usb/core/hub.h |  1 +
 3 files changed, 47 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
index fbe493d..706f261 100644
--- a/drivers/usb/Kconfig
+++ b/drivers/usb/Kconfig
@@ -40,6 +40,7 @@ config USB
tristate "Support for Host-side USB"
depends on USB_ARCH_HAS_HCD
select USB_COMMON
+   select POWER_SEQUENCE
select NLS  # for UTF-8 strings
---help---
  Universal Serial Bus (USB) is a specification for a serial bus
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index a56c75e..5b40c48 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -1616,6 +1617,7 @@ static void hub_disconnect(struct usb_interface *intf)
hub->error = 0;
hub_quiesce(hub, HUB_DISCONNECT);
 
+   of_pwrseq_off_list(>pwrseq_on_list);
mutex_lock(_port_peer_mutex);
 
/* Avoid races with recursively_mark_NOTATTACHED() */
@@ -1643,12 +1645,42 @@ static void hub_disconnect(struct usb_interface *intf)
kref_put(>kref, hub_release);
 }
 
+#ifdef CONFIG_OF
+static int hub_of_pwrseq_on(struct usb_hub *hub)
+{
+   struct device *parent;
+   struct usb_device *hdev = hub->hdev;
+   struct device_node *np;
+   int ret;
+
+   if (hdev->parent)
+   parent = >dev;
+   else
+   parent = bus_to_hcd(hdev->bus)->self.sysdev;
+
+   for_each_child_of_node(parent->of_node, np) {
+   ret = of_pwrseq_on_list(np, >pwrseq_on_list);
+   /* Maybe no power sequence library is chosen */
+   if (ret && ret != -ENOENT)
+   return ret;
+   }
+
+   return 0;
+}
+#else
+static int hub_of_pwrseq_on(struct usb_hub *hub)
+{
+   return 0;
+}
+#endif
+
 static int hub_probe(struct usb_interface *intf, const struct usb_device_id 
*id)
 {
struct usb_host_interface *desc;
struct usb_endpoint_descriptor *endpoint;
struct usb_device *hdev;
struct usb_hub *hub;
+   int ret = -ENODEV;
 
desc = intf->cur_altsetting;
hdev = interface_to_usbdev(intf);
@@ -1753,6 +1785,7 @@ static int hub_probe(struct usb_interface *intf, const 
struct usb_device_id *id)
INIT_DELAYED_WORK(>leds, led_work);
INIT_DELAYED_WORK(>init_work, NULL);
INIT_WORK(>events, hub_event);
+   INIT_LIST_HEAD(>pwrseq_on_list);
usb_get_intf(intf);
usb_get_dev(hdev);
 
@@ -1766,11 +1799,14 @@ static int hub_probe(struct usb_interface *intf, const 
struct usb_device_id *id)
if (id->driver_info & HUB_QUIRK_CHECK_PORT_AUTOSUSPEND)
hub->quirk_check_port_auto_suspend = 1;
 
-   if (hub_configure(hub, endpoint) >= 0)
-   return 0;
+   if (hub_configure(hub, endpoint) >= 0) {
+   ret = hub_of_pwrseq_on(hub);
+   if (!ret)
+   return 0;
+   }
 
hub_disconnect(intf);
-   return -ENODEV;
+   return ret;
 }
 
 static int
@@ -3584,14 +3620,19 @@ static int hub_suspend(struct usb_interface *intf, 
pm_message_t msg)
 
/* stop hub_wq and related activity */
hub_quiesce(hub, HUB_SUSPEND);
-   return 0;
+   return pwrseq_suspend_list(>pwrseq_on_list);
 }
 
 static int hub_resume(struct usb_interface *intf)
 {
struct usb_hub *hub = usb_get_intfdata(intf);
+   int ret;
 
dev_dbg(>dev, "%s\n", __func__);
+   ret = pwrseq_resume_list(>pwrseq_on_list);
+   if (ret)
+   return ret;
+
hub_activate(hub, HUB_RESUME);
return 0;
 }
diff --git a/drivers/usb/core/hub.h b/drivers/usb/core/hub.h
index 34c1a7e..cd86f91 100644
--- a/drivers/usb/core/hub.h
+++ b/drivers/usb/core/hub.h
@@ -78,6 +78,7 @@ struct usb_hub {
struct delayed_work init_work;
struct work_struct  events;
struct usb_port **ports;
+   struct list_headpwrseq_on_list; /* powered pwrseq node list */
 };
 
 /**
-- 
2.7.4

[PATCH] net: ethernet: ti: cpsw: return NET_XMIT_DROP if skb_padto failed

[Ivan Khoronzhuk]

If skb_padto failed the skb has been dropped already, so it was
consumed, but it doesn't mean it was sent, thus no need to update
queue tx time, etc. So, return NET_XMIT_DROP as more appropriate.

Signed-off-by: Ivan Khoronzhuk 
---
Based on net-next/master

 drivers/net/ethernet/ti/cpsw.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 4d1c0c3..503fa8a 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -1604,7 +1604,7 @@ static netdev_tx_t cpsw_ndo_start_xmit(struct sk_buff 
*skb,
if (skb_padto(skb, CPSW_MIN_PACKET_SIZE)) {
cpsw_err(priv, tx_err, "packet pad failed\n");
ndev->stats.tx_dropped++;
-   return NETDEV_TX_OK;
+   return NET_XMIT_DROP;
}
 
if (skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP &&
-- 
2.7.4

[PATCH v13 05/12] usb: ehci: fsl: use bus->sysdev for DMA configuration

[Peter Chen]

From: Arnd Bergmann 

For the dual role ehci fsl driver, sysdev will handle the dma
config.

Signed-off-by: Arnd Bergmann 
Signed-off-by: Sriram Dash 
Signed-off-by: Mathias Nyman 
---
 drivers/usb/host/ehci-fsl.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c
index 3733aab..4a08b70 100644
--- a/drivers/usb/host/ehci-fsl.c
+++ b/drivers/usb/host/ehci-fsl.c
@@ -96,8 +96,8 @@ static int fsl_ehci_drv_probe(struct platform_device *pdev)
}
irq = res->start;
 
-   hcd = usb_create_hcd(_ehci_hc_driver, >dev,
-   dev_name(>dev));
+   hcd = __usb_create_hcd(_ehci_hc_driver, pdev->dev.parent,
+  >dev, dev_name(>dev), NULL);
if (!hcd) {
retval = -ENOMEM;
goto err1;
-- 
2.7.4

[PATCH v13 01/12] binding-doc: power: pwrseq-generic: add binding doc for generic power sequence library

[Peter Chen]

Add binding doc for generic power sequence library.

Signed-off-by: Peter Chen 
Acked-by: Philipp Zabel 
Acked-by: Rob Herring 
---
 .../bindings/power/pwrseq/pwrseq-generic.txt   | 48 ++
 1 file changed, 48 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt

diff --git a/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt 
b/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
new file mode 100644
index 000..ebf0d47
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
@@ -0,0 +1,48 @@
+The generic power sequence library
+
+Some hard-wired devices (eg USB/MMC) need to do power sequence before
+the device can be enumerated on the bus, the typical power sequence
+like: enable USB PHY clock, toggle reset pin, etc. But current
+Linux device driver lacks of such code to do it, it may cause some
+hard-wired devices works abnormal or can't be recognized by
+controller at all. The power sequence will be done before this device
+can be found at the bus.
+
+The power sequence properties is under the device node.
+
+Optional properties:
+- clocks: the input clocks for device.
+- reset-gpios: Should specify the GPIO for reset.
+- reset-duration-us: the duration in microsecond for assert reset signal.
+
+Below is the example of USB power sequence properties on USB device
+nodes which have two level USB hubs.
+
+ {
+   vbus-supply = <_usb_otg1_vbus>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_usb_otg1_id>;
+   status = "okay";
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+   genesys: hub@1 {
+   compatible = "usb5e3,608";
+   reg = <1>;
+
+   clocks = < IMX6SX_CLK_CKO>;
+   reset-gpios = < 5 GPIO_ACTIVE_LOW>; /* hub reset pin */
+   reset-duration-us = <10>;
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+   asix: ethernet@1 {
+   compatible = "usbb95,1708";
+   reg = <1>;
+
+   clocks = < IMX6SX_CLK_IPG>;
+   reset-gpios = < 6 GPIO_ACTIVE_LOW>; /* 
ethernet_rst */
+   reset-duration-us = <15>;
+   };
+   };
+};
-- 
2.7.4

[PATCH] net: ethernet: ti: cpsw: return NET_XMIT_DROP if skb_padto failed

[Ivan Khoronzhuk]

If skb_padto failed the skb has been dropped already, so it was
consumed, but it doesn't mean it was sent, thus no need to update
queue tx time, etc. So, return NET_XMIT_DROP as more appropriate.

Signed-off-by: Ivan Khoronzhuk 
---
Based on net-next/master

 drivers/net/ethernet/ti/cpsw.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 4d1c0c3..503fa8a 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -1604,7 +1604,7 @@ static netdev_tx_t cpsw_ndo_start_xmit(struct sk_buff 
*skb,
if (skb_padto(skb, CPSW_MIN_PACKET_SIZE)) {
cpsw_err(priv, tx_err, "packet pad failed\n");
ndev->stats.tx_dropped++;
-   return NETDEV_TX_OK;
+   return NET_XMIT_DROP;
}
 
if (skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP &&
-- 
2.7.4

[PATCH v13 05/12] usb: ehci: fsl: use bus->sysdev for DMA configuration

[Peter Chen]

From: Arnd Bergmann 

For the dual role ehci fsl driver, sysdev will handle the dma
config.

Signed-off-by: Arnd Bergmann 
Signed-off-by: Sriram Dash 
Signed-off-by: Mathias Nyman 
---
 drivers/usb/host/ehci-fsl.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c
index 3733aab..4a08b70 100644
--- a/drivers/usb/host/ehci-fsl.c
+++ b/drivers/usb/host/ehci-fsl.c
@@ -96,8 +96,8 @@ static int fsl_ehci_drv_probe(struct platform_device *pdev)
}
irq = res->start;
 
-   hcd = usb_create_hcd(_ehci_hc_driver, >dev,
-   dev_name(>dev));
+   hcd = __usb_create_hcd(_ehci_hc_driver, pdev->dev.parent,
+  >dev, dev_name(>dev), NULL);
if (!hcd) {
retval = -ENOMEM;
goto err1;
-- 
2.7.4

[PATCH v13 01/12] binding-doc: power: pwrseq-generic: add binding doc for generic power sequence library

[Peter Chen]

Add binding doc for generic power sequence library.

Signed-off-by: Peter Chen 
Acked-by: Philipp Zabel 
Acked-by: Rob Herring 
---
 .../bindings/power/pwrseq/pwrseq-generic.txt   | 48 ++
 1 file changed, 48 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt

diff --git a/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt 
b/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
new file mode 100644
index 000..ebf0d47
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
@@ -0,0 +1,48 @@
+The generic power sequence library
+
+Some hard-wired devices (eg USB/MMC) need to do power sequence before
+the device can be enumerated on the bus, the typical power sequence
+like: enable USB PHY clock, toggle reset pin, etc. But current
+Linux device driver lacks of such code to do it, it may cause some
+hard-wired devices works abnormal or can't be recognized by
+controller at all. The power sequence will be done before this device
+can be found at the bus.
+
+The power sequence properties is under the device node.
+
+Optional properties:
+- clocks: the input clocks for device.
+- reset-gpios: Should specify the GPIO for reset.
+- reset-duration-us: the duration in microsecond for assert reset signal.
+
+Below is the example of USB power sequence properties on USB device
+nodes which have two level USB hubs.
+
+ {
+   vbus-supply = <_usb_otg1_vbus>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_usb_otg1_id>;
+   status = "okay";
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+   genesys: hub@1 {
+   compatible = "usb5e3,608";
+   reg = <1>;
+
+   clocks = < IMX6SX_CLK_CKO>;
+   reset-gpios = < 5 GPIO_ACTIVE_LOW>; /* hub reset pin */
+   reset-duration-us = <10>;
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+   asix: ethernet@1 {
+   compatible = "usbb95,1708";
+   reg = <1>;
+
+   clocks = < IMX6SX_CLK_IPG>;
+   reset-gpios = < 6 GPIO_ACTIVE_LOW>; /* 
ethernet_rst */
+   reset-duration-us = <15>;
+   };
+   };
+};
-- 
2.7.4

[PATCH v13 08/12] binding-doc: usb: usb-device: add optional properties for power sequence

[Peter Chen]

Add optional properties for power sequence.

Signed-off-by: Peter Chen 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/usb/usb-device.txt | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/usb/usb-device.txt 
b/Documentation/devicetree/bindings/usb/usb-device.txt
index 1c35e7b..3661dd2 100644
--- a/Documentation/devicetree/bindings/usb/usb-device.txt
+++ b/Documentation/devicetree/bindings/usb/usb-device.txt
@@ -13,6 +13,10 @@ Required properties:
 - reg: the port number which this device is connecting to, the range
   is 1-31.
 
+Optional properties:
+power sequence properties, see
+Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt for detail
+
 Example:
 
  {
@@ -21,8 +25,12 @@ Example:
#address-cells = <1>;
#size-cells = <0>;
 
-   hub: genesys@1 {
+   genesys: hub@1 {
compatible = "usb5e3,608";
reg = <1>;
+
+   clocks = < IMX6SX_CLK_CKO>;
+   reset-gpios = < 5 GPIO_ACTIVE_LOW>; /* hub reset pin */
+   reset-duration-us = <10>;
};
 }
-- 
2.7.4

[PATCH v13 08/12] binding-doc: usb: usb-device: add optional properties for power sequence

[Peter Chen]

Add optional properties for power sequence.

Signed-off-by: Peter Chen 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/usb/usb-device.txt | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/usb/usb-device.txt 
b/Documentation/devicetree/bindings/usb/usb-device.txt
index 1c35e7b..3661dd2 100644
--- a/Documentation/devicetree/bindings/usb/usb-device.txt
+++ b/Documentation/devicetree/bindings/usb/usb-device.txt
@@ -13,6 +13,10 @@ Required properties:
 - reg: the port number which this device is connecting to, the range
   is 1-31.
 
+Optional properties:
+power sequence properties, see
+Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt for detail
+
 Example:
 
  {
@@ -21,8 +25,12 @@ Example:
#address-cells = <1>;
#size-cells = <0>;
 
-   hub: genesys@1 {
+   genesys: hub@1 {
compatible = "usb5e3,608";
reg = <1>;
+
+   clocks = < IMX6SX_CLK_CKO>;
+   reset-gpios = < 5 GPIO_ACTIVE_LOW>; /* hub reset pin */
+   reset-duration-us = <10>;
};
 }
-- 
2.7.4

[PATCH] usb: musb: add code comment for clarification

[Gustavo A. R. Silva]

Add code comment to make it clear that the fall-through is intentional.
Read the link for more details: https://lkml.org/lkml/2017/2/9/292

Signed-off-by: Gustavo A. R. Silva 
---
 drivers/usb/musb/musb_core.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 892088f..1aec986 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1869,6 +1869,7 @@ static void musb_pm_runtime_check_session(struct  
musb *musb)


return;
}
+   /* fall through */
case MUSB_QUIRK_A_DISCONNECT_19:
if (musb->quirk_retries--) {
musb_dbg(musb,
--
2.5.0

Re: [PATCH 2/3] Bluetooth: cmtp: fix possible might sleep error in cmtp_session

[Brian Norris]

Hi,

On Tue, Jan 24, 2017 at 12:07:50PM +0800, Jeffy Chen wrote:
> It looks like cmtp_session has same pattern as the issue reported in
> old rfcomm:
> 
>   while (1) {
>   set_current_state(TASK_INTERRUPTIBLE);
>   if (condition)
>   break;
>   // may call might_sleep here
>   schedule();
>   }
>   __set_current_state(TASK_RUNNING);
> 
> Which fixed at:
>   dfb2fae Bluetooth: Fix nested sleeps
> 
> So let's fix it at the same way, also follow the suggestion of:
> https://lwn.net/Articles/628628/
> 
> Signed-off-by: Jeffy Chen 
> ---
> 
>  net/bluetooth/cmtp/core.c | 21 ++---
>  1 file changed, 14 insertions(+), 7 deletions(-)
> 
> diff --git a/net/bluetooth/cmtp/core.c b/net/bluetooth/cmtp/core.c
> index 9e59b66..6b03f2b 100644
> --- a/net/bluetooth/cmtp/core.c
> +++ b/net/bluetooth/cmtp/core.c
> @@ -280,16 +280,16 @@ static int cmtp_session(void *arg)
>   struct cmtp_session *session = arg;
>   struct sock *sk = session->sock->sk;
>   struct sk_buff *skb;
> - wait_queue_t wait;
> + DEFINE_WAIT_FUNC(wait, woken_wake_function);
>  
>   BT_DBG("session %p", session);
>  
>   set_user_nice(current, -15);
>  
> - init_waitqueue_entry(, current);
>   add_wait_queue(sk_sleep(sk), );
>   while (1) {
> - set_current_state(TASK_INTERRUPTIBLE);
> + /* Ensure session->terminate is updated */
> + smp_mb__before_atomic();
>  
>   if (atomic_read(>terminate))
>   break;
> @@ -306,9 +306,8 @@ static int cmtp_session(void *arg)
>  
>   cmtp_process_transmit(session);
>  
> - schedule();
> + wait_woken(, TASK_INTERRUPTIBLE, MAX_SCHEDULE_TIMEOUT);
>   }
> - __set_current_state(TASK_RUNNING);
>   remove_wait_queue(sk_sleep(sk), );
>  
>   down_write(_session_sem);
> @@ -393,7 +392,11 @@ int cmtp_add_connection(struct cmtp_connadd_req *req, 
> struct socket *sock)
>   err = cmtp_attach_device(session);
>   if (err < 0) {
>   atomic_inc(>terminate);
> - wake_up_process(session->task);
> +
> + /* Ensure session->terminate is updated */
> + smp_mb__after_atomic();
> +

Same comment about the barrier.

> + wake_up_interruptible(sk_sleep(session->sock->sk));
>   up_write(_session_sem);
>   return err;
>   }
> @@ -431,7 +434,11 @@ int cmtp_del_connection(struct cmtp_conndel_req *req)
>  
>   /* Stop session thread */
>   atomic_inc(>terminate);
> - wake_up_process(session->task);
> +
> + /* Ensure session->terminate is updated */
> + smp_mb__after_atomic();

And again.

But otherwise I think this looks OK, again with the caveat that I don't
know Bluetooth/CMTP that well:

Reviewed-by: Brian Norris 

> +
> + wake_up_interruptible(sk_sleep(session->sock->sk));
>   } else
>   err = -ENOENT;
>  
> -- 
> 2.1.4
> 
> 

[PATCH] usb: musb: add code comment for clarification

[Gustavo A. R. Silva]

Add code comment to make it clear that the fall-through is intentional.
Read the link for more details: https://lkml.org/lkml/2017/2/9/292

Signed-off-by: Gustavo A. R. Silva 
---
 drivers/usb/musb/musb_core.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 892088f..1aec986 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1869,6 +1869,7 @@ static void musb_pm_runtime_check_session(struct  
musb *musb)


return;
}
+   /* fall through */
case MUSB_QUIRK_A_DISCONNECT_19:
if (musb->quirk_retries--) {
musb_dbg(musb,
--
2.5.0

Re: [PATCH 2/3] Bluetooth: cmtp: fix possible might sleep error in cmtp_session

[Brian Norris]

Hi,

On Tue, Jan 24, 2017 at 12:07:50PM +0800, Jeffy Chen wrote:
> It looks like cmtp_session has same pattern as the issue reported in
> old rfcomm:
> 
>   while (1) {
>   set_current_state(TASK_INTERRUPTIBLE);
>   if (condition)
>   break;
>   // may call might_sleep here
>   schedule();
>   }
>   __set_current_state(TASK_RUNNING);
> 
> Which fixed at:
>   dfb2fae Bluetooth: Fix nested sleeps
> 
> So let's fix it at the same way, also follow the suggestion of:
> https://lwn.net/Articles/628628/
> 
> Signed-off-by: Jeffy Chen 
> ---
> 
>  net/bluetooth/cmtp/core.c | 21 ++---
>  1 file changed, 14 insertions(+), 7 deletions(-)
> 
> diff --git a/net/bluetooth/cmtp/core.c b/net/bluetooth/cmtp/core.c
> index 9e59b66..6b03f2b 100644
> --- a/net/bluetooth/cmtp/core.c
> +++ b/net/bluetooth/cmtp/core.c
> @@ -280,16 +280,16 @@ static int cmtp_session(void *arg)
>   struct cmtp_session *session = arg;
>   struct sock *sk = session->sock->sk;
>   struct sk_buff *skb;
> - wait_queue_t wait;
> + DEFINE_WAIT_FUNC(wait, woken_wake_function);
>  
>   BT_DBG("session %p", session);
>  
>   set_user_nice(current, -15);
>  
> - init_waitqueue_entry(, current);
>   add_wait_queue(sk_sleep(sk), );
>   while (1) {
> - set_current_state(TASK_INTERRUPTIBLE);
> + /* Ensure session->terminate is updated */
> + smp_mb__before_atomic();
>  
>   if (atomic_read(>terminate))
>   break;
> @@ -306,9 +306,8 @@ static int cmtp_session(void *arg)
>  
>   cmtp_process_transmit(session);
>  
> - schedule();
> + wait_woken(, TASK_INTERRUPTIBLE, MAX_SCHEDULE_TIMEOUT);
>   }
> - __set_current_state(TASK_RUNNING);
>   remove_wait_queue(sk_sleep(sk), );
>  
>   down_write(_session_sem);
> @@ -393,7 +392,11 @@ int cmtp_add_connection(struct cmtp_connadd_req *req, 
> struct socket *sock)
>   err = cmtp_attach_device(session);
>   if (err < 0) {
>   atomic_inc(>terminate);
> - wake_up_process(session->task);
> +
> + /* Ensure session->terminate is updated */
> + smp_mb__after_atomic();
> +

Same comment about the barrier.

> + wake_up_interruptible(sk_sleep(session->sock->sk));
>   up_write(_session_sem);
>   return err;
>   }
> @@ -431,7 +434,11 @@ int cmtp_del_connection(struct cmtp_conndel_req *req)
>  
>   /* Stop session thread */
>   atomic_inc(>terminate);
> - wake_up_process(session->task);
> +
> + /* Ensure session->terminate is updated */
> + smp_mb__after_atomic();

And again.

But otherwise I think this looks OK, again with the caveat that I don't
know Bluetooth/CMTP that well:

Reviewed-by: Brian Norris 

> +
> + wake_up_interruptible(sk_sleep(session->sock->sk));
>   } else
>   err = -ENOENT;
>  
> -- 
> 2.1.4
> 
>