Re: [PATCH v6 1/1] acpi: apei: Enable APEI multiple GHES source to share a single external IRQ

[Borislav Petkov]

On Wed, Jul 26, 2017 at 08:57:03PM +0200, Rafael J. Wysocki wrote:
> > Should I apply this or will Tony do that?
> 
> So am I suppsed to drop this?

Well, as suggested in another mail, I think it'll be best if Tony and I
put ourselves as reviewers for the APEI crap and you still collect it.

Unless you want to give it to us and we can arrange some pull order to
send it to you.

What do you prefer?

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
-- 

Re: [PATCH v6 1/1] acpi: apei: Enable APEI multiple GHES source to share a single external IRQ

[Borislav Petkov]

On Wed, Jul 26, 2017 at 08:57:03PM +0200, Rafael J. Wysocki wrote:
> > Should I apply this or will Tony do that?
> 
> So am I suppsed to drop this?

Well, as suggested in another mail, I think it'll be best if Tony and I
put ourselves as reviewers for the APEI crap and you still collect it.

Unless you want to give it to us and we can arrange some pull order to
send it to you.

What do you prefer?

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
-- 

Seek a machine named Thinkpad x121e (AMD E-450 APU)

[Dou Liyang]

Hi all,

Does somebody have the *Thinkpad x121e (AMD E-450 APU)*?

I need to do an regression test for a patchset[1].

This test is simple, but really special and only be reproduced in
Thinkpad x121e. I have tested it in Thinkpad s430, Lenovo M4340 and
Lenovo M4300. Unfortunately, I failed.

I did my utmost to look for it, but two weeks passed, I didn't got it.

Ask for help here, If you have this machine, please let me know.

[1] https://lkml.org/lkml/2017/7/14/20

Thanks,
dou.

Seek a machine named Thinkpad x121e (AMD E-450 APU)

[Dou Liyang]

Hi all,

Does somebody have the *Thinkpad x121e (AMD E-450 APU)*?

I need to do an regression test for a patchset[1].

This test is simple, but really special and only be reproduced in
Thinkpad x121e. I have tested it in Thinkpad s430, Lenovo M4340 and
Lenovo M4300. Unfortunately, I failed.

I did my utmost to look for it, but two weeks passed, I didn't got it.

Ask for help here, If you have this machine, please let me know.

[1] https://lkml.org/lkml/2017/7/14/20

Thanks,
dou.

Re: [PATCH 0/3] EDAC: Convert ghes_edac to a normal module

[Borislav Petkov]

On Wed, Jul 26, 2017 at 10:48:24AM +0200, Borislav Petkov wrote:
>   EDAC: Add edac_pr_err/info macros
>   ACPI/GHES: Add an EDAC notifier chain
>   EDAC, ghes: Make it a proper module

Pushed here:

https://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git/log/?h=ghes

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--

Re: [PATCH 0/3] EDAC: Convert ghes_edac to a normal module

[Borislav Petkov]

On Wed, Jul 26, 2017 at 10:48:24AM +0200, Borislav Petkov wrote:
>   EDAC: Add edac_pr_err/info macros
>   ACPI/GHES: Add an EDAC notifier chain
>   EDAC, ghes: Make it a proper module

Pushed here:

https://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git/log/?h=ghes

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--

Re: [Eas-dev] [PATCH V4 1/3] sched: cpufreq: Allow remote cpufreq callbacks

[Viresh Kumar]

On 26-07-17, 22:34, Joel Fernandes (Google) wrote:
> On Wed, Jul 26, 2017 at 2:22 AM, Viresh Kumar  wrote:
> > @@ -221,7 +226,7 @@ static void sugov_update_single(struct update_util_data 
> > *hook, u64 time,
> > sugov_set_iowait_boost(sg_cpu, time, flags);
> > sg_cpu->last_update = time;
> >
> > -   if (!sugov_should_update_freq(sg_policy, time))
> > +   if (!sugov_should_update_freq(sg_policy, time, hook->cpu))
> > return;
> 
> Since with the remote callbacks now possible, isn't it unsafe to
> modify sg_cpu and sg_policy structures without a lock in
> sugov_update_single?
> 
> Unlike sugov_update_shared, we don't acquire any lock in
> sugov_update_single before updating these structures. Did I miss
> something?

As Peter already mentioned it earlier, the callbacks are called with
rq locks held and so sugov_update_single() wouldn't get called in
parallel for a target CPU.

That's the only race you were worried about ?

-- 
viresh

Re: [Eas-dev] [PATCH V4 1/3] sched: cpufreq: Allow remote cpufreq callbacks

[Viresh Kumar]

On 26-07-17, 22:34, Joel Fernandes (Google) wrote:
> On Wed, Jul 26, 2017 at 2:22 AM, Viresh Kumar  wrote:
> > @@ -221,7 +226,7 @@ static void sugov_update_single(struct update_util_data 
> > *hook, u64 time,
> > sugov_set_iowait_boost(sg_cpu, time, flags);
> > sg_cpu->last_update = time;
> >
> > -   if (!sugov_should_update_freq(sg_policy, time))
> > +   if (!sugov_should_update_freq(sg_policy, time, hook->cpu))
> > return;
> 
> Since with the remote callbacks now possible, isn't it unsafe to
> modify sg_cpu and sg_policy structures without a lock in
> sugov_update_single?
> 
> Unlike sugov_update_shared, we don't acquire any lock in
> sugov_update_single before updating these structures. Did I miss
> something?

As Peter already mentioned it earlier, the callbacks are called with
rq locks held and so sugov_update_single() wouldn't get called in
parallel for a target CPU.

That's the only race you were worried about ?

-- 
viresh

Re: [PATCH v2 6/7] mailbox: bcm-flexrm-mailbox: Set msg_queue_len for each channel

[Anup Patel]

On Thu, Jul 27, 2017 at 10:29 AM, Jassi Brar  wrote:
> On Thu, Jul 27, 2017 at 9:25 AM, Anup Patel  wrote:
>> On Tue, Jul 25, 2017 at 9:37 PM, Jassi Brar  wrote:
>>> On Tue, Jul 25, 2017 at 11:11 AM, Anup Patel  
>>> wrote:
 On Mon, Jul 24, 2017 at 10:06 PM, Jassi Brar  
 wrote:
> On Mon, Jul 24, 2017 at 9:26 AM, Anup Patel  
> wrote:
>> Hi Jassi,
>>
>> Sorry for the delayed response...
>>
>> On Fri, Jul 21, 2017 at 9:16 PM, Jassi Brar  
>> wrote:
>>> Hi Anup,
>>>
>>> On Fri, Jul 21, 2017 at 12:25 PM, Anup Patel  
>>> wrote:
 The Broadcom FlexRM ring (i.e. mailbox channel) can handle
 larger number of messages queued in one FlexRM ring hence
 this patch sets msg_queue_len for each mailbox channel to
 be same as RING_MAX_REQ_COUNT.

 Signed-off-by: Anup Patel 
 Reviewed-by: Scott Branden 
 ---
  drivers/mailbox/bcm-flexrm-mailbox.c | 5 -
  1 file changed, 4 insertions(+), 1 deletion(-)

 diff --git a/drivers/mailbox/bcm-flexrm-mailbox.c 
 b/drivers/mailbox/bcm-flexrm-mailbox.c
 index 9873818..20055a0 100644
 --- a/drivers/mailbox/bcm-flexrm-mailbox.c
 +++ b/drivers/mailbox/bcm-flexrm-mailbox.c
 @@ -1683,8 +1683,11 @@ static int flexrm_mbox_probe(struct 
 platform_device *pdev)
 ret = -ENOMEM;
 goto fail_free_debugfs_root;
 }
 -   for (index = 0; index < mbox->num_rings; index++)
 +   for (index = 0; index < mbox->num_rings; index++) {
 +   mbox->controller.chans[index].msg_queue_len =
 +   RING_MAX_REQ_COUNT;
 mbox->controller.chans[index].con_priv = 
 >rings[index];
 +   }

>>> While writing mailbox.c I wasn't unaware that there is the option to
>>> choose the queue length at runtime.
>>> The idea was to keep the code as simple as possible. I am open to
>>> making it a runtime thing, but first, please help me understand how
>>> that is useful here.
>>>
>>> I understand FlexRm has a ring buffer of RING_MAX_REQ_COUNT(1024)
>>> elements. Any message submitted to mailbox api can be immediately
>>> written onto the ringbuffer if there is some space.
>>> Is there any mechanism to report back to a client driver, if its
>>> message in ringbuffer failed "to be sent"?
>>> If there isn't any, then I think, in flexrm_last_tx_done() you should
>>> simply return true if there is some space left in the rung-buffer,
>>> false otherwise.
>>
>> Yes, we have error code in "struct brcm_message" to report back
>> errors from send_message. In our mailbox clients, we check
>> return value of mbox_send_message() and also the error code
>> in "struct brcm_message".
>>
> I meant after the message has been accepted in the ringbuffer but the
> remote failed to receive it.

 Yes, even this case is handled.

 In case of IO errors after message has been put in ring buffer, we get
 completion message with error code and mailbox client drivers will
 receive back "struct brcm_message" with error set.

 You can refer flexrm_process_completions() for more details.

> It doesn't seem to be what I suggest. I see two issues in
> flexrm_process_completions()
> 1) It calls mbox_send_message(), which is a big NO for a controller
> driver. Why should you have one more message stored outside of
> ringbuffer?

The "last_pending_msg" in each FlexRM ring was added to fit FlexRM
in Mailbox framework.

We don't have any IRQ for TX done so "txdone_irq" out of the question for
FlexRM. We only have completions for both success or failures (IO errors).

This means we have to use "txdone_poll" for FlexRM. For "txdone_poll",
we have to provide last_tx_done() callback. The last_tx_done() callback
is supposed to return true if last send_data() call succeeded.

To implement last_tx_done() in FlexRM driver, we added "last_pending_msg".

When "last_pending_msg" is NULL it means last call to send_data() succeeded
and when "last_pending_msg" is != NULL it means last call to send_data()
did not go through due to lack of space in FlexRM ring. The IRQ worker
of FlexRM ring will automatically queue the message pointed by
"last_pending_message" and clear it. This is why we have mbox_send_message()
call in flexrm_process_completions().

>
> 2) It calls mbox_chan_received_data()  which is for messages received
> from the remote. And not the way to report failed _transmission_, for
> which 

Re: [PATCH v2 6/7] mailbox: bcm-flexrm-mailbox: Set msg_queue_len for each channel

[Anup Patel]

On Thu, Jul 27, 2017 at 10:29 AM, Jassi Brar  wrote:
> On Thu, Jul 27, 2017 at 9:25 AM, Anup Patel  wrote:
>> On Tue, Jul 25, 2017 at 9:37 PM, Jassi Brar  wrote:
>>> On Tue, Jul 25, 2017 at 11:11 AM, Anup Patel  
>>> wrote:
 On Mon, Jul 24, 2017 at 10:06 PM, Jassi Brar  
 wrote:
> On Mon, Jul 24, 2017 at 9:26 AM, Anup Patel  
> wrote:
>> Hi Jassi,
>>
>> Sorry for the delayed response...
>>
>> On Fri, Jul 21, 2017 at 9:16 PM, Jassi Brar  
>> wrote:
>>> Hi Anup,
>>>
>>> On Fri, Jul 21, 2017 at 12:25 PM, Anup Patel  
>>> wrote:
 The Broadcom FlexRM ring (i.e. mailbox channel) can handle
 larger number of messages queued in one FlexRM ring hence
 this patch sets msg_queue_len for each mailbox channel to
 be same as RING_MAX_REQ_COUNT.

 Signed-off-by: Anup Patel 
 Reviewed-by: Scott Branden 
 ---
  drivers/mailbox/bcm-flexrm-mailbox.c | 5 -
  1 file changed, 4 insertions(+), 1 deletion(-)

 diff --git a/drivers/mailbox/bcm-flexrm-mailbox.c 
 b/drivers/mailbox/bcm-flexrm-mailbox.c
 index 9873818..20055a0 100644
 --- a/drivers/mailbox/bcm-flexrm-mailbox.c
 +++ b/drivers/mailbox/bcm-flexrm-mailbox.c
 @@ -1683,8 +1683,11 @@ static int flexrm_mbox_probe(struct 
 platform_device *pdev)
 ret = -ENOMEM;
 goto fail_free_debugfs_root;
 }
 -   for (index = 0; index < mbox->num_rings; index++)
 +   for (index = 0; index < mbox->num_rings; index++) {
 +   mbox->controller.chans[index].msg_queue_len =
 +   RING_MAX_REQ_COUNT;
 mbox->controller.chans[index].con_priv = 
 >rings[index];
 +   }

>>> While writing mailbox.c I wasn't unaware that there is the option to
>>> choose the queue length at runtime.
>>> The idea was to keep the code as simple as possible. I am open to
>>> making it a runtime thing, but first, please help me understand how
>>> that is useful here.
>>>
>>> I understand FlexRm has a ring buffer of RING_MAX_REQ_COUNT(1024)
>>> elements. Any message submitted to mailbox api can be immediately
>>> written onto the ringbuffer if there is some space.
>>> Is there any mechanism to report back to a client driver, if its
>>> message in ringbuffer failed "to be sent"?
>>> If there isn't any, then I think, in flexrm_last_tx_done() you should
>>> simply return true if there is some space left in the rung-buffer,
>>> false otherwise.
>>
>> Yes, we have error code in "struct brcm_message" to report back
>> errors from send_message. In our mailbox clients, we check
>> return value of mbox_send_message() and also the error code
>> in "struct brcm_message".
>>
> I meant after the message has been accepted in the ringbuffer but the
> remote failed to receive it.

 Yes, even this case is handled.

 In case of IO errors after message has been put in ring buffer, we get
 completion message with error code and mailbox client drivers will
 receive back "struct brcm_message" with error set.

 You can refer flexrm_process_completions() for more details.

> It doesn't seem to be what I suggest. I see two issues in
> flexrm_process_completions()
> 1) It calls mbox_send_message(), which is a big NO for a controller
> driver. Why should you have one more message stored outside of
> ringbuffer?

The "last_pending_msg" in each FlexRM ring was added to fit FlexRM
in Mailbox framework.

We don't have any IRQ for TX done so "txdone_irq" out of the question for
FlexRM. We only have completions for both success or failures (IO errors).

This means we have to use "txdone_poll" for FlexRM. For "txdone_poll",
we have to provide last_tx_done() callback. The last_tx_done() callback
is supposed to return true if last send_data() call succeeded.

To implement last_tx_done() in FlexRM driver, we added "last_pending_msg".

When "last_pending_msg" is NULL it means last call to send_data() succeeded
and when "last_pending_msg" is != NULL it means last call to send_data()
did not go through due to lack of space in FlexRM ring. The IRQ worker
of FlexRM ring will automatically queue the message pointed by
"last_pending_message" and clear it. This is why we have mbox_send_message()
call in flexrm_process_completions().

>
> 2) It calls mbox_chan_received_data()  which is for messages received
> from the remote. And not the way to report failed _transmission_, for
> which the api calls back mbox_client.tx_done() .  In your client
> driver please populate mbox_client.tx_done() and see which message is
> reported "sent fine" when.
>
>
> There seems no such provision. IIANW, then you should be able to
> consider every 

Re: [Eas-dev] [PATCH V4 2/3] cpufreq: schedutil: Process remote callback for shared policies

[Joel Fernandes (Google)]

On Wed, Jul 26, 2017 at 2:22 AM, Viresh Kumar  wrote:
> This patch updates the schedutil governor to process cpufreq utilization
> update hooks called for remote CPUs where the remote CPU is managed by
> the cpufreq policy of the local CPU.
>
> Based on initial work from Steve Muckle.
>
> Signed-off-by: Viresh Kumar 

Reviewed-by: Joel Fernandes 


thanks,

-Joel


> ---
>  kernel/sched/cpufreq_schedutil.c | 21 ++---
>  1 file changed, 10 insertions(+), 11 deletions(-)
>
> diff --git a/kernel/sched/cpufreq_schedutil.c 
> b/kernel/sched/cpufreq_schedutil.c
> index bb834747e49b..c3baf70d360c 100644
> --- a/kernel/sched/cpufreq_schedutil.c
> +++ b/kernel/sched/cpufreq_schedutil.c
> @@ -72,13 +72,12 @@ static DEFINE_PER_CPU(struct sugov_cpu, sugov_cpu);
>
>  / Governor internals ***/
>
> -static bool sugov_should_update_freq(struct sugov_policy *sg_policy, u64 
> time,
> -int target_cpu)
> +static bool sugov_should_update_freq(struct sugov_policy *sg_policy, u64 
> time)
>  {
> s64 delta_ns;
>
> -   /* Don't allow remote callbacks */
> -   if (smp_processor_id() != target_cpu)
> +   /* Allow remote callbacks only on the CPUs sharing cpufreq policy */
> +   if (!cpumask_test_cpu(smp_processor_id(), sg_policy->policy->cpus))
> return false;
>
> if (sg_policy->work_in_progress)
> @@ -159,12 +158,12 @@ static unsigned int get_next_freq(struct sugov_policy 
> *sg_policy,
> return cpufreq_driver_resolve_freq(policy, freq);
>  }
>
> -static void sugov_get_util(unsigned long *util, unsigned long *max)
> +static void sugov_get_util(unsigned long *util, unsigned long *max, int cpu)
>  {
> -   struct rq *rq = this_rq();
> +   struct rq *rq = cpu_rq(cpu);
> unsigned long cfs_max;
>
> -   cfs_max = arch_scale_cpu_capacity(NULL, smp_processor_id());
> +   cfs_max = arch_scale_cpu_capacity(NULL, cpu);
>
> *util = min(rq->cfs.avg.util_avg, cfs_max);
> *max = cfs_max;
> @@ -226,7 +225,7 @@ static void sugov_update_single(struct update_util_data 
> *hook, u64 time,
> sugov_set_iowait_boost(sg_cpu, time, flags);
> sg_cpu->last_update = time;
>
> -   if (!sugov_should_update_freq(sg_policy, time, hook->cpu))
> +   if (!sugov_should_update_freq(sg_policy, time))
> return;
>
> busy = sugov_cpu_is_busy(sg_cpu);
> @@ -234,7 +233,7 @@ static void sugov_update_single(struct update_util_data 
> *hook, u64 time,
> if (flags & SCHED_CPUFREQ_RT_DL) {
> next_f = policy->cpuinfo.max_freq;
> } else {
> -   sugov_get_util(, );
> +   sugov_get_util(, , hook->cpu);
> sugov_iowait_boost(sg_cpu, , );
> next_f = get_next_freq(sg_policy, util, max);
> /*
> @@ -295,7 +294,7 @@ static void sugov_update_shared(struct update_util_data 
> *hook, u64 time,
> unsigned long util, max;
> unsigned int next_f;
>
> -   sugov_get_util(, );
> +   sugov_get_util(, , hook->cpu);
>
> raw_spin_lock(_policy->update_lock);
>
> @@ -306,7 +305,7 @@ static void sugov_update_shared(struct update_util_data 
> *hook, u64 time,
> sugov_set_iowait_boost(sg_cpu, time, flags);
> sg_cpu->last_update = time;
>
> -   if (sugov_should_update_freq(sg_policy, time, hook->cpu)) {
> +   if (sugov_should_update_freq(sg_policy, time)) {
> if (flags & SCHED_CPUFREQ_RT_DL)
> next_f = sg_policy->policy->cpuinfo.max_freq;

Re: [Eas-dev] [PATCH V4 2/3] cpufreq: schedutil: Process remote callback for shared policies

[Joel Fernandes (Google)]

On Wed, Jul 26, 2017 at 2:22 AM, Viresh Kumar  wrote:
> This patch updates the schedutil governor to process cpufreq utilization
> update hooks called for remote CPUs where the remote CPU is managed by
> the cpufreq policy of the local CPU.
>
> Based on initial work from Steve Muckle.
>
> Signed-off-by: Viresh Kumar 

Reviewed-by: Joel Fernandes 


thanks,

-Joel


> ---
>  kernel/sched/cpufreq_schedutil.c | 21 ++---
>  1 file changed, 10 insertions(+), 11 deletions(-)
>
> diff --git a/kernel/sched/cpufreq_schedutil.c 
> b/kernel/sched/cpufreq_schedutil.c
> index bb834747e49b..c3baf70d360c 100644
> --- a/kernel/sched/cpufreq_schedutil.c
> +++ b/kernel/sched/cpufreq_schedutil.c
> @@ -72,13 +72,12 @@ static DEFINE_PER_CPU(struct sugov_cpu, sugov_cpu);
>
>  / Governor internals ***/
>
> -static bool sugov_should_update_freq(struct sugov_policy *sg_policy, u64 
> time,
> -int target_cpu)
> +static bool sugov_should_update_freq(struct sugov_policy *sg_policy, u64 
> time)
>  {
> s64 delta_ns;
>
> -   /* Don't allow remote callbacks */
> -   if (smp_processor_id() != target_cpu)
> +   /* Allow remote callbacks only on the CPUs sharing cpufreq policy */
> +   if (!cpumask_test_cpu(smp_processor_id(), sg_policy->policy->cpus))
> return false;
>
> if (sg_policy->work_in_progress)
> @@ -159,12 +158,12 @@ static unsigned int get_next_freq(struct sugov_policy 
> *sg_policy,
> return cpufreq_driver_resolve_freq(policy, freq);
>  }
>
> -static void sugov_get_util(unsigned long *util, unsigned long *max)
> +static void sugov_get_util(unsigned long *util, unsigned long *max, int cpu)
>  {
> -   struct rq *rq = this_rq();
> +   struct rq *rq = cpu_rq(cpu);
> unsigned long cfs_max;
>
> -   cfs_max = arch_scale_cpu_capacity(NULL, smp_processor_id());
> +   cfs_max = arch_scale_cpu_capacity(NULL, cpu);
>
> *util = min(rq->cfs.avg.util_avg, cfs_max);
> *max = cfs_max;
> @@ -226,7 +225,7 @@ static void sugov_update_single(struct update_util_data 
> *hook, u64 time,
> sugov_set_iowait_boost(sg_cpu, time, flags);
> sg_cpu->last_update = time;
>
> -   if (!sugov_should_update_freq(sg_policy, time, hook->cpu))
> +   if (!sugov_should_update_freq(sg_policy, time))
> return;
>
> busy = sugov_cpu_is_busy(sg_cpu);
> @@ -234,7 +233,7 @@ static void sugov_update_single(struct update_util_data 
> *hook, u64 time,
> if (flags & SCHED_CPUFREQ_RT_DL) {
> next_f = policy->cpuinfo.max_freq;
> } else {
> -   sugov_get_util(, );
> +   sugov_get_util(, , hook->cpu);
> sugov_iowait_boost(sg_cpu, , );
> next_f = get_next_freq(sg_policy, util, max);
> /*
> @@ -295,7 +294,7 @@ static void sugov_update_shared(struct update_util_data 
> *hook, u64 time,
> unsigned long util, max;
> unsigned int next_f;
>
> -   sugov_get_util(, );
> +   sugov_get_util(, , hook->cpu);
>
> raw_spin_lock(_policy->update_lock);
>
> @@ -306,7 +305,7 @@ static void sugov_update_shared(struct update_util_data 
> *hook, u64 time,
> sugov_set_iowait_boost(sg_cpu, time, flags);
> sg_cpu->last_update = time;
>
> -   if (sugov_should_update_freq(sg_policy, time, hook->cpu)) {
> +   if (sugov_should_update_freq(sg_policy, time)) {
> if (flags & SCHED_CPUFREQ_RT_DL)
> next_f = sg_policy->policy->cpuinfo.max_freq;

Re: [Eas-dev] [PATCH V4 0/3] sched: cpufreq: Allow remote callbacks

[Viresh Kumar]

On 26-07-17, 22:14, Joel Fernandes (Google) wrote:
> I think you dropped [1] in your cover-letter. May be you meant to add
> it at the end of the cover letter?
> 
> I noticed from your v2 that its:
> https://pastebin.com/7LkMSRxE

Yeah, I missed it. Thanks :)

> Also one more comment about this usecase:
> 
> You mentioned in our discussion at [2] sometime back, about the
> question of initial utilization,
> 
> "We don't have any such configurable way possible right
> now, but there were discussions on how much utilization should a new
> task be assigned when it first comes up."

We still initialize it to a value, just that it isn't configurable.
See below..

> But, then in your cover letter above, you mentioned "This is verified
> using ftrace". So my question is how has this been verified with
> ftrace if the new initial utilization as you said in [2] is currently
> still under discussion? Basically how could you verify with ftrace
> that the target CPU frequency isn't increasing immediately on spawning
> of a new task remotely, if the initial utilization of a new task isn't
> something we set/configure with current code? Am I missing something?
> 
> [2] https://lists.linaro.org/pipermail/eas-dev/2017-January/000785.html

The statement "new tasks should receive maximum demand initially" is
used to represent tasks which have high demand every time they run.
For example scrolling of a web page or gallery on our phones. Yes,
maybe I can use the work "migrated" (as you suggested later) as the
history of its utilization will move with it then to the new CPU.

But even without that, if you see the routine
init_entity_runnable_average() in fair.c, the new tasks are
initialized in a way that they are seen as heavy tasks. And so even
for the first time they run, freq should normally increase on the
target CPU (at least with above application).

The application was written by Steve (all credit goes to him) before
he left Linaro, but I did test it with ftrace. What I saw with ftrace
was that the freq isn't reevaluated for almost an entire tick many
times because we enqueued the task remotely. And that changes with
this series.

> > The reason being that this patchset only targets a corner case, where
> > following are required to be true to improve performance and that
> > doesn't happen too often with these tests:
> >
> > - Task is migrated to another CPU.
> > - The task has maximum demand initially, and should take the CPU to
> 
> Just to make the cover-letter more clear and also confirming with you
> I understand the above usecase, maybe in the future this can reworded
> from "initially" to "before the migration" and "take the CPU" to "take
> the target CPU of the migration" ?

I can reword it a bit, but the test case wasn't really migrating
anything and was looking only at the initial loads.

> >   higher OPPs.
> > - And the target CPU doesn't call into schedutil until the next tick.
> 
> I found this usecase to be more plausible and can see this patch
> series being useful there.
> 
> Could you also keep me in CC on these patches (at joe...@google.com)?
> I'm interested in this series.

Sure.

-- 
viresh

Re: [Eas-dev] [PATCH V4 0/3] sched: cpufreq: Allow remote callbacks

[Viresh Kumar]

On 26-07-17, 22:14, Joel Fernandes (Google) wrote:
> I think you dropped [1] in your cover-letter. May be you meant to add
> it at the end of the cover letter?
> 
> I noticed from your v2 that its:
> https://pastebin.com/7LkMSRxE

Yeah, I missed it. Thanks :)

> Also one more comment about this usecase:
> 
> You mentioned in our discussion at [2] sometime back, about the
> question of initial utilization,
> 
> "We don't have any such configurable way possible right
> now, but there were discussions on how much utilization should a new
> task be assigned when it first comes up."

We still initialize it to a value, just that it isn't configurable.
See below..

> But, then in your cover letter above, you mentioned "This is verified
> using ftrace". So my question is how has this been verified with
> ftrace if the new initial utilization as you said in [2] is currently
> still under discussion? Basically how could you verify with ftrace
> that the target CPU frequency isn't increasing immediately on spawning
> of a new task remotely, if the initial utilization of a new task isn't
> something we set/configure with current code? Am I missing something?
> 
> [2] https://lists.linaro.org/pipermail/eas-dev/2017-January/000785.html

The statement "new tasks should receive maximum demand initially" is
used to represent tasks which have high demand every time they run.
For example scrolling of a web page or gallery on our phones. Yes,
maybe I can use the work "migrated" (as you suggested later) as the
history of its utilization will move with it then to the new CPU.

But even without that, if you see the routine
init_entity_runnable_average() in fair.c, the new tasks are
initialized in a way that they are seen as heavy tasks. And so even
for the first time they run, freq should normally increase on the
target CPU (at least with above application).

The application was written by Steve (all credit goes to him) before
he left Linaro, but I did test it with ftrace. What I saw with ftrace
was that the freq isn't reevaluated for almost an entire tick many
times because we enqueued the task remotely. And that changes with
this series.

> > The reason being that this patchset only targets a corner case, where
> > following are required to be true to improve performance and that
> > doesn't happen too often with these tests:
> >
> > - Task is migrated to another CPU.
> > - The task has maximum demand initially, and should take the CPU to
> 
> Just to make the cover-letter more clear and also confirming with you
> I understand the above usecase, maybe in the future this can reworded
> from "initially" to "before the migration" and "take the CPU" to "take
> the target CPU of the migration" ?

I can reword it a bit, but the test case wasn't really migrating
anything and was looking only at the initial loads.

> >   higher OPPs.
> > - And the target CPU doesn't call into schedutil until the next tick.
> 
> I found this usecase to be more plausible and can see this patch
> series being useful there.
> 
> Could you also keep me in CC on these patches (at joe...@google.com)?
> I'm interested in this series.

Sure.

-- 
viresh

linux-next: Tree for Jul 27

[Stephen Rothwell]

Hi all,

Changes since 20170726:

Non-merge commits (relative to Linus' tree): 2581
 2620 files changed, 92132 insertions(+), 46797 deletions(-)



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

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

Below is a summary of the state of the merge.

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

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

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

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

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (fd2b2c57ec20 Merge tag 'scsi-fixes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi)
Merging fixes/master (b4b8cbf679c4 Cavium CNN55XX: fix broken default Kconfig 
entry)
Merging kbuild-current/fixes (ad8181060788 kconfig: fix sparse warnings in 
nconfig)
Merging arc-current/for-curr (37f1db0e85ff ARC: [plat-axs10x]: prepare dts 
files for enabling PAE40 on axs103)
Merging arm-current/fixes (ce184a0dee92 ARM: 8687/1: signal: Fix unparseable 
iwmmxt_sigframe in uc_regspace[])
Merging m68k-current/for-linus (204a2be30a7a m68k: Remove ptrace_signal_deliver)
Merging metag-fixes/fixes (b884a190afce metag/usercopy: Add missing fixups)
Merging powerpc-fixes/fixes (029d9252b116 powerpc/mm: Mark __init memory 
no-execute when STRICT_KERNEL_RWX=y)
Merging sparc/master (8cd3ec51c0c3 sbus: Convert to using %pOF instead of 
full_name)
Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and 
linking special files)
Merging net/master (d94708a55302 bonding: commit link status change after 
propose)
Merging ipsec/master (e6194923237f esp: Fix memleaks on error paths.)
Merging netfilter/master (f7fb77fc1235 netfilter: nft_compat: check extension 
hook mask only if set)
Merging ipvs/master (3c5ab3f395d6 ipvs: SNAT packet replies only for NATed 
connections)
Merging wireless-drivers/master (d755cbc26e82 Merge tag 
'iwlwifi-for-kalle-2017-07-21' of 
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes)
Merging mac80211/master (d7f13f745036 cfg80211: Validate frequencies nested in 
NL80211_ATTR_SCAN_FREQUENCIES)
Merging sound-current/for-linus (ba92b1142879 ALSA: hda - Add mute led support 
for HP ProBook 440 G4)
Merging pci-current/for-linus (34d5ac2af644 PCI: rockchip: Check for 
pci_scan_root_bus_bridge() failure correctly)
Merging driver-core.current/driver-core-linus (5771a8c08880 Linux v4.13-rc1)
Merging tty.current/tty-linus (520eccdfe187 Linux 4.13-rc2)
Merging usb.current/usb-linus (520eccdfe187 Linux 4.13-rc2)
Merging usb-gadget-fixes/fixes (520eccdfe187 Linux 4.13-rc2)
Merging usb-serial-fixes/usb-linus (9585e340db9f USB: serial: cp210x: add 
support for Qivicon USB ZigBee dongle)
Merging usb-chipidea-fixes/ci-for-usb-stable (cbb22ebcfb99 usb: chipidea: core: 
check before accessing ci_role in ci_role_show)
Merging phy/fixes (5771a8c08880 Linux v4.13-rc1)
Merging staging.current/staging-linus (055655a9f0fe Merge tag 
'iio-fixes-for-4.13a' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus)
Merging char-misc.current/char-misc-linus (520eccdfe187 Linux 4.13-rc2)
Merging input-current/for-linus (293b915fd9be Input: trackpoint - assume 3 
buttons when buttons detection fails)
Merging crypto-current/master (41cdf7a45389 crypto: authencesn - Fix 
digest_null crash)
Merging ide/master (921edf312a6a ide: avoid warning for timings calculation)
Merging vfio-fixes/for-linus (bb67b496c338 include/linux/vfio.h: Guard 
powerpc-specific functions with CONFIG_VFIO_SPAPR_EEH)
Mer

linux-next: Tree for Jul 27

[Stephen Rothwell]

Hi all,

Changes since 20170726:

Non-merge commits (relative to Linus' tree): 2581
 2620 files changed, 92132 insertions(+), 46797 deletions(-)



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

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

Below is a summary of the state of the merge.

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

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

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

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

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (fd2b2c57ec20 Merge tag 'scsi-fixes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi)
Merging fixes/master (b4b8cbf679c4 Cavium CNN55XX: fix broken default Kconfig 
entry)
Merging kbuild-current/fixes (ad8181060788 kconfig: fix sparse warnings in 
nconfig)
Merging arc-current/for-curr (37f1db0e85ff ARC: [plat-axs10x]: prepare dts 
files for enabling PAE40 on axs103)
Merging arm-current/fixes (ce184a0dee92 ARM: 8687/1: signal: Fix unparseable 
iwmmxt_sigframe in uc_regspace[])
Merging m68k-current/for-linus (204a2be30a7a m68k: Remove ptrace_signal_deliver)
Merging metag-fixes/fixes (b884a190afce metag/usercopy: Add missing fixups)
Merging powerpc-fixes/fixes (029d9252b116 powerpc/mm: Mark __init memory 
no-execute when STRICT_KERNEL_RWX=y)
Merging sparc/master (8cd3ec51c0c3 sbus: Convert to using %pOF instead of 
full_name)
Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and 
linking special files)
Merging net/master (d94708a55302 bonding: commit link status change after 
propose)
Merging ipsec/master (e6194923237f esp: Fix memleaks on error paths.)
Merging netfilter/master (f7fb77fc1235 netfilter: nft_compat: check extension 
hook mask only if set)
Merging ipvs/master (3c5ab3f395d6 ipvs: SNAT packet replies only for NATed 
connections)
Merging wireless-drivers/master (d755cbc26e82 Merge tag 
'iwlwifi-for-kalle-2017-07-21' of 
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes)
Merging mac80211/master (d7f13f745036 cfg80211: Validate frequencies nested in 
NL80211_ATTR_SCAN_FREQUENCIES)
Merging sound-current/for-linus (ba92b1142879 ALSA: hda - Add mute led support 
for HP ProBook 440 G4)
Merging pci-current/for-linus (34d5ac2af644 PCI: rockchip: Check for 
pci_scan_root_bus_bridge() failure correctly)
Merging driver-core.current/driver-core-linus (5771a8c08880 Linux v4.13-rc1)
Merging tty.current/tty-linus (520eccdfe187 Linux 4.13-rc2)
Merging usb.current/usb-linus (520eccdfe187 Linux 4.13-rc2)
Merging usb-gadget-fixes/fixes (520eccdfe187 Linux 4.13-rc2)
Merging usb-serial-fixes/usb-linus (9585e340db9f USB: serial: cp210x: add 
support for Qivicon USB ZigBee dongle)
Merging usb-chipidea-fixes/ci-for-usb-stable (cbb22ebcfb99 usb: chipidea: core: 
check before accessing ci_role in ci_role_show)
Merging phy/fixes (5771a8c08880 Linux v4.13-rc1)
Merging staging.current/staging-linus (055655a9f0fe Merge tag 
'iio-fixes-for-4.13a' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus)
Merging char-misc.current/char-misc-linus (520eccdfe187 Linux 4.13-rc2)
Merging input-current/for-linus (293b915fd9be Input: trackpoint - assume 3 
buttons when buttons detection fails)
Merging crypto-current/master (41cdf7a45389 crypto: authencesn - Fix 
digest_null crash)
Merging ide/master (921edf312a6a ide: avoid warning for timings calculation)
Merging vfio-fixes/for-linus (bb67b496c338 include/linux/vfio.h: Guard 
powerpc-specific functions with CONFIG_VFIO_SPAPR_EEH)
Mer

Re: [PATCH 09/12] ima: introduce securityfs interfaces for digest lists

[kbuild test robot]

Hi Roberto,

[auto build test WARNING on integrity/next]
[also build test WARNING on v4.13-rc2 next-20170726]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Roberto-Sassu/ima-measure-digest-lists-instead-of-individual-files/20170727-123131
base:   
https://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity.git next
config: x86_64-randconfig-x000-201730 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

   In file included from security/integrity/ima/ima_fs.c:27:0:
   security/integrity/ima/ima.h: In function 'ima_parse_digest_list_metadata':
   security/integrity/ima/ima.h:165:10: error: 'ENOTSUP' undeclared (first use 
in this function)
 return -ENOTSUP;
 ^~~
   security/integrity/ima/ima.h:165:10: note: each undeclared identifier is 
reported only once for each function it appears in
>> security/integrity/ima/ima.h:166:1: warning: control reaches end of non-void 
>> function [-Wreturn-type]
}
^

vim +166 security/integrity/ima/ima.h

d68a6fe9f Mimi Zohar  2016-12-19  135  
3323eec92 Mimi Zohar  2009-02-04  136  /* Internal IMA function definitions 
*/
3323eec92 Mimi Zohar  2009-02-04  137  int ima_init(void);
bab739378 Mimi Zohar  2009-02-04  138  int ima_fs_init(void);
3323eec92 Mimi Zohar  2009-02-04  139  int ima_add_template_entry(struct 
ima_template_entry *entry, int violation,
9803d413f Roberto Sassu   2013-06-07  140  const char 
*op, struct inode *inode,
9803d413f Roberto Sassu   2013-06-07  141  const 
unsigned char *filename);
c7c8bb237 Dmitry Kasatkin 2013-04-25  142  int ima_calc_file_hash(struct file 
*file, struct ima_digest_data *hash);
11d7646df Dmitry Kasatkin 2014-04-17  143  int ima_calc_buffer_hash(const void 
*buf, loff_t len,
11d7646df Dmitry Kasatkin 2014-04-17  144struct 
ima_digest_data *hash);
b6f8f16f4 Roberto Sassu   2013-11-08  145  int ima_calc_field_array_hash(struct 
ima_field_data *field_data,
b6f8f16f4 Roberto Sassu   2013-11-08  146 struct 
ima_template_desc *desc, int num_fields,
c7c8bb237 Dmitry Kasatkin 2013-04-25  147 struct 
ima_digest_data *hash);
09ef54359 Dmitry Kasatkin 2013-06-07  148  int __init 
ima_calc_boot_aggregate(struct ima_digest_data *hash);
7d802a227 Roberto Sassu   2013-06-07  149  void ima_add_violation(struct file 
*file, const unsigned char *filename,
8d94eb9b5 Roberto Sassu   2015-04-11  150  struct 
integrity_iint_cache *iint,
3323eec92 Mimi Zohar  2009-02-04  151  const char *op, 
const char *cause);
76bb28f61 Dmitry Kasatkin 2012-06-08  152  int ima_init_crypto(void);
3ce1217d6 Roberto Sassu   2013-06-07  153  void ima_putc(struct seq_file *m, 
void *data, int datalen);
45b26133b Mimi Zohar  2015-06-11  154  void ima_print_digest(struct 
seq_file *m, u8 *digest, u32 size);
a71dc65d3 Roberto Sassu   2013-06-07  155  struct ima_template_desc 
*ima_template_desc_current(void);
94c3aac56 Mimi Zohar  2016-12-19  156  int 
ima_restore_measurement_entry(struct ima_template_entry *entry);
94c3aac56 Mimi Zohar  2016-12-19  157  int 
ima_restore_measurement_list(loff_t bufsize, void *buf);
4b1c19b3d Roberto Sassu   2017-07-25  158  struct ima_digest 
*ima_lookup_loaded_digest(u8 *digest);
4b1c19b3d Roberto Sassu   2017-07-25  159  int ima_add_digest_data_entry(u8 
*digest);
3580b2df6 Roberto Sassu   2017-07-25  160  #ifdef CONFIG_IMA_DIGEST_LIST
3580b2df6 Roberto Sassu   2017-07-25  161  ssize_t 
ima_parse_digest_list_metadata(loff_t size, void *buf);
3580b2df6 Roberto Sassu   2017-07-25  162  #else
3580b2df6 Roberto Sassu   2017-07-25  163  static inline ssize_t 
ima_parse_digest_list_metadata(loff_t size, void *buf)
3580b2df6 Roberto Sassu   2017-07-25  164  {
3580b2df6 Roberto Sassu   2017-07-25 @165   return -ENOTSUP;
3580b2df6 Roberto Sassu   2017-07-25 @166  }
3580b2df6 Roberto Sassu   2017-07-25  167  #endif
7b8589cc2 Mimi Zohar  2016-12-19  168  int ima_measurements_show(struct 
seq_file *m, void *v);
d158847ae Mimi Zohar  2016-12-19  169  unsigned long 
ima_get_binary_runtime_size(void);
a71dc65d3 Roberto Sassu   2013-06-07  170  int ima_init_template(void);
3f23d624d Mimi Zohar  2016-12-19  171  void ima_init_template_list(void);
3323eec92 Mimi Zohar  2009-02-04  172  

:: The code at line 166 was first introduced by commit
:: 3580b2df63c2ec47030a481fea2d2c865124aff4 ima: added parser of digest 
lists metadata

:: TO: Roberto Sassu <roberto.sa...@huawei.com>
:: CC: 0day robot <fengguang...@intel.com>

---
0-DAY kernel test infrastructureOpen Source Technology Center

Re: [PATCH 09/12] ima: introduce securityfs interfaces for digest lists

[kbuild test robot]

Hi Roberto,

[auto build test WARNING on integrity/next]
[also build test WARNING on v4.13-rc2 next-20170726]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Roberto-Sassu/ima-measure-digest-lists-instead-of-individual-files/20170727-123131
base:   
https://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity.git next
config: x86_64-randconfig-x000-201730 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

   In file included from security/integrity/ima/ima_fs.c:27:0:
   security/integrity/ima/ima.h: In function 'ima_parse_digest_list_metadata':
   security/integrity/ima/ima.h:165:10: error: 'ENOTSUP' undeclared (first use 
in this function)
 return -ENOTSUP;
 ^~~
   security/integrity/ima/ima.h:165:10: note: each undeclared identifier is 
reported only once for each function it appears in
>> security/integrity/ima/ima.h:166:1: warning: control reaches end of non-void 
>> function [-Wreturn-type]
}
^

vim +166 security/integrity/ima/ima.h

d68a6fe9f Mimi Zohar  2016-12-19  135  
3323eec92 Mimi Zohar  2009-02-04  136  /* Internal IMA function definitions 
*/
3323eec92 Mimi Zohar  2009-02-04  137  int ima_init(void);
bab739378 Mimi Zohar  2009-02-04  138  int ima_fs_init(void);
3323eec92 Mimi Zohar  2009-02-04  139  int ima_add_template_entry(struct 
ima_template_entry *entry, int violation,
9803d413f Roberto Sassu   2013-06-07  140  const char 
*op, struct inode *inode,
9803d413f Roberto Sassu   2013-06-07  141  const 
unsigned char *filename);
c7c8bb237 Dmitry Kasatkin 2013-04-25  142  int ima_calc_file_hash(struct file 
*file, struct ima_digest_data *hash);
11d7646df Dmitry Kasatkin 2014-04-17  143  int ima_calc_buffer_hash(const void 
*buf, loff_t len,
11d7646df Dmitry Kasatkin 2014-04-17  144struct 
ima_digest_data *hash);
b6f8f16f4 Roberto Sassu   2013-11-08  145  int ima_calc_field_array_hash(struct 
ima_field_data *field_data,
b6f8f16f4 Roberto Sassu   2013-11-08  146 struct 
ima_template_desc *desc, int num_fields,
c7c8bb237 Dmitry Kasatkin 2013-04-25  147 struct 
ima_digest_data *hash);
09ef54359 Dmitry Kasatkin 2013-06-07  148  int __init 
ima_calc_boot_aggregate(struct ima_digest_data *hash);
7d802a227 Roberto Sassu   2013-06-07  149  void ima_add_violation(struct file 
*file, const unsigned char *filename,
8d94eb9b5 Roberto Sassu   2015-04-11  150  struct 
integrity_iint_cache *iint,
3323eec92 Mimi Zohar  2009-02-04  151  const char *op, 
const char *cause);
76bb28f61 Dmitry Kasatkin 2012-06-08  152  int ima_init_crypto(void);
3ce1217d6 Roberto Sassu   2013-06-07  153  void ima_putc(struct seq_file *m, 
void *data, int datalen);
45b26133b Mimi Zohar  2015-06-11  154  void ima_print_digest(struct 
seq_file *m, u8 *digest, u32 size);
a71dc65d3 Roberto Sassu   2013-06-07  155  struct ima_template_desc 
*ima_template_desc_current(void);
94c3aac56 Mimi Zohar  2016-12-19  156  int 
ima_restore_measurement_entry(struct ima_template_entry *entry);
94c3aac56 Mimi Zohar  2016-12-19  157  int 
ima_restore_measurement_list(loff_t bufsize, void *buf);
4b1c19b3d Roberto Sassu   2017-07-25  158  struct ima_digest 
*ima_lookup_loaded_digest(u8 *digest);
4b1c19b3d Roberto Sassu   2017-07-25  159  int ima_add_digest_data_entry(u8 
*digest);
3580b2df6 Roberto Sassu   2017-07-25  160  #ifdef CONFIG_IMA_DIGEST_LIST
3580b2df6 Roberto Sassu   2017-07-25  161  ssize_t 
ima_parse_digest_list_metadata(loff_t size, void *buf);
3580b2df6 Roberto Sassu   2017-07-25  162  #else
3580b2df6 Roberto Sassu   2017-07-25  163  static inline ssize_t 
ima_parse_digest_list_metadata(loff_t size, void *buf)
3580b2df6 Roberto Sassu   2017-07-25  164  {
3580b2df6 Roberto Sassu   2017-07-25 @165   return -ENOTSUP;
3580b2df6 Roberto Sassu   2017-07-25 @166  }
3580b2df6 Roberto Sassu   2017-07-25  167  #endif
7b8589cc2 Mimi Zohar  2016-12-19  168  int ima_measurements_show(struct 
seq_file *m, void *v);
d158847ae Mimi Zohar  2016-12-19  169  unsigned long 
ima_get_binary_runtime_size(void);
a71dc65d3 Roberto Sassu   2013-06-07  170  int ima_init_template(void);
3f23d624d Mimi Zohar  2016-12-19  171  void ima_init_template_list(void);
3323eec92 Mimi Zohar  2009-02-04  172  

:: The code at line 166 was first introduced by commit
:: 3580b2df63c2ec47030a481fea2d2c865124aff4 ima: added parser of digest 
lists metadata

:: TO: Roberto Sassu 
:: CC: 0day robot 

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

Re: [f2fs-dev] [PATCH 1/2] f2fs: expose /sys/fs/f2fs/features

[Chao Yu]

On 2017/7/27 5:43, Jaegeuk Kim wrote:
> On 07/26, Chao Yu wrote:
>> On 2017/7/26 9:29, Jaegeuk Kim wrote:
>>> This patch exposes what features are supported by current f2fs build to 
>>> sysfs
>>> entry.
>>>
>>> Signed-off-by: Jaegeuk Kim 
>>
>> Reviewed-by: Chao Yu 
>>
>> Minor thing, can you exchange below function name to follow ext4:
>> f2fs_init_sysfs <-> f2fs_register_sysfs
>> f2fs_exit_sysfs <-> f2fs_unregister_sysfs
>>
>>From 4cf8a3138f3ee171750ae279fefd4de672a0ee29 Mon Sep 17 00:00:00 2001
> From: Jaegeuk Kim 
> Date: Wed, 26 Jul 2017 11:24:13 -0700
> Subject: [PATCH] f2fs: avoid naming confusion of sysfs init
> 
> This patch changes the function names of sysfs init to follow ext4.
> 
> f2fs_init_sysfs <-> f2fs_register_sysfs
> f2fs_exit_sysfs <-> f2fs_unregister_sysfs
> 
> Suggested-by: Chao Yu 
> Signed-off-by: Jaegeuk Kim 

Reivewed-by: Chao Yu 

Thanks,

> ---
>  fs/f2fs/f2fs.h  |  8 
>  fs/f2fs/super.c | 10 +-
>  fs/f2fs/sysfs.c |  8 
>  3 files changed, 13 insertions(+), 13 deletions(-)
> 
> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> index d486539086b6..a1bfd0b9be44 100644
> --- a/fs/f2fs/f2fs.h
> +++ b/fs/f2fs/f2fs.h
> @@ -2820,10 +2820,10 @@ void destroy_extent_cache(void);
>  /*
>   * sysfs.c
>   */
> -int __init f2fs_register_sysfs(void);
> -void f2fs_unregister_sysfs(void);
> -int f2fs_init_sysfs(struct f2fs_sb_info *sbi);
> -void f2fs_exit_sysfs(struct f2fs_sb_info *sbi);
> +int __init f2fs_init_sysfs(void);
> +void f2fs_exit_sysfs(void);
> +int f2fs_register_sysfs(struct f2fs_sb_info *sbi);
> +void f2fs_unregister_sysfs(struct f2fs_sb_info *sbi);
>  
>  /*
>   * crypto support
> diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
> index 1241739f4d54..12513caabe6e 100644
> --- a/fs/f2fs/super.c
> +++ b/fs/f2fs/super.c
> @@ -649,7 +649,7 @@ static void f2fs_put_super(struct super_block *sb)
>  
>   kfree(sbi->ckpt);
>  
> - f2fs_exit_sysfs(sbi);
> + f2fs_unregister_sysfs(sbi);
>  
>   sb->s_fs_info = NULL;
>   if (sbi->s_chksum_driver)
> @@ -2145,7 +2145,7 @@ static int f2fs_fill_super(struct super_block *sb, void 
> *data, int silent)
>   goto free_root_inode;
>   }
>  
> - err = f2fs_init_sysfs(sbi);
> + err = f2fs_register_sysfs(sbi);
>   if (err)
>   goto free_root_inode;
>  
> @@ -2216,7 +2216,7 @@ static int f2fs_fill_super(struct super_block *sb, void 
> *data, int silent)
>  
>  free_sysfs:
>   f2fs_sync_inode_meta(sbi);
> - f2fs_exit_sysfs(sbi);
> + f2fs_unregister_sysfs(sbi);
>  free_root_inode:
>   dput(sb->s_root);
>   sb->s_root = NULL;
> @@ -2334,7 +2334,7 @@ static int __init init_f2fs_fs(void)
>   err = create_extent_cache();
>   if (err)
>   goto free_checkpoint_caches;
> - err = f2fs_register_sysfs();
> + err = f2fs_init_sysfs();
>   if (err)
>   goto free_extent_cache;
>   err = register_shrinker(_shrinker_info);
> @@ -2373,7 +2373,7 @@ static void __exit exit_f2fs_fs(void)
>   f2fs_destroy_root_stats();
>   unregister_filesystem(_fs_type);
>   unregister_shrinker(_shrinker_info);
> - f2fs_unregister_sysfs();
> + f2fs_exit_sysfs();
>   destroy_extent_cache();
>   destroy_checkpoint_caches();
>   destroy_segment_manager_caches();
> diff --git a/fs/f2fs/sysfs.c b/fs/f2fs/sysfs.c
> index 71191d89917d..5a78b9af92ef 100644
> --- a/fs/f2fs/sysfs.c
> +++ b/fs/f2fs/sysfs.c
> @@ -304,7 +304,7 @@ static const struct file_operations 
> f2fs_seq_##_name##_fops = {   \
>  F2FS_PROC_FILE_DEF(segment_info);
>  F2FS_PROC_FILE_DEF(segment_bits);
>  
> -int __init f2fs_register_sysfs(void)
> +int __init f2fs_init_sysfs(void)
>  {
>   f2fs_proc_root = proc_mkdir("fs/f2fs", NULL);
>  
> @@ -314,13 +314,13 @@ int __init f2fs_register_sysfs(void)
>   return 0;
>  }
>  
> -void f2fs_unregister_sysfs(void)
> +void f2fs_exit_sysfs(void)
>  {
>   kset_unregister(f2fs_kset);
>   remove_proc_entry("fs/f2fs", NULL);
>  }
>  
> -int f2fs_init_sysfs(struct f2fs_sb_info *sbi)
> +int f2fs_register_sysfs(struct f2fs_sb_info *sbi)
>  {
>   struct super_block *sb = sbi->sb;
>   int err;
> @@ -351,7 +351,7 @@ int f2fs_init_sysfs(struct f2fs_sb_info *sbi)
>   return err;
>  }
>  
> -void f2fs_exit_sysfs(struct f2fs_sb_info *sbi)
> +void f2fs_unregister_sysfs(struct f2fs_sb_info *sbi)
>  {
>   kobject_del(>s_kobj);
>   kobject_put(>s_kobj);
> 

Re: [f2fs-dev] [PATCH 1/2] f2fs: expose /sys/fs/f2fs/features

[Chao Yu]

On 2017/7/27 5:43, Jaegeuk Kim wrote:
> On 07/26, Chao Yu wrote:
>> On 2017/7/26 9:29, Jaegeuk Kim wrote:
>>> This patch exposes what features are supported by current f2fs build to 
>>> sysfs
>>> entry.
>>>
>>> Signed-off-by: Jaegeuk Kim 
>>
>> Reviewed-by: Chao Yu 
>>
>> Minor thing, can you exchange below function name to follow ext4:
>> f2fs_init_sysfs <-> f2fs_register_sysfs
>> f2fs_exit_sysfs <-> f2fs_unregister_sysfs
>>
>>From 4cf8a3138f3ee171750ae279fefd4de672a0ee29 Mon Sep 17 00:00:00 2001
> From: Jaegeuk Kim 
> Date: Wed, 26 Jul 2017 11:24:13 -0700
> Subject: [PATCH] f2fs: avoid naming confusion of sysfs init
> 
> This patch changes the function names of sysfs init to follow ext4.
> 
> f2fs_init_sysfs <-> f2fs_register_sysfs
> f2fs_exit_sysfs <-> f2fs_unregister_sysfs
> 
> Suggested-by: Chao Yu 
> Signed-off-by: Jaegeuk Kim 

Reivewed-by: Chao Yu 

Thanks,

> ---
>  fs/f2fs/f2fs.h  |  8 
>  fs/f2fs/super.c | 10 +-
>  fs/f2fs/sysfs.c |  8 
>  3 files changed, 13 insertions(+), 13 deletions(-)
> 
> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> index d486539086b6..a1bfd0b9be44 100644
> --- a/fs/f2fs/f2fs.h
> +++ b/fs/f2fs/f2fs.h
> @@ -2820,10 +2820,10 @@ void destroy_extent_cache(void);
>  /*
>   * sysfs.c
>   */
> -int __init f2fs_register_sysfs(void);
> -void f2fs_unregister_sysfs(void);
> -int f2fs_init_sysfs(struct f2fs_sb_info *sbi);
> -void f2fs_exit_sysfs(struct f2fs_sb_info *sbi);
> +int __init f2fs_init_sysfs(void);
> +void f2fs_exit_sysfs(void);
> +int f2fs_register_sysfs(struct f2fs_sb_info *sbi);
> +void f2fs_unregister_sysfs(struct f2fs_sb_info *sbi);
>  
>  /*
>   * crypto support
> diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
> index 1241739f4d54..12513caabe6e 100644
> --- a/fs/f2fs/super.c
> +++ b/fs/f2fs/super.c
> @@ -649,7 +649,7 @@ static void f2fs_put_super(struct super_block *sb)
>  
>   kfree(sbi->ckpt);
>  
> - f2fs_exit_sysfs(sbi);
> + f2fs_unregister_sysfs(sbi);
>  
>   sb->s_fs_info = NULL;
>   if (sbi->s_chksum_driver)
> @@ -2145,7 +2145,7 @@ static int f2fs_fill_super(struct super_block *sb, void 
> *data, int silent)
>   goto free_root_inode;
>   }
>  
> - err = f2fs_init_sysfs(sbi);
> + err = f2fs_register_sysfs(sbi);
>   if (err)
>   goto free_root_inode;
>  
> @@ -2216,7 +2216,7 @@ static int f2fs_fill_super(struct super_block *sb, void 
> *data, int silent)
>  
>  free_sysfs:
>   f2fs_sync_inode_meta(sbi);
> - f2fs_exit_sysfs(sbi);
> + f2fs_unregister_sysfs(sbi);
>  free_root_inode:
>   dput(sb->s_root);
>   sb->s_root = NULL;
> @@ -2334,7 +2334,7 @@ static int __init init_f2fs_fs(void)
>   err = create_extent_cache();
>   if (err)
>   goto free_checkpoint_caches;
> - err = f2fs_register_sysfs();
> + err = f2fs_init_sysfs();
>   if (err)
>   goto free_extent_cache;
>   err = register_shrinker(_shrinker_info);
> @@ -2373,7 +2373,7 @@ static void __exit exit_f2fs_fs(void)
>   f2fs_destroy_root_stats();
>   unregister_filesystem(_fs_type);
>   unregister_shrinker(_shrinker_info);
> - f2fs_unregister_sysfs();
> + f2fs_exit_sysfs();
>   destroy_extent_cache();
>   destroy_checkpoint_caches();
>   destroy_segment_manager_caches();
> diff --git a/fs/f2fs/sysfs.c b/fs/f2fs/sysfs.c
> index 71191d89917d..5a78b9af92ef 100644
> --- a/fs/f2fs/sysfs.c
> +++ b/fs/f2fs/sysfs.c
> @@ -304,7 +304,7 @@ static const struct file_operations 
> f2fs_seq_##_name##_fops = {   \
>  F2FS_PROC_FILE_DEF(segment_info);
>  F2FS_PROC_FILE_DEF(segment_bits);
>  
> -int __init f2fs_register_sysfs(void)
> +int __init f2fs_init_sysfs(void)
>  {
>   f2fs_proc_root = proc_mkdir("fs/f2fs", NULL);
>  
> @@ -314,13 +314,13 @@ int __init f2fs_register_sysfs(void)
>   return 0;
>  }
>  
> -void f2fs_unregister_sysfs(void)
> +void f2fs_exit_sysfs(void)
>  {
>   kset_unregister(f2fs_kset);
>   remove_proc_entry("fs/f2fs", NULL);
>  }
>  
> -int f2fs_init_sysfs(struct f2fs_sb_info *sbi)
> +int f2fs_register_sysfs(struct f2fs_sb_info *sbi)
>  {
>   struct super_block *sb = sbi->sb;
>   int err;
> @@ -351,7 +351,7 @@ int f2fs_init_sysfs(struct f2fs_sb_info *sbi)
>   return err;
>  }
>  
> -void f2fs_exit_sysfs(struct f2fs_sb_info *sbi)
> +void f2fs_unregister_sysfs(struct f2fs_sb_info *sbi)
>  {
>   kobject_del(>s_kobj);
>   kobject_put(>s_kobj);
> 

Re: [Eas-dev] [PATCH V4 1/3] sched: cpufreq: Allow remote cpufreq callbacks

[Joel Fernandes (Google)]

Hi Viresh,

On Wed, Jul 26, 2017 at 2:22 AM, Viresh Kumar  wrote:
> We do not call cpufreq callbacks from scheduler core for remote
> (non-local) CPUs currently. But there are cases where such remote
> callbacks are useful, specially in the case of shared cpufreq policies.
>
> This patch updates the scheduler core to call the cpufreq callbacks for
> remote CPUs as well.
>
> For now, all the registered utilization update callbacks are updated to
> return early if remote callback is detected. That is, this patch just
> moves the decision making down in the hierarchy.
>
> Later patches would enable remote callbacks for shared policies.
>
> Based on initial work from Steve Muckle.
>
> Signed-off-by: Viresh Kumar 

> --- a/kernel/sched/cpufreq_schedutil.c
> +++ b/kernel/sched/cpufreq_schedutil.c
> @@ -72,10 +72,15 @@ static DEFINE_PER_CPU(struct sugov_cpu, sugov_cpu);
>
>  / Governor internals ***/
>
> -static bool sugov_should_update_freq(struct sugov_policy *sg_policy, u64 
> time)
> +static bool sugov_should_update_freq(struct sugov_policy *sg_policy, u64 
> time,
> +int target_cpu)
>  {
> s64 delta_ns;
>
> +   /* Don't allow remote callbacks */
> +   if (smp_processor_id() != target_cpu)
> +   return false;
> +
> if (sg_policy->work_in_progress)
> return false;
>
> @@ -221,7 +226,7 @@ static void sugov_update_single(struct update_util_data 
> *hook, u64 time,
> sugov_set_iowait_boost(sg_cpu, time, flags);
> sg_cpu->last_update = time;
>
> -   if (!sugov_should_update_freq(sg_policy, time))
> +   if (!sugov_should_update_freq(sg_policy, time, hook->cpu))
> return;

Since with the remote callbacks now possible, isn't it unsafe to
modify sg_cpu and sg_policy structures without a lock in
sugov_update_single?

Unlike sugov_update_shared, we don't acquire any lock in
sugov_update_single before updating these structures. Did I miss
something?


thanks,

-Joel

Re: [Eas-dev] [PATCH V4 1/3] sched: cpufreq: Allow remote cpufreq callbacks

[Joel Fernandes (Google)]

Hi Viresh,

On Wed, Jul 26, 2017 at 2:22 AM, Viresh Kumar  wrote:
> We do not call cpufreq callbacks from scheduler core for remote
> (non-local) CPUs currently. But there are cases where such remote
> callbacks are useful, specially in the case of shared cpufreq policies.
>
> This patch updates the scheduler core to call the cpufreq callbacks for
> remote CPUs as well.
>
> For now, all the registered utilization update callbacks are updated to
> return early if remote callback is detected. That is, this patch just
> moves the decision making down in the hierarchy.
>
> Later patches would enable remote callbacks for shared policies.
>
> Based on initial work from Steve Muckle.
>
> Signed-off-by: Viresh Kumar 

> --- a/kernel/sched/cpufreq_schedutil.c
> +++ b/kernel/sched/cpufreq_schedutil.c
> @@ -72,10 +72,15 @@ static DEFINE_PER_CPU(struct sugov_cpu, sugov_cpu);
>
>  / Governor internals ***/
>
> -static bool sugov_should_update_freq(struct sugov_policy *sg_policy, u64 
> time)
> +static bool sugov_should_update_freq(struct sugov_policy *sg_policy, u64 
> time,
> +int target_cpu)
>  {
> s64 delta_ns;
>
> +   /* Don't allow remote callbacks */
> +   if (smp_processor_id() != target_cpu)
> +   return false;
> +
> if (sg_policy->work_in_progress)
> return false;
>
> @@ -221,7 +226,7 @@ static void sugov_update_single(struct update_util_data 
> *hook, u64 time,
> sugov_set_iowait_boost(sg_cpu, time, flags);
> sg_cpu->last_update = time;
>
> -   if (!sugov_should_update_freq(sg_policy, time))
> +   if (!sugov_should_update_freq(sg_policy, time, hook->cpu))
> return;

Since with the remote callbacks now possible, isn't it unsafe to
modify sg_cpu and sg_policy structures without a lock in
sugov_update_single?

Unlike sugov_update_shared, we don't acquire any lock in
sugov_update_single before updating these structures. Did I miss
something?


thanks,

-Joel

Re: [PATCH 3/3] EDAC, ghes: Make it a proper module

[Borislav Petkov]

On Wed, Jul 26, 2017 at 07:24:59PM +, Kani, Toshimitsu wrote:
> Using sb_edac does not change the fact that it is FF.  I do not think
> you'd see normal CEs on your box.

I guess we should add some blurb to EDAC to say that on FF systems,
error counts are unreliable or even non-existent.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--

Re: [PATCH 3/3] EDAC, ghes: Make it a proper module

[Borislav Petkov]

On Wed, Jul 26, 2017 at 07:24:59PM +, Kani, Toshimitsu wrote:
> Using sb_edac does not change the fact that it is FF.  I do not think
> you'd see normal CEs on your box.

I guess we should add some blurb to EDAC to say that on FF systems,
error counts are unreliable or even non-existent.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--

Re: [PATCH v2 04/22] fpga: mgr: add region_id to fpga_image_info

[Wu Hao]

On Wed, Jul 26, 2017 at 01:33:53PM -0500, Alan Tull wrote:
> On Sun, Jun 25, 2017 at 8:52 PM, Wu Hao  wrote:
> 
> Hi Hao,
> 
> > This patch adds region_id to fpga_image_info data structure, it
> > allows driver to pass region id information to fpga-mgr via
> > fpga_image_info for fpga reconfiguration function.
> >
> > Signed-off-by: Wu Hao 
> > ---
> >  include/linux/fpga/fpga-mgr.h | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/include/linux/fpga/fpga-mgr.h b/include/linux/fpga/fpga-mgr.h
> > index 66d0e32..b222a57 100644
> > --- a/include/linux/fpga/fpga-mgr.h
> > +++ b/include/linux/fpga/fpga-mgr.h
> > @@ -95,6 +95,7 @@ struct fpga_image_info {
> > struct sg_table *sgt;
> > const char *buf;
> > size_t count;
> > +   int region_id;
> 
> Please add a line to document this region_id above where all the other
> struct members are documented.

Hi Alan

Thanks for the comments, I will fix this in the next version.

  * @sgt: scatter/gather table containing FPGA image
  * @buf: contiguous buffer containing FPGA image
  * @count: size of buf
+ * @region_id: id of target region
  * @overlay: Device Tree overlay
  */
 struct fpga_image_info {

Thanks
Hao

> 
> Alan
> 
> >  #ifdef CONFIG_OF
> > struct device_node *overlay;
> >  #endif
> > --
> > 1.8.3.1
> >

Re: [PATCH v2 04/22] fpga: mgr: add region_id to fpga_image_info

[Wu Hao]

On Wed, Jul 26, 2017 at 01:33:53PM -0500, Alan Tull wrote:
> On Sun, Jun 25, 2017 at 8:52 PM, Wu Hao  wrote:
> 
> Hi Hao,
> 
> > This patch adds region_id to fpga_image_info data structure, it
> > allows driver to pass region id information to fpga-mgr via
> > fpga_image_info for fpga reconfiguration function.
> >
> > Signed-off-by: Wu Hao 
> > ---
> >  include/linux/fpga/fpga-mgr.h | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/include/linux/fpga/fpga-mgr.h b/include/linux/fpga/fpga-mgr.h
> > index 66d0e32..b222a57 100644
> > --- a/include/linux/fpga/fpga-mgr.h
> > +++ b/include/linux/fpga/fpga-mgr.h
> > @@ -95,6 +95,7 @@ struct fpga_image_info {
> > struct sg_table *sgt;
> > const char *buf;
> > size_t count;
> > +   int region_id;
> 
> Please add a line to document this region_id above where all the other
> struct members are documented.

Hi Alan

Thanks for the comments, I will fix this in the next version.

  * @sgt: scatter/gather table containing FPGA image
  * @buf: contiguous buffer containing FPGA image
  * @count: size of buf
+ * @region_id: id of target region
  * @overlay: Device Tree overlay
  */
 struct fpga_image_info {

Thanks
Hao

> 
> Alan
> 
> >  #ifdef CONFIG_OF
> > struct device_node *overlay;
> >  #endif
> > --
> > 1.8.3.1
> >

Re: [PATCH 06/12] ima: added parser of digest lists metadata

[kbuild test robot]

Hi Roberto,

[auto build test ERROR on integrity/next]
[also build test ERROR on v4.13-rc2 next-20170726]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Roberto-Sassu/ima-measure-digest-lists-instead-of-individual-files/20170727-123131
base:   
https://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity.git next
config: x86_64-randconfig-x000-201730 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   In file included from security/integrity/ima/ima_fs.c:27:0:
   security/integrity/ima/ima.h: In function 'ima_parse_digest_list_metadata':
>> security/integrity/ima/ima.h:165:10: error: 'ENOTSUP' undeclared (first use 
>> in this function)
 return -ENOTSUP;
 ^~~
   security/integrity/ima/ima.h:165:10: note: each undeclared identifier is 
reported only once for each function it appears in

vim +/ENOTSUP +165 security/integrity/ima/ima.h

   135  
   136  /* Internal IMA function definitions */
   137  int ima_init(void);
   138  int ima_fs_init(void);
   139  int ima_add_template_entry(struct ima_template_entry *entry, int 
violation,
   140 const char *op, struct inode *inode,
   141 const unsigned char *filename);
   142  int ima_calc_file_hash(struct file *file, struct ima_digest_data *hash);
   143  int ima_calc_buffer_hash(const void *buf, loff_t len,
   144   struct ima_digest_data *hash);
   145  int ima_calc_field_array_hash(struct ima_field_data *field_data,
   146struct ima_template_desc *desc, int 
num_fields,
   147struct ima_digest_data *hash);
   148  int __init ima_calc_boot_aggregate(struct ima_digest_data *hash);
   149  void ima_add_violation(struct file *file, const unsigned char *filename,
   150 struct integrity_iint_cache *iint,
   151 const char *op, const char *cause);
   152  int ima_init_crypto(void);
   153  void ima_putc(struct seq_file *m, void *data, int datalen);
   154  void ima_print_digest(struct seq_file *m, u8 *digest, u32 size);
   155  struct ima_template_desc *ima_template_desc_current(void);
   156  int ima_restore_measurement_entry(struct ima_template_entry *entry);
   157  int ima_restore_measurement_list(loff_t bufsize, void *buf);
   158  struct ima_digest *ima_lookup_loaded_digest(u8 *digest);
   159  int ima_add_digest_data_entry(u8 *digest);
   160  #ifdef CONFIG_IMA_DIGEST_LIST
   161  ssize_t ima_parse_digest_list_metadata(loff_t size, void *buf);
   162  #else
   163  static inline ssize_t ima_parse_digest_list_metadata(loff_t size, void 
*buf)
   164  {
 > 165  return -ENOTSUP;
   166  }
   167  #endif
   168  int ima_measurements_show(struct seq_file *m, void *v);
   169  unsigned long ima_get_binary_runtime_size(void);
   170  int ima_init_template(void);
   171  void ima_init_template_list(void);
   172  

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


.config.gz
Description: application/gzip

Re: [PATCH 06/12] ima: added parser of digest lists metadata

[kbuild test robot]

Hi Roberto,

[auto build test ERROR on integrity/next]
[also build test ERROR on v4.13-rc2 next-20170726]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Roberto-Sassu/ima-measure-digest-lists-instead-of-individual-files/20170727-123131
base:   
https://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity.git next
config: x86_64-randconfig-x000-201730 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   In file included from security/integrity/ima/ima_fs.c:27:0:
   security/integrity/ima/ima.h: In function 'ima_parse_digest_list_metadata':
>> security/integrity/ima/ima.h:165:10: error: 'ENOTSUP' undeclared (first use 
>> in this function)
 return -ENOTSUP;
 ^~~
   security/integrity/ima/ima.h:165:10: note: each undeclared identifier is 
reported only once for each function it appears in

vim +/ENOTSUP +165 security/integrity/ima/ima.h

   135  
   136  /* Internal IMA function definitions */
   137  int ima_init(void);
   138  int ima_fs_init(void);
   139  int ima_add_template_entry(struct ima_template_entry *entry, int 
violation,
   140 const char *op, struct inode *inode,
   141 const unsigned char *filename);
   142  int ima_calc_file_hash(struct file *file, struct ima_digest_data *hash);
   143  int ima_calc_buffer_hash(const void *buf, loff_t len,
   144   struct ima_digest_data *hash);
   145  int ima_calc_field_array_hash(struct ima_field_data *field_data,
   146struct ima_template_desc *desc, int 
num_fields,
   147struct ima_digest_data *hash);
   148  int __init ima_calc_boot_aggregate(struct ima_digest_data *hash);
   149  void ima_add_violation(struct file *file, const unsigned char *filename,
   150 struct integrity_iint_cache *iint,
   151 const char *op, const char *cause);
   152  int ima_init_crypto(void);
   153  void ima_putc(struct seq_file *m, void *data, int datalen);
   154  void ima_print_digest(struct seq_file *m, u8 *digest, u32 size);
   155  struct ima_template_desc *ima_template_desc_current(void);
   156  int ima_restore_measurement_entry(struct ima_template_entry *entry);
   157  int ima_restore_measurement_list(loff_t bufsize, void *buf);
   158  struct ima_digest *ima_lookup_loaded_digest(u8 *digest);
   159  int ima_add_digest_data_entry(u8 *digest);
   160  #ifdef CONFIG_IMA_DIGEST_LIST
   161  ssize_t ima_parse_digest_list_metadata(loff_t size, void *buf);
   162  #else
   163  static inline ssize_t ima_parse_digest_list_metadata(loff_t size, void 
*buf)
   164  {
 > 165  return -ENOTSUP;
   166  }
   167  #endif
   168  int ima_measurements_show(struct seq_file *m, void *v);
   169  unsigned long ima_get_binary_runtime_size(void);
   170  int ima_init_template(void);
   171  void ima_init_template_list(void);
   172  

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


.config.gz
Description: application/gzip

[PATCH v4 1/3] include: uapi: usb: Introduce USB charger type and state definition

[Baolin Wang]

Introducing USB charger type and state definition can help
to support USB charging which will be added in USB phy core.

Signed-off-by: Baolin Wang 
---
 include/uapi/linux/usb/charger.h |   31 +++
 1 file changed, 31 insertions(+)
 create mode 100644 include/uapi/linux/usb/charger.h

diff --git a/include/uapi/linux/usb/charger.h b/include/uapi/linux/usb/charger.h
new file mode 100644
index 000..5f72af3
--- /dev/null
+++ b/include/uapi/linux/usb/charger.h
@@ -0,0 +1,31 @@
+/*
+ * This file defines the USB charger type and state that are needed for
+ * USB device APIs.
+ */
+
+#ifndef _UAPI__LINUX_USB_CHARGER_H
+#define _UAPI__LINUX_USB_CHARGER_H
+
+/*
+ * USB charger type:
+ * SDP (Standard Downstream Port)
+ * DCP (Dedicated Charging Port)
+ * CDP (Charging Downstream Port)
+ * ACA (Accessory Charger Adapters)
+ */
+enum usb_charger_type {
+   UNKNOWN_TYPE,
+   SDP_TYPE,
+   DCP_TYPE,
+   CDP_TYPE,
+   ACA_TYPE,
+};
+
+/* USB charger state */
+enum usb_charger_state {
+   USB_CHARGER_DEFAULT,
+   USB_CHARGER_PRESENT,
+   USB_CHARGER_ABSENT,
+};
+
+#endif /* _UAPI__LINUX_USB_CHARGER_H */
-- 
1.7.9.5

[PATCH v4 1/3] include: uapi: usb: Introduce USB charger type and state definition

[Baolin Wang]

Introducing USB charger type and state definition can help
to support USB charging which will be added in USB phy core.

Signed-off-by: Baolin Wang 
---
 include/uapi/linux/usb/charger.h |   31 +++
 1 file changed, 31 insertions(+)
 create mode 100644 include/uapi/linux/usb/charger.h

diff --git a/include/uapi/linux/usb/charger.h b/include/uapi/linux/usb/charger.h
new file mode 100644
index 000..5f72af3
--- /dev/null
+++ b/include/uapi/linux/usb/charger.h
@@ -0,0 +1,31 @@
+/*
+ * This file defines the USB charger type and state that are needed for
+ * USB device APIs.
+ */
+
+#ifndef _UAPI__LINUX_USB_CHARGER_H
+#define _UAPI__LINUX_USB_CHARGER_H
+
+/*
+ * USB charger type:
+ * SDP (Standard Downstream Port)
+ * DCP (Dedicated Charging Port)
+ * CDP (Charging Downstream Port)
+ * ACA (Accessory Charger Adapters)
+ */
+enum usb_charger_type {
+   UNKNOWN_TYPE,
+   SDP_TYPE,
+   DCP_TYPE,
+   CDP_TYPE,
+   ACA_TYPE,
+};
+
+/* USB charger state */
+enum usb_charger_state {
+   USB_CHARGER_DEFAULT,
+   USB_CHARGER_PRESENT,
+   USB_CHARGER_ABSENT,
+};
+
+#endif /* _UAPI__LINUX_USB_CHARGER_H */
-- 
1.7.9.5

[PATCH v4 2/3] usb: phy: Add USB charger support

[Baolin Wang]

This patch introduces the usb charger support based on usb phy that
makes an enhancement to a power driver. The basic conception of the
usb charger is that, when one usb charger is added or removed by
reporting from the extcon device state change, the usb charger will
report to power user to set the current limitation.

Power user can register a notifiee on the usb phy by issuing
usb_register_notifier() to get notified by charger status changes
or charger current changes.

we can notify what current to be drawn to power user according to
different charger type, and now we have 2 methods to get charger type.
One is get charger type from extcon subsystem, which also means the
charger state changes. Another is we can get the charger type from
USB controller detecting or PMIC detecting, and the charger state
changes should be told by issuing usb_phy_set_charger_state().

Signed-off-by: Baolin Wang 
---
 drivers/usb/phy/phy.c   |  272 +++
 include/linux/usb/phy.h |   49 +
 2 files changed, 321 insertions(+)

diff --git a/drivers/usb/phy/phy.c b/drivers/usb/phy/phy.c
index 032f5af..2dc48bb 100644
--- a/drivers/usb/phy/phy.c
+++ b/drivers/usb/phy/phy.c
@@ -18,6 +18,18 @@
 
 #include 
 
+/* Default current range by charger type. */
+#define DEFAULT_SDP_CUR_MIN2
+#define DEFAULT_SDP_CUR_MAX500
+#define DEFAULT_SDP_CUR_MIN_SS 150
+#define DEFAULT_SDP_CUR_MAX_SS 900
+#define DEFAULT_DCP_CUR_MIN500
+#define DEFAULT_DCP_CUR_MAX5000
+#define DEFAULT_CDP_CUR_MIN1500
+#define DEFAULT_CDP_CUR_MAX5000
+#define DEFAULT_ACA_CUR_MIN1500
+#define DEFAULT_ACA_CUR_MAX5000
+
 static LIST_HEAD(phy_list);
 static LIST_HEAD(phy_bind_list);
 static DEFINE_SPINLOCK(phy_lock);
@@ -77,6 +89,221 @@ static struct usb_phy *__of_usb_find_phy(struct device_node 
*node)
return ERR_PTR(-EPROBE_DEFER);
 }
 
+static void usb_phy_set_default_current(struct usb_phy *usb_phy)
+{
+   usb_phy->chg_cur.sdp_min = DEFAULT_SDP_CUR_MIN;
+   usb_phy->chg_cur.sdp_max = DEFAULT_SDP_CUR_MAX;
+   usb_phy->chg_cur.dcp_min = DEFAULT_DCP_CUR_MIN;
+   usb_phy->chg_cur.dcp_max = DEFAULT_DCP_CUR_MAX;
+   usb_phy->chg_cur.cdp_min = DEFAULT_CDP_CUR_MIN;
+   usb_phy->chg_cur.cdp_max = DEFAULT_CDP_CUR_MAX;
+   usb_phy->chg_cur.aca_min = DEFAULT_ACA_CUR_MIN;
+   usb_phy->chg_cur.aca_max = DEFAULT_ACA_CUR_MAX;
+}
+
+/**
+ * usb_phy_notify_charger_work - notify the USB charger state
+ * @work - the charger work to notify the USB charger state
+ *
+ * This work can be issued when USB charger state has been changed or
+ * USB charger current has been changed, then we can notify the current
+ * what can be drawn to power user and the charger state to userspace.
+ *
+ * If we get the charger type from extcon subsystem, we can notify the
+ * charger state to power user automatically by usb_phy_get_charger_type()
+ * issuing from extcon subsystem.
+ *
+ * If we get the charger type from ->charger_detect() instead of extcon
+ * subsystem, the usb phy driver should issue usb_phy_set_charger_state()
+ * to set charger state when the charger state has been changed.
+ */
+static void usb_phy_notify_charger_work(struct work_struct *work)
+{
+   struct usb_phy *usb_phy = container_of(work, struct usb_phy, chg_work);
+   char uchger_state[50] = { 0 };
+   char *envp[] = { uchger_state, NULL };
+   unsigned int min, max;
+
+   switch (usb_phy->chg_state) {
+   case USB_CHARGER_PRESENT:
+   usb_phy_get_charger_current(usb_phy, , );
+
+   atomic_notifier_call_chain(_phy->notifier, max, usb_phy);
+   snprintf(uchger_state, ARRAY_SIZE(uchger_state),
+"USB_CHARGER_STATE=%s", "USB_CHARGER_PRESENT");
+   break;
+   case USB_CHARGER_ABSENT:
+   usb_phy_set_default_current(usb_phy);
+
+   atomic_notifier_call_chain(_phy->notifier, 0, usb_phy);
+   snprintf(uchger_state, ARRAY_SIZE(uchger_state),
+"USB_CHARGER_STATE=%s", "USB_CHARGER_ABSENT");
+   break;
+   default:
+   dev_warn(usb_phy->dev, "Unknown USB charger state: %d\n",
+usb_phy->chg_state);
+   return;
+   }
+
+   kobject_uevent_env(_phy->dev->kobj, KOBJ_CHANGE, envp);
+}
+
+static void __usb_phy_get_charger_type(struct usb_phy *usb_phy)
+{
+   if (extcon_get_state(usb_phy->edev, EXTCON_CHG_USB_SDP) > 0) {
+   usb_phy->chg_type = SDP_TYPE;
+   usb_phy->chg_state = USB_CHARGER_PRESENT;
+   } else if (extcon_get_state(usb_phy->edev, EXTCON_CHG_USB_CDP) > 0) {
+   usb_phy->chg_type = CDP_TYPE;
+   usb_phy->chg_state = USB_CHARGER_PRESENT;
+   } else if (extcon_get_state(usb_phy->edev, EXTCON_CHG_USB_DCP) > 0) {
+   usb_phy->chg_type = DCP_TYPE;
+   usb_phy->chg_state = 

[PATCH v4 3/3] power: wm831x_power: Support USB charger current limit management

[Baolin Wang]

Integrate with the newly added USB charger interface to limit the current
we draw from the USB input based on the input device configuration
identified by the USB stack, allowing us to charge more quickly from high
current inputs without drawing more current than specified from others.

Signed-off-by: Mark Brown 
Signed-off-by: Baolin Wang 
Acked-by: Lee Jones 
Acked-by: Charles Keepax 
---
 Documentation/devicetree/bindings/mfd/wm831x.txt |1 +
 drivers/power/supply/wm831x_power.c  |   72 ++
 2 files changed, 73 insertions(+)

diff --git a/Documentation/devicetree/bindings/mfd/wm831x.txt 
b/Documentation/devicetree/bindings/mfd/wm831x.txt
index 9f8b743..4e3bc07 100644
--- a/Documentation/devicetree/bindings/mfd/wm831x.txt
+++ b/Documentation/devicetree/bindings/mfd/wm831x.txt
@@ -31,6 +31,7 @@ Required properties:
 ../interrupt-controller/interrupts.txt
 
 Optional sub-nodes:
+  - usb-phy : Contains a phandle to the USB PHY.
   - regulators : Contains sub-nodes for each of the regulators supplied by
 the device. The regulators are bound using their names listed below:
 
diff --git a/drivers/power/supply/wm831x_power.c 
b/drivers/power/supply/wm831x_power.c
index 7082301..dff6473 100644
--- a/drivers/power/supply/wm831x_power.c
+++ b/drivers/power/supply/wm831x_power.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -31,6 +32,8 @@ struct wm831x_power {
char usb_name[20];
char battery_name[20];
bool have_battery;
+   struct usb_phy *usb_phy;
+   struct notifier_block usb_notify;
 };
 
 static int wm831x_power_check_online(struct wm831x *wm831x, int supply,
@@ -125,6 +128,43 @@ static int wm831x_usb_get_prop(struct power_supply *psy,
POWER_SUPPLY_PROP_VOLTAGE_NOW,
 };
 
+/* In milliamps */
+static const unsigned int wm831x_usb_limits[] = {
+   0,
+   2,
+   100,
+   500,
+   900,
+   1500,
+   1800,
+   550,
+};
+
+static int wm831x_usb_limit_change(struct notifier_block *nb,
+  unsigned long limit, void *data)
+{
+   struct wm831x_power *wm831x_power = container_of(nb,
+struct wm831x_power,
+usb_notify);
+   unsigned int i, best;
+
+   /* Find the highest supported limit */
+   best = 0;
+   for (i = 0; i < ARRAY_SIZE(wm831x_usb_limits); i++) {
+   if (limit >= wm831x_usb_limits[i] &&
+   wm831x_usb_limits[best] < wm831x_usb_limits[i])
+   best = i;
+   }
+
+   dev_dbg(wm831x_power->wm831x->dev,
+   "Limiting USB current to %umA", wm831x_usb_limits[best]);
+
+   wm831x_set_bits(wm831x_power->wm831x, WM831X_POWER_STATE,
+   WM831X_USB_ILIM_MASK, best);
+
+   return 0;
+}
+
 /*
  * Battery properties
  */
@@ -607,6 +647,33 @@ static int wm831x_power_probe(struct platform_device *pdev)
}
}
 
+   power->usb_phy = devm_usb_get_phy_by_phandle(>dev, "usb-phy", 0);
+   ret = PTR_ERR_OR_ZERO(power->usb_phy);
+
+   switch (ret) {
+   case 0:
+   power->usb_notify.notifier_call = wm831x_usb_limit_change;
+   ret = usb_register_notifier(power->usb_phy, >usb_notify);
+   if (ret) {
+   dev_err(>dev, "Failed to register notifier: %d\n",
+   ret);
+   goto err_bat_irq;
+   }
+   break;
+   case -EINVAL:
+   case -ENODEV:
+   /* ignore missing usb-phy, it's optional */
+   power->usb_phy = NULL;
+   ret = 0;
+   break;
+   default:
+   dev_err(>dev, "Failed to find USB phy: %d\n", ret);
+   /* fall-through */
+   case -EPROBE_DEFER:
+   goto err_bat_irq;
+   break;
+   }
+
return ret;
 
 err_bat_irq:
@@ -637,6 +704,11 @@ static int wm831x_power_remove(struct platform_device 
*pdev)
struct wm831x *wm831x = wm831x_power->wm831x;
int irq, i;
 
+   if (wm831x_power->usb_phy) {
+   usb_unregister_notifier(wm831x_power->usb_phy,
+   _power->usb_notify);
+   }
+
for (i = 0; i < ARRAY_SIZE(wm831x_bat_irqs); i++) {
irq = wm831x_irq(wm831x, 
 platform_get_irq_byname(pdev,
-- 
1.7.9.5

[PATCH v4 2/3] usb: phy: Add USB charger support

[Baolin Wang]

This patch introduces the usb charger support based on usb phy that
makes an enhancement to a power driver. The basic conception of the
usb charger is that, when one usb charger is added or removed by
reporting from the extcon device state change, the usb charger will
report to power user to set the current limitation.

Power user can register a notifiee on the usb phy by issuing
usb_register_notifier() to get notified by charger status changes
or charger current changes.

we can notify what current to be drawn to power user according to
different charger type, and now we have 2 methods to get charger type.
One is get charger type from extcon subsystem, which also means the
charger state changes. Another is we can get the charger type from
USB controller detecting or PMIC detecting, and the charger state
changes should be told by issuing usb_phy_set_charger_state().

Signed-off-by: Baolin Wang 
---
 drivers/usb/phy/phy.c   |  272 +++
 include/linux/usb/phy.h |   49 +
 2 files changed, 321 insertions(+)

diff --git a/drivers/usb/phy/phy.c b/drivers/usb/phy/phy.c
index 032f5af..2dc48bb 100644
--- a/drivers/usb/phy/phy.c
+++ b/drivers/usb/phy/phy.c
@@ -18,6 +18,18 @@
 
 #include 
 
+/* Default current range by charger type. */
+#define DEFAULT_SDP_CUR_MIN2
+#define DEFAULT_SDP_CUR_MAX500
+#define DEFAULT_SDP_CUR_MIN_SS 150
+#define DEFAULT_SDP_CUR_MAX_SS 900
+#define DEFAULT_DCP_CUR_MIN500
+#define DEFAULT_DCP_CUR_MAX5000
+#define DEFAULT_CDP_CUR_MIN1500
+#define DEFAULT_CDP_CUR_MAX5000
+#define DEFAULT_ACA_CUR_MIN1500
+#define DEFAULT_ACA_CUR_MAX5000
+
 static LIST_HEAD(phy_list);
 static LIST_HEAD(phy_bind_list);
 static DEFINE_SPINLOCK(phy_lock);
@@ -77,6 +89,221 @@ static struct usb_phy *__of_usb_find_phy(struct device_node 
*node)
return ERR_PTR(-EPROBE_DEFER);
 }
 
+static void usb_phy_set_default_current(struct usb_phy *usb_phy)
+{
+   usb_phy->chg_cur.sdp_min = DEFAULT_SDP_CUR_MIN;
+   usb_phy->chg_cur.sdp_max = DEFAULT_SDP_CUR_MAX;
+   usb_phy->chg_cur.dcp_min = DEFAULT_DCP_CUR_MIN;
+   usb_phy->chg_cur.dcp_max = DEFAULT_DCP_CUR_MAX;
+   usb_phy->chg_cur.cdp_min = DEFAULT_CDP_CUR_MIN;
+   usb_phy->chg_cur.cdp_max = DEFAULT_CDP_CUR_MAX;
+   usb_phy->chg_cur.aca_min = DEFAULT_ACA_CUR_MIN;
+   usb_phy->chg_cur.aca_max = DEFAULT_ACA_CUR_MAX;
+}
+
+/**
+ * usb_phy_notify_charger_work - notify the USB charger state
+ * @work - the charger work to notify the USB charger state
+ *
+ * This work can be issued when USB charger state has been changed or
+ * USB charger current has been changed, then we can notify the current
+ * what can be drawn to power user and the charger state to userspace.
+ *
+ * If we get the charger type from extcon subsystem, we can notify the
+ * charger state to power user automatically by usb_phy_get_charger_type()
+ * issuing from extcon subsystem.
+ *
+ * If we get the charger type from ->charger_detect() instead of extcon
+ * subsystem, the usb phy driver should issue usb_phy_set_charger_state()
+ * to set charger state when the charger state has been changed.
+ */
+static void usb_phy_notify_charger_work(struct work_struct *work)
+{
+   struct usb_phy *usb_phy = container_of(work, struct usb_phy, chg_work);
+   char uchger_state[50] = { 0 };
+   char *envp[] = { uchger_state, NULL };
+   unsigned int min, max;
+
+   switch (usb_phy->chg_state) {
+   case USB_CHARGER_PRESENT:
+   usb_phy_get_charger_current(usb_phy, , );
+
+   atomic_notifier_call_chain(_phy->notifier, max, usb_phy);
+   snprintf(uchger_state, ARRAY_SIZE(uchger_state),
+"USB_CHARGER_STATE=%s", "USB_CHARGER_PRESENT");
+   break;
+   case USB_CHARGER_ABSENT:
+   usb_phy_set_default_current(usb_phy);
+
+   atomic_notifier_call_chain(_phy->notifier, 0, usb_phy);
+   snprintf(uchger_state, ARRAY_SIZE(uchger_state),
+"USB_CHARGER_STATE=%s", "USB_CHARGER_ABSENT");
+   break;
+   default:
+   dev_warn(usb_phy->dev, "Unknown USB charger state: %d\n",
+usb_phy->chg_state);
+   return;
+   }
+
+   kobject_uevent_env(_phy->dev->kobj, KOBJ_CHANGE, envp);
+}
+
+static void __usb_phy_get_charger_type(struct usb_phy *usb_phy)
+{
+   if (extcon_get_state(usb_phy->edev, EXTCON_CHG_USB_SDP) > 0) {
+   usb_phy->chg_type = SDP_TYPE;
+   usb_phy->chg_state = USB_CHARGER_PRESENT;
+   } else if (extcon_get_state(usb_phy->edev, EXTCON_CHG_USB_CDP) > 0) {
+   usb_phy->chg_type = CDP_TYPE;
+   usb_phy->chg_state = USB_CHARGER_PRESENT;
+   } else if (extcon_get_state(usb_phy->edev, EXTCON_CHG_USB_DCP) > 0) {
+   usb_phy->chg_type = DCP_TYPE;
+   usb_phy->chg_state = USB_CHARGER_PRESENT;
+   } else if 

[PATCH v4 3/3] power: wm831x_power: Support USB charger current limit management

[Baolin Wang]

Integrate with the newly added USB charger interface to limit the current
we draw from the USB input based on the input device configuration
identified by the USB stack, allowing us to charge more quickly from high
current inputs without drawing more current than specified from others.

Signed-off-by: Mark Brown 
Signed-off-by: Baolin Wang 
Acked-by: Lee Jones 
Acked-by: Charles Keepax 
---
 Documentation/devicetree/bindings/mfd/wm831x.txt |1 +
 drivers/power/supply/wm831x_power.c  |   72 ++
 2 files changed, 73 insertions(+)

diff --git a/Documentation/devicetree/bindings/mfd/wm831x.txt 
b/Documentation/devicetree/bindings/mfd/wm831x.txt
index 9f8b743..4e3bc07 100644
--- a/Documentation/devicetree/bindings/mfd/wm831x.txt
+++ b/Documentation/devicetree/bindings/mfd/wm831x.txt
@@ -31,6 +31,7 @@ Required properties:
 ../interrupt-controller/interrupts.txt
 
 Optional sub-nodes:
+  - usb-phy : Contains a phandle to the USB PHY.
   - regulators : Contains sub-nodes for each of the regulators supplied by
 the device. The regulators are bound using their names listed below:
 
diff --git a/drivers/power/supply/wm831x_power.c 
b/drivers/power/supply/wm831x_power.c
index 7082301..dff6473 100644
--- a/drivers/power/supply/wm831x_power.c
+++ b/drivers/power/supply/wm831x_power.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -31,6 +32,8 @@ struct wm831x_power {
char usb_name[20];
char battery_name[20];
bool have_battery;
+   struct usb_phy *usb_phy;
+   struct notifier_block usb_notify;
 };
 
 static int wm831x_power_check_online(struct wm831x *wm831x, int supply,
@@ -125,6 +128,43 @@ static int wm831x_usb_get_prop(struct power_supply *psy,
POWER_SUPPLY_PROP_VOLTAGE_NOW,
 };
 
+/* In milliamps */
+static const unsigned int wm831x_usb_limits[] = {
+   0,
+   2,
+   100,
+   500,
+   900,
+   1500,
+   1800,
+   550,
+};
+
+static int wm831x_usb_limit_change(struct notifier_block *nb,
+  unsigned long limit, void *data)
+{
+   struct wm831x_power *wm831x_power = container_of(nb,
+struct wm831x_power,
+usb_notify);
+   unsigned int i, best;
+
+   /* Find the highest supported limit */
+   best = 0;
+   for (i = 0; i < ARRAY_SIZE(wm831x_usb_limits); i++) {
+   if (limit >= wm831x_usb_limits[i] &&
+   wm831x_usb_limits[best] < wm831x_usb_limits[i])
+   best = i;
+   }
+
+   dev_dbg(wm831x_power->wm831x->dev,
+   "Limiting USB current to %umA", wm831x_usb_limits[best]);
+
+   wm831x_set_bits(wm831x_power->wm831x, WM831X_POWER_STATE,
+   WM831X_USB_ILIM_MASK, best);
+
+   return 0;
+}
+
 /*
  * Battery properties
  */
@@ -607,6 +647,33 @@ static int wm831x_power_probe(struct platform_device *pdev)
}
}
 
+   power->usb_phy = devm_usb_get_phy_by_phandle(>dev, "usb-phy", 0);
+   ret = PTR_ERR_OR_ZERO(power->usb_phy);
+
+   switch (ret) {
+   case 0:
+   power->usb_notify.notifier_call = wm831x_usb_limit_change;
+   ret = usb_register_notifier(power->usb_phy, >usb_notify);
+   if (ret) {
+   dev_err(>dev, "Failed to register notifier: %d\n",
+   ret);
+   goto err_bat_irq;
+   }
+   break;
+   case -EINVAL:
+   case -ENODEV:
+   /* ignore missing usb-phy, it's optional */
+   power->usb_phy = NULL;
+   ret = 0;
+   break;
+   default:
+   dev_err(>dev, "Failed to find USB phy: %d\n", ret);
+   /* fall-through */
+   case -EPROBE_DEFER:
+   goto err_bat_irq;
+   break;
+   }
+
return ret;
 
 err_bat_irq:
@@ -637,6 +704,11 @@ static int wm831x_power_remove(struct platform_device 
*pdev)
struct wm831x *wm831x = wm831x_power->wm831x;
int irq, i;
 
+   if (wm831x_power->usb_phy) {
+   usb_unregister_notifier(wm831x_power->usb_phy,
+   _power->usb_notify);
+   }
+
for (i = 0; i < ARRAY_SIZE(wm831x_bat_irqs); i++) {
irq = wm831x_irq(wm831x, 
 platform_get_irq_byname(pdev,
-- 
1.7.9.5

[PATCH v4 0/3] Introduce USB charger support in USB phy

[Baolin Wang]

Currently the Linux kernel does not provide any standard integration of this
feature that integrates the USB subsystem with the system power regulation
provided by PMICs meaning that either vendors must add this in their kernels
or USB gadget devices based on Linux (such as mobile phones) may not behave
as they should. Thus provide a standard USB charger support in USB phy core
for doing this in kernel.

Now introduce one user with wm831x_power to support and test the usb charger.
In future we will also cnvert below power drivers:
drivers/power/supply/axp288_charger.c
drivers/power/supply/bq24190_charger.c
drivers/power/supply/charger-manager.c
drivers/power/supply/qcom_smbb.c

Changes since v3:
 - Bail out errors when failed to find usb phy for wm831x_power driver.
Changes since v2:
 - Add DT binding documentation for wm831x_power driver.
 - Change 'usb-phy' as one optional property for wm831x_power driver.
Changes since v1:
 - Fix building errors.

Baolin Wang (3):
  include: uapi: usb: Introduce USB charger type and state definition
  usb: phy: Add USB charger support
  power: wm831x_power: Support USB charger current limit management

 Documentation/devicetree/bindings/mfd/wm831x.txt |1 +
 drivers/power/supply/wm831x_power.c  |   72 ++
 drivers/usb/phy/phy.c|  272 ++
 include/linux/usb/phy.h  |   49 
 include/uapi/linux/usb/charger.h |   31 +++
 5 files changed, 425 insertions(+)
 create mode 100644 include/uapi/linux/usb/charger.h

-- 
1.7.9.5

Re: [Eas-dev] [PATCH V4 0/3] sched: cpufreq: Allow remote callbacks

[Joel Fernandes (Google)]

Hi Viresh,

On Wed, Jul 26, 2017 at 2:22 AM, Viresh Kumar  wrote:

>
> With Android UI and benchmarks the latency of cpufreq response to
> certain scheduling events can become very critical. Currently, callbacks
> into schedutil are only made from the scheduler if the target CPU of the
> event is the same as the current CPU. This means there are certain
> situations where a target CPU may not run schedutil for some time.
>
> One testcase to show this behavior is where a task starts running on
> CPU0, then a new task is also spawned on CPU0 by a task on CPU1. If the
> system is configured such that new tasks should receive maximum demand
> initially, this should result in CPU0 increasing frequency immediately.
> Because of the above mentioned limitation though this does not occur.
> This is verified using ftrace with the sample [1] application.

I think you dropped [1] in your cover-letter. May be you meant to add
it at the end of the cover letter?

I noticed from your v2 that its:
https://pastebin.com/7LkMSRxE

Also one more comment about this usecase:

You mentioned in our discussion at [2] sometime back, about the
question of initial utilization,

"We don't have any such configurable way possible right
now, but there were discussions on how much utilization should a new
task be assigned when it first comes up."

But, then in your cover letter above, you mentioned "This is verified
using ftrace". So my question is how has this been verified with
ftrace if the new initial utilization as you said in [2] is currently
still under discussion? Basically how could you verify with ftrace
that the target CPU frequency isn't increasing immediately on spawning
of a new task remotely, if the initial utilization of a new task isn't
something we set/configure with current code? Am I missing something?

[2] https://lists.linaro.org/pipermail/eas-dev/2017-January/000785.html

>
> Maybe the ideal solution is to always allow remote callbacks but that
> has its own challenges:
>
> o There is no protection required for single CPU per policy case today,
>   and adding any kind of locking there, to supply remote callbacks,
>   isn't really a good idea.
>
> o If is local CPU isn't part of the same cpufreq policy as the target
>   CPU, then we wouldn't be able to do fast switching at all and have to
>   use some kind of bottom half to schedule work on the target CPU to do
>   real switching. That may be overkill as well.
>
>
> And so this series only allows remote callbacks for target CPUs that
> share the cpufreq policy with the local CPU.
>
> This series is tested with couple of usecases (Android: hackbench,
> recentfling, galleryfling, vellamo, Ubuntu: hackbench) on ARM hikey
> board (64 bit octa-core, single policy). Only galleryfling showed minor
> improvements, while others didn't had much deviation.
>
> The reason being that this patchset only targets a corner case, where
> following are required to be true to improve performance and that
> doesn't happen too often with these tests:
>
> - Task is migrated to another CPU.
> - The task has maximum demand initially, and should take the CPU to

Just to make the cover-letter more clear and also confirming with you
I understand the above usecase, maybe in the future this can reworded
from "initially" to "before the migration" and "take the CPU" to "take
the target CPU of the migration" ?

>   higher OPPs.
> - And the target CPU doesn't call into schedutil until the next tick.

I found this usecase to be more plausible and can see this patch
series being useful there.

Could you also keep me in CC on these patches (at joe...@google.com)?
I'm interested in this series.

thanks!

-Joel

Re: [Eas-dev] [PATCH V4 0/3] sched: cpufreq: Allow remote callbacks

[Joel Fernandes (Google)]

Hi Viresh,

On Wed, Jul 26, 2017 at 2:22 AM, Viresh Kumar  wrote:

>
> With Android UI and benchmarks the latency of cpufreq response to
> certain scheduling events can become very critical. Currently, callbacks
> into schedutil are only made from the scheduler if the target CPU of the
> event is the same as the current CPU. This means there are certain
> situations where a target CPU may not run schedutil for some time.
>
> One testcase to show this behavior is where a task starts running on
> CPU0, then a new task is also spawned on CPU0 by a task on CPU1. If the
> system is configured such that new tasks should receive maximum demand
> initially, this should result in CPU0 increasing frequency immediately.
> Because of the above mentioned limitation though this does not occur.
> This is verified using ftrace with the sample [1] application.

I think you dropped [1] in your cover-letter. May be you meant to add
it at the end of the cover letter?

I noticed from your v2 that its:
https://pastebin.com/7LkMSRxE

Also one more comment about this usecase:

You mentioned in our discussion at [2] sometime back, about the
question of initial utilization,

"We don't have any such configurable way possible right
now, but there were discussions on how much utilization should a new
task be assigned when it first comes up."

But, then in your cover letter above, you mentioned "This is verified
using ftrace". So my question is how has this been verified with
ftrace if the new initial utilization as you said in [2] is currently
still under discussion? Basically how could you verify with ftrace
that the target CPU frequency isn't increasing immediately on spawning
of a new task remotely, if the initial utilization of a new task isn't
something we set/configure with current code? Am I missing something?

[2] https://lists.linaro.org/pipermail/eas-dev/2017-January/000785.html

>
> Maybe the ideal solution is to always allow remote callbacks but that
> has its own challenges:
>
> o There is no protection required for single CPU per policy case today,
>   and adding any kind of locking there, to supply remote callbacks,
>   isn't really a good idea.
>
> o If is local CPU isn't part of the same cpufreq policy as the target
>   CPU, then we wouldn't be able to do fast switching at all and have to
>   use some kind of bottom half to schedule work on the target CPU to do
>   real switching. That may be overkill as well.
>
>
> And so this series only allows remote callbacks for target CPUs that
> share the cpufreq policy with the local CPU.
>
> This series is tested with couple of usecases (Android: hackbench,
> recentfling, galleryfling, vellamo, Ubuntu: hackbench) on ARM hikey
> board (64 bit octa-core, single policy). Only galleryfling showed minor
> improvements, while others didn't had much deviation.
>
> The reason being that this patchset only targets a corner case, where
> following are required to be true to improve performance and that
> doesn't happen too often with these tests:
>
> - Task is migrated to another CPU.
> - The task has maximum demand initially, and should take the CPU to

Just to make the cover-letter more clear and also confirming with you
I understand the above usecase, maybe in the future this can reworded
from "initially" to "before the migration" and "take the CPU" to "take
the target CPU of the migration" ?

>   higher OPPs.
> - And the target CPU doesn't call into schedutil until the next tick.

I found this usecase to be more plausible and can see this patch
series being useful there.

Could you also keep me in CC on these patches (at joe...@google.com)?
I'm interested in this series.

thanks!

-Joel

[PATCH v4 0/3] Introduce USB charger support in USB phy

[Baolin Wang]

Currently the Linux kernel does not provide any standard integration of this
feature that integrates the USB subsystem with the system power regulation
provided by PMICs meaning that either vendors must add this in their kernels
or USB gadget devices based on Linux (such as mobile phones) may not behave
as they should. Thus provide a standard USB charger support in USB phy core
for doing this in kernel.

Now introduce one user with wm831x_power to support and test the usb charger.
In future we will also cnvert below power drivers:
drivers/power/supply/axp288_charger.c
drivers/power/supply/bq24190_charger.c
drivers/power/supply/charger-manager.c
drivers/power/supply/qcom_smbb.c

Changes since v3:
 - Bail out errors when failed to find usb phy for wm831x_power driver.
Changes since v2:
 - Add DT binding documentation for wm831x_power driver.
 - Change 'usb-phy' as one optional property for wm831x_power driver.
Changes since v1:
 - Fix building errors.

Baolin Wang (3):
  include: uapi: usb: Introduce USB charger type and state definition
  usb: phy: Add USB charger support
  power: wm831x_power: Support USB charger current limit management

 Documentation/devicetree/bindings/mfd/wm831x.txt |1 +
 drivers/power/supply/wm831x_power.c  |   72 ++
 drivers/usb/phy/phy.c|  272 ++
 include/linux/usb/phy.h  |   49 
 include/uapi/linux/usb/charger.h |   31 +++
 5 files changed, 425 insertions(+)
 create mode 100644 include/uapi/linux/usb/charger.h

-- 
1.7.9.5

Re: [PATCH v8 1/3] perf: cavium: Support memory controller PMU counters

[Borislav Petkov]

On Wed, Jul 26, 2017 at 02:02:42PM -0700, David Daney wrote:
> Also, if a given configuration disables CONFIG_EDAC there is some hackery
> needed to get the perf portion of the driver included.

Yes, and we don't do performance counters in EDAC.

So you could add a small memory controller driver which does the
arbitration or fix the firmware.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--

Re: [PATCH v8 1/3] perf: cavium: Support memory controller PMU counters

[Borislav Petkov]

On Wed, Jul 26, 2017 at 02:02:42PM -0700, David Daney wrote:
> Also, if a given configuration disables CONFIG_EDAC there is some hackery
> needed to get the perf portion of the driver included.

Yes, and we don't do performance counters in EDAC.

So you could add a small memory controller driver which does the
arbitration or fix the firmware.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--

Re: [RFT 2/2] ASoC: samsung: Add proper error paths to s3c24xx I2S driver

[Arvind Yadav]

Hi,


On Thursday 27 July 2017 12:27 AM, Krzysztof Kozlowski wrote:

s3c2412_i2s_probe() might fail so driver has to revert work done by
s3c_i2sv2_probe() (clock enabling).  Missing doing this would lead to
clock enable in-balance.

Signed-off-by: Krzysztof Kozlowski 

---

Please, kindly test on S3C24xx hardware.
---
  sound/soc/samsung/s3c-i2s-v2.c  |  9 +
  sound/soc/samsung/s3c-i2s-v2.h  |  7 +++
  sound/soc/samsung/s3c2412-i2s.c | 11 +--
  3 files changed, 25 insertions(+), 2 deletions(-)

diff --git a/sound/soc/samsung/s3c-i2s-v2.c b/sound/soc/samsung/s3c-i2s-v2.c
index 9b28046eea8e..df83f2730a53 100644
--- a/sound/soc/samsung/s3c-i2s-v2.c
+++ b/sound/soc/samsung/s3c-i2s-v2.c
@@ -651,6 +651,15 @@ int s3c_i2sv2_probe(struct snd_soc_dai *dai,
  }
  EXPORT_SYMBOL_GPL(s3c_i2sv2_probe);
  
+void s3c_i2sv2_cleanup(struct snd_soc_dai *dai,

+ struct s3c_i2sv2_info *i2s)
+{
+   clk_disable(i2s->iis_pclk);
+   clk_put(i2s->iis_pclk);
+   i2s->iis_pclk = NULL;
+}
+EXPORT_SYMBOL_GPL(s3c_i2sv2_cleanup);
+
  #ifdef CONFIG_PM
  static int s3c2412_i2s_suspend(struct snd_soc_dai *dai)
  {
diff --git a/sound/soc/samsung/s3c-i2s-v2.h b/sound/soc/samsung/s3c-i2s-v2.h
index 182d80564e37..3fca20f7a853 100644
--- a/sound/soc/samsung/s3c-i2s-v2.h
+++ b/sound/soc/samsung/s3c-i2s-v2.h
@@ -92,6 +92,13 @@ extern int s3c_i2sv2_probe(struct snd_soc_dai *dai,
   unsigned long base);
  
  /**

+ * s3c_i2sv2_cleanup - cleanup resources allocated in s3c_i2sv2_probe
+ * @dai: The ASoC DAI structure supplied to the original probe.
+ * @i2s: Our local i2s structure to fill in.
+ */
+extern void s3c_i2sv2_cleanup(struct snd_soc_dai *dai,
+ struct s3c_i2sv2_info *i2s);
+/**
   * s3c_i2sv2_register_component - register component and dai with soc core
   * @dev: DAI device
   * @id: DAI ID
diff --git a/sound/soc/samsung/s3c2412-i2s.c b/sound/soc/samsung/s3c2412-i2s.c
index bcd1cbdeac93..005cd6db7d07 100644
--- a/sound/soc/samsung/s3c2412-i2s.c
+++ b/sound/soc/samsung/s3c2412-i2s.c
@@ -65,7 +65,8 @@ static int s3c2412_i2s_probe(struct snd_soc_dai *dai)
s3c2412_i2s.iis_cclk = devm_clk_get(dai->dev, "i2sclk");
if (IS_ERR(s3c2412_i2s.iis_cclk)) {
pr_err("failed to get i2sclk clock\n");
-   return PTR_ERR(s3c2412_i2s.iis_cclk);
+   ret = PTR_ERR(s3c2412_i2s.iis_cclk);
+   goto err;
}
  
  	/* Set MPLL as the source for IIS CLK */

@@ -73,7 +74,7 @@ static int s3c2412_i2s_probe(struct snd_soc_dai *dai)
clk_set_parent(s3c2412_i2s.iis_cclk, clk_get(NULL, "mpll"));

we can use devm_clk_get for "mpll" clock.

ret = clk_prepare_enable(s3c2412_i2s.iis_cclk);
if (ret)
-   return ret;
+   goto err;
  
  	s3c2412_i2s.iis_cclk = s3c2412_i2s.iis_pclk;

Now s3c2412_i2s.iis_cclk and s3c2412_i2s.iis_pclk are holding "iis" clock.
Now no one handling "mpll" clock. If we will call s3c2412_i2s_remove.
It's means. we are disabling "iis" clock twice. Which is not correct.
  
@@ -82,11 +83,17 @@ static int s3c2412_i2s_probe(struct snd_soc_dai *dai)

  S3C_GPIO_PULL_NONE);
  
  	return 0;

+
+err:
+   s3c_i2sv2_cleanup(dai, _i2s);
+
+   return ret;
  }
  
  static int s3c2412_i2s_remove(struct snd_soc_dai *dai)

  {
clk_disable_unprepare(s3c2412_i2s.iis_cclk);
+   s3c_i2sv2_cleanup(dai, _i2s);

here, We are disabling "iis" clock twice. please check my previous comment.
  
  	return 0;

  }

~arvind

Re: [RFT 2/2] ASoC: samsung: Add proper error paths to s3c24xx I2S driver

[Arvind Yadav]

Hi,


On Thursday 27 July 2017 12:27 AM, Krzysztof Kozlowski wrote:

s3c2412_i2s_probe() might fail so driver has to revert work done by
s3c_i2sv2_probe() (clock enabling).  Missing doing this would lead to
clock enable in-balance.

Signed-off-by: Krzysztof Kozlowski 

---

Please, kindly test on S3C24xx hardware.
---
  sound/soc/samsung/s3c-i2s-v2.c  |  9 +
  sound/soc/samsung/s3c-i2s-v2.h  |  7 +++
  sound/soc/samsung/s3c2412-i2s.c | 11 +--
  3 files changed, 25 insertions(+), 2 deletions(-)

diff --git a/sound/soc/samsung/s3c-i2s-v2.c b/sound/soc/samsung/s3c-i2s-v2.c
index 9b28046eea8e..df83f2730a53 100644
--- a/sound/soc/samsung/s3c-i2s-v2.c
+++ b/sound/soc/samsung/s3c-i2s-v2.c
@@ -651,6 +651,15 @@ int s3c_i2sv2_probe(struct snd_soc_dai *dai,
  }
  EXPORT_SYMBOL_GPL(s3c_i2sv2_probe);
  
+void s3c_i2sv2_cleanup(struct snd_soc_dai *dai,

+ struct s3c_i2sv2_info *i2s)
+{
+   clk_disable(i2s->iis_pclk);
+   clk_put(i2s->iis_pclk);
+   i2s->iis_pclk = NULL;
+}
+EXPORT_SYMBOL_GPL(s3c_i2sv2_cleanup);
+
  #ifdef CONFIG_PM
  static int s3c2412_i2s_suspend(struct snd_soc_dai *dai)
  {
diff --git a/sound/soc/samsung/s3c-i2s-v2.h b/sound/soc/samsung/s3c-i2s-v2.h
index 182d80564e37..3fca20f7a853 100644
--- a/sound/soc/samsung/s3c-i2s-v2.h
+++ b/sound/soc/samsung/s3c-i2s-v2.h
@@ -92,6 +92,13 @@ extern int s3c_i2sv2_probe(struct snd_soc_dai *dai,
   unsigned long base);
  
  /**

+ * s3c_i2sv2_cleanup - cleanup resources allocated in s3c_i2sv2_probe
+ * @dai: The ASoC DAI structure supplied to the original probe.
+ * @i2s: Our local i2s structure to fill in.
+ */
+extern void s3c_i2sv2_cleanup(struct snd_soc_dai *dai,
+ struct s3c_i2sv2_info *i2s);
+/**
   * s3c_i2sv2_register_component - register component and dai with soc core
   * @dev: DAI device
   * @id: DAI ID
diff --git a/sound/soc/samsung/s3c2412-i2s.c b/sound/soc/samsung/s3c2412-i2s.c
index bcd1cbdeac93..005cd6db7d07 100644
--- a/sound/soc/samsung/s3c2412-i2s.c
+++ b/sound/soc/samsung/s3c2412-i2s.c
@@ -65,7 +65,8 @@ static int s3c2412_i2s_probe(struct snd_soc_dai *dai)
s3c2412_i2s.iis_cclk = devm_clk_get(dai->dev, "i2sclk");
if (IS_ERR(s3c2412_i2s.iis_cclk)) {
pr_err("failed to get i2sclk clock\n");
-   return PTR_ERR(s3c2412_i2s.iis_cclk);
+   ret = PTR_ERR(s3c2412_i2s.iis_cclk);
+   goto err;
}
  
  	/* Set MPLL as the source for IIS CLK */

@@ -73,7 +74,7 @@ static int s3c2412_i2s_probe(struct snd_soc_dai *dai)
clk_set_parent(s3c2412_i2s.iis_cclk, clk_get(NULL, "mpll"));

we can use devm_clk_get for "mpll" clock.

ret = clk_prepare_enable(s3c2412_i2s.iis_cclk);
if (ret)
-   return ret;
+   goto err;
  
  	s3c2412_i2s.iis_cclk = s3c2412_i2s.iis_pclk;

Now s3c2412_i2s.iis_cclk and s3c2412_i2s.iis_pclk are holding "iis" clock.
Now no one handling "mpll" clock. If we will call s3c2412_i2s_remove.
It's means. we are disabling "iis" clock twice. Which is not correct.
  
@@ -82,11 +83,17 @@ static int s3c2412_i2s_probe(struct snd_soc_dai *dai)

  S3C_GPIO_PULL_NONE);
  
  	return 0;

+
+err:
+   s3c_i2sv2_cleanup(dai, _i2s);
+
+   return ret;
  }
  
  static int s3c2412_i2s_remove(struct snd_soc_dai *dai)

  {
clk_disable_unprepare(s3c2412_i2s.iis_cclk);
+   s3c_i2sv2_cleanup(dai, _i2s);

here, We are disabling "iis" clock twice. please check my previous comment.
  
  	return 0;

  }

~arvind

Warning: You tried to send an email with blocked content

[Service Desk]

The UCL E-Mail Virus Protection System has been triggered by a message you sent.

One or more of the original e-mail attachments have been removed and replaced 
with this message.

* The attachment may have contained a virus or malware
* The attachment may have an extension of a type unacceptable for UCL

Consider renaming the file extension (eg rename file.ext to file.ex_)
to avoid this constraint.  The recipient will be required to rename the
file back to its original extension.

--
UCL E-mail Virus Protection System
serviced...@ucl.ac.uk
Phone: +44 (0)20 767925000 
Internal phone: 25000

--- Additional Information ---:

Subject: 
Sender: linux-kernel@vger.kernel.org

Time received: 7/27/2017 5:11:19 AM
Message ID:<150113226780.2160.16068305012815993...@safaricombusiness.co.ke>
Detections found: 
EMAIL_983639_j.iliffe.zipJS/Nemucod

Warning: You tried to send an email with blocked content

[Service Desk]

The UCL E-Mail Virus Protection System has been triggered by a message you sent.

One or more of the original e-mail attachments have been removed and replaced 
with this message.

* The attachment may have contained a virus or malware
* The attachment may have an extension of a type unacceptable for UCL

Consider renaming the file extension (eg rename file.ext to file.ex_)
to avoid this constraint.  The recipient will be required to rename the
file back to its original extension.

--
UCL E-mail Virus Protection System
serviced...@ucl.ac.uk
Phone: +44 (0)20 767925000 
Internal phone: 25000

--- Additional Information ---:

Subject: 
Sender: linux-kernel@vger.kernel.org

Time received: 7/27/2017 5:11:19 AM
Message ID:<150113226780.2160.16068305012815993...@safaricombusiness.co.ke>
Detections found: 
EMAIL_983639_j.iliffe.zipJS/Nemucod

blk_mq_sched_insert_request: inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage

[Michael Ellerman]

Hi Jens,

I'm seeing the lockdep warning below on shutdown on a Power8 machine
using IPR.

If I'm reading it right it looks like the spin_lock() (non-irq) in
blk_mq_sched_insert_request() is the immediate cause.

Looking at blk_mq_requeue_work() (the caller), it is doing
spin_lock_irqsave(). So is switching blk_mq_sched_insert_request() to
spin_lock_irqsave() the right fix?

cheers


ipr 0001:08:00.0: shutdown


WARNING: inconsistent lock state
4.13.0-rc2-gcc6x-gf74c89b #1 Not tainted

inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
swapper/28/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
 (&(>lock)->rlock){+.?...}, at: [] 
blk_mq_sched_dispatch_requests+0xa4/0x2a0
{SOFTIRQ-ON-W} state was registered at:
  lock_acquire+0xec/0x2e0
  _raw_spin_lock+0x44/0x70
  blk_mq_sched_insert_request+0x88/0x1f0
  blk_mq_requeue_work+0x108/0x180
  process_one_work+0x310/0x800
  worker_thread+0x88/0x520
  kthread+0x164/0x1b0
  ret_from_kernel_thread+0x5c/0x74
irq event stamp: 3572314
hardirqs last  enabled at (3572314): [] 
_raw_spin_unlock_irqrestore+0x58/0xb0
hardirqs last disabled at (3572313): [] 
_raw_spin_lock_irqsave+0x3c/0x90
softirqs last  enabled at (3572302): [] irq_enter+0x9c/0xe0
softirqs last disabled at (3572303): [] irq_exit+0x108/0x150

other info that might help us debug this:
 Possible unsafe locking scenario:

   CPU0
   
  lock(&(>lock)->rlock);
  
lock(&(>lock)->rlock);

 *** DEADLOCK ***

2 locks held by swapper/28/0:
 #0:  ((_cmd->timer)){+.-...}, at: [] 
call_timer_fn+0x10/0x4b0
 #1:  (rcu_read_lock){..}, at: [] 
__blk_mq_run_hw_queue+0xa0/0x2c0

stack backtrace:
CPU: 28 PID: 0 Comm: swapper/28 Not tainted 4.13.0-rc2-gcc6x-gf74c89b #1
Call Trace:
[c01fffe97550] [c0b50818] dump_stack+0xe8/0x160 (unreliable)
[c01fffe97590] [c01586d0] print_usage_bug+0x2d0/0x390
[c01fffe97640] [c0158f34] mark_lock+0x7a4/0x8e0
[c01fffe976f0] [c015a000] __lock_acquire+0x6a0/0x1a70
[c01fffe97860] [c015befc] lock_acquire+0xec/0x2e0
[c01fffe97930] [c0b71514] _raw_spin_lock+0x44/0x70
[c01fffe97960] [c05b60f4] blk_mq_sched_dispatch_requests+0xa4/0x2a0
[c01fffe979c0] [c05acac0] __blk_mq_run_hw_queue+0x100/0x2c0
[c01fffe97a00] [c05ad478] __blk_mq_delay_run_hw_queue+0x118/0x130
[c01fffe97a40] [c05ad61c] blk_mq_start_hw_queues+0x6c/0xa0
[c01fffe97a80] [c0797aac] scsi_kick_queue+0x2c/0x60
[c01fffe97aa0] [c0797cf0] scsi_run_queue+0x210/0x360
[c01fffe97b10] [c079b888] scsi_run_host_queues+0x48/0x80
[c01fffe97b40] [c07b6090] ipr_ioa_bringdown_done+0x70/0x1e0
[c01fffe97bc0] [c07bc860] ipr_reset_ioa_job+0x80/0xf0
[c01fffe97bf0] [c07b4d50] ipr_reset_timer_done+0xd0/0x100
[c01fffe97c30] [c01937bc] call_timer_fn+0xdc/0x4b0
[c01fffe97cf0] [c0193d08] expire_timers+0x178/0x330
[c01fffe97d60] [c01940c8] run_timer_softirq+0xb8/0x120
[c01fffe97de0] [c0b726a8] __do_softirq+0x168/0x6d8
[c01fffe97ef0] [c00df2c8] irq_exit+0x108/0x150
[c01fffe97f10] [c0017bf4] __do_irq+0x2a4/0x4a0
[c01fffe97f90] [c002da50] call_do_irq+0x14/0x24
[c007fad93aa0] [c0017e8c] do_IRQ+0x9c/0x140
[c007fad93af0] [c0008b98] hardware_interrupt_common+0x138/0x140
--- interrupt: 501 at .L1.42+0x0/0x4
LR = arch_local_irq_restore.part.4+0x84/0xb0
[c007fad93de0] [c007ffc1f7d8] 0xc007ffc1f7d8 (unreliable)
[c007fad93e00] [c0988d3c] cpuidle_enter_state+0x1bc/0x530
[c007fad93e60] [c01457cc] call_cpuidle+0x4c/0x90
[c007fad93e80] [c0145b28] do_idle+0x208/0x2f0
[c007fad93ef0] [c0145f8c] cpu_startup_entry+0x3c/0x50
[c007fad93f20] [c0042bc0] start_secondary+0x3b0/0x4b0
[c007fad93f90] [c000ac6c] start_secondary_prolog+0x10/0x14

blk_mq_sched_insert_request: inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage

[Michael Ellerman]

Hi Jens,

I'm seeing the lockdep warning below on shutdown on a Power8 machine
using IPR.

If I'm reading it right it looks like the spin_lock() (non-irq) in
blk_mq_sched_insert_request() is the immediate cause.

Looking at blk_mq_requeue_work() (the caller), it is doing
spin_lock_irqsave(). So is switching blk_mq_sched_insert_request() to
spin_lock_irqsave() the right fix?

cheers


ipr 0001:08:00.0: shutdown


WARNING: inconsistent lock state
4.13.0-rc2-gcc6x-gf74c89b #1 Not tainted

inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
swapper/28/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
 (&(>lock)->rlock){+.?...}, at: [] 
blk_mq_sched_dispatch_requests+0xa4/0x2a0
{SOFTIRQ-ON-W} state was registered at:
  lock_acquire+0xec/0x2e0
  _raw_spin_lock+0x44/0x70
  blk_mq_sched_insert_request+0x88/0x1f0
  blk_mq_requeue_work+0x108/0x180
  process_one_work+0x310/0x800
  worker_thread+0x88/0x520
  kthread+0x164/0x1b0
  ret_from_kernel_thread+0x5c/0x74
irq event stamp: 3572314
hardirqs last  enabled at (3572314): [] 
_raw_spin_unlock_irqrestore+0x58/0xb0
hardirqs last disabled at (3572313): [] 
_raw_spin_lock_irqsave+0x3c/0x90
softirqs last  enabled at (3572302): [] irq_enter+0x9c/0xe0
softirqs last disabled at (3572303): [] irq_exit+0x108/0x150

other info that might help us debug this:
 Possible unsafe locking scenario:

   CPU0
   
  lock(&(>lock)->rlock);
  
lock(&(>lock)->rlock);

 *** DEADLOCK ***

2 locks held by swapper/28/0:
 #0:  ((_cmd->timer)){+.-...}, at: [] 
call_timer_fn+0x10/0x4b0
 #1:  (rcu_read_lock){..}, at: [] 
__blk_mq_run_hw_queue+0xa0/0x2c0

stack backtrace:
CPU: 28 PID: 0 Comm: swapper/28 Not tainted 4.13.0-rc2-gcc6x-gf74c89b #1
Call Trace:
[c01fffe97550] [c0b50818] dump_stack+0xe8/0x160 (unreliable)
[c01fffe97590] [c01586d0] print_usage_bug+0x2d0/0x390
[c01fffe97640] [c0158f34] mark_lock+0x7a4/0x8e0
[c01fffe976f0] [c015a000] __lock_acquire+0x6a0/0x1a70
[c01fffe97860] [c015befc] lock_acquire+0xec/0x2e0
[c01fffe97930] [c0b71514] _raw_spin_lock+0x44/0x70
[c01fffe97960] [c05b60f4] blk_mq_sched_dispatch_requests+0xa4/0x2a0
[c01fffe979c0] [c05acac0] __blk_mq_run_hw_queue+0x100/0x2c0
[c01fffe97a00] [c05ad478] __blk_mq_delay_run_hw_queue+0x118/0x130
[c01fffe97a40] [c05ad61c] blk_mq_start_hw_queues+0x6c/0xa0
[c01fffe97a80] [c0797aac] scsi_kick_queue+0x2c/0x60
[c01fffe97aa0] [c0797cf0] scsi_run_queue+0x210/0x360
[c01fffe97b10] [c079b888] scsi_run_host_queues+0x48/0x80
[c01fffe97b40] [c07b6090] ipr_ioa_bringdown_done+0x70/0x1e0
[c01fffe97bc0] [c07bc860] ipr_reset_ioa_job+0x80/0xf0
[c01fffe97bf0] [c07b4d50] ipr_reset_timer_done+0xd0/0x100
[c01fffe97c30] [c01937bc] call_timer_fn+0xdc/0x4b0
[c01fffe97cf0] [c0193d08] expire_timers+0x178/0x330
[c01fffe97d60] [c01940c8] run_timer_softirq+0xb8/0x120
[c01fffe97de0] [c0b726a8] __do_softirq+0x168/0x6d8
[c01fffe97ef0] [c00df2c8] irq_exit+0x108/0x150
[c01fffe97f10] [c0017bf4] __do_irq+0x2a4/0x4a0
[c01fffe97f90] [c002da50] call_do_irq+0x14/0x24
[c007fad93aa0] [c0017e8c] do_IRQ+0x9c/0x140
[c007fad93af0] [c0008b98] hardware_interrupt_common+0x138/0x140
--- interrupt: 501 at .L1.42+0x0/0x4
LR = arch_local_irq_restore.part.4+0x84/0xb0
[c007fad93de0] [c007ffc1f7d8] 0xc007ffc1f7d8 (unreliable)
[c007fad93e00] [c0988d3c] cpuidle_enter_state+0x1bc/0x530
[c007fad93e60] [c01457cc] call_cpuidle+0x4c/0x90
[c007fad93e80] [c0145b28] do_idle+0x208/0x2f0
[c007fad93ef0] [c0145f8c] cpu_startup_entry+0x3c/0x50
[c007fad93f20] [c0042bc0] start_secondary+0x3b0/0x4b0
[c007fad93f90] [c000ac6c] start_secondary_prolog+0x10/0x14

Re: [greybus-dev] [PATCH] staging: greybus: Remove unnecessary platform_set_drvdata

[Viresh Kumar]

On 26-07-17, 23:19, Amitoj Kaur Chawla wrote:
> Unnecessary platform_set_drvdata() has been removed since the driver
> core clears the driver data to NULL after device release or on
> probe failure. There is no need to manually clear the device
> driver data to NULL.
> 
> The Coccinelle semantic patch used to make this change is as follows:
> //
> @@
> struct platform_device *pdev;
> @@
> - platform_set_drvdata(pdev, NULL);
> //
> 
> Signed-off-by: Amitoj Kaur Chawla 
> ---
>  drivers/staging/greybus/arche-platform.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/staging/greybus/arche-platform.c 
> b/drivers/staging/greybus/arche-platform.c
> index eced2d2..358b260 100644
> --- a/drivers/staging/greybus/arche-platform.c
> +++ b/drivers/staging/greybus/arche-platform.c
> @@ -607,7 +607,6 @@ static int arche_platform_remove(struct platform_device 
> *pdev)
>   device_remove_file(>dev, _attr_state);
>   device_for_each_child(>dev, NULL, arche_remove_child);
>   arche_platform_poweroff_seq(arche_pdata);
> - platform_set_drvdata(pdev, NULL);
>  
>   if (usb3613_hub_mode_ctrl(false))
>   dev_warn(arche_pdata->dev, "failed to control hub device\n");

Acked-by: Viresh Kumar 

-- 
viresh

Re: [greybus-dev] [PATCH] staging: greybus: Remove unnecessary platform_set_drvdata

[Viresh Kumar]

On 26-07-17, 23:19, Amitoj Kaur Chawla wrote:
> Unnecessary platform_set_drvdata() has been removed since the driver
> core clears the driver data to NULL after device release or on
> probe failure. There is no need to manually clear the device
> driver data to NULL.
> 
> The Coccinelle semantic patch used to make this change is as follows:
> //
> @@
> struct platform_device *pdev;
> @@
> - platform_set_drvdata(pdev, NULL);
> //
> 
> Signed-off-by: Amitoj Kaur Chawla 
> ---
>  drivers/staging/greybus/arche-platform.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/staging/greybus/arche-platform.c 
> b/drivers/staging/greybus/arche-platform.c
> index eced2d2..358b260 100644
> --- a/drivers/staging/greybus/arche-platform.c
> +++ b/drivers/staging/greybus/arche-platform.c
> @@ -607,7 +607,6 @@ static int arche_platform_remove(struct platform_device 
> *pdev)
>   device_remove_file(>dev, _attr_state);
>   device_for_each_child(>dev, NULL, arche_remove_child);
>   arche_platform_poweroff_seq(arche_pdata);
> - platform_set_drvdata(pdev, NULL);
>  
>   if (usb3613_hub_mode_ctrl(false))
>   dev_warn(arche_pdata->dev, "failed to control hub device\n");

Acked-by: Viresh Kumar 

-- 
viresh

Re: [PATCH 08/12] ima: added parser for RPM data type

[kbuild test robot]

Hi Roberto,

[auto build test WARNING on integrity/next]
[also build test WARNING on v4.13-rc2 next-20170726]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Roberto-Sassu/ima-measure-digest-lists-instead-of-individual-files/20170727-123131
base:   
https://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity.git next
config: xtensa-allyesconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 4.9.0
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=xtensa 

All warnings (new ones prefixed by >>):

   security/integrity/ima/ima_digest_list.c: In function 'ima_parse_rpm':
>> security/integrity/ima/ima_digest_list.c:147:4: warning: ignoring return 
>> value of 'hex2bin', declared with attribute warn_unused_result 
>> [-Wunused-result]
   hex2bin(digest, datap, digest_len);
   ^

vim +/hex2bin +147 security/integrity/ima/ima_digest_list.c

98  
99  static int ima_parse_rpm(loff_t size, void *buf)
   100  {
   101  void *bufp = buf, *bufendp = buf + size;
   102  struct rpm_hdr *hdr = bufp;
   103  u32 tags = be32_to_cpu(hdr->tags);
   104  struct rpm_entryinfo *entry;
   105  void *datap = bufp + sizeof(*hdr) + tags * sizeof(struct 
rpm_entryinfo);
   106  int digest_len = hash_digest_size[ima_hash_algo];
   107  u8 digest[digest_len];
   108  int ret, i, j;
   109  
   110  const unsigned char rpm_header_magic[8] = {
   111  0x8e, 0xad, 0xe8, 0x01, 0x00, 0x00, 0x00, 0x00
   112  };
   113  
   114  if (size < sizeof(*hdr)) {
   115  pr_err("Missing RPM header\n");
   116  return -EINVAL;
   117  }
   118  
   119  if (memcmp(bufp, rpm_header_magic, sizeof(rpm_header_magic))) {
   120  pr_err("Invalid RPM header\n");
   121  return -EINVAL;
   122  }
   123  
   124  bufp += sizeof(*hdr);
   125  
   126  for (i = 0; i < tags && (bufp + sizeof(*entry)) <= bufendp;
   127   i++, bufp += sizeof(*entry)) {
   128  entry = bufp;
   129  
   130  if (be32_to_cpu(entry->tag) != RPMTAG_FILEDIGESTS)
   131  continue;
   132  
   133  datap += be32_to_cpu(entry->offset);
   134  
   135  for (j = 0; j < be32_to_cpu(entry->count) &&
   136   datap < bufendp; j++) {
   137  if (strlen(datap) == 0) {
   138  datap++;
   139  continue;
   140  }
   141  
   142  if (datap + digest_len * 2 + 1 > bufendp) {
   143  pr_err("RPM header read at invalid 
offset\n");
   144  return -EINVAL;
   145  }
   146  
 > 147  hex2bin(digest, datap, digest_len);
   148  
   149  ret = ima_add_digest_data_entry(digest);
   150  if (ret < 0 && ret != -EEXIST)
   151  return ret;
   152  
   153  datap += digest_len * 2 + 1;
   154  }
   155  
   156  break;
   157  }
   158  
   159  return 0;
   160  }
   161  

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


.config.gz
Description: application/gzip

Re: [PATCH 08/12] ima: added parser for RPM data type

[kbuild test robot]

Hi Roberto,

[auto build test WARNING on integrity/next]
[also build test WARNING on v4.13-rc2 next-20170726]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Roberto-Sassu/ima-measure-digest-lists-instead-of-individual-files/20170727-123131
base:   
https://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity.git next
config: xtensa-allyesconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 4.9.0
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=xtensa 

All warnings (new ones prefixed by >>):

   security/integrity/ima/ima_digest_list.c: In function 'ima_parse_rpm':
>> security/integrity/ima/ima_digest_list.c:147:4: warning: ignoring return 
>> value of 'hex2bin', declared with attribute warn_unused_result 
>> [-Wunused-result]
   hex2bin(digest, datap, digest_len);
   ^

vim +/hex2bin +147 security/integrity/ima/ima_digest_list.c

98  
99  static int ima_parse_rpm(loff_t size, void *buf)
   100  {
   101  void *bufp = buf, *bufendp = buf + size;
   102  struct rpm_hdr *hdr = bufp;
   103  u32 tags = be32_to_cpu(hdr->tags);
   104  struct rpm_entryinfo *entry;
   105  void *datap = bufp + sizeof(*hdr) + tags * sizeof(struct 
rpm_entryinfo);
   106  int digest_len = hash_digest_size[ima_hash_algo];
   107  u8 digest[digest_len];
   108  int ret, i, j;
   109  
   110  const unsigned char rpm_header_magic[8] = {
   111  0x8e, 0xad, 0xe8, 0x01, 0x00, 0x00, 0x00, 0x00
   112  };
   113  
   114  if (size < sizeof(*hdr)) {
   115  pr_err("Missing RPM header\n");
   116  return -EINVAL;
   117  }
   118  
   119  if (memcmp(bufp, rpm_header_magic, sizeof(rpm_header_magic))) {
   120  pr_err("Invalid RPM header\n");
   121  return -EINVAL;
   122  }
   123  
   124  bufp += sizeof(*hdr);
   125  
   126  for (i = 0; i < tags && (bufp + sizeof(*entry)) <= bufendp;
   127   i++, bufp += sizeof(*entry)) {
   128  entry = bufp;
   129  
   130  if (be32_to_cpu(entry->tag) != RPMTAG_FILEDIGESTS)
   131  continue;
   132  
   133  datap += be32_to_cpu(entry->offset);
   134  
   135  for (j = 0; j < be32_to_cpu(entry->count) &&
   136   datap < bufendp; j++) {
   137  if (strlen(datap) == 0) {
   138  datap++;
   139  continue;
   140  }
   141  
   142  if (datap + digest_len * 2 + 1 > bufendp) {
   143  pr_err("RPM header read at invalid 
offset\n");
   144  return -EINVAL;
   145  }
   146  
 > 147  hex2bin(digest, datap, digest_len);
   148  
   149  ret = ima_add_digest_data_entry(digest);
   150  if (ret < 0 && ret != -EEXIST)
   151  return ret;
   152  
   153  datap += digest_len * 2 + 1;
   154  }
   155  
   156  break;
   157  }
   158  
   159  return 0;
   160  }
   161  

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


.config.gz
Description: application/gzip

[PATCH v2 2/3] dt-bindings: media: Add Allwinner V3s Camera Sensor Interface (CSI)

[Yong Deng]

Add binding documentation for Allwinner V3s CSI.

Signed-off-by: Yong Deng 
---
 .../devicetree/bindings/media/sun6i-csi.txt| 49 ++
 1 file changed, 49 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/sun6i-csi.txt

diff --git a/Documentation/devicetree/bindings/media/sun6i-csi.txt 
b/Documentation/devicetree/bindings/media/sun6i-csi.txt
new file mode 100644
index 000..f8d83f6
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/sun6i-csi.txt
@@ -0,0 +1,49 @@
+Allwinner V3s Camera Sensor Interface
+--
+
+Required properties:
+  - compatible: value must be "allwinner,sun8i-v3s-csi"
+  - reg: base address and size of the memory-mapped region.
+  - interrupts: interrupt associated to this IP
+  - clocks: phandles to the clocks feeding the CSI
+* ahb: the CSI interface clock
+* mod: the CSI module clock
+* ram: the CSI DRAM clock
+  - clock-names: the clock names mentioned above
+  - resets: phandles to the reset line driving the CSI
+
+- ports: A ports node with endpoint definitions as defined in
+  Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Example:
+
+   csi1: csi@01cb4000 {
+   compatible = "allwinner,sun8i-v3s-csi";
+   reg = <0x01cb4000 0x1000>;
+   interrupts = ;
+   clocks = < CLK_BUS_CSI>,
+< CLK_CSI1_SCLK>,
+< CLK_DRAM_CSI>;
+   clock-names = "ahb", "mod", "ram";
+   resets = < RST_BUS_CSI>;
+
+   port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   /* Parallel bus endpoint */
+   csi1_ep: endpoint {
+   remote-endpoint = <_ep>;
+   bus-width = <16>;
+   data-shift = <0>;
+
+   /* If hsync-active/vsync-active are missing,
+  embedded BT.656 sync is used */
+   hsync-active = <0>; /* Active low */
+   vsync-active = <0>; /* Active low */
+   data-active = <1>;  /* Active high */
+   pclk-sample = <1>;  /* Rising */
+   };
+   };
+   };
+
-- 
1.8.3.1

[PATCH v2 2/3] dt-bindings: media: Add Allwinner V3s Camera Sensor Interface (CSI)

[Yong Deng]

Add binding documentation for Allwinner V3s CSI.

Signed-off-by: Yong Deng 
---
 .../devicetree/bindings/media/sun6i-csi.txt| 49 ++
 1 file changed, 49 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/sun6i-csi.txt

diff --git a/Documentation/devicetree/bindings/media/sun6i-csi.txt 
b/Documentation/devicetree/bindings/media/sun6i-csi.txt
new file mode 100644
index 000..f8d83f6
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/sun6i-csi.txt
@@ -0,0 +1,49 @@
+Allwinner V3s Camera Sensor Interface
+--
+
+Required properties:
+  - compatible: value must be "allwinner,sun8i-v3s-csi"
+  - reg: base address and size of the memory-mapped region.
+  - interrupts: interrupt associated to this IP
+  - clocks: phandles to the clocks feeding the CSI
+* ahb: the CSI interface clock
+* mod: the CSI module clock
+* ram: the CSI DRAM clock
+  - clock-names: the clock names mentioned above
+  - resets: phandles to the reset line driving the CSI
+
+- ports: A ports node with endpoint definitions as defined in
+  Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Example:
+
+   csi1: csi@01cb4000 {
+   compatible = "allwinner,sun8i-v3s-csi";
+   reg = <0x01cb4000 0x1000>;
+   interrupts = ;
+   clocks = < CLK_BUS_CSI>,
+< CLK_CSI1_SCLK>,
+< CLK_DRAM_CSI>;
+   clock-names = "ahb", "mod", "ram";
+   resets = < RST_BUS_CSI>;
+
+   port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   /* Parallel bus endpoint */
+   csi1_ep: endpoint {
+   remote-endpoint = <_ep>;
+   bus-width = <16>;
+   data-shift = <0>;
+
+   /* If hsync-active/vsync-active are missing,
+  embedded BT.656 sync is used */
+   hsync-active = <0>; /* Active low */
+   vsync-active = <0>; /* Active low */
+   data-active = <1>;  /* Active high */
+   pclk-sample = <1>;  /* Rising */
+   };
+   };
+   };
+
-- 
1.8.3.1

[PATCH v2 1/3] media: V3s: Add support for Allwinner CSI.

[Yong Deng]

Allwinner V3s SoC have two CSI module. CSI0 is used for MIPI interface
and CSI1 is used for parallel interface. This is not documented in
datasheet but by testing and guess.

This patch implement a v4l2 framework driver for it.

Currently, the driver only support the parallel interface. MIPI-CSI2,
ISP's support are not included in this patch.

Signed-off-by: Yong Deng 
---
 drivers/media/platform/Kconfig   |   1 +
 drivers/media/platform/Makefile  |   2 +
 drivers/media/platform/sun6i-csi/Kconfig |   9 +
 drivers/media/platform/sun6i-csi/Makefile|   3 +
 drivers/media/platform/sun6i-csi/sun6i_csi.c | 545 +++
 drivers/media/platform/sun6i-csi/sun6i_csi.h | 203 ++
 drivers/media/platform/sun6i-csi/sun6i_csi_v3s.c | 827 +++
 drivers/media/platform/sun6i-csi/sun6i_csi_v3s.h | 206 ++
 drivers/media/platform/sun6i-csi/sun6i_video.c   | 663 ++
 drivers/media/platform/sun6i-csi/sun6i_video.h   |  61 ++
 10 files changed, 2520 insertions(+)
 create mode 100644 drivers/media/platform/sun6i-csi/Kconfig
 create mode 100644 drivers/media/platform/sun6i-csi/Makefile
 create mode 100644 drivers/media/platform/sun6i-csi/sun6i_csi.c
 create mode 100644 drivers/media/platform/sun6i-csi/sun6i_csi.h
 create mode 100644 drivers/media/platform/sun6i-csi/sun6i_csi_v3s.c
 create mode 100644 drivers/media/platform/sun6i-csi/sun6i_csi_v3s.h
 create mode 100644 drivers/media/platform/sun6i-csi/sun6i_video.c
 create mode 100644 drivers/media/platform/sun6i-csi/sun6i_video.h

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 0c741d1..8371a87 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -143,6 +143,7 @@ source "drivers/media/platform/am437x/Kconfig"
 source "drivers/media/platform/xilinx/Kconfig"
 source "drivers/media/platform/rcar-vin/Kconfig"
 source "drivers/media/platform/atmel/Kconfig"
+source "drivers/media/platform/sun6i-csi/Kconfig"
 
 config VIDEO_TI_CAL
tristate "TI CAL (Camera Adaptation Layer) driver"
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 9beadc7..fb2459c 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -86,3 +86,5 @@ obj-$(CONFIG_VIDEO_MEDIATEK_MDP)  += mtk-mdp/
 obj-$(CONFIG_VIDEO_MEDIATEK_JPEG)  += mtk-jpeg/
 
 obj-$(CONFIG_VIDEO_QCOM_VENUS) += qcom/venus/
+
+obj-$(CONFIG_VIDEO_SUN6I_CSI)  += sun6i-csi/
diff --git a/drivers/media/platform/sun6i-csi/Kconfig 
b/drivers/media/platform/sun6i-csi/Kconfig
new file mode 100644
index 000..314188a
--- /dev/null
+++ b/drivers/media/platform/sun6i-csi/Kconfig
@@ -0,0 +1,9 @@
+config VIDEO_SUN6I_CSI
+   tristate "Allwinner V3s Camera Sensor Interface driver"
+   depends on VIDEO_V4L2 && COMMON_CLK && VIDEO_V4L2_SUBDEV_API && HAS_DMA
+   depends on ARCH_SUNXI || COMPILE_TEST
+   select VIDEOBUF2_DMA_CONTIG
+   select REGMAP_MMIO
+   select V4L2_FWNODE
+   ---help---
+  Support for the Allwinner Camera Sensor Interface Controller on V3s.
diff --git a/drivers/media/platform/sun6i-csi/Makefile 
b/drivers/media/platform/sun6i-csi/Makefile
new file mode 100644
index 000..a9b527b
--- /dev/null
+++ b/drivers/media/platform/sun6i-csi/Makefile
@@ -0,0 +1,3 @@
+sun6i-csi-y += sun6i_csi.o sun6i_video.o sun6i_csi_v3s.o
+
+obj-$(CONFIG_VIDEO_SUN6I_CSI) += sun6i-csi.o
diff --git a/drivers/media/platform/sun6i-csi/sun6i_csi.c 
b/drivers/media/platform/sun6i-csi/sun6i_csi.c
new file mode 100644
index 000..7a4bf53
--- /dev/null
+++ b/drivers/media/platform/sun6i-csi/sun6i_csi.c
@@ -0,0 +1,545 @@
+/*
+ * Copyright (c) 2017 Magewell Electronics Co., Ltd. (Nanjing),
+ * All rights reserved.
+ * Author: Yong Deng 
+ *
+ * Based on drivers/media/platform/xilinx/xilinx-vipp.c
+ * Copyright (C) 2013-2015 Ideas on Board
+ * Copyright (C) 2013-2015 Xilinx, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "sun6i_csi.h"
+
+/*
+ * struct sun6i_graph_entity - Entity in the video graph
+ * @list: list entry in a graph entities list
+ * @node: the entity's DT node
+ * @entity: media entity, from the corresponding V4L2 subdev
+ * @asd: subdev asynchronous registration information
+ * @subdev: V4L2 subdev
+ */
+struct sun6i_graph_entity {
+   struct list_headlist;
+   struct device_node  *node;
+   struct media_entity  

[PATCH v2 1/3] media: V3s: Add support for Allwinner CSI.

[Yong Deng]

Allwinner V3s SoC have two CSI module. CSI0 is used for MIPI interface
and CSI1 is used for parallel interface. This is not documented in
datasheet but by testing and guess.

This patch implement a v4l2 framework driver for it.

Currently, the driver only support the parallel interface. MIPI-CSI2,
ISP's support are not included in this patch.

Signed-off-by: Yong Deng 
---
 drivers/media/platform/Kconfig   |   1 +
 drivers/media/platform/Makefile  |   2 +
 drivers/media/platform/sun6i-csi/Kconfig |   9 +
 drivers/media/platform/sun6i-csi/Makefile|   3 +
 drivers/media/platform/sun6i-csi/sun6i_csi.c | 545 +++
 drivers/media/platform/sun6i-csi/sun6i_csi.h | 203 ++
 drivers/media/platform/sun6i-csi/sun6i_csi_v3s.c | 827 +++
 drivers/media/platform/sun6i-csi/sun6i_csi_v3s.h | 206 ++
 drivers/media/platform/sun6i-csi/sun6i_video.c   | 663 ++
 drivers/media/platform/sun6i-csi/sun6i_video.h   |  61 ++
 10 files changed, 2520 insertions(+)
 create mode 100644 drivers/media/platform/sun6i-csi/Kconfig
 create mode 100644 drivers/media/platform/sun6i-csi/Makefile
 create mode 100644 drivers/media/platform/sun6i-csi/sun6i_csi.c
 create mode 100644 drivers/media/platform/sun6i-csi/sun6i_csi.h
 create mode 100644 drivers/media/platform/sun6i-csi/sun6i_csi_v3s.c
 create mode 100644 drivers/media/platform/sun6i-csi/sun6i_csi_v3s.h
 create mode 100644 drivers/media/platform/sun6i-csi/sun6i_video.c
 create mode 100644 drivers/media/platform/sun6i-csi/sun6i_video.h

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 0c741d1..8371a87 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -143,6 +143,7 @@ source "drivers/media/platform/am437x/Kconfig"
 source "drivers/media/platform/xilinx/Kconfig"
 source "drivers/media/platform/rcar-vin/Kconfig"
 source "drivers/media/platform/atmel/Kconfig"
+source "drivers/media/platform/sun6i-csi/Kconfig"
 
 config VIDEO_TI_CAL
tristate "TI CAL (Camera Adaptation Layer) driver"
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 9beadc7..fb2459c 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -86,3 +86,5 @@ obj-$(CONFIG_VIDEO_MEDIATEK_MDP)  += mtk-mdp/
 obj-$(CONFIG_VIDEO_MEDIATEK_JPEG)  += mtk-jpeg/
 
 obj-$(CONFIG_VIDEO_QCOM_VENUS) += qcom/venus/
+
+obj-$(CONFIG_VIDEO_SUN6I_CSI)  += sun6i-csi/
diff --git a/drivers/media/platform/sun6i-csi/Kconfig 
b/drivers/media/platform/sun6i-csi/Kconfig
new file mode 100644
index 000..314188a
--- /dev/null
+++ b/drivers/media/platform/sun6i-csi/Kconfig
@@ -0,0 +1,9 @@
+config VIDEO_SUN6I_CSI
+   tristate "Allwinner V3s Camera Sensor Interface driver"
+   depends on VIDEO_V4L2 && COMMON_CLK && VIDEO_V4L2_SUBDEV_API && HAS_DMA
+   depends on ARCH_SUNXI || COMPILE_TEST
+   select VIDEOBUF2_DMA_CONTIG
+   select REGMAP_MMIO
+   select V4L2_FWNODE
+   ---help---
+  Support for the Allwinner Camera Sensor Interface Controller on V3s.
diff --git a/drivers/media/platform/sun6i-csi/Makefile 
b/drivers/media/platform/sun6i-csi/Makefile
new file mode 100644
index 000..a9b527b
--- /dev/null
+++ b/drivers/media/platform/sun6i-csi/Makefile
@@ -0,0 +1,3 @@
+sun6i-csi-y += sun6i_csi.o sun6i_video.o sun6i_csi_v3s.o
+
+obj-$(CONFIG_VIDEO_SUN6I_CSI) += sun6i-csi.o
diff --git a/drivers/media/platform/sun6i-csi/sun6i_csi.c 
b/drivers/media/platform/sun6i-csi/sun6i_csi.c
new file mode 100644
index 000..7a4bf53
--- /dev/null
+++ b/drivers/media/platform/sun6i-csi/sun6i_csi.c
@@ -0,0 +1,545 @@
+/*
+ * Copyright (c) 2017 Magewell Electronics Co., Ltd. (Nanjing),
+ * All rights reserved.
+ * Author: Yong Deng 
+ *
+ * Based on drivers/media/platform/xilinx/xilinx-vipp.c
+ * Copyright (C) 2013-2015 Ideas on Board
+ * Copyright (C) 2013-2015 Xilinx, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "sun6i_csi.h"
+
+/*
+ * struct sun6i_graph_entity - Entity in the video graph
+ * @list: list entry in a graph entities list
+ * @node: the entity's DT node
+ * @entity: media entity, from the corresponding V4L2 subdev
+ * @asd: subdev asynchronous registration information
+ * @subdev: V4L2 subdev
+ */
+struct sun6i_graph_entity {
+   struct list_headlist;
+   struct device_node  *node;
+   struct media_entity *entity;
+
+   struct 

[PATCH v2 3/3] media: MAINTAINERS: add entries for Allwinner V3s CSI

[Yong Deng]

Signed-off-by: Yong Deng 
---
 MAINTAINERS | 8 
 1 file changed, 8 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 9826a91..b91fa27 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3686,6 +3686,14 @@ M:   Jaya Kumar 
 S: Maintained
 F: sound/pci/cs5535audio/
 
+CSI DRIVERS FOR ALLWINNER V3s
+M: Yong Deng 
+L: linux-me...@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+S: Maintained
+F: drivers/media/platform/sun6i-csi/
+F: Documentation/devicetree/bindings/media/sun6i-csi.txt
+
 CW1200 WLAN driver
 M: Solomon Peachy 
 S: Maintained
-- 
1.8.3.1

[PATCH v2 3/3] media: MAINTAINERS: add entries for Allwinner V3s CSI

[Yong Deng]

Signed-off-by: Yong Deng 
---
 MAINTAINERS | 8 
 1 file changed, 8 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 9826a91..b91fa27 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3686,6 +3686,14 @@ M:   Jaya Kumar 
 S: Maintained
 F: sound/pci/cs5535audio/
 
+CSI DRIVERS FOR ALLWINNER V3s
+M: Yong Deng 
+L: linux-me...@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+S: Maintained
+F: drivers/media/platform/sun6i-csi/
+F: Documentation/devicetree/bindings/media/sun6i-csi.txt
+
 CW1200 WLAN driver
 M: Solomon Peachy 
 S: Maintained
-- 
1.8.3.1

Re: [PATCH] ASoC: samsung: s3c2412: cleanups / fixes for preparation of clocks.

[Arvind Yadav]

Hi,


On Thursday 27 July 2017 12:42 AM, Krzysztof Kozlowski wrote:

On Thu, Jul 27, 2017 at 12:28:52AM +0530, Arvind Yadav wrote:

-Use devm_clk_get() to make cleanup paths more simple.
-clk_prepare_enable() can fail here and we must check its return value.
-Add s3c_i2sv2_remove cleanup function of s3c_i2sv2_probe.
-No need to iounmap. Here, mapping done by devm_ioremap_resource.

Signed-off-by: Arvind Yadav 

Since I did not hear from you, I just sent fixes for these. We missed
each other by two minutes. :)

Anyway it is good to do one fix at a time, not everything in one commit.
You are changing here a lot so this should be split.

BTW, do you have the s3c24xx hardware? Can you test if issues spotted
here and in my patchset really happen?

Best regards,
Krzysztof

Please drop this patch. Sorry, I don't have s3c24xx hardware.
This is not available. :(

Thanks,
~arvind

---
  sound/soc/samsung/s3c-i2s-v2.c  | 19 ---
  sound/soc/samsung/s3c-i2s-v2.h  |  3 +++
  sound/soc/samsung/s3c2412-i2s.c | 10 --
  3 files changed, 27 insertions(+), 5 deletions(-)

diff --git a/sound/soc/samsung/s3c-i2s-v2.c b/sound/soc/samsung/s3c-i2s-v2.c
index 8f42dea..ab4899f 100644
--- a/sound/soc/samsung/s3c-i2s-v2.c
+++ b/sound/soc/samsung/s3c-i2s-v2.c
@@ -625,20 +625,24 @@ int s3c_i2sv2_probe(struct snd_soc_dai *dai,
  {
struct device *dev = dai->dev;
unsigned int iismod;
+   int ret;
  
  	i2s->dev = dev;
  
  	/* record our i2s structure for later use in the callbacks */

snd_soc_dai_set_drvdata(dai, i2s);
  
-	i2s->iis_pclk = clk_get(dev, "iis");

+   i2s->iis_pclk = devm_clk_get(dev, "iis");
if (IS_ERR(i2s->iis_pclk)) {
dev_err(dev, "failed to get iis_clock\n");
-   iounmap(i2s->regs);
return -ENOENT;
}
  
-	clk_enable(i2s->iis_pclk);

+   ret = clk_prepare_enable(i2s->iis_pclk);
+   if (ret) {
+   dev_err(dev, "failed to prepare iis_clock\n");
+   return ret;
+   }
  
  	/* Mark ourselves as in TXRX mode so we can run through our cleanup

 * process without warnings. */
@@ -652,6 +656,15 @@ int s3c_i2sv2_probe(struct snd_soc_dai *dai,
  }
  EXPORT_SYMBOL_GPL(s3c_i2sv2_probe);
  
+int s3c_i2sv2_remove(struct snd_soc_dai *dai)

+{
+   struct s3c_i2sv2_info *i2s = to_info(dai);
+
+   clk_disable_unprepare(i2s->iis_pclk);
+   return 0;
+}
+EXPORT_SYMBOL_GPL(s3c_i2sv2_remove);
+
  #ifdef CONFIG_PM
  static int s3c2412_i2s_suspend(struct snd_soc_dai *dai)
  {
diff --git a/sound/soc/samsung/s3c-i2s-v2.h b/sound/soc/samsung/s3c-i2s-v2.h
index 182d805..d6844b9 100644
--- a/sound/soc/samsung/s3c-i2s-v2.h
+++ b/sound/soc/samsung/s3c-i2s-v2.h
@@ -91,6 +91,9 @@ extern int s3c_i2sv2_probe(struct snd_soc_dai *dai,
   struct s3c_i2sv2_info *i2s,
   unsigned long base);
  
+

+extern int s3c_i2sv2_remove(struct snd_soc_dai *dai);
+
  /**
   * s3c_i2sv2_register_component - register component and dai with soc core
   * @dev: DAI device
diff --git a/sound/soc/samsung/s3c2412-i2s.c b/sound/soc/samsung/s3c2412-i2s.c
index 0a47182..adfbd52d 100644
--- a/sound/soc/samsung/s3c2412-i2s.c
+++ b/sound/soc/samsung/s3c2412-i2s.c
@@ -65,13 +65,18 @@ static int s3c2412_i2s_probe(struct snd_soc_dai *dai)
s3c2412_i2s.iis_cclk = devm_clk_get(dai->dev, "i2sclk");
if (IS_ERR(s3c2412_i2s.iis_cclk)) {
pr_err("failed to get i2sclk clock\n");
+   s3c_i2sv2_remove(dai);
return PTR_ERR(s3c2412_i2s.iis_cclk);
}
  
  	/* Set MPLL as the source for IIS CLK */
  
-	clk_set_parent(s3c2412_i2s.iis_cclk, clk_get(NULL, "mpll"));

-   clk_prepare_enable(s3c2412_i2s.iis_cclk);
+   clk_set_parent(s3c2412_i2s.iis_cclk, devm_clk_get(dai->dev, "mpll"));
+   ret = clk_prepare_enable(s3c2412_i2s.iis_cclk);
+   if (ret) {
+   s3c_i2sv2_remove(dai);
+   return ret;
+   }
  
  	s3c2412_i2s.iis_cclk = s3c2412_i2s.iis_pclk;
  
@@ -85,6 +90,7 @@ static int s3c2412_i2s_probe(struct snd_soc_dai *dai)

  static int s3c2412_i2s_remove(struct snd_soc_dai *dai)
  {
clk_disable_unprepare(s3c2412_i2s.iis_cclk);
+   s3c_i2sv2_remove(dai);
  
  	return 0;

  }
--
2.7.4

Re: [PATCH] ASoC: samsung: s3c2412: cleanups / fixes for preparation of clocks.

[Arvind Yadav]

Hi,


On Thursday 27 July 2017 12:42 AM, Krzysztof Kozlowski wrote:

On Thu, Jul 27, 2017 at 12:28:52AM +0530, Arvind Yadav wrote:

-Use devm_clk_get() to make cleanup paths more simple.
-clk_prepare_enable() can fail here and we must check its return value.
-Add s3c_i2sv2_remove cleanup function of s3c_i2sv2_probe.
-No need to iounmap. Here, mapping done by devm_ioremap_resource.

Signed-off-by: Arvind Yadav 

Since I did not hear from you, I just sent fixes for these. We missed
each other by two minutes. :)

Anyway it is good to do one fix at a time, not everything in one commit.
You are changing here a lot so this should be split.

BTW, do you have the s3c24xx hardware? Can you test if issues spotted
here and in my patchset really happen?

Best regards,
Krzysztof

Please drop this patch. Sorry, I don't have s3c24xx hardware.
This is not available. :(

Thanks,
~arvind

---
  sound/soc/samsung/s3c-i2s-v2.c  | 19 ---
  sound/soc/samsung/s3c-i2s-v2.h  |  3 +++
  sound/soc/samsung/s3c2412-i2s.c | 10 --
  3 files changed, 27 insertions(+), 5 deletions(-)

diff --git a/sound/soc/samsung/s3c-i2s-v2.c b/sound/soc/samsung/s3c-i2s-v2.c
index 8f42dea..ab4899f 100644
--- a/sound/soc/samsung/s3c-i2s-v2.c
+++ b/sound/soc/samsung/s3c-i2s-v2.c
@@ -625,20 +625,24 @@ int s3c_i2sv2_probe(struct snd_soc_dai *dai,
  {
struct device *dev = dai->dev;
unsigned int iismod;
+   int ret;
  
  	i2s->dev = dev;
  
  	/* record our i2s structure for later use in the callbacks */

snd_soc_dai_set_drvdata(dai, i2s);
  
-	i2s->iis_pclk = clk_get(dev, "iis");

+   i2s->iis_pclk = devm_clk_get(dev, "iis");
if (IS_ERR(i2s->iis_pclk)) {
dev_err(dev, "failed to get iis_clock\n");
-   iounmap(i2s->regs);
return -ENOENT;
}
  
-	clk_enable(i2s->iis_pclk);

+   ret = clk_prepare_enable(i2s->iis_pclk);
+   if (ret) {
+   dev_err(dev, "failed to prepare iis_clock\n");
+   return ret;
+   }
  
  	/* Mark ourselves as in TXRX mode so we can run through our cleanup

 * process without warnings. */
@@ -652,6 +656,15 @@ int s3c_i2sv2_probe(struct snd_soc_dai *dai,
  }
  EXPORT_SYMBOL_GPL(s3c_i2sv2_probe);
  
+int s3c_i2sv2_remove(struct snd_soc_dai *dai)

+{
+   struct s3c_i2sv2_info *i2s = to_info(dai);
+
+   clk_disable_unprepare(i2s->iis_pclk);
+   return 0;
+}
+EXPORT_SYMBOL_GPL(s3c_i2sv2_remove);
+
  #ifdef CONFIG_PM
  static int s3c2412_i2s_suspend(struct snd_soc_dai *dai)
  {
diff --git a/sound/soc/samsung/s3c-i2s-v2.h b/sound/soc/samsung/s3c-i2s-v2.h
index 182d805..d6844b9 100644
--- a/sound/soc/samsung/s3c-i2s-v2.h
+++ b/sound/soc/samsung/s3c-i2s-v2.h
@@ -91,6 +91,9 @@ extern int s3c_i2sv2_probe(struct snd_soc_dai *dai,
   struct s3c_i2sv2_info *i2s,
   unsigned long base);
  
+

+extern int s3c_i2sv2_remove(struct snd_soc_dai *dai);
+
  /**
   * s3c_i2sv2_register_component - register component and dai with soc core
   * @dev: DAI device
diff --git a/sound/soc/samsung/s3c2412-i2s.c b/sound/soc/samsung/s3c2412-i2s.c
index 0a47182..adfbd52d 100644
--- a/sound/soc/samsung/s3c2412-i2s.c
+++ b/sound/soc/samsung/s3c2412-i2s.c
@@ -65,13 +65,18 @@ static int s3c2412_i2s_probe(struct snd_soc_dai *dai)
s3c2412_i2s.iis_cclk = devm_clk_get(dai->dev, "i2sclk");
if (IS_ERR(s3c2412_i2s.iis_cclk)) {
pr_err("failed to get i2sclk clock\n");
+   s3c_i2sv2_remove(dai);
return PTR_ERR(s3c2412_i2s.iis_cclk);
}
  
  	/* Set MPLL as the source for IIS CLK */
  
-	clk_set_parent(s3c2412_i2s.iis_cclk, clk_get(NULL, "mpll"));

-   clk_prepare_enable(s3c2412_i2s.iis_cclk);
+   clk_set_parent(s3c2412_i2s.iis_cclk, devm_clk_get(dai->dev, "mpll"));
+   ret = clk_prepare_enable(s3c2412_i2s.iis_cclk);
+   if (ret) {
+   s3c_i2sv2_remove(dai);
+   return ret;
+   }
  
  	s3c2412_i2s.iis_cclk = s3c2412_i2s.iis_pclk;
  
@@ -85,6 +90,7 @@ static int s3c2412_i2s_probe(struct snd_soc_dai *dai)

  static int s3c2412_i2s_remove(struct snd_soc_dai *dai)
  {
clk_disable_unprepare(s3c2412_i2s.iis_cclk);
+   s3c_i2sv2_remove(dai);
  
  	return 0;

  }
--
2.7.4

[PATCH v2 0/3] Initial Allwinner V3s CSI Support

[Yong Deng]

Sorry for resend the patch. Delivering to somebody in cc has failed at
last time.

This patchset add initial support for Allwinner V3s CSI.

Allwinner V3s SoC have two CSI module. CSI0 is used for MIPI interface
and CSI1 is used for parallel interface. This is not documented in
datasheet but by testing and guess.

This patchset implement a v4l2 framework driver and add a binding 
documentation for it. 

Currently, the driver only support the parallel interface. And has been
tested with a BT1120 signal which generating from FPGA. The following
fetures are not support with this patchset:
  - ISP 
  - MIPI-CSI2
  - Master clock for camera sensor
  - Power regulator for the front end IC

sun6i_csi_ops is still there. I seriously thought about it. Without 
sun6i_csi_ops, the dependency between sun6i_video and sun6i_csi_v3s
will be complicated. Comments and criticisms are welcome.

Changes in v2:
  * Change sunxi-csi to sun6i-csi
  * Rebase to media_tree master branch

Yong Deng (3):
  media: V3s: Add support for Allwinner CSI.
  dt-bindings: media: Add Allwinner V3s Camera Sensor Interface (CSI)
  media: MAINTAINERS: add entries for Allwinner V3s CSI

 .../devicetree/bindings/media/sun6i-csi.txt|  49 ++
 MAINTAINERS|   8 +
 drivers/media/platform/Kconfig |   1 +
 drivers/media/platform/Makefile|   2 +
 drivers/media/platform/sun6i-csi/Kconfig   |   9 +
 drivers/media/platform/sun6i-csi/Makefile  |   3 +
 drivers/media/platform/sun6i-csi/sun6i_csi.c   | 545 ++
 drivers/media/platform/sun6i-csi/sun6i_csi.h   | 203 +
 drivers/media/platform/sun6i-csi/sun6i_csi_v3s.c   | 827 +
 drivers/media/platform/sun6i-csi/sun6i_csi_v3s.h   | 206 +
 drivers/media/platform/sun6i-csi/sun6i_video.c | 663 +
 drivers/media/platform/sun6i-csi/sun6i_video.h |  61 ++
 12 files changed, 2577 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/sun6i-csi.txt
 create mode 100644 drivers/media/platform/sun6i-csi/Kconfig
 create mode 100644 drivers/media/platform/sun6i-csi/Makefile
 create mode 100644 drivers/media/platform/sun6i-csi/sun6i_csi.c
 create mode 100644 drivers/media/platform/sun6i-csi/sun6i_csi.h
 create mode 100644 drivers/media/platform/sun6i-csi/sun6i_csi_v3s.c
 create mode 100644 drivers/media/platform/sun6i-csi/sun6i_csi_v3s.h
 create mode 100644 drivers/media/platform/sun6i-csi/sun6i_video.c
 create mode 100644 drivers/media/platform/sun6i-csi/sun6i_video.h

-- 
1.8.3.1

[PATCH v2 0/3] Initial Allwinner V3s CSI Support

[Yong Deng]

Sorry for resend the patch. Delivering to somebody in cc has failed at
last time.

This patchset add initial support for Allwinner V3s CSI.

Allwinner V3s SoC have two CSI module. CSI0 is used for MIPI interface
and CSI1 is used for parallel interface. This is not documented in
datasheet but by testing and guess.

This patchset implement a v4l2 framework driver and add a binding 
documentation for it. 

Currently, the driver only support the parallel interface. And has been
tested with a BT1120 signal which generating from FPGA. The following
fetures are not support with this patchset:
  - ISP 
  - MIPI-CSI2
  - Master clock for camera sensor
  - Power regulator for the front end IC

sun6i_csi_ops is still there. I seriously thought about it. Without 
sun6i_csi_ops, the dependency between sun6i_video and sun6i_csi_v3s
will be complicated. Comments and criticisms are welcome.

Changes in v2:
  * Change sunxi-csi to sun6i-csi
  * Rebase to media_tree master branch

Yong Deng (3):
  media: V3s: Add support for Allwinner CSI.
  dt-bindings: media: Add Allwinner V3s Camera Sensor Interface (CSI)
  media: MAINTAINERS: add entries for Allwinner V3s CSI

 .../devicetree/bindings/media/sun6i-csi.txt|  49 ++
 MAINTAINERS|   8 +
 drivers/media/platform/Kconfig |   1 +
 drivers/media/platform/Makefile|   2 +
 drivers/media/platform/sun6i-csi/Kconfig   |   9 +
 drivers/media/platform/sun6i-csi/Makefile  |   3 +
 drivers/media/platform/sun6i-csi/sun6i_csi.c   | 545 ++
 drivers/media/platform/sun6i-csi/sun6i_csi.h   | 203 +
 drivers/media/platform/sun6i-csi/sun6i_csi_v3s.c   | 827 +
 drivers/media/platform/sun6i-csi/sun6i_csi_v3s.h   | 206 +
 drivers/media/platform/sun6i-csi/sun6i_video.c | 663 +
 drivers/media/platform/sun6i-csi/sun6i_video.h |  61 ++
 12 files changed, 2577 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/sun6i-csi.txt
 create mode 100644 drivers/media/platform/sun6i-csi/Kconfig
 create mode 100644 drivers/media/platform/sun6i-csi/Makefile
 create mode 100644 drivers/media/platform/sun6i-csi/sun6i_csi.c
 create mode 100644 drivers/media/platform/sun6i-csi/sun6i_csi.h
 create mode 100644 drivers/media/platform/sun6i-csi/sun6i_csi_v3s.c
 create mode 100644 drivers/media/platform/sun6i-csi/sun6i_csi_v3s.h
 create mode 100644 drivers/media/platform/sun6i-csi/sun6i_video.c
 create mode 100644 drivers/media/platform/sun6i-csi/sun6i_video.h

-- 
1.8.3.1

Re: [PATCH 02/16] fpga: add FPGA device framework

[Wu Hao]

On Wed, Jul 26, 2017 at 05:29:11PM -0500, Alan Tull wrote:
> On Wed, Jul 26, 2017 at 9:20 AM, Alan Tull  wrote:
> > On Wed, Jul 26, 2017 at 4:50 AM, Wu Hao  wrote:
> >> On Tue, Jul 25, 2017 at 04:32:10PM -0500, Alan Tull wrote:
> >>> On Sat, Apr 1, 2017 at 7:18 AM, Wu Hao  wrote:
> >>>
> >>> Hi Hao,
> >>>
> >>> > On Fri, Mar 31, 2017 at 12:01:13PM -0700, 
> >>> > matthew.gerl...@linux.intel.com wrote:
> >>> >> On Fri, 31 Mar 2017, Wu Hao wrote:
> >>> >> >On Fri, Mar 31, 2017 at 08:09:09AM +0200, Greg KH wrote:
> >>> >> >>On Thu, Mar 30, 2017 at 08:08:02PM +0800, Wu Hao wrote:
> >>> >> >>>During FPGA device (e.g PCI-based) discovery, platform devices are
> >>> >> >>>registered for different FPGA function units. But the device node 
> >>> >> >>>path
> >>> >> >>>isn't quite friendly to applications.
> >>> >> >>>
> >>> >> >>>Consider this case, applications want to access child device's 
> >>> >> >>>sysfs file
> >>> >> >>>for some information.
> >>> >> >>>
> >>> >> >>>1) Access using bus-based path (e.g PCI)
> >>> >> >>>
> >>> >> >>>  /sys/bus/pci/devices/x/fpga_func_a.0/sysfs_file
> >>> >> >>>
> >>> >> >>>  From the path, it's clear which PCI device is the parent, but not 
> >>> >> >>> perfect
> >>> >> >>>  solution for applications. PCI device BDF is not fixed, 
> >>> >> >>> application may
> >>> >> >>>  need to search all PCI device to find the actual FPGA Device.
> >>> >> >>>
> >>> >> >>>2) Or access using platform device path
> >>> >> >>>
> >>> >> >>>  /sys/bus/platform/devices/fpga_func_a.0/sysfs_file
> >>> >> >>>
> >>> >> >>>  Applications find the actual function by name easily, but no 
> >>> >> >>> information
> >>> >> >>>  about which fpga device it belongs to. It's quite confusing if 
> >>> >> >>> multiple
> >>> >> >>>  FPGA devices are in one system.
> >>> >> >>>
> >>> >> >>>'FPGA Device' class is introduced to resolve this problem. Each 
> >>> >> >>>node under
> >>> >> >>>this class represents a fpga device, which may have one or more 
> >>> >> >>>child
> >>> >> >>>devices. Applications only need to search under this FPGA Device 
> >>> >> >>>class
> >>> >> >>>folder to find the child device node it needs.
> >>> >> >>>
> >>> >> >>>For example, for the platform has 2 fpga devices, each fpga device 
> >>> >> >>>has
> >>> >> >>>3 child devices, the hierarchy looks like this.
> >>> >> >>>
> >>> >> >>>Two nodes are under /sys/class/fpga/:
> >>> >> >>>/sys/class/fpga/fpga.0
> >>> >> >>>/sys/class/fpga/fpga.1
> >>> >> >>>
> >>> >> >>>Each node has 1 function A device and 2 function B devices:
> >>> >> >>>/sys/class/fpga/fpga.0/func_a.0
> >>> >> >>>/sys/class/fpga/fpga.0/func_b.0
> >>> >> >>>/sys/class/fpga/fpga.0/func_b.1
> >>> >> >>>
> >>> >> >>>/sys/class/fpga/fpga.1/func_a.1
> >>> >> >>>/sys/class/fpga/fpga.1/func_b.2
> >>> >> >>>/sys/class/fpga/fpga.1/func_b.3
> >>> >> >>>
> >>> >> >>>This following APIs are provided by FPGA device framework:
> >>> >> >>>* fpga_dev_create
> >>> >> >>>  Create fpga device under the given parent device.
> >>> >> >>>* fpga_dev_destroy
> >>> >> >>>  Destroy fpga device
> >>> >> >>>
> >>> >> >>>The following sysfs files are created:
> >>> >> >>>* /sys/class/fpga//name
> >>> >> >>>  Name of the fpga device.
> >>> >> >>
> >>> >> >>How does this interact with the existing "fpga class" that is in the
> >>> >> >>kernel already?
> >>> >> >
> >>> >> >The fpga-dev introduced by this patch, is only a container device, and
> >>> >>
> >>> >> I completely understand the need for a container device.  The 
> >>> >> fpga-region is
> >>> >> also primarily a container, and in some cases the fpga-region may 
> >>> >> represent
> >>> >> the entire fpga.  Over time this code may become redundant.
> >>> >
> >>> > Thanks a lot for your review and comments.
> >>> >
> >>> > I feel that the fpga-region implies that it supports reconfiguration,
> >>>
> >>> On Arria10, we create base fpga region which does not support full
> >>> reconfiguration.  It corresponds to the whole FPGA area, which was
> >>> loaded with a static FPGA image in the bootloader.  The partial
> >>> reconfiguration regions are children of the base FPGA region.  Any
> >>> devices in the FPGA are child devices of either the base region or a
> >>> region which is a child of it.
> >>>
> >>> > but
> >>> > in our cases, the Intel FPGA device, doesn't have base fpga-region for
> >>> > full reconfiguration, but many accelerators with partial reconfiguration
> >>> > support. A fpga-region brings together everything needed for the
> >>> > reconfiguration, and a fpga-dev is trying to brings everything on a FPGA
> >>> > device together, including fpga-region/bridge/manager, access different
> >>> > accelerators and other function units.
> >>> >
> >>> > I think it's not mandatory to use fpga-dev, as fpga-dev is just trying 
> >>> > to
> >>> > provide one more option here for some complex hardware.
> >>>
> >>> Now that you've put out v2 which uses fpga-regions, do you still need
> >>> 

Re: [PATCH 02/16] fpga: add FPGA device framework

[Wu Hao]

On Wed, Jul 26, 2017 at 05:29:11PM -0500, Alan Tull wrote:
> On Wed, Jul 26, 2017 at 9:20 AM, Alan Tull  wrote:
> > On Wed, Jul 26, 2017 at 4:50 AM, Wu Hao  wrote:
> >> On Tue, Jul 25, 2017 at 04:32:10PM -0500, Alan Tull wrote:
> >>> On Sat, Apr 1, 2017 at 7:18 AM, Wu Hao  wrote:
> >>>
> >>> Hi Hao,
> >>>
> >>> > On Fri, Mar 31, 2017 at 12:01:13PM -0700, 
> >>> > matthew.gerl...@linux.intel.com wrote:
> >>> >> On Fri, 31 Mar 2017, Wu Hao wrote:
> >>> >> >On Fri, Mar 31, 2017 at 08:09:09AM +0200, Greg KH wrote:
> >>> >> >>On Thu, Mar 30, 2017 at 08:08:02PM +0800, Wu Hao wrote:
> >>> >> >>>During FPGA device (e.g PCI-based) discovery, platform devices are
> >>> >> >>>registered for different FPGA function units. But the device node 
> >>> >> >>>path
> >>> >> >>>isn't quite friendly to applications.
> >>> >> >>>
> >>> >> >>>Consider this case, applications want to access child device's 
> >>> >> >>>sysfs file
> >>> >> >>>for some information.
> >>> >> >>>
> >>> >> >>>1) Access using bus-based path (e.g PCI)
> >>> >> >>>
> >>> >> >>>  /sys/bus/pci/devices/x/fpga_func_a.0/sysfs_file
> >>> >> >>>
> >>> >> >>>  From the path, it's clear which PCI device is the parent, but not 
> >>> >> >>> perfect
> >>> >> >>>  solution for applications. PCI device BDF is not fixed, 
> >>> >> >>> application may
> >>> >> >>>  need to search all PCI device to find the actual FPGA Device.
> >>> >> >>>
> >>> >> >>>2) Or access using platform device path
> >>> >> >>>
> >>> >> >>>  /sys/bus/platform/devices/fpga_func_a.0/sysfs_file
> >>> >> >>>
> >>> >> >>>  Applications find the actual function by name easily, but no 
> >>> >> >>> information
> >>> >> >>>  about which fpga device it belongs to. It's quite confusing if 
> >>> >> >>> multiple
> >>> >> >>>  FPGA devices are in one system.
> >>> >> >>>
> >>> >> >>>'FPGA Device' class is introduced to resolve this problem. Each 
> >>> >> >>>node under
> >>> >> >>>this class represents a fpga device, which may have one or more 
> >>> >> >>>child
> >>> >> >>>devices. Applications only need to search under this FPGA Device 
> >>> >> >>>class
> >>> >> >>>folder to find the child device node it needs.
> >>> >> >>>
> >>> >> >>>For example, for the platform has 2 fpga devices, each fpga device 
> >>> >> >>>has
> >>> >> >>>3 child devices, the hierarchy looks like this.
> >>> >> >>>
> >>> >> >>>Two nodes are under /sys/class/fpga/:
> >>> >> >>>/sys/class/fpga/fpga.0
> >>> >> >>>/sys/class/fpga/fpga.1
> >>> >> >>>
> >>> >> >>>Each node has 1 function A device and 2 function B devices:
> >>> >> >>>/sys/class/fpga/fpga.0/func_a.0
> >>> >> >>>/sys/class/fpga/fpga.0/func_b.0
> >>> >> >>>/sys/class/fpga/fpga.0/func_b.1
> >>> >> >>>
> >>> >> >>>/sys/class/fpga/fpga.1/func_a.1
> >>> >> >>>/sys/class/fpga/fpga.1/func_b.2
> >>> >> >>>/sys/class/fpga/fpga.1/func_b.3
> >>> >> >>>
> >>> >> >>>This following APIs are provided by FPGA device framework:
> >>> >> >>>* fpga_dev_create
> >>> >> >>>  Create fpga device under the given parent device.
> >>> >> >>>* fpga_dev_destroy
> >>> >> >>>  Destroy fpga device
> >>> >> >>>
> >>> >> >>>The following sysfs files are created:
> >>> >> >>>* /sys/class/fpga//name
> >>> >> >>>  Name of the fpga device.
> >>> >> >>
> >>> >> >>How does this interact with the existing "fpga class" that is in the
> >>> >> >>kernel already?
> >>> >> >
> >>> >> >The fpga-dev introduced by this patch, is only a container device, and
> >>> >>
> >>> >> I completely understand the need for a container device.  The 
> >>> >> fpga-region is
> >>> >> also primarily a container, and in some cases the fpga-region may 
> >>> >> represent
> >>> >> the entire fpga.  Over time this code may become redundant.
> >>> >
> >>> > Thanks a lot for your review and comments.
> >>> >
> >>> > I feel that the fpga-region implies that it supports reconfiguration,
> >>>
> >>> On Arria10, we create base fpga region which does not support full
> >>> reconfiguration.  It corresponds to the whole FPGA area, which was
> >>> loaded with a static FPGA image in the bootloader.  The partial
> >>> reconfiguration regions are children of the base FPGA region.  Any
> >>> devices in the FPGA are child devices of either the base region or a
> >>> region which is a child of it.
> >>>
> >>> > but
> >>> > in our cases, the Intel FPGA device, doesn't have base fpga-region for
> >>> > full reconfiguration, but many accelerators with partial reconfiguration
> >>> > support. A fpga-region brings together everything needed for the
> >>> > reconfiguration, and a fpga-dev is trying to brings everything on a FPGA
> >>> > device together, including fpga-region/bridge/manager, access different
> >>> > accelerators and other function units.
> >>> >
> >>> > I think it's not mandatory to use fpga-dev, as fpga-dev is just trying 
> >>> > to
> >>> > provide one more option here for some complex hardware.
> >>>
> >>> Now that you've put out v2 which uses fpga-regions, do you still need
> >>> fpga-dev class?
> >>
> >> Hi Alan
> >>
> >> Thanks for 

Re: [PATCH 4/6] dma: bcm-sba-raid: Break sba_process_deferred_requests() into two parts

[Anup Patel]

On Wed, Jul 26, 2017 at 10:45 PM, Vinod Koul  wrote:
> On Wed, Jul 26, 2017 at 11:06:42AM +0530, Anup Patel wrote:
>> This patch breaks sba_process_deferred_requests() into two parts
>> sba_process_received_request() and _sba_process_pending_requests()
>> for readability.
>>
>> In addition,
>
> that should be a separate patch then... no?
>
>> we remove redundant SBA_REQUEST_STATE_RECEIVED state
>
> this should be one more...

OK, I will make this separate patch.

>
>> and ensure that all requests in a chained request should be freed
>> only after all have been received.
>
> and then this, right?

OK.

>
>>
>> Signed-off-by: Anup Patel 
>> Reviewed-by: Scott Branden 
>> ---
>>  drivers/dma/bcm-sba-raid.c | 130 
>> -
>>  1 file changed, 47 insertions(+), 83 deletions(-)
>>
>> diff --git a/drivers/dma/bcm-sba-raid.c b/drivers/dma/bcm-sba-raid.c
>> index db5e3db..b92c756 100644
>> --- a/drivers/dma/bcm-sba-raid.c
>> +++ b/drivers/dma/bcm-sba-raid.c
>> @@ -97,9 +97,8 @@ enum sba_request_flags {
>>   SBA_REQUEST_STATE_ALLOCED   = 0x002,
>>   SBA_REQUEST_STATE_PENDING   = 0x004,
>>   SBA_REQUEST_STATE_ACTIVE= 0x008,
>> - SBA_REQUEST_STATE_RECEIVED  = 0x010,
>> - SBA_REQUEST_STATE_COMPLETED = 0x020,
>> - SBA_REQUEST_STATE_ABORTED   = 0x040,
>> + SBA_REQUEST_STATE_COMPLETED = 0x010,
>> + SBA_REQUEST_STATE_ABORTED   = 0x020,
>
> so we changed this is patch 1, only to change it here. why
>
> so let me stop here again and repeat myself again about splitting stuff up,
> blah blah, good patches, blah blah, read the Documentation blah blah.. and
> hope someones listening :(

OK, I will address your comments.

Regards,
Anup

Re: [PATCH 4/6] dma: bcm-sba-raid: Break sba_process_deferred_requests() into two parts

[Anup Patel]

On Wed, Jul 26, 2017 at 10:45 PM, Vinod Koul  wrote:
> On Wed, Jul 26, 2017 at 11:06:42AM +0530, Anup Patel wrote:
>> This patch breaks sba_process_deferred_requests() into two parts
>> sba_process_received_request() and _sba_process_pending_requests()
>> for readability.
>>
>> In addition,
>
> that should be a separate patch then... no?
>
>> we remove redundant SBA_REQUEST_STATE_RECEIVED state
>
> this should be one more...

OK, I will make this separate patch.

>
>> and ensure that all requests in a chained request should be freed
>> only after all have been received.
>
> and then this, right?

OK.

>
>>
>> Signed-off-by: Anup Patel 
>> Reviewed-by: Scott Branden 
>> ---
>>  drivers/dma/bcm-sba-raid.c | 130 
>> -
>>  1 file changed, 47 insertions(+), 83 deletions(-)
>>
>> diff --git a/drivers/dma/bcm-sba-raid.c b/drivers/dma/bcm-sba-raid.c
>> index db5e3db..b92c756 100644
>> --- a/drivers/dma/bcm-sba-raid.c
>> +++ b/drivers/dma/bcm-sba-raid.c
>> @@ -97,9 +97,8 @@ enum sba_request_flags {
>>   SBA_REQUEST_STATE_ALLOCED   = 0x002,
>>   SBA_REQUEST_STATE_PENDING   = 0x004,
>>   SBA_REQUEST_STATE_ACTIVE= 0x008,
>> - SBA_REQUEST_STATE_RECEIVED  = 0x010,
>> - SBA_REQUEST_STATE_COMPLETED = 0x020,
>> - SBA_REQUEST_STATE_ABORTED   = 0x040,
>> + SBA_REQUEST_STATE_COMPLETED = 0x010,
>> + SBA_REQUEST_STATE_ABORTED   = 0x020,
>
> so we changed this is patch 1, only to change it here. why
>
> so let me stop here again and repeat myself again about splitting stuff up,
> blah blah, good patches, blah blah, read the Documentation blah blah.. and
> hope someones listening :(

OK, I will address your comments.

Regards,
Anup

Re: [PATCH v2 6/7] mailbox: bcm-flexrm-mailbox: Set msg_queue_len for each channel

[Jassi Brar]

On Thu, Jul 27, 2017 at 9:25 AM, Anup Patel  wrote:
> On Tue, Jul 25, 2017 at 9:37 PM, Jassi Brar  wrote:
>> On Tue, Jul 25, 2017 at 11:11 AM, Anup Patel  wrote:
>>> On Mon, Jul 24, 2017 at 10:06 PM, Jassi Brar  
>>> wrote:
 On Mon, Jul 24, 2017 at 9:26 AM, Anup Patel  
 wrote:
> Hi Jassi,
>
> Sorry for the delayed response...
>
> On Fri, Jul 21, 2017 at 9:16 PM, Jassi Brar  
> wrote:
>> Hi Anup,
>>
>> On Fri, Jul 21, 2017 at 12:25 PM, Anup Patel  
>> wrote:
>>> The Broadcom FlexRM ring (i.e. mailbox channel) can handle
>>> larger number of messages queued in one FlexRM ring hence
>>> this patch sets msg_queue_len for each mailbox channel to
>>> be same as RING_MAX_REQ_COUNT.
>>>
>>> Signed-off-by: Anup Patel 
>>> Reviewed-by: Scott Branden 
>>> ---
>>>  drivers/mailbox/bcm-flexrm-mailbox.c | 5 -
>>>  1 file changed, 4 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/mailbox/bcm-flexrm-mailbox.c 
>>> b/drivers/mailbox/bcm-flexrm-mailbox.c
>>> index 9873818..20055a0 100644
>>> --- a/drivers/mailbox/bcm-flexrm-mailbox.c
>>> +++ b/drivers/mailbox/bcm-flexrm-mailbox.c
>>> @@ -1683,8 +1683,11 @@ static int flexrm_mbox_probe(struct 
>>> platform_device *pdev)
>>> ret = -ENOMEM;
>>> goto fail_free_debugfs_root;
>>> }
>>> -   for (index = 0; index < mbox->num_rings; index++)
>>> +   for (index = 0; index < mbox->num_rings; index++) {
>>> +   mbox->controller.chans[index].msg_queue_len =
>>> +   RING_MAX_REQ_COUNT;
>>> mbox->controller.chans[index].con_priv = 
>>> >rings[index];
>>> +   }
>>>
>> While writing mailbox.c I wasn't unaware that there is the option to
>> choose the queue length at runtime.
>> The idea was to keep the code as simple as possible. I am open to
>> making it a runtime thing, but first, please help me understand how
>> that is useful here.
>>
>> I understand FlexRm has a ring buffer of RING_MAX_REQ_COUNT(1024)
>> elements. Any message submitted to mailbox api can be immediately
>> written onto the ringbuffer if there is some space.
>> Is there any mechanism to report back to a client driver, if its
>> message in ringbuffer failed "to be sent"?
>> If there isn't any, then I think, in flexrm_last_tx_done() you should
>> simply return true if there is some space left in the rung-buffer,
>> false otherwise.
>
> Yes, we have error code in "struct brcm_message" to report back
> errors from send_message. In our mailbox clients, we check
> return value of mbox_send_message() and also the error code
> in "struct brcm_message".
>
 I meant after the message has been accepted in the ringbuffer but the
 remote failed to receive it.
>>>
>>> Yes, even this case is handled.
>>>
>>> In case of IO errors after message has been put in ring buffer, we get
>>> completion message with error code and mailbox client drivers will
>>> receive back "struct brcm_message" with error set.
>>>
>>> You can refer flexrm_process_completions() for more details.
>>>
It doesn't seem to be what I suggest. I see two issues in
flexrm_process_completions()
1) It calls mbox_send_message(), which is a big NO for a controller
driver. Why should you have one more message stored outside of
ringbuffer?

2) It calls mbox_chan_received_data()  which is for messages received
from the remote. And not the way to report failed _transmission_, for
which the api calls back mbox_client.tx_done() .  In your client
driver please populate mbox_client.tx_done() and see which message is
reported "sent fine" when.


 There seems no such provision. IIANW, then you should be able to
 consider every message as "sent successfully" once it is in the ring
 buffer i.e, immediately after mbox_send_message() returns 0.
 In that case I would think you don't need more than a couple of
 entries out of MBOX_TX_QUEUE_LEN ?
>>>
>>> What I am trying to suggest is that we can take upto 1024 messages
>>> in a FlexRM ring but the MBOX_TX_QUEUE_LEN limits us queuing
>>> more messages. This issue manifest easily when multiple CPUs
>>> queues to same FlexRM ring (i.e. same mailbox channel).
>>>
>> OK then, I guess we have to make the queue length a runtime decision.
>
> Do you agree with approach taken by PATCH5 and PATCH6 to
> make queue length runtime?
>
I agree that we may have to get the queue length from platform, if
MBOX_TX_QUEUE_LEN is limiting performance. That will be easier on both
of us. However I suspect the right fix for _this_ 

Re: [PATCH v2 6/7] mailbox: bcm-flexrm-mailbox: Set msg_queue_len for each channel

[Jassi Brar]

On Thu, Jul 27, 2017 at 9:25 AM, Anup Patel  wrote:
> On Tue, Jul 25, 2017 at 9:37 PM, Jassi Brar  wrote:
>> On Tue, Jul 25, 2017 at 11:11 AM, Anup Patel  wrote:
>>> On Mon, Jul 24, 2017 at 10:06 PM, Jassi Brar  
>>> wrote:
 On Mon, Jul 24, 2017 at 9:26 AM, Anup Patel  
 wrote:
> Hi Jassi,
>
> Sorry for the delayed response...
>
> On Fri, Jul 21, 2017 at 9:16 PM, Jassi Brar  
> wrote:
>> Hi Anup,
>>
>> On Fri, Jul 21, 2017 at 12:25 PM, Anup Patel  
>> wrote:
>>> The Broadcom FlexRM ring (i.e. mailbox channel) can handle
>>> larger number of messages queued in one FlexRM ring hence
>>> this patch sets msg_queue_len for each mailbox channel to
>>> be same as RING_MAX_REQ_COUNT.
>>>
>>> Signed-off-by: Anup Patel 
>>> Reviewed-by: Scott Branden 
>>> ---
>>>  drivers/mailbox/bcm-flexrm-mailbox.c | 5 -
>>>  1 file changed, 4 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/mailbox/bcm-flexrm-mailbox.c 
>>> b/drivers/mailbox/bcm-flexrm-mailbox.c
>>> index 9873818..20055a0 100644
>>> --- a/drivers/mailbox/bcm-flexrm-mailbox.c
>>> +++ b/drivers/mailbox/bcm-flexrm-mailbox.c
>>> @@ -1683,8 +1683,11 @@ static int flexrm_mbox_probe(struct 
>>> platform_device *pdev)
>>> ret = -ENOMEM;
>>> goto fail_free_debugfs_root;
>>> }
>>> -   for (index = 0; index < mbox->num_rings; index++)
>>> +   for (index = 0; index < mbox->num_rings; index++) {
>>> +   mbox->controller.chans[index].msg_queue_len =
>>> +   RING_MAX_REQ_COUNT;
>>> mbox->controller.chans[index].con_priv = 
>>> >rings[index];
>>> +   }
>>>
>> While writing mailbox.c I wasn't unaware that there is the option to
>> choose the queue length at runtime.
>> The idea was to keep the code as simple as possible. I am open to
>> making it a runtime thing, but first, please help me understand how
>> that is useful here.
>>
>> I understand FlexRm has a ring buffer of RING_MAX_REQ_COUNT(1024)
>> elements. Any message submitted to mailbox api can be immediately
>> written onto the ringbuffer if there is some space.
>> Is there any mechanism to report back to a client driver, if its
>> message in ringbuffer failed "to be sent"?
>> If there isn't any, then I think, in flexrm_last_tx_done() you should
>> simply return true if there is some space left in the rung-buffer,
>> false otherwise.
>
> Yes, we have error code in "struct brcm_message" to report back
> errors from send_message. In our mailbox clients, we check
> return value of mbox_send_message() and also the error code
> in "struct brcm_message".
>
 I meant after the message has been accepted in the ringbuffer but the
 remote failed to receive it.
>>>
>>> Yes, even this case is handled.
>>>
>>> In case of IO errors after message has been put in ring buffer, we get
>>> completion message with error code and mailbox client drivers will
>>> receive back "struct brcm_message" with error set.
>>>
>>> You can refer flexrm_process_completions() for more details.
>>>
It doesn't seem to be what I suggest. I see two issues in
flexrm_process_completions()
1) It calls mbox_send_message(), which is a big NO for a controller
driver. Why should you have one more message stored outside of
ringbuffer?

2) It calls mbox_chan_received_data()  which is for messages received
from the remote. And not the way to report failed _transmission_, for
which the api calls back mbox_client.tx_done() .  In your client
driver please populate mbox_client.tx_done() and see which message is
reported "sent fine" when.


 There seems no such provision. IIANW, then you should be able to
 consider every message as "sent successfully" once it is in the ring
 buffer i.e, immediately after mbox_send_message() returns 0.
 In that case I would think you don't need more than a couple of
 entries out of MBOX_TX_QUEUE_LEN ?
>>>
>>> What I am trying to suggest is that we can take upto 1024 messages
>>> in a FlexRM ring but the MBOX_TX_QUEUE_LEN limits us queuing
>>> more messages. This issue manifest easily when multiple CPUs
>>> queues to same FlexRM ring (i.e. same mailbox channel).
>>>
>> OK then, I guess we have to make the queue length a runtime decision.
>
> Do you agree with approach taken by PATCH5 and PATCH6 to
> make queue length runtime?
>
I agree that we may have to get the queue length from platform, if
MBOX_TX_QUEUE_LEN is limiting performance. That will be easier on both
of us. However I suspect the right fix for _this_ situation is in
flexrm driver. See above.

>>
>> BTW, is it a practical use case that needs to queue upto 1024
>> requests? Or are you just testing?
>
> Yes, we just need bigger queue length for FlexRM but we
> choose 1024 (max limit) 

Re: [PATCH 2/6] dma: bcm-sba-raid: Peek mbox when we are left with no free requests

[Anup Patel]

On Wed, Jul 26, 2017 at 10:40 PM, Vinod Koul  wrote:
> On Wed, Jul 26, 2017 at 11:06:40AM +0530, Anup Patel wrote:
>> We should peek mbox channels when we are left with no free
>> sba_requests in sba_alloc_request()
>
> and why is the world should we do that, how does that help??

When setting up RAID array on several NVMe disk we observed
that sba_alloc_request() start failing (due to no free requests left)
and RAID array setup becomes very slow.

Doing mbox channel peek when we have no free requests left,
improves performance of RAID array setup.

This change is inspired from mv_chan_alloc_slot() implemented
in drivers/dma/mv_xor.c

Regards,
Anup

Re: [PATCH 2/6] dma: bcm-sba-raid: Peek mbox when we are left with no free requests

[Anup Patel]

On Wed, Jul 26, 2017 at 10:40 PM, Vinod Koul  wrote:
> On Wed, Jul 26, 2017 at 11:06:40AM +0530, Anup Patel wrote:
>> We should peek mbox channels when we are left with no free
>> sba_requests in sba_alloc_request()
>
> and why is the world should we do that, how does that help??

When setting up RAID array on several NVMe disk we observed
that sba_alloc_request() start failing (due to no free requests left)
and RAID array setup becomes very slow.

Doing mbox channel peek when we have no free requests left,
improves performance of RAID array setup.

This change is inspired from mv_chan_alloc_slot() implemented
in drivers/dma/mv_xor.c

Regards,
Anup

Re: [PATCH 1/6] dma: bcm-sba-raid: Improve memory allocation in SBA RAID driver

[Anup Patel]

On Wed, Jul 26, 2017 at 10:39 PM, Vinod Koul  wrote:
> On Wed, Jul 26, 2017 at 11:06:39AM +0530, Anup Patel wrote:
>> This patch improves memory allocation in SBA RAID driver in
>> following ways:
>> 1. Simplify struct sba_request to reduce memory consumption
>
> what is the simplification?? You need to document that

OK, will make it a separate patch with detailed commit description.

>
>> 2. Allocate sba resources before registering dma device
>
> what is the motivation for that
>
> So, reading this log doesnt help me to know what to expect in this patch

OK, this also requires separate patch with detailed commit description.

>
>>
>> Signed-off-by: Anup Patel 
>> Reviewed-by: Scott Branden 
>> Reviewed-by: Ray Jui 
>> Reviewed-by: Vikram Prakash 
>> ---
>>  drivers/dma/bcm-sba-raid.c | 439 
>> +++--
>>  1 file changed, 226 insertions(+), 213 deletions(-)
>>
>> diff --git a/drivers/dma/bcm-sba-raid.c b/drivers/dma/bcm-sba-raid.c
>> index e41bbc7..6d15fed 100644
>> --- a/drivers/dma/bcm-sba-raid.c
>> +++ b/drivers/dma/bcm-sba-raid.c
>> @@ -48,7 +48,8 @@
>>
>>  #include "dmaengine.h"
>>
>> -/* SBA command related defines */
>> +/* == Driver macros and defines = */
>
> why this noise, seems unrelated to the change!

This is just minor beautification. Again, I will put this
in separate patch.

>
>> +
>>  #define SBA_TYPE_SHIFT   48
>>  #define SBA_TYPE_MASKGENMASK(1, 0)
>>  #define SBA_TYPE_A   0x0
>> @@ -82,39 +83,41 @@
>>  #define SBA_CMD_WRITE_BUFFER 0xc
>>  #define SBA_CMD_GALOIS   0xe
>>
>> -/* Driver helper macros */
>> +#define SBA_MAX_REQ_PER_MBOX_CHANNEL 8192
>> +
>>  #define to_sba_request(tx)   \
>>   container_of(tx, struct sba_request, tx)
>>  #define to_sba_device(dchan) \
>>   container_of(dchan, struct sba_device, dma_chan)
>>
>> -enum sba_request_state {
>> - SBA_REQUEST_STATE_FREE = 1,
>> - SBA_REQUEST_STATE_ALLOCED = 2,
>> - SBA_REQUEST_STATE_PENDING = 3,
>> - SBA_REQUEST_STATE_ACTIVE = 4,
>> - SBA_REQUEST_STATE_RECEIVED = 5,
>> - SBA_REQUEST_STATE_COMPLETED = 6,
>> - SBA_REQUEST_STATE_ABORTED = 7,
>> +/* = Driver data structures = */
>> +
>> +enum sba_request_flags {
>> + SBA_REQUEST_STATE_FREE  = 0x001,
>> + SBA_REQUEST_STATE_ALLOCED   = 0x002,
>> + SBA_REQUEST_STATE_PENDING   = 0x004,
>> + SBA_REQUEST_STATE_ACTIVE= 0x008,
>> + SBA_REQUEST_STATE_RECEIVED  = 0x010,
>> + SBA_REQUEST_STATE_COMPLETED = 0x020,
>> + SBA_REQUEST_STATE_ABORTED   = 0x040,
>> + SBA_REQUEST_STATE_MASK  = 0x0ff,
>> + SBA_REQUEST_FENCE   = 0x100,
>
> how does this help in mem alloctn?
>
>>  };
>>
>>  struct sba_request {
>>   /* Global state */
>>   struct list_head node;
>>   struct sba_device *sba;
>> - enum sba_request_state state;
>> - bool fence;
>> + u32 flags;
>>   /* Chained requests management */
>>   struct sba_request *first;
>>   struct list_head next;
>> - unsigned int next_count;
>>   atomic_t next_pending_count;
>>   /* BRCM message data */
>> - void *resp;
>> - dma_addr_t resp_dma;
>> - struct brcm_sba_command *cmds;
>>   struct brcm_message msg;
>>   struct dma_async_tx_descriptor tx;
>> + /* SBA commands */
>> + struct brcm_sba_command cmds[0];
>>  };
>>
>>  enum sba_version {
>> @@ -128,11 +131,11 @@ struct sba_device {
>>   /* DT configuration parameters */
>>   enum sba_version ver;
>>   /* Derived configuration parameters */
>> - u32 max_req;
>>   u32 hw_buf_size;
>>   u32 hw_resp_size;
>>   u32 max_pq_coefs;
>>   u32 max_pq_srcs;
>> + u32 max_req;
>>   u32 max_cmd_per_req;
>>   u32 max_xor_srcs;
>>   u32 max_resp_pool_size;
>> @@ -152,7 +155,6 @@ struct sba_device {
>>   void *cmds_base;
>>   dma_addr_t cmds_dma_base;
>>   spinlock_t reqs_lock;
>> - struct sba_request *reqs;
>>   bool reqs_fence;
>>   struct list_head reqs_alloc_list;
>>   struct list_head reqs_pending_list;
>> @@ -161,10 +163,9 @@ struct sba_device {
>>   struct list_head reqs_completed_list;
>>   struct list_head reqs_aborted_list;
>>   struct list_head reqs_free_list;
>> - int reqs_free_count;
>>  };
>>
>> -/* == SBA command helper routines = */
>> +/* == Command helper routines = */
>
> more noise..
>
>>
>>  static inline u64 __pure sba_cmd_enc(u64 cmd, u32 val, u32 shift, u32 mask)
>>  {
>> @@ -196,7 +197,7 @@ static inline u32 __pure sba_cmd_pq_c_mdata(u32 d, u32 
>> b1, u32 b0)
>>  ((d & SBA_C_MDATA_DNUM_MASK) << 

Re: [PATCH 1/6] dma: bcm-sba-raid: Improve memory allocation in SBA RAID driver

[Anup Patel]

On Wed, Jul 26, 2017 at 10:39 PM, Vinod Koul  wrote:
> On Wed, Jul 26, 2017 at 11:06:39AM +0530, Anup Patel wrote:
>> This patch improves memory allocation in SBA RAID driver in
>> following ways:
>> 1. Simplify struct sba_request to reduce memory consumption
>
> what is the simplification?? You need to document that

OK, will make it a separate patch with detailed commit description.

>
>> 2. Allocate sba resources before registering dma device
>
> what is the motivation for that
>
> So, reading this log doesnt help me to know what to expect in this patch

OK, this also requires separate patch with detailed commit description.

>
>>
>> Signed-off-by: Anup Patel 
>> Reviewed-by: Scott Branden 
>> Reviewed-by: Ray Jui 
>> Reviewed-by: Vikram Prakash 
>> ---
>>  drivers/dma/bcm-sba-raid.c | 439 
>> +++--
>>  1 file changed, 226 insertions(+), 213 deletions(-)
>>
>> diff --git a/drivers/dma/bcm-sba-raid.c b/drivers/dma/bcm-sba-raid.c
>> index e41bbc7..6d15fed 100644
>> --- a/drivers/dma/bcm-sba-raid.c
>> +++ b/drivers/dma/bcm-sba-raid.c
>> @@ -48,7 +48,8 @@
>>
>>  #include "dmaengine.h"
>>
>> -/* SBA command related defines */
>> +/* == Driver macros and defines = */
>
> why this noise, seems unrelated to the change!

This is just minor beautification. Again, I will put this
in separate patch.

>
>> +
>>  #define SBA_TYPE_SHIFT   48
>>  #define SBA_TYPE_MASKGENMASK(1, 0)
>>  #define SBA_TYPE_A   0x0
>> @@ -82,39 +83,41 @@
>>  #define SBA_CMD_WRITE_BUFFER 0xc
>>  #define SBA_CMD_GALOIS   0xe
>>
>> -/* Driver helper macros */
>> +#define SBA_MAX_REQ_PER_MBOX_CHANNEL 8192
>> +
>>  #define to_sba_request(tx)   \
>>   container_of(tx, struct sba_request, tx)
>>  #define to_sba_device(dchan) \
>>   container_of(dchan, struct sba_device, dma_chan)
>>
>> -enum sba_request_state {
>> - SBA_REQUEST_STATE_FREE = 1,
>> - SBA_REQUEST_STATE_ALLOCED = 2,
>> - SBA_REQUEST_STATE_PENDING = 3,
>> - SBA_REQUEST_STATE_ACTIVE = 4,
>> - SBA_REQUEST_STATE_RECEIVED = 5,
>> - SBA_REQUEST_STATE_COMPLETED = 6,
>> - SBA_REQUEST_STATE_ABORTED = 7,
>> +/* = Driver data structures = */
>> +
>> +enum sba_request_flags {
>> + SBA_REQUEST_STATE_FREE  = 0x001,
>> + SBA_REQUEST_STATE_ALLOCED   = 0x002,
>> + SBA_REQUEST_STATE_PENDING   = 0x004,
>> + SBA_REQUEST_STATE_ACTIVE= 0x008,
>> + SBA_REQUEST_STATE_RECEIVED  = 0x010,
>> + SBA_REQUEST_STATE_COMPLETED = 0x020,
>> + SBA_REQUEST_STATE_ABORTED   = 0x040,
>> + SBA_REQUEST_STATE_MASK  = 0x0ff,
>> + SBA_REQUEST_FENCE   = 0x100,
>
> how does this help in mem alloctn?
>
>>  };
>>
>>  struct sba_request {
>>   /* Global state */
>>   struct list_head node;
>>   struct sba_device *sba;
>> - enum sba_request_state state;
>> - bool fence;
>> + u32 flags;
>>   /* Chained requests management */
>>   struct sba_request *first;
>>   struct list_head next;
>> - unsigned int next_count;
>>   atomic_t next_pending_count;
>>   /* BRCM message data */
>> - void *resp;
>> - dma_addr_t resp_dma;
>> - struct brcm_sba_command *cmds;
>>   struct brcm_message msg;
>>   struct dma_async_tx_descriptor tx;
>> + /* SBA commands */
>> + struct brcm_sba_command cmds[0];
>>  };
>>
>>  enum sba_version {
>> @@ -128,11 +131,11 @@ struct sba_device {
>>   /* DT configuration parameters */
>>   enum sba_version ver;
>>   /* Derived configuration parameters */
>> - u32 max_req;
>>   u32 hw_buf_size;
>>   u32 hw_resp_size;
>>   u32 max_pq_coefs;
>>   u32 max_pq_srcs;
>> + u32 max_req;
>>   u32 max_cmd_per_req;
>>   u32 max_xor_srcs;
>>   u32 max_resp_pool_size;
>> @@ -152,7 +155,6 @@ struct sba_device {
>>   void *cmds_base;
>>   dma_addr_t cmds_dma_base;
>>   spinlock_t reqs_lock;
>> - struct sba_request *reqs;
>>   bool reqs_fence;
>>   struct list_head reqs_alloc_list;
>>   struct list_head reqs_pending_list;
>> @@ -161,10 +163,9 @@ struct sba_device {
>>   struct list_head reqs_completed_list;
>>   struct list_head reqs_aborted_list;
>>   struct list_head reqs_free_list;
>> - int reqs_free_count;
>>  };
>>
>> -/* == SBA command helper routines = */
>> +/* == Command helper routines = */
>
> more noise..
>
>>
>>  static inline u64 __pure sba_cmd_enc(u64 cmd, u32 val, u32 shift, u32 mask)
>>  {
>> @@ -196,7 +197,7 @@ static inline u32 __pure sba_cmd_pq_c_mdata(u32 d, u32 
>> b1, u32 b0)
>>  ((d & SBA_C_MDATA_DNUM_MASK) << SBA_C_MDATA_DNUM_SHIFT);
>>  }
>>
>> -/* == Channel resource management routines = */
>> +/* == General helper routines = */

Re: [PATCH 0/6] Broadcom SBA-RAID driver improvements

[Anup Patel]

On Wed, Jul 26, 2017 at 10:33 PM, Vinod Koul  wrote:
> On Wed, Jul 26, 2017 at 11:06:38AM +0530, Anup Patel wrote:
>> This patchset does various improvments to Broadcom SBA-RAID
>> driver and also adds SBA-RAID DT nodes for Stingray SOC.
>>
>> The patches are based on "[PATCH v2 0/7] FlexRM driver improvements"
>> and can also be found at sba-raid-imp-v1 branch of
>> https://github.com/Broadcom/arm64-linux.git
>
> and i cant apply this series without these?

The dependency is only because of last DT patch for stingray.

We are going to separate patchset for Stingray DT changes
so I will drop PATCH6 and have this part of Stingray DT patchset.

>
>>
>> Anup Patel (6):
>>   dma: bcm-sba-raid: Improve memory allocation in SBA RAID driver
>>   dma: bcm-sba-raid: Peek mbox when we are left with no free requests
>>   dma: bcm-sba-raid: pre-ack async tx descriptor
>>   dma: bcm-sba-raid: Break sba_process_deferred_requests() into two
>> parts
>>   dma: bcm-sba-raid: Add debugfs support
>
> why are these tagged dma, I have told you explcitly to fix this!!

Sure, I will remove "dma:" tag in next revision.

Regards,
Anup

Re: [PATCH 0/6] Broadcom SBA-RAID driver improvements

[Anup Patel]

On Wed, Jul 26, 2017 at 10:33 PM, Vinod Koul  wrote:
> On Wed, Jul 26, 2017 at 11:06:38AM +0530, Anup Patel wrote:
>> This patchset does various improvments to Broadcom SBA-RAID
>> driver and also adds SBA-RAID DT nodes for Stingray SOC.
>>
>> The patches are based on "[PATCH v2 0/7] FlexRM driver improvements"
>> and can also be found at sba-raid-imp-v1 branch of
>> https://github.com/Broadcom/arm64-linux.git
>
> and i cant apply this series without these?

The dependency is only because of last DT patch for stingray.

We are going to separate patchset for Stingray DT changes
so I will drop PATCH6 and have this part of Stingray DT patchset.

>
>>
>> Anup Patel (6):
>>   dma: bcm-sba-raid: Improve memory allocation in SBA RAID driver
>>   dma: bcm-sba-raid: Peek mbox when we are left with no free requests
>>   dma: bcm-sba-raid: pre-ack async tx descriptor
>>   dma: bcm-sba-raid: Break sba_process_deferred_requests() into two
>> parts
>>   dma: bcm-sba-raid: Add debugfs support
>
> why are these tagged dma, I have told you explcitly to fix this!!

Sure, I will remove "dma:" tag in next revision.

Regards,
Anup

Re: [PATCH v2 6/7] mailbox: bcm-flexrm-mailbox: Set msg_queue_len for each channel

[Anup Patel]

On Tue, Jul 25, 2017 at 9:37 PM, Jassi Brar  wrote:
> On Tue, Jul 25, 2017 at 11:11 AM, Anup Patel  wrote:
>> On Mon, Jul 24, 2017 at 10:06 PM, Jassi Brar  
>> wrote:
>>> On Mon, Jul 24, 2017 at 9:26 AM, Anup Patel  wrote:
 Hi Jassi,

 Sorry for the delayed response...

 On Fri, Jul 21, 2017 at 9:16 PM, Jassi Brar  
 wrote:
> Hi Anup,
>
> On Fri, Jul 21, 2017 at 12:25 PM, Anup Patel  
> wrote:
>> The Broadcom FlexRM ring (i.e. mailbox channel) can handle
>> larger number of messages queued in one FlexRM ring hence
>> this patch sets msg_queue_len for each mailbox channel to
>> be same as RING_MAX_REQ_COUNT.
>>
>> Signed-off-by: Anup Patel 
>> Reviewed-by: Scott Branden 
>> ---
>>  drivers/mailbox/bcm-flexrm-mailbox.c | 5 -
>>  1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/mailbox/bcm-flexrm-mailbox.c 
>> b/drivers/mailbox/bcm-flexrm-mailbox.c
>> index 9873818..20055a0 100644
>> --- a/drivers/mailbox/bcm-flexrm-mailbox.c
>> +++ b/drivers/mailbox/bcm-flexrm-mailbox.c
>> @@ -1683,8 +1683,11 @@ static int flexrm_mbox_probe(struct 
>> platform_device *pdev)
>> ret = -ENOMEM;
>> goto fail_free_debugfs_root;
>> }
>> -   for (index = 0; index < mbox->num_rings; index++)
>> +   for (index = 0; index < mbox->num_rings; index++) {
>> +   mbox->controller.chans[index].msg_queue_len =
>> +   RING_MAX_REQ_COUNT;
>> mbox->controller.chans[index].con_priv = 
>> >rings[index];
>> +   }
>>
> While writing mailbox.c I wasn't unaware that there is the option to
> choose the queue length at runtime.
> The idea was to keep the code as simple as possible. I am open to
> making it a runtime thing, but first, please help me understand how
> that is useful here.
>
> I understand FlexRm has a ring buffer of RING_MAX_REQ_COUNT(1024)
> elements. Any message submitted to mailbox api can be immediately
> written onto the ringbuffer if there is some space.
> Is there any mechanism to report back to a client driver, if its
> message in ringbuffer failed "to be sent"?
> If there isn't any, then I think, in flexrm_last_tx_done() you should
> simply return true if there is some space left in the rung-buffer,
> false otherwise.

 Yes, we have error code in "struct brcm_message" to report back
 errors from send_message. In our mailbox clients, we check
 return value of mbox_send_message() and also the error code
 in "struct brcm_message".

>>> I meant after the message has been accepted in the ringbuffer but the
>>> remote failed to receive it.
>>
>> Yes, even this case is handled.
>>
>> In case of IO errors after message has been put in ring buffer, we get
>> completion message with error code and mailbox client drivers will
>> receive back "struct brcm_message" with error set.
>>
>> You can refer flexrm_process_completions() for more details.
>>
>>> There seems no such provision. IIANW, then you should be able to
>>> consider every message as "sent successfully" once it is in the ring
>>> buffer i.e, immediately after mbox_send_message() returns 0.
>>> In that case I would think you don't need more than a couple of
>>> entries out of MBOX_TX_QUEUE_LEN ?
>>
>> What I am trying to suggest is that we can take upto 1024 messages
>> in a FlexRM ring but the MBOX_TX_QUEUE_LEN limits us queuing
>> more messages. This issue manifest easily when multiple CPUs
>> queues to same FlexRM ring (i.e. same mailbox channel).
>>
> OK then, I guess we have to make the queue length a runtime decision.

Do you agree with approach taken by PATCH5 and PATCH6 to
make queue length runtime?

>
> BTW, is it a practical use case that needs to queue upto 1024
> requests? Or are you just testing?

Yes, we just need bigger queue length for FlexRM but we
choose 1024 (max limit) to avoid changing it again in future.

Regards,
Anup

Re: [PATCH v2 6/7] mailbox: bcm-flexrm-mailbox: Set msg_queue_len for each channel

[Anup Patel]

On Tue, Jul 25, 2017 at 9:37 PM, Jassi Brar  wrote:
> On Tue, Jul 25, 2017 at 11:11 AM, Anup Patel  wrote:
>> On Mon, Jul 24, 2017 at 10:06 PM, Jassi Brar  
>> wrote:
>>> On Mon, Jul 24, 2017 at 9:26 AM, Anup Patel  wrote:
 Hi Jassi,

 Sorry for the delayed response...

 On Fri, Jul 21, 2017 at 9:16 PM, Jassi Brar  
 wrote:
> Hi Anup,
>
> On Fri, Jul 21, 2017 at 12:25 PM, Anup Patel  
> wrote:
>> The Broadcom FlexRM ring (i.e. mailbox channel) can handle
>> larger number of messages queued in one FlexRM ring hence
>> this patch sets msg_queue_len for each mailbox channel to
>> be same as RING_MAX_REQ_COUNT.
>>
>> Signed-off-by: Anup Patel 
>> Reviewed-by: Scott Branden 
>> ---
>>  drivers/mailbox/bcm-flexrm-mailbox.c | 5 -
>>  1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/mailbox/bcm-flexrm-mailbox.c 
>> b/drivers/mailbox/bcm-flexrm-mailbox.c
>> index 9873818..20055a0 100644
>> --- a/drivers/mailbox/bcm-flexrm-mailbox.c
>> +++ b/drivers/mailbox/bcm-flexrm-mailbox.c
>> @@ -1683,8 +1683,11 @@ static int flexrm_mbox_probe(struct 
>> platform_device *pdev)
>> ret = -ENOMEM;
>> goto fail_free_debugfs_root;
>> }
>> -   for (index = 0; index < mbox->num_rings; index++)
>> +   for (index = 0; index < mbox->num_rings; index++) {
>> +   mbox->controller.chans[index].msg_queue_len =
>> +   RING_MAX_REQ_COUNT;
>> mbox->controller.chans[index].con_priv = 
>> >rings[index];
>> +   }
>>
> While writing mailbox.c I wasn't unaware that there is the option to
> choose the queue length at runtime.
> The idea was to keep the code as simple as possible. I am open to
> making it a runtime thing, but first, please help me understand how
> that is useful here.
>
> I understand FlexRm has a ring buffer of RING_MAX_REQ_COUNT(1024)
> elements. Any message submitted to mailbox api can be immediately
> written onto the ringbuffer if there is some space.
> Is there any mechanism to report back to a client driver, if its
> message in ringbuffer failed "to be sent"?
> If there isn't any, then I think, in flexrm_last_tx_done() you should
> simply return true if there is some space left in the rung-buffer,
> false otherwise.

 Yes, we have error code in "struct brcm_message" to report back
 errors from send_message. In our mailbox clients, we check
 return value of mbox_send_message() and also the error code
 in "struct brcm_message".

>>> I meant after the message has been accepted in the ringbuffer but the
>>> remote failed to receive it.
>>
>> Yes, even this case is handled.
>>
>> In case of IO errors after message has been put in ring buffer, we get
>> completion message with error code and mailbox client drivers will
>> receive back "struct brcm_message" with error set.
>>
>> You can refer flexrm_process_completions() for more details.
>>
>>> There seems no such provision. IIANW, then you should be able to
>>> consider every message as "sent successfully" once it is in the ring
>>> buffer i.e, immediately after mbox_send_message() returns 0.
>>> In that case I would think you don't need more than a couple of
>>> entries out of MBOX_TX_QUEUE_LEN ?
>>
>> What I am trying to suggest is that we can take upto 1024 messages
>> in a FlexRM ring but the MBOX_TX_QUEUE_LEN limits us queuing
>> more messages. This issue manifest easily when multiple CPUs
>> queues to same FlexRM ring (i.e. same mailbox channel).
>>
> OK then, I guess we have to make the queue length a runtime decision.

Do you agree with approach taken by PATCH5 and PATCH6 to
make queue length runtime?

>
> BTW, is it a practical use case that needs to queue upto 1024
> requests? Or are you just testing?

Yes, we just need bigger queue length for FlexRM but we
choose 1024 (max limit) to avoid changing it again in future.

Regards,
Anup

[PATCH v2 0/3] Initial Allwinner V3s CSI Support

[Yong Deng]

This patchset add initial support for Allwinner V3s CSI.

Allwinner V3s SoC have two CSI module. CSI0 is used for MIPI interface
and CSI1 is used for parallel interface. This is not documented in
datasheet but by testing and guess.

This patchset implement a v4l2 framework driver and add a binding 
documentation for it. 

Currently, the driver only support the parallel interface. And has been
tested with a BT1120 signal which generating from FPGA. The following
fetures are not support with this patchset:
  - ISP 
  - MIPI-CSI2
  - Master clock for camera sensor
  - Power regulator for the front end IC

sun6i_csi_ops is still there. I seriously thought about it. Without 
sun6i_csi_ops, the dependency between sun6i_video and sun6i_csi_v3s
will be complicated. Comments and criticisms are welcome.

Changes in v2:
  * Change sunxi-csi to sun6i-csi
  * Rebase to media_tree master branch

Yong Deng (3):
  media: V3s: Add support for Allwinner CSI.
  dt-bindings: media: Add Allwinner V3s Camera Sensor Interface (CSI)
  media: MAINTAINERS: add entries for Allwinner V3s CSI

 .../devicetree/bindings/media/sun6i-csi.txt|  49 ++
 MAINTAINERS|   8 +
 drivers/media/platform/Kconfig |   1 +
 drivers/media/platform/Makefile|   2 +
 drivers/media/platform/sun6i-csi/Kconfig   |   9 +
 drivers/media/platform/sun6i-csi/Makefile  |   3 +
 drivers/media/platform/sun6i-csi/sun6i_csi.c   | 545 ++
 drivers/media/platform/sun6i-csi/sun6i_csi.h   | 203 +
 drivers/media/platform/sun6i-csi/sun6i_csi_v3s.c   | 827 +
 drivers/media/platform/sun6i-csi/sun6i_csi_v3s.h   | 206 +
 drivers/media/platform/sun6i-csi/sun6i_video.c | 663 +
 drivers/media/platform/sun6i-csi/sun6i_video.h |  61 ++
 12 files changed, 2577 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/sun6i-csi.txt
 create mode 100644 drivers/media/platform/sun6i-csi/Kconfig
 create mode 100644 drivers/media/platform/sun6i-csi/Makefile
 create mode 100644 drivers/media/platform/sun6i-csi/sun6i_csi.c
 create mode 100644 drivers/media/platform/sun6i-csi/sun6i_csi.h
 create mode 100644 drivers/media/platform/sun6i-csi/sun6i_csi_v3s.c
 create mode 100644 drivers/media/platform/sun6i-csi/sun6i_csi_v3s.h
 create mode 100644 drivers/media/platform/sun6i-csi/sun6i_video.c
 create mode 100644 drivers/media/platform/sun6i-csi/sun6i_video.h

-- 
1.8.3.1

[PATCH v2 0/3] Initial Allwinner V3s CSI Support

[Yong Deng]

This patchset add initial support for Allwinner V3s CSI.

Allwinner V3s SoC have two CSI module. CSI0 is used for MIPI interface
and CSI1 is used for parallel interface. This is not documented in
datasheet but by testing and guess.

This patchset implement a v4l2 framework driver and add a binding 
documentation for it. 

Currently, the driver only support the parallel interface. And has been
tested with a BT1120 signal which generating from FPGA. The following
fetures are not support with this patchset:
  - ISP 
  - MIPI-CSI2
  - Master clock for camera sensor
  - Power regulator for the front end IC

sun6i_csi_ops is still there. I seriously thought about it. Without 
sun6i_csi_ops, the dependency between sun6i_video and sun6i_csi_v3s
will be complicated. Comments and criticisms are welcome.

Changes in v2:
  * Change sunxi-csi to sun6i-csi
  * Rebase to media_tree master branch

Yong Deng (3):
  media: V3s: Add support for Allwinner CSI.
  dt-bindings: media: Add Allwinner V3s Camera Sensor Interface (CSI)
  media: MAINTAINERS: add entries for Allwinner V3s CSI

 .../devicetree/bindings/media/sun6i-csi.txt|  49 ++
 MAINTAINERS|   8 +
 drivers/media/platform/Kconfig |   1 +
 drivers/media/platform/Makefile|   2 +
 drivers/media/platform/sun6i-csi/Kconfig   |   9 +
 drivers/media/platform/sun6i-csi/Makefile  |   3 +
 drivers/media/platform/sun6i-csi/sun6i_csi.c   | 545 ++
 drivers/media/platform/sun6i-csi/sun6i_csi.h   | 203 +
 drivers/media/platform/sun6i-csi/sun6i_csi_v3s.c   | 827 +
 drivers/media/platform/sun6i-csi/sun6i_csi_v3s.h   | 206 +
 drivers/media/platform/sun6i-csi/sun6i_video.c | 663 +
 drivers/media/platform/sun6i-csi/sun6i_video.h |  61 ++
 12 files changed, 2577 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/sun6i-csi.txt
 create mode 100644 drivers/media/platform/sun6i-csi/Kconfig
 create mode 100644 drivers/media/platform/sun6i-csi/Makefile
 create mode 100644 drivers/media/platform/sun6i-csi/sun6i_csi.c
 create mode 100644 drivers/media/platform/sun6i-csi/sun6i_csi.h
 create mode 100644 drivers/media/platform/sun6i-csi/sun6i_csi_v3s.c
 create mode 100644 drivers/media/platform/sun6i-csi/sun6i_csi_v3s.h
 create mode 100644 drivers/media/platform/sun6i-csi/sun6i_video.c
 create mode 100644 drivers/media/platform/sun6i-csi/sun6i_video.h

-- 
1.8.3.1

[PATCH v2 2/3] dt-bindings: media: Add Allwinner V3s Camera Sensor Interface (CSI)

[Yong Deng]

Add binding documentation for Allwinner V3s CSI.

Signed-off-by: Yong Deng 
---
 .../devicetree/bindings/media/sun6i-csi.txt| 49 ++
 1 file changed, 49 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/sun6i-csi.txt

diff --git a/Documentation/devicetree/bindings/media/sun6i-csi.txt 
b/Documentation/devicetree/bindings/media/sun6i-csi.txt
new file mode 100644
index 000..f8d83f6
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/sun6i-csi.txt
@@ -0,0 +1,49 @@
+Allwinner V3s Camera Sensor Interface
+--
+
+Required properties:
+  - compatible: value must be "allwinner,sun8i-v3s-csi"
+  - reg: base address and size of the memory-mapped region.
+  - interrupts: interrupt associated to this IP
+  - clocks: phandles to the clocks feeding the CSI
+* ahb: the CSI interface clock
+* mod: the CSI module clock
+* ram: the CSI DRAM clock
+  - clock-names: the clock names mentioned above
+  - resets: phandles to the reset line driving the CSI
+
+- ports: A ports node with endpoint definitions as defined in
+  Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Example:
+
+   csi1: csi@01cb4000 {
+   compatible = "allwinner,sun8i-v3s-csi";
+   reg = <0x01cb4000 0x1000>;
+   interrupts = ;
+   clocks = < CLK_BUS_CSI>,
+< CLK_CSI1_SCLK>,
+< CLK_DRAM_CSI>;
+   clock-names = "ahb", "mod", "ram";
+   resets = < RST_BUS_CSI>;
+
+   port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   /* Parallel bus endpoint */
+   csi1_ep: endpoint {
+   remote-endpoint = <_ep>;
+   bus-width = <16>;
+   data-shift = <0>;
+
+   /* If hsync-active/vsync-active are missing,
+  embedded BT.656 sync is used */
+   hsync-active = <0>; /* Active low */
+   vsync-active = <0>; /* Active low */
+   data-active = <1>;  /* Active high */
+   pclk-sample = <1>;  /* Rising */
+   };
+   };
+   };
+
-- 
1.8.3.1

[PATCH v2 2/3] dt-bindings: media: Add Allwinner V3s Camera Sensor Interface (CSI)

[Yong Deng]

Add binding documentation for Allwinner V3s CSI.

Signed-off-by: Yong Deng 
---
 .../devicetree/bindings/media/sun6i-csi.txt| 49 ++
 1 file changed, 49 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/sun6i-csi.txt

diff --git a/Documentation/devicetree/bindings/media/sun6i-csi.txt 
b/Documentation/devicetree/bindings/media/sun6i-csi.txt
new file mode 100644
index 000..f8d83f6
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/sun6i-csi.txt
@@ -0,0 +1,49 @@
+Allwinner V3s Camera Sensor Interface
+--
+
+Required properties:
+  - compatible: value must be "allwinner,sun8i-v3s-csi"
+  - reg: base address and size of the memory-mapped region.
+  - interrupts: interrupt associated to this IP
+  - clocks: phandles to the clocks feeding the CSI
+* ahb: the CSI interface clock
+* mod: the CSI module clock
+* ram: the CSI DRAM clock
+  - clock-names: the clock names mentioned above
+  - resets: phandles to the reset line driving the CSI
+
+- ports: A ports node with endpoint definitions as defined in
+  Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Example:
+
+   csi1: csi@01cb4000 {
+   compatible = "allwinner,sun8i-v3s-csi";
+   reg = <0x01cb4000 0x1000>;
+   interrupts = ;
+   clocks = < CLK_BUS_CSI>,
+< CLK_CSI1_SCLK>,
+< CLK_DRAM_CSI>;
+   clock-names = "ahb", "mod", "ram";
+   resets = < RST_BUS_CSI>;
+
+   port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   /* Parallel bus endpoint */
+   csi1_ep: endpoint {
+   remote-endpoint = <_ep>;
+   bus-width = <16>;
+   data-shift = <0>;
+
+   /* If hsync-active/vsync-active are missing,
+  embedded BT.656 sync is used */
+   hsync-active = <0>; /* Active low */
+   vsync-active = <0>; /* Active low */
+   data-active = <1>;  /* Active high */
+   pclk-sample = <1>;  /* Rising */
+   };
+   };
+   };
+
-- 
1.8.3.1

[PATCH v2 1/3] media: V3s: Add support for Allwinner CSI.

[Yong Deng]

Allwinner V3s SoC have two CSI module. CSI0 is used for MIPI interface
and CSI1 is used for parallel interface. This is not documented in
datasheet but by testing and guess.

This patch implement a v4l2 framework driver for it.

Currently, the driver only support the parallel interface. MIPI-CSI2,
ISP's support are not included in this patch.

Signed-off-by: Yong Deng 
---
 drivers/media/platform/Kconfig   |   1 +
 drivers/media/platform/Makefile  |   2 +
 drivers/media/platform/sun6i-csi/Kconfig |   9 +
 drivers/media/platform/sun6i-csi/Makefile|   3 +
 drivers/media/platform/sun6i-csi/sun6i_csi.c | 545 +++
 drivers/media/platform/sun6i-csi/sun6i_csi.h | 203 ++
 drivers/media/platform/sun6i-csi/sun6i_csi_v3s.c | 827 +++
 drivers/media/platform/sun6i-csi/sun6i_csi_v3s.h | 206 ++
 drivers/media/platform/sun6i-csi/sun6i_video.c   | 663 ++
 drivers/media/platform/sun6i-csi/sun6i_video.h   |  61 ++
 10 files changed, 2520 insertions(+)
 create mode 100644 drivers/media/platform/sun6i-csi/Kconfig
 create mode 100644 drivers/media/platform/sun6i-csi/Makefile
 create mode 100644 drivers/media/platform/sun6i-csi/sun6i_csi.c
 create mode 100644 drivers/media/platform/sun6i-csi/sun6i_csi.h
 create mode 100644 drivers/media/platform/sun6i-csi/sun6i_csi_v3s.c
 create mode 100644 drivers/media/platform/sun6i-csi/sun6i_csi_v3s.h
 create mode 100644 drivers/media/platform/sun6i-csi/sun6i_video.c
 create mode 100644 drivers/media/platform/sun6i-csi/sun6i_video.h

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 0c741d1..8371a87 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -143,6 +143,7 @@ source "drivers/media/platform/am437x/Kconfig"
 source "drivers/media/platform/xilinx/Kconfig"
 source "drivers/media/platform/rcar-vin/Kconfig"
 source "drivers/media/platform/atmel/Kconfig"
+source "drivers/media/platform/sun6i-csi/Kconfig"
 
 config VIDEO_TI_CAL
tristate "TI CAL (Camera Adaptation Layer) driver"
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 9beadc7..fb2459c 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -86,3 +86,5 @@ obj-$(CONFIG_VIDEO_MEDIATEK_MDP)  += mtk-mdp/
 obj-$(CONFIG_VIDEO_MEDIATEK_JPEG)  += mtk-jpeg/
 
 obj-$(CONFIG_VIDEO_QCOM_VENUS) += qcom/venus/
+
+obj-$(CONFIG_VIDEO_SUN6I_CSI)  += sun6i-csi/
diff --git a/drivers/media/platform/sun6i-csi/Kconfig 
b/drivers/media/platform/sun6i-csi/Kconfig
new file mode 100644
index 000..314188a
--- /dev/null
+++ b/drivers/media/platform/sun6i-csi/Kconfig
@@ -0,0 +1,9 @@
+config VIDEO_SUN6I_CSI
+   tristate "Allwinner V3s Camera Sensor Interface driver"
+   depends on VIDEO_V4L2 && COMMON_CLK && VIDEO_V4L2_SUBDEV_API && HAS_DMA
+   depends on ARCH_SUNXI || COMPILE_TEST
+   select VIDEOBUF2_DMA_CONTIG
+   select REGMAP_MMIO
+   select V4L2_FWNODE
+   ---help---
+  Support for the Allwinner Camera Sensor Interface Controller on V3s.
diff --git a/drivers/media/platform/sun6i-csi/Makefile 
b/drivers/media/platform/sun6i-csi/Makefile
new file mode 100644
index 000..a9b527b
--- /dev/null
+++ b/drivers/media/platform/sun6i-csi/Makefile
@@ -0,0 +1,3 @@
+sun6i-csi-y += sun6i_csi.o sun6i_video.o sun6i_csi_v3s.o
+
+obj-$(CONFIG_VIDEO_SUN6I_CSI) += sun6i-csi.o
diff --git a/drivers/media/platform/sun6i-csi/sun6i_csi.c 
b/drivers/media/platform/sun6i-csi/sun6i_csi.c
new file mode 100644
index 000..7a4bf53
--- /dev/null
+++ b/drivers/media/platform/sun6i-csi/sun6i_csi.c
@@ -0,0 +1,545 @@
+/*
+ * Copyright (c) 2017 Magewell Electronics Co., Ltd. (Nanjing),
+ * All rights reserved.
+ * Author: Yong Deng 
+ *
+ * Based on drivers/media/platform/xilinx/xilinx-vipp.c
+ * Copyright (C) 2013-2015 Ideas on Board
+ * Copyright (C) 2013-2015 Xilinx, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "sun6i_csi.h"
+
+/*
+ * struct sun6i_graph_entity - Entity in the video graph
+ * @list: list entry in a graph entities list
+ * @node: the entity's DT node
+ * @entity: media entity, from the corresponding V4L2 subdev
+ * @asd: subdev asynchronous registration information
+ * @subdev: V4L2 subdev
+ */
+struct sun6i_graph_entity {
+   struct list_headlist;
+   struct device_node  *node;
+   struct media_entity  

[PATCH v2 1/3] media: V3s: Add support for Allwinner CSI.

[Yong Deng]

Allwinner V3s SoC have two CSI module. CSI0 is used for MIPI interface
and CSI1 is used for parallel interface. This is not documented in
datasheet but by testing and guess.

This patch implement a v4l2 framework driver for it.

Currently, the driver only support the parallel interface. MIPI-CSI2,
ISP's support are not included in this patch.

Signed-off-by: Yong Deng 
---
 drivers/media/platform/Kconfig   |   1 +
 drivers/media/platform/Makefile  |   2 +
 drivers/media/platform/sun6i-csi/Kconfig |   9 +
 drivers/media/platform/sun6i-csi/Makefile|   3 +
 drivers/media/platform/sun6i-csi/sun6i_csi.c | 545 +++
 drivers/media/platform/sun6i-csi/sun6i_csi.h | 203 ++
 drivers/media/platform/sun6i-csi/sun6i_csi_v3s.c | 827 +++
 drivers/media/platform/sun6i-csi/sun6i_csi_v3s.h | 206 ++
 drivers/media/platform/sun6i-csi/sun6i_video.c   | 663 ++
 drivers/media/platform/sun6i-csi/sun6i_video.h   |  61 ++
 10 files changed, 2520 insertions(+)
 create mode 100644 drivers/media/platform/sun6i-csi/Kconfig
 create mode 100644 drivers/media/platform/sun6i-csi/Makefile
 create mode 100644 drivers/media/platform/sun6i-csi/sun6i_csi.c
 create mode 100644 drivers/media/platform/sun6i-csi/sun6i_csi.h
 create mode 100644 drivers/media/platform/sun6i-csi/sun6i_csi_v3s.c
 create mode 100644 drivers/media/platform/sun6i-csi/sun6i_csi_v3s.h
 create mode 100644 drivers/media/platform/sun6i-csi/sun6i_video.c
 create mode 100644 drivers/media/platform/sun6i-csi/sun6i_video.h

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 0c741d1..8371a87 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -143,6 +143,7 @@ source "drivers/media/platform/am437x/Kconfig"
 source "drivers/media/platform/xilinx/Kconfig"
 source "drivers/media/platform/rcar-vin/Kconfig"
 source "drivers/media/platform/atmel/Kconfig"
+source "drivers/media/platform/sun6i-csi/Kconfig"
 
 config VIDEO_TI_CAL
tristate "TI CAL (Camera Adaptation Layer) driver"
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 9beadc7..fb2459c 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -86,3 +86,5 @@ obj-$(CONFIG_VIDEO_MEDIATEK_MDP)  += mtk-mdp/
 obj-$(CONFIG_VIDEO_MEDIATEK_JPEG)  += mtk-jpeg/
 
 obj-$(CONFIG_VIDEO_QCOM_VENUS) += qcom/venus/
+
+obj-$(CONFIG_VIDEO_SUN6I_CSI)  += sun6i-csi/
diff --git a/drivers/media/platform/sun6i-csi/Kconfig 
b/drivers/media/platform/sun6i-csi/Kconfig
new file mode 100644
index 000..314188a
--- /dev/null
+++ b/drivers/media/platform/sun6i-csi/Kconfig
@@ -0,0 +1,9 @@
+config VIDEO_SUN6I_CSI
+   tristate "Allwinner V3s Camera Sensor Interface driver"
+   depends on VIDEO_V4L2 && COMMON_CLK && VIDEO_V4L2_SUBDEV_API && HAS_DMA
+   depends on ARCH_SUNXI || COMPILE_TEST
+   select VIDEOBUF2_DMA_CONTIG
+   select REGMAP_MMIO
+   select V4L2_FWNODE
+   ---help---
+  Support for the Allwinner Camera Sensor Interface Controller on V3s.
diff --git a/drivers/media/platform/sun6i-csi/Makefile 
b/drivers/media/platform/sun6i-csi/Makefile
new file mode 100644
index 000..a9b527b
--- /dev/null
+++ b/drivers/media/platform/sun6i-csi/Makefile
@@ -0,0 +1,3 @@
+sun6i-csi-y += sun6i_csi.o sun6i_video.o sun6i_csi_v3s.o
+
+obj-$(CONFIG_VIDEO_SUN6I_CSI) += sun6i-csi.o
diff --git a/drivers/media/platform/sun6i-csi/sun6i_csi.c 
b/drivers/media/platform/sun6i-csi/sun6i_csi.c
new file mode 100644
index 000..7a4bf53
--- /dev/null
+++ b/drivers/media/platform/sun6i-csi/sun6i_csi.c
@@ -0,0 +1,545 @@
+/*
+ * Copyright (c) 2017 Magewell Electronics Co., Ltd. (Nanjing),
+ * All rights reserved.
+ * Author: Yong Deng 
+ *
+ * Based on drivers/media/platform/xilinx/xilinx-vipp.c
+ * Copyright (C) 2013-2015 Ideas on Board
+ * Copyright (C) 2013-2015 Xilinx, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "sun6i_csi.h"
+
+/*
+ * struct sun6i_graph_entity - Entity in the video graph
+ * @list: list entry in a graph entities list
+ * @node: the entity's DT node
+ * @entity: media entity, from the corresponding V4L2 subdev
+ * @asd: subdev asynchronous registration information
+ * @subdev: V4L2 subdev
+ */
+struct sun6i_graph_entity {
+   struct list_headlist;
+   struct device_node  *node;
+   struct media_entity *entity;
+
+   struct 

Re: [PATCH] cpufreq: intel_pstate: Drop ->get from intel_pstate structure

[Viresh Kumar]

On 26-07-17, 00:42, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki 
> 
> The ->get callback in the intel_pstate structure was mostly there
> for the scaling_cur_freq sysfs attribute to work, but after commit
> f8475cef9008 (x86: use common aperfmperf_khz_on_cpu() to calculate
> KHz using APERF/MPERF) that attribute uses arch_freq_get_on_cpu()
> provided by the x86 arch code on all processors supported by
> intel_pstate, so it doesn't need the ->get callback from the
> driver any more.
> 
> Moreover, the very presence of the ->get callback in the intel_pstate
> structure causes the cpuinfo_cur_freq attribute to be present when
> intel_pstate operates in the active mode, which is bogus, because
> the role of that attribute is to return the current CPU frequency
> as seen by the hardware.  For intel_pstate, though, this is just an
> average frequency and not really current, but computed for the
> previous sampling interval (the actual current frequency may be
> way different at the point this value is obtained by reading from
> cpuinfo_cur_freq), and after commit 82b4e03e01bc (intel_pstate: skip
> scheduler hook when in "performance" mode) the value in
> cpuinfo_cur_freq may be stale or just 0, depending on the driver's
> operation mode.  In fact, however, on the hardware supported by
> intel_pstate there is no way to read the current CPU frequency
> from it, so the cpuinfo_cur_freq attribute should not be present
> at all when this driver is in use.
> 
> For this reason, drop intel_pstate_get() and clear the ->get
> callback pointer pointing to it, so that the cpuinfo_cur_freq is
> not present for intel_pstate in the active mode any more.
> 
> Fixes: 82b4e03e01bc (intel_pstate: skip scheduler hook when in "performance" 
> mode)
> Reported-by: Huaisheng Ye 
> Signed-off-by: Rafael J. Wysocki 
> ---
>  drivers/cpufreq/intel_pstate.c |8 
>  1 file changed, 8 deletions(-)
> 
> Index: linux-pm/drivers/cpufreq/intel_pstate.c
> ===
> --- linux-pm.orig/drivers/cpufreq/intel_pstate.c
> +++ linux-pm/drivers/cpufreq/intel_pstate.c
> @@ -1674,13 +1674,6 @@ static int intel_pstate_init_cpu(unsigne
>   return 0;
>  }
>  
> -static unsigned int intel_pstate_get(unsigned int cpu_num)
> -{
> - struct cpudata *cpu = all_cpu_data[cpu_num];
> -
> - return cpu ? get_avg_frequency(cpu) : 0;
> -}
> -
>  static void intel_pstate_set_update_util_hook(unsigned int cpu_num)
>  {
>   struct cpudata *cpu = all_cpu_data[cpu_num];
> @@ -1921,7 +1914,6 @@ static struct cpufreq_driver intel_pstat
>   .setpolicy  = intel_pstate_set_policy,
>   .suspend= intel_pstate_hwp_save_state,
>   .resume = intel_pstate_resume,
> - .get= intel_pstate_get,
>   .init   = intel_pstate_cpu_init,
>   .exit   = intel_pstate_cpu_exit,
>   .stop_cpu   = intel_pstate_stop_cpu,

Acked-by: Viresh Kumar 

-- 
viresh

Re: [PATCH] cpufreq: intel_pstate: Drop ->get from intel_pstate structure

[Viresh Kumar]

On 26-07-17, 00:42, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki 
> 
> The ->get callback in the intel_pstate structure was mostly there
> for the scaling_cur_freq sysfs attribute to work, but after commit
> f8475cef9008 (x86: use common aperfmperf_khz_on_cpu() to calculate
> KHz using APERF/MPERF) that attribute uses arch_freq_get_on_cpu()
> provided by the x86 arch code on all processors supported by
> intel_pstate, so it doesn't need the ->get callback from the
> driver any more.
> 
> Moreover, the very presence of the ->get callback in the intel_pstate
> structure causes the cpuinfo_cur_freq attribute to be present when
> intel_pstate operates in the active mode, which is bogus, because
> the role of that attribute is to return the current CPU frequency
> as seen by the hardware.  For intel_pstate, though, this is just an
> average frequency and not really current, but computed for the
> previous sampling interval (the actual current frequency may be
> way different at the point this value is obtained by reading from
> cpuinfo_cur_freq), and after commit 82b4e03e01bc (intel_pstate: skip
> scheduler hook when in "performance" mode) the value in
> cpuinfo_cur_freq may be stale or just 0, depending on the driver's
> operation mode.  In fact, however, on the hardware supported by
> intel_pstate there is no way to read the current CPU frequency
> from it, so the cpuinfo_cur_freq attribute should not be present
> at all when this driver is in use.
> 
> For this reason, drop intel_pstate_get() and clear the ->get
> callback pointer pointing to it, so that the cpuinfo_cur_freq is
> not present for intel_pstate in the active mode any more.
> 
> Fixes: 82b4e03e01bc (intel_pstate: skip scheduler hook when in "performance" 
> mode)
> Reported-by: Huaisheng Ye 
> Signed-off-by: Rafael J. Wysocki 
> ---
>  drivers/cpufreq/intel_pstate.c |8 
>  1 file changed, 8 deletions(-)
> 
> Index: linux-pm/drivers/cpufreq/intel_pstate.c
> ===
> --- linux-pm.orig/drivers/cpufreq/intel_pstate.c
> +++ linux-pm/drivers/cpufreq/intel_pstate.c
> @@ -1674,13 +1674,6 @@ static int intel_pstate_init_cpu(unsigne
>   return 0;
>  }
>  
> -static unsigned int intel_pstate_get(unsigned int cpu_num)
> -{
> - struct cpudata *cpu = all_cpu_data[cpu_num];
> -
> - return cpu ? get_avg_frequency(cpu) : 0;
> -}
> -
>  static void intel_pstate_set_update_util_hook(unsigned int cpu_num)
>  {
>   struct cpudata *cpu = all_cpu_data[cpu_num];
> @@ -1921,7 +1914,6 @@ static struct cpufreq_driver intel_pstat
>   .setpolicy  = intel_pstate_set_policy,
>   .suspend= intel_pstate_hwp_save_state,
>   .resume = intel_pstate_resume,
> - .get= intel_pstate_get,
>   .init   = intel_pstate_cpu_init,
>   .exit   = intel_pstate_cpu_exit,
>   .stop_cpu   = intel_pstate_stop_cpu,

Acked-by: Viresh Kumar 

-- 
viresh

Re: [PATCH] cpufreq: docs: Add missing cpuinfo_cur_freq description

[Viresh Kumar]

On 27-07-17, 02:05, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki 
> 
> Add a description of the cpuinfo_cur_freq policy attribute in sysfs
> to the cpufreq documentation under Documentation/admin-guide/pm/ as
> it is missing after commit 2a0e49279850 (cpufreq: User/admin
> documentation update and consolidation) that overlooked it.
> 
> Fixes: 2a0e49279850 (cpufreq: User/admin documentation update and 
> consolidation)
> Signed-off-by: Rafael J. Wysocki 
> ---
>  Documentation/admin-guide/pm/cpufreq.rst |8 
>  1 file changed, 8 insertions(+)
> 
> Index: linux-pm/Documentation/admin-guide/pm/cpufreq.rst
> ===
> --- linux-pm.orig/Documentation/admin-guide/pm/cpufreq.rst
> +++ linux-pm/Documentation/admin-guide/pm/cpufreq.rst
> @@ -237,6 +237,14 @@ are the following:
>   This attribute is not present if the scaling driver in use does not
>   support it.
>  
> +``cpuinfo_cur_freq``
> + Current frequency of the CPUs belonging to this policy as obtained from
> + the hardware (in KHz).
> +
> + This is expected to be the frequency the hardware actually runs at.
> + If that frequency cannot be determined, this attribute should not
> + be present.
> +
>  ``cpuinfo_max_freq``
>   Maximum possible operating frequency the CPUs belonging to this policy
>   can run at (in kHz).

Acked-by: Viresh Kumar 

-- 
viresh

Re: [PATCH] cpufreq: docs: Add missing cpuinfo_cur_freq description

[Viresh Kumar]

On 27-07-17, 02:05, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki 
> 
> Add a description of the cpuinfo_cur_freq policy attribute in sysfs
> to the cpufreq documentation under Documentation/admin-guide/pm/ as
> it is missing after commit 2a0e49279850 (cpufreq: User/admin
> documentation update and consolidation) that overlooked it.
> 
> Fixes: 2a0e49279850 (cpufreq: User/admin documentation update and 
> consolidation)
> Signed-off-by: Rafael J. Wysocki 
> ---
>  Documentation/admin-guide/pm/cpufreq.rst |8 
>  1 file changed, 8 insertions(+)
> 
> Index: linux-pm/Documentation/admin-guide/pm/cpufreq.rst
> ===
> --- linux-pm.orig/Documentation/admin-guide/pm/cpufreq.rst
> +++ linux-pm/Documentation/admin-guide/pm/cpufreq.rst
> @@ -237,6 +237,14 @@ are the following:
>   This attribute is not present if the scaling driver in use does not
>   support it.
>  
> +``cpuinfo_cur_freq``
> + Current frequency of the CPUs belonging to this policy as obtained from
> + the hardware (in KHz).
> +
> + This is expected to be the frequency the hardware actually runs at.
> + If that frequency cannot be determined, this attribute should not
> + be present.
> +
>  ``cpuinfo_max_freq``
>   Maximum possible operating frequency the CPUs belonging to this policy
>   can run at (in kHz).

Acked-by: Viresh Kumar 

-- 
viresh

Re: [PATCH v2 5/5] dt-bindings: PCI: add support for new generation controller

[Honghui Zhang]

On Thu, 2017-07-27 at 10:58 +0800, honghui.zh...@mediatek.com wrote:
> From: Ryder Lee 
> 
> Add support for MediaTek new generation controller and update related
> properities.
> 
> Signed-off-by: Ryder Lee 
> Signed-off-by: Honghui Zhang 
> ---
>  .../devicetree/bindings/pci/mediatek-pcie.txt  | 168 
> -
>  1 file changed, 161 insertions(+), 7 deletions(-)
> 

Sorry for the disturb, I send the wrong patch from my local version for
this patch: 
[PATCH v2 5/5] dt-bindings: PCI: add support for new generation
 controller

And the new right version have been re-send.

thanks.

> diff --git a/Documentation/devicetree/bindings/pci/mediatek-pcie.txt 
> b/Documentation/devicetree/bindings/pci/mediatek-pcie.txt
> index a968f25..179329b 100644
> --- a/Documentation/devicetree/bindings/pci/mediatek-pcie.txt
> +++ b/Documentation/devicetree/bindings/pci/mediatek-pcie.txt
> @@ -3,18 +3,31 @@ MediaTek Gen2 PCIe controller
>  Required properties:
>  - compatible: Should contain one of the following string:
>   "mediatek,mt2701-pcie"
> + "mediatek,mt2712-pcie"
> + "mediatek,mt7622-pcie"
>   "mediatek,mt7623-pcie"
>  - device_type: Must be "pci"
> -- reg: Base addresses and lengths of the PCIe controller.
> +- reg: Base addresses and lengths of the PICe subsys and root ports.
> +- reg-names: Names of the above areas to use during resource look-up.
>  - #address-cells: Address representation for root ports (must be 3)
>  - #size-cells: Size representation for root ports (must be 2)
>  - clocks: Must contain an entry for each entry in clock-names.
>See ../clocks/clock-bindings.txt for details.
> -- clock-names: Must include the following entries:
> -  - free_ck :for reference clock of PCIe subsys
> -  - sys_ck0 :for clock of Port0
> -  - sys_ck1 :for clock of Port1
> -  - sys_ck2 :for clock of Port2
> +- clock-names:
> +  Mandatory entries:
> +   - sys_ckN :transaction layer and data link layer clock
> +  Required entries for MT2701/MT7623:
> +   - free_ck :for reference clock of PCIe subsys
> +  Required entries for MT2712/MT7622:
> +   - ahb_ckN :AHB slave interface operating clock for CSR access and RC
> +   initiated MMIO access
> +  Required entries for MT7622:
> +   - axi_ckN :application layer MMIO channel operating clock
> +   - aux_ckN :pe2_mac_bridge and pe2_mac_core operating clock when
> +   pcie_mac_ck/pcie_pipe_ck is turned off
> +   - obff_ckN :OBFF functional block operating clock
> +   - pipe_ckN :LTSSM and phy/mac layer operating clock
> +  where N starting from 0 to the maximum number of root ports.
>  - phys: List of PHY specifiers (used by generic PHY framework).
>  - phy-names : Must be "pcie-phy0", "pcie-phy1", "pcie-phyN".. based on the
>number of PHYs as specified in *phys* property.
> @@ -33,6 +46,10 @@ Required properties for MT7623/MT2701:
>  - reset-names: Must be "pcie-rst0", "pcie-rst1", "pcie-rstN".. based on the
>number of root ports.
>  
> +Required properties for MT2712/MT7622:
> +-interrupts: A list of interrupt outputs of the controller, must have one
> +  entry for each PCIe port
> +
>  In addition, the device tree node must have sub-nodes describing each
>  PCIe port interface, having the following mandatory properties:
>  
> @@ -50,7 +67,7 @@ Required properties:
>property is sufficient.
>  - num-lanes: Number of lanes to use for this port.
>  
> -Examples:
> +Examples for MT7623:
>  
>   hifsys: syscon@1a00 {
>   compatible = "mediatek,mt7623-hifsys",
> @@ -68,6 +85,7 @@ Examples:
> <0 0x1a142000 0 0x1000>, /* Port0 registers */
> <0 0x1a143000 0 0x1000>, /* Port1 registers */
> <0 0x1a144000 0 0x1000>; /* Port2 registers */
> + reg-names = "subsys", "port0", "port1", "port2";
>   #address-cells = <3>;
>   #size-cells = <2>;
>   #interrupt-cells = <1>;
> @@ -127,3 +145,139 @@ Examples:
>   num-lanes = <1>;
>   };
>   };
> +
> +Examples for MT2712:
> + pcie: pcie@1170 {
> + compatible = "mediatek,generic-pcie-v2";
> + device_type = "pci";
> + reg = <0 0x1170 0 0x1000>,
> +   <0 0x112ff000 0 0x1000>;
> + reg-names = "port0", "port1";
> + #address-cells = <3>;
> + #size-cells = <2>;
> + interrupts = ,
> +  ;
> + clocks = < CLK_PERI_PCIE0>,
> +  < CLK_PERI_PCIE1>,
> +  < CLK_TOP_PE2_MAC_P0_SEL>,
> +  < CLK_TOP_PE2_MAC_P1_SEL>;
> + clock-names = "sys_ck0", "sys_ck1", "ahb_ck0", "ahb_ck1";
> + phys = <_phy PHY_TYPE_PCIE>, <_phy PHY_TYPE_PCIE>;
> + phy-names = "pcie-phy0", "pcie-phy1";
> + bus-range = <0x00 0xff>;
> +   

Re: [PATCH v2 5/5] dt-bindings: PCI: add support for new generation controller

[Honghui Zhang]

On Thu, 2017-07-27 at 10:58 +0800, honghui.zh...@mediatek.com wrote:
> From: Ryder Lee 
> 
> Add support for MediaTek new generation controller and update related
> properities.
> 
> Signed-off-by: Ryder Lee 
> Signed-off-by: Honghui Zhang 
> ---
>  .../devicetree/bindings/pci/mediatek-pcie.txt  | 168 
> -
>  1 file changed, 161 insertions(+), 7 deletions(-)
> 

Sorry for the disturb, I send the wrong patch from my local version for
this patch: 
[PATCH v2 5/5] dt-bindings: PCI: add support for new generation
 controller

And the new right version have been re-send.

thanks.

> diff --git a/Documentation/devicetree/bindings/pci/mediatek-pcie.txt 
> b/Documentation/devicetree/bindings/pci/mediatek-pcie.txt
> index a968f25..179329b 100644
> --- a/Documentation/devicetree/bindings/pci/mediatek-pcie.txt
> +++ b/Documentation/devicetree/bindings/pci/mediatek-pcie.txt
> @@ -3,18 +3,31 @@ MediaTek Gen2 PCIe controller
>  Required properties:
>  - compatible: Should contain one of the following string:
>   "mediatek,mt2701-pcie"
> + "mediatek,mt2712-pcie"
> + "mediatek,mt7622-pcie"
>   "mediatek,mt7623-pcie"
>  - device_type: Must be "pci"
> -- reg: Base addresses and lengths of the PCIe controller.
> +- reg: Base addresses and lengths of the PICe subsys and root ports.
> +- reg-names: Names of the above areas to use during resource look-up.
>  - #address-cells: Address representation for root ports (must be 3)
>  - #size-cells: Size representation for root ports (must be 2)
>  - clocks: Must contain an entry for each entry in clock-names.
>See ../clocks/clock-bindings.txt for details.
> -- clock-names: Must include the following entries:
> -  - free_ck :for reference clock of PCIe subsys
> -  - sys_ck0 :for clock of Port0
> -  - sys_ck1 :for clock of Port1
> -  - sys_ck2 :for clock of Port2
> +- clock-names:
> +  Mandatory entries:
> +   - sys_ckN :transaction layer and data link layer clock
> +  Required entries for MT2701/MT7623:
> +   - free_ck :for reference clock of PCIe subsys
> +  Required entries for MT2712/MT7622:
> +   - ahb_ckN :AHB slave interface operating clock for CSR access and RC
> +   initiated MMIO access
> +  Required entries for MT7622:
> +   - axi_ckN :application layer MMIO channel operating clock
> +   - aux_ckN :pe2_mac_bridge and pe2_mac_core operating clock when
> +   pcie_mac_ck/pcie_pipe_ck is turned off
> +   - obff_ckN :OBFF functional block operating clock
> +   - pipe_ckN :LTSSM and phy/mac layer operating clock
> +  where N starting from 0 to the maximum number of root ports.
>  - phys: List of PHY specifiers (used by generic PHY framework).
>  - phy-names : Must be "pcie-phy0", "pcie-phy1", "pcie-phyN".. based on the
>number of PHYs as specified in *phys* property.
> @@ -33,6 +46,10 @@ Required properties for MT7623/MT2701:
>  - reset-names: Must be "pcie-rst0", "pcie-rst1", "pcie-rstN".. based on the
>number of root ports.
>  
> +Required properties for MT2712/MT7622:
> +-interrupts: A list of interrupt outputs of the controller, must have one
> +  entry for each PCIe port
> +
>  In addition, the device tree node must have sub-nodes describing each
>  PCIe port interface, having the following mandatory properties:
>  
> @@ -50,7 +67,7 @@ Required properties:
>property is sufficient.
>  - num-lanes: Number of lanes to use for this port.
>  
> -Examples:
> +Examples for MT7623:
>  
>   hifsys: syscon@1a00 {
>   compatible = "mediatek,mt7623-hifsys",
> @@ -68,6 +85,7 @@ Examples:
> <0 0x1a142000 0 0x1000>, /* Port0 registers */
> <0 0x1a143000 0 0x1000>, /* Port1 registers */
> <0 0x1a144000 0 0x1000>; /* Port2 registers */
> + reg-names = "subsys", "port0", "port1", "port2";
>   #address-cells = <3>;
>   #size-cells = <2>;
>   #interrupt-cells = <1>;
> @@ -127,3 +145,139 @@ Examples:
>   num-lanes = <1>;
>   };
>   };
> +
> +Examples for MT2712:
> + pcie: pcie@1170 {
> + compatible = "mediatek,generic-pcie-v2";
> + device_type = "pci";
> + reg = <0 0x1170 0 0x1000>,
> +   <0 0x112ff000 0 0x1000>;
> + reg-names = "port0", "port1";
> + #address-cells = <3>;
> + #size-cells = <2>;
> + interrupts = ,
> +  ;
> + clocks = < CLK_PERI_PCIE0>,
> +  < CLK_PERI_PCIE1>,
> +  < CLK_TOP_PE2_MAC_P0_SEL>,
> +  < CLK_TOP_PE2_MAC_P1_SEL>;
> + clock-names = "sys_ck0", "sys_ck1", "ahb_ck0", "ahb_ck1";
> + phys = <_phy PHY_TYPE_PCIE>, <_phy PHY_TYPE_PCIE>;
> + phy-names = "pcie-phy0", "pcie-phy1";
> + bus-range = <0x00 0xff>;
> + ranges = <0x8200 0 0x2000  0x0 0x2000  0 
> 0x1000>;

Re: [PATCH v2 5/5] dt-bindings: PCI: add support for new generation controller

[Honghui Zhang]

On Thu, 2017-07-27 at 10:58 +0800, honghui.zh...@mediatek.com wrote:
> From: Ryder Lee 
> 
> Add support for MediaTek new generation controller and update related
> properities.
> 
> Signed-off-by: Ryder Lee 
> Signed-off-by: Honghui Zhang 
> ---
>  .../devicetree/bindings/pci/mediatek-pcie.txt  | 168 
> -
>  1 file changed, 161 insertions(+), 7 deletions(-)
> 

Sorry about the disturb, I send the wrong local version  of this patch.
[PATCH v2 5/5] dt-bindings: PCI: add support for new generation
 controller

The right version for this patch have been re-send.

thanks.

> diff --git a/Documentation/devicetree/bindings/pci/mediatek-pcie.txt 
> b/Documentation/devicetree/bindings/pci/mediatek-pcie.txt
> index a968f25..179329b 100644
> --- a/Documentation/devicetree/bindings/pci/mediatek-pcie.txt
> +++ b/Documentation/devicetree/bindings/pci/mediatek-pcie.txt
> @@ -3,18 +3,31 @@ MediaTek Gen2 PCIe controller
>  Required properties:
>  - compatible: Should contain one of the following string:
>   "mediatek,mt2701-pcie"
> + "mediatek,mt2712-pcie"
> + "mediatek,mt7622-pcie"
>   "mediatek,mt7623-pcie"
>  - device_type: Must be "pci"
> -- reg: Base addresses and lengths of the PCIe controller.
> +- reg: Base addresses and lengths of the PICe subsys and root ports.
> +- reg-names: Names of the above areas to use during resource look-up.
>  - #address-cells: Address representation for root ports (must be 3)
>  - #size-cells: Size representation for root ports (must be 2)
>  - clocks: Must contain an entry for each entry in clock-names.
>See ../clocks/clock-bindings.txt for details.
> -- clock-names: Must include the following entries:
> -  - free_ck :for reference clock of PCIe subsys
> -  - sys_ck0 :for clock of Port0
> -  - sys_ck1 :for clock of Port1
> -  - sys_ck2 :for clock of Port2
> +- clock-names:
> +  Mandatory entries:
> +   - sys_ckN :transaction layer and data link layer clock
> +  Required entries for MT2701/MT7623:
> +   - free_ck :for reference clock of PCIe subsys
> +  Required entries for MT2712/MT7622:
> +   - ahb_ckN :AHB slave interface operating clock for CSR access and RC
> +   initiated MMIO access
> +  Required entries for MT7622:
> +   - axi_ckN :application layer MMIO channel operating clock
> +   - aux_ckN :pe2_mac_bridge and pe2_mac_core operating clock when
> +   pcie_mac_ck/pcie_pipe_ck is turned off
> +   - obff_ckN :OBFF functional block operating clock
> +   - pipe_ckN :LTSSM and phy/mac layer operating clock
> +  where N starting from 0 to the maximum number of root ports.
>  - phys: List of PHY specifiers (used by generic PHY framework).
>  - phy-names : Must be "pcie-phy0", "pcie-phy1", "pcie-phyN".. based on the
>number of PHYs as specified in *phys* property.
> @@ -33,6 +46,10 @@ Required properties for MT7623/MT2701:
>  - reset-names: Must be "pcie-rst0", "pcie-rst1", "pcie-rstN".. based on the
>number of root ports.
>  
> +Required properties for MT2712/MT7622:
> +-interrupts: A list of interrupt outputs of the controller, must have one
> +  entry for each PCIe port
> +
>  In addition, the device tree node must have sub-nodes describing each
>  PCIe port interface, having the following mandatory properties:
>  
> @@ -50,7 +67,7 @@ Required properties:
>property is sufficient.
>  - num-lanes: Number of lanes to use for this port.
>  
> -Examples:
> +Examples for MT7623:
>  
>   hifsys: syscon@1a00 {
>   compatible = "mediatek,mt7623-hifsys",
> @@ -68,6 +85,7 @@ Examples:
> <0 0x1a142000 0 0x1000>, /* Port0 registers */
> <0 0x1a143000 0 0x1000>, /* Port1 registers */
> <0 0x1a144000 0 0x1000>; /* Port2 registers */
> + reg-names = "subsys", "port0", "port1", "port2";
>   #address-cells = <3>;
>   #size-cells = <2>;
>   #interrupt-cells = <1>;
> @@ -127,3 +145,139 @@ Examples:
>   num-lanes = <1>;
>   };
>   };
> +
> +Examples for MT2712:
> + pcie: pcie@1170 {
> + compatible = "mediatek,generic-pcie-v2";
> + device_type = "pci";
> + reg = <0 0x1170 0 0x1000>,
> +   <0 0x112ff000 0 0x1000>;
> + reg-names = "port0", "port1";
> + #address-cells = <3>;
> + #size-cells = <2>;
> + interrupts = ,
> +  ;
> + clocks = < CLK_PERI_PCIE0>,
> +  < CLK_PERI_PCIE1>,
> +  < CLK_TOP_PE2_MAC_P0_SEL>,
> +  < CLK_TOP_PE2_MAC_P1_SEL>;
> + clock-names = "sys_ck0", "sys_ck1", "ahb_ck0", "ahb_ck1";
> + phys = <_phy PHY_TYPE_PCIE>, <_phy PHY_TYPE_PCIE>;
> + phy-names = "pcie-phy0", "pcie-phy1";
> + bus-range = <0x00 0xff>;
> + 

Re: [RFC PATCH] mm: memcg: fix css double put in mem_cgroup_iter

[Wenwei Tao]

2017-07-26 21:44 GMT+08:00 Michal Hocko :
> On Wed 26-07-17 21:07:42, Wenwei Tao wrote:
>> From: Wenwei Tao 
>>
>> By removing the child cgroup while the parent cgroup is
>> under reclaim, we could trigger the following kernel panic
>> on kernel 3.10:
>> 
>> kernel BUG at kernel/cgroup.c:893!
>>  invalid opcode:  [#1] SMP
>>  CPU: 1 PID: 22477 Comm: kworker/1:1 Not tainted 3.10.107 #1
>>  Workqueue: cgroup_destroy css_dput_fn
>>  task: 8817959a5780 ti: 8817e8886000 task.ti: 8817e8886000
>>  RIP: 0010:[]  []
>> cgroup_diput+0xc0/0xf0
>>  RSP: :8817e8887da0  EFLAGS: 00010246
>>  RAX:  RBX: 8817a5dd5d40 RCX: dead0200
>>  RDX:  RSI: 8817973a6910 RDI: 8817f54c2a00
>>  RBP: 8817e8887dc8 R08: 8817a5dd5dd0 R09: df9fb35794b01820
>>  R10: df9fb35794b01820 R11: 7fa95b1efcda R12: 8817a5dd5d9c
>>  R13: 8817f38b3a40 R14: 8817973a6910 R15: 8817973a6910
>>  FS:  () GS:88181f22()
>> knlGS:
>>  CS:  0010 DS:  ES:  CR0: 80050033
>>  CR2: 7fa6e6234000 CR3: 00179f19d000 CR4: 000407e0
>>  DR0:  DR1:  DR2: 
>>  DR3:  DR6: 0ff0 DR7: 0400
>>  Stack:
>>   8817a5dd5d40 8817a5dd5d9c 8817f38b3a40 8817973a6910
>>   0040 8817e8887df8 811b37c2 8817fa23c000
>>   8817f57dbb80 88181f232ac0 88181f237500 8817e8887e10
>>  Call Trace:
>>   [] dput+0x1a2/0x2f0
>>   [] cgroup_dput.isra.21+0x1c/0x30
>>   [] css_dput_fn+0x1d/0x20
>>   [] process_one_work+0x17c/0x460
>>   [] worker_thread+0x116/0x3b0
>>   [] ? manage_workers.isra.25+0x290/0x290
>>   [] kthread+0xc0/0xd0
>>   [] ? insert_kthread_work+0x40/0x40
>>   [] ret_from_fork+0x58/0x90
>>   [] ? insert_kthread_work+0x40/0x40
>>  Code: 41 5e 41 5f 5d c3 0f 1f 44 00 00 48 8b 7f 78 48 8b 07 a8 01 74 15
>> 48 81 c7 30 01 00 00 48 c7 c6 a0 a7 0c 81 e8 b2 83 02 00 eb c8 <0f> 0b
>> 49 8b 4e 18 48 c7 c2 7e f1 7a 81 be 85 03 00 00 48 c7 c7
>>  RIP  [] cgroup_diput+0xc0/0xf0
>>  RSP 
>>  ---[ end trace 85eeea5212c44f51 ]---
>> 
>>
>> I think there is a css double put in mem_cgroup_iter. Under reclaim,
>> we call mem_cgroup_iter the first time with prev == NULL, and we get
>> last_visited memcg from per zone's reclaim_iter then call 
>> __mem_cgroup_iter_next
>> try to get next alive memcg, __mem_cgroup_iter_next could return NULL
>> if last_visited is already the last one so we put the last_visited's
>> memcg css and continue to the next while loop, this time we might not
>> do css_tryget(_visited->css) if the dead_count is changed, but
>> we still do css_put(_visited->css), we put it twice, this could
>> trigger the BUG_ON at kernel/cgroup.c:893.
>
> Yes, I guess your are right and I suspect that this has been silently
> fixed by 519ebea3bf6d ("mm: memcontrol: factor out reclaim iterator
> loading and updating"). I think a more appropriate fix is would be.
> Are you able to reproduce and re-test it?
> ---

Yes, I think this commit can fix this issue, and I backport this
commit to 3.10.107 kernel
and cannot reproduce this issue. I guess this commit might need to be
backported to 3.10.y
stable kernel.

> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 437ae2cbe102..0848ec05c12a 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -1224,6 +1224,8 @@ struct mem_cgroup *mem_cgroup_iter(struct mem_cgroup 
> *root,
> if (last_visited && last_visited != root &&
> !css_tryget(_visited->css))
> last_visited = NULL;
> +   } else {
> +   last_visited = true;
> }
> }
>
> --
> Michal Hocko
> SUSE Labs

Re: [PATCH v2 5/5] dt-bindings: PCI: add support for new generation controller

[Honghui Zhang]

On Thu, 2017-07-27 at 10:58 +0800, honghui.zh...@mediatek.com wrote:
> From: Ryder Lee 
> 
> Add support for MediaTek new generation controller and update related
> properities.
> 
> Signed-off-by: Ryder Lee 
> Signed-off-by: Honghui Zhang 
> ---
>  .../devicetree/bindings/pci/mediatek-pcie.txt  | 168 
> -
>  1 file changed, 161 insertions(+), 7 deletions(-)
> 

Sorry about the disturb, I send the wrong local version  of this patch.
[PATCH v2 5/5] dt-bindings: PCI: add support for new generation
 controller

The right version for this patch have been re-send.

thanks.

> diff --git a/Documentation/devicetree/bindings/pci/mediatek-pcie.txt 
> b/Documentation/devicetree/bindings/pci/mediatek-pcie.txt
> index a968f25..179329b 100644
> --- a/Documentation/devicetree/bindings/pci/mediatek-pcie.txt
> +++ b/Documentation/devicetree/bindings/pci/mediatek-pcie.txt
> @@ -3,18 +3,31 @@ MediaTek Gen2 PCIe controller
>  Required properties:
>  - compatible: Should contain one of the following string:
>   "mediatek,mt2701-pcie"
> + "mediatek,mt2712-pcie"
> + "mediatek,mt7622-pcie"
>   "mediatek,mt7623-pcie"
>  - device_type: Must be "pci"
> -- reg: Base addresses and lengths of the PCIe controller.
> +- reg: Base addresses and lengths of the PICe subsys and root ports.
> +- reg-names: Names of the above areas to use during resource look-up.
>  - #address-cells: Address representation for root ports (must be 3)
>  - #size-cells: Size representation for root ports (must be 2)
>  - clocks: Must contain an entry for each entry in clock-names.
>See ../clocks/clock-bindings.txt for details.
> -- clock-names: Must include the following entries:
> -  - free_ck :for reference clock of PCIe subsys
> -  - sys_ck0 :for clock of Port0
> -  - sys_ck1 :for clock of Port1
> -  - sys_ck2 :for clock of Port2
> +- clock-names:
> +  Mandatory entries:
> +   - sys_ckN :transaction layer and data link layer clock
> +  Required entries for MT2701/MT7623:
> +   - free_ck :for reference clock of PCIe subsys
> +  Required entries for MT2712/MT7622:
> +   - ahb_ckN :AHB slave interface operating clock for CSR access and RC
> +   initiated MMIO access
> +  Required entries for MT7622:
> +   - axi_ckN :application layer MMIO channel operating clock
> +   - aux_ckN :pe2_mac_bridge and pe2_mac_core operating clock when
> +   pcie_mac_ck/pcie_pipe_ck is turned off
> +   - obff_ckN :OBFF functional block operating clock
> +   - pipe_ckN :LTSSM and phy/mac layer operating clock
> +  where N starting from 0 to the maximum number of root ports.
>  - phys: List of PHY specifiers (used by generic PHY framework).
>  - phy-names : Must be "pcie-phy0", "pcie-phy1", "pcie-phyN".. based on the
>number of PHYs as specified in *phys* property.
> @@ -33,6 +46,10 @@ Required properties for MT7623/MT2701:
>  - reset-names: Must be "pcie-rst0", "pcie-rst1", "pcie-rstN".. based on the
>number of root ports.
>  
> +Required properties for MT2712/MT7622:
> +-interrupts: A list of interrupt outputs of the controller, must have one
> +  entry for each PCIe port
> +
>  In addition, the device tree node must have sub-nodes describing each
>  PCIe port interface, having the following mandatory properties:
>  
> @@ -50,7 +67,7 @@ Required properties:
>property is sufficient.
>  - num-lanes: Number of lanes to use for this port.
>  
> -Examples:
> +Examples for MT7623:
>  
>   hifsys: syscon@1a00 {
>   compatible = "mediatek,mt7623-hifsys",
> @@ -68,6 +85,7 @@ Examples:
> <0 0x1a142000 0 0x1000>, /* Port0 registers */
> <0 0x1a143000 0 0x1000>, /* Port1 registers */
> <0 0x1a144000 0 0x1000>; /* Port2 registers */
> + reg-names = "subsys", "port0", "port1", "port2";
>   #address-cells = <3>;
>   #size-cells = <2>;
>   #interrupt-cells = <1>;
> @@ -127,3 +145,139 @@ Examples:
>   num-lanes = <1>;
>   };
>   };
> +
> +Examples for MT2712:
> + pcie: pcie@1170 {
> + compatible = "mediatek,generic-pcie-v2";
> + device_type = "pci";
> + reg = <0 0x1170 0 0x1000>,
> +   <0 0x112ff000 0 0x1000>;
> + reg-names = "port0", "port1";
> + #address-cells = <3>;
> + #size-cells = <2>;
> + interrupts = ,
> +  ;
> + clocks = < CLK_PERI_PCIE0>,
> +  < CLK_PERI_PCIE1>,
> +  < CLK_TOP_PE2_MAC_P0_SEL>,
> +  < CLK_TOP_PE2_MAC_P1_SEL>;
> + clock-names = "sys_ck0", "sys_ck1", "ahb_ck0", "ahb_ck1";
> + phys = <_phy PHY_TYPE_PCIE>, <_phy PHY_TYPE_PCIE>;
> + phy-names = "pcie-phy0", "pcie-phy1";
> + bus-range = <0x00 0xff>;
> + ranges = <0x8200 0 0x2000  0x0 0x2000  0 
> 0x1000>;
> +
> 

Re: [RFC PATCH] mm: memcg: fix css double put in mem_cgroup_iter

[Wenwei Tao]

2017-07-26 21:44 GMT+08:00 Michal Hocko :
> On Wed 26-07-17 21:07:42, Wenwei Tao wrote:
>> From: Wenwei Tao 
>>
>> By removing the child cgroup while the parent cgroup is
>> under reclaim, we could trigger the following kernel panic
>> on kernel 3.10:
>> 
>> kernel BUG at kernel/cgroup.c:893!
>>  invalid opcode:  [#1] SMP
>>  CPU: 1 PID: 22477 Comm: kworker/1:1 Not tainted 3.10.107 #1
>>  Workqueue: cgroup_destroy css_dput_fn
>>  task: 8817959a5780 ti: 8817e8886000 task.ti: 8817e8886000
>>  RIP: 0010:[]  []
>> cgroup_diput+0xc0/0xf0
>>  RSP: :8817e8887da0  EFLAGS: 00010246
>>  RAX:  RBX: 8817a5dd5d40 RCX: dead0200
>>  RDX:  RSI: 8817973a6910 RDI: 8817f54c2a00
>>  RBP: 8817e8887dc8 R08: 8817a5dd5dd0 R09: df9fb35794b01820
>>  R10: df9fb35794b01820 R11: 7fa95b1efcda R12: 8817a5dd5d9c
>>  R13: 8817f38b3a40 R14: 8817973a6910 R15: 8817973a6910
>>  FS:  () GS:88181f22()
>> knlGS:
>>  CS:  0010 DS:  ES:  CR0: 80050033
>>  CR2: 7fa6e6234000 CR3: 00179f19d000 CR4: 000407e0
>>  DR0:  DR1:  DR2: 
>>  DR3:  DR6: 0ff0 DR7: 0400
>>  Stack:
>>   8817a5dd5d40 8817a5dd5d9c 8817f38b3a40 8817973a6910
>>   0040 8817e8887df8 811b37c2 8817fa23c000
>>   8817f57dbb80 88181f232ac0 88181f237500 8817e8887e10
>>  Call Trace:
>>   [] dput+0x1a2/0x2f0
>>   [] cgroup_dput.isra.21+0x1c/0x30
>>   [] css_dput_fn+0x1d/0x20
>>   [] process_one_work+0x17c/0x460
>>   [] worker_thread+0x116/0x3b0
>>   [] ? manage_workers.isra.25+0x290/0x290
>>   [] kthread+0xc0/0xd0
>>   [] ? insert_kthread_work+0x40/0x40
>>   [] ret_from_fork+0x58/0x90
>>   [] ? insert_kthread_work+0x40/0x40
>>  Code: 41 5e 41 5f 5d c3 0f 1f 44 00 00 48 8b 7f 78 48 8b 07 a8 01 74 15
>> 48 81 c7 30 01 00 00 48 c7 c6 a0 a7 0c 81 e8 b2 83 02 00 eb c8 <0f> 0b
>> 49 8b 4e 18 48 c7 c2 7e f1 7a 81 be 85 03 00 00 48 c7 c7
>>  RIP  [] cgroup_diput+0xc0/0xf0
>>  RSP 
>>  ---[ end trace 85eeea5212c44f51 ]---
>> 
>>
>> I think there is a css double put in mem_cgroup_iter. Under reclaim,
>> we call mem_cgroup_iter the first time with prev == NULL, and we get
>> last_visited memcg from per zone's reclaim_iter then call 
>> __mem_cgroup_iter_next
>> try to get next alive memcg, __mem_cgroup_iter_next could return NULL
>> if last_visited is already the last one so we put the last_visited's
>> memcg css and continue to the next while loop, this time we might not
>> do css_tryget(_visited->css) if the dead_count is changed, but
>> we still do css_put(_visited->css), we put it twice, this could
>> trigger the BUG_ON at kernel/cgroup.c:893.
>
> Yes, I guess your are right and I suspect that this has been silently
> fixed by 519ebea3bf6d ("mm: memcontrol: factor out reclaim iterator
> loading and updating"). I think a more appropriate fix is would be.
> Are you able to reproduce and re-test it?
> ---

Yes, I think this commit can fix this issue, and I backport this
commit to 3.10.107 kernel
and cannot reproduce this issue. I guess this commit might need to be
backported to 3.10.y
stable kernel.

> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 437ae2cbe102..0848ec05c12a 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -1224,6 +1224,8 @@ struct mem_cgroup *mem_cgroup_iter(struct mem_cgroup 
> *root,
> if (last_visited && last_visited != root &&
> !css_tryget(_visited->css))
> last_visited = NULL;
> +   } else {
> +   last_visited = true;
> }
> }
>
> --
> Michal Hocko
> SUSE Labs

Re: [Eas-dev] [PATCH V3 1/3] sched: cpufreq: Allow remote cpufreq callbacks

[Viresh Kumar]

On 26-07-17, 14:00, Saravana Kannan wrote:
> No, the alternative is to pass it on to the CPU freq driver and let it
> decide what it wants to do. That's the whole point if having a CPU freq
> driver -- so that the generic code doesn't need to care about HW specific
> details. Which is the point I was making in an earlier email to Viresh's
> patch -- we shouldn't be doing any CPU check for the call backs at the
> scheduler or ever governor level.
> 
> That would simplify this whole thing by deleting a bunch of code. And having
> much simpler checks in those drivers that actually have to deal with their
> HW specific details.

So what you are saying is that we go and update (almost) every cpufreq
driver we have today and make their ->target() callbacks return early
if they don't support switching frequency remotely ? Is that really
simplifying anything?

The core already has most of the data required and I believe that we
need to handle it in the governor's code as is handled in this series.

To solve the problem that you have been reporting (update from any
CPU), we need something like this which I earlier suggested and I
will come back to it after this series is gone. Don't want to
complicate things here unnecessarily.

https://marc.info/?l=linux-kernel=148906012827786=2

-- 
viresh

Re: [Eas-dev] [PATCH V3 1/3] sched: cpufreq: Allow remote cpufreq callbacks

[Viresh Kumar]

On 26-07-17, 14:00, Saravana Kannan wrote:
> No, the alternative is to pass it on to the CPU freq driver and let it
> decide what it wants to do. That's the whole point if having a CPU freq
> driver -- so that the generic code doesn't need to care about HW specific
> details. Which is the point I was making in an earlier email to Viresh's
> patch -- we shouldn't be doing any CPU check for the call backs at the
> scheduler or ever governor level.
> 
> That would simplify this whole thing by deleting a bunch of code. And having
> much simpler checks in those drivers that actually have to deal with their
> HW specific details.

So what you are saying is that we go and update (almost) every cpufreq
driver we have today and make their ->target() callbacks return early
if they don't support switching frequency remotely ? Is that really
simplifying anything?

The core already has most of the data required and I believe that we
need to handle it in the governor's code as is handled in this series.

To solve the problem that you have been reporting (update from any
CPU), we need something like this which I earlier suggested and I
will come back to it after this series is gone. Don't want to
complicate things here unnecessarily.

https://marc.info/?l=linux-kernel=148906012827786=2

-- 
viresh

Re: [PATCH v2 1/5] PCI: mediatek: Add a structure to abstract the controller generations

[Honghui Zhang]

On Thu, 2017-07-27 at 11:19 +0800, Honghui Zhang wrote:
> On Thu, 2017-07-27 at 10:58 +0800, honghui.zh...@mediatek.com wrote:
> > From: Ryder Lee 
> > 
> > Introduce a structure "mtk_pcie_soc" to abstract the differences between
> > controller generations, and the .startup() hook is used to encapsulate
> > some SoC-dependent related setting. In doing so, the common code which
> > will be reused by future chips.
> > 
> > In addition, we change the approaches to waiting Gen2 training by using
> > readl_poll_timeout() calls.
> > 
> > Signed-off-by: Ryder Lee 
> > Signed-off-by: Honghui Zhang 
> > ---
> >  drivers/pci/host/pcie-mediatek.c | 81 
> > +++-
> >  1 file changed, 47 insertions(+), 34 deletions(-)
> > 
> > diff --git a/drivers/pci/host/pcie-mediatek.c 
> > b/drivers/pci/host/pcie-mediatek.c
> > index 5a9d858..7f952a4 100644
> > --- a/drivers/pci/host/pcie-mediatek.c
> > +++ b/drivers/pci/host/pcie-mediatek.c
> > @@ -16,6 +16,7 @@
> >  
> 
> Sorry about the disturb, I send the wrong patch for this one.
> I will resend the right version for this last patch.
> 

Sorry, I reply to the wrong patch mail.
I meant to re-send the patch:
[PATCH v2 5/5] dt-bindings: PCI: add support for new generation
controller, not this one.

This one is the right patch.

tahnks.

> thanks.
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -63,6 +64,18 @@
> >  #define PCIE_FC_CREDIT_MASK(GENMASK(31, 31) | GENMASK(28, 16))
> >  #define PCIE_FC_CREDIT_VAL(x)  ((x) << 16)
> >  
> > +struct mtk_pcie_port;
> > +
> > +/**
> > + * struct mtk_pcie_soc - differentiate between host generations
> > + * @ops: pointer to configuration access functions
> > + * @startup: pointer to controller setting functions
> > + */
> > +struct mtk_pcie_soc {
> > +   struct pci_ops *ops;
> > +   int (*startup)(struct mtk_pcie_port *port);
> > +};
> > +
> >  /**
> >   * struct mtk_pcie_port - PCIe port information
> >   * @base: IO mapped register base
> > @@ -96,6 +109,7 @@ struct mtk_pcie_port {
> >   * @busn: bus range
> >   * @offset: IO / Memory offset
> >   * @ports: pointer to PCIe port information
> > + * @soc: pointer to SoC-dependent operations
> >   */
> >  struct mtk_pcie {
> > struct device *dev;
> > @@ -111,13 +125,9 @@ struct mtk_pcie {
> > resource_size_t io;
> > } offset;
> > struct list_head ports;
> > +   const struct mtk_pcie_soc *soc;
> >  };
> >  
> > -static inline bool mtk_pcie_link_up(struct mtk_pcie_port *port)
> > -{
> > -   return !!(readl(port->base + PCIE_LINK_STATUS) & PCIE_PORT_LINKUP);
> > -}
> > -
> >  static void mtk_pcie_subsys_powerdown(struct mtk_pcie *pcie)
> >  {
> > struct device *dev = pcie->dev;
> > @@ -171,12 +181,30 @@ static struct pci_ops mtk_pcie_ops = {
> > .write = pci_generic_config_write,
> >  };
> >  
> > -static void mtk_pcie_configure_rc(struct mtk_pcie_port *port)
> > +static int mtk_pcie_startup_ports(struct mtk_pcie_port *port)
> >  {
> > struct mtk_pcie *pcie = port->pcie;
> > u32 func = PCI_FUNC(port->index << 3);
> > u32 slot = PCI_SLOT(port->index << 3);
> > u32 val;
> > +   int err;
> > +
> > +   /* assert port PERST_N */
> > +   val = readl(pcie->base + PCIE_SYS_CFG);
> > +   val |= PCIE_PORT_PERST(port->index);
> > +   writel(val, pcie->base + PCIE_SYS_CFG);
> > +
> > +   /* de-assert port PERST_N */
> > +   val = readl(pcie->base + PCIE_SYS_CFG);
> > +   val &= ~PCIE_PORT_PERST(port->index);
> > +   writel(val, pcie->base + PCIE_SYS_CFG);
> > +
> > +   /* 100ms timeout value should be enough for Gen1/2 training */
> > +   err = readl_poll_timeout(port->base + PCIE_LINK_STATUS, val,
> > +!!(val & PCIE_PORT_LINKUP), 20,
> > +100 * USEC_PER_MSEC);
> > +   if (err)
> > +   return -ETIMEDOUT;
> >  
> > /* enable interrupt */
> > val = readl(pcie->base + PCIE_INT_ENABLE);
> > @@ -209,30 +237,14 @@ static void mtk_pcie_configure_rc(struct 
> > mtk_pcie_port *port)
> > writel(PCIE_CONF_ADDR(PCIE_FTS_NUM, func, slot, 0),
> >pcie->base + PCIE_CFG_ADDR);
> > writel(val, pcie->base + PCIE_CFG_DATA);
> > -}
> >  
> > -static void mtk_pcie_assert_ports(struct mtk_pcie_port *port)
> > -{
> > -   struct mtk_pcie *pcie = port->pcie;
> > -   u32 val;
> > -
> > -   /* assert port PERST_N */
> > -   val = readl(pcie->base + PCIE_SYS_CFG);
> > -   val |= PCIE_PORT_PERST(port->index);
> > -   writel(val, pcie->base + PCIE_SYS_CFG);
> > -
> > -   /* de-assert port PERST_N */
> > -   val = readl(pcie->base + PCIE_SYS_CFG);
> > -   val &= ~PCIE_PORT_PERST(port->index);
> > -   writel(val, pcie->base + PCIE_SYS_CFG);
> > -
> > -   /* PCIe v2.0 need at least 100ms delay to train from Gen1 to Gen2 */
> > -   msleep(100);
> > +   return 0;
> >  }
> >  
> >  static void mtk_pcie_enable_ports(struct mtk_pcie_port 

Re: [PATCH v2 1/5] PCI: mediatek: Add a structure to abstract the controller generations

[Honghui Zhang]

On Thu, 2017-07-27 at 11:19 +0800, Honghui Zhang wrote:
> On Thu, 2017-07-27 at 10:58 +0800, honghui.zh...@mediatek.com wrote:
> > From: Ryder Lee 
> > 
> > Introduce a structure "mtk_pcie_soc" to abstract the differences between
> > controller generations, and the .startup() hook is used to encapsulate
> > some SoC-dependent related setting. In doing so, the common code which
> > will be reused by future chips.
> > 
> > In addition, we change the approaches to waiting Gen2 training by using
> > readl_poll_timeout() calls.
> > 
> > Signed-off-by: Ryder Lee 
> > Signed-off-by: Honghui Zhang 
> > ---
> >  drivers/pci/host/pcie-mediatek.c | 81 
> > +++-
> >  1 file changed, 47 insertions(+), 34 deletions(-)
> > 
> > diff --git a/drivers/pci/host/pcie-mediatek.c 
> > b/drivers/pci/host/pcie-mediatek.c
> > index 5a9d858..7f952a4 100644
> > --- a/drivers/pci/host/pcie-mediatek.c
> > +++ b/drivers/pci/host/pcie-mediatek.c
> > @@ -16,6 +16,7 @@
> >  
> 
> Sorry about the disturb, I send the wrong patch for this one.
> I will resend the right version for this last patch.
> 

Sorry, I reply to the wrong patch mail.
I meant to re-send the patch:
[PATCH v2 5/5] dt-bindings: PCI: add support for new generation
controller, not this one.

This one is the right patch.

tahnks.

> thanks.
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -63,6 +64,18 @@
> >  #define PCIE_FC_CREDIT_MASK(GENMASK(31, 31) | GENMASK(28, 16))
> >  #define PCIE_FC_CREDIT_VAL(x)  ((x) << 16)
> >  
> > +struct mtk_pcie_port;
> > +
> > +/**
> > + * struct mtk_pcie_soc - differentiate between host generations
> > + * @ops: pointer to configuration access functions
> > + * @startup: pointer to controller setting functions
> > + */
> > +struct mtk_pcie_soc {
> > +   struct pci_ops *ops;
> > +   int (*startup)(struct mtk_pcie_port *port);
> > +};
> > +
> >  /**
> >   * struct mtk_pcie_port - PCIe port information
> >   * @base: IO mapped register base
> > @@ -96,6 +109,7 @@ struct mtk_pcie_port {
> >   * @busn: bus range
> >   * @offset: IO / Memory offset
> >   * @ports: pointer to PCIe port information
> > + * @soc: pointer to SoC-dependent operations
> >   */
> >  struct mtk_pcie {
> > struct device *dev;
> > @@ -111,13 +125,9 @@ struct mtk_pcie {
> > resource_size_t io;
> > } offset;
> > struct list_head ports;
> > +   const struct mtk_pcie_soc *soc;
> >  };
> >  
> > -static inline bool mtk_pcie_link_up(struct mtk_pcie_port *port)
> > -{
> > -   return !!(readl(port->base + PCIE_LINK_STATUS) & PCIE_PORT_LINKUP);
> > -}
> > -
> >  static void mtk_pcie_subsys_powerdown(struct mtk_pcie *pcie)
> >  {
> > struct device *dev = pcie->dev;
> > @@ -171,12 +181,30 @@ static struct pci_ops mtk_pcie_ops = {
> > .write = pci_generic_config_write,
> >  };
> >  
> > -static void mtk_pcie_configure_rc(struct mtk_pcie_port *port)
> > +static int mtk_pcie_startup_ports(struct mtk_pcie_port *port)
> >  {
> > struct mtk_pcie *pcie = port->pcie;
> > u32 func = PCI_FUNC(port->index << 3);
> > u32 slot = PCI_SLOT(port->index << 3);
> > u32 val;
> > +   int err;
> > +
> > +   /* assert port PERST_N */
> > +   val = readl(pcie->base + PCIE_SYS_CFG);
> > +   val |= PCIE_PORT_PERST(port->index);
> > +   writel(val, pcie->base + PCIE_SYS_CFG);
> > +
> > +   /* de-assert port PERST_N */
> > +   val = readl(pcie->base + PCIE_SYS_CFG);
> > +   val &= ~PCIE_PORT_PERST(port->index);
> > +   writel(val, pcie->base + PCIE_SYS_CFG);
> > +
> > +   /* 100ms timeout value should be enough for Gen1/2 training */
> > +   err = readl_poll_timeout(port->base + PCIE_LINK_STATUS, val,
> > +!!(val & PCIE_PORT_LINKUP), 20,
> > +100 * USEC_PER_MSEC);
> > +   if (err)
> > +   return -ETIMEDOUT;
> >  
> > /* enable interrupt */
> > val = readl(pcie->base + PCIE_INT_ENABLE);
> > @@ -209,30 +237,14 @@ static void mtk_pcie_configure_rc(struct 
> > mtk_pcie_port *port)
> > writel(PCIE_CONF_ADDR(PCIE_FTS_NUM, func, slot, 0),
> >pcie->base + PCIE_CFG_ADDR);
> > writel(val, pcie->base + PCIE_CFG_DATA);
> > -}
> >  
> > -static void mtk_pcie_assert_ports(struct mtk_pcie_port *port)
> > -{
> > -   struct mtk_pcie *pcie = port->pcie;
> > -   u32 val;
> > -
> > -   /* assert port PERST_N */
> > -   val = readl(pcie->base + PCIE_SYS_CFG);
> > -   val |= PCIE_PORT_PERST(port->index);
> > -   writel(val, pcie->base + PCIE_SYS_CFG);
> > -
> > -   /* de-assert port PERST_N */
> > -   val = readl(pcie->base + PCIE_SYS_CFG);
> > -   val &= ~PCIE_PORT_PERST(port->index);
> > -   writel(val, pcie->base + PCIE_SYS_CFG);
> > -
> > -   /* PCIe v2.0 need at least 100ms delay to train from Gen1 to Gen2 */
> > -   msleep(100);
> > +   return 0;
> >  }
> >  
> >  static void mtk_pcie_enable_ports(struct mtk_pcie_port *port)
> >  {
> > -   struct device *dev = port->pcie->dev;
> > +   struct 

Re: [PATCH V4 1/3] sched: cpufreq: Allow remote cpufreq callbacks

[Viresh Kumar]

On 26-07-17, 19:42, Rafael J. Wysocki wrote:
> On Wednesday, July 26, 2017 02:52:32 PM Viresh Kumar wrote:

> > +   /* Don't allow remote callbacks */
> > +   if (smp_processor_id() != data->cpu)
> > +   return;
> 
> You can do this check against cpu->cpu, however.
> 
> > +   /* Don't allow remote callbacks */
> > +   if (smp_processor_id() != data->cpu)
> > +   return;
> 
> And same here.
> 
> > +
> > if (flags & SCHED_CPUFREQ_IOWAIT) {
> > cpu->iowait_boost = int_tofp(1);
> > } else if (cpu->iowait_boost) {
> > diff --git a/include/linux/sched/cpufreq.h b/include/linux/sched/cpufreq.h
> > index d2be2ccbb372..8256a8f35f22 100644
> > --- a/include/linux/sched/cpufreq.h
> > +++ b/include/linux/sched/cpufreq.h
> > @@ -16,6 +16,7 @@
> >  #ifdef CONFIG_CPU_FREQ
> >  struct update_util_data {
> > void (*func)(struct update_util_data *data, u64 time, unsigned int 
> > flags);
> > +   unsigned int cpu;
> 
> So it looks like you don't need this.
> 
> schedutil doesn't need it as per patch [2/3].

Hmm, so your comments are exactly same as what Peter suggested few
days back.

sugov_get_util() uses it in 2/3, as we need to know the target CPU
anyway.

But I think it would be better to add the cpu variable in sugov_cpu
structure instead as only schedutil needs it. I will do that change
and send V5.

-- 
viresh

Re: [PATCH V4 1/3] sched: cpufreq: Allow remote cpufreq callbacks

[Viresh Kumar]

On 26-07-17, 19:42, Rafael J. Wysocki wrote:
> On Wednesday, July 26, 2017 02:52:32 PM Viresh Kumar wrote:

> > +   /* Don't allow remote callbacks */
> > +   if (smp_processor_id() != data->cpu)
> > +   return;
> 
> You can do this check against cpu->cpu, however.
> 
> > +   /* Don't allow remote callbacks */
> > +   if (smp_processor_id() != data->cpu)
> > +   return;
> 
> And same here.
> 
> > +
> > if (flags & SCHED_CPUFREQ_IOWAIT) {
> > cpu->iowait_boost = int_tofp(1);
> > } else if (cpu->iowait_boost) {
> > diff --git a/include/linux/sched/cpufreq.h b/include/linux/sched/cpufreq.h
> > index d2be2ccbb372..8256a8f35f22 100644
> > --- a/include/linux/sched/cpufreq.h
> > +++ b/include/linux/sched/cpufreq.h
> > @@ -16,6 +16,7 @@
> >  #ifdef CONFIG_CPU_FREQ
> >  struct update_util_data {
> > void (*func)(struct update_util_data *data, u64 time, unsigned int 
> > flags);
> > +   unsigned int cpu;
> 
> So it looks like you don't need this.
> 
> schedutil doesn't need it as per patch [2/3].

Hmm, so your comments are exactly same as what Peter suggested few
days back.

sugov_get_util() uses it in 2/3, as we need to know the target CPU
anyway.

But I think it would be better to add the cpu variable in sugov_cpu
structure instead as only schedutil needs it. I will do that change
and send V5.

-- 
viresh

[PATCH V2 net] Revert "vhost: cache used event for better performance"

[Jason Wang]

This reverts commit 809ecb9bca6a9424ccd392d67e368160f8b76c92. Since it
was reported to break vhost_net. We want to cache used event and use
it to check for notification. The assumption was that guest won't move
the event idx back, but this could happen in fact when 16 bit index
wraps around after 64K entries.

Signed-off-by: Jason Wang 
---
- Changes from V1: tweak commit log
- The patch is needed for -stable.
---
 drivers/vhost/vhost.c | 28 ++--
 drivers/vhost/vhost.h |  3 ---
 2 files changed, 6 insertions(+), 25 deletions(-)

diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index e4613a3..9cb3f72 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -308,7 +308,6 @@ static void vhost_vq_reset(struct vhost_dev *dev,
vq->avail = NULL;
vq->used = NULL;
vq->last_avail_idx = 0;
-   vq->last_used_event = 0;
vq->avail_idx = 0;
vq->last_used_idx = 0;
vq->signalled_used = 0;
@@ -1402,7 +1401,7 @@ long vhost_vring_ioctl(struct vhost_dev *d, int ioctl, 
void __user *argp)
r = -EINVAL;
break;
}
-   vq->last_avail_idx = vq->last_used_event = s.num;
+   vq->last_avail_idx = s.num;
/* Forget the cached index value. */
vq->avail_idx = vq->last_avail_idx;
break;
@@ -2241,6 +2240,10 @@ static bool vhost_notify(struct vhost_dev *dev, struct 
vhost_virtqueue *vq)
__u16 old, new;
__virtio16 event;
bool v;
+   /* Flush out used index updates. This is paired
+* with the barrier that the Guest executes when enabling
+* interrupts. */
+   smp_mb();
 
if (vhost_has_feature(vq, VIRTIO_F_NOTIFY_ON_EMPTY) &&
unlikely(vq->avail_idx == vq->last_avail_idx))
@@ -2248,10 +2251,6 @@ static bool vhost_notify(struct vhost_dev *dev, struct 
vhost_virtqueue *vq)
 
if (!vhost_has_feature(vq, VIRTIO_RING_F_EVENT_IDX)) {
__virtio16 flags;
-   /* Flush out used index updates. This is paired
-* with the barrier that the Guest executes when enabling
-* interrupts. */
-   smp_mb();
if (vhost_get_avail(vq, flags, >avail->flags)) {
vq_err(vq, "Failed to get flags");
return true;
@@ -2266,26 +2265,11 @@ static bool vhost_notify(struct vhost_dev *dev, struct 
vhost_virtqueue *vq)
if (unlikely(!v))
return true;
 
-   /* We're sure if the following conditions are met, there's no
-* need to notify guest:
-* 1) cached used event is ahead of new
-* 2) old to new updating does not cross cached used event. */
-   if (vring_need_event(vq->last_used_event, new + vq->num, new) &&
-   !vring_need_event(vq->last_used_event, new, old))
-   return false;
-
-   /* Flush out used index updates. This is paired
-* with the barrier that the Guest executes when enabling
-* interrupts. */
-   smp_mb();
-
if (vhost_get_avail(vq, event, vhost_used_event(vq))) {
vq_err(vq, "Failed to get used event idx");
return true;
}
-   vq->last_used_event = vhost16_to_cpu(vq, event);
-
-   return vring_need_event(vq->last_used_event, new, old);
+   return vring_need_event(vhost16_to_cpu(vq, event), new, old);
 }
 
 /* This actually signals the guest, using eventfd. */
diff --git a/drivers/vhost/vhost.h b/drivers/vhost/vhost.h
index f720958..bb7c29b 100644
--- a/drivers/vhost/vhost.h
+++ b/drivers/vhost/vhost.h
@@ -115,9 +115,6 @@ struct vhost_virtqueue {
/* Last index we used. */
u16 last_used_idx;
 
-   /* Last used evet we've seen */
-   u16 last_used_event;
-
/* Used flags */
u16 used_flags;
 
-- 
2.7.4

[PATCH V2 net] Revert "vhost: cache used event for better performance"

[Jason Wang]

This reverts commit 809ecb9bca6a9424ccd392d67e368160f8b76c92. Since it
was reported to break vhost_net. We want to cache used event and use
it to check for notification. The assumption was that guest won't move
the event idx back, but this could happen in fact when 16 bit index
wraps around after 64K entries.

Signed-off-by: Jason Wang 
---
- Changes from V1: tweak commit log
- The patch is needed for -stable.
---
 drivers/vhost/vhost.c | 28 ++--
 drivers/vhost/vhost.h |  3 ---
 2 files changed, 6 insertions(+), 25 deletions(-)

diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index e4613a3..9cb3f72 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -308,7 +308,6 @@ static void vhost_vq_reset(struct vhost_dev *dev,
vq->avail = NULL;
vq->used = NULL;
vq->last_avail_idx = 0;
-   vq->last_used_event = 0;
vq->avail_idx = 0;
vq->last_used_idx = 0;
vq->signalled_used = 0;
@@ -1402,7 +1401,7 @@ long vhost_vring_ioctl(struct vhost_dev *d, int ioctl, 
void __user *argp)
r = -EINVAL;
break;
}
-   vq->last_avail_idx = vq->last_used_event = s.num;
+   vq->last_avail_idx = s.num;
/* Forget the cached index value. */
vq->avail_idx = vq->last_avail_idx;
break;
@@ -2241,6 +2240,10 @@ static bool vhost_notify(struct vhost_dev *dev, struct 
vhost_virtqueue *vq)
__u16 old, new;
__virtio16 event;
bool v;
+   /* Flush out used index updates. This is paired
+* with the barrier that the Guest executes when enabling
+* interrupts. */
+   smp_mb();
 
if (vhost_has_feature(vq, VIRTIO_F_NOTIFY_ON_EMPTY) &&
unlikely(vq->avail_idx == vq->last_avail_idx))
@@ -2248,10 +2251,6 @@ static bool vhost_notify(struct vhost_dev *dev, struct 
vhost_virtqueue *vq)
 
if (!vhost_has_feature(vq, VIRTIO_RING_F_EVENT_IDX)) {
__virtio16 flags;
-   /* Flush out used index updates. This is paired
-* with the barrier that the Guest executes when enabling
-* interrupts. */
-   smp_mb();
if (vhost_get_avail(vq, flags, >avail->flags)) {
vq_err(vq, "Failed to get flags");
return true;
@@ -2266,26 +2265,11 @@ static bool vhost_notify(struct vhost_dev *dev, struct 
vhost_virtqueue *vq)
if (unlikely(!v))
return true;
 
-   /* We're sure if the following conditions are met, there's no
-* need to notify guest:
-* 1) cached used event is ahead of new
-* 2) old to new updating does not cross cached used event. */
-   if (vring_need_event(vq->last_used_event, new + vq->num, new) &&
-   !vring_need_event(vq->last_used_event, new, old))
-   return false;
-
-   /* Flush out used index updates. This is paired
-* with the barrier that the Guest executes when enabling
-* interrupts. */
-   smp_mb();
-
if (vhost_get_avail(vq, event, vhost_used_event(vq))) {
vq_err(vq, "Failed to get used event idx");
return true;
}
-   vq->last_used_event = vhost16_to_cpu(vq, event);
-
-   return vring_need_event(vq->last_used_event, new, old);
+   return vring_need_event(vhost16_to_cpu(vq, event), new, old);
 }
 
 /* This actually signals the guest, using eventfd. */
diff --git a/drivers/vhost/vhost.h b/drivers/vhost/vhost.h
index f720958..bb7c29b 100644
--- a/drivers/vhost/vhost.h
+++ b/drivers/vhost/vhost.h
@@ -115,9 +115,6 @@ struct vhost_virtqueue {
/* Last index we used. */
u16 last_used_idx;
 
-   /* Last used evet we've seen */
-   u16 last_used_event;
-
/* Used flags */
u16 used_flags;
 
-- 
2.7.4

Re: [PATCH v2 1/5] PCI: mediatek: Add a structure to abstract the controller generations

[Honghui Zhang]

On Thu, 2017-07-27 at 10:58 +0800, honghui.zh...@mediatek.com wrote:
> From: Ryder Lee 
> 
> Introduce a structure "mtk_pcie_soc" to abstract the differences between
> controller generations, and the .startup() hook is used to encapsulate
> some SoC-dependent related setting. In doing so, the common code which
> will be reused by future chips.
> 
> In addition, we change the approaches to waiting Gen2 training by using
> readl_poll_timeout() calls.
> 
> Signed-off-by: Ryder Lee 
> Signed-off-by: Honghui Zhang 
> ---
>  drivers/pci/host/pcie-mediatek.c | 81 
> +++-
>  1 file changed, 47 insertions(+), 34 deletions(-)
> 
> diff --git a/drivers/pci/host/pcie-mediatek.c 
> b/drivers/pci/host/pcie-mediatek.c
> index 5a9d858..7f952a4 100644
> --- a/drivers/pci/host/pcie-mediatek.c
> +++ b/drivers/pci/host/pcie-mediatek.c
> @@ -16,6 +16,7 @@
>  

Sorry about the disturb, I send the wrong patch for this one.
I will resend the right version for this last patch.

thanks.
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -63,6 +64,18 @@
>  #define PCIE_FC_CREDIT_MASK  (GENMASK(31, 31) | GENMASK(28, 16))
>  #define PCIE_FC_CREDIT_VAL(x)((x) << 16)
>  
> +struct mtk_pcie_port;
> +
> +/**
> + * struct mtk_pcie_soc - differentiate between host generations
> + * @ops: pointer to configuration access functions
> + * @startup: pointer to controller setting functions
> + */
> +struct mtk_pcie_soc {
> + struct pci_ops *ops;
> + int (*startup)(struct mtk_pcie_port *port);
> +};
> +
>  /**
>   * struct mtk_pcie_port - PCIe port information
>   * @base: IO mapped register base
> @@ -96,6 +109,7 @@ struct mtk_pcie_port {
>   * @busn: bus range
>   * @offset: IO / Memory offset
>   * @ports: pointer to PCIe port information
> + * @soc: pointer to SoC-dependent operations
>   */
>  struct mtk_pcie {
>   struct device *dev;
> @@ -111,13 +125,9 @@ struct mtk_pcie {
>   resource_size_t io;
>   } offset;
>   struct list_head ports;
> + const struct mtk_pcie_soc *soc;
>  };
>  
> -static inline bool mtk_pcie_link_up(struct mtk_pcie_port *port)
> -{
> - return !!(readl(port->base + PCIE_LINK_STATUS) & PCIE_PORT_LINKUP);
> -}
> -
>  static void mtk_pcie_subsys_powerdown(struct mtk_pcie *pcie)
>  {
>   struct device *dev = pcie->dev;
> @@ -171,12 +181,30 @@ static struct pci_ops mtk_pcie_ops = {
>   .write = pci_generic_config_write,
>  };
>  
> -static void mtk_pcie_configure_rc(struct mtk_pcie_port *port)
> +static int mtk_pcie_startup_ports(struct mtk_pcie_port *port)
>  {
>   struct mtk_pcie *pcie = port->pcie;
>   u32 func = PCI_FUNC(port->index << 3);
>   u32 slot = PCI_SLOT(port->index << 3);
>   u32 val;
> + int err;
> +
> + /* assert port PERST_N */
> + val = readl(pcie->base + PCIE_SYS_CFG);
> + val |= PCIE_PORT_PERST(port->index);
> + writel(val, pcie->base + PCIE_SYS_CFG);
> +
> + /* de-assert port PERST_N */
> + val = readl(pcie->base + PCIE_SYS_CFG);
> + val &= ~PCIE_PORT_PERST(port->index);
> + writel(val, pcie->base + PCIE_SYS_CFG);
> +
> + /* 100ms timeout value should be enough for Gen1/2 training */
> + err = readl_poll_timeout(port->base + PCIE_LINK_STATUS, val,
> +  !!(val & PCIE_PORT_LINKUP), 20,
> +  100 * USEC_PER_MSEC);
> + if (err)
> + return -ETIMEDOUT;
>  
>   /* enable interrupt */
>   val = readl(pcie->base + PCIE_INT_ENABLE);
> @@ -209,30 +237,14 @@ static void mtk_pcie_configure_rc(struct mtk_pcie_port 
> *port)
>   writel(PCIE_CONF_ADDR(PCIE_FTS_NUM, func, slot, 0),
>  pcie->base + PCIE_CFG_ADDR);
>   writel(val, pcie->base + PCIE_CFG_DATA);
> -}
>  
> -static void mtk_pcie_assert_ports(struct mtk_pcie_port *port)
> -{
> - struct mtk_pcie *pcie = port->pcie;
> - u32 val;
> -
> - /* assert port PERST_N */
> - val = readl(pcie->base + PCIE_SYS_CFG);
> - val |= PCIE_PORT_PERST(port->index);
> - writel(val, pcie->base + PCIE_SYS_CFG);
> -
> - /* de-assert port PERST_N */
> - val = readl(pcie->base + PCIE_SYS_CFG);
> - val &= ~PCIE_PORT_PERST(port->index);
> - writel(val, pcie->base + PCIE_SYS_CFG);
> -
> - /* PCIe v2.0 need at least 100ms delay to train from Gen1 to Gen2 */
> - msleep(100);
> + return 0;
>  }
>  
>  static void mtk_pcie_enable_ports(struct mtk_pcie_port *port)
>  {
> - struct device *dev = port->pcie->dev;
> + struct mtk_pcie *pcie = port->pcie;
> + struct device *dev = pcie->dev;
>   int err;
>  
>   err = clk_prepare_enable(port->sys_ck);
> @@ -250,13 +262,8 @@ static void mtk_pcie_enable_ports(struct mtk_pcie_port 
> *port)
>   goto err_phy_on;
>   }
>  
> - mtk_pcie_assert_ports(port);
> -
> - /* if link up, then setup root port 

Re: [PATCH v2 1/5] PCI: mediatek: Add a structure to abstract the controller generations

[Honghui Zhang]

On Thu, 2017-07-27 at 10:58 +0800, honghui.zh...@mediatek.com wrote:
> From: Ryder Lee 
> 
> Introduce a structure "mtk_pcie_soc" to abstract the differences between
> controller generations, and the .startup() hook is used to encapsulate
> some SoC-dependent related setting. In doing so, the common code which
> will be reused by future chips.
> 
> In addition, we change the approaches to waiting Gen2 training by using
> readl_poll_timeout() calls.
> 
> Signed-off-by: Ryder Lee 
> Signed-off-by: Honghui Zhang 
> ---
>  drivers/pci/host/pcie-mediatek.c | 81 
> +++-
>  1 file changed, 47 insertions(+), 34 deletions(-)
> 
> diff --git a/drivers/pci/host/pcie-mediatek.c 
> b/drivers/pci/host/pcie-mediatek.c
> index 5a9d858..7f952a4 100644
> --- a/drivers/pci/host/pcie-mediatek.c
> +++ b/drivers/pci/host/pcie-mediatek.c
> @@ -16,6 +16,7 @@
>  

Sorry about the disturb, I send the wrong patch for this one.
I will resend the right version for this last patch.

thanks.
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -63,6 +64,18 @@
>  #define PCIE_FC_CREDIT_MASK  (GENMASK(31, 31) | GENMASK(28, 16))
>  #define PCIE_FC_CREDIT_VAL(x)((x) << 16)
>  
> +struct mtk_pcie_port;
> +
> +/**
> + * struct mtk_pcie_soc - differentiate between host generations
> + * @ops: pointer to configuration access functions
> + * @startup: pointer to controller setting functions
> + */
> +struct mtk_pcie_soc {
> + struct pci_ops *ops;
> + int (*startup)(struct mtk_pcie_port *port);
> +};
> +
>  /**
>   * struct mtk_pcie_port - PCIe port information
>   * @base: IO mapped register base
> @@ -96,6 +109,7 @@ struct mtk_pcie_port {
>   * @busn: bus range
>   * @offset: IO / Memory offset
>   * @ports: pointer to PCIe port information
> + * @soc: pointer to SoC-dependent operations
>   */
>  struct mtk_pcie {
>   struct device *dev;
> @@ -111,13 +125,9 @@ struct mtk_pcie {
>   resource_size_t io;
>   } offset;
>   struct list_head ports;
> + const struct mtk_pcie_soc *soc;
>  };
>  
> -static inline bool mtk_pcie_link_up(struct mtk_pcie_port *port)
> -{
> - return !!(readl(port->base + PCIE_LINK_STATUS) & PCIE_PORT_LINKUP);
> -}
> -
>  static void mtk_pcie_subsys_powerdown(struct mtk_pcie *pcie)
>  {
>   struct device *dev = pcie->dev;
> @@ -171,12 +181,30 @@ static struct pci_ops mtk_pcie_ops = {
>   .write = pci_generic_config_write,
>  };
>  
> -static void mtk_pcie_configure_rc(struct mtk_pcie_port *port)
> +static int mtk_pcie_startup_ports(struct mtk_pcie_port *port)
>  {
>   struct mtk_pcie *pcie = port->pcie;
>   u32 func = PCI_FUNC(port->index << 3);
>   u32 slot = PCI_SLOT(port->index << 3);
>   u32 val;
> + int err;
> +
> + /* assert port PERST_N */
> + val = readl(pcie->base + PCIE_SYS_CFG);
> + val |= PCIE_PORT_PERST(port->index);
> + writel(val, pcie->base + PCIE_SYS_CFG);
> +
> + /* de-assert port PERST_N */
> + val = readl(pcie->base + PCIE_SYS_CFG);
> + val &= ~PCIE_PORT_PERST(port->index);
> + writel(val, pcie->base + PCIE_SYS_CFG);
> +
> + /* 100ms timeout value should be enough for Gen1/2 training */
> + err = readl_poll_timeout(port->base + PCIE_LINK_STATUS, val,
> +  !!(val & PCIE_PORT_LINKUP), 20,
> +  100 * USEC_PER_MSEC);
> + if (err)
> + return -ETIMEDOUT;
>  
>   /* enable interrupt */
>   val = readl(pcie->base + PCIE_INT_ENABLE);
> @@ -209,30 +237,14 @@ static void mtk_pcie_configure_rc(struct mtk_pcie_port 
> *port)
>   writel(PCIE_CONF_ADDR(PCIE_FTS_NUM, func, slot, 0),
>  pcie->base + PCIE_CFG_ADDR);
>   writel(val, pcie->base + PCIE_CFG_DATA);
> -}
>  
> -static void mtk_pcie_assert_ports(struct mtk_pcie_port *port)
> -{
> - struct mtk_pcie *pcie = port->pcie;
> - u32 val;
> -
> - /* assert port PERST_N */
> - val = readl(pcie->base + PCIE_SYS_CFG);
> - val |= PCIE_PORT_PERST(port->index);
> - writel(val, pcie->base + PCIE_SYS_CFG);
> -
> - /* de-assert port PERST_N */
> - val = readl(pcie->base + PCIE_SYS_CFG);
> - val &= ~PCIE_PORT_PERST(port->index);
> - writel(val, pcie->base + PCIE_SYS_CFG);
> -
> - /* PCIe v2.0 need at least 100ms delay to train from Gen1 to Gen2 */
> - msleep(100);
> + return 0;
>  }
>  
>  static void mtk_pcie_enable_ports(struct mtk_pcie_port *port)
>  {
> - struct device *dev = port->pcie->dev;
> + struct mtk_pcie *pcie = port->pcie;
> + struct device *dev = pcie->dev;
>   int err;
>  
>   err = clk_prepare_enable(port->sys_ck);
> @@ -250,13 +262,8 @@ static void mtk_pcie_enable_ports(struct mtk_pcie_port 
> *port)
>   goto err_phy_on;
>   }
>  
> - mtk_pcie_assert_ports(port);
> -
> - /* if link up, then setup root port configuration space */
> - if (mtk_pcie_link_up(port)) {
> -