RE: [PATCH v1 4/5] ARM: dts: ls1043a: add qDMA node

[Yao Yuan]

On Mon 29 August 2016 03:34:47, : Alexander Stein  wrote:
> On Thursday 18 August 2016 14:38:47, Yuan Yao wrote:
> > From: Yuan Yao 
> >
> > Add the QDMA node for ls1043a platform to support QDMA driver.
> >
> > Signed-off-by: Yuan Yao 
> > ---
> >  arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 10 ++
> >  1 file changed, 10 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
> > b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi index
> > e8e4c3e..e463074
> > 100644
> > --- a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
> > @@ -467,6 +467,16 @@
> >  < 4 0>;
> > };
> >
> > +   qdma: qdma@839 {
> > +   compatible = "fsl,ls1021a-qdma", "fsl,ls1043a-qdma";
> 
> This doesn't match the order of your binding in Patch 2/5:
> > +- compatible :
> > +   - "fsl,ls1021a-qdma",
> > +   Or "fsl,ls1043a-qdma" followed by "fsl,ls1021a-qdma",
> 
> It should be the other way around.

Thanks for your review.
It should be compatible = "fsl,ls1043a-qspi", "fsl,ls1021a-qspi";
 I will update it in the next version.
Thanks.

RE: [PATCH v1 4/5] ARM: dts: ls1043a: add qDMA node

[Yao Yuan]

On Mon 29 August 2016 03:34:47, : Alexander Stein  wrote:
> On Thursday 18 August 2016 14:38:47, Yuan Yao wrote:
> > From: Yuan Yao 
> >
> > Add the QDMA node for ls1043a platform to support QDMA driver.
> >
> > Signed-off-by: Yuan Yao 
> > ---
> >  arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 10 ++
> >  1 file changed, 10 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
> > b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi index
> > e8e4c3e..e463074
> > 100644
> > --- a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
> > @@ -467,6 +467,16 @@
> >  < 4 0>;
> > };
> >
> > +   qdma: qdma@839 {
> > +   compatible = "fsl,ls1021a-qdma", "fsl,ls1043a-qdma";
> 
> This doesn't match the order of your binding in Patch 2/5:
> > +- compatible :
> > +   - "fsl,ls1021a-qdma",
> > +   Or "fsl,ls1043a-qdma" followed by "fsl,ls1021a-qdma",
> 
> It should be the other way around.

Thanks for your review.
It should be compatible = "fsl,ls1043a-qspi", "fsl,ls1021a-qspi";
 I will update it in the next version.
Thanks.

Re: [PATCH v3] time: alarmtimer: Add the trcepoints for alarmtimer

[Baolin Wang]

On 31 August 2016 at 02:58, John Stultz  wrote:
> On Tue, Aug 30, 2016 at 4:50 AM, Baolin Wang  wrote:
>> Hi,
>>
>> On 22 August 2016 at 12:23, Baolin Wang  wrote:
>>> For system debugging, we usually want to know who sets one alarm timer, the
>>> time of the timer, when the timer started and fired and so on. Thus adding
>>> tracepoints can help us trace the alarmtimer information.
>>>
>>> For example, when we debug the system supend/resume, if the system is always
>>> resumed by RTC alarm, we can find out which process set the alarm timer to
>>> resume system by below trace log:
>>>
>>> ..
>>> Binder:2976_6-3473  [005] d..2  1076.587732: alarmtimer_start: 
>>> process:Binder:2976_6
>>> alarmtimer type:ALARM_BOOTTIME expires:123415400 time: 1970-1-1 0:20:35
>>>
>>> Binder:2976_7-3480  [002] d..2  1076.592707: alarmtimer_cancel: 
>>> process:Binder:2976_7
>>> alarmtimer type:ALARM_BOOTTIME expires:13254630600 time: 2012-1-2 
>>> 0:11:0
>>>
>>> Binder:2976_7-3480  [002] d..2  1076.592731: alarmtimer_start: 
>>> process:Binder:2976_7
>>> alarmtimer type:ALARM_BOOTTIME expires:13253780400 time: 2012-1-1 
>>> 0:34:0
>>>
>>> system_server-2976  [003] d..2  1076.605587: alarmtimer_cancel: 
>>> process:system_server
>>> alarmtimer type:ALARM_BOOTTIME expires:123415400 time: 1970-1-1 0:20:35
>>>
>>> system_server-2976  [003] d..2  1076.605608: alarmtimer_start: 
>>> process:system_server
>>> alarmtimer type:ALARM_BOOTTIME expires:123415500 time: 1970-1-1 0:20:35
>>>
>>> system_server-3000  [002] ...1  1087.737565: alarmtimer_suspend: alarmtimer 
>>> type:ALARM_BOOTTIME
>>> expires time: 2012-1-1 0:34:0
>>> ..
>>>
>>> From the trace log, we can find out the 'Binder:2976_7' process set one 
>>> alarm
>>> timer which resumes the system.
>>
>> Do you have any comments about this patch? Thanks.
>
> No objection from me. I'll queue it for testing.

Thanks, John.

>
> thanks
> -john



-- 
Baolin.wang
Best Regards

Re: [PATCH v3] time: alarmtimer: Add the trcepoints for alarmtimer

[Baolin Wang]

On 31 August 2016 at 02:58, John Stultz  wrote:
> On Tue, Aug 30, 2016 at 4:50 AM, Baolin Wang  wrote:
>> Hi,
>>
>> On 22 August 2016 at 12:23, Baolin Wang  wrote:
>>> For system debugging, we usually want to know who sets one alarm timer, the
>>> time of the timer, when the timer started and fired and so on. Thus adding
>>> tracepoints can help us trace the alarmtimer information.
>>>
>>> For example, when we debug the system supend/resume, if the system is always
>>> resumed by RTC alarm, we can find out which process set the alarm timer to
>>> resume system by below trace log:
>>>
>>> ..
>>> Binder:2976_6-3473  [005] d..2  1076.587732: alarmtimer_start: 
>>> process:Binder:2976_6
>>> alarmtimer type:ALARM_BOOTTIME expires:123415400 time: 1970-1-1 0:20:35
>>>
>>> Binder:2976_7-3480  [002] d..2  1076.592707: alarmtimer_cancel: 
>>> process:Binder:2976_7
>>> alarmtimer type:ALARM_BOOTTIME expires:13254630600 time: 2012-1-2 
>>> 0:11:0
>>>
>>> Binder:2976_7-3480  [002] d..2  1076.592731: alarmtimer_start: 
>>> process:Binder:2976_7
>>> alarmtimer type:ALARM_BOOTTIME expires:13253780400 time: 2012-1-1 
>>> 0:34:0
>>>
>>> system_server-2976  [003] d..2  1076.605587: alarmtimer_cancel: 
>>> process:system_server
>>> alarmtimer type:ALARM_BOOTTIME expires:123415400 time: 1970-1-1 0:20:35
>>>
>>> system_server-2976  [003] d..2  1076.605608: alarmtimer_start: 
>>> process:system_server
>>> alarmtimer type:ALARM_BOOTTIME expires:123415500 time: 1970-1-1 0:20:35
>>>
>>> system_server-3000  [002] ...1  1087.737565: alarmtimer_suspend: alarmtimer 
>>> type:ALARM_BOOTTIME
>>> expires time: 2012-1-1 0:34:0
>>> ..
>>>
>>> From the trace log, we can find out the 'Binder:2976_7' process set one 
>>> alarm
>>> timer which resumes the system.
>>
>> Do you have any comments about this patch? Thanks.
>
> No objection from me. I'll queue it for testing.

Thanks, John.

>
> thanks
> -john



-- 
Baolin.wang
Best Regards

Re: [PATCH] mmc: sdhci-msm: Add pm_runtime and system PM support

[Pramod Gurav]

Thanks Ulf for the review.

On 29 August 2016 at 19:50, Ulf Hansson  wrote:
> On 16 June 2016 at 14:35, Pramod Gurav  wrote:



>> +   platform_set_drvdata(pdev, msm_host);
>> +
>> +   pm_runtime_set_active(>dev);
>> +   pm_runtime_enable(>dev);
>
> I think you need to move these a bit earlier, before calling sdhci_add_host().
>
> Maybe it's just easier if you look at the sdhci-of-at91.c driver,
> which behaves nicely around runtime PM deployment. You can probably
> use the very similar code, except the ->runtime_suspend|resume()
> callbacks.
>
> And don't forget to deploy runtime PM support in the ->remove()
> callback as well, again sdhci-of-at91 is a good reference.
>

Will take a look at the said driver and do necessary changes and repost.
Thanks again.

Regards,
Pramod

Re: [PATCH] mmc: sdhci-msm: Add pm_runtime and system PM support

[Pramod Gurav]

Thanks Ulf for the review.

On 29 August 2016 at 19:50, Ulf Hansson  wrote:
> On 16 June 2016 at 14:35, Pramod Gurav  wrote:



>> +   platform_set_drvdata(pdev, msm_host);
>> +
>> +   pm_runtime_set_active(>dev);
>> +   pm_runtime_enable(>dev);
>
> I think you need to move these a bit earlier, before calling sdhci_add_host().
>
> Maybe it's just easier if you look at the sdhci-of-at91.c driver,
> which behaves nicely around runtime PM deployment. You can probably
> use the very similar code, except the ->runtime_suspend|resume()
> callbacks.
>
> And don't forget to deploy runtime PM support in the ->remove()
> callback as well, again sdhci-of-at91 is a good reference.
>

Will take a look at the said driver and do necessary changes and repost.
Thanks again.

Regards,
Pramod

Re: constification and cocci / kernel build test robot ?

[Julia Lawall]

On Tue, 30 Aug 2016, Kees Cook wrote:

> On Tue, Aug 30, 2016 at 3:23 PM, Julia Lawall  wrote:
> >
> >
> > On Tue, 30 Aug 2016, Kees Cook wrote:
> >
> >> On Sun, Aug 28, 2016 at 9:13 AM, Julia Lawall  wrote:
> >> > [Adding Kees, in case it's of interest]
> >> >
> >> > Below is the list of types of top-level initialized structures and the
> >> > number that are const.  For quicker reading, here are some that are
> >> > sometimes const (numerator), but not always (denominator):
> >> >
> >> > file_operations: 2221/2233
> >> > attribute_group: 447/919
> >> > irq_chip: 1/518
> >> > net_device_ops: 488/498
> >> > regmap_config: 407/447
> >> > dev_pm_ops: 398/415
> >> > clk_ops: 314/386
> >> > resource: 6/385
> >> > seq_operations: 327/328
> >> > snd_pcm_ops: 9/288
> >> >
> >> > and here are the most used ones that are never const at all:
> >> >
> >> > platform_driver: 2943
> >> > platform_device: 2226
> >> > clk_branch: 1131
> >> > i2c_driver: 786
> >> > pci_driver: 781
> >> > omap_hwmod_ocp_if: 670
> >> > omap_hwmod: 582
> >> > notifier_block: 556
> >> > clk: 473
> >> > clk_rcg2: 384
> >> >
> >> > [...]
> >>
> >> The structures that should get the greatest level of attention are
> >> those that contain function pointers. The "constify" gcc plugin from
> >> PaX/Grsecurity does this, but it uses a big hammer: it moves all of
> >> them const even if they receive assignment. To handle this, there is
> >> the concept of an open/close method to gain temporary access to the
> >> structure. For example:
> >>
> >> drivers/cdrom/cdrom.c:
> >>
> >> int register_cdrom(...) {
> >> ...
> >> if (!cdo->generic_packet) {
> >> pax_open_kernel();
> >> const_cast(cdo->generic_packet) = 
> >> cdrom_dummy_generic_packet;
> >> pax_close_kernel();
> >
> > Thanks for the clarification.  The above has to be added to the code
> > manually, or the plugin does it?
>
> Currently, the plugin just warns, and a successful build depends on
> manually adding the open/close logic. For simple cases, the plugin
> could be taught to do this automatically, but some situations are more
> complex.

I guess it would be desirable to avoid this if at all possible. But maybe
it would end up in some library functions, because some drivers would call
them from an init context.

julia

Re: constification and cocci / kernel build test robot ?

[Julia Lawall]

On Tue, 30 Aug 2016, Kees Cook wrote:

> On Tue, Aug 30, 2016 at 3:23 PM, Julia Lawall  wrote:
> >
> >
> > On Tue, 30 Aug 2016, Kees Cook wrote:
> >
> >> On Sun, Aug 28, 2016 at 9:13 AM, Julia Lawall  wrote:
> >> > [Adding Kees, in case it's of interest]
> >> >
> >> > Below is the list of types of top-level initialized structures and the
> >> > number that are const.  For quicker reading, here are some that are
> >> > sometimes const (numerator), but not always (denominator):
> >> >
> >> > file_operations: 2221/2233
> >> > attribute_group: 447/919
> >> > irq_chip: 1/518
> >> > net_device_ops: 488/498
> >> > regmap_config: 407/447
> >> > dev_pm_ops: 398/415
> >> > clk_ops: 314/386
> >> > resource: 6/385
> >> > seq_operations: 327/328
> >> > snd_pcm_ops: 9/288
> >> >
> >> > and here are the most used ones that are never const at all:
> >> >
> >> > platform_driver: 2943
> >> > platform_device: 2226
> >> > clk_branch: 1131
> >> > i2c_driver: 786
> >> > pci_driver: 781
> >> > omap_hwmod_ocp_if: 670
> >> > omap_hwmod: 582
> >> > notifier_block: 556
> >> > clk: 473
> >> > clk_rcg2: 384
> >> >
> >> > [...]
> >>
> >> The structures that should get the greatest level of attention are
> >> those that contain function pointers. The "constify" gcc plugin from
> >> PaX/Grsecurity does this, but it uses a big hammer: it moves all of
> >> them const even if they receive assignment. To handle this, there is
> >> the concept of an open/close method to gain temporary access to the
> >> structure. For example:
> >>
> >> drivers/cdrom/cdrom.c:
> >>
> >> int register_cdrom(...) {
> >> ...
> >> if (!cdo->generic_packet) {
> >> pax_open_kernel();
> >> const_cast(cdo->generic_packet) = 
> >> cdrom_dummy_generic_packet;
> >> pax_close_kernel();
> >
> > Thanks for the clarification.  The above has to be added to the code
> > manually, or the plugin does it?
>
> Currently, the plugin just warns, and a successful build depends on
> manually adding the open/close logic. For simple cases, the plugin
> could be taught to do this automatically, but some situations are more
> complex.

I guess it would be desirable to avoid this if at all possible. But maybe
it would end up in some library functions, because some drivers would call
them from an init context.

julia

Re: [v2] locking/percpu-rwsem: Optimize readers and reduce global impact

[Guenter Roeck]

Peter,

On Tue, Aug 09, 2016 at 11:51:12AM +0200, Peter Zijlstra wrote:
> Currently the percpu-rwsem switches to (global) atomic ops while a
> writer is waiting; which could be quite a while and slows down
> releasing the readers.
> 
> This patch cures this problem by ordering the reader-state vs
> reader-count (see the comments in __percpu_down_read() and
> percpu_down_write()). This changes a global atomic op into a full
> memory barrier, which doesn't have the global cacheline contention.
> 
> This also enables using the percpu-rwsem with rcu_sync disabled in order
> to bias the implementation differently, reducing the writer latency by
> adding some cost to readers.
> 
> Cc: Paul McKenney 
> Reviewed-by: Oleg Nesterov 
> Signed-off-by: Peter Zijlstra (Intel) 
> ---
>  include/linux/percpu-rwsem.h  |   84 +--
>  kernel/locking/percpu-rwsem.c |  228 
> --
>  2 files changed, 206 insertions(+), 106 deletions(-)
> 
> --- a/include/linux/percpu-rwsem.h
> +++ b/include/linux/percpu-rwsem.h
> @@ -10,30 +10,96 @@
>  
>  struct percpu_rw_semaphore {
>   struct rcu_sync rss;
> - unsigned int __percpu   *fast_read_ctr;
> + unsigned int __percpu   *read_count;
>   struct rw_semaphore rw_sem;
> - atomic_tslow_read_ctr;
> - wait_queue_head_t   write_waitq;
> + wait_queue_head_t   writer;
> + int readers_block;
>  };
>  
> -extern void percpu_down_read(struct percpu_rw_semaphore *);
> -extern int  percpu_down_read_trylock(struct percpu_rw_semaphore *);
> -extern void percpu_up_read(struct percpu_rw_semaphore *);
> +extern int __percpu_down_read(struct percpu_rw_semaphore *, int);
> +extern void __percpu_up_read(struct percpu_rw_semaphore *);
> +
> +static inline void percpu_down_read(struct percpu_rw_semaphore *sem)
> +{
> + might_sleep();
> +
> + rwsem_acquire_read(>rw_sem.dep_map, 0, 0, _RET_IP_);
> +
> + preempt_disable();
> + /*
> +  * We are in an RCU-sched read-side critical section, so the writer
> +  * cannot both change sem->state from readers_fast and start checking
> +  * counters while we are here. So if we see !sem->state, we know that
> +  * the writer won't be checking until we're past the preempt_enable()
> +  * and that one the synchronize_sched() is done, the writer will see
> +  * anything we did within this RCU-sched read-size critical section.
> +  */
> + __this_cpu_inc(*sem->read_count);
> + if (unlikely(!rcu_sync_is_idle(>rss)))

The call to rcu_sync_is_idle() causes the following build error when building
x86_64:allmodconfig.

ERROR: "rcu_sync_lockdep_assert" [kernel/locking/locktorture.ko] undefined!
ERROR: "rcu_sync_lockdep_assert" [fs/ext4/ext4.ko] undefined!

I think this was also reported by the 0-day build bot.

The simple fix would of course be to export rcu_sync_lockdep_assert. Before I
apply that change to the Android code (where the patch has been aplied and
the problem is seen) - do you by any chance have a better solution in mind ?

Thanks,
Guenter

Re: [v2] locking/percpu-rwsem: Optimize readers and reduce global impact

[Guenter Roeck]

Peter,

On Tue, Aug 09, 2016 at 11:51:12AM +0200, Peter Zijlstra wrote:
> Currently the percpu-rwsem switches to (global) atomic ops while a
> writer is waiting; which could be quite a while and slows down
> releasing the readers.
> 
> This patch cures this problem by ordering the reader-state vs
> reader-count (see the comments in __percpu_down_read() and
> percpu_down_write()). This changes a global atomic op into a full
> memory barrier, which doesn't have the global cacheline contention.
> 
> This also enables using the percpu-rwsem with rcu_sync disabled in order
> to bias the implementation differently, reducing the writer latency by
> adding some cost to readers.
> 
> Cc: Paul McKenney 
> Reviewed-by: Oleg Nesterov 
> Signed-off-by: Peter Zijlstra (Intel) 
> ---
>  include/linux/percpu-rwsem.h  |   84 +--
>  kernel/locking/percpu-rwsem.c |  228 
> --
>  2 files changed, 206 insertions(+), 106 deletions(-)
> 
> --- a/include/linux/percpu-rwsem.h
> +++ b/include/linux/percpu-rwsem.h
> @@ -10,30 +10,96 @@
>  
>  struct percpu_rw_semaphore {
>   struct rcu_sync rss;
> - unsigned int __percpu   *fast_read_ctr;
> + unsigned int __percpu   *read_count;
>   struct rw_semaphore rw_sem;
> - atomic_tslow_read_ctr;
> - wait_queue_head_t   write_waitq;
> + wait_queue_head_t   writer;
> + int readers_block;
>  };
>  
> -extern void percpu_down_read(struct percpu_rw_semaphore *);
> -extern int  percpu_down_read_trylock(struct percpu_rw_semaphore *);
> -extern void percpu_up_read(struct percpu_rw_semaphore *);
> +extern int __percpu_down_read(struct percpu_rw_semaphore *, int);
> +extern void __percpu_up_read(struct percpu_rw_semaphore *);
> +
> +static inline void percpu_down_read(struct percpu_rw_semaphore *sem)
> +{
> + might_sleep();
> +
> + rwsem_acquire_read(>rw_sem.dep_map, 0, 0, _RET_IP_);
> +
> + preempt_disable();
> + /*
> +  * We are in an RCU-sched read-side critical section, so the writer
> +  * cannot both change sem->state from readers_fast and start checking
> +  * counters while we are here. So if we see !sem->state, we know that
> +  * the writer won't be checking until we're past the preempt_enable()
> +  * and that one the synchronize_sched() is done, the writer will see
> +  * anything we did within this RCU-sched read-size critical section.
> +  */
> + __this_cpu_inc(*sem->read_count);
> + if (unlikely(!rcu_sync_is_idle(>rss)))

The call to rcu_sync_is_idle() causes the following build error when building
x86_64:allmodconfig.

ERROR: "rcu_sync_lockdep_assert" [kernel/locking/locktorture.ko] undefined!
ERROR: "rcu_sync_lockdep_assert" [fs/ext4/ext4.ko] undefined!

I think this was also reported by the 0-day build bot.

The simple fix would of course be to export rcu_sync_lockdep_assert. Before I
apply that change to the Android code (where the patch has been aplied and
the problem is seen) - do you by any chance have a better solution in mind ?

Thanks,
Guenter

Re: [PATCH net-next 0/8] rxrpc: Preparation for removal of use of skbs from AFS

[David Miller]

From: David Howells <dhowe...@redhat.com>
Date: Tue, 30 Aug 2016 16:41:37 +0100

> Here's a set of patches that prepare the way for the removal of the use of
> sk_buffs from fs/afs (they'll be entirely retained within net/rxrpc):
> 
>  (1) Fix a potential NULL-pointer deref in rxrpc_abort_calls().
> 
>  (2) Condense all the terminal call state machine states to a single one
>  plus supplementary info.
> 
>  (3) Add a trace point for rxrpc call usage debugging.
> 
>  (4) Cleanups and missing headers.
> 
>  (5) Provide a way for AFS to ask about a call's peer address without
>  having an sk_buff to query.
> 
>  (6) Use call->peer directly rather than going via call->conn (which might
>  be NULL).
> 
>  (7) Pass struct socket * to various rxrpc kernel interface functions so
>  they can use that directly rather than getting it from the rxrpc_call
>  struct.
 ...
> Tagged thusly:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git
>   rxrpc-rewrite-20160830-1

Pulled, thanks David.

Re: [PATCH net-next 0/8] rxrpc: Preparation for removal of use of skbs from AFS

[David Miller]

From: David Howells 
Date: Tue, 30 Aug 2016 16:41:37 +0100

> Here's a set of patches that prepare the way for the removal of the use of
> sk_buffs from fs/afs (they'll be entirely retained within net/rxrpc):
> 
>  (1) Fix a potential NULL-pointer deref in rxrpc_abort_calls().
> 
>  (2) Condense all the terminal call state machine states to a single one
>  plus supplementary info.
> 
>  (3) Add a trace point for rxrpc call usage debugging.
> 
>  (4) Cleanups and missing headers.
> 
>  (5) Provide a way for AFS to ask about a call's peer address without
>  having an sk_buff to query.
> 
>  (6) Use call->peer directly rather than going via call->conn (which might
>  be NULL).
> 
>  (7) Pass struct socket * to various rxrpc kernel interface functions so
>  they can use that directly rather than getting it from the rxrpc_call
>  struct.
 ...
> Tagged thusly:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git
>   rxrpc-rewrite-20160830-1

Pulled, thanks David.

Re: trace: use-after-free in hist_unreg_all

[amanda4ray]

On Tuesday, June 28, 2016 at 8:59:10 AM UTC-4, dvyukov wrote:
> Hello,
> 
> While running tools/testing/selftests test suite with KASAN I hit the
> following use-after-free report:
> 
> 
> 
> ==
> BUG: KASAN: use-after-free in hist_unreg_all+0x1a1/0x1d0 at addr
> 880031632cc0
> Read of size 8 by task ftracetest/7413
> =
> BUG kmalloc-128 (Not tainted): kasan: bad access detected
> -
> 
> Disabling lock debugging due to kernel taint
> INFO: Allocated in 0x age=18446712312426182376 cpu=0 pid=0
> [< inline >] kmalloc include/linux/slab.h:478
> [< inline >] kzalloc include/linux/slab.h:622
> [<  none  >] event_hist_trigger_func+0xfcd/0x2430
> kernel/trace/trace_events_hist.c:1552
> [<  none  >] ___slab_alloc+0x564/0x5e0 mm/slub.c:2446
> [<  none  >] __slab_alloc+0x68/0xc0 mm/slub.c:2475
> [< inline >] slab_alloc_node mm/slub.c:2538
> [< inline >] slab_alloc mm/slub.c:2580
> [<  none  >] kmem_cache_alloc_trace+0x263/0x3d0 mm/slub.c:2597
> [< inline >] kmalloc include/linux/slab.h:478
> [< inline >] kzalloc include/linux/slab.h:622
> [<  none  >] event_hist_trigger_func+0xfcd/0x2430
> kernel/trace/trace_events_hist.c:1552
> [< inline >] trigger_process_regex
> kernel/trace/trace_events_trigger.c:234
> [< inline >] event_trigger_regex_write
> kernel/trace/trace_events_trigger.c:271
> [<  none  >] event_trigger_write+0x244/0x3c0
> kernel/trace/trace_events_trigger.c:300
> [<  none  >] __vfs_write+0x10b/0x620 fs/read_write.c:510
> [<  none  >] vfs_write+0x170/0x4a0 fs/read_write.c:560
> [< inline >] SYSC_write fs/read_write.c:607
> [<  none  >] SyS_write+0xd4/0x1a0 fs/read_write.c:599
> [<  none  >] entry_SYSCALL_64_fastpath+0x23/0xc1
> arch/x86/entry/entry_64.S:207
> 
> INFO: Freed in 0xfffcb4bb age=18446712239411738348 cpu=0 pid=0
> [<  none  >] trigger_data_free+0x75/0x90
> kernel/trace/trace_events_trigger.c:37
> [<  none  >] __slab_free+0x1e8/0x300 mm/slub.c:2657
> [< inline >] slab_free mm/slub.c:2810
> [<  none  >] kfree+0x2fc/0x370 mm/slub.c:3662
> [<  none  >] trigger_data_free+0x75/0x90
> kernel/trace/trace_events_trigger.c:37
> [<  none  >] event_hist_trigger_free+0xb5/0x120
> kernel/trace/trace_events_hist.c:1256
> [<  none  >] hist_unreg_all+0x156/0x1d0
> kernel/trace/trace_events_hist.c:1511
> [< inline >] event_trigger_regex_open
> kernel/trace/trace_events_trigger.c:205
> [<  none  >] event_trigger_open+0x1ee/0x2a0
> kernel/trace/trace_events_trigger.c:306
> [<  none  >] do_dentry_open+0x698/0xca0 fs/open.c:736
> [<  none  >] vfs_open+0x10f/0x210 fs/open.c:849
> [< inline >] do_last fs/namei.c:3360
> [<  none  >] path_openat+0x12f9/0x2a80 fs/namei.c:3483
> [<  none  >] do_filp_open+0x18c/0x250 fs/namei.c:3518
> [<  none  >] do_sys_open+0x1fc/0x420 fs/open.c:1016
> [< inline >] SYSC_open fs/open.c:1034
> [<  none  >] SyS_open+0x2d/0x40 fs/open.c:1029
> [<  none  >] entry_SYSCALL_64_fastpath+0x23/0xc1
> arch/x86/entry/entry_64.S:207
> INFO: Slab 0xeac58c80 objects=17 used=15 fp=0x880031632398
> flags=0xfffe004080
> INFO: Object 0x880031632c78 @offset=3192 fp=0x
> 
> Redzone 880031632c70: d0 6f 81 81 ff ff ff ff
> .o..
> Object 880031632c78: bb bb bb bb bb bb bb bb 00 00 00 00 00 00 00
> 00  
> Object 880031632c88: 00 00 00 00 00 00 00 00 c0 17 18 88 ff ff ff
> ff  
> Object 880031632c98: 00 17 18 88 ff ff ff ff 00 00 00 00 00 00 00
> 00  
> Object 880031632ca8: 00 00 00 00 00 00 00 00 98 23 63 31 00 88 ff
> ff  .#c1
> Object 880031632cb8: 00 00 00 00 00 00 00 00 40 e0 96 3e 00 88 ff
> ff  @..>
> Object 880031632cc8: 00 02 00 00 00 00 ad de 00 00 00 00 00 00 00
> 00  
> Object 880031632cd8: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00  
> Object 880031632ce8: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00  
> Redzone 880031632cf8: 00 00 00 00 00 00 00 00
> 
> Padding 880031632e30: aa b6 fc ff 00 00 00 00
> 
> CPU: 0 PID: 7413 Comm: ftracetest Tainted: GB   4.7.0-rc4+ #6
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>  880b58e0 88005ed1f8e8 82cc83cf 00c58c80
>  fbfff1016b1c 880031632000 880031632c78 88003e807480
>  eac58c80 8160e820 88005ed1f918 817b3ec0
> 
> Call Trace:
>  [] __asan_report_load8_noabort+0x3e/0x40
> 

Re: trace: use-after-free in hist_unreg_all

[amanda4ray]

On Tuesday, June 28, 2016 at 8:59:10 AM UTC-4, dvyukov wrote:
> Hello,
> 
> While running tools/testing/selftests test suite with KASAN I hit the
> following use-after-free report:
> 
> 
> 
> ==
> BUG: KASAN: use-after-free in hist_unreg_all+0x1a1/0x1d0 at addr
> 880031632cc0
> Read of size 8 by task ftracetest/7413
> =
> BUG kmalloc-128 (Not tainted): kasan: bad access detected
> -
> 
> Disabling lock debugging due to kernel taint
> INFO: Allocated in 0x age=18446712312426182376 cpu=0 pid=0
> [< inline >] kmalloc include/linux/slab.h:478
> [< inline >] kzalloc include/linux/slab.h:622
> [<  none  >] event_hist_trigger_func+0xfcd/0x2430
> kernel/trace/trace_events_hist.c:1552
> [<  none  >] ___slab_alloc+0x564/0x5e0 mm/slub.c:2446
> [<  none  >] __slab_alloc+0x68/0xc0 mm/slub.c:2475
> [< inline >] slab_alloc_node mm/slub.c:2538
> [< inline >] slab_alloc mm/slub.c:2580
> [<  none  >] kmem_cache_alloc_trace+0x263/0x3d0 mm/slub.c:2597
> [< inline >] kmalloc include/linux/slab.h:478
> [< inline >] kzalloc include/linux/slab.h:622
> [<  none  >] event_hist_trigger_func+0xfcd/0x2430
> kernel/trace/trace_events_hist.c:1552
> [< inline >] trigger_process_regex
> kernel/trace/trace_events_trigger.c:234
> [< inline >] event_trigger_regex_write
> kernel/trace/trace_events_trigger.c:271
> [<  none  >] event_trigger_write+0x244/0x3c0
> kernel/trace/trace_events_trigger.c:300
> [<  none  >] __vfs_write+0x10b/0x620 fs/read_write.c:510
> [<  none  >] vfs_write+0x170/0x4a0 fs/read_write.c:560
> [< inline >] SYSC_write fs/read_write.c:607
> [<  none  >] SyS_write+0xd4/0x1a0 fs/read_write.c:599
> [<  none  >] entry_SYSCALL_64_fastpath+0x23/0xc1
> arch/x86/entry/entry_64.S:207
> 
> INFO: Freed in 0xfffcb4bb age=18446712239411738348 cpu=0 pid=0
> [<  none  >] trigger_data_free+0x75/0x90
> kernel/trace/trace_events_trigger.c:37
> [<  none  >] __slab_free+0x1e8/0x300 mm/slub.c:2657
> [< inline >] slab_free mm/slub.c:2810
> [<  none  >] kfree+0x2fc/0x370 mm/slub.c:3662
> [<  none  >] trigger_data_free+0x75/0x90
> kernel/trace/trace_events_trigger.c:37
> [<  none  >] event_hist_trigger_free+0xb5/0x120
> kernel/trace/trace_events_hist.c:1256
> [<  none  >] hist_unreg_all+0x156/0x1d0
> kernel/trace/trace_events_hist.c:1511
> [< inline >] event_trigger_regex_open
> kernel/trace/trace_events_trigger.c:205
> [<  none  >] event_trigger_open+0x1ee/0x2a0
> kernel/trace/trace_events_trigger.c:306
> [<  none  >] do_dentry_open+0x698/0xca0 fs/open.c:736
> [<  none  >] vfs_open+0x10f/0x210 fs/open.c:849
> [< inline >] do_last fs/namei.c:3360
> [<  none  >] path_openat+0x12f9/0x2a80 fs/namei.c:3483
> [<  none  >] do_filp_open+0x18c/0x250 fs/namei.c:3518
> [<  none  >] do_sys_open+0x1fc/0x420 fs/open.c:1016
> [< inline >] SYSC_open fs/open.c:1034
> [<  none  >] SyS_open+0x2d/0x40 fs/open.c:1029
> [<  none  >] entry_SYSCALL_64_fastpath+0x23/0xc1
> arch/x86/entry/entry_64.S:207
> INFO: Slab 0xeac58c80 objects=17 used=15 fp=0x880031632398
> flags=0xfffe004080
> INFO: Object 0x880031632c78 @offset=3192 fp=0x
> 
> Redzone 880031632c70: d0 6f 81 81 ff ff ff ff
> .o..
> Object 880031632c78: bb bb bb bb bb bb bb bb 00 00 00 00 00 00 00
> 00  
> Object 880031632c88: 00 00 00 00 00 00 00 00 c0 17 18 88 ff ff ff
> ff  
> Object 880031632c98: 00 17 18 88 ff ff ff ff 00 00 00 00 00 00 00
> 00  
> Object 880031632ca8: 00 00 00 00 00 00 00 00 98 23 63 31 00 88 ff
> ff  .#c1
> Object 880031632cb8: 00 00 00 00 00 00 00 00 40 e0 96 3e 00 88 ff
> ff  @..>
> Object 880031632cc8: 00 02 00 00 00 00 ad de 00 00 00 00 00 00 00
> 00  
> Object 880031632cd8: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00  
> Object 880031632ce8: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00  
> Redzone 880031632cf8: 00 00 00 00 00 00 00 00
> 
> Padding 880031632e30: aa b6 fc ff 00 00 00 00
> 
> CPU: 0 PID: 7413 Comm: ftracetest Tainted: GB   4.7.0-rc4+ #6
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>  880b58e0 88005ed1f8e8 82cc83cf 00c58c80
>  fbfff1016b1c 880031632000 880031632c78 88003e807480
>  eac58c80 8160e820 88005ed1f918 817b3ec0
> 
> Call Trace:
>  [] __asan_report_load8_noabort+0x3e/0x40
> 

[PATCH v2 3/3] scsi/ncr5380: Improve interrupt latency during PIO tranfers

[Finn Thain]

Large PIO transfers are broken up into chunks to try to avoid disabling
local IRQs for long periods. But IRQs are still disabled for too long
and this causes SCC FIFO overruns during serial port transfers.

This patch reduces the PIO chunk size to reduce interrupt latency to
something on the order of milliseconds, at the expense of additional CPU
overhead from extra iterations of the NCR5380_main() loop.

That CPU overhead is a problem for slow machines (e.g. mac_scsi on 25 MHz
68030) but these machines generally use PDMA not PIO. This patch doesn't
make the overhead any worse on my Mac LC III (because it only gets about
510 accesses per ms).

This patch decreases disk performance by a fraction of one percent for
dmx3191d on my 333 MHz PowerPC 750. Other affected hardware (such as
g_NCR5380 on x86) was not tested but 5380 ISA cards generally use PDMA
and not PIO.

Signed-off-by: Finn Thain 

---
Changed since v1:
- PIO transfer chunk size is now hard-coded for simplicity.

---
 drivers/scsi/NCR5380.c |8 
 drivers/scsi/NCR5380.h |2 ++
 2 files changed, 6 insertions(+), 4 deletions(-)

Index: linux/drivers/scsi/NCR5380.c
===
--- linux.orig/drivers/scsi/NCR5380.c   2016-08-31 14:44:51.0 +1000
+++ linux/drivers/scsi/NCR5380.c2016-08-31 14:44:52.0 +1000
@@ -1849,11 +1849,11 @@ static void NCR5380_information_transfer
/* XXX - need to source or sink 
data here, as appropriate */
}
} else {
-   /* Break up transfer into 3 ms chunks,
-* presuming 6 accesses per handshake.
+   /* Transfer a small chunk so that the
+* irq mode lock is not held too long.
 */
-   transfersize = min((unsigned 
long)cmd->SCp.this_residual,
-  
hostdata->accesses_per_ms / 2);
+   transfersize = 
min(cmd->SCp.this_residual,
+  
NCR5380_PIO_CHUNK_SIZE);
len = transfersize;
NCR5380_transfer_pio(instance, , 
,
 (unsigned char 
**)>SCp.ptr);
Index: linux/drivers/scsi/NCR5380.h
===
--- linux.orig/drivers/scsi/NCR5380.h   2016-08-31 14:44:51.0 +1000
+++ linux/drivers/scsi/NCR5380.h2016-08-31 14:44:52.0 +1000
@@ -250,6 +250,8 @@ struct NCR5380_cmd {
 
 #define NCR5380_CMD_SIZE   (sizeof(struct NCR5380_cmd))
 
+#define NCR5380_PIO_CHUNK_SIZE 256
+
 static inline struct scsi_cmnd *NCR5380_to_scmd(struct NCR5380_cmd *ncmd_ptr)
 {
return ((struct scsi_cmnd *)ncmd_ptr) - 1;

[PATCH v2 3/3] scsi/ncr5380: Improve interrupt latency during PIO tranfers

[Finn Thain]

Large PIO transfers are broken up into chunks to try to avoid disabling
local IRQs for long periods. But IRQs are still disabled for too long
and this causes SCC FIFO overruns during serial port transfers.

This patch reduces the PIO chunk size to reduce interrupt latency to
something on the order of milliseconds, at the expense of additional CPU
overhead from extra iterations of the NCR5380_main() loop.

That CPU overhead is a problem for slow machines (e.g. mac_scsi on 25 MHz
68030) but these machines generally use PDMA not PIO. This patch doesn't
make the overhead any worse on my Mac LC III (because it only gets about
510 accesses per ms).

This patch decreases disk performance by a fraction of one percent for
dmx3191d on my 333 MHz PowerPC 750. Other affected hardware (such as
g_NCR5380 on x86) was not tested but 5380 ISA cards generally use PDMA
and not PIO.

Signed-off-by: Finn Thain 

---
Changed since v1:
- PIO transfer chunk size is now hard-coded for simplicity.

---
 drivers/scsi/NCR5380.c |8 
 drivers/scsi/NCR5380.h |2 ++
 2 files changed, 6 insertions(+), 4 deletions(-)

Index: linux/drivers/scsi/NCR5380.c
===
--- linux.orig/drivers/scsi/NCR5380.c   2016-08-31 14:44:51.0 +1000
+++ linux/drivers/scsi/NCR5380.c2016-08-31 14:44:52.0 +1000
@@ -1849,11 +1849,11 @@ static void NCR5380_information_transfer
/* XXX - need to source or sink 
data here, as appropriate */
}
} else {
-   /* Break up transfer into 3 ms chunks,
-* presuming 6 accesses per handshake.
+   /* Transfer a small chunk so that the
+* irq mode lock is not held too long.
 */
-   transfersize = min((unsigned 
long)cmd->SCp.this_residual,
-  
hostdata->accesses_per_ms / 2);
+   transfersize = 
min(cmd->SCp.this_residual,
+  
NCR5380_PIO_CHUNK_SIZE);
len = transfersize;
NCR5380_transfer_pio(instance, , 
,
 (unsigned char 
**)>SCp.ptr);
Index: linux/drivers/scsi/NCR5380.h
===
--- linux.orig/drivers/scsi/NCR5380.h   2016-08-31 14:44:51.0 +1000
+++ linux/drivers/scsi/NCR5380.h2016-08-31 14:44:52.0 +1000
@@ -250,6 +250,8 @@ struct NCR5380_cmd {
 
 #define NCR5380_CMD_SIZE   (sizeof(struct NCR5380_cmd))
 
+#define NCR5380_PIO_CHUNK_SIZE 256
+
 static inline struct scsi_cmnd *NCR5380_to_scmd(struct NCR5380_cmd *ncmd_ptr)
 {
return ((struct scsi_cmnd *)ncmd_ptr) - 1;

Re: [PATCH 1/4] spinlock: Document memory barrier rules

[Manfred Spraul]

On 08/29/2016 03:44 PM, Peter Zijlstra wrote:


If you add a barrier, the Changelog had better be clear. And I'm still
not entirely sure I get what exactly this barrier should do, nor why it
defaults to a full smp_mb. If what I suspect it should do, only PPC and
ARM64 need the barrier.
The barrier must ensure that taking the spinlock (as observed by another 
cpu with spin_unlock_wait()) and a following read are ordered.


start condition: sma->complex_mode = false;

CPU 1:
spin_lock(>lock); /* sem_nsems instances */
smp_mb__after_spin_lock();
if (!smp_load_acquire(>complex_mode)) {
/* fast path successful! */
return sops->sem_num;
}
 /* slow path, not relevant */

CPU 2: (holding sma->sem_perm.lock)

smp_store_mb(sma->complex_mode, true);

for (i = 0; i < sma->sem_nsems; i++) {
spin_unlock_wait(>sem_base[i].lock);
}

It must not happen that both CPUs proceed:
Either CPU1 proceeds, then CPU2 must spin in spin_unlock_wait()
or CPU2 proceeds, then CPU1 must enter the slow path.

What about this?
/*
 * spin_lock() provides ACQUIRE semantics regarding reading the lock.
 * There are no guarantees that the store of the lock is visible before
 * any read or write operation within the protected area is performed.
 * If the store of the lock must happen first, this function is required.
 */
#define spin_lock_store_acquire()

I would update the patch series.

--
Manfred

Re: [PATCH 1/4] spinlock: Document memory barrier rules

[Manfred Spraul]

On 08/29/2016 03:44 PM, Peter Zijlstra wrote:


If you add a barrier, the Changelog had better be clear. And I'm still
not entirely sure I get what exactly this barrier should do, nor why it
defaults to a full smp_mb. If what I suspect it should do, only PPC and
ARM64 need the barrier.
The barrier must ensure that taking the spinlock (as observed by another 
cpu with spin_unlock_wait()) and a following read are ordered.


start condition: sma->complex_mode = false;

CPU 1:
spin_lock(>lock); /* sem_nsems instances */
smp_mb__after_spin_lock();
if (!smp_load_acquire(>complex_mode)) {
/* fast path successful! */
return sops->sem_num;
}
 /* slow path, not relevant */

CPU 2: (holding sma->sem_perm.lock)

smp_store_mb(sma->complex_mode, true);

for (i = 0; i < sma->sem_nsems; i++) {
spin_unlock_wait(>sem_base[i].lock);
}

It must not happen that both CPUs proceed:
Either CPU1 proceeds, then CPU2 must spin in spin_unlock_wait()
or CPU2 proceeds, then CPU1 must enter the slow path.

What about this?
/*
 * spin_lock() provides ACQUIRE semantics regarding reading the lock.
 * There are no guarantees that the store of the lock is visible before
 * any read or write operation within the protected area is performed.
 * If the store of the lock must happen first, this function is required.
 */
#define spin_lock_store_acquire()

I would update the patch series.

--
Manfred

Re: [PATCH V3 2/2] rtc/rtc-cmos: Initialize software counters before irq is registered

[Dave Young]

Hi, Pratyush,

I'm not sure who is the maintainer to review and take the patches,
In MATAINERS file, x86 hpet is orphaned. rtc-cmos may go to rtc
maitianer Alessandro Zummo

Ccing Andrew maybe he can also take the patches for orphaned component.

On 08/30/16 at 03:24pm, Pratyush Anand wrote:
> Hi Dave,
> 
> On 30/08/2016:04:22:30 PM, Dave Young wrote:
> > Hi, Pratyush
> > 
> > On 08/16/16 at 08:55am, Pratyush Anand wrote:
> > > We have observed on few x86 machines with rtc-cmos device that
> > > hpet_rtc_interrupt() is called just after irq registration and before
> > > cmos_do_probe() could call hpet_rtc_timer_init().
> > > 
> > > So, neither hpet_default_delta nor hpet_t1_cmp is initialized by the time
> > > interrupt is raised in the given situation, and this results in NMI
> > > watchdog LOCKUP.
> > > 
> > > It has only been observed sporadically on kdump secondary kernels.
> > > 
> > > See the call trace:
> > > ---<-snip->---
> > >27.913194] Kernel panic - not syncing: Watchdog detected hard LOCKUP on
> > > cpu 0
> > > [   27.915371] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
> > > 3.10.0-342.el7.x86_64 #1
> > > [   27.917503] Hardware name: HP ProLiant DL160 Gen8, BIOS J03 02/10/2014
> > > [   27.919455]  8186a728 59c82488 880034e05af0
> > > 81637bd4
> > > [   27.921870]  880034e05b70 8163144a 0010
> > > 880034e05b80
> > > [   27.924257]  880034e05b20 59c82488 
> > > 
> > > [   27.926599] Call Trace:
> > > [   27.927352][] dump_stack+0x19/0x1b
> > > [   27.929080]  [] panic+0xd8/0x1e7
> > > [   27.930588]  [] ? restart_watchdog_hrtimer+0x50/0x50
> > > [   27.932502]  [] watchdog_overflow_callback+0xc2/0xd0
> > > [   27.934427]  [] __perf_event_overflow+0xa1/0x250
> > > [   27.936232]  [] perf_event_overflow+0x14/0x20
> > > [   27.937957]  [] intel_pmu_handle_irq+0x1e8/0x470
> > > [   27.939799]  [] perf_event_nmi_handler+0x2b/0x50
> > > [   27.941649]  [] nmi_handle.isra.0+0x69/0xb0
> > > [   27.943348]  [] do_nmi+0x169/0x340
> > > [   27.944802]  [] end_repeat_nmi+0x1e/0x2e
> > > [   27.946424]  [] ? hpet_rtc_interrupt+0x85/0x380
> > > [   27.948197]  [] ? hpet_rtc_interrupt+0x85/0x380
> > > [   27.949992]  [] ? hpet_rtc_interrupt+0x85/0x380
> > > [   27.951816]  <>[] ?
> > > run_timer_softirq+0x43/0x340
> > > [   27.954114]  [] handle_irq_event_percpu+0x3e/0x1e0
> > > [   27.955962]  [] handle_irq_event+0x3d/0x60
> > > [   27.957635]  [] handle_edge_irq+0x77/0x130
> > > [   27.959332]  [] handle_irq+0xbf/0x150
> > > [   27.960949]  [] do_IRQ+0x4f/0xf0
> > > [   27.962434]  [] common_interrupt+0x6d/0x6d
> > > [   27.964101][] ?
> > > _raw_spin_unlock_irqrestore+0x1b/0x40
> > > [   27.966308]  [] __setup_irq+0x2a7/0x570
> > > [   28.067859]  [] ? hpet_cpuhp_notify+0x140/0x140
> > > [   28.069709]  [] request_threaded_irq+0xcc/0x170
> > > [   28.071585]  [] cmos_do_probe+0x1e6/0x450
> > > [   28.073240]  [] ? cmos_do_probe+0x450/0x450
> > > [   28.074911]  [] cmos_pnp_probe+0xbb/0xc0
> > > [   28.076533]  [] pnp_device_probe+0x65/0xd0
> > > [   28.078198]  [] driver_probe_device+0x87/0x390
> > > [   28.079971]  [] __driver_attach+0x93/0xa0
> > > [   28.081660]  [] ? __device_attach+0x40/0x40
> > > [   28.083662]  [] bus_for_each_dev+0x73/0xc0
> > > [   28.085370]  [] driver_attach+0x1e/0x20
> > > [   28.086974]  [] bus_add_driver+0x200/0x2d0
> > > [   28.088634]  [] ? rtc_sysfs_init+0xe/0xe
> > > [   28.090349]  [] driver_register+0x64/0xf0
> > > [   28.091989]  [] pnp_register_driver+0x20/0x30
> > > [   28.093707]  [] cmos_init+0x11/0x71
> > > ---<-snip->---
> > > 
> > > The previous patch split hpet_rtc_timer_init into
> > > hpet_rtc_timer_counter_init() and hpet_rtc_timer_enable().
> > > 
> > > Therefore, this patch moved hpet_rtc_timer_counter_init() before IRQ
> > > registration, so that we can gracefully handle such spurious interrupts.
> > > 
> > > We were able to reproduce the problem in maximum 15 trials of kdump
> > > secondary kernel boot on an hp-dl160gen8 machine without this patch.
> > > However, more than 35 trials went fine after applying this patch.
> > > 
> > > Signed-off-by: Pratyush Anand 
> > > [dzic...@redhat.com: edited the patch's summary]
> > > Signed-off-by: Don Zickus 
> > > ---
> > >  drivers/rtc/rtc-cmos.c | 13 -
> > >  1 file changed, 12 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c
> > > index 43745cac0141..089d987f2638 100644
> > > --- a/drivers/rtc/rtc-cmos.c
> > > +++ b/drivers/rtc/rtc-cmos.c
> > > @@ -129,6 +129,16 @@ static inline int hpet_rtc_dropped_irq(void)
> > >   return 0;
> > >  }
> > >  
> > > +static inline int hpet_rtc_timer_counter_init(void)
> > > +{
> > > + return 0;
> > > +}
> > > +
> > > +static inline int hpet_rtc_timer_enable(void)
> > > +{
> > > + return 0;
> > > +}
> > > +
> > 
> > Can these dummy functions go to 

Re: [PATCH V3 2/2] rtc/rtc-cmos: Initialize software counters before irq is registered

[Dave Young]

Hi, Pratyush,

I'm not sure who is the maintainer to review and take the patches,
In MATAINERS file, x86 hpet is orphaned. rtc-cmos may go to rtc
maitianer Alessandro Zummo

Ccing Andrew maybe he can also take the patches for orphaned component.

On 08/30/16 at 03:24pm, Pratyush Anand wrote:
> Hi Dave,
> 
> On 30/08/2016:04:22:30 PM, Dave Young wrote:
> > Hi, Pratyush
> > 
> > On 08/16/16 at 08:55am, Pratyush Anand wrote:
> > > We have observed on few x86 machines with rtc-cmos device that
> > > hpet_rtc_interrupt() is called just after irq registration and before
> > > cmos_do_probe() could call hpet_rtc_timer_init().
> > > 
> > > So, neither hpet_default_delta nor hpet_t1_cmp is initialized by the time
> > > interrupt is raised in the given situation, and this results in NMI
> > > watchdog LOCKUP.
> > > 
> > > It has only been observed sporadically on kdump secondary kernels.
> > > 
> > > See the call trace:
> > > ---<-snip->---
> > >27.913194] Kernel panic - not syncing: Watchdog detected hard LOCKUP on
> > > cpu 0
> > > [   27.915371] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
> > > 3.10.0-342.el7.x86_64 #1
> > > [   27.917503] Hardware name: HP ProLiant DL160 Gen8, BIOS J03 02/10/2014
> > > [   27.919455]  8186a728 59c82488 880034e05af0
> > > 81637bd4
> > > [   27.921870]  880034e05b70 8163144a 0010
> > > 880034e05b80
> > > [   27.924257]  880034e05b20 59c82488 
> > > 
> > > [   27.926599] Call Trace:
> > > [   27.927352][] dump_stack+0x19/0x1b
> > > [   27.929080]  [] panic+0xd8/0x1e7
> > > [   27.930588]  [] ? restart_watchdog_hrtimer+0x50/0x50
> > > [   27.932502]  [] watchdog_overflow_callback+0xc2/0xd0
> > > [   27.934427]  [] __perf_event_overflow+0xa1/0x250
> > > [   27.936232]  [] perf_event_overflow+0x14/0x20
> > > [   27.937957]  [] intel_pmu_handle_irq+0x1e8/0x470
> > > [   27.939799]  [] perf_event_nmi_handler+0x2b/0x50
> > > [   27.941649]  [] nmi_handle.isra.0+0x69/0xb0
> > > [   27.943348]  [] do_nmi+0x169/0x340
> > > [   27.944802]  [] end_repeat_nmi+0x1e/0x2e
> > > [   27.946424]  [] ? hpet_rtc_interrupt+0x85/0x380
> > > [   27.948197]  [] ? hpet_rtc_interrupt+0x85/0x380
> > > [   27.949992]  [] ? hpet_rtc_interrupt+0x85/0x380
> > > [   27.951816]  <>[] ?
> > > run_timer_softirq+0x43/0x340
> > > [   27.954114]  [] handle_irq_event_percpu+0x3e/0x1e0
> > > [   27.955962]  [] handle_irq_event+0x3d/0x60
> > > [   27.957635]  [] handle_edge_irq+0x77/0x130
> > > [   27.959332]  [] handle_irq+0xbf/0x150
> > > [   27.960949]  [] do_IRQ+0x4f/0xf0
> > > [   27.962434]  [] common_interrupt+0x6d/0x6d
> > > [   27.964101][] ?
> > > _raw_spin_unlock_irqrestore+0x1b/0x40
> > > [   27.966308]  [] __setup_irq+0x2a7/0x570
> > > [   28.067859]  [] ? hpet_cpuhp_notify+0x140/0x140
> > > [   28.069709]  [] request_threaded_irq+0xcc/0x170
> > > [   28.071585]  [] cmos_do_probe+0x1e6/0x450
> > > [   28.073240]  [] ? cmos_do_probe+0x450/0x450
> > > [   28.074911]  [] cmos_pnp_probe+0xbb/0xc0
> > > [   28.076533]  [] pnp_device_probe+0x65/0xd0
> > > [   28.078198]  [] driver_probe_device+0x87/0x390
> > > [   28.079971]  [] __driver_attach+0x93/0xa0
> > > [   28.081660]  [] ? __device_attach+0x40/0x40
> > > [   28.083662]  [] bus_for_each_dev+0x73/0xc0
> > > [   28.085370]  [] driver_attach+0x1e/0x20
> > > [   28.086974]  [] bus_add_driver+0x200/0x2d0
> > > [   28.088634]  [] ? rtc_sysfs_init+0xe/0xe
> > > [   28.090349]  [] driver_register+0x64/0xf0
> > > [   28.091989]  [] pnp_register_driver+0x20/0x30
> > > [   28.093707]  [] cmos_init+0x11/0x71
> > > ---<-snip->---
> > > 
> > > The previous patch split hpet_rtc_timer_init into
> > > hpet_rtc_timer_counter_init() and hpet_rtc_timer_enable().
> > > 
> > > Therefore, this patch moved hpet_rtc_timer_counter_init() before IRQ
> > > registration, so that we can gracefully handle such spurious interrupts.
> > > 
> > > We were able to reproduce the problem in maximum 15 trials of kdump
> > > secondary kernel boot on an hp-dl160gen8 machine without this patch.
> > > However, more than 35 trials went fine after applying this patch.
> > > 
> > > Signed-off-by: Pratyush Anand 
> > > [dzic...@redhat.com: edited the patch's summary]
> > > Signed-off-by: Don Zickus 
> > > ---
> > >  drivers/rtc/rtc-cmos.c | 13 -
> > >  1 file changed, 12 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c
> > > index 43745cac0141..089d987f2638 100644
> > > --- a/drivers/rtc/rtc-cmos.c
> > > +++ b/drivers/rtc/rtc-cmos.c
> > > @@ -129,6 +129,16 @@ static inline int hpet_rtc_dropped_irq(void)
> > >   return 0;
> > >  }
> > >  
> > > +static inline int hpet_rtc_timer_counter_init(void)
> > > +{
> > > + return 0;
> > > +}
> > > +
> > > +static inline int hpet_rtc_timer_enable(void)
> > > +{
> > > + return 0;
> > > +}
> > > +
> > 
> > Can these dummy functions go to /usr/include/linux/hpet.h alont with
> > the #ifdef  

Re: [PATCH 0/7 v5] K3DMA fixes for HiKey HDMI audio

[Vinod Koul]

On Mon, Aug 29, 2016 at 10:30:46AM -0700, John Stultz wrote:
> Just sending these the k3dma fixes and cyclic mode patches
> needed to support audio on HiKey, hopefully one last time. :)
> 
> Again, no code changes here, but I did re-order the Kconfig
> chnage to be last to avoid a bisection build issue on i386
> w/ COMPILE_TEST that the kbuild test bot found.

Applied all, thanks

-- 
~Vinod

Re: [PATCH 0/7 v5] K3DMA fixes for HiKey HDMI audio

[Vinod Koul]

On Mon, Aug 29, 2016 at 10:30:46AM -0700, John Stultz wrote:
> Just sending these the k3dma fixes and cyclic mode patches
> needed to support audio on HiKey, hopefully one last time. :)
> 
> Again, no code changes here, but I did re-order the Kconfig
> chnage to be last to avoid a bisection build issue on i386
> w/ COMPILE_TEST that the kbuild test bot found.

Applied all, thanks

-- 
~Vinod

Re: [PATCH v2] scsi: move function declarations to scsi_priv.h

[Martin K. Petersen]

> "Baoyou" == Baoyou Xie  writes:

Baoyou> We get 2 warnings about global functions without a declaration
Baoyou> in the scsi driver when building with W=1:
Baoyou> drivers/scsi/scsi_lib.c:467:6: warning: no previous prototype
Baoyou> for 'scsi_requeue_run_queue' [-Wmissing-prototypes]
Baoyou> drivers/scsi/scsi_lib.c:2609:6: warning: no previous prototype
Baoyou> for 'scsi_evt_thread' [-Wmissing-prototypes]

Baoyou> in fact, both functions are declared in drivers/scsi/scsi_scan.c
Baoyou> but need to move them into scsi_priv.h.

Applied to 4.9/scsi-queue.

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH v2] scsi: move function declarations to scsi_priv.h

[Martin K. Petersen]

> "Baoyou" == Baoyou Xie  writes:

Baoyou> We get 2 warnings about global functions without a declaration
Baoyou> in the scsi driver when building with W=1:
Baoyou> drivers/scsi/scsi_lib.c:467:6: warning: no previous prototype
Baoyou> for 'scsi_requeue_run_queue' [-Wmissing-prototypes]
Baoyou> drivers/scsi/scsi_lib.c:2609:6: warning: no previous prototype
Baoyou> for 'scsi_evt_thread' [-Wmissing-prototypes]

Baoyou> in fact, both functions are declared in drivers/scsi/scsi_scan.c
Baoyou> but need to move them into scsi_priv.h.

Applied to 4.9/scsi-queue.

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH 0/3] Small fixes and cleanup

[Martin K. Petersen]

> "Finn" == Finn Thain  writes:

Finn> Miscellaneous small patches for an interrupt latency issue, a
Finn> compiler warning and a documentation cleanup.

Applied patches 1 and 2 to 4.9/scsi-queue.

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH 0/3] Small fixes and cleanup

[Martin K. Petersen]

> "Finn" == Finn Thain  writes:

Finn> Miscellaneous small patches for an interrupt latency issue, a
Finn> compiler warning and a documentation cleanup.

Applied patches 1 and 2 to 4.9/scsi-queue.

-- 
Martin K. Petersen  Oracle Linux Engineering

[PATCH v3 1/2] regulator: pwm: Add support for a fixed delay after duty cycle changes

[Douglas Anderson]

From: Matthias Kaehlcke 

A change of the duty cycle doesn't necessarily cause an immediate switch
to the target voltage.  On many PWM regulators there is a fixed "settle
time" (irrespective of the jump size) that we need to wait after an
upward jump.  This change introduces the device tree property
"settle-time-up-us" which allows us to specify a fixed delay after a
voltage increase.

We don't add an option of a fixed delay on the way down for now because
the way down is probably modelled best with a ramp rate, not a fixed
delay.

Signed-off-by: Matthias Kaehlcke 
Signed-off-by: Douglas Anderson 
---
Changes in v3:
- Took out fixed delay for falling transitions
- Updated description

 .../devicetree/bindings/regulator/pwm-regulator.txt   |  6 ++
 drivers/regulator/pwm-regulator.c | 19 +++
 2 files changed, 21 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/regulator/pwm-regulator.txt 
b/Documentation/devicetree/bindings/regulator/pwm-regulator.txt
index 3aeba9f86ed8..9dc15d18e787 100644
--- a/Documentation/devicetree/bindings/regulator/pwm-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/pwm-regulator.txt
@@ -34,6 +34,12 @@ Only required for Voltage Table Mode:
First cell is voltage in microvolts (uV)
Second cell is duty-cycle in percent (%)
 
+Optional properties:
+
+- settle-time-up-us:   Time to settle down after a voltage increase
+   (unit: us). For regulators with a ramp delay
+   the two values are added.
+
 Optional properties for Continuous mode:
 - pwm-dutycycle-unit:  Integer value encoding the duty cycle unit. If not
defined, <100> is assumed, meaning that
diff --git a/drivers/regulator/pwm-regulator.c 
b/drivers/regulator/pwm-regulator.c
index c24524242da2..94f1ca3b793d 100644
--- a/drivers/regulator/pwm-regulator.c
+++ b/drivers/regulator/pwm-regulator.c
@@ -48,6 +48,8 @@ struct pwm_regulator_data {
 
/* Enable GPIO */
struct gpio_desc *enb_gpio;
+
+   u32 settle_time_up_us;
 };
 
 struct pwm_voltages {
@@ -195,6 +197,7 @@ static int pwm_regulator_set_voltage(struct regulator_dev 
*rdev,
unsigned int max_uV_duty = drvdata->continuous.max_uV_dutycycle;
unsigned int duty_unit = drvdata->continuous.dutycycle_unit;
unsigned int ramp_delay = rdev->constraints->ramp_delay;
+   unsigned int delay = 0;
int min_uV = rdev->constraints->min_uV;
int max_uV = rdev->constraints->max_uV;
int diff_uV = max_uV - min_uV;
@@ -233,12 +236,17 @@ static int pwm_regulator_set_voltage(struct regulator_dev 
*rdev,
return ret;
}
 
-   if ((ramp_delay == 0) || !pwm_regulator_is_enabled(rdev))
+   if (req_min_uV > old_uV)
+   delay = drvdata->settle_time_up_us;
+
+   if (ramp_delay != 0)
+   /* Adjust ramp delay to uS and add to settle time. */
+   delay += DIV_ROUND_UP(abs(req_min_uV - old_uV), ramp_delay);
+
+   if ((delay == 0) || !pwm_regulator_is_enabled(rdev))
return 0;
 
-   /* Ramp delay is in uV/uS. Adjust to uS and delay */
-   ramp_delay = DIV_ROUND_UP(abs(req_min_uV - old_uV), ramp_delay);
-   usleep_range(ramp_delay, ramp_delay + DIV_ROUND_UP(ramp_delay, 10));
+   usleep_range(delay, delay + DIV_ROUND_UP(delay, 10));
 
return 0;
 }
@@ -368,6 +376,9 @@ static int pwm_regulator_probe(struct platform_device *pdev)
if (!init_data)
return -ENOMEM;
 
+   of_property_read_u32(np, "settle-time-up-us",
+   >settle_time_up_us);
+
config.of_node = np;
config.dev = >dev;
config.driver_data = drvdata;
-- 
2.8.0.rc3.226.g39d4020

[PATCH v3 2/2] regulator: pwm: Prevent falling too fast

[Douglas Anderson]

On some boards it's possible that transitioning the PWM regulator
downwards too fast will trigger the over voltage protection (OVP) on the
regulator.  This is because until the voltage actually falls there is a
time when the requested voltage is much lower than the actual voltage.

We'll fix this OVP problem by allowing users to specify the maximum
voltage that we can safely fall.  Apparently this maximum safe voltage
should be specified as a percentage of the current voltage.  The PWM
regulator will then break things into separate steps with a delay in
between.

In order to figure out what the delay should be we need to figure out
how slowly the voltage rail might fall in the worst (slowest) case.
We'll assume this worst case is present and delay so we know for sure
that we've finished each step.

In this patch we actually block returning from the set_voltage() call
until we've finished delaying.  A future patch atop this one might
choose to return more immediately and let the voltages fall in the
background.  That would possibly to allow us to cancel a slow downward
decay if there was a request to go back up.

Signed-off-by: Douglas Anderson 
---
Changes in v3:
- Prevent falling too fast new for v3.

 .../bindings/regulator/pwm-regulator.txt   |  7 ++
 drivers/regulator/pwm-regulator.c  | 79 +++---
 2 files changed, 78 insertions(+), 8 deletions(-)

diff --git a/Documentation/devicetree/bindings/regulator/pwm-regulator.txt 
b/Documentation/devicetree/bindings/regulator/pwm-regulator.txt
index 9dc15d18e787..99fa09c42aac 100644
--- a/Documentation/devicetree/bindings/regulator/pwm-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/pwm-regulator.txt
@@ -39,6 +39,13 @@ Optional properties:
 - settle-time-up-us:   Time to settle down after a voltage increase
(unit: us). For regulators with a ramp delay
the two values are added.
+- safe-fall-percent:   If specified, it's not safe to transition the regulator
+   down faster than this amount and bigger jumps need to
+   be broken into more than one step.
+- slowest-decay-rate:  Describes how slowly the regulator voltage will
+   decay down in the worst case (lightest expected load).
+   Specified in uV / us (like main regulator ramp rate).
+   This is required when safe-fall-percent is specified.
 
 Optional properties for Continuous mode:
 - pwm-dutycycle-unit:  Integer value encoding the duty cycle unit. If not
diff --git a/drivers/regulator/pwm-regulator.c 
b/drivers/regulator/pwm-regulator.c
index 94f1ca3b793d..47675632c0c6 100644
--- a/drivers/regulator/pwm-regulator.c
+++ b/drivers/regulator/pwm-regulator.c
@@ -50,6 +50,8 @@ struct pwm_regulator_data {
struct gpio_desc *enb_gpio;
 
u32 settle_time_up_us;
+   u32 slowest_decay_rate;
+   u32 safe_fall_percent;
 };
 
 struct pwm_voltages {
@@ -188,9 +190,8 @@ static int pwm_regulator_get_voltage(struct regulator_dev 
*rdev)
return voltage + min_uV;
 }
 
-static int pwm_regulator_set_voltage(struct regulator_dev *rdev,
-int req_min_uV, int req_max_uV,
-unsigned int *selector)
+static int _pwm_regulator_set_voltage(struct regulator_dev *rdev,
+ int old_uV, int req_uV)
 {
struct pwm_regulator_data *drvdata = rdev_get_drvdata(rdev);
unsigned int min_uV_duty = drvdata->continuous.min_uV_dutycycle;
@@ -202,7 +203,6 @@ static int pwm_regulator_set_voltage(struct regulator_dev 
*rdev,
int max_uV = rdev->constraints->max_uV;
int diff_uV = max_uV - min_uV;
struct pwm_state pstate;
-   int old_uV = pwm_regulator_get_voltage(rdev);
unsigned int diff_duty;
unsigned int dutycycle;
int ret;
@@ -219,8 +219,7 @@ static int pwm_regulator_set_voltage(struct regulator_dev 
*rdev,
else
diff_duty = max_uV_duty - min_uV_duty;
 
-   dutycycle = DIV_ROUND_CLOSEST_ULL((u64)(req_min_uV - min_uV) *
- diff_duty,
+   dutycycle = DIV_ROUND_CLOSEST_ULL((u64)(req_uV - min_uV) * diff_duty,
  diff_uV);
 
if (max_uV_duty < min_uV_duty)
@@ -236,12 +235,12 @@ static int pwm_regulator_set_voltage(struct regulator_dev 
*rdev,
return ret;
}
 
-   if (req_min_uV > old_uV)
+   if (req_uV > old_uV)
delay = drvdata->settle_time_up_us;
 
if (ramp_delay != 0)
/* Adjust ramp delay to uS and add to settle time. */
-   delay += DIV_ROUND_UP(abs(req_min_uV - old_uV), ramp_delay);
+   delay += DIV_ROUND_UP(abs(req_uV - old_uV), ramp_delay);
 
if ((delay == 0) || !pwm_regulator_is_enabled(rdev))

[PATCH v3 1/2] regulator: pwm: Add support for a fixed delay after duty cycle changes

[Douglas Anderson]

From: Matthias Kaehlcke 

A change of the duty cycle doesn't necessarily cause an immediate switch
to the target voltage.  On many PWM regulators there is a fixed "settle
time" (irrespective of the jump size) that we need to wait after an
upward jump.  This change introduces the device tree property
"settle-time-up-us" which allows us to specify a fixed delay after a
voltage increase.

We don't add an option of a fixed delay on the way down for now because
the way down is probably modelled best with a ramp rate, not a fixed
delay.

Signed-off-by: Matthias Kaehlcke 
Signed-off-by: Douglas Anderson 
---
Changes in v3:
- Took out fixed delay for falling transitions
- Updated description

 .../devicetree/bindings/regulator/pwm-regulator.txt   |  6 ++
 drivers/regulator/pwm-regulator.c | 19 +++
 2 files changed, 21 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/regulator/pwm-regulator.txt 
b/Documentation/devicetree/bindings/regulator/pwm-regulator.txt
index 3aeba9f86ed8..9dc15d18e787 100644
--- a/Documentation/devicetree/bindings/regulator/pwm-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/pwm-regulator.txt
@@ -34,6 +34,12 @@ Only required for Voltage Table Mode:
First cell is voltage in microvolts (uV)
Second cell is duty-cycle in percent (%)
 
+Optional properties:
+
+- settle-time-up-us:   Time to settle down after a voltage increase
+   (unit: us). For regulators with a ramp delay
+   the two values are added.
+
 Optional properties for Continuous mode:
 - pwm-dutycycle-unit:  Integer value encoding the duty cycle unit. If not
defined, <100> is assumed, meaning that
diff --git a/drivers/regulator/pwm-regulator.c 
b/drivers/regulator/pwm-regulator.c
index c24524242da2..94f1ca3b793d 100644
--- a/drivers/regulator/pwm-regulator.c
+++ b/drivers/regulator/pwm-regulator.c
@@ -48,6 +48,8 @@ struct pwm_regulator_data {
 
/* Enable GPIO */
struct gpio_desc *enb_gpio;
+
+   u32 settle_time_up_us;
 };
 
 struct pwm_voltages {
@@ -195,6 +197,7 @@ static int pwm_regulator_set_voltage(struct regulator_dev 
*rdev,
unsigned int max_uV_duty = drvdata->continuous.max_uV_dutycycle;
unsigned int duty_unit = drvdata->continuous.dutycycle_unit;
unsigned int ramp_delay = rdev->constraints->ramp_delay;
+   unsigned int delay = 0;
int min_uV = rdev->constraints->min_uV;
int max_uV = rdev->constraints->max_uV;
int diff_uV = max_uV - min_uV;
@@ -233,12 +236,17 @@ static int pwm_regulator_set_voltage(struct regulator_dev 
*rdev,
return ret;
}
 
-   if ((ramp_delay == 0) || !pwm_regulator_is_enabled(rdev))
+   if (req_min_uV > old_uV)
+   delay = drvdata->settle_time_up_us;
+
+   if (ramp_delay != 0)
+   /* Adjust ramp delay to uS and add to settle time. */
+   delay += DIV_ROUND_UP(abs(req_min_uV - old_uV), ramp_delay);
+
+   if ((delay == 0) || !pwm_regulator_is_enabled(rdev))
return 0;
 
-   /* Ramp delay is in uV/uS. Adjust to uS and delay */
-   ramp_delay = DIV_ROUND_UP(abs(req_min_uV - old_uV), ramp_delay);
-   usleep_range(ramp_delay, ramp_delay + DIV_ROUND_UP(ramp_delay, 10));
+   usleep_range(delay, delay + DIV_ROUND_UP(delay, 10));
 
return 0;
 }
@@ -368,6 +376,9 @@ static int pwm_regulator_probe(struct platform_device *pdev)
if (!init_data)
return -ENOMEM;
 
+   of_property_read_u32(np, "settle-time-up-us",
+   >settle_time_up_us);
+
config.of_node = np;
config.dev = >dev;
config.driver_data = drvdata;
-- 
2.8.0.rc3.226.g39d4020

[PATCH v3 2/2] regulator: pwm: Prevent falling too fast

[Douglas Anderson]

On some boards it's possible that transitioning the PWM regulator
downwards too fast will trigger the over voltage protection (OVP) on the
regulator.  This is because until the voltage actually falls there is a
time when the requested voltage is much lower than the actual voltage.

We'll fix this OVP problem by allowing users to specify the maximum
voltage that we can safely fall.  Apparently this maximum safe voltage
should be specified as a percentage of the current voltage.  The PWM
regulator will then break things into separate steps with a delay in
between.

In order to figure out what the delay should be we need to figure out
how slowly the voltage rail might fall in the worst (slowest) case.
We'll assume this worst case is present and delay so we know for sure
that we've finished each step.

In this patch we actually block returning from the set_voltage() call
until we've finished delaying.  A future patch atop this one might
choose to return more immediately and let the voltages fall in the
background.  That would possibly to allow us to cancel a slow downward
decay if there was a request to go back up.

Signed-off-by: Douglas Anderson 
---
Changes in v3:
- Prevent falling too fast new for v3.

 .../bindings/regulator/pwm-regulator.txt   |  7 ++
 drivers/regulator/pwm-regulator.c  | 79 +++---
 2 files changed, 78 insertions(+), 8 deletions(-)

diff --git a/Documentation/devicetree/bindings/regulator/pwm-regulator.txt 
b/Documentation/devicetree/bindings/regulator/pwm-regulator.txt
index 9dc15d18e787..99fa09c42aac 100644
--- a/Documentation/devicetree/bindings/regulator/pwm-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/pwm-regulator.txt
@@ -39,6 +39,13 @@ Optional properties:
 - settle-time-up-us:   Time to settle down after a voltage increase
(unit: us). For regulators with a ramp delay
the two values are added.
+- safe-fall-percent:   If specified, it's not safe to transition the regulator
+   down faster than this amount and bigger jumps need to
+   be broken into more than one step.
+- slowest-decay-rate:  Describes how slowly the regulator voltage will
+   decay down in the worst case (lightest expected load).
+   Specified in uV / us (like main regulator ramp rate).
+   This is required when safe-fall-percent is specified.
 
 Optional properties for Continuous mode:
 - pwm-dutycycle-unit:  Integer value encoding the duty cycle unit. If not
diff --git a/drivers/regulator/pwm-regulator.c 
b/drivers/regulator/pwm-regulator.c
index 94f1ca3b793d..47675632c0c6 100644
--- a/drivers/regulator/pwm-regulator.c
+++ b/drivers/regulator/pwm-regulator.c
@@ -50,6 +50,8 @@ struct pwm_regulator_data {
struct gpio_desc *enb_gpio;
 
u32 settle_time_up_us;
+   u32 slowest_decay_rate;
+   u32 safe_fall_percent;
 };
 
 struct pwm_voltages {
@@ -188,9 +190,8 @@ static int pwm_regulator_get_voltage(struct regulator_dev 
*rdev)
return voltage + min_uV;
 }
 
-static int pwm_regulator_set_voltage(struct regulator_dev *rdev,
-int req_min_uV, int req_max_uV,
-unsigned int *selector)
+static int _pwm_regulator_set_voltage(struct regulator_dev *rdev,
+ int old_uV, int req_uV)
 {
struct pwm_regulator_data *drvdata = rdev_get_drvdata(rdev);
unsigned int min_uV_duty = drvdata->continuous.min_uV_dutycycle;
@@ -202,7 +203,6 @@ static int pwm_regulator_set_voltage(struct regulator_dev 
*rdev,
int max_uV = rdev->constraints->max_uV;
int diff_uV = max_uV - min_uV;
struct pwm_state pstate;
-   int old_uV = pwm_regulator_get_voltage(rdev);
unsigned int diff_duty;
unsigned int dutycycle;
int ret;
@@ -219,8 +219,7 @@ static int pwm_regulator_set_voltage(struct regulator_dev 
*rdev,
else
diff_duty = max_uV_duty - min_uV_duty;
 
-   dutycycle = DIV_ROUND_CLOSEST_ULL((u64)(req_min_uV - min_uV) *
- diff_duty,
+   dutycycle = DIV_ROUND_CLOSEST_ULL((u64)(req_uV - min_uV) * diff_duty,
  diff_uV);
 
if (max_uV_duty < min_uV_duty)
@@ -236,12 +235,12 @@ static int pwm_regulator_set_voltage(struct regulator_dev 
*rdev,
return ret;
}
 
-   if (req_min_uV > old_uV)
+   if (req_uV > old_uV)
delay = drvdata->settle_time_up_us;
 
if (ramp_delay != 0)
/* Adjust ramp delay to uS and add to settle time. */
-   delay += DIV_ROUND_UP(abs(req_min_uV - old_uV), ramp_delay);
+   delay += DIV_ROUND_UP(abs(req_uV - old_uV), ramp_delay);
 
if ((delay == 0) || !pwm_regulator_is_enabled(rdev))
return 0;
@@ -251,6 +250,47 

Re: [PATCH net] rps: flow_dissector: Fix uninitialized flow_keys used in __skb_get_hash possibly

[Gao Feng]

On Wed, Aug 31, 2016 at 12:14 PM, Eric Dumazet  wrote:
> On Wed, 2016-08-31 at 10:56 +0800, f...@ikuai8.com wrote:
>> From: Gao Feng 
>>
>> The original codes depend on that the function parameters are evaluated from
>> left to right. But the parameter's evaluation order is not defined in C
>> standard actually.
>>
>> When flow_keys_have_l4() is invoked before ___skb_get_hash(skb, ,
>> hashrnd) with some compilers or environment, the keys passed to
>> flow_keys_have_l4 is not initialized.
>>
>> Signed-off-by: Gao Feng 
>> ---
>
> Good catch, please add
>
> Fixes: 6db61d79c1e1 ("flow_dissector: Ignore flow dissector return value from 
> ___skb_get_hash")
> Acked-by: Eric Dumazet 
>
>

Add it into the description and resend the patch again?

Best Regards
Feng

Re: [PATCH net] rps: flow_dissector: Fix uninitialized flow_keys used in __skb_get_hash possibly

[Gao Feng]

On Wed, Aug 31, 2016 at 12:14 PM, Eric Dumazet  wrote:
> On Wed, 2016-08-31 at 10:56 +0800, f...@ikuai8.com wrote:
>> From: Gao Feng 
>>
>> The original codes depend on that the function parameters are evaluated from
>> left to right. But the parameter's evaluation order is not defined in C
>> standard actually.
>>
>> When flow_keys_have_l4() is invoked before ___skb_get_hash(skb, ,
>> hashrnd) with some compilers or environment, the keys passed to
>> flow_keys_have_l4 is not initialized.
>>
>> Signed-off-by: Gao Feng 
>> ---
>
> Good catch, please add
>
> Fixes: 6db61d79c1e1 ("flow_dissector: Ignore flow dissector return value from 
> ___skb_get_hash")
> Acked-by: Eric Dumazet 
>
>

Add it into the description and resend the patch again?

Best Regards
Feng

Re: [PATCH] kasan: avoid overflowing quarantine size on low memory systems

[amanda4ray]

On Monday, August 1, 2016 at 10:59:29 AM UTC-4, Alexander Potapenko wrote:
> If the total amount of memory assigned to quarantine is less than the
> amount of memory assigned to per-cpu quarantines, |new_quarantine_size|
> may overflow. Instead, set it to zero.
> 
> Reported-by: Dmitry Vyukov 
> Fixes: 55834c59098d ("mm: kasan: initial memory quarantine
> implementation")
> Signed-off-by: Alexander Potapenko 
> ---
>  mm/kasan/quarantine.c | 12 ++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/mm/kasan/quarantine.c b/mm/kasan/quarantine.c
> index 65793f1..416d3b0 100644
> --- a/mm/kasan/quarantine.c
> +++ b/mm/kasan/quarantine.c
> @@ -196,7 +196,7 @@ void quarantine_put(struct kasan_free_meta *info, struct 
> kmem_cache *cache)
>  
>  void quarantine_reduce(void)
>  {
> - size_t new_quarantine_size;
> + size_t new_quarantine_size, percpu_quarantines;
>   unsigned long flags;
>   struct qlist_head to_free = QLIST_INIT;
>   size_t size_to_free = 0;
> @@ -214,7 +214,15 @@ void quarantine_reduce(void)
>*/
>   new_quarantine_size = (READ_ONCE(totalram_pages) << PAGE_SHIFT) /
>   QUARANTINE_FRACTION;
> - new_quarantine_size -= QUARANTINE_PERCPU_SIZE * num_online_cpus();
> + percpu_quarantines = QUARANTINE_PERCPU_SIZE * num_online_cpus();
> + if (new_quarantine_size < percpu_quarantines) {
> + WARN_ONCE(1,
> + "Too little memory, disabling global KASAN 
> quarantine.\n",
> + );
> + new_quarantine_size = 0;
> + } else {
> + new_quarantine_size -= percpu_quarantines;
> + }
>   WRITE_ONCE(quarantine_size, new_quarantine_size);
>  
>   last = global_quarantine.head;
> -- 
> 2.8.0.rc3.226.g39d4020



On Monday, August 1, 2016 at 10:59:29 AM UTC-4, Alexander Potapenko wrote:
> If the total amount of memory assigned to quarantine is less than the
> amount of memory assigned to per-cpu quarantines, |new_quarantine_size|
> may overflow. Instead, set it to zero.
> 
> Reported-by: Dmitry Vyukov 
> Fixes: 55834c59098d ("mm: kasan: initial memory quarantine
> implementation")
> Signed-off-by: Alexander Potapenko 
> ---
>  mm/kasan/quarantine.c | 12 ++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/mm/kasan/quarantine.c b/mm/kasan/quarantine.c
> index 65793f1..416d3b0 100644
> --- a/mm/kasan/quarantine.c
> +++ b/mm/kasan/quarantine.c
> @@ -196,7 +196,7 @@ void quarantine_put(struct kasan_free_meta *info, struct 
> kmem_cache *cache)
>  
>  void quarantine_reduce(void)
>  {
> - size_t new_quarantine_size;
> + size_t new_quarantine_size, percpu_quarantines;
>   unsigned long flags;
>   struct qlist_head to_free = QLIST_INIT;
>   size_t size_to_free = 0;
> @@ -214,7 +214,15 @@ void quarantine_reduce(void)
>*/
>   new_quarantine_size = (READ_ONCE(totalram_pages) << PAGE_SHIFT) /
>   QUARANTINE_FRACTION;
> - new_quarantine_size -= QUARANTINE_PERCPU_SIZE * num_online_cpus();
> + percpu_quarantines = QUARANTINE_PERCPU_SIZE * num_online_cpus();
> + if (new_quarantine_size < percpu_quarantines) {
> + WARN_ONCE(1,
> + "Too little memory, disabling global KASAN 
> quarantine.\n",
> + );
> + new_quarantine_size = 0;
> + } else {
> + new_quarantine_size -= percpu_quarantines;
> + }
>   WRITE_ONCE(quarantine_size, new_quarantine_size);
>  
>   last = global_quarantine.head;
> -- 
> 2.8.0.rc3.226.g39d4020

Re: [PATCH] kasan: avoid overflowing quarantine size on low memory systems

[amanda4ray]

On Monday, August 1, 2016 at 10:59:29 AM UTC-4, Alexander Potapenko wrote:
> If the total amount of memory assigned to quarantine is less than the
> amount of memory assigned to per-cpu quarantines, |new_quarantine_size|
> may overflow. Instead, set it to zero.
> 
> Reported-by: Dmitry Vyukov 
> Fixes: 55834c59098d ("mm: kasan: initial memory quarantine
> implementation")
> Signed-off-by: Alexander Potapenko 
> ---
>  mm/kasan/quarantine.c | 12 ++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/mm/kasan/quarantine.c b/mm/kasan/quarantine.c
> index 65793f1..416d3b0 100644
> --- a/mm/kasan/quarantine.c
> +++ b/mm/kasan/quarantine.c
> @@ -196,7 +196,7 @@ void quarantine_put(struct kasan_free_meta *info, struct 
> kmem_cache *cache)
>  
>  void quarantine_reduce(void)
>  {
> - size_t new_quarantine_size;
> + size_t new_quarantine_size, percpu_quarantines;
>   unsigned long flags;
>   struct qlist_head to_free = QLIST_INIT;
>   size_t size_to_free = 0;
> @@ -214,7 +214,15 @@ void quarantine_reduce(void)
>*/
>   new_quarantine_size = (READ_ONCE(totalram_pages) << PAGE_SHIFT) /
>   QUARANTINE_FRACTION;
> - new_quarantine_size -= QUARANTINE_PERCPU_SIZE * num_online_cpus();
> + percpu_quarantines = QUARANTINE_PERCPU_SIZE * num_online_cpus();
> + if (new_quarantine_size < percpu_quarantines) {
> + WARN_ONCE(1,
> + "Too little memory, disabling global KASAN 
> quarantine.\n",
> + );
> + new_quarantine_size = 0;
> + } else {
> + new_quarantine_size -= percpu_quarantines;
> + }
>   WRITE_ONCE(quarantine_size, new_quarantine_size);
>  
>   last = global_quarantine.head;
> -- 
> 2.8.0.rc3.226.g39d4020



On Monday, August 1, 2016 at 10:59:29 AM UTC-4, Alexander Potapenko wrote:
> If the total amount of memory assigned to quarantine is less than the
> amount of memory assigned to per-cpu quarantines, |new_quarantine_size|
> may overflow. Instead, set it to zero.
> 
> Reported-by: Dmitry Vyukov 
> Fixes: 55834c59098d ("mm: kasan: initial memory quarantine
> implementation")
> Signed-off-by: Alexander Potapenko 
> ---
>  mm/kasan/quarantine.c | 12 ++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/mm/kasan/quarantine.c b/mm/kasan/quarantine.c
> index 65793f1..416d3b0 100644
> --- a/mm/kasan/quarantine.c
> +++ b/mm/kasan/quarantine.c
> @@ -196,7 +196,7 @@ void quarantine_put(struct kasan_free_meta *info, struct 
> kmem_cache *cache)
>  
>  void quarantine_reduce(void)
>  {
> - size_t new_quarantine_size;
> + size_t new_quarantine_size, percpu_quarantines;
>   unsigned long flags;
>   struct qlist_head to_free = QLIST_INIT;
>   size_t size_to_free = 0;
> @@ -214,7 +214,15 @@ void quarantine_reduce(void)
>*/
>   new_quarantine_size = (READ_ONCE(totalram_pages) << PAGE_SHIFT) /
>   QUARANTINE_FRACTION;
> - new_quarantine_size -= QUARANTINE_PERCPU_SIZE * num_online_cpus();
> + percpu_quarantines = QUARANTINE_PERCPU_SIZE * num_online_cpus();
> + if (new_quarantine_size < percpu_quarantines) {
> + WARN_ONCE(1,
> + "Too little memory, disabling global KASAN 
> quarantine.\n",
> + );
> + new_quarantine_size = 0;
> + } else {
> + new_quarantine_size -= percpu_quarantines;
> + }
>   WRITE_ONCE(quarantine_size, new_quarantine_size);
>  
>   last = global_quarantine.head;
> -- 
> 2.8.0.rc3.226.g39d4020

Re: [PATCH net] rps: flow_dissector: Fix uninitialized flow_keys used in __skb_get_hash possibly

[Eric Dumazet]

On Wed, 2016-08-31 at 10:56 +0800, f...@ikuai8.com wrote:
> From: Gao Feng 
> 
> The original codes depend on that the function parameters are evaluated from
> left to right. But the parameter's evaluation order is not defined in C
> standard actually.
> 
> When flow_keys_have_l4() is invoked before ___skb_get_hash(skb, ,
> hashrnd) with some compilers or environment, the keys passed to
> flow_keys_have_l4 is not initialized.
> 
> Signed-off-by: Gao Feng 
> ---

Good catch, please add 

Fixes: 6db61d79c1e1 ("flow_dissector: Ignore flow dissector return value from 
___skb_get_hash")
Acked-by: Eric Dumazet 

Re: [PATCH net] rps: flow_dissector: Fix uninitialized flow_keys used in __skb_get_hash possibly

[Eric Dumazet]

On Wed, 2016-08-31 at 10:56 +0800, f...@ikuai8.com wrote:
> From: Gao Feng 
> 
> The original codes depend on that the function parameters are evaluated from
> left to right. But the parameter's evaluation order is not defined in C
> standard actually.
> 
> When flow_keys_have_l4() is invoked before ___skb_get_hash(skb, ,
> hashrnd) with some compilers or environment, the keys passed to
> flow_keys_have_l4 is not initialized.
> 
> Signed-off-by: Gao Feng 
> ---

Good catch, please add 

Fixes: 6db61d79c1e1 ("flow_dissector: Ignore flow dissector return value from 
___skb_get_hash")
Acked-by: Eric Dumazet 

Re: [PATCH V3 3/3] dmaengine: qcom_hidma: add error reporting for tx_status

[Vinod Koul]

On Tue, Aug 30, 2016 at 01:51:02PM -0400, Sinan Kaya wrote:
> On 8/30/2016 1:37 PM, Sinan Kaya wrote:
> > On 8/30/2016 1:04 PM, Vinod Koul wrote:
> >> On Tue, Aug 23, 2016 at 12:48:11AM -0400, Sinan Kaya wrote:
> >>
> >>>   spin_lock_init(>lock);
> >>> - tasklet_init(>rst_task, hidma_ll_abort, (unsigned long)lldev);
> >>
> >> ??
> >>
> >> This is not described in changlog? If you are not using in anywhere else,
> >> then rst_task variable should be removed too..
> >>
> > 
> > Sure, I can add more description. I thought I did mention that we are no 
> > longer
> > resetting the hardware in ISR. 
> > 
> > I can certainly mention that rst_task variable is removed and can get rid 
> > of it.
> > It is no longer in use.
> > 
> 
> It looks like I mentioned this in the cover letter only not in the commit 
> message.
> I'll pull the description into the commit message too.

Sounds good to me, thanks

-- 
~Vinod

Re: [PATCH V3 3/3] dmaengine: qcom_hidma: add error reporting for tx_status

[Vinod Koul]

On Tue, Aug 30, 2016 at 01:51:02PM -0400, Sinan Kaya wrote:
> On 8/30/2016 1:37 PM, Sinan Kaya wrote:
> > On 8/30/2016 1:04 PM, Vinod Koul wrote:
> >> On Tue, Aug 23, 2016 at 12:48:11AM -0400, Sinan Kaya wrote:
> >>
> >>>   spin_lock_init(>lock);
> >>> - tasklet_init(>rst_task, hidma_ll_abort, (unsigned long)lldev);
> >>
> >> ??
> >>
> >> This is not described in changlog? If you are not using in anywhere else,
> >> then rst_task variable should be removed too..
> >>
> > 
> > Sure, I can add more description. I thought I did mention that we are no 
> > longer
> > resetting the hardware in ISR. 
> > 
> > I can certainly mention that rst_task variable is removed and can get rid 
> > of it.
> > It is no longer in use.
> > 
> 
> It looks like I mentioned this in the cover letter only not in the commit 
> message.
> I'll pull the description into the commit message too.

Sounds good to me, thanks

-- 
~Vinod

Re: [PATCH RESEND] drm: bridge/dw-hdmi: Fix colorspace and scan information registers values

[Archit Taneja]

Hi,

On 08/29/2016 03:00 PM, Jose Abreu wrote:

Colorspace and scan information values were being written in wrong
offsets. This patch corrects this and writes the values at the
offsets specified in the databook.


queued to drm-misc after cleaning up some checkpatch
errors.

Thanks,
Archit



Signed-off-by: Jose Abreu 
Acked-by: Russell King 
Cc: Carlos Palminha 
Cc: Archit Taneja 
Cc: David Airlie 
Cc: Russell King 
Cc: Daniel Vetter 
Cc: dri-de...@lists.freedesktop.org
Cc: linux-kernel@vger.kernel.org
---
  drivers/gpu/drm/bridge/dw-hdmi.c | 7 ---
  1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index 77ab473..cdf39aa 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -940,10 +940,11 @@ static void hdmi_config_AVI(struct dw_hdmi *hdmi, struct 
drm_display_mode *mode)
 */

/*
-* AVI data byte 1 differences: Colorspace in bits 4,5 rather than 5,6,
-* active aspect present in bit 6 rather than 4.
+* AVI data byte 1 differences: Colorspace in bits 0,1 rather than 5,6,
+* scan info in bits 4,5 rather than 0,1 and active aspect present in
+* bit 6 rather than 4.
 */
-   val = (frame.colorspace & 3) << 4 | (frame.scan_mode & 0x3);
+   val = (frame.scan_mode & 3) << 4 | (frame.colorspace & 3);
if (frame.active_aspect & 15)
val |= HDMI_FC_AVICONF0_ACTIVE_FMT_INFO_PRESENT;
if (frame.top_bar || frame.bottom_bar)



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

Re: [PATCH RESEND] drm: bridge/dw-hdmi: Fix colorspace and scan information registers values

[Archit Taneja]

Hi,

On 08/29/2016 03:00 PM, Jose Abreu wrote:

Colorspace and scan information values were being written in wrong
offsets. This patch corrects this and writes the values at the
offsets specified in the databook.


queued to drm-misc after cleaning up some checkpatch
errors.

Thanks,
Archit



Signed-off-by: Jose Abreu 
Acked-by: Russell King 
Cc: Carlos Palminha 
Cc: Archit Taneja 
Cc: David Airlie 
Cc: Russell King 
Cc: Daniel Vetter 
Cc: dri-de...@lists.freedesktop.org
Cc: linux-kernel@vger.kernel.org
---
  drivers/gpu/drm/bridge/dw-hdmi.c | 7 ---
  1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index 77ab473..cdf39aa 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -940,10 +940,11 @@ static void hdmi_config_AVI(struct dw_hdmi *hdmi, struct 
drm_display_mode *mode)
 */

/*
-* AVI data byte 1 differences: Colorspace in bits 4,5 rather than 5,6,
-* active aspect present in bit 6 rather than 4.
+* AVI data byte 1 differences: Colorspace in bits 0,1 rather than 5,6,
+* scan info in bits 4,5 rather than 0,1 and active aspect present in
+* bit 6 rather than 4.
 */
-   val = (frame.colorspace & 3) << 4 | (frame.scan_mode & 0x3);
+   val = (frame.scan_mode & 3) << 4 | (frame.colorspace & 3);
if (frame.active_aspect & 15)
val |= HDMI_FC_AVICONF0_ACTIVE_FMT_INFO_PRESENT;
if (frame.top_bar || frame.bottom_bar)



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

Re: [PART2 PATCH v7 12/12] svm: Implements update_pi_irte hook to setup posted interrupt

[Radim Krčmář]

2016-08-23 13:52-0500, Suravee Suthikulpanit:
> From: Suravee Suthikulpanit 
> 
> This patch implements update_pi_irte function hook to allow SVM
> communicate to IOMMU driver regarding how to set up IRTE for handling
> posted interrupt.
> 
> In case AVIC is enabled, during vcpu_load/unload, SVM needs to update
> IOMMU IRTE with appropriate host physical APIC ID. Also, when
> vcpu_blocking/unblocking, SVM needs to update the is-running bit in
> the IOMMU IRTE. Both are achieved via calling amd_iommu_update_ga().
> 
> However, if GA mode is not enabled for the pass-through device,
> IOMMU driver will simply just return when calling amd_iommu_update_ga.
> 
> Signed-off-by: Suravee Suthikulpanit 
> ---

I forgot nitpicks in the office before going on a vacation, ;)

Reviewed-by: Radim Krčmář 

Re: [PART2 PATCH v7 12/12] svm: Implements update_pi_irte hook to setup posted interrupt

[Radim Krčmář]

2016-08-23 13:52-0500, Suravee Suthikulpanit:
> From: Suravee Suthikulpanit 
> 
> This patch implements update_pi_irte function hook to allow SVM
> communicate to IOMMU driver regarding how to set up IRTE for handling
> posted interrupt.
> 
> In case AVIC is enabled, during vcpu_load/unload, SVM needs to update
> IOMMU IRTE with appropriate host physical APIC ID. Also, when
> vcpu_blocking/unblocking, SVM needs to update the is-running bit in
> the IOMMU IRTE. Both are achieved via calling amd_iommu_update_ga().
> 
> However, if GA mode is not enabled for the pass-through device,
> IOMMU driver will simply just return when calling amd_iommu_update_ga.
> 
> Signed-off-by: Suravee Suthikulpanit 
> ---

I forgot nitpicks in the office before going on a vacation, ;)

Reviewed-by: Radim Krčmář 

Re: [PATCH] printk/nmi: avoid direct printk()-s from __printk_nmi_flush()

[Sergey Senozhatsky]

On (08/30/16 13:19), Petr Mladek wrote:
[..]
> > yes, x86 has a per-cpu nmi_state to handle the case when NMI is
> > loosing its NMI context. But other arch-s, as far as I can see,
> > don't do that. Does it mean that we are safe only on x86?
> 
> My understanding is that the kernel would crash on the other
> architectures if a double iret was called. By other words,
> they would have bigger problems than the nmi_enter()/nmi_exit()
> calls. So, we should be on the safe side.
> 
> > this printk_func_saved thing is still will be needed, I think,
> > for alt_printk.
> > 
> > Example:
> > 
> > process abc
> > printk()
> > alt_printk_enter()
> > this_cpu_write(printk_func, vprintk_alt);
> > ->  NMI
> > :   printk_nmi_enter()
> > :   this_cpu_write(printk_func, vprintk_nmi);
> > :   printk_nmi_exit()
> > :   this_cpu_write(printk_func, vprintk_default);
> > return NMI
> > 
> > printk()    nested printk -> vprintk_default(), set by 
> > nmi_exit()
> > alt_printk_exit()
> > ...
> 
> I see. But then we will need to be more careful because printk_func
> and printk_func_saved will be manipulated in different contexts:
> normal, irq, nmi. A solution might be using an atomic counter
> and selecting the right vprintk_func according to the value.

yes, I thought about something like this.
... or we can use the one and only 'nmi_seq' buffer and share it between
NMI and alt_printk, adding a special prefix to every message

if (in_nmi())
sprintf("NMI:%s", message)
else
sprintf("%s", message)

so, yes, it can get hairy, but at least it will be grep-able, still
better than nothing.

> Well, I am still afraid that yet another alt_printk is not
> the way to go.

well, it might be and it might be not.

-ss

Re: [PATCH] printk/nmi: avoid direct printk()-s from __printk_nmi_flush()

[Sergey Senozhatsky]

On (08/30/16 13:19), Petr Mladek wrote:
[..]
> > yes, x86 has a per-cpu nmi_state to handle the case when NMI is
> > loosing its NMI context. But other arch-s, as far as I can see,
> > don't do that. Does it mean that we are safe only on x86?
> 
> My understanding is that the kernel would crash on the other
> architectures if a double iret was called. By other words,
> they would have bigger problems than the nmi_enter()/nmi_exit()
> calls. So, we should be on the safe side.
> 
> > this printk_func_saved thing is still will be needed, I think,
> > for alt_printk.
> > 
> > Example:
> > 
> > process abc
> > printk()
> > alt_printk_enter()
> > this_cpu_write(printk_func, vprintk_alt);
> > ->  NMI
> > :   printk_nmi_enter()
> > :   this_cpu_write(printk_func, vprintk_nmi);
> > :   printk_nmi_exit()
> > :   this_cpu_write(printk_func, vprintk_default);
> > return NMI
> > 
> > printk()    nested printk -> vprintk_default(), set by 
> > nmi_exit()
> > alt_printk_exit()
> > ...
> 
> I see. But then we will need to be more careful because printk_func
> and printk_func_saved will be manipulated in different contexts:
> normal, irq, nmi. A solution might be using an atomic counter
> and selecting the right vprintk_func according to the value.

yes, I thought about something like this.
... or we can use the one and only 'nmi_seq' buffer and share it between
NMI and alt_printk, adding a special prefix to every message

if (in_nmi())
sprintf("NMI:%s", message)
else
sprintf("%s", message)

so, yes, it can get hairy, but at least it will be grep-able, still
better than nothing.

> Well, I am still afraid that yet another alt_printk is not
> the way to go.

well, it might be and it might be not.

-ss

Re: [PATCH] cpufreq: Drop unnecessary check from cpufreq_policy_alloc()

[Viresh Kumar]

On 31-08-16, 03:11, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki 
> 
> Since cpufreq_policy_alloc() doesn't use its dev variable for
> anything useful, drop that variable from there along with the
> NULL check against it.
> 
> Signed-off-by: Rafael J. Wysocki 
> ---
>  drivers/cpufreq/cpufreq.c |4 
>  1 file changed, 4 deletions(-)
> 
> Index: linux-pm/drivers/cpufreq/cpufreq.c
> ===
> --- linux-pm.orig/drivers/cpufreq/cpufreq.c
> +++ linux-pm/drivers/cpufreq/cpufreq.c
> @@ -1073,13 +1073,9 @@ static void handle_update(struct work_st
>  
>  static struct cpufreq_policy *cpufreq_policy_alloc(unsigned int cpu)
>  {
> - struct device *dev = get_cpu_device(cpu);
>   struct cpufreq_policy *policy;
>   int ret;
>  
> - if (WARN_ON(!dev))
> - return NULL;
> -
>   policy = kzalloc(sizeof(*policy), GFP_KERNEL);
>   if (!policy)
>   return NULL;

Acked-by: Viresh Kumar 

-- 
viresh

Re: [PATCH] cpufreq: Drop unnecessary check from cpufreq_policy_alloc()

[Viresh Kumar]

On 31-08-16, 03:11, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki 
> 
> Since cpufreq_policy_alloc() doesn't use its dev variable for
> anything useful, drop that variable from there along with the
> NULL check against it.
> 
> Signed-off-by: Rafael J. Wysocki 
> ---
>  drivers/cpufreq/cpufreq.c |4 
>  1 file changed, 4 deletions(-)
> 
> Index: linux-pm/drivers/cpufreq/cpufreq.c
> ===
> --- linux-pm.orig/drivers/cpufreq/cpufreq.c
> +++ linux-pm/drivers/cpufreq/cpufreq.c
> @@ -1073,13 +1073,9 @@ static void handle_update(struct work_st
>  
>  static struct cpufreq_policy *cpufreq_policy_alloc(unsigned int cpu)
>  {
> - struct device *dev = get_cpu_device(cpu);
>   struct cpufreq_policy *policy;
>   int ret;
>  
> - if (WARN_ON(!dev))
> - return NULL;
> -
>   policy = kzalloc(sizeof(*policy), GFP_KERNEL);
>   if (!policy)
>   return NULL;

Acked-by: Viresh Kumar 

-- 
viresh

Re: [Documentation] State of CPU controller in cgroup v2

[Andy Lutomirski]

On Mon, Aug 29, 2016 at 3:20 PM, Tejun Heo  wrote:
>> > These base-system operations are special regardless of cgroup and we
>> > already have sometimes crude ways to affect their behaviors where
>> > necessary through sysctl knobs, priorities on specific kernel threads
>> > and so on.  cgroup doesn't change the situation all that much.  What
>> > gets left in the root cgroup usually are the base-system operations
>> > which are outside the scope of cgroup resource control in the first
>> > place and cgroup resource graph can treat the root as an opaque anchor
>> > point.
>>
>> This seems to explain why the controllers need to be able to handle
>> things being charged to the root cgroup (or to an unidentifiable
>> cgroup, anyway).  That isn't quite the same thing as allowing, from an
>> ABI point of view, the root cgroup to contain processes and cgroups
>> but not allowing other cgroups to do the same thing.  Consider:
>
> The points are 1. we need the root to be a special container anyway

But you don't need to let userspace see that.

> 2. allowing it to be special and contain system-wide consumptions
> doesn't make the resource graph inconsistent once all non-system-wide
> consumptions are put in non-root cgroups, and 3. this is the most
> natural way to handle the situation both from implementation and
> interface standpoints as it makes non-cgroup configuration a natural
> degenerate case of cgroup configuration.
>
>> suppose that systemd (or some competing cgroup manager) is designed to
>> run in the root cgroup namespace.  It presumably expects *itself* to
>> be in the root cgroup.  Now try to run it using cgroups v2 in a
>> non-root namespace.  I don't see how it can possibly work if it the
>> hierarchy constraints don't permit it to create sub-cgroups while it's
>> still in the root.  In fact, this seems impossible to fix even with
>> user code changes.  The manager would need to simultaneously create a
>> new child cgroup to contain itself and assign itself to that child
>> cgroup, because the intermediate state is illegal.
>
> Please re-read the constraint.  It doesn't prevent any organizational
> operations before resource control is enabled.
>
>> I really, really think that cgroup v2 should supply the same
>> *interface* inside and outside of a non-root namespace.  If this is
>
> It *does*.  That's what I tried to explain, that it's exactly
> isomorhpic once you discount the system-wide consumptions.
>

I don't think I agree.

Suppose I wrote an init program or a cgroup manager.  I can expect
that init program to be started in the root cgroup.  The program can
be lazy and write +io to /cgroup/cgroup.subtree_control and then
create some new cgroup /cgroup/a and it will work (I just tried it).

Now I run that program in a namespace.  It will not work because it'll
get -EBUSY when it tries to write to cgroup.subtree_control.  (I just
tried this, too, only using cd instead of a namespace.)  So it's *not*
isomorphic.

It *also* won't work (I think) if subtree control is enabled on the
root, but I don't think this is a problem in practice because subtree
control won't be enabled on the namespace root by a sensible cgroup
manager.

--Andy

Re: [Documentation] State of CPU controller in cgroup v2

[Andy Lutomirski]

On Mon, Aug 29, 2016 at 3:20 PM, Tejun Heo  wrote:
>> > These base-system operations are special regardless of cgroup and we
>> > already have sometimes crude ways to affect their behaviors where
>> > necessary through sysctl knobs, priorities on specific kernel threads
>> > and so on.  cgroup doesn't change the situation all that much.  What
>> > gets left in the root cgroup usually are the base-system operations
>> > which are outside the scope of cgroup resource control in the first
>> > place and cgroup resource graph can treat the root as an opaque anchor
>> > point.
>>
>> This seems to explain why the controllers need to be able to handle
>> things being charged to the root cgroup (or to an unidentifiable
>> cgroup, anyway).  That isn't quite the same thing as allowing, from an
>> ABI point of view, the root cgroup to contain processes and cgroups
>> but not allowing other cgroups to do the same thing.  Consider:
>
> The points are 1. we need the root to be a special container anyway

But you don't need to let userspace see that.

> 2. allowing it to be special and contain system-wide consumptions
> doesn't make the resource graph inconsistent once all non-system-wide
> consumptions are put in non-root cgroups, and 3. this is the most
> natural way to handle the situation both from implementation and
> interface standpoints as it makes non-cgroup configuration a natural
> degenerate case of cgroup configuration.
>
>> suppose that systemd (or some competing cgroup manager) is designed to
>> run in the root cgroup namespace.  It presumably expects *itself* to
>> be in the root cgroup.  Now try to run it using cgroups v2 in a
>> non-root namespace.  I don't see how it can possibly work if it the
>> hierarchy constraints don't permit it to create sub-cgroups while it's
>> still in the root.  In fact, this seems impossible to fix even with
>> user code changes.  The manager would need to simultaneously create a
>> new child cgroup to contain itself and assign itself to that child
>> cgroup, because the intermediate state is illegal.
>
> Please re-read the constraint.  It doesn't prevent any organizational
> operations before resource control is enabled.
>
>> I really, really think that cgroup v2 should supply the same
>> *interface* inside and outside of a non-root namespace.  If this is
>
> It *does*.  That's what I tried to explain, that it's exactly
> isomorhpic once you discount the system-wide consumptions.
>

I don't think I agree.

Suppose I wrote an init program or a cgroup manager.  I can expect
that init program to be started in the root cgroup.  The program can
be lazy and write +io to /cgroup/cgroup.subtree_control and then
create some new cgroup /cgroup/a and it will work (I just tried it).

Now I run that program in a namespace.  It will not work because it'll
get -EBUSY when it tries to write to cgroup.subtree_control.  (I just
tried this, too, only using cd instead of a namespace.)  So it's *not*
isomorphic.

It *also* won't work (I think) if subtree control is enabled on the
root, but I don't think this is a problem in practice because subtree
control won't be enabled on the namespace root by a sensible cgroup
manager.

--Andy

Re: [RFC][PATCH] Fix a race between rwsem and the scheduler

[Balbir Singh]

On 30/08/16 22:19, Peter Zijlstra wrote:
> On Tue, Aug 30, 2016 at 06:49:37PM +1000, Balbir Singh wrote:
>>
>>
>> The origin of the issue I've seen seems to be related to
>> rwsem spin lock stealing. Basically I see the system deadlock'd in the
>> following state
> 
> As Nick says (good to see you're back Nick!), this is unrelated to
> rwsems.
> 
> This is true for pretty much every blocking wait loop out there, they
> all do:
> 
>   for (;;) {
>   current->state = UNINTERRUPTIBLE;
>   smp_mb();
>   if (cond)
>   break;
>   schedule();
>   }
>   current->state = RUNNING;
> 
> Which, if the wakeup is spurious, is just the pattern you need.

Yes True! My bad Alexey had seen the same basic pattern, I should have been 
clearer
in my commit log. Should I resend the patch?

> 
>> +++ b/kernel/sched/core.c
>> @@ -2016,6 +2016,17 @@ try_to_wake_up(struct task_struct *p, unsigned int 
>> state, int wake_flags)
>>  success = 1; /* we're going to change ->state */
>>  cpu = task_cpu(p);
>>  
>> +/*
>> + * Ensure we see on_rq and p_state consistently
>> + *
>> + * For example in __rwsem_down_write_failed(), we have
>> + *[S] ->on_rq = 1   [L] ->state
>> + *MB RMB
> 
> There isn't an MB there. The best I can do is UNLOCK+LOCK, which, thanks
> to PPC, is _not_ MB. It is however sufficient for this case.
> 

The MB comes from the __switch_to() in schedule(). Ben mentioned it in a 
different thread.

>> + *[S] ->state = TASK_UNINTERRUPTIBLE[L] ->on_rq
>> + * In the absence of the RMB p->on_rq can be observed to be 0
>> + * and we end up spinning indefinitely in while (p->on_cpu)
>> + */
> 
> 
>   /*
>* Ensure we load p->on_rq _after_ p->state, otherwise it would
>* be possible to, falsely, observe p->on_rq == 0 and get stuck
>* in smp_cond_load_acquire() below.
>*
>* sched_ttwu_pending() try_to_wake_up()
>*   [S] p->on_rq = 1;  [L] P->state
>*   UNLOCK rq->lock
>*
>* schedule()   RMB
>*   LOCK rq->lock
>*   UNLOCK rq->lock
>*
>* [task p]
>*   [S] p->state = UNINTERRUPTIBLE [L] p->on_rq
>*
>* Pairs with the UNLOCK+LOCK on rq->lock from the
>* last wakeup of our task and the schedule that got our task
>* current.
>*/
> 
>> +smp_rmb();
>>  if (p->on_rq && ttwu_remote(p, wake_flags))
>>  goto stat;
>>  
> 
> 
> Now, this has been present for a fair while, I suspect ever since we
> reworked the wakeup path to not use rq->lock twice. Curious you only now
> hit it.
> 

Yes, I just hit it a a week or two back and I needed to collect data to
explain why p->on_rq got to 0. Hitting it requires extreme stress -- for me
I needed a system with large threads and less memory running stress-ng.
Reproducing the problem takes an unpredictable amount of time.

Balbir Singh.

Re: [RFC][PATCH] Fix a race between rwsem and the scheduler

[Balbir Singh]

On 30/08/16 22:19, Peter Zijlstra wrote:
> On Tue, Aug 30, 2016 at 06:49:37PM +1000, Balbir Singh wrote:
>>
>>
>> The origin of the issue I've seen seems to be related to
>> rwsem spin lock stealing. Basically I see the system deadlock'd in the
>> following state
> 
> As Nick says (good to see you're back Nick!), this is unrelated to
> rwsems.
> 
> This is true for pretty much every blocking wait loop out there, they
> all do:
> 
>   for (;;) {
>   current->state = UNINTERRUPTIBLE;
>   smp_mb();
>   if (cond)
>   break;
>   schedule();
>   }
>   current->state = RUNNING;
> 
> Which, if the wakeup is spurious, is just the pattern you need.

Yes True! My bad Alexey had seen the same basic pattern, I should have been 
clearer
in my commit log. Should I resend the patch?

> 
>> +++ b/kernel/sched/core.c
>> @@ -2016,6 +2016,17 @@ try_to_wake_up(struct task_struct *p, unsigned int 
>> state, int wake_flags)
>>  success = 1; /* we're going to change ->state */
>>  cpu = task_cpu(p);
>>  
>> +/*
>> + * Ensure we see on_rq and p_state consistently
>> + *
>> + * For example in __rwsem_down_write_failed(), we have
>> + *[S] ->on_rq = 1   [L] ->state
>> + *MB RMB
> 
> There isn't an MB there. The best I can do is UNLOCK+LOCK, which, thanks
> to PPC, is _not_ MB. It is however sufficient for this case.
> 

The MB comes from the __switch_to() in schedule(). Ben mentioned it in a 
different thread.

>> + *[S] ->state = TASK_UNINTERRUPTIBLE[L] ->on_rq
>> + * In the absence of the RMB p->on_rq can be observed to be 0
>> + * and we end up spinning indefinitely in while (p->on_cpu)
>> + */
> 
> 
>   /*
>* Ensure we load p->on_rq _after_ p->state, otherwise it would
>* be possible to, falsely, observe p->on_rq == 0 and get stuck
>* in smp_cond_load_acquire() below.
>*
>* sched_ttwu_pending() try_to_wake_up()
>*   [S] p->on_rq = 1;  [L] P->state
>*   UNLOCK rq->lock
>*
>* schedule()   RMB
>*   LOCK rq->lock
>*   UNLOCK rq->lock
>*
>* [task p]
>*   [S] p->state = UNINTERRUPTIBLE [L] p->on_rq
>*
>* Pairs with the UNLOCK+LOCK on rq->lock from the
>* last wakeup of our task and the schedule that got our task
>* current.
>*/
> 
>> +smp_rmb();
>>  if (p->on_rq && ttwu_remote(p, wake_flags))
>>  goto stat;
>>  
> 
> 
> Now, this has been present for a fair while, I suspect ever since we
> reworked the wakeup path to not use rq->lock twice. Curious you only now
> hit it.
> 

Yes, I just hit it a a week or two back and I needed to collect data to
explain why p->on_rq got to 0. Hitting it requires extreme stress -- for me
I needed a system with large threads and less memory running stress-ng.
Reproducing the problem takes an unpredictable amount of time.

Balbir Singh.

Re: [RFC][PATCH] Fix a race between rwsem and the scheduler

[Balbir Singh]

On 30/08/16 22:58, Oleg Nesterov wrote:
> On 08/30, Balbir Singh wrote:
>>
>> The origin of the issue I've seen seems to be related to
>> rwsem spin lock stealing. Basically I see the system deadlock'd in the
>> following state
>>
>> I have a system with multiple threads and
>>
>> Most of the threads are stuck doing
>>
>> [67272.593915] --- interrupt: e81 at _raw_spin_lock_irqsave+0xa4/0x130
>> [67272.593915] LR = _raw_spin_lock_irqsave+0x9c/0x130
>> [67272.700996] [c00012857ae0] [c012453c] rwsem_wake+0xcc/0x110
>> [67272.749283] [c00012857b20] [c01215d8] up_write+0x78/0x90
>> [67272.788965] [c00012857b50] [c028153c] 
>> unlink_anon_vmas+0x15c/0x2c0
>> [67272.798782] [c00012857bc0] [c026f5c0] free_pgtables+0xf0/0x1c0
>> [67272.842528] [c00012857c10] [c027c9a0] exit_mmap+0x100/0x1a0
>> [67272.872947] [c00012857cd0] [c00b4a98] mmput+0xa8/0x1b0
>> [67272.898432] [c00012857d00] [c00bc50c] do_exit+0x33c/0xc30
>> [67272.944721] [c00012857dc0] [c00bcee4] do_group_exit+0x64/0x100
>> [67272.969014] [c00012857e00] [c00bcfac] SyS_exit_group+0x2c/0x30
>> [67272.978971] [c00012857e30] [c0009204] system_call+0x38/0xb4
>> [67272.999016] Instruction dump:
>>
>> They are spinning on the sem->wait_lock, the holder of sem->wait_lock has
>> irq's disabled and is doing
>>
>> [c0037930fb30] c00f724c try_to_wake_up+0x6c/0x570
>> [c0037930fbb0] c0124328 __rwsem_do_wake+0x1f8/0x260
>> [c0037930fc00] c01244b4 rwsem_wake+0x84/0x110
>> [c0037930fc40] c0121598 up_write+0x78/0x90
>> [c0037930fc70] c0281a54 anon_vma_fork+0x184/0x1d0
>> [c0037930fcc0] c00b68e0 copy_process.isra.5+0x14c0/0x1870
>> [c0037930fda0] c00b6e68 _do_fork+0xa8/0x4b0
>> [c0037930fe30] c0009460 ppc_clone+0x8/0xc
>>
>> The offset of try_to_wake_up is actually misleading, it is actually stuck
>> doing the following in try_to_wake_up
>>
>> while (p->on_cpu)
>>  cpu_relax();
>>
>> Analysis
>>
>> The issue is triggered, due to the following race
>>
>> CPU1 CPU2
>>
>> while () {
>>   if (cond)
>> break;
>>   do {
>> schedule();
>> set_current_state(TASK_UN..)
>>   } while (!cond);
>>  rwsem_wake()
>>spin_lock_irqsave(wait_lock)
>>   raw_spin_lock_irqsave(wait_lock) wake_up_process()
>> }  try_to_wake_up()
>> set_current_state(TASK_RUNNING);   ..
>> list_del();
>>
>> CPU2 wakes up CPU1, but before it can get the wait_lock and set
>> current state to TASK_RUNNING the following occurs
>>
>> CPU3
>> (stole the rwsem before waiter can be woken up from queue)
>> up_write()
>> rwsem_wake()
>> raw_spin_lock_irqsave(wait_lock)
>> if (!list_empty)
>>   wake_up_process()
>>   try_to_wake_up()
>>   raw_spin_lock_irqsave(p->pi_lock)
>>   ..
>>   if (p->on_rq && ttwu_wakeup())
>>   ..
>>   while (p->on_cpu)
>> cpu_relax()
>>   ..
>>
>> CPU3 tries to wake up the task on CPU1 again since it finds
>> it on the wait_queue, CPU1 is spinning on wait_lock, but immediately
>> after CPU2, CPU3 got it.
>>
>> CPU3 checks the state of p on CPU1, it is TASK_UNINTERRUPTIBLE and
>> the task is spinning on the wait_lock. Interestingly since p->on_rq
>> is checked under pi_lock, I've noticed that try_to_wake_up() finds
>> p->on_rq to be 0. This was the most confusing bit of the analysis,
>> but p->on_rq is changed under runqueue lock, rq_lock, the p->on_rq
>> check is not reliable without this fix IMHO. The race is visible
>> (based on the analysis) only when ttwu_queue() does a remote wakeup
>> via ttwu_queue_remote. In which case the p->on_rq change is not
>> done uder the pi_lock.
>>
>> The result is that after a while the entire system locks up on
>> the raw_spin_irqlock_save(wait_lock) and the holder spins infintely
>>
>> Reproduction of the issue
>>
>> The issue can be reproduced after a long run on my system with 80
>> threads and having to tweak available memory to very low and running
>> memory stress-ng mmapfork test. It usually takes a long time to
>> reproduce. I am trying to work on a test case that can reproduce
>> the issue faster, but thats work in progress. I am still testing the
>> changes on my still in a loop and the tests seem OK thus far.
>>
>> Big thanks to Benjamin and Nick for helping debug this as well.
>> Ben helped catch the missing barrier, Nick caught every missing
>> bit in my theory
>>
>> Cc: Peter Zijlstra 
>> Cc: Nicholas Piggin 
>> Cc: Benjamin Herrenschmidt 
>>
>> Signed-off-by: Balbir Singh 
>> ---
>>  kernel/sched/core.c | 11 +++
>>  1 file changed, 11 insertions(+)
>>
>> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
>> index 2a906f2..582c684 100644
>> --- 

Re: [PATCH net-next 4/6] perf, bpf: add perf events core support for BPF_PROG_TYPE_PERF_EVENT programs

[Alexei Starovoitov]

On Mon, Aug 29, 2016 at 02:17:18PM +0200, Peter Zijlstra wrote:
> On Fri, Aug 26, 2016 at 07:31:22PM -0700, Alexei Starovoitov wrote:
> > +static int perf_event_set_bpf_handler(struct perf_event *event, u32 
> > prog_fd)
> > +{
> > +   struct bpf_prog *prog;
> > +
> > +   if (event->overflow_handler_context)
> > +   /* hw breakpoint or kernel counter */
> > +   return -EINVAL;
> > +
> > +   if (event->prog)
> > +   return -EEXIST;
> > +
> > +   prog = bpf_prog_get_type(prog_fd, BPF_PROG_TYPE_PERF_EVENT);
> > +   if (IS_ERR(prog))
> > +   return PTR_ERR(prog);
> > +
> > +   event->prog = prog;
> > +   event->orig_overflow_handler = READ_ONCE(event->overflow_handler);
> > +   WRITE_ONCE(event->overflow_handler, bpf_overflow_handler);
> > +   return 0;
> > +}
> > +
> > +static void perf_event_free_bpf_handler(struct perf_event *event)
> > +{
> > +   struct bpf_prog *prog = event->prog;
> > +
> > +   if (!prog)
> > +   return;
> 
> Does it make sense to do something like:
> 
>   WARN_ON_ONCE(event->overflow_handler != bpf_overflow_handler);

Yes that's an implicit assumption here, but checking for that
would be overkill. event->overflow_handler and event->prog are set
back to back in two places and reset here once together.
Such warn_on will only make people reading this code in the future
think that this bit is too complex to analyze by hand.

> > +
> > +   WRITE_ONCE(event->overflow_handler, event->orig_overflow_handler);
> > +   event->prog = NULL;
> > +   bpf_prog_put(prog);
> > +}
> 
> 
> >  static int perf_event_set_bpf_prog(struct perf_event *event, u32 prog_fd)
> >  {
> > bool is_kprobe, is_tracepoint;
> > struct bpf_prog *prog;
> >  
> > +   if (event->attr.type == PERF_TYPE_HARDWARE ||
> > +   event->attr.type == PERF_TYPE_SOFTWARE)
> > +   return perf_event_set_bpf_handler(event, prog_fd);
> > +
> > if (event->attr.type != PERF_TYPE_TRACEPOINT)
> > return -EINVAL;
> >  
> > @@ -7647,6 +7711,8 @@ static void perf_event_free_bpf_prog(struct 
> > perf_event *event)
> >  {
> > struct bpf_prog *prog;
> >  
> > +   perf_event_free_bpf_handler(event);
> > +
> > if (!event->tp_event)
> > return;
> >  
> 
> Does it at all make sense to merge the tp_event->prog thing into this
> new event->prog?

'struct trace_event_call *tp_event' is global while tp_event->perf_events
are per cpu, so I don't see how we can do that without breaking user space
logic. Right now users do single perf_event_open of kprobe and attach prog
that is executed on all cpus where kprobe is firing. Additional per-cpu
filtering is done from within bpf prog.

> >  #ifdef CONFIG_HAVE_HW_BREAKPOINT
> > @@ -8957,6 +9029,14 @@ perf_event_alloc(struct perf_event_attr *attr, int 
> > cpu,
> > if (!overflow_handler && parent_event) {
> > overflow_handler = parent_event->overflow_handler;
> > context = parent_event->overflow_handler_context;
> > +   if (overflow_handler == bpf_overflow_handler) {
> > +   event->prog = bpf_prog_inc(parent_event->prog);
> > +   event->orig_overflow_handler = 
> > parent_event->orig_overflow_handler;
> > +   if (IS_ERR(event->prog)) {
> > +   event->prog = NULL;
> > +   overflow_handler = NULL;
> > +   }
> > +   }
> > }
> 
> Should we not fail the entire perf_event_alloc() call in that IS_ERR()
> case?

Yes. Good point. Will do.

Re: [RFC][PATCH] Fix a race between rwsem and the scheduler

[Balbir Singh]

On 30/08/16 22:58, Oleg Nesterov wrote:
> On 08/30, Balbir Singh wrote:
>>
>> The origin of the issue I've seen seems to be related to
>> rwsem spin lock stealing. Basically I see the system deadlock'd in the
>> following state
>>
>> I have a system with multiple threads and
>>
>> Most of the threads are stuck doing
>>
>> [67272.593915] --- interrupt: e81 at _raw_spin_lock_irqsave+0xa4/0x130
>> [67272.593915] LR = _raw_spin_lock_irqsave+0x9c/0x130
>> [67272.700996] [c00012857ae0] [c012453c] rwsem_wake+0xcc/0x110
>> [67272.749283] [c00012857b20] [c01215d8] up_write+0x78/0x90
>> [67272.788965] [c00012857b50] [c028153c] 
>> unlink_anon_vmas+0x15c/0x2c0
>> [67272.798782] [c00012857bc0] [c026f5c0] free_pgtables+0xf0/0x1c0
>> [67272.842528] [c00012857c10] [c027c9a0] exit_mmap+0x100/0x1a0
>> [67272.872947] [c00012857cd0] [c00b4a98] mmput+0xa8/0x1b0
>> [67272.898432] [c00012857d00] [c00bc50c] do_exit+0x33c/0xc30
>> [67272.944721] [c00012857dc0] [c00bcee4] do_group_exit+0x64/0x100
>> [67272.969014] [c00012857e00] [c00bcfac] SyS_exit_group+0x2c/0x30
>> [67272.978971] [c00012857e30] [c0009204] system_call+0x38/0xb4
>> [67272.999016] Instruction dump:
>>
>> They are spinning on the sem->wait_lock, the holder of sem->wait_lock has
>> irq's disabled and is doing
>>
>> [c0037930fb30] c00f724c try_to_wake_up+0x6c/0x570
>> [c0037930fbb0] c0124328 __rwsem_do_wake+0x1f8/0x260
>> [c0037930fc00] c01244b4 rwsem_wake+0x84/0x110
>> [c0037930fc40] c0121598 up_write+0x78/0x90
>> [c0037930fc70] c0281a54 anon_vma_fork+0x184/0x1d0
>> [c0037930fcc0] c00b68e0 copy_process.isra.5+0x14c0/0x1870
>> [c0037930fda0] c00b6e68 _do_fork+0xa8/0x4b0
>> [c0037930fe30] c0009460 ppc_clone+0x8/0xc
>>
>> The offset of try_to_wake_up is actually misleading, it is actually stuck
>> doing the following in try_to_wake_up
>>
>> while (p->on_cpu)
>>  cpu_relax();
>>
>> Analysis
>>
>> The issue is triggered, due to the following race
>>
>> CPU1 CPU2
>>
>> while () {
>>   if (cond)
>> break;
>>   do {
>> schedule();
>> set_current_state(TASK_UN..)
>>   } while (!cond);
>>  rwsem_wake()
>>spin_lock_irqsave(wait_lock)
>>   raw_spin_lock_irqsave(wait_lock) wake_up_process()
>> }  try_to_wake_up()
>> set_current_state(TASK_RUNNING);   ..
>> list_del();
>>
>> CPU2 wakes up CPU1, but before it can get the wait_lock and set
>> current state to TASK_RUNNING the following occurs
>>
>> CPU3
>> (stole the rwsem before waiter can be woken up from queue)
>> up_write()
>> rwsem_wake()
>> raw_spin_lock_irqsave(wait_lock)
>> if (!list_empty)
>>   wake_up_process()
>>   try_to_wake_up()
>>   raw_spin_lock_irqsave(p->pi_lock)
>>   ..
>>   if (p->on_rq && ttwu_wakeup())
>>   ..
>>   while (p->on_cpu)
>> cpu_relax()
>>   ..
>>
>> CPU3 tries to wake up the task on CPU1 again since it finds
>> it on the wait_queue, CPU1 is spinning on wait_lock, but immediately
>> after CPU2, CPU3 got it.
>>
>> CPU3 checks the state of p on CPU1, it is TASK_UNINTERRUPTIBLE and
>> the task is spinning on the wait_lock. Interestingly since p->on_rq
>> is checked under pi_lock, I've noticed that try_to_wake_up() finds
>> p->on_rq to be 0. This was the most confusing bit of the analysis,
>> but p->on_rq is changed under runqueue lock, rq_lock, the p->on_rq
>> check is not reliable without this fix IMHO. The race is visible
>> (based on the analysis) only when ttwu_queue() does a remote wakeup
>> via ttwu_queue_remote. In which case the p->on_rq change is not
>> done uder the pi_lock.
>>
>> The result is that after a while the entire system locks up on
>> the raw_spin_irqlock_save(wait_lock) and the holder spins infintely
>>
>> Reproduction of the issue
>>
>> The issue can be reproduced after a long run on my system with 80
>> threads and having to tweak available memory to very low and running
>> memory stress-ng mmapfork test. It usually takes a long time to
>> reproduce. I am trying to work on a test case that can reproduce
>> the issue faster, but thats work in progress. I am still testing the
>> changes on my still in a loop and the tests seem OK thus far.
>>
>> Big thanks to Benjamin and Nick for helping debug this as well.
>> Ben helped catch the missing barrier, Nick caught every missing
>> bit in my theory
>>
>> Cc: Peter Zijlstra 
>> Cc: Nicholas Piggin 
>> Cc: Benjamin Herrenschmidt 
>>
>> Signed-off-by: Balbir Singh 
>> ---
>>  kernel/sched/core.c | 11 +++
>>  1 file changed, 11 insertions(+)
>>
>> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
>> index 2a906f2..582c684 100644
>> --- a/kernel/sched/core.c
>> +++ b/kernel/sched/core.c
>> @@ -2016,6 +2016,17 @@ try_to_wake_up(struct 

Re: [PATCH net-next 4/6] perf, bpf: add perf events core support for BPF_PROG_TYPE_PERF_EVENT programs

[Alexei Starovoitov]

On Mon, Aug 29, 2016 at 02:17:18PM +0200, Peter Zijlstra wrote:
> On Fri, Aug 26, 2016 at 07:31:22PM -0700, Alexei Starovoitov wrote:
> > +static int perf_event_set_bpf_handler(struct perf_event *event, u32 
> > prog_fd)
> > +{
> > +   struct bpf_prog *prog;
> > +
> > +   if (event->overflow_handler_context)
> > +   /* hw breakpoint or kernel counter */
> > +   return -EINVAL;
> > +
> > +   if (event->prog)
> > +   return -EEXIST;
> > +
> > +   prog = bpf_prog_get_type(prog_fd, BPF_PROG_TYPE_PERF_EVENT);
> > +   if (IS_ERR(prog))
> > +   return PTR_ERR(prog);
> > +
> > +   event->prog = prog;
> > +   event->orig_overflow_handler = READ_ONCE(event->overflow_handler);
> > +   WRITE_ONCE(event->overflow_handler, bpf_overflow_handler);
> > +   return 0;
> > +}
> > +
> > +static void perf_event_free_bpf_handler(struct perf_event *event)
> > +{
> > +   struct bpf_prog *prog = event->prog;
> > +
> > +   if (!prog)
> > +   return;
> 
> Does it make sense to do something like:
> 
>   WARN_ON_ONCE(event->overflow_handler != bpf_overflow_handler);

Yes that's an implicit assumption here, but checking for that
would be overkill. event->overflow_handler and event->prog are set
back to back in two places and reset here once together.
Such warn_on will only make people reading this code in the future
think that this bit is too complex to analyze by hand.

> > +
> > +   WRITE_ONCE(event->overflow_handler, event->orig_overflow_handler);
> > +   event->prog = NULL;
> > +   bpf_prog_put(prog);
> > +}
> 
> 
> >  static int perf_event_set_bpf_prog(struct perf_event *event, u32 prog_fd)
> >  {
> > bool is_kprobe, is_tracepoint;
> > struct bpf_prog *prog;
> >  
> > +   if (event->attr.type == PERF_TYPE_HARDWARE ||
> > +   event->attr.type == PERF_TYPE_SOFTWARE)
> > +   return perf_event_set_bpf_handler(event, prog_fd);
> > +
> > if (event->attr.type != PERF_TYPE_TRACEPOINT)
> > return -EINVAL;
> >  
> > @@ -7647,6 +7711,8 @@ static void perf_event_free_bpf_prog(struct 
> > perf_event *event)
> >  {
> > struct bpf_prog *prog;
> >  
> > +   perf_event_free_bpf_handler(event);
> > +
> > if (!event->tp_event)
> > return;
> >  
> 
> Does it at all make sense to merge the tp_event->prog thing into this
> new event->prog?

'struct trace_event_call *tp_event' is global while tp_event->perf_events
are per cpu, so I don't see how we can do that without breaking user space
logic. Right now users do single perf_event_open of kprobe and attach prog
that is executed on all cpus where kprobe is firing. Additional per-cpu
filtering is done from within bpf prog.

> >  #ifdef CONFIG_HAVE_HW_BREAKPOINT
> > @@ -8957,6 +9029,14 @@ perf_event_alloc(struct perf_event_attr *attr, int 
> > cpu,
> > if (!overflow_handler && parent_event) {
> > overflow_handler = parent_event->overflow_handler;
> > context = parent_event->overflow_handler_context;
> > +   if (overflow_handler == bpf_overflow_handler) {
> > +   event->prog = bpf_prog_inc(parent_event->prog);
> > +   event->orig_overflow_handler = 
> > parent_event->orig_overflow_handler;
> > +   if (IS_ERR(event->prog)) {
> > +   event->prog = NULL;
> > +   overflow_handler = NULL;
> > +   }
> > +   }
> > }
> 
> Should we not fail the entire perf_event_alloc() call in that IS_ERR()
> case?

Yes. Good point. Will do.

[PATCH v4 0/2] serial: 8250_dw: Add ACPI support for uart on Hisilicon Hip05 SoC

[Kefeng Wang]

Handle all cases of dw8250_data->clk properly in dw8250_set_termios(), then
make it as the default set_termios callback for 8250 dw uart.

After that, add ACPI support for uart on Hisilicon Hip05 SoC, be careful that
it is not 16500 compatible, and with Heikki's patchset[1], we safely only add
ACPI identifier, due to the ACPI quirks in dw8250_quirks() only for "APMC0D08".

Change since v3:
- The new dev var patch is sent separately.
- Address the comment from Andy, and repost patches based on Heikki Krogerus's 
patchset[1]
  "[PATCHv2 0/3] serial: dw8250: ACPI tuning"  

Change since v2:
- Add a new patch to use new var dev in probe
- Use built-in device properties to set device parameters for existing device 
probed by acpi,
  suggested by Andy Shevchenko


Change since v1:
- Use acpi_match_device() instead of acpi_dev_found(), limit the check to the 
device
  being probed and not a global search for whole DSDT (pointed by 
graeme.greg...@linaro.org)

[1] http://www.spinics.net/lists/linux-acpi/msg68519.html

Kefeng Wang (2):
  serial: 8250_dw: make dw8250_set_termios as default set_termios
callback
  serial: 8250_dw: add ACPI support for uart on Hisilicon Hip05 SoC

 drivers/tty/serial/8250/8250_dw.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

-- 
1.7.12.4

Re: [PATCHV5 1/3] tracing: add a possibility of exporting function trace to other places instead of ring buffer only

[Chunyan Zhang]

On 30 August 2016 at 22:30, Steven Rostedt  wrote:
> On Tue, 30 Aug 2016 16:07:28 +0800
> Chunyan Zhang  wrote:
>
>> Currently Function traces can be only exported to ring buffer, this
>> patch added trace_export concept which can process traces and export
>> them to a registered destination as an addition to the current only
>> output of Ftrace - i.e. ring buffer.
>>
>> In this way, if we want Function traces to be sent to other destination
>> rather than ring buffer only, we just need to register a new
>> trace_export and implement its own .commit() callback or just use
>> 'trace_generic_commit()' which this patch also added and hooks up its
>> own .write() function for writing traces to the storage.
>>
>> With this patch, only Function trace (trace type is TRACE_FN)
>> is supported.
>>
>> Signed-off-by: Chunyan Zhang 
>> ---
>>  include/linux/trace.h |  35 
>>  kernel/trace/trace.c  | 155 
>> +-
>>  kernel/trace/trace.h  |   1 +
>>  3 files changed, 190 insertions(+), 1 deletion(-)
>>  create mode 100644 include/linux/trace.h
>>
>> diff --git a/include/linux/trace.h b/include/linux/trace.h
>> new file mode 100644
>> index 000..30ded92
>> --- /dev/null
>> +++ b/include/linux/trace.h
>> @@ -0,0 +1,35 @@
>> +#ifndef _LINUX_TRACE_H
>> +#define _LINUX_TRACE_H
>> +
>> +#include 
>> +struct trace_array;
>> +
>> +#ifdef CONFIG_TRACING
>> +/*
>> + * The trace export - an export of Ftrace. The trace_export can process
>> + * traces and export them to a registered destination as an addition to
>> + * the current only output of Ftrace - i.e. ring buffer.
>> + *
>> + * If you want traces to be sent to some other place rather than
>> + * ring buffer only, just need to register a new trace_export and
>> + * implement its own .commit() callback or just directly use
>> + * 'trace_generic_commit()' and hooks up its own .write() function
>> + * for writing traces to the storage.
>> + *
>> + * next  - pointer to the next trace_export
>> + * commit- commit the traces to the destination
>> + * write - copy traces which have been delt with ->commit() to
>> + * the destination
>> + */
>> +struct trace_export {
>> + struct trace_export __rcu   *next;
>> + void (*commit)(struct trace_array *, struct ring_buffer_event *);
>> + void (*write)(const char *, unsigned int);
>> +};
>> +
>> +int register_ftrace_export(struct trace_export *export);
>> +int unregister_ftrace_export(struct trace_export *export);
>> +
>> +#endif   /* CONFIG_TRACING */
>> +
>> +#endif   /* _LINUX_TRACE_H */
>> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
>> index dade4c9..3163fa6 100644
>> --- a/kernel/trace/trace.c
>> +++ b/kernel/trace/trace.c
>> @@ -40,6 +40,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>
>>  #include "trace.h"
>> @@ -2128,6 +2129,155 @@ void trace_buffer_unlock_commit_regs(struct 
>> trace_array *tr,
>>   ftrace_trace_userstack(buffer, flags, pc);
>>  }
>>
>> +static DEFINE_STATIC_KEY_FALSE(ftrace_exports_enabled);
>> +
>> +static void ftrace_exports_enable(void)
>> +{
>> + static_branch_enable(_exports_enabled);
>> +}
>> +
>> +static void ftrace_exports_disable(void)
>> +{
>> + static_branch_disable(_exports_enabled);
>> +}
>> +
>> +static size_t trace_size[] = {
>> + [TRACE_FN]  = sizeof(struct ftrace_entry),
>> + [TRACE_CTX] = sizeof(struct ctx_switch_entry),
>> + [TRACE_WAKE]= sizeof(struct ctx_switch_entry),
>> + [TRACE_STACK]   = sizeof(struct stack_entry),
>> + [TRACE_PRINT]   = sizeof(struct print_entry),
>> + [TRACE_BPRINT]  = sizeof(struct bprint_entry),
>> + [TRACE_MMIO_RW] = sizeof(struct trace_mmiotrace_rw),
>> + [TRACE_MMIO_MAP]= sizeof(struct trace_mmiotrace_map),
>> + [TRACE_BRANCH]  = sizeof(struct trace_branch),
>> + [TRACE_GRAPH_RET]   = sizeof(struct ftrace_graph_ret_entry),
>> + [TRACE_GRAPH_ENT]   = sizeof(struct ftrace_graph_ent_entry),
>> + [TRACE_USER_STACK]  = sizeof(struct userstack_entry),
>> + [TRACE_BPUTS]   = sizeof(struct bputs_entry),
>> +};
>> +
>> +static void
>> +trace_generic_commit(struct trace_array *tr,
>> +struct ring_buffer_event *event)
>> +{
>> + struct trace_entry *entry;
>> + struct trace_export *export = tr->export;
>
> Why not just pass in the export directly?
>
>> + unsigned int size = 0;
>> +
>> + entry = ring_buffer_event_data(event);
>> +
>> + size = trace_size[entry->type];
>
> BTW, it would make much more sense if you just did:
>
> size = ring_buffer_event_length(event);
>
> and get rid of that silly array, as that is prone to bugs if you add a
> new type.
>
>> + if (!size)
>> + return;
>> +
>> + if (export && export->write)
>> + 

[PATCH v4 0/2] serial: 8250_dw: Add ACPI support for uart on Hisilicon Hip05 SoC

[Kefeng Wang]

Handle all cases of dw8250_data->clk properly in dw8250_set_termios(), then
make it as the default set_termios callback for 8250 dw uart.

After that, add ACPI support for uart on Hisilicon Hip05 SoC, be careful that
it is not 16500 compatible, and with Heikki's patchset[1], we safely only add
ACPI identifier, due to the ACPI quirks in dw8250_quirks() only for "APMC0D08".

Change since v3:
- The new dev var patch is sent separately.
- Address the comment from Andy, and repost patches based on Heikki Krogerus's 
patchset[1]
  "[PATCHv2 0/3] serial: dw8250: ACPI tuning"  

Change since v2:
- Add a new patch to use new var dev in probe
- Use built-in device properties to set device parameters for existing device 
probed by acpi,
  suggested by Andy Shevchenko


Change since v1:
- Use acpi_match_device() instead of acpi_dev_found(), limit the check to the 
device
  being probed and not a global search for whole DSDT (pointed by 
graeme.greg...@linaro.org)

[1] http://www.spinics.net/lists/linux-acpi/msg68519.html

Kefeng Wang (2):
  serial: 8250_dw: make dw8250_set_termios as default set_termios
callback
  serial: 8250_dw: add ACPI support for uart on Hisilicon Hip05 SoC

 drivers/tty/serial/8250/8250_dw.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

-- 
1.7.12.4

Re: [PATCHV5 1/3] tracing: add a possibility of exporting function trace to other places instead of ring buffer only

[Chunyan Zhang]

On 30 August 2016 at 22:30, Steven Rostedt  wrote:
> On Tue, 30 Aug 2016 16:07:28 +0800
> Chunyan Zhang  wrote:
>
>> Currently Function traces can be only exported to ring buffer, this
>> patch added trace_export concept which can process traces and export
>> them to a registered destination as an addition to the current only
>> output of Ftrace - i.e. ring buffer.
>>
>> In this way, if we want Function traces to be sent to other destination
>> rather than ring buffer only, we just need to register a new
>> trace_export and implement its own .commit() callback or just use
>> 'trace_generic_commit()' which this patch also added and hooks up its
>> own .write() function for writing traces to the storage.
>>
>> With this patch, only Function trace (trace type is TRACE_FN)
>> is supported.
>>
>> Signed-off-by: Chunyan Zhang 
>> ---
>>  include/linux/trace.h |  35 
>>  kernel/trace/trace.c  | 155 
>> +-
>>  kernel/trace/trace.h  |   1 +
>>  3 files changed, 190 insertions(+), 1 deletion(-)
>>  create mode 100644 include/linux/trace.h
>>
>> diff --git a/include/linux/trace.h b/include/linux/trace.h
>> new file mode 100644
>> index 000..30ded92
>> --- /dev/null
>> +++ b/include/linux/trace.h
>> @@ -0,0 +1,35 @@
>> +#ifndef _LINUX_TRACE_H
>> +#define _LINUX_TRACE_H
>> +
>> +#include 
>> +struct trace_array;
>> +
>> +#ifdef CONFIG_TRACING
>> +/*
>> + * The trace export - an export of Ftrace. The trace_export can process
>> + * traces and export them to a registered destination as an addition to
>> + * the current only output of Ftrace - i.e. ring buffer.
>> + *
>> + * If you want traces to be sent to some other place rather than
>> + * ring buffer only, just need to register a new trace_export and
>> + * implement its own .commit() callback or just directly use
>> + * 'trace_generic_commit()' and hooks up its own .write() function
>> + * for writing traces to the storage.
>> + *
>> + * next  - pointer to the next trace_export
>> + * commit- commit the traces to the destination
>> + * write - copy traces which have been delt with ->commit() to
>> + * the destination
>> + */
>> +struct trace_export {
>> + struct trace_export __rcu   *next;
>> + void (*commit)(struct trace_array *, struct ring_buffer_event *);
>> + void (*write)(const char *, unsigned int);
>> +};
>> +
>> +int register_ftrace_export(struct trace_export *export);
>> +int unregister_ftrace_export(struct trace_export *export);
>> +
>> +#endif   /* CONFIG_TRACING */
>> +
>> +#endif   /* _LINUX_TRACE_H */
>> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
>> index dade4c9..3163fa6 100644
>> --- a/kernel/trace/trace.c
>> +++ b/kernel/trace/trace.c
>> @@ -40,6 +40,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>
>>  #include "trace.h"
>> @@ -2128,6 +2129,155 @@ void trace_buffer_unlock_commit_regs(struct 
>> trace_array *tr,
>>   ftrace_trace_userstack(buffer, flags, pc);
>>  }
>>
>> +static DEFINE_STATIC_KEY_FALSE(ftrace_exports_enabled);
>> +
>> +static void ftrace_exports_enable(void)
>> +{
>> + static_branch_enable(_exports_enabled);
>> +}
>> +
>> +static void ftrace_exports_disable(void)
>> +{
>> + static_branch_disable(_exports_enabled);
>> +}
>> +
>> +static size_t trace_size[] = {
>> + [TRACE_FN]  = sizeof(struct ftrace_entry),
>> + [TRACE_CTX] = sizeof(struct ctx_switch_entry),
>> + [TRACE_WAKE]= sizeof(struct ctx_switch_entry),
>> + [TRACE_STACK]   = sizeof(struct stack_entry),
>> + [TRACE_PRINT]   = sizeof(struct print_entry),
>> + [TRACE_BPRINT]  = sizeof(struct bprint_entry),
>> + [TRACE_MMIO_RW] = sizeof(struct trace_mmiotrace_rw),
>> + [TRACE_MMIO_MAP]= sizeof(struct trace_mmiotrace_map),
>> + [TRACE_BRANCH]  = sizeof(struct trace_branch),
>> + [TRACE_GRAPH_RET]   = sizeof(struct ftrace_graph_ret_entry),
>> + [TRACE_GRAPH_ENT]   = sizeof(struct ftrace_graph_ent_entry),
>> + [TRACE_USER_STACK]  = sizeof(struct userstack_entry),
>> + [TRACE_BPUTS]   = sizeof(struct bputs_entry),
>> +};
>> +
>> +static void
>> +trace_generic_commit(struct trace_array *tr,
>> +struct ring_buffer_event *event)
>> +{
>> + struct trace_entry *entry;
>> + struct trace_export *export = tr->export;
>
> Why not just pass in the export directly?
>
>> + unsigned int size = 0;
>> +
>> + entry = ring_buffer_event_data(event);
>> +
>> + size = trace_size[entry->type];
>
> BTW, it would make much more sense if you just did:
>
> size = ring_buffer_event_length(event);
>
> and get rid of that silly array, as that is prone to bugs if you add a
> new type.
>
>> + if (!size)
>> + return;
>> +
>> + if (export && export->write)
>> + export->write((char *)entry, size);
>> +}
>> +
>> +static 

[PATCH 1/3] autofs: remove possibly misleading /* #define DEBUG */

[Ian Kent]

From: Tomohiro Kusumi 

Having this in autofs_i.h gives illusion that uncommenting this
enables pr_debug(), but it doesn't enable all the pr_debug() in
autofs because inclusion order matters.

XFS has the same DEBUG macro in its core header fs/xfs/xfs.h,
however XFS seems to have a rule to include this prior to other
XFS headers as well as kernel headers. This is not the case with
autofs, and DEBUG could be enabled via Makefile, so autofs should
just get rid of this comment to make the code less confusing.
It's a comment, so there is literally no functional difference.

Signed-off-by: Tomohiro Kusumi 
Signed-off-by: Ian Kent 
---
 fs/autofs4/autofs_i.h |2 --
 1 file changed, 2 deletions(-)

diff --git a/fs/autofs4/autofs_i.h b/fs/autofs4/autofs_i.h
index dd71bd4..4404a22 100644
--- a/fs/autofs4/autofs_i.h
+++ b/fs/autofs4/autofs_i.h
@@ -34,8 +34,6 @@
 #include 
 #include 
 
-/* #define DEBUG */
-
 #ifdef pr_fmt
 #undef pr_fmt
 #endif

[PATCH 1/3] autofs: remove possibly misleading /* #define DEBUG */

[Ian Kent]

From: Tomohiro Kusumi 

Having this in autofs_i.h gives illusion that uncommenting this
enables pr_debug(), but it doesn't enable all the pr_debug() in
autofs because inclusion order matters.

XFS has the same DEBUG macro in its core header fs/xfs/xfs.h,
however XFS seems to have a rule to include this prior to other
XFS headers as well as kernel headers. This is not the case with
autofs, and DEBUG could be enabled via Makefile, so autofs should
just get rid of this comment to make the code less confusing.
It's a comment, so there is literally no functional difference.

Signed-off-by: Tomohiro Kusumi 
Signed-off-by: Ian Kent 
---
 fs/autofs4/autofs_i.h |2 --
 1 file changed, 2 deletions(-)

diff --git a/fs/autofs4/autofs_i.h b/fs/autofs4/autofs_i.h
index dd71bd4..4404a22 100644
--- a/fs/autofs4/autofs_i.h
+++ b/fs/autofs4/autofs_i.h
@@ -34,8 +34,6 @@
 #include 
 #include 
 
-/* #define DEBUG */
-
 #ifdef pr_fmt
 #undef pr_fmt
 #endif

[PATCH 3/3] autofs: fix "fix dev ioctl number range check"

[Ian Kent]

From: Tomohiro Kusumi 

102a340f had a typo that made the count macro negative (-13).
The acutal check used by ioctl is ((cmd - cmd_first) > COUNT),
so it needs to be positive (13).

* 102a340f is a commit in linux-next which hasn't been merged
to mainline upstream.

Signed-off-by: Tomohiro Kusumi 
Signed-off-by: Ian Kent 
---
 fs/autofs4/autofs_i.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/autofs4/autofs_i.h b/fs/autofs4/autofs_i.h
index 4404a22..a1fba42 100644
--- a/fs/autofs4/autofs_i.h
+++ b/fs/autofs4/autofs_i.h
@@ -21,7 +21,7 @@
 
 #define AUTOFS_DEV_IOCTL_IOC_FIRST (AUTOFS_DEV_IOCTL_VERSION)
 #define AUTOFS_DEV_IOCTL_IOC_COUNT \
-   (AUTOFS_DEV_IOCTL_VERSION_CMD - AUTOFS_DEV_IOCTL_ISMOUNTPOINT_CMD)
+   (AUTOFS_DEV_IOCTL_ISMOUNTPOINT_CMD - AUTOFS_DEV_IOCTL_VERSION_CMD)
 
 #include 
 #include 

[PATCH v4 2/2] serial: 8250_dw: add ACPI support for uart on Hisilicon Hip05 SoC

[Kefeng Wang]

Add ACPI identifier for UART on Hisilicon Hip05 SoC, be careful that
it is not 16550 compatible, and "reg-io-width" and "reg-shift" need
be set properly by _DSD method in DSDT.

Signed-off-by: Kefeng Wang 
---
 drivers/tty/serial/8250/8250_dw.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/tty/serial/8250/8250_dw.c 
b/drivers/tty/serial/8250/8250_dw.c
index adecece..3478c2c 100644
--- a/drivers/tty/serial/8250/8250_dw.c
+++ b/drivers/tty/serial/8250/8250_dw.c
@@ -623,6 +623,7 @@ static const struct acpi_device_id dw8250_acpi_match[] = {
{ "APMC0D08", 0},
{ "AMD0020", 0 },
{ "AMDI0020", 0 },
+   { "HISI0031", 0 },
{ },
 };
 MODULE_DEVICE_TABLE(acpi, dw8250_acpi_match);
-- 
1.7.12.4

[PATCH 2/3] autofs: refactor ioctl fn vector in iookup_dev_ioctl()

[Ian Kent]

From: Tomohiro Kusumi 

cmd part of this struct is the same as an index of itself within
_ioctls[]. In fact this cmd is unused, so we can drop this part.

Signed-off-by: Tomohiro Kusumi 
Signed-off-by: Ian Kent 
---
 fs/autofs4/dev-ioctl.c |   49 
 1 file changed, 16 insertions(+), 33 deletions(-)

diff --git a/fs/autofs4/dev-ioctl.c b/fs/autofs4/dev-ioctl.c
index e89d6bb..fc09eb7 100644
--- a/fs/autofs4/dev-ioctl.c
+++ b/fs/autofs4/dev-ioctl.c
@@ -597,42 +597,25 @@ out:
 
 static ioctl_fn lookup_dev_ioctl(unsigned int cmd)
 {
-   static struct {
-   int cmd;
-   ioctl_fn fn;
-   } _ioctls[] = {
-   {cmd_idx(AUTOFS_DEV_IOCTL_VERSION_CMD),
-autofs_dev_ioctl_version},
-   {cmd_idx(AUTOFS_DEV_IOCTL_PROTOVER_CMD),
-autofs_dev_ioctl_protover},
-   {cmd_idx(AUTOFS_DEV_IOCTL_PROTOSUBVER_CMD),
-autofs_dev_ioctl_protosubver},
-   {cmd_idx(AUTOFS_DEV_IOCTL_OPENMOUNT_CMD),
-autofs_dev_ioctl_openmount},
-   {cmd_idx(AUTOFS_DEV_IOCTL_CLOSEMOUNT_CMD),
-autofs_dev_ioctl_closemount},
-   {cmd_idx(AUTOFS_DEV_IOCTL_READY_CMD),
-autofs_dev_ioctl_ready},
-   {cmd_idx(AUTOFS_DEV_IOCTL_FAIL_CMD),
-autofs_dev_ioctl_fail},
-   {cmd_idx(AUTOFS_DEV_IOCTL_SETPIPEFD_CMD),
-autofs_dev_ioctl_setpipefd},
-   {cmd_idx(AUTOFS_DEV_IOCTL_CATATONIC_CMD),
-autofs_dev_ioctl_catatonic},
-   {cmd_idx(AUTOFS_DEV_IOCTL_TIMEOUT_CMD),
-autofs_dev_ioctl_timeout},
-   {cmd_idx(AUTOFS_DEV_IOCTL_REQUESTER_CMD),
-autofs_dev_ioctl_requester},
-   {cmd_idx(AUTOFS_DEV_IOCTL_EXPIRE_CMD),
-autofs_dev_ioctl_expire},
-   {cmd_idx(AUTOFS_DEV_IOCTL_ASKUMOUNT_CMD),
-autofs_dev_ioctl_askumount},
-   {cmd_idx(AUTOFS_DEV_IOCTL_ISMOUNTPOINT_CMD),
-autofs_dev_ioctl_ismountpoint}
+   static ioctl_fn _ioctls[] = {
+   autofs_dev_ioctl_version,
+   autofs_dev_ioctl_protover,
+   autofs_dev_ioctl_protosubver,
+   autofs_dev_ioctl_openmount,
+   autofs_dev_ioctl_closemount,
+   autofs_dev_ioctl_ready,
+   autofs_dev_ioctl_fail,
+   autofs_dev_ioctl_setpipefd,
+   autofs_dev_ioctl_catatonic,
+   autofs_dev_ioctl_timeout,
+   autofs_dev_ioctl_requester,
+   autofs_dev_ioctl_expire,
+   autofs_dev_ioctl_askumount,
+   autofs_dev_ioctl_ismountpoint,
};
unsigned int idx = cmd_idx(cmd);
 
-   return (idx >= ARRAY_SIZE(_ioctls)) ? NULL : _ioctls[idx].fn;
+   return (idx >= ARRAY_SIZE(_ioctls)) ? NULL : _ioctls[idx];
 }
 
 /* ioctl dispatcher */

[PATCH 3/3] autofs: fix "fix dev ioctl number range check"

[Ian Kent]

From: Tomohiro Kusumi 

102a340f had a typo that made the count macro negative (-13).
The acutal check used by ioctl is ((cmd - cmd_first) > COUNT),
so it needs to be positive (13).

* 102a340f is a commit in linux-next which hasn't been merged
to mainline upstream.

Signed-off-by: Tomohiro Kusumi 
Signed-off-by: Ian Kent 
---
 fs/autofs4/autofs_i.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/autofs4/autofs_i.h b/fs/autofs4/autofs_i.h
index 4404a22..a1fba42 100644
--- a/fs/autofs4/autofs_i.h
+++ b/fs/autofs4/autofs_i.h
@@ -21,7 +21,7 @@
 
 #define AUTOFS_DEV_IOCTL_IOC_FIRST (AUTOFS_DEV_IOCTL_VERSION)
 #define AUTOFS_DEV_IOCTL_IOC_COUNT \
-   (AUTOFS_DEV_IOCTL_VERSION_CMD - AUTOFS_DEV_IOCTL_ISMOUNTPOINT_CMD)
+   (AUTOFS_DEV_IOCTL_ISMOUNTPOINT_CMD - AUTOFS_DEV_IOCTL_VERSION_CMD)
 
 #include 
 #include 

[PATCH v4 2/2] serial: 8250_dw: add ACPI support for uart on Hisilicon Hip05 SoC

[Kefeng Wang]

Add ACPI identifier for UART on Hisilicon Hip05 SoC, be careful that
it is not 16550 compatible, and "reg-io-width" and "reg-shift" need
be set properly by _DSD method in DSDT.

Signed-off-by: Kefeng Wang 
---
 drivers/tty/serial/8250/8250_dw.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/tty/serial/8250/8250_dw.c 
b/drivers/tty/serial/8250/8250_dw.c
index adecece..3478c2c 100644
--- a/drivers/tty/serial/8250/8250_dw.c
+++ b/drivers/tty/serial/8250/8250_dw.c
@@ -623,6 +623,7 @@ static const struct acpi_device_id dw8250_acpi_match[] = {
{ "APMC0D08", 0},
{ "AMD0020", 0 },
{ "AMDI0020", 0 },
+   { "HISI0031", 0 },
{ },
 };
 MODULE_DEVICE_TABLE(acpi, dw8250_acpi_match);
-- 
1.7.12.4

[PATCH 2/3] autofs: refactor ioctl fn vector in iookup_dev_ioctl()

[Ian Kent]

From: Tomohiro Kusumi 

cmd part of this struct is the same as an index of itself within
_ioctls[]. In fact this cmd is unused, so we can drop this part.

Signed-off-by: Tomohiro Kusumi 
Signed-off-by: Ian Kent 
---
 fs/autofs4/dev-ioctl.c |   49 
 1 file changed, 16 insertions(+), 33 deletions(-)

diff --git a/fs/autofs4/dev-ioctl.c b/fs/autofs4/dev-ioctl.c
index e89d6bb..fc09eb7 100644
--- a/fs/autofs4/dev-ioctl.c
+++ b/fs/autofs4/dev-ioctl.c
@@ -597,42 +597,25 @@ out:
 
 static ioctl_fn lookup_dev_ioctl(unsigned int cmd)
 {
-   static struct {
-   int cmd;
-   ioctl_fn fn;
-   } _ioctls[] = {
-   {cmd_idx(AUTOFS_DEV_IOCTL_VERSION_CMD),
-autofs_dev_ioctl_version},
-   {cmd_idx(AUTOFS_DEV_IOCTL_PROTOVER_CMD),
-autofs_dev_ioctl_protover},
-   {cmd_idx(AUTOFS_DEV_IOCTL_PROTOSUBVER_CMD),
-autofs_dev_ioctl_protosubver},
-   {cmd_idx(AUTOFS_DEV_IOCTL_OPENMOUNT_CMD),
-autofs_dev_ioctl_openmount},
-   {cmd_idx(AUTOFS_DEV_IOCTL_CLOSEMOUNT_CMD),
-autofs_dev_ioctl_closemount},
-   {cmd_idx(AUTOFS_DEV_IOCTL_READY_CMD),
-autofs_dev_ioctl_ready},
-   {cmd_idx(AUTOFS_DEV_IOCTL_FAIL_CMD),
-autofs_dev_ioctl_fail},
-   {cmd_idx(AUTOFS_DEV_IOCTL_SETPIPEFD_CMD),
-autofs_dev_ioctl_setpipefd},
-   {cmd_idx(AUTOFS_DEV_IOCTL_CATATONIC_CMD),
-autofs_dev_ioctl_catatonic},
-   {cmd_idx(AUTOFS_DEV_IOCTL_TIMEOUT_CMD),
-autofs_dev_ioctl_timeout},
-   {cmd_idx(AUTOFS_DEV_IOCTL_REQUESTER_CMD),
-autofs_dev_ioctl_requester},
-   {cmd_idx(AUTOFS_DEV_IOCTL_EXPIRE_CMD),
-autofs_dev_ioctl_expire},
-   {cmd_idx(AUTOFS_DEV_IOCTL_ASKUMOUNT_CMD),
-autofs_dev_ioctl_askumount},
-   {cmd_idx(AUTOFS_DEV_IOCTL_ISMOUNTPOINT_CMD),
-autofs_dev_ioctl_ismountpoint}
+   static ioctl_fn _ioctls[] = {
+   autofs_dev_ioctl_version,
+   autofs_dev_ioctl_protover,
+   autofs_dev_ioctl_protosubver,
+   autofs_dev_ioctl_openmount,
+   autofs_dev_ioctl_closemount,
+   autofs_dev_ioctl_ready,
+   autofs_dev_ioctl_fail,
+   autofs_dev_ioctl_setpipefd,
+   autofs_dev_ioctl_catatonic,
+   autofs_dev_ioctl_timeout,
+   autofs_dev_ioctl_requester,
+   autofs_dev_ioctl_expire,
+   autofs_dev_ioctl_askumount,
+   autofs_dev_ioctl_ismountpoint,
};
unsigned int idx = cmd_idx(cmd);
 
-   return (idx >= ARRAY_SIZE(_ioctls)) ? NULL : _ioctls[idx].fn;
+   return (idx >= ARRAY_SIZE(_ioctls)) ? NULL : _ioctls[idx];
 }
 
 /* ioctl dispatcher */

[PATCH] serial: 8250_dw: Use an unified new dev variable in probe

[Kefeng Wang]

Use an unified new dev variable instead of >dev and p->dev
in probe function.

Signed-off-by: Kefeng Wang 
---
 drivers/tty/serial/8250/8250_dw.c | 45 ---
 1 file changed, 23 insertions(+), 22 deletions(-)

diff --git a/drivers/tty/serial/8250/8250_dw.c 
b/drivers/tty/serial/8250/8250_dw.c
index 3478c2c..225d797 100644
--- a/drivers/tty/serial/8250/8250_dw.c
+++ b/drivers/tty/serial/8250/8250_dw.c
@@ -363,18 +363,19 @@ static int dw8250_probe(struct platform_device *pdev)
struct resource *regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
int irq = platform_get_irq(pdev, 0);
struct uart_port *p = 
+   struct device *dev = >dev;
struct dw8250_data *data;
int err;
u32 val;
 
if (!regs) {
-   dev_err(>dev, "no registers defined\n");
+   dev_err(dev, "no registers defined\n");
return -EINVAL;
}
 
if (irq < 0) {
if (irq != -EPROBE_DEFER)
-   dev_err(>dev, "cannot get irq\n");
+   dev_err(dev, "cannot get irq\n");
return irq;
}
 
@@ -385,17 +386,17 @@ static int dw8250_probe(struct platform_device *pdev)
p->pm   = dw8250_do_pm;
p->type = PORT_8250;
p->flags= UPF_SHARE_IRQ | UPF_FIXED_PORT;
-   p->dev  = >dev;
+   p->dev  = dev;
p->iotype   = UPIO_MEM;
p->serial_in= dw8250_serial_in;
p->serial_out   = dw8250_serial_out;
p->set_termios  = dw8250_set_termios;
 
-   p->membase = devm_ioremap(>dev, regs->start, resource_size(regs));
+   p->membase = devm_ioremap(dev, regs->start, resource_size(regs));
if (!p->membase)
return -ENOMEM;
 
-   data = devm_kzalloc(>dev, sizeof(*data), GFP_KERNEL);
+   data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
if (!data)
return -ENOMEM;
 
@@ -403,57 +404,57 @@ static int dw8250_probe(struct platform_device *pdev)
data->usr_reg = DW_UART_USR;
p->private_data = data;
 
-   data->uart_16550_compatible = device_property_read_bool(p->dev,
+   data->uart_16550_compatible = device_property_read_bool(dev,
"snps,uart-16550-compatible");
 
-   err = device_property_read_u32(p->dev, "reg-shift", );
+   err = device_property_read_u32(dev, "reg-shift", );
if (!err)
p->regshift = val;
 
-   err = device_property_read_u32(p->dev, "reg-io-width", );
+   err = device_property_read_u32(dev, "reg-io-width", );
if (!err && val == 4) {
p->iotype = UPIO_MEM32;
p->serial_in = dw8250_serial_in32;
p->serial_out = dw8250_serial_out32;
}
 
-   if (device_property_read_bool(p->dev, "dcd-override")) {
+   if (device_property_read_bool(dev, "dcd-override")) {
/* Always report DCD as active */
data->msr_mask_on |= UART_MSR_DCD;
data->msr_mask_off |= UART_MSR_DDCD;
}
 
-   if (device_property_read_bool(p->dev, "dsr-override")) {
+   if (device_property_read_bool(dev, "dsr-override")) {
/* Always report DSR as active */
data->msr_mask_on |= UART_MSR_DSR;
data->msr_mask_off |= UART_MSR_DDSR;
}
 
-   if (device_property_read_bool(p->dev, "cts-override")) {
+   if (device_property_read_bool(dev, "cts-override")) {
/* Always report CTS as active */
data->msr_mask_on |= UART_MSR_CTS;
data->msr_mask_off |= UART_MSR_DCTS;
}
 
-   if (device_property_read_bool(p->dev, "ri-override")) {
+   if (device_property_read_bool(dev, "ri-override")) {
/* Always report Ring indicator as inactive */
data->msr_mask_off |= UART_MSR_RI;
data->msr_mask_off |= UART_MSR_TERI;
}
 
/* Always ask for fixed clock rate from a property. */
-   device_property_read_u32(p->dev, "clock-frequency", >uartclk);
+   device_property_read_u32(dev, "clock-frequency", >uartclk);
 
/* If there is separate baudclk, get the rate from it. */
-   data->clk = devm_clk_get(>dev, "baudclk");
+   data->clk = devm_clk_get(dev, "baudclk");
if (IS_ERR(data->clk) && PTR_ERR(data->clk) != -EPROBE_DEFER)
-   data->clk = devm_clk_get(>dev, NULL);
+   data->clk = devm_clk_get(dev, NULL);
if (IS_ERR(data->clk) && PTR_ERR(data->clk) == -EPROBE_DEFER)
return -EPROBE_DEFER;
if (!IS_ERR_OR_NULL(data->clk)) {
err = clk_prepare_enable(data->clk);
if (err)
-   dev_warn(>dev, "could not enable optional 
baudclk: %d\n",
+   dev_warn(dev, "could not enable 

[PATCH] serial: 8250_dw: Use an unified new dev variable in probe

[Kefeng Wang]

Use an unified new dev variable instead of >dev and p->dev
in probe function.

Signed-off-by: Kefeng Wang 
---
 drivers/tty/serial/8250/8250_dw.c | 45 ---
 1 file changed, 23 insertions(+), 22 deletions(-)

diff --git a/drivers/tty/serial/8250/8250_dw.c 
b/drivers/tty/serial/8250/8250_dw.c
index 3478c2c..225d797 100644
--- a/drivers/tty/serial/8250/8250_dw.c
+++ b/drivers/tty/serial/8250/8250_dw.c
@@ -363,18 +363,19 @@ static int dw8250_probe(struct platform_device *pdev)
struct resource *regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
int irq = platform_get_irq(pdev, 0);
struct uart_port *p = 
+   struct device *dev = >dev;
struct dw8250_data *data;
int err;
u32 val;
 
if (!regs) {
-   dev_err(>dev, "no registers defined\n");
+   dev_err(dev, "no registers defined\n");
return -EINVAL;
}
 
if (irq < 0) {
if (irq != -EPROBE_DEFER)
-   dev_err(>dev, "cannot get irq\n");
+   dev_err(dev, "cannot get irq\n");
return irq;
}
 
@@ -385,17 +386,17 @@ static int dw8250_probe(struct platform_device *pdev)
p->pm   = dw8250_do_pm;
p->type = PORT_8250;
p->flags= UPF_SHARE_IRQ | UPF_FIXED_PORT;
-   p->dev  = >dev;
+   p->dev  = dev;
p->iotype   = UPIO_MEM;
p->serial_in= dw8250_serial_in;
p->serial_out   = dw8250_serial_out;
p->set_termios  = dw8250_set_termios;
 
-   p->membase = devm_ioremap(>dev, regs->start, resource_size(regs));
+   p->membase = devm_ioremap(dev, regs->start, resource_size(regs));
if (!p->membase)
return -ENOMEM;
 
-   data = devm_kzalloc(>dev, sizeof(*data), GFP_KERNEL);
+   data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
if (!data)
return -ENOMEM;
 
@@ -403,57 +404,57 @@ static int dw8250_probe(struct platform_device *pdev)
data->usr_reg = DW_UART_USR;
p->private_data = data;
 
-   data->uart_16550_compatible = device_property_read_bool(p->dev,
+   data->uart_16550_compatible = device_property_read_bool(dev,
"snps,uart-16550-compatible");
 
-   err = device_property_read_u32(p->dev, "reg-shift", );
+   err = device_property_read_u32(dev, "reg-shift", );
if (!err)
p->regshift = val;
 
-   err = device_property_read_u32(p->dev, "reg-io-width", );
+   err = device_property_read_u32(dev, "reg-io-width", );
if (!err && val == 4) {
p->iotype = UPIO_MEM32;
p->serial_in = dw8250_serial_in32;
p->serial_out = dw8250_serial_out32;
}
 
-   if (device_property_read_bool(p->dev, "dcd-override")) {
+   if (device_property_read_bool(dev, "dcd-override")) {
/* Always report DCD as active */
data->msr_mask_on |= UART_MSR_DCD;
data->msr_mask_off |= UART_MSR_DDCD;
}
 
-   if (device_property_read_bool(p->dev, "dsr-override")) {
+   if (device_property_read_bool(dev, "dsr-override")) {
/* Always report DSR as active */
data->msr_mask_on |= UART_MSR_DSR;
data->msr_mask_off |= UART_MSR_DDSR;
}
 
-   if (device_property_read_bool(p->dev, "cts-override")) {
+   if (device_property_read_bool(dev, "cts-override")) {
/* Always report CTS as active */
data->msr_mask_on |= UART_MSR_CTS;
data->msr_mask_off |= UART_MSR_DCTS;
}
 
-   if (device_property_read_bool(p->dev, "ri-override")) {
+   if (device_property_read_bool(dev, "ri-override")) {
/* Always report Ring indicator as inactive */
data->msr_mask_off |= UART_MSR_RI;
data->msr_mask_off |= UART_MSR_TERI;
}
 
/* Always ask for fixed clock rate from a property. */
-   device_property_read_u32(p->dev, "clock-frequency", >uartclk);
+   device_property_read_u32(dev, "clock-frequency", >uartclk);
 
/* If there is separate baudclk, get the rate from it. */
-   data->clk = devm_clk_get(>dev, "baudclk");
+   data->clk = devm_clk_get(dev, "baudclk");
if (IS_ERR(data->clk) && PTR_ERR(data->clk) != -EPROBE_DEFER)
-   data->clk = devm_clk_get(>dev, NULL);
+   data->clk = devm_clk_get(dev, NULL);
if (IS_ERR(data->clk) && PTR_ERR(data->clk) == -EPROBE_DEFER)
return -EPROBE_DEFER;
if (!IS_ERR_OR_NULL(data->clk)) {
err = clk_prepare_enable(data->clk);
if (err)
-   dev_warn(>dev, "could not enable optional 
baudclk: %d\n",
+   dev_warn(dev, "could not enable optional baudclk: %d\n",
   

[PATCH v4 1/2] serial: 8250_dw: make dw8250_set_termios as default set_termios callback

[Kefeng Wang]

Make dw8250_set_termios() handle all cases of dw8250_data->clk properly,
then we can safely use dw8250_set_termios() as the default set_termios
callback instead of serial8250_do_set_termios(), so do it.

Signed-off-by: Kefeng Wang 
---
 drivers/tty/serial/8250/8250_dw.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/tty/serial/8250/8250_dw.c 
b/drivers/tty/serial/8250/8250_dw.c
index 5c0c123..adecece 100644
--- a/drivers/tty/serial/8250/8250_dw.c
+++ b/drivers/tty/serial/8250/8250_dw.c
@@ -235,7 +235,7 @@ static void dw8250_set_termios(struct uart_port *p, struct 
ktermios *termios,
unsigned int rate;
int ret;
 
-   if (IS_ERR(d->clk) || !old)
+   if (IS_ERR_OR_NULL(d->clk) || !old)
goto out;
 
clk_disable_unprepare(d->clk);
@@ -308,13 +308,11 @@ static void dw8250_quirks(struct uart_port *p, struct 
dw8250_data *data)
p->serial_in = dw8250_serial_in32;
data->uart_16550_compatible = true;
}
-   p->set_termios = dw8250_set_termios;
}
 
/* Platforms with iDMA */
if (platform_get_resource_byname(to_platform_device(p->dev),
 IORESOURCE_MEM, "lpss_priv")) {
-   p->set_termios = dw8250_set_termios;
data->dma.rx_param = p->dev->parent;
data->dma.tx_param = p->dev->parent;
data->dma.fn = dw8250_idma_filter;
@@ -391,6 +389,7 @@ static int dw8250_probe(struct platform_device *pdev)
p->iotype   = UPIO_MEM;
p->serial_in= dw8250_serial_in;
p->serial_out   = dw8250_serial_out;
+   p->set_termios  = dw8250_set_termios;
 
p->membase = devm_ioremap(>dev, regs->start, resource_size(regs));
if (!p->membase)
-- 
1.7.12.4

[PATCH v4 1/2] serial: 8250_dw: make dw8250_set_termios as default set_termios callback

[Kefeng Wang]

Make dw8250_set_termios() handle all cases of dw8250_data->clk properly,
then we can safely use dw8250_set_termios() as the default set_termios
callback instead of serial8250_do_set_termios(), so do it.

Signed-off-by: Kefeng Wang 
---
 drivers/tty/serial/8250/8250_dw.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/tty/serial/8250/8250_dw.c 
b/drivers/tty/serial/8250/8250_dw.c
index 5c0c123..adecece 100644
--- a/drivers/tty/serial/8250/8250_dw.c
+++ b/drivers/tty/serial/8250/8250_dw.c
@@ -235,7 +235,7 @@ static void dw8250_set_termios(struct uart_port *p, struct 
ktermios *termios,
unsigned int rate;
int ret;
 
-   if (IS_ERR(d->clk) || !old)
+   if (IS_ERR_OR_NULL(d->clk) || !old)
goto out;
 
clk_disable_unprepare(d->clk);
@@ -308,13 +308,11 @@ static void dw8250_quirks(struct uart_port *p, struct 
dw8250_data *data)
p->serial_in = dw8250_serial_in32;
data->uart_16550_compatible = true;
}
-   p->set_termios = dw8250_set_termios;
}
 
/* Platforms with iDMA */
if (platform_get_resource_byname(to_platform_device(p->dev),
 IORESOURCE_MEM, "lpss_priv")) {
-   p->set_termios = dw8250_set_termios;
data->dma.rx_param = p->dev->parent;
data->dma.tx_param = p->dev->parent;
data->dma.fn = dw8250_idma_filter;
@@ -391,6 +389,7 @@ static int dw8250_probe(struct platform_device *pdev)
p->iotype   = UPIO_MEM;
p->serial_in= dw8250_serial_in;
p->serial_out   = dw8250_serial_out;
+   p->set_termios  = dw8250_set_termios;
 
p->membase = devm_ioremap(>dev, regs->start, resource_size(regs));
if (!p->membase)
-- 
1.7.12.4

Re: [RFC v2 09/10] landlock: Handle cgroups (performance)

[Andy Lutomirski]

On Tue, Aug 30, 2016 at 6:36 PM, Alexei Starovoitov
 wrote:
> On Tue, Aug 30, 2016 at 02:45:14PM -0700, Andy Lutomirski wrote:
>>
>> One might argue that landlock shouldn't be tied to seccomp (in theory,
>> attached progs could be given access to syscall_get_xyz()), but I
>
> proposed lsm is way more powerful than syscall_get_xyz.
> no need to dumb it down.

I think you're misunderstanding me.

Mickaël's code allows one to make the LSM hook filters depend on the
syscall using SECCOMP_RET_LANDLOCK.  I'm suggesting that a similar
effect could be achieved by allowing the eBPF LSM hook to call
syscall_get_xyz() if it wants to.

>
>> think that the seccomp attachment mechanism is the right way to
>> install unprivileged filters.  It handles the no_new_privs stuff, it
>> allows TSYNC, it's totally independent of systemwide policy, etc.
>>
>> Trying to use cgroups or similar for this is going to be much nastier.
>> Some tighter sandboxes (Sandstorm, etc) aren't even going to dream of
>> putting cgroupfs in their containers, so requiring cgroups or similar
>> would be a mess for that type of application.
>
> I don't see why it is a 'mess'. cgroups are already used by majority
> of the systems, so I don't see why requiring a cgroup is such a big deal.

Requiring cgroup to be configured in isn't a big deal.  Requiring

> But let's say we don't do them. How implementation is going to look like
> for task based hierarchy? Note that we need an array of bpf_prog pointers.
> One for each lsm hook. Where this array is going to be stored?
> We cannot put in task_struct, since it's too large. Cannot put it
> into 'struct seccomp' directly either, unless it will become a pointer.
> Is that the proposal?

It would go in struct seccomp_filter or in something pointed to from there.

> So now we will be wasting extra 1kbyte of memory per task. Not great.
> We'd want to optimize it by sharing this such struct seccomp with prog array
> across threads of the same task? Or dynimically allocating it when
> landlock is in use? May sound nice, but how to account for that kernel
> memory? I guess also solvable by charging memlock.
> With cgroup based approach we don't need to worry about all that.
>

The considerations are essentially identical either way.

With cgroups, if you want to share the memory between multiple
separate sandboxes (Firejail instances, Sandstorm grains, Chromium
instances, xdg-apps, etc), you'd need to get them to all coordinate to
share a cgroup.  With a seccomp-like interface, you'd need to get them
to coordinate to share an installed layer (using my FD idea or
similar).

There would *not* be any duplication of this memory just because a
sandboxed process called fork().

--Andy

-- 
Andy Lutomirski
AMA Capital Management, LLC

Re: [RFC v2 09/10] landlock: Handle cgroups (performance)

[Andy Lutomirski]

On Tue, Aug 30, 2016 at 6:36 PM, Alexei Starovoitov
 wrote:
> On Tue, Aug 30, 2016 at 02:45:14PM -0700, Andy Lutomirski wrote:
>>
>> One might argue that landlock shouldn't be tied to seccomp (in theory,
>> attached progs could be given access to syscall_get_xyz()), but I
>
> proposed lsm is way more powerful than syscall_get_xyz.
> no need to dumb it down.

I think you're misunderstanding me.

Mickaël's code allows one to make the LSM hook filters depend on the
syscall using SECCOMP_RET_LANDLOCK.  I'm suggesting that a similar
effect could be achieved by allowing the eBPF LSM hook to call
syscall_get_xyz() if it wants to.

>
>> think that the seccomp attachment mechanism is the right way to
>> install unprivileged filters.  It handles the no_new_privs stuff, it
>> allows TSYNC, it's totally independent of systemwide policy, etc.
>>
>> Trying to use cgroups or similar for this is going to be much nastier.
>> Some tighter sandboxes (Sandstorm, etc) aren't even going to dream of
>> putting cgroupfs in their containers, so requiring cgroups or similar
>> would be a mess for that type of application.
>
> I don't see why it is a 'mess'. cgroups are already used by majority
> of the systems, so I don't see why requiring a cgroup is such a big deal.

Requiring cgroup to be configured in isn't a big deal.  Requiring

> But let's say we don't do them. How implementation is going to look like
> for task based hierarchy? Note that we need an array of bpf_prog pointers.
> One for each lsm hook. Where this array is going to be stored?
> We cannot put in task_struct, since it's too large. Cannot put it
> into 'struct seccomp' directly either, unless it will become a pointer.
> Is that the proposal?

It would go in struct seccomp_filter or in something pointed to from there.

> So now we will be wasting extra 1kbyte of memory per task. Not great.
> We'd want to optimize it by sharing this such struct seccomp with prog array
> across threads of the same task? Or dynimically allocating it when
> landlock is in use? May sound nice, but how to account for that kernel
> memory? I guess also solvable by charging memlock.
> With cgroup based approach we don't need to worry about all that.
>

The considerations are essentially identical either way.

With cgroups, if you want to share the memory between multiple
separate sandboxes (Firejail instances, Sandstorm grains, Chromium
instances, xdg-apps, etc), you'd need to get them to all coordinate to
share a cgroup.  With a seccomp-like interface, you'd need to get them
to coordinate to share an installed layer (using my FD idea or
similar).

There would *not* be any duplication of this memory just because a
sandboxed process called fork().

--Andy

-- 
Andy Lutomirski
AMA Capital Management, LLC

Re: [PATCH] pstore/ramoops: fixup driver removal

[Namhyung Kim]

(Resending with all recipients, sorry)

On Sat, Aug 20, 2016 at 1:52 AM, Sebastian Andrzej Siewior
 wrote:
> A basic rmmod ramoops segfaults. Let's see why.
>
> Since commit 34f0ec82e0a9 ("pstore: Correct the max_dump_cnt clearing of
> ramoops") sets ->max_dump_cnt to zero before looping over ->przs but we
> didn't use it before that either.
>
> And since commit ee1d267423a1 ("pstore: add pstore unregister") we free
> that memory on rmmod.
>
> But even then, we looped until a NULL pointer or ERR. I don't see where
> it is ensured that the last member is NULL. Let's try this instead:
> simply error recovery and free. Clean up in error case where ressouces
> were allocated. And then, in the free path, rely on ->max_dump_cnt in
> the free path.
>
> Cc: Anton Vorontsov 
> Cc: Colin Cross 
> Cc: Kees Cook 
> Cc: Tony Luck 
> Signed-off-by: Sebastian Andrzej Siewior 

Fwiw,

Acked-by: Namhyung Kim 

Thanks,
Namhyung


> ---
>
> Not sure if I miss something obvious or not.
>
>  fs/pstore/ram.c | 17 -
>  1 file changed, 12 insertions(+), 5 deletions(-)
>
> diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
> index 7a034d62cf8c..2340262a7e97 100644
> --- a/fs/pstore/ram.c
> +++ b/fs/pstore/ram.c
> @@ -377,13 +377,14 @@ static void ramoops_free_przs(struct ramoops_context 
> *cxt)
>  {
> int i;
>
> -   cxt->max_dump_cnt = 0;
> if (!cxt->przs)
> return;
>
> -   for (i = 0; !IS_ERR_OR_NULL(cxt->przs[i]); i++)
> +   for (i = 0; i < cxt->max_dump_cnt; i++)
> persistent_ram_free(cxt->przs[i]);
> +
> kfree(cxt->przs);
> +   cxt->max_dump_cnt = 0;
>  }
>
>  static int ramoops_init_przs(struct device *dev, struct ramoops_context *cxt,
> @@ -408,7 +409,7 @@ static int ramoops_init_przs(struct device *dev, struct 
> ramoops_context *cxt,
>  GFP_KERNEL);
> if (!cxt->przs) {
> dev_err(dev, "failed to initialize a prz array for dumps\n");
> -   goto fail_prz;
> +   goto fail_mem;
> }
>
> for (i = 0; i < cxt->max_dump_cnt; i++) {
> @@ -419,6 +420,11 @@ static int ramoops_init_przs(struct device *dev, struct 
> ramoops_context *cxt,
> err = PTR_ERR(cxt->przs[i]);
> dev_err(dev, "failed to request mem region 
> (0x%zx@0x%llx): %d\n",
> cxt->record_size, (unsigned long long)*paddr, 
> err);
> +
> +   while (i > 0) {
> +   i--;
> +   persistent_ram_free(cxt->przs[i]);
> +   }
> goto fail_prz;
> }
> *paddr += cxt->record_size;
> @@ -426,7 +432,9 @@ static int ramoops_init_przs(struct device *dev, struct 
> ramoops_context *cxt,
>
> return 0;
>  fail_prz:
> -   ramoops_free_przs(cxt);
> +   kfree(cxt->przs);
> +fail_mem:
> +   cxt->max_dump_cnt = 0;
> return err;
>  }
>
> @@ -659,7 +667,6 @@ static int ramoops_remove(struct platform_device *pdev)
> struct ramoops_context *cxt = _cxt;
>
> pstore_unregister(>pstore);
> -   cxt->max_dump_cnt = 0;
>
> kfree(cxt->pstore.buf);
> cxt->pstore.bufsize = 0;
> --
> 2.9.3
>

Re: [PATCH] sparc64 mm: Fix more TSB sizing issues

[Mike Kravetz]

On 08/30/2016 03:51 PM, kbuild test robot wrote:
> Hi Mike,
> 
> [auto build test ERROR on sparc/master]
> [also build test ERROR on v4.8-rc4 next-20160825]
> [cannot apply to sparc-next/master]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improve the system]
> [Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for 
> convenience) to record what (public, well-known) commit your patch series was 
> built on]
> [Check https://git-scm.com/docs/git-format-patch for more information]

Ugh!  I'll send a V2 patch with the non-hugepage/non-thp build error fixed.
I'd really like to fix this without adding another #ifdef to the routine.

-- 
Mike Kravetz

> 
> url:
> https://github.com/0day-ci/linux/commits/Mike-Kravetz/sparc64-mm-Fix-more-TSB-sizing-issues/20160831-054025
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc.git master
> config: sparc64-allnoconfig (attached as .config)
> compiler: sparc64-linux-gnu-gcc (Debian 5.4.0-6) 5.4.0 20160609
> reproduce:
> wget 
> https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
>  -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> make.cross ARCH=sparc64 
> 
> All errors (new ones prefixed by >>):
> 
>arch/sparc/mm/tsb.c: In function 'init_new_context':
>>> arch/sparc/mm/tsb.c:504:4: error: 'saved_thp_pte_count' undeclared (first 
>>> use in this function)
>saved_thp_pte_count * (HPAGE_SIZE / PAGE_SIZE));
>^
>arch/sparc/mm/tsb.c:504:4: note: each undeclared identifier is reported 
> only once for each function it appears in
>>> arch/sparc/mm/tsb.c:504:27: error: 'HPAGE_SIZE' undeclared (first use in 
>>> this function)
>saved_thp_pte_count * (HPAGE_SIZE / PAGE_SIZE));
>   ^
> 
> vim +/saved_thp_pte_count +504 arch/sparc/mm/tsb.c
> 
>498mm->context.tsb_block[i].tsb = NULL;
>499
>500/* If this is fork, inherit the parent's TSB size.  We 
> would
>501 * grow it to that size on the first page fault anyways.
>502 */
>503tsb_grow(mm, MM_TSB_BASE, get_mm_rss(mm) -
>  > 504 saved_thp_pte_count * (HPAGE_SIZE / 
> PAGE_SIZE));
>505
>506#if defined(CONFIG_HUGETLB_PAGE) || 
> defined(CONFIG_TRANSPARENT_HUGEPAGE)
>507if (unlikely(saved_hugetlb_pte_count + 
> saved_thp_pte_count))
> 
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all   Intel Corporation
> 

Re: [PATCH] pstore/ramoops: fixup driver removal

[Namhyung Kim]

(Resending with all recipients, sorry)

On Sat, Aug 20, 2016 at 1:52 AM, Sebastian Andrzej Siewior
 wrote:
> A basic rmmod ramoops segfaults. Let's see why.
>
> Since commit 34f0ec82e0a9 ("pstore: Correct the max_dump_cnt clearing of
> ramoops") sets ->max_dump_cnt to zero before looping over ->przs but we
> didn't use it before that either.
>
> And since commit ee1d267423a1 ("pstore: add pstore unregister") we free
> that memory on rmmod.
>
> But even then, we looped until a NULL pointer or ERR. I don't see where
> it is ensured that the last member is NULL. Let's try this instead:
> simply error recovery and free. Clean up in error case where ressouces
> were allocated. And then, in the free path, rely on ->max_dump_cnt in
> the free path.
>
> Cc: Anton Vorontsov 
> Cc: Colin Cross 
> Cc: Kees Cook 
> Cc: Tony Luck 
> Signed-off-by: Sebastian Andrzej Siewior 

Fwiw,

Acked-by: Namhyung Kim 

Thanks,
Namhyung


> ---
>
> Not sure if I miss something obvious or not.
>
>  fs/pstore/ram.c | 17 -
>  1 file changed, 12 insertions(+), 5 deletions(-)
>
> diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
> index 7a034d62cf8c..2340262a7e97 100644
> --- a/fs/pstore/ram.c
> +++ b/fs/pstore/ram.c
> @@ -377,13 +377,14 @@ static void ramoops_free_przs(struct ramoops_context 
> *cxt)
>  {
> int i;
>
> -   cxt->max_dump_cnt = 0;
> if (!cxt->przs)
> return;
>
> -   for (i = 0; !IS_ERR_OR_NULL(cxt->przs[i]); i++)
> +   for (i = 0; i < cxt->max_dump_cnt; i++)
> persistent_ram_free(cxt->przs[i]);
> +
> kfree(cxt->przs);
> +   cxt->max_dump_cnt = 0;
>  }
>
>  static int ramoops_init_przs(struct device *dev, struct ramoops_context *cxt,
> @@ -408,7 +409,7 @@ static int ramoops_init_przs(struct device *dev, struct 
> ramoops_context *cxt,
>  GFP_KERNEL);
> if (!cxt->przs) {
> dev_err(dev, "failed to initialize a prz array for dumps\n");
> -   goto fail_prz;
> +   goto fail_mem;
> }
>
> for (i = 0; i < cxt->max_dump_cnt; i++) {
> @@ -419,6 +420,11 @@ static int ramoops_init_przs(struct device *dev, struct 
> ramoops_context *cxt,
> err = PTR_ERR(cxt->przs[i]);
> dev_err(dev, "failed to request mem region 
> (0x%zx@0x%llx): %d\n",
> cxt->record_size, (unsigned long long)*paddr, 
> err);
> +
> +   while (i > 0) {
> +   i--;
> +   persistent_ram_free(cxt->przs[i]);
> +   }
> goto fail_prz;
> }
> *paddr += cxt->record_size;
> @@ -426,7 +432,9 @@ static int ramoops_init_przs(struct device *dev, struct 
> ramoops_context *cxt,
>
> return 0;
>  fail_prz:
> -   ramoops_free_przs(cxt);
> +   kfree(cxt->przs);
> +fail_mem:
> +   cxt->max_dump_cnt = 0;
> return err;
>  }
>
> @@ -659,7 +667,6 @@ static int ramoops_remove(struct platform_device *pdev)
> struct ramoops_context *cxt = _cxt;
>
> pstore_unregister(>pstore);
> -   cxt->max_dump_cnt = 0;
>
> kfree(cxt->pstore.buf);
> cxt->pstore.bufsize = 0;
> --
> 2.9.3
>

Re: [PATCH] sparc64 mm: Fix more TSB sizing issues

[Mike Kravetz]

On 08/30/2016 03:51 PM, kbuild test robot wrote:
> Hi Mike,
> 
> [auto build test ERROR on sparc/master]
> [also build test ERROR on v4.8-rc4 next-20160825]
> [cannot apply to sparc-next/master]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improve the system]
> [Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for 
> convenience) to record what (public, well-known) commit your patch series was 
> built on]
> [Check https://git-scm.com/docs/git-format-patch for more information]

Ugh!  I'll send a V2 patch with the non-hugepage/non-thp build error fixed.
I'd really like to fix this without adding another #ifdef to the routine.

-- 
Mike Kravetz

> 
> url:
> https://github.com/0day-ci/linux/commits/Mike-Kravetz/sparc64-mm-Fix-more-TSB-sizing-issues/20160831-054025
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc.git master
> config: sparc64-allnoconfig (attached as .config)
> compiler: sparc64-linux-gnu-gcc (Debian 5.4.0-6) 5.4.0 20160609
> reproduce:
> wget 
> https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
>  -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> make.cross ARCH=sparc64 
> 
> All errors (new ones prefixed by >>):
> 
>arch/sparc/mm/tsb.c: In function 'init_new_context':
>>> arch/sparc/mm/tsb.c:504:4: error: 'saved_thp_pte_count' undeclared (first 
>>> use in this function)
>saved_thp_pte_count * (HPAGE_SIZE / PAGE_SIZE));
>^
>arch/sparc/mm/tsb.c:504:4: note: each undeclared identifier is reported 
> only once for each function it appears in
>>> arch/sparc/mm/tsb.c:504:27: error: 'HPAGE_SIZE' undeclared (first use in 
>>> this function)
>saved_thp_pte_count * (HPAGE_SIZE / PAGE_SIZE));
>   ^
> 
> vim +/saved_thp_pte_count +504 arch/sparc/mm/tsb.c
> 
>498mm->context.tsb_block[i].tsb = NULL;
>499
>500/* If this is fork, inherit the parent's TSB size.  We 
> would
>501 * grow it to that size on the first page fault anyways.
>502 */
>503tsb_grow(mm, MM_TSB_BASE, get_mm_rss(mm) -
>  > 504 saved_thp_pte_count * (HPAGE_SIZE / 
> PAGE_SIZE));
>505
>506#if defined(CONFIG_HUGETLB_PAGE) || 
> defined(CONFIG_TRANSPARENT_HUGEPAGE)
>507if (unlikely(saved_hugetlb_pte_count + 
> saved_thp_pte_count))
> 
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all   Intel Corporation
> 

[PATCH 1/2] mm: Move definition of 'zone_names' array into mmzone.h

[Anshuman Khandual]

zone_names[] is used to identify any zone given it's index which
can be used in many other places. So moving the definition into
include/linux/mmzone.h for broader access.

Signed-off-by: Anshuman Khandual 
---
 include/linux/mmzone.h | 17 +
 mm/page_alloc.c| 17 -
 2 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index d572b78..01ca3f4 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -341,6 +341,23 @@ enum zone_type {
 
 };
 
+static char * const zone_names[__MAX_NR_ZONES] = {
+#ifdef CONFIG_ZONE_DMA
+"DMA",
+#endif
+#ifdef CONFIG_ZONE_DMA32
+"DMA32",
+#endif
+"Normal",
+#ifdef CONFIG_HIGHMEM
+"HighMem",
+#endif
+"Movable",
+#ifdef CONFIG_ZONE_DEVICE
+"Device",
+#endif
+};
+
 #ifndef __GENERATING_BOUNDS_H
 
 struct zone {
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 3fbe73a..8e2261c 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -207,23 +207,6 @@ int sysctl_lowmem_reserve_ratio[MAX_NR_ZONES-1] = {
 
 EXPORT_SYMBOL(totalram_pages);
 
-static char * const zone_names[MAX_NR_ZONES] = {
-#ifdef CONFIG_ZONE_DMA
-"DMA",
-#endif
-#ifdef CONFIG_ZONE_DMA32
-"DMA32",
-#endif
-"Normal",
-#ifdef CONFIG_HIGHMEM
-"HighMem",
-#endif
-"Movable",
-#ifdef CONFIG_ZONE_DEVICE
-"Device",
-#endif
-};
-
 char * const migratetype_names[MIGRATE_TYPES] = {
"Unmovable",
"Movable",
-- 
1.9.3

[PATCH 2/2] mm: Add sysfs interface to dump each node's zonelist information

[Anshuman Khandual]

Each individual node in the system has a ZONELIST_FALLBACK zonelist
and a ZONELIST_NOFALLBACK zonelist. These zonelists decide fallback
order of zones during memory allocations. Sometimes it helps to dump
these zonelists to see the priority order of various zones in them.
This change just adds a sysfs interface for doing the same.

Example zonelist information from a KVM guest.

[NODE (0)]
ZONELIST_FALLBACK
(0) (node 0) (zone DMA c140c000)
(1) (node 1) (zone DMA c001)
(2) (node 2) (zone DMA c002)
(3) (node 3) (zone DMA c003)
ZONELIST_NOFALLBACK
(0) (node 0) (zone DMA c140c000)
[NODE (1)]
ZONELIST_FALLBACK
(0) (node 1) (zone DMA c001)
(1) (node 2) (zone DMA c002)
(2) (node 3) (zone DMA c003)
(3) (node 0) (zone DMA c140c000)
ZONELIST_NOFALLBACK
(0) (node 1) (zone DMA c001)
[NODE (2)]
ZONELIST_FALLBACK
(0) (node 2) (zone DMA c002)
(1) (node 3) (zone DMA c003)
(2) (node 0) (zone DMA c140c000)
(3) (node 1) (zone DMA c001)
ZONELIST_NOFALLBACK
(0) (node 2) (zone DMA c002)
[NODE (3)]
ZONELIST_FALLBACK
(0) (node 3) (zone DMA c003)
(1) (node 0) (zone DMA c140c000)
(2) (node 1) (zone DMA c001)
(3) (node 2) (zone DMA c002)
ZONELIST_NOFALLBACK
(0) (node 3) (zone DMA c003)

Signed-off-by: Anshuman Khandual 
---
 drivers/base/memory.c | 46 ++
 1 file changed, 46 insertions(+)

diff --git a/drivers/base/memory.c b/drivers/base/memory.c
index dc75de9..8c9330a 100644
--- a/drivers/base/memory.c
+++ b/drivers/base/memory.c
@@ -442,7 +442,52 @@ print_block_size(struct device *dev, struct 
device_attribute *attr,
return sprintf(buf, "%lx\n", get_memory_block_size());
 }
 
+static ssize_t dump_zonelist(char *buf, struct zonelist *zonelist)
+{
+   unsigned int i;
+   ssize_t count = 0;
+
+   for (i = 0; zonelist->_zonerefs[i].zone; i++) {
+   count += sprintf(buf + count,
+   "\t\t(%d) (node %d) (%-10s %lx)\n", i,
+   zonelist->_zonerefs[i].zone->zone_pgdat->node_id,
+   zone_names[zonelist->_zonerefs[i].zone_idx],
+   (unsigned long) zonelist->_zonerefs[i].zone);
+   }
+   return count;
+}
+
+static ssize_t dump_zonelists(char *buf)
+{
+   struct zonelist *zonelist;
+   unsigned int node;
+   ssize_t count = 0;
+
+   for_each_online_node(node) {
+   zonelist = &(NODE_DATA(node)->
+   node_zonelists[ZONELIST_FALLBACK]);
+   count += sprintf(buf + count, "[NODE (%d)]\n", node);
+   count += sprintf(buf + count, "\tZONELIST_FALLBACK\n");
+   count += dump_zonelist(buf + count, zonelist);
+
+   zonelist = &(NODE_DATA(node)->
+   node_zonelists[ZONELIST_NOFALLBACK]);
+   count += sprintf(buf + count, "\tZONELIST_NOFALLBACK\n");
+   count += dump_zonelist(buf + count, zonelist);
+   }
+   return count;
+}
+
+static ssize_t
+print_system_zone_details(struct device *dev, struct device_attribute *attr,
+char *buf)
+{
+   return dump_zonelists(buf);
+}
+
+
 static DEVICE_ATTR(block_size_bytes, 0444, print_block_size, NULL);
+static DEVICE_ATTR(system_zone_details, 0444, print_system_zone_details, NULL);
 
 /*
  * Memory auto online policy.
@@ -783,6 +828,7 @@ static struct attribute *memory_root_attrs[] = {
 #endif
 
_attr_block_size_bytes.attr,
+   _attr_system_zone_details.attr,
_attr_auto_online_blocks.attr,
NULL
 };
-- 
1.9.3

[PATCH 1/2] mm: Move definition of 'zone_names' array into mmzone.h

[Anshuman Khandual]

zone_names[] is used to identify any zone given it's index which
can be used in many other places. So moving the definition into
include/linux/mmzone.h for broader access.

Signed-off-by: Anshuman Khandual 
---
 include/linux/mmzone.h | 17 +
 mm/page_alloc.c| 17 -
 2 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index d572b78..01ca3f4 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -341,6 +341,23 @@ enum zone_type {
 
 };
 
+static char * const zone_names[__MAX_NR_ZONES] = {
+#ifdef CONFIG_ZONE_DMA
+"DMA",
+#endif
+#ifdef CONFIG_ZONE_DMA32
+"DMA32",
+#endif
+"Normal",
+#ifdef CONFIG_HIGHMEM
+"HighMem",
+#endif
+"Movable",
+#ifdef CONFIG_ZONE_DEVICE
+"Device",
+#endif
+};
+
 #ifndef __GENERATING_BOUNDS_H
 
 struct zone {
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 3fbe73a..8e2261c 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -207,23 +207,6 @@ int sysctl_lowmem_reserve_ratio[MAX_NR_ZONES-1] = {
 
 EXPORT_SYMBOL(totalram_pages);
 
-static char * const zone_names[MAX_NR_ZONES] = {
-#ifdef CONFIG_ZONE_DMA
-"DMA",
-#endif
-#ifdef CONFIG_ZONE_DMA32
-"DMA32",
-#endif
-"Normal",
-#ifdef CONFIG_HIGHMEM
-"HighMem",
-#endif
-"Movable",
-#ifdef CONFIG_ZONE_DEVICE
-"Device",
-#endif
-};
-
 char * const migratetype_names[MIGRATE_TYPES] = {
"Unmovable",
"Movable",
-- 
1.9.3

[PATCH 2/2] mm: Add sysfs interface to dump each node's zonelist information

[Anshuman Khandual]

Each individual node in the system has a ZONELIST_FALLBACK zonelist
and a ZONELIST_NOFALLBACK zonelist. These zonelists decide fallback
order of zones during memory allocations. Sometimes it helps to dump
these zonelists to see the priority order of various zones in them.
This change just adds a sysfs interface for doing the same.

Example zonelist information from a KVM guest.

[NODE (0)]
ZONELIST_FALLBACK
(0) (node 0) (zone DMA c140c000)
(1) (node 1) (zone DMA c001)
(2) (node 2) (zone DMA c002)
(3) (node 3) (zone DMA c003)
ZONELIST_NOFALLBACK
(0) (node 0) (zone DMA c140c000)
[NODE (1)]
ZONELIST_FALLBACK
(0) (node 1) (zone DMA c001)
(1) (node 2) (zone DMA c002)
(2) (node 3) (zone DMA c003)
(3) (node 0) (zone DMA c140c000)
ZONELIST_NOFALLBACK
(0) (node 1) (zone DMA c001)
[NODE (2)]
ZONELIST_FALLBACK
(0) (node 2) (zone DMA c002)
(1) (node 3) (zone DMA c003)
(2) (node 0) (zone DMA c140c000)
(3) (node 1) (zone DMA c001)
ZONELIST_NOFALLBACK
(0) (node 2) (zone DMA c002)
[NODE (3)]
ZONELIST_FALLBACK
(0) (node 3) (zone DMA c003)
(1) (node 0) (zone DMA c140c000)
(2) (node 1) (zone DMA c001)
(3) (node 2) (zone DMA c002)
ZONELIST_NOFALLBACK
(0) (node 3) (zone DMA c003)

Signed-off-by: Anshuman Khandual 
---
 drivers/base/memory.c | 46 ++
 1 file changed, 46 insertions(+)

diff --git a/drivers/base/memory.c b/drivers/base/memory.c
index dc75de9..8c9330a 100644
--- a/drivers/base/memory.c
+++ b/drivers/base/memory.c
@@ -442,7 +442,52 @@ print_block_size(struct device *dev, struct 
device_attribute *attr,
return sprintf(buf, "%lx\n", get_memory_block_size());
 }
 
+static ssize_t dump_zonelist(char *buf, struct zonelist *zonelist)
+{
+   unsigned int i;
+   ssize_t count = 0;
+
+   for (i = 0; zonelist->_zonerefs[i].zone; i++) {
+   count += sprintf(buf + count,
+   "\t\t(%d) (node %d) (%-10s %lx)\n", i,
+   zonelist->_zonerefs[i].zone->zone_pgdat->node_id,
+   zone_names[zonelist->_zonerefs[i].zone_idx],
+   (unsigned long) zonelist->_zonerefs[i].zone);
+   }
+   return count;
+}
+
+static ssize_t dump_zonelists(char *buf)
+{
+   struct zonelist *zonelist;
+   unsigned int node;
+   ssize_t count = 0;
+
+   for_each_online_node(node) {
+   zonelist = &(NODE_DATA(node)->
+   node_zonelists[ZONELIST_FALLBACK]);
+   count += sprintf(buf + count, "[NODE (%d)]\n", node);
+   count += sprintf(buf + count, "\tZONELIST_FALLBACK\n");
+   count += dump_zonelist(buf + count, zonelist);
+
+   zonelist = &(NODE_DATA(node)->
+   node_zonelists[ZONELIST_NOFALLBACK]);
+   count += sprintf(buf + count, "\tZONELIST_NOFALLBACK\n");
+   count += dump_zonelist(buf + count, zonelist);
+   }
+   return count;
+}
+
+static ssize_t
+print_system_zone_details(struct device *dev, struct device_attribute *attr,
+char *buf)
+{
+   return dump_zonelists(buf);
+}
+
+
 static DEVICE_ATTR(block_size_bytes, 0444, print_block_size, NULL);
+static DEVICE_ATTR(system_zone_details, 0444, print_system_zone_details, NULL);
 
 /*
  * Memory auto online policy.
@@ -783,6 +828,7 @@ static struct attribute *memory_root_attrs[] = {
 #endif
 
_attr_block_size_bytes.attr,
+   _attr_system_zone_details.attr,
_attr_auto_online_blocks.attr,
NULL
 };
-- 
1.9.3

Re: [PATCH v9 1/2] ASoC: sun4i-codec: Distinguish sun4i from sun7i

[Chen-Yu Tsai]

On Tue, Aug 30, 2016 at 1:44 PM, Danny Milosavljevic
 wrote:
> This distinguishes sun4i from sun7i. It is necessary because they use
> different registers for the audio mixer.
> ---
>  sound/soc/sunxi/sun4i-codec.c | 44 
> +--
>  1 file changed, 34 insertions(+), 10 deletions(-)
>
> diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
> index 0e19c50..30f4ea2 100644
> --- a/sound/soc/sunxi/sun4i-codec.c
> +++ b/sound/soc/sunxi/sun4i-codec.c
> @@ -96,8 +96,9 @@
>  /* Other various ADC registers */
>  #define SUN4I_CODEC_DAC_TXCNT  (0x30)
>  #define SUN4I_CODEC_ADC_RXCNT  (0x34)
> -#define SUN4I_CODEC_AC_SYS_VERI(0x38)
> -#define SUN4I_CODEC_AC_MIC_PHONE_CAL   (0x3c)
> +
> +#define SUN7I_CODEC_AC_DAC_CAL (0x38)
> +#define SUN7I_CODEC_AC_MIC_PHONE_CAL   (0x3c)
>
>  struct sun4i_codec {
> struct device   *dev;
> @@ -509,10 +510,17 @@ static const struct snd_kcontrol_new 
> sun4i_codec_pa_mute =
>
>  static DECLARE_TLV_DB_SCALE(sun4i_codec_pa_volume_scale, -6300, 100, 1);
>
> -static const struct snd_kcontrol_new sun4i_codec_widgets[] = {
> -   SOC_SINGLE_TLV("Power Amplifier Volume", SUN4I_CODEC_DAC_ACTL,
> -  SUN4I_CODEC_DAC_ACTL_PA_VOL, 0x3F, 0,
> -  sun4i_codec_pa_volume_scale),
> +#define SUN4I_COMMON_CODEC_CONTROLS \
> +   SOC_SINGLE_TLV("Power Amplifier Volume", SUN4I_CODEC_DAC_ACTL,\
> +  SUN4I_CODEC_DAC_ACTL_PA_VOL, 0x3F, 0,\
> +  sun4i_codec_pa_volume_scale)

This is slightly worrying. It will get messy as you add more widgets.

> +
> +static const struct snd_kcontrol_new sun4i_codec_controls[] = {
> +   SUN4I_COMMON_CODEC_CONTROLS,
> +};
> +
> +static const struct snd_kcontrol_new sun7i_codec_controls[] = {
> +   SUN4I_COMMON_CODEC_CONTROLS,
>  };
>
>  static const struct snd_kcontrol_new sun4i_codec_left_mixer_controls[] = {
> @@ -629,8 +637,18 @@ static const struct snd_soc_dapm_route 
> sun4i_codec_codec_dapm_routes[] = {
>
>  static struct snd_soc_codec_driver sun4i_codec_codec = {
> .component_driver = {
> -   .controls   = sun4i_codec_widgets,
> -   .num_controls   = ARRAY_SIZE(sun4i_codec_widgets),
> +   .controls   = sun4i_codec_controls,
> +   .num_controls   = ARRAY_SIZE(sun4i_codec_controls),
> +   .dapm_widgets   = sun4i_codec_codec_dapm_widgets,
> +   .num_dapm_widgets   = 
> ARRAY_SIZE(sun4i_codec_codec_dapm_widgets),
> +   .dapm_routes= sun4i_codec_codec_dapm_routes,
> +   .num_dapm_routes= 
> ARRAY_SIZE(sun4i_codec_codec_dapm_routes),
> +   },
> +};
> +static struct snd_soc_codec_driver sun7i_codec_codec = {
> +   .component_driver = {
> +   .controls   = sun7i_codec_controls,
> +   .num_controls   = ARRAY_SIZE(sun7i_codec_controls),
> .dapm_widgets   = sun4i_codec_codec_dapm_widgets,
> .num_dapm_widgets   = 
> ARRAY_SIZE(sun4i_codec_codec_dapm_widgets),
> .dapm_routes= sun4i_codec_codec_dapm_routes,
> @@ -682,7 +700,7 @@ static const struct regmap_config 
> sun4i_codec_regmap_config = {
> .reg_bits   = 32,
> .reg_stride = 4,
> .val_bits   = 32,
> -   .max_register   = SUN4I_CODEC_AC_MIC_PHONE_CAL,
> +   .max_register   = SUN7I_CODEC_AC_MIC_PHONE_CAL,
>  };

On sun4i the registers only go as far as SUN4I_CODEC_ADC_RXCNT.
Could you add a separate regmap_config as well?

>
>  static const struct of_device_id sun4i_codec_of_match[] = {
> @@ -760,6 +778,7 @@ static int sun4i_codec_probe(struct platform_device *pdev)
>  {
> struct snd_soc_card *card;
> struct sun4i_codec *scodec;
> +   struct snd_soc_codec_driver *codec;
> struct resource *res;
> void __iomem *base;
> int ret;
> @@ -822,7 +841,12 @@ static int sun4i_codec_probe(struct platform_device 
> *pdev)
> scodec->capture_dma_data.maxburst = 4;
> scodec->capture_dma_data.addr_width = DMA_SLAVE_BUSWIDTH_2_BYTES;
>
> -   ret = snd_soc_register_codec(>dev, _codec_codec,
> +   if (of_device_is_compatible(pdev->dev.of_node,
> +   "allwinner,sun7i-a20-codec"))
> +   codec = _codec_codec;
> +   else
> +   codec = _codec_codec;
> +   ret = snd_soc_register_codec(>dev, codec,

This will get reworked into something like in

https://github.com/wens/linux/commit/54a58e3087fb67572ca416256bc000e08b163480

I haven't gotten around to posting this series yet though.

ChenYu

>  _codec_dai, 1);
> if (ret) {
> dev_err(>dev, "Failed to register our 

Re: [PATCH v9 1/2] ASoC: sun4i-codec: Distinguish sun4i from sun7i

[Chen-Yu Tsai]

On Tue, Aug 30, 2016 at 1:44 PM, Danny Milosavljevic
 wrote:
> This distinguishes sun4i from sun7i. It is necessary because they use
> different registers for the audio mixer.
> ---
>  sound/soc/sunxi/sun4i-codec.c | 44 
> +--
>  1 file changed, 34 insertions(+), 10 deletions(-)
>
> diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
> index 0e19c50..30f4ea2 100644
> --- a/sound/soc/sunxi/sun4i-codec.c
> +++ b/sound/soc/sunxi/sun4i-codec.c
> @@ -96,8 +96,9 @@
>  /* Other various ADC registers */
>  #define SUN4I_CODEC_DAC_TXCNT  (0x30)
>  #define SUN4I_CODEC_ADC_RXCNT  (0x34)
> -#define SUN4I_CODEC_AC_SYS_VERI(0x38)
> -#define SUN4I_CODEC_AC_MIC_PHONE_CAL   (0x3c)
> +
> +#define SUN7I_CODEC_AC_DAC_CAL (0x38)
> +#define SUN7I_CODEC_AC_MIC_PHONE_CAL   (0x3c)
>
>  struct sun4i_codec {
> struct device   *dev;
> @@ -509,10 +510,17 @@ static const struct snd_kcontrol_new 
> sun4i_codec_pa_mute =
>
>  static DECLARE_TLV_DB_SCALE(sun4i_codec_pa_volume_scale, -6300, 100, 1);
>
> -static const struct snd_kcontrol_new sun4i_codec_widgets[] = {
> -   SOC_SINGLE_TLV("Power Amplifier Volume", SUN4I_CODEC_DAC_ACTL,
> -  SUN4I_CODEC_DAC_ACTL_PA_VOL, 0x3F, 0,
> -  sun4i_codec_pa_volume_scale),
> +#define SUN4I_COMMON_CODEC_CONTROLS \
> +   SOC_SINGLE_TLV("Power Amplifier Volume", SUN4I_CODEC_DAC_ACTL,\
> +  SUN4I_CODEC_DAC_ACTL_PA_VOL, 0x3F, 0,\
> +  sun4i_codec_pa_volume_scale)

This is slightly worrying. It will get messy as you add more widgets.

> +
> +static const struct snd_kcontrol_new sun4i_codec_controls[] = {
> +   SUN4I_COMMON_CODEC_CONTROLS,
> +};
> +
> +static const struct snd_kcontrol_new sun7i_codec_controls[] = {
> +   SUN4I_COMMON_CODEC_CONTROLS,
>  };
>
>  static const struct snd_kcontrol_new sun4i_codec_left_mixer_controls[] = {
> @@ -629,8 +637,18 @@ static const struct snd_soc_dapm_route 
> sun4i_codec_codec_dapm_routes[] = {
>
>  static struct snd_soc_codec_driver sun4i_codec_codec = {
> .component_driver = {
> -   .controls   = sun4i_codec_widgets,
> -   .num_controls   = ARRAY_SIZE(sun4i_codec_widgets),
> +   .controls   = sun4i_codec_controls,
> +   .num_controls   = ARRAY_SIZE(sun4i_codec_controls),
> +   .dapm_widgets   = sun4i_codec_codec_dapm_widgets,
> +   .num_dapm_widgets   = 
> ARRAY_SIZE(sun4i_codec_codec_dapm_widgets),
> +   .dapm_routes= sun4i_codec_codec_dapm_routes,
> +   .num_dapm_routes= 
> ARRAY_SIZE(sun4i_codec_codec_dapm_routes),
> +   },
> +};
> +static struct snd_soc_codec_driver sun7i_codec_codec = {
> +   .component_driver = {
> +   .controls   = sun7i_codec_controls,
> +   .num_controls   = ARRAY_SIZE(sun7i_codec_controls),
> .dapm_widgets   = sun4i_codec_codec_dapm_widgets,
> .num_dapm_widgets   = 
> ARRAY_SIZE(sun4i_codec_codec_dapm_widgets),
> .dapm_routes= sun4i_codec_codec_dapm_routes,
> @@ -682,7 +700,7 @@ static const struct regmap_config 
> sun4i_codec_regmap_config = {
> .reg_bits   = 32,
> .reg_stride = 4,
> .val_bits   = 32,
> -   .max_register   = SUN4I_CODEC_AC_MIC_PHONE_CAL,
> +   .max_register   = SUN7I_CODEC_AC_MIC_PHONE_CAL,
>  };

On sun4i the registers only go as far as SUN4I_CODEC_ADC_RXCNT.
Could you add a separate regmap_config as well?

>
>  static const struct of_device_id sun4i_codec_of_match[] = {
> @@ -760,6 +778,7 @@ static int sun4i_codec_probe(struct platform_device *pdev)
>  {
> struct snd_soc_card *card;
> struct sun4i_codec *scodec;
> +   struct snd_soc_codec_driver *codec;
> struct resource *res;
> void __iomem *base;
> int ret;
> @@ -822,7 +841,12 @@ static int sun4i_codec_probe(struct platform_device 
> *pdev)
> scodec->capture_dma_data.maxburst = 4;
> scodec->capture_dma_data.addr_width = DMA_SLAVE_BUSWIDTH_2_BYTES;
>
> -   ret = snd_soc_register_codec(>dev, _codec_codec,
> +   if (of_device_is_compatible(pdev->dev.of_node,
> +   "allwinner,sun7i-a20-codec"))
> +   codec = _codec_codec;
> +   else
> +   codec = _codec_codec;
> +   ret = snd_soc_register_codec(>dev, codec,

This will get reworked into something like in

https://github.com/wens/linux/commit/54a58e3087fb67572ca416256bc000e08b163480

I haven't gotten around to posting this series yet though.

ChenYu

>  _codec_dai, 1);
> if (ret) {
> dev_err(>dev, "Failed to register our codec\n");

Re: [GIT PULL] bcm2835-dt-next-2016-08-29

[Florian Fainelli]

Le 29/08/2016 à 12:38, Eric Anholt a écrit :
> The following changes since commit 29b4817d4018df78086157ea3a55c1d9424a7cfc:
> 
>   Linux 4.8-rc1 (2016-08-07 18:18:00 -0700)
> 
> are available in the git repository at:
> 
>   https://github.com/anholt/linux bcm2835-dt-next-2016-08-29
> 
> for you to fetch changes up to c8336249c1eeca288919e3286f7dd03ae1d8ceae:
> 
>   ARM: dts: bcm2835: Add Raspberry Pi Zero (2016-08-24 13:33:19 -0700)
> 
> 
> This pull request brings in support for Raspberry Pi Zero.

Merged thanks Eric!
-- 
Florian



signature.asc
Description: OpenPGP digital signature

Re: [GIT PULL] bcm2835-dt-next-2016-08-29

[Florian Fainelli]

Le 29/08/2016 à 12:38, Eric Anholt a écrit :
> The following changes since commit 29b4817d4018df78086157ea3a55c1d9424a7cfc:
> 
>   Linux 4.8-rc1 (2016-08-07 18:18:00 -0700)
> 
> are available in the git repository at:
> 
>   https://github.com/anholt/linux bcm2835-dt-next-2016-08-29
> 
> for you to fetch changes up to c8336249c1eeca288919e3286f7dd03ae1d8ceae:
> 
>   ARM: dts: bcm2835: Add Raspberry Pi Zero (2016-08-24 13:33:19 -0700)
> 
> 
> This pull request brings in support for Raspberry Pi Zero.

Merged thanks Eric!
-- 
Florian



signature.asc
Description: OpenPGP digital signature

Re: [PATCH v2 2/4] mmc: sdhci-of-arasan: Control clock for accessing syscon

[Ziyuan Xu]

Hi Shawn,


On 2016年08月31日 09:37, Shawn Lin wrote:

In the eariler commit 65820199272d ("Documentation: mmc:
sdhci-of-arasan: Add soc-ctl-syscon for corecfg regs"), we
introduced syscon to control corecfg_* stuff provided by
arasan. But given that we may need to ungate the clock for
accessing corecfg_*, it not so perfect as it depends on
whether specific clock driver disables it if not referenced.
Meanwhile, if we don't need arasan contoller to work anymore,
there is no reason to still enable it. So let's control this
clock when needed.

Signed-off-by: Shawn Lin 

---


Without  this series of patches, we can't gate aclk_emmcgrf even though 
driver enter suspend/remove. It meaningful to save power consumption.

It looks nice to me, and also I have tested on rk3399 board, so

Tested-by: Ziyuan Xu 



Changes in v2:
- assign NULL to clk_syscon if it's not deferral error.

  drivers/mmc/host/sdhci-of-arasan.c | 33 ++---
  1 file changed, 30 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/host/sdhci-of-arasan.c 
b/drivers/mmc/host/sdhci-of-arasan.c
index 0b3a9cf..3169f81 100644
--- a/drivers/mmc/host/sdhci-of-arasan.c
+++ b/drivers/mmc/host/sdhci-of-arasan.c
@@ -78,6 +78,7 @@ struct sdhci_arasan_soc_ctl_map {
   * struct sdhci_arasan_data
   * @host: Pointer to the main SDHCI host structure.
   * @clk_ahb:  Pointer to the AHB clock
+ * @clk_syscon:Pointer to the optional clock for accessing 
syscon
   * @phy:  Pointer to the generic phy
   * @is_phy_on:True if the PHY is on; false if not.
   * @sdcardclk_hw: Struct for the clock we might provide to a PHY.
@@ -88,6 +89,7 @@ struct sdhci_arasan_soc_ctl_map {
  struct sdhci_arasan_data {
struct sdhci_host *host;
struct clk  *clk_ahb;
+   struct clk  *clk_syscon;
struct phy  *phy;
boolis_phy_on;
  
@@ -290,6 +292,7 @@ static int sdhci_arasan_suspend(struct device *dev)
  
  	clk_disable(pltfm_host->clk);

clk_disable(sdhci_arasan->clk_ahb);
+   clk_disable(sdhci_arasan->clk_syscon);
  
  	return 0;

  }
@@ -309,6 +312,12 @@ static int sdhci_arasan_resume(struct device *dev)
struct sdhci_arasan_data *sdhci_arasan = sdhci_pltfm_priv(pltfm_host);
int ret;
  
+	ret = clk_enable(sdhci_arasan->clk_syscon);

+   if (ret) {
+   dev_err(dev, "Cannot enable syscon clock.\n");
+   return ret;
+   }
+
ret = clk_enable(sdhci_arasan->clk_ahb);
if (ret) {
dev_err(dev, "Cannot enable AHB clock.\n");
@@ -528,26 +537,41 @@ static int sdhci_arasan_probe(struct platform_device 
*pdev)
ret);
goto err_pltfm_free;
}
+
+   sdhci_arasan->clk_syscon = devm_clk_get(>dev,
+   "clk_syscon");
+   if (IS_ERR(sdhci_arasan->clk_syscon)) {
+   ret = PTR_ERR(sdhci_arasan->clk_syscon);
+   if (ret == -EPROBE_DEFER)
+   goto err_pltfm_free;
+   else
+   sdhci_arasan->clk_syscon = NULL;
+   }
+
+   if (clk_prepare_enable(sdhci_arasan->clk_syscon)) {
+   dev_err(>dev, "Unable to enable syscon clock.\n");
+   goto err_pltfm_free;
+   }
}
  
  	sdhci_arasan->clk_ahb = devm_clk_get(>dev, "clk_ahb");

if (IS_ERR(sdhci_arasan->clk_ahb)) {
dev_err(>dev, "clk_ahb clock not found.\n");
ret = PTR_ERR(sdhci_arasan->clk_ahb);
-   goto err_pltfm_free;
+   goto clk_dis_syscon;
}
  
  	clk_xin = devm_clk_get(>dev, "clk_xin");

if (IS_ERR(clk_xin)) {
dev_err(>dev, "clk_xin clock not found.\n");
ret = PTR_ERR(clk_xin);
-   goto err_pltfm_free;
+   goto clk_dis_syscon;
}
  
  	ret = clk_prepare_enable(sdhci_arasan->clk_ahb);

if (ret) {
dev_err(>dev, "Unable to enable AHB clock.\n");
-   goto err_pltfm_free;
+   goto clk_dis_syscon;
}
  
  	ret = clk_prepare_enable(clk_xin);

@@ -607,6 +631,8 @@ clk_disable_all:
clk_disable_unprepare(clk_xin);
  clk_dis_ahb:
clk_disable_unprepare(sdhci_arasan->clk_ahb);
+clk_dis_syscon:
+   clk_disable_unprepare(sdhci_arasan->clk_syscon);
  err_pltfm_free:
sdhci_pltfm_free(pdev);
return ret;
@@ -631,6 +657,7 @@ static int sdhci_arasan_remove(struct platform_device *pdev)
ret = sdhci_pltfm_unregister(pdev);
  
  	clk_disable_unprepare(clk_ahb);

+   clk_disable_unprepare(sdhci_arasan->clk_syscon);
  
  	return ret;

  }

Re: [PATCH v2 3/4] arm64: dts: rockchip: add clk_syscon for sdhci on rk3399

[Ziyuan Xu]

Hi Shawn,


On 2016年08月31日 09:37, Shawn Lin wrote:

We are intent on letting the sdhci variant driver handle this
optional clock on rk3399 platform now.

Signed-off-by: Shawn Lin 
---


Thanks for your patch, we can gate aclk_emmcgrf now as soon as sdhci 
driver suspend.


Reviewed-by: Ziyuan Xu 
Tested-by: Ziyuan Xu 



Changes in v2: None

  arch/arm64/boot/dts/rockchip/rk3399.dtsi | 5 +++--
  1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index bc86e8c..d26c6ad 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -233,8 +233,9 @@
arasan,soc-ctl-syscon = <>;
assigned-clocks = < SCLK_EMMC>;
assigned-clock-rates = <2>;
-   clocks = < SCLK_EMMC>, < ACLK_EMMC>;
-   clock-names = "clk_xin", "clk_ahb";
+   clocks = < SCLK_EMMC>, < ACLK_EMMC>,
+< ACLK_EMMC_GRF>;
+   clock-names = "clk_xin", "clk_ahb", "clk_syscon";
clock-output-names = "emmc_cardclock";
#clock-cells = <0>;
phys = <_phy>;

Re: [PATCH v2 2/4] mmc: sdhci-of-arasan: Control clock for accessing syscon

[Ziyuan Xu]

Hi Shawn,


On 2016年08月31日 09:37, Shawn Lin wrote:

In the eariler commit 65820199272d ("Documentation: mmc:
sdhci-of-arasan: Add soc-ctl-syscon for corecfg regs"), we
introduced syscon to control corecfg_* stuff provided by
arasan. But given that we may need to ungate the clock for
accessing corecfg_*, it not so perfect as it depends on
whether specific clock driver disables it if not referenced.
Meanwhile, if we don't need arasan contoller to work anymore,
there is no reason to still enable it. So let's control this
clock when needed.

Signed-off-by: Shawn Lin 

---


Without  this series of patches, we can't gate aclk_emmcgrf even though 
driver enter suspend/remove. It meaningful to save power consumption.

It looks nice to me, and also I have tested on rk3399 board, so

Tested-by: Ziyuan Xu 



Changes in v2:
- assign NULL to clk_syscon if it's not deferral error.

  drivers/mmc/host/sdhci-of-arasan.c | 33 ++---
  1 file changed, 30 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/host/sdhci-of-arasan.c 
b/drivers/mmc/host/sdhci-of-arasan.c
index 0b3a9cf..3169f81 100644
--- a/drivers/mmc/host/sdhci-of-arasan.c
+++ b/drivers/mmc/host/sdhci-of-arasan.c
@@ -78,6 +78,7 @@ struct sdhci_arasan_soc_ctl_map {
   * struct sdhci_arasan_data
   * @host: Pointer to the main SDHCI host structure.
   * @clk_ahb:  Pointer to the AHB clock
+ * @clk_syscon:Pointer to the optional clock for accessing 
syscon
   * @phy:  Pointer to the generic phy
   * @is_phy_on:True if the PHY is on; false if not.
   * @sdcardclk_hw: Struct for the clock we might provide to a PHY.
@@ -88,6 +89,7 @@ struct sdhci_arasan_soc_ctl_map {
  struct sdhci_arasan_data {
struct sdhci_host *host;
struct clk  *clk_ahb;
+   struct clk  *clk_syscon;
struct phy  *phy;
boolis_phy_on;
  
@@ -290,6 +292,7 @@ static int sdhci_arasan_suspend(struct device *dev)
  
  	clk_disable(pltfm_host->clk);

clk_disable(sdhci_arasan->clk_ahb);
+   clk_disable(sdhci_arasan->clk_syscon);
  
  	return 0;

  }
@@ -309,6 +312,12 @@ static int sdhci_arasan_resume(struct device *dev)
struct sdhci_arasan_data *sdhci_arasan = sdhci_pltfm_priv(pltfm_host);
int ret;
  
+	ret = clk_enable(sdhci_arasan->clk_syscon);

+   if (ret) {
+   dev_err(dev, "Cannot enable syscon clock.\n");
+   return ret;
+   }
+
ret = clk_enable(sdhci_arasan->clk_ahb);
if (ret) {
dev_err(dev, "Cannot enable AHB clock.\n");
@@ -528,26 +537,41 @@ static int sdhci_arasan_probe(struct platform_device 
*pdev)
ret);
goto err_pltfm_free;
}
+
+   sdhci_arasan->clk_syscon = devm_clk_get(>dev,
+   "clk_syscon");
+   if (IS_ERR(sdhci_arasan->clk_syscon)) {
+   ret = PTR_ERR(sdhci_arasan->clk_syscon);
+   if (ret == -EPROBE_DEFER)
+   goto err_pltfm_free;
+   else
+   sdhci_arasan->clk_syscon = NULL;
+   }
+
+   if (clk_prepare_enable(sdhci_arasan->clk_syscon)) {
+   dev_err(>dev, "Unable to enable syscon clock.\n");
+   goto err_pltfm_free;
+   }
}
  
  	sdhci_arasan->clk_ahb = devm_clk_get(>dev, "clk_ahb");

if (IS_ERR(sdhci_arasan->clk_ahb)) {
dev_err(>dev, "clk_ahb clock not found.\n");
ret = PTR_ERR(sdhci_arasan->clk_ahb);
-   goto err_pltfm_free;
+   goto clk_dis_syscon;
}
  
  	clk_xin = devm_clk_get(>dev, "clk_xin");

if (IS_ERR(clk_xin)) {
dev_err(>dev, "clk_xin clock not found.\n");
ret = PTR_ERR(clk_xin);
-   goto err_pltfm_free;
+   goto clk_dis_syscon;
}
  
  	ret = clk_prepare_enable(sdhci_arasan->clk_ahb);

if (ret) {
dev_err(>dev, "Unable to enable AHB clock.\n");
-   goto err_pltfm_free;
+   goto clk_dis_syscon;
}
  
  	ret = clk_prepare_enable(clk_xin);

@@ -607,6 +631,8 @@ clk_disable_all:
clk_disable_unprepare(clk_xin);
  clk_dis_ahb:
clk_disable_unprepare(sdhci_arasan->clk_ahb);
+clk_dis_syscon:
+   clk_disable_unprepare(sdhci_arasan->clk_syscon);
  err_pltfm_free:
sdhci_pltfm_free(pdev);
return ret;
@@ -631,6 +657,7 @@ static int sdhci_arasan_remove(struct platform_device *pdev)
ret = sdhci_pltfm_unregister(pdev);
  
  	clk_disable_unprepare(clk_ahb);

+   clk_disable_unprepare(sdhci_arasan->clk_syscon);
  
  	return ret;

  }

Re: [PATCH v2 3/4] arm64: dts: rockchip: add clk_syscon for sdhci on rk3399

[Ziyuan Xu]

Hi Shawn,


On 2016年08月31日 09:37, Shawn Lin wrote:

We are intent on letting the sdhci variant driver handle this
optional clock on rk3399 platform now.

Signed-off-by: Shawn Lin 
---


Thanks for your patch, we can gate aclk_emmcgrf now as soon as sdhci 
driver suspend.


Reviewed-by: Ziyuan Xu 
Tested-by: Ziyuan Xu 



Changes in v2: None

  arch/arm64/boot/dts/rockchip/rk3399.dtsi | 5 +++--
  1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index bc86e8c..d26c6ad 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -233,8 +233,9 @@
arasan,soc-ctl-syscon = <>;
assigned-clocks = < SCLK_EMMC>;
assigned-clock-rates = <2>;
-   clocks = < SCLK_EMMC>, < ACLK_EMMC>;
-   clock-names = "clk_xin", "clk_ahb";
+   clocks = < SCLK_EMMC>, < ACLK_EMMC>,
+< ACLK_EMMC_GRF>;
+   clock-names = "clk_xin", "clk_ahb", "clk_syscon";
clock-output-names = "emmc_cardclock";
#clock-cells = <0>;
phys = <_phy>;

Re: [PATCH v3] time: alarmtimer: Add the trcepoints for alarmtimer

[Baolin Wang]

Hi Steven,

On 30 August 2016 at 23:42, Steven Rostedt  wrote:
> On Tue, 30 Aug 2016 19:50:20 +0800
> Baolin Wang  wrote:
>
>> Hi,
>>
>> On 22 August 2016 at 12:23, Baolin Wang  wrote:
>> > For system debugging, we usually want to know who sets one alarm timer, the
>> > time of the timer, when the timer started and fired and so on. Thus adding
>> > tracepoints can help us trace the alarmtimer information.
>> >
>> > For example, when we debug the system supend/resume, if the system is 
>> > always
>> > resumed by RTC alarm, we can find out which process set the alarm timer to
>> > resume system by below trace log:
>> >
>> > ..
>> > Binder:2976_6-3473  [005] d..2  1076.587732: alarmtimer_start: 
>> > process:Binder:2976_6
>> > alarmtimer type:ALARM_BOOTTIME expires:123415400 time: 1970-1-1 0:20:35
>> >
>> > Binder:2976_7-3480  [002] d..2  1076.592707: alarmtimer_cancel: 
>> > process:Binder:2976_7
>> > alarmtimer type:ALARM_BOOTTIME expires:13254630600 time: 2012-1-2 
>> > 0:11:0
>> >
>> > Binder:2976_7-3480  [002] d..2  1076.592731: alarmtimer_start: 
>> > process:Binder:2976_7
>> > alarmtimer type:ALARM_BOOTTIME expires:13253780400 time: 2012-1-1 
>> > 0:34:0
>> >
>> > system_server-2976  [003] d..2  1076.605587: alarmtimer_cancel: 
>> > process:system_server
>> > alarmtimer type:ALARM_BOOTTIME expires:123415400 time: 1970-1-1 0:20:35
>> >
>> > system_server-2976  [003] d..2  1076.605608: alarmtimer_start: 
>> > process:system_server
>> > alarmtimer type:ALARM_BOOTTIME expires:123415500 time: 1970-1-1 0:20:35
>> >
>> > system_server-3000  [002] ...1  1087.737565: alarmtimer_suspend: 
>> > alarmtimer type:ALARM_BOOTTIME
>> > expires time: 2012-1-1 0:34:0
>> > ..
>> >
>> > From the trace log, we can find out the 'Binder:2976_7' process set one 
>> > alarm
>> > timer which resumes the system.
>>
>> Do you have any comments about this patch? Thanks.
>
> Looks fine to me.
>
> Acked-by: Steven Rostedt 
>
> Now you need to get the time maintainers to accept it.

Thanks.

-- 
Baolin.wang
Best Regards

Re: [PATCH v3] time: alarmtimer: Add the trcepoints for alarmtimer

[Baolin Wang]

Hi Steven,

On 30 August 2016 at 23:42, Steven Rostedt  wrote:
> On Tue, 30 Aug 2016 19:50:20 +0800
> Baolin Wang  wrote:
>
>> Hi,
>>
>> On 22 August 2016 at 12:23, Baolin Wang  wrote:
>> > For system debugging, we usually want to know who sets one alarm timer, the
>> > time of the timer, when the timer started and fired and so on. Thus adding
>> > tracepoints can help us trace the alarmtimer information.
>> >
>> > For example, when we debug the system supend/resume, if the system is 
>> > always
>> > resumed by RTC alarm, we can find out which process set the alarm timer to
>> > resume system by below trace log:
>> >
>> > ..
>> > Binder:2976_6-3473  [005] d..2  1076.587732: alarmtimer_start: 
>> > process:Binder:2976_6
>> > alarmtimer type:ALARM_BOOTTIME expires:123415400 time: 1970-1-1 0:20:35
>> >
>> > Binder:2976_7-3480  [002] d..2  1076.592707: alarmtimer_cancel: 
>> > process:Binder:2976_7
>> > alarmtimer type:ALARM_BOOTTIME expires:13254630600 time: 2012-1-2 
>> > 0:11:0
>> >
>> > Binder:2976_7-3480  [002] d..2  1076.592731: alarmtimer_start: 
>> > process:Binder:2976_7
>> > alarmtimer type:ALARM_BOOTTIME expires:13253780400 time: 2012-1-1 
>> > 0:34:0
>> >
>> > system_server-2976  [003] d..2  1076.605587: alarmtimer_cancel: 
>> > process:system_server
>> > alarmtimer type:ALARM_BOOTTIME expires:123415400 time: 1970-1-1 0:20:35
>> >
>> > system_server-2976  [003] d..2  1076.605608: alarmtimer_start: 
>> > process:system_server
>> > alarmtimer type:ALARM_BOOTTIME expires:123415500 time: 1970-1-1 0:20:35
>> >
>> > system_server-3000  [002] ...1  1087.737565: alarmtimer_suspend: 
>> > alarmtimer type:ALARM_BOOTTIME
>> > expires time: 2012-1-1 0:34:0
>> > ..
>> >
>> > From the trace log, we can find out the 'Binder:2976_7' process set one 
>> > alarm
>> > timer which resumes the system.
>>
>> Do you have any comments about this patch? Thanks.
>
> Looks fine to me.
>
> Acked-by: Steven Rostedt 
>
> Now you need to get the time maintainers to accept it.

Thanks.

-- 
Baolin.wang
Best Regards

Re: [PATCH V3 2/2] usb: phy: phy-brcm-usb: Add Broadcom STB USB Phy driver

[kbuild test robot]

Hi Al,

[auto build test ERROR on phy/next]
[also build test ERROR on next-20160825]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]
[Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for 
convenience) to record what (public, well-known) commit your patch series was 
built on]
[Check https://git-scm.com/docs/git-format-patch for more information]

url:
https://github.com/0day-ci/linux/commits/Al-Cooper/soc-brcmstb-Add-Product-ID-and-Family-ID-helper-functions/20160830-224057
base:   https://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git 
next
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 5.4.0-6) 5.4.0 20160609
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm 

All errors (new ones prefixed by >>):

>> ERROR: "brcm_usb_common_init" [drivers/phy/phy-brcm-usb.ko] undefined!

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

Re: [PATCH V3 2/2] usb: phy: phy-brcm-usb: Add Broadcom STB USB Phy driver

[kbuild test robot]

Hi Al,

[auto build test ERROR on phy/next]
[also build test ERROR on next-20160825]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]
[Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for 
convenience) to record what (public, well-known) commit your patch series was 
built on]
[Check https://git-scm.com/docs/git-format-patch for more information]

url:
https://github.com/0day-ci/linux/commits/Al-Cooper/soc-brcmstb-Add-Product-ID-and-Family-ID-helper-functions/20160830-224057
base:   https://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git 
next
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 5.4.0-6) 5.4.0 20160609
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm 

All errors (new ones prefixed by >>):

>> ERROR: "brcm_usb_common_init" [drivers/phy/phy-brcm-usb.ko] undefined!

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

Re: [PATCH v2 4/4] clk: rockchip: remove CLK_IGNORE_UNUSED flag for aclk_emmc_grf on rk3399

[Ziyuan Xu]

On 2016年08月31日 09:37, Shawn Lin wrote:

aclk_emmc_grf is used for accessing corecfg_* of emmc stuff within
GRF block. We don't need to add CLK_IGNORE_UNUSED for it now as the
emmc driver will enable/disable it explicitly when needed.

Signed-off-by: Shawn Lin 


This patchset test result:

localhost driver # cat /sys/kernel/debug/clk/clk_summary | grep emmc
  gpll_aclk_emmc_src  11 
59400  0 0
 aclk_emmc35 
19800  0 0
aclk_emmcgrf  12 
19800  0 0
aclk_emmc_noc 11 
19800  0 0
aclk_emmccore 00 
19800  0 0
  clk_emmc12 
14850  0 0
 emmc_cardclock   00 
14850  0 0
  cpll_aclk_emmc_src  00 
8  0 0


After unbind driver.
localhost driver # cat /sys/kernel/debug/clk/clk_summary | grep emmc
  gpll_aclk_emmc_src  11 
59400  0 0
 aclk_emmc12 
19800  0 0
aclk_emmcgrf  00 
19800  0 0
aclk_emmc_noc 11 
19800  0 0
aclk_emmccore 00 
19800  0 0
  clk_emmc00 
14850  0 0
  cpll_aclk_emmc_src  00 
8  0 0


And aclk_emmcgrf(Bit 10, when high, enable clock) had gate.
localhost driver # mem r 0xff760380
0x0415

It works sane, so

Tested-by: Ziyuan Xu 


---

Changes in v2: None

  drivers/clk/rockchip/clk-rk3399.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/rockchip/clk-rk3399.c 
b/drivers/clk/rockchip/clk-rk3399.c
index ede6c47..908f684 100644
--- a/drivers/clk/rockchip/clk-rk3399.c
+++ b/drivers/clk/rockchip/clk-rk3399.c
@@ -934,7 +934,7 @@ static struct rockchip_clk_branch rk3399_clk_branches[] 
__initdata = {
RK3399_CLKGATE_CON(32), 8, GFLAGS),
GATE(ACLK_EMMC_NOC, "aclk_emmc_noc", "aclk_emmc", CLK_IGNORE_UNUSED,
RK3399_CLKGATE_CON(32), 9, GFLAGS),
-   GATE(ACLK_EMMC_GRF, "aclk_emmcgrf", "aclk_emmc", CLK_IGNORE_UNUSED,
+   GATE(ACLK_EMMC_GRF, "aclk_emmcgrf", "aclk_emmc", 0,
RK3399_CLKGATE_CON(32), 10, GFLAGS),
  
  	/* perilp0 */

Re: [PATCH v2 4/4] clk: rockchip: remove CLK_IGNORE_UNUSED flag for aclk_emmc_grf on rk3399

[Ziyuan Xu]

On 2016年08月31日 09:37, Shawn Lin wrote:

aclk_emmc_grf is used for accessing corecfg_* of emmc stuff within
GRF block. We don't need to add CLK_IGNORE_UNUSED for it now as the
emmc driver will enable/disable it explicitly when needed.

Signed-off-by: Shawn Lin 


This patchset test result:

localhost driver # cat /sys/kernel/debug/clk/clk_summary | grep emmc
  gpll_aclk_emmc_src  11 
59400  0 0
 aclk_emmc35 
19800  0 0
aclk_emmcgrf  12 
19800  0 0
aclk_emmc_noc 11 
19800  0 0
aclk_emmccore 00 
19800  0 0
  clk_emmc12 
14850  0 0
 emmc_cardclock   00 
14850  0 0
  cpll_aclk_emmc_src  00 
8  0 0


After unbind driver.
localhost driver # cat /sys/kernel/debug/clk/clk_summary | grep emmc
  gpll_aclk_emmc_src  11 
59400  0 0
 aclk_emmc12 
19800  0 0
aclk_emmcgrf  00 
19800  0 0
aclk_emmc_noc 11 
19800  0 0
aclk_emmccore 00 
19800  0 0
  clk_emmc00 
14850  0 0
  cpll_aclk_emmc_src  00 
8  0 0


And aclk_emmcgrf(Bit 10, when high, enable clock) had gate.
localhost driver # mem r 0xff760380
0x0415

It works sane, so

Tested-by: Ziyuan Xu 


---

Changes in v2: None

  drivers/clk/rockchip/clk-rk3399.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/rockchip/clk-rk3399.c 
b/drivers/clk/rockchip/clk-rk3399.c
index ede6c47..908f684 100644
--- a/drivers/clk/rockchip/clk-rk3399.c
+++ b/drivers/clk/rockchip/clk-rk3399.c
@@ -934,7 +934,7 @@ static struct rockchip_clk_branch rk3399_clk_branches[] 
__initdata = {
RK3399_CLKGATE_CON(32), 8, GFLAGS),
GATE(ACLK_EMMC_NOC, "aclk_emmc_noc", "aclk_emmc", CLK_IGNORE_UNUSED,
RK3399_CLKGATE_CON(32), 9, GFLAGS),
-   GATE(ACLK_EMMC_GRF, "aclk_emmcgrf", "aclk_emmc", CLK_IGNORE_UNUSED,
+   GATE(ACLK_EMMC_GRF, "aclk_emmcgrf", "aclk_emmc", 0,
RK3399_CLKGATE_CON(32), 10, GFLAGS),
  
  	/* perilp0 */

Re: [PATCH v5 00/11] Add HW throttle for Tegra soctherm

[Wei Ni]

On 08/19/2016 03:15 PM, Zhang Rui wrote:
> On 四, 2016-05-26 at 17:42 +0800, Wei Ni wrote:
>> Hi,
>> Does there have any comments on this series?
>> Let me know if someone has suggestions.
>>
> I have no objections to this patch set.
> As 10 patches out of 11, in this patch series, contain changes out of
> thermal scope, if you prefer this patch set go through thermal tree, I
> still need ACKs for the changes out of thermal scope.

Rui, thanks for your comments.

Thierry & Matt could you ACK this series ?

Thanks.
Wei.

> 
> thanks,
> rui
> 
>> Thanks.
>> Wei.
>>
>> On 05/11/2016 06:20 PM, Wei Ni wrote:
>>>
>>> This series add following functions for Tegra soctherm:
>>> 1. add HW throttle function.
>>> 2. enable soctherm node for Tegra124, Tegra132, Tegra210, and
>>> set "critical", "hot" trips for them.
>>>
>>> Main changes from v4:
>>> 1. drop the "nvidia" prefix from the node name, per Rob's comments.
>>>
>>> Main changes from v3:
>>> 1. change some properties'name and descriptions, per Rob's
>>> comments.
>>> 2. change the corresponding driver codes.
>>>
>>> Main changes from v2:
>>> 1. improve the of-binding, per Eduardo's comments, and
>>> change the corresponding driver codes.
>>> 2. move two setting critical trip patches in this series,
>>> 3. fix some bugs in dts changes.
>>>
>>> Main changes from v1:
>>> 1. use readl/writel instead of __raw_readl/__raw_writel.
>>> 2. rebase on the linux-next.
>>>
>>> The v1 series is in:
>>> https://lkml.org/lkml/2016/3/31/230
>>>
>>> The v2 series is in:
>>> https://lkml.org/lkml/2016/4/26/1577
>>>
>>> The v3 series is in:
>>> https://lkml.org/lkml/2016/5/3/274
>>>
>>> The v4 series is in:
>>> https://lkml.org/lkml/2016/5/9/45
>>>
>>> Wei Ni (11):
>>>   of: Add bindings of hw throttle for Tegra soctherm
>>>   thermal: tegra: add hw-throttle function
>>>   thermal: tegra: add hw-throttle for Tegra132
>>>   arm: tegra: set critical trips for Tegra124
>>>   arm: tegra: set hot trips for Tegra124
>>>   arm64: tegra: use tegra132-soctherm for Tegra132
>>>   arm64: tegra: set critical trips for Tegra132
>>>   arm64: tegra: set hot trips for Tegra132
>>>   arm64: tegra: add soctherm node for Tegra210
>>>   arm64: tegra: set critical trips for Tegra210
>>>   arm64: tegra: set hot trips for Tegra210
>>>
>>>  .../bindings/thermal/nvidia,tegra124-soctherm.txt  | 121 ++-
>>>  arch/arm/boot/dts/tegra124-jetson-tk1.dts  |  18 +-
>>>  arch/arm/boot/dts/tegra124.dtsi|  83 +-
>>>  arch/arm64/boot/dts/nvidia/tegra132.dtsi   | 119 ++-
>>>  arch/arm64/boot/dts/nvidia/tegra210.dtsi   | 127 
>>>  drivers/thermal/tegra/soctherm.c   | 842
>>> -
>>>  drivers/thermal/tegra/soctherm.h   |  10 +
>>>  drivers/thermal/tegra/tegra124-soctherm.c  |  18 +
>>>  drivers/thermal/tegra/tegra132-soctherm.c  |  18 +
>>>  drivers/thermal/tegra/tegra210-soctherm.c  |  18 +
>>>  include/dt-bindings/thermal/tegra124-soctherm.h|   5 +
>>>  11 files changed, 1344 insertions(+), 35 deletions(-)
>>>

Re: [PATCH v5 00/11] Add HW throttle for Tegra soctherm

[Wei Ni]

On 08/19/2016 03:15 PM, Zhang Rui wrote:
> On 四, 2016-05-26 at 17:42 +0800, Wei Ni wrote:
>> Hi,
>> Does there have any comments on this series?
>> Let me know if someone has suggestions.
>>
> I have no objections to this patch set.
> As 10 patches out of 11, in this patch series, contain changes out of
> thermal scope, if you prefer this patch set go through thermal tree, I
> still need ACKs for the changes out of thermal scope.

Rui, thanks for your comments.

Thierry & Matt could you ACK this series ?

Thanks.
Wei.

> 
> thanks,
> rui
> 
>> Thanks.
>> Wei.
>>
>> On 05/11/2016 06:20 PM, Wei Ni wrote:
>>>
>>> This series add following functions for Tegra soctherm:
>>> 1. add HW throttle function.
>>> 2. enable soctherm node for Tegra124, Tegra132, Tegra210, and
>>> set "critical", "hot" trips for them.
>>>
>>> Main changes from v4:
>>> 1. drop the "nvidia" prefix from the node name, per Rob's comments.
>>>
>>> Main changes from v3:
>>> 1. change some properties'name and descriptions, per Rob's
>>> comments.
>>> 2. change the corresponding driver codes.
>>>
>>> Main changes from v2:
>>> 1. improve the of-binding, per Eduardo's comments, and
>>> change the corresponding driver codes.
>>> 2. move two setting critical trip patches in this series,
>>> 3. fix some bugs in dts changes.
>>>
>>> Main changes from v1:
>>> 1. use readl/writel instead of __raw_readl/__raw_writel.
>>> 2. rebase on the linux-next.
>>>
>>> The v1 series is in:
>>> https://lkml.org/lkml/2016/3/31/230
>>>
>>> The v2 series is in:
>>> https://lkml.org/lkml/2016/4/26/1577
>>>
>>> The v3 series is in:
>>> https://lkml.org/lkml/2016/5/3/274
>>>
>>> The v4 series is in:
>>> https://lkml.org/lkml/2016/5/9/45
>>>
>>> Wei Ni (11):
>>>   of: Add bindings of hw throttle for Tegra soctherm
>>>   thermal: tegra: add hw-throttle function
>>>   thermal: tegra: add hw-throttle for Tegra132
>>>   arm: tegra: set critical trips for Tegra124
>>>   arm: tegra: set hot trips for Tegra124
>>>   arm64: tegra: use tegra132-soctherm for Tegra132
>>>   arm64: tegra: set critical trips for Tegra132
>>>   arm64: tegra: set hot trips for Tegra132
>>>   arm64: tegra: add soctherm node for Tegra210
>>>   arm64: tegra: set critical trips for Tegra210
>>>   arm64: tegra: set hot trips for Tegra210
>>>
>>>  .../bindings/thermal/nvidia,tegra124-soctherm.txt  | 121 ++-
>>>  arch/arm/boot/dts/tegra124-jetson-tk1.dts  |  18 +-
>>>  arch/arm/boot/dts/tegra124.dtsi|  83 +-
>>>  arch/arm64/boot/dts/nvidia/tegra132.dtsi   | 119 ++-
>>>  arch/arm64/boot/dts/nvidia/tegra210.dtsi   | 127 
>>>  drivers/thermal/tegra/soctherm.c   | 842
>>> -
>>>  drivers/thermal/tegra/soctherm.h   |  10 +
>>>  drivers/thermal/tegra/tegra124-soctherm.c  |  18 +
>>>  drivers/thermal/tegra/tegra132-soctherm.c  |  18 +
>>>  drivers/thermal/tegra/tegra210-soctherm.c  |  18 +
>>>  include/dt-bindings/thermal/tegra124-soctherm.h|   5 +
>>>  11 files changed, 1344 insertions(+), 35 deletions(-)
>>>

[PATCH net] rps: flow_dissector: Fix uninitialized flow_keys used in __skb_get_hash possibly

[fgao]

From: Gao Feng 

The original codes depend on that the function parameters are evaluated from
left to right. But the parameter's evaluation order is not defined in C
standard actually.

When flow_keys_have_l4() is invoked before ___skb_get_hash(skb, ,
hashrnd) with some compilers or environment, the keys passed to
flow_keys_have_l4 is not initialized.

Signed-off-by: Gao Feng 
---
 net/core/flow_dissector.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
index 61ad43f..52742a0 100644
--- a/net/core/flow_dissector.c
+++ b/net/core/flow_dissector.c
@@ -680,11 +680,13 @@ EXPORT_SYMBOL_GPL(__skb_get_hash_symmetric);
 void __skb_get_hash(struct sk_buff *skb)
 {
struct flow_keys keys;
+   u32 hash;
 
__flow_hash_secret_init();
 
-   __skb_set_sw_hash(skb, ___skb_get_hash(skb, , hashrnd),
- flow_keys_have_l4());
+   hash = ___skb_get_hash(skb, , hashrnd);
+
+   __skb_set_sw_hash(skb, hash, flow_keys_have_l4());
 }
 EXPORT_SYMBOL(__skb_get_hash);
 
-- 
1.9.1

[PATCH net] rps: flow_dissector: Fix uninitialized flow_keys used in __skb_get_hash possibly

[fgao]

From: Gao Feng 

The original codes depend on that the function parameters are evaluated from
left to right. But the parameter's evaluation order is not defined in C
standard actually.

When flow_keys_have_l4() is invoked before ___skb_get_hash(skb, ,
hashrnd) with some compilers or environment, the keys passed to
flow_keys_have_l4 is not initialized.

Signed-off-by: Gao Feng 
---
 net/core/flow_dissector.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
index 61ad43f..52742a0 100644
--- a/net/core/flow_dissector.c
+++ b/net/core/flow_dissector.c
@@ -680,11 +680,13 @@ EXPORT_SYMBOL_GPL(__skb_get_hash_symmetric);
 void __skb_get_hash(struct sk_buff *skb)
 {
struct flow_keys keys;
+   u32 hash;
 
__flow_hash_secret_init();
 
-   __skb_set_sw_hash(skb, ___skb_get_hash(skb, , hashrnd),
- flow_keys_have_l4());
+   hash = ___skb_get_hash(skb, , hashrnd);
+
+   __skb_set_sw_hash(skb, hash, flow_keys_have_l4());
 }
 EXPORT_SYMBOL(__skb_get_hash);
 
-- 
1.9.1

[PATCH] pwm/atmel-hlcdc: Add BACKLIGHT_PWM to config dependency

[Hyung Jin Jung]

atmel-hlcdc-pwm working with pwm-backlight so that add dependency to avoid user 
falut.

Signed-off-by: HyungJin Jung 
---
 drivers/pwm/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 80a566a..b32b2c1 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -54,6 +54,7 @@ config PWM_ATMEL_HLCDC_PWM
tristate "Atmel HLCDC PWM support"
depends on MFD_ATMEL_HLCDC
depends on HAVE_CLK
+   depends on BACKLIGHT_PWM
help
  Generic PWM framework driver for the PWM output of the HLCDC
  (Atmel High-end LCD Controller). This PWM output is mainly used
-- 
1.9.1

[PATCH] pwm/atmel-hlcdc: Add BACKLIGHT_PWM to config dependency

[Hyung Jin Jung]

atmel-hlcdc-pwm working with pwm-backlight so that add dependency to avoid user 
falut.

Signed-off-by: HyungJin Jung 
---
 drivers/pwm/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 80a566a..b32b2c1 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -54,6 +54,7 @@ config PWM_ATMEL_HLCDC_PWM
tristate "Atmel HLCDC PWM support"
depends on MFD_ATMEL_HLCDC
depends on HAVE_CLK
+   depends on BACKLIGHT_PWM
help
  Generic PWM framework driver for the PWM output of the HLCDC
  (Atmel High-end LCD Controller). This PWM output is mainly used
-- 
1.9.1